Re: Re: [RFD] How to tell ACPI drivers what the target sleep state is (was: Re: [PATCH 1/2] acpi choose sleep state help)

Re: Re: [RFD] How to tell ACPI drivers what the target sleep state is (was: Re: [PATCH 1/2] acpi choose sleep state help)

[David Brownell]

On Thursday 21 June 2007, Alan Stern wrote:
> On Thu, 21 Jun 2007, David Brownell wrote:
> > On Thursday 21 June 2007, Alan Stern wrote:
> > > 
> > > _How_ does the provider know what the next target state is?
> > 
> > That's an interface between the provider and the platform's PM code.
> > Remember those two patches?
> > ...
> 
> Now we're getting back to the question which started this thread.  
> That patch takes care of one platform, but now consider an ACPI system.  
> How should the ACPI core learn what the next target system state will
> be? 

The original patch -- to which the previous $SUBJECT patch was
an update -- did more or less the same thing:  pm_ops recorded
the ACPI target state ...


> And once it possess that knowledge, what's the best way for it to 
> tell various subsystems which device states/functions will be
> supported?

... and then exposed a method returning ACPI_STATE_Sx values,
called by non-core ACPI code.

At which point your narrative falters.  What it's exposed to is
not a subsystem ... but ACPI versions of hooks invoked by the
subsystem.  For PCI, to be specific.

That is, the knowledge of that target sleep state never leaves
that platform's PM code.  (In this case, ACPI; including its PCI
support, which lives in drivers/pci not drivers/acpi.)  Because
no subsystem other than ACPI itself should care how ACPI does any
of its PM stuff.


> > Of course, I believe we need to move away from "suspend_state_t"
> > being effectively just "standby" or "STR" (or "ON") so that more
> > of the hardware capabilities can be exposed.   Systems that have,
> > say, seven different hardware states can't fit into Linux today.
> 
> I agree that the list of system states should be configurable and 
> perhaps even adjustable at runtime.  However this is somewhat OT.

Only slightly; remember, a main reason Linux has so few states is
that PCs don't use any more.  There are a number of PC-specific
models and assumptions lurking in this area.  One of them is that
the target sleep state is anything more than a stepping-stone to
the important platform-specific information.


> > (Related, I think that target *run* states are under-appreciated.
> > That's the general runtime PM issue.  Interfaces should work for
> > run-state transitions as well as sleep-state ones...)
> 
> Perhaps something like this: Resource providers have an API whereby
> drivers can find out what resources either are currently available or
> will be available in the next system state (a little awkward to specify
> which is needed).  Then drivers decide on a new device state based on
> the type of change requested and the available resources, and notify
> the providers via a second API about any change in resource usage.

Resource providers have interfaces (*) they expose; yes.  *IF* those
resources change availability based on system states, there must be
interfaces drivers can use to notice that.  The providers already have
interfaces to manage resources, and won't need new cals for that. 

The calls to expose whether a given in-use resource must be released
or modified would be simplest if they're just query calls made by
driver suspend()/resume() methods, but there's also something to be
said for callbacks in certain contexts.

(*) "API" == "Application Programming Interface", a userspace thing.
    So I avoid using that TLA for anything inside the OS kernel.

 
> > > There could be a global next_pm_system_state() routine.  It would have
> > > to return _something_ -- and I think a cookie would be better than a
> > > struct.
> > 
> > But *should* there be such a routine?  Interpreting it would
> > necessarily be very platform-specific.  Why should anyone care
> > about platform-specific calls ... except people writing the
> > platform-specific code to implement and use those calls?
> 
> You forgot one thing.  Yes, the code that makes those calls and uses
> the results would be platform-specific.  But the code that gets called
> would be part of the PM core and hence not platform-specific -- even
> though the values it returns are.

That's the kind of notion that waves red flags at me.  If it's
returning platform-specific values and types, to platform-specific
code, is there any realistic way to view that code as not being
specific to that platform?  Why bother trying to package it as a
core capability, except to show that it's possible to discard
type information at will?

Sure, ACPI_STATE_Sx values aren't declared as "__bitwise", and so
they are very amenable to type punning with values from other
platforms.  But I'd call that sort of thing a "bug" not a "feature".
And I can't see a way to have that routine be part of the PM core
without relying on that bug in a very deep (and error prone) way.


> > I still disagree.  Has anyone even proposed an example of a driver
> > caring about "what the target sleep state is"?  Every example we
> > have seen in the past several years is an example where the relevant
> > detail is something *else* ... something which is only loosely
> > associated with that state, in a very platform-specific way.
> 
> Granted that the association is loose and platform-specific.  
> Nevertheless, it is non-zero.

