Hi,
On Wednesday 11 January 2012 07:13 PM, Paul Walmsley wrote:
cc Kevin
On Tue, 10 Jan 2012, NeilBrown wrote:
It seems that when cpuidle on an omap3 tries to switch to lower power
states, various things misbehave:
- UARTs lose characters
Is this with off-mode enabled, or is this with only retention idle
enabled?
If off-mode is enabled, and incoming serial traffic is used to wake the
system, it's known and expected that the first byte will be lost. This is
an artifact of the hardware and seems to be unavoidable.
- dss loses sync
Best to take this up with the DSS maintainer directly.
Could you enable omapdss debug by adding 'omapdss.debug=1 debug' in your
bootargs and share logs?
The pm_runtime_get_sync() call in dss_runtime_get() is returning a
negative value, could you print out that value too?
If the call to pm_runtime_get_sync() fails, we bail out immediately. So
the LCD interface shouldn't have been enabled at all. I don't know why
we get sync lost errors.
There is a possibility that the LCD interface wasn't switched off when
for some reason when we suspended, and switching on the clocks again
tries to start the transfer without DSS being configured correctly?
Also, are you on the final 3.2, or the 3.2-rc's by any chance? There
were some hwmod patches which got in 3.2-rc4 related to hwmod fixes.
Archit
- HDQ seems to lose everything.
Is this with off-mode enabled, or just with retention idle?
If the former, this is hardly surprising as the HDQ driver
(drivers/w1/masters/omap_hdq.c) doesn't contain any context save/restore
code. In fact the HDQ driver doesn't even use PM runtime, so quite a bit
of work is needed there.
- Paul
--
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
--
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
