[PATCH 0/5] AM437x: Add rtc-only + DDR mode support

[PATCH 0/5] AM437x: Add rtc-only + DDR mode support

[Keerthy]

RTC plus DDR in self-refresh is power a saving mode where in the entire
system including the different voltage rails from PMIC are shutdown except
the ones feeding on to RTC and DDR. DDR is kept in self-refresh hence the
contents are preserved. RTC ALARM2 is connected to PMIC_EN line once
we the ALARM2 is triggered we enter the mode with DDR in self-refresh
and RTC Ticking. After a predetermined time an RTC ALARM1 triggers waking
up the system. The control goes to bootloader. The bootloader then checks
RTC scratchpad registers to confirm it was an rtc_only wakeup and follows
a different path, configure bare minimal clocks for ddr and then jumps to
the resume address in another RTC scratchpad registers and transfers the
control to Kernel. Kernel then restores the saved context.

The patch series adds rtc-only + DDR mode support am am437x
Tested DS0, rtc+ddr back and forth on am437x-gp-evm board.

This mode works only with u-boot built with am43xx_evm_rtconly_defconfig

Additional patch is needed for omap-gpio save restore which will
come as fixes later.

Keerthy (5):
  rtc: OMAP: Add support for rtc-only mode
  rtc: interface: Add power_off_program to rtc_class_ops
  arm: mach-omap2: pm33xx: Add support for rtc+ddr in self refresh mode
  soc: ti: pm33xx: Push the am33xx_push_sram_idle to the top
  soc: ti: pm33xx: AM437X: Add rtc_only with ddr in self-refresh support

 arch/arm/mach-omap2/pm33xx-core.c    |  76 +++++++-
 drivers/rtc/interface.c              |  12 ++
 drivers/rtc/rtc-omap.c               |  49 ++++-
 drivers/soc/ti/Kconfig               |   5 +-
 drivers/soc/ti/pm33xx.c              | 272 ++++++++++++++++++++++-----
 include/linux/platform_data/pm33xx.h |   5 +
 include/linux/rtc.h                  |   2 +
 7 files changed, 360 insertions(+), 61 deletions(-)

-- 
2.17.1

[PATCH 1/5] rtc: OMAP: Add support for rtc-only mode

[Keerthy]

Prepare rtc driver for rtc-only with DDR in self-refresh mode.
omap_rtc_power_off now should cater to two features:

1) RTC plus DDR in self-refresh is power a saving mode where in the
entire system including the different voltage rails from PMIC are
shutdown except the ones feeding on to RTC and DDR. DDR is kept in
self-refresh hence the contents are preserved. RTC ALARM2 is connected
to PMIC_EN line once we the ALARM2 is triggered we enter the mode with
DDR in self-refresh and RTC Ticking. After a predetermined time an RTC
ALARM1 triggers waking up the system[1]. The control goes to bootloader.
The bootloader then checks RTC scratchpad registers to confirm it was an
rtc_only wakeup and follows a different path, configure bare minimal
clocks for ddr and then jumps to the resume address in another RTC
scratchpad registers and transfers the control to Kernel. Kernel then
restores the saved context. omap_rtc_power_off_program does the ALARM2
programming part.

     [1] http://www.ti.com/lit/ug/spruhl7h/spruhl7h.pdf Page 2884

2) Power-off: This is usual poweroff mode. omap_rtc_power_off calls the
above omap_rtc_power_off_program function and in addition to that
programs the OMAP_RTC_PMIC_REG for any external wake ups for PMIC like
the pushbutton and shuts off the PMIC.

Hence the split in omap_rtc_power_off.

Signed-off-by: Keerthy <j-keerthy@ti.com>
---
 drivers/rtc/rtc-omap.c | 48 +++++++++++++++++++++++++++++++++++-------
 1 file changed, 40 insertions(+), 8 deletions(-)

diff --git a/drivers/rtc/rtc-omap.c b/drivers/rtc/rtc-omap.c
index 2f28e21ee016..9b58c933e37d 100644
--- a/drivers/rtc/rtc-omap.c
+++ b/drivers/rtc/rtc-omap.c
@@ -407,15 +407,12 @@ static int omap_rtc_set_alarm(struct device *dev, struct rtc_wkalrm *alm)
 
 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.
- *
- * Called with local interrupts disabled.
+/**
+ * omap_rtc_power_off_program: Set the pmic power off sequence. The RTC
+ * generates pmic_pwr_enable control, which can be used to control an external
+ * PMIC.
  */
