From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933711AbbBCHpc (ORCPT ); Tue, 3 Feb 2015 02:45:32 -0500 Received: from mail-wi0-f180.google.com ([209.85.212.180]:40212 "EHLO mail-wi0-f180.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S933684AbbBCHpX (ORCPT ); Tue, 3 Feb 2015 02:45:23 -0500 Date: Tue, 3 Feb 2015 08:46:43 +0100 From: Daniel Vetter To: Russell King - ARM Linux Cc: Rob Clark , Sumit Semwal , LKML , "linux-media@vger.kernel.org" , DRI mailing list , Linaro MM SIG Mailman List , "linux-arm-kernel@lists.infradead.org" , "linux-mm@kvack.org" , Linaro Kernel Mailman List , Tomasz Stanislawski , Robin Murphy , Marek Szyprowski , Daniel Vetter Subject: Re: [RFCv3 2/2] dma-buf: add helpers for sharing attacher constraints with dma-parms Message-ID: <20150203074643.GE14009@phenom.ffwll.local> Mail-Followup-To: Russell King - ARM Linux , Rob Clark , Sumit Semwal , LKML , "linux-media@vger.kernel.org" , DRI mailing list , Linaro MM SIG Mailman List , "linux-arm-kernel@lists.infradead.org" , "linux-mm@kvack.org" , Linaro Kernel Mailman List , Tomasz Stanislawski , Robin Murphy , Marek Szyprowski References: <1422347154-15258-2-git-send-email-sumit.semwal@linaro.org> <20150129143908.GA26493@n2100.arm.linux.org.uk> <20150129154718.GB26493@n2100.arm.linux.org.uk> <20150129192610.GE26493@n2100.arm.linux.org.uk> <20150202165405.GX14009@phenom.ffwll.local> <20150202214616.GI8656@n2100.arm.linux.org.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150202214616.GI8656@n2100.arm.linux.org.uk> X-Operating-System: Linux phenom 3.16-2-amd64 User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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 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 From mboxrd@z Thu Jan 1 00:00:00 1970 Return-path: Received: from mail-we0-f172.google.com ([74.125.82.172]:60337 "EHLO mail-we0-f172.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S933618AbbBCHpX (ORCPT ); Tue, 3 Feb 2015 02:45:23 -0500 Received: by mail-we0-f172.google.com with SMTP id q59so43253668wes.3 for ; Mon, 02 Feb 2015 23:45:22 -0800 (PST) Date: Tue, 3 Feb 2015 08:46:43 +0100 From: Daniel Vetter To: Russell King - ARM Linux Cc: Rob Clark , Sumit Semwal , LKML , "linux-media@vger.kernel.org" , DRI mailing list , Linaro MM SIG Mailman List , "linux-arm-kernel@lists.infradead.org" , "linux-mm@kvack.org" , Linaro Kernel Mailman List , Tomasz Stanislawski , Robin Murphy , Marek Szyprowski , Daniel Vetter Subject: Re: [RFCv3 2/2] dma-buf: add helpers for sharing attacher constraints with dma-parms Message-ID: <20150203074643.GE14009@phenom.ffwll.local> References: <1422347154-15258-2-git-send-email-sumit.semwal@linaro.org> <20150129143908.GA26493@n2100.arm.linux.org.uk> <20150129154718.GB26493@n2100.arm.linux.org.uk> <20150129192610.GE26493@n2100.arm.linux.org.uk> <20150202165405.GX14009@phenom.ffwll.local> <20150202214616.GI8656@n2100.arm.linux.org.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150202214616.GI8656@n2100.arm.linux.org.uk> Sender: linux-media-owner@vger.kernel.org List-ID: 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 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 From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wg0-f44.google.com (mail-wg0-f44.google.com [74.125.82.44]) by kanga.kvack.org (Postfix) with ESMTP id AA0F96B0038 for ; Tue, 3 Feb 2015 02:45:24 -0500 (EST) Received: by mail-wg0-f44.google.com with SMTP id z12so43054864wgg.3 for ; Mon, 02 Feb 2015 23:45:24 -0800 (PST) Received: from mail-wi0-x22d.google.com (mail-wi0-x22d.google.com. [2a00:1450:400c:c05::22d]) by mx.google.com with ESMTPS id bl3si27529094wib.29.2015.02.02.23.45.22 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 02 Feb 2015 23:45:22 -0800 (PST) Received: by mail-wi0-f173.google.com with SMTP id r20so22087681wiv.0 for ; Mon, 02 Feb 2015 23:45:22 -0800 (PST) Date: Tue, 3 Feb 2015 08:46:43 +0100 From: Daniel Vetter Subject: Re: [RFCv3 2/2] dma-buf: add helpers for sharing attacher constraints with dma-parms Message-ID: <20150203074643.GE14009@phenom.ffwll.local> References: <1422347154-15258-2-git-send-email-sumit.semwal@linaro.org> <20150129143908.GA26493@n2100.arm.linux.org.uk> <20150129154718.GB26493@n2100.arm.linux.org.uk> <20150129192610.GE26493@n2100.arm.linux.org.uk> <20150202165405.GX14009@phenom.ffwll.local> <20150202214616.GI8656@n2100.arm.linux.org.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150202214616.GI8656@n2100.arm.linux.org.uk> Sender: owner-linux-mm@kvack.org List-ID: To: Russell King - ARM Linux Cc: Rob Clark , Sumit Semwal , LKML , "linux-media@vger.kernel.org" , DRI mailing list , Linaro MM SIG Mailman List , "linux-arm-kernel@lists.infradead.org" , "linux-mm@kvack.org" , Linaro Kernel Mailman List , Tomasz Stanislawski , Robin Murphy , Marek Szyprowski , Daniel Vetter 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 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, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 From: daniel@ffwll.ch (Daniel Vetter) Date: Tue, 3 Feb 2015 08:46:43 +0100 Subject: [RFCv3 2/2] dma-buf: add helpers for sharing attacher constraints with dma-parms In-Reply-To: <20150202214616.GI8656@n2100.arm.linux.org.uk> References: <1422347154-15258-2-git-send-email-sumit.semwal@linaro.org> <20150129143908.GA26493@n2100.arm.linux.org.uk> <20150129154718.GB26493@n2100.arm.linux.org.uk> <20150129192610.GE26493@n2100.arm.linux.org.uk> <20150202165405.GX14009@phenom.ffwll.local> <20150202214616.GI8656@n2100.arm.linux.org.uk> Message-ID: <20150203074643.GE14009@phenom.ffwll.local> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org 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 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