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):

quoted

Hi Jernej,

On Fri, Jan 24, 2020 at 09:54:23PM +0100, Jernej Škrabec wrote:

quoted

Dne sreda, 22. januar 2020 ob 13:44:09 CET je Maxime Ripard napisal(a):

quoted

Now that we have a driver for the IOMMU, let's start using it.

Signed-off-by: Maxime Ripard <redacted>
---

  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.

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel