On 2013-10-29 14:47, Ивайло Димитров wrote: > However, back to omapfb - my understanding is that the way it uses CMA (in > its current form) is > prone to allocation failures way beyond acceptable. > > Tomi, what do you think about adding module parameters to allow > pre-allocating framebuffer memory > from CMA during boot? Or re-implement VRAM allocator to use CMA? As a good > side-effect > OMAPFB_GET_VRAM_INFO will no longer return fake values.
I really dislike the idea of adding the omap vram allocator back. Then again, if the CMA doesn't work, something has to be done. Pre-allocating is possible, but that won't work if there's any need to re-allocating the framebuffers. Except if the omapfb would retain and manage the pre-allocated buffers, but that would just be more or less the old vram allocator again. So, as I see it, the best option would be to have the standard dma_alloc functions get the memory for omapfb from a private pool, which is not used for anything else. I wonder if that's possible already? It sounds quite trivial to me. Tomi
signature.asc
Description: OpenPGP digital signature
