Re: Problem with DSS clocks & accessing registers

["Cousson, Benoit" <b-cousson@ti.com>]

+ Rajendra

Hi Tomi,

On 3/7/2011 9:22 AM, Valkeinen, Tomi wrote:
> Hi Kevin, Paul,
>
> We currently have a small problem with OMAP4 DSS. When we enable the DSS
> clocks, it seems that the DSS registers are not always accessible right
> after the clock enable.

What clocks are you talking about? As you know, the DSS has a bunch of 
functional clocks available depending of the use case.

> I understood that on OMAP4 the clock framework doesn't guarantee that
> the registers are accessible after enabling clocks, and pm_runtime will
> handle this. Is this correct?

The point is that there is no status at clock level but only one status 
at module level. That's why this check does not have anything to do at 
clock level.
So hwmod with handle that status (OMAP4430_CM_DSS_DSS_CLKCTRL) during 
the hwmod_enable that is indirectly called by pm_runtime, through 
omap_device API.

> I have made a small hack fix for this. I added udelay(10) in the DSS
> code which enables the clocks and this seem to remove the problem. The
> delay is only called when DSS thinks the clocks have been off, so in
> practice the delay shouldn't be visible. Is this fix acceptable for now,
> until we get pm_runtime support to DSS?

Cannot you use omap_device for the moment? Relying on a udelay is not a 
very safe method, even temporally.
Or you might hack the main clock node to check for the module status. I 
think it was done like that at the beginning of OMAP4.
It was removed, but I do not remember if it was done at fmwk level or at 
clock nodes level.

Rajendra should know the full story.

Regards,
Benoit