[RFC] the right way to use gpiolib hooks to automate power management?

[RFC] the right way to use gpiolib hooks to automate power management?

[Gregory Bean]

Hi folks:

On MSM, we have a bank of gpios whose physical characteristics are
controlled via a 'gpiomux' subsystem, which sets things like drive
strength, pull-up, pull-down, gpio functional assignment, and the like.

We have a written a software driver which reference-counts these gpio
lines (via a put()/get() api), putting them in their "high-power" active
configurations when they're in use, and dropping them down into a
high-impedance low-power setting when they're not.

We can't use gpiolib for this because many of these gpios are set to
'non-gpio' mux settings: they get assigned to busses as data or address
lines (for example) and are not used as gpios after that.

However, for those gpios which are left in 'gpio mode', we DO want
gpiolib to 'do the right thing' as regards power management.  From the
following text in Documentation/gpio.txt:

   int gpio_request(unsigned gpio, const char *label);
   void gpio_free(unsigned gpio);

   ...Some platforms may also use knowledge about what GPIOs are
   active for power management, such as by powering down unused
   chip sectors and, more easily, gating off unused clocks...

I interpret from this that it is 'healthy' behavior to put a call to our
gpiomux get() in our gpio_chip's gpio_request(), and a matching call to
our gpiomux put() in gpio_free().  It seems to me that this would bring
lines out of low-power mode when they're first requested, and put them
back to sleep when they're released, exactly as we want.

Is this the right thing to be doing, or is this going to get us in
trouble? I want to make sure we're using the system as it was intended.

Thanks!
-- 
Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.

[RFC] the right way to use gpiolib hooks to automate power management?

[Gregory Bean]

Hi folks:

On MSM, we have a bank of gpios whose physical characteristics are
controlled via a 'gpiomux' subsystem, which sets things like drive
strength, pull-up, pull-down, gpio functional assignment, and the like.

We have a written a software driver which reference-counts these gpio
lines (via a put()/get() api), putting them in their "high-power" active
configurations when they're in use, and dropping them down into a
high-impedance low-power setting when they're not.

We can't use gpiolib for this because many of these gpios are set to
'non-gpio' mux settings: they get assigned to busses as data or address
lines (for example) and are not used as gpios after that.

However, for those gpios which are left in 'gpio mode', we DO want
gpiolib to 'do the right thing' as regards power management.  From the
following text in Documentation/gpio.txt:

   int gpio_request(unsigned gpio, const char *label);
   void gpio_free(unsigned gpio);

   ...Some platforms may also use knowledge about what GPIOs are
   active for power management, such as by powering down unused
   chip sectors and, more easily, gating off unused clocks...

I interpret from this that it is 'healthy' behavior to put a call to our
gpiomux get() in our gpio_chip's gpio_request(), and a matching call to
our gpiomux put() in gpio_free().  It seems to me that this would bring
lines out of low-power mode when they're first requested, and put them
back to sleep when they're released, exactly as we want.

Is this the right thing to be doing, or is this going to get us in
trouble? I want to make sure we're using the system as it was intended.

Thanks!
-- 
Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.

Re: [RFC] the right way to use gpiolib hooks to automate power management?

[Russell King - ARM Linux]

On Thu, Aug 12, 2010 at 09:39:29AM -0700, Gregory Bean wrote:
> On MSM, we have a bank of gpios whose physical characteristics are
> controlled via a 'gpiomux' subsystem, which sets things like drive
> strength, pull-up, pull-down, gpio functional assignment, and the like.
>
> We have a written a software driver which reference-counts these gpio
> lines (via a put()/get() api), putting them in their "high-power" active
> configurations when they're in use, and dropping them down into a
> high-impedance low-power setting when they're not.

Beware.  What you're suggesting can lead to an increase in power
consumption rather than the reduction you're looking for.

Inputs don't like to float at mid-rail (mid-rail is absolutely the _worst_
thing you can do with an unused input.)  Mid-rail means both transistors
on the input are partially turned on, thereby causing current to flow
between the supply rail through these transistors down to ground.

