On Tue, 2011-06-07 at 09:52 +0300, Tomi Valkeinen wrote: > On Mon, 2011-06-06 at 17:28 +0200, Cousson, Benoit wrote: > > > Before doing that, could you maybe just try something to make OMAP4 > > looks a little bit more like OMAP3? > > > > dss_fck -> ick > > dss_dss_fck -> main_clk > > > > That should ensure that both modulemode and the PRCM fclk will be > > managed by pm_runtime. > > I made the changes as you suggested, and while I haven't made the > changes to omapdss yet to see if I can remove the dispc_runtime_get/put > style function, I can boot up and start the dss. > > However, after booting up but before enabling the dss driver, I can see > that the clock counts are: > > dss_tv_clk 0 > dss_sys_clk 0 > dss_fck 7 > dss_dss_clk 0 > dss_48mhz_clk 0 > > So the modulemode is set for all dss hwmods? Isn't this exactly how it's > _not_ meant to be, as modulemode should be set only after enabling the > fck? This also seems to keep the DSS from going to RET or OFF, at least in the TI internal PM testing tree. So is the PM side buggy there, and it shouldn't care about the modulemode being enabled if other clocks are off, or is it the hwmod side that's buggy, and it should disable the modulemode also? Tomi -- 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
