[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <lsq.1404846110.619006759@decadent.org.uk>
Date: Tue, 08 Jul 2014 20:01:50 +0100
From: Ben Hutchings <ben@...adent.org.uk>
To: linux-kernel@...r.kernel.org, stable@...r.kernel.org
CC: akpm@...ux-foundation.org,
"Nicolas Ferre" <nicolas.ferre@...el.com>,
"Boris BREZILLON" <boris.brezillon@...e-electrons.com>,
"Andrew Victor" <linux@...im.org.za>,
"Bryan Evenson" <bevenson@...inkcorp.com>,
"Alessandro Zummo" <a.zummo@...ertech.it>,
"Jean-Christophe Plagniol-Villard" <plagnioj@...osoft.com>,
"Linus Torvalds" <torvalds@...ux-foundation.org>
Subject: [PATCH 3.2 064/125] rtc: rtc-at91rm9200: fix infinite wait for
ACKUPD irq
3.2.61-rc1 review patch. If anyone has any objections, please let me know.
------------------
From: Boris BREZILLON <boris.brezillon@...e-electrons.com>
commit 2fe121e1f5aa3bf31b418a9790db6c400e922291 upstream.
The rtc user must wait at least 1 sec between each time/calandar update
(see atmel's datasheet chapter "Updating Time/Calendar").
Use the 1Hz interrupt to update the at91_rtc_upd_rdy flag and wait for
the at91_rtc_wait_upd_rdy event if the rtc is not ready.
This patch fixes a deadlock in an uninterruptible wait when the RTC is
updated more than once every second. AFAICT the bug is here from the
beginning, but I think we should at least backport this fix to 3.10 and
the following longterm and stable releases.
Signed-off-by: Boris BREZILLON <boris.brezillon@...e-electrons.com>
Reported-by: Bryan Evenson <bevenson@...inkcorp.com>
Tested-by: Bryan Evenson <bevenson@...inkcorp.com>
Cc: Andrew Victor <linux@...im.org.za>
Cc: Nicolas Ferre <nicolas.ferre@...el.com>
Cc: Jean-Christophe Plagniol-Villard <plagnioj@...osoft.com>
Cc: Alessandro Zummo <a.zummo@...ertech.it>
Signed-off-by: Andrew Morton <akpm@...ux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@...ux-foundation.org>
[bwh: Backported to 3.2:
- Adjust context
- at91_rtc_write() is called at91_sys_write()
- Use at91_sys_write() directly instead of the missing
at91_rtc_write_ier() and at91_rtc_write_idr()]
Signed-off-by: Ben Hutchings <ben@...adent.org.uk>
---
drivers/rtc/rtc-at91rm9200.c | 16 ++++++++++++++--
1 file changed, 14 insertions(+), 2 deletions(-)
--- a/drivers/rtc/rtc-at91rm9200.c
+++ b/drivers/rtc/rtc-at91rm9200.c
@@ -36,6 +36,7 @@
#define AT91_RTC_EPOCH 1900UL /* just like arch/arm/common/rtctime.c */
static DECLARE_COMPLETION(at91_rtc_updated);
+static DECLARE_COMPLETION(at91_rtc_upd_rdy);
static unsigned int at91_alarm_year = AT91_RTC_EPOCH;
/*
@@ -97,6 +98,8 @@ static int at91_rtc_settime(struct devic
1900 + tm->tm_year, tm->tm_mon, tm->tm_mday,
tm->tm_hour, tm->tm_min, tm->tm_sec);
+ wait_for_completion(&at91_rtc_upd_rdy);
+
/* Stop Time/Calendar from counting */
cr = at91_sys_read(AT91_RTC_CR);
at91_sys_write(AT91_RTC_CR, cr | AT91_RTC_UPDCAL | AT91_RTC_UPDTIM);
@@ -119,7 +122,9 @@ static int at91_rtc_settime(struct devic
/* Restart Time/Calendar */
cr = at91_sys_read(AT91_RTC_CR);
+ at91_sys_write(AT91_RTC_SCCR, AT91_RTC_SECEV);
at91_sys_write(AT91_RTC_CR, cr & ~(AT91_RTC_UPDCAL | AT91_RTC_UPDTIM));
+ at91_sys_write(AT91_RTC_IER, AT91_RTC_SECEV);
return 0;
}
@@ -226,8 +231,10 @@ static irqreturn_t at91_rtc_interrupt(in
if (rtsr) { /* this interrupt is shared! Is it ours? */
if (rtsr & AT91_RTC_ALARM)
events |= (RTC_AF | RTC_IRQF);
- if (rtsr & AT91_RTC_SECEV)
- events |= (RTC_UF | RTC_IRQF);
+ if (rtsr & AT91_RTC_SECEV) {
+ complete(&at91_rtc_upd_rdy);
+ at91_sys_write(AT91_RTC_IDR, AT91_RTC_SECEV);
+ }
if (rtsr & AT91_RTC_ACKUPD)
complete(&at91_rtc_updated);
@@ -291,6 +298,11 @@ static int __init at91_rtc_probe(struct
}
platform_set_drvdata(pdev, rtc);
+ /* enable SECEV interrupt in order to initialize at91_rtc_upd_rdy
+ * completion.
+ */
+ at91_sys_write(AT91_RTC_IER, AT91_RTC_SECEV);
+
printk(KERN_INFO "AT91 Real Time Clock driver.\n");
return 0;
}
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists