From 73f8fed031d51868b57835cb1616c6aeea20a8d0 Mon Sep 17 00:00:00 2001 From: Andrew Jeffery Date: Fri, 10 Jun 2016 16:46:36 +0930 Subject: pinctrl: Reflow/wrap paragraph describing GPIO interaction Signed-off-by: Andrew Jeffery Signed-off-by: Linus Walleij --- Documentation/pinctrl.txt | 14 +++++++------- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git a/Documentation/pinctrl.txt b/Documentation/pinctrl.txt index 07d102c3d05a1..6414a613cb8a0 100644 --- a/Documentation/pinctrl.txt +++ b/Documentation/pinctrl.txt @@ -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 situations a cross-subsystem mapping between pins and GPIOs is needed. -Since the pin controller subsystem has its pinspace local to the pin -controller we need a mapping so that the pin control subsystem can figure out -which pin controller handles control of a certain GPIO pin. Since a single -pin controller may be muxing several GPIO ranges (typically SoCs that have -one set of pins, but internally several GPIO silicon blocks, each modelled as -a struct gpio_chip) any number of GPIO ranges can be added to a pin controller -instance like this: +Since the pin controller subsystem has its pinspace local to the pin controller +we need a mapping so that the pin control subsystem can figure out which pin +controller handles control of a certain GPIO pin. Since a single pin controller +may be muxing several GPIO ranges (typically SoCs that have one set of pins, +but internally several GPIO silicon blocks, each modelled as a struct +gpio_chip) any number of GPIO ranges can be added to a pin controller instance +like this: struct gpio_chip chip_a; struct gpio_chip chip_b; -- cgit v1.2.3