public inbox for linux-omap@vger.kernel.org
 help / color / mirror / Atom feed
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


  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