Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751873AbaFDVA7 (ORCPT ); Wed, 4 Jun 2014 17:00:59 -0400 Received: from mail-wi0-f174.google.com ([209.85.212.174]:54052 "EHLO mail-wi0-f174.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751787AbaFDVA4 (ORCPT ); Wed, 4 Jun 2014 17:00:56 -0400 Date: Wed, 4 Jun 2014 23:00:52 +0200 From: Thierry Reding To: Will Deacon Cc: Dave P Martin , Arnd Bergmann , "linux-arm-kernel@lists.infradead.org" , Mark Rutland , "devicetree@vger.kernel.org" , "linux-samsung-soc@vger.kernel.org" , Pawel Moll , Ian Campbell , Grant Grundler , Joerg Roedel , Stephen Warren , "linux-kernel@vger.kernel.org" , Marc Zyngier , Linux IOMMU , Rob Herring , Kumar Gala , "linux-tegra@vger.kernel.org" , Cho KyongHo , Hiroshi Doyu Subject: Re: [PATCH v2] devicetree: Add generic IOMMU device tree bindings Message-ID: <20140604210045.GB18710@mithrandir> 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> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="dTy3Mrz/UPE2dbVg" Content-Disposition: inline In-Reply-To: <20140604164132.GF6644@arm.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 --dTy3Mrz/UPE2dbVg Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Jun 04, 2014 at 05:41:32PM +0100, Will Deacon wrote: > On Wed, Jun 04, 2014 at 03:35:10PM +0100, Thierry Reding wrote: > > On Mon, Jun 02, 2014 at 11:41:04AM +0100, Dave Martin wrote: > > > In the strictest sense, no. > > >=20 > > > But for a large set of sane configurations, this probably works. > > >=20 > > > Small sets of randomly-assigned IDs can just be enumerated one by one. > > >=20 > > > We wouldn't be able to describe folding and bit shuffling, but we > > > probably don't want to encourage that anyway. > >=20 > > I'm having some difficulty understanding this. You make it sound like > > there's a fairly arbitrary number of IDs that the SMMU can handle. So > > how is the mapping to devices defined? If you say encourage that does > > make it sound like the assignment of IDs is purely defined by some > > mechanism in software rather than in hardware. Or they are more or less > > randomly picked by someone. If that's the case, is that not something > > that should be dynamically allocated by the kernel rather than put into > > the device tree? >=20 > 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. >=20 > The StreamID -> ContextID mapping is dynamic and controlled by software. > The Master -> StreamIDs mapping is fixed in the hardware. Okay, that sounds similar to what the Tegra SMMU does. The naming is slightly differently. "Master" is called "memory client", "StreamID" would be "SWGROUP" and "ContextID" I guess would map to what's called an "ASID" (Address Space ID) on Tegra. I'm not sure about the amount of leverage that we have to encourage the mappings that we think are easy to describe in DT and discourage those that we don't want. Last time I checked we were still playing catch up rather than being able to give recommendations to hardware engineers about what will result in sane DT content and what won't. Irrespective of the above, I still think that a generic binding based on an #iommu-cells and iommus property gives us the most flexibility. For easy cases, most of which are listed in the current proposal could easily be dealt with in convenience helpers. For the more complex cases drivers for those IOMMUs can define a specifier that make sense for the mappings they need to be able to describe. Also we're talking about a generic IOMMU binding here. That means that if some hardware comes along that's not "generic" and doesn't fit into the constraints set by this binding, then we still have the option of defining a completely different one for that particular case. Thierry --dTy3Mrz/UPE2dbVg Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iQIcBAEBAgAGBQJTj4j9AAoJEN0jrNd/PrOhthkP/3PIBa/lJxjOHVGl6FhiC0t4 IbjaZ7cTtGPpmnAzVVJK6CW75XM4UUXdmSXefh/8qMFGmhUT+Y8x6lCgT8yTh7hG VAp2qAAeZNBzUjeDDfbMO+insDB+qqYkZs5KmG/y9gMuBHxkpP0rIgx3xsCDXtGs /8F+X/+ca06tqUW6zlCzVMvQoy3r8PU+UxyjztUz4qa6L1F5OeI6SU8+S13lsmE0 RzWvUbDtehfuDvEr98JHcSjd+Mge7Ewj1G3637dIdO3nbdlOzwzrPgG6Om9gdExN Addh2mQ0DxUPVv0gDyNDB0UP5RdUsPUjILrERW1wxB2bLynMjcw7gtstvRRmEmTe 99ZcuEe7d/SddSR0dCdmscYnI3oWw3b5nnU/KzcdaVAEtJyXtYAuJPZFRfvOA+JC t7D8Q5Ic037iW8Fsj17UfxqlgsoHVrfdhVGYZJ/nwsRtU6t4o/RQ9YIBFl3kGU6L cNzhHOhbKQssxPIQW0PdxPxdw+Ud3q1x4XI947eh0j2BRFnNBINo1ryOKkH2+uqc 0xIf+W6IrNyuaJZVHbmmWuS7CKH9npNXOly+5YPKRqiIwxd4rkBZrvsEjm9sSbSX pNp/p9K3a9ixsFIOxKaUxhH+gSQZs2GwXQZ4c7nuCWBgYPvB5CMw7RA2/aWVXpuF RrtSvQiLY8FTipVjQHEQ =pRJk -----END PGP SIGNATURE----- --dTy3Mrz/UPE2dbVg-- -- 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/