| /kernel/linux/linux-4.19/arch/arm/mach-spear/ |
| D | pl080.c | 28 } signals[16] = {{0, 0}, }; variable
38 if (signals[signal].busy && in pl080_get_signal()
39 (signals[signal].val != cd->muxval)) { in pl080_get_signal()
45 if (!signals[signal].busy) { in pl080_get_signal()
58 signals[signal].busy++; in pl080_get_signal()
59 signals[signal].val = cd->muxval; in pl080_get_signal()
72 if (!signals[signal].busy) in pl080_put_signal()
75 signals[signal].busy--; in pl080_put_signal()
|
| /kernel/linux/linux-5.10/arch/arm/mach-spear/ |
| D | pl080.c | 28 } signals[16] = {{0, 0}, }; variable
38 if (signals[signal].busy && in pl080_get_signal()
39 (signals[signal].val != cd->muxval)) { in pl080_get_signal()
45 if (!signals[signal].busy) { in pl080_get_signal()
58 signals[signal].busy++; in pl080_get_signal()
59 signals[signal].val = cd->muxval; in pl080_get_signal()
72 if (!signals[signal].busy) in pl080_put_signal()
75 signals[signal].busy--; in pl080_put_signal()
|
| /kernel/linux/linux-5.10/tools/testing/selftests/arm64/fp/ |
| D | README | 30 Terminated by signal 15, no error, iterations=9467, signals=1014
33 Terminated by signal 15, no error, iterations=9448, signals=1028
36 Terminated by signal 15, no error, iterations=9436, signals=1039
39 Terminated by signal 15, no error, iterations=9421, signals=1039
42 Terminated by signal 15, no error, iterations=9403, signals=1039
45 Terminated by signal 15, no error, iterations=9385, signals=1036
48 Terminated by signal 15, no error, iterations=9376, signals=1039
51 Terminated by signal 15, no error, iterations=9361, signals=1039
54 Terminated by signal 15, no error, iterations=9350, signals=1039
|
| /kernel/linux/linux-4.19/Documentation/isdn/ |
| D | INTERFACE.fax | 72 ISDN_TTY_FAX_DR signals +FDR command to HL
74 ISDN_TTY_FAX_DT signals +FDT command to HL
76 ISDN_TTY_FAX_ET signals +FET command to HL
92 ISDN_TTY_FAX_ET signals end of data,
95 ISDN_TTY_FAX_FCON signals the established, outgoing connection,
98 ISDN_TTY_FAX_FCON_I signals the established, incoming connection,
103 ISDN_TTY_FAX_SENT signals that all data has been sent
107 ISDN_TTY_FAX_PTS signals a msg-confirmation (page sent successful),
114 ISDN_TTY_FAX_EOP signals end of data in receive mode,
|
| /kernel/linux/linux-5.10/drivers/net/wireless/rsi/ |
| D | Kconfig | 3 bool "Redpine Signals Inc devices"
16 tristate "Redpine Signals Inc 91x WLAN driver support"
24 bool "Redpine Signals Inc debug support"
32 tristate "Redpine Signals SDIO bus support"
40 tristate "Redpine Signals USB bus support"
48 bool "Redpine Signals WLAN BT Coexistence support"
|
| /kernel/linux/linux-4.19/drivers/net/wireless/rsi/ |
| D | Kconfig | 2 bool "Redpine Signals Inc devices"
15 tristate "Redpine Signals Inc 91x WLAN driver support"
23 bool "Redpine Signals Inc debug support"
31 tristate "Redpine Signals SDIO bus support"
39 tristate "Redpine Signals USB bus support"
47 bool "Redpine Signals WLAN BT Coexistence support"
|
| /kernel/linux/linux-5.10/Documentation/driver-api/ |
| D | generic-counter.rst | 80 A counter is defined as a set of input signals associated with count
82 input signals as defined by the respective count functions. Within the
84 each associated with a set of Signals, whose respective Synapse
93 Synapses; i.e. the count data for a set of Signals. The Generic
111 A pair of quadrature encoding signals are evaluated to determine
135 Any state transition on either quadrature pair signals updates the
167 many Signals may be associated with even a single Count. For example, a
183 In this example, two Signals (quadrature encoder lines A and B) are
188 encoder counter device; the Count, Signals, and Synapses simply
191 Signals associated with the same Count can have differing Synapse action
[all …]
|
| D | hsi.rst | 15 The serial protocol uses two signals, DATA and FLAG as combined data and clock
16 signals and an additional READY signal for flow control. An additional WAKE
17 signal can be used to wakeup the chips from standby modes. The signals are
18 commonly prefixed by AC for signals going from the application die to the
19 cellular die and CA for signals going the other way around.
|
| /kernel/linux/linux-5.10/drivers/staging/vc04_services/vchiq-mmal/ |
| D | mmal-msg.h | 220 /* Signals that the current payload is the end of the stream of data */
222 /* Signals that the start of the current payload starts a frame */
224 /* Signals that the end of the current payload ends a frame */
226 /* Signals that the current payload contains only complete frames (>1) */
230 /* Signals that the current payload is a keyframe (i.e. self decodable) */
233 * Signals a discontinuity in the stream of data (e.g. after a seek).
238 * Signals a buffer containing some kind of config data for the component
242 /* Signals an encrypted payload */
244 /* Signals a buffer containing side information */
247 * Signals a buffer which is the snapshot/postview image from a stills
[all …]
|
| /kernel/linux/linux-5.10/Documentation/trace/coresight/ |
| D | coresight-ect.rst | 14 individual input and output hardware signals known as triggers to and from
50 The hardware trigger signals can also be connected to non-CoreSight devices
72 capable of generating or using trigger signals.::
100 Individual trigger connection information. This describes trigger signals for
108 * ``in_types`` : functional types for in signals.
109 * ``out_signals`` : output trigger signals for this connection.
110 * ``out_types`` : functional types for out signals.
127 If a connection has zero signals in either the 'in' or 'out' triggers then
177 * ``chan_free``: Show channels with no attached signals.
185 dangerous output signals to be set.
[all …]
|
| /kernel/linux/linux-4.19/drivers/staging/vc04_services/bcm2835-camera/ |
| D | mmal-msg.h | 216 /** Signals that the current payload is the end of the stream of data */
218 /** Signals that the start of the current payload starts a frame */
220 /** Signals that the end of the current payload ends a frame */
222 /** Signals that the current payload contains only complete frames (>1) */
225 /** Signals that the current payload is a keyframe (i.e. self decodable) */
227 /** Signals a discontinuity in the stream of data (e.g. after a seek).
231 /** Signals a buffer containing some kind of config data for the component
235 /** Signals an encrypted payload */
237 /** Signals a buffer containing side information */
239 /** Signals a buffer which is the snapshot/postview image from a stills
[all …]
|
| /kernel/linux/linux-5.10/arch/mips/include/asm/mach-rc32434/ |
| D | gpio.h | 39 /* UART GPIO signals */
45 /* M & P bus GPIO signals */
51 /* CPU GPIO signals */
54 /* Reserved GPIO signals */
63 /* NAND GPIO signals */
|
| /kernel/linux/linux-4.19/arch/mips/include/asm/mach-rc32434/ |
| D | gpio.h | 39 /* UART GPIO signals */
45 /* M & P bus GPIO signals */
51 /* CPU GPIO signals */
54 /* Reserved GPIO signals */
63 /* NAND GPIO signals */
|
| /kernel/linux/linux-5.10/Documentation/devicetree/bindings/gpio/ |
| D | nvidia,tegra186-gpio.txt | 10 read/write the value of, numerous GPIO signals. Routing of GPIO signals to
24 b) GPIO registers, which allow manipulation of the GPIO signals. In some GPIO
48 Each GPIO controller can generate a number of interrupt signals. Each signal
50 number of interrupt signals generated by a controller varies as a rough function
54 Each GPIO controller in fact generates multiple interrupts signals for each set
56 interrupt signals generated by a set-of-ports. The intent is for each generated
59 per-port-set signals is reported via a separate register. Thus, a driver needs
|
| D | gpio-eic-sprd.txt | 11 connections. A debounce mechanism is used to capture the input signals'
19 The EIC-latch sub-module is used to latch some special power down signals
21 clock to capture signals.
23 The EIC-async sub-module uses a 32kHz clock to capture the short signals
28 when detecting input signals.
|
| /kernel/linux/linux-4.19/Documentation/devicetree/bindings/gpio/ |
| D | nvidia,tegra186-gpio.txt | 10 read/write the value of, numerous GPIO signals. Routing of GPIO signals to
24 b) GPIO registers, which allow manipulation of the GPIO signals. In some GPIO
48 Each GPIO controller can generate a number of interrupt signals. Each signal
50 number of interrupt signals generated by a controller varies as a rough function
54 Each GPIO controller in fact generates multiple interrupts signals for each set
56 interrupt signals generated by a set-of-ports. The intent is for each generated
59 per-port-set signals is reported via a separate register. Thus, a driver needs
|
| D | gpio-eic-sprd.txt | 11 connections. A debounce mechanism is used to capture the input signals'
19 The EIC-latch sub-module is used to latch some special power down signals
21 clock to capture signals.
23 The EIC-async sub-module uses a 32kHz clock to capture the short signals
28 when detecting input signals.
|
| /kernel/linux/linux-4.19/Documentation/devicetree/bindings/display/panel/ |
| D | panel-common.txt | 62 and timing of those control signals are device-specific and left for panel
64 used for panels that implement compatible control signals.
70 enable signals (or active high power down signals) can be supported by
78 while active. Active high reset signals can be supported by inverting the
97 backlight control through GPIO, PWM or other signals connected to an external
|
| /kernel/linux/linux-5.10/Documentation/devicetree/bindings/display/panel/ |
| D | panel-common.yaml | 105 # and timing of those control signals are device-specific and left for panel
107 # used for panels that implement compatible control signals.
116 signals (or active high power down signals) can be supported by inverting
127 while active. Active high reset signals can be supported by inverting the
134 The tearing effect signal is active high. Active low signals can be
152 # backlight control through GPIO, PWM or other signals connected to an external
|
| /kernel/linux/linux-5.10/Documentation/devicetree/bindings/reset/ |
| D | reset.txt | 3 This binding is intended to represent the hardware reset signals present
4 internally in most IC (SoC, FPGA, ...) designs. Reset signals for whole
24 may be reset. Instead, reset signals should be represented in the DT node
27 block node for dedicated reset signals. The intent of this binding is to give
28 appropriate software access to the reset signals in order to manage the HW,
|
| /kernel/linux/linux-4.19/Documentation/devicetree/bindings/reset/ |
| D | reset.txt | 3 This binding is intended to represent the hardware reset signals present
4 internally in most IC (SoC, FPGA, ...) designs. Reset signals for whole
24 may be reset. Instead, reset signals should be represented in the DT node
27 block node for dedicated reset signals. The intent of this binding is to give
28 appropriate software access to the reset signals in order to manage the HW,
|
| /kernel/linux/linux-5.10/Documentation/devicetree/bindings/arm/ |
| D | coresight-cti.yaml | 20 output hardware trigger signals. CTIs can have a maximum number of input and
21 output hardware trigger signals (8 each for v1 CTI, 32 each for v2 CTI). The
31 In general the connections between CTI and components via the trigger signals
41 binding can be declared with no explicit trigger signals. This will result
58 signals to GEN_IO.
60 Note that some hardware trigger signals can be connected to non-CoreSight
132 A trigger connections child node which describes the trigger signals
155 signals. Types in this array match to the corresponding signal in the
172 signals. Types in this array match to the corresponding signal
181 List of CTI trigger out signals that will be blocked from becoming
|
| /kernel/linux/linux-5.10/drivers/hwtracing/coresight/ |
| D | coresight-cti.h | 54 * CTI CSSoc 600 has a max of 32 trigger signals per direction.
62 * Group of related trigger signals
64 * @nr_sigs: number of signals in the group.
66 * @sig_types: array of types for the signals, length nr_sigs.
76 * lists input and output trigger signals for the device
78 * @con_in: connected CTIIN signals for the device.
79 * @con_out: connected CTIOUT signals for the device.
118 * @nr_trig_max: Max number of trigger signals implemented on device.
|
| /kernel/linux/linux-4.19/Documentation/driver-api/ |
| D | hsi.rst | 15 The serial protocol uses two signals, DATA and FLAG as combined data and clock
16 signals and an additional READY signal for flow control. An additional WAKE
17 signal can be used to wakeup the chips from standby modes. The signals are
18 commonly prefixed by AC for signals going from the application die to the
19 cellular die and CA for signals going the other way around.
|
| /kernel/linux/linux-5.10/arch/um/os-Linux/ |
| D | signal.c | 44 /* enable signals if sig isn't IRQ signal */ in sig_handler_common()
54 * These are the asynchronous signals. SIGPROF is excluded because we want to
184 * Again, pending comes back with a mask of signals in hard_handler()
241 * This must return with signals disabled, so this barrier in block_signals()
265 * Save and reset save_pending after enabling signals. This in unblock_signals()
280 * We have pending interrupts, so disable signals, as the in unblock_signals()
285 * pending signals will mess up the tracing state. in unblock_signals()
311 /* Re-enable signals and trace that we're doing so. */ in unblock_signals()
|