suspend/resume to RAM support

[laforge@…]

implement missing bits in our own drivers, plus test and verify that suspend and
resume works reliably.

[laforge@…]

Also assigning this mainly to werner. I will help him, while I'm concentrating
on GSM related stuff.

[laforge@…]

moving this to phase-1, we've relaxed our requirements ;)

[laforge@…]

this is working quite fine now (from a software point of view).

[mickey@…]

Reopening since it sometimes fails.

Kernel 2.6.22.5, U-Boot from 20.11.2007, on wakeup it hangs with:

s3c2410-i2c: cannot get bus (error -110)

[willie_chen@…]

Re-try on GTA02.

[spamisevil@…]

Is there any hope of getting this fixed on the GTA01? This is a real blocker in
terms of testing this device in real use-case scenarios. Is the issue with the
actual hardware, or can it be fixed in software?

[laforge@…]

AFAIK, for GTA01 this has been working for ages. So don't worry, this bugzilla
entry should be GTA02-only these days.

[mickey@…]

just confirmed that to be still a problem on gta01 w/ 2.6.24 (r4065),
interestingly enough only if you wake up using the Power Button. If you wake up
using the AUX button, it reliably resumes ten times in a row.

(note: reassigning to default owner)

[andy@…]

I created fix-i2c-s3c2410-resume-race.patch which I think will resolve this,
it is in git and svn #4111 and above so no point adding it here.

Let me know if you can create the issue after this patch.

[andy@…]

Please reopen if it is still happening... closing due to it should be fixed
and continuing spam about it being open on kernel list.

[reddog@…]

The resume from suspend is still problematic on GTA01v4.
Powerbutton, Auxbutton and Modem can wake but often crashes! Powerbutton is also
broken after wakeup with powerbutton (as seen on #1313)!

[mwester@…]

Confirmed. With the latest kernel, suspend/resume fails most (but not all) of
the time.

With X and GSMD *not* started, nothing plugged into the USB port, and logged in
via the console on the debug board, echoing "mem" to /sys/power/state will cause
a suspend. Using the AUX button to resume will usually result in an attempt to
resume (as seen on the console), but the console will be unresponsive. Using
the POWER button to resume will randomly appear to work, or not, and when it
appears to work, it seems to hang the kernel shortly thereafter. Occasionally
when resuming, the display will go all monochrome, and begin gradually cycling
through colors, changing in subtle patterns through a veritable rainbow of
colors that would have made this a really cool special effect for a 1970's
throwback party!

Work needs to be done to better define the failure mode; suggestions on how to
proceed will be graciously accepted.

[mwester@…]

Patch to register the SPI device and thus the save/resume for the display

[mwester@…]

Restore power button functionality after resume operation

[andy@…]

Thanks for the SPI patch, this is in stable and andy now.

Can you please add Signed-off-by: though? Upstream won't accept patches
without it. I added it in this case but I can't go on doing that.

[andy@…]

I also added the 50606 missed edge after resume patch to stable.

On GPS power, Holger has been here already a few days ago and it is in stable
git branch for some days.

​http://git.openmoko.org/?p=kernel.git;a=commitdiff;h=73a213f11aed2b9328ebd01de

[reddog@…]

I didn't tested the GPS stuff.

I booted with the new kernel from mwester, all seems to be fine.

1st try:
-Entered suspend via "echo mem > /sys/power/state" ... ok
-Woke it up by the power-btn ... ok
-Can't see something very special in dmesg
-Power-menu works :-) very good work! thanks!
-I don't know if sound works ... madplay says /dev/dsp busy!
openmoko-mediaplayer (wich looks very nice btw) says that i don't have the
gstreamer decoder plugin installed if i try to play an mp3. Will later try sound
when it's freshed booted (then it works for shure, because i can here the
startup sound)
-GSM seems to work, dialed my second number and it ring. I'm in train and GSM
registers to different networks, all seem to be fine! At this point i have to
say, that i have removed the console=xyz boot option in uboot!

2nd try:

• Also entered suspend via "echo mem > ..." because i don't know any other way

for it atm.

• Woke up by AUX-btn
• I tried to call my second phone, but my second phone doesn't ring. Instead of

a ringing phone, i could here a nice voice, wich told me that "the number you
are calling is temporary not available..."! Very nice, my old nokia sometimes
has a problem with network registration, but this shows me, that the sound
generally works!

• Power menu again works... very nice! :D

3rd try:

• Woke up by power-btn
• Again, with my limited knowledge, i can't see anything special in dmesg
• This time, i tried to receive an sms. It worked, but openmoko-messages put the

