On Fri, 13 Jan 2012, NeilBrown wrote: > Also, the HDQ access to the battery 'fuel gauge' is working fine, so > presumably that gets disturbed by one of the lower power states (3,4,5). > I guess it is 4,5,6 when CORE goes to RET or OFF. So we need some way for > HDQ to say "I'm busy" just like UART can. omap_hdq_can_sleep() ??? > There must be a cleaner way...
The first thing to try is the HDQ runtime PM conversion series that was sent separately. Maybe let us know if that fixes the problem. > More experiments: > - I enabled off_mode and started seeing state3 happening. UART and HDQ > still fine - as expected. > - I set the /sys/devices/system/cpu/cpu0/cpuidle/state?/usage values > all to '10'. > Now things start to break; > Console is mostly OK, but the first char after 10 seconds of idle is bad. > I type 'enter' and get 'C'. In general the first char typed is mapped to > something else in a consistent way: > 0a -> c3 > 20 -> 90 > 55 -> d5 > 2a -> 95 > It is a bit like we are missing a start bit, and a stop bit is shifting > down into the msb .. sometimes. I'm not seeing garbling at all on the OMAP3 BeagleBoard here, running v3.2 with omap2plus_defconfig. The first character from the console gets lost, which again is expected when the CORE enters a low-power state and there's no flow control on the serial interface -- but no garbling. > HDQ also breaks. > That surprised me a bit as the HDQ access is immediately after typing so > it should be in the 10-second timeout when the UART keeps CORE powered on. > Maybe we need runtime_pm to run omap_hdq_break() again to reinitialise > the HDQ port if CORE might have been turned off. > > Also saw states all the way down to 6. Cannot tell if this helps current > drain as I need HDQ working for that. If CORE is going off, the HDQ device context will be lost, since the HDQ controller will be powered off. You'll need to add code to either save and restore the HDQ register context into the HDQ driver, or to reinitialize the HDQ when it is re-enabled. The latter is what we do for I2C, I think. As far as the DSS goes, your best bet there is to try to work it out with Archit and Tomi. > Thanks for the patch, it's been: > Tested-by: NeilBrown <ne...@suse.de> Thanks. - Paul -- 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
