Questions about run time power management

Questions about run time power management

[Raj Kumar]

[-- Attachment #1.1: Type: text/plain, Size: 1050 bytes --]




Hi,


I am implementing the run time power management in my drivers. So i have the following
questions:


1) I am using the work queue approach for run time power management, Now the thing is
when the device is idle and it notifies the run time power management via helper function
pm_request_idle, and at the same time if resume is done then in that case does the runtime power management
cancels the idle and does not invoke any callback like runtime_suspend of driver? 


2) like as mentioned in run time power management document, when the usage_count of device
reaches zero, is there any run time power management thread in background that will immediately suspends
the device or it is again via helper functions. It seems from the code that usage_count is zero and suspended
via helper functions. Is it correct?


3) The third question is more specific about platform bus usage? can the char device driver use platform bus?
can char device register as platform device?


Regards
raj




     
 
 		 	   		  

[-- Attachment #1.2: Type: text/html, Size: 1313 bytes --]

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

Re: Questions about run time power management

[Alan Stern]

On Fri, 23 Jul 2010, Raj Kumar wrote:

> Hi,
> 
> 
> I am implementing the run time power management in my drivers. So i have the following
> questions:
> 
> 
> 1) I am using the work queue approach for run time power management, Now the thing is
> when the device is idle and it notifies the run time power management via helper function
> pm_request_idle, and at the same time if resume is done then in that case does the runtime power management
> cancels the idle and does not invoke any callback like runtime_suspend of driver? 

How can a resume occur while the device is idle?  Idle means that the 
device isn't suspended -- it's at full power but not doing anything.  
Hence a resume cannot occur at the same time.

> 2) like as mentioned in run time power management document, when the usage_count of device
> reaches zero, is there any run time power management thread in background that will immediately suspends
> the device or it is again via helper functions. It seems from the code that usage_count is zero and suspended
> via helper functions. Is it correct?

All suspends occur via the helper functions, whether a background 
thread is involved or not.

> 3) The third question is more specific about platform bus usage? can the char device driver use platform bus?
> can char device register as platform device?

Yes.  Devices can be registered on any bus.

Alan Stern

Re: Questions about run time power management

[Raj Kumar]

[-- Attachment #1.1: Type: text/plain, Size: 2977 bytes --]


Hi Alan,

 

Please see my following points:

 

 Suppose when device is idle, it says to run time power management framework i am idle

and run time power management asks the device's bus (if bus is being used), and 

probably the case is if the device does not want to get suspended because of the starting

of the activities immediately , it will return the error to platform bus and platform bus returns this error

to run time power management framework and run time power management will make

the device status active. In the code of 

 

int  __pm_runtime_suspend(arguments...)

{


 

  if (retval) {
                dev->power.runtime_status = RPM_ACTIVE;
                pm_runtime_cancel_pending(dev);

                if (retval == -EAGAIN || retval == -EBUSY) {
                        notify = true;
                        dev->power.runtime_error = 0;
                }
        } else {


 

}

 

So if the retval is -EAGAIN and -EBUSY,  so it means it will again try to make it idle but if the device is

already doing activities , since it is started doing activities then in that case is this error code

ECANCELED is appropriate?

 

Regards

Raj

 

 

 

 

 

 
> Date: Fri, 23 Jul 2010 10:26:07 -0400
> From: stern@rowland.harvard.edu
> To: rajkumar278@hotmail.com
> CC: linux-pm@lists.linux-foundation.org
> Subject: Re: [linux-pm] Questions about run time power management
> 
> On Fri, 23 Jul 2010, Raj Kumar wrote:
> 
> > Hi,
> > 
> > 
> > I am implementing the run time power management in my drivers. So i have the following
> > questions:
> > 
> > 
> > 1) I am using the work queue approach for run time power management, Now the thing is
> > when the device is idle and it notifies the run time power management via helper function
> > pm_request_idle, and at the same time if resume is done then in that case does the runtime power management
> > cancels the idle and does not invoke any callback like runtime_suspend of driver? 
> 
> How can a resume occur while the device is idle? Idle means that the 
> device isn't suspended -- it's at full power but not doing anything. 
> Hence a resume cannot occur at the same time.
> 
> > 2) like as mentioned in run time power management document, when the usage_count of device
> > reaches zero, is there any run time power management thread in background that will immediately suspends
> > the device or it is again via helper functions. It seems from the code that usage_count is zero and suspended
> > via helper functions. Is it correct?
> 
> All suspends occur via the helper functions, whether a background 
> thread is involved or not.
> 
> > 3) The third question is more specific about platform bus usage? can the char device driver use platform bus?
> > can char device register as platform device?
> 
> Yes. Devices can be registered on any bus.
> 
> Alan Stern
> 
 		 	   		  

