Commit 73f8fed0 authored by Andrew Jeffery's avatar Andrew Jeffery Committed by Linus Walleij

pinctrl: Reflow/wrap paragraph describing GPIO interaction

Signed-off-by: default avatarAndrew Jeffery <andrew@aj.id.au>
Signed-off-by: default avatarLinus Walleij <linus.walleij@linaro.org>
parent eef06737
...@@ -286,13 +286,13 @@ see the section named "pin control requests from drivers" and ...@@ -286,13 +286,13 @@ see the section named "pin control requests from drivers" and
"drivers needing both pin control and GPIOs" below for details. But in some "drivers needing both pin control and GPIOs" below for details. But in some
situations a cross-subsystem mapping between pins and GPIOs is needed. situations a cross-subsystem mapping between pins and GPIOs is needed.
Since the pin controller subsystem has its pinspace local to the pin Since the pin controller subsystem has its pinspace local to the pin controller
controller we need a mapping so that the pin control subsystem can figure out we need a mapping so that the pin control subsystem can figure out which pin
which pin controller handles control of a certain GPIO pin. Since a single controller handles control of a certain GPIO pin. Since a single pin controller
pin controller may be muxing several GPIO ranges (typically SoCs that have may be muxing several GPIO ranges (typically SoCs that have one set of pins,
one set of pins, but internally several GPIO silicon blocks, each modelled as but internally several GPIO silicon blocks, each modelled as a struct
a struct gpio_chip) any number of GPIO ranges can be added to a pin controller gpio_chip) any number of GPIO ranges can be added to a pin controller instance
instance like this: like this:
struct gpio_chip chip_a; struct gpio_chip chip_a;
struct gpio_chip chip_b; struct gpio_chip chip_b;
......
Markdown is supported
0%
or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment