Re: [PATCHv3 01/19] [HACK] of: dev_node has struct device pointer

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




On Fri, Oct 25, 2013 at 09:22:02AM +0100, Hiroshi Doyu wrote:
> Thierry Reding <thierry.reding@xxxxxxxxx> wrote @ Fri, 25 Oct 2013 09:56:55 +0200:
> 
> > I suspect that there will be enough differences between the various
> > IOMMU implementations that we won't be able to have a unified binding
> > (especially for how to associate devices with a particular virtual
> > address space), but perhaps that could be solved with something like an
> > .of_xlate() that IOMMU drivers implement, much like we've done with most
> > other subsystems too.
> > 
> > The binding for Tegra's IOMMU currently only uses the HW IDs (or a mask)
> > to put a device into a given address space, but I think that could be
> > easily extended to something like:
> > 
> > 	memory-clients = <&iommu MASK>;
> > 
> > Or similar. If other information is required, we could encode that into
> > a multi-cell specifier. Perhaps we could even leave away the phandle
> > since typically there will only be a single IOMMU in the system?
> > 
> > Does that sound reasonable? Hiroshi is much more familiar with IOMMUs,
> > so I'd like to get his opinion on the above as well.
> 
> I think that the above may be possible, but I'd like to listen from
> other IOMMU SOC maintainers.
> 
> A brief explanation for "memory-clients":
> 
> In tegra, every H/W has its own memory-client ID, and it can be
> associated to any address spaces. The above "memory-cilents" is used
> to indicate which ID a device has in DT. If the other SOC IOMMUs need
> this kind of "memory-clients", this would be standarized. Any comment?
> 
> At least arm-smmu seems to have the following. multiple IOMMUs can be
> handled with this.
> 
> 
> - smmu-parent   : When multiple SMMUs are chained together, this
>                   property can be used to provide a phandle to the
>                   parent SMMU (that is the next SMMU on the path going
>                   from the mmu-masters towards memory) node for this
>                   SMMU.

This property is for the case when IOMMUs are connected in series, which is
fairly horrendous. However, it is extremely common to have multiple IOMMU
instances within an Soc (Exynos SoCs have one IOMMU per device iirc), so
that certainly needs to be handled.

Will

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[Index of Archives]     [Device Tree Compilter]     [Device Tree Spec]     [Linux Driver Backports]     [Video for Linux]     [Linux USB Devel]     [Linux PCI Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Yosemite Backpacking]
  Powered by Linux