[-- Attachment #1.2: Type: text/html, Size: 4159 bytes --]

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

Re: Questions about run time power management

[Alan Stern]

On Sat, 24 Jul 2010, Raj Kumar wrote:

> Hi Alan,
> 
>  
> 
> Please see my following points:
> 
>  
> 
>  Suppose when device is idle, it says to run time power management framework i am idle
> 
> and run time power management asks the device's bus (if bus is being used), and 
> 
> probably the case is if the device does not want to get suspended because of the starting
> 
> of the activities immediately , it will return the error to platform bus and platform bus returns this error
> 
> to run time power management framework and run time power management will make
> 
> the device status active. In the code of 
> 
>  
> 
> int  __pm_runtime_suspend(arguments...)
> 
> {
> 
> 
>  
> 
>   if (retval) {
>                 dev->power.runtime_status = RPM_ACTIVE;
>                 pm_runtime_cancel_pending(dev);
> 
>                 if (retval == -EAGAIN || retval == -EBUSY) {
>                         notify = true;
>                         dev->power.runtime_error = 0;
>                 }
>         } else {
> 
> 
>  
> 
> }
> 
>  
> 
> So if the retval is -EAGAIN and -EBUSY,  so it means it will again try to make it idle but if the device is
> 
> already doing activities , since it is started doing activities then in that case is this error code
> 
> ECANCELED is appropriate?

No.  -EBUSY is more appropriate, since the device is busy.

Alan Stern

Re: Questions about run time power management

[Raj Kumar]

[-- Attachment #1.1: Type: text/plain, Size: 2913 bytes --]


 

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?

 

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?

 

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

 

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?

 

Regards

Raj 

 

 

 

 


 
> Date: Sun, 25 Jul 2010 11:48:34 -0400
> From: stern@rowland.harvard.edu
> To: rajkumar278@hotmail.com
> CC: linux-pm@lists.linux-foundation.org
> Subject: RE: [linux-pm] Questions about run time power management
> 
> On Sat, 24 Jul 2010, Raj Kumar wrote:
> 
> > Hi Alan,
> > 
> > 
> > 
> > Please see my following points:
> > 
> > 
> > 
> > Suppose when device is idle, it says to run time power management framework i am idle
> > 
> > and run time power management asks the device's bus (if bus is being used), and 
> > 
> > probably the case is if the device does not want to get suspended because of the starting
> > 
> > of the activities immediately , it will return the error to platform bus and platform bus returns this error
> > 
> > to run time power management framework and run time power management will make
> > 
> > the device status active. In the code of 
> > 
> > 
> > 
> > int __pm_runtime_suspend(arguments...)
> > 
> > {
> > 
> > 
> > 
> > 
> > if (retval) {
> > dev->power.runtime_status = RPM_ACTIVE;
> > pm_runtime_cancel_pending(dev);
> > 
> > if (retval == -EAGAIN || retval == -EBUSY) {
> > notify = true;
> > dev->power.runtime_error = 0;
> > }
> > } else {
> > 
> > 
> > 
> > 
> > }
> > 
> > 
> > 
> > So if the retval is -EAGAIN and -EBUSY, so it means it will again try to make it idle but if the device is
> > 
> > already doing activities , since it is started doing activities then in that case is this error code
> > 
> > ECANCELED is appropriate?
> 
> No. -EBUSY is more appropriate, since the device is busy.
> 
> Alan Stern
> 
 		 	   		  

[-- Attachment #1.2: Type: text/html, Size: 3887 bytes --]

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

Re: Questions about run time power management

[Alan Stern]

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