About run time power management in linux

About run time power management in linux

[Raj Kumar]

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



Hi,

I am working in power management. I have few questions about run time power management which was merged in linux 2.6.32 kernel onwards. 

 

Since the run time power management defines that when idle, suspend and resume will be scheduled, now the thing is from device driver perspective, 

 

it is bus driver that will suspend and resume its devices. but what from driver perspective driver needs to implement means as run time power management 

 

has also helper functions which will tell PM core that when to call various callbacks for suspend and resume for drivers (device, bus). 

 

But it might be case when the whole bus is not idle and still some drivers can be put into low power mode. 

 

Then does bus driver will be responsible for invoking the driver's suspend and resume (run time) or PM core will do that ? 

 

Use cases:

------------

 

 1) When the bus is idle

 

2) When the bus is not idle but still some peripherals can be put into low power mode...... 

 

 

Regards

Raj
 		 	   		  

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

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

Re: About run time power management in linux

[Alan Stern]

Please fix your email client to wrap lines after about 72 columns and 
not to insert excess blank lines.

On Wed, 30 Jun 2010, Raj Kumar wrote:

> Hi,
> 
> I am working in power management. I have few questions about run time power management which was merged in linux 2.6.32 kernel onwards. 
> 
>  
> 
> Since the run time power management defines that when idle, suspend and resume will be scheduled, now the thing is from device driver perspective, 
> 
>  
> 
> it is bus driver that will suspend and resume its devices. but what from driver perspective driver needs to implement means as run time power management 
> 
>  
> 
> has also helper functions which will tell PM core that when to call various callbacks for suspend and resume for drivers (device, bus). 
> 
>  
> 
> But it might be case when the whole bus is not idle and still some drivers can be put into low power mode. 
> 
>  
> 
> Then does bus driver will be responsible for invoking the driver's suspend and resume (run time) or PM core will do that ? 

The PM core will invoke the bus driver's runtime_idle, runtime_suspend,
and runtime_resume callback functions.  These functions are then
responsible for invoking the device driver's suspend and resume 
routines.

Alan Stern

Re: About run time power management in linux

[Raj Kumar]

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


 

Hi Alan,

 

First thanks for reply.  ok as also seems to be in runtime.c, if device wants to suspend and resume

 

then device will call helper functions for pm core like pm_runtime_suspend and pm_runtime_resume,

 

which internally calls the runtime_resume of the bus and which in turn calls the runtime_resume of the driver.

 

correct ?

 

Regards

Raj

 

 


 
> Date: Wed, 30 Jun 2010 10:23:41 -0400
> From: stern@rowland.harvard.edu
> To: rajkumar278@hotmail.com
> CC: linux-pm@lists.linux-foundation.org
> Subject: Re: [linux-pm] About run time power management in linux
> 
> Please fix your email client to wrap lines after about 72 columns and 
> not to insert excess blank lines.
> 
> On Wed, 30 Jun 2010, Raj Kumar wrote:
> 
> > Hi,
> > 
> > I am working in power management. I have few questions about run time power management which was merged in linux 2.6.32 kernel onwards. 
> > 
> > 
> > 
> > Since the run time power management defines that when idle, suspend and resume will be scheduled, now the thing is from device driver perspective, 
> > 
> > 
> > 
> > it is bus driver that will suspend and resume its devices. but what from driver perspective driver needs to implement means as run time power management 
> > 
> > 
> > 
> > has also helper functions which will tell PM core that when to call various callbacks for suspend and resume for drivers (device, bus). 
> > 
> > 
> > 
> > But it might be case when the whole bus is not idle and still some drivers can be put into low power mode. 
> > 
> > 
> > 
> > Then does bus driver will be responsible for invoking the driver's suspend and resume (run time) or PM core will do that ? 
> 
> The PM core will invoke the bus driver's runtime_idle, runtime_suspend,
> and runtime_resume callback functions. These functions are then
> responsible for invoking the device driver's suspend and resume 
> routines.
> 
> Alan Stern
> 
 		 	   		  

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

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

Re: About run time power management in linux

[Alan Stern]

On Wed, 30 Jun 2010, Raj Kumar wrote:

