Hello, On Wednesday, September 05, 2012 12:09 PM Tomi Valkeinen wrote: > OMAP has a custom video ram allocator, which I'd like to remove and use > the standard dma allocation functions. > > There are two problems for which I'd like to hear suggestions or > comments: > > First one is that the dma_alloc_* functions map the allocated memory for > cpu use. In many cases with OMAP DSS (display subsystem) this is not > needed: the memory may be written only by the SGX or the DSP, and it's > only read by the DSS, so it's never touched by the CPU. > > This is even more true when using VRFB on omap3 (and probably TILER on > omap4) for rotation, as VRFB hides the actual memory and offers rotated > views. In this case the backend memory is never accessed by anyone else > than VRFB. > > Is there a way to allocate the memory without creating a mapping? While > it won't break anything as such, the allocated areas can be quite large > thus causing large areas of the kernel's memory space to be needlessly > reserved. Please check commits d5724f172fd1 and 955c757e090 merged to v3.6-rc1. Support for this attribute is now only available in IOMMU-aware dma-mapping implementation, but I plan to add it also to standard linear ARM dma-mapping implementation based on alloc_pages_exact(). Some not-well-documented example can be found here: https://patchwork.kernel.org/patch/1323591/ (at the bottom). You probably might need to add your own custom dma_map_ops set of functions for TILER device, but I'm not really sure if I get right what does that device do and what will be the use cases for it. > The second case is passing a framebuffer address from the bootloader to > the kernel. Often with mobile devices the bootloader will initialize the > display hardware, showing a company logo or such. To keep the image on > the screen when kernel starts we need to reserve the same physical > memory area early at boot, and use that for the framebuffer. > > I'm not sure if there's any actual problem with this one, presuming > there is a solution for the first case. Somehow the memory is reserved > at early boot time, and this is passed to the fb driver. But can the > memory be managed the same way as in normal case (for example freeing > it), or does it need to be handled as a special case? The only solution I see here is to use custom coherent memory pool for the framebuffer device and setup it starting from the physical address of the framebuffer configured by bootloader. See dma_declare_coherent() function. Some usage example on ARM architecture can be found in arch/arm/plat-samsung/s5p-dev-mfc.c The other possibility is to enable Contiguous Memory Allocator and define a custom contiguous memory area for framebuffer device at the same physical address as configured by bootloader: http://git.linaro.org/gitweb?p=people/mszyprowski/linux-archive.git;a=commitdiff;h=f8ff4f99cfa4f67e09a3c948e007e82a0c21434a Feel free to comment both possibilities, maybe we can work out something better for solving this quite common use case. Best regards -- Marek Szyprowski Samsung Poland R&D Center -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
