[PATCH 1/2] gpio: add pin biasing and drive mode to gpiolib

Linus Walleij linus.walleij at linaro.org
Thu Apr 21 02:48:31 EDT 2011

2011/4/21 Ben Nizette <bn at niasdigital.com>:

>> This patch is about biasing and drive modes. We need to alter
>> these at runtime (from board code, indeed) due to the fact that
>> when you go to sleep e.g. floating a pin yeilds better power
>> characteristics.
> This is actually an interesting case because floating pins yeild
> /worse/ power characteristics (each transistor of the push-pull
> is on a little bit and you get a path straight through) [1].  To
> get good power performance you want to pull an input pin high or
> low but which of those two directions depends on external
> constraints, i.e. the board.

Yeah, mea culpa, I twisted it around in my head. I mean the
reverse. So this is why there are GPIO_CONFIG_BIAS_HIGH
and GPIO_CONFIG_BIAS_GROUND in the predefined pin
bias states.

(I do get it, don't worry, I was in electroscience before I
turned computer science actually...)

>  This is a case where the driver
> should /not/ go playing with things it can't fully understand.
> Perhaps one of the properties that a board can set in a gpio chip
> driver is the suspend state and have suspend/resume hooks in the
> gpio chip take care of setting things up on each side.

Yes, the API is not only for drivers, it's for boards alright.

Pushing it to drivers/gpio give us two advantages:

1. Depopulate the overpopulated arch/arm/* etc trees
2. Give an overview so the GPIO maintainer and others can
  think about consolidations
3. Clear cut drivers that can have runtime PM hooks etc...

Linus Walleij

More information about the linux-arm-kernel mailing list