Re: [PATCH 2/3] MMC: OMAP: HSMMC: add runtime pm support

[Kevin Hilman <khilman@ti.com>]

"T Krishnamoorthy, Balaji" <balajitk@ti.com> writes:

> On Wed, Jun 29, 2011 at 2:00 AM, Kevin Hilman <khilman@ti.com> wrote:
>> "T Krishnamoorthy, Balaji" <balajitk@ti.com> writes:
>>
>>> On Tue, Jun 28, 2011 at 10:52 PM, Paul Walmsley <paul@pwsan.com> wrote:
>>>> (cc'ing Adrian also)
>>>>
>>>> Hi Balaji
>>>>
>>>> On Wed, 22 Jun 2011, Balaji T K wrote:
>>>>
>>>>> Use runtime autosuspend APIs to enable auto suspend delay
>>>>
>>>> Does this really need to use runtime autosuspend?  Seems to me that since
>>>> PM runtime is just controlling the MMC IP blocks and not the regulators in
>>>> this instance, this could simply use pm_runtime_put*() and just avoid the
>>>> extra power wastage and complexity involved in autosuspend.
>>>>
>>>
>>> I have seen some instabilities if delay is very less, on some production boards.
>>> The previous implementation used 100ms delay before disabling the clocks.
>>
>> And your new one is using 50ms.  How did this value come about?
>>

> I don't have any specific affinity to this number, but when requests
> are bursty, they arrive within a few 10s of ms within each
> other. Didn't want to have the context/save restore penalty associated
> with every request.

Have you measured the context save/restore penalty when only the clocks
are gated (and no regulators involved) ?

In the current code, it's understandable why there were large latencies
that were avoided because the regulators were also cut.  With only the
clocks being cut, the latency involved will be significantly less.

>> As Paul mentioned, the timeout value here is probably usecase depeend
>>
>
> There is no direct relationship to the use case. Block layer buffers
> and reworks the order of requests and they are usually queued
> together. Having no context save / restore penalty for each request is
> definitely desirable.  

Desirable for what?

What is implied in that statement is desirable for performance.

What if a different user would prefer the power savings gained by more
aggressively cuttting clocks over the performance gains of leaving
clocks enabled?

Kevin
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html