On Mon, 8 Jun 2009, Rafael J. Wysocki wrote: > On Monday 08 June 2009, Oliver Neukum wrote: > > Am Sonntag, 7. Juni 2009 23:46:59 schrieb Rafael J. Wysocki: > > > It may be necessary to resume a device synchronously, but I'm still > > > thinking how to implement that. > > > > This will absolutely be the default. You resume a device because you want > > it to do something now. It seems to me that you making your problem worse > > by using a spinlock as a lock. A mutex would make it easier. > > But I need to be able to call __pm_schedule_resume() (at least) from interrupt > context and I can't use a mutex from there. Otherwise I'd have used a mutex. :-) > > Anyway, below is a version with synchronous resume. There are a few things here which need further thought: The implementation of pm_lock_device() assumes it will never be called with interrupts disabled. This is a bad assumption. Use of the RPM_UNKNOWN state isn't good. A bus may have valid reasons of its own for not carrying out an autosuspend. When this happens the device's state isn't unknown. The scheme doesn't include any mechanism for communicating runtime power information up the device tree. When a device is autosuspended, its parent's driver should be told so that the driver can consider autosuspending the parent. Likewise, if we want to autoresume a device below an autosuspended parent, the parent should be autoresumed first. Did you want to make the bus subsystem responsible for all of this? What about device's whose parent belongs to a different subsystem? There should be a sysfs interface (like the one in USB) to allow userspace to prevent a device from being autosuspended -- and perhaps also to force it to be suspended. What about devices that have more than two runtime power states? For example, you can't squeeze PCI's {D0,D1,D2,D3hot} range into {running, suspended}. That's what I come up with on a first reading. There may be more later on... :-) Alan Stern _______________________________________________ linux-pm mailing list linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/linux-pm