[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <201107051558.39344.arnd@arndb.de>
Date: Tue, 5 Jul 2011 15:58:39 +0200
From: Arnd Bergmann <arnd@...db.de>
To: linux-arm-kernel@...ts.infradead.org
Cc: "Russell King - ARM Linux" <linux@....linux.org.uk>,
Daniel Walker <dwalker@...eaurora.org>,
Jonathan Corbet <corbet@....net>, Mel Gorman <mel@....ul.ie>,
Chunsang Jeong <chunsang.jeong@...aro.org>,
Jesse Barker <jesse.barker@...aro.org>,
KAMEZAWA Hiroyuki <kamezawa.hiroyu@...fujitsu.com>,
linux-kernel@...r.kernel.org,
Michal Nazarewicz <mina86@...a86.com>,
linaro-mm-sig@...ts.linaro.org, linux-mm@...ck.org,
Kyungmin Park <kyungmin.park@...sung.com>,
Ankita Garg <ankita@...ibm.com>,
Andrew Morton <akpm@...ux-foundation.org>,
Marek Szyprowski <m.szyprowski@...sung.com>,
linux-media@...r.kernel.org
Subject: Re: [PATCH 6/8] drivers: add Contiguous Memory Allocator
On Tuesday 05 July 2011, Russell King - ARM Linux wrote:
> On Tue, Jul 05, 2011 at 02:27:44PM +0200, Arnd Bergmann wrote:
> > It's also a preexisting problem as far as I can tell, and it needs
> > to be solved in __dma_alloc for both cases, dma_alloc_from_contiguous
> > and __alloc_system_pages as introduced in patch 7.
>
> Which is now resolved in linux-next, and has been through this cycle
> as previously discussed.
>
> It's taken some time because the guy who tested the patch for me said
> he'd review other platforms but never did, so I've just about given up
> waiting and stuffed it in ready for the 3.1 merge window irrespective
> of anything else.
Ah, sorry I missed that patch on the mailing list, found it now in
your for-next branch.
If I'm reading your "ARM: DMA: steal memory for DMA coherent mappings"
correctly, the idea is to have a per-platform compile-time amount
of memory that is reserved purely for coherent allocations and
taking out of the buddy allocator, right?
As you say, this solves the problem for the non-CMA case, and does
not apply to CMA because the entire point of CMA is not to remove
the pages from the buddy allocator in order to preserve memory.
So with your patch getting merged, patch 7/8 obviously has both a
conflict and introduces a regression against the fix you did.
Consequently that patch needs to be redone in a way that fits on
top of your patch and avoids the double-mapping problem.
What about the rest? As I mentioned in private, adding invasive features
to core code is obviously not nice if it can be avoided, but my feeling
is that we can no longer claim that there is no need for this with so
much hardware relying on large contiguous memory ranges for DMA.
The patches have come a long way since the first version, especially
regarding the device driver interface and I think they are about as
good as it gets in that regard.
I do understand that without patch 7, there isn't a single architecture
using the feature, which is somewhat silly, but I'm also convinced
that other architectures will start using it, and that a solution for the
double mapping in the ways I mentioned in my previous mail is going
to happen. Probably not in 3.1 then, but we could put the patches into
-mm anyway until we get there.
Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists