lkml.org 
[lkml]   [2016]   [Jan]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [PATCH] ARM: omapfb: Add early framebuffer memory allocator
From
Date
Hi Tomi,

On 4.01.2016 13:37, Tomi Valkeinen wrote:
>
> We probably need exactly the same for omapdrm, as omapfb is on the way
> to being deprecated. And sounds to me that we probably need similar for
> other devices which try to do large allocations (camera? video decoders?).
>

Re omapdrm - I guess it wouldn't be hard for omapdrm to use the same
preallocated memory, when/if it is needed. Though I know nothing about
omapdrm, so can't really tell.

If not mistaken, camera driver uses sg lists. DSP needs such a memory,
but anyway it(driver) was removed from mainline, with no signs/hope to
be returned anytime soon.

> So I really think this should be somehow be a general option for any device.
>

Then maybe add the relevant people in CC, so we to start some kind of
discussion. But until such a general option exists, I think it makes
sense to apply the $subject patch, we can easily fix it to use whatever
general purpose API might the discussion come up with. As it is now,
omapfb simply cannot be used to play any video with sane resolution
(without preallocated memory that is), unless this is the only thing the
device does. And even then it is not assured.

> I also wonder if CMA can be improved to not need anything like this? If
> you just increase the CMA area, won't that increase the chances CMA will
> work?
>

The short answer is no, at least not with the CMA code currently
upstream. A kind of a long answer could be found on
http://marc.info/?l=linux-mm&m=141571797202006&w=2

Regards,
Ivo


\
 
 \ /
  Last update: 2016-01-04 14:21    [W:0.070 / U:0.808 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site