On Thu, 2007-03-22 at 11:13 -0700, David Brownell wrote: > Look at docs for most any SOC processor and you'll see that > not only does it have a variety of lowpower states, but that > each of them has various rules about what works there and > what doesn't. > > So long as driver suspend() methods have no some way to see > how far they "must" shut down for a given target sleep state, > there is only limited utility to defining such states. Oh ok, yeah, I see. > That's because the state would only really apply to the cpu > specific code ... drivers must assume the worst case, precluding > the primary reasons to use those less-deep system states. Right. That's a thing we'd have to fix in the interface to drivers to tell them which state we're entering. But that can also get hairy since the same device driver might support devices that are built into different systems and might support different things there by being hooked up differently.... > I just reposted my clk_must_disable() patches; I think it's time > to merge them. They address that issue for one of the most > common type of rule for system sleep states ... at least, in > terms of interface. Platform support will still be an issue, > but at least the issue won't be "crippled by bad design". I can't speak for any of that, I haven't ever worked with PM on anything not looking like a big desktop or at least laptop. In any case, I didn't intend to fix up all that or even make it possible, so far all I wanted was to clean up the mess surrounding pm_ops even as it is currently defined (though it wasn't really well-documented which probably led to the mess, I had to read the code to understand it, I had no part in writing it.) johannes
Attachment:
signature.asc
Description: This is a digitally signed message part
_______________________________________________ linux-pm mailing list linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/linux-pm
