* [PATCH 1/5] OMAP: FB: use DMA_BIT_MASK() for fb's coherent_dma_mask
2012-11-12 10:25 [PATCH 0/5] OMAPFB: use dma_alloc instead of omap's vram Tomi Valkeinen
@ 2012-11-12 10:25 ` Tomi Valkeinen
2012-11-12 10:25 ` [PATCH 2/5] OMAPFB: use dma_alloc_attrs to allocate memory Tomi Valkeinen
` (5 subsequent siblings)
6 siblings, 0 replies; 17+ messages in thread
From: Tomi Valkeinen @ 2012-11-12 10:25 UTC (permalink / raw)
To: linux-arm-kernel
Use DMA_BIT_MASK() for fb's coherent_dma_mask for clarity.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
---
arch/arm/plat-omap/fb.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/arch/arm/plat-omap/fb.c b/arch/arm/plat-omap/fb.c
index bcbb9d5..218963b 100644
--- a/arch/arm/plat-omap/fb.c
+++ b/arch/arm/plat-omap/fb.c
@@ -29,6 +29,7 @@
#include <linux/memblock.h>
#include <linux/io.h>
#include <linux/omapfb.h>
+#include <linux/dma-mapping.h>
#include <mach/hardware.h>
#include <asm/mach/map.h>
@@ -45,7 +46,7 @@ static struct platform_device omap_fb_device = {
.id = -1,
.dev = {
.dma_mask = &omap_fb_dma_mask,
- .coherent_dma_mask = ~(u32)0,
+ .coherent_dma_mask = DMA_BIT_MASK(32),
.platform_data = &omapfb_config,
},
.num_resources = 0,
@@ -81,7 +82,7 @@ static struct platform_device omap_fb_device = {
.id = -1,
.dev = {
.dma_mask = &omap_fb_dma_mask,
- .coherent_dma_mask = ~(u32)0,
+ .coherent_dma_mask = DMA_BIT_MASK(32),
.platform_data = &omapfb_config,
},
.num_resources = 0,
--
1.7.10.4
^ permalink raw reply related [flat|nested] 17+ messages in thread* [PATCH 2/5] OMAPFB: use dma_alloc_attrs to allocate memory
2012-11-12 10:25 [PATCH 0/5] OMAPFB: use dma_alloc instead of omap's vram Tomi Valkeinen
2012-11-12 10:25 ` [PATCH 1/5] OMAP: FB: use DMA_BIT_MASK() for fb's coherent_dma_mask Tomi Valkeinen
@ 2012-11-12 10:25 ` Tomi Valkeinen
2012-11-12 10:25 ` [PATCH 3/5] OMAP: RX51: remove use of vram Tomi Valkeinen
` (4 subsequent siblings)
6 siblings, 0 replies; 17+ messages in thread
From: Tomi Valkeinen @ 2012-11-12 10:25 UTC (permalink / raw)
To: linux-arm-kernel
Use dma_alloc_attrs to allocate memory instead of omap specific vram
allocator. After this we can remove the omap vram allocator.
There are some downsides to this change:
1) dma_alloc_attrs doesn't let us allocate at certain physical address.
However, this should not be a problem as this feature of vram allocator
is only used when reserving the framebuffer that was initialized by the
bootloader, and we don't currently support "passing" a framebuffer from
the bootloader to the kernel anyway.
2) dma_alloc_attrs, as of now, always ioremaps the allocated area, and
we don't need the ioremap when using VRFB. This patch uses
DMA_ATTR_NO_KERNEL_MAPPING for the allocation, but the flag is currently
not operational.
3) OMAPFB_GET_VRAM_INFO ioctl cannot return real values anymore. I
changed the ioctl to return 64M for all the values, which, I hope, the
applications will interpret as "there's enough vram".
4) "vram" kernel parameter to define how much ram to reserve for video
use no longer works. The user needs to enable CMA and use "cma"
parameter.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
---
drivers/video/omap2/omapfb/Kconfig | 1 -
drivers/video/omap2/omapfb/omapfb-ioctl.c | 14 +++---
drivers/video/omap2/omapfb/omapfb-main.c | 69 +++++++++++++++--------------
drivers/video/omap2/omapfb/omapfb.h | 5 +++
4 files changed, 48 insertions(+), 41 deletions(-)
diff --git a/drivers/video/omap2/omapfb/Kconfig b/drivers/video/omap2/omapfb/Kconfig
index 4ea17dc..4cb12ce 100644
--- a/drivers/video/omap2/omapfb/Kconfig
+++ b/drivers/video/omap2/omapfb/Kconfig
@@ -2,7 +2,6 @@ menuconfig FB_OMAP2
tristate "OMAP2+ frame buffer support"
depends on FB && OMAP2_DSS && !DRM_OMAP
- select OMAP2_VRAM
select OMAP2_VRFB if ARCH_OMAP2 || ARCH_OMAP3
select FB_CFB_FILLRECT
select FB_CFB_COPYAREA
diff --git a/drivers/video/omap2/omapfb/omapfb-ioctl.c b/drivers/video/omap2/omapfb/omapfb-ioctl.c
index 606b89f..574c170 100644
--- a/drivers/video/omap2/omapfb/omapfb-ioctl.c
+++ b/drivers/video/omap2/omapfb/omapfb-ioctl.c
@@ -31,7 +31,6 @@
#include <video/omapdss.h>
#include <plat/vrfb.h>
-#include <plat/vram.h>
#include "omapfb.h"
@@ -853,14 +852,15 @@ int omapfb_ioctl(struct fb_info *fbi, unsigned int cmd, unsigned long arg)
break;
case OMAPFB_GET_VRAM_INFO: {
- unsigned long vram, free, largest;
-
DBG("ioctl GET_VRAM_INFO\n");
- omap_vram_get_info(&vram, &free, &largest);
- p.vram_info.total = vram;
- p.vram_info.free = free;
- p.vram_info.largest_free_block = largest;
+ /*
+ * We don't have the ability to get this vram info anymore.
+ * Fill in something that should keep the applications working.
+ */
+ p.vram_info.total = SZ_1M * 64;
+ p.vram_info.free = SZ_1M * 64;
+ p.vram_info.largest_free_block = SZ_1M * 64;
if (copy_to_user((void __user *)arg, &p.vram_info,
sizeof(p.vram_info)))
diff --git a/drivers/video/omap2/omapfb/omapfb-main.c b/drivers/video/omap2/omapfb/omapfb-main.c
index 16db158..84c1012 100644
--- a/drivers/video/omap2/omapfb/omapfb-main.c
+++ b/drivers/video/omap2/omapfb/omapfb-main.c
@@ -32,7 +32,6 @@
#include <video/omapdss.h>
#include <plat/cpu.h>
-#include <plat/vram.h>
#include <plat/vrfb.h>
#include "omapfb.h"
@@ -1336,24 +1335,25 @@ static void omapfb_free_fbmem(struct fb_info *fbi)
rg = ofbi->region;
- WARN_ON(atomic_read(&rg->map_count));
-
- if (rg->paddr)
- if (omap_vram_free(rg->paddr, rg->size))
- dev_err(fbdev->dev, "VRAM FREE failed\n");
+ if (rg->token = NULL)
+ return;
- if (rg->vaddr)
- iounmap(rg->vaddr);
+ WARN_ON(atomic_read(&rg->map_count));
if (ofbi->rotation_type = OMAP_DSS_ROT_VRFB) {
/* unmap the 0 angle rotation */
if (rg->vrfb.vaddr[0]) {
iounmap(rg->vrfb.vaddr[0]);
- omap_vrfb_release_ctx(&rg->vrfb);
rg->vrfb.vaddr[0] = NULL;
}
+
+ omap_vrfb_release_ctx(&rg->vrfb);
}
+ dma_free_attrs(fbdev->dev, rg->size, rg->token, rg->dma_handle,
+ &rg->attrs);
+
+ rg->token = NULL;
rg->vaddr = NULL;
rg->paddr = 0;
rg->alloc = 0;
@@ -1388,7 +1388,9 @@ static int omapfb_alloc_fbmem(struct fb_info *fbi, unsigned long size,
struct omapfb_info *ofbi = FB2OFB(fbi);
struct omapfb2_device *fbdev = ofbi->fbdev;
struct omapfb2_mem_region *rg;
- void __iomem *vaddr;
+ void *token;
+ DEFINE_DMA_ATTRS(attrs);
+ dma_addr_t dma_handle;
int r;
rg = ofbi->region;
@@ -1403,42 +1405,43 @@ static int omapfb_alloc_fbmem(struct fb_info *fbi, unsigned long size,
size = PAGE_ALIGN(size);
- if (!paddr) {
- DBG("allocating %lu bytes for fb %d\n", size, ofbi->id);
- r = omap_vram_alloc(size, &paddr);
- } else {
- DBG("reserving %lu bytes at %lx for fb %d\n", size, paddr,
- ofbi->id);
- r = omap_vram_reserve(paddr, size);
- }
+ WARN_ONCE(paddr,
+ "reserving memory at predefined address not supported\n");
- if (r) {
+ dma_set_attr(DMA_ATTR_WRITE_COMBINE, &attrs);
+
+ if (ofbi->rotation_type = OMAP_DSS_ROT_VRFB)
+ dma_set_attr(DMA_ATTR_NO_KERNEL_MAPPING, &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");
return -ENOMEM;
}
- if (ofbi->rotation_type != OMAP_DSS_ROT_VRFB) {
- vaddr = ioremap_wc(paddr, size);
-
- if (!vaddr) {
- dev_err(fbdev->dev, "failed to ioremap framebuffer\n");
- omap_vram_free(paddr, size);
- return -ENOMEM;
- }
+ DBG("allocated VRAM paddr %lx, vaddr %p\n",
+ (unsigned long)dma_handle, token);
- DBG("allocated VRAM paddr %lx, vaddr %p\n", paddr, vaddr);
- } else {
+ if (ofbi->rotation_type = OMAP_DSS_ROT_VRFB) {
r = omap_vrfb_request_ctx(&rg->vrfb);
if (r) {
+ dma_free_attrs(fbdev->dev, size, token, dma_handle,
+ &attrs);
dev_err(fbdev->dev, "vrfb create ctx failed\n");
return r;
}
-
- vaddr = NULL;
}
- rg->paddr = paddr;
- rg->vaddr = vaddr;
+ rg->attrs = attrs;
+ rg->token = token;
+ rg->dma_handle = dma_handle;
+
+ rg->paddr = (unsigned long)dma_handle;
+ rg->vaddr = (void __iomem *)token;
rg->size = size;
rg->alloc = 1;
diff --git a/drivers/video/omap2/omapfb/omapfb.h b/drivers/video/omap2/omapfb/omapfb.h
index 5ced9b3..5f72bf9 100644
--- a/drivers/video/omap2/omapfb/omapfb.h
+++ b/drivers/video/omap2/omapfb/omapfb.h
@@ -28,6 +28,8 @@
#endif
#include <linux/rwsem.h>
+#include <linux/dma-attrs.h>
+#include <linux/dma-mapping.h>
#include <video/omapdss.h>
@@ -49,6 +51,9 @@ extern bool omapfb_debug;
struct omapfb2_mem_region {
int id;
+ struct dma_attrs attrs;
+ void *token;
+ dma_addr_t dma_handle;
u32 paddr;
void __iomem *vaddr;
struct vrfb vrfb;
--
1.7.10.4
^ permalink raw reply related [flat|nested] 17+ messages in thread* [PATCH 3/5] OMAP: RX51: remove use of vram
2012-11-12 10:25 [PATCH 0/5] OMAPFB: use dma_alloc instead of omap's vram Tomi Valkeinen
2012-11-12 10:25 ` [PATCH 1/5] OMAP: FB: use DMA_BIT_MASK() for fb's coherent_dma_mask Tomi Valkeinen
2012-11-12 10:25 ` [PATCH 2/5] OMAPFB: use dma_alloc_attrs to allocate memory Tomi Valkeinen
@ 2012-11-12 10:25 ` Tomi Valkeinen
2012-11-12 10:25 ` [PATCH 4/5] OMAP: common.c: remove init call to vram Tomi Valkeinen
` (3 subsequent siblings)
6 siblings, 0 replies; 17+ messages in thread
From: Tomi Valkeinen @ 2012-11-12 10:25 UTC (permalink / raw)
To: linux-arm-kernel
As omapfb no longer uses omap specific vram allocator we can remove the
vram pre-allocation from rx51 board file.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
---
arch/arm/mach-omap2/board-rx51-video.c | 14 --------------
arch/arm/mach-omap2/board-rx51.c | 3 ---
2 files changed, 17 deletions(-)
diff --git a/arch/arm/mach-omap2/board-rx51-video.c b/arch/arm/mach-omap2/board-rx51-video.c
index c22e111..46f4fc9 100644
--- a/arch/arm/mach-omap2/board-rx51-video.c
+++ b/arch/arm/mach-omap2/board-rx51-video.c
@@ -16,7 +16,6 @@
#include <linux/mm.h>
#include <asm/mach-types.h>
#include <video/omapdss.h>
-#include <plat/vram.h>
#include <linux/platform_data/spi-omap2-mcspi.h>
#include "board-rx51.h"
@@ -87,17 +86,4 @@ static int __init rx51_video_init(void)
}
subsys_initcall(rx51_video_init);
-
-void __init rx51_video_mem_init(void)
-{
- /*
- * GFX 864x480x32bpp
- * VID1/2 1280x720x32bpp double buffered
- */
- omap_vram_set_sdram_vram(PAGE_ALIGN(864 * 480 * 4) +
- 2 * PAGE_ALIGN(1280 * 720 * 4 * 2), 0);
-}
-
-#else
-void __init rx51_video_mem_init(void) { }
#endif /* defined(CONFIG_FB_OMAP2) || defined(CONFIG_FB_OMAP2_MODULE) */
diff --git a/arch/arm/mach-omap2/board-rx51.c b/arch/arm/mach-omap2/board-rx51.c
index 7bbb05d..6e0de6f 100644
--- a/arch/arm/mach-omap2/board-rx51.c
+++ b/arch/arm/mach-omap2/board-rx51.c
@@ -34,8 +34,6 @@
#define RX51_GPIO_SLEEP_IND 162
-extern void rx51_video_mem_init(void);
-
static struct gpio_led gpio_leds[] = {
{
.name = "sleep_ind",
@@ -112,7 +110,6 @@ static void __init rx51_init(void)
static void __init rx51_reserve(void)
{
- rx51_video_mem_init();
omap_reserve();
}
--
1.7.10.4
^ permalink raw reply related [flat|nested] 17+ messages in thread* [PATCH 4/5] OMAP: common.c: remove init call to vram
2012-11-12 10:25 [PATCH 0/5] OMAPFB: use dma_alloc instead of omap's vram Tomi Valkeinen
` (2 preceding siblings ...)
2012-11-12 10:25 ` [PATCH 3/5] OMAP: RX51: remove use of vram Tomi Valkeinen
@ 2012-11-12 10:25 ` Tomi Valkeinen
2012-11-12 10:25 ` [PATCH 5/5] OMAP: remove vram allocator Tomi Valkeinen
` (2 subsequent siblings)
6 siblings, 0 replies; 17+ messages in thread
From: Tomi Valkeinen @ 2012-11-12 10:25 UTC (permalink / raw)
To: linux-arm-kernel
OMAP specific vram allocator is no longer used, and we can remove init
call to the vram allocator.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
---
arch/arm/plat-omap/common.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/arch/arm/plat-omap/common.c b/arch/arm/plat-omap/common.c
index 111315a..d21ed18 100644
--- a/arch/arm/plat-omap/common.c
+++ b/arch/arm/plat-omap/common.c
@@ -17,7 +17,6 @@
#include <linux/dma-mapping.h>
#include <plat/common.h>
-#include <plat/vram.h>
#include <linux/platform_data/dsp-omap.h>
#include <plat/dma.h>
@@ -25,7 +24,6 @@
void __init omap_reserve(void)
{
- omap_vram_reserve_sdram_memblock();
omap_dsp_reserve_sdram_memblock();
omap_secure_ram_reserve_memblock();
omap_barrier_reserve_memblock();
--
1.7.10.4
^ permalink raw reply related [flat|nested] 17+ messages in thread* [PATCH 5/5] OMAP: remove vram allocator
2012-11-12 10:25 [PATCH 0/5] OMAPFB: use dma_alloc instead of omap's vram Tomi Valkeinen
` (3 preceding siblings ...)
2012-11-12 10:25 ` [PATCH 4/5] OMAP: common.c: remove init call to vram Tomi Valkeinen
@ 2012-11-12 10:25 ` Tomi Valkeinen
2012-11-12 13:39 ` [PATCH 0/5] OMAPFB: use dma_alloc instead of omap's vram Grazvydas Ignotas
2012-11-12 22:50 ` Tony Lindgren
6 siblings, 0 replies; 17+ messages in thread
From: Tomi Valkeinen @ 2012-11-12 10:25 UTC (permalink / raw)
To: linux-arm-kernel
OMAP specific vram allocator is no longer in use, and we can remove all
the vram code.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
---
arch/arm/plat-omap/include/plat/vram.h | 43 ---
drivers/video/omap2/Kconfig | 3 -
drivers/video/omap2/Makefile | 1 -
drivers/video/omap2/dss/Kconfig | 12 -
drivers/video/omap2/vram.c | 514 --------------------------------
5 files changed, 573 deletions(-)
delete mode 100644 arch/arm/plat-omap/include/plat/vram.h
delete mode 100644 drivers/video/omap2/vram.c
diff --git a/arch/arm/plat-omap/include/plat/vram.h b/arch/arm/plat-omap/include/plat/vram.h
deleted file mode 100644
index 4d65b7d..0000000
--- a/arch/arm/plat-omap/include/plat/vram.h
+++ /dev/null
@@ -1,43 +0,0 @@
-/*
- * VRAM manager for OMAP
- *
- * Copyright (C) 2009 Nokia Corporation
- * Author: Tomi Valkeinen <tomi.valkeinen@nokia.com>
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License version 2 as
- * published by the Free Software Foundation.
- *
- * This program is distributed in the hope that it will be useful, but
- * WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
- * General Public License for more details.
- *
- * You should have received a copy of the GNU General Public License along
- * with this program; if not, write to the Free Software Foundation, Inc.,
- * 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
- */
-
-#ifndef __OMAP_VRAM_H__
-#define __OMAP_VRAM_H__
-
-#include <linux/types.h>
-
-extern int omap_vram_add_region(unsigned long paddr, size_t size);
-extern int omap_vram_free(unsigned long paddr, size_t size);
-extern int omap_vram_alloc(size_t size, unsigned long *paddr);
-extern int omap_vram_reserve(unsigned long paddr, size_t size);
-extern void omap_vram_get_info(unsigned long *vram, unsigned long *free_vram,
- unsigned long *largest_free_block);
-
-#ifdef CONFIG_OMAP2_VRAM
-extern void omap_vram_set_sdram_vram(u32 size, u32 start);
-
-extern void omap_vram_reserve_sdram_memblock(void);
-#else
-static inline void omap_vram_set_sdram_vram(u32 size, u32 start) { }
-
-static inline void omap_vram_reserve_sdram_memblock(void) { }
-#endif
-
-#endif
diff --git a/drivers/video/omap2/Kconfig b/drivers/video/omap2/Kconfig
index d877c36..346d67d 100644
--- a/drivers/video/omap2/Kconfig
+++ b/drivers/video/omap2/Kconfig
@@ -1,6 +1,3 @@
-config OMAP2_VRAM
- bool
-
config OMAP2_VRFB
bool
diff --git a/drivers/video/omap2/Makefile b/drivers/video/omap2/Makefile
index 5ddef12..5ea7cb9 100644
--- a/drivers/video/omap2/Makefile
+++ b/drivers/video/omap2/Makefile
@@ -1,4 +1,3 @@
-obj-$(CONFIG_OMAP2_VRAM) += vram.o
obj-$(CONFIG_OMAP2_VRFB) += vrfb.o
obj-$(CONFIG_OMAP2_DSS) += dss/
diff --git a/drivers/video/omap2/dss/Kconfig b/drivers/video/omap2/dss/Kconfig
index 80f5390..058a669 100644
--- a/drivers/video/omap2/dss/Kconfig
+++ b/drivers/video/omap2/dss/Kconfig
@@ -6,18 +6,6 @@ menuconfig OMAP2_DSS
if OMAP2_DSS
-config OMAP2_VRAM_SIZE
- int "VRAM size (MB)"
- range 0 32
- default 0
- help
- The amount of SDRAM to reserve at boot time for video RAM use.
- This VRAM will be used by omapfb and other drivers that need
- large continuous RAM area for video use.
-
- You can also set this with "vram=<bytes>" kernel argument, or
- in the board file.
-
config OMAP2_DSS_DEBUG_SUPPORT
bool "Debug support"
default y
diff --git a/drivers/video/omap2/vram.c b/drivers/video/omap2/vram.c
deleted file mode 100644
index f2b15c4..0000000
--- a/drivers/video/omap2/vram.c
+++ /dev/null
@@ -1,514 +0,0 @@
-/*
- * VRAM manager for OMAP
- *
- * Copyright (C) 2009 Nokia Corporation
- * Author: Tomi Valkeinen <tomi.valkeinen@nokia.com>
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License version 2 as
- * published by the Free Software Foundation.
- *
- * This program is distributed in the hope that it will be useful, but
- * WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
- * General Public License for more details.
- *
- * You should have received a copy of the GNU General Public License along
- * with this program; if not, write to the Free Software Foundation, Inc.,
- * 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
- */
-
-/*#define DEBUG*/
-
-#include <linux/kernel.h>
-#include <linux/mm.h>
-#include <linux/list.h>
-#include <linux/slab.h>
-#include <linux/seq_file.h>
-#include <linux/memblock.h>
-#include <linux/completion.h>
-#include <linux/debugfs.h>
-#include <linux/jiffies.h>
-#include <linux/module.h>
-
-#include <asm/setup.h>
-
-#include <plat/vram.h>
-
-#ifdef DEBUG
-#define DBG(format, ...) pr_debug("VRAM: " format, ## __VA_ARGS__)
-#else
-#define DBG(format, ...)
-#endif
-
-/* postponed regions are used to temporarily store region information at boot
- * time when we cannot yet allocate the region list */
-#define MAX_POSTPONED_REGIONS 10
-
-static bool vram_initialized;
-static int postponed_cnt;
-static struct {
- unsigned long paddr;
- size_t size;
-} postponed_regions[MAX_POSTPONED_REGIONS];
-
-struct vram_alloc {
- struct list_head list;
- unsigned long paddr;
- unsigned pages;
-};
-
-struct vram_region {
- struct list_head list;
- struct list_head alloc_list;
- unsigned long paddr;
- unsigned pages;
-};
-
-static DEFINE_MUTEX(region_mutex);
-static LIST_HEAD(region_list);
-
-static struct vram_region *omap_vram_create_region(unsigned long paddr,
- unsigned pages)
-{
- struct vram_region *rm;
-
- rm = kzalloc(sizeof(*rm), GFP_KERNEL);
-
- if (rm) {
- INIT_LIST_HEAD(&rm->alloc_list);
- rm->paddr = paddr;
- rm->pages = pages;
- }
-
- return rm;
-}
-
-#if 0
-static void omap_vram_free_region(struct vram_region *vr)
-{
- list_del(&vr->list);
- kfree(vr);
-}
-#endif
-
-static struct vram_alloc *omap_vram_create_allocation(struct vram_region *vr,
- unsigned long paddr, unsigned pages)
-{
- struct vram_alloc *va;
- struct vram_alloc *new;
-
- new = kzalloc(sizeof(*va), GFP_KERNEL);
-
- if (!new)
- return NULL;
-
- new->paddr = paddr;
- new->pages = pages;
-
- list_for_each_entry(va, &vr->alloc_list, list) {
- if (va->paddr > new->paddr)
- break;
- }
-
- list_add_tail(&new->list, &va->list);
-
- return new;
-}
-
-static void omap_vram_free_allocation(struct vram_alloc *va)
-{
- list_del(&va->list);
- kfree(va);
-}
-
-int omap_vram_add_region(unsigned long paddr, size_t size)
-{
- struct vram_region *rm;
- unsigned pages;
-
- if (vram_initialized) {
- DBG("adding region paddr %08lx size %d\n",
- paddr, size);
-
- size &= PAGE_MASK;
- pages = size >> PAGE_SHIFT;
-
- rm = omap_vram_create_region(paddr, pages);
- if (rm = NULL)
- return -ENOMEM;
-
- list_add(&rm->list, ®ion_list);
- } else {
- if (postponed_cnt = MAX_POSTPONED_REGIONS)
- return -ENOMEM;
-
- postponed_regions[postponed_cnt].paddr = paddr;
- postponed_regions[postponed_cnt].size = size;
-
- ++postponed_cnt;
- }
- return 0;
-}
-
-int omap_vram_free(unsigned long paddr, size_t size)
-{
- struct vram_region *rm;
- struct vram_alloc *alloc;
- unsigned start, end;
-
- DBG("free mem paddr %08lx size %d\n", paddr, size);
-
- size = PAGE_ALIGN(size);
-
- mutex_lock(®ion_mutex);
-
- list_for_each_entry(rm, ®ion_list, list) {
- list_for_each_entry(alloc, &rm->alloc_list, list) {
- start = alloc->paddr;
- end = alloc->paddr + (alloc->pages >> PAGE_SHIFT);
-
- if (start >= paddr && end < paddr + size)
- goto found;
- }
- }
-
- mutex_unlock(®ion_mutex);
- return -EINVAL;
-
-found:
- omap_vram_free_allocation(alloc);
-
- mutex_unlock(®ion_mutex);
- return 0;
-}
-EXPORT_SYMBOL(omap_vram_free);
-
-static int _omap_vram_reserve(unsigned long paddr, unsigned pages)
-{
- struct vram_region *rm;
- struct vram_alloc *alloc;
- size_t size;
-
- size = pages << PAGE_SHIFT;
-
- list_for_each_entry(rm, ®ion_list, list) {
- unsigned long start, end;
-
- DBG("checking region %lx %d\n", rm->paddr, rm->pages);
-
- start = rm->paddr;
- end = start + (rm->pages << PAGE_SHIFT) - 1;
- if (start > paddr || end < paddr + size - 1)
- continue;
-
- DBG("block ok, checking allocs\n");
-
- list_for_each_entry(alloc, &rm->alloc_list, list) {
- end = alloc->paddr - 1;
-
- if (start <= paddr && end >= paddr + size - 1)
- goto found;
-
- start = alloc->paddr + (alloc->pages << PAGE_SHIFT);
- }
-
- end = rm->paddr + (rm->pages << PAGE_SHIFT) - 1;
-
- if (!(start <= paddr && end >= paddr + size - 1))
- continue;
-found:
- DBG("found area start %lx, end %lx\n", start, end);
-
- if (omap_vram_create_allocation(rm, paddr, pages) = NULL)
- return -ENOMEM;
-
- return 0;
- }
-
- return -ENOMEM;
-}
-
-int omap_vram_reserve(unsigned long paddr, size_t size)
-{
- unsigned pages;
- int r;
-
- DBG("reserve mem paddr %08lx size %d\n", paddr, size);
-
- size = PAGE_ALIGN(size);
- pages = size >> PAGE_SHIFT;
-
- mutex_lock(®ion_mutex);
-
- r = _omap_vram_reserve(paddr, pages);
-
- mutex_unlock(®ion_mutex);
-
- return r;
-}
-EXPORT_SYMBOL(omap_vram_reserve);
-
-static int _omap_vram_alloc(unsigned pages, unsigned long *paddr)
-{
- struct vram_region *rm;
- struct vram_alloc *alloc;
-
- list_for_each_entry(rm, ®ion_list, list) {
- unsigned long start, end;
-
- DBG("checking region %lx %d\n", rm->paddr, rm->pages);
-
- start = rm->paddr;
-
- list_for_each_entry(alloc, &rm->alloc_list, list) {
- end = alloc->paddr;
-
- if (end - start >= pages << PAGE_SHIFT)
- goto found;
-
- start = alloc->paddr + (alloc->pages << PAGE_SHIFT);
- }
-
- end = rm->paddr + (rm->pages << PAGE_SHIFT);
-found:
- if (end - start < pages << PAGE_SHIFT)
- continue;
-
- DBG("found %lx, end %lx\n", start, end);
-
- alloc = omap_vram_create_allocation(rm, start, pages);
- if (alloc = NULL)
- return -ENOMEM;
-
- *paddr = start;
-
- return 0;
- }
-
- return -ENOMEM;
-}
-
-int omap_vram_alloc(size_t size, unsigned long *paddr)
-{
- unsigned pages;
- int r;
-
- BUG_ON(!size);
-
- DBG("alloc mem size %d\n", size);
-
- size = PAGE_ALIGN(size);
- pages = size >> PAGE_SHIFT;
-
- mutex_lock(®ion_mutex);
-
- r = _omap_vram_alloc(pages, paddr);
-
- mutex_unlock(®ion_mutex);
-
- return r;
-}
-EXPORT_SYMBOL(omap_vram_alloc);
-
-void omap_vram_get_info(unsigned long *vram,
- unsigned long *free_vram,
- unsigned long *largest_free_block)
-{
- struct vram_region *vr;
- struct vram_alloc *va;
-
- *vram = 0;
- *free_vram = 0;
- *largest_free_block = 0;
-
- mutex_lock(®ion_mutex);
-
- list_for_each_entry(vr, ®ion_list, list) {
- unsigned free;
- unsigned long pa;
-
- pa = vr->paddr;
- *vram += vr->pages << PAGE_SHIFT;
-
- list_for_each_entry(va, &vr->alloc_list, list) {
- free = va->paddr - pa;
- *free_vram += free;
- if (free > *largest_free_block)
- *largest_free_block = free;
- pa = va->paddr + (va->pages << PAGE_SHIFT);
- }
-
- free = vr->paddr + (vr->pages << PAGE_SHIFT) - pa;
- *free_vram += free;
- if (free > *largest_free_block)
- *largest_free_block = free;
- }
-
- mutex_unlock(®ion_mutex);
-}
-EXPORT_SYMBOL(omap_vram_get_info);
-
-#if defined(CONFIG_DEBUG_FS)
-static int vram_debug_show(struct seq_file *s, void *unused)
-{
- struct vram_region *vr;
- struct vram_alloc *va;
- unsigned size;
-
- mutex_lock(®ion_mutex);
-
- list_for_each_entry(vr, ®ion_list, list) {
- size = vr->pages << PAGE_SHIFT;
- seq_printf(s, "%08lx-%08lx (%d bytes)\n",
- vr->paddr, vr->paddr + size - 1,
- size);
-
- list_for_each_entry(va, &vr->alloc_list, list) {
- size = va->pages << PAGE_SHIFT;
- seq_printf(s, " %08lx-%08lx (%d bytes)\n",
- va->paddr, va->paddr + size - 1,
- size);
- }
- }
-
- mutex_unlock(®ion_mutex);
-
- return 0;
-}
-
-static int vram_debug_open(struct inode *inode, struct file *file)
-{
- return single_open(file, vram_debug_show, inode->i_private);
-}
-
-static const struct file_operations vram_debug_fops = {
- .open = vram_debug_open,
- .read = seq_read,
- .llseek = seq_lseek,
- .release = single_release,
-};
-
-static int __init omap_vram_create_debugfs(void)
-{
- struct dentry *d;
-
- d = debugfs_create_file("vram", S_IRUGO, NULL,
- NULL, &vram_debug_fops);
- if (IS_ERR(d))
- return PTR_ERR(d);
-
- return 0;
-}
-#endif
-
-static __init int omap_vram_init(void)
-{
- int i;
-
- vram_initialized = 1;
-
- for (i = 0; i < postponed_cnt; i++)
- omap_vram_add_region(postponed_regions[i].paddr,
- postponed_regions[i].size);
-
-#ifdef CONFIG_DEBUG_FS
- if (omap_vram_create_debugfs())
- pr_err("VRAM: Failed to create debugfs file\n");
-#endif
-
- return 0;
-}
-
-arch_initcall(omap_vram_init);
-
-/* boottime vram alloc stuff */
-
-/* set from board file */
-static u32 omap_vram_sdram_start __initdata;
-static u32 omap_vram_sdram_size __initdata;
-
-/* set from kernel cmdline */
-static u32 omap_vram_def_sdram_size __initdata;
-static u32 omap_vram_def_sdram_start __initdata;
-
-static int __init omap_vram_early_vram(char *p)
-{
- omap_vram_def_sdram_size = memparse(p, &p);
- if (*p = ',')
- omap_vram_def_sdram_start = simple_strtoul(p + 1, &p, 16);
- return 0;
-}
-early_param("vram", omap_vram_early_vram);
-
-/*
- * Called from map_io. We need to call to this early enough so that we
- * can reserve the fixed SDRAM regions before VM could get hold of them.
- */
-void __init omap_vram_reserve_sdram_memblock(void)
-{
- u32 paddr;
- u32 size = 0;
-
- /* cmdline arg overrides the board file definition */
- if (omap_vram_def_sdram_size) {
- size = omap_vram_def_sdram_size;
- paddr = omap_vram_def_sdram_start;
- }
-
- if (!size) {
- size = omap_vram_sdram_size;
- paddr = omap_vram_sdram_start;
- }
-
-#ifdef CONFIG_OMAP2_VRAM_SIZE
- if (!size) {
- size = CONFIG_OMAP2_VRAM_SIZE * 1024 * 1024;
- paddr = 0;
- }
-#endif
-
- if (!size)
- return;
-
- size = ALIGN(size, SZ_2M);
-
- if (paddr) {
- if (paddr & ~PAGE_MASK) {
- pr_err("VRAM start address 0x%08x not page aligned\n",
- paddr);
- return;
- }
-
- if (!memblock_is_region_memory(paddr, size)) {
- pr_err("Illegal SDRAM region 0x%08x..0x%08x for VRAM\n",
- paddr, paddr + size - 1);
- return;
- }
-
- if (memblock_is_region_reserved(paddr, size)) {
- pr_err("FB: failed to reserve VRAM - busy\n");
- return;
- }
-
- if (memblock_reserve(paddr, size) < 0) {
- pr_err("FB: failed to reserve VRAM - no memory\n");
- return;
- }
- } else {
- paddr = memblock_alloc(size, SZ_2M);
- }
-
- memblock_free(paddr, size);
- memblock_remove(paddr, size);
-
- omap_vram_add_region(paddr, size);
-
- pr_info("Reserving %u bytes SDRAM for VRAM\n", size);
-}
-
-void __init omap_vram_set_sdram_vram(u32 size, u32 start)
-{
- omap_vram_sdram_start = start;
- omap_vram_sdram_size = size;
-}
--
1.7.10.4
^ permalink raw reply related [flat|nested] 17+ messages in thread* Re: [PATCH 0/5] OMAPFB: use dma_alloc instead of omap's vram
2012-11-12 10:25 [PATCH 0/5] OMAPFB: use dma_alloc instead of omap's vram Tomi Valkeinen
` (4 preceding siblings ...)
2012-11-12 10:25 ` [PATCH 5/5] OMAP: remove vram allocator Tomi Valkeinen
@ 2012-11-12 13:39 ` Grazvydas Ignotas
2012-11-12 13:50 ` Tomi Valkeinen
2012-11-12 13:57 ` Tomi Valkeinen
2012-11-12 22:50 ` Tony Lindgren
6 siblings, 2 replies; 17+ messages in thread
From: Grazvydas Ignotas @ 2012-11-12 13:39 UTC (permalink / raw)
To: linux-arm-kernel
Hi,
On Mon, Nov 12, 2012 at 12:25 PM, Tomi Valkeinen <tomi.valkeinen@ti.com> wrote:
> This series changes omapfb to use standard dma_alloc funcs instead of omap
> specific vram allocator. This let's us remove the omap vram allocator, making
> omapfb platform independent.
>
> However, note that using standard dma funcs causes the following downsides:
>
> ...
>
> 3) OMAPFB_GET_VRAM_INFO ioctl cannot return real values anymore. I
> changed the ioctl to return 64M for all the values, which, I hope, the
> applications will interpret as "there's enough vram".
Do at least OMAPFB_QUERY_MEM/OMAPFB_SETUP_MEM still work?
> 4) "vram" kernel parameter to define how much ram to reserve for video use no
> longer works. The user needs to enable CMA and use "cma" parameter.
That's a significant change, you should update Documentation/ .
What about omapfb.vram, is it still there?
Perhaps we also need to select/depend on CMA?
--
Gražvydas
^ permalink raw reply [flat|nested] 17+ messages in thread* Re: [PATCH 0/5] OMAPFB: use dma_alloc instead of omap's vram
2012-11-12 13:39 ` [PATCH 0/5] OMAPFB: use dma_alloc instead of omap's vram Grazvydas Ignotas
@ 2012-11-12 13:50 ` Tomi Valkeinen
2012-11-12 13:57 ` Tomi Valkeinen
1 sibling, 0 replies; 17+ messages in thread
From: Tomi Valkeinen @ 2012-11-12 13:50 UTC (permalink / raw)
To: linux-arm-kernel
[-- Attachment #1: Type: text/plain, Size: 1308 bytes --]
On 2012-11-12 15:39, Grazvydas Ignotas wrote:
> Hi,
>
> On Mon, Nov 12, 2012 at 12:25 PM, Tomi Valkeinen <tomi.valkeinen@ti.com> wrote:
>> This series changes omapfb to use standard dma_alloc funcs instead of omap
>> specific vram allocator. This let's us remove the omap vram allocator, making
>> omapfb platform independent.
>>
>> However, note that using standard dma funcs causes the following downsides:
>>
>> ...
>>
>> 3) OMAPFB_GET_VRAM_INFO ioctl cannot return real values anymore. I
>> changed the ioctl to return 64M for all the values, which, I hope, the
>> applications will interpret as "there's enough vram".
>
> Do at least OMAPFB_QUERY_MEM/OMAPFB_SETUP_MEM still work?
Yes.
>> 4) "vram" kernel parameter to define how much ram to reserve for video use no
>> longer works. The user needs to enable CMA and use "cma" parameter.
>
> That's a significant change, you should update Documentation/ .
Ah right. The documentation. I never remember =).
> What about omapfb.vram, is it still there?
Yes.
> Perhaps we also need to select/depend on CMA?
dma_alloc_* funcs work fine without CMA. CMA only makes them work
better. Thus I don't think OMAPFB should depend on CMA, but perhaps CMA
should be enabled by default in omap2plus_defconfig?
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 897 bytes --]
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH 0/5] OMAPFB: use dma_alloc instead of omap's vram
2012-11-12 13:39 ` [PATCH 0/5] OMAPFB: use dma_alloc instead of omap's vram Grazvydas Ignotas
2012-11-12 13:50 ` Tomi Valkeinen
@ 2012-11-12 13:57 ` Tomi Valkeinen
1 sibling, 0 replies; 17+ messages in thread
From: Tomi Valkeinen @ 2012-11-12 13:57 UTC (permalink / raw)
To: linux-arm-kernel
[-- Attachment #1: Type: text/plain, Size: 2064 bytes --]
On 2012-11-12 15:39, Grazvydas Ignotas wrote:
> Hi,
>
> On Mon, Nov 12, 2012 at 12:25 PM, Tomi Valkeinen <tomi.valkeinen@ti.com> wrote:
>> This series changes omapfb to use standard dma_alloc funcs instead of omap
>> specific vram allocator. This let's us remove the omap vram allocator, making
>> omapfb platform independent.
>>
>> However, note that using standard dma funcs causes the following downsides:
>>
>> ...
>>
>> 3) OMAPFB_GET_VRAM_INFO ioctl cannot return real values anymore. I
>> changed the ioctl to return 64M for all the values, which, I hope, the
>> applications will interpret as "there's enough vram".
>
> Do at least OMAPFB_QUERY_MEM/OMAPFB_SETUP_MEM still work?
>
>> 4) "vram" kernel parameter to define how much ram to reserve for video use no
>> longer works. The user needs to enable CMA and use "cma" parameter.
>
> That's a significant change, you should update Documentation/ .
I've added the following documentation change:
diff --git a/Documentation/arm/OMAP/DSS b/Documentation/arm/OMAP/DSS
index a564cee..4484e02 100644
--- a/Documentation/arm/OMAP/DSS
+++ b/Documentation/arm/OMAP/DSS
@@ -285,7 +285,10 @@ FB0 +-- GFX ---- LCD ---- LCD
Misc notes
----------
-OMAP FB allocates the framebuffer memory using the OMAP VRAM allocator.
+OMAP FB allocates the framebuffer memory using the standard dma allocator. You
+can enable Contiguous Memory Allocator (CONFIG_CMA) to improve the dma
+allocator, and if CMA is enabled, you use "cma=" kernel parameter to increase
+the global memory area for CMA.
Using DSI DPLL to generate pixel clock it is possible produce the pixel clock
of 86.5MHz (max possible), and with that you get 1280x1024@57 output from DVI.
@@ -301,11 +304,6 @@ framebuffer parameters.
Kernel boot arguments
---------------------
-vram=<size>[,<physaddr>]
- - Amount of total VRAM to preallocate and optionally a physical start
- memory address. For example, "10M". omapfb allocates memory for
- framebuffers from VRAM.
-
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 897 bytes --]
^ permalink raw reply related [flat|nested] 17+ messages in thread
* Re: [PATCH 0/5] OMAPFB: use dma_alloc instead of omap's vram
2012-11-12 10:25 [PATCH 0/5] OMAPFB: use dma_alloc instead of omap's vram Tomi Valkeinen
` (5 preceding siblings ...)
2012-11-12 13:39 ` [PATCH 0/5] OMAPFB: use dma_alloc instead of omap's vram Grazvydas Ignotas
@ 2012-11-12 22:50 ` Tony Lindgren
2012-11-16 7:15 ` Tomi Valkeinen
2012-11-16 9:06 ` Tomi Valkeinen
6 siblings, 2 replies; 17+ messages in thread
From: Tony Lindgren @ 2012-11-12 22:50 UTC (permalink / raw)
To: linux-arm-kernel
* Tomi Valkeinen <tomi.valkeinen@ti.com> [121112 02:27]:
> Hi,
>
> This series changes omapfb to use standard dma_alloc funcs instead of omap
> specific vram allocator. This let's us remove the omap vram allocator, making
> omapfb platform independent.
>
> However, note that using standard dma funcs causes the following downsides:
>
> 1) dma_alloc_attrs doesn't let us allocate at certain physical address.
> However, this should not be a problem as this feature of vram allocator
> is only used when reserving the framebuffer that was initialized by the
> bootloader, and we don't currently support "passing" a framebuffer from
> the bootloader to the kernel anyway.
>
> 2) dma_alloc_attrs, as of now, always ioremaps the allocated area, and
> we don't need the ioremap when using VRFB. This patch uses
> DMA_ATTR_NO_KERNEL_MAPPING for the allocation, but the flag is currently
> not operational.
>
> 3) OMAPFB_GET_VRAM_INFO ioctl cannot return real values anymore. I
> changed the ioctl to return 64M for all the values, which, I hope, the
> applications will interpret as "there's enough vram".
>
> 4) "vram" kernel parameter to define how much ram to reserve for video use no
> longer works. The user needs to enable CMA and use "cma" parameter.
Great, thanks for fixing these. Could you please queue these into
a separate branch against v3.7-rc5 that I can also merge into
omap-for-v3.8/cleanup-headers-prepare-multiplatform-v3?
Feel free to add my Acked-by: Tony Lindgren <tony@atomide.com> to the
arch/arm/*omap*/* parts.
Regards,
Tony
^ permalink raw reply [flat|nested] 17+ messages in thread* Re: [PATCH 0/5] OMAPFB: use dma_alloc instead of omap's vram
2012-11-12 22:50 ` Tony Lindgren
@ 2012-11-16 7:15 ` Tomi Valkeinen
2012-11-20 22:14 ` Tony Lindgren
2012-11-16 9:06 ` Tomi Valkeinen
1 sibling, 1 reply; 17+ messages in thread
From: Tomi Valkeinen @ 2012-11-16 7:15 UTC (permalink / raw)
To: linux-arm-kernel
[-- Attachment #1: Type: text/plain, Size: 1828 bytes --]
On 2012-11-13 00:50, Tony Lindgren wrote:
> * Tomi Valkeinen <tomi.valkeinen@ti.com> [121112 02:27]:
>> Hi,
>>
>> This series changes omapfb to use standard dma_alloc funcs instead of omap
>> specific vram allocator. This let's us remove the omap vram allocator, making
>> omapfb platform independent.
>>
>> However, note that using standard dma funcs causes the following downsides:
>>
>> 1) dma_alloc_attrs doesn't let us allocate at certain physical address.
>> However, this should not be a problem as this feature of vram allocator
>> is only used when reserving the framebuffer that was initialized by the
>> bootloader, and we don't currently support "passing" a framebuffer from
>> the bootloader to the kernel anyway.
>>
>> 2) dma_alloc_attrs, as of now, always ioremaps the allocated area, and
>> we don't need the ioremap when using VRFB. This patch uses
>> DMA_ATTR_NO_KERNEL_MAPPING for the allocation, but the flag is currently
>> not operational.
>>
>> 3) OMAPFB_GET_VRAM_INFO ioctl cannot return real values anymore. I
>> changed the ioctl to return 64M for all the values, which, I hope, the
>> applications will interpret as "there's enough vram".
>>
>> 4) "vram" kernel parameter to define how much ram to reserve for video use no
>> longer works. The user needs to enable CMA and use "cma" parameter.
>
> Great, thanks for fixing these. Could you please queue these into
> a separate branch against v3.7-rc5 that I can also merge into
> omap-for-v3.8/cleanup-headers-prepare-multiplatform-v3?
>
> Feel free to add my Acked-by: Tony Lindgren <tony@atomide.com> to the
> arch/arm/*omap*/* parts.
I added your acks, and pushed:
git://gitorious.org/linux-omap-dss2/linux.git 3.8/vram-conversion
It's based on -rc4 as my other branches are based on that.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 897 bytes --]
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH 0/5] OMAPFB: use dma_alloc instead of omap's vram
2012-11-16 7:15 ` Tomi Valkeinen
@ 2012-11-20 22:14 ` Tony Lindgren
2012-11-21 14:22 ` Jello huang
0 siblings, 1 reply; 17+ messages in thread
From: Tony Lindgren @ 2012-11-20 22:14 UTC (permalink / raw)
To: linux-arm-kernel
* Tomi Valkeinen <tomi.valkeinen@ti.com> [121115 23:17]:
>
> I added your acks, and pushed:
>
> git://gitorious.org/linux-omap-dss2/linux.git 3.8/vram-conversion
>
> It's based on -rc4 as my other branches are based on that.
OK thanks!
Tony
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH 0/5] OMAPFB: use dma_alloc instead of omap's vram
2012-11-20 22:14 ` Tony Lindgren
@ 2012-11-21 14:22 ` Jello huang
2012-11-22 13:52 ` Tomi Valkeinen
0 siblings, 1 reply; 17+ messages in thread
From: Jello huang @ 2012-11-21 14:22 UTC (permalink / raw)
To: linux-arm-kernel
HI Tomi,
we need one rank of cma to allocate the memory for driver in kernel
space .And the default CMA is for allocating memory frome usespace.So
if we allocate the memory from the
default CMA zone ,there maybe introduce fragmention to the default CMA
zone.The kernel space memory donot touch the memory from userspace
Jello Huang
On 21/11/2012, Tony Lindgren <tony@atomide.com> wrote:
> * Tomi Valkeinen <tomi.valkeinen@ti.com> [121115 23:17]:
>>
>> I added your acks, and pushed:
>>
>> git://gitorious.org/linux-omap-dss2/linux.git 3.8/vram-conversion
>>
>> It's based on -rc4 as my other branches are based on that.
>
> OK thanks!
>
> Tony
> --
> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
--
Thanks
Jello Huang
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH 0/5] OMAPFB: use dma_alloc instead of omap's vram
2012-11-12 22:50 ` Tony Lindgren
2012-11-16 7:15 ` Tomi Valkeinen
@ 2012-11-16 9:06 ` Tomi Valkeinen
2012-11-19 22:04 ` Tony Lindgren
1 sibling, 1 reply; 17+ messages in thread
From: Tomi Valkeinen @ 2012-11-16 9:06 UTC (permalink / raw)
To: linux-arm-kernel
[-- Attachment #1: Type: text/plain, Size: 1826 bytes --]
Hi Tony,
On 2012-11-13 00:50, Tony Lindgren wrote:
> * Tomi Valkeinen <tomi.valkeinen@ti.com> [121112 02:27]:
>> Hi,
>>
>> This series changes omapfb to use standard dma_alloc funcs instead of omap
>> specific vram allocator. This let's us remove the omap vram allocator, making
>> omapfb platform independent.
>>
>> However, note that using standard dma funcs causes the following downsides:
>>
>> 1) dma_alloc_attrs doesn't let us allocate at certain physical address.
>> However, this should not be a problem as this feature of vram allocator
>> is only used when reserving the framebuffer that was initialized by the
>> bootloader, and we don't currently support "passing" a framebuffer from
>> the bootloader to the kernel anyway.
>>
>> 2) dma_alloc_attrs, as of now, always ioremaps the allocated area, and
>> we don't need the ioremap when using VRFB. This patch uses
>> DMA_ATTR_NO_KERNEL_MAPPING for the allocation, but the flag is currently
>> not operational.
>>
>> 3) OMAPFB_GET_VRAM_INFO ioctl cannot return real values anymore. I
>> changed the ioctl to return 64M for all the values, which, I hope, the
>> applications will interpret as "there's enough vram".
>>
>> 4) "vram" kernel parameter to define how much ram to reserve for video use no
>> longer works. The user needs to enable CMA and use "cma" parameter.
>
> Great, thanks for fixing these. Could you please queue these into
> a separate branch against v3.7-rc5 that I can also merge into
> omap-for-v3.8/cleanup-headers-prepare-multiplatform-v3?
Should we enable CMA by default in omap2plus_defconfig? And perhaps on
omap1 also?
I have to say I don't know the details of the dma allocation, but afaik
there are no drawbacks with CMA. Although it is still marked
EXPERIMENTAL in the kconfig...
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 897 bytes --]
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH 0/5] OMAPFB: use dma_alloc instead of omap's vram
2012-11-16 9:06 ` Tomi Valkeinen
@ 2012-11-19 22:04 ` Tony Lindgren
2012-11-20 15:09 ` Tomi Valkeinen
0 siblings, 1 reply; 17+ messages in thread
From: Tony Lindgren @ 2012-11-19 22:04 UTC (permalink / raw)
To: linux-arm-kernel
* Tomi Valkeinen <tomi.valkeinen@ti.com> [121116 01:08]:
> Hi Tony,
>
> On 2012-11-13 00:50, Tony Lindgren wrote:
> > * Tomi Valkeinen <tomi.valkeinen@ti.com> [121112 02:27]:
> >> Hi,
> >>
> >> This series changes omapfb to use standard dma_alloc funcs instead of omap
> >> specific vram allocator. This let's us remove the omap vram allocator, making
> >> omapfb platform independent.
> >>
> >> However, note that using standard dma funcs causes the following downsides:
> >>
> >> 1) dma_alloc_attrs doesn't let us allocate at certain physical address.
> >> However, this should not be a problem as this feature of vram allocator
> >> is only used when reserving the framebuffer that was initialized by the
> >> bootloader, and we don't currently support "passing" a framebuffer from
> >> the bootloader to the kernel anyway.
> >>
> >> 2) dma_alloc_attrs, as of now, always ioremaps the allocated area, and
> >> we don't need the ioremap when using VRFB. This patch uses
> >> DMA_ATTR_NO_KERNEL_MAPPING for the allocation, but the flag is currently
> >> not operational.
> >>
> >> 3) OMAPFB_GET_VRAM_INFO ioctl cannot return real values anymore. I
> >> changed the ioctl to return 64M for all the values, which, I hope, the
> >> applications will interpret as "there's enough vram".
> >>
> >> 4) "vram" kernel parameter to define how much ram to reserve for video use no
> >> longer works. The user needs to enable CMA and use "cma" parameter.
> >
> > Great, thanks for fixing these. Could you please queue these into
> > a separate branch against v3.7-rc5 that I can also merge into
> > omap-for-v3.8/cleanup-headers-prepare-multiplatform-v3?
>
> Should we enable CMA by default in omap2plus_defconfig? And perhaps on
> omap1 also?
Yes if that's now needed for DSS.
> I have to say I don't know the details of the dma allocation, but afaik
> there are no drawbacks with CMA. Although it is still marked
> EXPERIMENTAL in the kconfig...
I guess that's still fine as that's what we're supposed to use :)
Regards,
Tony
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH 0/5] OMAPFB: use dma_alloc instead of omap's vram
2012-11-19 22:04 ` Tony Lindgren
@ 2012-11-20 15:09 ` Tomi Valkeinen
0 siblings, 0 replies; 17+ messages in thread
From: Tomi Valkeinen @ 2012-11-20 15:09 UTC (permalink / raw)
To: linux-arm-kernel
[-- Attachment #1: Type: text/plain, Size: 833 bytes --]
On 2012-11-20 00:04, Tony Lindgren wrote:
>> Should we enable CMA by default in omap2plus_defconfig? And perhaps on
>> omap1 also?
>
> Yes if that's now needed for DSS.
DSS works fine without CMA, at least for small displays, and when fb
allocation is done at boot time. So it's not a strict "need".
I'm not sure how easily FB allocations start to fail without CMA, and
how much CMA helps.
I'm not even sure what's the default DMA pool size on OMAP... If it's
the one set with "coherent_pool" kernel parameter, then the default
seems to be 256K, which is quite small for video use. For CMA the
default global area is 16M. Both can, of course, be changed with boot
params or kernel config (at least for CMA).
But I think it makes sense to have CMA by default even if non-CMA kernel
would work.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 897 bytes --]
^ permalink raw reply [flat|nested] 17+ messages in thread