[lkml]   [2011]   [Jan]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [PATCH 12/12] [RFC] Introduce Alarm (hybrid) timers
    On Wed, Jan 5, 2011 at 6:15 PM, John Stultz <> 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:;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
    > 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
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2011-01-06 05:11    [W:0.022 / U:4.016 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site