From: Santosh Shilimkar <santosh.shilimkar@ti.com>
To: Bryan Wu <bryan.wu@canonical.com>, Sebastien Jan <s-jan@ti.com>
Cc: Paul Walmsley <paul@pwsan.com>,
linux-omap@vger.kernel.org,
Ricardo Salveti de Araujo <ricardo.salveti@canonical.com>
Subject: RE: Passing mem=1G to kernel on Panda, system is unstable.
Date: Sat, 15 Jan 2011 00:25:08 +0530 [thread overview]
Message-ID: <85fb20a5e00e0a3e5b0abbd56574e36f@mail.gmail.com> (raw)
In-Reply-To: <AANLkTime0otkEhqwFBS4k_aYiU7a8hnbhYQsfE=GBHdr@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1073 bytes --]
> -----Original Message-----
> From: cooloney@gmail.com [mailto:cooloney@gmail.com] On Behalf Of
> Bryan Wu
> Sent: Saturday, January 15, 2011 12:11 AM
> To: Jan, Sebastien; Santosh Shilimkar
> Cc: Paul Walmsley; linux-omap@vger.kernel.org; Ricardo Salveti de
> Araujo
> Subject: Re: Passing mem=1G to kernel on Panda, system is unstable.
>
> On Sat, Jan 15, 2011 at 1:48 AM, Jan, Sebastien <s-jan@ti.com>
> wrote:
> > Hi Santosh,
> >
> > On Fri, Jan 14, 2011 at 6:22 PM, Santosh Shilimkar
> > <santosh.shilimkar@ti.com> wrote:
> >>>
> >>> I just tested with the 2.6.37 mainline kernel and Bryan config,
> and
> >>> can reproduce the issue with CONFIG_SMP disabled.
> >> Can you try the patch I sent on the list as well ?
> >
>
> Unfortunately, I still can reproduce this issue with mainline 2.6.37
> kernel + the patch here:
I see.
Since it's undefined async abort.... Mostly some clock/module race.
I have one more experimental debug patch if you would like to
try out.
This patch just configures the interconnect space to SO instead of
device memory.
Regards,
Santosh
[-- Attachment #2: 0001-OMAP3-4-Diable-IO-posting.patch --]
[-- Type: application/octet-stream, Size: 7118 bytes --]
From b9166a203741800c1e5c30c7455d90f7d36fb4fc Mon Sep 17 00:00:00 2001
From: Santosh Shilimkar <santosh.shilimkar@ti.com>
Date: Sat, 7 Aug 2010 14:10:14 +0530
Subject: [PATCH] OMAP3/4: Diable IO posting
Selectable posting control for internal device registers
To enable IO posting select CONFIG_INTERCONNECT_IO_POSTING
Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
Signed-off-by: Richard Woodruff <r-woodruff2@ti.com>
---
arch/arm/include/asm/mach/map.h | 2 ++
arch/arm/mach-omap2/Kconfig | 11 +++++++++++
arch/arm/mach-omap2/io.c | 31 ++++++++++++++++---------------
arch/arm/mm/mmu.c | 10 ++++++++++
arch/arm/plat-omap/include/plat/io.h | 23 +++++++++++++++++++++++
5 files changed, 62 insertions(+), 15 deletions(-)
diff --git a/arch/arm/include/asm/mach/map.h b/arch/arm/include/asm/mach/map.h
index d2fedb5..c9fcb79 100644
--- a/arch/arm/include/asm/mach/map.h
+++ b/arch/arm/include/asm/mach/map.h
@@ -29,6 +29,8 @@ struct map_desc {
#define MT_MEMORY_NONCACHED 11
#define MT_MEMORY_DTCM 12
#define MT_MEMORY_ITCM 13
+#define MT_MEMORY_SO 14
+#define MT_MEMORY_SO_EXE 15
#ifdef CONFIG_MMU
extern void iotable_init(struct map_desc *, int);
diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
index 1a2cf62..44fb785 100644
--- a/arch/arm/mach-omap2/Kconfig
+++ b/arch/arm/mach-omap2/Kconfig
@@ -50,6 +50,17 @@ config ARCH_OMAP4
select PM_OPP if PM
select USB_ARCH_HAS_EHCI
+config INTERCONNECT_IO_POSTING
+ bool "Enable bus posting for PIO accesses"
+ depends on ARCH_OMAP34XX || ARCH_OMAP4
+ default n
+ ---help---
+ This option sets PIO access for internal OMAP3 registers to follow the
+ ARMv7 DEVICE attribute. For 3430 this will allow posted writes in the
+ interconnect. Software will need to synchronize writes to ensure
+ completion. When not set the attribute is Strongly Ordered which is
+ non-posted on the OMAP3 interconnect.
+
comment "OMAP Core Type"
depends on ARCH_OMAP2
diff --git a/arch/arm/mach-omap2/io.c b/arch/arm/mach-omap2/io.c
index e66687b..c7eb79b 100644
--- a/arch/arm/mach-omap2/io.c
+++ b/arch/arm/mach-omap2/io.c
@@ -126,43 +126,43 @@ static struct map_desc omap34xx_io_desc[] __initdata = {
.virtual = L3_34XX_VIRT,
.pfn = __phys_to_pfn(L3_34XX_PHYS),
.length = L3_34XX_SIZE,
- .type = MT_DEVICE
+ .type = IO_MAP_TYPE
},
{
.virtual = L4_34XX_VIRT,
.pfn = __phys_to_pfn(L4_34XX_PHYS),
.length = L4_34XX_SIZE,
- .type = MT_DEVICE
+ .type = IO_MAP_TYPE
},
{
.virtual = OMAP34XX_GPMC_VIRT,
.pfn = __phys_to_pfn(OMAP34XX_GPMC_PHYS),
.length = OMAP34XX_GPMC_SIZE,
- .type = MT_DEVICE
+ .type = IO_MAP_TYPE
},
{
.virtual = OMAP343X_SMS_VIRT,
.pfn = __phys_to_pfn(OMAP343X_SMS_PHYS),
.length = OMAP343X_SMS_SIZE,
- .type = MT_DEVICE
+ .type = IO_MAP_TYPE
},
{
.virtual = OMAP343X_SDRC_VIRT,
.pfn = __phys_to_pfn(OMAP343X_SDRC_PHYS),
.length = OMAP343X_SDRC_SIZE,
- .type = MT_DEVICE
+ .type = IO_MAP_TYPE
},
{
.virtual = L4_PER_34XX_VIRT,
.pfn = __phys_to_pfn(L4_PER_34XX_PHYS),
.length = L4_PER_34XX_SIZE,
- .type = MT_DEVICE
+ .type = IO_MAP_TYPE
},
{
.virtual = L4_EMU_34XX_VIRT,
.pfn = __phys_to_pfn(L4_EMU_34XX_PHYS),
.length = L4_EMU_34XX_SIZE,
- .type = MT_DEVICE
+ .type = IO_MAP_TYPE
},
#if defined(CONFIG_DEBUG_LL) && \
(defined(CONFIG_MACH_OMAP_ZOOM2) || defined(CONFIG_MACH_OMAP_ZOOM3))
@@ -170,7 +170,7 @@ static struct map_desc omap34xx_io_desc[] __initdata = {
.virtual = ZOOM_UART_VIRT,
.pfn = __phys_to_pfn(ZOOM_UART_BASE),
.length = SZ_1M,
- .type = MT_DEVICE
+ .type = IO_MAP_TYPE
},
#endif
};
@@ -181,49 +181,50 @@ static struct map_desc omap44xx_io_desc[] __initdata = {
.virtual = L3_44XX_VIRT,
.pfn = __phys_to_pfn(L3_44XX_PHYS),
.length = L3_44XX_SIZE,
- .type = MT_DEVICE,
+ .type = IO_MAP_TYPE
},
{
.virtual = L4_44XX_VIRT,
.pfn = __phys_to_pfn(L4_44XX_PHYS),
.length = L4_44XX_SIZE,
- .type = MT_DEVICE,
+ .type = IO_MAP_TYPE
},
{
.virtual = OMAP44XX_GPMC_VIRT,
.pfn = __phys_to_pfn(OMAP44XX_GPMC_PHYS),
.length = OMAP44XX_GPMC_SIZE,
.type = MT_DEVICE,
+ .type = IO_MAP_TYPE
},
{
.virtual = OMAP44XX_EMIF1_VIRT,
.pfn = __phys_to_pfn(OMAP44XX_EMIF1_PHYS),
.length = OMAP44XX_EMIF1_SIZE,
- .type = MT_DEVICE,
+ .type = IO_MAP_TYPE
},
{
.virtual = OMAP44XX_EMIF2_VIRT,
.pfn = __phys_to_pfn(OMAP44XX_EMIF2_PHYS),
.length = OMAP44XX_EMIF2_SIZE,
- .type = MT_DEVICE,
+ .type = IO_MAP_TYPE
},
{
.virtual = OMAP44XX_DMM_VIRT,
.pfn = __phys_to_pfn(OMAP44XX_DMM_PHYS),
.length = OMAP44XX_DMM_SIZE,
- .type = MT_DEVICE,
+ .type = IO_MAP_TYPE
},
{
.virtual = L4_PER_44XX_VIRT,
.pfn = __phys_to_pfn(L4_PER_44XX_PHYS),
.length = L4_PER_44XX_SIZE,
- .type = MT_DEVICE,
+ .type = IO_MAP_TYPE
},
{
.virtual = L4_EMU_44XX_VIRT,
.pfn = __phys_to_pfn(L4_EMU_44XX_PHYS),
.length = L4_EMU_44XX_SIZE,
- .type = MT_DEVICE,
+ .type = IO_MAP_TYPE
},
};
#endif
diff --git a/arch/arm/mm/mmu.c b/arch/arm/mm/mmu.c
index 3c67e92..4e9f8d3 100644
--- a/arch/arm/mm/mmu.c
+++ b/arch/arm/mm/mmu.c
@@ -275,6 +275,16 @@ static struct mem_type mem_types[] = {
.prot_l1 = PMD_TYPE_TABLE,
.domain = DOMAIN_KERNEL,
},
+ [MT_MEMORY_SO] = {
+ .prot_sect = PMD_TYPE_SECT | PMD_SECT_AP_WRITE |
+ PMD_SECT_UNCACHED | PMD_SECT_XN,
+ .domain = DOMAIN_KERNEL,
+ },
+ [MT_MEMORY_SO_EXE] = {
+ .prot_sect = PMD_TYPE_SECT | PMD_SECT_AP_WRITE |
+ PMD_SECT_UNCACHED,
+ .domain = DOMAIN_KERNEL,
+ },
};
const struct mem_type *get_mem_type(unsigned int type)
diff --git a/arch/arm/plat-omap/include/plat/io.h b/arch/arm/plat-omap/include/plat/io.h
index ef4106c..ee333a6 100644
--- a/arch/arm/plat-omap/include/plat/io.h
+++ b/arch/arm/plat-omap/include/plat/io.h
@@ -60,6 +60,17 @@
#define IOMEM(x) ((void __force __iomem *)(x))
#endif
+#ifdef CONFIG_INTERCONNECT_IO_POSTING
+ /*
+ * ARM writes to devices are postable. Further software
+ * sychronization neeed ex: DSB or register read back
+ */
+ #define IO_MAP_TYPE MT_DEVICE
+ #else
+ /* ARM writes to devices are sychronized */
+ #define IO_MAP_TYPE MT_MEMORY_SO
+ #endif
+
#define OMAP1_IO_OFFSET 0x01000000 /* Virtual IO = 0xfefb0000 */
#define OMAP1_IO_ADDRESS(pa) IOMEM((pa) - OMAP1_IO_OFFSET)
@@ -144,6 +155,18 @@
* ----------------------------------------------------------------------------
*/
+/* Select ARM view IO behavior */
+#ifdef CONFIG_INTERCONNECT_IO_POSTING
+/*
+ * ARM writes to devices are postable. Further software
+ * sychronization neeed ex: DSB or register read back
+ */
+#define IO_MAP_TYPE MT_DEVICE
+#else
+/* ARM writes to devices are sychronized */
+#define IO_MAP_TYPE MT_MEMORY_SO
+#endif
+
/* We map both L3 and L4 on OMAP3 */
#define L3_34XX_PHYS L3_34XX_BASE /* 0x68000000 --> 0xf8000000 */
#define L3_34XX_VIRT (L3_34XX_PHYS + OMAP2_L3_IO_OFFSET)
--
1.6.0.4
next prev parent reply other threads:[~2011-01-14 18:55 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-01-11 16:52 Passing mem=1G to kernel on Panda, system is unstable Bryan Wu
2011-01-12 23:50 ` Paul Walmsley
2011-01-13 0:02 ` Bryan Wu
2011-01-14 5:41 ` Paul Walmsley
2011-01-14 10:09 ` Bryan Wu
2011-01-14 17:11 ` Jan, Sebastien
2011-01-14 17:22 ` Santosh Shilimkar
2011-01-14 17:48 ` Bryan Wu
2011-01-14 17:48 ` Jan, Sebastien
2011-01-14 18:41 ` Bryan Wu
2011-01-14 18:55 ` Santosh Shilimkar [this message]
2011-01-14 19:06 ` Bryan Wu
2011-01-14 20:26 ` Bryan Wu
2011-01-14 8:12 ` Santosh Shilimkar
2011-01-14 8:56 ` Santosh Shilimkar
2011-01-14 10:14 ` Bryan Wu
2011-01-14 10:12 ` Bryan Wu
2011-01-17 18:41 ` Jan, Sebastien
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=85fb20a5e00e0a3e5b0abbd56574e36f@mail.gmail.com \
--to=santosh.shilimkar@ti.com \
--cc=bryan.wu@canonical.com \
--cc=linux-omap@vger.kernel.org \
--cc=paul@pwsan.com \
--cc=ricardo.salveti@canonical.com \
--cc=s-jan@ti.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox