RE: [PATCH 1/2] ARM: omapfb: add coherent dma memory support
-Original Message- From: Ivaylo Dimitrov [mailto:ivo.g.dimitrov...@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-ker...@lists.infradead.org; linux- fb...@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 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] ARM: omapfb: add coherent dma memory support
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 signature.asc Description: OpenPGP digital signature
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 Ivo -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] ARM: omapfb: add coherent dma memory support
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 0x0080 bytes at 0x8f10 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@0x8F10 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 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: RE: [PATCH 1/2] ARM: omapfb: add coherent dma memory support
-Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- ow...@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-ker...@lists.infradead.org; linux- fb...@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@0xA000, 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@0xA000 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 a000, vaddr ca00 [1.451069] OMAPFB: region0 phys a000 virt ca00 size=1536000 [1.451086] OMAPFB: region1 phys virt (null) size=0 [1.451100] OMAPFB: region2 phys 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 a000 [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 a000 [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 a000, 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 a000 [ 20.544798] OMAPFB: pan_display(0) [ 20.544802] OMAPFB: setcmap [ 20.544859] OMAPFB: pan_display(0) [ 20.544865] OMAPFB: setcmap [ 20.544872
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@0xA000, 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 signature.asc Description: OpenPGP digital signature
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 a000, 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 signature.asc Description: OpenPGP digital signature
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- ker...@lists.infradead.org; linux-fb...@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@0xA000, 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 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 1/2] ARM: omapfb: add coherent dma memory support
-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- ker...@lists.infradead.org; linux-fb...@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 a000, 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 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 1/2] ARM: omapfb: add coherent dma memory support
-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- ker...@lists.infradead.org; linux-fb...@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- ker...@lists.infradead.org; linux-fb...@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@0xA000, 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_REVISION0020 DSS_SYSCONFIG 0001 DSS_SYSSTATUS 0001 DSS_CONTROL 0018 root@am43xx-epos-evm:~# root@am43xx-epos-evm:~# cat /sys/kernel/debug/omapdss/clk - DSS - DSS_FCK (DSS_FCLK1) = 19800 - DISPC - dispc fclk source = DSS_FCK (DSS_FCLK1) fck 19800 - LCD - LCD clk source = DSS_FCK (DSS_FCLK1) lck 19800 lck div 1 pck 3300pck 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_ODD1 ACBIAS_COUNT_STAT 0 PROG_LINE_NUM 1 GFX_FIFO_UNDERFLOW0 GFX_END_WIN 1 PAL_GAMMA_MASK0 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 WAKEUP0 root@am43xx-epos-evm:~# root@am43xx-epos-evm:~# cat /sys/kernel/debug/omapdss/dispc DISPC_REVISION 0030 DISPC_SYSCONFIG2011 DISPC_SYSSTATUS0001 DISPC_IRQSTATUS00ae DISPC_IRQENABLEd640 DISPC_CONTROL 00018309 DISPC_CONFIG 0204 DISPC_CAPABLE 03ff DISPC_LINE_STATUS 00b1 DISPC_LINE_NUMBER DISPC_GLOBAL_ALPHA 00ff DISPC_DEFAULT_COLOR(LCD) DISPC_TRANS_COLOR(LCD) DISPC_SIZE_MGR(LCD)01df031f DISPC_DEFAULT_COLOR(LCD) DISPC_TRANS_COLOR(LCD) DISPC_TIMING_H(LCD)00f0d11d DISPC_TIMING_V(LCD)00a0160c DISPC_POL_FREQ(LCD)3000 DISPC_DIVISORo(LCD)00010006 DISPC_SIZE_MGR(LCD)01df031f DISPC_DATA_CYCLE1(LCD
Re: [PATCH 1/2] ARM: omapfb: add coherent dma memory support
On 2014-01-08 01:59, Tony Lindgren wrote: * Tomi Valkeinen tomi.valkei...@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.valkei...@ti.com Cc: Ivaylo Dimitrov freemangor...@abv.bg Feel free to queue this along with the DSS patches: Acked-by: Tony Lindgren t...@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 signature.asc Description: OpenPGP digital signature
RE: [PATCH 1/2] ARM: omapfb: add coherent dma memory support
-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- ker...@lists.infradead.org; linux-fb...@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.valkei...@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.valkei...@ti.com Cc: Ivaylo Dimitrov freemangor...@abv.bg Feel free to queue this along with the DSS patches: Acked-by: Tony Lindgren t...@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@0xA000, and I believe it is correct way of usage. Thanks, Vaibhav Tomi -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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@0xA000, 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 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] ARM: omapfb: add coherent dma memory support
* Tomi Valkeinen tomi.valkei...@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.valkei...@ti.com Cc: Ivaylo Dimitrov freemangor...@abv.bg Feel free to queue this along with the DSS patches: Acked-by: Tony Lindgren t...@atomide.com -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] ARM: omapfb: add coherent dma memory support
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.valkei...@ti.com Cc: Ivaylo Dimitrov freemangor...@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 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
