* [PATCH v3 0/4] ARM: OMAP4+: PM: Consolidate code for re-use on OMAP5
@ 2013-04-05 12:58 ` Santosh Shilimkar
0 siblings, 0 replies; 46+ messages in thread
From: Santosh Shilimkar @ 2013-04-05 12:58 UTC (permalink / raw)
To: khilman; +Cc: tony, linux-omap, Santosh Shilimkar, linux-arm-kernel
Kevin,
As discussed on list, I split the v2 [1] series into cleanup and OMAP5 support.
This series contains the clean-up patches. I have rebased on top of Tony's
pull request and your 3.10/* branches. Series is tested on OMAP4430 SDP
with CPUIDLE and suspend. OMAP5 PM support I will post later since it has
a dependency with OMAP5 data files which are not pulled in yet.
Regards,
Santosh
[1] http://www.spinics.net/lists/linux-omap/msg88901.html
The following changes since commit 4b9ce8484d8122f2088cedf60265ae86f7822350:
Merge branch 'for_3.10/fixes/pm' of git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-omap-pm into for_3.10/omap_pm-cleanup (2013-04-05 18:10:34 +0530)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/ssantosh/linux.git
for you to fetch changes up to 884ef029cb434aad124bf8413211a698597f8f7a:
ARM: OMAP4+: CPUidle: Consolidate idle driver for OMAP5 support (2013-04-05 18:11:06 +0530)
----------------------------------------------------------------
Santosh Shilimkar (4):
ARM: OMAP4+: PM: Consolidate MPU subsystem PM code for re-use
ARM: OMAP4+: PM: Consolidate OMAP4 PM code to re-use it for OMAP5
ARM: OMAP4+: Make secondary_startup function name more consistent
ARM: OMAP4+: CPUidle: Consolidate idle driver for OMAP5 support
arch/arm/mach-omap2/Makefile | 9 +--
arch/arm/mach-omap2/common.h | 4 +-
arch/arm/mach-omap2/cpuidle44xx.c | 31 ++++-----
arch/arm/mach-omap2/omap-headsmp.S | 8 +--
arch/arm/mach-omap2/omap-mpuss-lowpower.c | 68 ++++++++++++++++----
arch/arm/mach-omap2/omap-smp.c | 6 +-
arch/arm/mach-omap2/{pm44xx.c => pm_omap4plus.c} | 58 ++++++++++++++---
.../mach-omap2/{sleep44xx.S => sleep_omap4plus.S} | 0
8 files changed, 132 insertions(+), 52 deletions(-)
rename arch/arm/mach-omap2/{pm44xx.c => pm_omap4plus.c} (83%)
rename arch/arm/mach-omap2/{sleep44xx.S => sleep_omap4plus.S} (100%)
--
1.7.9.5
^ permalink raw reply [flat|nested] 46+ messages in thread
* [PATCH v3 0/4] ARM: OMAP4+: PM: Consolidate code for re-use on OMAP5
@ 2013-04-05 12:58 ` Santosh Shilimkar
0 siblings, 0 replies; 46+ messages in thread
From: Santosh Shilimkar @ 2013-04-05 12:58 UTC (permalink / raw)
To: linux-arm-kernel
Kevin,
As discussed on list, I split the v2 [1] series into cleanup and OMAP5 support.
This series contains the clean-up patches. I have rebased on top of Tony's
pull request and your 3.10/* branches. Series is tested on OMAP4430 SDP
with CPUIDLE and suspend. OMAP5 PM support I will post later since it has
a dependency with OMAP5 data files which are not pulled in yet.
Regards,
Santosh
[1] http://www.spinics.net/lists/linux-omap/msg88901.html
The following changes since commit 4b9ce8484d8122f2088cedf60265ae86f7822350:
Merge branch 'for_3.10/fixes/pm' of git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-omap-pm into for_3.10/omap_pm-cleanup (2013-04-05 18:10:34 +0530)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/ssantosh/linux.git
for you to fetch changes up to 884ef029cb434aad124bf8413211a698597f8f7a:
ARM: OMAP4+: CPUidle: Consolidate idle driver for OMAP5 support (2013-04-05 18:11:06 +0530)
----------------------------------------------------------------
Santosh Shilimkar (4):
ARM: OMAP4+: PM: Consolidate MPU subsystem PM code for re-use
ARM: OMAP4+: PM: Consolidate OMAP4 PM code to re-use it for OMAP5
ARM: OMAP4+: Make secondary_startup function name more consistent
ARM: OMAP4+: CPUidle: Consolidate idle driver for OMAP5 support
arch/arm/mach-omap2/Makefile | 9 +--
arch/arm/mach-omap2/common.h | 4 +-
arch/arm/mach-omap2/cpuidle44xx.c | 31 ++++-----
arch/arm/mach-omap2/omap-headsmp.S | 8 +--
arch/arm/mach-omap2/omap-mpuss-lowpower.c | 68 ++++++++++++++++----
arch/arm/mach-omap2/omap-smp.c | 6 +-
arch/arm/mach-omap2/{pm44xx.c => pm_omap4plus.c} | 58 ++++++++++++++---
.../mach-omap2/{sleep44xx.S => sleep_omap4plus.S} | 0
8 files changed, 132 insertions(+), 52 deletions(-)
rename arch/arm/mach-omap2/{pm44xx.c => pm_omap4plus.c} (83%)
rename arch/arm/mach-omap2/{sleep44xx.S => sleep_omap4plus.S} (100%)
--
1.7.9.5
^ permalink raw reply [flat|nested] 46+ messages in thread
* [PATCH v3 1/4] ARM: OMAP4+: PM: Consolidate MPU subsystem PM code for re-use
2013-04-05 12:58 ` Santosh Shilimkar
@ 2013-04-05 12:59 ` Santosh Shilimkar
-1 siblings, 0 replies; 46+ messages in thread
From: Santosh Shilimkar @ 2013-04-05 12:59 UTC (permalink / raw)
To: khilman; +Cc: tony, linux-omap, Santosh Shilimkar, 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 | 62 ++++++++++++++++++++++++-----
1 file changed, 51 insertions(+), 11 deletions(-)
diff --git a/arch/arm/mach-omap2/omap-mpuss-lowpower.c b/arch/arm/mach-omap2/omap-mpuss-lowpower.c
index a27fe72..391bf2d 100644
--- a/arch/arm/mach-omap2/omap-mpuss-lowpower.c
+++ b/arch/arm/mach-omap2/omap-mpuss-lowpower.c
@@ -71,10 +71,43 @@ 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);
+};
+
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.
@@ -158,11 +191,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)
@@ -225,17 +259,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
@@ -271,14 +305,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;
@@ -355,6 +389,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] 46+ messages in thread
* [PATCH v3 1/4] ARM: OMAP4+: PM: Consolidate MPU subsystem PM code for re-use
@ 2013-04-05 12:59 ` Santosh Shilimkar
0 siblings, 0 replies; 46+ messages in thread
From: Santosh Shilimkar @ 2013-04-05 12:59 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 | 62 ++++++++++++++++++++++++-----
1 file changed, 51 insertions(+), 11 deletions(-)
diff --git a/arch/arm/mach-omap2/omap-mpuss-lowpower.c b/arch/arm/mach-omap2/omap-mpuss-lowpower.c
index a27fe72..391bf2d 100644
--- a/arch/arm/mach-omap2/omap-mpuss-lowpower.c
+++ b/arch/arm/mach-omap2/omap-mpuss-lowpower.c
@@ -71,10 +71,43 @@ 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);
+};
+
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.
@@ -158,11 +191,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)
@@ -225,17 +259,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
@@ -271,14 +305,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;
@@ -355,6 +389,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] 46+ messages in thread
* [PATCH v3 2/4] ARM: OMAP4+: PM: Consolidate OMAP4 PM code to re-use it for OMAP5
2013-04-05 12:58 ` Santosh Shilimkar
@ 2013-04-05 12:59 ` Santosh Shilimkar
-1 siblings, 0 replies; 46+ messages in thread
From: Santosh Shilimkar @ 2013-04-05 12:59 UTC (permalink / raw)
To: khilman; +Cc: tony, linux-omap, Santosh Shilimkar, 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.
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} | 58 ++++++++++++++++----
.../mach-omap2/{sleep44xx.S => sleep_omap4plus.S} | 0
3 files changed, 53 insertions(+), 14 deletions(-)
rename arch/arm/mach-omap2/{pm44xx.c => pm_omap4plus.c} (83%)
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 b068b7f..3e59895 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 83%
rename from arch/arm/mach-omap2/pm44xx.c
rename to arch/arm/mach-omap2/pm_omap4plus.c
index 5ba6d88..228deca 100644
--- a/arch/arm/mach-omap2/pm44xx.c
+++ b/arch/arm/mach-omap2/pm_omap4plus.c
@@ -1,7 +1,7 @@
/*
- * OMAP4 Power Management Routines
+ * OMAP4+ 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;
}
/*
@@ -171,6 +171,10 @@ int __init omap4_pm_init(void)
* MPUSS -> L4_PER/L3_* and DUCATI -> L3_* doesn't work as
* expected. The hardware recommendation is to enable static
* dependencies for these to avoid system lock ups or random crashes.
+ * The L4 wakeup depedency is added to workaround the OCP sync hardware
+ * BUG with 32K synctimer which lead to incorrect timer value read
+ * from the 32K counter. The BUG applies for GPTIMER1 and WDT2 which
+ * are part of L4 wakeup clockdomain.
*/
mpuss_clkdm = clkdm_lookup("mpuss_clkdm");
emif_clkdm = clkdm_lookup("l3_emif_clkdm");
@@ -179,7 +183,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 +192,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 OMAP4+ 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 +243,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] 46+ messages in thread
* [PATCH v3 2/4] ARM: OMAP4+: PM: Consolidate OMAP4 PM code to re-use it for OMAP5
@ 2013-04-05 12:59 ` Santosh Shilimkar
0 siblings, 0 replies; 46+ messages in thread
From: Santosh Shilimkar @ 2013-04-05 12:59 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.
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} | 58 ++++++++++++++++----
.../mach-omap2/{sleep44xx.S => sleep_omap4plus.S} | 0
3 files changed, 53 insertions(+), 14 deletions(-)
rename arch/arm/mach-omap2/{pm44xx.c => pm_omap4plus.c} (83%)
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 b068b7f..3e59895 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 83%
rename from arch/arm/mach-omap2/pm44xx.c
rename to arch/arm/mach-omap2/pm_omap4plus.c
index 5ba6d88..228deca 100644
--- a/arch/arm/mach-omap2/pm44xx.c
+++ b/arch/arm/mach-omap2/pm_omap4plus.c
@@ -1,7 +1,7 @@
/*
- * OMAP4 Power Management Routines
+ * OMAP4+ 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;
}
/*
@@ -171,6 +171,10 @@ int __init omap4_pm_init(void)
* MPUSS -> L4_PER/L3_* and DUCATI -> L3_* doesn't work as
* expected. The hardware recommendation is to enable static
* dependencies for these to avoid system lock ups or random crashes.
+ * The L4 wakeup depedency is added to workaround the OCP sync hardware
+ * BUG with 32K synctimer which lead to incorrect timer value read
+ * from the 32K counter. The BUG applies for GPTIMER1 and WDT2 which
+ * are part of L4 wakeup clockdomain.
*/
mpuss_clkdm = clkdm_lookup("mpuss_clkdm");
emif_clkdm = clkdm_lookup("l3_emif_clkdm");
@@ -179,7 +183,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 +192,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 OMAP4+ 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 +243,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] 46+ messages in thread
* [PATCH v3 3/4] ARM: OMAP4+: Make secondary_startup function name more consistent
2013-04-05 12:58 ` Santosh Shilimkar
@ 2013-04-05 12:59 ` Santosh Shilimkar
-1 siblings, 0 replies; 46+ messages in thread
From: Santosh Shilimkar @ 2013-04-05 12:59 UTC (permalink / raw)
To: khilman; +Cc: tony, linux-omap, Santosh Shilimkar, linux-arm-kernel
Current code has rather inconsistent function names for 'secondary_startup'
routines. Update it to make it more consistent.
Suggested by Kevin Hilman as part of OMAP5 PM patch review.
Cc: Kevin Hilman <khilman@deeprootsystems.com>
Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
---
arch/arm/mach-omap2/common.h | 4 ++--
arch/arm/mach-omap2/omap-headsmp.S | 8 ++++----
arch/arm/mach-omap2/omap-mpuss-lowpower.c | 6 +++---
arch/arm/mach-omap2/omap-smp.c | 6 +++---
4 files changed, 12 insertions(+), 12 deletions(-)
diff --git a/arch/arm/mach-omap2/common.h b/arch/arm/mach-omap2/common.h
index f5c9983..1fe86be 100644
--- a/arch/arm/mach-omap2/common.h
+++ b/arch/arm/mach-omap2/common.h
@@ -230,8 +230,8 @@ extern void omap_do_wfi(void);
#ifdef CONFIG_SMP
/* Needed for secondary core boot */
-extern void omap_secondary_startup(void);
-extern void omap_secondary_startup_4460(void);
+extern void omap4_secondary_startup(void);
+extern void omap4460_secondary_startup(void);
extern u32 omap_modify_auxcoreboot0(u32 set_mask, u32 clear_mask);
extern void omap_auxcoreboot_addr(u32 cpu_addr);
extern u32 omap_read_auxcoreboot0(void);
diff --git a/arch/arm/mach-omap2/omap-headsmp.S b/arch/arm/mach-omap2/omap-headsmp.S
index 0ea09fa..4ea3081 100644
--- a/arch/arm/mach-omap2/omap-headsmp.S
+++ b/arch/arm/mach-omap2/omap-headsmp.S
@@ -49,7 +49,7 @@ END(omap5_secondary_startup)
* The primary core will update this flag using a hardware
* register AuxCoreBoot0.
*/
-ENTRY(omap_secondary_startup)
+ENTRY(omap4_secondary_startup)
hold: ldr r12,=0x103
dsb
smc #0 @ read from AuxCoreBoot0
@@ -64,9 +64,9 @@ hold: ldr r12,=0x103
* should now contain the SVC stack for this core
*/
b secondary_startup
-ENDPROC(omap_secondary_startup)
+ENDPROC(omap4_secondary_startup)
-ENTRY(omap_secondary_startup_4460)
+ENTRY(omap4460_secondary_startup)
hold_2: ldr r12,=0x103
dsb
smc #0 @ read from AuxCoreBoot0
@@ -101,4 +101,4 @@ hold_2: ldr r12,=0x103
* should now contain the SVC stack for this core
*/
b secondary_startup
-ENDPROC(omap_secondary_startup_4460)
+ENDPROC(omap4460_secondary_startup)
diff --git a/arch/arm/mach-omap2/omap-mpuss-lowpower.c b/arch/arm/mach-omap2/omap-mpuss-lowpower.c
index 391bf2d..f993a41 100644
--- a/arch/arm/mach-omap2/omap-mpuss-lowpower.c
+++ b/arch/arm/mach-omap2/omap-mpuss-lowpower.c
@@ -310,7 +310,7 @@ int __cpuinit omap4_hotplug_cpu(unsigned int cpu, unsigned int 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_secondary_startup().
*/
omap_pm_ops.finish_suspend(cpu_state);
@@ -356,9 +356,9 @@ int __init omap4_mpuss_init(void)
pm_info->wkup_sar_addr = sar_base + CPU1_WAKEUP_NS_PA_ADDR_OFFSET;
pm_info->l2x0_sar_addr = sar_base + L2X0_SAVE_OFFSET1;
if (cpu_is_omap446x())
- pm_info->secondary_startup = omap_secondary_startup_4460;
+ pm_info->secondary_startup = omap4460_secondary_startup;
else
- pm_info->secondary_startup = omap_secondary_startup;
+ pm_info->secondary_startup = omap4_secondary_startup;
pm_info->pwrdm = pwrdm_lookup("cpu1_pwrdm");
if (!pm_info->pwrdm) {
diff --git a/arch/arm/mach-omap2/omap-smp.c b/arch/arm/mach-omap2/omap-smp.c
index e4441cc..8106e8d 100644
--- a/arch/arm/mach-omap2/omap-smp.c
+++ b/arch/arm/mach-omap2/omap-smp.c
@@ -94,7 +94,7 @@ static int __cpuinit omap4_boot_secondary(unsigned int cpu, struct task_struct *
/*
* Update the AuxCoreBoot0 with boot state for secondary core.
- * omap_secondary_startup() routine will hold the secondary core till
+ * omap4_secondary_startup() routine will hold the secondary core till
* the AuxCoreBoot1 register is updated with cpu state
* A barrier is added to ensure that write buffer is drained
*/
@@ -207,7 +207,7 @@ static void __init omap4_smp_init_cpus(void)
static void __init omap4_smp_prepare_cpus(unsigned int max_cpus)
{
- void *startup_addr = omap_secondary_startup;
+ void *startup_addr = omap4_secondary_startup;
void __iomem *base = omap_get_wakeupgen_base();
/*
@@ -218,7 +218,7 @@ static void __init omap4_smp_prepare_cpus(unsigned int max_cpus)
scu_enable(scu_base);
if (cpu_is_omap446x()) {
- startup_addr = omap_secondary_startup_4460;
+ startup_addr = omap4460_secondary_startup;
pm44xx_errata |= PM_OMAP4_ROM_SMP_BOOT_ERRATUM_GICD;
}
--
1.7.9.5
^ permalink raw reply related [flat|nested] 46+ messages in thread
* [PATCH v3 3/4] ARM: OMAP4+: Make secondary_startup function name more consistent
@ 2013-04-05 12:59 ` Santosh Shilimkar
0 siblings, 0 replies; 46+ messages in thread
From: Santosh Shilimkar @ 2013-04-05 12:59 UTC (permalink / raw)
To: linux-arm-kernel
Current code has rather inconsistent function names for 'secondary_startup'
routines. Update it to make it more consistent.
Suggested by Kevin Hilman as part of OMAP5 PM patch review.
Cc: Kevin Hilman <khilman@deeprootsystems.com>
Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
---
arch/arm/mach-omap2/common.h | 4 ++--
arch/arm/mach-omap2/omap-headsmp.S | 8 ++++----
arch/arm/mach-omap2/omap-mpuss-lowpower.c | 6 +++---
arch/arm/mach-omap2/omap-smp.c | 6 +++---
4 files changed, 12 insertions(+), 12 deletions(-)
diff --git a/arch/arm/mach-omap2/common.h b/arch/arm/mach-omap2/common.h
index f5c9983..1fe86be 100644
--- a/arch/arm/mach-omap2/common.h
+++ b/arch/arm/mach-omap2/common.h
@@ -230,8 +230,8 @@ extern void omap_do_wfi(void);
#ifdef CONFIG_SMP
/* Needed for secondary core boot */
-extern void omap_secondary_startup(void);
-extern void omap_secondary_startup_4460(void);
+extern void omap4_secondary_startup(void);
+extern void omap4460_secondary_startup(void);
extern u32 omap_modify_auxcoreboot0(u32 set_mask, u32 clear_mask);
extern void omap_auxcoreboot_addr(u32 cpu_addr);
extern u32 omap_read_auxcoreboot0(void);
diff --git a/arch/arm/mach-omap2/omap-headsmp.S b/arch/arm/mach-omap2/omap-headsmp.S
index 0ea09fa..4ea3081 100644
--- a/arch/arm/mach-omap2/omap-headsmp.S
+++ b/arch/arm/mach-omap2/omap-headsmp.S
@@ -49,7 +49,7 @@ END(omap5_secondary_startup)
* The primary core will update this flag using a hardware
* register AuxCoreBoot0.
*/
-ENTRY(omap_secondary_startup)
+ENTRY(omap4_secondary_startup)
hold: ldr r12,=0x103
dsb
smc #0 @ read from AuxCoreBoot0
@@ -64,9 +64,9 @@ hold: ldr r12,=0x103
* should now contain the SVC stack for this core
*/
b secondary_startup
-ENDPROC(omap_secondary_startup)
+ENDPROC(omap4_secondary_startup)
-ENTRY(omap_secondary_startup_4460)
+ENTRY(omap4460_secondary_startup)
hold_2: ldr r12,=0x103
dsb
smc #0 @ read from AuxCoreBoot0
@@ -101,4 +101,4 @@ hold_2: ldr r12,=0x103
* should now contain the SVC stack for this core
*/
b secondary_startup
-ENDPROC(omap_secondary_startup_4460)
+ENDPROC(omap4460_secondary_startup)
diff --git a/arch/arm/mach-omap2/omap-mpuss-lowpower.c b/arch/arm/mach-omap2/omap-mpuss-lowpower.c
index 391bf2d..f993a41 100644
--- a/arch/arm/mach-omap2/omap-mpuss-lowpower.c
+++ b/arch/arm/mach-omap2/omap-mpuss-lowpower.c
@@ -310,7 +310,7 @@ int __cpuinit omap4_hotplug_cpu(unsigned int cpu, unsigned int 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_secondary_startup().
*/
omap_pm_ops.finish_suspend(cpu_state);
@@ -356,9 +356,9 @@ int __init omap4_mpuss_init(void)
pm_info->wkup_sar_addr = sar_base + CPU1_WAKEUP_NS_PA_ADDR_OFFSET;
pm_info->l2x0_sar_addr = sar_base + L2X0_SAVE_OFFSET1;
if (cpu_is_omap446x())
- pm_info->secondary_startup = omap_secondary_startup_4460;
+ pm_info->secondary_startup = omap4460_secondary_startup;
else
- pm_info->secondary_startup = omap_secondary_startup;
+ pm_info->secondary_startup = omap4_secondary_startup;
pm_info->pwrdm = pwrdm_lookup("cpu1_pwrdm");
if (!pm_info->pwrdm) {
diff --git a/arch/arm/mach-omap2/omap-smp.c b/arch/arm/mach-omap2/omap-smp.c
index e4441cc..8106e8d 100644
--- a/arch/arm/mach-omap2/omap-smp.c
+++ b/arch/arm/mach-omap2/omap-smp.c
@@ -94,7 +94,7 @@ static int __cpuinit omap4_boot_secondary(unsigned int cpu, struct task_struct *
/*
* Update the AuxCoreBoot0 with boot state for secondary core.
- * omap_secondary_startup() routine will hold the secondary core till
+ * omap4_secondary_startup() routine will hold the secondary core till
* the AuxCoreBoot1 register is updated with cpu state
* A barrier is added to ensure that write buffer is drained
*/
@@ -207,7 +207,7 @@ static void __init omap4_smp_init_cpus(void)
static void __init omap4_smp_prepare_cpus(unsigned int max_cpus)
{
- void *startup_addr = omap_secondary_startup;
+ void *startup_addr = omap4_secondary_startup;
void __iomem *base = omap_get_wakeupgen_base();
/*
@@ -218,7 +218,7 @@ static void __init omap4_smp_prepare_cpus(unsigned int max_cpus)
scu_enable(scu_base);
if (cpu_is_omap446x()) {
- startup_addr = omap_secondary_startup_4460;
+ startup_addr = omap4460_secondary_startup;
pm44xx_errata |= PM_OMAP4_ROM_SMP_BOOT_ERRATUM_GICD;
}
--
1.7.9.5
^ permalink raw reply related [flat|nested] 46+ messages in thread
* [PATCH v3 4/4] ARM: OMAP4+: CPUidle: Consolidate idle driver for OMAP5 support
2013-04-05 12:58 ` Santosh Shilimkar
@ 2013-04-05 12:59 ` Santosh Shilimkar
-1 siblings, 0 replies; 46+ messages in thread
From: Santosh Shilimkar @ 2013-04-05 12:59 UTC (permalink / raw)
To: khilman; +Cc: tony, linux-omap, Santosh Shilimkar, 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 767f657..ca1551a 100644
--- a/arch/arm/mach-omap2/cpuidle44xx.c
+++ b/arch/arm/mach-omap2/cpuidle44xx.c
@@ -1,7 +1,7 @@
/*
- * OMAP4 CPU idle Routines
+ * OMAP4+ 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();
/*
@@ -168,7 +169,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",
@@ -180,7 +181,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"
},
@@ -189,7 +190,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",
},
@@ -198,7 +199,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",
},
@@ -210,9 +211,9 @@ static struct cpuidle_driver omap4_idle_driver = {
/* Public functions */
/**
- * omap4_idle_init - Init routine for OMAP4 idle
+ * omap4_idle_init - Init routine for OMAP4+ idle
*
- * Registers the OMAP4 specific cpuidle driver to the cpuidle
+ * Registers the OMAP4+ specific cpuidle driver to the cpuidle
* framework with the valid set of states.
*/
int __init omap4_idle_init(void)
@@ -240,7 +241,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] 46+ messages in thread
* [PATCH v3 4/4] ARM: OMAP4+: CPUidle: Consolidate idle driver for OMAP5 support
@ 2013-04-05 12:59 ` Santosh Shilimkar
0 siblings, 0 replies; 46+ messages in thread
From: Santosh Shilimkar @ 2013-04-05 12:59 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 767f657..ca1551a 100644
--- a/arch/arm/mach-omap2/cpuidle44xx.c
+++ b/arch/arm/mach-omap2/cpuidle44xx.c
@@ -1,7 +1,7 @@
/*
- * OMAP4 CPU idle Routines
+ * OMAP4+ 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();
/*
@@ -168,7 +169,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",
@@ -180,7 +181,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"
},
@@ -189,7 +190,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",
},
@@ -198,7 +199,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",
},
@@ -210,9 +211,9 @@ static struct cpuidle_driver omap4_idle_driver = {
/* Public functions */
/**
- * omap4_idle_init - Init routine for OMAP4 idle
+ * omap4_idle_init - Init routine for OMAP4+ idle
*
- * Registers the OMAP4 specific cpuidle driver to the cpuidle
+ * Registers the OMAP4+ specific cpuidle driver to the cpuidle
* framework with the valid set of states.
*/
int __init omap4_idle_init(void)
@@ -240,7 +241,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] 46+ messages in thread
* Re: [PATCH v3 1/4] ARM: OMAP4+: PM: Consolidate MPU subsystem PM code for re-use
2013-04-05 12:59 ` Santosh Shilimkar
@ 2013-04-05 13:19 ` Felipe Balbi
-1 siblings, 0 replies; 46+ messages in thread
From: Felipe Balbi @ 2013-04-05 13:19 UTC (permalink / raw)
To: Santosh Shilimkar; +Cc: khilman, tony, linux-omap, linux-arm-kernel
[-- Attachment #1.1: Type: text/plain, Size: 831 bytes --]
On Fri, Apr 05, 2013 at 06:29:00PM +0530, Santosh Shilimkar wrote:
> OMAP5 and future OMAP based SOCs has backward compatible MPUSS
> IP block with OMAP4. It's programming model is mostly similar.
s/It's/Its/
s/mostly //
(similar already expands to 'almost the same' :-)
> @@ -355,6 +389,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;
> + }
why don't you just rename omap4_* into omap_* and add cpu-based checks
there in order to handle differences between omap4 and omap5?
If implementation will be almost the same for both, you might be able to
save on some more duplication, no ?
--
balbi
[-- Attachment #1.2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
[-- Attachment #2: Type: text/plain, Size: 176 bytes --]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 46+ messages in thread
* [PATCH v3 1/4] ARM: OMAP4+: PM: Consolidate MPU subsystem PM code for re-use
@ 2013-04-05 13:19 ` Felipe Balbi
0 siblings, 0 replies; 46+ messages in thread
From: Felipe Balbi @ 2013-04-05 13:19 UTC (permalink / raw)
To: linux-arm-kernel
On Fri, Apr 05, 2013 at 06:29:00PM +0530, Santosh Shilimkar wrote:
> OMAP5 and future OMAP based SOCs has backward compatible MPUSS
> IP block with OMAP4. It's programming model is mostly similar.
s/It's/Its/
s/mostly //
(similar already expands to 'almost the same' :-)
> @@ -355,6 +389,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;
> + }
why don't you just rename omap4_* into omap_* and add cpu-based checks
there in order to handle differences between omap4 and omap5?
If implementation will be almost the same for both, you might be able to
save on some more duplication, no ?
--
balbi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130405/93830beb/attachment.sig>
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: [PATCH v3 2/4] ARM: OMAP4+: PM: Consolidate OMAP4 PM code to re-use it for OMAP5
2013-04-05 12:59 ` Santosh Shilimkar
@ 2013-04-05 13:21 ` Felipe Balbi
-1 siblings, 0 replies; 46+ messages in thread
From: Felipe Balbi @ 2013-04-05 13:21 UTC (permalink / raw)
To: Santosh Shilimkar; +Cc: khilman, tony, linux-omap, linux-arm-kernel
[-- Attachment #1.1: Type: text/plain, Size: 3846 bytes --]
On Fri, Apr 05, 2013 at 06:29:01PM +0530, Santosh Shilimkar wrote:
> 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.
>
> 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} | 58 ++++++++++++++++----
> .../mach-omap2/{sleep44xx.S => sleep_omap4plus.S} | 0
> 3 files changed, 53 insertions(+), 14 deletions(-)
> rename arch/arm/mach-omap2/{pm44xx.c => pm_omap4plus.c} (83%)
> 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 b068b7f..3e59895 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 83%
> rename from arch/arm/mach-omap2/pm44xx.c
> rename to arch/arm/mach-omap2/pm_omap4plus.c
> index 5ba6d88..228deca 100644
> --- a/arch/arm/mach-omap2/pm44xx.c
> +++ b/arch/arm/mach-omap2/pm_omap4plus.c
> @@ -1,7 +1,7 @@
> /*
> - * OMAP4 Power Management Routines
> + * OMAP4+ 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)
you can let compiler inline this if it chooses to, right ?? Otherwise,
if you really want to make sure this will be inlined, you could(should?)
be using __always_inline.
--
balbi
[-- Attachment #1.2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
[-- Attachment #2: Type: text/plain, Size: 176 bytes --]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 46+ messages in thread
* [PATCH v3 2/4] ARM: OMAP4+: PM: Consolidate OMAP4 PM code to re-use it for OMAP5
@ 2013-04-05 13:21 ` Felipe Balbi
0 siblings, 0 replies; 46+ messages in thread
From: Felipe Balbi @ 2013-04-05 13:21 UTC (permalink / raw)
To: linux-arm-kernel
On Fri, Apr 05, 2013 at 06:29:01PM +0530, Santosh Shilimkar wrote:
> 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.
>
> 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} | 58 ++++++++++++++++----
> .../mach-omap2/{sleep44xx.S => sleep_omap4plus.S} | 0
> 3 files changed, 53 insertions(+), 14 deletions(-)
> rename arch/arm/mach-omap2/{pm44xx.c => pm_omap4plus.c} (83%)
> 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 b068b7f..3e59895 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 83%
> rename from arch/arm/mach-omap2/pm44xx.c
> rename to arch/arm/mach-omap2/pm_omap4plus.c
> index 5ba6d88..228deca 100644
> --- a/arch/arm/mach-omap2/pm44xx.c
> +++ b/arch/arm/mach-omap2/pm_omap4plus.c
> @@ -1,7 +1,7 @@
> /*
> - * OMAP4 Power Management Routines
> + * OMAP4+ 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)
you can let compiler inline this if it chooses to, right ?? Otherwise,
if you really want to make sure this will be inlined, you could(should?)
be using __always_inline.
--
balbi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130405/fa4fb3f8/attachment.sig>
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: [PATCH v3 1/4] ARM: OMAP4+: PM: Consolidate MPU subsystem PM code for re-use
2013-04-05 13:19 ` Felipe Balbi
@ 2013-04-05 13:35 ` Nishanth Menon
-1 siblings, 0 replies; 46+ messages in thread
From: Nishanth Menon @ 2013-04-05 13:35 UTC (permalink / raw)
To: Felipe Balbi
Cc: khilman, tony, linux-omap, Santosh Shilimkar, linux-arm-kernel
On 16:19-20130405, Felipe Balbi wrote:
> On Fri, Apr 05, 2013 at 06:29:00PM +0530, Santosh Shilimkar wrote:
> > OMAP5 and future OMAP based SOCs has backward compatible MPUSS
> > IP block with OMAP4. It's programming model is mostly similar.
>
> s/It's/Its/
> s/mostly //
>
> (similar already expands to 'almost the same' :-)
>
> > @@ -355,6 +389,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;
> > + }
>
> why don't you just rename omap4_* into omap_* and add cpu-based checks
> there in order to handle differences between omap4 and omap5?
>
> If implementation will be almost the same for both, you might be able to
> save on some more duplication, no ?
Jeez NO! finish_suspend is assembly, further, it is the hottest path in
cpuidle framework - for every WFI we invoke it. we definitely dont want
to add more overhead beyond what is necessary.
>
> --
> balbi
--
Regards,
Nishanth Menon
^ permalink raw reply [flat|nested] 46+ messages in thread
* [PATCH v3 1/4] ARM: OMAP4+: PM: Consolidate MPU subsystem PM code for re-use
@ 2013-04-05 13:35 ` Nishanth Menon
0 siblings, 0 replies; 46+ messages in thread
From: Nishanth Menon @ 2013-04-05 13:35 UTC (permalink / raw)
To: linux-arm-kernel
On 16:19-20130405, Felipe Balbi wrote:
> On Fri, Apr 05, 2013 at 06:29:00PM +0530, Santosh Shilimkar wrote:
> > OMAP5 and future OMAP based SOCs has backward compatible MPUSS
> > IP block with OMAP4. It's programming model is mostly similar.
>
> s/It's/Its/
> s/mostly //
>
> (similar already expands to 'almost the same' :-)
>
> > @@ -355,6 +389,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;
> > + }
>
> why don't you just rename omap4_* into omap_* and add cpu-based checks
> there in order to handle differences between omap4 and omap5?
>
> If implementation will be almost the same for both, you might be able to
> save on some more duplication, no ?
Jeez NO! finish_suspend is assembly, further, it is the hottest path in
cpuidle framework - for every WFI we invoke it. we definitely dont want
to add more overhead beyond what is necessary.
>
> --
> balbi
--
Regards,
Nishanth Menon
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: [PATCH v3 2/4] ARM: OMAP4+: PM: Consolidate OMAP4 PM code to re-use it for OMAP5
2013-04-05 13:21 ` Felipe Balbi
@ 2013-04-05 13:35 ` Santosh Shilimkar
-1 siblings, 0 replies; 46+ messages in thread
From: Santosh Shilimkar @ 2013-04-05 13:35 UTC (permalink / raw)
To: balbi; +Cc: khilman, tony, linux-omap, linux-arm-kernel
On Friday 05 April 2013 06:51 PM, Felipe Balbi wrote:
> On Fri, Apr 05, 2013 at 06:29:01PM +0530, Santosh Shilimkar wrote:
>> 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.
>>
>> 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} | 58 ++++++++++++++++----
>> .../mach-omap2/{sleep44xx.S => sleep_omap4plus.S} | 0
>> 3 files changed, 53 insertions(+), 14 deletions(-)
>> rename arch/arm/mach-omap2/{pm44xx.c => pm_omap4plus.c} (83%)
>> 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 b068b7f..3e59895 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 83%
>> rename from arch/arm/mach-omap2/pm44xx.c
>> rename to arch/arm/mach-omap2/pm_omap4plus.c
>> index 5ba6d88..228deca 100644
>> --- a/arch/arm/mach-omap2/pm44xx.c
>> +++ b/arch/arm/mach-omap2/pm_omap4plus.c
>> @@ -1,7 +1,7 @@
>> /*
>> - * OMAP4 Power Management Routines
>> + * OMAP4+ 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)
>
> you can let compiler inline this if it chooses to, right ?? Otherwise,
> if you really want to make sure this will be inlined, you could(should?)
> be using __always_inline.
>
Compilers are smart now so that fine.
^ permalink raw reply [flat|nested] 46+ messages in thread
* [PATCH v3 2/4] ARM: OMAP4+: PM: Consolidate OMAP4 PM code to re-use it for OMAP5
@ 2013-04-05 13:35 ` Santosh Shilimkar
0 siblings, 0 replies; 46+ messages in thread
From: Santosh Shilimkar @ 2013-04-05 13:35 UTC (permalink / raw)
To: linux-arm-kernel
On Friday 05 April 2013 06:51 PM, Felipe Balbi wrote:
> On Fri, Apr 05, 2013 at 06:29:01PM +0530, Santosh Shilimkar wrote:
>> 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.
>>
>> 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} | 58 ++++++++++++++++----
>> .../mach-omap2/{sleep44xx.S => sleep_omap4plus.S} | 0
>> 3 files changed, 53 insertions(+), 14 deletions(-)
>> rename arch/arm/mach-omap2/{pm44xx.c => pm_omap4plus.c} (83%)
>> 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 b068b7f..3e59895 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 83%
>> rename from arch/arm/mach-omap2/pm44xx.c
>> rename to arch/arm/mach-omap2/pm_omap4plus.c
>> index 5ba6d88..228deca 100644
>> --- a/arch/arm/mach-omap2/pm44xx.c
>> +++ b/arch/arm/mach-omap2/pm_omap4plus.c
>> @@ -1,7 +1,7 @@
>> /*
>> - * OMAP4 Power Management Routines
>> + * OMAP4+ 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)
>
> you can let compiler inline this if it chooses to, right ?? Otherwise,
> if you really want to make sure this will be inlined, you could(should?)
> be using __always_inline.
>
Compilers are smart now so that fine.
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: [PATCH v3 1/4] ARM: OMAP4+: PM: Consolidate MPU subsystem PM code for re-use
2013-04-05 13:19 ` Felipe Balbi
@ 2013-04-05 13:37 ` Santosh Shilimkar
-1 siblings, 0 replies; 46+ messages in thread
From: Santosh Shilimkar @ 2013-04-05 13:37 UTC (permalink / raw)
To: balbi; +Cc: khilman, tony, linux-omap, linux-arm-kernel
On Friday 05 April 2013 06:49 PM, Felipe Balbi wrote:
> On Fri, Apr 05, 2013 at 06:29:00PM +0530, Santosh Shilimkar wrote:
>> OMAP5 and future OMAP based SOCs has backward compatible MPUSS
>> IP block with OMAP4. It's programming model is mostly similar.
>
> s/It's/Its/
> s/mostly //
>
> (similar already expands to 'almost the same' :-)
>
>> @@ -355,6 +389,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;
>> + }
>
> why don't you just rename omap4_* into omap_* and add cpu-based checks
> there in order to handle differences between omap4 and omap5?
>
The whole idea is to handle all these SOC specific stuff in init and
not sprinkle the checks in runtime code.
> If implementation will be almost the same for both, you might be able to
> save on some more duplication, no ?
>
The implementation is not same and hence. If it was same, I wouldn't
have introduced function pointers :)
Regards,
Santosh
^ permalink raw reply [flat|nested] 46+ messages in thread
* [PATCH v3 1/4] ARM: OMAP4+: PM: Consolidate MPU subsystem PM code for re-use
@ 2013-04-05 13:37 ` Santosh Shilimkar
0 siblings, 0 replies; 46+ messages in thread
From: Santosh Shilimkar @ 2013-04-05 13:37 UTC (permalink / raw)
To: linux-arm-kernel
On Friday 05 April 2013 06:49 PM, Felipe Balbi wrote:
> On Fri, Apr 05, 2013 at 06:29:00PM +0530, Santosh Shilimkar wrote:
>> OMAP5 and future OMAP based SOCs has backward compatible MPUSS
>> IP block with OMAP4. It's programming model is mostly similar.
>
> s/It's/Its/
> s/mostly //
>
> (similar already expands to 'almost the same' :-)
>
>> @@ -355,6 +389,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;
>> + }
>
> why don't you just rename omap4_* into omap_* and add cpu-based checks
> there in order to handle differences between omap4 and omap5?
>
The whole idea is to handle all these SOC specific stuff in init and
not sprinkle the checks in runtime code.
> If implementation will be almost the same for both, you might be able to
> save on some more duplication, no ?
>
The implementation is not same and hence. If it was same, I wouldn't
have introduced function pointers :)
Regards,
Santosh
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: [PATCH v3 1/4] ARM: OMAP4+: PM: Consolidate MPU subsystem PM code for re-use
2013-04-05 13:35 ` Nishanth Menon
@ 2013-04-05 13:39 ` Santosh Shilimkar
-1 siblings, 0 replies; 46+ messages in thread
From: Santosh Shilimkar @ 2013-04-05 13:39 UTC (permalink / raw)
To: Nishanth Menon; +Cc: khilman, tony, linux-omap, linux-arm-kernel, Felipe Balbi
On Friday 05 April 2013 07:05 PM, Nishanth Menon wrote:
> On 16:19-20130405, Felipe Balbi wrote:
>> On Fri, Apr 05, 2013 at 06:29:00PM +0530, Santosh Shilimkar wrote:
>>> OMAP5 and future OMAP based SOCs has backward compatible MPUSS
>>> IP block with OMAP4. It's programming model is mostly similar.
>>
>> s/It's/Its/
>> s/mostly //
>>
>> (similar already expands to 'almost the same' :-)
>>
>>> @@ -355,6 +389,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;
>>> + }
>>
>> why don't you just rename omap4_* into omap_* and add cpu-based checks
>> there in order to handle differences between omap4 and omap5?
>>
>> If implementation will be almost the same for both, you might be able to
>> save on some more duplication, no ?
> Jeez NO! finish_suspend is assembly, further, it is the hottest path in
> cpuidle framework - for every WFI we invoke it. we definitely dont want
> to add more overhead beyond what is necessary.
:-)
Our emails crossed. I just said the same thing in other words.
Regards,
Santosh
^ permalink raw reply [flat|nested] 46+ messages in thread
* [PATCH v3 1/4] ARM: OMAP4+: PM: Consolidate MPU subsystem PM code for re-use
@ 2013-04-05 13:39 ` Santosh Shilimkar
0 siblings, 0 replies; 46+ messages in thread
From: Santosh Shilimkar @ 2013-04-05 13:39 UTC (permalink / raw)
To: linux-arm-kernel
On Friday 05 April 2013 07:05 PM, Nishanth Menon wrote:
> On 16:19-20130405, Felipe Balbi wrote:
>> On Fri, Apr 05, 2013 at 06:29:00PM +0530, Santosh Shilimkar wrote:
>>> OMAP5 and future OMAP based SOCs has backward compatible MPUSS
>>> IP block with OMAP4. It's programming model is mostly similar.
>>
>> s/It's/Its/
>> s/mostly //
>>
>> (similar already expands to 'almost the same' :-)
>>
>>> @@ -355,6 +389,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;
>>> + }
>>
>> why don't you just rename omap4_* into omap_* and add cpu-based checks
>> there in order to handle differences between omap4 and omap5?
>>
>> If implementation will be almost the same for both, you might be able to
>> save on some more duplication, no ?
> Jeez NO! finish_suspend is assembly, further, it is the hottest path in
> cpuidle framework - for every WFI we invoke it. we definitely dont want
> to add more overhead beyond what is necessary.
:-)
Our emails crossed. I just said the same thing in other words.
Regards,
Santosh
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: [PATCH v3 1/4] ARM: OMAP4+: PM: Consolidate MPU subsystem PM code for re-use
2013-04-05 13:35 ` Nishanth Menon
@ 2013-04-05 14:04 ` Felipe Balbi
-1 siblings, 0 replies; 46+ messages in thread
From: Felipe Balbi @ 2013-04-05 14:04 UTC (permalink / raw)
To: Nishanth Menon
Cc: khilman, Felipe Balbi, tony, Santosh Shilimkar, linux-omap,
linux-arm-kernel
[-- Attachment #1.1: Type: text/plain, Size: 1311 bytes --]
Hi,
On Fri, Apr 05, 2013 at 08:35:11AM -0500, Nishanth Menon wrote:
> On 16:19-20130405, Felipe Balbi wrote:
> > On Fri, Apr 05, 2013 at 06:29:00PM +0530, Santosh Shilimkar wrote:
> > > OMAP5 and future OMAP based SOCs has backward compatible MPUSS
> > > IP block with OMAP4. It's programming model is mostly similar.
> >
> > s/It's/Its/
> > s/mostly //
> >
> > (similar already expands to 'almost the same' :-)
> >
> > > @@ -355,6 +389,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;
> > > + }
> >
> > why don't you just rename omap4_* into omap_* and add cpu-based checks
> > there in order to handle differences between omap4 and omap5?
> >
> > If implementation will be almost the same for both, you might be able to
> > save on some more duplication, no ?
> Jeez NO! finish_suspend is assembly, further, it is the hottest path in
> cpuidle framework - for every WFI we invoke it. we definitely dont want
> to add more overhead beyond what is necessary.
alright, settle down ;-) whoever suggested that isn't here anymore
--
balbi
[-- Attachment #1.2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
[-- Attachment #2: Type: text/plain, Size: 176 bytes --]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 46+ messages in thread
* [PATCH v3 1/4] ARM: OMAP4+: PM: Consolidate MPU subsystem PM code for re-use
@ 2013-04-05 14:04 ` Felipe Balbi
0 siblings, 0 replies; 46+ messages in thread
From: Felipe Balbi @ 2013-04-05 14:04 UTC (permalink / raw)
To: linux-arm-kernel
Hi,
On Fri, Apr 05, 2013 at 08:35:11AM -0500, Nishanth Menon wrote:
> On 16:19-20130405, Felipe Balbi wrote:
> > On Fri, Apr 05, 2013 at 06:29:00PM +0530, Santosh Shilimkar wrote:
> > > OMAP5 and future OMAP based SOCs has backward compatible MPUSS
> > > IP block with OMAP4. It's programming model is mostly similar.
> >
> > s/It's/Its/
> > s/mostly //
> >
> > (similar already expands to 'almost the same' :-)
> >
> > > @@ -355,6 +389,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;
> > > + }
> >
> > why don't you just rename omap4_* into omap_* and add cpu-based checks
> > there in order to handle differences between omap4 and omap5?
> >
> > If implementation will be almost the same for both, you might be able to
> > save on some more duplication, no ?
> Jeez NO! finish_suspend is assembly, further, it is the hottest path in
> cpuidle framework - for every WFI we invoke it. we definitely dont want
> to add more overhead beyond what is necessary.
alright, settle down ;-) whoever suggested that isn't here anymore
--
balbi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130405/40db40d5/attachment-0001.sig>
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: [PATCH v3 1/4] ARM: OMAP4+: PM: Consolidate MPU subsystem PM code for re-use
2013-04-05 14:04 ` Felipe Balbi
@ 2013-04-05 14:18 ` Nishanth Menon
-1 siblings, 0 replies; 46+ messages in thread
From: Nishanth Menon @ 2013-04-05 14:18 UTC (permalink / raw)
To: Felipe Balbi
Cc: khilman, tony, linux-omap, Santosh Shilimkar, linux-arm-kernel
On 17:04-20130405, Felipe Balbi wrote:
> Hi,
>
> On Fri, Apr 05, 2013 at 08:35:11AM -0500, Nishanth Menon wrote:
> > On 16:19-20130405, Felipe Balbi wrote:
> > > On Fri, Apr 05, 2013 at 06:29:00PM +0530, Santosh Shilimkar wrote:
> > > > OMAP5 and future OMAP based SOCs has backward compatible MPUSS
> > > > IP block with OMAP4. It's programming model is mostly similar.
> > >
> > > s/It's/Its/
> > > s/mostly //
> > >
> > > (similar already expands to 'almost the same' :-)
> > >
> > > > @@ -355,6 +389,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;
> > > > + }
> > >
> > > why don't you just rename omap4_* into omap_* and add cpu-based checks
> > > there in order to handle differences between omap4 and omap5?
> > >
> > > If implementation will be almost the same for both, you might be able to
> > > save on some more duplication, no ?
> > Jeez NO! finish_suspend is assembly, further, it is the hottest path in
> > cpuidle framework - for every WFI we invoke it. we definitely dont want
> > to add more overhead beyond what is necessary.
>
> alright, settle down ;-) whoever suggested that isn't here anymore
hehe, Apologies, I was'nt that stressed as the wording might have
indicated.. We spend tons of time evaluating with Lauterbach tracing to
weed out hot paths - folks who have been bitten by these tend to feel a
little defensive I guess and to have surprise regressions are painful to
find and fix - esp when around not-so-obvious paths ;)
--
Regards,
Nishanth Menon
^ permalink raw reply [flat|nested] 46+ messages in thread
* [PATCH v3 1/4] ARM: OMAP4+: PM: Consolidate MPU subsystem PM code for re-use
@ 2013-04-05 14:18 ` Nishanth Menon
0 siblings, 0 replies; 46+ messages in thread
From: Nishanth Menon @ 2013-04-05 14:18 UTC (permalink / raw)
To: linux-arm-kernel
On 17:04-20130405, Felipe Balbi wrote:
> Hi,
>
> On Fri, Apr 05, 2013 at 08:35:11AM -0500, Nishanth Menon wrote:
> > On 16:19-20130405, Felipe Balbi wrote:
> > > On Fri, Apr 05, 2013 at 06:29:00PM +0530, Santosh Shilimkar wrote:
> > > > OMAP5 and future OMAP based SOCs has backward compatible MPUSS
> > > > IP block with OMAP4. It's programming model is mostly similar.
> > >
> > > s/It's/Its/
> > > s/mostly //
> > >
> > > (similar already expands to 'almost the same' :-)
> > >
> > > > @@ -355,6 +389,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;
> > > > + }
> > >
> > > why don't you just rename omap4_* into omap_* and add cpu-based checks
> > > there in order to handle differences between omap4 and omap5?
> > >
> > > If implementation will be almost the same for both, you might be able to
> > > save on some more duplication, no ?
> > Jeez NO! finish_suspend is assembly, further, it is the hottest path in
> > cpuidle framework - for every WFI we invoke it. we definitely dont want
> > to add more overhead beyond what is necessary.
>
> alright, settle down ;-) whoever suggested that isn't here anymore
hehe, Apologies, I was'nt that stressed as the wording might have
indicated.. We spend tons of time evaluating with Lauterbach tracing to
weed out hot paths - folks who have been bitten by these tend to feel a
little defensive I guess and to have surprise regressions are painful to
find and fix - esp when around not-so-obvious paths ;)
--
Regards,
Nishanth Menon
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: [PATCH v3 1/4] ARM: OMAP4+: PM: Consolidate MPU subsystem PM code for re-use
2013-04-05 14:18 ` Nishanth Menon
@ 2013-04-05 14:29 ` Felipe Balbi
-1 siblings, 0 replies; 46+ messages in thread
From: Felipe Balbi @ 2013-04-05 14:29 UTC (permalink / raw)
To: Nishanth Menon
Cc: khilman, Felipe Balbi, tony, Santosh Shilimkar, linux-omap,
linux-arm-kernel
[-- Attachment #1.1: Type: text/plain, Size: 1921 bytes --]
On Fri, Apr 05, 2013 at 09:18:02AM -0500, Nishanth Menon wrote:
> On 17:04-20130405, Felipe Balbi wrote:
> > Hi,
> >
> > On Fri, Apr 05, 2013 at 08:35:11AM -0500, Nishanth Menon wrote:
> > > On 16:19-20130405, Felipe Balbi wrote:
> > > > On Fri, Apr 05, 2013 at 06:29:00PM +0530, Santosh Shilimkar wrote:
> > > > > OMAP5 and future OMAP based SOCs has backward compatible MPUSS
> > > > > IP block with OMAP4. It's programming model is mostly similar.
> > > >
> > > > s/It's/Its/
> > > > s/mostly //
> > > >
> > > > (similar already expands to 'almost the same' :-)
> > > >
> > > > > @@ -355,6 +389,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;
> > > > > + }
> > > >
> > > > why don't you just rename omap4_* into omap_* and add cpu-based checks
> > > > there in order to handle differences between omap4 and omap5?
> > > >
> > > > If implementation will be almost the same for both, you might be able to
> > > > save on some more duplication, no ?
> > > Jeez NO! finish_suspend is assembly, further, it is the hottest path in
> > > cpuidle framework - for every WFI we invoke it. we definitely dont want
> > > to add more overhead beyond what is necessary.
> >
> > alright, settle down ;-) whoever suggested that isn't here anymore
> hehe, Apologies, I was'nt that stressed as the wording might have
> indicated.. We spend tons of time evaluating with Lauterbach tracing to
> weed out hot paths - folks who have been bitten by these tend to feel a
> little defensive I guess and to have surprise regressions are painful to
> find and fix - esp when around not-so-obvious paths ;)
understood ;-)
--
balbi
[-- Attachment #1.2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
[-- Attachment #2: Type: text/plain, Size: 176 bytes --]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 46+ messages in thread
* [PATCH v3 1/4] ARM: OMAP4+: PM: Consolidate MPU subsystem PM code for re-use
@ 2013-04-05 14:29 ` Felipe Balbi
0 siblings, 0 replies; 46+ messages in thread
From: Felipe Balbi @ 2013-04-05 14:29 UTC (permalink / raw)
To: linux-arm-kernel
On Fri, Apr 05, 2013 at 09:18:02AM -0500, Nishanth Menon wrote:
> On 17:04-20130405, Felipe Balbi wrote:
> > Hi,
> >
> > On Fri, Apr 05, 2013 at 08:35:11AM -0500, Nishanth Menon wrote:
> > > On 16:19-20130405, Felipe Balbi wrote:
> > > > On Fri, Apr 05, 2013 at 06:29:00PM +0530, Santosh Shilimkar wrote:
> > > > > OMAP5 and future OMAP based SOCs has backward compatible MPUSS
> > > > > IP block with OMAP4. It's programming model is mostly similar.
> > > >
> > > > s/It's/Its/
> > > > s/mostly //
> > > >
> > > > (similar already expands to 'almost the same' :-)
> > > >
> > > > > @@ -355,6 +389,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;
> > > > > + }
> > > >
> > > > why don't you just rename omap4_* into omap_* and add cpu-based checks
> > > > there in order to handle differences between omap4 and omap5?
> > > >
> > > > If implementation will be almost the same for both, you might be able to
> > > > save on some more duplication, no ?
> > > Jeez NO! finish_suspend is assembly, further, it is the hottest path in
> > > cpuidle framework - for every WFI we invoke it. we definitely dont want
> > > to add more overhead beyond what is necessary.
> >
> > alright, settle down ;-) whoever suggested that isn't here anymore
> hehe, Apologies, I was'nt that stressed as the wording might have
> indicated.. We spend tons of time evaluating with Lauterbach tracing to
> weed out hot paths - folks who have been bitten by these tend to feel a
> little defensive I guess and to have surprise regressions are painful to
> find and fix - esp when around not-so-obvious paths ;)
understood ;-)
--
balbi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130405/a00aa6ff/attachment.sig>
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: [PATCH v3 4/4] ARM: OMAP4+: CPUidle: Consolidate idle driver for OMAP5 support
2013-04-05 12:59 ` Santosh Shilimkar
@ 2013-04-05 21:29 ` Kevin Hilman
-1 siblings, 0 replies; 46+ messages in thread
From: Kevin Hilman @ 2013-04-05 21:29 UTC (permalink / raw)
To: Santosh Shilimkar; +Cc: tony, linux-omap, 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>
Due to dependencies, I'll add this one to my for_3.10/cleanup/cpuidle
branch.
Kevin
> ---
> 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 767f657..ca1551a 100644
> --- a/arch/arm/mach-omap2/cpuidle44xx.c
> +++ b/arch/arm/mach-omap2/cpuidle44xx.c
> @@ -1,7 +1,7 @@
> /*
> - * OMAP4 CPU idle Routines
> + * OMAP4+ 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();
>
> /*
> @@ -168,7 +169,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",
> @@ -180,7 +181,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"
> },
> @@ -189,7 +190,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",
> },
> @@ -198,7 +199,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",
> },
> @@ -210,9 +211,9 @@ static struct cpuidle_driver omap4_idle_driver = {
> /* Public functions */
>
> /**
> - * omap4_idle_init - Init routine for OMAP4 idle
> + * omap4_idle_init - Init routine for OMAP4+ idle
> *
> - * Registers the OMAP4 specific cpuidle driver to the cpuidle
> + * Registers the OMAP4+ specific cpuidle driver to the cpuidle
> * framework with the valid set of states.
> */
> int __init omap4_idle_init(void)
> @@ -240,7 +241,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;
^ permalink raw reply [flat|nested] 46+ messages in thread
* [PATCH v3 4/4] ARM: OMAP4+: CPUidle: Consolidate idle driver for OMAP5 support
@ 2013-04-05 21:29 ` Kevin Hilman
0 siblings, 0 replies; 46+ messages in thread
From: Kevin Hilman @ 2013-04-05 21:29 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>
Due to dependencies, I'll add this one to my for_3.10/cleanup/cpuidle
branch.
Kevin
> ---
> 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 767f657..ca1551a 100644
> --- a/arch/arm/mach-omap2/cpuidle44xx.c
> +++ b/arch/arm/mach-omap2/cpuidle44xx.c
> @@ -1,7 +1,7 @@
> /*
> - * OMAP4 CPU idle Routines
> + * OMAP4+ 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();
>
> /*
> @@ -168,7 +169,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",
> @@ -180,7 +181,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"
> },
> @@ -189,7 +190,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",
> },
> @@ -198,7 +199,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",
> },
> @@ -210,9 +211,9 @@ static struct cpuidle_driver omap4_idle_driver = {
> /* Public functions */
>
> /**
> - * omap4_idle_init - Init routine for OMAP4 idle
> + * omap4_idle_init - Init routine for OMAP4+ idle
> *
> - * Registers the OMAP4 specific cpuidle driver to the cpuidle
> + * Registers the OMAP4+ specific cpuidle driver to the cpuidle
> * framework with the valid set of states.
> */
> int __init omap4_idle_init(void)
> @@ -240,7 +241,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;
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: [PATCH v3 2/4] ARM: OMAP4+: PM: Consolidate OMAP4 PM code to re-use it for OMAP5
2013-04-05 12:59 ` Santosh Shilimkar
@ 2013-04-05 21:34 ` Tony Lindgren
-1 siblings, 0 replies; 46+ messages in thread
From: Tony Lindgren @ 2013-04-05 21:34 UTC (permalink / raw)
To: Santosh Shilimkar; +Cc: khilman, linux-omap, linux-arm-kernel
* Santosh Shilimkar <santosh.shilimkar@ti.com> [130405 06:01]:
> 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.
>
> 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} | 58 ++++++++++++++++----
> .../mach-omap2/{sleep44xx.S => sleep_omap4plus.S} | 0
> 3 files changed, 53 insertions(+), 14 deletions(-)
> rename arch/arm/mach-omap2/{pm44xx.c => pm_omap4plus.c} (83%)
> rename arch/arm/mach-omap2/{sleep44xx.S => sleep_omap4plus.S} (100%)
I suggest you leave out the rename. That just adds churn and has
flame potential.
Regards,
Tony
^ permalink raw reply [flat|nested] 46+ messages in thread
* [PATCH v3 2/4] ARM: OMAP4+: PM: Consolidate OMAP4 PM code to re-use it for OMAP5
@ 2013-04-05 21:34 ` Tony Lindgren
0 siblings, 0 replies; 46+ messages in thread
From: Tony Lindgren @ 2013-04-05 21:34 UTC (permalink / raw)
To: linux-arm-kernel
* Santosh Shilimkar <santosh.shilimkar@ti.com> [130405 06:01]:
> 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.
>
> 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} | 58 ++++++++++++++++----
> .../mach-omap2/{sleep44xx.S => sleep_omap4plus.S} | 0
> 3 files changed, 53 insertions(+), 14 deletions(-)
> rename arch/arm/mach-omap2/{pm44xx.c => pm_omap4plus.c} (83%)
> rename arch/arm/mach-omap2/{sleep44xx.S => sleep_omap4plus.S} (100%)
I suggest you leave out the rename. That just adds churn and has
flame potential.
Regards,
Tony
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: [PATCH v3 0/4] ARM: OMAP4+: PM: Consolidate code for re-use on OMAP5
2013-04-05 12:58 ` Santosh Shilimkar
@ 2013-04-05 23:42 ` Kevin Hilman
-1 siblings, 0 replies; 46+ messages in thread
From: Kevin Hilman @ 2013-04-05 23:42 UTC (permalink / raw)
To: Santosh Shilimkar; +Cc: tony, linux-omap, linux-arm-kernel
Santosh Shilimkar <santosh.shilimkar@ti.com> writes:
> As discussed on list, I split the v2 [1] series into cleanup and OMAP5 support.
Thanks.
> This series contains the clean-up patches. I have rebased on top of Tony's
> pull request and your 3.10/* branches. Series is tested on OMAP4430 SDP
> with CPUIDLE and suspend. OMAP5 PM support I will post later since it has
> a dependency with OMAP5 data files which are not pulled in yet.
I've added 4/4 to my cpuidle branch and added 1,3/4 to my
for_3.10/cleanup/pm branch (now based on Tony's cleanup-v2 branch for
dependencies.) Patch 2/4 needs a respin without the rename as per
Tony's comments.
Thanks,
Kevin
^ permalink raw reply [flat|nested] 46+ messages in thread
* [PATCH v3 0/4] ARM: OMAP4+: PM: Consolidate code for re-use on OMAP5
@ 2013-04-05 23:42 ` Kevin Hilman
0 siblings, 0 replies; 46+ messages in thread
From: Kevin Hilman @ 2013-04-05 23:42 UTC (permalink / raw)
To: linux-arm-kernel
Santosh Shilimkar <santosh.shilimkar@ti.com> writes:
> As discussed on list, I split the v2 [1] series into cleanup and OMAP5 support.
Thanks.
> This series contains the clean-up patches. I have rebased on top of Tony's
> pull request and your 3.10/* branches. Series is tested on OMAP4430 SDP
> with CPUIDLE and suspend. OMAP5 PM support I will post later since it has
> a dependency with OMAP5 data files which are not pulled in yet.
I've added 4/4 to my cpuidle branch and added 1,3/4 to my
for_3.10/cleanup/pm branch (now based on Tony's cleanup-v2 branch for
dependencies.) Patch 2/4 needs a respin without the rename as per
Tony's comments.
Thanks,
Kevin
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: [PATCH v3 2/4] ARM: OMAP4+: PM: Consolidate OMAP4 PM code to re-use it for OMAP5
2013-04-05 21:34 ` Tony Lindgren
@ 2013-04-08 10:48 ` Santosh Shilimkar
-1 siblings, 0 replies; 46+ messages in thread
From: Santosh Shilimkar @ 2013-04-08 10:48 UTC (permalink / raw)
To: Tony Lindgren; +Cc: khilman, linux-omap, linux-arm-kernel
On Saturday 06 April 2013 03:04 AM, Tony Lindgren wrote:
> * Santosh Shilimkar <santosh.shilimkar@ti.com> [130405 06:01]:
>> 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.
>>
>> 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} | 58 ++++++++++++++++----
>> .../mach-omap2/{sleep44xx.S => sleep_omap4plus.S} | 0
>> 3 files changed, 53 insertions(+), 14 deletions(-)
>> rename arch/arm/mach-omap2/{pm44xx.c => pm_omap4plus.c} (83%)
>> rename arch/arm/mach-omap2/{sleep44xx.S => sleep_omap4plus.S} (100%)
>
> I suggest you leave out the rename. That just adds churn and has
> flame potential.
>
OK. I can leave that mow but have to do renames anyways when
I add OMAP5 support. OMAP54XX support inside pm44xx.c and sleep44x.S
will be really odd.
Let me know if you have concern on renaming it while OMAP5 support
gets added ?
Regards,
Santosh
^ permalink raw reply [flat|nested] 46+ messages in thread
* [PATCH v3 2/4] ARM: OMAP4+: PM: Consolidate OMAP4 PM code to re-use it for OMAP5
@ 2013-04-08 10:48 ` Santosh Shilimkar
0 siblings, 0 replies; 46+ messages in thread
From: Santosh Shilimkar @ 2013-04-08 10:48 UTC (permalink / raw)
To: linux-arm-kernel
On Saturday 06 April 2013 03:04 AM, Tony Lindgren wrote:
> * Santosh Shilimkar <santosh.shilimkar@ti.com> [130405 06:01]:
>> 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.
>>
>> 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} | 58 ++++++++++++++++----
>> .../mach-omap2/{sleep44xx.S => sleep_omap4plus.S} | 0
>> 3 files changed, 53 insertions(+), 14 deletions(-)
>> rename arch/arm/mach-omap2/{pm44xx.c => pm_omap4plus.c} (83%)
>> rename arch/arm/mach-omap2/{sleep44xx.S => sleep_omap4plus.S} (100%)
>
> I suggest you leave out the rename. That just adds churn and has
> flame potential.
>
OK. I can leave that mow but have to do renames anyways when
I add OMAP5 support. OMAP54XX support inside pm44xx.c and sleep44x.S
will be really odd.
Let me know if you have concern on renaming it while OMAP5 support
gets added ?
Regards,
Santosh
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: [PATCH v3 0/4] ARM: OMAP4+: PM: Consolidate code for re-use on OMAP5
2013-04-05 23:42 ` Kevin Hilman
@ 2013-04-08 11:03 ` Santosh Shilimkar
-1 siblings, 0 replies; 46+ messages in thread
From: Santosh Shilimkar @ 2013-04-08 11:03 UTC (permalink / raw)
To: Kevin Hilman; +Cc: linux-omap, linux-arm-kernel, tony
[-- Attachment #1: Type: text/plain, Size: 5223 bytes --]
On Saturday 06 April 2013 05:12 AM, Kevin Hilman wrote:
> Santosh Shilimkar <santosh.shilimkar@ti.com> writes:
>
>> As discussed on list, I split the v2 [1] series into cleanup and OMAP5 support.
>
> Thanks.
>
>> This series contains the clean-up patches. I have rebased on top of Tony's
>> pull request and your 3.10/* branches. Series is tested on OMAP4430 SDP
>> with CPUIDLE and suspend. OMAP5 PM support I will post later since it has
>> a dependency with OMAP5 data files which are not pulled in yet.
>
> I've added 4/4 to my cpuidle branch and added 1,3/4 to my
> for_3.10/cleanup/pm branch (now based on Tony's cleanup-v2 branch for
> dependencies.) Patch 2/4 needs a respin without the rename as per
> Tony's comments.
>
OK. Here is an updated patch against your "for_3.10/cleanup/pm"
branch. Attachment as well just in case mailer eat tabs.
Regards,
Santosh
>From 428289ddf30a6a34f7e459720e5f6bf59ce4fe63 Mon Sep 17 00:00:00 2001
From: Santosh Shilimkar <santosh.shilimkar@ti.com>
Date: Thu, 12 Apr 2012 16:51:47 +0530
Subject: [PATCH] ARM: OMAP4+: PM: Consolidate OMAP4 PM code to re-use it for
OMAP5
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.
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/pm44xx.c | 58 ++++++++++++++++++++++++++++++++++--------
1 file changed, 48 insertions(+), 10 deletions(-)
diff --git a/arch/arm/mach-omap2/pm44xx.c b/arch/arm/mach-omap2/pm44xx.c
index 5ba6d88..228deca 100644
--- a/arch/arm/mach-omap2/pm44xx.c
+++ b/arch/arm/mach-omap2/pm44xx.c
@@ -1,7 +1,7 @@
/*
- * OMAP4 Power Management Routines
+ * OMAP4+ 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;
}
/*
@@ -171,6 +171,10 @@ int __init omap4_pm_init(void)
* MPUSS -> L4_PER/L3_* and DUCATI -> L3_* doesn't work as
* expected. The hardware recommendation is to enable static
* dependencies for these to avoid system lock ups or random crashes.
+ * The L4 wakeup depedency is added to workaround the OCP sync hardware
+ * BUG with 32K synctimer which lead to incorrect timer value read
+ * from the 32K counter. The BUG applies for GPTIMER1 and WDT2 which
+ * are part of L4 wakeup clockdomain.
*/
mpuss_clkdm = clkdm_lookup("mpuss_clkdm");
emif_clkdm = clkdm_lookup("l3_emif_clkdm");
@@ -179,7 +183,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 +192,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 OMAP4+ 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 +243,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;
--
1.7.9.5
[-- Attachment #2: 0001-ARM-OMAP4-PM-Consolidate-OMAP4-PM-code-to-re-use-it-.patch --]
[-- Type: text/x-patch, Size: 4344 bytes --]
>From 428289ddf30a6a34f7e459720e5f6bf59ce4fe63 Mon Sep 17 00:00:00 2001
From: Santosh Shilimkar <santosh.shilimkar@ti.com>
Date: Thu, 12 Apr 2012 16:51:47 +0530
Subject: [PATCH] ARM: OMAP4+: PM: Consolidate OMAP4 PM code to re-use it for
OMAP5
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.
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/pm44xx.c | 58 ++++++++++++++++++++++++++++++++++--------
1 file changed, 48 insertions(+), 10 deletions(-)
diff --git a/arch/arm/mach-omap2/pm44xx.c b/arch/arm/mach-omap2/pm44xx.c
index 5ba6d88..228deca 100644
--- a/arch/arm/mach-omap2/pm44xx.c
+++ b/arch/arm/mach-omap2/pm44xx.c
@@ -1,7 +1,7 @@
/*
- * OMAP4 Power Management Routines
+ * OMAP4+ 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;
}
/*
@@ -171,6 +171,10 @@ int __init omap4_pm_init(void)
* MPUSS -> L4_PER/L3_* and DUCATI -> L3_* doesn't work as
* expected. The hardware recommendation is to enable static
* dependencies for these to avoid system lock ups or random crashes.
+ * The L4 wakeup depedency is added to workaround the OCP sync hardware
+ * BUG with 32K synctimer which lead to incorrect timer value read
+ * from the 32K counter. The BUG applies for GPTIMER1 and WDT2 which
+ * are part of L4 wakeup clockdomain.
*/
mpuss_clkdm = clkdm_lookup("mpuss_clkdm");
emif_clkdm = clkdm_lookup("l3_emif_clkdm");
@@ -179,7 +183,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 +192,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 OMAP4+ 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 +243,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;
--
1.7.9.5
^ permalink raw reply related [flat|nested] 46+ messages in thread
* [PATCH v3 0/4] ARM: OMAP4+: PM: Consolidate code for re-use on OMAP5
@ 2013-04-08 11:03 ` Santosh Shilimkar
0 siblings, 0 replies; 46+ messages in thread
From: Santosh Shilimkar @ 2013-04-08 11:03 UTC (permalink / raw)
To: linux-arm-kernel
On Saturday 06 April 2013 05:12 AM, Kevin Hilman wrote:
> Santosh Shilimkar <santosh.shilimkar@ti.com> writes:
>
>> As discussed on list, I split the v2 [1] series into cleanup and OMAP5 support.
>
> Thanks.
>
>> This series contains the clean-up patches. I have rebased on top of Tony's
>> pull request and your 3.10/* branches. Series is tested on OMAP4430 SDP
>> with CPUIDLE and suspend. OMAP5 PM support I will post later since it has
>> a dependency with OMAP5 data files which are not pulled in yet.
>
> I've added 4/4 to my cpuidle branch and added 1,3/4 to my
> for_3.10/cleanup/pm branch (now based on Tony's cleanup-v2 branch for
> dependencies.) Patch 2/4 needs a respin without the rename as per
> Tony's comments.
>
OK. Here is an updated patch against your "for_3.10/cleanup/pm"
branch. Attachment as well just in case mailer eat tabs.
Regards,
Santosh
>From 428289ddf30a6a34f7e459720e5f6bf59ce4fe63 Mon Sep 17 00:00:00 2001
From: Santosh Shilimkar <santosh.shilimkar@ti.com>
Date: Thu, 12 Apr 2012 16:51:47 +0530
Subject: [PATCH] ARM: OMAP4+: PM: Consolidate OMAP4 PM code to re-use it for
OMAP5
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.
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/pm44xx.c | 58 ++++++++++++++++++++++++++++++++++--------
1 file changed, 48 insertions(+), 10 deletions(-)
diff --git a/arch/arm/mach-omap2/pm44xx.c b/arch/arm/mach-omap2/pm44xx.c
index 5ba6d88..228deca 100644
--- a/arch/arm/mach-omap2/pm44xx.c
+++ b/arch/arm/mach-omap2/pm44xx.c
@@ -1,7 +1,7 @@
/*
- * OMAP4 Power Management Routines
+ * OMAP4+ 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;
}
/*
@@ -171,6 +171,10 @@ int __init omap4_pm_init(void)
* MPUSS -> L4_PER/L3_* and DUCATI -> L3_* doesn't work as
* expected. The hardware recommendation is to enable static
* dependencies for these to avoid system lock ups or random crashes.
+ * The L4 wakeup depedency is added to workaround the OCP sync hardware
+ * BUG with 32K synctimer which lead to incorrect timer value read
+ * from the 32K counter. The BUG applies for GPTIMER1 and WDT2 which
+ * are part of L4 wakeup clockdomain.
*/
mpuss_clkdm = clkdm_lookup("mpuss_clkdm");
emif_clkdm = clkdm_lookup("l3_emif_clkdm");
@@ -179,7 +183,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 +192,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 OMAP4+ 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 +243,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;
--
1.7.9.5
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-ARM-OMAP4-PM-Consolidate-OMAP4-PM-code-to-re-use-it-.patch
Type: text/x-patch
Size: 4344 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130408/ab185ebf/attachment.bin>
^ permalink raw reply related [flat|nested] 46+ messages in thread
* Re: [PATCH v3 2/4] ARM: OMAP4+: PM: Consolidate OMAP4 PM code to re-use it for OMAP5
2013-04-08 10:48 ` Santosh Shilimkar
@ 2013-04-08 16:42 ` Tony Lindgren
-1 siblings, 0 replies; 46+ messages in thread
From: Tony Lindgren @ 2013-04-08 16:42 UTC (permalink / raw)
To: Santosh Shilimkar; +Cc: khilman, linux-omap, linux-arm-kernel
* Santosh Shilimkar <santosh.shilimkar@ti.com> [130408 03:51]:
> On Saturday 06 April 2013 03:04 AM, Tony Lindgren wrote:
> > * Santosh Shilimkar <santosh.shilimkar@ti.com> [130405 06:01]:
> >> 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.
> >>
> >> 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} | 58 ++++++++++++++++----
> >> .../mach-omap2/{sleep44xx.S => sleep_omap4plus.S} | 0
> >> 3 files changed, 53 insertions(+), 14 deletions(-)
> >> rename arch/arm/mach-omap2/{pm44xx.c => pm_omap4plus.c} (83%)
> >> rename arch/arm/mach-omap2/{sleep44xx.S => sleep_omap4plus.S} (100%)
> >
> > I suggest you leave out the rename. That just adds churn and has
> > flame potential.
> >
> OK. I can leave that mow but have to do renames anyways when
> I add OMAP5 support. OMAP54XX support inside pm44xx.c and sleep44x.S
> will be really odd.
Well that should be just fine if the hardware is the same.
> Let me know if you have concern on renaming it while OMAP5 support
> gets added ?
If the rename is done, it should have a clear reason to do it in
a separate patch. IMHO it's just fine to have omap4 in some name and
then assume that at least some follow up SoCs also use that code.
In the worst case we may end up renaming things many times:
omap-xyz.c -> omap2-xyz.c -> omap2plus-xyz.c -> omap2-to-4-xyz.c ->
omap2-to-4-and-am35xx-xyz.c etc :)
If we rename something, the description should have a clear reason
for doing it like "To avoid confusing between PM code that does not
have support for bootrom assisted off-idle on SMP omaps with PM code
that's not bootrom assisted, let's rename foo to.."
For the naming, the only safe naming convention is to use something
actually describing the piece of hardware. Maybe some combination
of bootrom-assisted-off-idle + SMP in this case if there's no actual
name for this hwblock?
Regards,
Tony
^ permalink raw reply [flat|nested] 46+ messages in thread
* [PATCH v3 2/4] ARM: OMAP4+: PM: Consolidate OMAP4 PM code to re-use it for OMAP5
@ 2013-04-08 16:42 ` Tony Lindgren
0 siblings, 0 replies; 46+ messages in thread
From: Tony Lindgren @ 2013-04-08 16:42 UTC (permalink / raw)
To: linux-arm-kernel
* Santosh Shilimkar <santosh.shilimkar@ti.com> [130408 03:51]:
> On Saturday 06 April 2013 03:04 AM, Tony Lindgren wrote:
> > * Santosh Shilimkar <santosh.shilimkar@ti.com> [130405 06:01]:
> >> 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.
> >>
> >> 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} | 58 ++++++++++++++++----
> >> .../mach-omap2/{sleep44xx.S => sleep_omap4plus.S} | 0
> >> 3 files changed, 53 insertions(+), 14 deletions(-)
> >> rename arch/arm/mach-omap2/{pm44xx.c => pm_omap4plus.c} (83%)
> >> rename arch/arm/mach-omap2/{sleep44xx.S => sleep_omap4plus.S} (100%)
> >
> > I suggest you leave out the rename. That just adds churn and has
> > flame potential.
> >
> OK. I can leave that mow but have to do renames anyways when
> I add OMAP5 support. OMAP54XX support inside pm44xx.c and sleep44x.S
> will be really odd.
Well that should be just fine if the hardware is the same.
> Let me know if you have concern on renaming it while OMAP5 support
> gets added ?
If the rename is done, it should have a clear reason to do it in
a separate patch. IMHO it's just fine to have omap4 in some name and
then assume that at least some follow up SoCs also use that code.
In the worst case we may end up renaming things many times:
omap-xyz.c -> omap2-xyz.c -> omap2plus-xyz.c -> omap2-to-4-xyz.c ->
omap2-to-4-and-am35xx-xyz.c etc :)
If we rename something, the description should have a clear reason
for doing it like "To avoid confusing between PM code that does not
have support for bootrom assisted off-idle on SMP omaps with PM code
that's not bootrom assisted, let's rename foo to.."
For the naming, the only safe naming convention is to use something
actually describing the piece of hardware. Maybe some combination
of bootrom-assisted-off-idle + SMP in this case if there's no actual
name for this hwblock?
Regards,
Tony
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: [PATCH v3 2/4] ARM: OMAP4+: PM: Consolidate OMAP4 PM code to re-use it for OMAP5
2013-04-08 16:42 ` Tony Lindgren
@ 2013-04-09 6:13 ` Santosh Shilimkar
-1 siblings, 0 replies; 46+ messages in thread
From: Santosh Shilimkar @ 2013-04-09 6:13 UTC (permalink / raw)
To: Tony Lindgren; +Cc: khilman, linux-omap, linux-arm-kernel
On Monday 08 April 2013 10:12 PM, Tony Lindgren wrote:
> * Santosh Shilimkar <santosh.shilimkar@ti.com> [130408 03:51]:
>> On Saturday 06 April 2013 03:04 AM, Tony Lindgren wrote:
>>> * Santosh Shilimkar <santosh.shilimkar@ti.com> [130405 06:01]:
>>>> 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.
>>>>
>>>> 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} | 58 ++++++++++++++++----
>>>> .../mach-omap2/{sleep44xx.S => sleep_omap4plus.S} | 0
>>>> 3 files changed, 53 insertions(+), 14 deletions(-)
>>>> rename arch/arm/mach-omap2/{pm44xx.c => pm_omap4plus.c} (83%)
>>>> rename arch/arm/mach-omap2/{sleep44xx.S => sleep_omap4plus.S} (100%)
>>>
>>> I suggest you leave out the rename. That just adds churn and has
>>> flame potential.
>>>
>> OK. I can leave that mow but have to do renames anyways when
>> I add OMAP5 support. OMAP54XX support inside pm44xx.c and sleep44x.S
>> will be really odd.
>
> Well that should be just fine if the hardware is the same.
>
>> Let me know if you have concern on renaming it while OMAP5 support
>> gets added ?
>
> If the rename is done, it should have a clear reason to do it in
> a separate patch. IMHO it's just fine to have omap4 in some name and
> then assume that at least some follow up SoCs also use that code.
> In the worst case we may end up renaming things many times:
>
Agree. omap4_* is just fine and thats why many omap4_* are not renamed.
Here the files were calling specific family of OMAP4 i.e OMAP44XX and
hence the rename was appropriate.
> omap-xyz.c -> omap2-xyz.c -> omap2plus-xyz.c -> omap2-to-4-xyz.c ->
> omap2-to-4-and-am35xx-xyz.c etc :)
>
pm_omap4plus.c and sleep_omap4plus.S was chosen specifically considering
the OMAP4+ devices share the PRCM IP. But PRCM_IP itself isn't new so
calling by IP wasn't an option.
> If we rename something, the description should have a clear reason
> for doing it like "To avoid confusing between PM code that does not
> have support for bootrom assisted off-idle on SMP omaps with PM code
> that's not bootrom assisted, let's rename foo to.."
>
> For the naming, the only safe naming convention is to use something
> actually describing the piece of hardware. Maybe some combination
> of bootrom-assisted-off-idle + SMP in this case if there's no actual
> name for this hwblock?
>
As I said, the IP has been there from OMAP2XX days. Here the case that
IP version is very similar between OMAP4, OMAP5. DRA(next SOC) and its
derivatives. Hence can share most of the code. I thought this was good
enough reason considering at least 4 family of SOC's can make use
of the code.
It has nothing to do with SMP etc specifically and rather the similarity
between the PM infrastructure on the mentioned SOCs.
Let me know if you can suggested better name than what I chose ?
Regards,
Santosh
^ permalink raw reply [flat|nested] 46+ messages in thread
* [PATCH v3 2/4] ARM: OMAP4+: PM: Consolidate OMAP4 PM code to re-use it for OMAP5
@ 2013-04-09 6:13 ` Santosh Shilimkar
0 siblings, 0 replies; 46+ messages in thread
From: Santosh Shilimkar @ 2013-04-09 6:13 UTC (permalink / raw)
To: linux-arm-kernel
On Monday 08 April 2013 10:12 PM, Tony Lindgren wrote:
> * Santosh Shilimkar <santosh.shilimkar@ti.com> [130408 03:51]:
>> On Saturday 06 April 2013 03:04 AM, Tony Lindgren wrote:
>>> * Santosh Shilimkar <santosh.shilimkar@ti.com> [130405 06:01]:
>>>> 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.
>>>>
>>>> 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} | 58 ++++++++++++++++----
>>>> .../mach-omap2/{sleep44xx.S => sleep_omap4plus.S} | 0
>>>> 3 files changed, 53 insertions(+), 14 deletions(-)
>>>> rename arch/arm/mach-omap2/{pm44xx.c => pm_omap4plus.c} (83%)
>>>> rename arch/arm/mach-omap2/{sleep44xx.S => sleep_omap4plus.S} (100%)
>>>
>>> I suggest you leave out the rename. That just adds churn and has
>>> flame potential.
>>>
>> OK. I can leave that mow but have to do renames anyways when
>> I add OMAP5 support. OMAP54XX support inside pm44xx.c and sleep44x.S
>> will be really odd.
>
> Well that should be just fine if the hardware is the same.
>
>> Let me know if you have concern on renaming it while OMAP5 support
>> gets added ?
>
> If the rename is done, it should have a clear reason to do it in
> a separate patch. IMHO it's just fine to have omap4 in some name and
> then assume that at least some follow up SoCs also use that code.
> In the worst case we may end up renaming things many times:
>
Agree. omap4_* is just fine and thats why many omap4_* are not renamed.
Here the files were calling specific family of OMAP4 i.e OMAP44XX and
hence the rename was appropriate.
> omap-xyz.c -> omap2-xyz.c -> omap2plus-xyz.c -> omap2-to-4-xyz.c ->
> omap2-to-4-and-am35xx-xyz.c etc :)
>
pm_omap4plus.c and sleep_omap4plus.S was chosen specifically considering
the OMAP4+ devices share the PRCM IP. But PRCM_IP itself isn't new so
calling by IP wasn't an option.
> If we rename something, the description should have a clear reason
> for doing it like "To avoid confusing between PM code that does not
> have support for bootrom assisted off-idle on SMP omaps with PM code
> that's not bootrom assisted, let's rename foo to.."
>
> For the naming, the only safe naming convention is to use something
> actually describing the piece of hardware. Maybe some combination
> of bootrom-assisted-off-idle + SMP in this case if there's no actual
> name for this hwblock?
>
As I said, the IP has been there from OMAP2XX days. Here the case that
IP version is very similar between OMAP4, OMAP5. DRA(next SOC) and its
derivatives. Hence can share most of the code. I thought this was good
enough reason considering at least 4 family of SOC's can make use
of the code.
It has nothing to do with SMP etc specifically and rather the similarity
between the PM infrastructure on the mentioned SOCs.
Let me know if you can suggested better name than what I chose ?
Regards,
Santosh
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: [PATCH v3 2/4] ARM: OMAP4+: PM: Consolidate OMAP4 PM code to re-use it for OMAP5
2013-04-09 6:13 ` Santosh Shilimkar
@ 2013-04-09 16:55 ` Tony Lindgren
-1 siblings, 0 replies; 46+ messages in thread
From: Tony Lindgren @ 2013-04-09 16:55 UTC (permalink / raw)
To: Santosh Shilimkar; +Cc: khilman, linux-omap, linux-arm-kernel
* Santosh Shilimkar <santosh.shilimkar@ti.com> [130408 23:16]:
> >
> As I said, the IP has been there from OMAP2XX days. Here the case that
> IP version is very similar between OMAP4, OMAP5. DRA(next SOC) and its
> derivatives. Hence can share most of the code. I thought this was good
> enough reason considering at least 4 family of SOC's can make use
> of the code.
Well at least that might be enough of a reasoning to rename it as
it is somewhat futureproof.
> It has nothing to do with SMP etc specifically and rather the similarity
> between the PM infrastructure on the mentioned SOCs.
>
> Let me know if you can suggested better name than what I chose ?
Not really except something like pm-iprevXXX.[chS] where the rev is
the first revision that it works with?
But then again if it's touching registers all over the place directly,
that naming does not make much sense either :)
Regards,
Tony
^ permalink raw reply [flat|nested] 46+ messages in thread
* [PATCH v3 2/4] ARM: OMAP4+: PM: Consolidate OMAP4 PM code to re-use it for OMAP5
@ 2013-04-09 16:55 ` Tony Lindgren
0 siblings, 0 replies; 46+ messages in thread
From: Tony Lindgren @ 2013-04-09 16:55 UTC (permalink / raw)
To: linux-arm-kernel
* Santosh Shilimkar <santosh.shilimkar@ti.com> [130408 23:16]:
> >
> As I said, the IP has been there from OMAP2XX days. Here the case that
> IP version is very similar between OMAP4, OMAP5. DRA(next SOC) and its
> derivatives. Hence can share most of the code. I thought this was good
> enough reason considering at least 4 family of SOC's can make use
> of the code.
Well at least that might be enough of a reasoning to rename it as
it is somewhat futureproof.
> It has nothing to do with SMP etc specifically and rather the similarity
> between the PM infrastructure on the mentioned SOCs.
>
> Let me know if you can suggested better name than what I chose ?
Not really except something like pm-iprevXXX.[chS] where the rev is
the first revision that it works with?
But then again if it's touching registers all over the place directly,
that naming does not make much sense either :)
Regards,
Tony
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: [PATCH v3 2/4] ARM: OMAP4+: PM: Consolidate OMAP4 PM code to re-use it for OMAP5
2013-04-09 16:55 ` Tony Lindgren
@ 2013-04-10 6:17 ` Santosh Shilimkar
-1 siblings, 0 replies; 46+ messages in thread
From: Santosh Shilimkar @ 2013-04-10 6:17 UTC (permalink / raw)
To: Tony Lindgren; +Cc: khilman, linux-omap, linux-arm-kernel
On Tuesday 09 April 2013 10:25 PM, Tony Lindgren wrote:
> * Santosh Shilimkar <santosh.shilimkar@ti.com> [130408 23:16]:
>>>
>> As I said, the IP has been there from OMAP2XX days. Here the case that
>> IP version is very similar between OMAP4, OMAP5. DRA(next SOC) and its
>> derivatives. Hence can share most of the code. I thought this was good
>> enough reason considering at least 4 family of SOC's can make use
>> of the code.
>
> Well at least that might be enough of a reasoning to rename it as
> it is somewhat futureproof.
>
Yep. I can't see to much further in future but there is a *strong*
mandate to not break compatibility so hopefully we won't see too
much churn for similar IP blocks in future.
>> It has nothing to do with SMP etc specifically and rather the similarity
>> between the PM infrastructure on the mentioned SOCs.
>>
>> Let me know if you can suggested better name than what I chose ?
>
> Not really except something like pm-iprevXXX.[chS] where the rev is
> the first revision that it works with?
>
> But then again if it's touching registers all over the place directly,
> that naming does not make much sense either :)
>
Exactly. Thanks for the discussion. I will go ahead with rename
when we add OMAP5 stuff like I did in earlier patch.
i.e
pm44xx.c --> pm_omap4plus.c
sleep44xx.S --> sleep_omap4plus.S
Regrads,
Santosh
^ permalink raw reply [flat|nested] 46+ messages in thread
* [PATCH v3 2/4] ARM: OMAP4+: PM: Consolidate OMAP4 PM code to re-use it for OMAP5
@ 2013-04-10 6:17 ` Santosh Shilimkar
0 siblings, 0 replies; 46+ messages in thread
From: Santosh Shilimkar @ 2013-04-10 6:17 UTC (permalink / raw)
To: linux-arm-kernel
On Tuesday 09 April 2013 10:25 PM, Tony Lindgren wrote:
> * Santosh Shilimkar <santosh.shilimkar@ti.com> [130408 23:16]:
>>>
>> As I said, the IP has been there from OMAP2XX days. Here the case that
>> IP version is very similar between OMAP4, OMAP5. DRA(next SOC) and its
>> derivatives. Hence can share most of the code. I thought this was good
>> enough reason considering at least 4 family of SOC's can make use
>> of the code.
>
> Well at least that might be enough of a reasoning to rename it as
> it is somewhat futureproof.
>
Yep. I can't see to much further in future but there is a *strong*
mandate to not break compatibility so hopefully we won't see too
much churn for similar IP blocks in future.
>> It has nothing to do with SMP etc specifically and rather the similarity
>> between the PM infrastructure on the mentioned SOCs.
>>
>> Let me know if you can suggested better name than what I chose ?
>
> Not really except something like pm-iprevXXX.[chS] where the rev is
> the first revision that it works with?
>
> But then again if it's touching registers all over the place directly,
> that naming does not make much sense either :)
>
Exactly. Thanks for the discussion. I will go ahead with rename
when we add OMAP5 stuff like I did in earlier patch.
i.e
pm44xx.c --> pm_omap4plus.c
sleep44xx.S --> sleep_omap4plus.S
Regrads,
Santosh
^ permalink raw reply [flat|nested] 46+ messages in thread
end of thread, other threads:[~2013-04-10 6:17 UTC | newest]
Thread overview: 46+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2013-04-05 12:58 [PATCH v3 0/4] ARM: OMAP4+: PM: Consolidate code for re-use on OMAP5 Santosh Shilimkar
2013-04-05 12:58 ` Santosh Shilimkar
2013-04-05 12:59 ` [PATCH v3 1/4] ARM: OMAP4+: PM: Consolidate MPU subsystem PM code for re-use Santosh Shilimkar
2013-04-05 12:59 ` Santosh Shilimkar
2013-04-05 13:19 ` Felipe Balbi
2013-04-05 13:19 ` Felipe Balbi
2013-04-05 13:35 ` Nishanth Menon
2013-04-05 13:35 ` Nishanth Menon
2013-04-05 13:39 ` Santosh Shilimkar
2013-04-05 13:39 ` Santosh Shilimkar
2013-04-05 14:04 ` Felipe Balbi
2013-04-05 14:04 ` Felipe Balbi
2013-04-05 14:18 ` Nishanth Menon
2013-04-05 14:18 ` Nishanth Menon
2013-04-05 14:29 ` Felipe Balbi
2013-04-05 14:29 ` Felipe Balbi
2013-04-05 13:37 ` Santosh Shilimkar
2013-04-05 13:37 ` Santosh Shilimkar
2013-04-05 12:59 ` [PATCH v3 2/4] ARM: OMAP4+: PM: Consolidate OMAP4 PM code to re-use it for OMAP5 Santosh Shilimkar
2013-04-05 12:59 ` Santosh Shilimkar
2013-04-05 13:21 ` Felipe Balbi
2013-04-05 13:21 ` Felipe Balbi
2013-04-05 13:35 ` Santosh Shilimkar
2013-04-05 13:35 ` Santosh Shilimkar
2013-04-05 21:34 ` Tony Lindgren
2013-04-05 21:34 ` Tony Lindgren
2013-04-08 10:48 ` Santosh Shilimkar
2013-04-08 10:48 ` Santosh Shilimkar
2013-04-08 16:42 ` Tony Lindgren
2013-04-08 16:42 ` Tony Lindgren
2013-04-09 6:13 ` Santosh Shilimkar
2013-04-09 6:13 ` Santosh Shilimkar
2013-04-09 16:55 ` Tony Lindgren
2013-04-09 16:55 ` Tony Lindgren
2013-04-10 6:17 ` Santosh Shilimkar
2013-04-10 6:17 ` Santosh Shilimkar
2013-04-05 12:59 ` [PATCH v3 3/4] ARM: OMAP4+: Make secondary_startup function name more consistent Santosh Shilimkar
2013-04-05 12:59 ` Santosh Shilimkar
2013-04-05 12:59 ` [PATCH v3 4/4] ARM: OMAP4+: CPUidle: Consolidate idle driver for OMAP5 support Santosh Shilimkar
2013-04-05 12:59 ` Santosh Shilimkar
2013-04-05 21:29 ` Kevin Hilman
2013-04-05 21:29 ` Kevin Hilman
2013-04-05 23:42 ` [PATCH v3 0/4] ARM: OMAP4+: PM: Consolidate code for re-use on OMAP5 Kevin Hilman
2013-04-05 23:42 ` Kevin Hilman
2013-04-08 11:03 ` Santosh Shilimkar
2013-04-08 11:03 ` Santosh Shilimkar
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.