[PATCH] pinctrl: document the "GPIO mode" pitfall

Linus Walleij linus.walleij at linaro.org
Fri Apr 26 04:49:12 EDT 2013


On Fri, Apr 26, 2013 at 1:15 AM, Laurent Pinchart
<laurent.pinchart at ideasonboard.com> wrote:
> On Thursday 25 April 2013 23:39:18 Linus Walleij wrote:
>> On Tue, Apr 23, 2013 at 3:33 PM, Laurent Pinchart wrote:

>> > Could you clarify the exact scope of the two configuration parameters ?
>>
>> PIN_CONFIG_OUTPUT is left a bit unspecified, but here the idea was a passive
>> drive, like just connecting the pin to VDD or GND without any driver stage
>> at all.
>
> Isn't that a driver stage ? :-)

OK something that is not a totempole type drive ...
push/pull surely implies a totempole type design.

> What is unclear to me is the interaction between OUTPUT and DRIVE_*.
> That's the part I would like to see clarified.

I sent some patch now, check it ... hm reported-by still doesn't add
you to CC :-/ better patch git-send-email...

> Does DRIVE_* imply that the pin
> is driven by the selected function, and OUTPUT imply that the pin is driven to
> a fixed level ?

That is unclear, but I suggest DRIVE* implies that everything on the pin
is driven according to that configuration. (Else it is getting ignored...)

OUTPUT would be used when you don't know the particulars or when
the driving cannot be controlled in a fine-grained manner like with the
DRIVE* configs.

Does this make sense?

> If so, how do you configure the drive type of a pin that will
> be used through the GPIO API ?

It is possible to use the pinctrl and GPIO APIs orthogonally.

For example the pinctrl can use hogs to reconfigure the pins
during sleep without intervention from the GPIO API.

So they will be fingering on the same pins registers.
Maybe even the same register (if access can be protected
properly) from different APIs.

> What about cases where I want to drive the pin
> to a fixed level in a non low-power output mode (for instance because I need
> more current that what the low-power output mode provides) ?

Just use pinconfig for that?

Is the usecase something like a power-supplying GPIO pin
and then sometimes you want to provide more power from it?

Then use pinconfig to shunt in the driver stages, and GPIO API
to enable/disable it.

Yours,
Linus Walleij



More information about the linux-arm-kernel mailing list