-static void omap_rtc_power_off(void)
+static int omap_rtc_power_off_program(struct device *dev)
 {
 	struct omap_rtc *rtc = omap_rtc_power_off_rtc;
 	struct rtc_time tm;
@@ -429,6 +426,9 @@ static void omap_rtc_power_off(void)
 	rtc_writel(rtc, OMAP_RTC_PMIC_REG, val | OMAP_RTC_PMIC_POWER_EN_EN);
 
 again:
+	/* Clear any existing ALARM2 event */
+	rtc_writel(rtc, OMAP_RTC_STATUS_REG, OMAP_RTC_STATUS_ALARM2);
+
 	/* set alarm one second from now */
 	omap_rtc_read_time_raw(rtc, &tm);
 	seconds = tm.tm_sec;
@@ -465,6 +465,38 @@ static void omap_rtc_power_off(void)
 
 	rtc->type->lock(rtc);
 
+	return 0;
+}
+
+/*
+ * 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 one-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 rtc_device *rtc = omap_rtc_power_off_rtc->rtc;
+	u32 val;
+
+	omap_rtc_power_off_program(rtc->dev.parent);
+
+	/* Set PMIC power enable and EXT_WAKEUP in case PB power on is used */
+	omap_rtc_power_off_rtc->type->unlock(omap_rtc_power_off_rtc);
+	val = rtc_readl(omap_rtc_power_off_rtc, OMAP_RTC_PMIC_REG);
+	val |= OMAP_RTC_PMIC_POWER_EN_EN | OMAP_RTC_PMIC_EXT_WKUP_POL(0) |
+			OMAP_RTC_PMIC_EXT_WKUP_EN(0);
+	rtc_writel(omap_rtc_power_off_rtc, OMAP_RTC_PMIC_REG, val);
+	omap_rtc_power_off_rtc->type->lock(omap_rtc_power_off_rtc);
+
 	/*
 	 * Wait for alarm to trigger (within one second) and external PMIC to
 	 * power off the system. Add a 500 ms margin for external latencies
-- 
2.17.1

[PATCH 2/5] rtc: interface: Add power_off_program to rtc_class_ops

[Keerthy]

Add an interface function to set up the rtc for a power_off
mode.

Signed-off-by: Keerthy <j-keerthy@ti.com>
---
 drivers/rtc/interface.c | 12 ++++++++++++
 drivers/rtc/rtc-omap.c  |  1 +
 include/linux/rtc.h     |  2 ++
 3 files changed, 15 insertions(+)

diff --git a/drivers/rtc/interface.c b/drivers/rtc/interface.c
index 28bd767e03a0..3a9141ceb365 100644
--- a/drivers/rtc/interface.c
+++ b/drivers/rtc/interface.c
@@ -1065,3 +1065,15 @@ int rtc_set_offset(struct rtc_device *rtc, long offset)
 	trace_rtc_set_offset(offset, ret);
 	return ret;
 }
+
+/**
+ * rtc_power_off_program - Some of the rtc are hooked on to PMIC_EN
+ * line and can be used to power off the SoC.
+ *
+ * Kernel interface to program rtc to power off
+ */
+int rtc_power_off_program(struct rtc_device *rtc)
+{
+	return rtc->ops->power_off_program(rtc->dev.parent);
+}
+EXPORT_SYMBOL_GPL(rtc_power_off_program);
diff --git a/drivers/rtc/rtc-omap.c b/drivers/rtc/rtc-omap.c
index 9b58c933e37d..74cd391eeef7 100644
--- a/drivers/rtc/rtc-omap.c
+++ b/drivers/rtc/rtc-omap.c
@@ -511,6 +511,7 @@ static const struct rtc_class_ops omap_rtc_ops = {
 	.read_alarm	= omap_rtc_read_alarm,
 	.set_alarm	= omap_rtc_set_alarm,
 	.alarm_irq_enable = omap_rtc_alarm_irq_enable,
+	.power_off_program = omap_rtc_power_off_program,
 };
 
 static const struct omap_rtc_device_type omap_rtc_default_type = {
diff --git a/include/linux/rtc.h b/include/linux/rtc.h
index f89bfbb54902..9be8d97534b4 100644
--- a/include/linux/rtc.h
+++ b/include/linux/rtc.h
@@ -84,6 +84,7 @@ struct rtc_class_ops {
 	int (*alarm_irq_enable)(struct device *, unsigned int enabled);
 	int (*read_offset)(struct device *, long *offset);
 	int (*set_offset)(struct device *, long offset);
+	int (*power_off_program)(struct device *dev);
 };
 
 struct rtc_device;
@@ -209,6 +210,7 @@ void rtc_timer_cancel(struct rtc_device *rtc, struct rtc_timer *timer);
 int rtc_read_offset(struct rtc_device *rtc, long *offset);
 int rtc_set_offset(struct rtc_device *rtc, long offset);
 void rtc_timer_do_work(struct work_struct *work);
+int rtc_power_off_program(struct rtc_device *rtc);
 
 static inline bool is_leap_year(unsigned int year)
 {
-- 
2.17.1

[PATCH 3/5] arm: mach-omap2: pm33xx: Add support for rtc+ddr in self refresh mode

[Keerthy]

Add support for rtc+ddr in self refresh mode. Add addtional
pm hooks for save/restore and rtc suspend/resume.

Signed-off-by: Keerthy <j-keerthy@ti.com>
---
 arch/arm/mach-omap2/pm33xx-core.c    | 76 +++++++++++++++++++++++++++-
 include/linux/platform_data/pm33xx.h |  5 ++
 2 files changed, 80 insertions(+), 1 deletion(-)

diff --git a/arch/arm/mach-omap2/pm33xx-core.c b/arch/arm/mach-omap2/pm33xx-core.c
index 724cf5774a6c..8c02fc73a7a5 100644
--- a/arch/arm/mach-omap2/pm33xx-core.c
+++ b/arch/arm/mach-omap2/pm33xx-core.c
@@ -10,6 +10,12 @@
 #include <asm/suspend.h>
 #include <linux/errno.h>
 #include <linux/platform_data/pm33xx.h>
+#include <linux/clk.h>
+#include <linux/platform_data/gpio-omap.h>
+#include <linux/pinctrl/pinmux.h>
+#include <linux/wkup_m3_ipc.h>
+#include <linux/of.h>
+#include <linux/rtc.h>
 
 #include "cm33xx.h"
 #include "common.h"
@@ -38,6 +44,29 @@ static int am43xx_map_scu(void)
 	return 0;
 }
 
+static int am33xx_check_off_mode_enable(void)
+{
+	if (enable_off_mode)
+		pr_warn("WARNING: This platform does not support off-mode, entering DeepSleep suspend.\n");
+
+	/* off mode not supported on am335x so return 0 always */
+	return 0;
+}
+
+static int am43xx_check_off_mode_enable(void)
+{
+	/*
+	 * Check for am437x-sk-evm which due to HW design cannot support
+	 * this mode reliably.
+	 */
+	if (of_machine_is_compatible("ti,am437x-sk-evm") && enable_off_mode) {
+		pr_warn("WARNING: This platform does not support off-mode, entering DeepSleep suspend.\n");
+		return 0;
+	}
+
+	return enable_off_mode;
+}
+
 static int amx3_common_init(void)
 {
 	gfx_pwrdm = pwrdm_lookup("gfx_pwrdm");
@@ -139,7 +168,9 @@ static int am43xx_suspend(unsigned int state, int (*fn)(unsigned long),
 	scu_power_mode(scu_base, SCU_PM_POWEROFF);
 	ret = cpu_suspend(args, fn);
 	scu_power_mode(scu_base, SCU_PM_NORMAL);
-	amx3_post_suspend_common();
+
+	if (!am43xx_check_off_mode_enable())
+		amx3_post_suspend_common();
 
 	return ret;
 }
@@ -161,10 +192,48 @@ void __iomem *am43xx_get_rtc_base_addr(void)
 	return omap_hwmod_get_mpu_rt_va(rtc_oh);
 }
 
+static void am43xx_save_context(void)
+{
+}
+
+static void am33xx_save_context(void)
+{
+	omap_intc_save_context();
+}
+
+static void am33xx_restore_context(void)
+{
+	omap_intc_restore_context();
+}
+
+static void am43xx_restore_context(void)
+{
+	/*
+	 * HACK: restore dpll_per_clkdcoldo register contents, to avoid
+	 * breaking suspend-resume
+	 */
+	writel_relaxed(0x0, AM33XX_L4_WK_IO_ADDRESS(0x44df2e14));
+}
+
+static void am43xx_prepare_rtc_suspend(void)
+{
+	omap_hwmod_enable(rtc_oh);
+}
+
+static void am43xx_prepare_rtc_resume(void)
+{
+	omap_hwmod_idle(rtc_oh);
+}
+
 static struct am33xx_pm_platform_data am33xx_ops = {
 	.init = am33xx_suspend_init,
 	.soc_suspend = am33xx_suspend,
 	.get_sram_addrs = amx3_get_sram_addrs,
+	.save_context = am33xx_save_context,
+	.restore_context = am33xx_restore_context,
+	.prepare_rtc_suspend = am43xx_prepare_rtc_suspend,
+	.prepare_rtc_resume = am43xx_prepare_rtc_resume,
+	.check_off_mode_enable = am33xx_check_off_mode_enable,
 	.get_rtc_base_addr = am43xx_get_rtc_base_addr,
 };
 
@@ -172,6 +241,11 @@ static struct am33xx_pm_platform_data am43xx_ops = {
 	.init = am43xx_suspend_init,
 	.soc_suspend = am43xx_suspend,
 	.get_sram_addrs = amx3_get_sram_addrs,
+	.save_context = am43xx_save_context,
+	.restore_context = am43xx_restore_context,
+	.prepare_rtc_suspend = am43xx_prepare_rtc_suspend,
+	.prepare_rtc_resume = am43xx_prepare_rtc_resume,
+	.check_off_mode_enable = am43xx_check_off_mode_enable,
 	.get_rtc_base_addr = am43xx_get_rtc_base_addr,
 };
 
diff --git a/include/linux/platform_data/pm33xx.h b/include/linux/platform_data/pm33xx.h
index fbf5ed73c7cc..dd5971937a64 100644
--- a/include/linux/platform_data/pm33xx.h
+++ b/include/linux/platform_data/pm33xx.h
@@ -51,6 +51,11 @@ struct am33xx_pm_platform_data {
 			       unsigned long args);
 	struct  am33xx_pm_sram_addr *(*get_sram_addrs)(void);
 	void __iomem *(*get_rtc_base_addr)(void);
+	void (*save_context)(void);
+	void (*restore_context)(void);
+	void (*prepare_rtc_suspend)(void);
+	void (*prepare_rtc_resume)(void);
+	int (*check_off_mode_enable)(void);
 };
 
 struct am33xx_pm_sram_data {
-- 
2.17.1

[PATCH 4/5] soc: ti: pm33xx: Push the am33xx_push_sram_idle to the top

[Keerthy]

Push the am33xx_push_sram_idle function to the top as a preparation
for rtc+ddr mode as the function will be called by multiple functions
currently present before it.

Signed-off-by: Keerthy <j-keerthy@ti.com>
---
 drivers/soc/ti/pm33xx.c | 100 ++++++++++++++++++++--------------------
 1 file changed, 50 insertions(+), 50 deletions(-)

diff --git a/drivers/soc/ti/pm33xx.c b/drivers/soc/ti/pm33xx.c
index d0dab323651f..69128993776d 100644
--- a/drivers/soc/ti/pm33xx.c
+++ b/drivers/soc/ti/pm33xx.c
@@ -49,6 +49,56 @@ static u32 sram_suspend_address(unsigned long addr)
 		AMX3_PM_SRAM_SYMBOL_OFFSET(addr));
 }
 
