Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755231AbaFPP1r (ORCPT ); Mon, 16 Jun 2014 11:27:47 -0400 Received: from cam-admin0.cambridge.arm.com ([217.140.96.50]:52434 "EHLO cam-admin0.cambridge.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751007AbaFPP1p (ORCPT ); Mon, 16 Jun 2014 11:27:45 -0400 Date: Mon, 16 Jun 2014 16:27:39 +0100 From: Will Deacon To: Varun Sethi Cc: Thierry Reding , Mark Rutland , "devicetree@vger.kernel.org" , "linux-samsung-soc@vger.kernel.org" , Pawel Moll , Arnd Bergmann , Ian Campbell , Grant Grundler , Stephen Warren , "linux-kernel@vger.kernel.org" , Marc Zyngier , Linux IOMMU , Rob Herring , Kumar Gala , "linux-tegra@vger.kernel.org" , Cho KyongHo , Dave P Martin , "linux-arm-kernel@lists.infradead.org" , Stuart Yoder Subject: Re: [PATCH v2] devicetree: Add generic IOMMU device tree bindings Message-ID: <20140616152739.GS16758@arm.com> References: <1400877218-4113-1-git-send-email-thierry.reding@gmail.com> <4545972.cM7IP1qTXQ@wuerfel> <5288123.eXagyPAxNq@wuerfel> <20140602104104.GD3855@e103592.cambridge.arm.com> <20140604143509.GF28484@ulmo> <20140604164132.GF6644@arm.com> <07321368d15d4ad9928ebb83af87e401@DM2PR03MB479.namprd03.prod.outlook.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <07321368d15d4ad9928ebb83af87e401@DM2PR03MB479.namprd03.prod.outlook.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 Hi Varun, On Thu, Jun 05, 2014 at 08:10:19PM +0100, Varun Sethi wrote: > > The set of StreamIDs that can be generated by a master is fixed in the > > hardware. The SMMU can then be programmed to map these incoming IDs onto > > a context ID (or a set of context IDs), which are the IDs used internally > > by the SMMU to find the page tables etc. > > > > The StreamID -> ContextID mapping is dynamic and controlled by software. > > The Master -> StreamIDs mapping is fixed in the hardware. > The Master -> StreamIDs mapping may not always be fixed in the hardware. > At, least in our case we plan to program these via software. PCI devices > is one place where this mapping would have to be dynamic (based on the > topology i.e. if the devices are connected to a bridge etc). Also, we have > a hot plug device architecture where the stream ID is software > programmable. > > Other than that, based on the isolation requirements (iommu domain) > software programmability offers greater flexibility. For the sake of consistency, I'd really like to treat the master -> streamIDs mapping as fixed. If that means setting it once during boot in your case, then so be it (ideally in the firmware). That way, we just describe the fixed mapping to the kernel and the driver doesn't have to worry about changing the mapping, especially given that that's likely to be highly error-prone once the SMMU is in us. Do you have use-cases where you really need to change these mappings dynamically? Will -- 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/