> Hi Alan,
> 
>  
> 
> First thanks for reply.  ok as also seems to be in runtime.c, if device wants to suspend and resume
> 
>  
> 
> then device will call helper functions for pm core like pm_runtime_suspend and pm_runtime_resume,
> 
>  
> 
> which internally calls the runtime_resume of the bus and which in turn calls the runtime_resume of the driver.
> 
>  
> 
> correct ?

Yes.

Alan Stern

Re: About run time power management in linux

[Raj Kumar]

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


 

Hi Alan,

 

I have seen in run time power management helper functions. I have some questions during deep sleep modes

and runtime sleep modes.

 

1) I have seen the code and found that when System wants to go to suspend (deep sleep mode), it has to check for

pm_runtime_barrier which inturn sees if there is a pending runtime resume then it will not allow system to supend.

So it means system suspend can not be done forcefully if the some peripheral jobs are running, correct?

 

2) it means when System deep sleep is going on, run time suspend will never come to peripheral as it checks for usage counter and

if it is zero then it will ask try again.

 

3) if run time suspend is going on,  Then if system wants to go into deep sleep mode, it will wait for run time suspend to finish and then 

gracefully do the shutdown. correct?

 

4) Is it mandatory for peripheral driver but not the bus driver to implement runtime_idle operation?

 

RegardsRaj

 

 

 

 

 

 

 

 

 


 
> Date: Wed, 30 Jun 2010 12:25:21 -0400
> From: stern@rowland.harvard.edu
> To: rajkumar278@hotmail.com
> CC: linux-pm@lists.linux-foundation.org
> Subject: RE: [linux-pm] About run time power management in linux
> 
> On Wed, 30 Jun 2010, Raj Kumar wrote:
> 
> > Hi Alan,
> > 
> > 
> > 
> > First thanks for reply. ok as also seems to be in runtime.c, if device wants to suspend and resume
> > 
> > 
> > 
> > then device will call helper functions for pm core like pm_runtime_suspend and pm_runtime_resume,
> > 
> > 
> > 
> > which internally calls the runtime_resume of the bus and which in turn calls the runtime_resume of the driver.
> > 
> > 
> > 
> > correct ?
> 
> Yes.
> 
> Alan Stern
> 
 		 	   		  

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

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

Re: About run time power management in linux

[Alan Stern]

On Thu, 1 Jul 2010, Raj Kumar wrote:

> Hi Alan,
> 
>  
> 
> I have seen in run time power management helper functions. I have some questions during deep sleep modes
> 
> and runtime sleep modes.
> 
>  
> 
> 1) I have seen the code and found that when System wants to go to suspend (deep sleep mode), it has to check for
> 
> pm_runtime_barrier which inturn sees if there is a pending runtime resume then it will not allow system to supend.
> 
> So it means system suspend can not be done forcefully if the some peripheral jobs are running, correct?

Yes.  The system suspend will have to wait until the runtime PM 
activity is finished.

> 2) it means when System deep sleep is going on, run time suspend will never come to peripheral as it checks for usage counter and
> 
> if it is zero then it will ask try again.

Basically yes, although you have the reason backward.  If the usage 
count is _non-zero_ then runtime suspend won't occur.

> 3) if run time suspend is going on,  Then if system wants to go into deep sleep mode, it will wait for run time suspend to finish and then 
> 
> gracefully do the shutdown. correct?

Yes.

> 4) Is it mandatory for peripheral driver but not the bus driver to implement runtime_idle operation?

None of these are mandatory; it all depends on the bus subsystem.  
Some subsystems don't implement runtime PM at all.

Alan Stern

Re: About run time power management in linux

[Raj Kumar]

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


Hi,

 

yeah, mostly run time power management will be helpful for embedded devices where the power management is

crucial because then individual peripherals can be suspended and it saves a power. Because with run time power

management clock and power domains are easier to manage. 

 

But the thing is if driver goes for runtime_suspend and runtime_resume,

 

then is the runtime_idle is also mandatory to implement? because i have seen if run time suspend is failed due to

EAGAIN and EBUSY, it will notify  via  __pm_runtime_idle i guess this notification is valid for bus drivers.

 

The another question is suppose there are multiple power domains, then with run time power management require

