From: Ivaylo Dimitrov <ivo.g.dimitrov.75@gmail.com>
To: Pavel Machek <pavel@ucw.cz>,
Ivaylo Dimitrov <ivo.g.dimitrov.75@gmail.com>
Cc: tomi.valkeinen@ti.com, tony@atomide.com, linux@arm.linux.org.uk,
pali.rohar@gmail.com, 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: Fri, 27 Dec 2013 18:34:10 +0200 [thread overview]
Message-ID: <52BDAC02.4020404@gmail.com> (raw)
In-Reply-To: <20131227094801.GB17143@amd.pavel.ucw.cz>
On 27.12.2013 11:48, Pavel Machek wrote:
> On Thu 2013-12-26 01: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
>>
>> Signed-off-by: Ivaylo Dimitrov <freemangordon@abv.bg>
> Hmm, would it make sense to add a parameter to reserve certain ammount
> of memory for CMA? omapfb is probably not the only user hitting
> this...?
> Pavel
But that would mean that one must have CMA enabled to use that
functionality and it is an additional memory overhead. Also, I don't
think we will have much of a benefit of that - for video playback we'll
still have to preallocate the same amount of RAM as now - but with the
additional overhead of page migration when that RAM becomes needed by
DSP and OMAPFB. However, even if such functionality is someday
implemented in CMA, it doesn't conflict with the proposed patch - by
simply not preallocating memory for omapfb, one will automatically use it.
BTW there is CMEM driver (not upstreamed afaik) which does exactly that
- it manages a contiguous ("stolen")memory pool. No idea how easy it
would be to merge CMEM into CMA. Neither I am the right guy for the
task, IMO :)
Ivo
next prev parent reply other threads:[~2013-12-27 16:34 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <52A062A0.3070005@ti.com>
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 [this message]
2015-12-25 13:36 ` Ivaylo Dimitrov
2016-01-01 12:01 ` Pali Rohár
2016-01-04 11:37 ` Tomi Valkeinen
2016-01-04 13:04 ` Ivaylo Dimitrov
2016-01-11 18:34 ` Tomi Valkeinen
2016-02-13 7:25 ` Ivaylo Dimitrov
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=52BDAC02.4020404@gmail.com \
--to=ivo.g.dimitrov.75@gmail.com \
--cc=freemangordon@abv.bg \
--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=tomi.valkeinen@ti.com \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).