linux-omap.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Ivaylo Dimitrov <ivo.g.dimitrov.75@gmail.com>
To: "Tomi Valkeinen" <tomi.valkeinen@ti.com>,
	"Pali Rohár" <pali.rohar@gmail.com>
Cc: 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 15:04:17 +0200	[thread overview]
Message-ID: <568A6DD1.5050700@gmail.com> (raw)
In-Reply-To: <568A5970.2000201@ti.com>

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

  reply	other threads:[~2016-01-04 13:04 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
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 [this message]
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=568A6DD1.5050700@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).