* [PATCH v2 00/18] ARM: OMAP5: PM: Add MPUSS suspend and CPUidle support
@ 2013-03-25 10:04 ` Santosh Shilimkar
0 siblings, 0 replies; 128+ messages in thread
From: Santosh Shilimkar @ 2013-03-25 10:04 UTC (permalink / raw)
To: khilman; +Cc: linux-omap, linux-arm-kernel, nm, tony, Santosh Shilimkar
Kevin,
Here is the refreshed version(v2) of the OMAP5 PM suspport which was posted
earlier (March 1st 2013). Patch-set incorporates comments from Nishant
Menon (Thanks for review NM) and his acked-by tags. I would like to get this
queued for 3.10 merge window if you are ok with the series.
Series is built on top of my pull requests [1] [2] [3] sent to Tony and your
'for_3.10/pm/cleanup' branch. For testing, I have created a branch [4]
which put together all the needed dependencies, fixes which should make it
to 3.10 merge window.
Series adds OMAP5 MPUSS power management support for system wide suspend
and CPUidle. Its heavy re-use from OMAP4 and hence only ~400 odd lines are
needed to add OMAP5 PM support on top of existing OMAP4 PM support.
OMAP5 adds a mercury retention feature which is an enhancement of
existing retention feature to reduce the leakage. No change in
programming model except one time enabling of mercury retention
during init.
One more notable change in OMAP5 vs OMAP4 devices, CPUx power domains
support retention state which lets you hit MPUSS and Core retention with
very low latency C-states.
Tested on OMAP4430 SDP, OMAP4460 Panda, OMAP5430 SDP and OMAP5432 Panda
devices with suspend and CPUIdle. Rootfs is mounted over ramdisk since
the mmc and nfs based fs needs DMA engine patches. For suspend wakeup,
I used Sourav's couple of serial wakeup wip patches from the lists.
The following changes since commit 9981cde24de52e5bb9a7cd918d1e54de241f85c9:
Merge branch 'for_3.10/omap5_data_files' of git://git.kernel.org/pub/scm/linux/kernel/git/ssantosh/linux into for_3.10/omap5_pm (2013-03-25 12:29:34 +0530)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/ssantosh/linux.git for_3.10/omap5_pm
for you to fetch changes up to 75bd846d3103da858a208fe07127151903d1f608:
ARM: OMAP5: PM: handle device instance for warm reset (2013-03-25 12:37:44 +0530)
----------------------------------------------------------------
Nishanth Menon (1):
ARM: OMAP5: PM: handle device instance for warm reset
Santosh Shilimkar (17):
ARM: OMAP4+: PM: Consolidate MPU subsystem PM code for re-use
ARM: OMAP5: PM: Update CPU context register offset
ARM: OMAP4+: PM: Consolidate and use OMAP4 PM code for OMAP5
ARM: OMAP5: PM: Set MPUSS-EMIF clock-domain static dependency
ARM: OMAP5: PM: Enables ES2 PM mode by default
ARM: OMAP5: PM: Enable Mercury retention mode on CPUx powerdomains
ARM: OMAP5: Add init_late() hook to enable pm initialization
ARM: OMAP5: PM: Add CPU power off in hotplug path
ARM: OMAP4+: PM: Restore CPU power state to ON with clockdomain force
wakeup method
ARM: OMAP5: PM: Add MPU Open Switch Retention support
ARM: OMAP5: PM: Add L2 memory power down support
ARM: OMAP4: CPUidle: Avoid double idle driver registration
ARM: OMAP: CPUidle: Unregister drivere on device registration failure
ARM: OMAP4: CPUidle: Make C-state description field more precise
ARM: OMAP4+: CPUidle: Consolidate idle driver for OMAP5 support
ARM: OMAP4+: CPUidle: Deprecate use of
omap4_mpuss_read_prev_context_state()
ARM: OMAP4+: CPUidle: Add OMAP5 idle driver support
arch/arm/mach-omap2/Kconfig | 1 +
arch/arm/mach-omap2/Makefile | 12 +-
arch/arm/mach-omap2/board-generic.c | 1 +
arch/arm/mach-omap2/common.h | 8 +-
arch/arm/mach-omap2/cpuidle34xx.c | 6 +-
.../{cpuidle44xx.c => cpuidle_omap4plus.c} | 151 ++++++++++++++++---
arch/arm/mach-omap2/io.c | 8 +
arch/arm/mach-omap2/omap-mpuss-lowpower.c | 155 +++++++++++++++-----
arch/arm/mach-omap2/omap-secure.h | 9 ++
arch/arm/mach-omap2/omap-smp.c | 12 +-
arch/arm/mach-omap2/omap-wakeupgen.c | 30 +++-
arch/arm/mach-omap2/omap-wakeupgen.h | 1 +
arch/arm/mach-omap2/omap4-sar-layout.h | 2 +
arch/arm/mach-omap2/{pm44xx.c => pm_omap4plus.c} | 90 ++++++++++--
arch/arm/mach-omap2/prminst44xx.c | 10 +-
.../mach-omap2/{sleep44xx.S => sleep_omap4plus.S} | 106 +++++++++++++
16 files changed, 512 insertions(+), 90 deletions(-)
rename arch/arm/mach-omap2/{cpuidle44xx.c => cpuidle_omap4plus.c} (58%)
rename arch/arm/mach-omap2/{pm44xx.c => pm_omap4plus.c} (74%)
rename arch/arm/mach-omap2/{sleep44xx.S => sleep_omap4plus.S} (77%)
--
Regards,
Santosh
[1] http://www.spinics.net/lists/arm-kernel/msg231512.html
[2] http://www.spinics.net/lists/arm-kernel/msg231513.html
[3] http://www.spinics.net/lists/arm-kernel/msg231514.html
[4] git://git.kernel.org/pub/scm/linux/kernel/git/ssantosh/linux.git testing/3.10/omap5_int
^ permalink raw reply [flat|nested] 128+ messages in thread
* [PATCH v2 00/18] ARM: OMAP5: PM: Add MPUSS suspend and CPUidle support
@ 2013-03-25 10:04 ` Santosh Shilimkar
0 siblings, 0 replies; 128+ messages in thread
From: Santosh Shilimkar @ 2013-03-25 10:04 UTC (permalink / raw)
To: linux-arm-kernel
Kevin,
Here is the refreshed version(v2) of the OMAP5 PM suspport which was posted
earlier (March 1st 2013). Patch-set incorporates comments from Nishant
Menon (Thanks for review NM) and his acked-by tags. I would like to get this
queued for 3.10 merge window if you are ok with the series.
Series is built on top of my pull requests [1] [2] [3] sent to Tony and your
'for_3.10/pm/cleanup' branch. For testing, I have created a branch [4]
which put together all the needed dependencies, fixes which should make it
to 3.10 merge window.
Series adds OMAP5 MPUSS power management support for system wide suspend
and CPUidle. Its heavy re-use from OMAP4 and hence only ~400 odd lines are
needed to add OMAP5 PM support on top of existing OMAP4 PM support.
OMAP5 adds a mercury retention feature which is an enhancement of
existing retention feature to reduce the leakage. No change in
programming model except one time enabling of mercury retention
during init.
One more notable change in OMAP5 vs OMAP4 devices, CPUx power domains
support retention state which lets you hit MPUSS and Core retention with
very low latency C-states.
Tested on OMAP4430 SDP, OMAP4460 Panda, OMAP5430 SDP and OMAP5432 Panda
devices with suspend and CPUIdle. Rootfs is mounted over ramdisk since
the mmc and nfs based fs needs DMA engine patches. For suspend wakeup,
I used Sourav's couple of serial wakeup wip patches from the lists.
The following changes since commit 9981cde24de52e5bb9a7cd918d1e54de241f85c9:
Merge branch 'for_3.10/omap5_data_files' of git://git.kernel.org/pub/scm/linux/kernel/git/ssantosh/linux into for_3.10/omap5_pm (2013-03-25 12:29:34 +0530)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/ssantosh/linux.git for_3.10/omap5_pm
for you to fetch changes up to 75bd846d3103da858a208fe07127151903d1f608:
ARM: OMAP5: PM: handle device instance for warm reset (2013-03-25 12:37:44 +0530)
----------------------------------------------------------------
Nishanth Menon (1):
ARM: OMAP5: PM: handle device instance for warm reset
Santosh Shilimkar (17):
ARM: OMAP4+: PM: Consolidate MPU subsystem PM code for re-use
ARM: OMAP5: PM: Update CPU context register offset
ARM: OMAP4+: PM: Consolidate and use OMAP4 PM code for OMAP5
ARM: OMAP5: PM: Set MPUSS-EMIF clock-domain static dependency
ARM: OMAP5: PM: Enables ES2 PM mode by default
ARM: OMAP5: PM: Enable Mercury retention mode on CPUx powerdomains
ARM: OMAP5: Add init_late() hook to enable pm initialization
ARM: OMAP5: PM: Add CPU power off in hotplug path
ARM: OMAP4+: PM: Restore CPU power state to ON with clockdomain force
wakeup method
ARM: OMAP5: PM: Add MPU Open Switch Retention support
ARM: OMAP5: PM: Add L2 memory power down support
ARM: OMAP4: CPUidle: Avoid double idle driver registration
ARM: OMAP: CPUidle: Unregister drivere on device registration failure
ARM: OMAP4: CPUidle: Make C-state description field more precise
ARM: OMAP4+: CPUidle: Consolidate idle driver for OMAP5 support
ARM: OMAP4+: CPUidle: Deprecate use of
omap4_mpuss_read_prev_context_state()
ARM: OMAP4+: CPUidle: Add OMAP5 idle driver support
arch/arm/mach-omap2/Kconfig | 1 +
arch/arm/mach-omap2/Makefile | 12 +-
arch/arm/mach-omap2/board-generic.c | 1 +
arch/arm/mach-omap2/common.h | 8 +-
arch/arm/mach-omap2/cpuidle34xx.c | 6 +-
.../{cpuidle44xx.c => cpuidle_omap4plus.c} | 151 ++++++++++++++++---
arch/arm/mach-omap2/io.c | 8 +
arch/arm/mach-omap2/omap-mpuss-lowpower.c | 155 +++++++++++++++-----
arch/arm/mach-omap2/omap-secure.h | 9 ++
arch/arm/mach-omap2/omap-smp.c | 12 +-
arch/arm/mach-omap2/omap-wakeupgen.c | 30 +++-
arch/arm/mach-omap2/omap-wakeupgen.h | 1 +
arch/arm/mach-omap2/omap4-sar-layout.h | 2 +
arch/arm/mach-omap2/{pm44xx.c => pm_omap4plus.c} | 90 ++++++++++--
arch/arm/mach-omap2/prminst44xx.c | 10 +-
.../mach-omap2/{sleep44xx.S => sleep_omap4plus.S} | 106 +++++++++++++
16 files changed, 512 insertions(+), 90 deletions(-)
rename arch/arm/mach-omap2/{cpuidle44xx.c => cpuidle_omap4plus.c} (58%)
rename arch/arm/mach-omap2/{pm44xx.c => pm_omap4plus.c} (74%)
rename arch/arm/mach-omap2/{sleep44xx.S => sleep_omap4plus.S} (77%)
--
Regards,
Santosh
[1] http://www.spinics.net/lists/arm-kernel/msg231512.html
[2] http://www.spinics.net/lists/arm-kernel/msg231513.html
[3] http://www.spinics.net/lists/arm-kernel/msg231514.html
[4] git://git.kernel.org/pub/scm/linux/kernel/git/ssantosh/linux.git testing/3.10/omap5_int
^ permalink raw reply [flat|nested] 128+ messages in thread
* [PATCH v2 01/18] ARM: OMAP4+: PM: Consolidate MPU subsystem PM code for re-use
2013-03-25 10:04 ` Santosh Shilimkar
@ 2013-03-25 10:04 ` Santosh Shilimkar
-1 siblings, 0 replies; 128+ messages in thread
From: Santosh Shilimkar @ 2013-03-25 10:04 UTC (permalink / raw)
To: khilman; +Cc: linux-omap, linux-arm-kernel, nm, tony, Santosh Shilimkar
OMAP5 and future OMAP based SOCs has backward compatible MPUSS
IP block with OMAP4. It's programming model is mostly similar.
Hence consolidate the OMAP MPUSS code so that it can be re-used
on OMAP5 and future SOCs.
No functional change.
Acked-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
---
arch/arm/mach-omap2/omap-mpuss-lowpower.c | 65 ++++++++++++++++++++++++-----
1 file changed, 54 insertions(+), 11 deletions(-)
diff --git a/arch/arm/mach-omap2/omap-mpuss-lowpower.c b/arch/arm/mach-omap2/omap-mpuss-lowpower.c
index d650f91..d9e4843 100644
--- a/arch/arm/mach-omap2/omap-mpuss-lowpower.c
+++ b/arch/arm/mach-omap2/omap-mpuss-lowpower.c
@@ -71,10 +71,46 @@ struct omap4_cpu_pm_info {
void (*secondary_startup)(void);
};
+/**
+ * struct cpu_pm_ops - CPU pm operations
+ * @finish_suspend: CPU suspend finisher function pointer
+ * @resume: CPU resume function pointer
+ * @scu_prepare: CPU Snoop Control program function pointer
+ *
+ * Structure holds functions pointer for CPU low power operations like
+ * suspend, resume and scu programming.
+ */
+struct cpu_pm_ops {
+ int (*finish_suspend)(unsigned long cpu_state);
+ void (*resume)(void);
+ void (*scu_prepare)(unsigned int cpu_id, unsigned int cpu_state);
+};
+
+extern int omap4_finish_suspend(unsigned long cpu_state);
+extern void omap4_cpu_resume(void);
+
static DEFINE_PER_CPU(struct omap4_cpu_pm_info, omap4_pm_info);
static struct powerdomain *mpuss_pd;
static void __iomem *sar_base;
+static int default_finish_suspend(unsigned long cpu_state)
+{
+ omap_do_wfi();
+ return 0;
+}
+
+static void dummy_cpu_resume(void)
+{}
+
+static void dummy_scu_prepare(unsigned int cpu_id, unsigned int cpu_state)
+{}
+
+struct cpu_pm_ops omap_pm_ops = {
+ .finish_suspend = default_finish_suspend,
+ .resume = dummy_cpu_resume,
+ .scu_prepare = dummy_scu_prepare,
+};
+
/*
* Program the wakeup routine address for the CPU0 and CPU1
* used for OFF or DORMANT wakeup.
@@ -172,11 +208,12 @@ static void save_l2x0_context(void)
{
u32 val;
void __iomem *l2x0_base = omap4_get_l2cache_base();
-
- val = __raw_readl(l2x0_base + L2X0_AUX_CTRL);
- __raw_writel(val, sar_base + L2X0_AUXCTRL_OFFSET);
- val = __raw_readl(l2x0_base + L2X0_PREFETCH_CTRL);
- __raw_writel(val, sar_base + L2X0_PREFETCH_CTRL_OFFSET);
+ if (l2x0_base) {
+ val = __raw_readl(l2x0_base + L2X0_AUX_CTRL);
+ __raw_writel(val, sar_base + L2X0_AUXCTRL_OFFSET);
+ val = __raw_readl(l2x0_base + L2X0_PREFETCH_CTRL);
+ __raw_writel(val, sar_base + L2X0_PREFETCH_CTRL_OFFSET);
+ }
}
#else
static void save_l2x0_context(void)
@@ -239,17 +276,17 @@ int omap4_enter_lowpower(unsigned int cpu, unsigned int power_state)
cpu_clear_prev_logic_pwrst(cpu);
pwrdm_set_next_pwrst(pm_info->pwrdm, power_state);
- set_cpu_wakeup_addr(cpu, virt_to_phys(omap4_cpu_resume));
- scu_pwrst_prepare(cpu, power_state);
+ set_cpu_wakeup_addr(cpu, virt_to_phys(omap_pm_ops.resume));
+ omap_pm_ops.scu_prepare(cpu, power_state);
l2x0_pwrst_prepare(cpu, save_state);
/*
* Call low level function with targeted low power state.
*/
if (save_state)
- cpu_suspend(save_state, omap4_finish_suspend);
+ cpu_suspend(save_state, omap_pm_ops.finish_suspend);
else
- omap4_finish_suspend(save_state);
+ omap_pm_ops.finish_suspend(save_state);
/*
* Restore the CPUx power state to ON otherwise CPUx
@@ -285,14 +322,14 @@ int __cpuinit omap4_hotplug_cpu(unsigned int cpu, unsigned int power_state)
pwrdm_clear_all_prev_pwrst(pm_info->pwrdm);
pwrdm_set_next_pwrst(pm_info->pwrdm, power_state);
set_cpu_wakeup_addr(cpu, virt_to_phys(pm_info->secondary_startup));
- scu_pwrst_prepare(cpu, power_state);
+ omap_pm_ops.scu_prepare(cpu, power_state);
/*
* CPU never retuns back if targeted power state is OFF mode.
* CPU ONLINE follows normal CPU ONLINE ptah via
* omap_secondary_startup().
*/
- omap4_finish_suspend(cpu_state);
+ omap_pm_ops.finish_suspend(cpu_state);
pwrdm_set_next_pwrst(pm_info->pwrdm, PWRDM_POWER_ON);
return 0;
@@ -369,6 +406,12 @@ int __init omap4_mpuss_init(void)
save_l2x0_context();
+ if (cpu_is_omap44xx()) {
+ omap_pm_ops.finish_suspend = omap4_finish_suspend;
+ omap_pm_ops.resume = omap4_cpu_resume;
+ omap_pm_ops.scu_prepare = scu_pwrst_prepare;
+ }
+
return 0;
}
--
1.7.9.5
^ permalink raw reply related [flat|nested] 128+ messages in thread
* [PATCH v2 01/18] ARM: OMAP4+: PM: Consolidate MPU subsystem PM code for re-use
@ 2013-03-25 10:04 ` Santosh Shilimkar
0 siblings, 0 replies; 128+ messages in thread
From: Santosh Shilimkar @ 2013-03-25 10:04 UTC (permalink / raw)
To: linux-arm-kernel
OMAP5 and future OMAP based SOCs has backward compatible MPUSS
IP block with OMAP4. It's programming model is mostly similar.
Hence consolidate the OMAP MPUSS code so that it can be re-used
on OMAP5 and future SOCs.
No functional change.
Acked-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
---
arch/arm/mach-omap2/omap-mpuss-lowpower.c | 65 ++++++++++++++++++++++++-----
1 file changed, 54 insertions(+), 11 deletions(-)
diff --git a/arch/arm/mach-omap2/omap-mpuss-lowpower.c b/arch/arm/mach-omap2/omap-mpuss-lowpower.c
index d650f91..d9e4843 100644
--- a/arch/arm/mach-omap2/omap-mpuss-lowpower.c
+++ b/arch/arm/mach-omap2/omap-mpuss-lowpower.c
@@ -71,10 +71,46 @@ struct omap4_cpu_pm_info {
void (*secondary_startup)(void);
};
+/**
+ * struct cpu_pm_ops - CPU pm operations
+ * @finish_suspend: CPU suspend finisher function pointer
+ * @resume: CPU resume function pointer
+ * @scu_prepare: CPU Snoop Control program function pointer
+ *
+ * Structure holds functions pointer for CPU low power operations like
+ * suspend, resume and scu programming.
+ */
+struct cpu_pm_ops {
+ int (*finish_suspend)(unsigned long cpu_state);
+ void (*resume)(void);
+ void (*scu_prepare)(unsigned int cpu_id, unsigned int cpu_state);
+};
+
+extern int omap4_finish_suspend(unsigned long cpu_state);
+extern void omap4_cpu_resume(void);
+
static DEFINE_PER_CPU(struct omap4_cpu_pm_info, omap4_pm_info);
static struct powerdomain *mpuss_pd;
static void __iomem *sar_base;
+static int default_finish_suspend(unsigned long cpu_state)
+{
+ omap_do_wfi();
+ return 0;
+}
+
+static void dummy_cpu_resume(void)
+{}
+
+static void dummy_scu_prepare(unsigned int cpu_id, unsigned int cpu_state)
+{}
+
+struct cpu_pm_ops omap_pm_ops = {
+ .finish_suspend = default_finish_suspend,
+ .resume = dummy_cpu_resume,
+ .scu_prepare = dummy_scu_prepare,
+};
+
/*
* Program the wakeup routine address for the CPU0 and CPU1
* used for OFF or DORMANT wakeup.
@@ -172,11 +208,12 @@ static void save_l2x0_context(void)
{
u32 val;
void __iomem *l2x0_base = omap4_get_l2cache_base();
-
- val = __raw_readl(l2x0_base + L2X0_AUX_CTRL);
- __raw_writel(val, sar_base + L2X0_AUXCTRL_OFFSET);
- val = __raw_readl(l2x0_base + L2X0_PREFETCH_CTRL);
- __raw_writel(val, sar_base + L2X0_PREFETCH_CTRL_OFFSET);
+ if (l2x0_base) {
+ val = __raw_readl(l2x0_base + L2X0_AUX_CTRL);
+ __raw_writel(val, sar_base + L2X0_AUXCTRL_OFFSET);
+ val = __raw_readl(l2x0_base + L2X0_PREFETCH_CTRL);
+ __raw_writel(val, sar_base + L2X0_PREFETCH_CTRL_OFFSET);
+ }
}
#else
static void save_l2x0_context(void)
@@ -239,17 +276,17 @@ int omap4_enter_lowpower(unsigned int cpu, unsigned int power_state)
cpu_clear_prev_logic_pwrst(cpu);
pwrdm_set_next_pwrst(pm_info->pwrdm, power_state);
- set_cpu_wakeup_addr(cpu, virt_to_phys(omap4_cpu_resume));
- scu_pwrst_prepare(cpu, power_state);
+ set_cpu_wakeup_addr(cpu, virt_to_phys(omap_pm_ops.resume));
+ omap_pm_ops.scu_prepare(cpu, power_state);
l2x0_pwrst_prepare(cpu, save_state);
/*
* Call low level function with targeted low power state.
*/
if (save_state)
- cpu_suspend(save_state, omap4_finish_suspend);
+ cpu_suspend(save_state, omap_pm_ops.finish_suspend);
else
- omap4_finish_suspend(save_state);
+ omap_pm_ops.finish_suspend(save_state);
/*
* Restore the CPUx power state to ON otherwise CPUx
@@ -285,14 +322,14 @@ int __cpuinit omap4_hotplug_cpu(unsigned int cpu, unsigned int power_state)
pwrdm_clear_all_prev_pwrst(pm_info->pwrdm);
pwrdm_set_next_pwrst(pm_info->pwrdm, power_state);
set_cpu_wakeup_addr(cpu, virt_to_phys(pm_info->secondary_startup));
- scu_pwrst_prepare(cpu, power_state);
+ omap_pm_ops.scu_prepare(cpu, power_state);
/*
* CPU never retuns back if targeted power state is OFF mode.
* CPU ONLINE follows normal CPU ONLINE ptah via
* omap_secondary_startup().
*/
- omap4_finish_suspend(cpu_state);
+ omap_pm_ops.finish_suspend(cpu_state);
pwrdm_set_next_pwrst(pm_info->pwrdm, PWRDM_POWER_ON);
return 0;
@@ -369,6 +406,12 @@ int __init omap4_mpuss_init(void)
save_l2x0_context();
+ if (cpu_is_omap44xx()) {
+ omap_pm_ops.finish_suspend = omap4_finish_suspend;
+ omap_pm_ops.resume = omap4_cpu_resume;
+ omap_pm_ops.scu_prepare = scu_pwrst_prepare;
+ }
+
return 0;
}
--
1.7.9.5
^ permalink raw reply related [flat|nested] 128+ messages in thread
* [PATCH v2 02/18] ARM: OMAP5: PM: Update CPU context register offset
2013-03-25 10:04 ` Santosh Shilimkar
@ 2013-03-25 10:04 ` Santosh Shilimkar
-1 siblings, 0 replies; 128+ messages in thread
From: Santosh Shilimkar @ 2013-03-25 10:04 UTC (permalink / raw)
To: khilman; +Cc: linux-omap, linux-arm-kernel, nm, tony, Santosh Shilimkar
On OMAP5, RM_CPUi_CPUi_CONTEXT offset has changed. Update the code
so that same code works for OMAP4+ devices.
Acked-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
---
arch/arm/mach-omap2/omap-mpuss-lowpower.c | 13 +++++++++----
1 file changed, 9 insertions(+), 4 deletions(-)
diff --git a/arch/arm/mach-omap2/omap-mpuss-lowpower.c b/arch/arm/mach-omap2/omap-mpuss-lowpower.c
index d9e4843..b1441b1 100644
--- a/arch/arm/mach-omap2/omap-mpuss-lowpower.c
+++ b/arch/arm/mach-omap2/omap-mpuss-lowpower.c
@@ -56,6 +56,7 @@
#include "omap4-sar-layout.h"
#include "pm.h"
#include "prcm_mpu44xx.h"
+#include "prcm_mpu54xx.h"
#include "prminst44xx.h"
#include "prcm44xx.h"
#include "prm44xx.h"
@@ -92,6 +93,7 @@ extern void omap4_cpu_resume(void);
static DEFINE_PER_CPU(struct omap4_cpu_pm_info, omap4_pm_info);
static struct powerdomain *mpuss_pd;
static void __iomem *sar_base;
+static u32 cpu_context_offset;
static int default_finish_suspend(unsigned long cpu_state)
{
@@ -164,14 +166,14 @@ static inline void cpu_clear_prev_logic_pwrst(unsigned int cpu_id)
if (cpu_id) {
reg = omap4_prcm_mpu_read_inst_reg(OMAP4430_PRCM_MPU_CPU1_INST,
- OMAP4_RM_CPU1_CPU1_CONTEXT_OFFSET);
+ cpu_context_offset);
omap4_prcm_mpu_write_inst_reg(reg, OMAP4430_PRCM_MPU_CPU1_INST,
- OMAP4_RM_CPU1_CPU1_CONTEXT_OFFSET);
+ cpu_context_offset);
} else {
reg = omap4_prcm_mpu_read_inst_reg(OMAP4430_PRCM_MPU_CPU0_INST,
- OMAP4_RM_CPU0_CPU0_CONTEXT_OFFSET);
+ cpu_context_offset);
omap4_prcm_mpu_write_inst_reg(reg, OMAP4430_PRCM_MPU_CPU0_INST,
- OMAP4_RM_CPU0_CPU0_CONTEXT_OFFSET);
+ cpu_context_offset);
}
}
@@ -410,6 +412,9 @@ int __init omap4_mpuss_init(void)
omap_pm_ops.finish_suspend = omap4_finish_suspend;
omap_pm_ops.resume = omap4_cpu_resume;
omap_pm_ops.scu_prepare = scu_pwrst_prepare;
+ cpu_context_offset = OMAP4_RM_CPU0_CPU0_CONTEXT_OFFSET;
+ } else if (soc_is_omap54xx()) {
+ cpu_context_offset = OMAP54XX_RM_CPU0_CPU0_CONTEXT_OFFSET;
}
return 0;
--
1.7.9.5
^ permalink raw reply related [flat|nested] 128+ messages in thread
* [PATCH v2 02/18] ARM: OMAP5: PM: Update CPU context register offset
@ 2013-03-25 10:04 ` Santosh Shilimkar
0 siblings, 0 replies; 128+ messages in thread
From: Santosh Shilimkar @ 2013-03-25 10:04 UTC (permalink / raw)
To: linux-arm-kernel
On OMAP5, RM_CPUi_CPUi_CONTEXT offset has changed. Update the code
so that same code works for OMAP4+ devices.
Acked-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
---
arch/arm/mach-omap2/omap-mpuss-lowpower.c | 13 +++++++++----
1 file changed, 9 insertions(+), 4 deletions(-)
diff --git a/arch/arm/mach-omap2/omap-mpuss-lowpower.c b/arch/arm/mach-omap2/omap-mpuss-lowpower.c
index d9e4843..b1441b1 100644
--- a/arch/arm/mach-omap2/omap-mpuss-lowpower.c
+++ b/arch/arm/mach-omap2/omap-mpuss-lowpower.c
@@ -56,6 +56,7 @@
#include "omap4-sar-layout.h"
#include "pm.h"
#include "prcm_mpu44xx.h"
+#include "prcm_mpu54xx.h"
#include "prminst44xx.h"
#include "prcm44xx.h"
#include "prm44xx.h"
@@ -92,6 +93,7 @@ extern void omap4_cpu_resume(void);
static DEFINE_PER_CPU(struct omap4_cpu_pm_info, omap4_pm_info);
static struct powerdomain *mpuss_pd;
static void __iomem *sar_base;
+static u32 cpu_context_offset;
static int default_finish_suspend(unsigned long cpu_state)
{
@@ -164,14 +166,14 @@ static inline void cpu_clear_prev_logic_pwrst(unsigned int cpu_id)
if (cpu_id) {
reg = omap4_prcm_mpu_read_inst_reg(OMAP4430_PRCM_MPU_CPU1_INST,
- OMAP4_RM_CPU1_CPU1_CONTEXT_OFFSET);
+ cpu_context_offset);
omap4_prcm_mpu_write_inst_reg(reg, OMAP4430_PRCM_MPU_CPU1_INST,
- OMAP4_RM_CPU1_CPU1_CONTEXT_OFFSET);
+ cpu_context_offset);
} else {
reg = omap4_prcm_mpu_read_inst_reg(OMAP4430_PRCM_MPU_CPU0_INST,
- OMAP4_RM_CPU0_CPU0_CONTEXT_OFFSET);
+ cpu_context_offset);
omap4_prcm_mpu_write_inst_reg(reg, OMAP4430_PRCM_MPU_CPU0_INST,
- OMAP4_RM_CPU0_CPU0_CONTEXT_OFFSET);
+ cpu_context_offset);
}
}
@@ -410,6 +412,9 @@ int __init omap4_mpuss_init(void)
omap_pm_ops.finish_suspend = omap4_finish_suspend;
omap_pm_ops.resume = omap4_cpu_resume;
omap_pm_ops.scu_prepare = scu_pwrst_prepare;
+ cpu_context_offset = OMAP4_RM_CPU0_CPU0_CONTEXT_OFFSET;
+ } else if (soc_is_omap54xx()) {
+ cpu_context_offset = OMAP54XX_RM_CPU0_CPU0_CONTEXT_OFFSET;
}
return 0;
--
1.7.9.5
^ permalink raw reply related [flat|nested] 128+ messages in thread
* [PATCH v2 03/18] ARM: OMAP4+: PM: Consolidate and use OMAP4 PM code for OMAP5
2013-03-25 10:04 ` Santosh Shilimkar
@ 2013-03-25 10:04 ` Santosh Shilimkar
-1 siblings, 0 replies; 128+ messages in thread
From: Santosh Shilimkar @ 2013-03-25 10:04 UTC (permalink / raw)
To: khilman; +Cc: linux-omap, linux-arm-kernel, nm, tony, Santosh Shilimkar
OMAP5 has backward compatible PRCM block and it's programming
model is mostly similar to OMAP4. Same is going to be maintained
for future OMAP4 based SOCs. Hence consolidate the OMAP4 power
management code so that it can be re-used on OMAP5 and later devices.
With consolidated code, let basic power management code build
for OMAP5 devices. While at it, update the kernel-doc for omap4_pm_init().
Acked-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
---
arch/arm/mach-omap2/Makefile | 9 ++--
arch/arm/mach-omap2/{pm44xx.c => pm_omap4plus.c} | 54 ++++++++++++++++----
.../mach-omap2/{sleep44xx.S => sleep_omap4plus.S} | 0
3 files changed, 49 insertions(+), 14 deletions(-)
rename arch/arm/mach-omap2/{pm44xx.c => pm_omap4plus.c} (86%)
rename arch/arm/mach-omap2/{sleep44xx.S => sleep_omap4plus.S} (100%)
diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index 5d5ff91..d91ae0f 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -35,14 +35,14 @@ obj-$(CONFIG_SOC_HAS_OMAP2_SDRC) += sdrc.o
obj-$(CONFIG_SMP) += omap-smp.o omap-headsmp.o
obj-$(CONFIG_HOTPLUG_CPU) += omap-hotplug.o
omap-4-5-common = omap4-common.o omap-wakeupgen.o \
- sleep44xx.o
+ sleep_omap4plus.o
obj-$(CONFIG_ARCH_OMAP4) += $(omap-4-5-common)
obj-$(CONFIG_SOC_OMAP5) += $(omap-4-5-common)
plus_sec := $(call as-instr,.arch_extension sec,+sec)
AFLAGS_omap-headsmp.o :=-Wa,-march=armv7-a$(plus_sec)
AFLAGS_omap-smc.o :=-Wa,-march=armv7-a$(plus_sec)
-AFLAGS_sleep44xx.o :=-Wa,-march=armv7-a$(plus_sec)
+AFLAGS_sleep_omap4plus.o :=-Wa,-march=armv7-a$(plus_sec)
# Functions loaded to SRAM
obj-$(CONFIG_SOC_OMAP2420) += sram242x.o
@@ -80,11 +80,12 @@ endif
obj-$(CONFIG_OMAP_PM_NOOP) += omap-pm-noop.o
ifeq ($(CONFIG_PM),y)
+omap4plus-common-pm = omap-mpuss-lowpower.o pm_omap4plus.o
obj-$(CONFIG_ARCH_OMAP2) += pm24xx.o
obj-$(CONFIG_ARCH_OMAP2) += sleep24xx.o
obj-$(CONFIG_ARCH_OMAP3) += pm34xx.o sleep34xx.o
-obj-$(CONFIG_ARCH_OMAP4) += pm44xx.o omap-mpuss-lowpower.o
-obj-$(CONFIG_SOC_OMAP5) += omap-mpuss-lowpower.o
+obj-$(CONFIG_ARCH_OMAP4) += $(omap4plus-common-pm)
+obj-$(CONFIG_SOC_OMAP5) += $(omap4plus-common-pm)
obj-$(CONFIG_PM_DEBUG) += pm-debug.o
obj-$(CONFIG_POWER_AVS_OMAP) += sr_device.o
diff --git a/arch/arm/mach-omap2/pm44xx.c b/arch/arm/mach-omap2/pm_omap4plus.c
similarity index 86%
rename from arch/arm/mach-omap2/pm44xx.c
rename to arch/arm/mach-omap2/pm_omap4plus.c
index 5ba6d88..e920c34 100644
--- a/arch/arm/mach-omap2/pm44xx.c
+++ b/arch/arm/mach-omap2/pm_omap4plus.c
@@ -1,7 +1,7 @@
/*
- * OMAP4 Power Management Routines
+ * OMAP4PLUS Power Management Routines
*
- * Copyright (C) 2010-2011 Texas Instruments, Inc.
+ * Copyright (C) 2010-2013 Texas Instruments, Inc.
* Rajendra Nayak <rnayak@ti.com>
* Santosh Shilimkar <santosh.shilimkar@ti.com>
*
@@ -135,16 +135,16 @@ static void omap_default_idle(void)
}
/**
- * omap4_pm_init - Init routine for OMAP4 PM
+ * omap4_init_static_deps - Add OMAP4 static dependencies
*
- * Initializes all powerdomain and clockdomain target states
- * and all PRCM settings.
+ * Add needed static clockdomain dependencies on OMAP4 devices.
+ * Return: 0 on success or 'err' on failures
*/
-int __init omap4_pm_init(void)
+static inline int omap4_init_static_deps(void)
{
- int ret;
struct clockdomain *emif_clkdm, *mpuss_clkdm, *l3_1_clkdm;
struct clockdomain *ducati_clkdm, *l3_2_clkdm;
+ int ret = 0;
if (omap_rev() == OMAP4430_REV_ES1_0) {
WARN(1, "Power Management not supported on OMAP4430 ES1.0\n");
@@ -163,7 +163,7 @@ int __init omap4_pm_init(void)
ret = pwrdm_for_each(pwrdms_setup, NULL);
if (ret) {
pr_err("Failed to setup powerdomains\n");
- goto err2;
+ return ret;
}
/*
@@ -179,7 +179,7 @@ int __init omap4_pm_init(void)
ducati_clkdm = clkdm_lookup("ducati_clkdm");
if ((!mpuss_clkdm) || (!emif_clkdm) || (!l3_1_clkdm) ||
(!l3_2_clkdm) || (!ducati_clkdm))
- goto err2;
+ return -EINVAL;
ret = clkdm_add_wkdep(mpuss_clkdm, emif_clkdm);
ret |= clkdm_add_wkdep(mpuss_clkdm, l3_1_clkdm);
@@ -188,9 +188,42 @@ int __init omap4_pm_init(void)
ret |= clkdm_add_wkdep(ducati_clkdm, l3_2_clkdm);
if (ret) {
pr_err("Failed to add MPUSS -> L3/EMIF/L4PER, DUCATI -> L3 wakeup dependency\n");
+ return -EINVAL;
+ }
+
+ return ret;
+}
+
+/**
+ * omap4_pm_init - Init routine for OMAP4+ devices
+ *
+ * Initializes all powerdomain and clockdomain target states
+ * and all PRCM settings.
+ * Return: Returns the error code returned by called functions.
+ */
+int __init omap4_pm_init(void)
+{
+ int ret = 0;
+
+ if (omap_rev() == OMAP4430_REV_ES1_0) {
+ WARN(1, "Power Management not supported on OMAP4430 ES1.0\n");
+ return -ENODEV;
+ }
+
+ pr_info("Power Management for TI OMAP4PLUS devices.\n");
+
+ ret = pwrdm_for_each(pwrdms_setup, NULL);
+ if (ret) {
+ pr_err("Failed to setup powerdomains.\n");
goto err2;
}
+ if (cpu_is_omap44xx()) {
+ ret = omap4_init_static_deps();
+ if (ret)
+ goto err2;
+ }
+
ret = omap4_mpuss_init();
if (ret) {
pr_err("Failed to initialise OMAP4 MPUSS\n");
@@ -206,7 +239,8 @@ int __init omap4_pm_init(void)
/* Overwrite the default cpu_do_idle() */
arm_pm_idle = omap_default_idle;
- omap4_idle_init();
+ if (cpu_is_omap44xx())
+ omap4_idle_init();
err2:
return ret;
diff --git a/arch/arm/mach-omap2/sleep44xx.S b/arch/arm/mach-omap2/sleep_omap4plus.S
similarity index 100%
rename from arch/arm/mach-omap2/sleep44xx.S
rename to arch/arm/mach-omap2/sleep_omap4plus.S
--
1.7.9.5
^ permalink raw reply related [flat|nested] 128+ messages in thread
* [PATCH v2 03/18] ARM: OMAP4+: PM: Consolidate and use OMAP4 PM code for OMAP5
@ 2013-03-25 10:04 ` Santosh Shilimkar
0 siblings, 0 replies; 128+ messages in thread
From: Santosh Shilimkar @ 2013-03-25 10:04 UTC (permalink / raw)
To: linux-arm-kernel
OMAP5 has backward compatible PRCM block and it's programming
model is mostly similar to OMAP4. Same is going to be maintained
for future OMAP4 based SOCs. Hence consolidate the OMAP4 power
management code so that it can be re-used on OMAP5 and later devices.
With consolidated code, let basic power management code build
for OMAP5 devices. While at it, update the kernel-doc for omap4_pm_init().
Acked-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
---
arch/arm/mach-omap2/Makefile | 9 ++--
arch/arm/mach-omap2/{pm44xx.c => pm_omap4plus.c} | 54 ++++++++++++++++----
.../mach-omap2/{sleep44xx.S => sleep_omap4plus.S} | 0
3 files changed, 49 insertions(+), 14 deletions(-)
rename arch/arm/mach-omap2/{pm44xx.c => pm_omap4plus.c} (86%)
rename arch/arm/mach-omap2/{sleep44xx.S => sleep_omap4plus.S} (100%)
diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index 5d5ff91..d91ae0f 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -35,14 +35,14 @@ obj-$(CONFIG_SOC_HAS_OMAP2_SDRC) += sdrc.o
obj-$(CONFIG_SMP) += omap-smp.o omap-headsmp.o
obj-$(CONFIG_HOTPLUG_CPU) += omap-hotplug.o
omap-4-5-common = omap4-common.o omap-wakeupgen.o \
- sleep44xx.o
+ sleep_omap4plus.o
obj-$(CONFIG_ARCH_OMAP4) += $(omap-4-5-common)
obj-$(CONFIG_SOC_OMAP5) += $(omap-4-5-common)
plus_sec := $(call as-instr,.arch_extension sec,+sec)
AFLAGS_omap-headsmp.o :=-Wa,-march=armv7-a$(plus_sec)
AFLAGS_omap-smc.o :=-Wa,-march=armv7-a$(plus_sec)
-AFLAGS_sleep44xx.o :=-Wa,-march=armv7-a$(plus_sec)
+AFLAGS_sleep_omap4plus.o :=-Wa,-march=armv7-a$(plus_sec)
# Functions loaded to SRAM
obj-$(CONFIG_SOC_OMAP2420) += sram242x.o
@@ -80,11 +80,12 @@ endif
obj-$(CONFIG_OMAP_PM_NOOP) += omap-pm-noop.o
ifeq ($(CONFIG_PM),y)
+omap4plus-common-pm = omap-mpuss-lowpower.o pm_omap4plus.o
obj-$(CONFIG_ARCH_OMAP2) += pm24xx.o
obj-$(CONFIG_ARCH_OMAP2) += sleep24xx.o
obj-$(CONFIG_ARCH_OMAP3) += pm34xx.o sleep34xx.o
-obj-$(CONFIG_ARCH_OMAP4) += pm44xx.o omap-mpuss-lowpower.o
-obj-$(CONFIG_SOC_OMAP5) += omap-mpuss-lowpower.o
+obj-$(CONFIG_ARCH_OMAP4) += $(omap4plus-common-pm)
+obj-$(CONFIG_SOC_OMAP5) += $(omap4plus-common-pm)
obj-$(CONFIG_PM_DEBUG) += pm-debug.o
obj-$(CONFIG_POWER_AVS_OMAP) += sr_device.o
diff --git a/arch/arm/mach-omap2/pm44xx.c b/arch/arm/mach-omap2/pm_omap4plus.c
similarity index 86%
rename from arch/arm/mach-omap2/pm44xx.c
rename to arch/arm/mach-omap2/pm_omap4plus.c
index 5ba6d88..e920c34 100644
--- a/arch/arm/mach-omap2/pm44xx.c
+++ b/arch/arm/mach-omap2/pm_omap4plus.c
@@ -1,7 +1,7 @@
/*
- * OMAP4 Power Management Routines
+ * OMAP4PLUS Power Management Routines
*
- * Copyright (C) 2010-2011 Texas Instruments, Inc.
+ * Copyright (C) 2010-2013 Texas Instruments, Inc.
* Rajendra Nayak <rnayak@ti.com>
* Santosh Shilimkar <santosh.shilimkar@ti.com>
*
@@ -135,16 +135,16 @@ static void omap_default_idle(void)
}
/**
- * omap4_pm_init - Init routine for OMAP4 PM
+ * omap4_init_static_deps - Add OMAP4 static dependencies
*
- * Initializes all powerdomain and clockdomain target states
- * and all PRCM settings.
+ * Add needed static clockdomain dependencies on OMAP4 devices.
+ * Return: 0 on success or 'err' on failures
*/
-int __init omap4_pm_init(void)
+static inline int omap4_init_static_deps(void)
{
- int ret;
struct clockdomain *emif_clkdm, *mpuss_clkdm, *l3_1_clkdm;
struct clockdomain *ducati_clkdm, *l3_2_clkdm;
+ int ret = 0;
if (omap_rev() == OMAP4430_REV_ES1_0) {
WARN(1, "Power Management not supported on OMAP4430 ES1.0\n");
@@ -163,7 +163,7 @@ int __init omap4_pm_init(void)
ret = pwrdm_for_each(pwrdms_setup, NULL);
if (ret) {
pr_err("Failed to setup powerdomains\n");
- goto err2;
+ return ret;
}
/*
@@ -179,7 +179,7 @@ int __init omap4_pm_init(void)
ducati_clkdm = clkdm_lookup("ducati_clkdm");
if ((!mpuss_clkdm) || (!emif_clkdm) || (!l3_1_clkdm) ||
(!l3_2_clkdm) || (!ducati_clkdm))
- goto err2;
+ return -EINVAL;
ret = clkdm_add_wkdep(mpuss_clkdm, emif_clkdm);
ret |= clkdm_add_wkdep(mpuss_clkdm, l3_1_clkdm);
@@ -188,9 +188,42 @@ int __init omap4_pm_init(void)
ret |= clkdm_add_wkdep(ducati_clkdm, l3_2_clkdm);
if (ret) {
pr_err("Failed to add MPUSS -> L3/EMIF/L4PER, DUCATI -> L3 wakeup dependency\n");
+ return -EINVAL;
+ }
+
+ return ret;
+}
+
+/**
+ * omap4_pm_init - Init routine for OMAP4+ devices
+ *
+ * Initializes all powerdomain and clockdomain target states
+ * and all PRCM settings.
+ * Return: Returns the error code returned by called functions.
+ */
+int __init omap4_pm_init(void)
+{
+ int ret = 0;
+
+ if (omap_rev() == OMAP4430_REV_ES1_0) {
+ WARN(1, "Power Management not supported on OMAP4430 ES1.0\n");
+ return -ENODEV;
+ }
+
+ pr_info("Power Management for TI OMAP4PLUS devices.\n");
+
+ ret = pwrdm_for_each(pwrdms_setup, NULL);
+ if (ret) {
+ pr_err("Failed to setup powerdomains.\n");
goto err2;
}
+ if (cpu_is_omap44xx()) {
+ ret = omap4_init_static_deps();
+ if (ret)
+ goto err2;
+ }
+
ret = omap4_mpuss_init();
if (ret) {
pr_err("Failed to initialise OMAP4 MPUSS\n");
@@ -206,7 +239,8 @@ int __init omap4_pm_init(void)
/* Overwrite the default cpu_do_idle() */
arm_pm_idle = omap_default_idle;
- omap4_idle_init();
+ if (cpu_is_omap44xx())
+ omap4_idle_init();
err2:
return ret;
diff --git a/arch/arm/mach-omap2/sleep44xx.S b/arch/arm/mach-omap2/sleep_omap4plus.S
similarity index 100%
rename from arch/arm/mach-omap2/sleep44xx.S
rename to arch/arm/mach-omap2/sleep_omap4plus.S
--
1.7.9.5
^ permalink raw reply related [flat|nested] 128+ messages in thread
* [PATCH v2 04/18] ARM: OMAP5: PM: Set MPUSS-EMIF clock-domain static dependency
2013-03-25 10:04 ` Santosh Shilimkar
@ 2013-03-25 10:04 ` Santosh Shilimkar
-1 siblings, 0 replies; 128+ messages in thread
From: Santosh Shilimkar @ 2013-03-25 10:04 UTC (permalink / raw)
To: khilman; +Cc: linux-omap, linux-arm-kernel, nm, tony, Santosh Shilimkar
With EMIF clock-domain put under hardware supervised control, memory
corruption and untraceable crashes are observed on OMAP5. Further
investigation revealed that there is a weakness in the PRCM on this
specific dynamic dependency.
Async bridge issue which resulted in memory corruption and lock on
OMAP4 continue to exist on OMAP5 too unfortunately and hence the
MPU -> EMIF static dependency continue to be there.
Acked-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
---
arch/arm/mach-omap2/pm_omap4plus.c | 42 +++++++++++++++++++++++++++++++++---
1 file changed, 39 insertions(+), 3 deletions(-)
diff --git a/arch/arm/mach-omap2/pm_omap4plus.c b/arch/arm/mach-omap2/pm_omap4plus.c
index e920c34..2dadb4e 100644
--- a/arch/arm/mach-omap2/pm_omap4plus.c
+++ b/arch/arm/mach-omap2/pm_omap4plus.c
@@ -195,6 +195,37 @@ static inline int omap4_init_static_deps(void)
}
/**
+ * omap5_init_static_deps - Add OMAP5 static dependencies
+ *
+ * Add needed static clockdomain dependencies on OMAP5 devices.
+ * Return: 0 on success or 'err' on failures
+ */
+static inline int omap5_init_static_deps(void)
+{
+ struct clockdomain *mpuss_clkdm, *emif_clkdm;
+ int ret = 0;
+
+ /*
+ * The dynamic dependency between MPUSS -> EMIF is broken and has
+ * not worked as expected on OMAP5 too. Async bridge issue which
+ * resulted in memory corruption and lock on OMAP4 continue to
+ * exist on OMAP5 too and hence the MPU -> EMIF dependency to avoid
+ * random crashes and lockups.
+ */
+ mpuss_clkdm = clkdm_lookup("mpu_clkdm");
+ emif_clkdm = clkdm_lookup("emif_clkdm");
+ if (!mpuss_clkdm || !emif_clkdm)
+ return -EINVAL;
+
+ ret = clkdm_add_wkdep(mpuss_clkdm, emif_clkdm);
+ if (ret)
+ pr_err("%s: Failed to add static dependency with %d\n",
+ __func__, ret);
+
+ return ret;
+}
+
+/**
* omap4_pm_init - Init routine for OMAP4+ devices
*
* Initializes all powerdomain and clockdomain target states
@@ -218,10 +249,15 @@ int __init omap4_pm_init(void)
goto err2;
}
- if (cpu_is_omap44xx()) {
+ if (cpu_is_omap44xx())
ret = omap4_init_static_deps();
- if (ret)
- goto err2;
+ else if (soc_is_omap54xx())
+ ret = omap5_init_static_deps();
+
+ if (ret) {
+ pr_err("%s: Failed to initialise static dependency with %d\n",
+ __func__, ret);
+ goto err2;
}
ret = omap4_mpuss_init();
--
1.7.9.5
^ permalink raw reply related [flat|nested] 128+ messages in thread
* [PATCH v2 04/18] ARM: OMAP5: PM: Set MPUSS-EMIF clock-domain static dependency
@ 2013-03-25 10:04 ` Santosh Shilimkar
0 siblings, 0 replies; 128+ messages in thread
From: Santosh Shilimkar @ 2013-03-25 10:04 UTC (permalink / raw)
To: linux-arm-kernel
With EMIF clock-domain put under hardware supervised control, memory
corruption and untraceable crashes are observed on OMAP5. Further
investigation revealed that there is a weakness in the PRCM on this
specific dynamic dependency.
Async bridge issue which resulted in memory corruption and lock on
OMAP4 continue to exist on OMAP5 too unfortunately and hence the
MPU -> EMIF static dependency continue to be there.
Acked-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
---
arch/arm/mach-omap2/pm_omap4plus.c | 42 +++++++++++++++++++++++++++++++++---
1 file changed, 39 insertions(+), 3 deletions(-)
diff --git a/arch/arm/mach-omap2/pm_omap4plus.c b/arch/arm/mach-omap2/pm_omap4plus.c
index e920c34..2dadb4e 100644
--- a/arch/arm/mach-omap2/pm_omap4plus.c
+++ b/arch/arm/mach-omap2/pm_omap4plus.c
@@ -195,6 +195,37 @@ static inline int omap4_init_static_deps(void)
}
/**
+ * omap5_init_static_deps - Add OMAP5 static dependencies
+ *
+ * Add needed static clockdomain dependencies on OMAP5 devices.
+ * Return: 0 on success or 'err' on failures
+ */
+static inline int omap5_init_static_deps(void)
+{
+ struct clockdomain *mpuss_clkdm, *emif_clkdm;
+ int ret = 0;
+
+ /*
+ * The dynamic dependency between MPUSS -> EMIF is broken and has
+ * not worked as expected on OMAP5 too. Async bridge issue which
+ * resulted in memory corruption and lock on OMAP4 continue to
+ * exist on OMAP5 too and hence the MPU -> EMIF dependency to avoid
+ * random crashes and lockups.
+ */
+ mpuss_clkdm = clkdm_lookup("mpu_clkdm");
+ emif_clkdm = clkdm_lookup("emif_clkdm");
+ if (!mpuss_clkdm || !emif_clkdm)
+ return -EINVAL;
+
+ ret = clkdm_add_wkdep(mpuss_clkdm, emif_clkdm);
+ if (ret)
+ pr_err("%s: Failed to add static dependency with %d\n",
+ __func__, ret);
+
+ return ret;
+}
+
+/**
* omap4_pm_init - Init routine for OMAP4+ devices
*
* Initializes all powerdomain and clockdomain target states
@@ -218,10 +249,15 @@ int __init omap4_pm_init(void)
goto err2;
}
- if (cpu_is_omap44xx()) {
+ if (cpu_is_omap44xx())
ret = omap4_init_static_deps();
- if (ret)
- goto err2;
+ else if (soc_is_omap54xx())
+ ret = omap5_init_static_deps();
+
+ if (ret) {
+ pr_err("%s: Failed to initialise static dependency with %d\n",
+ __func__, ret);
+ goto err2;
}
ret = omap4_mpuss_init();
--
1.7.9.5
^ permalink raw reply related [flat|nested] 128+ messages in thread
* [PATCH v2 05/18] ARM: OMAP5: PM: Enables ES2 PM mode by default
2013-03-25 10:04 ` Santosh Shilimkar
@ 2013-03-25 10:04 ` Santosh Shilimkar
-1 siblings, 0 replies; 128+ messages in thread
From: Santosh Shilimkar @ 2013-03-25 10:04 UTC (permalink / raw)
To: khilman; +Cc: linux-omap, linux-arm-kernel, nm, tony, Santosh Shilimkar
Enables MPUSS ES2 power management mode using ES2_PM_MODE in
AMBA_IF_MODE register.
0x0: ES1 behavior, CPU cores would enter and exit OFF mode together. Broken
0x1: ES2 behavior, CPU cores are allowed to enter/exit OFF mode independently.
The AMBA_IF_MODE register value is stored on SAR RAM and restored by
ROM code.
Acked-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
---
arch/arm/mach-omap2/omap-secure.h | 2 ++
arch/arm/mach-omap2/omap-wakeupgen.c | 19 +++++++++++++++++++
arch/arm/mach-omap2/omap-wakeupgen.h | 1 +
3 files changed, 22 insertions(+)
diff --git a/arch/arm/mach-omap2/omap-secure.h b/arch/arm/mach-omap2/omap-secure.h
index 0e72917..82b3c4c 100644
--- a/arch/arm/mach-omap2/omap-secure.h
+++ b/arch/arm/mach-omap2/omap-secure.h
@@ -42,6 +42,8 @@
#define OMAP4_MON_L2X0_AUXCTRL_INDEX 0x109
#define OMAP4_MON_L2X0_PREFETCH_INDEX 0x113
+#define OMAP5_MON_AMBA_IF_INDEX 0x108
+
/* Secure PPA(Primary Protected Application) APIs */
#define OMAP4_PPA_L2_POR_INDEX 0x23
#define OMAP4_PPA_CPU_ACTRL_SMP_INDEX 0x25
diff --git a/arch/arm/mach-omap2/omap-wakeupgen.c b/arch/arm/mach-omap2/omap-wakeupgen.c
index f8bb3b9..8bcaa8c 100644
--- a/arch/arm/mach-omap2/omap-wakeupgen.c
+++ b/arch/arm/mach-omap2/omap-wakeupgen.c
@@ -42,6 +42,7 @@
#define CPU1_ID 0x1
#define OMAP4_NR_BANKS 4
#define OMAP4_NR_IRQS 128
+#define OMAP5_AMBA_IF_PM_MODE (1 << 5)
static void __iomem *wakeupgen_base;
static void __iomem *sar_base;
@@ -265,6 +266,11 @@ static inline void omap5_irq_save_context(void)
val = __raw_readl(wakeupgen_base + OMAP_AUX_CORE_BOOT_0);
__raw_writel(val, sar_base + OMAP5_AUXCOREBOOT1_OFFSET);
+ /* Save AMBA_IF_PM_MODE regsiter */
+ val = __raw_readl(wakeupgen_base + OMAP_AMBA_IF_MODE);
+ val |= OMAP5_AMBA_IF_PM_MODE;
+ __raw_writel(val, sar_base + OMAP5_AMBA_IF_MODE_OFFSET);
+
/* Set the Backup Bit Mask status */
val = __raw_readl(sar_base + OMAP5_SAR_BACKUP_STATUS_OFFSET);
val |= SAR_BACKUP_STATUS_WAKEUPGEN;
@@ -402,6 +408,7 @@ int __init omap_wakeupgen_init(void)
{
int i;
unsigned int boot_cpu = smp_processor_id();
+ u32 val;
/* Not supported on OMAP4 ES1.0 silicon */
if (omap_rev() == OMAP4430_REV_ES1_0) {
@@ -443,6 +450,18 @@ int __init omap_wakeupgen_init(void)
for (i = 0; i < max_irqs; i++)
irq_target_cpu[i] = boot_cpu;
+ /*
+ * Enables OMAP5 ES2 PM Mode using ES2_PM_MODE in AMBA_IF_MODE
+ * 0x0: ES1 behavior, CPU cores would enter and exit OFF mode together.
+ * 0x1: ES2 behavior, CPU cores are allowed to enter/exit OFF mode
+ * independently.
+ */
+ if (soc_is_omap54xx()) {
+ val = __raw_readl(wakeupgen_base + OMAP_AMBA_IF_MODE);
+ val |= OMAP5_AMBA_IF_PM_MODE;
+ omap_smc1(OMAP5_MON_AMBA_IF_INDEX, val);
+ }
+
irq_hotplug_init();
irq_pm_init();
diff --git a/arch/arm/mach-omap2/omap-wakeupgen.h b/arch/arm/mach-omap2/omap-wakeupgen.h
index b0fd16f..b3c8ecc 100644
--- a/arch/arm/mach-omap2/omap-wakeupgen.h
+++ b/arch/arm/mach-omap2/omap-wakeupgen.h
@@ -27,6 +27,7 @@
#define OMAP_WKG_ENB_E_1 0x420
#define OMAP_AUX_CORE_BOOT_0 0x800
#define OMAP_AUX_CORE_BOOT_1 0x804
+#define OMAP_AMBA_IF_MODE 0x80c
#define OMAP_PTMSYNCREQ_MASK 0xc00
#define OMAP_PTMSYNCREQ_EN 0xc04
#define OMAP_TIMESTAMPCYCLELO 0xc08
--
1.7.9.5
^ permalink raw reply related [flat|nested] 128+ messages in thread
* [PATCH v2 05/18] ARM: OMAP5: PM: Enables ES2 PM mode by default
@ 2013-03-25 10:04 ` Santosh Shilimkar
0 siblings, 0 replies; 128+ messages in thread
From: Santosh Shilimkar @ 2013-03-25 10:04 UTC (permalink / raw)
To: linux-arm-kernel
Enables MPUSS ES2 power management mode using ES2_PM_MODE in
AMBA_IF_MODE register.
0x0: ES1 behavior, CPU cores would enter and exit OFF mode together. Broken
0x1: ES2 behavior, CPU cores are allowed to enter/exit OFF mode independently.
The AMBA_IF_MODE register value is stored on SAR RAM and restored by
ROM code.
Acked-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
---
arch/arm/mach-omap2/omap-secure.h | 2 ++
arch/arm/mach-omap2/omap-wakeupgen.c | 19 +++++++++++++++++++
arch/arm/mach-omap2/omap-wakeupgen.h | 1 +
3 files changed, 22 insertions(+)
diff --git a/arch/arm/mach-omap2/omap-secure.h b/arch/arm/mach-omap2/omap-secure.h
index 0e72917..82b3c4c 100644
--- a/arch/arm/mach-omap2/omap-secure.h
+++ b/arch/arm/mach-omap2/omap-secure.h
@@ -42,6 +42,8 @@
#define OMAP4_MON_L2X0_AUXCTRL_INDEX 0x109
#define OMAP4_MON_L2X0_PREFETCH_INDEX 0x113
+#define OMAP5_MON_AMBA_IF_INDEX 0x108
+
/* Secure PPA(Primary Protected Application) APIs */
#define OMAP4_PPA_L2_POR_INDEX 0x23
#define OMAP4_PPA_CPU_ACTRL_SMP_INDEX 0x25
diff --git a/arch/arm/mach-omap2/omap-wakeupgen.c b/arch/arm/mach-omap2/omap-wakeupgen.c
index f8bb3b9..8bcaa8c 100644
--- a/arch/arm/mach-omap2/omap-wakeupgen.c
+++ b/arch/arm/mach-omap2/omap-wakeupgen.c
@@ -42,6 +42,7 @@
#define CPU1_ID 0x1
#define OMAP4_NR_BANKS 4
#define OMAP4_NR_IRQS 128
+#define OMAP5_AMBA_IF_PM_MODE (1 << 5)
static void __iomem *wakeupgen_base;
static void __iomem *sar_base;
@@ -265,6 +266,11 @@ static inline void omap5_irq_save_context(void)
val = __raw_readl(wakeupgen_base + OMAP_AUX_CORE_BOOT_0);
__raw_writel(val, sar_base + OMAP5_AUXCOREBOOT1_OFFSET);
+ /* Save AMBA_IF_PM_MODE regsiter */
+ val = __raw_readl(wakeupgen_base + OMAP_AMBA_IF_MODE);
+ val |= OMAP5_AMBA_IF_PM_MODE;
+ __raw_writel(val, sar_base + OMAP5_AMBA_IF_MODE_OFFSET);
+
/* Set the Backup Bit Mask status */
val = __raw_readl(sar_base + OMAP5_SAR_BACKUP_STATUS_OFFSET);
val |= SAR_BACKUP_STATUS_WAKEUPGEN;
@@ -402,6 +408,7 @@ int __init omap_wakeupgen_init(void)
{
int i;
unsigned int boot_cpu = smp_processor_id();
+ u32 val;
/* Not supported on OMAP4 ES1.0 silicon */
if (omap_rev() == OMAP4430_REV_ES1_0) {
@@ -443,6 +450,18 @@ int __init omap_wakeupgen_init(void)
for (i = 0; i < max_irqs; i++)
irq_target_cpu[i] = boot_cpu;
+ /*
+ * Enables OMAP5 ES2 PM Mode using ES2_PM_MODE in AMBA_IF_MODE
+ * 0x0: ES1 behavior, CPU cores would enter and exit OFF mode together.
+ * 0x1: ES2 behavior, CPU cores are allowed to enter/exit OFF mode
+ * independently.
+ */
+ if (soc_is_omap54xx()) {
+ val = __raw_readl(wakeupgen_base + OMAP_AMBA_IF_MODE);
+ val |= OMAP5_AMBA_IF_PM_MODE;
+ omap_smc1(OMAP5_MON_AMBA_IF_INDEX, val);
+ }
+
irq_hotplug_init();
irq_pm_init();
diff --git a/arch/arm/mach-omap2/omap-wakeupgen.h b/arch/arm/mach-omap2/omap-wakeupgen.h
index b0fd16f..b3c8ecc 100644
--- a/arch/arm/mach-omap2/omap-wakeupgen.h
+++ b/arch/arm/mach-omap2/omap-wakeupgen.h
@@ -27,6 +27,7 @@
#define OMAP_WKG_ENB_E_1 0x420
#define OMAP_AUX_CORE_BOOT_0 0x800
#define OMAP_AUX_CORE_BOOT_1 0x804
+#define OMAP_AMBA_IF_MODE 0x80c
#define OMAP_PTMSYNCREQ_MASK 0xc00
#define OMAP_PTMSYNCREQ_EN 0xc04
#define OMAP_TIMESTAMPCYCLELO 0xc08
--
1.7.9.5
^ permalink raw reply related [flat|nested] 128+ messages in thread
* [PATCH v2 06/18] ARM: OMAP5: PM: Enable Mercury retention mode on CPUx powerdomains
2013-03-25 10:04 ` Santosh Shilimkar
@ 2013-03-25 10:04 ` Santosh Shilimkar
-1 siblings, 0 replies; 128+ messages in thread
From: Santosh Shilimkar @ 2013-03-25 10:04 UTC (permalink / raw)
To: khilman; +Cc: linux-omap, linux-arm-kernel, nm, tony, Santosh Shilimkar
In addition to the standard power-management technique, the OMAP5
MPU subsystem also employs an SR3-APG (mercury) power management
technology to reduce leakage.
It allows for full logic and memories retention on MPU_C0 and MPU_C1 and
is controlled by the PRCM_MPU.
Acked-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
---
arch/arm/mach-omap2/omap-mpuss-lowpower.c | 27 +++++++++++++++++++++++++++
1 file changed, 27 insertions(+)
diff --git a/arch/arm/mach-omap2/omap-mpuss-lowpower.c b/arch/arm/mach-omap2/omap-mpuss-lowpower.c
index b1441b1..d390d18 100644
--- a/arch/arm/mach-omap2/omap-mpuss-lowpower.c
+++ b/arch/arm/mach-omap2/omap-mpuss-lowpower.c
@@ -62,6 +62,10 @@
#include "prm44xx.h"
#include "prm-regbits-44xx.h"
+/* Add defines needed for mercury mode. Refer MPU's PRM_PSCON_COUNT */
+#define PRM_PSCON_HG_EN (1 << 24)
+#define PRM_PSCON_HG_RAMPUP (1 << 25)
+
#ifdef CONFIG_SMP
struct omap4_cpu_pm_info {
@@ -337,6 +341,28 @@ int __cpuinit omap4_hotplug_cpu(unsigned int cpu, unsigned int power_state)
return 0;
}
+/**
+ * enable_mercury_retention_mode: Enable OMAP5 mercury retention feature
+ *
+ * OMAP5 devices supports SR3-APG (mercury) power management technology to
+ * reduce leakage. It allows for full logic and memories retention on
+ * MPU_C0 and MPU_C1 and is controlled by the PRCM_MPU. The function enable
+ * the mercury retention feature.
+ */
+static void enable_mercury_retention_mode(void)
+{
+ u32 reg;
+
+ /*
+ * To enable mercury mode, both HG_EN and HG_RAMPUP needs to be
+ * enabled from PRM_PSCON_COUNT register.
+ */
+ reg = omap4_prcm_mpu_read_inst_reg(OMAP54XX_PRCM_MPU_DEVICE_INST,
+ OMAP54XX_PRCM_MPU_PRM_PSCON_COUNT_OFFSET);
+ reg |= PRM_PSCON_HG_EN | PRM_PSCON_HG_RAMPUP;
+ omap4_prcm_mpu_write_inst_reg(reg, OMAP54XX_PRCM_MPU_DEVICE_INST,
+ OMAP54XX_PRCM_MPU_PRM_PSCON_COUNT_OFFSET);
+}
/*
* Initialise OMAP4 MPUSS
@@ -415,6 +441,7 @@ int __init omap4_mpuss_init(void)
cpu_context_offset = OMAP4_RM_CPU0_CPU0_CONTEXT_OFFSET;
} else if (soc_is_omap54xx()) {
cpu_context_offset = OMAP54XX_RM_CPU0_CPU0_CONTEXT_OFFSET;
+ enable_mercury_retention_mode();
}
return 0;
--
1.7.9.5
^ permalink raw reply related [flat|nested] 128+ messages in thread
* [PATCH v2 06/18] ARM: OMAP5: PM: Enable Mercury retention mode on CPUx powerdomains
@ 2013-03-25 10:04 ` Santosh Shilimkar
0 siblings, 0 replies; 128+ messages in thread
From: Santosh Shilimkar @ 2013-03-25 10:04 UTC (permalink / raw)
To: linux-arm-kernel
In addition to the standard power-management technique, the OMAP5
MPU subsystem also employs an SR3-APG (mercury) power management
technology to reduce leakage.
It allows for full logic and memories retention on MPU_C0 and MPU_C1 and
is controlled by the PRCM_MPU.
Acked-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
---
arch/arm/mach-omap2/omap-mpuss-lowpower.c | 27 +++++++++++++++++++++++++++
1 file changed, 27 insertions(+)
diff --git a/arch/arm/mach-omap2/omap-mpuss-lowpower.c b/arch/arm/mach-omap2/omap-mpuss-lowpower.c
index b1441b1..d390d18 100644
--- a/arch/arm/mach-omap2/omap-mpuss-lowpower.c
+++ b/arch/arm/mach-omap2/omap-mpuss-lowpower.c
@@ -62,6 +62,10 @@
#include "prm44xx.h"
#include "prm-regbits-44xx.h"
+/* Add defines needed for mercury mode. Refer MPU's PRM_PSCON_COUNT */
+#define PRM_PSCON_HG_EN (1 << 24)
+#define PRM_PSCON_HG_RAMPUP (1 << 25)
+
#ifdef CONFIG_SMP
struct omap4_cpu_pm_info {
@@ -337,6 +341,28 @@ int __cpuinit omap4_hotplug_cpu(unsigned int cpu, unsigned int power_state)
return 0;
}
+/**
+ * enable_mercury_retention_mode: Enable OMAP5 mercury retention feature
+ *
+ * OMAP5 devices supports SR3-APG (mercury) power management technology to
+ * reduce leakage. It allows for full logic and memories retention on
+ * MPU_C0 and MPU_C1 and is controlled by the PRCM_MPU. The function enable
+ * the mercury retention feature.
+ */
+static void enable_mercury_retention_mode(void)
+{
+ u32 reg;
+
+ /*
+ * To enable mercury mode, both HG_EN and HG_RAMPUP needs to be
+ * enabled from PRM_PSCON_COUNT register.
+ */
+ reg = omap4_prcm_mpu_read_inst_reg(OMAP54XX_PRCM_MPU_DEVICE_INST,
+ OMAP54XX_PRCM_MPU_PRM_PSCON_COUNT_OFFSET);
+ reg |= PRM_PSCON_HG_EN | PRM_PSCON_HG_RAMPUP;
+ omap4_prcm_mpu_write_inst_reg(reg, OMAP54XX_PRCM_MPU_DEVICE_INST,
+ OMAP54XX_PRCM_MPU_PRM_PSCON_COUNT_OFFSET);
+}
/*
* Initialise OMAP4 MPUSS
@@ -415,6 +441,7 @@ int __init omap4_mpuss_init(void)
cpu_context_offset = OMAP4_RM_CPU0_CPU0_CONTEXT_OFFSET;
} else if (soc_is_omap54xx()) {
cpu_context_offset = OMAP54XX_RM_CPU0_CPU0_CONTEXT_OFFSET;
+ enable_mercury_retention_mode();
}
return 0;
--
1.7.9.5
^ permalink raw reply related [flat|nested] 128+ messages in thread
* [PATCH v2 07/18] ARM: OMAP5: Add init_late() hook to enable pm initialization
2013-03-25 10:04 ` Santosh Shilimkar
@ 2013-03-25 10:04 ` Santosh Shilimkar
-1 siblings, 0 replies; 128+ messages in thread
From: Santosh Shilimkar @ 2013-03-25 10:04 UTC (permalink / raw)
To: khilman; +Cc: linux-omap, linux-arm-kernel, nm, tony, Santosh Shilimkar
With consolidated code, now we can add the .init_late hook for
OMAP5 to enable power management and mux initialization.
Acked-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
---
arch/arm/mach-omap2/board-generic.c | 1 +
arch/arm/mach-omap2/common.h | 3 ++-
arch/arm/mach-omap2/io.c | 8 ++++++++
3 files changed, 11 insertions(+), 1 deletion(-)
diff --git a/arch/arm/mach-omap2/board-generic.c b/arch/arm/mach-omap2/board-generic.c
index e54a480..8e261a6 100644
--- a/arch/arm/mach-omap2/board-generic.c
+++ b/arch/arm/mach-omap2/board-generic.c
@@ -180,6 +180,7 @@ DT_MACHINE_START(OMAP5_DT, "Generic OMAP5 (Flattened Device Tree)")
.init_irq = omap_gic_of_init,
.init_machine = omap_generic_init,
.init_time = omap5_realtime_timer_init,
+ .init_late = omap5_init_late,
.dt_compat = omap5_boards_compat,
.restart = omap44xx_restart,
MACHINE_END
diff --git a/arch/arm/mach-omap2/common.h b/arch/arm/mach-omap2/common.h
index 40f4a03..f75d972 100644
--- a/arch/arm/mach-omap2/common.h
+++ b/arch/arm/mach-omap2/common.h
@@ -59,7 +59,7 @@ static inline int omap3_pm_init(void)
}
#endif
-#if defined(CONFIG_PM) && defined(CONFIG_ARCH_OMAP4)
+#if defined(CONFIG_PM) && (defined(CONFIG_ARCH_OMAP4) || defined(CONFIG_SOC_OMAP5))
int omap4_pm_init(void);
#else
static inline int omap4_pm_init(void)
@@ -108,6 +108,7 @@ void omap35xx_init_late(void);
void omap3630_init_late(void);
void am35xx_init_late(void);
void ti81xx_init_late(void);
+void omap5_init_late(void);
int omap2_common_pm_late_init(void);
#if defined(CONFIG_SOC_OMAP2420) || defined(CONFIG_SOC_OMAP2430)
diff --git a/arch/arm/mach-omap2/io.c b/arch/arm/mach-omap2/io.c
index e948a39..cdd1264 100644
--- a/arch/arm/mach-omap2/io.c
+++ b/arch/arm/mach-omap2/io.c
@@ -636,6 +636,14 @@ void __init omap5_init_early(void)
omap_hwmod_init_postsetup();
}
+
+void __init omap5_init_late(void)
+{
+ omap_mux_late_init();
+ omap2_common_pm_late_init();
+ omap4_pm_init();
+ omap2_clk_enable_autoidle_all();
+}
#endif
void __init omap_sdrc_init(struct omap_sdrc_params *sdrc_cs0,
--
1.7.9.5
^ permalink raw reply related [flat|nested] 128+ messages in thread
* [PATCH v2 07/18] ARM: OMAP5: Add init_late() hook to enable pm initialization
@ 2013-03-25 10:04 ` Santosh Shilimkar
0 siblings, 0 replies; 128+ messages in thread
From: Santosh Shilimkar @ 2013-03-25 10:04 UTC (permalink / raw)
To: linux-arm-kernel
With consolidated code, now we can add the .init_late hook for
OMAP5 to enable power management and mux initialization.
Acked-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
---
arch/arm/mach-omap2/board-generic.c | 1 +
arch/arm/mach-omap2/common.h | 3 ++-
arch/arm/mach-omap2/io.c | 8 ++++++++
3 files changed, 11 insertions(+), 1 deletion(-)
diff --git a/arch/arm/mach-omap2/board-generic.c b/arch/arm/mach-omap2/board-generic.c
index e54a480..8e261a6 100644
--- a/arch/arm/mach-omap2/board-generic.c
+++ b/arch/arm/mach-omap2/board-generic.c
@@ -180,6 +180,7 @@ DT_MACHINE_START(OMAP5_DT, "Generic OMAP5 (Flattened Device Tree)")
.init_irq = omap_gic_of_init,
.init_machine = omap_generic_init,
.init_time = omap5_realtime_timer_init,
+ .init_late = omap5_init_late,
.dt_compat = omap5_boards_compat,
.restart = omap44xx_restart,
MACHINE_END
diff --git a/arch/arm/mach-omap2/common.h b/arch/arm/mach-omap2/common.h
index 40f4a03..f75d972 100644
--- a/arch/arm/mach-omap2/common.h
+++ b/arch/arm/mach-omap2/common.h
@@ -59,7 +59,7 @@ static inline int omap3_pm_init(void)
}
#endif
-#if defined(CONFIG_PM) && defined(CONFIG_ARCH_OMAP4)
+#if defined(CONFIG_PM) && (defined(CONFIG_ARCH_OMAP4) || defined(CONFIG_SOC_OMAP5))
int omap4_pm_init(void);
#else
static inline int omap4_pm_init(void)
@@ -108,6 +108,7 @@ void omap35xx_init_late(void);
void omap3630_init_late(void);
void am35xx_init_late(void);
void ti81xx_init_late(void);
+void omap5_init_late(void);
int omap2_common_pm_late_init(void);
#if defined(CONFIG_SOC_OMAP2420) || defined(CONFIG_SOC_OMAP2430)
diff --git a/arch/arm/mach-omap2/io.c b/arch/arm/mach-omap2/io.c
index e948a39..cdd1264 100644
--- a/arch/arm/mach-omap2/io.c
+++ b/arch/arm/mach-omap2/io.c
@@ -636,6 +636,14 @@ void __init omap5_init_early(void)
omap_hwmod_init_postsetup();
}
+
+void __init omap5_init_late(void)
+{
+ omap_mux_late_init();
+ omap2_common_pm_late_init();
+ omap4_pm_init();
+ omap2_clk_enable_autoidle_all();
+}
#endif
void __init omap_sdrc_init(struct omap_sdrc_params *sdrc_cs0,
--
1.7.9.5
^ permalink raw reply related [flat|nested] 128+ messages in thread
* [PATCH v2 08/18] ARM: OMAP5: PM: Add CPU power off in hotplug path
2013-03-25 10:04 ` Santosh Shilimkar
@ 2013-03-25 10:05 ` Santosh Shilimkar
-1 siblings, 0 replies; 128+ messages in thread
From: Santosh Shilimkar @ 2013-03-25 10:05 UTC (permalink / raw)
To: khilman; +Cc: linux-omap, linux-arm-kernel, nm, tony, Santosh Shilimkar
Add power management code to handle the CPU off mode to enable CPUP hotplug
mode for OMAP5 devices. Separate suspend finisher is used for OMAP5(Cortex-A15)
because it doesn't use SCU power status register and external PL310 L2 cache
which makes code flow bit different.
Acked-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
---
arch/arm/mach-omap2/omap-mpuss-lowpower.c | 30 ++++++++---
arch/arm/mach-omap2/omap-secure.h | 1 +
arch/arm/mach-omap2/omap4-sar-layout.h | 2 +
arch/arm/mach-omap2/sleep_omap4plus.S | 84 +++++++++++++++++++++++++++++
4 files changed, 110 insertions(+), 7 deletions(-)
diff --git a/arch/arm/mach-omap2/omap-mpuss-lowpower.c b/arch/arm/mach-omap2/omap-mpuss-lowpower.c
index d390d18..096f489 100644
--- a/arch/arm/mach-omap2/omap-mpuss-lowpower.c
+++ b/arch/arm/mach-omap2/omap-mpuss-lowpower.c
@@ -81,6 +81,7 @@ struct omap4_cpu_pm_info {
* @finish_suspend: CPU suspend finisher function pointer
* @resume: CPU resume function pointer
* @scu_prepare: CPU Snoop Control program function pointer
+ * @hotplug_restart: CPU hotplug restart kernel hook pointer
*
* Structure holds functions pointer for CPU low power operations like
* suspend, resume and scu programming.
@@ -89,10 +90,12 @@ struct cpu_pm_ops {
int (*finish_suspend)(unsigned long cpu_state);
void (*resume)(void);
void (*scu_prepare)(unsigned int cpu_id, unsigned int cpu_state);
+ void (*hotplug_restart)(void);
};
extern int omap4_finish_suspend(unsigned long cpu_state);
extern void omap4_cpu_resume(void);
+extern int omap5_finish_suspend(unsigned long cpu_state);
static DEFINE_PER_CPU(struct omap4_cpu_pm_info, omap4_pm_info);
static struct powerdomain *mpuss_pd;
@@ -115,6 +118,7 @@ struct cpu_pm_ops omap_pm_ops = {
.finish_suspend = default_finish_suspend,
.resume = dummy_cpu_resume,
.scu_prepare = dummy_scu_prepare,
+ .hotplug_restart = dummy_cpu_resume,
};
/*
@@ -327,7 +331,7 @@ int __cpuinit omap4_hotplug_cpu(unsigned int cpu, unsigned int power_state)
pwrdm_clear_all_prev_pwrst(pm_info->pwrdm);
pwrdm_set_next_pwrst(pm_info->pwrdm, power_state);
- set_cpu_wakeup_addr(cpu, virt_to_phys(pm_info->secondary_startup));
+ set_cpu_wakeup_addr(cpu, virt_to_phys(omap_pm_ops.hotplug_restart));
omap_pm_ops.scu_prepare(cpu, power_state);
/*
@@ -370,6 +374,7 @@ static void enable_mercury_retention_mode(void)
int __init omap4_mpuss_init(void)
{
struct omap4_cpu_pm_info *pm_info;
+ u32 cpu_wakeup_addr = 0;
if (omap_rev() == OMAP4430_REV_ES1_0) {
WARN(1, "Power Management not supported on OMAP4430 ES1.0\n");
@@ -379,9 +384,13 @@ int __init omap4_mpuss_init(void)
sar_base = omap4_get_sar_ram_base();
/* Initilaise per CPU PM information */
+ if (cpu_is_omap44xx())
+ cpu_wakeup_addr = CPU0_WAKEUP_NS_PA_ADDR_OFFSET;
+ else if (soc_is_omap54xx())
+ cpu_wakeup_addr = OMAP5_CPU0_WAKEUP_NS_PA_ADDR_OFFSET;
pm_info = &per_cpu(omap4_pm_info, 0x0);
pm_info->scu_sar_addr = sar_base + SCU_OFFSET0;
- pm_info->wkup_sar_addr = sar_base + CPU0_WAKEUP_NS_PA_ADDR_OFFSET;
+ pm_info->wkup_sar_addr = sar_base + cpu_wakeup_addr;
pm_info->l2x0_sar_addr = sar_base + L2X0_SAVE_OFFSET0;
pm_info->pwrdm = pwrdm_lookup("cpu0_pwrdm");
if (!pm_info->pwrdm) {
@@ -396,14 +405,14 @@ int __init omap4_mpuss_init(void)
/* Initialise CPU0 power domain state to ON */
pwrdm_set_next_pwrst(pm_info->pwrdm, PWRDM_POWER_ON);
+ if (cpu_is_omap44xx())
+ cpu_wakeup_addr = CPU1_WAKEUP_NS_PA_ADDR_OFFSET;
+ else if (soc_is_omap54xx())
+ cpu_wakeup_addr = OMAP5_CPU1_WAKEUP_NS_PA_ADDR_OFFSET;
pm_info = &per_cpu(omap4_pm_info, 0x1);
pm_info->scu_sar_addr = sar_base + SCU_OFFSET1;
- pm_info->wkup_sar_addr = sar_base + CPU1_WAKEUP_NS_PA_ADDR_OFFSET;
+ pm_info->wkup_sar_addr = sar_base + cpu_wakeup_addr;
pm_info->l2x0_sar_addr = sar_base + L2X0_SAVE_OFFSET1;
- if (cpu_is_omap446x())
- pm_info->secondary_startup = omap_secondary_startup_4460;
- else
- pm_info->secondary_startup = omap_secondary_startup;
pm_info->pwrdm = pwrdm_lookup("cpu1_pwrdm");
if (!pm_info->pwrdm) {
@@ -436,14 +445,21 @@ int __init omap4_mpuss_init(void)
if (cpu_is_omap44xx()) {
omap_pm_ops.finish_suspend = omap4_finish_suspend;
+ omap_pm_ops.hotplug_restart = omap_secondary_startup;
omap_pm_ops.resume = omap4_cpu_resume;
omap_pm_ops.scu_prepare = scu_pwrst_prepare;
cpu_context_offset = OMAP4_RM_CPU0_CPU0_CONTEXT_OFFSET;
} else if (soc_is_omap54xx()) {
+ omap_pm_ops.finish_suspend = omap5_finish_suspend;
+ omap_pm_ops.hotplug_restart = omap5_secondary_startup;
cpu_context_offset = OMAP54XX_RM_CPU0_CPU0_CONTEXT_OFFSET;
enable_mercury_retention_mode();
}
+ /* Over-write the OMAP4 hook to take care of ROM BUG */
+ if (cpu_is_omap446x())
+ omap_pm_ops.hotplug_restart = omap_secondary_startup_4460;
+
return 0;
}
diff --git a/arch/arm/mach-omap2/omap-secure.h b/arch/arm/mach-omap2/omap-secure.h
index 82b3c4c..6f4dbee 100644
--- a/arch/arm/mach-omap2/omap-secure.h
+++ b/arch/arm/mach-omap2/omap-secure.h
@@ -41,6 +41,7 @@
#define OMAP4_MON_L2X0_CTRL_INDEX 0x102
#define OMAP4_MON_L2X0_AUXCTRL_INDEX 0x109
#define OMAP4_MON_L2X0_PREFETCH_INDEX 0x113
+#define OMAP5_MON_CACHES_CLEAN_INDEX 0x103
#define OMAP5_MON_AMBA_IF_INDEX 0x108
diff --git a/arch/arm/mach-omap2/omap4-sar-layout.h b/arch/arm/mach-omap2/omap4-sar-layout.h
index 792b106..5b2966a 100644
--- a/arch/arm/mach-omap2/omap4-sar-layout.h
+++ b/arch/arm/mach-omap2/omap4-sar-layout.h
@@ -31,6 +31,8 @@
/* CPUx Wakeup Non-Secure Physical Address offsets in SAR_BANK3 */
#define CPU0_WAKEUP_NS_PA_ADDR_OFFSET 0xa04
#define CPU1_WAKEUP_NS_PA_ADDR_OFFSET 0xa08
+#define OMAP5_CPU0_WAKEUP_NS_PA_ADDR_OFFSET 0xe00
+#define OMAP5_CPU1_WAKEUP_NS_PA_ADDR_OFFSET 0xe04
#define SAR_BACKUP_STATUS_OFFSET (SAR_BANK3_OFFSET + 0x500)
#define SAR_SECURE_RAM_SIZE_OFFSET (SAR_BANK3_OFFSET + 0x504)
diff --git a/arch/arm/mach-omap2/sleep_omap4plus.S b/arch/arm/mach-omap2/sleep_omap4plus.S
index 88ff83a..5a372a6 100644
--- a/arch/arm/mach-omap2/sleep_omap4plus.S
+++ b/arch/arm/mach-omap2/sleep_omap4plus.S
@@ -326,6 +326,90 @@ skip_l2en:
b cpu_resume @ Jump to generic resume
ENDPROC(omap4_cpu_resume)
+
+/*
+ * ================================
+ * == OMAP5 CPU suspend finisher ==
+ * ================================
+ *
+ * OMAP5 MPUSS states for the context save:
+ * save_state =
+ * 0 - Nothing lost and no need to save: MPUSS INA/CSWR
+ * 1 - CPUx L1 and logic lost: CPU OFF, MPUSS INA/CSWR
+ */
+ENTRY(omap5_finish_suspend)
+ stmfd sp!, {r4-r12, lr}
+ cmp r0, #0x0
+ beq do_wfi @ No lowpower state, jump to WFI
+
+ /*
+ * Flush all data from the L1 data cache before disabling
+ * SCTLR.C bit. Since we modify stack here, we must clean and
+ * invalidate the local cache here to avoid stack corruption.
+ */
+ bl omap4_get_sar_ram_base
+ ldr r9, [r0, #OMAP_TYPE_OFFSET]
+ cmp r9, #0x1 @ Check for HS device
+ bne skip_secure_l1_clean_op
+ mov r0, #0 @ Clean secure L1
+ stmfd r13!, {r4-r12, r14}
+ ldr r12, =OMAP5_MON_CACHES_CLEAN_INDEX
+ DO_SMC
+ ldmfd r13!, {r4-r12, r14}
+skip_secure_l1_clean_op:
+ bl v7_flush_dcache_louis
+
+ /*
+ * Clear the SCTLR.C bit to prevent further data cache
+ * allocation.
+ */
+ mrc p15, 0, r0, c1, c0, 0
+ bic r0, r0, #(1 << 2) @ Disable the C bit
+ mcr p15, 0, r0, c1, c0, 0
+ isb
+
+ /*
+ * Clean and invalidate all data from the L1 data cache. The L2
+ * duplicate snoop tag RAM for this processor is now empty. This
+ * prevents any new data cache snoops or data cache maintenance
+ * operations from other processors in the MPCore device being
+ * issued to this processor.
+ */
+ bl v7_flush_dcache_louis
+
+ /*
+ * Take CPU out of Symmetric Multiprocessing (SMP) mode and thus
+ * preventing the CPU from receiving cache, TLB, or BTB
+ * maintenance operations broadcast by other CPUs in the cluster.
+ */
+ mrc p15, 0, r0, c1, c1, 2 @ Read NSACR data
+ tst r0, #(1 << 18)
+ mrcne p15, 0, r0, c1, c0, 1
+ bicne r0, r0, #(1 << 6) @ Disable SMP bit
+ mcrne p15, 0, r0, c1, c0, 1
+ isb
+ dsb
+
+do_wfi:
+ bl omap_do_wfi
+
+ /*
+ * CPU is here when it failed to enter OFF/DORMANT or
+ * no low power state was attempted.
+ */
+ mrc p15, 0, r0, c1, c0, 0
+ tst r0, #(1 << 2) @ Check C bit enabled?
+ orreq r0, r0, #(1 << 2) @ Enable the C bit
+ mcreq p15, 0, r0, c1, c0, 0
+ isb
+ mrc p15, 0, r0, c1, c0, 1
+ tst r0, #(1 << 6) @ Check SMP bit enabled?
+ orreq r0, r0, #(1 << 6)
+ mcreq p15, 0, r0, c1, c0, 1
+ isb
+ dsb
+ ldmfd sp!, {r4-r12, pc}
+ENDPROC(omap5_finish_suspend)
#endif
#ifndef CONFIG_OMAP4_ERRATA_I688
--
1.7.9.5
^ permalink raw reply related [flat|nested] 128+ messages in thread
* [PATCH v2 08/18] ARM: OMAP5: PM: Add CPU power off in hotplug path
@ 2013-03-25 10:05 ` Santosh Shilimkar
0 siblings, 0 replies; 128+ messages in thread
From: Santosh Shilimkar @ 2013-03-25 10:05 UTC (permalink / raw)
To: linux-arm-kernel
Add power management code to handle the CPU off mode to enable CPUP hotplug
mode for OMAP5 devices. Separate suspend finisher is used for OMAP5(Cortex-A15)
because it doesn't use SCU power status register and external PL310 L2 cache
which makes code flow bit different.
Acked-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
---
arch/arm/mach-omap2/omap-mpuss-lowpower.c | 30 ++++++++---
arch/arm/mach-omap2/omap-secure.h | 1 +
arch/arm/mach-omap2/omap4-sar-layout.h | 2 +
arch/arm/mach-omap2/sleep_omap4plus.S | 84 +++++++++++++++++++++++++++++
4 files changed, 110 insertions(+), 7 deletions(-)
diff --git a/arch/arm/mach-omap2/omap-mpuss-lowpower.c b/arch/arm/mach-omap2/omap-mpuss-lowpower.c
index d390d18..096f489 100644
--- a/arch/arm/mach-omap2/omap-mpuss-lowpower.c
+++ b/arch/arm/mach-omap2/omap-mpuss-lowpower.c
@@ -81,6 +81,7 @@ struct omap4_cpu_pm_info {
* @finish_suspend: CPU suspend finisher function pointer
* @resume: CPU resume function pointer
* @scu_prepare: CPU Snoop Control program function pointer
+ * @hotplug_restart: CPU hotplug restart kernel hook pointer
*
* Structure holds functions pointer for CPU low power operations like
* suspend, resume and scu programming.
@@ -89,10 +90,12 @@ struct cpu_pm_ops {
int (*finish_suspend)(unsigned long cpu_state);
void (*resume)(void);
void (*scu_prepare)(unsigned int cpu_id, unsigned int cpu_state);
+ void (*hotplug_restart)(void);
};
extern int omap4_finish_suspend(unsigned long cpu_state);
extern void omap4_cpu_resume(void);
+extern int omap5_finish_suspend(unsigned long cpu_state);
static DEFINE_PER_CPU(struct omap4_cpu_pm_info, omap4_pm_info);
static struct powerdomain *mpuss_pd;
@@ -115,6 +118,7 @@ struct cpu_pm_ops omap_pm_ops = {
.finish_suspend = default_finish_suspend,
.resume = dummy_cpu_resume,
.scu_prepare = dummy_scu_prepare,
+ .hotplug_restart = dummy_cpu_resume,
};
/*
@@ -327,7 +331,7 @@ int __cpuinit omap4_hotplug_cpu(unsigned int cpu, unsigned int power_state)
pwrdm_clear_all_prev_pwrst(pm_info->pwrdm);
pwrdm_set_next_pwrst(pm_info->pwrdm, power_state);
- set_cpu_wakeup_addr(cpu, virt_to_phys(pm_info->secondary_startup));
+ set_cpu_wakeup_addr(cpu, virt_to_phys(omap_pm_ops.hotplug_restart));
omap_pm_ops.scu_prepare(cpu, power_state);
/*
@@ -370,6 +374,7 @@ static void enable_mercury_retention_mode(void)
int __init omap4_mpuss_init(void)
{
struct omap4_cpu_pm_info *pm_info;
+ u32 cpu_wakeup_addr = 0;
if (omap_rev() == OMAP4430_REV_ES1_0) {
WARN(1, "Power Management not supported on OMAP4430 ES1.0\n");
@@ -379,9 +384,13 @@ int __init omap4_mpuss_init(void)
sar_base = omap4_get_sar_ram_base();
/* Initilaise per CPU PM information */
+ if (cpu_is_omap44xx())
+ cpu_wakeup_addr = CPU0_WAKEUP_NS_PA_ADDR_OFFSET;
+ else if (soc_is_omap54xx())
+ cpu_wakeup_addr = OMAP5_CPU0_WAKEUP_NS_PA_ADDR_OFFSET;
pm_info = &per_cpu(omap4_pm_info, 0x0);
pm_info->scu_sar_addr = sar_base + SCU_OFFSET0;
- pm_info->wkup_sar_addr = sar_base + CPU0_WAKEUP_NS_PA_ADDR_OFFSET;
+ pm_info->wkup_sar_addr = sar_base + cpu_wakeup_addr;
pm_info->l2x0_sar_addr = sar_base + L2X0_SAVE_OFFSET0;
pm_info->pwrdm = pwrdm_lookup("cpu0_pwrdm");
if (!pm_info->pwrdm) {
@@ -396,14 +405,14 @@ int __init omap4_mpuss_init(void)
/* Initialise CPU0 power domain state to ON */
pwrdm_set_next_pwrst(pm_info->pwrdm, PWRDM_POWER_ON);
+ if (cpu_is_omap44xx())
+ cpu_wakeup_addr = CPU1_WAKEUP_NS_PA_ADDR_OFFSET;
+ else if (soc_is_omap54xx())
+ cpu_wakeup_addr = OMAP5_CPU1_WAKEUP_NS_PA_ADDR_OFFSET;
pm_info = &per_cpu(omap4_pm_info, 0x1);
pm_info->scu_sar_addr = sar_base + SCU_OFFSET1;
- pm_info->wkup_sar_addr = sar_base + CPU1_WAKEUP_NS_PA_ADDR_OFFSET;
+ pm_info->wkup_sar_addr = sar_base + cpu_wakeup_addr;
pm_info->l2x0_sar_addr = sar_base + L2X0_SAVE_OFFSET1;
- if (cpu_is_omap446x())
- pm_info->secondary_startup = omap_secondary_startup_4460;
- else
- pm_info->secondary_startup = omap_secondary_startup;
pm_info->pwrdm = pwrdm_lookup("cpu1_pwrdm");
if (!pm_info->pwrdm) {
@@ -436,14 +445,21 @@ int __init omap4_mpuss_init(void)
if (cpu_is_omap44xx()) {
omap_pm_ops.finish_suspend = omap4_finish_suspend;
+ omap_pm_ops.hotplug_restart = omap_secondary_startup;
omap_pm_ops.resume = omap4_cpu_resume;
omap_pm_ops.scu_prepare = scu_pwrst_prepare;
cpu_context_offset = OMAP4_RM_CPU0_CPU0_CONTEXT_OFFSET;
} else if (soc_is_omap54xx()) {
+ omap_pm_ops.finish_suspend = omap5_finish_suspend;
+ omap_pm_ops.hotplug_restart = omap5_secondary_startup;
cpu_context_offset = OMAP54XX_RM_CPU0_CPU0_CONTEXT_OFFSET;
enable_mercury_retention_mode();
}
+ /* Over-write the OMAP4 hook to take care of ROM BUG */
+ if (cpu_is_omap446x())
+ omap_pm_ops.hotplug_restart = omap_secondary_startup_4460;
+
return 0;
}
diff --git a/arch/arm/mach-omap2/omap-secure.h b/arch/arm/mach-omap2/omap-secure.h
index 82b3c4c..6f4dbee 100644
--- a/arch/arm/mach-omap2/omap-secure.h
+++ b/arch/arm/mach-omap2/omap-secure.h
@@ -41,6 +41,7 @@
#define OMAP4_MON_L2X0_CTRL_INDEX 0x102
#define OMAP4_MON_L2X0_AUXCTRL_INDEX 0x109
#define OMAP4_MON_L2X0_PREFETCH_INDEX 0x113
+#define OMAP5_MON_CACHES_CLEAN_INDEX 0x103
#define OMAP5_MON_AMBA_IF_INDEX 0x108
diff --git a/arch/arm/mach-omap2/omap4-sar-layout.h b/arch/arm/mach-omap2/omap4-sar-layout.h
index 792b106..5b2966a 100644
--- a/arch/arm/mach-omap2/omap4-sar-layout.h
+++ b/arch/arm/mach-omap2/omap4-sar-layout.h
@@ -31,6 +31,8 @@
/* CPUx Wakeup Non-Secure Physical Address offsets in SAR_BANK3 */
#define CPU0_WAKEUP_NS_PA_ADDR_OFFSET 0xa04
#define CPU1_WAKEUP_NS_PA_ADDR_OFFSET 0xa08
+#define OMAP5_CPU0_WAKEUP_NS_PA_ADDR_OFFSET 0xe00
+#define OMAP5_CPU1_WAKEUP_NS_PA_ADDR_OFFSET 0xe04
#define SAR_BACKUP_STATUS_OFFSET (SAR_BANK3_OFFSET + 0x500)
#define SAR_SECURE_RAM_SIZE_OFFSET (SAR_BANK3_OFFSET + 0x504)
diff --git a/arch/arm/mach-omap2/sleep_omap4plus.S b/arch/arm/mach-omap2/sleep_omap4plus.S
index 88ff83a..5a372a6 100644
--- a/arch/arm/mach-omap2/sleep_omap4plus.S
+++ b/arch/arm/mach-omap2/sleep_omap4plus.S
@@ -326,6 +326,90 @@ skip_l2en:
b cpu_resume @ Jump to generic resume
ENDPROC(omap4_cpu_resume)
+
+/*
+ * ================================
+ * == OMAP5 CPU suspend finisher ==
+ * ================================
+ *
+ * OMAP5 MPUSS states for the context save:
+ * save_state =
+ * 0 - Nothing lost and no need to save: MPUSS INA/CSWR
+ * 1 - CPUx L1 and logic lost: CPU OFF, MPUSS INA/CSWR
+ */
+ENTRY(omap5_finish_suspend)
+ stmfd sp!, {r4-r12, lr}
+ cmp r0, #0x0
+ beq do_wfi @ No lowpower state, jump to WFI
+
+ /*
+ * Flush all data from the L1 data cache before disabling
+ * SCTLR.C bit. Since we modify stack here, we must clean and
+ * invalidate the local cache here to avoid stack corruption.
+ */
+ bl omap4_get_sar_ram_base
+ ldr r9, [r0, #OMAP_TYPE_OFFSET]
+ cmp r9, #0x1 @ Check for HS device
+ bne skip_secure_l1_clean_op
+ mov r0, #0 @ Clean secure L1
+ stmfd r13!, {r4-r12, r14}
+ ldr r12, =OMAP5_MON_CACHES_CLEAN_INDEX
+ DO_SMC
+ ldmfd r13!, {r4-r12, r14}
+skip_secure_l1_clean_op:
+ bl v7_flush_dcache_louis
+
+ /*
+ * Clear the SCTLR.C bit to prevent further data cache
+ * allocation.
+ */
+ mrc p15, 0, r0, c1, c0, 0
+ bic r0, r0, #(1 << 2) @ Disable the C bit
+ mcr p15, 0, r0, c1, c0, 0
+ isb
+
+ /*
+ * Clean and invalidate all data from the L1 data cache. The L2
+ * duplicate snoop tag RAM for this processor is now empty. This
+ * prevents any new data cache snoops or data cache maintenance
+ * operations from other processors in the MPCore device being
+ * issued to this processor.
+ */
+ bl v7_flush_dcache_louis
+
+ /*
+ * Take CPU out of Symmetric Multiprocessing (SMP) mode and thus
+ * preventing the CPU from receiving cache, TLB, or BTB
+ * maintenance operations broadcast by other CPUs in the cluster.
+ */
+ mrc p15, 0, r0, c1, c1, 2 @ Read NSACR data
+ tst r0, #(1 << 18)
+ mrcne p15, 0, r0, c1, c0, 1
+ bicne r0, r0, #(1 << 6) @ Disable SMP bit
+ mcrne p15, 0, r0, c1, c0, 1
+ isb
+ dsb
+
+do_wfi:
+ bl omap_do_wfi
+
+ /*
+ * CPU is here when it failed to enter OFF/DORMANT or
+ * no low power state was attempted.
+ */
+ mrc p15, 0, r0, c1, c0, 0
+ tst r0, #(1 << 2) @ Check C bit enabled?
+ orreq r0, r0, #(1 << 2) @ Enable the C bit
+ mcreq p15, 0, r0, c1, c0, 0
+ isb
+ mrc p15, 0, r0, c1, c0, 1
+ tst r0, #(1 << 6) @ Check SMP bit enabled?
+ orreq r0, r0, #(1 << 6)
+ mcreq p15, 0, r0, c1, c0, 1
+ isb
+ dsb
+ ldmfd sp!, {r4-r12, pc}
+ENDPROC(omap5_finish_suspend)
#endif
#ifndef CONFIG_OMAP4_ERRATA_I688
--
1.7.9.5
^ permalink raw reply related [flat|nested] 128+ messages in thread
* [PATCH v2 09/18] ARM: OMAP4+: PM: Restore CPU power state to ON with clockdomain force wakeup method
2013-03-25 10:04 ` Santosh Shilimkar
@ 2013-03-25 10:05 ` Santosh Shilimkar
-1 siblings, 0 replies; 128+ messages in thread
From: Santosh Shilimkar @ 2013-03-25 10:05 UTC (permalink / raw)
To: khilman; +Cc: linux-omap, linux-arm-kernel, nm, tony, Santosh Shilimkar
While waking up CPU from off state using clock domain force wakeup, restore
the CPU power state to ON state before putting CPU clock domain under
hardware control. Otherwise CPU wakeup might fail. The change is recommended
for all OMAP4+ devices though the PRCM weakness was observed on OMAP5
devices first.
So update the code accordingly.
Acked-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
---
arch/arm/mach-omap2/cpuidle44xx.c | 1 +
arch/arm/mach-omap2/omap-smp.c | 12 ++++++++++--
2 files changed, 11 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/cpuidle44xx.c b/arch/arm/mach-omap2/cpuidle44xx.c
index 944e64a..9de47a7 100644
--- a/arch/arm/mach-omap2/cpuidle44xx.c
+++ b/arch/arm/mach-omap2/cpuidle44xx.c
@@ -131,6 +131,7 @@ static int omap4_enter_idle_coupled(struct cpuidle_device *dev,
/* Wakeup CPU1 only if it is not offlined */
if (dev->cpu == 0 && cpumask_test_cpu(1, cpu_online_mask)) {
clkdm_wakeup(cpu_clkdm[1]);
+ omap_set_pwrdm_state(cpu_pd[1], PWRDM_POWER_ON);
clkdm_allow_idle(cpu_clkdm[1]);
}
diff --git a/arch/arm/mach-omap2/omap-smp.c b/arch/arm/mach-omap2/omap-smp.c
index 0cbb677..e4441cc 100644
--- a/arch/arm/mach-omap2/omap-smp.c
+++ b/arch/arm/mach-omap2/omap-smp.c
@@ -83,6 +83,7 @@ static int __cpuinit omap4_boot_secondary(unsigned int cpu, struct task_struct *
{
static struct clockdomain *cpu1_clkdm;
static bool booted;
+ static struct powerdomain *cpu1_pwrdm;
void __iomem *base = omap_get_wakeupgen_base();
/*
@@ -102,8 +103,10 @@ static int __cpuinit omap4_boot_secondary(unsigned int cpu, struct task_struct *
else
__raw_writel(0x20, base + OMAP_AUX_CORE_BOOT_0);
- if (!cpu1_clkdm)
+ if (!cpu1_clkdm && !cpu1_pwrdm) {
cpu1_clkdm = clkdm_lookup("mpu1_clkdm");
+ cpu1_pwrdm = pwrdm_lookup("cpu1_pwrdm");
+ }
/*
* The SGI(Software Generated Interrupts) are not wakeup capable
@@ -116,7 +119,7 @@ static int __cpuinit omap4_boot_secondary(unsigned int cpu, struct task_struct *
* Section :
* 4.3.4.2 Power States of CPU0 and CPU1
*/
- if (booted) {
+ if (booted && cpu1_pwrdm && cpu1_clkdm) {
/*
* GIC distributor control register has changed between
* CortexA9 r1pX and r2pX. The Control Register secure
@@ -137,7 +140,12 @@ static int __cpuinit omap4_boot_secondary(unsigned int cpu, struct task_struct *
gic_dist_disable();
}
+ /*
+ * Ensure that CPU power state is set to ON to avoid CPU
+ * powerdomain transition on wfi
+ */
clkdm_wakeup(cpu1_clkdm);
+ omap_set_pwrdm_state(cpu1_pwrdm, PWRDM_POWER_ON);
clkdm_allow_idle(cpu1_clkdm);
if (IS_PM44XX_ERRATUM(PM_OMAP4_ROM_SMP_BOOT_ERRATUM_GICD)) {
--
1.7.9.5
^ permalink raw reply related [flat|nested] 128+ messages in thread
* [PATCH v2 09/18] ARM: OMAP4+: PM: Restore CPU power state to ON with clockdomain force wakeup method
@ 2013-03-25 10:05 ` Santosh Shilimkar
0 siblings, 0 replies; 128+ messages in thread
From: Santosh Shilimkar @ 2013-03-25 10:05 UTC (permalink / raw)
To: linux-arm-kernel
While waking up CPU from off state using clock domain force wakeup, restore
the CPU power state to ON state before putting CPU clock domain under
hardware control. Otherwise CPU wakeup might fail. The change is recommended
for all OMAP4+ devices though the PRCM weakness was observed on OMAP5
devices first.
So update the code accordingly.
Acked-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
---
arch/arm/mach-omap2/cpuidle44xx.c | 1 +
arch/arm/mach-omap2/omap-smp.c | 12 ++++++++++--
2 files changed, 11 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/cpuidle44xx.c b/arch/arm/mach-omap2/cpuidle44xx.c
index 944e64a..9de47a7 100644
--- a/arch/arm/mach-omap2/cpuidle44xx.c
+++ b/arch/arm/mach-omap2/cpuidle44xx.c
@@ -131,6 +131,7 @@ static int omap4_enter_idle_coupled(struct cpuidle_device *dev,
/* Wakeup CPU1 only if it is not offlined */
if (dev->cpu == 0 && cpumask_test_cpu(1, cpu_online_mask)) {
clkdm_wakeup(cpu_clkdm[1]);
+ omap_set_pwrdm_state(cpu_pd[1], PWRDM_POWER_ON);
clkdm_allow_idle(cpu_clkdm[1]);
}
diff --git a/arch/arm/mach-omap2/omap-smp.c b/arch/arm/mach-omap2/omap-smp.c
index 0cbb677..e4441cc 100644
--- a/arch/arm/mach-omap2/omap-smp.c
+++ b/arch/arm/mach-omap2/omap-smp.c
@@ -83,6 +83,7 @@ static int __cpuinit omap4_boot_secondary(unsigned int cpu, struct task_struct *
{
static struct clockdomain *cpu1_clkdm;
static bool booted;
+ static struct powerdomain *cpu1_pwrdm;
void __iomem *base = omap_get_wakeupgen_base();
/*
@@ -102,8 +103,10 @@ static int __cpuinit omap4_boot_secondary(unsigned int cpu, struct task_struct *
else
__raw_writel(0x20, base + OMAP_AUX_CORE_BOOT_0);
- if (!cpu1_clkdm)
+ if (!cpu1_clkdm && !cpu1_pwrdm) {
cpu1_clkdm = clkdm_lookup("mpu1_clkdm");
+ cpu1_pwrdm = pwrdm_lookup("cpu1_pwrdm");
+ }
/*
* The SGI(Software Generated Interrupts) are not wakeup capable
@@ -116,7 +119,7 @@ static int __cpuinit omap4_boot_secondary(unsigned int cpu, struct task_struct *
* Section :
* 4.3.4.2 Power States of CPU0 and CPU1
*/
- if (booted) {
+ if (booted && cpu1_pwrdm && cpu1_clkdm) {
/*
* GIC distributor control register has changed between
* CortexA9 r1pX and r2pX. The Control Register secure
@@ -137,7 +140,12 @@ static int __cpuinit omap4_boot_secondary(unsigned int cpu, struct task_struct *
gic_dist_disable();
}
+ /*
+ * Ensure that CPU power state is set to ON to avoid CPU
+ * powerdomain transition on wfi
+ */
clkdm_wakeup(cpu1_clkdm);
+ omap_set_pwrdm_state(cpu1_pwrdm, PWRDM_POWER_ON);
clkdm_allow_idle(cpu1_clkdm);
if (IS_PM44XX_ERRATUM(PM_OMAP4_ROM_SMP_BOOT_ERRATUM_GICD)) {
--
1.7.9.5
^ permalink raw reply related [flat|nested] 128+ messages in thread
* [PATCH v2 10/18] ARM: OMAP5: PM: Add MPU Open Switch Retention support
2013-03-25 10:04 ` Santosh Shilimkar
@ 2013-03-25 10:05 ` Santosh Shilimkar
-1 siblings, 0 replies; 128+ messages in thread
From: Santosh Shilimkar @ 2013-03-25 10:05 UTC (permalink / raw)
To: khilman; +Cc: linux-omap, linux-arm-kernel, nm, tony, Santosh Shilimkar
In MPUSS OSWR(Open Switch Retention), entire CPU cluster is powered down
except L2 cache memory. For MPUSS OSWR state, both CPU's needs to be in
power off state.
Acked-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
---
arch/arm/mach-omap2/omap-mpuss-lowpower.c | 1 +
arch/arm/mach-omap2/omap-secure.h | 5 +++++
arch/arm/mach-omap2/omap-wakeupgen.c | 11 ++++++-----
arch/arm/mach-omap2/sleep_omap4plus.S | 1 +
4 files changed, 13 insertions(+), 5 deletions(-)
diff --git a/arch/arm/mach-omap2/omap-mpuss-lowpower.c b/arch/arm/mach-omap2/omap-mpuss-lowpower.c
index 096f489..995443a 100644
--- a/arch/arm/mach-omap2/omap-mpuss-lowpower.c
+++ b/arch/arm/mach-omap2/omap-mpuss-lowpower.c
@@ -452,6 +452,7 @@ int __init omap4_mpuss_init(void)
} else if (soc_is_omap54xx()) {
omap_pm_ops.finish_suspend = omap5_finish_suspend;
omap_pm_ops.hotplug_restart = omap5_secondary_startup;
+ omap_pm_ops.resume = cpu_resume;
cpu_context_offset = OMAP54XX_RM_CPU0_CPU0_CONTEXT_OFFSET;
enable_mercury_retention_mode();
}
diff --git a/arch/arm/mach-omap2/omap-secure.h b/arch/arm/mach-omap2/omap-secure.h
index 6f4dbee..1739468 100644
--- a/arch/arm/mach-omap2/omap-secure.h
+++ b/arch/arm/mach-omap2/omap-secure.h
@@ -34,6 +34,10 @@
#define OMAP4_HAL_SAVEHW_INDEX 0x1b
#define OMAP4_HAL_SAVEALL_INDEX 0x1c
#define OMAP4_HAL_SAVEGIC_INDEX 0x1d
+#define OMAP5_HAL_SAVESECURERAM_INDEX 0x1c
+#define OMAP5_HAL_SAVEHW_INDEX 0x1d
+#define OMAP5_HAL_SAVEALL_INDEX 0x1e
+#define OMAP5_HAL_SAVEGIC_INDEX 0x1f
/* Secure Monitor mode APIs */
#define OMAP4_MON_SCU_PWR_INDEX 0x108
@@ -42,6 +46,7 @@
#define OMAP4_MON_L2X0_AUXCTRL_INDEX 0x109
#define OMAP4_MON_L2X0_PREFETCH_INDEX 0x113
#define OMAP5_MON_CACHES_CLEAN_INDEX 0x103
+#define OMAP5_MON_AUX_CTRL_INDEX 0x107
#define OMAP5_MON_AMBA_IF_INDEX 0x108
diff --git a/arch/arm/mach-omap2/omap-wakeupgen.c b/arch/arm/mach-omap2/omap-wakeupgen.c
index 8bcaa8c..1697cec 100644
--- a/arch/arm/mach-omap2/omap-wakeupgen.c
+++ b/arch/arm/mach-omap2/omap-wakeupgen.c
@@ -50,7 +50,7 @@ static DEFINE_RAW_SPINLOCK(wakeupgen_lock);
static unsigned int irq_target_cpu[MAX_IRQS];
static unsigned int irq_banks = MAX_NR_REG_BANKS;
static unsigned int max_irqs = MAX_IRQS;
-static unsigned int omap_secure_apis;
+static unsigned int omap_secure_apis, secure_api_index;
/*
* Static helper functions.
@@ -320,7 +320,7 @@ static void irq_sar_clear(void)
static void irq_save_secure_context(void)
{
u32 ret;
- ret = omap_secure_dispatcher(OMAP4_HAL_SAVEGIC_INDEX,
+ ret = omap_secure_dispatcher(secure_api_index,
FLAG_START_CRITICAL,
0, 0, 0, 0, 0);
if (ret != API_HAL_RET_VALUE_OK)
@@ -382,9 +382,7 @@ static struct notifier_block irq_notifier_block = {
static void __init irq_pm_init(void)
{
- /* FIXME: Remove this when MPU OSWR support is added */
- if (!soc_is_omap54xx())
- cpu_pm_register_notifier(&irq_notifier_block);
+ cpu_pm_register_notifier(&irq_notifier_block);
}
#else
static void __init irq_pm_init(void)
@@ -425,6 +423,9 @@ int __init omap_wakeupgen_init(void)
irq_banks = OMAP4_NR_BANKS;
max_irqs = OMAP4_NR_IRQS;
omap_secure_apis = 1;
+ secure_api_index = OMAP4_HAL_SAVEGIC_INDEX;
+ } else if (soc_is_omap54xx()) {
+ secure_api_index = OMAP5_HAL_SAVEGIC_INDEX;
}
/* Clear all IRQ bitmasks at wakeupGen level */
diff --git a/arch/arm/mach-omap2/sleep_omap4plus.S b/arch/arm/mach-omap2/sleep_omap4plus.S
index 5a372a6..4a5e2e4 100644
--- a/arch/arm/mach-omap2/sleep_omap4plus.S
+++ b/arch/arm/mach-omap2/sleep_omap4plus.S
@@ -336,6 +336,7 @@ ENDPROC(omap4_cpu_resume)
* save_state =
* 0 - Nothing lost and no need to save: MPUSS INA/CSWR
* 1 - CPUx L1 and logic lost: CPU OFF, MPUSS INA/CSWR
+ * 2 - CPUx L1 and logic lost + GIC lost: MPUSS OSWR
*/
ENTRY(omap5_finish_suspend)
stmfd sp!, {r4-r12, lr}
--
1.7.9.5
^ permalink raw reply related [flat|nested] 128+ messages in thread
* [PATCH v2 10/18] ARM: OMAP5: PM: Add MPU Open Switch Retention support
@ 2013-03-25 10:05 ` Santosh Shilimkar
0 siblings, 0 replies; 128+ messages in thread
From: Santosh Shilimkar @ 2013-03-25 10:05 UTC (permalink / raw)
To: linux-arm-kernel
In MPUSS OSWR(Open Switch Retention), entire CPU cluster is powered down
except L2 cache memory. For MPUSS OSWR state, both CPU's needs to be in
power off state.
Acked-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
---
arch/arm/mach-omap2/omap-mpuss-lowpower.c | 1 +
arch/arm/mach-omap2/omap-secure.h | 5 +++++
arch/arm/mach-omap2/omap-wakeupgen.c | 11 ++++++-----
arch/arm/mach-omap2/sleep_omap4plus.S | 1 +
4 files changed, 13 insertions(+), 5 deletions(-)
diff --git a/arch/arm/mach-omap2/omap-mpuss-lowpower.c b/arch/arm/mach-omap2/omap-mpuss-lowpower.c
index 096f489..995443a 100644
--- a/arch/arm/mach-omap2/omap-mpuss-lowpower.c
+++ b/arch/arm/mach-omap2/omap-mpuss-lowpower.c
@@ -452,6 +452,7 @@ int __init omap4_mpuss_init(void)
} else if (soc_is_omap54xx()) {
omap_pm_ops.finish_suspend = omap5_finish_suspend;
omap_pm_ops.hotplug_restart = omap5_secondary_startup;
+ omap_pm_ops.resume = cpu_resume;
cpu_context_offset = OMAP54XX_RM_CPU0_CPU0_CONTEXT_OFFSET;
enable_mercury_retention_mode();
}
diff --git a/arch/arm/mach-omap2/omap-secure.h b/arch/arm/mach-omap2/omap-secure.h
index 6f4dbee..1739468 100644
--- a/arch/arm/mach-omap2/omap-secure.h
+++ b/arch/arm/mach-omap2/omap-secure.h
@@ -34,6 +34,10 @@
#define OMAP4_HAL_SAVEHW_INDEX 0x1b
#define OMAP4_HAL_SAVEALL_INDEX 0x1c
#define OMAP4_HAL_SAVEGIC_INDEX 0x1d
+#define OMAP5_HAL_SAVESECURERAM_INDEX 0x1c
+#define OMAP5_HAL_SAVEHW_INDEX 0x1d
+#define OMAP5_HAL_SAVEALL_INDEX 0x1e
+#define OMAP5_HAL_SAVEGIC_INDEX 0x1f
/* Secure Monitor mode APIs */
#define OMAP4_MON_SCU_PWR_INDEX 0x108
@@ -42,6 +46,7 @@
#define OMAP4_MON_L2X0_AUXCTRL_INDEX 0x109
#define OMAP4_MON_L2X0_PREFETCH_INDEX 0x113
#define OMAP5_MON_CACHES_CLEAN_INDEX 0x103
+#define OMAP5_MON_AUX_CTRL_INDEX 0x107
#define OMAP5_MON_AMBA_IF_INDEX 0x108
diff --git a/arch/arm/mach-omap2/omap-wakeupgen.c b/arch/arm/mach-omap2/omap-wakeupgen.c
index 8bcaa8c..1697cec 100644
--- a/arch/arm/mach-omap2/omap-wakeupgen.c
+++ b/arch/arm/mach-omap2/omap-wakeupgen.c
@@ -50,7 +50,7 @@ static DEFINE_RAW_SPINLOCK(wakeupgen_lock);
static unsigned int irq_target_cpu[MAX_IRQS];
static unsigned int irq_banks = MAX_NR_REG_BANKS;
static unsigned int max_irqs = MAX_IRQS;
-static unsigned int omap_secure_apis;
+static unsigned int omap_secure_apis, secure_api_index;
/*
* Static helper functions.
@@ -320,7 +320,7 @@ static void irq_sar_clear(void)
static void irq_save_secure_context(void)
{
u32 ret;
- ret = omap_secure_dispatcher(OMAP4_HAL_SAVEGIC_INDEX,
+ ret = omap_secure_dispatcher(secure_api_index,
FLAG_START_CRITICAL,
0, 0, 0, 0, 0);
if (ret != API_HAL_RET_VALUE_OK)
@@ -382,9 +382,7 @@ static struct notifier_block irq_notifier_block = {
static void __init irq_pm_init(void)
{
- /* FIXME: Remove this when MPU OSWR support is added */
- if (!soc_is_omap54xx())
- cpu_pm_register_notifier(&irq_notifier_block);
+ cpu_pm_register_notifier(&irq_notifier_block);
}
#else
static void __init irq_pm_init(void)
@@ -425,6 +423,9 @@ int __init omap_wakeupgen_init(void)
irq_banks = OMAP4_NR_BANKS;
max_irqs = OMAP4_NR_IRQS;
omap_secure_apis = 1;
+ secure_api_index = OMAP4_HAL_SAVEGIC_INDEX;
+ } else if (soc_is_omap54xx()) {
+ secure_api_index = OMAP5_HAL_SAVEGIC_INDEX;
}
/* Clear all IRQ bitmasks at wakeupGen level */
diff --git a/arch/arm/mach-omap2/sleep_omap4plus.S b/arch/arm/mach-omap2/sleep_omap4plus.S
index 5a372a6..4a5e2e4 100644
--- a/arch/arm/mach-omap2/sleep_omap4plus.S
+++ b/arch/arm/mach-omap2/sleep_omap4plus.S
@@ -336,6 +336,7 @@ ENDPROC(omap4_cpu_resume)
* save_state =
* 0 - Nothing lost and no need to save: MPUSS INA/CSWR
* 1 - CPUx L1 and logic lost: CPU OFF, MPUSS INA/CSWR
+ * 2 - CPUx L1 and logic lost + GIC lost: MPUSS OSWR
*/
ENTRY(omap5_finish_suspend)
stmfd sp!, {r4-r12, lr}
--
1.7.9.5
^ permalink raw reply related [flat|nested] 128+ messages in thread
* [PATCH v2 11/18] ARM: OMAP5: PM: Add L2 memory power down support
2013-03-25 10:04 ` Santosh Shilimkar
@ 2013-03-25 10:05 ` Santosh Shilimkar
-1 siblings, 0 replies; 128+ messages in thread
From: Santosh Shilimkar @ 2013-03-25 10:05 UTC (permalink / raw)
To: khilman; +Cc: linux-omap, linux-arm-kernel, nm, tony, Santosh Shilimkar
When the entire MPUSS cluster is powered down in device off state, L2 cache
memory looses it's content and hence while targetting such a state,
l2 cache needs to be flushed to main memory.
Add the necessary low power code support for the same.
Acked-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
---
arch/arm/mach-omap2/omap-secure.h | 1 +
arch/arm/mach-omap2/sleep_omap4plus.S | 21 +++++++++++++++++++++
2 files changed, 22 insertions(+)
diff --git a/arch/arm/mach-omap2/omap-secure.h b/arch/arm/mach-omap2/omap-secure.h
index 1739468..a171a5a 100644
--- a/arch/arm/mach-omap2/omap-secure.h
+++ b/arch/arm/mach-omap2/omap-secure.h
@@ -47,6 +47,7 @@
#define OMAP4_MON_L2X0_PREFETCH_INDEX 0x113
#define OMAP5_MON_CACHES_CLEAN_INDEX 0x103
#define OMAP5_MON_AUX_CTRL_INDEX 0x107
+#define OMAP5_MON_L2AUX_CTRL_INDEX 0x104
#define OMAP5_MON_AMBA_IF_INDEX 0x108
diff --git a/arch/arm/mach-omap2/sleep_omap4plus.S b/arch/arm/mach-omap2/sleep_omap4plus.S
index 4a5e2e4..288f62f 100644
--- a/arch/arm/mach-omap2/sleep_omap4plus.S
+++ b/arch/arm/mach-omap2/sleep_omap4plus.S
@@ -337,6 +337,7 @@ ENDPROC(omap4_cpu_resume)
* 0 - Nothing lost and no need to save: MPUSS INA/CSWR
* 1 - CPUx L1 and logic lost: CPU OFF, MPUSS INA/CSWR
* 2 - CPUx L1 and logic lost + GIC lost: MPUSS OSWR
+ * 3 - CPUx L1 and logic lost + GIC,L2 lost: MPU OSWR & L2 lost(debug only)
*/
ENTRY(omap5_finish_suspend)
stmfd sp!, {r4-r12, lr}
@@ -391,6 +392,26 @@ skip_secure_l1_clean_op:
isb
dsb
+ bl omap4_get_sar_ram_base
+ mov r8, r0
+ mrc p15, 0, r5, c0, c0, 5 @ Read MPIDR
+ ands r5, r5, #0x0f
+ ldreq r0, [r8, #L2X0_SAVE_OFFSET0] @ Retrieve L2 state
+ ldrne r0, [r8, #L2X0_SAVE_OFFSET1]
+ cmp r0, #3
+ bne do_wfi
+ bl omap4_get_sar_ram_base
+ ldr r9, [r0, #OMAP_TYPE_OFFSET]
+ cmp r9, #0x1 @ Check for HS device
+ bne skip_secure_l2_clean_op
+ mov r0, #1 @ Clean secure L2
+ stmfd r13!, {r4-r12, r14}
+ ldr r12, =OMAP5_MON_CACHES_CLEAN_INDEX
+ DO_SMC
+ ldmfd r13!, {r4-r12, r14}
+skip_secure_l2_clean_op:
+ bl v7_flush_dcache_all
+
do_wfi:
bl omap_do_wfi
--
1.7.9.5
^ permalink raw reply related [flat|nested] 128+ messages in thread
* [PATCH v2 11/18] ARM: OMAP5: PM: Add L2 memory power down support
@ 2013-03-25 10:05 ` Santosh Shilimkar
0 siblings, 0 replies; 128+ messages in thread
From: Santosh Shilimkar @ 2013-03-25 10:05 UTC (permalink / raw)
To: linux-arm-kernel
When the entire MPUSS cluster is powered down in device off state, L2 cache
memory looses it's content and hence while targetting such a state,
l2 cache needs to be flushed to main memory.
Add the necessary low power code support for the same.
Acked-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
---
arch/arm/mach-omap2/omap-secure.h | 1 +
arch/arm/mach-omap2/sleep_omap4plus.S | 21 +++++++++++++++++++++
2 files changed, 22 insertions(+)
diff --git a/arch/arm/mach-omap2/omap-secure.h b/arch/arm/mach-omap2/omap-secure.h
index 1739468..a171a5a 100644
--- a/arch/arm/mach-omap2/omap-secure.h
+++ b/arch/arm/mach-omap2/omap-secure.h
@@ -47,6 +47,7 @@
#define OMAP4_MON_L2X0_PREFETCH_INDEX 0x113
#define OMAP5_MON_CACHES_CLEAN_INDEX 0x103
#define OMAP5_MON_AUX_CTRL_INDEX 0x107
+#define OMAP5_MON_L2AUX_CTRL_INDEX 0x104
#define OMAP5_MON_AMBA_IF_INDEX 0x108
diff --git a/arch/arm/mach-omap2/sleep_omap4plus.S b/arch/arm/mach-omap2/sleep_omap4plus.S
index 4a5e2e4..288f62f 100644
--- a/arch/arm/mach-omap2/sleep_omap4plus.S
+++ b/arch/arm/mach-omap2/sleep_omap4plus.S
@@ -337,6 +337,7 @@ ENDPROC(omap4_cpu_resume)
* 0 - Nothing lost and no need to save: MPUSS INA/CSWR
* 1 - CPUx L1 and logic lost: CPU OFF, MPUSS INA/CSWR
* 2 - CPUx L1 and logic lost + GIC lost: MPUSS OSWR
+ * 3 - CPUx L1 and logic lost + GIC,L2 lost: MPU OSWR & L2 lost(debug only)
*/
ENTRY(omap5_finish_suspend)
stmfd sp!, {r4-r12, lr}
@@ -391,6 +392,26 @@ skip_secure_l1_clean_op:
isb
dsb
+ bl omap4_get_sar_ram_base
+ mov r8, r0
+ mrc p15, 0, r5, c0, c0, 5 @ Read MPIDR
+ ands r5, r5, #0x0f
+ ldreq r0, [r8, #L2X0_SAVE_OFFSET0] @ Retrieve L2 state
+ ldrne r0, [r8, #L2X0_SAVE_OFFSET1]
+ cmp r0, #3
+ bne do_wfi
+ bl omap4_get_sar_ram_base
+ ldr r9, [r0, #OMAP_TYPE_OFFSET]
+ cmp r9, #0x1 @ Check for HS device
+ bne skip_secure_l2_clean_op
+ mov r0, #1 @ Clean secure L2
+ stmfd r13!, {r4-r12, r14}
+ ldr r12, =OMAP5_MON_CACHES_CLEAN_INDEX
+ DO_SMC
+ ldmfd r13!, {r4-r12, r14}
+skip_secure_l2_clean_op:
+ bl v7_flush_dcache_all
+
do_wfi:
bl omap_do_wfi
--
1.7.9.5
^ permalink raw reply related [flat|nested] 128+ messages in thread
* [PATCH v2 12/18] ARM: OMAP4: CPUidle: Avoid double idle driver registration
2013-03-25 10:04 ` Santosh Shilimkar
@ 2013-03-25 10:05 ` Santosh Shilimkar
-1 siblings, 0 replies; 128+ messages in thread
From: Santosh Shilimkar @ 2013-03-25 10:05 UTC (permalink / raw)
To: khilman; +Cc: linux-omap, linux-arm-kernel, nm, tony, Santosh Shilimkar
OMAP4 CPUidle driver registration call is under a loop which leads
to calling cpuidle_register_driver twice which is not intended.
Fix it by moving the driver registration outside the loop.
Reported-by: Nishanth Menon <nm@ti.com>
Acked-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
---
arch/arm/mach-omap2/cpuidle44xx.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/cpuidle44xx.c b/arch/arm/mach-omap2/cpuidle44xx.c
index 9de47a7..d00b1ec 100644
--- a/arch/arm/mach-omap2/cpuidle44xx.c
+++ b/arch/arm/mach-omap2/cpuidle44xx.c
@@ -233,14 +233,14 @@ int __init omap4_idle_init(void)
/* Configure the broadcast timer on each cpu */
on_each_cpu(omap_setup_broadcast_timer, NULL, 1);
+ cpuidle_register_driver(&omap4_idle_driver);
+
for_each_cpu(cpu_id, cpu_online_mask) {
dev = &per_cpu(omap4_idle_dev, cpu_id);
dev->cpu = cpu_id;
#ifdef CONFIG_ARCH_NEEDS_CPU_IDLE_COUPLED
dev->coupled_cpus = *cpu_online_mask;
#endif
- cpuidle_register_driver(&omap4_idle_driver);
-
if (cpuidle_register_device(dev)) {
pr_err("%s: CPUidle register failed\n", __func__);
return -EIO;
--
1.7.9.5
^ permalink raw reply related [flat|nested] 128+ messages in thread
* [PATCH v2 12/18] ARM: OMAP4: CPUidle: Avoid double idle driver registration
@ 2013-03-25 10:05 ` Santosh Shilimkar
0 siblings, 0 replies; 128+ messages in thread
From: Santosh Shilimkar @ 2013-03-25 10:05 UTC (permalink / raw)
To: linux-arm-kernel
OMAP4 CPUidle driver registration call is under a loop which leads
to calling cpuidle_register_driver twice which is not intended.
Fix it by moving the driver registration outside the loop.
Reported-by: Nishanth Menon <nm@ti.com>
Acked-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
---
arch/arm/mach-omap2/cpuidle44xx.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/cpuidle44xx.c b/arch/arm/mach-omap2/cpuidle44xx.c
index 9de47a7..d00b1ec 100644
--- a/arch/arm/mach-omap2/cpuidle44xx.c
+++ b/arch/arm/mach-omap2/cpuidle44xx.c
@@ -233,14 +233,14 @@ int __init omap4_idle_init(void)
/* Configure the broadcast timer on each cpu */
on_each_cpu(omap_setup_broadcast_timer, NULL, 1);
+ cpuidle_register_driver(&omap4_idle_driver);
+
for_each_cpu(cpu_id, cpu_online_mask) {
dev = &per_cpu(omap4_idle_dev, cpu_id);
dev->cpu = cpu_id;
#ifdef CONFIG_ARCH_NEEDS_CPU_IDLE_COUPLED
dev->coupled_cpus = *cpu_online_mask;
#endif
- cpuidle_register_driver(&omap4_idle_driver);
-
if (cpuidle_register_device(dev)) {
pr_err("%s: CPUidle register failed\n", __func__);
return -EIO;
--
1.7.9.5
^ permalink raw reply related [flat|nested] 128+ messages in thread
* [PATCH v2 13/18] ARM: OMAP: CPUidle: Unregister drivere on device registration failure
2013-03-25 10:04 ` Santosh Shilimkar
@ 2013-03-25 10:05 ` Santosh Shilimkar
-1 siblings, 0 replies; 128+ messages in thread
From: Santosh Shilimkar @ 2013-03-25 10:05 UTC (permalink / raw)
To: khilman; +Cc: linux-omap, linux-arm-kernel, nm, tony, Santosh Shilimkar
If the CPUidle device registration fails for some reason, we should
unregister the driver on error path.
Fix the code accordingly. Also when at it, check of the driver registration
failure too.
Acked-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
---
arch/arm/mach-omap2/cpuidle34xx.c | 6 +++++-
arch/arm/mach-omap2/cpuidle44xx.c | 6 +++++-
2 files changed, 10 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/cpuidle34xx.c b/arch/arm/mach-omap2/cpuidle34xx.c
index 06f567f..e193ea2 100644
--- a/arch/arm/mach-omap2/cpuidle34xx.c
+++ b/arch/arm/mach-omap2/cpuidle34xx.c
@@ -355,7 +355,10 @@ int __init omap3_idle_init(void)
if (!mpu_pd || !core_pd || !per_pd || !cam_pd)
return -ENODEV;
- cpuidle_register_driver(&omap3_idle_driver);
+ if (cpuidle_register_driver(&omap3_idle_driver)) {
+ pr_err("%s: CPUidle driver register failed\n", __func__);
+ return -EIO;
+ }
dev = &per_cpu(omap3_idle_dev, smp_processor_id());
dev->cpu = 0;
@@ -363,6 +366,7 @@ int __init omap3_idle_init(void)
if (cpuidle_register_device(dev)) {
printk(KERN_ERR "%s: CPUidle register device failed\n",
__func__);
+ cpuidle_unregister_driver(&omap3_idle_driver);
return -EIO;
}
diff --git a/arch/arm/mach-omap2/cpuidle44xx.c b/arch/arm/mach-omap2/cpuidle44xx.c
index d00b1ec..908114d 100644
--- a/arch/arm/mach-omap2/cpuidle44xx.c
+++ b/arch/arm/mach-omap2/cpuidle44xx.c
@@ -233,7 +233,10 @@ int __init omap4_idle_init(void)
/* Configure the broadcast timer on each cpu */
on_each_cpu(omap_setup_broadcast_timer, NULL, 1);
- cpuidle_register_driver(&omap4_idle_driver);
+ if (cpuidle_register_driver(&omap4_idle_driver)) {
+ pr_err("%s: CPUidle driver register failed\n", __func__);
+ return -EIO;
+ }
for_each_cpu(cpu_id, cpu_online_mask) {
dev = &per_cpu(omap4_idle_dev, cpu_id);
@@ -243,6 +246,7 @@ int __init omap4_idle_init(void)
#endif
if (cpuidle_register_device(dev)) {
pr_err("%s: CPUidle register failed\n", __func__);
+ cpuidle_unregister_driver(&omap4_idle_driver);
return -EIO;
}
}
--
1.7.9.5
^ permalink raw reply related [flat|nested] 128+ messages in thread
* [PATCH v2 13/18] ARM: OMAP: CPUidle: Unregister drivere on device registration failure
@ 2013-03-25 10:05 ` Santosh Shilimkar
0 siblings, 0 replies; 128+ messages in thread
From: Santosh Shilimkar @ 2013-03-25 10:05 UTC (permalink / raw)
To: linux-arm-kernel
If the CPUidle device registration fails for some reason, we should
unregister the driver on error path.
Fix the code accordingly. Also when at it, check of the driver registration
failure too.
Acked-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
---
arch/arm/mach-omap2/cpuidle34xx.c | 6 +++++-
arch/arm/mach-omap2/cpuidle44xx.c | 6 +++++-
2 files changed, 10 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/cpuidle34xx.c b/arch/arm/mach-omap2/cpuidle34xx.c
index 06f567f..e193ea2 100644
--- a/arch/arm/mach-omap2/cpuidle34xx.c
+++ b/arch/arm/mach-omap2/cpuidle34xx.c
@@ -355,7 +355,10 @@ int __init omap3_idle_init(void)
if (!mpu_pd || !core_pd || !per_pd || !cam_pd)
return -ENODEV;
- cpuidle_register_driver(&omap3_idle_driver);
+ if (cpuidle_register_driver(&omap3_idle_driver)) {
+ pr_err("%s: CPUidle driver register failed\n", __func__);
+ return -EIO;
+ }
dev = &per_cpu(omap3_idle_dev, smp_processor_id());
dev->cpu = 0;
@@ -363,6 +366,7 @@ int __init omap3_idle_init(void)
if (cpuidle_register_device(dev)) {
printk(KERN_ERR "%s: CPUidle register device failed\n",
__func__);
+ cpuidle_unregister_driver(&omap3_idle_driver);
return -EIO;
}
diff --git a/arch/arm/mach-omap2/cpuidle44xx.c b/arch/arm/mach-omap2/cpuidle44xx.c
index d00b1ec..908114d 100644
--- a/arch/arm/mach-omap2/cpuidle44xx.c
+++ b/arch/arm/mach-omap2/cpuidle44xx.c
@@ -233,7 +233,10 @@ int __init omap4_idle_init(void)
/* Configure the broadcast timer on each cpu */
on_each_cpu(omap_setup_broadcast_timer, NULL, 1);
- cpuidle_register_driver(&omap4_idle_driver);
+ if (cpuidle_register_driver(&omap4_idle_driver)) {
+ pr_err("%s: CPUidle driver register failed\n", __func__);
+ return -EIO;
+ }
for_each_cpu(cpu_id, cpu_online_mask) {
dev = &per_cpu(omap4_idle_dev, cpu_id);
@@ -243,6 +246,7 @@ int __init omap4_idle_init(void)
#endif
if (cpuidle_register_device(dev)) {
pr_err("%s: CPUidle register failed\n", __func__);
+ cpuidle_unregister_driver(&omap4_idle_driver);
return -EIO;
}
}
--
1.7.9.5
^ permalink raw reply related [flat|nested] 128+ messages in thread
* [PATCH v2 14/18] ARM: OMAP4: CPUidle: Make C-state description field more precise
2013-03-25 10:04 ` Santosh Shilimkar
@ 2013-03-25 10:05 ` Santosh Shilimkar
-1 siblings, 0 replies; 128+ messages in thread
From: Santosh Shilimkar @ 2013-03-25 10:05 UTC (permalink / raw)
To: khilman; +Cc: linux-omap, linux-arm-kernel, nm, tony, Santosh Shilimkar
It is useful to know the CPU power state along with MPUSS power state
in a supported C-state. Since the data is available via sysfs, one can
avoid scrolling the source code for precise construction of C-state.
Reported-by: Nishanth Menon <nm@ti.com>
Acked-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
---
arch/arm/mach-omap2/cpuidle44xx.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/arm/mach-omap2/cpuidle44xx.c b/arch/arm/mach-omap2/cpuidle44xx.c
index 908114d..b8a22f0 100644
--- a/arch/arm/mach-omap2/cpuidle44xx.c
+++ b/arch/arm/mach-omap2/cpuidle44xx.c
@@ -181,7 +181,7 @@ static struct cpuidle_driver omap4_idle_driver = {
.flags = CPUIDLE_FLAG_TIME_VALID,
.enter = omap4_enter_idle_simple,
.name = "C1",
- .desc = "MPUSS ON"
+ .desc = "CPUx ON, MPUSS ON"
},
{
/* C2 - CPU0 OFF + CPU1 OFF + MPU CSWR */
@@ -190,7 +190,7 @@ static struct cpuidle_driver omap4_idle_driver = {
.flags = CPUIDLE_FLAG_TIME_VALID | CPUIDLE_FLAG_COUPLED,
.enter = omap4_enter_idle_coupled,
.name = "C2",
- .desc = "MPUSS CSWR",
+ .desc = "CPUx OFF, MPUSS CSWR",
},
{
/* C3 - CPU0 OFF + CPU1 OFF + MPU OSWR */
@@ -199,7 +199,7 @@ static struct cpuidle_driver omap4_idle_driver = {
.flags = CPUIDLE_FLAG_TIME_VALID | CPUIDLE_FLAG_COUPLED,
.enter = omap4_enter_idle_coupled,
.name = "C3",
- .desc = "MPUSS OSWR",
+ .desc = "CPUx OFF, MPUSS OSWR",
},
},
.state_count = ARRAY_SIZE(omap4_idle_data),
--
1.7.9.5
^ permalink raw reply related [flat|nested] 128+ messages in thread
* [PATCH v2 14/18] ARM: OMAP4: CPUidle: Make C-state description field more precise
@ 2013-03-25 10:05 ` Santosh Shilimkar
0 siblings, 0 replies; 128+ messages in thread
From: Santosh Shilimkar @ 2013-03-25 10:05 UTC (permalink / raw)
To: linux-arm-kernel
It is useful to know the CPU power state along with MPUSS power state
in a supported C-state. Since the data is available via sysfs, one can
avoid scrolling the source code for precise construction of C-state.
Reported-by: Nishanth Menon <nm@ti.com>
Acked-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
---
arch/arm/mach-omap2/cpuidle44xx.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/arm/mach-omap2/cpuidle44xx.c b/arch/arm/mach-omap2/cpuidle44xx.c
index 908114d..b8a22f0 100644
--- a/arch/arm/mach-omap2/cpuidle44xx.c
+++ b/arch/arm/mach-omap2/cpuidle44xx.c
@@ -181,7 +181,7 @@ static struct cpuidle_driver omap4_idle_driver = {
.flags = CPUIDLE_FLAG_TIME_VALID,
.enter = omap4_enter_idle_simple,
.name = "C1",
- .desc = "MPUSS ON"
+ .desc = "CPUx ON, MPUSS ON"
},
{
/* C2 - CPU0 OFF + CPU1 OFF + MPU CSWR */
@@ -190,7 +190,7 @@ static struct cpuidle_driver omap4_idle_driver = {
.flags = CPUIDLE_FLAG_TIME_VALID | CPUIDLE_FLAG_COUPLED,
.enter = omap4_enter_idle_coupled,
.name = "C2",
- .desc = "MPUSS CSWR",
+ .desc = "CPUx OFF, MPUSS CSWR",
},
{
/* C3 - CPU0 OFF + CPU1 OFF + MPU OSWR */
@@ -199,7 +199,7 @@ static struct cpuidle_driver omap4_idle_driver = {
.flags = CPUIDLE_FLAG_TIME_VALID | CPUIDLE_FLAG_COUPLED,
.enter = omap4_enter_idle_coupled,
.name = "C3",
- .desc = "MPUSS OSWR",
+ .desc = "CPUx OFF, MPUSS OSWR",
},
},
.state_count = ARRAY_SIZE(omap4_idle_data),
--
1.7.9.5
^ permalink raw reply related [flat|nested] 128+ messages in thread
* [PATCH v2 15/18] ARM: OMAP4+: CPUidle: Consolidate idle driver for OMAP5 support
2013-03-25 10:04 ` Santosh Shilimkar
@ 2013-03-25 10:05 ` Santosh Shilimkar
-1 siblings, 0 replies; 128+ messages in thread
From: Santosh Shilimkar @ 2013-03-25 10:05 UTC (permalink / raw)
To: khilman; +Cc: linux-omap, linux-arm-kernel, nm, tony, Santosh Shilimkar
The OMAP5 idle driver can re-use most of OMAP4 CPUidle driver
implementation. Also the next derivative SOCs are going to re-use
the MPUSS so, same driver with minor updates can be re-used.
Prepare the code so that its easier to add CPUidle support for
OMAP5 devices.
Acked-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
---
arch/arm/mach-omap2/cpuidle44xx.c | 31 ++++++++++++++++---------------
1 file changed, 16 insertions(+), 15 deletions(-)
diff --git a/arch/arm/mach-omap2/cpuidle44xx.c b/arch/arm/mach-omap2/cpuidle44xx.c
index b8a22f0..ac6d526 100644
--- a/arch/arm/mach-omap2/cpuidle44xx.c
+++ b/arch/arm/mach-omap2/cpuidle44xx.c
@@ -1,7 +1,7 @@
/*
- * OMAP4 CPU idle Routines
+ * OMAP4PLUS CPU idle Routines
*
- * Copyright (C) 2011 Texas Instruments, Inc.
+ * Copyright (C) 2011-2013 Texas Instruments, Inc.
* Santosh Shilimkar <santosh.shilimkar@ti.com>
* Rajendra Nayak <rnayak@ti.com>
*
@@ -24,13 +24,13 @@
#include "clockdomain.h"
/* Machine specific information */
-struct omap4_idle_statedata {
+struct idle_statedata {
u32 cpu_state;
u32 mpu_logic_state;
u32 mpu_state;
};
-static struct omap4_idle_statedata omap4_idle_data[] = {
+static struct idle_statedata omap4_idle_data[] = {
{
.cpu_state = PWRDM_POWER_ON,
.mpu_state = PWRDM_POWER_ON,
@@ -53,11 +53,12 @@ static struct clockdomain *cpu_clkdm[NR_CPUS];
static atomic_t abort_barrier;
static bool cpu_done[NR_CPUS];
+static struct idle_statedata *state_ptr = &omap4_idle_data[0];
/* Private functions */
/**
- * omap4_enter_idle_coupled_[simple/coupled] - OMAP4 cpuidle entry functions
+ * omap_enter_idle_[simple/coupled] - OMAP4PLUS cpuidle entry functions
* @dev: cpuidle device
* @drv: cpuidle driver
* @index: the index of state to be entered
@@ -66,7 +67,7 @@ static bool cpu_done[NR_CPUS];
* specified low power state selected by the governor.
* Returns the amount of time spent in the low power state.
*/
-static int omap4_enter_idle_simple(struct cpuidle_device *dev,
+static int omap_enter_idle_simple(struct cpuidle_device *dev,
struct cpuidle_driver *drv,
int index)
{
@@ -74,11 +75,11 @@ static int omap4_enter_idle_simple(struct cpuidle_device *dev,
return index;
}
-static int omap4_enter_idle_coupled(struct cpuidle_device *dev,
+static int omap_enter_idle_coupled(struct cpuidle_device *dev,
struct cpuidle_driver *drv,
int index)
{
- struct omap4_idle_statedata *cx = &omap4_idle_data[index];
+ struct idle_statedata *cx = state_ptr + index;
int cpu_id = smp_processor_id();
/*
@@ -167,7 +168,7 @@ static void omap_setup_broadcast_timer(void *arg)
clockevents_notify(CLOCK_EVT_NOTIFY_BROADCAST_ON, &cpu);
}
-static DEFINE_PER_CPU(struct cpuidle_device, omap4_idle_dev);
+static DEFINE_PER_CPU(struct cpuidle_device, omap_idle_dev);
static struct cpuidle_driver omap4_idle_driver = {
.name = "omap4_idle",
@@ -179,7 +180,7 @@ static struct cpuidle_driver omap4_idle_driver = {
.exit_latency = 2 + 2,
.target_residency = 5,
.flags = CPUIDLE_FLAG_TIME_VALID,
- .enter = omap4_enter_idle_simple,
+ .enter = omap_enter_idle_simple,
.name = "C1",
.desc = "CPUx ON, MPUSS ON"
},
@@ -188,7 +189,7 @@ static struct cpuidle_driver omap4_idle_driver = {
.exit_latency = 328 + 440,
.target_residency = 960,
.flags = CPUIDLE_FLAG_TIME_VALID | CPUIDLE_FLAG_COUPLED,
- .enter = omap4_enter_idle_coupled,
+ .enter = omap_enter_idle_coupled,
.name = "C2",
.desc = "CPUx OFF, MPUSS CSWR",
},
@@ -197,7 +198,7 @@ static struct cpuidle_driver omap4_idle_driver = {
.exit_latency = 460 + 518,
.target_residency = 1100,
.flags = CPUIDLE_FLAG_TIME_VALID | CPUIDLE_FLAG_COUPLED,
- .enter = omap4_enter_idle_coupled,
+ .enter = omap_enter_idle_coupled,
.name = "C3",
.desc = "CPUx OFF, MPUSS OSWR",
},
@@ -209,9 +210,9 @@ static struct cpuidle_driver omap4_idle_driver = {
/* Public functions */
/**
- * omap4_idle_init - Init routine for OMAP4 idle
+ * omap4_idle_init - Init routine for OMAP4PLUS idle
*
- * Registers the OMAP4 specific cpuidle driver to the cpuidle
+ * Registers the OMAP4PLUS specific cpuidle driver to the cpuidle
* framework with the valid set of states.
*/
int __init omap4_idle_init(void)
@@ -239,7 +240,7 @@ int __init omap4_idle_init(void)
}
for_each_cpu(cpu_id, cpu_online_mask) {
- dev = &per_cpu(omap4_idle_dev, cpu_id);
+ dev = &per_cpu(omap_idle_dev, cpu_id);
dev->cpu = cpu_id;
#ifdef CONFIG_ARCH_NEEDS_CPU_IDLE_COUPLED
dev->coupled_cpus = *cpu_online_mask;
--
1.7.9.5
^ permalink raw reply related [flat|nested] 128+ messages in thread
* [PATCH v2 15/18] ARM: OMAP4+: CPUidle: Consolidate idle driver for OMAP5 support
@ 2013-03-25 10:05 ` Santosh Shilimkar
0 siblings, 0 replies; 128+ messages in thread
From: Santosh Shilimkar @ 2013-03-25 10:05 UTC (permalink / raw)
To: linux-arm-kernel
The OMAP5 idle driver can re-use most of OMAP4 CPUidle driver
implementation. Also the next derivative SOCs are going to re-use
the MPUSS so, same driver with minor updates can be re-used.
Prepare the code so that its easier to add CPUidle support for
OMAP5 devices.
Acked-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
---
arch/arm/mach-omap2/cpuidle44xx.c | 31 ++++++++++++++++---------------
1 file changed, 16 insertions(+), 15 deletions(-)
diff --git a/arch/arm/mach-omap2/cpuidle44xx.c b/arch/arm/mach-omap2/cpuidle44xx.c
index b8a22f0..ac6d526 100644
--- a/arch/arm/mach-omap2/cpuidle44xx.c
+++ b/arch/arm/mach-omap2/cpuidle44xx.c
@@ -1,7 +1,7 @@
/*
- * OMAP4 CPU idle Routines
+ * OMAP4PLUS CPU idle Routines
*
- * Copyright (C) 2011 Texas Instruments, Inc.
+ * Copyright (C) 2011-2013 Texas Instruments, Inc.
* Santosh Shilimkar <santosh.shilimkar@ti.com>
* Rajendra Nayak <rnayak@ti.com>
*
@@ -24,13 +24,13 @@
#include "clockdomain.h"
/* Machine specific information */
-struct omap4_idle_statedata {
+struct idle_statedata {
u32 cpu_state;
u32 mpu_logic_state;
u32 mpu_state;
};
-static struct omap4_idle_statedata omap4_idle_data[] = {
+static struct idle_statedata omap4_idle_data[] = {
{
.cpu_state = PWRDM_POWER_ON,
.mpu_state = PWRDM_POWER_ON,
@@ -53,11 +53,12 @@ static struct clockdomain *cpu_clkdm[NR_CPUS];
static atomic_t abort_barrier;
static bool cpu_done[NR_CPUS];
+static struct idle_statedata *state_ptr = &omap4_idle_data[0];
/* Private functions */
/**
- * omap4_enter_idle_coupled_[simple/coupled] - OMAP4 cpuidle entry functions
+ * omap_enter_idle_[simple/coupled] - OMAP4PLUS cpuidle entry functions
* @dev: cpuidle device
* @drv: cpuidle driver
* @index: the index of state to be entered
@@ -66,7 +67,7 @@ static bool cpu_done[NR_CPUS];
* specified low power state selected by the governor.
* Returns the amount of time spent in the low power state.
*/
-static int omap4_enter_idle_simple(struct cpuidle_device *dev,
+static int omap_enter_idle_simple(struct cpuidle_device *dev,
struct cpuidle_driver *drv,
int index)
{
@@ -74,11 +75,11 @@ static int omap4_enter_idle_simple(struct cpuidle_device *dev,
return index;
}
-static int omap4_enter_idle_coupled(struct cpuidle_device *dev,
+static int omap_enter_idle_coupled(struct cpuidle_device *dev,
struct cpuidle_driver *drv,
int index)
{
- struct omap4_idle_statedata *cx = &omap4_idle_data[index];
+ struct idle_statedata *cx = state_ptr + index;
int cpu_id = smp_processor_id();
/*
@@ -167,7 +168,7 @@ static void omap_setup_broadcast_timer(void *arg)
clockevents_notify(CLOCK_EVT_NOTIFY_BROADCAST_ON, &cpu);
}
-static DEFINE_PER_CPU(struct cpuidle_device, omap4_idle_dev);
+static DEFINE_PER_CPU(struct cpuidle_device, omap_idle_dev);
static struct cpuidle_driver omap4_idle_driver = {
.name = "omap4_idle",
@@ -179,7 +180,7 @@ static struct cpuidle_driver omap4_idle_driver = {
.exit_latency = 2 + 2,
.target_residency = 5,
.flags = CPUIDLE_FLAG_TIME_VALID,
- .enter = omap4_enter_idle_simple,
+ .enter = omap_enter_idle_simple,
.name = "C1",
.desc = "CPUx ON, MPUSS ON"
},
@@ -188,7 +189,7 @@ static struct cpuidle_driver omap4_idle_driver = {
.exit_latency = 328 + 440,
.target_residency = 960,
.flags = CPUIDLE_FLAG_TIME_VALID | CPUIDLE_FLAG_COUPLED,
- .enter = omap4_enter_idle_coupled,
+ .enter = omap_enter_idle_coupled,
.name = "C2",
.desc = "CPUx OFF, MPUSS CSWR",
},
@@ -197,7 +198,7 @@ static struct cpuidle_driver omap4_idle_driver = {
.exit_latency = 460 + 518,
.target_residency = 1100,
.flags = CPUIDLE_FLAG_TIME_VALID | CPUIDLE_FLAG_COUPLED,
- .enter = omap4_enter_idle_coupled,
+ .enter = omap_enter_idle_coupled,
.name = "C3",
.desc = "CPUx OFF, MPUSS OSWR",
},
@@ -209,9 +210,9 @@ static struct cpuidle_driver omap4_idle_driver = {
/* Public functions */
/**
- * omap4_idle_init - Init routine for OMAP4 idle
+ * omap4_idle_init - Init routine for OMAP4PLUS idle
*
- * Registers the OMAP4 specific cpuidle driver to the cpuidle
+ * Registers the OMAP4PLUS specific cpuidle driver to the cpuidle
* framework with the valid set of states.
*/
int __init omap4_idle_init(void)
@@ -239,7 +240,7 @@ int __init omap4_idle_init(void)
}
for_each_cpu(cpu_id, cpu_online_mask) {
- dev = &per_cpu(omap4_idle_dev, cpu_id);
+ dev = &per_cpu(omap_idle_dev, cpu_id);
dev->cpu = cpu_id;
#ifdef CONFIG_ARCH_NEEDS_CPU_IDLE_COUPLED
dev->coupled_cpus = *cpu_online_mask;
--
1.7.9.5
^ permalink raw reply related [flat|nested] 128+ messages in thread
* [PATCH v2 16/18] ARM: OMAP4+: CPUidle: Deprecate use of omap4_mpuss_read_prev_context_state()
2013-03-25 10:04 ` Santosh Shilimkar
@ 2013-03-25 10:05 ` Santosh Shilimkar
-1 siblings, 0 replies; 128+ messages in thread
From: Santosh Shilimkar @ 2013-03-25 10:05 UTC (permalink / raw)
To: khilman; +Cc: linux-omap, linux-arm-kernel, nm, tony, Santosh Shilimkar
Current OMAP4 CPUIdle driver is using omap4_mpuss_read_prev_context_state()
function to check whether the MPU cluster lost context or not. Thanks to
couple CPUIdle, cluster low power entry is almost guaranteed and hence
the programmed cluster check is enough in idle exit path. The API was
more of an optimization for corner cases, where if the cluster low power
entry fails for some reason, the cluster context restore gets skipped.
Moving forward, OMAP CPUidle drivers needs to be moved to drivers/idle/*
once the PRM/CM code gets moved to drivers. This patch also reduces one
dependency with platform code for idle driver movement.
Acked-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
---
arch/arm/mach-omap2/common.h | 5 -----
arch/arm/mach-omap2/cpuidle44xx.c | 3 ++-
arch/arm/mach-omap2/omap-mpuss-lowpower.c | 14 --------------
3 files changed, 2 insertions(+), 20 deletions(-)
diff --git a/arch/arm/mach-omap2/common.h b/arch/arm/mach-omap2/common.h
index f75d972..6b97d42 100644
--- a/arch/arm/mach-omap2/common.h
+++ b/arch/arm/mach-omap2/common.h
@@ -250,7 +250,6 @@ extern int omap4_enter_lowpower(unsigned int cpu, unsigned int power_state);
extern int omap4_finish_suspend(unsigned long cpu_state);
extern void omap4_cpu_resume(void);
extern int omap4_hotplug_cpu(unsigned int cpu, unsigned int power_state);
-extern u32 omap4_mpuss_read_prev_context_state(void);
#else
static inline int omap4_enter_lowpower(unsigned int cpu,
unsigned int power_state)
@@ -278,10 +277,6 @@ static inline int omap4_finish_suspend(unsigned long cpu_state)
static inline void omap4_cpu_resume(void)
{}
-static inline u32 omap4_mpuss_read_prev_context_state(void)
-{
- return 0;
-}
#endif
struct omap_sdrc_params;
diff --git a/arch/arm/mach-omap2/cpuidle44xx.c b/arch/arm/mach-omap2/cpuidle44xx.c
index ac6d526..e6218d3 100644
--- a/arch/arm/mach-omap2/cpuidle44xx.c
+++ b/arch/arm/mach-omap2/cpuidle44xx.c
@@ -146,7 +146,8 @@ static int omap_enter_idle_coupled(struct cpuidle_device *dev,
* Call idle CPU cluster PM exit notifier chain
* to restore GIC and wakeupgen context.
*/
- if (omap4_mpuss_read_prev_context_state())
+ if ((cx->mpu_state == PWRDM_POWER_RET) &&
+ (cx->mpu_logic_state == PWRDM_POWER_OFF))
cpu_cluster_pm_exit();
clockevents_notify(CLOCK_EVT_NOTIFY_BROADCAST_EXIT, &cpu_id);
diff --git a/arch/arm/mach-omap2/omap-mpuss-lowpower.c b/arch/arm/mach-omap2/omap-mpuss-lowpower.c
index 995443a..6e917d7 100644
--- a/arch/arm/mach-omap2/omap-mpuss-lowpower.c
+++ b/arch/arm/mach-omap2/omap-mpuss-lowpower.c
@@ -185,20 +185,6 @@ static inline void cpu_clear_prev_logic_pwrst(unsigned int cpu_id)
}
}
-/**
- * omap4_mpuss_read_prev_context_state:
- * Function returns the MPUSS previous context state
- */
-u32 omap4_mpuss_read_prev_context_state(void)
-{
- u32 reg;
-
- reg = omap4_prminst_read_inst_reg(OMAP4430_PRM_PARTITION,
- OMAP4430_PRM_MPU_INST, OMAP4_RM_MPU_MPU_CONTEXT_OFFSET);
- reg &= OMAP4430_LOSTCONTEXT_DFF_MASK;
- return reg;
-}
-
/*
* Store the CPU cluster state for L2X0 low power operations.
*/
--
1.7.9.5
^ permalink raw reply related [flat|nested] 128+ messages in thread
* [PATCH v2 16/18] ARM: OMAP4+: CPUidle: Deprecate use of omap4_mpuss_read_prev_context_state()
@ 2013-03-25 10:05 ` Santosh Shilimkar
0 siblings, 0 replies; 128+ messages in thread
From: Santosh Shilimkar @ 2013-03-25 10:05 UTC (permalink / raw)
To: linux-arm-kernel
Current OMAP4 CPUIdle driver is using omap4_mpuss_read_prev_context_state()
function to check whether the MPU cluster lost context or not. Thanks to
couple CPUIdle, cluster low power entry is almost guaranteed and hence
the programmed cluster check is enough in idle exit path. The API was
more of an optimization for corner cases, where if the cluster low power
entry fails for some reason, the cluster context restore gets skipped.
Moving forward, OMAP CPUidle drivers needs to be moved to drivers/idle/*
once the PRM/CM code gets moved to drivers. This patch also reduces one
dependency with platform code for idle driver movement.
Acked-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
---
arch/arm/mach-omap2/common.h | 5 -----
arch/arm/mach-omap2/cpuidle44xx.c | 3 ++-
arch/arm/mach-omap2/omap-mpuss-lowpower.c | 14 --------------
3 files changed, 2 insertions(+), 20 deletions(-)
diff --git a/arch/arm/mach-omap2/common.h b/arch/arm/mach-omap2/common.h
index f75d972..6b97d42 100644
--- a/arch/arm/mach-omap2/common.h
+++ b/arch/arm/mach-omap2/common.h
@@ -250,7 +250,6 @@ extern int omap4_enter_lowpower(unsigned int cpu, unsigned int power_state);
extern int omap4_finish_suspend(unsigned long cpu_state);
extern void omap4_cpu_resume(void);
extern int omap4_hotplug_cpu(unsigned int cpu, unsigned int power_state);
-extern u32 omap4_mpuss_read_prev_context_state(void);
#else
static inline int omap4_enter_lowpower(unsigned int cpu,
unsigned int power_state)
@@ -278,10 +277,6 @@ static inline int omap4_finish_suspend(unsigned long cpu_state)
static inline void omap4_cpu_resume(void)
{}
-static inline u32 omap4_mpuss_read_prev_context_state(void)
-{
- return 0;
-}
#endif
struct omap_sdrc_params;
diff --git a/arch/arm/mach-omap2/cpuidle44xx.c b/arch/arm/mach-omap2/cpuidle44xx.c
index ac6d526..e6218d3 100644
--- a/arch/arm/mach-omap2/cpuidle44xx.c
+++ b/arch/arm/mach-omap2/cpuidle44xx.c
@@ -146,7 +146,8 @@ static int omap_enter_idle_coupled(struct cpuidle_device *dev,
* Call idle CPU cluster PM exit notifier chain
* to restore GIC and wakeupgen context.
*/
- if (omap4_mpuss_read_prev_context_state())
+ if ((cx->mpu_state == PWRDM_POWER_RET) &&
+ (cx->mpu_logic_state == PWRDM_POWER_OFF))
cpu_cluster_pm_exit();
clockevents_notify(CLOCK_EVT_NOTIFY_BROADCAST_EXIT, &cpu_id);
diff --git a/arch/arm/mach-omap2/omap-mpuss-lowpower.c b/arch/arm/mach-omap2/omap-mpuss-lowpower.c
index 995443a..6e917d7 100644
--- a/arch/arm/mach-omap2/omap-mpuss-lowpower.c
+++ b/arch/arm/mach-omap2/omap-mpuss-lowpower.c
@@ -185,20 +185,6 @@ static inline void cpu_clear_prev_logic_pwrst(unsigned int cpu_id)
}
}
-/**
- * omap4_mpuss_read_prev_context_state:
- * Function returns the MPUSS previous context state
- */
-u32 omap4_mpuss_read_prev_context_state(void)
-{
- u32 reg;
-
- reg = omap4_prminst_read_inst_reg(OMAP4430_PRM_PARTITION,
- OMAP4430_PRM_MPU_INST, OMAP4_RM_MPU_MPU_CONTEXT_OFFSET);
- reg &= OMAP4430_LOSTCONTEXT_DFF_MASK;
- return reg;
-}
-
/*
* Store the CPU cluster state for L2X0 low power operations.
*/
--
1.7.9.5
^ permalink raw reply related [flat|nested] 128+ messages in thread
* [PATCH v2 17/18] ARM: OMAP4+: CPUidle: Add OMAP5 idle driver support
2013-03-25 10:04 ` Santosh Shilimkar
@ 2013-03-25 10:05 ` Santosh Shilimkar
-1 siblings, 0 replies; 128+ messages in thread
From: Santosh Shilimkar @ 2013-03-25 10:05 UTC (permalink / raw)
To: khilman; +Cc: linux-omap, linux-arm-kernel, nm, tony, Santosh Shilimkar
The OMAP5 idle driver can re-use OMAP4 CPUidle driver implementation thanks
to compatible MPUSS design.
Though unlike OMAP4, on OMAP5 devices, MPUSS CSWR (Close Switch Retention)
power states can be achieved with respective power states on CPU0 and CPU1
power domain. This mode was broken on OMAP4 devices because of hardware
limitation. Also there is no CPU low power entry order requirement like
master CPU etc for CSWR C-state, which is icing on the cake. Code makes
use of voting scheme for cluster low power state to support MPUSS CSWR
C-state.
Supported OMAP5 CPUidle C-states:
C1 - CPU0 ON(WFI) + CPU1 ON(WFI) + MPUSS ON
C2 - CPU0 CSWR + CPU1 CSWR + MPUSS CSWR
C3 - CPU0 OFF + CPU1 OFF + MPUSS OSWR
Acked-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
---
arch/arm/mach-omap2/Kconfig | 1 +
arch/arm/mach-omap2/Makefile | 3 +-
.../{cpuidle44xx.c => cpuidle_omap4plus.c} | 110 +++++++++++++++++++-
arch/arm/mach-omap2/omap-mpuss-lowpower.c | 7 +-
arch/arm/mach-omap2/pm_omap4plus.c | 2 +-
5 files changed, 115 insertions(+), 8 deletions(-)
rename arch/arm/mach-omap2/{cpuidle44xx.c => cpuidle_omap4plus.c} (69%)
diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
index b9c0ed3..838ea67 100644
--- a/arch/arm/mach-omap2/Kconfig
+++ b/arch/arm/mach-omap2/Kconfig
@@ -105,6 +105,7 @@ config SOC_OMAP5
select HAVE_SMP
select COMMON_CLK
select HAVE_ARM_ARCH_TIMER
+ select ARCH_NEEDS_CPU_IDLE_COUPLED
comment "OMAP Core Type"
depends on ARCH_OMAP2
diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index d91ae0f..ddaaa6c 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -102,7 +102,8 @@ endif
ifeq ($(CONFIG_CPU_IDLE),y)
obj-$(CONFIG_ARCH_OMAP3) += cpuidle34xx.o
-obj-$(CONFIG_ARCH_OMAP4) += cpuidle44xx.o
+obj-$(CONFIG_ARCH_OMAP4) += cpuidle_omap4plus.o
+obj-$(CONFIG_SOC_OMAP5) += cpuidle_omap4plus.o
endif
# PRCM
diff --git a/arch/arm/mach-omap2/cpuidle44xx.c b/arch/arm/mach-omap2/cpuidle_omap4plus.c
similarity index 69%
rename from arch/arm/mach-omap2/cpuidle44xx.c
rename to arch/arm/mach-omap2/cpuidle_omap4plus.c
index e6218d3..defb830 100644
--- a/arch/arm/mach-omap2/cpuidle44xx.c
+++ b/arch/arm/mach-omap2/cpuidle_omap4plus.c
@@ -22,12 +22,14 @@
#include "pm.h"
#include "prm.h"
#include "clockdomain.h"
+#include "soc.h"
/* Machine specific information */
struct idle_statedata {
u32 cpu_state;
u32 mpu_logic_state;
u32 mpu_state;
+ u32 mpu_state_vote;
};
static struct idle_statedata omap4_idle_data[] = {
@@ -48,17 +50,36 @@ static struct idle_statedata omap4_idle_data[] = {
},
};
+static struct idle_statedata omap5_idle_data[] = {
+ {
+ .cpu_state = PWRDM_POWER_ON,
+ .mpu_state = PWRDM_POWER_ON,
+ .mpu_logic_state = PWRDM_POWER_RET,
+ },
+ {
+ .cpu_state = PWRDM_POWER_RET,
+ .mpu_state = PWRDM_POWER_RET,
+ .mpu_logic_state = PWRDM_POWER_RET,
+ },
+ {
+ .cpu_state = PWRDM_POWER_OFF,
+ .mpu_state = PWRDM_POWER_RET,
+ .mpu_logic_state = PWRDM_POWER_OFF,
+ },
+};
+
static struct powerdomain *mpu_pd, *cpu_pd[NR_CPUS];
static struct clockdomain *cpu_clkdm[NR_CPUS];
static atomic_t abort_barrier;
static bool cpu_done[NR_CPUS];
-static struct idle_statedata *state_ptr = &omap4_idle_data[0];
+static struct idle_statedata *state_ptr;
+static DEFINE_RAW_SPINLOCK(mpu_lock);
/* Private functions */
/**
- * omap_enter_idle_[simple/coupled] - OMAP4PLUS cpuidle entry functions
+ * omap_enter_idle_[simple/smp/coupled] - OMAP4PLUS cpuidle entry functions
* @dev: cpuidle device
* @drv: cpuidle driver
* @index: the index of state to be entered
@@ -131,6 +152,8 @@ static int omap_enter_idle_coupled(struct cpuidle_device *dev,
/* Wakeup CPU1 only if it is not offlined */
if (dev->cpu == 0 && cpumask_test_cpu(1, cpu_online_mask)) {
+ /* Restore MPU PD state post idle */
+ omap_set_pwrdm_state(mpu_pd, PWRDM_POWER_ON);
clkdm_wakeup(cpu_clkdm[1]);
omap_set_pwrdm_state(cpu_pd[1], PWRDM_POWER_ON);
clkdm_allow_idle(cpu_clkdm[1]);
@@ -159,6 +182,37 @@ fail:
return index;
}
+static int omap_enter_idle_smp(struct cpuidle_device *dev,
+ struct cpuidle_driver *drv,
+ int index)
+{
+ struct idle_statedata *cx = state_ptr + index;
+ int cpu_id = smp_processor_id();
+ unsigned long flag;
+
+ clockevents_notify(CLOCK_EVT_NOTIFY_BROADCAST_ENTER, &cpu_id);
+
+ raw_spin_lock_irqsave(&mpu_lock, flag);
+ cx->mpu_state_vote++;
+ if (cx->mpu_state_vote == num_online_cpus()) {
+ pwrdm_set_logic_retst(mpu_pd, cx->mpu_logic_state);
+ omap_set_pwrdm_state(mpu_pd, cx->mpu_state);
+ }
+ raw_spin_unlock_irqrestore(&mpu_lock, flag);
+
+ omap4_enter_lowpower(dev->cpu, cx->cpu_state);
+
+ raw_spin_lock_irqsave(&mpu_lock, flag);
+ if (cx->mpu_state_vote == num_online_cpus())
+ omap_set_pwrdm_state(mpu_pd, PWRDM_POWER_ON);
+ cx->mpu_state_vote--;
+ raw_spin_unlock_irqrestore(&mpu_lock, flag);
+
+ clockevents_notify(CLOCK_EVT_NOTIFY_BROADCAST_EXIT, &cpu_id);
+
+ return index;
+}
+
/*
* For each cpu, setup the broadcast timer because local timers
* stops for the states above C1.
@@ -208,6 +262,43 @@ static struct cpuidle_driver omap4_idle_driver = {
.safe_state_index = 0,
};
+static struct cpuidle_driver omap5_idle_driver = {
+ .name = "omap5_idle",
+ .owner = THIS_MODULE,
+ .en_core_tk_irqen = 1,
+ .states = {
+ {
+ /* C1 - CPU0 ON + CPU1 ON + MPU ON */
+ .exit_latency = 2 + 2,
+ .target_residency = 5,
+ .flags = CPUIDLE_FLAG_TIME_VALID,
+ .enter = omap_enter_idle_simple,
+ .name = "C1",
+ .desc = "CPUx ON, MPUSS ON"
+ },
+ {
+ /* C2 - CPU0 CSWR + CPU1 CSWR + MPU CSWR */
+ .exit_latency = 16 + 16,
+ .target_residency = 40,
+ .flags = CPUIDLE_FLAG_TIME_VALID,
+ .enter = omap_enter_idle_smp,
+ .name = "C2",
+ .desc = "CPUx CSWR, MPUSS CSWR",
+ },
+ {
+ /* C3 - CPU0 OFF + CPU1 OFF + MPU OSWR */
+ .exit_latency = 460 + 518,
+ .target_residency = 1100,
+ .flags = CPUIDLE_FLAG_TIME_VALID | CPUIDLE_FLAG_COUPLED,
+ .enter = omap_enter_idle_coupled,
+ .name = "C3",
+ .desc = "CPUx OFF, MPUSS OSWR",
+ },
+ },
+ .state_count = ARRAY_SIZE(omap5_idle_data),
+ .safe_state_index = 0,
+};
+
/* Public functions */
/**
@@ -219,7 +310,8 @@ static struct cpuidle_driver omap4_idle_driver = {
int __init omap4_idle_init(void)
{
struct cpuidle_device *dev;
- unsigned int cpu_id = 0;
+ static struct cpuidle_driver *drv;
+ unsigned cpu_id = 0;
mpu_pd = pwrdm_lookup("mpu_pwrdm");
cpu_pd[0] = pwrdm_lookup("cpu0_pwrdm");
@@ -235,7 +327,15 @@ int __init omap4_idle_init(void)
/* Configure the broadcast timer on each cpu */
on_each_cpu(omap_setup_broadcast_timer, NULL, 1);
- if (cpuidle_register_driver(&omap4_idle_driver)) {
+ if (cpu_is_omap44xx()) {
+ drv = &omap4_idle_driver;
+ state_ptr = &omap4_idle_data[0];
+ } else if (soc_is_omap54xx()) {
+ drv = &omap5_idle_driver;
+ state_ptr = &omap5_idle_data[0];
+ }
+
+ if (cpuidle_register_driver(drv)) {
pr_err("%s: CPUidle driver register failed\n", __func__);
return -EIO;
}
@@ -248,7 +348,7 @@ int __init omap4_idle_init(void)
#endif
if (cpuidle_register_device(dev)) {
pr_err("%s: CPUidle register failed\n", __func__);
- cpuidle_unregister_driver(&omap4_idle_driver);
+ cpuidle_unregister_driver(drv);
return -EIO;
}
}
diff --git a/arch/arm/mach-omap2/omap-mpuss-lowpower.c b/arch/arm/mach-omap2/omap-mpuss-lowpower.c
index 6e917d7..8f6a0be 100644
--- a/arch/arm/mach-omap2/omap-mpuss-lowpower.c
+++ b/arch/arm/mach-omap2/omap-mpuss-lowpower.c
@@ -100,7 +100,7 @@ extern int omap5_finish_suspend(unsigned long cpu_state);
static DEFINE_PER_CPU(struct omap4_cpu_pm_info, omap4_pm_info);
static struct powerdomain *mpuss_pd;
static void __iomem *sar_base;
-static u32 cpu_context_offset;
+static u32 cpu_context_offset, cpu_cswr_supported;
static int default_finish_suspend(unsigned long cpu_state)
{
@@ -248,6 +248,10 @@ int omap4_enter_lowpower(unsigned int cpu, unsigned int power_state)
save_state = 1;
break;
case PWRDM_POWER_RET:
+ if (cpu_cswr_supported) {
+ save_state = 0;
+ break;
+ }
default:
/*
* CPUx CSWR is invalid hardware state. Also CPUx OSWR
@@ -441,6 +445,7 @@ int __init omap4_mpuss_init(void)
omap_pm_ops.resume = cpu_resume;
cpu_context_offset = OMAP54XX_RM_CPU0_CPU0_CONTEXT_OFFSET;
enable_mercury_retention_mode();
+ cpu_cswr_supported = 1;
}
/* Over-write the OMAP4 hook to take care of ROM BUG */
diff --git a/arch/arm/mach-omap2/pm_omap4plus.c b/arch/arm/mach-omap2/pm_omap4plus.c
index 2dadb4e..85408ce 100644
--- a/arch/arm/mach-omap2/pm_omap4plus.c
+++ b/arch/arm/mach-omap2/pm_omap4plus.c
@@ -275,7 +275,7 @@ int __init omap4_pm_init(void)
/* Overwrite the default cpu_do_idle() */
arm_pm_idle = omap_default_idle;
- if (cpu_is_omap44xx())
+ if (cpu_is_omap44xx() || soc_is_omap54xx())
omap4_idle_init();
err2:
--
1.7.9.5
^ permalink raw reply related [flat|nested] 128+ messages in thread
* [PATCH v2 17/18] ARM: OMAP4+: CPUidle: Add OMAP5 idle driver support
@ 2013-03-25 10:05 ` Santosh Shilimkar
0 siblings, 0 replies; 128+ messages in thread
From: Santosh Shilimkar @ 2013-03-25 10:05 UTC (permalink / raw)
To: linux-arm-kernel
The OMAP5 idle driver can re-use OMAP4 CPUidle driver implementation thanks
to compatible MPUSS design.
Though unlike OMAP4, on OMAP5 devices, MPUSS CSWR (Close Switch Retention)
power states can be achieved with respective power states on CPU0 and CPU1
power domain. This mode was broken on OMAP4 devices because of hardware
limitation. Also there is no CPU low power entry order requirement like
master CPU etc for CSWR C-state, which is icing on the cake. Code makes
use of voting scheme for cluster low power state to support MPUSS CSWR
C-state.
Supported OMAP5 CPUidle C-states:
C1 - CPU0 ON(WFI) + CPU1 ON(WFI) + MPUSS ON
C2 - CPU0 CSWR + CPU1 CSWR + MPUSS CSWR
C3 - CPU0 OFF + CPU1 OFF + MPUSS OSWR
Acked-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
---
arch/arm/mach-omap2/Kconfig | 1 +
arch/arm/mach-omap2/Makefile | 3 +-
.../{cpuidle44xx.c => cpuidle_omap4plus.c} | 110 +++++++++++++++++++-
arch/arm/mach-omap2/omap-mpuss-lowpower.c | 7 +-
arch/arm/mach-omap2/pm_omap4plus.c | 2 +-
5 files changed, 115 insertions(+), 8 deletions(-)
rename arch/arm/mach-omap2/{cpuidle44xx.c => cpuidle_omap4plus.c} (69%)
diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
index b9c0ed3..838ea67 100644
--- a/arch/arm/mach-omap2/Kconfig
+++ b/arch/arm/mach-omap2/Kconfig
@@ -105,6 +105,7 @@ config SOC_OMAP5
select HAVE_SMP
select COMMON_CLK
select HAVE_ARM_ARCH_TIMER
+ select ARCH_NEEDS_CPU_IDLE_COUPLED
comment "OMAP Core Type"
depends on ARCH_OMAP2
diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index d91ae0f..ddaaa6c 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -102,7 +102,8 @@ endif
ifeq ($(CONFIG_CPU_IDLE),y)
obj-$(CONFIG_ARCH_OMAP3) += cpuidle34xx.o
-obj-$(CONFIG_ARCH_OMAP4) += cpuidle44xx.o
+obj-$(CONFIG_ARCH_OMAP4) += cpuidle_omap4plus.o
+obj-$(CONFIG_SOC_OMAP5) += cpuidle_omap4plus.o
endif
# PRCM
diff --git a/arch/arm/mach-omap2/cpuidle44xx.c b/arch/arm/mach-omap2/cpuidle_omap4plus.c
similarity index 69%
rename from arch/arm/mach-omap2/cpuidle44xx.c
rename to arch/arm/mach-omap2/cpuidle_omap4plus.c
index e6218d3..defb830 100644
--- a/arch/arm/mach-omap2/cpuidle44xx.c
+++ b/arch/arm/mach-omap2/cpuidle_omap4plus.c
@@ -22,12 +22,14 @@
#include "pm.h"
#include "prm.h"
#include "clockdomain.h"
+#include "soc.h"
/* Machine specific information */
struct idle_statedata {
u32 cpu_state;
u32 mpu_logic_state;
u32 mpu_state;
+ u32 mpu_state_vote;
};
static struct idle_statedata omap4_idle_data[] = {
@@ -48,17 +50,36 @@ static struct idle_statedata omap4_idle_data[] = {
},
};
+static struct idle_statedata omap5_idle_data[] = {
+ {
+ .cpu_state = PWRDM_POWER_ON,
+ .mpu_state = PWRDM_POWER_ON,
+ .mpu_logic_state = PWRDM_POWER_RET,
+ },
+ {
+ .cpu_state = PWRDM_POWER_RET,
+ .mpu_state = PWRDM_POWER_RET,
+ .mpu_logic_state = PWRDM_POWER_RET,
+ },
+ {
+ .cpu_state = PWRDM_POWER_OFF,
+ .mpu_state = PWRDM_POWER_RET,
+ .mpu_logic_state = PWRDM_POWER_OFF,
+ },
+};
+
static struct powerdomain *mpu_pd, *cpu_pd[NR_CPUS];
static struct clockdomain *cpu_clkdm[NR_CPUS];
static atomic_t abort_barrier;
static bool cpu_done[NR_CPUS];
-static struct idle_statedata *state_ptr = &omap4_idle_data[0];
+static struct idle_statedata *state_ptr;
+static DEFINE_RAW_SPINLOCK(mpu_lock);
/* Private functions */
/**
- * omap_enter_idle_[simple/coupled] - OMAP4PLUS cpuidle entry functions
+ * omap_enter_idle_[simple/smp/coupled] - OMAP4PLUS cpuidle entry functions
* @dev: cpuidle device
* @drv: cpuidle driver
* @index: the index of state to be entered
@@ -131,6 +152,8 @@ static int omap_enter_idle_coupled(struct cpuidle_device *dev,
/* Wakeup CPU1 only if it is not offlined */
if (dev->cpu == 0 && cpumask_test_cpu(1, cpu_online_mask)) {
+ /* Restore MPU PD state post idle */
+ omap_set_pwrdm_state(mpu_pd, PWRDM_POWER_ON);
clkdm_wakeup(cpu_clkdm[1]);
omap_set_pwrdm_state(cpu_pd[1], PWRDM_POWER_ON);
clkdm_allow_idle(cpu_clkdm[1]);
@@ -159,6 +182,37 @@ fail:
return index;
}
+static int omap_enter_idle_smp(struct cpuidle_device *dev,
+ struct cpuidle_driver *drv,
+ int index)
+{
+ struct idle_statedata *cx = state_ptr + index;
+ int cpu_id = smp_processor_id();
+ unsigned long flag;
+
+ clockevents_notify(CLOCK_EVT_NOTIFY_BROADCAST_ENTER, &cpu_id);
+
+ raw_spin_lock_irqsave(&mpu_lock, flag);
+ cx->mpu_state_vote++;
+ if (cx->mpu_state_vote == num_online_cpus()) {
+ pwrdm_set_logic_retst(mpu_pd, cx->mpu_logic_state);
+ omap_set_pwrdm_state(mpu_pd, cx->mpu_state);
+ }
+ raw_spin_unlock_irqrestore(&mpu_lock, flag);
+
+ omap4_enter_lowpower(dev->cpu, cx->cpu_state);
+
+ raw_spin_lock_irqsave(&mpu_lock, flag);
+ if (cx->mpu_state_vote == num_online_cpus())
+ omap_set_pwrdm_state(mpu_pd, PWRDM_POWER_ON);
+ cx->mpu_state_vote--;
+ raw_spin_unlock_irqrestore(&mpu_lock, flag);
+
+ clockevents_notify(CLOCK_EVT_NOTIFY_BROADCAST_EXIT, &cpu_id);
+
+ return index;
+}
+
/*
* For each cpu, setup the broadcast timer because local timers
* stops for the states above C1.
@@ -208,6 +262,43 @@ static struct cpuidle_driver omap4_idle_driver = {
.safe_state_index = 0,
};
+static struct cpuidle_driver omap5_idle_driver = {
+ .name = "omap5_idle",
+ .owner = THIS_MODULE,
+ .en_core_tk_irqen = 1,
+ .states = {
+ {
+ /* C1 - CPU0 ON + CPU1 ON + MPU ON */
+ .exit_latency = 2 + 2,
+ .target_residency = 5,
+ .flags = CPUIDLE_FLAG_TIME_VALID,
+ .enter = omap_enter_idle_simple,
+ .name = "C1",
+ .desc = "CPUx ON, MPUSS ON"
+ },
+ {
+ /* C2 - CPU0 CSWR + CPU1 CSWR + MPU CSWR */
+ .exit_latency = 16 + 16,
+ .target_residency = 40,
+ .flags = CPUIDLE_FLAG_TIME_VALID,
+ .enter = omap_enter_idle_smp,
+ .name = "C2",
+ .desc = "CPUx CSWR, MPUSS CSWR",
+ },
+ {
+ /* C3 - CPU0 OFF + CPU1 OFF + MPU OSWR */
+ .exit_latency = 460 + 518,
+ .target_residency = 1100,
+ .flags = CPUIDLE_FLAG_TIME_VALID | CPUIDLE_FLAG_COUPLED,
+ .enter = omap_enter_idle_coupled,
+ .name = "C3",
+ .desc = "CPUx OFF, MPUSS OSWR",
+ },
+ },
+ .state_count = ARRAY_SIZE(omap5_idle_data),
+ .safe_state_index = 0,
+};
+
/* Public functions */
/**
@@ -219,7 +310,8 @@ static struct cpuidle_driver omap4_idle_driver = {
int __init omap4_idle_init(void)
{
struct cpuidle_device *dev;
- unsigned int cpu_id = 0;
+ static struct cpuidle_driver *drv;
+ unsigned cpu_id = 0;
mpu_pd = pwrdm_lookup("mpu_pwrdm");
cpu_pd[0] = pwrdm_lookup("cpu0_pwrdm");
@@ -235,7 +327,15 @@ int __init omap4_idle_init(void)
/* Configure the broadcast timer on each cpu */
on_each_cpu(omap_setup_broadcast_timer, NULL, 1);
- if (cpuidle_register_driver(&omap4_idle_driver)) {
+ if (cpu_is_omap44xx()) {
+ drv = &omap4_idle_driver;
+ state_ptr = &omap4_idle_data[0];
+ } else if (soc_is_omap54xx()) {
+ drv = &omap5_idle_driver;
+ state_ptr = &omap5_idle_data[0];
+ }
+
+ if (cpuidle_register_driver(drv)) {
pr_err("%s: CPUidle driver register failed\n", __func__);
return -EIO;
}
@@ -248,7 +348,7 @@ int __init omap4_idle_init(void)
#endif
if (cpuidle_register_device(dev)) {
pr_err("%s: CPUidle register failed\n", __func__);
- cpuidle_unregister_driver(&omap4_idle_driver);
+ cpuidle_unregister_driver(drv);
return -EIO;
}
}
diff --git a/arch/arm/mach-omap2/omap-mpuss-lowpower.c b/arch/arm/mach-omap2/omap-mpuss-lowpower.c
index 6e917d7..8f6a0be 100644
--- a/arch/arm/mach-omap2/omap-mpuss-lowpower.c
+++ b/arch/arm/mach-omap2/omap-mpuss-lowpower.c
@@ -100,7 +100,7 @@ extern int omap5_finish_suspend(unsigned long cpu_state);
static DEFINE_PER_CPU(struct omap4_cpu_pm_info, omap4_pm_info);
static struct powerdomain *mpuss_pd;
static void __iomem *sar_base;
-static u32 cpu_context_offset;
+static u32 cpu_context_offset, cpu_cswr_supported;
static int default_finish_suspend(unsigned long cpu_state)
{
@@ -248,6 +248,10 @@ int omap4_enter_lowpower(unsigned int cpu, unsigned int power_state)
save_state = 1;
break;
case PWRDM_POWER_RET:
+ if (cpu_cswr_supported) {
+ save_state = 0;
+ break;
+ }
default:
/*
* CPUx CSWR is invalid hardware state. Also CPUx OSWR
@@ -441,6 +445,7 @@ int __init omap4_mpuss_init(void)
omap_pm_ops.resume = cpu_resume;
cpu_context_offset = OMAP54XX_RM_CPU0_CPU0_CONTEXT_OFFSET;
enable_mercury_retention_mode();
+ cpu_cswr_supported = 1;
}
/* Over-write the OMAP4 hook to take care of ROM BUG */
diff --git a/arch/arm/mach-omap2/pm_omap4plus.c b/arch/arm/mach-omap2/pm_omap4plus.c
index 2dadb4e..85408ce 100644
--- a/arch/arm/mach-omap2/pm_omap4plus.c
+++ b/arch/arm/mach-omap2/pm_omap4plus.c
@@ -275,7 +275,7 @@ int __init omap4_pm_init(void)
/* Overwrite the default cpu_do_idle() */
arm_pm_idle = omap_default_idle;
- if (cpu_is_omap44xx())
+ if (cpu_is_omap44xx() || soc_is_omap54xx())
omap4_idle_init();
err2:
--
1.7.9.5
^ permalink raw reply related [flat|nested] 128+ messages in thread
* [PATCH v2 18/18] ARM: OMAP5: PM: handle device instance for warm reset
2013-03-25 10:04 ` Santosh Shilimkar
@ 2013-03-25 10:05 ` Santosh Shilimkar
-1 siblings, 0 replies; 128+ messages in thread
From: Santosh Shilimkar @ 2013-03-25 10:05 UTC (permalink / raw)
To: khilman; +Cc: linux-omap, linux-arm-kernel, nm, tony, Santosh Shilimkar
From: Nishanth Menon <nm@ti.com>
OMAP5 and OMAP4 have different device instance offsets.
So to handle them properly, use a runtime detected instance offset
Other bit offsets and register offsets remained constant.
Creating a new function is not really worthwhile here as the logic
will be replicated without much benefit.
Signed-off-by: Nishanth Menon <nm@ti.com>
[santosh.shilimkar@ti.com: Refreshed patch against 3.9]
Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
---
arch/arm/mach-omap2/prminst44xx.c | 10 +++++++---
1 file changed, 7 insertions(+), 3 deletions(-)
diff --git a/arch/arm/mach-omap2/prminst44xx.c b/arch/arm/mach-omap2/prminst44xx.c
index c12320c..430fb1d 100644
--- a/arch/arm/mach-omap2/prminst44xx.c
+++ b/arch/arm/mach-omap2/prminst44xx.c
@@ -20,10 +20,12 @@
#include "common.h"
#include "prcm-common.h"
#include "prm44xx.h"
+#include "prm54xx.h"
#include "prminst44xx.h"
#include "prm-regbits-44xx.h"
#include "prcm44xx.h"
#include "prcm_mpu44xx.h"
+#include "soc.h"
static void __iomem *_prm_bases[OMAP4_MAX_PRCM_PARTITIONS];
@@ -165,17 +167,19 @@ int omap4_prminst_deassert_hardreset(u8 shift, u8 part, s16 inst,
void omap4_prminst_global_warm_sw_reset(void)
{
u32 v;
+ s16 dev_inst = cpu_is_omap44xx() ? OMAP4430_PRM_DEVICE_INST :
+ OMAP54XX_PRM_DEVICE_INST;
v = omap4_prminst_read_inst_reg(OMAP4430_PRM_PARTITION,
- OMAP4430_PRM_DEVICE_INST,
+ dev_inst,
OMAP4_PRM_RSTCTRL_OFFSET);
v |= OMAP4430_RST_GLOBAL_WARM_SW_MASK;
omap4_prminst_write_inst_reg(v, OMAP4430_PRM_PARTITION,
- OMAP4430_PRM_DEVICE_INST,
+ dev_inst,
OMAP4_PRM_RSTCTRL_OFFSET);
/* OCP barrier */
v = omap4_prminst_read_inst_reg(OMAP4430_PRM_PARTITION,
- OMAP4430_PRM_DEVICE_INST,
+ dev_inst,
OMAP4_PRM_RSTCTRL_OFFSET);
}
--
1.7.9.5
^ permalink raw reply related [flat|nested] 128+ messages in thread
* [PATCH v2 18/18] ARM: OMAP5: PM: handle device instance for warm reset
@ 2013-03-25 10:05 ` Santosh Shilimkar
0 siblings, 0 replies; 128+ messages in thread
From: Santosh Shilimkar @ 2013-03-25 10:05 UTC (permalink / raw)
To: linux-arm-kernel
From: Nishanth Menon <nm@ti.com>
OMAP5 and OMAP4 have different device instance offsets.
So to handle them properly, use a runtime detected instance offset
Other bit offsets and register offsets remained constant.
Creating a new function is not really worthwhile here as the logic
will be replicated without much benefit.
Signed-off-by: Nishanth Menon <nm@ti.com>
[santosh.shilimkar at ti.com: Refreshed patch against 3.9]
Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
---
arch/arm/mach-omap2/prminst44xx.c | 10 +++++++---
1 file changed, 7 insertions(+), 3 deletions(-)
diff --git a/arch/arm/mach-omap2/prminst44xx.c b/arch/arm/mach-omap2/prminst44xx.c
index c12320c..430fb1d 100644
--- a/arch/arm/mach-omap2/prminst44xx.c
+++ b/arch/arm/mach-omap2/prminst44xx.c
@@ -20,10 +20,12 @@
#include "common.h"
#include "prcm-common.h"
#include "prm44xx.h"
+#include "prm54xx.h"
#include "prminst44xx.h"
#include "prm-regbits-44xx.h"
#include "prcm44xx.h"
#include "prcm_mpu44xx.h"
+#include "soc.h"
static void __iomem *_prm_bases[OMAP4_MAX_PRCM_PARTITIONS];
@@ -165,17 +167,19 @@ int omap4_prminst_deassert_hardreset(u8 shift, u8 part, s16 inst,
void omap4_prminst_global_warm_sw_reset(void)
{
u32 v;
+ s16 dev_inst = cpu_is_omap44xx() ? OMAP4430_PRM_DEVICE_INST :
+ OMAP54XX_PRM_DEVICE_INST;
v = omap4_prminst_read_inst_reg(OMAP4430_PRM_PARTITION,
- OMAP4430_PRM_DEVICE_INST,
+ dev_inst,
OMAP4_PRM_RSTCTRL_OFFSET);
v |= OMAP4430_RST_GLOBAL_WARM_SW_MASK;
omap4_prminst_write_inst_reg(v, OMAP4430_PRM_PARTITION,
- OMAP4430_PRM_DEVICE_INST,
+ dev_inst,
OMAP4_PRM_RSTCTRL_OFFSET);
/* OCP barrier */
v = omap4_prminst_read_inst_reg(OMAP4430_PRM_PARTITION,
- OMAP4430_PRM_DEVICE_INST,
+ dev_inst,
OMAP4_PRM_RSTCTRL_OFFSET);
}
--
1.7.9.5
^ permalink raw reply related [flat|nested] 128+ messages in thread
* Re: [PATCH v2 00/18] ARM: OMAP5: PM: Add MPUSS suspend and CPUidle support
2013-03-25 10:04 ` Santosh Shilimkar
@ 2013-03-25 11:46 ` Lokesh Vutla
-1 siblings, 0 replies; 128+ messages in thread
From: Lokesh Vutla @ 2013-03-25 11:46 UTC (permalink / raw)
To: Santosh Shilimkar; +Cc: khilman, linux-omap, linux-arm-kernel, nm, tony
Hi Santosh,
On Monday 25 March 2013 03:34 PM, Santosh Shilimkar wrote:
> Kevin,
>
> Here is the refreshed version(v2) of the OMAP5 PM suspport which was posted
> earlier (March 1st 2013). Patch-set incorporates comments from Nishant
> Menon (Thanks for review NM) and his acked-by tags. I would like to get this
> queued for 3.10 merge window if you are ok with the series.
>
> Series is built on top of my pull requests [1] [2] [3] sent to Tony and your
> 'for_3.10/pm/cleanup' branch. For testing, I have created a branch [4]
> which put together all the needed dependencies, fixes which should make it
> to 3.10 merge window.
>
> Series adds OMAP5 MPUSS power management support for system wide suspend
> and CPUidle. Its heavy re-use from OMAP4 and hence only ~400 odd lines are
> needed to add OMAP5 PM support on top of existing OMAP4 PM support.
>
> OMAP5 adds a mercury retention feature which is an enhancement of
> existing retention feature to reduce the leakage. No change in
> programming model except one time enabling of mercury retention
> during init.
>
> One more notable change in OMAP5 vs OMAP4 devices, CPUx power domains
> support retention state which lets you hit MPUSS and Core retention with
> very low latency C-states.
>
> Tested on OMAP4430 SDP, OMAP4460 Panda, OMAP5430 SDP and OMAP5432 Panda
> devices with suspend and CPUIdle. Rootfs is mounted over ramdisk since
> the mmc and nfs based fs needs DMA engine patches. For suspend wakeup,
> I used Sourav's couple of serial wakeup wip patches from the lists.
I did the following build tests on [1]:
-> Native omap2plus build
-> Omap2 only build
-> Omap3 only build
-> Omap4 only build
-> Omap5 only build
-> AM33XX only build.
-> omap1_defconfig
And also did functional testing on [2] where omap5_pm branch[1] is merged.
On OMAP5430 EVM: Suspend to RAM (UART wakeup)
CPU_IDLE
On OMAP4430 SDP: Suspend to RAM (UART wakeup)
CPU_IDLE
Note:
1) Disabled SMP for doing build test on Omap2/3 only builds.
2) If we enable CPU_IDLE on OMAP4430, debug message flood from
reset_ctrl_regs() will appear.
As this is already disussed and a patch is already sent on Mainline
Will get more info on this here[3]
Tested-by: Lokesh Vutla <lokeshvutla@ti.com>
Thanks and Regards,
Lokesh
[1] git://git.kernel.org/pub/scm/linux/kernel/git/ssantosh/linux
for_3.10/omap5_pm
[2] git://git.kernel.org/pub/scm/linux/kernel/git/ssantosh/linux.git
testing/3.10/omap5_int
[3] https://lkml.org/lkml/2013/3/13/50
>
> The following changes since commit 9981cde24de52e5bb9a7cd918d1e54de241f85c9:
>
> Merge branch 'for_3.10/omap5_data_files' of git://git.kernel.org/pub/scm/linux/kernel/git/ssantosh/linux into for_3.10/omap5_pm (2013-03-25 12:29:34 +0530)
>
> are available in the git repository at:
>
>
> git://git.kernel.org/pub/scm/linux/kernel/git/ssantosh/linux.git for_3.10/omap5_pm
>
> for you to fetch changes up to 75bd846d3103da858a208fe07127151903d1f608:
>
> ARM: OMAP5: PM: handle device instance for warm reset (2013-03-25 12:37:44 +0530)
>
> ----------------------------------------------------------------
> Nishanth Menon (1):
> ARM: OMAP5: PM: handle device instance for warm reset
>
> Santosh Shilimkar (17):
> ARM: OMAP4+: PM: Consolidate MPU subsystem PM code for re-use
> ARM: OMAP5: PM: Update CPU context register offset
> ARM: OMAP4+: PM: Consolidate and use OMAP4 PM code for OMAP5
> ARM: OMAP5: PM: Set MPUSS-EMIF clock-domain static dependency
> ARM: OMAP5: PM: Enables ES2 PM mode by default
> ARM: OMAP5: PM: Enable Mercury retention mode on CPUx powerdomains
> ARM: OMAP5: Add init_late() hook to enable pm initialization
> ARM: OMAP5: PM: Add CPU power off in hotplug path
> ARM: OMAP4+: PM: Restore CPU power state to ON with clockdomain force
> wakeup method
> ARM: OMAP5: PM: Add MPU Open Switch Retention support
> ARM: OMAP5: PM: Add L2 memory power down support
> ARM: OMAP4: CPUidle: Avoid double idle driver registration
> ARM: OMAP: CPUidle: Unregister drivere on device registration failure
> ARM: OMAP4: CPUidle: Make C-state description field more precise
> ARM: OMAP4+: CPUidle: Consolidate idle driver for OMAP5 support
> ARM: OMAP4+: CPUidle: Deprecate use of
> omap4_mpuss_read_prev_context_state()
> ARM: OMAP4+: CPUidle: Add OMAP5 idle driver support
>
> arch/arm/mach-omap2/Kconfig | 1 +
> arch/arm/mach-omap2/Makefile | 12 +-
> arch/arm/mach-omap2/board-generic.c | 1 +
> arch/arm/mach-omap2/common.h | 8 +-
> arch/arm/mach-omap2/cpuidle34xx.c | 6 +-
> .../{cpuidle44xx.c => cpuidle_omap4plus.c} | 151 ++++++++++++++++---
> arch/arm/mach-omap2/io.c | 8 +
> arch/arm/mach-omap2/omap-mpuss-lowpower.c | 155 +++++++++++++++-----
> arch/arm/mach-omap2/omap-secure.h | 9 ++
> arch/arm/mach-omap2/omap-smp.c | 12 +-
> arch/arm/mach-omap2/omap-wakeupgen.c | 30 +++-
> arch/arm/mach-omap2/omap-wakeupgen.h | 1 +
> arch/arm/mach-omap2/omap4-sar-layout.h | 2 +
> arch/arm/mach-omap2/{pm44xx.c => pm_omap4plus.c} | 90 ++++++++++--
> arch/arm/mach-omap2/prminst44xx.c | 10 +-
> .../mach-omap2/{sleep44xx.S => sleep_omap4plus.S} | 106 +++++++++++++
> 16 files changed, 512 insertions(+), 90 deletions(-)
> rename arch/arm/mach-omap2/{cpuidle44xx.c => cpuidle_omap4plus.c} (58%)
> rename arch/arm/mach-omap2/{pm44xx.c => pm_omap4plus.c} (74%)
> rename arch/arm/mach-omap2/{sleep44xx.S => sleep_omap4plus.S} (77%)
>
^ permalink raw reply [flat|nested] 128+ messages in thread
* [PATCH v2 00/18] ARM: OMAP5: PM: Add MPUSS suspend and CPUidle support
@ 2013-03-25 11:46 ` Lokesh Vutla
0 siblings, 0 replies; 128+ messages in thread
From: Lokesh Vutla @ 2013-03-25 11:46 UTC (permalink / raw)
To: linux-arm-kernel
Hi Santosh,
On Monday 25 March 2013 03:34 PM, Santosh Shilimkar wrote:
> Kevin,
>
> Here is the refreshed version(v2) of the OMAP5 PM suspport which was posted
> earlier (March 1st 2013). Patch-set incorporates comments from Nishant
> Menon (Thanks for review NM) and his acked-by tags. I would like to get this
> queued for 3.10 merge window if you are ok with the series.
>
> Series is built on top of my pull requests [1] [2] [3] sent to Tony and your
> 'for_3.10/pm/cleanup' branch. For testing, I have created a branch [4]
> which put together all the needed dependencies, fixes which should make it
> to 3.10 merge window.
>
> Series adds OMAP5 MPUSS power management support for system wide suspend
> and CPUidle. Its heavy re-use from OMAP4 and hence only ~400 odd lines are
> needed to add OMAP5 PM support on top of existing OMAP4 PM support.
>
> OMAP5 adds a mercury retention feature which is an enhancement of
> existing retention feature to reduce the leakage. No change in
> programming model except one time enabling of mercury retention
> during init.
>
> One more notable change in OMAP5 vs OMAP4 devices, CPUx power domains
> support retention state which lets you hit MPUSS and Core retention with
> very low latency C-states.
>
> Tested on OMAP4430 SDP, OMAP4460 Panda, OMAP5430 SDP and OMAP5432 Panda
> devices with suspend and CPUIdle. Rootfs is mounted over ramdisk since
> the mmc and nfs based fs needs DMA engine patches. For suspend wakeup,
> I used Sourav's couple of serial wakeup wip patches from the lists.
I did the following build tests on [1]:
-> Native omap2plus build
-> Omap2 only build
-> Omap3 only build
-> Omap4 only build
-> Omap5 only build
-> AM33XX only build.
-> omap1_defconfig
And also did functional testing on [2] where omap5_pm branch[1] is merged.
On OMAP5430 EVM: Suspend to RAM (UART wakeup)
CPU_IDLE
On OMAP4430 SDP: Suspend to RAM (UART wakeup)
CPU_IDLE
Note:
1) Disabled SMP for doing build test on Omap2/3 only builds.
2) If we enable CPU_IDLE on OMAP4430, debug message flood from
reset_ctrl_regs() will appear.
As this is already disussed and a patch is already sent on Mainline
Will get more info on this here[3]
Tested-by: Lokesh Vutla <lokeshvutla@ti.com>
Thanks and Regards,
Lokesh
[1] git://git.kernel.org/pub/scm/linux/kernel/git/ssantosh/linux
for_3.10/omap5_pm
[2] git://git.kernel.org/pub/scm/linux/kernel/git/ssantosh/linux.git
testing/3.10/omap5_int
[3] https://lkml.org/lkml/2013/3/13/50
>
> The following changes since commit 9981cde24de52e5bb9a7cd918d1e54de241f85c9:
>
> Merge branch 'for_3.10/omap5_data_files' of git://git.kernel.org/pub/scm/linux/kernel/git/ssantosh/linux into for_3.10/omap5_pm (2013-03-25 12:29:34 +0530)
>
> are available in the git repository at:
>
>
> git://git.kernel.org/pub/scm/linux/kernel/git/ssantosh/linux.git for_3.10/omap5_pm
>
> for you to fetch changes up to 75bd846d3103da858a208fe07127151903d1f608:
>
> ARM: OMAP5: PM: handle device instance for warm reset (2013-03-25 12:37:44 +0530)
>
> ----------------------------------------------------------------
> Nishanth Menon (1):
> ARM: OMAP5: PM: handle device instance for warm reset
>
> Santosh Shilimkar (17):
> ARM: OMAP4+: PM: Consolidate MPU subsystem PM code for re-use
> ARM: OMAP5: PM: Update CPU context register offset
> ARM: OMAP4+: PM: Consolidate and use OMAP4 PM code for OMAP5
> ARM: OMAP5: PM: Set MPUSS-EMIF clock-domain static dependency
> ARM: OMAP5: PM: Enables ES2 PM mode by default
> ARM: OMAP5: PM: Enable Mercury retention mode on CPUx powerdomains
> ARM: OMAP5: Add init_late() hook to enable pm initialization
> ARM: OMAP5: PM: Add CPU power off in hotplug path
> ARM: OMAP4+: PM: Restore CPU power state to ON with clockdomain force
> wakeup method
> ARM: OMAP5: PM: Add MPU Open Switch Retention support
> ARM: OMAP5: PM: Add L2 memory power down support
> ARM: OMAP4: CPUidle: Avoid double idle driver registration
> ARM: OMAP: CPUidle: Unregister drivere on device registration failure
> ARM: OMAP4: CPUidle: Make C-state description field more precise
> ARM: OMAP4+: CPUidle: Consolidate idle driver for OMAP5 support
> ARM: OMAP4+: CPUidle: Deprecate use of
> omap4_mpuss_read_prev_context_state()
> ARM: OMAP4+: CPUidle: Add OMAP5 idle driver support
>
> arch/arm/mach-omap2/Kconfig | 1 +
> arch/arm/mach-omap2/Makefile | 12 +-
> arch/arm/mach-omap2/board-generic.c | 1 +
> arch/arm/mach-omap2/common.h | 8 +-
> arch/arm/mach-omap2/cpuidle34xx.c | 6 +-
> .../{cpuidle44xx.c => cpuidle_omap4plus.c} | 151 ++++++++++++++++---
> arch/arm/mach-omap2/io.c | 8 +
> arch/arm/mach-omap2/omap-mpuss-lowpower.c | 155 +++++++++++++++-----
> arch/arm/mach-omap2/omap-secure.h | 9 ++
> arch/arm/mach-omap2/omap-smp.c | 12 +-
> arch/arm/mach-omap2/omap-wakeupgen.c | 30 +++-
> arch/arm/mach-omap2/omap-wakeupgen.h | 1 +
> arch/arm/mach-omap2/omap4-sar-layout.h | 2 +
> arch/arm/mach-omap2/{pm44xx.c => pm_omap4plus.c} | 90 ++++++++++--
> arch/arm/mach-omap2/prminst44xx.c | 10 +-
> .../mach-omap2/{sleep44xx.S => sleep_omap4plus.S} | 106 +++++++++++++
> 16 files changed, 512 insertions(+), 90 deletions(-)
> rename arch/arm/mach-omap2/{cpuidle44xx.c => cpuidle_omap4plus.c} (58%)
> rename arch/arm/mach-omap2/{pm44xx.c => pm_omap4plus.c} (74%)
> rename arch/arm/mach-omap2/{sleep44xx.S => sleep_omap4plus.S} (77%)
>
^ permalink raw reply [flat|nested] 128+ messages in thread
* Re: [PATCH v2 00/18] ARM: OMAP5: PM: Add MPUSS suspend and CPUidle support
2013-03-25 11:46 ` Lokesh Vutla
@ 2013-03-25 12:10 ` Santosh Shilimkar
-1 siblings, 0 replies; 128+ messages in thread
From: Santosh Shilimkar @ 2013-03-25 12:10 UTC (permalink / raw)
To: Lokesh Vutla; +Cc: khilman, linux-omap, linux-arm-kernel, nm, tony
On Monday 25 March 2013 05:16 PM, Lokesh Vutla wrote:
> Hi Santosh,
>
> On Monday 25 March 2013 03:34 PM, Santosh Shilimkar wrote:
>> Kevin,
>>
>> Here is the refreshed version(v2) of the OMAP5 PM suspport which was posted
>> earlier (March 1st 2013). Patch-set incorporates comments from Nishant
>> Menon (Thanks for review NM) and his acked-by tags. I would like to get this
>> queued for 3.10 merge window if you are ok with the series.
>>
>> Series is built on top of my pull requests [1] [2] [3] sent to Tony and your
>> 'for_3.10/pm/cleanup' branch. For testing, I have created a branch [4]
>> which put together all the needed dependencies, fixes which should make it
>> to 3.10 merge window.
>>
>> Series adds OMAP5 MPUSS power management support for system wide suspend
>> and CPUidle. Its heavy re-use from OMAP4 and hence only ~400 odd lines are
>> needed to add OMAP5 PM support on top of existing OMAP4 PM support.
>>
>> OMAP5 adds a mercury retention feature which is an enhancement of
>> existing retention feature to reduce the leakage. No change in
>> programming model except one time enabling of mercury retention
>> during init.
>>
>> One more notable change in OMAP5 vs OMAP4 devices, CPUx power domains
>> support retention state which lets you hit MPUSS and Core retention with
>> very low latency C-states.
>>
>> Tested on OMAP4430 SDP, OMAP4460 Panda, OMAP5430 SDP and OMAP5432 Panda
>> devices with suspend and CPUIdle. Rootfs is mounted over ramdisk since
>> the mmc and nfs based fs needs DMA engine patches. For suspend wakeup,
>> I used Sourav's couple of serial wakeup wip patches from the lists.
>
> I did the following build tests on [1]:
> -> Native omap2plus build
> -> Omap2 only build
> -> Omap3 only build
> -> Omap4 only build
> -> Omap5 only build
> -> AM33XX only build.
> -> omap1_defconfig
>
Thanks for the build coverage.
> And also did functional testing on [2] where omap5_pm branch[1] is merged.
> On OMAP5430 EVM: Suspend to RAM (UART wakeup)
> CPU_IDLE
> On OMAP4430 SDP: Suspend to RAM (UART wakeup)
> CPU_IDLE
Excellent.
> Note:
> 1) Disabled SMP for doing build test on Omap2/3 only builds.
I noticed this one as well.
> 2) If we enable CPU_IDLE on OMAP4430, debug message flood from reset_ctrl_regs() will appear.
> As this is already disussed and a patch is already sent on Mainline
> Will get more info on this here[3]
>
Yep. I applied the patch while testing. The patch is already in RMK's queue as per Will D.
> Tested-by: Lokesh Vutla <lokeshvutla@ti.com>
>
Thanks a bunch for detailed testing and your tested-by tag.
Regards,
Santosh
>
> [1] git://git.kernel.org/pub/scm/linux/kernel/git/ssantosh/linux for_3.10/omap5_pm
> [2] git://git.kernel.org/pub/scm/linux/kernel/git/ssantosh/linux.git testing/3.10/omap5_int
> [3] https://lkml.org/lkml/2013/3/13/50
>
^ permalink raw reply [flat|nested] 128+ messages in thread
* [PATCH v2 00/18] ARM: OMAP5: PM: Add MPUSS suspend and CPUidle support
@ 2013-03-25 12:10 ` Santosh Shilimkar
0 siblings, 0 replies; 128+ messages in thread
From: Santosh Shilimkar @ 2013-03-25 12:10 UTC (permalink / raw)
To: linux-arm-kernel
On Monday 25 March 2013 05:16 PM, Lokesh Vutla wrote:
> Hi Santosh,
>
> On Monday 25 March 2013 03:34 PM, Santosh Shilimkar wrote:
>> Kevin,
>>
>> Here is the refreshed version(v2) of the OMAP5 PM suspport which was posted
>> earlier (March 1st 2013). Patch-set incorporates comments from Nishant
>> Menon (Thanks for review NM) and his acked-by tags. I would like to get this
>> queued for 3.10 merge window if you are ok with the series.
>>
>> Series is built on top of my pull requests [1] [2] [3] sent to Tony and your
>> 'for_3.10/pm/cleanup' branch. For testing, I have created a branch [4]
>> which put together all the needed dependencies, fixes which should make it
>> to 3.10 merge window.
>>
>> Series adds OMAP5 MPUSS power management support for system wide suspend
>> and CPUidle. Its heavy re-use from OMAP4 and hence only ~400 odd lines are
>> needed to add OMAP5 PM support on top of existing OMAP4 PM support.
>>
>> OMAP5 adds a mercury retention feature which is an enhancement of
>> existing retention feature to reduce the leakage. No change in
>> programming model except one time enabling of mercury retention
>> during init.
>>
>> One more notable change in OMAP5 vs OMAP4 devices, CPUx power domains
>> support retention state which lets you hit MPUSS and Core retention with
>> very low latency C-states.
>>
>> Tested on OMAP4430 SDP, OMAP4460 Panda, OMAP5430 SDP and OMAP5432 Panda
>> devices with suspend and CPUIdle. Rootfs is mounted over ramdisk since
>> the mmc and nfs based fs needs DMA engine patches. For suspend wakeup,
>> I used Sourav's couple of serial wakeup wip patches from the lists.
>
> I did the following build tests on [1]:
> -> Native omap2plus build
> -> Omap2 only build
> -> Omap3 only build
> -> Omap4 only build
> -> Omap5 only build
> -> AM33XX only build.
> -> omap1_defconfig
>
Thanks for the build coverage.
> And also did functional testing on [2] where omap5_pm branch[1] is merged.
> On OMAP5430 EVM: Suspend to RAM (UART wakeup)
> CPU_IDLE
> On OMAP4430 SDP: Suspend to RAM (UART wakeup)
> CPU_IDLE
Excellent.
> Note:
> 1) Disabled SMP for doing build test on Omap2/3 only builds.
I noticed this one as well.
> 2) If we enable CPU_IDLE on OMAP4430, debug message flood from reset_ctrl_regs() will appear.
> As this is already disussed and a patch is already sent on Mainline
> Will get more info on this here[3]
>
Yep. I applied the patch while testing. The patch is already in RMK's queue as per Will D.
> Tested-by: Lokesh Vutla <lokeshvutla@ti.com>
>
Thanks a bunch for detailed testing and your tested-by tag.
Regards,
Santosh
>
> [1] git://git.kernel.org/pub/scm/linux/kernel/git/ssantosh/linux for_3.10/omap5_pm
> [2] git://git.kernel.org/pub/scm/linux/kernel/git/ssantosh/linux.git testing/3.10/omap5_int
> [3] https://lkml.org/lkml/2013/3/13/50
>
^ permalink raw reply [flat|nested] 128+ messages in thread
* Re: [PATCH v2 00/18] ARM: OMAP5: PM: Add MPUSS suspend and CPUidle support
2013-03-25 10:04 ` Santosh Shilimkar
@ 2013-03-25 12:27 ` Sourav Poddar
-1 siblings, 0 replies; 128+ messages in thread
From: Sourav Poddar @ 2013-03-25 12:27 UTC (permalink / raw)
To: Santosh Shilimkar; +Cc: khilman, linux-omap, linux-arm-kernel, nm, tony
Hi Santosh,
On Monday 25 March 2013 03:34 PM, Santosh Shilimkar wrote:
> Kevin,
>
> Here is the refreshed version(v2) of the OMAP5 PM suspport which was posted
> earlier (March 1st 2013). Patch-set incorporates comments from Nishant
> Menon (Thanks for review NM) and his acked-by tags. I would like to get this
> queued for 3.10 merge window if you are ok with the series.
>
> Series is built on top of my pull requests [1] [2] [3] sent to Tony and your
> 'for_3.10/pm/cleanup' branch. For testing, I have created a branch [4]
> which put together all the needed dependencies, fixes which should make it
> to 3.10 merge window.
>
> Series adds OMAP5 MPUSS power management support for system wide suspend
> and CPUidle. Its heavy re-use from OMAP4 and hence only ~400 odd lines are
> needed to add OMAP5 PM support on top of existing OMAP4 PM support.
>
> OMAP5 adds a mercury retention feature which is an enhancement of
> existing retention feature to reduce the leakage. No change in
> programming model except one time enabling of mercury retention
> during init.
>
> One more notable change in OMAP5 vs OMAP4 devices, CPUx power domains
> support retention state which lets you hit MPUSS and Core retention with
> very low latency C-states.
>
> Tested on OMAP4430 SDP, OMAP4460 Panda, OMAP5430 SDP and OMAP5432 Panda
> devices with suspend and CPUIdle. Rootfs is mounted over ramdisk since
> the mmc and nfs based fs needs DMA engine patches. For suspend wakeup,
> I used Sourav's couple of serial wakeup wip patches from the lists.
>
> The following changes since commit 9981cde24de52e5bb9a7cd918d1e54de241f85c9:
>
> Merge branch 'for_3.10/omap5_data_files' of git://git.kernel.org/pub/scm/linux/kernel/git/ssantosh/linux into for_3.10/omap5_pm (2013-03-25 12:29:34 +0530)
>
> are available in the git repository at:
>
>
> git://git.kernel.org/pub/scm/linux/kernel/git/ssantosh/linux.git for_3.10/omap5_pm
>
> for you to fetch changes up to 75bd846d3103da858a208fe07127151903d1f608:
>
> ARM: OMAP5: PM: handle device instance for warm reset (2013-03-25 12:37:44 +0530)
>
> ----------------------------------------------------------------
> Nishanth Menon (1):
> ARM: OMAP5: PM: handle device instance for warm reset
>
> Santosh Shilimkar (17):
> ARM: OMAP4+: PM: Consolidate MPU subsystem PM code for re-use
> ARM: OMAP5: PM: Update CPU context register offset
> ARM: OMAP4+: PM: Consolidate and use OMAP4 PM code for OMAP5
> ARM: OMAP5: PM: Set MPUSS-EMIF clock-domain static dependency
> ARM: OMAP5: PM: Enables ES2 PM mode by default
> ARM: OMAP5: PM: Enable Mercury retention mode on CPUx powerdomains
> ARM: OMAP5: Add init_late() hook to enable pm initialization
> ARM: OMAP5: PM: Add CPU power off in hotplug path
> ARM: OMAP4+: PM: Restore CPU power state to ON with clockdomain force
> wakeup method
> ARM: OMAP5: PM: Add MPU Open Switch Retention support
> ARM: OMAP5: PM: Add L2 memory power down support
> ARM: OMAP4: CPUidle: Avoid double idle driver registration
> ARM: OMAP: CPUidle: Unregister drivere on device registration failure
> ARM: OMAP4: CPUidle: Make C-state description field more precise
> ARM: OMAP4+: CPUidle: Consolidate idle driver for OMAP5 support
> ARM: OMAP4+: CPUidle: Deprecate use of
> omap4_mpuss_read_prev_context_state()
> ARM: OMAP4+: CPUidle: Add OMAP5 idle driver support
>
> arch/arm/mach-omap2/Kconfig | 1 +
> arch/arm/mach-omap2/Makefile | 12 +-
> arch/arm/mach-omap2/board-generic.c | 1 +
> arch/arm/mach-omap2/common.h | 8 +-
> arch/arm/mach-omap2/cpuidle34xx.c | 6 +-
> .../{cpuidle44xx.c => cpuidle_omap4plus.c} | 151 ++++++++++++++++---
> arch/arm/mach-omap2/io.c | 8 +
> arch/arm/mach-omap2/omap-mpuss-lowpower.c | 155 +++++++++++++++-----
> arch/arm/mach-omap2/omap-secure.h | 9 ++
> arch/arm/mach-omap2/omap-smp.c | 12 +-
> arch/arm/mach-omap2/omap-wakeupgen.c | 30 +++-
> arch/arm/mach-omap2/omap-wakeupgen.h | 1 +
> arch/arm/mach-omap2/omap4-sar-layout.h | 2 +
> arch/arm/mach-omap2/{pm44xx.c => pm_omap4plus.c} | 90 ++++++++++--
> arch/arm/mach-omap2/prminst44xx.c | 10 +-
> .../mach-omap2/{sleep44xx.S => sleep_omap4plus.S} | 106 +++++++++++++
> 16 files changed, 512 insertions(+), 90 deletions(-)
> rename arch/arm/mach-omap2/{cpuidle44xx.c => cpuidle_omap4plus.c} (58%)
> rename arch/arm/mach-omap2/{pm44xx.c => pm_omap4plus.c} (74%)
> rename arch/arm/mach-omap2/{sleep44xx.S => sleep_omap4plus.S} (77%)
>
Build tested [1] for omap2plus_defconfig.
For [2], where omap5_pm_branch[1] is merged, testing details are as follows:
* Boot tested on omap4430 sdp, omap5 evm.
* Wakeup from UART after suspend using dt was tested on omap4430sdp and
omap5430 evm.
Note: For the above UART testing, we need to append
"no_console_suspend" in our
bootargs.
Tested-by: Sourav Poddar <sourav.poddar@ti.com>
Thanks,
Sourav
[1] git://git.kernel.org/pub/scm/linux/kernel/git/ssantosh/linux
for_3.10/omap5_pm
[2] git://git.kernel.org/pub/scm/linux/kernel/git/ssantosh/linux.git
testing/3.10/omap5_int
^ permalink raw reply [flat|nested] 128+ messages in thread
* [PATCH v2 00/18] ARM: OMAP5: PM: Add MPUSS suspend and CPUidle support
@ 2013-03-25 12:27 ` Sourav Poddar
0 siblings, 0 replies; 128+ messages in thread
From: Sourav Poddar @ 2013-03-25 12:27 UTC (permalink / raw)
To: linux-arm-kernel
Hi Santosh,
On Monday 25 March 2013 03:34 PM, Santosh Shilimkar wrote:
> Kevin,
>
> Here is the refreshed version(v2) of the OMAP5 PM suspport which was posted
> earlier (March 1st 2013). Patch-set incorporates comments from Nishant
> Menon (Thanks for review NM) and his acked-by tags. I would like to get this
> queued for 3.10 merge window if you are ok with the series.
>
> Series is built on top of my pull requests [1] [2] [3] sent to Tony and your
> 'for_3.10/pm/cleanup' branch. For testing, I have created a branch [4]
> which put together all the needed dependencies, fixes which should make it
> to 3.10 merge window.
>
> Series adds OMAP5 MPUSS power management support for system wide suspend
> and CPUidle. Its heavy re-use from OMAP4 and hence only ~400 odd lines are
> needed to add OMAP5 PM support on top of existing OMAP4 PM support.
>
> OMAP5 adds a mercury retention feature which is an enhancement of
> existing retention feature to reduce the leakage. No change in
> programming model except one time enabling of mercury retention
> during init.
>
> One more notable change in OMAP5 vs OMAP4 devices, CPUx power domains
> support retention state which lets you hit MPUSS and Core retention with
> very low latency C-states.
>
> Tested on OMAP4430 SDP, OMAP4460 Panda, OMAP5430 SDP and OMAP5432 Panda
> devices with suspend and CPUIdle. Rootfs is mounted over ramdisk since
> the mmc and nfs based fs needs DMA engine patches. For suspend wakeup,
> I used Sourav's couple of serial wakeup wip patches from the lists.
>
> The following changes since commit 9981cde24de52e5bb9a7cd918d1e54de241f85c9:
>
> Merge branch 'for_3.10/omap5_data_files' of git://git.kernel.org/pub/scm/linux/kernel/git/ssantosh/linux into for_3.10/omap5_pm (2013-03-25 12:29:34 +0530)
>
> are available in the git repository at:
>
>
> git://git.kernel.org/pub/scm/linux/kernel/git/ssantosh/linux.git for_3.10/omap5_pm
>
> for you to fetch changes up to 75bd846d3103da858a208fe07127151903d1f608:
>
> ARM: OMAP5: PM: handle device instance for warm reset (2013-03-25 12:37:44 +0530)
>
> ----------------------------------------------------------------
> Nishanth Menon (1):
> ARM: OMAP5: PM: handle device instance for warm reset
>
> Santosh Shilimkar (17):
> ARM: OMAP4+: PM: Consolidate MPU subsystem PM code for re-use
> ARM: OMAP5: PM: Update CPU context register offset
> ARM: OMAP4+: PM: Consolidate and use OMAP4 PM code for OMAP5
> ARM: OMAP5: PM: Set MPUSS-EMIF clock-domain static dependency
> ARM: OMAP5: PM: Enables ES2 PM mode by default
> ARM: OMAP5: PM: Enable Mercury retention mode on CPUx powerdomains
> ARM: OMAP5: Add init_late() hook to enable pm initialization
> ARM: OMAP5: PM: Add CPU power off in hotplug path
> ARM: OMAP4+: PM: Restore CPU power state to ON with clockdomain force
> wakeup method
> ARM: OMAP5: PM: Add MPU Open Switch Retention support
> ARM: OMAP5: PM: Add L2 memory power down support
> ARM: OMAP4: CPUidle: Avoid double idle driver registration
> ARM: OMAP: CPUidle: Unregister drivere on device registration failure
> ARM: OMAP4: CPUidle: Make C-state description field more precise
> ARM: OMAP4+: CPUidle: Consolidate idle driver for OMAP5 support
> ARM: OMAP4+: CPUidle: Deprecate use of
> omap4_mpuss_read_prev_context_state()
> ARM: OMAP4+: CPUidle: Add OMAP5 idle driver support
>
> arch/arm/mach-omap2/Kconfig | 1 +
> arch/arm/mach-omap2/Makefile | 12 +-
> arch/arm/mach-omap2/board-generic.c | 1 +
> arch/arm/mach-omap2/common.h | 8 +-
> arch/arm/mach-omap2/cpuidle34xx.c | 6 +-
> .../{cpuidle44xx.c => cpuidle_omap4plus.c} | 151 ++++++++++++++++---
> arch/arm/mach-omap2/io.c | 8 +
> arch/arm/mach-omap2/omap-mpuss-lowpower.c | 155 +++++++++++++++-----
> arch/arm/mach-omap2/omap-secure.h | 9 ++
> arch/arm/mach-omap2/omap-smp.c | 12 +-
> arch/arm/mach-omap2/omap-wakeupgen.c | 30 +++-
> arch/arm/mach-omap2/omap-wakeupgen.h | 1 +
> arch/arm/mach-omap2/omap4-sar-layout.h | 2 +
> arch/arm/mach-omap2/{pm44xx.c => pm_omap4plus.c} | 90 ++++++++++--
> arch/arm/mach-omap2/prminst44xx.c | 10 +-
> .../mach-omap2/{sleep44xx.S => sleep_omap4plus.S} | 106 +++++++++++++
> 16 files changed, 512 insertions(+), 90 deletions(-)
> rename arch/arm/mach-omap2/{cpuidle44xx.c => cpuidle_omap4plus.c} (58%)
> rename arch/arm/mach-omap2/{pm44xx.c => pm_omap4plus.c} (74%)
> rename arch/arm/mach-omap2/{sleep44xx.S => sleep_omap4plus.S} (77%)
>
Build tested [1] for omap2plus_defconfig.
For [2], where omap5_pm_branch[1] is merged, testing details are as follows:
* Boot tested on omap4430 sdp, omap5 evm.
* Wakeup from UART after suspend using dt was tested on omap4430sdp and
omap5430 evm.
Note: For the above UART testing, we need to append
"no_console_suspend" in our
bootargs.
Tested-by: Sourav Poddar <sourav.poddar@ti.com>
Thanks,
Sourav
[1] git://git.kernel.org/pub/scm/linux/kernel/git/ssantosh/linux
for_3.10/omap5_pm
[2] git://git.kernel.org/pub/scm/linux/kernel/git/ssantosh/linux.git
testing/3.10/omap5_int
^ permalink raw reply [flat|nested] 128+ messages in thread
* Re: [PATCH v2 00/18] ARM: OMAP5: PM: Add MPUSS suspend and CPUidle support
2013-03-25 12:27 ` Sourav Poddar
@ 2013-03-25 12:47 ` Rajendra Nayak
-1 siblings, 0 replies; 128+ messages in thread
From: Rajendra Nayak @ 2013-03-25 12:47 UTC (permalink / raw)
To: Sourav Poddar
Cc: Santosh Shilimkar, khilman, nm, tony, linux-omap, linux-arm-kernel
On Monday 25 March 2013 05:57 PM, Sourav Poddar wrote:
> Hi Santosh,
> On Monday 25 March 2013 03:34 PM, Santosh Shilimkar wrote:
>> Kevin,
>>
>> Here is the refreshed version(v2) of the OMAP5 PM suspport which was posted
>> earlier (March 1st 2013). Patch-set incorporates comments from Nishant
>> Menon (Thanks for review NM) and his acked-by tags. I would like to get this
>> queued for 3.10 merge window if you are ok with the series.
>>
>> Series is built on top of my pull requests [1] [2] [3] sent to Tony and your
>> 'for_3.10/pm/cleanup' branch. For testing, I have created a branch [4]
>> which put together all the needed dependencies, fixes which should make it
>> to 3.10 merge window.
>>
>> Series adds OMAP5 MPUSS power management support for system wide suspend
>> and CPUidle. Its heavy re-use from OMAP4 and hence only ~400 odd lines are
>> needed to add OMAP5 PM support on top of existing OMAP4 PM support.
>>
>> OMAP5 adds a mercury retention feature which is an enhancement of
>> existing retention feature to reduce the leakage. No change in
>> programming model except one time enabling of mercury retention
>> during init.
>>
>> One more notable change in OMAP5 vs OMAP4 devices, CPUx power domains
>> support retention state which lets you hit MPUSS and Core retention with
>> very low latency C-states.
>>
>> Tested on OMAP4430 SDP, OMAP4460 Panda, OMAP5430 SDP and OMAP5432 Panda
>> devices with suspend and CPUIdle. Rootfs is mounted over ramdisk since
>> the mmc and nfs based fs needs DMA engine patches. For suspend wakeup,
>> I used Sourav's couple of serial wakeup wip patches from the lists.
>>
>> The following changes since commit 9981cde24de52e5bb9a7cd918d1e54de241f85c9:
>>
>> Merge branch 'for_3.10/omap5_data_files' of git://git.kernel.org/pub/scm/linux/kernel/git/ssantosh/linux into for_3.10/omap5_pm (2013-03-25 12:29:34 +0530)
>>
>> are available in the git repository at:
>>
>>
>> git://git.kernel.org/pub/scm/linux/kernel/git/ssantosh/linux.git for_3.10/omap5_pm
>>
>> for you to fetch changes up to 75bd846d3103da858a208fe07127151903d1f608:
>>
>> ARM: OMAP5: PM: handle device instance for warm reset (2013-03-25 12:37:44 +0530)
>>
>> ----------------------------------------------------------------
>> Nishanth Menon (1):
>> ARM: OMAP5: PM: handle device instance for warm reset
>>
>> Santosh Shilimkar (17):
>> ARM: OMAP4+: PM: Consolidate MPU subsystem PM code for re-use
>> ARM: OMAP5: PM: Update CPU context register offset
>> ARM: OMAP4+: PM: Consolidate and use OMAP4 PM code for OMAP5
>> ARM: OMAP5: PM: Set MPUSS-EMIF clock-domain static dependency
>> ARM: OMAP5: PM: Enables ES2 PM mode by default
>> ARM: OMAP5: PM: Enable Mercury retention mode on CPUx powerdomains
>> ARM: OMAP5: Add init_late() hook to enable pm initialization
>> ARM: OMAP5: PM: Add CPU power off in hotplug path
>> ARM: OMAP4+: PM: Restore CPU power state to ON with clockdomain force
>> wakeup method
>> ARM: OMAP5: PM: Add MPU Open Switch Retention support
>> ARM: OMAP5: PM: Add L2 memory power down support
>> ARM: OMAP4: CPUidle: Avoid double idle driver registration
>> ARM: OMAP: CPUidle: Unregister drivere on device registration failure
>> ARM: OMAP4: CPUidle: Make C-state description field more precise
>> ARM: OMAP4+: CPUidle: Consolidate idle driver for OMAP5 support
>> ARM: OMAP4+: CPUidle: Deprecate use of
>> omap4_mpuss_read_prev_context_state()
>> ARM: OMAP4+: CPUidle: Add OMAP5 idle driver support
>>
>> arch/arm/mach-omap2/Kconfig | 1 +
>> arch/arm/mach-omap2/Makefile | 12 +-
>> arch/arm/mach-omap2/board-generic.c | 1 +
>> arch/arm/mach-omap2/common.h | 8 +-
>> arch/arm/mach-omap2/cpuidle34xx.c | 6 +-
>> .../{cpuidle44xx.c => cpuidle_omap4plus.c} | 151 ++++++++++++++++---
>> arch/arm/mach-omap2/io.c | 8 +
>> arch/arm/mach-omap2/omap-mpuss-lowpower.c | 155 +++++++++++++++-----
>> arch/arm/mach-omap2/omap-secure.h | 9 ++
>> arch/arm/mach-omap2/omap-smp.c | 12 +-
>> arch/arm/mach-omap2/omap-wakeupgen.c | 30 +++-
>> arch/arm/mach-omap2/omap-wakeupgen.h | 1 +
>> arch/arm/mach-omap2/omap4-sar-layout.h | 2 +
>> arch/arm/mach-omap2/{pm44xx.c => pm_omap4plus.c} | 90 ++++++++++--
>> arch/arm/mach-omap2/prminst44xx.c | 10 +-
>> .../mach-omap2/{sleep44xx.S => sleep_omap4plus.S} | 106 +++++++++++++
>> 16 files changed, 512 insertions(+), 90 deletions(-)
>> rename arch/arm/mach-omap2/{cpuidle44xx.c => cpuidle_omap4plus.c} (58%)
>> rename arch/arm/mach-omap2/{pm44xx.c => pm_omap4plus.c} (74%)
>> rename arch/arm/mach-omap2/{sleep44xx.S => sleep_omap4plus.S} (77%)
>>
> Build tested [1] for omap2plus_defconfig.
>
> For [2], where omap5_pm_branch[1] is merged, testing details are as follows:
> * Boot tested on omap4430 sdp, omap5 evm.
>
> * Wakeup from UART after suspend using dt was tested on omap4430sdp and
> omap5430 evm.
> Note: For the above UART testing, we need to append "no_console_suspend" in our
> bootargs.
Is this for both omap4 and omap5 that you need 'no_console_suspend'?
>
> Tested-by: Sourav Poddar <sourav.poddar@ti.com>
>
> Thanks,
> Sourav
>
> [1] git://git.kernel.org/pub/scm/linux/kernel/git/ssantosh/linux for_3.10/omap5_pm
> [2] git://git.kernel.org/pub/scm/linux/kernel/git/ssantosh/linux.git testing/3.10/omap5_int
>
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 128+ messages in thread
* [PATCH v2 00/18] ARM: OMAP5: PM: Add MPUSS suspend and CPUidle support
@ 2013-03-25 12:47 ` Rajendra Nayak
0 siblings, 0 replies; 128+ messages in thread
From: Rajendra Nayak @ 2013-03-25 12:47 UTC (permalink / raw)
To: linux-arm-kernel
On Monday 25 March 2013 05:57 PM, Sourav Poddar wrote:
> Hi Santosh,
> On Monday 25 March 2013 03:34 PM, Santosh Shilimkar wrote:
>> Kevin,
>>
>> Here is the refreshed version(v2) of the OMAP5 PM suspport which was posted
>> earlier (March 1st 2013). Patch-set incorporates comments from Nishant
>> Menon (Thanks for review NM) and his acked-by tags. I would like to get this
>> queued for 3.10 merge window if you are ok with the series.
>>
>> Series is built on top of my pull requests [1] [2] [3] sent to Tony and your
>> 'for_3.10/pm/cleanup' branch. For testing, I have created a branch [4]
>> which put together all the needed dependencies, fixes which should make it
>> to 3.10 merge window.
>>
>> Series adds OMAP5 MPUSS power management support for system wide suspend
>> and CPUidle. Its heavy re-use from OMAP4 and hence only ~400 odd lines are
>> needed to add OMAP5 PM support on top of existing OMAP4 PM support.
>>
>> OMAP5 adds a mercury retention feature which is an enhancement of
>> existing retention feature to reduce the leakage. No change in
>> programming model except one time enabling of mercury retention
>> during init.
>>
>> One more notable change in OMAP5 vs OMAP4 devices, CPUx power domains
>> support retention state which lets you hit MPUSS and Core retention with
>> very low latency C-states.
>>
>> Tested on OMAP4430 SDP, OMAP4460 Panda, OMAP5430 SDP and OMAP5432 Panda
>> devices with suspend and CPUIdle. Rootfs is mounted over ramdisk since
>> the mmc and nfs based fs needs DMA engine patches. For suspend wakeup,
>> I used Sourav's couple of serial wakeup wip patches from the lists.
>>
>> The following changes since commit 9981cde24de52e5bb9a7cd918d1e54de241f85c9:
>>
>> Merge branch 'for_3.10/omap5_data_files' of git://git.kernel.org/pub/scm/linux/kernel/git/ssantosh/linux into for_3.10/omap5_pm (2013-03-25 12:29:34 +0530)
>>
>> are available in the git repository at:
>>
>>
>> git://git.kernel.org/pub/scm/linux/kernel/git/ssantosh/linux.git for_3.10/omap5_pm
>>
>> for you to fetch changes up to 75bd846d3103da858a208fe07127151903d1f608:
>>
>> ARM: OMAP5: PM: handle device instance for warm reset (2013-03-25 12:37:44 +0530)
>>
>> ----------------------------------------------------------------
>> Nishanth Menon (1):
>> ARM: OMAP5: PM: handle device instance for warm reset
>>
>> Santosh Shilimkar (17):
>> ARM: OMAP4+: PM: Consolidate MPU subsystem PM code for re-use
>> ARM: OMAP5: PM: Update CPU context register offset
>> ARM: OMAP4+: PM: Consolidate and use OMAP4 PM code for OMAP5
>> ARM: OMAP5: PM: Set MPUSS-EMIF clock-domain static dependency
>> ARM: OMAP5: PM: Enables ES2 PM mode by default
>> ARM: OMAP5: PM: Enable Mercury retention mode on CPUx powerdomains
>> ARM: OMAP5: Add init_late() hook to enable pm initialization
>> ARM: OMAP5: PM: Add CPU power off in hotplug path
>> ARM: OMAP4+: PM: Restore CPU power state to ON with clockdomain force
>> wakeup method
>> ARM: OMAP5: PM: Add MPU Open Switch Retention support
>> ARM: OMAP5: PM: Add L2 memory power down support
>> ARM: OMAP4: CPUidle: Avoid double idle driver registration
>> ARM: OMAP: CPUidle: Unregister drivere on device registration failure
>> ARM: OMAP4: CPUidle: Make C-state description field more precise
>> ARM: OMAP4+: CPUidle: Consolidate idle driver for OMAP5 support
>> ARM: OMAP4+: CPUidle: Deprecate use of
>> omap4_mpuss_read_prev_context_state()
>> ARM: OMAP4+: CPUidle: Add OMAP5 idle driver support
>>
>> arch/arm/mach-omap2/Kconfig | 1 +
>> arch/arm/mach-omap2/Makefile | 12 +-
>> arch/arm/mach-omap2/board-generic.c | 1 +
>> arch/arm/mach-omap2/common.h | 8 +-
>> arch/arm/mach-omap2/cpuidle34xx.c | 6 +-
>> .../{cpuidle44xx.c => cpuidle_omap4plus.c} | 151 ++++++++++++++++---
>> arch/arm/mach-omap2/io.c | 8 +
>> arch/arm/mach-omap2/omap-mpuss-lowpower.c | 155 +++++++++++++++-----
>> arch/arm/mach-omap2/omap-secure.h | 9 ++
>> arch/arm/mach-omap2/omap-smp.c | 12 +-
>> arch/arm/mach-omap2/omap-wakeupgen.c | 30 +++-
>> arch/arm/mach-omap2/omap-wakeupgen.h | 1 +
>> arch/arm/mach-omap2/omap4-sar-layout.h | 2 +
>> arch/arm/mach-omap2/{pm44xx.c => pm_omap4plus.c} | 90 ++++++++++--
>> arch/arm/mach-omap2/prminst44xx.c | 10 +-
>> .../mach-omap2/{sleep44xx.S => sleep_omap4plus.S} | 106 +++++++++++++
>> 16 files changed, 512 insertions(+), 90 deletions(-)
>> rename arch/arm/mach-omap2/{cpuidle44xx.c => cpuidle_omap4plus.c} (58%)
>> rename arch/arm/mach-omap2/{pm44xx.c => pm_omap4plus.c} (74%)
>> rename arch/arm/mach-omap2/{sleep44xx.S => sleep_omap4plus.S} (77%)
>>
> Build tested [1] for omap2plus_defconfig.
>
> For [2], where omap5_pm_branch[1] is merged, testing details are as follows:
> * Boot tested on omap4430 sdp, omap5 evm.
>
> * Wakeup from UART after suspend using dt was tested on omap4430sdp and
> omap5430 evm.
> Note: For the above UART testing, we need to append "no_console_suspend" in our
> bootargs.
Is this for both omap4 and omap5 that you need 'no_console_suspend'?
>
> Tested-by: Sourav Poddar <sourav.poddar@ti.com>
>
> Thanks,
> Sourav
>
> [1] git://git.kernel.org/pub/scm/linux/kernel/git/ssantosh/linux for_3.10/omap5_pm
> [2] git://git.kernel.org/pub/scm/linux/kernel/git/ssantosh/linux.git testing/3.10/omap5_int
>
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 128+ messages in thread
* Re: [PATCH v2 00/18] ARM: OMAP5: PM: Add MPUSS suspend and CPUidle support
2013-03-25 12:47 ` Rajendra Nayak
@ 2013-03-25 13:00 ` Sourav Poddar
-1 siblings, 0 replies; 128+ messages in thread
From: Sourav Poddar @ 2013-03-25 13:00 UTC (permalink / raw)
To: Rajendra Nayak
Cc: Santosh Shilimkar, khilman, nm, tony, linux-omap, linux-arm-kernel
Hi Rajendra,
On Monday 25 March 2013 06:17 PM, Rajendra Nayak wrote:
> On Monday 25 March 2013 05:57 PM, Sourav Poddar wrote:
>> Hi Santosh,
>> On Monday 25 March 2013 03:34 PM, Santosh Shilimkar wrote:
>>> Kevin,
>>>
>>> Here is the refreshed version(v2) of the OMAP5 PM suspport which was posted
>>> earlier (March 1st 2013). Patch-set incorporates comments from Nishant
>>> Menon (Thanks for review NM) and his acked-by tags. I would like to get this
>>> queued for 3.10 merge window if you are ok with the series.
>>>
>>> Series is built on top of my pull requests [1] [2] [3] sent to Tony and your
>>> 'for_3.10/pm/cleanup' branch. For testing, I have created a branch [4]
>>> which put together all the needed dependencies, fixes which should make it
>>> to 3.10 merge window.
>>>
>>> Series adds OMAP5 MPUSS power management support for system wide suspend
>>> and CPUidle. Its heavy re-use from OMAP4 and hence only ~400 odd lines are
>>> needed to add OMAP5 PM support on top of existing OMAP4 PM support.
>>>
>>> OMAP5 adds a mercury retention feature which is an enhancement of
>>> existing retention feature to reduce the leakage. No change in
>>> programming model except one time enabling of mercury retention
>>> during init.
>>>
>>> One more notable change in OMAP5 vs OMAP4 devices, CPUx power domains
>>> support retention state which lets you hit MPUSS and Core retention with
>>> very low latency C-states.
>>>
>>> Tested on OMAP4430 SDP, OMAP4460 Panda, OMAP5430 SDP and OMAP5432 Panda
>>> devices with suspend and CPUIdle. Rootfs is mounted over ramdisk since
>>> the mmc and nfs based fs needs DMA engine patches. For suspend wakeup,
>>> I used Sourav's couple of serial wakeup wip patches from the lists.
>>>
>>> The following changes since commit 9981cde24de52e5bb9a7cd918d1e54de241f85c9:
>>>
>>> Merge branch 'for_3.10/omap5_data_files' of git://git.kernel.org/pub/scm/linux/kernel/git/ssantosh/linux into for_3.10/omap5_pm (2013-03-25 12:29:34 +0530)
>>>
>>> are available in the git repository at:
>>>
>>>
>>> git://git.kernel.org/pub/scm/linux/kernel/git/ssantosh/linux.git for_3.10/omap5_pm
>>>
>>> for you to fetch changes up to 75bd846d3103da858a208fe07127151903d1f608:
>>>
>>> ARM: OMAP5: PM: handle device instance for warm reset (2013-03-25 12:37:44 +0530)
>>>
>>> ----------------------------------------------------------------
>>> Nishanth Menon (1):
>>> ARM: OMAP5: PM: handle device instance for warm reset
>>>
>>> Santosh Shilimkar (17):
>>> ARM: OMAP4+: PM: Consolidate MPU subsystem PM code for re-use
>>> ARM: OMAP5: PM: Update CPU context register offset
>>> ARM: OMAP4+: PM: Consolidate and use OMAP4 PM code for OMAP5
>>> ARM: OMAP5: PM: Set MPUSS-EMIF clock-domain static dependency
>>> ARM: OMAP5: PM: Enables ES2 PM mode by default
>>> ARM: OMAP5: PM: Enable Mercury retention mode on CPUx powerdomains
>>> ARM: OMAP5: Add init_late() hook to enable pm initialization
>>> ARM: OMAP5: PM: Add CPU power off in hotplug path
>>> ARM: OMAP4+: PM: Restore CPU power state to ON with clockdomain force
>>> wakeup method
>>> ARM: OMAP5: PM: Add MPU Open Switch Retention support
>>> ARM: OMAP5: PM: Add L2 memory power down support
>>> ARM: OMAP4: CPUidle: Avoid double idle driver registration
>>> ARM: OMAP: CPUidle: Unregister drivere on device registration failure
>>> ARM: OMAP4: CPUidle: Make C-state description field more precise
>>> ARM: OMAP4+: CPUidle: Consolidate idle driver for OMAP5 support
>>> ARM: OMAP4+: CPUidle: Deprecate use of
>>> omap4_mpuss_read_prev_context_state()
>>> ARM: OMAP4+: CPUidle: Add OMAP5 idle driver support
>>>
>>> arch/arm/mach-omap2/Kconfig | 1 +
>>> arch/arm/mach-omap2/Makefile | 12 +-
>>> arch/arm/mach-omap2/board-generic.c | 1 +
>>> arch/arm/mach-omap2/common.h | 8 +-
>>> arch/arm/mach-omap2/cpuidle34xx.c | 6 +-
>>> .../{cpuidle44xx.c => cpuidle_omap4plus.c} | 151 ++++++++++++++++---
>>> arch/arm/mach-omap2/io.c | 8 +
>>> arch/arm/mach-omap2/omap-mpuss-lowpower.c | 155 +++++++++++++++-----
>>> arch/arm/mach-omap2/omap-secure.h | 9 ++
>>> arch/arm/mach-omap2/omap-smp.c | 12 +-
>>> arch/arm/mach-omap2/omap-wakeupgen.c | 30 +++-
>>> arch/arm/mach-omap2/omap-wakeupgen.h | 1 +
>>> arch/arm/mach-omap2/omap4-sar-layout.h | 2 +
>>> arch/arm/mach-omap2/{pm44xx.c => pm_omap4plus.c} | 90 ++++++++++--
>>> arch/arm/mach-omap2/prminst44xx.c | 10 +-
>>> .../mach-omap2/{sleep44xx.S => sleep_omap4plus.S} | 106 +++++++++++++
>>> 16 files changed, 512 insertions(+), 90 deletions(-)
>>> rename arch/arm/mach-omap2/{cpuidle44xx.c => cpuidle_omap4plus.c} (58%)
>>> rename arch/arm/mach-omap2/{pm44xx.c => pm_omap4plus.c} (74%)
>>> rename arch/arm/mach-omap2/{sleep44xx.S => sleep_omap4plus.S} (77%)
>>>
>> Build tested [1] for omap2plus_defconfig.
>>
>> For [2], where omap5_pm_branch[1] is merged, testing details are as follows:
>> * Boot tested on omap4430 sdp, omap5 evm.
>>
>> * Wakeup from UART after suspend using dt was tested on omap4430sdp and
>> omap5430 evm.
>> Note: For the above UART testing, we need to append "no_console_suspend" in our
>> bootargs.
> Is this for both omap4 and omap5 that you need 'no_console_suspend'?
>
For omap5, using "no_console_suspend" is mandatory as of now.
For omap4 dt case,
We can also do without "no_console_suspend".
But the tested branch[2] contains a patch which fixes wakeup from uart
on both
omap4/5 with dt, while using "no_console_suspend" in the bootargs..
~Sourav
>> Tested-by: Sourav Poddar<sourav.poddar@ti.com>
>>
>> Thanks,
>> Sourav
>>
>> [1] git://git.kernel.org/pub/scm/linux/kernel/git/ssantosh/linux for_3.10/omap5_pm
>> [2] git://git.kernel.org/pub/scm/linux/kernel/git/ssantosh/linux.git testing/3.10/omap5_int
>>
>>
>>
>> _______________________________________________
>> linux-arm-kernel mailing list
>> linux-arm-kernel@lists.infradead.org
>> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 128+ messages in thread
* [PATCH v2 00/18] ARM: OMAP5: PM: Add MPUSS suspend and CPUidle support
@ 2013-03-25 13:00 ` Sourav Poddar
0 siblings, 0 replies; 128+ messages in thread
From: Sourav Poddar @ 2013-03-25 13:00 UTC (permalink / raw)
To: linux-arm-kernel
Hi Rajendra,
On Monday 25 March 2013 06:17 PM, Rajendra Nayak wrote:
> On Monday 25 March 2013 05:57 PM, Sourav Poddar wrote:
>> Hi Santosh,
>> On Monday 25 March 2013 03:34 PM, Santosh Shilimkar wrote:
>>> Kevin,
>>>
>>> Here is the refreshed version(v2) of the OMAP5 PM suspport which was posted
>>> earlier (March 1st 2013). Patch-set incorporates comments from Nishant
>>> Menon (Thanks for review NM) and his acked-by tags. I would like to get this
>>> queued for 3.10 merge window if you are ok with the series.
>>>
>>> Series is built on top of my pull requests [1] [2] [3] sent to Tony and your
>>> 'for_3.10/pm/cleanup' branch. For testing, I have created a branch [4]
>>> which put together all the needed dependencies, fixes which should make it
>>> to 3.10 merge window.
>>>
>>> Series adds OMAP5 MPUSS power management support for system wide suspend
>>> and CPUidle. Its heavy re-use from OMAP4 and hence only ~400 odd lines are
>>> needed to add OMAP5 PM support on top of existing OMAP4 PM support.
>>>
>>> OMAP5 adds a mercury retention feature which is an enhancement of
>>> existing retention feature to reduce the leakage. No change in
>>> programming model except one time enabling of mercury retention
>>> during init.
>>>
>>> One more notable change in OMAP5 vs OMAP4 devices, CPUx power domains
>>> support retention state which lets you hit MPUSS and Core retention with
>>> very low latency C-states.
>>>
>>> Tested on OMAP4430 SDP, OMAP4460 Panda, OMAP5430 SDP and OMAP5432 Panda
>>> devices with suspend and CPUIdle. Rootfs is mounted over ramdisk since
>>> the mmc and nfs based fs needs DMA engine patches. For suspend wakeup,
>>> I used Sourav's couple of serial wakeup wip patches from the lists.
>>>
>>> The following changes since commit 9981cde24de52e5bb9a7cd918d1e54de241f85c9:
>>>
>>> Merge branch 'for_3.10/omap5_data_files' of git://git.kernel.org/pub/scm/linux/kernel/git/ssantosh/linux into for_3.10/omap5_pm (2013-03-25 12:29:34 +0530)
>>>
>>> are available in the git repository at:
>>>
>>>
>>> git://git.kernel.org/pub/scm/linux/kernel/git/ssantosh/linux.git for_3.10/omap5_pm
>>>
>>> for you to fetch changes up to 75bd846d3103da858a208fe07127151903d1f608:
>>>
>>> ARM: OMAP5: PM: handle device instance for warm reset (2013-03-25 12:37:44 +0530)
>>>
>>> ----------------------------------------------------------------
>>> Nishanth Menon (1):
>>> ARM: OMAP5: PM: handle device instance for warm reset
>>>
>>> Santosh Shilimkar (17):
>>> ARM: OMAP4+: PM: Consolidate MPU subsystem PM code for re-use
>>> ARM: OMAP5: PM: Update CPU context register offset
>>> ARM: OMAP4+: PM: Consolidate and use OMAP4 PM code for OMAP5
>>> ARM: OMAP5: PM: Set MPUSS-EMIF clock-domain static dependency
>>> ARM: OMAP5: PM: Enables ES2 PM mode by default
>>> ARM: OMAP5: PM: Enable Mercury retention mode on CPUx powerdomains
>>> ARM: OMAP5: Add init_late() hook to enable pm initialization
>>> ARM: OMAP5: PM: Add CPU power off in hotplug path
>>> ARM: OMAP4+: PM: Restore CPU power state to ON with clockdomain force
>>> wakeup method
>>> ARM: OMAP5: PM: Add MPU Open Switch Retention support
>>> ARM: OMAP5: PM: Add L2 memory power down support
>>> ARM: OMAP4: CPUidle: Avoid double idle driver registration
>>> ARM: OMAP: CPUidle: Unregister drivere on device registration failure
>>> ARM: OMAP4: CPUidle: Make C-state description field more precise
>>> ARM: OMAP4+: CPUidle: Consolidate idle driver for OMAP5 support
>>> ARM: OMAP4+: CPUidle: Deprecate use of
>>> omap4_mpuss_read_prev_context_state()
>>> ARM: OMAP4+: CPUidle: Add OMAP5 idle driver support
>>>
>>> arch/arm/mach-omap2/Kconfig | 1 +
>>> arch/arm/mach-omap2/Makefile | 12 +-
>>> arch/arm/mach-omap2/board-generic.c | 1 +
>>> arch/arm/mach-omap2/common.h | 8 +-
>>> arch/arm/mach-omap2/cpuidle34xx.c | 6 +-
>>> .../{cpuidle44xx.c => cpuidle_omap4plus.c} | 151 ++++++++++++++++---
>>> arch/arm/mach-omap2/io.c | 8 +
>>> arch/arm/mach-omap2/omap-mpuss-lowpower.c | 155 +++++++++++++++-----
>>> arch/arm/mach-omap2/omap-secure.h | 9 ++
>>> arch/arm/mach-omap2/omap-smp.c | 12 +-
>>> arch/arm/mach-omap2/omap-wakeupgen.c | 30 +++-
>>> arch/arm/mach-omap2/omap-wakeupgen.h | 1 +
>>> arch/arm/mach-omap2/omap4-sar-layout.h | 2 +
>>> arch/arm/mach-omap2/{pm44xx.c => pm_omap4plus.c} | 90 ++++++++++--
>>> arch/arm/mach-omap2/prminst44xx.c | 10 +-
>>> .../mach-omap2/{sleep44xx.S => sleep_omap4plus.S} | 106 +++++++++++++
>>> 16 files changed, 512 insertions(+), 90 deletions(-)
>>> rename arch/arm/mach-omap2/{cpuidle44xx.c => cpuidle_omap4plus.c} (58%)
>>> rename arch/arm/mach-omap2/{pm44xx.c => pm_omap4plus.c} (74%)
>>> rename arch/arm/mach-omap2/{sleep44xx.S => sleep_omap4plus.S} (77%)
>>>
>> Build tested [1] for omap2plus_defconfig.
>>
>> For [2], where omap5_pm_branch[1] is merged, testing details are as follows:
>> * Boot tested on omap4430 sdp, omap5 evm.
>>
>> * Wakeup from UART after suspend using dt was tested on omap4430sdp and
>> omap5430 evm.
>> Note: For the above UART testing, we need to append "no_console_suspend" in our
>> bootargs.
> Is this for both omap4 and omap5 that you need 'no_console_suspend'?
>
For omap5, using "no_console_suspend" is mandatory as of now.
For omap4 dt case,
We can also do without "no_console_suspend".
But the tested branch[2] contains a patch which fixes wakeup from uart
on both
omap4/5 with dt, while using "no_console_suspend" in the bootargs..
~Sourav
>> Tested-by: Sourav Poddar<sourav.poddar@ti.com>
>>
>> Thanks,
>> Sourav
>>
>> [1] git://git.kernel.org/pub/scm/linux/kernel/git/ssantosh/linux for_3.10/omap5_pm
>> [2] git://git.kernel.org/pub/scm/linux/kernel/git/ssantosh/linux.git testing/3.10/omap5_int
>>
>>
>>
>> _______________________________________________
>> linux-arm-kernel mailing list
>> linux-arm-kernel at lists.infradead.org
>> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 128+ messages in thread
* Re: [PATCH v2 01/18] ARM: OMAP4+: PM: Consolidate MPU subsystem PM code for re-use
2013-03-25 10:04 ` Santosh Shilimkar
@ 2013-04-03 19:44 ` Kevin Hilman
-1 siblings, 0 replies; 128+ messages in thread
From: Kevin Hilman @ 2013-04-03 19:44 UTC (permalink / raw)
To: Santosh Shilimkar; +Cc: nm, tony, linux-omap, linux-arm-kernel
Hi Santosh,
Santosh Shilimkar <santosh.shilimkar@ti.com> writes:
> OMAP5 and future OMAP based SOCs has backward compatible MPUSS
> IP block with OMAP4. It's programming model is mostly similar.
> Hence consolidate the OMAP MPUSS code so that it can be re-used
> on OMAP5 and future SOCs.
>
> No functional change.
>
> Acked-by: Nishanth Menon <nm@ti.com>
> Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
> ---
> arch/arm/mach-omap2/omap-mpuss-lowpower.c | 65 ++++++++++++++++++++++++-----
> 1 file changed, 54 insertions(+), 11 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/omap-mpuss-lowpower.c b/arch/arm/mach-omap2/omap-mpuss-lowpower.c
> index d650f91..d9e4843 100644
> --- a/arch/arm/mach-omap2/omap-mpuss-lowpower.c
> +++ b/arch/arm/mach-omap2/omap-mpuss-lowpower.c
> @@ -71,10 +71,46 @@ struct omap4_cpu_pm_info {
> void (*secondary_startup)(void);
> };
>
> +/**
> + * struct cpu_pm_ops - CPU pm operations
> + * @finish_suspend: CPU suspend finisher function pointer
> + * @resume: CPU resume function pointer
> + * @scu_prepare: CPU Snoop Control program function pointer
> + *
> + * Structure holds functions pointer for CPU low power operations like
> + * suspend, resume and scu programming.
> + */
> +struct cpu_pm_ops {
> + int (*finish_suspend)(unsigned long cpu_state);
> + void (*resume)(void);
> + void (*scu_prepare)(unsigned int cpu_id, unsigned int cpu_state);
> +};
> +
> +extern int omap4_finish_suspend(unsigned long cpu_state);
> +extern void omap4_cpu_resume(void);
checkpatch should've yelled at you for adding externs to .c files.
Also, aren't these already defined in common.h anyways?
Otherwise, patch looks fine.
Kevin
> static DEFINE_PER_CPU(struct omap4_cpu_pm_info, omap4_pm_info);
> static struct powerdomain *mpuss_pd;
> static void __iomem *sar_base;
>
> +static int default_finish_suspend(unsigned long cpu_state)
> +{
> + omap_do_wfi();
> + return 0;
> +}
> +
> +static void dummy_cpu_resume(void)
> +{}
> +
> +static void dummy_scu_prepare(unsigned int cpu_id, unsigned int cpu_state)
> +{}
> +
> +struct cpu_pm_ops omap_pm_ops = {
> + .finish_suspend = default_finish_suspend,
> + .resume = dummy_cpu_resume,
> + .scu_prepare = dummy_scu_prepare,
> +};
> +
> /*
> * Program the wakeup routine address for the CPU0 and CPU1
> * used for OFF or DORMANT wakeup.
> @@ -172,11 +208,12 @@ static void save_l2x0_context(void)
> {
> u32 val;
> void __iomem *l2x0_base = omap4_get_l2cache_base();
> -
> - val = __raw_readl(l2x0_base + L2X0_AUX_CTRL);
> - __raw_writel(val, sar_base + L2X0_AUXCTRL_OFFSET);
> - val = __raw_readl(l2x0_base + L2X0_PREFETCH_CTRL);
> - __raw_writel(val, sar_base + L2X0_PREFETCH_CTRL_OFFSET);
> + if (l2x0_base) {
> + val = __raw_readl(l2x0_base + L2X0_AUX_CTRL);
> + __raw_writel(val, sar_base + L2X0_AUXCTRL_OFFSET);
> + val = __raw_readl(l2x0_base + L2X0_PREFETCH_CTRL);
> + __raw_writel(val, sar_base + L2X0_PREFETCH_CTRL_OFFSET);
> + }
> }
> #else
> static void save_l2x0_context(void)
> @@ -239,17 +276,17 @@ int omap4_enter_lowpower(unsigned int cpu, unsigned int power_state)
>
> cpu_clear_prev_logic_pwrst(cpu);
> pwrdm_set_next_pwrst(pm_info->pwrdm, power_state);
> - set_cpu_wakeup_addr(cpu, virt_to_phys(omap4_cpu_resume));
> - scu_pwrst_prepare(cpu, power_state);
> + set_cpu_wakeup_addr(cpu, virt_to_phys(omap_pm_ops.resume));
> + omap_pm_ops.scu_prepare(cpu, power_state);
> l2x0_pwrst_prepare(cpu, save_state);
>
> /*
> * Call low level function with targeted low power state.
> */
> if (save_state)
> - cpu_suspend(save_state, omap4_finish_suspend);
> + cpu_suspend(save_state, omap_pm_ops.finish_suspend);
> else
> - omap4_finish_suspend(save_state);
> + omap_pm_ops.finish_suspend(save_state);
>
> /*
> * Restore the CPUx power state to ON otherwise CPUx
> @@ -285,14 +322,14 @@ int __cpuinit omap4_hotplug_cpu(unsigned int cpu, unsigned int power_state)
> pwrdm_clear_all_prev_pwrst(pm_info->pwrdm);
> pwrdm_set_next_pwrst(pm_info->pwrdm, power_state);
> set_cpu_wakeup_addr(cpu, virt_to_phys(pm_info->secondary_startup));
> - scu_pwrst_prepare(cpu, power_state);
> + omap_pm_ops.scu_prepare(cpu, power_state);
>
> /*
> * CPU never retuns back if targeted power state is OFF mode.
> * CPU ONLINE follows normal CPU ONLINE ptah via
> * omap_secondary_startup().
> */
> - omap4_finish_suspend(cpu_state);
> + omap_pm_ops.finish_suspend(cpu_state);
>
> pwrdm_set_next_pwrst(pm_info->pwrdm, PWRDM_POWER_ON);
> return 0;
> @@ -369,6 +406,12 @@ int __init omap4_mpuss_init(void)
>
> save_l2x0_context();
>
> + if (cpu_is_omap44xx()) {
> + omap_pm_ops.finish_suspend = omap4_finish_suspend;
> + omap_pm_ops.resume = omap4_cpu_resume;
> + omap_pm_ops.scu_prepare = scu_pwrst_prepare;
> + }
> +
> return 0;
> }
^ permalink raw reply [flat|nested] 128+ messages in thread
* [PATCH v2 01/18] ARM: OMAP4+: PM: Consolidate MPU subsystem PM code for re-use
@ 2013-04-03 19:44 ` Kevin Hilman
0 siblings, 0 replies; 128+ messages in thread
From: Kevin Hilman @ 2013-04-03 19:44 UTC (permalink / raw)
To: linux-arm-kernel
Hi Santosh,
Santosh Shilimkar <santosh.shilimkar@ti.com> writes:
> OMAP5 and future OMAP based SOCs has backward compatible MPUSS
> IP block with OMAP4. It's programming model is mostly similar.
> Hence consolidate the OMAP MPUSS code so that it can be re-used
> on OMAP5 and future SOCs.
>
> No functional change.
>
> Acked-by: Nishanth Menon <nm@ti.com>
> Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
> ---
> arch/arm/mach-omap2/omap-mpuss-lowpower.c | 65 ++++++++++++++++++++++++-----
> 1 file changed, 54 insertions(+), 11 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/omap-mpuss-lowpower.c b/arch/arm/mach-omap2/omap-mpuss-lowpower.c
> index d650f91..d9e4843 100644
> --- a/arch/arm/mach-omap2/omap-mpuss-lowpower.c
> +++ b/arch/arm/mach-omap2/omap-mpuss-lowpower.c
> @@ -71,10 +71,46 @@ struct omap4_cpu_pm_info {
> void (*secondary_startup)(void);
> };
>
> +/**
> + * struct cpu_pm_ops - CPU pm operations
> + * @finish_suspend: CPU suspend finisher function pointer
> + * @resume: CPU resume function pointer
> + * @scu_prepare: CPU Snoop Control program function pointer
> + *
> + * Structure holds functions pointer for CPU low power operations like
> + * suspend, resume and scu programming.
> + */
> +struct cpu_pm_ops {
> + int (*finish_suspend)(unsigned long cpu_state);
> + void (*resume)(void);
> + void (*scu_prepare)(unsigned int cpu_id, unsigned int cpu_state);
> +};
> +
> +extern int omap4_finish_suspend(unsigned long cpu_state);
> +extern void omap4_cpu_resume(void);
checkpatch should've yelled at you for adding externs to .c files.
Also, aren't these already defined in common.h anyways?
Otherwise, patch looks fine.
Kevin
> static DEFINE_PER_CPU(struct omap4_cpu_pm_info, omap4_pm_info);
> static struct powerdomain *mpuss_pd;
> static void __iomem *sar_base;
>
> +static int default_finish_suspend(unsigned long cpu_state)
> +{
> + omap_do_wfi();
> + return 0;
> +}
> +
> +static void dummy_cpu_resume(void)
> +{}
> +
> +static void dummy_scu_prepare(unsigned int cpu_id, unsigned int cpu_state)
> +{}
> +
> +struct cpu_pm_ops omap_pm_ops = {
> + .finish_suspend = default_finish_suspend,
> + .resume = dummy_cpu_resume,
> + .scu_prepare = dummy_scu_prepare,
> +};
> +
> /*
> * Program the wakeup routine address for the CPU0 and CPU1
> * used for OFF or DORMANT wakeup.
> @@ -172,11 +208,12 @@ static void save_l2x0_context(void)
> {
> u32 val;
> void __iomem *l2x0_base = omap4_get_l2cache_base();
> -
> - val = __raw_readl(l2x0_base + L2X0_AUX_CTRL);
> - __raw_writel(val, sar_base + L2X0_AUXCTRL_OFFSET);
> - val = __raw_readl(l2x0_base + L2X0_PREFETCH_CTRL);
> - __raw_writel(val, sar_base + L2X0_PREFETCH_CTRL_OFFSET);
> + if (l2x0_base) {
> + val = __raw_readl(l2x0_base + L2X0_AUX_CTRL);
> + __raw_writel(val, sar_base + L2X0_AUXCTRL_OFFSET);
> + val = __raw_readl(l2x0_base + L2X0_PREFETCH_CTRL);
> + __raw_writel(val, sar_base + L2X0_PREFETCH_CTRL_OFFSET);
> + }
> }
> #else
> static void save_l2x0_context(void)
> @@ -239,17 +276,17 @@ int omap4_enter_lowpower(unsigned int cpu, unsigned int power_state)
>
> cpu_clear_prev_logic_pwrst(cpu);
> pwrdm_set_next_pwrst(pm_info->pwrdm, power_state);
> - set_cpu_wakeup_addr(cpu, virt_to_phys(omap4_cpu_resume));
> - scu_pwrst_prepare(cpu, power_state);
> + set_cpu_wakeup_addr(cpu, virt_to_phys(omap_pm_ops.resume));
> + omap_pm_ops.scu_prepare(cpu, power_state);
> l2x0_pwrst_prepare(cpu, save_state);
>
> /*
> * Call low level function with targeted low power state.
> */
> if (save_state)
> - cpu_suspend(save_state, omap4_finish_suspend);
> + cpu_suspend(save_state, omap_pm_ops.finish_suspend);
> else
> - omap4_finish_suspend(save_state);
> + omap_pm_ops.finish_suspend(save_state);
>
> /*
> * Restore the CPUx power state to ON otherwise CPUx
> @@ -285,14 +322,14 @@ int __cpuinit omap4_hotplug_cpu(unsigned int cpu, unsigned int power_state)
> pwrdm_clear_all_prev_pwrst(pm_info->pwrdm);
> pwrdm_set_next_pwrst(pm_info->pwrdm, power_state);
> set_cpu_wakeup_addr(cpu, virt_to_phys(pm_info->secondary_startup));
> - scu_pwrst_prepare(cpu, power_state);
> + omap_pm_ops.scu_prepare(cpu, power_state);
>
> /*
> * CPU never retuns back if targeted power state is OFF mode.
> * CPU ONLINE follows normal CPU ONLINE ptah via
> * omap_secondary_startup().
> */
> - omap4_finish_suspend(cpu_state);
> + omap_pm_ops.finish_suspend(cpu_state);
>
> pwrdm_set_next_pwrst(pm_info->pwrdm, PWRDM_POWER_ON);
> return 0;
> @@ -369,6 +406,12 @@ int __init omap4_mpuss_init(void)
>
> save_l2x0_context();
>
> + if (cpu_is_omap44xx()) {
> + omap_pm_ops.finish_suspend = omap4_finish_suspend;
> + omap_pm_ops.resume = omap4_cpu_resume;
> + omap_pm_ops.scu_prepare = scu_pwrst_prepare;
> + }
> +
> return 0;
> }
^ permalink raw reply [flat|nested] 128+ messages in thread
* Re: [PATCH v2 03/18] ARM: OMAP4+: PM: Consolidate and use OMAP4 PM code for OMAP5
2013-03-25 10:04 ` Santosh Shilimkar
@ 2013-04-03 20:20 ` Kevin Hilman
-1 siblings, 0 replies; 128+ messages in thread
From: Kevin Hilman @ 2013-04-03 20:20 UTC (permalink / raw)
To: Santosh Shilimkar; +Cc: linux-omap, linux-arm-kernel, nm, tony
Santosh Shilimkar <santosh.shilimkar@ti.com> writes:
> OMAP5 has backward compatible PRCM block and it's programming
> model is mostly similar to OMAP4. Same is going to be maintained
> for future OMAP4 based SOCs. Hence consolidate the OMAP4 power
> management code so that it can be re-used on OMAP5 and later devices.
>
> With consolidated code, let basic power management code build
> for OMAP5 devices. While at it, update the kernel-doc for omap4_pm_init().
>
> Acked-by: Nishanth Menon <nm@ti.com>
> Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
> ---
> arch/arm/mach-omap2/Makefile | 9 ++--
> arch/arm/mach-omap2/{pm44xx.c => pm_omap4plus.c} | 54 ++++++++++++++++----
> .../mach-omap2/{sleep44xx.S => sleep_omap4plus.S} | 0
> 3 files changed, 49 insertions(+), 14 deletions(-)
> rename arch/arm/mach-omap2/{pm44xx.c => pm_omap4plus.c} (86%)
> rename arch/arm/mach-omap2/{sleep44xx.S => sleep_omap4plus.S} (100%)
>
> diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
> index 5d5ff91..d91ae0f 100644
> --- a/arch/arm/mach-omap2/Makefile
> +++ b/arch/arm/mach-omap2/Makefile
> @@ -35,14 +35,14 @@ obj-$(CONFIG_SOC_HAS_OMAP2_SDRC) += sdrc.o
> obj-$(CONFIG_SMP) += omap-smp.o omap-headsmp.o
> obj-$(CONFIG_HOTPLUG_CPU) += omap-hotplug.o
> omap-4-5-common = omap4-common.o omap-wakeupgen.o \
> - sleep44xx.o
> + sleep_omap4plus.o
> obj-$(CONFIG_ARCH_OMAP4) += $(omap-4-5-common)
> obj-$(CONFIG_SOC_OMAP5) += $(omap-4-5-common)
>
> plus_sec := $(call as-instr,.arch_extension sec,+sec)
> AFLAGS_omap-headsmp.o :=-Wa,-march=armv7-a$(plus_sec)
> AFLAGS_omap-smc.o :=-Wa,-march=armv7-a$(plus_sec)
> -AFLAGS_sleep44xx.o :=-Wa,-march=armv7-a$(plus_sec)
> +AFLAGS_sleep_omap4plus.o :=-Wa,-march=armv7-a$(plus_sec)
>
> # Functions loaded to SRAM
> obj-$(CONFIG_SOC_OMAP2420) += sram242x.o
> @@ -80,11 +80,12 @@ endif
> obj-$(CONFIG_OMAP_PM_NOOP) += omap-pm-noop.o
>
> ifeq ($(CONFIG_PM),y)
> +omap4plus-common-pm = omap-mpuss-lowpower.o pm_omap4plus.o
> obj-$(CONFIG_ARCH_OMAP2) += pm24xx.o
> obj-$(CONFIG_ARCH_OMAP2) += sleep24xx.o
> obj-$(CONFIG_ARCH_OMAP3) += pm34xx.o sleep34xx.o
> -obj-$(CONFIG_ARCH_OMAP4) += pm44xx.o omap-mpuss-lowpower.o
> -obj-$(CONFIG_SOC_OMAP5) += omap-mpuss-lowpower.o
> +obj-$(CONFIG_ARCH_OMAP4) += $(omap4plus-common-pm)
> +obj-$(CONFIG_SOC_OMAP5) += $(omap4plus-common-pm)
> obj-$(CONFIG_PM_DEBUG) += pm-debug.o
>
> obj-$(CONFIG_POWER_AVS_OMAP) += sr_device.o
> diff --git a/arch/arm/mach-omap2/pm44xx.c b/arch/arm/mach-omap2/pm_omap4plus.c
> similarity index 86%
> rename from arch/arm/mach-omap2/pm44xx.c
> rename to arch/arm/mach-omap2/pm_omap4plus.c
> index 5ba6d88..e920c34 100644
> --- a/arch/arm/mach-omap2/pm44xx.c
> +++ b/arch/arm/mach-omap2/pm_omap4plus.c
> @@ -1,7 +1,7 @@
> /*
> - * OMAP4 Power Management Routines
> + * OMAP4PLUS Power Management Routines
nit: OMAP4+ (you only need to spell out "plus" in the filename.
> *
> - * Copyright (C) 2010-2011 Texas Instruments, Inc.
> + * Copyright (C) 2010-2013 Texas Instruments, Inc.
> * Rajendra Nayak <rnayak@ti.com>
> * Santosh Shilimkar <santosh.shilimkar@ti.com>
> *
> @@ -135,16 +135,16 @@ static void omap_default_idle(void)
> }
>
> /**
> - * omap4_pm_init - Init routine for OMAP4 PM
> + * omap4_init_static_deps - Add OMAP4 static dependencies
> *
> - * Initializes all powerdomain and clockdomain target states
> - * and all PRCM settings.
> + * Add needed static clockdomain dependencies on OMAP4 devices.
> + * Return: 0 on success or 'err' on failures
> */
> -int __init omap4_pm_init(void)
> +static inline int omap4_init_static_deps(void)
You dropped the __init here, but it's still only called from another
__init function, so I suspect it should stay.
> {
> - int ret;
> struct clockdomain *emif_clkdm, *mpuss_clkdm, *l3_1_clkdm;
> struct clockdomain *ducati_clkdm, *l3_2_clkdm;
> + int ret = 0;
>
> if (omap_rev() == OMAP4430_REV_ES1_0) {
> WARN(1, "Power Management not supported on OMAP4430 ES1.0\n");
> @@ -163,7 +163,7 @@ int __init omap4_pm_init(void)
> ret = pwrdm_for_each(pwrdms_setup, NULL);
> if (ret) {
> pr_err("Failed to setup powerdomains\n");
> - goto err2;
> + return ret;
> }
>
> /*
> @@ -179,7 +179,7 @@ int __init omap4_pm_init(void)
> ducati_clkdm = clkdm_lookup("ducati_clkdm");
> if ((!mpuss_clkdm) || (!emif_clkdm) || (!l3_1_clkdm) ||
> (!l3_2_clkdm) || (!ducati_clkdm))
> - goto err2;
> + return -EINVAL;
> ret = clkdm_add_wkdep(mpuss_clkdm, emif_clkdm);
> ret |= clkdm_add_wkdep(mpuss_clkdm, l3_1_clkdm);
> @@ -188,9 +188,42 @@ int __init omap4_pm_init(void)
> ret |= clkdm_add_wkdep(ducati_clkdm, l3_2_clkdm);
> if (ret) {
> pr_err("Failed to add MPUSS -> L3/EMIF/L4PER, DUCATI -> L3 wakeup dependency\n");
> + return -EINVAL;
> + }
> +
> + return ret;
> +}
> +
> +/**
> + * omap4_pm_init - Init routine for OMAP4+ devices
> + *
> + * Initializes all powerdomain and clockdomain target states
> + * and all PRCM settings.
> + * Return: Returns the error code returned by called functions.
> + */
> +int __init omap4_pm_init(void)
> +{
> + int ret = 0;
> +
> + if (omap_rev() == OMAP4430_REV_ES1_0) {
> + WARN(1, "Power Management not supported on OMAP4430 ES1.0\n");
> + return -ENODEV;
> + }
> +
> + pr_info("Power Management for TI OMAP4PLUS devices.\n");
s/PLUS/+/
Kevin
> +
> + ret = pwrdm_for_each(pwrdms_setup, NULL);
> + if (ret) {
> + pr_err("Failed to setup powerdomains.\n");
> goto err2;
> }
>
> + if (cpu_is_omap44xx()) {
> + ret = omap4_init_static_deps();
> + if (ret)
> + goto err2;
> + }
> +
> ret = omap4_mpuss_init();
> if (ret) {
> pr_err("Failed to initialise OMAP4 MPUSS\n");
> @@ -206,7 +239,8 @@ int __init omap4_pm_init(void)
> /* Overwrite the default cpu_do_idle() */
> arm_pm_idle = omap_default_idle;
>
> - omap4_idle_init();
> + if (cpu_is_omap44xx())
> + omap4_idle_init();
>
> err2:
> return ret;
> diff --git a/arch/arm/mach-omap2/sleep44xx.S b/arch/arm/mach-omap2/sleep_omap4plus.S
> similarity index 100%
> rename from arch/arm/mach-omap2/sleep44xx.S
> rename to arch/arm/mach-omap2/sleep_omap4plus.S
^ permalink raw reply [flat|nested] 128+ messages in thread
* [PATCH v2 03/18] ARM: OMAP4+: PM: Consolidate and use OMAP4 PM code for OMAP5
@ 2013-04-03 20:20 ` Kevin Hilman
0 siblings, 0 replies; 128+ messages in thread
From: Kevin Hilman @ 2013-04-03 20:20 UTC (permalink / raw)
To: linux-arm-kernel
Santosh Shilimkar <santosh.shilimkar@ti.com> writes:
> OMAP5 has backward compatible PRCM block and it's programming
> model is mostly similar to OMAP4. Same is going to be maintained
> for future OMAP4 based SOCs. Hence consolidate the OMAP4 power
> management code so that it can be re-used on OMAP5 and later devices.
>
> With consolidated code, let basic power management code build
> for OMAP5 devices. While at it, update the kernel-doc for omap4_pm_init().
>
> Acked-by: Nishanth Menon <nm@ti.com>
> Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
> ---
> arch/arm/mach-omap2/Makefile | 9 ++--
> arch/arm/mach-omap2/{pm44xx.c => pm_omap4plus.c} | 54 ++++++++++++++++----
> .../mach-omap2/{sleep44xx.S => sleep_omap4plus.S} | 0
> 3 files changed, 49 insertions(+), 14 deletions(-)
> rename arch/arm/mach-omap2/{pm44xx.c => pm_omap4plus.c} (86%)
> rename arch/arm/mach-omap2/{sleep44xx.S => sleep_omap4plus.S} (100%)
>
> diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
> index 5d5ff91..d91ae0f 100644
> --- a/arch/arm/mach-omap2/Makefile
> +++ b/arch/arm/mach-omap2/Makefile
> @@ -35,14 +35,14 @@ obj-$(CONFIG_SOC_HAS_OMAP2_SDRC) += sdrc.o
> obj-$(CONFIG_SMP) += omap-smp.o omap-headsmp.o
> obj-$(CONFIG_HOTPLUG_CPU) += omap-hotplug.o
> omap-4-5-common = omap4-common.o omap-wakeupgen.o \
> - sleep44xx.o
> + sleep_omap4plus.o
> obj-$(CONFIG_ARCH_OMAP4) += $(omap-4-5-common)
> obj-$(CONFIG_SOC_OMAP5) += $(omap-4-5-common)
>
> plus_sec := $(call as-instr,.arch_extension sec,+sec)
> AFLAGS_omap-headsmp.o :=-Wa,-march=armv7-a$(plus_sec)
> AFLAGS_omap-smc.o :=-Wa,-march=armv7-a$(plus_sec)
> -AFLAGS_sleep44xx.o :=-Wa,-march=armv7-a$(plus_sec)
> +AFLAGS_sleep_omap4plus.o :=-Wa,-march=armv7-a$(plus_sec)
>
> # Functions loaded to SRAM
> obj-$(CONFIG_SOC_OMAP2420) += sram242x.o
> @@ -80,11 +80,12 @@ endif
> obj-$(CONFIG_OMAP_PM_NOOP) += omap-pm-noop.o
>
> ifeq ($(CONFIG_PM),y)
> +omap4plus-common-pm = omap-mpuss-lowpower.o pm_omap4plus.o
> obj-$(CONFIG_ARCH_OMAP2) += pm24xx.o
> obj-$(CONFIG_ARCH_OMAP2) += sleep24xx.o
> obj-$(CONFIG_ARCH_OMAP3) += pm34xx.o sleep34xx.o
> -obj-$(CONFIG_ARCH_OMAP4) += pm44xx.o omap-mpuss-lowpower.o
> -obj-$(CONFIG_SOC_OMAP5) += omap-mpuss-lowpower.o
> +obj-$(CONFIG_ARCH_OMAP4) += $(omap4plus-common-pm)
> +obj-$(CONFIG_SOC_OMAP5) += $(omap4plus-common-pm)
> obj-$(CONFIG_PM_DEBUG) += pm-debug.o
>
> obj-$(CONFIG_POWER_AVS_OMAP) += sr_device.o
> diff --git a/arch/arm/mach-omap2/pm44xx.c b/arch/arm/mach-omap2/pm_omap4plus.c
> similarity index 86%
> rename from arch/arm/mach-omap2/pm44xx.c
> rename to arch/arm/mach-omap2/pm_omap4plus.c
> index 5ba6d88..e920c34 100644
> --- a/arch/arm/mach-omap2/pm44xx.c
> +++ b/arch/arm/mach-omap2/pm_omap4plus.c
> @@ -1,7 +1,7 @@
> /*
> - * OMAP4 Power Management Routines
> + * OMAP4PLUS Power Management Routines
nit: OMAP4+ (you only need to spell out "plus" in the filename.
> *
> - * Copyright (C) 2010-2011 Texas Instruments, Inc.
> + * Copyright (C) 2010-2013 Texas Instruments, Inc.
> * Rajendra Nayak <rnayak@ti.com>
> * Santosh Shilimkar <santosh.shilimkar@ti.com>
> *
> @@ -135,16 +135,16 @@ static void omap_default_idle(void)
> }
>
> /**
> - * omap4_pm_init - Init routine for OMAP4 PM
> + * omap4_init_static_deps - Add OMAP4 static dependencies
> *
> - * Initializes all powerdomain and clockdomain target states
> - * and all PRCM settings.
> + * Add needed static clockdomain dependencies on OMAP4 devices.
> + * Return: 0 on success or 'err' on failures
> */
> -int __init omap4_pm_init(void)
> +static inline int omap4_init_static_deps(void)
You dropped the __init here, but it's still only called from another
__init function, so I suspect it should stay.
> {
> - int ret;
> struct clockdomain *emif_clkdm, *mpuss_clkdm, *l3_1_clkdm;
> struct clockdomain *ducati_clkdm, *l3_2_clkdm;
> + int ret = 0;
>
> if (omap_rev() == OMAP4430_REV_ES1_0) {
> WARN(1, "Power Management not supported on OMAP4430 ES1.0\n");
> @@ -163,7 +163,7 @@ int __init omap4_pm_init(void)
> ret = pwrdm_for_each(pwrdms_setup, NULL);
> if (ret) {
> pr_err("Failed to setup powerdomains\n");
> - goto err2;
> + return ret;
> }
>
> /*
> @@ -179,7 +179,7 @@ int __init omap4_pm_init(void)
> ducati_clkdm = clkdm_lookup("ducati_clkdm");
> if ((!mpuss_clkdm) || (!emif_clkdm) || (!l3_1_clkdm) ||
> (!l3_2_clkdm) || (!ducati_clkdm))
> - goto err2;
> + return -EINVAL;
> ret = clkdm_add_wkdep(mpuss_clkdm, emif_clkdm);
> ret |= clkdm_add_wkdep(mpuss_clkdm, l3_1_clkdm);
> @@ -188,9 +188,42 @@ int __init omap4_pm_init(void)
> ret |= clkdm_add_wkdep(ducati_clkdm, l3_2_clkdm);
> if (ret) {
> pr_err("Failed to add MPUSS -> L3/EMIF/L4PER, DUCATI -> L3 wakeup dependency\n");
> + return -EINVAL;
> + }
> +
> + return ret;
> +}
> +
> +/**
> + * omap4_pm_init - Init routine for OMAP4+ devices
> + *
> + * Initializes all powerdomain and clockdomain target states
> + * and all PRCM settings.
> + * Return: Returns the error code returned by called functions.
> + */
> +int __init omap4_pm_init(void)
> +{
> + int ret = 0;
> +
> + if (omap_rev() == OMAP4430_REV_ES1_0) {
> + WARN(1, "Power Management not supported on OMAP4430 ES1.0\n");
> + return -ENODEV;
> + }
> +
> + pr_info("Power Management for TI OMAP4PLUS devices.\n");
s/PLUS/+/
Kevin
> +
> + ret = pwrdm_for_each(pwrdms_setup, NULL);
> + if (ret) {
> + pr_err("Failed to setup powerdomains.\n");
> goto err2;
> }
>
> + if (cpu_is_omap44xx()) {
> + ret = omap4_init_static_deps();
> + if (ret)
> + goto err2;
> + }
> +
> ret = omap4_mpuss_init();
> if (ret) {
> pr_err("Failed to initialise OMAP4 MPUSS\n");
> @@ -206,7 +239,8 @@ int __init omap4_pm_init(void)
> /* Overwrite the default cpu_do_idle() */
> arm_pm_idle = omap_default_idle;
>
> - omap4_idle_init();
> + if (cpu_is_omap44xx())
> + omap4_idle_init();
>
> err2:
> return ret;
> diff --git a/arch/arm/mach-omap2/sleep44xx.S b/arch/arm/mach-omap2/sleep_omap4plus.S
> similarity index 100%
> rename from arch/arm/mach-omap2/sleep44xx.S
> rename to arch/arm/mach-omap2/sleep_omap4plus.S
^ permalink raw reply [flat|nested] 128+ messages in thread
* Re: [PATCH v2 05/18] ARM: OMAP5: PM: Enables ES2 PM mode by default
2013-03-25 10:04 ` Santosh Shilimkar
@ 2013-04-03 20:25 ` Kevin Hilman
-1 siblings, 0 replies; 128+ messages in thread
From: Kevin Hilman @ 2013-04-03 20:25 UTC (permalink / raw)
To: Santosh Shilimkar; +Cc: linux-omap, linux-arm-kernel, nm, tony
Santosh Shilimkar <santosh.shilimkar@ti.com> writes:
> Enables MPUSS ES2 power management mode using ES2_PM_MODE in
> AMBA_IF_MODE register.
>
> 0x0: ES1 behavior, CPU cores would enter and exit OFF mode together. Broken
What is broken?
> 0x1: ES2 behavior, CPU cores are allowed to enter/exit OFF mode independently.
>
> The AMBA_IF_MODE register value is stored on SAR RAM and restored by
> ROM code.
>
> Acked-by: Nishanth Menon <nm@ti.com>
> Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
> ---
> arch/arm/mach-omap2/omap-secure.h | 2 ++
> arch/arm/mach-omap2/omap-wakeupgen.c | 19 +++++++++++++++++++
> arch/arm/mach-omap2/omap-wakeupgen.h | 1 +
> 3 files changed, 22 insertions(+)
>
> diff --git a/arch/arm/mach-omap2/omap-secure.h b/arch/arm/mach-omap2/omap-secure.h
> index 0e72917..82b3c4c 100644
> --- a/arch/arm/mach-omap2/omap-secure.h
> +++ b/arch/arm/mach-omap2/omap-secure.h
> @@ -42,6 +42,8 @@
> #define OMAP4_MON_L2X0_AUXCTRL_INDEX 0x109
> #define OMAP4_MON_L2X0_PREFETCH_INDEX 0x113
>
> +#define OMAP5_MON_AMBA_IF_INDEX 0x108
> +
> /* Secure PPA(Primary Protected Application) APIs */
> #define OMAP4_PPA_L2_POR_INDEX 0x23
> #define OMAP4_PPA_CPU_ACTRL_SMP_INDEX 0x25
> diff --git a/arch/arm/mach-omap2/omap-wakeupgen.c b/arch/arm/mach-omap2/omap-wakeupgen.c
> index f8bb3b9..8bcaa8c 100644
> --- a/arch/arm/mach-omap2/omap-wakeupgen.c
> +++ b/arch/arm/mach-omap2/omap-wakeupgen.c
> @@ -42,6 +42,7 @@
> #define CPU1_ID 0x1
> #define OMAP4_NR_BANKS 4
> #define OMAP4_NR_IRQS 128
> +#define OMAP5_AMBA_IF_PM_MODE (1 << 5)
nit: use BIT()
Kevin
^ permalink raw reply [flat|nested] 128+ messages in thread
* [PATCH v2 05/18] ARM: OMAP5: PM: Enables ES2 PM mode by default
@ 2013-04-03 20:25 ` Kevin Hilman
0 siblings, 0 replies; 128+ messages in thread
From: Kevin Hilman @ 2013-04-03 20:25 UTC (permalink / raw)
To: linux-arm-kernel
Santosh Shilimkar <santosh.shilimkar@ti.com> writes:
> Enables MPUSS ES2 power management mode using ES2_PM_MODE in
> AMBA_IF_MODE register.
>
> 0x0: ES1 behavior, CPU cores would enter and exit OFF mode together. Broken
What is broken?
> 0x1: ES2 behavior, CPU cores are allowed to enter/exit OFF mode independently.
>
> The AMBA_IF_MODE register value is stored on SAR RAM and restored by
> ROM code.
>
> Acked-by: Nishanth Menon <nm@ti.com>
> Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
> ---
> arch/arm/mach-omap2/omap-secure.h | 2 ++
> arch/arm/mach-omap2/omap-wakeupgen.c | 19 +++++++++++++++++++
> arch/arm/mach-omap2/omap-wakeupgen.h | 1 +
> 3 files changed, 22 insertions(+)
>
> diff --git a/arch/arm/mach-omap2/omap-secure.h b/arch/arm/mach-omap2/omap-secure.h
> index 0e72917..82b3c4c 100644
> --- a/arch/arm/mach-omap2/omap-secure.h
> +++ b/arch/arm/mach-omap2/omap-secure.h
> @@ -42,6 +42,8 @@
> #define OMAP4_MON_L2X0_AUXCTRL_INDEX 0x109
> #define OMAP4_MON_L2X0_PREFETCH_INDEX 0x113
>
> +#define OMAP5_MON_AMBA_IF_INDEX 0x108
> +
> /* Secure PPA(Primary Protected Application) APIs */
> #define OMAP4_PPA_L2_POR_INDEX 0x23
> #define OMAP4_PPA_CPU_ACTRL_SMP_INDEX 0x25
> diff --git a/arch/arm/mach-omap2/omap-wakeupgen.c b/arch/arm/mach-omap2/omap-wakeupgen.c
> index f8bb3b9..8bcaa8c 100644
> --- a/arch/arm/mach-omap2/omap-wakeupgen.c
> +++ b/arch/arm/mach-omap2/omap-wakeupgen.c
> @@ -42,6 +42,7 @@
> #define CPU1_ID 0x1
> #define OMAP4_NR_BANKS 4
> #define OMAP4_NR_IRQS 128
> +#define OMAP5_AMBA_IF_PM_MODE (1 << 5)
nit: use BIT()
Kevin
^ permalink raw reply [flat|nested] 128+ messages in thread
* Re: [PATCH v2 06/18] ARM: OMAP5: PM: Enable Mercury retention mode on CPUx powerdomains
2013-03-25 10:04 ` Santosh Shilimkar
@ 2013-04-03 20:31 ` Kevin Hilman
-1 siblings, 0 replies; 128+ messages in thread
From: Kevin Hilman @ 2013-04-03 20:31 UTC (permalink / raw)
To: Santosh Shilimkar; +Cc: linux-omap, linux-arm-kernel, nm, tony
Santosh Shilimkar <santosh.shilimkar@ti.com> writes:
> In addition to the standard power-management technique, the OMAP5
> MPU subsystem also employs an SR3-APG (mercury) power management
> technology to reduce leakage.
>
> It allows for full logic and memories retention on MPU_C0 and MPU_C1 and
> is controlled by the PRCM_MPU.
>
> Acked-by: Nishanth Menon <nm@ti.com>
> Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
> ---
> arch/arm/mach-omap2/omap-mpuss-lowpower.c | 27 +++++++++++++++++++++++++++
> 1 file changed, 27 insertions(+)
>
> diff --git a/arch/arm/mach-omap2/omap-mpuss-lowpower.c b/arch/arm/mach-omap2/omap-mpuss-lowpower.c
> index b1441b1..d390d18 100644
> --- a/arch/arm/mach-omap2/omap-mpuss-lowpower.c
> +++ b/arch/arm/mach-omap2/omap-mpuss-lowpower.c
> @@ -62,6 +62,10 @@
> #include "prm44xx.h"
> #include "prm-regbits-44xx.h"
>
> +/* Add defines needed for mercury mode. Refer MPU's PRM_PSCON_COUNT */
> +#define PRM_PSCON_HG_EN (1 << 24)
> +#define PRM_PSCON_HG_RAMPUP (1 << 25)
nit: use BIT()
> #ifdef CONFIG_SMP
>
> struct omap4_cpu_pm_info {
> @@ -337,6 +341,28 @@ int __cpuinit omap4_hotplug_cpu(unsigned int cpu, unsigned int power_state)
> return 0;
> }
>
> +/**
> + * enable_mercury_retention_mode: Enable OMAP5 mercury retention feature
> + *
> + * OMAP5 devices supports SR3-APG (mercury) power management technology to
> + * reduce leakage. It allows for full logic and memories retention on
> + * MPU_C0 and MPU_C1 and is controlled by the PRCM_MPU. The function enable
> + * the mercury retention feature.
> + */
> +static void enable_mercury_retention_mode(void)
__init ?
This is very OMAP5 specific (unless you generalize the offsets used) so
should this have omap5_ prefix?
Kevin
> +{
> + u32 reg;
> +
> + /*
> + * To enable mercury mode, both HG_EN and HG_RAMPUP needs to be
> + * enabled from PRM_PSCON_COUNT register.
> + */
> + reg = omap4_prcm_mpu_read_inst_reg(OMAP54XX_PRCM_MPU_DEVICE_INST,
> + OMAP54XX_PRCM_MPU_PRM_PSCON_COUNT_OFFSET);
> + reg |= PRM_PSCON_HG_EN | PRM_PSCON_HG_RAMPUP;
> + omap4_prcm_mpu_write_inst_reg(reg, OMAP54XX_PRCM_MPU_DEVICE_INST,
> + OMAP54XX_PRCM_MPU_PRM_PSCON_COUNT_OFFSET);
nit: when I see 'reg', I expect it to be a register/offset. But this is
a register value. Maybe use 'val' instead as you've done elsewhere in
this series.
Kevin
> +}
>
> /*
> * Initialise OMAP4 MPUSS
> @@ -415,6 +441,7 @@ int __init omap4_mpuss_init(void)
> cpu_context_offset = OMAP4_RM_CPU0_CPU0_CONTEXT_OFFSET;
> } else if (soc_is_omap54xx()) {
> cpu_context_offset = OMAP54XX_RM_CPU0_CPU0_CONTEXT_OFFSET;
> + enable_mercury_retention_mode();
> }
>
> return 0;
^ permalink raw reply [flat|nested] 128+ messages in thread
* [PATCH v2 06/18] ARM: OMAP5: PM: Enable Mercury retention mode on CPUx powerdomains
@ 2013-04-03 20:31 ` Kevin Hilman
0 siblings, 0 replies; 128+ messages in thread
From: Kevin Hilman @ 2013-04-03 20:31 UTC (permalink / raw)
To: linux-arm-kernel
Santosh Shilimkar <santosh.shilimkar@ti.com> writes:
> In addition to the standard power-management technique, the OMAP5
> MPU subsystem also employs an SR3-APG (mercury) power management
> technology to reduce leakage.
>
> It allows for full logic and memories retention on MPU_C0 and MPU_C1 and
> is controlled by the PRCM_MPU.
>
> Acked-by: Nishanth Menon <nm@ti.com>
> Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
> ---
> arch/arm/mach-omap2/omap-mpuss-lowpower.c | 27 +++++++++++++++++++++++++++
> 1 file changed, 27 insertions(+)
>
> diff --git a/arch/arm/mach-omap2/omap-mpuss-lowpower.c b/arch/arm/mach-omap2/omap-mpuss-lowpower.c
> index b1441b1..d390d18 100644
> --- a/arch/arm/mach-omap2/omap-mpuss-lowpower.c
> +++ b/arch/arm/mach-omap2/omap-mpuss-lowpower.c
> @@ -62,6 +62,10 @@
> #include "prm44xx.h"
> #include "prm-regbits-44xx.h"
>
> +/* Add defines needed for mercury mode. Refer MPU's PRM_PSCON_COUNT */
> +#define PRM_PSCON_HG_EN (1 << 24)
> +#define PRM_PSCON_HG_RAMPUP (1 << 25)
nit: use BIT()
> #ifdef CONFIG_SMP
>
> struct omap4_cpu_pm_info {
> @@ -337,6 +341,28 @@ int __cpuinit omap4_hotplug_cpu(unsigned int cpu, unsigned int power_state)
> return 0;
> }
>
> +/**
> + * enable_mercury_retention_mode: Enable OMAP5 mercury retention feature
> + *
> + * OMAP5 devices supports SR3-APG (mercury) power management technology to
> + * reduce leakage. It allows for full logic and memories retention on
> + * MPU_C0 and MPU_C1 and is controlled by the PRCM_MPU. The function enable
> + * the mercury retention feature.
> + */
> +static void enable_mercury_retention_mode(void)
__init ?
This is very OMAP5 specific (unless you generalize the offsets used) so
should this have omap5_ prefix?
Kevin
> +{
> + u32 reg;
> +
> + /*
> + * To enable mercury mode, both HG_EN and HG_RAMPUP needs to be
> + * enabled from PRM_PSCON_COUNT register.
> + */
> + reg = omap4_prcm_mpu_read_inst_reg(OMAP54XX_PRCM_MPU_DEVICE_INST,
> + OMAP54XX_PRCM_MPU_PRM_PSCON_COUNT_OFFSET);
> + reg |= PRM_PSCON_HG_EN | PRM_PSCON_HG_RAMPUP;
> + omap4_prcm_mpu_write_inst_reg(reg, OMAP54XX_PRCM_MPU_DEVICE_INST,
> + OMAP54XX_PRCM_MPU_PRM_PSCON_COUNT_OFFSET);
nit: when I see 'reg', I expect it to be a register/offset. But this is
a register value. Maybe use 'val' instead as you've done elsewhere in
this series.
Kevin
> +}
>
> /*
> * Initialise OMAP4 MPUSS
> @@ -415,6 +441,7 @@ int __init omap4_mpuss_init(void)
> cpu_context_offset = OMAP4_RM_CPU0_CPU0_CONTEXT_OFFSET;
> } else if (soc_is_omap54xx()) {
> cpu_context_offset = OMAP54XX_RM_CPU0_CPU0_CONTEXT_OFFSET;
> + enable_mercury_retention_mode();
> }
>
> return 0;
^ permalink raw reply [flat|nested] 128+ messages in thread
* Re: [PATCH v2 07/18] ARM: OMAP5: Add init_late() hook to enable pm initialization
2013-03-25 10:04 ` Santosh Shilimkar
@ 2013-04-03 20:33 ` Kevin Hilman
-1 siblings, 0 replies; 128+ messages in thread
From: Kevin Hilman @ 2013-04-03 20:33 UTC (permalink / raw)
To: Santosh Shilimkar; +Cc: linux-omap, linux-arm-kernel, nm, tony
Santosh Shilimkar <santosh.shilimkar@ti.com> writes:
> With consolidated code, now we can add the .init_late hook for
> OMAP5 to enable power management and mux initialization.
>
> Acked-by: Nishanth Menon <nm@ti.com>
> Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
> ---
> arch/arm/mach-omap2/board-generic.c | 1 +
> arch/arm/mach-omap2/common.h | 3 ++-
> arch/arm/mach-omap2/io.c | 8 ++++++++
> 3 files changed, 11 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm/mach-omap2/board-generic.c b/arch/arm/mach-omap2/board-generic.c
> index e54a480..8e261a6 100644
> --- a/arch/arm/mach-omap2/board-generic.c
> +++ b/arch/arm/mach-omap2/board-generic.c
> @@ -180,6 +180,7 @@ DT_MACHINE_START(OMAP5_DT, "Generic OMAP5 (Flattened Device Tree)")
> .init_irq = omap_gic_of_init,
> .init_machine = omap_generic_init,
> .init_time = omap5_realtime_timer_init,
> + .init_late = omap5_init_late,
> .dt_compat = omap5_boards_compat,
> .restart = omap44xx_restart,
> MACHINE_END
> diff --git a/arch/arm/mach-omap2/common.h b/arch/arm/mach-omap2/common.h
> index 40f4a03..f75d972 100644
> --- a/arch/arm/mach-omap2/common.h
> +++ b/arch/arm/mach-omap2/common.h
> @@ -59,7 +59,7 @@ static inline int omap3_pm_init(void)
> }
> #endif
>
> -#if defined(CONFIG_PM) && defined(CONFIG_ARCH_OMAP4)
> +#if defined(CONFIG_PM) && (defined(CONFIG_ARCH_OMAP4) || defined(CONFIG_SOC_OMAP5))
> int omap4_pm_init(void);
> #else
> static inline int omap4_pm_init(void)
> @@ -108,6 +108,7 @@ void omap35xx_init_late(void);
> void omap3630_init_late(void);
> void am35xx_init_late(void);
> void ti81xx_init_late(void);
> +void omap5_init_late(void);
> int omap2_common_pm_late_init(void);
>
> #if defined(CONFIG_SOC_OMAP2420) || defined(CONFIG_SOC_OMAP2430)
> diff --git a/arch/arm/mach-omap2/io.c b/arch/arm/mach-omap2/io.c
> index e948a39..cdd1264 100644
> --- a/arch/arm/mach-omap2/io.c
> +++ b/arch/arm/mach-omap2/io.c
> @@ -636,6 +636,14 @@ void __init omap5_init_early(void)
> omap_hwmod_init_postsetup();
>
> }
> +
> +void __init omap5_init_late(void)
> +{
> + omap_mux_late_init();
> + omap2_common_pm_late_init();
> + omap4_pm_init();
> + omap2_clk_enable_autoidle_all();
> +}
Since you're consolidating, why not rename omap4430_init_late to
omap4plus_init_late and use it for both OMAP4 and OMAP5?
Kevin
> #endif
>
> void __init omap_sdrc_init(struct omap_sdrc_params *sdrc_cs0,
^ permalink raw reply [flat|nested] 128+ messages in thread
* [PATCH v2 07/18] ARM: OMAP5: Add init_late() hook to enable pm initialization
@ 2013-04-03 20:33 ` Kevin Hilman
0 siblings, 0 replies; 128+ messages in thread
From: Kevin Hilman @ 2013-04-03 20:33 UTC (permalink / raw)
To: linux-arm-kernel
Santosh Shilimkar <santosh.shilimkar@ti.com> writes:
> With consolidated code, now we can add the .init_late hook for
> OMAP5 to enable power management and mux initialization.
>
> Acked-by: Nishanth Menon <nm@ti.com>
> Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
> ---
> arch/arm/mach-omap2/board-generic.c | 1 +
> arch/arm/mach-omap2/common.h | 3 ++-
> arch/arm/mach-omap2/io.c | 8 ++++++++
> 3 files changed, 11 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm/mach-omap2/board-generic.c b/arch/arm/mach-omap2/board-generic.c
> index e54a480..8e261a6 100644
> --- a/arch/arm/mach-omap2/board-generic.c
> +++ b/arch/arm/mach-omap2/board-generic.c
> @@ -180,6 +180,7 @@ DT_MACHINE_START(OMAP5_DT, "Generic OMAP5 (Flattened Device Tree)")
> .init_irq = omap_gic_of_init,
> .init_machine = omap_generic_init,
> .init_time = omap5_realtime_timer_init,
> + .init_late = omap5_init_late,
> .dt_compat = omap5_boards_compat,
> .restart = omap44xx_restart,
> MACHINE_END
> diff --git a/arch/arm/mach-omap2/common.h b/arch/arm/mach-omap2/common.h
> index 40f4a03..f75d972 100644
> --- a/arch/arm/mach-omap2/common.h
> +++ b/arch/arm/mach-omap2/common.h
> @@ -59,7 +59,7 @@ static inline int omap3_pm_init(void)
> }
> #endif
>
> -#if defined(CONFIG_PM) && defined(CONFIG_ARCH_OMAP4)
> +#if defined(CONFIG_PM) && (defined(CONFIG_ARCH_OMAP4) || defined(CONFIG_SOC_OMAP5))
> int omap4_pm_init(void);
> #else
> static inline int omap4_pm_init(void)
> @@ -108,6 +108,7 @@ void omap35xx_init_late(void);
> void omap3630_init_late(void);
> void am35xx_init_late(void);
> void ti81xx_init_late(void);
> +void omap5_init_late(void);
> int omap2_common_pm_late_init(void);
>
> #if defined(CONFIG_SOC_OMAP2420) || defined(CONFIG_SOC_OMAP2430)
> diff --git a/arch/arm/mach-omap2/io.c b/arch/arm/mach-omap2/io.c
> index e948a39..cdd1264 100644
> --- a/arch/arm/mach-omap2/io.c
> +++ b/arch/arm/mach-omap2/io.c
> @@ -636,6 +636,14 @@ void __init omap5_init_early(void)
> omap_hwmod_init_postsetup();
>
> }
> +
> +void __init omap5_init_late(void)
> +{
> + omap_mux_late_init();
> + omap2_common_pm_late_init();
> + omap4_pm_init();
> + omap2_clk_enable_autoidle_all();
> +}
Since you're consolidating, why not rename omap4430_init_late to
omap4plus_init_late and use it for both OMAP4 and OMAP5?
Kevin
> #endif
>
> void __init omap_sdrc_init(struct omap_sdrc_params *sdrc_cs0,
^ permalink raw reply [flat|nested] 128+ messages in thread
* Re: [PATCH v2 08/18] ARM: OMAP5: PM: Add CPU power off in hotplug path
2013-03-25 10:05 ` Santosh Shilimkar
@ 2013-04-03 20:49 ` Kevin Hilman
-1 siblings, 0 replies; 128+ messages in thread
From: Kevin Hilman @ 2013-04-03 20:49 UTC (permalink / raw)
To: Santosh Shilimkar; +Cc: linux-omap, linux-arm-kernel, nm, tony
Santosh Shilimkar <santosh.shilimkar@ti.com> writes:
> Add power management code to handle the CPU off mode to enable CPUP hotplug
> mode for OMAP5 devices. Separate suspend finisher is used for OMAP5(Cortex-A15)
> because it doesn't use SCU power status register and external PL310 L2 cache
> which makes code flow bit different.
>
> Acked-by: Nishanth Menon <nm@ti.com>
> Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
[...]
> @@ -436,14 +445,21 @@ int __init omap4_mpuss_init(void)
>
> if (cpu_is_omap44xx()) {
> omap_pm_ops.finish_suspend = omap4_finish_suspend;
> + omap_pm_ops.hotplug_restart = omap_secondary_startup;
> omap_pm_ops.resume = omap4_cpu_resume;
> omap_pm_ops.scu_prepare = scu_pwrst_prepare;
> cpu_context_offset = OMAP4_RM_CPU0_CPU0_CONTEXT_OFFSET;
> } else if (soc_is_omap54xx()) {
> + omap_pm_ops.finish_suspend = omap5_finish_suspend;
> + omap_pm_ops.hotplug_restart = omap5_secondary_startup;
> cpu_context_offset = OMAP54XX_RM_CPU0_CPU0_CONTEXT_OFFSET;
> enable_mercury_retention_mode();
> }
>
> + /* Over-write the OMAP4 hook to take care of ROM BUG */
> + if (cpu_is_omap446x())
> + omap_pm_ops.hotplug_restart = omap_secondary_startup_4460;
A couple nits...
I think this would go better at the end of the 'if omap44xx' block
above.
Also, while you're hear, maybe it's time to rename the current secondary
startup functions to match the new one. IOW omap4_..., omap4460_... and omap5_...
Kevin
^ permalink raw reply [flat|nested] 128+ messages in thread
* [PATCH v2 08/18] ARM: OMAP5: PM: Add CPU power off in hotplug path
@ 2013-04-03 20:49 ` Kevin Hilman
0 siblings, 0 replies; 128+ messages in thread
From: Kevin Hilman @ 2013-04-03 20:49 UTC (permalink / raw)
To: linux-arm-kernel
Santosh Shilimkar <santosh.shilimkar@ti.com> writes:
> Add power management code to handle the CPU off mode to enable CPUP hotplug
> mode for OMAP5 devices. Separate suspend finisher is used for OMAP5(Cortex-A15)
> because it doesn't use SCU power status register and external PL310 L2 cache
> which makes code flow bit different.
>
> Acked-by: Nishanth Menon <nm@ti.com>
> Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
[...]
> @@ -436,14 +445,21 @@ int __init omap4_mpuss_init(void)
>
> if (cpu_is_omap44xx()) {
> omap_pm_ops.finish_suspend = omap4_finish_suspend;
> + omap_pm_ops.hotplug_restart = omap_secondary_startup;
> omap_pm_ops.resume = omap4_cpu_resume;
> omap_pm_ops.scu_prepare = scu_pwrst_prepare;
> cpu_context_offset = OMAP4_RM_CPU0_CPU0_CONTEXT_OFFSET;
> } else if (soc_is_omap54xx()) {
> + omap_pm_ops.finish_suspend = omap5_finish_suspend;
> + omap_pm_ops.hotplug_restart = omap5_secondary_startup;
> cpu_context_offset = OMAP54XX_RM_CPU0_CPU0_CONTEXT_OFFSET;
> enable_mercury_retention_mode();
> }
>
> + /* Over-write the OMAP4 hook to take care of ROM BUG */
> + if (cpu_is_omap446x())
> + omap_pm_ops.hotplug_restart = omap_secondary_startup_4460;
A couple nits...
I think this would go better at the end of the 'if omap44xx' block
above.
Also, while you're hear, maybe it's time to rename the current secondary
startup functions to match the new one. IOW omap4_..., omap4460_... and omap5_...
Kevin
^ permalink raw reply [flat|nested] 128+ messages in thread
* Re: [PATCH v2 09/18] ARM: OMAP4+: PM: Restore CPU power state to ON with clockdomain force wakeup method
2013-03-25 10:05 ` Santosh Shilimkar
@ 2013-04-03 20:54 ` Kevin Hilman
-1 siblings, 0 replies; 128+ messages in thread
From: Kevin Hilman @ 2013-04-03 20:54 UTC (permalink / raw)
To: Santosh Shilimkar; +Cc: linux-omap, linux-arm-kernel, nm, tony
Santosh Shilimkar <santosh.shilimkar@ti.com> writes:
> While waking up CPU from off state using clock domain force wakeup, restore
> the CPU power state to ON state before putting CPU clock domain under
> hardware control. Otherwise CPU wakeup might fail. The change is recommended
> for all OMAP4+ devices though the PRCM weakness was observed on OMAP5
> devices first.
Sounds reasonable, but can you describe the "weakness" a little more?
IOW, what exactly happens if this is not done? It sounds like the CPU
might immediately go back to retention, but how does that happen unless
it does a WFI?
Also, this sounds like a fix to me, and should probably be broken out
accordingly.
Kevin
^ permalink raw reply [flat|nested] 128+ messages in thread
* [PATCH v2 09/18] ARM: OMAP4+: PM: Restore CPU power state to ON with clockdomain force wakeup method
@ 2013-04-03 20:54 ` Kevin Hilman
0 siblings, 0 replies; 128+ messages in thread
From: Kevin Hilman @ 2013-04-03 20:54 UTC (permalink / raw)
To: linux-arm-kernel
Santosh Shilimkar <santosh.shilimkar@ti.com> writes:
> While waking up CPU from off state using clock domain force wakeup, restore
> the CPU power state to ON state before putting CPU clock domain under
> hardware control. Otherwise CPU wakeup might fail. The change is recommended
> for all OMAP4+ devices though the PRCM weakness was observed on OMAP5
> devices first.
Sounds reasonable, but can you describe the "weakness" a little more?
IOW, what exactly happens if this is not done? It sounds like the CPU
might immediately go back to retention, but how does that happen unless
it does a WFI?
Also, this sounds like a fix to me, and should probably be broken out
accordingly.
Kevin
^ permalink raw reply [flat|nested] 128+ messages in thread
* Re: [PATCH v2 11/18] ARM: OMAP5: PM: Add L2 memory power down support
2013-03-25 10:05 ` Santosh Shilimkar
@ 2013-04-03 20:58 ` Kevin Hilman
-1 siblings, 0 replies; 128+ messages in thread
From: Kevin Hilman @ 2013-04-03 20:58 UTC (permalink / raw)
To: Santosh Shilimkar; +Cc: linux-omap, linux-arm-kernel, nm, tony
Santosh Shilimkar <santosh.shilimkar@ti.com> writes:
> When the entire MPUSS cluster is powered down in device off state, L2 cache
> memory looses it's content and hence while targetting such a state,
> l2 cache needs to be flushed to main memory.
>
> Add the necessary low power code support for the same.
>
> Acked-by: Nishanth Menon <nm@ti.com>
> Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
> ---
> arch/arm/mach-omap2/omap-secure.h | 1 +
> arch/arm/mach-omap2/sleep_omap4plus.S | 21 +++++++++++++++++++++
> 2 files changed, 22 insertions(+)
>
> diff --git a/arch/arm/mach-omap2/omap-secure.h b/arch/arm/mach-omap2/omap-secure.h
> index 1739468..a171a5a 100644
> --- a/arch/arm/mach-omap2/omap-secure.h
> +++ b/arch/arm/mach-omap2/omap-secure.h
> @@ -47,6 +47,7 @@
> #define OMAP4_MON_L2X0_PREFETCH_INDEX 0x113
> #define OMAP5_MON_CACHES_CLEAN_INDEX 0x103
> #define OMAP5_MON_AUX_CTRL_INDEX 0x107
> +#define OMAP5_MON_L2AUX_CTRL_INDEX 0x104
this #define is not used in this patch.
Kevin
> #define OMAP5_MON_AMBA_IF_INDEX 0x108
>
> diff --git a/arch/arm/mach-omap2/sleep_omap4plus.S b/arch/arm/mach-omap2/sleep_omap4plus.S
> index 4a5e2e4..288f62f 100644
> --- a/arch/arm/mach-omap2/sleep_omap4plus.S
> +++ b/arch/arm/mach-omap2/sleep_omap4plus.S
> @@ -337,6 +337,7 @@ ENDPROC(omap4_cpu_resume)
> * 0 - Nothing lost and no need to save: MPUSS INA/CSWR
> * 1 - CPUx L1 and logic lost: CPU OFF, MPUSS INA/CSWR
> * 2 - CPUx L1 and logic lost + GIC lost: MPUSS OSWR
> + * 3 - CPUx L1 and logic lost + GIC,L2 lost: MPU OSWR & L2 lost(debug only)
> */
> ENTRY(omap5_finish_suspend)
> stmfd sp!, {r4-r12, lr}
> @@ -391,6 +392,26 @@ skip_secure_l1_clean_op:
> isb
> dsb
>
> + bl omap4_get_sar_ram_base
> + mov r8, r0
> + mrc p15, 0, r5, c0, c0, 5 @ Read MPIDR
> + ands r5, r5, #0x0f
> + ldreq r0, [r8, #L2X0_SAVE_OFFSET0] @ Retrieve L2 state
> + ldrne r0, [r8, #L2X0_SAVE_OFFSET1]
> + cmp r0, #3
> + bne do_wfi
> + bl omap4_get_sar_ram_base
> + ldr r9, [r0, #OMAP_TYPE_OFFSET]
> + cmp r9, #0x1 @ Check for HS device
> + bne skip_secure_l2_clean_op
> + mov r0, #1 @ Clean secure L2
> + stmfd r13!, {r4-r12, r14}
> + ldr r12, =OMAP5_MON_CACHES_CLEAN_INDEX
> + DO_SMC
> + ldmfd r13!, {r4-r12, r14}
> +skip_secure_l2_clean_op:
> + bl v7_flush_dcache_all
> +
> do_wfi:
> bl omap_do_wfi
^ permalink raw reply [flat|nested] 128+ messages in thread
* [PATCH v2 11/18] ARM: OMAP5: PM: Add L2 memory power down support
@ 2013-04-03 20:58 ` Kevin Hilman
0 siblings, 0 replies; 128+ messages in thread
From: Kevin Hilman @ 2013-04-03 20:58 UTC (permalink / raw)
To: linux-arm-kernel
Santosh Shilimkar <santosh.shilimkar@ti.com> writes:
> When the entire MPUSS cluster is powered down in device off state, L2 cache
> memory looses it's content and hence while targetting such a state,
> l2 cache needs to be flushed to main memory.
>
> Add the necessary low power code support for the same.
>
> Acked-by: Nishanth Menon <nm@ti.com>
> Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
> ---
> arch/arm/mach-omap2/omap-secure.h | 1 +
> arch/arm/mach-omap2/sleep_omap4plus.S | 21 +++++++++++++++++++++
> 2 files changed, 22 insertions(+)
>
> diff --git a/arch/arm/mach-omap2/omap-secure.h b/arch/arm/mach-omap2/omap-secure.h
> index 1739468..a171a5a 100644
> --- a/arch/arm/mach-omap2/omap-secure.h
> +++ b/arch/arm/mach-omap2/omap-secure.h
> @@ -47,6 +47,7 @@
> #define OMAP4_MON_L2X0_PREFETCH_INDEX 0x113
> #define OMAP5_MON_CACHES_CLEAN_INDEX 0x103
> #define OMAP5_MON_AUX_CTRL_INDEX 0x107
> +#define OMAP5_MON_L2AUX_CTRL_INDEX 0x104
this #define is not used in this patch.
Kevin
> #define OMAP5_MON_AMBA_IF_INDEX 0x108
>
> diff --git a/arch/arm/mach-omap2/sleep_omap4plus.S b/arch/arm/mach-omap2/sleep_omap4plus.S
> index 4a5e2e4..288f62f 100644
> --- a/arch/arm/mach-omap2/sleep_omap4plus.S
> +++ b/arch/arm/mach-omap2/sleep_omap4plus.S
> @@ -337,6 +337,7 @@ ENDPROC(omap4_cpu_resume)
> * 0 - Nothing lost and no need to save: MPUSS INA/CSWR
> * 1 - CPUx L1 and logic lost: CPU OFF, MPUSS INA/CSWR
> * 2 - CPUx L1 and logic lost + GIC lost: MPUSS OSWR
> + * 3 - CPUx L1 and logic lost + GIC,L2 lost: MPU OSWR & L2 lost(debug only)
> */
> ENTRY(omap5_finish_suspend)
> stmfd sp!, {r4-r12, lr}
> @@ -391,6 +392,26 @@ skip_secure_l1_clean_op:
> isb
> dsb
>
> + bl omap4_get_sar_ram_base
> + mov r8, r0
> + mrc p15, 0, r5, c0, c0, 5 @ Read MPIDR
> + ands r5, r5, #0x0f
> + ldreq r0, [r8, #L2X0_SAVE_OFFSET0] @ Retrieve L2 state
> + ldrne r0, [r8, #L2X0_SAVE_OFFSET1]
> + cmp r0, #3
> + bne do_wfi
> + bl omap4_get_sar_ram_base
> + ldr r9, [r0, #OMAP_TYPE_OFFSET]
> + cmp r9, #0x1 @ Check for HS device
> + bne skip_secure_l2_clean_op
> + mov r0, #1 @ Clean secure L2
> + stmfd r13!, {r4-r12, r14}
> + ldr r12, =OMAP5_MON_CACHES_CLEAN_INDEX
> + DO_SMC
> + ldmfd r13!, {r4-r12, r14}
> +skip_secure_l2_clean_op:
> + bl v7_flush_dcache_all
> +
> do_wfi:
> bl omap_do_wfi
^ permalink raw reply [flat|nested] 128+ messages in thread
* Re: [PATCH v2 12/18] ARM: OMAP4: CPUidle: Avoid double idle driver registration
2013-03-25 10:05 ` Santosh Shilimkar
@ 2013-04-03 21:03 ` Kevin Hilman
-1 siblings, 0 replies; 128+ messages in thread
From: Kevin Hilman @ 2013-04-03 21:03 UTC (permalink / raw)
To: Santosh Shilimkar; +Cc: linux-omap, linux-arm-kernel, nm, tony
Santosh Shilimkar <santosh.shilimkar@ti.com> writes:
> OMAP4 CPUidle driver registration call is under a loop which leads
> to calling cpuidle_register_driver twice which is not intended.
>
> Fix it by moving the driver registration outside the loop.
>
> Reported-by: Nishanth Menon <nm@ti.com>
> Acked-by: Nishanth Menon <nm@ti.com>
> Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
Looks good.
I've already got a for_3.10/fixes/cpuidle branch going, so I'll apply
this one there.
Kevin
^ permalink raw reply [flat|nested] 128+ messages in thread
* [PATCH v2 12/18] ARM: OMAP4: CPUidle: Avoid double idle driver registration
@ 2013-04-03 21:03 ` Kevin Hilman
0 siblings, 0 replies; 128+ messages in thread
From: Kevin Hilman @ 2013-04-03 21:03 UTC (permalink / raw)
To: linux-arm-kernel
Santosh Shilimkar <santosh.shilimkar@ti.com> writes:
> OMAP4 CPUidle driver registration call is under a loop which leads
> to calling cpuidle_register_driver twice which is not intended.
>
> Fix it by moving the driver registration outside the loop.
>
> Reported-by: Nishanth Menon <nm@ti.com>
> Acked-by: Nishanth Menon <nm@ti.com>
> Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
Looks good.
I've already got a for_3.10/fixes/cpuidle branch going, so I'll apply
this one there.
Kevin
^ permalink raw reply [flat|nested] 128+ messages in thread
* Re: [PATCH v2 13/18] ARM: OMAP: CPUidle: Unregister drivere on device registration failure
2013-03-25 10:05 ` Santosh Shilimkar
@ 2013-04-03 21:03 ` Kevin Hilman
-1 siblings, 0 replies; 128+ messages in thread
From: Kevin Hilman @ 2013-04-03 21:03 UTC (permalink / raw)
To: Santosh Shilimkar; +Cc: linux-omap, linux-arm-kernel, nm, tony
Santosh Shilimkar <santosh.shilimkar@ti.com> writes:
> If the CPUidle device registration fails for some reason, we should
> unregister the driver on error path.
>
> Fix the code accordingly. Also when at it, check of the driver registration
> failure too.
>
> Acked-by: Nishanth Menon <nm@ti.com>
> Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
Adding to my for_3.10/fixes/cpuidle branch.
Kevin
^ permalink raw reply [flat|nested] 128+ messages in thread
* [PATCH v2 13/18] ARM: OMAP: CPUidle: Unregister drivere on device registration failure
@ 2013-04-03 21:03 ` Kevin Hilman
0 siblings, 0 replies; 128+ messages in thread
From: Kevin Hilman @ 2013-04-03 21:03 UTC (permalink / raw)
To: linux-arm-kernel
Santosh Shilimkar <santosh.shilimkar@ti.com> writes:
> If the CPUidle device registration fails for some reason, we should
> unregister the driver on error path.
>
> Fix the code accordingly. Also when at it, check of the driver registration
> failure too.
>
> Acked-by: Nishanth Menon <nm@ti.com>
> Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
Adding to my for_3.10/fixes/cpuidle branch.
Kevin
^ permalink raw reply [flat|nested] 128+ messages in thread
* Re: [PATCH v2 14/18] ARM: OMAP4: CPUidle: Make C-state description field more precise
2013-03-25 10:05 ` Santosh Shilimkar
@ 2013-04-03 21:05 ` Kevin Hilman
-1 siblings, 0 replies; 128+ messages in thread
From: Kevin Hilman @ 2013-04-03 21:05 UTC (permalink / raw)
To: Santosh Shilimkar; +Cc: linux-omap, linux-arm-kernel, nm, tony
Santosh Shilimkar <santosh.shilimkar@ti.com> writes:
> It is useful to know the CPU power state along with MPUSS power state
> in a supported C-state. Since the data is available via sysfs, one can
> avoid scrolling the source code for precise construction of C-state.
>
> Reported-by: Nishanth Menon <nm@ti.com>
> Acked-by: Nishanth Menon <nm@ti.com>
> Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
Nice.
Adding to for_3.10/fixes/cpuidle branch.
Kevin
^ permalink raw reply [flat|nested] 128+ messages in thread
* [PATCH v2 14/18] ARM: OMAP4: CPUidle: Make C-state description field more precise
@ 2013-04-03 21:05 ` Kevin Hilman
0 siblings, 0 replies; 128+ messages in thread
From: Kevin Hilman @ 2013-04-03 21:05 UTC (permalink / raw)
To: linux-arm-kernel
Santosh Shilimkar <santosh.shilimkar@ti.com> writes:
> It is useful to know the CPU power state along with MPUSS power state
> in a supported C-state. Since the data is available via sysfs, one can
> avoid scrolling the source code for precise construction of C-state.
>
> Reported-by: Nishanth Menon <nm@ti.com>
> Acked-by: Nishanth Menon <nm@ti.com>
> Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
Nice.
Adding to for_3.10/fixes/cpuidle branch.
Kevin
^ permalink raw reply [flat|nested] 128+ messages in thread
* Re: [PATCH v2 15/18] ARM: OMAP4+: CPUidle: Consolidate idle driver for OMAP5 support
2013-03-25 10:05 ` Santosh Shilimkar
@ 2013-04-03 21:10 ` Kevin Hilman
-1 siblings, 0 replies; 128+ messages in thread
From: Kevin Hilman @ 2013-04-03 21:10 UTC (permalink / raw)
To: Santosh Shilimkar; +Cc: linux-omap, linux-arm-kernel, nm, tony
Santosh Shilimkar <santosh.shilimkar@ti.com> writes:
> The OMAP5 idle driver can re-use most of OMAP4 CPUidle driver
> implementation. Also the next derivative SOCs are going to re-use
> the MPUSS so, same driver with minor updates can be re-used.
>
> Prepare the code so that its easier to add CPUidle support for
> OMAP5 devices.
>
> Acked-by: Nishanth Menon <nm@ti.com>
> Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
> ---
> arch/arm/mach-omap2/cpuidle44xx.c | 31 ++++++++++++++++---------------
> 1 file changed, 16 insertions(+), 15 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/cpuidle44xx.c b/arch/arm/mach-omap2/cpuidle44xx.c
> index b8a22f0..ac6d526 100644
> --- a/arch/arm/mach-omap2/cpuidle44xx.c
> +++ b/arch/arm/mach-omap2/cpuidle44xx.c
> @@ -1,7 +1,7 @@
> /*
> - * OMAP4 CPU idle Routines
> + * OMAP4PLUS CPU idle Routines
nit: s/PLUS/+/
in a few other places in this patch also.
> *
> - * Copyright (C) 2011 Texas Instruments, Inc.
> + * Copyright (C) 2011-2013 Texas Instruments, Inc.
> * Santosh Shilimkar <santosh.shilimkar@ti.com>
> * Rajendra Nayak <rnayak@ti.com>
> *
> @@ -24,13 +24,13 @@
> #include "clockdomain.h"
>
> /* Machine specific information */
> -struct omap4_idle_statedata {
> +struct idle_statedata {
> u32 cpu_state;
> u32 mpu_logic_state;
> u32 mpu_state;
> };
>
> -static struct omap4_idle_statedata omap4_idle_data[] = {
> +static struct idle_statedata omap4_idle_data[] = {
> {
> .cpu_state = PWRDM_POWER_ON,
> .mpu_state = PWRDM_POWER_ON,
> @@ -53,11 +53,12 @@ static struct clockdomain *cpu_clkdm[NR_CPUS];
>
> static atomic_t abort_barrier;
> static bool cpu_done[NR_CPUS];
> +static struct idle_statedata *state_ptr = &omap4_idle_data[0];
The assignment at init time (from the next patch) should be done here
for 44xx, and the next patch can just add OMAP5 support.
Kevin
^ permalink raw reply [flat|nested] 128+ messages in thread
* [PATCH v2 15/18] ARM: OMAP4+: CPUidle: Consolidate idle driver for OMAP5 support
@ 2013-04-03 21:10 ` Kevin Hilman
0 siblings, 0 replies; 128+ messages in thread
From: Kevin Hilman @ 2013-04-03 21:10 UTC (permalink / raw)
To: linux-arm-kernel
Santosh Shilimkar <santosh.shilimkar@ti.com> writes:
> The OMAP5 idle driver can re-use most of OMAP4 CPUidle driver
> implementation. Also the next derivative SOCs are going to re-use
> the MPUSS so, same driver with minor updates can be re-used.
>
> Prepare the code so that its easier to add CPUidle support for
> OMAP5 devices.
>
> Acked-by: Nishanth Menon <nm@ti.com>
> Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
> ---
> arch/arm/mach-omap2/cpuidle44xx.c | 31 ++++++++++++++++---------------
> 1 file changed, 16 insertions(+), 15 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/cpuidle44xx.c b/arch/arm/mach-omap2/cpuidle44xx.c
> index b8a22f0..ac6d526 100644
> --- a/arch/arm/mach-omap2/cpuidle44xx.c
> +++ b/arch/arm/mach-omap2/cpuidle44xx.c
> @@ -1,7 +1,7 @@
> /*
> - * OMAP4 CPU idle Routines
> + * OMAP4PLUS CPU idle Routines
nit: s/PLUS/+/
in a few other places in this patch also.
> *
> - * Copyright (C) 2011 Texas Instruments, Inc.
> + * Copyright (C) 2011-2013 Texas Instruments, Inc.
> * Santosh Shilimkar <santosh.shilimkar@ti.com>
> * Rajendra Nayak <rnayak@ti.com>
> *
> @@ -24,13 +24,13 @@
> #include "clockdomain.h"
>
> /* Machine specific information */
> -struct omap4_idle_statedata {
> +struct idle_statedata {
> u32 cpu_state;
> u32 mpu_logic_state;
> u32 mpu_state;
> };
>
> -static struct omap4_idle_statedata omap4_idle_data[] = {
> +static struct idle_statedata omap4_idle_data[] = {
> {
> .cpu_state = PWRDM_POWER_ON,
> .mpu_state = PWRDM_POWER_ON,
> @@ -53,11 +53,12 @@ static struct clockdomain *cpu_clkdm[NR_CPUS];
>
> static atomic_t abort_barrier;
> static bool cpu_done[NR_CPUS];
> +static struct idle_statedata *state_ptr = &omap4_idle_data[0];
The assignment at init time (from the next patch) should be done here
for 44xx, and the next patch can just add OMAP5 support.
Kevin
^ permalink raw reply [flat|nested] 128+ messages in thread
* Re: [PATCH v2 17/18] ARM: OMAP4+: CPUidle: Add OMAP5 idle driver support
2013-03-25 10:05 ` Santosh Shilimkar
@ 2013-04-03 21:25 ` Kevin Hilman
-1 siblings, 0 replies; 128+ messages in thread
From: Kevin Hilman @ 2013-04-03 21:25 UTC (permalink / raw)
To: Santosh Shilimkar; +Cc: linux-omap, linux-arm-kernel, nm, tony
Santosh Shilimkar <santosh.shilimkar@ti.com> writes:
> The OMAP5 idle driver can re-use OMAP4 CPUidle driver implementation thanks
> to compatible MPUSS design.
>
> Though unlike OMAP4, on OMAP5 devices, MPUSS CSWR (Close Switch
> Retention) power states can be achieved with respective power states
> on CPU0 and CPU1 power domain. This mode was broken on OMAP4 devices
> because of hardware limitation.
I'm a bit confused by the description here.
I gather from the code that this means that CPU0 and CPU1 can hit CSWR
independently, correct?
> Also there is no CPU low power entry order requirement like
> master CPU etc for CSWR C-state, which is icing on the cake.
Even on secure devices?
> Code makes use of voting scheme for cluster low power state to support
> MPUSS CSWR C-state.
The voting scheme and associated locking should be better described
here, or commented in the code itself.
> Supported OMAP5 CPUidle C-states:
> C1 - CPU0 ON(WFI) + CPU1 ON(WFI) + MPUSS ON
> C2 - CPU0 CSWR + CPU1 CSWR + MPUSS CSWR
> C3 - CPU0 OFF + CPU1 OFF + MPUSS OSWR
>
> Acked-by: Nishanth Menon <nm@ti.com>
> Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
[...]
> +static int omap_enter_idle_smp(struct cpuidle_device *dev,
> + struct cpuidle_driver *drv,
> + int index)
> +{
> + struct idle_statedata *cx = state_ptr + index;
> + int cpu_id = smp_processor_id();
> + unsigned long flag;
> +
> + clockevents_notify(CLOCK_EVT_NOTIFY_BROADCAST_ENTER, &cpu_id);
I think the CPUidle core handles the broadcast notification now.
> + raw_spin_lock_irqsave(&mpu_lock, flag);
> + cx->mpu_state_vote++;
How about using an atomic_t and atomic_inc()/atomic_dec() instead, which
will avoid the need for a spinlock.
Even with that, it still seems potentially racy. Do you need a memory
barrier here to be sure that any changes from another CPU are visible
here, and vice versa?
> + if (cx->mpu_state_vote == num_online_cpus()) {
> + pwrdm_set_logic_retst(mpu_pd, cx->mpu_logic_state);
> + omap_set_pwrdm_state(mpu_pd, cx->mpu_state);
> + }
> + raw_spin_unlock_irqrestore(&mpu_lock, flag);
> +
> + omap4_enter_lowpower(dev->cpu, cx->cpu_state);
> +
> + raw_spin_lock_irqsave(&mpu_lock, flag);
> + if (cx->mpu_state_vote == num_online_cpus())
> + omap_set_pwrdm_state(mpu_pd, PWRDM_POWER_ON);
> + cx->mpu_state_vote--;
> + raw_spin_unlock_irqrestore(&mpu_lock, flag);
> +
> + clockevents_notify(CLOCK_EVT_NOTIFY_BROADCAST_EXIT, &cpu_id);
> +
> + return index;
> +}
Kevin
^ permalink raw reply [flat|nested] 128+ messages in thread
* [PATCH v2 17/18] ARM: OMAP4+: CPUidle: Add OMAP5 idle driver support
@ 2013-04-03 21:25 ` Kevin Hilman
0 siblings, 0 replies; 128+ messages in thread
From: Kevin Hilman @ 2013-04-03 21:25 UTC (permalink / raw)
To: linux-arm-kernel
Santosh Shilimkar <santosh.shilimkar@ti.com> writes:
> The OMAP5 idle driver can re-use OMAP4 CPUidle driver implementation thanks
> to compatible MPUSS design.
>
> Though unlike OMAP4, on OMAP5 devices, MPUSS CSWR (Close Switch
> Retention) power states can be achieved with respective power states
> on CPU0 and CPU1 power domain. This mode was broken on OMAP4 devices
> because of hardware limitation.
I'm a bit confused by the description here.
I gather from the code that this means that CPU0 and CPU1 can hit CSWR
independently, correct?
> Also there is no CPU low power entry order requirement like
> master CPU etc for CSWR C-state, which is icing on the cake.
Even on secure devices?
> Code makes use of voting scheme for cluster low power state to support
> MPUSS CSWR C-state.
The voting scheme and associated locking should be better described
here, or commented in the code itself.
> Supported OMAP5 CPUidle C-states:
> C1 - CPU0 ON(WFI) + CPU1 ON(WFI) + MPUSS ON
> C2 - CPU0 CSWR + CPU1 CSWR + MPUSS CSWR
> C3 - CPU0 OFF + CPU1 OFF + MPUSS OSWR
>
> Acked-by: Nishanth Menon <nm@ti.com>
> Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
[...]
> +static int omap_enter_idle_smp(struct cpuidle_device *dev,
> + struct cpuidle_driver *drv,
> + int index)
> +{
> + struct idle_statedata *cx = state_ptr + index;
> + int cpu_id = smp_processor_id();
> + unsigned long flag;
> +
> + clockevents_notify(CLOCK_EVT_NOTIFY_BROADCAST_ENTER, &cpu_id);
I think the CPUidle core handles the broadcast notification now.
> + raw_spin_lock_irqsave(&mpu_lock, flag);
> + cx->mpu_state_vote++;
How about using an atomic_t and atomic_inc()/atomic_dec() instead, which
will avoid the need for a spinlock.
Even with that, it still seems potentially racy. Do you need a memory
barrier here to be sure that any changes from another CPU are visible
here, and vice versa?
> + if (cx->mpu_state_vote == num_online_cpus()) {
> + pwrdm_set_logic_retst(mpu_pd, cx->mpu_logic_state);
> + omap_set_pwrdm_state(mpu_pd, cx->mpu_state);
> + }
> + raw_spin_unlock_irqrestore(&mpu_lock, flag);
> +
> + omap4_enter_lowpower(dev->cpu, cx->cpu_state);
> +
> + raw_spin_lock_irqsave(&mpu_lock, flag);
> + if (cx->mpu_state_vote == num_online_cpus())
> + omap_set_pwrdm_state(mpu_pd, PWRDM_POWER_ON);
> + cx->mpu_state_vote--;
> + raw_spin_unlock_irqrestore(&mpu_lock, flag);
> +
> + clockevents_notify(CLOCK_EVT_NOTIFY_BROADCAST_EXIT, &cpu_id);
> +
> + return index;
> +}
Kevin
^ permalink raw reply [flat|nested] 128+ messages in thread
* Re: [PATCH v2 16/18] ARM: OMAP4+: CPUidle: Deprecate use of omap4_mpuss_read_prev_context_state()
2013-03-25 10:05 ` Santosh Shilimkar
@ 2013-04-03 21:37 ` Kevin Hilman
-1 siblings, 0 replies; 128+ messages in thread
From: Kevin Hilman @ 2013-04-03 21:37 UTC (permalink / raw)
To: Santosh Shilimkar; +Cc: linux-omap, linux-arm-kernel, nm, tony
Santosh Shilimkar <santosh.shilimkar@ti.com> writes:
> Current OMAP4 CPUIdle driver is using omap4_mpuss_read_prev_context_state()
> function to check whether the MPU cluster lost context or not. Thanks to
> couple CPUIdle, cluster low power entry is almost guaranteed and hence
> the programmed cluster check is enough in idle exit path. The API was
> more of an optimization for corner cases, where if the cluster low power
> entry fails for some reason, the cluster context restore gets skipped.
>
> Moving forward, OMAP CPUidle drivers needs to be moved to drivers/idle/*
> once the PRM/CM code gets moved to drivers. This patch also reduces one
> dependency with platform code for idle driver movement.
>
> Acked-by: Nishanth Menon <nm@ti.com>
> Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
Looks good, but I find the changelog a bit confusing.
Below is a slightly modified patch (I only modified the changelog). If
those changes are OK with you, I'll add it to my cpuidle branch as well.
Kevin
>From c01794dc249f826f0714578f26ff9efd35ea6296 Mon Sep 17 00:00:00 2001
From: Santosh Shilimkar <santosh.shilimkar@ti.com>
Date: Mon, 25 Mar 2013 15:35:08 +0530
Subject: [PATCH] ARM: OMAP4+: CPUidle: Deprecate use of
omap4_mpuss_read_prev_context_state()
Current OMAP4 CPUIdle driver is using omap4_mpuss_read_prev_context_state()
to check whether the MPU cluster lost context or not before calling
cpu_cluster_pm_exit(). This was initially done an optimization for
corner cases, where if the cluster low power entry fails for some
reason, the cluster context restore gets skipped. However, since
reading the previous context is expensive (involving slow accesses to
the PRCM), it's better to avoid it and simply check the target cluster
state instead.
Moving forward, OMAP CPUidle drivers needs to be moved to drivers/idle/*
once the PRM/CM code gets moved to drivers. This patch also reduces one
dependency with platform code for idle driver movement.
Acked-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
[khilman@linaro.org: minor changelog edits]
Signed-off-by: Kevin Hilman <khilman@linaro.org>
---
arch/arm/mach-omap2/common.h | 5 -----
arch/arm/mach-omap2/cpuidle44xx.c | 3 ++-
arch/arm/mach-omap2/omap-mpuss-lowpower.c | 14 --------------
3 files changed, 2 insertions(+), 20 deletions(-)
diff --git a/arch/arm/mach-omap2/common.h b/arch/arm/mach-omap2/common.h
index 40f4a03..f5c9983 100644
--- a/arch/arm/mach-omap2/common.h
+++ b/arch/arm/mach-omap2/common.h
@@ -249,7 +249,6 @@ extern int omap4_enter_lowpower(unsigned int cpu, unsigned int power_state);
extern int omap4_finish_suspend(unsigned long cpu_state);
extern void omap4_cpu_resume(void);
extern int omap4_hotplug_cpu(unsigned int cpu, unsigned int power_state);
-extern u32 omap4_mpuss_read_prev_context_state(void);
#else
static inline int omap4_enter_lowpower(unsigned int cpu,
unsigned int power_state)
@@ -277,10 +276,6 @@ static inline int omap4_finish_suspend(unsigned long cpu_state)
static inline void omap4_cpu_resume(void)
{}
-static inline u32 omap4_mpuss_read_prev_context_state(void)
-{
- return 0;
-}
#endif
struct omap_sdrc_params;
diff --git a/arch/arm/mach-omap2/cpuidle44xx.c b/arch/arm/mach-omap2/cpuidle44xx.c
index 354517a..3cad103 100644
--- a/arch/arm/mach-omap2/cpuidle44xx.c
+++ b/arch/arm/mach-omap2/cpuidle44xx.c
@@ -149,7 +149,8 @@ static int omap4_enter_idle_coupled(struct cpuidle_device *dev,
* Call idle CPU cluster PM exit notifier chain
* to restore GIC and wakeupgen context.
*/
- if (omap4_mpuss_read_prev_context_state())
+ if ((cx->mpu_state == PWRDM_POWER_RET) &&
+ (cx->mpu_logic_state == PWRDM_POWER_OFF))
cpu_cluster_pm_exit();
clockevents_notify(CLOCK_EVT_NOTIFY_BROADCAST_EXIT, &cpu_id);
diff --git a/arch/arm/mach-omap2/omap-mpuss-lowpower.c b/arch/arm/mach-omap2/omap-mpuss-lowpower.c
index 8bcb64b..e80327b 100644
--- a/arch/arm/mach-omap2/omap-mpuss-lowpower.c
+++ b/arch/arm/mach-omap2/omap-mpuss-lowpower.c
@@ -139,20 +139,6 @@ static inline void cpu_clear_prev_logic_pwrst(unsigned int cpu_id)
}
}
-/**
- * omap4_mpuss_read_prev_context_state:
- * Function returns the MPUSS previous context state
- */
-u32 omap4_mpuss_read_prev_context_state(void)
-{
- u32 reg;
-
- reg = omap4_prminst_read_inst_reg(OMAP4430_PRM_PARTITION,
- OMAP4430_PRM_MPU_INST, OMAP4_RM_MPU_MPU_CONTEXT_OFFSET);
- reg &= OMAP4430_LOSTCONTEXT_DFF_MASK;
- return reg;
-}
-
/*
* Store the CPU cluster state for L2X0 low power operations.
*/
--
1.8.2
^ permalink raw reply related [flat|nested] 128+ messages in thread
* [PATCH v2 16/18] ARM: OMAP4+: CPUidle: Deprecate use of omap4_mpuss_read_prev_context_state()
@ 2013-04-03 21:37 ` Kevin Hilman
0 siblings, 0 replies; 128+ messages in thread
From: Kevin Hilman @ 2013-04-03 21:37 UTC (permalink / raw)
To: linux-arm-kernel
Santosh Shilimkar <santosh.shilimkar@ti.com> writes:
> Current OMAP4 CPUIdle driver is using omap4_mpuss_read_prev_context_state()
> function to check whether the MPU cluster lost context or not. Thanks to
> couple CPUIdle, cluster low power entry is almost guaranteed and hence
> the programmed cluster check is enough in idle exit path. The API was
> more of an optimization for corner cases, where if the cluster low power
> entry fails for some reason, the cluster context restore gets skipped.
>
> Moving forward, OMAP CPUidle drivers needs to be moved to drivers/idle/*
> once the PRM/CM code gets moved to drivers. This patch also reduces one
> dependency with platform code for idle driver movement.
>
> Acked-by: Nishanth Menon <nm@ti.com>
> Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
Looks good, but I find the changelog a bit confusing.
Below is a slightly modified patch (I only modified the changelog). If
those changes are OK with you, I'll add it to my cpuidle branch as well.
Kevin
>From c01794dc249f826f0714578f26ff9efd35ea6296 Mon Sep 17 00:00:00 2001
From: Santosh Shilimkar <santosh.shilimkar@ti.com>
Date: Mon, 25 Mar 2013 15:35:08 +0530
Subject: [PATCH] ARM: OMAP4+: CPUidle: Deprecate use of
omap4_mpuss_read_prev_context_state()
Current OMAP4 CPUIdle driver is using omap4_mpuss_read_prev_context_state()
to check whether the MPU cluster lost context or not before calling
cpu_cluster_pm_exit(). This was initially done an optimization for
corner cases, where if the cluster low power entry fails for some
reason, the cluster context restore gets skipped. However, since
reading the previous context is expensive (involving slow accesses to
the PRCM), it's better to avoid it and simply check the target cluster
state instead.
Moving forward, OMAP CPUidle drivers needs to be moved to drivers/idle/*
once the PRM/CM code gets moved to drivers. This patch also reduces one
dependency with platform code for idle driver movement.
Acked-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
[khilman at linaro.org: minor changelog edits]
Signed-off-by: Kevin Hilman <khilman@linaro.org>
---
arch/arm/mach-omap2/common.h | 5 -----
arch/arm/mach-omap2/cpuidle44xx.c | 3 ++-
arch/arm/mach-omap2/omap-mpuss-lowpower.c | 14 --------------
3 files changed, 2 insertions(+), 20 deletions(-)
diff --git a/arch/arm/mach-omap2/common.h b/arch/arm/mach-omap2/common.h
index 40f4a03..f5c9983 100644
--- a/arch/arm/mach-omap2/common.h
+++ b/arch/arm/mach-omap2/common.h
@@ -249,7 +249,6 @@ extern int omap4_enter_lowpower(unsigned int cpu, unsigned int power_state);
extern int omap4_finish_suspend(unsigned long cpu_state);
extern void omap4_cpu_resume(void);
extern int omap4_hotplug_cpu(unsigned int cpu, unsigned int power_state);
-extern u32 omap4_mpuss_read_prev_context_state(void);
#else
static inline int omap4_enter_lowpower(unsigned int cpu,
unsigned int power_state)
@@ -277,10 +276,6 @@ static inline int omap4_finish_suspend(unsigned long cpu_state)
static inline void omap4_cpu_resume(void)
{}
-static inline u32 omap4_mpuss_read_prev_context_state(void)
-{
- return 0;
-}
#endif
struct omap_sdrc_params;
diff --git a/arch/arm/mach-omap2/cpuidle44xx.c b/arch/arm/mach-omap2/cpuidle44xx.c
index 354517a..3cad103 100644
--- a/arch/arm/mach-omap2/cpuidle44xx.c
+++ b/arch/arm/mach-omap2/cpuidle44xx.c
@@ -149,7 +149,8 @@ static int omap4_enter_idle_coupled(struct cpuidle_device *dev,
* Call idle CPU cluster PM exit notifier chain
* to restore GIC and wakeupgen context.
*/
- if (omap4_mpuss_read_prev_context_state())
+ if ((cx->mpu_state == PWRDM_POWER_RET) &&
+ (cx->mpu_logic_state == PWRDM_POWER_OFF))
cpu_cluster_pm_exit();
clockevents_notify(CLOCK_EVT_NOTIFY_BROADCAST_EXIT, &cpu_id);
diff --git a/arch/arm/mach-omap2/omap-mpuss-lowpower.c b/arch/arm/mach-omap2/omap-mpuss-lowpower.c
index 8bcb64b..e80327b 100644
--- a/arch/arm/mach-omap2/omap-mpuss-lowpower.c
+++ b/arch/arm/mach-omap2/omap-mpuss-lowpower.c
@@ -139,20 +139,6 @@ static inline void cpu_clear_prev_logic_pwrst(unsigned int cpu_id)
}
}
-/**
- * omap4_mpuss_read_prev_context_state:
- * Function returns the MPUSS previous context state
- */
-u32 omap4_mpuss_read_prev_context_state(void)
-{
- u32 reg;
-
- reg = omap4_prminst_read_inst_reg(OMAP4430_PRM_PARTITION,
- OMAP4430_PRM_MPU_INST, OMAP4_RM_MPU_MPU_CONTEXT_OFFSET);
- reg &= OMAP4430_LOSTCONTEXT_DFF_MASK;
- return reg;
-}
-
/*
* Store the CPU cluster state for L2X0 low power operations.
*/
--
1.8.2
^ permalink raw reply related [flat|nested] 128+ messages in thread
* Re: [PATCH v2 00/18] ARM: OMAP5: PM: Add MPUSS suspend and CPUidle support
2013-03-25 10:04 ` Santosh Shilimkar
@ 2013-04-03 22:52 ` Kevin Hilman
-1 siblings, 0 replies; 128+ messages in thread
From: Kevin Hilman @ 2013-04-03 22:52 UTC (permalink / raw)
To: Santosh Shilimkar; +Cc: linux-omap, linux-arm-kernel, nm, tony
Hi Santosh,
Santosh Shilimkar <santosh.shilimkar@ti.com> writes:
> Here is the refreshed version(v2) of the OMAP5 PM suspport which was posted
> earlier (March 1st 2013). Patch-set incorporates comments from Nishant
> Menon (Thanks for review NM) and his acked-by tags. I would like to get this
> queued for 3.10 merge window if you are ok with the series.
I did a review of this series with several comments on the individual
patches.
I've already queued most of the CPUidle fixes/cleanups in my
for_3.10/cleanup/cpuidle branch and will get that to Tony soon. For the
rest, I suggest probably breaking it up into cleanup/consolidation stuff
and then OMAP5 support. The latter will depend on all the OMAP5
data/headers but the cleanup/consolidation stuff could be merged sooner
(but probably a bit late for v3.10 now.)
Kevin
^ permalink raw reply [flat|nested] 128+ messages in thread
* [PATCH v2 00/18] ARM: OMAP5: PM: Add MPUSS suspend and CPUidle support
@ 2013-04-03 22:52 ` Kevin Hilman
0 siblings, 0 replies; 128+ messages in thread
From: Kevin Hilman @ 2013-04-03 22:52 UTC (permalink / raw)
To: linux-arm-kernel
Hi Santosh,
Santosh Shilimkar <santosh.shilimkar@ti.com> writes:
> Here is the refreshed version(v2) of the OMAP5 PM suspport which was posted
> earlier (March 1st 2013). Patch-set incorporates comments from Nishant
> Menon (Thanks for review NM) and his acked-by tags. I would like to get this
> queued for 3.10 merge window if you are ok with the series.
I did a review of this series with several comments on the individual
patches.
I've already queued most of the CPUidle fixes/cleanups in my
for_3.10/cleanup/cpuidle branch and will get that to Tony soon. For the
rest, I suggest probably breaking it up into cleanup/consolidation stuff
and then OMAP5 support. The latter will depend on all the OMAP5
data/headers but the cleanup/consolidation stuff could be merged sooner
(but probably a bit late for v3.10 now.)
Kevin
^ permalink raw reply [flat|nested] 128+ messages in thread
* Re: [PATCH v2 01/18] ARM: OMAP4+: PM: Consolidate MPU subsystem PM code for re-use
2013-04-03 19:44 ` Kevin Hilman
@ 2013-04-04 11:32 ` Santosh Shilimkar
-1 siblings, 0 replies; 128+ messages in thread
From: Santosh Shilimkar @ 2013-04-04 11:32 UTC (permalink / raw)
To: Kevin Hilman; +Cc: linux-omap, linux-arm-kernel, nm, tony
On Thursday 04 April 2013 01:14 AM, Kevin Hilman wrote:
> Hi Santosh,
>
> Santosh Shilimkar <santosh.shilimkar@ti.com> writes:
>
>> OMAP5 and future OMAP based SOCs has backward compatible MPUSS
>> IP block with OMAP4. It's programming model is mostly similar.
>> Hence consolidate the OMAP MPUSS code so that it can be re-used
>> on OMAP5 and future SOCs.
>>
>> No functional change.
>>
>> Acked-by: Nishanth Menon <nm@ti.com>
>> Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
>> ---
>> arch/arm/mach-omap2/omap-mpuss-lowpower.c | 65 ++++++++++++++++++++++++-----
>> 1 file changed, 54 insertions(+), 11 deletions(-)
>>
>> diff --git a/arch/arm/mach-omap2/omap-mpuss-lowpower.c b/arch/arm/mach-omap2/omap-mpuss-lowpower.c
>> index d650f91..d9e4843 100644
>> --- a/arch/arm/mach-omap2/omap-mpuss-lowpower.c
>> +++ b/arch/arm/mach-omap2/omap-mpuss-lowpower.c
>> @@ -71,10 +71,46 @@ struct omap4_cpu_pm_info {
>> void (*secondary_startup)(void);
>> };
>>
>> +/**
>> + * struct cpu_pm_ops - CPU pm operations
>> + * @finish_suspend: CPU suspend finisher function pointer
>> + * @resume: CPU resume function pointer
>> + * @scu_prepare: CPU Snoop Control program function pointer
>> + *
>> + * Structure holds functions pointer for CPU low power operations like
>> + * suspend, resume and scu programming.
>> + */
>> +struct cpu_pm_ops {
>> + int (*finish_suspend)(unsigned long cpu_state);
>> + void (*resume)(void);
>> + void (*scu_prepare)(unsigned int cpu_id, unsigned int cpu_state);
>> +};
>> +
>> +extern int omap4_finish_suspend(unsigned long cpu_state);
>> +extern void omap4_cpu_resume(void);
>
> checkpatch should've yelled at you for adding externs to .c files.
>
It does. I didn't see they were already in header file and considering
they were shared between asm and mpuss file, I just kept it that way.
i have seen many places in kernel for asm exports, this is being used
and hence kept it.
> Also, aren't these already defined in common.h anyways?
>
Yep. I will just drop above hunk.
> Otherwise, patch looks fine.
>
I will take that as an ack then ?
Regards,
Santosh
^ permalink raw reply [flat|nested] 128+ messages in thread
* [PATCH v2 01/18] ARM: OMAP4+: PM: Consolidate MPU subsystem PM code for re-use
@ 2013-04-04 11:32 ` Santosh Shilimkar
0 siblings, 0 replies; 128+ messages in thread
From: Santosh Shilimkar @ 2013-04-04 11:32 UTC (permalink / raw)
To: linux-arm-kernel
On Thursday 04 April 2013 01:14 AM, Kevin Hilman wrote:
> Hi Santosh,
>
> Santosh Shilimkar <santosh.shilimkar@ti.com> writes:
>
>> OMAP5 and future OMAP based SOCs has backward compatible MPUSS
>> IP block with OMAP4. It's programming model is mostly similar.
>> Hence consolidate the OMAP MPUSS code so that it can be re-used
>> on OMAP5 and future SOCs.
>>
>> No functional change.
>>
>> Acked-by: Nishanth Menon <nm@ti.com>
>> Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
>> ---
>> arch/arm/mach-omap2/omap-mpuss-lowpower.c | 65 ++++++++++++++++++++++++-----
>> 1 file changed, 54 insertions(+), 11 deletions(-)
>>
>> diff --git a/arch/arm/mach-omap2/omap-mpuss-lowpower.c b/arch/arm/mach-omap2/omap-mpuss-lowpower.c
>> index d650f91..d9e4843 100644
>> --- a/arch/arm/mach-omap2/omap-mpuss-lowpower.c
>> +++ b/arch/arm/mach-omap2/omap-mpuss-lowpower.c
>> @@ -71,10 +71,46 @@ struct omap4_cpu_pm_info {
>> void (*secondary_startup)(void);
>> };
>>
>> +/**
>> + * struct cpu_pm_ops - CPU pm operations
>> + * @finish_suspend: CPU suspend finisher function pointer
>> + * @resume: CPU resume function pointer
>> + * @scu_prepare: CPU Snoop Control program function pointer
>> + *
>> + * Structure holds functions pointer for CPU low power operations like
>> + * suspend, resume and scu programming.
>> + */
>> +struct cpu_pm_ops {
>> + int (*finish_suspend)(unsigned long cpu_state);
>> + void (*resume)(void);
>> + void (*scu_prepare)(unsigned int cpu_id, unsigned int cpu_state);
>> +};
>> +
>> +extern int omap4_finish_suspend(unsigned long cpu_state);
>> +extern void omap4_cpu_resume(void);
>
> checkpatch should've yelled at you for adding externs to .c files.
>
It does. I didn't see they were already in header file and considering
they were shared between asm and mpuss file, I just kept it that way.
i have seen many places in kernel for asm exports, this is being used
and hence kept it.
> Also, aren't these already defined in common.h anyways?
>
Yep. I will just drop above hunk.
> Otherwise, patch looks fine.
>
I will take that as an ack then ?
Regards,
Santosh
^ permalink raw reply [flat|nested] 128+ messages in thread
* Re: [PATCH v2 03/18] ARM: OMAP4+: PM: Consolidate and use OMAP4 PM code for OMAP5
2013-04-03 20:20 ` Kevin Hilman
@ 2013-04-04 11:51 ` Santosh Shilimkar
-1 siblings, 0 replies; 128+ messages in thread
From: Santosh Shilimkar @ 2013-04-04 11:51 UTC (permalink / raw)
To: Kevin Hilman; +Cc: linux-omap, linux-arm-kernel, nm, tony
On Thursday 04 April 2013 01:50 AM, Kevin Hilman wrote:
> Santosh Shilimkar <santosh.shilimkar@ti.com> writes:
>
>> OMAP5 has backward compatible PRCM block and it's programming
>> model is mostly similar to OMAP4. Same is going to be maintained
>> for future OMAP4 based SOCs. Hence consolidate the OMAP4 power
>> management code so that it can be re-used on OMAP5 and later devices.
>>
>> With consolidated code, let basic power management code build
>> for OMAP5 devices. While at it, update the kernel-doc for omap4_pm_init().
>>
>> Acked-by: Nishanth Menon <nm@ti.com>
>> Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
>> ---
>> arch/arm/mach-omap2/Makefile | 9 ++--
>> arch/arm/mach-omap2/{pm44xx.c => pm_omap4plus.c} | 54 ++++++++++++++++----
>> .../mach-omap2/{sleep44xx.S => sleep_omap4plus.S} | 0
>> 3 files changed, 49 insertions(+), 14 deletions(-)
>> rename arch/arm/mach-omap2/{pm44xx.c => pm_omap4plus.c} (86%)
>> rename arch/arm/mach-omap2/{sleep44xx.S => sleep_omap4plus.S} (100%)
>>
[..]
>> diff --git a/arch/arm/mach-omap2/pm44xx.c b/arch/arm/mach-omap2/pm_omap4plus.c
>> similarity index 86%
>> rename from arch/arm/mach-omap2/pm44xx.c
>> rename to arch/arm/mach-omap2/pm_omap4plus.c
>> index 5ba6d88..e920c34 100644
>> --- a/arch/arm/mach-omap2/pm44xx.c
>> +++ b/arch/arm/mach-omap2/pm_omap4plus.c
>> @@ -1,7 +1,7 @@
>> /*
>> - * OMAP4 Power Management Routines
>> + * OMAP4PLUS Power Management Routines
>
> nit: OMAP4+ (you only need to spell out "plus" in the filename.
>
OK. I will replace '+' instead of 'PLUS' in rest of the places.
>> *
>> - * Copyright (C) 2010-2011 Texas Instruments, Inc.
>> + * Copyright (C) 2010-2013 Texas Instruments, Inc.
>> * Rajendra Nayak <rnayak@ti.com>
>> * Santosh Shilimkar <santosh.shilimkar@ti.com>
>> *
>> @@ -135,16 +135,16 @@ static void omap_default_idle(void)
>> }
>>
>> /**
>> - * omap4_pm_init - Init routine for OMAP4 PM
>> + * omap4_init_static_deps - Add OMAP4 static dependencies
>> *
>> - * Initializes all powerdomain and clockdomain target states
>> - * and all PRCM settings.
>> + * Add needed static clockdomain dependencies on OMAP4 devices.
>> + * Return: 0 on success or 'err' on failures
>> */
>> -int __init omap4_pm_init(void)
>> +static inline int omap4_init_static_deps(void)
>
> You dropped the __init here, but it's still only called from another
> __init function, so I suspect it should stay.
>
Yep. Will keep that in next version.
Regards,
Santosh
^ permalink raw reply [flat|nested] 128+ messages in thread
* [PATCH v2 03/18] ARM: OMAP4+: PM: Consolidate and use OMAP4 PM code for OMAP5
@ 2013-04-04 11:51 ` Santosh Shilimkar
0 siblings, 0 replies; 128+ messages in thread
From: Santosh Shilimkar @ 2013-04-04 11:51 UTC (permalink / raw)
To: linux-arm-kernel
On Thursday 04 April 2013 01:50 AM, Kevin Hilman wrote:
> Santosh Shilimkar <santosh.shilimkar@ti.com> writes:
>
>> OMAP5 has backward compatible PRCM block and it's programming
>> model is mostly similar to OMAP4. Same is going to be maintained
>> for future OMAP4 based SOCs. Hence consolidate the OMAP4 power
>> management code so that it can be re-used on OMAP5 and later devices.
>>
>> With consolidated code, let basic power management code build
>> for OMAP5 devices. While at it, update the kernel-doc for omap4_pm_init().
>>
>> Acked-by: Nishanth Menon <nm@ti.com>
>> Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
>> ---
>> arch/arm/mach-omap2/Makefile | 9 ++--
>> arch/arm/mach-omap2/{pm44xx.c => pm_omap4plus.c} | 54 ++++++++++++++++----
>> .../mach-omap2/{sleep44xx.S => sleep_omap4plus.S} | 0
>> 3 files changed, 49 insertions(+), 14 deletions(-)
>> rename arch/arm/mach-omap2/{pm44xx.c => pm_omap4plus.c} (86%)
>> rename arch/arm/mach-omap2/{sleep44xx.S => sleep_omap4plus.S} (100%)
>>
[..]
>> diff --git a/arch/arm/mach-omap2/pm44xx.c b/arch/arm/mach-omap2/pm_omap4plus.c
>> similarity index 86%
>> rename from arch/arm/mach-omap2/pm44xx.c
>> rename to arch/arm/mach-omap2/pm_omap4plus.c
>> index 5ba6d88..e920c34 100644
>> --- a/arch/arm/mach-omap2/pm44xx.c
>> +++ b/arch/arm/mach-omap2/pm_omap4plus.c
>> @@ -1,7 +1,7 @@
>> /*
>> - * OMAP4 Power Management Routines
>> + * OMAP4PLUS Power Management Routines
>
> nit: OMAP4+ (you only need to spell out "plus" in the filename.
>
OK. I will replace '+' instead of 'PLUS' in rest of the places.
>> *
>> - * Copyright (C) 2010-2011 Texas Instruments, Inc.
>> + * Copyright (C) 2010-2013 Texas Instruments, Inc.
>> * Rajendra Nayak <rnayak@ti.com>
>> * Santosh Shilimkar <santosh.shilimkar@ti.com>
>> *
>> @@ -135,16 +135,16 @@ static void omap_default_idle(void)
>> }
>>
>> /**
>> - * omap4_pm_init - Init routine for OMAP4 PM
>> + * omap4_init_static_deps - Add OMAP4 static dependencies
>> *
>> - * Initializes all powerdomain and clockdomain target states
>> - * and all PRCM settings.
>> + * Add needed static clockdomain dependencies on OMAP4 devices.
>> + * Return: 0 on success or 'err' on failures
>> */
>> -int __init omap4_pm_init(void)
>> +static inline int omap4_init_static_deps(void)
>
> You dropped the __init here, but it's still only called from another
> __init function, so I suspect it should stay.
>
Yep. Will keep that in next version.
Regards,
Santosh
^ permalink raw reply [flat|nested] 128+ messages in thread
* Re: [PATCH v2 03/18] ARM: OMAP4+: PM: Consolidate and use OMAP4 PM code for OMAP5
2013-04-04 11:51 ` Santosh Shilimkar
@ 2013-04-04 11:55 ` Santosh Shilimkar
-1 siblings, 0 replies; 128+ messages in thread
From: Santosh Shilimkar @ 2013-04-04 11:55 UTC (permalink / raw)
To: Kevin Hilman; +Cc: linux-omap, linux-arm-kernel, nm, tony
On Thursday 04 April 2013 05:21 PM, Santosh Shilimkar wrote:
> On Thursday 04 April 2013 01:50 AM, Kevin Hilman wrote:
>> Santosh Shilimkar <santosh.shilimkar@ti.com> writes:
>>
>>> OMAP5 has backward compatible PRCM block and it's programming
>>> model is mostly similar to OMAP4. Same is going to be maintained
>>> for future OMAP4 based SOCs. Hence consolidate the OMAP4 power
>>> management code so that it can be re-used on OMAP5 and later devices.
>>>
>>> With consolidated code, let basic power management code build
>>> for OMAP5 devices. While at it, update the kernel-doc for omap4_pm_init().
>>>
>>> Acked-by: Nishanth Menon <nm@ti.com>
>>> Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
>>> ---
>>> arch/arm/mach-omap2/Makefile | 9 ++--
>>> arch/arm/mach-omap2/{pm44xx.c => pm_omap4plus.c} | 54 ++++++++++++++++----
>>> .../mach-omap2/{sleep44xx.S => sleep_omap4plus.S} | 0
>>> 3 files changed, 49 insertions(+), 14 deletions(-)
>>> rename arch/arm/mach-omap2/{pm44xx.c => pm_omap4plus.c} (86%)
>>> rename arch/arm/mach-omap2/{sleep44xx.S => sleep_omap4plus.S} (100%)
>>>
>
> [..]
>>>
>>> /**
>>> - * omap4_pm_init - Init routine for OMAP4 PM
>>> + * omap4_init_static_deps - Add OMAP4 static dependencies
>>> *
>>> - * Initializes all powerdomain and clockdomain target states
>>> - * and all PRCM settings.
>>> + * Add needed static clockdomain dependencies on OMAP4 devices.
>>> + * Return: 0 on success or 'err' on failures
>>> */
>>> -int __init omap4_pm_init(void)
>>> +static inline int omap4_init_static_deps(void)
>>
>> You dropped the __init here, but it's still only called from another
>> __init function, so I suspect it should stay.
>>
> Yep. Will keep that in next version.
>
I was too quick to respond. The function is "static inline" so
there is no need to add __init here.
Regards,
Santosh
^ permalink raw reply [flat|nested] 128+ messages in thread
* [PATCH v2 03/18] ARM: OMAP4+: PM: Consolidate and use OMAP4 PM code for OMAP5
@ 2013-04-04 11:55 ` Santosh Shilimkar
0 siblings, 0 replies; 128+ messages in thread
From: Santosh Shilimkar @ 2013-04-04 11:55 UTC (permalink / raw)
To: linux-arm-kernel
On Thursday 04 April 2013 05:21 PM, Santosh Shilimkar wrote:
> On Thursday 04 April 2013 01:50 AM, Kevin Hilman wrote:
>> Santosh Shilimkar <santosh.shilimkar@ti.com> writes:
>>
>>> OMAP5 has backward compatible PRCM block and it's programming
>>> model is mostly similar to OMAP4. Same is going to be maintained
>>> for future OMAP4 based SOCs. Hence consolidate the OMAP4 power
>>> management code so that it can be re-used on OMAP5 and later devices.
>>>
>>> With consolidated code, let basic power management code build
>>> for OMAP5 devices. While at it, update the kernel-doc for omap4_pm_init().
>>>
>>> Acked-by: Nishanth Menon <nm@ti.com>
>>> Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
>>> ---
>>> arch/arm/mach-omap2/Makefile | 9 ++--
>>> arch/arm/mach-omap2/{pm44xx.c => pm_omap4plus.c} | 54 ++++++++++++++++----
>>> .../mach-omap2/{sleep44xx.S => sleep_omap4plus.S} | 0
>>> 3 files changed, 49 insertions(+), 14 deletions(-)
>>> rename arch/arm/mach-omap2/{pm44xx.c => pm_omap4plus.c} (86%)
>>> rename arch/arm/mach-omap2/{sleep44xx.S => sleep_omap4plus.S} (100%)
>>>
>
> [..]
>>>
>>> /**
>>> - * omap4_pm_init - Init routine for OMAP4 PM
>>> + * omap4_init_static_deps - Add OMAP4 static dependencies
>>> *
>>> - * Initializes all powerdomain and clockdomain target states
>>> - * and all PRCM settings.
>>> + * Add needed static clockdomain dependencies on OMAP4 devices.
>>> + * Return: 0 on success or 'err' on failures
>>> */
>>> -int __init omap4_pm_init(void)
>>> +static inline int omap4_init_static_deps(void)
>>
>> You dropped the __init here, but it's still only called from another
>> __init function, so I suspect it should stay.
>>
> Yep. Will keep that in next version.
>
I was too quick to respond. The function is "static inline" so
there is no need to add __init here.
Regards,
Santosh
^ permalink raw reply [flat|nested] 128+ messages in thread
* Re: [PATCH v2 05/18] ARM: OMAP5: PM: Enables ES2 PM mode by default
2013-04-03 20:25 ` Kevin Hilman
@ 2013-04-04 12:02 ` Santosh Shilimkar
-1 siblings, 0 replies; 128+ messages in thread
From: Santosh Shilimkar @ 2013-04-04 12:02 UTC (permalink / raw)
To: Kevin Hilman; +Cc: linux-omap, linux-arm-kernel, nm, tony
On Thursday 04 April 2013 01:55 AM, Kevin Hilman wrote:
> Santosh Shilimkar <santosh.shilimkar@ti.com> writes:
>
>> Enables MPUSS ES2 power management mode using ES2_PM_MODE in
>> AMBA_IF_MODE register.
>>
>> 0x0: ES1 behavior, CPU cores would enter and exit OFF mode together. Broken
>
> What is broken?
>
Should have added clarification here. Sorry. Changelog is updated as below
0x0: ES1 behavior, CPU cores would enter and exit OFF mode together.
0x1: ES2 behavior, CPU cores are allowed to enter/exit OFF mode independently.
ES1.0 CPUx OFF mode behavior never worked and after analysis by design team,
it was declared as a broken hardware feature. That lead to addition of
ES2.0 behavior which works.
>> 0x1: ES2 behavior, CPU cores are allowed to enter/exit OFF mode independently.
>>
>> The AMBA_IF_MODE register value is stored on SAR RAM and restored by
>> ROM code.
>>
>> Acked-by: Nishanth Menon <nm@ti.com>
>> Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
>> ---
[..]
>> diff --git a/arch/arm/mach-omap2/omap-wakeupgen.c b/arch/arm/mach-omap2/omap-wakeupgen.c
>> index f8bb3b9..8bcaa8c 100644
>> --- a/arch/arm/mach-omap2/omap-wakeupgen.c
>> +++ b/arch/arm/mach-omap2/omap-wakeupgen.c
>> @@ -42,6 +42,7 @@
>> #define CPU1_ID 0x1
>> #define OMAP4_NR_BANKS 4
>> #define OMAP4_NR_IRQS 128
>> +#define OMAP5_AMBA_IF_PM_MODE (1 << 5)
>
> nit: use BIT()
>
Ok.
Regards,
santosh
^ permalink raw reply [flat|nested] 128+ messages in thread
* [PATCH v2 05/18] ARM: OMAP5: PM: Enables ES2 PM mode by default
@ 2013-04-04 12:02 ` Santosh Shilimkar
0 siblings, 0 replies; 128+ messages in thread
From: Santosh Shilimkar @ 2013-04-04 12:02 UTC (permalink / raw)
To: linux-arm-kernel
On Thursday 04 April 2013 01:55 AM, Kevin Hilman wrote:
> Santosh Shilimkar <santosh.shilimkar@ti.com> writes:
>
>> Enables MPUSS ES2 power management mode using ES2_PM_MODE in
>> AMBA_IF_MODE register.
>>
>> 0x0: ES1 behavior, CPU cores would enter and exit OFF mode together. Broken
>
> What is broken?
>
Should have added clarification here. Sorry. Changelog is updated as below
0x0: ES1 behavior, CPU cores would enter and exit OFF mode together.
0x1: ES2 behavior, CPU cores are allowed to enter/exit OFF mode independently.
ES1.0 CPUx OFF mode behavior never worked and after analysis by design team,
it was declared as a broken hardware feature. That lead to addition of
ES2.0 behavior which works.
>> 0x1: ES2 behavior, CPU cores are allowed to enter/exit OFF mode independently.
>>
>> The AMBA_IF_MODE register value is stored on SAR RAM and restored by
>> ROM code.
>>
>> Acked-by: Nishanth Menon <nm@ti.com>
>> Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
>> ---
[..]
>> diff --git a/arch/arm/mach-omap2/omap-wakeupgen.c b/arch/arm/mach-omap2/omap-wakeupgen.c
>> index f8bb3b9..8bcaa8c 100644
>> --- a/arch/arm/mach-omap2/omap-wakeupgen.c
>> +++ b/arch/arm/mach-omap2/omap-wakeupgen.c
>> @@ -42,6 +42,7 @@
>> #define CPU1_ID 0x1
>> #define OMAP4_NR_BANKS 4
>> #define OMAP4_NR_IRQS 128
>> +#define OMAP5_AMBA_IF_PM_MODE (1 << 5)
>
> nit: use BIT()
>
Ok.
Regards,
santosh
^ permalink raw reply [flat|nested] 128+ messages in thread
* Re: [PATCH v2 06/18] ARM: OMAP5: PM: Enable Mercury retention mode on CPUx powerdomains
2013-04-03 20:31 ` Kevin Hilman
@ 2013-04-04 12:08 ` Santosh Shilimkar
-1 siblings, 0 replies; 128+ messages in thread
From: Santosh Shilimkar @ 2013-04-04 12:08 UTC (permalink / raw)
To: Kevin Hilman; +Cc: linux-omap, linux-arm-kernel, nm, tony
On Thursday 04 April 2013 02:01 AM, Kevin Hilman wrote:
> Santosh Shilimkar <santosh.shilimkar@ti.com> writes:
>
>> In addition to the standard power-management technique, the OMAP5
>> MPU subsystem also employs an SR3-APG (mercury) power management
>> technology to reduce leakage.
>>
>> It allows for full logic and memories retention on MPU_C0 and MPU_C1 and
>> is controlled by the PRCM_MPU.
>>
>> Acked-by: Nishanth Menon <nm@ti.com>
>> Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
>> ---
>> arch/arm/mach-omap2/omap-mpuss-lowpower.c | 27 +++++++++++++++++++++++++++
>> 1 file changed, 27 insertions(+)
>>
>> diff --git a/arch/arm/mach-omap2/omap-mpuss-lowpower.c b/arch/arm/mach-omap2/omap-mpuss-lowpower.c
>> index b1441b1..d390d18 100644
>> --- a/arch/arm/mach-omap2/omap-mpuss-lowpower.c
>> +++ b/arch/arm/mach-omap2/omap-mpuss-lowpower.c
>> @@ -62,6 +62,10 @@
>> #include "prm44xx.h"
>> #include "prm-regbits-44xx.h"
>>
>> +/* Add defines needed for mercury mode. Refer MPU's PRM_PSCON_COUNT */
>> +#define PRM_PSCON_HG_EN (1 << 24)
>> +#define PRM_PSCON_HG_RAMPUP (1 << 25)
>
> nit: use BIT()
>
ok
>> #ifdef CONFIG_SMP
>>
>> struct omap4_cpu_pm_info {
>> @@ -337,6 +341,28 @@ int __cpuinit omap4_hotplug_cpu(unsigned int cpu, unsigned int power_state)
>> return 0;
>> }
>>
>> +/**
>> + * enable_mercury_retention_mode: Enable OMAP5 mercury retention feature
>> + *
>> + * OMAP5 devices supports SR3-APG (mercury) power management technology to
>> + * reduce leakage. It allows for full logic and memories retention on
>> + * MPU_C0 and MPU_C1 and is controlled by the PRCM_MPU. The function enable
>> + * the mercury retention feature.
>> + */
>> +static void enable_mercury_retention_mode(void)
>
> __init ?
>
yep.
> This is very OMAP5 specific (unless you generalize the offsets used) so
> should this have omap5_ prefix?
>
Agree.
>
>> +{
>> + u32 reg;
>> +
>> + /*
>> + * To enable mercury mode, both HG_EN and HG_RAMPUP needs to be
>> + * enabled from PRM_PSCON_COUNT register.
>> + */
>> + reg = omap4_prcm_mpu_read_inst_reg(OMAP54XX_PRCM_MPU_DEVICE_INST,
>> + OMAP54XX_PRCM_MPU_PRM_PSCON_COUNT_OFFSET);
>> + reg |= PRM_PSCON_HG_EN | PRM_PSCON_HG_RAMPUP;
>> + omap4_prcm_mpu_write_inst_reg(reg, OMAP54XX_PRCM_MPU_DEVICE_INST,
>> + OMAP54XX_PRCM_MPU_PRM_PSCON_COUNT_OFFSET);
>
> nit: when I see 'reg', I expect it to be a register/offset. But this is
> a register value. Maybe use 'val' instead as you've done elsewhere in
> this series.
>
I generally use 'offset' if it is offset and 'reg' for actual register read.
Anyways, I have changed it to 'val' now.
Regards,
Santosh
^ permalink raw reply [flat|nested] 128+ messages in thread
* [PATCH v2 06/18] ARM: OMAP5: PM: Enable Mercury retention mode on CPUx powerdomains
@ 2013-04-04 12:08 ` Santosh Shilimkar
0 siblings, 0 replies; 128+ messages in thread
From: Santosh Shilimkar @ 2013-04-04 12:08 UTC (permalink / raw)
To: linux-arm-kernel
On Thursday 04 April 2013 02:01 AM, Kevin Hilman wrote:
> Santosh Shilimkar <santosh.shilimkar@ti.com> writes:
>
>> In addition to the standard power-management technique, the OMAP5
>> MPU subsystem also employs an SR3-APG (mercury) power management
>> technology to reduce leakage.
>>
>> It allows for full logic and memories retention on MPU_C0 and MPU_C1 and
>> is controlled by the PRCM_MPU.
>>
>> Acked-by: Nishanth Menon <nm@ti.com>
>> Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
>> ---
>> arch/arm/mach-omap2/omap-mpuss-lowpower.c | 27 +++++++++++++++++++++++++++
>> 1 file changed, 27 insertions(+)
>>
>> diff --git a/arch/arm/mach-omap2/omap-mpuss-lowpower.c b/arch/arm/mach-omap2/omap-mpuss-lowpower.c
>> index b1441b1..d390d18 100644
>> --- a/arch/arm/mach-omap2/omap-mpuss-lowpower.c
>> +++ b/arch/arm/mach-omap2/omap-mpuss-lowpower.c
>> @@ -62,6 +62,10 @@
>> #include "prm44xx.h"
>> #include "prm-regbits-44xx.h"
>>
>> +/* Add defines needed for mercury mode. Refer MPU's PRM_PSCON_COUNT */
>> +#define PRM_PSCON_HG_EN (1 << 24)
>> +#define PRM_PSCON_HG_RAMPUP (1 << 25)
>
> nit: use BIT()
>
ok
>> #ifdef CONFIG_SMP
>>
>> struct omap4_cpu_pm_info {
>> @@ -337,6 +341,28 @@ int __cpuinit omap4_hotplug_cpu(unsigned int cpu, unsigned int power_state)
>> return 0;
>> }
>>
>> +/**
>> + * enable_mercury_retention_mode: Enable OMAP5 mercury retention feature
>> + *
>> + * OMAP5 devices supports SR3-APG (mercury) power management technology to
>> + * reduce leakage. It allows for full logic and memories retention on
>> + * MPU_C0 and MPU_C1 and is controlled by the PRCM_MPU. The function enable
>> + * the mercury retention feature.
>> + */
>> +static void enable_mercury_retention_mode(void)
>
> __init ?
>
yep.
> This is very OMAP5 specific (unless you generalize the offsets used) so
> should this have omap5_ prefix?
>
Agree.
>
>> +{
>> + u32 reg;
>> +
>> + /*
>> + * To enable mercury mode, both HG_EN and HG_RAMPUP needs to be
>> + * enabled from PRM_PSCON_COUNT register.
>> + */
>> + reg = omap4_prcm_mpu_read_inst_reg(OMAP54XX_PRCM_MPU_DEVICE_INST,
>> + OMAP54XX_PRCM_MPU_PRM_PSCON_COUNT_OFFSET);
>> + reg |= PRM_PSCON_HG_EN | PRM_PSCON_HG_RAMPUP;
>> + omap4_prcm_mpu_write_inst_reg(reg, OMAP54XX_PRCM_MPU_DEVICE_INST,
>> + OMAP54XX_PRCM_MPU_PRM_PSCON_COUNT_OFFSET);
>
> nit: when I see 'reg', I expect it to be a register/offset. But this is
> a register value. Maybe use 'val' instead as you've done elsewhere in
> this series.
>
I generally use 'offset' if it is offset and 'reg' for actual register read.
Anyways, I have changed it to 'val' now.
Regards,
Santosh
^ permalink raw reply [flat|nested] 128+ messages in thread
* Re: [PATCH v2 07/18] ARM: OMAP5: Add init_late() hook to enable pm initialization
2013-04-03 20:33 ` Kevin Hilman
@ 2013-04-04 12:28 ` Santosh Shilimkar
-1 siblings, 0 replies; 128+ messages in thread
From: Santosh Shilimkar @ 2013-04-04 12:28 UTC (permalink / raw)
To: Kevin Hilman; +Cc: linux-omap, linux-arm-kernel, nm, tony
On Thursday 04 April 2013 02:03 AM, Kevin Hilman wrote:
> Santosh Shilimkar <santosh.shilimkar@ti.com> writes:
>
>> With consolidated code, now we can add the .init_late hook for
>> OMAP5 to enable power management and mux initialization.
>>
>> Acked-by: Nishanth Menon <nm@ti.com>
>> Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
>> ---
[..]
>> diff --git a/arch/arm/mach-omap2/io.c b/arch/arm/mach-omap2/io.c
>> index e948a39..cdd1264 100644
>> --- a/arch/arm/mach-omap2/io.c
>> +++ b/arch/arm/mach-omap2/io.c
>> @@ -636,6 +636,14 @@ void __init omap5_init_early(void)
>> omap_hwmod_init_postsetup();
>>
>> }
>> +
>> +void __init omap5_init_late(void)
>> +{
>> + omap_mux_late_init();
>> + omap2_common_pm_late_init();
>> + omap4_pm_init();
>> + omap2_clk_enable_autoidle_all();
>> +}
>
> Since you're consolidating, why not rename omap4430_init_late to
> omap4plus_init_late and use it for both OMAP4 and OMAP5?
>
Now re-looking again, I need to drop omap_mux_late_init()
since OMAP5 is DT only. And hence OMAP5 needs to be a
separate hook at least for now.
Regards,
Santosh
^ permalink raw reply [flat|nested] 128+ messages in thread
* [PATCH v2 07/18] ARM: OMAP5: Add init_late() hook to enable pm initialization
@ 2013-04-04 12:28 ` Santosh Shilimkar
0 siblings, 0 replies; 128+ messages in thread
From: Santosh Shilimkar @ 2013-04-04 12:28 UTC (permalink / raw)
To: linux-arm-kernel
On Thursday 04 April 2013 02:03 AM, Kevin Hilman wrote:
> Santosh Shilimkar <santosh.shilimkar@ti.com> writes:
>
>> With consolidated code, now we can add the .init_late hook for
>> OMAP5 to enable power management and mux initialization.
>>
>> Acked-by: Nishanth Menon <nm@ti.com>
>> Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
>> ---
[..]
>> diff --git a/arch/arm/mach-omap2/io.c b/arch/arm/mach-omap2/io.c
>> index e948a39..cdd1264 100644
>> --- a/arch/arm/mach-omap2/io.c
>> +++ b/arch/arm/mach-omap2/io.c
>> @@ -636,6 +636,14 @@ void __init omap5_init_early(void)
>> omap_hwmod_init_postsetup();
>>
>> }
>> +
>> +void __init omap5_init_late(void)
>> +{
>> + omap_mux_late_init();
>> + omap2_common_pm_late_init();
>> + omap4_pm_init();
>> + omap2_clk_enable_autoidle_all();
>> +}
>
> Since you're consolidating, why not rename omap4430_init_late to
> omap4plus_init_late and use it for both OMAP4 and OMAP5?
>
Now re-looking again, I need to drop omap_mux_late_init()
since OMAP5 is DT only. And hence OMAP5 needs to be a
separate hook at least for now.
Regards,
Santosh
^ permalink raw reply [flat|nested] 128+ messages in thread
* Re: [PATCH v2 08/18] ARM: OMAP5: PM: Add CPU power off in hotplug path
2013-04-03 20:49 ` Kevin Hilman
@ 2013-04-04 13:23 ` Santosh Shilimkar
-1 siblings, 0 replies; 128+ messages in thread
From: Santosh Shilimkar @ 2013-04-04 13:23 UTC (permalink / raw)
To: Kevin Hilman; +Cc: linux-omap, linux-arm-kernel, nm, tony
On Thursday 04 April 2013 02:19 AM, Kevin Hilman wrote:
> Santosh Shilimkar <santosh.shilimkar@ti.com> writes:
>
>> Add power management code to handle the CPU off mode to enable CPUP hotplug
>> mode for OMAP5 devices. Separate suspend finisher is used for OMAP5(Cortex-A15)
>> because it doesn't use SCU power status register and external PL310 L2 cache
>> which makes code flow bit different.
>>
>> Acked-by: Nishanth Menon <nm@ti.com>
>> Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
>
> [...]
>
>> @@ -436,14 +445,21 @@ int __init omap4_mpuss_init(void)
>>
>> if (cpu_is_omap44xx()) {
>> omap_pm_ops.finish_suspend = omap4_finish_suspend;
>> + omap_pm_ops.hotplug_restart = omap_secondary_startup;
>> omap_pm_ops.resume = omap4_cpu_resume;
>> omap_pm_ops.scu_prepare = scu_pwrst_prepare;
>> cpu_context_offset = OMAP4_RM_CPU0_CPU0_CONTEXT_OFFSET;
>> } else if (soc_is_omap54xx()) {
>> + omap_pm_ops.finish_suspend = omap5_finish_suspend;
>> + omap_pm_ops.hotplug_restart = omap5_secondary_startup;
>> cpu_context_offset = OMAP54XX_RM_CPU0_CPU0_CONTEXT_OFFSET;
>> enable_mercury_retention_mode();
>> }
>>
>> + /* Over-write the OMAP4 hook to take care of ROM BUG */
>> + if (cpu_is_omap446x())
>> + omap_pm_ops.hotplug_restart = omap_secondary_startup_4460;
>
> A couple nits...
>
> I think this would go better at the end of the 'if omap44xx' block
> above.
>
Nishant commented on this as well. The indentation was looking ugly
and I thought its better to have this BUG hunk separate. I prefer
it this way though if you really insist, i have to change it.
> Also, while you're hear, maybe it's time to rename the current secondary
> startup functions to match the new one. IOW omap4_..., omap4460_... and omap5_...
>
Good idea. Will do it in a separate patch since these have been there in few
files.
Regards,
Santosh
^ permalink raw reply [flat|nested] 128+ messages in thread
* [PATCH v2 08/18] ARM: OMAP5: PM: Add CPU power off in hotplug path
@ 2013-04-04 13:23 ` Santosh Shilimkar
0 siblings, 0 replies; 128+ messages in thread
From: Santosh Shilimkar @ 2013-04-04 13:23 UTC (permalink / raw)
To: linux-arm-kernel
On Thursday 04 April 2013 02:19 AM, Kevin Hilman wrote:
> Santosh Shilimkar <santosh.shilimkar@ti.com> writes:
>
>> Add power management code to handle the CPU off mode to enable CPUP hotplug
>> mode for OMAP5 devices. Separate suspend finisher is used for OMAP5(Cortex-A15)
>> because it doesn't use SCU power status register and external PL310 L2 cache
>> which makes code flow bit different.
>>
>> Acked-by: Nishanth Menon <nm@ti.com>
>> Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
>
> [...]
>
>> @@ -436,14 +445,21 @@ int __init omap4_mpuss_init(void)
>>
>> if (cpu_is_omap44xx()) {
>> omap_pm_ops.finish_suspend = omap4_finish_suspend;
>> + omap_pm_ops.hotplug_restart = omap_secondary_startup;
>> omap_pm_ops.resume = omap4_cpu_resume;
>> omap_pm_ops.scu_prepare = scu_pwrst_prepare;
>> cpu_context_offset = OMAP4_RM_CPU0_CPU0_CONTEXT_OFFSET;
>> } else if (soc_is_omap54xx()) {
>> + omap_pm_ops.finish_suspend = omap5_finish_suspend;
>> + omap_pm_ops.hotplug_restart = omap5_secondary_startup;
>> cpu_context_offset = OMAP54XX_RM_CPU0_CPU0_CONTEXT_OFFSET;
>> enable_mercury_retention_mode();
>> }
>>
>> + /* Over-write the OMAP4 hook to take care of ROM BUG */
>> + if (cpu_is_omap446x())
>> + omap_pm_ops.hotplug_restart = omap_secondary_startup_4460;
>
> A couple nits...
>
> I think this would go better at the end of the 'if omap44xx' block
> above.
>
Nishant commented on this as well. The indentation was looking ugly
and I thought its better to have this BUG hunk separate. I prefer
it this way though if you really insist, i have to change it.
> Also, while you're hear, maybe it's time to rename the current secondary
> startup functions to match the new one. IOW omap4_..., omap4460_... and omap5_...
>
Good idea. Will do it in a separate patch since these have been there in few
files.
Regards,
Santosh
^ permalink raw reply [flat|nested] 128+ messages in thread
* Re: [PATCH v2 09/18] ARM: OMAP4+: PM: Restore CPU power state to ON with clockdomain force wakeup method
2013-04-03 20:54 ` Kevin Hilman
@ 2013-04-04 13:37 ` Santosh Shilimkar
-1 siblings, 0 replies; 128+ messages in thread
From: Santosh Shilimkar @ 2013-04-04 13:37 UTC (permalink / raw)
To: Kevin Hilman; +Cc: linux-omap, linux-arm-kernel, nm, tony
On Thursday 04 April 2013 02:24 AM, Kevin Hilman wrote:
> Santosh Shilimkar <santosh.shilimkar@ti.com> writes:
>
>> While waking up CPU from off state using clock domain force wakeup, restore
>> the CPU power state to ON state before putting CPU clock domain under
>> hardware control. Otherwise CPU wakeup might fail. The change is recommended
>> for all OMAP4+ devices though the PRCM weakness was observed on OMAP5
>> devices first.
>
> Sounds reasonable, but can you describe the "weakness" a little more?
>
> IOW, what exactly happens if this is not done? It sounds like the CPU
> might immediately go back to retention, but how does that happen unless
> it does a WFI?
>
Its more of lock-up inside the hardware state machine and results
are UN-predictable. We have seen hard-locks most of the time where system
is just frozen. The hardware gets into wrong state machine if the power
domain state isn't restored. I will add this information to changelog.
> Also, this sounds like a fix to me, and should probably be broken out
> accordingly.
>
Yeah. You mean a separate patch from the series, right ? This patch
actually can be independently added.
In case you decide to apply it for the fixes branch, updated patch
at end of the email.
Regards,
Santosh
>From a0cef44760d859b63a34603010f8c0621da4b8ab Mon Sep 17 00:00:00 2001
From: Santosh Shilimkar <santosh.shilimkar@ti.com>
Date: Fri, 8 Feb 2013 22:50:58 +0530
Subject: [PATCH] ARM: OMAP4+: PM: Restore CPU power state to ON with
clockdomain force wakeup method
While waking up CPU from off state using clock domain force wakeup, restore
the CPU power state to ON state before putting CPU clock domain under
hardware control. Otherwise CPU wakeup might fail. The change is recommended
for all OMAP4+ devices though the PRCM weakness was observed on OMAP5
devices first.
As a result of weakness, lock-up is observed inside the hardware state
machine of local CPU PRCM and results are UN-predictable as per designers.
In software testing, we have seen hard-locks most of the time where system
gets frozen. With power domain state restored, system behaves correctly.
So update the code accordingly.
Acked-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
---
arch/arm/mach-omap2/cpuidle44xx.c | 1 +
arch/arm/mach-omap2/omap-smp.c | 12 ++++++++++--
2 files changed, 11 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/cpuidle44xx.c b/arch/arm/mach-omap2/cpuidle44xx.c
index 944e64a..9de47a7 100644
--- a/arch/arm/mach-omap2/cpuidle44xx.c
+++ b/arch/arm/mach-omap2/cpuidle44xx.c
@@ -131,6 +131,7 @@ static int omap4_enter_idle_coupled(struct cpuidle_device *dev,
/* Wakeup CPU1 only if it is not offlined */
if (dev->cpu == 0 && cpumask_test_cpu(1, cpu_online_mask)) {
clkdm_wakeup(cpu_clkdm[1]);
+ omap_set_pwrdm_state(cpu_pd[1], PWRDM_POWER_ON);
clkdm_allow_idle(cpu_clkdm[1]);
}
diff --git a/arch/arm/mach-omap2/omap-smp.c b/arch/arm/mach-omap2/omap-smp.c
index 5b20165..8106e8d 100644
--- a/arch/arm/mach-omap2/omap-smp.c
+++ b/arch/arm/mach-omap2/omap-smp.c
@@ -83,6 +83,7 @@ static int __cpuinit omap4_boot_secondary(unsigned int cpu, struct task_struct *
{
static struct clockdomain *cpu1_clkdm;
static bool booted;
+ static struct powerdomain *cpu1_pwrdm;
void __iomem *base = omap_get_wakeupgen_base();
/*
@@ -102,8 +103,10 @@ static int __cpuinit omap4_boot_secondary(unsigned int cpu, struct task_struct *
else
__raw_writel(0x20, base + OMAP_AUX_CORE_BOOT_0);
- if (!cpu1_clkdm)
+ if (!cpu1_clkdm && !cpu1_pwrdm) {
cpu1_clkdm = clkdm_lookup("mpu1_clkdm");
+ cpu1_pwrdm = pwrdm_lookup("cpu1_pwrdm");
+ }
/*
* The SGI(Software Generated Interrupts) are not wakeup capable
@@ -116,7 +119,7 @@ static int __cpuinit omap4_boot_secondary(unsigned int cpu, struct task_struct *
* Section :
* 4.3.4.2 Power States of CPU0 and CPU1
*/
- if (booted) {
+ if (booted && cpu1_pwrdm && cpu1_clkdm) {
/*
* GIC distributor control register has changed between
* CortexA9 r1pX and r2pX. The Control Register secure
@@ -137,7 +140,12 @@ static int __cpuinit omap4_boot_secondary(unsigned int cpu, struct task_struct *
gic_dist_disable();
}
+ /*
+ * Ensure that CPU power state is set to ON to avoid CPU
+ * powerdomain transition on wfi
+ */
clkdm_wakeup(cpu1_clkdm);
+ omap_set_pwrdm_state(cpu1_pwrdm, PWRDM_POWER_ON);
clkdm_allow_idle(cpu1_clkdm);
if (IS_PM44XX_ERRATUM(PM_OMAP4_ROM_SMP_BOOT_ERRATUM_GICD)) {
--
1.7.9.5
^ permalink raw reply related [flat|nested] 128+ messages in thread
* [PATCH v2 09/18] ARM: OMAP4+: PM: Restore CPU power state to ON with clockdomain force wakeup method
@ 2013-04-04 13:37 ` Santosh Shilimkar
0 siblings, 0 replies; 128+ messages in thread
From: Santosh Shilimkar @ 2013-04-04 13:37 UTC (permalink / raw)
To: linux-arm-kernel
On Thursday 04 April 2013 02:24 AM, Kevin Hilman wrote:
> Santosh Shilimkar <santosh.shilimkar@ti.com> writes:
>
>> While waking up CPU from off state using clock domain force wakeup, restore
>> the CPU power state to ON state before putting CPU clock domain under
>> hardware control. Otherwise CPU wakeup might fail. The change is recommended
>> for all OMAP4+ devices though the PRCM weakness was observed on OMAP5
>> devices first.
>
> Sounds reasonable, but can you describe the "weakness" a little more?
>
> IOW, what exactly happens if this is not done? It sounds like the CPU
> might immediately go back to retention, but how does that happen unless
> it does a WFI?
>
Its more of lock-up inside the hardware state machine and results
are UN-predictable. We have seen hard-locks most of the time where system
is just frozen. The hardware gets into wrong state machine if the power
domain state isn't restored. I will add this information to changelog.
> Also, this sounds like a fix to me, and should probably be broken out
> accordingly.
>
Yeah. You mean a separate patch from the series, right ? This patch
actually can be independently added.
In case you decide to apply it for the fixes branch, updated patch
at end of the email.
Regards,
Santosh
>From a0cef44760d859b63a34603010f8c0621da4b8ab Mon Sep 17 00:00:00 2001
From: Santosh Shilimkar <santosh.shilimkar@ti.com>
Date: Fri, 8 Feb 2013 22:50:58 +0530
Subject: [PATCH] ARM: OMAP4+: PM: Restore CPU power state to ON with
clockdomain force wakeup method
While waking up CPU from off state using clock domain force wakeup, restore
the CPU power state to ON state before putting CPU clock domain under
hardware control. Otherwise CPU wakeup might fail. The change is recommended
for all OMAP4+ devices though the PRCM weakness was observed on OMAP5
devices first.
As a result of weakness, lock-up is observed inside the hardware state
machine of local CPU PRCM and results are UN-predictable as per designers.
In software testing, we have seen hard-locks most of the time where system
gets frozen. With power domain state restored, system behaves correctly.
So update the code accordingly.
Acked-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
---
arch/arm/mach-omap2/cpuidle44xx.c | 1 +
arch/arm/mach-omap2/omap-smp.c | 12 ++++++++++--
2 files changed, 11 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/cpuidle44xx.c b/arch/arm/mach-omap2/cpuidle44xx.c
index 944e64a..9de47a7 100644
--- a/arch/arm/mach-omap2/cpuidle44xx.c
+++ b/arch/arm/mach-omap2/cpuidle44xx.c
@@ -131,6 +131,7 @@ static int omap4_enter_idle_coupled(struct cpuidle_device *dev,
/* Wakeup CPU1 only if it is not offlined */
if (dev->cpu == 0 && cpumask_test_cpu(1, cpu_online_mask)) {
clkdm_wakeup(cpu_clkdm[1]);
+ omap_set_pwrdm_state(cpu_pd[1], PWRDM_POWER_ON);
clkdm_allow_idle(cpu_clkdm[1]);
}
diff --git a/arch/arm/mach-omap2/omap-smp.c b/arch/arm/mach-omap2/omap-smp.c
index 5b20165..8106e8d 100644
--- a/arch/arm/mach-omap2/omap-smp.c
+++ b/arch/arm/mach-omap2/omap-smp.c
@@ -83,6 +83,7 @@ static int __cpuinit omap4_boot_secondary(unsigned int cpu, struct task_struct *
{
static struct clockdomain *cpu1_clkdm;
static bool booted;
+ static struct powerdomain *cpu1_pwrdm;
void __iomem *base = omap_get_wakeupgen_base();
/*
@@ -102,8 +103,10 @@ static int __cpuinit omap4_boot_secondary(unsigned int cpu, struct task_struct *
else
__raw_writel(0x20, base + OMAP_AUX_CORE_BOOT_0);
- if (!cpu1_clkdm)
+ if (!cpu1_clkdm && !cpu1_pwrdm) {
cpu1_clkdm = clkdm_lookup("mpu1_clkdm");
+ cpu1_pwrdm = pwrdm_lookup("cpu1_pwrdm");
+ }
/*
* The SGI(Software Generated Interrupts) are not wakeup capable
@@ -116,7 +119,7 @@ static int __cpuinit omap4_boot_secondary(unsigned int cpu, struct task_struct *
* Section :
* 4.3.4.2 Power States of CPU0 and CPU1
*/
- if (booted) {
+ if (booted && cpu1_pwrdm && cpu1_clkdm) {
/*
* GIC distributor control register has changed between
* CortexA9 r1pX and r2pX. The Control Register secure
@@ -137,7 +140,12 @@ static int __cpuinit omap4_boot_secondary(unsigned int cpu, struct task_struct *
gic_dist_disable();
}
+ /*
+ * Ensure that CPU power state is set to ON to avoid CPU
+ * powerdomain transition on wfi
+ */
clkdm_wakeup(cpu1_clkdm);
+ omap_set_pwrdm_state(cpu1_pwrdm, PWRDM_POWER_ON);
clkdm_allow_idle(cpu1_clkdm);
if (IS_PM44XX_ERRATUM(PM_OMAP4_ROM_SMP_BOOT_ERRATUM_GICD)) {
--
1.7.9.5
^ permalink raw reply related [flat|nested] 128+ messages in thread
* Re: [PATCH v2 11/18] ARM: OMAP5: PM: Add L2 memory power down support
2013-04-03 20:58 ` Kevin Hilman
@ 2013-04-04 13:46 ` Santosh Shilimkar
-1 siblings, 0 replies; 128+ messages in thread
From: Santosh Shilimkar @ 2013-04-04 13:46 UTC (permalink / raw)
To: Kevin Hilman; +Cc: linux-omap, linux-arm-kernel, nm, tony
On Thursday 04 April 2013 02:28 AM, Kevin Hilman wrote:
> Santosh Shilimkar <santosh.shilimkar@ti.com> writes:
>
>> When the entire MPUSS cluster is powered down in device off state, L2 cache
>> memory looses it's content and hence while targetting such a state,
>> l2 cache needs to be flushed to main memory.
>>
>> Add the necessary low power code support for the same.
>>
>> Acked-by: Nishanth Menon <nm@ti.com>
>> Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
>> ---
>> arch/arm/mach-omap2/omap-secure.h | 1 +
>> arch/arm/mach-omap2/sleep_omap4plus.S | 21 +++++++++++++++++++++
>> 2 files changed, 22 insertions(+)
>>
>> diff --git a/arch/arm/mach-omap2/omap-secure.h b/arch/arm/mach-omap2/omap-secure.h
>> index 1739468..a171a5a 100644
>> --- a/arch/arm/mach-omap2/omap-secure.h
>> +++ b/arch/arm/mach-omap2/omap-secure.h
>> @@ -47,6 +47,7 @@
>> #define OMAP4_MON_L2X0_PREFETCH_INDEX 0x113
>> #define OMAP5_MON_CACHES_CLEAN_INDEX 0x103
>> #define OMAP5_MON_AUX_CTRL_INDEX 0x107
>> +#define OMAP5_MON_L2AUX_CTRL_INDEX 0x104
>
> this #define is not used in this patch.
>
Yep. Will drop above hunk.
I forgot to drop this one after dropping the L2X0
setting from last version. Its no longer needed on OMAP5
ES2.0.
Regards,
Santosh
^ permalink raw reply [flat|nested] 128+ messages in thread
* [PATCH v2 11/18] ARM: OMAP5: PM: Add L2 memory power down support
@ 2013-04-04 13:46 ` Santosh Shilimkar
0 siblings, 0 replies; 128+ messages in thread
From: Santosh Shilimkar @ 2013-04-04 13:46 UTC (permalink / raw)
To: linux-arm-kernel
On Thursday 04 April 2013 02:28 AM, Kevin Hilman wrote:
> Santosh Shilimkar <santosh.shilimkar@ti.com> writes:
>
>> When the entire MPUSS cluster is powered down in device off state, L2 cache
>> memory looses it's content and hence while targetting such a state,
>> l2 cache needs to be flushed to main memory.
>>
>> Add the necessary low power code support for the same.
>>
>> Acked-by: Nishanth Menon <nm@ti.com>
>> Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
>> ---
>> arch/arm/mach-omap2/omap-secure.h | 1 +
>> arch/arm/mach-omap2/sleep_omap4plus.S | 21 +++++++++++++++++++++
>> 2 files changed, 22 insertions(+)
>>
>> diff --git a/arch/arm/mach-omap2/omap-secure.h b/arch/arm/mach-omap2/omap-secure.h
>> index 1739468..a171a5a 100644
>> --- a/arch/arm/mach-omap2/omap-secure.h
>> +++ b/arch/arm/mach-omap2/omap-secure.h
>> @@ -47,6 +47,7 @@
>> #define OMAP4_MON_L2X0_PREFETCH_INDEX 0x113
>> #define OMAP5_MON_CACHES_CLEAN_INDEX 0x103
>> #define OMAP5_MON_AUX_CTRL_INDEX 0x107
>> +#define OMAP5_MON_L2AUX_CTRL_INDEX 0x104
>
> this #define is not used in this patch.
>
Yep. Will drop above hunk.
I forgot to drop this one after dropping the L2X0
setting from last version. Its no longer needed on OMAP5
ES2.0.
Regards,
Santosh
^ permalink raw reply [flat|nested] 128+ messages in thread
* Re: [PATCH v2 12/18] ARM: OMAP4: CPUidle: Avoid double idle driver registration
2013-04-03 21:03 ` Kevin Hilman
@ 2013-04-04 13:47 ` Santosh Shilimkar
-1 siblings, 0 replies; 128+ messages in thread
From: Santosh Shilimkar @ 2013-04-04 13:47 UTC (permalink / raw)
To: Kevin Hilman; +Cc: linux-omap, linux-arm-kernel, nm, tony
On Thursday 04 April 2013 02:33 AM, Kevin Hilman wrote:
> Santosh Shilimkar <santosh.shilimkar@ti.com> writes:
>
>> OMAP4 CPUidle driver registration call is under a loop which leads
>> to calling cpuidle_register_driver twice which is not intended.
>>
>> Fix it by moving the driver registration outside the loop.
>>
>> Reported-by: Nishanth Menon <nm@ti.com>
>> Acked-by: Nishanth Menon <nm@ti.com>
>> Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
>
> Looks good.
>
> I've already got a for_3.10/fixes/cpuidle branch going, so I'll apply
> this one there.
>
ok.
Regards,
Santosh
^ permalink raw reply [flat|nested] 128+ messages in thread
* [PATCH v2 12/18] ARM: OMAP4: CPUidle: Avoid double idle driver registration
@ 2013-04-04 13:47 ` Santosh Shilimkar
0 siblings, 0 replies; 128+ messages in thread
From: Santosh Shilimkar @ 2013-04-04 13:47 UTC (permalink / raw)
To: linux-arm-kernel
On Thursday 04 April 2013 02:33 AM, Kevin Hilman wrote:
> Santosh Shilimkar <santosh.shilimkar@ti.com> writes:
>
>> OMAP4 CPUidle driver registration call is under a loop which leads
>> to calling cpuidle_register_driver twice which is not intended.
>>
>> Fix it by moving the driver registration outside the loop.
>>
>> Reported-by: Nishanth Menon <nm@ti.com>
>> Acked-by: Nishanth Menon <nm@ti.com>
>> Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
>
> Looks good.
>
> I've already got a for_3.10/fixes/cpuidle branch going, so I'll apply
> this one there.
>
ok.
Regards,
Santosh
^ permalink raw reply [flat|nested] 128+ messages in thread
* Re: [PATCH v2 13/18] ARM: OMAP: CPUidle: Unregister drivere on device registration failure
2013-04-03 21:03 ` Kevin Hilman
@ 2013-04-04 13:48 ` Santosh Shilimkar
-1 siblings, 0 replies; 128+ messages in thread
From: Santosh Shilimkar @ 2013-04-04 13:48 UTC (permalink / raw)
To: Kevin Hilman; +Cc: linux-omap, linux-arm-kernel, nm, tony
On Thursday 04 April 2013 02:33 AM, Kevin Hilman wrote:
> Santosh Shilimkar <santosh.shilimkar@ti.com> writes:
>
>> If the CPUidle device registration fails for some reason, we should
>> unregister the driver on error path.
>>
>> Fix the code accordingly. Also when at it, check of the driver registration
>> failure too.
>>
>> Acked-by: Nishanth Menon <nm@ti.com>
>> Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
>
> Adding to my for_3.10/fixes/cpuidle branch.
>
Thanks.
regards,
Santosh
^ permalink raw reply [flat|nested] 128+ messages in thread
* [PATCH v2 13/18] ARM: OMAP: CPUidle: Unregister drivere on device registration failure
@ 2013-04-04 13:48 ` Santosh Shilimkar
0 siblings, 0 replies; 128+ messages in thread
From: Santosh Shilimkar @ 2013-04-04 13:48 UTC (permalink / raw)
To: linux-arm-kernel
On Thursday 04 April 2013 02:33 AM, Kevin Hilman wrote:
> Santosh Shilimkar <santosh.shilimkar@ti.com> writes:
>
>> If the CPUidle device registration fails for some reason, we should
>> unregister the driver on error path.
>>
>> Fix the code accordingly. Also when at it, check of the driver registration
>> failure too.
>>
>> Acked-by: Nishanth Menon <nm@ti.com>
>> Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
>
> Adding to my for_3.10/fixes/cpuidle branch.
>
Thanks.
regards,
Santosh
^ permalink raw reply [flat|nested] 128+ messages in thread
* Re: [PATCH v2 14/18] ARM: OMAP4: CPUidle: Make C-state description field more precise
2013-04-03 21:05 ` Kevin Hilman
@ 2013-04-04 13:48 ` Santosh Shilimkar
-1 siblings, 0 replies; 128+ messages in thread
From: Santosh Shilimkar @ 2013-04-04 13:48 UTC (permalink / raw)
To: Kevin Hilman; +Cc: linux-omap, linux-arm-kernel, nm, tony
On Thursday 04 April 2013 02:35 AM, Kevin Hilman wrote:
> Santosh Shilimkar <santosh.shilimkar@ti.com> writes:
>
>> It is useful to know the CPU power state along with MPUSS power state
>> in a supported C-state. Since the data is available via sysfs, one can
>> avoid scrolling the source code for precise construction of C-state.
>>
>> Reported-by: Nishanth Menon <nm@ti.com>
>> Acked-by: Nishanth Menon <nm@ti.com>
>> Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
>
> Nice.
>
> Adding to for_3.10/fixes/cpuidle branch.
>
Thanks.
regards,
Santosh
^ permalink raw reply [flat|nested] 128+ messages in thread
* [PATCH v2 14/18] ARM: OMAP4: CPUidle: Make C-state description field more precise
@ 2013-04-04 13:48 ` Santosh Shilimkar
0 siblings, 0 replies; 128+ messages in thread
From: Santosh Shilimkar @ 2013-04-04 13:48 UTC (permalink / raw)
To: linux-arm-kernel
On Thursday 04 April 2013 02:35 AM, Kevin Hilman wrote:
> Santosh Shilimkar <santosh.shilimkar@ti.com> writes:
>
>> It is useful to know the CPU power state along with MPUSS power state
>> in a supported C-state. Since the data is available via sysfs, one can
>> avoid scrolling the source code for precise construction of C-state.
>>
>> Reported-by: Nishanth Menon <nm@ti.com>
>> Acked-by: Nishanth Menon <nm@ti.com>
>> Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
>
> Nice.
>
> Adding to for_3.10/fixes/cpuidle branch.
>
Thanks.
regards,
Santosh
^ permalink raw reply [flat|nested] 128+ messages in thread
* Re: [PATCH v2 16/18] ARM: OMAP4+: CPUidle: Deprecate use of omap4_mpuss_read_prev_context_state()
2013-04-03 21:37 ` Kevin Hilman
@ 2013-04-04 13:59 ` Santosh Shilimkar
-1 siblings, 0 replies; 128+ messages in thread
From: Santosh Shilimkar @ 2013-04-04 13:59 UTC (permalink / raw)
To: Kevin Hilman; +Cc: linux-omap, linux-arm-kernel, nm, tony
On Thursday 04 April 2013 03:07 AM, Kevin Hilman wrote:
> Santosh Shilimkar <santosh.shilimkar@ti.com> writes:
>
>> Current OMAP4 CPUIdle driver is using omap4_mpuss_read_prev_context_state()
>> function to check whether the MPU cluster lost context or not. Thanks to
>> couple CPUIdle, cluster low power entry is almost guaranteed and hence
>> the programmed cluster check is enough in idle exit path. The API was
>> more of an optimization for corner cases, where if the cluster low power
>> entry fails for some reason, the cluster context restore gets skipped.
>>
>> Moving forward, OMAP CPUidle drivers needs to be moved to drivers/idle/*
>> once the PRM/CM code gets moved to drivers. This patch also reduces one
>> dependency with platform code for idle driver movement.
>>
>> Acked-by: Nishanth Menon <nm@ti.com>
>> Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
>
> Looks good, but I find the changelog a bit confusing.
>
> Below is a slightly modified patch (I only modified the changelog). If
> those changes are OK with you, I'll add it to my cpuidle branch as well.
>
Looks good to me Kevin. Thanks for the change-log update.
Regards,
Santosh
^ permalink raw reply [flat|nested] 128+ messages in thread
* [PATCH v2 16/18] ARM: OMAP4+: CPUidle: Deprecate use of omap4_mpuss_read_prev_context_state()
@ 2013-04-04 13:59 ` Santosh Shilimkar
0 siblings, 0 replies; 128+ messages in thread
From: Santosh Shilimkar @ 2013-04-04 13:59 UTC (permalink / raw)
To: linux-arm-kernel
On Thursday 04 April 2013 03:07 AM, Kevin Hilman wrote:
> Santosh Shilimkar <santosh.shilimkar@ti.com> writes:
>
>> Current OMAP4 CPUIdle driver is using omap4_mpuss_read_prev_context_state()
>> function to check whether the MPU cluster lost context or not. Thanks to
>> couple CPUIdle, cluster low power entry is almost guaranteed and hence
>> the programmed cluster check is enough in idle exit path. The API was
>> more of an optimization for corner cases, where if the cluster low power
>> entry fails for some reason, the cluster context restore gets skipped.
>>
>> Moving forward, OMAP CPUidle drivers needs to be moved to drivers/idle/*
>> once the PRM/CM code gets moved to drivers. This patch also reduces one
>> dependency with platform code for idle driver movement.
>>
>> Acked-by: Nishanth Menon <nm@ti.com>
>> Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
>
> Looks good, but I find the changelog a bit confusing.
>
> Below is a slightly modified patch (I only modified the changelog). If
> those changes are OK with you, I'll add it to my cpuidle branch as well.
>
Looks good to me Kevin. Thanks for the change-log update.
Regards,
Santosh
^ permalink raw reply [flat|nested] 128+ messages in thread
* Re: [PATCH v2 15/18] ARM: OMAP4+: CPUidle: Consolidate idle driver for OMAP5 support
2013-04-03 21:10 ` Kevin Hilman
@ 2013-04-04 14:04 ` Santosh Shilimkar
-1 siblings, 0 replies; 128+ messages in thread
From: Santosh Shilimkar @ 2013-04-04 14:04 UTC (permalink / raw)
To: Kevin Hilman; +Cc: linux-omap, linux-arm-kernel, nm, tony
On Thursday 04 April 2013 02:40 AM, Kevin Hilman wrote:
> Santosh Shilimkar <santosh.shilimkar@ti.com> writes:
>
>> The OMAP5 idle driver can re-use most of OMAP4 CPUidle driver
>> implementation. Also the next derivative SOCs are going to re-use
>> the MPUSS so, same driver with minor updates can be re-used.
>>
>> Prepare the code so that its easier to add CPUidle support for
>> OMAP5 devices.
>>
>> Acked-by: Nishanth Menon <nm@ti.com>
>> Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
>> ---
>> arch/arm/mach-omap2/cpuidle44xx.c | 31 ++++++++++++++++---------------
>> 1 file changed, 16 insertions(+), 15 deletions(-)
>>
>> diff --git a/arch/arm/mach-omap2/cpuidle44xx.c b/arch/arm/mach-omap2/cpuidle44xx.c
>> index b8a22f0..ac6d526 100644
>> --- a/arch/arm/mach-omap2/cpuidle44xx.c
>> +++ b/arch/arm/mach-omap2/cpuidle44xx.c
>> @@ -1,7 +1,7 @@
>> /*
>> - * OMAP4 CPU idle Routines
>> + * OMAP4PLUS CPU idle Routines
>
> nit: s/PLUS/+/
>
> in a few other places in this patch also.
>
yes. Will update that.
>> @@ -24,13 +24,13 @@
>> #include "clockdomain.h"
>>
>> /* Machine specific information */
>> -struct omap4_idle_statedata {
>> +struct idle_statedata {
>> u32 cpu_state;
>> u32 mpu_logic_state;
>> u32 mpu_state;
>> };
>>
>> -static struct omap4_idle_statedata omap4_idle_data[] = {
>> +static struct idle_statedata omap4_idle_data[] = {
>> {
>> .cpu_state = PWRDM_POWER_ON,
>> .mpu_state = PWRDM_POWER_ON,
>> @@ -53,11 +53,12 @@ static struct clockdomain *cpu_clkdm[NR_CPUS];
>>
>> static atomic_t abort_barrier;
>> static bool cpu_done[NR_CPUS];
>> +static struct idle_statedata *state_ptr = &omap4_idle_data[0];
>
> The assignment at init time (from the next patch) should be done here
> for 44xx, and the next patch can just add OMAP5 support.
>
You don't need that to be differentiated at init at this
patch since only OMAP4 is supported and static assignment takes care
of it. Next patch ofcouse we need to differentiate and hence added
the checks there.
Regards,
Santosh
^ permalink raw reply [flat|nested] 128+ messages in thread
* [PATCH v2 15/18] ARM: OMAP4+: CPUidle: Consolidate idle driver for OMAP5 support
@ 2013-04-04 14:04 ` Santosh Shilimkar
0 siblings, 0 replies; 128+ messages in thread
From: Santosh Shilimkar @ 2013-04-04 14:04 UTC (permalink / raw)
To: linux-arm-kernel
On Thursday 04 April 2013 02:40 AM, Kevin Hilman wrote:
> Santosh Shilimkar <santosh.shilimkar@ti.com> writes:
>
>> The OMAP5 idle driver can re-use most of OMAP4 CPUidle driver
>> implementation. Also the next derivative SOCs are going to re-use
>> the MPUSS so, same driver with minor updates can be re-used.
>>
>> Prepare the code so that its easier to add CPUidle support for
>> OMAP5 devices.
>>
>> Acked-by: Nishanth Menon <nm@ti.com>
>> Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
>> ---
>> arch/arm/mach-omap2/cpuidle44xx.c | 31 ++++++++++++++++---------------
>> 1 file changed, 16 insertions(+), 15 deletions(-)
>>
>> diff --git a/arch/arm/mach-omap2/cpuidle44xx.c b/arch/arm/mach-omap2/cpuidle44xx.c
>> index b8a22f0..ac6d526 100644
>> --- a/arch/arm/mach-omap2/cpuidle44xx.c
>> +++ b/arch/arm/mach-omap2/cpuidle44xx.c
>> @@ -1,7 +1,7 @@
>> /*
>> - * OMAP4 CPU idle Routines
>> + * OMAP4PLUS CPU idle Routines
>
> nit: s/PLUS/+/
>
> in a few other places in this patch also.
>
yes. Will update that.
>> @@ -24,13 +24,13 @@
>> #include "clockdomain.h"
>>
>> /* Machine specific information */
>> -struct omap4_idle_statedata {
>> +struct idle_statedata {
>> u32 cpu_state;
>> u32 mpu_logic_state;
>> u32 mpu_state;
>> };
>>
>> -static struct omap4_idle_statedata omap4_idle_data[] = {
>> +static struct idle_statedata omap4_idle_data[] = {
>> {
>> .cpu_state = PWRDM_POWER_ON,
>> .mpu_state = PWRDM_POWER_ON,
>> @@ -53,11 +53,12 @@ static struct clockdomain *cpu_clkdm[NR_CPUS];
>>
>> static atomic_t abort_barrier;
>> static bool cpu_done[NR_CPUS];
>> +static struct idle_statedata *state_ptr = &omap4_idle_data[0];
>
> The assignment at init time (from the next patch) should be done here
> for 44xx, and the next patch can just add OMAP5 support.
>
You don't need that to be differentiated at init at this
patch since only OMAP4 is supported and static assignment takes care
of it. Next patch ofcouse we need to differentiate and hence added
the checks there.
Regards,
Santosh
^ permalink raw reply [flat|nested] 128+ messages in thread
* Re: [PATCH v2 17/18] ARM: OMAP4+: CPUidle: Add OMAP5 idle driver support
2013-04-03 21:25 ` Kevin Hilman
@ 2013-04-04 14:16 ` Santosh Shilimkar
-1 siblings, 0 replies; 128+ messages in thread
From: Santosh Shilimkar @ 2013-04-04 14:16 UTC (permalink / raw)
To: Kevin Hilman; +Cc: linux-omap, linux-arm-kernel, nm, tony
On Thursday 04 April 2013 02:55 AM, Kevin Hilman wrote:
> Santosh Shilimkar <santosh.shilimkar@ti.com> writes:
>
>> The OMAP5 idle driver can re-use OMAP4 CPUidle driver implementation thanks
>> to compatible MPUSS design.
>>
>> Though unlike OMAP4, on OMAP5 devices, MPUSS CSWR (Close Switch
>> Retention) power states can be achieved with respective power states
>> on CPU0 and CPU1 power domain. This mode was broken on OMAP4 devices
>> because of hardware limitation.
>
> I'm a bit confused by the description here.
>
> I gather from the code that this means that CPU0 and CPU1 can hit CSWR
> independently, correct?
>
They can be programmed independently without any ordering(like
CPU0 last etc), but the actual transition to the low power CSWR
happens together. Till that the first CPU hit WFI remains in WFI
state waiting for other CPU to hit WFI and then both transition
together.
Completely managed inside hardware.
>> Also there is no CPU low power entry order requirement like
>> master CPU etc for CSWR C-state, which is icing on the cake.
>
> Even on secure devices?
>
Yes. On secure devices too. Actually since we don't loose context,
secure entry/exit doesn't come into picture.
>> Code makes use of voting scheme for cluster low power state to support
>> MPUSS CSWR C-state.
>
> The voting scheme and associated locking should be better described
> here, or commented in the code itself.
>
You are right. It deserves some description.
>> Supported OMAP5 CPUidle C-states:
>> C1 - CPU0 ON(WFI) + CPU1 ON(WFI) + MPUSS ON
>> C2 - CPU0 CSWR + CPU1 CSWR + MPUSS CSWR
>> C3 - CPU0 OFF + CPU1 OFF + MPUSS OSWR
>>
>> Acked-by: Nishanth Menon <nm@ti.com>
>> Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
>
> [...]
>
>> +static int omap_enter_idle_smp(struct cpuidle_device *dev,
>> + struct cpuidle_driver *drv,
>> + int index)
>> +{
>> + struct idle_statedata *cx = state_ptr + index;
>> + int cpu_id = smp_processor_id();
>> + unsigned long flag;
>> +
>> + clockevents_notify(CLOCK_EVT_NOTIFY_BROADCAST_ENTER, &cpu_id);
>
> I think the CPUidle core handles the broadcast notification now.
>
Not in mainline yet. And those patches came after my patches and
I don't wanted un-necessary merge dependency, I avoided it. Its trivial
though to drop if from here once the idle next is merged.
>> + raw_spin_lock_irqsave(&mpu_lock, flag);
>> + cx->mpu_state_vote++;
>
> How about using an atomic_t and atomic_inc()/atomic_dec() instead, which
> will avoid the need for a spinlock.
>
Spin lock is not just for the vote variable. I had atomics opps in first
version I gave it to product team. But they found a race condition in
where MPU power state was getting overwritten by other CPU.
> Even with that, it still seems potentially racy. Do you need a memory
> barrier here to be sure that any changes from another CPU are visible
> here, and vice versa?
>
With locks, you don't need barriers since the updated copy is guaranteed.
Can you please elaborate on potential race ? I have given pretty hard
thought and didn't see any race which can be exposed with locks in place.
Regards,
Santosh
^ permalink raw reply [flat|nested] 128+ messages in thread
* [PATCH v2 17/18] ARM: OMAP4+: CPUidle: Add OMAP5 idle driver support
@ 2013-04-04 14:16 ` Santosh Shilimkar
0 siblings, 0 replies; 128+ messages in thread
From: Santosh Shilimkar @ 2013-04-04 14:16 UTC (permalink / raw)
To: linux-arm-kernel
On Thursday 04 April 2013 02:55 AM, Kevin Hilman wrote:
> Santosh Shilimkar <santosh.shilimkar@ti.com> writes:
>
>> The OMAP5 idle driver can re-use OMAP4 CPUidle driver implementation thanks
>> to compatible MPUSS design.
>>
>> Though unlike OMAP4, on OMAP5 devices, MPUSS CSWR (Close Switch
>> Retention) power states can be achieved with respective power states
>> on CPU0 and CPU1 power domain. This mode was broken on OMAP4 devices
>> because of hardware limitation.
>
> I'm a bit confused by the description here.
>
> I gather from the code that this means that CPU0 and CPU1 can hit CSWR
> independently, correct?
>
They can be programmed independently without any ordering(like
CPU0 last etc), but the actual transition to the low power CSWR
happens together. Till that the first CPU hit WFI remains in WFI
state waiting for other CPU to hit WFI and then both transition
together.
Completely managed inside hardware.
>> Also there is no CPU low power entry order requirement like
>> master CPU etc for CSWR C-state, which is icing on the cake.
>
> Even on secure devices?
>
Yes. On secure devices too. Actually since we don't loose context,
secure entry/exit doesn't come into picture.
>> Code makes use of voting scheme for cluster low power state to support
>> MPUSS CSWR C-state.
>
> The voting scheme and associated locking should be better described
> here, or commented in the code itself.
>
You are right. It deserves some description.
>> Supported OMAP5 CPUidle C-states:
>> C1 - CPU0 ON(WFI) + CPU1 ON(WFI) + MPUSS ON
>> C2 - CPU0 CSWR + CPU1 CSWR + MPUSS CSWR
>> C3 - CPU0 OFF + CPU1 OFF + MPUSS OSWR
>>
>> Acked-by: Nishanth Menon <nm@ti.com>
>> Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
>
> [...]
>
>> +static int omap_enter_idle_smp(struct cpuidle_device *dev,
>> + struct cpuidle_driver *drv,
>> + int index)
>> +{
>> + struct idle_statedata *cx = state_ptr + index;
>> + int cpu_id = smp_processor_id();
>> + unsigned long flag;
>> +
>> + clockevents_notify(CLOCK_EVT_NOTIFY_BROADCAST_ENTER, &cpu_id);
>
> I think the CPUidle core handles the broadcast notification now.
>
Not in mainline yet. And those patches came after my patches and
I don't wanted un-necessary merge dependency, I avoided it. Its trivial
though to drop if from here once the idle next is merged.
>> + raw_spin_lock_irqsave(&mpu_lock, flag);
>> + cx->mpu_state_vote++;
>
> How about using an atomic_t and atomic_inc()/atomic_dec() instead, which
> will avoid the need for a spinlock.
>
Spin lock is not just for the vote variable. I had atomics opps in first
version I gave it to product team. But they found a race condition in
where MPU power state was getting overwritten by other CPU.
> Even with that, it still seems potentially racy. Do you need a memory
> barrier here to be sure that any changes from another CPU are visible
> here, and vice versa?
>
With locks, you don't need barriers since the updated copy is guaranteed.
Can you please elaborate on potential race ? I have given pretty hard
thought and didn't see any race which can be exposed with locks in place.
Regards,
Santosh
^ permalink raw reply [flat|nested] 128+ messages in thread
* Re: [PATCH v2 00/18] ARM: OMAP5: PM: Add MPUSS suspend and CPUidle support
2013-04-03 22:52 ` Kevin Hilman
@ 2013-04-04 14:34 ` Santosh Shilimkar
-1 siblings, 0 replies; 128+ messages in thread
From: Santosh Shilimkar @ 2013-04-04 14:34 UTC (permalink / raw)
To: Kevin Hilman; +Cc: linux-omap, linux-arm-kernel, nm, tony
On Thursday 04 April 2013 04:22 AM, Kevin Hilman wrote:
> Hi Santosh,
>
> Santosh Shilimkar <santosh.shilimkar@ti.com> writes:
>
>> Here is the refreshed version(v2) of the OMAP5 PM suspport which was posted
>> earlier (March 1st 2013). Patch-set incorporates comments from Nishant
>> Menon (Thanks for review NM) and his acked-by tags. I would like to get this
>> queued for 3.10 merge window if you are ok with the series.
>
> I did a review of this series with several comments on the individual
> patches.
>
Thanks a lot Kevin. I have addressed all the comments and have
updated patches ready.
> I've already queued most of the CPUidle fixes/cleanups in my
> for_3.10/cleanup/cpuidle branch and will get that to Tony soon. For the
> rest, I suggest probably breaking it up into cleanup/consolidation stuff
> and then OMAP5 support. The latter will depend on all the OMAP5
> data/headers but the cleanup/consolidation stuff could be merged sooner
> (but probably a bit late for v3.10 now.)
>
I have already split the patch-set into 'consolidation' and 'OMAP5
support' since it was straight forward. Need to just build the
branches on top of your branches. So waiting for you to update
your 'for_3.10/*' branches.
For the merge, its your call:)
As you said OMAP5 support(couple of patches) has a dependency
on OMAP5 data files. I will at least make the branches ready on
top of yours.
Regards,
Santosh
^ permalink raw reply [flat|nested] 128+ messages in thread
* [PATCH v2 00/18] ARM: OMAP5: PM: Add MPUSS suspend and CPUidle support
@ 2013-04-04 14:34 ` Santosh Shilimkar
0 siblings, 0 replies; 128+ messages in thread
From: Santosh Shilimkar @ 2013-04-04 14:34 UTC (permalink / raw)
To: linux-arm-kernel
On Thursday 04 April 2013 04:22 AM, Kevin Hilman wrote:
> Hi Santosh,
>
> Santosh Shilimkar <santosh.shilimkar@ti.com> writes:
>
>> Here is the refreshed version(v2) of the OMAP5 PM suspport which was posted
>> earlier (March 1st 2013). Patch-set incorporates comments from Nishant
>> Menon (Thanks for review NM) and his acked-by tags. I would like to get this
>> queued for 3.10 merge window if you are ok with the series.
>
> I did a review of this series with several comments on the individual
> patches.
>
Thanks a lot Kevin. I have addressed all the comments and have
updated patches ready.
> I've already queued most of the CPUidle fixes/cleanups in my
> for_3.10/cleanup/cpuidle branch and will get that to Tony soon. For the
> rest, I suggest probably breaking it up into cleanup/consolidation stuff
> and then OMAP5 support. The latter will depend on all the OMAP5
> data/headers but the cleanup/consolidation stuff could be merged sooner
> (but probably a bit late for v3.10 now.)
>
I have already split the patch-set into 'consolidation' and 'OMAP5
support' since it was straight forward. Need to just build the
branches on top of your branches. So waiting for you to update
your 'for_3.10/*' branches.
For the merge, its your call:)
As you said OMAP5 support(couple of patches) has a dependency
on OMAP5 data files. I will at least make the branches ready on
top of yours.
Regards,
Santosh
^ permalink raw reply [flat|nested] 128+ messages in thread
* Re: [PATCH v2 00/18] ARM: OMAP5: PM: Add MPUSS suspend and CPUidle support
2013-04-04 14:34 ` Santosh Shilimkar
@ 2013-04-04 16:49 ` Santosh Shilimkar
-1 siblings, 0 replies; 128+ messages in thread
From: Santosh Shilimkar @ 2013-04-04 16:49 UTC (permalink / raw)
To: Kevin Hilman; +Cc: linux-omap, linux-arm-kernel, nm, tony
On Thursday 04 April 2013 08:04 PM, Santosh Shilimkar wrote:
> On Thursday 04 April 2013 04:22 AM, Kevin Hilman wrote:
>> Hi Santosh,
>>
>> Santosh Shilimkar <santosh.shilimkar@ti.com> writes:
>>
>>> Here is the refreshed version(v2) of the OMAP5 PM suspport which was posted
>>> earlier (March 1st 2013). Patch-set incorporates comments from Nishant
>>> Menon (Thanks for review NM) and his acked-by tags. I would like to get this
>>> queued for 3.10 merge window if you are ok with the series.
>>
>> I did a review of this series with several comments on the individual
>> patches.
>>
> Thanks a lot Kevin. I have addressed all the comments and have
> updated patches ready.
>
>> I've already queued most of the CPUidle fixes/cleanups in my
>> for_3.10/cleanup/cpuidle branch and will get that to Tony soon. For the
>> rest, I suggest probably breaking it up into cleanup/consolidation stuff
>> and then OMAP5 support. The latter will depend on all the OMAP5
>> data/headers but the cleanup/consolidation stuff could be merged sooner
>> (but probably a bit late for v3.10 now.)
>>
> I have already split the patch-set into 'consolidation' and 'OMAP5
> support' since it was straight forward. Need to just build the
> branches on top of your branches. So waiting for you to update
> your 'for_3.10/*' branches.
>
> For the merge, its your call:)
> As you said OMAP5 support(couple of patches) has a dependency
> on OMAP5 data files. I will at least make the branches ready on
> top of yours.
>
After looking at your tree, looks like the branches are already
there. Idle branch name is not for_3.10/fixes/cpuidle though :)
So I created 'for_3.10/omap_pm-cleanup' and 'for_3.10/omap5_pm_v2'
and pushed on my git tree [1] in case you would like to have
a look. I briefly tested them on OMAP4 device with
CPUidle enabled and they seems to work fine. Will do OMAP5
testing tomorrow and then post the updated patches on list.
Regards,
Santosh
[1] git://git.kernel.org/pub/scm/linux/kernel/git/ssantosh/linux.git
^ permalink raw reply [flat|nested] 128+ messages in thread
* [PATCH v2 00/18] ARM: OMAP5: PM: Add MPUSS suspend and CPUidle support
@ 2013-04-04 16:49 ` Santosh Shilimkar
0 siblings, 0 replies; 128+ messages in thread
From: Santosh Shilimkar @ 2013-04-04 16:49 UTC (permalink / raw)
To: linux-arm-kernel
On Thursday 04 April 2013 08:04 PM, Santosh Shilimkar wrote:
> On Thursday 04 April 2013 04:22 AM, Kevin Hilman wrote:
>> Hi Santosh,
>>
>> Santosh Shilimkar <santosh.shilimkar@ti.com> writes:
>>
>>> Here is the refreshed version(v2) of the OMAP5 PM suspport which was posted
>>> earlier (March 1st 2013). Patch-set incorporates comments from Nishant
>>> Menon (Thanks for review NM) and his acked-by tags. I would like to get this
>>> queued for 3.10 merge window if you are ok with the series.
>>
>> I did a review of this series with several comments on the individual
>> patches.
>>
> Thanks a lot Kevin. I have addressed all the comments and have
> updated patches ready.
>
>> I've already queued most of the CPUidle fixes/cleanups in my
>> for_3.10/cleanup/cpuidle branch and will get that to Tony soon. For the
>> rest, I suggest probably breaking it up into cleanup/consolidation stuff
>> and then OMAP5 support. The latter will depend on all the OMAP5
>> data/headers but the cleanup/consolidation stuff could be merged sooner
>> (but probably a bit late for v3.10 now.)
>>
> I have already split the patch-set into 'consolidation' and 'OMAP5
> support' since it was straight forward. Need to just build the
> branches on top of your branches. So waiting for you to update
> your 'for_3.10/*' branches.
>
> For the merge, its your call:)
> As you said OMAP5 support(couple of patches) has a dependency
> on OMAP5 data files. I will at least make the branches ready on
> top of yours.
>
After looking at your tree, looks like the branches are already
there. Idle branch name is not for_3.10/fixes/cpuidle though :)
So I created 'for_3.10/omap_pm-cleanup' and 'for_3.10/omap5_pm_v2'
and pushed on my git tree [1] in case you would like to have
a look. I briefly tested them on OMAP4 device with
CPUidle enabled and they seems to work fine. Will do OMAP5
testing tomorrow and then post the updated patches on list.
Regards,
Santosh
[1] git://git.kernel.org/pub/scm/linux/kernel/git/ssantosh/linux.git
^ permalink raw reply [flat|nested] 128+ messages in thread
* Re: [PATCH v2 08/18] ARM: OMAP5: PM: Add CPU power off in hotplug path
2013-04-04 13:23 ` Santosh Shilimkar
@ 2013-04-04 17:31 ` Kevin Hilman
-1 siblings, 0 replies; 128+ messages in thread
From: Kevin Hilman @ 2013-04-04 17:31 UTC (permalink / raw)
To: Santosh Shilimkar; +Cc: linux-omap, linux-arm-kernel, nm, tony
Santosh Shilimkar <santosh.shilimkar@ti.com> writes:
> On Thursday 04 April 2013 02:19 AM, Kevin Hilman wrote:
>> Santosh Shilimkar <santosh.shilimkar@ti.com> writes:
>>
>>> Add power management code to handle the CPU off mode to enable CPUP hotplug
>>> mode for OMAP5 devices. Separate suspend finisher is used for OMAP5(Cortex-A15)
>>> because it doesn't use SCU power status register and external PL310 L2 cache
>>> which makes code flow bit different.
>>>
>>> Acked-by: Nishanth Menon <nm@ti.com>
>>> Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
>>
>> [...]
>>
>>> @@ -436,14 +445,21 @@ int __init omap4_mpuss_init(void)
>>>
>>> if (cpu_is_omap44xx()) {
>>> omap_pm_ops.finish_suspend = omap4_finish_suspend;
>>> + omap_pm_ops.hotplug_restart = omap_secondary_startup;
>>> omap_pm_ops.resume = omap4_cpu_resume;
>>> omap_pm_ops.scu_prepare = scu_pwrst_prepare;
>>> cpu_context_offset = OMAP4_RM_CPU0_CPU0_CONTEXT_OFFSET;
>>> } else if (soc_is_omap54xx()) {
>>> + omap_pm_ops.finish_suspend = omap5_finish_suspend;
>>> + omap_pm_ops.hotplug_restart = omap5_secondary_startup;
>>> cpu_context_offset = OMAP54XX_RM_CPU0_CPU0_CONTEXT_OFFSET;
>>> enable_mercury_retention_mode();
>>> }
>>>
>>> + /* Over-write the OMAP4 hook to take care of ROM BUG */
>>> + if (cpu_is_omap446x())
>>> + omap_pm_ops.hotplug_restart = omap_secondary_startup_4460;
>>
>> A couple nits...
>>
>> I think this would go better at the end of the 'if omap44xx' block
>> above.
>>
> Nishant commented on this as well. The indentation was looking ugly
> and I thought its better to have this BUG hunk separate. I prefer
> it this way though if you really insist, i have to change it.
I insist.
>> Also, while you're hear, maybe it's time to rename the current secondary
>> startup functions to match the new one. IOW omap4_..., omap4460_... and omap5_...
>>
> Good idea. Will do it in a separate patch since these have been there in few
> files.
OK.
Thanks,
Kevin
^ permalink raw reply [flat|nested] 128+ messages in thread
* [PATCH v2 08/18] ARM: OMAP5: PM: Add CPU power off in hotplug path
@ 2013-04-04 17:31 ` Kevin Hilman
0 siblings, 0 replies; 128+ messages in thread
From: Kevin Hilman @ 2013-04-04 17:31 UTC (permalink / raw)
To: linux-arm-kernel
Santosh Shilimkar <santosh.shilimkar@ti.com> writes:
> On Thursday 04 April 2013 02:19 AM, Kevin Hilman wrote:
>> Santosh Shilimkar <santosh.shilimkar@ti.com> writes:
>>
>>> Add power management code to handle the CPU off mode to enable CPUP hotplug
>>> mode for OMAP5 devices. Separate suspend finisher is used for OMAP5(Cortex-A15)
>>> because it doesn't use SCU power status register and external PL310 L2 cache
>>> which makes code flow bit different.
>>>
>>> Acked-by: Nishanth Menon <nm@ti.com>
>>> Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
>>
>> [...]
>>
>>> @@ -436,14 +445,21 @@ int __init omap4_mpuss_init(void)
>>>
>>> if (cpu_is_omap44xx()) {
>>> omap_pm_ops.finish_suspend = omap4_finish_suspend;
>>> + omap_pm_ops.hotplug_restart = omap_secondary_startup;
>>> omap_pm_ops.resume = omap4_cpu_resume;
>>> omap_pm_ops.scu_prepare = scu_pwrst_prepare;
>>> cpu_context_offset = OMAP4_RM_CPU0_CPU0_CONTEXT_OFFSET;
>>> } else if (soc_is_omap54xx()) {
>>> + omap_pm_ops.finish_suspend = omap5_finish_suspend;
>>> + omap_pm_ops.hotplug_restart = omap5_secondary_startup;
>>> cpu_context_offset = OMAP54XX_RM_CPU0_CPU0_CONTEXT_OFFSET;
>>> enable_mercury_retention_mode();
>>> }
>>>
>>> + /* Over-write the OMAP4 hook to take care of ROM BUG */
>>> + if (cpu_is_omap446x())
>>> + omap_pm_ops.hotplug_restart = omap_secondary_startup_4460;
>>
>> A couple nits...
>>
>> I think this would go better at the end of the 'if omap44xx' block
>> above.
>>
> Nishant commented on this as well. The indentation was looking ugly
> and I thought its better to have this BUG hunk separate. I prefer
> it this way though if you really insist, i have to change it.
I insist.
>> Also, while you're hear, maybe it's time to rename the current secondary
>> startup functions to match the new one. IOW omap4_..., omap4460_... and omap5_...
>>
> Good idea. Will do it in a separate patch since these have been there in few
> files.
OK.
Thanks,
Kevin
^ permalink raw reply [flat|nested] 128+ messages in thread
* Re: [PATCH v2 09/18] ARM: OMAP4+: PM: Restore CPU power state to ON with clockdomain force wakeup method
2013-04-04 13:37 ` Santosh Shilimkar
@ 2013-04-04 17:42 ` Kevin Hilman
-1 siblings, 0 replies; 128+ messages in thread
From: Kevin Hilman @ 2013-04-04 17:42 UTC (permalink / raw)
To: Santosh Shilimkar; +Cc: linux-omap, linux-arm-kernel, nm, tony
Santosh Shilimkar <santosh.shilimkar@ti.com> writes:
> On Thursday 04 April 2013 02:24 AM, Kevin Hilman wrote:
>> Santosh Shilimkar <santosh.shilimkar@ti.com> writes:
>>
>>> While waking up CPU from off state using clock domain force wakeup, restore
>>> the CPU power state to ON state before putting CPU clock domain under
>>> hardware control. Otherwise CPU wakeup might fail. The change is recommended
>>> for all OMAP4+ devices though the PRCM weakness was observed on OMAP5
>>> devices first.
>>
>> Sounds reasonable, but can you describe the "weakness" a little more?
>>
>> IOW, what exactly happens if this is not done? It sounds like the CPU
>> might immediately go back to retention, but how does that happen unless
>> it does a WFI?
>>
> Its more of lock-up inside the hardware state machine and results
> are UN-predictable. We have seen hard-locks most of the time where system
> is just frozen. The hardware gets into wrong state machine if the power
> domain state isn't restored. I will add this information to changelog.
>
>> Also, this sounds like a fix to me, and should probably be broken out
>> accordingly.
>>
> Yeah. You mean a separate patch from the series, right ? This patch
> actually can be independently added.
>
> In case you decide to apply it for the fixes branch, updated patch
> at end of the email.
Curious which branch you applied it to? It didn't apply cleanly to
v3.9-rc5 (but did with fuzz).
So I've now added it to my for_3.10/fixes/pm branch.
Kevin
> From a0cef44760d859b63a34603010f8c0621da4b8ab Mon Sep 17 00:00:00 2001
> From: Santosh Shilimkar <santosh.shilimkar@ti.com>
> Date: Fri, 8 Feb 2013 22:50:58 +0530
> Subject: [PATCH] ARM: OMAP4+: PM: Restore CPU power state to ON with
> clockdomain force wakeup method
>
> While waking up CPU from off state using clock domain force wakeup, restore
> the CPU power state to ON state before putting CPU clock domain under
> hardware control. Otherwise CPU wakeup might fail. The change is recommended
> for all OMAP4+ devices though the PRCM weakness was observed on OMAP5
> devices first.
>
> As a result of weakness, lock-up is observed inside the hardware state
> machine of local CPU PRCM and results are UN-predictable as per designers.
> In software testing, we have seen hard-locks most of the time where system
> gets frozen. With power domain state restored, system behaves correctly.
>
> So update the code accordingly.
>
> Acked-by: Nishanth Menon <nm@ti.com>
> Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
> ---
> arch/arm/mach-omap2/cpuidle44xx.c | 1 +
> arch/arm/mach-omap2/omap-smp.c | 12 ++++++++++--
> 2 files changed, 11 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/cpuidle44xx.c b/arch/arm/mach-omap2/cpuidle44xx.c
> index 944e64a..9de47a7 100644
> --- a/arch/arm/mach-omap2/cpuidle44xx.c
> +++ b/arch/arm/mach-omap2/cpuidle44xx.c
> @@ -131,6 +131,7 @@ static int omap4_enter_idle_coupled(struct cpuidle_device *dev,
> /* Wakeup CPU1 only if it is not offlined */
> if (dev->cpu == 0 && cpumask_test_cpu(1, cpu_online_mask)) {
> clkdm_wakeup(cpu_clkdm[1]);
> + omap_set_pwrdm_state(cpu_pd[1], PWRDM_POWER_ON);
> clkdm_allow_idle(cpu_clkdm[1]);
> }
>
> diff --git a/arch/arm/mach-omap2/omap-smp.c b/arch/arm/mach-omap2/omap-smp.c
> index 5b20165..8106e8d 100644
> --- a/arch/arm/mach-omap2/omap-smp.c
> +++ b/arch/arm/mach-omap2/omap-smp.c
> @@ -83,6 +83,7 @@ static int __cpuinit omap4_boot_secondary(unsigned int cpu, struct task_struct *
> {
> static struct clockdomain *cpu1_clkdm;
> static bool booted;
> + static struct powerdomain *cpu1_pwrdm;
> void __iomem *base = omap_get_wakeupgen_base();
>
> /*
> @@ -102,8 +103,10 @@ static int __cpuinit omap4_boot_secondary(unsigned int cpu, struct task_struct *
> else
> __raw_writel(0x20, base + OMAP_AUX_CORE_BOOT_0);
>
> - if (!cpu1_clkdm)
> + if (!cpu1_clkdm && !cpu1_pwrdm) {
> cpu1_clkdm = clkdm_lookup("mpu1_clkdm");
> + cpu1_pwrdm = pwrdm_lookup("cpu1_pwrdm");
> + }
>
> /*
> * The SGI(Software Generated Interrupts) are not wakeup capable
> @@ -116,7 +119,7 @@ static int __cpuinit omap4_boot_secondary(unsigned int cpu, struct task_struct *
> * Section :
> * 4.3.4.2 Power States of CPU0 and CPU1
> */
> - if (booted) {
> + if (booted && cpu1_pwrdm && cpu1_clkdm) {
> /*
> * GIC distributor control register has changed between
> * CortexA9 r1pX and r2pX. The Control Register secure
> @@ -137,7 +140,12 @@ static int __cpuinit omap4_boot_secondary(unsigned int cpu, struct task_struct *
> gic_dist_disable();
> }
>
> + /*
> + * Ensure that CPU power state is set to ON to avoid CPU
> + * powerdomain transition on wfi
> + */
> clkdm_wakeup(cpu1_clkdm);
> + omap_set_pwrdm_state(cpu1_pwrdm, PWRDM_POWER_ON);
> clkdm_allow_idle(cpu1_clkdm);
>
> if (IS_PM44XX_ERRATUM(PM_OMAP4_ROM_SMP_BOOT_ERRATUM_GICD)) {
^ permalink raw reply [flat|nested] 128+ messages in thread
* [PATCH v2 09/18] ARM: OMAP4+: PM: Restore CPU power state to ON with clockdomain force wakeup method
@ 2013-04-04 17:42 ` Kevin Hilman
0 siblings, 0 replies; 128+ messages in thread
From: Kevin Hilman @ 2013-04-04 17:42 UTC (permalink / raw)
To: linux-arm-kernel
Santosh Shilimkar <santosh.shilimkar@ti.com> writes:
> On Thursday 04 April 2013 02:24 AM, Kevin Hilman wrote:
>> Santosh Shilimkar <santosh.shilimkar@ti.com> writes:
>>
>>> While waking up CPU from off state using clock domain force wakeup, restore
>>> the CPU power state to ON state before putting CPU clock domain under
>>> hardware control. Otherwise CPU wakeup might fail. The change is recommended
>>> for all OMAP4+ devices though the PRCM weakness was observed on OMAP5
>>> devices first.
>>
>> Sounds reasonable, but can you describe the "weakness" a little more?
>>
>> IOW, what exactly happens if this is not done? It sounds like the CPU
>> might immediately go back to retention, but how does that happen unless
>> it does a WFI?
>>
> Its more of lock-up inside the hardware state machine and results
> are UN-predictable. We have seen hard-locks most of the time where system
> is just frozen. The hardware gets into wrong state machine if the power
> domain state isn't restored. I will add this information to changelog.
>
>> Also, this sounds like a fix to me, and should probably be broken out
>> accordingly.
>>
> Yeah. You mean a separate patch from the series, right ? This patch
> actually can be independently added.
>
> In case you decide to apply it for the fixes branch, updated patch
> at end of the email.
Curious which branch you applied it to? It didn't apply cleanly to
v3.9-rc5 (but did with fuzz).
So I've now added it to my for_3.10/fixes/pm branch.
Kevin
> From a0cef44760d859b63a34603010f8c0621da4b8ab Mon Sep 17 00:00:00 2001
> From: Santosh Shilimkar <santosh.shilimkar@ti.com>
> Date: Fri, 8 Feb 2013 22:50:58 +0530
> Subject: [PATCH] ARM: OMAP4+: PM: Restore CPU power state to ON with
> clockdomain force wakeup method
>
> While waking up CPU from off state using clock domain force wakeup, restore
> the CPU power state to ON state before putting CPU clock domain under
> hardware control. Otherwise CPU wakeup might fail. The change is recommended
> for all OMAP4+ devices though the PRCM weakness was observed on OMAP5
> devices first.
>
> As a result of weakness, lock-up is observed inside the hardware state
> machine of local CPU PRCM and results are UN-predictable as per designers.
> In software testing, we have seen hard-locks most of the time where system
> gets frozen. With power domain state restored, system behaves correctly.
>
> So update the code accordingly.
>
> Acked-by: Nishanth Menon <nm@ti.com>
> Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
> ---
> arch/arm/mach-omap2/cpuidle44xx.c | 1 +
> arch/arm/mach-omap2/omap-smp.c | 12 ++++++++++--
> 2 files changed, 11 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/cpuidle44xx.c b/arch/arm/mach-omap2/cpuidle44xx.c
> index 944e64a..9de47a7 100644
> --- a/arch/arm/mach-omap2/cpuidle44xx.c
> +++ b/arch/arm/mach-omap2/cpuidle44xx.c
> @@ -131,6 +131,7 @@ static int omap4_enter_idle_coupled(struct cpuidle_device *dev,
> /* Wakeup CPU1 only if it is not offlined */
> if (dev->cpu == 0 && cpumask_test_cpu(1, cpu_online_mask)) {
> clkdm_wakeup(cpu_clkdm[1]);
> + omap_set_pwrdm_state(cpu_pd[1], PWRDM_POWER_ON);
> clkdm_allow_idle(cpu_clkdm[1]);
> }
>
> diff --git a/arch/arm/mach-omap2/omap-smp.c b/arch/arm/mach-omap2/omap-smp.c
> index 5b20165..8106e8d 100644
> --- a/arch/arm/mach-omap2/omap-smp.c
> +++ b/arch/arm/mach-omap2/omap-smp.c
> @@ -83,6 +83,7 @@ static int __cpuinit omap4_boot_secondary(unsigned int cpu, struct task_struct *
> {
> static struct clockdomain *cpu1_clkdm;
> static bool booted;
> + static struct powerdomain *cpu1_pwrdm;
> void __iomem *base = omap_get_wakeupgen_base();
>
> /*
> @@ -102,8 +103,10 @@ static int __cpuinit omap4_boot_secondary(unsigned int cpu, struct task_struct *
> else
> __raw_writel(0x20, base + OMAP_AUX_CORE_BOOT_0);
>
> - if (!cpu1_clkdm)
> + if (!cpu1_clkdm && !cpu1_pwrdm) {
> cpu1_clkdm = clkdm_lookup("mpu1_clkdm");
> + cpu1_pwrdm = pwrdm_lookup("cpu1_pwrdm");
> + }
>
> /*
> * The SGI(Software Generated Interrupts) are not wakeup capable
> @@ -116,7 +119,7 @@ static int __cpuinit omap4_boot_secondary(unsigned int cpu, struct task_struct *
> * Section :
> * 4.3.4.2 Power States of CPU0 and CPU1
> */
> - if (booted) {
> + if (booted && cpu1_pwrdm && cpu1_clkdm) {
> /*
> * GIC distributor control register has changed between
> * CortexA9 r1pX and r2pX. The Control Register secure
> @@ -137,7 +140,12 @@ static int __cpuinit omap4_boot_secondary(unsigned int cpu, struct task_struct *
> gic_dist_disable();
> }
>
> + /*
> + * Ensure that CPU power state is set to ON to avoid CPU
> + * powerdomain transition on wfi
> + */
> clkdm_wakeup(cpu1_clkdm);
> + omap_set_pwrdm_state(cpu1_pwrdm, PWRDM_POWER_ON);
> clkdm_allow_idle(cpu1_clkdm);
>
> if (IS_PM44XX_ERRATUM(PM_OMAP4_ROM_SMP_BOOT_ERRATUM_GICD)) {
^ permalink raw reply [flat|nested] 128+ messages in thread
* Re: [PATCH v2 17/18] ARM: OMAP4+: CPUidle: Add OMAP5 idle driver support
2013-04-04 14:16 ` Santosh Shilimkar
@ 2013-04-04 17:55 ` Kevin Hilman
-1 siblings, 0 replies; 128+ messages in thread
From: Kevin Hilman @ 2013-04-04 17:55 UTC (permalink / raw)
To: Santosh Shilimkar; +Cc: linux-omap, linux-arm-kernel, nm, tony
Santosh Shilimkar <santosh.shilimkar@ti.com> writes:
> On Thursday 04 April 2013 02:55 AM, Kevin Hilman wrote:
>> Santosh Shilimkar <santosh.shilimkar@ti.com> writes:
>>
>>> The OMAP5 idle driver can re-use OMAP4 CPUidle driver implementation thanks
>>> to compatible MPUSS design.
>>>
>>> Though unlike OMAP4, on OMAP5 devices, MPUSS CSWR (Close Switch
>>> Retention) power states can be achieved with respective power states
>>> on CPU0 and CPU1 power domain. This mode was broken on OMAP4 devices
>>> because of hardware limitation.
>>
>> I'm a bit confused by the description here.
>>
>> I gather from the code that this means that CPU0 and CPU1 can hit CSWR
>> independently, correct?
>>
> They can be programmed independently without any ordering(like
> CPU0 last etc), but the actual transition to the low power CSWR
> happens together. Till that the first CPU hit WFI remains in WFI
> state waiting for other CPU to hit WFI and then both transition
> together.
> Completely managed inside hardware.
OK, elaborating this in the changelog would be helpful. Use the "will I
understand this changelog in a year" rule to see if the changelog is
detailed enough. Or better, "will Kevin understand this changelog in a
year." (hint: the answer is usually no.) ;)
>>> Also there is no CPU low power entry order requirement like
>>> master CPU etc for CSWR C-state, which is icing on the cake.
>>
>> Even on secure devices?
>>
> Yes. On secure devices too. Actually since we don't loose context,
> secure entry/exit doesn't come into picture.
>
>>> Code makes use of voting scheme for cluster low power state to support
>>> MPUSS CSWR C-state.
>>
>> The voting scheme and associated locking should be better described
>> here, or commented in the code itself.
>>
> You are right. It deserves some description.
>
>>> Supported OMAP5 CPUidle C-states:
>>> C1 - CPU0 ON(WFI) + CPU1 ON(WFI) + MPUSS ON
>>> C2 - CPU0 CSWR + CPU1 CSWR + MPUSS CSWR
>>> C3 - CPU0 OFF + CPU1 OFF + MPUSS OSWR
>>>
>>> Acked-by: Nishanth Menon <nm@ti.com>
>>> Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
>>
>> [...]
>>
>>> +static int omap_enter_idle_smp(struct cpuidle_device *dev,
>>> + struct cpuidle_driver *drv,
>>> + int index)
>>> +{
>>> + struct idle_statedata *cx = state_ptr + index;
>>> + int cpu_id = smp_processor_id();
>>> + unsigned long flag;
>>> +
>>> + clockevents_notify(CLOCK_EVT_NOTIFY_BROADCAST_ENTER, &cpu_id);
>>
>> I think the CPUidle core handles the broadcast notification now.
>>
> Not in mainline yet. And those patches came after my patches and
> I don't wanted un-necessary merge dependency, I avoided it. Its trivial
> though to drop if from here once the idle next is merged.
OK.
I believe that stuff is already queued, no? Maybe ahave this as an
add-on separate patch that can be used for your loal testing, but does
not go upstream.
I would only include this if you're sure the other series is not going
upstream.
>>> + raw_spin_lock_irqsave(&mpu_lock, flag);
>>> + cx->mpu_state_vote++;
>>
>> How about using an atomic_t and atomic_inc()/atomic_dec() instead, which
>> will avoid the need for a spinlock.
>>
> Spin lock is not just for the vote variable. I had atomics opps in first
> version I gave it to product team. But they found a race condition in
> where MPU power state was getting overwritten by other CPU.
>
>> Even with that, it still seems potentially racy. Do you need a memory
>> barrier here to be sure that any changes from another CPU are visible
>> here, and vice versa?
>>
> With locks, you don't need barriers since the updated copy is guaranteed.
It's guaranteed because the spinlock implementation uses barriers.
> Can you please elaborate on potential race ? I have given pretty hard
> thought and didn't see any race which can be exposed with locks in place.
I was referring to using atomic ops. With atomic ops, you'd need an
explicit barrier (which you're getting inside the spinlock
implementation)
That being said, I have not thought through all the corner cases as you
have, so I'll defer to your choice (as long as it's well documented.)
If you decide to stick with spinlocks, be sure to describe all of what
the spinlock is protecting, and why.
Thanks,
Kevin
^ permalink raw reply [flat|nested] 128+ messages in thread
* [PATCH v2 17/18] ARM: OMAP4+: CPUidle: Add OMAP5 idle driver support
@ 2013-04-04 17:55 ` Kevin Hilman
0 siblings, 0 replies; 128+ messages in thread
From: Kevin Hilman @ 2013-04-04 17:55 UTC (permalink / raw)
To: linux-arm-kernel
Santosh Shilimkar <santosh.shilimkar@ti.com> writes:
> On Thursday 04 April 2013 02:55 AM, Kevin Hilman wrote:
>> Santosh Shilimkar <santosh.shilimkar@ti.com> writes:
>>
>>> The OMAP5 idle driver can re-use OMAP4 CPUidle driver implementation thanks
>>> to compatible MPUSS design.
>>>
>>> Though unlike OMAP4, on OMAP5 devices, MPUSS CSWR (Close Switch
>>> Retention) power states can be achieved with respective power states
>>> on CPU0 and CPU1 power domain. This mode was broken on OMAP4 devices
>>> because of hardware limitation.
>>
>> I'm a bit confused by the description here.
>>
>> I gather from the code that this means that CPU0 and CPU1 can hit CSWR
>> independently, correct?
>>
> They can be programmed independently without any ordering(like
> CPU0 last etc), but the actual transition to the low power CSWR
> happens together. Till that the first CPU hit WFI remains in WFI
> state waiting for other CPU to hit WFI and then both transition
> together.
> Completely managed inside hardware.
OK, elaborating this in the changelog would be helpful. Use the "will I
understand this changelog in a year" rule to see if the changelog is
detailed enough. Or better, "will Kevin understand this changelog in a
year." (hint: the answer is usually no.) ;)
>>> Also there is no CPU low power entry order requirement like
>>> master CPU etc for CSWR C-state, which is icing on the cake.
>>
>> Even on secure devices?
>>
> Yes. On secure devices too. Actually since we don't loose context,
> secure entry/exit doesn't come into picture.
>
>>> Code makes use of voting scheme for cluster low power state to support
>>> MPUSS CSWR C-state.
>>
>> The voting scheme and associated locking should be better described
>> here, or commented in the code itself.
>>
> You are right. It deserves some description.
>
>>> Supported OMAP5 CPUidle C-states:
>>> C1 - CPU0 ON(WFI) + CPU1 ON(WFI) + MPUSS ON
>>> C2 - CPU0 CSWR + CPU1 CSWR + MPUSS CSWR
>>> C3 - CPU0 OFF + CPU1 OFF + MPUSS OSWR
>>>
>>> Acked-by: Nishanth Menon <nm@ti.com>
>>> Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
>>
>> [...]
>>
>>> +static int omap_enter_idle_smp(struct cpuidle_device *dev,
>>> + struct cpuidle_driver *drv,
>>> + int index)
>>> +{
>>> + struct idle_statedata *cx = state_ptr + index;
>>> + int cpu_id = smp_processor_id();
>>> + unsigned long flag;
>>> +
>>> + clockevents_notify(CLOCK_EVT_NOTIFY_BROADCAST_ENTER, &cpu_id);
>>
>> I think the CPUidle core handles the broadcast notification now.
>>
> Not in mainline yet. And those patches came after my patches and
> I don't wanted un-necessary merge dependency, I avoided it. Its trivial
> though to drop if from here once the idle next is merged.
OK.
I believe that stuff is already queued, no? Maybe ahave this as an
add-on separate patch that can be used for your loal testing, but does
not go upstream.
I would only include this if you're sure the other series is not going
upstream.
>>> + raw_spin_lock_irqsave(&mpu_lock, flag);
>>> + cx->mpu_state_vote++;
>>
>> How about using an atomic_t and atomic_inc()/atomic_dec() instead, which
>> will avoid the need for a spinlock.
>>
> Spin lock is not just for the vote variable. I had atomics opps in first
> version I gave it to product team. But they found a race condition in
> where MPU power state was getting overwritten by other CPU.
>
>> Even with that, it still seems potentially racy. Do you need a memory
>> barrier here to be sure that any changes from another CPU are visible
>> here, and vice versa?
>>
> With locks, you don't need barriers since the updated copy is guaranteed.
It's guaranteed because the spinlock implementation uses barriers.
> Can you please elaborate on potential race ? I have given pretty hard
> thought and didn't see any race which can be exposed with locks in place.
I was referring to using atomic ops. With atomic ops, you'd need an
explicit barrier (which you're getting inside the spinlock
implementation)
That being said, I have not thought through all the corner cases as you
have, so I'll defer to your choice (as long as it's well documented.)
If you decide to stick with spinlocks, be sure to describe all of what
the spinlock is protecting, and why.
Thanks,
Kevin
^ permalink raw reply [flat|nested] 128+ messages in thread
* Re: [PATCH v2 00/18] ARM: OMAP5: PM: Add MPUSS suspend and CPUidle support
2013-04-04 16:49 ` Santosh Shilimkar
@ 2013-04-04 17:57 ` Kevin Hilman
-1 siblings, 0 replies; 128+ messages in thread
From: Kevin Hilman @ 2013-04-04 17:57 UTC (permalink / raw)
To: Santosh Shilimkar; +Cc: linux-omap, linux-arm-kernel, nm, tony
Santosh Shilimkar <santosh.shilimkar@ti.com> writes:
> On Thursday 04 April 2013 08:04 PM, Santosh Shilimkar wrote:
>> On Thursday 04 April 2013 04:22 AM, Kevin Hilman wrote:
>>> Hi Santosh,
>>>
>>> Santosh Shilimkar <santosh.shilimkar@ti.com> writes:
>>>
>>>> Here is the refreshed version(v2) of the OMAP5 PM suspport which was posted
>>>> earlier (March 1st 2013). Patch-set incorporates comments from Nishant
>>>> Menon (Thanks for review NM) and his acked-by tags. I would like to get this
>>>> queued for 3.10 merge window if you are ok with the series.
>>>
>>> I did a review of this series with several comments on the individual
>>> patches.
>>>
>> Thanks a lot Kevin. I have addressed all the comments and have
>> updated patches ready.
>>
>>> I've already queued most of the CPUidle fixes/cleanups in my
>>> for_3.10/cleanup/cpuidle branch and will get that to Tony soon. For the
>>> rest, I suggest probably breaking it up into cleanup/consolidation stuff
>>> and then OMAP5 support. The latter will depend on all the OMAP5
>>> data/headers but the cleanup/consolidation stuff could be merged sooner
>>> (but probably a bit late for v3.10 now.)
>>>
>> I have already split the patch-set into 'consolidation' and 'OMAP5
>> support' since it was straight forward. Need to just build the
>> branches on top of your branches. So waiting for you to update
>> your 'for_3.10/*' branches.
>>
>> For the merge, its your call:)
>> As you said OMAP5 support(couple of patches) has a dependency
>> on OMAP5 data files. I will at least make the branches ready on
>> top of yours.
>>
> After looking at your tree, looks like the branches are already
> there. Idle branch name is not for_3.10/fixes/cpuidle though :)
oh, sorry. I changed it to 'cleanup'.
> So I created 'for_3.10/omap_pm-cleanup' and 'for_3.10/omap5_pm_v2'
> and pushed on my git tree [1] in case you would like to have
> a look. I briefly tested them on OMAP4 device with
> CPUidle enabled and they seems to work fine. Will do OMAP5
> testing tomorrow and then post the updated patches on list.
Perfect, thanks.
Kevin
^ permalink raw reply [flat|nested] 128+ messages in thread
* [PATCH v2 00/18] ARM: OMAP5: PM: Add MPUSS suspend and CPUidle support
@ 2013-04-04 17:57 ` Kevin Hilman
0 siblings, 0 replies; 128+ messages in thread
From: Kevin Hilman @ 2013-04-04 17:57 UTC (permalink / raw)
To: linux-arm-kernel
Santosh Shilimkar <santosh.shilimkar@ti.com> writes:
> On Thursday 04 April 2013 08:04 PM, Santosh Shilimkar wrote:
>> On Thursday 04 April 2013 04:22 AM, Kevin Hilman wrote:
>>> Hi Santosh,
>>>
>>> Santosh Shilimkar <santosh.shilimkar@ti.com> writes:
>>>
>>>> Here is the refreshed version(v2) of the OMAP5 PM suspport which was posted
>>>> earlier (March 1st 2013). Patch-set incorporates comments from Nishant
>>>> Menon (Thanks for review NM) and his acked-by tags. I would like to get this
>>>> queued for 3.10 merge window if you are ok with the series.
>>>
>>> I did a review of this series with several comments on the individual
>>> patches.
>>>
>> Thanks a lot Kevin. I have addressed all the comments and have
>> updated patches ready.
>>
>>> I've already queued most of the CPUidle fixes/cleanups in my
>>> for_3.10/cleanup/cpuidle branch and will get that to Tony soon. For the
>>> rest, I suggest probably breaking it up into cleanup/consolidation stuff
>>> and then OMAP5 support. The latter will depend on all the OMAP5
>>> data/headers but the cleanup/consolidation stuff could be merged sooner
>>> (but probably a bit late for v3.10 now.)
>>>
>> I have already split the patch-set into 'consolidation' and 'OMAP5
>> support' since it was straight forward. Need to just build the
>> branches on top of your branches. So waiting for you to update
>> your 'for_3.10/*' branches.
>>
>> For the merge, its your call:)
>> As you said OMAP5 support(couple of patches) has a dependency
>> on OMAP5 data files. I will at least make the branches ready on
>> top of yours.
>>
> After looking at your tree, looks like the branches are already
> there. Idle branch name is not for_3.10/fixes/cpuidle though :)
oh, sorry. I changed it to 'cleanup'.
> So I created 'for_3.10/omap_pm-cleanup' and 'for_3.10/omap5_pm_v2'
> and pushed on my git tree [1] in case you would like to have
> a look. I briefly tested them on OMAP4 device with
> CPUidle enabled and they seems to work fine. Will do OMAP5
> testing tomorrow and then post the updated patches on list.
Perfect, thanks.
Kevin
^ permalink raw reply [flat|nested] 128+ messages in thread
* Re: [PATCH v2 08/18] ARM: OMAP5: PM: Add CPU power off in hotplug path
2013-04-04 17:31 ` Kevin Hilman
@ 2013-04-05 9:04 ` Santosh Shilimkar
-1 siblings, 0 replies; 128+ messages in thread
From: Santosh Shilimkar @ 2013-04-05 9:04 UTC (permalink / raw)
To: Kevin Hilman; +Cc: linux-omap, linux-arm-kernel, nm, tony
On Thursday 04 April 2013 11:01 PM, Kevin Hilman wrote:
> Santosh Shilimkar <santosh.shilimkar@ti.com> writes:
>
>> On Thursday 04 April 2013 02:19 AM, Kevin Hilman wrote:
>>> Santosh Shilimkar <santosh.shilimkar@ti.com> writes:
>>>
>>>> Add power management code to handle the CPU off mode to enable CPUP hotplug
>>>> mode for OMAP5 devices. Separate suspend finisher is used for OMAP5(Cortex-A15)
>>>> because it doesn't use SCU power status register and external PL310 L2 cache
>>>> which makes code flow bit different.
>>>>
>>>> Acked-by: Nishanth Menon <nm@ti.com>
>>>> Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
>>>
>>> [...]
>>>
>>>> @@ -436,14 +445,21 @@ int __init omap4_mpuss_init(void)
>>>>
>>>> if (cpu_is_omap44xx()) {
>>>> omap_pm_ops.finish_suspend = omap4_finish_suspend;
>>>> + omap_pm_ops.hotplug_restart = omap_secondary_startup;
>>>> omap_pm_ops.resume = omap4_cpu_resume;
>>>> omap_pm_ops.scu_prepare = scu_pwrst_prepare;
>>>> cpu_context_offset = OMAP4_RM_CPU0_CPU0_CONTEXT_OFFSET;
>>>> } else if (soc_is_omap54xx()) {
>>>> + omap_pm_ops.finish_suspend = omap5_finish_suspend;
>>>> + omap_pm_ops.hotplug_restart = omap5_secondary_startup;
>>>> cpu_context_offset = OMAP54XX_RM_CPU0_CPU0_CONTEXT_OFFSET;
>>>> enable_mercury_retention_mode();
>>>> }
>>>>
>>>> + /* Over-write the OMAP4 hook to take care of ROM BUG */
>>>> + if (cpu_is_omap446x())
>>>> + omap_pm_ops.hotplug_restart = omap_secondary_startup_4460;
>>>
>>> A couple nits...
>>>
>>> I think this would go better at the end of the 'if omap44xx' block
>>> above.
>>>
>> Nishant commented on this as well. The indentation was looking ugly
>> and I thought its better to have this BUG hunk separate. I prefer
>> it this way though if you really insist, i have to change it.
>
> I insist.
>
Will update the patch accordingly then.
Regards,
Santosh
^ permalink raw reply [flat|nested] 128+ messages in thread
* [PATCH v2 08/18] ARM: OMAP5: PM: Add CPU power off in hotplug path
@ 2013-04-05 9:04 ` Santosh Shilimkar
0 siblings, 0 replies; 128+ messages in thread
From: Santosh Shilimkar @ 2013-04-05 9:04 UTC (permalink / raw)
To: linux-arm-kernel
On Thursday 04 April 2013 11:01 PM, Kevin Hilman wrote:
> Santosh Shilimkar <santosh.shilimkar@ti.com> writes:
>
>> On Thursday 04 April 2013 02:19 AM, Kevin Hilman wrote:
>>> Santosh Shilimkar <santosh.shilimkar@ti.com> writes:
>>>
>>>> Add power management code to handle the CPU off mode to enable CPUP hotplug
>>>> mode for OMAP5 devices. Separate suspend finisher is used for OMAP5(Cortex-A15)
>>>> because it doesn't use SCU power status register and external PL310 L2 cache
>>>> which makes code flow bit different.
>>>>
>>>> Acked-by: Nishanth Menon <nm@ti.com>
>>>> Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
>>>
>>> [...]
>>>
>>>> @@ -436,14 +445,21 @@ int __init omap4_mpuss_init(void)
>>>>
>>>> if (cpu_is_omap44xx()) {
>>>> omap_pm_ops.finish_suspend = omap4_finish_suspend;
>>>> + omap_pm_ops.hotplug_restart = omap_secondary_startup;
>>>> omap_pm_ops.resume = omap4_cpu_resume;
>>>> omap_pm_ops.scu_prepare = scu_pwrst_prepare;
>>>> cpu_context_offset = OMAP4_RM_CPU0_CPU0_CONTEXT_OFFSET;
>>>> } else if (soc_is_omap54xx()) {
>>>> + omap_pm_ops.finish_suspend = omap5_finish_suspend;
>>>> + omap_pm_ops.hotplug_restart = omap5_secondary_startup;
>>>> cpu_context_offset = OMAP54XX_RM_CPU0_CPU0_CONTEXT_OFFSET;
>>>> enable_mercury_retention_mode();
>>>> }
>>>>
>>>> + /* Over-write the OMAP4 hook to take care of ROM BUG */
>>>> + if (cpu_is_omap446x())
>>>> + omap_pm_ops.hotplug_restart = omap_secondary_startup_4460;
>>>
>>> A couple nits...
>>>
>>> I think this would go better at the end of the 'if omap44xx' block
>>> above.
>>>
>> Nishant commented on this as well. The indentation was looking ugly
>> and I thought its better to have this BUG hunk separate. I prefer
>> it this way though if you really insist, i have to change it.
>
> I insist.
>
Will update the patch accordingly then.
Regards,
Santosh
^ permalink raw reply [flat|nested] 128+ messages in thread
* Re: [PATCH v2 09/18] ARM: OMAP4+: PM: Restore CPU power state to ON with clockdomain force wakeup method
2013-04-04 17:42 ` Kevin Hilman
@ 2013-04-05 9:07 ` Santosh Shilimkar
-1 siblings, 0 replies; 128+ messages in thread
From: Santosh Shilimkar @ 2013-04-05 9:07 UTC (permalink / raw)
To: Kevin Hilman; +Cc: linux-omap, linux-arm-kernel, nm, tony
On Thursday 04 April 2013 11:12 PM, Kevin Hilman wrote:
> Santosh Shilimkar <santosh.shilimkar@ti.com> writes:
>
>> On Thursday 04 April 2013 02:24 AM, Kevin Hilman wrote:
>>> Santosh Shilimkar <santosh.shilimkar@ti.com> writes:
>>>
>>>> While waking up CPU from off state using clock domain force wakeup, restore
>>>> the CPU power state to ON state before putting CPU clock domain under
>>>> hardware control. Otherwise CPU wakeup might fail. The change is recommended
>>>> for all OMAP4+ devices though the PRCM weakness was observed on OMAP5
>>>> devices first.
>>>
>>> Sounds reasonable, but can you describe the "weakness" a little more?
>>>
>>> IOW, what exactly happens if this is not done? It sounds like the CPU
>>> might immediately go back to retention, but how does that happen unless
>>> it does a WFI?
>>>
>> Its more of lock-up inside the hardware state machine and results
>> are UN-predictable. We have seen hard-locks most of the time where system
>> is just frozen. The hardware gets into wrong state machine if the power
>> domain state isn't restored. I will add this information to changelog.
>>
>>> Also, this sounds like a fix to me, and should probably be broken out
>>> accordingly.
>>>
>> Yeah. You mean a separate patch from the series, right ? This patch
>> actually can be independently added.
>>
>> In case you decide to apply it for the fixes branch, updated patch
>> at end of the email.
>
> Curious which branch you applied it to? It didn't apply cleanly to
> v3.9-rc5 (but did with fuzz).
>
Mostly applied on top of the Tony's pull request branches.
> So I've now added it to my for_3.10/fixes/pm branch.
>
Thanks. I will pull that in to re-base other patches.
Regards,
Santosh
^ permalink raw reply [flat|nested] 128+ messages in thread
* [PATCH v2 09/18] ARM: OMAP4+: PM: Restore CPU power state to ON with clockdomain force wakeup method
@ 2013-04-05 9:07 ` Santosh Shilimkar
0 siblings, 0 replies; 128+ messages in thread
From: Santosh Shilimkar @ 2013-04-05 9:07 UTC (permalink / raw)
To: linux-arm-kernel
On Thursday 04 April 2013 11:12 PM, Kevin Hilman wrote:
> Santosh Shilimkar <santosh.shilimkar@ti.com> writes:
>
>> On Thursday 04 April 2013 02:24 AM, Kevin Hilman wrote:
>>> Santosh Shilimkar <santosh.shilimkar@ti.com> writes:
>>>
>>>> While waking up CPU from off state using clock domain force wakeup, restore
>>>> the CPU power state to ON state before putting CPU clock domain under
>>>> hardware control. Otherwise CPU wakeup might fail. The change is recommended
>>>> for all OMAP4+ devices though the PRCM weakness was observed on OMAP5
>>>> devices first.
>>>
>>> Sounds reasonable, but can you describe the "weakness" a little more?
>>>
>>> IOW, what exactly happens if this is not done? It sounds like the CPU
>>> might immediately go back to retention, but how does that happen unless
>>> it does a WFI?
>>>
>> Its more of lock-up inside the hardware state machine and results
>> are UN-predictable. We have seen hard-locks most of the time where system
>> is just frozen. The hardware gets into wrong state machine if the power
>> domain state isn't restored. I will add this information to changelog.
>>
>>> Also, this sounds like a fix to me, and should probably be broken out
>>> accordingly.
>>>
>> Yeah. You mean a separate patch from the series, right ? This patch
>> actually can be independently added.
>>
>> In case you decide to apply it for the fixes branch, updated patch
>> at end of the email.
>
> Curious which branch you applied it to? It didn't apply cleanly to
> v3.9-rc5 (but did with fuzz).
>
Mostly applied on top of the Tony's pull request branches.
> So I've now added it to my for_3.10/fixes/pm branch.
>
Thanks. I will pull that in to re-base other patches.
Regards,
Santosh
^ permalink raw reply [flat|nested] 128+ messages in thread
* Re: [PATCH v2 17/18] ARM: OMAP4+: CPUidle: Add OMAP5 idle driver support
2013-04-04 17:55 ` Kevin Hilman
@ 2013-04-05 9:41 ` Santosh Shilimkar
-1 siblings, 0 replies; 128+ messages in thread
From: Santosh Shilimkar @ 2013-04-05 9:41 UTC (permalink / raw)
To: Kevin Hilman; +Cc: nm, tony, linux-omap, linux-arm-kernel
On Thursday 04 April 2013 11:25 PM, Kevin Hilman wrote:
> Santosh Shilimkar <santosh.shilimkar@ti.com> writes:
>
>> On Thursday 04 April 2013 02:55 AM, Kevin Hilman wrote:
>>> Santosh Shilimkar <santosh.shilimkar@ti.com> writes:
>>>
>>>> The OMAP5 idle driver can re-use OMAP4 CPUidle driver implementation thanks
>>>> to compatible MPUSS design.
>>>>
>>>> Though unlike OMAP4, on OMAP5 devices, MPUSS CSWR (Close Switch
>>>> Retention) power states can be achieved with respective power states
>>>> on CPU0 and CPU1 power domain. This mode was broken on OMAP4 devices
>>>> because of hardware limitation.
>>>
>>> I'm a bit confused by the description here.
>>>
>>> I gather from the code that this means that CPU0 and CPU1 can hit CSWR
>>> independently, correct?
>>>
>> They can be programmed independently without any ordering(like
>> CPU0 last etc), but the actual transition to the low power CSWR
>> happens together. Till that the first CPU hit WFI remains in WFI
>> state waiting for other CPU to hit WFI and then both transition
>> together.
>> Completely managed inside hardware.
>
> OK, elaborating this in the changelog would be helpful. Use the "will I
> understand this changelog in a year" rule to see if the changelog is
> detailed enough. Or better, "will Kevin understand this changelog in a
> year." (hint: the answer is usually no.) ;)
>
:-) I added above description in change-log.
>>>> Also there is no CPU low power entry order requirement like
>>>> master CPU etc for CSWR C-state, which is icing on the cake.
>>>
>>> Even on secure devices?
>>>
>> Yes. On secure devices too. Actually since we don't loose context,
>> secure entry/exit doesn't come into picture.
>>
>>>> Code makes use of voting scheme for cluster low power state to support
>>>> MPUSS CSWR C-state.
>>>
>>> The voting scheme and associated locking should be better described
>>> here, or commented in the code itself.
>>>
>> You are right. It deserves some description.
>>
>>>> Supported OMAP5 CPUidle C-states:
>>>> C1 - CPU0 ON(WFI) + CPU1 ON(WFI) + MPUSS ON
>>>> C2 - CPU0 CSWR + CPU1 CSWR + MPUSS CSWR
>>>> C3 - CPU0 OFF + CPU1 OFF + MPUSS OSWR
>>>>
>>>> Acked-by: Nishanth Menon <nm@ti.com>
>>>> Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
>>>
>>> [...]
>>>
>>>> +static int omap_enter_idle_smp(struct cpuidle_device *dev,
>>>> + struct cpuidle_driver *drv,
>>>> + int index)
>>>> +{
>>>> + struct idle_statedata *cx = state_ptr + index;
>>>> + int cpu_id = smp_processor_id();
>>>> + unsigned long flag;
>>>> +
>>>> + clockevents_notify(CLOCK_EVT_NOTIFY_BROADCAST_ENTER, &cpu_id);
>>>
>>> I think the CPUidle core handles the broadcast notification now.
>>>
>> Not in mainline yet. And those patches came after my patches and
>> I don't wanted un-necessary merge dependency, I avoided it. Its trivial
>> though to drop if from here once the idle next is merged.
>
> OK.
>
> I believe that stuff is already queued, no? Maybe ahave this as an
> add-on separate patch that can be used for your loal testing, but does
> not go upstream.
>
Will do.
> I would only include this if you're sure the other series is not going
> upstream.
>
It might go upstream so I will manually apply the patch or pull a branch
if available.
>>>> + raw_spin_lock_irqsave(&mpu_lock, flag);
>>>> + cx->mpu_state_vote++;
>>>
>>> How about using an atomic_t and atomic_inc()/atomic_dec() instead, which
>>> will avoid the need for a spinlock.
>>>
>> Spin lock is not just for the vote variable. I had atomics opps in first
>> version I gave it to product team. But they found a race condition in
>> where MPU power state was getting overwritten by other CPU.
>>
>>> Even with that, it still seems potentially racy. Do you need a memory
>>> barrier here to be sure that any changes from another CPU are visible
>>> here, and vice versa?
>>>
>> With locks, you don't need barriers since the updated copy is guaranteed.
>
> It's guaranteed because the spinlock implementation uses barriers.
>
Yeah.
>> Can you please elaborate on potential race ? I have given pretty hard
>> thought and didn't see any race which can be exposed with locks in place.
>
> I was referring to using atomic ops. With atomic ops, you'd need an
> explicit barrier (which you're getting inside the spinlock
> implementation)
>
> That being said, I have not thought through all the corner cases as you
> have, so I'll defer to your choice (as long as it's well documented.)
> If you decide to stick with spinlocks, be sure to describe all of what
> the spinlock is protecting, and why.
>
Have updated the change-log as well as code to elaborate the lock use.
Thanks for review.
Regards,
Santosh
^ permalink raw reply [flat|nested] 128+ messages in thread
* [PATCH v2 17/18] ARM: OMAP4+: CPUidle: Add OMAP5 idle driver support
@ 2013-04-05 9:41 ` Santosh Shilimkar
0 siblings, 0 replies; 128+ messages in thread
From: Santosh Shilimkar @ 2013-04-05 9:41 UTC (permalink / raw)
To: linux-arm-kernel
On Thursday 04 April 2013 11:25 PM, Kevin Hilman wrote:
> Santosh Shilimkar <santosh.shilimkar@ti.com> writes:
>
>> On Thursday 04 April 2013 02:55 AM, Kevin Hilman wrote:
>>> Santosh Shilimkar <santosh.shilimkar@ti.com> writes:
>>>
>>>> The OMAP5 idle driver can re-use OMAP4 CPUidle driver implementation thanks
>>>> to compatible MPUSS design.
>>>>
>>>> Though unlike OMAP4, on OMAP5 devices, MPUSS CSWR (Close Switch
>>>> Retention) power states can be achieved with respective power states
>>>> on CPU0 and CPU1 power domain. This mode was broken on OMAP4 devices
>>>> because of hardware limitation.
>>>
>>> I'm a bit confused by the description here.
>>>
>>> I gather from the code that this means that CPU0 and CPU1 can hit CSWR
>>> independently, correct?
>>>
>> They can be programmed independently without any ordering(like
>> CPU0 last etc), but the actual transition to the low power CSWR
>> happens together. Till that the first CPU hit WFI remains in WFI
>> state waiting for other CPU to hit WFI and then both transition
>> together.
>> Completely managed inside hardware.
>
> OK, elaborating this in the changelog would be helpful. Use the "will I
> understand this changelog in a year" rule to see if the changelog is
> detailed enough. Or better, "will Kevin understand this changelog in a
> year." (hint: the answer is usually no.) ;)
>
:-) I added above description in change-log.
>>>> Also there is no CPU low power entry order requirement like
>>>> master CPU etc for CSWR C-state, which is icing on the cake.
>>>
>>> Even on secure devices?
>>>
>> Yes. On secure devices too. Actually since we don't loose context,
>> secure entry/exit doesn't come into picture.
>>
>>>> Code makes use of voting scheme for cluster low power state to support
>>>> MPUSS CSWR C-state.
>>>
>>> The voting scheme and associated locking should be better described
>>> here, or commented in the code itself.
>>>
>> You are right. It deserves some description.
>>
>>>> Supported OMAP5 CPUidle C-states:
>>>> C1 - CPU0 ON(WFI) + CPU1 ON(WFI) + MPUSS ON
>>>> C2 - CPU0 CSWR + CPU1 CSWR + MPUSS CSWR
>>>> C3 - CPU0 OFF + CPU1 OFF + MPUSS OSWR
>>>>
>>>> Acked-by: Nishanth Menon <nm@ti.com>
>>>> Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
>>>
>>> [...]
>>>
>>>> +static int omap_enter_idle_smp(struct cpuidle_device *dev,
>>>> + struct cpuidle_driver *drv,
>>>> + int index)
>>>> +{
>>>> + struct idle_statedata *cx = state_ptr + index;
>>>> + int cpu_id = smp_processor_id();
>>>> + unsigned long flag;
>>>> +
>>>> + clockevents_notify(CLOCK_EVT_NOTIFY_BROADCAST_ENTER, &cpu_id);
>>>
>>> I think the CPUidle core handles the broadcast notification now.
>>>
>> Not in mainline yet. And those patches came after my patches and
>> I don't wanted un-necessary merge dependency, I avoided it. Its trivial
>> though to drop if from here once the idle next is merged.
>
> OK.
>
> I believe that stuff is already queued, no? Maybe ahave this as an
> add-on separate patch that can be used for your loal testing, but does
> not go upstream.
>
Will do.
> I would only include this if you're sure the other series is not going
> upstream.
>
It might go upstream so I will manually apply the patch or pull a branch
if available.
>>>> + raw_spin_lock_irqsave(&mpu_lock, flag);
>>>> + cx->mpu_state_vote++;
>>>
>>> How about using an atomic_t and atomic_inc()/atomic_dec() instead, which
>>> will avoid the need for a spinlock.
>>>
>> Spin lock is not just for the vote variable. I had atomics opps in first
>> version I gave it to product team. But they found a race condition in
>> where MPU power state was getting overwritten by other CPU.
>>
>>> Even with that, it still seems potentially racy. Do you need a memory
>>> barrier here to be sure that any changes from another CPU are visible
>>> here, and vice versa?
>>>
>> With locks, you don't need barriers since the updated copy is guaranteed.
>
> It's guaranteed because the spinlock implementation uses barriers.
>
Yeah.
>> Can you please elaborate on potential race ? I have given pretty hard
>> thought and didn't see any race which can be exposed with locks in place.
>
> I was referring to using atomic ops. With atomic ops, you'd need an
> explicit barrier (which you're getting inside the spinlock
> implementation)
>
> That being said, I have not thought through all the corner cases as you
> have, so I'll defer to your choice (as long as it's well documented.)
> If you decide to stick with spinlocks, be sure to describe all of what
> the spinlock is protecting, and why.
>
Have updated the change-log as well as code to elaborate the lock use.
Thanks for review.
Regards,
Santosh
^ permalink raw reply [flat|nested] 128+ messages in thread
* Re: [PATCH v2 09/18] ARM: OMAP4+: PM: Restore CPU power state to ON with clockdomain force wakeup method
2013-04-05 9:07 ` Santosh Shilimkar
@ 2013-04-05 11:58 ` Santosh Shilimkar
-1 siblings, 0 replies; 128+ messages in thread
From: Santosh Shilimkar @ 2013-04-05 11:58 UTC (permalink / raw)
To: Kevin Hilman; +Cc: nm, tony, linux-omap, linux-arm-kernel
On Friday 05 April 2013 02:37 PM, Santosh Shilimkar wrote:
> On Thursday 04 April 2013 11:12 PM, Kevin Hilman wrote:
>> Santosh Shilimkar <santosh.shilimkar@ti.com> writes:
>>
>>> On Thursday 04 April 2013 02:24 AM, Kevin Hilman wrote:
>>>> Santosh Shilimkar <santosh.shilimkar@ti.com> writes:
>>>>
>>>>> While waking up CPU from off state using clock domain force wakeup, restore
>>>>> the CPU power state to ON state before putting CPU clock domain under
>>>>> hardware control. Otherwise CPU wakeup might fail. The change is recommended
>>>>> for all OMAP4+ devices though the PRCM weakness was observed on OMAP5
>>>>> devices first.
>>>>
>>>> Sounds reasonable, but can you describe the "weakness" a little more?
>>>>
>>>> IOW, what exactly happens if this is not done? It sounds like the CPU
>>>> might immediately go back to retention, but how does that happen unless
>>>> it does a WFI?
>>>>
>>> Its more of lock-up inside the hardware state machine and results
>>> are UN-predictable. We have seen hard-locks most of the time where system
>>> is just frozen. The hardware gets into wrong state machine if the power
>>> domain state isn't restored. I will add this information to changelog.
>>>
>>>> Also, this sounds like a fix to me, and should probably be broken out
>>>> accordingly.
>>>>
>>> Yeah. You mean a separate patch from the series, right ? This patch
>>> actually can be independently added.
>>>
>>> In case you decide to apply it for the fixes branch, updated patch
>>> at end of the email.
>>
>> Curious which branch you applied it to? It didn't apply cleanly to
>> v3.9-rc5 (but did with fuzz).
>>
> Mostly applied on top of the Tony's pull request branches.
>
>> So I've now added it to my for_3.10/fixes/pm branch.
>>
> Thanks. I will pull that in to re-base other patches.
>
While pulling your 'for_3.10/fixes/pm' branch on top
of Tony's pull request[1] sent to arm-soc already.
In my tree, I had pulled Tony's couple of pull requests.
Regards,
Santosh
[1] http://www.spinics.net/lists/arm-kernel/msg235788.html
^ permalink raw reply [flat|nested] 128+ messages in thread
* [PATCH v2 09/18] ARM: OMAP4+: PM: Restore CPU power state to ON with clockdomain force wakeup method
@ 2013-04-05 11:58 ` Santosh Shilimkar
0 siblings, 0 replies; 128+ messages in thread
From: Santosh Shilimkar @ 2013-04-05 11:58 UTC (permalink / raw)
To: linux-arm-kernel
On Friday 05 April 2013 02:37 PM, Santosh Shilimkar wrote:
> On Thursday 04 April 2013 11:12 PM, Kevin Hilman wrote:
>> Santosh Shilimkar <santosh.shilimkar@ti.com> writes:
>>
>>> On Thursday 04 April 2013 02:24 AM, Kevin Hilman wrote:
>>>> Santosh Shilimkar <santosh.shilimkar@ti.com> writes:
>>>>
>>>>> While waking up CPU from off state using clock domain force wakeup, restore
>>>>> the CPU power state to ON state before putting CPU clock domain under
>>>>> hardware control. Otherwise CPU wakeup might fail. The change is recommended
>>>>> for all OMAP4+ devices though the PRCM weakness was observed on OMAP5
>>>>> devices first.
>>>>
>>>> Sounds reasonable, but can you describe the "weakness" a little more?
>>>>
>>>> IOW, what exactly happens if this is not done? It sounds like the CPU
>>>> might immediately go back to retention, but how does that happen unless
>>>> it does a WFI?
>>>>
>>> Its more of lock-up inside the hardware state machine and results
>>> are UN-predictable. We have seen hard-locks most of the time where system
>>> is just frozen. The hardware gets into wrong state machine if the power
>>> domain state isn't restored. I will add this information to changelog.
>>>
>>>> Also, this sounds like a fix to me, and should probably be broken out
>>>> accordingly.
>>>>
>>> Yeah. You mean a separate patch from the series, right ? This patch
>>> actually can be independently added.
>>>
>>> In case you decide to apply it for the fixes branch, updated patch
>>> at end of the email.
>>
>> Curious which branch you applied it to? It didn't apply cleanly to
>> v3.9-rc5 (but did with fuzz).
>>
> Mostly applied on top of the Tony's pull request branches.
>
>> So I've now added it to my for_3.10/fixes/pm branch.
>>
> Thanks. I will pull that in to re-base other patches.
>
While pulling your 'for_3.10/fixes/pm' branch on top
of Tony's pull request[1] sent to arm-soc already.
In my tree, I had pulled Tony's couple of pull requests.
Regards,
Santosh
[1] http://www.spinics.net/lists/arm-kernel/msg235788.html
^ permalink raw reply [flat|nested] 128+ messages in thread
end of thread, other threads:[~2013-04-05 11:58 UTC | newest]
Thread overview: 128+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2013-03-25 10:04 [PATCH v2 00/18] ARM: OMAP5: PM: Add MPUSS suspend and CPUidle support Santosh Shilimkar
2013-03-25 10:04 ` Santosh Shilimkar
2013-03-25 10:04 ` [PATCH v2 01/18] ARM: OMAP4+: PM: Consolidate MPU subsystem PM code for re-use Santosh Shilimkar
2013-03-25 10:04 ` Santosh Shilimkar
2013-04-03 19:44 ` Kevin Hilman
2013-04-03 19:44 ` Kevin Hilman
2013-04-04 11:32 ` Santosh Shilimkar
2013-04-04 11:32 ` Santosh Shilimkar
2013-03-25 10:04 ` [PATCH v2 02/18] ARM: OMAP5: PM: Update CPU context register offset Santosh Shilimkar
2013-03-25 10:04 ` Santosh Shilimkar
2013-03-25 10:04 ` [PATCH v2 03/18] ARM: OMAP4+: PM: Consolidate and use OMAP4 PM code for OMAP5 Santosh Shilimkar
2013-03-25 10:04 ` Santosh Shilimkar
2013-04-03 20:20 ` Kevin Hilman
2013-04-03 20:20 ` Kevin Hilman
2013-04-04 11:51 ` Santosh Shilimkar
2013-04-04 11:51 ` Santosh Shilimkar
2013-04-04 11:55 ` Santosh Shilimkar
2013-04-04 11:55 ` Santosh Shilimkar
2013-03-25 10:04 ` [PATCH v2 04/18] ARM: OMAP5: PM: Set MPUSS-EMIF clock-domain static dependency Santosh Shilimkar
2013-03-25 10:04 ` Santosh Shilimkar
2013-03-25 10:04 ` [PATCH v2 05/18] ARM: OMAP5: PM: Enables ES2 PM mode by default Santosh Shilimkar
2013-03-25 10:04 ` Santosh Shilimkar
2013-04-03 20:25 ` Kevin Hilman
2013-04-03 20:25 ` Kevin Hilman
2013-04-04 12:02 ` Santosh Shilimkar
2013-04-04 12:02 ` Santosh Shilimkar
2013-03-25 10:04 ` [PATCH v2 06/18] ARM: OMAP5: PM: Enable Mercury retention mode on CPUx powerdomains Santosh Shilimkar
2013-03-25 10:04 ` Santosh Shilimkar
2013-04-03 20:31 ` Kevin Hilman
2013-04-03 20:31 ` Kevin Hilman
2013-04-04 12:08 ` Santosh Shilimkar
2013-04-04 12:08 ` Santosh Shilimkar
2013-03-25 10:04 ` [PATCH v2 07/18] ARM: OMAP5: Add init_late() hook to enable pm initialization Santosh Shilimkar
2013-03-25 10:04 ` Santosh Shilimkar
2013-04-03 20:33 ` Kevin Hilman
2013-04-03 20:33 ` Kevin Hilman
2013-04-04 12:28 ` Santosh Shilimkar
2013-04-04 12:28 ` Santosh Shilimkar
2013-03-25 10:05 ` [PATCH v2 08/18] ARM: OMAP5: PM: Add CPU power off in hotplug path Santosh Shilimkar
2013-03-25 10:05 ` Santosh Shilimkar
2013-04-03 20:49 ` Kevin Hilman
2013-04-03 20:49 ` Kevin Hilman
2013-04-04 13:23 ` Santosh Shilimkar
2013-04-04 13:23 ` Santosh Shilimkar
2013-04-04 17:31 ` Kevin Hilman
2013-04-04 17:31 ` Kevin Hilman
2013-04-05 9:04 ` Santosh Shilimkar
2013-04-05 9:04 ` Santosh Shilimkar
2013-03-25 10:05 ` [PATCH v2 09/18] ARM: OMAP4+: PM: Restore CPU power state to ON with clockdomain force wakeup method Santosh Shilimkar
2013-03-25 10:05 ` Santosh Shilimkar
2013-04-03 20:54 ` Kevin Hilman
2013-04-03 20:54 ` Kevin Hilman
2013-04-04 13:37 ` Santosh Shilimkar
2013-04-04 13:37 ` Santosh Shilimkar
2013-04-04 17:42 ` Kevin Hilman
2013-04-04 17:42 ` Kevin Hilman
2013-04-05 9:07 ` Santosh Shilimkar
2013-04-05 9:07 ` Santosh Shilimkar
2013-04-05 11:58 ` Santosh Shilimkar
2013-04-05 11:58 ` Santosh Shilimkar
2013-03-25 10:05 ` [PATCH v2 10/18] ARM: OMAP5: PM: Add MPU Open Switch Retention support Santosh Shilimkar
2013-03-25 10:05 ` Santosh Shilimkar
2013-03-25 10:05 ` [PATCH v2 11/18] ARM: OMAP5: PM: Add L2 memory power down support Santosh Shilimkar
2013-03-25 10:05 ` Santosh Shilimkar
2013-04-03 20:58 ` Kevin Hilman
2013-04-03 20:58 ` Kevin Hilman
2013-04-04 13:46 ` Santosh Shilimkar
2013-04-04 13:46 ` Santosh Shilimkar
2013-03-25 10:05 ` [PATCH v2 12/18] ARM: OMAP4: CPUidle: Avoid double idle driver registration Santosh Shilimkar
2013-03-25 10:05 ` Santosh Shilimkar
2013-04-03 21:03 ` Kevin Hilman
2013-04-03 21:03 ` Kevin Hilman
2013-04-04 13:47 ` Santosh Shilimkar
2013-04-04 13:47 ` Santosh Shilimkar
2013-03-25 10:05 ` [PATCH v2 13/18] ARM: OMAP: CPUidle: Unregister drivere on device registration failure Santosh Shilimkar
2013-03-25 10:05 ` Santosh Shilimkar
2013-04-03 21:03 ` Kevin Hilman
2013-04-03 21:03 ` Kevin Hilman
2013-04-04 13:48 ` Santosh Shilimkar
2013-04-04 13:48 ` Santosh Shilimkar
2013-03-25 10:05 ` [PATCH v2 14/18] ARM: OMAP4: CPUidle: Make C-state description field more precise Santosh Shilimkar
2013-03-25 10:05 ` Santosh Shilimkar
2013-04-03 21:05 ` Kevin Hilman
2013-04-03 21:05 ` Kevin Hilman
2013-04-04 13:48 ` Santosh Shilimkar
2013-04-04 13:48 ` Santosh Shilimkar
2013-03-25 10:05 ` [PATCH v2 15/18] ARM: OMAP4+: CPUidle: Consolidate idle driver for OMAP5 support Santosh Shilimkar
2013-03-25 10:05 ` Santosh Shilimkar
2013-04-03 21:10 ` Kevin Hilman
2013-04-03 21:10 ` Kevin Hilman
2013-04-04 14:04 ` Santosh Shilimkar
2013-04-04 14:04 ` Santosh Shilimkar
2013-03-25 10:05 ` [PATCH v2 16/18] ARM: OMAP4+: CPUidle: Deprecate use of omap4_mpuss_read_prev_context_state() Santosh Shilimkar
2013-03-25 10:05 ` Santosh Shilimkar
2013-04-03 21:37 ` Kevin Hilman
2013-04-03 21:37 ` Kevin Hilman
2013-04-04 13:59 ` Santosh Shilimkar
2013-04-04 13:59 ` Santosh Shilimkar
2013-03-25 10:05 ` [PATCH v2 17/18] ARM: OMAP4+: CPUidle: Add OMAP5 idle driver support Santosh Shilimkar
2013-03-25 10:05 ` Santosh Shilimkar
2013-04-03 21:25 ` Kevin Hilman
2013-04-03 21:25 ` Kevin Hilman
2013-04-04 14:16 ` Santosh Shilimkar
2013-04-04 14:16 ` Santosh Shilimkar
2013-04-04 17:55 ` Kevin Hilman
2013-04-04 17:55 ` Kevin Hilman
2013-04-05 9:41 ` Santosh Shilimkar
2013-04-05 9:41 ` Santosh Shilimkar
2013-03-25 10:05 ` [PATCH v2 18/18] ARM: OMAP5: PM: handle device instance for warm reset Santosh Shilimkar
2013-03-25 10:05 ` Santosh Shilimkar
2013-03-25 11:46 ` [PATCH v2 00/18] ARM: OMAP5: PM: Add MPUSS suspend and CPUidle support Lokesh Vutla
2013-03-25 11:46 ` Lokesh Vutla
2013-03-25 12:10 ` Santosh Shilimkar
2013-03-25 12:10 ` Santosh Shilimkar
2013-03-25 12:27 ` Sourav Poddar
2013-03-25 12:27 ` Sourav Poddar
2013-03-25 12:47 ` Rajendra Nayak
2013-03-25 12:47 ` Rajendra Nayak
2013-03-25 13:00 ` Sourav Poddar
2013-03-25 13:00 ` Sourav Poddar
2013-04-03 22:52 ` Kevin Hilman
2013-04-03 22:52 ` Kevin Hilman
2013-04-04 14:34 ` Santosh Shilimkar
2013-04-04 14:34 ` Santosh Shilimkar
2013-04-04 16:49 ` Santosh Shilimkar
2013-04-04 16:49 ` Santosh Shilimkar
2013-04-04 17:57 ` Kevin Hilman
2013-04-04 17:57 ` Kevin Hilman
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.