DSS2 broken with 36-rc1

DSS2 broken with 36-rc1

[Ameya Palande]

Hi Tomi,

When I tried to boot 2.6.36-rc1 kernel on Nokia N900, omapfb failed with
following error messages:

[    0.124145] OMAP DSS rev 2.0
[    0.124237] OMAP DISPC rev 3.0

[    0.303833] acx565akm spi1.2: omapfb: acx565akm rev 8b LCD detected

[    0.805419] omapfb omapfb: failed to allocate framebuffer
[    0.810882] omapfb omapfb: failed to allocate fbmem
[    0.815856] omapfb omapfb: failed to setup omapfb
[    0.820648] omapfb: probe of omapfb failed with error -12

I used CONFIG_CMDLINE="console=tty0 console=ttyS2,115200n8
omapfb.vram=0:2M,1:2M,2:2M nosplash"

I have verified that the kernel config which I used, works well with
2.6.35 series kernel.

Cheers,
Ameya.

Re: DSS2 broken with 36-rc1

[Pawel Moll]

Hi Ameya,

> [    0.805419] omapfb omapfb: failed to allocate framebuffer
> [    0.810882] omapfb omapfb: failed to allocate fbmem
> [    0.815856] omapfb omapfb: failed to setup omapfb
> [    0.820648] omapfb: probe of omapfb failed with error -12

Could you quickly try this hack?

diff --git a/arch/arm/mm/ioremap.c b/arch/arm/mm/ioremap.c
index ab50627..0875b2d 100644
--- a/arch/arm/mm/ioremap.c
+++ b/arch/arm/mm/ioremap.c
@@ -204,8 +204,8 @@ void __iomem * __arm_ioremap_pfn_caller(unsigned long pfn,
        /*
         * Don't allow RAM to be mapped - this causes problems with ARMv6+
         */
-       if (WARN_ON(pfn_valid(pfn)))
-               return NULL;
+//     if (WARN_ON(pfn_valid(pfn)))
+//             return NULL;
 
        type = get_mem_type(mtype);
        if (!type)


If it helps you have just encountered side effects of this:


commit 309caa9cc6ff39d261264ec4ff10e29489afc8f8
Author: Russell King <rmk+kernel@arm.linux.org.uk>
Date:   Mon Jun 21 21:03:18 2010 +0100

    ARM: Prohibit ioremap() on kernel managed RAM


I've been there last week as well... (didn't have time to think this
over, though)

Cheers!

Paweł

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

Re: DSS2 broken with 36-rc1

[Ameya Palande]

