On Wed, 20 Nov 2013 21:22:39 +0100
Stephen Warren <swarren@xxxxxxxxxxxxx> wrote:
...
> >> In PATCHv5[2], we took the following DT binding where multiple cell
> >> properties seem to work ok.
> >>
> >> smmu_a: iommu@xxxxxxxx {
> >> #iommu-cells = <2>;
> >> ....
> >> };
> >>
> >> smmu_b: iommu@xxxxxxxx {
> >> #iommu-cells = <3>;
> >> ....
> >> };
> >>
> >> device_a {
> >> iommus = <&smmu_a param1 param2>,
> >> <&smmu_b param1 param2 param3>;
> >> };
> >>
> >> This can describe the relation between a device and an iommu
> >> independently. The number of params needed for each IOMMU can be
> >> sepcified by #iommu-cells in its iommu entry.
> >>
> >> device_a <-> smmu_a, needs 2 params for a device
> >> device_a <-> smmu_b, needs 3 params for a device
> >>
> >> For example, "smmu_a" can be an bus level global IOMMU where all child
> >> devices can be an master of "smmu_a", and "smmu_b" is a local IOMMU
> >> only for "device_a".
> >>
> >> "memory controller"---"smmu_a"---bus--+--"smmu_b"--"device_a"
> >> |
> >> |
> >> +--"device_b"
> >
> > I think the above binding would be the correct way to describe things
> > if you have 1 device connected to 2 IOMMUs (directly rather than
> > chained). IIUC, that is something you have on tegra?
>
> I'm not sure that we do, but perhaps; Hiroshi will have to answer.
> Certainly whenever I personally mentioned chained IOMMUs it was simply
> in the context of making sure the bindings allowed for any potential
> arbitrary HW configuration, not because I had specific knowledge of one
> that actually exists.
In tegra, IOMMUs are chained in a way that:
- "device_a" run in "smmu_b"'s virtual address space.
- "device_a"'s requesting address is transted into "smmu_a"'s virtual
address via "smmu_b".
- This "smmu_a"'s virtual address is translated into physical address
via "smmu_a".
"smmu_a" and "smmu_b" are different driver although we haven't
converted "smmu_b" as the standard IOMMU API yet.
> > For the topology above where you are chaining iommu's, I think
> > something like this is more accurately describing the hierarchy:
> >
> > smmu_b: iommu@xxxxxxxx {
> > #iommu-cells = <3>;
> > iommus = <&smmu_a param1 param2>;
> > ....
> > };
> > device_a {
> > iommus = <&smmu_b param1 param2 param3>;
> > };
This describes the dependency between IOMMUs in Tegra. We can populate
"smmu_a" always earlier than "smmu_b". Those dependency/hierarchy can
be stored in IOMMU class(global IOMMU list), which Thierry suggested.
--
To unsubscribe from this list: send the line "unsubscribe linux-tegra" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
