Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S934009AbbBCQh7 (ORCPT ); Tue, 3 Feb 2015 11:37:59 -0500 Received: from mout.kundenserver.de ([212.227.17.13]:60872 "EHLO mout.kundenserver.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S933924AbbBCQh4 (ORCPT ); Tue, 3 Feb 2015 11:37:56 -0500 From: Arnd Bergmann To: linaro-kernel@lists.linaro.org Cc: Rob Clark , Russell King - ARM Linux , Tomasz Stanislawski , LKML , DRI mailing list , "linaro-mm-sig@lists.linaro.org" , "linux-mm@kvack.org" , Daniel Vetter , Robin Murphy , "linux-arm-kernel@lists.infradead.org" , "linux-media@vger.kernel.org" Subject: Re: [Linaro-mm-sig] [RFCv3 2/2] dma-buf: add helpers for sharing attacher constraints with dma-parms Date: Tue, 03 Feb 2015 17:36:59 +0100 Message-ID: <7233574.nKiRa7HnXU@wuerfel> User-Agent: KMail/4.11.5 (Linux/3.16.0-10-generic; KDE/4.11.5; x86_64; ; ) In-Reply-To: References: <1422347154-15258-1-git-send-email-sumit.semwal@linaro.org> <6906596.JU5vQoa1jV@wuerfel> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Provags-ID: V03:K0:RmbLj+upShy9qqw2u1CYBzF5SvazeeF6aOLLw5Z2Nt/rBHXZJEN RDfWyqVCeVqUp/LsNDNFHNARnnEUhsUM47N6Y/wdh/b5JOOq9f460Y4AKD7hQd5LoN3kCu9 PX/MX5F0mjAR1nozIZuZ+BiTZwJiLifU3aPHA82vLfMYlqHtZ8JhvtVnmr3Y0uOScI++n7h vwBbIzy68DZPge0TJ10aQ== X-UI-Out-Filterresults: notjunk:1; Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1363 Lines: 32 On Tuesday 03 February 2015 11:22:01 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. I think from the driver perspective, I'd view those two cases as identical. Not sure if Russell agrees with that. Arnd -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/