How to power gate a specific single device from outside?

How to power gate a specific single device from outside?

[Waldemar Rymarkiewicz]

Hi

I am looking for a convenient way to power gate specific single device
when the platform is running in backup mode - the platform lost main
power supply and it's on backup buttery now. The intention is to save
max power in backup mode and switch off all unnecessary blocks.

I could not find anything standard that let me power gate single
device from userland. Perhaps it's considered as a too risky operation
to expose to the user. I don't want to touch drivers too much as well
not to make them dependant on extra system feature. Better to have a
separate module that handles this system mode and forces some drivers
to unload/power gate their HW.

Are there already some proven solutions/ideas around the kernel that
can be used straight away?

Suggestions appreciated.

/Waldek

Re: How to power gate a specific single device from outside?

[Alan Cox]

> I could not find anything standard that let me power gate single
> device from userland. Perhaps it's considered as a too risky operation
> to expose to the user. I don't want to touch drivers too much as well
> not to make them dependant on extra system feature. Better to have a
> separate module that handles this system mode and forces some drivers
> to unload/power gate their HW.
> 
> Are there already some proven solutions/ideas around the kernel that
> can be used straight away?

For a lot of devices if you close it then it will try and put the device
into a low power state. If a driver isn't doing that then (unless there
are hardware constraints preventing it) it would make sense to fix it.

There are some things entirely in your control - big ones. In particular
the brightness of laptop panels, pulling everything off one CPU socket,
disabling the nmi watchdog, hard disk power settings, stopping processes
that wake up a lot.

Many of those you can set anyway for best power behaviour (see powertop).

Alan

Re: How to power gate a specific single device from outside?

[Waldemar Rymarkiewicz]

On 25 October 2017 at 01:56, Alan Cox <gnomes@lxorguk.ukuu.org.uk> wrote:
>
> For a lot of devices if you close it then it will try and put the device
> into a low power state. If a driver isn't doing that then (unless there
> are hardware constraints preventing it) it would make sense to fix it.
>
> There are some things entirely in your control - big ones. In particular
> the brightness of laptop panels, pulling everything off one CPU socket,
> disabling the nmi watchdog, hard disk power settings, stopping processes
> that wake up a lot.
>
> Many of those you can set anyway for best power behaviour (see powertop).
>

Thanks Alan for your feedback.

This is not really what I'm looking for. I do an embedded design and
need to have more fine-grained control over certain IP blocks inside
the SoC and outside when entering "backup" mode or "selective suspend"
or whatever we call it.

The whole idea is to save maximum power in case of voltage outage on
the main rail to let the system still do some emergency activities
when it's on the backup battery. A simple circuit (or more complex
power switch IC) will discover voltage outage, switch to a
battery-backed rail and will generate an irq to SoC.

Now, what I need in the kernel is to _selectively_ suspend devices
that are not needed in the "backup/emergency" mode.

If current state of the power frameworks for system sleep, runtime pm,
genpd etc. are not able to handle this transition, and as far as I
understand these subsystems they cannot handle this straight away, I
propose to extend with a new power state PM_SUSPEND_EMERGENCY or so to
suspend unnecessary blocks of the system and leave the rest to operate
in emergency mode.

In DT we could specify which devices should go in low power state when
in emergency mode eg.
node {
    ....
    suspend-in-emergency;
    .....
}

So the device driver knows if it should be suspended in
PM_SUSPEND_EMERGENCY or not.  The driver has to provide a callback in
pm_ops to handle this transition or we could reuse suspend callback if
possible.

Just a brief idea. Does it make sense to anyone?

/Waldek

Re: How to power gate a specific single device from outside?

[Alan Cox]

> Now, what I need in the kernel is to _selectively_ suspend devices
> that are not needed in the "backup/emergency" mode.

Which means you need to get the applications using them to die - or you
could rewrite the driver top to bottom to have locking sufficient to
ensure that your power management changes don't interact with any
existing functionality and every function neatly aborts or errors in a
safe way to the userspace which you've also modified extensively to cope.

I knmow which I'd choose.

> If current state of the power frameworks for system sleep, runtime pm,
> genpd etc. are not able to handle this transition, and as far as I
> understand these subsystems they cannot handle this straight away

Correct - nor can you handle it straight away because you might be in the
middle of doing something so need to finish a transactio before you can
drop to a lower power level.

> In DT we could specify which devices should go in low power state when
> in emergency mode eg.
> node {
>     ....
>     suspend-in-emergency;
>     .....
> }

If a component of your hardware has a low power mode then why aren't you
always putting it in lowest power mode except when it's in current use ?

> So the device driver knows if it should be suspended in
> PM_SUSPEND_EMERGENCY or not.  The driver has to provide a callback in
> pm_ops to handle this transition or we could reuse suspend callback if
> possible.

You need to re-use the existing power management logic, and in many cases
that means you'll need to shut down the userspace processes that are
keeping the device busy because they will be keeping it from going to
sleep.

> Just a brief idea. Does it make sense to anyone?

So the normal way you do this kind of stuff is to use runlevels with init
(or the systemd equivalents)

When the power goes poof you change runlevel. init kills off and
shuts down all the services you want to drop. Those close the devices,
which being well behaved shove themselves into the deepest sleep they can.

When the power comes back you switch runlevel back and stuff respawns.

Alan