OMAPFB: use dma_alloc instead of omap's vram
Get series with b4
b4 am [email protected]Versions newest first
- v1 Latest0 of 5 patches 0 repliesNew
Patches in v1 No applies recorded yet
None of the 5 patches the cover letter announces are in this archive.
Reviews trailers per patch
No Reviewed-by, Acked-by or Tested-by trailers for v1 yet.
Cover letter [PATCH 0/5] OMAPFB: use dma_alloc instead of omap's vram
Hi Tony,
Quoted 24 lines · Tony Lindgren
Quoted 23 lines · Tomi Valkeinen
Hi,
This series changes omapfb to use standard
dma_allocfuncs 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_attrsdoesn'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 usesDMA_ATTR_NO_KERNEL_MAPPINGfor the allocation, but the flag is currently not operational.3)
OMAPFB_GET_VRAM_INFOioctl 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".
Quoted 6 lines
Quoted 2 lines
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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 897 bytes
Desc: OpenPGP digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20121116/7903ce26/attachment.sig>