On Mon, 2010-08-16 at 14:59 +0200, ext Pawel Moll wrote:
> Hi Ameya,
> 
> > [    0.805419] omapfb omapfb: failed to allocate framebuffer
> > [    0.810882] omapfb omapfb: failed to allocate fbmem
> > [    0.815856] omapfb omapfb: failed to setup omapfb
> > [    0.820648] omapfb: probe of omapfb failed with error -12
> 
> Could you quickly try this hack?
> 
> diff --git a/arch/arm/mm/ioremap.c b/arch/arm/mm/ioremap.c
> index ab50627..0875b2d 100644
> --- a/arch/arm/mm/ioremap.c
> +++ b/arch/arm/mm/ioremap.c
> @@ -204,8 +204,8 @@ void __iomem * __arm_ioremap_pfn_caller(unsigned long pfn,
>         /*
>          * Don't allow RAM to be mapped - this causes problems with ARMv6+
>          */
> -       if (WARN_ON(pfn_valid(pfn)))
> -               return NULL;
> +//     if (WARN_ON(pfn_valid(pfn)))
> +//             return NULL;
>  
>         type = get_mem_type(mtype);
>         if (!type)
> 
> 
> If it helps you have just encountered side effects of this:

Doesn't help :( But I also feel that it might be broken because of:

commit 98864ff58dd2b8ef9e72b0d2c70f34e7ff24a2ee
Author: Russell King <rmk+kernel@arm.linux.org.uk>
Date:   Sat May 22 23:59:11 2010 +0100

    ARM: OMAP: Convert OMAPFB and VRAM SDRAM reservation to LMB
    
    Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>

commit 8d717a52d1b0959128be5134dd12608e8e4f2115
Author: Russell King <rmk+kernel@arm.linux.org.uk>
Date:   Sat May 22 19:47:18 2010 +0100

    ARM: Convert platform reservations to use LMB rather than bootmem
    
    Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>

Cheers,
Ameya.

Re: DSS2 broken with 36-rc1

[Mike Rapoport]

Hi Ameya,

Ameya Palande wrote:
> Hi Tomi,
> 
> When I tried to boot 2.6.36-rc1 kernel on Nokia N900, omapfb failed with
> following error messages:
> 
> [    0.124145] OMAP DSS rev 2.0
> [    0.124237] OMAP DISPC rev 3.0
> 
> [    0.303833] acx565akm spi1.2: omapfb: acx565akm rev 8b LCD detected
> 
> [    0.805419] omapfb omapfb: failed to allocate framebuffer
> [    0.810882] omapfb omapfb: failed to allocate fbmem
> [    0.815856] omapfb omapfb: failed to setup omapfb
> [    0.820648] omapfb: probe of omapfb failed with error -12

Can you try this one:

 From 28de4496224d1e2ae72dcb5bb52b72d850d3cc49 Mon Sep 17 00:00:00 2001
From: Mike Rapoport <mike@compulab.co.il>
Date: Mon, 23 Aug 2010 09:40:09 +0300
Subject: [PATCH] OMAP: DSS2: OMAPFB: use phys_to_virt for RAM mappings

After commit 309caa9cc6ff39d261264ec4ff10e29489afc8f8 (ARM: Prohibit
ioremap() on kernel managed RAM) it is impossible to ioremap SDRAM for
the framebuffer. Use phys_to_virt for kernel managed RAM mapping and
ioremap for other memory types

Reported-by: Ameya Palande <ameya.palande@nokia.com>
Signed-off-by: Mike Rapoport <mike@compulab.co.il>
---
  drivers/video/omap2/omapfb/omapfb-main.c |    5 ++++-
  1 files changed, 4 insertions(+), 1 deletions(-)

diff --git a/drivers/video/omap2/omapfb/omapfb-main.c b/drivers/video/omap2/omapfb/omapfb-main.c
index 04034d4..7f7b1c2 100644
--- a/drivers/video/omap2/omapfb/omapfb-main.c
+++ b/drivers/video/omap2/omapfb/omapfb-main.c
@@ -1436,7 +1436,10 @@ static int omapfb_alloc_fbmem(struct fb_info *fbi, unsigned long size,
  	}

  	if (ofbi->rotation_type != OMAP_DSS_ROT_VRFB) {
-		vaddr = ioremap_wc(paddr, size);
+		if (region_mem_type(paddr) == OMAP_VRAM_MEMTYPE_SDRAM)
+			vaddr = phys_to_virt(paddr);
+		else
+			vaddr = ioremap_wc(paddr, size);

  		if (!vaddr) {
  			dev_err(fbdev->dev, "failed to ioremap framebuffer\n");
-- 
1.6.6.2




-- 
Sincerely yours,
Mike.

Re: DSS2 broken with 36-rc1

[Mike Rapoport]

Mike Rapoport wrote:
> Hi Ameya,
> 
> Ameya Palande wrote:
>> Hi Tomi,
>>
>> When I tried to boot 2.6.36-rc1 kernel on Nokia N900, omapfb failed with
>> following error messages:
>>
>> [    0.124145] OMAP DSS rev 2.0
>> [    0.124237] OMAP DISPC rev 3.0
>>
>> [    0.303833] acx565akm spi1.2: omapfb: acx565akm rev 8b LCD detected
>>
>> [    0.805419] omapfb omapfb: failed to allocate framebuffer
>> [    0.810882] omapfb omapfb: failed to allocate fbmem
>> [    0.815856] omapfb omapfb: failed to setup omapfb
>> [    0.820648] omapfb: probe of omapfb failed with error -12
> 

Please discard the previous patch, it's buggy :(
Sorry for the noise.

 From 81e9278ad27bc91be42105321e0e26d0be9e883b Mon Sep 17 00:00:00 2001
From: Mike Rapoport <mike@compulab.co.il>
Date: Mon, 23 Aug 2010 09:40:09 +0300
Subject: [PATCH] OMAP: DSS2: OMAPFB: use phys_to_virt for RAM mappings

After commit 309caa9cc6ff39d261264ec4ff10e29489afc8f8 (ARM: Prohibit
ioremap() on kernel managed RAM) it is impossible to ioremap SDRAM for
the framebuffer. Use phys_to_virt for kernel managed RAM mapping and
ioremap for other memory types

Reported-by: Ameya Palande <ameya.palande@nokia.com>
Signed-off-by: Mike Rapoport <mike@compulab.co.il>
---
  arch/arm/plat-omap/include/plat/vram.h   |    1 +
  drivers/video/omap2/omapfb/omapfb-main.c |    2 +-
  drivers/video/omap2/vram.c               |   10 ++++++++++
  3 files changed, 12 insertions(+), 1 deletions(-)

diff --git a/arch/arm/plat-omap/include/plat/vram.h b/arch/arm/plat-omap/include/plat/vram.h
index 0aa4ecd..b1b137c 100644
--- a/arch/arm/plat-omap/include/plat/vram.h
+++ b/arch/arm/plat-omap/include/plat/vram.h
@@ -33,6 +33,7 @@ extern int omap_vram_alloc(int mtype, size_t size, unsigned long *paddr);
  extern int omap_vram_reserve(unsigned long paddr, size_t size);
  extern void omap_vram_get_info(unsigned long *vram, unsigned long *free_vram,
  		unsigned long *largest_free_block);
+extern void __iomem *omap_vram_remap(size_t size, unsigned long paddr);

  #ifdef CONFIG_OMAP2_VRAM
  extern void omap_vram_set_sdram_vram(u32 size, u32 start);
diff --git a/drivers/video/omap2/omapfb/omapfb-main.c b/drivers/video/omap2/omapfb/omapfb-main.c
index 04034d4..39f53b1 100644
--- a/drivers/video/omap2/omapfb/omapfb-main.c
+++ b/drivers/video/omap2/omapfb/omapfb-main.c
@@ -1436,7 +1436,7 @@ static int omapfb_alloc_fbmem(struct fb_info *fbi, unsigned long size,
  	}

  	if (ofbi->rotation_type != OMAP_DSS_ROT_VRFB) {
-		vaddr = ioremap_wc(paddr, size);
+		vaddr = omap_vram_remap(size, paddr);

  		if (!vaddr) {
  			dev_err(fbdev->dev, "failed to ioremap framebuffer\n");
diff --git a/drivers/video/omap2/vram.c b/drivers/video/omap2/vram.c
index f6fdc20..37557b6 100644
--- a/drivers/video/omap2/vram.c
+++ b/drivers/video/omap2/vram.c
@@ -30,6 +30,7 @@
  #include <linux/debugfs.h>
  #include <linux/jiffies.h>
  #include <linux/module.h>
+#include <linux/io.h>

  #include <asm/setup.h>

@@ -425,6 +426,15 @@ void omap_vram_get_info(unsigned long *vram,
  }
  EXPORT_SYMBOL(omap_vram_get_info);

+void __iomem *omap_vram_remap(size_t size, unsigned long paddr)
+{
+	if (region_mem_type(paddr) == OMAP_VRAM_MEMTYPE_SDRAM)
+		return phys_to_virt(paddr);
+
+	return ioremap_wc(paddr, size);
+}
+EXPORT_SYMBOL(omap_vram_remap);
+
  #if defined(CONFIG_DEBUG_FS)
  static int vram_debug_show(struct seq_file *s, void *unused)
  {
-- 
1.6.6.2



-- 
Sincerely yours,
Mike.

Re: DSS2 broken with 36-rc1

[Laine Walker-Avina]

On Mon, Aug 23, 2010 at 12:06 AM, Mike Rapoport <mike@compulab.co.il> wrote:
> Mike Rapoport wrote:
>>
>> Hi Ameya,
>>
>> Ameya Palande wrote:
>>>
>>> Hi Tomi,
>>>
>>> When I tried to boot 2.6.36-rc1 kernel on Nokia N900, omapfb failed with
>>> following error messages:
>>>
>>> [    0.124145] OMAP DSS rev 2.0
>>> [    0.124237] OMAP DISPC rev 3.0
>>>
>>> [    0.303833] acx565akm spi1.2: omapfb: acx565akm rev 8b LCD detected
>>>
>>> [    0.805419] omapfb omapfb: failed to allocate framebuffer
>>> [    0.810882] omapfb omapfb: failed to allocate fbmem
>>> [    0.815856] omapfb omapfb: failed to setup omapfb
>>> [    0.820648] omapfb: probe of omapfb failed with error -12
>>
>
> Please discard the previous patch, it's buggy :(
> Sorry for the noise.
>
> From 81e9278ad27bc91be42105321e0e26d0be9e883b Mon Sep 17 00:00:00 2001
> From: Mike Rapoport <mike@compulab.co.il>
> Date: Mon, 23 Aug 2010 09:40:09 +0300
> Subject: [PATCH] OMAP: DSS2: OMAPFB: use phys_to_virt for RAM mappings
>
> After commit 309caa9cc6ff39d261264ec4ff10e29489afc8f8 (ARM: Prohibit
> ioremap() on kernel managed RAM) it is impossible to ioremap SDRAM for
> the framebuffer. Use phys_to_virt for kernel managed RAM mapping and
> ioremap for other memory types
>
> Reported-by: Ameya Palande <ameya.palande@nokia.com>
> Signed-off-by: Mike Rapoport <mike@compulab.co.il>
> ---
>  arch/arm/plat-omap/include/plat/vram.h   |    1 +
>  drivers/video/omap2/omapfb/omapfb-main.c |    2 +-
>  drivers/video/omap2/vram.c               |   10 ++++++++++
>  3 files changed, 12 insertions(+), 1 deletions(-)
>
> diff --git a/arch/arm/plat-omap/include/plat/vram.h
> b/arch/arm/plat-omap/include/plat/vram.h
> index 0aa4ecd..b1b137c 100644
> --- a/arch/arm/plat-omap/include/plat/vram.h
> +++ b/arch/arm/plat-omap/include/plat/vram.h
> @@ -33,6 +33,7 @@ extern int omap_vram_alloc(int mtype, size_t size,
> unsigned long *paddr);
>  extern int omap_vram_reserve(unsigned long paddr, size_t size);
>  extern void omap_vram_get_info(unsigned long *vram, unsigned long
> *free_vram,
>                unsigned long *largest_free_block);
> +extern void __iomem *omap_vram_remap(size_t size, unsigned long paddr);
>
>  #ifdef CONFIG_OMAP2_VRAM
>  extern void omap_vram_set_sdram_vram(u32 size, u32 start);
> diff --git a/drivers/video/omap2/omapfb/omapfb-main.c
> b/drivers/video/omap2/omapfb/omapfb-main.c
> index 04034d4..39f53b1 100644
> --- a/drivers/video/omap2/omapfb/omapfb-main.c
> +++ b/drivers/video/omap2/omapfb/omapfb-main.c
> @@ -1436,7 +1436,7 @@ static int omapfb_alloc_fbmem(struct fb_info *fbi,
> unsigned long size,
>        }
>
>        if (ofbi->rotation_type != OMAP_DSS_ROT_VRFB) {
> -               vaddr = ioremap_wc(paddr, size);
> +               vaddr = omap_vram_remap(size, paddr);
>
>                if (!vaddr) {
>                        dev_err(fbdev->dev, "failed to ioremap
> framebuffer\n");
> diff --git a/drivers/video/omap2/vram.c b/drivers/video/omap2/vram.c
> index f6fdc20..37557b6 100644
> --- a/drivers/video/omap2/vram.c
> +++ b/drivers/video/omap2/vram.c
> @@ -30,6 +30,7 @@
>  #include <linux/debugfs.h>
>  #include <linux/jiffies.h>
>  #include <linux/module.h>
> +#include <linux/io.h>
>
>  #include <asm/setup.h>
>
> @@ -425,6 +426,15 @@ void omap_vram_get_info(unsigned long *vram,
>  }
>  EXPORT_SYMBOL(omap_vram_get_info);
>
> +void __iomem *omap_vram_remap(size_t size, unsigned long paddr)
> +{
> +       if (region_mem_type(paddr) == OMAP_VRAM_MEMTYPE_SDRAM)
> +               return phys_to_virt(paddr);
> +
> +       return ioremap_wc(paddr, size);
> +}
> +EXPORT_SYMBOL(omap_vram_remap);
> +
>  #if defined(CONFIG_DEBUG_FS)
>  static int vram_debug_show(struct seq_file *s, void *unused)
>  {
> --
> 1.6.6.2
>
>
>
> --
> Sincerely yours,
> Mike.
> --
> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>

I just tried this on my custom board, and it solves my issue with
ioremap. As a point of consistency, I'd reverse the order of the
parameters on omap_vram_remap() so that they match the old
ioremap_wc() call. Otherwise, I'd ACK this patch.


-- 
Laine Walker-Avina
Firmware Engineer
PASCO scientific
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: DSS2 broken with 36-rc1

[Tomi Valkeinen]

Hi,

On Mon, 2010-08-23 at 09:06 +0200, ext Mike Rapoport wrote:
> Mike Rapoport wrote:

>  From 81e9278ad27bc91be42105321e0e26d0be9e883b Mon Sep 17 00:00:00 2001
> From: Mike Rapoport <mike@compulab.co.il>
> Date: Mon, 23 Aug 2010 09:40:09 +0300
> Subject: [PATCH] OMAP: DSS2: OMAPFB: use phys_to_virt for RAM mappings
> 
> After commit 309caa9cc6ff39d261264ec4ff10e29489afc8f8 (ARM: Prohibit
> ioremap() on kernel managed RAM) it is impossible to ioremap SDRAM for
> the framebuffer. Use phys_to_virt for kernel managed RAM mapping and
> ioremap for other memory types

Hmm. omapfb reserves/allocates the ram using memblock, and obviously
memory from memblock is "kernel managed RAM". What does it mean? The RAM
is already mapped? I guess so, if phys_to_virt() works. (I guess the
whole RAM is mapped automatically). With what caching? How can we get
writecombining for this memory?

Looking at the description of "ARM: Prohibit ioremap() on kernel managed
RAM" it sounds to me that we cannot have writecombining for framebuffer
memory, if it's "kernel managed RAM".

 Tomi

RE: DSS2 broken with 36-rc1

[Shilimkar, Santosh]

> -----Original Message-----
> From: linux-omap-owner@vger.kernel.org [mailto:linux-omap-
> owner@vger.kernel.org] On Behalf Of Tomi Valkeinen
> Sent: Wednesday, August 25, 2010 1:36 PM
> To: ext Mike Rapoport
> Cc: Palande Ameya (Nokia-MS/Helsinki); linux-omap
> Subject: Re: DSS2 broken with 36-rc1
> 
> Hi,
> 
> On Mon, 2010-08-23 at 09:06 +0200, ext Mike Rapoport wrote:
> > Mike Rapoport wrote:
> 
> >  From 81e9278ad27bc91be42105321e0e26d0be9e883b Mon Sep 17 00:00:00 2001
> > From: Mike Rapoport <mike@compulab.co.il>
> > Date: Mon, 23 Aug 2010 09:40:09 +0300
> > Subject: [PATCH] OMAP: DSS2: OMAPFB: use phys_to_virt for RAM mappings
> >
> > After commit 309caa9cc6ff39d261264ec4ff10e29489afc8f8 (ARM: Prohibit
> > ioremap() on kernel managed RAM) it is impossible to ioremap SDRAM for
> > the framebuffer. Use phys_to_virt for kernel managed RAM mapping and
> > ioremap for other memory types
> 
> Hmm. omapfb reserves/allocates the ram using memblock, and obviously
> memory from memblock is "kernel managed RAM". What does it mean? The RAM
> is already mapped? I guess so, if phys_to_virt() works. (I guess the
> whole RAM is mapped automatically). With what caching? How can we get
> writecombining for this memory?
> 
> Looking at the description of "ARM: Prohibit ioremap() on kernel managed
> RAM" it sounds to me that we cannot have writecombining for framebuffer
> memory, if it's "kernel managed RAM".
> 
This is indeed the case. One way to get write combining memory is to
use dma_alloc_coherent in kernel space. 
You can reserve some memory outside the kernel memory map and directly
mmap it to users pace with whatever attributes you interested in.

Regards,
Santosh

Re: DSS2 broken with 36-rc1

[Grazvydas Ignotas]

Let's CC Russell for this one.

On Wed, Aug 25, 2010 at 11:05 AM, Tomi Valkeinen
<tomi.valkeinen@nokia.com> wrote:
> Hi,
>
> On Mon, 2010-08-23 at 09:06 +0200, ext Mike Rapoport wrote:
>> Mike Rapoport wrote:
>
>>  From 81e9278ad27bc91be42105321e0e26d0be9e883b Mon Sep 17 00:00:00 2001
>> From: Mike Rapoport <mike@compulab.co.il>
>> Date: Mon, 23 Aug 2010 09:40:09 +0300
>> Subject: [PATCH] OMAP: DSS2: OMAPFB: use phys_to_virt for RAM mappings
>>
>> After commit 309caa9cc6ff39d261264ec4ff10e29489afc8f8 (ARM: Prohibit
>> ioremap() on kernel managed RAM) it is impossible to ioremap SDRAM for
>> the framebuffer. Use phys_to_virt for kernel managed RAM mapping and
>> ioremap for other memory types
>
> Hmm. omapfb reserves/allocates the ram using memblock, and obviously
> memory from memblock is "kernel managed RAM". What does it mean? The RAM
> is already mapped? I guess so, if phys_to_virt() works. (I guess the
> whole RAM is mapped automatically). With what caching? How can we get
> writecombining for this memory?
>
> Looking at the description of "ARM: Prohibit ioremap() on kernel managed
> RAM" it sounds to me that we cannot have writecombining for framebuffer
> memory, if it's "kernel managed RAM".
>
>  Tomi
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: DSS2 broken with 36-rc1

[Tomi Valkeinen]

On Wed, 2010-08-25 at 11:21 +0200, ext Grazvydas Ignotas wrote:
> Let's CC Russell for this one.
> 
> On Wed, Aug 25, 2010 at 11:05 AM, Tomi Valkeinen
> <tomi.valkeinen@nokia.com> wrote:
> > Hi,
> >
> > On Mon, 2010-08-23 at 09:06 +0200, ext Mike Rapoport wrote:
> >> Mike Rapoport wrote:
> >
> >>  From 81e9278ad27bc91be42105321e0e26d0be9e883b Mon Sep 17 00:00:00 2001
> >> From: Mike Rapoport <mike@compulab.co.il>
> >> Date: Mon, 23 Aug 2010 09:40:09 +0300
> >> Subject: [PATCH] OMAP: DSS2: OMAPFB: use phys_to_virt for RAM mappings
> >>
> >> After commit 309caa9cc6ff39d261264ec4ff10e29489afc8f8 (ARM: Prohibit
> >> ioremap() on kernel managed RAM) it is impossible to ioremap SDRAM for
> >> the framebuffer. Use phys_to_virt for kernel managed RAM mapping and
> >> ioremap for other memory types
> >
> > Hmm. omapfb reserves/allocates the ram using memblock, and obviously
> > memory from memblock is "kernel managed RAM". What does it mean? The RAM
> > is already mapped? I guess so, if phys_to_virt() works. (I guess the
> > whole RAM is mapped automatically). With what caching? How can we get
> > writecombining for this memory?
> >
> > Looking at the description of "ARM: Prohibit ioremap() on kernel managed
> > RAM" it sounds to me that we cannot have writecombining for framebuffer
> > memory, if it's "kernel managed RAM".

I'll try to summarize how the framebuffer memory is used with OMAP:

We have two kinds of memories:
- SRAM
- SDRAM

We have two ways to get the memory (done with memblock):
- Allocate, when we don't care about the address
- Reserve, when the bootloader has initialized a region of memory for
fb, and we want to use that

We have two ways to access the memories:
- Direct (ie. access it normally)
- VRFB (only for SDRAM)

VRFB is a HW block doing rotation. VRFB does not have any memory of its
own, but it uses a given region of SDRAM to store the pixels in a custom
format. VRFB has 4 regions, corresponding to 0, 90, 180 and 270 degree
rotations, and the user uses these regions to access the pixels, and
VRFB does the rotation on the fly.

We have three users for the memory:
- HW (DSS, DSP, SGX, ...)
- CPU inside kernel
- CPU inside user space

---

Some points:

- The memory for kernel is mapped with ioremap_wc().
- The memory for user space is mapped with io_remap_pfn_range(), and is
using pgprot_writecombine.

- When using VRFB, the SDRAM is accessed only by VRFB and thus does not
need to be mapped. VRFB regions can be ioremapped normally.

- SRAM can probably be ioremapped normally, as it's not normal kernel
managed RAM.

- In many cases we wouldn't need to ioremap inside the kernel at all, as
the kernel doesn't really need to read/write from/to the framebuffer. I
think the only user for this is the framebuffer console, which can be
disabled.

- I'm not really familiar with caching for ARM, but I believe the
framebuffer should use writecombining.

- There is dma_alloc_coherent, but that doesn't allow us to get the
memory at certain location, and at least previously it didn't support
allocating large enough buffers. Also, dma_alloc_coherent always maps
the memory for kernel, which is not required in some cases.

---

Questions, aimed at no one particular.

- Is all of the SDRAM automatically mapped, and so using phys_to_virt()
instead of ioremap() is ok?
- If ioremap()'ing SDRAM is not ok, is io_remap_pfn_range() and using
pgprot_writecombine also not ok?
- If we want to have different caching, how can we do that?
- Is it possible to get a memory area with memblock that would not be
part of the kernel managed RAM?
- And generally, what would be the best way to handle this all? =)

 Tomi

Re: DSS2 broken with 36-rc1

[Russell King - ARM Linux]

I'll respond more fully when I'm back in September.

On Wed, Aug 25, 2010 at 02:43:18PM +0300, Tomi Valkeinen wrote:
> I'll try to summarize how the framebuffer memory is used with OMAP:
> 
> We have two kinds of memories:
> - SRAM
> - SDRAM
> 
> We have two ways to get the memory (done with memblock):
> - Allocate, when we don't care about the address
> - Reserve, when the bootloader has initialized a region of memory for
> fb, and we want to use that
> 
> We have two ways to access the memories:
> - Direct (ie. access it normally)
> - VRFB (only for SDRAM)
> 
> VRFB is a HW block doing rotation. VRFB does not have any memory of its
> own, but it uses a given region of SDRAM to store the pixels in a custom
> format. VRFB has 4 regions, corresponding to 0, 90, 180 and 270 degree
> rotations, and the user uses these regions to access the pixels, and
> VRFB does the rotation on the fly.
> 
> We have three users for the memory:
> - HW (DSS, DSP, SGX, ...)
> - CPU inside kernel
> - CPU inside user space
> 
> ---
> 
> Some points:
> 
> - The memory for kernel is mapped with ioremap_wc().
> - The memory for user space is mapped with io_remap_pfn_range(), and is
> using pgprot_writecombine.

These two are fine when you consider only these two mappings.  However,
when you also consider that the memory is also mapped by the kernel as
a fully cacheable mapping, that's where the problem appears.

> - When using VRFB, the SDRAM is accessed only by VRFB and thus does not
> need to be mapped. VRFB regions can be ioremapped normally.

If this SDRAM isn't declared to the kernel, then that sounds fine.

> - SRAM can probably be ioremapped normally, as it's not normal kernel
> managed RAM.

Correct.

> - In many cases we wouldn't need to ioremap inside the kernel at all, as
> the kernel doesn't really need to read/write from/to the framebuffer. I
> think the only user for this is the framebuffer console, which can be
> disabled.

I'm not sure that it's possible to omit the virtual mapping of the
framebuffer - that's a question for the framebuffer people.

> - I'm not really familiar with caching for ARM, but I believe the
> framebuffer should use writecombining.

Yes it should, otherwise writes won't happen in a timely manner, and you
can have cache-visible effects apparant when things are being updated.

> - There is dma_alloc_coherent, but that doesn't allow us to get the
> memory at certain location, and at least previously it didn't support
> allocating large enough buffers. Also, dma_alloc_coherent always maps
> the memory for kernel, which is not required in some cases.

dma_alloc_coherent() is bounded by:
1. the size of the coherent region
2. the maximum size that alloc_pages() can allocate.

(1) can be expanded to increase the available mapping area.  (2) is a
harder problem to solve.

There is, however, talk about changing the dma_declare_coherent_memory()
interface such that we can give it SDRAM without it using ioremap().
This memory is available via dma_alloc_coherent(), and this is probably
a better solution to this problem.

The down side is that the memory will be set aside for the device, and
won't be available for other uses.

> Questions, aimed at no one particular.
> 
> - Is all of the SDRAM automatically mapped, and so using phys_to_virt()
> instead of ioremap() is ok?

Everything except memory deemed to be in the highmem range.

> - If ioremap()'ing SDRAM is not ok, is io_remap_pfn_range() and using
> pgprot_writecombine also not ok?

Correct - the problem is when you have multiple mappings of a physical
address with a different memory type (memory/device/strongly ordered)
or different memory cache attributes (write combine/writeback read alloc/
writeback write alloc etc).  Mappings of the same region with different
attributes is architecturally unpredictable.

Note that dma_alloc_coherent() suffers from this and needs to be fixed,
and is something I'll be working on over the next couple of months.

> - If we want to have different caching, how can we do that?

Good question, one which I don't yet have a definite answer for.

One of the problems we face is that with the kernel's mapping of SDRAM,
it is not easy to change or unmap sections of that mapping as it is
duplicated across every page table in the system - and with SMP systems
these page tables could well be in use on other processors.

The problem there is that dma_alloc_coherent() is supposed to work from
interrupt context - and we can't talk to the other processors from IRQ
context to ensure TLB coherence...

All very nasty.

> - Is it possible to get a memory area with memblock that would not be
> part of the kernel managed RAM?

SDRAM marked as reserved in memblock is still mapped - because reserved
memory contains things like the kernel, initial page table and such
like.  The other issue is that we map memory using 1MB sections, so
this memory which you want unmapped must be multiples of 1MB.

> - And generally, what would be the best way to handle this all? =)

We haven't got that far yet...

Re: DSS2 broken with 36-rc1

[Tomi Valkeinen]

On Mon, 2010-08-23 at 08:46 +0200, ext Mike Rapoport wrote:
> Hi Ameya,
> 
> Ameya Palande wrote:
> > Hi Tomi,
> > 
> > When I tried to boot 2.6.36-rc1 kernel on Nokia N900, omapfb failed with
> > following error messages:
> > 
> > [    0.124145] OMAP DSS rev 2.0
> > [    0.124237] OMAP DISPC rev 3.0
> > 
> > [    0.303833] acx565akm spi1.2: omapfb: acx565akm rev 8b LCD detected
> > 
> > [    0.805419] omapfb omapfb: failed to allocate framebuffer
> > [    0.810882] omapfb omapfb: failed to allocate fbmem
> > [    0.815856] omapfb omapfb: failed to setup omapfb
> > [    0.820648] omapfb: probe of omapfb failed with error -12

I tested 36-rc1 briefly with OMAP 3430SDP board. I wonder why that
works, but not N900...

Tomi

Re: DSS2 broken with 36-rc1

[Mike Rapoport]

Tomi Valkeinen wrote:
> On Mon, 2010-08-23 at 08:46 +0200, ext Mike Rapoport wrote:
>> Hi Ameya,
>>
>> Ameya Palande wrote:
>>> Hi Tomi,
>>>
>>> When I tried to boot 2.6.36-rc1 kernel on Nokia N900, omapfb failed with
>>> following error messages:
>>>
>>> [    0.124145] OMAP DSS rev 2.0
>>> [    0.124237] OMAP DISPC rev 3.0
>>>
>>> [    0.303833] acx565akm spi1.2: omapfb: acx565akm rev 8b LCD detected
>>>
>>> [    0.805419] omapfb omapfb: failed to allocate framebuffer
>>> [    0.810882] omapfb omapfb: failed to allocate fbmem
>>> [    0.815856] omapfb omapfb: failed to setup omapfb
>>> [    0.820648] omapfb: probe of omapfb failed with error -12
> 
> I tested 36-rc1 briefly with OMAP 3430SDP board. I wonder why that
> works, but not N900...

May it be that 3430SDP uses SRAM for the framebuffer? Or reserves framebuffer 
memory from the RAM that is not managed by the kernel, e.g with something like
mem=<RAM size - fb size> vram=<fb size>,0x8...... ?

> Tomi
> 
> 


-- 
Sincerely yours,
Mike.

Re: DSS2 broken with 36-rc1

[Tomi Valkeinen]

On Mon, 2010-08-23 at 09:19 +0200, ext Mike Rapoport wrote:
> Tomi Valkeinen wrote:
> > 
> > I tested 36-rc1 briefly with OMAP 3430SDP board. I wonder why that
> > works, but not N900...
> 
> May it be that 3430SDP uses SRAM for the framebuffer? Or reserves framebuffer 
> memory from the RAM that is not managed by the kernel, e.g with something like
> mem=<RAM size - fb size> vram=<fb size>,0x8...... ?

No, SRAM cannot be used on OMAP3s, as SRAM is too small to hold a
framebuffer. And no, I don't think it's reserving it from RAM not
managed by the kernel.

What is actually failing there? Looking at Ameya's original post, the
problem is in allocating the framebuffer. Your patch is doing something
_after_ the allocation has failed, so I don't see Ameya's problem having
anything to do with ioremap.

Ameya, you could try turning on the debugs in
drivers/video/omap2/vram.c, and checking what it says. Or see what is in
debugfs/vram file

 Tomi

Re: DSS2 broken with 36-rc1

[Mike Rapoport]

Tomi Valkeinen wrote:
> On Mon, 2010-08-23 at 09:19 +0200, ext Mike Rapoport wrote:
>> Tomi Valkeinen wrote:
>>> I tested 36-rc1 briefly with OMAP 3430SDP board. I wonder why that
>>> works, but not N900...
>> May it be that 3430SDP uses SRAM for the framebuffer? Or reserves framebuffer 
>> memory from the RAM that is not managed by the kernel, e.g with something like
>> mem=<RAM size - fb size> vram=<fb size>,0x8...... ?
> 
> No, SRAM cannot be used on OMAP3s, as SRAM is too small to hold a
> framebuffer. And no, I don't think it's reserving it from RAM not
> managed by the kernel.

The N900 only sets omap_vram_sdram_{start,size} in rx51_video_mem_init.
I think that it should also call omap_vram_reserve_sdram_memblock():

diff --git a/arch/arm/mach-omap2/board-rx51-video.c b/arch/arm/mach-omap2/board-rx51-video.c
index 5a1005b..fdfe844 100644
--- a/arch/arm/mach-omap2/board-rx51-video.c
+++ b/arch/arm/mach-omap2/board-rx51-video.c
@@ -101,6 +101,7 @@ void __init rx51_video_mem_init(void)
          */
         omap_vram_set_sdram_vram(PAGE_ALIGN(864 * 480 * 4) +
                         2 * PAGE_ALIGN(1280 * 720 * 4 * 2), 0);
+       omap_vram_reserve_sdram_memblock();
  }

  #else


> What is actually failing there? Looking at Ameya's original post, the
> problem is in allocating the framebuffer. Your patch is doing something
> _after_ the allocation has failed, so I don't see Ameya's problem having
> anything to do with ioremap.

You are right, I've misread the Ameya's original post. I'm fixing another problem:

OMAPFB: omapfb_init
OMAPFB: omapfb_probe
OMAPFB: create 3 framebuffers
OMAPFB: fb_infos allocated
OMAPFB: allocating 614400 bytes for fb 0
VRAM: alloc mem type 0 size 614400
VRAM: checking region 8f000000 4096
VRAM: found 8f000000, end 90000000
------------[ cut here ]------------
WARNING: at arch/arm/mm/ioremap.c:207 __arm_ioremap_pfn_caller+0x48/0x18c()

Modules linked in:
[<c004e458>] (unwind_backtrace+0x0/0xec) from [<c007dfe8>] (warn_slowpath_common+0x4c/0x64)
[<c007dfe8>] (warn_slowpath_common+0x4c/0x64) from [<c007e018>] (warn_slowpath_null+0x18/0x1c)
[<c007e018>] (warn_slowpath_null+0x18/0x1c) from [<c00500c8>] (__arm_ioremap_pfn_caller+0x48/0x18c)
[<c00500c8>] (__arm_ioremap_pfn_caller+0x48/0x18c) from [<c0050270>] (__arm_ioremap_caller+0x54/0x58)
[<c0050270>] (__arm_ioremap_caller+0x54/0x58) from [<c02561e0>] (omapfb_alloc_fbmem+0xf0/0x19c)
[<c02561e0>] (omapfb_alloc_fbmem+0xf0/0x19c) from [<c0257584>] (omapfb_allocate_all_fbs+0x2b8/0x34c)
[<c0257584>] (omapfb_allocate_all_fbs+0x2b8/0x34c) from [<c0257a80>] (omapfb_probe+0x468/0x8dc)
[<c0257a80>] (omapfb_probe+0x468/0x8dc) from [<c028330c>] (platform_drv_probe+0x18/0x1c)
[<c028330c>] (platform_drv_probe+0x18/0x1c) from [<c0282344>] (driver_probe_device+0xc8/0x184)
[<c0282344>] (driver_probe_device+0xc8/0x184) from [<c0282468>] (__driver_attach+0x68/0x8c)
[<c0282468>] (__driver_attach+0x68/0x8c) from [<c0281afc>] (bus_for_each_dev+0x44/0x74)
[<c0281afc>] (bus_for_each_dev+0x44/0x74) from [<c0281438>] (bus_add_driver+0x100/0x288)
[<c0281438>] (bus_add_driver+0x100/0x288) from [<c028275c>] (driver_register+0xa8/0x134)
[<c028275c>] (driver_register+0xa8/0x134) from [<c0022b34>] (omapfb_init+0x24/0x4c)
[<c0022b34>] (omapfb_init+0x24/0x4c) from [<c00483ac>] (do_one_initcall+0xbc/0x194)
[<c00483ac>] (do_one_initcall+0xbc/0x194) from [<c0008574>] (kernel_init+0x94/0x14c)
[<c0008574>] (kernel_init+0x94/0x14c) from [<c0049930>] (kernel_thread_exit+0x0/0x8)
---[ end trace 1b75b31a2719ed1f ]---
omapfb omapfb: failed to ioremap framebuffer
VRAM: free mem paddr 8f000000 size 614400
omapfb omapfb: failed to allocate fbmem
OMAPFB: free_resources
OMAPFB: free all fbmem
omapfb omapfb: failed to setup omapfb
omapfb: probe of omapfb failed with error -12

> Ameya, you could try turning on the debugs in
> drivers/video/omap2/vram.c, and checking what it says. Or see what is in
> debugfs/vram file
> 
>  Tomi
> 
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html


-- 
Sincerely yours,
Mike.

Re: DSS2 broken with 36-rc1

[Tomi Valkeinen]

On Mon, 2010-08-23 at 10:51 +0200, ext Mike Rapoport wrote:
> Tomi Valkeinen wrote:
> > On Mon, 2010-08-23 at 09:19 +0200, ext Mike Rapoport wrote:
> >> Tomi Valkeinen wrote:
> >>> I tested 36-rc1 briefly with OMAP 3430SDP board. I wonder why that
> >>> works, but not N900...
> >> May it be that 3430SDP uses SRAM for the framebuffer? Or reserves framebuffer 
> >> memory from the RAM that is not managed by the kernel, e.g with something like
> >> mem=<RAM size - fb size> vram=<fb size>,0x8...... ?
> > 
> > No, SRAM cannot be used on OMAP3s, as SRAM is too small to hold a
> > framebuffer. And no, I don't think it's reserving it from RAM not
> > managed by the kernel.
> 
> The N900 only sets omap_vram_sdram_{start,size} in rx51_video_mem_init.
> I think that it should also call omap_vram_reserve_sdram_memblock():
> 
> diff --git a/arch/arm/mach-omap2/board-rx51-video.c b/arch/arm/mach-omap2/board-rx51-video.c
> index 5a1005b..fdfe844 100644
> --- a/arch/arm/mach-omap2/board-rx51-video.c
> +++ b/arch/arm/mach-omap2/board-rx51-video.c
> @@ -101,6 +101,7 @@ void __init rx51_video_mem_init(void)
>           */
>          omap_vram_set_sdram_vram(PAGE_ALIGN(864 * 480 * 4) +
>                          2 * PAGE_ALIGN(1280 * 720 * 4 * 2), 0);
> +       omap_vram_reserve_sdram_memblock();
>   }

But omap_vram_reserve_sdram_memblock() is called automatically from
arch/arm/plat-omap/common.c. rx51_video_mem_init() should have been
called before that happens. Has the call order changed, so that
omap_vram_reserve_sdram_memblock() is called first, and
rx51_video_mem_init() only after that?

 Tomi

Re: DSS2 broken with 36-rc1

[Felipe Contreras]

On Wed, Aug 25, 2010 at 11:09 AM, Tomi Valkeinen
<tomi.valkeinen@nokia.com> wrote:
> On Mon, 2010-08-23 at 10:51 +0200, ext Mike Rapoport wrote:
>> Tomi Valkeinen wrote:
>> > On Mon, 2010-08-23 at 09:19 +0200, ext Mike Rapoport wrote:
>> >> Tomi Valkeinen wrote:
>> >>> I tested 36-rc1 briefly with OMAP 3430SDP board. I wonder why that
>> >>> works, but not N900...
>> >> May it be that 3430SDP uses SRAM for the framebuffer? Or reserves framebuffer
>> >> memory from the RAM that is not managed by the kernel, e.g with something like
>> >> mem=<RAM size - fb size> vram=<fb size>,0x8...... ?
>> >
>> > No, SRAM cannot be used on OMAP3s, as SRAM is too small to hold a
>> > framebuffer. And no, I don't think it's reserving it from RAM not
>> > managed by the kernel.
>>
>> The N900 only sets omap_vram_sdram_{start,size} in rx51_video_mem_init.
>> I think that it should also call omap_vram_reserve_sdram_memblock():
>>
>> diff --git a/arch/arm/mach-omap2/board-rx51-video.c b/arch/arm/mach-omap2/board-rx51-video.c
>> index 5a1005b..fdfe844 100644
>> --- a/arch/arm/mach-omap2/board-rx51-video.c
>> +++ b/arch/arm/mach-omap2/board-rx51-video.c
>> @@ -101,6 +101,7 @@ void __init rx51_video_mem_init(void)
>>           */
>>          omap_vram_set_sdram_vram(PAGE_ALIGN(864 * 480 * 4) +
>>                          2 * PAGE_ALIGN(1280 * 720 * 4 * 2), 0);
>> +       omap_vram_reserve_sdram_memblock();
>>   }
>
> But omap_vram_reserve_sdram_memblock() is called automatically from
> arch/arm/plat-omap/common.c. rx51_video_mem_init() should have been
> called before that happens. Has the call order changed, so that
> omap_vram_reserve_sdram_memblock() is called first, and
> rx51_video_mem_init() only after that?

That is indeed the case, ->reserve() is now called way earlier in the
boot process, before early param, and before ->map_io(), which is a
good thing, because now ->reserve() can take away the memory from the
kernel.

I'm sending the patches that fix this for me, you would also need:
http://article.gmane.org/gmane.linux.kernel/1047146

-- 
Felipe Contreras
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 1/2] video: omap: vram: remove from normal memory

[Felipe Contreras]

So that we can ioremap happily.

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

diff --git a/drivers/video/omap2/vram.c b/drivers/video/omap2/vram.c
index f6fdc20..1a99777 100644
--- a/drivers/video/omap2/vram.c
+++ b/drivers/video/omap2/vram.c
@@ -575,6 +575,8 @@ void __init omap_vram_reserve_sdram_memblock(void)
 		}
 	} else {
 		paddr = memblock_alloc_base(size, PAGE_SIZE, MEMBLOCK_REAL_LIMIT);
+		memblock_free(paddr, size);
+		memblock_remove(paddr, size);
 	}
 
 	omap_vram_add_region(paddr, size);
-- 
1.7.3.1.2.g7fe2b

[PATCH 1/2] video: omap: vram: remove from normal memory

[Felipe Contreras]

So that we can ioremap happily.

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

diff --git a/drivers/video/omap2/vram.c b/drivers/video/omap2/vram.c
index f6fdc20..1a99777 100644
--- a/drivers/video/omap2/vram.c
+++ b/drivers/video/omap2/vram.c
@@ -575,6 +575,8 @@ void __init omap_vram_reserve_sdram_memblock(void)
 		}
 	} else {
 		paddr = memblock_alloc_base(size, PAGE_SIZE, MEMBLOCK_REAL_LIMIT);
+		memblock_free(paddr, size);
+		memblock_remove(paddr, size);
 	}
 
 	omap_vram_add_region(paddr, size);
