public inbox for linux-omap@vger.kernel.org
 help / color / mirror / Atom feed
From: Santosh Shilimkar <santosh.shilimkar@ti.com>
To: Tony Lindgren <tony@atomide.com>
Cc: Nicolas Pitre <nico@fluxnic.net>,
	linux-arm-kernel@lists.infradead.org, linux-omap@vger.kernel.org
Subject: Re: [PATCH 1/4] ARM: Add __arm_ioremap_exec for mapping external memory as MT_MEMORY
Date: Fri, 07 Oct 2011 23:09:39 +0530	[thread overview]
Message-ID: <4E8F395B.9070203@ti.com> (raw)
In-Reply-To: <20111007151116.GI6324@atomide.com>

On Friday 07 October 2011 08:41 PM, Tony Lindgren wrote:
> * Santosh Shilimkar <santosh.shilimkar@ti.com> [111007 07:29]:
>> On Friday 07 October 2011 08:13 PM, Tony Lindgren wrote:
>>>
>>> ..so I think we should just have a separate static mapping for
>>> the omap4 errata fix SO page, and just limit the memory available
>>> for SRAM code to ioremap.
>>>
>>> How does that sounds to you?
>>>
>> That's more or less what the patch is already doing.
>> Instead of static mapping, I was dynamically stealing one
>> page ( SZ_4K) and mapping it as MT_MEMORY_SO and rest
>> of the memory as MT_MEMORY for OMAP4.
> 
> Yeah cool.
>  
>> It should be doable with your updates as well,
>> I guess with or without static mapping since the only
>> requisite is to keep one page of SRAM free on OMAP4 and
>> them map them using  iotable_init() with MT_MEMORY_SO.
> 
> How about something like the following, this won't compile
> without at least moving the defines around a bit, but shows
> what I had in mind:
> 
> --- a/arch/arm/mach-omap2/io.c
> +++ b/arch/arm/mach-omap2/io.c
> @@ -238,6 +238,14 @@ static struct map_desc omap44xx_io_desc[] __initdata = {
>  		.length		= L4_EMU_44XX_SIZE,
>  		.type		= MT_DEVICE,
>  	},
> +#ifdef CONFIG_OMAP4_ERRATA_I688
> +	{
> +		.virtual	= OMAP4_SRAM_VA,
> +		.pfn		= __phys_to_pfn(OMAP4_SRAM_PA),
> +		.length		= PAGE_SIZE,
> +		.type		= MT_MEMORY_SO,
> +	},
> +#endif
>  };

I initially tried some thing similar but the issue was GP and
HS devices. SRAM_PA isn't same on GP and EMU device and hence
did that dynamically. One way is I can make GP and HS
device SRAM_PA same for OMAP4 (Will loose 16 KB of
SRAM on OMAP4 GP). It's ok to loose that 16 KB SRAM
for OMAP4 with errata enabled.

Below change works on both GP and HS device
If you are OK with it, I can update errata patch accordingly.

diff --git a/arch/arm/plat-omap/include/plat/sram.h
b/arch/arm/plat-omap/include/plat/sram.h
index f500fc3..111b1a8 100644
--- a/arch/arm/plat-omap/include/plat/sram.h
+++ b/arch/arm/plat-omap/include/plat/sram.h
@@ -95,6 +95,11 @@ static inline void omap_push_sram_idle(void) {}
  */
 #define OMAP2_SRAM_PA		0x40200000
 #define OMAP3_SRAM_PA           0x40200000
+#ifdef CONFIG_OMAP4_ERRATA_I688
+#define OMAP4_SRAM_PA		0x40304000
+#else
 #define OMAP4_SRAM_PA		0x40300000
+#endif
+#define OMAP4_SRAM_VA		0xfe404000

 #endif
diff --git a/arch/arm/plat-omap/sram.c b/arch/arm/plat-omap/sram.c
index 363c91e..cdd303f 100644
--- a/arch/arm/plat-omap/sram.c
+++ b/arch/arm/plat-omap/sram.c
@@ -48,9 +48,13 @@
 #define OMAP3_SRAM_VA           0xfe400000
 #define OMAP3_SRAM_PUB_PA       (OMAP3_SRAM_PA + 0x8000)
 #define OMAP3_SRAM_PUB_VA       (OMAP3_SRAM_VA + 0x8000)
