[RFC] Consolidate SRAM support

Commit Message

Tomi Valkeinen April 19, 2011, 2:16 p.m. UTC

Hi Tony and Russell,

On Mon, 2011-04-18 at 11:17 +0300, Tony Lindgren wrote:
> * Tomi Valkeinen <[e-mail]> [110418 09:57]:

> > So, I can make a patch that removes the SRAM support from omapfb, and
> > queue it up for the next merge window.
> 
> OK. That patch should probably go into Russell's tree along with
> other SRAM related patches to avoid conflicts.

Here's a simple patch to remove SRAM support from omapfb. Or more
precisely, this just disables it.

I started to remove the SRAM support from the drivers, but the patches
got quite big and will probably cause conflicts if they reside in
somebody else's tree than mine. So I believe it's easiest to divide SRAM
FB removal into this patch, handled by Russell (?), and then the rest,
handled by me.

Is there something else related to OMAP FB than the code removed in this
patch that is hindering the SRAM work?

 Tomi


From 8a32eb1762d9ecead1aee08cbe955748d67999fd Mon Sep 17 00:00:00 2001
From: Tomi Valkeinen <[e-mail]>
Date: Tue, 19 Apr 2011 16:58:51 +0300
Subject: [PATCH] OMAP: Remove reserve_sram calls to omapfb

This patch removes calls from arch/arm/plat-omap/sram.c to
omapfb_reserve_sram() and omap_vram_reserve_sram(), effectively
disabling SRAM support for the old and new display drivers.

SRAM code in the display drivers will be removed in separate patches.

Signed-off-by: Tomi Valkeinen <[e-mail]>
---
 arch/arm/plat-omap/sram.c |   13 -------------
 1 files changed, 0 insertions(+), 13 deletions(-)

Comments

Tony Lindgren April 20, 2011, 5:27 a.m. UTC | #1

* Tomi Valkeinen <[e-mail]> [110419 17:13]:
> Hi Tony and Russell,
> 
> On Mon, 2011-04-18 at 11:17 +0300, Tony Lindgren wrote:
> > * Tomi Valkeinen <[e-mail]> [110418 09:57]:
> 
> > > So, I can make a patch that removes the SRAM support from omapfb, and
> > > queue it up for the next merge window.
> > 
> > OK. That patch should probably go into Russell's tree along with
> > other SRAM related patches to avoid conflicts.
> 
> Here's a simple patch to remove SRAM support from omapfb. Or more
> precisely, this just disables it.
> 
> I started to remove the SRAM support from the drivers, but the patches
> got quite big and will probably cause conflicts if they reside in
> somebody else's tree than mine. So I believe it's easiest to divide SRAM
> FB removal into this patch, handled by Russell (?), and then the rest,
> handled by me.

OK sounds like a plan.
 
> Is there something else related to OMAP FB than the code removed in this
> patch that is hindering the SRAM work?

I think we can now also remove sram_ceil and omap_sram_push_address?

Regards,

Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to [e-mail]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Patch

diff --git a/arch/arm/plat-omap/sram.c b/arch/arm/plat-omap/sram.c
index a3f50b3..e10eeed 100644
--- a/arch/arm/plat-omap/sram.c
+++ b/arch/arm/plat-omap/sram.c
@@ -19,7 +19,6 @@ 
 #include <linux/kernel.h>
 #include <linux/init.h>
 #include <linux/io.h>
-#include <linux/omapfb.h>
 
 #include <asm/tlb.h>
 #include <asm/cacheflush.h>
@@ -32,7 +31,6 @@ 
 #include <plat/vram.h>
 
 #include "sram.h"
-#include "fb.h"
 
 /* XXX These "sideways" includes are a sign that something is wrong */
 #if defined(CONFIG_ARCH_OMAP2) || defined(CONFIG_ARCH_OMAP3)
@@ -170,17 +168,6 @@  static void __init omap_detect_sram(void)
 			omap_sram_size = 0x4000;
 		}
 	}
-	reserved = omapfb_reserve_sram(omap_sram_start, omap_sram_base,
-				       omap_sram_size,
-				       omap_sram_start + SRAM_BOOTLOADER_SZ,
-				       omap_sram_size - SRAM_BOOTLOADER_SZ);
-	omap_sram_size -= reserved;
-
-	reserved = omap_vram_reserve_sram(omap_sram_start, omap_sram_base,
-			omap_sram_size,
-			omap_sram_start + SRAM_BOOTLOADER_SZ,
-			omap_sram_size - SRAM_BOOTLOADER_SZ);
-	omap_sram_size -= reserved;
 
 	omap_sram_ceil = omap_sram_base + omap_sram_size;
 }