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

[Paul Walmsley]

Hello Gowda,

A few questions...

On Wed, 22 Feb 2012, Madhusudhan.Gowda at elektrobit.com wrote:

> I have tested this on beagle board as well as on OMAP3630 based
> propriatory phone using SDTI serial trace interface.

What driver are you using for SDTI?  Does it use pm_runtime* or call 
clk_enable() on some clock when it is in use?  Are you defining a hwmod 
for it?  I don't see an SDTI driver in mainline, but maybe I am just 
missing it.  If it's not there, could you please post it or post a link to 
it so we can take a look at what it's doing?

> Also you can test it by just observing the 
> CM_EMU (48005100) clkstctrl register
>  48 => 00000001
> Across MPU OFF alone
> 
> [root at beagleboard /]# echo 0 >
> /sys/kernel/debug/pm_debug/neon_pwrdm/suspend
> [root at beagleboard /]# echo 0 >
> /sys/kernel/debug/pm_debug/mpu_pwrdm/suspend
> [root at beagleboard /]# echo 1 >
> /sys/kernel/debug/pm_debug/core_pwrdm/suspend
> [root at beagleboard /]# echo 1 >
> /sys/kernel/debug/pm_debug/per_pwrdm/suspend
> [root at beagleboard /]# echo mem >/sys/power/state
> [   59.694671] PM: Syncing filesystems ... done.
> [   59.758209] Freezing user space processes ... (elapsed 0.02 seconds)
> done.
> [   59.789947] Freezing remaining freezable tasks ... (elapsed 0.02
> seconds) done.
> [   59.820709] Suspending console(s) (use no_console_suspend to debug)
> [   60.055816] PM: suspend of devices complete after 212.493 msecs
> [   60.059661] PM: late suspend of devices complete after 3.784 msecs
> [   60.059753] Disabling non-boot CPUs ...
> [   64.299865] Successfully put all powerdomains to target state
> [   64.302551] PM: early resume of devices complete after 2.319 msecs
> [   64.636444] PM: resume of devices complete after 332.336 msecs
> [   64.688446] Restarting tasks ... done.
> [root at beagleboard /]# 
> 
> And then print again the CM_EMU (48005100) clkstctrl register offset 48
> this will have the reset value and PRM_EMU (48307100) offset e4 =>
> 00000100 register confirms the domain wakeup reset from OFF.
> 
> At this moment the SDTI serial trace interface looses connection.
> 
> With my patch applied the CM_EMU (48005100) clkstctrl register restores
> it initial setting across MPU OFF.

Maybe you can walk through these thoughts with me and see if it makes 
sense to you.

When the PM code initializes, it will put the EMU clockdomain to 
software-supervised sleep.  (Ideally it would put it to 
hardware-supervised idle, but Jouni turned this off a long time ago, 
apparently due to some PRCM usecounting problem with it -- which may 
simply have been some software problem on our part?)

That accounts for CM_CLKSTCTRL_EMU being set to 0x1 before MPU OFF.  Does 
the SDTI work for you when CM_CLKSTCTRL_EMU is set to 0x1? There's no 
FCLKEN/ICLKEN bit for the PRCM to use-count, it seems :-( Although maybe 
this is done through the SDTI_WINCTRL register?

I observe the same phenomenon that you do, that when MPU comes back from 
OFF, CM_CLKSTCTRL_EMU is set to 0x2.  From reading the TRM, it's not clear 
to me what is causing that, although I'd agree with your conclusion that 
it's related to the MPU's reset line.

But here's the part that's unclear to me about your description: according 
to the TRM, 0x2 means software-supervised wakeup.  So the EMU clockdomain 
should be awake at that point.  That shouldn't prevent the SDTI from 
working; in fact quite the opposite.  So I don't really understand how 
your patch would fix anything in this regard.  Any thoughts?

My suspicion, by the way, is that the underlying problem may be with the 
SDTI driver that you're using.  My guess would be that it's not integrated 
with the OMAP power management infrastructure (via pm_runtime* calls), 
and that's what's causing the problem.


- Paul