-#define OMAP4_SRAM_VA		0xfe400000
+#ifdef CONFIG_OMAP4_ERRATA_I688
+#define OMAP4_SRAM_PUB_PA	OMAP4_SRAM_PA
+#define OMAP4_SRAM_PUB_VA	OMAP4_SRAM_VA
+#else
 #define OMAP4_SRAM_PUB_PA	(OMAP4_SRAM_PA + 0x4000)
 #define OMAP4_SRAM_PUB_VA	(OMAP4_SRAM_VA + 0x4000)
+#endif

 #if defined(CONFIG_ARCH_OMAP2PLUS)
 #define SRAM_BOOTLOADER_SZ	0x00
@@ -203,6 +207,11 @@ static void __init omap_map_sram(void)
 	if (omap_sram_size == 0)
 		return;

+#ifdef CONFIG_OMAP4_ERRATA_I688
+		omap_sram_base += PAGE_SIZE;
+		omap_sram_start += PAGE_SIZE;
+		omap_sram_size -= SZ_16K;
+#endif
 	if (cpu_is_omap34xx()) {
 		/*
 		 * SRAM must be marked as non-cached on OMAP3 since the

Regards
Santosh

  reply	other threads:[~2011-10-07 17:39 UTC|newest]

Thread overview: 37+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-10-05  0:45 [PATCH 0/4] initialize omap SRAM later on with __arm_ioremap_exec() Tony Lindgren
2011-10-05  0:45 ` [PATCH 1/4] ARM: Add __arm_ioremap_exec for mapping external memory as MT_MEMORY Tony Lindgren
2011-10-05  1:00   ` Nicolas Pitre
2011-10-05 22:06     ` Tony Lindgren
2011-10-05 22:08       ` [PATCH 1.5/4] ARM: OMAP1: Use generic map_io, init_early and init_irq Tony Lindgren
2011-10-07  6:40       ` [PATCH 1/4] ARM: Add __arm_ioremap_exec for mapping external memory as MT_MEMORY Santosh Shilimkar
2011-10-07 14:43         ` Tony Lindgren
2011-10-07 15:03           ` Santosh Shilimkar
2011-10-07 15:11             ` Tony Lindgren
2011-10-07 17:39               ` Santosh Shilimkar [this message]
2011-10-07 18:16                 ` Tony Lindgren
2011-10-07 18:20                   ` Santosh Shilimkar
2011-10-07 18:27                     ` Tony Lindgren
2011-10-05  0:45 ` [PATCH 2/4] ARM: OMAP: Avoid cpu_is_omapxxxx usage until map_io is done Tony Lindgren
2011-10-07  6:47   ` Santosh Shilimkar
2011-10-05  0:45 ` [PATCH 3/4] ARM: OMAP: Remove calls to SRAM allocations for framebuffer Tony Lindgren
2011-10-05  6:45   ` Tomi Valkeinen
2011-10-05 22:41     ` Tony Lindgren
2011-10-06  8:38       ` Tomi Valkeinen
2011-10-06 16:22         ` Tony Lindgren
2011-10-05  0:45 ` [PATCH 4/4] ARM: OMAP: Map SRAM later on with ioremap_exec() Tony Lindgren
2011-10-05  1:07   ` Nicolas Pitre
2011-10-05 22:13     ` Tony Lindgren
2011-10-05 23:01       ` Nicolas Pitre
2011-10-07  6:52       ` Santosh Shilimkar
2011-10-07 14:55         ` Tony Lindgren
2011-10-05  1:40 ` [PATCH 5/4] ARM: OMAP: Move set_globals initialization to happen in init_early Tony Lindgren
2011-10-05  1:51   ` Nicolas Pitre
2011-10-06  1:36     ` Tony Lindgren
2011-10-07  6:56       ` Santosh Shilimkar
2011-10-07 14:54         ` Tony Lindgren
2011-10-07 23:26           ` Nicolas Pitre
2011-10-05  7:03 ` [PATCH 0/4] initialize omap SRAM later on with __arm_ioremap_exec() Santosh Shilimkar
2011-10-06  1:42   ` Tony Lindgren
2011-10-07  6:59     ` Santosh Shilimkar
2011-10-07 14:45       ` Tony Lindgren
2011-10-07 20:23       ` Nicolas Pitre

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=4E8F395B.9070203@ti.com \
    --to=santosh.shilimkar@ti.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-omap@vger.kernel.org \
    --cc=nico@fluxnic.net \
    --cc=tony@atomide.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