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
--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