+static int am33xx_push_sram_idle(void)
+{
+	struct am33xx_pm_ro_sram_data ro_sram_data;
+	int ret;
+	u32 table_addr, ro_data_addr;
+	void *copy_addr;
+
+	ro_sram_data.amx3_pm_sram_data_virt = ocmcram_location_data;
+	ro_sram_data.amx3_pm_sram_data_phys =
+		gen_pool_virt_to_phys(sram_pool_data, ocmcram_location_data);
+	ro_sram_data.rtc_base_virt = pm_ops->get_rtc_base_addr();
+
+	/* Save physical address to calculate resume offset during pm init */
+	am33xx_do_wfi_sram_phys = gen_pool_virt_to_phys(sram_pool,
+							ocmcram_location);
+
+	am33xx_do_wfi_sram = sram_exec_copy(sram_pool, (void *)ocmcram_location,
+					    pm_sram->do_wfi,
+					    *pm_sram->do_wfi_sz);
+	if (!am33xx_do_wfi_sram) {
+		dev_err(pm33xx_dev,
+			"PM: %s: am33xx_do_wfi copy to sram failed\n",
+			__func__);
+		return -ENODEV;
+	}
+
+	table_addr =
+		sram_suspend_address((unsigned long)pm_sram->emif_sram_table);
+	ret = ti_emif_copy_pm_function_table(sram_pool, (void *)table_addr);
+	if (ret) {
+		dev_dbg(pm33xx_dev,
+			"PM: %s: EMIF function copy failed\n", __func__);
+		return -EPROBE_DEFER;
+	}
+
+	ro_data_addr =
+		sram_suspend_address((unsigned long)pm_sram->ro_sram_data);
+	copy_addr = sram_exec_copy(sram_pool, (void *)ro_data_addr,
+				   &ro_sram_data,
+				   sizeof(ro_sram_data));
+	if (!copy_addr) {
+		dev_err(pm33xx_dev,
+			"PM: %s: ro_sram_data copy to sram failed\n",
+			__func__);
+		return -ENODEV;
+	}
+
+	return 0;
+}
+
 #ifdef CONFIG_SUSPEND
 static int am33xx_pm_suspend(suspend_state_t suspend_state)
 {
@@ -219,56 +269,6 @@ static int am33xx_pm_alloc_sram(void)
 	return ret;
 }
 
-static int am33xx_push_sram_idle(void)
-{
-	struct am33xx_pm_ro_sram_data ro_sram_data;
-	int ret;
-	u32 table_addr, ro_data_addr;
-	void *copy_addr;
-
-	ro_sram_data.amx3_pm_sram_data_virt = ocmcram_location_data;
-	ro_sram_data.amx3_pm_sram_data_phys =
-		gen_pool_virt_to_phys(sram_pool_data, ocmcram_location_data);
-	ro_sram_data.rtc_base_virt = pm_ops->get_rtc_base_addr();
-
-	/* Save physical address to calculate resume offset during pm init */
-	am33xx_do_wfi_sram_phys = gen_pool_virt_to_phys(sram_pool,
-							ocmcram_location);
-
-	am33xx_do_wfi_sram = sram_exec_copy(sram_pool, (void *)ocmcram_location,
-					    pm_sram->do_wfi,
-					    *pm_sram->do_wfi_sz);
-	if (!am33xx_do_wfi_sram) {
-		dev_err(pm33xx_dev,
-			"PM: %s: am33xx_do_wfi copy to sram failed\n",
-			__func__);
-		return -ENODEV;
-	}
-
-	table_addr =
-		sram_suspend_address((unsigned long)pm_sram->emif_sram_table);
-	ret = ti_emif_copy_pm_function_table(sram_pool, (void *)table_addr);
-	if (ret) {
-		dev_dbg(pm33xx_dev,
-			"PM: %s: EMIF function copy failed\n", __func__);
-		return -EPROBE_DEFER;
-	}
-
-	ro_data_addr =
-		sram_suspend_address((unsigned long)pm_sram->ro_sram_data);
-	copy_addr = sram_exec_copy(sram_pool, (void *)ro_data_addr,
-				   &ro_sram_data,
-				   sizeof(ro_sram_data));
-	if (!copy_addr) {
-		dev_err(pm33xx_dev,
-			"PM: %s: ro_sram_data copy to sram failed\n",
-			__func__);
-		return -ENODEV;
-	}
-
-	return 0;
-}
-
 static int am33xx_pm_probe(struct platform_device *pdev)
 {
 	struct device *dev = &pdev->dev;
-- 
2.17.1

[PATCH 5/5] soc: ti: pm33xx: AM437X: Add rtc_only with ddr in self-refresh support

[Keerthy]

During RTC-only suspend, power is lost to the wkup domain, so we need to
save and restore the state of that domain. We also need to store some
information within the RTC registers so that u-boot can do the right thing
at powerup.

The state is entered by getting the RTC to bring the pmic_power_en line low
which will instruct the PMIC to disable the appropriate power rails after
putting DDR into self-refresh mode. To bring pmic_power_en low, we need to
get an ALARM2 event. Since we are running from SRAM at that point, it means
calculating what the next second is (via ASM) and programming that into the
RTC. This patch also adds support for wake up source detection.

Signed-off-by: Keerthy <j-keerthy@ti.com>
Signed-off-by: Dave Gerlach <d-gerlach@ti.com>
---
 drivers/soc/ti/Kconfig  |   5 +-
 drivers/soc/ti/pm33xx.c | 190 ++++++++++++++++++++++++++++++++++++++--
 2 files changed, 184 insertions(+), 11 deletions(-)

diff --git a/drivers/soc/ti/Kconfig b/drivers/soc/ti/Kconfig
index be4570baad96..57960e92ebe0 100644
--- a/drivers/soc/ti/Kconfig
+++ b/drivers/soc/ti/Kconfig
@@ -45,11 +45,12 @@ config KEYSTONE_NAVIGATOR_DMA
 config AMX3_PM
 	tristate "AMx3 Power Management"
 	depends on SOC_AM33XX || SOC_AM43XX
-	depends on WKUP_M3_IPC && TI_EMIF_SRAM && SRAM
+	depends on WKUP_M3_IPC && TI_EMIF_SRAM && SRAM && RTC_DRV_OMAP
 	help
 	  Enable power management on AM335x and AM437x. Required for suspend to mem
 	  and standby states on both AM335x and AM437x platforms and for deeper cpuidle
-	  c-states on AM335x.
+	  c-states on AM335x. Also required for rtc and ddr in self-refresh low
+	  power mode on AM437x platforms.
 
 config WKUP_M3_IPC
 	tristate "TI AMx3 Wkup-M3 IPC Driver"
diff --git a/drivers/soc/ti/pm33xx.c b/drivers/soc/ti/pm33xx.c
index 69128993776d..15b1414d3465 100644
--- a/drivers/soc/ti/pm33xx.c
+++ b/drivers/soc/ti/pm33xx.c
@@ -6,6 +6,7 @@
  *	Vaibhav Bedia, Dave Gerlach
  */
 
+#include <linux/clk.h>
 #include <linux/cpu.h>
 #include <linux/err.h>
 #include <linux/genalloc.h>
@@ -13,9 +14,11 @@
 #include <linux/init.h>
 #include <linux/io.h>
 #include <linux/module.h>
+#include <linux/nvmem-consumer.h>
 #include <linux/of.h>
 #include <linux/platform_data/pm33xx.h>
 #include <linux/platform_device.h>
+#include <linux/rtc.h>
 #include <linux/sizes.h>
 #include <linux/sram.h>
 #include <linux/suspend.h>
@@ -29,20 +32,47 @@
 #define AMX3_PM_SRAM_SYMBOL_OFFSET(sym) ((unsigned long)(sym) - \
 					 (unsigned long)pm_sram->do_wfi)
 
