Re: [PATCH] ARM: omapfb: Add early framebuffer memory allocator

[Tomi Valkeinen <tomi.valkeinen@ti.com>]

[-- Attachment #1: Type: text/plain, Size: 2206 bytes --]


On 04/01/16 15:04, Ivaylo Dimitrov wrote:
> 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.

I don't know about omap3 (if that's what you're talking about), but
generally, I think it depends very much on the IPs used. I don't think
all capture IPs support sg.

>> 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.

The patch itself looks fine to me, and I have no problem adding
temporary code to help solve use cases. Except when they add new
userspace APIs, which is what's done here. I've been bitten too many
times by an userspace API that I need to maintain forever, making new
development difficult. That's the reason I'm (maybe overly) cautious here.

I also want to point out that the patch was posted two years ago. And
now there's a ping for the first time. It cannot be a huge problem to a
lot of people.

Adding to that is the fact that omapfb is now in maintenance mode, and
all new development is done for omapdrm.

So, I'm not very enthusiastic about adding this feature as an omapfb
specific boot parameter.

 Tomi


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]