So are the association with Earthlings, and the non-association with
Martians or Venusians.  ;)

The association is so weak that trying to build on it becomes
rapidly counterproductive.  Focus on the "something else" which
actually matters to the drivers.

- Dave

Re: Re: [RFD] How to tell ACPI drivers what the target sleep state is (was: Re: [PATCH 1/2] acpi choose sleep state help)

[Rafael J. Wysocki]

On Thursday, 21 June 2007 20:51, Alan Stern wrote:
> On Thu, 21 Jun 2007, David Brownell wrote:
> 
> > On Thursday 21 June 2007, Alan Stern wrote:
> > > On Thu, 21 Jun 2007, David Brownell wrote:
> > > 
> > > > > If a driver wants to find out whether some resource will be available
> > > > > in the target system state, the only way is to ask the resource's
> > > > > provider.  Hence the driver needs to have some cookie (representing the
> > > > > target state) that it can pass to the provider.
> > > > 
> > > > Not true.  The provider knows the target state.  Just ask it whether
> > > > the resource will be available.  It doesn't need a cookie to distinguish
> > > > between multiple target states, since there can be only one.
> > > 
> > > _How_ does the provider know what the next target state is?
> > 
> > That's an interface between the provider and the platform's PM code.
> > Remember those two patches?
> > 
> >   http://lkml.org/lkml/2007/3/22/241
> >   http://lkml.org/lkml/2007/3/22/242
> > 
> > The second one does that by coupling one platform's pm_ops to its
> > clock framework using an internal interface.  That will be typical
> > for any SOC system, where the difference between states is mostly
> > just which oscillators/PLLs are active ... pm_ops being essentially
> > tasked with turning some stuff off.
> 
> Now we're getting back to the question which started this thread.  
> That patch takes care of one platform, but now consider an ACPI system.  
> How should the ACPI core learn what the next target system state will
> be?

Yes, this is what I'm interested in in the first place.

> And once it possess that knowledge, what's the best way for it to 
> tell various subsystems which device states/functions will be
> supported?

I think it can be asked for that via a pair of callbacks, like:

platform->lowest_power_state_the_device_can_be_in(dev, wakeup)

and

platform->highest_power_state_the_device_can_be_in(dev)

where 'wakeup' tells the platform whether we want this device to be able to
wake up the system.

> > Of course, I believe we need to move away from "suspend_state_t"
> > being effectively just "standby" or "STR" (or "ON") so that more
> > of the hardware capabilities can be exposed.   Systems that have,
> > say, seven different hardware states can't fit into Linux today.
> 
> I agree that the list of system states should be configurable and 
> perhaps even adjustable at runtime.  However this is somewhat OT.

Agreed.

> > (Related, I think that target *run* states are under-appreciated.
> > That's the general runtime PM issue.  Interfaces should work for
> > run-state transitions as well as sleep-state ones...)
> 
> Perhaps something like this: Resource providers have an API whereby
> drivers can find out what resources either are currently available or
> will be available in the next system state (a little awkward to specify
> which is needed).  Then drivers decide on a new device state based on
> the type of change requested and the available resources, and notify
> the providers via a second API about any change in resource usage.

Yes, something like this.
 
> > > There could be a global next_pm_system_state() routine.  It would have
> > > to return _something_ -- and I think a cookie would be better than a
> > > struct.
> > 
> > But *should* there be such a routine?  Interpreting it would
> > necessarily be very platform-specific.  Why should anyone care
> > about platform-specific calls ... except people writing the
> > platform-specific code to implement and use those calls?
> 
> You forgot one thing.  Yes, the code that makes those calls and uses
> the results would be platform-specific.  But the code that gets called
> would be part of the PM core and hence not platform-specific -- even
> though the values it returns are.
> 
> Now perhaps I'm beating a dead horse and the existing pm_ops callbacks 
> already provide the necessary notifications.  If so I'll shut up.

No, they don't.

pm_ops->prepare() is now called after the drivers' .suspend() routines have
been executed, so the ACPI core, for example, has no means of learning what
the next system state will be until all devices have been suspended.
 
> > I still disagree.  Has anyone even proposed an example of a driver
> > caring about "what the target sleep state is"?  Every example we
> > have seen in the past several years is an example where the relevant
> > detail is something *else* ... something which is only loosely
> > associated with that state, in a very platform-specific way.
> 
> Granted that the association is loose and platform-specific.  
> Nevertheless, it is non-zero.

Agreed.

Greetings,
Rafael


