[lkml]   [2013]   [Oct]   [30]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: 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.


[unhandled content-type:application/pgp-signature]
 \ /
  Last update: 2013-10-30 13:41    [W:0.038 / U:4.648 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site