Re: DSS2/PM on 3.2 broken?

[Tomi Valkeinen <tomi.valkeinen@ti.com>]

[-- Attachment #1: Type: text/plain, Size: 2318 bytes --]

On Thu, 2012-01-19 at 10:17 +0000, Joe Woodward wrote:
> ...snip...
> > 
> >    cat /sys/kernel/debug/omapdss/clk
> > 
> > is below and reports 66461538 for fck, so 66MHz?  Still safe for OPP50.
> > 
> > And disabling SMART REFLEX had no obvious effect.
> > 
> > If you can think of anything else I could try to explore to narrow down
> > the source of this, I am very happy to test or examine anything you
> > suggest.
> > 
> > Thanks,
> > NeilBrown
> > 
> 
> I'm not sure if this will give you any pointers but i'll tell you what I'm fairly certain I'm seeing...
> 
> If I run the stock 3.2 with the changes to dss.c and dispc.c to make the pm_runtime_put()'s in to pm_runtime_put_sync()'s then the DSS warnings when 
> suspending do indeed go away.
> 
> I have two wake sources, one being the UART the console is on and the other being a GPIO button.
> 
> I've tested the following situations:
>  - If I sleep using the console and wake by typing a character then I *never* get a SYNC_LOST error.
>  - If I sleep by pressing a button on the display (which does a system ("echo mem > /sys/power/state") and then wake by typing a character in to the console then 
> I *never* get a SYNC_LOST error.
>  - If I sleep by pressing a button on the display (which does a system ("echo mem > /sys/power/state") and then wake by pressing a button attached to the GPIO 
> then I get a sequence of SYNC_LOST errors which continue at a rate of about one every 0.5 seconds until a type a character in to the console and then everything 
> settles down and starts working again.
> 
> So, at least from what I'm seeing, the SYNC_LOST errors seem related somehow to the UART, if that is indeed possible?

Well, I don't see how UART could directly affect DSS. The thing that
comes to my mind is that typing a char in the console causes a change in
the power management, which then "fixes" the DSS. But then again, I'd
expect the console to go into sleep/idle state after a short while,
which should again cause sync_losts. But that's not happening...

Can you show the dss clocks you use (cat debugfs/omapdss/clk)?

It's been a while since I did anything with PM, so I don't remember how
and if it can be done, but a simple test would be to lock the OMAP to
always use OPP100.

 Tomi


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]