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
733 sure no other device or GPIO assignment is already using the selected
740 Pin control interaction with the GPIO subsystem
746 that your datasheet calls "GPIO mode", but actually is just an electrical
748 "GPIO mode pitfalls" for more details on this scenario.
757 NOTE that platforms and individual drivers shall *NOT* request GPIO pins to be
762 individual pin into a GPIO pin independent of any other pins, and then try
765 In this case, the function array would become 64 entries for each GPIO
769 to enable only GPIO on an individual pin: .gpio_request_enable() and
772 This function will pass in the affected GPIO range identified by the pin
773 controller core, so you know which GPIO pins are being affected by the request
777 GPIO pin shall be used for input or output you can implement the
779 gpiolib driver and the affected GPIO range, pin offset and desired direction
783 named functions for each GPIO pin, the pinctrl_request_gpio() will attempt to
784 obtain the function "gpioN" where "N" is the global GPIO pin number if no
785 special GPIO-handler is registered.
788 GPIO mode pitfalls
791 Due to the naming conventions used by hardware engineers, where "GPIO"
794 into "GPIO mode". It appears that what hardware engineers mean with
795 "GPIO mode" is not necessarily the use case that is implied in the kernel
800 Rather hardware engineers think that "GPIO mode" means that you can
805 The GPIO portions of a pin and its relation to a certain pin controller
815 | +- GPIO
821 whether the pin is used for GPIO or not. If you multiplex a GPIO onto a
822 pin, you can also drive it high/low from "GPIO" registers.
824 still applying desired pin config properties. GPIO functionality is thus
827 In this arrangement the registers for the GPIO portions of the pin controller,
828 or the registers for the GPIO hardware module are likely to reside in a
829 separate memory range only intended for GPIO driving, and the register
841 GPIO pin
845 In this arrangement, the GPIO functionality can always be enabled, such that
846 e.g. a GPIO input can be used to "spy" on the SPI/I2C/MMC signal while it is
848 wrong things on the GPIO block, as it is never really disconnected. It is
849 possible that the GPIO, pin config and pin multiplex registers are placed into
861 from various other HW blocks (e.g. I2C, MMC, or GPIO) onto pins should
864 - Registers (or fields within registers) that control GPIO functionality
865 such as setting a GPIO's output value, reading a GPIO's input value, or
866 setting GPIO pin direction should be exposed through the GPIO subsystem,
871 GPIO subsystem may call into the pinctrl subsystem in order to
873 be needed for HW with separate GPIO and pin controller HW modules, where
874 e.g. GPIO direction is determined by a register in the pin controller HW
875 module rather than the GPIO HW module.
879 of the GPIO register in case (B) especially. This doesn't mean that such
880 properties necessarily pertain to what the Linux kernel calls "GPIO".
883 system sleep, we need to put this pin into "GPIO mode" and ground it.
885 If you make a 1-to-1 map to the GPIO subsystem for this pin, you may start
887 pin shall be used for UART TX and GPIO at the same time, that you will grab
889 muxed in, then twist it over to GPIO mode and use gpio_direction_output()
894 The solution is to not think that what the datasheet calls "GPIO mode"
902 So it is perfectly possible to push a pin into "GPIO mode" and drive the
950 GPIO mode.
953 GPIO subsystem. It is just an electrical configuration used by that device
955 datasheet calls "GPIO mode", but that is not the point: it is still used
957 driver, putting them into modes needed by the UART. GPIO in the Linux
964 Some datasheets will be more helpful and refer to the "GPIO mode" as
965 "low power mode" rather than anything to do with GPIO. This often means
968 specific muxing or configuration rather than anything related to the GPIO
1298 Here we first request a certain pin state and then request GPIO 14 to be
1301 state BEFORE requesting the GPIO. This is a semantic convention to avoid
1303 mux in and bias pins in a certain way before the GPIO subsystems starts to
1308 probing, nevertheless orthogonal to the GPIO subsystem.
1310 But there are also situations where it makes sense for the GPIO subsystem
1312 back-end. This is when the GPIO driver may call out to the functions
1313 described in the section "Pin control interaction with the GPIO subsystem"
1318 If a pin control driver and a GPIO driver is dealing with the same pins
1320 as a back-end for the GPIO driver like this, unless your hardware design
1321 is such that the GPIO controller can override the pin controller's