* Tomi Valkeinen <tomi.valkeinen@xxxxxx> [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 <tony@xxxxxxxxxxx> 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 majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