-- 
1.7.3.1.2.g7fe2b

Re: [PATCH 1/2] video: omap: vram: remove from normal memory

[Tomi Valkeinen]

Hi,

On Fri, 2010-10-15 at 14:46 +0200, ext Felipe Contreras wrote:
> So that we can ioremap happily.
> 
> Cc: Tomi Valkeinen <tomi.valkeinen@nokia.com>
> Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
> ---
>  drivers/video/omap2/vram.c |    2 ++
>  1 files changed, 2 insertions(+), 0 deletions(-)
> 
> diff --git a/drivers/video/omap2/vram.c b/drivers/video/omap2/vram.c
> index f6fdc20..1a99777 100644
> --- a/drivers/video/omap2/vram.c
> +++ b/drivers/video/omap2/vram.c
> @@ -575,6 +575,8 @@ void __init omap_vram_reserve_sdram_memblock(void)
>  		}
>  	} else {
>  		paddr = memblock_alloc_base(size, PAGE_SIZE, MEMBLOCK_REAL_LIMIT);
> +		memblock_free(paddr, size);
> +		memblock_remove(paddr, size);
>  	}
>  
>  	omap_vram_add_region(paddr, size);

I tested this on OMAP3 SDP board, on top of my DSS2 tree. I can boot up
fine, but my test program crashes the kernel (dump below).

