Hi Alan, [Re-adding Kevin] On Wed, May 13, 2009 at 11:12 PM, Alan Stern <stern@xxxxxxxxxxxxxxxxxxx> wrote: > On Wed, 13 May 2009, Magnus Damm wrote: > >> Hi everyone, >> >> What is the future plan for dev->status.power? Right now it seems to >> reflect the upcoming internal software state of each device when >> performing suspend and resume. The attached picture may clarify things >> if it makes it to the list. >> >> I'm a bit interested in modifying dev->status.power to reflect the >> current device power state. Basically getting rid of DPM_PREPARING, >> DPM_RESUMING, DPM_SUSPENDING and DPM_OFF_NOIRQ (they seem to be fairly >> unused anyway), > > "Fairly unused" is very different from "completely unused". Please > don't get rid of them. I understand that USB is using dev->power.status for power management. USB power management very is good to have, so I have no intention in breaking that. =) >> and instead using the following states: >> >> DPM_ON - default operational state >> DPM_FROZEN - set after PMSG_FREEZE >> DPM_OFF - set after PMSG_HIBERNATE >> DPM_SUSPENDED - set after PMSG_SUSPEND > > Is there any reason for making this change? > >> On top of this I'd like to allow device drivers to mark devices as >> idle. And if a device is marked idle then I'd like to allow power >> management code to perform freeze() on a single device. After that >> marking the device frozen using DPM_FROZEN. poweroff() may also be >> called to perform some partial system suspend. It gets more >> complicated of course, but I guess we need a way to know the state of >> each device regardless. >> >> Any comments? > > It sounds like you're trying to resuscitate the proposals for > centralized device power management from several years ago. The idea > was abandoned because there was no way to make it work. And there's no > reason to think the situation is any different now. So let's look at it from a different angle then. Today there are many SoCs on the market from multiple vendors, and they all need to be power managed somehow. Upstream linux is not very good at it, some vendors have many out-of-tree patches for these things. For SuperH we have no power management code out-of-tree so _now_ we have a good chance of implementing something upstream that multiple architectures can make use of. Paul Walmsley, Kevin Hilman and I discussed this during last Embedded Linux Conference last month. From architecture perspective both Arm and SuperH need to be able enter deep sleep states. For this to happen we need the ability to save and restore device context during run time. Do you have any recommendation for us? Thank you! / magnus _______________________________________________ linux-pm mailing list linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/linux-pm
