Searched full:consumer (Results 1 – 25 of 220) sorted by relevance
123456789
| /Documentation/driver-api/iio/ |
| D | hw-consumer.rst | 2 HW consumer
5 case the buffers between IIO provider and IIO consumer are handled by hardware.
6 The Industrial I/O HW consumer offers a way to bond these IIO devices without
8 :file:`drivers/iio/buffer/hw-consumer.c`
11 * struct iio_hw_consumer — Hardware consumer structure
12 * :c:func:`iio_hw_consumer_alloc` — Allocate IIO hardware consumer
13 * :c:func:`iio_hw_consumer_free` — Free IIO hardware consumer
14 * :c:func:`iio_hw_consumer_enable` — Enable IIO hardware consumer
15 * :c:func:`iio_hw_consumer_disable` — Disable IIO hardware consumer
18 HW consumer setup
[all …]
|
| /Documentation/ABI/testing/ |
| D | sysfs-class-devlink | 7 denoted as ... above, is of the form <supplier>--<consumer>
8 where <supplier> is the supplier bus:device name and <consumer>
9 is the consumer bus:device name.
16 automatically removed by the driver core when the consumer and
21 - 'consumer unbind'
25 'consumer unbind' means the device link will be removed when
26 the consumer's driver is unbound from the consumer device.
32 when as long as the supplier and consumer devices themselves
35 What: /sys/class/devlink/.../consumer
39 This file is a symlink to the consumer device's sysfs directory.
[all …]
|
| D | sysfs-devices-consumer | 1 What: /sys/devices/.../consumer:<consumer>
5 The /sys/devices/.../consumer:<consumer> are symlinks to device
6 links where this device is the supplier. <consumer> denotes the
7 name of the consumer in that device link and is of the form
|
| /Documentation/power/regulator/ |
| D | overview.rst | 39 - Consumer
43 Static: consumer does not change its supply voltage or
48 Dynamic: consumer needs to change its supply voltage or
59 Regulator -+-> Switch-1 -+-> Switch-2 --> [Consumer A]
61 | +-> [Consumer B], [Consumer C]
63 +-> [Consumer D], [Consumer E]
69 - Domain 3: Consumer A.
78 Regulator-1 -+-> Regulator-2 -+-> [Consumer A]
80 +-> [Consumer B]
84 - Domain 1: Regulator-2, Consumer B.
[all …]
|
| D | machine.rst | 10 Regulator-1 -+-> Regulator-2 --> [Consumer A @ 1.8 - 2.0V]
12 +-> [Consumer B @ 3.3V]
20 const char *dev_name; /* consumer dev_name() */
21 const char *supply; /* consumer supply - e.g. "vcc" */
27 REGULATOR_SUPPLY("Vcc", "consumer B"),
31 REGULATOR_SUPPLY("Vcc", "consumer A"),
34 This maps Regulator-1 to the 'Vcc' supply for Consumer B and maps Regulator-2
35 to the 'Vcc' supply for Consumer A.
59 with the core so that Regulator-1 is also enabled when Consumer A enables its
|
| D | consumer.rst | 2 Regulator Consumer Driver Interface
5 This text describes the regulator interface for consumer device drivers.
9 1. Consumer Regulator Access (static & dynamic drivers)
12 A consumer driver can get access to its supply regulator by calling ::
16 The consumer passes in its struct device pointer and power supply ID. The core
19 regulator that supplies this consumer.
21 To release the regulator the consumer driver should call ::
25 Consumers can be supplied by more than one regulator e.g. codec consumer with
39 A consumer can enable its power supply by calling::
45 This may happen if the consumer shares the regulator or the regulator has been
[all …]
|
| /Documentation/admin-guide/gpio/ |
| D | gpio-virtuser.rst | 3 Virtual GPIO Consumer
6 The virtual GPIO Consumer module allows users to instantiate virtual devices
8 consumer devices can be instantiated from device-tree or over configfs.
10 A virtual consumer uses the driver-facing GPIO APIs and allows to cover it with
17 The gpio-consumer module registers a configfs subsystem called
22 values of exposed attributes. Once the consumer is instantiated, this hierarchy
27 This is the top directory of the gpio-consumer configfs tree.
29 **Group:** ``/config/gpio-consumer/example-name``
31 **Attribute:** ``/config/gpio-consumer/example-name/live``
33 **Attribute:** ``/config/gpio-consumer/example-name/dev_name``
[all …]
|
| /Documentation/networking/ |
| D | tls-handshake.rst | 31 kernel consumer might require a TLS handshake. Handshake agents listen
46 A kernel TLS consumer initiates a client-side TLS handshake on an open
65 The @ta_sock field references an open and connected socket. The consumer
67 while the handshake is in progress. The consumer must also have
75 The consumer can provide a NUL-terminated hostname in the @ta_peername
79 The consumer can fill in the @ta_timeout_ms field to force the servicing
86 that are instantiated by the consumer before making the handshake
87 request. The consumer can provide a private keyring that is linked into
91 To request an x.509-authenticated TLS session, the consumer fills in
113 However, in this case, the consumer fills in the @ta_my_peerids array
[all …]
|
| /Documentation/core-api/ |
| D | circular-buffers.rst | 15 (2) Memory barriers for when the producer and the consumer of objects in the
19 producer and just one consumer. It is possible to handle multiple producers by
31 - The consumer.
44 (2) A 'tail' index - the point at which the consumer finds the next item in
115 but the consumer may still be depleting the buffer on another CPU and
118 To the consumer it will show an upper bound as the producer may be busy
121 (2) CIRC_CNT*() are intended to be used in the consumer. To the consumer they
122 will return a lower bound as the consumer controls the tail index, but the
126 To the producer it will show an upper bound as the consumer may be busy
130 producer and consumer become visible cannot be guaranteed as they are
[all …]
|
| /Documentation/driver-api/ |
| D | device_link.rst | 29 "supplier" device and its "consumer" devices, and it guarantees driver
30 presence on the supplier. The consumer devices are not probed before the
42 whenever and for as long as the consumer is runtime resumed.
49 :c:func:`device_initialize()` has been called for the consumer.
60 represents a driver presence dependency, yet is added from the consumer's
63 consumer in the first place. The onus is thus on the consumer to check
65 non-presence. [Note that it is valid to create a link from the consumer's
66 ``->probe`` callback while the supplier is still probing, but the consumer must
68 the case, for instance, if the consumer has just acquired some resources that
72 is added in the ``->probe`` callback of the supplier or consumer driver, it is
[all …]
|
| D | pwrseq.rst | 36 dependencies) that a consumer selects by its name when requesting a handle
43 A handle passed by the pwrseq core to every consumer that serves as the
47 Consumer interface
50 The consumer API is aimed to be as simple as possible. The driver interested in
54 the consumer can request the powering down of its target with
72 Dynamic consumer matching
82 client device is indeed its consumer. For example: if the provider binds to the
84 consumer driver controls one of its modules, the provider driver may parse the
86 the PMU to the consumer.
|
| D | reset.rst | 13 the `consumer driver interface <#consumer-driver-interface>`__ (`API reference
14 <#reset-consumer-api>`__), which allows peripheral drivers to request control
49 Reset consumer
54 Consumer driver interface
58 Consumer drivers use get and put operations to acquire and release reset
94 Consumer drivers use the reset_control_assert() and reset_control_deassert()
101 Consumer drivers using shared reset controls should assume that the reset line
104 consumer has requested it to be deasserted.
109 Consumer drivers use reset_control_reset() to trigger a reset pulse on a
112 requesting a pulse from any consumer driver will reset all connected
[all …]
|
| D | regulator.rst | 40 Consumer
49 regulator and all consumer devices. The configuration of the regulator
58 Consumer driver interface
61 This offers a similar API to the kernel clock framework. Consumer
79 regulators. Consumer devices use the :c:func:`regulator_enable()` and
86 cause the supply provided by the regulator to be disabled. Consumer
92 Some consumer devices may need to be able to dynamically configure their
160 .. kernel-doc:: include/linux/regulator/consumer.h
|
| /Documentation/infiniband/ |
| D | core_locking.rst | 62 example, a consumer may safely call ib_poll_cq() on multiple CPUs
71 allowed for a low-level driver to call a consumer's completion event
85 consumer CQ event callback:
89 /* ... */ consumer CQ event callback:
108 semaphores that could cause deadlock if a consumer calls back into
111 An upper level protocol consumer may begin using an IB device as
113 device. A consumer must finish all cleanup and free all resources
116 A consumer is permitted to sleep in its add and remove methods.
|
| /Documentation/devicetree/bindings/net/pcs/ |
| D | snps,dw-xpcs.yaml | 18 Synopsys PMA (also called DesignWare Consumer/Enterprise PHY) although in
30 - description: Synopsys DesignWare XPCS with Consumer Gen1 3G PMA
32 - description: Synopsys DesignWare XPCS with Consumer Gen2 3G PMA
34 - description: Synopsys DesignWare XPCS with Consumer Gen2 6G PMA
36 - description: Synopsys DesignWare XPCS with Consumer Gen4 3G PMA
38 - description: Synopsys DesignWare XPCS with Consumer Gen4 6G PMA
40 - description: Synopsys DesignWare XPCS with Consumer Gen5 10G PMA
42 - description: Synopsys DesignWare XPCS with Consumer Gen5 12G PMA
|
| /Documentation/devicetree/bindings/mux/ |
| D | mux-consumer.yaml | 4 $id: http://devicetree.org/schemas/mux/mux-consumer.yaml#
7 title: Common multiplexer controller consumer
24 each consumer. An optional property "mux-control-names" may contain a list of
34 the consumers want to control the mux controller. If the consumer needs
36 "mux-controls" can be used. If the consumer needs to set the mux
|
| /Documentation/crypto/ |
| D | intro.rst | 50 transformation objects is held by a crypto API consumer or another
52 consumer requests a transformation implementation. The consumer is then
68 returned to the consumer. Therefore, please refer to all initialization
69 API calls that refer to the data structure type a consumer is expected
|
| /Documentation/devicetree/bindings/access-controllers/ |
| D | access-controllers.yaml | 23 is a consumer and the access controller is the provider.
27 of the consumer device. A consumer node can refer to the provider by phandle
36 Each node can be a consumer for the several access controllers.
52 access-controllers entries. Consumer drivers will use
|
| /Documentation/devicetree/bindings/cpufreq/ |
| D | imx-cpufreq-dt.txt | 15 0: Consumer
16 1: Extended Consumer
27 /* grade >= 0, consumer only */
|
| /Documentation/devicetree/bindings/net/ |
| D | mdio-mux-multiplexer.yaml | 7 title: Properties for an MDIO bus multiplexer consumer device
13 This is a special case of MDIO mux when MDIO mux is defined as a consumer
43 mdio-mux-1 { // Mux consumer
63 mdio-mux-2 { // Mux consumer
|
| /Documentation/devicetree/bindings/reset/ |
| D | ti-syscon-reset.txt | 28 - #reset-cells : Should be 1. Please see the reset consumer node below
49 SysCon Reset Consumer Nodes
51 Each of the reset consumer nodes should have the following properties,
65 using the syscon node, and a consumer (a DSP device) on the TI Keystone 2
|
| /Documentation/devicetree/bindings/gpio/ |
| D | gpio-delay.yaml | 20 | GPIO | | | R | Consumer |
32 If the input on the consumer is controlled by an open-drain signal
77 consumer {
|
| /Documentation/devicetree/bindings/remoteproc/ |
| D | ti,pru-consumer.yaml | 4 $id: http://devicetree.org/schemas/remoteproc/ti,pru-consumer.yaml#
7 title: TI PRU Consumer Common Properties
13 A PRU application/consumer/user node typically uses one or more PRU device
|
| /Documentation/bpf/ |
| D | ringbuf.rst | 93 discarded. Discard is similar to commit, but makes consumer ignore the
113 a record as discarded, and such records are supposed to be ignored by consumer
128 of consumer/producer, respectively.
160 - consumer counter shows up to which logical position consumer consumed the
169 time if record is discarded. In the latter case, consumer is supposed to skip
180 completely lockless and independent. All records become available to consumer
197 being available after commit only if consumer has already caught up right up to
198 the record being committed. If not, consumer still has to catch up and thus
|
| /Documentation/driver-api/hte/ |
| D | tegra-hte.rst | 26 consumer can request an GPIO line.
39 provides an example of how a consumer can request an IRQ line. Since it is a
41 number that they are interested in. There is no userspace consumer support for
|
123456789