omapfb: option to use coherent dma mem
Subsystems (4)
cover omapfb: option to use coherent dma mem
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(-)
Signature · 1 line
1.8.3.2
PATCH 1/2 ARM: omapfb: add coherent dma memory support
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.
--- 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(-)
arch/arm/mach-omap2/common.c +1 -0
@@ -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 (); }
arch/arm/mach-omap2/common.h +2 -0
@@ -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 );
arch/arm/mach-omap2/fb.c +76 -1
95 lines not on this page · raw message
Signature · 1 line
1.8.3.2
PATCH 1/2 ARM: omapfb: add coherent dma memory support
Quoted 15 lines · Tomi Valkeinen
The omapfb driver uses
dma_allocto 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. Thedma_allocfunction will first try to allocate the fb from the coherent memory area, and if that fails, it'll use the normal method of allocation.
Quoted 8 lines
Signed-off-by Tomi Valkeinen <[email protected]>Cc Ivaylo Dimitrov <[email protected]>--- 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
Tony Lindgren
maintainerPATCH 1/2 ARM: omapfb: add coherent dma memory support
In reply to Tomi ValkeinenQuoted 10 lines · Tomi Valkeinen
The omapfb driver uses
dma_allocto 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.
Quoted 7 lines
The memory area is reserved with memblock, and assigned to omapfb with
dma_declare_coherent_memory. Thedma_allocfunction 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 <[email protected]>Cc Ivaylo Dimitrov <[email protected]>
Feel free to queue this along with the DSS patches:
PATCH 1/2 ARM: omapfb: add coherent dma memory support
Quoted 16 lines · Tony Lindgren
Quoted 15 lines · Tomi Valkeinen
The omapfb driver uses
dma_allocto 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. Thedma_allocfunction will first try to allocate the fb from the coherent memory area, and if that fails, it'll use the normal method of allocation.
Quoted 6 lines
Quoted 2 lines
Signed-off-by Tomi Valkeinen <[email protected]>Cc Ivaylo Dimitrov <[email protected]>Feel free to queue this along with the DSS patches:
Acked-by Tony Lindgren <[email protected]>
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>
PATCH 1/2 ARM: omapfb: add coherent dma memory support
Quoted 31 lines
-----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 supportQuoted 10 lines · Tony Lindgren
Quoted 9 lines · Tomi Valkeinen
The omapfb driver uses
dma_allocto 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 isreserved.
Quoted 11 lines
Quoted 8 lines
The memory area is reserved with memblock, and assigned to omapfb with
dma_declare_coherent_memory. Thedma_allocfunction 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 <[email protected]>Cc Ivaylo Dimitrov <[email protected]>Feel free to queue this along with the DSS patches:
Quoted 9 lines
Quoted 1 line
Acked-by Tony Lindgren <[email protected]>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
Quoted 2 lines
Tomi
PATCH 1/2 ARM: omapfb: add coherent dma memory support
Quoted 10 lines · Vaibhav
Tomi,
I am seeing underflow issue on AM43x device if I use
omapfb_vramargument. 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
PATCH 1/2 ARM: omapfb: add coherent dma memory support
Quoted 19 lines
-----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 supportQuoted 6 lines · Vaibhav
Tomi,
I am seeing underflow issue on AM43x device if I use
omapfb_vramargument. Did you see this on OMAP?I am using "omapfb_vram=10M at
0xA0000000", and I believe it is correct wayof usage.
Quoted 1 line
Quoted 9 lines
Quoted 3 lines
Thanks,
VaibhavAFAIK 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.
Quoted 5 lines
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
Quoted 6 lines · Vaibhav
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:
Quoted 6 lines
[ 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>
PATCH 1/2 ARM: omapfb: add coherent dma memory support
Quoted 24 lines
-----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 supportQuoted 2 lines · Vaibhav
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.
Quoted 10 lines
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
Quoted 5 lines
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.
Quoted 5 lines
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
In reply to Hiremath, VaibhavQuoted 6 lines · Vaibhav
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: 61696free_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
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
Ivo
PATCH 1/2 ARM: omapfb: add coherent dma memory support
Quoted 10 lines
-----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
Quoted 2 lines
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
In reply to Ivaylo DimitrovQuoted 1 line · Ivaylo Dimitrov
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>
PATCH 1/2 ARM: omapfb: add coherent dma memory support
In reply to Hiremath, VaibhavQuoted 4 lines · Vaibhav
I am seeing underflow issue on AM43x device if I use
omapfb_vramargument. 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>
PATCH 1/2 ARM: omapfb: add coherent dma memory support
Quoted 29 lines
-----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 supportQuoted 4 lines · Vaibhav
I am seeing underflow issue on AM43x device if I use
omapfb_vramargument. Did you see this on OMAP?I am using "omapfb_vram=10M at
0xA0000000", and I believe it is correct wayof 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 passesDMA_ATTR_WRITE_COMBINEas 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).
Quoted 8 lines
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_allocand 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
In reply to Tomi ValkeinenQuoted 46 lines
-----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 supportQuoted 11 lines
-----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 supportQuoted 1 line · Vaibhav
I am seeing underflow issue on AM43x device if I use
omapfb_vramargument.
Quoted 23 lines
Quoted 4 lines
Did you see this on OMAP?
I am using "omapfb_vram=10M at
0xA0000000", and I believe it is correct wayof 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 passesDMA_ATTR_WRITE_COMBINEas 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...
Quoted 7 lines
Quoted 4 lines
Vaibhav, just to be sure, can you run both with normal
dma_allocand 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:~#
PATCH 2/2 omapfb: add support to reserve fb at specified phys address
In reply to Tomi ValkeinenThe 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.
--- drivers/video/omap2/omapfb/omapfb-main.c | 36 ++++++++++++++++++++++++-------- drivers/video/omap2/omapfb/omapfb.h | 1 + 2 files changed, 28 insertions(+), 9 deletions(-)
drivers/video/omap2/omapfb/omapfb-main.c +27 -9
@@ -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); }
drivers/video/omap2/omapfb/omapfb.h +1 -0
@@ -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 */
Signature · 1 line
1.8.3.2