On Wed, Nov 20, 2013 at 10:31:11AM +0000, Will Deacon wrote: > On Tue, Nov 19, 2013 at 08:45:02PM +0000, Rob Herring wrote: > > On 11/19/2013 11:35 AM, Will Deacon wrote: > > > Adding Andreas and Rob for input on potential binding additions to the SMMU. > > > > The above proposal would be an incompatible change. However, I think we > > could still deal with a change in this binding at this stage. > > > > One way approach to handle this without changing the binding would be to > > scan the DT for all iommu's up front and create a list of all nodes and > > their iommu parent. The fact that the hierarchy is described in a way > > that doesn't fit Linux well is really a Linux implementation detail. > > > > If changing the binding, a simple approach would be to allow > > 'smmu-parent' to be a bus and/or device property and not just for > > chained iommu's. This could be a global or bus property that is > > inherited. Like interrupt-parent, you would have to deal with the parent > > being itself. Also, perhaps iommu-parent would be a better name. In any > > case, I'd like to see this all be a generic iommu binding. > > I like that idea. I've recently been toying with removing the chained IOMMU > support, since I don't think anybody is using it who is interested in > mainline. However, making it more general sounds like a better idea. > > One potential issue is that I think the nvidia guys want to describe masters > that master via multiple SMMUs (which I believe was the motivation for > moving the stream-ids out into the master nodes, rather than keeping them in > the SMMU). Again, that's not something we can easily add to the arm-smmu, > because the incoming stream-ids are a property of the SMMU node. If I remember correctly, one of the reasons for the proposal was also that the interrupt-parent property turned out to be insufficient for some use-cases, which lead to Grant's proposal of the new interrupts- extended property. Since that comparison has already been drawn, I think we can agree that both are used in similar ways. Therefore we should consider what we've learned from interrupt-parent when designing this generic IOMMU binding to avoid having to introduce iommu-extended at some point. > So the question is: do we actually need to describe masters that master > through multiple SMMUs as a single node in the devicetree? I would think so, yes. The alternative would be to have several nodes that describe the same device, and that conflicts on a different level. Perhaps it could be done by having separate sub-nodes that each use a different IOMMU, but that sounds like a much grosser solution. That pretty much boils down to interrupt-parent/interrupt-map. Thierry
Attachment:
pgpYSxAgcaHBA.pgp
Description: PGP signature
