Re: DSS2/PM on 3.2 broken?

[NeilBrown <neilb@suse.de>]

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

On Wed, 11 Jan 2012 06:43:04 -0700 (MST) Paul Walmsley <paul@pwsan.com> 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?

I haven't experimented with off-mode much.  When I try it the suspend-time
current drain goes from 65mA to about 90mA which doesn't seem the right
direction.  The only other observation is that the "cam" power domain
doesn't reach the target state of '0'.  I'm guessing they are related but
haven't progressed further. (I don't have anything like a camera driver
compiled in - nor do I have a camera attached).

So it is just retention.

I occasionally see evidence of a garbled char when I wake from suspend, but
that doesn't bother me much.

I spent some time exploring why cpuidle never drops below state 0 and found
out that the code explicitly disables other states when uart is active - for
a fairly broad definition of 'active'.

I found the "sleep_timeout" setting and set them all to 1 second.  This meant
that cpuidle started working, but I got a lot of garbage characters.

> 
> 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.

Does this really mean CPU_IDLE cannot be used when you might expect chars
from a serial port - e.g. GPS or Bluetooth?
Which power domain needs to stay non-off?  I would guess 'CORE' for UART1,2
and 'PER' for UART3,4.  I'm using UART3 for the console port, but it looks
like 'PER' doesn't get switched off by CPUIDLE.

What is the important issue here that I don't know about ? :-)

> 
> >  - dss loses sync
> 
> Best to take this up with the DSS maintainer directly.
> 
> >  - HDQ seems to lose everything.
> 
> Is this with off-mode enabled, or just with retention idle?

Not off-mode - just retention.

> 
> 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. 

The HDQ driver does enable/disable the iclk and fclk.  I thought I read that
having the clocks enabled would prevent the powerdomain from dropping to a
lower-power state ??

Could you suggest some other driver which does do the right sort of runtime
PM that I could try copying?

Thanks,
NeilBrown


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 828 bytes --]