Messages in this thread | | | Date | Thu, 21 Apr 2011 08:48:31 +0200 | Subject | Re: [PATCH 1/2] gpio: add pin biasing and drive mode to gpiolib | From | Linus Walleij <> |
| |
2011/4/21 Ben Nizette <bn@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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |