diff options
Diffstat (limited to 'Documentation/gpio.txt')
| -rw-r--r-- | Documentation/gpio.txt | 42 |
1 files changed, 42 insertions, 0 deletions
diff --git a/Documentation/gpio.txt b/Documentation/gpio.txt index e08a883de36e..77a1d11af723 100644 --- a/Documentation/gpio.txt +++ b/Documentation/gpio.txt | |||
| @@ -439,6 +439,48 @@ slower clock delays the rising edge of SCK, and the I2C master adjusts its | |||
| 439 | signaling rate accordingly. | 439 | signaling rate accordingly. |
| 440 | 440 | ||
| 441 | 441 | ||
| 442 | GPIO controllers and the pinctrl subsystem | ||
| 443 | ------------------------------------------ | ||
| 444 | |||
| 445 | A GPIO controller on a SOC might be tightly coupled with the pinctrl | ||
| 446 | subsystem, in the sense that the pins can be used by other functions | ||
| 447 | together with an optional gpio feature. We have already covered the | ||
| 448 | case where e.g. a GPIO controller need to reserve a pin or set the | ||
| 449 | direction of a pin by calling any of: | ||
| 450 | |||
| 451 | pinctrl_request_gpio() | ||
| 452 | pinctrl_free_gpio() | ||
| 453 | pinctrl_gpio_direction_input() | ||
| 454 | pinctrl_gpio_direction_output() | ||
| 455 | |||
| 456 | But how does the pin control subsystem cross-correlate the GPIO | ||
| 457 | numbers (which are a global business) to a certain pin on a certain | ||
| 458 | pin controller? | ||
| 459 | |||
| 460 | This is done by registering "ranges" of pins, which are essentially | ||
| 461 | cross-reference tables. These are described in | ||
| 462 | Documentation/pinctrl.txt | ||
| 463 | |||
| 464 | While the pin allocation is totally managed by the pinctrl subsystem, | ||
| 465 | gpio (under gpiolib) is still maintained by gpio drivers. It may happen | ||
| 466 | that different pin ranges in a SoC is managed by different gpio drivers. | ||
| 467 | |||
| 468 | This makes it logical to let gpio drivers announce their pin ranges to | ||
| 469 | the pin ctrl subsystem before it will call 'pinctrl_request_gpio' in order | ||
| 470 | to request the corresponding pin to be prepared by the pinctrl subsystem | ||
| 471 | before any gpio usage. | ||
| 472 | |||
| 473 | For this, the gpio controller can register its pin range with pinctrl | ||
| 474 | subsystem. There are two ways of doing it currently: with or without DT. | ||
| 475 | |||
| 476 | For with DT support refer to Documentation/devicetree/bindings/gpio/gpio.txt. | ||
| 477 | |||
| 478 | For non-DT support, user can call gpiochip_add_pin_range() with appropriate | ||
| 479 | parameters to register a range of gpio pins with a pinctrl driver. For this | ||
| 480 | exact name string of pinctrl device has to be passed as one of the | ||
| 481 | argument to this routine. | ||
| 482 | |||
| 483 | |||
| 442 | What do these conventions omit? | 484 | What do these conventions omit? |
| 443 | =============================== | 485 | =============================== |
| 444 | One of the biggest things these conventions omit is pin multiplexing, since | 486 | One of the biggest things these conventions omit is pin multiplexing, since |
