All of lore.kernel.org
 help / color / mirror / Atom feed
From: Tomi Valkeinen <tomi.valkeinen@ti.com>
To: "Ивайло Димитров" <freemangordon@abv.bg>
Cc: Minchan Kim <minchan@kernel.org>,
	pavel@ucw.cz, sre@debian.org, pali.rohar@gmail.com,
	pc+n900@asdf.org, linux-kernel@vger.kernel.org,
	linux-mm@kvack.org
Subject: Re: OMAPFB: CMA allocation failures
Date: Wed, 30 Oct 2013 14:19:32 +0200	[thread overview]
Message-ID: <5270F954.7090109@ti.com> (raw)
In-Reply-To: <737255712.30460.1383050855911.JavaMail.apache@mail83.abv.bg>

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

On 2013-10-29 14:47, Ивайло Димитров wrote:

> However, back to omapfb - my understanding is that the way it uses CMA (in its current form) is
> prone to allocation failures way beyond acceptable. 
> 
> Tomi, what do you think about adding module parameters to allow pre-allocating framebuffer memory
> from CMA during boot? Or re-implement VRAM allocator to use CMA? As a good side-effect 
> OMAPFB_GET_VRAM_INFO will no longer return fake values.

I really dislike the idea of adding the omap vram allocator back. Then
again, if the CMA doesn't work, something has to be done.

Pre-allocating is possible, but that won't work if there's any need to
re-allocating the framebuffers. Except if the omapfb would retain and
manage the pre-allocated buffers, but that would just be more or less
the old vram allocator again.

So, as I see it, the best option would be to have the standard dma_alloc
functions get the memory for omapfb from a private pool, which is not
used for anything else.

I wonder if that's possible already? It sounds quite trivial to me.

 Tomi



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

WARNING: multiple messages have this Message-ID (diff)
From: Tomi Valkeinen <tomi.valkeinen@ti.com>
To: "Ивайло Димитров" <freemangordon@abv.bg>
Cc: Minchan Kim <minchan@kernel.org>, <pavel@ucw.cz>,
	<sre@debian.org>, <pali.rohar@gmail.com>, <pc+n900@asdf.org>,
	<linux-kernel@vger.kernel.org>, <linux-mm@kvack.org>
Subject: Re: OMAPFB: CMA allocation failures
Date: Wed, 30 Oct 2013 14:19:32 +0200	[thread overview]
Message-ID: <5270F954.7090109@ti.com> (raw)
In-Reply-To: <737255712.30460.1383050855911.JavaMail.apache@mail83.abv.bg>

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

On 2013-10-29 14:47, Ивайло Димитров wrote:

> However, back to omapfb - my understanding is that the way it uses CMA (in its current form) is
> prone to allocation failures way beyond acceptable. 
> 
> Tomi, what do you think about adding module parameters to allow pre-allocating framebuffer memory
> from CMA during boot? Or re-implement VRAM allocator to use CMA? As a good side-effect 
> OMAPFB_GET_VRAM_INFO will no longer return fake values.

I really dislike the idea of adding the omap vram allocator back. Then
again, if the CMA doesn't work, something has to be done.

Pre-allocating is possible, but that won't work if there's any need to
re-allocating the framebuffers. Except if the omapfb would retain and
manage the pre-allocated buffers, but that would just be more or less
the old vram allocator again.

So, as I see it, the best option would be to have the standard dma_alloc
functions get the memory for omapfb from a private pool, which is not
used for anything else.

I wonder if that's possible already? It sounds quite trivial to me.

 Tomi



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

  parent reply	other threads:[~2013-10-30 12:19 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-10-29 12:47 OMAPFB: CMA allocation failures Ивайло Димитров
2013-10-29 12:47 ` Ивайло Димитров
2013-10-30  5:53 ` Minchan Kim
2013-10-30  5:53   ` Minchan Kim
2013-10-30 12:19 ` Tomi Valkeinen [this message]
2013-10-30 12:19   ` Tomi Valkeinen
     [not found] <1847426616.52843.1383681351015.JavaMail.apache@mail83.abv.bg>
2013-11-30 10:00 ` 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
  -- strict thread matches above, loose matches on Subject: below --
2013-11-05 19:55 Ивайло Димитров
2013-11-05 19:55 ` Ивайло Димитров
2013-10-23 21:59 Ивайло Димитров
2013-10-23 21:59 ` Ивайло Димитров
2013-10-24  7:00 ` Tomi Valkeinen
2013-10-24  7:00   ` Tomi Valkeinen
2013-10-16  6:33 Ивайло Димитров
2013-10-16  6:33 ` Ивайло Димитров
2013-10-15  6:49 Ивайло Димитров
2013-10-15  6:49 ` Ивайло Димитров
2013-10-15  7:36 ` Tomi Valkeinen
2013-10-15  7:36   ` Tomi Valkeinen
2013-10-28  7:37 ` Minchan Kim
2013-10-28  7:37   ` Minchan Kim
2013-10-12 14:43 Ивайло Димитров
2013-10-14  6:04 ` Tomi Valkeinen

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=5270F954.7090109@ti.com \
    --to=tomi.valkeinen@ti.com \
    --cc=freemangordon@abv.bg \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=minchan@kernel.org \
    --cc=pali.rohar@gmail.com \
    --cc=pavel@ucw.cz \
    --cc=pc+n900@asdf.org \
    --cc=sre@debian.org \
    /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.