Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1271125 > unrolled thread

[PATCH v3] alarmtimer: fix unexpected rtc interrupt when system resume from S3

Started byzhuo-hao.lee@intel.com
First post2015-11-17 13:10 +0100
Last post2015-11-25 22:50 +0100
Articles 5 — 4 participants

Back to article view | Back to linux.kernel


Contents

  [PATCH v3] alarmtimer: fix unexpected rtc interrupt when system resume from S3 zhuo-hao.lee@intel.com - 2015-11-17 13:10 +0100
    Re: [PATCH v3] alarmtimer: fix unexpected rtc interrupt when system  resume from S3 John Stultz <john.stultz@linaro.org> - 2015-11-20 20:30 +0100
      RE: [PATCH v3] alarmtimer: fix unexpected rtc interrupt when system  resume from S3 "Lee, Zhuo-hao" <zhuo-hao.lee@intel.com> - 2015-11-23 03:00 +0100
      Re: [PATCH v3] alarmtimer: fix unexpected rtc interrupt when system  resume from S3 Thomas Gleixner <tglx@linutronix.de> - 2015-11-25 15:30 +0100
        Re: [PATCH v3] alarmtimer: fix unexpected rtc interrupt when system  resume from S3 John Stultz <john.stultz@linaro.org> - 2015-11-25 22:50 +0100

#1271125 — [PATCH v3] alarmtimer: fix unexpected rtc interrupt when system resume from S3

Fromzhuo-hao.lee@intel.com
Date2015-11-17 13:10 +0100
Subject[PATCH v3] alarmtimer: fix unexpected rtc interrupt when system resume from S3
Message-ID<qvNfc-4R6-15@gated-at.bofh.it>
From: zhuo-hao <zhuo-hao.lee@intel.com>

Before the system go to suspend (S3), if user create a timer with clockid
CLOCK_REALTIME_ALARM/CLOCK_BOOTTIME_ALARM and set a "large" timeout value
to this timer. The function alarmtimer_suspend will be called to setup
a timeout value to RTC timer to avoid the system sleep over time. However,
if the system wakeup early than RTC timeout, the RTC timer will not be cleared.
And this will cause the hpet_rtc_interrupt come unexpectedly until the RTC
timeout. To fix this problem, just adding alarmtimer_resume to cancel the
RTC timer.

This was noticed because the HPET RTC emulation fires an interrupt every
16ms(=1/2^DEFAULT_RTC_SHIFT) up to the point where the alarm time is reached.
This program always hits this situation(https://lkml.org/lkml/2015/11/8/326),
if system wake up earlier than alarm time.

Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: John Stultz <john.stultz@linaro.org>
Signed-off-by: Zhuo-hao Lee <zhuo-hao.lee@intel.com>
---
 kernel/time/alarmtimer.c | 17 +++++++++++++++++
 1 file changed, 17 insertions(+)

diff --git a/kernel/time/alarmtimer.c b/kernel/time/alarmtimer.c
index 7fbba63..e840ed8 100644
--- a/kernel/time/alarmtimer.c
+++ b/kernel/time/alarmtimer.c
@@ -271,11 +271,27 @@ static int alarmtimer_suspend(struct device *dev)
 		__pm_wakeup_event(ws, MSEC_PER_SEC);
 	return ret;
 }
+
+static int alarmtimer_resume(struct device *dev)
+{
+	struct rtc_device *rtc;
+
+	rtc = alarmtimer_get_rtcdev();
+	if (rtc)
+		rtc_timer_cancel(rtc, &rtctimer);
+	return 0;
+}
+
 #else
 static int alarmtimer_suspend(struct device *dev)
 {
 	return 0;
 }
+
+static int alarmtimer_resume(struct device *dev)
+{
+	return 0;
+}
 #endif
 
 static void alarmtimer_freezerset(ktime_t absexp, enum alarmtimer_type type)
