sysfs power/state file & dpm_runtime_suspend()

sysfs power/state file & dpm_runtime_suspend()

[???]

Hi,

It seems that we have a consensus on the obsoleteness of the sysfs
power/state
file and dev->power.power_state.event. Could anybody explain why? I have
recently
joined this mailing list and I would like to follow up with the technical
background of
this agreement.

If the sysfs mechanism is deprecated, the dpm_runtime_suspend() seems to be
the only method for runtime power management. But I think it's difficult for
a user-
space power manager to use this function because the caller needs to have
the pointer
to the device which it wants to control.

Lastly, shouldn't the dpm_runtime_suspend() move the device from dpm_active
list
to dpm_off list upon success? This would prevent suspending an
already-suspended
device again in the device_suspend() function.

Ikhwan

Re: sysfs power/state file & dpm_runtime_suspend()

[Alan Stern]

On Thu, 27 Jul 2006, ??? wrote:

> Hi,
> 
> It seems that we have a consensus on the obsoleteness of the sysfs
> power/state
> file and dev->power.power_state.event. Could anybody explain why? I have
> recently
> joined this mailing list and I would like to follow up with the technical
> background of
> this agreement.

Here's a quick summary.  Other people might want to contribute additional 
reasons:

	The values appearing in power/state are foolish numbers (0 or 2).  
	A sane interface would have something more meaningful.

	dpm_runtime_{suspend|resume}() changes the value of
	dev->power.power_state.event, which means that drivers can't
	use the field to store data reliably.

	Proper runtime power management requires drivers to change their
	devices' power states as needed, with no intervention of the PM
	core.  Neither power/state nor power.power_state.event is really
	necessary for this purpose.

	For the most part, user space shouldn't be concerned about runtime
	PM, at least not on the level of individual devices.  In the cases 
	where it does care, there can be device- or system-specific 
	ways of handling it -- like the way DPM handles runtime PM for
	screens.  Userspace _does_ need to be involved in setting runtime 
	PM policy, but that's a separate issue.

	The interface from dpm_runtime_suspend() to device drivers is
	broken.  It calls the drivers' suspend() methods, but that method
	is really meant to inform drivers that the entire system is
	suspending.

	Especially on embedded systems, but potentially everywhere, 
	devices often have more power levels than just ON and SUSPENDED.
	(The most obvious example is PCI with D0, D1, D2, and D3hot, but
	consider also a disk drive that might use ON, STANDBY, and
	SPINDOWN.)  The dpm_runtime_suspend API has no way to describe
	these different power states.

> If the sysfs mechanism is deprecated, the dpm_runtime_suspend() seems to be
> the only method for runtime power management. But I think it's difficult for
> a user-
> space power manager to use this function because the caller needs to have
> the pointer
> to the device which it wants to control.

Userspace power managers shouldn't use dpm_runtime_suspend() at all, for 
the reasons mentioned above.

> Lastly, shouldn't the dpm_runtime_suspend() move the device from dpm_active
> list
> to dpm_off list upon success? This would prevent suspending an
> already-suspended
> device again in the device_suspend() function.

This is a moot point.  dpm_runtime_suspend() shouldn't exist at all, so 
the details of what it does hardly matter.

Alan Stern

Re: sysfs power/state file & dpm_runtime_suspend()

[David Brownell]

On Thursday 27 July 2006 7:43 am, Alan Stern wrote:
> 
> 	Proper runtime power management requires drivers to change their
> 	devices' power states as needed, with no intervention of the PM
> 	core.  Neither power/state nor power.power_state.event is really
> 	necessary for this purpose.

That's a key point that I think was not widely understood early on.  The
driver APIs exist to make sure systems can be cleanly shut down ... not
to reduce power usage.  At best, that sysfs power/state thing is a big
distraction from actually trying to make drivers be power-efficient.

See list archives for the "RFC -- updated Documentation/power/devices.txt"
thread; one of my last posts there has a version of that document with lots
of examples of how runtime power saving works; it does NOT need to involve
any kind of public power state updating.  Things like cpufreq and dynamic
tick, or power-aware idle tasks, don't need to change externally visible
state any more than per-device power saving policies do.

- Dave

Re: sysfs power/state file & dpm_runtime_suspend()

[Ikhwan Lee]

Hi,

Thank you for your answers.

