Neo1973 suspend/resume

[Harald Welte]

Hi Ben & Werner!

We have integrated your patch into our u-boot, and we also have added
enable_irq_wake() calls to our 'gta01kbd' driver in
gta01-inputdevice.patch.  

This should resurrect the system when the '911 button' is pressed that's
the button on top of the device, close to debug port and Bluetooth
module on top of the LCM.

The button press causes interrupts, as can be clearly seen in
/proc/interrupts while the system is running.

the suspend is working quite fine:

===

PM: Preparing system for mem sleep
Stopping tasks ... done.
platform bluetooth: suspend
LM4857 I2C Amp 0-007c: suspend
WM8753 I2C Codec 0-001a: suspend
soc-audio soc-audio: suspend
pcf50606 0-0008: suspend
__reg_read: (pcf=c05e9400, reg=0x1b, val=0x1e)
__reg_read: (pcf=c05e9400, reg=0x1c, val=0x00)
__reg_read: (pcf=c05e9400, reg=0x1f, val=0xe8)
__reg_read: (pcf=c05e9400, reg=0x21, val=0xe4)
__reg_read: (pcf=c05e9400, reg=0x23, val=0xf8)
__reg_read: (pcf=c05e9400, reg=0x24, val=0x16)
__reg_read: (pcf=c05e9400, reg=0x25, val=0x10)
__reg_read: (pcf=c05e9400, reg=0x26, val=0x00)
__reg_read: (pcf=c05e9400, reg=0x27, val=0xf8)
__reg_read: (pcf=c05e9400, reg=0x2e, val=0x00)
__reg_read: (pcf=c05e9400, reg=0x2f, val=0x00)
__reg_read: (pcf=c05e9400, reg=0x35, val=0x00)
__reg_read: (pcf=c05e9400, reg=0x05, val=0x40)
__reg_read: (pcf=c05e9400, reg=0x06, val=0x00)
__reg_read: (pcf=c05e9400, reg=0x07, val=0x08)
__reg_write: (pcf=c05e9400, reg=0x05, val=0x75)
__reg_write: (pcf=c05e9400, reg=0x06, val=0x97)
__reg_write: (pcf=c05e9400, reg=0x07, val=0x3f)
jbt6k74 spi0.0: suspend
jbt_suspend: entering
jbt6k74_enter_state: entering(old_state=0, new_state=0)
s3c2410-ts s3c2410-ts: suspend
s3c2410-nand s3c2410-nand: suspend
s3c2410-usbgadget s3c2410-usbgadget: suspend
gta01_udc_command(2)
platform s3c2410-sdi: suspend
platform s3c2410-iis: suspend
s3c2410-i2c s3c2410-i2c: suspend
platform s3c2410-wdt: suspend
s3c2410-lcd s3c2410-lcd: suspend
platform s3c2410-ohci: suspend
s3c2410-uart s3c2410-uart.1: suspend
s3c2410-uart s3c2410-uart.0: suspend
platform gta01-pm-bt.0: suspend
platform gta01-pm-gps.0: suspend
platform gta01-pm-gsm.0: suspend
gta01-button gta01-button.0: suspend
gta01-bl gta01-bl.0: suspend
s3c24xx-spi-gpio s3c24xx-spi-gpio.1: suspend
PM: Entering mem sleep
platform bluetooth: LATE suspend
soc-audio soc-audio: LATE suspend
s3c2410-ts s3c2410-ts: LATE suspend
s3c2410-nand s3c2410-nand: LATE suspend
s3c2410-usbgadget s3c2410-usbgadget: LATE suspend
platform s3c2410-sdi: LATE suspend
platform s3c2410-iis: LATE suspend
s3c2410-i2c s3c2410-i2c: LATE suspend
platform s3c2410-wdt: LATE suspend
s3c2410-lcd s3c2410-lcd: LATE suspend
platform s3c2410-ohci: LATE suspend
s3c2410-uart s3c2410-uart.1: LATE suspend
s3c2410-uart s3c2410-uart.0: LATE suspend
platform gta01-pm-bt.0: LATE suspend
platform gta01-pm-gps.0: LATE suspend
platform gta01-pm-gsm.0: LATE suspend
gta01-button gta01-button.0: LATE suspend
gta01-bl gta01-bl.0: LATE suspend
s3c24xx-spi-gpio s3c24xx-spi-gpio.1s LATE suspend
aved f0000008 value 657e3fcf
saved f000001c value 000001fe
suspending dma channel 0
suspending dma channel 1
suspending dma channel 2
suspendingsdma channel 3
3c2410_pm_enter(3)
Found system RAM at 30000000..37ffffff
Area 30000000..37ffffff, 2048 blocks
s3c2410_pm_prepare_check: 8192 checks needed
s3c2410_sleep_save_phys=0x360fde68
saved f6400000 value 005e47ff
saved f6400004 value 00000000
saved f6400010 value 00145416
saved f6400014 value 0000013e
saved f6400018 value 000007ff
saved f6400020 value aaaa12a9
saved f6400024 value 000000ec
saved f6400028 value 0000ffff
saved f6400030 value aaaaaaaa
saved f6400034 value 00000000
saved f6400038 value 0000ffff
saved f6400040 value a02aaaaa
saved f6400044 value 0000ffd9
saved f6400048 value 0000ffff
saved f6400050 value 0000aa19
saved f6400054 value 0000007e
saved f6400058 value 000000ff
saved f6400060 value ff425041
saved f6400064 value 000001fe
saved f6400068 value 0000afef
saved f6400070 value 0000faaa
saved f6400074 value 0000075f
saved f6400078 value 000007ff
saved f6400084 value 00000000
saved f0200000 value 00ffffff
saved f020000c value 000b7de0
saved f0100000 value 2211d120
saved f0100004 value 00000700
saved f0100008 value 00000700
saved f010000c value 00000700
saved f0100010 value 00001f4c
saved f0100014 value 00000700
saved f0100018 value 00000700
saved f0200014 value 00000003
saved f0200004 value 00090070
saved f0200008 value 00078023
saved f0200010 value 00000004
saved f0100024 value 009e03e5
saved f0400000 value 00000003
saved f0400004 value 00000385
saved f0400008 value 00000011
saved f040000c value 00000000
saved f0400028 value 0000001a
saved f0404000 value 00000007
saved f0404004 value 00000385
saved f0404008 value 00000011
saved f040400c value 00000000
saved f0404028 value 00000000
saved f0408000 value 00000000
saved f0408004 value 00000000
saved f0408008 value 00000000
saved f040800c value 00000000
saved f0408028 value 00000000
Disabling IRQ 17 (pin 161)
Disabling IRQ 48 (pin 164)
Disabling IRQ 49 (pin 165)
Leaving IRQ 50 (pin 166) enabled
Leaving IRQ 51 (pin 167) enabled
sleep: irq wakeup masks: ffffffff,ffffff3f
GSTATUS3 0x302e3d08
GSTATUS4 0x00000000
Found system RAM at 30000000..37ffffff

