[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <1264574987.3601.171.camel@pasglop>
Date: Wed, 27 Jan 2010 17:49:47 +1100
From: Benjamin Herrenschmidt <benh@...nel.crashing.org>
To: FUJITA Tomonori <fujita.tomonori@....ntt.co.jp>
Cc: adharmap@...eaurora.org, linux-kernel@...r.kernel.org,
linux-arm-msm@...r.kernel.org, dwalker@...eaurora.org,
arnd@...db.de, akpm@...ux-foundation.org, mingo@...e.hu,
joerg.roedel@....com, maciej.sosnowski@...el.com,
dan.j.williams@...el.com, beckyb@...nel.crashing.org,
yanghy@...fujitsu.com, linux-arch@...r.kernel.org,
adharmap@...cinc.com
Subject: Re: [RFC PATCH] dma: Add barrierless dma mapping/unmapping api
On Wed, 2010-01-27 at 14:19 +0900, FUJITA Tomonori wrote:
> > I somehow missed your post, my apologies. Agreed that
> dma_map/unmap_sg
> > would be the correct api to use here, however they still call the
> > dmac_.*_range to map buffers.
>
> Hmm, sounds like arm's implementation issue. dma_map_sg API doesn't
> require such. dma_map_sg API gives what you want, do a sync only after
> mapping the last buffer.
dmac_* appears to be ARM's low-level ops for cache flushing on
non-coherent DMA, so it's really down to arch stuff here and how ARM
implements dma_[un]map_sg() and we keep a sane global driver API.
Cheers,
Ben.
--
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