> > Proper runtime power management requires drivers to change their
> > devices' power states as needed, with no intervention of the PM
> > core.  Neither power/state nor power.power_state.event is really
> > necessary for this purpose.
>
> That's a key point that I think was not widely understood early on.  The
> driver APIs exist to make sure systems can be cleanly shut down ... not
> to reduce power usage.  At best, that sysfs power/state thing is a big
> distraction from actually trying to make drivers be power-efficient.

Now I understand that the drivers are responsible for making runtime power
management decisions for individual devices. But there are cases that a
device driver does not have enough information to make the most effective
decision. In such a case, we may want to employ a high level power manager
to make decisions for them.

Suppose we have a SoC with an on-chip multimedia codec. The codec can either
be clock-gated or power-gated, and it shares its power domain with a
neighboring IP, say a 3D engine. Clock gating can be done by the driver
since the clock can be controlled separately. However, the codec driver can
never perform power-gating since it does not know if the 3D engine is active
or not. We would prefer a centralized device power manager in this case.
This is a common case for state-of-the-art mobile handsets such as a DMB
phone. As a different example, a system-level power manager may want to put
the codec into a low quality (thus low power) mode regarding the battery
status. Certainly, this kind of decision cannot be made by the driver.

IMO, having support for such use cases in the PM core and exporting
necessary driver APIs would not be a bad idea. Centralized device power
manager can keep track of the system power states and interdependencies
among devices (the device model perfectly suits for this) while device
drivers provide necessary APIs for safe power state transitions.

> See list archives for the "RFC -- updated Documentation/power/devices.txt"
> thread; one of my last posts there has a version of that document with
lots
> of examples of how runtime power saving works; it does NOT need to involve
> any kind of public power state updating.  Things like cpufreq and dynamic
> tick, or power-aware idle tasks, don't need to change externally visible
> state any more than per-device power saving policies do.

I have been following the thread. I especially like the section on runtime
power management, with lots of examples. I am actually working on some of
them, and my claim is that (as stated above) we may need to involve some
kind of public power state updating in a system-wide way.

Regards,

Ikhwan

Re: sysfs power/state file & dpm_runtime_suspend()

[Alan Stern]

On Wed, 16 Aug 2006, Ikhwan Lee wrote:

> Now I understand that the drivers are responsible for making runtime power
> management decisions for individual devices. But there are cases that a
> device driver does not have enough information to make the most effective
> decision. In such a case, we may want to employ a high level power manager
> to make decisions for them.

Yes, these managers are sometimes needed.

> Suppose we have a SoC with an on-chip multimedia codec. The codec can either
> be clock-gated or power-gated, and it shares its power domain with a
> neighboring IP, say a 3D engine. Clock gating can be done by the driver
> since the clock can be controlled separately. However, the codec driver can
> never perform power-gating since it does not know if the 3D engine is active
> or not. We would prefer a centralized device power manager in this case.
> This is a common case for state-of-the-art mobile handsets such as a DMB
> phone.

In which case a centralized power manager would handle things.  But
there's no reason that power manager couldn't be part of the kernel's
infrastructure.  The individual device drivers would tell it when they
need power, and it would gate off the power when nobody needs any.  In
this case no userspace API is required.  It's merely a platform-level
design issue.

> As a different example, a system-level power manager may want to put
> the codec into a low quality (thus low power) mode regarding the battery
> status. Certainly, this kind of decision cannot be made by the driver.
> 
> IMO, having support for such use cases in the PM core and exporting
> necessary driver APIs would not be a bad idea. Centralized device power
> manager can keep track of the system power states and interdependencies
> among devices (the device model perfectly suits for this) while device
> drivers provide necessary APIs for safe power state transitions.

Unfortunately it's far from clear how or when to do this.  Which drivers 
need to export such an API?  What form should the API take?  Remember, 
each driver will support its own specialized set of power states.  Putting 
such things in the PM core makes sense only if they can all be constrained 
to follow a common pattern.

> I have been following the thread. I especially like the section on runtime
> power management, with lots of examples. I am actually working on some of
> them, and my claim is that (as stated above) we may need to involve some
> kind of public power state updating in a system-wide way.

It's easy to say "some kind of public power state updating".  The hard 
part comes when you have to specify exactly _what_ kind.  That's when the 
flame wars start.

Alan Stern

Re: sysfs power/state file & dpm_runtime_suspend()

[David Brownell]