-- 
"Premature optimization is the root of all evil." - Donald Knuth

Re: Re: [RFD] How to tell ACPI drivers what the target sleep state is (was: Re: [PATCH 1/2] acpi choose sleep state help)

[David Brownell]

On Thursday 21 June 2007, Rafael J. Wysocki wrote:

> platform->lowest_power_state_the_device_can_be_in(dev, wakeup)
> 
> and
> 
> platform->highest_power_state_the_device_can_be_in(dev)
> 
> where 'wakeup' tells the platform whether we want this device to be able to
> wake up the system.

That won't work well except with ACPI, since few systems centralize
that knowledge.  Like ACPI does with AML ... but mostly for PCI.

Look at your average SOC chip spec and you'll see a lot of information
that lives most naturally in the device drivers, or sometimes in the
clock framework.



> pm_ops->prepare() is now called after the drivers' .suspend() routines have
> been executed, so the ACPI core, for example, has no means of learning what
> the next system state will be until all devices have been suspended.

Well that's a design mistake.  Remember that those suspend() methods
need to know the target system states, so that they can call the right
"_SxD" and "_SxW" methods.  There needs to be *SOME* call into the
platform code that can be used to track "x" for ACPI ... or whatever
is needed on other platforms.

What is "now" by the way ... something in the MM tree?  Or did that
sneak in while I wasn't looking?

- Dave

Re: Re: [RFD] How to tell ACPI drivers what the target sleep state is (was: Re: [PATCH 1/2] acpi choose sleep state help)

[Rafael J. Wysocki]

On Thursday, 21 June 2007 22:32, David Brownell wrote:
> On Thursday 21 June 2007, Rafael J. Wysocki wrote:
> 
> > platform->lowest_power_state_the_device_can_be_in(dev, wakeup)
> > 
> > and
> > 
> > platform->highest_power_state_the_device_can_be_in(dev)
> > 
> > where 'wakeup' tells the platform whether we want this device to be able to
> > wake up the system.
> 
> That won't work well except with ACPI, since few systems centralize
> that knowledge.  Like ACPI does with AML ... but mostly for PCI.
> 
> Look at your average SOC chip spec and you'll see a lot of information
> that lives most naturally in the device drivers, or sometimes in the
> clock framework.
> 
> 
> 
> > pm_ops->prepare() is now called after the drivers' .suspend() routines have
> > been executed, so the ACPI core, for example, has no means of learning what
> > the next system state will be until all devices have been suspended.
> 
> Well that's a design mistake.

pm_ops->prepare() has to be called after device_suspend() for other reasons.

> Remember that those suspend() methods 
> need to know the target system states, so that they can call the right
> "_SxD" and "_SxW" methods.  There needs to be *SOME* call into the
> platform code that can be used to track "x" for ACPI ... or whatever
> is needed on other platforms.

YES!  And that's what I'm asking about: How are we going to handle that?

> What is "now" by the way ... something in the MM tree?  Or did that
> sneak in while I wasn't looking?

2.6.22-rc5 actually, and the patch was from Linus himself, acked by Len. ;-)

Greetings,
Rafael


-- 
"Premature optimization is the root of all evil." - Donald Knuth

Re: Re: [RFD] How to tell ACPI drivers what the target sleep state is (was: Re: [PATCH 1/2] acpi choose sleep state help)

[Rafael J. Wysocki]

On Thursday, 21 June 2007 21:51, David Brownell wrote:
> On Thursday 21 June 2007, Alan Stern wrote:
> > On Thu, 21 Jun 2007, David Brownell wrote:
> > > On Thursday 21 June 2007, Alan Stern wrote:
> > > > 
> > > > _How_ does the provider know what the next target state is?
> > > 
> > > That's an interface between the provider and the platform's PM code.
> > > Remember those two patches?
> > > ...
> > 
> > Now we're getting back to the question which started this thread.  
> > That patch takes care of one platform, but now consider an ACPI system.  
> > How should the ACPI core learn what the next target system state will
> > be? 
> 
> The original patch -- to which the previous $SUBJECT patch was
> an update -- did more or less the same thing:  pm_ops recorded
> the ACPI target state ...
> 
> 
> > And once it possess that knowledge, what's the best way for it to 
> > tell various subsystems which device states/functions will be
> > supported?
> 
> ... and then exposed a method returning ACPI_STATE_Sx values,
> called by non-core ACPI code.

But we have changed the suspend code ordering and the state
recorded by pm_ops only becomes known to ACPI _after_ we have suspended
devices.

That's what this thread is all about, BTW.