This crash doesn't happen if I have the "HACK: OMAP: DSS2: OMAPFB: use
phys_to_virt for RAM mappings" patch in (I removed that during testing
this patch).

I don't know yet what is crashing the kernel, but I'd guess it's the
fact that my test program reallocates the framebuffer memory with
OMAPFB_SETUP_MEM ioctl.

 Tomi


[   53.131591] Unable to handle kernel NULL pointer dereference at virtual address 00000048
[   53.140350] pgd = c7038000
[   53.143096] [00000048] *pgd=87058031, *pte=00000000, *ppte=00000000
[   53.149749] Internal error: Oops: 17 [#1]
[   53.153808] last sysfs file: /sys/devices/platform/serial8250.2/sleep_timeout
[   53.161010] Modules linked in:
[   53.164123] CPU: 0    Tainted: G        W    (2.6.36-rc8-00016-g0897fa9 #1216)
[   53.171417] PC is at filemap_fault+0x2c/0x380
[   53.175842] LR is at __do_fault+0x50/0x41c
[   53.179962] pc : [<c00d8d90>]    lr : [<c00ee2e4>]    psr: a0000113
[   53.179992] sp : c7ff9db8  ip : 00000062  fp : c7fce040
[   53.191528] r10: c7fce040  r9 : c796ee18  r8 : 00000062
[   53.196807] r7 : 00000000  r6 : c7fcd280  r5 : c7fe68a0  r4 : c704ac28
[   53.203369] r3 : 00000000  r2 : 00000fff  r1 : 00000000  r0 : c704ac28
[   53.209960] Flags: NzCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment user
[   53.217163] Control: 10c5387d  Table: 87038019  DAC: 00000015
[   53.222961] Process db (pid: 649, stack limit = 0xc7ff82f0)
[   53.228576] Stack: (0xc7ff9db8 to 0xc7ffa000)
[   53.232971] 9da0:                                                       00000183 00000001
[   53.241241] 9dc0: c7ff9e00 00000000 00000001 c7039008 c7fe68a0 00000000 00000000 c704ac28
[   53.249481] 9de0: 40228000 c7fce040 c7fce040 c00ee2e4 40228000 00000000 c0481e04 c02283b8
[   53.257720] 9e00: 00000000 00000062 40228000 00000000 60000113 c7fe6800 c7fe68a0 c7ff9fb0
[   53.265960] 9e20: 00000000 c704ac28 40228000 c7fce040 c7038000 c00ef750 00000062 00000000
[   53.274200] 9e40: 00000000 60000113 c04845e4 00000028 00000201 00000000 000000a0 c7039008
[   53.282470] 9e60: c7fce040 c7ff3080 80000007 c704ac28 00000005 c7ff9fb0 40228ef4 c7fce074
[   53.290710] 9e80: c7fce040 c7ff3080 80000007 c0484684 00000000 87600000 004b0000 00000000
[   53.298950] 9ea0: 00000000 00000002 00010001 00000000 00000780 00000000 00000000 00000000
[   53.307189] 9ec0: 00000000 00000000 00000000 c7feb000 00000000 c7feb000 ffffff9c 00000000
[   53.315429] 9ee0: 60000013 00000000 00000000 c0630d64 00000005 00000007 c7ff9fb0 40228ef4
[   53.323669] 9f00: 402e3600 400922c0 bea93a8c c00451fc 00000003 00000003 bea93c3c c01117f0
[   53.331909] 9f20: 00000000 c0111ef4 00000000 00000000 00000000 00000000 c7ff3080 c00a8030
[   53.340179] 9f40: c7ff3080 c0100b90 60000013 c7feb000 c0102b10 c00a7f5c c7c05bc0 c7c0ed40
[   53.348419] 9f60: 60000013 c0100b90 00000000 bea93c3c c7ff3080 c0482cc4 00000000 00000001
[   53.356658] 9f80: 402e4008 c00a7f5c c07fdf68 00000005 00000000 c0482cc4 c07fdf68 00000005
[   53.364898] 9fa0: 00000000 00000001 402e4008 c0482cd4 402e3600 000095b8 00000005 402e2c68
[   53.373138] 9fc0: 00000000 00000005 00000000 00000001 402e4008 402e3600 400922c0 bea93a8c
[   53.381378] 9fe0: 402e3000 bea934e0 402022e0 40228ef4 60000010 ffffffff 00000000 00000000
[   53.389678] [<c00d8d90>] (filemap_fault+0x2c/0x380) from [<c00ee2e4>] (__do_fault+0x50/0x41c)
[   53.398284] [<c00ee2e4>] (__do_fault+0x50/0x41c) from [<c00ef750>] (handle_mm_fault+0x31c/0x760)
[   53.407165] [<c00ef750>] (handle_mm_fault+0x31c/0x760) from [<c0484684>] (do_page_fault+0x124/0x2
c0)
[   53.416381] [<c0484684>] (do_page_fault+0x124/0x2c0) from [<c00451fc>] (do_PrefetchAbort+0x34/0x9
4)
[   53.425567] [<c00451fc>] (do_PrefetchAbort+0x34/0x94) from [<c0482cd4>] (ret_from_exception+0x0/0
x10)
[   53.434844] Exception stack(0xc7ff9fb0 to 0xc7ff9ff8)
[   53.439941] 9fa0:                                     402e3600 000095b8 00000005 402e2c68
[   53.448181] 9fc0: 00000000 00000005 00000000 00000001 402e4008 402e3600 400922c0 bea93a8c
[   53.456420] 9fe0: 402e3000 bea934e0 402022e0 40228ef4 60000010 ffffffff
[   53.463104] Code: e59f2348 e5991000 e3a03000 e58d100c (e1c104d8) 
[   53.469482] ---[ end trace fe98055867aed1db ]---
[   59.962432] BUG: spinlock lockup on CPU#0, db/649, c796c378
[   59.968231] [<c004b5b4>] (unwind_backtrace+0x0/0xec) from [<c022e9a4>] (do_raw_spin_lock+0x110/0x
14c)
[   59.977722] [<c022e9a4>] (do_raw_spin_lock+0x110/0x14c) from [<c0481c84>] (_raw_spin_lock+0x5c/0x
70)
[   59.987121] [<c0481c84>] (_raw_spin_lock+0x5c/0x70) from [<c00f3c54>] (unlink_file_vma+0x24/0x40)
[   59.996246] [<c00f3c54>] (unlink_file_vma+0x24/0x40) from [<c00f1aa0>] (free_pgtables+0x60/0x9c)
[   60.005279] [<c00f1aa0>] (free_pgtables+0x60/0x9c) from [<c00f37b4>] (exit_mmap+0xc8/0x160)
[   60.013885] [<c00f37b4>] (exit_mmap+0xc8/0x160) from [<c0079728>] (mmput+0x48/0x104)
[   60.021850] [<c0079728>] (mmput+0x48/0x104) from [<c007d4a8>] (exit_mm+0x120/0x128)
[   60.029754] [<c007d4a8>] (exit_mm+0x120/0x128) from [<c007edc0>] (do_exit+0x198/0x620)
[   60.037902] [<c007edc0>] (do_exit+0x198/0x620) from [<c0049750>] (die+0x2c8/0x30c)
[   60.045715] [<c0049750>] (die+0x2c8/0x30c) from [<c004c6b0>] (__do_kernel_fault+0x64/0x84)
[   60.054229] [<c004c6b0>] (__do_kernel_fault+0x64/0x84) from [<c04847f4>] (do_page_fault+0x294/0x2
c0)
[   60.063598] [<c04847f4>] (do_page_fault+0x294/0x2c0) from [<c0045290>] (do_DataAbort+0x34/0x94)
[   60.072570] [<c0045290>] (do_DataAbort+0x34/0x94) from [<c04826f4>] (__dabt_svc+0x54/0x80)
[   60.081054] Exception stack(0xc7ff9d70 to 0xc7ff9db8)
[   60.086273] 9d60:                                     c704ac28 00000000 00000fff 00000000
[   60.094665] 9d80: c704ac28 c7fe68a0 c7fcd280 00000000 00000062 c796ee18 c7fce040 c7fce040
[   60.103027] 9da0: 00000062 c7ff9db8 c00ee2e4 c00d8d90 a0000113 ffffffff
[   60.109863] [<c04826f4>] (__dabt_svc+0x54/0x80) from [<c00d8d90>] (filemap_fault+0x2c/0x380)
[   60.118560] [<c00d8d90>] (filemap_fault+0x2c/0x380) from [<c00ee2e4>] (__do_fault+0x50/0x41c)
[   60.127319] [<c00ee2e4>] (__do_fault+0x50/0x41c) from [<c00ef750>] (handle_mm_fault+0x31c/0x760)
[   60.136352] [<c00ef750>] (handle_mm_fault+0x31c/0x760) from [<c0484684>] (do_page_fault+0x124/0x2
c0)
[   60.145751] [<c0484684>] (do_page_fault+0x124/0x2c0) from [<c00451fc>] (do_PrefetchAbort+0x34/0x9
4)
[   60.155059] [<c00451fc>] (do_PrefetchAbort+0x34/0x94) from [<c0482cd4>] (ret_from_exception+0x0/0
x10)
[   60.164520] Exception stack(0xc7ff9fb0 to 0xc7ff9ff8)
[   60.169738] 9fa0:                                     402e3600 000095b8 00000005 402e2c68
[   60.178131] 9fc0: 00000000 00000005 00000000 00000001 402e4008 402e3600 400922c0 bea93a8c
[   60.186492] 9fe0: 402e3000 bea934e0 402022e0 40228ef4 60000010 ffffffff
û



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

[PATCH 1/2] video: omap: vram: remove from normal memory

[Tomi Valkeinen]

Hi,

On Fri, 2010-10-15 at 14:46 +0200, ext Felipe Contreras wrote:
> So that we can ioremap happily.
> 
> Cc: Tomi Valkeinen <tomi.valkeinen@nokia.com>
> Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
> ---
>  drivers/video/omap2/vram.c |    2 ++
>  1 files changed, 2 insertions(+), 0 deletions(-)
> 
> diff --git a/drivers/video/omap2/vram.c b/drivers/video/omap2/vram.c
> index f6fdc20..1a99777 100644
> --- a/drivers/video/omap2/vram.c
> +++ b/drivers/video/omap2/vram.c
> @@ -575,6 +575,8 @@ void __init omap_vram_reserve_sdram_memblock(void)
>  		}
>  	} else {
>  		paddr = memblock_alloc_base(size, PAGE_SIZE, MEMBLOCK_REAL_LIMIT);
> +		memblock_free(paddr, size);
> +		memblock_remove(paddr, size);
>  	}
>  
>  	omap_vram_add_region(paddr, size);

