All of lore.kernel.org
 help / color / mirror / Atom feed
From: Tomi Valkeinen <tomi.valkeinen@ti.com>
To: "Pali Rohár" <pali.rohar@gmail.com>
Cc: Ivaylo Dimitrov <ivo.g.dimitrov.75@gmail.com>,
	tony@atomide.com, linux@arm.linux.org.uk, pavel@ucw.cz,
	linux-omap@vger.kernel.org, linux-kernel@vger.kernel.org,
	Ivaylo Dimitrov <freemangordon@abv.bg>
Subject: Re: [PATCH] ARM: omapfb: Add early framebuffer memory allocator
Date: Mon, 4 Jan 2016 13:37:20 +0200	[thread overview]
Message-ID: <568A5970.2000201@ti.com> (raw)
In-Reply-To: <201601011301.27415@pali>

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

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


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

WARNING: multiple messages have this Message-ID (diff)
From: Tomi Valkeinen <tomi.valkeinen@ti.com>
To: "Pali Rohár" <pali.rohar@gmail.com>
Cc: Ivaylo Dimitrov <ivo.g.dimitrov.75@gmail.com>, <tony@atomide.com>,
	<linux@arm.linux.org.uk>, <pavel@ucw.cz>,
	<linux-omap@vger.kernel.org>, <linux-kernel@vger.kernel.org>,
	Ivaylo Dimitrov <freemangordon@abv.bg>
Subject: Re: [PATCH] ARM: omapfb: Add early framebuffer memory allocator
Date: Mon, 4 Jan 2016 13:37:20 +0200	[thread overview]
Message-ID: <568A5970.2000201@ti.com> (raw)
In-Reply-To: <201601011301.27415@pali>

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

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


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

  reply	other threads:[~2016-01-04 11:37 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <1847426616.52843.1383681351015.JavaMail.apache@mail83.abv.bg>
2013-11-30 10:00 ` OMAPFB: CMA allocation failures Ivajlo Dimitrov
2013-11-30 10:00   ` Ivajlo Dimitrov
2013-12-05 11:25   ` Tomi Valkeinen
2013-12-05 11:25     ` Tomi Valkeinen
2013-12-06  8:31     ` Ivajlo Dimitrov
2013-12-06  8:31       ` Ivajlo Dimitrov
2013-12-25 23:12     ` [PATCH] ARM: omapfb: Add early framebuffer memory allocator Ivaylo Dimitrov
2013-12-27  9:48       ` Pavel Machek
2013-12-27 16:34         ` Ivaylo Dimitrov
2015-12-25 13:36       ` Ivaylo Dimitrov
2016-01-01 12:01       ` Pali Rohár
2016-01-04 11:37         ` Tomi Valkeinen [this message]
2016-01-04 11:37           ` Tomi Valkeinen
2016-01-04 13:04           ` Ivaylo Dimitrov
2016-01-11 18:34             ` Tomi Valkeinen
2016-01-11 18:34               ` Tomi Valkeinen
2016-02-13  7:25               ` Ivaylo Dimitrov
2016-02-16 13:51                 ` Tomi Valkeinen
2016-02-16 13:51                   ` Tomi Valkeinen
2016-02-16 14:05                   ` Pali Rohár
2016-02-17  7:31                   ` Ivaylo Dimitrov

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=568A5970.2000201@ti.com \
    --to=tomi.valkeinen@ti.com \
    --cc=freemangordon@abv.bg \
    --cc=ivo.g.dimitrov.75@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-omap@vger.kernel.org \
    --cc=linux@arm.linux.org.uk \
    --cc=pali.rohar@gmail.com \
    --cc=pavel@ucw.cz \
    --cc=tony@atomide.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.