> At which point your narrative falters.  What it's exposed to is
> not a subsystem ... but ACPI versions of hooks invoked by the
> subsystem.  For PCI, to be specific.
> 
> That is, the knowledge of that target sleep state never leaves
> that platform's PM code.  (In this case, ACPI; including its PCI
> support, which lives in drivers/pci not drivers/acpi.)  Because
> no subsystem other than ACPI itself should care how ACPI does any
> of its PM stuff.

All of this is fine, but we need some way to tell ACPI what the next sleep
state will be, because currently _we_ _have_ _not_ one.

So, do we introduce an additional pm_op to do that or are we going to do
something else?
 
> > > Of course, I believe we need to move away from "suspend_state_t"
> > > being effectively just "standby" or "STR" (or "ON") so that more
> > > of the hardware capabilities can be exposed.   Systems that have,
> > > say, seven different hardware states can't fit into Linux today.
> > 
> > I agree that the list of system states should be configurable and 
> > perhaps even adjustable at runtime.  However this is somewhat OT.
> 
> Only slightly; remember, a main reason Linux has so few states is
> that PCs don't use any more.  There are a number of PC-specific
> models and assumptions lurking in this area.  One of them is that
> the target sleep state is anything more than a stepping-stone to
> the important platform-specific information.

As far as my original question is concerned, this is OT.

> > > (Related, I think that target *run* states are under-appreciated.
> > > That's the general runtime PM issue.  Interfaces should work for
> > > run-state transitions as well as sleep-state ones...)
> > 
> > Perhaps something like this: Resource providers have an API whereby
> > drivers can find out what resources either are currently available or
> > will be available in the next system state (a little awkward to specify
> > which is needed).  Then drivers decide on a new device state based on
> > the type of change requested and the available resources, and notify
> > the providers via a second API about any change in resource usage.
> 
> Resource providers have interfaces (*) they expose; yes.  *IF* those
> resources change availability based on system states, there must be
> interfaces drivers can use to notice that.  The providers already have
> interfaces to manage resources, and won't need new cals for that. 
> 
> The calls to expose whether a given in-use resource must be released
> or modified would be simplest if they're just query calls made by
> driver suspend()/resume() methods, but there's also something to be
> said for callbacks in certain contexts.
> 
> (*) "API" == "Application Programming Interface", a userspace thing.
>     So I avoid using that TLA for anything inside the OS kernel.

Agreed.

Greetings,
Rafael


-- 
"Premature optimization is the root of all evil." - Donald Knuth

Re: Re: [RFD] How to tell ACPI drivers what the target sleep state is (was: Re: [PATCH 1/2] acpi choose sleep state help)

[David Brownell]

On Thursday 21 June 2007, Rafael J. Wysocki wrote:

> All of this is fine, but we need some way to tell ACPI what the next sleep
> state will be, because currently _we_ _have_ _not_ one.
> 
> So, do we introduce an additional pm_op to do that or are we going to do
> something else?

Simplest would be an additional op.

Re: Re: [RFD] How to tell ACPI drivers what the target sleep state is (was: Re: [PATCH 1/2] acpi choose sleep state help)

[Rafael J. Wysocki]

On Thursday, 21 June 2007 22:46, David Brownell wrote:
> On Thursday 21 June 2007, Rafael J. Wysocki wrote:
> 
> > All of this is fine, but we need some way to tell ACPI what the next sleep
> > state will be, because currently _we_ _have_ _not_ one.
> > 
> > So, do we introduce an additional pm_op to do that or are we going to do
> > something else?
> 
> Simplest would be an additional op.

OK

Does anyone have any objections to adding a new pm_op that will tell
the ACPI core (or generally, a platform core code) what target system sleep
state we are going to enter?

Greetings,
Rafael


-- 
"Premature optimization is the root of all evil." - Donald Knuth

Platform-specific system power states

[Alan Stern]

[Note change of Subject and CC: list restriction]

On Thu, 21 Jun 2007, David Brownell wrote:

> That is, the knowledge of that target sleep state never leaves
> that platform's PM code.  (In this case, ACPI; including its PCI
> support, which lives in drivers/pci not drivers/acpi.)  Because
> no subsystem other than ACPI itself should care how ACPI does any
> of its PM stuff.

> > I agree that the list of system states should be configurable and 
> > perhaps even adjustable at runtime.  However this is somewhat OT.
> 
> Only slightly; remember, a main reason Linux has so few states is
> that PCs don't use any more.  There are a number of PC-specific
> models and assumptions lurking in this area.  One of them is that
> the target sleep state is anything more than a stepping-stone to
> the important platform-specific information.