I tested this on OMAP3 SDP board, on top of my DSS2 tree. I can boot up
fine, but my test program crashes the kernel (dump below).

This crash doesn't happen if I have the "HACK: OMAP: DSS2: OMAPFB: use
phys_to_virt for RAM mappings" patch in (I removed that during testing
this patch).

I don't know yet what is crashing the kernel, but I'd guess it's the
fact that my test program reallocates the framebuffer memory with
OMAPFB_SETUP_MEM ioctl.

 Tomi


[   53.131591] Unable to handle kernel NULL pointer dereference at virtual address 00000048
[   53.140350] pgd = c7038000
[   53.143096] [00000048] *pgd=87058031, *pte=00000000, *ppte=00000000
[   53.149749] Internal error: Oops: 17 [#1]
[   53.153808] last sysfs file: /sys/devices/platform/serial8250.2/sleep_timeout
[   53.161010] Modules linked in:
[   53.164123] CPU: 0    Tainted: G        W    (2.6.36-rc8-00016-g0897fa9 #1216)
[   53.171417] PC is at filemap_fault+0x2c/0x380
[   53.175842] LR is at __do_fault+0x50/0x41c
[   53.179962] pc : [<c00d8d90>]    lr : [<c00ee2e4>]    psr: a0000113
[   53.179992] sp : c7ff9db8  ip : 00000062  fp : c7fce040
[   53.191528] r10: c7fce040  r9 : c796ee18  r8 : 00000062
[   53.196807] r7 : 00000000  r6 : c7fcd280  r5 : c7fe68a0  r4 : c704ac28
[   53.203369] r3 : 00000000  r2 : 00000fff  r1 : 00000000  r0 : c704ac28
[   53.209960] Flags: NzCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment user
[   53.217163] Control: 10c5387d  Table: 87038019  DAC: 00000015
[   53.222961] Process db (pid: 649, stack limit = 0xc7ff82f0)
[   53.228576] Stack: (0xc7ff9db8 to 0xc7ffa000)
[   53.232971] 9da0:                                                       00000183 00000001
[   53.241241] 9dc0: c7ff9e00 00000000 00000001 c7039008 c7fe68a0 00000000 00000000 c704ac28
[   53.249481] 9de0: 40228000 c7fce040 c7fce040 c00ee2e4 40228000 00000000 c0481e04 c02283b8
[   53.257720] 9e00: 00000000 00000062 40228000 00000000 60000113 c7fe6800 c7fe68a0 c7ff9fb0
[   53.265960] 9e20: 00000000 c704ac28 40228000 c7fce040 c7038000 c00ef750 00000062 00000000
[   53.274200] 9e40: 00000000 60000113 c04845e4 00000028 00000201 00000000 000000a0 c7039008
[   53.282470] 9e60: c7fce040 c7ff3080 80000007 c704ac28 00000005 c7ff9fb0 40228ef4 c7fce074
[   53.290710] 9e80: c7fce040 c7ff3080 80000007 c0484684 00000000 87600000 004b0000 00000000
[   53.298950] 9ea0: 00000000 00000002 00010001 00000000 00000780 00000000 00000000 00000000
[   53.307189] 9ec0: 00000000 00000000 00000000 c7feb000 00000000 c7feb000 ffffff9c 00000000
[   53.315429] 9ee0: 60000013 00000000 00000000 c0630d64 00000005 00000007 c7ff9fb0 40228ef4
[   53.323669] 9f00: 402e3600 400922c0 bea93a8c c00451fc 00000003 00000003 bea93c3c c01117f0
[   53.331909] 9f20: 00000000 c0111ef4 00000000 00000000 00000000 00000000 c7ff3080 c00a8030
[   53.340179] 9f40: c7ff3080 c0100b90 60000013 c7feb000 c0102b10 c00a7f5c c7c05bc0 c7c0ed40
[   53.348419] 9f60: 60000013 c0100b90 00000000 bea93c3c c7ff3080 c0482cc4 00000000 00000001
[   53.356658] 9f80: 402e4008 c00a7f5c c07fdf68 00000005 00000000 c0482cc4 c07fdf68 00000005
[   53.364898] 9fa0: 00000000 00000001 402e4008 c0482cd4 402e3600 000095b8 00000005 402e2c68
[   53.373138] 9fc0: 00000000 00000005 00000000 00000001 402e4008 402e3600 400922c0 bea93a8c
[   53.381378] 9fe0: 402e3000 bea934e0 402022e0 40228ef4 60000010 ffffffff 00000000 00000000
[   53.389678] [<c00d8d90>] (filemap_fault+0x2c/0x380) from [<c00ee2e4>] (__do_fault+0x50/0x41c)
[   53.398284] [<c00ee2e4>] (__do_fault+0x50/0x41c) from [<c00ef750>] (handle_mm_fault+0x31c/0x760)
[   53.407165] [<c00ef750>] (handle_mm_fault+0x31c/0x760) from [<c0484684>] (do_page_fault+0x124/0x2
c0)
[   53.416381] [<c0484684>] (do_page_fault+0x124/0x2c0) from [<c00451fc>] (do_PrefetchAbort+0x34/0x9
4)
[   53.425567] [<c00451fc>] (do_PrefetchAbort+0x34/0x94) from [<c0482cd4>] (ret_from_exception+0x0/0
x10)
[   53.434844] Exception stack(0xc7ff9fb0 to 0xc7ff9ff8)
[   53.439941] 9fa0:                                     402e3600 000095b8 00000005 402e2c68
[   53.448181] 9fc0: 00000000 00000005 00000000 00000001 402e4008 402e3600 400922c0 bea93a8c
[   53.456420] 9fe0: 402e3000 bea934e0 402022e0 40228ef4 60000010 ffffffff
[   53.463104] Code: e59f2348 e5991000 e3a03000 e58d100c (e1c104d8) 
[   53.469482] ---[ end trace fe98055867aed1db ]---
[   59.962432] BUG: spinlock lockup on CPU#0, db/649, c796c378
[   59.968231] [<c004b5b4>] (unwind_backtrace+0x0/0xec) from [<c022e9a4>] (do_raw_spin_lock+0x110/0x
14c)
[   59.977722] [<c022e9a4>] (do_raw_spin_lock+0x110/0x14c) from [<c0481c84>] (_raw_spin_lock+0x5c/0x
70)
[   59.987121] [<c0481c84>] (_raw_spin_lock+0x5c/0x70) from [<c00f3c54>] (unlink_file_vma+0x24/0x40)
[   59.996246] [<c00f3c54>] (unlink_file_vma+0x24/0x40) from [<c00f1aa0>] (free_pgtables+0x60/0x9c)
[   60.005279] [<c00f1aa0>] (free_pgtables+0x60/0x9c) from [<c00f37b4>] (exit_mmap+0xc8/0x160)
[   60.013885] [<c00f37b4>] (exit_mmap+0xc8/0x160) from [<c0079728>] (mmput+0x48/0x104)
[   60.021850] [<c0079728>] (mmput+0x48/0x104) from [<c007d4a8>] (exit_mm+0x120/0x128)
[   60.029754] [<c007d4a8>] (exit_mm+0x120/0x128) from [<c007edc0>] (do_exit+0x198/0x620)
[   60.037902] [<c007edc0>] (do_exit+0x198/0x620) from [<c0049750>] (die+0x2c8/0x30c)
[   60.045715] [<c0049750>] (die+0x2c8/0x30c) from [<c004c6b0>] (__do_kernel_fault+0x64/0x84)
[   60.054229] [<c004c6b0>] (__do_kernel_fault+0x64/0x84) from [<c04847f4>] (do_page_fault+0x294/0x2
c0)
[   60.063598] [<c04847f4>] (do_page_fault+0x294/0x2c0) from [<c0045290>] (do_DataAbort+0x34/0x94)
[   60.072570] [<c0045290>] (do_DataAbort+0x34/0x94) from [<c04826f4>] (__dabt_svc+0x54/0x80)
[   60.081054] Exception stack(0xc7ff9d70 to 0xc7ff9db8)
[   60.086273] 9d60:                                     c704ac28 00000000 00000fff 00000000
[   60.094665] 9d80: c704ac28 c7fe68a0 c7fcd280 00000000 00000062 c796ee18 c7fce040 c7fce040
[   60.103027] 9da0: 00000062 c7ff9db8 c00ee2e4 c00d8d90 a0000113 ffffffff
[   60.109863] [<c04826f4>] (__dabt_svc+0x54/0x80) from [<c00d8d90>] (filemap_fault+0x2c/0x380)
[   60.118560] [<c00d8d90>] (filemap_fault+0x2c/0x380) from [<c00ee2e4>] (__do_fault+0x50/0x41c)
[   60.127319] [<c00ee2e4>] (__do_fault+0x50/0x41c) from [<c00ef750>] (handle_mm_fault+0x31c/0x760)
[   60.136352] [<c00ef750>] (handle_mm_fault+0x31c/0x760) from [<c0484684>] (do_page_fault+0x124/0x2
c0)
[   60.145751] [<c0484684>] (do_page_fault+0x124/0x2c0) from [<c00451fc>] (do_PrefetchAbort+0x34/0x9
4)
[   60.155059] [<c00451fc>] (do_PrefetchAbort+0x34/0x94) from [<c0482cd4>] (ret_from_exception+0x0/0
x10)
[   60.164520] Exception stack(0xc7ff9fb0 to 0xc7ff9ff8)
[   60.169738] 9fa0:                                     402e3600 000095b8 00000005 402e2c68
[   60.178131] 9fc0: 00000000 00000005 00000000 00000001 402e4008 402e3600 400922c0 bea93a8c
[   60.186492] 9fe0: 402e3000 bea934e0 402022e0 40228ef4 60000010 ffffffff
?

Re: [PATCH 1/2] video: omap: vram: remove from normal memory

[Tomi Valkeinen]

On Mon, 2010-10-18 at 16:10 +0300, Tomi Valkeinen wrote:
> Hi,
> 
> On Fri, 2010-10-15 at 14:46 +0200, ext Felipe Contreras wrote:
> > So that we can ioremap happily.
> > 
> > Cc: Tomi Valkeinen <tomi.valkeinen@nokia.com>
> > Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
> > ---
> >  drivers/video/omap2/vram.c |    2 ++
> >  1 files changed, 2 insertions(+), 0 deletions(-)
> > 
> > diff --git a/drivers/video/omap2/vram.c b/drivers/video/omap2/vram.c
> > index f6fdc20..1a99777 100644
> > --- a/drivers/video/omap2/vram.c
> > +++ b/drivers/video/omap2/vram.c
> > @@ -575,6 +575,8 @@ void __init omap_vram_reserve_sdram_memblock(void)
> >  		}
> >  	} else {
> >  		paddr = memblock_alloc_base(size, PAGE_SIZE, MEMBLOCK_REAL_LIMIT);
> > +		memblock_free(paddr, size);
> > +		memblock_remove(paddr, size);
> >  	}
> >  
> >  	omap_vram_add_region(paddr, size);
> 
> I tested this on OMAP3 SDP board, on top of my DSS2 tree. I can boot up
> fine, but my test program crashes the kernel (dump below).
> 
> This crash doesn't happen if I have the "HACK: OMAP: DSS2: OMAPFB: use
> phys_to_virt for RAM mappings" patch in (I removed that during testing
> this patch).
> 
> I don't know yet what is crashing the kernel, but I'd guess it's the
> fact that my test program reallocates the framebuffer memory with
> OMAPFB_SETUP_MEM ioctl.

