resume/suspend observations

Werner Almesberger werner at
Sun Feb 24 14:46:10 CET 2008

Andy Green wrote:
> Well, if it is broken I guess resume from Hold button is not a critical
> feature... does it have a scenario where it is useful?

Dunno. But we don't see HOLD at all, which is a bit nastier. Once
we can see it, I'm sure resume will work as well.

>> - if we suspend after having resumed with a PMU event (i.e., POWER
>>   or an RTC alarm), no other PMU event will bring us out of suspend

Seems that the interrupt is lost, so we don't get any more interrupts
from the PMU. Maybe we should switch to level-triggered interrupts
after all.

I've checked in a quick fix for this problem (revision 4104):

- drivers/i2c/chips/pcf50633.c (pcf50633_resume): after resume, process all
  pending interrupts, since we may have lost the interrupt that woke us up

I'll think about possible races in that one when I've had a bit of
sleep :-) I can now happily suspend and resume with POWER, until the
death in "Restarting tasks" gets the system (which happens every 2-5

> Matt is on that one.

Great. One item off my list :)

> The main difference between the git config and the stock one is that I
> moved most key drivers into the monolithic kernel.

Yep, and you have the accelerometers which are missing in my config.
Need to fix that. There are a number of differences in other options.
Many of them hopefully won't matter, but some might. We'll see.

>> - every once in a while, the kernel hangs right after initializing the
>>   Glamo, about 2s into the kernel start (this is not related to suspend)
> Hm.

Yeah, ugly.

> Curiouser and curiouser, since it is just my "=Y" config on your same
> tree.  That would make one think of a race we didn't take care of.

Could be. But there's a lot more than just =m -> =y, so it may
well be some non-essential driver that doesn't resume gracefully.

> I think we need a bit more of an explanation than blaming the (valid)
> config for these behaviours when it must be coming out of the code.

Naw, the .config is good. Just one of the things it enables isn't :)

- Werner

More information about the openmoko-kernel mailing list