Re: [PATCH 0/5] OMAPFB: use dma_alloc instead of omap's vram
Hi, On 2012-11-21 16:22, Jello huang wrote: HI Tomi, we need one rank of cma to allocate the memory for driver in kernel space .And the default CMA is for allocating memory frome usespace.So if we allocate the memory from the default CMA zone ,there maybe introduce fragmention to the default CMA zone.The kernel space memory donot touch the memory from userspace Can you elaborate a bit? I didn't understand your point. Are you saying each kernel driver that uses dma_alloc should have their own CMA zone? That doesn't make sense... How do you allocate CMA memory from userspace? Tomi signature.asc Description: OpenPGP digital signature
Re: [PATCH 0/5] OMAPFB: use dma_alloc instead of omap's vram
HI Tomi, we need one rank of cma to allocate the memory for driver in kernel space .And the default CMA is for allocating memory frome usespace.So if we allocate the memory from the default CMA zone ,there maybe introduce fragmention to the default CMA zone.The kernel space memory donot touch the memory from userspace Jello Huang On 21/11/2012, Tony Lindgren t...@atomide.com wrote: * Tomi Valkeinen tomi.valkei...@ti.com [121115 23:17]: I added your acks, and pushed: git://gitorious.org/linux-omap-dss2/linux.git 3.8/vram-conversion It's based on -rc4 as my other branches are based on that. OK thanks! Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- Thanks Jello Huang -- 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 0/5] OMAPFB: use dma_alloc instead of omap's vram
On 2012-11-20 00:04, Tony Lindgren wrote: Should we enable CMA by default in omap2plus_defconfig? And perhaps on omap1 also? Yes if that's now needed for DSS. DSS works fine without CMA, at least for small displays, and when fb allocation is done at boot time. So it's not a strict need. I'm not sure how easily FB allocations start to fail without CMA, and how much CMA helps. I'm not even sure what's the default DMA pool size on OMAP... If it's the one set with coherent_pool kernel parameter, then the default seems to be 256K, which is quite small for video use. For CMA the default global area is 16M. Both can, of course, be changed with boot params or kernel config (at least for CMA). But I think it makes sense to have CMA by default even if non-CMA kernel would work. Tomi signature.asc Description: OpenPGP digital signature
Re: [PATCH 0/5] OMAPFB: use dma_alloc instead of omap's vram
* Tomi Valkeinen tomi.valkei...@ti.com [121115 23:17]: I added your acks, and pushed: git://gitorious.org/linux-omap-dss2/linux.git 3.8/vram-conversion It's based on -rc4 as my other branches are based on that. OK thanks! Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/5] OMAPFB: use dma_alloc instead of omap's vram
* Tomi Valkeinen tomi.valkei...@ti.com [121116 01:08]: Hi Tony, On 2012-11-13 00:50, Tony Lindgren wrote: * Tomi Valkeinen tomi.valkei...@ti.com [121112 02:27]: Hi, This series changes omapfb to use standard dma_alloc funcs instead of omap specific vram allocator. This let's us remove the omap vram allocator, making omapfb platform independent. However, note that using standard dma funcs causes the following downsides: 1) dma_alloc_attrs doesn't let us allocate at certain physical address. However, this should not be a problem as this feature of vram allocator is only used when reserving the framebuffer that was initialized by the bootloader, and we don't currently support passing a framebuffer from the bootloader to the kernel anyway. 2) dma_alloc_attrs, as of now, always ioremaps the allocated area, and we don't need the ioremap when using VRFB. This patch uses DMA_ATTR_NO_KERNEL_MAPPING for the allocation, but the flag is currently not operational. 3) OMAPFB_GET_VRAM_INFO ioctl cannot return real values anymore. I changed the ioctl to return 64M for all the values, which, I hope, the applications will interpret as there's enough vram. 4) vram kernel parameter to define how much ram to reserve for video use no longer works. The user needs to enable CMA and use cma parameter. Great, thanks for fixing these. Could you please queue these into a separate branch against v3.7-rc5 that I can also merge into omap-for-v3.8/cleanup-headers-prepare-multiplatform-v3? Should we enable CMA by default in omap2plus_defconfig? And perhaps on omap1 also? Yes if that's now needed for DSS. I have to say I don't know the details of the dma allocation, but afaik there are no drawbacks with CMA. Although it is still marked EXPERIMENTAL in the kconfig... I guess that's still fine as that's what we're supposed to use :) Regards, Tony -- 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 0/5] OMAPFB: use dma_alloc instead of omap's vram
Hi Tony, On 2012-11-13 00:50, Tony Lindgren wrote: * Tomi Valkeinen tomi.valkei...@ti.com [121112 02:27]: Hi, This series changes omapfb to use standard dma_alloc funcs instead of omap specific vram allocator. This let's us remove the omap vram allocator, making omapfb platform independent. However, note that using standard dma funcs causes the following downsides: 1) dma_alloc_attrs doesn't let us allocate at certain physical address. However, this should not be a problem as this feature of vram allocator is only used when reserving the framebuffer that was initialized by the bootloader, and we don't currently support passing a framebuffer from the bootloader to the kernel anyway. 2) dma_alloc_attrs, as of now, always ioremaps the allocated area, and we don't need the ioremap when using VRFB. This patch uses DMA_ATTR_NO_KERNEL_MAPPING for the allocation, but the flag is currently not operational. 3) OMAPFB_GET_VRAM_INFO ioctl cannot return real values anymore. I changed the ioctl to return 64M for all the values, which, I hope, the applications will interpret as there's enough vram. 4) vram kernel parameter to define how much ram to reserve for video use no longer works. The user needs to enable CMA and use cma parameter. Great, thanks for fixing these. Could you please queue these into a separate branch against v3.7-rc5 that I can also merge into omap-for-v3.8/cleanup-headers-prepare-multiplatform-v3? Should we enable CMA by default in omap2plus_defconfig? And perhaps on omap1 also? I have to say I don't know the details of the dma allocation, but afaik there are no drawbacks with CMA. Although it is still marked EXPERIMENTAL in the kconfig... Tomi signature.asc Description: OpenPGP digital signature
Re: [PATCH 0/5] OMAPFB: use dma_alloc instead of omap's vram
On 2012-11-13 00:50, Tony Lindgren wrote: * Tomi Valkeinen tomi.valkei...@ti.com [121112 02:27]: Hi, This series changes omapfb to use standard dma_alloc funcs instead of omap specific vram allocator. This let's us remove the omap vram allocator, making omapfb platform independent. However, note that using standard dma funcs causes the following downsides: 1) dma_alloc_attrs doesn't let us allocate at certain physical address. However, this should not be a problem as this feature of vram allocator is only used when reserving the framebuffer that was initialized by the bootloader, and we don't currently support passing a framebuffer from the bootloader to the kernel anyway. 2) dma_alloc_attrs, as of now, always ioremaps the allocated area, and we don't need the ioremap when using VRFB. This patch uses DMA_ATTR_NO_KERNEL_MAPPING for the allocation, but the flag is currently not operational. 3) OMAPFB_GET_VRAM_INFO ioctl cannot return real values anymore. I changed the ioctl to return 64M for all the values, which, I hope, the applications will interpret as there's enough vram. 4) vram kernel parameter to define how much ram to reserve for video use no longer works. The user needs to enable CMA and use cma parameter. Great, thanks for fixing these. Could you please queue these into a separate branch against v3.7-rc5 that I can also merge into omap-for-v3.8/cleanup-headers-prepare-multiplatform-v3? Feel free to add my Acked-by: Tony Lindgren t...@atomide.com to the arch/arm/*omap*/* parts. I added your acks, and pushed: git://gitorious.org/linux-omap-dss2/linux.git 3.8/vram-conversion It's based on -rc4 as my other branches are based on that. Tomi signature.asc Description: OpenPGP digital signature
[PATCH 0/5] OMAPFB: use dma_alloc instead of omap's vram
Hi, This series changes omapfb to use standard dma_alloc funcs instead of omap specific vram allocator. This let's us remove the omap vram allocator, making omapfb platform independent. However, note that using standard dma funcs causes the following downsides: 1) dma_alloc_attrs doesn't let us allocate at certain physical address. However, this should not be a problem as this feature of vram allocator is only used when reserving the framebuffer that was initialized by the bootloader, and we don't currently support passing a framebuffer from the bootloader to the kernel anyway. 2) dma_alloc_attrs, as of now, always ioremaps the allocated area, and we don't need the ioremap when using VRFB. This patch uses DMA_ATTR_NO_KERNEL_MAPPING for the allocation, but the flag is currently not operational. 3) OMAPFB_GET_VRAM_INFO ioctl cannot return real values anymore. I changed the ioctl to return 64M for all the values, which, I hope, the applications will interpret as there's enough vram. 4) vram kernel parameter to define how much ram to reserve for video use no longer works. The user needs to enable CMA and use cma parameter. Tomi Tomi Valkeinen (5): OMAP: FB: use DMA_BIT_MASK() for fb's coherent_dma_mask OMAPFB: use dma_alloc_attrs to allocate memory OMAP: RX51: remove use of vram OMAP: common.c: remove init call to vram OMAP: remove vram allocator arch/arm/mach-omap2/board-rx51-video.c| 14 - arch/arm/mach-omap2/board-rx51.c |3 - arch/arm/plat-omap/common.c |2 - arch/arm/plat-omap/fb.c |5 +- arch/arm/plat-omap/include/plat/vram.h| 43 --- drivers/video/omap2/Kconfig |3 - drivers/video/omap2/Makefile |1 - drivers/video/omap2/dss/Kconfig | 12 - drivers/video/omap2/omapfb/Kconfig|1 - drivers/video/omap2/omapfb/omapfb-ioctl.c | 14 +- drivers/video/omap2/omapfb/omapfb-main.c | 69 ++-- drivers/video/omap2/omapfb/omapfb.h |5 + drivers/video/omap2/vram.c| 514 - 13 files changed, 51 insertions(+), 635 deletions(-) delete mode 100644 arch/arm/plat-omap/include/plat/vram.h delete mode 100644 drivers/video/omap2/vram.c -- 1.7.10.4 -- 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 0/5] OMAPFB: use dma_alloc instead of omap's vram
Hi, On Mon, Nov 12, 2012 at 12:25 PM, Tomi Valkeinen tomi.valkei...@ti.com wrote: This series changes omapfb to use standard dma_alloc funcs instead of omap specific vram allocator. This let's us remove the omap vram allocator, making omapfb platform independent. However, note that using standard dma funcs causes the following downsides: ... 3) OMAPFB_GET_VRAM_INFO ioctl cannot return real values anymore. I changed the ioctl to return 64M for all the values, which, I hope, the applications will interpret as there's enough vram. Do at least OMAPFB_QUERY_MEM/OMAPFB_SETUP_MEM still work? 4) vram kernel parameter to define how much ram to reserve for video use no longer works. The user needs to enable CMA and use cma parameter. That's a significant change, you should update Documentation/ . What about omapfb.vram, is it still there? Perhaps we also need to select/depend on CMA? -- GraÅžvydas -- 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 0/5] OMAPFB: use dma_alloc instead of omap's vram
On 2012-11-12 15:39, Grazvydas Ignotas wrote: Hi, On Mon, Nov 12, 2012 at 12:25 PM, Tomi Valkeinen tomi.valkei...@ti.com wrote: This series changes omapfb to use standard dma_alloc funcs instead of omap specific vram allocator. This let's us remove the omap vram allocator, making omapfb platform independent. However, note that using standard dma funcs causes the following downsides: ... 3) OMAPFB_GET_VRAM_INFO ioctl cannot return real values anymore. I changed the ioctl to return 64M for all the values, which, I hope, the applications will interpret as there's enough vram. Do at least OMAPFB_QUERY_MEM/OMAPFB_SETUP_MEM still work? Yes. 4) vram kernel parameter to define how much ram to reserve for video use no longer works. The user needs to enable CMA and use cma parameter. That's a significant change, you should update Documentation/ . Ah right. The documentation. I never remember =). What about omapfb.vram, is it still there? Yes. Perhaps we also need to select/depend on CMA? dma_alloc_* funcs work fine without CMA. CMA only makes them work better. Thus I don't think OMAPFB should depend on CMA, but perhaps CMA should be enabled by default in omap2plus_defconfig? Tomi signature.asc Description: OpenPGP digital signature
Re: [PATCH 0/5] OMAPFB: use dma_alloc instead of omap's vram
On 2012-11-12 15:39, Grazvydas Ignotas wrote: Hi, On Mon, Nov 12, 2012 at 12:25 PM, Tomi Valkeinen tomi.valkei...@ti.com wrote: This series changes omapfb to use standard dma_alloc funcs instead of omap specific vram allocator. This let's us remove the omap vram allocator, making omapfb platform independent. However, note that using standard dma funcs causes the following downsides: ... 3) OMAPFB_GET_VRAM_INFO ioctl cannot return real values anymore. I changed the ioctl to return 64M for all the values, which, I hope, the applications will interpret as there's enough vram. Do at least OMAPFB_QUERY_MEM/OMAPFB_SETUP_MEM still work? 4) vram kernel parameter to define how much ram to reserve for video use no longer works. The user needs to enable CMA and use cma parameter. That's a significant change, you should update Documentation/ . I've added the following documentation change: diff --git a/Documentation/arm/OMAP/DSS b/Documentation/arm/OMAP/DSS index a564cee..4484e02 100644 --- a/Documentation/arm/OMAP/DSS +++ b/Documentation/arm/OMAP/DSS @@ -285,7 +285,10 @@ FB0 +-- GFX LCD LCD Misc notes -- -OMAP FB allocates the framebuffer memory using the OMAP VRAM allocator. +OMAP FB allocates the framebuffer memory using the standard dma allocator. You +can enable Contiguous Memory Allocator (CONFIG_CMA) to improve the dma +allocator, and if CMA is enabled, you use cma= kernel parameter to increase +the global memory area for CMA. Using DSI DPLL to generate pixel clock it is possible produce the pixel clock of 86.5MHz (max possible), and with that you get 1280x1024@57 output from DVI. @@ -301,11 +304,6 @@ framebuffer parameters. Kernel boot arguments - -vram=size[,physaddr] - - Amount of total VRAM to preallocate and optionally a physical start - memory address. For example, 10M. omapfb allocates memory for - framebuffers from VRAM. - signature.asc Description: OpenPGP digital signature
Re: [PATCH 0/5] OMAPFB: use dma_alloc instead of omap's vram
* Tomi Valkeinen tomi.valkei...@ti.com [121112 02:27]: Hi, This series changes omapfb to use standard dma_alloc funcs instead of omap specific vram allocator. This let's us remove the omap vram allocator, making omapfb platform independent. However, note that using standard dma funcs causes the following downsides: 1) dma_alloc_attrs doesn't let us allocate at certain physical address. However, this should not be a problem as this feature of vram allocator is only used when reserving the framebuffer that was initialized by the bootloader, and we don't currently support passing a framebuffer from the bootloader to the kernel anyway. 2) dma_alloc_attrs, as of now, always ioremaps the allocated area, and we don't need the ioremap when using VRFB. This patch uses DMA_ATTR_NO_KERNEL_MAPPING for the allocation, but the flag is currently not operational. 3) OMAPFB_GET_VRAM_INFO ioctl cannot return real values anymore. I changed the ioctl to return 64M for all the values, which, I hope, the applications will interpret as there's enough vram. 4) vram kernel parameter to define how much ram to reserve for video use no longer works. The user needs to enable CMA and use cma parameter. Great, thanks for fixing these. Could you please queue these into a separate branch against v3.7-rc5 that I can also merge into omap-for-v3.8/cleanup-headers-prepare-multiplatform-v3? Feel free to add my Acked-by: Tony Lindgren t...@atomide.com to the arch/arm/*omap*/* parts. Regards, Tony -- 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