Ah, sorry, I was missing the patch from Russel which you mentioned in
another mail (http://article.gmane.org/gmane.linux.kernel/1047146). With
that patch included things seem to work.

 Tomi

[PATCH 1/2] video: omap: vram: remove from normal memory

[Tomi Valkeinen]

On Mon, 2010-10-18 at 16:10 +0300, Tomi Valkeinen wrote:
> Hi,
> 
> On Fri, 2010-10-15 at 14:46 +0200, ext Felipe Contreras wrote:
> > So that we can ioremap happily.
> > 
> > Cc: Tomi Valkeinen <tomi.valkeinen@nokia.com>
> > Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
> > ---
> >  drivers/video/omap2/vram.c |    2 ++
> >  1 files changed, 2 insertions(+), 0 deletions(-)
> > 
> > diff --git a/drivers/video/omap2/vram.c b/drivers/video/omap2/vram.c
> > index f6fdc20..1a99777 100644
> > --- a/drivers/video/omap2/vram.c
> > +++ b/drivers/video/omap2/vram.c
> > @@ -575,6 +575,8 @@ void __init omap_vram_reserve_sdram_memblock(void)
> >  		}
> >  	} else {
> >  		paddr = memblock_alloc_base(size, PAGE_SIZE, MEMBLOCK_REAL_LIMIT);
> > +		memblock_free(paddr, size);
> > +		memblock_remove(paddr, size);
> >  	}
> >  
> >  	omap_vram_add_region(paddr, size);
> 
> I tested this on OMAP3 SDP board, on top of my DSS2 tree. I can boot up
> fine, but my test program crashes the kernel (dump below).
> 
> This crash doesn't happen if I have the "HACK: OMAP: DSS2: OMAPFB: use
> phys_to_virt for RAM mappings" patch in (I removed that during testing
> this patch).
> 
> I don't know yet what is crashing the kernel, but I'd guess it's the
> fact that my test program reallocates the framebuffer memory with
> OMAPFB_SETUP_MEM ioctl.

Ah, sorry, I was missing the patch from Russel which you mentioned in
another mail (http://article.gmane.org/gmane.linux.kernel/1047146). With
that patch included things seem to work.

 Tomi

Re: [PATCH 1/2] video: omap: vram: remove from normal memory

[Tony Lindgren]

* Tomi Valkeinen <tomi.valkeinen@nokia.com> [101018 06:55]:
> On Mon, 2010-10-18 at 16:10 +0300, Tomi Valkeinen wrote:
> > Hi,
> > 
> > On Fri, 2010-10-15 at 14:46 +0200, ext Felipe Contreras wrote:
> > > So that we can ioremap happily.
> > > 
> > > Cc: Tomi Valkeinen <tomi.valkeinen@nokia.com>
> > > Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
> > > ---
> > >  drivers/video/omap2/vram.c |    2 ++
> > >  1 files changed, 2 insertions(+), 0 deletions(-)
> > > 
> > > diff --git a/drivers/video/omap2/vram.c b/drivers/video/omap2/vram.c
> > > index f6fdc20..1a99777 100644
> > > --- a/drivers/video/omap2/vram.c
> > > +++ b/drivers/video/omap2/vram.c
> > > @@ -575,6 +575,8 @@ void __init omap_vram_reserve_sdram_memblock(void)
> > >  		}
> > >  	} else {
> > >  		paddr = memblock_alloc_base(size, PAGE_SIZE, MEMBLOCK_REAL_LIMIT);
> > > +		memblock_free(paddr, size);
> > > +		memblock_remove(paddr, size);
> > >  	}
> > >  
> > >  	omap_vram_add_region(paddr, size);
> > 
> > I tested this on OMAP3 SDP board, on top of my DSS2 tree. I can boot up
> > fine, but my test program crashes the kernel (dump below).
> > 
> > This crash doesn't happen if I have the "HACK: OMAP: DSS2: OMAPFB: use
> > phys_to_virt for RAM mappings" patch in (I removed that during testing
> > this patch).
> > 
> > I don't know yet what is crashing the kernel, but I'd guess it's the
> > fact that my test program reallocates the framebuffer memory with
> > OMAPFB_SETUP_MEM ioctl.
> 
> Ah, sorry, I was missing the patch from Russel which you mentioned in
> another mail (http://article.gmane.org/gmane.linux.kernel/1047146). With
> that patch included things seem to work.

Tomi, I assume you're queuing these? If so, for both:

Acked-by: Tony Lindgren <tony@atomide.com>

[PATCH 1/2] video: omap: vram: remove from normal memory

[Tony Lindgren]

* Tomi Valkeinen <tomi.valkeinen@nokia.com> [101018 06:55]:
> On Mon, 2010-10-18 at 16:10 +0300, Tomi Valkeinen wrote:
> > Hi,
> > 
> > On Fri, 2010-10-15 at 14:46 +0200, ext Felipe Contreras wrote:
> > > So that we can ioremap happily.
> > > 
> > > Cc: Tomi Valkeinen <tomi.valkeinen@nokia.com>
> > > Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
> > > ---
> > >  drivers/video/omap2/vram.c |    2 ++
> > >  1 files changed, 2 insertions(+), 0 deletions(-)
> > > 
> > > diff --git a/drivers/video/omap2/vram.c b/drivers/video/omap2/vram.c
> > > index f6fdc20..1a99777 100644
> > > --- a/drivers/video/omap2/vram.c
> > > +++ b/drivers/video/omap2/vram.c
> > > @@ -575,6 +575,8 @@ void __init omap_vram_reserve_sdram_memblock(void)
> > >  		}
> > >  	} else {
> > >  		paddr = memblock_alloc_base(size, PAGE_SIZE, MEMBLOCK_REAL_LIMIT);
> > > +		memblock_free(paddr, size);
> > > +		memblock_remove(paddr, size);
> > >  	}
> > >  
> > >  	omap_vram_add_region(paddr, size);
> > 
> > I tested this on OMAP3 SDP board, on top of my DSS2 tree. I can boot up
> > fine, but my test program crashes the kernel (dump below).
> > 
> > This crash doesn't happen if I have the "HACK: OMAP: DSS2: OMAPFB: use
> > phys_to_virt for RAM mappings" patch in (I removed that during testing
> > this patch).
> > 
> > I don't know yet what is crashing the kernel, but I'd guess it's the
> > fact that my test program reallocates the framebuffer memory with
> > OMAPFB_SETUP_MEM ioctl.
> 
> Ah, sorry, I was missing the patch from Russel which you mentioned in
> another mail (http://article.gmane.org/gmane.linux.kernel/1047146). With
> that patch included things seem to work.

Tomi, I assume you're queuing these? If so, for both:

Acked-by: Tony Lindgren <tony@atomide.com>

Re: [PATCH 1/2] video: omap: vram: remove from normal memory

[Felipe Contreras]

On Tue, Oct 19, 2010 at 1:55 AM, Tony Lindgren <tony@atomide.com> wrote:
> * Tomi Valkeinen <tomi.valkeinen@nokia.com> [101018 06:55]:
>> On Mon, 2010-10-18 at 16:10 +0300, Tomi Valkeinen wrote:
>> > Hi,
>> >
>> > On Fri, 2010-10-15 at 14:46 +0200, ext Felipe Contreras wrote:
>> > > So that we can ioremap happily.
>> > >
>> > > Cc: Tomi Valkeinen <tomi.valkeinen@nokia.com>
>> > > Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
>> > > ---
>> > >  drivers/video/omap2/vram.c |    2 ++
>> > >  1 files changed, 2 insertions(+), 0 deletions(-)
>> > >
>> > > diff --git a/drivers/video/omap2/vram.c b/drivers/video/omap2/vram.c
>> > > index f6fdc20..1a99777 100644
>> > > --- a/drivers/video/omap2/vram.c
>> > > +++ b/drivers/video/omap2/vram.c
>> > > @@ -575,6 +575,8 @@ void __init omap_vram_reserve_sdram_memblock(void)
>> > >           }
>> > >   } else {
>> > >           paddr = memblock_alloc_base(size, PAGE_SIZE, MEMBLOCK_REAL_LIMIT);
>> > > +         memblock_free(paddr, size);
>> > > +         memblock_remove(paddr, size);
>> > >   }
>> > >
>> > >   omap_vram_add_region(paddr, size);
>> >
>> > I tested this on OMAP3 SDP board, on top of my DSS2 tree. I can boot up
>> > fine, but my test program crashes the kernel (dump below).
>> >
>> > This crash doesn't happen if I have the "HACK: OMAP: DSS2: OMAPFB: use
>> > phys_to_virt for RAM mappings" patch in (I removed that during testing
>> > this patch).
>> >
>> > I don't know yet what is crashing the kernel, but I'd guess it's the
>> > fact that my test program reallocates the framebuffer memory with
>> > OMAPFB_SETUP_MEM ioctl.
>>
>> Ah, sorry, I was missing the patch from Russel which you mentioned in
>> another mail (http://article.gmane.org/gmane.linux.kernel/1047146). With
>> that patch included things seem to work.
>
> Tomi, I assume you're queuing these? If so, for both:
>
> Acked-by: Tony Lindgren <tony@atomide.com>

Note that this depends on a patch by Russell that is not clear if it
will be merged on .37.

-- 
Felipe Contreras
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 1/2] video: omap: vram: remove from normal memory

