Tomi Valkeinen <tomi.valkeinen@xxxxxxxxx> writes: > On Tue, 2009-09-22 at 16:54 +0200, ext Kevin Hilman wrote: >> Tomi Valkeinen <tomi.valkeinen@xxxxxxxxx> 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@xxxxxxxxx> 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 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
