From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wi0-f169.google.com (mail-wi0-f169.google.com [209.85.212.169]) by kanga.kvack.org (Postfix) with ESMTP id 2590D6B0038 for ; Tue, 3 Feb 2015 12:02:02 -0500 (EST) Received: by mail-wi0-f169.google.com with SMTP id h11so23931200wiw.0 for ; Tue, 03 Feb 2015 09:02:01 -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 fa1si7464851wjd.150.2015.02.03.09.01.59 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Tue, 03 Feb 2015 09:02:00 -0800 (PST) Date: Tue, 3 Feb 2015 17:01:46 +0000 From: Russell King - ARM Linux Subject: Re: [Linaro-mm-sig] [RFCv3 2/2] dma-buf: add helpers for sharing attacher constraints with dma-parms Message-ID: <20150203170146.GX8656@n2100.arm.linux.org.uk> References: <1422347154-15258-1-git-send-email-sumit.semwal@linaro.org> <3783167.LiVXgA35gN@wuerfel> <20150203155404.GV8656@n2100.arm.linux.org.uk> <6906596.JU5vQoa1jV@wuerfel> 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: Arnd Bergmann , "linaro-mm-sig@lists.linaro.org" , Linaro Kernel Mailman List , Robin Murphy , LKML , DRI mailing list , "linux-mm@kvack.org" , Daniel Vetter , Tomasz Stanislawski , "linux-arm-kernel@lists.infradead.org" , "linux-media@vger.kernel.org" On Tue, Feb 03, 2015 at 11:22:01AM -0500, Rob Clark wrote: > On Tue, Feb 3, 2015 at 11:12 AM, Arnd Bergmann wrote: > > I agree for the case you are describing here. From what I understood > > from Rob was that he is looking at something more like: > > > > Fig 3 > > CPU--L1cache--L2cache--Memory--IOMMU-----device > > > > where the IOMMU controls one or more contexts per device, and is > > shared across GPU and non-GPU devices. Here, we need to use the > > dmap-mapping interface to set up the IO page table for any device > > that is unable to address all of system RAM, and we can use it > > for purposes like isolation of the devices. There are also cases > > where using the IOMMU is not optional. > > > Actually, just to clarify, the IOMMU instance is specific to the GPU.. > not shared with other devices. Otherwise managing multiple contexts > would go quite badly.. > > But other devices have their own instance of the same IOMMU.. so same > driver could be used. Okay, so that is my Fig.2 case, and we don't have to worry about Fig.3. One thing I forgot in Fig.1/2 which my original did have were to mark the system MMU as optional. (Think an ARM64 with SMMU into a 32-bit peripheral bus.) Do we support stacked MMUs in the DMA API? We may need to if we keep IOMMUs in the DMA API. -- 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