[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20160311111522.GA3450@infradead.org>
Date: Fri, 11 Mar 2016 03:15:22 -0800
From: Christoph Hellwig <hch@...radead.org>
To: Dan Williams <dan.j.williams@...el.com>
Cc: Christoph Hellwig <hch@...radead.org>,
Vinod Koul <vinod.koul@...el.com>,
linux-renesas-soc@...r.kernel.org,
"linux-arm-kernel@...ts.infradead.org"
<linux-arm-kernel@...ts.infradead.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"dmaengine@...r.kernel.org" <dmaengine@...r.kernel.org>,
iommu@...ts.linux-foundation.org, robin.murphy@....com,
Laurent Pinchart <laurent.pinchart@...asonboard.com>,
geert+renesas@...der.be, Linus Walleij <linus.walleij@...aro.org>,
Arnd Bergmann <arnd@...db.de>, linux-arch@...r.kernel.org
Subject: Re: [PATCH v5 3/9] dma-mapping: add dma_{map,unmap}_resource
On Thu, Mar 10, 2016 at 10:47:10PM -0800, Dan Williams wrote:
> I think it is confusing to use the dma_ prefix for this peer-to-peer
> mmio functionality. dma_addr_t is a device's view of host memory.
> Something like bus_addr_t bus_map_resource(). Doesn't this routine
> also need the source device in addition to the target device? The
> resource address is from the perspective of the host cpu, it may be a
> different address space in the view of two devices relative to each
> other.
Is it supposed to be per-mmio? It's in dma-mapping ops, and has dma
in the name, so I suspected it's for some form of peer dma. But given
that our dma APIs reuqire a struct page backing I have no idea how this
even supposed to work, and this little documentation blurb still doesn't
clear that up.
So for now I'd like to NAK this patch until the use case can be
explained clearly, and actually works.
Powered by blists - more mailing lists