diff options
Diffstat (limited to 'Documentation/gpio/driver.txt')
| -rw-r--r-- | Documentation/gpio/driver.txt | 126 |
1 files changed, 87 insertions, 39 deletions
diff --git a/Documentation/gpio/driver.txt b/Documentation/gpio/driver.txt index 368d5a294d89..fc1d2f83564d 100644 --- a/Documentation/gpio/driver.txt +++ b/Documentation/gpio/driver.txt @@ -41,34 +41,71 @@ In the gpiolib framework each GPIO controller is packaged as a "struct gpio_chip" (see linux/gpio/driver.h for its complete definition) with members common to each controller of that type: - - methods to establish GPIO direction - - methods used to access GPIO values - - method to return the IRQ number associated to a given GPIO + - methods to establish GPIO line direction + - methods used to access GPIO line values + - method to set electrical configuration to a a given GPIO line + - method to return the IRQ number associated to a given GPIO line - flag saying whether calls to its methods may sleep + - optional line names array to identify lines - optional debugfs dump method (showing extra state like pullup config) - optional base number (will be automatically assigned if omitted) - - label for diagnostics and GPIOs mapping using platform data + - optional label for diagnostics and GPIO chip mapping using platform data The code implementing a gpio_chip should support multiple instances of the controller, possibly using the driver model. That code will configure each -gpio_chip and issue gpiochip_add(). Removing a GPIO controller should be rare; -use gpiochip_remove() when it is unavoidable. +gpio_chip and issue gpiochip_add[_data]() or devm_gpiochip_add_data(). +Removing a GPIO controller should be rare; use [devm_]gpiochip_remove() when +it is unavoidable. -Most often a gpio_chip is part of an instance-specific structure with state not +Often a gpio_chip is part of an instance-specific structure with states not exposed by the GPIO interfaces, such as addressing, power management, and more. -Chips such as codecs will have complex non-GPIO state. +Chips such as audio codecs will have complex non-GPIO states. Any debugfs dump method should normally ignore signals which haven't been requested as GPIOs. They can use gpiochip_is_requested(), which returns either NULL or the label associated with that GPIO when it was requested. -RT_FULL: GPIO driver should not use spinlock_t or any sleepable APIs +RT_FULL: the GPIO driver should not use spinlock_t or any sleepable APIs (like PM runtime) in its gpio_chip implementation (.get/.set and direction control callbacks) if it is expected to call GPIO APIs from atomic context on -RT (inside hard IRQ handlers and similar contexts). Normally this should not be required. +GPIO electrical configuration +----------------------------- + +GPIOs can be configured for several electrical modes of operation by using the +.set_config() callback. Currently this API supports setting debouncing and +single-ended modes (open drain/open source). These settings are described +below. + +The .set_config() callback uses the same enumerators and configuration +semantics as the generic pin control drivers. This is not a coincidence: it is +possible to assign the .set_config() to the function gpiochip_generic_config() +which will result in pinctrl_gpio_set_config() being called and eventually +ending up in the pin control back-end "behind" the GPIO controller, usually +closer to the actual pins. This way the pin controller can manage the below +listed GPIO configurations. + + +GPIOs with debounce support +--------------------------- + +Debouncing is a configuration set to a pin indicating that it is connected to +a mechanical switch or button, or similar that may bounce. Bouncing means the +line is pulled high/low quickly at very short intervals for mechanical +reasons. This can result in the value being unstable or irqs fireing repeatedly +unless the line is debounced. + +Debouncing in practice involves setting up a timer when something happens on +the line, wait a little while and then sample the line again, so see if it +still has the same value (low or high). This could also be repeated by a clever +state machine, waiting for a line to become stable. In either case, it sets +a certain number of milliseconds for debouncing, or just "on/off" if that time +is not configurable. + + GPIOs with open drain/source support ------------------------------------ @@ -146,10 +183,11 @@ a pull-up resistor is needed on the outgoing rail to complete the circuit, and in the second case, a pull-down resistor is needed on the rail. Hardware that supports open drain or open source or both, can implement a -special callback in the gpio_chip: .set_single_ended() that takes an enum flag -telling whether to configure the line as open drain, open source or push-pull. -This will happen in response to the GPIO_OPEN_DRAIN or GPIO_OPEN_SOURCE flag -set in the machine file, or coming from other hardware descriptions. +special callback in the gpio_chip: .set_config() that takes a generic +pinconf packed value telling whether to configure the line as open drain, +open source or push-pull. This will happen in response to the +GPIO_OPEN_DRAIN or GPIO_OPEN_SOURCE flag set in the machine file, or coming +from other hardware descriptions. If this state can not be configured in hardware, i.e. if the GPIO hardware does not support open drain/open source in hardware, the GPIO library will instead @@ -175,8 +213,8 @@ The IRQ portions of the GPIO block are implemented using an irqchip, using the header <linux/irq.h>. So basically such a driver is utilizing two sub- systems simultaneously: gpio and irq. -RT_FULL: GPIO driver should not use spinlock_t or any sleepable APIs -(like PM runtime) as part of its irq_chip implementation on -RT. +RT_FULL: a realtime compliant GPIO driver should not use spinlock_t or any +sleepable APIs (like PM runtime) as part of its irq_chip implementation. - spinlock_t should be replaced with raw_spinlock_t [1]. - If sleepable APIs have to be used, these can be done from the .irq_bus_lock() and .irq_bus_unlock() callbacks, as these are the only slowpath callbacks @@ -185,33 +223,32 @@ RT_FULL: GPIO driver should not use spinlock_t or any sleepable APIs GPIO irqchips usually fall in one of two categories: * CHAINED GPIO irqchips: these are usually the type that is embedded on - an SoC. This means that there is a fast IRQ handler for the GPIOs that + an SoC. This means that there is a fast IRQ flow handler for the GPIOs that gets called in a chain from the parent IRQ handler, most typically the - system interrupt controller. This means the GPIO irqchip is registered - using irq_set_chained_handler() or the corresponding - gpiochip_set_chained_irqchip() helper function, and the GPIO irqchip - handler will be called immediately from the parent irqchip, while - holding the IRQs disabled. The GPIO irqchip will then end up calling - something like this sequence in its interrupt handler: - - static irqreturn_t tc3589x_gpio_irq(int irq, void *data) + system interrupt controller. This means that the GPIO irqchip handler will + be called immediately from the parent irqchip, while holding the IRQs + disabled. The GPIO irqchip will then end up calling something like this + sequence in its interrupt handler: + + static irqreturn_t foo_gpio_irq(int irq, void *data) chained_irq_enter(...); generic_handle_irq(...); chained_irq_exit(...); Chained GPIO irqchips typically can NOT set the .can_sleep flag on - struct gpio_chip, as everything happens directly in the callbacks. + struct gpio_chip, as everything happens directly in the callbacks: no + slow bus traffic like I2C can be used. RT_FULL: Note, chained IRQ handlers will not be forced threaded on -RT. As result, spinlock_t or any sleepable APIs (like PM runtime) can't be used in chained IRQ handler. - if required (and if it can't be converted to the nested threaded GPIO irqchip) - - chained IRQ handler can be converted to generic irq handler and this way - it will be threaded IRQ handler on -RT and hard IRQ handler on non-RT + If required (and if it can't be converted to the nested threaded GPIO irqchip) + a chained IRQ handler can be converted to generic irq handler and this way + it will be a threaded IRQ handler on -RT and a hard IRQ handler on non-RT (for example, see [3]). Know W/A: The generic_handle_irq() is expected to be called with IRQ disabled, - so IRQ core will complain if it will be called from IRQ handler which is - forced thread. The "fake?" raw lock can be used to W/A this problem: + so the IRQ core will complain if it is called from an IRQ handler which is + forced to a thread. The "fake?" raw lock can be used to W/A this problem: raw_spinlock_t wa_lock; static irqreturn_t omap_gpio_irq_handler(int irq, void *gpiobank) @@ -243,7 +280,7 @@ GPIO irqchips usually fall in one of two categories: by the driver. The hallmark of this driver is to call something like this in its interrupt handler: - static irqreturn_t tc3589x_gpio_irq(int irq, void *data) + static irqreturn_t foo_gpio_irq(int irq, void *data) ... handle_nested_irq(irq); @@ -256,23 +293,31 @@ associated irqdomain and resource allocation callbacks, the gpiolib has some helpers that can be enabled by selecting the GPIOLIB_IRQCHIP Kconfig symbol: -* gpiochip_irqchip_add(): adds an irqchip to a gpiochip. It will pass +* gpiochip_irqchip_add(): adds a chained irqchip to a gpiochip. It will pass the struct gpio_chip* for the chip to all IRQ callbacks, so the callbacks need to embed the gpio_chip in its state container and obtain a pointer to the container using container_of(). (See Documentation/driver-model/design-patterns.txt) - If there is a need to exclude certain GPIOs from the IRQ domain, one can - set .irq_need_valid_mask of the gpiochip before gpiochip_add_data() is - called. This allocates .irq_valid_mask with as many bits set as there are - GPIOs in the chip. Drivers can exclude GPIOs by clearing bits from this - mask. The mask must be filled in before gpiochip_irqchip_add() is called. +* gpiochip_irqchip_add_nested(): adds a nested irqchip to a gpiochip. + Apart from that it works exactly like the chained irqchip. * gpiochip_set_chained_irqchip(): sets up a chained irq handler for a gpio_chip from a parent IRQ and passes the struct gpio_chip* as handler data. (Notice handler data, since the irqchip data is likely used by the - parent irqchip!) This is for the chained type of chip. This is also used - to set up a nested irqchip if NULL is passed as handler. + parent irqchip!). + +* gpiochip_set_nested_irqchip(): sets up a nested irq handler for a + gpio_chip from a parent IRQ. As the parent IRQ has usually been + explicitly requested by the driver, this does very little more than + mark all the child IRQs as having the other IRQ as parent. + +If there is a need to exclude certain GPIOs from the IRQ domain, you can +set .irq_need_valid_mask of the gpiochip before gpiochip_add_data() is +called. This allocates an .irq_valid_mask with as many bits set as there +are GPIOs in the chip. Drivers can exclude GPIOs by clearing bits from this +mask. The mask must be filled in before gpiochip_irqchip_add() or +gpiochip_irqchip_add_nested() is called. To use the helpers please keep the following in mind: @@ -323,6 +368,9 @@ When implementing an irqchip inside a GPIO driver, these two functions should typically be called in the .startup() and .shutdown() callbacks from the irqchip. +When using the gpiolib irqchip helpers, these callback are automatically +assigned. + Real-Time compliance for GPIO IRQ chips --------------------------------------- |