提交 73f8fed0 编写于 作者: A Andrew Jeffery 提交者: Linus Walleij

pinctrl: Reflow/wrap paragraph describing GPIO interaction

Signed-off-by: NAndrew Jeffery <andrew@aj.id.au>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
上级 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% .
You are about to add 0 people to the discussion. Proceed with caution.
先完成此消息的编辑!
想要评论请 注册