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)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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

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

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

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

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

Alan Stern

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

[Index of Archives]     [Linux IBM ACPI]     [Linux Power Management]     [Linux Kernel]     [Linux Laptop]     [Kernel Newbies]     [Share Photos]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Samba]     [Video 4 Linux]     [Device Mapper]     [Linux Resources]

  Powered by Linux