From: Linus Walleij <[email protected]>
This elaborates a bit on the pin control and pin muxing
logic vs GPIO arangements in the hardware.
Inspired by some drawings in a mail from Christian Ruppert.
Both arrangements are confirmed to exist in practice.
Cc: Rob Landley <[email protected]>
Cc: Christian Ruppert <[email protected]>
Signed-off-by: Linus Walleij <[email protected]>
---
ChangeLog v1->v2:
- Cut down to two arrangements that I *know* exist in reality.
- Reword, rehash, rinse, repeat...
---
Documentation/pinctrl.txt | 69 ++++++++++++++++++++++++++++++++++++++++++-----
1 file changed, 63 insertions(+), 6 deletions(-)
diff --git a/Documentation/pinctrl.txt b/Documentation/pinctrl.txt
index c5948c7..62f3f2f 100644
--- a/Documentation/pinctrl.txt
+++ b/Documentation/pinctrl.txt
@@ -795,18 +795,75 @@ special GPIO-handler is registered.
GPIO mode pitfalls
==================
-Sometime the developer may be confused by a datasheet talking about a pin
-being possible to set into "GPIO mode". It appears that what hardware
-engineers mean with "GPIO mode" is not necessarily the use case that is
-implied in the kernel interface <linux/gpio.h>: a pin that you grab from
-kernel code and then either listen for input or drive high/low to
-assert/deassert some external line.
+Due to the naming conventions used by hardware engineers, where "GPIO"
+is taken to mean different things than what the kernel does, the developer
+may be confused by a datasheet talking about a pin being possible to set
+into "GPIO mode". It appears that what hardware engineers mean with
+"GPIO mode" is not necessarily the use case that is implied in the kernel
+interface <linux/gpio.h>: a pin that you grab from kernel code and then
+either listen for input or drive high/low to assert/deassert some
+external line.
Rather hardware engineers think that "GPIO mode" means that you can
software-control a few electrical properties of the pin that you would
not be able to control if the pin was in some other mode, such as muxed in
for a device.
+The GPIO portions of a pin and its relation to a certain pin controller
+configuration and muxing logic can be constructed in several ways. Here
+are three examples:
+
+(A)
+ pin config
+ logic regs
+ | +- SPI
+ Physical pins --- pad --- pinmux -+- I2C
+ | +- mmc
+ | +- GPIO
+ pin
+ multiplex
+ logic
+
+Here some electrical properties of the pin can be configured no matter if the
+pin is used for GPIO or not. After multiplexing GPIO onto the pin, you can
+also drive it high/low from a certain bitset named "GPIO". Or the line can be
+controlled by a certain peripheral, while still applying desired pin config
+properties. GPIO functionality is thus orthogonal to any other device using the
+pad/pin.
+
+In this arrangement the registers for the GPIO portions of the pin controller
+are likely to reside in a separate memory range only intended for GPIO
+driving, and the register range dealing with pin config and pin multiplexing
+get placed into a different memory range and a separate section of the data
+sheet.
+
+(B)
+
+ pin config
+ logic regs
+ | +- SPI
+ Physical pins --- pad --- pinmux -+- I2C
+ | | +- mmc
+ | |
+ GPIO pin
+ multiplex
+ logic
+
+In this arrangement, the GPIO functionality can always be enabled, such that
+e.g. a GPIO input can be used to "spy" on the SPI/I2C/MMC signal while it is
+pulsed out. It is likely possible to disrupt the traffic on the pin by doing
+wrong things on the GPIO block, as it is never really disconnected. It is
+likely that the GPIO, pin config and pin multiplex registers are placed into
+the same memory range and the same section of the data sheet.
+
+From a kernel point of view, however, these are different aspects of the
+hardware and shall be put into different subsystems.
+
+Electrical properties of the pin such as biasing and drive strength
+may be placed at some pin-specific register in all cases or as part
+of the GPIO register in case (B) especially. This doesn't mean that such
+properties necessarily pertain to what the Linux kernel calls "GPIO".
+
Example: a pin is usually muxed in to be used as a UART TX line. But during
system sleep, we need to put this pin into "GPIO mode" and ground it.
--
1.7.11.3
On Thu, Jun 27, 2013 at 11:54:47AM +0200, Linus Walleij wrote:
> From: Linus Walleij <[email protected]>
>
> This elaborates a bit on the pin control and pin muxing
> logic vs GPIO arangements in the hardware.
>
> Inspired by some drawings in a mail from Christian Ruppert.
> Both arrangements are confirmed to exist in practice.
>
> Cc: Rob Landley <[email protected]>
> Cc: Christian Ruppert <[email protected]>
> Signed-off-by: Linus Walleij <[email protected]>
To me this sounds very clear.
Reviewed-by: Christian Ruppert <[email protected]>
> ---
> ChangeLog v1->v2:
> - Cut down to two arrangements that I *know* exist in reality.
> - Reword, rehash, rinse, repeat...
--
Christian Ruppert , <[email protected]>
/|
Tel: +41/(0)22 816 19-42 //| 3, Chemin du Pr?-Fleuri
_// | bilis Systems CH-1228 Plan-les-Ouates
On 06/27/2013 03:54 AM, Linus Walleij wrote:
> From: Linus Walleij <[email protected]>
>
> This elaborates a bit on the pin control and pin muxing
> logic vs GPIO arangements in the hardware.
>
> Inspired by some drawings in a mail from Christian Ruppert.
> Both arrangements are confirmed to exist in practice.
> diff --git a/Documentation/pinctrl.txt b/Documentation/pinctrl.txt
> +The GPIO portions of a pin and its relation to a certain pin controller
> +configuration and muxing logic can be constructed in several ways. Here
> +are three examples:
s/three/two/ now:-)
> +(A)
...
> +Here some electrical properties of the pin can be configured no matter if the
> +pin is used for GPIO or not. After multiplexing GPIO onto the pin, you can
> +also drive it high/low from a certain bitset named "GPIO". Or the line can be
> +controlled by a certain peripheral, while still applying desired pin config
> +properties. GPIO functionality is thus orthogonal to any other device using the
> +pad/pin.
I'd make a few minor tweaks to that:
-----
Here some electrical properties of the pin can be configured no matter
whether the pin is used for GPIO or not. If you multiplex a GPIO onto a
pin, you can also drive it high/low from "GPIO" registers.
Alternatively, the pin can be controlled by a certain peripheral, while
still applying desired pin config properties. GPIO functionality is thus
orthogonal to any other device using the pin.
-----
> +In this arrangement the registers for the GPIO portions of the pin controller
That slightly assumes that GPIO is part of the pin controller HW module,
and then this paragraph is simply saying that the registers are likely
to be segmented within that HW module. To more explicitly allow for
entirely separate GPIO and pin controller HW modules, I would add the
following immediately after that line:
, or the registers for the GPIO HW module,
> +are likely to reside in a separate memory range only intended for GPIO
> +driving, and the register range dealing with pin config and pin multiplexing
> +get placed into a different memory range and a separate section of the data
> +sheet.
> +(B)
...
> +In this arrangement, the GPIO functionality can always be enabled, such that
> +e.g. a GPIO input can be used to "spy" on the SPI/I2C/MMC signal while it is
> +pulsed out. It is likely possible to disrupt the traffic on the pin by doing
> +wrong things on the GPIO block, as it is never really disconnected.
(added a line break here)
> +It is
> +likely that the GPIO, pin config and pin multiplex registers are placed into
> +the same memory range and the same section of the data sheet.
Well, I guess the one example we have of this HW structure is that way,
but I don't see any HW reason that has to be true. I would vote to
either remove that last sentence, or perhaps re-write it as:
-----
It is possible that the GPIO, pin config and pin multiplex registers are
placed into the same memory range and the same section of the data
sheet, although that need not be the case.
-----
> +From a kernel point of view, however, these are different aspects of the
> +hardware and shall be put into different subsystems.
> +
> +Electrical properties of the pin such as biasing and drive strength
> +may be placed at some pin-specific register in all cases or as part
> +of the GPIO register in case (B) especially. This doesn't mean that such
> +properties necessarily pertain to what the Linux kernel calls "GPIO".
Is it worth explaining which Linux subsystem each of the three aspects
are controlled by. Something like:
-----
Registers (or fields within registers) that control electrical
properties of the pin such as biasing and drive strength should be
exposed through the pinctrl subsystem, as "pin configuration" settings.
Registers (or fields within registers) that control muxing of signals
from various other HW blocks (e.g. I2C, MMC, or GPIO) onto pins should
be exposed through the pinctrl subssytem, as mux functions.
Registers (or fields within registers) that control GPIO functionality
such as setting a GPIO's output value, reading a GPIO's input value, or
setting GPIO pin direction should be exposed through the GPIO subsystem.
Depending on the exact HW register design, some functions exposed by the
GPIO subsystem may call into the pinctrl subsystem in order to
co-ordinate register settings across HW modules. In particular, this may
be needed for HW with separate GPIO and pin controller HW modules, where
e.g. GPIO direction is determined by a register in the pin controller HW
module rather than the GPIO HW module.
-----
Otherwise, this patch seems good. Reading this version, it's much more
obvious to me what the intent of the patch is, for some reason:-)
On Thu, Jun 27, 2013 at 04:00:49PM -0600, Stephen Warren wrote:
> On 06/27/2013 03:54 AM, Linus Walleij wrote:
> > From: Linus Walleij <[email protected]>
> [...]
> > +From a kernel point of view, however, these are different aspects of the
> > +hardware and shall be put into different subsystems.
> > +
> > +Electrical properties of the pin such as biasing and drive strength
> > +may be placed at some pin-specific register in all cases or as part
> > +of the GPIO register in case (B) especially. This doesn't mean that such
> > +properties necessarily pertain to what the Linux kernel calls "GPIO".
>
> Is it worth explaining which Linux subsystem each of the three aspects
> are controlled by. Something like:
>
> -----
> Registers (or fields within registers) that control electrical
> properties of the pin such as biasing and drive strength should be
> exposed through the pinctrl subsystem, as "pin configuration" settings.
>
> Registers (or fields within registers) that control muxing of signals
> from various other HW blocks (e.g. I2C, MMC, or GPIO) onto pins should
> be exposed through the pinctrl subssytem, as mux functions.
>
> Registers (or fields within registers) that control GPIO functionality
> such as setting a GPIO's output value, reading a GPIO's input value, or
> setting GPIO pin direction should be exposed through the GPIO subsystem.
>
> Depending on the exact HW register design, some functions exposed by the
> GPIO subsystem may call into the pinctrl subsystem in order to
> co-ordinate register settings across HW modules. In particular, this may
> be needed for HW with separate GPIO and pin controller HW modules, where
> e.g. GPIO direction is determined by a register in the pin controller HW
> module rather than the GPIO HW module.
> -----
I agree, this is really worth mentioning in some place, maybe even a
more prominent one than here.
--
Christian Ruppert , <[email protected]>
/|
Tel: +41/(0)22 816 19-42 //| 3, Chemin du Pr?-Fleuri
_// | bilis Systems CH-1228 Plan-les-Ouates
On Fri, Jun 28, 2013 at 12:00 AM, Stephen Warren <[email protected]> wrote:
> Otherwise, this patch seems good. Reading this version, it's much more
> obvious to me what the intent of the patch is, for some reason:-)
I left this off the pull request and I have now incorporated all your
comments to a final version.
Sorry for the delay!
Yours,
Linus Walleij