On 6/7/2011 1:51 PM, Valkeinen, Tomi wrote:
On Tue, 2011-06-07 at 13:37 +0200, Cousson, Benoit wrote:
On 6/7/2011 8:52 AM, Valkeinen, Tomi 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?
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.
And for PM, it doesn't matter if the dss_fck is enabled once or seven
times, I presume a use count of one will still prevent RET or OFF?
If you cannot do that at your level, we will have to set a hwmod
dependency between DSS modules and the main DSS subsystem.
For the moment we do not have such HW dependencies.
I can do this in the driver, and in fact I already do. The dss_core
hwmod is enabled by all the other hwmods before they do anything.
My reasoning for this dependency is that the dss_core contains for
example the clock mux registers, and other misc registers used by most
other dss modules. But I'm not sure if this dependency should be in the
hwmod level or not.
It makes sense for me as well to have that dependency between drivers.
Having it for hwmod for my point of view will make the hwmod state out
of sync with the driver that manage it potentially. That kind of hard
coded dependencies at hwmod level should maybe be considered only if the
dependent hwmod does not belong to any driver.
Benoit
--
To unsubscribe from this list: send the line "unsubscribe linux-fbdev" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
