One issue regarding the run time power management

One issue regarding the run time power management

[Raj Kumar]

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


 
Hi,
 
There is a one issue coming regarding the run time power management during system suspend, Suppose
system suspend is going on and before the suspend callback of driver is executed, driver issues a runtime resume to run time power management core before it gets
the system suspend call back but System suspend is going on then how the run time power management prevents this condition?
 
As I saw the code during dpm_prepare, power usage count is incremented by 1 by calling pm_runtime_get_noresume(dev) and then it calls
pm_runtime_barrier,
 
Since During System suspend, driver calls pm_runtime_get which will invoke 
 
atomic_inc(&dev->power.usage_count);
 
which increments the power usage count and calls pm_request_resume which does not have any check on power usage count,
 
So when System suspend is going on and it has not reached suspend call back of driver and driver submits run time resume request (if
the device is suspended at runtime earlier)
 
Then How run time power management prevents device run time resume when the system suspend is going on as it does not
check for power usage count?
 
Regards
Raj  		 	   		  

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

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

Re: One issue regarding the run time power management

[Rafael J. Wysocki]

On Tuesday, November 02, 2010, Raj Kumar wrote:
> 
> Hi,
>  
> There is a one issue coming regarding the run time power management during system suspend, Suppose
> system suspend is going on and before the suspend callback of driver is executed, driver issues a runtime resume to run time power management core before it gets
> the system suspend call back but System suspend is going on then how the run time power management prevents this condition?
>  
> As I saw the code during dpm_prepare, power usage count is incremented by 1 by calling pm_runtime_get_noresume(dev) and then it calls
> pm_runtime_barrier,
>  
> Since During System suspend, driver calls pm_runtime_get which will invoke 
>  
> atomic_inc(&dev->power.usage_count);
>  
> which increments the power usage count and calls pm_request_resume which does not have any check on power usage count,

pm_request_resume() called during system suspend will not have any effect, unless it is called before
the pm_runtime_barrier() in dpm_prepare(), in which case the device is going to be resumed and
system suspend will be aborted, because the PM workqueue if frozen before the suspend of
devices.

> So when System suspend is going on and it has not reached suspend call back of driver and driver submits run time resume request (if
> the device is suspended at runtime earlier)
>  
> Then How run time power management prevents device run time resume when the system suspend is going on as it does not
> check for power usage count?

The request to resume the device waits until the thawing of the PM workqueue.
if the driver needs to resume the device during suspend, it should use
pm_runtime_resume() for that, in which case the PM core doesn't care.

Thanks,
Rafael

Re: One issue regarding the run time power management

[Alan Stern]

On Wed, 3 Nov 2010, Rafael J. Wysocki wrote:

> On Tuesday, November 02, 2010, Raj Kumar wrote:
> > 
> > Hi,
> >  
> > There is a one issue coming regarding the run time power management during system suspend, Suppose
> > system suspend is going on and before the suspend callback of driver is executed, driver issues a runtime resume to run time power management core before it gets
> > the system suspend call back but System suspend is going on then how the run time power management prevents this condition?
> >  
> > As I saw the code during dpm_prepare, power usage count is incremented by 1 by calling pm_runtime_get_noresume(dev) and then it calls
> > pm_runtime_barrier,
> >  
> > Since During System suspend, driver calls pm_runtime_get which will invoke 
> >  
> > atomic_inc(&dev->power.usage_count);
> >  
> > which increments the power usage count and calls pm_request_resume which does not have any check on power usage count,
> 
> pm_request_resume() called during system suspend will not have any effect, unless it is called before
> the pm_runtime_barrier() in dpm_prepare(), in which case the device is going to be resumed and
> system suspend will be aborted, because the PM workqueue if frozen before the suspend of
> devices.

Should pm_request_resume be changed?  Maybe it should abort a system
sleep transition.  Or maybe it should abort the sleep if the device in 
question has already been suspended.

Alan Stern

Re: One issue regarding the run time power management

[Rafael J. Wysocki]

On Sunday, November 07, 2010, Alan Stern wrote:
> On Wed, 3 Nov 2010, Rafael J. Wysocki wrote:
> 
> > On Tuesday, November 02, 2010, Raj Kumar wrote:
> > > 
> > > Hi,
> > >  
> > > There is a one issue coming regarding the run time power management during system suspend, Suppose
> > > system suspend is going on and before the suspend callback of driver is executed, driver issues a runtime resume to run time power management core before it gets
> > > the system suspend call back but System suspend is going on then how the run time power management prevents this condition?
> > >  
> > > As I saw the code during dpm_prepare, power usage count is incremented by 1 by calling pm_runtime_get_noresume(dev) and then it calls
> > > pm_runtime_barrier,
> > >  
> > > Since During System suspend, driver calls pm_runtime_get which will invoke 
> > >  
> > > atomic_inc(&dev->power.usage_count);
> > >  
> > > which increments the power usage count and calls pm_request_resume which does not have any check on power usage count,
> > 
> > pm_request_resume() called during system suspend will not have any effect, unless it is called before
> > the pm_runtime_barrier() in dpm_prepare(), in which case the device is going to be resumed and
> > system suspend will be aborted, because the PM workqueue if frozen before the suspend of
> > devices.

I should have said that it only affects the devices for which device_may_wakeup()
returns 'true'.

> Should pm_request_resume be changed?  Maybe it should abort a system
> sleep transition.  Or maybe it should abort the sleep if the device in 
> question has already been suspended.

Well, I don't think so, at least not always.  Perhaps it's better to let the
caller execute pm_wakeup_event() or pm_stay_awake() before calling
pm_request_resume() in case it wants to abort system suspend in progress.

I guess the core might do that as well, actually, in the situation described
above ...

Thanks,
Rafael

Regarding the dedicated memory for hibernation

[Raj Kumar]

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


Hi Rafael,

I have one question regarding the dedicated memory(the memory that is not OS addressable). But when userspace does mmap, I am creating mapping for VMA to physical addresses that are in dedicated memory.
The question is when system hibernates, will the OS kernel take care of this when creating hibernation image as mmap creates a virtual address space or device driver should explicity swap this memory(dedicated memory) in hibernation image?

Regards
Raj
 		 	   		  

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

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

Re: Regarding the dedicated memory for hibernation

[Rafael J. Wysocki]

On Tuesday, March 22, 2011, Raj Kumar wrote:
> 
> Hi Rafael,
> 
> I have one question regarding the dedicated memory(the memory that is not OS addressable).

What do you mean by not OS addressable?

> But when userspace does mmap, I am creating mapping for VMA to physical addresses that are in dedicated memory.
> The question is when system hibernates, will the OS kernel take care of this when creating hibernation image as mmap creates a virtual address space or device driver should explicity swap this memory(dedicated memory) in hibernation image?

The hibernate core saves everything that's regarded as RAM.  The other memory
areas have to be saved by drivers (or generally subsystems) that manage them
before the image is created.

Thanks,
Rafael