one bus driver corresponding to each power domain? right?

 

Regards

raj

 

 

 


 
> Date: Thu, 1 Jul 2010 10:03:46 -0400
> From: stern@rowland.harvard.edu
> To: rajkumar278@hotmail.com
> CC: linux-pm@lists.linux-foundation.org
> Subject: RE: [linux-pm] About run time power management in linux
> 
> On Thu, 1 Jul 2010, Raj Kumar wrote:
> 
> > Hi Alan,
> > 
> > 
> > 
> > I have seen in run time power management helper functions. I have some questions during deep sleep modes
> > 
> > and runtime sleep modes.
> > 
> > 
> > 
> > 1) I have seen the code and found that when System wants to go to suspend (deep sleep mode), it has to check for
> > 
> > pm_runtime_barrier which inturn sees if there is a pending runtime resume then it will not allow system to supend.
> > 
> > So it means system suspend can not be done forcefully if the some peripheral jobs are running, correct?
> 
> Yes. The system suspend will have to wait until the runtime PM 
> activity is finished.
> 
> > 2) it means when System deep sleep is going on, run time suspend will never come to peripheral as it checks for usage counter and
> > 
> > if it is zero then it will ask try again.
> 
> Basically yes, although you have the reason backward. If the usage 
> count is _non-zero_ then runtime suspend won't occur.
> 
> > 3) if run time suspend is going on, Then if system wants to go into deep sleep mode, it will wait for run time suspend to finish and then 
> > 
> > gracefully do the shutdown. correct?
> 
> Yes.
> 
> > 4) Is it mandatory for peripheral driver but not the bus driver to implement runtime_idle operation?
> 
> None of these are mandatory; it all depends on the bus subsystem. 
> Some subsystems don't implement runtime PM at all.
> 
> Alan Stern
> 
 		 	   		  

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

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

Re: About run time power management in linux

[Alan Stern]

On Thu, 1 Jul 2010, Raj Kumar wrote:

> Hi,
> 
>  
> 
> yeah, mostly run time power management will be helpful for embedded devices where the power management is
> 
> crucial because then individual peripherals can be suspended and it saves a power. Because with run time power
> 
> management clock and power domains are easier to manage. 
> 
>  
> 
> But the thing is if driver goes for runtime_suspend and runtime_resume,
> 
>  
> 
> then is the runtime_idle is also mandatory to implement? because i have seen if run time suspend is failed due to
> 
> EAGAIN and EBUSY, it will notify  via  __pm_runtime_idle i guess this notification is valid for bus drivers.

runtime_idle is not mandatory.

> The another question is suppose there are multiple power domains, then with run time power management require
> 
> one bus driver corresponding to each power domain? right?

No, you can use the same driver for multiple power domains.

Alan Stern

Re: About run time power management in linux

[Raj Kumar]

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


Hi Alan,

 

I have few more questions about run time power management:

 

1) Please correct me if i am wrong. If there is a bus driver that is managing various power domains,

and suppose this domain has some child devices. 

 

Then child has to inform run time Power management core i am idle and i want to go to get suspended,

 

then run time pm core will notify the bus driver of child and then bus driver calls the corresponding child's

 

suspend. right?

 

2) run time power management can be done at device "type" and "class". But what does mean of this device

type. what use cases are defined for run time power management for device "type"?

 

Regards

