[PATCH 0/2] omapfb: option to use coherent dma mem

[PATCH 0/2] omapfb: option to use coherent dma mem

[Tomi Valkeinen]

Hi,

This is a bit refined version from the patch sent by Ivaylo.

So Ivaylo asked for an exclusive memory area for omapfb, so that the
allocations would not fail, and Vaibhav asked for reserving the fb at a
specified physical address, so that the bootloader can pass the fb to the
kernel. Those are a bit linked issues, and these patches try to accomplish
both.

This series is somewhat experimental, as I'm not so familiar with the dma api,
but, well, this seemed to work for the tests I did.

 Tomi

Tomi Valkeinen (2):
  ARM: omapfb: add coherent dma memory support
  omapfb: add support to reserve fb at specified phys address

 arch/arm/mach-omap2/common.c             |  1 +
 arch/arm/mach-omap2/common.h             |  2 +
 arch/arm/mach-omap2/fb.c                 | 77 +++++++++++++++++++++++++++++++-
 drivers/video/omap2/omapfb/omapfb-main.c | 36 +++++++++++----
 drivers/video/omap2/omapfb/omapfb.h      |  1 +
 5 files changed, 107 insertions(+), 10 deletions(-)

-- 
1.8.3.2

[PATCH 0/2] omapfb: option to use coherent dma mem

[Tomi Valkeinen]

Hi,

This is a bit refined version from the patch sent by Ivaylo.

So Ivaylo asked for an exclusive memory area for omapfb, so that the
allocations would not fail, and Vaibhav asked for reserving the fb at a
specified physical address, so that the bootloader can pass the fb to the
kernel. Those are a bit linked issues, and these patches try to accomplish
both.

This series is somewhat experimental, as I'm not so familiar with the dma api,
but, well, this seemed to work for the tests I did.

 Tomi

Tomi Valkeinen (2):
  ARM: omapfb: add coherent dma memory support
  omapfb: add support to reserve fb at specified phys address

 arch/arm/mach-omap2/common.c             |  1 +
 arch/arm/mach-omap2/common.h             |  2 +
 arch/arm/mach-omap2/fb.c                 | 77 +++++++++++++++++++++++++++++++-
 drivers/video/omap2/omapfb/omapfb-main.c | 36 +++++++++++----
 drivers/video/omap2/omapfb/omapfb.h      |  1 +
 5 files changed, 107 insertions(+), 10 deletions(-)

-- 
1.8.3.2

[PATCH 0/2] omapfb: option to use coherent dma mem

[Tomi Valkeinen]

Hi,

This is a bit refined version from the patch sent by Ivaylo.

So Ivaylo asked for an exclusive memory area for omapfb, so that the
allocations would not fail, and Vaibhav asked for reserving the fb at a
specified physical address, so that the bootloader can pass the fb to the
kernel. Those are a bit linked issues, and these patches try to accomplish
both.

This series is somewhat experimental, as I'm not so familiar with the dma api,
but, well, this seemed to work for the tests I did.

 Tomi

Tomi Valkeinen (2):
  ARM: omapfb: add coherent dma memory support
  omapfb: add support to reserve fb at specified phys address

 arch/arm/mach-omap2/common.c             |  1 +
 arch/arm/mach-omap2/common.h             |  2 +
 arch/arm/mach-omap2/fb.c                 | 77 +++++++++++++++++++++++++++++++-
 drivers/video/omap2/omapfb/omapfb-main.c | 36 +++++++++++----
 drivers/video/omap2/omapfb/omapfb.h      |  1 +
 5 files changed, 107 insertions(+), 10 deletions(-)

-- 
1.8.3.2

[PATCH 1/2] ARM: omapfb: add coherent dma memory support

[Tomi Valkeinen]

The omapfb driver uses dma_alloc to reserve memory for the framebuffers.
However, on some use cases, even when CMA is in use, it's quite probable
that omapfb fails to allocate the fb, either due to not enough free dma
memory, fragmented dma memory, or CMA failing to make enough contiguous
space.

This patch adds a kernel cmdline parameter 'omapfb_vram' which can be
used to give the size of a memory area reserved exclusively for omapfb,
and optionally a physical address where the memory area is reserved.

The memory area is reserved with memblock, and assigned to omapfb with
dma_declare_coherent_memory. The dma_alloc function will first try to
allocate the fb from the coherent memory area, and if that fails, it'll
use the normal method of allocation.

Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Cc: Ivaylo Dimitrov <freemangordon@abv.bg>
---
 arch/arm/mach-omap2/common.c |  1 +
 arch/arm/mach-omap2/common.h |  2 ++
 arch/arm/mach-omap2/fb.c     | 77 +++++++++++++++++++++++++++++++++++++++++++-
 3 files changed, 79 insertions(+), 1 deletion(-)

diff --git a/arch/arm/mach-omap2/common.c b/arch/arm/mach-omap2/common.c
index 2dabb9ecb986..9beecded0380 100644
--- a/arch/arm/mach-omap2/common.c
+++ b/arch/arm/mach-omap2/common.c
@@ -33,4 +33,5 @@ void __init omap_reserve(void)
 	omap_dsp_reserve_sdram_memblock();
 	omap_secure_ram_reserve_memblock();
 	omap_barrier_reserve_memblock();
+	omap_fb_reserve_memblock();
 }
diff --git a/arch/arm/mach-omap2/common.h b/arch/arm/mach-omap2/common.h
index e30ef6797c63..21afdc0fe15e 100644
--- a/arch/arm/mach-omap2/common.h
+++ b/arch/arm/mach-omap2/common.h
@@ -304,6 +304,8 @@ extern void omap_reserve(void);
 struct omap_hwmod;
 extern int omap_dss_reset(struct omap_hwmod *);
 
+extern void omap_fb_reserve_memblock(void);
+
 /* SoC specific clock initializer */
 extern int (*omap_clk_init)(void);
 
diff --git a/arch/arm/mach-omap2/fb.c b/arch/arm/mach-omap2/fb.c
index 26e28e94f625..80630329e508 100644
--- a/arch/arm/mach-omap2/fb.c
+++ b/arch/arm/mach-omap2/fb.c
@@ -30,9 +30,11 @@
 #include <linux/dma-mapping.h>
 
 #include <asm/mach/map.h>
+#include <asm/memblock.h>
 
 #include "soc.h"
 #include "display.h"
+#include "common.h"
 
 #ifdef CONFIG_OMAP2_VRFB
 
@@ -106,10 +108,83 @@ static struct platform_device omap_fb_device = {
 	.num_resources = 0,
 };
 
+static phys_addr_t omapfb_mem_base __initdata;
+static phys_addr_t omapfb_mem_size __initdata;
+
+static int __init early_omapfb_vram(char *p)
+{
+	omapfb_mem_size = memparse(p, &p);
+
+	if (!omapfb_mem_size) {
+		pr_err("omapfb: bad size for 'omapfb_vram' param\n");
+		return 0;
+	}
+
+	if (*p = '@') {
+		omapfb_mem_base = memparse(p + 1, NULL);
+
+		if (!omapfb_mem_base) {
+			pr_err("omapfb: bad addr for 'omapfb_vram' param\n");
+			omapfb_mem_size = 0;
+			return 0;
+		}
+	}
+
+	return 0;
+}
+early_param("omapfb_vram", early_omapfb_vram);
+
+void __init omap_fb_reserve_memblock(void)
+{
+	int r;
+
+	if (!omapfb_mem_size)
+		return;
+
+	if (omapfb_mem_base) {
+		r = memblock_reserve(omapfb_mem_base, omapfb_mem_size);
+
+		if (r) {
+			pr_err("omapfb: memblock_reserve failed: %d\n", r);
+			return;
+		}
+	} else {
+		omapfb_mem_base = memblock_alloc(omapfb_mem_size, SZ_1M);
+
+		if (!omapfb_mem_base) {
+			pr_err("omapfb: memblock_alloc failed\n");
+			return;
+		}
+	}
+
+	memblock_free(omapfb_mem_base, omapfb_mem_size);
+	memblock_remove(omapfb_mem_base, omapfb_mem_size);
+
+	pr_info("omapfb: reserved %pa bytes at %pa\n",
+			&omapfb_mem_size, &omapfb_mem_base);
+}
+
 int __init omap_init_fb(void)
 {
-	return platform_device_register(&omap_fb_device);
+	int r;
+
+	r = platform_device_register(&omap_fb_device);
+
+	if (r)
+		return r;
+
+	if (!omapfb_mem_base)
+		return 0;
+
+	r = dma_declare_coherent_memory(&omap_fb_device.dev,
+					  omapfb_mem_base, omapfb_mem_base,
+					  omapfb_mem_size, DMA_MEMORY_MAP);
+	if (!(r & DMA_MEMORY_MAP))
+		pr_err("omapfb: dma_declare_coherent_memory failed\n");
+
+	return 0;
 }
+
 #else
 int __init omap_init_fb(void) { return 0; }
 #endif
-- 
1.8.3.2

[PATCH 1/2] ARM: omapfb: add coherent dma memory support

[Tomi Valkeinen]

The omapfb driver uses dma_alloc to reserve memory for the framebuffers.
However, on some use cases, even when CMA is in use, it's quite probable
that omapfb fails to allocate the fb, either due to not enough free dma
memory, fragmented dma memory, or CMA failing to make enough contiguous
space.

This patch adds a kernel cmdline parameter 'omapfb_vram' which can be
used to give the size of a memory area reserved exclusively for omapfb,
and optionally a physical address where the memory area is reserved.

The memory area is reserved with memblock, and assigned to omapfb with
dma_declare_coherent_memory. The dma_alloc function will first try to
allocate the fb from the coherent memory area, and if that fails, it'll
use the normal method of allocation.

Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Cc: Ivaylo Dimitrov <freemangordon@abv.bg>
---
 arch/arm/mach-omap2/common.c |  1 +
 arch/arm/mach-omap2/common.h |  2 ++
 arch/arm/mach-omap2/fb.c     | 77 +++++++++++++++++++++++++++++++++++++++++++-
 3 files changed, 79 insertions(+), 1 deletion(-)

diff --git a/arch/arm/mach-omap2/common.c b/arch/arm/mach-omap2/common.c
index 2dabb9ecb986..9beecded0380 100644
--- a/arch/arm/mach-omap2/common.c
+++ b/arch/arm/mach-omap2/common.c
@@ -33,4 +33,5 @@ void __init omap_reserve(void)
 	omap_dsp_reserve_sdram_memblock();
 	omap_secure_ram_reserve_memblock();
 	omap_barrier_reserve_memblock();
+	omap_fb_reserve_memblock();
 }
diff --git a/arch/arm/mach-omap2/common.h b/arch/arm/mach-omap2/common.h
index e30ef6797c63..21afdc0fe15e 100644
--- a/arch/arm/mach-omap2/common.h
+++ b/arch/arm/mach-omap2/common.h
@@ -304,6 +304,8 @@ extern void omap_reserve(void);
 struct omap_hwmod;
 extern int omap_dss_reset(struct omap_hwmod *);
 
+extern void omap_fb_reserve_memblock(void);
+
 /* SoC specific clock initializer */
 extern int (*omap_clk_init)(void);
 
diff --git a/arch/arm/mach-omap2/fb.c b/arch/arm/mach-omap2/fb.c
index 26e28e94f625..80630329e508 100644
--- a/arch/arm/mach-omap2/fb.c
+++ b/arch/arm/mach-omap2/fb.c
@@ -30,9 +30,11 @@
 #include <linux/dma-mapping.h>
 
 #include <asm/mach/map.h>
+#include <asm/memblock.h>
 
 #include "soc.h"
 #include "display.h"
+#include "common.h"
 
 #ifdef CONFIG_OMAP2_VRFB
 
@@ -106,10 +108,83 @@ static struct platform_device omap_fb_device = {
 	.num_resources = 0,
 };
 
+static phys_addr_t omapfb_mem_base __initdata;
+static phys_addr_t omapfb_mem_size __initdata;
+
+static int __init early_omapfb_vram(char *p)
+{
+	omapfb_mem_size = memparse(p, &p);
+
+	if (!omapfb_mem_size) {
+		pr_err("omapfb: bad size for 'omapfb_vram' param\n");
+		return 0;
+	}
+
+	if (*p == '@') {
+		omapfb_mem_base = memparse(p + 1, NULL);
+
+		if (!omapfb_mem_base) {
+			pr_err("omapfb: bad addr for 'omapfb_vram' param\n");
+			omapfb_mem_size = 0;
+			return 0;
+		}
+	}
+
+	return 0;
+}
+early_param("omapfb_vram", early_omapfb_vram);
+
+void __init omap_fb_reserve_memblock(void)
+{
+	int r;
+
+	if (!omapfb_mem_size)
+		return;
+
+	if (omapfb_mem_base) {
+		r = memblock_reserve(omapfb_mem_base, omapfb_mem_size);
+
+		if (r) {
+			pr_err("omapfb: memblock_reserve failed: %d\n", r);
+			return;
+		}
+	} else {
+		omapfb_mem_base = memblock_alloc(omapfb_mem_size, SZ_1M);
+
+		if (!omapfb_mem_base) {
+			pr_err("omapfb: memblock_alloc failed\n");
+			return;
+		}
+	}
+
+	memblock_free(omapfb_mem_base, omapfb_mem_size);
+	memblock_remove(omapfb_mem_base, omapfb_mem_size);
+
+	pr_info("omapfb: reserved %pa bytes at %pa\n",
+			&omapfb_mem_size, &omapfb_mem_base);
+}
+
 int __init omap_init_fb(void)
 {
-	return platform_device_register(&omap_fb_device);
+	int r;
+
+	r = platform_device_register(&omap_fb_device);
+
+	if (r)
+		return r;
+
+	if (!omapfb_mem_base)
+		return 0;
+
+	r = dma_declare_coherent_memory(&omap_fb_device.dev,
+					  omapfb_mem_base, omapfb_mem_base,
+					  omapfb_mem_size, DMA_MEMORY_MAP);
+	if (!(r & DMA_MEMORY_MAP))
+		pr_err("omapfb: dma_declare_coherent_memory failed\n");
+
+	return 0;
 }
+
 #else
 int __init omap_init_fb(void) { return 0; }
 #endif
-- 
1.8.3.2

[PATCH 1/2] ARM: omapfb: add coherent dma memory support

[Tomi Valkeinen]

The omapfb driver uses dma_alloc to reserve memory for the framebuffers.
However, on some use cases, even when CMA is in use, it's quite probable
that omapfb fails to allocate the fb, either due to not enough free dma
memory, fragmented dma memory, or CMA failing to make enough contiguous
space.

This patch adds a kernel cmdline parameter 'omapfb_vram' which can be
used to give the size of a memory area reserved exclusively for omapfb,
and optionally a physical address where the memory area is reserved.

The memory area is reserved with memblock, and assigned to omapfb with
dma_declare_coherent_memory. The dma_alloc function will first try to
allocate the fb from the coherent memory area, and if that fails, it'll
use the normal method of allocation.

Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Cc: Ivaylo Dimitrov <freemangordon@abv.bg>
---
 arch/arm/mach-omap2/common.c |  1 +
 arch/arm/mach-omap2/common.h |  2 ++
 arch/arm/mach-omap2/fb.c     | 77 +++++++++++++++++++++++++++++++++++++++++++-
 3 files changed, 79 insertions(+), 1 deletion(-)

diff --git a/arch/arm/mach-omap2/common.c b/arch/arm/mach-omap2/common.c
index 2dabb9ecb986..9beecded0380 100644
--- a/arch/arm/mach-omap2/common.c
+++ b/arch/arm/mach-omap2/common.c
@@ -33,4 +33,5 @@ void __init omap_reserve(void)
 	omap_dsp_reserve_sdram_memblock();
 	omap_secure_ram_reserve_memblock();
 	omap_barrier_reserve_memblock();
+	omap_fb_reserve_memblock();
 }
diff --git a/arch/arm/mach-omap2/common.h b/arch/arm/mach-omap2/common.h
index e30ef6797c63..21afdc0fe15e 100644
--- a/arch/arm/mach-omap2/common.h
+++ b/arch/arm/mach-omap2/common.h
@@ -304,6 +304,8 @@ extern void omap_reserve(void);
 struct omap_hwmod;
 extern int omap_dss_reset(struct omap_hwmod *);
 
+extern void omap_fb_reserve_memblock(void);
+
 /* SoC specific clock initializer */
 extern int (*omap_clk_init)(void);
 
diff --git a/arch/arm/mach-omap2/fb.c b/arch/arm/mach-omap2/fb.c
index 26e28e94f625..80630329e508 100644
--- a/arch/arm/mach-omap2/fb.c
+++ b/arch/arm/mach-omap2/fb.c
@@ -30,9 +30,11 @@
 #include <linux/dma-mapping.h>
 
 #include <asm/mach/map.h>
+#include <asm/memblock.h>
 
 #include "soc.h"
 #include "display.h"
+#include "common.h"
 
 #ifdef CONFIG_OMAP2_VRFB
 
@@ -106,10 +108,83 @@ static struct platform_device omap_fb_device = {
 	.num_resources = 0,
 };
 
+static phys_addr_t omapfb_mem_base __initdata;
+static phys_addr_t omapfb_mem_size __initdata;
+
+static int __init early_omapfb_vram(char *p)
+{
+	omapfb_mem_size = memparse(p, &p);
+
+	if (!omapfb_mem_size) {
+		pr_err("omapfb: bad size for 'omapfb_vram' param\n");
+		return 0;
+	}
+
+	if (*p == '@') {
+		omapfb_mem_base = memparse(p + 1, NULL);
+
+		if (!omapfb_mem_base) {
+			pr_err("omapfb: bad addr for 'omapfb_vram' param\n");
+			omapfb_mem_size = 0;
+			return 0;
+		}
+	}
+
+	return 0;
+}
+early_param("omapfb_vram", early_omapfb_vram);
+
+void __init omap_fb_reserve_memblock(void)
+{
+	int r;
+
+	if (!omapfb_mem_size)
+		return;
+
+	if (omapfb_mem_base) {
+		r = memblock_reserve(omapfb_mem_base, omapfb_mem_size);
+
+		if (r) {
+			pr_err("omapfb: memblock_reserve failed: %d\n", r);
+			return;
+		}
+	} else {
+		omapfb_mem_base = memblock_alloc(omapfb_mem_size, SZ_1M);
+
+		if (!omapfb_mem_base) {
+			pr_err("omapfb: memblock_alloc failed\n");
+			return;
+		}
+	}
+
+	memblock_free(omapfb_mem_base, omapfb_mem_size);
+	memblock_remove(omapfb_mem_base, omapfb_mem_size);
+
+	pr_info("omapfb: reserved %pa bytes at %pa\n",
+			&omapfb_mem_size, &omapfb_mem_base);
+}
+
 int __init omap_init_fb(void)
 {
-	return platform_device_register(&omap_fb_device);
+	int r;
+
+	r = platform_device_register(&omap_fb_device);
+
+	if (r)
+		return r;
+
+	if (!omapfb_mem_base)
+		return 0;
+
+	r = dma_declare_coherent_memory(&omap_fb_device.dev,
+					  omapfb_mem_base, omapfb_mem_base,
+					  omapfb_mem_size, DMA_MEMORY_MAP);
+	if (!(r & DMA_MEMORY_MAP))
+		pr_err("omapfb: dma_declare_coherent_memory failed\n");
+
+	return 0;
 }
+
 #else
 int __init omap_init_fb(void) { return 0; }
 #endif
-- 
1.8.3.2

[PATCH 2/2] omapfb: add support to reserve fb at specified phys address

[Tomi Valkeinen]

The previous patch added support to reserve an exclusive coherent area
for omapfb. This patch adds support to allocate a fb from a specified
physical address inside that coherent area.

This can be used to "pass" a framebuffer from the bootloader to the
kernel: the bootloader sets up the DSS hardware to display a piece of
memory, and gives the address and size of the used piece of memory to
the kernel via omapfb_vram and omapfb.vram cmdline parameters.

Note that the DSS driver itself does not yet support this, and the DSS
hardware is reset at kernel init. This means that the display will be
off until later omapfb is started, which will set up the DSS again.

Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Cc: Vaibhav Hiremath <hvaibhav@ti.com>
---
 drivers/video/omap2/omapfb/omapfb-main.c | 36 ++++++++++++++++++++++++--------
 drivers/video/omap2/omapfb/omapfb.h      |  1 +
 2 files changed, 28 insertions(+), 9 deletions(-)

