2013-06-26 23:10:04

by Zoran Markovic

[permalink] [raw]
Subject: [RFC PATCH] rtc: keep system awake until all expired RTC timers are handled

Current implementation of RTC interface allows for system suspend to
occur in the following cases:
(a) if a timer is set in the past and rtc_timer_do_work() is scheduled
to handle it, and
(b) if rtc_timer_do_work() is called to handle expired timers whose
handlers implement a preemption point.

A pending suspend request may be honoured in the above cases causing
timer handling to be delayed until after the next resume. This is
undesirable since timer handlers may have time-critical code to execute.

This patch makes sure that the system stays awake until all expired
timers are handled.

Note that all calls to pm_stay_awake() are eventually paired with
the single pm_relax() call in rtc_timer_do_work(), which is launched
using schedule_work().

Cc: Alessandro Zummo <[email protected]>
Cc: John Stultz <[email protected]>
Cc: Arve Hjonnevag <[email protected]>
Cc: Todd Poynor <[email protected]>
Signed-off-by: Zoran Markovic <[email protected]>
---
drivers/rtc/interface.c | 13 +++++++++----
1 file changed, 9 insertions(+), 4 deletions(-)

diff --git a/drivers/rtc/interface.c b/drivers/rtc/interface.c
index 42bd57d..dace26e 100644
--- a/drivers/rtc/interface.c
+++ b/drivers/rtc/interface.c
@@ -72,6 +72,7 @@ int rtc_set_time(struct rtc_device *rtc, struct rtc_time *tm)
} else
err = -EINVAL;

+ pm_stay_awake(rtc->dev.parent);
mutex_unlock(&rtc->ops_lock);
/* A timer might have just expired */
schedule_work(&rtc->irqwork);
@@ -113,6 +114,7 @@ int rtc_set_mmss(struct rtc_device *rtc, unsigned long secs)
else
err = -EINVAL;

+ pm_stay_awake(rtc->dev.parent);
mutex_unlock(&rtc->ops_lock);
/* A timer might have just expired */
schedule_work(&rtc->irqwork);
@@ -771,9 +773,10 @@ static int rtc_timer_enqueue(struct rtc_device *rtc, struct rtc_timer *timer)
alarm.time = rtc_ktime_to_tm(timer->node.expires);
alarm.enabled = 1;
err = __rtc_set_alarm(rtc, &alarm);
- if (err == -ETIME)
+ if (err == -ETIME) {
+ pm_stay_awake(rtc->dev.parent);
schedule_work(&rtc->irqwork);
- else if (err) {
+ } else if (err) {
timerqueue_del(&rtc->timerqueue, &timer->node);
timer->enabled = 0;
return err;
@@ -818,8 +821,10 @@ static void rtc_timer_remove(struct rtc_device *rtc, struct rtc_timer *timer)
alarm.time = rtc_ktime_to_tm(next->expires);
alarm.enabled = 1;
err = __rtc_set_alarm(rtc, &alarm);
- if (err == -ETIME)
+ if (err == -ETIME) {
+ pm_stay_awake(rtc->dev.parent);
schedule_work(&rtc->irqwork);
+ }
}
}

@@ -845,7 +850,6 @@ void rtc_timer_do_work(struct work_struct *work)

mutex_lock(&rtc->ops_lock);
again:
- pm_relax(rtc->dev.parent);
__rtc_read_time(rtc, &tm);
now = rtc_tm_to_ktime(tm);
while ((next = timerqueue_getnext(&rtc->timerqueue))) {
@@ -880,6 +884,7 @@ again:
} else
rtc_alarm_disable(rtc);

+ pm_relax(rtc->dev.parent);
mutex_unlock(&rtc->ops_lock);
}

--
1.7.9.5


2013-07-18 20:03:55

by John Stultz

[permalink] [raw]
Subject: Re: [RFC PATCH] rtc: keep system awake until all expired RTC timers are handled

On 06/26/2013 04:09 PM, Zoran Markovic wrote:
> Current implementation of RTC interface allows for system suspend to
> occur in the following cases:
> (a) if a timer is set in the past and rtc_timer_do_work() is scheduled
> to handle it, and
> (b) if rtc_timer_do_work() is called to handle expired timers whose
> handlers implement a preemption point.
>
> A pending suspend request may be honoured in the above cases causing
> timer handling to be delayed until after the next resume. This is
> undesirable since timer handlers may have time-critical code to execute.
>
> This patch makes sure that the system stays awake until all expired
> timers are handled.
>
> Note that all calls to pm_stay_awake() are eventually paired with
> the single pm_relax() call in rtc_timer_do_work(), which is launched
> using schedule_work().
>
> Cc: Alessandro Zummo <[email protected]>
> Cc: John Stultz <[email protected]>
> Cc: Arve Hjonnevag <[email protected]>
> Cc: Todd Poynor <[email protected]>
> Signed-off-by: Zoran Markovic <[email protected]>

Haven't seen any objections here, so I'll queue this for 3.12.

thanks
-john