[PATCH 1/3] OMAP: VRAM: improve VRAM error prints

[PATCH 1/3] OMAP: VRAM: improve VRAM error prints

[Tomi Valkeinen]

Improve the error prints to give more information about the offending
address & size.

Signed-off-by: Tomi Valkeinen <tomi.valkeinen@nokia.com>
---
 drivers/video/omap2/vram.c |   12 +++++++++---
 1 files changed, 9 insertions(+), 3 deletions(-)

diff --git a/drivers/video/omap2/vram.c b/drivers/video/omap2/vram.c
index fed2a72..bb5ee06 100644
--- a/drivers/video/omap2/vram.c
+++ b/drivers/video/omap2/vram.c
@@ -554,9 +554,15 @@ void __init omap_vram_reserve_sdram_memblock(void)
 	size = PAGE_ALIGN(size);
 
 	if (paddr) {
-		if ((paddr & ~PAGE_MASK) ||
-		    !memblock_is_region_memory(paddr, size)) {
-			pr_err("Illegal SDRAM region for VRAM\n");
+		if (paddr & ~PAGE_MASK) {
+			pr_err("VRAM start address 0x%08x not page aligned\n",
+					paddr);
+			return;
+		}
+
+		if (!memblock_is_region_memory(paddr, size)) {
+			pr_err("Illegal SDRAM region 0x%08x..0x%08x for VRAM\n",
+					paddr, paddr + size - 1);
 			return;
 		}
 
-- 
1.7.1

[PATCH 2/3] OMAP: VRAM: Fix boot-time memory allocation

[Tomi Valkeinen]

Use memblock_free() and memblock_remove() to remove the allocated or
reserved VRAM area from normal kernel memory.

This is a slightly modified version of patches from Felipe Contreras and
Namhyung Kim.

Reported-by: Felipe Contreras <felipe.contreras@gmail.com>
Reported-by: Namhyung Kim <namhyung@gmail.com>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@nokia.com>
---
 drivers/video/omap2/vram.c |    5 ++++-
 1 files changed, 4 insertions(+), 1 deletions(-)

diff --git a/drivers/video/omap2/vram.c b/drivers/video/omap2/vram.c
index bb5ee06..2fd7e52 100644
--- a/drivers/video/omap2/vram.c
+++ b/drivers/video/omap2/vram.c
@@ -576,9 +576,12 @@ void __init omap_vram_reserve_sdram_memblock(void)
 			return;
 		}
 	} else {
-		paddr = memblock_alloc_base(size, PAGE_SIZE, MEMBLOCK_REAL_LIMIT);
+		paddr = memblock_alloc(size, PAGE_SIZE);
 	}
 
+	memblock_free(paddr, size);
+	memblock_remove(paddr, size);
+
 	omap_vram_add_region(paddr, size);
 
 	pr_info("Reserving %u bytes SDRAM for VRAM\n", size);
-- 
1.7.1

Re: [PATCH 2/3] OMAP: VRAM: Fix boot-time memory allocation

[Felipe Contreras]

On Wed, Nov 10, 2010 at 11:45 AM, Tomi Valkeinen
<tomi.valkeinen@nokia.com> wrote:
> Use memblock_free() and memblock_remove() to remove the allocated or
> reserved VRAM area from normal kernel memory.
>
> This is a slightly modified version of patches from Felipe Contreras and
> Namhyung Kim.
>
> Reported-by: Felipe Contreras <felipe.contreras@gmail.com>
> Reported-by: Namhyung Kim <namhyung@gmail.com>
> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@nokia.com>

I would have kept these as two separate patches as they do two different things:
 1) Fix a build error
 2) Prepare for future ioremap() changes[1]

The current patch mentions 1) in the summary, and 2) in the commit
message, but it doesn't explain why 2) is needed. Maybe for the next
time.

Cheers.

[1] http://article.gmane.org/gmane.linux.ports.arm.omap/44978

-- 
Felipe Contreras

[PATCH 3/3] OMAP: DSS: Fix documentation regarding 'vram' kernel parameter

[Tomi Valkeinen]

The DSS documentation didn't mention the option to give the VRAM start
address.

Signed-off-by: Tomi Valkeinen <tomi.valkeinen@nokia.com>
---
 Documentation/arm/OMAP/DSS |    7 ++++---
 1 files changed, 4 insertions(+), 3 deletions(-)

diff --git a/Documentation/arm/OMAP/DSS b/Documentation/arm/OMAP/DSS
index 0af0e9e..888ae7b 100644
--- a/Documentation/arm/OMAP/DSS
+++ b/Documentation/arm/OMAP/DSS
@@ -255,9 +255,10 @@ framebuffer parameters.
 Kernel boot arguments
 ---------------------
 
-vram=<size>
-	- Amount of total VRAM to preallocate. For example, "10M". omapfb
-	  allocates memory for framebuffers from VRAM.
+vram=<size>[,<physaddr>]
+	- Amount of total VRAM to preallocate and optionally a physical start
+	  memory address. For example, "10M". omapfb allocates memory for
+	  framebuffers from VRAM.
 
 omapfb.mode=<display>:<mode>[,...]
 	- Default video mode for specified displays. For example,
-- 
1.7.1

Re: [PATCH 1/3] OMAP: VRAM: improve VRAM error prints

[Paul Mundt]

On Wed, Nov 10, 2010 at 11:45:18AM +0200, Tomi Valkeinen wrote:
> Improve the error prints to give more information about the offending
> address & size.
> 
> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@nokia.com>

1-3 queued for .37, thanks.

Re: [PATCH 1/3] OMAP: VRAM: improve VRAM error prints

[Tomi Valkeinen]

On Wed, 2010-11-10 at 12:51 +0100, ext Paul Mundt wrote:
> On Wed, Nov 10, 2010 at 11:45:18AM +0200, Tomi Valkeinen wrote:
> > Improve the error prints to give more information about the offending
> > address & size.
> > 
> > Signed-off-by: Tomi Valkeinen <tomi.valkeinen@nokia.com>
> 
> 1-3 queued for .37, thanks.

They were just for review =).

If it's ok to you, I'll pick all OMAP display related patches to my
tree, and send you a pull request when I think they are ready.

But for these three patches it's ok if you already queued them: they are
quite high priority, as the OMAP framebuffer doesn't work at all without
the second patch.

 Tomi

Re: [PATCH 1/3] OMAP: VRAM: improve VRAM error prints

[Paul Mundt]

On Wed, Nov 10, 2010 at 02:04:14PM +0200, Tomi Valkeinen wrote:
> On Wed, 2010-11-10 at 12:51 +0100, ext Paul Mundt wrote:
> > On Wed, Nov 10, 2010 at 11:45:18AM +0200, Tomi Valkeinen wrote:
> > > Improve the error prints to give more information about the offending
> > > address & size.
> > > 
> > > Signed-off-by: Tomi Valkeinen <tomi.valkeinen@nokia.com>
> > 
> > 1-3 queued for .37, thanks.
> 
> They were just for review =).
> 
> If it's ok to you, I'll pick all OMAP display related patches to my
> tree, and send you a pull request when I think they are ready.
> 
I wasn't sure what your intentions were, but that's of course fine, too!

Please keep an eye on the -rc timing however, so we don't end up with
bigger things piling up in the later -rc stages and then have to start
cherry-picking the urgent bits.

> But for these three patches it's ok if you already queued them: they are
> quite high priority, as the OMAP framebuffer doesn't work at all without
> the second patch.
> 
Right. I looked through the OMAP list archives for some context on these
first and since the second one was at least a build fix I assumed you
wanted to get them merged sooner rather than later.