On Sat, 14 Jan 2012 10:09:15 +1100 NeilBrown <neilb@xxxxxxx> wrote: > On Fri, 13 Jan 2012 04:31:37 -0700 (MST) Paul Walmsley <paul@xxxxxxxxx> wrote: > > > 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. > > Not completely - but I'm still exploring. > > I've finished exploring (for now) and am seriously stumped. Maybe you can help... I modified your patch so that hdq uses autosuspend - because it seemed like a good idea and ends up providing slightly more informative failure modes. The normal behaviour of the bq27000 driver is to request lots of values in quick succession. So using autosuspend (with 100ms timeout) means that we have only one pm_resume and one pm_suspend for each batch of requests which at least reduces the noise. I have added an omap_hdq_can_sleep() function which only succeeds if the hdq device is run-time suspended, and call it in the same place that omap_uart_can_sleep is called, to ensure the core never goes to a lower state while he hdq is active. I've double-checked that this really works. HDQ all works find normally, but then normally CORE stays ON because the UART keeps it on. If I tell the UARTs they can sleep (by setting sleep_timeout) and then access the bq27000 via HDQ it doesn't work properly. The normal sequence is that it resets the HDQ and sends a 'BREAK' signal (possibly not really necessary) for which we get a TIMEOUT interrupt. Then write address - get TX interrupt - wait a bit - get RX interrupt - read byte. We normally get the TIMEOUT interrupt and often get the first TX and then RX interrupts but then the device goes silent. No more interrupts come in, and the status register (which shows interrupt source) reads as zero. Occasionally I have seen maybe half a dozen successful reads before it goes silent, but usually it is zero or 1. It is as though something is timing out and going to sleep. A clock auto-sleeping? Seems unlikely. If I set all the UART sleep_timeout values to 0 to keep CORE always ON, the problem doesn't fix itself. Whatever got turned off stays off. Once it starts failing, it never works again until a reboot. Could we be caching something in memory which we think is on, but due to CORE going into RET (or maybe OFF), the thing is now off and we never bother to reset it because the cached value is 'on' ?? I'm wondering about _sysc_cache, but I haven't looked very deeply into it. Any other ideas? Oh - another thing. Sometimes during early boot I get: [ 0.158447] omap_hwmod: usbtll_fck: missing clockdomain for usbtll_fck. [ 0.176879] omap_hwmod: hdq: softreset failed (waited 10000 usec) At the same time the UART seem to hiccup and my USB-Serial port loses track and doesn't see any more characters until I close and re-open. Could that be related? Any idea what it means? Thanks, NeilBrown
Attachment:
signature.asc
Description: PGP signature
