[suspend/resume] if press power batton right after suspend, the device won't wake up

[wendy_hung]

Summary:
[suspend/resume] if press power batton right after suspend, the device won't wake up

kernel:20080826-asu.stable-uImage.bin
root file system:20080827-asu.stable-rootfs.jffs2

Steps+current results:
1) wait the device go suspend or press the power button to make the device suspend
2) press the power button right after device goes to suspend
3) the device won't wake up right away, have to press again or just never wake up...

Reproduceable:
sometimes

Expected:
should wake up from suspend time

[Treviño]

I've the same using the latest kernels available in repositories or in buildhost since long time, that's why until this evening I've always used the mwester stable kernel (that btw had some issues too as you can read here).

This evening, in fact, I've tried to get the latest stable kernel from git to which I've applied also the latest glamo patches (fix-glamo-turbo-host-interface.patch and fix-glamo-crank-memory-to-90MHz.patch taken from the andy branch in order to try to fix my problems with (X)glamo that has always freezed to me after few minutes of usage - more here).

Well, while using the latest mwester kernel I was able to make it suspend and resume nicely only if it was never attached to USB power (read above) - but I had the glamo freezes (I used Xfbdev infact) - now, using my own compiled kernel (using the defconfig-2.6.24), I've never got a glamo/xglamo freeze but I neither was ever able to wakeup the phone from a suspension (like with the latest stable kernels)!!!

Pratically every time I press the power button to suspend, I've to remove the battery to make it reboot again.

I could attach also my image for tests. Maybe only my Freerunner refuses it :|.

[Treviño]

I've just tried to kill X and loading apm -s.
Phone suspends but, again, it freezes and won't come up until forced reboot :/

[Treviño]

Another try. I've turned on a led and then launched apm -s. Well... The led didn't turn off for about 40 seconds (maybe more).

This should mean that the phone didn't go to sleep until then (isn't it?). However pushing the power button and waiting minutes doesn't help :(

[hbernard]

I can confirm this on a up2date 2008.08. This is a bit painful to test because I have to remove the batery after that.

Before doing it again, what are the log files that are needed here to help ?

[andy]

What probably happens here is PMU interrupt is stuck low during suspend time.

That means power button press and USB jack insert / remove won't wake any more.

If that's the case, other wake source may still wake the device... try inserting headset jack or removing it and seeing if that gets you a wake. After that, because we clear the PMU interrupt source on resume, you might be OK again with PMU sources.

[Treviño]

