Re: [PATCH] PM/domains: add delayed power off capability

[Mayuresh Kulkarni <mkulkarni@nvidia.com>]

On Thursday 14 March 2013 02:29 PM, Peter De Schrijver wrote:
> On Wed, Mar 13, 2013 at 08:27:02PM +0100, Kevin Hilman wrote:
>> Mayuresh Kulkarni <mkulkarni@nvidia.com> writes:
>>
>>> On Tuesday 12 March 2013 07:19 PM, Greg KH wrote:
>>>> On Tue, Mar 12, 2013 at 02:19:19PM +0530, Mayuresh Kulkarni wrote:
>>>>> - this commit adds a capability to delay the powering off
>>>>> of the domain
>>>>
>>>> Why?
>>>>
>>>
>>> - As I mentioned below (sorry for mentioning below rather than at
>>> start), powering off a domain means the context save needs to be done
>>> && it needs to be restored during power on.
>>> - It often observed that saving and restoring of context is expensive
>>> in terms of power consumed as well as overall system response.
>>
>> Are you talking about per-device context save/restore?
>>
>> Your drivers should be using runtime PM, which has an autosuspend
>> timeout feature.  Using autosuspend on any device in the power domain
>> will have the same effect as this proposed patch.
>>
>> Using runtime PM to target specific devices that have expensive
>> save/restore paths is also more understandable and maintainable IMO,
>> because the "fix" is targetted.
>>
>
> No. The goal of this patch is to introduce something similar to autosuspend
> for turning off domains. Even if all peripherals in a domain are idle, you
> might not want to turn off the domain immediately, but wait a little in case
> a new request comes in. We are using this scheme today in our GPU driver and
> it works quite well, but that's done entirely without PM domains.
>
> Cheers,
>
> Peter.
>

- As Peter mentioned above, the idea is to wait for some time before 
turning off a domain with the anticipation that it will be needed soon 
for a particular use case.
- My previous comments would sound valid if you imagine a domain that 
has a single device attached to it. In such case, there are 2 things 
that happen during power-on/off: context save/restore of the device and 
powering on/off of a domain. Both of them needs energy and possibly time 
to settle down (stabilize the domain power).
- If such a domain is going to be needed very soon in future, it makes 
sense to avoid its power down for at-least that much amount of time 
(which is what the proposed patch does).