gta04 modem - blink led only on KEY_UNKNOWN

Events are comming also after resume, but they dont have KEY_UNKNOWN
code.

http://lists.goldelico.com/pipermail/gta04-owner/2012-July/002660.html
qtopianamespace - cleanup the RTC functnions
gta04 - implement race free suspend

http://lists.goldelico.com/pipermail/gta04-owner/2012-July/002587.html

[Gta04-owner] Kernel update for gta04
NeilBrown neilb at suse.de
Sun Jul 8 11:46:40 CEST 2012

    Previous message: [Gta04-owner] Kernel update for gta04
    Next message: [Gta04-owner] Kernel update for gta04
    Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

On Sun, 08 Jul 2012 11:13:59 +0200 Neil Jerram <neil at ossau.homelinux.net>
wrote:

> NeilBrown <neilb at suse.de> writes:
>
> > 1/ my phone would often crash on resume.  I found one bug which is already
> >    fixed in 3.3, and another that is still present in mainline.
> >    More details can be found at http://neil.brown.name/blog/20120706122934
>
> I think I've seen that - except does it (or did it) make sense that
> sometime later the phone will wake up again?

No.  Both these bugs were permanent death.  One was an infinite loops with
interrupts disabled, the other was the uSD card interface locking up.

>
> My experience was:
> - Phone was suspended.
> - I heard the QtMoko beeps as for a message arriving.
> - Went to the phone, saw that it was off, pressed power button: no
> effect.
> - Guessed that the beeps were actually a critical battery alert, and
> that the battery had run out; went to bed.
> - Following morning, heard beeps again.
> - Went to the phone, saw that it was off, pressed power button: phone
> lit up as it should.

This must have been something different.

>
> BTW, there's one typo in your blog: "should be be" -> "should not be".

Fixed, thanks.

>
> > 2/ I added 'wakeup_sources' for the buttons, RTC alarm, and 3G interrupt.
> >    This means that if one of these happens while an auto-suspend is happening,
> >    the suspend will abort.  It is probably quite rare than an alarm will fire
> >    or a TXT will arrive just as the phone is suspending, but it can happen and it
> >    is good to be able to avoid it.
> >
> > 3/ I've also updated to the latest -stable version for each.
>
> Nice, thanks.
>
> >  The simplest way to avoid races with suspend is:
> >  -  read /sys/power/wakeup_count and record the number
> >  -  final check that no buttons are pressed etc
> >  -  write the recorded number to /sys/power/wakeup_count
> >  -  If that succeeds, write "mem" to /sys/power/state
> >
> >  though it works better is the platform is enhanced to to auto-suspend
> >  properly.
>
> I don't get this.  Is this more detailed exposition of how you made
> 'wakeup_sources' work, or is it an alternative to the 'wakeup_sources'
> work mentioned above?

Neither.
To get race-free suspend you need support in the kernel and in user-space.
The kernel side requires that wakeup-events identify themselves.  Last I
checked, *nothing* in the kernel identifies as a "wakeup source".  My kernel
changes told the power-button, aux-button, RTC alarm and 3G interrupt to
identify themselves as wakeup sources.

The user-space side is what I was trying to outline here.
Normally wakeup events will wake from suspend, but if they happen moments
before the suspend request completes, they can be missed.  User-space needs
to first request that the kernel abort the next suspend if a wakeup event
occurs between now and when the suspend completes, then check that no events
happened just before it made that request, then request suspend.  That is
what the above sequence does.
I have a little collection of code which makes this fairly easily available
to programs - currently called 'susman'.
  git://neil.brown.name/susman

I use it in a mode where it requests suspend whenever nothing is explicitly
disabling suspend.  Then my screen-lock program and my 'gsmd' and various
other bits need to explicitly disable suspend while they do what they need to
do.  You can also use it in a mode where suspend needs to be explicitly
requested.

As of 3.5 there is code in the kernel which does the core part of this.
Whether that is easier or harder to use remains to be seen.  It was added
because that is more like how Android works.

>
> > I haven't played much more with 3.5-rc.  The power usage is still way too
> > high.  I've seen some messages on the linux-omap list which suggest that
> > might be fixed soon.  So I'll probably get back to it at the next -rc, or
> > maybe 3.5-final.
>
> Thanks for keeping this mainline tracking going!
>
> Out of interest, what is your personal plan for user space?

I have a bunch of little bits and pieces that I wrote myself - because I'm a
NIH kind of guy.  Mostly python with bits of C when needed.
Being in control of, and very familiar, with all the code makes it easy to
experiment with auto-suspend etc, and is a great learning experience :-)

I'm occasionally tempted to use QTMoko because it is much more complete and
generally nicer than the bits I've hacked together, but then I'd probably
need to learn Qt, and maybe even C++, to do any programming and I'm not sure
I really want to.

NeilBrown