On Wednesday 16 August 2006 12:17 am, Ikhwan Lee wrote:
> Hi,
> 
> Thank you for your answers.
> 
> > > Proper runtime power management requires drivers to change their
> > > devices' power states as needed, with no intervention of the PM
> > > core.  Neither power/state nor power.power_state.event is really
> > > necessary for this purpose.
> >
> > That's a key point that I think was not widely understood early on.  The
> > driver APIs exist to make sure systems can be cleanly shut down ... not
> > to reduce power usage.  At best, that sysfs power/state thing is a big
> > distraction from actually trying to make drivers be power-efficient.
> 
> Now I understand that the drivers are responsible for making runtime power
> management decisions for individual devices. But there are cases that a
> device driver does not have enough information to make the most effective
> decision. In such a case, we may want to employ a high level power manager
> to make decisions for them.

And that will need some sort of programming interface.  But those will
be providing domain-specific hints and information, not describing the
system-wide power state transitions which are being addressed by current
bus/class/driver suspend()/resume() methods.

Plus, not all drivers will have those cases and thus need new APIs.
Best to let just those drivers pay the costs of such interfaces, and
not try to inflict them universally.  :)


> Suppose we have a SoC with an on-chip multimedia codec. The codec can either
> be clock-gated or power-gated, and it shares its power domain with a
> neighboring IP, say a 3D engine. Clock gating can be done by the driver
> since the clock can be controlled separately. However, the codec driver can
> never perform power-gating since it does not know if the 3D engine is active
> or not. We would prefer a centralized device power manager in this case.

I wouldn't say "centralized"; it doesn't need to handle every device in
the system.  All it needs to understand is one power domain.  And in at
least some of these cases, a simple refcounted enable/disable API should
be able to manage the power domain ... exactly like such an API already
manages the clock domains.  (You can obviously come up with examples
where such refcounting doesn't suffice.  But there are a lot where it
does, including the one you described here.)

There was a voltage domain API drafted a while back, by some folk at
Nokia.  The draft I saw was incomplete, but looked to be in the right
kind of direction; and it was very much in the flavor of <linux/clk.h>
but of course had to deal with the fact that power domains need to
support a choice of voltages.  Example:  voltage fed to an MMC/SD
card may often be 3.3V, but there are low voltage cards too; and many
power domains can be modeled simply as "turn on/off the 2.2V supply".


> This is a common case for state-of-the-art mobile handsets such as a DMB
> phone. As a different example, a system-level power manager may want to put
> the codec into a low quality (thus low power) mode regarding the battery
> status. Certainly, this kind of decision cannot be made by the driver.

You've got a bit of chicken-vs-egg going on there, in that you're assuming
the answer is a system/global manager that knows about the codec!!  While in
fact there can easily be other solutions.  Examples include notifying the
user and letting _them_ choose which module to put into lowpower/off mode
(maybe the WLAN instead, since the codec is more essential just now), or
a general system "cut power usage" notification, which that driver will
interpret in that way.

But I certainly agree that there are cases where "higher level" inputs
are needed to help drivers manage power usage effectively.  I consider
most of those to be domain-specific APIs, outside the specific scope
of the PM framework.  (But clearly needing to be pm-aware designs.)


> IMO, having support for such use cases in the PM core and exporting
> necessary driver APIs would not be a bad idea. Centralized device power
> manager can keep track of the system power states 

A system power state manager should manage/track system power states,
both operating points and sleep states.  Board-specific in general;
each SOC will have reusable functionality (lots of potential operating
points), but then so will external chips ... there's lots of variability
in how things get wired up, so a "glue" component will be needed too.

That is: SOC stuff, plus device drivers, plus board glue, plus state info,
plus configuration ... == system manager.

I can't see any point to a manager that deals only with devices, since
how they're managed (and what they are!) must be board-specific and must
be integrated with the SOC stuff for stuff like power and clock domains,
wake event processing, DMA (e.g. to on-SOC SRAM vs DRAM that might be
in self-refresh mode), etc.


> and interdependencies 
> among devices (the device model perfectly suits for this) while device
> drivers provide necessary APIs for safe power state transitions.

The device model has glitches in terms of not handling power/voltage
domains at all, or devices that sit on multiple busses.  One example
I've seen quite often is an external multifunction chip with a highspeed
serial bus for a codec data link, and a separate serial bus (I2C, SPI, etc)
for its control link and lowspeed non-codec data.  Plus, clusters of
interrelated devices aren't handled that well, even if you assume that
clock and power domain APIs will handle those issues; my pet example
being USB-OTG modules, which started out involving five controllers
(host, peripheral, and OTG for USB; plus I2c and external PHY) before
chip vendors started to use more integrated design approaches.