+#define RTC_SCRATCH_RESUME_REG	0
+#define RTC_SCRATCH_MAGIC_REG	1
+#define RTC_REG_BOOT_MAGIC	0x8cd0 /* RTC */
+#define GIC_INT_SET_PENDING_BASE 0x200
+#define AM43XX_GIC_DIST_BASE	0x48241000
+
+static u32 rtc_magic_val;
+
 static int (*am33xx_do_wfi_sram)(unsigned long unused);
 static phys_addr_t am33xx_do_wfi_sram_phys;
 
 static struct gen_pool *sram_pool, *sram_pool_data;
 static unsigned long ocmcram_location, ocmcram_location_data;
 
+static struct rtc_device *omap_rtc;
+static void __iomem *gic_dist_base;
+
 static struct am33xx_pm_platform_data *pm_ops;
 static struct am33xx_pm_sram_addr *pm_sram;
 
 static struct device *pm33xx_dev;
 static struct wkup_m3_ipc *m3_ipc;
 
+#ifdef CONFIG_SUSPEND
+static int rtc_only_idle;
+static int retrigger_irq;
 static unsigned long suspend_wfi_flags;
 
+static struct wkup_m3_wakeup_src wakeup_src = {.irq_nr = 0,
+	.src = "Unknown",
+};
+
+static struct wkup_m3_wakeup_src rtc_alarm_wakeup = {
+	.irq_nr = 108, .src = "RTC Alarm",
+};
+
+static struct wkup_m3_wakeup_src rtc_ext_wakeup = {
+	.irq_nr = 0, .src = "Ext wakeup",
+};
+#endif
+
 static u32 sram_suspend_address(unsigned long addr)
 {
 	return ((unsigned long)am33xx_do_wfi_sram +
@@ -99,13 +129,65 @@ static int am33xx_push_sram_idle(void)
 	return 0;
 }
 
+static int __init am43xx_map_gic(void)
+{
+	gic_dist_base = ioremap(AM43XX_GIC_DIST_BASE, SZ_4K);
+
+	if (!gic_dist_base)
+		return -ENOMEM;
+
+	return 0;
+}
+
 #ifdef CONFIG_SUSPEND
+struct wkup_m3_wakeup_src rtc_wake_src(void)
+{
+	u32 i;
+
+	i = __raw_readl(pm_ops->get_rtc_base_addr() + 0x44) & 0x40;
+
+	if (i) {
+		retrigger_irq = rtc_alarm_wakeup.irq_nr;
+		return rtc_alarm_wakeup;
+	}
+
+	retrigger_irq = rtc_ext_wakeup.irq_nr;
+
+	return rtc_ext_wakeup;
+}
+
+int am33xx_rtc_only_idle(unsigned long wfi_flags)
+{
+	rtc_power_off_program(omap_rtc);
+	am33xx_do_wfi_sram(wfi_flags);
+	return 0;
+}
+
 static int am33xx_pm_suspend(suspend_state_t suspend_state)
 {
 	int i, ret = 0;
 
-	ret = pm_ops->soc_suspend((unsigned long)suspend_state,
-				  am33xx_do_wfi_sram, suspend_wfi_flags);
+	if (suspend_state == PM_SUSPEND_MEM &&
+	    pm_ops->check_off_mode_enable()) {
+		pm_ops->prepare_rtc_suspend();
+		pm_ops->save_context();
+		suspend_wfi_flags |= WFI_FLAG_RTC_ONLY;
+		clk_save_context();
+		ret = pm_ops->soc_suspend(suspend_state, am33xx_rtc_only_idle,
+					  suspend_wfi_flags);
+
+		suspend_wfi_flags &= ~WFI_FLAG_RTC_ONLY;
+
+		if (!ret) {
+			clk_restore_context();
+			pm_ops->restore_context();
+			m3_ipc->ops->set_rtc_only(m3_ipc);
+			am33xx_push_sram_idle();
+		}
+	} else {
+		ret = pm_ops->soc_suspend(suspend_state, am33xx_do_wfi_sram,
+					  suspend_wfi_flags);
+	}
 
 	if (ret) {
 		dev_err(pm33xx_dev, "PM: Kernel suspend failure\n");
@@ -127,8 +209,20 @@ static int am33xx_pm_suspend(suspend_state_t suspend_state)
 				"PM: CM3 returned unknown result = %d\n", i);
 			ret = -1;
 		}
+
+		/* print the wakeup reason */
+		if (rtc_only_idle) {
+			wakeup_src = rtc_wake_src();
+			pr_info("PM: Wakeup source %s\n", wakeup_src.src);
+		} else {
+			pr_info("PM: Wakeup source %s\n",
+				m3_ipc->ops->request_wake_src(m3_ipc));
+		}
 	}
 
+	if (suspend_state == PM_SUSPEND_MEM && pm_ops->check_off_mode_enable())
+		pm_ops->prepare_rtc_resume();
+
 	return ret;
 }
 
