Re: [linux-pm] 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 <david-b@pacbell.net>]

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.

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.
(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...)


> Right now 
> there's no way for that information to get from the PM core to the
> provider other than pm_message_t, and the pm_message_t will generally
> be passed to the provider _after_ it is passed to the lower-level
> drivers.

No, providers don't get a pm_message_t ... that goes to drivers.


> 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?
Is there any way that driver code could ever make use of such
a suspend_state_t value?


> There are other possible ways to disseminate the information.  The 
> details don't matter much, and relatively few drivers would care.  
> However the form of the information is a legitimate concern at this 
> point.

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.

The same PCI chip may need to act very differently based on whether
the system uses ACPI (or not), and how it's wired on that particular
mainboard.  That's platform-specific behavior which is not coupled
directly to a sleep state.

- Dave


-
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html