Re: [PATCH 06/12] pinctrl/nomadik: implement pin configuration

[Linus Walleij]

On Wed, May 9, 2012 at 10:44 PM, Stephen Warren <swarren@xxxxxxxxxxxxx> wrote:
> On 05/08/2012 03:45 AM, Linus Walleij wrote:
>> From: Linus Walleij <linus.walleij@xxxxxxxxxx>
>>
>> This implements the pin configuration interface for the
>> Nomadik pin controller.
>>
>> As part of the exercise we add a bit in the pin_cfg_t for
>> the Nomadik pinctrl driver that indicates if the pin should
>> be forced into GPIO mode. This is not done to go behind the
>> back of the GPIO subsystem, but to ensure that default modes
>> can be set by hogs on boot and system suspend/resume states.
>> It was used implicitly by the old code defining all config
>> settings and modes in a single config word but we now have
>> a split between pinmux and pinconf leading to the need to
>> have this.
>
> Yes, I have wondered if we should have always represented the
> GPIO/pinctrl interaction as a pinctrl "function" of "GPIO. There are a
> few gotchas that prevented me moving forward with this though:
>
> 1) On Tegra at least, GPIO-vs-pinmux is actually a bit in the GPIO
> controller, so that mux is after the pinmux's output mux

Nomadik/Ux500 is different. It has the mux before the driver
stage, so we need to driver the GPIO lo/hi by a bit into the
mux, then after the driver stage we can e.g. pull up/down.

> 2) I'm not sure how it'd work when you could mux "GPIO controller A GPIO
> x" or "GPIO controller B pin y" onto the same pinctrl pin

Well pins x and y have a unique number in the GPIO numberspace,
which means they will have two different ranges defined,
and depending on which range you get passed to
.gpio_request_enable() you do different things in the driver.

But with named gpio functions on each pin and just a plain request()
there will be a problem (I guess this is what you're referring to).

Maybe it's simply so that .gpio_request_enable() is a better
idea for this kind of scenario anyway?

> 3) On Tegra at least, special-function muxing is at a per-pingroup
> level, but GPIO muxing is at a per-pin level. So much for regular HW:-(

I think we need to keep concepts separate, and think of the
usecase rather than the fact that the pin has a mode which happens
to be called "gpio", for my usecase that is just a four-letter acronym
with no meaning than that it's a hardware state, it could be named
"drive control" or "frox" or whatever.

Right now it's working pretty well since when I put the pins to sleep
I need to configure them into a mode where I can set the pins to be
biased and in a certain way and with certain wakeup props.

That mode happens to have the name "gpio" and has the
side-effect that if it had been claimed for GPIO it would have been
possible to use the gpiolib interface to drive it high/low etc. But since
the pins are occupied by a device, this isn't possible, gpio_request()
would fail on it.

So this is one of these cases where trying to map physical
properties to logical framework use breaks down, and we have
to rely on the kernel concepts for determining what the pin is
really used for. Just reading a hardware register won't tell us
if it's actually used for GPIO or for some device sleep mode.
Not in this driver atleast.

>> @@ -1561,7 +1562,8 @@ int nmk_gpio_request_enable(struct pinctrl_dev *pctldev,
>>
>>       clk_enable(nmk_chip->clk);
>>       bit = offset % NMK_GPIO_PER_CHIP;
>> -     __nmk_gpio_set_mode_safe(nmk_chip, bit, NMK_GPIO_ALT_GPIO, false);
>> +     /* There is no glitch when converting any pin to GPIO */
>> +     __nmk_gpio_set_mode(nmk_chip, bit, NMK_GPIO_ALT_GPIO);
>
> Was that meant to be squashed into some other earlier change?

Yes, I'll update!

Thanks,
Linus Walleij
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/