message in the wrong folder! I opened a new Bug.

• Then i sent a sms, and it worked also.

The next 4th to 7th tries, it woked up fine by using the power-btn.

8th try:
Woked up by AUX-btn

9th try:
I used my second phone to call neo ... neo woke up, shows incoming call, but
doens't ring!

10th try:
I used again my second phone to send a sms to he neo ... nothing ...
Woke up by AUX-btn ... waiting ... no sms!! Hmm, who got my sms?? I, looked at
send-objects on my nokia and it shows me, that i sent the sms to the neo. Bad!

11st try:
Woke up by AUX-btn

12nd try:
Woke up by (uh .. forgotten)

13th try:
Woke up by power-btn

14th try:
Woke up by aux

Now my time is over ...

I will send it to sleep and will later look at battery status...
now it is 10:40

[...]

So i'm back and it is 11:40, one hour later!
I pressed AUX-btn: now it got a white screen but it is awake, i can ssh into it.
apm says:
Off-line: 94%

so about 6% in one hour, if we could trust this apm message.

I thought to give it a try to suspend again:
-echo mem > ...
-woke up by AUX-btn, but again white screen!

A restart of x doesn't help, it has again a white screen. But it has vibrated,
that could be the missing sms?

Now i reboot the phone!

I attach the last dmesg (20080414.dmesg), in it are some old lines and the
latest after the white screen.

[reddog@…]

the dmesg log, when neo got white screen

[mwester@…]

Preserve the GPS power state over suspend/resume - temporary patch

[mwester@…]

Add missing platform_data that caused the GTA01 to crash on suspend/resume

[mwester@…]

With the above two patches added, the GTA01 seems to be almost functioning in
terms of suspend/resume of the kernel (I'm not yet considering user-space).
Several major open items include:

a) when booted to console mode (i.e. no X server), the screen is all white on
resume; the expected behavior is that the text content of the display should be
restored on resume.

b) console interference with the GSM modem may still exist; several anomalies
were noted in the console output that imply that the serial FIFOs are not empty
when the serial port is switched to and from the GSM device; this can't help
with syncronization with the modem. (Another problem is a user-space issue;
the stty commands were removed from the gsmd startup script leaving the console
non-functional when gsmd exists.)

The combination of (a) and (b) makes debugging of the GSM device during
suspend/resume very difficult, but the real blocking problem is (a). The
framebuffer console is the only functional place to log debug data while the GSM
device is active; thus we need to get that functioning over suspend/resume
cycles in order to work on the real big issue, which is (c):

c) The GSM device cannot reliably wake the CPU while the CPU is suspended. I
have two GTA01s, with different firmware. With the same kernel and rootfs,
sending SMS messages to each results in no activity. Incoming phone calls will
wake one of the two, but not the other. The one that wakes does not answer the
call; this is probably the missing characters after resume problem noted
elsewhere by the community.

This is the current status, then. Any suggestions or assistance in solving the
display/framebuffer console suspend/resume issue would be gratefully accepted.
Once that's resolved, we'll be at parity with the 2.6.22 kernel on the GTA01,
and we can begin work on characterizing and resolving the GSM modem wakeup issues.

[reddog@…]

i just did this via ssh:
/etc/init.d/xserver-nodm stop
apm -s; fbset vga

*press key*

and voila ... screen is back! :D

[reddog@…]

fix resume of fbdev

[andy@…]

Thanks guys you have done some great work here. I believe I captured all of
these patches into the andy/stable/andy-tracking now.

On the GSM wakeup thing, have a look through your .config and make sure about

CONFIG_S3C_LOWLEVEL_UART_PORT=x

Where x should somehow be 0 or 2 depending on if you are GTA01 or not. It
says where late suspend messages should go... maybe it makes sense to try to
disable CONFIG_S3C2410_PM_DEBUG and see if it helps with the suspend issue
too.

[mwester@…]

Updated kernel config file for the GTA01 to resolve GSM resume problem

[mwester@…]

The final kernel config change for the GTA01 brings the device to the same point
that the GTA02 was at some days ago -- suspend/resume seems to work, however
since there is no gsmd support yet for suspend, anything will wake the device
from suspend.

One of my devices (T-Mobile SIM) will suspend, but will not resume on an SMS
message. It will resume, however, on an incoming call -- but the device is so
slow coming out of the deep standby state that you usually cannot answer the
call before it is missed.

The other device (Cingular/AT&T SIM) will suspend and immediately resume. Once
in a long while it will actually stay suspended for a few minutes before some
activity on the GSM device wakes it back up.