diff --git a/drivers/video/omap2/omapfb/omapfb-main.c b/drivers/video/omap2/omapfb/omapfb-main.c
index 27d6905683f3..88c1fe92d2c6 100644
--- a/drivers/video/omap2/omapfb/omapfb-main.c
+++ b/drivers/video/omap2/omapfb/omapfb-main.c
@@ -1383,18 +1383,36 @@ static int omapfb_alloc_fbmem(struct fb_info *fbi, unsigned long size,
 	rg->type = 0;
 	rg->alloc = false;
 	rg->map = false;
+	rg->noclear = 0;
 
 	size = PAGE_ALIGN(size);
 
-	dma_set_attr(DMA_ATTR_WRITE_COMBINE, &attrs);
+	if (paddr) {
+		DBG("reserving %#lx bytes at %#lx\n", size, paddr);
 
-	if (ofbi->rotation_type = OMAP_DSS_ROT_VRFB)
-		dma_set_attr(DMA_ATTR_NO_KERNEL_MAPPING, &attrs);
+		token = dma_mark_declared_memory_occupied(fbdev->dev,
+			paddr, size);
+
+		if (IS_ERR(token)) {
+			dev_err(fbdev->dev,
+				"dma_mark_declared_memory_occupied failed: %ld\n",
+				PTR_ERR(token));
+			return PTR_ERR(token);
+		}
+
+		dma_handle = paddr;
+		rg->noclear = 1;
+	} else {
+		dma_set_attr(DMA_ATTR_WRITE_COMBINE, &attrs);
 
-	DBG("allocating %lu bytes for fb %d\n", size, ofbi->id);
+		if (ofbi->rotation_type = OMAP_DSS_ROT_VRFB)
+			dma_set_attr(DMA_ATTR_NO_KERNEL_MAPPING, &attrs);
 
-	token = dma_alloc_attrs(fbdev->dev, size, &dma_handle,
-			GFP_KERNEL, &attrs);
+		DBG("allocating %lu bytes for fb %d\n", size, ofbi->id);
+
+		token = dma_alloc_attrs(fbdev->dev, size, &dma_handle,
+				GFP_KERNEL, &attrs);
+	}
 
 	if (token = NULL) {
 		dev_err(fbdev->dev, "failed to allocate framebuffer\n");
@@ -1513,9 +1531,6 @@ static int omapfb_parse_vram_param(const char *param, int max_entries,
 
 		}
 
-		WARN_ONCE(paddr,
-			"reserving memory at predefined address not supported\n");
-
 		paddrs[fbnum] = paddr;
 		sizes[fbnum] = size;
 
@@ -1950,6 +1965,9 @@ static int omapfb_create_framebuffers(struct omapfb2_device *fbdev)
 		if (ofbi->region->size = 0)
 			continue;
 
+		if (ofbi->region->noclear)
+			continue;
+
 		omapfb_clear_fb(fbi);
 	}
 
diff --git a/drivers/video/omap2/omapfb/omapfb.h b/drivers/video/omap2/omapfb/omapfb.h
index 623cd872a367..69642944f453 100644
--- a/drivers/video/omap2/omapfb/omapfb.h
+++ b/drivers/video/omap2/omapfb/omapfb.h
@@ -64,6 +64,7 @@ struct omapfb2_mem_region {
 	atomic_t	map_count;
 	struct rw_semaphore lock;
 	atomic_t	lock_count;
+	bool		noclear;	/* don't clear the fb on alloc */
 };
 
 /* appended to fb_info */
-- 
1.8.3.2

[PATCH 2/2] omapfb: add support to reserve fb at specified phys address

[Tomi Valkeinen]

The previous patch added support to reserve an exclusive coherent area
for omapfb. This patch adds support to allocate a fb from a specified
physical address inside that coherent area.

This can be used to "pass" a framebuffer from the bootloader to the
kernel: the bootloader sets up the DSS hardware to display a piece of
memory, and gives the address and size of the used piece of memory to
the kernel via omapfb_vram and omapfb.vram cmdline parameters.

Note that the DSS driver itself does not yet support this, and the DSS
hardware is reset at kernel init. This means that the display will be
off until later omapfb is started, which will set up the DSS again.

Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Cc: Vaibhav Hiremath <hvaibhav@ti.com>
---
 drivers/video/omap2/omapfb/omapfb-main.c | 36 ++++++++++++++++++++++++--------
 drivers/video/omap2/omapfb/omapfb.h      |  1 +
 2 files changed, 28 insertions(+), 9 deletions(-)

diff --git a/drivers/video/omap2/omapfb/omapfb-main.c b/drivers/video/omap2/omapfb/omapfb-main.c
index 27d6905683f3..88c1fe92d2c6 100644
--- a/drivers/video/omap2/omapfb/omapfb-main.c
+++ b/drivers/video/omap2/omapfb/omapfb-main.c
@@ -1383,18 +1383,36 @@ static int omapfb_alloc_fbmem(struct fb_info *fbi, unsigned long size,
 	rg->type = 0;
 	rg->alloc = false;
 	rg->map = false;
+	rg->noclear = 0;
 
 	size = PAGE_ALIGN(size);
 
-	dma_set_attr(DMA_ATTR_WRITE_COMBINE, &attrs);
+	if (paddr) {
+		DBG("reserving %#lx bytes at %#lx\n", size, paddr);
 
-	if (ofbi->rotation_type == OMAP_DSS_ROT_VRFB)
-		dma_set_attr(DMA_ATTR_NO_KERNEL_MAPPING, &attrs);
+		token = dma_mark_declared_memory_occupied(fbdev->dev,
+			paddr, size);
+
+		if (IS_ERR(token)) {
+			dev_err(fbdev->dev,
+				"dma_mark_declared_memory_occupied failed: %ld\n",
+				PTR_ERR(token));
+			return PTR_ERR(token);
+		}
+
+		dma_handle = paddr;
+		rg->noclear = 1;
+	} else {
+		dma_set_attr(DMA_ATTR_WRITE_COMBINE, &attrs);
 
-	DBG("allocating %lu bytes for fb %d\n", size, ofbi->id);
+		if (ofbi->rotation_type == OMAP_DSS_ROT_VRFB)
+			dma_set_attr(DMA_ATTR_NO_KERNEL_MAPPING, &attrs);
 
-	token = dma_alloc_attrs(fbdev->dev, size, &dma_handle,
-			GFP_KERNEL, &attrs);
+		DBG("allocating %lu bytes for fb %d\n", size, ofbi->id);
+
+		token = dma_alloc_attrs(fbdev->dev, size, &dma_handle,
+				GFP_KERNEL, &attrs);
+	}
 
 	if (token == NULL) {
 		dev_err(fbdev->dev, "failed to allocate framebuffer\n");
@@ -1513,9 +1531,6 @@ static int omapfb_parse_vram_param(const char *param, int max_entries,
 
 		}
 
-		WARN_ONCE(paddr,
-			"reserving memory at predefined address not supported\n");
-
 		paddrs[fbnum] = paddr;
 		sizes[fbnum] = size;
 
@@ -1950,6 +1965,9 @@ static int omapfb_create_framebuffers(struct omapfb2_device *fbdev)
 		if (ofbi->region->size == 0)
 			continue;
 
+		if (ofbi->region->noclear)
+			continue;
+
 		omapfb_clear_fb(fbi);
 	}
 
diff --git a/drivers/video/omap2/omapfb/omapfb.h b/drivers/video/omap2/omapfb/omapfb.h
index 623cd872a367..69642944f453 100644
--- a/drivers/video/omap2/omapfb/omapfb.h
+++ b/drivers/video/omap2/omapfb/omapfb.h
@@ -64,6 +64,7 @@ struct omapfb2_mem_region {
 	atomic_t	map_count;
 	struct rw_semaphore lock;
 	atomic_t	lock_count;
+	bool		noclear;	/* don't clear the fb on alloc */
 };
 
 /* appended to fb_info */
-- 
1.8.3.2

[PATCH 2/2] omapfb: add support to reserve fb at specified phys address

[Tomi Valkeinen]

The previous patch added support to reserve an exclusive coherent area
for omapfb. This patch adds support to allocate a fb from a specified
physical address inside that coherent area.

This can be used to "pass" a framebuffer from the bootloader to the
kernel: the bootloader sets up the DSS hardware to display a piece of
memory, and gives the address and size of the used piece of memory to
the kernel via omapfb_vram and omapfb.vram cmdline parameters.

Note that the DSS driver itself does not yet support this, and the DSS
hardware is reset at kernel init. This means that the display will be
off until later omapfb is started, which will set up the DSS again.

Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Cc: Vaibhav Hiremath <hvaibhav@ti.com>
---
 drivers/video/omap2/omapfb/omapfb-main.c | 36 ++++++++++++++++++++++++--------
 drivers/video/omap2/omapfb/omapfb.h      |  1 +
 2 files changed, 28 insertions(+), 9 deletions(-)

diff --git a/drivers/video/omap2/omapfb/omapfb-main.c b/drivers/video/omap2/omapfb/omapfb-main.c
index 27d6905683f3..88c1fe92d2c6 100644
--- a/drivers/video/omap2/omapfb/omapfb-main.c
+++ b/drivers/video/omap2/omapfb/omapfb-main.c
@@ -1383,18 +1383,36 @@ static int omapfb_alloc_fbmem(struct fb_info *fbi, unsigned long size,
 	rg->type = 0;
 	rg->alloc = false;
 	rg->map = false;
+	rg->noclear = 0;
 
 	size = PAGE_ALIGN(size);
 
-	dma_set_attr(DMA_ATTR_WRITE_COMBINE, &attrs);
+	if (paddr) {
+		DBG("reserving %#lx bytes at %#lx\n", size, paddr);
 
-	if (ofbi->rotation_type == OMAP_DSS_ROT_VRFB)
-		dma_set_attr(DMA_ATTR_NO_KERNEL_MAPPING, &attrs);
+		token = dma_mark_declared_memory_occupied(fbdev->dev,
+			paddr, size);
+
+		if (IS_ERR(token)) {
+			dev_err(fbdev->dev,
+				"dma_mark_declared_memory_occupied failed: %ld\n",
+				PTR_ERR(token));
+			return PTR_ERR(token);
+		}
+
+		dma_handle = paddr;
+		rg->noclear = 1;
+	} else {
+		dma_set_attr(DMA_ATTR_WRITE_COMBINE, &attrs);
 
-	DBG("allocating %lu bytes for fb %d\n", size, ofbi->id);
+		if (ofbi->rotation_type == OMAP_DSS_ROT_VRFB)
+			dma_set_attr(DMA_ATTR_NO_KERNEL_MAPPING, &attrs);
 
-	token = dma_alloc_attrs(fbdev->dev, size, &dma_handle,
-			GFP_KERNEL, &attrs);
+		DBG("allocating %lu bytes for fb %d\n", size, ofbi->id);
+
+		token = dma_alloc_attrs(fbdev->dev, size, &dma_handle,
+				GFP_KERNEL, &attrs);
+	}
 
 	if (token == NULL) {
 		dev_err(fbdev->dev, "failed to allocate framebuffer\n");
@@ -1513,9 +1531,6 @@ static int omapfb_parse_vram_param(const char *param, int max_entries,
 
 		}
 
-		WARN_ONCE(paddr,
-			"reserving memory at predefined address not supported\n");
-
 		paddrs[fbnum] = paddr;
 		sizes[fbnum] = size;
 
@@ -1950,6 +1965,9 @@ static int omapfb_create_framebuffers(struct omapfb2_device *fbdev)
 		if (ofbi->region->size == 0)
 			continue;
 
+		if (ofbi->region->noclear)
+			continue;
+
 		omapfb_clear_fb(fbi);
 	}
 
diff --git a/drivers/video/omap2/omapfb/omapfb.h b/drivers/video/omap2/omapfb/omapfb.h
index 623cd872a367..69642944f453 100644
--- a/drivers/video/omap2/omapfb/omapfb.h
+++ b/drivers/video/omap2/omapfb/omapfb.h
@@ -64,6 +64,7 @@ struct omapfb2_mem_region {
 	atomic_t	map_count;
 	struct rw_semaphore lock;
 	atomic_t	lock_count;
+	bool		noclear;	/* don't clear the fb on alloc */
 };
 
 /* appended to fb_info */
-- 
1.8.3.2

Re: [PATCH 1/2] ARM: omapfb: add coherent dma memory support

[Ivaylo Dimitrov]

On 30.12.2013 15:19, Tomi Valkeinen wrote:
> The omapfb driver uses dma_alloc to reserve memory for the framebuffers.
> However, on some use cases, even when CMA is in use, it's quite probable
> that omapfb fails to allocate the fb, either due to not enough free dma
> memory, fragmented dma memory, or CMA failing to make enough contiguous
> space.
>
> This patch adds a kernel cmdline parameter 'omapfb_vram' which can be
> used to give the size of a memory area reserved exclusively for omapfb,
> and optionally a physical address where the memory area is reserved.
>
> The memory area is reserved with memblock, and assigned to omapfb with
> dma_declare_coherent_memory. The dma_alloc function will first try to
> allocate the fb from the coherent memory area, and if that fails, it'll
> use the normal method of allocation.
>
> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
> Cc: Ivaylo Dimitrov <freemangordon@abv.bg>
> ---
>   arch/arm/mach-omap2/common.c |  1 +
>   arch/arm/mach-omap2/common.h |  2 ++
>   arch/arm/mach-omap2/fb.c     | 77 +++++++++++++++++++++++++++++++++++++++++++-
>   3 files changed, 79 insertions(+), 1 deletion(-)
>

Tested on Nokia N900 with Maemo5 and linux 3.13-rc6

Re: [PATCH 1/2] ARM: omapfb: add coherent dma memory support

[Ivaylo Dimitrov]

On 30.12.2013 15:19, Tomi Valkeinen wrote:
> The omapfb driver uses dma_alloc to reserve memory for the framebuffers.
> However, on some use cases, even when CMA is in use, it's quite probable
> that omapfb fails to allocate the fb, either due to not enough free dma
> memory, fragmented dma memory, or CMA failing to make enough contiguous
> space.
>
> This patch adds a kernel cmdline parameter 'omapfb_vram' which can be
> used to give the size of a memory area reserved exclusively for omapfb,
> and optionally a physical address where the memory area is reserved.
>
> The memory area is reserved with memblock, and assigned to omapfb with
> dma_declare_coherent_memory. The dma_alloc function will first try to
> allocate the fb from the coherent memory area, and if that fails, it'll
> use the normal method of allocation.
>
> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
> Cc: Ivaylo Dimitrov <freemangordon@abv.bg>
> ---
>   arch/arm/mach-omap2/common.c |  1 +
>   arch/arm/mach-omap2/common.h |  2 ++
>   arch/arm/mach-omap2/fb.c     | 77 +++++++++++++++++++++++++++++++++++++++++++-
>   3 files changed, 79 insertions(+), 1 deletion(-)
>

Tested on Nokia N900 with Maemo5 and linux 3.13-rc6

[PATCH 1/2] ARM: omapfb: add coherent dma memory support

[Ivaylo Dimitrov]

On 30.12.2013 15:19, Tomi Valkeinen wrote:
> The omapfb driver uses dma_alloc to reserve memory for the framebuffers.
> However, on some use cases, even when CMA is in use, it's quite probable
> that omapfb fails to allocate the fb, either due to not enough free dma
> memory, fragmented dma memory, or CMA failing to make enough contiguous
> space.
>
> This patch adds a kernel cmdline parameter 'omapfb_vram' which can be
> used to give the size of a memory area reserved exclusively for omapfb,
> and optionally a physical address where the memory area is reserved.
>
> The memory area is reserved with memblock, and assigned to omapfb with
> dma_declare_coherent_memory. The dma_alloc function will first try to
> allocate the fb from the coherent memory area, and if that fails, it'll
> use the normal method of allocation.
>
> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
> Cc: Ivaylo Dimitrov <freemangordon@abv.bg>
> ---
>   arch/arm/mach-omap2/common.c |  1 +
>   arch/arm/mach-omap2/common.h |  2 ++
>   arch/arm/mach-omap2/fb.c     | 77 +++++++++++++++++++++++++++++++++++++++++++-
>   3 files changed, 79 insertions(+), 1 deletion(-)
>

Tested on Nokia N900 with Maemo5 and linux 3.13-rc6

Re: [PATCH 1/2] ARM: omapfb: add coherent dma memory support

[Tony Lindgren]

* Tomi Valkeinen <tomi.valkeinen@ti.com> [131230 05:21]:
> The omapfb driver uses dma_alloc to reserve memory for the framebuffers.
> However, on some use cases, even when CMA is in use, it's quite probable
> that omapfb fails to allocate the fb, either due to not enough free dma
> memory, fragmented dma memory, or CMA failing to make enough contiguous
> space.
> 
> This patch adds a kernel cmdline parameter 'omapfb_vram' which can be
> used to give the size of a memory area reserved exclusively for omapfb,
> and optionally a physical address where the memory area is reserved.
> 
> The memory area is reserved with memblock, and assigned to omapfb with
> dma_declare_coherent_memory. The dma_alloc function will first try to
> allocate the fb from the coherent memory area, and if that fails, it'll
> use the normal method of allocation.
> 
> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
> Cc: Ivaylo Dimitrov <freemangordon@abv.bg>

Feel free to queue this along with the DSS patches:

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

Re: [PATCH 1/2] ARM: omapfb: add coherent dma memory support

[Tony Lindgren]

* Tomi Valkeinen <tomi.valkeinen@ti.com> [131230 05:21]:
> The omapfb driver uses dma_alloc to reserve memory for the framebuffers.
> However, on some use cases, even when CMA is in use, it's quite probable
> that omapfb fails to allocate the fb, either due to not enough free dma
> memory, fragmented dma memory, or CMA failing to make enough contiguous
> space.
> 
> This patch adds a kernel cmdline parameter 'omapfb_vram' which can be
> used to give the size of a memory area reserved exclusively for omapfb,
> and optionally a physical address where the memory area is reserved.
> 
> The memory area is reserved with memblock, and assigned to omapfb with
> dma_declare_coherent_memory. The dma_alloc function will first try to
> allocate the fb from the coherent memory area, and if that fails, it'll
> use the normal method of allocation.
> 
> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
> Cc: Ivaylo Dimitrov <freemangordon@abv.bg>

Feel free to queue this along with the DSS patches:

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

[PATCH 1/2] ARM: omapfb: add coherent dma memory support

[Tony Lindgren]

* Tomi Valkeinen <tomi.valkeinen@ti.com> [131230 05:21]:
> The omapfb driver uses dma_alloc to reserve memory for the framebuffers.
> However, on some use cases, even when CMA is in use, it's quite probable
> that omapfb fails to allocate the fb, either due to not enough free dma
> memory, fragmented dma memory, or CMA failing to make enough contiguous
> space.
> 
> This patch adds a kernel cmdline parameter 'omapfb_vram' which can be
> used to give the size of a memory area reserved exclusively for omapfb,
> and optionally a physical address where the memory area is reserved.
> 
> The memory area is reserved with memblock, and assigned to omapfb with
> dma_declare_coherent_memory. The dma_alloc function will first try to
> allocate the fb from the coherent memory area, and if that fails, it'll
> use the normal method of allocation.
> 
> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
> Cc: Ivaylo Dimitrov <freemangordon@abv.bg>

Feel free to queue this along with the DSS patches:

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

Re: [PATCH 1/2] ARM: omapfb: add coherent dma memory support

[Tomi Valkeinen]

[-- Attachment #1: Type: text/plain, Size: 1443 bytes --]

On 2014-01-08 01:59, Tony Lindgren wrote:
> * Tomi Valkeinen <tomi.valkeinen@ti.com> [131230 05:21]:
>> The omapfb driver uses dma_alloc to reserve memory for the framebuffers.
>> However, on some use cases, even when CMA is in use, it's quite probable
>> that omapfb fails to allocate the fb, either due to not enough free dma
>> memory, fragmented dma memory, or CMA failing to make enough contiguous
>> space.
>>
>> This patch adds a kernel cmdline parameter 'omapfb_vram' which can be
>> used to give the size of a memory area reserved exclusively for omapfb,
>> and optionally a physical address where the memory area is reserved.
>>
>> The memory area is reserved with memblock, and assigned to omapfb with
>> dma_declare_coherent_memory. The dma_alloc function will first try to
>> allocate the fb from the coherent memory area, and if that fails, it'll
>> use the normal method of allocation.
>>
>> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
>> Cc: Ivaylo Dimitrov <freemangordon@abv.bg>
> 
> Feel free to queue this along with the DSS patches:
> 
> Acked-by: Tony Lindgren <tony@atomide.com>

Thanks.

This introduces new kernel boot parameter, and I haven't really had time
to test and think about this. If Ivaylo doesn't insist on this to be
merged for 3.14, I'd rather leave this for 3.15 as adding new parameter
that we need to support "forever" should be thought a bit more.

 Tomi



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]

Re: [PATCH 1/2] ARM: omapfb: add coherent dma memory support

[Tomi Valkeinen]

[-- Attachment #1: Type: text/plain, Size: 1443 bytes --]

On 2014-01-08 01:59, Tony Lindgren wrote:
> * Tomi Valkeinen <tomi.valkeinen@ti.com> [131230 05:21]:
>> The omapfb driver uses dma_alloc to reserve memory for the framebuffers.
>> However, on some use cases, even when CMA is in use, it's quite probable
>> that omapfb fails to allocate the fb, either due to not enough free dma
>> memory, fragmented dma memory, or CMA failing to make enough contiguous
>> space.
>>
>> This patch adds a kernel cmdline parameter 'omapfb_vram' which can be
>> used to give the size of a memory area reserved exclusively for omapfb,
>> and optionally a physical address where the memory area is reserved.
>>
>> The memory area is reserved with memblock, and assigned to omapfb with
>> dma_declare_coherent_memory. The dma_alloc function will first try to
>> allocate the fb from the coherent memory area, and if that fails, it'll
>> use the normal method of allocation.
>>
>> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
>> Cc: Ivaylo Dimitrov <freemangordon@abv.bg>
> 
> Feel free to queue this along with the DSS patches:
> 
> Acked-by: Tony Lindgren <tony@atomide.com>

Thanks.

This introduces new kernel boot parameter, and I haven't really had time
to test and think about this. If Ivaylo doesn't insist on this to be
merged for 3.14, I'd rather leave this for 3.15 as adding new parameter
that we need to support "forever" should be thought a bit more.

 Tomi



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]

[PATCH 1/2] ARM: omapfb: add coherent dma memory support

[Tomi Valkeinen]

On 2014-01-08 01:59, Tony Lindgren wrote:
> * Tomi Valkeinen <tomi.valkeinen@ti.com> [131230 05:21]:
>> The omapfb driver uses dma_alloc to reserve memory for the framebuffers.
>> However, on some use cases, even when CMA is in use, it's quite probable
>> that omapfb fails to allocate the fb, either due to not enough free dma
>> memory, fragmented dma memory, or CMA failing to make enough contiguous
>> space.
>>
>> This patch adds a kernel cmdline parameter 'omapfb_vram' which can be
>> used to give the size of a memory area reserved exclusively for omapfb,
>> and optionally a physical address where the memory area is reserved.
>>
>> The memory area is reserved with memblock, and assigned to omapfb with
>> dma_declare_coherent_memory. The dma_alloc function will first try to
>> allocate the fb from the coherent memory area, and if that fails, it'll
>> use the normal method of allocation.
>>
>> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
>> Cc: Ivaylo Dimitrov <freemangordon@abv.bg>
> 
> Feel free to queue this along with the DSS patches:
> 
> Acked-by: Tony Lindgren <tony@atomide.com>

Thanks.

This introduces new kernel boot parameter, and I haven't really had time
to test and think about this. If Ivaylo doesn't insist on this to be
merged for 3.14, I'd rather leave this for 3.15 as adding new parameter
that we need to support "forever" should be thought a bit more.

 Tomi


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 901 bytes
Desc: OpenPGP digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140108/5a22d129/attachment.sig>

RE: [PATCH 1/2] ARM: omapfb: add coherent dma memory support

[Hiremath, Vaibhav]

> -----Original Message-----
> From: Valkeinen, Tomi
> Sent: Wednesday, January 08, 2014 7:44 PM
> To: Tony Lindgren; Ivaylo Dimitrov
> Cc: Hiremath, Vaibhav; linux-omap@vger.kernel.org; linux-arm-
> kernel@lists.infradead.org; linux-fbdev@vger.kernel.org
> Subject: Re: [PATCH 1/2] ARM: omapfb: add coherent dma memory support
> 
> On 2014-01-08 01:59, Tony Lindgren wrote:
> > * Tomi Valkeinen <tomi.valkeinen@ti.com> [131230 05:21]:
> >> The omapfb driver uses dma_alloc to reserve memory for the framebuffers.
> >> However, on some use cases, even when CMA is in use, it's quite
> >> probable that omapfb fails to allocate the fb, either due to not
> >> enough free dma memory, fragmented dma memory, or CMA failing to make
> >> enough contiguous space.
> >>
> >> This patch adds a kernel cmdline parameter 'omapfb_vram' which can be
> >> used to give the size of a memory area reserved exclusively for
> >> omapfb, and optionally a physical address where the memory area is
> reserved.
> >>
> >> The memory area is reserved with memblock, and assigned to omapfb
> >> with dma_declare_coherent_memory. The dma_alloc function will first
> >> try to allocate the fb from the coherent memory area, and if that
> >> fails, it'll use the normal method of allocation.
> >>
> >> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
> >> Cc: Ivaylo Dimitrov <freemangordon@abv.bg>
> >
> > Feel free to queue this along with the DSS patches:
> >
> > Acked-by: Tony Lindgren <tony@atomide.com>
> 
> Thanks.
> 
> This introduces new kernel boot parameter, and I haven't really had time to test
> and think about this. If Ivaylo doesn't insist on this to be merged for 3.14, I'd
> rather leave this for 3.15 as adding new parameter that we need to support
> "forever" should be thought a bit more.
> 
Tomi,

I am seeing underflow issue on AM43x device if I use omapfb_vram argument.
Did you see this on OMAP?

I am using "omapfb_vram\x10M@0xA0000000", and I believe it is correct way of usage.

Thanks,
Vaibhav


>  Tomi
> 

RE: [PATCH 1/2] ARM: omapfb: add coherent dma memory support

[Hiremath, Vaibhav]

> -----Original Message-----
> From: Valkeinen, Tomi
> Sent: Wednesday, January 08, 2014 7:44 PM
> To: Tony Lindgren; Ivaylo Dimitrov
> Cc: Hiremath, Vaibhav; linux-omap@vger.kernel.org; linux-arm-
> kernel@lists.infradead.org; linux-fbdev@vger.kernel.org
> Subject: Re: [PATCH 1/2] ARM: omapfb: add coherent dma memory support
> 
> On 2014-01-08 01:59, Tony Lindgren wrote:
> > * Tomi Valkeinen <tomi.valkeinen@ti.com> [131230 05:21]:
> >> The omapfb driver uses dma_alloc to reserve memory for the framebuffers.
> >> However, on some use cases, even when CMA is in use, it's quite
> >> probable that omapfb fails to allocate the fb, either due to not
> >> enough free dma memory, fragmented dma memory, or CMA failing to make
> >> enough contiguous space.
> >>
> >> This patch adds a kernel cmdline parameter 'omapfb_vram' which can be
> >> used to give the size of a memory area reserved exclusively for
> >> omapfb, and optionally a physical address where the memory area is
> reserved.
> >>
> >> The memory area is reserved with memblock, and assigned to omapfb
> >> with dma_declare_coherent_memory. The dma_alloc function will first
> >> try to allocate the fb from the coherent memory area, and if that
> >> fails, it'll use the normal method of allocation.
> >>
> >> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
> >> Cc: Ivaylo Dimitrov <freemangordon@abv.bg>
> >
> > Feel free to queue this along with the DSS patches:
> >
> > Acked-by: Tony Lindgren <tony@atomide.com>
> 
> Thanks.
> 
> This introduces new kernel boot parameter, and I haven't really had time to test
> and think about this. If Ivaylo doesn't insist on this to be merged for 3.14, I'd
> rather leave this for 3.15 as adding new parameter that we need to support
> "forever" should be thought a bit more.
> 
Tomi,

I am seeing underflow issue on AM43x device if I use omapfb_vram argument.
Did you see this on OMAP?

I am using "omapfb_vram=10M@0xA0000000", and I believe it is correct way of usage.

Thanks,
Vaibhav


>  Tomi
> 

[PATCH 1/2] ARM: omapfb: add coherent dma memory support

[Hiremath, Vaibhav]

> -----Original Message-----
> From: Valkeinen, Tomi
> Sent: Wednesday, January 08, 2014 7:44 PM
> To: Tony Lindgren; Ivaylo Dimitrov
> Cc: Hiremath, Vaibhav; linux-omap at vger.kernel.org; linux-arm-
> kernel at lists.infradead.org; linux-fbdev at vger.kernel.org
> Subject: Re: [PATCH 1/2] ARM: omapfb: add coherent dma memory support
> 
> On 2014-01-08 01:59, Tony Lindgren wrote:
> > * Tomi Valkeinen <tomi.valkeinen@ti.com> [131230 05:21]:
> >> The omapfb driver uses dma_alloc to reserve memory for the framebuffers.
> >> However, on some use cases, even when CMA is in use, it's quite
> >> probable that omapfb fails to allocate the fb, either due to not
> >> enough free dma memory, fragmented dma memory, or CMA failing to make
> >> enough contiguous space.
> >>
> >> This patch adds a kernel cmdline parameter 'omapfb_vram' which can be
> >> used to give the size of a memory area reserved exclusively for
> >> omapfb, and optionally a physical address where the memory area is
> reserved.
> >>
> >> The memory area is reserved with memblock, and assigned to omapfb
> >> with dma_declare_coherent_memory. The dma_alloc function will first
> >> try to allocate the fb from the coherent memory area, and if that
> >> fails, it'll use the normal method of allocation.
> >>
> >> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
> >> Cc: Ivaylo Dimitrov <freemangordon@abv.bg>
> >
> > Feel free to queue this along with the DSS patches:
> >
> > Acked-by: Tony Lindgren <tony@atomide.com>
> 
> Thanks.
> 
> This introduces new kernel boot parameter, and I haven't really had time to test
> and think about this. If Ivaylo doesn't insist on this to be merged for 3.14, I'd
> rather leave this for 3.15 as adding new parameter that we need to support
> "forever" should be thought a bit more.
> 
Tomi,

I am seeing underflow issue on AM43x device if I use omapfb_vram argument.
Did you see this on OMAP?

I am using "omapfb_vram=10M at 0xA0000000", and I believe it is correct way of usage.

Thanks,
Vaibhav


>  Tomi
> 

Re: RE: [PATCH 1/2] ARM: omapfb: add coherent dma memory support

[Ivaylo Dimitrov]

On 09.01.2014 07:06, Hiremath, Vaibhav wrote:
> Tomi,
>
> I am seeing underflow issue on AM43x device if I use omapfb_vram argument.
> Did you see this on OMAP?
>
> I am using "omapfb_vram\x10M@0xA0000000", and I believe it is correct way of usage.
>
> Thanks,
> Vaibhav
>

AFAIK underflow interrupts could come from badly calculated DSS core 
clock or bad HW resizer setup and should be unrelated to the memory 
allocation. It might be something similar to the problem I have on N900 
- see https://lkml.org/lkml/2014/1/6/173

Is it possible to upload the video you have problems with, so me to test 
it on N900? So far I didn't see any underflow issues on it (N900 is 
OMAP3, in case you're not aware), no matter the resolution of the videos 
I played(up to 720p), however I didn't test the part that allocates the 
memory on a pre-defined address. Though I don't think that should matter.

Ivo

Re: RE: [PATCH 1/2] ARM: omapfb: add coherent dma memory support

[Ivaylo Dimitrov]

On 09.01.2014 07:06, Hiremath, Vaibhav wrote:
> Tomi,
>
> I am seeing underflow issue on AM43x device if I use omapfb_vram argument.
> Did you see this on OMAP?
>
> I am using "omapfb_vram=10M@0xA0000000", and I believe it is correct way of usage.
>
> Thanks,
> Vaibhav
>

AFAIK underflow interrupts could come from badly calculated DSS core 
clock or bad HW resizer setup and should be unrelated to the memory 
allocation. It might be something similar to the problem I have on N900 
- see https://lkml.org/lkml/2014/1/6/173

Is it possible to upload the video you have problems with, so me to test 
it on N900? So far I didn't see any underflow issues on it (N900 is 
OMAP3, in case you're not aware), no matter the resolution of the videos 
I played(up to 720p), however I didn't test the part that allocates the 
memory on a pre-defined address. Though I don't think that should matter.

Ivo

[PATCH 1/2] ARM: omapfb: add coherent dma memory support

[Ivaylo Dimitrov]

On 09.01.2014 07:06, Hiremath, Vaibhav wrote:
> Tomi,
>
> I am seeing underflow issue on AM43x device if I use omapfb_vram argument.
> Did you see this on OMAP?
>
> I am using "omapfb_vram=10M at 0xA0000000", and I believe it is correct way of usage.
>
> Thanks,
> Vaibhav
>

AFAIK underflow interrupts could come from badly calculated DSS core 
clock or bad HW resizer setup and should be unrelated to the memory 
allocation. It might be something similar to the problem I have on N900 
- see https://lkml.org/lkml/2014/1/6/173

Is it possible to upload the video you have problems with, so me to test 
it on N900? So far I didn't see any underflow issues on it (N900 is 
OMAP3, in case you're not aware), no matter the resolution of the videos 
I played(up to 720p), however I didn't test the part that allocates the 
memory on a pre-defined address. Though I don't think that should matter.

Ivo

RE: RE: [PATCH 1/2] ARM: omapfb: add coherent dma memory support

[Hiremath, Vaibhav]

> -----Original Message-----
> From: linux-omap-owner@vger.kernel.org [mailto:linux-omap-
> owner@vger.kernel.org] On Behalf Of Ivaylo Dimitrov
> Sent: Thursday, January 09, 2014 1:05 PM
> To: Hiremath, Vaibhav; Valkeinen, Tomi; Tony Lindgren; Ivaylo Dimitrov
> Cc: linux-omap@vger.kernel.org; linux-arm-kernel@lists.infradead.org; linux-
> fbdev@vger.kernel.org
> Subject: Re: RE: [PATCH 1/2] ARM: omapfb: add coherent dma memory support
> 
> 
> On 09.01.2014 07:06, Hiremath, Vaibhav wrote:
> > Tomi,
> >
> > I am seeing underflow issue on AM43x device if I use omapfb_vram argument.
> > Did you see this on OMAP?
> >
> > I am using "omapfb_vram\x10M@0xA0000000", and I believe it is correct way
> of usage.
> >
> > Thanks,
> > Vaibhav
> >
> 
> AFAIK underflow interrupts could come from badly calculated DSS core clock or
> bad HW resizer setup and should be unrelated to the memory allocation. It
> might be something similar to the problem I have on N900
> - see https://lkml.org/lkml/2014/1/6/173
> 

I can see the difference when I really "omapfb_vram" command line argument.

Without omapfb_vram in bootargs 
-------------------------------------------
bootargs=console=ttyO0,115200n8 root=/dev/mmcblk0p2 rw rootfstype=ext3 rootwait mem\x128M 
consoleblank=0 clocksource=gp_timer consoleblank=0 earlyprintk omapfb.debug=y omapdss.debug=y

I do not get UNDERFLOW during boot.

With omapfb_vram in the bootargs
---------------------------------------------
bootargs=console=ttyO0,115200n8 root=/dev/mmcblk0p2 rw rootfstype=ext3 rootwait mem\x128M 
consoleblank=0 clocksource=gp_timer consoleblank=0 earlyprintk omapfb_vram\x10M@0xA0000000 
omapfb.debug=y omapdss.debug=y

I always get UNDERFLOW during boot itself.

> Is it possible to upload the video you have problems with, so me to test it on
> N900? So far I didn't see any underflow issues on it (N900 is OMAP3, in case
> you're not aware), no matter the resolution of the videos I played(up to 720p),
> however I didn't test the part that allocates the memory on a pre-defined
> address. Though I don't think that should matter.

No, that's what is causing issue to me. Can you try predefined address flow?
Just to highlight, I get UNDERFLOW during boot itself, immediately when it gets mapped to userspace.

Boot LOG:

[    1.443021] OMAPFB: omapfb_probe
[    1.446137] OMAPFB: create 3 framebuffers
[    1.446178] OMAPFB: fb_infos allocated
[    1.446198] OMAPFB: allocating 1536000 bytes for fb 0
[    1.451044] OMAPFB: allocated VRAM paddr a0000000, vaddr ca000000
[    1.451069] OMAPFB: region0 phys a0000000 virt ca000000 size\x1536000
[    1.451086] OMAPFB: region1 phys 00000000 virt   (null) size=0
[    1.451100] OMAPFB: region2 phys 00000000 virt   (null) size=0
[    1.451109] OMAPFB: fbmems allocated
[    1.451363] OMAPFB: check_fb_var 0
[    1.451386] OMAPFB: max frame size 1536000, line size 3200
[    1.451401] OMAPFB: xres = 800, yres = 480, vxres = 800, vyres = 480
[    1.451414] OMAPFB: set_fb_fix
[    1.460278] OMAPFB: fb_infos initialized
[    1.465325] OMAPFB: set_par(0)
[    1.465384] OMAPFB: set_fb_fix
[    1.465393] OMAPFB: apply_changes, fb 0, ovl 0
[    1.465443] OMAPFB: setup_overlay 0, posx 0, posy 0, outw 800, outh 480
[    1.465450] OMAPFB: paddr a0000000
[    1.465592] OMAPFB: pan_display(0)
[    1.465600] OMAPFB: setcmap
[    1.465607] OMAPFB: setcmap
[    1.474504] Console: switching to colour frame buffer device 100x30
[    1.474528] OMAPFB: pan_display(0)
[    1.474534] OMAPFB: setcmap
[    1.482185] OMAPFB: setcmap
[    1.484808] OMAPFB: framebuffers registered
[    1.484839] OMAPFB: apply_changes, fb 0, ovl 0
[    1.484857] OMAPFB: setup_overlay 0, posx 0, posy 0, outw 800, outh 480
[    1.484870] OMAPFB: paddr a0000000
[    1.484919] OMAPFB: apply_changes, fb 1, ovl 1
[    1.485010] OMAPFB: apply_changes, fb 2, ovl 2
[    1.485111] OMAPFB: create_framebuffers done
[    1.485128] OMAPFB: mgr->apply'ed
[    1.489793] OMAPFB: create sysfs for fbs
[    1.489816] OMAPFB: create sysfs for fbs

....

[    4.822549] Freeing unused kernel memory: 440K (c0919000 - c0987000)
[    5.276615] OMAPFB: pan_display(0)
[    5.276625] OMAPFB: setcmap
[    5.276635] OMAPFB: setcmap
[    5.293518] OMAPFB: user mmap region start a0000000, len 1536000, off 0
[    5.300171] omapdss APPLY error: FIFO UNDERFLOW on gfx, disabling the overlay

...

[   20.499076] OMAPFB: pan_display(0)
[   20.499085] OMAPFB: setcmap
[   20.499093] OMAPFB: setcmap
[   20.544419] OMAPFB: check_var(0)
[   20.544631] OMAPFB: check_fb_var 0
[   20.544644] OMAPFB: max frame size 1536000, line size 3200
[   20.544651] OMAPFB: xres = 800, yres = 480, vxres = 800, vyres = 480
[   20.544699] OMAPFB: set_par(0)
[   20.544706] OMAPFB: set_fb_fix
[   20.544712] OMAPFB: apply_changes, fb 0, ovl 0
[   20.544762] OMAPFB: setup_overlay 0, posx 0, posy 0, outw 800, outh 480
[   20.544767] OMAPFB: paddr a0000000
[   20.544798] OMAPFB: pan_display(0)
[   20.544802] OMAPFB: setcmap
[   20.544859] OMAPFB: pan_display(0)
[   20.544865] OMAPFB: setcmap
[   20.544872] OMAPFB: setcmap
[   20.553841] OMAPFB: setcmap
[   23.002160] OMAPFB: user mmap region start a0000000, len 1536000, off 0

Thanks,
Vaibhav

RE: RE: [PATCH 1/2] ARM: omapfb: add coherent dma memory support

[Hiremath, Vaibhav]

> -----Original Message-----
> From: linux-omap-owner@vger.kernel.org [mailto:linux-omap-
> owner@vger.kernel.org] On Behalf Of Ivaylo Dimitrov
> Sent: Thursday, January 09, 2014 1:05 PM
> To: Hiremath, Vaibhav; Valkeinen, Tomi; Tony Lindgren; Ivaylo Dimitrov
> Cc: linux-omap@vger.kernel.org; linux-arm-kernel@lists.infradead.org; linux-
> fbdev@vger.kernel.org
> Subject: Re: RE: [PATCH 1/2] ARM: omapfb: add coherent dma memory support
> 
> 
> On 09.01.2014 07:06, Hiremath, Vaibhav wrote:
> > Tomi,
> >
> > I am seeing underflow issue on AM43x device if I use omapfb_vram argument.
> > Did you see this on OMAP?
> >
> > I am using "omapfb_vram=10M@0xA0000000", and I believe it is correct way
> of usage.
> >
> > Thanks,
> > Vaibhav
> >
> 
> AFAIK underflow interrupts could come from badly calculated DSS core clock or
> bad HW resizer setup and should be unrelated to the memory allocation. It
> might be something similar to the problem I have on N900
> - see https://lkml.org/lkml/2014/1/6/173
> 

I can see the difference when I really "omapfb_vram" command line argument.

Without omapfb_vram in bootargs 
-------------------------------------------
bootargs=console=ttyO0,115200n8 root=/dev/mmcblk0p2 rw rootfstype=ext3 rootwait mem=128M 
consoleblank=0 clocksource=gp_timer consoleblank=0 earlyprintk omapfb.debug=y omapdss.debug=y

I do not get UNDERFLOW during boot.

With omapfb_vram in the bootargs
---------------------------------------------
bootargs=console=ttyO0,115200n8 root=/dev/mmcblk0p2 rw rootfstype=ext3 rootwait mem=128M 
consoleblank=0 clocksource=gp_timer consoleblank=0 earlyprintk omapfb_vram=10M@0xA0000000 
omapfb.debug=y omapdss.debug=y

I always get UNDERFLOW during boot itself.

> Is it possible to upload the video you have problems with, so me to test it on
> N900? So far I didn't see any underflow issues on it (N900 is OMAP3, in case
> you're not aware), no matter the resolution of the videos I played(up to 720p),
> however I didn't test the part that allocates the memory on a pre-defined
> address. Though I don't think that should matter.

No, that's what is causing issue to me. Can you try predefined address flow?
Just to highlight, I get UNDERFLOW during boot itself, immediately when it gets mapped to userspace.

Boot LOG:

[    1.443021] OMAPFB: omapfb_probe
[    1.446137] OMAPFB: create 3 framebuffers
[    1.446178] OMAPFB: fb_infos allocated
[    1.446198] OMAPFB: allocating 1536000 bytes for fb 0
[    1.451044] OMAPFB: allocated VRAM paddr a0000000, vaddr ca000000
[    1.451069] OMAPFB: region0 phys a0000000 virt ca000000 size=1536000
[    1.451086] OMAPFB: region1 phys 00000000 virt   (null) size=0
[    1.451100] OMAPFB: region2 phys 00000000 virt   (null) size=0
[    1.451109] OMAPFB: fbmems allocated
[    1.451363] OMAPFB: check_fb_var 0
[    1.451386] OMAPFB: max frame size 1536000, line size 3200
[    1.451401] OMAPFB: xres = 800, yres = 480, vxres = 800, vyres = 480
[    1.451414] OMAPFB: set_fb_fix
[    1.460278] OMAPFB: fb_infos initialized
[    1.465325] OMAPFB: set_par(0)
[    1.465384] OMAPFB: set_fb_fix
[    1.465393] OMAPFB: apply_changes, fb 0, ovl 0
[    1.465443] OMAPFB: setup_overlay 0, posx 0, posy 0, outw 800, outh 480
[    1.465450] OMAPFB: paddr a0000000
[    1.465592] OMAPFB: pan_display(0)
[    1.465600] OMAPFB: setcmap
[    1.465607] OMAPFB: setcmap
[    1.474504] Console: switching to colour frame buffer device 100x30
[    1.474528] OMAPFB: pan_display(0)
[    1.474534] OMAPFB: setcmap
[    1.482185] OMAPFB: setcmap
[    1.484808] OMAPFB: framebuffers registered
[    1.484839] OMAPFB: apply_changes, fb 0, ovl 0
[    1.484857] OMAPFB: setup_overlay 0, posx 0, posy 0, outw 800, outh 480
[    1.484870] OMAPFB: paddr a0000000
[    1.484919] OMAPFB: apply_changes, fb 1, ovl 1
[    1.485010] OMAPFB: apply_changes, fb 2, ovl 2
[    1.485111] OMAPFB: create_framebuffers done
[    1.485128] OMAPFB: mgr->apply'ed
[    1.489793] OMAPFB: create sysfs for fbs
[    1.489816] OMAPFB: create sysfs for fbs

....

[    4.822549] Freeing unused kernel memory: 440K (c0919000 - c0987000)
[    5.276615] OMAPFB: pan_display(0)
[    5.276625] OMAPFB: setcmap
[    5.276635] OMAPFB: setcmap
[    5.293518] OMAPFB: user mmap region start a0000000, len 1536000, off 0
[    5.300171] omapdss APPLY error: FIFO UNDERFLOW on gfx, disabling the overlay

...

[   20.499076] OMAPFB: pan_display(0)
[   20.499085] OMAPFB: setcmap
[   20.499093] OMAPFB: setcmap
[   20.544419] OMAPFB: check_var(0)
[   20.544631] OMAPFB: check_fb_var 0
[   20.544644] OMAPFB: max frame size 1536000, line size 3200
[   20.544651] OMAPFB: xres = 800, yres = 480, vxres = 800, vyres = 480
[   20.544699] OMAPFB: set_par(0)
[   20.544706] OMAPFB: set_fb_fix
[   20.544712] OMAPFB: apply_changes, fb 0, ovl 0
[   20.544762] OMAPFB: setup_overlay 0, posx 0, posy 0, outw 800, outh 480
[   20.544767] OMAPFB: paddr a0000000
[   20.544798] OMAPFB: pan_display(0)
[   20.544802] OMAPFB: setcmap
[   20.544859] OMAPFB: pan_display(0)
[   20.544865] OMAPFB: setcmap
[   20.544872] OMAPFB: setcmap
[   20.553841] OMAPFB: setcmap
[   23.002160] OMAPFB: user mmap region start a0000000, len 1536000, off 0

Thanks,
Vaibhav

[PATCH 1/2] ARM: omapfb: add coherent dma memory support

[Hiremath, Vaibhav]

> -----Original Message-----
> From: linux-omap-owner at vger.kernel.org [mailto:linux-omap-
> owner at vger.kernel.org] On Behalf Of Ivaylo Dimitrov
> Sent: Thursday, January 09, 2014 1:05 PM
> To: Hiremath, Vaibhav; Valkeinen, Tomi; Tony Lindgren; Ivaylo Dimitrov
> Cc: linux-omap at vger.kernel.org; linux-arm-kernel at lists.infradead.org; linux-
> fbdev at vger.kernel.org
> Subject: Re: RE: [PATCH 1/2] ARM: omapfb: add coherent dma memory support
> 
> 
> On 09.01.2014 07:06, Hiremath, Vaibhav wrote:
> > Tomi,
> >
> > I am seeing underflow issue on AM43x device if I use omapfb_vram argument.
> > Did you see this on OMAP?
> >
> > I am using "omapfb_vram=10M at 0xA0000000", and I believe it is correct way
> of usage.
> >
> > Thanks,
> > Vaibhav
> >
> 
> AFAIK underflow interrupts could come from badly calculated DSS core clock or
> bad HW resizer setup and should be unrelated to the memory allocation. It
> might be something similar to the problem I have on N900
> - see https://lkml.org/lkml/2014/1/6/173
> 

I can see the difference when I really "omapfb_vram" command line argument.

Without omapfb_vram in bootargs 
-------------------------------------------
bootargs=console=ttyO0,115200n8 root=/dev/mmcblk0p2 rw rootfstype=ext3 rootwait mem=128M 
consoleblank=0 clocksource=gp_timer consoleblank=0 earlyprintk omapfb.debug=y omapdss.debug=y

I do not get UNDERFLOW during boot.

With omapfb_vram in the bootargs
---------------------------------------------
bootargs=console=ttyO0,115200n8 root=/dev/mmcblk0p2 rw rootfstype=ext3 rootwait mem=128M 
consoleblank=0 clocksource=gp_timer consoleblank=0 earlyprintk omapfb_vram=10M at 0xA0000000 
omapfb.debug=y omapdss.debug=y

I always get UNDERFLOW during boot itself.

> Is it possible to upload the video you have problems with, so me to test it on
> N900? So far I didn't see any underflow issues on it (N900 is OMAP3, in case
> you're not aware), no matter the resolution of the videos I played(up to 720p),
> however I didn't test the part that allocates the memory on a pre-defined
> address. Though I don't think that should matter.

No, that's what is causing issue to me. Can you try predefined address flow?
Just to highlight, I get UNDERFLOW during boot itself, immediately when it gets mapped to userspace.

Boot LOG:

[    1.443021] OMAPFB: omapfb_probe
[    1.446137] OMAPFB: create 3 framebuffers
[    1.446178] OMAPFB: fb_infos allocated
[    1.446198] OMAPFB: allocating 1536000 bytes for fb 0
[    1.451044] OMAPFB: allocated VRAM paddr a0000000, vaddr ca000000
[    1.451069] OMAPFB: region0 phys a0000000 virt ca000000 size=1536000
[    1.451086] OMAPFB: region1 phys 00000000 virt   (null) size=0
[    1.451100] OMAPFB: region2 phys 00000000 virt   (null) size=0
[    1.451109] OMAPFB: fbmems allocated
[    1.451363] OMAPFB: check_fb_var 0
[    1.451386] OMAPFB: max frame size 1536000, line size 3200
[    1.451401] OMAPFB: xres = 800, yres = 480, vxres = 800, vyres = 480
[    1.451414] OMAPFB: set_fb_fix
[    1.460278] OMAPFB: fb_infos initialized
[    1.465325] OMAPFB: set_par(0)
[    1.465384] OMAPFB: set_fb_fix
[    1.465393] OMAPFB: apply_changes, fb 0, ovl 0
[    1.465443] OMAPFB: setup_overlay 0, posx 0, posy 0, outw 800, outh 480
[    1.465450] OMAPFB: paddr a0000000
[    1.465592] OMAPFB: pan_display(0)
[    1.465600] OMAPFB: setcmap
[    1.465607] OMAPFB: setcmap
[    1.474504] Console: switching to colour frame buffer device 100x30
[    1.474528] OMAPFB: pan_display(0)
[    1.474534] OMAPFB: setcmap
[    1.482185] OMAPFB: setcmap
[    1.484808] OMAPFB: framebuffers registered
[    1.484839] OMAPFB: apply_changes, fb 0, ovl 0
[    1.484857] OMAPFB: setup_overlay 0, posx 0, posy 0, outw 800, outh 480
[    1.484870] OMAPFB: paddr a0000000
[    1.484919] OMAPFB: apply_changes, fb 1, ovl 1
[    1.485010] OMAPFB: apply_changes, fb 2, ovl 2
[    1.485111] OMAPFB: create_framebuffers done
[    1.485128] OMAPFB: mgr->apply'ed
[    1.489793] OMAPFB: create sysfs for fbs
[    1.489816] OMAPFB: create sysfs for fbs

....

[    4.822549] Freeing unused kernel memory: 440K (c0919000 - c0987000)
[    5.276615] OMAPFB: pan_display(0)
[    5.276625] OMAPFB: setcmap
[    5.276635] OMAPFB: setcmap
[    5.293518] OMAPFB: user mmap region start a0000000, len 1536000, off 0
[    5.300171] omapdss APPLY error: FIFO UNDERFLOW on gfx, disabling the overlay

...

[   20.499076] OMAPFB: pan_display(0)
[   20.499085] OMAPFB: setcmap
[   20.499093] OMAPFB: setcmap
[   20.544419] OMAPFB: check_var(0)
[   20.544631] OMAPFB: check_fb_var 0
[   20.544644] OMAPFB: max frame size 1536000, line size 3200
[   20.544651] OMAPFB: xres = 800, yres = 480, vxres = 800, vyres = 480
[   20.544699] OMAPFB: set_par(0)
[   20.544706] OMAPFB: set_fb_fix
[   20.544712] OMAPFB: apply_changes, fb 0, ovl 0
[   20.544762] OMAPFB: setup_overlay 0, posx 0, posy 0, outw 800, outh 480
[   20.544767] OMAPFB: paddr a0000000
[   20.544798] OMAPFB: pan_display(0)
[   20.544802] OMAPFB: setcmap
[   20.544859] OMAPFB: pan_display(0)
[   20.544865] OMAPFB: setcmap
[   20.544872] OMAPFB: setcmap
[   20.553841] OMAPFB: setcmap
[   23.002160] OMAPFB: user mmap region start a0000000, len 1536000, off 0

Thanks,
Vaibhav

Re: [PATCH 1/2] ARM: omapfb: add coherent dma memory support

[Tomi Valkeinen]

[-- Attachment #1: Type: text/plain, Size: 1271 bytes --]

On 2014-01-09 07:06, Hiremath, Vaibhav wrote:

> I am seeing underflow issue on AM43x device if I use omapfb_vram argument.
> Did you see this on OMAP?
> 
> I am using "omapfb_vram=10M@0xA0000000", and I believe it is correct way of usage.

Hmm ok... The AM4x seems to have issues anyway, as we're seeing
underflows easily in other situations also.

Well, there's a small difference in the allocation. The normal dma alloc
uses dma_alloc_attrs() and passes DMA_ATTR_WRITE_COMBINE as a flag,
whereas allocating from the absolute address just uses the piece of
memory. I couldn't find how to set write-combine for the abs memory area.

Then again, that's for CPU caching, so I don't see why it would affect
DSS as such (but that's still something we should measure, cpu
read/write perf for normal and abs allocation).

The only thought I have is that somehow the reserved memory area is
missing some configuration that is done for the rest of the memory. But
that's purely a guess, this is totally out of my area of expertise...

Vaibhav, just to be sure, can you run both with normal dma_alloc and
with the reserve, and verify that the dispc register dumps are the same?
I don't see how they could be different, but just to be sure.

 Tomi



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]

Re: [PATCH 1/2] ARM: omapfb: add coherent dma memory support

[Tomi Valkeinen]

[-- Attachment #1.1: Type: text/plain, Size: 1271 bytes --]

On 2014-01-09 07:06, Hiremath, Vaibhav wrote:

> I am seeing underflow issue on AM43x device if I use omapfb_vram argument.
> Did you see this on OMAP?
> 
> I am using "omapfb_vram=10M@0xA0000000", and I believe it is correct way of usage.

Hmm ok... The AM4x seems to have issues anyway, as we're seeing
underflows easily in other situations also.

Well, there's a small difference in the allocation. The normal dma alloc
uses dma_alloc_attrs() and passes DMA_ATTR_WRITE_COMBINE as a flag,
whereas allocating from the absolute address just uses the piece of
memory. I couldn't find how to set write-combine for the abs memory area.

Then again, that's for CPU caching, so I don't see why it would affect
DSS as such (but that's still something we should measure, cpu
read/write perf for normal and abs allocation).

The only thought I have is that somehow the reserved memory area is
missing some configuration that is done for the rest of the memory. But
that's purely a guess, this is totally out of my area of expertise...

Vaibhav, just to be sure, can you run both with normal dma_alloc and
with the reserve, and verify that the dispc register dumps are the same?
I don't see how they could be different, but just to be sure.

 Tomi



[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]

[-- Attachment #2: Type: text/plain, Size: 176 bytes --]

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH 1/2] ARM: omapfb: add coherent dma memory support

[Tomi Valkeinen]

On 2014-01-09 07:06, Hiremath, Vaibhav wrote:

> I am seeing underflow issue on AM43x device if I use omapfb_vram argument.
> Did you see this on OMAP?
> 
> I am using "omapfb_vram=10M at 0xA0000000", and I believe it is correct way of usage.

Hmm ok... The AM4x seems to have issues anyway, as we're seeing
underflows easily in other situations also.

Well, there's a small difference in the allocation. The normal dma alloc
uses dma_alloc_attrs() and passes DMA_ATTR_WRITE_COMBINE as a flag,
whereas allocating from the absolute address just uses the piece of
memory. I couldn't find how to set write-combine for the abs memory area.

Then again, that's for CPU caching, so I don't see why it would affect
DSS as such (but that's still something we should measure, cpu
read/write perf for normal and abs allocation).

The only thought I have is that somehow the reserved memory area is
missing some configuration that is done for the rest of the memory. But
that's purely a guess, this is totally out of my area of expertise...

Vaibhav, just to be sure, can you run both with normal dma_alloc and
with the reserve, and verify that the dispc register dumps are the same?
I don't see how they could be different, but just to be sure.

 Tomi


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 901 bytes
Desc: OpenPGP digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140109/72c0c420/attachment.sig>

Re: [PATCH 1/2] ARM: omapfb: add coherent dma memory support

[Tomi Valkeinen]

[-- Attachment #1: Type: text/plain, Size: 1042 bytes --]

On 2014-01-09 10:08, Hiremath, Vaibhav wrote:

> No, that's what is causing issue to me. Can you try predefined address flow?
> Just to highlight, I get UNDERFLOW during boot itself, immediately when it gets mapped to userspace.
> 
> Boot LOG:
> 

> [    4.822549] Freeing unused kernel memory: 440K (c0919000 - c0987000)
> [    5.276615] OMAPFB: pan_display(0)
> [    5.276625] OMAPFB: setcmap
> [    5.276635] OMAPFB: setcmap
> [    5.293518] OMAPFB: user mmap region start a0000000, len 1536000, off 0
> [    5.300171] omapdss APPLY error: FIFO UNDERFLOW on gfx, disabling the overlay

Hmm that's interesting... So you have some tool that's ran early, which
draws something on the screen? Or maybe that's X starting?

Ah... I think I understand now. As I mentioned, AM4x has issues already.
I think the CPU/others can block DSS when accessing memory. So, if we
have bad caching for the mapped framebuffer, the CPU will use more
bandwidth when reading/writing to it, and that will cause DSS to underflow.

 Tomi



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]

Re: [PATCH 1/2] ARM: omapfb: add coherent dma memory support

[Tomi Valkeinen]

[-- Attachment #1.1: Type: text/plain, Size: 1042 bytes --]

On 2014-01-09 10:08, Hiremath, Vaibhav wrote:

> No, that's what is causing issue to me. Can you try predefined address flow?
> Just to highlight, I get UNDERFLOW during boot itself, immediately when it gets mapped to userspace.
> 
> Boot LOG:
> 

> [    4.822549] Freeing unused kernel memory: 440K (c0919000 - c0987000)
> [    5.276615] OMAPFB: pan_display(0)
> [    5.276625] OMAPFB: setcmap
> [    5.276635] OMAPFB: setcmap
> [    5.293518] OMAPFB: user mmap region start a0000000, len 1536000, off 0
> [    5.300171] omapdss APPLY error: FIFO UNDERFLOW on gfx, disabling the overlay

Hmm that's interesting... So you have some tool that's ran early, which
draws something on the screen? Or maybe that's X starting?

Ah... I think I understand now. As I mentioned, AM4x has issues already.
I think the CPU/others can block DSS when accessing memory. So, if we
have bad caching for the mapped framebuffer, the CPU will use more
bandwidth when reading/writing to it, and that will cause DSS to underflow.

 Tomi



[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]

[-- Attachment #2: Type: text/plain, Size: 176 bytes --]

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH 1/2] ARM: omapfb: add coherent dma memory support

[Tomi Valkeinen]

On 2014-01-09 10:08, Hiremath, Vaibhav wrote:

> No, that's what is causing issue to me. Can you try predefined address flow?
> Just to highlight, I get UNDERFLOW during boot itself, immediately when it gets mapped to userspace.
> 
> Boot LOG:
> 

> [    4.822549] Freeing unused kernel memory: 440K (c0919000 - c0987000)
> [    5.276615] OMAPFB: pan_display(0)
> [    5.276625] OMAPFB: setcmap
> [    5.276635] OMAPFB: setcmap
> [    5.293518] OMAPFB: user mmap region start a0000000, len 1536000, off 0
> [    5.300171] omapdss APPLY error: FIFO UNDERFLOW on gfx, disabling the overlay

Hmm that's interesting... So you have some tool that's ran early, which
draws something on the screen? Or maybe that's X starting?

Ah... I think I understand now. As I mentioned, AM4x has issues already.
I think the CPU/others can block DSS when accessing memory. So, if we
have bad caching for the mapped framebuffer, the CPU will use more
bandwidth when reading/writing to it, and that will cause DSS to underflow.

 Tomi


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 901 bytes
Desc: OpenPGP digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140109/94e5177e/attachment-0001.sig>

RE: [PATCH 1/2] ARM: omapfb: add coherent dma memory support

[Hiremath, Vaibhav]

> -----Original Message-----
> From: Valkeinen, Tomi
> Sent: Thursday, January 09, 2014 1:52 PM
> To: Hiremath, Vaibhav; Ivaylo Dimitrov
> Cc: Tony Lindgren; linux-omap@vger.kernel.org; linux-arm-
> kernel@lists.infradead.org; linux-fbdev@vger.kernel.org
> Subject: Re: [PATCH 1/2] ARM: omapfb: add coherent dma memory support
> 
> On 2014-01-09 07:06, Hiremath, Vaibhav wrote:
> 
> > I am seeing underflow issue on AM43x device if I use omapfb_vram argument.
> > Did you see this on OMAP?
> >
> > I am using "omapfb_vram\x10M@0xA0000000", and I believe it is correct way
> of usage.
> 
> Hmm ok... The AM4x seems to have issues anyway, as we're seeing underflows
> easily in other situations also.
> 
> Well, there's a small difference in the allocation. The normal dma alloc uses
> dma_alloc_attrs() and passes DMA_ATTR_WRITE_COMBINE as a flag, whereas
> allocating from the absolute address just uses the piece of memory. I couldn't
> find how to set write-combine for the abs memory area.
> 
> Then again, that's for CPU caching, so I don't see why it would affect DSS as
> such (but that's still something we should measure, cpu read/write perf for
> normal and abs allocation).
> 
> The only thought I have is that somehow the reserved memory area is missing
> some configuration that is done for the rest of the memory. But that's purely a
> guess, this is totally out of my area of expertise...
> 
> Vaibhav, just to be sure, can you run both with normal dma_alloc and with the
> reserve, and verify that the dispc register dumps are the same?
> I don't see how they could be different, but just to be sure.
> 

Will check and update you shortly.

Thanks,
Vaibhav

RE: [PATCH 1/2] ARM: omapfb: add coherent dma memory support

[Hiremath, Vaibhav]

> -----Original Message-----
> From: Valkeinen, Tomi
> Sent: Thursday, January 09, 2014 1:52 PM
> To: Hiremath, Vaibhav; Ivaylo Dimitrov
> Cc: Tony Lindgren; linux-omap@vger.kernel.org; linux-arm-
> kernel@lists.infradead.org; linux-fbdev@vger.kernel.org
> Subject: Re: [PATCH 1/2] ARM: omapfb: add coherent dma memory support
> 
> On 2014-01-09 07:06, Hiremath, Vaibhav wrote:
> 
> > I am seeing underflow issue on AM43x device if I use omapfb_vram argument.
> > Did you see this on OMAP?
> >
> > I am using "omapfb_vram=10M@0xA0000000", and I believe it is correct way
> of usage.
> 
> Hmm ok... The AM4x seems to have issues anyway, as we're seeing underflows
> easily in other situations also.
> 
> Well, there's a small difference in the allocation. The normal dma alloc uses
> dma_alloc_attrs() and passes DMA_ATTR_WRITE_COMBINE as a flag, whereas
> allocating from the absolute address just uses the piece of memory. I couldn't
> find how to set write-combine for the abs memory area.
> 
> Then again, that's for CPU caching, so I don't see why it would affect DSS as
> such (but that's still something we should measure, cpu read/write perf for
> normal and abs allocation).
> 
> The only thought I have is that somehow the reserved memory area is missing
> some configuration that is done for the rest of the memory. But that's purely a
> guess, this is totally out of my area of expertise...
> 
> Vaibhav, just to be sure, can you run both with normal dma_alloc and with the
> reserve, and verify that the dispc register dumps are the same?
> I don't see how they could be different, but just to be sure.
> 

Will check and update you shortly.

Thanks,
Vaibhav

[PATCH 1/2] ARM: omapfb: add coherent dma memory support

[Hiremath, Vaibhav]

> -----Original Message-----
> From: Valkeinen, Tomi
> Sent: Thursday, January 09, 2014 1:52 PM
> To: Hiremath, Vaibhav; Ivaylo Dimitrov
> Cc: Tony Lindgren; linux-omap at vger.kernel.org; linux-arm-
> kernel at lists.infradead.org; linux-fbdev at vger.kernel.org
> Subject: Re: [PATCH 1/2] ARM: omapfb: add coherent dma memory support
> 
> On 2014-01-09 07:06, Hiremath, Vaibhav wrote:
> 
> > I am seeing underflow issue on AM43x device if I use omapfb_vram argument.
> > Did you see this on OMAP?
> >
> > I am using "omapfb_vram=10M at 0xA0000000", and I believe it is correct way
> of usage.
> 
> Hmm ok... The AM4x seems to have issues anyway, as we're seeing underflows
> easily in other situations also.
> 
> Well, there's a small difference in the allocation. The normal dma alloc uses
> dma_alloc_attrs() and passes DMA_ATTR_WRITE_COMBINE as a flag, whereas
> allocating from the absolute address just uses the piece of memory. I couldn't
> find how to set write-combine for the abs memory area.
> 
> Then again, that's for CPU caching, so I don't see why it would affect DSS as
> such (but that's still something we should measure, cpu read/write perf for
> normal and abs allocation).
> 
> The only thought I have is that somehow the reserved memory area is missing
> some configuration that is done for the rest of the memory. But that's purely a
> guess, this is totally out of my area of expertise...
> 
> Vaibhav, just to be sure, can you run both with normal dma_alloc and with the
> reserve, and verify that the dispc register dumps are the same?
> I don't see how they could be different, but just to be sure.
> 

Will check and update you shortly.

Thanks,
Vaibhav

RE: [PATCH 1/2] ARM: omapfb: add coherent dma memory support

[Hiremath, Vaibhav]

> -----Original Message-----
> From: Valkeinen, Tomi
> Sent: Thursday, January 09, 2014 1:57 PM
> To: Hiremath, Vaibhav; Ivaylo Dimitrov; Ivaylo Dimitrov
> Cc: Tony Lindgren; linux-omap@vger.kernel.org; linux-arm-
> kernel@lists.infradead.org; linux-fbdev@vger.kernel.org
> Subject: Re: [PATCH 1/2] ARM: omapfb: add coherent dma memory support
> 
> On 2014-01-09 10:08, Hiremath, Vaibhav wrote:
> 
> > No, that's what is causing issue to me. Can you try predefined address flow?
> > Just to highlight, I get UNDERFLOW during boot itself, immediately when it
> gets mapped to userspace.
> >
> > Boot LOG:
> >
> 
> > [    4.822549] Freeing unused kernel memory: 440K (c0919000 - c0987000)
> > [    5.276615] OMAPFB: pan_display(0)
> > [    5.276625] OMAPFB: setcmap
> > [    5.276635] OMAPFB: setcmap
> > [    5.293518] OMAPFB: user mmap region start a0000000, len 1536000, off 0
> > [    5.300171] omapdss APPLY error: FIFO UNDERFLOW on gfx, disabling the
> overlay
> 
> Hmm that's interesting... So you have some tool that's ran early, which draws
> something on the screen? Or maybe that's X starting?
> 

It's initial demo, not sure whether you heard of MATRIX demo. I am running Matrix demo
As part of init script.

> Ah... I think I understand now. As I mentioned, AM4x has issues already.
> I think the CPU/others can block DSS when accessing memory. So, if we have
> bad caching for the mapped framebuffer, the CPU will use more bandwidth
> when reading/writing to it, and that will cause DSS to underflow.
> 

Yeah, AM4x already has some issues but I am comparing normal dma_alloc and reserved
Memory and I see different behavior and it could be due to bad caching for the mapped buffers.

Thanks,
Vaibhav

RE: [PATCH 1/2] ARM: omapfb: add coherent dma memory support

[Hiremath, Vaibhav]

> -----Original Message-----
> From: Valkeinen, Tomi
> Sent: Thursday, January 09, 2014 1:57 PM
> To: Hiremath, Vaibhav; Ivaylo Dimitrov; Ivaylo Dimitrov
> Cc: Tony Lindgren; linux-omap@vger.kernel.org; linux-arm-
> kernel@lists.infradead.org; linux-fbdev@vger.kernel.org
> Subject: Re: [PATCH 1/2] ARM: omapfb: add coherent dma memory support
> 
> On 2014-01-09 10:08, Hiremath, Vaibhav wrote:
> 
> > No, that's what is causing issue to me. Can you try predefined address flow?
> > Just to highlight, I get UNDERFLOW during boot itself, immediately when it
> gets mapped to userspace.
> >
> > Boot LOG:
> >
> 
> > [    4.822549] Freeing unused kernel memory: 440K (c0919000 - c0987000)
> > [    5.276615] OMAPFB: pan_display(0)
> > [    5.276625] OMAPFB: setcmap
> > [    5.276635] OMAPFB: setcmap
> > [    5.293518] OMAPFB: user mmap region start a0000000, len 1536000, off 0
> > [    5.300171] omapdss APPLY error: FIFO UNDERFLOW on gfx, disabling the
> overlay
> 
> Hmm that's interesting... So you have some tool that's ran early, which draws
> something on the screen? Or maybe that's X starting?
> 

It's initial demo, not sure whether you heard of MATRIX demo. I am running Matrix demo
As part of init script.

> Ah... I think I understand now. As I mentioned, AM4x has issues already.
> I think the CPU/others can block DSS when accessing memory. So, if we have
> bad caching for the mapped framebuffer, the CPU will use more bandwidth
> when reading/writing to it, and that will cause DSS to underflow.
> 

Yeah, AM4x already has some issues but I am comparing normal dma_alloc and reserved
Memory and I see different behavior and it could be due to bad caching for the mapped buffers.

Thanks,
Vaibhav

[PATCH 1/2] ARM: omapfb: add coherent dma memory support

[Hiremath, Vaibhav]

> -----Original Message-----
> From: Valkeinen, Tomi
> Sent: Thursday, January 09, 2014 1:57 PM
> To: Hiremath, Vaibhav; Ivaylo Dimitrov; Ivaylo Dimitrov
> Cc: Tony Lindgren; linux-omap at vger.kernel.org; linux-arm-
> kernel at lists.infradead.org; linux-fbdev at vger.kernel.org
> Subject: Re: [PATCH 1/2] ARM: omapfb: add coherent dma memory support
> 
> On 2014-01-09 10:08, Hiremath, Vaibhav wrote:
> 
> > No, that's what is causing issue to me. Can you try predefined address flow?
> > Just to highlight, I get UNDERFLOW during boot itself, immediately when it
> gets mapped to userspace.
> >
> > Boot LOG:
> >
> 
> > [    4.822549] Freeing unused kernel memory: 440K (c0919000 - c0987000)
> > [    5.276615] OMAPFB: pan_display(0)
> > [    5.276625] OMAPFB: setcmap
> > [    5.276635] OMAPFB: setcmap
> > [    5.293518] OMAPFB: user mmap region start a0000000, len 1536000, off 0
> > [    5.300171] omapdss APPLY error: FIFO UNDERFLOW on gfx, disabling the
> overlay
> 
> Hmm that's interesting... So you have some tool that's ran early, which draws
> something on the screen? Or maybe that's X starting?
> 

It's initial demo, not sure whether you heard of MATRIX demo. I am running Matrix demo
As part of init script.

> Ah... I think I understand now. As I mentioned, AM4x has issues already.
> I think the CPU/others can block DSS when accessing memory. So, if we have
> bad caching for the mapped framebuffer, the CPU will use more bandwidth
> when reading/writing to it, and that will cause DSS to underflow.
> 

Yeah, AM4x already has some issues but I am comparing normal dma_alloc and reserved
Memory and I see different behavior and it could be due to bad caching for the mapped buffers.

Thanks,
Vaibhav

RE: [PATCH 1/2] ARM: omapfb: add coherent dma memory support

[Hiremath, Vaibhav]

> -----Original Message-----
> From: Hiremath, Vaibhav
> Sent: Thursday, January 09, 2014 2:01 PM
> To: Valkeinen, Tomi; Ivaylo Dimitrov
> Cc: Tony Lindgren; linux-omap@vger.kernel.org; linux-arm-
> kernel@lists.infradead.org; linux-fbdev@vger.kernel.org
> Subject: RE: [PATCH 1/2] ARM: omapfb: add coherent dma memory support
> 
> 
> > -----Original Message-----
> > From: Valkeinen, Tomi
> > Sent: Thursday, January 09, 2014 1:52 PM
> > To: Hiremath, Vaibhav; Ivaylo Dimitrov
> > Cc: Tony Lindgren; linux-omap@vger.kernel.org; linux-arm-
> > kernel@lists.infradead.org; linux-fbdev@vger.kernel.org
> > Subject: Re: [PATCH 1/2] ARM: omapfb: add coherent dma memory support
> >
> > On 2014-01-09 07:06, Hiremath, Vaibhav wrote:
> >
> > > I am seeing underflow issue on AM43x device if I use omapfb_vram
> argument.
> > > Did you see this on OMAP?
> > >
> > > I am using "omapfb_vram\x10M@0xA0000000", and I believe it is correct
> > > way
> > of usage.
> >
> > Hmm ok... The AM4x seems to have issues anyway, as we're seeing
> > underflows easily in other situations also.
> >
> > Well, there's a small difference in the allocation. The normal dma
> > alloc uses
> > dma_alloc_attrs() and passes DMA_ATTR_WRITE_COMBINE as a flag, whereas
> > allocating from the absolute address just uses the piece of memory. I
> > couldn't find how to set write-combine for the abs memory area.
> >
> > Then again, that's for CPU caching, so I don't see why it would affect
> > DSS as such (but that's still something we should measure, cpu
> > read/write perf for normal and abs allocation).
> >
> > The only thought I have is that somehow the reserved memory area is
> > missing some configuration that is done for the rest of the memory.
> > But that's purely a guess, this is totally out of my area of expertise...
> >
> > Vaibhav, just to be sure, can you run both with normal dma_alloc and
> > with the reserve, and verify that the dispc register dumps are the same?
> > I don't see how they could be different, but just to be sure.
> >
> 
> Will check and update you shortly.
> 

I checked both the DSS configuration in both scenarios and they look same to me.


With normal dma_alloc:
=========root@am43xx-epos-evm:~#
root@am43xx-epos-evm:~#
root@am43xx-epos-evm:~# cat /proc/cmdline
console=ttyO0,115200n8 root=/dev/mmcblk0p2 rw rootfstype=ext3 rootwait mem\x128M consoleblank=0 clocksource=gp_timer consoleblank=0 earlyprintk
root@am43xx-epos-evm:~#
root@am43xx-epos-evm:~#
root@am43xx-epos-evm:~#
root@am43xx-epos-evm:~# cat /sys/kernel/debug/omapdss/dss
DSS_REVISION                        00000020
DSS_SYSCONFIG                       00000001
DSS_SYSSTATUS                       00000001
DSS_CONTROL                         00000018
root@am43xx-epos-evm:~#
root@am43xx-epos-evm:~# cat /sys/kernel/debug/omapdss/clk
- DSS -
DSS_FCK (DSS_FCLK1) = 198000000
- DISPC -
dispc fclk source = DSS_FCK (DSS_FCLK1)
fck             198000000
- LCD -
LCD clk source = DSS_FCK (DSS_FCLK1)
lck             198000000       lck div 1
pck             33000000        pck div 6
root@am43xx-epos-evm:~#
root@am43xx-epos-evm:~# cat /sys/kernel/debug/omapdss/dispc_irq
period 44780 ms
irqs 1
FRAMEDONE                     0
VSYNC                         1
EVSYNC_EVEN                   1
EVSYNC_ODD                    1
ACBIAS_COUNT_STAT             0
PROG_LINE_NUM                 1
GFX_FIFO_UNDERFLOW            0
GFX_END_WIN                   1
PAL_GAMMA_MASK                0
OCP_ERR                       0
VID1_FIFO_UNDERFLOW           0
VID1_END_WIN                  0
VID2_FIFO_UNDERFLOW           0
VID2_END_WIN                  0
SYNC_LOST                     0
SYNC_LOST_DIGIT               0
WAKEUP                        0
root@am43xx-epos-evm:~#
root@am43xx-epos-evm:~# cat /sys/kernel/debug/omapdss/dispc
DISPC_REVISION                                     00000030
DISPC_SYSCONFIG                                    00002011
DISPC_SYSSTATUS                                    00000001
DISPC_IRQSTATUS                                    000000ae
DISPC_IRQENABLE                                    0000d640
DISPC_CONTROL                                      00018309
DISPC_CONFIG                                       00000204
DISPC_CAPABLE                                      000003ff
DISPC_LINE_STATUS                                  000000b1
DISPC_LINE_NUMBER                                  00000000
DISPC_GLOBAL_ALPHA                                 000000ff
DISPC_DEFAULT_COLOR(LCD)                           00000000
DISPC_TRANS_COLOR(LCD)                             00000000
DISPC_SIZE_MGR(LCD)                                01df031f
DISPC_DEFAULT_COLOR(LCD)                           00000000
DISPC_TRANS_COLOR(LCD)                             00000000
DISPC_TIMING_H(LCD)                                00f0d11d
DISPC_TIMING_V(LCD)                                00a0160c
DISPC_POL_FREQ(LCD)                                00003000
DISPC_DIVISORo(LCD)                                00010006
DISPC_SIZE_MGR(LCD)                                01df031f
DISPC_DATA_CYCLE1(LCD)                             00000000
DISPC_DATA_CYCLE2(LCD)                             00000000
DISPC_DATA_CYCLE3(LCD)                             00000000
DISPC_CPR_COEF_R(LCD)                              00000000
DISPC_CPR_COEF_G(LCD)                              00000000
DISPC_CPR_COEF_B(LCD)                              00000000
DISPC_OVL_BA0(GFX)                                 86900000
DISPC_OVL_BA1(GFX)                                 86900000
DISPC_OVL_POSITION(GFX)                            00000000
DISPC_OVL_SIZE(GFX)                                01df031f
DISPC_OVL_ATTRIBUTES(GFX)                          00000091
DISPC_OVL_FIFO_THRESHOLD(GFX)                      03ff03c0
DISPC_OVL_FIFO_SIZE_STATUS(GFX)                    00000400
DISPC_OVL_ROW_INC(GFX)                             00000001
DISPC_OVL_PIXEL_INC(GFX)                           00000001
DISPC_OVL_PRELOAD(GFX)                             00000100
DISPC_OVL_WINDOW_SKIP(GFX)                         00000000
DISPC_OVL_TABLE_BA(GFX)                            00000000
DISPC_OVL_BA0(VID1)                                00000000
DISPC_OVL_BA1(VID1)                                00000000
DISPC_OVL_POSITION(VID1)                           00000000
DISPC_OVL_SIZE(VID1)                               00000000
DISPC_OVL_ATTRIBUTES(VID1)                         00008000
DISPC_OVL_FIFO_THRESHOLD(VID1)                     03ff03c0
DISPC_OVL_FIFO_SIZE_STATUS(VID1)                   00000400
DISPC_OVL_ROW_INC(VID1)                            00000001
DISPC_OVL_PIXEL_INC(VID1)                          00000001
DISPC_OVL_PRELOAD(VID1)                            00000100
DISPC_OVL_FIR(VID1)                                00000000
DISPC_OVL_PICTURE_SIZE(VID1)                       00000000
DISPC_OVL_ACCU0(VID1)                              00000000
DISPC_OVL_ACCU1(VID1)                              00000000
DISPC_OVL_PRELOAD(VID1)                            00000100
DISPC_OVL_BA0(VID2)                                00000000
DISPC_OVL_BA1(VID2)                                00000000
DISPC_OVL_POSITION(VID2)                           00000000
DISPC_OVL_SIZE(VID2)                               00000000
DISPC_OVL_ATTRIBUTES(VID2)                         00008000
DISPC_OVL_FIFO_THRESHOLD(VID2)                     03ff03c0
DISPC_OVL_FIFO_SIZE_STATUS(VID2)                   00000400
DISPC_OVL_ROW_INC(VID2)                            00000001
DISPC_OVL_PIXEL_INC(VID2)                          00000001
DISPC_OVL_PRELOAD(VID2)                            00000100
DISPC_OVL_FIR(VID2)                                00000000
DISPC_OVL_PICTURE_SIZE(VID2)                       00000000
DISPC_OVL_ACCU0(VID2)                              00000000
DISPC_OVL_ACCU1(VID2)                              00000000
DISPC_OVL_PRELOAD(VID2)                            00000100
DISPC_OVL_FIR_COEF_H_0(VID1)                       00000000
DISPC_OVL_FIR_COEF_H_1(VID1)                       00000000
DISPC_OVL_FIR_COEF_H_2(VID1)                       00000000
DISPC_OVL_FIR_COEF_H_3(VID1)                       00000000
DISPC_OVL_FIR_COEF_H_4(VID1)                       00000000
DISPC_OVL_FIR_COEF_H_5(VID1)                       00000000
DISPC_OVL_FIR_COEF_H_6(VID1)                       00000000
DISPC_OVL_FIR_COEF_H_7(VID1)                       00000000
DISPC_OVL_FIR_COEF_HV_0(VID1)                      00000000
DISPC_OVL_FIR_COEF_HV_1(VID1)                      00000000
DISPC_OVL_FIR_COEF_HV_2(VID1)                      00000000
DISPC_OVL_FIR_COEF_HV_3(VID1)                      00000000
DISPC_OVL_FIR_COEF_HV_4(VID1)                      00000000
DISPC_OVL_FIR_COEF_HV_5(VID1)                      00000000
DISPC_OVL_FIR_COEF_HV_6(VID1)                      00000000
DISPC_OVL_FIR_COEF_HV_7(VID1)                      00000000
DISPC_OVL_CONV_COEF_0(VID1)                        0199012a
DISPC_OVL_CONV_COEF_1(VID1)                        012a0000
DISPC_OVL_CONV_COEF_2(VID1)                        079c0730
DISPC_OVL_CONV_COEF_3(VID1)                        0000012a
DISPC_OVL_CONV_COEF_4(VID1)                        00000205
DISPC_OVL_FIR_COEF_V_0(VID1)                       00000000
DISPC_OVL_FIR_COEF_V_1(VID1)                       00000000
DISPC_OVL_FIR_COEF_V_2(VID1)                       00000000
DISPC_OVL_FIR_COEF_V_3(VID1)                       00000000
DISPC_OVL_FIR_COEF_V_4(VID1)                       00000000
DISPC_OVL_FIR_COEF_V_5(VID1)                       00000000
DISPC_OVL_FIR_COEF_V_6(VID1)                       00000000
DISPC_OVL_FIR_COEF_V_7(VID1)                       00000000
DISPC_OVL_FIR_COEF_H_0(VID2)                       00000000
DISPC_OVL_FIR_COEF_H_1(VID2)                       00000000
DISPC_OVL_FIR_COEF_H_2(VID2)                       00000000
DISPC_OVL_FIR_COEF_H_3(VID2)                       00000000
DISPC_OVL_FIR_COEF_H_4(VID2)                       00000000
DISPC_OVL_FIR_COEF_H_5(VID2)                       00000000
DISPC_OVL_FIR_COEF_H_6(VID2)                       00000000
DISPC_OVL_FIR_COEF_H_7(VID2)                       00000000
DISPC_OVL_FIR_COEF_HV_0(VID2)                      00000000
DISPC_OVL_FIR_COEF_HV_1(VID2)                      00000000
DISPC_OVL_FIR_COEF_HV_2(VID2)                      00000000
DISPC_OVL_FIR_COEF_HV_3(VID2)                      00000000
DISPC_OVL_FIR_COEF_HV_4(VID2)                      00000000
DISPC_OVL_FIR_COEF_HV_5(VID2)                      00000000
DISPC_OVL_FIR_COEF_HV_6(VID2)                      00000000
DISPC_OVL_FIR_COEF_HV_7(VID2)                      00000000
DISPC_OVL_CONV_COEF_0(VID2)                        0199012a
DISPC_OVL_CONV_COEF_1(VID2)                        012a0000
DISPC_OVL_CONV_COEF_2(VID2)                        079c0730
DISPC_OVL_CONV_COEF_3(VID2)                        0000012a
DISPC_OVL_CONV_COEF_4(VID2)                        00000205
DISPC_OVL_FIR_COEF_V_0(VID2)                       00000000
DISPC_OVL_FIR_COEF_V_1(VID2)                       00000000
DISPC_OVL_FIR_COEF_V_2(VID2)                       00000000
DISPC_OVL_FIR_COEF_V_3(VID2)                       00000000
DISPC_OVL_FIR_COEF_V_4(VID2)                       00000000
DISPC_OVL_FIR_COEF_V_5(VID2)                       00000000
DISPC_OVL_FIR_COEF_V_6(VID2)                       00000000
DISPC_OVL_FIR_COEF_V_7(VID2)                       00000000
root@am43xx-epos-evm:~#




With Reserved memory for FB:
==============
root@am43xx-epos-evm:~# cat /proc/cmdline
console=ttyO0,115200n8 root=/dev/mmcblk0p2 rw rootfstype=ext3 rootwait mem\x128M consoleblank=0 clocksource=gp_timer consoleblank=0 earlyprintk omapfb_vram\x10M@0xA0000000
root@am43xx-epos-evm:~#
root@am43xx-epos-evm:~#
root@am43xx-epos-evm:~#
root@am43xx-epos-evm:~# cat /sys/kernel/debug/omapdss/dss
DSS_REVISION                        00000020
DSS_SYSCONFIG                       00000001
DSS_SYSSTATUS                       00000001
DSS_CONTROL                         00000018
root@am43xx-epos-evm:~#
root@am43xx-epos-evm:~# cat /sys/kernel/debug/omapdss/clk
- DSS -
DSS_FCK (DSS_FCLK1) = 198000000
- DISPC -
dispc fclk source = DSS_FCK (DSS_FCLK1)
fck             198000000
- LCD -
LCD clk source = DSS_FCK (DSS_FCLK1)
lck             198000000       lck div 1
pck             33000000        pck div 6
root@am43xx-epos-evm:~#
root@am43xx-epos-evm:~# cat /sys/kernel/debug/omapdss/dispc_irq
period 48010 ms
irqs 2
FRAMEDONE                     0
VSYNC                         2
EVSYNC_EVEN                   2
EVSYNC_ODD                    2
ACBIAS_COUNT_STAT             0
PROG_LINE_NUM                 2
GFX_FIFO_UNDERFLOW            2
GFX_END_WIN                   2
PAL_GAMMA_MASK                0
OCP_ERR                       0
VID1_FIFO_UNDERFLOW           0
VID1_END_WIN                  0
VID2_FIFO_UNDERFLOW           0
VID2_END_WIN                  0
SYNC_LOST                     0

SYNC_LOST_DIGIT               0
WAKEUP                        0
root@am43xx-epos-evm:~#
root@am43xx-epos-evm:~#
root@am43xx-epos-evm:~#
root@am43xx-epos-evm:~# cat /sys/kernel/debug/omapdss/dispc
DISPC_REVISION                                     00000030
DISPC_SYSCONFIG                                    00002011
DISPC_SYSSTATUS                                    00000001
DISPC_IRQSTATUS                                    0000002e
DISPC_IRQENABLE                                    0000d640
DISPC_CONTROL                                      00018309
DISPC_CONFIG                                       00000204
DISPC_CAPABLE                                      000003ff
DISPC_LINE_STATUS                                  0000011d
DISPC_LINE_NUMBER                                  00000000
DISPC_GLOBAL_ALPHA                                 000000ff
DISPC_DEFAULT_COLOR(LCD)                           00000000
DISPC_TRANS_COLOR(LCD)                             00000000
DISPC_SIZE_MGR(LCD)                                01df031f
DISPC_DEFAULT_COLOR(LCD)                           00000000
DISPC_TRANS_COLOR(LCD)                             00000000
DISPC_TIMING_H(LCD)                                00f0d11d
DISPC_TIMING_V(LCD)                                00a0160c
DISPC_POL_FREQ(LCD)                                00003000
DISPC_DIVISORo(LCD)                                00010006
DISPC_SIZE_MGR(LCD)                                01df031f
DISPC_DATA_CYCLE1(LCD)                             00000000
DISPC_DATA_CYCLE2(LCD)                             00000000
DISPC_DATA_CYCLE3(LCD)                             00000000
DISPC_CPR_COEF_R(LCD)                              00000000
DISPC_CPR_COEF_G(LCD)                              00000000
DISPC_CPR_COEF_B(LCD)                              00000000
DISPC_OVL_BA0(GFX)                                 a0000000
DISPC_OVL_BA1(GFX)                                 a0000000
DISPC_OVL_POSITION(GFX)                            00000000
DISPC_OVL_SIZE(GFX)                                01df031f
DISPC_OVL_ATTRIBUTES(GFX)                          00000090
DISPC_OVL_FIFO_THRESHOLD(GFX)                      03ff03c0
DISPC_OVL_FIFO_SIZE_STATUS(GFX)                    00000400
DISPC_OVL_ROW_INC(GFX)                             00000001
DISPC_OVL_PIXEL_INC(GFX)                           00000001
DISPC_OVL_PRELOAD(GFX)                             00000100
DISPC_OVL_WINDOW_SKIP(GFX)                         00000000
DISPC_OVL_TABLE_BA(GFX)                            00000000
DISPC_OVL_BA0(VID1)                                00000000
DISPC_OVL_BA1(VID1)                                00000000
DISPC_OVL_POSITION(VID1)                           00000000
DISPC_OVL_SIZE(VID1)                               00000000
DISPC_OVL_ATTRIBUTES(VID1)                         00008000
DISPC_OVL_FIFO_THRESHOLD(VID1)                     03ff03c0
DISPC_OVL_FIFO_SIZE_STATUS(VID1)                   00000400
DISPC_OVL_ROW_INC(VID1)                            00000001
DISPC_OVL_PIXEL_INC(VID1)                          00000001
DISPC_OVL_PRELOAD(VID1)                            00000100
DISPC_OVL_FIR(VID1)                                00000000
DISPC_OVL_PICTURE_SIZE(VID1)                       00000000
DISPC_OVL_ACCU0(VID1)                              00000000
DISPC_OVL_ACCU1(VID1)                              00000000
DISPC_OVL_PRELOAD(VID1)                            00000100
DISPC_OVL_BA0(VID2)                                00000000
DISPC_OVL_BA1(VID2)                                00000000
DISPC_OVL_POSITION(VID2)                           00000000
DISPC_OVL_SIZE(VID2)                               00000000
DISPC_OVL_ATTRIBUTES(VID2)                         00008000
DISPC_OVL_FIFO_THRESHOLD(VID2)                     03ff03c0
DISPC_OVL_FIFO_SIZE_STATUS(VID2)                   00000400
DISPC_OVL_ROW_INC(VID2)                            00000001
DISPC_OVL_PIXEL_INC(VID2)                          00000001
DISPC_OVL_PRELOAD(VID2)                            00000100
DISPC_OVL_FIR(VID2)                                00000000
DISPC_OVL_PICTURE_SIZE(VID2)                       00000000
DISPC_OVL_ACCU0(VID2)                              00000000
DISPC_OVL_ACCU1(VID2)                              00000000
DISPC_OVL_PRELOAD(VID2)                            00000100
DISPC_OVL_FIR_COEF_H_0(VID1)                       00000000
DISPC_OVL_FIR_COEF_H_1(VID1)                       00000000
DISPC_OVL_FIR_COEF_H_2(VID1)                       00000000
DISPC_OVL_FIR_COEF_H_3(VID1)                       00000000
DISPC_OVL_FIR_COEF_H_4(VID1)                       00000000
DISPC_OVL_FIR_COEF_H_5(VID1)                       00000000
DISPC_OVL_FIR_COEF_H_6(VID1)                       00000000
DISPC_OVL_FIR_COEF_H_7(VID1)                       00000000
DISPC_OVL_FIR_COEF_HV_0(VID1)                      00000000
DISPC_OVL_FIR_COEF_HV_1(VID1)                      00000000
DISPC_OVL_FIR_COEF_HV_2(VID1)                      00000000
DISPC_OVL_FIR_COEF_HV_3(VID1)                      00000000
DISPC_OVL_FIR_COEF_HV_4(VID1)                      00000000
DISPC_OVL_FIR_COEF_HV_5(VID1)                      00000000
DISPC_OVL_FIR_COEF_HV_6(VID1)                      00000000
DISPC_OVL_FIR_COEF_HV_7(VID1)                      00000000
DISPC_OVL_CONV_COEF_0(VID1)                        0199012a
DISPC_OVL_CONV_COEF_1(VID1)                        012a0000
DISPC_OVL_CONV_COEF_2(VID1)                        079c0730
DISPC_OVL_CONV_COEF_3(VID1)                        0000012a
DISPC_OVL_CONV_COEF_4(VID1)                        00000205
DISPC_OVL_FIR_COEF_V_0(VID1)                       00000000
DISPC_OVL_FIR_COEF_V_1(VID1)                       00000000
DISPC_OVL_FIR_COEF_V_2(VID1)                       00000000
DISPC_OVL_FIR_COEF_V_3(VID1)                       00000000
DISPC_OVL_FIR_COEF_V_4(VID1)                       00000000
DISPC_OVL_FIR_COEF_V_5(VID1)                       00000000
DISPC_OVL_FIR_COEF_V_6(VID1)                       00000000
DISPC_OVL_FIR_COEF_V_7(VID1)                       00000000
DISPC_OVL_FIR_COEF_H_0(VID2)                       00000000
DISPC_OVL_FIR_COEF_H_1(VID2)                       00000000
DISPC_OVL_FIR_COEF_H_2(VID2)                       00000000
DISPC_OVL_FIR_COEF_H_3(VID2)                       00000000
DISPC_OVL_FIR_COEF_H_4(VID2)                       00000000
DISPC_OVL_FIR_COEF_H_5(VID2)                       00000000
DISPC_OVL_FIR_COEF_H_6(VID2)                       00000000
DISPC_OVL_FIR_COEF_H_7(VID2)                       00000000
DISPC_OVL_FIR_COEF_HV_0(VID2)                      00000000
DISPC_OVL_FIR_COEF_HV_1(VID2)                      00000000
DISPC_OVL_FIR_COEF_HV_2(VID2)                      00000000
DISPC_OVL_FIR_COEF_HV_3(VID2)                      00000000
DISPC_OVL_FIR_COEF_HV_4(VID2)                      00000000
DISPC_OVL_FIR_COEF_HV_5(VID2)                      00000000
DISPC_OVL_FIR_COEF_HV_6(VID2)                      00000000
DISPC_OVL_FIR_COEF_HV_7(VID2)                      00000000
DISPC_OVL_CONV_COEF_0(VID2)                        0199012a
DISPC_OVL_CONV_COEF_1(VID2)                        012a0000
DISPC_OVL_CONV_COEF_2(VID2)                        079c0730
DISPC_OVL_CONV_COEF_3(VID2)                        0000012a
DISPC_OVL_CONV_COEF_4(VID2)                        00000205
DISPC_OVL_FIR_COEF_V_0(VID2)                       00000000
DISPC_OVL_FIR_COEF_V_1(VID2)                       00000000
DISPC_OVL_FIR_COEF_V_2(VID2)                       00000000
DISPC_OVL_FIR_COEF_V_3(VID2)                       00000000
DISPC_OVL_FIR_COEF_V_4(VID2)                       00000000
DISPC_OVL_FIR_COEF_V_5(VID2)                       00000000
DISPC_OVL_FIR_COEF_V_6(VID2)                       00000000
DISPC_OVL_FIR_COEF_V_7(VID2)                       00000000
root@am43xx-epos-evm:~#

RE: [PATCH 1/2] ARM: omapfb: add coherent dma memory support

[Hiremath, Vaibhav]

> -----Original Message-----
> From: Hiremath, Vaibhav
> Sent: Thursday, January 09, 2014 2:01 PM
> To: Valkeinen, Tomi; Ivaylo Dimitrov
> Cc: Tony Lindgren; linux-omap@vger.kernel.org; linux-arm-
> kernel@lists.infradead.org; linux-fbdev@vger.kernel.org
> Subject: RE: [PATCH 1/2] ARM: omapfb: add coherent dma memory support
> 
> 
> > -----Original Message-----
> > From: Valkeinen, Tomi
> > Sent: Thursday, January 09, 2014 1:52 PM
> > To: Hiremath, Vaibhav; Ivaylo Dimitrov
> > Cc: Tony Lindgren; linux-omap@vger.kernel.org; linux-arm-
> > kernel@lists.infradead.org; linux-fbdev@vger.kernel.org
> > Subject: Re: [PATCH 1/2] ARM: omapfb: add coherent dma memory support
> >
> > On 2014-01-09 07:06, Hiremath, Vaibhav wrote:
> >
> > > I am seeing underflow issue on AM43x device if I use omapfb_vram
> argument.
> > > Did you see this on OMAP?
> > >
> > > I am using "omapfb_vram=10M@0xA0000000", and I believe it is correct
> > > way
> > of usage.
> >
> > Hmm ok... The AM4x seems to have issues anyway, as we're seeing
> > underflows easily in other situations also.
> >
> > Well, there's a small difference in the allocation. The normal dma
> > alloc uses
> > dma_alloc_attrs() and passes DMA_ATTR_WRITE_COMBINE as a flag, whereas
> > allocating from the absolute address just uses the piece of memory. I
> > couldn't find how to set write-combine for the abs memory area.
> >
> > Then again, that's for CPU caching, so I don't see why it would affect
> > DSS as such (but that's still something we should measure, cpu
> > read/write perf for normal and abs allocation).
> >
> > The only thought I have is that somehow the reserved memory area is
> > missing some configuration that is done for the rest of the memory.
> > But that's purely a guess, this is totally out of my area of expertise...
> >
> > Vaibhav, just to be sure, can you run both with normal dma_alloc and
> > with the reserve, and verify that the dispc register dumps are the same?
> > I don't see how they could be different, but just to be sure.
> >
> 
> Will check and update you shortly.
> 

I checked both the DSS configuration in both scenarios and they look same to me.


With normal dma_alloc:
===================
root@am43xx-epos-evm:~#
root@am43xx-epos-evm:~#
root@am43xx-epos-evm:~# cat /proc/cmdline
console=ttyO0,115200n8 root=/dev/mmcblk0p2 rw rootfstype=ext3 rootwait mem=128M consoleblank=0 clocksource=gp_timer consoleblank=0 earlyprintk
root@am43xx-epos-evm:~#
root@am43xx-epos-evm:~#
root@am43xx-epos-evm:~#
root@am43xx-epos-evm:~# cat /sys/kernel/debug/omapdss/dss
DSS_REVISION                        00000020
DSS_SYSCONFIG                       00000001
DSS_SYSSTATUS                       00000001
DSS_CONTROL                         00000018
root@am43xx-epos-evm:~#
root@am43xx-epos-evm:~# cat /sys/kernel/debug/omapdss/clk
- DSS -
DSS_FCK (DSS_FCLK1) = 198000000
- DISPC -
dispc fclk source = DSS_FCK (DSS_FCLK1)
fck             198000000
- LCD -
LCD clk source = DSS_FCK (DSS_FCLK1)
lck             198000000       lck div 1
pck             33000000        pck div 6
root@am43xx-epos-evm:~#
root@am43xx-epos-evm:~# cat /sys/kernel/debug/omapdss/dispc_irq
period 44780 ms
irqs 1
FRAMEDONE                     0
VSYNC                         1
EVSYNC_EVEN                   1
EVSYNC_ODD                    1
ACBIAS_COUNT_STAT             0
PROG_LINE_NUM                 1
GFX_FIFO_UNDERFLOW            0
GFX_END_WIN                   1
PAL_GAMMA_MASK                0
OCP_ERR                       0
VID1_FIFO_UNDERFLOW           0
VID1_END_WIN                  0
VID2_FIFO_UNDERFLOW           0
VID2_END_WIN                  0
SYNC_LOST                     0
SYNC_LOST_DIGIT               0
WAKEUP                        0
root@am43xx-epos-evm:~#
root@am43xx-epos-evm:~# cat /sys/kernel/debug/omapdss/dispc
DISPC_REVISION                                     00000030
DISPC_SYSCONFIG                                    00002011
DISPC_SYSSTATUS                                    00000001
DISPC_IRQSTATUS                                    000000ae
DISPC_IRQENABLE                                    0000d640
DISPC_CONTROL                                      00018309
DISPC_CONFIG                                       00000204
DISPC_CAPABLE                                      000003ff
DISPC_LINE_STATUS                                  000000b1
DISPC_LINE_NUMBER                                  00000000
DISPC_GLOBAL_ALPHA                                 000000ff
DISPC_DEFAULT_COLOR(LCD)                           00000000
DISPC_TRANS_COLOR(LCD)                             00000000
DISPC_SIZE_MGR(LCD)                                01df031f
DISPC_DEFAULT_COLOR(LCD)                           00000000
DISPC_TRANS_COLOR(LCD)                             00000000
DISPC_TIMING_H(LCD)                                00f0d11d
DISPC_TIMING_V(LCD)                                00a0160c
DISPC_POL_FREQ(LCD)                                00003000
DISPC_DIVISORo(LCD)                                00010006
DISPC_SIZE_MGR(LCD)                                01df031f
DISPC_DATA_CYCLE1(LCD)                             00000000
DISPC_DATA_CYCLE2(LCD)                             00000000
DISPC_DATA_CYCLE3(LCD)                             00000000
DISPC_CPR_COEF_R(LCD)                              00000000
DISPC_CPR_COEF_G(LCD)                              00000000
DISPC_CPR_COEF_B(LCD)                              00000000
DISPC_OVL_BA0(GFX)                                 86900000
DISPC_OVL_BA1(GFX)                                 86900000
DISPC_OVL_POSITION(GFX)                            00000000
DISPC_OVL_SIZE(GFX)                                01df031f
DISPC_OVL_ATTRIBUTES(GFX)                          00000091
DISPC_OVL_FIFO_THRESHOLD(GFX)                      03ff03c0
DISPC_OVL_FIFO_SIZE_STATUS(GFX)                    00000400
DISPC_OVL_ROW_INC(GFX)                             00000001
DISPC_OVL_PIXEL_INC(GFX)                           00000001
DISPC_OVL_PRELOAD(GFX)                             00000100
DISPC_OVL_WINDOW_SKIP(GFX)                         00000000
DISPC_OVL_TABLE_BA(GFX)                            00000000
DISPC_OVL_BA0(VID1)                                00000000
DISPC_OVL_BA1(VID1)                                00000000
DISPC_OVL_POSITION(VID1)                           00000000
DISPC_OVL_SIZE(VID1)                               00000000
DISPC_OVL_ATTRIBUTES(VID1)                         00008000
DISPC_OVL_FIFO_THRESHOLD(VID1)                     03ff03c0
DISPC_OVL_FIFO_SIZE_STATUS(VID1)                   00000400
DISPC_OVL_ROW_INC(VID1)                            00000001
DISPC_OVL_PIXEL_INC(VID1)                          00000001
DISPC_OVL_PRELOAD(VID1)                            00000100
DISPC_OVL_FIR(VID1)                                00000000
DISPC_OVL_PICTURE_SIZE(VID1)                       00000000
DISPC_OVL_ACCU0(VID1)                              00000000
DISPC_OVL_ACCU1(VID1)                              00000000
DISPC_OVL_PRELOAD(VID1)                            00000100
DISPC_OVL_BA0(VID2)                                00000000
DISPC_OVL_BA1(VID2)                                00000000
DISPC_OVL_POSITION(VID2)                           00000000
DISPC_OVL_SIZE(VID2)                               00000000
DISPC_OVL_ATTRIBUTES(VID2)                         00008000
DISPC_OVL_FIFO_THRESHOLD(VID2)                     03ff03c0
DISPC_OVL_FIFO_SIZE_STATUS(VID2)                   00000400
DISPC_OVL_ROW_INC(VID2)                            00000001
DISPC_OVL_PIXEL_INC(VID2)                          00000001
DISPC_OVL_PRELOAD(VID2)                            00000100
DISPC_OVL_FIR(VID2)                                00000000
DISPC_OVL_PICTURE_SIZE(VID2)                       00000000
DISPC_OVL_ACCU0(VID2)                              00000000
DISPC_OVL_ACCU1(VID2)                              00000000
DISPC_OVL_PRELOAD(VID2)                            00000100
DISPC_OVL_FIR_COEF_H_0(VID1)                       00000000
DISPC_OVL_FIR_COEF_H_1(VID1)                       00000000
DISPC_OVL_FIR_COEF_H_2(VID1)                       00000000
DISPC_OVL_FIR_COEF_H_3(VID1)                       00000000
DISPC_OVL_FIR_COEF_H_4(VID1)                       00000000
DISPC_OVL_FIR_COEF_H_5(VID1)                       00000000
DISPC_OVL_FIR_COEF_H_6(VID1)                       00000000
DISPC_OVL_FIR_COEF_H_7(VID1)                       00000000
DISPC_OVL_FIR_COEF_HV_0(VID1)                      00000000
DISPC_OVL_FIR_COEF_HV_1(VID1)                      00000000
DISPC_OVL_FIR_COEF_HV_2(VID1)                      00000000
DISPC_OVL_FIR_COEF_HV_3(VID1)                      00000000
DISPC_OVL_FIR_COEF_HV_4(VID1)                      00000000
DISPC_OVL_FIR_COEF_HV_5(VID1)                      00000000
DISPC_OVL_FIR_COEF_HV_6(VID1)                      00000000
DISPC_OVL_FIR_COEF_HV_7(VID1)                      00000000
DISPC_OVL_CONV_COEF_0(VID1)                        0199012a
DISPC_OVL_CONV_COEF_1(VID1)                        012a0000
DISPC_OVL_CONV_COEF_2(VID1)                        079c0730
DISPC_OVL_CONV_COEF_3(VID1)                        0000012a
DISPC_OVL_CONV_COEF_4(VID1)                        00000205
DISPC_OVL_FIR_COEF_V_0(VID1)                       00000000
DISPC_OVL_FIR_COEF_V_1(VID1)                       00000000
DISPC_OVL_FIR_COEF_V_2(VID1)                       00000000
DISPC_OVL_FIR_COEF_V_3(VID1)                       00000000
DISPC_OVL_FIR_COEF_V_4(VID1)                       00000000
DISPC_OVL_FIR_COEF_V_5(VID1)                       00000000
DISPC_OVL_FIR_COEF_V_6(VID1)                       00000000
DISPC_OVL_FIR_COEF_V_7(VID1)                       00000000
DISPC_OVL_FIR_COEF_H_0(VID2)                       00000000
DISPC_OVL_FIR_COEF_H_1(VID2)                       00000000
DISPC_OVL_FIR_COEF_H_2(VID2)                       00000000
DISPC_OVL_FIR_COEF_H_3(VID2)                       00000000
DISPC_OVL_FIR_COEF_H_4(VID2)                       00000000
DISPC_OVL_FIR_COEF_H_5(VID2)                       00000000
DISPC_OVL_FIR_COEF_H_6(VID2)                       00000000
DISPC_OVL_FIR_COEF_H_7(VID2)                       00000000
DISPC_OVL_FIR_COEF_HV_0(VID2)                      00000000
DISPC_OVL_FIR_COEF_HV_1(VID2)                      00000000
DISPC_OVL_FIR_COEF_HV_2(VID2)                      00000000
DISPC_OVL_FIR_COEF_HV_3(VID2)                      00000000
DISPC_OVL_FIR_COEF_HV_4(VID2)                      00000000
DISPC_OVL_FIR_COEF_HV_5(VID2)                      00000000
DISPC_OVL_FIR_COEF_HV_6(VID2)                      00000000
DISPC_OVL_FIR_COEF_HV_7(VID2)                      00000000
DISPC_OVL_CONV_COEF_0(VID2)                        0199012a
DISPC_OVL_CONV_COEF_1(VID2)                        012a0000
DISPC_OVL_CONV_COEF_2(VID2)                        079c0730
DISPC_OVL_CONV_COEF_3(VID2)                        0000012a
DISPC_OVL_CONV_COEF_4(VID2)                        00000205
DISPC_OVL_FIR_COEF_V_0(VID2)                       00000000
DISPC_OVL_FIR_COEF_V_1(VID2)                       00000000
DISPC_OVL_FIR_COEF_V_2(VID2)                       00000000
DISPC_OVL_FIR_COEF_V_3(VID2)                       00000000
DISPC_OVL_FIR_COEF_V_4(VID2)                       00000000
DISPC_OVL_FIR_COEF_V_5(VID2)                       00000000
DISPC_OVL_FIR_COEF_V_6(VID2)                       00000000
DISPC_OVL_FIR_COEF_V_7(VID2)                       00000000
root@am43xx-epos-evm:~#




With Reserved memory for FB:
============================
root@am43xx-epos-evm:~# cat /proc/cmdline
console=ttyO0,115200n8 root=/dev/mmcblk0p2 rw rootfstype=ext3 rootwait mem=128M consoleblank=0 clocksource=gp_timer consoleblank=0 earlyprintk omapfb_vram=10M@0xA0000000
root@am43xx-epos-evm:~#
root@am43xx-epos-evm:~#
root@am43xx-epos-evm:~#
root@am43xx-epos-evm:~# cat /sys/kernel/debug/omapdss/dss
DSS_REVISION                        00000020
DSS_SYSCONFIG                       00000001
DSS_SYSSTATUS                       00000001
DSS_CONTROL                         00000018
root@am43xx-epos-evm:~#
root@am43xx-epos-evm:~# cat /sys/kernel/debug/omapdss/clk
- DSS -
DSS_FCK (DSS_FCLK1) = 198000000
- DISPC -
dispc fclk source = DSS_FCK (DSS_FCLK1)
fck             198000000
- LCD -
LCD clk source = DSS_FCK (DSS_FCLK1)
lck             198000000       lck div 1
pck             33000000        pck div 6
root@am43xx-epos-evm:~#
root@am43xx-epos-evm:~# cat /sys/kernel/debug/omapdss/dispc_irq
period 48010 ms
irqs 2
FRAMEDONE                     0
VSYNC                         2
EVSYNC_EVEN                   2
EVSYNC_ODD                    2
ACBIAS_COUNT_STAT             0
PROG_LINE_NUM                 2
GFX_FIFO_UNDERFLOW            2
GFX_END_WIN                   2
PAL_GAMMA_MASK                0
OCP_ERR                       0
VID1_FIFO_UNDERFLOW           0
VID1_END_WIN                  0
VID2_FIFO_UNDERFLOW           0
VID2_END_WIN                  0
SYNC_LOST                     0

SYNC_LOST_DIGIT               0
WAKEUP                        0
root@am43xx-epos-evm:~#
root@am43xx-epos-evm:~#
root@am43xx-epos-evm:~#
root@am43xx-epos-evm:~# cat /sys/kernel/debug/omapdss/dispc
DISPC_REVISION                                     00000030
DISPC_SYSCONFIG                                    00002011
DISPC_SYSSTATUS                                    00000001
DISPC_IRQSTATUS                                    0000002e
DISPC_IRQENABLE                                    0000d640
DISPC_CONTROL                                      00018309
DISPC_CONFIG                                       00000204
DISPC_CAPABLE                                      000003ff
DISPC_LINE_STATUS                                  0000011d
DISPC_LINE_NUMBER                                  00000000
DISPC_GLOBAL_ALPHA                                 000000ff
DISPC_DEFAULT_COLOR(LCD)                           00000000
DISPC_TRANS_COLOR(LCD)                             00000000
DISPC_SIZE_MGR(LCD)                                01df031f
DISPC_DEFAULT_COLOR(LCD)                           00000000
DISPC_TRANS_COLOR(LCD)                             00000000
DISPC_TIMING_H(LCD)                                00f0d11d
DISPC_TIMING_V(LCD)                                00a0160c
DISPC_POL_FREQ(LCD)                                00003000
DISPC_DIVISORo(LCD)                                00010006
DISPC_SIZE_MGR(LCD)                                01df031f
DISPC_DATA_CYCLE1(LCD)                             00000000
DISPC_DATA_CYCLE2(LCD)                             00000000
DISPC_DATA_CYCLE3(LCD)                             00000000
DISPC_CPR_COEF_R(LCD)                              00000000
DISPC_CPR_COEF_G(LCD)                              00000000
DISPC_CPR_COEF_B(LCD)                              00000000
DISPC_OVL_BA0(GFX)                                 a0000000
DISPC_OVL_BA1(GFX)                                 a0000000
DISPC_OVL_POSITION(GFX)                            00000000
DISPC_OVL_SIZE(GFX)                                01df031f
DISPC_OVL_ATTRIBUTES(GFX)                          00000090
DISPC_OVL_FIFO_THRESHOLD(GFX)                      03ff03c0
DISPC_OVL_FIFO_SIZE_STATUS(GFX)                    00000400
DISPC_OVL_ROW_INC(GFX)                             00000001
DISPC_OVL_PIXEL_INC(GFX)                           00000001
DISPC_OVL_PRELOAD(GFX)                             00000100
DISPC_OVL_WINDOW_SKIP(GFX)                         00000000
DISPC_OVL_TABLE_BA(GFX)                            00000000
DISPC_OVL_BA0(VID1)                                00000000
DISPC_OVL_BA1(VID1)                                00000000
DISPC_OVL_POSITION(VID1)                           00000000
DISPC_OVL_SIZE(VID1)                               00000000
DISPC_OVL_ATTRIBUTES(VID1)                         00008000
DISPC_OVL_FIFO_THRESHOLD(VID1)                     03ff03c0
DISPC_OVL_FIFO_SIZE_STATUS(VID1)                   00000400
DISPC_OVL_ROW_INC(VID1)                            00000001
DISPC_OVL_PIXEL_INC(VID1)                          00000001
DISPC_OVL_PRELOAD(VID1)                            00000100
DISPC_OVL_FIR(VID1)                                00000000
DISPC_OVL_PICTURE_SIZE(VID1)                       00000000
DISPC_OVL_ACCU0(VID1)                              00000000
DISPC_OVL_ACCU1(VID1)                              00000000
DISPC_OVL_PRELOAD(VID1)                            00000100
DISPC_OVL_BA0(VID2)                                00000000
DISPC_OVL_BA1(VID2)                                00000000
DISPC_OVL_POSITION(VID2)                           00000000
DISPC_OVL_SIZE(VID2)                               00000000
DISPC_OVL_ATTRIBUTES(VID2)                         00008000
DISPC_OVL_FIFO_THRESHOLD(VID2)                     03ff03c0
DISPC_OVL_FIFO_SIZE_STATUS(VID2)                   00000400
DISPC_OVL_ROW_INC(VID2)                            00000001
DISPC_OVL_PIXEL_INC(VID2)                          00000001
DISPC_OVL_PRELOAD(VID2)                            00000100
DISPC_OVL_FIR(VID2)                                00000000
DISPC_OVL_PICTURE_SIZE(VID2)                       00000000
DISPC_OVL_ACCU0(VID2)                              00000000
DISPC_OVL_ACCU1(VID2)                              00000000
DISPC_OVL_PRELOAD(VID2)                            00000100
DISPC_OVL_FIR_COEF_H_0(VID1)                       00000000
DISPC_OVL_FIR_COEF_H_1(VID1)                       00000000
DISPC_OVL_FIR_COEF_H_2(VID1)                       00000000
DISPC_OVL_FIR_COEF_H_3(VID1)                       00000000
DISPC_OVL_FIR_COEF_H_4(VID1)                       00000000
DISPC_OVL_FIR_COEF_H_5(VID1)                       00000000
DISPC_OVL_FIR_COEF_H_6(VID1)                       00000000
DISPC_OVL_FIR_COEF_H_7(VID1)                       00000000
DISPC_OVL_FIR_COEF_HV_0(VID1)                      00000000
DISPC_OVL_FIR_COEF_HV_1(VID1)                      00000000
DISPC_OVL_FIR_COEF_HV_2(VID1)                      00000000
DISPC_OVL_FIR_COEF_HV_3(VID1)                      00000000
DISPC_OVL_FIR_COEF_HV_4(VID1)                      00000000
DISPC_OVL_FIR_COEF_HV_5(VID1)                      00000000
DISPC_OVL_FIR_COEF_HV_6(VID1)                      00000000
DISPC_OVL_FIR_COEF_HV_7(VID1)                      00000000
DISPC_OVL_CONV_COEF_0(VID1)                        0199012a
DISPC_OVL_CONV_COEF_1(VID1)                        012a0000
DISPC_OVL_CONV_COEF_2(VID1)                        079c0730
DISPC_OVL_CONV_COEF_3(VID1)                        0000012a
DISPC_OVL_CONV_COEF_4(VID1)                        00000205
DISPC_OVL_FIR_COEF_V_0(VID1)                       00000000
DISPC_OVL_FIR_COEF_V_1(VID1)                       00000000
DISPC_OVL_FIR_COEF_V_2(VID1)                       00000000
DISPC_OVL_FIR_COEF_V_3(VID1)                       00000000
DISPC_OVL_FIR_COEF_V_4(VID1)                       00000000
DISPC_OVL_FIR_COEF_V_5(VID1)                       00000000
DISPC_OVL_FIR_COEF_V_6(VID1)                       00000000
DISPC_OVL_FIR_COEF_V_7(VID1)                       00000000
DISPC_OVL_FIR_COEF_H_0(VID2)                       00000000
DISPC_OVL_FIR_COEF_H_1(VID2)                       00000000
DISPC_OVL_FIR_COEF_H_2(VID2)                       00000000
DISPC_OVL_FIR_COEF_H_3(VID2)                       00000000
DISPC_OVL_FIR_COEF_H_4(VID2)                       00000000
DISPC_OVL_FIR_COEF_H_5(VID2)                       00000000
DISPC_OVL_FIR_COEF_H_6(VID2)                       00000000
DISPC_OVL_FIR_COEF_H_7(VID2)                       00000000
DISPC_OVL_FIR_COEF_HV_0(VID2)                      00000000
DISPC_OVL_FIR_COEF_HV_1(VID2)                      00000000
DISPC_OVL_FIR_COEF_HV_2(VID2)                      00000000
DISPC_OVL_FIR_COEF_HV_3(VID2)                      00000000
DISPC_OVL_FIR_COEF_HV_4(VID2)                      00000000
DISPC_OVL_FIR_COEF_HV_5(VID2)                      00000000
DISPC_OVL_FIR_COEF_HV_6(VID2)                      00000000
DISPC_OVL_FIR_COEF_HV_7(VID2)                      00000000
DISPC_OVL_CONV_COEF_0(VID2)                        0199012a
DISPC_OVL_CONV_COEF_1(VID2)                        012a0000
DISPC_OVL_CONV_COEF_2(VID2)                        079c0730
DISPC_OVL_CONV_COEF_3(VID2)                        0000012a
DISPC_OVL_CONV_COEF_4(VID2)                        00000205
DISPC_OVL_FIR_COEF_V_0(VID2)                       00000000
DISPC_OVL_FIR_COEF_V_1(VID2)                       00000000
DISPC_OVL_FIR_COEF_V_2(VID2)                       00000000
DISPC_OVL_FIR_COEF_V_3(VID2)                       00000000
DISPC_OVL_FIR_COEF_V_4(VID2)                       00000000
DISPC_OVL_FIR_COEF_V_5(VID2)                       00000000
DISPC_OVL_FIR_COEF_V_6(VID2)                       00000000
DISPC_OVL_FIR_COEF_V_7(VID2)                       00000000
root@am43xx-epos-evm:~#

[PATCH 1/2] ARM: omapfb: add coherent dma memory support

[Hiremath, Vaibhav]

> -----Original Message-----
> From: Hiremath, Vaibhav
> Sent: Thursday, January 09, 2014 2:01 PM
> To: Valkeinen, Tomi; Ivaylo Dimitrov
> Cc: Tony Lindgren; linux-omap at vger.kernel.org; linux-arm-
> kernel at lists.infradead.org; linux-fbdev at vger.kernel.org
> Subject: RE: [PATCH 1/2] ARM: omapfb: add coherent dma memory support
> 
> 
> > -----Original Message-----
> > From: Valkeinen, Tomi
> > Sent: Thursday, January 09, 2014 1:52 PM
> > To: Hiremath, Vaibhav; Ivaylo Dimitrov
> > Cc: Tony Lindgren; linux-omap at vger.kernel.org; linux-arm-
> > kernel at lists.infradead.org; linux-fbdev at vger.kernel.org
> > Subject: Re: [PATCH 1/2] ARM: omapfb: add coherent dma memory support
> >
> > On 2014-01-09 07:06, Hiremath, Vaibhav wrote:
> >
> > > I am seeing underflow issue on AM43x device if I use omapfb_vram
> argument.
> > > Did you see this on OMAP?
> > >
> > > I am using "omapfb_vram=10M at 0xA0000000", and I believe it is correct
> > > way
> > of usage.
> >
> > Hmm ok... The AM4x seems to have issues anyway, as we're seeing
> > underflows easily in other situations also.
> >
> > Well, there's a small difference in the allocation. The normal dma
> > alloc uses
> > dma_alloc_attrs() and passes DMA_ATTR_WRITE_COMBINE as a flag, whereas
> > allocating from the absolute address just uses the piece of memory. I
> > couldn't find how to set write-combine for the abs memory area.
> >
> > Then again, that's for CPU caching, so I don't see why it would affect
> > DSS as such (but that's still something we should measure, cpu
> > read/write perf for normal and abs allocation).
> >
> > The only thought I have is that somehow the reserved memory area is
> > missing some configuration that is done for the rest of the memory.
> > But that's purely a guess, this is totally out of my area of expertise...
> >
> > Vaibhav, just to be sure, can you run both with normal dma_alloc and
> > with the reserve, and verify that the dispc register dumps are the same?
> > I don't see how they could be different, but just to be sure.
> >
> 
> Will check and update you shortly.
> 

I checked both the DSS configuration in both scenarios and they look same to me.


With normal dma_alloc:
===================
root at am43xx-epos-evm:~#
root at am43xx-epos-evm:~#
root at am43xx-epos-evm:~# cat /proc/cmdline
console=ttyO0,115200n8 root=/dev/mmcblk0p2 rw rootfstype=ext3 rootwait mem=128M consoleblank=0 clocksource=gp_timer consoleblank=0 earlyprintk
root at am43xx-epos-evm:~#
root at am43xx-epos-evm:~#
root at am43xx-epos-evm:~#
root at am43xx-epos-evm:~# cat /sys/kernel/debug/omapdss/dss
DSS_REVISION                        00000020
DSS_SYSCONFIG                       00000001
DSS_SYSSTATUS                       00000001
DSS_CONTROL                         00000018
root at am43xx-epos-evm:~#
root at am43xx-epos-evm:~# cat /sys/kernel/debug/omapdss/clk
- DSS -
DSS_FCK (DSS_FCLK1) = 198000000
- DISPC -
dispc fclk source = DSS_FCK (DSS_FCLK1)
fck             198000000
- LCD -
LCD clk source = DSS_FCK (DSS_FCLK1)
lck             198000000       lck div 1
pck             33000000        pck div 6
root at am43xx-epos-evm:~#
root at am43xx-epos-evm:~# cat /sys/kernel/debug/omapdss/dispc_irq
period 44780 ms
irqs 1
FRAMEDONE                     0
VSYNC                         1
EVSYNC_EVEN                   1
EVSYNC_ODD                    1
ACBIAS_COUNT_STAT             0
PROG_LINE_NUM                 1
GFX_FIFO_UNDERFLOW            0
GFX_END_WIN                   1
PAL_GAMMA_MASK                0
OCP_ERR                       0
VID1_FIFO_UNDERFLOW           0
VID1_END_WIN                  0
VID2_FIFO_UNDERFLOW           0
VID2_END_WIN                  0
SYNC_LOST                     0
SYNC_LOST_DIGIT               0
WAKEUP                        0
root at am43xx-epos-evm:~#
root at am43xx-epos-evm:~# cat /sys/kernel/debug/omapdss/dispc
DISPC_REVISION                                     00000030
DISPC_SYSCONFIG                                    00002011
DISPC_SYSSTATUS                                    00000001
DISPC_IRQSTATUS                                    000000ae
DISPC_IRQENABLE                                    0000d640
DISPC_CONTROL                                      00018309
DISPC_CONFIG                                       00000204
DISPC_CAPABLE                                      000003ff
DISPC_LINE_STATUS                                  000000b1
DISPC_LINE_NUMBER                                  00000000
DISPC_GLOBAL_ALPHA                                 000000ff
DISPC_DEFAULT_COLOR(LCD)                           00000000
DISPC_TRANS_COLOR(LCD)                             00000000
DISPC_SIZE_MGR(LCD)                                01df031f
DISPC_DEFAULT_COLOR(LCD)                           00000000
DISPC_TRANS_COLOR(LCD)                             00000000
DISPC_TIMING_H(LCD)                                00f0d11d
DISPC_TIMING_V(LCD)                                00a0160c
DISPC_POL_FREQ(LCD)                                00003000
DISPC_DIVISORo(LCD)                                00010006
DISPC_SIZE_MGR(LCD)                                01df031f
DISPC_DATA_CYCLE1(LCD)                             00000000
DISPC_DATA_CYCLE2(LCD)                             00000000
DISPC_DATA_CYCLE3(LCD)                             00000000
DISPC_CPR_COEF_R(LCD)                              00000000
DISPC_CPR_COEF_G(LCD)                              00000000
DISPC_CPR_COEF_B(LCD)                              00000000
DISPC_OVL_BA0(GFX)                                 86900000
DISPC_OVL_BA1(GFX)                                 86900000
DISPC_OVL_POSITION(GFX)                            00000000
DISPC_OVL_SIZE(GFX)                                01df031f
DISPC_OVL_ATTRIBUTES(GFX)                          00000091
DISPC_OVL_FIFO_THRESHOLD(GFX)                      03ff03c0
DISPC_OVL_FIFO_SIZE_STATUS(GFX)                    00000400
DISPC_OVL_ROW_INC(GFX)                             00000001
DISPC_OVL_PIXEL_INC(GFX)                           00000001
DISPC_OVL_PRELOAD(GFX)                             00000100
DISPC_OVL_WINDOW_SKIP(GFX)                         00000000
DISPC_OVL_TABLE_BA(GFX)                            00000000
DISPC_OVL_BA0(VID1)                                00000000
DISPC_OVL_BA1(VID1)                                00000000
DISPC_OVL_POSITION(VID1)                           00000000
DISPC_OVL_SIZE(VID1)                               00000000
DISPC_OVL_ATTRIBUTES(VID1)                         00008000
DISPC_OVL_FIFO_THRESHOLD(VID1)                     03ff03c0
DISPC_OVL_FIFO_SIZE_STATUS(VID1)                   00000400
DISPC_OVL_ROW_INC(VID1)                            00000001
DISPC_OVL_PIXEL_INC(VID1)                          00000001
DISPC_OVL_PRELOAD(VID1)                            00000100
DISPC_OVL_FIR(VID1)                                00000000
DISPC_OVL_PICTURE_SIZE(VID1)                       00000000
DISPC_OVL_ACCU0(VID1)                              00000000
DISPC_OVL_ACCU1(VID1)                              00000000
DISPC_OVL_PRELOAD(VID1)                            00000100
DISPC_OVL_BA0(VID2)                                00000000
DISPC_OVL_BA1(VID2)                                00000000
DISPC_OVL_POSITION(VID2)                           00000000
DISPC_OVL_SIZE(VID2)                               00000000
DISPC_OVL_ATTRIBUTES(VID2)                         00008000
DISPC_OVL_FIFO_THRESHOLD(VID2)                     03ff03c0
DISPC_OVL_FIFO_SIZE_STATUS(VID2)                   00000400
DISPC_OVL_ROW_INC(VID2)                            00000001
DISPC_OVL_PIXEL_INC(VID2)                          00000001
DISPC_OVL_PRELOAD(VID2)                            00000100
DISPC_OVL_FIR(VID2)                                00000000
DISPC_OVL_PICTURE_SIZE(VID2)                       00000000
DISPC_OVL_ACCU0(VID2)                              00000000
DISPC_OVL_ACCU1(VID2)                              00000000
DISPC_OVL_PRELOAD(VID2)                            00000100
DISPC_OVL_FIR_COEF_H_0(VID1)                       00000000
DISPC_OVL_FIR_COEF_H_1(VID1)                       00000000
DISPC_OVL_FIR_COEF_H_2(VID1)                       00000000
DISPC_OVL_FIR_COEF_H_3(VID1)                       00000000
DISPC_OVL_FIR_COEF_H_4(VID1)                       00000000
DISPC_OVL_FIR_COEF_H_5(VID1)                       00000000
DISPC_OVL_FIR_COEF_H_6(VID1)                       00000000
DISPC_OVL_FIR_COEF_H_7(VID1)                       00000000
DISPC_OVL_FIR_COEF_HV_0(VID1)                      00000000
DISPC_OVL_FIR_COEF_HV_1(VID1)                      00000000
DISPC_OVL_FIR_COEF_HV_2(VID1)                      00000000
DISPC_OVL_FIR_COEF_HV_3(VID1)                      00000000
DISPC_OVL_FIR_COEF_HV_4(VID1)                      00000000
DISPC_OVL_FIR_COEF_HV_5(VID1)                      00000000
DISPC_OVL_FIR_COEF_HV_6(VID1)                      00000000
DISPC_OVL_FIR_COEF_HV_7(VID1)                      00000000
DISPC_OVL_CONV_COEF_0(VID1)                        0199012a
DISPC_OVL_CONV_COEF_1(VID1)                        012a0000
DISPC_OVL_CONV_COEF_2(VID1)                        079c0730
DISPC_OVL_CONV_COEF_3(VID1)                        0000012a
DISPC_OVL_CONV_COEF_4(VID1)                        00000205
DISPC_OVL_FIR_COEF_V_0(VID1)                       00000000
DISPC_OVL_FIR_COEF_V_1(VID1)                       00000000
DISPC_OVL_FIR_COEF_V_2(VID1)                       00000000
DISPC_OVL_FIR_COEF_V_3(VID1)                       00000000
DISPC_OVL_FIR_COEF_V_4(VID1)                       00000000
DISPC_OVL_FIR_COEF_V_5(VID1)                       00000000
DISPC_OVL_FIR_COEF_V_6(VID1)                       00000000
DISPC_OVL_FIR_COEF_V_7(VID1)                       00000000
DISPC_OVL_FIR_COEF_H_0(VID2)                       00000000
DISPC_OVL_FIR_COEF_H_1(VID2)                       00000000
DISPC_OVL_FIR_COEF_H_2(VID2)                       00000000
DISPC_OVL_FIR_COEF_H_3(VID2)                       00000000
DISPC_OVL_FIR_COEF_H_4(VID2)                       00000000
DISPC_OVL_FIR_COEF_H_5(VID2)                       00000000
DISPC_OVL_FIR_COEF_H_6(VID2)                       00000000
DISPC_OVL_FIR_COEF_H_7(VID2)                       00000000
DISPC_OVL_FIR_COEF_HV_0(VID2)                      00000000
DISPC_OVL_FIR_COEF_HV_1(VID2)                      00000000
DISPC_OVL_FIR_COEF_HV_2(VID2)                      00000000
DISPC_OVL_FIR_COEF_HV_3(VID2)                      00000000
DISPC_OVL_FIR_COEF_HV_4(VID2)                      00000000
DISPC_OVL_FIR_COEF_HV_5(VID2)                      00000000
DISPC_OVL_FIR_COEF_HV_6(VID2)                      00000000
DISPC_OVL_FIR_COEF_HV_7(VID2)                      00000000
DISPC_OVL_CONV_COEF_0(VID2)                        0199012a
DISPC_OVL_CONV_COEF_1(VID2)                        012a0000
DISPC_OVL_CONV_COEF_2(VID2)                        079c0730
DISPC_OVL_CONV_COEF_3(VID2)                        0000012a
DISPC_OVL_CONV_COEF_4(VID2)                        00000205
DISPC_OVL_FIR_COEF_V_0(VID2)                       00000000
DISPC_OVL_FIR_COEF_V_1(VID2)                       00000000
DISPC_OVL_FIR_COEF_V_2(VID2)                       00000000
DISPC_OVL_FIR_COEF_V_3(VID2)                       00000000
DISPC_OVL_FIR_COEF_V_4(VID2)                       00000000
DISPC_OVL_FIR_COEF_V_5(VID2)                       00000000
DISPC_OVL_FIR_COEF_V_6(VID2)                       00000000
DISPC_OVL_FIR_COEF_V_7(VID2)                       00000000
root at am43xx-epos-evm:~#




With Reserved memory for FB:
============================
root at am43xx-epos-evm:~# cat /proc/cmdline
console=ttyO0,115200n8 root=/dev/mmcblk0p2 rw rootfstype=ext3 rootwait mem=128M consoleblank=0 clocksource=gp_timer consoleblank=0 earlyprintk omapfb_vram=10M at 0xA0000000
root at am43xx-epos-evm:~#
root at am43xx-epos-evm:~#
root at am43xx-epos-evm:~#
root at am43xx-epos-evm:~# cat /sys/kernel/debug/omapdss/dss
DSS_REVISION                        00000020
DSS_SYSCONFIG                       00000001
DSS_SYSSTATUS                       00000001
DSS_CONTROL                         00000018
root at am43xx-epos-evm:~#
root at am43xx-epos-evm:~# cat /sys/kernel/debug/omapdss/clk
- DSS -
DSS_FCK (DSS_FCLK1) = 198000000
- DISPC -
dispc fclk source = DSS_FCK (DSS_FCLK1)
fck             198000000
- LCD -
LCD clk source = DSS_FCK (DSS_FCLK1)
lck             198000000       lck div 1
pck             33000000        pck div 6
root at am43xx-epos-evm:~#
root at am43xx-epos-evm:~# cat /sys/kernel/debug/omapdss/dispc_irq
period 48010 ms
irqs 2
FRAMEDONE                     0
VSYNC                         2
EVSYNC_EVEN                   2
EVSYNC_ODD                    2
ACBIAS_COUNT_STAT             0
PROG_LINE_NUM                 2
GFX_FIFO_UNDERFLOW            2
GFX_END_WIN                   2
PAL_GAMMA_MASK                0
OCP_ERR                       0
VID1_FIFO_UNDERFLOW           0
VID1_END_WIN                  0
VID2_FIFO_UNDERFLOW           0
VID2_END_WIN                  0
SYNC_LOST                     0

SYNC_LOST_DIGIT               0
WAKEUP                        0
root at am43xx-epos-evm:~#
root at am43xx-epos-evm:~#
root at am43xx-epos-evm:~#
root at am43xx-epos-evm:~# cat /sys/kernel/debug/omapdss/dispc
DISPC_REVISION                                     00000030
DISPC_SYSCONFIG                                    00002011
DISPC_SYSSTATUS                                    00000001
DISPC_IRQSTATUS                                    0000002e
DISPC_IRQENABLE                                    0000d640
DISPC_CONTROL                                      00018309
DISPC_CONFIG                                       00000204
DISPC_CAPABLE                                      000003ff
DISPC_LINE_STATUS                                  0000011d
DISPC_LINE_NUMBER                                  00000000
DISPC_GLOBAL_ALPHA                                 000000ff
DISPC_DEFAULT_COLOR(LCD)                           00000000
DISPC_TRANS_COLOR(LCD)                             00000000
DISPC_SIZE_MGR(LCD)                                01df031f
DISPC_DEFAULT_COLOR(LCD)                           00000000
DISPC_TRANS_COLOR(LCD)                             00000000
DISPC_TIMING_H(LCD)                                00f0d11d
DISPC_TIMING_V(LCD)                                00a0160c
DISPC_POL_FREQ(LCD)                                00003000
DISPC_DIVISORo(LCD)                                00010006
DISPC_SIZE_MGR(LCD)                                01df031f
DISPC_DATA_CYCLE1(LCD)                             00000000
DISPC_DATA_CYCLE2(LCD)                             00000000
DISPC_DATA_CYCLE3(LCD)                             00000000
DISPC_CPR_COEF_R(LCD)                              00000000
DISPC_CPR_COEF_G(LCD)                              00000000
DISPC_CPR_COEF_B(LCD)                              00000000
DISPC_OVL_BA0(GFX)                                 a0000000
DISPC_OVL_BA1(GFX)                                 a0000000
DISPC_OVL_POSITION(GFX)                            00000000
DISPC_OVL_SIZE(GFX)                                01df031f
DISPC_OVL_ATTRIBUTES(GFX)                          00000090
DISPC_OVL_FIFO_THRESHOLD(GFX)                      03ff03c0
DISPC_OVL_FIFO_SIZE_STATUS(GFX)                    00000400
DISPC_OVL_ROW_INC(GFX)                             00000001
DISPC_OVL_PIXEL_INC(GFX)                           00000001
DISPC_OVL_PRELOAD(GFX)                             00000100
DISPC_OVL_WINDOW_SKIP(GFX)                         00000000
DISPC_OVL_TABLE_BA(GFX)                            00000000
DISPC_OVL_BA0(VID1)                                00000000
DISPC_OVL_BA1(VID1)                                00000000
DISPC_OVL_POSITION(VID1)                           00000000
DISPC_OVL_SIZE(VID1)                               00000000
DISPC_OVL_ATTRIBUTES(VID1)                         00008000
DISPC_OVL_FIFO_THRESHOLD(VID1)                     03ff03c0
DISPC_OVL_FIFO_SIZE_STATUS(VID1)                   00000400
DISPC_OVL_ROW_INC(VID1)                            00000001
DISPC_OVL_PIXEL_INC(VID1)                          00000001
DISPC_OVL_PRELOAD(VID1)                            00000100
DISPC_OVL_FIR(VID1)                                00000000
DISPC_OVL_PICTURE_SIZE(VID1)                       00000000
DISPC_OVL_ACCU0(VID1)                              00000000
DISPC_OVL_ACCU1(VID1)                              00000000
DISPC_OVL_PRELOAD(VID1)                            00000100
DISPC_OVL_BA0(VID2)                                00000000
DISPC_OVL_BA1(VID2)                                00000000
DISPC_OVL_POSITION(VID2)                           00000000
DISPC_OVL_SIZE(VID2)                               00000000
DISPC_OVL_ATTRIBUTES(VID2)                         00008000
DISPC_OVL_FIFO_THRESHOLD(VID2)                     03ff03c0
DISPC_OVL_FIFO_SIZE_STATUS(VID2)                   00000400
DISPC_OVL_ROW_INC(VID2)                            00000001
DISPC_OVL_PIXEL_INC(VID2)                          00000001
DISPC_OVL_PRELOAD(VID2)                            00000100
DISPC_OVL_FIR(VID2)                                00000000
DISPC_OVL_PICTURE_SIZE(VID2)                       00000000
DISPC_OVL_ACCU0(VID2)                              00000000
DISPC_OVL_ACCU1(VID2)                              00000000
DISPC_OVL_PRELOAD(VID2)                            00000100
DISPC_OVL_FIR_COEF_H_0(VID1)                       00000000
DISPC_OVL_FIR_COEF_H_1(VID1)                       00000000
DISPC_OVL_FIR_COEF_H_2(VID1)                       00000000
DISPC_OVL_FIR_COEF_H_3(VID1)                       00000000
DISPC_OVL_FIR_COEF_H_4(VID1)                       00000000
DISPC_OVL_FIR_COEF_H_5(VID1)                       00000000
DISPC_OVL_FIR_COEF_H_6(VID1)                       00000000
DISPC_OVL_FIR_COEF_H_7(VID1)                       00000000
DISPC_OVL_FIR_COEF_HV_0(VID1)                      00000000
DISPC_OVL_FIR_COEF_HV_1(VID1)                      00000000
DISPC_OVL_FIR_COEF_HV_2(VID1)                      00000000
DISPC_OVL_FIR_COEF_HV_3(VID1)                      00000000
DISPC_OVL_FIR_COEF_HV_4(VID1)                      00000000
DISPC_OVL_FIR_COEF_HV_5(VID1)                      00000000
DISPC_OVL_FIR_COEF_HV_6(VID1)                      00000000
DISPC_OVL_FIR_COEF_HV_7(VID1)                      00000000
DISPC_OVL_CONV_COEF_0(VID1)                        0199012a
DISPC_OVL_CONV_COEF_1(VID1)                        012a0000
DISPC_OVL_CONV_COEF_2(VID1)                        079c0730
DISPC_OVL_CONV_COEF_3(VID1)                        0000012a
DISPC_OVL_CONV_COEF_4(VID1)                        00000205
DISPC_OVL_FIR_COEF_V_0(VID1)                       00000000
DISPC_OVL_FIR_COEF_V_1(VID1)                       00000000
DISPC_OVL_FIR_COEF_V_2(VID1)                       00000000
DISPC_OVL_FIR_COEF_V_3(VID1)                       00000000
DISPC_OVL_FIR_COEF_V_4(VID1)                       00000000
DISPC_OVL_FIR_COEF_V_5(VID1)                       00000000
DISPC_OVL_FIR_COEF_V_6(VID1)                       00000000
DISPC_OVL_FIR_COEF_V_7(VID1)                       00000000
DISPC_OVL_FIR_COEF_H_0(VID2)                       00000000
DISPC_OVL_FIR_COEF_H_1(VID2)                       00000000
DISPC_OVL_FIR_COEF_H_2(VID2)                       00000000
DISPC_OVL_FIR_COEF_H_3(VID2)                       00000000
DISPC_OVL_FIR_COEF_H_4(VID2)                       00000000
DISPC_OVL_FIR_COEF_H_5(VID2)                       00000000
DISPC_OVL_FIR_COEF_H_6(VID2)                       00000000
DISPC_OVL_FIR_COEF_H_7(VID2)                       00000000
DISPC_OVL_FIR_COEF_HV_0(VID2)                      00000000
DISPC_OVL_FIR_COEF_HV_1(VID2)                      00000000
DISPC_OVL_FIR_COEF_HV_2(VID2)                      00000000
DISPC_OVL_FIR_COEF_HV_3(VID2)                      00000000
DISPC_OVL_FIR_COEF_HV_4(VID2)                      00000000
DISPC_OVL_FIR_COEF_HV_5(VID2)                      00000000
DISPC_OVL_FIR_COEF_HV_6(VID2)                      00000000
DISPC_OVL_FIR_COEF_HV_7(VID2)                      00000000
DISPC_OVL_CONV_COEF_0(VID2)                        0199012a
DISPC_OVL_CONV_COEF_1(VID2)                        012a0000
DISPC_OVL_CONV_COEF_2(VID2)                        079c0730
DISPC_OVL_CONV_COEF_3(VID2)                        0000012a
DISPC_OVL_CONV_COEF_4(VID2)                        00000205
DISPC_OVL_FIR_COEF_V_0(VID2)                       00000000
DISPC_OVL_FIR_COEF_V_1(VID2)                       00000000
DISPC_OVL_FIR_COEF_V_2(VID2)                       00000000
DISPC_OVL_FIR_COEF_V_3(VID2)                       00000000
DISPC_OVL_FIR_COEF_V_4(VID2)                       00000000
DISPC_OVL_FIR_COEF_V_5(VID2)                       00000000
DISPC_OVL_FIR_COEF_V_6(VID2)                       00000000
DISPC_OVL_FIR_COEF_V_7(VID2)                       00000000
root at am43xx-epos-evm:~#

Re: [PATCH 1/2] ARM: omapfb: add coherent dma memory support

[Ivaylo Dimitrov]

On 09.01.2014 10:08, Hiremath, Vaibhav wrote:

>
> No, that's what is causing issue to me. Can you try predefined address flow?
>
> Thanks,
> Vaibhav
>

Booting Linux on physical CPU 0x0
Initializing cgroup subsys cpu
Linux version 3.13.0-rc7+ (maemo@maemo-desktop) (gcc version 4.7.2 
20120701 (prerelease) (Linaro GCC 4.7-2012.07) ) #24 PREEMPT Sat Jan 11 
17:06:39 EET 2014
CPU: ARMv7 Processor [411fc083] revision 3 (ARMv7), cr\x10c53c7d
CPU: PIPT / VIPT nonaliasing data cache, VIPT nonaliasing instruction cache
Machine: Nokia RX-51 board
omapfb: reserved 0x00800000 bytes at 0x8f100000
Memory policy: Data cache writeback
On node 0 totalpages: 61696
free_area_init_node: node 0, pgdat c05b73b4, node_mem_map c061b000
   Normal zone: 512 pages used for memmap
   Normal zone: 0 pages reserved
   Normal zone: 61696 pages, LIFO batch:15
CPU: All CPU(s) started in SVC mode.
OMAP3430/3530 ES3.1 (l2cache iva sgx neon isp )
pcpu-alloc: s0 r0 d32768 u32768 alloc=1*32768
pcpu-alloc: [0] 0
Built 1 zonelists in Zone order, mobility grouping on.  Total pages: 61184
Kernel command line: init=/sbin/preinit ubi.mtd=rootfs root=ubi0:rootfs 
rootfstype=ubifs rootflags=bulk_read,no_chk_data_crc rw 
mtdoops.mtddev=log console=tty0 console=ttyO2 omapfb_vram=8M@0x8F100000 
omapfb.mode=lcd:848x480-16


There are no (UNDERFLOW) errors on OMAP3 when predefined address is 
used, I am still able to play every video I try.

Ivo

Re: [PATCH 1/2] ARM: omapfb: add coherent dma memory support

[Ivaylo Dimitrov]

On 09.01.2014 10:08, Hiremath, Vaibhav wrote:

>
> No, that's what is causing issue to me. Can you try predefined address flow?
>
> Thanks,
> Vaibhav
>

Booting Linux on physical CPU 0x0
Initializing cgroup subsys cpu
Linux version 3.13.0-rc7+ (maemo@maemo-desktop) (gcc version 4.7.2 
20120701 (prerelease) (Linaro GCC 4.7-2012.07) ) #24 PREEMPT Sat Jan 11 
17:06:39 EET 2014
CPU: ARMv7 Processor [411fc083] revision 3 (ARMv7), cr=10c53c7d
CPU: PIPT / VIPT nonaliasing data cache, VIPT nonaliasing instruction cache
Machine: Nokia RX-51 board
omapfb: reserved 0x00800000 bytes at 0x8f100000
Memory policy: Data cache writeback
On node 0 totalpages: 61696
free_area_init_node: node 0, pgdat c05b73b4, node_mem_map c061b000
   Normal zone: 512 pages used for memmap
   Normal zone: 0 pages reserved
   Normal zone: 61696 pages, LIFO batch:15
CPU: All CPU(s) started in SVC mode.
OMAP3430/3530 ES3.1 (l2cache iva sgx neon isp )
pcpu-alloc: s0 r0 d32768 u32768 alloc=1*32768
pcpu-alloc: [0] 0
Built 1 zonelists in Zone order, mobility grouping on.  Total pages: 61184
Kernel command line: init=/sbin/preinit ubi.mtd=rootfs root=ubi0:rootfs 
rootfstype=ubifs rootflags=bulk_read,no_chk_data_crc rw 
mtdoops.mtddev=log console=tty0 console=ttyO2 omapfb_vram=8M@0x8F100000 
omapfb.mode=lcd:848x480-16


There are no (UNDERFLOW) errors on OMAP3 when predefined address is 
used, I am still able to play every video I try.

Ivo

[PATCH 1/2] ARM: omapfb: add coherent dma memory support

[Ivaylo Dimitrov]

On 09.01.2014 10:08, Hiremath, Vaibhav wrote:

>
> No, that's what is causing issue to me. Can you try predefined address flow?
>
> Thanks,
> Vaibhav
>

Booting Linux on physical CPU 0x0
Initializing cgroup subsys cpu
Linux version 3.13.0-rc7+ (maemo at maemo-desktop) (gcc version 4.7.2 
20120701 (prerelease) (Linaro GCC 4.7-2012.07) ) #24 PREEMPT Sat Jan 11 
17:06:39 EET 2014
CPU: ARMv7 Processor [411fc083] revision 3 (ARMv7), cr=10c53c7d
CPU: PIPT / VIPT nonaliasing data cache, VIPT nonaliasing instruction cache
Machine: Nokia RX-51 board
omapfb: reserved 0x00800000 bytes at 0x8f100000
Memory policy: Data cache writeback
On node 0 totalpages: 61696
free_area_init_node: node 0, pgdat c05b73b4, node_mem_map c061b000
   Normal zone: 512 pages used for memmap
   Normal zone: 0 pages reserved
   Normal zone: 61696 pages, LIFO batch:15
CPU: All CPU(s) started in SVC mode.
OMAP3430/3530 ES3.1 (l2cache iva sgx neon isp )
pcpu-alloc: s0 r0 d32768 u32768 alloc=1*32768
pcpu-alloc: [0] 0
Built 1 zonelists in Zone order, mobility grouping on.  Total pages: 61184
Kernel command line: init=/sbin/preinit ubi.mtd=rootfs root=ubi0:rootfs 
rootfstype=ubifs rootflags=bulk_read,no_chk_data_crc rw 
mtdoops.mtddev=log console=tty0 console=ttyO2 omapfb_vram=8M at 0x8F100000 
omapfb.mode=lcd:848x480-16


There are no (UNDERFLOW) errors on OMAP3 when predefined address is 
used, I am still able to play every video I try.

Ivo

Re: [PATCH 1/2] ARM: omapfb: add coherent dma memory support

[Ivaylo Dimitrov]

Hmm, maybe this https://lkml.org/lkml/2014/1/22/386 will solve our issues

Ivo

Re: [PATCH 1/2] ARM: omapfb: add coherent dma memory support

[Ivaylo Dimitrov]

Hmm, maybe this https://lkml.org/lkml/2014/1/22/386 will solve our issues

Ivo

[PATCH 1/2] ARM: omapfb: add coherent dma memory support

[Ivaylo Dimitrov]

Hmm, maybe this https://lkml.org/lkml/2014/1/22/386 will solve our issues

Ivo

RE: [PATCH 1/2] ARM: omapfb: add coherent dma memory support

[Hiremath, Vaibhav]

> -----Original Message-----
> From: Ivaylo Dimitrov [mailto:ivo.g.dimitrov.75@gmail.com]
> Sent: Thursday, January 23, 2014 2:38 AM
> To: Hiremath, Vaibhav; Ivaylo Dimitrov; Valkeinen, Tomi
> Cc: linux-omap@vger.kernel.org; linux-arm-kernel@lists.infradead.org; linux-
> fbdev@vger.kernel.org
> Subject: Re: [PATCH 1/2] ARM: omapfb: add coherent dma memory support
> 
> Hmm, maybe this https://lkml.org/lkml/2014/1/22/386 will solve our issues
> 
Link seems to be coming blank to me :)

Thanks,
Vaibhav

RE: [PATCH 1/2] ARM: omapfb: add coherent dma memory support

[Hiremath, Vaibhav]

> -----Original Message-----
> From: Ivaylo Dimitrov [mailto:ivo.g.dimitrov.75@gmail.com]
> Sent: Thursday, January 23, 2014 2:38 AM
> To: Hiremath, Vaibhav; Ivaylo Dimitrov; Valkeinen, Tomi
> Cc: linux-omap@vger.kernel.org; linux-arm-kernel@lists.infradead.org; linux-
> fbdev@vger.kernel.org
> Subject: Re: [PATCH 1/2] ARM: omapfb: add coherent dma memory support
> 
> Hmm, maybe this https://lkml.org/lkml/2014/1/22/386 will solve our issues
> 
Link seems to be coming blank to me :)

Thanks,
Vaibhav

[PATCH 1/2] ARM: omapfb: add coherent dma memory support

[Hiremath, Vaibhav]

> -----Original Message-----
> From: Ivaylo Dimitrov [mailto:ivo.g.dimitrov.75 at gmail.com]
> Sent: Thursday, January 23, 2014 2:38 AM
> To: Hiremath, Vaibhav; Ivaylo Dimitrov; Valkeinen, Tomi
> Cc: linux-omap at vger.kernel.org; linux-arm-kernel at lists.infradead.org; linux-
> fbdev at vger.kernel.org
> Subject: Re: [PATCH 1/2] ARM: omapfb: add coherent dma memory support
> 
> Hmm, maybe this https://lkml.org/lkml/2014/1/22/386 will solve our issues
> 
Link seems to be coming blank to me :)

Thanks,
Vaibhav

Re: [PATCH 1/2] ARM: omapfb: add coherent dma memory support

[Tomi Valkeinen]

[-- Attachment #1: Type: text/plain, Size: 374 bytes --]

On 2014-01-22 23:08, Ivaylo Dimitrov wrote:
> Hmm, maybe this https://lkml.org/lkml/2014/1/22/386 will solve our issues

I don't know, it wasn't immediately clear to me if the reserved memory
was handled with CMA or not.

Also, we have this funniness that omapfb is not present in DT data, so
we can't give reserved memory to omapfb directly like that.

 Tomi



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]

Re: [PATCH 1/2] ARM: omapfb: add coherent dma memory support

[Tomi Valkeinen]

[-- Attachment #1: Type: text/plain, Size: 374 bytes --]

On 2014-01-22 23:08, Ivaylo Dimitrov wrote:
> Hmm, maybe this https://lkml.org/lkml/2014/1/22/386 will solve our issues

I don't know, it wasn't immediately clear to me if the reserved memory
was handled with CMA or not.

Also, we have this funniness that omapfb is not present in DT data, so
we can't give reserved memory to omapfb directly like that.

 Tomi



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]

[PATCH 1/2] ARM: omapfb: add coherent dma memory support

[Tomi Valkeinen]

On 2014-01-22 23:08, Ivaylo Dimitrov wrote:
> Hmm, maybe this https://lkml.org/lkml/2014/1/22/386 will solve our issues

I don't know, it wasn't immediately clear to me if the reserved memory
was handled with CMA or not.

Also, we have this funniness that omapfb is not present in DT data, so
we can't give reserved memory to omapfb directly like that.

 Tomi


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 901 bytes
Desc: OpenPGP digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140124/ee42870f/attachment.sig>