From mboxrd@z Thu Jan 1 00:00:00 1970 From: Thierry Reding Subject: Re: [PATCH v2] devicetree: Add generic IOMMU device tree bindings Date: Wed, 4 Jun 2014 23:12:38 +0200 Message-ID: <20140604211237.GC18710@mithrandir> References: <1400877395-4235-1-git-send-email-thierry.reding@gmail.com> <538757B6.4010109@wwwdotorg.org> <20140530073006.GA24748@ulmo> <20140530112728.GB3949@e103592.cambridge.arm.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="VywGB/WGlW4DM4P8" Return-path: Content-Disposition: inline In-Reply-To: <20140530112728.GB3949@e103592.cambridge.arm.com> Sender: linux-samsung-soc-owner@vger.kernel.org To: Dave Martin Cc: Stephen Warren , Arnd Bergmann , Rob Herring , Pawel Moll , Mark Rutland , Ian Campbell , Kumar Gala , Cho KyongHo , Grant Grundler , Marc Zyngier , Will Deacon , Joerg Roedel , Hiroshi Doyu , "devicetree@vger.kernel.org" , "iommu@lists.linux-foundation.org" , "linux-arm-kernel@lists.infradead.org" , "linux-tegra@vger.kernel.org" , "linux-samsung-soc@vger.kernel.org" , "linux-kernel@vger.kernel.org" List-Id: devicetree@vger.kernel.org --VywGB/WGlW4DM4P8 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, May 30, 2014 at 12:27:28PM +0100, Dave Martin wrote: > On Fri, May 30, 2014 at 08:30:08AM +0100, Thierry Reding wrote: [...] > > Arnd, can you take another look at this binding and see if there's > > anything else missing? If not I'll go through the document again and > > update all #address-cells/#size-cells references with #iommu-cells as > > appropriate and submit v3. >=20 > How do you envisage propagation of the master ID bits downstream of the > IOMMU would be described? >=20 > We will definitely need a way to describe this for GICv3. How those > values are propagated is likely to vary between related SoCs and doesn't > feel like it should be baked into a driver, especially for the ARM SMMU > which may get reused in radically different SoC families from different > vendors. Well, we've had cases like these in the past (power sequences come to mind). Some concepts are just too difficult or unwieldy to be put into device tree. I think that this is one of them. > The most likely types of remapping are the adding of a base offset or > some extra bits to the ID -- because not all MSIs to the GIC will > necessarily pass through the IOMMU. It's also possible that we might > see ID squashing or folding in some systems. It can easily be argued that if the algorithm used to remap the ID varies, the compatibility of the device changes. Therefore I would expect any variant of the GICv3 that deviates from the "standard" mapping (if there is such a thing) to have its own compatible string. At that point there are two possibilities: a) handle the remapping in code hooked into the driver via matching of the compatible string or b) specifying a different specifier for each of these and keep the description in DT. From an implementation point of view, variant b) is likely going to be very similar to a), though (I'm thinking .of_xlate type of functions here). Thierry --VywGB/WGlW4DM4P8 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iQIcBAEBAgAGBQJTj4vFAAoJEN0jrNd/PrOheCAP/i+lBZElAIcRlK6s2zrZYOSX 92zTVfj0mb8G1wjEGuuFARffdwwjiiy6EvSMvFHelQr7eHdhBaWS1NnXDTArNeHe 1GXXRMG7v3uJaIY7FDIHWxloL+v6/8FOpiQD8oyXwnZRE7cUwp1wikYO34fwRURH KQ4TwBNFYe8wXku1gffSYLKIF5HeN0zd+36f2E+JmbzEJEcvjagRSDdfV03uj3KA lqzwHNuIqBzsUVBCg7SI5fInfstUOTo/yRqXA6KYNms0twy7xC5wbKi5K2MQhAl4 3xHrfwaC42Z6W2tXt8XGYRgS31V5nvq3Xg+sd/pr9v73jnwXzvyYNrlAuRBPvrPO UdKOpI8//EqU1+abQDpO0nZZtGEPYFqg7Rljz66gCav2faEn+44qZlAsQvDIzON3 1FyEQIbFEUd/2m/RGEMO+Dhk0M0cpkVlmYteSvuNNRK/nrzCldYH8ubhGF5lFOCr dYfZfXXRS8JT3jH1o+i4eSts/cDQr29h9rE/fqhOercD2vc6DQjzC8UHFNgO78yN ozBhBd1EyQ1McT5SROrTqY1VXHjOAsADfP5pW2fbdDCyBnX3mVznqHYx0G5CINf7 Ux1xscC6qGldF9+xFMTXJd8g5xAglPRZzXf9pP68ZJnxV+OJcuwsDixP3zcLIpMg UX+JzjNS4F7MccluPvrz =xLVK -----END PGP SIGNATURE----- --VywGB/WGlW4DM4P8--