On Tue, 2011-06-07 at 18:43 +0200, Cousson, Benoit wrote: > On 6/7/2011 1:51 PM, Valkeinen, Tomi wrote: > > On Tue, 2011-06-07 at 13:37 +0200, Cousson, Benoit wrote: > >> The issue is that there is only one modulemode for the whole DSS. > >> Potentially only the dss_hwmod should have it. But then you have to > >> ensure that this device is enabled before any other DSS devices. > > > > Does that change anything? Isn't the above (modulemode enabled before > > opt clock) still true, even if it was enabled only once for the dss_core > > hwmod? > > It does not really change anything, but it is more accurate. > Modulemode need to be enable after the opt clocks that act as a > functional clock and before enabling HW_AUTO for the clockdomain. > > The important parameter is the clock domain mode change. It is another > issue that we have to fix. It might not affect you for the moment. Ok. But the main issue now is the PM. If I change the clocks in hwmod data as you suggested, dss_fck will always stay enabled and prevent RET and OFF. So the fix is not acceptable even for temporary use. So is there some way to fix this, or shall we just go forward with the current patch series having the somewhat hacky way to use pm_runtime? I would personally like to get the driver right from the start, even if that means more hacks in the hwmod fmwk (because that's where the problems are). But if that is very difficult, I'm fine with the current patch series. 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