I'd be perfectly happy to have the list of supported system power 
states be exported by the platform code instead of predetermined by the 
PM core.  It would still be necessary to add a method whereby the PM 
core could inform the platform about the new target state at the 
beginning of a state change.  And of course there would have to be a 
way for drivers or subsystems to query the platform, to see what 
resources would be available.


> > Perhaps something like this: Resource providers have an API whereby
> > drivers can find out what resources either are currently available or
> > will be available in the next system state (a little awkward to specify
> > which is needed).  Then drivers decide on a new device state based on
> > the type of change requested and the available resources, and notify
> > the providers via a second API about any change in resource usage.
> 
> Resource providers have interfaces (*) they expose; yes.  *IF* those
> resources change availability based on system states, there must be
> interfaces drivers can use to notice that.  The providers already have
> interfaces to manage resources, and won't need new cals for that. 
> 
> The calls to expose whether a given in-use resource must be released
> or modified would be simplest if they're just query calls made by
> driver suspend()/resume() methods, but there's also something to be
> said for callbacks in certain contexts.

I'm not sure how the callback approach would work.  Fortunately so far
none of this has been needed in USB programming; only the host
controllers (PCI and non-PCI each in their own ways) have to worry
about it.  That might change in a more generalized setting; conceivably 
there could be multiple system power states in which USB devices are 
allowed to run.  Then the platform would need an interface to tell the 
USB subsystem whether the devices must be suspended in the new state.


> (*) "API" == "Application Programming Interface", a userspace thing.
>     So I avoid using that TLA for anything inside the OS kernel.

Strong agreement -- I abhor the term "API".  I use it because it is so 
convenient; "interface" is much longer and is overloaded with other 
meanings.

When you come down to it, "Application" is itself short for 
"Application Program" which AFAIK originated in Apple (that could 
easily be wrong).  But it is used to mean _any_ program, application or 
otherwise, and as such it is a misnomer.  Strictly speaking, utility 
programs aren't applications -- they are utilities.  Same goes for 
system management programs and other categories.  Remember MS-DOS and 
TSRs?  Or the old Mac OS and desk accessories?

So if a user library has an API, does that mean the library can't be 
used by utilities or other non-application programs?  :-)

Alan Stern

Re: Platform-specific system power states

[David Brownell]

On Thursday 21 June 2007, Alan Stern wrote:
> 
> I'd be perfectly happy to have the list of supported system power 
> states be exported by the platform code instead of predetermined by the 
> PM core.  It would still be necessary to add a method whereby the PM 
> core could inform the platform about the new target state at the 
> beginning of a state change.  And of course there would have to be a 
> way for drivers or subsystems to query the platform, to see what 
> resources would be available.

Rafael will propose the new method, I guess; and as for querying,
the many power-related resources involved would seem to be clocks
and power domains.  ACPI has an internal notion of the latter, but
skips the former.  You've seen my proposal for what seems to be
sufficient in the case of clocks.  (And one of these days I'm sure
I'll push it upstream.  After that new method lands, to replace
the now-missing functionality...)


> > > Perhaps something like this: Resource providers have an API whereby
> > > drivers can find out what resources either are currently available or
> > > will be available in the next system state (a little awkward to specify
> > > which is needed).  Then drivers decide on a new device state based on
> > > the type of change requested and the available resources, and notify
> > > the providers via a second API about any change in resource usage.
> > 
> > Resource providers have interfaces (*) they expose; yes.  *IF* those
> > resources change availability based on system states, there must be
> > interfaces drivers can use to notice that.  The providers already have
> > interfaces to manage resources, and won't need new cals for that. 
> > 
> > The calls to expose whether a given in-use resource must be released
> > or modified would be simplest if they're just query calls made by
> > driver suspend()/resume() methods, but there's also something to be
> > said for callbacks in certain contexts.
> 
> I'm not sure how the callback approach would work.

One old example comes from early "DPM" support.  When a system's
base clock rate changes, derived clocks may need to change.  When
that involves for example a USART clock, the external bit rate
must remain the same ... which means adjusting dividers.  In fact
it might even mean needing to reject proposed clock rate changes,
if they can't support the necessary frequency.


> Fortunately so far 
> none of this has been needed in USB programming; only the host
> controllers (PCI and non-PCI each in their own ways) have to worry
> about it.  That might change in a more generalized setting; conceivably 
> there could be multiple system power states in which USB devices are 
> allowed to run.  Then the platform would need an interface to tell the 
> USB subsystem whether the devices must be suspended in the new state.

