* [PATCH 01/25] ARM: mm: Add strongly ordered descriptor support.
2011-09-04 13:54 [PATCH 00/25] OMAP4: PM: suspend, CPU-hotplug and CPUilde support Santosh Shilimkar
@ 2011-09-04 13:54 ` Santosh Shilimkar
2011-09-13 20:23 ` Tony Lindgren
2011-09-04 13:54 ` [PATCH 02/25] OMAP4: Redefine mandatory barriers for OMAP to include interconnect barriers Santosh Shilimkar
` (26 subsequent siblings)
27 siblings, 1 reply; 119+ messages in thread
From: Santosh Shilimkar @ 2011-09-04 13:54 UTC (permalink / raw)
To: linux-arm-kernel
On certain architectures, there might be a need to mark certain
addresses with strongly ordered memory attributes to avoid ordering
issues at the interconnect level.
On OMAP4, the asynchronous bridge buffers can only be drained
with strongly ordered accesses and hence the need to mark the
memory strongly ordered.
Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
Signed-off-by: Woodruff Richard <r-woodruff2@ti.com>
Cc: Russell King <rmk+kernel@arm.linux.org.uk>
---
arch/arm/include/asm/mach/map.h | 1 +
arch/arm/include/asm/pgtable.h | 3 +++
arch/arm/mm/mmu.c | 8 ++++++++
3 files changed, 12 insertions(+), 0 deletions(-)
diff --git a/arch/arm/include/asm/mach/map.h b/arch/arm/include/asm/mach/map.h
index d2fedb5..b36f365 100644
--- a/arch/arm/include/asm/mach/map.h
+++ b/arch/arm/include/asm/mach/map.h
@@ -29,6 +29,7 @@ struct map_desc {
#define MT_MEMORY_NONCACHED 11
#define MT_MEMORY_DTCM 12
#define MT_MEMORY_ITCM 13
+#define MT_MEMORY_SO 14
#ifdef CONFIG_MMU
extern void iotable_init(struct map_desc *, int);
diff --git a/arch/arm/include/asm/pgtable.h b/arch/arm/include/asm/pgtable.h
index 5750704..f1956b2 100644
--- a/arch/arm/include/asm/pgtable.h
+++ b/arch/arm/include/asm/pgtable.h
@@ -232,6 +232,9 @@ extern pgprot_t pgprot_kernel;
#define pgprot_writecombine(prot) \
__pgprot_modify(prot, L_PTE_MT_MASK, L_PTE_MT_BUFFERABLE)
+#define pgprot_stronglyordered(prot) \
+ __pgprot_modify(prot, L_PTE_MT_MASK, L_PTE_MT_UNCACHED)
+
#ifdef CONFIG_ARM_DMA_MEM_BUFFERABLE
#define pgprot_dmacoherent(prot) \
__pgprot_modify(prot, L_PTE_MT_MASK, L_PTE_MT_BUFFERABLE | L_PTE_XN)
diff --git a/arch/arm/mm/mmu.c b/arch/arm/mm/mmu.c
index 594d677..ea9c9f3 100644
--- a/arch/arm/mm/mmu.c
+++ b/arch/arm/mm/mmu.c
@@ -273,6 +273,14 @@ static struct mem_type mem_types[] = {
.prot_l1 = PMD_TYPE_TABLE,
.domain = DOMAIN_KERNEL,
},
+ [MT_MEMORY_SO] = {
+ .prot_pte = L_PTE_PRESENT | L_PTE_YOUNG | L_PTE_DIRTY |
+ L_PTE_MT_UNCACHED,
+ .prot_l1 = PMD_TYPE_TABLE,
+ .prot_sect = PMD_TYPE_SECT | PMD_SECT_AP_WRITE | PMD_SECT_S |
+ PMD_SECT_UNCACHED | PMD_SECT_XN,
+ .domain = DOMAIN_KERNEL,
+ },
};
const struct mem_type *get_mem_type(unsigned int type)
--
1.7.4.1
^ permalink raw reply related [flat|nested] 119+ messages in thread* [PATCH 01/25] ARM: mm: Add strongly ordered descriptor support.
2011-09-04 13:54 ` [PATCH 01/25] ARM: mm: Add strongly ordered descriptor support Santosh Shilimkar
@ 2011-09-13 20:23 ` Tony Lindgren
2011-09-14 5:36 ` Shilimkar, Santosh
0 siblings, 1 reply; 119+ messages in thread
From: Tony Lindgren @ 2011-09-13 20:23 UTC (permalink / raw)
To: linux-arm-kernel
* Santosh Shilimkar <santosh.shilimkar@ti.com> [110904 06:22]:
> On certain architectures, there might be a need to mark certain
> addresses with strongly ordered memory attributes to avoid ordering
> issues at the interconnect level.
This is something Russell needs to look.
You might want to also read the mailing list archives regarding the
strongly ordered access.
Basically it still won't guarantee that the write gets to the
device, only a read back from the device in question guarantees
that at the bus level.
Regards,
Tony
^ permalink raw reply [flat|nested] 119+ messages in thread
* [PATCH 01/25] ARM: mm: Add strongly ordered descriptor support.
2011-09-13 20:23 ` Tony Lindgren
@ 2011-09-14 5:36 ` Shilimkar, Santosh
0 siblings, 0 replies; 119+ messages in thread
From: Shilimkar, Santosh @ 2011-09-14 5:36 UTC (permalink / raw)
To: linux-arm-kernel
On Wed, Sep 14, 2011 at 1:53 AM, Tony Lindgren <tony@atomide.com> wrote:
> * Santosh Shilimkar <santosh.shilimkar@ti.com> [110904 06:22]:
>> On certain architectures, there might be a need to mark certain
>> addresses with strongly ordered memory attributes to avoid ordering
>> issues at the interconnect level.
>
> This is something Russell needs to look.
>
> You might want to also read the mailing list archives regarding the
> strongly ordered access.
>
> Basically it still won't guarantee that the write gets to the
> device, only a read back from the device in question guarantees
> that at the bus level.
>
Russell has already seen this. I have sent this patches to Russell
before adding them
in the queue.
This is different. There is a BUG in asynchronous bridges on OMAP44XX
devices and
that's the reason it' s needed.
Regards
Santosh
^ permalink raw reply [flat|nested] 119+ messages in thread
* [PATCH 02/25] OMAP4: Redefine mandatory barriers for OMAP to include interconnect barriers.
2011-09-04 13:54 [PATCH 00/25] OMAP4: PM: suspend, CPU-hotplug and CPUilde support Santosh Shilimkar
2011-09-04 13:54 ` [PATCH 01/25] ARM: mm: Add strongly ordered descriptor support Santosh Shilimkar
@ 2011-09-04 13:54 ` Santosh Shilimkar
2011-09-13 20:27 ` Tony Lindgren
2011-09-04 13:54 ` [PATCH 03/25] OMAP4: PM: Use custom omap_do_wfi() for suspend and default idle Santosh Shilimkar
` (25 subsequent siblings)
27 siblings, 1 reply; 119+ messages in thread
From: Santosh Shilimkar @ 2011-09-04 13:54 UTC (permalink / raw)
To: linux-arm-kernel
On OMAP4 SOC intecronnects has many write buffers in the async bridges
and they can be drained only with stongly ordered accesses.
There are two ports as below from MPU and both needs to be drained.
- MPU --> L3 T2ASYNC FIFO
- MPU --> DDR T2ASYNC FIFO
Without the interconnect barriers, many issues have been observed
leading to system freeze, CPU deadlocks, random crashes with
register accesses, synchronization loss on initiators operating
on both interconnect port simultaneously.
Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
Signed-off-by: Richard Woodruff <r-woodruff2@ti.com>
---
arch/arm/mach-omap2/Kconfig | 1 +
arch/arm/mach-omap2/Makefile | 3 +-
arch/arm/mach-omap2/include/mach/barriers.h | 48 ++++++++++++++++++++++
arch/arm/mach-omap2/include/mach/omap4-common.h | 9 ++++-
arch/arm/mach-omap2/omap4-common.c | 50 +++++++++++++++++++++++
arch/arm/mach-omap2/sleep44xx.S | 29 +++++++++++++
arch/arm/plat-omap/include/plat/sram.h | 1 +
arch/arm/plat-omap/sram.c | 47 +++++++++++++++------
8 files changed, 172 insertions(+), 16 deletions(-)
create mode 100644 arch/arm/mach-omap2/include/mach/barriers.h
create mode 100644 arch/arm/mach-omap2/sleep44xx.S
diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
index 57b66d5..62f45e8 100644
--- a/arch/arm/mach-omap2/Kconfig
+++ b/arch/arm/mach-omap2/Kconfig
@@ -50,6 +50,7 @@ config ARCH_OMAP4
select ARCH_HAS_OPP
select PM_OPP if PM
select USB_ARCH_HAS_EHCI
+ select ARCH_HAS_BARRIERS
comment "OMAP Core Type"
depends on ARCH_OMAP2
diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index f343365..42e4613 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -62,13 +62,14 @@ 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 sleep44xx.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
AFLAGS_sleep24xx.o :=-Wa,-march=armv6
AFLAGS_sleep34xx.o :=-Wa,-march=armv7-a$(plus_sec)
+AFLAGS_sleep44xx.o :=-Wa,-march=armv7-a$(plus_sec)
ifeq ($(CONFIG_PM_VERBOSE),y)
CFLAGS_pm_bus.o += -DDEBUG
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 0000000..aa72a33
--- /dev/null
+++ b/arch/arm/mach-omap2/include/mach/barriers.h
@@ -0,0 +1,48 @@
+/*
+ * OMAP memory barrier header.
+ *
+ * Copyright (C) 2011 Texas Instruments, Inc.
+ * Santosh Shilimkar <santosh.shilimkar@ti.com>
+ * Richard Woodruff <r-woodruff2@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., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
+ */
+
+#ifndef __MACH_BARRIERS_H
+#define __MACH_BARRIERS_H
+
+#include <linux/types.h>
+
+/* provide func ptr so to allow safe calling at any point */
+struct omap_bus_post_fns {
+ void (*sync)(void);
+};
+
+extern struct omap_bus_post_fns omap_bus_post;
+
+#ifdef CONFIG_ARCH_OMAP4
+static inline void bus_sync(void)
+{
+ omap_bus_post.sync();
+}
+#else
+static inline void bus_sync(void)
+{ }
+#endif
+
+#define rmb() dsb()
+#define wmb() do { dsb(); outer_sync(); bus_sync(); } while (0)
+#define mb() wmb()
+
+#endif /* __MACH_BARRIERS_H */
diff --git a/arch/arm/mach-omap2/include/mach/omap4-common.h b/arch/arm/mach-omap2/include/mach/omap4-common.h
index e4bd87619..26653f6 100644
--- a/arch/arm/mach-omap2/include/mach/omap4-common.h
+++ b/arch/arm/mach-omap2/include/mach/omap4-common.h
@@ -13,6 +13,10 @@
#ifndef OMAP_ARCH_OMAP4_COMMON_H
#define OMAP_ARCH_OMAP4_COMMON_H
+/* Used to implement memory barrier on DRAM path */
+#define OMAP4_DRAM_BARRIER_VA 0xfe600000
+
+#ifndef __ASSEMBLER__
/*
* wfi used in low power code. Directly opcode is used instead
* of instruction to avoid mulit-omap build break
@@ -32,6 +36,8 @@ extern void __iomem *gic_dist_base_addr;
extern void __init gic_init_irq(void);
extern void omap_smc1(u32 fn, u32 arg);
+extern void omap_bus_sync(void);
+extern unsigned long omap_get_dram_barrier_base(void);
#ifdef CONFIG_SMP
/* Needed for secondary core boot */
@@ -40,4 +46,5 @@ 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
-#endif
+#endif /* __ASSEMBLER__ */
+#endif /* OMAP_ARCH_OMAP4_COMMON_H */
diff --git a/arch/arm/mach-omap2/omap4-common.c b/arch/arm/mach-omap2/omap4-common.c
index 35ac3e5..4791370 100644
--- a/arch/arm/mach-omap2/omap4-common.c
+++ b/arch/arm/mach-omap2/omap4-common.c
@@ -15,9 +15,11 @@
#include <linux/init.h>
#include <linux/io.h>
#include <linux/platform_device.h>
+#include <linux/memblock.h>
#include <asm/hardware/gic.h>
#include <asm/hardware/cache-l2x0.h>
+#include <asm/mach/map.h>
#include <plat/irqs.h>
@@ -30,6 +32,54 @@ void __iomem *l2cache_base;
void __iomem *gic_dist_base_addr;
+static unsigned long dram_barrier_base;
+
+static void omap_bus_sync_noop(void)
+{ }
+
+struct omap_bus_post_fns omap_bus_post = {
+ .sync = omap_bus_sync_noop,
+};
+EXPORT_SYMBOL(omap_bus_post);
+
+unsigned long omap_get_dram_barrier_base(void)
+{
+ return dram_barrier_base;
+}
+
+static int __init omap_barriers_init(void)
+{
+ struct map_desc dram_io_desc[1];
+ phys_addr_t paddr;
+ u32 size;
+
+ if (!cpu_is_omap44xx())
+ return -ENODEV;
+
+ size = ALIGN(PAGE_SIZE, SZ_1M);
+ paddr = memblock_alloc(size, SZ_1M);
+ if (!paddr) {
+ pr_err("%s: failed to reserve 4 Kbytes\n", __func__);
+ return -ENOMEM;
+ }
+ memblock_free(paddr, size);
+ memblock_remove(paddr, size);
+
+ dram_io_desc[0].virtual = OMAP4_DRAM_BARRIER_VA;
+ dram_io_desc[0].pfn = __phys_to_pfn(paddr);
+ dram_barrier_base = dram_io_desc[0].virtual;
+ dram_io_desc[0].length = size;
+ dram_io_desc[0].type = MT_MEMORY_SO;
+
+ iotable_init(dram_io_desc, ARRAY_SIZE(dram_io_desc));
+ omap_bus_post.sync = omap_bus_sync;
+
+ pr_info("OMAP4: Map 0x%08llx to 0x%08lx for dram barrier\n",
+ (long long) paddr, dram_io_desc[0].virtual);
+
+ return 0;
+}
+core_initcall(omap_barriers_init);
void __init gic_init_irq(void)
{
diff --git a/arch/arm/mach-omap2/sleep44xx.S b/arch/arm/mach-omap2/sleep44xx.S
new file mode 100644
index 0000000..5406713
--- /dev/null
+++ b/arch/arm/mach-omap2/sleep44xx.S
@@ -0,0 +1,29 @@
+/*
+ * OMAP44xx sleep code.
+ *
+ * Copyright (C) 2011 Texas Instruments, Inc.
+ * Santosh Shilimkar <santosh.shilimkar@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/linkage.h>
+#include <asm/system.h>
+
+#include <mach/omap4-common.h>
+
+ENTRY(omap_bus_sync)
+ stmfd sp!, {lr}
+ /* SO write to drain of MPU-2-DDR T2ASYNC FIFO */
+ bl omap_get_dram_barrier_base
+ ldr r2, [r0]
+ str r2, [r0]
+ /* SO write to drain MPU-2-L3 T2ASYNC FIFO */
+ bl omap_get_sram_barrier_base
+ ldr r2, [r0]
+ str r2, [r0]
+ isb
+ ldmfd sp!, {pc}
+ENDPROC(omap_bus_sync)
diff --git a/arch/arm/plat-omap/include/plat/sram.h b/arch/arm/plat-omap/include/plat/sram.h
index f500fc3..a6000d4 100644
--- a/arch/arm/plat-omap/include/plat/sram.h
+++ b/arch/arm/plat-omap/include/plat/sram.h
@@ -15,6 +15,7 @@
#include <asm/fncpy.h>
extern void *omap_sram_push_address(unsigned long size);
+extern unsigned long omap_get_sram_barrier_base(void);
/* Macro to push a function to the internal SRAM, using the fncpy API */
#define omap_sram_push(funcp, size) ({ \
diff --git a/arch/arm/plat-omap/sram.c b/arch/arm/plat-omap/sram.c
index 363c91e..0d370be 100644
--- a/arch/arm/plat-omap/sram.c
+++ b/arch/arm/plat-omap/sram.c
@@ -76,6 +76,12 @@ static unsigned long omap_sram_start;
static unsigned long omap_sram_base;
static unsigned long omap_sram_size;
static unsigned long omap_sram_ceil;
+static unsigned long omap_barrier_base;
+
+unsigned long omap_get_sram_barrier_base(void)
+{
+ return omap_barrier_base;
+}
/*
* Depending on the target RAMFS firewall setup, the public usable amount of
@@ -185,24 +191,25 @@ static void __init omap_detect_sram(void)
omap_sram_ceil = omap_sram_base + omap_sram_size;
}
-static struct map_desc omap_sram_io_desc[] __initdata = {
- { /* .length gets filled in at runtime */
- .virtual = OMAP1_SRAM_VA,
- .pfn = __phys_to_pfn(OMAP1_SRAM_PA),
- .type = MT_MEMORY
- }
-};
-
/*
* Note that we cannot use ioremap for SRAM, as clock init needs SRAM early.
*/
static void __init omap_map_sram(void)
{
unsigned long base;
+ struct map_desc omap_sram_io_desc[2];
+ int nr_desc = 1;
if (omap_sram_size == 0)
return;
+ omap_sram_io_desc[0].virtual = omap_sram_base;
+ base = omap_sram_start;
+ base = ROUND_DOWN(base, PAGE_SIZE);
+ omap_sram_io_desc[0].pfn = __phys_to_pfn(base);
+ omap_sram_io_desc[0].length = ROUND_DOWN(omap_sram_size, PAGE_SIZE);
+ omap_sram_io_desc[0].type = MT_MEMORY;
+
if (cpu_is_omap34xx()) {
/*
* SRAM must be marked as non-cached on OMAP3 since the
@@ -212,14 +219,26 @@ static void __init omap_map_sram(void)
* which will cause the system to hang.
*/
omap_sram_io_desc[0].type = MT_MEMORY_NONCACHED;
+ } else if (cpu_is_omap44xx()) {
+ omap_sram_io_desc[0].length =
+ ROUND_DOWN(omap_sram_size - PAGE_SIZE, PAGE_SIZE);
+ /*
+ * Map a page of SRAM with strongly ordered attributes
+ * for interconnect barrier usage.
+ */
+ omap_sram_io_desc[1].virtual =
+ omap_sram_base + omap_sram_io_desc[0].length;
+ omap_barrier_base = omap_sram_io_desc[1].virtual;
+ base = omap_sram_start + omap_sram_io_desc[0].length;
+ base = ROUND_DOWN(base, PAGE_SIZE);
+ omap_sram_io_desc[1].pfn = __phys_to_pfn(base);
+ omap_sram_io_desc[1].length = PAGE_SIZE;
+ omap_sram_io_desc[1].type = MT_MEMORY_SO;
+ nr_desc = 2;
}
- omap_sram_io_desc[0].virtual = omap_sram_base;
- base = omap_sram_start;
- base = ROUND_DOWN(base, PAGE_SIZE);
- omap_sram_io_desc[0].pfn = __phys_to_pfn(base);
- omap_sram_io_desc[0].length = ROUND_DOWN(omap_sram_size, PAGE_SIZE);
- iotable_init(omap_sram_io_desc, ARRAY_SIZE(omap_sram_io_desc));
+
+ iotable_init(omap_sram_io_desc, nr_desc);
pr_info("SRAM: Mapped pa 0x%08llx to va 0x%08lx size: 0x%lx\n",
(long long) __pfn_to_phys(omap_sram_io_desc[0].pfn),
--
1.7.4.1
^ permalink raw reply related [flat|nested] 119+ messages in thread* [PATCH 02/25] OMAP4: Redefine mandatory barriers for OMAP to include interconnect barriers.
2011-09-04 13:54 ` [PATCH 02/25] OMAP4: Redefine mandatory barriers for OMAP to include interconnect barriers Santosh Shilimkar
@ 2011-09-13 20:27 ` Tony Lindgren
2011-09-14 5:39 ` Shilimkar, Santosh
2011-09-14 10:24 ` Santosh
0 siblings, 2 replies; 119+ messages in thread
From: Tony Lindgren @ 2011-09-13 20:27 UTC (permalink / raw)
To: linux-arm-kernel
* Santosh Shilimkar <santosh.shilimkar@ti.com> [110904 06:22]:
> On OMAP4 SOC intecronnects has many write buffers in the async bridges
> and they can be drained only with stongly ordered accesses.
This is not correct, strongly ordered access does not guarantee
anything here. If it fixes issues, it's because it makes the writes
to reach the device faster. Strongly ordered does not affect anything
outside ARM, so the bus access won't change.
The only real fix here is to do a read back of the device in question
to guarantee the write got to the device.
> There are two ports as below from MPU and both needs to be drained.
> - MPU --> L3 T2ASYNC FIFO
> - MPU --> DDR T2ASYNC FIFO
>
> Without the interconnect barriers, many issues have been observed
> leading to system freeze, CPU deadlocks, random crashes with
> register accesses, synchronization loss on initiators operating
> on both interconnect port simultaneously.
We had these issues for omap3 too. Adding a few read backs solved
those kinds of issues.
Regards,
Tony
^ permalink raw reply [flat|nested] 119+ messages in thread
* [PATCH 02/25] OMAP4: Redefine mandatory barriers for OMAP to include interconnect barriers.
2011-09-13 20:27 ` Tony Lindgren
@ 2011-09-14 5:39 ` Shilimkar, Santosh
2011-09-14 10:24 ` Santosh
1 sibling, 0 replies; 119+ messages in thread
From: Shilimkar, Santosh @ 2011-09-14 5:39 UTC (permalink / raw)
To: linux-arm-kernel
On Wed, Sep 14, 2011 at 1:57 AM, Tony Lindgren <tony@atomide.com> wrote:
> * Santosh Shilimkar <santosh.shilimkar@ti.com> [110904 06:22]:
>> On OMAP4 SOC intecronnects has many write buffers in the async bridges
>> and they can be drained only with stongly ordered accesses.
>
> This is not correct, strongly ordered access does not guarantee
> anything here. If it fixes issues, it's because it makes the writes
> to reach the device faster. Strongly ordered does not affect anything
> outside ARM, so the bus access won't change.
>
> The only real fix here is to do a read back of the device in question
> to guarantee the write got to the device.
>
>> There are two ports as below from MPU and both needs to be drained.
>> ? ? ? - MPU --> L3 T2ASYNC FIFO
>> ? ? ? - MPU --> DDR T2ASYNC FIFO
>>
>> Without the interconnect barriers, many issues have been observed
>> leading to system freeze, CPU deadlocks, random crashes with
>> register accesses, synchronization loss on initiators operating
>> on both interconnect port simultaneously.
>
> We had these issues for omap3 too. Adding a few read backs solved
> those kinds of issues.
>
No. Don't mix things. OMAP3 behaviour is a interconnect level and
it was single interconnect channel.
The issue here is a BUG in the asynchronous bridges and OMAp4 has
two separate channels at interconnect level form MPU side as mentioned
above.
Both of these patches I have passed it through Russell and Caralin before
including them here.
Regards
Santosh
^ permalink raw reply [flat|nested] 119+ messages in thread
* [PATCH 02/25] OMAP4: Redefine mandatory barriers for OMAP to include interconnect barriers.
2011-09-13 20:27 ` Tony Lindgren
2011-09-14 5:39 ` Shilimkar, Santosh
@ 2011-09-14 10:24 ` Santosh
2011-09-15 17:17 ` Kevin Hilman
1 sibling, 1 reply; 119+ messages in thread
From: Santosh @ 2011-09-14 10:24 UTC (permalink / raw)
To: linux-arm-kernel
On Wednesday 14 September 2011 01:57 AM, Tony Lindgren wrote:
> * Santosh Shilimkar<santosh.shilimkar@ti.com> [110904 06:22]:
>> On OMAP4 SOC intecronnects has many write buffers in the async bridges
>> and they can be drained only with stongly ordered accesses.
>
> This is not correct, strongly ordered access does not guarantee
> anything here. If it fixes issues, it's because it makes the writes
> to reach the device faster. Strongly ordered does not affect anything
> outside ARM, so the bus access won't change.
>
What I said is the aync bridges WB and what is said is correct
from MPU accesses point of view.
It's not about faster or slower. With device memory the, writes
can get stuck into write buffers where as with SO, the write buffers
will be bypassed.
The behaviours is limited to the MPU side async bridge boundary which
is the problem. The statement is not for l3 and l4 interconnect which
probably you mean.
There is always a hardware signal to communicate CPU at async bridges
to ensure that data is not stuck in these bridges before CPU
clock/voltage is cut. Unfortunately we have a BUG on OMAP44XX devices
and the dual channel makes it even worst since both pipes have the
same BUG. So what we are doing is issuing SO write/read accesses
on these pipes so that there is nothing stuck there before MPU
hits low power states and also avoids any race conditions when
both channels are used together by some initiators. The behaviour
is validated at RTL level and there is no ambiguity about it.
May be you have mistaken the L3 and L4 as the interconnect levels
in this case.
Regards
Santosh
^ permalink raw reply [flat|nested] 119+ messages in thread
* [PATCH 02/25] OMAP4: Redefine mandatory barriers for OMAP to include interconnect barriers.
2011-09-14 10:24 ` Santosh
@ 2011-09-15 17:17 ` Kevin Hilman
2011-09-15 17:24 ` Shilimkar, Santosh
0 siblings, 1 reply; 119+ messages in thread
From: Kevin Hilman @ 2011-09-15 17:17 UTC (permalink / raw)
To: linux-arm-kernel
Santosh <santosh.shilimkar@ti.com> writes:
> On Wednesday 14 September 2011 01:57 AM, Tony Lindgren wrote:
>> * Santosh Shilimkar<santosh.shilimkar@ti.com> [110904 06:22]:
>>> On OMAP4 SOC intecronnects has many write buffers in the async bridges
>>> and they can be drained only with stongly ordered accesses.
>>
>> This is not correct, strongly ordered access does not guarantee
>> anything here. If it fixes issues, it's because it makes the writes
>> to reach the device faster. Strongly ordered does not affect anything
>> outside ARM, so the bus access won't change.
>>
> What I said is the aync bridges WB and what is said is correct
> from MPU accesses point of view.
>
> It's not about faster or slower. With device memory the, writes
> can get stuck into write buffers where as with SO, the write buffers
> will be bypassed.
>
> The behaviours is limited to the MPU side async bridge boundary which
> is the problem. The statement is not for l3 and l4 interconnect which
> probably you mean.
>
> There is always a hardware signal to communicate CPU at async bridges
> to ensure that data is not stuck in these bridges before CPU
> clock/voltage is cut. Unfortunately we have a BUG on OMAP44XX devices
> and the dual channel makes it even worst since both pipes have the
> same BUG. So what we are doing is issuing SO write/read accesses
> on these pipes so that there is nothing stuck there before MPU
> hits low power states and also avoids any race conditions when
> both channels are used together by some initiators. The behaviour
> is validated at RTL level and there is no ambiguity about it.
>
> May be you have mistaken the L3 and L4 as the interconnect levels
> in this case.
Sounds to me like the changelog needs to be a bit more verbose.
Remember, we're all probably going to forget the gory details of this in
a few months and want to be able to go back to the code w/changelog to
refresh our memories.
Thanks,
Kevin
^ permalink raw reply [flat|nested] 119+ messages in thread
* [PATCH 02/25] OMAP4: Redefine mandatory barriers for OMAP to include interconnect barriers.
2011-09-15 17:17 ` Kevin Hilman
@ 2011-09-15 17:24 ` Shilimkar, Santosh
2011-09-15 17:53 ` Tony Lindgren
0 siblings, 1 reply; 119+ messages in thread
From: Shilimkar, Santosh @ 2011-09-15 17:24 UTC (permalink / raw)
To: linux-arm-kernel
On Thu, Sep 15, 2011 at 10:47 PM, Kevin Hilman <khilman@ti.com> wrote:
> Santosh <santosh.shilimkar@ti.com> writes:
>
>> On Wednesday 14 September 2011 01:57 AM, Tony Lindgren wrote:
>>> * Santosh Shilimkar<santosh.shilimkar@ti.com> ?[110904 06:22]:
>>>> On OMAP4 SOC intecronnects has many write buffers in the async bridges
>>>> and they can be drained only with stongly ordered accesses.
>>>
>>> This is not correct, strongly ordered access does not guarantee
>>> anything here. If it fixes issues, it's because it makes the writes
>>> to reach the device faster. Strongly ordered does not affect anything
>>> outside ARM, so the bus access won't change.
>>>
>> What I said is the aync bridges WB and what is said is correct
>> from MPU accesses point of view.
>>
>> It's not about faster or slower. With device memory the, writes
>> can get stuck into write buffers where as with SO, the write buffers
>> will be bypassed.
>>
>> The behaviours is limited to the MPU side async bridge boundary which
>> is the problem. The statement is not for l3 and l4 interconnect which
>> probably you mean.
>>
>> There is always a hardware signal to communicate CPU at async bridges
>> to ensure that data is not stuck in these bridges before CPU
>> clock/voltage is cut. Unfortunately we have a BUG on OMAP44XX devices
>> and the dual channel makes it even worst since both pipes have the
>> same BUG. So what we are doing is issuing SO write/read accesses
>> on these pipes so that there is nothing stuck there before MPU
>> hits low power states and also avoids any race conditions when
>> both channels are used together by some initiators. The behaviour
>> is validated at RTL level and there is no ambiguity about it.
>>
>> May be you have mistaken the L3 and L4 as the interconnect levels
>> in this case.
>
> Sounds to me like the changelog needs to be a bit more verbose.
>
> Remember, we're all probably going to forget the gory details of this in
> a few months and want to be able to go back to the code w/changelog to
> refresh our memories.
>
Change log was accurate but I agree it needs more description to make it
clear. I plan to update it.
^ permalink raw reply [flat|nested] 119+ messages in thread
* [PATCH 02/25] OMAP4: Redefine mandatory barriers for OMAP to include interconnect barriers.
2011-09-15 17:24 ` Shilimkar, Santosh
@ 2011-09-15 17:53 ` Tony Lindgren
2011-09-15 18:22 ` Shilimkar, Santosh
0 siblings, 1 reply; 119+ messages in thread
From: Tony Lindgren @ 2011-09-15 17:53 UTC (permalink / raw)
To: linux-arm-kernel
* Shilimkar, Santosh <santosh.shilimkar@ti.com> [110915 09:51]:
> On Thu, Sep 15, 2011 at 10:47 PM, Kevin Hilman <khilman@ti.com> wrote:
> > Santosh <santosh.shilimkar@ti.com> writes:
> >
> >> On Wednesday 14 September 2011 01:57 AM, Tony Lindgren wrote:
> >>> * Santosh Shilimkar<santosh.shilimkar@ti.com> ?[110904 06:22]:
> >>>> On OMAP4 SOC intecronnects has many write buffers in the async bridges
> >>>> and they can be drained only with stongly ordered accesses.
> >>>
> >>> This is not correct, strongly ordered access does not guarantee
> >>> anything here. If it fixes issues, it's because it makes the writes
> >>> to reach the device faster. Strongly ordered does not affect anything
> >>> outside ARM, so the bus access won't change.
> >>>
> >> What I said is the aync bridges WB and what is said is correct
> >> from MPU accesses point of view.
> >>
> >> It's not about faster or slower. With device memory the, writes
> >> can get stuck into write buffers where as with SO, the write buffers
> >> will be bypassed.
> >>
> >> The behaviours is limited to the MPU side async bridge boundary which
> >> is the problem. The statement is not for l3 and l4 interconnect which
> >> probably you mean.
> >>
> >> There is always a hardware signal to communicate CPU at async bridges
> >> to ensure that data is not stuck in these bridges before CPU
> >> clock/voltage is cut. Unfortunately we have a BUG on OMAP44XX devices
> >> and the dual channel makes it even worst since both pipes have the
> >> same BUG. So what we are doing is issuing SO write/read accesses
> >> on these pipes so that there is nothing stuck there before MPU
> >> hits low power states and also avoids any race conditions when
> >> both channels are used together by some initiators. The behaviour
> >> is validated at RTL level and there is no ambiguity about it.
> >>
> >> May be you have mistaken the L3 and L4 as the interconnect levels
> >> in this case.
> >
> > Sounds to me like the changelog needs to be a bit more verbose.
> >
> > Remember, we're all probably going to forget the gory details of this in
> > a few months and want to be able to go back to the code w/changelog to
> > refresh our memories.
> >
> Change log was accurate but I agree it needs more description to make it
> clear. I plan to update it.
Please also include the errata in the description and set it up with
a Kconfig entry with something like ARM_ERRATA_XXXXXX or TI_ERRATA_XXXXXX.
Also it would be best to apply this fix at the end of the PM series so
it is easier to verify the bug and potentially remove the hack if
a better fix is ever available.
Regards,
Tony
^ permalink raw reply [flat|nested] 119+ messages in thread
* [PATCH 02/25] OMAP4: Redefine mandatory barriers for OMAP to include interconnect barriers.
2011-09-15 17:53 ` Tony Lindgren
@ 2011-09-15 18:22 ` Shilimkar, Santosh
2011-09-15 19:43 ` Tony Lindgren
0 siblings, 1 reply; 119+ messages in thread
From: Shilimkar, Santosh @ 2011-09-15 18:22 UTC (permalink / raw)
To: linux-arm-kernel
On Thu, Sep 15, 2011 at 11:23 PM, Tony Lindgren <tony@atomide.com> wrote:
> * Shilimkar, Santosh <santosh.shilimkar@ti.com> [110915 09:51]:
>> On Thu, Sep 15, 2011 at 10:47 PM, Kevin Hilman <khilman@ti.com> wrote:
>> > Santosh <santosh.shilimkar@ti.com> writes:
>> >
>> >> On Wednesday 14 September 2011 01:57 AM, Tony Lindgren wrote:
>> >>> * Santosh Shilimkar<santosh.shilimkar@ti.com> ?[110904 06:22]:
>> >>>> On OMAP4 SOC intecronnects has many write buffers in the async bridges
>> >>>> and they can be drained only with stongly ordered accesses.
>> >>>
>> >>> This is not correct, strongly ordered access does not guarantee
>> >>> anything here. If it fixes issues, it's because it makes the writes
>> >>> to reach the device faster. Strongly ordered does not affect anything
>> >>> outside ARM, so the bus access won't change.
>> >>>
>> >> What I said is the aync bridges WB and what is said is correct
>> >> from MPU accesses point of view.
>> >>
>> >> It's not about faster or slower. With device memory the, writes
>> >> can get stuck into write buffers where as with SO, the write buffers
>> >> will be bypassed.
>> >>
>> >> The behaviours is limited to the MPU side async bridge boundary which
>> >> is the problem. The statement is not for l3 and l4 interconnect which
>> >> probably you mean.
>> >>
>> >> There is always a hardware signal to communicate CPU at async bridges
>> >> to ensure that data is not stuck in these bridges before CPU
>> >> clock/voltage is cut. Unfortunately we have a BUG on OMAP44XX devices
>> >> and the dual channel makes it even worst since both pipes have the
>> >> same BUG. So what we are doing is issuing SO write/read accesses
>> >> on these pipes so that there is nothing stuck there before MPU
>> >> hits low power states and also avoids any race conditions when
>> >> both channels are used together by some initiators. The behaviour
>> >> is validated at RTL level and there is no ambiguity about it.
>> >>
>> >> May be you have mistaken the L3 and L4 as the interconnect levels
>> >> in this case.
>> >
>> > Sounds to me like the changelog needs to be a bit more verbose.
>> >
>> > Remember, we're all probably going to forget the gory details of this in
>> > a few months and want to be able to go back to the code w/changelog to
>> > refresh our memories.
>> >
>> Change log was accurate but I agree it needs more description to make it
>> clear. I plan to update it.
>
> Please also include the errata in the description and set it up with
> a Kconfig entry with something like ARM_ERRATA_XXXXXX or TI_ERRATA_XXXXXX.
>
Sure.
It's a TI ERRATA.
> Also it would be best to apply this fix at the end of the PM series so
> it is easier to verify the bug and potentially remove the hack if
> a better fix is ever available.
>
As such order doesn't matter much because it can be removed either way
even if it is in the beginning of the series with KCONFIG entry.
But I can change the order if you prefer that way.
Regards
Santosh
^ permalink raw reply [flat|nested] 119+ messages in thread
* [PATCH 02/25] OMAP4: Redefine mandatory barriers for OMAP to include interconnect barriers.
2011-09-15 18:22 ` Shilimkar, Santosh
@ 2011-09-15 19:43 ` Tony Lindgren
2011-09-15 20:00 ` Shilimkar, Santosh
0 siblings, 1 reply; 119+ messages in thread
From: Tony Lindgren @ 2011-09-15 19:43 UTC (permalink / raw)
To: linux-arm-kernel
* Shilimkar, Santosh <santosh.shilimkar@ti.com> [110915 10:49]:
> On Thu, Sep 15, 2011 at 11:23 PM, Tony Lindgren <tony@atomide.com> wrote:
> >
> > Please also include the errata in the description and set it up with
> > a Kconfig entry with something like ARM_ERRATA_XXXXXX or TI_ERRATA_XXXXXX.
> >
> Sure.
> It's a TI ERRATA.
OK
> > Also it would be best to apply this fix at the end of the PM series so
> > it is easier to verify the bug and potentially remove the hack if
> > a better fix is ever available.
> >
> As such order doesn't matter much because it can be removed either way
> even if it is in the beginning of the series with KCONFIG entry.
>
> But I can change the order if you prefer that way.
Well it seems that it's the omap4_finish_suspend in this series that
can be used to trigger the bug, although the bug has been around for
few years. So then instead of mentioning random hangups you can have
a better description with something like "Patch xyz added PM idle
support for omap4, however bug 123 causes so and so. Fix the issue
with blah blah".
Also, if you have some easy way to reproduce the bug maybe mention
that too? That would make it easy to verify if issue has been fixed.
Regards,
Tony
^ permalink raw reply [flat|nested] 119+ messages in thread
* [PATCH 02/25] OMAP4: Redefine mandatory barriers for OMAP to include interconnect barriers.
2011-09-15 19:43 ` Tony Lindgren
@ 2011-09-15 20:00 ` Shilimkar, Santosh
2011-09-16 12:01 ` Shilimkar, Santosh
0 siblings, 1 reply; 119+ messages in thread
From: Shilimkar, Santosh @ 2011-09-15 20:00 UTC (permalink / raw)
To: linux-arm-kernel
On Fri, Sep 16, 2011 at 1:13 AM, Tony Lindgren <tony@atomide.com> wrote:
> * Shilimkar, Santosh <santosh.shilimkar@ti.com> [110915 10:49]:
>> On Thu, Sep 15, 2011 at 11:23 PM, Tony Lindgren <tony@atomide.com> wrote:
>> >
>> > Please also include the errata in the description and set it up with
>> > a Kconfig entry with something like ARM_ERRATA_XXXXXX or TI_ERRATA_XXXXXX.
>> >
>> Sure.
>> It's a ?TI ERRATA.
>
> OK
>
>> > Also it would be best to apply this fix at the end of the PM series so
>> > it is easier to verify the bug and potentially remove the hack if
>> > a better fix is ever available.
>> >
>> As such order doesn't matter much because it can be removed either way
>> even if it is in the beginning of the series with KCONFIG entry.
>>
>> But I can change the order if you prefer that way.
>
> Well it seems that it's the omap4_finish_suspend in this series that
> can be used to trigger the bug, although the bug has been around for
> few years. So then instead of mentioning random hangups you can have
> a better description with something like "Patch xyz added PM idle
> support for omap4, however bug 123 causes so and so. Fix the issue
> with blah blah".
>
Sounds good .
> Also, if you have some easy way to reproduce the bug maybe mention
> that too? That would make it easy to verify if issue has been fixed.
>
There are some multimedia usecases where the bug was discovered
but on mainline obviously we don't have that support.
I will check with IP folks if any other simple test-case is possible
to reproduce the issue and If I find one, will mention that.
Thanks for the review.
Regards
Santosh
^ permalink raw reply [flat|nested] 119+ messages in thread
* [PATCH 02/25] OMAP4: Redefine mandatory barriers for OMAP to include interconnect barriers.
2011-09-15 20:00 ` Shilimkar, Santosh
@ 2011-09-16 12:01 ` Shilimkar, Santosh
0 siblings, 0 replies; 119+ messages in thread
From: Shilimkar, Santosh @ 2011-09-16 12:01 UTC (permalink / raw)
To: linux-arm-kernel
On Fri, Sep 16, 2011 at 1:30 AM, Shilimkar, Santosh
<santosh.shilimkar@ti.com> wrote:
> On Fri, Sep 16, 2011 at 1:13 AM, Tony Lindgren <tony@atomide.com> wrote:
>> * Shilimkar, Santosh <santosh.shilimkar@ti.com> [110915 10:49]:
>>> On Thu, Sep 15, 2011 at 11:23 PM, Tony Lindgren <tony@atomide.com> wrote:
>>> >
>>> > Please also include the errata in the description and set it up with
>>> > a Kconfig entry with something like ARM_ERRATA_XXXXXX or TI_ERRATA_XXXXXX.
>>> >
>>> Sure.
>>> It's a ?TI ERRATA.
>>
>> OK
>>
>>> > Also it would be best to apply this fix at the end of the PM series so
>>> > it is easier to verify the bug and potentially remove the hack if
>>> > a better fix is ever available.
>>> >
>>> As such order doesn't matter much because it can be removed either way
>>> even if it is in the beginning of the series with KCONFIG entry.
>>>
>>> But I can change the order if you prefer that way.
>>
>> Well it seems that it's the omap4_finish_suspend in this series that
>> can be used to trigger the bug, although the bug has been around for
>> few years. So then instead of mentioning random hangups you can have
>> a better description with something like "Patch xyz added PM idle
>> support for omap4, however bug 123 causes so and so. Fix the issue
>> with blah blah".
>>
> Sounds good .
>
>> Also, if you have some easy way to reproduce the bug maybe mention
>> that too? That would make it easy to verify if issue has been fixed.
>>
Just for record, Below are the errata details.
ERRATA: i688: Async Bridge Corruption
If a data is stalled inside asynchronous bridge because
of backpressure, 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, MPU to L3 interconnect and Cortex M3 to Emif .
This situation can happen only when the idle is initiated by a Master
Request Disconnection (which is trigged by software whenexecuting WFI)
WORKAROUND
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.
> There are some multimedia usecases where the bug was discovered
> but on mainline obviously we don't have that support.
>
> I will check with IP folks if any other simple test-case is possible
> to reproduce the issue and If I find one, will mention that.
>
We have a GFX usecase which demonstrate this issue but can't
be tested on mainline sicne no GFX support.
But the same patch is already in the product line which
has fixed the GFX usecase issue.
Regards
Santosh
^ permalink raw reply [flat|nested] 119+ messages in thread
* [PATCH 03/25] OMAP4: PM: Use custom omap_do_wfi() for suspend and default idle.
2011-09-04 13:54 [PATCH 00/25] OMAP4: PM: suspend, CPU-hotplug and CPUilde support Santosh Shilimkar
2011-09-04 13:54 ` [PATCH 01/25] ARM: mm: Add strongly ordered descriptor support Santosh Shilimkar
2011-09-04 13:54 ` [PATCH 02/25] OMAP4: Redefine mandatory barriers for OMAP to include interconnect barriers Santosh Shilimkar
@ 2011-09-04 13:54 ` Santosh Shilimkar
2011-09-04 13:54 ` [PATCH 04/25] OMAP4: Remove un-used do_wfi() macro Santosh Shilimkar
` (24 subsequent siblings)
27 siblings, 0 replies; 119+ messages in thread
From: Santosh Shilimkar @ 2011-09-04 13:54 UTC (permalink / raw)
To: linux-arm-kernel
The omap_do_wfi() incorporates interconnect barriers to meet
OMAP44XX interconnect ordering requirements. Make use of this
hook in default idle, suspend and CPU hot-plug paths.
Without the interconnect barriers, many issues have been observed
leading to system freeze, CPU deadlocks, random crashes with
register accesses, synchronization loss on initiators operating
on both interconnect port simultaneously.
Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
Cc: Kevin Hilman <khilman@ti.com>
---
arch/arm/mach-omap2/include/mach/omap4-common.h | 1 +
arch/arm/mach-omap2/omap-hotplug.c | 2 +-
arch/arm/mach-omap2/pm44xx.c | 22 ++++++++++-
arch/arm/mach-omap2/sleep44xx.S | 47 +++++++++++++++++++++++
4 files changed, 70 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/include/mach/omap4-common.h b/arch/arm/mach-omap2/include/mach/omap4-common.h
index 26653f6..62d8d07 100644
--- a/arch/arm/mach-omap2/include/mach/omap4-common.h
+++ b/arch/arm/mach-omap2/include/mach/omap4-common.h
@@ -38,6 +38,7 @@ extern void __init gic_init_irq(void);
extern void omap_smc1(u32 fn, u32 arg);
extern void omap_bus_sync(void);
extern unsigned long omap_get_dram_barrier_base(void);
+extern void omap_do_wfi(void);
#ifdef CONFIG_SMP
/* Needed for secondary core boot */
diff --git a/arch/arm/mach-omap2/omap-hotplug.c b/arch/arm/mach-omap2/omap-hotplug.c
index 4976b93..80167ec 100644
--- a/arch/arm/mach-omap2/omap-hotplug.c
+++ b/arch/arm/mach-omap2/omap-hotplug.c
@@ -45,7 +45,7 @@ void platform_cpu_die(unsigned int cpu)
/*
* Execute WFI
*/
- do_wfi();
+ omap_do_wfi();
if (omap_read_auxcoreboot0() == cpu) {
/*
diff --git a/arch/arm/mach-omap2/pm44xx.c b/arch/arm/mach-omap2/pm44xx.c
index 59a870b..4bbc6fe 100644
--- a/arch/arm/mach-omap2/pm44xx.c
+++ b/arch/arm/mach-omap2/pm44xx.c
@@ -33,7 +33,7 @@ static LIST_HEAD(pwrst_list);
#ifdef CONFIG_SUSPEND
static int omap4_pm_suspend(void)
{
- do_wfi();
+ omap_do_wfi();
return 0;
}
@@ -91,6 +91,23 @@ static int __init pwrdms_setup(struct powerdomain *pwrdm, void *unused)
}
/**
+ * omap_default_idle -
+ * 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
@@ -115,6 +132,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;
}
diff --git a/arch/arm/mach-omap2/sleep44xx.S b/arch/arm/mach-omap2/sleep44xx.S
index 5406713..049f426 100644
--- a/arch/arm/mach-omap2/sleep44xx.S
+++ b/arch/arm/mach-omap2/sleep44xx.S
@@ -27,3 +27,50 @@ ENTRY(omap_bus_sync)
isb
ldmfd sp!, {pc}
ENDPROC(omap_bus_sync)
+
+ENTRY(omap_do_wfi)
+ stmfd sp!, {lr}
+ /* Drain interconnect write buffers. */
+ bl omap_bus_sync
+
+ /*
+ * Execute an ISB instruction to ensure that all of the
+ * CP15 register changes have been committed.
+ */
+ isb
+
+ /*
+ * Execute a barrier instruction to ensure that all cache,
+ * TLB and branch predictor maintenance operations issued
+ * by any CPU in the cluster have completed.
+ */
+ dsb
+ dmb
+
+ /*
+ * Execute a WFI instruction and wait until the
+ * STANDBYWFI output is asserted to indicate that the
+ * CPU is in idle and low power state. CPU can specualatively
+ * prefetch the instructions so add NOPs after WFI. Sixteen
+ * NOPs as per Cortex-A9 pipeline.
+ */
+ wfi @ Wait For Interrupt
+ nop
+ nop
+ nop
+ nop
+ nop
+ nop
+ nop
+ nop
+ nop
+ nop
+ nop
+ nop
+ nop
+ nop
+ nop
+ nop
+
+ ldmfd sp!, {pc}
+ENDPROC(omap_do_wfi)
--
1.7.4.1
^ permalink raw reply related [flat|nested] 119+ messages in thread* [PATCH 04/25] OMAP4: Remove un-used do_wfi() macro.
2011-09-04 13:54 [PATCH 00/25] OMAP4: PM: suspend, CPU-hotplug and CPUilde support Santosh Shilimkar
` (2 preceding siblings ...)
2011-09-04 13:54 ` [PATCH 03/25] OMAP4: PM: Use custom omap_do_wfi() for suspend and default idle Santosh Shilimkar
@ 2011-09-04 13:54 ` Santosh Shilimkar
2011-09-04 13:54 ` [PATCH 05/25] OMAP4: Use WARN_ON() instead of BUG_ON() with graceful exit Santosh Shilimkar
` (23 subsequent siblings)
27 siblings, 0 replies; 119+ messages in thread
From: Santosh Shilimkar @ 2011-09-04 13:54 UTC (permalink / raw)
To: linux-arm-kernel
With OMAP4 suspend, idle and hotplug series, we no longer need
do_wfi() macro.
Remove the same.
Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
Cc: Kevin Hilman <khilman@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 62d8d07..552b5e7 100644
--- a/arch/arm/mach-omap2/include/mach/omap4-common.h
+++ b/arch/arm/mach-omap2/include/mach/omap4-common.h
@@ -17,16 +17,6 @@
#define OMAP4_DRAM_BARRIER_VA 0xfe600000
#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__ (".word 0xe320f003" : : : "memory")
-#endif
#ifdef CONFIG_CACHE_L2X0
extern void __iomem *l2cache_base;
--
1.7.4.1
^ permalink raw reply related [flat|nested] 119+ messages in thread* [PATCH 05/25] OMAP4: Use WARN_ON() instead of BUG_ON() with graceful exit
2011-09-04 13:54 [PATCH 00/25] OMAP4: PM: suspend, CPU-hotplug and CPUilde support Santosh Shilimkar
` (3 preceding siblings ...)
2011-09-04 13:54 ` [PATCH 04/25] OMAP4: Remove un-used do_wfi() macro Santosh Shilimkar
@ 2011-09-04 13:54 ` Santosh Shilimkar
2011-09-05 10:11 ` Sergei Shtylyov
2011-09-04 13:54 ` [PATCH 06/25] OMAP4: Export omap4_get_base*() rather than global address pointers Santosh Shilimkar
` (22 subsequent siblings)
27 siblings, 1 reply; 119+ messages in thread
From: Santosh Shilimkar @ 2011-09-04 13:54 UTC (permalink / raw)
To: linux-arm-kernel
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 <khilman@ti.com> during
OMAP4 PM code review.
Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
Cc: Kevin Hilman <khilman@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 4791370..4904025 100644
--- a/arch/arm/mach-omap2/omap4-common.c
+++ b/arch/arm/mach-omap2/omap4-common.c
@@ -121,7 +121,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 -ENODEV;
/*
* 16-way associativity, parity disabled
--
1.7.4.1
^ permalink raw reply related [flat|nested] 119+ messages in thread* [PATCH 05/25] OMAP4: Use WARN_ON() instead of BUG_ON() with graceful exit
2011-09-04 13:54 ` [PATCH 05/25] OMAP4: Use WARN_ON() instead of BUG_ON() with graceful exit Santosh Shilimkar
@ 2011-09-05 10:11 ` Sergei Shtylyov
2011-09-05 10:42 ` Santosh
0 siblings, 1 reply; 119+ messages in thread
From: Sergei Shtylyov @ 2011-09-05 10:11 UTC (permalink / raw)
To: linux-arm-kernel
Hello.
On 04-09-2011 17:54, Santosh Shilimkar wrote:
> 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<khilman@ti.com> during
> OMAP4 PM code review.
> Signed-off-by: Santosh Shilimkar<santosh.shilimkar@ti.com>
> Cc: Kevin Hilman<khilman@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 4791370..4904025 100644
> --- a/arch/arm/mach-omap2/omap4-common.c
> +++ b/arch/arm/mach-omap2/omap4-common.c
> @@ -121,7 +121,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 -ENODEV;
Rather ENOMEM...
WBR, Sergei
^ permalink raw reply [flat|nested] 119+ messages in thread* [PATCH 05/25] OMAP4: Use WARN_ON() instead of BUG_ON() with graceful exit
2011-09-05 10:11 ` Sergei Shtylyov
@ 2011-09-05 10:42 ` Santosh
2011-09-05 10:47 ` Russell King - ARM Linux
0 siblings, 1 reply; 119+ messages in thread
From: Santosh @ 2011-09-05 10:42 UTC (permalink / raw)
To: linux-arm-kernel
On Monday 05 September 2011 03:41 PM, Sergei Shtylyov wrote:
> Hello.
>
> On 04-09-2011 17:54, Santosh Shilimkar wrote:
>
>> 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<khilman@ti.com> during
>> OMAP4 PM code review.
>
>> Signed-off-by: Santosh Shilimkar<santosh.shilimkar@ti.com>
>> Cc: Kevin Hilman<khilman@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 4791370..4904025 100644
>> --- a/arch/arm/mach-omap2/omap4-common.c
>> +++ b/arch/arm/mach-omap2/omap4-common.c
>> @@ -121,7 +121,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 -ENODEV;
>
> Rather ENOMEM...
>
Nope. Even though it's related to memory, it's
a memory controller so DEV is right.
Regards
Santosh
^ permalink raw reply [flat|nested] 119+ messages in thread
* [PATCH 05/25] OMAP4: Use WARN_ON() instead of BUG_ON() with graceful exit
2011-09-05 10:42 ` Santosh
@ 2011-09-05 10:47 ` Russell King - ARM Linux
2011-09-05 10:51 ` Santosh
0 siblings, 1 reply; 119+ messages in thread
From: Russell King - ARM Linux @ 2011-09-05 10:47 UTC (permalink / raw)
To: linux-arm-kernel
On Mon, Sep 05, 2011 at 04:12:02PM +0530, Santosh wrote:
> On Monday 05 September 2011 03:41 PM, Sergei Shtylyov wrote:
>> Hello.
>>
>> On 04-09-2011 17:54, Santosh Shilimkar wrote:
>>
>>> 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<khilman@ti.com> during
>>> OMAP4 PM code review.
>>
>>> Signed-off-by: Santosh Shilimkar<santosh.shilimkar@ti.com>
>>> Cc: Kevin Hilman<khilman@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 4791370..4904025 100644
>>> --- a/arch/arm/mach-omap2/omap4-common.c
>>> +++ b/arch/arm/mach-omap2/omap4-common.c
>>> @@ -121,7 +121,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 -ENODEV;
>>
>> Rather ENOMEM...
>>
> Nope. Even though it's related to memory, it's
> a memory controller so DEV is right.
No it's not. The most likely reason ioremap() fails is because:
1. it's run out of memory for the metadata or page tables.
2. you passed it an invalid memory type (unlikely, you're using ioremap
which uses a fixed known good type).
3. the address was >4GB but was not section aligned (also unlikely).
Therefore, the error code should be "out of memory" not "no such device".
^ permalink raw reply [flat|nested] 119+ messages in thread
* [PATCH 05/25] OMAP4: Use WARN_ON() instead of BUG_ON() with graceful exit
2011-09-05 10:47 ` Russell King - ARM Linux
@ 2011-09-05 10:51 ` Santosh
2011-09-08 18:51 ` Jean Pihet
0 siblings, 1 reply; 119+ messages in thread
From: Santosh @ 2011-09-05 10:51 UTC (permalink / raw)
To: linux-arm-kernel
On Monday 05 September 2011 04:17 PM, Russell King - ARM Linux wrote:
> On Mon, Sep 05, 2011 at 04:12:02PM +0530, Santosh wrote:
>> On Monday 05 September 2011 03:41 PM, Sergei Shtylyov wrote:
[..]
>>>> /* Static mapping, never released */
>>>> l2cache_base = ioremap(OMAP44XX_L2CACHE_BASE, SZ_4K);
>>>> - BUG_ON(!l2cache_base);
>>>> + if (WARN_ON(!l2cache_base))
>>>> + return -ENODEV;
>>>
>>> Rather ENOMEM...
>>>
>> Nope. Even though it's related to memory, it's
>> a memory controller so DEV is right.
>
> No it's not. The most likely reason ioremap() fails is because:
>
> 1. it's run out of memory for the metadata or page tables.
> 2. you passed it an invalid memory type (unlikely, you're using ioremap
> which uses a fixed known good type).
> 3. the address was>4GB but was not section aligned (also unlikely).
>
> Therefore, the error code should be "out of memory" not "no such device".
Got it. Will fix that.
^ permalink raw reply [flat|nested] 119+ messages in thread
* [PATCH 05/25] OMAP4: Use WARN_ON() instead of BUG_ON() with graceful exit
2011-09-05 10:51 ` Santosh
@ 2011-09-08 18:51 ` Jean Pihet
0 siblings, 0 replies; 119+ messages in thread
From: Jean Pihet @ 2011-09-08 18:51 UTC (permalink / raw)
To: linux-arm-kernel
Hi Santosh,
On Mon, Sep 5, 2011 at 12:51 PM, Santosh <santosh.shilimkar@ti.com> wrote:
> On Monday 05 September 2011 04:17 PM, Russell King - ARM Linux wrote:
>>
>> On Mon, Sep 05, 2011 at 04:12:02PM +0530, Santosh wrote:
>>>
>>> On Monday 05 September 2011 03:41 PM, Sergei Shtylyov wrote:
>
> [..]
>
>>>>> /* Static mapping, never released */
>>>>> l2cache_base = ioremap(OMAP44XX_L2CACHE_BASE, SZ_4K);
>>>>> - BUG_ON(!l2cache_base);
>>>>> + if (WARN_ON(!l2cache_base))
>>>>> + return -ENODEV;
>>>>
>>>> Rather ENOMEM...
>>>>
>>> Nope. Even though it's related to memory, it's
>>> a memory controller so DEV is right.
>>
>> No it's not. ?The most likely reason ioremap() fails is because:
>>
>> 1. it's run out of memory for the metadata or page tables.
>> 2. you passed it an invalid memory type (unlikely, you're using ioremap
>> ? ?which uses a fixed known good type).
>> 3. the address was>4GB but was not section aligned (also unlikely).
>>
>> Therefore, the error code should be "out of memory" not "no such device".
>
> Got it. Will fix that.
Patch [07/25] has the same code and so will need fixing too.
Regards,
Jean
> --
> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at ?http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply [flat|nested] 119+ messages in thread
* [PATCH 06/25] OMAP4: Export omap4_get_base*() rather than global address pointers
2011-09-04 13:54 [PATCH 00/25] OMAP4: PM: suspend, CPU-hotplug and CPUilde support Santosh Shilimkar
` (4 preceding siblings ...)
2011-09-04 13:54 ` [PATCH 05/25] OMAP4: Use WARN_ON() instead of BUG_ON() with graceful exit Santosh Shilimkar
@ 2011-09-04 13:54 ` Santosh Shilimkar
2011-09-04 13:54 ` [PATCH 07/25] OMAP4: PM: Add SAR RAM support Santosh Shilimkar
` (21 subsequent siblings)
27 siblings, 0 replies; 119+ messages in thread
From: Santosh Shilimkar @ 2011-09-04 13:54 UTC (permalink / raw)
To: linux-arm-kernel
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 <khilman@ti.com> during
OMAP4 PM code review.
Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
Cc: Kevin Hilman <khilman@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 552b5e7..ba629fc 100644
--- a/arch/arm/mach-omap2/include/mach/omap4-common.h
+++ b/arch/arm/mach-omap2/include/mach/omap4-common.h
@@ -19,10 +19,17 @@
#ifndef __ASSEMBLER__
#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 4904025..090db8f 100644
--- a/arch/arm/mach-omap2/omap4-common.c
+++ b/arch/arm/mach-omap2/omap4-common.c
@@ -27,7 +27,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;
@@ -96,6 +96,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
^ permalink raw reply related [flat|nested] 119+ messages in thread* [PATCH 07/25] OMAP4: PM: Add SAR RAM support
2011-09-04 13:54 [PATCH 00/25] OMAP4: PM: suspend, CPU-hotplug and CPUilde support Santosh Shilimkar
` (5 preceding siblings ...)
2011-09-04 13:54 ` [PATCH 06/25] OMAP4: Export omap4_get_base*() rather than global address pointers Santosh Shilimkar
@ 2011-09-04 13:54 ` Santosh Shilimkar
2011-09-04 13:54 ` [PATCH 08/25] OMAP4: PM: Keep static dep between MPUSS-EMIF and MPUSS-L3 and DUCATI-L3 Santosh Shilimkar
` (20 subsequent siblings)
27 siblings, 0 replies; 119+ messages in thread
From: Santosh Shilimkar @ 2011-09-04 13:54 UTC (permalink / raw)
To: linux-arm-kernel
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.shilimkar@ti.com>
Cc: Kevin Hilman <khilman@ti.com>
---
arch/arm/mach-omap2/include/mach/omap4-common.h | 1 +
arch/arm/mach-omap2/omap4-common.c | 30 +++++++++++++++++++++++
arch/arm/mach-omap2/omap4-sar-layout.h | 22 ++++++++++++++++
arch/arm/plat-omap/include/plat/omap44xx.h | 1 +
4 files changed, 54 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 ba629fc..040dcf6 100644
--- a/arch/arm/mach-omap2/include/mach/omap4-common.h
+++ b/arch/arm/mach-omap2/include/mach/omap4-common.h
@@ -36,6 +36,7 @@ extern void omap_smc1(u32 fn, u32 arg);
extern void omap_bus_sync(void);
extern unsigned long omap_get_dram_barrier_base(void);
extern void omap_do_wfi(void);
+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 090db8f..1166ee4 100644
--- a/arch/arm/mach-omap2/omap4-common.c
+++ b/arch/arm/mach-omap2/omap4-common.c
@@ -26,6 +26,8 @@
#include <mach/hardware.h>
#include <mach/omap4-common.h>
+#include "omap4-sar-layout.h"
+
#ifdef CONFIG_CACHE_L2X0
static void __iomem *l2cache_base;
#endif
@@ -33,6 +35,7 @@ static void __iomem *l2cache_base;
void __iomem *gic_dist_base_addr;
static unsigned long dram_barrier_base;
+static void __iomem *sar_ram_base;
static void omap_bus_sync_noop(void)
{ }
@@ -167,3 +170,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 -ENODEV;
+
+ /* Static mapping, never released */
+ sar_ram_base = ioremap(OMAP44XX_SAR_RAM_BASE, SZ_8K);
+ if (WARN_ON(!sar_ram_base))
+ return -ENODEV;
+
+ 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 0000000..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.shilimkar@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 0x0000
+#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_BASE 0x40132000
#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
^ permalink raw reply related [flat|nested] 119+ messages in thread* [PATCH 08/25] OMAP4: PM: Keep static dep between MPUSS-EMIF and MPUSS-L3 and DUCATI-L3
2011-09-04 13:54 [PATCH 00/25] OMAP4: PM: suspend, CPU-hotplug and CPUilde support Santosh Shilimkar
` (6 preceding siblings ...)
2011-09-04 13:54 ` [PATCH 07/25] OMAP4: PM: Add SAR RAM support Santosh Shilimkar
@ 2011-09-04 13:54 ` Santosh Shilimkar
2011-09-08 18:06 ` Kevin Hilman
2011-09-04 13:54 ` [PATCH 09/25] OMAP4: PM: Avoid omap4_pm_init() on OMAP4430 ES1.0 Santosh Shilimkar
` (19 subsequent siblings)
27 siblings, 1 reply; 119+ messages in thread
From: Santosh Shilimkar @ 2011-09-04 13:54 UTC (permalink / raw)
To: linux-arm-kernel
As per OMAP4430 TRM, the dynamic dependency between MPUSS -> EMIF
and MPUSS -> 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 keep above dependencies.
Without this system locks up or randomly crashesh.
Signed-off-by: Rajendra Nayak <rnayak@ti.com>
Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
Acked-by: Paul Walmsley <paul@pwsan.com>
Cc: Kevin Hilman <khilman@ti.com>
---
arch/arm/mach-omap2/pm44xx.c | 28 ++++++++++++++++++++++++++++
1 files changed, 28 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/pm44xx.c b/arch/arm/mach-omap2/pm44xx.c
index 4bbc6fe..35ba028 100644
--- a/arch/arm/mach-omap2/pm44xx.c
+++ b/arch/arm/mach-omap2/pm44xx.c
@@ -116,6 +116,8 @@ static void omap_default_idle(void)
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;
if (!cpu_is_omap44xx())
return -ENODEV;
@@ -128,6 +130,32 @@ static int __init omap4_pm_init(void)
goto err2;
}
+ /*
+ * The dynamic dependency between MPUSS -> MEMIF and
+ * MPUSS -> L3_* and DUCATI -> doesn't work as expected.
+ * The hardware recommendation is to keep above dependencies.
+ * Without this system locks up or randomly crashesh.
+ */
+ 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");
+ ducati_clkdm = clkdm_lookup("ducati_clkdm");
+ if ((!mpuss_clkdm) || (!emif_clkdm) || (!l3_1_clkdm) ||
+ (!l3_2_clkdm) || (!ducati_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(ducati_clkdm, l3_1_clkdm);
+ ret |= clkdm_add_wkdep(ducati_clkdm, l3_2_clkdm);
+ if (ret) {
+ pr_err("Failed to add MPUSS -> L3/EMIF, DUCATI -> L3 "
+ "wakeup dependency\n");
+ goto err2;
+ }
+
#ifdef CONFIG_SUSPEND
suspend_set_ops(&omap_pm_ops);
#endif /* CONFIG_SUSPEND */
--
1.7.4.1
^ permalink raw reply related [flat|nested] 119+ messages in thread* [PATCH 08/25] OMAP4: PM: Keep static dep between MPUSS-EMIF and MPUSS-L3 and DUCATI-L3
2011-09-04 13:54 ` [PATCH 08/25] OMAP4: PM: Keep static dep between MPUSS-EMIF and MPUSS-L3 and DUCATI-L3 Santosh Shilimkar
@ 2011-09-08 18:06 ` Kevin Hilman
2011-09-09 4:21 ` Santosh
0 siblings, 1 reply; 119+ messages in thread
From: Kevin Hilman @ 2011-09-08 18:06 UTC (permalink / raw)
To: linux-arm-kernel
Santosh Shilimkar <santosh.shilimkar@ti.com> writes:
> As per OMAP4430 TRM, the dynamic dependency between MPUSS -> EMIF
> and MPUSS -> 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 keep above dependencies.
Minor nit on changelog wording...
The use of "above dependencies" here is a bit confusing, since the only
thing refered to above are dynamic dependencies.
I think this should be worked to be clear that what is being kept are
the *static* dependencies (assuming I understand it correctly.)
> Without this system locks up or randomly crashesh.
Is 'crashesh' a particular kind of crash. maybe a silent one? ;)
> Signed-off-by: Rajendra Nayak <rnayak@ti.com>
> Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
> Acked-by: Paul Walmsley <paul@pwsan.com>
> Cc: Kevin Hilman <khilman@ti.com>
> ---
> arch/arm/mach-omap2/pm44xx.c | 28 ++++++++++++++++++++++++++++
> 1 files changed, 28 insertions(+), 0 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/pm44xx.c b/arch/arm/mach-omap2/pm44xx.c
> index 4bbc6fe..35ba028 100644
> --- a/arch/arm/mach-omap2/pm44xx.c
> +++ b/arch/arm/mach-omap2/pm44xx.c
> @@ -116,6 +116,8 @@ static void omap_default_idle(void)
> 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;
>
> if (!cpu_is_omap44xx())
> return -ENODEV;
> @@ -128,6 +130,32 @@ static int __init omap4_pm_init(void)
> goto err2;
> }
>
> + /*
> + * The dynamic dependency between MPUSS -> MEMIF and
> + * MPUSS -> L3_* and DUCATI -> doesn't work as expected.
> + * The hardware recommendation is to keep above dependencies.
same here... "The hardware recommendation is to use static dependencies."
> + * Without this system locks up or randomly crashesh.
> + */
> + 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");
> + ducati_clkdm = clkdm_lookup("ducati_clkdm");
> + if ((!mpuss_clkdm) || (!emif_clkdm) || (!l3_1_clkdm) ||
> + (!l3_2_clkdm) || (!ducati_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(ducati_clkdm, l3_1_clkdm);
> + ret |= clkdm_add_wkdep(ducati_clkdm, l3_2_clkdm);
> + if (ret) {
> + pr_err("Failed to add MPUSS -> L3/EMIF, DUCATI -> L3 "
> + "wakeup dependency\n");
> + goto err2;
> + }
> +
> #ifdef CONFIG_SUSPEND
> suspend_set_ops(&omap_pm_ops);
> #endif /* CONFIG_SUSPEND */
Kevin
^ permalink raw reply [flat|nested] 119+ messages in thread* [PATCH 08/25] OMAP4: PM: Keep static dep between MPUSS-EMIF and MPUSS-L3 and DUCATI-L3
2011-09-08 18:06 ` Kevin Hilman
@ 2011-09-09 4:21 ` Santosh
0 siblings, 0 replies; 119+ messages in thread
From: Santosh @ 2011-09-09 4:21 UTC (permalink / raw)
To: linux-arm-kernel
On Thursday 08 September 2011 11:36 PM, Kevin Hilman wrote:
> Santosh Shilimkar<santosh.shilimkar@ti.com> writes:
>
>> As per OMAP4430 TRM, the dynamic dependency between MPUSS -> EMIF
>> and MPUSS -> 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 keep above dependencies.
>
> Minor nit on changelog wording...
>
> The use of "above dependencies" here is a bit confusing, since the only
> thing refered to above are dynamic dependencies.
>
> I think this should be worked to be clear that what is being kept are
> the *static* dependencies (assuming I understand it correctly.)
>
Will mention about static deps.
>
>> Without this system locks up or randomly crashesh.
>
> Is 'crashesh' a particular kind of crash. maybe a silent one? ;)
>
My typo made it special :)
Will fix it.
Regards
Santosh
^ permalink raw reply [flat|nested] 119+ messages in thread
* [PATCH 09/25] OMAP4: PM: Avoid omap4_pm_init() on OMAP4430 ES1.0
2011-09-04 13:54 [PATCH 00/25] OMAP4: PM: suspend, CPU-hotplug and CPUilde support Santosh Shilimkar
` (7 preceding siblings ...)
2011-09-04 13:54 ` [PATCH 08/25] OMAP4: PM: Keep static dep between MPUSS-EMIF and MPUSS-L3 and DUCATI-L3 Santosh Shilimkar
@ 2011-09-04 13:54 ` Santosh Shilimkar
2011-09-04 13:54 ` [PATCH 10/25] OMAP4: PM: Initialise all the clockdomains to supported states Santosh Shilimkar
` (18 subsequent siblings)
27 siblings, 0 replies; 119+ messages in thread
From: Santosh Shilimkar @ 2011-09-04 13:54 UTC (permalink / raw)
To: linux-arm-kernel
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.shilimkar@ti.com>
Reported-by: Kevin Hilman <khilman@ti.com>
Cc: Kevin Hilman <khilman@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 35ba028..0154363 100644
--- a/arch/arm/mach-omap2/pm44xx.c
+++ b/arch/arm/mach-omap2/pm44xx.c
@@ -122,6 +122,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
^ permalink raw reply related [flat|nested] 119+ messages in thread* [PATCH 10/25] OMAP4: PM: Initialise all the clockdomains to supported states
2011-09-04 13:54 [PATCH 00/25] OMAP4: PM: suspend, CPU-hotplug and CPUilde support Santosh Shilimkar
` (8 preceding siblings ...)
2011-09-04 13:54 ` [PATCH 09/25] OMAP4: PM: Avoid omap4_pm_init() on OMAP4430 ES1.0 Santosh Shilimkar
@ 2011-09-04 13:54 ` Santosh Shilimkar
2011-09-04 13:54 ` [PATCH 11/25] OMAP: Add Secure HAL and monitor mode API infrastructure Santosh Shilimkar
` (17 subsequent siblings)
27 siblings, 0 replies; 119+ messages in thread
From: Santosh Shilimkar @ 2011-09-04 13:54 UTC (permalink / raw)
To: linux-arm-kernel
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.shilimkar@ti.com>
Signed-off-by: Rajendra Nayak <rnayak@ti.com>
Cc: Kevin Hilman <khilman@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 0154363..44ce15c 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;
@@ -161,6 +178,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
^ permalink raw reply related [flat|nested] 119+ messages in thread* [PATCH 11/25] OMAP: Add Secure HAL and monitor mode API infrastructure.
2011-09-04 13:54 [PATCH 00/25] OMAP4: PM: suspend, CPU-hotplug and CPUilde support Santosh Shilimkar
` (9 preceding siblings ...)
2011-09-04 13:54 ` [PATCH 10/25] OMAP4: PM: Initialise all the clockdomains to supported states Santosh Shilimkar
@ 2011-09-04 13:54 ` Santosh Shilimkar
2011-09-08 18:58 ` Jean Pihet
2011-09-04 13:54 ` [PATCH 12/25] OMAP: Add support to allocate the memory for secure RAM Santosh Shilimkar
` (16 subsequent siblings)
27 siblings, 1 reply; 119+ messages in thread
From: Santosh Shilimkar @ 2011-09-04 13:54 UTC (permalink / raw)
To: linux-arm-kernel
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, 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.shilimkar@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 42e4613..c53a8e8 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 0000000..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.shilimkar@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 0xFFFFFFFE
+#define API_HAL_RET_VALUE_SERVICE_UNKNWON 0xFFFFFFFF
+
+/* HAL API error codes */
+#define API_HAL_RET_VALUE_OK 0x00
+#define API_HAL_RET_VALUE_FAIL 0x01
+
+/* Secure HAL API flags */
+#define FLAG_START_CRITICAL 0x4
+#define FLAG_IRQFIQ_MASK 0x3
+#define FLAG_IRQ_ENABLE 0x2
+#define FLAG_FIQ_ENABLE 0x1
+#define NO_FLAG 0x0
+
+
+/* Secure low power HAL API index */
+#define OMAP4_HAL_SAVESECURERAM_INDEX 0x1a
+#define OMAP4_HAL_SAVEHW_INDEX 0x1b
+#define OMAP4_HAL_SAVEALL_INDEX 0x1c
+#define OMAP4_HAL_SAVEGIC_INDEX 0x1d
+
+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 0000000..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.shilimkar@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>
+#include <linux/io.h>
+
+#include <asm/cacheflush.h>
+
+#include <mach/omap-secure.h>
+
+/**
+ * omap_sec_dispatcher: Routine to dispatch low power secure
+ * service routines
+ * @idx: The HAL API index
+ * @flag: The flag indicating criticality of operation
+ * @nargs: Number of valid arguments out of four.
+ * @arg1, arg2, arg3 args4: Parameters passed to secure API
+ *
+ * Return the non-zero error value on failure.
+ */
+u32 omap_secure_dispatcher(u32 idx, u32 flag, u32 nargs, u32 arg1, u32 arg2,
+ u32 arg3, u32 arg4)
+{
+ u32 ret;
+ u32 param[5];
+
+ param[0] = nargs;
+ param[1] = arg1;
+ param[2] = arg2;
+ param[3] = arg3;
+ param[4] = arg4;
+
+ /*
+ * Secure API needs physical address
+ * pointer for the parameters
+ */
+ flush_cache_all();
+ outer_clean_range(__pa(param), __pa(param + 5));
+ ret = omap_smc2(idx, flag, __pa(param));
+
+ return ret;
+}
diff --git a/arch/arm/mach-omap2/omap44xx-smc.S b/arch/arm/mach-omap2/omap-smc.S
similarity index 70%
rename from arch/arm/mach-omap2/omap44xx-smc.S
rename to arch/arm/mach-omap2/omap-smc.S
index e69d37d..f6441c1 100644
--- a/arch/arm/mach-omap2/omap44xx-smc.S
+++ b/arch/arm/mach-omap2/omap-smc.S
@@ -31,6 +31,29 @@ ENTRY(omap_smc1)
ldmfd sp!, {r2-r12, pc}
ENDPROC(omap_smc1)
+/**
+ * u32 omap_smc2(u32 id, u32 falg, u32 pargs)
+ * Low level common routine for secure HAL and PPA APIs.
+ * @id: Application ID of HAL APIs
+ * @flag: Flag to indicate the criticality of operation
+ * @pargs: Physical address of parameter list starting
+ * with number of parametrs
+ */
+ENTRY(omap_smc2)
+ stmfd sp!, {r4-r12, lr}
+ mov r3, r2
+ mov r2, r1
+ mov r1, #0x0 @ Process ID
+ mov r6, #0xff
+ mov r12, #0x00 @ Secure Service ID
+ mov r7, #0
+ mcr p15, 0, r7, c7, c5, 6
+ dsb
+ dmb
+ smc #0
+ ldmfd sp!, {r4-r12, pc}
+ENDPROC(omap_smc2)
+
ENTRY(omap_modify_auxcoreboot0)
stmfd sp!, {r1-r12, lr}
ldr r12, =0x104
--
1.7.4.1
^ permalink raw reply related [flat|nested] 119+ messages in thread* [PATCH 11/25] OMAP: Add Secure HAL and monitor mode API infrastructure.
2011-09-04 13:54 ` [PATCH 11/25] OMAP: Add Secure HAL and monitor mode API infrastructure Santosh Shilimkar
@ 2011-09-08 18:58 ` Jean Pihet
2011-09-09 4:22 ` Santosh
0 siblings, 1 reply; 119+ messages in thread
From: Jean Pihet @ 2011-09-08 18:58 UTC (permalink / raw)
To: linux-arm-kernel
Santosh,
On Sun, Sep 4, 2011 at 3:54 PM, Santosh Shilimkar
<santosh.shilimkar@ti.com> wrote:
> 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, omap44xx-smc.S to omap-smc.S since the common APIs
> can be used on other OMAP's too.
'move' or 'rename' is missing in the sentence.
Regards,
Jean
^ permalink raw reply [flat|nested] 119+ messages in thread
* [PATCH 11/25] OMAP: Add Secure HAL and monitor mode API infrastructure.
2011-09-08 18:58 ` Jean Pihet
@ 2011-09-09 4:22 ` Santosh
0 siblings, 0 replies; 119+ messages in thread
From: Santosh @ 2011-09-09 4:22 UTC (permalink / raw)
To: linux-arm-kernel
On Friday 09 September 2011 12:28 AM, Jean Pihet wrote:
> Santosh,
>
> On Sun, Sep 4, 2011 at 3:54 PM, Santosh Shilimkar
> <santosh.shilimkar@ti.com> wrote:
>> 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, omap44xx-smc.S to omap-smc.S since the common APIs
>> can be used on other OMAP's too.
> 'move' or 'rename' is missing in the sentence.
>
Yep. Will fix it.
Regards
Santosh
^ permalink raw reply [flat|nested] 119+ messages in thread
* [PATCH 12/25] OMAP: Add support to allocate the memory for secure RAM
2011-09-04 13:54 [PATCH 00/25] OMAP4: PM: suspend, CPU-hotplug and CPUilde support Santosh Shilimkar
` (10 preceding siblings ...)
2011-09-04 13:54 ` [PATCH 11/25] OMAP: Add Secure HAL and monitor mode API infrastructure Santosh Shilimkar
@ 2011-09-04 13:54 ` Santosh Shilimkar
2011-09-08 19:19 ` Jean Pihet
2011-09-04 13:54 ` [PATCH 13/25] OMAP4: PM: Add WakeupGen module as OMAP gic_arch_extn Santosh Shilimkar
` (15 subsequent siblings)
27 siblings, 1 reply; 119+ messages in thread
From: Santosh Shilimkar @ 2011-09-04 13:54 UTC (permalink / raw)
To: linux-arm-kernel
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 possible size is allocated and can cater to OMAP3XXX / OMAP4XXX
secure RAM size requirements.
Signed-off-by: Santosh Shilimkar <santosh.shilimkar@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_ENABLE 0x1
#define NO_FLAG 0x0
+/* 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 0xffffffff
@@ -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
^ permalink raw reply related [flat|nested] 119+ messages in thread* [PATCH 12/25] OMAP: Add support to allocate the memory for secure RAM
2011-09-04 13:54 ` [PATCH 12/25] OMAP: Add support to allocate the memory for secure RAM Santosh Shilimkar
@ 2011-09-08 19:19 ` Jean Pihet
2011-09-09 9:43 ` Santosh
0 siblings, 1 reply; 119+ messages in thread
From: Jean Pihet @ 2011-09-08 19:19 UTC (permalink / raw)
To: linux-arm-kernel
On Sun, Sep 4, 2011 at 3:54 PM, Santosh Shilimkar
<santosh.shilimkar@ti.com> wrote:
> 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 possible size is allocated and can cater to OMAP3XXX / OMAP4XXX
> secure RAM size requirements.
>
> Signed-off-by: Santosh Shilimkar <santosh.shilimkar@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_ENABLE ? ? ? ? ? ? ? ? ? ? ? ?0x1
> ?#define NO_FLAG ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?0x0
>
> +/* Maximum Secure memory storage size */
> +#define OMAP_SECURE_RAM_STORAGE ? ? ? ?(88 * SZ_1K)
Is this valid for all supported devices? How to differentiate
variations in the size for new chips variants in the future?
Regards,
Jean
^ permalink raw reply [flat|nested] 119+ messages in thread
* [PATCH 12/25] OMAP: Add support to allocate the memory for secure RAM
2011-09-08 19:19 ` Jean Pihet
@ 2011-09-09 9:43 ` Santosh
2011-09-09 12:54 ` Jean Pihet
0 siblings, 1 reply; 119+ messages in thread
From: Santosh @ 2011-09-09 9:43 UTC (permalink / raw)
To: linux-arm-kernel
On Friday 09 September 2011 12:49 AM, Jean Pihet wrote:
> On Sun, Sep 4, 2011 at 3:54 PM, Santosh Shilimkar
> <santosh.shilimkar@ti.com> wrote:
>> 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 possible size is allocated and can cater to OMAP3XXX / OMAP4XXX
>> secure RAM size requirements.
>>
>> Signed-off-by: Santosh Shilimkar<santosh.shilimkar@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_ENABLE 0x1
>> #define NO_FLAG 0x0
>>
>> +/* Maximum Secure memory storage size */
>> +#define OMAP_SECURE_RAM_STORAGE (88 * SZ_1K)
> Is this valid for all supported devices? How to differentiate
> variations in the size for new chips variants in the future?
>
You don't have to. ROM code does that job. We should just ensure
that maximum needed memory is made available to secure code.
Regards
Santosh
^ permalink raw reply [flat|nested] 119+ messages in thread
* [PATCH 12/25] OMAP: Add support to allocate the memory for secure RAM
2011-09-09 9:43 ` Santosh
@ 2011-09-09 12:54 ` Jean Pihet
2011-09-09 14:09 ` Shilimkar, Santosh
0 siblings, 1 reply; 119+ messages in thread
From: Jean Pihet @ 2011-09-09 12:54 UTC (permalink / raw)
To: linux-arm-kernel
Santosh,
On Fri, Sep 9, 2011 at 11:43 AM, Santosh <santosh.shilimkar@ti.com> wrote:
> On Friday 09 September 2011 12:49 AM, Jean Pihet wrote:
>>
>> On Sun, Sep 4, 2011 at 3:54 PM, Santosh Shilimkar
>> <santosh.shilimkar@ti.com> ?wrote:
>>>
>>> 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 possible size is allocated and can cater to OMAP3XXX / OMAP4XXX
>>> secure RAM size requirements.
>>>
>>> Signed-off-by: Santosh Shilimkar<santosh.shilimkar@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_ENABLE ? ? ? ? ? ? ? ? ? ? ? ?0x1
>>> ?#define NO_FLAG ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?0x0
>>>
>>> +/* Maximum Secure memory storage size */
>>> +#define OMAP_SECURE_RAM_STORAGE ? ? ? ?(88 * SZ_1K)
>>
>> Is this valid for all supported devices? How to differentiate
>> variations in the size for new chips variants in the future?
>>
> You don't have to. ROM code does that job. We should just ensure
> that maximum needed memory is made available to secure code.
The question was: what would be the code if tomorrow -for example- we
have OMAP4460 with 88K of secure RAM, OMAP5432 with 128K and OMAP6667
with 132K? How to code the differences?
Regards,
Jean
>
> Regards
> Santosh
>
^ permalink raw reply [flat|nested] 119+ messages in thread
* [PATCH 12/25] OMAP: Add support to allocate the memory for secure RAM
2011-09-09 12:54 ` Jean Pihet
@ 2011-09-09 14:09 ` Shilimkar, Santosh
0 siblings, 0 replies; 119+ messages in thread
From: Shilimkar, Santosh @ 2011-09-09 14:09 UTC (permalink / raw)
To: linux-arm-kernel
On Fri, Sep 9, 2011 at 6:24 PM, Jean Pihet <jean.pihet@newoldbits.com> wrote:
> Santosh,
>
> On Fri, Sep 9, 2011 at 11:43 AM, Santosh <santosh.shilimkar@ti.com> wrote:
>> On Friday 09 September 2011 12:49 AM, Jean Pihet wrote:
>>>
>>> On Sun, Sep 4, 2011 at 3:54 PM, Santosh Shilimkar
>>> <santosh.shilimkar@ti.com> ?wrote:
>>>>
>>>> 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 possible size is allocated and can cater to OMAP3XXX / OMAP4XXX
>>>> secure RAM size requirements.
>>>>
>>>> Signed-off-by: Santosh Shilimkar<santosh.shilimkar@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_ENABLE ? ? ? ? ? ? ? ? ? ? ? ?0x1
>>>> ?#define NO_FLAG ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?0x0
>>>>
>>>> +/* Maximum Secure memory storage size */
>>>> +#define OMAP_SECURE_RAM_STORAGE ? ? ? ?(88 * SZ_1K)
>>>
>>> Is this valid for all supported devices? How to differentiate
>>> variations in the size for new chips variants in the future?
>>>
>> You don't have to. ROM code does that job. We should just ensure
>> that maximum needed memory is made available to secure code.
> The question was: what would be the code if tomorrow -for example- we
> have OMAP4460 with 88K of secure RAM, OMAP5432 with 128K and OMAP6667
> with 132K? How to code the differences?
>
The size doesn't depend on silicon but depends on Secure software
stack size. As I
said, we will allocate maximum needed as per security team recommendation.
If on newer security stack, if we need more, we will just increase it
to maximum needed.
^ permalink raw reply [flat|nested] 119+ messages in thread
* [PATCH 13/25] OMAP4: PM: Add WakeupGen module as OMAP gic_arch_extn
2011-09-04 13:54 [PATCH 00/25] OMAP4: PM: suspend, CPU-hotplug and CPUilde support Santosh Shilimkar
` (11 preceding siblings ...)
2011-09-04 13:54 ` [PATCH 12/25] OMAP: Add support to allocate the memory for secure RAM Santosh Shilimkar
@ 2011-09-04 13:54 ` Santosh Shilimkar
2011-09-08 18:27 ` Kevin Hilman
` (2 more replies)
2011-09-04 13:54 ` [PATCH 14/25] OMAP4: PM: Add CPUX OFF mode support Santosh Shilimkar
` (14 subsequent siblings)
27 siblings, 3 replies; 119+ messages in thread
From: Santosh Shilimkar @ 2011-09-04 13:54 UTC (permalink / raw)
To: linux-arm-kernel
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 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.
Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
Cc: Kevin Hilman <khilman@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 | 241 +++++++++++++++++++++
arch/arm/mach-omap2/omap4-common.c | 3 +
4 files changed, 284 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 c53a8e8..b032c21 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 0000000..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.shilimkar@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_0 0x20
+#define OMAP_WKG_ENB_SECURE_B_0 0x24
+#define OMAP_WKG_ENB_SECURE_C_0 0x28
+#define OMAP_WKG_ENB_SECURE_D_0 0x2c
+#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_1 0x420
+#define OMAP_WKG_ENB_SECURE_B_1 0x424
+#define OMAP_WKG_ENB_SECURE_C_1 0x428
+#define OMAP_WKG_ENB_SECURE_D_1 0x42c
+#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 0000000..a0882e6
--- /dev/null
+++ b/arch/arm/mach-omap2/omap-wakeupgen.c
@@ -0,0 +1,241 @@
+/*
+ * 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.shilimkar@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>
+#include <linux/io.h>
+#include <linux/irq.h>
+#include <linux/platform_device.h>
+
+#include <asm/hardware/gic.h>
+
+#include <mach/omap-wakeupgen.h>
+
+#define NR_BANKS 4
+#define MAX_IRQS 128
+#define WKG_MASK_ALL 0x00000000
+#define WKG_UNMASK_ALL 0xffffffff
+#define CPU_ENA_OFFSET 0x400
+#define CPU0_ID 0x0
+#define CPU1_ID 0x1
+
+static void __iomem *wakeupgen_base;
+static DEFINE_PER_CPU(u32 [NR_BANKS], irqmasks);
+static DEFINE_SPINLOCK(wakeupgen_lock);
+static unsigned int irq_target_cpu[NR_IRQS];
+
+/*
+ * Static helper functions.
+ */
+static inline u32 wakeupgen_readl(u8 idx, u32 cpu)
+{
+ return __raw_readl(wakeupgen_base + OMAP_WKG_ENB_A_0 +
+ (cpu * CPU_ENA_OFFSET) + (idx * 4));
+}
+
+static inline void wakeupgen_writel(u32 val, u8 idx, u32 cpu)
+{
+ __raw_writel(val, wakeupgen_base + OMAP_WKG_ENB_A_0 +
+ (cpu * CPU_ENA_OFFSET) + (idx * 4));
+}
+
+static void _wakeupgen_set_all(unsigned int cpu, unsigned int reg)
+{
+ u8 i;
+
+ for (i = 0; i < NR_BANKS; i++)
+ wakeupgen_writel(reg, i, cpu);
+}
+
+static inline int _wakeupgen_get_irq_info(u32 irq, u32 *bit_posn, u8 *reg_index)
+{
+ unsigned int spi_irq;
+
+ /*
+ * PPIs and SGIs are not supported.
+ */
+ if (irq < OMAP44XX_IRQ_GIC_START)
+ return -EINVAL;
+
+ /*
+ * Subtract the GIC offset.
+ */
+ spi_irq = irq - OMAP44XX_IRQ_GIC_START;
+ if (spi_irq > MAX_IRQS) {
+ pr_err("omap wakeupGen: Invalid IRQ%d\n", irq);
+ return -EINVAL;
+ }
+
+ /*
+ * Each WakeupGen register controls 32 interrupt.
+ * i.e. 1 bit per SPI IRQ
+ */
+ *reg_index = spi_irq >> 5;
+ *bit_posn = spi_irq %= 32;
+
+ return 0;
+}
+
+static void _wakeupgen_clear(unsigned int irq, unsigned int cpu)
+{
+ u32 val, bit_number;
+ u8 i;
+
+ if (_wakeupgen_get_irq_info(irq, &bit_number, &i))
+ return;
+
+ val = wakeupgen_readl(i, cpu);
+ val &= ~BIT(bit_number);
+ wakeupgen_writel(val, i, cpu);
+}
+
+static void _wakeupgen_set(unsigned int irq, unsigned int cpu)
+{
+ u32 val, bit_number;
+ u8 i;
+
+ if (_wakeupgen_get_irq_info(irq, &bit_number, &i))
+ return;
+
+ val = wakeupgen_readl(i, cpu);
+ val |= BIT(bit_number);
+ wakeupgen_writel(val, i, cpu);
+}
+
+static void _wakeupgen_save_masks(unsigned int cpu)
+{
+ u8 i;
+
+ for (i = 0; i < NR_BANKS; i++)
+ per_cpu(irqmasks, cpu)[i] = wakeupgen_readl(i, cpu);
+}
+
+static void _wakeupgen_restore_masks(unsigned int cpu)
+{
+ u8 i;
+
+ for (i = 0; i < NR_BANKS; i++)
+ wakeupgen_writel(per_cpu(irqmasks, cpu)[i], i, cpu);
+}
+
+/*
+ * Architecture specific Mask extension
+ */
+static void wakeupgen_mask(struct irq_data *d)
+{
+ unsigned long flags;
+
+ spin_lock_irqsave(&wakeupgen_lock, flags);
+ _wakeupgen_clear(d->irq, irq_target_cpu[d->irq]);
+ spin_unlock_irqrestore(&wakeupgen_lock, flags);
+}
+
+/*
+ * Architecture specific Unmask extension
+ */
+static void wakeupgen_unmask(struct irq_data *d)
+{
+ unsigned long flags;
+
+ spin_lock_irqsave(&wakeupgen_lock, flags);
+ _wakeupgen_set(d->irq, irq_target_cpu[d->irq]);
+ spin_unlock_irqrestore(&wakeupgen_lock, flags);
+}
+
+#ifdef CONFIG_PM
+/*
+ * Masking wakeup irqs is handled by the IRQCHIP_MASK_ON_SUSPEND flag,
+ * so no action is necessary in set_wake, but implement an empty handler
+ * here to prevent enable_irq_wake() returning an error.
+ * FIXME: Remove the dummy handler once gen irq code fix above.
+ */
+static int wakeupgen_set_wake(struct irq_data *d, unsigned int on)
+{
+ return 0;
+}
+#else
+#define wakeupgen_set_wake NULL
+#endif
+
+/*
+ * Mask or unmask all interrupts on given CPU.
+ * 0 = Mask all interrupts on the 'cpu'
+ * 1 = Unmask all interrupts on the 'cpu'
+ * Ensure that the initial mask is maintained. This is faster than
+ * iterating through GIC registers to arrive at the correct masks.
+ */
+void wakeupgen_irqmask_all(unsigned int cpu, unsigned int set)
+{
+ unsigned long flags;
+
+ spin_lock_irqsave(&wakeupgen_lock, flags);
+ if (set) {
+ _wakeupgen_save_masks(cpu);
+ _wakeupgen_set_all(cpu, WKG_MASK_ALL);
+ } else {
+ _wakeupgen_set_all(cpu, WKG_UNMASK_ALL);
+ _wakeupgen_restore_masks(cpu);
+ }
+ spin_unlock_irqrestore(&wakeupgen_lock, flags);
+}
+
+/*
+ * Initialise the wakeupgen module.
+ */
+int __init omap_wakeupgen_init(void)
+{
+ int i;
+ unsigned int boot_cpu = smp_processor_id();
+
+ /* Not supported on OMAP4 ES1.0 silicon */
+ if (omap_rev() == OMAP4430_REV_ES1_0) {
+ WARN(1, "WakeupGen: Not supported on OMAP4430 ES1.0\n");
+ return -EPERM;
+ }
+
+ /* Static mapping, never released */
+ wakeupgen_base = ioremap(OMAP44XX_WKUPGEN_BASE, SZ_4K);
+ if (WARN_ON(!wakeupgen_base))
+ return -ENODEV;
+
+ /* Clear all IRQ bitmasks at wakeupGen level */
+ for (i = 0; i < NR_BANKS; i++) {
+ wakeupgen_writel(0, i, CPU0_ID);
+ wakeupgen_writel(0, i, CPU1_ID);
+ }
+
+ /*
+ * Override GIC architecture specific functions to add
+ * OMAP WakeupGen interrupt controller along with GIC
+ */
+ gic_arch_extn.irq_mask = wakeupgen_mask;
+ gic_arch_extn.irq_unmask = wakeupgen_unmask;
+ gic_arch_extn.irq_set_wake = wakeupgen_set_wake;
+ gic_arch_extn.flags = IRQCHIP_MASK_ON_SUSPEND;
+
+ /*
+ * FIXME: Add support to set_smp_affinity() once the core
+ * GIC code has necessary hooks in place.
+ */
+
+ /* Associate all the IRQs to boot CPU like GIC init does. */
+ for (i = 0; i < NR_IRQS; i++)
+ irq_target_cpu[i] = boot_cpu;
+
+ return 0;
+}
diff --git a/arch/arm/mach-omap2/omap4-common.c b/arch/arm/mach-omap2/omap4-common.c
index 1166ee4..49b65cf 100644
--- a/arch/arm/mach-omap2/omap4-common.c
+++ b/arch/arm/mach-omap2/omap4-common.c
@@ -25,6 +25,7 @@
#include <mach/hardware.h>
#include <mach/omap4-common.h>
+#include <mach/omap-wakeupgen.h>
#include "omap4-sar-layout.h"
@@ -94,6 +95,8 @@ void __init gic_init_irq(void)
omap_irq_base = ioremap(OMAP44XX_GIC_CPU_BASE, SZ_512);
BUG_ON(!omap_irq_base);
+ omap_wakeupgen_init();
+
gic_init(0, 29, gic_dist_base_addr, omap_irq_base);
}
--
1.7.4.1
^ permalink raw reply related [flat|nested] 119+ messages in thread* [PATCH 13/25] OMAP4: PM: Add WakeupGen module as OMAP gic_arch_extn
2011-09-04 13:54 ` [PATCH 13/25] OMAP4: PM: Add WakeupGen module as OMAP gic_arch_extn Santosh Shilimkar
@ 2011-09-08 18:27 ` Kevin Hilman
2011-09-09 4:29 ` Santosh
2011-09-08 19:16 ` Jean Pihet
2011-09-13 20:36 ` Tony Lindgren
2 siblings, 1 reply; 119+ messages in thread
From: Kevin Hilman @ 2011-09-08 18:27 UTC (permalink / raw)
To: linux-arm-kernel
Santosh Shilimkar <santosh.shilimkar@ti.com> writes:
> 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 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.
>
> Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
> Cc: Kevin Hilman <khilman@ti.com>
[...]
> +#ifdef CONFIG_PM
> +/*
> + * Masking wakeup irqs is handled by the IRQCHIP_MASK_ON_SUSPEND flag,
> + * so no action is necessary in set_wake, but implement an empty handler
> + * here to prevent enable_irq_wake() returning an error.
> + * FIXME: Remove the dummy handler once gen irq code fix above.
> + */
Just curious... is there a fix for this pending for v3.2?
Kevin
^ permalink raw reply [flat|nested] 119+ messages in thread
* [PATCH 13/25] OMAP4: PM: Add WakeupGen module as OMAP gic_arch_extn
2011-09-08 18:27 ` Kevin Hilman
@ 2011-09-09 4:29 ` Santosh
2011-09-09 7:19 ` Thomas Gleixner
0 siblings, 1 reply; 119+ messages in thread
From: Santosh @ 2011-09-09 4:29 UTC (permalink / raw)
To: linux-arm-kernel
On Thursday 08 September 2011 11:57 PM, Kevin Hilman wrote:
> Santosh Shilimkar<santosh.shilimkar@ti.com> writes:
>
>> 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 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.
>>
>> Signed-off-by: Santosh Shilimkar<santosh.shilimkar@ti.com>
>> Cc: Kevin Hilman<khilman@ti.com>
>
> [...]
>
>> +#ifdef CONFIG_PM
>> +/*
>> + * Masking wakeup irqs is handled by the IRQCHIP_MASK_ON_SUSPEND flag,
>> + * so no action is necessary in set_wake, but implement an empty handler
>> + * here to prevent enable_irq_wake() returning an error.
>> + * FIXME: Remove the dummy handler once gen irq code fix above.
>> + */
>
> Just curious... is there a fix for this pending for v3.2?
>
I have sent a proposed change to Thomas but have not seen
any response yet from him.
http://www.spinics.net/lists/arm-kernel/msg134297.html
Regards
Santosh
^ permalink raw reply [flat|nested] 119+ messages in thread
* [PATCH 13/25] OMAP4: PM: Add WakeupGen module as OMAP gic_arch_extn
2011-09-09 4:29 ` Santosh
@ 2011-09-09 7:19 ` Thomas Gleixner
2011-09-09 8:07 ` Santosh
0 siblings, 1 reply; 119+ messages in thread
From: Thomas Gleixner @ 2011-09-09 7:19 UTC (permalink / raw)
To: linux-arm-kernel
On Fri, 9 Sep 2011, Santosh wrote:
> On Thursday 08 September 2011 11:57 PM, Kevin Hilman wrote:
> > Santosh Shilimkar<santosh.shilimkar@ti.com> writes:
> >
> > > 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 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.
> > >
> > > Signed-off-by: Santosh Shilimkar<santosh.shilimkar@ti.com>
> > > Cc: Kevin Hilman<khilman@ti.com>
> >
> > [...]
> >
> > > +#ifdef CONFIG_PM
> > > +/*
> > > + * Masking wakeup irqs is handled by the IRQCHIP_MASK_ON_SUSPEND flag,
> > > + * so no action is necessary in set_wake, but implement an empty handler
> > > + * here to prevent enable_irq_wake() returning an error.
> > > + * FIXME: Remove the dummy handler once gen irq code fix above.
> > > + */
> >
> > Just curious... is there a fix for this pending for v3.2?
> >
> I have sent a proposed change to Thomas but have not seen
> any response yet from him.
>
> http://www.spinics.net/lists/arm-kernel/msg134297.html
diff --git a/kernel/irq/manage.c b/kernel/irq/manage.c
index 0a7840a..cd4bc01 100644
--- a/kernel/irq/manage.c
+++ b/kernel/irq/manage.c
@@ -467,6 +467,9 @@ static int set_irq_wake_real(unsigned int irq, unsigned int on)
struct irq_desc *desc = irq_to_desc(irq);
int ret = -ENXIO;
+ if (irq_desc_get_chip(desc)->flags & IRQCHIP_MASK_ON_SUSPEND)
+ return 0;
+
if (desc->irq_data.chip->irq_set_wake)
ret = desc->irq_data.chip->irq_set_wake(&desc->irq_data, on);
The flag says: MASK ON SUSPEND and it does not imply that you don't
need a wake function. There might be cases where you want to setup
stuff in that function in order to have the wakeup happen on that
interrupt line despite of the mask on suspend.
We either need a separate flag or a global dummy set_wake function in
the core to avoid empty copies all over the place.
Thanks,
tglx
^ permalink raw reply [flat|nested] 119+ messages in thread
* [PATCH 13/25] OMAP4: PM: Add WakeupGen module as OMAP gic_arch_extn
2011-09-09 7:19 ` Thomas Gleixner
@ 2011-09-09 8:07 ` Santosh
2011-09-09 8:18 ` Thomas Gleixner
0 siblings, 1 reply; 119+ messages in thread
From: Santosh @ 2011-09-09 8:07 UTC (permalink / raw)
To: linux-arm-kernel
On Friday 09 September 2011 12:49 PM, Thomas Gleixner wrote:
> On Fri, 9 Sep 2011, Santosh wrote:
>
>> On Thursday 08 September 2011 11:57 PM, Kevin Hilman wrote:
>>> Santosh Shilimkar<santosh.shilimkar@ti.com> writes:
>>>
>>>> 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 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.
>>>>
>>>> Signed-off-by: Santosh Shilimkar<santosh.shilimkar@ti.com>
>>>> Cc: Kevin Hilman<khilman@ti.com>
>>>
>>> [...]
>>>
>>>> +#ifdef CONFIG_PM
>>>> +/*
>>>> + * Masking wakeup irqs is handled by the IRQCHIP_MASK_ON_SUSPEND flag,
>>>> + * so no action is necessary in set_wake, but implement an empty handler
>>>> + * here to prevent enable_irq_wake() returning an error.
>>>> + * FIXME: Remove the dummy handler once gen irq code fix above.
>>>> + */
>>>
>>> Just curious... is there a fix for this pending for v3.2?
>>>
>> I have sent a proposed change to Thomas but have not seen
>> any response yet from him.
>>
>> http://www.spinics.net/lists/arm-kernel/msg134297.html
>
> diff --git a/kernel/irq/manage.c b/kernel/irq/manage.c
> index 0a7840a..cd4bc01 100644
> --- a/kernel/irq/manage.c
> +++ b/kernel/irq/manage.c
>
> @@ -467,6 +467,9 @@ static int set_irq_wake_real(unsigned int irq, unsigned int on)
>
> struct irq_desc *desc = irq_to_desc(irq);
> int ret = -ENXIO;
>
> + if (irq_desc_get_chip(desc)->flags& IRQCHIP_MASK_ON_SUSPEND)
> + return 0;
> +
> if (desc->irq_data.chip->irq_set_wake)
> ret = desc->irq_data.chip->irq_set_wake(&desc->irq_data, on);
>
> The flag says: MASK ON SUSPEND and it does not imply that you don't
> need a wake function. There might be cases where you want to setup
> stuff in that function in order to have the wakeup happen on that
> interrupt line despite of the mask on suspend.
>
I see your point.
> We either need a separate flag or a global dummy set_wake function in
> the core to avoid empty copies all over the place.
>
A flag is probably better since you mentioned that on some arch, there
might be need to have actual set_wake() handler. Or if the global
dummy can be over-ridden by platform, that's fine too.
Regards
Santosh
^ permalink raw reply [flat|nested] 119+ messages in thread
* [PATCH 13/25] OMAP4: PM: Add WakeupGen module as OMAP gic_arch_extn
2011-09-09 8:07 ` Santosh
@ 2011-09-09 8:18 ` Thomas Gleixner
2011-09-09 9:05 ` Santosh
0 siblings, 1 reply; 119+ messages in thread
From: Thomas Gleixner @ 2011-09-09 8:18 UTC (permalink / raw)
To: linux-arm-kernel
On Fri, 9 Sep 2011, Santosh wrote:
> On Friday 09 September 2011 12:49 PM, Thomas Gleixner wrote:
> >
> > The flag says: MASK ON SUSPEND and it does not imply that you don't
> > need a wake function. There might be cases where you want to setup
> > stuff in that function in order to have the wakeup happen on that
> > interrupt line despite of the mask on suspend.
> >
> I see your point.
>
> > We either need a separate flag or a global dummy set_wake function in
> > the core to avoid empty copies all over the place.
> >
> A flag is probably better since you mentioned that on some arch, there
> might be need to have actual set_wake() handler. Or if the global
> dummy can be over-ridden by platform, that's fine too.
Global dummy would mean:
int irq_set_wake_dummy(...)
{
return 0;
}
And you just add it to your chip, but either way I don't care whether
it's a dummy function or a flag.
Thanks,
tglx
^ permalink raw reply [flat|nested] 119+ messages in thread* [PATCH 13/25] OMAP4: PM: Add WakeupGen module as OMAP gic_arch_extn
2011-09-09 8:18 ` Thomas Gleixner
@ 2011-09-09 9:05 ` Santosh
2011-09-12 7:56 ` Thomas Gleixner
0 siblings, 1 reply; 119+ messages in thread
From: Santosh @ 2011-09-09 9:05 UTC (permalink / raw)
To: linux-arm-kernel
On Friday 09 September 2011 01:48 PM, Thomas Gleixner wrote:
> On Fri, 9 Sep 2011, Santosh wrote:
>> On Friday 09 September 2011 12:49 PM, Thomas Gleixner wrote:
>>>
>>> The flag says: MASK ON SUSPEND and it does not imply that you don't
>>> need a wake function. There might be cases where you want to setup
>>> stuff in that function in order to have the wakeup happen on that
>>> interrupt line despite of the mask on suspend.
>>>
>> I see your point.
>>
>>> We either need a separate flag or a global dummy set_wake function in
>>> the core to avoid empty copies all over the place.
>>>
>> A flag is probably better since you mentioned that on some arch, there
>> might be need to have actual set_wake() handler. Or if the global
>> dummy can be over-ridden by platform, that's fine too.
>
> Global dummy would mean:
>
> int irq_set_wake_dummy(...)
> {
> return 0;
> }
>
> And you just add it to your chip, but either way I don't care whether
> it's a dummy function or a flag.
>
Will below patch work for you then ?
Attaching the same in case mailer damages it.
Regards,
Santosh
From d63d4347dc8fb144b19f4d4e7c0621397cccea94 Mon Sep 17 00:00:00 2001
From: Santosh Shilimkar <santosh.shilimkar@ti.com>
Date: Fri, 9 Sep 2011 13:59:35 +0530
Subject: [PATCH] irq: Add IRQCHIP_SKIP_SET_WAKE flag to avoid need of
dummy set_wake() handler.
Certain IRQCHIP's may not need to install the irq_set_wake() handler if
the IRQCHIP_MASK_ON_SUSPEND flag is set. But but if it's not implemented,
enable_irq_wake() will return an error. That needs the IRQCHIP to install
an empty set_wake handler.
Add an 'IRQCHIP_SKIP_SET_WAKE' flag so that IRQCHIP can inform the core
irq code that irq_set_wake() handler is not necessary.
Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
---
include/linux/irq.h | 2 ++
kernel/irq/manage.c | 3 +++
2 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/include/linux/irq.h b/include/linux/irq.h
index 5951730..4b0d842 100644
--- a/include/linux/irq.h
+++ b/include/linux/irq.h
@@ -336,12 +336,14 @@ struct irq_chip {
* IRQCHIP_MASK_ON_SUSPEND: Mask non wake irqs in the suspend path
* IRQCHIP_ONOFFLINE_ENABLED: Only call irq_on/off_line callbacks
* when irq enabled
+ * IRQCHIP_SKIP_SET_WAKE: Skip chip.irq_set_wake(), for this IRQCHIP
*/
enum {
IRQCHIP_SET_TYPE_MASKED = (1 << 0),
IRQCHIP_EOI_IF_HANDLED = (1 << 1),
IRQCHIP_MASK_ON_SUSPEND = (1 << 2),
IRQCHIP_ONOFFLINE_ENABLED = (1 << 3),
+ IRQCHIP_SKIP_SET_WAKE = (1 << 4),
};
/* This include will go away once we isolated irq_desc usage to core
code */
diff --git a/kernel/irq/manage.c b/kernel/irq/manage.c
index 9b956fa..7e1a3ed 100644
--- a/kernel/irq/manage.c
+++ b/kernel/irq/manage.c
@@ -467,6 +467,9 @@ static int set_irq_wake_real(unsigned int irq,
unsigned int on)
struct irq_desc *desc = irq_to_desc(irq);
int ret = -ENXIO;
+ if (irq_desc_get_chip(desc)->flags & IRQCHIP_SKIP_SET_WAKE)
+ return 0;
+
if (desc->irq_data.chip->irq_set_wake)
ret = desc->irq_data.chip->irq_set_wake(&desc->irq_data, on);
--
1.7.4.1
^ permalink raw reply related [flat|nested] 119+ messages in thread* [PATCH 13/25] OMAP4: PM: Add WakeupGen module as OMAP gic_arch_extn
2011-09-09 9:05 ` Santosh
@ 2011-09-12 7:56 ` Thomas Gleixner
2011-09-12 8:44 ` Santosh
0 siblings, 1 reply; 119+ messages in thread
From: Thomas Gleixner @ 2011-09-12 7:56 UTC (permalink / raw)
To: linux-arm-kernel
On Fri, 9 Sep 2011, Santosh wrote:
> On Friday 09 September 2011 01:48 PM, Thomas Gleixner wrote:
> > On Fri, 9 Sep 2011, Santosh wrote:
> > > On Friday 09 September 2011 12:49 PM, Thomas Gleixner wrote:
> > > >
> > > > The flag says: MASK ON SUSPEND and it does not imply that you don't
> > > > need a wake function. There might be cases where you want to setup
> > > > stuff in that function in order to have the wakeup happen on that
> > > > interrupt line despite of the mask on suspend.
> > > >
> > > I see your point.
> > >
> > > > We either need a separate flag or a global dummy set_wake function in
> > > > the core to avoid empty copies all over the place.
> > > >
> > > A flag is probably better since you mentioned that on some arch, there
> > > might be need to have actual set_wake() handler. Or if the global
> > > dummy can be over-ridden by platform, that's fine too.
> >
> > Global dummy would mean:
> >
> > int irq_set_wake_dummy(...)
> > {
> > return 0;
> > }
> >
> > And you just add it to your chip, but either way I don't care whether
> > it's a dummy function or a flag.
> >
> Will below patch work for you then ?
> Attaching the same in case mailer damages it.
It does :)
> Regards,
> Santosh
>
> From d63d4347dc8fb144b19f4d4e7c0621397cccea94 Mon Sep 17 00:00:00 2001
> From: Santosh Shilimkar <santosh.shilimkar@ti.com>
> Date: Fri, 9 Sep 2011 13:59:35 +0530
> Subject: [PATCH] irq: Add IRQCHIP_SKIP_SET_WAKE flag to avoid need of dummy
> set_wake() handler.
>
> Certain IRQCHIP's may not need to install the irq_set_wake() handler if
> the IRQCHIP_MASK_ON_SUSPEND flag is set. But but if it's not implemented,
> enable_irq_wake() will return an error. That needs the IRQCHIP to install
> an empty set_wake handler.
>
> Add an 'IRQCHIP_SKIP_SET_WAKE' flag so that IRQCHIP can inform the core
> irq code that irq_set_wake() handler is not necessary.
>
> Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
> Cc: Thomas Gleixner <tglx@linutronix.de>
Queued to irq/core for 3.2
Thanks,
tglx
^ permalink raw reply [flat|nested] 119+ messages in thread* [PATCH 13/25] OMAP4: PM: Add WakeupGen module as OMAP gic_arch_extn
2011-09-12 7:56 ` Thomas Gleixner
@ 2011-09-12 8:44 ` Santosh
0 siblings, 0 replies; 119+ messages in thread
From: Santosh @ 2011-09-12 8:44 UTC (permalink / raw)
To: linux-arm-kernel
On Monday 12 September 2011 01:26 PM, Thomas Gleixner wrote:
> On Fri, 9 Sep 2011, Santosh wrote:
>
[..]
>> From d63d4347dc8fb144b19f4d4e7c0621397cccea94 Mon Sep 17 00:00:00 2001
>> From: Santosh Shilimkar<santosh.shilimkar@ti.com>
>> Date: Fri, 9 Sep 2011 13:59:35 +0530
>> Subject: [PATCH] irq: Add IRQCHIP_SKIP_SET_WAKE flag to avoid need of dummy
>> set_wake() handler.
>>
>> Certain IRQCHIP's may not need to install the irq_set_wake() handler if
>> the IRQCHIP_MASK_ON_SUSPEND flag is set. But but if it's not implemented,
>> enable_irq_wake() will return an error. That needs the IRQCHIP to install
>> an empty set_wake handler.
>>
>> Add an 'IRQCHIP_SKIP_SET_WAKE' flag so that IRQCHIP can inform the core
>> irq code that irq_set_wake() handler is not necessary.
>>
>> Signed-off-by: Santosh Shilimkar<santosh.shilimkar@ti.com>
>> Cc: Thomas Gleixner<tglx@linutronix.de>
>
> Queued to irq/core for 3.2
>
Thanks a lot Thomas.
Will update OMAP PM code based on above change.
Regards
Santosh
^ permalink raw reply [flat|nested] 119+ messages in thread
* [PATCH 13/25] OMAP4: PM: Add WakeupGen module as OMAP gic_arch_extn
2011-09-04 13:54 ` [PATCH 13/25] OMAP4: PM: Add WakeupGen module as OMAP gic_arch_extn Santosh Shilimkar
2011-09-08 18:27 ` Kevin Hilman
@ 2011-09-08 19:16 ` Jean Pihet
2011-09-09 4:23 ` Santosh
2011-09-13 20:36 ` Tony Lindgren
2 siblings, 1 reply; 119+ messages in thread
From: Jean Pihet @ 2011-09-08 19:16 UTC (permalink / raw)
To: linux-arm-kernel
On Sun, Sep 4, 2011 at 3:54 PM, Santosh Shilimkar
<santosh.shilimkar@ti.com> wrote:
> 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 wakeup event
... for generating the wakeup events
> from the incoming interrupts and enable bits. It is implemented
> in MPU always ON power domain. During normal operation,
in the MPU...
> WakeupGen delivers external interrupts directly to the GIC.
... delivers the external interrupts
>
> Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
> Cc: Kevin Hilman <khilman@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 ? ? ? ? ? ? ?| ?241 +++++++++++++++++++++
> ?arch/arm/mach-omap2/omap4-common.c ? ? ? ? ? ? ? ?| ? ?3 +
> ?4 files changed, 284 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
>
...
> + */
> +int __init omap_wakeupgen_init(void)
> +{
> + ? ? ? int i;
> + ? ? ? unsigned int boot_cpu = smp_processor_id();
> +
> + ? ? ? /* Not supported on OMAP4 ES1.0 silicon */
> + ? ? ? if (omap_rev() == OMAP4430_REV_ES1_0) {
> + ? ? ? ? ? ? ? WARN(1, "WakeupGen: Not supported on OMAP4430 ES1.0\n");
> + ? ? ? ? ? ? ? return -EPERM;
> + ? ? ? }
> +
> + ? ? ? /* Static mapping, never released */
> + ? ? ? wakeupgen_base = ioremap(OMAP44XX_WKUPGEN_BASE, SZ_4K);
> + ? ? ? if (WARN_ON(!wakeupgen_base))
> + ? ? ? ? ? ? ? return -ENODEV;
-ENOMEM os required as discussed in the other patches of the series.
Regards,
Jean
^ permalink raw reply [flat|nested] 119+ messages in thread* [PATCH 13/25] OMAP4: PM: Add WakeupGen module as OMAP gic_arch_extn
2011-09-08 19:16 ` Jean Pihet
@ 2011-09-09 4:23 ` Santosh
0 siblings, 0 replies; 119+ messages in thread
From: Santosh @ 2011-09-09 4:23 UTC (permalink / raw)
To: linux-arm-kernel
On Friday 09 September 2011 12:46 AM, Jean Pihet wrote:
> On Sun, Sep 4, 2011 at 3:54 PM, Santosh Shilimkar
> <santosh.shilimkar@ti.com> wrote:
>> 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 wakeup event
> ... for generating the wakeup events
>> from the incoming interrupts and enable bits. It is implemented
>> in MPU always ON power domain. During normal operation,
> in the MPU...
>> WakeupGen delivers external interrupts directly to the GIC.
> ... delivers the external interrupts
>
OK.
>> Signed-off-by: Santosh Shilimkar<santosh.shilimkar@ti.com>
>> Cc: Kevin Hilman<khilman@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 | 241 +++++++++++++++++++++
>> arch/arm/mach-omap2/omap4-common.c | 3 +
>> 4 files changed, 284 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
>>
> ...
>
>> + */
>> +int __init omap_wakeupgen_init(void)
>> +{
>> + int i;
>> + unsigned int boot_cpu = smp_processor_id();
>> +
>> + /* Not supported on OMAP4 ES1.0 silicon */
>> + if (omap_rev() == OMAP4430_REV_ES1_0) {
>> + WARN(1, "WakeupGen: Not supported on OMAP4430 ES1.0\n");
>> + return -EPERM;
>> + }
>> +
>> + /* Static mapping, never released */
>> + wakeupgen_base = ioremap(OMAP44XX_WKUPGEN_BASE, SZ_4K);
>> + if (WARN_ON(!wakeupgen_base))
>> + return -ENODEV;
> -ENOMEM os required as discussed in the other patches of the series.
>
Yep.
^ permalink raw reply [flat|nested] 119+ messages in thread
* [PATCH 13/25] OMAP4: PM: Add WakeupGen module as OMAP gic_arch_extn
2011-09-04 13:54 ` [PATCH 13/25] OMAP4: PM: Add WakeupGen module as OMAP gic_arch_extn Santosh Shilimkar
2011-09-08 18:27 ` Kevin Hilman
2011-09-08 19:16 ` Jean Pihet
@ 2011-09-13 20:36 ` Tony Lindgren
2011-09-14 5:34 ` Shilimkar, Santosh
2 siblings, 1 reply; 119+ messages in thread
From: Tony Lindgren @ 2011-09-13 20:36 UTC (permalink / raw)
To: linux-arm-kernel
* Santosh Shilimkar <santosh.shilimkar@ti.com> [110904 06:23]:
> 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 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.
...
> + /*
> + * Override GIC architecture specific functions to add
> + * OMAP WakeupGen interrupt controller along with GIC
> + */
> + gic_arch_extn.irq_mask = wakeupgen_mask;
> + gic_arch_extn.irq_unmask = wakeupgen_unmask;
> + gic_arch_extn.irq_set_wake = wakeupgen_set_wake;
> + gic_arch_extn.flags = IRQCHIP_MASK_ON_SUSPEND;
As I've commented before, there should not be any need to tweak
the wakeupgen registers for each interrupt during the runtime.
AFAIK the wakeupgen registers only need to be armed every time
before entering idle.
Regards,
Tony
^ permalink raw reply [flat|nested] 119+ messages in thread
* [PATCH 13/25] OMAP4: PM: Add WakeupGen module as OMAP gic_arch_extn
2011-09-13 20:36 ` Tony Lindgren
@ 2011-09-14 5:34 ` Shilimkar, Santosh
2011-09-14 15:21 ` Tony Lindgren
0 siblings, 1 reply; 119+ messages in thread
From: Shilimkar, Santosh @ 2011-09-14 5:34 UTC (permalink / raw)
To: linux-arm-kernel
Tony,
On Wed, Sep 14, 2011 at 2:06 AM, Tony Lindgren <tony@atomide.com> wrote:
> * Santosh Shilimkar <santosh.shilimkar@ti.com> [110904 06:23]:
>> 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 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.
> ...
>
>> + ? ? /*
>> + ? ? ?* Override GIC architecture specific functions to add
>> + ? ? ?* OMAP WakeupGen interrupt controller along with GIC
>> + ? ? ?*/
>> + ? ? gic_arch_extn.irq_mask = wakeupgen_mask;
>> + ? ? gic_arch_extn.irq_unmask = wakeupgen_unmask;
>> + ? ? gic_arch_extn.irq_set_wake = wakeupgen_set_wake;
>> + ? ? gic_arch_extn.flags = IRQCHIP_MASK_ON_SUSPEND;
>
> As I've commented before, there should not be any need to tweak
> the wakeupgen registers for each interrupt during the runtime.
>
And I gave you all the reasons why it needs to be done this way.
> AFAIK the wakeupgen registers only need to be armed every time
> before entering idle.
>
No that doesn't work and it completely hacky approach.
This problem is for all SOC's using A9 SMP and GIC and every soc
has an architecture specific interrupt controller extension. And that
was the reason the GIC arch_extn was proposed.
It's just another IRQCHIP and works seamlessly being part of the
framework. And it will also initialized with primary IRQCHIP( GIC).
Regards
Santosh
^ permalink raw reply [flat|nested] 119+ messages in thread
* [PATCH 13/25] OMAP4: PM: Add WakeupGen module as OMAP gic_arch_extn
2011-09-14 5:34 ` Shilimkar, Santosh
@ 2011-09-14 15:21 ` Tony Lindgren
2011-09-14 16:49 ` Santosh
0 siblings, 1 reply; 119+ messages in thread
From: Tony Lindgren @ 2011-09-14 15:21 UTC (permalink / raw)
To: linux-arm-kernel
* Shilimkar, Santosh <santosh.shilimkar@ti.com> [110913 22:01]:
> Tony,
> On Wed, Sep 14, 2011 at 2:06 AM, Tony Lindgren <tony@atomide.com> wrote:
> > * Santosh Shilimkar <santosh.shilimkar@ti.com> [110904 06:23]:
> >> 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 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.
> > ...
> >
> >> + ? ? /*
> >> + ? ? ?* Override GIC architecture specific functions to add
> >> + ? ? ?* OMAP WakeupGen interrupt controller along with GIC
> >> + ? ? ?*/
> >> + ? ? gic_arch_extn.irq_mask = wakeupgen_mask;
> >> + ? ? gic_arch_extn.irq_unmask = wakeupgen_unmask;
> >> + ? ? gic_arch_extn.irq_set_wake = wakeupgen_set_wake;
> >> + ? ? gic_arch_extn.flags = IRQCHIP_MASK_ON_SUSPEND;
> >
> > As I've commented before, there should not be any need to tweak
> > the wakeupgen registers for each interrupt during the runtime.
> >
> And I gave you all the reasons why it needs to be done this way.
Hmm, I don't think you ever answered the main question:
Why would you need to write the wakeupgen registers for every
interrupt during the runtime instead of arming them only when
entering idle?
> > AFAIK the wakeupgen registers only need to be armed every time
> > before entering idle.
> >
> No that doesn't work and it completely hacky approach.
And how is writing the registers over and over again unnecessarily
a non-hacky approach?
> This problem is for all SOC's using A9 SMP and GIC and every soc
> has an architecture specific interrupt controller extension. And that
> was the reason the GIC arch_extn was proposed.
> It's just another IRQCHIP and works seamlessly being part of the
> framework. And it will also initialized with primary IRQCHIP( GIC).
Sure, but I don't know if there is really a need for for that?
Regards,
Tony
^ permalink raw reply [flat|nested] 119+ messages in thread
* [PATCH 13/25] OMAP4: PM: Add WakeupGen module as OMAP gic_arch_extn
2011-09-14 15:21 ` Tony Lindgren
@ 2011-09-14 16:49 ` Santosh
2011-09-14 17:08 ` Tony Lindgren
0 siblings, 1 reply; 119+ messages in thread
From: Santosh @ 2011-09-14 16:49 UTC (permalink / raw)
To: linux-arm-kernel
On Wednesday 14 September 2011 08:51 PM, Tony Lindgren wrote:
> * Shilimkar, Santosh<santosh.shilimkar@ti.com> [110913 22:01]:
>> Tony,
>> On Wed, Sep 14, 2011 at 2:06 AM, Tony Lindgren<tony@atomide.com> wrote:
>>> * Santosh Shilimkar<santosh.shilimkar@ti.com> [110904 06:23]:
>>>> 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 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.
>>> ...
>>>
>>>> + /*
>>>> + * Override GIC architecture specific functions to add
>>>> + * OMAP WakeupGen interrupt controller along with GIC
>>>> + */
>>>> + gic_arch_extn.irq_mask = wakeupgen_mask;
>>>> + gic_arch_extn.irq_unmask = wakeupgen_unmask;
>>>> + gic_arch_extn.irq_set_wake = wakeupgen_set_wake;
>>>> + gic_arch_extn.flags = IRQCHIP_MASK_ON_SUSPEND;
>>>
>>> As I've commented before, there should not be any need to tweak
>>> the wakeupgen registers for each interrupt during the runtime.
>>>
>> And I gave you all the reasons why it needs to be done this way.
>
> Hmm, I don't think you ever answered the main question:
>
> Why would you need to write the wakeupgen registers for every
> interrupt during the runtime instead of arming them only when
> entering idle?
>
I thought I did that in last thread.
Let me try again,
First and foremost, I have to go with the approach here because MPUSS
hardware team put a requirement that GIC and wakeupgen should always be
kept in sync. If needed we can discuss this off-the list with Richard.
Below is the extract from the veyron func specs.
-------------------------------------
Version 1.6 of veyron spec has this.
From page 95, paragraph 2 on version 1.6:
"It is SW responsibility to program interrupt enabling/disabling
coherently in the GIC and in the Wugen enable registers. That is, a
given interrupt for a given CPU is either enable at both GIC and Wugen,
or disable at both, but no mix."
-------------------------------------
The way understand this IP is, even in normal scenario's every IRQ
will come to wakeupgen and then it will pass that to GIC. CPU clock
domains are kept under HW supervised always and they can enter inactive
any time without WFI. Only wakeup gen can bring the CPU out of inactive
state.
That's requirement really lead to this design choice. Just to add
all ARM SOC's using GIC has a gic extension interrupt controller and
follow the same approach for the secondary IRQCHIPO.
Below points as such don't matter after the strict hardware
requirement. Still .....
Let's say, we ignore the hardware recommendation and try
to do what you are suggesting.
How will you know while entering in idle which IRQ's to be
masked and which are to be unmasked ?
The only way is to run though entire 1024 possible IRQ's from GIC
and then check the state of each IRQ and set things accordingly.
At GIC level, mask and unmask registers are different so you will
end up reading those many registers. That also means you need to
export some non-standard APIs from GIC driver.
In system wide suspend, the core irq code, communicates
the wakeup and non-wakeup functionality using standard mask/
unmask APIs when used with IRQCHIP_MASK_ON_SUSPEND.
With what you are suggesting it won't work
as desired. Because that information is only passed
to the IRQ chips. So you will still need IRQCHIP and
mask/unmask APIs. That can be done as part of set_wake()
handler as well though.
The wakeupgen is within CPU cluster and the accesses
to it are not as expensive as like accessing 32 K timer or
GP timer.
By making the wakeupgen as an IRQCHIP, we meet the hardware
requirement and also make use of this IP properly for the
desired functionality using standard IRQCHIP interfaces
No need of non-standard hacking.
It also avoid platform code monkeing with common GIC code
and irq subsystem to hack the stuff.
Btw, not exactly related here, but because of common code consolidation,
we need to actually use GIC common
save/restore hooks, even though OMAP has very
optimal software save and hardware restore mechanism
for GIC.
Hope this email summarise all previous multiple discussions
in one place.
Regards
Santosh
^ permalink raw reply [flat|nested] 119+ messages in thread
* [PATCH 13/25] OMAP4: PM: Add WakeupGen module as OMAP gic_arch_extn
2011-09-14 16:49 ` Santosh
@ 2011-09-14 17:08 ` Tony Lindgren
2011-09-14 17:13 ` Santosh
0 siblings, 1 reply; 119+ messages in thread
From: Tony Lindgren @ 2011-09-14 17:08 UTC (permalink / raw)
To: linux-arm-kernel
* Santosh <santosh.shilimkar@ti.com> [110914 09:16]:
>
> First and foremost, I have to go with the approach here because MPUSS
> hardware team put a requirement that GIC and wakeupgen should always be
> kept in sync. If needed we can discuss this off-the list with Richard.
>
> Below is the extract from the veyron func specs.
> -------------------------------------
> Version 1.6 of veyron spec has this.
>
> From page 95, paragraph 2 on version 1.6:
>
> "It is SW responsibility to program interrupt enabling/disabling
> coherently in the GIC and in the Wugen enable registers. That is, a
> given interrupt for a given CPU is either enable at both GIC and Wugen,
> or disable at both, but no mix."
> -------------------------------------
>
> The way understand this IP is, even in normal scenario's every IRQ
> will come to wakeupgen and then it will pass that to GIC. CPU clock
> domains are kept under HW supervised always and they can enter inactive
> any time without WFI. Only wakeup gen can bring the CPU out of inactive
> state.
>
> That's requirement really lead to this design choice. Just to add
> all ARM SOC's using GIC has a gic extension interrupt controller and
> follow the same approach for the secondary IRQCHIPO.
Thanks for the clarification. It seems to me the spec is most likely
wrong as we've had the GIC working for over two years now without
doing anything with the wakeup gen registers :)
Of course the wakeup events probably don't work currently, but the
GIC interrupts certainly do. So most likely there's no need to
continuously syncronize the wakeup gen registers with the GIC
registers.
> Below points as such don't matter after the strict hardware
> requirement. Still .....
I think the issue is that you're assuming the spec is correct,
which does not seem to be the case here.
> Let's say, we ignore the hardware recommendation and try
> to do what you are suggesting.
>
> How will you know while entering in idle which IRQ's to be
> masked and which are to be unmasked ?
> The only way is to run though entire 1024 possible IRQ's from GIC
> and then check the state of each IRQ and set things accordingly.
> At GIC level, mask and unmask registers are different so you will
> end up reading those many registers. That also means you need to
> export some non-standard APIs from GIC driver.
When entering idle, we have plenty of time to do that. Sounds like
that could be easily implemented in a generic way.
> In system wide suspend, the core irq code, communicates
> the wakeup and non-wakeup functionality using standard mask/
> unmask APIs when used with IRQCHIP_MASK_ON_SUSPEND.
> With what you are suggesting it won't work
> as desired. Because that information is only passed
> to the IRQ chips. So you will still need IRQCHIP and
> mask/unmask APIs. That can be done as part of set_wake()
> handler as well though.
>
> The wakeupgen is within CPU cluster and the accesses
> to it are not as expensive as like accessing 32 K timer or
> GP timer.
Sure, but it still causes unnecesary writes for every interrupt.
There's no technical reason to do that.
> By making the wakeupgen as an IRQCHIP, we meet the hardware
> requirement and also make use of this IP properly for the
> desired functionality using standard IRQCHIP interfaces
> No need of non-standard hacking.
Well it seems the "hardware requirement" is based on a buggy
spec considering things are currently working.
> It also avoid platform code monkeing with common GIC code
> and irq subsystem to hack the stuff.
What I'm suggesting can be implemented in a generic way.
> Btw, not exactly related here, but because of common code
> consolidation, we need to actually use GIC common
> save/restore hooks, even though OMAP has very
> optimal software save and hardware restore mechanism
> for GIC.
>
> Hope this email summarise all previous multiple discussions
> in one place.
Thanks, but unfortunately it does not. To me it still seems
this is the wrong approach for the wakeup triggers.
Regards,
Tony
^ permalink raw reply [flat|nested] 119+ messages in thread
* [PATCH 13/25] OMAP4: PM: Add WakeupGen module as OMAP gic_arch_extn
2011-09-14 17:08 ` Tony Lindgren
@ 2011-09-14 17:13 ` Santosh
2011-09-14 17:18 ` Tony Lindgren
0 siblings, 1 reply; 119+ messages in thread
From: Santosh @ 2011-09-14 17:13 UTC (permalink / raw)
To: linux-arm-kernel
On Wednesday 14 September 2011 10:38 PM, Tony Lindgren wrote:
> * Santosh<santosh.shilimkar@ti.com> [110914 09:16]:
>>
>> First and foremost, I have to go with the approach here because MPUSS
>> hardware team put a requirement that GIC and wakeupgen should always be
>> kept in sync. If needed we can discuss this off-the list with Richard.
>>
>> Below is the extract from the veyron func specs.
>> -------------------------------------
>> Version 1.6 of veyron spec has this.
>>
>> From page 95, paragraph 2 on version 1.6:
>>
>> "It is SW responsibility to program interrupt enabling/disabling
>> coherently in the GIC and in the Wugen enable registers. That is, a
>> given interrupt for a given CPU is either enable at both GIC and Wugen,
>> or disable at both, but no mix."
>> -------------------------------------
>>
>> The way understand this IP is, even in normal scenario's every IRQ
>> will come to wakeupgen and then it will pass that to GIC. CPU clock
>> domains are kept under HW supervised always and they can enter inactive
>> any time without WFI. Only wakeup gen can bring the CPU out of inactive
>> state.
>>
>> That's requirement really lead to this design choice. Just to add
>> all ARM SOC's using GIC has a gic extension interrupt controller and
>> follow the same approach for the secondary IRQCHIPO.
>
> Thanks for the clarification. It seems to me the spec is most likely
> wrong as we've had the GIC working for over two years now without
> doing anything with the wakeup gen registers :)
>
It's working because CPU clockdomain are never put under HW
supervised mode and they are kept in force wakeup. Clock-domain
never idles on mainline code. PM series will put the clock-domains
under HW supervison as needed to achieve any low power states and
then all sorts of corner cases will come out.
Regards
Santosh
^ permalink raw reply [flat|nested] 119+ messages in thread
* [PATCH 13/25] OMAP4: PM: Add WakeupGen module as OMAP gic_arch_extn
2011-09-14 17:13 ` Santosh
@ 2011-09-14 17:18 ` Tony Lindgren
2011-09-14 17:21 ` Santosh
2011-09-14 17:22 ` Santosh
0 siblings, 2 replies; 119+ messages in thread
From: Tony Lindgren @ 2011-09-14 17:18 UTC (permalink / raw)
To: linux-arm-kernel
* Santosh <santosh.shilimkar@ti.com> [110914 09:40]:
> On Wednesday 14 September 2011 10:38 PM, Tony Lindgren wrote:
> >* Santosh<santosh.shilimkar@ti.com> [110914 09:16]:
> >
> >Thanks for the clarification. It seems to me the spec is most likely
> >wrong as we've had the GIC working for over two years now without
> >doing anything with the wakeup gen registers :)
> >
> It's working because CPU clockdomain are never put under HW
> supervised mode and they are kept in force wakeup. Clock-domain
> never idles on mainline code. PM series will put the clock-domains
> under HW supervison as needed to achieve any low power states and
> then all sorts of corner cases will come out.
But again the wakeup gen triggers only do something when hitting
idle. There should be no use for them during runtime, right?
Tony
^ permalink raw reply [flat|nested] 119+ messages in thread
* [PATCH 13/25] OMAP4: PM: Add WakeupGen module as OMAP gic_arch_extn
2011-09-14 17:18 ` Tony Lindgren
@ 2011-09-14 17:21 ` Santosh
2011-09-14 17:22 ` Santosh
1 sibling, 0 replies; 119+ messages in thread
From: Santosh @ 2011-09-14 17:21 UTC (permalink / raw)
To: linux-arm-kernel
On Wednesday 14 September 2011 10:48 PM, Tony Lindgren wrote:
> * Santosh<santosh.shilimkar@ti.com> [110914 09:40]:
>> On Wednesday 14 September 2011 10:38 PM, Tony Lindgren wrote:
>>> * Santosh<santosh.shilimkar@ti.com> [110914 09:16]:
>>>
>>> Thanks for the clarification. It seems to me the spec is most likely
>>> wrong as we've had the GIC working for over two years now without
>>> doing anything with the wakeup gen registers :)
>>>
>> It's working because CPU clockdomain are never put under HW
>> supervised mode and they are kept in force wakeup. Clock-domain
>> never idles on mainline code. PM series will put the clock-domains
>> under HW supervison as needed to achieve any low power states and
>> then all sorts of corner cases will come out.
>
> But again the wakeup gen triggers only do something when hitting
> idle. There should be no use for them during runtime, right?
>
You missed my point in the description. Clockdomain inactive
doesn't depend on idle or WFI execution. Under HW supervison
CPU clock domain can get into inactive when CPU is stalled and
waiting for a read response from slow interconnect.
Regards
Santosh
^ permalink raw reply [flat|nested] 119+ messages in thread
* [PATCH 13/25] OMAP4: PM: Add WakeupGen module as OMAP gic_arch_extn
2011-09-14 17:18 ` Tony Lindgren
2011-09-14 17:21 ` Santosh
@ 2011-09-14 17:22 ` Santosh
2011-09-14 19:04 ` Tony Lindgren
2011-09-15 9:36 ` Cousson, Benoit
1 sibling, 2 replies; 119+ messages in thread
From: Santosh @ 2011-09-14 17:22 UTC (permalink / raw)
To: linux-arm-kernel
On Wednesday 14 September 2011 10:48 PM, Tony Lindgren wrote:
> * Santosh<santosh.shilimkar@ti.com> [110914 09:40]:
>> On Wednesday 14 September 2011 10:38 PM, Tony Lindgren wrote:
>>> * Santosh<santosh.shilimkar@ti.com> [110914 09:16]:
>>>
>>> Thanks for the clarification. It seems to me the spec is most likely
>>> wrong as we've had the GIC working for over two years now without
>>> doing anything with the wakeup gen registers :)
>>>
>> It's working because CPU clockdomain are never put under HW
>> supervised mode and they are kept in force wakeup. Clock-domain
>> never idles on mainline code. PM series will put the clock-domains
>> under HW supervison as needed to achieve any low power states and
>> then all sorts of corner cases will come out.
>
> But again the wakeup gen triggers only do something when hitting
> idle. There should be no use for them during runtime, right?
>
You missed my point in the description. Clockdomain inactive
doesn't depend on idle or WFI execution. Under HW supervison
CPU clock domain can get into inactive when CPU is stalled and
waiting for a read response from slow interconnect.
One thing for sure. Designers has chosen a wrong name to this
IP. Wakeugen apears like needed only for low power wakeup which
not seems to be entirely correct as per specs
Regards
Santosh
^ permalink raw reply [flat|nested] 119+ messages in thread
* [PATCH 13/25] OMAP4: PM: Add WakeupGen module as OMAP gic_arch_extn
2011-09-14 17:22 ` Santosh
@ 2011-09-14 19:04 ` Tony Lindgren
2011-09-15 2:57 ` Santosh
2011-09-15 9:36 ` Cousson, Benoit
1 sibling, 1 reply; 119+ messages in thread
From: Tony Lindgren @ 2011-09-14 19:04 UTC (permalink / raw)
To: linux-arm-kernel
* Santosh <santosh.shilimkar@ti.com> [110914 09:49]:
> On Wednesday 14 September 2011 10:48 PM, Tony Lindgren wrote:
> >* Santosh<santosh.shilimkar@ti.com> [110914 09:40]:
> >>On Wednesday 14 September 2011 10:38 PM, Tony Lindgren wrote:
> >>>* Santosh<santosh.shilimkar@ti.com> [110914 09:16]:
> >>>
> >>>Thanks for the clarification. It seems to me the spec is most likely
> >>>wrong as we've had the GIC working for over two years now without
> >>>doing anything with the wakeup gen registers :)
> >>>
> >>It's working because CPU clockdomain are never put under HW
> >>supervised mode and they are kept in force wakeup. Clock-domain
> >>never idles on mainline code. PM series will put the clock-domains
> >>under HW supervison as needed to achieve any low power states and
> >>then all sorts of corner cases will come out.
> >
> >But again the wakeup gen triggers only do something when hitting
> >idle. There should be no use for them during runtime, right?
> >
> You missed my point in the description. Clockdomain inactive
> doesn't depend on idle or WFI execution. Under HW supervison
> CPU clock domain can get into inactive when CPU is stalled and
> waiting for a read response from slow interconnect.
Ah OK. If it's needed during runtime too then that explains why
the registers need to be kept in sync.
> One thing for sure. Designers has chosen a wrong name to this
> IP. Wakeugen apears like needed only for low power wakeup which
> not seems to be entirely correct as per specs
Yes it's not obvious reading the TRM either. Maybe add some
comment about that to the patch?
Regards,
Tony
^ permalink raw reply [flat|nested] 119+ messages in thread
* [PATCH 13/25] OMAP4: PM: Add WakeupGen module as OMAP gic_arch_extn
2011-09-14 19:04 ` Tony Lindgren
@ 2011-09-15 2:57 ` Santosh
0 siblings, 0 replies; 119+ messages in thread
From: Santosh @ 2011-09-15 2:57 UTC (permalink / raw)
To: linux-arm-kernel
On Thursday 15 September 2011 12:34 AM, Tony Lindgren wrote:
> * Santosh <santosh.shilimkar@ti.com> [110914 09:49]:
>> On Wednesday 14 September 2011 10:48 PM, Tony Lindgren wrote:
>>> * Santosh<santosh.shilimkar@ti.com> [110914 09:40]:
>>>> On Wednesday 14 September 2011 10:38 PM, Tony Lindgren wrote:
>>>>> * Santosh<santosh.shilimkar@ti.com> [110914 09:16]:
>>>>>
>>>>> Thanks for the clarification. It seems to me the spec is most likely
>>>>> wrong as we've had the GIC working for over two years now without
>>>>> doing anything with the wakeup gen registers :)
>>>>>
>>>> It's working because CPU clockdomain are never put under HW
>>>> supervised mode and they are kept in force wakeup. Clock-domain
>>>> never idles on mainline code. PM series will put the clock-domains
>>>> under HW supervison as needed to achieve any low power states and
>>>> then all sorts of corner cases will come out.
>>>
>>> But again the wakeup gen triggers only do something when hitting
>>> idle. There should be no use for them during runtime, right?
>>>
>> You missed my point in the description. Clockdomain inactive
>> doesn't depend on idle or WFI execution. Under HW supervison
>> CPU clock domain can get into inactive when CPU is stalled and
>> waiting for a read response from slow interconnect.
>
> Ah OK. If it's needed during runtime too then that explains why
> the registers need to be kept in sync.
>
>> One thing for sure. Designers has chosen a wrong name to this
>> IP. Wakeugen apears like needed only for low power wakeup which
>> not seems to be entirely correct as per specs
>
> Yes it's not obvious reading the TRM either. Maybe add some
> comment about that to the patch?
>
You are right. Documentation isn't clear about this. Will
add the above point in change log.
btw, thanks for the good discussion on this topic.
Regards
Santosh
^ permalink raw reply [flat|nested] 119+ messages in thread
* [PATCH 13/25] OMAP4: PM: Add WakeupGen module as OMAP gic_arch_extn
2011-09-14 17:22 ` Santosh
2011-09-14 19:04 ` Tony Lindgren
@ 2011-09-15 9:36 ` Cousson, Benoit
2011-09-15 12:02 ` Shilimkar, Santosh
1 sibling, 1 reply; 119+ messages in thread
From: Cousson, Benoit @ 2011-09-15 9:36 UTC (permalink / raw)
To: linux-arm-kernel
Hi Santosh,
On 9/14/2011 7:22 PM, Shilimkar, Santosh wrote:
> On Wednesday 14 September 2011 10:48 PM, Tony Lindgren wrote:
>> * Santosh<santosh.shilimkar@ti.com> [110914 09:40]:
>>> On Wednesday 14 September 2011 10:38 PM, Tony Lindgren wrote:
>>>> * Santosh<santosh.shilimkar@ti.com> [110914 09:16]:
>>>>
>>>> Thanks for the clarification. It seems to me the spec is most likely
>>>> wrong as we've had the GIC working for over two years now without
>>>> doing anything with the wakeup gen registers :)
>>>>
>>> It's working because CPU clockdomain are never put under HW
>>> supervised mode and they are kept in force wakeup. Clock-domain
>>> never idles on mainline code. PM series will put the clock-domains
>>> under HW supervison as needed to achieve any low power states and
>>> then all sorts of corner cases will come out.
>>
>> But again the wakeup gen triggers only do something when hitting
>> idle. There should be no use for them during runtime, right?
>>
> You missed my point in the description. Clockdomain inactive
> doesn't depend on idle or WFI execution. Under HW supervison
> CPU clock domain can get into inactive when CPU is stalled and
> waiting for a read response from slow interconnect.
I'm a little bit confused by that statement...
I'm wondering how the PRCM can gate the CPU/MPU clock and re-enable it
if the MPU is gated? What kind of event can wakeup the CPU in case of
CPU stalled?
The spec seems to indicate that wakeupgen is needed only if CPU are in
WFI. It is even written: "CPUx will change power state only when
StandbyWFI is asserted.". Even a WFE is not supposed to trigger a standby.
How can the CPU be inactive at clock domain level without a WFI?
Regards,
Benoit
^ permalink raw reply [flat|nested] 119+ messages in thread
* [PATCH 13/25] OMAP4: PM: Add WakeupGen module as OMAP gic_arch_extn
2011-09-15 9:36 ` Cousson, Benoit
@ 2011-09-15 12:02 ` Shilimkar, Santosh
2011-09-15 13:29 ` Woodruff, Richard
0 siblings, 1 reply; 119+ messages in thread
From: Shilimkar, Santosh @ 2011-09-15 12:02 UTC (permalink / raw)
To: linux-arm-kernel
On Thu, Sep 15, 2011 at 3:06 PM, Cousson, Benoit <b-cousson@ti.com> wrote:
> Hi Santosh,
>
> On 9/14/2011 7:22 PM, Shilimkar, Santosh wrote:
>>
>> On Wednesday 14 September 2011 10:48 PM, Tony Lindgren wrote:
>>>
>>> * Santosh<santosh.shilimkar@ti.com> ? [110914 09:40]:
>>>>
>>>> On Wednesday 14 September 2011 10:38 PM, Tony Lindgren wrote:
>>>>>
>>>>> * Santosh<santosh.shilimkar@ti.com> ? ?[110914 09:16]:
>>>>>
>>>>> Thanks for the clarification. It seems to me the spec is most likely
>>>>> wrong as we've had the GIC working for over two years now without
>>>>> doing anything with the wakeup gen registers :)
>>>>>
>>>> It's working because CPU clockdomain are never put under HW
>>>> supervised mode and they are kept in force wakeup. Clock-domain
>>>> never idles on mainline code. PM series will put the clock-domains
>>>> under HW supervison as needed to achieve any low power states and
>>>> then all sorts of corner cases will come out.
>>>
>>> But again the wakeup gen triggers only do something when hitting
>>> idle. There should be no use for them during runtime, right?
>>>
>> You missed my point in the description. Clockdomain inactive
>> doesn't depend on idle or WFI execution. Under HW supervison
>> CPU clock domain can get into inactive when CPU is stalled and
>> waiting for a read response from slow interconnect.
>
> I'm a little bit confused by that statement...
>
> I'm wondering how the PRCM can gate the CPU/MPU clock and re-enable it if
> the MPU is gated? What kind of event can wakeup the CPU in case of CPU
> stalled?
>
> The spec seems to indicate that wakeupgen is needed only if CPU are in WFI.
> It is even written: "CPUx will change power state only when StandbyWFI is
> asserted.". Even a WFE is not supposed to trigger a standby.
> How can the CPU be inactive at clock domain level without a WFI?
>
I mean only CPU clock domain and not the power domain inactive
and local CPU clock can be gated without WFI when clock domain
is kept under hardware supervision.
But I agree with you that, for the stalled case, wakeupgen can't
generate any event and it will LPRM state-machine which take
care of un-gating the clock for that local CPU.
I have been discussing today morning with design IP team on the
restriction in the functional specs and they said they will check and
comeback.
For now, I would like to go with what specs says. By next merge window,
am sure we will be clear inputs from IP team on this and if it happens
that the requirement needs to be changed and we need not do
mask/unmask in non-low power scenario, we can start looking
at other aspects as Tony suggested.
Regards
Santosh
^ permalink raw reply [flat|nested] 119+ messages in thread
* [PATCH 13/25] OMAP4: PM: Add WakeupGen module as OMAP gic_arch_extn
2011-09-15 12:02 ` Shilimkar, Santosh
@ 2011-09-15 13:29 ` Woodruff, Richard
0 siblings, 0 replies; 119+ messages in thread
From: Woodruff, Richard @ 2011-09-15 13:29 UTC (permalink / raw)
To: linux-arm-kernel
> From: Shilimkar, Santosh
> Sent: Thursday, September 15, 2011 7:02 AM
> >> You missed my point in the description. Clockdomain inactive
> >> doesn't depend on idle or WFI execution. Under HW supervison
> >> CPU clock domain can get into inactive when CPU is stalled and
> >> waiting for a read response from slow interconnect.
My understanding is MPSS global clock domain can not gate unless each cpu is in wfi and other conditions are met. Other conditions are a wugen ack that there are no irqs and ocp-bridge logic giving its ok.
What kind of local clock gating is there per cpu or sub-clock domains is not as clear. The mpu's pivot on individual wfi while other blocks in mpuss have other considerations.
The spec is very clear about coherent programmation of wugen and gic. Like being discussed.
Its examples are about how wugen used I've heard about are around transition in and out of standbys at wfi. Wugen will process all irqs before giving ack to sleep, it also has ability to fail sleep if new irqs come in before final idle.
* It may be possible depending on clarifications to handle near wfi, but you might have to do it for -every- cpu's wfi unless you can coordinate who the last one is. Doing it as you go with gic would avoid redoing work over and over at the many wfi calls. This extra work costs in latency and power.
Doing housekeeping along with gic seems better from a run time perspective.
Regards,
Richard W.
^ permalink raw reply [flat|nested] 119+ messages in thread
* [PATCH 14/25] OMAP4: PM: Add CPUX OFF mode support
2011-09-04 13:54 [PATCH 00/25] OMAP4: PM: suspend, CPU-hotplug and CPUilde support Santosh Shilimkar
` (12 preceding siblings ...)
2011-09-04 13:54 ` [PATCH 13/25] OMAP4: PM: Add WakeupGen module as OMAP gic_arch_extn Santosh Shilimkar
@ 2011-09-04 13:54 ` Santosh Shilimkar
2011-09-08 19:39 ` Jean Pihet
` (2 more replies)
2011-09-04 13:54 ` [PATCH 15/25] OMAP4: Remove __INIT from omap_secondary_startup() to re-use it for hotplug Santosh Shilimkar
` (13 subsequent siblings)
27 siblings, 3 replies; 119+ messages in thread
From: Santosh Shilimkar @ 2011-09-04 13:54 UTC (permalink / raw)
To: linux-arm-kernel
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.shilimkar@ti.com>
Cc: Kevin Hilman <khilman@ti.com>
---
arch/arm/mach-omap2/Makefile | 3 +-
arch/arm/mach-omap2/include/mach/omap-secure.h | 8 +
arch/arm/mach-omap2/include/mach/omap4-common.h | 25 +++
arch/arm/mach-omap2/omap-mpuss-lowpower.c | 249 +++++++++++++++++++++++
arch/arm/mach-omap2/omap-smp.c | 6 +
arch/arm/mach-omap2/omap4-sar-layout.h | 9 +
arch/arm/mach-omap2/pm44xx.c | 6 +
arch/arm/mach-omap2/sleep44xx.S | 213 +++++++++++++++++++
8 files changed, 518 insertions(+), 1 deletions(-)
create mode 100644 arch/arm/mach-omap2/omap-mpuss-lowpower.c
diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index b032c21..b4f2eeb 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -63,7 +63,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 sleep44xx.o
+obj-$(CONFIG_ARCH_OMAP4) += pm44xx.o sleep44xx.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_INDEX 0x1c
#define OMAP4_HAL_SAVEGIC_INDEX 0x1d
+/* Secure Monitor mode APIs */
+#define OMAP4_MON_SCU_PWR_INDEX 0x108
+
+/* 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 040dcf6..662f37c 100644
--- a/arch/arm/mach-omap2/include/mach/omap4-common.h
+++ b/arch/arm/mach-omap2/include/mach/omap4-common.h
@@ -45,5 +45,30 @@ 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)
+{
+ omap_do_wfi();
+ return 0;
+}
+
+static inline int omap4_mpuss_init(void)
+{
+ return 0;
+}
+
+static inline int omap4_finish_suspend(unsigned long cpu_state)
+{}
+static inline void omap4_cpu_resume(void)
+{}
+#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
new file mode 100644
index 0000000..1137537
--- /dev/null
+++ b/arch/arm/mach-omap2/omap-mpuss-lowpower.c
@@ -0,0 +1,249 @@
+/*
+ * OMAP MPUSS low power code
+ *
+ * Copyright (C) 2011 Texas Instruments, Inc.
+ * Santosh Shilimkar <santosh.shilimkar@ti.com>
+ *
+ * OMAP4430 MPUSS mainly consists of dual Cortex-A9 with per-CPU
+ * Local timer and Watchdog, GIC, SCU, PL310 L2 cache controller,
+ * CPU0 and CPU1 LPRM modules.
+ * CPU0, CPU1 and MPUSS each have there own power domain and
+ * hence multiple low power combinations of MPUSS are possible.
+ *
+ * The CPU0 and CPU1 can't support Closed switch Retention (CSWR)
+ * because the mode is not supported by hw constraints of dormant
+ * mode. While waking up from the dormant mode, a reset signal
+ * to the Cortex-A9 processor must be asserted by the external
+ * power controller.
+ *
+ * With architectural inputs and hardware recommendations, only
+ * below modes are supported from power gain vs latency point of view.
+ *
+ * CPU0 CPU1 MPUSS
+ * ----------------------------------------------
+ * ON ON ON
+ * ON(Inactive) OFF ON(Inactive)
+ * OFF OFF CSWR
+ * OFF OFF OSWR (*TBD)
+ * OFF OFF OFF* (*TBD)
+ * ----------------------------------------------
+ *
+ * Note: CPU0 is the master core and it is the last CPU to go down
+ * and first to wake-up when MPUSS low power states are excercised
+ *
+ *
+ * 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/io.h>
+#include <linux/errno.h>
+#include <linux/linkage.h>
+#include <linux/smp.h>
+
+#include <asm/cacheflush.h>
+#include <asm/tlbflush.h>
+#include <asm/smp_scu.h>
+#include <asm/system.h>
+#include <asm/pgalloc.h>
+#include <asm/suspend.h>
+
+#include <plat/omap44xx.h>
+#include <mach/omap4-common.h>
+
+#include "omap4-sar-layout.h"
+#include "pm.h"
+#include "powerdomain.h"
+
+#ifdef CONFIG_SMP
+
+struct omap4_cpu_pm_info {
+ struct powerdomain *pwrdm;
+ void __iomem *scu_sar_addr;
+ void __iomem *wkup_sar_addr;
+};
+
+static DEFINE_PER_CPU(struct omap4_cpu_pm_info, omap4_pm_info);
+
+/*
+ * Program the wakeup routine address for the CPU0 and CPU1
+ * used for OFF or DORMANT wakeup.
+ */
+static inline void set_cpu_wakeup_addr(unsigned int cpu_id, u32 addr)
+{
+ struct omap4_cpu_pm_info *pm_info = &per_cpu(omap4_pm_info, cpu_id);
+
+ __raw_writel(addr, pm_info->wkup_sar_addr);
+}
+
+/*
+ * Set the CPUx powerdomain's previous power state
+ */
+static inline void set_cpu_next_pwrst(unsigned int cpu_id,
+ unsigned int power_state)
+{
+ struct omap4_cpu_pm_info *pm_info = &per_cpu(omap4_pm_info, cpu_id);
+
+ pwrdm_set_next_pwrst(pm_info->pwrdm, power_state);
+}
+
+/*
+ * Read CPU's previous power state
+ */
+static inline unsigned int read_cpu_prev_pwrst(unsigned int cpu_id)
+{
+ struct omap4_cpu_pm_info *pm_info = &per_cpu(omap4_pm_info, cpu_id);
+
+ return pwrdm_read_prev_pwrst(pm_info->pwrdm);
+}
+
+/*
+ * Clear the CPUx powerdomain's previous power state
+ */
+static inline void clear_cpu_prev_pwrst(unsigned int cpu_id)
+{
+ struct omap4_cpu_pm_info *pm_info = &per_cpu(omap4_pm_info, cpu_id);
+
+ pwrdm_clear_all_prev_pwrst(pm_info->pwrdm);
+}
+
+/*
+ * Store the SCU power status value to scratchpad memory
+ */
+static void scu_pwrst_prepare(unsigned int cpu_id, unsigned int cpu_state)
+{
+ struct omap4_cpu_pm_info *pm_info = &per_cpu(omap4_pm_info, cpu_id);
+ u32 scu_pwr_st;
+
+ switch (cpu_state) {
+ case PWRDM_POWER_RET:
+ scu_pwr_st = SCU_PM_DORMANT;
+ break;
+ case PWRDM_POWER_OFF:
+ scu_pwr_st = SCU_PM_POWEROFF;
+ break;
+ case PWRDM_POWER_ON:
+ case PWRDM_POWER_INACTIVE:
+ default:
+ scu_pwr_st = SCU_PM_NORMAL;
+ break;
+ }
+
+ __raw_writel(scu_pwr_st, pm_info->scu_sar_addr);
+}
+
+/**
+ * omap4_enter_lowpower: OMAP4 MPUSS Low Power Entry Function
+ * The purpose of this function is to manage low power programming
+ * of OMAP4 MPUSS subsystem
+ * @cpu : CPU ID
+ * @power_state: Low power state.
+ */
+int omap4_enter_lowpower(unsigned int cpu, unsigned int power_state)
+{
+ unsigned int save_state = 0;
+ unsigned int wakeup_cpu;
+
+ if (omap_rev() == OMAP4430_REV_ES1_0)
+ return -ENXIO;
+
+ switch (power_state) {
+ case PWRDM_POWER_ON:
+ case PWRDM_POWER_INACTIVE:
+ save_state = 0;
+ break;
+ case PWRDM_POWER_OFF:
+ save_state = 1;
+ break;
+ case PWRDM_POWER_RET:
+ default:
+ /*
+ * CPUx CSWR is invalid hardware state. Also CPUx OSWR
+ * doesn't make much scense, since logic is lost and $L1
+ * needs to be cleaned because of coherency. This makes
+ * CPUx OSWR equivalent to CPUX OFF and hence not supported
+ */
+ WARN_ON(1);
+ return -ENXIO;
+ }
+
+ clear_cpu_prev_pwrst(cpu);
+ set_cpu_next_pwrst(cpu, power_state);
+ set_cpu_wakeup_addr(cpu, virt_to_phys(omap4_cpu_resume));
+ scu_pwrst_prepare(cpu, power_state);
+
+ /*
+ * Call low level function with targeted CPU id
+ * and its low power state.
+ */
+ cpu_suspend(save_state, omap4_finish_suspend);
+
+ /*
+ * Restore the CPUx power state to ON otherwise CPUx
+ * power domain can transitions to programmed low power
+ * state while doing WFI outside the low powe code. On
+ * secure devices, CPUx does WFI which can result in
+ * domain transition
+ */
+ wakeup_cpu = smp_processor_id();
+ set_cpu_next_pwrst(wakeup_cpu, PWRDM_POWER_ON);
+
+ return 0;
+}
+
+/*
+ * Initialise OMAP4 MPUSS
+ */
+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;
+ }
+
+ /* 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->pwrdm = pwrdm_lookup("cpu0_pwrdm");
+ if (!pm_info->pwrdm) {
+ pr_err("Lookup failed for CPU0 pwrdm\n");
+ return -ENODEV;
+ }
+
+ /* Clear CPU previous power domain state */
+ pwrdm_clear_all_prev_pwrst(pm_info->pwrdm);
+
+ /* Initialise CPU0 power domain state to ON */
+ pwrdm_set_next_pwrst(pm_info->pwrdm, PWRDM_POWER_ON);
+
+ 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->pwrdm = pwrdm_lookup("cpu1_pwrdm");
+ if (!pm_info->pwrdm) {
+ pr_err("Lookup failed for CPU1 pwrdm\n");
+ return -ENODEV;
+ }
+
+ /* Clear CPU previous power domain state */
+ pwrdm_clear_all_prev_pwrst(pm_info->pwrdm);
+
+ /* Initialise CPU1 power domain state to ON */
+ pwrdm_set_next_pwrst(pm_info->pwrdm, PWRDM_POWER_ON);
+
+ /* 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);
+ else
+ __raw_writel(0, sar_base + OMAP_TYPE_OFFSET);
+
+ return 0;
+}
+
+#endif
diff --git a/arch/arm/mach-omap2/omap-smp.c b/arch/arm/mach-omap2/omap-smp.c
index 8e9b491..f920abe 100644
--- a/arch/arm/mach-omap2/omap-smp.c
+++ b/arch/arm/mach-omap2/omap-smp.c
@@ -25,6 +25,7 @@
#include <asm/smp_scu.h>
#include <mach/hardware.h>
#include <mach/omap4-common.h>
+#include <mach/omap-secure.h>
/* SCU base address */
static void __iomem *scu_base;
@@ -38,6 +39,11 @@ void __iomem *omap4_get_scu_base(void)
void __cpuinit platform_secondary_init(unsigned int cpu)
{
+ /* Enable NS access to SMP bit for this CPU on EMU/HS devices */
+ if (cpu_is_omap443x() && (omap_type() != OMAP2_DEVICE_TYPE_GP))
+ omap_secure_dispatcher(OMAP4_PPA_CPU_ACTRL_SMP_INDEX,
+ 4, 0, 0, 0, 0, 0);
+
/*
* If any interrupts are already enabled for the primary
* core (e.g. timer irq), then they will not have been enabled
diff --git a/arch/arm/mach-omap2/omap4-sar-layout.h b/arch/arm/mach-omap2/omap4-sar-layout.h
index 7781ea4..970a2ee 100644
--- a/arch/arm/mach-omap2/omap4-sar-layout.h
+++ b/arch/arm/mach-omap2/omap4-sar-layout.h
@@ -19,4 +19,13 @@
#define SAR_BANK3_OFFSET 0x2000
#define SAR_BANK4_OFFSET 0x3000
+/* Scratch pad memory offsets from SAR_BANK1 */
+#define SCU_OFFSET0 0xd00
+#define SCU_OFFSET1 0xd04
+#define OMAP_TYPE_OFFSET 0xd10
+
+/* CPUx Wakeup Non-Secure Physical Address offsets in SAR_BANK3 */
+#define CPU0_WAKEUP_NS_PA_ADDR_OFFSET 0xa04
+#define CPU1_WAKEUP_NS_PA_ADDR_OFFSET 0xa08
+
#endif
diff --git a/arch/arm/mach-omap2/pm44xx.c b/arch/arm/mach-omap2/pm44xx.c
index 44ce15c..4f39de5 100644
--- a/arch/arm/mach-omap2/pm44xx.c
+++ b/arch/arm/mach-omap2/pm44xx.c
@@ -178,6 +178,12 @@ static int __init omap4_pm_init(void)
goto err2;
}
+ ret = omap4_mpuss_init();
+ if (ret) {
+ pr_err("Failed to initialise OMAP4 MPUSS\n");
+ goto err2;
+ }
+
(void) clkdm_for_each(clkdms_setup, NULL);
#ifdef CONFIG_SUSPEND
diff --git a/arch/arm/mach-omap2/sleep44xx.S b/arch/arm/mach-omap2/sleep44xx.S
index 049f426..230ab8c 100644
--- a/arch/arm/mach-omap2/sleep44xx.S
+++ b/arch/arm/mach-omap2/sleep44xx.S
@@ -11,8 +11,221 @@
#include <linux/linkage.h>
#include <asm/system.h>
+#include <asm/smp_scu.h>
+#include <asm/memory.h>
+#include <asm/hardware/cache-l2x0.h>
+#include <plat/omap44xx.h>
#include <mach/omap4-common.h>
+#include <mach/omap-secure.h>
+
+#include "omap4-sar-layout.h"
+
+#ifdef CONFIG_SMP
+
+.macro DO_SMC
+ dsb
+ smc #0
+ dsb
+.endm
+
+ppa_zero_params:
+ .word 0x0
+
+/*
+ * =============================
+ * == CPU suspend finisher ==
+ * =============================
+ *
+ * void omap4_finish_suspend(unsigned long cpu_state)
+ *
+ * This function code saves the CPU context and performs the CPU
+ * power down sequence. Calling WFI effectively changes the CPU
+ * power domains states to the desired target power state.
+ *
+ * @cpu_state : contains context save state (r0)
+ * 0 - No context lost
+ * 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: MPUSS OFF
+ * @return: This function never returns for CPU OFF and DORMANT power states.
+ * Post WFI, CPU transitions to DORMANT or OFF power state and on wake-up
+ * from this follows a full CPU reset path via ROM code to CPU restore code.
+ * It returns to the caller for CPU INACTIVE and ON power states or in case
+ * CPU failed to transition to targeted OFF/DORMANT state.
+ */
+ENTRY(omap4_finish_suspend)
+ stmfd sp!, {lr}
+ cmp r0, #0x0
+ beq do_WFI @ No lowpower state, jump to WFI
+
+ /*
+ * Flush all data from the L1 data cache before disabling
+ * SCTLR.C bit.
+ */
+ bl omap4_get_sar_ram_base
+ ldr r9, [r0, #OMAP_TYPE_OFFSET]
+ cmp r9, #0x1 @ Check for HS device
+ bne skip_secure_l1_clean
+ mov r0, #SCU_PM_NORMAL
+ mov r1, #0xFF @ clean seucre L1
+ stmfd r13!, {r4-r12, r14}
+ ldr r12, =OMAP4_MON_SCU_PWR_INDEX
+ DO_SMC
+ ldmfd r13!, {r4-r12, r14}
+skip_secure_l1_clean:
+
+ /*
+ * Clear the SCTLR.C bit to prevent further data cache
+ * allocation. Clearing SCTLR.C would make all the data accesses
+ * strongly ordered and would not hit the cache.
+ */
+ mrc p15, 0, r0, c1, c0, 0
+ bic r0, r0, #(1 << 2) @ Disable the C bit
+ mcr p15, 0, r0, c1, c0, 0
+ isb
+
+ /*
+ * Invalidate L1 data cache. Even though only invalidate is
+ * necessary exported flush API is used here. Doing clean
+ * on already clean cache would be almost NOP.
+ */
+ bl v7_flush_dcache_all
+
+ /*
+ * Switch the CPU from Symmetric Multiprocessing (SMP) mode
+ * to AsymmetricMultiprocessing (AMP) mode by programming
+ * the SCU power status to DORMANT or OFF mode.
+ * This enables the CPU to be taken out of coherency by
+ * preventing the CPU from receiving cache, TLB, or BTB
+ * maintenance operations broadcast by other CPUs in the cluster.
+ */
+ bl omap4_get_sar_ram_base
+ mov r8, r0
+ ldr r9, [r8, #OMAP_TYPE_OFFSET]
+ cmp r9, #0x1 @ Check for HS device
+ bne scu_gp_set
+ mrc p15, 0, r0, c0, c0, 5 @ Read MPIDR
+ ands r0, r0, #0x0f
+ ldreq r0, [r8, #SCU_OFFSET0]
+ ldrne r0, [r8, #SCU_OFFSET1]
+ mov r1, #0x00
+ stmfd r13!, {r4-r12, r14}
+ ldr r12, =OMAP4_MON_SCU_PWR_INDEX
+ DO_SMC
+ ldmfd r13!, {r4-r12, r14}
+ b skip_scu_gp_set
+scu_gp_set:
+ mrc p15, 0, r0, c0, c0, 5 @ Read MPIDR
+ ands r0, r0, #0x0f
+ ldreq r1, [r8, #SCU_OFFSET0]
+ ldrne r1, [r8, #SCU_OFFSET1]
+ bl omap4_get_scu_base
+ bl scu_power_mode
+skip_scu_gp_set:
+ mrc p15, 0, r0, c1, c1, 2 @ Read NSACR data
+ tst r0, #(1 << 18)
+ mrcne p15, 0, r0, c1, c0, 1
+ bicne r0, r0, #(1 << 6) @ Disable SMP bit
+ mcrne p15, 0, r0, c1, c0, 1
+ isb
+ dsb
+
+do_WFI:
+ bl omap_do_wfi
+
+ /*
+ * CPU is here when it failed to enter OFF/DORMANT or
+ * no low power state was attempted.
+ */
+ mrc p15, 0, r0, c1, c0, 0
+ tst r0, #(1 << 2) @ Check C bit enabled?
+ orreq r0, r0, #(1 << 2) @ Enable the C bit
+ mcreq p15, 0, r0, c1, c0, 0
+ isb
+
+ /*
+ * Ensure the CPU power state is set to NORMAL in
+ * SCU power state so that CPU is back in coherency.
+ * In non-coherent mode CPU can lock-up and lead to
+ * system deadlock.
+ */
+ mrc p15, 0, r0, c1, c0, 1
+ tst r0, #(1 << 6) @ Check SMP bit enabled?
+ orreq r0, r0, #(1 << 6)
+ mcreq p15, 0, r0, c1, c0, 1
+ isb
+ bl omap4_get_sar_ram_base
+ mov r8, r0
+ ldr r9, [r8, #OMAP_TYPE_OFFSET]
+ cmp r9, #0x1 @ Check for HS device
+ bne scu_gp_clear
+ mov r0, #SCU_PM_NORMAL
+ mov r1, #0x00
+ stmfd r13!, {r4-r12, r14}
+ ldr r12, =OMAP4_MON_SCU_PWR_INDEX
+ DO_SMC
+ ldmfd r13!, {r4-r12, r14}
+ b skip_scu_gp_clear
+scu_gp_clear:
+ bl omap4_get_scu_base
+ mov r1, #SCU_PM_NORMAL
+ bl scu_power_mode
+skip_scu_gp_clear:
+ isb
+ dsb
+ ldmfd sp!, {pc}
+ENDPROC(omap4_finish_suspend)
+
+/*
+ * ============================
+ * == CPU resume entry point ==
+ * ============================
+ *
+ * void omap4_cpu_resume(void)
+ *
+ * ROM code jumps to this function while waking up from CPU
+ * OFF or DORMANT state. Physical address of the function is
+ * stored in the SAR RAM while entering to OFF or DORMANT mode.
+ */
+ENTRY(omap4_cpu_resume)
+ /*
+ * Configure ACTRL and enable NS SMP bit access on CPU1 on HS device.
+ * OMAP44XX EMU/HS devices - CPU0 SMP bit access is enabled in PPA
+ * init and for CPU1, a secure PPA API provided. CPU0 must be ON
+ * while executing NS_SMP API on CPU1 and PPA version must be 1.4.0+.
+ * OMAP443X GP devices- SMP bit isn't accessible.
+ * OMAP446X GP devices - SMP bit access is enabled on both CPUs.
+ */
+ ldr r8, =OMAP44XX_SAR_RAM_BASE
+ ldr r9, [r8, #OMAP_TYPE_OFFSET]
+ cmp r9, #0x1 @ Skip if GP device
+ bne skip_ns_smp_enable
+ mrc p15, 0, r0, c0, c0, 5
+ ands r0, r0, #0x0f
+ beq skip_ns_smp_enable
+ppa_actrl_retry:
+ mov r0, #OMAP4_PPA_CPU_ACTRL_SMP_INDEX
+ adr r3, ppa_zero_params @ Pointer to parameters
+ mov r1, #0x0 @ Process ID
+ mov r2, #0x4 @ Flag
+ mov r6, #0xff
+ mov r12, #0x00 @ Secure Service ID
+ DO_SMC
+ cmp r0, #0x0 @ API returns 0 on success.
+ beq enable_smp_bit
+ b ppa_actrl_retry
+enable_smp_bit:
+ mrc p15, 0, r0, c1, c0, 1
+ tst r0, #(1 << 6) @ Check SMP bit enabled?
+ orreq r0, r0, #(1 << 6)
+ mcreq p15, 0, r0, c1, c0, 1
+ isb
+skip_ns_smp_enable:
+
+ b cpu_resume @ Jump to generic resume
+ENDPROC(omap4_cpu_resume)
+#endif
ENTRY(omap_bus_sync)
stmfd sp!, {lr}
--
1.7.4.1
^ permalink raw reply related [flat|nested] 119+ messages in thread* [PATCH 14/25] OMAP4: PM: Add CPUX OFF mode support
2011-09-04 13:54 ` [PATCH 14/25] OMAP4: PM: Add CPUX OFF mode support Santosh Shilimkar
@ 2011-09-08 19:39 ` Jean Pihet
2011-09-09 9:59 ` Santosh
2011-09-09 8:04 ` Shawn Guo
2011-09-12 21:06 ` Kevin Hilman
2 siblings, 1 reply; 119+ messages in thread
From: Jean Pihet @ 2011-09-08 19:39 UTC (permalink / raw)
To: linux-arm-kernel
On Sun, Sep 4, 2011 at 3:54 PM, Santosh Shilimkar
<santosh.shilimkar@ti.com> wrote:
> 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.shilimkar@ti.com>
> Cc: Kevin Hilman <khilman@ti.com>
> ---
> ?arch/arm/mach-omap2/Makefile ? ? ? ? ? ? ? ? ? ?| ? ?3 +-
> ?arch/arm/mach-omap2/include/mach/omap-secure.h ?| ? ?8 +
> ?arch/arm/mach-omap2/include/mach/omap4-common.h | ? 25 +++
> ?arch/arm/mach-omap2/omap-mpuss-lowpower.c ? ? ? | ?249 +++++++++++++++++++++++
> ?arch/arm/mach-omap2/omap-smp.c ? ? ? ? ? ? ? ? ?| ? ?6 +
> ?arch/arm/mach-omap2/omap4-sar-layout.h ? ? ? ? ?| ? ?9 +
> ?arch/arm/mach-omap2/pm44xx.c ? ? ? ? ? ? ? ? ? ?| ? ?6 +
> ?arch/arm/mach-omap2/sleep44xx.S ? ? ? ? ? ? ? ? | ?213 +++++++++++++++++++
> ?8 files changed, 518 insertions(+), 1 deletions(-)
> ?create mode 100644 arch/arm/mach-omap2/omap-mpuss-lowpower.c
>
> diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
> index b032c21..b4f2eeb 100644
> --- a/arch/arm/mach-omap2/Makefile
> +++ b/arch/arm/mach-omap2/Makefile
> @@ -63,7 +63,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 sleep44xx.o
> +obj-$(CONFIG_ARCH_OMAP4) ? ? ? ? ? ? ? += pm44xx.o sleep44xx.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_INDEX ? ? ? ? ? ? ? ?0x1c
> ?#define OMAP4_HAL_SAVEGIC_INDEX ? ? ? ? ? ? ? ?0x1d
>
> +/* Secure Monitor mode APIs */
> +#define OMAP4_MON_SCU_PWR_INDEX ? ? ? ? ? ? ? ?0x108
> +
> +/* 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 040dcf6..662f37c 100644
> --- a/arch/arm/mach-omap2/include/mach/omap4-common.h
> +++ b/arch/arm/mach-omap2/include/mach/omap4-common.h
> @@ -45,5 +45,30 @@ 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)
> +{
> + ? ? ? omap_do_wfi();
> + ? ? ? return 0;
> +}
> +
> +static inline int omap4_mpuss_init(void)
> +{
> + ? ? ? return 0;
> +}
> +
> +static inline int omap4_finish_suspend(unsigned long cpu_state)
> +{}
The int function should return something (0?)
Has the code been test compiled without SMP and/or PM?
> +static inline void omap4_cpu_resume(void)
> +{}
> +#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
...
> +/**
> + * omap4_enter_lowpower: OMAP4 MPUSS Low Power Entry Function
> + * The purpose of this function is to manage low power programming
> + * of OMAP4 MPUSS subsystem
> + * @cpu : CPU ID
> + * @power_state: Low power state.
> + */
> +int omap4_enter_lowpower(unsigned int cpu, unsigned int power_state)
> +{
> + ? ? ? unsigned int save_state = 0;
> + ? ? ? unsigned int wakeup_cpu;
> +
> + ? ? ? if (omap_rev() == OMAP4430_REV_ES1_0)
> + ? ? ? ? ? ? ? return -ENXIO;
> +
> + ? ? ? switch (power_state) {
> + ? ? ? case PWRDM_POWER_ON:
> + ? ? ? case PWRDM_POWER_INACTIVE:
> + ? ? ? ? ? ? ? save_state = 0;
> + ? ? ? ? ? ? ? break;
> + ? ? ? case PWRDM_POWER_OFF:
> + ? ? ? ? ? ? ? save_state = 1;
> + ? ? ? ? ? ? ? break;
> + ? ? ? case PWRDM_POWER_RET:
> + ? ? ? default:
> + ? ? ? ? ? ? ? /*
> + ? ? ? ? ? ? ? ?* CPUx CSWR is invalid hardware state. Also CPUx OSWR
> + ? ? ? ? ? ? ? ?* doesn't make much scense, since logic is lost and $L1
> + ? ? ? ? ? ? ? ?* needs to be cleaned because of coherency. This makes
> + ? ? ? ? ? ? ? ?* CPUx OSWR equivalent to CPUX OFF and hence not supported
> + ? ? ? ? ? ? ? ?*/
> + ? ? ? ? ? ? ? WARN_ON(1);
> + ? ? ? ? ? ? ? return -ENXIO;
> + ? ? ? }
> +
> + ? ? ? clear_cpu_prev_pwrst(cpu);
> + ? ? ? set_cpu_next_pwrst(cpu, power_state);
> + ? ? ? set_cpu_wakeup_addr(cpu, virt_to_phys(omap4_cpu_resume));
> + ? ? ? scu_pwrst_prepare(cpu, power_state);
> +
> + ? ? ? /*
> + ? ? ? ?* Call low level function ?with targeted CPU id
> + ? ? ? ?* and its low power state.
> + ? ? ? ?*/
> + ? ? ? cpu_suspend(save_state, omap4_finish_suspend);
There is no CPU id parameter to the call although the above comment says so.
...
> diff --git a/arch/arm/mach-omap2/sleep44xx.S b/arch/arm/mach-omap2/sleep44xx.S
...
> +/*
> + * =============================
> + * == CPU suspend finisher ==
> + * =============================
> + *
> + * void omap4_finish_suspend(unsigned long cpu_state)
> + *
> + * This function code saves the CPU context and performs the CPU
> + * power down sequence. Calling WFI effectively changes the CPU
> + * power domains states to the desired target power state.
> + *
> + * @cpu_state : contains context save state (r0)
> + * ? ? 0 - No context lost
> + * ? ? 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: MPUSS OFF
> + * @return: This function never returns for CPU OFF and DORMANT power states.
> + * Post WFI, CPU transitions to DORMANT or OFF power state and on wake-up
> + * from this follows a full CPU reset path via ROM code to CPU restore code.
Is the ROM code jumping to the physical address of omap4_cpu_resume?
If so please add it in the comment.
...
> +/*
> + * ============================
> + * == CPU resume entry point ==
> + * ============================
> + *
> + * void omap4_cpu_resume(void)
> + *
> + * ROM code jumps to this function while waking up from CPU
> + * OFF or DORMANT state. Physical address of the function is
> + * stored in the SAR RAM while entering to OFF or DORMANT mode.
Which code stores the address in the SAR RAM? Please describe it here.
> + */
> +ENTRY(omap4_cpu_resume)
> + ? ? ? /*
...
Regards,
Jean
^ permalink raw reply [flat|nested] 119+ messages in thread* [PATCH 14/25] OMAP4: PM: Add CPUX OFF mode support
2011-09-08 19:39 ` Jean Pihet
@ 2011-09-09 9:59 ` Santosh
0 siblings, 0 replies; 119+ messages in thread
From: Santosh @ 2011-09-09 9:59 UTC (permalink / raw)
To: linux-arm-kernel
On Friday 09 September 2011 01:09 AM, Jean Pihet wrote:
> On Sun, Sep 4, 2011 at 3:54 PM, Santosh Shilimkar
> <santosh.shilimkar@ti.com> wrote:
>> 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.shilimkar@ti.com>
>> Cc: Kevin Hilman<khilman@ti.com>
>> ---
>> arch/arm/mach-omap2/Makefile | 3 +-
>> arch/arm/mach-omap2/include/mach/omap-secure.h | 8 +
>> arch/arm/mach-omap2/include/mach/omap4-common.h | 25 +++
>> arch/arm/mach-omap2/omap-mpuss-lowpower.c | 249 +++++++++++++++++++++++
>> arch/arm/mach-omap2/omap-smp.c | 6 +
>> arch/arm/mach-omap2/omap4-sar-layout.h | 9 +
>> arch/arm/mach-omap2/pm44xx.c | 6 +
>> arch/arm/mach-omap2/sleep44xx.S | 213 +++++++++++++++++++
>> 8 files changed, 518 insertions(+), 1 deletions(-)
>> create mode 100644 arch/arm/mach-omap2/omap-mpuss-lowpower.c
>>
>> diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
>> index b032c21..b4f2eeb 100644
>> --- a/arch/arm/mach-omap2/Makefile
>> +++ b/arch/arm/mach-omap2/Makefile
>> @@ -63,7 +63,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 sleep44xx.o
>> +obj-$(CONFIG_ARCH_OMAP4) += pm44xx.o sleep44xx.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_INDEX 0x1c
>> #define OMAP4_HAL_SAVEGIC_INDEX 0x1d
>>
>> +/* Secure Monitor mode APIs */
>> +#define OMAP4_MON_SCU_PWR_INDEX 0x108
>> +
>> +/* 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 040dcf6..662f37c 100644
>> --- a/arch/arm/mach-omap2/include/mach/omap4-common.h
>> +++ b/arch/arm/mach-omap2/include/mach/omap4-common.h
>> @@ -45,5 +45,30 @@ 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)
>> +{
>> + omap_do_wfi();
>> + return 0;
>> +}
>> +
>> +static inline int omap4_mpuss_init(void)
>> +{
>> + return 0;
>> +}
>> +
>> +static inline int omap4_finish_suspend(unsigned long cpu_state)
>> +{}
> The int function should return something (0?)
> Has the code been test compiled without SMP and/or PM?
>
>> +static inline void omap4_cpu_resume(void)
>> +{}
>> +#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
> ...
>
>> +/**
>> + * omap4_enter_lowpower: OMAP4 MPUSS Low Power Entry Function
>> + * The purpose of this function is to manage low power programming
>> + * of OMAP4 MPUSS subsystem
>> + * @cpu : CPU ID
>> + * @power_state: Low power state.
>> + */
>> +int omap4_enter_lowpower(unsigned int cpu, unsigned int power_state)
>> +{
>> + unsigned int save_state = 0;
>> + unsigned int wakeup_cpu;
>> +
>> + if (omap_rev() == OMAP4430_REV_ES1_0)
>> + return -ENXIO;
>> +
>> + switch (power_state) {
>> + case PWRDM_POWER_ON:
>> + case PWRDM_POWER_INACTIVE:
>> + save_state = 0;
>> + break;
>> + case PWRDM_POWER_OFF:
>> + save_state = 1;
>> + break;
>> + case PWRDM_POWER_RET:
>> + default:
>> + /*
>> + * CPUx CSWR is invalid hardware state. Also CPUx OSWR
>> + * doesn't make much scense, since logic is lost and $L1
>> + * needs to be cleaned because of coherency. This makes
>> + * CPUx OSWR equivalent to CPUX OFF and hence not supported
>> + */
>> + WARN_ON(1);
>> + return -ENXIO;
>> + }
>> +
>> + clear_cpu_prev_pwrst(cpu);
>> + set_cpu_next_pwrst(cpu, power_state);
>> + set_cpu_wakeup_addr(cpu, virt_to_phys(omap4_cpu_resume));
>> + scu_pwrst_prepare(cpu, power_state);
>> +
>> + /*
>> + * Call low level function with targeted CPU id
>> + * and its low power state.
>> + */
>> + cpu_suspend(save_state, omap4_finish_suspend);
> There is no CPU id parameter to the call although the above comment says so.
>
> ...
>
>> diff --git a/arch/arm/mach-omap2/sleep44xx.S b/arch/arm/mach-omap2/sleep44xx.S
> ...
>
>> +/*
>> + * =============================
>> + * == CPU suspend finisher ==
>> + * =============================
>> + *
>> + * void omap4_finish_suspend(unsigned long cpu_state)
>> + *
>> + * This function code saves the CPU context and performs the CPU
>> + * power down sequence. Calling WFI effectively changes the CPU
>> + * power domains states to the desired target power state.
>> + *
>> + * @cpu_state : contains context save state (r0)
>> + * 0 - No context lost
>> + * 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: MPUSS OFF
>> + * @return: This function never returns for CPU OFF and DORMANT power states.
>> + * Post WFI, CPU transitions to DORMANT or OFF power state and on wake-up
>> + * from this follows a full CPU reset path via ROM code to CPU restore code.
> Is the ROM code jumping to the physical address of omap4_cpu_resume?
> If so please add it in the comment.
>
> ...
>
>> +/*
>> + * ============================
>> + * == CPU resume entry point ==
>> + * ============================
>> + *
>> + * void omap4_cpu_resume(void)
>> + *
>> + * ROM code jumps to this function while waking up from CPU
>> + * OFF or DORMANT state. Physical address of the function is
>> + * stored in the SAR RAM while entering to OFF or DORMANT mode.
> Which code stores the address in the SAR RAM? Please describe it here.
>
Will add that comment.
Regards
Santosh
^ permalink raw reply [flat|nested] 119+ messages in thread
* [PATCH 14/25] OMAP4: PM: Add CPUX OFF mode support
2011-09-04 13:54 ` [PATCH 14/25] OMAP4: PM: Add CPUX OFF mode support Santosh Shilimkar
2011-09-08 19:39 ` Jean Pihet
@ 2011-09-09 8:04 ` Shawn Guo
2011-09-09 8:09 ` Santosh
2011-09-12 21:06 ` Kevin Hilman
2 siblings, 1 reply; 119+ messages in thread
From: Shawn Guo @ 2011-09-09 8:04 UTC (permalink / raw)
To: linux-arm-kernel
Hi Santosh,
On Sun, Sep 04, 2011 at 07:24:15PM +0530, Santosh Shilimkar wrote:
> 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.shilimkar@ti.com>
> Cc: Kevin Hilman <khilman@ti.com>
> ---
> arch/arm/mach-omap2/Makefile | 3 +-
> arch/arm/mach-omap2/include/mach/omap-secure.h | 8 +
> arch/arm/mach-omap2/include/mach/omap4-common.h | 25 +++
> arch/arm/mach-omap2/omap-mpuss-lowpower.c | 249 +++++++++++++++++++++++
> arch/arm/mach-omap2/omap-smp.c | 6 +
> arch/arm/mach-omap2/omap4-sar-layout.h | 9 +
> arch/arm/mach-omap2/pm44xx.c | 6 +
> arch/arm/mach-omap2/sleep44xx.S | 213 +++++++++++++++++++
> 8 files changed, 518 insertions(+), 1 deletions(-)
> create mode 100644 arch/arm/mach-omap2/omap-mpuss-lowpower.c
>
[...]
> diff --git a/arch/arm/mach-omap2/sleep44xx.S b/arch/arm/mach-omap2/sleep44xx.S
> index 049f426..230ab8c 100644
> --- a/arch/arm/mach-omap2/sleep44xx.S
> +++ b/arch/arm/mach-omap2/sleep44xx.S
> @@ -11,8 +11,221 @@
>
> #include <linux/linkage.h>
> #include <asm/system.h>
> +#include <asm/smp_scu.h>
> +#include <asm/memory.h>
> +#include <asm/hardware/cache-l2x0.h>
>
> +#include <plat/omap44xx.h>
> #include <mach/omap4-common.h>
> +#include <mach/omap-secure.h>
> +
> +#include "omap4-sar-layout.h"
> +
> +#ifdef CONFIG_SMP
> +
> +.macro DO_SMC
> + dsb
> + smc #0
> + dsb
> +.endm
> +
> +ppa_zero_params:
> + .word 0x0
> +
> +/*
> + * =============================
> + * == CPU suspend finisher ==
> + * =============================
> + *
> + * void omap4_finish_suspend(unsigned long cpu_state)
> + *
> + * This function code saves the CPU context and performs the CPU
> + * power down sequence. Calling WFI effectively changes the CPU
> + * power domains states to the desired target power state.
> + *
> + * @cpu_state : contains context save state (r0)
> + * 0 - No context lost
> + * 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: MPUSS OFF
I was told by rmk that same as imx6q, omap44xx will retain L2 content
across suspen/resume cycle. Then what does "L2 lost" mean here? Or
what rmk meant is the case cpu_state == 2?
--
Regards,
Shawn
^ permalink raw reply [flat|nested] 119+ messages in thread
* [PATCH 14/25] OMAP4: PM: Add CPUX OFF mode support
2011-09-09 8:04 ` Shawn Guo
@ 2011-09-09 8:09 ` Santosh
2011-09-09 14:13 ` Shawn Guo
0 siblings, 1 reply; 119+ messages in thread
From: Santosh @ 2011-09-09 8:09 UTC (permalink / raw)
To: linux-arm-kernel
On Friday 09 September 2011 01:34 PM, Shawn Guo wrote:
> Hi Santosh,
>
> On Sun, Sep 04, 2011 at 07:24:15PM +0530, Santosh Shilimkar wrote:
>> 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.shilimkar@ti.com>
>> Cc: Kevin Hilman<khilman@ti.com>
>> ---
>> arch/arm/mach-omap2/Makefile | 3 +-
>> arch/arm/mach-omap2/include/mach/omap-secure.h | 8 +
>> arch/arm/mach-omap2/include/mach/omap4-common.h | 25 +++
>> arch/arm/mach-omap2/omap-mpuss-lowpower.c | 249 +++++++++++++++++++++++
>> arch/arm/mach-omap2/omap-smp.c | 6 +
>> arch/arm/mach-omap2/omap4-sar-layout.h | 9 +
>> arch/arm/mach-omap2/pm44xx.c | 6 +
>> arch/arm/mach-omap2/sleep44xx.S | 213 +++++++++++++++++++
>> 8 files changed, 518 insertions(+), 1 deletions(-)
>> create mode 100644 arch/arm/mach-omap2/omap-mpuss-lowpower.c
>>
>
> [...]
>
>> diff --git a/arch/arm/mach-omap2/sleep44xx.S b/arch/arm/mach-omap2/sleep44xx.S
>> index 049f426..230ab8c 100644
>> --- a/arch/arm/mach-omap2/sleep44xx.S
>> +++ b/arch/arm/mach-omap2/sleep44xx.S
>> @@ -11,8 +11,221 @@
>>
>> #include<linux/linkage.h>
>> #include<asm/system.h>
>> +#include<asm/smp_scu.h>
>> +#include<asm/memory.h>
>> +#include<asm/hardware/cache-l2x0.h>
>>
>> +#include<plat/omap44xx.h>
>> #include<mach/omap4-common.h>
>> +#include<mach/omap-secure.h>
>> +
>> +#include "omap4-sar-layout.h"
>> +
>> +#ifdef CONFIG_SMP
>> +
>> +.macro DO_SMC
>> + dsb
>> + smc #0
>> + dsb
>> +.endm
>> +
>> +ppa_zero_params:
>> + .word 0x0
>> +
>> +/*
>> + * =============================
>> + * == CPU suspend finisher ==
>> + * =============================
>> + *
>> + * void omap4_finish_suspend(unsigned long cpu_state)
>> + *
>> + * This function code saves the CPU context and performs the CPU
>> + * power down sequence. Calling WFI effectively changes the CPU
>> + * power domains states to the desired target power state.
>> + *
>> + * @cpu_state : contains context save state (r0)
>> + * 0 - No context lost
>> + * 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: MPUSS OFF
>
> I was told by rmk that same as imx6q, omap44xx will retain L2 content
> across suspen/resume cycle. Then what does "L2 lost" mean here? Or
> what rmk meant is the case cpu_state == 2?
>
Yes.
The last case is entire SOC OFF. We call Device OFF in OMAP.
All voltages will scale to 0 V. This isn't supported by this
series.
Regards
Santosh
^ permalink raw reply [flat|nested] 119+ messages in thread
* [PATCH 14/25] OMAP4: PM: Add CPUX OFF mode support
2011-09-09 8:09 ` Santosh
@ 2011-09-09 14:13 ` Shawn Guo
2011-09-09 14:11 ` Shilimkar, Santosh
0 siblings, 1 reply; 119+ messages in thread
From: Shawn Guo @ 2011-09-09 14:13 UTC (permalink / raw)
To: linux-arm-kernel
On Fri, Sep 09, 2011 at 01:39:51PM +0530, Santosh wrote:
> On Friday 09 September 2011 01:34 PM, Shawn Guo wrote:
> >Hi Santosh,
> >
> >On Sun, Sep 04, 2011 at 07:24:15PM +0530, Santosh Shilimkar wrote:
> >>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.shilimkar@ti.com>
> >>Cc: Kevin Hilman<khilman@ti.com>
> >>---
> >> arch/arm/mach-omap2/Makefile | 3 +-
> >> arch/arm/mach-omap2/include/mach/omap-secure.h | 8 +
> >> arch/arm/mach-omap2/include/mach/omap4-common.h | 25 +++
> >> arch/arm/mach-omap2/omap-mpuss-lowpower.c | 249 +++++++++++++++++++++++
> >> arch/arm/mach-omap2/omap-smp.c | 6 +
> >> arch/arm/mach-omap2/omap4-sar-layout.h | 9 +
> >> arch/arm/mach-omap2/pm44xx.c | 6 +
> >> arch/arm/mach-omap2/sleep44xx.S | 213 +++++++++++++++++++
> >> 8 files changed, 518 insertions(+), 1 deletions(-)
> >> create mode 100644 arch/arm/mach-omap2/omap-mpuss-lowpower.c
> >>
> >
> >[...]
> >
> >>diff --git a/arch/arm/mach-omap2/sleep44xx.S b/arch/arm/mach-omap2/sleep44xx.S
> >>index 049f426..230ab8c 100644
> >>--- a/arch/arm/mach-omap2/sleep44xx.S
> >>+++ b/arch/arm/mach-omap2/sleep44xx.S
> >>@@ -11,8 +11,221 @@
> >>
> >> #include<linux/linkage.h>
> >> #include<asm/system.h>
> >>+#include<asm/smp_scu.h>
> >>+#include<asm/memory.h>
> >>+#include<asm/hardware/cache-l2x0.h>
> >>
> >>+#include<plat/omap44xx.h>
> >> #include<mach/omap4-common.h>
> >>+#include<mach/omap-secure.h>
> >>+
> >>+#include "omap4-sar-layout.h"
> >>+
> >>+#ifdef CONFIG_SMP
> >>+
> >>+.macro DO_SMC
> >>+ dsb
> >>+ smc #0
> >>+ dsb
> >>+.endm
> >>+
> >>+ppa_zero_params:
> >>+ .word 0x0
> >>+
> >>+/*
> >>+ * =============================
> >>+ * == CPU suspend finisher ==
> >>+ * =============================
> >>+ *
> >>+ * void omap4_finish_suspend(unsigned long cpu_state)
> >>+ *
> >>+ * This function code saves the CPU context and performs the CPU
> >>+ * power down sequence. Calling WFI effectively changes the CPU
> >>+ * power domains states to the desired target power state.
> >>+ *
> >>+ * @cpu_state : contains context save state (r0)
> >>+ * 0 - No context lost
> >>+ * 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: MPUSS OFF
> >
> >I was told by rmk that same as imx6q, omap44xx will retain L2 content
> >across suspen/resume cycle. Then what does "L2 lost" mean here? Or
> >what rmk meant is the case cpu_state == 2?
> >
> Yes.
>
> The last case is entire SOC OFF. We call Device OFF in OMAP.
> All voltages will scale to 0 V. This isn't supported by this
> series.
>
Then the second question would be what the following patch in this
series is for.
[PATCH 20/25] OMAP4: PM: Add L2X0 cache lowpower support
I could have read the patch incorrectly, but it seems l2x_clean_inv
will also be called for "MPUSS OSWR" in which case L2 is retained?
Shouldn't L2 for this case have been handled by rmk's patch (ARM: pm:
add L2 cache cleaning for suspend)?
--
Regards,
Shawn
^ permalink raw reply [flat|nested] 119+ messages in thread* [PATCH 14/25] OMAP4: PM: Add CPUX OFF mode support
2011-09-09 14:13 ` Shawn Guo
@ 2011-09-09 14:11 ` Shilimkar, Santosh
2011-09-09 15:27 ` Shawn Guo
0 siblings, 1 reply; 119+ messages in thread
From: Shilimkar, Santosh @ 2011-09-09 14:11 UTC (permalink / raw)
To: linux-arm-kernel
On Fri, Sep 9, 2011 at 7:43 PM, Shawn Guo <shawn.guo@freescale.com> wrote:
> On Fri, Sep 09, 2011 at 01:39:51PM +0530, Santosh wrote:
>> On Friday 09 September 2011 01:34 PM, Shawn Guo wrote:
>> >Hi Santosh,
>> >
>> >On Sun, Sep 04, 2011 at 07:24:15PM +0530, Santosh Shilimkar wrote:
>> >>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.shilimkar@ti.com>
>> >>Cc: Kevin Hilman<khilman@ti.com>
>> >>---
>> >> ?arch/arm/mach-omap2/Makefile ? ? ? ? ? ? ? ? ? ?| ? ?3 +-
>> >> ?arch/arm/mach-omap2/include/mach/omap-secure.h ?| ? ?8 +
>> >> ?arch/arm/mach-omap2/include/mach/omap4-common.h | ? 25 +++
>> >> ?arch/arm/mach-omap2/omap-mpuss-lowpower.c ? ? ? | ?249 +++++++++++++++++++++++
>> >> ?arch/arm/mach-omap2/omap-smp.c ? ? ? ? ? ? ? ? ?| ? ?6 +
>> >> ?arch/arm/mach-omap2/omap4-sar-layout.h ? ? ? ? ?| ? ?9 +
>> >> ?arch/arm/mach-omap2/pm44xx.c ? ? ? ? ? ? ? ? ? ?| ? ?6 +
>> >> ?arch/arm/mach-omap2/sleep44xx.S ? ? ? ? ? ? ? ? | ?213 +++++++++++++++++++
>> >> ?8 files changed, 518 insertions(+), 1 deletions(-)
>> >> ?create mode 100644 arch/arm/mach-omap2/omap-mpuss-lowpower.c
>> >>
>> >
>> >[...]
>> >
>> >>diff --git a/arch/arm/mach-omap2/sleep44xx.S b/arch/arm/mach-omap2/sleep44xx.S
>> >>index 049f426..230ab8c 100644
>> >>--- a/arch/arm/mach-omap2/sleep44xx.S
>> >>+++ b/arch/arm/mach-omap2/sleep44xx.S
>> >>@@ -11,8 +11,221 @@
>> >>
>> >> ?#include<linux/linkage.h>
>> >> ?#include<asm/system.h>
>> >>+#include<asm/smp_scu.h>
>> >>+#include<asm/memory.h>
>> >>+#include<asm/hardware/cache-l2x0.h>
>> >>
>> >>+#include<plat/omap44xx.h>
>> >> ?#include<mach/omap4-common.h>
>> >>+#include<mach/omap-secure.h>
>> >>+
>> >>+#include "omap4-sar-layout.h"
>> >>+
>> >>+#ifdef CONFIG_SMP
>> >>+
>> >>+.macro ? ? DO_SMC
>> >>+ ? dsb
>> >>+ ? smc ? ? #0
>> >>+ ? dsb
>> >>+.endm
>> >>+
>> >>+ppa_zero_params:
>> >>+ ? .word ? ? ? ? ? 0x0
>> >>+
>> >>+/*
>> >>+ * =============================
>> >>+ * == CPU suspend finisher ==
>> >>+ * =============================
>> >>+ *
>> >>+ * void omap4_finish_suspend(unsigned long cpu_state)
>> >>+ *
>> >>+ * This function code saves the CPU context and performs the CPU
>> >>+ * power down sequence. Calling WFI effectively changes the CPU
>> >>+ * power domains states to the desired target power state.
>> >>+ *
>> >>+ * @cpu_state : contains context save state (r0)
>> >>+ * 0 - No context lost
>> >>+ * ? ? ? ? 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: MPUSS OFF
>> >
>> >I was told by rmk that same as imx6q, omap44xx will retain L2 content
>> >across suspen/resume cycle. ?Then what does "L2 lost" mean here? ?Or
>> >what rmk meant is the case cpu_state == 2?
>> >
>> Yes.
>>
>> The last case is entire SOC OFF. We call Device OFF in OMAP.
>> All voltages will scale to 0 V. This isn't supported by this
>> series.
>>
> Then the second question would be what the following patch in this
> series is for.
>
> ? ?[PATCH 20/25] OMAP4: PM: Add L2X0 cache lowpower support
>
> I could have read the patch incorrectly, but it seems l2x_clean_inv
> will also be called for "MPUSS OSWR" in which case L2 is retained?
> Shouldn't L2 for this case have been handled by rmk's patch (ARM: pm:
> add L2 cache cleaning for suspend)?
>
Yes you did read it wrongly :)
It won't be called for OSWR
^ permalink raw reply [flat|nested] 119+ messages in thread
* [PATCH 14/25] OMAP4: PM: Add CPUX OFF mode support
2011-09-09 14:11 ` Shilimkar, Santosh
@ 2011-09-09 15:27 ` Shawn Guo
2011-09-09 16:59 ` Santosh
0 siblings, 1 reply; 119+ messages in thread
From: Shawn Guo @ 2011-09-09 15:27 UTC (permalink / raw)
To: linux-arm-kernel
On Fri, Sep 09, 2011 at 07:41:08PM +0530, Shilimkar, Santosh wrote:
> On Fri, Sep 9, 2011 at 7:43 PM, Shawn Guo <shawn.guo@freescale.com> wrote:
> > On Fri, Sep 09, 2011 at 01:39:51PM +0530, Santosh wrote:
> >> On Friday 09 September 2011 01:34 PM, Shawn Guo wrote:
> >> >Hi Santosh,
> >> >
> >> >On Sun, Sep 04, 2011 at 07:24:15PM +0530, Santosh Shilimkar wrote:
> >> >>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.shilimkar@ti.com>
> >> >>Cc: Kevin Hilman<khilman@ti.com>
> >> >>---
> >> >> ?arch/arm/mach-omap2/Makefile ? ? ? ? ? ? ? ? ? ?| ? ?3 +-
> >> >> ?arch/arm/mach-omap2/include/mach/omap-secure.h ?| ? ?8 +
> >> >> ?arch/arm/mach-omap2/include/mach/omap4-common.h | ? 25 +++
> >> >> ?arch/arm/mach-omap2/omap-mpuss-lowpower.c ? ? ? | ?249 +++++++++++++++++++++++
> >> >> ?arch/arm/mach-omap2/omap-smp.c ? ? ? ? ? ? ? ? ?| ? ?6 +
> >> >> ?arch/arm/mach-omap2/omap4-sar-layout.h ? ? ? ? ?| ? ?9 +
> >> >> ?arch/arm/mach-omap2/pm44xx.c ? ? ? ? ? ? ? ? ? ?| ? ?6 +
> >> >> ?arch/arm/mach-omap2/sleep44xx.S ? ? ? ? ? ? ? ? | ?213 +++++++++++++++++++
> >> >> ?8 files changed, 518 insertions(+), 1 deletions(-)
> >> >> ?create mode 100644 arch/arm/mach-omap2/omap-mpuss-lowpower.c
> >> >>
> >> >
> >> >[...]
> >> >
> >> >>diff --git a/arch/arm/mach-omap2/sleep44xx.S b/arch/arm/mach-omap2/sleep44xx.S
> >> >>index 049f426..230ab8c 100644
> >> >>--- a/arch/arm/mach-omap2/sleep44xx.S
> >> >>+++ b/arch/arm/mach-omap2/sleep44xx.S
> >> >>@@ -11,8 +11,221 @@
> >> >>
> >> >> ?#include<linux/linkage.h>
> >> >> ?#include<asm/system.h>
> >> >>+#include<asm/smp_scu.h>
> >> >>+#include<asm/memory.h>
> >> >>+#include<asm/hardware/cache-l2x0.h>
> >> >>
> >> >>+#include<plat/omap44xx.h>
> >> >> ?#include<mach/omap4-common.h>
> >> >>+#include<mach/omap-secure.h>
> >> >>+
> >> >>+#include "omap4-sar-layout.h"
> >> >>+
> >> >>+#ifdef CONFIG_SMP
> >> >>+
> >> >>+.macro ? ? DO_SMC
> >> >>+ ? dsb
> >> >>+ ? smc ? ? #0
> >> >>+ ? dsb
> >> >>+.endm
> >> >>+
> >> >>+ppa_zero_params:
> >> >>+ ? .word ? ? ? ? ? 0x0
> >> >>+
> >> >>+/*
> >> >>+ * =============================
> >> >>+ * == CPU suspend finisher ==
> >> >>+ * =============================
> >> >>+ *
> >> >>+ * void omap4_finish_suspend(unsigned long cpu_state)
> >> >>+ *
> >> >>+ * This function code saves the CPU context and performs the CPU
> >> >>+ * power down sequence. Calling WFI effectively changes the CPU
> >> >>+ * power domains states to the desired target power state.
> >> >>+ *
> >> >>+ * @cpu_state : contains context save state (r0)
> >> >>+ * 0 - No context lost
> >> >>+ * ? ? ? ? 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: MPUSS OFF
> >> >
> >> >I was told by rmk that same as imx6q, omap44xx will retain L2 content
> >> >across suspen/resume cycle. ?Then what does "L2 lost" mean here? ?Or
> >> >what rmk meant is the case cpu_state == 2?
> >> >
> >> Yes.
> >>
> >> The last case is entire SOC OFF. We call Device OFF in OMAP.
> >> All voltages will scale to 0 V. This isn't supported by this
> >> series.
> >>
> > Then the second question would be what the following patch in this
> > series is for.
> >
> > ? ?[PATCH 20/25] OMAP4: PM: Add L2X0 cache lowpower support
> >
> > I could have read the patch incorrectly, but it seems l2x_clean_inv
> > will also be called for "MPUSS OSWR" in which case L2 is retained?
> > Shouldn't L2 for this case have been handled by rmk's patch (ARM: pm:
> > add L2 cache cleaning for suspend)?
> >
> Yes you did read it wrongly :)
> It won't be called for OSWR
>
Come on, man. It's really hard for me who is still at entry level of
assembly to understand that. So please help me out.
The following is a copy from arch/arm/mach-omap2/sleep44xx.S after I
apply this patch series on v3.1-rc4.
> /*
> * =============================
> * == CPU suspend finisher ==
> * =============================
> *
> * void omap4_finish_suspend(unsigned long cpu_state)
> *
> * This function code saves the CPU context and performs the CPU
> * power down sequence. Calling WFI effectively changes the CPU
> * power domains states to the desired target power state.
> *
> * @cpu_state : contains context save state (r0)
So cpu_state is passed in r0.
> * 0 - No context lost
> * 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: MPUSS OFF
> * @return: This function never returns for CPU OFF and DORMANT power states.
> * Post WFI, CPU transitions to DORMANT or OFF power state and on wake-up
> * from this follows a full CPU reset path via ROM code to CPU restore code.
> * It returns to the caller for CPU INACTIVE and ON power states or in case
> * CPU failed to transition to targeted OFF/DORMANT state.
> */
> ENTRY(omap4_finish_suspend)
> stmfd sp!, {lr}
> cmp r0, #0x0
> beq do_WFI @ No lowpower state, jump to WFI
The case "0" is handled here.
>
> /*
> * Flush all data from the L1 data cache before disabling
> * SCTLR.C bit.
> */
> bl omap4_get_sar_ram_base
Isn't r0 lost here?
> ldr r9, [r0, #OMAP_TYPE_OFFSET]
> cmp r9, #0x1 @ Check for HS device
> bne skip_secure_l1_clean
> mov r0, #SCU_PM_NORMAL
> mov r1, #0xFF @ clean seucre L1
> stmfd r13!, {r4-r12, r14}
> ldr r12, =OMAP4_MON_SCU_PWR_INDEX
> DO_SMC
> ldmfd r13!, {r4-r12, r14}
> skip_secure_l1_clean:
>
> /*
> * Clear the SCTLR.C bit to prevent further data cache
> * allocation. Clearing SCTLR.C would make all the data accesses
> * strongly ordered and would not hit the cache.
> */
> mrc p15, 0, r0, c1, c0, 0
> bic r0, r0, #(1 << 2) @ Disable the C bit
> mcr p15, 0, r0, c1, c0, 0
> isb
>
> /*
> * Invalidate L1 data cache. Even though only invalidate is
> * necessary exported flush API is used here. Doing clean
> * on already clean cache would be almost NOP.
> */
> bl v7_flush_dcache_all
>
> /*
> * Switch the CPU from Symmetric Multiprocessing (SMP) mode
> * to AsymmetricMultiprocessing (AMP) mode by programming
> * the SCU power status to DORMANT or OFF mode.
> * This enables the CPU to be taken out of coherency by
> * preventing the CPU from receiving cache, TLB, or BTB
> * maintenance operations broadcast by other CPUs in the cluster.
> */
> bl omap4_get_sar_ram_base
> mov r8, r0
> ldr r9, [r8, #OMAP_TYPE_OFFSET]
> cmp r9, #0x1 @ Check for HS device
> bne scu_gp_set
> mrc p15, 0, r0, c0, c0, 5 @ Read MPIDR
> ands r0, r0, #0x0f
> ldreq r0, [r8, #SCU_OFFSET0]
> ldrne r0, [r8, #SCU_OFFSET1]
> mov r1, #0x00
> stmfd r13!, {r4-r12, r14}
> ldr r12, =OMAP4_MON_SCU_PWR_INDEX
> DO_SMC
> ldmfd r13!, {r4-r12, r14}
> b skip_scu_gp_set
> scu_gp_set:
> mrc p15, 0, r0, c0, c0, 5 @ Read MPIDR
> ands r0, r0, #0x0f
> ldreq r1, [r8, #SCU_OFFSET0]
> ldrne r1, [r8, #SCU_OFFSET1]
> bl omap4_get_scu_base
> bl scu_power_mode
> skip_scu_gp_set:
> mrc p15, 0, r0, c1, c1, 2 @ Read NSACR data
> tst r0, #(1 << 18)
> mrcne p15, 0, r0, c1, c0, 1
> bicne r0, r0, #(1 << 6) @ Disable SMP bit
> mcrne p15, 0, r0, c1, c0, 1
> isb
> dsb
> #ifdef CONFIG_CACHE_L2X0
> /*
> * Clean and invalidate the L2 cache.
> * Common cache-l2x0.c functions can't be used here since it
> * uses spinlocks. We are out of coherency here with data cache
> * disabled. The spinlock implementation uses exclusive load/store
> * instruction which can fail without data cache being enabled.
> * OMAP4 hardware doesn't support exclusive monitor which can
> * overcome exclusive access issue. Because of this, CPU can
> * lead to deadlock.
> */
> l2x_clean_inv:
> bl omap4_get_sar_ram_base
> mov r8, r0
> mrc p15, 0, r5, c0, c0, 5 @ Read MPIDR
> ands r5, r5, #0x0f
> ldreq r0, [r8, #L2X0_SAVE_OFFSET0]
> ldrne r0, [r8, #L2X0_SAVE_OFFSET1]
> cmp r0, #3
> bne do_WFI
It looks like you are bypassing L2 clean and invalidate for cases
"1" and "2" here. But I really do not understand how you get r0
back here.
Regards,
Shawn
> #ifdef CONFIG_PL310_ERRATA_727915
> mov r0, #0x03
> mov r12, #OMAP4_MON_L2X0_DBG_CTRL_INDEX
> DO_SMC
> #endif
> bl omap4_get_l2cache_base
> mov r2, r0
> ldr r0, =0xffff
> str r0, [r2, #L2X0_CLEAN_INV_WAY]
> wait:
> ldr r0, [r2, #L2X0_CLEAN_INV_WAY]
> ldr r1, =0xffff
> ands r0, r0, r1
> bne wait
> #ifdef CONFIG_PL310_ERRATA_727915
> mov r0, #0x00
> mov r12, #OMAP4_MON_L2X0_DBG_CTRL_INDEX
> DO_SMC
> #endif
> l2x_sync:
> bl omap4_get_l2cache_base
> mov r2, r0
> mov r0, #0x0
> str r0, [r2, #L2X0_CACHE_SYNC]
> sync:
> ldr r0, [r2, #L2X0_CACHE_SYNC]
> ands r0, r0, #0x1
> bne sync
> #endif
>
> do_WFI:
> bl omap_do_wfi
>
> /*
> * CPU is here when it failed to enter OFF/DORMANT or
> * no low power state was attempted.
> */
> mrc p15, 0, r0, c1, c0, 0
> tst r0, #(1 << 2) @ Check C bit enabled?
> orreq r0, r0, #(1 << 2) @ Enable the C bit
> mcreq p15, 0, r0, c1, c0, 0
> isb
>
> /*
> * Ensure the CPU power state is set to NORMAL in
> * SCU power state so that CPU is back in coherency.
> * In non-coherent mode CPU can lock-up and lead to
> * system deadlock.
> */
> mrc p15, 0, r0, c1, c0, 1
> tst r0, #(1 << 6) @ Check SMP bit enabled?
> orreq r0, r0, #(1 << 6)
> mcreq p15, 0, r0, c1, c0, 1
> isb
> bl omap4_get_sar_ram_base
> mov r8, r0
> ldr r9, [r8, #OMAP_TYPE_OFFSET]
> cmp r9, #0x1 @ Check for HS device
> bne scu_gp_clear
> mov r0, #SCU_PM_NORMAL
> mov r1, #0x00
> stmfd r13!, {r4-r12, r14}
> ldr r12, =OMAP4_MON_SCU_PWR_INDEX
> DO_SMC
> ldmfd r13!, {r4-r12, r14}
> b skip_scu_gp_clear
> scu_gp_clear:
> bl omap4_get_scu_base
> mov r1, #SCU_PM_NORMAL
> bl scu_power_mode
> skip_scu_gp_clear:
> isb
> dsb
> ldmfd sp!, {pc}
> ENDPROC(omap4_finish_suspend)
^ permalink raw reply [flat|nested] 119+ messages in thread* [PATCH 14/25] OMAP4: PM: Add CPUX OFF mode support
2011-09-09 15:27 ` Shawn Guo
@ 2011-09-09 16:59 ` Santosh
2011-09-09 18:34 ` Kevin Hilman
2011-09-09 23:34 ` Shawn Guo
0 siblings, 2 replies; 119+ messages in thread
From: Santosh @ 2011-09-09 16:59 UTC (permalink / raw)
To: linux-arm-kernel
On Friday 09 September 2011 08:57 PM, Shawn Guo wrote:
> On Fri, Sep 09, 2011 at 07:41:08PM +0530, Shilimkar, Santosh wrote:
>> On Fri, Sep 9, 2011 at 7:43 PM, Shawn Guo<shawn.guo@freescale.com> wrote:
>>> On Fri, Sep 09, 2011 at 01:39:51PM +0530, Santosh wrote:
>>>> On Friday 09 September 2011 01:34 PM, Shawn Guo wrote:
>>>>> Hi Santosh,
[...]
>> #ifdef CONFIG_CACHE_L2X0
>> /*
>> * Clean and invalidate the L2 cache.
>> * Common cache-l2x0.c functions can't be used here since it
>> * uses spinlocks. We are out of coherency here with data cache
>> * disabled. The spinlock implementation uses exclusive load/store
>> * instruction which can fail without data cache being enabled.
>> * OMAP4 hardware doesn't support exclusive monitor which can
>> * overcome exclusive access issue. Because of this, CPU can
>> * lead to deadlock.
>> */
>> l2x_clean_inv:
>> bl omap4_get_sar_ram_base
>> mov r8, r0
>> mrc p15, 0, r5, c0, c0, 5 @ Read MPIDR
>> ands r5, r5, #0x0f
>> ldreq r0, [r8, #L2X0_SAVE_OFFSET0]
>> ldrne r0, [r8, #L2X0_SAVE_OFFSET1]
>> cmp r0, #3
>> bne do_WFI
>
> It looks like you are bypassing L2 clean and invalidate for cases
> "1" and "2" here. But I really do not understand how you get r0
> back here.
>
The value which is passed in R0 is also stored in scratch patch memory
and retrieved using L2X0_SAVE_OFFSET0.
Simple :)
Regards
Santosh
^ permalink raw reply [flat|nested] 119+ messages in thread
* [PATCH 14/25] OMAP4: PM: Add CPUX OFF mode support
2011-09-09 16:59 ` Santosh
@ 2011-09-09 18:34 ` Kevin Hilman
2011-09-10 3:39 ` Shilimkar, Santosh
2011-09-09 23:34 ` Shawn Guo
1 sibling, 1 reply; 119+ messages in thread
From: Kevin Hilman @ 2011-09-09 18:34 UTC (permalink / raw)
To: linux-arm-kernel
Santosh <santosh.shilimkar@ti.com> writes:
> On Friday 09 September 2011 08:57 PM, Shawn Guo wrote:
>> On Fri, Sep 09, 2011 at 07:41:08PM +0530, Shilimkar, Santosh wrote:
>>> On Fri, Sep 9, 2011 at 7:43 PM, Shawn Guo<shawn.guo@freescale.com> wrote:
>>>> On Fri, Sep 09, 2011 at 01:39:51PM +0530, Santosh wrote:
>>>>> On Friday 09 September 2011 01:34 PM, Shawn Guo wrote:
>>>>>> Hi Santosh,
>
> [...]
>
>>> #ifdef CONFIG_CACHE_L2X0
>>> /*
>>> * Clean and invalidate the L2 cache.
>>> * Common cache-l2x0.c functions can't be used here since it
>>> * uses spinlocks. We are out of coherency here with data cache
>>> * disabled. The spinlock implementation uses exclusive load/store
>>> * instruction which can fail without data cache being enabled.
>>> * OMAP4 hardware doesn't support exclusive monitor which can
>>> * overcome exclusive access issue. Because of this, CPU can
>>> * lead to deadlock.
>>> */
>>> l2x_clean_inv:
>>> bl omap4_get_sar_ram_base
>>> mov r8, r0
>>> mrc p15, 0, r5, c0, c0, 5 @ Read MPIDR
>>> ands r5, r5, #0x0f
>>> ldreq r0, [r8, #L2X0_SAVE_OFFSET0]
>>> ldrne r0, [r8, #L2X0_SAVE_OFFSET1]
>>> cmp r0, #3
>>> bne do_WFI
>>
>> It looks like you are bypassing L2 clean and invalidate for cases
>> "1" and "2" here. But I really do not understand how you get r0
>> back here.
>>
> The value which is passed in R0 is also stored in scratch patch memory
> and retrieved using L2X0_SAVE_OFFSET0.
> Simple :)
Sounds like some in-code documentation needs to be added to make this a
bit more understandable.
Thanks,
Kevin
^ permalink raw reply [flat|nested] 119+ messages in thread
* [PATCH 14/25] OMAP4: PM: Add CPUX OFF mode support
2011-09-09 18:34 ` Kevin Hilman
@ 2011-09-10 3:39 ` Shilimkar, Santosh
0 siblings, 0 replies; 119+ messages in thread
From: Shilimkar, Santosh @ 2011-09-10 3:39 UTC (permalink / raw)
To: linux-arm-kernel
On Sat, Sep 10, 2011 at 12:04 AM, Kevin Hilman <khilman@ti.com> wrote:
> Santosh <santosh.shilimkar@ti.com> writes:
>
>> On Friday 09 September 2011 08:57 PM, Shawn Guo wrote:
>>> On Fri, Sep 09, 2011 at 07:41:08PM +0530, Shilimkar, Santosh wrote:
>>>> On Fri, Sep 9, 2011 at 7:43 PM, Shawn Guo<shawn.guo@freescale.com> ?wrote:
>>>>> On Fri, Sep 09, 2011 at 01:39:51PM +0530, Santosh wrote:
>>>>>> On Friday 09 September 2011 01:34 PM, Shawn Guo wrote:
>>>>>>> Hi Santosh,
>>
>> [...]
>>
>>>> #ifdef CONFIG_CACHE_L2X0
>>>> ? ? /*
>>>> ? ? ?* Clean and invalidate the L2 cache.
>>>> ? ? ?* Common cache-l2x0.c functions can't be used here since it
>>>> ? ? ?* uses spinlocks. We are out of coherency here with data cache
>>>> ? ? ?* disabled. The spinlock implementation uses exclusive load/store
>>>> ? ? ?* instruction which can fail without data cache being enabled.
>>>> ? ? ?* OMAP4 hardware doesn't support exclusive monitor which can
>>>> ? ? ?* overcome exclusive access issue. Because of this, CPU can
>>>> ? ? ?* lead to deadlock.
>>>> ? ? ?*/
>>>> l2x_clean_inv:
>>>> ? ? bl ? ? ?omap4_get_sar_ram_base
>>>> ? ? mov ? ? r8, r0
>>>> ? ? mrc ? ? p15, 0, r5, c0, c0, 5 ? ? ? ? ? @ Read MPIDR
>>>> ? ? ands ? ?r5, r5, #0x0f
>>>> ? ? ldreq ? r0, [r8, #L2X0_SAVE_OFFSET0]
>>>> ? ? ldrne ? r0, [r8, #L2X0_SAVE_OFFSET1]
>>>> ? ? cmp ? ? r0, #3
>>>> ? ? bne ? ? do_WFI
>>>
>>> It looks like you are bypassing L2 clean and invalidate for cases
>>> "1" and "2" here. ?But I really do not understand how you get r0
>>> back here.
>>>
>> The value which is passed in R0 is also stored in scratch patch memory
>> and retrieved using L2X0_SAVE_OFFSET0.
>> Simple :)
>
> Sounds like some in-code documentation needs to be added to make this a
> bit more understandable.
>
Will add a comment
^ permalink raw reply [flat|nested] 119+ messages in thread
* [PATCH 14/25] OMAP4: PM: Add CPUX OFF mode support
2011-09-09 16:59 ` Santosh
2011-09-09 18:34 ` Kevin Hilman
@ 2011-09-09 23:34 ` Shawn Guo
2011-09-10 3:38 ` Shilimkar, Santosh
1 sibling, 1 reply; 119+ messages in thread
From: Shawn Guo @ 2011-09-09 23:34 UTC (permalink / raw)
To: linux-arm-kernel
On Fri, Sep 09, 2011 at 10:29:49PM +0530, Santosh wrote:
> On Friday 09 September 2011 08:57 PM, Shawn Guo wrote:
> >On Fri, Sep 09, 2011 at 07:41:08PM +0530, Shilimkar, Santosh wrote:
> >>On Fri, Sep 9, 2011 at 7:43 PM, Shawn Guo<shawn.guo@freescale.com> wrote:
> >>>On Fri, Sep 09, 2011 at 01:39:51PM +0530, Santosh wrote:
> >>>>On Friday 09 September 2011 01:34 PM, Shawn Guo wrote:
> >>>>>Hi Santosh,
>
> [...]
>
> >>#ifdef CONFIG_CACHE_L2X0
> >> /*
> >> * Clean and invalidate the L2 cache.
> >> * Common cache-l2x0.c functions can't be used here since it
> >> * uses spinlocks. We are out of coherency here with data cache
> >> * disabled. The spinlock implementation uses exclusive load/store
> >> * instruction which can fail without data cache being enabled.
> >> * OMAP4 hardware doesn't support exclusive monitor which can
> >> * overcome exclusive access issue. Because of this, CPU can
> >> * lead to deadlock.
> >> */
> >>l2x_clean_inv:
> >> bl omap4_get_sar_ram_base
> >> mov r8, r0
> >> mrc p15, 0, r5, c0, c0, 5 @ Read MPIDR
> >> ands r5, r5, #0x0f
> >> ldreq r0, [r8, #L2X0_SAVE_OFFSET0]
> >> ldrne r0, [r8, #L2X0_SAVE_OFFSET1]
> >> cmp r0, #3
> >> bne do_WFI
> >
> >It looks like you are bypassing L2 clean and invalidate for cases
> >"1" and "2" here. But I really do not understand how you get r0
> >back here.
> >
> The value which is passed in R0 is also stored in scratch patch memory
> and retrieved using L2X0_SAVE_OFFSET0.
> Simple :)
>
Aha, no wonder that I read it wrongly. The parameter passing in r0
is here simply for confusing people.
Also, IMO, lable "l2x_clean_inv" should be put after the "bne do_WFI".
Otherwise, my original statement (it seems l2x_clean_inv will be
called for case "2") stands correct :)
--
Regards,
Shawn
^ permalink raw reply [flat|nested] 119+ messages in thread
* [PATCH 14/25] OMAP4: PM: Add CPUX OFF mode support
2011-09-09 23:34 ` Shawn Guo
@ 2011-09-10 3:38 ` Shilimkar, Santosh
2011-09-10 4:54 ` Shawn Guo
0 siblings, 1 reply; 119+ messages in thread
From: Shilimkar, Santosh @ 2011-09-10 3:38 UTC (permalink / raw)
To: linux-arm-kernel
IOn Sat, Sep 10, 2011 at 5:04 AM, Shawn Guo <shawn.guo@freescale.com> wrote:
> On Fri, Sep 09, 2011 at 10:29:49PM +0530, Santosh wrote:
>> On Friday 09 September 2011 08:57 PM, Shawn Guo wrote:
>> >On Fri, Sep 09, 2011 at 07:41:08PM +0530, Shilimkar, Santosh wrote:
>> >>On Fri, Sep 9, 2011 at 7:43 PM, Shawn Guo<shawn.guo@freescale.com> ?wrote:
>> >>>On Fri, Sep 09, 2011 at 01:39:51PM +0530, Santosh wrote:
>> >>>>On Friday 09 September 2011 01:34 PM, Shawn Guo wrote:
>> >>>>>Hi Santosh,
>>
>> [...]
>>
>> >>#ifdef CONFIG_CACHE_L2X0
>> >> ? ?/*
>> >> ? ? * Clean and invalidate the L2 cache.
>> >> ? ? * Common cache-l2x0.c functions can't be used here since it
>> >> ? ? * uses spinlocks. We are out of coherency here with data cache
>> >> ? ? * disabled. The spinlock implementation uses exclusive load/store
>> >> ? ? * instruction which can fail without data cache being enabled.
>> >> ? ? * OMAP4 hardware doesn't support exclusive monitor which can
>> >> ? ? * overcome exclusive access issue. Because of this, CPU can
>> >> ? ? * lead to deadlock.
>> >> ? ? */
>> >>l2x_clean_inv:
>> >> ? ?bl ? ? ?omap4_get_sar_ram_base
>> >> ? ?mov ? ? r8, r0
>> >> ? ?mrc ? ? p15, 0, r5, c0, c0, 5 ? ? ? ? ? @ Read MPIDR
>> >> ? ?ands ? ?r5, r5, #0x0f
>> >> ? ?ldreq ? r0, [r8, #L2X0_SAVE_OFFSET0]
>> >> ? ?ldrne ? r0, [r8, #L2X0_SAVE_OFFSET1]
>> >> ? ?cmp ? ? r0, #3
>> >> ? ?bne ? ? do_WFI
>> >
>> >It looks like you are bypassing L2 clean and invalidate for cases
>> >"1" and "2" here. ?But I really do not understand how you get r0
>> >back here.
>> >
>> The value which is passed in R0 is also stored in scratch patch memory
>> and retrieved using L2X0_SAVE_OFFSET0.
>> Simple :)
>>
> Aha, no wonder that I read it wrongly. ?The parameter passing in r0
> is here simply for confusing people.
>
No It's not. Same cod is used for CPUIDLE and we do have different
C-states than just OSWR. ON and INACTIVE makes use of it.
> Also, IMO, lable "l2x_clean_inv" should be put after the "bne do_WFI".
> Otherwise, my original statement (it seems l2x_clean_inv will be
> called for case "2") stands correct :)
>
It's just a label. All L2 related code and checks for the valid state is
kept under that by purpose.
Regards
Santosh
^ permalink raw reply [flat|nested] 119+ messages in thread
* [PATCH 14/25] OMAP4: PM: Add CPUX OFF mode support
2011-09-10 3:38 ` Shilimkar, Santosh
@ 2011-09-10 4:54 ` Shawn Guo
2011-09-10 5:51 ` Santosh
0 siblings, 1 reply; 119+ messages in thread
From: Shawn Guo @ 2011-09-10 4:54 UTC (permalink / raw)
To: linux-arm-kernel
On Sat, Sep 10, 2011 at 09:08:16AM +0530, Shilimkar, Santosh wrote:
> IOn Sat, Sep 10, 2011 at 5:04 AM, Shawn Guo <shawn.guo@freescale.com> wrote:
[...]
> > Also, IMO, lable "l2x_clean_inv" should be put after the "bne do_WFI".
> > Otherwise, my original statement (it seems l2x_clean_inv will be
> > called for case "2") stands correct :)
> >
> It's just a label. All L2 related code and checks for the valid state is
> kept under that by purpose.
>
So for some case, you enter l2x_clean_inv but do not actually clean
and invalidate L2. I do not see this label being used anywhere, so
you may want to remove it to save the confusion to stupid people like
me. Just my opinion.
--
Regards,
Shawn
^ permalink raw reply [flat|nested] 119+ messages in thread
* [PATCH 14/25] OMAP4: PM: Add CPUX OFF mode support
2011-09-10 4:54 ` Shawn Guo
@ 2011-09-10 5:51 ` Santosh
0 siblings, 0 replies; 119+ messages in thread
From: Santosh @ 2011-09-10 5:51 UTC (permalink / raw)
To: linux-arm-kernel
On Saturday 10 September 2011 10:24 AM, Shawn Guo wrote:
> On Sat, Sep 10, 2011 at 09:08:16AM +0530, Shilimkar, Santosh wrote:
>> IOn Sat, Sep 10, 2011 at 5:04 AM, Shawn Guo<shawn.guo@freescale.com> wrote:
> [...]
>>> Also, IMO, lable "l2x_clean_inv" should be put after the "bne do_WFI".
>>> Otherwise, my original statement (it seems l2x_clean_inv will be
>>> called for case "2") stands correct :)
>>>
>> It's just a label. All L2 related code and checks for the valid state is
>> kept under that by purpose.
>>
> So for some case, you enter l2x_clean_inv but do not actually clean
> and invalidate L2. I do not see this label being used anywhere, so
> you may want to remove it to save the confusion to stupid people like
> me. Just my opinion.
>
Will remove the label :)
Regards
Santosh
^ permalink raw reply [flat|nested] 119+ messages in thread
* [PATCH 14/25] OMAP4: PM: Add CPUX OFF mode support
2011-09-04 13:54 ` [PATCH 14/25] OMAP4: PM: Add CPUX OFF mode support Santosh Shilimkar
2011-09-08 19:39 ` Jean Pihet
2011-09-09 8:04 ` Shawn Guo
@ 2011-09-12 21:06 ` Kevin Hilman
2011-09-13 5:39 ` Santosh
2 siblings, 1 reply; 119+ messages in thread
From: Kevin Hilman @ 2011-09-12 21:06 UTC (permalink / raw)
To: linux-arm-kernel
Santosh Shilimkar <santosh.shilimkar@ti.com> writes:
> 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.shilimkar@ti.com>
> Cc: Kevin Hilman <khilman@ti.com>
[...]
> @@ -38,6 +39,11 @@ void __iomem *omap4_get_scu_base(void)
>
> void __cpuinit platform_secondary_init(unsigned int cpu)
> {
> + /* Enable NS access to SMP bit for this CPU on EMU/HS devices */
> + if (cpu_is_omap443x() && (omap_type() != OMAP2_DEVICE_TYPE_GP))
A comment here about why this is 443x specific would be helpful.
I see a comment in omap4_cpu_resume() that seems to indicate that SMP
bit is accessible on 446x NS devices, but repeating that commen here
would help future readability.
Kevin
^ permalink raw reply [flat|nested] 119+ messages in thread* [PATCH 14/25] OMAP4: PM: Add CPUX OFF mode support
2011-09-12 21:06 ` Kevin Hilman
@ 2011-09-13 5:39 ` Santosh
2011-09-13 17:33 ` Kevin Hilman
0 siblings, 1 reply; 119+ messages in thread
From: Santosh @ 2011-09-13 5:39 UTC (permalink / raw)
To: linux-arm-kernel
On Tuesday 13 September 2011 02:36 AM, Kevin Hilman wrote:
> Santosh Shilimkar<santosh.shilimkar@ti.com> writes:
>
>> 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.shilimkar@ti.com>
>> Cc: Kevin Hilman<khilman@ti.com>
>
> [...]
>
>> @@ -38,6 +39,11 @@ void __iomem *omap4_get_scu_base(void)
>>
>> void __cpuinit platform_secondary_init(unsigned int cpu)
>> {
>> + /* Enable NS access to SMP bit for this CPU on EMU/HS devices */
>> + if (cpu_is_omap443x()&& (omap_type() != OMAP2_DEVICE_TYPE_GP))
>
> A comment here about why this is 443x specific would be helpful.
>
> I see a comment in omap4_cpu_resume() that seems to indicate that SMP
> bit is accessible on 446x NS devices, but repeating that commen here
> would help future readability.
>
Ok. Will add comments here too. Was just trying to save some lines :)
Regards
Santosh
^ permalink raw reply [flat|nested] 119+ messages in thread* [PATCH 14/25] OMAP4: PM: Add CPUX OFF mode support
2011-09-13 5:39 ` Santosh
@ 2011-09-13 17:33 ` Kevin Hilman
2011-09-14 5:26 ` Shilimkar, Santosh
0 siblings, 1 reply; 119+ messages in thread
From: Kevin Hilman @ 2011-09-13 17:33 UTC (permalink / raw)
To: linux-arm-kernel
Santosh <santosh.shilimkar@ti.com> writes:
> On Tuesday 13 September 2011 02:36 AM, Kevin Hilman wrote:
>> Santosh Shilimkar<santosh.shilimkar@ti.com> writes:
>>
>>> 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.shilimkar@ti.com>
>>> Cc: Kevin Hilman<khilman@ti.com>
>>
>> [...]
>>
>>> @@ -38,6 +39,11 @@ void __iomem *omap4_get_scu_base(void)
>>>
>>> void __cpuinit platform_secondary_init(unsigned int cpu)
>>> {
>>> + /* Enable NS access to SMP bit for this CPU on EMU/HS devices */
>>> + if (cpu_is_omap443x()&& (omap_type() != OMAP2_DEVICE_TYPE_GP))
>>
>> A comment here about why this is 443x specific would be helpful.
>>
>> I see a comment in omap4_cpu_resume() that seems to indicate that SMP
>> bit is accessible on 446x NS devices, but repeating that commen here
>> would help future readability.
>>
> Ok. Will add comments here too. Was just trying to save some lines :)
heh, this is a negative side-effect of people caring primarily about
diffstat. :(
One other comment on this patch. You need spaces around the '&&' above.
Kevin
^ permalink raw reply [flat|nested] 119+ messages in thread* [PATCH 14/25] OMAP4: PM: Add CPUX OFF mode support
2011-09-13 17:33 ` Kevin Hilman
@ 2011-09-14 5:26 ` Shilimkar, Santosh
0 siblings, 0 replies; 119+ messages in thread
From: Shilimkar, Santosh @ 2011-09-14 5:26 UTC (permalink / raw)
To: linux-arm-kernel
On Tue, Sep 13, 2011 at 11:03 PM, Kevin Hilman <khilman@ti.com> wrote:
> Santosh <santosh.shilimkar@ti.com> writes:
>
>> On Tuesday 13 September 2011 02:36 AM, Kevin Hilman wrote:
>>> Santosh Shilimkar<santosh.shilimkar@ti.com> ?writes:
>>>
>>>> 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.shilimkar@ti.com>
>>>> Cc: Kevin Hilman<khilman@ti.com>
>>>
>>> [...]
>>>
>>>> @@ -38,6 +39,11 @@ void __iomem *omap4_get_scu_base(void)
>>>>
>>>> ? void __cpuinit platform_secondary_init(unsigned int cpu)
>>>> ? {
>>>> + ? /* Enable NS access to SMP bit for this CPU on EMU/HS devices */
>>>> + ? if (cpu_is_omap443x()&& ?(omap_type() != OMAP2_DEVICE_TYPE_GP))
>>>
>>> A comment here about why this is 443x specific would be helpful.
>>>
>>> I see a comment in omap4_cpu_resume() that seems to indicate that SMP
>>> bit is accessible on 446x NS devices, but repeating that commen here
>>> would help future readability.
>>>
>> Ok. Will add comments here too. Was just trying to save some lines :)
>
> heh, this is a negative side-effect of people caring primarily about
> diffstat. :(
>
ya.
> One other comment on this patch. ?You need spaces around the '&&' above.
>
The original patch is fine for that. Some replies has eaten that space. My
Thunderbird email client is doing the same. :(
Regards
Santosh
^ permalink raw reply [flat|nested] 119+ messages in thread
* [PATCH 15/25] OMAP4: Remove __INIT from omap_secondary_startup() to re-use it for hotplug.
2011-09-04 13:54 [PATCH 00/25] OMAP4: PM: suspend, CPU-hotplug and CPUilde support Santosh Shilimkar
` (13 preceding siblings ...)
2011-09-04 13:54 ` [PATCH 14/25] OMAP4: PM: Add CPUX OFF mode support Santosh Shilimkar
@ 2011-09-04 13:54 ` Santosh Shilimkar
2011-09-04 13:54 ` [PATCH 16/25] OMAP4: PM: Program CPU1 to hit OFF when off-lined Santosh Shilimkar
` (12 subsequent siblings)
27 siblings, 0 replies; 119+ messages in thread
From: Santosh Shilimkar @ 2011-09-04 13:54 UTC (permalink / raw)
To: linux-arm-kernel
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.shilimkar@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_PA 0x48281804
-
- __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
^ permalink raw reply related [flat|nested] 119+ messages in thread* [PATCH 16/25] OMAP4: PM: Program CPU1 to hit OFF when off-lined
2011-09-04 13:54 [PATCH 00/25] OMAP4: PM: suspend, CPU-hotplug and CPUilde support Santosh Shilimkar
` (14 preceding siblings ...)
2011-09-04 13:54 ` [PATCH 15/25] OMAP4: Remove __INIT from omap_secondary_startup() to re-use it for hotplug Santosh Shilimkar
@ 2011-09-04 13:54 ` Santosh Shilimkar
2011-09-12 21:12 ` Kevin Hilman
2011-09-04 13:54 ` [PATCH 17/25] OMAP4: PM: CPU1 wakeup workaround from Low power modes Santosh Shilimkar
` (11 subsequent siblings)
27 siblings, 1 reply; 119+ messages in thread
From: Santosh Shilimkar @ 2011-09-04 13:54 UTC (permalink / raw)
To: linux-arm-kernel
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.shilimkar@ti.com>
Cc: Kevin Hilman <khilman@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 | 33 +++++++++++++++++++++++
arch/arm/mach-omap2/omap-wakeupgen.c | 32 ++++++++++++++++++++++
4 files changed, 81 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 662f37c..14803c3 100644
--- a/arch/arm/mach-omap2/include/mach/omap4-common.h
+++ b/arch/arm/mach-omap2/include/mach/omap4-common.h
@@ -51,6 +51,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)
@@ -59,6 +60,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)
+{
+ omap_do_wfi();
+ 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 80167ec..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
*/
- omap_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 1137537..9d68abf 100644
--- a/arch/arm/mach-omap2/omap-mpuss-lowpower.c
+++ b/arch/arm/mach-omap2/omap-mpuss-lowpower.c
@@ -193,6 +193,39 @@ 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);
+ cpu_clear_prev_logic_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 a0882e6..6461f22 100644
--- a/arch/arm/mach-omap2/omap-wakeupgen.c
+++ b/arch/arm/mach-omap2/omap-wakeupgen.c
@@ -194,6 +194,36 @@ 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);
+ break;
+ }
+ return NOTIFY_OK;
+}
+
+static struct notifier_block __refdata irq_hotplug_notifier = {
+ .notifier_call = irq_cpu_hotplug_notify,
+};
+
+static void __init irq_hotplug_init(void)
+{
+ register_hotcpu_notifier(&irq_hotplug_notifier);
+}
+#else
+static void __init irq_hotplug_init(void)
+{}
+#endif
+
/*
* Initialise the wakeupgen module.
*/
@@ -237,5 +267,7 @@ int __init omap_wakeupgen_init(void)
for (i = 0; i < NR_IRQS; i++)
irq_target_cpu[i] = boot_cpu;
+ irq_hotplug_init();
+
return 0;
}
--
1.7.4.1
^ permalink raw reply related [flat|nested] 119+ messages in thread* [PATCH 16/25] OMAP4: PM: Program CPU1 to hit OFF when off-lined
2011-09-04 13:54 ` [PATCH 16/25] OMAP4: PM: Program CPU1 to hit OFF when off-lined Santosh Shilimkar
@ 2011-09-12 21:12 ` Kevin Hilman
2011-09-13 5:35 ` Santosh
0 siblings, 1 reply; 119+ messages in thread
From: Kevin Hilman @ 2011-09-12 21:12 UTC (permalink / raw)
To: linux-arm-kernel
Santosh Shilimkar <santosh.shilimkar@ti.com> writes:
> 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.shilimkar@ti.com>
> Cc: Kevin Hilman <khilman@ti.com>
[...]
> @@ -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");
nit: pr_crit() exists if you want to keep the same level. Or did you
lower the level on purpose?
Kevin
^ permalink raw reply [flat|nested] 119+ messages in thread* [PATCH 16/25] OMAP4: PM: Program CPU1 to hit OFF when off-lined
2011-09-12 21:12 ` Kevin Hilman
@ 2011-09-13 5:35 ` Santosh
0 siblings, 0 replies; 119+ messages in thread
From: Santosh @ 2011-09-13 5:35 UTC (permalink / raw)
To: linux-arm-kernel
On Tuesday 13 September 2011 02:42 AM, Kevin Hilman wrote:
> Santosh Shilimkar<santosh.shilimkar@ti.com> writes:
>
>> 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.shilimkar@ti.com>
>> Cc: Kevin Hilman<khilman@ti.com>
>
> [...]
>
>> @@ -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");
>
> nit: pr_crit() exists if you want to keep the same level. Or did you
> lower the level on purpose?
>
I lowered it on purpose since I didn't find it crtical.
Regards
Santosh
^ permalink raw reply [flat|nested] 119+ messages in thread
* [PATCH 17/25] OMAP4: PM: CPU1 wakeup workaround from Low power modes
2011-09-04 13:54 [PATCH 00/25] OMAP4: PM: suspend, CPU-hotplug and CPUilde support Santosh Shilimkar
` (15 preceding siblings ...)
2011-09-04 13:54 ` [PATCH 16/25] OMAP4: PM: Program CPU1 to hit OFF when off-lined Santosh Shilimkar
@ 2011-09-04 13:54 ` Santosh Shilimkar
2011-09-04 13:54 ` [PATCH 18/25] OMAP4: suspend: Add MPUSS power domain RETENTION support Santosh Shilimkar
` (10 subsequent siblings)
27 siblings, 0 replies; 119+ messages in thread
From: Santosh Shilimkar @ 2011-09-04 13:54 UTC (permalink / raw)
To: linux-arm-kernel
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.shilimkar@ti.com>
Cc: Kevin Hilman <khilman@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 f920abe..4872e04 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;
@@ -60,6 +62,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
@@ -75,6 +79,29 @@ int __cpuinit boot_secondary(unsigned int cpu, struct task_struct *idle)
omap_modify_auxcoreboot0(0x200, 0xfffffdff);
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
^ permalink raw reply related [flat|nested] 119+ messages in thread* [PATCH 18/25] OMAP4: suspend: Add MPUSS power domain RETENTION support
2011-09-04 13:54 [PATCH 00/25] OMAP4: PM: suspend, CPU-hotplug and CPUilde support Santosh Shilimkar
` (16 preceding siblings ...)
2011-09-04 13:54 ` [PATCH 17/25] OMAP4: PM: CPU1 wakeup workaround from Low power modes Santosh Shilimkar
@ 2011-09-04 13:54 ` Santosh Shilimkar
2011-09-15 0:27 ` Kevin Hilman
2011-09-04 13:54 ` [PATCH 19/25] OMAP4: PM: Add WakeupGen and secure GIC low power support Santosh Shilimkar
` (9 subsequent siblings)
27 siblings, 1 reply; 119+ messages in thread
From: Santosh Shilimkar @ 2011-09-04 13:54 UTC (permalink / raw)
To: linux-arm-kernel
This patch adds MPUSS(MPU Sub System) power domain
CSWR(Close Switch Retention) support to system wide suspend.
For both MPUSS RET support, CPUs are programmed to OFF state.
Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
Cc: Kevin Hilman <khilman@ti.com>
---
arch/arm/mach-omap2/omap-mpuss-lowpower.c | 16 +++++++
arch/arm/mach-omap2/pm44xx.c | 71 +++++++++++++++++++++++++++--
2 files changed, 82 insertions(+), 5 deletions(-)
diff --git a/arch/arm/mach-omap2/omap-mpuss-lowpower.c b/arch/arm/mach-omap2/omap-mpuss-lowpower.c
index 9d68abf..9f632fe 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));
@@ -270,6 +279,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 4f39de5..63e8f9b 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 <rnayak@ti.com>
+ * Santosh Shilimkar <santosh.shilimkar@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,48 @@ static LIST_HEAD(pwrst_list);
#ifdef CONFIG_SUSPEND
static int omap4_pm_suspend(void)
{
- omap_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 domain needs to be in OFF or DORMANT
+ * state. For MPUSS to reach off-mode. CPU0 and CPU1 power domain
+ * should be in off state.
+ * Only master CPU followes 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;
+ }
+ omap_set_pwrdm_state(pwrst->pwrdm, pwrst->saved_state);
+ }
+ if (ret)
+ pr_err("Could not enter target state in pm_suspend\n");
+ else
+ pr_err("Successfully put all powerdomains to target state\n");
+
return 0;
}
@@ -97,14 +141,31 @@ static int __init pwrdms_setup(struct powerdomain *pwrdm, void *unused)
if (!pwrdm->pwrsts)
return 0;
+ /*
+ * Skip CPU0 and CPU1 power domains. CPU1 is programmed
+ * through hotplug path and CPU0 explicitly programmed
+ * further down in the code path
+ */
+ if ((!strcmp(pwrdm->name, "cpu0_pwrdm")) ||
+ (!strcmp(pwrdm->name, "cpu1_pwrdm")))
+ return 0;
+
+ /*
+ * FIXME: Remove this check when core retention is supported
+ * Only MPUSS power domain is added in the list.
+ */
+ if (strcmp(pwrdm->name, "mpu_pwrdm"))
+ return 0;
+
pwrst = kmalloc(sizeof(struct power_state), GFP_ATOMIC);
if (!pwrst)
return -ENOMEM;
+
pwrst->pwrdm = pwrdm;
- pwrst->next_state = PWRDM_POWER_ON;
+ pwrst->next_state = PWRDM_POWER_RET;
list_add(&pwrst->node, &pwrst_list);
- return pwrdm_set_next_pwrst(pwrst->pwrdm, pwrst->next_state);
+ return omap_set_pwrdm_state(pwrst->pwrdm, pwrst->next_state);
}
/**
--
1.7.4.1
^ permalink raw reply related [flat|nested] 119+ messages in thread* [PATCH 18/25] OMAP4: suspend: Add MPUSS power domain RETENTION support
2011-09-04 13:54 ` [PATCH 18/25] OMAP4: suspend: Add MPUSS power domain RETENTION support Santosh Shilimkar
@ 2011-09-15 0:27 ` Kevin Hilman
2011-09-15 3:19 ` Santosh
0 siblings, 1 reply; 119+ messages in thread
From: Kevin Hilman @ 2011-09-15 0:27 UTC (permalink / raw)
To: linux-arm-kernel
Santosh Shilimkar <santosh.shilimkar@ti.com> writes:
> This patch adds MPUSS(MPU Sub System) power domain
> CSWR(Close Switch Retention) support to system wide suspend.
> For both MPUSS RET support, CPUs are programmed to OFF state.
is 'both' in the wrong place in this sentence? I think you meant:
For MPUSS retention support, both CPUs are programmed to OFF state.
> Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
> Cc: Kevin Hilman <khilman@ti.com>
> ---
> arch/arm/mach-omap2/omap-mpuss-lowpower.c | 16 +++++++
> arch/arm/mach-omap2/pm44xx.c | 71 +++++++++++++++++++++++++++--
> 2 files changed, 82 insertions(+), 5 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/omap-mpuss-lowpower.c b/arch/arm/mach-omap2/omap-mpuss-lowpower.c
> index 9d68abf..9f632fe 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));
> @@ -270,6 +279,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 4f39de5..63e8f9b 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 <rnayak@ti.com>
> + * Santosh Shilimkar <santosh.shilimkar@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,48 @@ static LIST_HEAD(pwrst_list);
> #ifdef CONFIG_SUSPEND
> static int omap4_pm_suspend(void)
> {
> - omap_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 domain needs to be in OFF or DORMANT
s/domain needs/domains need/
> + * state. For MPUSS to reach off-mode. CPU0 and CPU1 power domain
> + * should be in off state.
nit: please be consistent with naming of power states (e.g. OFF vs. off)
> + * Only master CPU followes suspend path. All other CPUs follow
> + * cpu-hotplug path in system wide suspend. On OMAP4, CPU power
> + * domain CSWR is not supported by hardware.
I think this sentence belongs a little earlier. E.g. something like
...CPU0 and CPU1 power domains need to be in OFF or DORMANT state, since
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;
> + }
> + omap_set_pwrdm_state(pwrst->pwrdm, pwrst->saved_state);
> + }
> + if (ret)
> + pr_err("Could not enter target state in pm_suspend\n");
Without more details, this isn't terribly useful. I'd suggest just
making the per-state one above pr_err().
> + else
> + pr_err("Successfully put all powerdomains to target state\n");
and this one pr_info.
> return 0;
> }
>
> @@ -97,14 +141,31 @@ static int __init pwrdms_setup(struct powerdomain *pwrdm, void *unused)
> if (!pwrdm->pwrsts)
> return 0;
>
> + /*
> + * Skip CPU0 and CPU1 power domains. CPU1 is programmed
> + * through hotplug path and CPU0 explicitly programmed
> + * further down in the code path
> + */
> + if ((!strcmp(pwrdm->name, "cpu0_pwrdm")) ||
> + (!strcmp(pwrdm->name, "cpu1_pwrdm")))
or just one compare using strncmp(pwrdm->name, "cpu", 3)
> + return 0;
> +
> + /*
> + * FIXME: Remove this check when core retention is supported
> + * Only MPUSS power domain is added in the list.
> + */
> + if (strcmp(pwrdm->name, "mpu_pwrdm"))
> + return 0;
> +
> pwrst = kmalloc(sizeof(struct power_state), GFP_ATOMIC);
> if (!pwrst)
> return -ENOMEM;
> +
> pwrst->pwrdm = pwrdm;
> - pwrst->next_state = PWRDM_POWER_ON;
> + pwrst->next_state = PWRDM_POWER_RET;
> list_add(&pwrst->node, &pwrst_list);
>
> - return pwrdm_set_next_pwrst(pwrst->pwrdm, pwrst->next_state);
> + return omap_set_pwrdm_state(pwrst->pwrdm, pwrst->next_state);
> }
>
> /**
Kevin
^ permalink raw reply [flat|nested] 119+ messages in thread* [PATCH 18/25] OMAP4: suspend: Add MPUSS power domain RETENTION support
2011-09-15 0:27 ` Kevin Hilman
@ 2011-09-15 3:19 ` Santosh
0 siblings, 0 replies; 119+ messages in thread
From: Santosh @ 2011-09-15 3:19 UTC (permalink / raw)
To: linux-arm-kernel
On Thursday 15 September 2011 05:57 AM, Kevin Hilman wrote:
> Santosh Shilimkar <santosh.shilimkar@ti.com> writes:
>
>> This patch adds MPUSS(MPU Sub System) power domain
>> CSWR(Close Switch Retention) support to system wide suspend.
>> For both MPUSS RET support, CPUs are programmed to OFF state.
>
> is 'both' in the wrong place in this sentence? I think you meant:
>
You are right.
> For MPUSS retention support, both CPUs are programmed to OFF state.
>
>> Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
>> Cc: Kevin Hilman <khilman@ti.com>
>> ---
>> arch/arm/mach-omap2/omap-mpuss-lowpower.c | 16 +++++++
>> arch/arm/mach-omap2/pm44xx.c | 71 +++++++++++++++++++++++++++--
>> 2 files changed, 82 insertions(+), 5 deletions(-)
>>
>> diff --git a/arch/arm/mach-omap2/omap-mpuss-lowpower.c b/arch/arm/mach-omap2/omap-mpuss-lowpower.c
>> index 9d68abf..9f632fe 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));
>> @@ -270,6 +279,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 4f39de5..63e8f9b 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 <rnayak@ti.com>
>> + * Santosh Shilimkar <santosh.shilimkar@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,48 @@ static LIST_HEAD(pwrst_list);
>> #ifdef CONFIG_SUSPEND
>> static int omap4_pm_suspend(void)
>> {
>> - omap_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 domain needs to be in OFF or DORMANT
>
> s/domain needs/domains need/
>
ok
>> + * state. For MPUSS to reach off-mode. CPU0 and CPU1 power domain
>> + * should be in off state.
>
> nit: please be consistent with naming of power states (e.g. OFF vs. off)
>
ok.
>> + * Only master CPU followes suspend path. All other CPUs follow
>> + * cpu-hotplug path in system wide suspend. On OMAP4, CPU power
>> + * domain CSWR is not supported by hardware.
>
> I think this sentence belongs a little earlier. E.g. something like
> ...CPU0 and CPU1 power domains need to be in OFF or DORMANT state, since
> CPU power domain CSWR is not supported by hardware.
>
Looks better.
>> + * 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;
>> + }0001
>> + omap_set_pwrdm_state(pwrst->pwrdm, pwrst->saved_state);
>> + }
>> + if (ret)
>> + pr_err("Could not enter target state in pm_suspend\n");
>
> Without more details, this isn't terribly useful. I'd suggest just
> making the per-state one above pr_err().
>
You mean pr_crit ?
>> + else
>> + pr_err("Successfully put all powerdomains to target state\n");
>
> and this one pr_info.
>
>> return 0;
>> }
>>
>> @@ -97,14 +141,31 @@ static int __init pwrdms_setup(struct powerdomain *pwrdm, void *unused)
>> if (!pwrdm->pwrsts)
>> return 0;
>>
>> + /*
>> + * Skip CPU0 and CPU1 power domains. CPU1 is programmed
>> + * through hotplug path and CPU0 explicitly programmed
>> + * further down in the code path
>> + */
>> + if ((!strcmp(pwrdm->name, "cpu0_pwrdm")) ||
>> + (!strcmp(pwrdm->name, "cpu1_pwrdm")))
>
> or just one compare using strncmp(pwrdm->name, "cpu", 3)
>
Let me check this.
Regards
Santosh
^ permalink raw reply [flat|nested] 119+ messages in thread
* [PATCH 19/25] OMAP4: PM: Add WakeupGen and secure GIC low power support
2011-09-04 13:54 [PATCH 00/25] OMAP4: PM: suspend, CPU-hotplug and CPUilde support Santosh Shilimkar
` (17 preceding siblings ...)
2011-09-04 13:54 ` [PATCH 18/25] OMAP4: suspend: Add MPUSS power domain RETENTION support Santosh Shilimkar
@ 2011-09-04 13:54 ` Santosh Shilimkar
2011-09-04 13:54 ` [PATCH 20/25] OMAP4: PM: Add L2X0 cache lowpower support Santosh Shilimkar
` (8 subsequent siblings)
27 siblings, 0 replies; 119+ messages in thread
From: Santosh Shilimkar @ 2011-09-04 13:54 UTC (permalink / raw)
To: linux-arm-kernel
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.shilimkar@ti.com>
Cc: Kevin Hilman <khilman@ti.com>
---
arch/arm/mach-omap2/omap-wakeupgen.c | 130 ++++++++++++++++++++++++++++++++
arch/arm/mach-omap2/omap4-sar-layout.h | 15 ++++
2 files changed, 145 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/omap-wakeupgen.c b/arch/arm/mach-omap2/omap-wakeupgen.c
index 6461f22..6a24764 100644
--- a/arch/arm/mach-omap2/omap-wakeupgen.c
+++ b/arch/arm/mach-omap2/omap-wakeupgen.c
@@ -21,10 +21,17 @@
#include <linux/io.h>
#include <linux/irq.h>
#include <linux/platform_device.h>
+#include <linux/notifier.h>
+#include <linux/cpu.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
@@ -35,6 +42,7 @@
#define CPU1_ID 0x1
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];
@@ -54,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;
@@ -194,6 +207,91 @@ 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 secure API
+ * for HS/EMU devices.
+ */
+static void irq_save_secure_context(void)
+{
+ u32 ret;
+ ret = omap_secure_dispatcher(OMAP4_HAL_SAVEGIC_INDEX,
+ FLAG_START_CRITICAL,
+ 0, 0, 0, 0, 0);
+ if (ret != API_HAL_RET_VALUE_OK)
+ pr_err("GIC and Wakeupgen context save failed\n");
+}
+
#ifdef CONFIG_HOTPLUG_CPU
static int __cpuinit irq_cpu_hotplug_notify(struct notifier_block *self,
unsigned long action, void *hcpu)
@@ -224,6 +322,37 @@ static void __init irq_hotplug_init(void)
{}
#endif
+#ifdef CONFIG_CPU_PM
+static int irq_notifier(struct notifier_block *self, unsigned long cmd, void *v)
+{
+ switch (cmd) {
+ case CPU_CLUSTER_PM_ENTER:
+ if (omap_type() == OMAP2_DEVICE_TYPE_GP)
+ irq_save_context();
+ else
+ irq_save_secure_context();
+ break;
+ case CPU_CLUSTER_PM_EXIT:
+ if (omap_type() == OMAP2_DEVICE_TYPE_GP)
+ irq_sar_clear();
+ break;
+ }
+ return NOTIFY_OK;
+}
+
+static struct notifier_block irq_notifier_block = {
+ .notifier_call = irq_notifier,
+};
+
+static void __init irq_pm_init(void)
+{
+ cpu_pm_register_notifier(&irq_notifier_block);
+}
+#else
+static void __init irq_pm_init(void)
+{}
+#endif
+
/*
* Initialise the wakeupgen module.
*/
@@ -268,6 +397,7 @@ int __init omap_wakeupgen_init(void)
irq_target_cpu[i] = boot_cpu;
irq_hotplug_init();
+ irq_pm_init();
return 0;
}
diff --git a/arch/arm/mach-omap2/omap4-sar-layout.h b/arch/arm/mach-omap2/omap4-sar-layout.h
index 970a2ee..aa14a8d 100644
--- a/arch/arm/mach-omap2/omap4-sar-layout.h
+++ b/arch/arm/mach-omap2/omap4-sar-layout.h
@@ -28,4 +28,19 @@
#define CPU0_WAKEUP_NS_PA_ADDR_OFFSET 0xa04
#define CPU1_WAKEUP_NS_PA_ADDR_OFFSET 0xa08
+#define SAR_BACKUP_STATUS_OFFSET (SAR_BANK3_OFFSET + 0x500)
+#define SAR_SECURE_RAM_SIZE_OFFSET (SAR_BANK3_OFFSET + 0x504)
+#define SAR_SECRAM_SAVED_AT_OFFSET (SAR_BANK3_OFFSET + 0x508)
+
+/* WakeUpGen save restore offset from OMAP44XX_SAR_RAM_BASE */
+#define WAKEUPGENENB_OFFSET_CPU0 (SAR_BANK3_OFFSET + 0x684)
+#define WAKEUPGENENB_SECURE_OFFSET_CPU0 (SAR_BANK3_OFFSET + 0x694)
+#define WAKEUPGENENB_OFFSET_CPU1 (SAR_BANK3_OFFSET + 0x6a4)
+#define WAKEUPGENENB_SECURE_OFFSET_CPU1 (SAR_BANK3_OFFSET + 0x6b4)
+#define AUXCOREBOOT0_OFFSET (SAR_BANK3_OFFSET + 0x6c4)
+#define AUXCOREBOOT1_OFFSET (SAR_BANK3_OFFSET + 0x6c8)
+#define PTMSYNCREQ_MASK_OFFSET (SAR_BANK3_OFFSET + 0x6cc)
+#define PTMSYNCREQ_EN_OFFSET (SAR_BANK3_OFFSET + 0x6d0)
+#define SAR_BACKUP_STATUS_WAKEUPGEN 0x10
+
#endif
--
1.7.4.1
^ permalink raw reply related [flat|nested] 119+ messages in thread* [PATCH 20/25] OMAP4: PM: Add L2X0 cache lowpower support
2011-09-04 13:54 [PATCH 00/25] OMAP4: PM: suspend, CPU-hotplug and CPUilde support Santosh Shilimkar
` (18 preceding siblings ...)
2011-09-04 13:54 ` [PATCH 19/25] OMAP4: PM: Add WakeupGen and secure GIC low power support Santosh Shilimkar
@ 2011-09-04 13:54 ` Santosh Shilimkar
2011-09-05 14:01 ` Lorenzo Pieralisi
2011-09-16 17:23 ` Kevin Hilman
2011-09-04 13:54 ` [PATCH 21/25] OMAP4: PM: Add MPUSS power domain OSWR support Santosh Shilimkar
` (7 subsequent siblings)
27 siblings, 2 replies; 119+ messages in thread
From: Santosh Shilimkar @ 2011-09-04 13:54 UTC (permalink / raw)
To: linux-arm-kernel
When MPUSS hits off-mode e, 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.shilimkar@ti.com>
Cc: Kevin Hilman <khilman@ti.com>
---
arch/arm/mach-omap2/include/mach/omap-secure.h | 5 +
arch/arm/mach-omap2/omap-mpuss-lowpower.c | 38 +++++++++-
arch/arm/mach-omap2/omap4-sar-layout.h | 4 +
arch/arm/mach-omap2/sleep44xx.S | 96 ++++++++++++++++++++++++
4 files changed, 142 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_INDEX 0x108
+#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 9f632fe..aea6deb 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,33 @@ 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.
+ */
+static void save_l2x0_context(void)
+{
+#ifdef CONFIG_CACHE_L2X0
+ 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);
+#endif
+}
+
/**
* omap4_enter_lowpower: OMAP4 MPUSS Low Power Entry Function
* The purpose of this function is to manage low power programming
@@ -182,6 +212,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 CPU id
@@ -241,17 +272,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");
@@ -267,6 +300,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");
@@ -292,6 +326,8 @@ int __init omap4_mpuss_init(void)
else
__raw_writel(0, sar_base + OMAP_TYPE_OFFSET);
+ save_l2x0_context();
+
return 0;
}
diff --git a/arch/arm/mach-omap2/omap4-sar-layout.h b/arch/arm/mach-omap2/omap4-sar-layout.h
index aa14a8d..fe5b545 100644
--- a/arch/arm/mach-omap2/omap4-sar-layout.h
+++ b/arch/arm/mach-omap2/omap4-sar-layout.h
@@ -23,6 +23,10 @@
#define SCU_OFFSET0 0xd00
#define SCU_OFFSET1 0xd04
#define OMAP_TYPE_OFFSET 0xd10
+#define L2X0_SAVE_OFFSET0 0xd14
+#define L2X0_SAVE_OFFSET1 0xd18
+#define L2X0_AUXCTRL_OFFSET 0xd1c
+#define L2X0_PREFETCH_CTRL_OFFSET 0xd20
/* CPUx Wakeup Non-Secure Physical Address offsets in SAR_BANK3 */
#define CPU0_WAKEUP_NS_PA_ADDR_OFFSET 0xa04
diff --git a/arch/arm/mach-omap2/sleep44xx.S b/arch/arm/mach-omap2/sleep44xx.S
index 230ab8c..a7cce0b 100644
--- a/arch/arm/mach-omap2/sleep44xx.S
+++ b/arch/arm/mach-omap2/sleep44xx.S
@@ -32,6 +32,9 @@
ppa_zero_params:
.word 0x0
+ppa_por_params:
+ .word 1, 0
+
/*
* =============================
* == CPU suspend finisher ==
@@ -130,6 +133,55 @@ skip_scu_gp_set:
mcrne p15, 0, r0, c1, c0, 1
isb
dsb
+#ifdef CONFIG_CACHE_L2X0
+ /*
+ * Clean and invalidate the L2 cache.
+ * Common cache-l2x0.c functions can't be used here since it
+ * uses spinlocks. We are out of coherency here with data cache
+ * disabled. The spinlock implementation uses exclusive load/store
+ * instruction which can fail without data cache being enabled.
+ * OMAP4 hardware doesn't support exclusive monitor which can
+ * overcome exclusive access issue. Because of this, CPU can
+ * lead to deadlock.
+ */
+l2x_clean_inv:
+ bl omap4_get_sar_ram_base
+ mov r8, r0
+ mrc p15, 0, r5, c0, c0, 5 @ Read MPIDR
+ ands r5, r5, #0x0f
+ ldreq r0, [r8, #L2X0_SAVE_OFFSET0]
+ ldrne r0, [r8, #L2X0_SAVE_OFFSET1]
+ cmp r0, #3
+ bne do_WFI
+#ifdef CONFIG_PL310_ERRATA_727915
+ mov r0, #0x03
+ mov r12, #OMAP4_MON_L2X0_DBG_CTRL_INDEX
+ DO_SMC
+#endif
+ bl omap4_get_l2cache_base
+ mov r2, r0
+ ldr r0, =0xffff
+ str r0, [r2, #L2X0_CLEAN_INV_WAY]
+wait:
+ ldr r0, [r2, #L2X0_CLEAN_INV_WAY]
+ ldr r1, =0xffff
+ ands r0, r0, r1
+ bne wait
+#ifdef CONFIG_PL310_ERRATA_727915
+ mov r0, #0x00
+ mov r12, #OMAP4_MON_L2X0_DBG_CTRL_INDEX
+ DO_SMC
+#endif
+l2x_sync:
+ bl omap4_get_l2cache_base
+ mov r2, r0
+ mov r0, #0x0
+ str r0, [r2, #L2X0_CACHE_SYNC]
+sync:
+ ldr r0, [r2, #L2X0_CACHE_SYNC]
+ ands r0, r0, #0x1
+ bne sync
+#endif
do_WFI:
bl omap_do_wfi
@@ -222,6 +274,50 @@ enable_smp_bit:
mcreq p15, 0, r0, c1, c0, 1
isb
skip_ns_smp_enable:
+#ifdef CONFIG_CACHE_L2X0
+ /*
+ * Restore the L2 AUXCTRL and enable the L2 cache.
+ * OMAP4_MON_L2X0_AUXCTRL_INDEX = Program the L2X0 AUXCTRL
+ * OMAP4_MON_L2X0_CTRL_INDEX = Enable the L2 using L2X0 CTRL
+ * register r0 contains value to be programmed.
+ * L2 cache is already invalidate by ROM code as part
+ * of MPUSS OFF wakeup path.
+ */
+ ldr r2, =OMAP44XX_L2CACHE_BASE
+ ldr r0, [r2, #L2X0_CTRL]
+ and r0, #0x0f
+ cmp r0, #1
+ beq skip_l2en @ Skip if already enabled
+ ldr r3, =OMAP44XX_SAR_RAM_BASE
+ ldr r1, [r3, #OMAP_TYPE_OFFSET]
+ cmp r1, #0x1 @ Check for HS device
+ bne set_gp_por
+ ldr r0, =OMAP4_PPA_L2_POR_INDEX
+ ldr r1, =OMAP44XX_SAR_RAM_BASE
+ ldr r4, [r1, #L2X0_PREFETCH_CTRL_OFFSET]
+ adr r3, ppa_por_params
+ str r4, [r3, #0x04]
+ mov r1, #0x0 @ Process ID
+ mov r2, #0x4 @ Flag
+ mov r6, #0xff
+ mov r12, #0x00 @ Secure Service ID
+ DO_SMC
+ b set_aux_ctrl
+set_gp_por:
+ ldr r1, =OMAP44XX_SAR_RAM_BASE
+ ldr r0, [r1, #L2X0_PREFETCH_CTRL_OFFSET]
+ ldr r12, =OMAP4_MON_L2X0_PREFETCH_INDEX @ Setup L2 PREFETCH
+ DO_SMC
+set_aux_ctrl:
+ ldr r1, =OMAP44XX_SAR_RAM_BASE
+ ldr r0, [r1, #L2X0_AUXCTRL_OFFSET]
+ ldr r12, =OMAP4_MON_L2X0_AUXCTRL_INDEX @ Setup L2 AUXCTRL
+ DO_SMC
+ mov r0, #0x1
+ ldr r12, =OMAP4_MON_L2X0_CTRL_INDEX @ Enable L2 cache
+ DO_SMC
+skip_l2en:
+#endif
b cpu_resume @ Jump to generic resume
ENDPROC(omap4_cpu_resume)
--
1.7.4.1
^ permalink raw reply related [flat|nested] 119+ messages in thread* [PATCH 20/25] OMAP4: PM: Add L2X0 cache lowpower support
2011-09-04 13:54 ` [PATCH 20/25] OMAP4: PM: Add L2X0 cache lowpower support Santosh Shilimkar
@ 2011-09-05 14:01 ` Lorenzo Pieralisi
2011-09-05 14:13 ` Santosh
2011-09-16 17:23 ` Kevin Hilman
1 sibling, 1 reply; 119+ messages in thread
From: Lorenzo Pieralisi @ 2011-09-05 14:01 UTC (permalink / raw)
To: linux-arm-kernel
Hi Santosh,
just a question below.
On Sun, Sep 04, 2011 at 02:54:21PM +0100, Santosh Shilimkar wrote:
> When MPUSS hits off-mode e, 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.shilimkar@ti.com>
> Cc: Kevin Hilman <khilman@ti.com>
> ---
> arch/arm/mach-omap2/include/mach/omap-secure.h | 5 +
> arch/arm/mach-omap2/omap-mpuss-lowpower.c | 38 +++++++++-
> arch/arm/mach-omap2/omap4-sar-layout.h | 4 +
> arch/arm/mach-omap2/sleep44xx.S | 96 ++++++++++++++++++++++++
> 4 files changed, 142 insertions(+), 1 deletions(-)
>
[...]
> diff --git a/arch/arm/mach-omap2/sleep44xx.S b/arch/arm/mach-omap2/sleep44xx.S
> index 230ab8c..a7cce0b 100644
> --- a/arch/arm/mach-omap2/sleep44xx.S
> +++ b/arch/arm/mach-omap2/sleep44xx.S
> @@ -32,6 +32,9 @@
> ppa_zero_params:
> .word 0x0
>
> +ppa_por_params:
> + .word 1, 0
> +
> /*
> * =============================
> * == CPU suspend finisher ==
> @@ -130,6 +133,55 @@ skip_scu_gp_set:
> mcrne p15, 0, r0, c1, c0, 1
> isb
> dsb
> +#ifdef CONFIG_CACHE_L2X0
> + /*
> + * Clean and invalidate the L2 cache.
> + * Common cache-l2x0.c functions can't be used here since it
> + * uses spinlocks. We are out of coherency here with data cache
> + * disabled. The spinlock implementation uses exclusive load/store
> + * instruction which can fail without data cache being enabled.
> + * OMAP4 hardware doesn't support exclusive monitor which can
> + * overcome exclusive access issue. Because of this, CPU can
> + * lead to deadlock.
> + */
> +l2x_clean_inv:
> + bl omap4_get_sar_ram_base
> + mov r8, r0
> + mrc p15, 0, r5, c0, c0, 5 @ Read MPIDR
> + ands r5, r5, #0x0f
> + ldreq r0, [r8, #L2X0_SAVE_OFFSET0]
> + ldrne r0, [r8, #L2X0_SAVE_OFFSET1]
> + cmp r0, #3
> + bne do_WFI
> +#ifdef CONFIG_PL310_ERRATA_727915
> + mov r0, #0x03
> + mov r12, #OMAP4_MON_L2X0_DBG_CTRL_INDEX
> + DO_SMC
> +#endif
> + bl omap4_get_l2cache_base
> + mov r2, r0
> + ldr r0, =0xffff
> + str r0, [r2, #L2X0_CLEAN_INV_WAY]
> +wait:
> + ldr r0, [r2, #L2X0_CLEAN_INV_WAY]
> + ldr r1, =0xffff
> + ands r0, r0, r1
> + bne wait
> +#ifdef CONFIG_PL310_ERRATA_727915
> + mov r0, #0x00
> + mov r12, #OMAP4_MON_L2X0_DBG_CTRL_INDEX
> + DO_SMC
> +#endif
> +l2x_sync:
> + bl omap4_get_l2cache_base
> + mov r2, r0
> + mov r0, #0x0
> + str r0, [r2, #L2X0_CACHE_SYNC]
> +sync:
> + ldr r0, [r2, #L2X0_CACHE_SYNC]
> + ands r0, r0, #0x1
> + bne sync
> +#endif
>
If I am not mistaken, here the PL310 is still on. Is it
safe to go to wfi (PL310 logic state is lost then ?) with the controller
enabled ? You still use the stack and I think prefetch is enabled,
do not know if you can end up having AXI bus transactions ongoing
whilst HW yanks the power. To disable it I think you need a secure call,
again it is just a question for my information.
Thanks,
Lorenzo
> do_WFI:
> bl omap_do_wfi
> @@ -222,6 +274,50 @@ enable_smp_bit:
> mcreq p15, 0, r0, c1, c0, 1
> isb
> skip_ns_smp_enable:
> +#ifdef CONFIG_CACHE_L2X0
> + /*
> + * Restore the L2 AUXCTRL and enable the L2 cache.
> + * OMAP4_MON_L2X0_AUXCTRL_INDEX = Program the L2X0 AUXCTRL
> + * OMAP4_MON_L2X0_CTRL_INDEX = Enable the L2 using L2X0 CTRL
> + * register r0 contains value to be programmed.
> + * L2 cache is already invalidate by ROM code as part
> + * of MPUSS OFF wakeup path.
> + */
> + ldr r2, =OMAP44XX_L2CACHE_BASE
> + ldr r0, [r2, #L2X0_CTRL]
> + and r0, #0x0f
> + cmp r0, #1
> + beq skip_l2en @ Skip if already enabled
> + ldr r3, =OMAP44XX_SAR_RAM_BASE
> + ldr r1, [r3, #OMAP_TYPE_OFFSET]
> + cmp r1, #0x1 @ Check for HS device
> + bne set_gp_por
> + ldr r0, =OMAP4_PPA_L2_POR_INDEX
> + ldr r1, =OMAP44XX_SAR_RAM_BASE
> + ldr r4, [r1, #L2X0_PREFETCH_CTRL_OFFSET]
> + adr r3, ppa_por_params
> + str r4, [r3, #0x04]
> + mov r1, #0x0 @ Process ID
> + mov r2, #0x4 @ Flag
> + mov r6, #0xff
> + mov r12, #0x00 @ Secure Service ID
> + DO_SMC
> + b set_aux_ctrl
> +set_gp_por:
> + ldr r1, =OMAP44XX_SAR_RAM_BASE
> + ldr r0, [r1, #L2X0_PREFETCH_CTRL_OFFSET]
> + ldr r12, =OMAP4_MON_L2X0_PREFETCH_INDEX @ Setup L2 PREFETCH
> + DO_SMC
> +set_aux_ctrl:
> + ldr r1, =OMAP44XX_SAR_RAM_BASE
> + ldr r0, [r1, #L2X0_AUXCTRL_OFFSET]
> + ldr r12, =OMAP4_MON_L2X0_AUXCTRL_INDEX @ Setup L2 AUXCTRL
> + DO_SMC
> + mov r0, #0x1
> + ldr r12, =OMAP4_MON_L2X0_CTRL_INDEX @ Enable L2 cache
> + DO_SMC
> +skip_l2en:
> +#endif
>
> b cpu_resume @ Jump to generic resume
> ENDPROC(omap4_cpu_resume)
> --
> 1.7.4.1
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>
^ permalink raw reply [flat|nested] 119+ messages in thread
* [PATCH 20/25] OMAP4: PM: Add L2X0 cache lowpower support
2011-09-05 14:01 ` Lorenzo Pieralisi
@ 2011-09-05 14:13 ` Santosh
0 siblings, 0 replies; 119+ messages in thread
From: Santosh @ 2011-09-05 14:13 UTC (permalink / raw)
To: linux-arm-kernel
On Monday 05 September 2011 07:31 PM, Lorenzo Pieralisi wrote:
> Hi Santosh,
>
> just a question below.
>
> On Sun, Sep 04, 2011 at 02:54:21PM +0100, Santosh Shilimkar wrote:
>> When MPUSS hits off-mode e, 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.shilimkar@ti.com>
>> Cc: Kevin Hilman<khilman@ti.com>
>> ---
>> arch/arm/mach-omap2/include/mach/omap-secure.h | 5 +
>> arch/arm/mach-omap2/omap-mpuss-lowpower.c | 38 +++++++++-
>> arch/arm/mach-omap2/omap4-sar-layout.h | 4 +
>> arch/arm/mach-omap2/sleep44xx.S | 96 ++++++++++++++++++++++++
>> 4 files changed, 142 insertions(+), 1 deletions(-)
>>
>
> [...]
>
>> diff --git a/arch/arm/mach-omap2/sleep44xx.S b/arch/arm/mach-omap2/sleep44xx.S
>> index 230ab8c..a7cce0b 100644
>> --- a/arch/arm/mach-omap2/sleep44xx.S
>> +++ b/arch/arm/mach-omap2/sleep44xx.S
>> @@ -32,6 +32,9 @@
>> ppa_zero_params:
>> .word 0x0
>>
>> +ppa_por_params:
>> + .word 1, 0
>> +
>> /*
>> * =============================
>> * == CPU suspend finisher ==
>> @@ -130,6 +133,55 @@ skip_scu_gp_set:
>> mcrne p15, 0, r0, c1, c0, 1
>> isb
>> dsb
>> +#ifdef CONFIG_CACHE_L2X0
>> + /*
>> + * Clean and invalidate the L2 cache.
>> + * Common cache-l2x0.c functions can't be used here since it
>> + * uses spinlocks. We are out of coherency here with data cache
>> + * disabled. The spinlock implementation uses exclusive load/store
>> + * instruction which can fail without data cache being enabled.
>> + * OMAP4 hardware doesn't support exclusive monitor which can
>> + * overcome exclusive access issue. Because of this, CPU can
>> + * lead to deadlock.
>> + */
>> +l2x_clean_inv:
>> + bl omap4_get_sar_ram_base
>> + mov r8, r0
>> + mrc p15, 0, r5, c0, c0, 5 @ Read MPIDR
>> + ands r5, r5, #0x0f
>> + ldreq r0, [r8, #L2X0_SAVE_OFFSET0]
>> + ldrne r0, [r8, #L2X0_SAVE_OFFSET1]
>> + cmp r0, #3
>> + bne do_WFI
>> +#ifdef CONFIG_PL310_ERRATA_727915
>> + mov r0, #0x03
>> + mov r12, #OMAP4_MON_L2X0_DBG_CTRL_INDEX
>> + DO_SMC
>> +#endif
>> + bl omap4_get_l2cache_base
>> + mov r2, r0
>> + ldr r0, =0xffff
>> + str r0, [r2, #L2X0_CLEAN_INV_WAY]
>> +wait:
>> + ldr r0, [r2, #L2X0_CLEAN_INV_WAY]
>> + ldr r1, =0xffff
>> + ands r0, r0, r1
>> + bne wait
>> +#ifdef CONFIG_PL310_ERRATA_727915
>> + mov r0, #0x00
>> + mov r12, #OMAP4_MON_L2X0_DBG_CTRL_INDEX
>> + DO_SMC
>> +#endif
>> +l2x_sync:
>> + bl omap4_get_l2cache_base
>> + mov r2, r0
>> + mov r0, #0x0
>> + str r0, [r2, #L2X0_CACHE_SYNC]
>> +sync:
>> + ldr r0, [r2, #L2X0_CACHE_SYNC]
>> + ands r0, r0, #0x1
>> + bne sync
>> +#endif
>>
>
> If I am not mistaken, here the PL310 is still on. Is it
> safe to go to wfi (PL310 logic state is lost then ?) with the controller
> enabled ? You still use the stack and I think prefetch is enabled,
> do not know if you can end up having AXI bus transactions ongoing
> whilst HW yanks the power. To disable it I think you need a secure call,
> again it is just a question for my information.
>
PL310 is ON but C-bit is disabled. More over the Last sync will ensure
that all out-standing transactions are completed. So it should be
safe to go down. On OMAP, hardware waits for AXI transation complete
before CPU transitioning to low power, so that's not an issue.
For disabling, we need secure call. I didn't disable it because
we haven't seen any issue so far and AXI ack is already in
place.
Regards
Santosh
^ permalink raw reply [flat|nested] 119+ messages in thread
* [PATCH 20/25] OMAP4: PM: Add L2X0 cache lowpower support
2011-09-04 13:54 ` [PATCH 20/25] OMAP4: PM: Add L2X0 cache lowpower support Santosh Shilimkar
2011-09-05 14:01 ` Lorenzo Pieralisi
@ 2011-09-16 17:23 ` Kevin Hilman
2011-09-18 8:46 ` Santosh
1 sibling, 1 reply; 119+ messages in thread
From: Kevin Hilman @ 2011-09-16 17:23 UTC (permalink / raw)
To: linux-arm-kernel
Santosh Shilimkar <santosh.shilimkar@ti.com> writes:
> When MPUSS hits off-mode e, L2 cache is lost. This patch adds L2X0
^^^
extra 'e' ?
> necessary maintenance operations and context restoration in the
> low power code.
>
> Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
> Cc: Kevin Hilman <khilman@ti.com>
[...]
> @@ -135,6 +138,33 @@ 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.
> + */
> +static void save_l2x0_context(void)
> +{
> +#ifdef CONFIG_CACHE_L2X0
> + 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);
> +#endif
nit: (c.f. '#ifdefs are ugly' in Documentatin/SubmittingPatches)
This should probably be more like
#ifdef CONFIG_CACHE_L2X0
static void save_l2x0_context(void)
{
/* real function */
}
#else
static void save_l2x0_context(void) {}
#endif
Kevin
^ permalink raw reply [flat|nested] 119+ messages in thread* [PATCH 20/25] OMAP4: PM: Add L2X0 cache lowpower support
2011-09-16 17:23 ` Kevin Hilman
@ 2011-09-18 8:46 ` Santosh
0 siblings, 0 replies; 119+ messages in thread
From: Santosh @ 2011-09-18 8:46 UTC (permalink / raw)
To: linux-arm-kernel
On Friday 16 September 2011 10:53 PM, Kevin Hilman wrote:
> Santosh Shilimkar <santosh.shilimkar@ti.com> writes:
>
>> When MPUSS hits off-mode e, L2 cache is lost. This patch adds L2X0
> ^^^
> extra 'e' ?
>
>> necessary maintenance operations and context restoration in the
>> low power code.
>>
>> Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
>> Cc: Kevin Hilman <khilman@ti.com>
>
> [...]
>
>> @@ -135,6 +138,33 @@ 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.
>> + */
>> +static void save_l2x0_context(void)
>> +{
>> +#ifdef CONFIG_CACHE_L2X0
>> + 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);
>> +#endif
>
> nit: (c.f. '#ifdefs are ugly' in Documentatin/SubmittingPatches)
>
> This should probably be more like
>
> #ifdef CONFIG_CACHE_L2X0
> static void save_l2x0_context(void)
> {
> /* real function */
> }
> #else
> static void save_l2x0_context(void) {}
> #endif
>
Ok. Will fix this.
Regards
Santosh
^ permalink raw reply [flat|nested] 119+ messages in thread
* [PATCH 21/25] OMAP4: PM: Add MPUSS power domain OSWR support
2011-09-04 13:54 [PATCH 00/25] OMAP4: PM: suspend, CPU-hotplug and CPUilde support Santosh Shilimkar
` (19 preceding siblings ...)
2011-09-04 13:54 ` [PATCH 20/25] OMAP4: PM: Add L2X0 cache lowpower support Santosh Shilimkar
@ 2011-09-04 13:54 ` Santosh Shilimkar
2011-09-12 18:52 ` Kevin Hilman
2011-09-04 13:54 ` [PATCH 22/25] OMAP4: PM: Add power domain statistics support Santosh Shilimkar
` (6 subsequent siblings)
27 siblings, 1 reply; 119+ messages in thread
From: Santosh Shilimkar @ 2011-09-04 13:54 UTC (permalink / raw)
To: linux-arm-kernel
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.shilimkar@ti.com>
Cc: Kevin Hilman <khilman@ti.com>
---
arch/arm/mach-omap2/include/mach/omap4-common.h | 10 +++-
arch/arm/mach-omap2/omap-mpuss-lowpower.c | 65 +++++++++++++++++++++-
arch/arm/mach-omap2/pm44xx.c | 4 ++
3 files changed, 75 insertions(+), 4 deletions(-)
diff --git a/arch/arm/mach-omap2/include/mach/omap4-common.h b/arch/arm/mach-omap2/include/mach/omap4-common.h
index 14803c3..6651cb0 100644
--- a/arch/arm/mach-omap2/include/mach/omap4-common.h
+++ b/arch/arm/mach-omap2/include/mach/omap4-common.h
@@ -52,6 +52,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)
@@ -70,11 +71,18 @@ static inline int omap4_mpuss_init(void)
{
return 0;
}
-
+static inline u32 omap4_mpuss_read_prev_context_state(void)
+{
+ return 0;
+}
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__ */
diff --git a/arch/arm/mach-omap2/omap-mpuss-lowpower.c b/arch/arm/mach-omap2/omap-mpuss-lowpower.c
index aea6deb..4dd9d0f 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 operations.
*/
@@ -207,8 +253,18 @@ int omap4_enter_lowpower(unsigned int cpu, unsigned int power_state)
return -ENXIO;
}
+ /*
+ * Check MPUSS next state and save interrupt controller if needed.
+ * In MPUSS OSWR or device OFF, interrupt controller contest is lost.
+ */
+ mpuss_clear_prev_logic_pwrst();
pwrdm_clear_all_prev_pwrst(mpuss_pd);
+ if ((pwrdm_read_next_pwrst(mpuss_pd) == PWRDM_POWER_RET) &&
+ (pwrdm_read_logic_retst(mpuss_pd) == PWRDM_POWER_OFF))
+ save_state = 2;
+
clear_cpu_prev_pwrst(cpu);
+ cpu_clear_prev_logic_pwrst(cpu);
set_cpu_next_pwrst(cpu, power_state);
set_cpu_wakeup_addr(cpu, virt_to_phys(omap4_cpu_resume));
scu_pwrst_prepare(cpu, power_state);
@@ -293,6 +349,7 @@ int __init omap4_mpuss_init(void)
/* Clear CPU previous power domain state */
pwrdm_clear_all_prev_pwrst(pm_info->pwrdm);
+ cpu_clear_prev_logic_pwrst(0);
/* Initialise CPU0 power domain state to ON */
pwrdm_set_next_pwrst(pm_info->pwrdm, PWRDM_POWER_ON);
@@ -309,6 +366,7 @@ int __init omap4_mpuss_init(void)
/* Clear CPU previous power domain state */
pwrdm_clear_all_prev_pwrst(pm_info->pwrdm);
+ cpu_clear_prev_logic_pwrst(1);
/* Initialise CPU1 power domain state to ON */
pwrdm_set_next_pwrst(pm_info->pwrdm, PWRDM_POWER_ON);
@@ -319,6 +377,7 @@ int __init omap4_mpuss_init(void)
return -ENODEV;
}
pwrdm_clear_all_prev_pwrst(mpuss_pd);
+ mpuss_clear_prev_logic_pwrst();
/* Save device type on scratchpad for low level code to use */
if (omap_type() != OMAP2_DEVICE_TYPE_GP)
diff --git a/arch/arm/mach-omap2/pm44xx.c b/arch/arm/mach-omap2/pm44xx.c
index 63e8f9b..8df57cb 100644
--- a/arch/arm/mach-omap2/pm44xx.c
+++ b/arch/arm/mach-omap2/pm44xx.c
@@ -28,6 +28,7 @@ struct power_state {
u32 next_state;
#ifdef CONFIG_SUSPEND
u32 saved_state;
+ u32 saved_logic_state;
#endif
struct list_head node;
};
@@ -44,11 +45,13 @@ static int omap4_pm_suspend(void)
/* Save current powerdomain state */
list_for_each_entry(pwrst, &pwrst_list, node) {
pwrst->saved_state = pwrdm_read_next_pwrst(pwrst->pwrdm);
+ pwrst->saved_logic_state = pwrdm_read_logic_retst(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);
+ pwrdm_set_logic_retst(pwrst->pwrdm, PWRDM_POWER_OFF);
}
/*
@@ -73,6 +76,7 @@ static int omap4_pm_suspend(void)
ret = -1;
}
omap_set_pwrdm_state(pwrst->pwrdm, pwrst->saved_state);
+ pwrdm_set_logic_retst(pwrst->pwrdm, pwrst->saved_logic_state);
}
if (ret)
pr_err("Could not enter target state in pm_suspend\n");
--
1.7.4.1
^ permalink raw reply related [flat|nested] 119+ messages in thread* [PATCH 21/25] OMAP4: PM: Add MPUSS power domain OSWR support
2011-09-04 13:54 ` [PATCH 21/25] OMAP4: PM: Add MPUSS power domain OSWR support Santosh Shilimkar
@ 2011-09-12 18:52 ` Kevin Hilman
2011-09-13 5:37 ` Santosh
0 siblings, 1 reply; 119+ messages in thread
From: Kevin Hilman @ 2011-09-12 18:52 UTC (permalink / raw)
To: linux-arm-kernel
Santosh Shilimkar <santosh.shilimkar@ti.com> writes:
> 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.shilimkar@ti.com>
> Cc: Kevin Hilman <khilman@ti.com>
Compile failure for the !CONFIG_PM case:
[...]
> @@ -70,11 +71,18 @@ static inline int omap4_mpuss_init(void)
> {
> return 0;
> }
> -
> +static inline u32 omap4_mpuss_read_prev_context_state(void)
> +{
> + return 0;
> +}
added here
> 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;
> +}
same thing added here
Kevin
^ permalink raw reply [flat|nested] 119+ messages in thread* [PATCH 21/25] OMAP4: PM: Add MPUSS power domain OSWR support
2011-09-12 18:52 ` Kevin Hilman
@ 2011-09-13 5:37 ` Santosh
2011-09-13 7:39 ` Jean Pihet
0 siblings, 1 reply; 119+ messages in thread
From: Santosh @ 2011-09-13 5:37 UTC (permalink / raw)
To: linux-arm-kernel
On Tuesday 13 September 2011 12:22 AM, Kevin Hilman wrote:
> Santosh Shilimkar<santosh.shilimkar@ti.com> writes:
>
>> 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.shilimkar@ti.com>
>> Cc: Kevin Hilman<khilman@ti.com>
>
> Compile failure for the !CONFIG_PM case:
>
> [...]
>
>> @@ -70,11 +71,18 @@ static inline int omap4_mpuss_init(void)
>> {
>> return 0;
>> }
>> -
>> +static inline u32 omap4_mpuss_read_prev_context_state(void)
>> +{
>> + return 0;
>> +}
>
> added here
>
>> 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;
>> +}
>
> same thing added here
>
I noticed this yesterday and was planning to send a note on this
patch. :(
Have removed this already in the updated patches.
Thanks for pointing it out.
Regards
Santosh
^ permalink raw reply [flat|nested] 119+ messages in thread* [PATCH 21/25] OMAP4: PM: Add MPUSS power domain OSWR support
2011-09-13 5:37 ` Santosh
@ 2011-09-13 7:39 ` Jean Pihet
2011-09-13 8:25 ` Santosh
0 siblings, 1 reply; 119+ messages in thread
From: Jean Pihet @ 2011-09-13 7:39 UTC (permalink / raw)
To: linux-arm-kernel
Hi Santosh,
On Tue, Sep 13, 2011 at 7:37 AM, Santosh <santosh.shilimkar@ti.com> wrote:
> On Tuesday 13 September 2011 12:22 AM, Kevin Hilman wrote:
>>
>> Santosh Shilimkar<santosh.shilimkar@ti.com> ?writes:
>>
>>> 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.shilimkar@ti.com>
>>> Cc: Kevin Hilman<khilman@ti.com>
>>
>> Compile failure for the !CONFIG_PM case:
>>
>> [...]
>>
>>> @@ -70,11 +71,18 @@ static inline int omap4_mpuss_init(void)
>>> ?{
>>> ? ? ? ?return 0;
>>> ?}
>>> -
>>> +static inline u32 omap4_mpuss_read_prev_context_state(void)
>>> +{
>>> + ? ? ? return 0;
>>> +}
>>
>> added here
>>
>>> ?static inline int omap4_finish_suspend(unsigned long cpu_state)
>>> ?{}
This one should return 0, as I already pointed out in the comments for [14/25].
Regards,
Jean
>>> ?static inline void omap4_cpu_resume(void)
>>> ?{}
>>> +static inline u32 omap4_mpuss_read_prev_context_state(void)
>>> +{
>>> + ? ? ? return 0;
>>> +}
>>
>> same thing added here
>>
> I noticed this yesterday and was planning to send a note on this
> patch. :(
> Have removed this already in the updated patches.
> Thanks for pointing it out.
>
> Regards
> Santosh
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at ?http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply [flat|nested] 119+ messages in thread* [PATCH 21/25] OMAP4: PM: Add MPUSS power domain OSWR support
2011-09-13 7:39 ` Jean Pihet
@ 2011-09-13 8:25 ` Santosh
0 siblings, 0 replies; 119+ messages in thread
From: Santosh @ 2011-09-13 8:25 UTC (permalink / raw)
To: linux-arm-kernel
On Tuesday 13 September 2011 01:09 PM, Jean Pihet wrote:
> Hi Santosh,
>
> On Tue, Sep 13, 2011 at 7:37 AM, Santosh<santosh.shilimkar@ti.com> wrote:
>> On Tuesday 13 September 2011 12:22 AM, Kevin Hilman wrote:
>>>
[..]
>>>
>>>> static inline int omap4_finish_suspend(unsigned long cpu_state)
>>>> {}
> This one should return 0, as I already pointed out in the comments for [14/25].
>
Taken care already.
Regards
Santosh
^ permalink raw reply [flat|nested] 119+ messages in thread
* [PATCH 22/25] OMAP4: PM: Add power domain statistics support
2011-09-04 13:54 [PATCH 00/25] OMAP4: PM: suspend, CPU-hotplug and CPUilde support Santosh Shilimkar
` (20 preceding siblings ...)
2011-09-04 13:54 ` [PATCH 21/25] OMAP4: PM: Add MPUSS power domain OSWR support Santosh Shilimkar
@ 2011-09-04 13:54 ` Santosh Shilimkar
2011-09-05 10:08 ` Sergei Shtylyov
2011-09-04 13:54 ` [PATCH 23/25] OMAP4: PM: Add CPUidle support Santosh Shilimkar
` (5 subsequent siblings)
27 siblings, 1 reply; 119+ messages in thread
From: Santosh Shilimkar @ 2011-09-04 13:54 UTC (permalink / raw)
To: linux-arm-kernel
Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
Cc: Kevin Hilman <khilman@ti.com>
---
arch/arm/mach-omap2/omap-mpuss-lowpower.c | 5 +++++
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/omap-mpuss-lowpower.c b/arch/arm/mach-omap2/omap-mpuss-lowpower.c
index 4dd9d0f..0bc7610 100644
--- a/arch/arm/mach-omap2/omap-mpuss-lowpower.c
+++ b/arch/arm/mach-omap2/omap-mpuss-lowpower.c
@@ -253,6 +253,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.
@@ -270,6 +272,7 @@ int omap4_enter_lowpower(unsigned int cpu, unsigned int power_state)
scu_pwrst_prepare(cpu, power_state);
l2x0_pwrst_prepare(cpu, save_state);
+
/*
* Call low level function with targeted CPU id
* and its low power state.
@@ -286,6 +289,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
^ permalink raw reply related [flat|nested] 119+ messages in thread* [PATCH 22/25] OMAP4: PM: Add power domain statistics support
2011-09-04 13:54 ` [PATCH 22/25] OMAP4: PM: Add power domain statistics support Santosh Shilimkar
@ 2011-09-05 10:08 ` Sergei Shtylyov
2011-09-05 10:43 ` Santosh
0 siblings, 1 reply; 119+ messages in thread
From: Sergei Shtylyov @ 2011-09-05 10:08 UTC (permalink / raw)
To: linux-arm-kernel
Hello.
On 04-09-2011 17:54, Santosh Shilimkar wrote:
> Signed-off-by: Santosh Shilimkar<santosh.shilimkar@ti.com>
> Cc: Kevin Hilman<khilman@ti.com>
> ---
> arch/arm/mach-omap2/omap-mpuss-lowpower.c | 5 +++++
> 1 files changed, 5 insertions(+), 0 deletions(-)
> diff --git a/arch/arm/mach-omap2/omap-mpuss-lowpower.c b/arch/arm/mach-omap2/omap-mpuss-lowpower.c
> index 4dd9d0f..0bc7610 100644
> --- a/arch/arm/mach-omap2/omap-mpuss-lowpower.c
> +++ b/arch/arm/mach-omap2/omap-mpuss-lowpower.c
[...]
> @@ -270,6 +272,7 @@ int omap4_enter_lowpower(unsigned int cpu, unsigned int power_state)
> scu_pwrst_prepare(cpu, power_state);
> l2x0_pwrst_prepare(cpu, save_state);
>
> +
Stray newline?
> /*
> * Call low level function with targeted CPU id
> * and its low power state.
WBR, Sergei
^ permalink raw reply [flat|nested] 119+ messages in thread* [PATCH 22/25] OMAP4: PM: Add power domain statistics support
2011-09-05 10:08 ` Sergei Shtylyov
@ 2011-09-05 10:43 ` Santosh
0 siblings, 0 replies; 119+ messages in thread
From: Santosh @ 2011-09-05 10:43 UTC (permalink / raw)
To: linux-arm-kernel
On Monday 05 September 2011 03:38 PM, Sergei Shtylyov wrote:
> Hello.
>
> On 04-09-2011 17:54, Santosh Shilimkar wrote:
>
>> Signed-off-by: Santosh Shilimkar<santosh.shilimkar@ti.com>
>> Cc: Kevin Hilman<khilman@ti.com>
>> ---
>> arch/arm/mach-omap2/omap-mpuss-lowpower.c | 5 +++++
>> 1 files changed, 5 insertions(+), 0 deletions(-)
>
>> diff --git a/arch/arm/mach-omap2/omap-mpuss-lowpower.c
>> b/arch/arm/mach-omap2/omap-mpuss-lowpower.c
>> index 4dd9d0f..0bc7610 100644
>> --- a/arch/arm/mach-omap2/omap-mpuss-lowpower.c
>> +++ b/arch/arm/mach-omap2/omap-mpuss-lowpower.c
> [...]
>> @@ -270,6 +272,7 @@ int omap4_enter_lowpower(unsigned int cpu,
>> unsigned int power_state)
>> scu_pwrst_prepare(cpu, power_state);
>> l2x0_pwrst_prepare(cpu, save_state);
>>
>> +
>
> Stray newline?
>
I noticed this later after scanning it on the list.
Will remove it.
Regards
Sntosh
^ permalink raw reply [flat|nested] 119+ messages in thread
* [PATCH 23/25] OMAP4: PM: Add CPUidle support
2011-09-04 13:54 [PATCH 00/25] OMAP4: PM: suspend, CPU-hotplug and CPUilde support Santosh Shilimkar
` (21 preceding siblings ...)
2011-09-04 13:54 ` [PATCH 22/25] OMAP4: PM: Add power domain statistics support Santosh Shilimkar
@ 2011-09-04 13:54 ` Santosh Shilimkar
2011-09-16 17:45 ` Kevin Hilman
2011-09-04 13:54 ` [PATCH 24/25] OMAP4: cpuidle: Switch to gptimer from twd in deeper C-states Santosh Shilimkar
` (4 subsequent siblings)
27 siblings, 1 reply; 119+ messages in thread
From: Santosh Shilimkar @ 2011-09-04 13:54 UTC (permalink / raw)
To: linux-arm-kernel
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-chalhoub@ti.com> for doing exhaustive
C-state latency profiling.
Signed-off-by: Rajendra Nayak <rnayak@ti.com>
Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
Cc: Kevin Hilman <khilman@ti.com>
---
arch/arm/mach-omap2/Makefile | 2 +-
arch/arm/mach-omap2/cpuidle44xx.c | 198 +++++++++++++++++++++++++++++++++++++
arch/arm/mach-omap2/pm.h | 1 +
arch/arm/mach-omap2/pm44xx.c | 2 +
4 files changed, 202 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 b4f2eeb..f603286 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -64,7 +64,7 @@ obj-$(CONFIG_ARCH_OMAP2) += sleep24xx.o
obj-$(CONFIG_ARCH_OMAP3) += pm34xx.o sleep34xx.o \
cpuidle34xx.o
obj-$(CONFIG_ARCH_OMAP4) += pm44xx.o sleep44xx.o \
- omap-mpuss-lowpower.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 0000000..c9c6f43
--- /dev/null
+++ b/arch/arm/mach-omap2/cpuidle44xx.c
@@ -0,0 +1,198 @@
+/*
+ * OMAP4 CPU idle Routines
+ *
+ * Copyright (C) 2011 Texas Instruments, Inc.
+ * Santosh Shilimkar <santosh.shilimkar@ti.com>
+ * Rajendra Nayak <rnayak@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();
+
+ /*
+ * Keep demoting CPU0 C-state till CPU1 hits 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.
+ */
+ cpu1_state = pwrdm_read_pwrst(cpu1_pd);
+ if (cpu1_state != PWRDM_POWER_OFF) {
+ dev->last_state = dev->safe_state;
+ cx = cpuidle_get_statedata(dev->safe_state);
+ }
+
+ /* Call idle CPU PM enter notifier chain */
+ if (cx->cpu_state == PWRDM_POWER_OFF)
+ cpu_pm_enter();
+
+ pwrdm_set_logic_retst(mpu_pd, cx->mpu_logic_state);
+ omap_set_pwrdm_state(mpu_pd, cx->mpu_state);
+
+ /* Call idle CPU cluster PM enter notifier chain */
+ if ((cx->mpu_state == PWRDM_POWER_RET) &&
+ (cx->mpu_logic_state == PWRDM_POWER_OFF))
+ cpu_cluster_pm_enter();
+
+ omap4_enter_lowpower(dev->cpu, cx->cpu_state);
+
+ /* Call idle CPU PM exit notifier chain */
+ if (pwrdm_read_prev_pwrst(cpu0_pd) == PWRDM_POWER_OFF)
+ cpu_pm_exit();
+
+ /* Call idle CPU cluster PM exit notifier chain */
+ if (omap4_mpuss_read_prev_context_state())
+ cpu_cluster_pm_exit();
+
+ getnstimeofday(&ts_postidle);
+ ts_idle = timespec_sub(ts_postidle, ts_preidle);
+
+ local_irq_enable();
+ local_fiq_enable();
+
+ return ts_idle.tv_nsec / NSEC_PER_USEC + ts_idle.tv_sec * USEC_PER_SEC;
+}
+
+DEFINE_PER_CPU(struct cpuidle_device, omap4_idle_dev);
+
+struct cpuidle_driver omap4_idle_driver = {
+ .name = "omap4_idle",
+ .owner = THIS_MODULE,
+};
+
+/* Fill in the state data from the mach tables and register the driver_data */
+static inline struct omap4_idle_statedata *_fill_cstate(
+ struct cpuidle_device *dev,
+ int idx, const char *descr)
+{
+ struct omap4_idle_statedata *cx = &omap4_idle_data[idx];
+ struct cpuidle_state *state = &dev->states[idx];
+
+ state->exit_latency = cpuidle_params_table[idx].exit_latency;
+ state->target_residency = cpuidle_params_table[idx].target_residency;
+ state->flags = CPUIDLE_FLAG_TIME_VALID;
+ state->enter = omap4_enter_idle;
+ cx->valid = cpuidle_params_table[idx].valid;
+ sprintf(state->name, "C%d", idx + 1);
+ strncpy(state->desc, descr, CPUIDLE_DESC_LEN);
+ cpuidle_set_statedata(state, cx);
+
+ return cx;
+}
+
+/**
+ * omap4_idle_init - Init routine for OMAP4 idle
+ *
+ * Registers the OMAP4 specific cpuidle driver to the cpuidle
+ * framework with the valid set of states.
+ */
+int __init omap4_idle_init(void)
+{
+ struct omap4_idle_statedata *cx;
+ struct cpuidle_device *dev;
+ unsigned int cpu_id = 0;
+
+ mpu_pd = pwrdm_lookup("mpu_pwrdm");
+ cpu0_pd = pwrdm_lookup("cpu0_pwrdm");
+ cpu1_pd = pwrdm_lookup("cpu1_pwrdm");
+ if ((!mpu_pd) || (!cpu0_pd) || (!cpu1_pd))
+ return -ENODEV;
+
+ cpuidle_register_driver(&omap4_idle_driver);
+
+ dev = &per_cpu(omap4_idle_dev, cpu_id);
+ dev->cpu = cpu_id;
+
+ /* C1 - CPU0 ON + CPU1 ON + MPU ON */
+ cx = _fill_cstate(dev, 0, "MPUSS ON");
+ dev->safe_state = &dev->states[0];
+ cx->valid = 1; /* C1 is always valid */
+ cx->cpu_state = PWRDM_POWER_ON;
+ cx->mpu_state = PWRDM_POWER_ON;
+ cx->mpu_logic_state = PWRDM_POWER_RET;
+
+ /* C2 - CPU0 OFF + CPU1 OFF + MPU CSWR */
+ cx = _fill_cstate(dev, 1, "MPUSS CSWR");
+ cx->cpu_state = PWRDM_POWER_OFF;
+ cx->mpu_state = PWRDM_POWER_RET;
+ cx->mpu_logic_state = PWRDM_POWER_RET;
+
+ /* C3 - CPU0 OFF + CPU1 OFF + MPU OSWR */
+ cx = _fill_cstate(dev, 2, "MPUSS OSWR");
+ cx->cpu_state = PWRDM_POWER_OFF;
+ cx->mpu_state = PWRDM_POWER_RET;
+ cx->mpu_logic_state = PWRDM_POWER_OFF;
+
+ dev->state_count = OMAP4_NUM_STATES;
+ if (cpuidle_register_device(dev)) {
+ pr_err("%s: CPUidle register device failed\n", __func__);
+ return -EIO;
+ }
+
+ return 0;
+}
+#else
+int __init omap4_idle_init(void)
+{
+ return 0;
+}
+#endif /* CONFIG_CPU_IDLE */
diff --git a/arch/arm/mach-omap2/pm.h b/arch/arm/mach-omap2/pm.h
index 4e166ad..b737b11 100644
--- a/arch/arm/mach-omap2/pm.h
+++ b/arch/arm/mach-omap2/pm.h
@@ -21,6 +21,7 @@ extern void omap_sram_idle(void);
extern int omap3_can_sleep(void);
extern int omap_set_pwrdm_state(struct powerdomain *pwrdm, u32 state);
extern int omap3_idle_init(void);
+extern int omap4_idle_init(void);
#if defined(CONFIG_PM_OPP)
extern int omap3_opp_init(void);
diff --git a/arch/arm/mach-omap2/pm44xx.c b/arch/arm/mach-omap2/pm44xx.c
index 8df57cb..a4ba474 100644
--- a/arch/arm/mach-omap2/pm44xx.c
+++ b/arch/arm/mach-omap2/pm44xx.c
@@ -258,6 +258,8 @@ static int __init omap4_pm_init(void)
/* Overwrite the default arch_idle() */
pm_idle = omap_default_idle;
+ omap4_idle_init();
+
err2:
return ret;
}
--
1.7.4.1
^ permalink raw reply related [flat|nested] 119+ messages in thread* [PATCH 23/25] OMAP4: PM: Add CPUidle support
2011-09-04 13:54 ` [PATCH 23/25] OMAP4: PM: Add CPUidle support Santosh Shilimkar
@ 2011-09-16 17:45 ` Kevin Hilman
2011-09-18 8:47 ` Santosh
0 siblings, 1 reply; 119+ messages in thread
From: Kevin Hilman @ 2011-09-16 17:45 UTC (permalink / raw)
To: linux-arm-kernel
Hi Santosh,
Santosh Shilimkar <santosh.shilimkar@ti.com> writes:
> 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-chalhoub@ti.com> for doing exhaustive
> C-state latency profiling.
>
> Signed-off-by: Rajendra Nayak <rnayak@ti.com>
> Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
> Cc: Kevin Hilman <khilman@ti.com>
A handful of minor comments below...
[...]
> +/**
> + * 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();
> +
> + /*
> + * Keep demoting CPU0 C-state till CPU1 hits OFF state.
IMO, the working here isn't as clear as it could be. IOW, I don't like
"keep demoting", which makes it sound iterative through a set of states,
where what's happening here is a one-time decision.
Rather, what I think you mean is "CPU0 has to stay on (e.g in C1) until
CPU1 is off."
> + * 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.
> + */
> + cpu1_state = pwrdm_read_pwrst(cpu1_pd);
> + if (cpu1_state != PWRDM_POWER_OFF) {
> + dev->last_state = dev->safe_state;
> + cx = cpuidle_get_statedata(dev->safe_state);
> + }
> +
> + /* Call idle CPU PM enter notifier chain */
This comment doesn't add any value over the code. If anything, a
comment explaining why it's only there for off-mode transitions would be
helpful.
> + if (cx->cpu_state == PWRDM_POWER_OFF)
> + cpu_pm_enter();
I think the CPU PM notifier usage should probably be a separate patch.
> + pwrdm_set_logic_retst(mpu_pd, cx->mpu_logic_state);
> + omap_set_pwrdm_state(mpu_pd, cx->mpu_state);
> +
> + /* Call idle CPU cluster PM enter notifier chain */
> + if ((cx->mpu_state == PWRDM_POWER_RET) &&
> + (cx->mpu_logic_state == PWRDM_POWER_OFF))
> + cpu_cluster_pm_enter();
> +
> + omap4_enter_lowpower(dev->cpu, cx->cpu_state);
> +
> + /* Call idle CPU PM exit notifier chain */
As above, this comment doesn't add any value over the code.
While I understand why it's only done for CPU0 here (CPU1 is managed by
hotplug), we should anticipating the moment where we will have forgotten
why it's only done for CPU0, and add a comment here.
> + if (pwrdm_read_prev_pwrst(cpu0_pd) == PWRDM_POWER_OFF)
> + cpu_pm_exit();
> +
> + /* Call idle CPU cluster PM exit notifier chain */
again, comment not helpful
> + if (omap4_mpuss_read_prev_context_state())
> + cpu_cluster_pm_exit();
> +
> + getnstimeofday(&ts_postidle);
> + ts_idle = timespec_sub(ts_postidle, ts_preidle);
> +
> + local_irq_enable();
> + local_fiq_enable();
> +
> + return ts_idle.tv_nsec / NSEC_PER_USEC + ts_idle.tv_sec * USEC_PER_SEC;
> +}
> +
> +DEFINE_PER_CPU(struct cpuidle_device, omap4_idle_dev);
> +
> +struct cpuidle_driver omap4_idle_driver = {
> + .name = "omap4_idle",
> + .owner = THIS_MODULE,
> +};
> +
> +/* Fill in the state data from the mach tables and register the driver_data */
if documented, it should have a kerneldoc header instead
> +static inline struct omap4_idle_statedata *_fill_cstate(
> + struct cpuidle_device *dev,
> + int idx, const char *descr)
> +{
> + struct omap4_idle_statedata *cx = &omap4_idle_data[idx];
> + struct cpuidle_state *state = &dev->states[idx];
> +
> + state->exit_latency = cpuidle_params_table[idx].exit_latency;
> + state->target_residency = cpuidle_params_table[idx].target_residency;
> + state->flags = CPUIDLE_FLAG_TIME_VALID;
> + state->enter = omap4_enter_idle;
> + cx->valid = cpuidle_params_table[idx].valid;
> + sprintf(state->name, "C%d", idx + 1);
> + strncpy(state->desc, descr, CPUIDLE_DESC_LEN);
> + cpuidle_set_statedata(state, cx);
> +
> + return cx;
> +}
Kevin
^ permalink raw reply [flat|nested] 119+ messages in thread* [PATCH 23/25] OMAP4: PM: Add CPUidle support
2011-09-16 17:45 ` Kevin Hilman
@ 2011-09-18 8:47 ` Santosh
0 siblings, 0 replies; 119+ messages in thread
From: Santosh @ 2011-09-18 8:47 UTC (permalink / raw)
To: linux-arm-kernel
On Friday 16 September 2011 11:15 PM, Kevin Hilman wrote:
> Hi Santosh,
>
> Santosh Shilimkar <santosh.shilimkar@ti.com> writes:
>
>> 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-chalhoub@ti.com> for doing exhaustive
>> C-state latency profiling.
>>
>> Signed-off-by: Rajendra Nayak <rnayak@ti.com>
>> Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
>> Cc: Kevin Hilman <khilman@ti.com>
>
> A handful of minor comments below...
>
Will take care of them.
Regards
Santosh
^ permalink raw reply [flat|nested] 119+ messages in thread
* [PATCH 24/25] OMAP4: cpuidle: Switch to gptimer from twd in deeper C-states.
2011-09-04 13:54 [PATCH 00/25] OMAP4: PM: suspend, CPU-hotplug and CPUilde support Santosh Shilimkar
` (22 preceding siblings ...)
2011-09-04 13:54 ` [PATCH 23/25] OMAP4: PM: Add CPUidle support Santosh Shilimkar
@ 2011-09-04 13:54 ` Santosh Shilimkar
2011-09-16 17:51 ` Kevin Hilman
2011-09-04 13:54 ` [PATCH 25/25] OMAP3: CPUidle: Make use of CPU PM notifiers Santosh Shilimkar
` (3 subsequent siblings)
27 siblings, 1 reply; 119+ messages in thread
From: Santosh Shilimkar @ 2011-09-04 13:54 UTC (permalink / raw)
To: linux-arm-kernel
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).
Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
Cc: Kevin Hilman <khilman@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 c9c6f43..e0140d6 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 */
if (cx->cpu_state == PWRDM_POWER_OFF)
cpu_pm_enter();
@@ -103,6 +108,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
^ permalink raw reply related [flat|nested] 119+ messages in thread* [PATCH 24/25] OMAP4: cpuidle: Switch to gptimer from twd in deeper C-states.
2011-09-04 13:54 ` [PATCH 24/25] OMAP4: cpuidle: Switch to gptimer from twd in deeper C-states Santosh Shilimkar
@ 2011-09-16 17:51 ` Kevin Hilman
2011-09-18 8:48 ` Santosh
0 siblings, 1 reply; 119+ messages in thread
From: Kevin Hilman @ 2011-09-16 17:51 UTC (permalink / raw)
To: linux-arm-kernel
Santosh Shilimkar <santosh.shilimkar@ti.com> writes:
> 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.
nit: this comment makes is sound like this patch adds the registration
of this timer, when all this patch does is add the notification.
Changelog should be updated to make it clear that the global timer exists
already, and is already marked with the C3STOP flag.
> Then notify the clock events layer from idle code using
> CLOCK_EVT_NOTIFY_BROADCAST_ENTER/EXIT).
>
> Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
> Cc: Kevin Hilman <khilman@ti.com>
Other than that
Acked-by: Kevin Hilman <khilman@ti.com>
^ permalink raw reply [flat|nested] 119+ messages in thread
* [PATCH 24/25] OMAP4: cpuidle: Switch to gptimer from twd in deeper C-states.
2011-09-16 17:51 ` Kevin Hilman
@ 2011-09-18 8:48 ` Santosh
0 siblings, 0 replies; 119+ messages in thread
From: Santosh @ 2011-09-18 8:48 UTC (permalink / raw)
To: linux-arm-kernel
On Friday 16 September 2011 11:21 PM, Kevin Hilman wrote:
> Santosh Shilimkar <santosh.shilimkar@ti.com> writes:
>
>> 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.
>
> nit: this comment makes is sound like this patch adds the registration
> of this timer, when all this patch does is add the notification.
>
> Changelog should be updated to make it clear that the global timer exists
> already, and is already marked with the C3STOP flag.
>
Will add couple of lines in the change log to make it clear.
>> Then notify the clock events layer from idle code using
>> CLOCK_EVT_NOTIFY_BROADCAST_ENTER/EXIT).
>>
>> Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
>> Cc: Kevin Hilman <khilman@ti.com>
>
> Other than that
>
> Acked-by: Kevin Hilman <khilman@ti.com>
>
Thanks.
Regards
Santosh
^ permalink raw reply [flat|nested] 119+ messages in thread
* [PATCH 25/25] OMAP3: CPUidle: Make use of CPU PM notifiers
2011-09-04 13:54 [PATCH 00/25] OMAP4: PM: suspend, CPU-hotplug and CPUilde support Santosh Shilimkar
` (23 preceding siblings ...)
2011-09-04 13:54 ` [PATCH 24/25] OMAP4: cpuidle: Switch to gptimer from twd in deeper C-states Santosh Shilimkar
@ 2011-09-04 13:54 ` Santosh Shilimkar
2011-09-08 17:57 ` Kevin Hilman
2011-09-08 20:15 ` [PATCH 00/25] OMAP4: PM: suspend, CPU-hotplug and CPUilde support Jean Pihet
` (2 subsequent siblings)
27 siblings, 1 reply; 119+ messages in thread
From: Santosh Shilimkar @ 2011-09-04 13:54 UTC (permalink / raw)
To: linux-arm-kernel
These notifiers can be used to isolate non-cpu specific PM
code from CPU idle code.
To start with, we can already leverage VFP handlers using notifier
chain for low power idle code. So use them.
Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
Cc: Kevin Hilman <khilman@ti.com>
---
arch/arm/mach-omap2/cpuidle34xx.c | 7 +++++++
1 files changed, 7 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/cpuidle34xx.c b/arch/arm/mach-omap2/cpuidle34xx.c
index 4bf6e6e..1112519 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,15 @@ static int omap3_enter_idle(struct cpuidle_device *dev,
pwrdm_for_each_clkdm(core_pd, _cpuidle_deny_idle);
}
+ if (mpu_state == PWRDM_POWER_OFF)
+ cpu_pm_enter();
+
/* Execute ARM wfi */
omap_sram_idle();
+ 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
^ permalink raw reply related [flat|nested] 119+ messages in thread* [PATCH 25/25] OMAP3: CPUidle: Make use of CPU PM notifiers
2011-09-04 13:54 ` [PATCH 25/25] OMAP3: CPUidle: Make use of CPU PM notifiers Santosh Shilimkar
@ 2011-09-08 17:57 ` Kevin Hilman
2011-09-09 4:20 ` Santosh
2011-09-09 7:17 ` Santosh
0 siblings, 2 replies; 119+ messages in thread
From: Kevin Hilman @ 2011-09-08 17:57 UTC (permalink / raw)
To: linux-arm-kernel
Hi Santosh,
Santosh Shilimkar <santosh.shilimkar@ti.com> writes:
> These notifiers can be used to isolate non-cpu specific PM
> code from CPU idle code.
>
> To start with, we can already leverage VFP handlers using notifier
> chain for low power idle code. So use them.
>
> Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
> Cc: Kevin Hilman <khilman@ti.com>
A comment below related to our other discussion in the CPU PM notifiers
thread...
> ---
> arch/arm/mach-omap2/cpuidle34xx.c | 7 +++++++
> 1 files changed, 7 insertions(+), 0 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/cpuidle34xx.c b/arch/arm/mach-omap2/cpuidle34xx.c
> index 4bf6e6e..1112519 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,15 @@ static int omap3_enter_idle(struct cpuidle_device *dev,
> pwrdm_for_each_clkdm(core_pd, _cpuidle_deny_idle);
> }
>
> + if (mpu_state == PWRDM_POWER_OFF)
> + cpu_pm_enter();
Making all CPU PM notifiers conditional on the MPU power state is not
right since upon an MPU transition, other domains might also transition.
What if there are notifiers for other drivers in other power domains
whose states might be transitioning? Notifiers for those devices should
be called no matter what the MPU's target state is.
Also triggering the notifiers here has the same problem that I mentioned
with the syscore PM ops. Namely, that next power states are not yet
determined, so any device notifier decisions based on that will be wrong.
The way I envision this working is (at least on OMAP) is CPU PM
notifiers are triggered only *after* the next power states are
determined and programmed. This allows the device-specific notifiers to
check their target power state and take appropriate action.
I've been testing the CPU PM notifiers with the patch below (after also
dropping [PATCH 2/5] from your the CPU PM notifiers series.) This patch works
for both suspend and idle by using the code common to them, and
triggering the event only after the target states are programmed.
I'm testing this patch now along with the 2nd patch below which removes
all the UART calls from the idle/suspend path and just adds a notifier
in the UART driver.
Will post these officially after a bit more testing, but so far it's
working on OMAP2420/n810 and OMAP3430/n900.
Kevin
^ permalink raw reply [flat|nested] 119+ messages in thread
* [PATCH 25/25] OMAP3: CPUidle: Make use of CPU PM notifiers
2011-09-08 17:57 ` Kevin Hilman
@ 2011-09-09 4:20 ` Santosh
2011-09-09 7:17 ` Santosh
1 sibling, 0 replies; 119+ messages in thread
From: Santosh @ 2011-09-09 4:20 UTC (permalink / raw)
To: linux-arm-kernel
On Thursday 08 September 2011 11:27 PM, Kevin Hilman wrote:
> Hi Santosh,
>
> Santosh Shilimkar<santosh.shilimkar@ti.com> writes:
>
>> These notifiers can be used to isolate non-cpu specific PM
>> code from CPU idle code.
>>
>> To start with, we can already leverage VFP handlers using notifier
>> chain for low power idle code. So use them.
>>
>> Signed-off-by: Santosh Shilimkar<santosh.shilimkar@ti.com>
>> Cc: Kevin Hilman<khilman@ti.com>
>
> A comment below related to our other discussion in the CPU PM notifiers
> thread...
>
After the discussion, this patch needs to be updated.
>> ---
>> arch/arm/mach-omap2/cpuidle34xx.c | 7 +++++++
>> 1 files changed, 7 insertions(+), 0 deletions(-)
>>
>> diff --git a/arch/arm/mach-omap2/cpuidle34xx.c b/arch/arm/mach-omap2/cpuidle34xx.c
>> index 4bf6e6e..1112519 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,15 @@ static int omap3_enter_idle(struct cpuidle_device *dev,
>> pwrdm_for_each_clkdm(core_pd, _cpuidle_deny_idle);
>> }
>>
>> + if (mpu_state == PWRDM_POWER_OFF)
>> + cpu_pm_enter();
>
> Making all CPU PM notifiers conditional on the MPU power state is not
> right since upon an MPU transition, other domains might also transition.
>
> What if there are notifiers for other drivers in other power domains
> whose states might be transitioning? Notifiers for those devices should
> be called no matter what the MPU's target state is.
>
> Also triggering the notifiers here has the same problem that I mentioned
> with the syscore PM ops. Namely, that next power states are not yet
> determined, so any device notifier decisions based on that will be wrong.
>
> The way I envision this working is (at least on OMAP) is CPU PM
> notifiers are triggered only *after* the next power states are
> determined and programmed. This allows the device-specific notifiers to
> check their target power state and take appropriate action.
>
> I've been testing the CPU PM notifiers with the patch below (after also
> dropping [PATCH 2/5] from your the CPU PM notifiers series.) This patch works
> for both suspend and idle by using the code common to them, and
> triggering the event only after the target states are programmed.
>
> I'm testing this patch now along with the 2nd patch below which removes
> all the UART calls from the idle/suspend path and just adds a notifier
> in the UART driver.
>
> Will post these officially after a bit more testing, but so far it's
> working on OMAP2420/n810 and OMAP3430/n900.
>
Agree. I will drop my patch in favour of below patch.
Regards
Santosh
^ permalink raw reply [flat|nested] 119+ messages in thread
* [PATCH 25/25] OMAP3: CPUidle: Make use of CPU PM notifiers
2011-09-08 17:57 ` Kevin Hilman
2011-09-09 4:20 ` Santosh
@ 2011-09-09 7:17 ` Santosh
1 sibling, 0 replies; 119+ messages in thread
From: Santosh @ 2011-09-09 7:17 UTC (permalink / raw)
To: linux-arm-kernel
On Thursday 08 September 2011 11:27 PM, Kevin Hilman wrote:
> From 8ad40f8c7f950105b25cc8d2cc35caa50871f86f Mon Sep 17 00:00:00 2001
> From: Kevin Hilman<khilman@ti.com>
> Date: Wed, 7 Sep 2011 12:04:44 -0700
> Subject: [PATCH 1/2] OMAP2/3: PM: trigger CPU PM notifiers in idle and
> suspend path
>
> Add calls to CPU PM notifier core in the idle and suspend paths
> so any CPU PM notifiers are properly called.
>
> [add more description about the need to trigger notifiers only after
> next power states are programmed.]
>
> Signed-off-by: Kevin Hilman<khilman@ti.com>
> ---
> arch/arm/mach-omap2/pm24xx.c | 5 +++++
> arch/arm/mach-omap2/pm34xx.c | 5 +++++
> 2 files changed, 10 insertions(+), 0 deletions(-)
>
[...]
> diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
> index 7255d9b..b167c7f 100644
> --- a/arch/arm/mach-omap2/pm34xx.c
> +++ b/arch/arm/mach-omap2/pm34xx.c
> @@ -29,6 +29,7 @@
> #include<linux/delay.h>
> #include<linux/slab.h>
> #include<linux/console.h>
> +#include<linux/cpu_pm.h>
> #include<trace/events/power.h>
>
> #include<asm/suspend.h>
> @@ -386,6 +387,8 @@ void omap_sram_idle(void)
> if (!console_trylock())
> goto console_still_active;
>
> + cpu_pm_enter();
> +
I don't think you should blindly call CPU_PM notifiers.
This should called if the MPU targeted state is OFF.
With blind notifiers, CPU context like VFP or GIC or L2
will be saved and restored even if CPU/CPU cluster is
not entering into low power. This is highly un-optimal for
CPUIDLE and defeats the purpose of adding different
CPU PM events.
Looking at your UART driver notfier usage, you might need
add new events instead of using the CPU and CPU cluster
events.
Even though on OMAP UART is idles as part of CPU, it's still
an independent PD.
E.g just to make a point,
MPU is programmed to INACTIVE and let say PER PD is programmed
to OFF.
From MPU point of view the CPU_PM notifier change need not be called
because, it's doesn't loose any context, but UART notifier needs to
be executed since UART context must be saved.
Regards
Santosh
^ permalink raw reply [flat|nested] 119+ messages in thread
* [PATCH 00/25] OMAP4: PM: suspend, CPU-hotplug and CPUilde support
2011-09-04 13:54 [PATCH 00/25] OMAP4: PM: suspend, CPU-hotplug and CPUilde support Santosh Shilimkar
` (24 preceding siblings ...)
2011-09-04 13:54 ` [PATCH 25/25] OMAP3: CPUidle: Make use of CPU PM notifiers Santosh Shilimkar
@ 2011-09-08 20:15 ` Jean Pihet
2011-09-09 4:25 ` Santosh
2011-09-20 11:24 ` Vishwanath Sripathy
2011-09-20 11:57 ` Santosh
27 siblings, 1 reply; 119+ messages in thread
From: Jean Pihet @ 2011-09-08 20:15 UTC (permalink / raw)
To: linux-arm-kernel
Hi Santosh,
On Sun, Sep 4, 2011 at 3:54 PM, Santosh Shilimkar
<santosh.shilimkar@ti.com> wrote:
> This series adds OMAP4 MPUSS (MPU SubSystem) power management support for
> suspend (S2R), CPU hotplug and CPUidle.
>
> Most of these patches have been posted and reviewed earlier [1] on the list
> and have missed last couple of merge windows because of dependencies.
> New set of patches have diverged more and hence the series version
> continuity isn't maintained.
>
> Below are the main updates from previous versions.
> - Use of generic ARM suspend hooks instead of OMAP custom code.
> - Making use of common GIC code instead of OMAP custom code.
> - Use of generic CPU PM notifiers for CPUIDLE and suspend.
> - Use of CPU PM notifiers and hotplug notifiers for GIC extension.
> - PM support of OMAP4 HS devices.
> - Introduction of interconnect barriers as per the OMAP4 requirements.
>
> Special thanks to,
> - Kevin Hilman for the detailed reviews.
> - Russell for adding the L2 cache handling support to generic suspend.
> - Colin Cross for the generic CPU PM notifier patches.
> - Rajendra Nayak and Paul Walmsley for clock-domain sequencing series.
>
> Below series has dependency on Russell's L2 generic suspend support [2]
> and earlier posted CPU PM notifiers series [3].
> An integrated branch with these dependencies can be found here [4].
>
> The series is tested on OMAP4430 SDP for suspend, hotplug and CPUidle
> with OMAP4 GP and HS (secure) devices.
>
> 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-omap4-mpuss-pm
Some comments have been sent on this patch set, otherwise OK after review.
FWIW:
Acked-by: Jean Pihet <j-pihet@ti.com>
Regards,
Jean
>
> Santosh Shilimkar (25):
> ? ? ?ARM: mm: Add strongly ordered descriptor support.
> ? ? ?OMAP4: Redefine mandatory barriers for OMAP to include interconnect barriers.
> ? ? ?OMAP4: PM: Use custom omap_do_wfi() for suspend and default idle.
> ? ? ?OMAP4: Remove un-used do_wfi() macro.
> ? ? ?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 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: 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: suspend: Add MPUSS power domain RETENTION support
> ? ? ?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
>
> ?arch/arm/include/asm/mach/map.h ? ? ? ? ? ? ? ? ? ?| ? ?1 +
> ?arch/arm/include/asm/pgtable.h ? ? ? ? ? ? ? ? ? ? | ? ?3 +
> ?arch/arm/mach-omap2/Kconfig ? ? ? ? ? ? ? ? ? ? ? ?| ? ?1 +
> ?arch/arm/mach-omap2/Makefile ? ? ? ? ? ? ? ? ? ? ? | ? 15 +-
> ?arch/arm/mach-omap2/cpuidle34xx.c ? ? ? ? ? ? ? ? ?| ? ?7 +
> ?arch/arm/mach-omap2/cpuidle44xx.c ? ? ? ? ? ? ? ? ?| ?206 ++++++++++
> ?arch/arm/mach-omap2/include/mach/barriers.h ? ? ? ?| ? 48 +++
> ?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 ? ?| ? 70 +++-
> ?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 ? ? ? ? ? ? ? ? ? ? | ? 38 ++
> ?arch/arm/mach-omap2/omap-wakeupgen.c ? ? ? ? ? ? ? | ?403 ++++++++++++++++++++
> ?arch/arm/mach-omap2/omap4-common.c ? ? ? ? ? ? ? ? | ? 93 +++++-
> ?arch/arm/mach-omap2/omap4-sar-layout.h ? ? ? ? ? ? | ? 50 +++
> ?arch/arm/mach-omap2/pm.h ? ? ? ? ? ? ? ? ? ? ? ? ? | ? ?1 +
> ?arch/arm/mach-omap2/pm44xx.c ? ? ? ? ? ? ? ? ? ? ? | ?155 ++++++++-
> ?arch/arm/mach-omap2/sleep44xx.S ? ? ? ? ? ? ? ? ? ?| ?385 +++++++++++++++++++
> ?arch/arm/mm/mmu.c ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?| ? ?8 +
> ?arch/arm/plat-omap/common.c ? ? ? ? ? ? ? ? ? ? ? ?| ? ?3 +
> ?arch/arm/plat-omap/include/plat/omap44xx.h ? ? ? ? | ? ?1 +
> ?arch/arm/plat-omap/include/plat/sram.h ? ? ? ? ? ? | ? ?1 +
> ?arch/arm/plat-omap/sram.c ? ? ? ? ? ? ? ? ? ? ? ? ?| ? 47 ++-
> ?27 files changed, 2104 insertions(+), 49 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] http://www.mail-archive.com/linux-omap at vger.kernel.org/msg47511.html
>
> [2] http://www.spinics.net/lists/arm-kernel/msg138803.html
>
> [3] https://lkml.org/lkml/2011/9/3/49
>
> [4] https://gitorious.org/omap-sw-develoment/linux-omap-dev/commits/v3.1-rc4-omap4-pm-integrated
> --
> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at ?http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply [flat|nested] 119+ messages in thread* [PATCH 00/25] OMAP4: PM: suspend, CPU-hotplug and CPUilde support
2011-09-08 20:15 ` [PATCH 00/25] OMAP4: PM: suspend, CPU-hotplug and CPUilde support Jean Pihet
@ 2011-09-09 4:25 ` Santosh
0 siblings, 0 replies; 119+ messages in thread
From: Santosh @ 2011-09-09 4:25 UTC (permalink / raw)
To: linux-arm-kernel
On Friday 09 September 2011 01:45 AM, Jean Pihet wrote:
> Hi Santosh,
>
> On Sun, Sep 4, 2011 at 3:54 PM, Santosh Shilimkar
> <santosh.shilimkar@ti.com> wrote:
>> This series adds OMAP4 MPUSS (MPU SubSystem) power management support for
>> suspend (S2R), CPU hotplug and CPUidle.
>>
>> Most of these patches have been posted and reviewed earlier [1] on the list
>> and have missed last couple of merge windows because of dependencies.
>> New set of patches have diverged more and hence the series version
>> continuity isn't maintained.
>>
>> Below are the main updates from previous versions.
>> - Use of generic ARM suspend hooks instead of OMAP custom code.
>> - Making use of common GIC code instead of OMAP custom code.
>> - Use of generic CPU PM notifiers for CPUIDLE and suspend.
>> - Use of CPU PM notifiers and hotplug notifiers for GIC extension.
>> - PM support of OMAP4 HS devices.
>> - Introduction of interconnect barriers as per the OMAP4 requirements.
>>
>> Special thanks to,
>> - Kevin Hilman for the detailed reviews.
>> - Russell for adding the L2 cache handling support to generic suspend.
>> - Colin Cross for the generic CPU PM notifier patches.
>> - Rajendra Nayak and Paul Walmsley for clock-domain sequencing series.
>>
>> Below series has dependency on Russell's L2 generic suspend support [2]
>> and earlier posted CPU PM notifiers series [3].
>> An integrated branch with these dependencies can be found here [4].
>>
>> The series is tested on OMAP4430 SDP for suspend, hotplug and CPUidle
>> with OMAP4 GP and HS (secure) devices.
>>
>> 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-omap4-mpuss-pm
>
> Some comments have been sent on this patch set, otherwise OK after review.
>
> FWIW:
> Acked-by: Jean Pihet<j-pihet@ti.com>
>
Thanks
Regards
Santosh
^ permalink raw reply [flat|nested] 119+ messages in thread
* [PATCH 00/25] OMAP4: PM: suspend, CPU-hotplug and CPUilde support
2011-09-04 13:54 [PATCH 00/25] OMAP4: PM: suspend, CPU-hotplug and CPUilde support Santosh Shilimkar
` (25 preceding siblings ...)
2011-09-08 20:15 ` [PATCH 00/25] OMAP4: PM: suspend, CPU-hotplug and CPUilde support Jean Pihet
@ 2011-09-20 11:24 ` Vishwanath Sripathy
2011-09-20 11:37 ` Santosh
2011-09-20 11:57 ` Santosh
27 siblings, 1 reply; 119+ messages in thread
From: Vishwanath Sripathy @ 2011-09-20 11:24 UTC (permalink / raw)
To: linux-arm-kernel
> -----Original Message-----
> From: linux-arm-kernel-bounces at lists.infradead.org [mailto:linux-
> arm-kernel-bounces at lists.infradead.org] On Behalf Of Santosh
> Shilimkar
> Sent: Sunday, September 04, 2011 7:24 PM
> To: linux-omap at vger.kernel.org
> Cc: khilman at ti.com; Santosh Shilimkar; rnayak at ti.com;
> linux at arm.linux.org.uk; linux-arm-kernel at lists.infradead.org
> Subject: [PATCH 00/25] OMAP4: PM: suspend, CPU-hotplug and CPUilde
> support
>
> This series adds OMAP4 MPUSS (MPU SubSystem) power management
> support for
> suspend (S2R), CPU hotplug and CPUidle.
>
> Most of these patches have been posted and reviewed earlier [1] on
> the list
> and have missed last couple of merge windows because of dependencies.
> New set of patches have diverged more and hence the series version
> continuity isn't maintained.
>
> Below are the main updates from previous versions.
> - Use of generic ARM suspend hooks instead of OMAP custom code.
> - Making use of common GIC code instead of OMAP custom code.
> - Use of generic CPU PM notifiers for CPUIDLE and suspend.
> - Use of CPU PM notifiers and hotplug notifiers for GIC extension.
> - PM support of OMAP4 HS devices.
> - Introduction of interconnect barriers as per the OMAP4
> requirements.
>
> Special thanks to,
> - Kevin Hilman for the detailed reviews.
> - Russell for adding the L2 cache handling support to generic
> suspend.
> - Colin Cross for the generic CPU PM notifier patches.
> - Rajendra Nayak and Paul Walmsley for clock-domain sequencing
> series.
>
> Below series has dependency on Russell's L2 generic suspend support
> [2]
> and earlier posted CPU PM notifiers series [3].
> An integrated branch with these dependencies can be found here [4].
>
> The series is tested on OMAP4430 SDP for suspend, hotplug and
> CPUidle
> with OMAP4 GP and HS (secure) devices.
>
> 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-omap4-mpuss-pm
I have tested these patch series after adding core retention support (In
suspend/resume path)[1] and it worked Fine. I do see that Core and MPU are
entering CSWR upon suspend and able to wake up via uart.
You could add tested-by: Vishwanath BS < Vishwanath.bs@ti.com> if you
want.
[1]: git://gitorious.org/omap-pm/linux.git omap4_core_pm
Regards
Vishwa
>
> Santosh Shilimkar (25):
> ARM: mm: Add strongly ordered descriptor support.
> OMAP4: Redefine mandatory barriers for OMAP to include
> interconnect barriers.
> OMAP4: PM: Use custom omap_do_wfi() for suspend and default
> idle.
> OMAP4: Remove un-used do_wfi() macro.
> 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 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: 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: suspend: Add MPUSS power domain RETENTION support
> 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
>
> arch/arm/include/asm/mach/map.h | 1 +
> arch/arm/include/asm/pgtable.h | 3 +
> arch/arm/mach-omap2/Kconfig | 1 +
> arch/arm/mach-omap2/Makefile | 15 +-
> arch/arm/mach-omap2/cpuidle34xx.c | 7 +
> arch/arm/mach-omap2/cpuidle44xx.c | 206
> ++++++++++
> arch/arm/mach-omap2/include/mach/barriers.h | 48 +++
> 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 | 70 +++-
> 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 | 38 ++
> arch/arm/mach-omap2/omap-wakeupgen.c | 403
> ++++++++++++++++++++
> arch/arm/mach-omap2/omap4-common.c | 93 +++++-
> arch/arm/mach-omap2/omap4-sar-layout.h | 50 +++
> arch/arm/mach-omap2/pm.h | 1 +
> arch/arm/mach-omap2/pm44xx.c | 155 ++++++++-
> arch/arm/mach-omap2/sleep44xx.S | 385
> +++++++++++++++++++
> arch/arm/mm/mmu.c | 8 +
> arch/arm/plat-omap/common.c | 3 +
> arch/arm/plat-omap/include/plat/omap44xx.h | 1 +
> arch/arm/plat-omap/include/plat/sram.h | 1 +
> arch/arm/plat-omap/sram.c | 47 ++-
> 27 files changed, 2104 insertions(+), 49 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] http://www.mail-archive.com/linux-
> omap at vger.kernel.org/msg47511.html
>
> [2] http://www.spinics.net/lists/arm-kernel/msg138803.html
>
> [3] https://lkml.org/lkml/2011/9/3/49
>
> [4] https://gitorious.org/omap-sw-develoment/linux-omap-
> dev/commits/v3.1-rc4-omap4-pm-integrated
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 119+ messages in thread* [PATCH 00/25] OMAP4: PM: suspend, CPU-hotplug and CPUilde support
2011-09-20 11:24 ` Vishwanath Sripathy
@ 2011-09-20 11:37 ` Santosh
0 siblings, 0 replies; 119+ messages in thread
From: Santosh @ 2011-09-20 11:37 UTC (permalink / raw)
To: linux-arm-kernel
On Tuesday 20 September 2011 04:54 PM, Vishwanath Sripathy wrote:
>> -----Original Message-----
>> From: linux-arm-kernel-bounces at lists.infradead.org [mailto:linux-
>> arm-kernel-bounces at lists.infradead.org] On Behalf Of Santosh
>> Shilimkar
>> Sent: Sunday, September 04, 2011 7:24 PM
>> To: linux-omap at vger.kernel.org
>> Cc: khilman at ti.com; Santosh Shilimkar; rnayak at ti.com;
>> linux at arm.linux.org.uk; linux-arm-kernel at lists.infradead.org
>> Subject: [PATCH 00/25] OMAP4: PM: suspend, CPU-hotplug and CPUilde
>> support
>>
[...]
>> The series is tested on OMAP4430 SDP for suspend, hotplug and
>> CPUidle
>> with OMAP4 GP and HS (secure) devices.
>>
>> 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-omap4-mpuss-pm
> I have tested these patch series after adding core retention support (In
> suspend/resume path)[1] and it worked Fine. I do see that Core and MPU are
> entering CSWR upon suspend and able to wake up via uart.
>
> You could add tested-by: Vishwanath BS < Vishwanath.bs@ti.com> if you
> want.
>
Yes I want tested-by and will add your tested-by on the series.
Thanks for testing
Regards
Santosh
^ permalink raw reply [flat|nested] 119+ messages in thread
* [PATCH 00/25] OMAP4: PM: suspend, CPU-hotplug and CPUilde support
2011-09-04 13:54 [PATCH 00/25] OMAP4: PM: suspend, CPU-hotplug and CPUilde support Santosh Shilimkar
` (26 preceding siblings ...)
2011-09-20 11:24 ` Vishwanath Sripathy
@ 2011-09-20 11:57 ` Santosh
27 siblings, 0 replies; 119+ messages in thread
From: Santosh @ 2011-09-20 11:57 UTC (permalink / raw)
To: linux-arm-kernel
On Sunday 04 September 2011 07:24 PM, Santosh Shilimkar wrote:
> This series adds OMAP4 MPUSS (MPU SubSystem) power management support for
> suspend (S2R), CPU hotplug and CPUidle.
>
Thanks all for your review's and testing of this series. Have addressed
all the concerns/comments as part of the next post which I am holding
for couple of days more.
Reason is mainly to ensure that dependent patches(series) are merged or
on the way for 3.2, and the patches are re-based against the
right tree for the merge.
As documented earlier, there are 3 dependencies for this series.
1) Russell's L2 cache update to generic suspend which seems to be
be ready now since Lorenzo confirmed that pending issue is fixed.
http://www.spinics.net/lists/linux-omap/msg57625.html
2) CPU PM notifier series for which I have pull request ready
to be send.
https://lkml.org/lkml/2011/9/3/49
3) IRQ subystem patch which is already in Thomas's irq/core for 3.2
http://www.mail-archive.com/linux-omap at vger.kernel.org/msg55483.html
Regards
Santosh
^ permalink raw reply [flat|nested] 119+ messages in thread