From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755553AbaGINoc (ORCPT ); Wed, 9 Jul 2014 09:44:32 -0400 Received: from cam-admin0.cambridge.arm.com ([217.140.96.50]:39824 "EHLO cam-admin0.cambridge.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753076AbaGINoa (ORCPT ); Wed, 9 Jul 2014 09:44:30 -0400 Date: Wed, 9 Jul 2014 14:40:50 +0100 From: Will Deacon To: Thierry Reding Cc: Rob Herring , Pawel Moll , Mark Rutland , Ian Campbell , Kumar Gala , Stephen Warren , Arnd Bergmann , Joerg Roedel , Cho KyongHo , Grant Grundler , Dave P Martin , Marc Zyngier , Hiroshi Doyu , Olav Haugan , Varun Sethi , "devicetree@vger.kernel.org" , "iommu@lists.linux-foundation.org" , "linux-arm-kernel@lists.infradead.org" , "linux-tegra@vger.kernel.org" , "linux-kernel@vger.kernel.org" Subject: Re: [PATCH v4] devicetree: Add generic IOMMU device tree bindings Message-ID: <20140709134050.GN9485@arm.com> References: <1404487757-18829-1-git-send-email-thierry.reding@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1404487757-18829-1-git-send-email-thierry.reding@gmail.com> 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 Fri, Jul 04, 2014 at 04:29:17PM +0100, Thierry Reding wrote: > From: Thierry Reding > > This commit introduces a generic device tree binding for IOMMU devices. > Only a very minimal subset is described here, but it is enough to cover > the requirements of both the Exynos System MMU and Tegra SMMU as > discussed here: > > https://lkml.org/lkml/2014/4/27/346 > > Signed-off-by: Thierry Reding Acked-by: Will Deacon I would like to move the ARM SMMU driver over to this for 3.18, if possible. One use-case there is the ability to describe groups of masters behind a multi-master IOMMU but which must be part of the same domain (i.e. an iommu_group). This is useful for presenting devices to a guest with a virtual SMMU, where the physical devices share a stage-2 context. With your binding, does this simply mean determining the set of master IDs in the group, then describing the complete set for each master? Will