pinctrl: allow exlusive GPIO/mux pin allocation

Disallow simultaneous use of the the GPIO and peripheral mux
functions by setting a flag "strict" in struct pinctrl_desc.

The blackfin pinmux and gpio controller doesn't allow user to
set up a pin for both GPIO and peripheral function. So, add flag
strict in struct pinctrl_desc to check both gpio_owner and
mux_owner before approving the pin request.

v2-changes:
- if strict flag is set, check gpio_owner and mux_onwer in if and
  else clause

v3-changes:
- add kerneldoc for this struct
- augment Documentation/pinctrl.txt

Signed-off-by: Sonic Zhang <sonic.zhang@analog.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>

1 files changed, 11 insertions, 0 deletions

diff --git a/Documentation/pinctrl.txt b/Documentation/pinctrl.txt
index a9b4716..d6b2bed 100644
--- a/Documentation/pinctrl.txt
+++ b/Documentation/pinctrl.txt
@@ -73,6 +73,7 @@ static struct pinctrl_desc foo_desc = {
 	.pins = foo_pins,
 	.npins = ARRAY_SIZE(foo_pins),
 	.owner = THIS_MODULE,
+	.strict = true,
 };
 
 int __init foo_probe(void)
@@ -830,6 +831,11 @@ 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.
 
+A flag "strict" in struct pinctrl_desc is available to check and deny
+simultaneous access to the same pin from GPIO and pin multiplexing
+consumers on hardware of this type. The pinctrl driver should set this flag
+accordingly.
+
 (B)
 
                        pin config
@@ -850,6 +856,11 @@ 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.
 
+In some pin controllers, although the physical pins are designed in the same
+way as (B), the GPIO function still can't be enabled at the same time as the
+peripheral functions. So again the "strict" flag should be set, denying
+simultaneous activation by GPIO and other muxed in devices.
+
 From a kernel point of view, however, these are different aspects of the
 hardware and shall be put into different subsystems: