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 02:20:51PM +0100, Will Deacon wrote:
> 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.

Okay, in that case perhaps some sort of generic binding should mandate
the phandle, even for systems that only have a single one. I suspect a
generic variant of smmu-parent (iommu-parent?) would also be useful to
describe setups with cascaded IOMMUs.

Thierry

Attachment: pgpbJr3yrrlL4.pgp
Description: PGP signature


[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