[PATCH 00/12] rtc: omap: fixes and power-off feature

[PATCH 00/12] rtc: omap: fixes and power-off feature

[Johan Hovold]

This series fixes a few issues with the omap rtc-driver, cleans up a bit
and finally adds support for the PMIC control feature found in some
revisions of this RTC IP block.

Ultimately, this allows for powering off the Beaglebone and waking it up
again on RTC alarms.

I noticed yesterday that Lokesh Vutla recently posted some patches to
add regulator support to this driver. [1] While that series has some
issues that needs to be addressed, I still think it could be a good idea
to rebase my pmic_power_en patch on top of it as it adds some long
overdue device abstraction. That would be needed anyway in order to
support the new power-off infrastructure that's in the pipe in a clean
way. [2]

So my suggestion is to merge the first seven patches, rebase Lokesh
series on top of that, and then I rebase my final five patches on top
of that in turn. Hopefully, the new power-off handler call chain will
have stabilised by then.

Johan

[1] http://www.spinics.net/lists/devicetree/msg50869.html
[2] https://lkml.org/lkml/2014/10/7/30


Johan Hovold (12):
  rtc: omap: fix clock-source configuration
  rtc: omap: fix missing wakealarm attribute
  rtc: omap: fix class-device registration
  rtc: omap: remove unused register-base define
  rtc: omap: remove redundant debug message
  rtc: omap: use dev_info and dev_dbg
  rtc: omap: silence bogus power-up reset message at probe
  rtc: omap: restore irq state after reading TC registers
  rtc: omap: add support for pmic_power_en
  rtc: omap: enable wake-up from power off
  ARM: dts: am33xx: update rtc node compatible property
  ARM: dts: am335x-bone-common: enable power off and rtc wake up

 Documentation/devicetree/bindings/rtc/rtc-omap.txt |   9 +-
 arch/arm/boot/dts/am335x-bone-common.dtsi          |   4 +
 arch/arm/boot/dts/am33xx.dtsi                      |   2 +-
 drivers/rtc/rtc-omap.c                             | 202 ++++++++++++++++-----
 4 files changed, 173 insertions(+), 44 deletions(-)

-- 
2.0.4

[PATCH 01/12] rtc: omap: fix clock-source configuration

[Johan Hovold]

Make sure not to reset the clock-source configuration when enabling the
32kHz clock mux.

Until the clock source can be configured through device tree we must not
overwrite settings made by the bootloader (e.g. clock-source selection).

Fixes: cd914bba03d8 ("drivers/rtc/rtc-omap.c: add support for enabling
32khz clock")
Cc: stable <stable@vger.kernel.org>

Signed-off-by: Johan Hovold <johan@kernel.org>
---
 drivers/rtc/rtc-omap.c | 6 ++++--
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/rtc/rtc-omap.c b/drivers/rtc/rtc-omap.c
index 21142e6574a9..f842c216f2dd 100644
--- a/drivers/rtc/rtc-omap.c
+++ b/drivers/rtc/rtc-omap.c
@@ -431,8 +431,10 @@ static int __init omap_rtc_probe(struct platform_device *pdev)
 	rtc_write(0, OMAP_RTC_INTERRUPTS_REG);
 
 	/* enable RTC functional clock */
-	if (id_entry->driver_data & OMAP_RTC_HAS_32KCLK_EN)
-		rtc_writel(OMAP_RTC_OSC_32KCLK_EN, OMAP_RTC_OSC_REG);
+	if (id_entry->driver_data & OMAP_RTC_HAS_32KCLK_EN) {
+		reg = rtc_read(OMAP_RTC_OSC_REG);
+		rtc_writel(reg | OMAP_RTC_OSC_32KCLK_EN, OMAP_RTC_OSC_REG);
+	}
 
 	/* clear old status */
 	reg = rtc_read(OMAP_RTC_STATUS_REG);
-- 
2.0.4

[PATCH 02/12] rtc: omap: fix missing wakealarm attribute

[Johan Hovold]

The platform device must be registered as wakeup capable before
registering the class device, or the wakealarm attribute will not be
created.

Also make sure to unregister the wakeup source on probe errors.

Fixes: 1d2e2b65d098 ("rtc: omap: restore back (hard-code) wakeup support")
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Johan Hovold <johan@kernel.org>
---
 drivers/rtc/rtc-omap.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/rtc/rtc-omap.c b/drivers/rtc/rtc-omap.c
index f842c216f2dd..828cb9983cc2 100644
--- a/drivers/rtc/rtc-omap.c
+++ b/drivers/rtc/rtc-omap.c
@@ -416,6 +416,8 @@ static int __init omap_rtc_probe(struct platform_device *pdev)
 		rtc_writel(KICK1_VALUE, OMAP_RTC_KICK1_REG);
 	}
 
+	device_init_wakeup(&pdev->dev, true);
+
 	rtc = devm_rtc_device_register(&pdev->dev, pdev->name,
 			&omap_rtc_ops, THIS_MODULE);
 	if (IS_ERR(rtc)) {
@@ -484,8 +486,6 @@ static int __init omap_rtc_probe(struct platform_device *pdev)
 	 *    is write-only, and always reads as zero...)
 	 */
 
-	device_init_wakeup(&pdev->dev, true);
-
 	if (new_ctrl & (u8) OMAP_RTC_CTRL_SPLIT)
 		pr_info("%s: split power mode\n", pdev->name);
 
@@ -495,6 +495,7 @@ static int __init omap_rtc_probe(struct platform_device *pdev)
 	return 0;
 
 fail0:
+	device_init_wakeup(&pdev->dev, false);
 	if (id_entry->driver_data & OMAP_RTC_HAS_KICKER)
 		rtc_writel(0, OMAP_RTC_KICK0_REG);
 	pm_runtime_put_sync(&pdev->dev);
-- 
2.0.4

[PATCH 03/12] rtc: omap: fix class-device registration

[Johan Hovold]

Make sure not to register the class device until after it has been
configured and interrupt handlers registered at probe.

Currently, the device is not fully configured (e.g. 24-hour mode) when
the class device is registered, something which involves driver
callbacks for example to read the current time.

This reordering also prevents user space from enabling an alarm before
an interrupt handler has been registered.

Note that the interrupts are now registered using the platform-device
rather than class-device name.

Signed-off-by: Johan Hovold <johan@kernel.org>
---
 drivers/rtc/rtc-omap.c | 32 +++++++++++++++++---------------
 1 file changed, 17 insertions(+), 15 deletions(-)

diff --git a/drivers/rtc/rtc-omap.c b/drivers/rtc/rtc-omap.c
index 828cb9983cc2..2eca141e784e 100644
--- a/drivers/rtc/rtc-omap.c
+++ b/drivers/rtc/rtc-omap.c
@@ -147,8 +147,9 @@ static void rtc_wait_not_busy(void)
 	/* now we have ~15 usec to read/write various registers */
 }
 
-static irqreturn_t rtc_irq(int irq, void *rtc)
+static irqreturn_t rtc_irq(int irq, void *dev_id)
 {
+	struct rtc_device	*rtc = platform_get_drvdata(dev_id);
 	unsigned long		events = 0;
 	u8			irq_data;
 
@@ -164,7 +165,8 @@ static irqreturn_t rtc_irq(int irq, void *rtc)
 	if (irq_data & OMAP_RTC_STATUS_1S_EVENT)
 		events |= RTC_IRQF | RTC_UF;
 
-	rtc_update_irq(rtc, 1, events);
+	if (rtc)
+		rtc_update_irq(rtc, 1, events);
 
 	return IRQ_HANDLED;
 }
@@ -416,17 +418,6 @@ static int __init omap_rtc_probe(struct platform_device *pdev)
 		rtc_writel(KICK1_VALUE, OMAP_RTC_KICK1_REG);
 	}
 
-	device_init_wakeup(&pdev->dev, true);
-
-	rtc = devm_rtc_device_register(&pdev->dev, pdev->name,
-			&omap_rtc_ops, THIS_MODULE);
-	if (IS_ERR(rtc)) {
-		pr_debug("%s: can't register RTC device, err %ld\n",
-			pdev->name, PTR_ERR(rtc));
-		goto fail0;
-	}
-	platform_set_drvdata(pdev, rtc);
-
 	/* clear pending irqs, and set 1/second periodic,
 	 * which we'll use instead of update irqs
 	 */
@@ -450,14 +441,14 @@ static int __init omap_rtc_probe(struct platform_device *pdev)
 
 	/* handle periodic and alarm irqs */
 	if (devm_request_irq(&pdev->dev, omap_rtc_timer, rtc_irq, 0,
-			dev_name(&rtc->dev), rtc)) {
+			dev_name(&pdev->dev), pdev)) {
 		pr_debug("%s: RTC timer interrupt IRQ%d already claimed\n",
 			pdev->name, omap_rtc_timer);
 		goto fail0;
 	}
 	if ((omap_rtc_timer != omap_rtc_alarm) &&
 		(devm_request_irq(&pdev->dev, omap_rtc_alarm, rtc_irq, 0,
-			dev_name(&rtc->dev), rtc))) {
+			dev_name(&pdev->dev), pdev))) {
 		pr_debug("%s: RTC alarm interrupt IRQ%d already claimed\n",
 			pdev->name, omap_rtc_alarm);
 		goto fail0;
@@ -492,6 +483,17 @@ static int __init omap_rtc_probe(struct platform_device *pdev)
 	if (reg != new_ctrl)
 		rtc_write(new_ctrl, OMAP_RTC_CTRL_REG);
 
+	device_init_wakeup(&pdev->dev, true);
+
+	rtc = devm_rtc_device_register(&pdev->dev, pdev->name,
+			&omap_rtc_ops, THIS_MODULE);
+	if (IS_ERR(rtc)) {
+		pr_debug("%s: can't register RTC device, err %ld\n",
+			pdev->name, PTR_ERR(rtc));
+		goto fail0;
+	}
+	platform_set_drvdata(pdev, rtc);
+
 	return 0;
 
 fail0:
-- 
2.0.4

[PATCH 04/12] rtc: omap: remove unused register-base define

[Johan Hovold]

Remove register-base define, which is no longer used.

Signed-off-by: Johan Hovold <johan@kernel.org>
---
 drivers/rtc/rtc-omap.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/rtc/rtc-omap.c b/drivers/rtc/rtc-omap.c
index 2eca141e784e..d1b5562a148b 100644
--- a/drivers/rtc/rtc-omap.c
+++ b/drivers/rtc/rtc-omap.c
@@ -41,8 +41,6 @@
 
 #define	DRIVER_NAME			"omap_rtc"
 
-#define OMAP_RTC_BASE			0xfffb4800
-
 /* RTC registers */
 #define OMAP_RTC_SECONDS_REG		0x00
 #define OMAP_RTC_MINUTES_REG		0x04
-- 
2.0.4

[PATCH 05/12] rtc: omap: remove redundant debug message

[Johan Hovold]

Remove redundant debug message.

The corresponding error has already been logged by rtc core.

Signed-off-by: Johan Hovold <johan@kernel.org>
---
 drivers/rtc/rtc-omap.c | 6 ++----
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/drivers/rtc/rtc-omap.c b/drivers/rtc/rtc-omap.c
index d1b5562a148b..e50ffd7063f5 100644
--- a/drivers/rtc/rtc-omap.c
+++ b/drivers/rtc/rtc-omap.c
@@ -485,11 +485,9 @@ static int __init omap_rtc_probe(struct platform_device *pdev)
 
 	rtc = devm_rtc_device_register(&pdev->dev, pdev->name,
 			&omap_rtc_ops, THIS_MODULE);
-	if (IS_ERR(rtc)) {
-		pr_debug("%s: can't register RTC device, err %ld\n",
-			pdev->name, PTR_ERR(rtc));
+	if (IS_ERR(rtc))
 		goto fail0;
-	}
+
 	platform_set_drvdata(pdev, rtc);
 
 	return 0;
-- 
2.0.4

[PATCH 06/12] rtc: omap: use dev_info and dev_dbg

[Johan Hovold]

Use dev_info and dev_dbg rather than pr_info and pr_debug.

Signed-off-by: Johan Hovold <johan@kernel.org>
---
 drivers/rtc/rtc-omap.c | 19 +++++++++----------
 1 file changed, 9 insertions(+), 10 deletions(-)

diff --git a/drivers/rtc/rtc-omap.c b/drivers/rtc/rtc-omap.c
index e50ffd7063f5..1c58920b0c88 100644
--- a/drivers/rtc/rtc-omap.c
+++ b/drivers/rtc/rtc-omap.c
@@ -392,13 +392,13 @@ static int __init omap_rtc_probe(struct platform_device *pdev)
 
 	omap_rtc_timer = platform_get_irq(pdev, 0);
 	if (omap_rtc_timer <= 0) {
-		pr_debug("%s: no update irq?\n", pdev->name);
+		dev_dbg(&pdev->dev, "no update irq\n");
 		return -ENOENT;
 	}
 
 	omap_rtc_alarm = platform_get_irq(pdev, 1);
 	if (omap_rtc_alarm <= 0) {
-		pr_debug("%s: no alarm irq?\n", pdev->name);
+		dev_dbg(&pdev->dev, "no alarm irq\n");
 		return -ENOENT;
 	}
 
@@ -430,8 +430,7 @@ static int __init omap_rtc_probe(struct platform_device *pdev)
 	/* clear old status */
 	reg = rtc_read(OMAP_RTC_STATUS_REG);
 	if (reg & (u8) OMAP_RTC_STATUS_POWER_UP) {
-		pr_info("%s: RTC power up reset detected\n",
-			pdev->name);
+		dev_info(&pdev->dev, "RTC power up reset detected\n");
 		rtc_write(OMAP_RTC_STATUS_POWER_UP, OMAP_RTC_STATUS_REG);
 	}
 	if (reg & (u8) OMAP_RTC_STATUS_ALARM)
@@ -440,22 +439,22 @@ static int __init omap_rtc_probe(struct platform_device *pdev)
 	/* handle periodic and alarm irqs */
 	if (devm_request_irq(&pdev->dev, omap_rtc_timer, rtc_irq, 0,
 			dev_name(&pdev->dev), pdev)) {
-		pr_debug("%s: RTC timer interrupt IRQ%d already claimed\n",
-			pdev->name, omap_rtc_timer);
+		dev_dbg(&pdev->dev, "RTC timer interrupt IRQ%d already claimed\n",
+				omap_rtc_timer);
 		goto fail0;
 	}
 	if ((omap_rtc_timer != omap_rtc_alarm) &&
 		(devm_request_irq(&pdev->dev, omap_rtc_alarm, rtc_irq, 0,
 			dev_name(&pdev->dev), pdev))) {
-		pr_debug("%s: RTC alarm interrupt IRQ%d already claimed\n",
-			pdev->name, omap_rtc_alarm);
+		dev_dbg(&pdev->dev, "RTC alarm interrupt IRQ%d already claimed\n",
+				omap_rtc_alarm);
 		goto fail0;
 	}
 
 	/* On boards with split power, RTC_ON_NOFF won't reset the RTC */
 	reg = rtc_read(OMAP_RTC_CTRL_REG);
 	if (reg & (u8) OMAP_RTC_CTRL_STOP)
-		pr_info("%s: already running\n", pdev->name);
+		dev_info(&pdev->dev, "already running\n");
 
 	/* force to 24 hour mode */
 	new_ctrl = reg & (OMAP_RTC_CTRL_SPLIT|OMAP_RTC_CTRL_AUTO_COMP);
@@ -476,7 +475,7 @@ static int __init omap_rtc_probe(struct platform_device *pdev)
 	 */
 
 	if (new_ctrl & (u8) OMAP_RTC_CTRL_SPLIT)
-		pr_info("%s: split power mode\n", pdev->name);
+		dev_info(&pdev->dev, "split power mode\n");
 
 	if (reg != new_ctrl)
 		rtc_write(new_ctrl, OMAP_RTC_CTRL_REG);
-- 
2.0.4

[PATCH 07/12] rtc: omap: silence bogus power-up reset message at probe

[Johan Hovold]

Some legacy RTC IP revisions has a power-up reset flag in the status
register that later revisions lack.

As this flag is always read back as set on later revisions (or is
overloaded with a different flag), make sure to only clear the flag and
print the info message on legacy platforms.

Signed-off-by: Johan Hovold <johan@kernel.org>
---
 drivers/rtc/rtc-omap.c | 23 +++++++++++++++++------
 1 file changed, 17 insertions(+), 6 deletions(-)

diff --git a/drivers/rtc/rtc-omap.c b/drivers/rtc/rtc-omap.c
index 1c58920b0c88..0ef016553a97 100644
--- a/drivers/rtc/rtc-omap.c
+++ b/drivers/rtc/rtc-omap.c
@@ -118,6 +118,12 @@
  */
 #define OMAP_RTC_HAS_32KCLK_EN		BIT(2)
 
+/*
+ * Some legacy RTC IP revisions has a power-up reset flag which later
+ * revisions lack.
+ */
+#define OMAP_RTC_HAS_POWER_UP_RESET	BIT(3)
+
 static void __iomem	*rtc_base;
 
 #define rtc_read(addr)		readb(rtc_base + (addr))
@@ -347,6 +353,7 @@ static int omap_rtc_timer;
 static struct platform_device_id omap_rtc_devtype[] = {
 	{
 		.name	= DRIVER_NAME,
+		.driver_data = OMAP_RTC_HAS_POWER_UP_RESET,
 	},
 	[OMAP_RTC_DATA_AM3352_IDX] = {
 		.name	= "am3352-rtc",
@@ -376,7 +383,7 @@ static int __init omap_rtc_probe(struct platform_device *pdev)
 {
 	struct resource		*res;
 	struct rtc_device	*rtc;
-	u8			reg, new_ctrl;
+	u8			reg, mask, new_ctrl;
 	const struct platform_device_id *id_entry;
 	const struct of_device_id *of_id;
 
@@ -429,12 +436,16 @@ static int __init omap_rtc_probe(struct platform_device *pdev)
 
 	/* clear old status */
 	reg = rtc_read(OMAP_RTC_STATUS_REG);
-	if (reg & (u8) OMAP_RTC_STATUS_POWER_UP) {
-		dev_info(&pdev->dev, "RTC power up reset detected\n");
-		rtc_write(OMAP_RTC_STATUS_POWER_UP, OMAP_RTC_STATUS_REG);
+
+	mask = OMAP_RTC_STATUS_ALARM;
+	if (id_entry->driver_data & OMAP_RTC_HAS_POWER_UP_RESET) {
+		mask |= OMAP_RTC_STATUS_POWER_UP;
+		if (reg & OMAP_RTC_STATUS_POWER_UP)
+			dev_info(&pdev->dev, "RTC power up reset detected\n");
 	}
-	if (reg & (u8) OMAP_RTC_STATUS_ALARM)
-		rtc_write(OMAP_RTC_STATUS_ALARM, OMAP_RTC_STATUS_REG);
+
+	if (reg & mask)
+		rtc_write(reg & mask, OMAP_RTC_STATUS_REG);
 
 	/* handle periodic and alarm irqs */
 	if (devm_request_irq(&pdev->dev, omap_rtc_timer, rtc_irq, 0,
-- 
2.0.4

[PATCH 08/12] rtc: omap: restore irq state after reading TC registers

[Johan Hovold]

Make sure to restore local irq state when reading the timer/calendar
(TC) registers, so that omap_rtc_read_time() can be called with
interrupts disabled.

Signed-off-by: Johan Hovold <johan@kernel.org>
---
 drivers/rtc/rtc-omap.c | 6 ++++--
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/rtc/rtc-omap.c b/drivers/rtc/rtc-omap.c
index 0ef016553a97..62e2e9a9887a 100644
--- a/drivers/rtc/rtc-omap.c
+++ b/drivers/rtc/rtc-omap.c
@@ -239,8 +239,10 @@ static void bcd2tm(struct rtc_time *tm)
 
 static int omap_rtc_read_time(struct device *dev, struct rtc_time *tm)
 {
+	unsigned long flags;
+
 	/* we don't report wday/yday/isdst ... */
-	local_irq_disable();
+	local_irq_save(flags);
 	rtc_wait_not_busy();
 
 	tm->tm_sec = rtc_read(OMAP_RTC_SECONDS_REG);
@@ -250,7 +252,7 @@ static int omap_rtc_read_time(struct device *dev, struct rtc_time *tm)
 	tm->tm_mon = rtc_read(OMAP_RTC_MONTHS_REG);
 	tm->tm_year = rtc_read(OMAP_RTC_YEARS_REG);
 
-	local_irq_enable();
+	local_irq_restore(flags);
 
 	bcd2tm(tm);
 	return 0;
-- 
2.0.4

[PATCH 09/12] rtc: omap: add support for pmic_power_en

[Johan Hovold]

Add new property "ti,system-power-controller" to register the RTC as a
power-off handler.

Some RTC IP revisions can control an external PMIC via the pmic_power_en
pin, which can be configured to transition to OFF on ALARM2 events and
back to ON on subsequent ALARM (wakealarm) events.

This is based on earlier work by Colin Foe-Parker and AnilKumar Ch. [1]

[1] https://www.mail-archive.com/linux-omap@vger.kernel.org/msg82127.html

Signed-off-by: Johan Hovold <johan@kernel.org>
---
 Documentation/devicetree/bindings/rtc/rtc-omap.txt |   9 +-
 drivers/rtc/rtc-omap.c                             | 107 ++++++++++++++++++++-
 2 files changed, 110 insertions(+), 6 deletions(-)

diff --git a/Documentation/devicetree/bindings/rtc/rtc-omap.txt b/Documentation/devicetree/bindings/rtc/rtc-omap.txt
index 5a0f02d34d95..750efd40c72e 100644
--- a/Documentation/devicetree/bindings/rtc/rtc-omap.txt
+++ b/Documentation/devicetree/bindings/rtc/rtc-omap.txt
@@ -5,11 +5,17 @@ Required properties:
 	- "ti,da830-rtc"  - for RTC IP used similar to that on DA8xx SoC family.
 	- "ti,am3352-rtc" - for RTC IP used similar to that on AM335x SoC family.
 			    This RTC IP has special WAKE-EN Register to enable
-			    Wakeup generation for event Alarm.
+			    Wakeup generation for event Alarm. It can also be
+			    used to control an external PMIC via the
+			    pmic_power_en pin.
 - reg: Address range of rtc register set
 - interrupts: rtc timer, alarm interrupts in order
 - interrupt-parent: phandle for the interrupt controller
 
+Optional properties:
+- ti,system-power-controller: whether the rtc is controlling the system power
+  through pmic_power_en
+
 Example:
 
 rtc@1c23000 {
@@ -18,4 +24,5 @@ rtc@1c23000 {
 	interrupts = <19
 		      19>;
 	interrupt-parent = <&intc>;
+	ti,system-power-controller;
 };
diff --git a/drivers/rtc/rtc-omap.c b/drivers/rtc/rtc-omap.c
index 62e2e9a9887a..b0319864dd42 100644
--- a/drivers/rtc/rtc-omap.c
+++ b/drivers/rtc/rtc-omap.c
@@ -70,6 +70,15 @@
 
 #define OMAP_RTC_IRQWAKEEN		0x7c
 
+#define OMAP_RTC_ALARM2_SECONDS_REG	0x80
+#define OMAP_RTC_ALARM2_MINUTES_REG	0x84
+#define OMAP_RTC_ALARM2_HOURS_REG	0x88
+#define OMAP_RTC_ALARM2_DAYS_REG	0x8c
+#define OMAP_RTC_ALARM2_MONTHS_REG	0x90
+#define OMAP_RTC_ALARM2_YEARS_REG	0x94
+
+#define OMAP_RTC_PMIC_REG		0x98
+
 /* OMAP_RTC_CTRL_REG bit fields: */
 #define OMAP_RTC_CTRL_SPLIT		BIT(7)
 #define OMAP_RTC_CTRL_DISABLE		BIT(6)
@@ -82,6 +91,7 @@
 
 /* OMAP_RTC_STATUS_REG bit fields: */
 #define OMAP_RTC_STATUS_POWER_UP	BIT(7)
+#define OMAP_RTC_STATUS_ALARM2		BIT(7)
 #define OMAP_RTC_STATUS_ALARM		BIT(6)
 #define OMAP_RTC_STATUS_1D_EVENT	BIT(5)
 #define OMAP_RTC_STATUS_1H_EVENT	BIT(4)
@@ -91,6 +101,7 @@
 #define OMAP_RTC_STATUS_BUSY		BIT(0)
 
 /* OMAP_RTC_INTERRUPTS_REG bit fields: */
+#define OMAP_RTC_INTERRUPTS_IT_ALARM2	BIT(4)
 #define OMAP_RTC_INTERRUPTS_IT_ALARM	BIT(3)
 #define OMAP_RTC_INTERRUPTS_IT_TIMER	BIT(2)
 
@@ -100,6 +111,9 @@
 /* OMAP_RTC_IRQWAKEEN bit fields: */
 #define OMAP_RTC_IRQWAKEEN_ALARM_WAKEEN	BIT(1)
 
+/* OMAP_RTC_PMIC bit fields: */
+#define OMAP_RTC_PMIC_POWER_EN_EN	BIT(16)
+
 /* OMAP_RTC_KICKER values */
 #define	KICK0_VALUE			0x83e70b13
 #define	KICK1_VALUE			0x95a4f1e0
@@ -124,11 +138,18 @@
  */
 #define OMAP_RTC_HAS_POWER_UP_RESET	BIT(3)
 
+/*
+ * Some RTC IP revisions can control an external PMIC via the pmic_power_en
+ * pin.
+ */
+#define OMAP_RTC_HAS_PMIC_MODE		BIT(4)
+
 static void __iomem	*rtc_base;
 
 #define rtc_read(addr)		readb(rtc_base + (addr))
 #define rtc_write(val, addr)	writeb(val, rtc_base + (addr))
 
+#define rtc_readl(addr)		readl(rtc_base + (addr))
 #define rtc_writel(val, addr)	writel(val, rtc_base + (addr))
 
 
@@ -338,6 +359,61 @@ static int omap_rtc_set_alarm(struct device *dev, struct rtc_wkalrm *alm)
 	return 0;
 }
 
+static struct platform_device *omap_rtc_power_off_dev;
+
+/*
+ * omap_rtc_poweroff: RTC-controlled power off
+ *
+ * The RTC can be used to control an external PMIC via the pmic_power_en pin,
+ * which can be configured to transition to OFF on ALARM2 events.
+ *
+ * Notes:
+ * The two-second alarm offset is the shortest offset possible as the alarm
+ * registers must be set before the next timer update and the offset
+ * calculation is to heavy for everything to be done within a single access
+ * period (~15us).
+ *
+ * Called with local interrupts disabled.
+ */
+static void omap_rtc_power_off(void)
+{
+	struct rtc_time tm;
+	unsigned long now;
+	u32 val;
+
+	/* enable pmic_power_en control */
+	val = rtc_readl(OMAP_RTC_PMIC_REG);
+	rtc_writel(val | OMAP_RTC_PMIC_POWER_EN_EN, OMAP_RTC_PMIC_REG);
+
+	/* set alarm two seconds from now */
+	omap_rtc_read_time(&omap_rtc_power_off_dev->dev, &tm);
+	rtc_tm_to_time(&tm, &now);
+	rtc_time_to_tm(now + 2, &tm);
+
+	if (tm2bcd(&tm) < 0) {
+		pr_err("%s - power off failed\n", __func__);
+		return;
+	}
+
+	rtc_wait_not_busy();
+
+	rtc_write(tm.tm_sec, OMAP_RTC_ALARM2_SECONDS_REG);
+	rtc_write(tm.tm_min, OMAP_RTC_ALARM2_MINUTES_REG);
+	rtc_write(tm.tm_hour, OMAP_RTC_ALARM2_HOURS_REG);
+	rtc_write(tm.tm_mday, OMAP_RTC_ALARM2_DAYS_REG);
+	rtc_write(tm.tm_mon, OMAP_RTC_ALARM2_MONTHS_REG);
+	rtc_write(tm.tm_year, OMAP_RTC_ALARM2_YEARS_REG);
+
+	/*
+	 * enable ALARM2 interrupt
+	 *
+	 * NOTE: this fails on AM3352 if rtc_write (writeb) is used
+	 */
+	val = rtc_read(OMAP_RTC_INTERRUPTS_REG);
+	rtc_writel(val | OMAP_RTC_INTERRUPTS_IT_ALARM2,
+			OMAP_RTC_INTERRUPTS_REG);
+}
+
 static struct rtc_class_ops omap_rtc_ops = {
 	.read_time	= omap_rtc_read_time,
 	.set_time	= omap_rtc_set_time,
@@ -360,7 +436,7 @@ static struct platform_device_id omap_rtc_devtype[] = {
 	[OMAP_RTC_DATA_AM3352_IDX] = {
 		.name	= "am3352-rtc",
 		.driver_data = OMAP_RTC_HAS_KICKER | OMAP_RTC_HAS_IRQWAKEEN |
-			       OMAP_RTC_HAS_32KCLK_EN,
+			       OMAP_RTC_HAS_32KCLK_EN | OMAP_RTC_HAS_PMIC_MODE,
 	},
 	[OMAP_RTC_DATA_DA830_IDX] = {
 		.name	= "da830-rtc",
@@ -386,12 +462,16 @@ static int __init omap_rtc_probe(struct platform_device *pdev)
 	struct resource		*res;
 	struct rtc_device	*rtc;
 	u8			reg, mask, new_ctrl;
+	bool			pm_off = false;
 	const struct platform_device_id *id_entry;
 	const struct of_device_id *of_id;
 
 	of_id = of_match_device(omap_rtc_of_match, &pdev->dev);
-	if (of_id)
+	if (of_id) {
 		pdev->id_entry = of_id->data;
+		pm_off = of_property_read_bool(pdev->dev.of_node,
+				"ti,system-power-controller");
+	}
 
 	id_entry = platform_get_device_id(pdev);
 	if (!id_entry) {
@@ -425,10 +505,12 @@ static int __init omap_rtc_probe(struct platform_device *pdev)
 		rtc_writel(KICK1_VALUE, OMAP_RTC_KICK1_REG);
 	}
 
-	/* clear pending irqs, and set 1/second periodic,
-	 * which we'll use instead of update irqs
+	/*
+	 * disable interrupts
+	 *
+	 * NOTE: ALARM2 is not cleared on AM3352 if rtc_write (writeb) is used
 	 */
-	rtc_write(0, OMAP_RTC_INTERRUPTS_REG);
+	rtc_writel(0, OMAP_RTC_INTERRUPTS_REG);
 
 	/* enable RTC functional clock */
 	if (id_entry->driver_data & OMAP_RTC_HAS_32KCLK_EN) {
@@ -440,6 +522,8 @@ static int __init omap_rtc_probe(struct platform_device *pdev)
 	reg = rtc_read(OMAP_RTC_STATUS_REG);
 
 	mask = OMAP_RTC_STATUS_ALARM;
+	if (id_entry->driver_data & OMAP_RTC_HAS_PMIC_MODE)
+		mask |= OMAP_RTC_STATUS_ALARM2;
 	if (id_entry->driver_data & OMAP_RTC_HAS_POWER_UP_RESET) {
 		mask |= OMAP_RTC_STATUS_POWER_UP;
 		if (reg & OMAP_RTC_STATUS_POWER_UP)
@@ -502,6 +586,13 @@ static int __init omap_rtc_probe(struct platform_device *pdev)
 
 	platform_set_drvdata(pdev, rtc);
 
+	if (id_entry->driver_data & OMAP_RTC_HAS_PMIC_MODE) {
+		if (pm_off && !pm_power_off) {
+			omap_rtc_power_off_dev = pdev;
+			pm_power_off = omap_rtc_power_off;
+		}
+	}
+
 	return 0;
 
 fail0:
@@ -518,6 +609,12 @@ static int __exit omap_rtc_remove(struct platform_device *pdev)
 	const struct platform_device_id *id_entry =
 				platform_get_device_id(pdev);
 
+	if (pm_power_off == omap_rtc_power_off &&
+			omap_rtc_power_off_dev == pdev) {
+		pm_power_off = NULL;
+		omap_rtc_power_off_dev = NULL;
+	}
+
 	device_init_wakeup(&pdev->dev, 0);
 
 	/* leave rtc running, but disable irqs */
-- 
2.0.4

[PATCH 10/12] rtc: omap: enable wake-up from power off

[Johan Hovold]

The ALARM interrupt must not be disabled during shutdown in order to be
able to power up the system using an RTC alarm.

Signed-off-by: Johan Hovold <johan@kernel.org>
---
 drivers/rtc/rtc-omap.c | 10 +++++++++-
 1 file changed, 9 insertions(+), 1 deletion(-)

diff --git a/drivers/rtc/rtc-omap.c b/drivers/rtc/rtc-omap.c
index b0319864dd42..8836c58901b5 100644
--- a/drivers/rtc/rtc-omap.c
+++ b/drivers/rtc/rtc-omap.c
@@ -670,7 +670,15 @@ static SIMPLE_DEV_PM_OPS(omap_rtc_pm_ops, omap_rtc_suspend, omap_rtc_resume);
 
 static void omap_rtc_shutdown(struct platform_device *pdev)
 {
-	rtc_write(0, OMAP_RTC_INTERRUPTS_REG);
+	u8 mask;
+
+	/*
+	 * Keep the ALARM interrupt enabled to allow the system to power up on
+	 * alarm events.
+	 */
+	mask = rtc_read(OMAP_RTC_INTERRUPTS_REG);
+	mask &= OMAP_RTC_INTERRUPTS_IT_ALARM;
+	rtc_write(mask, OMAP_RTC_INTERRUPTS_REG);
 }
 
 MODULE_ALIAS("platform:omap_rtc");
-- 
2.0.4

[PATCH 11/12] ARM: dts: am33xx: update rtc node compatible property

[Johan Hovold]

Enable am33xx specific RTC features (e.g. PMIC control) by adding
"ti,am3352-rtc" to the compatible property of the rtc node.

Signed-off-by: Johan Hovold <johan@kernel.org>
---
 arch/arm/boot/dts/am33xx.dtsi | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
index 3a0a161342ba..098e53602d5c 100644
--- a/arch/arm/boot/dts/am33xx.dtsi
+++ b/arch/arm/boot/dts/am33xx.dtsi
@@ -411,7 +411,7 @@
 		};
 
 		rtc: rtc@44e3e000 {
-			compatible = "ti,da830-rtc";
+			compatible = "ti,am3352-rtc", "ti,da830-rtc";
 			reg = <0x44e3e000 0x1000>;
 			interrupts = <75
 				      76>;
-- 
2.0.4

[PATCH 12/12] ARM: dts: am335x-bone-common: enable power off and rtc wake up

[Johan Hovold]

Configure the RTC as system-power controller, which allows the system to
be powered off as well as woken up again on subsequent RTC alarms.

Note that the PMIC needs to be put in SLEEP (rather than OFF) mode to
maintain RTC power. Specifically, this means that the PMIC
ti,pmic-shutdown-controller property must be left unset in order to be
able to wake up on RTC alarms.

Tested on BeagleBone Black (rev A5).

Signed-off-by: Johan Hovold <johan@kernel.org>
---
 arch/arm/boot/dts/am335x-bone-common.dtsi | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/arch/arm/boot/dts/am335x-bone-common.dtsi b/arch/arm/boot/dts/am335x-bone-common.dtsi
index bde1777b62be..d0693bea9580 100644
--- a/arch/arm/boot/dts/am335x-bone-common.dtsi
+++ b/arch/arm/boot/dts/am335x-bone-common.dtsi
@@ -298,3 +298,7 @@
 	cd-gpios = <&gpio0 6 GPIO_ACTIVE_HIGH>;
 	cd-inverted;
 };
+
+&rtc {
+	ti,system-power-controller;
+};
-- 
2.0.4

Re: [PATCH 00/12] rtc: omap: fixes and power-off feature

[Felipe Balbi]

[-- Attachment #1: Type: text/plain, Size: 869 bytes --]

HI,

On Thu, Oct 09, 2014 at 09:06:22PM +0200, Johan Hovold wrote:
> This series fixes a few issues with the omap rtc-driver, cleans up a bit
> and finally adds support for the PMIC control feature found in some
> revisions of this RTC IP block.
> 
> Ultimately, this allows for powering off the Beaglebone and waking it up
> again on RTC alarms.
> 
> I noticed yesterday that Lokesh Vutla recently posted some patches to
> add regulator support to this driver. [1] While that series has some
> issues that needs to be addressed, I still think it could be a good idea
> to rebase my pmic_power_en patch on top of it as it adds some long
> overdue device abstraction. That would be needed anyway in order to
> support the new power-off infrastructure that's in the pipe in a clean
> way. [2]

is this power-off feature "RTC-only mode" ?

-- 
balbi

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: [PATCH 01/12] rtc: omap: fix clock-source configuration

[Felipe Balbi]

[-- Attachment #1: Type: text/plain, Size: 1393 bytes --]

On Thu, Oct 09, 2014 at 09:06:23PM +0200, Johan Hovold wrote:
> Make sure not to reset the clock-source configuration when enabling the
> 32kHz clock mux.
> 
> Until the clock source can be configured through device tree we must not
> overwrite settings made by the bootloader (e.g. clock-source selection).
> 
> Fixes: cd914bba03d8 ("drivers/rtc/rtc-omap.c: add support for enabling
> 32khz clock")
> Cc: stable <stable@vger.kernel.org>
> 
> Signed-off-by: Johan Hovold <johan@kernel.org>

Reviewed-by: Felipe Balbi <balbi@ti.com>

> ---
>  drivers/rtc/rtc-omap.c | 6 ++++--
>  1 file changed, 4 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/rtc/rtc-omap.c b/drivers/rtc/rtc-omap.c
> index 21142e6574a9..f842c216f2dd 100644
> --- a/drivers/rtc/rtc-omap.c
> +++ b/drivers/rtc/rtc-omap.c
> @@ -431,8 +431,10 @@ static int __init omap_rtc_probe(struct platform_device *pdev)
>  	rtc_write(0, OMAP_RTC_INTERRUPTS_REG);
>  
>  	/* enable RTC functional clock */
> -	if (id_entry->driver_data & OMAP_RTC_HAS_32KCLK_EN)
> -		rtc_writel(OMAP_RTC_OSC_32KCLK_EN, OMAP_RTC_OSC_REG);
> +	if (id_entry->driver_data & OMAP_RTC_HAS_32KCLK_EN) {
> +		reg = rtc_read(OMAP_RTC_OSC_REG);
> +		rtc_writel(reg | OMAP_RTC_OSC_32KCLK_EN, OMAP_RTC_OSC_REG);
> +	}
>  
>  	/* clear old status */
>  	reg = rtc_read(OMAP_RTC_STATUS_REG);
> -- 
> 2.0.4
> 

-- 
balbi

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: [PATCH 02/12] rtc: omap: fix missing wakealarm attribute

[Felipe Balbi]

[-- Attachment #1: Type: text/plain, Size: 1725 bytes --]

On Thu, Oct 09, 2014 at 09:06:24PM +0200, Johan Hovold wrote:
> The platform device must be registered as wakeup capable before
> registering the class device, or the wakealarm attribute will not be
> created.
> 
> Also make sure to unregister the wakeup source on probe errors.
> 
> Fixes: 1d2e2b65d098 ("rtc: omap: restore back (hard-code) wakeup support")
> Cc: stable <stable@vger.kernel.org>
> Signed-off-by: Johan Hovold <johan@kernel.org>
> ---

Reviewed-by: Felipe Balbi <balbi@ti.com>

>  drivers/rtc/rtc-omap.c | 5 +++--
>  1 file changed, 3 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/rtc/rtc-omap.c b/drivers/rtc/rtc-omap.c
> index f842c216f2dd..828cb9983cc2 100644
> --- a/drivers/rtc/rtc-omap.c
> +++ b/drivers/rtc/rtc-omap.c
> @@ -416,6 +416,8 @@ static int __init omap_rtc_probe(struct platform_device *pdev)
>  		rtc_writel(KICK1_VALUE, OMAP_RTC_KICK1_REG);
>  	}
>  
> +	device_init_wakeup(&pdev->dev, true);
> +
>  	rtc = devm_rtc_device_register(&pdev->dev, pdev->name,
>  			&omap_rtc_ops, THIS_MODULE);
>  	if (IS_ERR(rtc)) {
> @@ -484,8 +486,6 @@ static int __init omap_rtc_probe(struct platform_device *pdev)
>  	 *    is write-only, and always reads as zero...)
>  	 */
>  
> -	device_init_wakeup(&pdev->dev, true);
> -
>  	if (new_ctrl & (u8) OMAP_RTC_CTRL_SPLIT)
>  		pr_info("%s: split power mode\n", pdev->name);
>  
> @@ -495,6 +495,7 @@ static int __init omap_rtc_probe(struct platform_device *pdev)
>  	return 0;
>  
>  fail0:
> +	device_init_wakeup(&pdev->dev, false);
>  	if (id_entry->driver_data & OMAP_RTC_HAS_KICKER)
>  		rtc_writel(0, OMAP_RTC_KICK0_REG);
>  	pm_runtime_put_sync(&pdev->dev);
> -- 
> 2.0.4
> 

-- 
balbi

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: [PATCH 03/12] rtc: omap: fix class-device registration

[Felipe Balbi]

[-- Attachment #1: Type: text/plain, Size: 3164 bytes --]

On Thu, Oct 09, 2014 at 09:06:25PM +0200, Johan Hovold wrote:
> Make sure not to register the class device until after it has been
> configured and interrupt handlers registered at probe.
> 
> Currently, the device is not fully configured (e.g. 24-hour mode) when
> the class device is registered, something which involves driver
> callbacks for example to read the current time.
> 
> This reordering also prevents user space from enabling an alarm before
> an interrupt handler has been registered.
> 
> Note that the interrupts are now registered using the platform-device
> rather than class-device name.
> 
> Signed-off-by: Johan Hovold <johan@kernel.org>
> ---
>  drivers/rtc/rtc-omap.c | 32 +++++++++++++++++---------------
>  1 file changed, 17 insertions(+), 15 deletions(-)
> 
> diff --git a/drivers/rtc/rtc-omap.c b/drivers/rtc/rtc-omap.c
> index 828cb9983cc2..2eca141e784e 100644
> --- a/drivers/rtc/rtc-omap.c
> +++ b/drivers/rtc/rtc-omap.c
> @@ -147,8 +147,9 @@ static void rtc_wait_not_busy(void)
>  	/* now we have ~15 usec to read/write various registers */
>  }
>  
> -static irqreturn_t rtc_irq(int irq, void *rtc)
> +static irqreturn_t rtc_irq(int irq, void *dev_id)
>  {
> +	struct rtc_device	*rtc = platform_get_drvdata(dev_id);
>  	unsigned long		events = 0;
>  	u8			irq_data;
>  
> @@ -164,7 +165,8 @@ static irqreturn_t rtc_irq(int irq, void *rtc)
>  	if (irq_data & OMAP_RTC_STATUS_1S_EVENT)
>  		events |= RTC_IRQF | RTC_UF;
>  
> -	rtc_update_irq(rtc, 1, events);
> +	if (rtc)
> +		rtc_update_irq(rtc, 1, events);
>  
>  	return IRQ_HANDLED;
>  }
> @@ -416,17 +418,6 @@ static int __init omap_rtc_probe(struct platform_device *pdev)
>  		rtc_writel(KICK1_VALUE, OMAP_RTC_KICK1_REG);
>  	}
>  
> -	device_init_wakeup(&pdev->dev, true);
> -
> -	rtc = devm_rtc_device_register(&pdev->dev, pdev->name,
> -			&omap_rtc_ops, THIS_MODULE);
> -	if (IS_ERR(rtc)) {
> -		pr_debug("%s: can't register RTC device, err %ld\n",
> -			pdev->name, PTR_ERR(rtc));
> -		goto fail0;
> -	}
> -	platform_set_drvdata(pdev, rtc);
> -
>  	/* clear pending irqs, and set 1/second periodic,
>  	 * which we'll use instead of update irqs
>  	 */
> @@ -450,14 +441,14 @@ static int __init omap_rtc_probe(struct platform_device *pdev)
>  
>  	/* handle periodic and alarm irqs */
>  	if (devm_request_irq(&pdev->dev, omap_rtc_timer, rtc_irq, 0,
> -			dev_name(&rtc->dev), rtc)) {
> +			dev_name(&pdev->dev), pdev)) {
>  		pr_debug("%s: RTC timer interrupt IRQ%d already claimed\n",
>  			pdev->name, omap_rtc_timer);
>  		goto fail0;
>  	}
>  	if ((omap_rtc_timer != omap_rtc_alarm) &&
>  		(devm_request_irq(&pdev->dev, omap_rtc_alarm, rtc_irq, 0,
> -			dev_name(&rtc->dev), rtc))) {
> +			dev_name(&pdev->dev), pdev))) {

i don't get it. Why pass pdev as cookie when all you need is rtc ?
Doesn't sound very good to me. Also, IRQ handler *must* be registered
only after RTC is registered. That's because if you request an IRQ here,
you could already have a pending interrupt and since you won't have a
valid rtc pointer you won't be able to clear the interrupt line.

-- 
balbi

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: [PATCH 04/12] rtc: omap: remove unused register-base define

[Felipe Balbi]

[-- Attachment #1: Type: text/plain, Size: 719 bytes --]

On Thu, Oct 09, 2014 at 09:06:26PM +0200, Johan Hovold wrote:
> Remove register-base define, which is no longer used.
> 
> Signed-off-by: Johan Hovold <johan@kernel.org>

Reviewed-by: Felipe Balbi <balbi@ti.com>

> ---
>  drivers/rtc/rtc-omap.c | 2 --
>  1 file changed, 2 deletions(-)
> 
> diff --git a/drivers/rtc/rtc-omap.c b/drivers/rtc/rtc-omap.c
> index 2eca141e784e..d1b5562a148b 100644
> --- a/drivers/rtc/rtc-omap.c
> +++ b/drivers/rtc/rtc-omap.c
> @@ -41,8 +41,6 @@
>  
>  #define	DRIVER_NAME			"omap_rtc"
>  
> -#define OMAP_RTC_BASE			0xfffb4800
> -
>  /* RTC registers */
>  #define OMAP_RTC_SECONDS_REG		0x00
>  #define OMAP_RTC_MINUTES_REG		0x04
> -- 
> 2.0.4
> 

-- 
balbi

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: [PATCH 05/12] rtc: omap: remove redundant debug message

[Felipe Balbi]

[-- Attachment #1: Type: text/plain, Size: 987 bytes --]

On Thu, Oct 09, 2014 at 09:06:27PM +0200, Johan Hovold wrote:
> Remove redundant debug message.
> 
> The corresponding error has already been logged by rtc core.
> 
> Signed-off-by: Johan Hovold <johan@kernel.org>

Reviewed-by: Felipe Balbi <balbi@ti.com>

> ---
>  drivers/rtc/rtc-omap.c | 6 ++----
>  1 file changed, 2 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/rtc/rtc-omap.c b/drivers/rtc/rtc-omap.c
> index d1b5562a148b..e50ffd7063f5 100644
> --- a/drivers/rtc/rtc-omap.c
> +++ b/drivers/rtc/rtc-omap.c
> @@ -485,11 +485,9 @@ static int __init omap_rtc_probe(struct platform_device *pdev)
>  
>  	rtc = devm_rtc_device_register(&pdev->dev, pdev->name,
>  			&omap_rtc_ops, THIS_MODULE);
> -	if (IS_ERR(rtc)) {
> -		pr_debug("%s: can't register RTC device, err %ld\n",
> -			pdev->name, PTR_ERR(rtc));
> +	if (IS_ERR(rtc))
>  		goto fail0;
> -	}
> +
>  	platform_set_drvdata(pdev, rtc);
>  
>  	return 0;
> -- 
> 2.0.4
> 

-- 
balbi

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: [PATCH 06/12] rtc: omap: use dev_info and dev_dbg

[Felipe Balbi]

[-- Attachment #1: Type: text/plain, Size: 3048 bytes --]

On Thu, Oct 09, 2014 at 09:06:28PM +0200, Johan Hovold wrote:
> Use dev_info and dev_dbg rather than pr_info and pr_debug.
> 
> Signed-off-by: Johan Hovold <johan@kernel.org>

thanks!

Reviewed-by: Felipe Balbi <balbi@ti.com>

> ---
>  drivers/rtc/rtc-omap.c | 19 +++++++++----------
>  1 file changed, 9 insertions(+), 10 deletions(-)
> 
> diff --git a/drivers/rtc/rtc-omap.c b/drivers/rtc/rtc-omap.c
> index e50ffd7063f5..1c58920b0c88 100644
> --- a/drivers/rtc/rtc-omap.c
> +++ b/drivers/rtc/rtc-omap.c
> @@ -392,13 +392,13 @@ static int __init omap_rtc_probe(struct platform_device *pdev)
>  
>  	omap_rtc_timer = platform_get_irq(pdev, 0);
>  	if (omap_rtc_timer <= 0) {
> -		pr_debug("%s: no update irq?\n", pdev->name);
> +		dev_dbg(&pdev->dev, "no update irq\n");
>  		return -ENOENT;
>  	}
>  
>  	omap_rtc_alarm = platform_get_irq(pdev, 1);
>  	if (omap_rtc_alarm <= 0) {
> -		pr_debug("%s: no alarm irq?\n", pdev->name);
> +		dev_dbg(&pdev->dev, "no alarm irq\n");
>  		return -ENOENT;
>  	}
>  
> @@ -430,8 +430,7 @@ static int __init omap_rtc_probe(struct platform_device *pdev)
>  	/* clear old status */
>  	reg = rtc_read(OMAP_RTC_STATUS_REG);
>  	if (reg & (u8) OMAP_RTC_STATUS_POWER_UP) {
> -		pr_info("%s: RTC power up reset detected\n",
> -			pdev->name);
> +		dev_info(&pdev->dev, "RTC power up reset detected\n");
>  		rtc_write(OMAP_RTC_STATUS_POWER_UP, OMAP_RTC_STATUS_REG);
>  	}
>  	if (reg & (u8) OMAP_RTC_STATUS_ALARM)
> @@ -440,22 +439,22 @@ static int __init omap_rtc_probe(struct platform_device *pdev)
>  	/* handle periodic and alarm irqs */
>  	if (devm_request_irq(&pdev->dev, omap_rtc_timer, rtc_irq, 0,
>  			dev_name(&pdev->dev), pdev)) {
> -		pr_debug("%s: RTC timer interrupt IRQ%d already claimed\n",
> -			pdev->name, omap_rtc_timer);
> +		dev_dbg(&pdev->dev, "RTC timer interrupt IRQ%d already claimed\n",
> +				omap_rtc_timer);
>  		goto fail0;
>  	}
>  	if ((omap_rtc_timer != omap_rtc_alarm) &&
>  		(devm_request_irq(&pdev->dev, omap_rtc_alarm, rtc_irq, 0,
>  			dev_name(&pdev->dev), pdev))) {
> -		pr_debug("%s: RTC alarm interrupt IRQ%d already claimed\n",
> -			pdev->name, omap_rtc_alarm);
> +		dev_dbg(&pdev->dev, "RTC alarm interrupt IRQ%d already claimed\n",
> +				omap_rtc_alarm);
>  		goto fail0;
>  	}
>  
>  	/* On boards with split power, RTC_ON_NOFF won't reset the RTC */
>  	reg = rtc_read(OMAP_RTC_CTRL_REG);
>  	if (reg & (u8) OMAP_RTC_CTRL_STOP)
> -		pr_info("%s: already running\n", pdev->name);
> +		dev_info(&pdev->dev, "already running\n");
>  
>  	/* force to 24 hour mode */
>  	new_ctrl = reg & (OMAP_RTC_CTRL_SPLIT|OMAP_RTC_CTRL_AUTO_COMP);
> @@ -476,7 +475,7 @@ static int __init omap_rtc_probe(struct platform_device *pdev)
>  	 */
>  
>  	if (new_ctrl & (u8) OMAP_RTC_CTRL_SPLIT)
> -		pr_info("%s: split power mode\n", pdev->name);
> +		dev_info(&pdev->dev, "split power mode\n");
>  
>  	if (reg != new_ctrl)
>  		rtc_write(new_ctrl, OMAP_RTC_CTRL_REG);
> -- 
> 2.0.4
> 

-- 
balbi

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: [PATCH 07/12] rtc: omap: silence bogus power-up reset message at probe

[Felipe Balbi]

[-- Attachment #1: Type: text/plain, Size: 2578 bytes --]

On Thu, Oct 09, 2014 at 09:06:29PM +0200, Johan Hovold wrote:
> Some legacy RTC IP revisions has a power-up reset flag in the status
> register that later revisions lack.
> 
> As this flag is always read back as set on later revisions (or is
> overloaded with a different flag), make sure to only clear the flag and
> print the info message on legacy platforms.
> 
> Signed-off-by: Johan Hovold <johan@kernel.org>

Reviewed-by: Felipe Balbi <balbi@ti.com>

> ---
>  drivers/rtc/rtc-omap.c | 23 +++++++++++++++++------
>  1 file changed, 17 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/rtc/rtc-omap.c b/drivers/rtc/rtc-omap.c
> index 1c58920b0c88..0ef016553a97 100644
> --- a/drivers/rtc/rtc-omap.c
> +++ b/drivers/rtc/rtc-omap.c
> @@ -118,6 +118,12 @@
>   */
>  #define OMAP_RTC_HAS_32KCLK_EN		BIT(2)
>  
> +/*
> + * Some legacy RTC IP revisions has a power-up reset flag which later
> + * revisions lack.
> + */
> +#define OMAP_RTC_HAS_POWER_UP_RESET	BIT(3)
> +
>  static void __iomem	*rtc_base;
>  
>  #define rtc_read(addr)		readb(rtc_base + (addr))
> @@ -347,6 +353,7 @@ static int omap_rtc_timer;
>  static struct platform_device_id omap_rtc_devtype[] = {
>  	{
>  		.name	= DRIVER_NAME,
> +		.driver_data = OMAP_RTC_HAS_POWER_UP_RESET,
>  	},
>  	[OMAP_RTC_DATA_AM3352_IDX] = {
>  		.name	= "am3352-rtc",
> @@ -376,7 +383,7 @@ static int __init omap_rtc_probe(struct platform_device *pdev)
>  {
>  	struct resource		*res;
>  	struct rtc_device	*rtc;
> -	u8			reg, new_ctrl;
> +	u8			reg, mask, new_ctrl;
>  	const struct platform_device_id *id_entry;
>  	const struct of_device_id *of_id;
>  
> @@ -429,12 +436,16 @@ static int __init omap_rtc_probe(struct platform_device *pdev)
>  
>  	/* clear old status */
>  	reg = rtc_read(OMAP_RTC_STATUS_REG);
> -	if (reg & (u8) OMAP_RTC_STATUS_POWER_UP) {
> -		dev_info(&pdev->dev, "RTC power up reset detected\n");
> -		rtc_write(OMAP_RTC_STATUS_POWER_UP, OMAP_RTC_STATUS_REG);
> +
> +	mask = OMAP_RTC_STATUS_ALARM;
> +	if (id_entry->driver_data & OMAP_RTC_HAS_POWER_UP_RESET) {
> +		mask |= OMAP_RTC_STATUS_POWER_UP;
> +		if (reg & OMAP_RTC_STATUS_POWER_UP)
> +			dev_info(&pdev->dev, "RTC power up reset detected\n");
>  	}
> -	if (reg & (u8) OMAP_RTC_STATUS_ALARM)
> -		rtc_write(OMAP_RTC_STATUS_ALARM, OMAP_RTC_STATUS_REG);
> +
> +	if (reg & mask)
> +		rtc_write(reg & mask, OMAP_RTC_STATUS_REG);
>  
>  	/* handle periodic and alarm irqs */
>  	if (devm_request_irq(&pdev->dev, omap_rtc_timer, rtc_irq, 0,
> -- 
> 2.0.4
> 

-- 
balbi

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: [PATCH 08/12] rtc: omap: restore irq state after reading TC registers

[Felipe Balbi]

[-- Attachment #1: Type: text/plain, Size: 1019 bytes --]

Hi,

On Thu, Oct 09, 2014 at 09:06:30PM +0200, Johan Hovold wrote:
> Make sure to restore local irq state when reading the timer/calendar
> (TC) registers, so that omap_rtc_read_time() can be called with
> interrupts disabled.
> 
> Signed-off-by: Johan Hovold <johan@kernel.org>
> ---
>  drivers/rtc/rtc-omap.c | 6 ++++--
>  1 file changed, 4 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/rtc/rtc-omap.c b/drivers/rtc/rtc-omap.c
> index 0ef016553a97..62e2e9a9887a 100644
> --- a/drivers/rtc/rtc-omap.c
> +++ b/drivers/rtc/rtc-omap.c
> @@ -239,8 +239,10 @@ static void bcd2tm(struct rtc_time *tm)
>  
>  static int omap_rtc_read_time(struct device *dev, struct rtc_time *tm)
>  {
> +	unsigned long flags;
> +
>  	/* we don't report wday/yday/isdst ... */
> -	local_irq_disable();
> +	local_irq_save(flags);

you should really convert these to a real spin_lock_irq*(), that's
because local_irq* do not get re-written with RT patchset, so this
pretty much "breaks" RT.

-- 
balbi

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: [PATCH 07/12] rtc: omap: silence bogus power-up reset message at probe

[Felipe Balbi]

[-- Attachment #1: Type: text/plain, Size: 617 bytes --]

On Fri, Oct 10, 2014 at 01:00:54PM -0500, Felipe Balbi wrote:
> On Thu, Oct 09, 2014 at 09:06:29PM +0200, Johan Hovold wrote:
> > Some legacy RTC IP revisions has a power-up reset flag in the status
> > register that later revisions lack.
> > 
> > As this flag is always read back as set on later revisions (or is
> > overloaded with a different flag), make sure to only clear the flag and
> > print the info message on legacy platforms.
> > 
> > Signed-off-by: Johan Hovold <johan@kernel.org>
> 
> Reviewed-by: Felipe Balbi <balbi@ti.com>

oh, btw. This should be done for DT probes too.

-- 
balbi

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: [PATCH 09/12] rtc: omap: add support for pmic_power_en

[Felipe Balbi]

[-- Attachment #1: Type: text/plain, Size: 1955 bytes --]

Hi,

On Thu, Oct 09, 2014 at 09:06:31PM +0200, Johan Hovold wrote:
> @@ -124,11 +138,18 @@
>   */
>  #define OMAP_RTC_HAS_POWER_UP_RESET	BIT(3)
>  
> +/*
> + * Some RTC IP revisions can control an external PMIC via the pmic_power_en
> + * pin.
> + */
> +#define OMAP_RTC_HAS_PMIC_MODE		BIT(4)
> +
>  static void __iomem	*rtc_base;
>  
>  #define rtc_read(addr)		readb(rtc_base + (addr))
>  #define rtc_write(val, addr)	writeb(val, rtc_base + (addr))
>  
> +#define rtc_readl(addr)		readl(rtc_base + (addr))

looks like this should be part of another patch. Or, at a minimum (since
it's so minor), it deserves a mention on commit log.

>  #define rtc_writel(val, addr)	writel(val, rtc_base + (addr))
>  
>  
> @@ -338,6 +359,61 @@ static int omap_rtc_set_alarm(struct device *dev, struct rtc_wkalrm *alm)
>  	return 0;
>  }
>  
> +static struct platform_device *omap_rtc_power_off_dev;
> +
> +/*
> + * omap_rtc_poweroff: RTC-controlled power off
> + *
> + * The RTC can be used to control an external PMIC via the pmic_power_en pin,
> + * which can be configured to transition to OFF on ALARM2 events.
> + *
> + * Notes:
> + * The two-second alarm offset is the shortest offset possible as the alarm
> + * registers must be set before the next timer update and the offset
> + * calculation is to heavy for everything to be done within a single access

s/to/too

> @@ -425,10 +505,12 @@ static int __init omap_rtc_probe(struct platform_device *pdev)
>  		rtc_writel(KICK1_VALUE, OMAP_RTC_KICK1_REG);
>  	}
>  
> -	/* clear pending irqs, and set 1/second periodic,
> -	 * which we'll use instead of update irqs
> +	/*
> +	 * disable interrupts
> +	 *
> +	 * NOTE: ALARM2 is not cleared on AM3352 if rtc_write (writeb) is used
>  	 */
> -	rtc_write(0, OMAP_RTC_INTERRUPTS_REG);
> +	rtc_writel(0, OMAP_RTC_INTERRUPTS_REG);

bug fix, should be part of a separate patch and Cc stable :-)

-- 
balbi

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: [PATCH 10/12] rtc: omap: enable wake-up from power off

[Felipe Balbi]

[-- Attachment #1: Type: text/plain, Size: 1157 bytes --]

On Thu, Oct 09, 2014 at 09:06:32PM +0200, Johan Hovold wrote:
> The ALARM interrupt must not be disabled during shutdown in order to be
> able to power up the system using an RTC alarm.
> 
> Signed-off-by: Johan Hovold <johan@kernel.org>

nicely done!

Reviewed-by: Felipe Balbi <balbi@ti.com>

> ---
>  drivers/rtc/rtc-omap.c | 10 +++++++++-
>  1 file changed, 9 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/rtc/rtc-omap.c b/drivers/rtc/rtc-omap.c
> index b0319864dd42..8836c58901b5 100644
> --- a/drivers/rtc/rtc-omap.c
> +++ b/drivers/rtc/rtc-omap.c
> @@ -670,7 +670,15 @@ static SIMPLE_DEV_PM_OPS(omap_rtc_pm_ops, omap_rtc_suspend, omap_rtc_resume);
>  
>  static void omap_rtc_shutdown(struct platform_device *pdev)
>  {
> -	rtc_write(0, OMAP_RTC_INTERRUPTS_REG);
> +	u8 mask;
> +
> +	/*
> +	 * Keep the ALARM interrupt enabled to allow the system to power up on
> +	 * alarm events.
> +	 */
> +	mask = rtc_read(OMAP_RTC_INTERRUPTS_REG);
> +	mask &= OMAP_RTC_INTERRUPTS_IT_ALARM;
> +	rtc_write(mask, OMAP_RTC_INTERRUPTS_REG);
>  }
>  
>  MODULE_ALIAS("platform:omap_rtc");
> -- 
> 2.0.4
> 

-- 
balbi

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: [PATCH 11/12] ARM: dts: am33xx: update rtc node compatible property

[Felipe Balbi]

[-- Attachment #1: Type: text/plain, Size: 859 bytes --]

On Thu, Oct 09, 2014 at 09:06:33PM +0200, Johan Hovold wrote:
> Enable am33xx specific RTC features (e.g. PMIC control) by adding
> "ti,am3352-rtc" to the compatible property of the rtc node.
> 
> Signed-off-by: Johan Hovold <johan@kernel.org>

Reviewed-by: Felipe Balbi <balbi@ti.com>

> ---
>  arch/arm/boot/dts/am33xx.dtsi | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
> index 3a0a161342ba..098e53602d5c 100644
> --- a/arch/arm/boot/dts/am33xx.dtsi
> +++ b/arch/arm/boot/dts/am33xx.dtsi
> @@ -411,7 +411,7 @@
>  		};
>  
>  		rtc: rtc@44e3e000 {
> -			compatible = "ti,da830-rtc";
> +			compatible = "ti,am3352-rtc", "ti,da830-rtc";
>  			reg = <0x44e3e000 0x1000>;
>  			interrupts = <75
>  				      76>;
> -- 
> 2.0.4
> 

-- 
balbi

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: [PATCH 12/12] ARM: dts: am335x-bone-common: enable power off and rtc wake up

[Felipe Balbi]

[-- Attachment #1: Type: text/plain, Size: 1302 bytes --]

On Thu, Oct 09, 2014 at 09:06:34PM +0200, Johan Hovold wrote:
> Configure the RTC as system-power controller, which allows the system to
> be powered off as well as woken up again on subsequent RTC alarms.
> 
> Note that the PMIC needs to be put in SLEEP (rather than OFF) mode to
> maintain RTC power. Specifically, this means that the PMIC
> ti,pmic-shutdown-controller property must be left unset in order to be
> able to wake up on RTC alarms.
> 
> Tested on BeagleBone Black (rev A5).

one thing though. IIRC, rtc-only mode does not work with ES1.0 and
beagle-bone white uses that. Perhaps move this from bone-common to
boneblack.dts ?

other than that

Reviewed-by: Felipe Balbi <balbi@ti.com>

> Signed-off-by: Johan Hovold <johan@kernel.org>
> ---
>  arch/arm/boot/dts/am335x-bone-common.dtsi | 4 ++++
>  1 file changed, 4 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/am335x-bone-common.dtsi b/arch/arm/boot/dts/am335x-bone-common.dtsi
> index bde1777b62be..d0693bea9580 100644
> --- a/arch/arm/boot/dts/am335x-bone-common.dtsi
> +++ b/arch/arm/boot/dts/am335x-bone-common.dtsi
> @@ -298,3 +298,7 @@
>  	cd-gpios = <&gpio0 6 GPIO_ACTIVE_HIGH>;
>  	cd-inverted;
>  };
> +
> +&rtc {
> +	ti,system-power-controller;
> +};
> -- 
> 2.0.4
> 

-- 
balbi

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: [PATCH 00/12] rtc: omap: fixes and power-off feature

[Johan Hovold]

On Fri, Oct 10, 2014 at 12:54:22PM -0500, Felipe Balbi wrote:
> HI,
> 
> On Thu, Oct 09, 2014 at 09:06:22PM +0200, Johan Hovold wrote:
> > This series fixes a few issues with the omap rtc-driver, cleans up a bit
> > and finally adds support for the PMIC control feature found in some
> > revisions of this RTC IP block.
> > 
> > Ultimately, this allows for powering off the Beaglebone and waking it up
> > again on RTC alarms.
> > 
> > I noticed yesterday that Lokesh Vutla recently posted some patches to
> > add regulator support to this driver. [1] While that series has some
> > issues that needs to be addressed, I still think it could be a good idea
> > to rebase my pmic_power_en patch on top of it as it adds some long
> > overdue device abstraction. That would be needed anyway in order to
> > support the new power-off infrastructure that's in the pipe in a clean
> > way. [2]
> 
> is this power-off feature "RTC-only mode" ?

Yes, I believe so, at least as long as RTC power is maintained. The
pmic_power_en pin can otherwise still be used to power off. 

On the BeagleBone the PMIC can be configured to enter OFF or SLEEP mode
on power off, where the latter (and default) mode keeps the RTC power
supply enabled.

Thanks for the fast review, Felipe.

Johan

Re: [PATCH 03/12] rtc: omap: fix class-device registration

[Johan Hovold]

On Fri, Oct 10, 2014 at 12:59:30PM -0500, Felipe Balbi wrote:
> On Thu, Oct 09, 2014 at 09:06:25PM +0200, Johan Hovold wrote:
> > Make sure not to register the class device until after it has been
> > configured and interrupt handlers registered at probe.
> > 
> > Currently, the device is not fully configured (e.g. 24-hour mode) when
> > the class device is registered, something which involves driver
> > callbacks for example to read the current time.
> > 
> > This reordering also prevents user space from enabling an alarm before
> > an interrupt handler has been registered.
> > 
> > Note that the interrupts are now registered using the platform-device
> > rather than class-device name.
> > 
> > Signed-off-by: Johan Hovold <johan@kernel.org>
> > ---
> >  drivers/rtc/rtc-omap.c | 32 +++++++++++++++++---------------
> >  1 file changed, 17 insertions(+), 15 deletions(-)
> > 
> > diff --git a/drivers/rtc/rtc-omap.c b/drivers/rtc/rtc-omap.c
> > index 828cb9983cc2..2eca141e784e 100644
> > --- a/drivers/rtc/rtc-omap.c
> > +++ b/drivers/rtc/rtc-omap.c
> > @@ -147,8 +147,9 @@ static void rtc_wait_not_busy(void)
> >  	/* now we have ~15 usec to read/write various registers */
> >  }
> >  
> > -static irqreturn_t rtc_irq(int irq, void *rtc)
> > +static irqreturn_t rtc_irq(int irq, void *dev_id)
> >  {
> > +	struct rtc_device	*rtc = platform_get_drvdata(dev_id);
> >  	unsigned long		events = 0;
> >  	u8			irq_data;
> >  
> > @@ -164,7 +165,8 @@ static irqreturn_t rtc_irq(int irq, void *rtc)
> >  	if (irq_data & OMAP_RTC_STATUS_1S_EVENT)
> >  		events |= RTC_IRQF | RTC_UF;
> >  
> > -	rtc_update_irq(rtc, 1, events);
> > +	if (rtc)
> > +		rtc_update_irq(rtc, 1, events);
> >  
> >  	return IRQ_HANDLED;
> >  }
> > @@ -416,17 +418,6 @@ static int __init omap_rtc_probe(struct platform_device *pdev)
> >  		rtc_writel(KICK1_VALUE, OMAP_RTC_KICK1_REG);
> >  	}
> >  
> > -	device_init_wakeup(&pdev->dev, true);
> > -
> > -	rtc = devm_rtc_device_register(&pdev->dev, pdev->name,
> > -			&omap_rtc_ops, THIS_MODULE);
> > -	if (IS_ERR(rtc)) {
> > -		pr_debug("%s: can't register RTC device, err %ld\n",
> > -			pdev->name, PTR_ERR(rtc));
> > -		goto fail0;
> > -	}
> > -	platform_set_drvdata(pdev, rtc);
> > -
> >  	/* clear pending irqs, and set 1/second periodic,
> >  	 * which we'll use instead of update irqs
> >  	 */
> > @@ -450,14 +441,14 @@ static int __init omap_rtc_probe(struct platform_device *pdev)
> >  
> >  	/* handle periodic and alarm irqs */
> >  	if (devm_request_irq(&pdev->dev, omap_rtc_timer, rtc_irq, 0,
> > -			dev_name(&rtc->dev), rtc)) {
> > +			dev_name(&pdev->dev), pdev)) {
> >  		pr_debug("%s: RTC timer interrupt IRQ%d already claimed\n",
> >  			pdev->name, omap_rtc_timer);
> >  		goto fail0;
> >  	}
> >  	if ((omap_rtc_timer != omap_rtc_alarm) &&
> >  		(devm_request_irq(&pdev->dev, omap_rtc_alarm, rtc_irq, 0,
> > -			dev_name(&rtc->dev), rtc))) {
> > +			dev_name(&pdev->dev), pdev))) {
> 
> i don't get it. Why pass pdev as cookie when all you need is rtc ?
> Doesn't sound very good to me. Also, IRQ handler *must* be registered
> only after RTC is registered. That's because if you request an IRQ here,
> you could already have a pending interrupt and since you won't have a
> valid rtc pointer you won't be able to clear the interrupt line.

We don't need the class device (rtc pointer) to clear the interrupt
line. The iomem base is enough, and that is static until Lokesh adds the
struct omap_rtc_dev abstraction. Then we pass that as the cookie.

And all RTC interrupts have been disabled, and pending interrupts
cleared before registering the handlers so that should not be a problem.

To the contrary, once the class device has been registered user-space
could enable interrupts at any time and that is why everything should
have been set up before.

Johan

Re: [PATCH 08/12] rtc: omap: restore irq state after reading TC registers

[Johan Hovold]

On Fri, Oct 10, 2014 at 01:02:31PM -0500, Felipe Balbi wrote:
> Hi,
> 
> On Thu, Oct 09, 2014 at 09:06:30PM +0200, Johan Hovold wrote:
> > Make sure to restore local irq state when reading the timer/calendar
> > (TC) registers, so that omap_rtc_read_time() can be called with
> > interrupts disabled.
> > 
> > Signed-off-by: Johan Hovold <johan@kernel.org>
> > ---
> >  drivers/rtc/rtc-omap.c | 6 ++++--
> >  1 file changed, 4 insertions(+), 2 deletions(-)
> > 
> > diff --git a/drivers/rtc/rtc-omap.c b/drivers/rtc/rtc-omap.c
> > index 0ef016553a97..62e2e9a9887a 100644
> > --- a/drivers/rtc/rtc-omap.c
> > +++ b/drivers/rtc/rtc-omap.c
> > @@ -239,8 +239,10 @@ static void bcd2tm(struct rtc_time *tm)
> >  
> >  static int omap_rtc_read_time(struct device *dev, struct rtc_time *tm)
> >  {
> > +	unsigned long flags;
> > +
> >  	/* we don't report wday/yday/isdst ... */
> > -	local_irq_disable();
> > +	local_irq_save(flags);
> 
> you should really convert these to a real spin_lock_irq*(), that's
> because local_irq* do not get re-written with RT patchset, so this
> pretty much "breaks" RT.

The driver uses local_irq* throughout to guarantee registers are not
read or written during an update event.

In fact, at least on AM33xx, this is not even necessary when reading (as
opposed to writing) the TC registers, but I did not dare change that
without knowing how the legacy platforms work in this respect.

Do you suggest doing this conversion as part of, or on top of, this
series?

Johan

Re: [PATCH 07/12] rtc: omap: silence bogus power-up reset message at probe

[Johan Hovold]

On Fri, Oct 10, 2014 at 01:02:56PM -0500, Felipe Balbi wrote:
> On Fri, Oct 10, 2014 at 01:00:54PM -0500, Felipe Balbi wrote:
> > On Thu, Oct 09, 2014 at 09:06:29PM +0200, Johan Hovold wrote:
> > > Some legacy RTC IP revisions has a power-up reset flag in the status
> > > register that later revisions lack.
> > > 
> > > As this flag is always read back as set on later revisions (or is
> > > overloaded with a different flag), make sure to only clear the flag and
> > > print the info message on legacy platforms.
> > > 
> > > Signed-off-by: Johan Hovold <johan@kernel.org>
> > 
> > Reviewed-by: Felipe Balbi <balbi@ti.com>
> 
> oh, btw. This should be done for DT probes too.

What do you mean? This is for DT probes (of "ti,da830-rtc" and
"ti,am3352-rtc"). DT probing of legacy RTC IPs is currently not
supported.

Are you suggesting I should add a new compatible string for that?

Johan

Re: [PATCH 09/12] rtc: omap: add support for pmic_power_en

[Johan Hovold]

On Fri, Oct 10, 2014 at 01:07:27PM -0500, Felipe Balbi wrote:
> Hi,
> 
> On Thu, Oct 09, 2014 at 09:06:31PM +0200, Johan Hovold wrote:
> > @@ -124,11 +138,18 @@
> >   */
> >  #define OMAP_RTC_HAS_POWER_UP_RESET	BIT(3)
> >  
> > +/*
> > + * Some RTC IP revisions can control an external PMIC via the pmic_power_en
> > + * pin.
> > + */
> > +#define OMAP_RTC_HAS_PMIC_MODE		BIT(4)
> > +
> >  static void __iomem	*rtc_base;
> >  
> >  #define rtc_read(addr)		readb(rtc_base + (addr))
> >  #define rtc_write(val, addr)	writeb(val, rtc_base + (addr))
> >  
> > +#define rtc_readl(addr)		readl(rtc_base + (addr))
> 
> looks like this should be part of another patch. Or, at a minimum (since
> it's so minor), it deserves a mention on commit log.

Ok, I'll add it separately.

> >  #define rtc_writel(val, addr)	writel(val, rtc_base + (addr))
> >  
> >  
> > @@ -338,6 +359,61 @@ static int omap_rtc_set_alarm(struct device *dev, struct rtc_wkalrm *alm)
> >  	return 0;
> >  }
> >  
> > +static struct platform_device *omap_rtc_power_off_dev;
> > +
> > +/*
> > + * omap_rtc_poweroff: RTC-controlled power off
> > + *
> > + * The RTC can be used to control an external PMIC via the pmic_power_en pin,
> > + * which can be configured to transition to OFF on ALARM2 events.
> > + *
> > + * Notes:
> > + * The two-second alarm offset is the shortest offset possible as the alarm
> > + * registers must be set before the next timer update and the offset
> > + * calculation is to heavy for everything to be done within a single access
> 
> s/to/too

Thanks.

> > @@ -425,10 +505,12 @@ static int __init omap_rtc_probe(struct platform_device *pdev)
> >  		rtc_writel(KICK1_VALUE, OMAP_RTC_KICK1_REG);
> >  	}
> >  
> > -	/* clear pending irqs, and set 1/second periodic,
> > -	 * which we'll use instead of update irqs
> > +	/*
> > +	 * disable interrupts
> > +	 *
> > +	 * NOTE: ALARM2 is not cleared on AM3352 if rtc_write (writeb) is used
> >  	 */
> > -	rtc_write(0, OMAP_RTC_INTERRUPTS_REG);
> > +	rtc_writel(0, OMAP_RTC_INTERRUPTS_REG);
> 
> bug fix, should be part of a separate patch and Cc stable :-)

Yeah, I guess you're right. Even though ALARM2 would never have been set
by Linux before this patch we might as well fix this separately.

Thanks,
Johan

Re: [PATCH 12/12] ARM: dts: am335x-bone-common: enable power off and rtc wake up

[Johan Hovold]

On Fri, Oct 10, 2014 at 01:09:49PM -0500, Felipe Balbi wrote:
> On Thu, Oct 09, 2014 at 09:06:34PM +0200, Johan Hovold wrote:
> > Configure the RTC as system-power controller, which allows the system to
> > be powered off as well as woken up again on subsequent RTC alarms.
> > 
> > Note that the PMIC needs to be put in SLEEP (rather than OFF) mode to
> > maintain RTC power. Specifically, this means that the PMIC
> > ti,pmic-shutdown-controller property must be left unset in order to be
> > able to wake up on RTC alarms.
> > 
> > Tested on BeagleBone Black (rev A5).
> 
> one thing though. IIRC, rtc-only mode does not work with ES1.0 and
> beagle-bone white uses that. Perhaps move this from bone-common to
> boneblack.dts ?

Yeah, I had a quick look at the errata and you seem to be correct. I'll
move it to boneblack.dts.

> other than that
> 
> Reviewed-by: Felipe Balbi <balbi@ti.com>

Thanks,
Johan

Re: [PATCH 00/12] rtc: omap: fixes and power-off feature

[Tony Lindgren]

* Johan Hovold <johan@kernel.org> [141011 02:42]:
> On Fri, Oct 10, 2014 at 12:54:22PM -0500, Felipe Balbi wrote:
> > 
> > is this power-off feature "RTC-only mode" ?
> 
> Yes, I believe so, at least as long as RTC power is maintained. The
> pmic_power_en pin can otherwise still be used to power off. 
> 
> On the BeagleBone the PMIC can be configured to enter OFF or SLEEP mode
> on power off, where the latter (and default) mode keeps the RTC power
> supply enabled.
> 
> Thanks for the fast review, Felipe.

Great :) I assume adding the regulator support to this driver should
also help in the 35xx case?

That is assuming that RTC power can be configured as a Linux
regulator on 35xx.

Regards,

Tony

Re: [PATCH 08/12] rtc: omap: restore irq state after reading TC registers

[Felipe Balbi]

[-- Attachment #1: Type: text/plain, Size: 1728 bytes --]

On Sat, Oct 11, 2014 at 12:12:01PM +0200, Johan Hovold wrote:
> On Fri, Oct 10, 2014 at 01:02:31PM -0500, Felipe Balbi wrote:
> > Hi,
> > 
> > On Thu, Oct 09, 2014 at 09:06:30PM +0200, Johan Hovold wrote:
> > > Make sure to restore local irq state when reading the timer/calendar
> > > (TC) registers, so that omap_rtc_read_time() can be called with
> > > interrupts disabled.
> > > 
> > > Signed-off-by: Johan Hovold <johan@kernel.org>
> > > ---
> > >  drivers/rtc/rtc-omap.c | 6 ++++--
> > >  1 file changed, 4 insertions(+), 2 deletions(-)
> > > 
> > > diff --git a/drivers/rtc/rtc-omap.c b/drivers/rtc/rtc-omap.c
> > > index 0ef016553a97..62e2e9a9887a 100644
> > > --- a/drivers/rtc/rtc-omap.c
> > > +++ b/drivers/rtc/rtc-omap.c
> > > @@ -239,8 +239,10 @@ static void bcd2tm(struct rtc_time *tm)
> > >  
> > >  static int omap_rtc_read_time(struct device *dev, struct rtc_time *tm)
> > >  {
> > > +	unsigned long flags;
> > > +
> > >  	/* we don't report wday/yday/isdst ... */
> > > -	local_irq_disable();
> > > +	local_irq_save(flags);
> > 
> > you should really convert these to a real spin_lock_irq*(), that's
> > because local_irq* do not get re-written with RT patchset, so this
> > pretty much "breaks" RT.
> 
> The driver uses local_irq* throughout to guarantee registers are not
> read or written during an update event.
> 
> In fact, at least on AM33xx, this is not even necessary when reading (as
> opposed to writing) the TC registers, but I did not dare change that
> without knowing how the legacy platforms work in this respect.
> 
> Do you suggest doing this conversion as part of, or on top of, this
> series?

probably on top of is. Safer that way.

-- 
balbi

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: [PATCH 07/12] rtc: omap: silence bogus power-up reset message at probe

[Felipe Balbi]

[-- Attachment #1: Type: text/plain, Size: 1161 bytes --]

Hi,

On Sat, Oct 11, 2014 at 12:20:04PM +0200, Johan Hovold wrote:
> On Fri, Oct 10, 2014 at 01:02:56PM -0500, Felipe Balbi wrote:
> > On Fri, Oct 10, 2014 at 01:00:54PM -0500, Felipe Balbi wrote:
> > > On Thu, Oct 09, 2014 at 09:06:29PM +0200, Johan Hovold wrote:
> > > > Some legacy RTC IP revisions has a power-up reset flag in the status
> > > > register that later revisions lack.
> > > > 
> > > > As this flag is always read back as set on later revisions (or is
> > > > overloaded with a different flag), make sure to only clear the flag and
> > > > print the info message on legacy platforms.
> > > > 
> > > > Signed-off-by: Johan Hovold <johan@kernel.org>
> > > 
> > > Reviewed-by: Felipe Balbi <balbi@ti.com>
> > 
> > oh, btw. This should be done for DT probes too.
> 
> What do you mean? This is for DT probes (of "ti,da830-rtc" and
> "ti,am3352-rtc"). DT probing of legacy RTC IPs is currently not
> supported.
> 
> Are you suggesting I should add a new compatible string for that?

it seemed to me that you're only passing the new flag through
platform_device_id table, not DT table. Did I miss something ?

-- 
balbi

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: [PATCH 07/12] rtc: omap: silence bogus power-up reset message at probe

[Johan Hovold]

On Sat, Oct 11, 2014 at 07:50:07PM -0500, Felipe Balbi wrote:
> Hi,
> 
> On Sat, Oct 11, 2014 at 12:20:04PM +0200, Johan Hovold wrote:
> > On Fri, Oct 10, 2014 at 01:02:56PM -0500, Felipe Balbi wrote:
> > > On Fri, Oct 10, 2014 at 01:00:54PM -0500, Felipe Balbi wrote:
> > > > On Thu, Oct 09, 2014 at 09:06:29PM +0200, Johan Hovold wrote:
> > > > > Some legacy RTC IP revisions has a power-up reset flag in the status
> > > > > register that later revisions lack.
> > > > > 
> > > > > As this flag is always read back as set on later revisions (or is
> > > > > overloaded with a different flag), make sure to only clear the flag and
> > > > > print the info message on legacy platforms.
> > > > > 
> > > > > Signed-off-by: Johan Hovold <johan@kernel.org>
> > > > 
> > > > Reviewed-by: Felipe Balbi <balbi@ti.com>
> > > 
> > > oh, btw. This should be done for DT probes too.
> > 
> > What do you mean? This is for DT probes (of "ti,da830-rtc" and
> > "ti,am3352-rtc"). DT probing of legacy RTC IPs is currently not
> > supported.
> > 
> > Are you suggesting I should add a new compatible string for that?
> 
> it seemed to me that you're only passing the new flag through
> platform_device_id table, not DT table. Did I miss something ?

Ah, that's just the way the driver currently encodes the IP revision
differences. The platform_device_id entries are references from
of_device_id data. Should probably clean that up as well.

Thanks again for the review. I'll post a new version when I'm back from
Düsseldorf and ELC-E/Plumbers.

Johan

Re: [PATCH 07/12] rtc: omap: silence bogus power-up reset message at probe

[Felipe Balbi]

[-- Attachment #1: Type: text/plain, Size: 1719 bytes --]

Hi,

On Sun, Oct 12, 2014 at 08:42:40PM +0200, Johan Hovold wrote:
> On Sat, Oct 11, 2014 at 07:50:07PM -0500, Felipe Balbi wrote:
> > Hi,
> > 
> > On Sat, Oct 11, 2014 at 12:20:04PM +0200, Johan Hovold wrote:
> > > On Fri, Oct 10, 2014 at 01:02:56PM -0500, Felipe Balbi wrote:
> > > > On Fri, Oct 10, 2014 at 01:00:54PM -0500, Felipe Balbi wrote:
> > > > > On Thu, Oct 09, 2014 at 09:06:29PM +0200, Johan Hovold wrote:
> > > > > > Some legacy RTC IP revisions has a power-up reset flag in the status
> > > > > > register that later revisions lack.
> > > > > > 
> > > > > > As this flag is always read back as set on later revisions (or is
> > > > > > overloaded with a different flag), make sure to only clear the flag and
> > > > > > print the info message on legacy platforms.
> > > > > > 
> > > > > > Signed-off-by: Johan Hovold <johan@kernel.org>
> > > > > 
> > > > > Reviewed-by: Felipe Balbi <balbi@ti.com>
> > > > 
> > > > oh, btw. This should be done for DT probes too.
> > > 
> > > What do you mean? This is for DT probes (of "ti,da830-rtc" and
> > > "ti,am3352-rtc"). DT probing of legacy RTC IPs is currently not
> > > supported.
> > > 
> > > Are you suggesting I should add a new compatible string for that?
> > 
> > it seemed to me that you're only passing the new flag through
> > platform_device_id table, not DT table. Did I miss something ?
> 
> Ah, that's just the way the driver currently encodes the IP revision
> differences. The platform_device_id entries are references from
> of_device_id data. Should probably clean that up as well.

oh, alright :-)

> Thanks again for the review. I'll post a new version when I'm back from

no problem.

-- 
balbi

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: [PATCH 03/12] rtc: omap: fix class-device registration

[Felipe Balbi]

[-- Attachment #1: Type: text/plain, Size: 1723 bytes --]

Hi,

On Sat, Oct 11, 2014 at 11:59:47AM +0200, Johan Hovold wrote:
> > > @@ -450,14 +441,14 @@ static int __init omap_rtc_probe(struct platform_device *pdev)
> > >  
> > >  	/* handle periodic and alarm irqs */
> > >  	if (devm_request_irq(&pdev->dev, omap_rtc_timer, rtc_irq, 0,
> > > -			dev_name(&rtc->dev), rtc)) {
> > > +			dev_name(&pdev->dev), pdev)) {
> > >  		pr_debug("%s: RTC timer interrupt IRQ%d already claimed\n",
> > >  			pdev->name, omap_rtc_timer);
> > >  		goto fail0;
> > >  	}
> > >  	if ((omap_rtc_timer != omap_rtc_alarm) &&
> > >  		(devm_request_irq(&pdev->dev, omap_rtc_alarm, rtc_irq, 0,
> > > -			dev_name(&rtc->dev), rtc))) {
> > > +			dev_name(&pdev->dev), pdev))) {
> > 
> > i don't get it. Why pass pdev as cookie when all you need is rtc ?
> > Doesn't sound very good to me. Also, IRQ handler *must* be registered
> > only after RTC is registered. That's because if you request an IRQ here,
> > you could already have a pending interrupt and since you won't have a
> > valid rtc pointer you won't be able to clear the interrupt line.
> 
> We don't need the class device (rtc pointer) to clear the interrupt
> line. The iomem base is enough, and that is static until Lokesh adds the
> struct omap_rtc_dev abstraction. Then we pass that as the cookie.

I wonder how that patch will look like ;-)

> And all RTC interrupts have been disabled, and pending interrupts
> cleared before registering the handlers so that should not be a problem.
> 
> To the contrary, once the class device has been registered user-space
> could enable interrupts at any time and that is why everything should
> have been set up before.

alright, got it. Thanks

-- 
balbi

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: [PATCH 00/12] rtc: omap: fixes and power-off feature

[Felipe Balbi]

[-- Attachment #1: Type: text/plain, Size: 1109 bytes --]

Hi,

On Thu, Oct 09, 2014 at 09:06:22PM +0200, Johan Hovold wrote:
> This series fixes a few issues with the omap rtc-driver, cleans up a bit
> and finally adds support for the PMIC control feature found in some
> revisions of this RTC IP block.
> 
> Ultimately, this allows for powering off the Beaglebone and waking it up
> again on RTC alarms.
> 
> I noticed yesterday that Lokesh Vutla recently posted some patches to
> add regulator support to this driver. [1] While that series has some
> issues that needs to be addressed, I still think it could be a good idea
> to rebase my pmic_power_en patch on top of it as it adds some long
> overdue device abstraction. That would be needed anyway in order to
> support the new power-off infrastructure that's in the pipe in a clean
> way. [2]
> 
> So my suggestion is to merge the first seven patches, rebase Lokesh
> series on top of that, and then I rebase my final five patches on top
> of that in turn. Hopefully, the new power-off handler call chain will
> have stabilised by then.

BTW, how do you test this series ?

-- 
balbi

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: [PATCH 00/12] rtc: omap: fixes and power-off feature

[Johan Hovold]

On Wed, Oct 15, 2014 at 11:55:02AM -0500, Felipe Balbi wrote:
> Hi,
> 
> On Thu, Oct 09, 2014 at 09:06:22PM +0200, Johan Hovold wrote:
> > This series fixes a few issues with the omap rtc-driver, cleans up a bit
> > and finally adds support for the PMIC control feature found in some
> > revisions of this RTC IP block.
> > 
> > Ultimately, this allows for powering off the Beaglebone and waking it up
> > again on RTC alarms.
> > 
> > I noticed yesterday that Lokesh Vutla recently posted some patches to
> > add regulator support to this driver. [1] While that series has some
> > issues that needs to be addressed, I still think it could be a good idea
> > to rebase my pmic_power_en patch on top of it as it adds some long
> > overdue device abstraction. That would be needed anyway in order to
> > support the new power-off infrastructure that's in the pipe in a clean
> > way. [2]
> > 
> > So my suggestion is to merge the first seven patches, rebase Lokesh
> > series on top of that, and then I rebase my final five patches on top
> > of that in turn. Hopefully, the new power-off handler call chain will
> > have stabilised by then.
> 
> BTW, how do you test this series ?

Set a 30 second wakealarm using the sysfs attribute of the rtc class
device and power off the BBB:

	echo +30 >wakealarm; poweroff

Johan

Re: [PATCH 00/12] rtc: omap: fixes and power-off feature

[Felipe Balbi]

[-- Attachment #1: Type: text/plain, Size: 2557 bytes --]

On Wed, Oct 15, 2014 at 07:06:28PM +0200, Johan Hovold wrote:
> On Wed, Oct 15, 2014 at 11:55:02AM -0500, Felipe Balbi wrote:
> > Hi,
> > 
> > On Thu, Oct 09, 2014 at 09:06:22PM +0200, Johan Hovold wrote:
> > > This series fixes a few issues with the omap rtc-driver, cleans up a bit
> > > and finally adds support for the PMIC control feature found in some
> > > revisions of this RTC IP block.
> > > 
> > > Ultimately, this allows for powering off the Beaglebone and waking it up
> > > again on RTC alarms.
> > > 
> > > I noticed yesterday that Lokesh Vutla recently posted some patches to
> > > add regulator support to this driver. [1] While that series has some
> > > issues that needs to be addressed, I still think it could be a good idea
> > > to rebase my pmic_power_en patch on top of it as it adds some long
> > > overdue device abstraction. That would be needed anyway in order to
> > > support the new power-off infrastructure that's in the pipe in a clean
> > > way. [2]
> > > 
> > > So my suggestion is to merge the first seven patches, rebase Lokesh
> > > series on top of that, and then I rebase my final five patches on top
> > > of that in turn. Hopefully, the new power-off handler call chain will
> > > have stabilised by then.
> > 
> > BTW, how do you test this series ?
> 
> Set a 30 second wakealarm using the sysfs attribute of the rtc class
> device and power off the BBB:
> 
> 	echo +30 >wakealarm; poweroff

sweet!!!! It worked just fine :-)

Too bad there's yet another DRM bug:

[  271.150158] Kernel panic - not syncing: Attempted to kill init! exitcode=0x00000000
[  271.150158] 
[  271.159725] CPU: 0 PID: 1 Comm: systemd-shutdow Not tainted 3.17.0-08392-g7fe2269-dirty #326
[  271.168567] [<c00175a4>] (unwind_backtrace) from [<c00132f0>] (show_stack+0x20/0x24)
[  271.176668] [<c00132f0>] (show_stack) from [<c06573a4>] (dump_stack+0x8c/0xa4)
[  271.184215] [<c06573a4>] (dump_stack) from [<c0654f10>] (panic+0xa0/0x220)
[  271.191405] [<c0654f10>] (panic) from [<c0049e54>] (do_exit+0x974/0x9d0)
[  271.198410] [<c0049e54>] (do_exit) from [<c0067694>] (SyS_reboot+0x14c/0x1e8)
[  271.205870] [<c0067694>] (SyS_reboot) from [<c000f080>] (ret_fast_syscall+0x0/0x48)
[  271.214023] drm_kms_helper: panic occurred, switching back to text console
[  271.221312] ---[ end Kernel panic - not syncing: Attempted to kill init! exitcode=0x00000000

In any case, board still powered up after 30 seconds(-ish). So this gets
a:

Tested-by: Felipe Balbi <balbi@ti.com>

-- 
balbi

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

[PATCH v2 00/20] rtc: omap: fixes and power-off feature

[Johan Hovold]

This series fixes a few issues with the omap rtc-driver, cleans up a
bit, adds device abstraction, and finally adds support for the PMIC
control feature found in some revisions of this RTC IP block.

Ultimately, this allows for powering off the Beaglebone and waking it up
again on RTC alarms.

Changes since v1 include:

 - add device abstraction
 - add structured device-type info
 - fix interrupt disable at probe separately
 - register interrupts after class device as before
 - add helper to read raw bcd time
 - more clean ups
 - add copyright entry
 - enable pmic control only for Beaglebone Black

I realised that it was better to keep this patch series self-contained
and include the device abstraction in it, rather than rely on some
patches yet to be posted (contrary to what I proposed in v1). It should
now be straight forward to add deferred-probing and regulator support on
top of this series instead. [1]

I've kept Felipe's Reviewed-by tags only on the first and last couple of
patches which have not changed (in any significant way).

For the record, the new functionality is easily tested on BBB with:

	echo +30 >/sys/class/rtc/rtc0/wakealarm; poweroff

There are some patches floating around to add power-off handler
call chains [2] as well as an RFC for a generic "poweroff-source"
property [3]. Since it is unclear if, when (and through which tree) this
will eventually go in, I suggest merging this series as-is now and do
the trivial updates to use these new interfaces once the infrastructure
is in place.

Johan

[1] https://lkml.org/lkml/2014/10/9/427
[2] https://lkml.org/lkml/2014/10/7/30
[3] https://lkml.org/lkml/2014/10/7/654


Johan Hovold (20):
  rtc: omap: fix clock-source configuration
  rtc: omap: fix missing wakealarm attribute
  rtc: omap: fix interrupt disable at probe
  rtc: omap: clean up probe error handling
  rtc: omap: fix class-device registration
  rtc: omap: remove unused register-base define
  rtc: omap: use dev_info
  rtc: omap: make platform-device id table const
  rtc: omap: add device abstraction
  rtc: omap: remove DRIVER_NAME macro
  rtc: omap: add structured device-type info
  rtc: omap: silence bogus power-up reset message at probe
  rtc: omap: add helper to read raw bcd time
  rtc: omap: add helper to read 32-bit registers
  rtc: omap: add support for pmic_power_en
  rtc: omap: enable wake-up from power off
  rtc: omap: fix minor coding style issues
  rtc: omap: add copyright entry
  ARM: dts: am33xx: update rtc-node compatible property
  ARM: dts: am335x-boneblack: enable power off and rtc wake up

 Documentation/devicetree/bindings/rtc/rtc-omap.txt |   9 +-
 arch/arm/boot/dts/am335x-boneblack.dts             |   4 +
 arch/arm/boot/dts/am33xx.dtsi                      |   2 +-
 drivers/rtc/rtc-omap.c                             | 540 +++++++++++++--------
 4 files changed, 355 insertions(+), 200 deletions(-)

-- 
2.0.4

[PATCH v2 01/20] rtc: omap: fix clock-source configuration

[Johan Hovold]

Make sure not to reset the clock-source configuration when enabling the
32kHz clock mux.

Until the clock source can be configured through device tree we must not
overwrite settings made by the bootloader (e.g. clock-source selection).

Fixes: cd914bba03d8 ("drivers/rtc/rtc-omap.c: add support for enabling
32khz clock")
Cc: stable <stable@vger.kernel.org>
Reviewed-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: Johan Hovold <johan@kernel.org>
---
 drivers/rtc/rtc-omap.c | 6 ++++--
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/rtc/rtc-omap.c b/drivers/rtc/rtc-omap.c
index 21142e6574a9..f842c216f2dd 100644
--- a/drivers/rtc/rtc-omap.c
+++ b/drivers/rtc/rtc-omap.c
@@ -431,8 +431,10 @@ static int __init omap_rtc_probe(struct platform_device *pdev)
 	rtc_write(0, OMAP_RTC_INTERRUPTS_REG);
 
 	/* enable RTC functional clock */
-	if (id_entry->driver_data & OMAP_RTC_HAS_32KCLK_EN)
-		rtc_writel(OMAP_RTC_OSC_32KCLK_EN, OMAP_RTC_OSC_REG);
+	if (id_entry->driver_data & OMAP_RTC_HAS_32KCLK_EN) {
+		reg = rtc_read(OMAP_RTC_OSC_REG);
+		rtc_writel(reg | OMAP_RTC_OSC_32KCLK_EN, OMAP_RTC_OSC_REG);
+	}
 
 	/* clear old status */
 	reg = rtc_read(OMAP_RTC_STATUS_REG);
-- 
2.0.4

[PATCH v2 02/20] rtc: omap: fix missing wakealarm attribute

[Johan Hovold]

The platform device must be registered as wakeup capable before
registering the class device, or the wakealarm attribute will not be
created.

Also make sure to unregister the wakeup source on probe errors.

Fixes: 1d2e2b65d098 ("rtc: omap: restore back (hard-code) wakeup support")
Cc: stable <stable@vger.kernel.org>
Reviewed-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: Johan Hovold <johan@kernel.org>
---
 drivers/rtc/rtc-omap.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/rtc/rtc-omap.c b/drivers/rtc/rtc-omap.c
index f842c216f2dd..828cb9983cc2 100644
--- a/drivers/rtc/rtc-omap.c
+++ b/drivers/rtc/rtc-omap.c
@@ -416,6 +416,8 @@ static int __init omap_rtc_probe(struct platform_device *pdev)
 		rtc_writel(KICK1_VALUE, OMAP_RTC_KICK1_REG);
 	}
 
+	device_init_wakeup(&pdev->dev, true);
+
 	rtc = devm_rtc_device_register(&pdev->dev, pdev->name,
 			&omap_rtc_ops, THIS_MODULE);
 	if (IS_ERR(rtc)) {
@@ -484,8 +486,6 @@ static int __init omap_rtc_probe(struct platform_device *pdev)
 	 *    is write-only, and always reads as zero...)
 	 */
 
-	device_init_wakeup(&pdev->dev, true);
-
 	if (new_ctrl & (u8) OMAP_RTC_CTRL_SPLIT)
 		pr_info("%s: split power mode\n", pdev->name);
 
@@ -495,6 +495,7 @@ static int __init omap_rtc_probe(struct platform_device *pdev)
 	return 0;
 
 fail0:
+	device_init_wakeup(&pdev->dev, false);
 	if (id_entry->driver_data & OMAP_RTC_HAS_KICKER)
 		rtc_writel(0, OMAP_RTC_KICK0_REG);
 	pm_runtime_put_sync(&pdev->dev);
-- 
2.0.4

[PATCH v2 03/20] rtc: omap: fix interrupt disable at probe

[Johan Hovold]

Use writel instead of writeb when disabling interrupts at probe as
ALARM2 is not cleared otherwise on some IP-block revisions (e.g.
AM3352).

Note that the driver currently never enables the ALARM2 interrupt.

Signed-off-by: Johan Hovold <johan@kernel.org>
---
 drivers/rtc/rtc-omap.c | 8 +++++---
 1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/drivers/rtc/rtc-omap.c b/drivers/rtc/rtc-omap.c
index 828cb9983cc2..813d475fe7c6 100644
--- a/drivers/rtc/rtc-omap.c
+++ b/drivers/rtc/rtc-omap.c
@@ -427,10 +427,12 @@ static int __init omap_rtc_probe(struct platform_device *pdev)
 	}
 	platform_set_drvdata(pdev, rtc);
 
-	/* clear pending irqs, and set 1/second periodic,
-	 * which we'll use instead of update irqs
+	/*
+	 * disable interrupts
+	 *
+	 * NOTE: ALARM2 is not cleared on AM3352 if rtc_write (writeb) is used
 	 */
-	rtc_write(0, OMAP_RTC_INTERRUPTS_REG);
+	rtc_writel(0, OMAP_RTC_INTERRUPTS_REG);
 
 	/* enable RTC functional clock */
 	if (id_entry->driver_data & OMAP_RTC_HAS_32KCLK_EN) {
-- 
2.0.4

[PATCH v2 04/20] rtc: omap: clean up probe error handling

[Johan Hovold]

Remove some debug messages and return errors from subsystems rather than
always fail with -EIO.

Note that the class-registration error has already been logged by rtc
core.

Signed-off-by: Johan Hovold <johan@kernel.org>
---
 drivers/rtc/rtc-omap.c | 41 ++++++++++++++++++-----------------------
 1 file changed, 18 insertions(+), 23 deletions(-)

diff --git a/drivers/rtc/rtc-omap.c b/drivers/rtc/rtc-omap.c
index 813d475fe7c6..6b10db5a5702 100644
--- a/drivers/rtc/rtc-omap.c
+++ b/drivers/rtc/rtc-omap.c
@@ -379,6 +379,7 @@ static int __init omap_rtc_probe(struct platform_device *pdev)
 	u8			reg, new_ctrl;
 	const struct platform_device_id *id_entry;
 	const struct of_device_id *of_id;
+	int ret;
 
 	of_id = of_match_device(omap_rtc_of_match, &pdev->dev);
 	if (of_id)
@@ -391,16 +392,12 @@ static int __init omap_rtc_probe(struct platform_device *pdev)
 	}
 
 	omap_rtc_timer = platform_get_irq(pdev, 0);
-	if (omap_rtc_timer <= 0) {
-		pr_debug("%s: no update irq?\n", pdev->name);
+	if (omap_rtc_timer <= 0)
 		return -ENOENT;
-	}
 
 	omap_rtc_alarm = platform_get_irq(pdev, 1);
-	if (omap_rtc_alarm <= 0) {
-		pr_debug("%s: no alarm irq?\n", pdev->name);
+	if (omap_rtc_alarm <= 0)
 		return -ENOENT;
-	}
 
 	res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
 	rtc_base = devm_ioremap_resource(&pdev->dev, res);
@@ -421,9 +418,8 @@ static int __init omap_rtc_probe(struct platform_device *pdev)
 	rtc = devm_rtc_device_register(&pdev->dev, pdev->name,
 			&omap_rtc_ops, THIS_MODULE);
 	if (IS_ERR(rtc)) {
-		pr_debug("%s: can't register RTC device, err %ld\n",
-			pdev->name, PTR_ERR(rtc));
-		goto fail0;
+		ret = PTR_ERR(rtc);
+		goto err;
 	}
 	platform_set_drvdata(pdev, rtc);
 
@@ -451,18 +447,16 @@ static int __init omap_rtc_probe(struct platform_device *pdev)
 		rtc_write(OMAP_RTC_STATUS_ALARM, OMAP_RTC_STATUS_REG);
 
 	/* handle periodic and alarm irqs */
-	if (devm_request_irq(&pdev->dev, omap_rtc_timer, rtc_irq, 0,
-			dev_name(&rtc->dev), rtc)) {
-		pr_debug("%s: RTC timer interrupt IRQ%d already claimed\n",
-			pdev->name, omap_rtc_timer);
-		goto fail0;
-	}
-	if ((omap_rtc_timer != omap_rtc_alarm) &&
-		(devm_request_irq(&pdev->dev, omap_rtc_alarm, rtc_irq, 0,
-			dev_name(&rtc->dev), rtc))) {
-		pr_debug("%s: RTC alarm interrupt IRQ%d already claimed\n",
-			pdev->name, omap_rtc_alarm);
-		goto fail0;
+	ret = devm_request_irq(&pdev->dev, omap_rtc_timer, rtc_irq, 0,
+			dev_name(&rtc->dev), rtc);
+	if (ret)
+		goto err;
+
+	if (omap_rtc_timer != omap_rtc_alarm) {
+		ret = devm_request_irq(&pdev->dev, omap_rtc_alarm, rtc_irq, 0,
+				dev_name(&rtc->dev), rtc);
+		if (ret)
+			goto err;
 	}
 
 	/* On boards with split power, RTC_ON_NOFF won't reset the RTC */
@@ -496,13 +490,14 @@ static int __init omap_rtc_probe(struct platform_device *pdev)
 
 	return 0;
 
-fail0:
+err:
 	device_init_wakeup(&pdev->dev, false);
 	if (id_entry->driver_data & OMAP_RTC_HAS_KICKER)
 		rtc_writel(0, OMAP_RTC_KICK0_REG);
 	pm_runtime_put_sync(&pdev->dev);
 	pm_runtime_disable(&pdev->dev);
-	return -EIO;
+
+	return ret;
 }
 
 static int __exit omap_rtc_remove(struct platform_device *pdev)
-- 
2.0.4

[PATCH v2 05/20] rtc: omap: fix class-device registration

[Johan Hovold]

Make sure not to register the class device until after the device has
been configured.

Currently, the device is not fully configured (e.g. 24-hour mode) when
the class device is registered, something which involves driver
callbacks for example to read the current time.

Signed-off-by: Johan Hovold <johan@kernel.org>
---
 drivers/rtc/rtc-omap.c | 46 +++++++++++++++++++++++-----------------------
 1 file changed, 23 insertions(+), 23 deletions(-)

diff --git a/drivers/rtc/rtc-omap.c b/drivers/rtc/rtc-omap.c
index 6b10db5a5702..813bed270867 100644
--- a/drivers/rtc/rtc-omap.c
+++ b/drivers/rtc/rtc-omap.c
@@ -413,16 +413,6 @@ static int __init omap_rtc_probe(struct platform_device *pdev)
 		rtc_writel(KICK1_VALUE, OMAP_RTC_KICK1_REG);
 	}
 
-	device_init_wakeup(&pdev->dev, true);
-
-	rtc = devm_rtc_device_register(&pdev->dev, pdev->name,
-			&omap_rtc_ops, THIS_MODULE);
-	if (IS_ERR(rtc)) {
-		ret = PTR_ERR(rtc);
-		goto err;
-	}
-	platform_set_drvdata(pdev, rtc);
-
 	/*
 	 * disable interrupts
 	 *
@@ -446,19 +436,6 @@ static int __init omap_rtc_probe(struct platform_device *pdev)
 	if (reg & (u8) OMAP_RTC_STATUS_ALARM)
 		rtc_write(OMAP_RTC_STATUS_ALARM, OMAP_RTC_STATUS_REG);
 
-	/* handle periodic and alarm irqs */
-	ret = devm_request_irq(&pdev->dev, omap_rtc_timer, rtc_irq, 0,
-			dev_name(&rtc->dev), rtc);
-	if (ret)
-		goto err;
-
-	if (omap_rtc_timer != omap_rtc_alarm) {
-		ret = devm_request_irq(&pdev->dev, omap_rtc_alarm, rtc_irq, 0,
-				dev_name(&rtc->dev), rtc);
-		if (ret)
-			goto err;
-	}
-
 	/* On boards with split power, RTC_ON_NOFF won't reset the RTC */
 	reg = rtc_read(OMAP_RTC_CTRL_REG);
 	if (reg & (u8) OMAP_RTC_CTRL_STOP)
@@ -488,6 +465,29 @@ static int __init omap_rtc_probe(struct platform_device *pdev)
 	if (reg != new_ctrl)
 		rtc_write(new_ctrl, OMAP_RTC_CTRL_REG);
 
+	device_init_wakeup(&pdev->dev, true);
+
+	rtc = devm_rtc_device_register(&pdev->dev, pdev->name,
+			&omap_rtc_ops, THIS_MODULE);
+	if (IS_ERR(rtc)) {
+		ret = PTR_ERR(rtc);
+		goto err;
+	}
+	platform_set_drvdata(pdev, rtc);
+
+	/* handle periodic and alarm irqs */
+	ret = devm_request_irq(&pdev->dev, omap_rtc_timer, rtc_irq, 0,
+			dev_name(&rtc->dev), rtc);
+	if (ret)
+		goto err;
+
+	if (omap_rtc_timer != omap_rtc_alarm) {
+		ret = devm_request_irq(&pdev->dev, omap_rtc_alarm, rtc_irq, 0,
+				dev_name(&rtc->dev), rtc);
+		if (ret)
+			goto err;
+	}
+
 	return 0;
 
 err:
-- 
2.0.4

[PATCH v2 06/20] rtc: omap: remove unused register-base define

[Johan Hovold]

Remove register-base define, which is no longer used.

Signed-off-by: Johan Hovold <johan@kernel.org>
---
 drivers/rtc/rtc-omap.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/rtc/rtc-omap.c b/drivers/rtc/rtc-omap.c
index 813bed270867..c750678de652 100644
--- a/drivers/rtc/rtc-omap.c
+++ b/drivers/rtc/rtc-omap.c
@@ -41,8 +41,6 @@
 
 #define	DRIVER_NAME			"omap_rtc"
 
-#define OMAP_RTC_BASE			0xfffb4800
-
 /* RTC registers */
 #define OMAP_RTC_SECONDS_REG		0x00
 #define OMAP_RTC_MINUTES_REG		0x04
-- 
2.0.4

[PATCH v2 07/20] rtc: omap: use dev_info

[Johan Hovold]

Use dev_info rather than pr_info.

Signed-off-by: Johan Hovold <johan@kernel.org>
---
 drivers/rtc/rtc-omap.c | 7 +++----
 1 file changed, 3 insertions(+), 4 deletions(-)

diff --git a/drivers/rtc/rtc-omap.c b/drivers/rtc/rtc-omap.c
index c750678de652..dbb88e46c25d 100644
--- a/drivers/rtc/rtc-omap.c
+++ b/drivers/rtc/rtc-omap.c
@@ -427,8 +427,7 @@ static int __init omap_rtc_probe(struct platform_device *pdev)
 	/* clear old status */
 	reg = rtc_read(OMAP_RTC_STATUS_REG);
 	if (reg & (u8) OMAP_RTC_STATUS_POWER_UP) {
-		pr_info("%s: RTC power up reset detected\n",
-			pdev->name);
+		dev_info(&pdev->dev, "RTC power up reset detected\n");
 		rtc_write(OMAP_RTC_STATUS_POWER_UP, OMAP_RTC_STATUS_REG);
 	}
 	if (reg & (u8) OMAP_RTC_STATUS_ALARM)
@@ -437,7 +436,7 @@ static int __init omap_rtc_probe(struct platform_device *pdev)
 	/* On boards with split power, RTC_ON_NOFF won't reset the RTC */
 	reg = rtc_read(OMAP_RTC_CTRL_REG);
 	if (reg & (u8) OMAP_RTC_CTRL_STOP)
-		pr_info("%s: already running\n", pdev->name);
+		dev_info(&pdev->dev, "already running\n");
 
 	/* force to 24 hour mode */
 	new_ctrl = reg & (OMAP_RTC_CTRL_SPLIT|OMAP_RTC_CTRL_AUTO_COMP);
@@ -458,7 +457,7 @@ static int __init omap_rtc_probe(struct platform_device *pdev)
 	 */
 
 	if (new_ctrl & (u8) OMAP_RTC_CTRL_SPLIT)
-		pr_info("%s: split power mode\n", pdev->name);
+		dev_info(&pdev->dev, "split power mode\n");
 
 	if (reg != new_ctrl)
 		rtc_write(new_ctrl, OMAP_RTC_CTRL_REG);
-- 
2.0.4

[PATCH v2 08/20] rtc: omap: make platform-device id table const

[Johan Hovold]

Make platform-device id table const.

Signed-off-by: Johan Hovold <johan@kernel.org>
---
 drivers/rtc/rtc-omap.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/rtc/rtc-omap.c b/drivers/rtc/rtc-omap.c
index dbb88e46c25d..bdee29674589 100644
--- a/drivers/rtc/rtc-omap.c
+++ b/drivers/rtc/rtc-omap.c
@@ -342,7 +342,7 @@ static int omap_rtc_timer;
 #define	OMAP_RTC_DATA_AM3352_IDX	1
 #define	OMAP_RTC_DATA_DA830_IDX		2
 
-static struct platform_device_id omap_rtc_devtype[] = {
+static const struct platform_device_id omap_rtc_devtype[] = {
 	{
 		.name	= DRIVER_NAME,
 	},
-- 
2.0.4

[PATCH v2 09/20] rtc: omap: add device abstraction

[Johan Hovold]

Add struct omap_rtc to hold previously global data as well as the
IP-block feature flags.

Also convert the register-access macros to proper inline helper functions.

Signed-off-by: Johan Hovold <johan@kernel.org>
---
 drivers/rtc/rtc-omap.c | 239 +++++++++++++++++++++++++++----------------------
 1 file changed, 133 insertions(+), 106 deletions(-)

diff --git a/drivers/rtc/rtc-omap.c b/drivers/rtc/rtc-omap.c
index bdee29674589..1da610b8981f 100644
--- a/drivers/rtc/rtc-omap.c
+++ b/drivers/rtc/rtc-omap.c
@@ -118,26 +118,42 @@
  */
 #define OMAP_RTC_HAS_32KCLK_EN		BIT(2)
 
-static void __iomem	*rtc_base;
+struct omap_rtc {
+	struct rtc_device *rtc;
+	void __iomem *base;
+	int irq_alarm;
+	int irq_timer;
+	u8 interrupts_reg;
+	unsigned long flags;
+};
 
-#define rtc_read(addr)		readb(rtc_base + (addr))
-#define rtc_write(val, addr)	writeb(val, rtc_base + (addr))
+static inline u8 rtc_read(struct omap_rtc *rtc, unsigned int reg)
+{
+	return readb(rtc->base + reg);
+}
 
-#define rtc_writel(val, addr)	writel(val, rtc_base + (addr))
+static inline void rtc_write(struct omap_rtc *rtc, unsigned int reg, u8 val)
+{
+	writeb(val, rtc->base + reg);
+}
 
+static inline void rtc_writel(struct omap_rtc *rtc, unsigned int reg, u32 val)
+{
+	writel(val, rtc->base + reg);
+}
 
 /* we rely on the rtc framework to handle locking (rtc->ops_lock),
  * so the only other requirement is that register accesses which
  * require BUSY to be clear are made with IRQs locally disabled
  */
-static void rtc_wait_not_busy(void)
+static void rtc_wait_not_busy(struct omap_rtc *rtc)
 {
 	int	count = 0;
 	u8	status;
 
 	/* BUSY may stay active for 1/32768 second (~30 usec) */
 	for (count = 0; count < 50; count++) {
-		status = rtc_read(OMAP_RTC_STATUS_REG);
+		status = rtc_read(rtc, OMAP_RTC_STATUS_REG);
 		if ((status & (u8)OMAP_RTC_STATUS_BUSY) == 0)
 			break;
 		udelay(1);
@@ -145,16 +161,17 @@ static void rtc_wait_not_busy(void)
 	/* now we have ~15 usec to read/write various registers */
 }
 
-static irqreturn_t rtc_irq(int irq, void *rtc)
+static irqreturn_t rtc_irq(int irq, void *dev_id)
 {
+	struct omap_rtc		*rtc = dev_id;
 	unsigned long		events = 0;
 	u8			irq_data;
 
-	irq_data = rtc_read(OMAP_RTC_STATUS_REG);
+	irq_data = rtc_read(rtc, OMAP_RTC_STATUS_REG);
 
 	/* alarm irq? */
 	if (irq_data & OMAP_RTC_STATUS_ALARM) {
-		rtc_write(OMAP_RTC_STATUS_ALARM, OMAP_RTC_STATUS_REG);
+		rtc_write(rtc, OMAP_RTC_STATUS_REG, OMAP_RTC_STATUS_ALARM);
 		events |= RTC_IRQF | RTC_AF;
 	}
 
@@ -162,23 +179,21 @@ static irqreturn_t rtc_irq(int irq, void *rtc)
 	if (irq_data & OMAP_RTC_STATUS_1S_EVENT)
 		events |= RTC_IRQF | RTC_UF;
 
-	rtc_update_irq(rtc, 1, events);
+	rtc_update_irq(rtc->rtc, 1, events);
 
 	return IRQ_HANDLED;
 }
 
 static int omap_rtc_alarm_irq_enable(struct device *dev, unsigned int enabled)
 {
+	struct omap_rtc *rtc = dev_get_drvdata(dev);
 	u8 reg, irqwake_reg = 0;
-	struct platform_device *pdev = to_platform_device(dev);
-	const struct platform_device_id *id_entry =
-					platform_get_device_id(pdev);
 
 	local_irq_disable();
-	rtc_wait_not_busy();
-	reg = rtc_read(OMAP_RTC_INTERRUPTS_REG);
-	if (id_entry->driver_data & OMAP_RTC_HAS_IRQWAKEEN)
-		irqwake_reg = rtc_read(OMAP_RTC_IRQWAKEEN);
+	rtc_wait_not_busy(rtc);
+	reg = rtc_read(rtc, OMAP_RTC_INTERRUPTS_REG);
+	if (rtc->flags & OMAP_RTC_HAS_IRQWAKEEN)
+		irqwake_reg = rtc_read(rtc, OMAP_RTC_IRQWAKEEN);
 
 	if (enabled) {
 		reg |= OMAP_RTC_INTERRUPTS_IT_ALARM;
@@ -187,10 +202,10 @@ static int omap_rtc_alarm_irq_enable(struct device *dev, unsigned int enabled)
 		reg &= ~OMAP_RTC_INTERRUPTS_IT_ALARM;
 		irqwake_reg &= ~OMAP_RTC_IRQWAKEEN_ALARM_WAKEEN;
 	}
-	rtc_wait_not_busy();
-	rtc_write(reg, OMAP_RTC_INTERRUPTS_REG);
-	if (id_entry->driver_data & OMAP_RTC_HAS_IRQWAKEEN)
-		rtc_write(irqwake_reg, OMAP_RTC_IRQWAKEEN);
+	rtc_wait_not_busy(rtc);
+	rtc_write(rtc, OMAP_RTC_INTERRUPTS_REG, reg);
+	if (rtc->flags & OMAP_RTC_HAS_IRQWAKEEN)
+		rtc_write(rtc, OMAP_RTC_IRQWAKEEN, irqwake_reg);
 	local_irq_enable();
 
 	return 0;
@@ -231,16 +246,18 @@ static void bcd2tm(struct rtc_time *tm)
 
 static int omap_rtc_read_time(struct device *dev, struct rtc_time *tm)
 {
+	struct omap_rtc *rtc = dev_get_drvdata(dev);
+
 	/* we don't report wday/yday/isdst ... */
 	local_irq_disable();
-	rtc_wait_not_busy();
+	rtc_wait_not_busy(rtc);
 
-	tm->tm_sec = rtc_read(OMAP_RTC_SECONDS_REG);
-	tm->tm_min = rtc_read(OMAP_RTC_MINUTES_REG);
-	tm->tm_hour = rtc_read(OMAP_RTC_HOURS_REG);
-	tm->tm_mday = rtc_read(OMAP_RTC_DAYS_REG);
-	tm->tm_mon = rtc_read(OMAP_RTC_MONTHS_REG);
-	tm->tm_year = rtc_read(OMAP_RTC_YEARS_REG);
+	tm->tm_sec = rtc_read(rtc, OMAP_RTC_SECONDS_REG);
+	tm->tm_min = rtc_read(rtc, OMAP_RTC_MINUTES_REG);
+	tm->tm_hour = rtc_read(rtc, OMAP_RTC_HOURS_REG);
+	tm->tm_mday = rtc_read(rtc, OMAP_RTC_DAYS_REG);
+	tm->tm_mon = rtc_read(rtc, OMAP_RTC_MONTHS_REG);
+	tm->tm_year = rtc_read(rtc, OMAP_RTC_YEARS_REG);
 
 	local_irq_enable();
 
@@ -250,17 +267,19 @@ static int omap_rtc_read_time(struct device *dev, struct rtc_time *tm)
 
 static int omap_rtc_set_time(struct device *dev, struct rtc_time *tm)
 {
+	struct omap_rtc *rtc = dev_get_drvdata(dev);
+
 	if (tm2bcd(tm) < 0)
 		return -EINVAL;
 	local_irq_disable();
-	rtc_wait_not_busy();
+	rtc_wait_not_busy(rtc);
 
-	rtc_write(tm->tm_year, OMAP_RTC_YEARS_REG);
-	rtc_write(tm->tm_mon, OMAP_RTC_MONTHS_REG);
-	rtc_write(tm->tm_mday, OMAP_RTC_DAYS_REG);
-	rtc_write(tm->tm_hour, OMAP_RTC_HOURS_REG);
-	rtc_write(tm->tm_min, OMAP_RTC_MINUTES_REG);
-	rtc_write(tm->tm_sec, OMAP_RTC_SECONDS_REG);
+	rtc_write(rtc, OMAP_RTC_YEARS_REG, tm->tm_year);
+	rtc_write(rtc, OMAP_RTC_MONTHS_REG, tm->tm_mon);
+	rtc_write(rtc, OMAP_RTC_DAYS_REG, tm->tm_mday);
+	rtc_write(rtc, OMAP_RTC_HOURS_REG, tm->tm_hour);
+	rtc_write(rtc, OMAP_RTC_MINUTES_REG, tm->tm_min);
+	rtc_write(rtc, OMAP_RTC_SECONDS_REG, tm->tm_sec);
 
 	local_irq_enable();
 
@@ -269,20 +288,22 @@ static int omap_rtc_set_time(struct device *dev, struct rtc_time *tm)
 
 static int omap_rtc_read_alarm(struct device *dev, struct rtc_wkalrm *alm)
 {
+	struct omap_rtc *rtc = dev_get_drvdata(dev);
+
 	local_irq_disable();
-	rtc_wait_not_busy();
+	rtc_wait_not_busy(rtc);
 
-	alm->time.tm_sec = rtc_read(OMAP_RTC_ALARM_SECONDS_REG);
-	alm->time.tm_min = rtc_read(OMAP_RTC_ALARM_MINUTES_REG);
-	alm->time.tm_hour = rtc_read(OMAP_RTC_ALARM_HOURS_REG);
-	alm->time.tm_mday = rtc_read(OMAP_RTC_ALARM_DAYS_REG);
-	alm->time.tm_mon = rtc_read(OMAP_RTC_ALARM_MONTHS_REG);
-	alm->time.tm_year = rtc_read(OMAP_RTC_ALARM_YEARS_REG);
+	alm->time.tm_sec = rtc_read(rtc, OMAP_RTC_ALARM_SECONDS_REG);
+	alm->time.tm_min = rtc_read(rtc, OMAP_RTC_ALARM_MINUTES_REG);
+	alm->time.tm_hour = rtc_read(rtc, OMAP_RTC_ALARM_HOURS_REG);
+	alm->time.tm_mday = rtc_read(rtc, OMAP_RTC_ALARM_DAYS_REG);
+	alm->time.tm_mon = rtc_read(rtc, OMAP_RTC_ALARM_MONTHS_REG);
+	alm->time.tm_year = rtc_read(rtc, OMAP_RTC_ALARM_YEARS_REG);
 
 	local_irq_enable();
 
 	bcd2tm(&alm->time);
-	alm->enabled = !!(rtc_read(OMAP_RTC_INTERRUPTS_REG)
+	alm->enabled = !!(rtc_read(rtc, OMAP_RTC_INTERRUPTS_REG)
 			& OMAP_RTC_INTERRUPTS_IT_ALARM);
 
 	return 0;
@@ -290,27 +311,25 @@ static int omap_rtc_read_alarm(struct device *dev, struct rtc_wkalrm *alm)
 
 static int omap_rtc_set_alarm(struct device *dev, struct rtc_wkalrm *alm)
 {
+	struct omap_rtc *rtc = dev_get_drvdata(dev);
 	u8 reg, irqwake_reg = 0;
-	struct platform_device *pdev = to_platform_device(dev);
-	const struct platform_device_id *id_entry =
-					platform_get_device_id(pdev);
 
 	if (tm2bcd(&alm->time) < 0)
 		return -EINVAL;
 
 	local_irq_disable();
-	rtc_wait_not_busy();
+	rtc_wait_not_busy(rtc);
 
-	rtc_write(alm->time.tm_year, OMAP_RTC_ALARM_YEARS_REG);
-	rtc_write(alm->time.tm_mon, OMAP_RTC_ALARM_MONTHS_REG);
-	rtc_write(alm->time.tm_mday, OMAP_RTC_ALARM_DAYS_REG);
-	rtc_write(alm->time.tm_hour, OMAP_RTC_ALARM_HOURS_REG);
-	rtc_write(alm->time.tm_min, OMAP_RTC_ALARM_MINUTES_REG);
-	rtc_write(alm->time.tm_sec, OMAP_RTC_ALARM_SECONDS_REG);
+	rtc_write(rtc, OMAP_RTC_ALARM_YEARS_REG, alm->time.tm_year);
+	rtc_write(rtc, OMAP_RTC_ALARM_MONTHS_REG, alm->time.tm_mon);
+	rtc_write(rtc, OMAP_RTC_ALARM_DAYS_REG, alm->time.tm_mday);
+	rtc_write(rtc, OMAP_RTC_ALARM_HOURS_REG, alm->time.tm_hour);
+	rtc_write(rtc, OMAP_RTC_ALARM_MINUTES_REG, alm->time.tm_min);
+	rtc_write(rtc, OMAP_RTC_ALARM_SECONDS_REG, alm->time.tm_sec);
 
-	reg = rtc_read(OMAP_RTC_INTERRUPTS_REG);
-	if (id_entry->driver_data & OMAP_RTC_HAS_IRQWAKEEN)
-		irqwake_reg = rtc_read(OMAP_RTC_IRQWAKEEN);
+	reg = rtc_read(rtc, OMAP_RTC_INTERRUPTS_REG);
+	if (rtc->flags & OMAP_RTC_HAS_IRQWAKEEN)
+		irqwake_reg = rtc_read(rtc, OMAP_RTC_IRQWAKEEN);
 
 	if (alm->enabled) {
 		reg |= OMAP_RTC_INTERRUPTS_IT_ALARM;
@@ -319,9 +338,9 @@ static int omap_rtc_set_alarm(struct device *dev, struct rtc_wkalrm *alm)
 		reg &= ~OMAP_RTC_INTERRUPTS_IT_ALARM;
 		irqwake_reg &= ~OMAP_RTC_IRQWAKEEN_ALARM_WAKEEN;
 	}
-	rtc_write(reg, OMAP_RTC_INTERRUPTS_REG);
-	if (id_entry->driver_data & OMAP_RTC_HAS_IRQWAKEEN)
-		rtc_write(irqwake_reg, OMAP_RTC_IRQWAKEEN);
+	rtc_write(rtc, OMAP_RTC_INTERRUPTS_REG, reg);
+	if (rtc->flags & OMAP_RTC_HAS_IRQWAKEEN)
+		rtc_write(rtc, OMAP_RTC_IRQWAKEEN, irqwake_reg);
 
 	local_irq_enable();
 
@@ -336,9 +355,6 @@ static struct rtc_class_ops omap_rtc_ops = {
 	.alarm_irq_enable = omap_rtc_alarm_irq_enable,
 };
 
-static int omap_rtc_alarm;
-static int omap_rtc_timer;
-
 #define	OMAP_RTC_DATA_AM3352_IDX	1
 #define	OMAP_RTC_DATA_DA830_IDX		2
 
@@ -372,13 +388,17 @@ MODULE_DEVICE_TABLE(of, omap_rtc_of_match);
 
 static int __init omap_rtc_probe(struct platform_device *pdev)
 {
+	struct omap_rtc		*rtc;
 	struct resource		*res;
-	struct rtc_device	*rtc;
 	u8			reg, new_ctrl;
 	const struct platform_device_id *id_entry;
 	const struct of_device_id *of_id;
 	int ret;
 
+	rtc = devm_kzalloc(&pdev->dev, sizeof(*rtc), GFP_KERNEL);
+	if (!rtc)
+		return -ENOMEM;
+
 	of_id = of_match_device(omap_rtc_of_match, &pdev->dev);
 	if (of_id)
 		pdev->id_entry = of_id->data;
@@ -389,26 +409,30 @@ static int __init omap_rtc_probe(struct platform_device *pdev)
 		return -ENODEV;
 	}
 
-	omap_rtc_timer = platform_get_irq(pdev, 0);
-	if (omap_rtc_timer <= 0)
+	rtc->flags = id_entry->driver_data;
+
+	rtc->irq_timer = platform_get_irq(pdev, 0);
+	if (rtc->irq_timer <= 0)
 		return -ENOENT;
 
-	omap_rtc_alarm = platform_get_irq(pdev, 1);
-	if (omap_rtc_alarm <= 0)
+	rtc->irq_alarm = platform_get_irq(pdev, 1);
+	if (rtc->irq_alarm <= 0)
 		return -ENOENT;
 
 	res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
-	rtc_base = devm_ioremap_resource(&pdev->dev, res);
-	if (IS_ERR(rtc_base))
-		return PTR_ERR(rtc_base);
+	rtc->base = devm_ioremap_resource(&pdev->dev, res);
+	if (IS_ERR(rtc->base))
+		return PTR_ERR(rtc->base);
+
+	platform_set_drvdata(pdev, rtc);
 
 	/* Enable the clock/module so that we can access the registers */
 	pm_runtime_enable(&pdev->dev);
 	pm_runtime_get_sync(&pdev->dev);
 
-	if (id_entry->driver_data & OMAP_RTC_HAS_KICKER) {
-		rtc_writel(KICK0_VALUE, OMAP_RTC_KICK0_REG);
-		rtc_writel(KICK1_VALUE, OMAP_RTC_KICK1_REG);
+	if (rtc->flags & OMAP_RTC_HAS_KICKER) {
+		rtc_writel(rtc, OMAP_RTC_KICK0_REG, KICK0_VALUE);
+		rtc_writel(rtc, OMAP_RTC_KICK1_REG, KICK1_VALUE);
 	}
 
 	/*
@@ -416,25 +440,26 @@ static int __init omap_rtc_probe(struct platform_device *pdev)
 	 *
 	 * NOTE: ALARM2 is not cleared on AM3352 if rtc_write (writeb) is used
 	 */
-	rtc_writel(0, OMAP_RTC_INTERRUPTS_REG);
+	rtc_writel(rtc, OMAP_RTC_INTERRUPTS_REG, 0);
 
 	/* enable RTC functional clock */
-	if (id_entry->driver_data & OMAP_RTC_HAS_32KCLK_EN) {
-		reg = rtc_read(OMAP_RTC_OSC_REG);
-		rtc_writel(reg | OMAP_RTC_OSC_32KCLK_EN, OMAP_RTC_OSC_REG);
+	if (rtc->flags & OMAP_RTC_HAS_32KCLK_EN) {
+		reg = rtc_read(rtc, OMAP_RTC_OSC_REG);
+		rtc_writel(rtc, OMAP_RTC_OSC_REG,
+				reg | OMAP_RTC_OSC_32KCLK_EN);
 	}
 
 	/* clear old status */
-	reg = rtc_read(OMAP_RTC_STATUS_REG);
+	reg = rtc_read(rtc, OMAP_RTC_STATUS_REG);
 	if (reg & (u8) OMAP_RTC_STATUS_POWER_UP) {
 		dev_info(&pdev->dev, "RTC power up reset detected\n");
-		rtc_write(OMAP_RTC_STATUS_POWER_UP, OMAP_RTC_STATUS_REG);
+		rtc_write(rtc, OMAP_RTC_STATUS_REG, OMAP_RTC_STATUS_POWER_UP);
 	}
 	if (reg & (u8) OMAP_RTC_STATUS_ALARM)
-		rtc_write(OMAP_RTC_STATUS_ALARM, OMAP_RTC_STATUS_REG);
+		rtc_write(rtc, OMAP_RTC_STATUS_REG, OMAP_RTC_STATUS_ALARM);
 
 	/* On boards with split power, RTC_ON_NOFF won't reset the RTC */
-	reg = rtc_read(OMAP_RTC_CTRL_REG);
+	reg = rtc_read(rtc, OMAP_RTC_CTRL_REG);
 	if (reg & (u8) OMAP_RTC_CTRL_STOP)
 		dev_info(&pdev->dev, "already running\n");
 
@@ -460,27 +485,26 @@ static int __init omap_rtc_probe(struct platform_device *pdev)
 		dev_info(&pdev->dev, "split power mode\n");
 
 	if (reg != new_ctrl)
-		rtc_write(new_ctrl, OMAP_RTC_CTRL_REG);
+		rtc_write(rtc, OMAP_RTC_CTRL_REG, new_ctrl);
 
 	device_init_wakeup(&pdev->dev, true);
 
-	rtc = devm_rtc_device_register(&pdev->dev, pdev->name,
+	rtc->rtc = devm_rtc_device_register(&pdev->dev, pdev->name,
 			&omap_rtc_ops, THIS_MODULE);
-	if (IS_ERR(rtc)) {
-		ret = PTR_ERR(rtc);
+	if (IS_ERR(rtc->rtc)) {
+		ret = PTR_ERR(rtc->rtc);
 		goto err;
 	}
-	platform_set_drvdata(pdev, rtc);
 
 	/* handle periodic and alarm irqs */
-	ret = devm_request_irq(&pdev->dev, omap_rtc_timer, rtc_irq, 0,
-			dev_name(&rtc->dev), rtc);
+	ret = devm_request_irq(&pdev->dev, rtc->irq_timer, rtc_irq, 0,
+			dev_name(&rtc->rtc->dev), rtc);
 	if (ret)
 		goto err;
 
-	if (omap_rtc_timer != omap_rtc_alarm) {
-		ret = devm_request_irq(&pdev->dev, omap_rtc_alarm, rtc_irq, 0,
-				dev_name(&rtc->dev), rtc);
+	if (rtc->irq_timer != rtc->irq_alarm) {
+		ret = devm_request_irq(&pdev->dev, rtc->irq_alarm, rtc_irq, 0,
+				dev_name(&rtc->rtc->dev), rtc);
 		if (ret)
 			goto err;
 	}
@@ -489,8 +513,8 @@ static int __init omap_rtc_probe(struct platform_device *pdev)
 
 err:
 	device_init_wakeup(&pdev->dev, false);
-	if (id_entry->driver_data & OMAP_RTC_HAS_KICKER)
-		rtc_writel(0, OMAP_RTC_KICK0_REG);
+	if (rtc->flags & OMAP_RTC_HAS_KICKER)
+		rtc_writel(rtc, OMAP_RTC_KICK0_REG, 0);
 	pm_runtime_put_sync(&pdev->dev);
 	pm_runtime_disable(&pdev->dev);
 
@@ -499,16 +523,15 @@ err:
 
 static int __exit omap_rtc_remove(struct platform_device *pdev)
 {
-	const struct platform_device_id *id_entry =
-				platform_get_device_id(pdev);
+	struct omap_rtc *rtc = platform_get_drvdata(pdev);
 
 	device_init_wakeup(&pdev->dev, 0);
 
 	/* leave rtc running, but disable irqs */
-	rtc_write(0, OMAP_RTC_INTERRUPTS_REG);
+	rtc_write(rtc, OMAP_RTC_INTERRUPTS_REG, 0);
 
-	if (id_entry->driver_data & OMAP_RTC_HAS_KICKER)
-		rtc_writel(0, OMAP_RTC_KICK0_REG);
+	if (rtc->flags & OMAP_RTC_HAS_KICKER)
+		rtc_writel(rtc, OMAP_RTC_KICK0_REG, 0);
 
 	/* Disable the clock/module */
 	pm_runtime_put_sync(&pdev->dev);
@@ -518,20 +541,20 @@ static int __exit omap_rtc_remove(struct platform_device *pdev)
 }
 
 #ifdef CONFIG_PM_SLEEP
-static u8 irqstat;
-
 static int omap_rtc_suspend(struct device *dev)
 {
-	irqstat = rtc_read(OMAP_RTC_INTERRUPTS_REG);
+	struct omap_rtc *rtc = dev_get_drvdata(dev);
+
+	rtc->interrupts_reg = rtc_read(rtc, OMAP_RTC_INTERRUPTS_REG);
 
 	/* FIXME the RTC alarm is not currently acting as a wakeup event
 	 * source on some platforms, and in fact this enable() call is just
 	 * saving a flag that's never used...
 	 */
 	if (device_may_wakeup(dev))
-		enable_irq_wake(omap_rtc_alarm);
+		enable_irq_wake(rtc->irq_alarm);
 	else
-		rtc_write(0, OMAP_RTC_INTERRUPTS_REG);
+		rtc_write(rtc, OMAP_RTC_INTERRUPTS_REG, 0);
 
 	/* Disable the clock/module */
 	pm_runtime_put_sync(dev);
@@ -541,13 +564,15 @@ static int omap_rtc_suspend(struct device *dev)
 
 static int omap_rtc_resume(struct device *dev)
 {
+	struct omap_rtc *rtc = dev_get_drvdata(dev);
+
 	/* Enable the clock/module so that we can access the registers */
 	pm_runtime_get_sync(dev);
 
 	if (device_may_wakeup(dev))
-		disable_irq_wake(omap_rtc_alarm);
+		disable_irq_wake(rtc->irq_alarm);
 	else
-		rtc_write(irqstat, OMAP_RTC_INTERRUPTS_REG);
+		rtc_write(rtc, OMAP_RTC_INTERRUPTS_REG, rtc->interrupts_reg);
 
 	return 0;
 }
@@ -557,7 +582,9 @@ static SIMPLE_DEV_PM_OPS(omap_rtc_pm_ops, omap_rtc_suspend, omap_rtc_resume);
 
 static void omap_rtc_shutdown(struct platform_device *pdev)
 {
-	rtc_write(0, OMAP_RTC_INTERRUPTS_REG);
+	struct omap_rtc *rtc = platform_get_drvdata(pdev);
+
+	rtc_write(rtc, OMAP_RTC_INTERRUPTS_REG, 0);
 }
 
 MODULE_ALIAS("platform:omap_rtc");
-- 
2.0.4

[PATCH v2 10/20] rtc: omap: remove DRIVER_NAME macro

[Johan Hovold]

Remove DRIVER_NAME macro which was used for unrelated strings (e.g.
id-table entry and module name), but not for related ones (e.g. module
name and alias).

Also move the module alias to the other module-info entries.

Signed-off-by: Johan Hovold <johan@kernel.org>
---
 drivers/rtc/rtc-omap.c | 8 +++-----
 1 file changed, 3 insertions(+), 5 deletions(-)

diff --git a/drivers/rtc/rtc-omap.c b/drivers/rtc/rtc-omap.c
index 1da610b8981f..f70ae660368b 100644
--- a/drivers/rtc/rtc-omap.c
+++ b/drivers/rtc/rtc-omap.c
@@ -39,8 +39,6 @@
  * the SoC). See the BOARD-SPECIFIC CUSTOMIZATION comment.
  */
 
-#define	DRIVER_NAME			"omap_rtc"
-
 /* RTC registers */
 #define OMAP_RTC_SECONDS_REG		0x00
 #define OMAP_RTC_MINUTES_REG		0x04
@@ -360,7 +358,7 @@ static struct rtc_class_ops omap_rtc_ops = {
 
 static const struct platform_device_id omap_rtc_devtype[] = {
 	{
-		.name	= DRIVER_NAME,
+		.name	= "omap_rtc",
 	},
 	[OMAP_RTC_DATA_AM3352_IDX] = {
 		.name	= "am3352-rtc",
@@ -587,12 +585,11 @@ static void omap_rtc_shutdown(struct platform_device *pdev)
 	rtc_write(rtc, OMAP_RTC_INTERRUPTS_REG, 0);
 }
 
-MODULE_ALIAS("platform:omap_rtc");
 static struct platform_driver omap_rtc_driver = {
 	.remove		= __exit_p(omap_rtc_remove),
 	.shutdown	= omap_rtc_shutdown,
 	.driver		= {
-		.name	= DRIVER_NAME,
+		.name	= "omap_rtc",
 		.owner	= THIS_MODULE,
 		.pm	= &omap_rtc_pm_ops,
 		.of_match_table = omap_rtc_of_match,
@@ -602,5 +599,6 @@ static struct platform_driver omap_rtc_driver = {
 
 module_platform_driver_probe(omap_rtc_driver, omap_rtc_probe);
 
+MODULE_ALIAS("platform:omap_rtc");
 MODULE_AUTHOR("George G. Davis (and others)");
 MODULE_LICENSE("GPL");
-- 
2.0.4

[PATCH v2 11/20] rtc: omap: add structured device-type info

[Johan Hovold]

Add structured device-type info to encode IP-block revision differences.

Signed-off-by: Johan Hovold <johan@kernel.org>
---
 drivers/rtc/rtc-omap.c | 103 ++++++++++++++++++++++++-------------------------
 1 file changed, 51 insertions(+), 52 deletions(-)

diff --git a/drivers/rtc/rtc-omap.c b/drivers/rtc/rtc-omap.c
index f70ae660368b..1abd88e24c22 100644
--- a/drivers/rtc/rtc-omap.c
+++ b/drivers/rtc/rtc-omap.c
@@ -102,19 +102,11 @@
 #define	KICK0_VALUE			0x83e70b13
 #define	KICK1_VALUE			0x95a4f1e0
 
-#define	OMAP_RTC_HAS_KICKER		BIT(0)
-
-/*
- * Few RTC IP revisions has special WAKE-EN Register to enable Wakeup
- * generation for event Alarm.
- */
-#define	OMAP_RTC_HAS_IRQWAKEEN		BIT(1)
-
-/*
- * Some RTC IP revisions (like those in AM335x and DRA7x) need
- * the 32KHz clock to be explicitly enabled.
- */
-#define OMAP_RTC_HAS_32KCLK_EN		BIT(2)
+struct omap_rtc_device_type {
+	bool has_32kclk_en;
+	bool has_kicker;
+	bool has_irqwakeen;
+};
 
 struct omap_rtc {
 	struct rtc_device *rtc;
@@ -122,7 +114,7 @@ struct omap_rtc {
 	int irq_alarm;
 	int irq_timer;
 	u8 interrupts_reg;
-	unsigned long flags;
+	const struct omap_rtc_device_type *type;
 };
 
 static inline u8 rtc_read(struct omap_rtc *rtc, unsigned int reg)
@@ -190,7 +182,7 @@ static int omap_rtc_alarm_irq_enable(struct device *dev, unsigned int enabled)
 	local_irq_disable();
 	rtc_wait_not_busy(rtc);
 	reg = rtc_read(rtc, OMAP_RTC_INTERRUPTS_REG);
-	if (rtc->flags & OMAP_RTC_HAS_IRQWAKEEN)
+	if (rtc->type->has_irqwakeen)
 		irqwake_reg = rtc_read(rtc, OMAP_RTC_IRQWAKEEN);
 
 	if (enabled) {
@@ -202,7 +194,7 @@ static int omap_rtc_alarm_irq_enable(struct device *dev, unsigned int enabled)
 	}
 	rtc_wait_not_busy(rtc);
 	rtc_write(rtc, OMAP_RTC_INTERRUPTS_REG, reg);
-	if (rtc->flags & OMAP_RTC_HAS_IRQWAKEEN)
+	if (rtc->type->has_irqwakeen)
 		rtc_write(rtc, OMAP_RTC_IRQWAKEEN, irqwake_reg);
 	local_irq_enable();
 
@@ -326,7 +318,7 @@ static int omap_rtc_set_alarm(struct device *dev, struct rtc_wkalrm *alm)
 	rtc_write(rtc, OMAP_RTC_ALARM_SECONDS_REG, alm->time.tm_sec);
 
 	reg = rtc_read(rtc, OMAP_RTC_INTERRUPTS_REG);
-	if (rtc->flags & OMAP_RTC_HAS_IRQWAKEEN)
+	if (rtc->type->has_irqwakeen)
 		irqwake_reg = rtc_read(rtc, OMAP_RTC_IRQWAKEEN);
 
 	if (alm->enabled) {
@@ -337,7 +329,7 @@ static int omap_rtc_set_alarm(struct device *dev, struct rtc_wkalrm *alm)
 		irqwake_reg &= ~OMAP_RTC_IRQWAKEEN_ALARM_WAKEEN;
 	}
 	rtc_write(rtc, OMAP_RTC_INTERRUPTS_REG, reg);
-	if (rtc->flags & OMAP_RTC_HAS_IRQWAKEEN)
+	if (rtc->type->has_irqwakeen)
 		rtc_write(rtc, OMAP_RTC_IRQWAKEEN, irqwake_reg);
 
 	local_irq_enable();
@@ -353,34 +345,45 @@ static struct rtc_class_ops omap_rtc_ops = {
 	.alarm_irq_enable = omap_rtc_alarm_irq_enable,
 };
 
-#define	OMAP_RTC_DATA_AM3352_IDX	1
-#define	OMAP_RTC_DATA_DA830_IDX		2
+static const struct omap_rtc_device_type omap_rtc_default_type = {
+};
+
+static const struct omap_rtc_device_type omap_rtc_am3352_type = {
+	.has_32kclk_en	= true,
+	.has_kicker	= true,
+	.has_irqwakeen	= true,
+};
+
+static const struct omap_rtc_device_type omap_rtc_da830_type = {
+	.has_kicker	= true,
+};
 
-static const struct platform_device_id omap_rtc_devtype[] = {
+static const struct platform_device_id omap_rtc_id_table[] = {
 	{
 		.name	= "omap_rtc",
-	},
-	[OMAP_RTC_DATA_AM3352_IDX] = {
+		.driver_data = (kernel_ulong_t)&omap_rtc_default_type,
+	}, {
 		.name	= "am3352-rtc",
-		.driver_data = OMAP_RTC_HAS_KICKER | OMAP_RTC_HAS_IRQWAKEEN |
-			       OMAP_RTC_HAS_32KCLK_EN,
-	},
-	[OMAP_RTC_DATA_DA830_IDX] = {
+		.driver_data = (kernel_ulong_t)&omap_rtc_am3352_type,
+	}, {
 		.name	= "da830-rtc",
-		.driver_data = OMAP_RTC_HAS_KICKER,
-	},
-	{},
+		.driver_data = (kernel_ulong_t)&omap_rtc_da830_type,
+	}, {
+		/* sentinel */
+	}
 };
-MODULE_DEVICE_TABLE(platform, omap_rtc_devtype);
+MODULE_DEVICE_TABLE(platform, omap_rtc_id_table);
 
 static const struct of_device_id omap_rtc_of_match[] = {
-	{	.compatible	= "ti,da830-rtc",
-		.data		= &omap_rtc_devtype[OMAP_RTC_DATA_DA830_IDX],
-	},
-	{	.compatible	= "ti,am3352-rtc",
-		.data		= &omap_rtc_devtype[OMAP_RTC_DATA_AM3352_IDX],
-	},
-	{},
+	{
+		.compatible	= "ti,am3352-rtc",
+		.data		= &omap_rtc_am3352_type,
+	}, {
+		.compatible	= "ti,da830-rtc",
+		.data		= &omap_rtc_da830_type,
+	}, {
+		/* sentinel */
+	}
 };
 MODULE_DEVICE_TABLE(of, omap_rtc_of_match);
 
@@ -398,17 +401,13 @@ static int __init omap_rtc_probe(struct platform_device *pdev)
 		return -ENOMEM;
 
 	of_id = of_match_device(omap_rtc_of_match, &pdev->dev);
-	if (of_id)
-		pdev->id_entry = of_id->data;
-
-	id_entry = platform_get_device_id(pdev);
-	if (!id_entry) {
-		dev_err(&pdev->dev, "no matching device entry\n");
-		return -ENODEV;
+	if (of_id) {
+		rtc->type = of_id->data;
+	} else {
+		id_entry = platform_get_device_id(pdev);
+		rtc->type = (void *)id_entry->driver_data;
 	}
 
-	rtc->flags = id_entry->driver_data;
-
 	rtc->irq_timer = platform_get_irq(pdev, 0);
 	if (rtc->irq_timer <= 0)
 		return -ENOENT;
@@ -428,7 +427,7 @@ static int __init omap_rtc_probe(struct platform_device *pdev)
 	pm_runtime_enable(&pdev->dev);
 	pm_runtime_get_sync(&pdev->dev);
 
-	if (rtc->flags & OMAP_RTC_HAS_KICKER) {
+	if (rtc->type->has_kicker) {
 		rtc_writel(rtc, OMAP_RTC_KICK0_REG, KICK0_VALUE);
 		rtc_writel(rtc, OMAP_RTC_KICK1_REG, KICK1_VALUE);
 	}
@@ -441,7 +440,7 @@ static int __init omap_rtc_probe(struct platform_device *pdev)
 	rtc_writel(rtc, OMAP_RTC_INTERRUPTS_REG, 0);
 
 	/* enable RTC functional clock */
-	if (rtc->flags & OMAP_RTC_HAS_32KCLK_EN) {
+	if (rtc->type->has_32kclk_en) {
 		reg = rtc_read(rtc, OMAP_RTC_OSC_REG);
 		rtc_writel(rtc, OMAP_RTC_OSC_REG,
 				reg | OMAP_RTC_OSC_32KCLK_EN);
@@ -511,7 +510,7 @@ static int __init omap_rtc_probe(struct platform_device *pdev)
 
 err:
 	device_init_wakeup(&pdev->dev, false);
-	if (rtc->flags & OMAP_RTC_HAS_KICKER)
+	if (rtc->type->has_kicker)
 		rtc_writel(rtc, OMAP_RTC_KICK0_REG, 0);
 	pm_runtime_put_sync(&pdev->dev);
 	pm_runtime_disable(&pdev->dev);
@@ -528,7 +527,7 @@ static int __exit omap_rtc_remove(struct platform_device *pdev)
 	/* leave rtc running, but disable irqs */
 	rtc_write(rtc, OMAP_RTC_INTERRUPTS_REG, 0);
 
-	if (rtc->flags & OMAP_RTC_HAS_KICKER)
+	if (rtc->type->has_kicker)
 		rtc_writel(rtc, OMAP_RTC_KICK0_REG, 0);
 
 	/* Disable the clock/module */
@@ -594,7 +593,7 @@ static struct platform_driver omap_rtc_driver = {
 		.pm	= &omap_rtc_pm_ops,
 		.of_match_table = omap_rtc_of_match,
 	},
-	.id_table	= omap_rtc_devtype,
+	.id_table	= omap_rtc_id_table,
 };
 
 module_platform_driver_probe(omap_rtc_driver, omap_rtc_probe);
-- 
2.0.4

[PATCH v2 12/20] rtc: omap: silence bogus power-up reset message at probe

[Johan Hovold]

Some legacy RTC IP revisions has a power-up reset flag in the status
register that later revisions lack.

As this flag is always read back as set on later revisions (or is
overloaded with a different flag), make sure to only clear the flag and
print the info message on legacy platforms.

Signed-off-by: Johan Hovold <johan@kernel.org>
---
 drivers/rtc/rtc-omap.c | 19 +++++++++++++------
 1 file changed, 13 insertions(+), 6 deletions(-)

diff --git a/drivers/rtc/rtc-omap.c b/drivers/rtc/rtc-omap.c
index 1abd88e24c22..ee20f2d36065 100644
--- a/drivers/rtc/rtc-omap.c
+++ b/drivers/rtc/rtc-omap.c
@@ -106,6 +106,7 @@ struct omap_rtc_device_type {
 	bool has_32kclk_en;
 	bool has_kicker;
 	bool has_irqwakeen;
+	bool has_power_up_reset;
 };
 
 struct omap_rtc {
@@ -346,6 +347,7 @@ static struct rtc_class_ops omap_rtc_ops = {
 };
 
 static const struct omap_rtc_device_type omap_rtc_default_type = {
+	.has_power_up_reset = true,
 };
 
 static const struct omap_rtc_device_type omap_rtc_am3352_type = {
@@ -391,7 +393,7 @@ static int __init omap_rtc_probe(struct platform_device *pdev)
 {
 	struct omap_rtc		*rtc;
 	struct resource		*res;
-	u8			reg, new_ctrl;
+	u8			reg, mask, new_ctrl;
 	const struct platform_device_id *id_entry;
 	const struct of_device_id *of_id;
 	int ret;
@@ -448,12 +450,17 @@ static int __init omap_rtc_probe(struct platform_device *pdev)
 
 	/* clear old status */
 	reg = rtc_read(rtc, OMAP_RTC_STATUS_REG);
-	if (reg & (u8) OMAP_RTC_STATUS_POWER_UP) {
-		dev_info(&pdev->dev, "RTC power up reset detected\n");
-		rtc_write(rtc, OMAP_RTC_STATUS_REG, OMAP_RTC_STATUS_POWER_UP);
+
+	mask = OMAP_RTC_STATUS_ALARM;
+
+	if (rtc->type->has_power_up_reset) {
+		mask |= OMAP_RTC_STATUS_POWER_UP;
+		if (reg & OMAP_RTC_STATUS_POWER_UP)
+			dev_info(&pdev->dev, "RTC power up reset detected\n");
 	}
-	if (reg & (u8) OMAP_RTC_STATUS_ALARM)
-		rtc_write(rtc, OMAP_RTC_STATUS_REG, OMAP_RTC_STATUS_ALARM);
+
+	if (reg & mask)
+		rtc_write(rtc, OMAP_RTC_STATUS_REG, reg & mask);
 
 	/* On boards with split power, RTC_ON_NOFF won't reset the RTC */
 	reg = rtc_read(rtc, OMAP_RTC_CTRL_REG);
-- 
2.0.4

[PATCH v2 13/20] rtc: omap: add helper to read raw bcd time

[Johan Hovold]

Add helper to read raw BCD time that can be used in interrupt context.

Signed-off-by: Johan Hovold <johan@kernel.org>
---
 drivers/rtc/rtc-omap.c | 18 ++++++++++--------
 1 file changed, 10 insertions(+), 8 deletions(-)

diff --git a/drivers/rtc/rtc-omap.c b/drivers/rtc/rtc-omap.c
index ee20f2d36065..bcdf3c596214 100644
--- a/drivers/rtc/rtc-omap.c
+++ b/drivers/rtc/rtc-omap.c
@@ -234,22 +234,24 @@ static void bcd2tm(struct rtc_time *tm)
 	tm->tm_year = bcd2bin(tm->tm_year) + 100;
 }
 
-
-static int omap_rtc_read_time(struct device *dev, struct rtc_time *tm)
+static void omap_rtc_read_time_raw(struct omap_rtc *rtc, struct rtc_time *tm)
 {
-	struct omap_rtc *rtc = dev_get_drvdata(dev);
-
-	/* we don't report wday/yday/isdst ... */
-	local_irq_disable();
-	rtc_wait_not_busy(rtc);
-
 	tm->tm_sec = rtc_read(rtc, OMAP_RTC_SECONDS_REG);
 	tm->tm_min = rtc_read(rtc, OMAP_RTC_MINUTES_REG);
 	tm->tm_hour = rtc_read(rtc, OMAP_RTC_HOURS_REG);
 	tm->tm_mday = rtc_read(rtc, OMAP_RTC_DAYS_REG);
 	tm->tm_mon = rtc_read(rtc, OMAP_RTC_MONTHS_REG);
 	tm->tm_year = rtc_read(rtc, OMAP_RTC_YEARS_REG);
+}
+
+static int omap_rtc_read_time(struct device *dev, struct rtc_time *tm)
+{
+	struct omap_rtc *rtc = dev_get_drvdata(dev);
 
+	/* we don't report wday/yday/isdst ... */
+	local_irq_disable();
+	rtc_wait_not_busy(rtc);
+	omap_rtc_read_time_raw(rtc, tm);
 	local_irq_enable();
 
 	bcd2tm(tm);
-- 
2.0.4

[PATCH v2 14/20] rtc: omap: add helper to read 32-bit registers

[Johan Hovold]

Add helper to read full register width.

Signed-off-by: Johan Hovold <johan@kernel.org>
---
 drivers/rtc/rtc-omap.c | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/drivers/rtc/rtc-omap.c b/drivers/rtc/rtc-omap.c
index bcdf3c596214..c508e45ca3ce 100644
--- a/drivers/rtc/rtc-omap.c
+++ b/drivers/rtc/rtc-omap.c
@@ -123,6 +123,11 @@ static inline u8 rtc_read(struct omap_rtc *rtc, unsigned int reg)
 	return readb(rtc->base + reg);
 }
 
+static inline u32 rtc_readl(struct omap_rtc *rtc, unsigned int reg)
+{
+	return readl(rtc->base + reg);
+}
+
 static inline void rtc_write(struct omap_rtc *rtc, unsigned int reg, u8 val)
 {
 	writeb(val, rtc->base + reg);
-- 
2.0.4

[PATCH v2 15/20] rtc: omap: add support for pmic_power_en

[Johan Hovold]

Add new property "ti,system-power-controller" to register the RTC as a
power-off handler.

Some RTC IP revisions can control an external PMIC via the pmic_power_en
pin, which can be configured to transition to OFF on ALARM2 events and
back to ON on subsequent ALARM (wakealarm) events.

This is based on earlier work by Colin Foe-Parker and AnilKumar Ch. [1]

[1] https://www.mail-archive.com/linux-omap@vger.kernel.org/msg82127.html

Signed-off-by: Johan Hovold <johan@kernel.org>
---
 Documentation/devicetree/bindings/rtc/rtc-omap.txt |  9 ++-
 drivers/rtc/rtc-omap.c                             | 93 ++++++++++++++++++++++
 2 files changed, 101 insertions(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/rtc/rtc-omap.txt b/Documentation/devicetree/bindings/rtc/rtc-omap.txt
index 5a0f02d34d95..750efd40c72e 100644
--- a/Documentation/devicetree/bindings/rtc/rtc-omap.txt
+++ b/Documentation/devicetree/bindings/rtc/rtc-omap.txt
@@ -5,11 +5,17 @@ Required properties:
 	- "ti,da830-rtc"  - for RTC IP used similar to that on DA8xx SoC family.
 	- "ti,am3352-rtc" - for RTC IP used similar to that on AM335x SoC family.
 			    This RTC IP has special WAKE-EN Register to enable
-			    Wakeup generation for event Alarm.
+			    Wakeup generation for event Alarm. It can also be
+			    used to control an external PMIC via the
+			    pmic_power_en pin.
 - reg: Address range of rtc register set
 - interrupts: rtc timer, alarm interrupts in order
 - interrupt-parent: phandle for the interrupt controller
 
+Optional properties:
+- ti,system-power-controller: whether the rtc is controlling the system power
+  through pmic_power_en
+
 Example:
 
 rtc@1c23000 {
@@ -18,4 +24,5 @@ rtc@1c23000 {
 	interrupts = <19
 		      19>;
 	interrupt-parent = <&intc>;
+	ti,system-power-controller;
 };
diff --git a/drivers/rtc/rtc-omap.c b/drivers/rtc/rtc-omap.c
index c508e45ca3ce..f6c93f877857 100644
--- a/drivers/rtc/rtc-omap.c
+++ b/drivers/rtc/rtc-omap.c
@@ -68,6 +68,15 @@
 
 #define OMAP_RTC_IRQWAKEEN		0x7c
 
+#define OMAP_RTC_ALARM2_SECONDS_REG	0x80
+#define OMAP_RTC_ALARM2_MINUTES_REG	0x84
+#define OMAP_RTC_ALARM2_HOURS_REG	0x88
+#define OMAP_RTC_ALARM2_DAYS_REG	0x8c
+#define OMAP_RTC_ALARM2_MONTHS_REG	0x90
+#define OMAP_RTC_ALARM2_YEARS_REG	0x94
+
+#define OMAP_RTC_PMIC_REG		0x98
+
 /* OMAP_RTC_CTRL_REG bit fields: */
 #define OMAP_RTC_CTRL_SPLIT		BIT(7)
 #define OMAP_RTC_CTRL_DISABLE		BIT(6)
@@ -80,6 +89,7 @@
 
 /* OMAP_RTC_STATUS_REG bit fields: */
 #define OMAP_RTC_STATUS_POWER_UP	BIT(7)
+#define OMAP_RTC_STATUS_ALARM2		BIT(7)
 #define OMAP_RTC_STATUS_ALARM		BIT(6)
 #define OMAP_RTC_STATUS_1D_EVENT	BIT(5)
 #define OMAP_RTC_STATUS_1H_EVENT	BIT(4)
@@ -89,6 +99,7 @@
 #define OMAP_RTC_STATUS_BUSY		BIT(0)
 
 /* OMAP_RTC_INTERRUPTS_REG bit fields: */
+#define OMAP_RTC_INTERRUPTS_IT_ALARM2	BIT(4)
 #define OMAP_RTC_INTERRUPTS_IT_ALARM	BIT(3)
 #define OMAP_RTC_INTERRUPTS_IT_TIMER	BIT(2)
 
@@ -98,6 +109,9 @@
 /* OMAP_RTC_IRQWAKEEN bit fields: */
 #define OMAP_RTC_IRQWAKEEN_ALARM_WAKEEN	BIT(1)
 
+/* OMAP_RTC_PMIC bit fields: */
+#define OMAP_RTC_PMIC_POWER_EN_EN	BIT(16)
+
 /* OMAP_RTC_KICKER values */
 #define	KICK0_VALUE			0x83e70b13
 #define	KICK1_VALUE			0x95a4f1e0
@@ -106,6 +120,7 @@ struct omap_rtc_device_type {
 	bool has_32kclk_en;
 	bool has_kicker;
 	bool has_irqwakeen;
+	bool has_pmic_mode;
 	bool has_power_up_reset;
 };
 
@@ -115,6 +130,7 @@ struct omap_rtc {
 	int irq_alarm;
 	int irq_timer;
 	u8 interrupts_reg;
+	bool is_pmic_controller;
 	const struct omap_rtc_device_type *type;
 };
 
@@ -345,6 +361,63 @@ static int omap_rtc_set_alarm(struct device *dev, struct rtc_wkalrm *alm)
 	return 0;
 }
 
+static struct omap_rtc *omap_rtc_power_off_rtc;
+
+/*
+ * omap_rtc_poweroff: RTC-controlled power off
+ *
+ * The RTC can be used to control an external PMIC via the pmic_power_en pin,
+ * which can be configured to transition to OFF on ALARM2 events.
+ *
+ * Notes:
+ * The two-second alarm offset is the shortest offset possible as the alarm
+ * registers must be set before the next timer update and the offset
+ * calculation is too heavy for everything to be done within a single access
+ * period (~15us).
+ *
+ * Called with local interrupts disabled.
+ */
+static void omap_rtc_power_off(void)
+{
+	struct omap_rtc *rtc = omap_rtc_power_off_rtc;
+	struct rtc_time tm;
+	unsigned long now;
+	u32 val;
+
+	/* enable pmic_power_en control */
+	val = rtc_readl(rtc, OMAP_RTC_PMIC_REG);
+	rtc_writel(rtc, OMAP_RTC_PMIC_REG, val | OMAP_RTC_PMIC_POWER_EN_EN);
+
+	/* set alarm two seconds from now */
+	omap_rtc_read_time_raw(rtc, &tm);
+	bcd2tm(&tm);
+	rtc_tm_to_time(&tm, &now);
+	rtc_time_to_tm(now + 2, &tm);
+
+	if (tm2bcd(&tm) < 0) {
+		dev_err(&rtc->rtc->dev, "power off failed\n");
+		return;
+	}
+
+	rtc_wait_not_busy(rtc);
+
+	rtc_write(rtc, OMAP_RTC_ALARM2_SECONDS_REG, tm.tm_sec);
+	rtc_write(rtc, OMAP_RTC_ALARM2_MINUTES_REG, tm.tm_min);
+	rtc_write(rtc, OMAP_RTC_ALARM2_HOURS_REG, tm.tm_hour);
+	rtc_write(rtc, OMAP_RTC_ALARM2_DAYS_REG, tm.tm_mday);
+	rtc_write(rtc, OMAP_RTC_ALARM2_MONTHS_REG, tm.tm_mon);
+	rtc_write(rtc, OMAP_RTC_ALARM2_YEARS_REG, tm.tm_year);
+
+	/*
+	 * enable ALARM2 interrupt
+	 *
+	 * NOTE: this fails on AM3352 if rtc_write (writeb) is used
+	 */
+	val = rtc_read(rtc, OMAP_RTC_INTERRUPTS_REG);
+	rtc_writel(rtc, OMAP_RTC_INTERRUPTS_REG,
+			val | OMAP_RTC_INTERRUPTS_IT_ALARM2);
+}
+
 static struct rtc_class_ops omap_rtc_ops = {
 	.read_time	= omap_rtc_read_time,
 	.set_time	= omap_rtc_set_time,
@@ -361,6 +434,7 @@ static const struct omap_rtc_device_type omap_rtc_am3352_type = {
 	.has_32kclk_en	= true,
 	.has_kicker	= true,
 	.has_irqwakeen	= true,
+	.has_pmic_mode	= true,
 };
 
 static const struct omap_rtc_device_type omap_rtc_da830_type = {
@@ -412,6 +486,9 @@ static int __init omap_rtc_probe(struct platform_device *pdev)
 	of_id = of_match_device(omap_rtc_of_match, &pdev->dev);
 	if (of_id) {
 		rtc->type = of_id->data;
+		rtc->is_pmic_controller = rtc->type->has_pmic_mode &&
+				of_property_read_bool(pdev->dev.of_node,
+						"ti,system-power-controller");
 	} else {
 		id_entry = platform_get_device_id(pdev);
 		rtc->type = (void *)id_entry->driver_data;
@@ -460,6 +537,9 @@ static int __init omap_rtc_probe(struct platform_device *pdev)
 
 	mask = OMAP_RTC_STATUS_ALARM;
 
+	if (rtc->type->has_pmic_mode)
+		mask |= OMAP_RTC_STATUS_ALARM2;
+
 	if (rtc->type->has_power_up_reset) {
 		mask |= OMAP_RTC_STATUS_POWER_UP;
 		if (reg & OMAP_RTC_STATUS_POWER_UP)
@@ -520,6 +600,13 @@ static int __init omap_rtc_probe(struct platform_device *pdev)
 			goto err;
 	}
 
+	if (rtc->is_pmic_controller) {
+		if (!pm_power_off) {
+			omap_rtc_power_off_rtc = rtc;
+			pm_power_off = omap_rtc_power_off;
+		}
+	}
+
 	return 0;
 
 err:
@@ -536,6 +623,12 @@ static int __exit omap_rtc_remove(struct platform_device *pdev)
 {
 	struct omap_rtc *rtc = platform_get_drvdata(pdev);
 
+	if (pm_power_off == omap_rtc_power_off &&
+			omap_rtc_power_off_rtc == rtc) {
+		pm_power_off = NULL;
+		omap_rtc_power_off_rtc = NULL;
+	}
+
 	device_init_wakeup(&pdev->dev, 0);
 
 	/* leave rtc running, but disable irqs */
-- 
2.0.4

[PATCH v2 16/20] rtc: omap: enable wake-up from power off

[Johan Hovold]

The ALARM interrupt must not be disabled during shutdown in order to be
able to power up the system using an RTC alarm.

Signed-off-by: Johan Hovold <johan@kernel.org>
---
 drivers/rtc/rtc-omap.c | 9 ++++++++-
 1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/drivers/rtc/rtc-omap.c b/drivers/rtc/rtc-omap.c
index f6c93f877857..cb5ef3c845d1 100644
--- a/drivers/rtc/rtc-omap.c
+++ b/drivers/rtc/rtc-omap.c
@@ -687,8 +687,15 @@ static SIMPLE_DEV_PM_OPS(omap_rtc_pm_ops, omap_rtc_suspend, omap_rtc_resume);
 static void omap_rtc_shutdown(struct platform_device *pdev)
 {
 	struct omap_rtc *rtc = platform_get_drvdata(pdev);
+	u8 mask;
 
-	rtc_write(rtc, OMAP_RTC_INTERRUPTS_REG, 0);
+	/*
+	 * Keep the ALARM interrupt enabled to allow the system to power up on
+	 * alarm events.
+	 */
+	mask = rtc_read(rtc, OMAP_RTC_INTERRUPTS_REG);
+	mask &= OMAP_RTC_INTERRUPTS_IT_ALARM;
+	rtc_write(rtc, OMAP_RTC_INTERRUPTS_REG, mask);
 }
 
 static struct platform_driver omap_rtc_driver = {
-- 
2.0.4

[PATCH v2 17/20] rtc: omap: fix minor coding style issues

[Johan Hovold]

Fix minor coding style issues like comment style, indentation and remove
a few unnecessary casts.

Also drop the 1 from OMAP1 in the driver description.

Signed-off-by: Johan Hovold <johan@kernel.org>
---
 drivers/rtc/rtc-omap.c | 46 +++++++++++++++++++++++++++-------------------
 1 file changed, 27 insertions(+), 19 deletions(-)

diff --git a/drivers/rtc/rtc-omap.c b/drivers/rtc/rtc-omap.c
index cb5ef3c845d1..4278421183e5 100644
--- a/drivers/rtc/rtc-omap.c
+++ b/drivers/rtc/rtc-omap.c
@@ -1,5 +1,5 @@
 /*
- * TI OMAP1 Real Time Clock interface for Linux
+ * TI OMAP Real Time Clock interface for Linux
  *
  * Copyright (C) 2003 MontaVista Software, Inc.
  * Author: George G. Davis <gdavis@mvista.com> or <source@mvista.com>
@@ -25,7 +25,8 @@
 #include <linux/pm_runtime.h>
 #include <linux/io.h>
 
-/* The OMAP1 RTC is a year/month/day/hours/minutes/seconds BCD clock
+/*
+ * The OMAP RTC is a year/month/day/hours/minutes/seconds BCD clock
  * with century-range alarm matching, driven by the 32kHz clock.
  *
  * The main user-visible ways it differs from PC RTCs are by omitting
@@ -154,19 +155,20 @@ static inline void rtc_writel(struct omap_rtc *rtc, unsigned int reg, u32 val)
 	writel(val, rtc->base + reg);
 }
 
-/* we rely on the rtc framework to handle locking (rtc->ops_lock),
+/*
+ * We rely on the rtc framework to handle locking (rtc->ops_lock),
  * so the only other requirement is that register accesses which
  * require BUSY to be clear are made with IRQs locally disabled
  */
 static void rtc_wait_not_busy(struct omap_rtc *rtc)
 {
-	int	count = 0;
-	u8	status;
+	int count;
+	u8 status;
 
 	/* BUSY may stay active for 1/32768 second (~30 usec) */
 	for (count = 0; count < 50; count++) {
 		status = rtc_read(rtc, OMAP_RTC_STATUS_REG);
-		if ((status & (u8)OMAP_RTC_STATUS_BUSY) == 0)
+		if (!(status & OMAP_RTC_STATUS_BUSY))
 			break;
 		udelay(1);
 	}
@@ -175,9 +177,9 @@ static void rtc_wait_not_busy(struct omap_rtc *rtc)
 
 static irqreturn_t rtc_irq(int irq, void *dev_id)
 {
-	struct omap_rtc		*rtc = dev_id;
-	unsigned long		events = 0;
-	u8			irq_data;
+	struct omap_rtc	*rtc = dev_id;
+	unsigned long events = 0;
+	u8 irq_data;
 
 	irq_data = rtc_read(rtc, OMAP_RTC_STATUS_REG);
 
@@ -276,6 +278,7 @@ static int omap_rtc_read_time(struct device *dev, struct rtc_time *tm)
 	local_irq_enable();
 
 	bcd2tm(tm);
+
 	return 0;
 }
 
@@ -285,6 +288,7 @@ static int omap_rtc_set_time(struct device *dev, struct rtc_time *tm)
 
 	if (tm2bcd(tm) < 0)
 		return -EINVAL;
+
 	local_irq_disable();
 	rtc_wait_not_busy(rtc);
 
@@ -303,6 +307,7 @@ static int omap_rtc_set_time(struct device *dev, struct rtc_time *tm)
 static int omap_rtc_read_alarm(struct device *dev, struct rtc_wkalrm *alm)
 {
 	struct omap_rtc *rtc = dev_get_drvdata(dev);
+	u8 interrupts;
 
 	local_irq_disable();
 	rtc_wait_not_busy(rtc);
@@ -317,8 +322,9 @@ static int omap_rtc_read_alarm(struct device *dev, struct rtc_wkalrm *alm)
 	local_irq_enable();
 
 	bcd2tm(&alm->time);
-	alm->enabled = !!(rtc_read(rtc, OMAP_RTC_INTERRUPTS_REG)
-			& OMAP_RTC_INTERRUPTS_IT_ALARM);
+
+	interrupts = rtc_read(rtc, OMAP_RTC_INTERRUPTS_REG);
+	alm->enabled = !!(interrupts & OMAP_RTC_INTERRUPTS_IT_ALARM);
 
 	return 0;
 }
@@ -472,9 +478,9 @@ MODULE_DEVICE_TABLE(of, omap_rtc_of_match);
 
 static int __init omap_rtc_probe(struct platform_device *pdev)
 {
-	struct omap_rtc		*rtc;
-	struct resource		*res;
-	u8			reg, mask, new_ctrl;
+	struct omap_rtc	*rtc;
+	struct resource	*res;
+	u8 reg, mask, new_ctrl;
 	const struct platform_device_id *id_entry;
 	const struct of_device_id *of_id;
 	int ret;
@@ -551,14 +557,15 @@ static int __init omap_rtc_probe(struct platform_device *pdev)
 
 	/* On boards with split power, RTC_ON_NOFF won't reset the RTC */
 	reg = rtc_read(rtc, OMAP_RTC_CTRL_REG);
-	if (reg & (u8) OMAP_RTC_CTRL_STOP)
+	if (reg & OMAP_RTC_CTRL_STOP)
 		dev_info(&pdev->dev, "already running\n");
 
 	/* force to 24 hour mode */
-	new_ctrl = reg & (OMAP_RTC_CTRL_SPLIT|OMAP_RTC_CTRL_AUTO_COMP);
+	new_ctrl = reg & (OMAP_RTC_CTRL_SPLIT | OMAP_RTC_CTRL_AUTO_COMP);
 	new_ctrl |= OMAP_RTC_CTRL_STOP;
 
-	/* BOARD-SPECIFIC CUSTOMIZATION CAN GO HERE:
+	/*
+	 * BOARD-SPECIFIC CUSTOMIZATION CAN GO HERE:
 	 *
 	 *  - Device wake-up capability setting should come through chip
 	 *    init logic. OMAP1 boards should initialize the "wakeup capable"
@@ -572,7 +579,7 @@ static int __init omap_rtc_probe(struct platform_device *pdev)
 	 *    is write-only, and always reads as zero...)
 	 */
 
-	if (new_ctrl & (u8) OMAP_RTC_CTRL_SPLIT)
+	if (new_ctrl & OMAP_RTC_CTRL_SPLIT)
 		dev_info(&pdev->dev, "split power mode\n");
 
 	if (reg != new_ctrl)
@@ -651,7 +658,8 @@ static int omap_rtc_suspend(struct device *dev)
 
 	rtc->interrupts_reg = rtc_read(rtc, OMAP_RTC_INTERRUPTS_REG);
 
-	/* FIXME the RTC alarm is not currently acting as a wakeup event
+	/*
+	 * FIXME: the RTC alarm is not currently acting as a wakeup event
 	 * source on some platforms, and in fact this enable() call is just
 	 * saving a flag that's never used...
 	 */
-- 
2.0.4

[PATCH v2 18/20] rtc: omap: add copyright entry

[Johan Hovold]

Add myself to the list of copyright holders.

Signed-off-by: Johan Hovold <johan@kernel.org>
---
 drivers/rtc/rtc-omap.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/rtc/rtc-omap.c b/drivers/rtc/rtc-omap.c
index 4278421183e5..e74750f00b18 100644
--- a/drivers/rtc/rtc-omap.c
+++ b/drivers/rtc/rtc-omap.c
@@ -5,6 +5,7 @@
  * Author: George G. Davis <gdavis@mvista.com> or <source@mvista.com>
  *
  * Copyright (C) 2006 David Brownell (new RTC framework)
+ * Copyright (C) 2014 Johan Hovold <johan@kernel.org>
  *
  * This program is free software; you can redistribute it and/or
  * modify it under the terms of the GNU General Public License
-- 
2.0.4

[PATCH v2 19/20] ARM: dts: am33xx: update rtc-node compatible property

[Johan Hovold]

Enable am33xx specific RTC features (e.g. PMIC control) by adding
"ti,am3352-rtc" to the compatible property of the rtc node.

Reviewed-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: Johan Hovold <johan@kernel.org>
---
 arch/arm/boot/dts/am33xx.dtsi | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
index 3a0a161342ba..098e53602d5c 100644
--- a/arch/arm/boot/dts/am33xx.dtsi
+++ b/arch/arm/boot/dts/am33xx.dtsi
@@ -411,7 +411,7 @@
 		};
 
 		rtc: rtc@44e3e000 {
-			compatible = "ti,da830-rtc";
+			compatible = "ti,am3352-rtc", "ti,da830-rtc";
 			reg = <0x44e3e000 0x1000>;
 			interrupts = <75
 				      76>;
-- 
2.0.4

[PATCH v2 20/20] ARM: dts: am335x-boneblack: enable power off and rtc wake up

[Johan Hovold]

Configure the RTC as system-power controller, which allows the system to
be powered off as well as woken up again on subsequent RTC alarms.

Note that the PMIC needs to be put in SLEEP (rather than OFF) mode to
maintain RTC power. Specifically, this means that the PMIC
ti,pmic-shutdown-controller property must be left unset in order to be
able to wake up on RTC alarms.

Tested on BeagleBone Black (rev A5).

Reviewed-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: Johan Hovold <johan@kernel.org>
---
 arch/arm/boot/dts/am335x-boneblack.dts | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/arch/arm/boot/dts/am335x-boneblack.dts b/arch/arm/boot/dts/am335x-boneblack.dts
index 305975d3f531..0c8cdc9520b7 100644
--- a/arch/arm/boot/dts/am335x-boneblack.dts
+++ b/arch/arm/boot/dts/am335x-boneblack.dts
@@ -75,3 +75,7 @@
 		status = "okay";
 	};
 };
+
+&rtc {
+	ti,system-power-controller;
+};
-- 
2.0.4

Re: [PATCH 09/12] rtc: omap: add support for pmic_power_en

[Johan Hovold]

On Fri, Oct 10, 2014 at 01:07:27PM -0500, Felipe Balbi wrote:
> On Thu, Oct 09, 2014 at 09:06:31PM +0200, Johan Hovold wrote:

> > -	/* clear pending irqs, and set 1/second periodic,
> > -	 * which we'll use instead of update irqs
> > +	/*
> > +	 * disable interrupts
> > +	 *
> > +	 * NOTE: ALARM2 is not cleared on AM3352 if rtc_write (writeb) is used
> >  	 */
> > -	rtc_write(0, OMAP_RTC_INTERRUPTS_REG);
> > +	rtc_writel(0, OMAP_RTC_INTERRUPTS_REG);
> 
> bug fix, should be part of a separate patch and Cc stable :-)

I made this a separate fix in v2 but did not mark it for stable for now
as no one has been bitten by it (ALARM2 is never enabled by the current
driver).

Johan

Re: [PATCH 00/12] rtc: omap: fixes and power-off feature

[Johan Hovold]

On Wed, Oct 15, 2014 at 12:08:32PM -0500, Felipe Balbi wrote:
> On Wed, Oct 15, 2014 at 07:06:28PM +0200, Johan Hovold wrote:
> > On Wed, Oct 15, 2014 at 11:55:02AM -0500, Felipe Balbi wrote:

> > > BTW, how do you test this series ?
> > 
> > Set a 30 second wakealarm using the sysfs attribute of the rtc class
> > device and power off the BBB:
> > 
> > 	echo +30 >wakealarm; poweroff
> 
> sweet!!!! It worked just fine :-)

:)

> Too bad there's yet another DRM bug:
> 
> [  271.150158] Kernel panic - not syncing: Attempted to kill init! exitcode=0x00000000
> [  271.150158] 
> [  271.159725] CPU: 0 PID: 1 Comm: systemd-shutdow Not tainted 3.17.0-08392-g7fe2269-dirty #326
> [  271.168567] [<c00175a4>] (unwind_backtrace) from [<c00132f0>] (show_stack+0x20/0x24)
> [  271.176668] [<c00132f0>] (show_stack) from [<c06573a4>] (dump_stack+0x8c/0xa4)
> [  271.184215] [<c06573a4>] (dump_stack) from [<c0654f10>] (panic+0xa0/0x220)
> [  271.191405] [<c0654f10>] (panic) from [<c0049e54>] (do_exit+0x974/0x9d0)
> [  271.198410] [<c0049e54>] (do_exit) from [<c0067694>] (SyS_reboot+0x14c/0x1e8)
> [  271.205870] [<c0067694>] (SyS_reboot) from [<c000f080>] (ret_fast_syscall+0x0/0x48)
> [  271.214023] drm_kms_helper: panic occurred, switching back to text console
> [  271.221312] ---[ end Kernel panic - not syncing: Attempted to kill init! exitcode=0x00000000
> 
> In any case, board still powered up after 30 seconds(-ish). So this gets
> a:
> 
> Tested-by: Felipe Balbi <balbi@ti.com>

Thanks for testing. I didn't include your Tested-by in v2 due to the
invasiveness of the new device-abstraction patch. Still works fine on BBB
here though.

Johan

Re: [PATCH 08/12] rtc: omap: restore irq state after reading TC registers

[Johan Hovold]

On Sat, Oct 11, 2014 at 07:47:58PM -0500, Felipe Balbi wrote:
> On Sat, Oct 11, 2014 at 12:12:01PM +0200, Johan Hovold wrote:
> > On Fri, Oct 10, 2014 at 01:02:31PM -0500, Felipe Balbi wrote:
> > > Hi,
> > > 
> > > On Thu, Oct 09, 2014 at 09:06:30PM +0200, Johan Hovold wrote:
> > > > Make sure to restore local irq state when reading the timer/calendar
> > > > (TC) registers, so that omap_rtc_read_time() can be called with
> > > > interrupts disabled.
> > > > 
> > > > Signed-off-by: Johan Hovold <johan@kernel.org>
> > > > ---
> > > >  drivers/rtc/rtc-omap.c | 6 ++++--
> > > >  1 file changed, 4 insertions(+), 2 deletions(-)
> > > > 
> > > > diff --git a/drivers/rtc/rtc-omap.c b/drivers/rtc/rtc-omap.c
> > > > index 0ef016553a97..62e2e9a9887a 100644
> > > > --- a/drivers/rtc/rtc-omap.c
> > > > +++ b/drivers/rtc/rtc-omap.c
> > > > @@ -239,8 +239,10 @@ static void bcd2tm(struct rtc_time *tm)
> > > >  
> > > >  static int omap_rtc_read_time(struct device *dev, struct rtc_time *tm)
> > > >  {
> > > > +	unsigned long flags;
> > > > +
> > > >  	/* we don't report wday/yday/isdst ... */
> > > > -	local_irq_disable();
> > > > +	local_irq_save(flags);
> > > 
> > > you should really convert these to a real spin_lock_irq*(), that's
> > > because local_irq* do not get re-written with RT patchset, so this
> > > pretty much "breaks" RT.
> > 
> > The driver uses local_irq* throughout to guarantee registers are not
> > read or written during an update event.
> > 
> > In fact, at least on AM33xx, this is not even necessary when reading (as
> > opposed to writing) the TC registers, but I did not dare change that
> > without knowing how the legacy platforms work in this respect.
> > 
> > Do you suggest doing this conversion as part of, or on top of, this
> > series?
> 
> probably on top of is. Safer that way.

I didn't include this conversion in v2 as you may have noticed. In fact,
I'm not even sure it should be done.

Using local_irq* "breaks" RT, but if we change it to spin_lock_irq* and
RT preempts us, we may miss the 15us access window which would break the
driver:

	"If the ARM accesses the TC registers outside of the access
	 period, then the access is not guaranteed."

On am33xx this only affects updating the TC (timer/calendar) or alarm
registers, but the driver currently disables interrupts also on reading
the time (possibly because the early IP revisions did not have the
shadow read registers).

Johan

Re: [PATCH 00/12] rtc: omap: fixes and power-off feature

[Johan Hovold]

On Sat, Oct 11, 2014 at 12:08:18PM -0700, Tony Lindgren wrote:
> * Johan Hovold <johan@kernel.org> [141011 02:42]:
> > On Fri, Oct 10, 2014 at 12:54:22PM -0500, Felipe Balbi wrote:
> > > 
> > > is this power-off feature "RTC-only mode" ?
> > 
> > Yes, I believe so, at least as long as RTC power is maintained. The
> > pmic_power_en pin can otherwise still be used to power off. 
> > 
> > On the BeagleBone the PMIC can be configured to enter OFF or SLEEP mode
> > on power off, where the latter (and default) mode keeps the RTC power
> > supply enabled.
> > 
> > Thanks for the fast review, Felipe.
> 
> Great :) I assume adding the regulator support to this driver should
> also help in the 35xx case?

If I remember correctly both OMAP and Sitara 35xx have no on-chip RTC so
they won't be using this driver.

> That is assuming that RTC power can be configured as a Linux
> regulator on 35xx.

Johan

Re: [PATCH 00/12] rtc: omap: fixes and power-off feature

[Tony Lindgren]

* Johan Hovold <johan@kernel.org> [141022 04:12]:
> On Sat, Oct 11, 2014 at 12:08:18PM -0700, Tony Lindgren wrote:
> > * Johan Hovold <johan@kernel.org> [141011 02:42]:
> > > On Fri, Oct 10, 2014 at 12:54:22PM -0500, Felipe Balbi wrote:
> > > > 
> > > > is this power-off feature "RTC-only mode" ?
> > > 
> > > Yes, I believe so, at least as long as RTC power is maintained. The
> > > pmic_power_en pin can otherwise still be used to power off. 
> > > 
> > > On the BeagleBone the PMIC can be configured to enter OFF or SLEEP mode
> > > on power off, where the latter (and default) mode keeps the RTC power
> > > supply enabled.
> > > 
> > > Thanks for the fast review, Felipe.
> > 
> > Great :) I assume adding the regulator support to this driver should
> > also help in the 35xx case?
> 
> If I remember correctly both OMAP and Sitara 35xx have no on-chip RTC so
> they won't be using this driver.

Sorry I made a typo.. I meanto to ask if adding the regulator
helps in your 335x case (not 35xx case)?

Regards,

Tony

Re: [PATCH 00/12] rtc: omap: fixes and power-off feature

[Johan Hovold]

On Wed, Oct 22, 2014 at 08:29:56AM -0700, Tony Lindgren wrote:
> * Johan Hovold <johan@kernel.org> [141022 04:12]:
> > On Sat, Oct 11, 2014 at 12:08:18PM -0700, Tony Lindgren wrote:
> > > * Johan Hovold <johan@kernel.org> [141011 02:42]:
> > > > On Fri, Oct 10, 2014 at 12:54:22PM -0500, Felipe Balbi wrote:
> > > > > 
> > > > > is this power-off feature "RTC-only mode" ?
> > > > 
> > > > Yes, I believe so, at least as long as RTC power is maintained. The
> > > > pmic_power_en pin can otherwise still be used to power off. 
> > > > 
> > > > On the BeagleBone the PMIC can be configured to enter OFF or SLEEP mode
> > > > on power off, where the latter (and default) mode keeps the RTC power
> > > > supply enabled.
> > > > 
> > > > Thanks for the fast review, Felipe.
> > > 
> > > Great :) I assume adding the regulator support to this driver should
> > > also help in the 35xx case?
> > 
> > If I remember correctly both OMAP and Sitara 35xx have no on-chip RTC so
> > they won't be using this driver.
> 
> Sorry I made a typo.. I meanto to ask if adding the regulator
> helps in your 335x case (not 35xx case)?

Ah, sorry, that's what I first read before I noticed you wrote "35xx"
twice. :)

Yes, RTC power can be configured as a regulator on am33xx (e.g. provided
by LDO1 of the PMIC on BBB). I guess you would still need to configure
it as always-on to be able to use the RTC-only mode, though.

Johan

Re: [PATCH 00/12] rtc: omap: fixes and power-off feature

[Tony Lindgren]

* Johan Hovold <johan@kernel.org> [141022 09:25]:
> On Wed, Oct 22, 2014 at 08:29:56AM -0700, Tony Lindgren wrote:
> > * Johan Hovold <johan@kernel.org> [141022 04:12]:
> > > On Sat, Oct 11, 2014 at 12:08:18PM -0700, Tony Lindgren wrote:
> > > > * Johan Hovold <johan@kernel.org> [141011 02:42]:
> > > > > On Fri, Oct 10, 2014 at 12:54:22PM -0500, Felipe Balbi wrote:
> > > > > > 
> > > > > > is this power-off feature "RTC-only mode" ?
> > > > > 
> > > > > Yes, I believe so, at least as long as RTC power is maintained. The
> > > > > pmic_power_en pin can otherwise still be used to power off. 
> > > > > 
> > > > > On the BeagleBone the PMIC can be configured to enter OFF or SLEEP mode
> > > > > on power off, where the latter (and default) mode keeps the RTC power
> > > > > supply enabled.
> > > > > 
> > > > > Thanks for the fast review, Felipe.
> > > > 
> > > > Great :) I assume adding the regulator support to this driver should
> > > > also help in the 35xx case?
> > > 
> > > If I remember correctly both OMAP and Sitara 35xx have no on-chip RTC so
> > > they won't be using this driver.
> > 
> > Sorry I made a typo.. I meanto to ask if adding the regulator
> > helps in your 335x case (not 35xx case)?
> 
> Ah, sorry, that's what I first read before I noticed you wrote "35xx"
> twice. :)

Yes sorry my nerves are doing things on their own for some stuff
it seems like :)
 
> Yes, RTC power can be configured as a regulator on am33xx (e.g. provided
> by LDO1 of the PMIC on BBB). I guess you would still need to configure
> it as always-on to be able to use the RTC-only mode, though.

OK great.

Tony

Re: [PATCH 08/12] rtc: omap: restore irq state after reading TC registers

[Felipe Balbi]

[-- Attachment #1: Type: text/plain, Size: 2848 bytes --]

On Wed, Oct 22, 2014 at 12:50:11PM +0200, Johan Hovold wrote:
> On Sat, Oct 11, 2014 at 07:47:58PM -0500, Felipe Balbi wrote:
> > On Sat, Oct 11, 2014 at 12:12:01PM +0200, Johan Hovold wrote:
> > > On Fri, Oct 10, 2014 at 01:02:31PM -0500, Felipe Balbi wrote:
> > > > Hi,
> > > > 
> > > > On Thu, Oct 09, 2014 at 09:06:30PM +0200, Johan Hovold wrote:
> > > > > Make sure to restore local irq state when reading the timer/calendar
> > > > > (TC) registers, so that omap_rtc_read_time() can be called with
> > > > > interrupts disabled.
> > > > > 
> > > > > Signed-off-by: Johan Hovold <johan@kernel.org>
> > > > > ---
> > > > >  drivers/rtc/rtc-omap.c | 6 ++++--
> > > > >  1 file changed, 4 insertions(+), 2 deletions(-)
> > > > > 
> > > > > diff --git a/drivers/rtc/rtc-omap.c b/drivers/rtc/rtc-omap.c
> > > > > index 0ef016553a97..62e2e9a9887a 100644
> > > > > --- a/drivers/rtc/rtc-omap.c
> > > > > +++ b/drivers/rtc/rtc-omap.c
> > > > > @@ -239,8 +239,10 @@ static void bcd2tm(struct rtc_time *tm)
> > > > >  
> > > > >  static int omap_rtc_read_time(struct device *dev, struct rtc_time *tm)
> > > > >  {
> > > > > +	unsigned long flags;
> > > > > +
> > > > >  	/* we don't report wday/yday/isdst ... */
> > > > > -	local_irq_disable();
> > > > > +	local_irq_save(flags);
> > > > 
> > > > you should really convert these to a real spin_lock_irq*(), that's
> > > > because local_irq* do not get re-written with RT patchset, so this
> > > > pretty much "breaks" RT.
> > > 
> > > The driver uses local_irq* throughout to guarantee registers are not
> > > read or written during an update event.
> > > 
> > > In fact, at least on AM33xx, this is not even necessary when reading (as
> > > opposed to writing) the TC registers, but I did not dare change that
> > > without knowing how the legacy platforms work in this respect.
> > > 
> > > Do you suggest doing this conversion as part of, or on top of, this
> > > series?
> > 
> > probably on top of is. Safer that way.
> 
> I didn't include this conversion in v2 as you may have noticed. In fact,
> I'm not even sure it should be done.
> 
> Using local_irq* "breaks" RT, but if we change it to spin_lock_irq* and
> RT preempts us, we may miss the 15us access window which would break the
> driver:
> 
> 	"If the ARM accesses the TC registers outside of the access
> 	 period, then the access is not guaranteed."
> 
> On am33xx this only affects updating the TC (timer/calendar) or alarm
> registers, but the driver currently disables interrupts also on reading
> the time (possibly because the early IP revisions did not have the
> shadow read registers).

that's alright, better not to change the behavior in this case. But as a
future patch, you might want to convert this to a raw_spinlock. That
won't get preempted.

-- 
balbi

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: [PATCH 09/12] rtc: omap: add support for pmic_power_en

[Felipe Balbi]

[-- Attachment #1: Type: text/plain, Size: 823 bytes --]

On Wed, Oct 22, 2014 at 12:18:49PM +0200, Johan Hovold wrote:
> On Fri, Oct 10, 2014 at 01:07:27PM -0500, Felipe Balbi wrote:
> > On Thu, Oct 09, 2014 at 09:06:31PM +0200, Johan Hovold wrote:
> 
> > > -	/* clear pending irqs, and set 1/second periodic,
> > > -	 * which we'll use instead of update irqs
> > > +	/*
> > > +	 * disable interrupts
> > > +	 *
> > > +	 * NOTE: ALARM2 is not cleared on AM3352 if rtc_write (writeb) is used
> > >  	 */
> > > -	rtc_write(0, OMAP_RTC_INTERRUPTS_REG);
> > > +	rtc_writel(0, OMAP_RTC_INTERRUPTS_REG);
> > 
> > bug fix, should be part of a separate patch and Cc stable :-)
> 
> I made this a separate fix in v2 but did not mark it for stable for now
> as no one has been bitten by it (ALARM2 is never enabled by the current
> driver).

makes sense.

-- 
balbi

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: [PATCH 00/12] rtc: omap: fixes and power-off feature

[Felipe Balbi]

[-- Attachment #1: Type: text/plain, Size: 1894 bytes --]

On Wed, Oct 22, 2014 at 12:23:05PM +0200, Johan Hovold wrote:
> On Wed, Oct 15, 2014 at 12:08:32PM -0500, Felipe Balbi wrote:
> > On Wed, Oct 15, 2014 at 07:06:28PM +0200, Johan Hovold wrote:
> > > On Wed, Oct 15, 2014 at 11:55:02AM -0500, Felipe Balbi wrote:
> 
> > > > BTW, how do you test this series ?
> > > 
> > > Set a 30 second wakealarm using the sysfs attribute of the rtc class
> > > device and power off the BBB:
> > > 
> > > 	echo +30 >wakealarm; poweroff
> > 
> > sweet!!!! It worked just fine :-)
> 
> :)
> 
> > Too bad there's yet another DRM bug:
> > 
> > [  271.150158] Kernel panic - not syncing: Attempted to kill init! exitcode=0x00000000
> > [  271.150158] 
> > [  271.159725] CPU: 0 PID: 1 Comm: systemd-shutdow Not tainted 3.17.0-08392-g7fe2269-dirty #326
> > [  271.168567] [<c00175a4>] (unwind_backtrace) from [<c00132f0>] (show_stack+0x20/0x24)
> > [  271.176668] [<c00132f0>] (show_stack) from [<c06573a4>] (dump_stack+0x8c/0xa4)
> > [  271.184215] [<c06573a4>] (dump_stack) from [<c0654f10>] (panic+0xa0/0x220)
> > [  271.191405] [<c0654f10>] (panic) from [<c0049e54>] (do_exit+0x974/0x9d0)
> > [  271.198410] [<c0049e54>] (do_exit) from [<c0067694>] (SyS_reboot+0x14c/0x1e8)
> > [  271.205870] [<c0067694>] (SyS_reboot) from [<c000f080>] (ret_fast_syscall+0x0/0x48)
> > [  271.214023] drm_kms_helper: panic occurred, switching back to text console
> > [  271.221312] ---[ end Kernel panic - not syncing: Attempted to kill init! exitcode=0x00000000
> > 
> > In any case, board still powered up after 30 seconds(-ish). So this gets
> > a:
> > 
> > Tested-by: Felipe Balbi <balbi@ti.com>
> 
> Thanks for testing. I didn't include your Tested-by in v2 due to the
> invasiveness of the new device-abstraction patch. Still works fine on BBB
> here though.

alright, if I have time I'll test again, but not this week.

-- 
balbi

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: [PATCH 00/12] rtc: omap: fixes and power-off feature

[Johan Hovold]

On Thu, Oct 23, 2014 at 01:55:13PM -0500, Felipe Balbi wrote:
> On Wed, Oct 22, 2014 at 12:23:05PM +0200, Johan Hovold wrote:
> > On Wed, Oct 15, 2014 at 12:08:32PM -0500, Felipe Balbi wrote:
> > > On Wed, Oct 15, 2014 at 07:06:28PM +0200, Johan Hovold wrote:
> > > > On Wed, Oct 15, 2014 at 11:55:02AM -0500, Felipe Balbi wrote:
> > 
> > > > > BTW, how do you test this series ?
> > > > 
> > > > Set a 30 second wakealarm using the sysfs attribute of the rtc class
> > > > device and power off the BBB:
> > > > 
> > > > 	echo +30 >wakealarm; poweroff
> > > 
> > > sweet!!!! It worked just fine :-)
> > 
> > :)
> > 
> > > Too bad there's yet another DRM bug:
> > > 
> > > [  271.150158] Kernel panic - not syncing: Attempted to kill init! exitcode=0x00000000
> > > [  271.150158] 
> > > [  271.159725] CPU: 0 PID: 1 Comm: systemd-shutdow Not tainted 3.17.0-08392-g7fe2269-dirty #326
> > > [  271.168567] [<c00175a4>] (unwind_backtrace) from [<c00132f0>] (show_stack+0x20/0x24)
> > > [  271.176668] [<c00132f0>] (show_stack) from [<c06573a4>] (dump_stack+0x8c/0xa4)
> > > [  271.184215] [<c06573a4>] (dump_stack) from [<c0654f10>] (panic+0xa0/0x220)
> > > [  271.191405] [<c0654f10>] (panic) from [<c0049e54>] (do_exit+0x974/0x9d0)
> > > [  271.198410] [<c0049e54>] (do_exit) from [<c0067694>] (SyS_reboot+0x14c/0x1e8)
> > > [  271.205870] [<c0067694>] (SyS_reboot) from [<c000f080>] (ret_fast_syscall+0x0/0x48)
> > > [  271.214023] drm_kms_helper: panic occurred, switching back to text console
> > > [  271.221312] ---[ end Kernel panic - not syncing: Attempted to kill init! exitcode=0x00000000
> > > 
> > > In any case, board still powered up after 30 seconds(-ish). So this gets
> > > a:
> > > 
> > > Tested-by: Felipe Balbi <balbi@ti.com>
> > 
> > Thanks for testing. I didn't include your Tested-by in v2 due to the
> > invasiveness of the new device-abstraction patch. Still works fine on BBB
> > here though.
> 
> alright, if I have time I'll test again, but not this week.

Great, thanks! I believe Andrew usually adds any late Reviewed-by or
Tested-by tags while the patches live in his tree.

Johan

Re: [PATCH v2 00/20] rtc: omap: fixes and power-off feature

[Felipe Balbi]

[-- Attachment #1: Type: text/plain, Size: 2831 bytes --]

Hi,

On Tue, Oct 21, 2014 at 07:37:46PM +0200, Johan Hovold wrote:
> This series fixes a few issues with the omap rtc-driver, cleans up a
> bit, adds device abstraction, and finally adds support for the PMIC
> control feature found in some revisions of this RTC IP block.
> 
> Ultimately, this allows for powering off the Beaglebone and waking it up
> again on RTC alarms.
> 
> Changes since v1 include:
> 
>  - add device abstraction
>  - add structured device-type info
>  - fix interrupt disable at probe separately
>  - register interrupts after class device as before
>  - add helper to read raw bcd time
>  - more clean ups
>  - add copyright entry
>  - enable pmic control only for Beaglebone Black
> 
> I realised that it was better to keep this patch series self-contained
> and include the device abstraction in it, rather than rely on some
> patches yet to be posted (contrary to what I proposed in v1). It should
> now be straight forward to add deferred-probing and regulator support on
> top of this series instead. [1]
> 
> I've kept Felipe's Reviewed-by tags only on the first and last couple of
> patches which have not changed (in any significant way).
> 
> For the record, the new functionality is easily tested on BBB with:
> 
> 	echo +30 >/sys/class/rtc/rtc0/wakealarm; poweroff
> 
> There are some patches floating around to add power-off handler
> call chains [2] as well as an RFC for a generic "poweroff-source"
> property [3]. Since it is unclear if, when (and through which tree) this
> will eventually go in, I suggest merging this series as-is now and do
> the trivial updates to use these new interfaces once the infrastructure
> is in place.

I tested this entire series with my BBB and it still works fine. However
I still get below panic. This time without any DRM errors:

[   63.087832] Kernel panic - not syncing: Attempted to kill init! exitcode=0x00000000
[   63.087832] 
[   63.097399] CPU: 0 PID: 1 Comm: systemd-shutdow Not tainted 3.18.0-rc1-00095-g8524e69 #556
[   63.106060] [<c00175a4>] (unwind_backtrace) from [<c00132f0>] (show_stack+0x20/0x24)
[   63.114160] [<c00132f0>] (show_stack) from [<c0657404>] (dump_stack+0x8c/0xa4)
[   63.121706] [<c0657404>] (dump_stack) from [<c0654f70>] (panic+0xa0/0x220)
[   63.128895] [<c0654f70>] (panic) from [<c0049e64>] (do_exit+0x974/0x9d0)
[   63.135900] [<c0049e64>] (do_exit) from [<c006775c>] (SyS_reboot+0x14c/0x1e8)
[   63.143361] [<c006775c>] (SyS_reboot) from [<c000f080>] (ret_fast_syscall+0x0/0x48)
[   63.151596] ---[ end Kernel panic - not syncing: Attempted to kill init! exitcode=0x00000000

Then again, this also happens by simply calling poweroff without
enabling wakealarm.

In any case, for the whole series:

Tested-by: Felipe Balbi <balbi@ti.com>


-- 
balbi

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: [PATCH v2 00/20] rtc: omap: fixes and power-off feature

[Johan Hovold]

[ +CC: Russell ]

On Fri, Oct 24, 2014 at 11:08:45AM -0500, Felipe Balbi wrote:

> I tested this entire series with my BBB and it still works fine. However
> I still get below panic. This time without any DRM errors:
> 
> [   63.087832] Kernel panic - not syncing: Attempted to kill init! exitcode=0x00000000
> [   63.087832] 
> [   63.097399] CPU: 0 PID: 1 Comm: systemd-shutdow Not tainted 3.18.0-rc1-00095-g8524e69 #556
> [   63.106060] [<c00175a4>] (unwind_backtrace) from [<c00132f0>] (show_stack+0x20/0x24)
> [   63.114160] [<c00132f0>] (show_stack) from [<c0657404>] (dump_stack+0x8c/0xa4)
> [   63.121706] [<c0657404>] (dump_stack) from [<c0654f70>] (panic+0xa0/0x220)
> [   63.128895] [<c0654f70>] (panic) from [<c0049e64>] (do_exit+0x974/0x9d0)
> [   63.135900] [<c0049e64>] (do_exit) from [<c006775c>] (SyS_reboot+0x14c/0x1e8)
> [   63.143361] [<c006775c>] (SyS_reboot) from [<c000f080>] (ret_fast_syscall+0x0/0x48)
> [   63.151596] ---[ end Kernel panic - not syncing: Attempted to kill init! exitcode=0x00000000
> 
> Then again, this also happens by simply calling poweroff without
> enabling wakealarm.

Bah, I forgot to look into that. I haven't seen this myself as I don't
use systemd (which does the syscall from process 0).

Some driver power-off implementations and some arch machine_power_off
spin indefinitely (or use an mdelay and WARN) after trying to power off.

I think this is really a bug in arch/arm that should be fixed
analogously to how failed reboot is handled in machine_restart().

Care to try the patch below?

I should still add a two-second delay to rtc-omap to avoid the arch
error message.

Andrew, can you update one patch in the series or should I just resend
them all (with proper Tested-by tags)?

> In any case, for the whole series:
> 
> Tested-by: Felipe Balbi <balbi@ti.com>

Thanks for testing!

Johan


>From aaa1d1d6171c895b6966ba5b738ac7946ada97c7 Mon Sep 17 00:00:00 2001
From: Johan Hovold <johan@kernel.org>
Date: Fri, 24 Oct 2014 18:53:09 +0200
Subject: [PATCH] ARM: fix failed power-off handling

Make sure to handle failed power off by printing an error message and
halting (analogously to how failed reboot is handled).

Power off can fail for example if the hardware has not been wired up
correctly.

This avoids a kernel panic when called from process 0:

[   63.087832] Kernel panic - not syncing: Attempted to kill init! exitcode=0x00000000
[   63.087832]
[   63.097399] CPU: 0 PID: 1 Comm: systemd-shutdow Not tainted 3.18.0-rc1-00095-g8524e69 #556
[   63.106060] [<c00175a4>] (unwind_backtrace) from [<c00132f0>] (show_stack+0x20/0x24)
[   63.114160] [<c00132f0>] (show_stack) from [<c0657404>] (dump_stack+0x8c/0xa4)
[   63.121706] [<c0657404>] (dump_stack) from [<c0654f70>] (panic+0xa0/0x220)
[   63.128895] [<c0654f70>] (panic) from [<c0049e64>] (do_exit+0x974/0x9d0)
[   63.135900] [<c0049e64>] (do_exit) from [<c006775c>] (SyS_reboot+0x14c/0x1e8)
[   63.143361] [<c006775c>] (SyS_reboot) from [<c000f080>] (ret_fast_syscall+0x0/0x48)
[   63.151596] ---[ end Kernel panic - not syncing: Attempted to kill init! exitcode=0x00000000

Signed-off-by: Johan Hovold <johan@kernel.org>
---
 arch/arm/kernel/process.c | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/arch/arm/kernel/process.c b/arch/arm/kernel/process.c
index a35f6ebbd2c2..68c38af5687c 100644
--- a/arch/arm/kernel/process.c
+++ b/arch/arm/kernel/process.c
@@ -212,6 +212,12 @@ void machine_power_off(void)
 
 	if (pm_power_off)
 		pm_power_off();
+
+	/* Give a grace period for failure to power off */
+	mdelay(1000);
+
+	pr_err("Power off failed -- system halted\n");
+	while (1);
 }
 
 /*
-- 
2.0.4

Re: [PATCH v2 00/20] rtc: omap: fixes and power-off feature

[Felipe Balbi]

[-- Attachment #1: Type: text/plain, Size: 4143 bytes --]

On Fri, Oct 24, 2014 at 09:02:51PM +0200, Johan Hovold wrote:
> [ +CC: Russell ]
> 
> On Fri, Oct 24, 2014 at 11:08:45AM -0500, Felipe Balbi wrote:
> 
> > I tested this entire series with my BBB and it still works fine. However
> > I still get below panic. This time without any DRM errors:
> > 
> > [   63.087832] Kernel panic - not syncing: Attempted to kill init! exitcode=0x00000000
> > [   63.087832] 
> > [   63.097399] CPU: 0 PID: 1 Comm: systemd-shutdow Not tainted 3.18.0-rc1-00095-g8524e69 #556
> > [   63.106060] [<c00175a4>] (unwind_backtrace) from [<c00132f0>] (show_stack+0x20/0x24)
> > [   63.114160] [<c00132f0>] (show_stack) from [<c0657404>] (dump_stack+0x8c/0xa4)
> > [   63.121706] [<c0657404>] (dump_stack) from [<c0654f70>] (panic+0xa0/0x220)
> > [   63.128895] [<c0654f70>] (panic) from [<c0049e64>] (do_exit+0x974/0x9d0)
> > [   63.135900] [<c0049e64>] (do_exit) from [<c006775c>] (SyS_reboot+0x14c/0x1e8)
> > [   63.143361] [<c006775c>] (SyS_reboot) from [<c000f080>] (ret_fast_syscall+0x0/0x48)
> > [   63.151596] ---[ end Kernel panic - not syncing: Attempted to kill init! exitcode=0x00000000
> > 
> > Then again, this also happens by simply calling poweroff without
> > enabling wakealarm.
> 
> Bah, I forgot to look into that. I haven't seen this myself as I don't
> use systemd (which does the syscall from process 0).
> 
> Some driver power-off implementations and some arch machine_power_off
> spin indefinitely (or use an mdelay and WARN) after trying to power off.
> 
> I think this is really a bug in arch/arm that should be fixed
> analogously to how failed reboot is handled in machine_restart().
> 
> Care to try the patch below?
> 
> I should still add a two-second delay to rtc-omap to avoid the arch
> error message.
> 
> Andrew, can you update one patch in the series or should I just resend
> them all (with proper Tested-by tags)?
> 
> > In any case, for the whole series:
> > 
> > Tested-by: Felipe Balbi <balbi@ti.com>
> 
> Thanks for testing!
> 
> Johan
> 
> 
> >From aaa1d1d6171c895b6966ba5b738ac7946ada97c7 Mon Sep 17 00:00:00 2001
> From: Johan Hovold <johan@kernel.org>
> Date: Fri, 24 Oct 2014 18:53:09 +0200
> Subject: [PATCH] ARM: fix failed power-off handling
> 
> Make sure to handle failed power off by printing an error message and
> halting (analogously to how failed reboot is handled).
> 
> Power off can fail for example if the hardware has not been wired up
> correctly.
> 
> This avoids a kernel panic when called from process 0:
> 
> [   63.087832] Kernel panic - not syncing: Attempted to kill init! exitcode=0x00000000
> [   63.087832]
> [   63.097399] CPU: 0 PID: 1 Comm: systemd-shutdow Not tainted 3.18.0-rc1-00095-g8524e69 #556
> [   63.106060] [<c00175a4>] (unwind_backtrace) from [<c00132f0>] (show_stack+0x20/0x24)
> [   63.114160] [<c00132f0>] (show_stack) from [<c0657404>] (dump_stack+0x8c/0xa4)
> [   63.121706] [<c0657404>] (dump_stack) from [<c0654f70>] (panic+0xa0/0x220)
> [   63.128895] [<c0654f70>] (panic) from [<c0049e64>] (do_exit+0x974/0x9d0)
> [   63.135900] [<c0049e64>] (do_exit) from [<c006775c>] (SyS_reboot+0x14c/0x1e8)
> [   63.143361] [<c006775c>] (SyS_reboot) from [<c000f080>] (ret_fast_syscall+0x0/0x48)
> [   63.151596] ---[ end Kernel panic - not syncing: Attempted to kill init! exitcode=0x00000000
> 
> Signed-off-by: Johan Hovold <johan@kernel.org>
> ---
>  arch/arm/kernel/process.c | 6 ++++++
>  1 file changed, 6 insertions(+)
> 
> diff --git a/arch/arm/kernel/process.c b/arch/arm/kernel/process.c
> index a35f6ebbd2c2..68c38af5687c 100644
> --- a/arch/arm/kernel/process.c
> +++ b/arch/arm/kernel/process.c
> @@ -212,6 +212,12 @@ void machine_power_off(void)
>  
>  	if (pm_power_off)
>  		pm_power_off();
> +
> +	/* Give a grace period for failure to power off */
> +	mdelay(1000);
> +
> +	pr_err("Power off failed -- system halted\n");
> +	while (1);
>  }

with this I always get to "Power off failed -- system halted". If I
switch to v3.18-rc1 vanilla, then it works. So it's definitely caused by
your rtc-only patches.

-- 
balbi

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: [PATCH v2 00/20] rtc: omap: fixes and power-off feature

[Felipe Balbi]

[-- Attachment #1: Type: text/plain, Size: 4723 bytes --]

Hi,

On Fri, Oct 24, 2014 at 02:25:40PM -0500, Felipe Balbi wrote:
> On Fri, Oct 24, 2014 at 09:02:51PM +0200, Johan Hovold wrote:
> > [ +CC: Russell ]
> > 
> > On Fri, Oct 24, 2014 at 11:08:45AM -0500, Felipe Balbi wrote:
> > 
> > > I tested this entire series with my BBB and it still works fine. However
> > > I still get below panic. This time without any DRM errors:
> > > 
> > > [   63.087832] Kernel panic - not syncing: Attempted to kill init! exitcode=0x00000000
> > > [   63.087832] 
> > > [   63.097399] CPU: 0 PID: 1 Comm: systemd-shutdow Not tainted 3.18.0-rc1-00095-g8524e69 #556
> > > [   63.106060] [<c00175a4>] (unwind_backtrace) from [<c00132f0>] (show_stack+0x20/0x24)
> > > [   63.114160] [<c00132f0>] (show_stack) from [<c0657404>] (dump_stack+0x8c/0xa4)
> > > [   63.121706] [<c0657404>] (dump_stack) from [<c0654f70>] (panic+0xa0/0x220)
> > > [   63.128895] [<c0654f70>] (panic) from [<c0049e64>] (do_exit+0x974/0x9d0)
> > > [   63.135900] [<c0049e64>] (do_exit) from [<c006775c>] (SyS_reboot+0x14c/0x1e8)
> > > [   63.143361] [<c006775c>] (SyS_reboot) from [<c000f080>] (ret_fast_syscall+0x0/0x48)
> > > [   63.151596] ---[ end Kernel panic - not syncing: Attempted to kill init! exitcode=0x00000000
> > > 
> > > Then again, this also happens by simply calling poweroff without
> > > enabling wakealarm.
> > 
> > Bah, I forgot to look into that. I haven't seen this myself as I don't
> > use systemd (which does the syscall from process 0).
> > 
> > Some driver power-off implementations and some arch machine_power_off
> > spin indefinitely (or use an mdelay and WARN) after trying to power off.
> > 
> > I think this is really a bug in arch/arm that should be fixed
> > analogously to how failed reboot is handled in machine_restart().
> > 
> > Care to try the patch below?
> > 
> > I should still add a two-second delay to rtc-omap to avoid the arch
> > error message.
> > 
> > Andrew, can you update one patch in the series or should I just resend
> > them all (with proper Tested-by tags)?
> > 
> > > In any case, for the whole series:
> > > 
> > > Tested-by: Felipe Balbi <balbi@ti.com>
> > 
> > Thanks for testing!
> > 
> > Johan
> > 
> > 
> > >From aaa1d1d6171c895b6966ba5b738ac7946ada97c7 Mon Sep 17 00:00:00 2001
> > From: Johan Hovold <johan@kernel.org>
> > Date: Fri, 24 Oct 2014 18:53:09 +0200
> > Subject: [PATCH] ARM: fix failed power-off handling
> > 
> > Make sure to handle failed power off by printing an error message and
> > halting (analogously to how failed reboot is handled).
> > 
> > Power off can fail for example if the hardware has not been wired up
> > correctly.
> > 
> > This avoids a kernel panic when called from process 0:
> > 
> > [   63.087832] Kernel panic - not syncing: Attempted to kill init! exitcode=0x00000000
> > [   63.087832]
> > [   63.097399] CPU: 0 PID: 1 Comm: systemd-shutdow Not tainted 3.18.0-rc1-00095-g8524e69 #556
> > [   63.106060] [<c00175a4>] (unwind_backtrace) from [<c00132f0>] (show_stack+0x20/0x24)
> > [   63.114160] [<c00132f0>] (show_stack) from [<c0657404>] (dump_stack+0x8c/0xa4)
> > [   63.121706] [<c0657404>] (dump_stack) from [<c0654f70>] (panic+0xa0/0x220)
> > [   63.128895] [<c0654f70>] (panic) from [<c0049e64>] (do_exit+0x974/0x9d0)
> > [   63.135900] [<c0049e64>] (do_exit) from [<c006775c>] (SyS_reboot+0x14c/0x1e8)
> > [   63.143361] [<c006775c>] (SyS_reboot) from [<c000f080>] (ret_fast_syscall+0x0/0x48)
> > [   63.151596] ---[ end Kernel panic - not syncing: Attempted to kill init! exitcode=0x00000000
> > 
> > Signed-off-by: Johan Hovold <johan@kernel.org>
> > ---
> >  arch/arm/kernel/process.c | 6 ++++++
> >  1 file changed, 6 insertions(+)
> > 
> > diff --git a/arch/arm/kernel/process.c b/arch/arm/kernel/process.c
> > index a35f6ebbd2c2..68c38af5687c 100644
> > --- a/arch/arm/kernel/process.c
> > +++ b/arch/arm/kernel/process.c
> > @@ -212,6 +212,12 @@ void machine_power_off(void)
> >  
> >  	if (pm_power_off)
> >  		pm_power_off();
> > +
> > +	/* Give a grace period for failure to power off */
> > +	mdelay(1000);
> > +
> > +	pr_err("Power off failed -- system halted\n");
> > +	while (1);
> >  }
> 
> with this I always get to "Power off failed -- system halted". If I
> switch to v3.18-rc1 vanilla, then it works. So it's definitely caused by
> your rtc-only patches.

ok, so it seems like it takes more than 1 second for things to
propagate. If I increase that mdelay() to 3000, then everything works
fine on my end. I think we should get RMK's input on this 3000ms delay
to machine_power_off(). Should it be generic, or should we add it to our
rtc pm_power_off implementation ?

-- 
balbi

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: [PATCH v2 00/20] rtc: omap: fixes and power-off feature

[Johan Hovold]

On Fri, Oct 24, 2014 at 02:29:48PM -0500, Felipe Balbi wrote:
> Hi,
> 
> On Fri, Oct 24, 2014 at 02:25:40PM -0500, Felipe Balbi wrote:
> > On Fri, Oct 24, 2014 at 09:02:51PM +0200, Johan Hovold wrote:
> > > [ +CC: Russell ]
> > > 
> > > On Fri, Oct 24, 2014 at 11:08:45AM -0500, Felipe Balbi wrote:
> > > 
> > > > I tested this entire series with my BBB and it still works fine. However
> > > > I still get below panic. This time without any DRM errors:
> > > > 
> > > > [   63.087832] Kernel panic - not syncing: Attempted to kill init! exitcode=0x00000000
> > > > [   63.087832] 
> > > > [   63.097399] CPU: 0 PID: 1 Comm: systemd-shutdow Not tainted 3.18.0-rc1-00095-g8524e69 #556
> > > > [   63.106060] [<c00175a4>] (unwind_backtrace) from [<c00132f0>] (show_stack+0x20/0x24)
> > > > [   63.114160] [<c00132f0>] (show_stack) from [<c0657404>] (dump_stack+0x8c/0xa4)
> > > > [   63.121706] [<c0657404>] (dump_stack) from [<c0654f70>] (panic+0xa0/0x220)
> > > > [   63.128895] [<c0654f70>] (panic) from [<c0049e64>] (do_exit+0x974/0x9d0)
> > > > [   63.135900] [<c0049e64>] (do_exit) from [<c006775c>] (SyS_reboot+0x14c/0x1e8)
> > > > [   63.143361] [<c006775c>] (SyS_reboot) from [<c000f080>] (ret_fast_syscall+0x0/0x48)
> > > > [   63.151596] ---[ end Kernel panic - not syncing: Attempted to kill init! exitcode=0x00000000
> > > > 
> > > > Then again, this also happens by simply calling poweroff without
> > > > enabling wakealarm.
> > > 
> > > Bah, I forgot to look into that. I haven't seen this myself as I don't
> > > use systemd (which does the syscall from process 0).
> > > 
> > > Some driver power-off implementations and some arch machine_power_off
> > > spin indefinitely (or use an mdelay and WARN) after trying to power off.
> > > 
> > > I think this is really a bug in arch/arm that should be fixed
> > > analogously to how failed reboot is handled in machine_restart().
> > > 
> > > Care to try the patch below?
> > > 
> > > I should still add a two-second delay to rtc-omap to avoid the arch
> > > error message.
> > > 
> > > Andrew, can you update one patch in the series or should I just resend
> > > them all (with proper Tested-by tags)?
> > > 
> > > > In any case, for the whole series:
> > > > 
> > > > Tested-by: Felipe Balbi <balbi@ti.com>
> > > 
> > > Thanks for testing!
> > > 
> > > Johan
> > > 
> > > 
> > > >From aaa1d1d6171c895b6966ba5b738ac7946ada97c7 Mon Sep 17 00:00:00 2001
> > > From: Johan Hovold <johan@kernel.org>
> > > Date: Fri, 24 Oct 2014 18:53:09 +0200
> > > Subject: [PATCH] ARM: fix failed power-off handling
> > > 
> > > Make sure to handle failed power off by printing an error message and
> > > halting (analogously to how failed reboot is handled).
> > > 
> > > Power off can fail for example if the hardware has not been wired up
> > > correctly.
> > > 
> > > This avoids a kernel panic when called from process 0:
> > > 
> > > [   63.087832] Kernel panic - not syncing: Attempted to kill init! exitcode=0x00000000
> > > [   63.087832]
> > > [   63.097399] CPU: 0 PID: 1 Comm: systemd-shutdow Not tainted 3.18.0-rc1-00095-g8524e69 #556
> > > [   63.106060] [<c00175a4>] (unwind_backtrace) from [<c00132f0>] (show_stack+0x20/0x24)
> > > [   63.114160] [<c00132f0>] (show_stack) from [<c0657404>] (dump_stack+0x8c/0xa4)
> > > [   63.121706] [<c0657404>] (dump_stack) from [<c0654f70>] (panic+0xa0/0x220)
> > > [   63.128895] [<c0654f70>] (panic) from [<c0049e64>] (do_exit+0x974/0x9d0)
> > > [   63.135900] [<c0049e64>] (do_exit) from [<c006775c>] (SyS_reboot+0x14c/0x1e8)
> > > [   63.143361] [<c006775c>] (SyS_reboot) from [<c000f080>] (ret_fast_syscall+0x0/0x48)
> > > [   63.151596] ---[ end Kernel panic - not syncing: Attempted to kill init! exitcode=0x00000000
> > > 
> > > Signed-off-by: Johan Hovold <johan@kernel.org>
> > > ---
> > >  arch/arm/kernel/process.c | 6 ++++++
> > >  1 file changed, 6 insertions(+)
> > > 
> > > diff --git a/arch/arm/kernel/process.c b/arch/arm/kernel/process.c
> > > index a35f6ebbd2c2..68c38af5687c 100644
> > > --- a/arch/arm/kernel/process.c
> > > +++ b/arch/arm/kernel/process.c
> > > @@ -212,6 +212,12 @@ void machine_power_off(void)
> > >  
> > >  	if (pm_power_off)
> > >  		pm_power_off();
> > > +
> > > +	/* Give a grace period for failure to power off */
> > > +	mdelay(1000);
> > > +
> > > +	pr_err("Power off failed -- system halted\n");
> > > +	while (1);
> > >  }
> > 
> > with this I always get to "Power off failed -- system halted". If I
> > switch to v3.18-rc1 vanilla, then it works. So it's definitely caused by
> > your rtc-only patches.

That's expected (see below). It works with v3.18-rc1 vanilla because
machine_halt is called instead of machine_power_off as there is no
registered power-off handler.

> ok, so it seems like it takes more than 1 second for things to
> propagate. If I increase that mdelay() to 3000, then everything works
> fine on my end. I think we should get RMK's input on this 3000ms delay
> to machine_power_off(). Should it be generic, or should we add it to our
> rtc pm_power_off implementation ?

As I wrote above, we still need a 2-second mdelay in rtc-omap, which I
intend to add to the pmic_power_en patch.

The one-second delay is there in machine_power_off to catch most cases
which wouldn't take nearly as long as rtc-omap and hence wouldn't be
adding an explicit delay in the driver power-off handler.

Johan

Re: [PATCH v2 00/20] rtc: omap: fixes and power-off feature

[Felipe Balbi]

[-- Attachment #1: Type: text/plain, Size: 5898 bytes --]

On Fri, Oct 24, 2014 at 09:36:55PM +0200, Johan Hovold wrote:
> On Fri, Oct 24, 2014 at 02:29:48PM -0500, Felipe Balbi wrote:
> > Hi,
> > 
> > On Fri, Oct 24, 2014 at 02:25:40PM -0500, Felipe Balbi wrote:
> > > On Fri, Oct 24, 2014 at 09:02:51PM +0200, Johan Hovold wrote:
> > > > [ +CC: Russell ]
> > > > 
> > > > On Fri, Oct 24, 2014 at 11:08:45AM -0500, Felipe Balbi wrote:
> > > > 
> > > > > I tested this entire series with my BBB and it still works fine. However
> > > > > I still get below panic. This time without any DRM errors:
> > > > > 
> > > > > [   63.087832] Kernel panic - not syncing: Attempted to kill init! exitcode=0x00000000
> > > > > [   63.087832] 
> > > > > [   63.097399] CPU: 0 PID: 1 Comm: systemd-shutdow Not tainted 3.18.0-rc1-00095-g8524e69 #556
> > > > > [   63.106060] [<c00175a4>] (unwind_backtrace) from [<c00132f0>] (show_stack+0x20/0x24)
> > > > > [   63.114160] [<c00132f0>] (show_stack) from [<c0657404>] (dump_stack+0x8c/0xa4)
> > > > > [   63.121706] [<c0657404>] (dump_stack) from [<c0654f70>] (panic+0xa0/0x220)
> > > > > [   63.128895] [<c0654f70>] (panic) from [<c0049e64>] (do_exit+0x974/0x9d0)
> > > > > [   63.135900] [<c0049e64>] (do_exit) from [<c006775c>] (SyS_reboot+0x14c/0x1e8)
> > > > > [   63.143361] [<c006775c>] (SyS_reboot) from [<c000f080>] (ret_fast_syscall+0x0/0x48)
> > > > > [   63.151596] ---[ end Kernel panic - not syncing: Attempted to kill init! exitcode=0x00000000
> > > > > 
> > > > > Then again, this also happens by simply calling poweroff without
> > > > > enabling wakealarm.
> > > > 
> > > > Bah, I forgot to look into that. I haven't seen this myself as I don't
> > > > use systemd (which does the syscall from process 0).
> > > > 
> > > > Some driver power-off implementations and some arch machine_power_off
> > > > spin indefinitely (or use an mdelay and WARN) after trying to power off.
> > > > 
> > > > I think this is really a bug in arch/arm that should be fixed
> > > > analogously to how failed reboot is handled in machine_restart().
> > > > 
> > > > Care to try the patch below?
> > > > 
> > > > I should still add a two-second delay to rtc-omap to avoid the arch
> > > > error message.
> > > > 
> > > > Andrew, can you update one patch in the series or should I just resend
> > > > them all (with proper Tested-by tags)?
> > > > 
> > > > > In any case, for the whole series:
> > > > > 
> > > > > Tested-by: Felipe Balbi <balbi@ti.com>
> > > > 
> > > > Thanks for testing!
> > > > 
> > > > Johan
> > > > 
> > > > 
> > > > >From aaa1d1d6171c895b6966ba5b738ac7946ada97c7 Mon Sep 17 00:00:00 2001
> > > > From: Johan Hovold <johan@kernel.org>
> > > > Date: Fri, 24 Oct 2014 18:53:09 +0200
> > > > Subject: [PATCH] ARM: fix failed power-off handling
> > > > 
> > > > Make sure to handle failed power off by printing an error message and
> > > > halting (analogously to how failed reboot is handled).
> > > > 
> > > > Power off can fail for example if the hardware has not been wired up
> > > > correctly.
> > > > 
> > > > This avoids a kernel panic when called from process 0:
> > > > 
> > > > [   63.087832] Kernel panic - not syncing: Attempted to kill init! exitcode=0x00000000
> > > > [   63.087832]
> > > > [   63.097399] CPU: 0 PID: 1 Comm: systemd-shutdow Not tainted 3.18.0-rc1-00095-g8524e69 #556
> > > > [   63.106060] [<c00175a4>] (unwind_backtrace) from [<c00132f0>] (show_stack+0x20/0x24)
> > > > [   63.114160] [<c00132f0>] (show_stack) from [<c0657404>] (dump_stack+0x8c/0xa4)
> > > > [   63.121706] [<c0657404>] (dump_stack) from [<c0654f70>] (panic+0xa0/0x220)
> > > > [   63.128895] [<c0654f70>] (panic) from [<c0049e64>] (do_exit+0x974/0x9d0)
> > > > [   63.135900] [<c0049e64>] (do_exit) from [<c006775c>] (SyS_reboot+0x14c/0x1e8)
> > > > [   63.143361] [<c006775c>] (SyS_reboot) from [<c000f080>] (ret_fast_syscall+0x0/0x48)
> > > > [   63.151596] ---[ end Kernel panic - not syncing: Attempted to kill init! exitcode=0x00000000
> > > > 
> > > > Signed-off-by: Johan Hovold <johan@kernel.org>
> > > > ---
> > > >  arch/arm/kernel/process.c | 6 ++++++
> > > >  1 file changed, 6 insertions(+)
> > > > 
> > > > diff --git a/arch/arm/kernel/process.c b/arch/arm/kernel/process.c
> > > > index a35f6ebbd2c2..68c38af5687c 100644
> > > > --- a/arch/arm/kernel/process.c
> > > > +++ b/arch/arm/kernel/process.c
> > > > @@ -212,6 +212,12 @@ void machine_power_off(void)
> > > >  
> > > >  	if (pm_power_off)
> > > >  		pm_power_off();
> > > > +
> > > > +	/* Give a grace period for failure to power off */
> > > > +	mdelay(1000);
> > > > +
> > > > +	pr_err("Power off failed -- system halted\n");
> > > > +	while (1);
> > > >  }
> > > 
> > > with this I always get to "Power off failed -- system halted". If I
> > > switch to v3.18-rc1 vanilla, then it works. So it's definitely caused by
> > > your rtc-only patches.
> 
> That's expected (see below). It works with v3.18-rc1 vanilla because
> machine_halt is called instead of machine_power_off as there is no
> registered power-off handler.

yeah, that much I figured :-)

> > ok, so it seems like it takes more than 1 second for things to
> > propagate. If I increase that mdelay() to 3000, then everything works
> > fine on my end. I think we should get RMK's input on this 3000ms delay
> > to machine_power_off(). Should it be generic, or should we add it to our
> > rtc pm_power_off implementation ?
> 
> As I wrote above, we still need a 2-second mdelay in rtc-omap, which I
> intend to add to the pmic_power_en patch.

oh, alright then. If you can Cc me, I'll make sure to test that too ;-)

> The one-second delay is there in machine_power_off to catch most cases
> which wouldn't take nearly as long as rtc-omap and hence wouldn't be
> adding an explicit delay in the driver power-off handler.

alright.

-- 
balbi

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: [PATCH v2 00/20] rtc: omap: fixes and power-off feature

[Johan Hovold]

On Fri, Oct 24, 2014 at 02:44:42PM -0500, Felipe Balbi wrote:
> On Fri, Oct 24, 2014 at 09:36:55PM +0200, Johan Hovold wrote:
> > On Fri, Oct 24, 2014 at 02:29:48PM -0500, Felipe Balbi wrote:
> > > Hi,
> > > 
> > > On Fri, Oct 24, 2014 at 02:25:40PM -0500, Felipe Balbi wrote:

> > > > with this I always get to "Power off failed -- system halted". If I
> > > > switch to v3.18-rc1 vanilla, then it works. So it's definitely caused by
> > > > your rtc-only patches.
> > 
> > That's expected (see below). It works with v3.18-rc1 vanilla because
> > machine_halt is called instead of machine_power_off as there is no
> > registered power-off handler.
> 
> yeah, that much I figured :-)
> 
> > > ok, so it seems like it takes more than 1 second for things to
> > > propagate. If I increase that mdelay() to 3000, then everything works
> > > fine on my end. I think we should get RMK's input on this 3000ms delay
> > > to machine_power_off(). Should it be generic, or should we add it to our
> > > rtc pm_power_off implementation ?
> > 
> > As I wrote above, we still need a 2-second mdelay in rtc-omap, which I
> > intend to add to the pmic_power_en patch.
> 
> oh, alright then. If you can Cc me, I'll make sure to test that too ;-)

I will. :) Just wanted to see whether Andrew preferred I resend the
whole series or just that one patch first.

The diff is minimal:

diff --git a/drivers/rtc/rtc-omap.c b/drivers/rtc/rtc-omap.c
index e74750f00b18..e4f97ad9eb21 100644
--- a/drivers/rtc/rtc-omap.c
+++ b/drivers/rtc/rtc-omap.c
@@ -423,6 +423,8 @@ static void omap_rtc_power_off(void)
        val = rtc_read(rtc, OMAP_RTC_INTERRUPTS_REG);
        rtc_writel(rtc, OMAP_RTC_INTERRUPTS_REG,
                        val | OMAP_RTC_INTERRUPTS_IT_ALARM2);
+
+       mdelay(2000);
 }

> > The one-second delay is there in machine_power_off to catch most cases
> > which wouldn't take nearly as long as rtc-omap and hence wouldn't be
> > adding an explicit delay in the driver power-off handler.
> 
> alright.

I'll call it a day now. Will keep you posted.

Thanks,
Johan

Re: [PATCH v2 00/20] rtc: omap: fixes and power-off feature

[Felipe Balbi]

[-- Attachment #1: Type: text/plain, Size: 2080 bytes --]

On Fri, Oct 24, 2014 at 09:55:32PM +0200, Johan Hovold wrote:
> On Fri, Oct 24, 2014 at 02:44:42PM -0500, Felipe Balbi wrote:
> > On Fri, Oct 24, 2014 at 09:36:55PM +0200, Johan Hovold wrote:
> > > On Fri, Oct 24, 2014 at 02:29:48PM -0500, Felipe Balbi wrote:
> > > > Hi,
> > > > 
> > > > On Fri, Oct 24, 2014 at 02:25:40PM -0500, Felipe Balbi wrote:
> 
> > > > > with this I always get to "Power off failed -- system halted". If I
> > > > > switch to v3.18-rc1 vanilla, then it works. So it's definitely caused by
> > > > > your rtc-only patches.
> > > 
> > > That's expected (see below). It works with v3.18-rc1 vanilla because
> > > machine_halt is called instead of machine_power_off as there is no
> > > registered power-off handler.
> > 
> > yeah, that much I figured :-)
> > 
> > > > ok, so it seems like it takes more than 1 second for things to
> > > > propagate. If I increase that mdelay() to 3000, then everything works
> > > > fine on my end. I think we should get RMK's input on this 3000ms delay
> > > > to machine_power_off(). Should it be generic, or should we add it to our
> > > > rtc pm_power_off implementation ?
> > > 
> > > As I wrote above, we still need a 2-second mdelay in rtc-omap, which I
> > > intend to add to the pmic_power_en patch.
> > 
> > oh, alright then. If you can Cc me, I'll make sure to test that too ;-)
> 
> I will. :) Just wanted to see whether Andrew preferred I resend the
> whole series or just that one patch first.
> 
> The diff is minimal:
> 
> diff --git a/drivers/rtc/rtc-omap.c b/drivers/rtc/rtc-omap.c
> index e74750f00b18..e4f97ad9eb21 100644
> --- a/drivers/rtc/rtc-omap.c
> +++ b/drivers/rtc/rtc-omap.c
> @@ -423,6 +423,8 @@ static void omap_rtc_power_off(void)
>         val = rtc_read(rtc, OMAP_RTC_INTERRUPTS_REG);
>         rtc_writel(rtc, OMAP_RTC_INTERRUPTS_REG,
>                         val | OMAP_RTC_INTERRUPTS_IT_ALARM2);
> +
> +       mdelay(2000);
>  }

you can add my:

Tested-by: Felipe Balbi <balbi@ti.com>

for this too. Now it's all good.

-- 
balbi

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

[PATCH v3] rtc: omap: add support for pmic_power_en

[Johan Hovold]

Add new property "ti,system-power-controller" to register the RTC as a
power-off handler.

Some RTC IP revisions can control an external PMIC via the pmic_power_en
pin, which can be configured to transition to OFF on ALARM2 events and
back to ON on subsequent ALARM (wakealarm) events.

This is based on earlier work by Colin Foe-Parker and AnilKumar Ch. [1]

[1] https://www.mail-archive.com/linux-omap@vger.kernel.org/msg82127.html

Tested-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: Johan Hovold <johan@kernel.org>
---

Changes since v2:
 - add two-second delay to allow alarm to trigger before returning

Andrew, can you replace just this patch in the series that you already
have in your tree, or do you prefer I resend the whole series (with
Felipe's Tested-by tags)?

Thanks,
Johan


 Documentation/devicetree/bindings/rtc/rtc-omap.txt |  9 +-
 drivers/rtc/rtc-omap.c                             | 95 ++++++++++++++++++++++
 2 files changed, 103 insertions(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/rtc/rtc-omap.txt b/Documentation/devicetree/bindings/rtc/rtc-omap.txt
index 5a0f02d34d95..750efd40c72e 100644
--- a/Documentation/devicetree/bindings/rtc/rtc-omap.txt
+++ b/Documentation/devicetree/bindings/rtc/rtc-omap.txt
@@ -5,11 +5,17 @@ Required properties:
 	- "ti,da830-rtc"  - for RTC IP used similar to that on DA8xx SoC family.
 	- "ti,am3352-rtc" - for RTC IP used similar to that on AM335x SoC family.
 			    This RTC IP has special WAKE-EN Register to enable
-			    Wakeup generation for event Alarm.
+			    Wakeup generation for event Alarm. It can also be
+			    used to control an external PMIC via the
+			    pmic_power_en pin.
 - reg: Address range of rtc register set
 - interrupts: rtc timer, alarm interrupts in order
 - interrupt-parent: phandle for the interrupt controller
 
+Optional properties:
+- ti,system-power-controller: whether the rtc is controlling the system power
+  through pmic_power_en
+
 Example:
 
 rtc@1c23000 {
@@ -18,4 +24,5 @@ rtc@1c23000 {
 	interrupts = <19
 		      19>;
 	interrupt-parent = <&intc>;
+	ti,system-power-controller;
 };
diff --git a/drivers/rtc/rtc-omap.c b/drivers/rtc/rtc-omap.c
index c508e45ca3ce..87cfee751554 100644
--- a/drivers/rtc/rtc-omap.c
+++ b/drivers/rtc/rtc-omap.c
@@ -68,6 +68,15 @@
 
 #define OMAP_RTC_IRQWAKEEN		0x7c
 
+#define OMAP_RTC_ALARM2_SECONDS_REG	0x80
+#define OMAP_RTC_ALARM2_MINUTES_REG	0x84
+#define OMAP_RTC_ALARM2_HOURS_REG	0x88
+#define OMAP_RTC_ALARM2_DAYS_REG	0x8c
+#define OMAP_RTC_ALARM2_MONTHS_REG	0x90
+#define OMAP_RTC_ALARM2_YEARS_REG	0x94
+
+#define OMAP_RTC_PMIC_REG		0x98
+
 /* OMAP_RTC_CTRL_REG bit fields: */
 #define OMAP_RTC_CTRL_SPLIT		BIT(7)
 #define OMAP_RTC_CTRL_DISABLE		BIT(6)
@@ -80,6 +89,7 @@
 
 /* OMAP_RTC_STATUS_REG bit fields: */
 #define OMAP_RTC_STATUS_POWER_UP	BIT(7)
+#define OMAP_RTC_STATUS_ALARM2		BIT(7)
 #define OMAP_RTC_STATUS_ALARM		BIT(6)
 #define OMAP_RTC_STATUS_1D_EVENT	BIT(5)
 #define OMAP_RTC_STATUS_1H_EVENT	BIT(4)
@@ -89,6 +99,7 @@
 #define OMAP_RTC_STATUS_BUSY		BIT(0)
 
 /* OMAP_RTC_INTERRUPTS_REG bit fields: */
+#define OMAP_RTC_INTERRUPTS_IT_ALARM2	BIT(4)
 #define OMAP_RTC_INTERRUPTS_IT_ALARM	BIT(3)
 #define OMAP_RTC_INTERRUPTS_IT_TIMER	BIT(2)
 
@@ -98,6 +109,9 @@
 /* OMAP_RTC_IRQWAKEEN bit fields: */
 #define OMAP_RTC_IRQWAKEEN_ALARM_WAKEEN	BIT(1)
 
+/* OMAP_RTC_PMIC bit fields: */
+#define OMAP_RTC_PMIC_POWER_EN_EN	BIT(16)
+
 /* OMAP_RTC_KICKER values */
 #define	KICK0_VALUE			0x83e70b13
 #define	KICK1_VALUE			0x95a4f1e0
@@ -106,6 +120,7 @@ struct omap_rtc_device_type {
 	bool has_32kclk_en;
 	bool has_kicker;
 	bool has_irqwakeen;
+	bool has_pmic_mode;
 	bool has_power_up_reset;
 };
 
@@ -115,6 +130,7 @@ struct omap_rtc {
 	int irq_alarm;
 	int irq_timer;
 	u8 interrupts_reg;
+	bool is_pmic_controller;
 	const struct omap_rtc_device_type *type;
 };
 
@@ -345,6 +361,65 @@ static int omap_rtc_set_alarm(struct device *dev, struct rtc_wkalrm *alm)
 	return 0;
 }
 
+static struct omap_rtc *omap_rtc_power_off_rtc;
+
+/*
+ * omap_rtc_poweroff: RTC-controlled power off
+ *
+ * The RTC can be used to control an external PMIC via the pmic_power_en pin,
+ * which can be configured to transition to OFF on ALARM2 events.
+ *
+ * Notes:
+ * The two-second alarm offset is the shortest offset possible as the alarm
+ * registers must be set before the next timer update and the offset
+ * calculation is too heavy for everything to be done within a single access
+ * period (~15us).
+ *
+ * Called with local interrupts disabled.
+ */
+static void omap_rtc_power_off(void)
+{
+	struct omap_rtc *rtc = omap_rtc_power_off_rtc;
+	struct rtc_time tm;
+	unsigned long now;
+	u32 val;
+
+	/* enable pmic_power_en control */
+	val = rtc_readl(rtc, OMAP_RTC_PMIC_REG);
+	rtc_writel(rtc, OMAP_RTC_PMIC_REG, val | OMAP_RTC_PMIC_POWER_EN_EN);
+
+	/* set alarm two seconds from now */
+	omap_rtc_read_time_raw(rtc, &tm);
+	bcd2tm(&tm);
+	rtc_tm_to_time(&tm, &now);
+	rtc_time_to_tm(now + 2, &tm);
+
+	if (tm2bcd(&tm) < 0) {
+		dev_err(&rtc->rtc->dev, "power off failed\n");
+		return;
+	}
+
+	rtc_wait_not_busy(rtc);
+
+	rtc_write(rtc, OMAP_RTC_ALARM2_SECONDS_REG, tm.tm_sec);
+	rtc_write(rtc, OMAP_RTC_ALARM2_MINUTES_REG, tm.tm_min);
+	rtc_write(rtc, OMAP_RTC_ALARM2_HOURS_REG, tm.tm_hour);
+	rtc_write(rtc, OMAP_RTC_ALARM2_DAYS_REG, tm.tm_mday);
+	rtc_write(rtc, OMAP_RTC_ALARM2_MONTHS_REG, tm.tm_mon);
+	rtc_write(rtc, OMAP_RTC_ALARM2_YEARS_REG, tm.tm_year);
+
+	/*
+	 * enable ALARM2 interrupt
+	 *
+	 * NOTE: this fails on AM3352 if rtc_write (writeb) is used
+	 */
+	val = rtc_read(rtc, OMAP_RTC_INTERRUPTS_REG);
+	rtc_writel(rtc, OMAP_RTC_INTERRUPTS_REG,
+			val | OMAP_RTC_INTERRUPTS_IT_ALARM2);
+
+	mdelay(2000);
+}
+
 static struct rtc_class_ops omap_rtc_ops = {
 	.read_time	= omap_rtc_read_time,
 	.set_time	= omap_rtc_set_time,
@@ -361,6 +436,7 @@ static const struct omap_rtc_device_type omap_rtc_am3352_type = {
 	.has_32kclk_en	= true,
 	.has_kicker	= true,
 	.has_irqwakeen	= true,
+	.has_pmic_mode	= true,
 };
 
 static const struct omap_rtc_device_type omap_rtc_da830_type = {
@@ -412,6 +488,9 @@ static int __init omap_rtc_probe(struct platform_device *pdev)
 	of_id = of_match_device(omap_rtc_of_match, &pdev->dev);
 	if (of_id) {
 		rtc->type = of_id->data;
+		rtc->is_pmic_controller = rtc->type->has_pmic_mode &&
+				of_property_read_bool(pdev->dev.of_node,
+						"ti,system-power-controller");
 	} else {
 		id_entry = platform_get_device_id(pdev);
 		rtc->type = (void *)id_entry->driver_data;
@@ -460,6 +539,9 @@ static int __init omap_rtc_probe(struct platform_device *pdev)
 
 	mask = OMAP_RTC_STATUS_ALARM;
 
+	if (rtc->type->has_pmic_mode)
+		mask |= OMAP_RTC_STATUS_ALARM2;
+
 	if (rtc->type->has_power_up_reset) {
 		mask |= OMAP_RTC_STATUS_POWER_UP;
 		if (reg & OMAP_RTC_STATUS_POWER_UP)
@@ -520,6 +602,13 @@ static int __init omap_rtc_probe(struct platform_device *pdev)
 			goto err;
 	}
 
+	if (rtc->is_pmic_controller) {
+		if (!pm_power_off) {
+			omap_rtc_power_off_rtc = rtc;
+			pm_power_off = omap_rtc_power_off;
+		}
+	}
+
 	return 0;
 
 err:
@@ -536,6 +625,12 @@ static int __exit omap_rtc_remove(struct platform_device *pdev)
 {
 	struct omap_rtc *rtc = platform_get_drvdata(pdev);
 
+	if (pm_power_off == omap_rtc_power_off &&
+			omap_rtc_power_off_rtc == rtc) {
+		pm_power_off = NULL;
+		omap_rtc_power_off_rtc = NULL;
+	}
+
 	device_init_wakeup(&pdev->dev, 0);
 
 	/* leave rtc running, but disable irqs */
-- 
2.0.4

Re: [PATCH v3] rtc: omap: add support for pmic_power_en

[Felipe Balbi]

[-- Attachment #1: Type: text/plain, Size: 2397 bytes --]

On Mon, Oct 27, 2014 at 09:09:28AM +0100, Johan Hovold wrote:
> Add new property "ti,system-power-controller" to register the RTC as a
> power-off handler.
> 
> Some RTC IP revisions can control an external PMIC via the pmic_power_en
> pin, which can be configured to transition to OFF on ALARM2 events and
> back to ON on subsequent ALARM (wakealarm) events.
> 
> This is based on earlier work by Colin Foe-Parker and AnilKumar Ch. [1]
> 
> [1] https://www.mail-archive.com/linux-omap@vger.kernel.org/msg82127.html
> 
> Tested-by: Felipe Balbi <balbi@ti.com>
> Signed-off-by: Johan Hovold <johan@kernel.org>
> ---
> 
> Changes since v2:
>  - add two-second delay to allow alarm to trigger before returning
> 
> Andrew, can you replace just this patch in the series that you already
> have in your tree, or do you prefer I resend the whole series (with
> Felipe's Tested-by tags)?
> 
> Thanks,
> Johan
> 
> 
>  Documentation/devicetree/bindings/rtc/rtc-omap.txt |  9 +-
>  drivers/rtc/rtc-omap.c                             | 95 ++++++++++++++++++++++
>  2 files changed, 103 insertions(+), 1 deletion(-)
> 
> diff --git a/Documentation/devicetree/bindings/rtc/rtc-omap.txt b/Documentation/devicetree/bindings/rtc/rtc-omap.txt
> index 5a0f02d34d95..750efd40c72e 100644
> --- a/Documentation/devicetree/bindings/rtc/rtc-omap.txt
> +++ b/Documentation/devicetree/bindings/rtc/rtc-omap.txt
> @@ -5,11 +5,17 @@ Required properties:
>  	- "ti,da830-rtc"  - for RTC IP used similar to that on DA8xx SoC family.
>  	- "ti,am3352-rtc" - for RTC IP used similar to that on AM335x SoC family.
>  			    This RTC IP has special WAKE-EN Register to enable
> -			    Wakeup generation for event Alarm.
> +			    Wakeup generation for event Alarm. It can also be
> +			    used to control an external PMIC via the
> +			    pmic_power_en pin.
>  - reg: Address range of rtc register set
>  - interrupts: rtc timer, alarm interrupts in order
>  - interrupt-parent: phandle for the interrupt controller
>  
> +Optional properties:
> +- ti,system-power-controller: whether the rtc is controlling the system power

isn't there a discussion going on to drop the vendor prefix ? I wonder
if we should just use the final binding to avoid supporting this for
rtc-omap too. OTOH, all of that can be hidden under
of_is_system_power_controller() itself.

-- 
balbi

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: [PATCH v3] rtc: omap: add support for pmic_power_en

[Johan Hovold]

On Mon, Oct 27, 2014 at 11:45:44AM -0500, Felipe Balbi wrote:
> On Mon, Oct 27, 2014 at 09:09:28AM +0100, Johan Hovold wrote:
> > Add new property "ti,system-power-controller" to register the RTC as a
> > power-off handler.
> > 
> > Some RTC IP revisions can control an external PMIC via the pmic_power_en
> > pin, which can be configured to transition to OFF on ALARM2 events and
> > back to ON on subsequent ALARM (wakealarm) events.
> > 
> > This is based on earlier work by Colin Foe-Parker and AnilKumar Ch. [1]
> > 
> > [1] https://www.mail-archive.com/linux-omap@vger.kernel.org/msg82127.html
> > 
> > Tested-by: Felipe Balbi <balbi@ti.com>
> > Signed-off-by: Johan Hovold <johan@kernel.org>
> > ---
> > 
> > Changes since v2:
> >  - add two-second delay to allow alarm to trigger before returning
> > 
> > Andrew, can you replace just this patch in the series that you already
> > have in your tree, or do you prefer I resend the whole series (with
> > Felipe's Tested-by tags)?
> > 
> > Thanks,
> > Johan
> > 
> > 
> >  Documentation/devicetree/bindings/rtc/rtc-omap.txt |  9 +-
> >  drivers/rtc/rtc-omap.c                             | 95 ++++++++++++++++++++++
> >  2 files changed, 103 insertions(+), 1 deletion(-)
> > 
> > diff --git a/Documentation/devicetree/bindings/rtc/rtc-omap.txt b/Documentation/devicetree/bindings/rtc/rtc-omap.txt
> > index 5a0f02d34d95..750efd40c72e 100644
> > --- a/Documentation/devicetree/bindings/rtc/rtc-omap.txt
> > +++ b/Documentation/devicetree/bindings/rtc/rtc-omap.txt
> > @@ -5,11 +5,17 @@ Required properties:
> >  	- "ti,da830-rtc"  - for RTC IP used similar to that on DA8xx SoC family.
> >  	- "ti,am3352-rtc" - for RTC IP used similar to that on AM335x SoC family.
> >  			    This RTC IP has special WAKE-EN Register to enable
> > -			    Wakeup generation for event Alarm.
> > +			    Wakeup generation for event Alarm. It can also be
> > +			    used to control an external PMIC via the
> > +			    pmic_power_en pin.
> >  - reg: Address range of rtc register set
> >  - interrupts: rtc timer, alarm interrupts in order
> >  - interrupt-parent: phandle for the interrupt controller
> >  
> > +Optional properties:
> > +- ti,system-power-controller: whether the rtc is controlling the system power
> 
> isn't there a discussion going on to drop the vendor prefix ? I wonder
> if we should just use the final binding to avoid supporting this for
> rtc-omap too. OTOH, all of that can be hidden under
> of_is_system_power_controller() itself.

Exactly, Romain intends to support both versions (i.e. with and without
the prefix) with his helper function as there are already other uses of
this variant in the wild.

As I believe I mentioned in my cover letter, I suggest simply updating
to the generic property name (i.e. use the helper and drop the prefix)
once that code has been merged. Either way, we should always be able
to change the property name before it has been used in a mainline
release (as long as we update the driver and any dts use in one commit
in order not to break bisectability).

Johan

Re: [PATCH v3] rtc: omap: add support for pmic_power_en

[Felipe Balbi]

[-- Attachment #1: Type: text/plain, Size: 3357 bytes --]

On Mon, Oct 27, 2014 at 05:56:54PM +0100, Johan Hovold wrote:
> On Mon, Oct 27, 2014 at 11:45:44AM -0500, Felipe Balbi wrote:
> > On Mon, Oct 27, 2014 at 09:09:28AM +0100, Johan Hovold wrote:
> > > Add new property "ti,system-power-controller" to register the RTC as a
> > > power-off handler.
> > > 
> > > Some RTC IP revisions can control an external PMIC via the pmic_power_en
> > > pin, which can be configured to transition to OFF on ALARM2 events and
> > > back to ON on subsequent ALARM (wakealarm) events.
> > > 
> > > This is based on earlier work by Colin Foe-Parker and AnilKumar Ch. [1]
> > > 
> > > [1] https://www.mail-archive.com/linux-omap@vger.kernel.org/msg82127.html
> > > 
> > > Tested-by: Felipe Balbi <balbi@ti.com>
> > > Signed-off-by: Johan Hovold <johan@kernel.org>
> > > ---
> > > 
> > > Changes since v2:
> > >  - add two-second delay to allow alarm to trigger before returning
> > > 
> > > Andrew, can you replace just this patch in the series that you already
> > > have in your tree, or do you prefer I resend the whole series (with
> > > Felipe's Tested-by tags)?
> > > 
> > > Thanks,
> > > Johan
> > > 
> > > 
> > >  Documentation/devicetree/bindings/rtc/rtc-omap.txt |  9 +-
> > >  drivers/rtc/rtc-omap.c                             | 95 ++++++++++++++++++++++
> > >  2 files changed, 103 insertions(+), 1 deletion(-)
> > > 
> > > diff --git a/Documentation/devicetree/bindings/rtc/rtc-omap.txt b/Documentation/devicetree/bindings/rtc/rtc-omap.txt
> > > index 5a0f02d34d95..750efd40c72e 100644
> > > --- a/Documentation/devicetree/bindings/rtc/rtc-omap.txt
> > > +++ b/Documentation/devicetree/bindings/rtc/rtc-omap.txt
> > > @@ -5,11 +5,17 @@ Required properties:
> > >  	- "ti,da830-rtc"  - for RTC IP used similar to that on DA8xx SoC family.
> > >  	- "ti,am3352-rtc" - for RTC IP used similar to that on AM335x SoC family.
> > >  			    This RTC IP has special WAKE-EN Register to enable
> > > -			    Wakeup generation for event Alarm.
> > > +			    Wakeup generation for event Alarm. It can also be
> > > +			    used to control an external PMIC via the
> > > +			    pmic_power_en pin.
> > >  - reg: Address range of rtc register set
> > >  - interrupts: rtc timer, alarm interrupts in order
> > >  - interrupt-parent: phandle for the interrupt controller
> > >  
> > > +Optional properties:
> > > +- ti,system-power-controller: whether the rtc is controlling the system power
> > 
> > isn't there a discussion going on to drop the vendor prefix ? I wonder
> > if we should just use the final binding to avoid supporting this for
> > rtc-omap too. OTOH, all of that can be hidden under
> > of_is_system_power_controller() itself.
> 
> Exactly, Romain intends to support both versions (i.e. with and without
> the prefix) with his helper function as there are already other uses of
> this variant in the wild.
> 
> As I believe I mentioned in my cover letter, I suggest simply updating
> to the generic property name (i.e. use the helper and drop the prefix)
> once that code has been merged. Either way, we should always be able
> to change the property name before it has been used in a mainline
> release (as long as we update the driver and any dts use in one commit
> in order not to break bisectability).

fine by me :-) cheers

-- 
balbi

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: [PATCH v3] rtc: omap: add support for pmic_power_en

[Andrew Morton]

On Mon, 27 Oct 2014 09:09:28 +0100 Johan Hovold <johan@kernel.org> wrote:

> Add new property "ti,system-power-controller" to register the RTC as a
> power-off handler.
> 
> Some RTC IP revisions can control an external PMIC via the pmic_power_en
> pin, which can be configured to transition to OFF on ALARM2 events and
> back to ON on subsequent ALARM (wakealarm) events.
> 
> This is based on earlier work by Colin Foe-Parker and AnilKumar Ch. [1]
> 
> [1] https://www.mail-archive.com/linux-omap@vger.kernel.org/msg82127.html
> 
> Tested-by: Felipe Balbi <balbi@ti.com>
> Signed-off-by: Johan Hovold <johan@kernel.org>
> ---
> 
> Changes since v2:
>  - add two-second delay to allow alarm to trigger before returning

hmpf.  As this sentence is below the ^--- it doesn't get into the
changelog.

> ...
>
> +static void omap_rtc_power_off(void)
> +{
> +	struct omap_rtc *rtc = omap_rtc_power_off_rtc;
> +	struct rtc_time tm;
> +	unsigned long now;
> +	u32 val;
> +
> +	/* enable pmic_power_en control */
> +	val = rtc_readl(rtc, OMAP_RTC_PMIC_REG);
> +	rtc_writel(rtc, OMAP_RTC_PMIC_REG, val | OMAP_RTC_PMIC_POWER_EN_EN);
> +
> +	/* set alarm two seconds from now */
> +	omap_rtc_read_time_raw(rtc, &tm);
> +	bcd2tm(&tm);
> +	rtc_tm_to_time(&tm, &now);
> +	rtc_time_to_tm(now + 2, &tm);
> +
> +	if (tm2bcd(&tm) < 0) {
> +		dev_err(&rtc->rtc->dev, "power off failed\n");
> +		return;
> +	}
> +
> +	rtc_wait_not_busy(rtc);
> +
> +	rtc_write(rtc, OMAP_RTC_ALARM2_SECONDS_REG, tm.tm_sec);
> +	rtc_write(rtc, OMAP_RTC_ALARM2_MINUTES_REG, tm.tm_min);
> +	rtc_write(rtc, OMAP_RTC_ALARM2_HOURS_REG, tm.tm_hour);
> +	rtc_write(rtc, OMAP_RTC_ALARM2_DAYS_REG, tm.tm_mday);
> +	rtc_write(rtc, OMAP_RTC_ALARM2_MONTHS_REG, tm.tm_mon);
> +	rtc_write(rtc, OMAP_RTC_ALARM2_YEARS_REG, tm.tm_year);
> +
> +	/*
> +	 * enable ALARM2 interrupt
> +	 *
> +	 * NOTE: this fails on AM3352 if rtc_write (writeb) is used
> +	 */
> +	val = rtc_read(rtc, OMAP_RTC_INTERRUPTS_REG);
> +	rtc_writel(rtc, OMAP_RTC_INTERRUPTS_REG,
> +			val | OMAP_RTC_INTERRUPTS_IT_ALARM2);
> +
> +	mdelay(2000);

And it is uncommented.

How on earth is a reader to know why this is here?

I can do this

--- a/drivers/rtc/rtc-omap.c~rtc-omap-add-support-for-pmic_power_en-v3-fix
+++ a/drivers/rtc/rtc-omap.c
@@ -417,6 +417,7 @@ static void omap_rtc_power_off(void)
 	rtc_writel(rtc, OMAP_RTC_INTERRUPTS_REG,
 			val | OMAP_RTC_INTERRUPTS_IT_ALARM2);
 
+	/* Allow alarm to trigger before returning */
 	mdelay(2000);
 }
 


But it doesn't explain *why* we want the alarm to trigger before
returning.

Re: [PATCH v2 00/20] rtc: omap: fixes and power-off feature

[Andrew Morton]

On Fri, 24 Oct 2014 21:55:32 +0200 Johan Hovold <johan@kernel.org> wrote:

> On Fri, Oct 24, 2014 at 02:44:42PM -0500, Felipe Balbi wrote:
> > On Fri, Oct 24, 2014 at 09:36:55PM +0200, Johan Hovold wrote:
> > > On Fri, Oct 24, 2014 at 02:29:48PM -0500, Felipe Balbi wrote:
> > > > Hi,
> > > > 
> > > > On Fri, Oct 24, 2014 at 02:25:40PM -0500, Felipe Balbi wrote:
> 
> > > > > with this I always get to "Power off failed -- system halted". If I
> > > > > switch to v3.18-rc1 vanilla, then it works. So it's definitely caused by
> > > > > your rtc-only patches.
> > > 
> > > That's expected (see below). It works with v3.18-rc1 vanilla because
> > > machine_halt is called instead of machine_power_off as there is no
> > > registered power-off handler.
> > 
> > yeah, that much I figured :-)
> > 
> > > > ok, so it seems like it takes more than 1 second for things to
> > > > propagate. If I increase that mdelay() to 3000, then everything works
> > > > fine on my end. I think we should get RMK's input on this 3000ms delay
> > > > to machine_power_off(). Should it be generic, or should we add it to our
> > > > rtc pm_power_off implementation ?
> > > 
> > > As I wrote above, we still need a 2-second mdelay in rtc-omap, which I
> > > intend to add to the pmic_power_en patch.
> > 
> > oh, alright then. If you can Cc me, I'll make sure to test that too ;-)
> 
> I will. :) Just wanted to see whether Andrew preferred I resend the
> whole series or just that one patch first.
> 
> The diff is minimal:
> 
> diff --git a/drivers/rtc/rtc-omap.c b/drivers/rtc/rtc-omap.c
> index e74750f00b18..e4f97ad9eb21 100644
> --- a/drivers/rtc/rtc-omap.c
> +++ b/drivers/rtc/rtc-omap.c
> @@ -423,6 +423,8 @@ static void omap_rtc_power_off(void)
>         val = rtc_read(rtc, OMAP_RTC_INTERRUPTS_REG);
>         rtc_writel(rtc, OMAP_RTC_INTERRUPTS_REG,
>                         val | OMAP_RTC_INTERRUPTS_IT_ALARM2);
> +
> +       mdelay(2000);
>  }

Yes, having read this threadlet: we need a very good comment in there
explaining what's going on, please.

Do we even need this delay on anything other than arm?  Or even on all arm?

Re: [PATCH v2 00/20] rtc: omap: fixes and power-off feature

[Russell King - ARM Linux]

On Mon, Oct 27, 2014 at 04:22:51PM -0700, Andrew Morton wrote:
> On Fri, 24 Oct 2014 21:55:32 +0200 Johan Hovold <johan@kernel.org> wrote:
> > I will. :) Just wanted to see whether Andrew preferred I resend the
> > whole series or just that one patch first.
> > 
> > The diff is minimal:
> > 
> > diff --git a/drivers/rtc/rtc-omap.c b/drivers/rtc/rtc-omap.c
> > index e74750f00b18..e4f97ad9eb21 100644
> > --- a/drivers/rtc/rtc-omap.c
> > +++ b/drivers/rtc/rtc-omap.c
> > @@ -423,6 +423,8 @@ static void omap_rtc_power_off(void)
> >         val = rtc_read(rtc, OMAP_RTC_INTERRUPTS_REG);
> >         rtc_writel(rtc, OMAP_RTC_INTERRUPTS_REG,
> >                         val | OMAP_RTC_INTERRUPTS_IT_ALARM2);
> > +
> > +       mdelay(2000);
> >  }
> 
> Yes, having read this threadlet: we need a very good comment in there
> explaining what's going on, please.
> 
> Do we even need this delay on anything other than arm?  Or even on all arm?

I think I've already commented on the behaviour of the reboot syscalls
such as power off which can return to userspace, pointing out that
x86 can return to userspace.

As long as x86 can return to userspace, I see no harm in ARM returning
to userspace.  If a driver which is hooking into the power off stuff
is unable to immediately shut off the power (wtf it can't for 2 sec
I've no idea) then having that driver work around that hardware's
specific brokenness with a delay seems entirely reasonable.

That allows those SoCs which can do the right thing to do the right
thing without being hindered by such silliness.  And it also stops
the next person coming along and bumping the delay from 2 to 3, to 5,
and then what... 10 seconds?

Keeping it in the driver means that the workaround for the broken
hardware is kept with the driver for the broken hardware - exactly
where it should be.

-- 
FTTC broadband for 0.8mile line: currently at 9.5Mbps down 400kbps up
according to speedtest.net.

Re: [PATCH v2 00/20] rtc: omap: fixes and power-off feature

[Johan Hovold]

On Tue, Oct 28, 2014 at 12:25:52AM +0000, Russell King - ARM Linux wrote:
> On Mon, Oct 27, 2014 at 04:22:51PM -0700, Andrew Morton wrote:
> > On Fri, 24 Oct 2014 21:55:32 +0200 Johan Hovold <johan@kernel.org> wrote:
> > > I will. :) Just wanted to see whether Andrew preferred I resend the
> > > whole series or just that one patch first.
> > > 
> > > The diff is minimal:
> > > 
> > > diff --git a/drivers/rtc/rtc-omap.c b/drivers/rtc/rtc-omap.c
> > > index e74750f00b18..e4f97ad9eb21 100644
> > > --- a/drivers/rtc/rtc-omap.c
> > > +++ b/drivers/rtc/rtc-omap.c
> > > @@ -423,6 +423,8 @@ static void omap_rtc_power_off(void)
> > >         val = rtc_read(rtc, OMAP_RTC_INTERRUPTS_REG);
> > >         rtc_writel(rtc, OMAP_RTC_INTERRUPTS_REG,
> > >                         val | OMAP_RTC_INTERRUPTS_IT_ALARM2);
> > > +
> > > +       mdelay(2000);
> > >  }
> > 
> > Yes, having read this threadlet: we need a very good comment in there
> > explaining what's going on, please.
> >
> > Do we even need this delay on anything other than arm?  Or even on all arm?
> 
> I think I've already commented on the behaviour of the reboot syscalls
> such as power off which can return to userspace, pointing out that
> x86 can return to userspace.
> 
> As long as x86 can return to userspace, I see no harm in ARM returning
> to userspace.  If a driver which is hooking into the power off stuff
> is unable to immediately shut off the power (wtf it can't for 2 sec
> I've no idea) then having that driver work around that hardware's
> specific brokenness with a delay seems entirely reasonable.

Yeah, there are two issues here. If a power-off handler is crazy slow
there really should be a delay in the handler. That was just an
oversight on my part. [ In this case it takes between one and two
seconds due to the resolution of the rtc and they way it's alarm events
are triggered. ]

The other issue is whether arch code should inform the user about failed
power-off, in really exactly the same way as it does for failed reboot,
see:

	ac15e00b1efe ("ARM: restart: move reboot failure handing into
	machine_restart()"

by Russell.

It looks like we're soon to be having power-off call chains, with
configurable priorities, to shut of various parts of the hardware and
this is all at least partly configurable through DT. [1] I think it's
reasonable to expect to see more frequent failures to power off either
due to (DT) misconfiguration or broken or flakey hardware.

Having a short delay (I proposed 1s as for reboot) would also prevent
any oopses when returning to user-space for just quite slow devices
(e.g. millisecond range) without requiring explicit delays in these
handlers.

But as Andrew points out above, this really isn't an arm-specific issue,
and currently various arches deal with this differently, where some
return to user-space, some spin indefinitely (without an error message),
and some spin on failed reboot but not power-off (e.g. arm and arm64).

> That allows those SoCs which can do the right thing to do the right
> thing without being hindered by such silliness.  And it also stops
> the next person coming along and bumping the delay from 2 to 3, to 5,
> and then what... 10 seconds?

That wouldn't be an issue then. Arch code would only handle the
non-crazy case and complete power-off failures.

> Keeping it in the driver means that the workaround for the broken
> hardware is kept with the driver for the broken hardware - exactly
> where it should be.

Agreed.

Johan

[1] https://lkml.org/lkml/2014/10/27/506

Re: [PATCH v3] rtc: omap: add support for pmic_power_en

[Johan Hovold]

On Mon, Oct 27, 2014 at 03:40:31PM -0700, Andrew Morton wrote:
> On Mon, 27 Oct 2014 09:09:28 +0100 Johan Hovold <johan@kernel.org> wrote:
> 
> > Add new property "ti,system-power-controller" to register the RTC as a
> > power-off handler.
> > 
> > Some RTC IP revisions can control an external PMIC via the pmic_power_en
> > pin, which can be configured to transition to OFF on ALARM2 events and
> > back to ON on subsequent ALARM (wakealarm) events.
> > 
> > This is based on earlier work by Colin Foe-Parker and AnilKumar Ch. [1]
> > 
> > [1] https://www.mail-archive.com/linux-omap@vger.kernel.org/msg82127.html
> > 
> > Tested-by: Felipe Balbi <balbi@ti.com>
> > Signed-off-by: Johan Hovold <johan@kernel.org>
> > ---
> > 
> > Changes since v2:
> >  - add two-second delay to allow alarm to trigger before returning
> 
> hmpf.  As this sentence is below the ^--- it doesn't get into the
> changelog.

We usually don't keep the patch-revision change log in the commit message
(e.g. put in the cover letter).

But in general, how do you want to handle updates to a single patch in a
series you already have in your tree? Do you prefer a proper
incremental-fix patch (with commit message), just an updated single
patch, or a resend of the whole series?

> > ...
> >
> > +static void omap_rtc_power_off(void)
> > +{
> > +	struct omap_rtc *rtc = omap_rtc_power_off_rtc;
> > +	struct rtc_time tm;
> > +	unsigned long now;
> > +	u32 val;
> > +
> > +	/* enable pmic_power_en control */
> > +	val = rtc_readl(rtc, OMAP_RTC_PMIC_REG);
> > +	rtc_writel(rtc, OMAP_RTC_PMIC_REG, val | OMAP_RTC_PMIC_POWER_EN_EN);
> > +
> > +	/* set alarm two seconds from now */
> > +	omap_rtc_read_time_raw(rtc, &tm);
> > +	bcd2tm(&tm);
> > +	rtc_tm_to_time(&tm, &now);
> > +	rtc_time_to_tm(now + 2, &tm);
> > +
> > +	if (tm2bcd(&tm) < 0) {
> > +		dev_err(&rtc->rtc->dev, "power off failed\n");
> > +		return;
> > +	}
> > +
> > +	rtc_wait_not_busy(rtc);
> > +
> > +	rtc_write(rtc, OMAP_RTC_ALARM2_SECONDS_REG, tm.tm_sec);
> > +	rtc_write(rtc, OMAP_RTC_ALARM2_MINUTES_REG, tm.tm_min);
> > +	rtc_write(rtc, OMAP_RTC_ALARM2_HOURS_REG, tm.tm_hour);
> > +	rtc_write(rtc, OMAP_RTC_ALARM2_DAYS_REG, tm.tm_mday);
> > +	rtc_write(rtc, OMAP_RTC_ALARM2_MONTHS_REG, tm.tm_mon);
> > +	rtc_write(rtc, OMAP_RTC_ALARM2_YEARS_REG, tm.tm_year);
> > +
> > +	/*
> > +	 * enable ALARM2 interrupt
> > +	 *
> > +	 * NOTE: this fails on AM3352 if rtc_write (writeb) is used
> > +	 */
> > +	val = rtc_read(rtc, OMAP_RTC_INTERRUPTS_REG);
> > +	rtc_writel(rtc, OMAP_RTC_INTERRUPTS_REG,
> > +			val | OMAP_RTC_INTERRUPTS_IT_ALARM2);
> > +
> > +	mdelay(2000);
> 
> And it is uncommented.
> 
> How on earth is a reader to know why this is here?

The comment above the function reads:

 * The RTC can be used to control an external PMIC via the pmic_power_en pin,
 * which can be configured to transition to OFF on ALARM2 events.
 *
 * Notes:
 * The two-second alarm offset is the shortest offset possible as the alarm
 * registers must be set before the next timer update and the offset
 * calculation is too heavy for everything to be done within a single access
 * period (~15us).

So it's effect is at least fairly obvious and documented.

> I can do this
> 
> --- a/drivers/rtc/rtc-omap.c~rtc-omap-add-support-for-pmic_power_en-v3-fix
> +++ a/drivers/rtc/rtc-omap.c
> @@ -417,6 +417,7 @@ static void omap_rtc_power_off(void)
>  	rtc_writel(rtc, OMAP_RTC_INTERRUPTS_REG,
>  			val | OMAP_RTC_INTERRUPTS_IT_ALARM2);
>  
> +	/* Allow alarm to trigger before returning */
>  	mdelay(2000);
>  }

Looks good, and I should have put something like that there nonetheless.

> But it doesn't explain *why* we want the alarm to trigger before
> returning.

Should we really require every power-off handler to document arch
behaviour (even if its inconsistent and currently undocumented); in
this case that some arches return to user-space where we may oops if
called from process 0 (e.g. systemd, but not if using sysvinit)?

Johan

Re: [PATCH v2 00/20] rtc: omap: fixes and power-off feature

[Russell King - ARM Linux]

On Tue, Oct 28, 2014 at 09:16:16AM +0100, Johan Hovold wrote:
> It looks like we're soon to be having power-off call chains, with
> configurable priorities, to shut of various parts of the hardware

I really hope that they *don't* get used like that.  I guess this is
what happens when people don't read the code before they decide to
implement something.

All the reboot/power off/halt methods already call into the driver model,
and the driver model then iterates over all bound drivers calling their
"shutdown" method.  So, today, as it has been for years, all device
drivers are notified of system power off.

That's where most device drivers should be cleanly stopping their
hardware.

The only thing which is left is the actual hardware triggering of the
action, and that should be what's done via the notifier.

-- 
FTTC broadband for 0.8mile line: currently at 9.5Mbps down 400kbps up
according to speedtest.net.

Re: [PATCH v2 00/20] rtc: omap: fixes and power-off feature

[Johan Hovold]

On Tue, Oct 28, 2014 at 08:47:46AM +0000, Russell King - ARM Linux wrote:
> On Tue, Oct 28, 2014 at 09:16:16AM +0100, Johan Hovold wrote:
> > It looks like we're soon to be having power-off call chains, with
> > configurable priorities, to shut of various parts of the hardware
> 
> I really hope that they *don't* get used like that.  I guess this is
> what happens when people don't read the code before they decide to
> implement something.
> 
> All the reboot/power off/halt methods already call into the driver model,
> and the driver model then iterates over all bound drivers calling their
> "shutdown" method.  So, today, as it has been for years, all device
> drivers are notified of system power off.
> 
> That's where most device drivers should be cleanly stopping their
> hardware.
> 
> The only thing which is left is the actual hardware triggering of the
> action, and that should be what's done via the notifier.

That's not what I was trying to refer to. But the patch set explicitly
allows for multiple, prioritised power-off handlers, which can power
off a board in different ways and with various degrees of success.
Specifically, it allows for fallback handlers in case one or more
power-off handlers fail.

So if we allow for that, what is to prevent the final power-off handler
from failing? And should this not be logged by arch code in the same way
as failure to restart is?

Johan

Re: [PATCH v2 00/20] rtc: omap: fixes and power-off feature

[Russell King - ARM Linux]

On Tue, Oct 28, 2014 at 02:12:57PM +0100, Johan Hovold wrote:
> That's not what I was trying to refer to. But the patch set explicitly
> allows for multiple, prioritised power-off handlers, which can power
> off a board in different ways and with various degrees of success.
> Specifically, it allows for fallback handlers in case one or more
> power-off handlers fail.
> 
> So if we allow for that, what is to prevent the final power-off handler
> from failing? And should this not be logged by arch code in the same way
> as failure to restart is?

And how is that different from having a set of power-off handlers, and
reporting when each individual one fails?  Don't you want to know if
your primary high priority reboot handler fails, just as much as you
want to know if your final last-resort power-off handler fails?

Or different from having no power-off handlers.

Here's the x86 code:

void machine_power_off(void)
{
        machine_ops.power_off();
}

struct machine_ops machine_ops = {
        .power_off = native_machine_power_off,
...

static void native_machine_power_off(void)
{
        if (pm_power_off) {
                if (!reboot_force)
                        machine_shutdown();
                pm_power_off();
        }
        /* A fallback in case there is no PM info available */
        tboot_shutdown(TB_SHUTDOWN_HALT);
}

void tboot_shutdown(u32 shutdown_type)
{
        void (*shutdown)(void);

        if (!tboot_enabled())
                return;

See - x86 can very well just fall straight back out of machine_power_off()
if there's no pm_power_off() hook and tboot is not enabled.

-- 
FTTC broadband for 0.8mile line: currently at 9.5Mbps down 400kbps up
according to speedtest.net.

Re: [PATCH v3] rtc: omap: add support for pmic_power_en

[Andrew Morton]

On Tue, 28 Oct 2014 09:36:33 +0100 Johan Hovold <johan@kernel.org> wrote:

> > But it doesn't explain *why* we want the alarm to trigger before
> > returning.
> 
> Should we really require every power-off handler to document arch
> behaviour (even if its inconsistent and currently undocumented); in
> this case that some arches return to user-space where we may oops if
> called from process 0 (e.g. systemd, but not if using sysvinit)?

The kernel really doesn't have a problem related to excessive amounts
of useful code comments :(

The bottom line is: did I provide a reader with the ability to
understand why the code is this way?  If "no" then improvements beckon.

This does look like one code site where an elaborate explanation is
warranted.  There's no way in which a reader can get to your above
paragraph from the current rtc-omap.c.

Re: [PATCH v2 00/20] rtc: omap: fixes and power-off feature

[Johan Hovold]

On Tue, Oct 28, 2014 at 03:16:10PM +0000, Russell King - ARM Linux wrote:
> On Tue, Oct 28, 2014 at 02:12:57PM +0100, Johan Hovold wrote:
> > That's not what I was trying to refer to. But the patch set explicitly
> > allows for multiple, prioritised power-off handlers, which can power
> > off a board in different ways and with various degrees of success.
> > Specifically, it allows for fallback handlers in case one or more
> > power-off handlers fail.
> > 
> > So if we allow for that, what is to prevent the final power-off handler
> > from failing? And should this not be logged by arch code in the same way
> > as failure to restart is?
> 
> And how is that different from having a set of power-off handlers, and
> reporting when each individual one fails?  Don't you want to know if
> your primary high priority reboot handler fails, just as much as you
> want to know if your final last-resort power-off handler fails?

Good point. Failed power-off should probably be logged by the power-off
call chain implementation (which seems to makes notifier chains a bad
fit).

And what about any power-off latencies? Should this always be dealt with
in the power-off handler?

Again, if it's predictable and high, as in the OMAP RTC case, it should
go in the handler. But what if it's just normal bus latencies
(peripheral busses, i2c, or whatever people may come up with)?

Should there always be a short delay before calling the next handler?

> Or different from having no power-off handlers.

That is actually quite different, as in that case we call machine_halt
instead (via kernel_halt).

> Here's the x86 code:
> 
> void machine_power_off(void)
> {
>         machine_ops.power_off();
> }
> 
> struct machine_ops machine_ops = {
>         .power_off = native_machine_power_off,
> ...
> 
> static void native_machine_power_off(void)
> {
>         if (pm_power_off) {
>                 if (!reboot_force)
>                         machine_shutdown();
>                 pm_power_off();
>         }
>         /* A fallback in case there is no PM info available */
>         tboot_shutdown(TB_SHUTDOWN_HALT);
> }
> 
> void tboot_shutdown(u32 shutdown_type)
> {
>         void (*shutdown)(void);
> 
>         if (!tboot_enabled())
>                 return;
> 
> See - x86 can very well just fall straight back out of machine_power_off()
> if there's no pm_power_off() hook and tboot is not enabled.

I never doubted that, but is the right thing to do? Not all arches do it
that way.

And what about the killing of init? Shall we simply consider that a
systemd bug? 

	case LINUX_REBOOT_CMD_POWER_OFF:
		kernel_power_off();
		do_exit(0);
		break;

If power-off fails (for whatever reason), do_exit(0) will trigger a
panic when called from PID 1.

Johan

Re: [PATCH v3] rtc: omap: add support for pmic_power_en

[Johan Hovold]

On Tue, Oct 28, 2014 at 02:18:05PM -0700, Andrew Morton wrote:
> On Tue, 28 Oct 2014 09:36:33 +0100 Johan Hovold <johan@kernel.org> wrote:
> 
> > > But it doesn't explain *why* we want the alarm to trigger before
> > > returning.
> > 
> > Should we really require every power-off handler to document arch
> > behaviour (even if its inconsistent and currently undocumented); in
> > this case that some arches return to user-space where we may oops if
> > called from process 0 (e.g. systemd, but not if using sysvinit)?
> 
> The kernel really doesn't have a problem related to excessive amounts
> of useful code comments :(
> 
> The bottom line is: did I provide a reader with the ability to
> understand why the code is this way?  If "no" then improvements beckon.
> 
> This does look like one code site where an elaborate explanation is
> warranted.  There's no way in which a reader can get to your above
> paragraph from the current rtc-omap.c.

I agree with you that I should add a comment on why that mdelay is
there to make it perfectly clear and obvious that it's purpose is to let
the alarm trigger, which in turn causes the pmic to power off the
system.

It is a power-off handler, and any power-off handler should not return
until it has at least attempted to power off the system. In this case,
that mandates a two-second delay.

So far, so good. I don't agree with you that every power-off handler
should document what happens if it fails to power-off the system. That
is, to describe what arches will happily return to user space, and under
what conditions (e.g. what init system is used) that this will cause a
panic.

If anything that belongs in arch code or kernel/reboot.c, and is
also something that is likely to change over time (consider the
power-off-handler call chains).

Johan

Re: [PATCH v3] rtc: omap: add support for pmic_power_en

[Johan Hovold]

On Tue, Oct 28, 2014 at 09:36:33AM +0100, Johan Hovold wrote:
> On Mon, Oct 27, 2014 at 03:40:31PM -0700, Andrew Morton wrote:
> > On Mon, 27 Oct 2014 09:09:28 +0100 Johan Hovold <johan@kernel.org> wrote:

> But in general, how do you want to handle updates to a single patch in a
> series you already have in your tree? Do you prefer a proper
> incremental-fix patch (with commit message), just an updated single
> patch, or a resend of the whole series?

How should I best send the updated patch? Can you just replace the
current three incremental patches:

	rtc-omap-add-support-for-pmic_power_en.patch
	rtc-omap-add-support-for-pmic_power_en-v3.patch
	rtc-omap-add-support-for-pmic_power_en-v3-fix.patch

that you have in your tree, with a single new v4 which adds a more
elaborate comment?

Thanks,
Johan

Re: [PATCH v2 00/20] rtc: omap: fixes and power-off feature

[Romain Perier]

Johan:. do you really plan to use this "poweroff-source" property ? As
you proposed a renaming few days ago...
I don't really want to waste time to propose patches to fix things
incrementally and rename it if the old one is used...

Romain

2014-10-29 13:34 GMT+01:00 Johan Hovold <johan@kernel.org>:
> On Tue, Oct 28, 2014 at 03:16:10PM +0000, Russell King - ARM Linux wrote:
>> On Tue, Oct 28, 2014 at 02:12:57PM +0100, Johan Hovold wrote:
>> > That's not what I was trying to refer to. But the patch set explicitly
>> > allows for multiple, prioritised power-off handlers, which can power
>> > off a board in different ways and with various degrees of success.
>> > Specifically, it allows for fallback handlers in case one or more
>> > power-off handlers fail.
>> >
>> > So if we allow for that, what is to prevent the final power-off handler
>> > from failing? And should this not be logged by arch code in the same way
>> > as failure to restart is?
>>
>> And how is that different from having a set of power-off handlers, and
>> reporting when each individual one fails?  Don't you want to know if
>> your primary high priority reboot handler fails, just as much as you
>> want to know if your final last-resort power-off handler fails?
>
> Good point. Failed power-off should probably be logged by the power-off
> call chain implementation (which seems to makes notifier chains a bad
> fit).
>
> And what about any power-off latencies? Should this always be dealt with
> in the power-off handler?
>
> Again, if it's predictable and high, as in the OMAP RTC case, it should
> go in the handler. But what if it's just normal bus latencies
> (peripheral busses, i2c, or whatever people may come up with)?
>
> Should there always be a short delay before calling the next handler?
>
>> Or different from having no power-off handlers.
>
> That is actually quite different, as in that case we call machine_halt
> instead (via kernel_halt).
>
>> Here's the x86 code:
>>
>> void machine_power_off(void)
>> {
>>         machine_ops.power_off();
>> }
>>
>> struct machine_ops machine_ops = {
>>         .power_off = native_machine_power_off,
>> ...
>>
>> static void native_machine_power_off(void)
>> {
>>         if (pm_power_off) {
>>                 if (!reboot_force)
>>                         machine_shutdown();
>>                 pm_power_off();
>>         }
>>         /* A fallback in case there is no PM info available */
>>         tboot_shutdown(TB_SHUTDOWN_HALT);
>> }
>>
>> void tboot_shutdown(u32 shutdown_type)
>> {
>>         void (*shutdown)(void);
>>
>>         if (!tboot_enabled())
>>                 return;
>>
>> See - x86 can very well just fall straight back out of machine_power_off()
>> if there's no pm_power_off() hook and tboot is not enabled.
>
> I never doubted that, but is the right thing to do? Not all arches do it
> that way.
>
> And what about the killing of init? Shall we simply consider that a
> systemd bug?
>
>         case LINUX_REBOOT_CMD_POWER_OFF:
>                 kernel_power_off();
>                 do_exit(0);
>                 break;
>
> If power-off fails (for whatever reason), do_exit(0) will trigger a
> panic when called from PID 1.
>
> Johan
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH v2 00/20] rtc: omap: fixes and power-off feature

[Johan Hovold]

[ Please do not top-post. ]

On Wed, Oct 29, 2014 at 01:55:49PM +0100, Romain Perier wrote:
> Johan:. do you really plan to use this "poweroff-source" property ? As
> you proposed a renaming few days ago...
> I don't really want to waste time to propose patches to fix things
> incrementally and rename it if the old one is used...

Why would I want to use your retracted renaming proposal for this
property (i.e. "poweroff-source")?

These patches use "ti,system-power-controller" and the vendor prefix
will be dropped when your patches have been merged.

Johan

Re: [PATCH v2 00/20] rtc: omap: fixes and power-off feature

[Russell King - ARM Linux]

On Wed, Oct 29, 2014 at 01:34:18PM +0100, Johan Hovold wrote:
> On Tue, Oct 28, 2014 at 03:16:10PM +0000, Russell King - ARM Linux wrote:
> > And how is that different from having a set of power-off handlers, and
> > reporting when each individual one fails?  Don't you want to know if
> > your primary high priority reboot handler fails, just as much as you
> > want to know if your final last-resort power-off handler fails?
> 
> Good point. Failed power-off should probably be logged by the power-off
> call chain implementation (which seems to makes notifier chains a bad
> fit).
> 
> And what about any power-off latencies? Should this always be dealt with
> in the power-off handler?
> 
> Again, if it's predictable and high, as in the OMAP RTC case, it should
> go in the handler. But what if it's just normal bus latencies
> (peripheral busses, i2c, or whatever people may come up with)?
> 
> Should there always be a short delay before calling the next handler?

If the handler has determined that it has failed, then why delay before
trying the next handler?  At the point it has decided it has failed,
surely that's after it has waited sufficient time to determine that
failure?

> > Or different from having no power-off handlers.
> 
> That is actually quite different, as in that case we call machine_halt
> instead (via kernel_halt).

Today, ARM does exactly what x86 does.  If there's no power off handler
registered, machine_power_off() shuts down other CPUs and returns.

> > Here's the x86 code:
> > 
> > void machine_power_off(void)
> > {
> >         machine_ops.power_off();
> > }
> > 
> > struct machine_ops machine_ops = {
> >         .power_off = native_machine_power_off,
> > ...
> > 
> > static void native_machine_power_off(void)
> > {
> >         if (pm_power_off) {
> >                 if (!reboot_force)
> >                         machine_shutdown();
> >                 pm_power_off();
> >         }
> >         /* A fallback in case there is no PM info available */
> >         tboot_shutdown(TB_SHUTDOWN_HALT);
> > }
> > 
> > void tboot_shutdown(u32 shutdown_type)
> > {
> >         void (*shutdown)(void);
> > 
> >         if (!tboot_enabled())
> >                 return;
> > 
> > See - x86 can very well just fall straight back out of machine_power_off()
> > if there's no pm_power_off() hook and tboot is not enabled.
> 
> I never doubted that, but is the right thing to do? Not all arches do it
> that way.

Well, the biggest question there is: if the power off or restart syscall
fails, what is the _generic_ non-architecture action which is supposed to
happen?

Whatever the answer is to that question, that action should be performed
by the _generic_ non-architecture code, rather than having the same
implementation spread across all 30 architectures which the kernel
supports today.

> And what about the killing of init? Shall we simply consider that a
> systemd bug? 
> 
> 	case LINUX_REBOOT_CMD_POWER_OFF:
> 		kernel_power_off();
> 		do_exit(0);
> 		break;
> 
> If power-off fails (for whatever reason), do_exit(0) will trigger a
> panic when called from PID 1.

Oh, systemd calls this from PID1?  I guess that's another reason to hate
systemd with vitriol.  :)  SysVinit and upstart implementations call it
from the "halt" command, which is itself normally run from a script,
which totally avoids that problem.

I'm quite sure the insane systemd lobby will scream that this is a kernel
bug and will want to change it somehow, just like they want to change the
kernel in soo many other silly ways.

-- 
FTTC broadband for 0.8mile line: currently at 9.5Mbps down 400kbps up
according to speedtest.net.

Re: [PATCH v2 00/20] rtc: omap: fixes and power-off feature

[Romain Perier]

This just to be sure, nothing more. I did read that you mentionned
"poweroff-source" earlier. However If I am wrong, my bad, everything
is fine.

2014-10-29 14:00 GMT+01:00 Johan Hovold <johan@kernel.org>:
> [ Please do not top-post. ]
>
> On Wed, Oct 29, 2014 at 01:55:49PM +0100, Romain Perier wrote:
>> Johan:. do you really plan to use this "poweroff-source" property ? As
>> you proposed a renaming few days ago...
>> I don't really want to waste time to propose patches to fix things
>> incrementally and rename it if the old one is used...
>
> Why would I want to use your retracted renaming proposal for this
> property (i.e. "poweroff-source")?
>
> These patches use "ti,system-power-controller" and the vendor prefix
> will be dropped when your patches have been merged.
>
> Johan

Re: [PATCH v2 00/20] rtc: omap: fixes and power-off feature

[Guenter Roeck]

On 10/29/2014 05:34 AM, Johan Hovold wrote:
> On Tue, Oct 28, 2014 at 03:16:10PM +0000, Russell King - ARM Linux wrote:
>> On Tue, Oct 28, 2014 at 02:12:57PM +0100, Johan Hovold wrote:
>>> That's not what I was trying to refer to. But the patch set explicitly
>>> allows for multiple, prioritised power-off handlers, which can power
>>> off a board in different ways and with various degrees of success.
>>> Specifically, it allows for fallback handlers in case one or more
>>> power-off handlers fail.
>>>
>>> So if we allow for that, what is to prevent the final power-off handler
>>> from failing? And should this not be logged by arch code in the same way
>>> as failure to restart is?
>>
>> And how is that different from having a set of power-off handlers, and
>> reporting when each individual one fails?  Don't you want to know if
>> your primary high priority reboot handler fails, just as much as you
>> want to know if your final last-resort power-off handler fails?
>
> Good point. Failed power-off should probably be logged by the power-off
> call chain implementation (which seems to makes notifier chains a bad
> fit).
>
Good that I just replaced notifier chain with an open coded implementation.
Sure, that is possible, but I would prefer to do that as a follow-up commit,
and it should be discussed in the context of the power-off handler patch set.

> And what about any power-off latencies? Should this always be dealt with
> in the power-off handler?
>
> Again, if it's predictable and high, as in the OMAP RTC case, it should
> go in the handler. But what if it's just normal bus latencies
> (peripheral busses, i2c, or whatever people may come up with)?
>
> Should there always be a short delay before calling the next handler?
>
That delay would depend on the individual power-off handler, so I think
the current implementation works just fine (where power-off handlers
implement the delay).

We could move the delay into the infrastructure, but it would have
to be configurable. I would prefer to consider that as a follow-up patch
to not overload the power-off handler patch set with too many changes
at the same time.

>> Or different from having no power-off handlers.
>
> That is actually quite different, as in that case we call machine_halt
> instead (via kernel_halt).
>
>> Here's the x86 code:
>>
>> void machine_power_off(void)
>> {
>>          machine_ops.power_off();
>> }
>>
>> struct machine_ops machine_ops = {
>>          .power_off = native_machine_power_off,
>> ...
>>
>> static void native_machine_power_off(void)
>> {
>>          if (pm_power_off) {
>>                  if (!reboot_force)
>>                          machine_shutdown();
>>                  pm_power_off();
>>          }
>>          /* A fallback in case there is no PM info available */
>>          tboot_shutdown(TB_SHUTDOWN_HALT);
>> }
>>
>> void tboot_shutdown(u32 shutdown_type)
>> {
>>          void (*shutdown)(void);
>>
>>          if (!tboot_enabled())
>>                  return;
>>
>> See - x86 can very well just fall straight back out of machine_power_off()
>> if there's no pm_power_off() hook and tboot is not enabled.
>
> I never doubted that, but is the right thing to do? Not all arches do it
> that way.
>
> And what about the killing of init? Shall we simply consider that a
> systemd bug?
>
> 	case LINUX_REBOOT_CMD_POWER_OFF:
> 		kernel_power_off();
> 		do_exit(0);
> 		break;
>
> If power-off fails (for whatever reason), do_exit(0) will trigger a
> panic when called from PID 1.
>
Common handling of that condition - eg to call machine_halt() - might be
an option. Separate patch, though.

Guenter

Re: [PATCH v2 00/20] rtc: omap: fixes and power-off feature

[Johan Hovold]

On Wed, Oct 29, 2014 at 01:10:20PM +0000, Russell King - ARM Linux wrote:
> On Wed, Oct 29, 2014 at 01:34:18PM +0100, Johan Hovold wrote:
> > On Tue, Oct 28, 2014 at 03:16:10PM +0000, Russell King - ARM Linux wrote:
> > > And how is that different from having a set of power-off handlers, and
> > > reporting when each individual one fails?  Don't you want to know if
> > > your primary high priority reboot handler fails, just as much as you
> > > want to know if your final last-resort power-off handler fails?
> > 
> > Good point. Failed power-off should probably be logged by the power-off
> > call chain implementation (which seems to makes notifier chains a bad
> > fit).
> > 
> > And what about any power-off latencies? Should this always be dealt with
> > in the power-off handler?
> > 
> > Again, if it's predictable and high, as in the OMAP RTC case, it should
> > go in the handler. But what if it's just normal bus latencies
> > (peripheral busses, i2c, or whatever people may come up with)?
> > 
> > Should there always be a short delay before calling the next handler?
> 
> If the handler has determined that it has failed, then why delay before
> trying the next handler?  At the point it has decided it has failed,
> surely that's after it has waited sufficient time to determine that
> failure?

The current handlers we have are not expecting any other handler to be
run after they return. My question was whether all these handlers should
get a short mdelay added to them (e.g. to compensate for bus latencies)
or if this could be done in the power-off handler (e.g. before printing
the error message).

> > > Or different from having no power-off handlers.
> > 
> > That is actually quite different, as in that case we call machine_halt
> > instead (via kernel_halt).
> 
> Today, ARM does exactly what x86 does.  If there's no power off handler
> registered, machine_power_off() shuts down other CPUs and returns.

No, if there are no power-off handlers registered, kernel/reboot.c will
never call machine_power_off:

	/* Instead of trying to make the power_off code look like
	 * halt when pm_power_off is not set do it the easy way.
	 */
	if ((cmd == LINUX_REBOOT_CMD_POWER_OFF) && !pm_power_off)
		cmd = LINUX_REBOOT_CMD_HALT;

So in that case on arm, a system-halted message is printed, and we never
return to user-space.

> > > Here's the x86 code:
> > > 
> > > void machine_power_off(void)
> > > {
> > >         machine_ops.power_off();
> > > }
> > > 
> > > struct machine_ops machine_ops = {
> > >         .power_off = native_machine_power_off,
> > > ...
> > > 
> > > static void native_machine_power_off(void)
> > > {
> > >         if (pm_power_off) {
> > >                 if (!reboot_force)
> > >                         machine_shutdown();
> > >                 pm_power_off();
> > >         }
> > >         /* A fallback in case there is no PM info available */
> > >         tboot_shutdown(TB_SHUTDOWN_HALT);
> > > }
> > > 
> > > void tboot_shutdown(u32 shutdown_type)
> > > {
> > >         void (*shutdown)(void);
> > > 
> > >         if (!tboot_enabled())
> > >                 return;
> > > 
> > > See - x86 can very well just fall straight back out of machine_power_off()
> > > if there's no pm_power_off() hook and tboot is not enabled.
> > 
> > I never doubted that, but is the right thing to do? Not all arches do it
> > that way.
> 
> Well, the biggest question there is: if the power off or restart syscall
> fails, what is the _generic_ non-architecture action which is supposed to
> happen?
> 
> Whatever the answer is to that question, that action should be performed
> by the _generic_ non-architecture code, rather than having the same
> implementation spread across all 30 architectures which the kernel
> supports today.

I fully agree.

> > And what about the killing of init? Shall we simply consider that a
> > systemd bug? 
> > 
> > 	case LINUX_REBOOT_CMD_POWER_OFF:
> > 		kernel_power_off();
> > 		do_exit(0);
> > 		break;
> > 
> > If power-off fails (for whatever reason), do_exit(0) will trigger a
> > panic when called from PID 1.
> 
> Oh, systemd calls this from PID1?  I guess that's another reason to hate
> systemd with vitriol.  :)  SysVinit and upstart implementations call it
> from the "halt" command, which is itself normally run from a script,
> which totally avoids that problem.

Yeah, that's why I never noticed the missing mdelay.

> I'm quite sure the insane systemd lobby will scream that this is a kernel
> bug and will want to change it somehow, just like they want to change the
> kernel in soo many other silly ways.

Will be interesting to follow. :)

Johan

Re: [PATCH v2 00/20] rtc: omap: fixes and power-off feature

[Johan Hovold]

On Wed, Oct 29, 2014 at 06:20:40AM -0700, Guenter Roeck wrote:
> On 10/29/2014 05:34 AM, Johan Hovold wrote:
> > On Tue, Oct 28, 2014 at 03:16:10PM +0000, Russell King - ARM Linux wrote:
> >> On Tue, Oct 28, 2014 at 02:12:57PM +0100, Johan Hovold wrote:
> >>> That's not what I was trying to refer to. But the patch set explicitly
> >>> allows for multiple, prioritised power-off handlers, which can power
> >>> off a board in different ways and with various degrees of success.
> >>> Specifically, it allows for fallback handlers in case one or more
> >>> power-off handlers fail.
> >>>
> >>> So if we allow for that, what is to prevent the final power-off handler
> >>> from failing? And should this not be logged by arch code in the same way
> >>> as failure to restart is?
> >>
> >> And how is that different from having a set of power-off handlers, and
> >> reporting when each individual one fails?  Don't you want to know if
> >> your primary high priority reboot handler fails, just as much as you
> >> want to know if your final last-resort power-off handler fails?
> >
> > Good point. Failed power-off should probably be logged by the power-off
> > call chain implementation (which seems to makes notifier chains a bad
> > fit).
>
> Good that I just replaced notifier chain with an open coded implementation.

Good to hear.

> Sure, that is possible, but I would prefer to do that as a follow-up commit,
> and it should be discussed in the context of the power-off handler patch set.

Fine with me.

> > And what about any power-off latencies? Should this always be dealt with
> > in the power-off handler?
> >
> > Again, if it's predictable and high, as in the OMAP RTC case, it should
> > go in the handler. But what if it's just normal bus latencies
> > (peripheral busses, i2c, or whatever people may come up with)?
> >
> > Should there always be a short delay before calling the next handler?
> 
> That delay would depend on the individual power-off handler, so I think
> the current implementation works just fine (where power-off handlers
> implement the delay).

Some don't, and could possibly unknowingly have been relying on the fact
that they could return to user space and be powered off at some later
time. With systemd that would have caused a panic.

Also consider generic power-off handlers such as gpio-poweroff. It
currently hard-codes a three-second delay but the actual delay would
really be board specific.

> We could move the delay into the infrastructure, but it would have
> to be configurable. I would prefer to consider that as a follow-up patch
> to not overload the power-off handler patch set with too many changes
> at the same time.

Sure.

Johan

Re: [PATCH v2 00/20] rtc: omap: fixes and power-off feature

[Johan Hovold]

[ Again, please stop with the top-posting.

A: http://en.wikipedia.org/wiki/Top_post
Q: Were do I find info about this thing called top-posting?

A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing? ]

On Wed, Oct 29, 2014 at 02:11:02PM +0100, Romain Perier wrote:
> This just to be sure, nothing more. I did read that you mentionned
> "poweroff-source" earlier. However If I am wrong, my bad, everything
> is fine.

I only mentioned that you had proposed that name in my cover letter.

Johan

Re: [PATCH v2 00/20] rtc: omap: fixes and power-off feature

[Guenter Roeck]

On Wed, Oct 29, 2014 at 02:22:44PM +0100, Johan Hovold wrote:
> On Wed, Oct 29, 2014 at 01:10:20PM +0000, Russell King - ARM Linux wrote:
> > On Wed, Oct 29, 2014 at 01:34:18PM +0100, Johan Hovold wrote:
> > > On Tue, Oct 28, 2014 at 03:16:10PM +0000, Russell King - ARM Linux wrote:
> > > > And how is that different from having a set of power-off handlers, and
> > > > reporting when each individual one fails?  Don't you want to know if
> > > > your primary high priority reboot handler fails, just as much as you
> > > > want to know if your final last-resort power-off handler fails?
> > > 
> > > Good point. Failed power-off should probably be logged by the power-off
> > > call chain implementation (which seems to makes notifier chains a bad
> > > fit).
> > > 
> > > And what about any power-off latencies? Should this always be dealt with
> > > in the power-off handler?
> > > 
> > > Again, if it's predictable and high, as in the OMAP RTC case, it should
> > > go in the handler. But what if it's just normal bus latencies
> > > (peripheral busses, i2c, or whatever people may come up with)?
> > > 
> > > Should there always be a short delay before calling the next handler?
> > 
> > If the handler has determined that it has failed, then why delay before
> > trying the next handler?  At the point it has decided it has failed,
> > surely that's after it has waited sufficient time to determine that
> > failure?
> 
> The current handlers we have are not expecting any other handler to be
> run after they return. My question was whether all these handlers should
> get a short mdelay added to them (e.g. to compensate for bus latencies)

Some of them do add a delay.

> or if this could be done in the power-off handler (e.g. before printing
> the error message).
> 
That might make sense, but it would have to be configurable, since the delay
is platform specific and power-off handler does not know how long to wait
(the longest delay I have seen is 10 seconds).

> > > > Or different from having no power-off handlers.
> > > 
> > > That is actually quite different, as in that case we call machine_halt
> > > instead (via kernel_halt).
> > 
> > Today, ARM does exactly what x86 does.  If there's no power off handler
> > registered, machine_power_off() shuts down other CPUs and returns.
> 
> No, if there are no power-off handlers registered, kernel/reboot.c will
> never call machine_power_off:
> 
> 	/* Instead of trying to make the power_off code look like
> 	 * halt when pm_power_off is not set do it the easy way.
> 	 */
> 	if ((cmd == LINUX_REBOOT_CMD_POWER_OFF) && !pm_power_off)
> 		cmd = LINUX_REBOOT_CMD_HALT;
> 
> So in that case on arm, a system-halted message is printed, and we never
> return to user-space.
> 
Some architectures do that, or go into an endless loop. Others do return
from machine_power_off. Having a well defined behavior would be nice
(such as dumping an error mesasge and calling machine_halt if
machine_power_off returns). Only question would be where to put it.
kernel_power_off() might be a good place; only problem is that there
are direct callers of machine_power_off().

Guenter

Re: [PATCH v2 00/20] rtc: omap: fixes and power-off feature

[Guenter Roeck]

On Wed, Oct 29, 2014 at 02:35:26PM +0100, Johan Hovold wrote:
> On Wed, Oct 29, 2014 at 06:20:40AM -0700, Guenter Roeck wrote:
> > On 10/29/2014 05:34 AM, Johan Hovold wrote:
> > > On Tue, Oct 28, 2014 at 03:16:10PM +0000, Russell King - ARM Linux wrote:
> > >> On Tue, Oct 28, 2014 at 02:12:57PM +0100, Johan Hovold wrote:
> > >>> That's not what I was trying to refer to. But the patch set explicitly
> > >>> allows for multiple, prioritised power-off handlers, which can power
> > >>> off a board in different ways and with various degrees of success.
> > >>> Specifically, it allows for fallback handlers in case one or more
> > >>> power-off handlers fail.
> > >>>
> > >>> So if we allow for that, what is to prevent the final power-off handler
> > >>> from failing? And should this not be logged by arch code in the same way
> > >>> as failure to restart is?
> > >>
> > >> And how is that different from having a set of power-off handlers, and
> > >> reporting when each individual one fails?  Don't you want to know if
> > >> your primary high priority reboot handler fails, just as much as you
> > >> want to know if your final last-resort power-off handler fails?
> > >
> > > Good point. Failed power-off should probably be logged by the power-off
> > > call chain implementation (which seems to makes notifier chains a bad
> > > fit).
> >
> > Good that I just replaced notifier chain with an open coded implementation.
> 
> Good to hear.
> 
> > Sure, that is possible, but I would prefer to do that as a follow-up commit,
> > and it should be discussed in the context of the power-off handler patch set.
> 
> Fine with me.
> 
> > > And what about any power-off latencies? Should this always be dealt with
> > > in the power-off handler?
> > >
> > > Again, if it's predictable and high, as in the OMAP RTC case, it should
> > > go in the handler. But what if it's just normal bus latencies
> > > (peripheral busses, i2c, or whatever people may come up with)?
> > >
> > > Should there always be a short delay before calling the next handler?
> > 
> > That delay would depend on the individual power-off handler, so I think
> > the current implementation works just fine (where power-off handlers
> > implement the delay).
> 
> Some don't, and could possibly unknowingly have been relying on the fact
> that they could return to user space and be powered off at some later
> time. With systemd that would have caused a panic.
> 
Agreed, but there are two cases to consider: What should be the delay
before the next power-off handler is called, and what should the system
do if all power-off handlers fail (or if there are none). The current
behavior isn't exactly well defined. Ok, with systemd that results in
a crash, but I am not really sure if one can or should blame systemd
for that. The discussion about systemd and its philosophy should not
cloud the fact that power-off behavior isn't exactly well defined.

> Also consider generic power-off handlers such as gpio-poweroff. It
> currently hard-codes a three-second delay but the actual delay would
> really be board specific.
> 
A configurable delay would address that. The actually required delay
could be provided in platform data or as devicetree property.

Thanks,
Guenter

Re: [PATCH v2 00/20] rtc: omap: fixes and power-off feature

[Johan Hovold]

On Wed, Oct 29, 2014 at 08:25:02AM -0700, Guenter Roeck wrote:
> On Wed, Oct 29, 2014 at 02:22:44PM +0100, Johan Hovold wrote:
> > On Wed, Oct 29, 2014 at 01:10:20PM +0000, Russell King - ARM Linux wrote:
> > > On Wed, Oct 29, 2014 at 01:34:18PM +0100, Johan Hovold wrote:
> > > > On Tue, Oct 28, 2014 at 03:16:10PM +0000, Russell King - ARM Linux wrote:
> > > > > And how is that different from having a set of power-off handlers, and
> > > > > reporting when each individual one fails?  Don't you want to know if
> > > > > your primary high priority reboot handler fails, just as much as you
> > > > > want to know if your final last-resort power-off handler fails?
> > > > 
> > > > Good point. Failed power-off should probably be logged by the power-off
> > > > call chain implementation (which seems to makes notifier chains a bad
> > > > fit).
> > > > 
> > > > And what about any power-off latencies? Should this always be dealt with
> > > > in the power-off handler?
> > > > 
> > > > Again, if it's predictable and high, as in the OMAP RTC case, it should
> > > > go in the handler. But what if it's just normal bus latencies
> > > > (peripheral busses, i2c, or whatever people may come up with)?
> > > > 
> > > > Should there always be a short delay before calling the next handler?
> > > 
> > > If the handler has determined that it has failed, then why delay before
> > > trying the next handler?  At the point it has decided it has failed,
> > > surely that's after it has waited sufficient time to determine that
> > > failure?
> > 
> > The current handlers we have are not expecting any other handler to be
> > run after they return. My question was whether all these handlers should
> > get a short mdelay added to them (e.g. to compensate for bus latencies)
> 
> Some of them do add a delay.

Yes, but not all.

> > or if this could be done in the power-off handler (e.g. before printing
> > the error message).
> > 
> That might make sense, but it would have to be configurable, since the delay
> is platform specific and power-off handler does not know how long to wait
> (the longest delay I have seen is 10 seconds).

We've already concluded in this thread that such delays must be encoded
in the actual handler (even if it's an argument to the power-off call
chain code). The only exception should be generic handlers such as
gpio-poweroff, which may need to define different delays depending on
board. This could of course just be an argument of the corresponding DT
node.

My question above was if it was reasonable to add some generic short
delay after calling each power-off handler to handle short power-off
latencies (e.g. bus latencies) so that not every handler needs an
explicit delay.

> > > > > Or different from having no power-off handlers.
> > > > 
> > > > That is actually quite different, as in that case we call machine_halt
> > > > instead (via kernel_halt).
> > > 
> > > Today, ARM does exactly what x86 does.  If there's no power off handler
> > > registered, machine_power_off() shuts down other CPUs and returns.
> > 
> > No, if there are no power-off handlers registered, kernel/reboot.c will
> > never call machine_power_off:
> > 
> > 	/* Instead of trying to make the power_off code look like
> > 	 * halt when pm_power_off is not set do it the easy way.
> > 	 */
> > 	if ((cmd == LINUX_REBOOT_CMD_POWER_OFF) && !pm_power_off)
> > 		cmd = LINUX_REBOOT_CMD_HALT;
> > 
> > So in that case on arm, a system-halted message is printed, and we never
> > return to user-space.
> > 
> Some architectures do that, or go into an endless loop. Others do return
> from machine_power_off.

Please re-read my comment and the code above. machine_power_off is never
called if there's no handler registered.

Some archs machine_power_off to spin on failed power-off (i.e. when
there is a handler), something which I've mentioned a few times already
in this thread.

> Having a well defined behavior would be nice
> (such as dumping an error mesasge and calling machine_halt if
> machine_power_off returns). Only question would be where to put it.
> kernel_power_off() might be a good place; only problem is that there
> are direct callers of machine_power_off().

Indeed. Adding an error message to the power-off handler call chain code
would solve the first problem as I mentioned before.

Then it's mostly a matter of whether we care about consistency, and
either remove the indefinite spins from those non-x86/non-arm arches, or
prevent the latter (and some others) from returning to user-space.

I'm inclined to having all arches return to user space on failed
power-off, even if it means systemd cannot call reboot() from PID 1.

Johan

Re: [PATCH v2 00/20] rtc: omap: fixes and power-off feature

[Johan Hovold]

On Wed, Oct 29, 2014 at 08:36:41AM -0700, Guenter Roeck wrote:
> On Wed, Oct 29, 2014 at 02:35:26PM +0100, Johan Hovold wrote:
> > On Wed, Oct 29, 2014 at 06:20:40AM -0700, Guenter Roeck wrote:
> > > On 10/29/2014 05:34 AM, Johan Hovold wrote:

> > > > And what about any power-off latencies? Should this always be dealt with
> > > > in the power-off handler?
> > > >
> > > > Again, if it's predictable and high, as in the OMAP RTC case, it should
> > > > go in the handler. But what if it's just normal bus latencies
> > > > (peripheral busses, i2c, or whatever people may come up with)?
> > > >
> > > > Should there always be a short delay before calling the next handler?
> > > 
> > > That delay would depend on the individual power-off handler, so I think
> > > the current implementation works just fine (where power-off handlers
> > > implement the delay).
> > 
> > Some don't, and could possibly unknowingly have been relying on the fact
> > that they could return to user space and be powered off at some later
> > time. With systemd that would have caused a panic.
>
> Agreed, but there are two cases to consider: What should be the delay
> before the next power-off handler is called, and what should the system
> do if all power-off handlers fail (or if there are none). The current
> behavior isn't exactly well defined. Ok, with systemd that results in
> a crash, but I am not really sure if one can or should blame systemd
> for that. The discussion about systemd and its philosophy should not
> cloud the fact that power-off behavior isn't exactly well defined.

Sounds like we pretty much agree. See my response to your last mail.

> > Also consider generic power-off handlers such as gpio-poweroff. It
> > currently hard-codes a three-second delay but the actual delay would
> > really be board specific.
> > 
> A configurable delay would address that. The actually required delay
> could be provided in platform data or as devicetree property.

Yep, see mail mentioned above.

Johan

Re: [PATCH v3] rtc: omap: add support for pmic_power_en

[Andrew Morton]

On Wed, 29 Oct 2014 13:50:05 +0100 Johan Hovold <johan@kernel.org> wrote:

> On Tue, Oct 28, 2014 at 09:36:33AM +0100, Johan Hovold wrote:
> > On Mon, Oct 27, 2014 at 03:40:31PM -0700, Andrew Morton wrote:
> > > On Mon, 27 Oct 2014 09:09:28 +0100 Johan Hovold <johan@kernel.org> wrote:
> 
> > But in general, how do you want to handle updates to a single patch in a
> > series you already have in your tree? Do you prefer a proper
> > incremental-fix patch (with commit message), just an updated single
> > patch, or a resend of the whole series?
> 
> How should I best send the updated patch? Can you just replace the
> current three incremental patches:
> 
> 	rtc-omap-add-support-for-pmic_power_en.patch
> 	rtc-omap-add-support-for-pmic_power_en-v3.patch
> 	rtc-omap-add-support-for-pmic_power_en-v3-fix.patch
> 
> that you have in your tree, with a single new v4 which adds a more
> elaborate comment?

Yep, that works.  I'll almost always turn the new patch into an
incremental, mainly so that I (and others) can see what was changed.

[PATCH v4] rtc: omap: add support for pmic_power_en

[Johan Hovold]

Add new property "ti,system-power-controller" to register the RTC as a
power-off handler.

Some RTC IP revisions can control an external PMIC via the pmic_power_en
pin, which can be configured to transition to OFF on ALARM2 events and
back to ON on subsequent ALARM (wakealarm) events.

This is based on earlier work by Colin Foe-Parker and AnilKumar Ch. [1]

[1] https://www.mail-archive.com/linux-omap@vger.kernel.org/msg82127.html

Tested-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: Johan Hovold <johan@kernel.org>
---

Here's an updated patch, which adds a comment on why there is a delay
after activating the alarm.

Note that I also increased the delay to include a margin for external
latencies. For example, on Beaglebone Black, the PMIC has a 50ms
deglitch time on the PWR_EN pin (which is connected to pmic_power_en).

Such margins should probably eventually be specified through device
tree, for instance, as an attribute to accompany the
system-power-controller attribute and be handled by the power-off call
chain infrastructure.

Johan


Changes since v3:
 - increase the delay when waiting for power-off to include a 500ms
   margin for external latencies (e.g. debounce circuits)
 - add comment on why that delay is there
 - add a space to one comment

Changes since v2:
 - add two-second delay to allow alarm to trigger before returning


 Documentation/devicetree/bindings/rtc/rtc-omap.txt |   9 +-
 drivers/rtc/rtc-omap.c                             | 100 +++++++++++++++++++++
 2 files changed, 108 insertions(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/rtc/rtc-omap.txt b/Documentation/devicetree/bindings/rtc/rtc-omap.txt
index 5a0f02d34d95..750efd40c72e 100644
--- a/Documentation/devicetree/bindings/rtc/rtc-omap.txt
+++ b/Documentation/devicetree/bindings/rtc/rtc-omap.txt
@@ -5,11 +5,17 @@ Required properties:
 	- "ti,da830-rtc"  - for RTC IP used similar to that on DA8xx SoC family.
 	- "ti,am3352-rtc" - for RTC IP used similar to that on AM335x SoC family.
 			    This RTC IP has special WAKE-EN Register to enable
-			    Wakeup generation for event Alarm.
+			    Wakeup generation for event Alarm. It can also be
+			    used to control an external PMIC via the
+			    pmic_power_en pin.
 - reg: Address range of rtc register set
 - interrupts: rtc timer, alarm interrupts in order
 - interrupt-parent: phandle for the interrupt controller
 
+Optional properties:
+- ti,system-power-controller: whether the rtc is controlling the system power
+  through pmic_power_en
+
 Example:
 
 rtc@1c23000 {
@@ -18,4 +24,5 @@ rtc@1c23000 {
 	interrupts = <19
 		      19>;
 	interrupt-parent = <&intc>;
+	ti,system-power-controller;
 };
diff --git a/drivers/rtc/rtc-omap.c b/drivers/rtc/rtc-omap.c
index c508e45ca3ce..e83f51ae7f63 100644
--- a/drivers/rtc/rtc-omap.c
+++ b/drivers/rtc/rtc-omap.c
@@ -68,6 +68,15 @@
 
 #define OMAP_RTC_IRQWAKEEN		0x7c
 
+#define OMAP_RTC_ALARM2_SECONDS_REG	0x80
+#define OMAP_RTC_ALARM2_MINUTES_REG	0x84
+#define OMAP_RTC_ALARM2_HOURS_REG	0x88
+#define OMAP_RTC_ALARM2_DAYS_REG	0x8c
+#define OMAP_RTC_ALARM2_MONTHS_REG	0x90
+#define OMAP_RTC_ALARM2_YEARS_REG	0x94
+
+#define OMAP_RTC_PMIC_REG		0x98
+
 /* OMAP_RTC_CTRL_REG bit fields: */
 #define OMAP_RTC_CTRL_SPLIT		BIT(7)
 #define OMAP_RTC_CTRL_DISABLE		BIT(6)
@@ -80,6 +89,7 @@
 
 /* OMAP_RTC_STATUS_REG bit fields: */
 #define OMAP_RTC_STATUS_POWER_UP	BIT(7)
+#define OMAP_RTC_STATUS_ALARM2		BIT(7)
 #define OMAP_RTC_STATUS_ALARM		BIT(6)
 #define OMAP_RTC_STATUS_1D_EVENT	BIT(5)
 #define OMAP_RTC_STATUS_1H_EVENT	BIT(4)
@@ -89,6 +99,7 @@
 #define OMAP_RTC_STATUS_BUSY		BIT(0)
 
 /* OMAP_RTC_INTERRUPTS_REG bit fields: */
+#define OMAP_RTC_INTERRUPTS_IT_ALARM2	BIT(4)
 #define OMAP_RTC_INTERRUPTS_IT_ALARM	BIT(3)
 #define OMAP_RTC_INTERRUPTS_IT_TIMER	BIT(2)
 
@@ -98,6 +109,9 @@
 /* OMAP_RTC_IRQWAKEEN bit fields: */
 #define OMAP_RTC_IRQWAKEEN_ALARM_WAKEEN	BIT(1)
 
+/* OMAP_RTC_PMIC bit fields: */
+#define OMAP_RTC_PMIC_POWER_EN_EN	BIT(16)
+
 /* OMAP_RTC_KICKER values */
 #define	KICK0_VALUE			0x83e70b13
 #define	KICK1_VALUE			0x95a4f1e0
@@ -106,6 +120,7 @@ struct omap_rtc_device_type {
 	bool has_32kclk_en;
 	bool has_kicker;
 	bool has_irqwakeen;
+	bool has_pmic_mode;
 	bool has_power_up_reset;
 };
 
@@ -115,6 +130,7 @@ struct omap_rtc {
 	int irq_alarm;
 	int irq_timer;
 	u8 interrupts_reg;
+	bool is_pmic_controller;
 	const struct omap_rtc_device_type *type;
 };
 
@@ -345,6 +361,70 @@ static int omap_rtc_set_alarm(struct device *dev, struct rtc_wkalrm *alm)
 	return 0;
 }
 
+static struct omap_rtc *omap_rtc_power_off_rtc;
+
+/*
+ * omap_rtc_poweroff: RTC-controlled power off
+ *
+ * The RTC can be used to control an external PMIC via the pmic_power_en pin,
+ * which can be configured to transition to OFF on ALARM2 events.
+ *
+ * Notes:
+ * The two-second alarm offset is the shortest offset possible as the alarm
+ * registers must be set before the next timer update and the offset
+ * calculation is too heavy for everything to be done within a single access
+ * period (~15 us).
+ *
+ * Called with local interrupts disabled.
+ */
+static void omap_rtc_power_off(void)
+{
+	struct omap_rtc *rtc = omap_rtc_power_off_rtc;
+	struct rtc_time tm;
+	unsigned long now;
+	u32 val;
+
+	/* enable pmic_power_en control */
+	val = rtc_readl(rtc, OMAP_RTC_PMIC_REG);
+	rtc_writel(rtc, OMAP_RTC_PMIC_REG, val | OMAP_RTC_PMIC_POWER_EN_EN);
+
+	/* set alarm two seconds from now */
+	omap_rtc_read_time_raw(rtc, &tm);
+	bcd2tm(&tm);
+	rtc_tm_to_time(&tm, &now);
+	rtc_time_to_tm(now + 2, &tm);
+
+	if (tm2bcd(&tm) < 0) {
+		dev_err(&rtc->rtc->dev, "power off failed\n");
+		return;
+	}
+
+	rtc_wait_not_busy(rtc);
+
+	rtc_write(rtc, OMAP_RTC_ALARM2_SECONDS_REG, tm.tm_sec);
+	rtc_write(rtc, OMAP_RTC_ALARM2_MINUTES_REG, tm.tm_min);
+	rtc_write(rtc, OMAP_RTC_ALARM2_HOURS_REG, tm.tm_hour);
+	rtc_write(rtc, OMAP_RTC_ALARM2_DAYS_REG, tm.tm_mday);
+	rtc_write(rtc, OMAP_RTC_ALARM2_MONTHS_REG, tm.tm_mon);
+	rtc_write(rtc, OMAP_RTC_ALARM2_YEARS_REG, tm.tm_year);
+
+	/*
+	 * enable ALARM2 interrupt
+	 *
+	 * NOTE: this fails on AM3352 if rtc_write (writeb) is used
+	 */
+	val = rtc_read(rtc, OMAP_RTC_INTERRUPTS_REG);
+	rtc_writel(rtc, OMAP_RTC_INTERRUPTS_REG,
+			val | OMAP_RTC_INTERRUPTS_IT_ALARM2);
+
+	/*
+	 * Wait for alarm to trigger (within two seconds) and external PMIC to
+	 * power off the system. Add a 500 ms margin for external latencies
+	 * (e.g. debounce circuits).
+	 */
+	mdelay(2500);
+}
+
 static struct rtc_class_ops omap_rtc_ops = {
 	.read_time	= omap_rtc_read_time,
 	.set_time	= omap_rtc_set_time,
@@ -361,6 +441,7 @@ static const struct omap_rtc_device_type omap_rtc_am3352_type = {
 	.has_32kclk_en	= true,
 	.has_kicker	= true,
 	.has_irqwakeen	= true,
+	.has_pmic_mode	= true,
 };
 
 static const struct omap_rtc_device_type omap_rtc_da830_type = {
@@ -412,6 +493,9 @@ static int __init omap_rtc_probe(struct platform_device *pdev)
 	of_id = of_match_device(omap_rtc_of_match, &pdev->dev);
 	if (of_id) {
 		rtc->type = of_id->data;
+		rtc->is_pmic_controller = rtc->type->has_pmic_mode &&
+				of_property_read_bool(pdev->dev.of_node,
+						"ti,system-power-controller");
 	} else {
 		id_entry = platform_get_device_id(pdev);
 		rtc->type = (void *)id_entry->driver_data;
@@ -460,6 +544,9 @@ static int __init omap_rtc_probe(struct platform_device *pdev)
 
 	mask = OMAP_RTC_STATUS_ALARM;
 
+	if (rtc->type->has_pmic_mode)
+		mask |= OMAP_RTC_STATUS_ALARM2;
+
 	if (rtc->type->has_power_up_reset) {
 		mask |= OMAP_RTC_STATUS_POWER_UP;
 		if (reg & OMAP_RTC_STATUS_POWER_UP)
@@ -520,6 +607,13 @@ static int __init omap_rtc_probe(struct platform_device *pdev)
 			goto err;
 	}
 
+	if (rtc->is_pmic_controller) {
+		if (!pm_power_off) {
+			omap_rtc_power_off_rtc = rtc;
+			pm_power_off = omap_rtc_power_off;
+		}
+	}
+
 	return 0;
 
 err:
@@ -536,6 +630,12 @@ static int __exit omap_rtc_remove(struct platform_device *pdev)
 {
 	struct omap_rtc *rtc = platform_get_drvdata(pdev);
 
+	if (pm_power_off == omap_rtc_power_off &&
+			omap_rtc_power_off_rtc == rtc) {
+		pm_power_off = NULL;
+		omap_rtc_power_off_rtc = NULL;
+	}
+
 	device_init_wakeup(&pdev->dev, 0);
 
 	/* leave rtc running, but disable irqs */
-- 
2.0.4

Re: [PATCH v2 00/20] rtc: omap: fixes and power-off feature

[Johan Hovold]

On Wed, Oct 29, 2014 at 04:51:09PM +0100, Johan Hovold wrote:
> On Wed, Oct 29, 2014 at 08:25:02AM -0700, Guenter Roeck wrote:
> > On Wed, Oct 29, 2014 at 02:22:44PM +0100, Johan Hovold wrote:
> > > On Wed, Oct 29, 2014 at 01:10:20PM +0000, Russell King - ARM Linux wrote:
> > > > On Wed, Oct 29, 2014 at 01:34:18PM +0100, Johan Hovold wrote:
> > > > > On Tue, Oct 28, 2014 at 03:16:10PM +0000, Russell King - ARM Linux wrote:
> > > > > > And how is that different from having a set of power-off handlers, and
> > > > > > reporting when each individual one fails?  Don't you want to know if
> > > > > > your primary high priority reboot handler fails, just as much as you
> > > > > > want to know if your final last-resort power-off handler fails?
> > > > > 
> > > > > Good point. Failed power-off should probably be logged by the power-off
> > > > > call chain implementation (which seems to makes notifier chains a bad
> > > > > fit).
> > > > > 
> > > > > And what about any power-off latencies? Should this always be dealt with
> > > > > in the power-off handler?
> > > > > 
> > > > > Again, if it's predictable and high, as in the OMAP RTC case, it should
> > > > > go in the handler. But what if it's just normal bus latencies
> > > > > (peripheral busses, i2c, or whatever people may come up with)?
> > > > > 
> > > > > Should there always be a short delay before calling the next handler?
> > > > 
> > > > If the handler has determined that it has failed, then why delay before
> > > > trying the next handler?  At the point it has decided it has failed,
> > > > surely that's after it has waited sufficient time to determine that
> > > > failure?
> > > 
> > > The current handlers we have are not expecting any other handler to be
> > > run after they return. My question was whether all these handlers should
> > > get a short mdelay added to them (e.g. to compensate for bus latencies)
> > 
> > Some of them do add a delay.
> 
> Yes, but not all.
> 
> > > or if this could be done in the power-off handler (e.g. before printing
> > > the error message).
> > > 
> > That might make sense, but it would have to be configurable, since the delay
> > is platform specific and power-off handler does not know how long to wait
> > (the longest delay I have seen is 10 seconds).
> 
> We've already concluded in this thread that such delays must be encoded
> in the actual handler (even if it's an argument to the power-off call
> chain code). The only exception should be generic handlers such as
> gpio-poweroff, which may need to define different delays depending on
> board. This could of course just be an argument of the corresponding DT
> node.

There probably should be a generic device-tree property for this, even
if some delays would be device specific (e.g. the two second delay for
omap rtc).

But on top of that, external latencies would be quite board specific.
The PMIC on the Beaglebone black adds a 50ms deglitch time, for
instance.

> My question above was if it was reasonable to add some generic short
> delay after calling each power-off handler to handle short power-off
> latencies (e.g. bus latencies) so that not every handler needs an
> explicit delay.

I just added a 500ms margin to the OMAP rtc power-off handler. That
should be more than enough, and perhaps something like that could be a
default in the power-off call chain. Consider that arch-arm has a 1s
grace period before reporting failed reboot already today.

Johan