From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wg0-f49.google.com (mail-wg0-f49.google.com [74.125.82.49]) by kanga.kvack.org (Postfix) with ESMTP id 8A4CE6B0038 for ; Mon, 2 Feb 2015 16:46:36 -0500 (EST) Received: by mail-wg0-f49.google.com with SMTP id k14so41250866wgh.8 for ; Mon, 02 Feb 2015 13:46:35 -0800 (PST) Received: from pandora.arm.linux.org.uk (pandora.arm.linux.org.uk. [2001:4d48:ad52:3201:214:fdff:fe10:1be6]) by mx.google.com with ESMTPS id gj5si25684394wib.57.2015.02.02.13.46.34 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Mon, 02 Feb 2015 13:46:34 -0800 (PST) Date: Mon, 2 Feb 2015 21:46:16 +0000 From: Russell King - ARM Linux Subject: Re: [RFCv3 2/2] dma-buf: add helpers for sharing attacher constraints with dma-parms Message-ID: <20150202214616.GI8656@n2100.arm.linux.org.uk> References: <1422347154-15258-1-git-send-email-sumit.semwal@linaro.org> <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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Sender: owner-linux-mm@kvack.org List-ID: To: Rob Clark Cc: 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 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. -- FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up according to speedtest.net. -- 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