On 6/8/2011 9:55 AM, Valkeinen, Tomi wrote:
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.
Mmm, the issue is probably due to the way we are managing interface
clock that are usually able to autoidle. Because of that the
_disable_clocks function will not try to disable an interface clock
except if you use the following flag: OCPIF_SWSUP_IDLE.
static struct omap_hwmod_ocp_if omap44xx_l3_main_2__dss = {
.master = &omap44xx_l3_main_2_hwmod,
.slave = &omap44xx_dss_hwmod,
.clk = "dss_fck",
.addr = omap44xx_dss_dma_addrs,
.addr_cnt = ARRAY_SIZE(omap44xx_dss_dma_addrs),
.user = OCP_USER_SDMA,
+ .flags = OCPIF_SWSUP_IDLE,
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.
I hope we'll be able to fix the fmwk for 3.0.1.
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
