From: Mark Kettenis <hidden> Date: 2021-03-21 16:01:38
Date: Sat, 20 Mar 2021 15:19:33 +0000
From: Sven Peter <redacted>
Hi,
After Hector's initial work [1] to bring up Linux on Apple's M1 it's time to
bring up more devices. Most peripherals connected to the SoC are behind a iommu
which Apple calls "Device Address Resolution Table", or DART for short [2].
Unfortunately, it only shares the name with PowerPC's DART.
Configuring this iommu is mandatory if these peripherals require DMA access.
This patchset implements initial support for this iommu. The hardware itself
uses a pagetable format that's very similar to the one already implement in
io-pgtable.c. There are some minor modifications, namely some details of the
PTE format and that there are always three pagetable levels, which I've
implement as a new format variant.
I have mainly tested this with the USB controller in device mode which is
compatible with Linux's dwc3 driver. Some custom PHY initialization (which is
not yet ready or fully understood) is required though to bring up the ports,
see e.g. my patches to our m1n1 bootloader [3,4]. If you want to test the same
setup you will probably need that branch for now and add the nodes from
the DT binding specification example to your device tree.
Even though each DART instances could support up to 16 devices usually only
a single device is actually connected. Different devices generally just use
an entirely separate DART instance with a seperate MMIO range, IRQ, etc.
I have just noticed today though that at least the USB DWC3 controller in host
mode uses *two* darts at the same time. I'm not sure yet which parts seem to
require which DART instance.
This means that we might need to support devices attached to two iommus
simultaneously and just create the same iova mappings. Currently this only
seems to be required for USB according to Apple's Device Tree.
I see two options for this and would like to get feedback before
I implement either one:
1) Change #iommu-cells = <1>; to #iommu-cells = <2>; and use the first cell
to identify the DART and the second one to identify the master.
The DART DT node would then also take two register ranges that would
correspond to the two DARTs. Both instances use the same IRQ and the
same clocks according to Apple's device tree and my experiments.
This would keep a single device node and the DART driver would then
simply map iovas in both DARTs if required.
2) Keep #iommu-cells as-is but support
iommus = <&usb_dart1a 1>, <&usb_dart1b 0>;
instead.
This would then require two devices nodes for the two DART instances and
some housekeeping in the DART driver to support mapping iovas in both
DARTs.
I believe omap-iommu.c supports this setup but I will have to read
more code to understand the details there and figure out how to implement
this in a sane way.
I currently prefer the first option but I don't understand enough details of
the iommu system to actually make an informed decision.
I'm obviously also open to more options :-)
Hi Sven,
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.
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.
Cheers,
Mark
[1] Documentation/devicetree/bindings/pci/pci-iommu.txt
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
From: Sven Peter <hidden> Date: 2021-03-21 17:30:44
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 [off-list ref] 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
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
From: Rob Herring <robh@kernel.org> Date: 2021-03-23 20:54:52
On Sun, Mar 21, 2021 at 05:00:50PM +0100, Mark Kettenis wrote:
quoted
Date: Sat, 20 Mar 2021 15:19:33 +0000
From: Sven Peter <redacted>
Hi,
After Hector's initial work [1] to bring up Linux on Apple's M1 it's time to
bring up more devices. Most peripherals connected to the SoC are behind a iommu
which Apple calls "Device Address Resolution Table", or DART for short [2].
Unfortunately, it only shares the name with PowerPC's DART.
Configuring this iommu is mandatory if these peripherals require DMA access.
This patchset implements initial support for this iommu. The hardware itself
uses a pagetable format that's very similar to the one already implement in
io-pgtable.c. There are some minor modifications, namely some details of the
PTE format and that there are always three pagetable levels, which I've
implement as a new format variant.
I have mainly tested this with the USB controller in device mode which is
compatible with Linux's dwc3 driver. Some custom PHY initialization (which is
not yet ready or fully understood) is required though to bring up the ports,
see e.g. my patches to our m1n1 bootloader [3,4]. If you want to test the same
setup you will probably need that branch for now and add the nodes from
the DT binding specification example to your device tree.
Even though each DART instances could support up to 16 devices usually only
a single device is actually connected. Different devices generally just use
an entirely separate DART instance with a seperate MMIO range, IRQ, etc.
I have just noticed today though that at least the USB DWC3 controller in host
mode uses *two* darts at the same time. I'm not sure yet which parts seem to
require which DART instance.
This means that we might need to support devices attached to two iommus
simultaneously and just create the same iova mappings. Currently this only
seems to be required for USB according to Apple's Device Tree.
I see two options for this and would like to get feedback before
I implement either one:
1) Change #iommu-cells = <1>; to #iommu-cells = <2>; and use the first cell
to identify the DART and the second one to identify the master.
The DART DT node would then also take two register ranges that would
correspond to the two DARTs. Both instances use the same IRQ and the
same clocks according to Apple's device tree and my experiments.
This would keep a single device node and the DART driver would then
simply map iovas in both DARTs if required.
2) Keep #iommu-cells as-is but support
iommus = <&usb_dart1a 1>, <&usb_dart1b 0>;
instead.
This would then require two devices nodes for the two DART instances and
some housekeeping in the DART driver to support mapping iovas in both
DARTs.
I believe omap-iommu.c supports this setup but I will have to read
more code to understand the details there and figure out how to implement
this in a sane way.
I currently prefer the first option but I don't understand enough details of
the iommu system to actually make an informed decision.
Please don't mix what does the h/w look like and what's easy to
implement in Linux's IOMMU subsytem. It's pretty clear (at least
from the description here) that option 2 reflects the h/w.
quoted
I'm obviously also open to more options :-)
Hi Sven,
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.
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.
From: Sven Peter <hidden> Date: 2021-03-25 07:55:10
On Tue, Mar 23, 2021, at 21:53, Rob Herring wrote:
On Sun, Mar 21, 2021 at 05:00:50PM +0100, Mark Kettenis wrote:
quoted
quoted
Date: Sat, 20 Mar 2021 15:19:33 +0000
From: Sven Peter <redacted>
I have just noticed today though that at least the USB DWC3 controller in host
mode uses *two* darts at the same time. I'm not sure yet which parts seem to
require which DART instance.
This means that we might need to support devices attached to two iommus
simultaneously and just create the same iova mappings. Currently this only
seems to be required for USB according to Apple's Device Tree.
I see two options for this and would like to get feedback before
I implement either one:
1) Change #iommu-cells = <1>; to #iommu-cells = <2>; and use the first cell
to identify the DART and the second one to identify the master.
The DART DT node would then also take two register ranges that would
correspond to the two DARTs. Both instances use the same IRQ and the
same clocks according to Apple's device tree and my experiments.
This would keep a single device node and the DART driver would then
simply map iovas in both DARTs if required.
2) Keep #iommu-cells as-is but support
iommus = <&usb_dart1a 1>, <&usb_dart1b 0>;
instead.
This would then require two devices nodes for the two DART instances and
some housekeeping in the DART driver to support mapping iovas in both
DARTs.
I believe omap-iommu.c supports this setup but I will have to read
more code to understand the details there and figure out how to implement
this in a sane way.
I currently prefer the first option but I don't understand enough details of
the iommu system to actually make an informed decision.
Please don't mix what does the h/w look like and what's easy to
implement in Linux's IOMMU subsytem. It's pretty clear (at least
from the description here) that option 2 reflects the h/w.
Good point, I'll keep that in mind and give option 2 a try.
quoted
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.
'dma-ranges' is what should be used here.
The iommu binding documentation [1] mentions that
The device tree node of the IOMMU device's parent bus must contain a valid
"dma-ranges" property that describes how the physical address space of the
IOMMU maps to memory. An empty "dma-ranges" property means that there is a
1:1 mapping from IOMMU to memory.
which, if I understand this correctly, means that the 'dma-ranges' for the
parent bus of the iommu should be empty since the DART hardware can see the
full physical address space with a 1:1 mapping.
The documentation also mentions that
When an "iommus" property is specified in a device tree node, the IOMMU
will be used for address translation. If a "dma-ranges" property exists
in the device's parent node it will be ignored.
which means that specifying a 'dma-ranges' in the parent bus of any devices
that use the iommu will just be ignored.
As a concrete example, the PCIe DART IOMMU only allows translations from iovas
within 0x00100000...0x3ff00000 to the entire physical address space (though
realistically it will only map to 16GB RAM starting at 0x800000000 on the M1).
I'm probably just confused or maybe the documentation is outdated but I don't
see how I could specify "this device can only use DMA addresses from
0x00100000...0x3ff00000 but can map these via the iommu to any physical
address" using 'dma-ranges'.
Could you maybe point me to the right direction or give me a small example?
That would help a lot!
Thanks,
Sven
[1] Documentation/devicetree/bindings/iommu/iommu.txt
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
From: Robin Murphy <robin.murphy@arm.com> Date: 2021-03-25 11:51:52
On 2021-03-25 07:53, Sven Peter wrote:
On Tue, Mar 23, 2021, at 21:53, Rob Herring wrote:
quoted
On Sun, Mar 21, 2021 at 05:00:50PM +0100, Mark Kettenis wrote:
quoted
quoted
Date: Sat, 20 Mar 2021 15:19:33 +0000
From: Sven Peter <redacted>
I have just noticed today though that at least the USB DWC3 controller in host
mode uses *two* darts at the same time. I'm not sure yet which parts seem to
require which DART instance.
This means that we might need to support devices attached to two iommus
simultaneously and just create the same iova mappings. Currently this only
seems to be required for USB according to Apple's Device Tree.
I see two options for this and would like to get feedback before
I implement either one:
1) Change #iommu-cells = <1>; to #iommu-cells = <2>; and use the first cell
to identify the DART and the second one to identify the master.
The DART DT node would then also take two register ranges that would
correspond to the two DARTs. Both instances use the same IRQ and the
same clocks according to Apple's device tree and my experiments.
This would keep a single device node and the DART driver would then
simply map iovas in both DARTs if required.
2) Keep #iommu-cells as-is but support
iommus = <&usb_dart1a 1>, <&usb_dart1b 0>;
instead.
This would then require two devices nodes for the two DART instances and
some housekeeping in the DART driver to support mapping iovas in both
DARTs.
I believe omap-iommu.c supports this setup but I will have to read
more code to understand the details there and figure out how to implement
this in a sane way.
I currently prefer the first option but I don't understand enough details of
the iommu system to actually make an informed decision.
Please don't mix what does the h/w look like and what's easy to
implement in Linux's IOMMU subsytem. It's pretty clear (at least
from the description here) that option 2 reflects the h/w.
Good point, I'll keep that in mind and give option 2 a try.
quoted
quoted
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.
'dma-ranges' is what should be used here.
The iommu binding documentation [1] mentions that
The device tree node of the IOMMU device's parent bus must contain a valid
"dma-ranges" property that describes how the physical address space of the
IOMMU maps to memory. An empty "dma-ranges" property means that there is a
1:1 mapping from IOMMU to memory.
which, if I understand this correctly, means that the 'dma-ranges' for the
parent bus of the iommu should be empty since the DART hardware can see the
full physical address space with a 1:1 mapping.
The documentation also mentions that
When an "iommus" property is specified in a device tree node, the IOMMU
will be used for address translation. If a "dma-ranges" property exists
in the device's parent node it will be ignored.
which means that specifying a 'dma-ranges' in the parent bus of any devices
that use the iommu will just be ignored.
I think that's just wrong and wants updating (or at least clarifying).
The high-level view now is that we use "dma-ranges" to describe
limitations imposed by a bridge or interconnect segment, and that can
certainly happen upstream of an IOMMU. As it happens, I've just recently
sent a patch for precisely that case[1].
I guess what it might have been trying to say is that "dma-ranges"
*does* become irrelevant in terms of constraining what physical memory
is usable for DMA, but that shouldn't imply that its meaning doesn't
just shift to a different purpose.
As a concrete example, the PCIe DART IOMMU only allows translations from iovas
within 0x00100000...0x3ff00000 to the entire physical address space (though
realistically it will only map to 16GB RAM starting at 0x800000000 on the M1).
I'm probably just confused or maybe the documentation is outdated but I don't
see how I could specify "this device can only use DMA addresses from
0x00100000...0x3ff00000 but can map these via the iommu to any physical
address" using 'dma-ranges'.
Could you maybe point me to the right direction or give me a small example?
That would help a lot!
From: Sven Peter <hidden> Date: 2021-03-25 20:50:21
On Thu, Mar 25, 2021, at 12:50, Robin Murphy wrote:
On 2021-03-25 07:53, Sven Peter wrote:
quoted
On Tue, Mar 23, 2021, at 21:53, Rob Herring wrote:
quoted
On Sun, Mar 21, 2021 at 05:00:50PM +0100, Mark Kettenis wrote:
quoted
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.
'dma-ranges' is what should be used here.
The iommu binding documentation [1] mentions that
The device tree node of the IOMMU device's parent bus must contain a valid
"dma-ranges" property that describes how the physical address space of the
IOMMU maps to memory. An empty "dma-ranges" property means that there is a
1:1 mapping from IOMMU to memory.
which, if I understand this correctly, means that the 'dma-ranges' for the
parent bus of the iommu should be empty since the DART hardware can see the
full physical address space with a 1:1 mapping.
The documentation also mentions that
When an "iommus" property is specified in a device tree node, the IOMMU
will be used for address translation. If a "dma-ranges" property exists
in the device's parent node it will be ignored.
which means that specifying a 'dma-ranges' in the parent bus of any devices
that use the iommu will just be ignored.
I think that's just wrong and wants updating (or at least clarifying).
The high-level view now is that we use "dma-ranges" to describe
limitations imposed by a bridge or interconnect segment, and that can
certainly happen upstream of an IOMMU. As it happens, I've just recently
sent a patch for precisely that case[1].
I guess what it might have been trying to say is that "dma-ranges"
*does* become irrelevant in terms of constraining what physical memory
is usable for DMA, but that shouldn't imply that its meaning doesn't
just shift to a different purpose.
Okay, now it makes sense then!
quoted
As a concrete example, the PCIe DART IOMMU only allows translations from iovas
within 0x00100000...0x3ff00000 to the entire physical address space (though
realistically it will only map to 16GB RAM starting at 0x800000000 on the M1).
I'm probably just confused or maybe the documentation is outdated but I don't
see how I could specify "this device can only use DMA addresses from
0x00100000...0x3ff00000 but can map these via the iommu to any physical
address" using 'dma-ranges'.
Could you maybe point me to the right direction or give me a small example?
That would help a lot!
PCI is easy, since it's already standard practice to use "dma-ranges" to
describe host bridge inbound windows. Even if the restriction is really
out in the host-side interconnect rather than in the bridge itself, to
all intents and purposes it's indistinguishable so can still be
described the same way.
The case of a standalone device having fewer address bits wired up than
both its output and the corresponding IOMMU input might expect is a
little more awkward, since that often *does* require adding an extra
level of "bus" to explicitly represent that interconnect link in the DT
model, e.g. [2].
Nice, thanks! That's exactly what I was looking for :)
Best,
Sven
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
From: Sven Peter <hidden> Date: 2021-03-27 15:35:01
Hi Robin,
On Thu, Mar 25, 2021, at 12:50, Robin Murphy wrote:
On 2021-03-25 07:53, Sven Peter wrote:
quoted
The iommu binding documentation [1] mentions that
The device tree node of the IOMMU device's parent bus must contain a valid
"dma-ranges" property that describes how the physical address space of the
IOMMU maps to memory. An empty "dma-ranges" property means that there is a
1:1 mapping from IOMMU to memory.
which, if I understand this correctly, means that the 'dma-ranges' for the
parent bus of the iommu should be empty since the DART hardware can see the
full physical address space with a 1:1 mapping.
The documentation also mentions that
When an "iommus" property is specified in a device tree node, the IOMMU
will be used for address translation. If a "dma-ranges" property exists
in the device's parent node it will be ignored.
which means that specifying a 'dma-ranges' in the parent bus of any devices
that use the iommu will just be ignored.
I think that's just wrong and wants updating (or at least clarifying).
The high-level view now is that we use "dma-ranges" to describe
limitations imposed by a bridge or interconnect segment, and that can
certainly happen upstream of an IOMMU. As it happens, I've just recently
sent a patch for precisely that case[1].
I guess what it might have been trying to say is that "dma-ranges"
*does* become irrelevant in terms of constraining what physical memory
is usable for DMA, but that shouldn't imply that its meaning doesn't
just shift to a different purpose.
Should I add a patch to clarify this paragraph for v2 or submit a separate
one-off patch? I'm not entirely sure about the process here but I could add
a Suggested-by: to the commit if that's fine with you.
Best,
Sven
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
On Thu, Mar 25, 2021 at 8:53 AM Sven Peter [off-list ref] wrote:
On Tue, Mar 23, 2021, at 21:53, Rob Herring wrote:
I'm probably just confused or maybe the documentation is outdated but I don't
see how I could specify "this device can only use DMA addresses from
0x00100000...0x3ff00000 but can map these via the iommu to any physical
address" using 'dma-ranges'.
It sounds like this is a holdover from the original powerpc iommu, which also
had a limited set of virtual addresses in the iommu.
I would think it's sufficient to describe it in the iommu itself,
since the limitation
is more "addresses coming into the iommu must be this range" than "this device
must use that address range for talking to the iommu".
If the addresses are allocated by the iommu driver, and each iommu only has
one DMA master attached to it, having a simple range property in the iommu
node should do the trick here. If there might be multiple devices on the same
iommu but with different address ranges (which I don't think is the case), then
it could be part of the reference to the iommu.
Arnd
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel