Searched full:consumer (Results 1 – 25 of 177) sorted by relevance
12345678
| /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 :c:type:`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/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 …]
|
| D | design.rst | 24 Consumer use cases
36 The consumer API should be structured so that these use cases are
|
| /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 | 33 "supplier" device and its "consumer" devices, and it guarantees driver
34 presence on the supplier. The consumer devices are not probed before the
46 whenever and for as long as the consumer is runtime resumed.
53 :c:func:`device_initialize()` has been called for the consumer.
64 represents a driver presence dependency, yet is added from the consumer's
67 consumer in the first place. The onus is thus on the consumer to check
69 non-presence. [Note that it is valid to create a link from the consumer's
70 ``->probe`` callback while the supplier is still probing, but the consumer must
72 the case, for instance, if the consumer has just acquired some resources that
76 is added in the ``->probe`` callback of the supplier or consumer driver, it is
[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/devicetree/bindings/net/ |
| D | mdio-mux-multiplexer.txt | 1 Properties for an MDIO bus multiplexer consumer device
3 This is a special case of MDIO mux when MDIO mux is defined as a consumer
13 each child node of mdio bus multiplexer consumer device represent a mdio
21 In below example the Mux producer and consumer are separate nodes.
38 mdio-mux-1 { // Mux consumer
61 mdio-mux-2 { // Mux consumer
|
| /Documentation/infiniband/ |
| D | core_locking.rst | 64 example, a consumer may safely call ib_poll_cq() on multiple CPUs
73 allowed for a low-level driver to call a consumer's completion event
87 consumer CQ event callback:
91 /* ... */ consumer CQ event callback:
110 semaphores that could cause deadlock if a consumer calls back into
113 An upper level protocol consumer may begin using an IB device as
115 device. A consumer must finish all cleanup and free all resources
118 A consumer is permitted to sleep in its add and remove methods.
|
| /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/cpufreq/ |
| D | imx-cpufreq-dt.txt | 15 0: Consumer
16 1: Extended Consumer
27 /* grade >= 0, consumer only */
|
| /Documentation/devicetree/bindings/reset/ |
| D | ti,sci-reset.txt | 21 - #reset-cells : Should be 2. Please see the reset consumer node below for
24 TI-SCI Reset Consumer Nodes
26 Each of the reset consumer nodes should have the following properties,
47 consumer (a DSP device) on the 66AK2G SoC.
|
| 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/networking/ |
| D | af_xdp.rst | 64 single-consumer / single-producer (for performance reasons), the new
116 The UMEM has two single-producer/single-consumer rings, that are used
124 TX. All rings are single-producer/single-consumer, so the user-space
133 The rings are head(producer)/tail(consumer) based rings. A producer
135 producer member, and increasing the producer index. A consumer reads
136 the data ring at the index pointed out by struct xdp_ring consumer
137 member, and increasing the consumer index.
245 // __u32 *consumer;
251 // __u32 *consumer;
263 __u32 entries = *ring->producer - *ring->consumer;
[all …]
|
| /Documentation/devicetree/bindings/interconnect/ |
| D | interconnect.txt | 13 to consumer drivers. These capabilities can be throughput, latency, priority
14 etc. The consumer drivers set constraints on interconnect path (or endpoints)
40 can be multiple interconnect providers on a SoC and the consumer may consume
|
| /Documentation/devicetree/bindings/mux/ |
| D | mux-controller.txt | 4 A multiplexer (or mux) controller will have one, or several, consumer devices
7 multiplexer needed by each consumer, but a single mux controller can of course
8 control several multiplexers for a single consumer.
29 each consumer. An optional property "mux-control-names" may contain a list of
43 /* One consumer of a 2-way mux controller (one GPIO-line) */
64 for the consumer node in fact asks for a named mux controller, that name is of
|
| /Documentation/devicetree/bindings/clock/ |
| D | ux500.txt | 15 clock in the prcmu-clock node the consumer wants to use.
18 The first cell indicates which PRCC block the consumer
24 The first cell indicates which PRCC block the consumer
|
| D | clock-bindings.txt | 5 tree. Those nodes are designated as clock providers. Clock consumer
32 Clock consumer nodes must never directly reference
43 "ckil" and the second named "ckih". Consumer nodes always reference
129 * The PLL is both a clock provider and a clock consumer. It uses the clock
166 conflicting parent or rate configuration in multiple consumer nodes for
169 Configuration of common clocks, which affect multiple consumer devices can
|
| D | maxim,max77686.txt | 59 Clock consumer node
84 Clock consumer node
107 Clock consumer node
|
| D | csr,atlas7-car.txt | 9 The clock consumer should specify the desired clock by having the clock
13 The reset consumer should specify the desired reset by having the reset
|
| /Documentation/devicetree/bindings/iio/adc/ |
| D | at91-sama5d2_adc.txt | 24 - #io-channel-cells: in case consumer drivers are attached, this must be 1.
27 Properties for consumer drivers:
28 - Consumer drivers can be connected to this producer device, as specified
|
| /Documentation/devicetree/bindings/nvmem/ |
| D | nvmem-consumer.yaml | 4 $id: http://devicetree.org/schemas/nvmem/nvmem-consumer.yaml#
7 title: NVMEM (Non Volatile Memory) Consumer Device Tree Bindings
|
| D | nvmem.txt | 1 This file has been moved to nvmem.yaml and nvmem-consumer.yaml.
|
| /Documentation/PCI/ |
| D | acpi-info.rst | 55 ACPI defines a Consumer/Producer bit to distinguish the bridge registers
56 ("Consumer") from the bridge apertures ("Producer") [4, 5], but early
58 spec defines Consumer/Producer only for the Extended Address Space
64 Consumer/Producer meant there was no way to describe bridge registers in
71 New architectures should be able to use "Consumer" Extended Address Space
74 ia64 kernels assume all address space descriptors, including "Consumer"
141 General Flags: Bit [0] Consumer/Producer:
|
12345678