Hi Mark,
Sorry for the spam if you get this message twice. This is pretty embarrassing
but I've just switched mail providers after ProtonMail messed up yesterday and
it looks like my new one defaulted to sending HTML messages even though I only
typed plaintext. This shouldn't have happened in the first place but it
certainly shouldn't happen again now :-(
> On 21. Mar 2021, at 17:00, Mark Kettenis <mark.kette...@xs4all.nl> wrote:
>
> I don't think the first option is going to work for PCIe. PCIe
> devices will have to use "iommu-map" properties to map PCI devices to
> the right iommu, and the currently implementation seems to assume that
> #iommu-cells = <1>. The devictree binding[1] doesn't explicitly state
> that it relies on #iommu-cells = <1>, but it isn't clear how the
> rid-base to iommu-base mapping mechanism would work when that isn't
> the case.
>
> Now the PCIe DARTs are simpler and seem to have only one "instance"
> per DART. So if we keep #iommu-cells = <1> for those, you'd still be
> fine using the first approach.
Good point, I guess that only leaves option two for now then.
Having some DARTs use cells = <1> and others <2> sounds confusing to me.
>
> As I mentioned before, not all DARTs support the full 32-bit aperture.
> In particular the PCIe DARTs support a smaller address-space. It is
> not clear whether this is a restriction of the PCIe host controller or
> the DART, but the Apple Device Tree has "vm-base" and "vm-size"
> properties that encode the base address and size of the aperture.
> These single-cell properties which is probably why for the USB DARTs
> only "vm-base" is given; since "vm-base" is 0, a 32-bit number
> wouldn't be able to encode the full aperture size. We could make them
> 64-bit numbers in the Linux device tree though and always be explicit
> about the size. Older Sun SPARC machines used a single "virtual-dma"
> property to encode the aperture. We could do someting similar. You
> would use this property to initialize domain->geometry.aperture_start
> and domain->geometry.aperture_end in diff 3/3 of this series.
>
> I think it would make sense to include this in this series, as this
> would make adding support for PCIe very easy, and PCIe gives you
> aupport for network (both wired and wireless) and the type-A USB ports
> on the mini.
Agreed, I'd ideally like to converge on a device tree binding
that won't have to change in the near future.
I've tried to use an address space larger than 32bit and that seems to
work for parts of the dwc3 controller but breaks for the xhci parts because
the upper lines don't seem to be connected there (e.g. if xhci tries to
use <0x1 0xffff0000> I get a fault for <0 0xffff0000>).
Looking at other iommu drivers I have found the following two similar
bindings:
qcom uses a ranges property with a 64bit address and 32 bit size [1]
apps_iommu: iommu@1e20000 {
...
ranges = <0 0x1e20000 0x40000>;
...
};
and tegra seems to support a dma-window property with 32bit address
and size [2]
smmu {
[...]
dma-window = <0 0x40000000>; /* IOVA start & length */
[...]
};
I believe there already is of_get_dma_window to handle parsing this
in the common iommu code [3] but I can't find any place using it.
It's a little bit more complex that we need since it allows to specify the
number of cells for both the address and the size but it should allow us to
express all possible configurations:
usb_dart {
[ ... ]
#dma-address-cells = <1>;
#dma-size-cells = <2>;
dma-window = <0 0x1 0x0>;
[ ... ]
};
pcie_dart {
[ ... ]
#dma-address-cells = <1>;
#dma-size-cells = <1>;
dma-window = <0x100000 0x3fe00000>;
[ ... ]
};
where #dma-address-cells and #dma-size-cells default to
#address-cells and #size-cells respectively if I understand
the code correctly. That way we could also just always use
a 64bit address and size in the DT, e.g.
pcie_dart {
[ ... ]
dma-window = <0 0x100000 0 0x3fe00000>;
[ ... ]
};
Best,
Sven
[1] Documentation/devicetree/bindings/iommu/qcom,iommu.txt
[2] Documentation/devicetree/bindings/iommu/nvidia,tegra30-smmu.txt
[3] drivers/iommu/of_iommu.c
