Lines Matching full:that
7 These calls use the gpio_* naming prefix. No other calls should use that
18 which GPIOs. Drivers can be written generically, so that board setup code
26 also "GPIO Expander" chips that connect using the I2C or SPI serial busses.
33 options about how that value is driven, so that for example only one
60 Note that this is called a "convention" because you don't need to do it this
63 glue logic that may even change between board revisions, and can't ever be
64 used on a board that's wired differently. Only least-common-denominator
66 and that can be critical for glue logic.
76 That said, if the convention is supported on their platform, drivers should
78 is strictly required. Drivers that can't work without
88 Note that these operations include I/O barriers on platforms which need to
94 GPIOs are identified by unsigned integers in the range 0..MAX_INT. That
96 "not available on this board", or indicating faults. Code that doesn't
100 for the GPIO lines so that board-specific setup code directly corresponds
102 numbers passed to them from that setup code, using platform_data to hold
104 data they need). That avoids portability problems.
113 some negative number (perhaps "-EINVAL"); that will never be valid. To
119 A number that's not valid will be rejected by calls which may request
124 implementation issue, as are whether that support can leave "holes" in the space
150 of a GPIO implicitly requests that GPIO (see below) if it has not been
151 requested already. That compatibility is being removed from the optional
155 that particular GPIO can't be used in that mode. It's generally a bad
158 that board setup code probably needs to multiplex that pin as a GPIO,
179 pin ... that won't always match the specified output value, because of
183 been reported earlier from gpio_direction_*(). However, note that not all
184 platforms can read the value of output pins; those that can't should always
185 return zero. Also, using these calls for GPIOs that can't safely be accessed
197 GPIO access that may sleep
204 Platforms that support this type of GPIO distinguish them from other GPIOs
223 Other than the fact that these accessors might sleep, and will work
224 on GPIOs that can't be accessed from hardIRQ handlers, these calls act
258 GPIOs that have already been claimed with that call. The return value of
267 (a) two or more drivers wrongly think they have exclusive use of that
269 needed to manage a signal that's in active use. That is, requesting a
276 For GPIOs that use pins known to the pinctrl subsystem, that subsystem should
283 Any programming of pin multiplexing hardware that is needed to route the
292 pullup/pulldown. Platform software should arrange that any such details are
294 the pinctrl subsystem's mapping table, so that GPIO users need not be aware
297 Also note that it's your responsibility to have stopped using a GPIO
337 When setting the flag as GPIOF_OPEN_DRAIN then it will assume that pins is
343 When setting the flag as GPIOF_OPEN_SOURCE then it will assume that pins is
396 number that wasn't set up as an input using gpio_direction_input(), or
397 to use an IRQ number that didn't originally come from gpio_to_irq().
404 devices, by the board-specific initialization code. Note that IRQ trigger
410 when the IRQ is edge-triggered. Note that some platforms don't support
417 low signal level is actually driven. (That term applies to CMOS transistors;
427 there's a common idiom you can use to emulate it with any GPIO pin that can
438 is driving the shared signal low. That's not necessarily an error. As one
439 common example, that's how I2C clocks are stretched: a slave that needs a
448 subsystem, in the sense that the pins can be used by other functions
468 that different pin ranges in a SoC is managed by different gpio drivers.
493 come from systems that run Linux today.)
498 pullups (or pulldowns) so that the on-chip ones should not be used.
504 There are other system-specific mechanisms that are not specified here,
506 Hardware may support reading or writing GPIOs in gangs, but that's usually
524 will be found there. That will list all the controllers registered through
531 with information common to each controller of that type:
543 controller, possibly using the driver model. That code will configure each
553 either NULL or the label associated with that GPIO when it was requested.
561 It may also provide a custom value for ARCH_NR_GPIOS, so that it better
562 reflects the number of GPIOs in actual use on that platform, without
596 registering controller devices and ensures that their drivers know what GPIO
601 of GPIOs that chip will expose, and passes them to each GPIO expander chip
602 using platform_data. Then the chip driver's probe() routine could pass that
606 an I2C-based GPIO, its probe() routine should only be called after that GPIO
607 becomes available. That may mean the device should not be registered until
608 calls for that GPIO can work. One way to address such dependencies is for
624 know for example that GPIO #23 controls the write protect line used to
626 may need to temporarily remove that protection, first importing a GPIO,
632 userspace GPIO can be used to determine system configuration data that
634 GPIO drivers could be all that the system really needs.
636 Note that standard kernel drivers exist for common "LEDs and Buttons"
652 That's in addition to standard files including the "device" symlink.
662 for GPIO #19, if that's not requested by kernel code.
678 configure the GPIO as an output with that initial value.
680 Note that this attribute *will not exist* if the kernel
682 it was exported by kernel code that didn't explicitly
691 description of "edge"), you can poll(2) on that file and
700 that will make poll(2) on the "value" file return.
753 of experiments easier), or can provide an always-there interface that's