Re: Questions about run time power management

[Alan Stern <stern@rowland.harvard.edu>]

On Wed, 28 Jul 2010, Raj Kumar wrote:

> Hi ALan,
> 
>  
> 
> 1) As you mentioned that -EBUSY code is appropriate, But if the
> 
> device started doing activities during that time then it is not appropriate
> 
> to check every time if device is idle.
> 
>  
> 
> Because if -EBUSY is returned, then workqueue thread will check again and again
> 
> that if the device is idle.
> 
>  
> 
>         if (notify)
>                 __pm_runtime_idle(dev);
> 
> 
> That is notify flag will be true. right?

Yes.  But the thread won't check again and again; it will check only
once.  Your runtime_idle callback will know that the device is busy,
and therefore it won't schedule another suspend on the workqueue.  Not 
until the device really becomes idle again.

> 2) The 2nd thing is use case of deep sleep state i.e. system suspend.
> 
>  
> 
> Suppose device is active and its run time status is active. Now when the system suspend 
> 
> happens, it will increment usage_counter of device in power management framework,
> 
>  
> 
> now at that time since clocks and power are enabled, So what will device do?

It will continue running normally until the driver's suspend callback
is invoked.

> My point is when system suspend comes to device and device is doing activities at that time,
> 
> if the device will ask run time power management to shut its clock off and make it suspended,
> 
>  
> 
> and then it respond to system suspend????

The _device_ doesn't do any of these things; the _driver_ does them.

During system suspend, the driver has to shut off the clock and suspend
the device.  It can't do these things by using runtime PM calls; it has
to do them some other way.

> Run time power management will not do at the time as its usage counter is already increased,
> 
>  
> 
> Right? so what about this use case when this kind of overlapping occurs?

Right.  During system suspend, the driver has to do its job without
using runtime PM.

Alan Stern