On 10/05/2012 03:20 PM, Archit Taneja wrote: > 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 :) Well, it is true that in the case of the DSS the modulemode is only managing the interface clock. And since the interface clock is doing autogating, it will not prevent clockdomain transition. But I will not recommend using that, it should not be useful assuming the clocks are properly managed by the DSS. I think we still have issue dur to the presence of that fake modulemode clock node. Regards, Benoit -- 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
