On Wed, May 27, 2009 at 11:30 PM, Alan Stern <stern@xxxxxxxxxxxxxxxxxxx> wrote: > On Wed, 27 May 2009, Magnus Damm wrote: >> PM: Runtime platform device power management > Have you given any thought as to whether the platform_device_wakeup and > platform_device_idle calls should be restricted to process context? Good question. The first thing that pops into my mind is to have same restrictions as clk_enable() and clk_disable(). To keep things simple I'd say that it's unlikely that any embedded platform driver would need to sleep during the dev_pm_ops callbacks. Maybe it makes sense to only allow _noirq variants of dev_pm_ops, not sure. Any ideas? > You should consider using a special workqueue for this stuff instead of > relying on the default workqueue. It can help avoid deadlocks, and it > has the advantage that you can define the workqueue to be freezable. > (Generally speaking, you don't want platform-level wakeup and idle > calls to start running spontaneously in the middle of a system sleep > transition.) Yeah, the mockup code needs more work. =) For SuperH Mobile I suspect that we don't need any workqueues since the freeze() and disabling of power has to be done from cpuidle context. For SoCs with more complex power domain layouts it may make sense handle each power domain independently. And on top of this we probably want to have some QoS information so the runtime pm code can chose which device sleep mode to enter. Like cpuidle but for devices or power domains. Thanks for your comments! / magnus _______________________________________________ linux-pm mailing list linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/linux-pm
