From: hunold@linuxtv.org (Michael Hunold)
To: linux-arm-kernel@lists.infradead.org
Subject: dma_alloc_writecombine() and MAX_ORDER
Date: Fri, 29 Apr 2011 14:50:37 +0200 [thread overview]
Message-ID: <4DBAB41D.7030705@linuxtv.org> (raw)
Hello,
I'm using dma_alloc_writecombine() to allocate memory in my framebuffer
device driver just like many other drivers do.
Now I have a new panel with a higher resolution and more bits-per-pixel.
I want to use double-buffering with DirectFB and so my framebuffer size
exceeds 4Mb.
Even though my embedded system has plenty of memory, now I receive the
following warning and the allocation fails:
WARNING: at /home/teemhu/mcu/has/topas/mm/page_alloc.c:2012
__alloc_pages_nodemask+0x444/0x650()
This is due to the following check in __alloc_pages_slowpath():
if (order >= MAX_ORDER) {
WARN_ON_ONCE(!(gfp_mask & __GFP_NOWARN));
return NULL;
}
Because MAX_ORDER is 11, only memory chunks of size (PAGE_SIZE <<
MAX_ORDER_NR_PAGES) = 4Mb can be allocated.
Apparently this topic has come up when using the OMAP DSS already:
http://www.spinics.net/lists/linux-omap/msg08124.html
Another user has asked this question on the linuxfb-dev mailing list in
October 2010, but did not receive an answer:
http://www.spinics.net/lists/linux-fbdev/msg01745.html
So, would increasing MAX_ORDER in order to allow bigger memory chunks to
be allocated via dma_alloc_writecombine() be acceptable?
If not, can anybody give me some advice how to do the memory allocation
for the framebuffer memory instead in order to circumvent the problem?
CU
Michael.
next reply other threads:[~2011-04-29 12:50 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-04-29 12:50 Michael Hunold [this message]
2011-04-29 14:27 ` dma_alloc_writecombine() and MAX_ORDER Russell King - ARM Linux
2011-05-03 6:25 ` Michael Hunold
2011-05-03 8:44 ` Russell King - ARM Linux
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=4DBAB41D.7030705@linuxtv.org \
--to=hunold@linuxtv.org \
--cc=linux-arm-kernel@lists.infradead.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.