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