Lines Matching refs:GPIO
99 also consider matching of offsets to the GPIO ranges that may be handled by
278 Interaction with the GPIO subsystem
281 The GPIO drivers may want to perform operations of various types on the same
291 which pin controller handles control of a certain GPIO pin. Since a single
292 pin controller may be muxing several GPIO ranges (typically SoCs that have
293 one set of pins, but internally several GPIO silicon blocks, each modelled as
294 a struct gpio_chip) any number of GPIO ranges can be added to a pin controller
326 GPIO chips. "chip a" has 16 pins and "chip b" has 8 pins. The "chip a" and
328 GPIO range.
330 The GPIO range of "chip a" starts from the GPIO base of 32 and actual
332 offset for the GPIO range and pin range. The GPIO range of "chip b" starts
333 from GPIO number 48, while the pin range of "chip b" starts from 64.
336 They are mapped in the global GPIO pin space at:
339 - GPIO range : [32 .. 47]
342 - GPIO range : [48 .. 55]
367 When GPIO-specific functions in the pin control subsystem are called, these
370 pin controller handling the matching range is found, GPIO-specific functions
438 some general-purpose GPIO pin. However, in another setting, pins { A5, B5 } can
455 Since general-purpose I/O pins (GPIO) are typically always in shortage, it is
456 common to be able to use almost any pin as a GPIO pin if it is not currently
465 in your machine configuration. It is inspired by the clk, GPIO and regulator
467 to request a single pin for e.g. GPIO.
537 other device mux setting or GPIO pin request has already taken your physical
734 sure no other device or GPIO assignment is already using the selected
741 Pin control interaction with the GPIO subsystem
747 that your datasheet calls "GPIO mode", but actually is just an electrical
749 "GPIO mode pitfalls" for more details on this scenario.
758 NOTE that platforms and individual drivers shall *NOT* request GPIO pins to be
763 individual pin into a GPIO pin independent of any other pins, and then try
766 In this case, the function array would become 64 entries for each GPIO
770 to enable only GPIO on an individual pin: .gpio_request_enable() and
773 This function will pass in the affected GPIO range identified by the pin
774 controller core, so you know which GPIO pins are being affected by the request
778 GPIO pin shall be used for input or output you can implement the
780 gpiolib driver and the affected GPIO range, pin offset and desired direction
784 named functions for each GPIO pin, the pinctrl_request_gpio() will attempt to
785 obtain the function "gpioN" where "N" is the global GPIO pin number if no
786 special GPIO-handler is registered.
789 GPIO mode pitfalls
792 Due to the naming conventions used by hardware engineers, where "GPIO"
795 into "GPIO mode". It appears that what hardware engineers mean with
796 "GPIO mode" is not necessarily the use case that is implied in the kernel
801 Rather hardware engineers think that "GPIO mode" means that you can
806 The GPIO portions of a pin and its relation to a certain pin controller
816 | +- GPIO
822 whether the pin is used for GPIO or not. If you multiplex a GPIO onto a
823 pin, you can also drive it high/low from "GPIO" registers.
825 still applying desired pin config properties. GPIO functionality is thus
828 In this arrangement the registers for the GPIO portions of the pin controller,
829 or the registers for the GPIO hardware module are likely to reside in a
830 separate memory range only intended for GPIO driving, and the register
835 simultaneous access to the same pin from GPIO and pin multiplexing
847 GPIO pin
851 In this arrangement, the GPIO functionality can always be enabled, such that
852 e.g. a GPIO input can be used to "spy" on the SPI/I2C/MMC signal while it is
854 wrong things on the GPIO block, as it is never really disconnected. It is
855 possible that the GPIO, pin config and pin multiplex registers are placed into
860 way as (B), the GPIO function still can't be enabled at the same time as the
862 simultaneous activation by GPIO and other muxed in devices.
872 from various other HW blocks (e.g. I2C, MMC, or GPIO) onto pins should
875 - Registers (or fields within registers) that control GPIO functionality
876 such as setting a GPIO's output value, reading a GPIO's input value, or
877 setting GPIO pin direction should be exposed through the GPIO subsystem,
882 GPIO subsystem may call into the pinctrl subsystem in order to
884 be needed for HW with separate GPIO and pin controller HW modules, where
885 e.g. GPIO direction is determined by a register in the pin controller HW
886 module rather than the GPIO HW module.
890 of the GPIO register in case (B) especially. This doesn't mean that such
891 properties necessarily pertain to what the Linux kernel calls "GPIO".
894 system sleep, we need to put this pin into "GPIO mode" and ground it.
896 If you make a 1-to-1 map to the GPIO subsystem for this pin, you may start
898 pin shall be used for UART TX and GPIO at the same time, that you will grab
900 muxed in, then twist it over to GPIO mode and use gpio_direction_output()
905 The solution is to not think that what the datasheet calls "GPIO mode"
913 So it is perfectly possible to push a pin into "GPIO mode" and drive the
961 GPIO mode.
964 GPIO subsystem. It is just an electrical configuration used by that device
966 datasheet calls "GPIO mode", but that is not the point: it is still used
968 driver, putting them into modes needed by the UART. GPIO in the Linux
975 Some datasheets will be more helpful and refer to the "GPIO mode" as
976 "low power mode" rather than anything to do with GPIO. This often means
979 specific muxing or configuration rather than anything related to the GPIO
1309 Here we first request a certain pin state and then request GPIO 14 to be
1312 state BEFORE requesting the GPIO. This is a semantic convention to avoid
1314 mux in and bias pins in a certain way before the GPIO subsystems starts to
1319 probing, nevertheless orthogonal to the GPIO subsystem.
1321 But there are also situations where it makes sense for the GPIO subsystem
1323 back-end. This is when the GPIO driver may call out to the functions
1324 described in the section "Pin control interaction with the GPIO subsystem"
1329 If a pin control driver and a GPIO driver is dealing with the same pins
1331 as a back-end for the GPIO driver like this, unless your hardware design
1332 is such that the GPIO controller can override the pin controller's