Regression on U-boot without batery [was: u-boot low-battery handling]

Mike (mwester) mwester at dls.net
Wed Aug 27 02:32:04 CEST 2008


Andy Green wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Somebody in the thread at some point said:
> 
> | echo 0 > /sys/bus/platform/devices/neo1973-pm-gsm.0/power_on
> |
> | then put it to sleep it doesn't really go all the way to sleep. an ssh
> | via usb ethernet still works. But, if I do
> |
> | echo 1 > /sys/bus/platform/devices/neo1973-pm-gsm.0/power_on
> |
> | then put it to sleep it locks up. This is with the 2.6.26 kernel.
> 
> That sounds really interesting... so suspend part panic'd or spins with
> interrupts up in the first case.

I've seen similar strangeness occur.

On my "TTBD" (Things To Be Done) list, yellowing with age, is a note
that tells me that I intended to do the following few tests to see if
this might expose something:

a) remove the code disabling the UART clocks for all UARTs on suspend
(in the serial driver) and enable the ifdef'd code in plat-s3c24xx/pm.c
  that saves/restores the UARTs' registers on suspend/resume.

b) disable AFC at suspend for any devices found with AFC enabled
(*before* the clocks are shut down), and restore it at resume time.

I've not had time to try this myself, but perhaps the results would be
interesting if someone were to give this a shot.

Of course, a manual code walk-through just to make sure that none of the
GTA01 code is doing anything on the GTA02, and that we don't end up
walking off the end of allocated memory or any such thing, might be good
too.

[I also can't resist a comment, in line with Andy's recent comments
about bringing up sore points repeatedly so we don't repeat the mistake.
 I cannot trust ttySAC0.  I don't care how strongly people insist that
"console=ttySAC2" fixes *every* reference to UART0 as the console
device, I remain deeply suspicious.  Let's make sure that the GSM is on
UART1 on the GTA03 - why fight long-held tradition and linux-cultural
assumptions?]

Mike (mwester)



More information about the openmoko-kernel mailing list