Hi Rajendra,

On 07/31/2012 12:41 AM, Rajendra Nayak wrote:

Hi Jon,

On Tuesday 31 July 2012 10:11 AM, Jon Hunter wrote:

quoted

Hi Paul, Rajendra,

On 07/27/2012 12:43 AM, Rajendra Nayak wrote:

quoted

On Friday 27 July 2012 02:34 AM, Paul Walmsley wrote:

quoted

Commit 4da71ae6 ("OMAP: clockdomain: Arch specific funcs for
clkdm_clk_enable/disable") called the OMAP2xxx-specific functions for
clockdomain wakeup and sleep.  This would probably have broken
software-supervised clockdomain wakeup and sleep on OMAP3.

Its strange this went unnoticed for so long. Thanks for this fix and
sorry about introducing the bug in the first place.

Any chance that's because of the following code? I needed to
remove this to get the EMU clock domain to turn off on OMAP3
whilst testing PMU.

No, this doesn't seem right. We still have clockdomains for omap2/3
controlled using clkdm_clk_enable/disable functions called from
within clk framework, and not clkdm_hwmod_enable/disable from
within hwmod framework.
Besides you removing these checks only in clkdm_hwmod_disable (and
keeping them in clkdm_hwmod_enable) tells me its just hiding some
usecounting issues you were having with clkdm_clk_enable/disable.

Yes you are right. I was focused in the disable side because the EMU CD
is staying on.

Btw, on OMAP2/3 as long as a domain has interface clocks which are
explicitly enabled and autoidled, the clkdm usecount never ends up
going to 0, which is probably what you are hit with too.

Yes so after further debugging, this is not a problem and not the cause
of my problem either.

Sorry for the noise.

Cheers
Jon