Raj

 

 

 

 

 


 
> Date: Thu, 1 Jul 2010 10:03:46 -0400
> From: stern@rowland.harvard.edu
> To: rajkumar278@hotmail.com
> CC: linux-pm@lists.linux-foundation.org
> Subject: RE: [linux-pm] About run time power management in linux
> 
> On Thu, 1 Jul 2010, Raj Kumar wrote:
> 
> > Hi Alan,
> > 
> > 
> > 
> > I have seen in run time power management helper functions. I have some questions during deep sleep modes
> > 
> > and runtime sleep modes.
> > 
> > 
> > 
> > 1) I have seen the code and found that when System wants to go to suspend (deep sleep mode), it has to check for
> > 
> > pm_runtime_barrier which inturn sees if there is a pending runtime resume then it will not allow system to supend.
> > 
> > So it means system suspend can not be done forcefully if the some peripheral jobs are running, correct?
> 
> Yes. The system suspend will have to wait until the runtime PM 
> activity is finished.
> 
> > 2) it means when System deep sleep is going on, run time suspend will never come to peripheral as it checks for usage counter and
> > 
> > if it is zero then it will ask try again.
> 
> Basically yes, although you have the reason backward. If the usage 
> count is _non-zero_ then runtime suspend won't occur.
> 
> > 3) if run time suspend is going on, Then if system wants to go into deep sleep mode, it will wait for run time suspend to finish and then 
> > 
> > gracefully do the shutdown. correct?
> 
> Yes.
> 
> > 4) Is it mandatory for peripheral driver but not the bus driver to implement runtime_idle operation?
> 
> None of these are mandatory; it all depends on the bus subsystem. 
> Some subsystems don't implement runtime PM at all.
> 
> Alan Stern
> 
 		 	   		  

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

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

Re: About run time power management in linux

[Alan Stern]

On Mon, 5 Jul 2010, Raj Kumar wrote:

> 
> Hi Alan,
> 
>  
> 
> I have few more questions about run time power management:
> 
>  
> 
> 1) Please correct me if i am wrong. If there is a bus driver that is managing various power domains,
> 
> and suppose this domain has some child devices. 
> 
>  
> 
> Then child has to inform run time Power management core i am idle and i want to go to get suspended,

Strictly speaking, the child device doesn't do this -- its driver does.

> then run time pm core will notify the bus driver of child and then bus driver calls the corresponding child's
> 
>  
> 
> suspend. right?

Right.  In fact, that's true even when the bus driver manages only a 
single power domain.

> 2) run time power management can be done at device "type" and "class". But what does mean of this device
> 
> type. what use cases are defined for run time power management for device "type"?

Here are a couple of examples.  In the USB subsystem there are two
"types": devices and interfaces.  In the SCSI subsystem there are three
"types": hosts, targets, and LUNs.  Each type generally needs to do 
runtime power management differently.

Alan Stern

Re: About run time power management in linux

[Raj Kumar]

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



Hi Alen,

This question is regarding the power management in case of battery is low. Suppose if the battery is low,
how the battery driver notifies the linux power management core to transition to low power state.

How the linux power management addresses this issue?

Thanks
Raj

> Date: Mon, 5 Jul 2010 09:51:55 -0400
> From: stern@rowland.harvard.edu
> To: rajkumar278@hotmail.com
> CC: linux-pm@lists.linux-foundation.org
> Subject: RE: [linux-pm] About run time power management in linux
> 
> On Mon, 5 Jul 2010, Raj Kumar wrote:
> 
> > 
> > Hi Alan,
> > 
> >  
> > 
> > I have few more questions about run time power management:
> > 
> >  
> > 
> > 1) Please correct me if i am wrong. If there is a bus driver that is managing various power domains,
> > 
> > and suppose this domain has some child devices. 
> > 
> >  
> > 
> > Then child has to inform run time Power management core i am idle and i want to go to get suspended,
> 
> Strictly speaking, the child device doesn't do this -- its driver does.
> 
> > then run time pm core will notify the bus driver of child and then bus driver calls the corresponding child's
> > 
> >  
> > 
> > suspend. right?
> 
> Right.  In fact, that's true even when the bus driver manages only a 
> single power domain.
> 
> > 2) run time power management can be done at device "type" and "class". But what does mean of this device
> > 
> > type. what use cases are defined for run time power management for device "type"?
> 
> Here are a couple of examples.  In the USB subsystem there are two
> "types": devices and interfaces.  In the SCSI subsystem there are three
> "types": hosts, targets, and LUNs.  Each type generally needs to do 
> runtime power management differently.
> 
> Alan Stern
> 
 		 	   		  

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

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

Re: About run time power management in linux

[Alan Stern]

On Tue, 6 Jul 2010, Raj Kumar wrote:

> Hi Alen,
> 
> This question is regarding the power management in case of battery is low. Suppose if the battery is low,
> how the battery driver notifies the linux power management core to transition to low power state.
> 
> How the linux power management addresses this issue?

I don't know.

Alan Stern