All of lore.kernel.org
 help / color / mirror / Atom feed
From: Tomi Valkeinen <tomi.valkeinen@nokia.com>
To: linux-omap@vger.kernel.org
Subject: OMAP Framebuffer memory allocation and mapping
Date: Thu, 20 Nov 2008 12:52:09 +0200	[thread overview]
Message-ID: <1227178329.6860.139.camel@tubuntu> (raw)

Hi,

I have a couple of questions regarding the memory management for the new
display subsystem.

The new DSS allocates memory with dma_alloc_writecombine() and mmaps it
to user space with dma_mmap_writecombine(). Allocation is done when
omapfb starts up. Normally memory gets very quickly too fragmented for
dma_alloc_writecombine() to work, but setting
CONFIG_FB_OMAP_CONSISTENT_DMA_SIZE helps this.

However, even when CONFIG_FB_OMAP_CONSISTENT_DMA_SIZE is set to 14, I
am, for some reason, not able to allocate 1280x1024x4 (~5.2M)
framebuffer. Could the consistent DMA area be already too fragmented, or
is there some size limit there?

There's also support to allocate fb memory in very early phase with
reserve_bootmem(), which needs a predefined physical address and size
that can come from the bootloader. I've been looking at the old DSS to
see how this memory should be mapped, but I haven't been able to get it
to work. It looks like the DSS DMA and the user space have a bit
different view of the memory, so my assumption is that there's some
caching or similar being done.

So how to setup the memory gotten from reserve_bootmem() (or
alloc_bootmem()) so that it would work the same way as
dma_alloc_writecombine()'s memory?

And generally: any other ideas how to improve the memory management of
the DSS?

 Tomi



             reply	other threads:[~2008-11-20 10:52 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-11-20 10:52 Tomi Valkeinen [this message]
2008-11-20 11:25 ` OMAP Framebuffer memory allocation and mapping Hiremath, Vaibhav
2008-11-26 23:07   ` Tony Lindgren

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=1227178329.6860.139.camel@tubuntu \
    --to=tomi.valkeinen@nokia.com \
    --cc=linux-omap@vger.kernel.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.