Re: [PATCH] video: omap2: dss: RET on idle, enable/disable dss clocks only when needed.

[Kevin Hilman <khilman@deeprootsystems.com>]

Tomi Valkeinen <tomi.valkeinen@nokia.com> writes:

> On Tue, 2009-09-22 at 16:54 +0200, ext Kevin Hilman wrote:
>> Tomi Valkeinen <tomi.valkeinen@nokia.com> writes:
>> 
>> > Hi,
>> >
>> > On Fri, 2009-09-18 at 19:33 +0200, ext Mike Chan wrote:
>> >> On Fri, Sep 18, 2009 at 1:27 AM, Tomi Valkeinen
>> >> <tomi.valkeinen@nokia.com> wrote:
>> >> > Hi,
>> >> >
>> >> > If you disable the clocks to allow RET, you also allow OFF mode. And
>> >> > resuming from OFF mode hasn't been implemented for DSI, if I recall
>> >> > right. And when I was testing it, it didn't seem to be trivial with the
>> >> > DSI PLL.
>> >> >
>> >> 
>> >> You can limiting the pwrdm next state to RET when being called from cpuidle.
>> >
>> > No, you _must_ limit it to RET. Otherwise the DSI will break down. So we
>> > can either keep the dsi code as it is now, or explicitely disable OFF
>> > mode and then apply your patch. But your patch alone won't work.
>> 
>> Or could add a hack to this patch so that 'enable_off_mode' doesn't
>> affect DSS_MOD until DSS has off-mode support.
>
> Is this something that the driver can do with the current PM API? The
> thing is, most of the DSS has off-mode support, only DSI and RFBI is
> missing the support. So optimally we would allow full PM normally, but
> when DSI display is in use, only allow RET.

There's not an official API for this, but for testing, you could just
set the next state for the DSS_MOD to be off.  This would be overridden
whenever someone changes the enable_off_mode flag.

In general, we don't want drivers restricting states at that level.
We'd rather the drivers use the OMAP PM layer to define/declare its
constraints.

>> 
>> > In the long run I think we anyway need to somehow dynamically manage the
>> > power state. I haven't measured it but I believe resuming from OFF will
>> > have a bit of a penalty, as (I think) DSI PLL etc. will have to
>> > reinitialized. But it would still be good to allow RET whenever
>> > possible, and OFF only after some period of inactivity.
>> 
>> This is the purpose of latency constraints.  These can be used when
>> the latency of going OFF will cause a problem.
>
> I think this is a different problem. My understanding of the PM latency
> functionality is that they control how quickly MPU responds to
> interrupts, or how quickly the HW module is awake after clk_enable().

That's only part of the story.

> The problem here is that there's bunch of DSI initialization that needs
> to be done after the DSS module has woken up. The DSI PLL needs to be
> configured and locked, complex IO has to be configured etc. I don't know
> how long those take (should make some measurements at some point), but I
> imagine they are not anywhere near instant. And the latency from those
> things is what I'm concerned about. So it would be beneficial if the DSS
> driver could define easily what DSS PM level is allowed.

Actually, the OMAP PM layer is meant to handle device wakeup latencies
as well.  See Documentation/arm/OMAP/omap_pm, and the
set_max_dev_wakeup_lat() hook in particular.

For example, if you know that DSS wakeup from OFF takes X usecs and
the driver has set a max device wakeup latency < X, then DSS will
never go to OFF.  The same can be done to prevent RET for even faster
wakeup.

Kevin