1================================ 2GPIO Descriptor Driver Interface 3================================ 4 5This document serves as a guide for GPIO chip drivers writers. Note that it 6describes the new descriptor-based interface. For a description of the 7deprecated integer-based GPIO interface please refer to gpio-legacy.txt. 8 9Each GPIO controller driver needs to include the following header, which defines 10the structures used to define a GPIO driver: 11 12 #include <linux/gpio/driver.h> 13 14 15Internal Representation of GPIOs 16================================ 17 18Inside a GPIO driver, individual GPIOs are identified by their hardware number, 19which is a unique number between 0 and n, n being the number of GPIOs managed by 20the chip. This number is purely internal: the hardware number of a particular 21GPIO descriptor is never made visible outside of the driver. 22 23On top of this internal number, each GPIO also need to have a global number in 24the integer GPIO namespace so that it can be used with the legacy GPIO 25interface. Each chip must thus have a "base" number (which can be automatically 26assigned), and for each GPIO the global number will be (base + hardware number). 27Although the integer representation is considered deprecated, it still has many 28users and thus needs to be maintained. 29 30So for example one platform could use numbers 32-159 for GPIOs, with a 31controller defining 128 GPIOs at a "base" of 32 ; while another platform uses 32numbers 0..63 with one set of GPIO controllers, 64-79 with another type of GPIO 33controller, and on one particular board 80-95 with an FPGA. The numbers need not 34be contiguous; either of those platforms could also use numbers 2000-2063 to 35identify GPIOs in a bank of I2C GPIO expanders. 36 37 38Controller Drivers: gpio_chip 39============================= 40 41In the gpiolib framework each GPIO controller is packaged as a "struct 42gpio_chip" (see linux/gpio/driver.h for its complete definition) with members 43common to each controller of that type: 44 45 - methods to establish GPIO line direction 46 - methods used to access GPIO line values 47 - method to set electrical configuration for a given GPIO line 48 - method to return the IRQ number associated to a given GPIO line 49 - flag saying whether calls to its methods may sleep 50 - optional line names array to identify lines 51 - optional debugfs dump method (showing extra state like pullup config) 52 - optional base number (will be automatically assigned if omitted) 53 - optional label for diagnostics and GPIO chip mapping using platform data 54 55The code implementing a gpio_chip should support multiple instances of the 56controller, possibly using the driver model. That code will configure each 57gpio_chip and issue ``gpiochip_add[_data]()`` or ``devm_gpiochip_add_data()``. 58Removing a GPIO controller should be rare; use ``[devm_]gpiochip_remove()`` 59when it is unavoidable. 60 61Often a gpio_chip is part of an instance-specific structure with states not 62exposed by the GPIO interfaces, such as addressing, power management, and more. 63Chips such as audio codecs will have complex non-GPIO states. 64 65Any debugfs dump method should normally ignore signals which haven't been 66requested as GPIOs. They can use gpiochip_is_requested(), which returns either 67NULL or the label associated with that GPIO when it was requested. 68 69RT_FULL: the GPIO driver should not use spinlock_t or any sleepable APIs 70(like PM runtime) in its gpio_chip implementation (.get/.set and direction 71control callbacks) if it is expected to call GPIO APIs from atomic context 72on -RT (inside hard IRQ handlers and similar contexts). Normally this should 73not be required. 74 75 76GPIO electrical configuration 77----------------------------- 78 79GPIOs can be configured for several electrical modes of operation by using the 80.set_config() callback. Currently this API supports setting debouncing and 81single-ended modes (open drain/open source). These settings are described 82below. 83 84The .set_config() callback uses the same enumerators and configuration 85semantics as the generic pin control drivers. This is not a coincidence: it is 86possible to assign the .set_config() to the function gpiochip_generic_config() 87which will result in pinctrl_gpio_set_config() being called and eventually 88ending up in the pin control back-end "behind" the GPIO controller, usually 89closer to the actual pins. This way the pin controller can manage the below 90listed GPIO configurations. 91 92If a pin controller back-end is used, the GPIO controller or hardware 93description needs to provide "GPIO ranges" mapping the GPIO line offsets to pin 94numbers on the pin controller so they can properly cross-reference each other. 95 96 97GPIOs with debounce support 98--------------------------- 99 100Debouncing is a configuration set to a pin indicating that it is connected to 101a mechanical switch or button, or similar that may bounce. Bouncing means the 102line is pulled high/low quickly at very short intervals for mechanical 103reasons. This can result in the value being unstable or irqs fireing repeatedly 104unless the line is debounced. 105 106Debouncing in practice involves setting up a timer when something happens on 107the line, wait a little while and then sample the line again, so see if it 108still has the same value (low or high). This could also be repeated by a clever 109state machine, waiting for a line to become stable. In either case, it sets 110a certain number of milliseconds for debouncing, or just "on/off" if that time 111is not configurable. 112 113 114GPIOs with open drain/source support 115------------------------------------ 116 117Open drain (CMOS) or open collector (TTL) means the line is not actively driven 118high: instead you provide the drain/collector as output, so when the transistor 119is not open, it will present a high-impedance (tristate) to the external rail:: 120 121 122 CMOS CONFIGURATION TTL CONFIGURATION 123 124 ||--- out +--- out 125 in ----|| |/ 126 ||--+ in ----| 127 | |\ 128 GND GND 129 130This configuration is normally used as a way to achieve one of two things: 131 132- Level-shifting: to reach a logical level higher than that of the silicon 133 where the output resides. 134 135- inverse wire-OR on an I/O line, for example a GPIO line, making it possible 136 for any driving stage on the line to drive it low even if any other output 137 to the same line is simultaneously driving it high. A special case of this 138 is driving the SCL and SCA lines of an I2C bus, which is by definition a 139 wire-OR bus. 140 141Both usecases require that the line be equipped with a pull-up resistor. This 142resistor will make the line tend to high level unless one of the transistors on 143the rail actively pulls it down. 144 145The level on the line will go as high as the VDD on the pull-up resistor, which 146may be higher than the level supported by the transistor, achieving a 147level-shift to the higher VDD. 148 149Integrated electronics often have an output driver stage in the form of a CMOS 150"totem-pole" with one N-MOS and one P-MOS transistor where one of them drives 151the line high and one of them drives the line low. This is called a push-pull 152output. The "totem-pole" looks like so:: 153 154 VDD 155 | 156 OD ||--+ 157 +--/ ---o|| P-MOS-FET 158 | ||--+ 159 IN --+ +----- out 160 | ||--+ 161 +--/ ----|| N-MOS-FET 162 OS ||--+ 163 | 164 GND 165 166The desired output signal (e.g. coming directly from some GPIO output register) 167arrives at IN. The switches named "OD" and "OS" are normally closed, creating 168a push-pull circuit. 169 170Consider the little "switches" named "OD" and "OS" that enable/disable the 171P-MOS or N-MOS transistor right after the split of the input. As you can see, 172either transistor will go totally numb if this switch is open. The totem-pole 173is then halved and give high impedance instead of actively driving the line 174high or low respectively. That is usually how software-controlled open 175drain/source works. 176 177Some GPIO hardware come in open drain / open source configuration. Some are 178hard-wired lines that will only support open drain or open source no matter 179what: there is only one transistor there. Some are software-configurable: 180by flipping a bit in a register the output can be configured as open drain 181or open source, in practice by flicking open the switches labeled "OD" and "OS" 182in the drawing above. 183 184By disabling the P-MOS transistor, the output can be driven between GND and 185high impedance (open drain), and by disabling the N-MOS transistor, the output 186can be driven between VDD and high impedance (open source). In the first case, 187a pull-up resistor is needed on the outgoing rail to complete the circuit, and 188in the second case, a pull-down resistor is needed on the rail. 189 190Hardware that supports open drain or open source or both, can implement a 191special callback in the gpio_chip: .set_config() that takes a generic 192pinconf packed value telling whether to configure the line as open drain, 193open source or push-pull. This will happen in response to the 194GPIO_OPEN_DRAIN or GPIO_OPEN_SOURCE flag set in the machine file, or coming 195from other hardware descriptions. 196 197If this state can not be configured in hardware, i.e. if the GPIO hardware does 198not support open drain/open source in hardware, the GPIO library will instead 199use a trick: when a line is set as output, if the line is flagged as open 200drain, and the IN output value is low, it will be driven low as usual. But 201if the IN output value is set to high, it will instead *NOT* be driven high, 202instead it will be switched to input, as input mode is high impedance, thus 203achieveing an "open drain emulation" of sorts: electrically the behaviour will 204be identical, with the exception of possible hardware glitches when switching 205the mode of the line. 206 207For open source configuration the same principle is used, just that instead 208of actively driving the line low, it is set to input. 209 210 211GPIO drivers providing IRQs 212--------------------------- 213It is custom that GPIO drivers (GPIO chips) are also providing interrupts, 214most often cascaded off a parent interrupt controller, and in some special 215cases the GPIO logic is melded with a SoC's primary interrupt controller. 216 217The IRQ portions of the GPIO block are implemented using an irqchip, using 218the header <linux/irq.h>. So basically such a driver is utilizing two sub- 219systems simultaneously: gpio and irq. 220 221RT_FULL: a realtime compliant GPIO driver should not use spinlock_t or any 222sleepable APIs (like PM runtime) as part of its irq_chip implementation. 223 224* spinlock_t should be replaced with raw_spinlock_t [1]. 225* If sleepable APIs have to be used, these can be done from the .irq_bus_lock() 226 and .irq_bus_unlock() callbacks, as these are the only slowpath callbacks 227 on an irqchip. Create the callbacks if needed [2]. 228 229GPIO irqchips usually fall in one of two categories: 230 231* CHAINED GPIO irqchips: these are usually the type that is embedded on 232 an SoC. This means that there is a fast IRQ flow handler for the GPIOs that 233 gets called in a chain from the parent IRQ handler, most typically the 234 system interrupt controller. This means that the GPIO irqchip handler will 235 be called immediately from the parent irqchip, while holding the IRQs 236 disabled. The GPIO irqchip will then end up calling something like this 237 sequence in its interrupt handler:: 238 239 static irqreturn_t foo_gpio_irq(int irq, void *data) 240 chained_irq_enter(...); 241 generic_handle_irq(...); 242 chained_irq_exit(...); 243 244 Chained GPIO irqchips typically can NOT set the .can_sleep flag on 245 struct gpio_chip, as everything happens directly in the callbacks: no 246 slow bus traffic like I2C can be used. 247 248 RT_FULL: Note, chained IRQ handlers will not be forced threaded on -RT. 249 As result, spinlock_t or any sleepable APIs (like PM runtime) can't be used 250 in chained IRQ handler. 251 If required (and if it can't be converted to the nested threaded GPIO irqchip) 252 a chained IRQ handler can be converted to generic irq handler and this way 253 it will be a threaded IRQ handler on -RT and a hard IRQ handler on non-RT 254 (for example, see [3]). 255 Know W/A: The generic_handle_irq() is expected to be called with IRQ disabled, 256 so the IRQ core will complain if it is called from an IRQ handler which is 257 forced to a thread. The "fake?" raw lock can be used to W/A this problem:: 258 259 raw_spinlock_t wa_lock; 260 static irqreturn_t omap_gpio_irq_handler(int irq, void *gpiobank) 261 unsigned long wa_lock_flags; 262 raw_spin_lock_irqsave(&bank->wa_lock, wa_lock_flags); 263 generic_handle_irq(irq_find_mapping(bank->chip.irq.domain, bit)); 264 raw_spin_unlock_irqrestore(&bank->wa_lock, wa_lock_flags); 265 266* GENERIC CHAINED GPIO irqchips: these are the same as "CHAINED GPIO irqchips", 267 but chained IRQ handlers are not used. Instead GPIO IRQs dispatching is 268 performed by generic IRQ handler which is configured using request_irq(). 269 The GPIO irqchip will then end up calling something like this sequence in 270 its interrupt handler:: 271 272 static irqreturn_t gpio_rcar_irq_handler(int irq, void *dev_id) 273 for each detected GPIO IRQ 274 generic_handle_irq(...); 275 276 RT_FULL: Such kind of handlers will be forced threaded on -RT, as result IRQ 277 core will complain that generic_handle_irq() is called with IRQ enabled and 278 the same W/A as for "CHAINED GPIO irqchips" can be applied. 279 280* NESTED THREADED GPIO irqchips: these are off-chip GPIO expanders and any 281 other GPIO irqchip residing on the other side of a sleeping bus. Of course 282 such drivers that need slow bus traffic to read out IRQ status and similar, 283 traffic which may in turn incur other IRQs to happen, cannot be handled 284 in a quick IRQ handler with IRQs disabled. Instead they need to spawn a 285 thread and then mask the parent IRQ line until the interrupt is handled 286 by the driver. The hallmark of this driver is to call something like 287 this in its interrupt handler:: 288 289 static irqreturn_t foo_gpio_irq(int irq, void *data) 290 ... 291 handle_nested_irq(irq); 292 293 The hallmark of threaded GPIO irqchips is that they set the .can_sleep 294 flag on struct gpio_chip to true, indicating that this chip may sleep 295 when accessing the GPIOs. 296 297To help out in handling the set-up and management of GPIO irqchips and the 298associated irqdomain and resource allocation callbacks, the gpiolib has 299some helpers that can be enabled by selecting the GPIOLIB_IRQCHIP Kconfig 300symbol: 301 302* gpiochip_irqchip_add(): adds a chained irqchip to a gpiochip. It will pass 303 the struct gpio_chip* for the chip to all IRQ callbacks, so the callbacks 304 need to embed the gpio_chip in its state container and obtain a pointer 305 to the container using container_of(). 306 (See Documentation/driver-model/design-patterns.txt) 307 308* gpiochip_irqchip_add_nested(): adds a nested irqchip to a gpiochip. 309 Apart from that it works exactly like the chained irqchip. 310 311* gpiochip_set_chained_irqchip(): sets up a chained irq handler for a 312 gpio_chip from a parent IRQ and passes the struct gpio_chip* as handler 313 data. (Notice handler data, since the irqchip data is likely used by the 314 parent irqchip!). 315 316* gpiochip_set_nested_irqchip(): sets up a nested irq handler for a 317 gpio_chip from a parent IRQ. As the parent IRQ has usually been 318 explicitly requested by the driver, this does very little more than 319 mark all the child IRQs as having the other IRQ as parent. 320 321If there is a need to exclude certain GPIOs from the IRQ domain, you can 322set .irq.need_valid_mask of the gpiochip before gpiochip_add_data() is 323called. This allocates an .irq.valid_mask with as many bits set as there 324are GPIOs in the chip. Drivers can exclude GPIOs by clearing bits from this 325mask. The mask must be filled in before gpiochip_irqchip_add() or 326gpiochip_irqchip_add_nested() is called. 327 328To use the helpers please keep the following in mind: 329 330- Make sure to assign all relevant members of the struct gpio_chip so that 331 the irqchip can initialize. E.g. .dev and .can_sleep shall be set up 332 properly. 333 334- Nominally set all handlers to handle_bad_irq() in the setup call and pass 335 handle_bad_irq() as flow handler parameter in gpiochip_irqchip_add() if it is 336 expected for GPIO driver that irqchip .set_type() callback have to be called 337 before using/enabling GPIO IRQ. Then set the handler to handle_level_irq() 338 and/or handle_edge_irq() in the irqchip .set_type() callback depending on 339 what your controller supports. 340 341It is legal for any IRQ consumer to request an IRQ from any irqchip no matter 342if that is a combined GPIO+IRQ driver. The basic premise is that gpio_chip and 343irq_chip are orthogonal, and offering their services independent of each 344other. 345 346gpiod_to_irq() is just a convenience function to figure out the IRQ for a 347certain GPIO line and should not be relied upon to have been called before 348the IRQ is used. 349 350So always prepare the hardware and make it ready for action in respective 351callbacks from the GPIO and irqchip APIs. Do not rely on gpiod_to_irq() having 352been called first. 353 354This orthogonality leads to ambiguities that we need to solve: if there is 355competition inside the subsystem which side is using the resource (a certain 356GPIO line and register for example) it needs to deny certain operations and 357keep track of usage inside of the gpiolib subsystem. This is why the API 358below exists. 359 360 361Locking IRQ usage 362----------------- 363Input GPIOs can be used as IRQ signals. When this happens, a driver is requested 364to mark the GPIO as being used as an IRQ:: 365 366 int gpiochip_lock_as_irq(struct gpio_chip *chip, unsigned int offset) 367 368This will prevent the use of non-irq related GPIO APIs until the GPIO IRQ lock 369is released:: 370 371 void gpiochip_unlock_as_irq(struct gpio_chip *chip, unsigned int offset) 372 373When implementing an irqchip inside a GPIO driver, these two functions should 374typically be called in the .startup() and .shutdown() callbacks from the 375irqchip. 376 377When using the gpiolib irqchip helpers, these callback are automatically 378assigned. 379 380Real-Time compliance for GPIO IRQ chips 381--------------------------------------- 382 383Any provider of irqchips needs to be carefully tailored to support Real Time 384preemption. It is desirable that all irqchips in the GPIO subsystem keep this 385in mind and do the proper testing to assure they are real time-enabled. 386So, pay attention on above " RT_FULL:" notes, please. 387The following is a checklist to follow when preparing a driver for real 388time-compliance: 389 390- ensure spinlock_t is not used as part irq_chip implementation; 391- ensure that sleepable APIs are not used as part irq_chip implementation. 392 If sleepable APIs have to be used, these can be done from the .irq_bus_lock() 393 and .irq_bus_unlock() callbacks; 394- Chained GPIO irqchips: ensure spinlock_t or any sleepable APIs are not used 395 from chained IRQ handler; 396- Generic chained GPIO irqchips: take care about generic_handle_irq() calls and 397 apply corresponding W/A; 398- Chained GPIO irqchips: get rid of chained IRQ handler and use generic irq 399 handler if possible :) 400- regmap_mmio: Sry, but you are in trouble :( if MMIO regmap is used as for 401 GPIO IRQ chip implementation; 402- Test your driver with the appropriate in-kernel real time test cases for both 403 level and edge IRQs. 404 405 406Requesting self-owned GPIO pins 407------------------------------- 408 409Sometimes it is useful to allow a GPIO chip driver to request its own GPIO 410descriptors through the gpiolib API. Using gpio_request() for this purpose 411does not help since it pins the module to the kernel forever (it calls 412try_module_get()). A GPIO driver can use the following functions instead 413to request and free descriptors without being pinned to the kernel forever:: 414 415 struct gpio_desc *gpiochip_request_own_desc(struct gpio_desc *desc, 416 const char *label) 417 418 void gpiochip_free_own_desc(struct gpio_desc *desc) 419 420Descriptors requested with gpiochip_request_own_desc() must be released with 421gpiochip_free_own_desc(). 422 423These functions must be used with care since they do not affect module use 424count. Do not use the functions to request gpio descriptors not owned by the 425calling driver. 426 427* [1] http://www.spinics.net/lists/linux-omap/msg120425.html 428* [2] https://lkml.org/lkml/2015/9/25/494 429* [3] https://lkml.org/lkml/2015/9/25/495 430