Given the wide variety of possible device power states, I really think
it's best to try to keep the driver model out of that business.


> > See list archives for the "RFC -- updated Documentation/power/devices.txt"
> > thread; one of my last posts there has a version of that document with
> > lots
> > of examples of how runtime power saving works; it does NOT need to involve
> > any kind of public power state updating.  Things like cpufreq and dynamic
> > tick, or power-aware idle tasks, don't need to change externally visible
> > state any more than per-device power saving policies do.
> 
> I have been following the thread. I especially like the section on runtime
> power management, with lots of examples. I am actually working on some of
> them, and my claim is that (as stated above) we may need to involve some
> kind of public power state updating in a system-wide way.

I can't disagree with that at all.  :)

One of my concerns is how to factor that stuff well -- "architect" it -- so
that the approach is broadly applicable.  A factoring that works well at
the SOC level may not work as well at the board level; working well on one
family of SOCs doesn't mean it works well on others.

I feel comfortable saying we need a power/voltage domain framework, and an
extensible framework for system-wide operating (and non-operating sleep)
states.  The rest looks to me like stuff that would best be worked out
over time, while integrating those two things and fixing the inevitable
botches in the initial designs, as applied to current hardware.

- Dave

Re: sysfs power/state file & dpm_runtime_suspend()

[Ikhwan Lee]

Thanks for your comment.

> > Suppose we have a SoC with an on-chip multimedia codec. The codec can
either
> > be clock-gated or power-gated, and it shares its power domain with a
> > neighboring IP, say a 3D engine. Clock gating can be done by the driver
> > since the clock can be controlled separately. However, the codec driver
can
> > never perform power-gating since it does not know if the 3D engine is
active
> > or not. We would prefer a centralized device power manager in this case.
> > This is a common case for state-of-the-art mobile handsets such as a DMB
> > phone.
>
> In which case a centralized power manager would handle things.  But
> there's no reason that power manager couldn't be part of the kernel's
> infrastructure.  The individual device drivers would tell it when they
> need power, and it would gate off the power when nobody needs any.  In
> this case no userspace API is required.  It's merely a platform-level
> design issue.

We can have the device power manager in the kernel and let the platform
designers hardcode the rules specific to their platform. It is easier to
implement and we can use that scheme right away.

In the future however, I think it is more clear to have a "power/voltage
domain framework, and an extensible framework for system-wide operating (and
non-operating sleep) states," quoting from what David said in his response
to my message.

Ikhwan

Re: sysfs power/state file & dpm_runtime_suspend()

[Ikhwan Lee]

Thanks for your comments.

> > Now I understand that the drivers are responsible for making runtime
power
> > management decisions for individual devices. But there are cases that a
> > device driver does not have enough information to make the most
effective
> > decision. In such a case, we may want to employ a high level power
manager
> > to make decisions for them.
>
> And that will need some sort of programming interface.  But those will
> be providing domain-specific hints and information, not describing the
> system-wide power state transitions which are being addressed by current
> bus/class/driver suspend()/resume() methods.
>
> Plus, not all drivers will have those cases and thus need new APIs.
> Best to let just those drivers pay the costs of such interfaces, and
> not try to inflict them universally.  :)

Basically agree. Some drivers actually allow applications to manage the
device power directly. (usually through ioctl) However, for a
battery-operated embedded system, we would prefer to have all the drivers
provide such interfaces.

> > This is a common case for state-of-the-art mobile handsets such as a DMB
> > phone. As a different example, a system-level power manager may want to
put
> > the codec into a low quality (thus low power) mode regarding the battery
> > status. Certainly, this kind of decision cannot be made by the driver.
>
> You've got a bit of chicken-vs-egg going on there, in that you're assuming
> the answer is a system/global manager that knows about the codec!!  While
in
> fact there can easily be other solutions.  Examples include notifying the
> user and letting _them_ choose which module to put into lowpower/off mode
> (maybe the WLAN instead, since the codec is more essential just now), or
> a general system "cut power usage" notification, which that driver will
> interpret in that way.
>
> But I certainly agree that there are cases where "higher level" inputs
> are needed to help drivers manage power usage effectively.  I consider
> most of those to be domain-specific APIs, outside the specific scope
> of the PM framework.  (But clearly needing to be pm-aware designs.)