The usual situation with USB is there are two modes other than
"fully operational".  One is where everything's suspended but
the USB functional clock is available.  (Maybe the register
interface isn't clocked though.)  The other is where that clock
isn't available.  In some cases that implies controller reset.
In other cases it doesn't; and if it doesn't, potentially the
key power session state can be maintained with help from the
PHY ... and, on the host side, something supplying VBUS.


> > (*) "API" == "Application Programming Interface", a userspace thing.
> >     So I avoid using that TLA for anything inside the OS kernel.
> 
> Strong agreement -- I abhor the term "API".  I use it because it is so 
> convenient; "interface" is much longer and is overloaded with other 
> meanings.

I recall Sun talking lots about a "Device Driver Interface" or DDI.
Presumably there are other names for such stuff.  I'm not sure any
better acronym could catch on.  ;)

 
> When you come down to it, "Application" is itself short for 
> "Application Program" which AFAIK originated in Apple (that could 
> easily be wrong).

I'm quite certain that terminology predates Apple by many decades!


> But it is used to mean _any_ program, application or  
> otherwise, and as such it is a misnomer.  Strictly speaking, utility 
> programs aren't applications -- they are utilities.  Same goes for 
> system management programs and other categories.  Remember MS-DOS and 
> TSRs?  Or the old Mac OS and desk accessories?
> 
> So if a user library has an API, does that mean the library can't be 
> used by utilities or other non-application programs?  :-)

Well, from the perspective of hardware *all* software is "application". :)

- Dave


 

Re: Re: Platform-specific system power states

[Rafael J. Wysocki]

On Friday, 22 June 2007 21:49, David Brownell wrote:
> On Thursday 21 June 2007, Alan Stern wrote:
> > 
> > I'd be perfectly happy to have the list of supported system power 
> > states be exported by the platform code instead of predetermined by the 
> > PM core.  It would still be necessary to add a method whereby the PM 
> > core could inform the platform about the new target state at the 
> > beginning of a state change.  And of course there would have to be a 
> > way for drivers or subsystems to query the platform, to see what 
> > resources would be available.
> 
> Rafael will propose the new method, I guess;

Yes, I will.

Still, for now, I'm going to make it take an integer argument equal to either
PM_SUSPEND_STANDBY or PM_SUSPEND_MEM, since these are the only two sleep states
known to the core right now.

I think, however, that in the long run the better solution would be to make
the platform tell the PM core, during the initialization, what system sleep
states are available.  Then, before the transition, the PM core will tell the
platform which state is the target one.  IMO for this purpose the sleep will
need to be identified in a universal way and perhaps it's a good idea to
discuss that for a while. ;-)

> and as for querying, the many power-related resources involved would seem to
> be clocks and power domains.  ACPI has an internal notion of the latter, but 
> skips the former.  You've seen my proposal for what seems to be sufficient in
> the case of clocks.  (And one of these days I'm sure I'll push it upstream.
> After that new method lands, to replace the now-missing functionality...)

In fact the ACPI spec regards clock sources as power resources.  More
precisely, it defines a power resource as "resources (for example, power planes
and clock sources) that a device requires to operate in a given power state"
(Section 2.1 in the 3.0b spec).  Perhaps we also could use a general notion of
"power resource" in a similar fashion?

Greetings,
Rafael


-- 
"Premature optimization is the root of all evil." - Donald Knuth

Re: Re: Platform-specific system power states

[Alan Stern]

On Fri, 22 Jun 2007, Rafael J. Wysocki wrote:

> On Friday, 22 June 2007 21:49, David Brownell wrote:
> > On Thursday 21 June 2007, Alan Stern wrote:
> > > 
> > > I'd be perfectly happy to have the list of supported system power 
> > > states be exported by the platform code instead of predetermined by the 
> > > PM core.  It would still be necessary to add a method whereby the PM 
> > > core could inform the platform about the new target state at the 
> > > beginning of a state change.  And of course there would have to be a 
> > > way for drivers or subsystems to query the platform, to see what 
> > > resources would be available.
> > 
> > Rafael will propose the new method, I guess;
> 
> Yes, I will.
> 
> Still, for now, I'm going to make it take an integer argument equal to either
> PM_SUSPEND_STANDBY or PM_SUSPEND_MEM, since these are the only two sleep states
> known to the core right now.
> 
> I think, however, that in the long run the better solution would be to make
> the platform tell the PM core, during the initialization, what system sleep
> states are available.  Then, before the transition, the PM core will tell the
> platform which state is the target one.  IMO for this purpose the sleep will
> need to be identified in a universal way and perhaps it's a good idea to
> discuss that for a while. ;-)

