alarm - make the vibrations start after 30s

It's quite annoying to be woken up by the vibrations. So give user
1 minute with sound alarm before starting vibra motor.
qtopiabase - new function rtcNow() for reading real time clock
alarmcontrol - fix and cleanup alarms

Alarms were broken. They rely on bundled atd crap which is used just
to wake the phone up from suspend. When phone is woken the code checks
for nearest alarm and starts ringing if found.

The problem is that wakeup interrupt triggered by atd is using RTC time
and the code for alarm check is using system time and Qt timers. If RTC
and system time get out of sync the phone is put in suspend and never
wakes up by RTC anymore.

So the fix is to also remember the alarm time in RTC clock time and check
for both. We also do the check for alarm after resume.

Another nice thing now is that we can get rid of bundled atd which was
holding /dev/rtc0 open and utilities like hwclock were not working because
of this.
alarm - enable suspend after users acknowledges the alarm
alarmcontrol - reformat code with indent.sh and remove debug stuff
get rid of bundled atd
gta04 merge - neocontrol variant for gta04

This is taken from master_gta04 branch.
qx - merge and ifdef changes in master_gta04
alarm - implement custom tones
alarm - hack to stop sound

just calling alarmt->stop does not work for long ogg file
alarm - add some tones from android

They should be free licensed, see android license for details
alarm - better handle vibrate delay
neocontrol - add tab with RTC info
qtmaze - use QVibrateAccessory

Vibration now works on GTA04 too
gta04 - read and report via led interrupts from modem

We are reading /dev/input/incoming which generates input event on
incoming call or SMS.

When new event arrives we set fast blinking on the AUX green led.
If it apppears to be call then we switch to slow blinking (already
implemented in qmodem after incoming call AT command arrives).

If it's not call we leave it fast blinking and this indicates SMS.
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
debian - attempt for multi package
debian - dont delete debhelper files in rules, fix install files