Re: [linux-pm] [patch update 2 fix] PM: Introduce core framework for run-time PM of I/O devices

Alan Stern
2009-06-20T14:30:56Z

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.

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?

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.

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.

Alan Stern