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@xxxxxxxx> 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-media" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
