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
