Re: [PATCH 0/8] OMAP3/4: Misc fixes and clean-up
Paul, On Thursday 08 September 2011 10:51 AM, Santosh Shilimkar wrote: The series contains few fixes and clean-up for OMAP. Briefly, - HWMOD fix for the address space count - Improving the L3 register accesses - Bug fix in the L3 error handler - Sparce warning and indentation fixes in L3 error handler - Print master id in case of L3 custom errors for better debug. - Adding local time clock node for the CPUfreq and time re-calibration - Fix in the address overlap for emif and emulation domain. The series is tested on OMAP4430 SDP and OMAP4430 beagle and SDP. The following changes since commit c6a389f123b9f68d605bb7e0f9b32ec1e3e14132: Linux 3.1-rc4 (2011-08-28 21:16:01 -0700) are available in the git repository at: git://gitorious.org/omap-sw-develoment/linux-omap-dev.git v3.1-rc4-omap-misc I need your ack on below two patches so that I can re-base them and send a pull request to Tony. OMAP4: clock: Add CPU local timer clock node. OMAP: Fix sparse warnings in l3 error handler. Regards Santosh -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 00/24 V2] OMAP4: PM: suspend, CPU-hotplug and CPUilde support
The series adds OMAP4 MPUSS (MPU SubSystem) power management support for
suspend (S2R), CPU hotplug and CPUidle.
This is a repost with minor changelog updates, re-basing against 3.1-rc6,
adding reiwed-by/tested-by etc and re-ordering of errata patch.
The main change is the errata i688 is cleanly separated and kept as
last patch in the series as per Tony's suggestion.
Now Russell's L2 suspend series is merged in his for-next branch and CPU
PM notifiers series pull request is out, most of the dependencies are taken
care. The irq/core patch is also in Thomas's 3.2 queue.
An integrated branch with these branches merged can be found here [1].
The series is tested on OMAP4430 SDP for suspend, hotplug and CPUidle
with OMAP4 GP and HS (secure) devices.
The following changes since commit b6fd41e29dea9c6753b1843a77e50433e6123bcb:
Linux 3.1-rc6 (2011-09-12 14:02:02 -0700)
are available in the git repository at:
git://gitorious.org/omap-sw-develoment/linux-omap-dev.git
for_3_2/omap4-mpuss-pm
Santosh Shilimkar (24):
OMAP4: Use WARN_ON() instead of BUG_ON() with graceful exit
OMAP4: Export omap4_get_base*() rather than global address pointers
OMAP4: PM: Add SAR RAM support
OMAP4: PM: Keep static dep between MPUSS-EMIF and MPUSS-L3/L4 and
DUCATI-L3
OMAP4: PM: Avoid omap4_pm_init() on OMAP4430 ES1.0
OMAP4: PM: Initialise all the clockdomains to supported states
OMAP: Add Secure HAL and monitor mode API infrastructure.
OMAP: PM: Add support to allocate the memory for secure RAM
OMAP4: PM: Add WakeupGen module as OMAP gic_arch_extn
OMAP4: PM: Add CPUX OFF mode support
OMAP4: Remove __INIT from omap_secondary_startup() to re-use it for
hotplug.
OMAP4: PM: Program CPU1 to hit OFF when off-lined
OMAP4: PM: CPU1 wakeup workaround from Low power modes
OMAP4: PM: Use custom omap_do_wfi() for default idle.
OMAP4: suspend: Add MPUSS power domain RETENTION support
OMAP4: Remove un-used do_wfi() macro.
OMAP4: PM: Add WakeupGen and secure GIC low power support
OMAP4: PM: Add L2X0 cache lowpower support
OMAP4: PM: Add MPUSS power domain OSWR support
OMAP4: PM: Add power domain statistics support
OMAP4: PM: Add CPUidle support
OMAP4: cpuidle: Switch to gptimer from twd in deeper C-states.
OMAP3: CPUidle: Make use of CPU PM notifiers
OMAP4: Fix errata i688 with MPU interconnect barriers.
arch/arm/mach-omap2/Kconfig| 21 +
arch/arm/mach-omap2/Makefile | 16 +-
arch/arm/mach-omap2/cpuidle34xx.c | 15 +
arch/arm/mach-omap2/cpuidle44xx.c | 218 +++
arch/arm/mach-omap2/include/mach/barriers.h| 31 ++
arch/arm/mach-omap2/include/mach/omap-secure.h | 57 +++
arch/arm/mach-omap2/include/mach/omap-wakeupgen.h | 39 ++
arch/arm/mach-omap2/include/mach/omap4-common.h| 71 +++-
arch/arm/mach-omap2/omap-headsmp.S |5 -
arch/arm/mach-omap2/omap-hotplug.c | 14 +-
arch/arm/mach-omap2/omap-mpuss-lowpower.c | 398
arch/arm/mach-omap2/omap-secure.c | 81
arch/arm/mach-omap2/{omap44xx-smc.S = omap-smc.S} | 23 ++
arch/arm/mach-omap2/omap-smp.c | 45 +++
arch/arm/mach-omap2/omap-wakeupgen.c | 387 +++
arch/arm/mach-omap2/omap4-common.c | 88 +-
arch/arm/mach-omap2/omap4-sar-layout.h | 50 +++
arch/arm/mach-omap2/pm.h |1 +
arch/arm/mach-omap2/pm44xx.c | 156 -
arch/arm/mach-omap2/sleep44xx.S| 378 +++
arch/arm/plat-omap/common.c|3 +
arch/arm/plat-omap/include/plat/omap44xx.h |1 +
arch/arm/plat-omap/sram.c | 43 ++-
23 files changed, 2091 insertions(+), 50 deletions(-)
create mode 100644 arch/arm/mach-omap2/cpuidle44xx.c
create mode 100644 arch/arm/mach-omap2/include/mach/barriers.h
create mode 100644 arch/arm/mach-omap2/include/mach/omap-secure.h
create mode 100644 arch/arm/mach-omap2/include/mach/omap-wakeupgen.h
create mode 100644 arch/arm/mach-omap2/omap-mpuss-lowpower.c
create mode 100644 arch/arm/mach-omap2/omap-secure.c
rename arch/arm/mach-omap2/{omap44xx-smc.S = omap-smc.S} (70%)
create mode 100644 arch/arm/mach-omap2/omap-wakeupgen.c
create mode 100644 arch/arm/mach-omap2/omap4-sar-layout.h
create mode 100644 arch/arm/mach-omap2/sleep44xx.S
Regards,
Santosh
[1] git://gitorious.org/omap-sw-develoment/linux-omap-dev.git
for_3_2/omap4_mpuss_pm-integrated
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 01/24] OMAP4: Use WARN_ON() instead of BUG_ON() with graceful exit
OMAP4 L2X0 initialisation code uses BUG_ON() for the ioremap() failure scenarios. Use WARN_ON() instead and allow graceful function exits. This was suggsted by Kevin Hilman khil...@ti.com during OMAP4 PM code review. Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com Acked-by: Jean Pihet j-pi...@ti.com Reviewed-by: Kevin Hilman khil...@ti.com Tested-by: Vishwanath BS vishwanath...@ti.com --- arch/arm/mach-omap2/omap4-common.c |3 ++- 1 files changed, 2 insertions(+), 1 deletions(-) diff --git a/arch/arm/mach-omap2/omap4-common.c b/arch/arm/mach-omap2/omap4-common.c index 35ac3e5..a6c33e4 100644 --- a/arch/arm/mach-omap2/omap4-common.c +++ b/arch/arm/mach-omap2/omap4-common.c @@ -71,7 +71,8 @@ static int __init omap_l2_cache_init(void) /* Static mapping, never released */ l2cache_base = ioremap(OMAP44XX_L2CACHE_BASE, SZ_4K); - BUG_ON(!l2cache_base); + if (WARN_ON(!l2cache_base)) + return -ENOMEM; /* * 16-way associativity, parity disabled -- 1.7.4.1 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 03/24] OMAP4: PM: Add SAR RAM support
This patch adds SAR RAM support on OMAP4430. SAR RAM used to save
and restore the HW context in low power modes.
Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
Acked-by: Jean Pihet j-pi...@ti.com
Reviewed-by: Kevin Hilman khil...@ti.com
Tested-by: Vishwanath BS vishwanath...@ti.com
---
arch/arm/mach-omap2/include/mach/omap4-common.h |1 +
arch/arm/mach-omap2/omap4-common.c | 31 +++
arch/arm/mach-omap2/omap4-sar-layout.h | 22
arch/arm/plat-omap/include/plat/omap44xx.h |1 +
4 files changed, 55 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/mach-omap2/omap4-sar-layout.h
diff --git a/arch/arm/mach-omap2/include/mach/omap4-common.h
b/arch/arm/mach-omap2/include/mach/omap4-common.h
index b28ad10..947d0c8 100644
--- a/arch/arm/mach-omap2/include/mach/omap4-common.h
+++ b/arch/arm/mach-omap2/include/mach/omap4-common.h
@@ -39,6 +39,7 @@ static inline void __iomem *omap4_get_scu_base(void)
extern void __init gic_init_irq(void);
extern void omap_smc1(u32 fn, u32 arg);
+extern void __iomem *omap4_get_sar_ram_base(void);
#ifdef CONFIG_SMP
/* Needed for secondary core boot */
diff --git a/arch/arm/mach-omap2/omap4-common.c
b/arch/arm/mach-omap2/omap4-common.c
index a12896a..652e319 100644
--- a/arch/arm/mach-omap2/omap4-common.c
+++ b/arch/arm/mach-omap2/omap4-common.c
@@ -24,12 +24,16 @@
#include mach/hardware.h
#include mach/omap4-common.h
+#include omap4-sar-layout.h
+
#ifdef CONFIG_CACHE_L2X0
static void __iomem *l2cache_base;
#endif
void __iomem *gic_dist_base_addr;
+static void __iomem *sar_ram_base;
+
void __init gic_init_irq(void)
{
@@ -117,3 +121,30 @@ static int __init omap_l2_cache_init(void)
}
early_initcall(omap_l2_cache_init);
#endif
+
+void __iomem *omap4_get_sar_ram_base(void)
+{
+ return sar_ram_base;
+}
+
+/*
+ * SAR RAM used to save and restore the HW
+ * context in low power modes
+ */
+static int __init omap4_sar_ram_init(void)
+{
+ /*
+* To avoid code running on other OMAPs in
+* multi-omap builds
+*/
+ if (!cpu_is_omap44xx())
+ return -ENOMEM;
+
+ /* Static mapping, never released */
+ sar_ram_base = ioremap(OMAP44XX_SAR_RAM_BASE, SZ_8K);
+ if (WARN_ON(!sar_ram_base))
+ return -ENOMEM;
+
+ return 0;
+}
+early_initcall(omap4_sar_ram_init);
diff --git a/arch/arm/mach-omap2/omap4-sar-layout.h
b/arch/arm/mach-omap2/omap4-sar-layout.h
new file mode 100644
index 000..7781ea4
--- /dev/null
+++ b/arch/arm/mach-omap2/omap4-sar-layout.h
@@ -0,0 +1,22 @@
+/*
+ * omap4-sar-layout.h: OMAP4 SAR RAM layout header file
+ *
+ * Copyright (C) 2011 Texas Instruments, Inc.
+ * Santosh Shilimkar santosh.shilim...@ti.com
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+#ifndef OMAP_ARCH_OMAP4_SAR_LAYOUT_H
+#define OMAP_ARCH_OMAP4_SAR_LAYOUT_H
+
+/*
+ * SAR BANK offsets from base address OMAP44XX_SAR_RAM_BASE
+ */
+#define SAR_BANK1_OFFSET 0x
+#define SAR_BANK2_OFFSET 0x1000
+#define SAR_BANK3_OFFSET 0x2000
+#define SAR_BANK4_OFFSET 0x3000
+
+#endif
diff --git a/arch/arm/plat-omap/include/plat/omap44xx.h
b/arch/arm/plat-omap/include/plat/omap44xx.h
index ea2b8a6..c0d478e 100644
--- a/arch/arm/plat-omap/include/plat/omap44xx.h
+++ b/arch/arm/plat-omap/include/plat/omap44xx.h
@@ -45,6 +45,7 @@
#define OMAP44XX_WKUPGEN_BASE 0x48281000
#define OMAP44XX_MCPDM_BASE0x40132000
#define OMAP44XX_MCPDM_L3_BASE 0x49032000
+#define OMAP44XX_SAR_RAM_BASE 0x4a326000
#define OMAP44XX_MAILBOX_BASE (L4_44XX_BASE + 0xF4000)
#define OMAP44XX_HSUSB_OTG_BASE(L4_44XX_BASE + 0xAB000)
--
1.7.4.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 02/24] OMAP4: Export omap4_get_base*() rather than global address pointers
This patch exports APIs to get base address for GIC
distributor, CPU interface, SCU and PL310 L2 Cache which
are used in OMAP4 PM code.
This was suggested by Kevin Hilman khil...@ti.com during
OMAP4 PM code review.
Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
Acked-by: Jean Pihet j-pi...@ti.com
Reviewed-by: Kevin Hilman khil...@ti.com
Tested-by: Vishwanath BS vishwanath...@ti.com
---
arch/arm/mach-omap2/include/mach/omap4-common.h | 11 +--
arch/arm/mach-omap2/omap-smp.c |5 +
arch/arm/mach-omap2/omap4-common.c |7 ++-
3 files changed, 20 insertions(+), 3 deletions(-)
diff --git a/arch/arm/mach-omap2/include/mach/omap4-common.h
b/arch/arm/mach-omap2/include/mach/omap4-common.h
index e4bd87619..b28ad10 100644
--- a/arch/arm/mach-omap2/include/mach/omap4-common.h
+++ b/arch/arm/mach-omap2/include/mach/omap4-common.h
@@ -25,10 +25,17 @@
#endif
#ifdef CONFIG_CACHE_L2X0
-extern void __iomem *l2cache_base;
+extern void __iomem *omap4_get_l2cache_base(void);
#endif
-extern void __iomem *gic_dist_base_addr;
+#ifdef CONFIG_SMP
+extern void __iomem *omap4_get_scu_base(void);
+#else
+static inline void __iomem *omap4_get_scu_base(void)
+{
+ return NULL;
+}
+#endif
extern void __init gic_init_irq(void);
extern void omap_smc1(u32 fn, u32 arg);
diff --git a/arch/arm/mach-omap2/omap-smp.c b/arch/arm/mach-omap2/omap-smp.c
index ce65e93..8e9b491 100644
--- a/arch/arm/mach-omap2/omap-smp.c
+++ b/arch/arm/mach-omap2/omap-smp.c
@@ -31,6 +31,11 @@ static void __iomem *scu_base;
static DEFINE_SPINLOCK(boot_lock);
+void __iomem *omap4_get_scu_base(void)
+{
+ return scu_base;
+}
+
void __cpuinit platform_secondary_init(unsigned int cpu)
{
/*
diff --git a/arch/arm/mach-omap2/omap4-common.c
b/arch/arm/mach-omap2/omap4-common.c
index a6c33e4..a12896a 100644
--- a/arch/arm/mach-omap2/omap4-common.c
+++ b/arch/arm/mach-omap2/omap4-common.c
@@ -25,7 +25,7 @@
#include mach/omap4-common.h
#ifdef CONFIG_CACHE_L2X0
-void __iomem *l2cache_base;
+static void __iomem *l2cache_base;
#endif
void __iomem *gic_dist_base_addr;
@@ -46,6 +46,11 @@ void __init gic_init_irq(void)
#ifdef CONFIG_CACHE_L2X0
+void __iomem *omap4_get_l2cache_base(void)
+{
+ return l2cache_base;
+}
+
static void omap4_l2x0_disable(void)
{
/* Disable PL310 L2 Cache controller */
--
1.7.4.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 05/24] OMAP4: PM: Avoid omap4_pm_init() on OMAP4430 ES1.0
On OMAP4430 ES1.0, Power Management features are not supported.
Avoid omap4_pm_init() on ES1.0 silicon so that we can continue
to use same kernel binary to boot on all OMAP4 silicons.
The ES1.0 boot failure with OMAP4 PM series was because of
the clockdomain initialisation code. Hardware supervised
clockdomain mode isn't functional for all clockdomains
on OMAP4430 ES1.0 silicon so avoid the same.
Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
Reported-by: Kevin Hilman khil...@ti.com
Acked-by: Jean Pihet j-pi...@ti.com
Reviewed-by: Kevin Hilman khil...@ti.com
Tested-by: Vishwanath BS vishwanath...@ti.com
---
arch/arm/mach-omap2/pm44xx.c |5 +
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/pm44xx.c b/arch/arm/mach-omap2/pm44xx.c
index 348ebf1..44761bb 100644
--- a/arch/arm/mach-omap2/pm44xx.c
+++ b/arch/arm/mach-omap2/pm44xx.c
@@ -105,6 +105,11 @@ static int __init omap4_pm_init(void)
if (!cpu_is_omap44xx())
return -ENODEV;
+ if (omap_rev() == OMAP4430_REV_ES1_0) {
+ WARN(1, Power Management not supported on OMAP4430 ES1.0\n);
+ return -ENODEV;
+ }
+
pr_err(Power Management for TI OMAP4.\n);
ret = pwrdm_for_each(pwrdms_setup, NULL);
--
1.7.4.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 04/24] OMAP4: PM: Keep static dep between MPUSS-EMIF and MPUSS-L3/L4 and DUCATI-L3
As per OMAP4430 TRM, the dynamic dependency between MPUSS - EMIF
and MPUSS - L4PER/L3_* and DUCATI - L3_* clockdomains is enable
by default. Refer register CM_MPU_DYNAMICDEP description for details.
But these dynamic dependencies doesn't work as expected. The hardware
recommendation is to enable static dependencies for above clockdomains.
Without this, system locks up or randomly crashes.
Signed-off-by: Rajendra Nayak rna...@ti.com
Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
Acked-by: Paul Walmsley p...@pwsan.com
Acked-by: Jean Pihet j-pi...@ti.com
Reviewed-by: Kevin Hilman khil...@ti.com
Tested-by: Vishwanath BS vishwanath...@ti.com
---
arch/arm/mach-omap2/pm44xx.c | 30 ++
1 files changed, 30 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/pm44xx.c b/arch/arm/mach-omap2/pm44xx.c
index 59a870b..348ebf1 100644
--- a/arch/arm/mach-omap2/pm44xx.c
+++ b/arch/arm/mach-omap2/pm44xx.c
@@ -99,6 +99,8 @@ static int __init pwrdms_setup(struct powerdomain *pwrdm,
void *unused)
static int __init omap4_pm_init(void)
{
int ret;
+ struct clockdomain *emif_clkdm, *mpuss_clkdm, *l3_1_clkdm;
+ struct clockdomain *ducati_clkdm, *l3_2_clkdm, *l4_per_clkdm;
if (!cpu_is_omap44xx())
return -ENODEV;
@@ -111,6 +113,34 @@ static int __init omap4_pm_init(void)
goto err2;
}
+ /*
+* The dynamic dependency between MPUSS - MEMIF and
+* 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.
+*/
+ mpuss_clkdm = clkdm_lookup(mpuss_clkdm);
+ emif_clkdm = clkdm_lookup(l3_emif_clkdm);
+ l3_1_clkdm = clkdm_lookup(l3_1_clkdm);
+ l3_2_clkdm = clkdm_lookup(l3_2_clkdm);
+ l4_per_clkdm = clkdm_lookup(l4_per_clkdm);
+ ducati_clkdm = clkdm_lookup(ducati_clkdm);
+ if ((!mpuss_clkdm) || (!emif_clkdm) || (!l3_1_clkdm) ||
+ (!l3_2_clkdm) || (!ducati_clkdm) || (!l4_per_clkdm))
+ goto err2;
+
+ ret = clkdm_add_wkdep(mpuss_clkdm, emif_clkdm);
+ ret |= clkdm_add_wkdep(mpuss_clkdm, l3_1_clkdm);
+ ret |= clkdm_add_wkdep(mpuss_clkdm, l3_2_clkdm);
+ ret |= clkdm_add_wkdep(mpuss_clkdm, l4_per_clkdm);
+ ret |= clkdm_add_wkdep(ducati_clkdm, l3_1_clkdm);
+ 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);
+ goto err2;
+ }
+
#ifdef CONFIG_SUSPEND
suspend_set_ops(omap_pm_ops);
#endif /* CONFIG_SUSPEND */
--
1.7.4.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 06/24] OMAP4: PM: Initialise all the clockdomains to supported states
Initialise hardware supervised mode for all clockdomains if it's
supported. Initiate sleep transition for other clockdomains,
if they are not being used.
Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
Signed-off-by: Rajendra Nayak rna...@ti.com
Acked-by: Jean Pihet j-pi...@ti.com
Reviewed-by: Kevin Hilman khil...@ti.com
Tested-by: Vishwanath BS vishwanath...@ti.com
---
arch/arm/mach-omap2/pm44xx.c | 19 +++
1 files changed, 19 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/pm44xx.c b/arch/arm/mach-omap2/pm44xx.c
index 44761bb..5ec4bc6 100644
--- a/arch/arm/mach-omap2/pm44xx.c
+++ b/arch/arm/mach-omap2/pm44xx.c
@@ -17,6 +17,7 @@
#include linux/slab.h
#include powerdomain.h
+#include clockdomain.h
#include mach/omap4-common.h
struct power_state {
@@ -73,6 +74,22 @@ static const struct platform_suspend_ops omap_pm_ops = {
};
#endif /* CONFIG_SUSPEND */
+/*
+ * Enable hardware supervised mode for all clockdomains if it's
+ * supported. Initiate sleep transition for other clockdomains, if
+ * they are not used
+ */
+static int __init clkdms_setup(struct clockdomain *clkdm, void *unused)
+{
+ if (clkdm-flags CLKDM_CAN_ENABLE_AUTO)
+ clkdm_allow_idle(clkdm);
+ else if (clkdm-flags CLKDM_CAN_FORCE_SLEEP
+ atomic_read(clkdm-usecount) == 0)
+ clkdm_sleep(clkdm);
+ return 0;
+}
+
+
static int __init pwrdms_setup(struct powerdomain *pwrdm, void *unused)
{
struct power_state *pwrst;
@@ -146,6 +163,8 @@ static int __init omap4_pm_init(void)
goto err2;
}
+ (void) clkdm_for_each(clkdms_setup, NULL);
+
#ifdef CONFIG_SUSPEND
suspend_set_ops(omap_pm_ops);
#endif /* CONFIG_SUSPEND */
--
1.7.4.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 08/24] OMAP: PM: Add support to allocate the memory for secure RAM
Allocate the memory to save secure ram context which needs
to be done when MPU is hitting OFF mode.
The ROM code expects a physical address to this memory
and hence use memblock APIs to reserve this memory as part
of .reserve() callback. Maximum size as per secure RAM requirements
is allocated.
Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
Acked-by: Jean Pihet j-pi...@ti.com
Reviewed-by: Kevin Hilman khil...@ti.com
Tested-by: Vishwanath BS vishwanath...@ti.com
---
arch/arm/mach-omap2/include/mach/omap-secure.h |4 +++
arch/arm/mach-omap2/omap-secure.c | 29
arch/arm/plat-omap/common.c|3 ++
3 files changed, 36 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/include/mach/omap-secure.h
b/arch/arm/mach-omap2/include/mach/omap-secure.h
index 26e7bcc..e2f95a0 100644
--- a/arch/arm/mach-omap2/include/mach/omap-secure.h
+++ b/arch/arm/mach-omap2/include/mach/omap-secure.h
@@ -26,6 +26,8 @@
#define FLAG_FIQ_ENABLE0x1
#define NO_FLAG0x0
+/* Maximum Secure memory storage size */
+#define OMAP_SECURE_RAM_STORAGE(88 * SZ_1K)
/* Secure low power HAL API index */
#define OMAP4_HAL_SAVESECURERAM_INDEX 0x1a
@@ -36,5 +38,7 @@
extern u32 omap_secure_dispatcher(u32 idx, u32 flag, u32 nargs,
u32 arg1, u32 arg2, u32 arg3, u32 arg4);
extern u32 omap_smc2(u32 id, u32 falg, u32 pargs);
+extern phys_addr_t omap_secure_ram_mempool_base(void);
+extern int omap_secure_ram_reserve_memblock(void);
#endif /* OMAP_ARCH_OMAP_SECURE_H */
diff --git a/arch/arm/mach-omap2/omap-secure.c
b/arch/arm/mach-omap2/omap-secure.c
index e5a606e..69f3c72 100644
--- a/arch/arm/mach-omap2/omap-secure.c
+++ b/arch/arm/mach-omap2/omap-secure.c
@@ -13,11 +13,14 @@
#include linux/kernel.h
#include linux/init.h
#include linux/io.h
+#include linux/memblock.h
#include asm/cacheflush.h
#include mach/omap-secure.h
+static phys_addr_t omap_secure_memblock_base;
+
/**
* omap_sec_dispatcher: Routine to dispatch low power secure
* service routines
@@ -50,3 +53,29 @@ u32 omap_secure_dispatcher(u32 idx, u32 flag, u32 nargs, u32
arg1, u32 arg2,
return ret;
}
+
+/* Allocate the memory to save secure ram */
+int __init omap_secure_ram_reserve_memblock(void)
+{
+ phys_addr_t paddr;
+ u32 size = OMAP_SECURE_RAM_STORAGE;
+
+ size = ALIGN(size, SZ_1M);
+ paddr = memblock_alloc(size, SZ_1M);
+ if (!paddr) {
+ pr_err(%s: failed to reserve %x bytes\n,
+ __func__, size);
+ return -ENOMEM;
+ }
+ memblock_free(paddr, size);
+ memblock_remove(paddr, size);
+
+ omap_secure_memblock_base = paddr;
+
+ return 0;
+}
+
+phys_addr_t omap_secure_ram_mempool_base(void)
+{
+ return omap_secure_memblock_base;
+}
diff --git a/arch/arm/plat-omap/common.c b/arch/arm/plat-omap/common.c
index d9f10a3..827f896 100644
--- a/arch/arm/plat-omap/common.c
+++ b/arch/arm/plat-omap/common.c
@@ -21,6 +21,8 @@
#include plat/vram.h
#include plat/dsp.h
+#include mach/omap-secure.h
+
#define NO_LENGTH_CHECK 0x
@@ -65,4 +67,5 @@ void __init omap_reserve(void)
omapfb_reserve_sdram_memblock();
omap_vram_reserve_sdram_memblock();
omap_dsp_reserve_sdram_memblock();
+ omap_secure_ram_reserve_memblock();
}
--
1.7.4.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 11/24] OMAP4: Remove __INIT from omap_secondary_startup() to re-use it for hotplug.
Remove the __INIT from omap_secondary_startup() so that it can be re-used for CPU hotplug. While at this, remove the un-used AUXBOOT register reference. Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com Acked-by: Jean Pihet j-pi...@ti.com Reviewed-by: Kevin Hilman khil...@ti.com Tested-by: Vishwanath BS vishwanath...@ti.com --- arch/arm/mach-omap2/omap-headsmp.S |5 - 1 files changed, 0 insertions(+), 5 deletions(-) diff --git a/arch/arm/mach-omap2/omap-headsmp.S b/arch/arm/mach-omap2/omap-headsmp.S index 4ee6aec..b13ef7e 100644 --- a/arch/arm/mach-omap2/omap-headsmp.S +++ b/arch/arm/mach-omap2/omap-headsmp.S @@ -18,11 +18,6 @@ #include linux/linkage.h #include linux/init.h -/* Physical address needed since MMU not enabled yet on secondary core */ -#define OMAP4_AUX_CORE_BOOT1_PA0x48281804 - - __INIT - /* * OMAP4 specific entry point for secondary CPU to jump from ROM * code. This routine also provides a holding flag into which -- 1.7.4.1 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 14/24] OMAP4: PM: Use custom omap_do_wfi() for default idle.
Default arch_idle() isn't good enough for OMAP4 because of aync bridge errata
and necessity of NOPs post WFI to avoid speculative prefetch aborts.
Hence Use OMAP4 custom omap_do_wfi() hook for default idle.
Later in the series, async bridge errata work-around patch updates the
omap_do_wfi() with necessary interconnects barriers.
Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
Acked-by: Jean Pihet j-pi...@ti.com
Reviewed-by: Kevin Hilman khil...@ti.com
Tested-by: Vishwanath BS vishwanath...@ti.com
---
arch/arm/mach-omap2/pm44xx.c | 21 +
1 files changed, 21 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/pm44xx.c b/arch/arm/mach-omap2/pm44xx.c
index 3805c0c..fdba72a 100644
--- a/arch/arm/mach-omap2/pm44xx.c
+++ b/arch/arm/mach-omap2/pm44xx.c
@@ -108,6 +108,24 @@ static int __init pwrdms_setup(struct powerdomain *pwrdm,
void *unused)
}
/**
+ * omap_default_idle - OMAP4 default ilde routine.'
+ *
+ * Implements OMAP4 memory, IO ordering requirements which can't be addressed
+ * with default arch_idle() hook. Used by all CPUs with !CONFIG_CPUIDLE and
+ * by secondary CPU with CONFIG_CPUIDLE.
+ */
+static void omap_default_idle(void)
+{
+ local_irq_disable();
+ local_fiq_disable();
+
+ omap_do_wfi();
+
+ local_fiq_enable();
+ local_irq_enable();
+}
+
+/**
* omap4_pm_init - Init routine for OMAP4 PM
*
* Initializes all powerdomain and clockdomain target states
@@ -175,6 +193,9 @@ static int __init omap4_pm_init(void)
suspend_set_ops(omap_pm_ops);
#endif /* CONFIG_SUSPEND */
+ /* Overwrite the default arch_idle() */
+ pm_idle = omap_default_idle;
+
err2:
return ret;
}
--
1.7.4.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 16/24] OMAP4: Remove un-used do_wfi() macro.
With OMAP4 suspend, idle and hotplug series, we no longer need do_wfi() macro. Remove the same. Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com Acked-by: Jean Pihet j-pi...@ti.com Reviewed-by: Kevin Hilman khil...@ti.com Tested-by: Vishwanath BS vishwanath...@ti.com --- arch/arm/mach-omap2/include/mach/omap4-common.h | 10 -- 1 files changed, 0 insertions(+), 10 deletions(-) diff --git a/arch/arm/mach-omap2/include/mach/omap4-common.h b/arch/arm/mach-omap2/include/mach/omap4-common.h index ed3797c..e5db389 100644 --- a/arch/arm/mach-omap2/include/mach/omap4-common.h +++ b/arch/arm/mach-omap2/include/mach/omap4-common.h @@ -16,16 +16,6 @@ #include asm/proc-fns.h #ifndef __ASSEMBLER__ -/* - * wfi used in low power code. Directly opcode is used instead - * of instruction to avoid mulit-omap build break - */ -#ifdef CONFIG_THUMB2_KERNEL -#define do_wfi() __asm__ __volatile__ (wfi : : : memory) -#else -#define do_wfi() \ - __asm__ __volatile__ (.word0xe320f003 : : : memory) -#endif #ifdef CONFIG_CACHE_L2X0 extern void __iomem *omap4_get_l2cache_base(void); -- 1.7.4.1 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 13/24] OMAP4: PM: CPU1 wakeup workaround from Low power modes
The SGI(Software Generated Interrupts) are not wakeup capable from
low power states. This is known limitation on OMAP4 and needs to be
worked around by using software forced clockdomain wake-up. CPU0 forces
the CPU1 clockdomain to software force wakeup.
More details can be found in OMAP4430 TRM - Version J
Section :
4.3.4.2 Power States of CPU0 and CPU1
Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
Acked-by: Jean Pihet j-pi...@ti.com
Reviewed-by: Kevin Hilman khil...@ti.com
Tested-by: Vishwanath BS vishwanath...@ti.com
---
arch/arm/mach-omap2/omap-smp.c | 27 +++
1 files changed, 27 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/omap-smp.c b/arch/arm/mach-omap2/omap-smp.c
index 844ca5d..d550a44 100644
--- a/arch/arm/mach-omap2/omap-smp.c
+++ b/arch/arm/mach-omap2/omap-smp.c
@@ -27,6 +27,8 @@
#include mach/omap4-common.h
#include mach/omap-secure.h
+#include clockdomain.h
+
/* SCU base address */
static void __iomem *scu_base;
@@ -67,6 +69,8 @@ void __cpuinit platform_secondary_init(unsigned int cpu)
int __cpuinit boot_secondary(unsigned int cpu, struct task_struct *idle)
{
+ static struct clockdomain *cpu1_clkdm;
+ static bool booted;
/*
* Set synchronisation state between this boot processor
* and the secondary one
@@ -82,6 +86,29 @@ int __cpuinit boot_secondary(unsigned int cpu, struct
task_struct *idle)
omap_modify_auxcoreboot0(0x200, 0xfdff);
flush_cache_all();
smp_wmb();
+
+ if (!cpu1_clkdm)
+ cpu1_clkdm = clkdm_lookup(mpu1_clkdm);
+
+ /*
+* The SGI(Software Generated Interrupts) are not wakeup capable
+* from low power states. This is known limitation on OMAP4 and
+* needs to be worked around by using software forced clockdomain
+* wake-up. To wakeup CPU1, CPU0 forces the CPU1 clockdomain to
+* software force wakeup. The clockdomain is then put back to
+* hardware supervised mode.
+* More details can be found in OMAP4430 TRM - Version J
+* Section :
+* 4.3.4.2 Power States of CPU0 and CPU1
+*/
+ if (booted) {
+ clkdm_wakeup(cpu1_clkdm);
+ clkdm_allow_idle(cpu1_clkdm);
+ } else {
+ dsb_sev();
+ booted = true;
+ }
+
gic_raise_softirq(cpumask_of(cpu), 1);
/*
--
1.7.4.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 12/24] OMAP4: PM: Program CPU1 to hit OFF when off-lined
Program non-boot CPUs to hit lowest supported power state
when it is off-lined using cpu hotplug framework.
Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
Acked-by: Jean Pihet j-pi...@ti.com
Reviewed-by: Kevin Hilman khil...@ti.com
Tested-by: Vishwanath BS vishwanath...@ti.com
---
arch/arm/mach-omap2/include/mach/omap4-common.h |7 +
arch/arm/mach-omap2/omap-hotplug.c | 14 ++---
arch/arm/mach-omap2/omap-mpuss-lowpower.c | 32 +++
arch/arm/mach-omap2/omap-wakeupgen.c| 32 +++
4 files changed, 80 insertions(+), 5 deletions(-)
diff --git a/arch/arm/mach-omap2/include/mach/omap4-common.h
b/arch/arm/mach-omap2/include/mach/omap4-common.h
index 1f6c9ac..ed3797c 100644
--- a/arch/arm/mach-omap2/include/mach/omap4-common.h
+++ b/arch/arm/mach-omap2/include/mach/omap4-common.h
@@ -58,6 +58,7 @@ extern int omap4_mpuss_init(void);
extern int omap4_enter_lowpower(unsigned int cpu, unsigned int power_state);
extern int omap4_finish_suspend(unsigned long cpu_state);
extern void omap4_cpu_resume(void);
+extern int omap4_hotplug_cpu(unsigned int cpu, unsigned int power_state);
#else
static inline int omap4_enter_lowpower(unsigned int cpu,
unsigned int power_state)
@@ -66,6 +67,12 @@ static inline int omap4_enter_lowpower(unsigned int cpu,
return 0;
}
+static inline int omap4_hotplug_cpu(unsigned int cpu, unsigned int power_state)
+{
+ cpu_do_idle();
+ return 0;
+}
+
static inline int omap4_mpuss_init(void)
{
return 0;
diff --git a/arch/arm/mach-omap2/omap-hotplug.c
b/arch/arm/mach-omap2/omap-hotplug.c
index 4976b93..51ade8d 100644
--- a/arch/arm/mach-omap2/omap-hotplug.c
+++ b/arch/arm/mach-omap2/omap-hotplug.c
@@ -21,6 +21,8 @@
#include asm/cacheflush.h
#include mach/omap4-common.h
+#include powerdomain.h
+
int platform_cpu_kill(unsigned int cpu)
{
return 1;
@@ -32,6 +34,8 @@ int platform_cpu_kill(unsigned int cpu)
*/
void platform_cpu_die(unsigned int cpu)
{
+ unsigned int this_cpu;
+
flush_cache_all();
dsb();
@@ -39,15 +43,15 @@ void platform_cpu_die(unsigned int cpu)
* we're ready for shutdown now, so do it
*/
if (omap_modify_auxcoreboot0(0x0, 0x200) != 0x0)
- printk(KERN_CRIT Secure clear status failed\n);
+ pr_err(Secure clear status failed\n);
for (;;) {
/*
-* Execute WFI
+* Enter into low power state
*/
- do_wfi();
-
- if (omap_read_auxcoreboot0() == cpu) {
+ omap4_hotplug_cpu(cpu, PWRDM_POWER_OFF);
+ this_cpu = smp_processor_id();
+ if (omap_read_auxcoreboot0() == this_cpu) {
/*
* OK, proper wakeup, we're done
*/
diff --git a/arch/arm/mach-omap2/omap-mpuss-lowpower.c
b/arch/arm/mach-omap2/omap-mpuss-lowpower.c
index e4f11be..c0b6472 100644
--- a/arch/arm/mach-omap2/omap-mpuss-lowpower.c
+++ b/arch/arm/mach-omap2/omap-mpuss-lowpower.c
@@ -192,6 +192,38 @@ int omap4_enter_lowpower(unsigned int cpu, unsigned int
power_state)
return 0;
}
+/**
+ * omap4_hotplug_cpu: OMAP4 CPU hotplug entry
+ * @cpu : CPU ID
+ * @power_state: CPU low power state.
+ */
+int omap4_hotplug_cpu(unsigned int cpu, unsigned int power_state)
+{
+ unsigned int cpu_state = 0;
+
+ if (omap_rev() == OMAP4430_REV_ES1_0)
+ return -ENXIO;
+
+ if (power_state == PWRDM_POWER_OFF)
+ cpu_state = 1;
+
+ clear_cpu_prev_pwrst(cpu);
+ set_cpu_next_pwrst(cpu, power_state);
+ set_cpu_wakeup_addr(cpu, virt_to_phys(omap_secondary_startup));
+ scu_pwrst_prepare(cpu, power_state);
+
+ /*
+* CPU never retuns back if targetted power state is OFF mode.
+* CPU ONLINE follows normal CPU ONLINE ptah via
+* omap_secondary_startup().
+*/
+ omap4_finish_suspend(cpu_state);
+
+ set_cpu_next_pwrst(cpu, PWRDM_POWER_ON);
+ return 0;
+}
+
+
/*
* Initialise OMAP4 MPUSS
*/
diff --git a/arch/arm/mach-omap2/omap-wakeupgen.c
b/arch/arm/mach-omap2/omap-wakeupgen.c
index 22b0269..12b00e0 100644
--- a/arch/arm/mach-omap2/omap-wakeupgen.c
+++ b/arch/arm/mach-omap2/omap-wakeupgen.c
@@ -180,6 +180,36 @@ static void wakeupgen_irqmask_all(unsigned int cpu,
unsigned int set)
spin_unlock_irqrestore(wakeupgen_lock, flags);
}
+#ifdef CONFIG_HOTPLUG_CPU
+static int __cpuinit irq_cpu_hotplug_notify(struct notifier_block *self,
+unsigned long action, void *hcpu)
+{
+ unsigned int cpu = (unsigned int)hcpu;
+
+ switch (action) {
+ case CPU_ONLINE:
+ wakeupgen_irqmask_all(cpu, 0);
+ break;
+ case CPU_DEAD:
+ wakeupgen_irqmask_all(cpu, 1);
+
[PATCH v2 09/24] OMAP4: PM: Add WakeupGen module as OMAP gic_arch_extn
OMAP WakeupGen is the interrupt controller extension used along with ARM GIC to wake the CPU out from low power states on external interrupts. The WakeupGen unit is responsible for generating the wakeup event from the incoming interrupts and enable bits. It is implemented in the MPU always ON power domain. During normal operation, WakeupGen delivers the external interrupts directly to the GIC. WakeupGen specification has one restriction as per Veyron version 1.6. It is SW responsibility to program interrupt enabling/disabling coherently in the GIC and in the WakeupGen enable registers. That is, a given interrupt for a given CPU is either enable at both GIC and WakeupGen, or disable at both, but no mix. That's the reason the WakeupGen is implemented as an extension of GIC. Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com Acked-by: Jean Pihet j-pi...@ti.com Reviewed-by: Kevin Hilman khil...@ti.com Tested-by: Vishwanath BS vishwanath...@ti.com --- arch/arm/mach-omap2/Makefile |2 +- arch/arm/mach-omap2/include/mach/omap-wakeupgen.h | 39 arch/arm/mach-omap2/omap-wakeupgen.c | 226 + arch/arm/mach-omap2/omap4-common.c|3 + 4 files changed, 269 insertions(+), 1 deletions(-) create mode 100644 arch/arm/mach-omap2/include/mach/omap-wakeupgen.h create mode 100644 arch/arm/mach-omap2/omap-wakeupgen.c diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile index 663f28a..ba8249b 100644 --- a/arch/arm/mach-omap2/Makefile +++ b/arch/arm/mach-omap2/Makefile @@ -25,7 +25,7 @@ obj-$(CONFIG_TWL4030_CORE) += omap_twl.o obj-$(CONFIG_SMP) += omap-smp.o omap-headsmp.o obj-$(CONFIG_LOCAL_TIMERS) += timer-mpu.o obj-$(CONFIG_HOTPLUG_CPU) += omap-hotplug.o -obj-$(CONFIG_ARCH_OMAP4) += omap4-common.o +obj-$(CONFIG_ARCH_OMAP4) += omap4-common.o omap-wakeupgen.o plus_sec := $(call as-instr,.arch_extension sec,+sec) AFLAGS_omap-headsmp.o :=-Wa,-march=armv7-a$(plus_sec) diff --git a/arch/arm/mach-omap2/include/mach/omap-wakeupgen.h b/arch/arm/mach-omap2/include/mach/omap-wakeupgen.h new file mode 100644 index 000..d79321b --- /dev/null +++ b/arch/arm/mach-omap2/include/mach/omap-wakeupgen.h @@ -0,0 +1,39 @@ +/* + * OMAP WakeupGen header file + * + * Copyright (C) 2011 Texas Instruments, Inc. + * Santosh Shilimkar santosh.shilim...@ti.com + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License version 2 as + * published by the Free Software Foundation. + */ +#ifndef OMAP_ARCH_WAKEUPGEN_H +#define OMAP_ARCH_WAKEUPGEN_H + +#define OMAP_WKG_CONTROL_0 0x00 +#define OMAP_WKG_ENB_A_0 0x10 +#define OMAP_WKG_ENB_B_0 0x14 +#define OMAP_WKG_ENB_C_0 0x18 +#define OMAP_WKG_ENB_D_0 0x1c +#define OMAP_WKG_ENB_SECURE_A_00x20 +#define OMAP_WKG_ENB_SECURE_B_00x24 +#define OMAP_WKG_ENB_SECURE_C_00x28 +#define OMAP_WKG_ENB_SECURE_D_00x2c +#define OMAP_WKG_ENB_A_1 0x410 +#define OMAP_WKG_ENB_B_1 0x414 +#define OMAP_WKG_ENB_C_1 0x418 +#define OMAP_WKG_ENB_D_1 0x41c +#define OMAP_WKG_ENB_SECURE_A_10x420 +#define OMAP_WKG_ENB_SECURE_B_10x424 +#define OMAP_WKG_ENB_SECURE_C_10x428 +#define OMAP_WKG_ENB_SECURE_D_10x42c +#define OMAP_AUX_CORE_BOOT_0 0x800 +#define OMAP_AUX_CORE_BOOT_1 0x804 +#define OMAP_PTMSYNCREQ_MASK 0xc00 +#define OMAP_PTMSYNCREQ_EN 0xc04 +#define OMAP_TIMESTAMPCYCLELO 0xc08 +#define OMAP_TIMESTAMPCYCLEHI 0xc0c + +extern int __init omap_wakeupgen_init(void); +#endif diff --git a/arch/arm/mach-omap2/omap-wakeupgen.c b/arch/arm/mach-omap2/omap-wakeupgen.c new file mode 100644 index 000..22b0269 --- /dev/null +++ b/arch/arm/mach-omap2/omap-wakeupgen.c @@ -0,0 +1,226 @@ +/* + * OMAP WakeupGen Source file + * + * OMAP WakeupGen is the interrupt controller extension used along + * with ARM GIC to wake the CPU out from low power states on + * external interrupts. It is responsible for generating wakeup + * event from the incoming interrupts and enable bits. It is + * implemented in MPU always ON power domain. During normal operation, + * WakeupGen delivers external interrupts directly to the GIC. + * + * Copyright (C) 2011 Texas Instruments, Inc. + * Santosh Shilimkar santosh.shilim...@ti.com + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License version 2 as + * published by
[PATCH v2 17/24] OMAP4: PM: Add WakeupGen and secure GIC low power support
Add WakeupGen and secure GIC low power support to save and restore
it's registers. WakeupGen Registers are saved to pre-defined SAR RAM layout
and the restore is automatically done by hardware(ROM code) while coming
out of MPUSS OSWR or Device off state. Secure GIC is saved using secure
API and restored by hardware like WakeupGen.
Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
Acked-by: Jean Pihet j-pi...@ti.com
Reviewed-by: Kevin Hilman khil...@ti.com
Tested-by: Vishwanath BS vishwanath...@ti.com
---
arch/arm/mach-omap2/omap-wakeupgen.c | 129
arch/arm/mach-omap2/omap4-sar-layout.h | 15
2 files changed, 144 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/omap-wakeupgen.c
b/arch/arm/mach-omap2/omap-wakeupgen.c
index 12b00e0..bdd7210 100644
--- a/arch/arm/mach-omap2/omap-wakeupgen.c
+++ b/arch/arm/mach-omap2/omap-wakeupgen.c
@@ -22,10 +22,16 @@
#include linux/irq.h
#include linux/platform_device.h
#include linux/cpu.h
+#include linux/notifier.h
+#include linux/cpu_pm.h
#include asm/hardware/gic.h
#include mach/omap-wakeupgen.h
+#include mach/omap4-common.h
+#include mach/omap-secure.h
+
+#include omap4-sar-layout.h
#define NR_BANKS 4
#define MAX_IRQS 128
@@ -36,6 +42,7 @@
#define CPU1_ID0x1
static void __iomem *wakeupgen_base;
+static void __iomem *sar_base;
static DEFINE_PER_CPU(u32 [NR_BANKS], irqmasks);
static DEFINE_SPINLOCK(wakeupgen_lock);
static unsigned int irq_target_cpu[NR_IRQS];
@@ -55,6 +62,11 @@ static inline void wakeupgen_writel(u32 val, u8 idx, u32 cpu)
(cpu * CPU_ENA_OFFSET) + (idx * 4));
}
+static inline void sar_writel(u32 val, u32 offset, u8 idx)
+{
+ __raw_writel(val, sar_base + offset + (idx * 4));
+}
+
static void _wakeupgen_set_all(unsigned int cpu, unsigned int reg)
{
u8 i;
@@ -180,6 +192,91 @@ static void wakeupgen_irqmask_all(unsigned int cpu,
unsigned int set)
spin_unlock_irqrestore(wakeupgen_lock, flags);
}
+/*
+ * Save WakeupGen interrupt context in SAR BANK3. Restore is done by
+ * ROM code. WakeupGen IP is integrated along with GIC to manage the
+ * interrupt wakeups from CPU low power states. It manages
+ * masking/unmasking of Shared peripheral interrupts(SPI). So the
+ * interrupt enable/disable control should be in sync and consistent
+ * at WakeupGen and GIC so that interrupts are not lost.
+ */
+static void irq_save_context(void)
+{
+ u32 i, val;
+
+ if (omap_rev() == OMAP4430_REV_ES1_0)
+ return;
+
+ if (!sar_base)
+ sar_base = omap4_get_sar_ram_base();
+
+ for (i = 0; i NR_BANKS; i++) {
+ /* Save the CPUx interrupt mask for IRQ 0 to 127 */
+ val = wakeupgen_readl(i, 0);
+ sar_writel(val, WAKEUPGENENB_OFFSET_CPU0, i);
+ val = wakeupgen_readl(i, 1);
+ sar_writel(val, WAKEUPGENENB_OFFSET_CPU1, i);
+
+ /*
+* Disable the secure interrupts for CPUx. The restore
+* code blindly restores secure and non-secure interrupt
+* masks from SAR RAM. Secure interrupts are not suppose
+* to be enabled from HLOS. So overwrite the SAR location
+* so that the secure interrupt remains disabled.
+*/
+ sar_writel(0x0, WAKEUPGENENB_SECURE_OFFSET_CPU0, i);
+ sar_writel(0x0, WAKEUPGENENB_SECURE_OFFSET_CPU1, i);
+ }
+
+ /* Save AuxBoot* registers */
+ val = __raw_readl(wakeupgen_base + OMAP_AUX_CORE_BOOT_0);
+ __raw_writel(val, sar_base + AUXCOREBOOT0_OFFSET);
+ val = __raw_readl(wakeupgen_base + OMAP_AUX_CORE_BOOT_0);
+ __raw_writel(val, sar_base + AUXCOREBOOT1_OFFSET);
+
+ /* Save SyncReq generation logic */
+ val = __raw_readl(wakeupgen_base + OMAP_AUX_CORE_BOOT_0);
+ __raw_writel(val, sar_base + AUXCOREBOOT0_OFFSET);
+ val = __raw_readl(wakeupgen_base + OMAP_AUX_CORE_BOOT_0);
+ __raw_writel(val, sar_base + AUXCOREBOOT1_OFFSET);
+
+ /* Save SyncReq generation logic */
+ val = __raw_readl(wakeupgen_base + OMAP_PTMSYNCREQ_MASK);
+ __raw_writel(val, sar_base + PTMSYNCREQ_MASK_OFFSET);
+ val = __raw_readl(wakeupgen_base + OMAP_PTMSYNCREQ_EN);
+ __raw_writel(val, sar_base + PTMSYNCREQ_EN_OFFSET);
+
+ /* Set the Backup Bit Mask status */
+ val = __raw_readl(sar_base + SAR_BACKUP_STATUS_OFFSET);
+ val |= SAR_BACKUP_STATUS_WAKEUPGEN;
+ __raw_writel(val, sar_base + SAR_BACKUP_STATUS_OFFSET);
+}
+
+/*
+ * Clear WakeupGen SAR backup status.
+ */
+void irq_sar_clear(void)
+{
+ u32 val;
+ val = __raw_readl(sar_base + SAR_BACKUP_STATUS_OFFSET);
+ val = ~SAR_BACKUP_STATUS_WAKEUPGEN;
+ __raw_writel(val, sar_base + SAR_BACKUP_STATUS_OFFSET);
+}
+
+/*
+ * Save GIC and Wakeupgen interrupt context using
[PATCH v2 10/24] OMAP4: PM: Add CPUX OFF mode support
This patch adds the CPU0 and CPU1 off mode support. CPUX close switch
retention (CSWR) is not supported by hardware design.
The CPUx OFF mode isn't supported on OMAP4430 ES1.0
CPUx sleep code is common for hotplug, suspend and CPUilde.
Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
Acked-by: Jean Pihet j-pi...@ti.com
Reviewed-by: Kevin Hilman khil...@ti.com
Tested-by: Vishwanath BS vishwanath...@ti.com
---
arch/arm/mach-omap2/Makefile|6 +-
arch/arm/mach-omap2/include/mach/omap-secure.h |8 +
arch/arm/mach-omap2/include/mach/omap4-common.h | 32 +++
arch/arm/mach-omap2/omap-mpuss-lowpower.c | 248
arch/arm/mach-omap2/omap-smp.c | 13 +
arch/arm/mach-omap2/omap4-sar-layout.h |9 +
arch/arm/mach-omap2/pm44xx.c|6 +
arch/arm/mach-omap2/sleep44xx.S | 275 +++
8 files changed, 595 insertions(+), 2 deletions(-)
create mode 100644 arch/arm/mach-omap2/omap-mpuss-lowpower.c
create mode 100644 arch/arm/mach-omap2/sleep44xx.S
diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index ba8249b..974c9d1 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -25,11 +25,13 @@ obj-$(CONFIG_TWL4030_CORE) += omap_twl.o
obj-$(CONFIG_SMP) += omap-smp.o omap-headsmp.o
obj-$(CONFIG_LOCAL_TIMERS) += timer-mpu.o
obj-$(CONFIG_HOTPLUG_CPU) += omap-hotplug.o
-obj-$(CONFIG_ARCH_OMAP4) += omap4-common.o omap-wakeupgen.o
+obj-$(CONFIG_ARCH_OMAP4) += omap4-common.o omap-wakeupgen.o \
+ sleep44xx.o
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)
# Functions loaded to SRAM
obj-$(CONFIG_SOC_OMAP2420) += sram242x.o
@@ -63,7 +65,7 @@ obj-$(CONFIG_ARCH_OMAP2) += pm24xx.o
obj-$(CONFIG_ARCH_OMAP2) += sleep24xx.o
obj-$(CONFIG_ARCH_OMAP3) += pm34xx.o sleep34xx.o \
cpuidle34xx.o
-obj-$(CONFIG_ARCH_OMAP4) += pm44xx.o
+obj-$(CONFIG_ARCH_OMAP4) += pm44xx.o omap-mpuss-lowpower.o
obj-$(CONFIG_PM_DEBUG) += pm-debug.o
obj-$(CONFIG_OMAP_SMARTREFLEX) += sr_device.o smartreflex.o
obj-$(CONFIG_OMAP_SMARTREFLEX_CLASS3) += smartreflex-class3.o
diff --git a/arch/arm/mach-omap2/include/mach/omap-secure.h
b/arch/arm/mach-omap2/include/mach/omap-secure.h
index e2f95a0..0062d49 100644
--- a/arch/arm/mach-omap2/include/mach/omap-secure.h
+++ b/arch/arm/mach-omap2/include/mach/omap-secure.h
@@ -35,10 +35,18 @@
#define OMAP4_HAL_SAVEALL_INDEX0x1c
#define OMAP4_HAL_SAVEGIC_INDEX0x1d
+/* Secure Monitor mode APIs */
+#define OMAP4_MON_SCU_PWR_INDEX0x108
+
+/* Secure PPA(Primary Protected Application) APIs */
+#define OMAP4_PPA_CPU_ACTRL_SMP_INDEX 0x25
+
+#ifndef __ASSEMBLER__
extern u32 omap_secure_dispatcher(u32 idx, u32 flag, u32 nargs,
u32 arg1, u32 arg2, u32 arg3, u32 arg4);
extern u32 omap_smc2(u32 id, u32 falg, u32 pargs);
extern phys_addr_t omap_secure_ram_mempool_base(void);
extern int omap_secure_ram_reserve_memblock(void);
+#endif /* __ASSEMBLER__ */
#endif /* OMAP_ARCH_OMAP_SECURE_H */
diff --git a/arch/arm/mach-omap2/include/mach/omap4-common.h
b/arch/arm/mach-omap2/include/mach/omap4-common.h
index 947d0c8..1f6c9ac 100644
--- a/arch/arm/mach-omap2/include/mach/omap4-common.h
+++ b/arch/arm/mach-omap2/include/mach/omap4-common.h
@@ -13,6 +13,9 @@
#ifndef OMAP_ARCH_OMAP4_COMMON_H
#define OMAP_ARCH_OMAP4_COMMON_H
+#include asm/proc-fns.h
+
+#ifndef __ASSEMBLER__
/*
* wfi used in low power code. Directly opcode is used instead
* of instruction to avoid mulit-omap build break
@@ -40,6 +43,7 @@ static inline void __iomem *omap4_get_scu_base(void)
extern void __init gic_init_irq(void);
extern void omap_smc1(u32 fn, u32 arg);
extern void __iomem *omap4_get_sar_ram_base(void);
+extern void omap_do_wfi(void);
#ifdef CONFIG_SMP
/* Needed for secondary core boot */
@@ -48,4 +52,32 @@ 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);
#endif
+
+#if defined(CONFIG_SMP) defined(CONFIG_PM)
+extern int omap4_mpuss_init(void);
+extern int omap4_enter_lowpower(unsigned int cpu, unsigned int power_state);
+extern int omap4_finish_suspend(unsigned long cpu_state);
+extern void omap4_cpu_resume(void);
+#else
+static inline int omap4_enter_lowpower(unsigned int cpu,
+ unsigned int power_state)
+{
+ cpu_do_idle();
+
[PATCH v2 20/24] OMAP4: PM: Add power domain statistics support
Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com Acked-by: Jean Pihet j-pi...@ti.com Reviewed-by: Kevin Hilman khil...@ti.com Tested-by: Vishwanath BS vishwanath...@ti.com --- arch/arm/mach-omap2/omap-mpuss-lowpower.c |4 1 files changed, 4 insertions(+), 0 deletions(-) diff --git a/arch/arm/mach-omap2/omap-mpuss-lowpower.c b/arch/arm/mach-omap2/omap-mpuss-lowpower.c index 505844f..b146854 100644 --- a/arch/arm/mach-omap2/omap-mpuss-lowpower.c +++ b/arch/arm/mach-omap2/omap-mpuss-lowpower.c @@ -256,6 +256,8 @@ int omap4_enter_lowpower(unsigned int cpu, unsigned int power_state) return -ENXIO; } + pwrdm_pre_transition(); + /* * Check MPUSS next state and save interrupt controller if needed. * In MPUSS OSWR or device OFF, interrupt controller contest is lost. @@ -288,6 +290,8 @@ int omap4_enter_lowpower(unsigned int cpu, unsigned int power_state) wakeup_cpu = smp_processor_id(); set_cpu_next_pwrst(wakeup_cpu, PWRDM_POWER_ON); + pwrdm_post_transition(); + return 0; } -- 1.7.4.1 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 21/24] OMAP4: PM: Add CPUidle support
Add OMAP4 CPUIDLE support. CPU1 is left with defualt idle and
the low power state for it is managed via cpu-hotplug.
This patch adds MPUSS low power states in cpuidle.
C1 - CPU0 ON + CPU1 ON + MPU ON
C2 - CPU0 OFF + CPU1 OFF + MPU CSWR
C3 - CPU0 OFF + CPU1 OFF + MPU OSWR
OMAP4460 onwards, MPUSS power domain doesn't support OFF state any more
anymore just like CORE power domain. The deepest state supported is OSWr.
Ofcourse when MPUSS and CORE PD transitions to OSWR along with device
off mode, even the memory contemts are lost which is as good as
the PD off state.
On OMAP4 because of hardware constraints, no low power states are
targeted when both CPUs are online and in SMP mode. The low power
states are attempted only when secondary CPU gets offline to OFF
through hotplug infrastructure.
Thanks to Nicole Chalhoub n-chalh...@ti.com for doing exhaustive
C-state latency profiling.
Signed-off-by: Rajendra Nayak rna...@ti.com
Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
Acked-by: Jean Pihet j-pi...@ti.com
Reviewed-by: Kevin Hilman khil...@ti.com
Tested-by: Vishwanath BS vishwanath...@ti.com
---
arch/arm/mach-omap2/Makefile |3 +-
arch/arm/mach-omap2/cpuidle44xx.c | 210 +
arch/arm/mach-omap2/pm.h |1 +
arch/arm/mach-omap2/pm44xx.c |2 +
4 files changed, 215 insertions(+), 1 deletions(-)
create mode 100644 arch/arm/mach-omap2/cpuidle44xx.c
diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index 974c9d1..a9f8d48 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -65,7 +65,8 @@ obj-$(CONFIG_ARCH_OMAP2) += pm24xx.o
obj-$(CONFIG_ARCH_OMAP2) += sleep24xx.o
obj-$(CONFIG_ARCH_OMAP3) += pm34xx.o sleep34xx.o \
cpuidle34xx.o
-obj-$(CONFIG_ARCH_OMAP4) += pm44xx.o omap-mpuss-lowpower.o
+obj-$(CONFIG_ARCH_OMAP4) += pm44xx.o omap-mpuss-lowpower.o \
+ cpuidle44xx.o
obj-$(CONFIG_PM_DEBUG) += pm-debug.o
obj-$(CONFIG_OMAP_SMARTREFLEX) += sr_device.o smartreflex.o
obj-$(CONFIG_OMAP_SMARTREFLEX_CLASS3) += smartreflex-class3.o
diff --git a/arch/arm/mach-omap2/cpuidle44xx.c
b/arch/arm/mach-omap2/cpuidle44xx.c
new file mode 100644
index 000..ac8f4c0
--- /dev/null
+++ b/arch/arm/mach-omap2/cpuidle44xx.c
@@ -0,0 +1,210 @@
+/*
+ * OMAP4 CPU idle Routines
+ *
+ * Copyright (C) 2011 Texas Instruments, Inc.
+ * Santosh Shilimkar santosh.shilim...@ti.com
+ * Rajendra Nayak rna...@ti.com
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include linux/sched.h
+#include linux/cpuidle.h
+#include linux/cpu_pm.h
+
+#include asm/proc-fns.h
+
+#include mach/omap4-common.h
+
+#include pm.h
+#include prm.h
+
+#ifdef CONFIG_CPU_IDLE
+
+/* Machine specific information to be recorded in the C-state driver_data */
+struct omap4_idle_statedata {
+ u32 cpu_state;
+ u32 mpu_logic_state;
+ u32 mpu_state;
+ u8 valid;
+};
+
+static struct cpuidle_params cpuidle_params_table[] = {
+ /* C1 - CPU0 ON + CPU1 ON + MPU ON */
+ {.exit_latency = 2 + 2 , .target_residency = 5, .valid = 1},
+ /* C2- CPU0 OFF + CPU1 OFF + MPU CSWR */
+ {.exit_latency = 328 + 440 , .target_residency = 960, .valid = 1},
+ /* C3 - CPU0 OFF + CPU1 OFF + MPU OSWR */
+ {.exit_latency = 460 + 518 , .target_residency = 1100, .valid = 1},
+};
+
+#define OMAP4_NUM_STATES ARRAY_SIZE(cpuidle_params_table)
+
+struct omap4_idle_statedata omap4_idle_data[OMAP4_NUM_STATES];
+static struct powerdomain *mpu_pd, *cpu0_pd, *cpu1_pd;
+
+/**
+ * omap4_enter_idle - Programs OMAP4 to enter the specified state
+ * @dev: cpuidle device
+ * @state: The target state to be programmed
+ *
+ * Called from the CPUidle framework to program the device to the
+ * specified low power state selected by the governor.
+ * Returns the amount of time spent in the low power state.
+ */
+static int omap4_enter_idle(struct cpuidle_device *dev,
+ struct cpuidle_state *state)
+{
+ struct omap4_idle_statedata *cx = cpuidle_get_statedata(state);
+ struct timespec ts_preidle, ts_postidle, ts_idle;
+ u32 cpu1_state;
+
+ /* Used to keep track of the total time in idle */
+ getnstimeofday(ts_preidle);
+
+ local_irq_disable();
+ local_fiq_disable();
+
+ /*
+* CPU0 has to stay ON (i.e in C1) until CPU1 is OFF state.
+* This is necessary to honour hardware recommondation
+* of triggeing all the possible low power modes once CPU1 is
+* out of coherency and in OFF mode.
+* Update dev-last_state so that governor stats reflects right
+* data.
+*/
+
[PATCH v2 18/24] OMAP4: PM: Add L2X0 cache lowpower support
When MPUSS hits off-mode, L2 cache is lost. This patch adds L2X0
necessary maintenance operations and context restoration in the
low power code.
Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
Acked-by: Jean Pihet j-pi...@ti.com
Reviewed-by: Kevin Hilman khil...@ti.com
Tested-by: Vishwanath BS vishwanath...@ti.com
---
arch/arm/mach-omap2/include/mach/omap-secure.h |5 +
arch/arm/mach-omap2/omap-mpuss-lowpower.c | 41 ++-
arch/arm/mach-omap2/omap4-sar-layout.h |4 +
arch/arm/mach-omap2/sleep44xx.S| 95
4 files changed, 144 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/include/mach/omap-secure.h
b/arch/arm/mach-omap2/include/mach/omap-secure.h
index 0062d49..6e929c5 100644
--- a/arch/arm/mach-omap2/include/mach/omap-secure.h
+++ b/arch/arm/mach-omap2/include/mach/omap-secure.h
@@ -37,8 +37,13 @@
/* Secure Monitor mode APIs */
#define OMAP4_MON_SCU_PWR_INDEX0x108
+#define OMAP4_MON_L2X0_DBG_CTRL_INDEX 0x100
+#define OMAP4_MON_L2X0_CTRL_INDEX 0x102
+#define OMAP4_MON_L2X0_AUXCTRL_INDEX 0x109
+#define OMAP4_MON_L2X0_PREFETCH_INDEX 0x113
/* Secure PPA(Primary Protected Application) APIs */
+#define OMAP4_PPA_L2_POR_INDEX 0x23
#define OMAP4_PPA_CPU_ACTRL_SMP_INDEX 0x25
#ifndef __ASSEMBLER__
diff --git a/arch/arm/mach-omap2/omap-mpuss-lowpower.c
b/arch/arm/mach-omap2/omap-mpuss-lowpower.c
index d8becec..752dc57 100644
--- a/arch/arm/mach-omap2/omap-mpuss-lowpower.c
+++ b/arch/arm/mach-omap2/omap-mpuss-lowpower.c
@@ -49,6 +49,7 @@
#include asm/system.h
#include asm/pgalloc.h
#include asm/suspend.h
+#include asm/hardware/cache-l2x0.h
#include plat/omap44xx.h
#include mach/omap4-common.h
@@ -63,10 +64,12 @@ struct omap4_cpu_pm_info {
struct powerdomain *pwrdm;
void __iomem *scu_sar_addr;
void __iomem *wkup_sar_addr;
+ void __iomem *l2x0_sar_addr;
};
static DEFINE_PER_CPU(struct omap4_cpu_pm_info, omap4_pm_info);
static struct powerdomain *mpuss_pd;
+static void __iomem *sar_base;
/*
* Program the wakeup routine address for the CPU0 and CPU1
@@ -135,6 +138,36 @@ static void scu_pwrst_prepare(unsigned int cpu_id,
unsigned int cpu_state)
__raw_writel(scu_pwr_st, pm_info-scu_sar_addr);
}
+/*
+ * Store the CPU cluster state for L2X0 low power operations.
+ */
+static void l2x0_pwrst_prepare(unsigned int cpu_id, unsigned int save_state)
+{
+ struct omap4_cpu_pm_info *pm_info = per_cpu(omap4_pm_info, cpu_id);
+
+ __raw_writel(save_state, pm_info-l2x0_sar_addr);
+}
+
+/*
+ * Save the L2X0 AUXCTRL and POR value to SAR memory. Its used to
+ * in every restore MPUSS OFF path.
+ */
+#ifdef CONFIG_CACHE_L2X0
+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);
+}
+#else
+static void save_l2x0_context(void)
+{}
+#endif
+
/**
* omap4_enter_lowpower: OMAP4 MPUSS Low Power Entry Function
* The purpose of this function is to manage low power programming
@@ -182,6 +215,7 @@ int omap4_enter_lowpower(unsigned int cpu, unsigned int
power_state)
set_cpu_next_pwrst(cpu, power_state);
set_cpu_wakeup_addr(cpu, virt_to_phys(omap4_cpu_resume));
scu_pwrst_prepare(cpu, power_state);
+ l2x0_pwrst_prepare(cpu, save_state);
/*
* Call low level function with targeted low power state.
@@ -239,17 +273,19 @@ int omap4_hotplug_cpu(unsigned int cpu, unsigned int
power_state)
int __init omap4_mpuss_init(void)
{
struct omap4_cpu_pm_info *pm_info;
- void __iomem *sar_base = omap4_get_sar_ram_base();
if (omap_rev() == OMAP4430_REV_ES1_0) {
WARN(1, Power Management not supported on OMAP4430 ES1.0\n);
return -ENODEV;
}
+ sar_base = omap4_get_sar_ram_base();
+
/* Initilaise per CPU PM information */
pm_info = per_cpu(omap4_pm_info, 0x0);
pm_info-scu_sar_addr = sar_base + SCU_OFFSET0;
pm_info-wkup_sar_addr = sar_base + CPU0_WAKEUP_NS_PA_ADDR_OFFSET;
+ pm_info-l2x0_sar_addr = sar_base + L2X0_SAVE_OFFSET0;
pm_info-pwrdm = pwrdm_lookup(cpu0_pwrdm);
if (!pm_info-pwrdm) {
pr_err(Lookup failed for CPU0 pwrdm\n);
@@ -265,6 +301,7 @@ int __init omap4_mpuss_init(void)
pm_info = per_cpu(omap4_pm_info, 0x1);
pm_info-scu_sar_addr = sar_base + SCU_OFFSET1;
pm_info-wkup_sar_addr = sar_base + CPU1_WAKEUP_NS_PA_ADDR_OFFSET;
+ pm_info-l2x0_sar_addr = sar_base + L2X0_SAVE_OFFSET1;
pm_info-pwrdm = pwrdm_lookup(cpu1_pwrdm);
if (!pm_info-pwrdm) {
pr_err(Lookup failed for CPU1 pwrdm\n);
@@ -290,6 +327,8 @@ int
[PATCH v2 22/24] OMAP4: cpuidle: Switch to gptimer from twd in deeper C-states.
CPU local timer(TWD) stops when the CPU is transitioning into deeper C-States. Since these timers are not wakeup capable, we need the wakeup capable global timer to program the wakeup time depending on the next timer expiry. It can be handled by registering a global wakeup capable timer along with local timers marked with (mis)feature flag CLOCK_EVT_FEAT_C3STOP. Then notify the clock events layer from idle code using CLOCK_EVT_NOTIFY_BROADCAST_ENTER/EXIT). ARM local timers are already marked with C3STOP feature. Add the notifiers to OMAP4 CPU idle code for the broadcast entry and exit. Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com Acked-by: Jean Pihet j-pi...@ti.com Acked-by: Kevin Hilman khil...@ti.com Tested-by: Vishwanath BS vishwanath...@ti.com --- arch/arm/mach-omap2/cpuidle44xx.c |8 1 files changed, 8 insertions(+), 0 deletions(-) diff --git a/arch/arm/mach-omap2/cpuidle44xx.c b/arch/arm/mach-omap2/cpuidle44xx.c index ac8f4c0..f0cd214 100644 --- a/arch/arm/mach-omap2/cpuidle44xx.c +++ b/arch/arm/mach-omap2/cpuidle44xx.c @@ -13,6 +13,7 @@ #include linux/sched.h #include linux/cpuidle.h #include linux/cpu_pm.h +#include linux/clockchips.h #include asm/proc-fns.h @@ -60,6 +61,7 @@ static int omap4_enter_idle(struct cpuidle_device *dev, struct omap4_idle_statedata *cx = cpuidle_get_statedata(state); struct timespec ts_preidle, ts_postidle, ts_idle; u32 cpu1_state; + int cpu_id = smp_processor_id(); /* Used to keep track of the total time in idle */ getnstimeofday(ts_preidle); @@ -81,6 +83,9 @@ static int omap4_enter_idle(struct cpuidle_device *dev, cx = cpuidle_get_statedata(dev-safe_state); } + if (state dev-states[0]) + clockevents_notify(CLOCK_EVT_NOTIFY_BROADCAST_ENTER, cpu_id); + /* * Call idle CPU PM enter notifier chain so that * VFP and per CPU interrupt context is saved. @@ -116,6 +121,9 @@ static int omap4_enter_idle(struct cpuidle_device *dev, if (omap4_mpuss_read_prev_context_state()) cpu_cluster_pm_exit(); + if (state dev-states[0]) + clockevents_notify(CLOCK_EVT_NOTIFY_BROADCAST_EXIT, cpu_id); + getnstimeofday(ts_postidle); ts_idle = timespec_sub(ts_postidle, ts_preidle); -- 1.7.4.1 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 23/24] OMAP3: CPUidle: Make use of CPU PM notifiers
Save VFP CPU context using CPU PM notifier chain. VFP context
is lost when CPU hits OFF state.
Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
Reviewed-by: Kevin Hilman khil...@ti.com
Tested-by: Vishwanath BS vishwanath...@ti.com
---
arch/arm/mach-omap2/cpuidle34xx.c | 15 +++
1 files changed, 15 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/cpuidle34xx.c
b/arch/arm/mach-omap2/cpuidle34xx.c
index 4bf6e6e..861920a 100644
--- a/arch/arm/mach-omap2/cpuidle34xx.c
+++ b/arch/arm/mach-omap2/cpuidle34xx.c
@@ -24,6 +24,7 @@
#include linux/sched.h
#include linux/cpuidle.h
+#include linux/cpu_pm.h
#include plat/prcm.h
#include plat/irqs.h
@@ -118,9 +119,23 @@ static int omap3_enter_idle(struct cpuidle_device *dev,
pwrdm_for_each_clkdm(core_pd, _cpuidle_deny_idle);
}
+ /*
+* Call idle CPU PM enter notifier chain so that
+* VFP context is saved.
+*/
+ if (mpu_state == PWRDM_POWER_OFF)
+ cpu_pm_enter();
+
/* Execute ARM wfi */
omap_sram_idle();
+ /*
+* Call idle CPU PM enter notifier chain to restore
+* VFP context.
+*/
+ if (pwrdm_read_prev_pwrst(mpu_pd) == PWRDM_POWER_OFF)
+ cpu_pm_exit();
+
/* Re-allow idle for C1 */
if (state == dev-states[0]) {
pwrdm_for_each_clkdm(mpu_pd, _cpuidle_allow_idle);
--
1.7.4.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 19/24] OMAP4: PM: Add MPUSS power domain OSWR support
This patch adds the MPUSS OSWR (Open Switch Retention) support. The MPUSS
OSWR configuration is as below.
- CPUx L1 and logic lost, MPUSS logic lost, L2 memory is retained
OMAP4460 onwards, MPUSS power domain doesn't support OFF state any more
anymore just like CORE power domain. The deepest state supported is OSWR.
On OMAP4430 secure devices too, MPUSS off mode can't be used because of
a bug which alters Ducati and Tesla states. Hence MPUSS off mode as an
independent state isn't supported on OMAP44XX devices.
Ofcourse when MPUSS power domain transitions to OSWR along
with device off mode, it eventually hits off state since memory
contents are lost.
Hence the MPUSS off mode independent state is not attempted without
device off mode. All the necessary infrastructure code for MPUSS
off mode is in place as part of this series.
Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
Acked-by: Jean Pihet j-pi...@ti.com
Reviewed-by: Kevin Hilman khil...@ti.com
Tested-by: Vishwanath BS vishwanath...@ti.com
---
arch/arm/mach-omap2/include/mach/omap4-common.h |6 ++
arch/arm/mach-omap2/omap-mpuss-lowpower.c | 65 +-
arch/arm/mach-omap2/pm44xx.c|4 ++
3 files changed, 72 insertions(+), 3 deletions(-)
diff --git a/arch/arm/mach-omap2/include/mach/omap4-common.h
b/arch/arm/mach-omap2/include/mach/omap4-common.h
index e5db389..1f6ae1d 100644
--- a/arch/arm/mach-omap2/include/mach/omap4-common.h
+++ b/arch/arm/mach-omap2/include/mach/omap4-common.h
@@ -49,6 +49,7 @@ extern int omap4_enter_lowpower(unsigned int cpu, unsigned
int power_state);
extern int omap4_finish_suspend(unsigned long cpu_state);
extern void omap4_cpu_resume(void);
extern int omap4_hotplug_cpu(unsigned int cpu, unsigned int power_state);
+extern u32 omap4_mpuss_read_prev_context_state(void);
#else
static inline int omap4_enter_lowpower(unsigned int cpu,
unsigned int power_state)
@@ -75,6 +76,11 @@ static inline int omap4_finish_suspend(unsigned long
cpu_state)
static inline void omap4_cpu_resume(void)
{}
+
+static inline u32 omap4_mpuss_read_prev_context_state(void)
+{
+ return 0;
+}
#endif
#endif /* __ASSEMBLER__ */
#endif /* OMAP_ARCH_OMAP4_COMMON_H */
diff --git a/arch/arm/mach-omap2/omap-mpuss-lowpower.c
b/arch/arm/mach-omap2/omap-mpuss-lowpower.c
index 752dc57..505844f 100644
--- a/arch/arm/mach-omap2/omap-mpuss-lowpower.c
+++ b/arch/arm/mach-omap2/omap-mpuss-lowpower.c
@@ -24,8 +24,8 @@
* ON ON ON
* ON(Inactive)OFF ON(Inactive)
* OFF OFF CSWR
- * OFF OFF OSWR (*TBD)
- * OFF OFF OFF* (*TBD)
+ * OFF OFF OSWR
+ * OFF OFF OFF(Device OFF *TBD)
* --
*
* Note: CPU0 is the master core and it is the last CPU to go down
@@ -56,7 +56,11 @@
#include omap4-sar-layout.h
#include pm.h
-#include powerdomain.h
+#include prcm_mpu44xx.h
+#include prminst44xx.h
+#include prcm44xx.h
+#include prm44xx.h
+#include prm-regbits-44xx.h
#ifdef CONFIG_SMP
@@ -138,6 +142,48 @@ static void scu_pwrst_prepare(unsigned int cpu_id,
unsigned int cpu_state)
__raw_writel(scu_pwr_st, pm_info-scu_sar_addr);
}
+/* Helper functions for MPUSS OSWR */
+static inline void mpuss_clear_prev_logic_pwrst(void)
+{
+ u32 reg;
+
+ reg = omap4_prminst_read_inst_reg(OMAP4430_PRM_PARTITION,
+ OMAP4430_PRM_MPU_INST, OMAP4_RM_MPU_MPU_CONTEXT_OFFSET);
+ omap4_prminst_write_inst_reg(reg, OMAP4430_PRM_PARTITION,
+ OMAP4430_PRM_MPU_INST, OMAP4_RM_MPU_MPU_CONTEXT_OFFSET);
+}
+
+static inline void cpu_clear_prev_logic_pwrst(unsigned int cpu_id)
+{
+ u32 reg;
+
+ if (cpu_id) {
+ reg = omap4_prcm_mpu_read_inst_reg(OMAP4430_PRCM_MPU_CPU1_INST,
+ OMAP4_RM_CPU1_CPU1_CONTEXT_OFFSET);
+ omap4_prcm_mpu_write_inst_reg(reg, OMAP4430_PRCM_MPU_CPU1_INST,
+ OMAP4_RM_CPU1_CPU1_CONTEXT_OFFSET);
+ } else {
+ reg = omap4_prcm_mpu_read_inst_reg(OMAP4430_PRCM_MPU_CPU0_INST,
+ OMAP4_RM_CPU0_CPU0_CONTEXT_OFFSET);
+ omap4_prcm_mpu_write_inst_reg(reg, OMAP4430_PRCM_MPU_CPU0_INST,
+ OMAP4_RM_CPU0_CPU0_CONTEXT_OFFSET);
+ }
+}
+
+/**
+ * omap4_mpuss_read_prev_context_state:
+ * Function returns the MPUSS previous context state
+ */
+u32 omap4_mpuss_read_prev_context_state(void)
+{
+ u32 reg;
+
+ reg = omap4_prminst_read_inst_reg(OMAP4430_PRM_PARTITION,
+ OMAP4430_PRM_MPU_INST, OMAP4_RM_MPU_MPU_CONTEXT_OFFSET);
+ reg = OMAP4430_LOSTCONTEXT_DFF_MASK;
+ return reg;
+}
+
/*
* Store the CPU cluster state for L2X0 low power
[PATCH v2 24/24] OMAP4: Fix errata i688 with MPU interconnect barriers.
On OMAP4 SOC, intecronnects has many write buffers in the async bridges and they need to be drained before CPU enters into standby state. Patch 'OMAP4: PM: Add CPUX OFF mode support' added CPU PM support but OMAP errata i688 (Async Bridge Corruption) needs to be taken care to avoid issues like system freeze, CPU deadlocks, random crashes with register accesses, synchronisation loss on initiators operating on both interconnect port simultaneously. As per the errata, if a data is stalled inside asynchronous bridge because of back pressure, it may be accepted multiple times, creating pointer misalignment that will corrupt next transfers on that data path until next reset of the system (No recovery procedure once the issue is hit, the path remains consistently broken). Async bridge can be found on path between MPU to EMIF and MPU to L3 interconnect. This situation can happen only when the idle is initiated by a Master Request Disconnection (which is trigged by software when executing WFI on CPU). The work-around for this errata needs all the initiators connected through async bridge must ensure that data path is properly drained before issuing WFI. This condition will be met if one Strongly ordered access is performed to the target right before executing the WFI. In MPU case, L3 T2ASYNC FIFO and DDR T2ASYNC FIFO needs to be drained. IO barrier ensure that there is no synchronisation loss on initiators operating on both interconnect port simultaneously. Thanks to Russell for a tip to conver assembly function to C fuction there by reducing 40 odd lines of code from the patch. Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com Signed-off-by: Richard Woodruff r-woodru...@ti.com Acked-by: Jean Pihet j-pi...@ti.com Reviewed-by: Kevin Hilman khil...@ti.com Tested-by: Vishwanath BS vishwanath...@ti.com Cc: Russell King li...@arm.linux.org.uk --- arch/arm/mach-omap2/Kconfig | 21 +++ arch/arm/mach-omap2/include/mach/barriers.h | 31 arch/arm/mach-omap2/include/mach/omap4-common.h |4 ++ arch/arm/mach-omap2/omap4-common.c | 44 +++ arch/arm/mach-omap2/sleep44xx.S |8 arch/arm/plat-omap/sram.c | 43 ++ 6 files changed, 136 insertions(+), 15 deletions(-) create mode 100644 arch/arm/mach-omap2/include/mach/barriers.h diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig index 57b66d5..767a587 100644 --- a/arch/arm/mach-omap2/Kconfig +++ b/arch/arm/mach-omap2/Kconfig @@ -345,6 +345,27 @@ config OMAP3_SDRC_AC_TIMING wish to say no. Selecting yes without understanding what is going on could result in system crashes; +config OMAP4_ERRATA_I688 + bool OMAP4 errata: Async Bridge Corruption + depends on ARCH_OMAP4 + select ARCH_HAS_BARRIERS + help + If a data is stalled inside asynchronous bridge because of back + pressure, it may be accepted multiple times, creating pointer + misalignment that will corrupt next transfers on that data path + until next reset of the system (No recovery procedure once the + issue is hit, the path remains consistently broken). Async bridge + can be found on path between MPU to EMIF and MPU to L3 interconnect. + This situation can happen only when the idle is initiated by a + Master Request Disconnection (which is trigged by software when + executing WFI on CPU). + The work-around for this errata needs all the initiators connected + through async bridge must ensure that data path is properly drained + before issuing WFI. This condition will be met if one Strongly ordered + access is performed to the target right before executing the WFI. + In MPU case, L3 T2ASYNC FIFO and DDR T2ASYNC FIFO needs to be drained. + IO barrier ensure that there is no synchronisation loss on initiators + operating on both interconnect port simultaneously. endmenu endif diff --git a/arch/arm/mach-omap2/include/mach/barriers.h b/arch/arm/mach-omap2/include/mach/barriers.h new file mode 100644 index 000..4fa72c7 --- /dev/null +++ b/arch/arm/mach-omap2/include/mach/barriers.h @@ -0,0 +1,31 @@ +/* + * OMAP memory barrier header. + * + * Copyright (C) 2011 Texas Instruments, Inc. + * Santosh Shilimkar santosh.shilim...@ti.com + * Richard Woodruff r-woodru...@ti.com + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License version 2 as + * published by the Free Software Foundation. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU
[PATCH v2 15/24] OMAP4: suspend: Add MPUSS power domain RETENTION support
This patch adds MPUSS(MPU Sub System) power domain
CSWR(Close Switch Retention) support to system wide suspend.
For MPUSS power domain to hit retention(CSWR or OSWR), both
CPU0 and CPU1 power domains need to be in OFF or DORMANT state,
since CPU power domain CSWR is not supported by hardware
Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
Acked-by: Jean Pihet j-pi...@ti.com
Reviewed-by: Kevin Hilman khil...@ti.com
Tested-by: Vishwanath BS vishwanath...@ti.com
---
arch/arm/mach-omap2/omap-mpuss-lowpower.c | 16 +++
arch/arm/mach-omap2/pm44xx.c | 69 ++--
2 files changed, 80 insertions(+), 5 deletions(-)
diff --git a/arch/arm/mach-omap2/omap-mpuss-lowpower.c
b/arch/arm/mach-omap2/omap-mpuss-lowpower.c
index c0b6472..d8becec 100644
--- a/arch/arm/mach-omap2/omap-mpuss-lowpower.c
+++ b/arch/arm/mach-omap2/omap-mpuss-lowpower.c
@@ -66,6 +66,7 @@ struct omap4_cpu_pm_info {
};
static DEFINE_PER_CPU(struct omap4_cpu_pm_info, omap4_pm_info);
+static struct powerdomain *mpuss_pd;
/*
* Program the wakeup routine address for the CPU0 and CPU1
@@ -140,6 +141,13 @@ static void scu_pwrst_prepare(unsigned int cpu_id,
unsigned int cpu_state)
* of OMAP4 MPUSS subsystem
* @cpu : CPU ID
* @power_state: Low power state.
+ *
+ * MPUSS states for the context save:
+ * save_state =
+ * 0 - Nothing lost and no need to save: MPUSS INACTIVE
+ * 1 - CPUx L1 and logic lost: MPUSS CSWR
+ * 2 - CPUx L1 and logic lost + GIC lost: MPUSS OSWR
+ * 3 - CPUx L1 and logic lost + GIC + L2 lost: DEVICE OFF
*/
int omap4_enter_lowpower(unsigned int cpu, unsigned int power_state)
{
@@ -169,6 +177,7 @@ int omap4_enter_lowpower(unsigned int cpu, unsigned int
power_state)
return -ENXIO;
}
+ pwrdm_clear_all_prev_pwrst(mpuss_pd);
clear_cpu_prev_pwrst(cpu);
set_cpu_next_pwrst(cpu, power_state);
set_cpu_wakeup_addr(cpu, virt_to_phys(omap4_cpu_resume));
@@ -268,6 +277,13 @@ int __init omap4_mpuss_init(void)
/* Initialise CPU1 power domain state to ON */
pwrdm_set_next_pwrst(pm_info-pwrdm, PWRDM_POWER_ON);
+ mpuss_pd = pwrdm_lookup(mpu_pwrdm);
+ if (!mpuss_pd) {
+ pr_err(Failed to lookup MPUSS power domain\n);
+ return -ENODEV;
+ }
+ pwrdm_clear_all_prev_pwrst(mpuss_pd);
+
/* Save device type on scratchpad for low level code to use */
if (omap_type() != OMAP2_DEVICE_TYPE_GP)
__raw_writel(1, sar_base + OMAP_TYPE_OFFSET);
diff --git a/arch/arm/mach-omap2/pm44xx.c b/arch/arm/mach-omap2/pm44xx.c
index fdba72a..e64e275 100644
--- a/arch/arm/mach-omap2/pm44xx.c
+++ b/arch/arm/mach-omap2/pm44xx.c
@@ -1,8 +1,9 @@
/*
* OMAP4 Power Management Routines
*
- * Copyright (C) 2010 Texas Instruments, Inc.
+ * Copyright (C) 2010-2011 Texas Instruments, Inc.
* Rajendra Nayak rna...@ti.com
+ * Santosh Shilimkar santosh.shilim...@ti.com
*
* This program is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License version 2 as
@@ -16,9 +17,11 @@
#include linux/err.h
#include linux/slab.h
+#include mach/omap4-common.h
+
#include powerdomain.h
#include clockdomain.h
-#include mach/omap4-common.h
+#include pm.h
struct power_state {
struct powerdomain *pwrdm;
@@ -34,7 +37,47 @@ static LIST_HEAD(pwrst_list);
#ifdef CONFIG_SUSPEND
static int omap4_pm_suspend(void)
{
- do_wfi();
+ struct power_state *pwrst;
+ int state, ret = 0;
+ u32 cpu_id = smp_processor_id();
+
+ /* Save current powerdomain state */
+ list_for_each_entry(pwrst, pwrst_list, node) {
+ pwrst-saved_state = pwrdm_read_next_pwrst(pwrst-pwrdm);
+ }
+
+ /* Set targeted power domain states by suspend */
+ list_for_each_entry(pwrst, pwrst_list, node) {
+ omap_set_pwrdm_state(pwrst-pwrdm, pwrst-next_state);
+ }
+
+ /*
+* For MPUSS to hit power domain retention(CSWR or OSWR),
+* CPU0 and CPU1 power domains need to be in OFF or DORMANT state,
+* since CPU power domain CSWR is not supported by hardware
+* Only master CPU follows suspend path. All other CPUs follow
+* CPU hotplug path in system wide suspend. On OMAP4, CPU power
+* domain CSWR is not supported by hardware.
+* More details can be found in OMAP4430 TRM section 4.3.4.2.
+*/
+ omap4_enter_lowpower(cpu_id, PWRDM_POWER_OFF);
+
+ /* Restore next powerdomain state */
+ list_for_each_entry(pwrst, pwrst_list, node) {
+ state = pwrdm_read_prev_pwrst(pwrst-pwrdm);
+ if (state pwrst-next_state) {
+ pr_info(Powerdomain (%s) didn't enter
+ target state %d\n,
+ pwrst-pwrdm-name, pwrst-next_state);
+ ret = -1;
+ }
+
[PATCH v2 07/24] OMAP: Add Secure HAL and monitor mode API infrastructure.
On OMAP secure/emulation devices, certain APIs are exported by secure
code. Add an infrastructure so that relevant operations on secure
devices can be implemented using it.
While at this, rename omap44xx-smc.S to omap-smc.S since the common APIs
can be used on other OMAP's too.
Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
Acked-by: Jean Pihet j-pi...@ti.com
Reviewed-by: Kevin Hilman khil...@ti.com
Tested-by: Vishwanath BS vishwanath...@ti.com
---
arch/arm/mach-omap2/Makefile | 11 ++--
arch/arm/mach-omap2/include/mach/omap-secure.h | 40 +++
arch/arm/mach-omap2/omap-secure.c | 52
arch/arm/mach-omap2/{omap44xx-smc.S = omap-smc.S} | 23 +
4 files changed, 121 insertions(+), 5 deletions(-)
create mode 100644 arch/arm/mach-omap2/include/mach/omap-secure.h
create mode 100644 arch/arm/mach-omap2/omap-secure.c
rename arch/arm/mach-omap2/{omap44xx-smc.S = omap-smc.S} (70%)
diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index f343365..663f28a 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -11,10 +11,11 @@ hwmod-common= omap_hwmod.o \
omap_hwmod_common_data.o
clock-common = clock.o clock_common_data.o \
clkt_dpll.o clkt_clksel.o
+secure-common = omap-smc.o omap-secure.o
-obj-$(CONFIG_ARCH_OMAP2) += $(omap-2-3-common) $(hwmod-common)
-obj-$(CONFIG_ARCH_OMAP3) += $(omap-2-3-common) $(hwmod-common)
-obj-$(CONFIG_ARCH_OMAP4) += prm44xx.o $(hwmod-common)
+obj-$(CONFIG_ARCH_OMAP2) += $(omap-2-3-common) $(hwmod-common) $(secure-common)
+obj-$(CONFIG_ARCH_OMAP3) += $(omap-2-3-common) $(hwmod-common) $(secure-common)
+obj-$(CONFIG_ARCH_OMAP4) += prm44xx.o $(hwmod-common) $(secure-common)
obj-$(CONFIG_OMAP_MCBSP) += mcbsp.o
@@ -24,11 +25,11 @@ obj-$(CONFIG_TWL4030_CORE) += omap_twl.o
obj-$(CONFIG_SMP) += omap-smp.o omap-headsmp.o
obj-$(CONFIG_LOCAL_TIMERS) += timer-mpu.o
obj-$(CONFIG_HOTPLUG_CPU) += omap-hotplug.o
-obj-$(CONFIG_ARCH_OMAP4) += omap44xx-smc.o omap4-common.o
+obj-$(CONFIG_ARCH_OMAP4) += omap4-common.o
plus_sec := $(call as-instr,.arch_extension sec,+sec)
AFLAGS_omap-headsmp.o :=-Wa,-march=armv7-a$(plus_sec)
-AFLAGS_omap44xx-smc.o :=-Wa,-march=armv7-a$(plus_sec)
+AFLAGS_omap-smc.o :=-Wa,-march=armv7-a$(plus_sec)
# Functions loaded to SRAM
obj-$(CONFIG_SOC_OMAP2420) += sram242x.o
diff --git a/arch/arm/mach-omap2/include/mach/omap-secure.h
b/arch/arm/mach-omap2/include/mach/omap-secure.h
new file mode 100644
index 000..26e7bcc
--- /dev/null
+++ b/arch/arm/mach-omap2/include/mach/omap-secure.h
@@ -0,0 +1,40 @@
+/*
+ * omap-secure.h: OMAP Secure infrastructure header.
+ *
+ * Copyright (C) 2011 Texas Instruments, Inc.
+ * Santosh Shilimkar santosh.shilim...@ti.com
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+#ifndef OMAP_ARCH_OMAP_SECURE_H
+#define OMAP_ARCH_OMAP_SECURE_H
+
+/* Monitor error code */
+#define API_HAL_RET_VALUE_NS2S_CONVERSION_ERROR 0xFFFE
+#define API_HAL_RET_VALUE_SERVICE_UNKNWON 0x
+
+/* HAL API error codes */
+#define API_HAL_RET_VALUE_OK 0x00
+#define API_HAL_RET_VALUE_FAIL0x01
+
+/* Secure HAL API flags */
+#define FLAG_START_CRITICAL0x4
+#define FLAG_IRQFIQ_MASK 0x3
+#define FLAG_IRQ_ENABLE0x2
+#define FLAG_FIQ_ENABLE0x1
+#define NO_FLAG0x0
+
+
+/* Secure low power HAL API index */
+#define OMAP4_HAL_SAVESECURERAM_INDEX 0x1a
+#define OMAP4_HAL_SAVEHW_INDEX 0x1b
+#define OMAP4_HAL_SAVEALL_INDEX0x1c
+#define OMAP4_HAL_SAVEGIC_INDEX0x1d
+
+extern u32 omap_secure_dispatcher(u32 idx, u32 flag, u32 nargs,
+ u32 arg1, u32 arg2, u32 arg3, u32 arg4);
+extern u32 omap_smc2(u32 id, u32 falg, u32 pargs);
+
+#endif /* OMAP_ARCH_OMAP_SECURE_H */
diff --git a/arch/arm/mach-omap2/omap-secure.c
b/arch/arm/mach-omap2/omap-secure.c
new file mode 100644
index 000..e5a606e
--- /dev/null
+++ b/arch/arm/mach-omap2/omap-secure.c
@@ -0,0 +1,52 @@
+/*
+ * OMAP Secure API infrastructure.
+ *
+ * Copyright (C) 2011 Texas Instruments, Inc.
+ * Santosh Shilimkar santosh.shilim...@ti.com
+ *
+ *
+ * This program is free software,you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include linux/kernel.h
+#include linux/init.h
Re: [PATCH 1/5 v11] arm: omap: usb: ehci and ohci hwmod structures for omap4
Hi On Fri, 23 Sep 2011, Munegowda, Keshava wrote: Paul Walmsley p...@pwsan.com wrote: So I'd suggest one of two approaches: 1. If the pin muxing can follow the PM runtime status of the UHH IP block, then the pin mux data should be associated with the UHH hwmod. No, the mux is applicable only to ehci and ohci , where as sysconfig is applicable to uhh ( usb_host_hs class). My point is that, as far as I can tell, I/O pad wakeup (caused by USB remote wakeup) is only going to matter when the entire UHH IP block has its clocks cut. Otherwise, while the UHH is clocked, the EHCI and/or OHCI IP blocks will also be clocked, so no I/O pad wakeup will be needed. Do you agree? 2. If the pin muxing must follow the EHCI/OHCI IP block PM runtime status, then drivers/mfd/omap-usb-host.c is what should be handling the remuxing. omap-usb-host.c can set the dev_pm_ops of the EHCI/OHCI platform_devices to point to functions either in arch/arm/mach-omap2/usb-host.c, or local functions that call into mach-omap2/usb-host.c functions to handle pin remuxing. (Those function pointers should be provided to the MFD driver in some clean way, like via platform_data.) The dev_pm_ops of ehci should exist in /drivers/usb/host/ehci-omap.c and dev_pm_ops of phci should exist in /drivers/usb/host/ohci-omap3.c. In the existing design, the omap-usb-host.c host can not access the platform driver of ehci and ohci. But, through function pointers it is possible to send the platform data to ehci and ohci drivers to handle pin remuxing; but we will not able to use tero's patches; and it will prevent our future design activity for remote wakeup of ehci and ohci. Could you please explain in more detail why the dynamic remuxing can't be done when the UHH enters or exits idle? - Paul
Re: [PATCH 2/5 v11] arm: omap: usb: ehci and ohci hwmod structures for omap3
On Fri, 23 Sep 2011, Munegowda, Keshava wrote: On Thu, Sep 22, 2011 at 11:31 PM, Paul Walmsley p...@pwsan.com wrote: But the question arises here , why do we need these ehci and ohci as two different hwmods containing only irq and base address? It is required for future - to implement remote wakeup feature for ehci and ohci ports depending on irq-chain handler patches by Tero. Separate hwmods for ehci and ohci are needed to enable prcm chain-handler to uniquely identify the wakeup source as ehci or ohci and call only the corresponding interrupt handler. We will be using omap_hwmod_mux_init for ehci and ohci hwmods to enable I/O wakeup capability for respective IO-pads. Depending on the particular wakeup source(ehci/ohci), the corresponding ehci or ohci irq handler will be called. If ehci and ohci are combined with usbhs hwmod as a single hwmod , then for every wakeup (either ehci or ohci port wakeup) only the first interrupt handler will be called (please look at the function omap_hwmod_mux_handle_irq of /arch/arm/mach-omap2/mux.c file ; in tero's latest patch: http://www.mail-archive.com/linux-omap@vger.kernel.org/msg53139.html) , so in this case, if ehci interrupt is the first interrupt , then even for ohci wakeup , only ehci interrupt will get called; which will break the functionality. Any reason why this couldn't be handled either by: 1. adding an IRQ number field to struct omap_hwmod_mux_info, and changing _omap_hwmod_mux_handle_irq() to raise that IRQ number? or 2. using shared interrupts? - Paul -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/8] OMAP3/4: Misc fixes and clean-up
Hi Santosh On Sat, 24 Sep 2011, Santosh Shilimkar wrote: On Thursday 08 September 2011 10:51 AM, Santosh Shilimkar wrote: The series contains few fixes and clean-up for OMAP. Briefly, - HWMOD fix for the address space count - Improving the L3 register accesses - Bug fix in the L3 error handler - Sparce warning and indentation fixes in L3 error handler - Print master id in case of L3 custom errors for better debug. - Adding local time clock node for the CPUfreq and time re-calibration - Fix in the address overlap for emif and emulation domain. The series is tested on OMAP4430 SDP and OMAP4430 beagle and SDP. The following changes since commit c6a389f123b9f68d605bb7e0f9b32ec1e3e14132: Linux 3.1-rc4 (2011-08-28 21:16:01 -0700) are available in the git repository at: git://gitorious.org/omap-sw-develoment/linux-omap-dev.git v3.1-rc4-omap-misc I need your ack on below two patches so that I can re-base them and send a pull request to Tony. OMAP4: clock: Add CPU local timer clock node. OMAP: Fix sparse warnings in l3 error handler. Are you targeting these for 3.1-rc ? - Paul -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/8] OMAP3/4: Misc fixes and clean-up
On Saturday 24 September 2011 12:01 PM, Paul Walmsley wrote: Hi Santosh On Sat, 24 Sep 2011, Santosh Shilimkar wrote: On Thursday 08 September 2011 10:51 AM, Santosh Shilimkar wrote: The series contains few fixes and clean-up for OMAP. Briefly, - HWMOD fix for the address space count - Improving the L3 register accesses - Bug fix in the L3 error handler - Sparce warning and indentation fixes in L3 error handler - Print master id in case of L3 custom errors for better debug. - Adding local time clock node for the CPUfreq and time re-calibration - Fix in the address overlap for emif and emulation domain. The series is tested on OMAP4430 SDP and OMAP4430 beagle and SDP. The following changes since commit c6a389f123b9f68d605bb7e0f9b32ec1e3e14132: Linux 3.1-rc4 (2011-08-28 21:16:01 -0700) are available in the git repository at: git://gitorious.org/omap-sw-develoment/linux-omap-dev.git v3.1-rc4-omap-misc I need your ack on below two patches so that I can re-base them and send a pull request to Tony. OMAP4: clock: Add CPU local timer clock node. OMAP: Fix sparse warnings in l3 error handler. Are you targeting these for 3.1-rc ? Nope. It's for 3.2 merge window. As such, the series doesn't have any major regression fixes which should make it before 3.2 Regards Santosh -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/5 v11] arm: omap: usb: ehci and ohci hwmod structures for omap3
On Fri, 23 Sep 2011, Munegowda, Keshava wrote:
On Thu, Sep 22, 2011 at 11:31 PM, Paul Walmsley p...@pwsan.com wrote:
On Thu, 22 Sep 2011, Keshava Munegowda wrote:
4. usb_tll_hs hwmod of usbhs with the TLL base address and irq.
Signed-off-by: Keshava Munegowda keshava_mgo...@ti.com
Reviewed-by: Partha Basak part...@india.ti.com
---
arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 271
1 files changed, 271 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
index 59fdb9f..d79f728 100644
--- a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
+static struct omap_hwmod_ocp_if omap34xx_f128m_cfg__usb_host_hs = {
+ .clk = usbhost_120m_fck,
This doesn't look right. This is an interface structure record, so it
should be associated with an interface clock. Is the hardware really
using the functional clock as the interface clock? Or, as seems more
likely...
Agreed, how about:
main clock: usbhost_120m_fck
optional f clock: usbhost_48m_fck
Assuming the interface clock is enabled, which one of these clocks is
needed for UHH register accesses to complete successfully?
interface clock: usbhost_ick.
+ .user = OCP_USER_MPU,
+ .flags = OCPIF_SWSUP_IDLE,
... is this just a hack? OCPIF_SWSUP_IDLE is intended to work around
hardware autoidle bugs only. Are you sure this shouldn't be defined as an
optional clock instead?
yes ! it was causeing resets, hence you this flag.
usbhost_120m_fck is not an interface clock. That is probably what was
causing the problem you describe.
+static struct omap_hwmod omap34xx_usb_host_hs_hwmod = {
+ .name = usb_host_hs,
+ .class = omap34xx_usb_host_hs_hwmod_class,
+ .main_clk = usbhost_ick,
Is this really the main clock? The main clock is the clock that drives
the register logic in the IP block. Looks to me, based on the integration
document in the 34xx TRM vZR, that this module has a functional clock. In
general, the only time that the main_clk should be an interface clock is
when the clock is a combined interface and functional clock. The mailbox
IP block is a classic example.
As I mentioned above; I can make
main clock: usbhost_120m_fck
optional f clock: usbhost_48m_fck
interface clock: usbhost_ick.
do you agree?
The interface clock should definitely be usbhost_ick, no doubt about it.
But, as I mentioned above, to determine which functional clock should be
the main clock, you first need to know which of those two clocks need to
be enabled for register accesses to that module to succeed.
I did this work a few years ago, by trial and error since it was largely
undocumented. It was needed since the OMAP3 clk_enable() code waits for
the PRCM to request that the IP block exit idle before returning.
You might want to take a look at arch/arm/mach-omap2/clock3xxx_data.c.
+static struct omap_hwmod omap34xx_usb_tll_hs_hwmod = {
+ .name = usb_tll_hs,
+ .class = omap34xx_usb_tll_hs_hwmod_class,
+ .mpu_irqs = omap34xx_usb_tll_hs_irqs,
+ .main_clk = usbtll_ick,
Is this really the main clock? The main clock is the clock that drives
the register logic in the IP block. Looks to me, based on the integration
document in the 34xx TRM vZR, that this module has a functional clock.
I can make
main clock: usbtll_fck
interface clock: usbtll_ick.
do you agree?
Doesn't that make more sense?
- Paul
Re: [PATCH 0/8] OMAP3/4: Misc fixes and clean-up
Hi On Sat, 24 Sep 2011, Santosh Shilimkar wrote: On Saturday 24 September 2011 12:01 PM, Paul Walmsley wrote: Hi Santosh On Sat, 24 Sep 2011, Santosh Shilimkar wrote: On Thursday 08 September 2011 10:51 AM, Santosh Shilimkar wrote: I need your ack on below two patches so that I can re-base them and send a pull request to Tony. OMAP4: clock: Add CPU local timer clock node. OMAP: Fix sparse warnings in l3 error handler. Are you targeting these for 3.1-rc ? Nope. It's for 3.2 merge window. As such, the series doesn't have any major regression fixes which should make it before 3.2 In that case, patches 1 and 7 should go in through me. The rest should go via Tony. So you can just drop 1 and 7 from your branch, I'll pull those off the list. Some comments though: Looks like you need to repost patch 1 due to comments from Benoît? Also, have the autogeneration scripts been updated for patch 7? ... As far as patch 5 goes, you don't need my ack on that one, since I'm not the maintainer or original author of that code. But feel free to add a Reviewed-by:. I also tested the two L3 files with sparse and they are clean now. Thanks very much for taking the initiative on this; I personally appreciate it quite a bit, and I think having clean code increases our credibility with upstream maintainers. - Paul
Re: [PATCH 2/6] OMAP4: Clock: Associate clocks for OMAP temperature sensor
On Fri, 23 Sep 2011, J, KEERTHY wrote:
On Fri, Sep 23, 2011 at 11:28 AM, Paul Walmsley p...@pwsan.com wrote:
On Fri, 23 Sep 2011, J, KEERTHY wrote:
On Fri, Sep 23, 2011 at 10:48 AM, Paul Walmsley p...@pwsan.com wrote:
On Thu, 22 Sep 2011, Keerthy wrote:
---
arch/arm/mach-omap2/clock44xx_data.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/clock44xx_data.c
b/arch/arm/mach-omap2/clock44xx_data.c
index 946bf04..c51e513 100644
--- a/arch/arm/mach-omap2/clock44xx_data.c
+++ b/arch/arm/mach-omap2/clock44xx_data.c
@@ -3185,9 +3185,9 @@ static struct omap_clk omap44xx_clks[] = {
CLK(NULL, aes2_fck, aes2_fck,
CK_443X),
CLK(NULL, aess_fck, aess_fck,
CK_443X),
CLK(NULL, bandgap_fclk, bandgap_fclk,
CK_443X),
- CLK(NULL, bandgap_ts_fclk, bandgap_ts_fclk,
CK_446X),
+ CLK(omap4460plus_scm.0, fck, bandgap_ts_fclk,
CK_446X),
CLK(NULL, des3des_fck, des3des_fck,
CK_443X),
- CLK(NULL, div_ts_ck, div_ts_ck,
CK_446X),
+ CLK(omap4460plus_scm.0, div_ck,
div_ts_ck, CK_446X),
Clearly this device is incorrectly named. You're setting up a clkdev
entry that's marked as being valid for OMAP4430, but your device is
called
omap4460plus_scm. They can't both be right...
This is addressed in Patch 06.
How does patch 6 address it?
I am not sure i interpreted the comment right. These clock nodes are specific
to
OMAP4460 and are tagged CK_446X hence the device name omap4460plus_scm.0
Looking back over this, I misread the intention of this patch - sorry
about that. The right thing to do in this clock file depends on how the
rest of the code is structured; will write some followup comments about
that.
- Paul
Re: [PATCH 0/8] OMAP3/4: Misc fixes and clean-up
On Saturday 24 September 2011 01:06 PM, Paul Walmsley wrote: Hi On Sat, 24 Sep 2011, Santosh Shilimkar wrote: On Saturday 24 September 2011 12:01 PM, Paul Walmsley wrote: Hi Santosh On Sat, 24 Sep 2011, Santosh Shilimkar wrote: On Thursday 08 September 2011 10:51 AM, Santosh Shilimkar wrote: I need your ack on below two patches so that I can re-base them and send a pull request to Tony. OMAP4: clock: Add CPU local timer clock node. OMAP: Fix sparse warnings in l3 error handler. Are you targeting these for 3.1-rc ? Nope. It's for 3.2 merge window. As such, the series doesn't have any major regression fixes which should make it before 3.2 In that case, patches 1 and 7 should go in through me. The rest should go via Tony. So you can just drop 1 and 7 from your branch, I'll pull those off the list. Will do. Some comments though: Looks like you need to repost patch 1 due to comments from Benoît? Also, have the autogeneration scripts been updated for patch 7? Ok. Will post updated patch1. For the patch 7, I will align with Benoit on the autogen script. It has some differences with mainline OMAP4 clock data file. ... As far as patch 5 goes, you don't need my ack on that one, since I'm not the maintainer or original author of that code. But feel free to add a Reviewed-by:. I also tested the two L3 files with sparse and they are clean now. Thanks very much for taking the initiative on this; I personally appreciate it quite a bit, and I think having clean code increases our credibility with upstream maintainers. Actually I wanted you to have a look to ensure that we addressed the all sparce warnings. Will add your reviewed by on that patch. Couldn't agree more on the clean code remark. Regards Santosh -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/6] OMAP4460: Temperature sensor data
On Fri, 23 Sep 2011, J, KEERTHY wrote: On Fri, Sep 23, 2011 at 11:33 AM, Paul Walmsley p...@pwsan.com wrote: On Thu, 22 Sep 2011, Keerthy wrote: @@ -0,0 +1,175 @@ +/* + * OMAP system control module header file + * + * Copyright (C) 2011 Texas Instruments Incorporated - http://www.ti.com/ + * Author: J Keerthy j-keer...@ti.com + * + * This program is free software; you can redistribute it and/or + * modify it under the terms of the GNU General Public License + * version 2 as published by the Free Software Foundation. + * + * This program is distributed in the hope that it will be useful, but + * WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU + * General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA + * 02110-1301 USA + * + */ + +#ifndef __ARCH_ARM_PLAT_OMAP_INCLUDE_PLAT_TEMPERATURE_SENSOR_H +#define __ARCH_ARM_PLAT_OMAP_INCLUDE_PLAT_TEMPERATURE_SENSOR_H You're also missing important #includes here for things like mutexes and kernel types that you use later on in the file. Those header files are included in c files. And how does that affect my comment? +#define OMAP_ADC_START_VALUE 530 +#define OMAP_ADC_END_VALUE 923 Are these OMAP4460, OMAP4xxx, or OMAP2+ specific? OMAP4460. I will pass even these values through pdata since they differ from platform to platform. So then the macro names need to include OMAP4460 or whatever SoC they are first valid for. + +/** + * struct omap4460plus_scm_dev_attr - device attributes for scm There are loads of references to 'omap4460plus' when it seems to me that much of this driver should also apply to OMAP4430 also. Shouldn't this driver be named something like 'omap4430plus_scm' or even better 'omap4_scm' ? This is used by hwmod. Hence keeping it in the header file. Did you even read my comment before responding? - Paul
Re: [PATCH v2 1/8] OMAP: hwmod: Fix the addr spaces, irq, dma count APIs.
Paul, On Sunday 18 September 2011 02:28 PM, Santosh wrote: On Friday 16 September 2011 09:10 PM, Cousson, Benoit wrote: Hi Sricharan, On 9/9/2011 6:02 PM, R, Sricharan wrote: The address spaces, irqs and dma reqs count API returns the number of corresponding entries in a hwmod including a additional null value or a -1 terminator in the structure introduced recently. More information here: 212738a4 (omap_hwmod: use a terminator record with omap_hwmod_mpu_irqs arrays) 78183f3f (omap_hwmod: use a null structure record to terminate omap_hwmod_addr_space arrays) bc614958 (omap_hwmod: use a terminator record with omap_hwmod_dma_info arrays) The devices which have multiple hwmods and use device_build_ss are broken with this, as their resources are populated with a extra null value, subsequently the probe fails. So fix the API not to include the array terminator in the count. Signed-off-by: sricharanr.sricha...@ti.com Signed-off-by: Santosh Shilimkarsantosh.shilim...@ti.com Cc: Benoit Coussonb-cous...@ti.com Cc: Paul Walmsleyp...@pwsan.com Cc: Kevin Hilmankhil...@ti.com It would have been nice to give me the credit for the bug report on the other functions, but otherwise: Sure. Will add reported-by of yours. Acked-by: Benoit Cousson b-cous...@ti.com Thanks And I still prefer the return i - 1 :-) Let's do i-1 as you prefer. Maintainer always have final say !! Here is the updated patch with i-1 as agreed with Benoit. Also attaching it in case mailer eats spaces. From c55f38512e1471b8a9405c2cb45d9377e0c45999 Mon Sep 17 00:00:00 2001 From: sricharan r.sricha...@ti.com Date: Wed, 21 Sep 2011 16:08:46 +0530 Subject: [PATCH 1/8] OMAP: hwmod: Fix the addr space, irq, dma count APIs The address spaces, irqs and dma reqs count API returns the number of corresponding entries in a hwmod including a additional null value or a -1 terminator in the structure introduced recently. More information here: - 212738a4 (omap_hwmod: use a terminator record with omap_hwmod_mpu_irqs arrays) - 78183f3f (omap_hwmod: use a null structure record to terminate omap_hwmod_addr_space arrays) - bc614958 (omap_hwmod: use a terminator record with omap_hwmod_dma_info arrays) The issue with irqs and dma info was originally reported by Benoit Cousson. The devices which have multiple hwmods and use device_build_ss are broken with this, as their resources are populated with a extra null value, subsequently the probe fails. So fix the API not to include the array terminator in the count. Reported-by: Benoit Cousson b-cous...@ti.com Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com Signed-off-by: sricharan r.sricha...@ti.com Acked: Benoit Cousson b-cous...@ti.com --- arch/arm/mach-omap2/omap_hwmod.c |6 +++--- 1 files changed, 3 insertions(+), 3 deletions(-) diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-omap2/omap_hwmod.c index 84cc0bd..f396c83 100644 --- a/arch/arm/mach-omap2/omap_hwmod.c +++ b/arch/arm/mach-omap2/omap_hwmod.c @@ -749,7 +749,7 @@ static int _count_mpu_irqs(struct omap_hwmod *oh) ohii = oh-mpu_irqs[i++]; } while (ohii-irq != -1); - return i; + return i-1; } /** @@ -772,7 +772,7 @@ static int _count_sdma_reqs(struct omap_hwmod *oh) ohdi = oh-sdma_reqs[i++]; } while (ohdi-dma_req != -1); - return i; + return i-1; } /** @@ -795,7 +795,7 @@ static int _count_ocp_if_addr_spaces(struct omap_hwmod_ocp_if *os) mem = os-addr[i++]; } while (mem-pa_start != mem-pa_end); - return i; + return i-1; } /** -- 1.7.4.1 From c55f38512e1471b8a9405c2cb45d9377e0c45999 Mon Sep 17 00:00:00 2001 From: sricharan r.sricha...@ti.com Date: Wed, 21 Sep 2011 16:08:46 +0530 Subject: [PATCH 1/8] OMAP: hwmod: Fix the addr space, irq, dma count APIs The address spaces, irqs and dma reqs count API returns the number of corresponding entries in a hwmod including a additional null value or a -1 terminator in the structure introduced recently. More information here: - 212738a4 (omap_hwmod: use a terminator record with omap_hwmod_mpu_irqs arrays) - 78183f3f (omap_hwmod: use a null structure record to terminate omap_hwmod_addr_space arrays) - bc614958 (omap_hwmod: use a terminator record with omap_hwmod_dma_info arrays) The issue with irqs and dma info was originally reported by Benoit Cousson. The devices which have multiple hwmods and use device_build_ss are broken with this, as their resources are populated with a extra null value, subsequently the probe fails. So fix the API not to include the array terminator in the count. Reported-by: Benoit Cousson b-cous...@ti.com Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com Signed-off-by: sricharan r.sricha...@ti.com Acked: Benoit Cousson b-cous...@ti.com --- arch/arm/mach-omap2/omap_hwmod.c |6 +++--- 1 files changed, 3 insertions(+), 3 deletions(-) diff --git a/arch/arm/mach-omap2/omap_hwmod.c
Re: [PATCH 3/6] OMAP4460: Temperature sensor data
On Fri, 23 Sep 2011, J, KEERTHY wrote: On Fri, Sep 23, 2011 at 11:33 AM, Paul Walmsley p...@pwsan.com wrote: On Thu, 22 Sep 2011, Keerthy wrote: diff --git a/arch/arm/mach-omap2/temp_sensor4460_data.c b/arch/arm/mach-omap2/temp_sensor4460_data.c new file mode 100644 index 000..2804615 --- /dev/null +++ b/arch/arm/mach-omap2/temp_sensor4460_data.c Is there some reason why this shouldn't go into drivers/ in some form? This is used by mach-omap2. Why does something in mach-omap2 need this data? diff --git a/arch/arm/plat-omap/include/plat/scm.h b/arch/arm/plat-omap/include/plat/scm.h new file mode 100644 index 000..47aa38f --- /dev/null +++ b/arch/arm/plat-omap/include/plat/scm.h If this is being used by a driver, then this header file should go into the appropriate drivers/ subdirectory. If it is being used by code in arch/arm/mach-omap2, then please use the existing arch/arm/mach-omap2/control.h instead. The header file has structures used both by drivers/ and mach-omap. So kept it in plat-omap. The point is, if there are structure definitions and macros that are only needed by code in drivers/, then those should be split off into a separate file and placed in drivers/. Similarly, if there are elements of this file that are only used in mach-omap2/, then those should go into mach-omap2/control.h. About the only part off the top of my head that should go into a plat-omap header file should be the dev_attr structure. And it's debatable whether this driver even needs a dev_attr, or whether all this data should just go into an omap4460_scm.c MFD driver that uses a bunch of common code for the parts that are shared with 4430, etc. Do you have any views on this issue? - Paul
[GIT PULL] OMAP: Few sparse/bug fixes and clean-up for 3.2
Tony, Please pull few OMAP sparse/bug fixes and clean-up for 3.2 Thnaks, Santosh The following changes since commit b6fd41e29dea9c6753b1843a77e50433e6123bcb: Linux 3.1-rc6 (2011-09-12 14:02:02 -0700) are available in the git repository at: git://gitorious.org/omap-sw-develoment/linux-omap-dev.git for_3_2/omap_misc Santosh Shilimkar (1): OMAP4: Fix the emif and dmm virtual mapping Todd Poynor (2): OMAP: Improve register access in L3 Error handler. OMAP: Fix a BUG in l3 error handler. sricharan (3): OMAP: Fix indentation issues in l3 error handler. OMAP: Fix sparse warnings in l3 error handler. OMAP: Print Initiator name for l3 custom error. arch/arm/mach-omap2/omap_l3_noc.c| 130 ++-- arch/arm/mach-omap2/omap_l3_noc.h| 224 +++--- arch/arm/mach-omap2/omap_l3_smx.c| 91 +++--- arch/arm/mach-omap2/omap_l3_smx.h| 164 arch/arm/plat-omap/include/plat/io.h |4 +- 5 files changed, 322 insertions(+), 291 deletions(-) -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v7 00/26] gpio/omap: driver cleanup and fixes
On Saturday 24 September 2011 09:26 AM, DebBarma, Tarun Kanti wrote:
[...]
After debugging this myself a bit, here's what I think may be going on.
This may not be the only problem but here's at least one of them.
First, debounce clocks are disabled in the runtime_suspend callback.
When a GPIO is freed and it's the last one in the bank, bank-mod_usage
goes to zero.
After that, pm_runtime_put_sync() is called, which will trigger the
driver's -runtime_suspend callback. The -runtime_suspend() callback
checks bank-mod_usage as well, and if zero, doesn't do anything
(notably, it doesn't disable debounce clocks.)
I need some clarification in reproducing/testing the fix on OMAP3430SDP.
The first thing I am trying to verify is the code flow of suspend.
1) With no debounce clock enabled, when I enable UART timeouts, I
automatically see
system going to retention. That is I don't have to type echo mem
/sys/power/state
echo 5 /sys/devices/platform/omap/omap_uart.0/sleep_timeout
echo 5 /sys/devices/platform/omap/omap_uart.1/sleep_timeout
echo 5 /sys/devices/platform/omap/omap_uart.2/sleep_timeout
2) I am do not see the print in omap_gpio_suspend/resume(), but I see
the print in
*_prepare_for_idle()/*_resume_after_idle().
Hmmm,
This is mostly happening because you are missing a below
fix from Kevin in the branch you are testing with.
http://www.mail-archive.com/linux-omap@vger.kernel.org/msg54927.html
{OMAP: omap_device: fix !CONFIG_SUSPEND case in _noirq handlers}
If you rebase, your branch against 3.1-rc6, you should already
have this fix. Commit {126caf1376e7}
Regards
Santosh
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/6] OMAP4460: Temperature sensor data
On Sat, Sep 24, 2011 at 1:29 PM, Paul Walmsley p...@pwsan.com wrote: On Fri, 23 Sep 2011, J, KEERTHY wrote: On Fri, Sep 23, 2011 at 11:33 AM, Paul Walmsley p...@pwsan.com wrote: On Thu, 22 Sep 2011, Keerthy wrote: diff --git a/arch/arm/mach-omap2/temp_sensor4460_data.c b/arch/arm/mach-omap2/temp_sensor4460_data.c new file mode 100644 index 000..2804615 --- /dev/null +++ b/arch/arm/mach-omap2/temp_sensor4460_data.c Is there some reason why this shouldn't go into drivers/ in some form? This is used by mach-omap2. Why does something in mach-omap2 need this data? The scm hwmod is populating the pointer to the register set which is specific to OMAP4460. So i have kept the OMAP4460 specific data file in mach-omap2. diff --git a/arch/arm/plat-omap/include/plat/scm.h b/arch/arm/plat-omap/include/plat/scm.h new file mode 100644 index 000..47aa38f --- /dev/null +++ b/arch/arm/plat-omap/include/plat/scm.h If this is being used by a driver, then this header file should go into the appropriate drivers/ subdirectory. If it is being used by code in arch/arm/mach-omap2, then please use the existing arch/arm/mach-omap2/control.h instead. The header file has structures used both by drivers/ and mach-omap. So kept it in plat-omap. The point is, if there are structure definitions and macros that are only needed by code in drivers/, then those should be split off into a separate file and placed in drivers/. Similarly, if there are elements of this file that are only used in mach-omap2/, then those should go into mach-omap2/control.h. About the only part off the top of my head that should go into a plat-omap header file should be the dev_attr structure. And it's debatable whether this driver even needs a dev_attr, or whether all this data should just go into an omap4460_scm.c MFD driver that uses a bunch of common code for the parts that are shared with 4430, etc. Do you have any views on this issue? There can be a common omap4_scm.c driver. The temperature sensor is different from OMAP4430 and OMAP4460. So keeping the temperature sensor as omap4460plus. Coming to structure definitions. pdata structure is needed both by mach-omap device file to populate it and also by the driver t extract it. So keeping all of the structure definitions in one header file in plat_omap. My question is which is the ideal place to keep the common structure definition like pdata? Since the temperature sensor does not have a separate hwmod of its own i feel there is a necessity of dev_attr. - Paul -- Regards and Thanks, Keerthy -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v7 00/26] gpio/omap: driver cleanup and fixes
Santosh, Kevin,
[...]
After that, pm_runtime_put_sync() is called, which will trigger the
driver's -runtime_suspend callback. The -runtime_suspend() callback
checks bank-mod_usage as well, and if zero, doesn't do anything
(notably, it doesn't disable debounce clocks.)
I need some clarification in reproducing/testing the fix on OMAP3430SDP.
The first thing I am trying to verify is the code flow of suspend.
1) With no debounce clock enabled, when I enable UART timeouts, I
automatically see
system going to retention. That is I don't have to type echo mem
/sys/power/state
echo 5 /sys/devices/platform/omap/omap_uart.0/sleep_timeout
echo 5 /sys/devices/platform/omap/omap_uart.1/sleep_timeout
echo 5 /sys/devices/platform/omap/omap_uart.2/sleep_timeout
2) I am do not see the print in omap_gpio_suspend/resume(), but I see
the print in
*_prepare_for_idle()/*_resume_after_idle().
Hmmm,
This is mostly happening because you are missing a below
fix from Kevin in the branch you are testing with.
http://www.mail-archive.com/linux-omap@vger.kernel.org/msg54927.html
{OMAP: omap_device: fix !CONFIG_SUSPEND case in _noirq handlers}
If you rebase, your branch against 3.1-rc6, you should already
have this fix. Commit {126caf1376e7}
Yes, this patch was missing in Kevin's branch and was
causing the suspend issue.
As pointed out by Kevin, debounce clock was not getting disabled.
In my testing I was somehow grepping CORE power domain instead
of PER power domain and hence missed it. The fix for the debounce
clock issue is at the end of the email.
- Have re-based the for_3.2/gpio-cleanup branch against 3.1-rc6.
- Dropped [PATCH 26/26] gpio/omap: add dbclk aliases for all gpio modules
as suggested by Kevin since it's already taken care by hwmod.
- Added the debounce clock fix in the end.
With above, PER is hitting low power state in Suspend and Idle path.
Have pushed a branch at below URL with mentioned changes.
git://gitorious.org/omap-sw-develoment/linux-omap-dev.git
for_3.2/kevin/gpio-cleanup
Regards,
Tarun
From 5d9a97197ea5426fc79b7a47dd0fd9c6b6ea Mon Sep 17 00:00:00 2001
From: Tarun Kanti DebBarma tarun.ka...@ti.com
Date: Sat, 24 Sep 2011 13:32:32 +0530
Subject: [PATCH] gpio/omap: fix debounce clock handling
GPIO debounce clock can gate the PER power domain transition
and needs to be disabled in GPIO driver suspend.
The debounce clock is not getting disabled in runtime_suspend
callback because of an un-necessary bank-mod_usage check.
In omap_gpio_suspend/resume too, there is no need to do
any operation if the gpio bank is not used.
Remove the un-necessary bank-mod_usage check from
suspend callbacks.
Thanks to Kevin Hilman for pointing out this issue.
Signed-off-by: Tarun Kanti DebBarma tarun.ka...@ti.com
Cc: Kevin Hilman khil...@ti.com
Cc: Santosh Shilimkar santosh.shilim...@ti.com
---
drivers/gpio/gpio-omap.c | 12 ++--
1 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/gpio/gpio-omap.c b/drivers/gpio/gpio-omap.c
index c597303..349e774 100644
--- a/drivers/gpio/gpio-omap.c
+++ b/drivers/gpio/gpio-omap.c
@@ -1107,6 +1107,9 @@ static int omap_gpio_suspend(struct device *dev)
void __iomem *wake_status;
unsigned long flags;
+ if (!bank-mod_usage || !bank-loses_context)
+ return 0;
+
if (!bank-regs-wkup_en || !bank-suspend_wakeup)
return 0;
@@ -1128,6 +1131,9 @@ static int omap_gpio_resume(struct device *dev)
void __iomem *base = bank-base;
unsigned long flags;
+ if (!bank-mod_usage || !bank-loses_context)
+ return 0;
+
if (!bank-regs-wkup_en || !bank-saved_wakeup)
return 0;
@@ -1151,9 +1157,6 @@ static int omap_gpio_runtime_suspend(struct device *dev)
int j;
unsigned long flags;
- if (!bank-mod_usage)
- return 0;
-
spin_lock_irqsave(bank-lock, flags);
/*
* If going to OFF, remove triggering for all
@@ -1199,9 +1202,6 @@ static int omap_gpio_runtime_resume(struct device *dev)
int j;
unsigned long flags;
- if (!bank-mod_usage)
- return 0;
-
spin_lock_irqsave(bank-lock, flags);
for (j = 0; j hweight_long(bank-dbck_enable_mask); j++)
clk_enable(bank-dbck);
--
1.7.0.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/4] iommu: Prevent oops in iommu_get() and while arch_iommu is in use
On Tue, Mar 29, 2011 at 8:32 AM, Laurent Pinchart laurent.pinch...@ideasonboard.com wrote: I think that Sakari's patches correcty fix the problems he noticed. However, they won't fix one basic issue, which is that the iommu2 module won't be automatically pulled in when the omap3isp module is loaded. The omap3isp driver will then fail to probe the device. That's better than crashing though. One possible solution for that is to turn the tristate option for iommu2 into a bool option. I've also read a couple of times that the kernel provides a standard iommu API. Maybe switching to it would help. I'm attempting to get support for the Gumstix Caspa image sensor (based on mt9v032) working with the 3.0 release. I'm running into the issue described above -- the omap3-isp module loads but fails to probe the device. I've tried the tristate-bool option change and find that it does allow me to proceed further, but the omap3-isp module is no longer loaded automatically when I call omap3_init_camera in the board file. I have to manually modprobe it. I then see the sensor module successfully probed and the video devices created (though not functioning yet). Are you aware of a better way to do this? I see lots of patches for iommu since this thread. Would I be better off waiting for 3.1 and trying that, or will final resolution of this issue come even later? Best regards, Steve -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 3/6] iommu/msm: announce supported page sizes
On Fri, Sep 16, 2011 at 08:51:43PM +0300, Ohad Ben-Cohen wrote: Let the IOMMU core know we support 4KiB, 64KiB, 1MiB and 16MiB page sizes. This way the IOMMU core can split any arbitrary-sized physically contiguous regions (that it needs to map) as needed. Signed-off-by: Ohad Ben-Cohen o...@wizery.com Cc: David Brown dav...@codeaurora.org Cc: Stepan Moskovchenko step...@codeaurora.org --- drivers/iommu/msm_iommu.c |8 +++- Acked-by: David Brown dav...@codeaurora.org -- Sent by an employee of the Qualcomm Innovation Center, Inc. The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
