Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1300656 > unrolled thread

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

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: [PATCH] ARM: omapfb: Add early framebuffer memory allocator Tomi Valkeinen <tomi.valkeinen@ti.com> - 2016-01-04 12:40 +0100
    Re: [PATCH] ARM: omapfb: Add early framebuffer memory allocator Ivaylo Dimitrov <ivo.g.dimitrov.75@gmail.com> - 2016-01-04 14:10 +0100
      Re: [PATCH] ARM: omapfb: Add early framebuffer memory allocator Tomi Valkeinen <tomi.valkeinen@ti.com> - 2016-01-11 19:40 +0100

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

[Multipart message — attachments visible in raw view] — view raw

Hi,

On 01/01/16 14:01, Pali Rohár wrote:
> Hi Tomi! Can you review this patch? It is waiting here for two years!
> 
> On Thursday 26 December 2013 00:12:39 Ivaylo Dimitrov wrote:
>> From: Ivaylo Dimitrov <freemangordon@abv.bg>
>>
>> On memory limited devices, CMA fails easily when asked to allocate
>> big chunks of memory like framebuffer memory needed for video
>> playback.
>>
>> Add boot parameter "omapfb_memsize" which allocates memory to be used
>> as dma coherent memory, so dma_alloc_attrs won't hit CMA allocator
>> when trying to allocate memory for the framebuffers

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

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

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?

 Tomi

[toc] | [next] | [standalone]

#1300736

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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1306596

[Multipart message — attachments visible in raw view] — view raw

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

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web