Date:	Tue, 3 Feb 2015 08:46:43 +0100
From:	Daniel Vetter <daniel@...ll.ch>
To:	Russell King - ARM Linux <linux@....linux.org.uk>
Cc:	Rob Clark <robdclark@...il.com>,
	Sumit Semwal <sumit.semwal@...aro.org>,
	LKML <linux-kernel@...r.kernel.org>,
	"linux-media@...r.kernel.org" <linux-media@...r.kernel.org>,
	DRI mailing list <dri-devel@...ts.freedesktop.org>,
	Linaro MM SIG Mailman List <linaro-mm-sig@...ts.linaro.org>,
	"linux-arm-kernel@...ts.infradead.org" 
	<linux-arm-kernel@...ts.infradead.org>,
	"linux-mm@...ck.org" <linux-mm@...ck.org>,
	Linaro Kernel Mailman List <linaro-kernel@...ts.linaro.org>,
	Tomasz Stanislawski <stanislawski.tomasz@...glemail.com>,
	Robin Murphy <robin.murphy@....com>,
	Marek Szyprowski <m.szyprowski@...sung.com>,
	Daniel Vetter <daniel@...ll.ch>
Subject: Re: [RFCv3 2/2] dma-buf: add helpers for sharing attacher
 constraints with dma-parms

On Mon, Feb 02, 2015 at 09:46:16PM +0000, Russell King - ARM Linux wrote:
> On Mon, Feb 02, 2015 at 03:30:21PM -0500, Rob Clark wrote:
> > On Mon, Feb 2, 2015 at 11:54 AM, Daniel Vetter <daniel@...ll.ch> wrote:
> > >> My initial thought is for dma-buf to not try to prevent something than
> > >> an exporter can actually do.. I think the scenario you describe could
> > >> be handled by two sg-lists, if the exporter was clever enough.
> > >
> > > That's already needed, each attachment has it's own sg-list. After all
> > > there's no array of dma_addr_t in the sg tables, so you can't use one sg
> > > for more than one mapping. And due to different iommu different devices
> > > can easily end up with different addresses.
> > 
> > 
> > Well, to be fair it may not be explicitly stated, but currently one
> > should assume the dma_addr_t's in the dmabuf sglist are bogus.  With
> > gpu's that implement per-process/context page tables, I'm not really
> > sure that there is a sane way to actually do anything else..
> 
> That's incorrect - and goes dead against the design of scatterlists.
> 
> Not only that, but it is entirely possible that you may get handed
> memory via dmabufs for which there are no struct page's associated
> with that memory - think about display systems which have their own
> video memory which is accessible to the GPU, but it isn't system
> memory.
> 
> In those circumstances, you have to use the dma_addr_t's and not the
> pages.

Yeah exactly. At least with i915 we'd really want to be able to share
stolen memory in some cases, and since that's stolen there's no struct
pages for them. On top of that any cpu access is also blocked to that
range in the memory controller, so the dma_addr_t is really the _only_
thing you can use to get at those memory ranges. And afaik the camera pipe
on intel soc can get there - unfortunately that one doesn't have an
upstream driver :(

And just to clarify: All current dma-buf exporter that I've seen implement
the sg mapping correctly and _do_ map the sg table into device address
space with dma_map_sg. In other words: The dma_addr_t are all valid, it's
just that e.g. with ttm no one has bothered to teach ttm a dma-buf
correctly. The internal abstraction is all there, ttm-internal buffer
object interface match what dma-buf exposes fairly closes (hey I didn't do
shit when designing those interfaces ;-)
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
--
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