Messages in this thread | | | Date | Wed, 5 Jan 2011 20:07:54 -0800 | Subject | Re: [PATCH 12/12] [RFC] Introduce Alarm (hybrid) timers | From | Arve Hjønnevåg <> |
| |
On Wed, Jan 5, 2011 at 6:15 PM, John Stultz <john.stultz@linaro.org> 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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |