On 27/01/2020 7:04 pm, Jernej Škrabec wrote:
Hi!
Dne ponedeljek, 27. januar 2020 ob 15:23:39 CET je Maxime Ripard napisal(a):
Hi Jernej,
On Fri, Jan 24, 2020 at 09:54:23PM +0100, Jernej Škrabec wrote:
Dne sreda, 22. januar 2020 ob 13:44:09 CET je Maxime Ripard napisal(a):
Now that we have a driver for the IOMMU, let's start using it.
Signed-off-by: Maxime Ripard <maxime@xxxxxxxxxx>
---
arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi | 11 +++++++++++
1 file changed, 11 insertions(+)
diff --git a/arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi
b/arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi index
29824081b43b..8608bcf1c52c 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi
+++ b/arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi
@@ -53,6 +53,7 @@
de: display-engine {
compatible = "allwinner,sun50i-h6-display-engine";
allwinner,pipelines = <&mixer0>;
+ iommus = <&iommu 0>;
status = "disabled";
};
Isn't iommu property of the mixer node? After all, mixer is the one which
reads one or more framebuffers. Once second mixer is defined, would you
put
another iommu phandle here?
You're right. I added it during the early dev, and forgot to remove
it. Thanks!
Remove it or move it? I guess enabling iommu support in each driver needs a
bit more work than just referencing iommu node, right? At least in such case
buffers don't need to be allocated by CMA, which sun4i-drm driver currently
use.
Note that the DRM "CMA" helpers are somewhat misnamed, since they're in
fact based on the common DMA API, and thus transparent IOMMU-backed DMA
ops will "just work" without the drivers having to care. Since all the
display components behind the IOMMU will be in the same IOMMU group,
they're guaranteed to always operate in the same address space as each
other, so there should be no additional problems with buffer sharing
(assuming the code doesn't have bugs that it's currently just getting
away with).
I just take another look at BSP kernel and it seems that only one channel is
used for whole display stack. That would mean that both mixers would have same
iommu phandle, right? Confusingly enough, DE2 iommu channel seems to be for
deinterlace core.
That's also fine - as discussed on the driver thread there's no point
trying to expose a distinction between devices at the API level, so the
IDs are really only relevant to the driver internals touching the
various enable registers (and even then only if you wanted to refine the
current "just enable everything" approach).
Robin.