===

If I use JTAG to interrupt the system, it halts somewhere in the CRC32
code, which is good.  resume + halting it a bit later results in a
timout (CPU seems to be in power_off state now).

If I then press the button and generate the wakeup-irq, the backlight
becomes bright for something like estimated 250ms, but the content
slowly fades out (no LCM refresh happening) and n the system
seems to power-off again, since the JTAG adaptor continues to issue

> Error:   arm7_9_common.c:561 arm7_9_execute_sys_speed(): timeout waiting for SYSCOMP & DBGACK, last DBG_STATUS: 0

The CPU does not want to halt on JTAG request, at least not if that
request is issued before the wake-up event happens.

Do you have any experience in using JTAG to single-step the resume
procedure?

Also, some other notes:

1) If there are no wakeup sources, the suspend seems to almost complete
(display off, etc.) then there's the message about no wekeup soucres,
and it powers up everything else again.  This means the suspend/resume
functions in our drivers seem to basically work.

2) As you know, current hardware doesn't care about the PWREN output and
thus leaves VDDi/VDDiarm/VDDi_*PLL enabled while in Power_off.  Can this
be the reason why resume isn't working as expected?

Any other ideas?

-- 
- Harald Welte <laforge at openmoko.org>          	        http://openmoko.org/
============================================================================
Software for the world's first truly open Free Software mobile phone