From: John Stultz <john.stultz@linaro.org>
To: "Arve Hjønnevåg" <arve@android.com>
Cc: linux-kernel@vger.kernel.org,
Brian Swetland <swetland@google.com>,
Thomas Gleixner <tglx@linutronix.de>,
Alessandro Zummo <a.zummo@towertech.it>
Subject: Re: [PATCH 12/12] [RFC] Introduce Alarm (hybrid) timers
Date: Thu, 06 Jan 2011 10:04:01 -0800 [thread overview]
Message-ID: <1294337041.4518.87.camel@work-vm> (raw)
In-Reply-To: <AANLkTi=i9bnAz9FoB_Q1u4pTOwpBCTHK4S21iukZWBpF@mail.gmail.com>
On Wed, 2011-01-05 at 20:07 -0800, Arve Hjønnevåg wrote:
> On Wed, Jan 5, 2011 at 6:15 PM, John Stultz <john.stultz@linaro.org> wrote:
> > 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
Hrm. I was hoping to avoid wakelock discussions for now. What happens if
an app sets a single alarm and then never calls back in? I assume
closing the device drops the wakelock?
> 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.
Ok. I'll have to check out the pm_wakeup.h api and see if it can be
used.
> 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).
This is useful. I think I was being overly cautious using a mutex
instead of a spinlock for the base lock since I was worried about
calling into the RTC code which require mutexes, but we only do that at
suspend, so it should be ok to use a spinlock there. I'll revise and add
that in.
So otherwise, do you see any reason why android might not be able to
adapt this code to replace the android alarm timers?
thanks
-john
next prev parent reply other threads:[~2011-01-06 18:04 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-01-06 2:15 [PATCH 00/12] Posix Alarm Timers full patchset John Stultz
2011-01-06 2:15 ` [PATCH 01/12] timers: Introduce timerlist infrastructure John Stultz
2011-01-06 2:15 ` [PATCH 02/12] timers: Rename timerlist infrastructure to timerqueue John Stultz
2011-01-06 2:15 ` [PATCH 03/12] timers: Fixup allmodconfig build issue John Stultz
2011-01-06 2:15 ` [PATCH 04/12] hrtimers: Convert hrtimers to use timerlist infrastructure John Stultz
2011-01-06 2:15 ` [PATCH 05/12] hrtimer: fix timerqueue conversion flub John Stultz
2011-01-06 2:15 ` [PATCH 06/12] RTC: Rework RTC code to use timerqueue for events John Stultz
2011-01-06 2:15 ` [PATCH 07/12] RTC: Remove UIE emulation John Stultz
2011-01-06 2:15 ` [PATCH 08/12] rtc: Namespace fixup John Stultz
2011-01-06 2:15 ` [PATCH 09/12] [RFC] hrtimers: extend hrtimer base code to handle more then 2 clockids John Stultz
2011-01-06 2:15 ` [PATCH 10/12] [RFC] hrtimers: Add CLOCK_BOOTTIME clockid, hrtimerbase and posix interface John Stultz
2011-01-06 2:15 ` [PATCH 11/12] timers: Add rb_init_node() to allow for stack allocated rb nodes John Stultz
2011-01-06 2:15 ` [PATCH 12/12] [RFC] Introduce Alarm (hybrid) timers John Stultz
2011-01-06 4:07 ` Arve Hjønnevåg
2011-01-06 18:04 ` John Stultz [this message]
2011-01-07 0:58 ` Arve Hjønnevåg
2011-01-07 2:30 ` John Stultz
2011-01-08 10:36 ` Rafael J. Wysocki
2011-01-13 5:03 ` Arve Hjønnevåg
2011-01-11 18:56 ` John Stultz
2011-01-11 19:22 ` Anca Emanuel
2011-01-13 4:50 ` Arve Hjønnevåg
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1294337041.4518.87.camel@work-vm \
--to=john.stultz@linaro.org \
--cc=a.zummo@towertech.it \
--cc=arve@android.com \
--cc=linux-kernel@vger.kernel.org \
--cc=swetland@google.com \
--cc=tglx@linutronix.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox