On Friday 05 October 2012 06:07 PM, Rajendra Nayak wrote:
On Friday 05 October 2012 05:59 PM, Archit Taneja wrote:
The other not so good option to make DSS PM work would be to add
OCPIF_SWSUP_IDLE flag to our l3_main_2__dss_* slave interfaces(which
have the hack "dss_fck" as slave clock). I gave this approach a try,
that too isn't working so well. When I disable DSS, I get
CM_DSS_DSS_CLKCTRL.IDLEST as 0x1, and
CM_DSS_CLKSTCTRL.CLKACTIVITY_DSS_L3_ICLK is set. I wonder why that's
happening.

I have seen DSS get stuck in transition, with just a clkdm state toggle
(from say HWSUP to SWWKUP) while its optional clocks are not running.
Thats probably whats happening now.

Oh ok, I can notice that too. So in the _idle() path, the clocks are disabled first, and then we try to change the clkdm state. I guess that could be the reason why DSS doesn't sleep.

But then, I don't understand why this problem isn't seen if I try the alternative option of removing the fake dss_fck slave clock, and tie modulemode to only the parent hwmod. There DSS IDLEST is 0x3 when I disable DSS.

I think with this approach, the problem is with _disable_clocks(), in disable_clocks, main_clk is disabled first, and then the slave clocks. That translates to DSS_FCK opt clock getting disabled first, and then MODULEMODE bits. I think DSS doesn't transition to sleep with this disable sequence.


Did you try keeping the modulemode enabled and see if it really gates
DSS/system sleep. I remember testing with Teros CORE ret/off patches
and I was always seeing DSS modulemode enabled but it wasn't gating
sleep.

If the clkdm is in HW_AUTO, I can get DSS in sleep(STBYST and IDLEST all set). Is this helpful? Can we just leave modulemode on all the time? That'll be the best :)

Anyway, I guess it would be the best to have a custom _setup function(or skip them all together) for DSS as Benoit suggested.

Archit

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

Reply via email to