[Felipe Contreras]

On Tue, Oct 19, 2010 at 1:55 AM, Tony Lindgren <tony@atomide.com> wrote:
> * Tomi Valkeinen <tomi.valkeinen@nokia.com> [101018 06:55]:
>> On Mon, 2010-10-18 at 16:10 +0300, Tomi Valkeinen wrote:
>> > Hi,
>> >
>> > On Fri, 2010-10-15 at 14:46 +0200, ext Felipe Contreras wrote:
>> > > So that we can ioremap happily.
>> > >
>> > > Cc: Tomi Valkeinen <tomi.valkeinen@nokia.com>
>> > > Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
>> > > ---
>> > > ?drivers/video/omap2/vram.c | ? ?2 ++
>> > > ?1 files changed, 2 insertions(+), 0 deletions(-)
>> > >
>> > > diff --git a/drivers/video/omap2/vram.c b/drivers/video/omap2/vram.c
>> > > index f6fdc20..1a99777 100644
>> > > --- a/drivers/video/omap2/vram.c
>> > > +++ b/drivers/video/omap2/vram.c
>> > > @@ -575,6 +575,8 @@ void __init omap_vram_reserve_sdram_memblock(void)
>> > > ? ? ? ? ? }
>> > > ? } else {
>> > > ? ? ? ? ? paddr = memblock_alloc_base(size, PAGE_SIZE, MEMBLOCK_REAL_LIMIT);
>> > > + ? ? ? ? memblock_free(paddr, size);
>> > > + ? ? ? ? memblock_remove(paddr, size);
>> > > ? }
>> > >
>> > > ? omap_vram_add_region(paddr, size);
>> >
>> > I tested this on OMAP3 SDP board, on top of my DSS2 tree. I can boot up
>> > fine, but my test program crashes the kernel (dump below).
>> >
>> > This crash doesn't happen if I have the "HACK: OMAP: DSS2: OMAPFB: use
>> > phys_to_virt for RAM mappings" patch in (I removed that during testing
>> > this patch).
>> >
>> > I don't know yet what is crashing the kernel, but I'd guess it's the
>> > fact that my test program reallocates the framebuffer memory with
>> > OMAPFB_SETUP_MEM ioctl.
>>
>> Ah, sorry, I was missing the patch from Russel which you mentioned in
>> another mail (http://article.gmane.org/gmane.linux.kernel/1047146). With
>> that patch included things seem to work.
>
> Tomi, I assume you're queuing these? If so, for both:
>
> Acked-by: Tony Lindgren <tony@atomide.com>

Note that this depends on a patch by Russell that is not clear if it
will be merged on .37.

-- 
Felipe Contreras

Re: [PATCH 1/2] video: omap: vram: remove from normal memory

[Tomi Valkeinen]

On Tue, 2010-10-19 at 00:55 +0200, ext Tony Lindgren wrote:
> * Tomi Valkeinen <tomi.valkeinen@nokia.com> [101018 06:55]:
> > On Mon, 2010-10-18 at 16:10 +0300, Tomi Valkeinen wrote:
> > > Hi,
> > > 
> > > On Fri, 2010-10-15 at 14:46 +0200, ext Felipe Contreras wrote:
> > > > So that we can ioremap happily.
> > > > 
> > > > Cc: Tomi Valkeinen <tomi.valkeinen@nokia.com>
> > > > Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
> > > > ---
> > > >  drivers/video/omap2/vram.c |    2 ++
> > > >  1 files changed, 2 insertions(+), 0 deletions(-)
> > > > 
> > > > diff --git a/drivers/video/omap2/vram.c b/drivers/video/omap2/vram.c
> > > > index f6fdc20..1a99777 100644
> > > > --- a/drivers/video/omap2/vram.c
> > > > +++ b/drivers/video/omap2/vram.c
> > > > @@ -575,6 +575,8 @@ void __init omap_vram_reserve_sdram_memblock(void)
> > > >  		}
> > > >  	} else {
> > > >  		paddr = memblock_alloc_base(size, PAGE_SIZE, MEMBLOCK_REAL_LIMIT);
> > > > +		memblock_free(paddr, size);
> > > > +		memblock_remove(paddr, size);
> > > >  	}
> > > >  
> > > >  	omap_vram_add_region(paddr, size);
> > > 
> > > I tested this on OMAP3 SDP board, on top of my DSS2 tree. I can boot up
> > > fine, but my test program crashes the kernel (dump below).
> > > 
> > > This crash doesn't happen if I have the "HACK: OMAP: DSS2: OMAPFB: use
> > > phys_to_virt for RAM mappings" patch in (I removed that during testing
> > > this patch).
> > > 
> > > I don't know yet what is crashing the kernel, but I'd guess it's the
> > > fact that my test program reallocates the framebuffer memory with
> > > OMAPFB_SETUP_MEM ioctl.
> > 
> > Ah, sorry, I was missing the patch from Russel which you mentioned in
> > another mail (http://article.gmane.org/gmane.linux.kernel/1047146). With
> > that patch included things seem to work.
> 
> Tomi, I assume you're queuing these? If so, for both:
> 
> Acked-by: Tony Lindgren <tony@atomide.com>

Yes, I can queue them (when the required memblock stuff is in).

 Tomi

[PATCH 1/2] video: omap: vram: remove from normal memory

[Tomi Valkeinen]

On Tue, 2010-10-19 at 00:55 +0200, ext Tony Lindgren wrote:
> * Tomi Valkeinen <tomi.valkeinen@nokia.com> [101018 06:55]:
> > On Mon, 2010-10-18 at 16:10 +0300, Tomi Valkeinen wrote:
> > > Hi,
> > > 
> > > On Fri, 2010-10-15 at 14:46 +0200, ext Felipe Contreras wrote:
> > > > So that we can ioremap happily.
> > > > 
> > > > Cc: Tomi Valkeinen <tomi.valkeinen@nokia.com>
> > > > Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
> > > > ---
> > > >  drivers/video/omap2/vram.c |    2 ++
> > > >  1 files changed, 2 insertions(+), 0 deletions(-)
> > > > 
> > > > diff --git a/drivers/video/omap2/vram.c b/drivers/video/omap2/vram.c
> > > > index f6fdc20..1a99777 100644
> > > > --- a/drivers/video/omap2/vram.c
> > > > +++ b/drivers/video/omap2/vram.c
> > > > @@ -575,6 +575,8 @@ void __init omap_vram_reserve_sdram_memblock(void)
> > > >  		}
> > > >  	} else {
> > > >  		paddr = memblock_alloc_base(size, PAGE_SIZE, MEMBLOCK_REAL_LIMIT);
> > > > +		memblock_free(paddr, size);
> > > > +		memblock_remove(paddr, size);
> > > >  	}
> > > >  
> > > >  	omap_vram_add_region(paddr, size);
> > > 
> > > I tested this on OMAP3 SDP board, on top of my DSS2 tree. I can boot up
> > > fine, but my test program crashes the kernel (dump below).
> > > 
> > > This crash doesn't happen if I have the "HACK: OMAP: DSS2: OMAPFB: use
> > > phys_to_virt for RAM mappings" patch in (I removed that during testing
> > > this patch).
> > > 
> > > I don't know yet what is crashing the kernel, but I'd guess it's the
> > > fact that my test program reallocates the framebuffer memory with
> > > OMAPFB_SETUP_MEM ioctl.
> > 
> > Ah, sorry, I was missing the patch from Russel which you mentioned in
> > another mail (http://article.gmane.org/gmane.linux.kernel/1047146). With
> > that patch included things seem to work.
> 
> Tomi, I assume you're queuing these? If so, for both:
> 
> Acked-by: Tony Lindgren <tony@atomide.com>

Yes, I can queue them (when the required memblock stuff is in).

 Tomi

Re: [PATCH 1/2] video: omap: vram: remove from normal memory

[Felipe Contreras]

On Tue, Oct 19, 2010 at 3:03 PM, Tomi Valkeinen
<tomi.valkeinen@nokia.com> wrote:
> On Tue, 2010-10-19 at 00:55 +0200, ext Tony Lindgren wrote:
>> * Tomi Valkeinen <tomi.valkeinen@nokia.com> [101018 06:55]:
>> > On Mon, 2010-10-18 at 16:10 +0300, Tomi Valkeinen wrote:
>> > > Hi,
>> > >
>> > > On Fri, 2010-10-15 at 14:46 +0200, ext Felipe Contreras wrote:
>> > > > So that we can ioremap happily.
>> > > >
>> > > > Cc: Tomi Valkeinen <tomi.valkeinen@nokia.com>
>> > > > Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
>> > > > ---
>> > > >  drivers/video/omap2/vram.c |    2 ++
>> > > >  1 files changed, 2 insertions(+), 0 deletions(-)
>> > > >
>> > > > diff --git a/drivers/video/omap2/vram.c b/drivers/video/omap2/vram.c
>> > > > index f6fdc20..1a99777 100644
>> > > > --- a/drivers/video/omap2/vram.c
>> > > > +++ b/drivers/video/omap2/vram.c
>> > > > @@ -575,6 +575,8 @@ void __init omap_vram_reserve_sdram_memblock(void)
>> > > >                 }
>> > > >         } else {
>> > > >                 paddr = memblock_alloc_base(size, PAGE_SIZE, MEMBLOCK_REAL_LIMIT);
>> > > > +               memblock_free(paddr, size);
>> > > > +               memblock_remove(paddr, size);
>> > > >         }
>> > > >
>> > > >         omap_vram_add_region(paddr, size);
>> > >
>> > > I tested this on OMAP3 SDP board, on top of my DSS2 tree. I can boot up
>> > > fine, but my test program crashes the kernel (dump below).
>> > >
>> > > This crash doesn't happen if I have the "HACK: OMAP: DSS2: OMAPFB: use
>> > > phys_to_virt for RAM mappings" patch in (I removed that during testing
>> > > this patch).
>> > >
>> > > I don't know yet what is crashing the kernel, but I'd guess it's the
>> > > fact that my test program reallocates the framebuffer memory with
>> > > OMAPFB_SETUP_MEM ioctl.
>> >
>> > Ah, sorry, I was missing the patch from Russel which you mentioned in
>> > another mail (http://article.gmane.org/gmane.linux.kernel/1047146). With
>> > that patch included things seem to work.
>>
>> Tomi, I assume you're queuing these? If so, for both:
>>
>> Acked-by: Tony Lindgren <tony@atomide.com>
>
> Yes, I can queue them (when the required memblock stuff is in).

Now it's in :) (v2.6.37-rc1)

-- 
Felipe Contreras
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 1/2] video: omap: vram: remove from normal memory

[Felipe Contreras]