@@ -800,6 +816,7 @@ out:
 /* Suspend hook structures */
 static const struct dev_pm_ops alarmtimer_pm_ops = {
 	.suspend = alarmtimer_suspend,
+	.resume = alarmtimer_resume,
 };
 
 static struct platform_driver alarmtimer_driver = {
-- 
2.1.2

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

[toc] | [next] | [standalone]


#1274369 — Re: [PATCH v3] alarmtimer: fix unexpected rtc interrupt when system resume from S3

FromJohn Stultz <john.stultz@linaro.org>
Date2015-11-20 20:30 +0100
SubjectRe: [PATCH v3] alarmtimer: fix unexpected rtc interrupt when system resume from S3
Message-ID<qwZxD-32K-15@gated-at.bofh.it>
In reply to#1271125
On Tue, Nov 17, 2015 at 4:08 AM,  <zhuo-hao.lee@intel.com> wrote:
> From: zhuo-hao <zhuo-hao.lee@intel.com>
>
> Before the system go to suspend (S3), if user create a timer with clockid
> CLOCK_REALTIME_ALARM/CLOCK_BOOTTIME_ALARM and set a "large" timeout value
> to this timer. The function alarmtimer_suspend will be called to setup
> a timeout value to RTC timer to avoid the system sleep over time. However,
> if the system wakeup early than RTC timeout, the RTC timer will not be cleared.
> And this will cause the hpet_rtc_interrupt come unexpectedly until the RTC
> timeout. To fix this problem, just adding alarmtimer_resume to cancel the
> RTC timer.
>
> This was noticed because the HPET RTC emulation fires an interrupt every
> 16ms(=1/2^DEFAULT_RTC_SHIFT) up to the point where the alarm time is reached.
> This program always hits this situation(https://lkml.org/lkml/2015/11/8/326),
> if system wake up earlier than alarm time.

So thanks for the extra context here, and again I don't have an
objection to this patch.

Although from the earlier discussion it still isn't quite clear to me:
Why must the HPET RTC emulation need to fire the alarm every 16ms? Is
that not something that can be fixed?

I just want to make sure we're not hiding a deeper issue.

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

[toc] | [prev] | [next] | [standalone]


#1275008 — RE: [PATCH v3] alarmtimer: fix unexpected rtc interrupt when system resume from S3

From"Lee, Zhuo-hao" <zhuo-hao.lee@intel.com>
Date2015-11-23 03:00 +0100
SubjectRE: [PATCH v3] alarmtimer: fix unexpected rtc interrupt when system resume from S3
Message-ID<qxOAa-3v8-5@gated-at.bofh.it>
In reply to#1274369
PkFsdGhvdWdoIGZyb20gdGhlIGVhcmxpZXIgZGlzY3Vzc2lvbiBpdCBzdGlsbCBpc24ndCBxdWl0
ZSBjbGVhciB0byBtZToNCj5XaHkgbXVzdCB0aGUgSFBFVCBSVEMgZW11bGF0aW9uIG5lZWQgdG8g
ZmlyZSB0aGUgYWxhcm0gZXZlcnkgMTZtcz8gSXMgdGhhdCBub3Qgc29tZXRoaW5nIHRoYXQgY2Fu
IGJlIGZpeGVkPw0KDQpUaGlzIGlzIGhwZXQgZHJpdmVyJ3MgYmVoYXZpb3IuIFBsZWFzZSBjaGVj
ayB0aGUgZm9sbG93aW5nIGNvbW1lbnQgd2hpY2ggaXMgY29waWVkIGZyb20gdGhlIGZpbGUgaHBl
dC5jDQoNCi8qIEhQRVQgaW4gTGVnYWN5UmVwbGFjZW1lbnQgTW9kZSBlYXRzIHVwIFJUQyBpbnRl
cnJ1cHQgbGluZS4gV2hlbiwgSFBFVA0KICogaXMgZW5hYmxlZCwgd2Ugc3VwcG9ydCBSVEMgaW50
ZXJydXB0IGZ1bmN0aW9uYWxpdHkgaW4gc29mdHdhcmUuDQogKiBSVEMgaGFzIDMga2luZHMgb2Yg
aW50ZXJydXB0czoNCiAqIDEpIFVwZGF0ZSBJbnRlcnJ1cHQgLSBnZW5lcmF0ZSBhbiBpbnRlcnJ1
cHQsIGV2ZXJ5IHNlYywgd2hlbiBSVEMgY2xvY2sNCiAqICAgIGlzIHVwZGF0ZWQNCiAqIDIpIEFs
YXJtIEludGVycnVwdCAtIGdlbmVyYXRlIGFuIGludGVycnVwdCBhdCBhIHNwZWNpZmljIHRpbWUg
b2YgZGF5DQogKiAzKSBQZXJpb2RpYyBJbnRlcnJ1cHQgLSBnZW5lcmF0ZSBwZXJpb2RpYyBpbnRl
cnJ1cHQsIHdpdGggZnJlcXVlbmNpZXMNCiAqICAgIDJIei04MTkySHogKDJIei02NEh6IGZvciBu
b24tcm9vdCB1c2VyKSAoYWxsIGZyZXFzIGluIHBvd2VycyBvZiAyKQ0KICogKDEpIGFuZCAoMikg
YWJvdmUgYXJlIGltcGxlbWVudGVkIHVzaW5nIHBvbGxpbmcgYXQgYSBmcmVxdWVuY3kgb2YNCiAq
IDY0IEh6LiBUaGUgZXhhY3QgZnJlcXVlbmN5IGlzIGEgdHJhZGVvZmYgYmV0d2VlbiBhY2N1cmFj
eSBhbmQgaW50ZXJydXB0DQogKiBvdmVyaGVhZC4gKERFRkFVTFRfUlRDX0lOVF9GUkVRKQ0KICog
Rm9yICgzKSwgd2UgdXNlIGludGVycnVwdHMgYXQgNjRIeiBvciB1c2VyIHNwZWNpZmllZCBwZXJp
b2RpYw0KICogZnJlcXVlbmN5LCB3aGljaGV2ZXIgaXMgaGlnaGVyLg0KICovDQogDQpUaGUgYWxh
cm0gaW50ZXJydXB0IGhhdmUgYSBmcmVxdWVuY3kgb2YgNjRIei4gVGhpcyBpcyBhIHRyYWRlb2Zm
IGJldHdlZW4gYWNjdXJhY3kgYW5kIGludGVycnVwdCBvdmVyaGVhZC4gDQpTbyB0aGF0LCBJIHRo
aW5rIDE2bXMoMS82NHMpIGludGVycnVwdCBpcyBleHBlY3RlZCB1bmxlc3Mgd2UgY2hhbmdlIHRo
ZSBkcml2ZXIncyBkZXNpZ24uDQpIb3dldmVyLCBjaGFuZ2luZyB0aGUgZHJpdmVyJ3MgYmVoYXZp
b3IgaXMgYSBodWdlIG1vZGlmaWNhdGlvbi4gVGhpcyBkcml2ZXIgYWxyZWFkeSBleGlzdHMgZm9y
IGEgbG9uZyB0aW1lDQooc3RhcnRpbmcgZnJvbSAgY29tbWl0IGlkIDoxZGExNzdlNGMzZjQxNTI0
ZTg4NmI3ZjFiOGEwYzFmYzczMjFjYWMyIG9yIGVhbGllcikuDQpTbywgSSB0ZW5kIG5vdCB0byBt
b2RpZnkgdGhpcyBkcml2ZXIncyBiZWhhdmlvci4NCg0KVGhhbmtzDQpMZWUsIFpodW8taGFvDQo=
--
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/

[toc] | [prev] | [next] | [standalone]


#1277428 — Re: [PATCH v3] alarmtimer: fix unexpected rtc interrupt when system resume from S3

FromThomas Gleixner <tglx@linutronix.de>
Date2015-11-25 15:30 +0100
SubjectRe: [PATCH v3] alarmtimer: fix unexpected rtc interrupt when system resume from S3
Message-ID<qyJf4-7rz-23@gated-at.bofh.it>
In reply to#1274369
On Fri, 20 Nov 2015, John Stultz wrote:

> On Tue, Nov 17, 2015 at 4:08 AM,  <zhuo-hao.lee@intel.com> wrote:
> > From: zhuo-hao <zhuo-hao.lee@intel.com>
> >
> > Before the system go to suspend (S3), if user create a timer with clockid
> > CLOCK_REALTIME_ALARM/CLOCK_BOOTTIME_ALARM and set a "large" timeout value
> > to this timer. The function alarmtimer_suspend will be called to setup
> > a timeout value to RTC timer to avoid the system sleep over time. However,
> > if the system wakeup early than RTC timeout, the RTC timer will not be cleared.
> > And this will cause the hpet_rtc_interrupt come unexpectedly until the RTC
> > timeout. To fix this problem, just adding alarmtimer_resume to cancel the
> > RTC timer.
> >
> > This was noticed because the HPET RTC emulation fires an interrupt every
> > 16ms(=1/2^DEFAULT_RTC_SHIFT) up to the point where the alarm time is reached.
> > This program always hits this situation(https://lkml.org/lkml/2015/11/8/326),
> > if system wake up earlier than alarm time.
> 
> So thanks for the extra context here, and again I don't have an
> objection to this patch.
> 
> Although from the earlier discussion it still isn't quite clear to me:
> Why must the HPET RTC emulation need to fire the alarm every 16ms? Is
> that not something that can be fixed?

We probably can fix it with some surgery. OTOH that stuff is fragile
as hell and I rather avoid touching it, but I won't hinder someone
brave enough doing it :)
 
> I just want to make sure we're not hiding a deeper issue.

It's not a deeper issue. It's a - admittedly dumb - implementation
detail.

Thanks,

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

[toc] | [prev] | [next] | [standalone]


#1277817 — Re: [PATCH v3] alarmtimer: fix unexpected rtc interrupt when system resume from S3

FromJohn Stultz <john.stultz@linaro.org>
Date2015-11-25 22:50 +0100
SubjectRe: [PATCH v3] alarmtimer: fix unexpected rtc interrupt when system resume from S3
Message-ID<qyQ6S-3nP-3@gated-at.bofh.it>
In reply to#1277428
On Wed, Nov 25, 2015 at 6:25 AM, Thomas Gleixner <tglx@linutronix.de> wrote:
> On Fri, 20 Nov 2015, John Stultz wrote:
>
>> On Tue, Nov 17, 2015 at 4:08 AM,  <zhuo-hao.lee@intel.com> wrote:
>> > From: zhuo-hao <zhuo-hao.lee@intel.com>
>> >
>> > Before the system go to suspend (S3), if user create a timer with clockid
>> > CLOCK_REALTIME_ALARM/CLOCK_BOOTTIME_ALARM and set a "large" timeout value
>> > to this timer. The function alarmtimer_suspend will be called to setup
>> > a timeout value to RTC timer to avoid the system sleep over time. However,
>> > if the system wakeup early than RTC timeout, the RTC timer will not be cleared.
>> > And this will cause the hpet_rtc_interrupt come unexpectedly until the RTC
>> > timeout. To fix this problem, just adding alarmtimer_resume to cancel the
>> > RTC timer.
>> >
>> > This was noticed because the HPET RTC emulation fires an interrupt every
>> > 16ms(=1/2^DEFAULT_RTC_SHIFT) up to the point where the alarm time is reached.
>> > This program always hits this situation(https://lkml.org/lkml/2015/11/8/326),
>> > if system wake up earlier than alarm time.
>>
>> So thanks for the extra context here, and again I don't have an
>> objection to this patch.
>>
>> Although from the earlier discussion it still isn't quite clear to me:
>> Why must the HPET RTC emulation need to fire the alarm every 16ms? Is
>> that not something that can be fixed?
>
> We probably can fix it with some surgery. OTOH that stuff is fragile
> as hell and I rather avoid touching it, but I won't hinder someone
> brave enough doing it :)
>
>> I just want to make sure we're not hiding a deeper issue.
>
> It's not a deeper issue. It's a - admittedly dumb - implementation
> detail.

Fair enough.. I've got it queued up for testing.

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

[toc] | [prev] | [standalone]


Back to top | Article view | linux.kernel


csiph-web