@@ -151,6 +245,18 @@ static int am33xx_pm_enter(suspend_state_t suspend_state)
 static int am33xx_pm_begin(suspend_state_t state)
 {
 	int ret = -EINVAL;
+	struct nvmem_device *nvmem;
+
+	if (state == PM_SUSPEND_MEM && pm_ops->check_off_mode_enable()) {
+		nvmem = devm_nvmem_device_get(&omap_rtc->dev,
+					      "omap_rtc_scratch0");
+		if (nvmem)
+			nvmem_device_write(nvmem, RTC_SCRATCH_MAGIC_REG * 4, 4,
+					   (void *)&rtc_magic_val);
+		rtc_only_idle = 1;
+	} else {
+		rtc_only_idle = 0;
+	}
 
 	switch (state) {
 	case PM_SUSPEND_MEM:
@@ -166,7 +272,28 @@ static int am33xx_pm_begin(suspend_state_t state)
 
 static void am33xx_pm_end(void)
 {
+	u32 val = 0;
+	struct nvmem_device *nvmem;
+
+	nvmem = devm_nvmem_device_get(&omap_rtc->dev, "omap_rtc_scratch0");
 	m3_ipc->ops->finish_low_power(m3_ipc);
+	if (rtc_only_idle) {
+		if (retrigger_irq)
+			/*
+			 * 32 bits of Interrupt Set-Pending correspond to 32
+			 * 32 interrupts. Compute the bit offset of the
+			 * Interrupt and set that particular bit
+			 * Compute the register offset by dividing interrupt
+			 * number by 32 and mutiplying by 4
+			 */
+			writel_relaxed(1 << (retrigger_irq & 31),
+				       gic_dist_base + GIC_INT_SET_PENDING_BASE
+				       + retrigger_irq / 32 * 4);
+			nvmem_device_write(nvmem, RTC_SCRATCH_MAGIC_REG * 4, 4,
+					   (void *)&val);
+	}
+
+	rtc_only_idle = 0;
 }
 
 static int am33xx_pm_valid(suspend_state_t state)
@@ -269,6 +396,42 @@ static int am33xx_pm_alloc_sram(void)
 	return ret;
 }
 
+static int am33xx_pm_rtc_setup(void)
+{
+	struct device_node *np;
+	unsigned long val = 0;
+	struct nvmem_device *nvmem;
+
+	np = of_find_node_by_name(NULL, "rtc");
+
+	if (of_device_is_available(np)) {
+		omap_rtc = rtc_class_open("rtc0");
+		if (!omap_rtc) {
+			pr_warn("PM: rtc0 not available");
+			return -EPROBE_DEFER;
+		}
+
+		nvmem = devm_nvmem_device_get(&omap_rtc->dev,
+					      "omap_rtc_scratch0");
+		if (nvmem) {
+			nvmem_device_read(nvmem, RTC_SCRATCH_MAGIC_REG * 4,
+					  4, (void *)&rtc_magic_val);
+			if ((rtc_magic_val & 0xffff) != RTC_REG_BOOT_MAGIC)
+				pr_warn("PM: bootloader does not support rtc-only!\n");
+
+			nvmem_device_write(nvmem, RTC_SCRATCH_MAGIC_REG * 4,
+					   4, (void *)&val);
+			val = pm_sram->resume_address;
+			nvmem_device_write(nvmem, RTC_SCRATCH_RESUME_REG * 4,
+					   4, (void *)&val);
+		}
+	} else {
+		pr_warn("PM: no-rtc available, rtc-only mode disabled.\n");
+	}
+
+	return 0;
+}
+
 static int am33xx_pm_probe(struct platform_device *pdev)
 {
 	struct device *dev = &pdev->dev;
@@ -284,34 +447,42 @@ static int am33xx_pm_probe(struct platform_device *pdev)
 		return -ENODEV;
 	}
 
+	ret = am43xx_map_gic();
+	if (ret) {
+		pr_err("PM: Could not ioremap GIC base\n");
+		return ret;
+	}
+
 	pm_sram = pm_ops->get_sram_addrs();
 	if (!pm_sram) {
 		dev_err(dev, "PM: Cannot get PM asm function addresses!!\n");
 		return -ENODEV;
 	}
 
+	m3_ipc = wkup_m3_ipc_get();
+	if (!m3_ipc) {
+		pr_err("PM: Cannot get wkup_m3_ipc handle\n");
+		return -EPROBE_DEFER;
+	}
+
 	pm33xx_dev = dev;
 
 	ret = am33xx_pm_alloc_sram();
 	if (ret)
 		return ret;
 
-	ret = am33xx_push_sram_idle();
+	ret = am33xx_pm_rtc_setup();
 	if (ret)
 		goto err_free_sram;
 
-	m3_ipc = wkup_m3_ipc_get();
-	if (!m3_ipc) {
-		dev_dbg(dev, "PM: Cannot get wkup_m3_ipc handle\n");
-		ret = -EPROBE_DEFER;
+	ret = am33xx_push_sram_idle();
+	if (ret)
 		goto err_free_sram;
-	}
 
 	am33xx_pm_set_ipc_ops();
 
 #ifdef CONFIG_SUSPEND
 	suspend_set_ops(&am33xx_pm_ops);
-#endif /* CONFIG_SUSPEND */
 
 	/*
 	 * For a system suspend we must flush the caches, we want
@@ -323,6 +494,7 @@ static int am33xx_pm_probe(struct platform_device *pdev)
 	suspend_wfi_flags |= WFI_FLAG_SELF_REFRESH;
 	suspend_wfi_flags |= WFI_FLAG_SAVE_EMIF;
 	suspend_wfi_flags |= WFI_FLAG_WAKE_M3;
+#endif /* CONFIG_SUSPEND */
 
 	ret = pm_ops->init();
 	if (ret) {
-- 
2.17.1

Re: [PATCH 0/5] AM437x: Add rtc-only + DDR mode support

[Russell King - ARM Linux admin]

On Fri, Mar 22, 2019 at 10:46:14PM +0530, Keerthy wrote:
> RTC plus DDR in self-refresh is power a saving mode where in the entire
                                 "a power" ?

> system including the different voltage rails from PMIC are shutdown except
> the ones feeding on to RTC and DDR. DDR is kept in self-refresh hence the
> contents are preserved. RTC ALARM2 is connected to PMIC_EN line once
> we the ALARM2 is triggered we enter the mode with DDR in self-refresh

Doesn't make sense.

> and RTC Ticking. After a predetermined time an RTC ALARM1 triggers waking
> up the system.

Huh, you start off explaining the wiring above... how does RTC ALARM1
trigger waking up the system if RTC ALARM2 is connected to the PMIC
and all other power is shut down?

> The control goes to bootloader. The bootloader then checks
> RTC scratchpad registers to confirm it was an rtc_only wakeup and follows
> a different path, configure bare minimal clocks for ddr and then jumps to
> the resume address in another RTC scratchpad registers and transfers the
> control to Kernel. Kernel then restores the saved context.
> 
> The patch series adds rtc-only + DDR mode support am am437x
> Tested DS0, rtc+ddr back and forth on am437x-gp-evm board.
> 
> This mode works only with u-boot built with am43xx_evm_rtconly_defconfig
> 
> Additional patch is needed for omap-gpio save restore which will
> come as fixes later.
> 
> Keerthy (5):
>   rtc: OMAP: Add support for rtc-only mode
>   rtc: interface: Add power_off_program to rtc_class_ops
>   arm: mach-omap2: pm33xx: Add support for rtc+ddr in self refresh mode
>   soc: ti: pm33xx: Push the am33xx_push_sram_idle to the top
>   soc: ti: pm33xx: AM437X: Add rtc_only with ddr in self-refresh support
> 
>  arch/arm/mach-omap2/pm33xx-core.c    |  76 +++++++-
>  drivers/rtc/interface.c              |  12 ++
>  drivers/rtc/rtc-omap.c               |  49 ++++-
>  drivers/soc/ti/Kconfig               |   5 +-
>  drivers/soc/ti/pm33xx.c              | 272 ++++++++++++++++++++++-----
>  include/linux/platform_data/pm33xx.h |   5 +
>  include/linux/rtc.h                  |   2 +
>  7 files changed, 360 insertions(+), 61 deletions(-)
> 
> -- 
> 2.17.1
> 
> 
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
> 

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up
According to speedtest.net: 11.9Mbps down 500kbps up

Re: [PATCH 0/5] AM437x: Add rtc-only + DDR mode support

[keerthy]

On 3/23/2019 12:02 AM, Russell King - ARM Linux admin wrote:
> On Fri, Mar 22, 2019 at 10:46:14PM +0530, Keerthy wrote:
>> RTC plus DDR in self-refresh is power a saving mode where in the entire
>                                   "a power" ?

Will correct the above typo.

> 
>> system including the different voltage rails from PMIC are shutdown except
>> the ones feeding on to RTC and DDR. DDR is kept in self-refresh hence the

As explained above All the voltage rails of PMIC are shut off except for 
RTC and DDR Rails.

>> contents are preserved. RTC ALARM2 is connected to PMIC_EN line once
>> we the ALARM2 is triggered we enter the mode with DDR in self-refresh
> 
> Doesn't make sense.
> 
>> and RTC Ticking. After a predetermined time an RTC ALARM1 triggers waking
>> up the system.
> 
> Huh, you start off explaining the wiring above... how does RTC ALARM1
> trigger waking up the system if RTC ALARM2 is connected to the PMIC
> and all other power is shut down?
The entire PMIC is shutdown but for RTC rail. RTC is a separate voltage 
domain and is powered up during this power save mode.

http://www.ti.com/lit/ug/spruhl7h/spruhl7h.pdf Page 2884.

> 
>> The control goes to bootloader. The bootloader then checks
>> RTC scratchpad registers to confirm it was an rtc_only wakeup and follows
>> a different path, configure bare minimal clocks for ddr and then jumps to
>> the resume address in another RTC scratchpad registers and transfers the
>> control to Kernel. Kernel then restores the saved context.
>>
>> The patch series adds rtc-only + DDR mode support am am437x
>> Tested DS0, rtc+ddr back and forth on am437x-gp-evm board.
>>
>> This mode works only with u-boot built with am43xx_evm_rtconly_defconfig
>>
>> Additional patch is needed for omap-gpio save restore which will
>> come as fixes later.
>>
>> Keerthy (5):
>>    rtc: OMAP: Add support for rtc-only mode
>>    rtc: interface: Add power_off_program to rtc_class_ops
>>    arm: mach-omap2: pm33xx: Add support for rtc+ddr in self refresh mode
>>    soc: ti: pm33xx: Push the am33xx_push_sram_idle to the top
>>    soc: ti: pm33xx: AM437X: Add rtc_only with ddr in self-refresh support
>>
>>   arch/arm/mach-omap2/pm33xx-core.c    |  76 +++++++-
>>   drivers/rtc/interface.c              |  12 ++
>>   drivers/rtc/rtc-omap.c               |  49 ++++-
>>   drivers/soc/ti/Kconfig               |   5 +-
>>   drivers/soc/ti/pm33xx.c              | 272 ++++++++++++++++++++++-----
>>   include/linux/platform_data/pm33xx.h |   5 +
>>   include/linux/rtc.h                  |   2 +
>>   7 files changed, 360 insertions(+), 61 deletions(-)
>>
>> -- 
>> 2.17.1
>>
>>
>> _______________________________________________
>> linux-arm-kernel mailing list
>> linux-arm-kernel@lists.infradead.org
>> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>>
> 

Re: [PATCH 0/5] AM437x: Add rtc-only + DDR mode support

[Russell King - ARM Linux admin]

On Mon, Mar 25, 2019 at 07:13:53AM +0530, keerthy wrote:
> 
> 
> On 3/23/2019 12:02 AM, Russell King - ARM Linux admin wrote:
> > On Fri, Mar 22, 2019 at 10:46:14PM +0530, Keerthy wrote:
> > > RTC plus DDR in self-refresh is power a saving mode where in the entire
> >                                   "a power" ?
> 
> Will correct the above typo.
> 
> > 
> > > system including the different voltage rails from PMIC are shutdown except
> > > the ones feeding on to RTC and DDR. DDR is kept in self-refresh hence the
> 
> As explained above All the voltage rails of PMIC are shut off except for RTC
> and DDR Rails.

You seem to be replying to yourself there - the quote above your reply
there is what you wrote.

> 
> > > contents are preserved. RTC ALARM2 is connected to PMIC_EN line once
> > > we the ALARM2 is triggered we enter the mode with DDR in self-refresh
> > 
> > Doesn't make sense.
> > 
> > > and RTC Ticking. After a predetermined time an RTC ALARM1 triggers waking
> > > up the system.
> > 
> > Huh, you start off explaining the wiring above... how does RTC ALARM1
> > trigger waking up the system if RTC ALARM2 is connected to the PMIC
> > and all other power is shut down?
> The entire PMIC is shutdown but for RTC rail. RTC is a separate voltage
> domain and is powered up during this power save mode.
> 
> http://www.ti.com/lit/ug/spruhl7h/spruhl7h.pdf Page 2884.

I'm not asking for a reference, I'm asking for your cover letter to
make sense and actually be useful.  Right now, it's far from that.

Thanks.

> 
> > 
> > > The control goes to bootloader. The bootloader then checks
> > > RTC scratchpad registers to confirm it was an rtc_only wakeup and follows
> > > a different path, configure bare minimal clocks for ddr and then jumps to
> > > the resume address in another RTC scratchpad registers and transfers the
> > > control to Kernel. Kernel then restores the saved context.
> > > 
> > > The patch series adds rtc-only + DDR mode support am am437x
> > > Tested DS0, rtc+ddr back and forth on am437x-gp-evm board.
> > > 
> > > This mode works only with u-boot built with am43xx_evm_rtconly_defconfig
> > > 
> > > Additional patch is needed for omap-gpio save restore which will
> > > come as fixes later.
> > > 
> > > Keerthy (5):
> > >    rtc: OMAP: Add support for rtc-only mode
> > >    rtc: interface: Add power_off_program to rtc_class_ops
> > >    arm: mach-omap2: pm33xx: Add support for rtc+ddr in self refresh mode
> > >    soc: ti: pm33xx: Push the am33xx_push_sram_idle to the top
> > >    soc: ti: pm33xx: AM437X: Add rtc_only with ddr in self-refresh support
> > > 
> > >   arch/arm/mach-omap2/pm33xx-core.c    |  76 +++++++-
> > >   drivers/rtc/interface.c              |  12 ++
> > >   drivers/rtc/rtc-omap.c               |  49 ++++-
> > >   drivers/soc/ti/Kconfig               |   5 +-
> > >   drivers/soc/ti/pm33xx.c              | 272 ++++++++++++++++++++++-----
> > >   include/linux/platform_data/pm33xx.h |   5 +
> > >   include/linux/rtc.h                  |   2 +
> > >   7 files changed, 360 insertions(+), 61 deletions(-)
> > > 
> > > -- 
> > > 2.17.1
> > > 
> > > 
> > > _______________________________________________
> > > linux-arm-kernel mailing list
> > > linux-arm-kernel@lists.infradead.org
> > > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
> > > 
> > 
> 

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up
According to speedtest.net: 11.9Mbps down 500kbps up

Re: [PATCH 0/5] AM437x: Add rtc-only + DDR mode support

[keerthy]

On 3/25/2019 4:29 PM, Russell King - ARM Linux admin wrote:
> On Mon, Mar 25, 2019 at 07:13:53AM +0530, keerthy wrote:
>>
>>
>> On 3/23/2019 12:02 AM, Russell King - ARM Linux admin wrote:
>>> On Fri, Mar 22, 2019 at 10:46:14PM +0530, Keerthy wrote:
>>>> RTC plus DDR in self-refresh is power a saving mode where in the entire
>>>                                    "a power" ?
>>
>> Will correct the above typo.
>>
>>>
>>>> system including the different voltage rails from PMIC are shutdown except
>>>> the ones feeding on to RTC and DDR. DDR is kept in self-refresh hence the
>>
>> As explained above All the voltage rails of PMIC are shut off except for RTC
>> and DDR Rails.
> 
> You seem to be replying to yourself there - the quote above your reply
> there is what you wrote.


well. I wanted point out that PMIC has granular control.

> 
>>
>>>> contents are preserved. RTC ALARM2 is connected to PMIC_EN line once
>>>> we the ALARM2 is triggered we enter the mode with DDR in self-refresh
>>>
>>> Doesn't make sense.
>>>
>>>> and RTC Ticking. After a predetermined time an RTC ALARM1 triggers waking
>>>> up the system.
>>>
>>> Huh, you start off explaining the wiring above... how does RTC ALARM1
>>> trigger waking up the system if RTC ALARM2 is connected to the PMIC
>>> and all other power is shut down?
>> The entire PMIC is shutdown but for RTC rail. RTC is a separate voltage
>> domain and is powered up during this power save mode.
>>
>> http://www.ti.com/lit/ug/spruhl7h/spruhl7h.pdf Page 2884.
> 
> I'm not asking for a reference, I'm asking for your cover letter to
> make sense and actually be useful.  Right now, it's far from that.

Okay I get it. I will definitely add more details in the next version.

> 
> Thanks.
> 
>>
>>>
>>>> The control goes to bootloader. The bootloader then checks
>>>> RTC scratchpad registers to confirm it was an rtc_only wakeup and follows
>>>> a different path, configure bare minimal clocks for ddr and then jumps to
>>>> the resume address in another RTC scratchpad registers and transfers the
>>>> control to Kernel. Kernel then restores the saved context.
>>>>
>>>> The patch series adds rtc-only + DDR mode support am am437x
>>>> Tested DS0, rtc+ddr back and forth on am437x-gp-evm board.
>>>>
>>>> This mode works only with u-boot built with am43xx_evm_rtconly_defconfig
>>>>
>>>> Additional patch is needed for omap-gpio save restore which will
>>>> come as fixes later.
>>>>
>>>> Keerthy (5):
>>>>     rtc: OMAP: Add support for rtc-only mode
>>>>     rtc: interface: Add power_off_program to rtc_class_ops
>>>>     arm: mach-omap2: pm33xx: Add support for rtc+ddr in self refresh mode
>>>>     soc: ti: pm33xx: Push the am33xx_push_sram_idle to the top
>>>>     soc: ti: pm33xx: AM437X: Add rtc_only with ddr in self-refresh support
>>>>
>>>>    arch/arm/mach-omap2/pm33xx-core.c    |  76 +++++++-
>>>>    drivers/rtc/interface.c              |  12 ++
>>>>    drivers/rtc/rtc-omap.c               |  49 ++++-
>>>>    drivers/soc/ti/Kconfig               |   5 +-
>>>>    drivers/soc/ti/pm33xx.c              | 272 ++++++++++++++++++++++-----
>>>>    include/linux/platform_data/pm33xx.h |   5 +
>>>>    include/linux/rtc.h                  |   2 +
>>>>    7 files changed, 360 insertions(+), 61 deletions(-)
>>>>
>>>> -- 
>>>> 2.17.1
>>>>
>>>>
>>>> _______________________________________________
>>>> linux-arm-kernel mailing list
>>>> linux-arm-kernel@lists.infradead.org
>>>> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>>>>
>>>
>>
> 

Re: [PATCH 1/5] rtc: OMAP: Add support for rtc-only mode

[Keerthy]

On 22/03/19 10:46 PM, Keerthy wrote:
> Prepare rtc driver for rtc-only with DDR in self-refresh mode.
> omap_rtc_power_off now should cater to two features:

Hi Alexandre,

Any feedback on this?

Thanks,
Keerthy
> 
> 1) RTC plus DDR in self-refresh is power a saving mode where in the
> entire system including the different voltage rails from PMIC are
> shutdown except the ones feeding on to RTC and DDR. DDR is kept in
> self-refresh hence the contents are preserved. RTC ALARM2 is connected
> to PMIC_EN line once we the ALARM2 is triggered we enter the mode with
> DDR in self-refresh and RTC Ticking. After a predetermined time an RTC
> ALARM1 triggers waking up the system[1]. The control goes to bootloader.
> The bootloader then checks RTC scratchpad registers to confirm it was an
> rtc_only wakeup and follows a different path, configure bare minimal
> clocks for ddr and then jumps to the resume address in another RTC
> scratchpad registers and transfers the control to Kernel. Kernel then
> restores the saved context. omap_rtc_power_off_program does the ALARM2
> programming part.
> 
>       [1] http://www.ti.com/lit/ug/spruhl7h/spruhl7h.pdf Page 2884
> 
> 2) Power-off: This is usual poweroff mode. omap_rtc_power_off calls the
> above omap_rtc_power_off_program function and in addition to that
> programs the OMAP_RTC_PMIC_REG for any external wake ups for PMIC like
> the pushbutton and shuts off the PMIC.
> 
> Hence the split in omap_rtc_power_off.
> 
> Signed-off-by: Keerthy <j-keerthy@ti.com>
> ---
>   drivers/rtc/rtc-omap.c | 48 +++++++++++++++++++++++++++++++++++-------
>   1 file changed, 40 insertions(+), 8 deletions(-)
> 
> diff --git a/drivers/rtc/rtc-omap.c b/drivers/rtc/rtc-omap.c
> index 2f28e21ee016..9b58c933e37d 100644
> --- a/drivers/rtc/rtc-omap.c
> +++ b/drivers/rtc/rtc-omap.c
> @@ -407,15 +407,12 @@ static int omap_rtc_set_alarm(struct device *dev, struct rtc_wkalrm *alm)
>   
>   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.
> - *
> - * Called with local interrupts disabled.
> +/**
> + * omap_rtc_power_off_program: Set the pmic power off sequence. The RTC
> + * generates pmic_pwr_enable control, which can be used to control an external
> + * PMIC.
>    */
> -static void omap_rtc_power_off(void)
> +static int omap_rtc_power_off_program(struct device *dev)
>   {
>   	struct omap_rtc *rtc = omap_rtc_power_off_rtc;
>   	struct rtc_time tm;
> @@ -429,6 +426,9 @@ static void omap_rtc_power_off(void)
>   	rtc_writel(rtc, OMAP_RTC_PMIC_REG, val | OMAP_RTC_PMIC_POWER_EN_EN);
>   
>   again:
> +	/* Clear any existing ALARM2 event */
> +	rtc_writel(rtc, OMAP_RTC_STATUS_REG, OMAP_RTC_STATUS_ALARM2);
> +
>   	/* set alarm one second from now */
>   	omap_rtc_read_time_raw(rtc, &tm);
>   	seconds = tm.tm_sec;
> @@ -465,6 +465,38 @@ static void omap_rtc_power_off(void)
>   
>   	rtc->type->lock(rtc);
>   
> +	return 0;
> +}
> +
> +/*
> + * 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 one-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 rtc_device *rtc = omap_rtc_power_off_rtc->rtc;
> +	u32 val;
> +
> +	omap_rtc_power_off_program(rtc->dev.parent);
> +
> +	/* Set PMIC power enable and EXT_WAKEUP in case PB power on is used */
> +	omap_rtc_power_off_rtc->type->unlock(omap_rtc_power_off_rtc);
> +	val = rtc_readl(omap_rtc_power_off_rtc, OMAP_RTC_PMIC_REG);
> +	val |= OMAP_RTC_PMIC_POWER_EN_EN | OMAP_RTC_PMIC_EXT_WKUP_POL(0) |
> +			OMAP_RTC_PMIC_EXT_WKUP_EN(0);
> +	rtc_writel(omap_rtc_power_off_rtc, OMAP_RTC_PMIC_REG, val);
> +	omap_rtc_power_off_rtc->type->lock(omap_rtc_power_off_rtc);
> +
>   	/*
>   	 * Wait for alarm to trigger (within one second) and external PMIC to
>   	 * power off the system. Add a 500 ms margin for external latencies
> 

Re: [PATCH 3/5] arm: mach-omap2: pm33xx: Add support for rtc+ddr in self refresh mode

[Tony Lindgren]

Hi,

* Keerthy <j-keerthy@ti.com> [190322 17:16]:
> +static int am43xx_check_off_mode_enable(void)
> +{
> +	/*
> +	 * Check for am437x-sk-evm which due to HW design cannot support
> +	 * this mode reliably.
> +	 */
> +	if (of_machine_is_compatible("ti,am437x-sk-evm") && enable_off_mode) {
> +		pr_warn("WARNING: This platform does not support off-mode, entering DeepSleep suspend.\n");
> +		return 0;
> +	}
> +
> +	return enable_off_mode;
> +}