On Tue, Oct 19, 2010 at 3:03 PM, Tomi Valkeinen
<tomi.valkeinen@nokia.com> wrote:
> On Tue, 2010-10-19 at 00:55 +0200, ext Tony Lindgren wrote:
>> * Tomi Valkeinen <tomi.valkeinen@nokia.com> [101018 06:55]:
>> > On Mon, 2010-10-18 at 16:10 +0300, Tomi Valkeinen wrote:
>> > > Hi,
>> > >
>> > > On Fri, 2010-10-15 at 14:46 +0200, ext Felipe Contreras wrote:
>> > > > So that we can ioremap happily.
>> > > >
>> > > > Cc: Tomi Valkeinen <tomi.valkeinen@nokia.com>
>> > > > Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
>> > > > ---
>> > > > ?drivers/video/omap2/vram.c | ? ?2 ++
>> > > > ?1 files changed, 2 insertions(+), 0 deletions(-)
>> > > >
>> > > > diff --git a/drivers/video/omap2/vram.c b/drivers/video/omap2/vram.c
>> > > > index f6fdc20..1a99777 100644
>> > > > --- a/drivers/video/omap2/vram.c
>> > > > +++ b/drivers/video/omap2/vram.c
>> > > > @@ -575,6 +575,8 @@ void __init omap_vram_reserve_sdram_memblock(void)
>> > > > ? ? ? ? ? ? ? ? }
>> > > > ? ? ? ? } else {
>> > > > ? ? ? ? ? ? ? ? paddr = memblock_alloc_base(size, PAGE_SIZE, MEMBLOCK_REAL_LIMIT);
>> > > > + ? ? ? ? ? ? ? memblock_free(paddr, size);
>> > > > + ? ? ? ? ? ? ? memblock_remove(paddr, size);
>> > > > ? ? ? ? }
>> > > >
>> > > > ? ? ? ? omap_vram_add_region(paddr, size);
>> > >
>> > > I tested this on OMAP3 SDP board, on top of my DSS2 tree. I can boot up
>> > > fine, but my test program crashes the kernel (dump below).
>> > >
>> > > This crash doesn't happen if I have the "HACK: OMAP: DSS2: OMAPFB: use
>> > > phys_to_virt for RAM mappings" patch in (I removed that during testing
>> > > this patch).
>> > >
>> > > I don't know yet what is crashing the kernel, but I'd guess it's the
>> > > fact that my test program reallocates the framebuffer memory with
>> > > OMAPFB_SETUP_MEM ioctl.
>> >
>> > Ah, sorry, I was missing the patch from Russel which you mentioned in
>> > another mail (http://article.gmane.org/gmane.linux.kernel/1047146). With
>> > that patch included things seem to work.
>>
>> Tomi, I assume you're queuing these? If so, for both:
>>
>> Acked-by: Tony Lindgren <tony@atomide.com>
>
> Yes, I can queue them (when the required memblock stuff is in).

Now it's in :) (v2.6.37-rc1)

-- 
Felipe Contreras

Re: [PATCH 1/2] video: omap: vram: remove from normal memory

[Tomi Valkeinen]

Hi,

On Sun, 2010-11-07 at 23:49 +0100, ext Felipe Contreras wrote:
> On Tue, Oct 19, 2010 at 3:03 PM, Tomi Valkeinen
> <tomi.valkeinen@nokia.com> wrote:

> > Yes, I can queue them (when the required memblock stuff is in).
> 
> Now it's in :) (v2.6.37-rc1)

I pushed vram patches to my DSS tree.

I combined the patches from Felipe and Namhyung with some changes: 1)
use memblock_alloc instead of memblock_alloc_base, and 2) use
memblock_free and memblock_remove for both reserved and allocated
memory. I hope this is ok for Felipe and Namhyung?

I think there was also a bug in memblock_is_region_memory(), for which I
sent a patch to memblock people. It's also in my tree.

Works for me on 3430SDP board, for both reserved and allocated vram, and
memblock and vram debug output looks sane.

 Tomi

[PATCH 1/2] video: omap: vram: remove from normal memory

[Tomi Valkeinen]

Hi,

On Sun, 2010-11-07 at 23:49 +0100, ext Felipe Contreras wrote:
> On Tue, Oct 19, 2010 at 3:03 PM, Tomi Valkeinen
> <tomi.valkeinen@nokia.com> wrote:

> > Yes, I can queue them (when the required memblock stuff is in).
> 
> Now it's in :) (v2.6.37-rc1)

I pushed vram patches to my DSS tree.

I combined the patches from Felipe and Namhyung with some changes: 1)
use memblock_alloc instead of memblock_alloc_base, and 2) use
memblock_free and memblock_remove for both reserved and allocated
memory. I hope this is ok for Felipe and Namhyung?

I think there was also a bug in memblock_is_region_memory(), for which I
sent a patch to memblock people. It's also in my tree.

Works for me on 3430SDP board, for both reserved and allocated vram, and
memblock and vram debug output looks sane.

 Tomi

[PATCH 2/2] omap: rx51: mark reserved memory earlier

[Felipe Contreras]

So that omap_vram_set_sdram_vram() is called before
omap_vram_reserve_sdram_memblock().

Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
---
 arch/arm/mach-omap2/board-rx51.c |    9 +++++++--
 1 files changed, 7 insertions(+), 2 deletions(-)

diff --git a/arch/arm/mach-omap2/board-rx51.c b/arch/arm/mach-omap2/board-rx51.c
index a58e8cb..861079b 100644
--- a/arch/arm/mach-omap2/board-rx51.c
+++ b/arch/arm/mach-omap2/board-rx51.c
@@ -144,17 +144,22 @@ static void __init rx51_init(void)
 static void __init rx51_map_io(void)
 {
 	omap2_set_globals_3xxx();
-	rx51_video_mem_init();
 	omap34xx_map_common_io();
 }
 
+static void __init rx51_reserve(void)
+{
+	rx51_video_mem_init();
+	omap_reserve();
+}
+
 MACHINE_START(NOKIA_RX51, "Nokia RX-51 board")
 	/* Maintainer: Lauri Leukkunen <lauri.leukkunen@nokia.com> */
 	.phys_io	= 0x48000000,
 	.io_pg_offst	= ((0xfa000000) >> 18) & 0xfffc,
 	.boot_params	= 0x80000100,
 	.map_io		= rx51_map_io,
-	.reserve	= omap_reserve,
+	.reserve	= rx51_reserve,
 	.init_irq	= rx51_init_irq,
 	.init_machine	= rx51_init,
 	.timer		= &omap_timer,
-- 
1.7.3.1.2.g7fe2b

[PATCH 2/2] omap: rx51: mark reserved memory earlier

[Felipe Contreras]

So that omap_vram_set_sdram_vram() is called before
omap_vram_reserve_sdram_memblock().

Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
---
 arch/arm/mach-omap2/board-rx51.c |    9 +++++++--
 1 files changed, 7 insertions(+), 2 deletions(-)

diff --git a/arch/arm/mach-omap2/board-rx51.c b/arch/arm/mach-omap2/board-rx51.c
index a58e8cb..861079b 100644
--- a/arch/arm/mach-omap2/board-rx51.c
+++ b/arch/arm/mach-omap2/board-rx51.c
@@ -144,17 +144,22 @@ static void __init rx51_init(void)
 static void __init rx51_map_io(void)
 {
 	omap2_set_globals_3xxx();
-	rx51_video_mem_init();
 	omap34xx_map_common_io();
 }
 
+static void __init rx51_reserve(void)
+{
+	rx51_video_mem_init();
+	omap_reserve();
+}
+
 MACHINE_START(NOKIA_RX51, "Nokia RX-51 board")
 	/* Maintainer: Lauri Leukkunen <lauri.leukkunen@nokia.com> */
 	.phys_io	= 0x48000000,
 	.io_pg_offst	= ((0xfa000000) >> 18) & 0xfffc,
 	.boot_params	= 0x80000100,
 	.map_io		= rx51_map_io,
-	.reserve	= omap_reserve,
+	.reserve	= rx51_reserve,
 	.init_irq	= rx51_init_irq,
 	.init_machine	= rx51_init,
 	.timer		= &omap_timer,
-- 
1.7.3.1.2.g7fe2b

Re: [PATCH 2/2] omap: rx51: mark reserved memory earlier

[Felipe Contreras]

On Fri, Oct 15, 2010 at 3:46 PM, Felipe Contreras
<felipe.contreras@gmail.com> wrote:
> So that omap_vram_set_sdram_vram() is called before
> omap_vram_reserve_sdram_memblock().

I actually didn't test this (my battery died).

But the previous one works with CONFIG_OMAP2_VRAM_SIZE=6.

-- 
Felipe Contreras

[PATCH 2/2] omap: rx51: mark reserved memory earlier

[Felipe Contreras]

On Fri, Oct 15, 2010 at 3:46 PM, Felipe Contreras
<felipe.contreras@gmail.com> wrote:
> So that omap_vram_set_sdram_vram() is called before
> omap_vram_reserve_sdram_memblock().

I actually didn't test this (my battery died).

But the previous one works with CONFIG_OMAP2_VRAM_SIZE=6.

-- 
Felipe Contreras

Re: [PATCH 2/2] omap: rx51: mark reserved memory earlier

[Tomi Valkeinen]

Hi,

On Fri, 2010-10-15 at 14:46 +0200, ext Felipe Contreras wrote:
> So that omap_vram_set_sdram_vram() is called before
> omap_vram_reserve_sdram_memblock().

Is this still valid after the latest memblock stuff? I presume it is.
I'm not able to test this, and you said you didn't test it, so I'm a bit
uneasy about applying =).

 Tomi


> 
> Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
> ---
>  arch/arm/mach-omap2/board-rx51.c |    9 +++++++--
>  1 files changed, 7 insertions(+), 2 deletions(-)
> 
> diff --git a/arch/arm/mach-omap2/board-rx51.c b/arch/arm/mach-omap2/board-rx51.c
> index a58e8cb..861079b 100644
> --- a/arch/arm/mach-omap2/board-rx51.c
> +++ b/arch/arm/mach-omap2/board-rx51.c
> @@ -144,17 +144,22 @@ static void __init rx51_init(void)
>  static void __init rx51_map_io(void)
>  {
>  	omap2_set_globals_3xxx();
> -	rx51_video_mem_init();
>  	omap34xx_map_common_io();
>  }
>  
> +static void __init rx51_reserve(void)
> +{
> +	rx51_video_mem_init();
> +	omap_reserve();
> +}
> +
>  MACHINE_START(NOKIA_RX51, "Nokia RX-51 board")
>  	/* Maintainer: Lauri Leukkunen <lauri.leukkunen@nokia.com> */
>  	.phys_io	= 0x48000000,
>  	.io_pg_offst	= ((0xfa000000) >> 18) & 0xfffc,
>  	.boot_params	= 0x80000100,
>  	.map_io		= rx51_map_io,
> -	.reserve	= omap_reserve,
> +	.reserve	= rx51_reserve,
>  	.init_irq	= rx51_init_irq,
>  	.init_machine	= rx51_init,
>  	.timer		= &omap_timer,

[PATCH 2/2] omap: rx51: mark reserved memory earlier

[Tomi Valkeinen]

Hi,

On Fri, 2010-10-15 at 14:46 +0200, ext Felipe Contreras wrote:
> So that omap_vram_set_sdram_vram() is called before
> omap_vram_reserve_sdram_memblock().

Is this still valid after the latest memblock stuff? I presume it is.
I'm not able to test this, and you said you didn't test it, so I'm a bit
uneasy about applying =).

 Tomi


> 
> Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
> ---
>  arch/arm/mach-omap2/board-rx51.c |    9 +++++++--
>  1 files changed, 7 insertions(+), 2 deletions(-)
> 
> diff --git a/arch/arm/mach-omap2/board-rx51.c b/arch/arm/mach-omap2/board-rx51.c
> index a58e8cb..861079b 100644
> --- a/arch/arm/mach-omap2/board-rx51.c
> +++ b/arch/arm/mach-omap2/board-rx51.c
> @@ -144,17 +144,22 @@ static void __init rx51_init(void)
>  static void __init rx51_map_io(void)
>  {
>  	omap2_set_globals_3xxx();
> -	rx51_video_mem_init();
>  	omap34xx_map_common_io();
>  }
>  
> +static void __init rx51_reserve(void)
> +{
> +	rx51_video_mem_init();
> +	omap_reserve();
> +}
> +
>  MACHINE_START(NOKIA_RX51, "Nokia RX-51 board")
>  	/* Maintainer: Lauri Leukkunen <lauri.leukkunen@nokia.com> */
>  	.phys_io	= 0x48000000,
>  	.io_pg_offst	= ((0xfa000000) >> 18) & 0xfffc,
>  	.boot_params	= 0x80000100,
>  	.map_io		= rx51_map_io,
> -	.reserve	= omap_reserve,
> +	.reserve	= rx51_reserve,
>  	.init_irq	= rx51_init_irq,
>  	.init_machine	= rx51_init,
>  	.timer		= &omap_timer,

Re: [PATCH 2/2] omap: rx51: mark reserved memory earlier

[Felipe Contreras]

On Fri, Nov 12, 2010 at 3:28 PM, Tomi Valkeinen
<tomi.valkeinen@nokia.com> wrote:
> On Fri, 2010-10-15 at 14:46 +0200, ext Felipe Contreras wrote:
>> So that omap_vram_set_sdram_vram() is called before
>> omap_vram_reserve_sdram_memblock().
>
> Is this still valid after the latest memblock stuff? I presume it is.
> I'm not able to test this, and you said you didn't test it, so I'm a bit
> uneasy about applying =).

This has been tested on other boards. Can you apply?

-- 
Felipe Contreras

[PATCH 2/2] omap: rx51: mark reserved memory earlier

[Felipe Contreras]

On Fri, Nov 12, 2010 at 3:28 PM, Tomi Valkeinen
<tomi.valkeinen@nokia.com> wrote:
> On Fri, 2010-10-15 at 14:46 +0200, ext Felipe Contreras wrote:
>> So that omap_vram_set_sdram_vram() is called before
>> omap_vram_reserve_sdram_memblock().
>
> Is this still valid after the latest memblock stuff? I presume it is.
> I'm not able to test this, and you said you didn't test it, so I'm a bit
> uneasy about applying =).

This has been tested on other boards. Can you apply?

-- 
Felipe Contreras