...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?
Cheers,
Joe
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
