Searched full:events (Results 1 – 25 of 552) sorted by relevance
12345678910>>...23
| /Documentation/ABI/testing/ |
| D | sysfs-bus-iio | 15 based on hardware generated events (e.g. data ready) or
92 buffered samples and events for device X.
834 What: /sys/bus/iio/devices/iio:deviceX/events
838 Configuration of which hardware generated events are passed up
841 What: /sys/.../iio:deviceX/events/in_accel_x_thresh_rising_en
842 What: /sys/.../iio:deviceX/events/in_accel_x_thresh_falling_en
843 What: /sys/.../iio:deviceX/events/in_accel_y_thresh_rising_en
844 What: /sys/.../iio:deviceX/events/in_accel_y_thresh_falling_en
845 What: /sys/.../iio:deviceX/events/in_accel_z_thresh_rising_en
846 What: /sys/.../iio:deviceX/events/in_accel_z_thresh_falling_en
[all …]
|
| D | sysfs-bus-event_source-devices-events | 1 What: /sys/devices/cpu/events/
2 /sys/devices/cpu/events/branch-misses
3 /sys/devices/cpu/events/cache-references
4 /sys/devices/cpu/events/cache-misses
5 /sys/devices/cpu/events/stalled-cycles-frontend
6 /sys/devices/cpu/events/branch-instructions
7 /sys/devices/cpu/events/stalled-cycles-backend
8 /sys/devices/cpu/events/instructions
9 /sys/devices/cpu/events/cpu-cycles
15 Description: Generic performance monitoring events
[all …]
|
| /Documentation/userspace-api/media/v4l/ |
| D | dev-event.rst | 11 include start of frame or loss of signal events, for example. Changes in
13 events.
15 To receive events, the events the user is interested in first must be
18 an event is subscribed, the events of subscribed types are dequeueable
19 using the :ref:`VIDIOC_DQEVENT` ioctl. Events may be
21 type V4L2_EVENT_ALL may be used to unsubscribe all the events the
28 The information on dequeueable events is obtained by using select or
29 poll system calls on video devices. The V4L2 events use POLLPRI events
33 events:
|
| /Documentation/userspace-api/gpio/ |
| D | gpio-v2-lineinfo-changed-read.rst | 12 GPIO_V2_LINEINFO_CHANGED_READ - Read line info changed events for watched
27 The buffer to contain the :c:type:`events<gpio_v2_line_info_changed>`.
36 Read line info changed events for watched lines from the chip.
42 These events relate to changes in a line's request state or configuration,
43 not its value. Use gpio-v2-line-event-read.rst to receive events when a
47 info changed events. Subsequently, a request, release, or reconfiguration
50 The kernel timestamps events when they occur and stores them in a buffer
53 The size of the kernel event buffer is fixed at 32 events per ``chip_fd``.
55 The buffer may overflow if bursts of events occur quicker than they are read
59 Events read from the buffer are always in the same order that they were
[all …]
|
| D | gpio-lineinfo-changed-read.rst | 16 GPIO_LINEINFO_CHANGED_READ - Read line info change events for watched lines
31 The buffer to contain the :c:type:`events<gpioline_info_changed>`.
40 Read line info change events for watched lines from the chip.
46 These events relate to changes in a line's request state or configuration,
47 not its value. Use gpio-lineevent-data-read.rst to receive events when a
51 info changed events. Subsequently, a request, release, or reconfiguration
54 The kernel timestamps events when they occur and stores them in a buffer
57 The size of the kernel event buffer is fixed at 32 events per ``chip_fd``.
59 The buffer may overflow if bursts of events occur quicker than they are read
63 Events read from the buffer are always in the same order that they were
[all …]
|
| D | gpio-v2-line-event-read.rst | 12 GPIO_V2_LINE_EVENT_READ - Read edge detection events for lines from a request.
27 The buffer to contain the :c:type:`events<gpio_v2_line_event>`.
36 Read edge detection events for lines from a request.
40 both. Edge events are then generated whenever edge interrupts are detected on
48 The kernel captures and timestamps edge events as close as possible to their
52 Events read from the buffer are always in the same order that they were
61 The buffer may overflow if bursts of events occur quicker than they are read
66 To minimize the number of calls required to copy events from the kernel to
67 userspace, `read()` supports copying multiple events. The number of events
72 does not remove or modify the events already contained in the kernel event
|
| D | gpio-lineevent-data-read.rst | 16 GPIO_LINEEVENT_DATA_READ - Read edge detection events from a line event.
31 The buffer to contain the :c:type:`events<gpioevent_data>`.
40 Read edge detection events for a line from a line event.
44 both. Edge events are then generated whenever edge interrupts are detected on
52 The kernel captures and timestamps edge events as close as possible to their
62 Events read from the buffer are always in the same order that they were
65 The size of the kernel event buffer is fixed at 16 events.
67 The buffer may overflow if bursts of events occur quicker than they are read
71 To minimize the number of calls required to copy events from the kernel to
72 userspace, `read()` supports copying multiple events. The number of events
|
| /Documentation/arch/powerpc/ |
| D | pmu-ebb.rst | 6 branch directly to a specified user space address when certain events occur.
20 Throughout this document we will refer to an "EBB event" or "EBB events". This
22 attr.config. All events which can be configured on the hardware PMU are
23 possible "EBB events".
32 It is a feature of the perf_events API that events can be created on other
34 events, however unless the target process enables EBBs (via mtspr(BESCR)) no
38 actually configure any events. At a later time another process can come along
45 events can be configured. This means that EBB events can not be run
46 concurrently with regular 'perf' commands, or any other perf events.
50 its events could not run.
[all …]
|
| /Documentation/admin-guide/perf/ |
| D | arm_dsu_pmu.rst | 7 allows counting the various events related to the L3 cache, Snoop Control Unit
12 PMU doesn't support process specific events and cannot be used in sampling mode.
14 The DSU provides a bitmap for a subset of implemented events via hardware
15 registers. There is no way for the driver to determine if the other events
16 are available or not. Hence the driver exposes only those events advertised
17 by the DSU, in "events" directory under::
21 The user should refer to the TRM of the product to figure out the supported events
22 and use the raw event code for the unlisted events.
|
| D | arm-cmn.rst | 16 PMU events
22 each mesh counts its own events entirely independently, and additional
25 Most events are specified in a format based directly on the TRM
27 event number. Some events require an additional occupancy ID, which is
30 * Since RN-D nodes do not have any distinct events from RN-I nodes, they
37 * XP events also encode the port and channel in the "eventid" field, to
50 The PMU can also count watchpoint events to monitor specific flit
52 events can be global or targeted with a particular XP's "nodeid" value.
54 register selection, separate events are provided for flit uploads and
61 REQ or SNP channel, it can be specified as two events - one for each
[all …]
|
| D | arm-ccn.rst | 14 description of available events and configuration options
18 and config2 fields of the perf_event_attr structure. The "events"
20 events, that can be used with perf tool. For example "xp_valid_flit"
24 For events originating from device, "node" defines its index.
26 Crosspoint PMU events require "xp" (index), "bus" (bus number)
29 Crosspoint watchpoint-based events (special "event" value 0xfe)
44 the CCN PMU events. It is recommended that the user space tools
45 request the events on this processor (if not, the perf_event->cpu value
47 the events are migrated to another one and the attribute is updated.
|
| D | qcom_l2_pmu.rst | 12 The driver provides a description of its available events and configuration
15 The "format" directory describes the format of the events.
17 Events can be envisioned as a 2-dimensional array. Each column represents
18 a group of events. There are 8 groups. Only one entry from each
19 group can be in use at a time. If multiple events from the same group
20 are specified, the conflicting events cannot be counted at the same time.
22 Events are specified as 0xCCG, where CC is 2 hex digits specifying
30 events on that cluster.
|
| D | cxl.rst | 13 message types and a set of additional events for things commonly counted on
14 CXL devices (e.g. DRAM events).
32 PMU driver provides description of available events and filter options in sysfs.
36 parameters) fields of the perf_event_attr structure. The "events" directory
37 describes all documented events show in perf list.
39 The events shown in perf list are the most fine grained events with a single
40 bit of the event mask set. More general events may be enable by setting
62 Vendor specific events may also be available and if so can be used via
|
| D | hisi-pcie-pmu.rst | 20 PMU driver provides description of available events and filter options in sysfs,
23 The "format" directory describes all formats of the config (events) and config1
24 (filter options) fields of the perf_event_attr structure. The "events" directory
25 describes all documented events shown in perf list.
45 The related events usually used to calculate the bandwidth, latency or others.
46 They need to start and end counting at the same time, therefore related events
48 ways to know if they are related events:
50 a) By event name, such as the latency events "xxx_latency, xxx_cnt" or
51 bandwidth events "xxx_flux, xxx_time".
77 "port" filter can be used in all PCIe PMU events, target Root Port can be
[all …]
|
| /Documentation/trace/ |
| D | events-power.rst | 5 The power tracing system captures events related to power transitions
8 - Power state switch which reports events related to suspend (S-states),
16 Cf. include/trace/events/power.h for the events definitions.
18 1. Power state switch events
24 A 'cpu' event class gathers the CPU-related events: cpuidle and
48 2. Clocks events
50 The clock events are used for clock enable/disable and for
62 3. Power domains events
64 The power domain events are used for power domains transitions
72 4. PM QoS events
[all …]
|
| D | index.rst | 18 events
19 events-kmem
20 events-power
21 events-nmi
22 events-msr
|
| D | tracepoint-analysis.rst | 2 Notes on Analysing Behaviour Using Events and Tracepoints
13 Simplistically, tracepoints represent important events that can be
16 gathering and interpreting these events. Lacking any current Best Practises,
23 2. Listing Available Events
29 All possible events are visible from /sys/kernel/tracing/events. Simply
32 $ find /sys/kernel/tracing/events -type d
34 will give a fair indication of the number of events available.
39 Discovery and enumeration of all counters and events, including tracepoints,
40 are available with the perf tool. Getting a list of available events is a
52 3. Enabling Events
[all …]
|
| D | events.rst | 26 The events which are available for tracing can be found in the file
34 .. Note:: '>>' is necessary, otherwise it will firstly disable all the events.
41 To disable all events, echo an empty line to the set_event file::
45 To enable all events, echo ``*:*`` or ``*:`` to the set_event file::
49 The events are organized into subsystems, such as ext4, irq, sched,
52 file. All of the events in a subsystem can be specified via the syntax
53 ``<subsystem>:*``; for example, to enable all irq events, you can use the
61 The events available are also listed in /sys/kernel/tracing/events/ hierarchy
66 # echo 1 > /sys/kernel/tracing/events/sched/sched_wakeup/enable
70 # echo 0 > /sys/kernel/tracing/events/sched/sched_wakeup/enable
[all …]
|
| /Documentation/devicetree/bindings/goldfish/ |
| D | events.txt | 1 Android Goldfish Events Keypad
3 Android goldfish events keypad device generated by android emulator.
7 - compatible : should contain "google,goldfish-events-keypad" to match emulator
13 goldfish-events@9040000 {
14 compatible = "google,goldfish-events-keypad";
|
| /Documentation/driver-api/surface_aggregator/clients/ |
| D | cdev.rst | 28 Receiving Events
31 Events can be received by reading from the device-file. The are represented by
34 Before events are available to be read, however, the desired notifiers must be
41 Notifiers themselves do not enable events on the EC. Thus, it may additionally
42 be necessary to enable events via the ``SSAM_CDEV_EVENT_ENABLE`` IOCTL. While
43 notifiers work per-client (i.e. per-device-file-instance), events are enabled
46 IOCTLs take care of reference counting the events, such that an event is
49 Note that enabled events are not automatically disabled once the client
52 is, however, perfectly valid to enable and disable events on different client
53 instances. For example, it is valid to set up notifiers and read events on
[all …]
|
| /Documentation/driver-api/media/ |
| D | v4l2-event.rst | 3 V4L2 events
6 The V4L2 events provide a generic way to pass events to user space.
7 The driver must use :c:type:`v4l2_fh` to be able to support V4L2 events.
9 Events are subscribed per-filehandle. An event specification consists of a
14 The :c:type:`v4l2_fh` struct has a list of subscribed events on its
23 of :c:func:`v4l2_event_subscribe`. This ringbuffer is used to store any events
28 generating lots of events of one type in a short time, then that will
29 not overwrite events of another type.
31 But if you get more events of one type than the size of the
47 - struct v4l2_fh has two lists: one of the ``subscribed`` events,
[all …]
|
| /Documentation/input/ |
| D | notifier.rst | 6 events (see kbd_keycode() function for details). The passed structure is
15 - KBD_KEYCODE events are always sent before other events, value is the keycode.
16 - KBD_UNBOUND_KEYCODE events are sent if the keycode is not bound to a keysym.
18 - KBD_UNICODE events are sent if the keycode -> keysym translation produced a
20 - KBD_KEYSYM events are sent if the keycode -> keysym translation produced a
22 - KBD_POST_KEYSYM events are sent after the treatment of non-unicode keysyms.
|
| D | event-codes.rst | 12 A single hardware event generates multiple input events. Each input event
14 used to separate input events into packets of input data changes occurring at
18 The input protocol is a stateful protocol. Events are emitted only when values
31 type has a set of applicable codes to be used in generating events. See the
36 - Used as markers to separate events. Events may be separated in time or in
99 - Used to synchronize and separate events into packets of input data changes
110 - Used to synchronize and separate touch events. See the
116 Client should ignore all events up to and including next SYN_REPORT
123 EV_KEY events take the form KEY_<name> or BTN_<name>. For example, KEY_A is used
126 emitted with value 0. Some hardware send events when a key is repeated. These
[all …]
|
| /Documentation/admin-guide/laptops/ |
| D | sonypi.rst | 17 It will give access (through a user space utility) to some events those laptops
20 - jogdial events (the small wheel on the side of Vaios)
21 - capture button events (only on Vaio Picturebook series)
27 Those events (see linux/sonypi.h) can be polled using the character device node
29 A simple daemon which translates the jogdial movements into mouse wheel events
32 Another option to intercept the events is to get them directly through the
64 fnkeyinit: on some Vaios (C1VE, C1VR etc), the Fn key events don't
73 verbose: set to 1 to print unknown events received from the
75 set to 2 to print all events received from the
79 events. If the driver worked for you in the past
[all …]
|
| /Documentation/sound/designs/ |
| D | seq-oss.rst | 22 * Normal sequencer and MIDI events:
24 They are converted to the ALSA sequencer events, and sent to the
27 * Timer events:
47 The events are queued before processing them.
59 The events can be processed in real time without using out of bound
61 events will be processed in real-time without queued. To switch off the
154 events from ``/dev/sequencer`` are processed and put onto the queue
157 All the events from ``/dev/sequencer`` are parsed at beginning.
158 The timing events are also parsed at this moment, so that the events may
161 In the real-time mode, all events are dispatched immediately.
[all …]
|
12345678910>>...23