This is also exactly the same reason why power consumption is related to
clock speeds - when an input changes state, there's an overlap between one
transistor turning on and the other turning off, which causes a pulse of
current to be taken.

It's far better, not only for power consumption reasons but also ESD
sensitivity reasons to have unused outputs actively driven to their
appropriate inactive level.

Consider that output you're about to switch to a high impedance state
(which makes it appear as an input.)  Have you first checked that there's
a pull-up or pull-down resistor on the signal, or have you just created
the situation where the device has become more sensitive to electrical
noise and increased its (and the connected device) quiescent power
dissipation?

[RFC] the right way to use gpiolib hooks to automate power management?

[Russell King - ARM Linux]

On Thu, Aug 12, 2010 at 09:39:29AM -0700, Gregory Bean wrote:
> On MSM, we have a bank of gpios whose physical characteristics are
> controlled via a 'gpiomux' subsystem, which sets things like drive
> strength, pull-up, pull-down, gpio functional assignment, and the like.
>
> We have a written a software driver which reference-counts these gpio
> lines (via a put()/get() api), putting them in their "high-power" active
> configurations when they're in use, and dropping them down into a
> high-impedance low-power setting when they're not.

Beware.  What you're suggesting can lead to an increase in power
consumption rather than the reduction you're looking for.

Inputs don't like to float at mid-rail (mid-rail is absolutely the _worst_
thing you can do with an unused input.)  Mid-rail means both transistors
on the input are partially turned on, thereby causing current to flow
between the supply rail through these transistors down to ground.

This is also exactly the same reason why power consumption is related to
clock speeds - when an input changes state, there's an overlap between one
transistor turning on and the other turning off, which causes a pulse of
current to be taken.

It's far better, not only for power consumption reasons but also ESD
sensitivity reasons to have unused outputs actively driven to their
appropriate inactive level.

Consider that output you're about to switch to a high impedance state
(which makes it appear as an input.)  Have you first checked that there's
a pull-up or pull-down resistor on the signal, or have you just created
the situation where the device has become more sensitive to electrical
noise and increased its (and the connected device) quiescent power
dissipation?

Re: [RFC] the right way to use gpiolib hooks to automate power management?

[David Brown]

On Thu, Aug 12, 2010 at 07:27:44PM +0100, Russell King - ARM Linux wrote:
> On Thu, Aug 12, 2010 at 09:39:29AM -0700, Gregory Bean wrote:
> > We have a written a software driver which reference-counts these gpio
> > lines (via a put()/get() api), putting them in their "high-power" active
> > configurations when they're in use, and dropping them down into a
> > high-impedance low-power setting when they're not.
> 
> Beware.  What you're suggesting can lead to an increase in power
> consumption rather than the reduction you're looking for.

That probably just got a little obscured, since I think Greg is more
concerned with the mechanism in software.  Our gpio's are generally
configured in "low power" to be high-impedance with a pull-up or
pull-down, depending on what it is hooked to.  They can be configured
in most of the ways that would make sense to do so.

It may be the case, though, that what this "low power" mode is might
need to also be configurable, since it likely depends on how the pin
is connected.

David

[RFC] the right way to use gpiolib hooks to automate power management?

[David Brown]

On Thu, Aug 12, 2010 at 07:27:44PM +0100, Russell King - ARM Linux wrote:
> On Thu, Aug 12, 2010 at 09:39:29AM -0700, Gregory Bean wrote:
> > We have a written a software driver which reference-counts these gpio
> > lines (via a put()/get() api), putting them in their "high-power" active
> > configurations when they're in use, and dropping them down into a
> > high-impedance low-power setting when they're not.
> 
> Beware.  What you're suggesting can lead to an increase in power
> consumption rather than the reduction you're looking for.

That probably just got a little obscured, since I think Greg is more
concerned with the mechanism in software.  Our gpio's are generally
configured in "low power" to be high-impedance with a pull-up or
pull-down, depending on what it is hooked to.  They can be configured
in most of the ways that would make sense to do so.

It may be the case, though, that what this "low power" mode is might
need to also be configurable, since it likely depends on how the pin
is connected.

David