Re: [linux-pm] [patch update 2 fix] PM: Introduce core framework for run-time PM of I/O devices
From: Rafael J. Wysocki
Date: Sat Jun 20 2009 - 19:48:29 EST
On Saturday 20 June 2009, Alan Stern wrote:
> Some more thoughts...
> Magnus, you might have some insights here. It occurred to me that some
> devices can switch power levels very quickly, and the drivers might
> therefore want the runtime suspend and resume methods to be called as
> soon as possible, even in interrupt context.
Then, we'll need special suspend and resume calls for them.
> In terms of the current framework, this probably means holding the
> runtime PM lock (i.e., not releasing it) across the calls to
> ->runtime_suspend and ->runtime_resume. It also means that
> pm_request_suspend and pm_request_resume should carry out their jobs
> immediately instead of queuing a work item. (Unless the current status
> is RPM_SUSPENDING or RPM_RESUMING, which should never happen.)
> Should there be a flag in dev_pm_info to select this behavior?
I don't think we should complicate pm_request_suspend() and pm_request_resume()
further to handle this particular case. IMO it's better to provide separate
core calls for that.
> When a device structure is unregistered and deallocated, we have to
> insure that there aren't any pending runtime PM workqueue items.
> Hence device_del should call a routine that changes the status to an
> exceptional state (not RPM_ERROR but something else) to prevent new
> requests from being queued, and then calls cancel_work_sync or
> cancel_delayed_work_sync as required.
This is done in the patch I've just sent.
> Similarly, we should insure that runtime PM calls made before the
> device is registered don't do anything. So when the device structure
> is first created and the contents are all 0, this should also be
> interpreted as an exceptional state. We could call it RPM_UNREGISTERED
> and use it for both purposes.
Hmm. How do you think is possible that the pm_runtime_* functions will be
called in such a situation?
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/