Re: [PATCH 12/12] [RFC] Introduce Alarm (hybrid) timers

[Arve Hjønnevåg]

On Wed, Jan 5, 2011 at 6:15 PM, John Stultz <john.stultz@xxxxxxxxxx> wrote:
> This patch introduces a new type of hybrid timer, called
> alarm-timers.
>
> Alarm-timers are similar to hrtimers, but when a system
> is suspended, the RTC device is set to fire when the soonest
> alarm timer expires.
>
> Alarm-timers are exposed to userland via the posix clock and timers
> interface, using two new clockids: CLOCK_REALTIME_ALARM and
> CLOCK_BOOTTIME_ALARM. Both clockids behave identically to
> CLOCK_REALTIME and CLOCK_BOOTTIME, respectively, but timers
> set against the _ALARM suffixed clockids will wake the system if
> it is suspended.
>
> The concept for Alarm-timers was inspired by the Android Alarm
> driver (by Arve Hjønnevåg) found in the Android kernel tree.
>
> See: http://android.git.kernel.org/?p=kernel/common.git;a=blob;f=drivers/rtc/alarm.c;h=1250edfbdf3302f5e4ea6194847c6ef4bb7beb1c;hb=android-2.6.36
>
> The android alarm driver was built on top of direct RTC
> manipulation, and also implemented its own rbtree timer
> code, so instead of trying to porting it over to my
> timerlist and RTC timer code, I just re-implemented the
> basic functionality roughly following the android in-kernel
> interface.
>
> Another distinction is that while the in-kernel interface
> is pretty similar, the user-space interface for android alarm
> timers is via ioctls. As mentioned above, I've instead chosen
> to export this functionality via the posix interface, as it
> seemed a little simpler and avoids creating duplicate interfaces
> to things like CLOCK_REALTIME and CLOCK_MONOTONIC under alternate
> names (ie:ANDROID_ALARM_RTC and ANDROID_ALARM_SYSTEMTIME).
>
> Its possible that I've missed some subtleties of the Android
> alarm driver interface, and that some of the interface decisions
> I've made may not allow Android to use this interface directly,
> I'd be very interested if those details could be pointed out,
> and hopefully we can find a good solution to get this useful
> functionality upstream.
>

I don't know how suited the posix interface is for this, but I think
it is critical to prevent suspend while an alarm is pending. If an
alarm is important enough to wake the system up from suspend, it is
probably not safe to suspend right after it triggered. The android
alarm driver holds a wakelock until user-space calls back in to wait
for the next alarm, while in-kernel alarms are called from interrupt
context. The apis provided in include/linux/pm_wakeup.h should provide
the functionality you need to prevent suspend until the alarms have
been fully processed, but I have not tried this api yet.

It would also be useful to still allow in-kernel alarms to be
activated from atomic context (we currently do this in a couple of
drivers to avoid using a second wakelock).

-- 
Arve Hjønnevåg
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/