Messages in this thread | | | Date | Wed, 30 Oct 2013 14:19:32 +0200 | From | Tomi Valkeinen <> | Subject | Re: OMAPFB: CMA allocation failures |
| |
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
[unhandled content-type:application/pgp-signature] | |