lkml.org 
[lkml]   [2011]   [Jan]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
SubjectRe: [PATCH 12/12] [RFC] Introduce Alarm (hybrid) timers
From
2011/1/6 John Stultz <john.stultz@linaro.org>:
> 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?
>

Yes, but the current driver only supports a single client, so this
only happens when the system_server crashes, not when apps exits.

>> 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?
>

The user-space interface does not look appealing, but I don't see any
reason why the in-kernel interface(s) cannot be shared. Our user-space
code has a single thread that waits for alarms to trigger, while the
alarms can be modified from any thread. As far as I can tell, using
the posix interface would either require a thread per alarm (up to 5)
or using signals. Both make the user-space code more complicated, and
it is not clear if either of them provide a clear hand-off between
where the kernel needs to block suspend because the alarm has not been
delivered to user-space and where user-space needs to block suspend
because it is handling the alarm.

--
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/

\
 
 \ /
  Last update: 2011-01-07 02:01    [W:0.078 / U:1.672 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site