Maybe it is the PowerOp's scope?

> > and interdependencies
> > among devices (the device model perfectly suits for this) while device
> > drivers provide necessary APIs for safe power state transitions.
>
> The device model has glitches in terms of not handling power/voltage
> domains at all, or devices that sit on multiple busses.  One example
> I've seen quite often is an external multifunction chip with a highspeed
> serial bus for a codec data link, and a separate serial bus (I2C, SPI,
etc)
> for its control link and lowspeed non-codec data.  Plus, clusters of
> interrelated devices aren't handled that well, even if you assume that
> clock and power domain APIs will handle those issues; my pet example
> being USB-OTG modules, which started out involving five controllers
> (host, peripheral, and OTG for USB; plus I2c and external PHY) before
> chip vendors started to use more integrated design approaches.
>
> Given the wide variety of possible device power states, I really think
> it's best to try to keep the driver model out of that business.

OK, maybe a power/voltage domain framework will do it, and I hope that it
would not be as complex as the device model.

> > I have been following the thread. I especially like the section on
runtime
> > power management, with lots of examples. I am actually working on some
of
> > them, and my claim is that (as stated above) we may need to involve some
> > kind of public power state updating in a system-wide way.
>
> I can't disagree with that at all.  :)
>
> One of my concerns is how to factor that stuff well -- "architect" it -- 
so
> that the approach is broadly applicable.  A factoring that works well at
> the SOC level may not work as well at the board level; working well on one
> family of SOCs doesn't mean it works well on others.

This is a real problem. I sometimes even want to distinguish on-chip devices
from on-board devices.

> I feel comfortable saying we need a power/voltage domain framework, and an
> extensible framework for system-wide operating (and non-operating sleep)
> states.  The rest looks to me like stuff that would best be worked out
> over time, while integrating those two things and fixing the inevitable
> botches in the initial designs, as applied to current hardware.

Can't agree more. =) Having a power/voltage domain framework, the clock
framework, and a framework for system-wide operating states (maybe PowerOp),
we can say that we have a complete power management solution for embedded
systems.

Ikhwan

Re: sysfs power/state file & dpm_runtime_suspend()

[Matthew Locke]

On Aug 16, 2006, at 7:41 PM, Ikhwan Lee wrote:

> Thanks for your comments.
>
>>> Now I understand that the drivers are responsible for making runtime
> power
>>> management decisions for individual devices. But there are cases 
>>> that a
>>> device driver does not have enough information to make the most
> effective
>>> decision. In such a case, we may want to employ a high level power
> manager
>>> to make decisions for them.
>>
>> And that will need some sort of programming interface.  But those will
>> be providing domain-specific hints and information, not describing the
>> system-wide power state transitions which are being addressed by 
>> current
>> bus/class/driver suspend()/resume() methods.
>>
>> Plus, not all drivers will have those cases and thus need new APIs.
>> Best to let just those drivers pay the costs of such interfaces, and
>> not try to inflict them universally.  :)
>
> Basically agree. Some drivers actually allow applications to manage the
> device power directly. (usually through ioctl) However, for a
> battery-operated embedded system, we would prefer to have all the 
> drivers
> provide such interfaces.

Yes, all drivers on the battery power embedded system will need to 
provide the interface and the interface should be the same for these 
drivers.  I'm thinking we only need to allow userspace to turn the 
device on and off.   The other states of the device can be managed by 
the driver with input from another kernel component as discussed 
elsewhere in this thread (But I can't find where right now).

>
>>> This is a common case for state-of-the-art mobile handsets such as a 
>>> DMB
>>> phone. As a different example, a system-level power manager may want 
>>> to
> put
>>> the codec into a low quality (thus low power) mode regarding the 
>>> battery
>>> status. Certainly, this kind of decision cannot be made by the 
>>> driver.
>>
>> You've got a bit of chicken-vs-egg going on there, in that you're 
>> assuming
>> the answer is a system/global manager that knows about the codec!!

Dave,  That is not a chicken v egg problem.  The manager on these 
devices will know a lot about the system.  Its really the only way to 
get maximum balance between power efficiency and keeping the device 
operational for its various use cases.

>>  While
> in
>> fact there can easily be other solutions.  Examples include notifying 
>> the
>> user and letting _them_ choose which module to put into lowpower/off 
>> mode
>> (maybe the WLAN instead, since the codec is more essential just now), 
>> or
>> a general system "cut power usage" notification, which that driver 
>> will
>> interpret in that way.

This is the same as having a manager.  Sometimes it will be a user and 
sometimes it will be automatic based on a policy.

>>
>> But I certainly agree that there are cases where "higher level" inputs
>> are needed to help drivers manage power usage effectively.  I consider
>> most of those to be domain-specific APIs, outside the specific scope
>> of the PM framework.  (But clearly needing to be pm-aware designs.)
>
> Maybe it is the PowerOp's scope?

Partially.  and I don't have much more to add specifically right now:)  
Something will have to tell the audio driver its ok to reduce quality.  
The connection between powerop and drivers (which doesn't exist yet) 
will have to facilitate this communication.

>
>>> and interdependencies
>>> among devices (the device model perfectly suits for this) while 
>>> device
>>> drivers provide necessary APIs for safe power state transitions.
>>
>> The device model has glitches in terms of not handling power/voltage
>> domains at all, or devices that sit on multiple busses.  One example
>> I've seen quite often is an external multifunction chip with a 
>> highspeed
>> serial bus for a codec data link, and a separate serial bus (I2C, SPI,
> etc)
>> for its control link and lowspeed non-codec data.  Plus, clusters of
>> interrelated devices aren't handled that well, even if you assume that
>> clock and power domain APIs will handle those issues; my pet example
>> being USB-OTG modules, which started out involving five controllers
>> (host, peripheral, and OTG for USB; plus I2c and external PHY) before
>> chip vendors started to use more integrated design approaches.
>>
>> Given the wide variety of possible device power states, I really think
>> it's best to try to keep the driver model out of that business.
>
> OK, maybe a power/voltage domain framework will do it, and I hope that 
> it
> would not be as complex as the device model.
>
>>> I have been following the thread. I especially like the section on
> runtime
>>> power management, with lots of examples. I am actually working on 
>>> some
> of
>>> them, and my claim is that (as stated above) we may need to involve 
>>> some
>>> kind of public power state updating in a system-wide way.
>>
>> I can't disagree with that at all.  :)
>>
>> One of my concerns is how to factor that stuff well -- "architect" it 
>> --
> so
>> that the approach is broadly applicable.  A factoring that works well 
>> at
>> the SOC level may not work as well at the board level; working well 
>> on one
>> family of SOCs doesn't mean it works well on others.
>
> This is a real problem. I sometimes even want to distinguish on-chip 
> devices
> from on-board devices.
>
>> I feel comfortable saying we need a power/voltage domain framework, 
>> and an
>> extensible framework for system-wide operating (and non-operating 
>> sleep)
>> states.  The rest looks to me like stuff that would best be worked out
>> over time, while integrating those two things and fixing the 
>> inevitable
>> botches in the initial designs, as applied to current hardware.
>
> Can't agree more. =) Having a power/voltage domain framework, the clock
> framework, and a framework for system-wide operating states (maybe 
> PowerOp),
> we can say that we have a complete power management solution for 
> embedded
> systems.
>

Well, I have to agree with that too:)

> Ikhwan
>
>
> _______________________________________________
> linux-pm mailing list
> linux-pm@lists.osdl.org
> https://lists.osdl.org/mailman/listinfo/linux-pm
>

Re: sysfs power/state file & dpm_runtime_suspend()

[Alan Stern]

On Thu, 17 Aug 2006, Ikhwan Lee wrote:

> We can have the device power manager in the kernel and let the platform
> designers hardcode the rules specific to their platform. It is easier to
> implement and we can use that scheme right away.
> 
> In the future however, I think it is more clear to have a "power/voltage
> domain framework, and an extensible framework for system-wide operating (and
> non-operating sleep) states," quoting from what David said in his response
> to my message.

The second is a generalized version of the first.  However the issue of
the scope of a "power/voltage domain framework" is independent of the
nature of the userspace API for such a framework, which is what you
originally were discussing.  My point was that in a large number of simple
cases (like this one) there is no need for a userspace API at all.

To put it another way, suppose several devices have inter-related power
requirements, such as a common gated voltage source.  Provided each device
has only two power states (ON = "in use" and OFF = "not in use") then any
reasonable framework would be able to manage them adequately even with no
userspace involvement.

Alan Stern