Considering off-mode suspend depends on how the board is
wired for various things such as memory, PMIC and the related
signal lines, I agree using the machine compatible is the best
check we can do here.

But since the device can hang during suspend unless things are
configured right for the board, I suggest you rather list allowed
boards here that are known to work with off-mode.

Otherwise many out-of-tree boards might hang during suspend
mysteriously.

Regards,

Tony

Re: [PATCH 3/5] arm: mach-omap2: pm33xx: Add support for rtc+ddr in self refresh mode

[Andreas Kemnade]

[-- Attachment #1.1: Type: text/plain, Size: 1408 bytes --]

On Mon, 1 Apr 2019 10:52:45 -0700
Tony Lindgren <tony@atomide.com> wrote:

> Hi,
> 
> * Keerthy <j-keerthy@ti.com> [190322 17:16]:
> > +static int am43xx_check_off_mode_enable(void)
> > +{
> > +	/*
> > +	 * Check for am437x-sk-evm which due to HW design cannot support
> > +	 * this mode reliably.
> > +	 */
> > +	if (of_machine_is_compatible("ti,am437x-sk-evm") && enable_off_mode) {
> > +		pr_warn("WARNING: This platform does not support off-mode, entering DeepSleep suspend.\n");
> > +		return 0;
> > +	}
> > +
> > +	return enable_off_mode;
> > +}  
> 
> Considering off-mode suspend depends on how the board is
> wired for various things such as memory, PMIC and the related
> signal lines, I agree using the machine compatible is the best
> check we can do here.
> 
> But since the device can hang during suspend unless things are
> configured right for the board, I suggest you rather list allowed
> boards here that are known to work with off-mode.
> 
Could we somehow describe this property of the hardware
(is-offmode-capable or is-wired-for-offmode) as a separate devicetree
property of the soc?

In mmc we have for example "cap-power-off-card" for
indicating some is-wired-suitable-for thing.

That looks to be clearer as looking for some strange conditions
derived from something.

I have still my offmode patch os the boilerplate...

Regards,
Andreas

[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

[-- Attachment #2: Type: text/plain, Size: 176 bytes --]

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH 3/5] arm: mach-omap2: pm33xx: Add support for rtc+ddr in self refresh mode

[Tony Lindgren]

* Andreas Kemnade <andreas@kemnade.info> [190401 18:39]:
> On Mon, 1 Apr 2019 10:52:45 -0700
> Tony Lindgren <tony@atomide.com> wrote:
> 
> > Hi,
> > 
> > * Keerthy <j-keerthy@ti.com> [190322 17:16]:
> > > +static int am43xx_check_off_mode_enable(void)
> > > +{
> > > +	/*
> > > +	 * Check for am437x-sk-evm which due to HW design cannot support
> > > +	 * this mode reliably.
> > > +	 */
> > > +	if (of_machine_is_compatible("ti,am437x-sk-evm") && enable_off_mode) {
> > > +		pr_warn("WARNING: This platform does not support off-mode, entering DeepSleep suspend.\n");
> > > +		return 0;
> > > +	}
> > > +
> > > +	return enable_off_mode;
> > > +}  
> > 
> > Considering off-mode suspend depends on how the board is
> > wired for various things such as memory, PMIC and the related
> > signal lines, I agree using the machine compatible is the best
> > check we can do here.
> > 
> > But since the device can hang during suspend unless things are
> > configured right for the board, I suggest you rather list allowed
> > boards here that are known to work with off-mode.
> > 
> Could we somehow describe this property of the hardware
> (is-offmode-capable or is-wired-for-offmode) as a separate devicetree
> property of the soc?
> 
> In mmc we have for example "cap-power-off-card" for
> indicating some is-wired-suitable-for thing.

And we also have "regulator-off-in-suspend".

How about "soc-off-in-suspend" for the generic name?

> That looks to be clearer as looking for some strange conditions
> derived from something.
> 
> I have still my offmode patch os the boilerplate...

Care to send a binding patch to devicetree@vger.kernel.org
for that?

And then when it gets acked, we can just start using it :)

Regards,

Tony

Re: [PATCH 3/5] arm: mach-omap2: pm33xx: Add support for rtc+ddr in self refresh mode

[Andreas Kemnade]

[-- Attachment #1.1: Type: text/plain, Size: 1870 bytes --]

On Mon, 1 Apr 2019 13:40:33 -0700
Tony Lindgren <tony@atomide.com> wrote:

> * Andreas Kemnade <andreas@kemnade.info> [190401 18:39]:
> > On Mon, 1 Apr 2019 10:52:45 -0700
> > Tony Lindgren <tony@atomide.com> wrote:
> >   
> > > Hi,
> > > 
> > > * Keerthy <j-keerthy@ti.com> [190322 17:16]:  
> > > > +static int am43xx_check_off_mode_enable(void)
> > > > +{
> > > > +	/*
> > > > +	 * Check for am437x-sk-evm which due to HW design cannot support
> > > > +	 * this mode reliably.
> > > > +	 */
> > > > +	if (of_machine_is_compatible("ti,am437x-sk-evm") && enable_off_mode) {
> > > > +		pr_warn("WARNING: This platform does not support off-mode, entering DeepSleep suspend.\n");
> > > > +		return 0;
> > > > +	}
> > > > +
> > > > +	return enable_off_mode;
> > > > +}    
> > > 
> > > Considering off-mode suspend depends on how the board is
> > > wired for various things such as memory, PMIC and the related
> > > signal lines, I agree using the machine compatible is the best
> > > check we can do here.
> > > 
> > > But since the device can hang during suspend unless things are
> > > configured right for the board, I suggest you rather list allowed
> > > boards here that are known to work with off-mode.
> > >   
> > Could we somehow describe this property of the hardware
> > (is-offmode-capable or is-wired-for-offmode) as a separate devicetree
> > property of the soc?
> > 
> > In mmc we have for example "cap-power-off-card" for
> > indicating some is-wired-suitable-for thing.  
> 
> And we also have "regulator-off-in-suspend".
> 
> How about "soc-off-in-suspend" for the generic name?
> 
Well, remember my "omap3: give off mode enable a more prominent place"
maybe we can use the same  capability property for both proposes.

I was a bit unsure about it, so I did not continue with it yet

Regards,
Andreas

[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

[-- Attachment #2: Type: text/plain, Size: 176 bytes --]

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH 3/5] arm: mach-omap2: pm33xx: Add support for rtc+ddr in self refresh mode

[Tony Lindgren]

* Andreas Kemnade <andreas@kemnade.info> [190404 10:53]:
> On Mon, 1 Apr 2019 13:40:33 -0700
> Tony Lindgren <tony@atomide.com> wrote:
> > * Andreas Kemnade <andreas@kemnade.info> [190401 18:39]:
> > > Could we somehow describe this property of the hardware
> > > (is-offmode-capable or is-wired-for-offmode) as a separate devicetree
> > > property of the soc?
> > > 
> > > In mmc we have for example "cap-power-off-card" for
> > > indicating some is-wired-suitable-for thing.  
> > 
> > And we also have "regulator-off-in-suspend".
> > 
> > How about "soc-off-in-suspend" for the generic name?
> > 
> Well, remember my "omap3: give off mode enable a more prominent place"
> maybe we can use the same  capability property for both proposes.

Yes. I don't think we need a Kconfig option for it though.
Seems just a device specific property should be enough for now.

Regards,

Tony