[RFC] ARM: at91: gpio add mux check

[RFC] ARM: at91: gpio add mux check

[Jean-Christophe PLAGNIOL-VILLARD]

this will check if the pio is not configured as mux first

Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>
Cc: Linus Walleij <linus.walleij@stericsson.com>
Cc: swarren at nvidia.com
---
Hi,

	one of the the issue is what happened it the bootloader miss
	configured a pin a periph A or B?

	do we need to keep the tracking of it in the pinmux?

Best Regards,
J.
 arch/arm/mach-at91/gpio.c |   15 +++++++++++++++
 1 files changed, 15 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-at91/gpio.c b/arch/arm/mach-at91/gpio.c
index 743f668..89761d0 100644
--- a/arch/arm/mach-at91/gpio.c
+++ b/arch/arm/mach-at91/gpio.c
@@ -38,6 +38,7 @@ struct at91_gpio_chip {
 #define to_at91_gpio_chip(c) container_of(c, struct at91_gpio_chip, chip)
 
 static void at91_gpiolib_dbg_show(struct seq_file *s, struct gpio_chip *chip);
+static int at91_gpiolib_request(struct gpio_chip *chip, unsigned offset);
 static void at91_gpiolib_set(struct gpio_chip *chip, unsigned offset, int val);
 static int at91_gpiolib_get(struct gpio_chip *chip, unsigned offset);
 static int at91_gpiolib_direction_output(struct gpio_chip *chip,
@@ -49,6 +50,7 @@ static int at91_gpiolib_direction_input(struct gpio_chip *chip,
 	{								\
 		.chip = {						\
 			.label		  = name,			\
+			.request	  = at91_gpiolib_request,	\
 			.direction_input  = at91_gpiolib_direction_input, \
 			.direction_output = at91_gpiolib_direction_output, \
 			.get		  = at91_gpiolib_get,		\
@@ -532,6 +534,19 @@ void __init at91_gpio_irq_setup(void)
 }
 
 /* gpiolib support */
+
+static int at91_gpiolib_request(struct gpio_chip *chip, unsigned offset)
+{
+	struct at91_gpio_chip *at91_gpio = to_at91_gpio_chip(chip);
+	void __iomem *pio = at91_gpio->regbase;
+	unsigned mask = 1 << offset;
+
+	if (__raw_readl(pio + PIO_PSR) & mask)
+		return 0;
+
+	return -EBUSY;
+}
+
 static int at91_gpiolib_direction_input(struct gpio_chip *chip,
 					unsigned offset)
 {
-- 
1.7.7

[RFC] ARM: at91: gpio add mux check

[Stephen Warren]

Jean-Christophe PLAGNIOL-VILLARD wrote at Monday, October 24, 2011 7:13 AM:
> this will check if the pio is not configured as mux first
...
> 	one of the the issue is what happened it the bootloader miss
> 	configured a pin a periph A or B?
> 
> 	do we need to keep the tracking of it in the pinmux?
...
> +static int at91_gpiolib_request(struct gpio_chip *chip, unsigned offset)
> +{
> +	struct at91_gpio_chip *at91_gpio = to_at91_gpio_chip(chip);
> +	void __iomem *pio = at91_gpio->regbase;
> +	unsigned mask = 1 << offset;
> +
> +	if (__raw_readl(pio + PIO_PSR) & mask)
> +		return 0;
> +
> +	return -EBUSY;
> +}

Yes, this will break if the boot-loader configured some pin as a special
function instead of as a GPIO. I suggest this check be implemented using
SW state instead; pinctrl's gpio_request_enable op should set this SW
state. On Tegra at least (and I think looking at your registers, on this
Atmel part too), the pinctrl's gpio_request_enable ends up calling a
function in the GPIO driver to toggle between GPIO vs. special function
mode for the pin, so both maintenance and usage of this SW state could
be completely isolated within the GPIO driver; no data explicit sharing
of the variable is required between pinmux and GPIO.

-- 
nvpublic

[RFC] ARM: at91: gpio add mux check

[Linus Walleij]

On Mon, Oct 24, 2011 at 3:13 PM, Jean-Christophe PLAGNIOL-VILLARD
<plagnioj@jcrosoft.com> wrote:

> Hi,
>
> ? ? ? ?one of the the issue is what happened it the bootloader miss
> ? ? ? ?configured a pin a periph A or B?
>
> ? ? ? ?do we need to keep the tracking of it in the pinmux?

Is there an AT91 pinmux driver? If yes, I guess it's something custom and I
have only looked briefly at these. Generally I would recommend modeling
any muxing using the pinctrl subsystem but if and only if Torvalds decide to
pull it in.

Yours.
Linus Walleij

[RFC] ARM: at91: gpio add mux check

[Jean-Christophe PLAGNIOL-VILLARD]

On 10:39 Tue 25 Oct     , Linus Walleij wrote:
> On Mon, Oct 24, 2011 at 3:13 PM, Jean-Christophe PLAGNIOL-VILLARD
> <plagnioj@jcrosoft.com> wrote:
> 
> > Hi,
> >
> > ? ? ? ?one of the the issue is what happened it the bootloader miss
> > ? ? ? ?configured a pin a periph A or B?
> >
> > ? ? ? ?do we need to keep the tracking of it in the pinmux?
> 
> Is there an AT91 pinmux driver? If yes, I guess it's something custom and I
> have only looked briefly at these. Generally I would recommend modeling
> any muxing using the pinctrl subsystem but if and only if Torvalds decide to
> pull it in.
Yes I start to implement one

but I've need to hardcode in the driver the pull, multidrive per function

I'll send it soon

Best Regards,
J.

[RFC] ARM: at91: gpio add mux check

[Linus Walleij]

On Tue, Oct 25, 2011 at 1:09 PM, Jean-Christophe PLAGNIOL-VILLARD
<plagnioj@jcrosoft.com> wrote:
> On 10:39 Tue 25 Oct ? ? , Linus Walleij wrote:
>> Is there an AT91 pinmux driver? If yes, I guess it's something custom and I
>> have only looked briefly at these. Generally I would recommend modeling
>> any muxing using the pinctrl subsystem but if and only if Torvalds decide to
>> pull it in.
>
> Yes I start to implement one

Yes! Way to go! I just tried to convince Torvalds to pull this subsystem
in so it's nice to see some traction.

> but I've need to hardcode in the driver the pull, multidrive per function

For the next kernel cycle I (and I guess Steven & the others)
surely want to provide the right interfaces to do also this kind
of stuff. Help us iron it out!

Yours,
Linus Walleij