Lines Matching +full:line +full:- +full:based
21 - Simple compile coverage with e.g. COMPILE_TEST - it does not matter that
25 - Truly optional GPIOLIB support - where the driver does not really make use
26 of the GPIOs on certain compile-time configurations for certain systems, but
27 will use it under other compile-time configurations. In this case the
35 All the functions that work with the descriptor-based GPIO interface are
45 With the descriptor-based interface, GPIOs are identified with an opaque,
46 non-forgeable handler that must be obtained through a call to one of the
62 see Documentation/driver-api/gpio/board.rst
72 * GPIOD_OUT_LOW_OPEN_DRAIN same as GPIOD_OUT_LOW but also enforce the line
74 * GPIOD_OUT_HIGH_OPEN_DRAIN same as GPIOD_OUT_HIGH but also enforce the line
77 Note that the initial value is *logical* and the physical line level depends on
78 whether the line is configured active high or active low (see
82 as I2C: if the line is not already configured as open drain in the mappings
87 with IS_ERR() (they will never return a NULL pointer). -ENOENT will be returned
94 instead of -ENOENT if no GPIO has been assigned to the requested function::
108 -ENOSYS return codes. System integrators should however be careful to enable
127 The following function returns NULL instead of -ENOENT if no GPIOs have been
134 Device-managed variants of these functions are also defined::
173 The device-managed variants are, unsurprisingly::
184 -----------------
186 direction-setting flags have been given to gpiod_get*(), this is done by
195 for spinlock-safe GPIOs it is OK to use them before tasking is enabled, as part
212 Spinlock-Safe GPIO Access
213 -------------------------
215 don't need to sleep, and can safely be done from inside hard (non-threaded) IRQ
226 open-drain signaling and output latencies.
236 --------------------------
237 Some GPIO controllers must be accessed using message based buses like I2C or
253 IRQ handler, and those accessors must be used instead of spinlock-safe
258 spinlock-safe calls.
264 ---------------------------------------
265 As a consumer should not have to care about the physical line level, all of the
269 and if so, they manipulate the passed value before the physical line level is
278 parameter "value" as "active" ("1") or "inactive" ("0"). The physical line
282 gpiod_set_(array)_value_xxx() passes "active" ("1"), the physical line level
287 Function (example) line property physical line
300 but it should be avoided as much as possible, especially by system-agnostic drivers
301 which should not need to care about the actual physical line level and worry about
306 -------------------------
307 Consumers exist that need to manage the logical state of a GPIO line, i.e. the value
309 line.
311 The following set of calls ignore the active-low or open drain property of a GPIO and
312 work on the raw line value::
327 should not have to care about the physical line level or open drain semantics.
331 -------------------------------------------------
376 * array_size - the number of array elements
377 * desc_array - an array of GPIO descriptors
378 * array_info - optional information obtained from gpiod_get_array()
379 * value_bitmap - a bitmap to store the GPIOs' values (get) or
388 gpiod_set_array_value(my_gpio_descs->ndescs, my_gpio_descs->desc,
389 my_gpio_descs->info, my_gpio_value_bitmap);
415 --------------------
427 Non-error values returned from gpiod_to_irq() can be passed to request_irq() or
429 by the board-specific initialization code. Note that IRQ trigger options are
449 For details refer to Documentation/firmware-guide/acpi/gpio-properties.rst
455 integer-based interface. It is strongly recommended to update these to the new
458 and vice-versa::