A good way to identify a sleep state would be a pointer to a string 
containing the state's name.  The PM core could use these pointers to 
export the states in sysfs.

Alan Stern

Re: Re: Platform-specific system power states

[Rafael J. Wysocki]

On Saturday, 23 June 2007 03:32, Alan Stern wrote:
> On Fri, 22 Jun 2007, Rafael J. Wysocki wrote:
> 
> > On Friday, 22 June 2007 21:49, David Brownell wrote:
> > > On Thursday 21 June 2007, Alan Stern wrote:
> > > > 
> > > > I'd be perfectly happy to have the list of supported system power 
> > > > states be exported by the platform code instead of predetermined by the 
> > > > PM core.  It would still be necessary to add a method whereby the PM 
> > > > core could inform the platform about the new target state at the 
> > > > beginning of a state change.  And of course there would have to be a 
> > > > way for drivers or subsystems to query the platform, to see what 
> > > > resources would be available.
> > > 
> > > Rafael will propose the new method, I guess;
> > 
> > Yes, I will.
> > 
> > Still, for now, I'm going to make it take an integer argument equal to either
> > PM_SUSPEND_STANDBY or PM_SUSPEND_MEM, since these are the only two sleep states
> > known to the core right now.
> > 
> > I think, however, that in the long run the better solution would be to make
> > the platform tell the PM core, during the initialization, what system sleep
> > states are available.  Then, before the transition, the PM core will tell the
> > platform which state is the target one.  IMO for this purpose the sleep will
> > need to be identified in a universal way and perhaps it's a good idea to
> > discuss that for a while. ;-)
> 
> A good way to identify a sleep state would be a pointer to a string 
> containing the state's name.  The PM core could use these pointers to 
> export the states in sysfs.

Well, I thought of exactly the same thing.

Perhaps we can generalize it a bit by defining:

struct pm_sleep_state {
	char *name;
};

and make the platforms give us a NULL-terminated array of such things during
the initializatiion.

Then, if it turns out to be convenient to add another field to this structure,
there won't be any problems with that.  Also, the platforms will be able to
embed a struct pm_sleep_state in their internal structures representing system
sleep states, if need be.

Greetings,
Rafael


-- 
"Premature optimization is the root of all evil." - Donald Knuth

Re: Re: Platform-specific system power states

[David Brownell]

On Saturday 23 June 2007, Rafael J. Wysocki wrote:
> On Saturday, 23 June 2007 03:32, Alan Stern wrote:

> > A good way to identify a sleep state would be a pointer to a string 
> > containing the state's name.  The PM core could use these pointers to 
> > export the states in sysfs.
> 
> Well, I thought of exactly the same thing.

There's an echo in the room ...


> Perhaps we can generalize it a bit by defining:
> 
> struct pm_sleep_state {
> 	char *name;
> };

I suppose having the core use only the name would be a bit radical;
but on the other hand, I really like the resulting notion that the
generic code must accordingly know *NOTHING* about the semantics
of any such states.  Having a struct sort of begs that it someday
be expanded.


> and make the platforms give us a NULL-terminated array of such things during
> the initializatiion.

And conceptually "typedef struct pm_sleep_state *suspend_state_t;"?
Though eventually "suspend_state_t" should vanish.

- Dave

Re: Re: Platform-specific system power states

[Rafael J. Wysocki]

On Monday, 25 June 2007 02:10, David Brownell wrote:
> On Saturday 23 June 2007, Rafael J. Wysocki wrote:
> > On Saturday, 23 June 2007 03:32, Alan Stern wrote:
> 
> > > A good way to identify a sleep state would be a pointer to a string 
> > > containing the state's name.  The PM core could use these pointers to 
> > > export the states in sysfs.
> > 
> > Well, I thought of exactly the same thing.
> 
> There's an echo in the room ...
> 
> 
> > Perhaps we can generalize it a bit by defining:
> > 
> > struct pm_sleep_state {
> > 	char *name;
> > };
> 
> I suppose having the core use only the name would be a bit radical;
> but on the other hand, I really like the resulting notion that the
> generic code must accordingly know *NOTHING* about the semantics
> of any such states.  Having a struct sort of begs that it someday
> be expanded.

Still, so to speak, the struct is self-commenting (to some extent), and the
'bare' string might be confusing in some contexts.

> > and make the platforms give us a NULL-terminated array of such things during
> > the initializatiion.
> 
> And conceptually "typedef struct pm_sleep_state *suspend_state_t;"?

More or less.

> Though eventually "suspend_state_t" should vanish.

Well ...

Greetings,
Rafael