So, at this point, the major issues with the GTA01 kernel are addressed. We
still need feedback from the community, but while that is happening, the next
items to work on include determining what else is supposed to wake the device,
and testing those wake events, as well as testing other general GTA01 functions
for recovery over suspend/resume (gllin, bluetooth, usb networking).

[werner@…]

Great progress, congratulations Mike !

We had that immediate wakeup on GTA02 as well, but I don't remember what
caused it. Could this have been noise on JACK_INSERT ?

• Werner

[reddog@…]

another phone calling -> neo: hearing on both sides the clicking sound when i
knock the other device on the table.
suspend ... resume
another phone calling -> neo: hearing on the "another phone" side doesn't work
anymore.

I didn't have enough time for testing yet, but it seems that the mic doesn't
work on receiving a call after resume.

[andy@…]

Is it possible that

alsactl restore

can help with the mic issue Tim, after resume?

[reddog@…]

I test this... now neo is booting.
I enter the PIN. (Btw: there is a click when i touch the screen)

Now i use my other phone (nokia) to call the neo:
Neo rings and vibrates ... i catch it up: Hrm ... to late! :-(
Again:
Neo rings and vibrates ... i catch it up: Ok, this time it works!
I knock the nokia on the table and can hear this on the neo.
I knock the neo on the table and can hear this on the nokia.
If i puff in the phone and not knock the phone, i get the same result.

Now i use the neo to call the nokia:
Nokia rings and vibrates ... i catch it up:
Same tests, same results! And, btw the voice quality seems very good!

Now i pres the power-btn and my patched neod brings up a nice menu in wich i
press "Suspend Phone". Now the goes with ne "apm -s" command in suspens.

... tuedelue ...

Wake up with Power-Button:
Now there is no click when i touch the screen anymore!

I use my nokia to call the neo:
Neo _doesn't ring_ but vibrates ... i catch it up:
I knock the nokia on the table and can hear this on the neo.
I knock the neo on the table and _can't_ hear this on the nokia.
If i puff in the phone and not knock the phone, i get the same result.

Now i use the neo to call the nokia:
Nokia rings and vibrates ... i catch it up:
I knock the nokia on the table and can hear this on the neo.
I knock the neo on the table and _can't_ hear this on the nokia.
If i puff in the phone and not knock the phone, i get the same result.

Ok, the bug is still there and now i will enter alsactl restore via ssh.
The touchscreen click isn't there.

I use the nokia to call the neo:
Neo _doesn't ring_ but vibrates ... i catch it up:

I knock the nokia on the table and can hear this on the neo.
I knock the neo on the table and can hear this on the nokia.
If i puff in the phone and not knock the phone, i get the same result.

Seems that the alsactl helps with the mic, but not the ringing and clicking.
Could this be a pulseaudio error?

But generall i think it's not correct to restore the alsa state after resume!

[nigel@…]

Using the alsa utils to save and restore the volume settings is the right thing
to do. For some reason that's unknown to me, the alsa developers have decided
that post-resume, output should be muted, not restored to the pre-resume values.

Then again, from what you describe it sounds to me like the volume might already
be being restored. *shrug*

[reddog@…]

But i think pulseaudio don't likes the suspending:
I started pulseaudio:
/usr/bin/pulseaudio -vvvv --no-cpu-limit --resample-method=trivial -nF
/etc/pulse/session
suspend/resume and then i get:
W: module-alsa-sink.c: Got POLLERR from ALSA

A little google told me, that this could be an alsa bug. Pulseaudio can just
reinit the audio, but as i saw this in our version this is already implemented
but didn't help!

[mwester@…]

Current status: In additional to all the patches to date on this bug report, one
must currently remove ttySAC0 from the boot parameters in u-boot. There remains
a race condition wherein the console is re-activated at resume time despite
being disabled when the GSM is powered up.

I have strong feelings about a solution to this, but this probably isn't a good
forum for that discussion, so for the moment users need to edit their u-boot
environment to remove the ttySAC0 from the bootargs.

[anonymous]

Milestone Phase 1 deleted

[andy]

What's the current situation with GTA01 suspend and resume? GTA02 suspend and resume seem to be working well on current stable, the last post is 7 months old on this one.

[mwester]

The current situation with the latest (2.6.29) kernel is unknown from a "in-the-field" point-of-view (few users, if any, I expect) -- but this ticket has probably outlived its usefulness. Time to close it, and any new issues found should open new (more specific) tickets instead.