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

[Rafael J. Wysocki]

On Sunday 21 June 2009, Alan Stern wrote:
> On Sun, 21 Jun 2009, Rafael J. Wysocki wrote:
> 
> > 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.
> 
> Good idea.  pm_runtime_resume_atomic() and pm_runtime_suspend_atomic().  
> No need for _request variants since the status should never be 
> RPM_SUSPENDING or RPM_RESUMING while the lock is released.

Yes, exactly.  I also thought of the same names. :-)

> > > 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?
> 
> By mistake.  :-)
> 
> Seriously, there _are_ places where drivers get bound to device before
> those devices are registered.  This happens for example in USB when a
> bunch of related interfaces are present in the same physical device.  
> When the first interface is registered, its driver binds itself to all
> the others even though they haven't been registered yet.

Well, the suspend functions could be protected against that under the
assumption that no suspend is possible for resume_counter = 0 (then, the "good
to go" value would be -1).

Still, the resume functions start from acquring a spinlock, which is not going
to work if that spinlock is uninitialized.

Best,
Rafael
--
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/