Tried. Nothing changed... :( To resume:
* Powerbutton doesn't wakeup
* Incoming call/sms doesn't wakeup
* Usb cable inserting doesn't wakeup
* Headset jack inserting/removing doesn't wakeup

Simply, doesn't wakeup :|. I just hope that all these battery remotion won't damage it...

[hbernard]

Mhh, since the update of today (I think I didn't reboot at the time of my last comment), I can't reproduce exactly the same.

What I'm able to reproduce :
* powerbutton to put in suspend
* powerbutton right after (during the darkening effect of suspend)
* wait some seconds
* powerbutton resume, but the display fade to dark soon after ang go back to suspend
* (I can repeat the above line several times)
* It seems when I wait some more seconds (10 or 20), it resumes OK

I also tested the wake from jack, which is working OK

Not sure it helps... Trevino, are you using an up2date 2008.08 ?

[Treviño]

Well, not completely... As said above I'm using only a bleeding edge kernel (well, not so much :P) but the rest of the software stack I'm using come from the zecke update of about a week ago.

I'll try to upgrade...

[Treviño]

I can confirm that this is a kernel issue: I've put my kernel (the stable+glamo-patches explained above) in the microSD kernel partition overwriting the mwester-kernel (that worked flawlessly) I had there.
Well, now qtopia (the distro I've in the SD) suspends but doesn't resume at all (while it worked with no problems using the mwester's uImage-gta02-mwester-stable-d6f9fd270943fb22.bin image).

I figure that using qtopia-fb the glamo patches (taken from andy) I've added doesn't disturb the suspending work (well glamo should be initialized anyway but I guess it isn't in use), isn't it?

[Treviño]

Well, I've tried again with a stable kernel from git d744c88c149269b95ec068c8615e492375415d6d that I've configured using the defconfig-2.6.24 and patched only with linux-glamo-mpeg.patch and fix-glamo-crank-memory-to-90MHz.patch. Now suspension (well, it would better say "resume" since the phone has always gone into sleeping) works and I can resume the phone quite in all the tests I've done.

So, the andy kernel branch has problems in resuming and I figure that they're due mostly to the patch: fix-glamo-turbo-host-interface.patch. In fact, if I enable this with my configuration I get a fps speedup (I don't know if it's only a placebo effect, btw :P) but the phone doesn't resume at all!

I've just to say that the first suspension is longer than the others (I can check it turning on a LED, it takes some seconds more to turn off the first time). Is this a known issue?

PS: this is not in theme, but I've to underline that the fix-glamo-crank-memory-to-90MHz.patch fixes all the glamo hangups/freezes I had using Xglamo.

[matt_hsu]

Problem statement:

This issue is result from the INT is trapped in the PMU when system is getting into suspend. During the time of getting into suspend, there's a window that the I2C device is suspended. This interrupt from PCF50633 can't be READ & CLEAR in this moment. So you could not wake the system anymore.

In my opinion, there are three approaches which could resolve this issue.

1. Like HXD8, add an alternative INT pin to S3C2442. This this pin as a wakeup source.
2. Extend the debounce time of ONKEY. But this will change the behavior of users.
3. Use bitbang to R&C the INT register of PMU in the last moment(this sounds crazy).

[andy]

What happens if we read the level of the EINT for PMU as GPIO input at the end of suspend, and abort the suspend (ie, resume) if we see it is active?

What happens if we turn PMU interrupt to level instead of edge? Previously it made trouble but that was before 2.6.24 and we never really understood the mechanism anyway. Maybe just using level will clear this issue (by forcing wake from EINT under these circumstances).

[matt_hsu]

This issue is resloved in stable-tracking branch.

According to Werner and Andy's suggestion, I changed the interrupt type of pcf50633 driver
and do some rework on s3c24xx power management routine.

[wendy_hung]

if it's gonna happen in new kernel, we did not see that in Dec.02's image yet.
tested with Om2008.testing image:
Kernel: testing-om-gta02-20081202.uImage.bin
rootfs: openmoko-testing-om-gta02.rootfs.jffs2 (2008.Dec.02)

Still happen with this problem, it just never wake up. Leave it as open until we really get it in testing phones.

[andy]

Hello Wendy - this issue was marked by Matt as fixed in stable-tracking, it means that it is meant to be solved in the new 2.6.28 kernels that will replace the current stable ones based on 2.6.24.

I really think you need to start testing with the 2.6.28 ones, because for some weeks we no longer really do work on the 2.6.24 branch.

I will talk to John Lee and see if we can get packages made for it if we don't already so you can test with it easily.

[wendy_hung]

Hi Andy, thanks for your reminding. In QA's work flow, we test the status of the testing builds. To put the ticket into "fixed" for us means we can't see the bug anymore.
We would like to test it ASAP, but it seems the new kernel is not in the testing build yet. Can you help bringing it there, so that we can start testing it?

[andy]

Understood... I just added a packaging config for John Lee to use to make these new packages and posted about it on the kernel list. So hopefully soon you will be able to easily use the new 2.6.28 stuff and tell us about all the bugs you find :-))

[andy]

Wendy did you try this with a recent 2.6.29-rc2 kernel lately?

[wendy_hung]

Hi Andy,
i think this can be close as the kernel fix, but it does not work in om2008.12.
So the kernel fixed, but not the image.