Re: DSS2/PM on 3.2 broken?

[Kevin Hilman <khilman@ti.com>]

NeilBrown <neilb@suse.de> writes:

> On Thu, 19 Jan 2012 11:37:39 -0800 Kevin Hilman <khilman@ti.com> wrote:
>
>> "Joe Woodward" <jw@terrafix.co.uk> writes:
>> 
>> [...]
>> 
>> > If I do (either from the console or via a button press on the screen)
>> > then I never get a SYNC_LOST.
>> >
>> >   echo 0 > /sys/devices/omapdss/display0/enabled
>> >   echo 1 > /sys/devices/omapdss/display0/enabled
>> >
>> > Just trying to think of some ideas that may be affecting the DSS...
>> >   - Could it to be to do with the GPIO being used as a wake source (i.e. does the GPIO driver do runtime_pm properly?)?
>> >   - Could it to be to do with the UART as it seems to fix itself whenever a character is pressed?
>> >   - Could it to be to do with the ordering in which drivers are resumed?
>> 
>> Here's my guess/hunch as to why the UART wakeup helps and GPIO doesn't.
>> 
>> The UART's are idled using timeouts, so after any activity (including a
>> wakeup) the UART timeout will not alow the UARTs to idle (and thus the
>> system to hit low power states) for a given timeout period.
>
> While I agree with that, I'm wondering if there might be something else odd
> relating to the UARTs that we haven't spotted yet.

I suspect the problem for both is constraints that aren't stated
explicitly.

> I'm chasing done the different problem of HDQ not coping with CPUIDLE but I
> think it is very likely to have a similar root cause, as HDQ goes wrong at
> the same time that DSS goes wrong, and is a vaguely similar way.
>
> I just tried compiling omap_hwmod.c with "#define DEBUG" and got some strange
> results.

Strange indeed.

I assume you are you using the runtime PM converted driver from Paul?  I
tried that branch on my 3530/Overo (console on UART3) and didn't see any
nul's on my UART3 console.  

[...]

> The other thing I discovered is that when I set the uart 'sleep_timeout' to 5
> (all uarts) so that CPUIDLE can let CORE enter the lower power states, I get
> a fairly steady stream of:
>
> [ 1168.490478] omap_hwmod: uart1: enabling
> [ 1168.490509] omap_hwmod: uart1: enabling clocks
> [ 1168.490539] omap_hwmod: uart2: enabling
> [ 1168.490539] omap_hwmod: uart2: enabling clocks
> [ 1168.490631] omap_hwmod: uart3: enabling
> [ 1168.490661] omap_hwmod: uart3: enabling clocks
> [ 1168.490661] omap_hwmod: uart4: enabling
> [ 1168.490692] omap_hwmod: uart4: enabling clocks
> [ 1168.578796] omap_hwmod: uart3: idling
> [ 1168.578796] omap_hwmod: uart3: disabling clocks
> [ 1168.578826] omap_hwmod: uart4: idling
> [ 1168.578826] omap_hwmod: uart4: disabling clocks
> [ 1168.578857] omap_hwmod: uart1: idling
> [ 1168.578857] omap_hwmod: uart1: disabling clocks
> [ 1168.578887] omap_hwmod: uart2: idling
> [ 1168.578887] omap_hwmod: uart2: disabling clocks
> [ 1168.714263] omap_hwmod: uart1: enabling
> [ 1168.714294] omap_hwmod: uart1: enabling clocks
> [ 1168.714324] omap_hwmod: uart2: enabling
> [ 1168.714324] omap_hwmod: uart2: enabling clocks
> [ 1168.714416] omap_hwmod: uart3: enabling
> [ 1168.714447] omap_hwmod: uart3: enabling clocks
> [ 1168.714447] omap_hwmod: uart4: enabling
> [ 1168.714477] omap_hwmod: uart4: enabling clocks
> [ 1168.803344] omap_hwmod: uart3: idling
> [ 1168.803344] omap_hwmod: uart3: disabling clocks
> [ 1168.803375] omap_hwmod: uart4: idling
> [ 1168.803375] omap_hwmod: uart4: disabling clocks
> [ 1168.851257] omap_hwmod: uart3: enabling
> [ 1168.851287] omap_hwmod: uart3: enabling clocks
> [ 1168.851318] omap_hwmod: uart4: enabling
> [ 1168.851318] omap_hwmod: uart4: enabling clocks
> [ 1168.885955] omap_hwmod: uart3: idling
> [ 1168.885986] omap_hwmod: uart3: disabling clocks
> [ 1168.885986] omap_hwmod: uart4: idling
> [ 1168.886016] omap_hwmod: uart4: disabling clocks
> [ 1168.886383] omap_hwmod: uart3: enabling
> [ 1168.886383] omap_hwmod: uart3: enabling clocks
> [ 1168.886383] omap_hwmod: uart4: enabling
> [ 1168.886413] omap_hwmod: uart4: enabling clocks
> [ 1168.944885] omap_hwmod: uart3: idling
> [ 1168.944915] omap_hwmod: uart3: disabling clocks

At least this part is expected.  

In the kernel you're using the UART clocks are enabled/disabled during
the idle path depending on the low-power state being targetted, so would
expect to see lots of UART clock gating going on.

Kevin

> It seems to mostly be uart3 and uart4.
> If there is any interaction between the uart clock and the hdq clock, this
> could explain why the HDQ gets confused when all this is happening.
>
> And if there is a connection there, then there could also be a connection
> with a DSS clock which could be confusing it.
>
> I admit this is largely surmise and hypothesis - but there is definitely
> something odd here!
>
> Thanks,
> NeilBrown