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:
signature.asc
Description: This is a digitally signed message part
