> > The ARM SMMU refers to these as "stream IDs", as that's the architected name
> > that appears in all the hardware documentation. If "swgroup" is the term
> > used
> > in the hardware documentation I think it makes sense to stick with it, as
> > long
> > as there's a description in the binding document that points out what an
> > "swgroup" is. If there's a common term that both binding documents could
> > refer
> > to to define what stream-id/swgroup are, that would be nice.
>
> Sounds like:
>
> stream id == memory client id (part of the binding)
> context id == address space id (internal to the driver)
Good explanation. This would be helpful when I read ARM SMMU TRM;)
> > There are a few other differences in approach with the current ARM SMMU
> > binding:
> > Documentation/devicetree/bindings/iommu/arm,smmu.txt
> >
> > We should probably begin to look for commonality such that the next iommu
> > device that gets a binding is closer to a generic iommu class binding.
I think that now I got the "mmu-masters".
- mmu-masters : A list of phandles to device nodes representing bus
masters for which the SMMU can provide a translation
and their corresponding StreamIDs (see example below).
Each device node linked from this list must have a
"#stream-id-cells" property, indicating the number of
StreamIDs associated with it.
If I apply this to Tegra, this would be:
host1x {
#swgroup-id-cells = <1>;
gr3d {
#swgroup-id-cells = <2>;
};
};
smmu: iommu {
compatible = "nvidia,tegra114-smmu", "nvidia,tegra30-smmu";
reg = <0x70019010 0x02c>,
<0x700191f0 0x010>,
<0x70019228 0x074>;
.......
mmu-masters = <&host1x TEGRA_SWGROUP_HC>,
<&mpe TEGRA_SWGROUP_MPE>,
..........
<&gr3d TEGRA_SWGROUP_NV TEGRA_SWGROUP_NV2>;
};
>From consistency POV, this may look better. Also if "stream-id-cells",
"mmu-masters" is defined as IOMMU standard tag, it would be more
easier. Otherwise, I may need to stick to "swgroup-id-cells".
> > > Assuming "swgroup" is "memory client ID", why can't the driver just
> > > create a list/... of known swgroups at runtime, based on the swgroup
> > > values that each device uses, which would presumably be either
> > > hard-coded in the client device's driver, or represented in the DT smmu
> > > property's "iommu specifier" value.
> >
> > Assuming that the swgroup values of IP block instances are static, that
> > sounds
> > like the ARM SMMU binding approach. Are the IDs static, or can they be
> > assigned
> > at runtime?
>
> The only valid case I can think of for dynamic IDs is for hotpluggable
> devices sitting being a form of host controller (e.g. PCIe). In that case,
> the host controller should handle the ID assignment, which must remain
> static for the lifetime of a device.
In Tegra PCIe clients belong to one swgroup statically.
--
To unsubscribe from this list: send the line "unsubscribe linux-tegra" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
