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

[Alan Stern]

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

--
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/