Alexandre Courbot | fd8e198 | 2013-11-16 21:34:21 +0900 | [diff] [blame] | 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 | |
Grygorii Strashko | c307b00 | 2015-10-20 17:22:15 +0300 | [diff] [blame] | 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. |
Linus Walleij | 99adc05 | 2014-01-22 15:00:55 +0100 | [diff] [blame] | 70 | |
Linus Walleij | 6b5029d | 2016-04-05 16:49:57 +0200 | [diff] [blame] | 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 | |
Linus Walleij | 451938d5 | 2016-04-27 10:23:44 +0200 | [diff] [blame] | 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 | |
Linus Walleij | 6b5029d | 2016-04-05 16:49:57 +0200 | [diff] [blame] | 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 | | ||--+ |
Linus Walleij | 451938d5 | 2016-04-27 10:23:44 +0200 | [diff] [blame] | 117 | IN --+ +----- out |
Linus Walleij | 6b5029d | 2016-04-05 16:49:57 +0200 | [diff] [blame] | 118 | | ||--+ |
| 119 | +--/ ----|| N-MOS-FET |
| 120 | OS ||--+ |
| 121 | | |
| 122 | GND |
| 123 | |
Linus Walleij | 451938d5 | 2016-04-27 10:23:44 +0200 | [diff] [blame] | 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 |
Linus Walleij | 6b5029d | 2016-04-05 16:49:57 +0200 | [diff] [blame] | 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 |
Linus Walleij | 451938d5 | 2016-04-27 10:23:44 +0200 | [diff] [blame] | 139 | or open source, in practice by flicking open the switches labeled "OD" and "OS" |
| 140 | in the drawing above. |
Linus Walleij | 6b5029d | 2016-04-05 16:49:57 +0200 | [diff] [blame] | 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 |
Linus Walleij | 451938d5 | 2016-04-27 10:23:44 +0200 | [diff] [blame] | 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, |
Linus Walleij | 6b5029d | 2016-04-05 16:49:57 +0200 | [diff] [blame] | 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 | |
Linus Walleij | 99adc05 | 2014-01-22 15:00:55 +0100 | [diff] [blame] | 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 | |
Grygorii Strashko | c307b00 | 2015-10-20 17:22:15 +0300 | [diff] [blame] | 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 [1]. |
| 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 [2]. |
| 184 | |
Linus Walleij | 90887db | 2014-04-09 14:36:32 +0200 | [diff] [blame] | 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 | |
Grygorii Strashko | c307b00 | 2015-10-20 17:22:15 +0300 | [diff] [blame] | 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 [3]). |
| 212 | Know W/A: The generic_handle_irq() is expected to be called with IRQ disabled, |
Masanari Iida | 547d4c1 | 2015-11-16 20:00:35 +0900 | [diff] [blame] | 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: |
Grygorii Strashko | c307b00 | 2015-10-20 17:22:15 +0300 | [diff] [blame] | 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 | |
Linus Walleij | 4aa50b8 | 2015-10-27 11:13:18 +0100 | [diff] [blame] | 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: |
Linus Walleij | 90887db | 2014-04-09 14:36:32 +0200 | [diff] [blame] | 245 | |
| 246 | static irqreturn_t tc3589x_gpio_irq(int irq, void *data) |
| 247 | ... |
| 248 | handle_nested_irq(irq); |
| 249 | |
Linus Walleij | 4aa50b8 | 2015-10-27 11:13:18 +0100 | [diff] [blame] | 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. |
Linus Walleij | 90887db | 2014-04-09 14:36:32 +0200 | [diff] [blame] | 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 | * gpiochip_set_chained_irqchip(): sets up a chained irq handler for a |
| 266 | gpio_chip from a parent IRQ and passes the struct gpio_chip* as handler |
| 267 | data. (Notice handler data, since the irqchip data is likely used by the |
Linus Walleij | 3f97d5fc | 2014-09-26 14:19:52 +0200 | [diff] [blame] | 268 | parent irqchip!) This is for the chained type of chip. This is also used |
Linus Walleij | 4aa50b8 | 2015-10-27 11:13:18 +0100 | [diff] [blame] | 269 | to set up a nested irqchip if NULL is passed as handler. |
Linus Walleij | 90887db | 2014-04-09 14:36:32 +0200 | [diff] [blame] | 270 | |
| 271 | To use the helpers please keep the following in mind: |
| 272 | |
| 273 | - Make sure to assign all relevant members of the struct gpio_chip so that |
| 274 | the irqchip can initialize. E.g. .dev and .can_sleep shall be set up |
| 275 | properly. |
| 276 | |
Grygorii Strashko | c307b00 | 2015-10-20 17:22:15 +0300 | [diff] [blame] | 277 | - Nominally set all handlers to handle_bad_irq() in the setup call and pass |
| 278 | handle_bad_irq() as flow handler parameter in gpiochip_irqchip_add() if it is |
| 279 | expected for GPIO driver that irqchip .set_type() callback have to be called |
| 280 | before using/enabling GPIO IRQ. Then set the handler to handle_level_irq() |
| 281 | and/or handle_edge_irq() in the irqchip .set_type() callback depending on |
| 282 | what your controller supports. |
| 283 | |
Linus Walleij | 99adc05 | 2014-01-22 15:00:55 +0100 | [diff] [blame] | 284 | It is legal for any IRQ consumer to request an IRQ from any irqchip no matter |
| 285 | if that is a combined GPIO+IRQ driver. The basic premise is that gpio_chip and |
| 286 | irq_chip are orthogonal, and offering their services independent of each |
| 287 | other. |
| 288 | |
| 289 | gpiod_to_irq() is just a convenience function to figure out the IRQ for a |
| 290 | certain GPIO line and should not be relied upon to have been called before |
| 291 | the IRQ is used. |
| 292 | |
| 293 | So always prepare the hardware and make it ready for action in respective |
| 294 | callbacks from the GPIO and irqchip APIs. Do not rely on gpiod_to_irq() having |
| 295 | been called first. |
| 296 | |
| 297 | This orthogonality leads to ambiguities that we need to solve: if there is |
| 298 | competition inside the subsystem which side is using the resource (a certain |
| 299 | GPIO line and register for example) it needs to deny certain operations and |
| 300 | keep track of usage inside of the gpiolib subsystem. This is why the API |
| 301 | below exists. |
| 302 | |
| 303 | |
Alexandre Courbot | fd8e198 | 2013-11-16 21:34:21 +0900 | [diff] [blame] | 304 | Locking IRQ usage |
| 305 | ----------------- |
| 306 | Input GPIOs can be used as IRQ signals. When this happens, a driver is requested |
| 307 | to mark the GPIO as being used as an IRQ: |
| 308 | |
Alexandre Courbot | e3a2e87 | 2014-10-23 17:27:07 +0900 | [diff] [blame] | 309 | int gpiochip_lock_as_irq(struct gpio_chip *chip, unsigned int offset) |
Alexandre Courbot | fd8e198 | 2013-11-16 21:34:21 +0900 | [diff] [blame] | 310 | |
| 311 | This will prevent the use of non-irq related GPIO APIs until the GPIO IRQ lock |
| 312 | is released: |
| 313 | |
Alexandre Courbot | e3a2e87 | 2014-10-23 17:27:07 +0900 | [diff] [blame] | 314 | void gpiochip_unlock_as_irq(struct gpio_chip *chip, unsigned int offset) |
Linus Walleij | 99adc05 | 2014-01-22 15:00:55 +0100 | [diff] [blame] | 315 | |
| 316 | When implementing an irqchip inside a GPIO driver, these two functions should |
| 317 | typically be called in the .startup() and .shutdown() callbacks from the |
| 318 | irqchip. |
Guenter Roeck | f7d4ad9 | 2014-07-22 08:01:01 -0700 | [diff] [blame] | 319 | |
Grygorii Strashko | c307b00 | 2015-10-20 17:22:15 +0300 | [diff] [blame] | 320 | Real-Time compliance for GPIO IRQ chips |
| 321 | --------------------------------------- |
| 322 | |
| 323 | Any provider of irqchips needs to be carefully tailored to support Real Time |
Masanari Iida | 547d4c1 | 2015-11-16 20:00:35 +0900 | [diff] [blame] | 324 | preemption. It is desirable that all irqchips in the GPIO subsystem keep this |
Grygorii Strashko | c307b00 | 2015-10-20 17:22:15 +0300 | [diff] [blame] | 325 | in mind and does the proper testing to assure they are real time-enabled. |
| 326 | So, pay attention on above " RT_FULL:" notes, please. |
| 327 | The following is a checklist to follow when preparing a driver for real |
| 328 | time-compliance: |
| 329 | |
| 330 | - ensure spinlock_t is not used as part irq_chip implementation; |
| 331 | - ensure that sleepable APIs are not used as part irq_chip implementation. |
| 332 | If sleepable APIs have to be used, these can be done from the .irq_bus_lock() |
| 333 | and .irq_bus_unlock() callbacks; |
| 334 | - Chained GPIO irqchips: ensure spinlock_t or any sleepable APIs are not used |
| 335 | from chained IRQ handler; |
| 336 | - Generic chained GPIO irqchips: take care about generic_handle_irq() calls and |
| 337 | apply corresponding W/A; |
| 338 | - Chained GPIO irqchips: get rid of chained IRQ handler and use generic irq |
| 339 | handler if possible :) |
| 340 | - regmap_mmio: Sry, but you are in trouble :( if MMIO regmap is used as for |
| 341 | GPIO IRQ chip implementation; |
| 342 | - Test your driver with the appropriate in-kernel real time test cases for both |
| 343 | level and edge IRQs. |
| 344 | |
Guenter Roeck | f7d4ad9 | 2014-07-22 08:01:01 -0700 | [diff] [blame] | 345 | |
| 346 | Requesting self-owned GPIO pins |
| 347 | ------------------------------- |
| 348 | |
| 349 | Sometimes it is useful to allow a GPIO chip driver to request its own GPIO |
| 350 | descriptors through the gpiolib API. Using gpio_request() for this purpose |
| 351 | does not help since it pins the module to the kernel forever (it calls |
| 352 | try_module_get()). A GPIO driver can use the following functions instead |
| 353 | to request and free descriptors without being pinned to the kernel forever. |
| 354 | |
Alexandre Courbot | abdc08a | 2014-08-19 10:06:09 -0700 | [diff] [blame] | 355 | struct gpio_desc *gpiochip_request_own_desc(struct gpio_desc *desc, |
| 356 | const char *label) |
Guenter Roeck | f7d4ad9 | 2014-07-22 08:01:01 -0700 | [diff] [blame] | 357 | |
| 358 | void gpiochip_free_own_desc(struct gpio_desc *desc) |
| 359 | |
| 360 | Descriptors requested with gpiochip_request_own_desc() must be released with |
| 361 | gpiochip_free_own_desc(). |
| 362 | |
| 363 | These functions must be used with care since they do not affect module use |
| 364 | count. Do not use the functions to request gpio descriptors not owned by the |
| 365 | calling driver. |
Grygorii Strashko | c307b00 | 2015-10-20 17:22:15 +0300 | [diff] [blame] | 366 | |
| 367 | [1] http://www.spinics.net/lists/linux-omap/msg120425.html |
| 368 | [2] https://lkml.org/lkml/2015/9/25/494 |
| 369 | [3] https://lkml.org/lkml/2015/9/25/495 |