[GIT PULL] OMAP PM EMU fix for v3.3

[Paul Walmsley]

Hi

On Thu, 23 Feb 2012, Madhusudhan.Gowda at elektrobit.com wrote:

> [Gowda] I found this BUG in the CM code while trying to use both SDTI as
> well as requirement of enabling Hardware supervised transition
> CLKTRCTRL_EMU to 0x3.
> 
> SDTI requires the softwre supervised transition to keep connected, by
> enabling Hardware supervised transition SDTI does not like it so Jouni
> had commented out the HW supervised transtion. Which I agree it is fine
> on SDTI part.
> .flags          = /* CLKDM_CAN_ENABLE_AUTO |  */CLKDM_CAN_SWSUP,
> 
> But my point here is when I set the HW supervised transition, across MPU
> OFF the register loses its previous value and changes to reset value 0x2
> (SW supervised) is not correct. So I submitted this patch for fixing
> this general CM code bug.

Okay, that's a little more clear.  So this patch does not affect the SDTI 
functionality with your driver?  Your patch description reads:

"Embedded trace debug tools like Serial Trace Interface(sti) using
 EMU domain loses connection across MPU OFF. The patch fixes this issue"

But it sounds like that's not the case?  At least, if the reset value for 
CM_CLKSTCTRL_EMU is 0x2, I don't understand how this patch could fix it.

About the patch - I'm fine with the basic underlying idea, but so far it 
looks like this is material for 3.4 rather than 3.3-rc, since it's not a 
regression?

> Please let me know if my comments answers your question.

Well I was hoping that you might answer my earlier questions about whether 
the driver you're using calls into the OMAP infrastructure via 
pm_runtime*(), and whether its clocks and hwmod data are defined.


- Paul