Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1411363 > unrolled thread
| Started by | Gabriele Mazzotta <gabriele.mzt@gmail.com> |
|---|---|
| First post | 2016-06-01 17:50 +0200 |
| Last post | 2016-06-04 19:50 +0200 |
| Articles | 5 — 2 participants |
Back to article view | Back to linux.kernel
[PATCH 1/2] rtc-cmos: Clear expired alarm after resume Gabriele Mazzotta <gabriele.mzt@gmail.com> - 2016-06-01 17:50 +0200
Re: [PATCH 1/2] rtc-cmos: Clear expired alarm after resume Gabriele Mazzotta <gabriele.mzt@gmail.com> - 2016-06-01 18:20 +0200
Re: [PATCH 1/2] rtc-cmos: Clear expired alarm after resume Alexandre Belloni <alexandre.belloni@free-electrons.com> - 2016-06-04 16:50 +0200
Re: [PATCH 1/2] rtc-cmos: Clear expired alarm after resume Gabriele Mazzotta <gabriele.mzt@gmail.com> - 2016-06-04 19:00 +0200
Re: [PATCH 1/2] rtc-cmos: Clear expired alarm after resume Alexandre Belloni <alexandre.belloni@free-electrons.com> - 2016-06-04 19:50 +0200
| From | Gabriele Mazzotta <gabriele.mzt@gmail.com> |
|---|---|
| Date | 2016-06-01 17:50 +0200 |
| Subject | [PATCH 1/2] rtc-cmos: Clear expired alarm after resume |
| Message-ID | <rFgz8-1Kx-21@gated-at.bofh.it> |
If the system wakes up because of a wake alarm, the internal state
of the alarm is not updated. As consequence, the state no longer
reflects the actual state of the hardware and setting a new alarm
is not possible until the expired alarm is cleared.
Signed-off-by: Gabriele Mazzotta <gabriele.mzt@gmail.com>
---
drivers/rtc/rtc-cmos.c | 22 ++++++++++++++++++++++
1 file changed, 22 insertions(+)
diff --git a/drivers/rtc/rtc-cmos.c b/drivers/rtc/rtc-cmos.c
index fbe9c72..fd121e3 100644
--- a/drivers/rtc/rtc-cmos.c
+++ b/drivers/rtc/rtc-cmos.c
@@ -900,11 +900,33 @@ static inline int cmos_poweroff(struct device *dev)
#ifdef CONFIG_PM_SLEEP
+static void cmos_check_alarm(struct device *dev)
+{
+ struct cmos_rtc *cmos = dev_get_drvdata(dev);
+ struct rtc_wkalrm alarm;
+ struct rtc_time now;
+ time64_t t_now;
+ time64_t t_expires;
+
+ cmos_read_time(dev, &now);
+ rtc_read_alarm(cmos->rtc, &alarm);
+ t_now = rtc_tm_to_time64(&now);
+ t_expires = rtc_tm_to_time64(&alarm.time);
+
+ if (t_expires <= t_now && alarm.enabled) {
+ alarm.enabled = 0;
+ cmos->suspend_ctrl &= ~RTC_AIE;
+ rtc_set_alarm(cmos->rtc, &alarm);
+ }
+}
+
static int cmos_resume(struct device *dev)
{
struct cmos_rtc *cmos = dev_get_drvdata(dev);
unsigned char tmp;
+ cmos_check_alarm(dev);
+
if (cmos->enabled_wake) {
if (cmos->wake_off)
cmos->wake_off(dev);
--
2.8.1
[toc] | [next] | [standalone]
| From | Gabriele Mazzotta <gabriele.mzt@gmail.com> |
|---|---|
| Date | 2016-06-01 18:20 +0200 |
| Message-ID | <rFh2a-2cp-25@gated-at.bofh.it> |
| In reply to | #1411363 |
On 01/06/2016 17:40, Gabriele Mazzotta wrote:
> If the system wakes up because of a wake alarm, the internal state
> of the alarm is not updated. As consequence, the state no longer
> reflects the actual state of the hardware and setting a new alarm
> is not possible until the expired alarm is cleared.
>
> Signed-off-by: Gabriele Mazzotta <gabriele.mzt@gmail.com>
> ---
> drivers/rtc/rtc-cmos.c | 22 ++++++++++++++++++++++
> 1 file changed, 22 insertions(+)
>
> diff --git a/drivers/rtc/rtc-cmos.c b/drivers/rtc/rtc-cmos.c
> index fbe9c72..fd121e3 100644
> --- a/drivers/rtc/rtc-cmos.c
> +++ b/drivers/rtc/rtc-cmos.c
> @@ -900,11 +900,33 @@ static inline int cmos_poweroff(struct device *dev)
>
> #ifdef CONFIG_PM_SLEEP
>
> +static void cmos_check_alarm(struct device *dev)
> +{
> + struct cmos_rtc *cmos = dev_get_drvdata(dev);
> + struct rtc_wkalrm alarm;
> + struct rtc_time now;
> + time64_t t_now;
> + time64_t t_expires;
> +
> + cmos_read_time(dev, &now);
> + rtc_read_alarm(cmos->rtc, &alarm);
Here it should probably check the return value and exit in case of error.
> + t_now = rtc_tm_to_time64(&now);
> + t_expires = rtc_tm_to_time64(&alarm.time);
> +
> + if (t_expires <= t_now && alarm.enabled) {
> + alarm.enabled = 0;
> + cmos->suspend_ctrl &= ~RTC_AIE;
> + rtc_set_alarm(cmos->rtc, &alarm);
Same here.
> + }
> +}
> +
> static int cmos_resume(struct device *dev)
> {
> struct cmos_rtc *cmos = dev_get_drvdata(dev);
> unsigned char tmp;
>
> + cmos_check_alarm(dev);
> +
> if (cmos->enabled_wake) {
> if (cmos->wake_off)
> cmos->wake_off(dev);
>
[toc] | [prev] | [next] | [standalone]
| From | Alexandre Belloni <alexandre.belloni@free-electrons.com> |
|---|---|
| Date | 2016-06-04 16:50 +0200 |
| Message-ID | <rGl3H-2ms-5@gated-at.bofh.it> |
| In reply to | #1411363 |
Hi, On 01/06/2016 at 17:40:14 +0200, Gabriele Mazzotta wrote : > If the system wakes up because of a wake alarm, the internal state > of the alarm is not updated. As consequence, the state no longer > reflects the actual state of the hardware and setting a new alarm > is not possible until the expired alarm is cleared. > I'm not completely sure to understand what is happening but could you check whether that one is solved by 2b2f5ff00f63847d95adad6289bd8b05f5983dd5 in my tree (rtc-next). -- Alexandre Belloni, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com
[toc] | [prev] | [next] | [standalone]
| From | Gabriele Mazzotta <gabriele.mzt@gmail.com> |
|---|---|
| Date | 2016-06-04 19:00 +0200 |
| Message-ID | <rGn5v-3xT-15@gated-at.bofh.it> |
| In reply to | #1413769 |
2016-06-04 16:46 GMT+02:00 Alexandre Belloni
<alexandre.belloni@free-electrons.com>:
> Hi,
>
> On 01/06/2016 at 17:40:14 +0200, Gabriele Mazzotta wrote :
>> If the system wakes up because of a wake alarm, the internal state
>> of the alarm is not updated. As consequence, the state no longer
>> reflects the actual state of the hardware and setting a new alarm
>> is not possible until the expired alarm is cleared.
>>
>
> I'm not completely sure to understand what is happening but could you
> check whether that one is solved by
> 2b2f5ff00f63847d95adad6289bd8b05f5983dd5 in my tree (rtc-next).
>
I picked 2b2f5ff00f63847d95adad6289bd8b05f5983dd5 and applied it
on top of 4.7-rc1, but that didn't fix the problem.
Let me explain the problem by showing you how I reproduce it:
root@localhost:~# cat /proc/driver/rtc | grep alarm_IRQ
alarm_IRQ : no
root@localhost:~# echo +10 > /sys/class/rtc/rtc0/wakealarm
root@localhost:~# echo mem > /sys/power/state # wait for auto-resume
root@localhost:~# echo +10 > /sys/class/rtc/rtc0/wakealarm
bash: echo: write error: Device or resource busy
root@localhost:~# cat /proc/driver/rtc | grep alarm_IRQ
alarm_IRQ : yes
To set another alarm, I have to first write 0 to wakealarm. After that
I can set what I want. This doesn't happen if the alarm fires while
the system is awake, it happens only if the system is suspended and
the alarm wakes it.
I actually forgot to say that maybe this problem is not limited
to rtc-cmos and that maybe a general solution could be used.
I've just looked better into what is causing this and the problem
seems to be caused by the fact that rtc_timer_do_work() is not
executed if the timer expires while the system is suspended.
The following solves this particular problem:
diff --git a/drivers/rtc/class.c b/drivers/rtc/class.c
index 74fd974..80d6a12 100644
--- a/drivers/rtc/class.c
+++ b/drivers/rtc/class.c
@@ -102,6 +102,9 @@ static int rtc_resume(struct device *dev)
struct timespec64 sleep_time;
int err;
+ /* A timer might have expired while suspended */
+ schedule_work(&rtc->irqwork);
+
if (timekeeping_rtc_skipresume())
return 0;
> --
> Alexandre Belloni, Free Electrons
> Embedded Linux, Kernel and Android engineering
> http://free-electrons.com
[toc] | [prev] | [next] | [standalone]
| From | Alexandre Belloni <alexandre.belloni@free-electrons.com> |
|---|---|
| Date | 2016-06-04 19:50 +0200 |
| Message-ID | <rGnRU-43r-5@gated-at.bofh.it> |
| In reply to | #1413797 |
On 04/06/2016 at 18:58:59 +0200, Gabriele Mazzotta wrote : > 2016-06-04 16:46 GMT+02:00 Alexandre Belloni > <alexandre.belloni@free-electrons.com>: > > On 01/06/2016 at 17:40:14 +0200, Gabriele Mazzotta wrote : > >> If the system wakes up because of a wake alarm, the internal state > >> of the alarm is not updated. As consequence, the state no longer > >> reflects the actual state of the hardware and setting a new alarm > >> is not possible until the expired alarm is cleared. > >> > > > > I'm not completely sure to understand what is happening but could you > > check whether that one is solved by > > 2b2f5ff00f63847d95adad6289bd8b05f5983dd5 in my tree (rtc-next). > > > > I picked 2b2f5ff00f63847d95adad6289bd8b05f5983dd5 and applied it > on top of 4.7-rc1, but that didn't fix the problem. > > Let me explain the problem by showing you how I reproduce it: > > root@localhost:~# cat /proc/driver/rtc | grep alarm_IRQ > alarm_IRQ : no > root@localhost:~# echo +10 > /sys/class/rtc/rtc0/wakealarm > root@localhost:~# echo mem > /sys/power/state # wait for auto-resume > root@localhost:~# echo +10 > /sys/class/rtc/rtc0/wakealarm > bash: echo: write error: Device or resource busy > root@localhost:~# cat /proc/driver/rtc | grep alarm_IRQ > alarm_IRQ : yes > > To set another alarm, I have to first write 0 to wakealarm. After that > I can set what I want. This doesn't happen if the alarm fires while > the system is awake, it happens only if the system is suspended and > the alarm wakes it. > > I actually forgot to say that maybe this problem is not limited > to rtc-cmos and that maybe a general solution could be used. > > I've just looked better into what is causing this and the problem > seems to be caused by the fact that rtc_timer_do_work() is not > executed if the timer expires while the system is suspended. > I doubt this is a driver independent issues as I don't get that behaviour on many other RTCs. I'll have a look. -- Alexandre Belloni, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com
[toc] | [prev] | [standalone]
Back to top | Article view | linux.kernel
csiph-web