the right way to use gpiolib hooks to automate power management?

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.

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?

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