Re: DSS2/PM on 3.2 broken?

[NeilBrown <neilb@suse.de>]

[-- Attachment #1: Type: text/plain, Size: 3400 bytes --]

On Sat, 14 Jan 2012 10:09:15 +1100 NeilBrown <neilb@suse.de> wrote:

> On Fri, 13 Jan 2012 04:31:37 -0700 (MST) Paul Walmsley <paul@pwsan.com> 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 #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 828 bytes --]