On Saturday 22 July 2006 8:59 pm, Alan Stern wrote: > On Sat, 22 Jul 2006, David Brownell wrote: > > > In short that's kind of a mess. IMO the correct approach involves removing > > the dev->power.power_state thing entirely, along with the sysfs thing, but > > we can't do that quite yet. > > Then what _can_ we do now? Or better yet, what _should_ we aim towards > doing? I'm perfectly happy to have those things removed, but what (if > anything) should take their place? Remove both, replace with nothing generic ... my $US 0.02. You will have noticed the patch I sent to add a config option to remove the /sys/devices/.../power/state files; that can start phasing out soon. Removing power_state can be done over time. Some busses could provide bus-specific replacements ... PCI and USB, not I2C or SPI, as examples. I can't really argue any reason to make such a replacement though, other than for testing. > Some simple questions may help start the ball rolling. During a system > resume, should all devices be powered on full, or should they be restored > to the state they were in before the suspend? I'd say the answer is bus- or driver-specific, but lean towards the latter. Though it's not clear how the PM core could tell about runtime states, since I also think those should be driver-internal ... so how could anyone tell the difference? And for that matter, what is a "system resume" on systems that aren't as simple as PCs? E.g. when there are multiple run modes, there's no reason to expect the post-resume mode to be the same as the pre-suspend one and thus have e.g. the same clocks and voltages available ... neither "all on full" nor "all on as before suspend" make sense everywhere. > Or should there be a third > possibility -- maybe some devices always on, others the way they were? > And who decides? The driver? A given system should be able to provide the answer appropriate for its applications. Example, if it's woken up by a given device, maybe that's the only non-system device that _needs_ to be activated ... > For that matter, to what extent does the PM core need to be involved in > runtime power management? Hardly at all, in my book. As I wrote in that revised devices.txt... see that for more info. (That's written to reflect the status quo.) Different problem domains can have their own hooks ... there's not a lot of really generic stuff, since the problem domains are so varied. > As far as I can see, all the core can do is > provide centralized routines that would be widely useful. But apart from > something resembling the current sysfs interface, I can't see what those > routines might do. See above ... I consider the current /sys/devices/.../power/state interface irredeemably broken. Which leaves nothing generic enough for the core, at least in terms of mechanisms needed/used by Linux today. - Dave