-- 
"Premature optimization is the root of all evil." - Donald Knuth

Re: Re: Platform-specific system power states

[David Brownell]

On Friday 22 June 2007, Rafael J. Wysocki wrote:
> On Friday, 22 June 2007 21:49, David Brownell wrote:

> > and as for querying, the many power-related resources involved would seem to
> > be clocks and power domains.  ACPI has an internal notion of the latter, but 
> > skips the former.  You've seen my proposal for what seems to be sufficient in
> > the case of clocks.  (And one of these days I'm sure I'll push it upstream.
> > After that new method lands, to replace the now-missing functionality...)
> 
> In fact the ACPI spec regards clock sources as power resources.  More
> precisely, it defines a power resource as "resources (for example, power planes
> and clock sources) that a device requires to operate in a given power state"
> (Section 2.1 in the 3.0b spec).  Perhaps we also could use a general notion of
> "power resource" in a similar fashion?

The problem with claiming that ACPI has a notion of clocks is that it
doesn't have any clock-like semantics.  Like getting/setting rates,
reparenting, and so forth ... everything the clk_*() interfaces do.
At best it has "stuff that can be enabled/disabled".


Related:  Linux doesn't even expose the limited notion of power resource
that ACPI packages.  And, as shown by some comments on one patch I posted,
even that notion needs work before it behaves.  ISTR the issue was that
the ACPI power methods apply to PCI functions, but the resources applied
to PCI devices.  So in the absense of refcounting, powering down one
function would surprisingly enough power them all down... absolutely
contrary to the intent of powering down just that function.

There's probably some generalizable notion lurking there, but clearly it's
not cooked in today's Linux ACPI stack.

And suffice it to say that I've seen work with such "general notions"
blow up so regularly (the basic crime being loss of contact with real
world problems, leading to useless code bloat) that my first reaction
is almost always "no, don't generalize yet, solve some problems first".

Hence my ongoing belief that we need voltage abstractions (both producer
and consumer) resembling the current clock abstraction, before we start
to think about grouping the two under some umbrella.

- Dave

Re: Re: Platform-specific system power states

[Rafael J. Wysocki]

On Monday, 25 June 2007 02:26, David Brownell wrote:
> On Friday 22 June 2007, Rafael J. Wysocki wrote:
> > On Friday, 22 June 2007 21:49, David Brownell wrote:
> 
> > > and as for querying, the many power-related resources involved would seem to
> > > be clocks and power domains.  ACPI has an internal notion of the latter, but 
> > > skips the former.  You've seen my proposal for what seems to be sufficient in
> > > the case of clocks.  (And one of these days I'm sure I'll push it upstream.
> > > After that new method lands, to replace the now-missing functionality...)
> > 
> > In fact the ACPI spec regards clock sources as power resources.  More
> > precisely, it defines a power resource as "resources (for example, power planes
> > and clock sources) that a device requires to operate in a given power state"
> > (Section 2.1 in the 3.0b spec).  Perhaps we also could use a general notion of
> > "power resource" in a similar fashion?
> 
> The problem with claiming that ACPI has a notion of clocks is that it
> doesn't have any clock-like semantics.  Like getting/setting rates,
> reparenting, and so forth ... everything the clk_*() interfaces do.
> At best it has "stuff that can be enabled/disabled".

I think the idea in the spec is similar to how fans are treated by ACPI (they
can only be 'on' or 'off' and if you have one fan with two speeds, you need to
define two 'logical fans' to describe the physical one etc.).


> Related:  Linux doesn't even expose the limited notion of power resource
> that ACPI packages.  And, as shown by some comments on one patch I posted,
> even that notion needs work before it behaves.  ISTR the issue was that
> the ACPI power methods apply to PCI functions, but the resources applied
> to PCI devices.  So in the absense of refcounting, powering down one
> function would surprisingly enough power them all down... absolutely
> contrary to the intent of powering down just that function.
> 
> There's probably some generalizable notion lurking there, but clearly it's
> not cooked in today's Linux ACPI stack.

Agreed.

> And suffice it to say that I've seen work with such "general notions"
> blow up so regularly (the basic crime being loss of contact with real
> world problems, leading to useless code bloat) that my first reaction
> is almost always "no, don't generalize yet, solve some problems first".
> 
> Hence my ongoing belief that we need voltage abstractions (both producer
> and consumer) resembling the current clock abstraction, before we start
> to think about grouping the two under some umbrella.

Still, we'd need to take the ACPIish way of treating power resources into
consideration somehow.

Greetings,
Rafael


-- 
"Premature optimization is the root of all evil." - Donald Knuth