...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 majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
