Re: DSS2/PM on 3.2 broken?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.

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

What baud rate?

If I use 57600 or lower I see no problem at all.  The first char I type gets
through fine.
If I try higher rates (115200 is the default, I've tried 230400 and 460800)
I get consistent corruption, though different corruptions at different rates.

I've tried enabling hardware handshaking but it makes no difference -
however it is possibly there is something wrong with the wiring so I'll check
that before pursuing that direction much further.

Presumably with working hardware handshaking we should be able to avoid any
loss or corruption??

(I'm not sure if I said - but the board I am working on is the GTA04 Openmoko
board: www.gta04.org).

Thanks,
NeilBrown

Attachment: signature.asc
Description: PGP signature


[Index of Archives]     [Linux Arm (vger)]     [ARM Kernel]     [ARM MSM]     [Linux Tegra]     [Linux WPAN Networking]     [Linux Wireless Networking]     [Maemo Users]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite Trails]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux