| Message ID | 1388409550-10720-2-git-send-email-tomi.valkeinen@ti.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On 30.12.2013 15:19, Tomi Valkeinen wrote: > The omapfb driver uses dma_alloc to reserve memory for the framebuffers. > However, on some use cases, even when CMA is in use, it's quite probable > that omapfb fails to allocate the fb, either due to not enough free dma > memory, fragmented dma memory, or CMA failing to make enough contiguous > space. > > This patch adds a kernel cmdline parameter 'omapfb_vram' which can be > used to give the size of a memory area reserved exclusively for omapfb, > and optionally a physical address where the memory area is reserved. > > The memory area is reserved with memblock, and assigned to omapfb with > dma_declare_coherent_memory. The dma_alloc function will first try to > allocate the fb from the coherent memory area, and if that fails, it'll > use the normal method of allocation. > > Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com> > Cc: Ivaylo Dimitrov <freemangordon@abv.bg> > --- > arch/arm/mach-omap2/common.c | 1 + > arch/arm/mach-omap2/common.h | 2 ++ > arch/arm/mach-omap2/fb.c | 77 +++++++++++++++++++++++++++++++++++++++++++- > 3 files changed, 79 insertions(+), 1 deletion(-) > Tested on Nokia N900 with Maemo5 and linux 3.13-rc6 -- To unsubscribe from this list: send the line "unsubscribe linux-fbdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
* Tomi Valkeinen <tomi.valkeinen@ti.com> [131230 05:21]: > The omapfb driver uses dma_alloc to reserve memory for the framebuffers. > However, on some use cases, even when CMA is in use, it's quite probable > that omapfb fails to allocate the fb, either due to not enough free dma > memory, fragmented dma memory, or CMA failing to make enough contiguous > space. > > This patch adds a kernel cmdline parameter 'omapfb_vram' which can be > used to give the size of a memory area reserved exclusively for omapfb, > and optionally a physical address where the memory area is reserved. > > The memory area is reserved with memblock, and assigned to omapfb with > dma_declare_coherent_memory. The dma_alloc function will first try to > allocate the fb from the coherent memory area, and if that fails, it'll > use the normal method of allocation. > > Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com> > Cc: Ivaylo Dimitrov <freemangordon@abv.bg> Feel free to queue this along with the DSS patches: Acked-by: Tony Lindgren <tony@atomide.com> -- To unsubscribe from this list: send the line "unsubscribe linux-fbdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 2014-01-08 01:59, Tony Lindgren wrote: > * Tomi Valkeinen <tomi.valkeinen@ti.com> [131230 05:21]: >> The omapfb driver uses dma_alloc to reserve memory for the framebuffers. >> However, on some use cases, even when CMA is in use, it's quite probable >> that omapfb fails to allocate the fb, either due to not enough free dma >> memory, fragmented dma memory, or CMA failing to make enough contiguous >> space. >> >> This patch adds a kernel cmdline parameter 'omapfb_vram' which can be >> used to give the size of a memory area reserved exclusively for omapfb, >> and optionally a physical address where the memory area is reserved. >> >> The memory area is reserved with memblock, and assigned to omapfb with >> dma_declare_coherent_memory. The dma_alloc function will first try to >> allocate the fb from the coherent memory area, and if that fails, it'll >> use the normal method of allocation. >> >> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com> >> Cc: Ivaylo Dimitrov <freemangordon@abv.bg> > > Feel free to queue this along with the DSS patches: > > Acked-by: Tony Lindgren <tony@atomide.com> Thanks. This introduces new kernel boot parameter, and I haven't really had time to test and think about this. If Ivaylo doesn't insist on this to be merged for 3.14, I'd rather leave this for 3.15 as adding new parameter that we need to support "forever" should be thought a bit more. Tomi
> -----Original Message----- > From: Valkeinen, Tomi > Sent: Wednesday, January 08, 2014 7:44 PM > To: Tony Lindgren; Ivaylo Dimitrov > Cc: Hiremath, Vaibhav; linux-omap@vger.kernel.org; linux-arm- > kernel@lists.infradead.org; linux-fbdev@vger.kernel.org > Subject: Re: [PATCH 1/2] ARM: omapfb: add coherent dma memory support > > On 2014-01-08 01:59, Tony Lindgren wrote: > > * Tomi Valkeinen <tomi.valkeinen@ti.com> [131230 05:21]: > >> The omapfb driver uses dma_alloc to reserve memory for the framebuffers. > >> However, on some use cases, even when CMA is in use, it's quite > >> probable that omapfb fails to allocate the fb, either due to not > >> enough free dma memory, fragmented dma memory, or CMA failing to make > >> enough contiguous space. > >> > >> This patch adds a kernel cmdline parameter 'omapfb_vram' which can be > >> used to give the size of a memory area reserved exclusively for > >> omapfb, and optionally a physical address where the memory area is > reserved. > >> > >> The memory area is reserved with memblock, and assigned to omapfb > >> with dma_declare_coherent_memory. The dma_alloc function will first > >> try to allocate the fb from the coherent memory area, and if that > >> fails, it'll use the normal method of allocation. > >> > >> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com> > >> Cc: Ivaylo Dimitrov <freemangordon@abv.bg> > > > > Feel free to queue this along with the DSS patches: > > > > Acked-by: Tony Lindgren <tony@atomide.com> > > Thanks. > > This introduces new kernel boot parameter, and I haven't really had time to test > and think about this. If Ivaylo doesn't insist on this to be merged for 3.14, I'd > rather leave this for 3.15 as adding new parameter that we need to support > "forever" should be thought a bit more. > Tomi, I am seeing underflow issue on AM43x device if I use omapfb_vram argument. Did you see this on OMAP? I am using "omapfb_vram=10M@0xA0000000", and I believe it is correct way of usage. Thanks, Vaibhav > Tomi > -- To unsubscribe from this list: send the line "unsubscribe linux-fbdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 09.01.2014 07:06, Hiremath, Vaibhav wrote: > Tomi, > > I am seeing underflow issue on AM43x device if I use omapfb_vram argument. > Did you see this on OMAP? > > I am using "omapfb_vram=10M@0xA0000000", and I believe it is correct way of usage. > > Thanks, > Vaibhav > AFAIK underflow interrupts could come from badly calculated DSS core clock or bad HW resizer setup and should be unrelated to the memory allocation. It might be something similar to the problem I have on N900 - see https://lkml.org/lkml/2014/1/6/173 Is it possible to upload the video you have problems with, so me to test it on N900? So far I didn't see any underflow issues on it (N900 is OMAP3, in case you're not aware), no matter the resolution of the videos I played(up to 720p), however I didn't test the part that allocates the memory on a pre-defined address. Though I don't think that should matter. Ivo -- To unsubscribe from this list: send the line "unsubscribe linux-fbdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
> -----Original Message----- > From: linux-omap-owner@vger.kernel.org [mailto:linux-omap- > owner@vger.kernel.org] On Behalf Of Ivaylo Dimitrov > Sent: Thursday, January 09, 2014 1:05 PM > To: Hiremath, Vaibhav; Valkeinen, Tomi; Tony Lindgren; Ivaylo Dimitrov > Cc: linux-omap@vger.kernel.org; linux-arm-kernel@lists.infradead.org; linux- > fbdev@vger.kernel.org > Subject: Re: RE: [PATCH 1/2] ARM: omapfb: add coherent dma memory support > > > On 09.01.2014 07:06, Hiremath, Vaibhav wrote: > > Tomi, > > > > I am seeing underflow issue on AM43x device if I use omapfb_vram argument. > > Did you see this on OMAP? > > > > I am using "omapfb_vram=10M@0xA0000000", and I believe it is correct way > of usage. > > > > Thanks, > > Vaibhav > > > > AFAIK underflow interrupts could come from badly calculated DSS core clock or > bad HW resizer setup and should be unrelated to the memory allocation. It > might be something similar to the problem I have on N900 > - see https://lkml.org/lkml/2014/1/6/173 > I can see the difference when I really "omapfb_vram" command line argument. Without omapfb_vram in bootargs ------------------------------------------- bootargs=console=ttyO0,115200n8 root=/dev/mmcblk0p2 rw rootfstype=ext3 rootwait mem=128M consoleblank=0 clocksource=gp_timer consoleblank=0 earlyprintk omapfb.debug=y omapdss.debug=y I do not get UNDERFLOW during boot. With omapfb_vram in the bootargs --------------------------------------------- bootargs=console=ttyO0,115200n8 root=/dev/mmcblk0p2 rw rootfstype=ext3 rootwait mem=128M consoleblank=0 clocksource=gp_timer consoleblank=0 earlyprintk omapfb_vram=10M@0xA0000000 omapfb.debug=y omapdss.debug=y I always get UNDERFLOW during boot itself. > Is it possible to upload the video you have problems with, so me to test it on > N900? So far I didn't see any underflow issues on it (N900 is OMAP3, in case > you're not aware), no matter the resolution of the videos I played(up to 720p), > however I didn't test the part that allocates the memory on a pre-defined > address. Though I don't think that should matter. No, that's what is causing issue to me. Can you try predefined address flow? Just to highlight, I get UNDERFLOW during boot itself, immediately when it gets mapped to userspace. Boot LOG: [ 1.443021] OMAPFB: omapfb_probe [ 1.446137] OMAPFB: create 3 framebuffers [ 1.446178] OMAPFB: fb_infos allocated [ 1.446198] OMAPFB: allocating 1536000 bytes for fb 0 [ 1.451044] OMAPFB: allocated VRAM paddr a0000000, vaddr ca000000 [ 1.451069] OMAPFB: region0 phys a0000000 virt ca000000 size=1536000 [ 1.451086] OMAPFB: region1 phys 00000000 virt (null) size=0 [ 1.451100] OMAPFB: region2 phys 00000000 virt (null) size=0 [ 1.451109] OMAPFB: fbmems allocated [ 1.451363] OMAPFB: check_fb_var 0 [ 1.451386] OMAPFB: max frame size 1536000, line size 3200 [ 1.451401] OMAPFB: xres = 800, yres = 480, vxres = 800, vyres = 480 [ 1.451414] OMAPFB: set_fb_fix [ 1.460278] OMAPFB: fb_infos initialized [ 1.465325] OMAPFB: set_par(0) [ 1.465384] OMAPFB: set_fb_fix [ 1.465393] OMAPFB: apply_changes, fb 0, ovl 0 [ 1.465443] OMAPFB: setup_overlay 0, posx 0, posy 0, outw 800, outh 480 [ 1.465450] OMAPFB: paddr a0000000 [ 1.465592] OMAPFB: pan_display(0) [ 1.465600] OMAPFB: setcmap [ 1.465607] OMAPFB: setcmap [ 1.474504] Console: switching to colour frame buffer device 100x30 [ 1.474528] OMAPFB: pan_display(0) [ 1.474534] OMAPFB: setcmap [ 1.482185] OMAPFB: setcmap [ 1.484808] OMAPFB: framebuffers registered [ 1.484839] OMAPFB: apply_changes, fb 0, ovl 0 [ 1.484857] OMAPFB: setup_overlay 0, posx 0, posy 0, outw 800, outh 480 [ 1.484870] OMAPFB: paddr a0000000 [ 1.484919] OMAPFB: apply_changes, fb 1, ovl 1 [ 1.485010] OMAPFB: apply_changes, fb 2, ovl 2 [ 1.485111] OMAPFB: create_framebuffers done [ 1.485128] OMAPFB: mgr->apply'ed [ 1.489793] OMAPFB: create sysfs for fbs [ 1.489816] OMAPFB: create sysfs for fbs .... [ 4.822549] Freeing unused kernel memory: 440K (c0919000 - c0987000) [ 5.276615] OMAPFB: pan_display(0) [ 5.276625] OMAPFB: setcmap [ 5.276635] OMAPFB: setcmap [ 5.293518] OMAPFB: user mmap region start a0000000, len 1536000, off 0 [ 5.300171] omapdss APPLY error: FIFO UNDERFLOW on gfx, disabling the overlay ... [ 20.499076] OMAPFB: pan_display(0) [ 20.499085] OMAPFB: setcmap [ 20.499093] OMAPFB: setcmap [ 20.544419] OMAPFB: check_var(0) [ 20.544631] OMAPFB: check_fb_var 0 [ 20.544644] OMAPFB: max frame size 1536000, line size 3200 [ 20.544651] OMAPFB: xres = 800, yres = 480, vxres = 800, vyres = 480 [ 20.544699] OMAPFB: set_par(0) [ 20.544706] OMAPFB: set_fb_fix [ 20.544712] OMAPFB: apply_changes, fb 0, ovl 0 [ 20.544762] OMAPFB: setup_overlay 0, posx 0, posy 0, outw 800, outh 480 [ 20.544767] OMAPFB: paddr a0000000 [ 20.544798] OMAPFB: pan_display(0) [ 20.544802] OMAPFB: setcmap [ 20.544859] OMAPFB: pan_display(0) [ 20.544865] OMAPFB: setcmap [ 20.544872] OMAPFB: setcmap [ 20.553841] OMAPFB: setcmap [ 23.002160] OMAPFB: user mmap region start a0000000, len 1536000, off 0 Thanks, Vaibhav -- To unsubscribe from this list: send the line "unsubscribe linux-fbdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 2014-01-09 07:06, Hiremath, Vaibhav wrote: > I am seeing underflow issue on AM43x device if I use omapfb_vram argument. > Did you see this on OMAP? > > I am using "omapfb_vram=10M@0xA0000000", and I believe it is correct way of usage. Hmm ok... The AM4x seems to have issues anyway, as we're seeing underflows easily in other situations also. Well, there's a small difference in the allocation. The normal dma alloc uses dma_alloc_attrs() and passes DMA_ATTR_WRITE_COMBINE as a flag, whereas allocating from the absolute address just uses the piece of memory. I couldn't find how to set write-combine for the abs memory area. Then again, that's for CPU caching, so I don't see why it would affect DSS as such (but that's still something we should measure, cpu read/write perf for normal and abs allocation). The only thought I have is that somehow the reserved memory area is missing some configuration that is done for the rest of the memory. But that's purely a guess, this is totally out of my area of expertise... Vaibhav, just to be sure, can you run both with normal dma_alloc and with the reserve, and verify that the dispc register dumps are the same? I don't see how they could be different, but just to be sure. Tomi
On 2014-01-09 10:08, Hiremath, Vaibhav wrote: > No, that's what is causing issue to me. Can you try predefined address flow? > Just to highlight, I get UNDERFLOW during boot itself, immediately when it gets mapped to userspace. > > Boot LOG: > > [ 4.822549] Freeing unused kernel memory: 440K (c0919000 - c0987000) > [ 5.276615] OMAPFB: pan_display(0) > [ 5.276625] OMAPFB: setcmap > [ 5.276635] OMAPFB: setcmap > [ 5.293518] OMAPFB: user mmap region start a0000000, len 1536000, off 0 > [ 5.300171] omapdss APPLY error: FIFO UNDERFLOW on gfx, disabling the overlay Hmm that's interesting... So you have some tool that's ran early, which draws something on the screen? Or maybe that's X starting? Ah... I think I understand now. As I mentioned, AM4x has issues already. I think the CPU/others can block DSS when accessing memory. So, if we have bad caching for the mapped framebuffer, the CPU will use more bandwidth when reading/writing to it, and that will cause DSS to underflow. Tomi
> -----Original Message----- > From: Valkeinen, Tomi > Sent: Thursday, January 09, 2014 1:52 PM > To: Hiremath, Vaibhav; Ivaylo Dimitrov > Cc: Tony Lindgren; linux-omap@vger.kernel.org; linux-arm- > kernel@lists.infradead.org; linux-fbdev@vger.kernel.org > Subject: Re: [PATCH 1/2] ARM: omapfb: add coherent dma memory support > > On 2014-01-09 07:06, Hiremath, Vaibhav wrote: > > > I am seeing underflow issue on AM43x device if I use omapfb_vram argument. > > Did you see this on OMAP? > > > > I am using "omapfb_vram=10M@0xA0000000", and I believe it is correct way > of usage. > > Hmm ok... The AM4x seems to have issues anyway, as we're seeing underflows > easily in other situations also. > > Well, there's a small difference in the allocation. The normal dma alloc uses > dma_alloc_attrs() and passes DMA_ATTR_WRITE_COMBINE as a flag, whereas > allocating from the absolute address just uses the piece of memory. I couldn't > find how to set write-combine for the abs memory area. > > Then again, that's for CPU caching, so I don't see why it would affect DSS as > such (but that's still something we should measure, cpu read/write perf for > normal and abs allocation). > > The only thought I have is that somehow the reserved memory area is missing > some configuration that is done for the rest of the memory. But that's purely a > guess, this is totally out of my area of expertise... > > Vaibhav, just to be sure, can you run both with normal dma_alloc and with the > reserve, and verify that the dispc register dumps are the same? > I don't see how they could be different, but just to be sure. > Will check and update you shortly. Thanks, Vaibhav -- To unsubscribe from this list: send the line "unsubscribe linux-fbdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
> -----Original Message----- > From: Valkeinen, Tomi > Sent: Thursday, January 09, 2014 1:57 PM > To: Hiremath, Vaibhav; Ivaylo Dimitrov; Ivaylo Dimitrov > Cc: Tony Lindgren; linux-omap@vger.kernel.org; linux-arm- > kernel@lists.infradead.org; linux-fbdev@vger.kernel.org > Subject: Re: [PATCH 1/2] ARM: omapfb: add coherent dma memory support > > On 2014-01-09 10:08, Hiremath, Vaibhav wrote: > > > No, that's what is causing issue to me. Can you try predefined address flow? > > Just to highlight, I get UNDERFLOW during boot itself, immediately when it > gets mapped to userspace. > > > > Boot LOG: > > > > > [ 4.822549] Freeing unused kernel memory: 440K (c0919000 - c0987000) > > [ 5.276615] OMAPFB: pan_display(0) > > [ 5.276625] OMAPFB: setcmap > > [ 5.276635] OMAPFB: setcmap > > [ 5.293518] OMAPFB: user mmap region start a0000000, len 1536000, off 0 > > [ 5.300171] omapdss APPLY error: FIFO UNDERFLOW on gfx, disabling the > overlay > > Hmm that's interesting... So you have some tool that's ran early, which draws > something on the screen? Or maybe that's X starting? > It's initial demo, not sure whether you heard of MATRIX demo. I am running Matrix demo As part of init script. > Ah... I think I understand now. As I mentioned, AM4x has issues already. > I think the CPU/others can block DSS when accessing memory. So, if we have > bad caching for the mapped framebuffer, the CPU will use more bandwidth > when reading/writing to it, and that will cause DSS to underflow. > Yeah, AM4x already has some issues but I am comparing normal dma_alloc and reserved Memory and I see different behavior and it could be due to bad caching for the mapped buffers. Thanks, Vaibhav -- To unsubscribe from this list: send the line "unsubscribe linux-fbdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
> -----Original Message----- > From: Hiremath, Vaibhav > Sent: Thursday, January 09, 2014 2:01 PM > To: Valkeinen, Tomi; Ivaylo Dimitrov > Cc: Tony Lindgren; linux-omap@vger.kernel.org; linux-arm- > kernel@lists.infradead.org; linux-fbdev@vger.kernel.org > Subject: RE: [PATCH 1/2] ARM: omapfb: add coherent dma memory support > > > > -----Original Message----- > > From: Valkeinen, Tomi > > Sent: Thursday, January 09, 2014 1:52 PM > > To: Hiremath, Vaibhav; Ivaylo Dimitrov > > Cc: Tony Lindgren; linux-omap@vger.kernel.org; linux-arm- > > kernel@lists.infradead.org; linux-fbdev@vger.kernel.org > > Subject: Re: [PATCH 1/2] ARM: omapfb: add coherent dma memory support > > > > On 2014-01-09 07:06, Hiremath, Vaibhav wrote: > > > > > I am seeing underflow issue on AM43x device if I use omapfb_vram > argument. > > > Did you see this on OMAP? > > > > > > I am using "omapfb_vram=10M@0xA0000000", and I believe it is correct > > > way > > of usage. > > > > Hmm ok... The AM4x seems to have issues anyway, as we're seeing > > underflows easily in other situations also. > > > > Well, there's a small difference in the allocation. The normal dma > > alloc uses > > dma_alloc_attrs() and passes DMA_ATTR_WRITE_COMBINE as a flag, whereas > > allocating from the absolute address just uses the piece of memory. I > > couldn't find how to set write-combine for the abs memory area. > > > > Then again, that's for CPU caching, so I don't see why it would affect > > DSS as such (but that's still something we should measure, cpu > > read/write perf for normal and abs allocation). > > > > The only thought I have is that somehow the reserved memory area is > > missing some configuration that is done for the rest of the memory. > > But that's purely a guess, this is totally out of my area of expertise... > > > > Vaibhav, just to be sure, can you run both with normal dma_alloc and > > with the reserve, and verify that the dispc register dumps are the same? > > I don't see how they could be different, but just to be sure. > > > > Will check and update you shortly. > I checked both the DSS configuration in both scenarios and they look same to me. With normal dma_alloc: =================== root@am43xx-epos-evm:~# root@am43xx-epos-evm:~# root@am43xx-epos-evm:~# cat /proc/cmdline console=ttyO0,115200n8 root=/dev/mmcblk0p2 rw rootfstype=ext3 rootwait mem=128M consoleblank=0 clocksource=gp_timer consoleblank=0 earlyprintk root@am43xx-epos-evm:~# root@am43xx-epos-evm:~# root@am43xx-epos-evm:~# root@am43xx-epos-evm:~# cat /sys/kernel/debug/omapdss/dss DSS_REVISION 00000020 DSS_SYSCONFIG 00000001 DSS_SYSSTATUS 00000001 DSS_CONTROL 00000018 root@am43xx-epos-evm:~# root@am43xx-epos-evm:~# cat /sys/kernel/debug/omapdss/clk - DSS - DSS_FCK (DSS_FCLK1) = 198000000 - DISPC - dispc fclk source = DSS_FCK (DSS_FCLK1) fck 198000000 - LCD - LCD clk source = DSS_FCK (DSS_FCLK1) lck 198000000 lck div 1 pck 33000000 pck div 6 root@am43xx-epos-evm:~# root@am43xx-epos-evm:~# cat /sys/kernel/debug/omapdss/dispc_irq period 44780 ms irqs 1 FRAMEDONE 0 VSYNC 1 EVSYNC_EVEN 1 EVSYNC_ODD 1 ACBIAS_COUNT_STAT 0 PROG_LINE_NUM 1 GFX_FIFO_UNDERFLOW 0 GFX_END_WIN 1 PAL_GAMMA_MASK 0 OCP_ERR 0 VID1_FIFO_UNDERFLOW 0 VID1_END_WIN 0 VID2_FIFO_UNDERFLOW 0 VID2_END_WIN 0 SYNC_LOST 0 SYNC_LOST_DIGIT 0 WAKEUP 0 root@am43xx-epos-evm:~# root@am43xx-epos-evm:~# cat /sys/kernel/debug/omapdss/dispc DISPC_REVISION 00000030 DISPC_SYSCONFIG 00002011 DISPC_SYSSTATUS 00000001 DISPC_IRQSTATUS 000000ae DISPC_IRQENABLE 0000d640 DISPC_CONTROL 00018309 DISPC_CONFIG 00000204 DISPC_CAPABLE 000003ff DISPC_LINE_STATUS 000000b1 DISPC_LINE_NUMBER 00000000 DISPC_GLOBAL_ALPHA 000000ff DISPC_DEFAULT_COLOR(LCD) 00000000 DISPC_TRANS_COLOR(LCD) 00000000 DISPC_SIZE_MGR(LCD) 01df031f DISPC_DEFAULT_COLOR(LCD) 00000000 DISPC_TRANS_COLOR(LCD) 00000000 DISPC_TIMING_H(LCD) 00f0d11d DISPC_TIMING_V(LCD) 00a0160c DISPC_POL_FREQ(LCD) 00003000 DISPC_DIVISORo(LCD) 00010006 DISPC_SIZE_MGR(LCD) 01df031f DISPC_DATA_CYCLE1(LCD) 00000000 DISPC_DATA_CYCLE2(LCD) 00000000 DISPC_DATA_CYCLE3(LCD) 00000000 DISPC_CPR_COEF_R(LCD) 00000000 DISPC_CPR_COEF_G(LCD) 00000000 DISPC_CPR_COEF_B(LCD) 00000000 DISPC_OVL_BA0(GFX) 86900000 DISPC_OVL_BA1(GFX) 86900000 DISPC_OVL_POSITION(GFX) 00000000 DISPC_OVL_SIZE(GFX) 01df031f DISPC_OVL_ATTRIBUTES(GFX) 00000091 DISPC_OVL_FIFO_THRESHOLD(GFX) 03ff03c0 DISPC_OVL_FIFO_SIZE_STATUS(GFX) 00000400 DISPC_OVL_ROW_INC(GFX) 00000001 DISPC_OVL_PIXEL_INC(GFX) 00000001 DISPC_OVL_PRELOAD(GFX) 00000100 DISPC_OVL_WINDOW_SKIP(GFX) 00000000 DISPC_OVL_TABLE_BA(GFX) 00000000 DISPC_OVL_BA0(VID1) 00000000 DISPC_OVL_BA1(VID1) 00000000 DISPC_OVL_POSITION(VID1) 00000000 DISPC_OVL_SIZE(VID1) 00000000 DISPC_OVL_ATTRIBUTES(VID1) 00008000 DISPC_OVL_FIFO_THRESHOLD(VID1) 03ff03c0 DISPC_OVL_FIFO_SIZE_STATUS(VID1) 00000400 DISPC_OVL_ROW_INC(VID1) 00000001 DISPC_OVL_PIXEL_INC(VID1) 00000001 DISPC_OVL_PRELOAD(VID1) 00000100 DISPC_OVL_FIR(VID1) 00000000 DISPC_OVL_PICTURE_SIZE(VID1) 00000000 DISPC_OVL_ACCU0(VID1) 00000000 DISPC_OVL_ACCU1(VID1) 00000000 DISPC_OVL_PRELOAD(VID1) 00000100 DISPC_OVL_BA0(VID2) 00000000 DISPC_OVL_BA1(VID2) 00000000 DISPC_OVL_POSITION(VID2) 00000000 DISPC_OVL_SIZE(VID2) 00000000 DISPC_OVL_ATTRIBUTES(VID2) 00008000 DISPC_OVL_FIFO_THRESHOLD(VID2) 03ff03c0 DISPC_OVL_FIFO_SIZE_STATUS(VID2) 00000400 DISPC_OVL_ROW_INC(VID2) 00000001 DISPC_OVL_PIXEL_INC(VID2) 00000001 DISPC_OVL_PRELOAD(VID2) 00000100 DISPC_OVL_FIR(VID2) 00000000 DISPC_OVL_PICTURE_SIZE(VID2) 00000000 DISPC_OVL_ACCU0(VID2) 00000000 DISPC_OVL_ACCU1(VID2) 00000000 DISPC_OVL_PRELOAD(VID2) 00000100 DISPC_OVL_FIR_COEF_H_0(VID1) 00000000 DISPC_OVL_FIR_COEF_H_1(VID1) 00000000 DISPC_OVL_FIR_COEF_H_2(VID1) 00000000 DISPC_OVL_FIR_COEF_H_3(VID1) 00000000 DISPC_OVL_FIR_COEF_H_4(VID1) 00000000 DISPC_OVL_FIR_COEF_H_5(VID1) 00000000 DISPC_OVL_FIR_COEF_H_6(VID1) 00000000 DISPC_OVL_FIR_COEF_H_7(VID1) 00000000 DISPC_OVL_FIR_COEF_HV_0(VID1) 00000000 DISPC_OVL_FIR_COEF_HV_1(VID1) 00000000 DISPC_OVL_FIR_COEF_HV_2(VID1) 00000000 DISPC_OVL_FIR_COEF_HV_3(VID1) 00000000 DISPC_OVL_FIR_COEF_HV_4(VID1) 00000000 DISPC_OVL_FIR_COEF_HV_5(VID1) 00000000 DISPC_OVL_FIR_COEF_HV_6(VID1) 00000000 DISPC_OVL_FIR_COEF_HV_7(VID1) 00000000 DISPC_OVL_CONV_COEF_0(VID1) 0199012a DISPC_OVL_CONV_COEF_1(VID1) 012a0000 DISPC_OVL_CONV_COEF_2(VID1) 079c0730 DISPC_OVL_CONV_COEF_3(VID1) 0000012a DISPC_OVL_CONV_COEF_4(VID1) 00000205 DISPC_OVL_FIR_COEF_V_0(VID1) 00000000 DISPC_OVL_FIR_COEF_V_1(VID1) 00000000 DISPC_OVL_FIR_COEF_V_2(VID1) 00000000 DISPC_OVL_FIR_COEF_V_3(VID1) 00000000 DISPC_OVL_FIR_COEF_V_4(VID1) 00000000 DISPC_OVL_FIR_COEF_V_5(VID1) 00000000 DISPC_OVL_FIR_COEF_V_6(VID1) 00000000 DISPC_OVL_FIR_COEF_V_7(VID1) 00000000 DISPC_OVL_FIR_COEF_H_0(VID2) 00000000 DISPC_OVL_FIR_COEF_H_1(VID2) 00000000 DISPC_OVL_FIR_COEF_H_2(VID2) 00000000 DISPC_OVL_FIR_COEF_H_3(VID2) 00000000 DISPC_OVL_FIR_COEF_H_4(VID2) 00000000 DISPC_OVL_FIR_COEF_H_5(VID2) 00000000 DISPC_OVL_FIR_COEF_H_6(VID2) 00000000 DISPC_OVL_FIR_COEF_H_7(VID2) 00000000 DISPC_OVL_FIR_COEF_HV_0(VID2) 00000000 DISPC_OVL_FIR_COEF_HV_1(VID2) 00000000 DISPC_OVL_FIR_COEF_HV_2(VID2) 00000000 DISPC_OVL_FIR_COEF_HV_3(VID2) 00000000 DISPC_OVL_FIR_COEF_HV_4(VID2) 00000000 DISPC_OVL_FIR_COEF_HV_5(VID2) 00000000 DISPC_OVL_FIR_COEF_HV_6(VID2) 00000000 DISPC_OVL_FIR_COEF_HV_7(VID2) 00000000 DISPC_OVL_CONV_COEF_0(VID2) 0199012a DISPC_OVL_CONV_COEF_1(VID2) 012a0000 DISPC_OVL_CONV_COEF_2(VID2) 079c0730 DISPC_OVL_CONV_COEF_3(VID2) 0000012a DISPC_OVL_CONV_COEF_4(VID2) 00000205 DISPC_OVL_FIR_COEF_V_0(VID2) 00000000 DISPC_OVL_FIR_COEF_V_1(VID2) 00000000 DISPC_OVL_FIR_COEF_V_2(VID2) 00000000 DISPC_OVL_FIR_COEF_V_3(VID2) 00000000 DISPC_OVL_FIR_COEF_V_4(VID2) 00000000 DISPC_OVL_FIR_COEF_V_5(VID2) 00000000 DISPC_OVL_FIR_COEF_V_6(VID2) 00000000 DISPC_OVL_FIR_COEF_V_7(VID2) 00000000 root@am43xx-epos-evm:~# With Reserved memory for FB: ============================ root@am43xx-epos-evm:~# cat /proc/cmdline console=ttyO0,115200n8 root=/dev/mmcblk0p2 rw rootfstype=ext3 rootwait mem=128M consoleblank=0 clocksource=gp_timer consoleblank=0 earlyprintk omapfb_vram=10M@0xA0000000 root@am43xx-epos-evm:~# root@am43xx-epos-evm:~# root@am43xx-epos-evm:~# root@am43xx-epos-evm:~# cat /sys/kernel/debug/omapdss/dss DSS_REVISION 00000020 DSS_SYSCONFIG 00000001 DSS_SYSSTATUS 00000001 DSS_CONTROL 00000018 root@am43xx-epos-evm:~# root@am43xx-epos-evm:~# cat /sys/kernel/debug/omapdss/clk - DSS - DSS_FCK (DSS_FCLK1) = 198000000 - DISPC - dispc fclk source = DSS_FCK (DSS_FCLK1) fck 198000000 - LCD - LCD clk source = DSS_FCK (DSS_FCLK1) lck 198000000 lck div 1 pck 33000000 pck div 6 root@am43xx-epos-evm:~# root@am43xx-epos-evm:~# cat /sys/kernel/debug/omapdss/dispc_irq period 48010 ms irqs 2 FRAMEDONE 0 VSYNC 2 EVSYNC_EVEN 2 EVSYNC_ODD 2 ACBIAS_COUNT_STAT 0 PROG_LINE_NUM 2 GFX_FIFO_UNDERFLOW 2 GFX_END_WIN 2 PAL_GAMMA_MASK 0 OCP_ERR 0 VID1_FIFO_UNDERFLOW 0 VID1_END_WIN 0 VID2_FIFO_UNDERFLOW 0 VID2_END_WIN 0 SYNC_LOST 0 SYNC_LOST_DIGIT 0 WAKEUP 0 root@am43xx-epos-evm:~# root@am43xx-epos-evm:~# root@am43xx-epos-evm:~# root@am43xx-epos-evm:~# cat /sys/kernel/debug/omapdss/dispc DISPC_REVISION 00000030 DISPC_SYSCONFIG 00002011 DISPC_SYSSTATUS 00000001 DISPC_IRQSTATUS 0000002e DISPC_IRQENABLE 0000d640 DISPC_CONTROL 00018309 DISPC_CONFIG 00000204 DISPC_CAPABLE 000003ff DISPC_LINE_STATUS 0000011d DISPC_LINE_NUMBER 00000000 DISPC_GLOBAL_ALPHA 000000ff DISPC_DEFAULT_COLOR(LCD) 00000000 DISPC_TRANS_COLOR(LCD) 00000000 DISPC_SIZE_MGR(LCD) 01df031f DISPC_DEFAULT_COLOR(LCD) 00000000 DISPC_TRANS_COLOR(LCD) 00000000 DISPC_TIMING_H(LCD) 00f0d11d DISPC_TIMING_V(LCD) 00a0160c DISPC_POL_FREQ(LCD) 00003000 DISPC_DIVISORo(LCD) 00010006 DISPC_SIZE_MGR(LCD) 01df031f DISPC_DATA_CYCLE1(LCD) 00000000 DISPC_DATA_CYCLE2(LCD) 00000000 DISPC_DATA_CYCLE3(LCD) 00000000 DISPC_CPR_COEF_R(LCD) 00000000 DISPC_CPR_COEF_G(LCD) 00000000 DISPC_CPR_COEF_B(LCD) 00000000 DISPC_OVL_BA0(GFX) a0000000 DISPC_OVL_BA1(GFX) a0000000 DISPC_OVL_POSITION(GFX) 00000000 DISPC_OVL_SIZE(GFX) 01df031f DISPC_OVL_ATTRIBUTES(GFX) 00000090 DISPC_OVL_FIFO_THRESHOLD(GFX) 03ff03c0 DISPC_OVL_FIFO_SIZE_STATUS(GFX) 00000400 DISPC_OVL_ROW_INC(GFX) 00000001 DISPC_OVL_PIXEL_INC(GFX) 00000001 DISPC_OVL_PRELOAD(GFX) 00000100 DISPC_OVL_WINDOW_SKIP(GFX) 00000000 DISPC_OVL_TABLE_BA(GFX) 00000000 DISPC_OVL_BA0(VID1) 00000000 DISPC_OVL_BA1(VID1) 00000000 DISPC_OVL_POSITION(VID1) 00000000 DISPC_OVL_SIZE(VID1) 00000000 DISPC_OVL_ATTRIBUTES(VID1) 00008000 DISPC_OVL_FIFO_THRESHOLD(VID1) 03ff03c0 DISPC_OVL_FIFO_SIZE_STATUS(VID1) 00000400 DISPC_OVL_ROW_INC(VID1) 00000001 DISPC_OVL_PIXEL_INC(VID1) 00000001 DISPC_OVL_PRELOAD(VID1) 00000100 DISPC_OVL_FIR(VID1) 00000000 DISPC_OVL_PICTURE_SIZE(VID1) 00000000 DISPC_OVL_ACCU0(VID1) 00000000 DISPC_OVL_ACCU1(VID1) 00000000 DISPC_OVL_PRELOAD(VID1) 00000100 DISPC_OVL_BA0(VID2) 00000000 DISPC_OVL_BA1(VID2) 00000000 DISPC_OVL_POSITION(VID2) 00000000 DISPC_OVL_SIZE(VID2) 00000000 DISPC_OVL_ATTRIBUTES(VID2) 00008000 DISPC_OVL_FIFO_THRESHOLD(VID2) 03ff03c0 DISPC_OVL_FIFO_SIZE_STATUS(VID2) 00000400 DISPC_OVL_ROW_INC(VID2) 00000001 DISPC_OVL_PIXEL_INC(VID2) 00000001 DISPC_OVL_PRELOAD(VID2) 00000100 DISPC_OVL_FIR(VID2) 00000000 DISPC_OVL_PICTURE_SIZE(VID2) 00000000 DISPC_OVL_ACCU0(VID2) 00000000 DISPC_OVL_ACCU1(VID2) 00000000 DISPC_OVL_PRELOAD(VID2) 00000100 DISPC_OVL_FIR_COEF_H_0(VID1) 00000000 DISPC_OVL_FIR_COEF_H_1(VID1) 00000000 DISPC_OVL_FIR_COEF_H_2(VID1) 00000000 DISPC_OVL_FIR_COEF_H_3(VID1) 00000000 DISPC_OVL_FIR_COEF_H_4(VID1) 00000000 DISPC_OVL_FIR_COEF_H_5(VID1) 00000000 DISPC_OVL_FIR_COEF_H_6(VID1) 00000000 DISPC_OVL_FIR_COEF_H_7(VID1) 00000000 DISPC_OVL_FIR_COEF_HV_0(VID1) 00000000 DISPC_OVL_FIR_COEF_HV_1(VID1) 00000000 DISPC_OVL_FIR_COEF_HV_2(VID1) 00000000 DISPC_OVL_FIR_COEF_HV_3(VID1) 00000000 DISPC_OVL_FIR_COEF_HV_4(VID1) 00000000 DISPC_OVL_FIR_COEF_HV_5(VID1) 00000000 DISPC_OVL_FIR_COEF_HV_6(VID1) 00000000 DISPC_OVL_FIR_COEF_HV_7(VID1) 00000000 DISPC_OVL_CONV_COEF_0(VID1) 0199012a DISPC_OVL_CONV_COEF_1(VID1) 012a0000 DISPC_OVL_CONV_COEF_2(VID1) 079c0730 DISPC_OVL_CONV_COEF_3(VID1) 0000012a DISPC_OVL_CONV_COEF_4(VID1) 00000205 DISPC_OVL_FIR_COEF_V_0(VID1) 00000000 DISPC_OVL_FIR_COEF_V_1(VID1) 00000000 DISPC_OVL_FIR_COEF_V_2(VID1) 00000000 DISPC_OVL_FIR_COEF_V_3(VID1) 00000000 DISPC_OVL_FIR_COEF_V_4(VID1) 00000000 DISPC_OVL_FIR_COEF_V_5(VID1) 00000000 DISPC_OVL_FIR_COEF_V_6(VID1) 00000000 DISPC_OVL_FIR_COEF_V_7(VID1) 00000000 DISPC_OVL_FIR_COEF_H_0(VID2) 00000000 DISPC_OVL_FIR_COEF_H_1(VID2) 00000000 DISPC_OVL_FIR_COEF_H_2(VID2) 00000000 DISPC_OVL_FIR_COEF_H_3(VID2) 00000000 DISPC_OVL_FIR_COEF_H_4(VID2) 00000000 DISPC_OVL_FIR_COEF_H_5(VID2) 00000000 DISPC_OVL_FIR_COEF_H_6(VID2) 00000000 DISPC_OVL_FIR_COEF_H_7(VID2) 00000000 DISPC_OVL_FIR_COEF_HV_0(VID2) 00000000 DISPC_OVL_FIR_COEF_HV_1(VID2) 00000000 DISPC_OVL_FIR_COEF_HV_2(VID2) 00000000 DISPC_OVL_FIR_COEF_HV_3(VID2) 00000000 DISPC_OVL_FIR_COEF_HV_4(VID2) 00000000 DISPC_OVL_FIR_COEF_HV_5(VID2) 00000000 DISPC_OVL_FIR_COEF_HV_6(VID2) 00000000 DISPC_OVL_FIR_COEF_HV_7(VID2) 00000000 DISPC_OVL_CONV_COEF_0(VID2) 0199012a DISPC_OVL_CONV_COEF_1(VID2) 012a0000 DISPC_OVL_CONV_COEF_2(VID2) 079c0730 DISPC_OVL_CONV_COEF_3(VID2) 0000012a DISPC_OVL_CONV_COEF_4(VID2) 00000205 DISPC_OVL_FIR_COEF_V_0(VID2) 00000000 DISPC_OVL_FIR_COEF_V_1(VID2) 00000000 DISPC_OVL_FIR_COEF_V_2(VID2) 00000000 DISPC_OVL_FIR_COEF_V_3(VID2) 00000000 DISPC_OVL_FIR_COEF_V_4(VID2) 00000000 DISPC_OVL_FIR_COEF_V_5(VID2) 00000000 DISPC_OVL_FIR_COEF_V_6(VID2) 00000000 DISPC_OVL_FIR_COEF_V_7(VID2) 00000000 root@am43xx-epos-evm:~# -- To unsubscribe from this list: send the line "unsubscribe linux-fbdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 09.01.2014 10:08, Hiremath, Vaibhav wrote: > > No, that's what is causing issue to me. Can you try predefined address flow? > > Thanks, > Vaibhav > Booting Linux on physical CPU 0x0 Initializing cgroup subsys cpu Linux version 3.13.0-rc7+ (maemo@maemo-desktop) (gcc version 4.7.2 20120701 (prerelease) (Linaro GCC 4.7-2012.07) ) #24 PREEMPT Sat Jan 11 17:06:39 EET 2014 CPU: ARMv7 Processor [411fc083] revision 3 (ARMv7), cr=10c53c7d CPU: PIPT / VIPT nonaliasing data cache, VIPT nonaliasing instruction cache Machine: Nokia RX-51 board omapfb: reserved 0x00800000 bytes at 0x8f100000 Memory policy: Data cache writeback On node 0 totalpages: 61696 free_area_init_node: node 0, pgdat c05b73b4, node_mem_map c061b000 Normal zone: 512 pages used for memmap Normal zone: 0 pages reserved Normal zone: 61696 pages, LIFO batch:15 CPU: All CPU(s) started in SVC mode. OMAP3430/3530 ES3.1 (l2cache iva sgx neon isp ) pcpu-alloc: s0 r0 d32768 u32768 alloc=1*32768 pcpu-alloc: [0] 0 Built 1 zonelists in Zone order, mobility grouping on. Total pages: 61184 Kernel command line: init=/sbin/preinit ubi.mtd=rootfs root=ubi0:rootfs rootfstype=ubifs rootflags=bulk_read,no_chk_data_crc rw mtdoops.mtddev=log console=tty0 console=ttyO2 omapfb_vram=8M@0x8F100000 omapfb.mode=lcd:848x480-16 There are no (UNDERFLOW) errors on OMAP3 when predefined address is used, I am still able to play every video I try. Ivo -- To unsubscribe from this list: send the line "unsubscribe linux-fbdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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-fbdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
> -----Original Message----- > From: Ivaylo Dimitrov [mailto:ivo.g.dimitrov.75@gmail.com] > Sent: Thursday, January 23, 2014 2:38 AM > To: Hiremath, Vaibhav; Ivaylo Dimitrov; Valkeinen, Tomi > Cc: linux-omap@vger.kernel.org; linux-arm-kernel@lists.infradead.org; linux- > fbdev@vger.kernel.org > Subject: Re: [PATCH 1/2] ARM: omapfb: add coherent dma memory support > > Hmm, maybe this https://lkml.org/lkml/2014/1/22/386 will solve our issues > Link seems to be coming blank to me :) Thanks, Vaibhav -- To unsubscribe from this list: send the line "unsubscribe linux-fbdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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
diff --git a/arch/arm/mach-omap2/common.c b/arch/arm/mach-omap2/common.c index 2dabb9ecb986..9beecded0380 100644 --- a/arch/arm/mach-omap2/common.c +++ b/arch/arm/mach-omap2/common.c @@ -33,4 +33,5 @@ void __init omap_reserve(void) omap_dsp_reserve_sdram_memblock(); omap_secure_ram_reserve_memblock(); omap_barrier_reserve_memblock(); + omap_fb_reserve_memblock(); } diff --git a/arch/arm/mach-omap2/common.h b/arch/arm/mach-omap2/common.h index e30ef6797c63..21afdc0fe15e 100644 --- a/arch/arm/mach-omap2/common.h +++ b/arch/arm/mach-omap2/common.h @@ -304,6 +304,8 @@ extern void omap_reserve(void); struct omap_hwmod; extern int omap_dss_reset(struct omap_hwmod *); +extern void omap_fb_reserve_memblock(void); + /* SoC specific clock initializer */ extern int (*omap_clk_init)(void); diff --git a/arch/arm/mach-omap2/fb.c b/arch/arm/mach-omap2/fb.c index 26e28e94f625..80630329e508 100644 --- a/arch/arm/mach-omap2/fb.c +++ b/arch/arm/mach-omap2/fb.c @@ -30,9 +30,11 @@ #include <linux/dma-mapping.h> #include <asm/mach/map.h> +#include <asm/memblock.h> #include "soc.h" #include "display.h" +#include "common.h" #ifdef CONFIG_OMAP2_VRFB @@ -106,10 +108,83 @@ static struct platform_device omap_fb_device = { .num_resources = 0, }; +static phys_addr_t omapfb_mem_base __initdata; +static phys_addr_t omapfb_mem_size __initdata; + +static int __init early_omapfb_vram(char *p) +{ + omapfb_mem_size = memparse(p, &p); + + if (!omapfb_mem_size) { + pr_err("omapfb: bad size for 'omapfb_vram' param\n"); + return 0; + } + + if (*p == '@') { + omapfb_mem_base = memparse(p + 1, NULL); + + if (!omapfb_mem_base) { + pr_err("omapfb: bad addr for 'omapfb_vram' param\n"); + omapfb_mem_size = 0; + return 0; + } + } + + return 0; +} +early_param("omapfb_vram", early_omapfb_vram); + +void __init omap_fb_reserve_memblock(void) +{ + int r; + + if (!omapfb_mem_size) + return; + + if (omapfb_mem_base) { + r = memblock_reserve(omapfb_mem_base, omapfb_mem_size); + + if (r) { + pr_err("omapfb: memblock_reserve failed: %d\n", r); + return; + } + } else { + omapfb_mem_base = memblock_alloc(omapfb_mem_size, SZ_1M); + + if (!omapfb_mem_base) { + pr_err("omapfb: memblock_alloc failed\n"); + return; + } + } + + memblock_free(omapfb_mem_base, omapfb_mem_size); + memblock_remove(omapfb_mem_base, omapfb_mem_size); + + pr_info("omapfb: reserved %pa bytes at %pa\n", + &omapfb_mem_size, &omapfb_mem_base); +} + int __init omap_init_fb(void) { - return platform_device_register(&omap_fb_device); + int r; + + r = platform_device_register(&omap_fb_device); + + if (r) + return r; + + if (!omapfb_mem_base) + return 0; + + r = dma_declare_coherent_memory(&omap_fb_device.dev, + omapfb_mem_base, omapfb_mem_base, + omapfb_mem_size, DMA_MEMORY_MAP); + if (!(r & DMA_MEMORY_MAP)) + pr_err("omapfb: dma_declare_coherent_memory failed\n"); + + return 0; } + #else int __init omap_init_fb(void) { return 0; } #endif
The omapfb driver uses dma_alloc to reserve memory for the framebuffers. However, on some use cases, even when CMA is in use, it's quite probable that omapfb fails to allocate the fb, either due to not enough free dma memory, fragmented dma memory, or CMA failing to make enough contiguous space. This patch adds a kernel cmdline parameter 'omapfb_vram' which can be used to give the size of a memory area reserved exclusively for omapfb, and optionally a physical address where the memory area is reserved. The memory area is reserved with memblock, and assigned to omapfb with dma_declare_coherent_memory. The dma_alloc function will first try to allocate the fb from the coherent memory area, and if that fails, it'll use the normal method of allocation. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com> Cc: Ivaylo Dimitrov <freemangordon@abv.bg> --- arch/arm/mach-omap2/common.c | 1 + arch/arm/mach-omap2/common.h | 2 ++ arch/arm/mach-omap2/fb.c | 77 +++++++++++++++++++++++++++++++++++++++++++- 3 files changed, 79 insertions(+), 1 deletion(-)