[PATCH 0/2] arm64: tegra: Enable mmu on Tegra194 display controllers

[PATCH 0/2] arm64: tegra: Enable mmu on Tegra194 display controllers

[Aaron Kling]

This involves reverting a commit that explicitly disabled the associated
smmu, then wiring that to unit to the display controllers.

Signed-off-by: Aaron Kling <webgeek1234@gmail.com>
---
Aaron Kling (2):
      Revert "arm64: tegra: Disable ISO SMMU for Tegra194"
      arm64: tegra: Enable mmu on Tegra194 display controllers

 arch/arm64/boot/dts/nvidia/tegra194.dtsi | 8 ++++++--
 1 file changed, 6 insertions(+), 2 deletions(-)
---
base-commit: dcb6fa37fd7bc9c3d2b066329b0d27dedf8becaa
change-id: 20251101-tegra194-dc-mmu-ce925cf3d4cf

Best regards,
-- 
Aaron Kling <webgeek1234@gmail.com>

[PATCH 0/2] arm64: tegra: Enable mmu on Tegra194 display controllers

[Aaron Kling via B4 Relay]

This involves reverting a commit that explicitly disabled the associated
smmu, then wiring that to unit to the display controllers.

Signed-off-by: Aaron Kling <webgeek1234@gmail.com>
---
Aaron Kling (2):
      Revert "arm64: tegra: Disable ISO SMMU for Tegra194"
      arm64: tegra: Enable mmu on Tegra194 display controllers

 arch/arm64/boot/dts/nvidia/tegra194.dtsi | 8 ++++++--
 1 file changed, 6 insertions(+), 2 deletions(-)
---
base-commit: dcb6fa37fd7bc9c3d2b066329b0d27dedf8becaa
change-id: 20251101-tegra194-dc-mmu-ce925cf3d4cf

Best regards,
-- 
Aaron Kling <webgeek1234@gmail.com>

[PATCH 1/2] Revert "arm64: tegra: Disable ISO SMMU for Tegra194"

[Aaron Kling]

This reverts commit ebea268ea583ba4970df425dfef8c8e21d0a4e12.

Mmu is now being enabled for the display controllers.

Signed-off-by: Aaron Kling <webgeek1234@gmail.com>
---
 arch/arm64/boot/dts/nvidia/tegra194.dtsi | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm64/boot/dts/nvidia/tegra194.dtsi b/arch/arm64/boot/dts/nvidia/tegra194.dtsi
index 1399342f23e1c4f73b278adc66dfb948fc30d326..854ed6d46aa1d8eedcdfbae1fdde1374adf40337 100644
--- a/arch/arm64/boot/dts/nvidia/tegra194.dtsi
+++ b/arch/arm64/boot/dts/nvidia/tegra194.dtsi
@@ -1807,7 +1807,7 @@ iommu@10000000 {
 			#iommu-cells = <1>;
 
 			nvidia,memory-controller = <&mc>;
-			status = "disabled";
+			status = "okay";
 		};
 
 		smmu: iommu@12000000 {

-- 
2.51.0

[PATCH 1/2] Revert "arm64: tegra: Disable ISO SMMU for Tegra194"

[Aaron Kling via B4 Relay]

From: Aaron Kling <webgeek1234@gmail.com>

This reverts commit ebea268ea583ba4970df425dfef8c8e21d0a4e12.

Mmu is now being enabled for the display controllers.

Signed-off-by: Aaron Kling <webgeek1234@gmail.com>
---
 arch/arm64/boot/dts/nvidia/tegra194.dtsi | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm64/boot/dts/nvidia/tegra194.dtsi b/arch/arm64/boot/dts/nvidia/tegra194.dtsi
index 1399342f23e1c4f73b278adc66dfb948fc30d326..854ed6d46aa1d8eedcdfbae1fdde1374adf40337 100644
--- a/arch/arm64/boot/dts/nvidia/tegra194.dtsi
+++ b/arch/arm64/boot/dts/nvidia/tegra194.dtsi
@@ -1807,7 +1807,7 @@ iommu@10000000 {
 			#iommu-cells = <1>;
 
 			nvidia,memory-controller = <&mc>;
-			status = "disabled";
+			status = "okay";
 		};
 
 		smmu: iommu@12000000 {

-- 
2.51.0

Re: [PATCH 1/2] Revert "arm64: tegra: Disable ISO SMMU for Tegra194"

[Aaron Kling]

On Sat, Nov 1, 2025 at 6:01 PM Aaron Kling via B4 Relay
<devnull+webgeek1234.gmail.com@kernel.org> wrote:
>
> From: Aaron Kling <webgeek1234@gmail.com>
>
> This reverts commit ebea268ea583ba4970df425dfef8c8e21d0a4e12.
>
> Mmu is now being enabled for the display controllers.
>
> Signed-off-by: Aaron Kling <webgeek1234@gmail.com>
> ---
>  arch/arm64/boot/dts/nvidia/tegra194.dtsi | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/arm64/boot/dts/nvidia/tegra194.dtsi b/arch/arm64/boot/dts/nvidia/tegra194.dtsi
> index 1399342f23e1c4f73b278adc66dfb948fc30d326..854ed6d46aa1d8eedcdfbae1fdde1374adf40337 100644
> --- a/arch/arm64/boot/dts/nvidia/tegra194.dtsi
> +++ b/arch/arm64/boot/dts/nvidia/tegra194.dtsi
> @@ -1807,7 +1807,7 @@ iommu@10000000 {
>                         #iommu-cells = <1>;
>
>                         nvidia,memory-controller = <&mc>;
> -                       status = "disabled";
> +                       status = "okay";
>                 };
>
>                 smmu: iommu@12000000 {
>
> --
> 2.51.0
>
>

Question for Jon as the author of the commit being reverted. The
commit message states "we do not have a way to pass frame-buffer
memory from the bootloader to the kernel". If I understand this
correctly, this is talking about seamless handoff. What does this have
to do with enabling mmu on the display controllers? Seamless does not
work on any tegra arch as far as I'm aware, but Tegra194 is the only
one that doesn't have mmu enabled for the dc's. But enabling mmu
allows for better and faster memory allocation. My initial attempts to
enable this didn't work because I tried to attach them to the main mmu
unit, see the related freedesktop issue [0]. After noticing in the
downstream dt that the dc's are on a separate unit, I made it work.
And so far, it seems to work just as well as Tegra186. Then when I was
packaging up the change to submit, I found that this had been
explicitly disabled. But I'm not seeing why. Am I missing some
additional factors?

Aaron

[0] https://gitlab.freedesktop.org/drm/tegra/-/issues/5

Re: [PATCH 1/2] Revert "arm64: tegra: Disable ISO SMMU for Tegra194"

[Thierry Reding]

[-- Attachment #1: Type: text/plain, Size: 3342 bytes --]

On Sat, Nov 01, 2025 at 06:13:26PM -0500, Aaron Kling wrote:
> On Sat, Nov 1, 2025 at 6:01 PM Aaron Kling via B4 Relay
> <devnull+webgeek1234.gmail.com@kernel.org> wrote:
> >
> > From: Aaron Kling <webgeek1234@gmail.com>
> >
> > This reverts commit ebea268ea583ba4970df425dfef8c8e21d0a4e12.
> >
> > Mmu is now being enabled for the display controllers.
> >
> > Signed-off-by: Aaron Kling <webgeek1234@gmail.com>
> > ---
> >  arch/arm64/boot/dts/nvidia/tegra194.dtsi | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/arch/arm64/boot/dts/nvidia/tegra194.dtsi b/arch/arm64/boot/dts/nvidia/tegra194.dtsi
> > index 1399342f23e1c4f73b278adc66dfb948fc30d326..854ed6d46aa1d8eedcdfbae1fdde1374adf40337 100644
> > --- a/arch/arm64/boot/dts/nvidia/tegra194.dtsi
> > +++ b/arch/arm64/boot/dts/nvidia/tegra194.dtsi
> > @@ -1807,7 +1807,7 @@ iommu@10000000 {
> >                         #iommu-cells = <1>;
> >
> >                         nvidia,memory-controller = <&mc>;
> > -                       status = "disabled";
> > +                       status = "okay";
> >                 };
> >
> >                 smmu: iommu@12000000 {
> >
> > --
> > 2.51.0
> >
> >
> 
> Question for Jon as the author of the commit being reverted. The
> commit message states "we do not have a way to pass frame-buffer
> memory from the bootloader to the kernel". If I understand this
> correctly, this is talking about seamless handoff. What does this have
> to do with enabling mmu on the display controllers? Seamless does not
> work on any tegra arch as far as I'm aware, but Tegra194 is the only
> one that doesn't have mmu enabled for the dc's. But enabling mmu
> allows for better and faster memory allocation. My initial attempts to
> enable this didn't work because I tried to attach them to the main mmu
> unit, see the related freedesktop issue [0]. After noticing in the
> downstream dt that the dc's are on a separate unit, I made it work.
> And so far, it seems to work just as well as Tegra186. Then when I was
> packaging up the change to submit, I found that this had been
> explicitly disabled. But I'm not seeing why. Am I missing some
> additional factors?

This isn't seamless handoff to the Tegra DRM driver for display, but
rather to simple-framebuffer. While this does technically work, it also
causes a spew of SMMU faults during early boot because the firmware does
not properly pass the SMMU mapping information to the kernel.

In a nutshell what happens is that the firmware sets up the display
controller to scan out from a reserved memory region, but it does so
without involving the SMMU, so it uses physical addresses directly. When
the kernel boots and the SMMU is enabled the continued accesses from
display hardware cause SMMU faults (because there is no mapping for the
framebuffer addresses).

That said, we did solve these issues and this may not be happening
anymore with the most recent L4T releases, so it may be okay to revert
this now. We should find out exactly which release includes all the
needed changes so that it can be referenced in the commit message. I
want to avoid people running new kernels with an old L4T release and
then seeing these errors without any reference as to why that might
suddenly happen.

Thierry

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [PATCH 1/2] Revert "arm64: tegra: Disable ISO SMMU for Tegra194"

[Aaron Kling]

On Mon, Nov 3, 2025 at 5:07 AM Thierry Reding <thierry.reding@gmail.com> wrote:
>
> On Sat, Nov 01, 2025 at 06:13:26PM -0500, Aaron Kling wrote:
> > On Sat, Nov 1, 2025 at 6:01 PM Aaron Kling via B4 Relay
> > <devnull+webgeek1234.gmail.com@kernel.org> wrote:
> > >
> > > From: Aaron Kling <webgeek1234@gmail.com>
> > >
> > > This reverts commit ebea268ea583ba4970df425dfef8c8e21d0a4e12.
> > >
> > > Mmu is now being enabled for the display controllers.
> > >
> > > Signed-off-by: Aaron Kling <webgeek1234@gmail.com>
> > > ---
> > >  arch/arm64/boot/dts/nvidia/tegra194.dtsi | 2 +-
> > >  1 file changed, 1 insertion(+), 1 deletion(-)
> > >
> > > diff --git a/arch/arm64/boot/dts/nvidia/tegra194.dtsi b/arch/arm64/boot/dts/nvidia/tegra194.dtsi
> > > index 1399342f23e1c4f73b278adc66dfb948fc30d326..854ed6d46aa1d8eedcdfbae1fdde1374adf40337 100644
> > > --- a/arch/arm64/boot/dts/nvidia/tegra194.dtsi
> > > +++ b/arch/arm64/boot/dts/nvidia/tegra194.dtsi
> > > @@ -1807,7 +1807,7 @@ iommu@10000000 {
> > >                         #iommu-cells = <1>;
> > >
> > >                         nvidia,memory-controller = <&mc>;
> > > -                       status = "disabled";
> > > +                       status = "okay";
> > >                 };
> > >
> > >                 smmu: iommu@12000000 {
> > >
> > > --
> > > 2.51.0
> > >
> > >
> >
> > Question for Jon as the author of the commit being reverted. The
> > commit message states "we do not have a way to pass frame-buffer
> > memory from the bootloader to the kernel". If I understand this
> > correctly, this is talking about seamless handoff. What does this have
> > to do with enabling mmu on the display controllers? Seamless does not
> > work on any tegra arch as far as I'm aware, but Tegra194 is the only
> > one that doesn't have mmu enabled for the dc's. But enabling mmu
> > allows for better and faster memory allocation. My initial attempts to
> > enable this didn't work because I tried to attach them to the main mmu
> > unit, see the related freedesktop issue [0]. After noticing in the
> > downstream dt that the dc's are on a separate unit, I made it work.
> > And so far, it seems to work just as well as Tegra186. Then when I was
> > packaging up the change to submit, I found that this had been
> > explicitly disabled. But I'm not seeing why. Am I missing some
> > additional factors?
>
> This isn't seamless handoff to the Tegra DRM driver for display, but
> rather to simple-framebuffer. While this does technically work, it also
> causes a spew of SMMU faults during early boot because the firmware does
> not properly pass the SMMU mapping information to the kernel.
>
> In a nutshell what happens is that the firmware sets up the display
> controller to scan out from a reserved memory region, but it does so
> without involving the SMMU, so it uses physical addresses directly. When
> the kernel boots and the SMMU is enabled the continued accesses from
> display hardware cause SMMU faults (because there is no mapping for the
> framebuffer addresses).
>
> That said, we did solve these issues and this may not be happening
> anymore with the most recent L4T releases, so it may be okay to revert
> this now. We should find out exactly which release includes all the
> needed changes so that it can be referenced in the commit message. I
> want to avoid people running new kernels with an old L4T release and
> then seeing these errors without any reference as to why that might
> suddenly happen.

For reference, I have rolled back my Android usecase to use the L4T
r32.7.6 bootloaders on T194 for a variety of reasons. So I am using
cboot as the final bootloader and not edk2 as in L4T r34/r35. I have a
pending cboot patch to support simple-framebuffer handoff, but haven't
fully verified it as tegra-drm is currently unable to takeover from
simplefb like openrm does for t234. But all that to say that since I
no longer use r35 for t194 I don't have the setup to easily verify
which point release works here and what doesn't.

Aaron

Re: [PATCH 1/2] Revert "arm64: tegra: Disable ISO SMMU for Tegra194"

[Aaron Kling]

On Mon, Nov 3, 2025 at 12:05 PM Aaron Kling <webgeek1234@gmail.com> wrote:
>
> On Mon, Nov 3, 2025 at 5:07 AM Thierry Reding <thierry.reding@gmail.com> wrote:
> >
> > On Sat, Nov 01, 2025 at 06:13:26PM -0500, Aaron Kling wrote:
> > > On Sat, Nov 1, 2025 at 6:01 PM Aaron Kling via B4 Relay
> > > <devnull+webgeek1234.gmail.com@kernel.org> wrote:
> > > >
> > > > From: Aaron Kling <webgeek1234@gmail.com>
> > > >
> > > > This reverts commit ebea268ea583ba4970df425dfef8c8e21d0a4e12.
> > > >
> > > > Mmu is now being enabled for the display controllers.
> > > >
> > > > Signed-off-by: Aaron Kling <webgeek1234@gmail.com>
> > > > ---
> > > >  arch/arm64/boot/dts/nvidia/tegra194.dtsi | 2 +-
> > > >  1 file changed, 1 insertion(+), 1 deletion(-)
> > > >
> > > > diff --git a/arch/arm64/boot/dts/nvidia/tegra194.dtsi b/arch/arm64/boot/dts/nvidia/tegra194.dtsi
> > > > index 1399342f23e1c4f73b278adc66dfb948fc30d326..854ed6d46aa1d8eedcdfbae1fdde1374adf40337 100644
> > > > --- a/arch/arm64/boot/dts/nvidia/tegra194.dtsi
> > > > +++ b/arch/arm64/boot/dts/nvidia/tegra194.dtsi
> > > > @@ -1807,7 +1807,7 @@ iommu@10000000 {
> > > >                         #iommu-cells = <1>;
> > > >
> > > >                         nvidia,memory-controller = <&mc>;
> > > > -                       status = "disabled";
> > > > +                       status = "okay";
> > > >                 };
> > > >
> > > >                 smmu: iommu@12000000 {
> > > >
> > > > --
> > > > 2.51.0
> > > >
> > > >
> > >
> > > Question for Jon as the author of the commit being reverted. The
> > > commit message states "we do not have a way to pass frame-buffer
> > > memory from the bootloader to the kernel". If I understand this
> > > correctly, this is talking about seamless handoff. What does this have
> > > to do with enabling mmu on the display controllers? Seamless does not
> > > work on any tegra arch as far as I'm aware, but Tegra194 is the only
> > > one that doesn't have mmu enabled for the dc's. But enabling mmu
> > > allows for better and faster memory allocation. My initial attempts to
> > > enable this didn't work because I tried to attach them to the main mmu
> > > unit, see the related freedesktop issue [0]. After noticing in the
> > > downstream dt that the dc's are on a separate unit, I made it work.
> > > And so far, it seems to work just as well as Tegra186. Then when I was
> > > packaging up the change to submit, I found that this had been
> > > explicitly disabled. But I'm not seeing why. Am I missing some
> > > additional factors?
> >
> > This isn't seamless handoff to the Tegra DRM driver for display, but
> > rather to simple-framebuffer. While this does technically work, it also
> > causes a spew of SMMU faults during early boot because the firmware does
> > not properly pass the SMMU mapping information to the kernel.
> >
> > In a nutshell what happens is that the firmware sets up the display
> > controller to scan out from a reserved memory region, but it does so
> > without involving the SMMU, so it uses physical addresses directly. When
> > the kernel boots and the SMMU is enabled the continued accesses from
> > display hardware cause SMMU faults (because there is no mapping for the
> > framebuffer addresses).
> >
> > That said, we did solve these issues and this may not be happening
> > anymore with the most recent L4T releases, so it may be okay to revert
> > this now. We should find out exactly which release includes all the
> > needed changes so that it can be referenced in the commit message. I
> > want to avoid people running new kernels with an old L4T release and
> > then seeing these errors without any reference as to why that might
> > suddenly happen.
>
> For reference, I have rolled back my Android usecase to use the L4T
> r32.7.6 bootloaders on T194 for a variety of reasons. So I am using
> cboot as the final bootloader and not edk2 as in L4T r34/r35. I have a
> pending cboot patch to support simple-framebuffer handoff, but haven't
> fully verified it as tegra-drm is currently unable to takeover from
> simplefb like openrm does for t234. But all that to say that since I
> no longer use r35 for t194 I don't have the setup to easily verify
> which point release works here and what doesn't.

Any further thoughts on this patch?

Aaron

Re: [PATCH 1/2] Revert "arm64: tegra: Disable ISO SMMU for Tegra194"

[Mikko Perttunen]

On Tuesday, December 9, 2025 1:21 PM Aaron Kling wrote:
> On Mon, Nov 3, 2025 at 12:05 PM Aaron Kling <webgeek1234@gmail.com> wrote:
> >
> > On Mon, Nov 3, 2025 at 5:07 AM Thierry Reding <thierry.reding@gmail.com> wrote:
> > >
> > > On Sat, Nov 01, 2025 at 06:13:26PM -0500, Aaron Kling wrote:
> > > > On Sat, Nov 1, 2025 at 6:01 PM Aaron Kling via B4 Relay
> > > > <devnull+webgeek1234.gmail.com@kernel.org> wrote:
> > > > >
> > > > > From: Aaron Kling <webgeek1234@gmail.com>
> > > > >
> > > > > This reverts commit ebea268ea583ba4970df425dfef8c8e21d0a4e12.
> > > > >
> > > > > Mmu is now being enabled for the display controllers.
> > > > >
> > > > > Signed-off-by: Aaron Kling <webgeek1234@gmail.com>
> > > > > ---
> > > > >  arch/arm64/boot/dts/nvidia/tegra194.dtsi | 2 +-
> > > > >  1 file changed, 1 insertion(+), 1 deletion(-)
> > > > >
> > > > > diff --git a/arch/arm64/boot/dts/nvidia/tegra194.dtsi b/arch/arm64/boot/dts/nvidia/tegra194.dtsi
> > > > > index 1399342f23e1c4f73b278adc66dfb948fc30d326..854ed6d46aa1d8eedcdfbae1fdde1374adf40337 100644
> > > > > --- a/arch/arm64/boot/dts/nvidia/tegra194.dtsi
> > > > > +++ b/arch/arm64/boot/dts/nvidia/tegra194.dtsi
> > > > > @@ -1807,7 +1807,7 @@ iommu@10000000 {
> > > > >                         #iommu-cells = <1>;
> > > > >
> > > > >                         nvidia,memory-controller = <&mc>;
> > > > > -                       status = "disabled";
> > > > > +                       status = "okay";
> > > > >                 };
> > > > >
> > > > >                 smmu: iommu@12000000 {
> > > > >
> > > > > --
> > > > > 2.51.0
> > > > >
> > > > >
> > > >
> > > > Question for Jon as the author of the commit being reverted. The
> > > > commit message states "we do not have a way to pass frame-buffer
> > > > memory from the bootloader to the kernel". If I understand this
> > > > correctly, this is talking about seamless handoff. What does this have
> > > > to do with enabling mmu on the display controllers? Seamless does not
> > > > work on any tegra arch as far as I'm aware, but Tegra194 is the only
> > > > one that doesn't have mmu enabled for the dc's. But enabling mmu
> > > > allows for better and faster memory allocation. My initial attempts to
> > > > enable this didn't work because I tried to attach them to the main mmu
> > > > unit, see the related freedesktop issue [0]. After noticing in the
> > > > downstream dt that the dc's are on a separate unit, I made it work.
> > > > And so far, it seems to work just as well as Tegra186. Then when I was
> > > > packaging up the change to submit, I found that this had been
> > > > explicitly disabled. But I'm not seeing why. Am I missing some
> > > > additional factors?
> > >
> > > This isn't seamless handoff to the Tegra DRM driver for display, but
> > > rather to simple-framebuffer. While this does technically work, it also
> > > causes a spew of SMMU faults during early boot because the firmware does
> > > not properly pass the SMMU mapping information to the kernel.
> > >
> > > In a nutshell what happens is that the firmware sets up the display
> > > controller to scan out from a reserved memory region, but it does so
> > > without involving the SMMU, so it uses physical addresses directly. When
> > > the kernel boots and the SMMU is enabled the continued accesses from
> > > display hardware cause SMMU faults (because there is no mapping for the
> > > framebuffer addresses).
> > >
> > > That said, we did solve these issues and this may not be happening
> > > anymore with the most recent L4T releases, so it may be okay to revert
> > > this now. We should find out exactly which release includes all the
> > > needed changes so that it can be referenced in the commit message. I
> > > want to avoid people running new kernels with an old L4T release and
> > > then seeing these errors without any reference as to why that might
> > > suddenly happen.
> >
> > For reference, I have rolled back my Android usecase to use the L4T
> > r32.7.6 bootloaders on T194 for a variety of reasons. So I am using
> > cboot as the final bootloader and not edk2 as in L4T r34/r35. I have a
> > pending cboot patch to support simple-framebuffer handoff, but haven't
> > fully verified it as tegra-drm is currently unable to takeover from
> > simplefb like openrm does for t234. But all that to say that since I
> > no longer use r35 for t194 I don't have the setup to easily verify
> > which point release works here and what doesn't.
> 
> Any further thoughts on this patch?
> 
> Aaron

FWIW,

looks like the edk2 patch to update iommu-addresses --

commit 6071946461389221d2314cbbae0377610b5b1f6a
Author: Jan Bobek <jbobek@nvidia.com>
Date:   Tue Mar 21 00:15:27 2023 +0000

    feat(NvDisplayControllerDxe): update FDT with framebuffer info
    
    On ready-to-boot and whenever FDT is installed, update FDT with
    framebuffer mode information, base address and size.
    
    Signed-off-by: Jan Bobek <jbobek@nvidia.com>
    Reviewed-by: Ashish Singhal <ashishsingha@nvidia.com>

is in since r36.2

$ git tag --contains 6071946461389221d2314cbbae0377610b5b1f6a | grep "^r"                                                                 
r36.2
r36.3.0
r36.4.0
r36.4.3
r36.4.4
r36.4.5
r38.2
r38.4

Not so good for T194 since r36 only supports Orin.

I'll look into getting this cherry-picked to r35.

Mikko

Re: [PATCH 1/2] Revert "arm64: tegra: Disable ISO SMMU for Tegra194"

[Mikko Perttunen]

On Thursday, January 22, 2026 7:22 PM Mikko Perttunen wrote:
> On Tuesday, December 9, 2025 1:21 PM Aaron Kling wrote:
> > On Mon, Nov 3, 2025 at 12:05 PM Aaron Kling <webgeek1234@gmail.com> wrote:
> > >
> > > On Mon, Nov 3, 2025 at 5:07 AM Thierry Reding <thierry.reding@gmail.com> wrote:
> > > >
> > > > On Sat, Nov 01, 2025 at 06:13:26PM -0500, Aaron Kling wrote:
> > > > > On Sat, Nov 1, 2025 at 6:01 PM Aaron Kling via B4 Relay
> > > > > <devnull+webgeek1234.gmail.com@kernel.org> wrote:
> > > > > >
> > > > > > From: Aaron Kling <webgeek1234@gmail.com>
> > > > > >
> > > > > > This reverts commit ebea268ea583ba4970df425dfef8c8e21d0a4e12.
> > > > > >
> > > > > > Mmu is now being enabled for the display controllers.
> > > > > >
> > > > > > Signed-off-by: Aaron Kling <webgeek1234@gmail.com>
> > > > > > ---
> > > > > >  arch/arm64/boot/dts/nvidia/tegra194.dtsi | 2 +-
> > > > > >  1 file changed, 1 insertion(+), 1 deletion(-)
> > > > > >
> > > > > > diff --git a/arch/arm64/boot/dts/nvidia/tegra194.dtsi b/arch/arm64/boot/dts/nvidia/tegra194.dtsi
> > > > > > index 1399342f23e1c4f73b278adc66dfb948fc30d326..854ed6d46aa1d8eedcdfbae1fdde1374adf40337 100644
> > > > > > --- a/arch/arm64/boot/dts/nvidia/tegra194.dtsi
> > > > > > +++ b/arch/arm64/boot/dts/nvidia/tegra194.dtsi
> > > > > > @@ -1807,7 +1807,7 @@ iommu@10000000 {
> > > > > >                         #iommu-cells = <1>;
> > > > > >
> > > > > >                         nvidia,memory-controller = <&mc>;
> > > > > > -                       status = "disabled";
> > > > > > +                       status = "okay";
> > > > > >                 };
> > > > > >
> > > > > >                 smmu: iommu@12000000 {
> > > > > >
> > > > > > --
> > > > > > 2.51.0
> > > > > >
> > > > > >
> > > > >
> > > > > Question for Jon as the author of the commit being reverted. The
> > > > > commit message states "we do not have a way to pass frame-buffer
> > > > > memory from the bootloader to the kernel". If I understand this
> > > > > correctly, this is talking about seamless handoff. What does this have
> > > > > to do with enabling mmu on the display controllers? Seamless does not
> > > > > work on any tegra arch as far as I'm aware, but Tegra194 is the only
> > > > > one that doesn't have mmu enabled for the dc's. But enabling mmu
> > > > > allows for better and faster memory allocation. My initial attempts to
> > > > > enable this didn't work because I tried to attach them to the main mmu
> > > > > unit, see the related freedesktop issue [0]. After noticing in the
> > > > > downstream dt that the dc's are on a separate unit, I made it work.
> > > > > And so far, it seems to work just as well as Tegra186. Then when I was
> > > > > packaging up the change to submit, I found that this had been
> > > > > explicitly disabled. But I'm not seeing why. Am I missing some
> > > > > additional factors?
> > > >
> > > > This isn't seamless handoff to the Tegra DRM driver for display, but
> > > > rather to simple-framebuffer. While this does technically work, it also
> > > > causes a spew of SMMU faults during early boot because the firmware does
> > > > not properly pass the SMMU mapping information to the kernel.
> > > >
> > > > In a nutshell what happens is that the firmware sets up the display
> > > > controller to scan out from a reserved memory region, but it does so
> > > > without involving the SMMU, so it uses physical addresses directly. When
> > > > the kernel boots and the SMMU is enabled the continued accesses from
> > > > display hardware cause SMMU faults (because there is no mapping for the
> > > > framebuffer addresses).
> > > >
> > > > That said, we did solve these issues and this may not be happening
> > > > anymore with the most recent L4T releases, so it may be okay to revert
> > > > this now. We should find out exactly which release includes all the
> > > > needed changes so that it can be referenced in the commit message. I
> > > > want to avoid people running new kernels with an old L4T release and
> > > > then seeing these errors without any reference as to why that might
> > > > suddenly happen.
> > >
> > > For reference, I have rolled back my Android usecase to use the L4T
> > > r32.7.6 bootloaders on T194 for a variety of reasons. So I am using
> > > cboot as the final bootloader and not edk2 as in L4T r34/r35. I have a
> > > pending cboot patch to support simple-framebuffer handoff, but haven't
> > > fully verified it as tegra-drm is currently unable to takeover from
> > > simplefb like openrm does for t234. But all that to say that since I
> > > no longer use r35 for t194 I don't have the setup to easily verify
> > > which point release works here and what doesn't.
> > 
> > Any further thoughts on this patch?
> > 
> > Aaron
> 
> FWIW,
> 
> looks like the edk2 patch to update iommu-addresses --
> 
> commit 6071946461389221d2314cbbae0377610b5b1f6a
> Author: Jan Bobek <jbobek@nvidia.com>
> Date:   Tue Mar 21 00:15:27 2023 +0000
> 
>     feat(NvDisplayControllerDxe): update FDT with framebuffer info
>     
>     On ready-to-boot and whenever FDT is installed, update FDT with
>     framebuffer mode information, base address and size.
>     
>     Signed-off-by: Jan Bobek <jbobek@nvidia.com>
>     Reviewed-by: Ashish Singhal <ashishsingha@nvidia.com>
> 
> is in since r36.2
> 
> $ git tag --contains 6071946461389221d2314cbbae0377610b5b1f6a | grep "^r"                                                                 
> r36.2
> r36.3.0
> r36.4.0
> r36.4.3
> r36.4.4
> r36.4.5
> r38.2
> r38.4
> 
> Not so good for T194 since r36 only supports Orin.
> 
> I'll look into getting this cherry-picked to r35.
> 
> Mikko
> 
> 

I looked into this and it appears a version of this is in r35, but it only supports T234. However, I also found that at one point, L4T bootloader configuration has been modified to place the display controllers into SMMU bypass until otherwise configured by the kernel -- which the kernel does in tegra_mc_probe_device.

I think that means there is still potential for an issue where the display continues to be on between tegra_mc_probe_device and tegradrm reconfiguring it. However, I cannot reproduce that happening -- most likely the display is being turned off before that because of a clock or power domain being turned off.

In any case, this means that we no longer need to pass the framebuffer's information to the kernel. I think it would be good to have some clarity to ensure the issue described above cannot happen, but otherwise we should be able to enable IOMMU.

Mikko

Re: [PATCH 1/2] Revert "arm64: tegra: Disable ISO SMMU for Tegra194"

[Thierry Reding]

[-- Attachment #1: Type: text/plain, Size: 7691 bytes --]

On Tue, Feb 17, 2026 at 12:53:54PM +0900, Mikko Perttunen wrote:
> On Thursday, January 22, 2026 7:22 PM Mikko Perttunen wrote:
> > On Tuesday, December 9, 2025 1:21 PM Aaron Kling wrote:
> > > On Mon, Nov 3, 2025 at 12:05 PM Aaron Kling <webgeek1234@gmail.com> wrote:
> > > >
> > > > On Mon, Nov 3, 2025 at 5:07 AM Thierry Reding <thierry.reding@gmail.com> wrote:
> > > > >
> > > > > On Sat, Nov 01, 2025 at 06:13:26PM -0500, Aaron Kling wrote:
> > > > > > On Sat, Nov 1, 2025 at 6:01 PM Aaron Kling via B4 Relay
> > > > > > <devnull+webgeek1234.gmail.com@kernel.org> wrote:
> > > > > > >
> > > > > > > From: Aaron Kling <webgeek1234@gmail.com>
> > > > > > >
> > > > > > > This reverts commit ebea268ea583ba4970df425dfef8c8e21d0a4e12.
> > > > > > >
> > > > > > > Mmu is now being enabled for the display controllers.
> > > > > > >
> > > > > > > Signed-off-by: Aaron Kling <webgeek1234@gmail.com>
> > > > > > > ---
> > > > > > >  arch/arm64/boot/dts/nvidia/tegra194.dtsi | 2 +-
> > > > > > >  1 file changed, 1 insertion(+), 1 deletion(-)
> > > > > > >
> > > > > > > diff --git a/arch/arm64/boot/dts/nvidia/tegra194.dtsi b/arch/arm64/boot/dts/nvidia/tegra194.dtsi
> > > > > > > index 1399342f23e1c4f73b278adc66dfb948fc30d326..854ed6d46aa1d8eedcdfbae1fdde1374adf40337 100644
> > > > > > > --- a/arch/arm64/boot/dts/nvidia/tegra194.dtsi
> > > > > > > +++ b/arch/arm64/boot/dts/nvidia/tegra194.dtsi
> > > > > > > @@ -1807,7 +1807,7 @@ iommu@10000000 {
> > > > > > >                         #iommu-cells = <1>;
> > > > > > >
> > > > > > >                         nvidia,memory-controller = <&mc>;
> > > > > > > -                       status = "disabled";
> > > > > > > +                       status = "okay";
> > > > > > >                 };
> > > > > > >
> > > > > > >                 smmu: iommu@12000000 {
> > > > > > >
> > > > > > > --
> > > > > > > 2.51.0
> > > > > > >
> > > > > > >
> > > > > >
> > > > > > Question for Jon as the author of the commit being reverted. The
> > > > > > commit message states "we do not have a way to pass frame-buffer
> > > > > > memory from the bootloader to the kernel". If I understand this
> > > > > > correctly, this is talking about seamless handoff. What does this have
> > > > > > to do with enabling mmu on the display controllers? Seamless does not
> > > > > > work on any tegra arch as far as I'm aware, but Tegra194 is the only
> > > > > > one that doesn't have mmu enabled for the dc's. But enabling mmu
> > > > > > allows for better and faster memory allocation. My initial attempts to
> > > > > > enable this didn't work because I tried to attach them to the main mmu
> > > > > > unit, see the related freedesktop issue [0]. After noticing in the
> > > > > > downstream dt that the dc's are on a separate unit, I made it work.
> > > > > > And so far, it seems to work just as well as Tegra186. Then when I was
> > > > > > packaging up the change to submit, I found that this had been
> > > > > > explicitly disabled. But I'm not seeing why. Am I missing some
> > > > > > additional factors?
> > > > >
> > > > > This isn't seamless handoff to the Tegra DRM driver for display, but
> > > > > rather to simple-framebuffer. While this does technically work, it also
> > > > > causes a spew of SMMU faults during early boot because the firmware does
> > > > > not properly pass the SMMU mapping information to the kernel.
> > > > >
> > > > > In a nutshell what happens is that the firmware sets up the display
> > > > > controller to scan out from a reserved memory region, but it does so
> > > > > without involving the SMMU, so it uses physical addresses directly. When
> > > > > the kernel boots and the SMMU is enabled the continued accesses from
> > > > > display hardware cause SMMU faults (because there is no mapping for the
> > > > > framebuffer addresses).
> > > > >
> > > > > That said, we did solve these issues and this may not be happening
> > > > > anymore with the most recent L4T releases, so it may be okay to revert
> > > > > this now. We should find out exactly which release includes all the
> > > > > needed changes so that it can be referenced in the commit message. I
> > > > > want to avoid people running new kernels with an old L4T release and
> > > > > then seeing these errors without any reference as to why that might
> > > > > suddenly happen.
> > > >
> > > > For reference, I have rolled back my Android usecase to use the L4T
> > > > r32.7.6 bootloaders on T194 for a variety of reasons. So I am using
> > > > cboot as the final bootloader and not edk2 as in L4T r34/r35. I have a
> > > > pending cboot patch to support simple-framebuffer handoff, but haven't
> > > > fully verified it as tegra-drm is currently unable to takeover from
> > > > simplefb like openrm does for t234. But all that to say that since I
> > > > no longer use r35 for t194 I don't have the setup to easily verify
> > > > which point release works here and what doesn't.
> > > 
> > > Any further thoughts on this patch?
> > > 
> > > Aaron
> > 
> > FWIW,
> > 
> > looks like the edk2 patch to update iommu-addresses --
> > 
> > commit 6071946461389221d2314cbbae0377610b5b1f6a
> > Author: Jan Bobek <jbobek@nvidia.com>
> > Date:   Tue Mar 21 00:15:27 2023 +0000
> > 
> >     feat(NvDisplayControllerDxe): update FDT with framebuffer info
> >     
> >     On ready-to-boot and whenever FDT is installed, update FDT with
> >     framebuffer mode information, base address and size.
> >     
> >     Signed-off-by: Jan Bobek <jbobek@nvidia.com>
> >     Reviewed-by: Ashish Singhal <ashishsingha@nvidia.com>
> > 
> > is in since r36.2
> > 
> > $ git tag --contains 6071946461389221d2314cbbae0377610b5b1f6a | grep "^r"                                                                 
> > r36.2
> > r36.3.0
> > r36.4.0
> > r36.4.3
> > r36.4.4
> > r36.4.5
> > r38.2
> > r38.4
> > 
> > Not so good for T194 since r36 only supports Orin.
> > 
> > I'll look into getting this cherry-picked to r35.
> > 
> > Mikko
> > 
> > 
> 
> I looked into this and it appears a version of this is in r35, but it
> only supports T234. However, I also found that at one point, L4T
> bootloader configuration has been modified to place the display
> controllers into SMMU bypass until otherwise configured by the kernel
> -- which the kernel does in tegra_mc_probe_device.
> 
> I think that means there is still potential for an issue where the
> display continues to be on between tegra_mc_probe_device and tegradrm
> reconfiguring it. However, I cannot reproduce that happening -- most
> likely the display is being turned off before that because of a clock
> or power domain being turned off.
> 
> In any case, this means that we no longer need to pass the
> framebuffer's information to the kernel. I think it would be good to
> have some clarity to ensure the issue described above cannot happen,
> but otherwise we should be able to enable IOMMU.

The problem would happen if you enable some sort of early framebuffer
support, such as simple-drm or simple-framebuffer. Maybe even efifb. I
think it'd still be worth getting the iommu-addresses code into r35 if
for nothing else but to have a bit more of a safety buffer for the
future.

If we don't and for some reason decide that we want early framebuffer
support, it might be too late to get UEFI updated for Tegra194. I recall
that the UEFI code for Tegra194 is different from the one for Tegra234,
so it is probably not as trivial as a simple cherry-pick, but I'll try
to do some digging and find the code that does this for Xavier.

Thierry

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [PATCH 1/2] Revert "arm64: tegra: Disable ISO SMMU for Tegra194"

[Aaron Kling]

On Tue, Feb 17, 2026 at 4:13 AM Thierry Reding
<thierry.reding@kernel.org> wrote:
>
> On Tue, Feb 17, 2026 at 12:53:54PM +0900, Mikko Perttunen wrote:
> > On Thursday, January 22, 2026 7:22 PM Mikko Perttunen wrote:
> > > On Tuesday, December 9, 2025 1:21 PM Aaron Kling wrote:
> > > > On Mon, Nov 3, 2025 at 12:05 PM Aaron Kling <webgeek1234@gmail.com> wrote:
> > > > >
> > > > > On Mon, Nov 3, 2025 at 5:07 AM Thierry Reding <thierry.reding@gmail.com> wrote:
> > > > > >
> > > > > > On Sat, Nov 01, 2025 at 06:13:26PM -0500, Aaron Kling wrote:
> > > > > > > On Sat, Nov 1, 2025 at 6:01 PM Aaron Kling via B4 Relay
> > > > > > > <devnull+webgeek1234.gmail.com@kernel.org> wrote:
> > > > > > > >
> > > > > > > > From: Aaron Kling <webgeek1234@gmail.com>
> > > > > > > >
> > > > > > > > This reverts commit ebea268ea583ba4970df425dfef8c8e21d0a4e12.
> > > > > > > >
> > > > > > > > Mmu is now being enabled for the display controllers.
> > > > > > > >
> > > > > > > > Signed-off-by: Aaron Kling <webgeek1234@gmail.com>
> > > > > > > > ---
> > > > > > > >  arch/arm64/boot/dts/nvidia/tegra194.dtsi | 2 +-
> > > > > > > >  1 file changed, 1 insertion(+), 1 deletion(-)
> > > > > > > >
> > > > > > > > diff --git a/arch/arm64/boot/dts/nvidia/tegra194.dtsi b/arch/arm64/boot/dts/nvidia/tegra194.dtsi
> > > > > > > > index 1399342f23e1c4f73b278adc66dfb948fc30d326..854ed6d46aa1d8eedcdfbae1fdde1374adf40337 100644
> > > > > > > > --- a/arch/arm64/boot/dts/nvidia/tegra194.dtsi
> > > > > > > > +++ b/arch/arm64/boot/dts/nvidia/tegra194.dtsi
> > > > > > > > @@ -1807,7 +1807,7 @@ iommu@10000000 {
> > > > > > > >                         #iommu-cells = <1>;
> > > > > > > >
> > > > > > > >                         nvidia,memory-controller = <&mc>;
> > > > > > > > -                       status = "disabled";
> > > > > > > > +                       status = "okay";
> > > > > > > >                 };
> > > > > > > >
> > > > > > > >                 smmu: iommu@12000000 {
> > > > > > > >
> > > > > > > > --
> > > > > > > > 2.51.0
> > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > > > Question for Jon as the author of the commit being reverted. The
> > > > > > > commit message states "we do not have a way to pass frame-buffer
> > > > > > > memory from the bootloader to the kernel". If I understand this
> > > > > > > correctly, this is talking about seamless handoff. What does this have
> > > > > > > to do with enabling mmu on the display controllers? Seamless does not
> > > > > > > work on any tegra arch as far as I'm aware, but Tegra194 is the only
> > > > > > > one that doesn't have mmu enabled for the dc's. But enabling mmu
> > > > > > > allows for better and faster memory allocation. My initial attempts to
> > > > > > > enable this didn't work because I tried to attach them to the main mmu
> > > > > > > unit, see the related freedesktop issue [0]. After noticing in the
> > > > > > > downstream dt that the dc's are on a separate unit, I made it work.
> > > > > > > And so far, it seems to work just as well as Tegra186. Then when I was
> > > > > > > packaging up the change to submit, I found that this had been
> > > > > > > explicitly disabled. But I'm not seeing why. Am I missing some
> > > > > > > additional factors?
> > > > > >
> > > > > > This isn't seamless handoff to the Tegra DRM driver for display, but
> > > > > > rather to simple-framebuffer. While this does technically work, it also
> > > > > > causes a spew of SMMU faults during early boot because the firmware does
> > > > > > not properly pass the SMMU mapping information to the kernel.
> > > > > >
> > > > > > In a nutshell what happens is that the firmware sets up the display
> > > > > > controller to scan out from a reserved memory region, but it does so
> > > > > > without involving the SMMU, so it uses physical addresses directly. When
> > > > > > the kernel boots and the SMMU is enabled the continued accesses from
> > > > > > display hardware cause SMMU faults (because there is no mapping for the
> > > > > > framebuffer addresses).
> > > > > >
> > > > > > That said, we did solve these issues and this may not be happening
> > > > > > anymore with the most recent L4T releases, so it may be okay to revert
> > > > > > this now. We should find out exactly which release includes all the
> > > > > > needed changes so that it can be referenced in the commit message. I
> > > > > > want to avoid people running new kernels with an old L4T release and
> > > > > > then seeing these errors without any reference as to why that might
> > > > > > suddenly happen.
> > > > >
> > > > > For reference, I have rolled back my Android usecase to use the L4T
> > > > > r32.7.6 bootloaders on T194 for a variety of reasons. So I am using
> > > > > cboot as the final bootloader and not edk2 as in L4T r34/r35. I have a
> > > > > pending cboot patch to support simple-framebuffer handoff, but haven't
> > > > > fully verified it as tegra-drm is currently unable to takeover from
> > > > > simplefb like openrm does for t234. But all that to say that since I
> > > > > no longer use r35 for t194 I don't have the setup to easily verify
> > > > > which point release works here and what doesn't.
> > > >
> > > > Any further thoughts on this patch?
> > > >
> > > > Aaron
> > >
> > > FWIW,
> > >
> > > looks like the edk2 patch to update iommu-addresses --
> > >
> > > commit 6071946461389221d2314cbbae0377610b5b1f6a
> > > Author: Jan Bobek <jbobek@nvidia.com>
> > > Date:   Tue Mar 21 00:15:27 2023 +0000
> > >
> > >     feat(NvDisplayControllerDxe): update FDT with framebuffer info
> > >
> > >     On ready-to-boot and whenever FDT is installed, update FDT with
> > >     framebuffer mode information, base address and size.
> > >
> > >     Signed-off-by: Jan Bobek <jbobek@nvidia.com>
> > >     Reviewed-by: Ashish Singhal <ashishsingha@nvidia.com>
> > >
> > > is in since r36.2
> > >
> > > $ git tag --contains 6071946461389221d2314cbbae0377610b5b1f6a | grep "^r"
> > > r36.2
> > > r36.3.0
> > > r36.4.0
> > > r36.4.3
> > > r36.4.4
> > > r36.4.5
> > > r38.2
> > > r38.4
> > >
> > > Not so good for T194 since r36 only supports Orin.
> > >
> > > I'll look into getting this cherry-picked to r35.
> > >
> > > Mikko
> > >
> > >
> >
> > I looked into this and it appears a version of this is in r35, but it
> > only supports T234. However, I also found that at one point, L4T
> > bootloader configuration has been modified to place the display
> > controllers into SMMU bypass until otherwise configured by the kernel
> > -- which the kernel does in tegra_mc_probe_device.
> >
> > I think that means there is still potential for an issue where the
> > display continues to be on between tegra_mc_probe_device and tegradrm
> > reconfiguring it. However, I cannot reproduce that happening -- most
> > likely the display is being turned off before that because of a clock
> > or power domain being turned off.
> >
> > In any case, this means that we no longer need to pass the
> > framebuffer's information to the kernel. I think it would be good to
> > have some clarity to ensure the issue described above cannot happen,
> > but otherwise we should be able to enable IOMMU.
>
> The problem would happen if you enable some sort of early framebuffer
> support, such as simple-drm or simple-framebuffer. Maybe even efifb. I
> think it'd still be worth getting the iommu-addresses code into r35 if
> for nothing else but to have a bit more of a safety buffer for the
> future.
>
> If we don't and for some reason decide that we want early framebuffer
> support, it might be too late to get UEFI updated for Tegra194. I recall
> that the UEFI code for Tegra194 is different from the one for Tegra234,
> so it is probably not as trivial as a simple cherry-pick, but I'll try
> to do some digging and find the code that does this for Xavier.

Any updates on this?

Aaron

Re: [PATCH 1/2] Revert "arm64: tegra: Disable ISO SMMU for Tegra194"

[Mikko Perttunen]

On Monday, April 6, 2026 4:49 PM Aaron Kling wrote:
> On Tue, Feb 17, 2026 at 4:13 AM Thierry Reding
> <thierry.reding@kernel.org> wrote:
> >
> > On Tue, Feb 17, 2026 at 12:53:54PM +0900, Mikko Perttunen wrote:
> > > On Thursday, January 22, 2026 7:22 PM Mikko Perttunen wrote:
> > > > On Tuesday, December 9, 2025 1:21 PM Aaron Kling wrote:
> > > > > On Mon, Nov 3, 2025 at 12:05 PM Aaron Kling <webgeek1234@gmail.com> wrote:
> > > > > >
> > > > > > On Mon, Nov 3, 2025 at 5:07 AM Thierry Reding <thierry.reding@gmail.com> wrote:
> > > > > > >
> > > > > > > On Sat, Nov 01, 2025 at 06:13:26PM -0500, Aaron Kling wrote:
> > > > > > > > On Sat, Nov 1, 2025 at 6:01 PM Aaron Kling via B4 Relay
> > > > > > > > <devnull+webgeek1234.gmail.com@kernel.org> wrote:
> > > > > > > > >
> > > > > > > > > From: Aaron Kling <webgeek1234@gmail.com>
> > > > > > > > >
> > > > > > > > > This reverts commit ebea268ea583ba4970df425dfef8c8e21d0a4e12.
> > > > > > > > >
> > > > > > > > > Mmu is now being enabled for the display controllers.
> > > > > > > > >
> > > > > > > > > Signed-off-by: Aaron Kling <webgeek1234@gmail.com>
> > > > > > > > > ---
> > > > > > > > >  arch/arm64/boot/dts/nvidia/tegra194.dtsi | 2 +-
> > > > > > > > >  1 file changed, 1 insertion(+), 1 deletion(-)
> > > > > > > > >
> > > > > > > > > diff --git a/arch/arm64/boot/dts/nvidia/tegra194.dtsi b/arch/arm64/boot/dts/nvidia/tegra194.dtsi
> > > > > > > > > index 1399342f23e1c4f73b278adc66dfb948fc30d326..854ed6d46aa1d8eedcdfbae1fdde1374adf40337 100644
> > > > > > > > > --- a/arch/arm64/boot/dts/nvidia/tegra194.dtsi
> > > > > > > > > +++ b/arch/arm64/boot/dts/nvidia/tegra194.dtsi
> > > > > > > > > @@ -1807,7 +1807,7 @@ iommu@10000000 {
> > > > > > > > >                         #iommu-cells = <1>;
> > > > > > > > >
> > > > > > > > >                         nvidia,memory-controller = <&mc>;
> > > > > > > > > -                       status = "disabled";
> > > > > > > > > +                       status = "okay";
> > > > > > > > >                 };
> > > > > > > > >
> > > > > > > > >                 smmu: iommu@12000000 {
> > > > > > > > >
> > > > > > > > > --
> > > > > > > > > 2.51.0
> > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > > > Question for Jon as the author of the commit being reverted. The
> > > > > > > > commit message states "we do not have a way to pass frame-buffer
> > > > > > > > memory from the bootloader to the kernel". If I understand this
> > > > > > > > correctly, this is talking about seamless handoff. What does this have
> > > > > > > > to do with enabling mmu on the display controllers? Seamless does not
> > > > > > > > work on any tegra arch as far as I'm aware, but Tegra194 is the only
> > > > > > > > one that doesn't have mmu enabled for the dc's. But enabling mmu
> > > > > > > > allows for better and faster memory allocation. My initial attempts to
> > > > > > > > enable this didn't work because I tried to attach them to the main mmu
> > > > > > > > unit, see the related freedesktop issue [0]. After noticing in the
> > > > > > > > downstream dt that the dc's are on a separate unit, I made it work.
> > > > > > > > And so far, it seems to work just as well as Tegra186. Then when I was
> > > > > > > > packaging up the change to submit, I found that this had been
> > > > > > > > explicitly disabled. But I'm not seeing why. Am I missing some
> > > > > > > > additional factors?
> > > > > > >
> > > > > > > This isn't seamless handoff to the Tegra DRM driver for display, but
> > > > > > > rather to simple-framebuffer. While this does technically work, it also
> > > > > > > causes a spew of SMMU faults during early boot because the firmware does
> > > > > > > not properly pass the SMMU mapping information to the kernel.
> > > > > > >
> > > > > > > In a nutshell what happens is that the firmware sets up the display
> > > > > > > controller to scan out from a reserved memory region, but it does so
> > > > > > > without involving the SMMU, so it uses physical addresses directly. When
> > > > > > > the kernel boots and the SMMU is enabled the continued accesses from
> > > > > > > display hardware cause SMMU faults (because there is no mapping for the
> > > > > > > framebuffer addresses).
> > > > > > >
> > > > > > > That said, we did solve these issues and this may not be happening
> > > > > > > anymore with the most recent L4T releases, so it may be okay to revert
> > > > > > > this now. We should find out exactly which release includes all the
> > > > > > > needed changes so that it can be referenced in the commit message. I
> > > > > > > want to avoid people running new kernels with an old L4T release and
> > > > > > > then seeing these errors without any reference as to why that might
> > > > > > > suddenly happen.
> > > > > >
> > > > > > For reference, I have rolled back my Android usecase to use the L4T
> > > > > > r32.7.6 bootloaders on T194 for a variety of reasons. So I am using
> > > > > > cboot as the final bootloader and not edk2 as in L4T r34/r35. I have a
> > > > > > pending cboot patch to support simple-framebuffer handoff, but haven't
> > > > > > fully verified it as tegra-drm is currently unable to takeover from
> > > > > > simplefb like openrm does for t234. But all that to say that since I
> > > > > > no longer use r35 for t194 I don't have the setup to easily verify
> > > > > > which point release works here and what doesn't.
> > > > >
> > > > > Any further thoughts on this patch?
> > > > >
> > > > > Aaron
> > > >
> > > > FWIW,
> > > >
> > > > looks like the edk2 patch to update iommu-addresses --
> > > >
> > > > commit 6071946461389221d2314cbbae0377610b5b1f6a
> > > > Author: Jan Bobek <jbobek@nvidia.com>
> > > > Date:   Tue Mar 21 00:15:27 2023 +0000
> > > >
> > > >     feat(NvDisplayControllerDxe): update FDT with framebuffer info
> > > >
> > > >     On ready-to-boot and whenever FDT is installed, update FDT with
> > > >     framebuffer mode information, base address and size.
> > > >
> > > >     Signed-off-by: Jan Bobek <jbobek@nvidia.com>
> > > >     Reviewed-by: Ashish Singhal <ashishsingha@nvidia.com>
> > > >
> > > > is in since r36.2
> > > >
> > > > $ git tag --contains 6071946461389221d2314cbbae0377610b5b1f6a | grep "^r"
> > > > r36.2
> > > > r36.3.0
> > > > r36.4.0
> > > > r36.4.3
> > > > r36.4.4
> > > > r36.4.5
> > > > r38.2
> > > > r38.4
> > > >
> > > > Not so good for T194 since r36 only supports Orin.
> > > >
> > > > I'll look into getting this cherry-picked to r35.
> > > >
> > > > Mikko
> > > >
> > > >
> > >
> > > I looked into this and it appears a version of this is in r35, but it
> > > only supports T234. However, I also found that at one point, L4T
> > > bootloader configuration has been modified to place the display
> > > controllers into SMMU bypass until otherwise configured by the kernel
> > > -- which the kernel does in tegra_mc_probe_device.
> > >
> > > I think that means there is still potential for an issue where the
> > > display continues to be on between tegra_mc_probe_device and tegradrm
> > > reconfiguring it. However, I cannot reproduce that happening -- most
> > > likely the display is being turned off before that because of a clock
> > > or power domain being turned off.
> > >
> > > In any case, this means that we no longer need to pass the
> > > framebuffer's information to the kernel. I think it would be good to
> > > have some clarity to ensure the issue described above cannot happen,
> > > but otherwise we should be able to enable IOMMU.
> >
> > The problem would happen if you enable some sort of early framebuffer
> > support, such as simple-drm or simple-framebuffer. Maybe even efifb. I
> > think it'd still be worth getting the iommu-addresses code into r35 if
> > for nothing else but to have a bit more of a safety buffer for the
> > future.
> >
> > If we don't and for some reason decide that we want early framebuffer
> > support, it might be too late to get UEFI updated for Tegra194. I recall
> > that the UEFI code for Tegra194 is different from the one for Tegra234,
> > so it is probably not as trivial as a simple cherry-pick, but I'll try
> > to do some digging and find the code that does this for Xavier.
> 
> Any updates on this?

FWIW, in my testing with L4T versions with UEFI firmware, I'm not seeing 
any issues even if efifb is enabled. My inclination would be to merge, 
and we can work on issues related to early framebuffer separately.

Outside adding support to r35, one option is to make it so TegraDRM has 
to explicitly call tegra_mc_probe_device (not necessarily directly) when 
it has quiesced the hardware during probe. This would not allow seamless 
early framebuffer transition, but otherwise it should work. Implementing 
this for tegra-smmu would also allow us to get rid of the IOMMU API 
paths in TegraDRM and Host1x, which would be a great boon.

Cheers
Mikko

> 
> Aaron

Re: [PATCH 1/2] Revert "arm64: tegra: Disable ISO SMMU for Tegra194"

[Thierry Reding]

[-- Attachment #1: Type: text/plain, Size: 9789 bytes --]

On Tue, Apr 07, 2026 at 01:09:10PM +0900, Mikko Perttunen wrote:
> On Monday, April 6, 2026 4:49 PM Aaron Kling wrote:
> > On Tue, Feb 17, 2026 at 4:13 AM Thierry Reding
> > <thierry.reding@kernel.org> wrote:
> > >
> > > On Tue, Feb 17, 2026 at 12:53:54PM +0900, Mikko Perttunen wrote:
> > > > On Thursday, January 22, 2026 7:22 PM Mikko Perttunen wrote:
> > > > > On Tuesday, December 9, 2025 1:21 PM Aaron Kling wrote:
> > > > > > On Mon, Nov 3, 2025 at 12:05 PM Aaron Kling <webgeek1234@gmail.com> wrote:
> > > > > > >
> > > > > > > On Mon, Nov 3, 2025 at 5:07 AM Thierry Reding <thierry.reding@gmail.com> wrote:
> > > > > > > >
> > > > > > > > On Sat, Nov 01, 2025 at 06:13:26PM -0500, Aaron Kling wrote:
> > > > > > > > > On Sat, Nov 1, 2025 at 6:01 PM Aaron Kling via B4 Relay
> > > > > > > > > <devnull+webgeek1234.gmail.com@kernel.org> wrote:
> > > > > > > > > >
> > > > > > > > > > From: Aaron Kling <webgeek1234@gmail.com>
> > > > > > > > > >
> > > > > > > > > > This reverts commit ebea268ea583ba4970df425dfef8c8e21d0a4e12.
> > > > > > > > > >
> > > > > > > > > > Mmu is now being enabled for the display controllers.
> > > > > > > > > >
> > > > > > > > > > Signed-off-by: Aaron Kling <webgeek1234@gmail.com>
> > > > > > > > > > ---
> > > > > > > > > >  arch/arm64/boot/dts/nvidia/tegra194.dtsi | 2 +-
> > > > > > > > > >  1 file changed, 1 insertion(+), 1 deletion(-)
> > > > > > > > > >
> > > > > > > > > > diff --git a/arch/arm64/boot/dts/nvidia/tegra194.dtsi b/arch/arm64/boot/dts/nvidia/tegra194.dtsi
> > > > > > > > > > index 1399342f23e1c4f73b278adc66dfb948fc30d326..854ed6d46aa1d8eedcdfbae1fdde1374adf40337 100644
> > > > > > > > > > --- a/arch/arm64/boot/dts/nvidia/tegra194.dtsi
> > > > > > > > > > +++ b/arch/arm64/boot/dts/nvidia/tegra194.dtsi
> > > > > > > > > > @@ -1807,7 +1807,7 @@ iommu@10000000 {
> > > > > > > > > >                         #iommu-cells = <1>;
> > > > > > > > > >
> > > > > > > > > >                         nvidia,memory-controller = <&mc>;
> > > > > > > > > > -                       status = "disabled";
> > > > > > > > > > +                       status = "okay";
> > > > > > > > > >                 };
> > > > > > > > > >
> > > > > > > > > >                 smmu: iommu@12000000 {
> > > > > > > > > >
> > > > > > > > > > --
> > > > > > > > > > 2.51.0
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > > > Question for Jon as the author of the commit being reverted. The
> > > > > > > > > commit message states "we do not have a way to pass frame-buffer
> > > > > > > > > memory from the bootloader to the kernel". If I understand this
> > > > > > > > > correctly, this is talking about seamless handoff. What does this have
> > > > > > > > > to do with enabling mmu on the display controllers? Seamless does not
> > > > > > > > > work on any tegra arch as far as I'm aware, but Tegra194 is the only
> > > > > > > > > one that doesn't have mmu enabled for the dc's. But enabling mmu
> > > > > > > > > allows for better and faster memory allocation. My initial attempts to
> > > > > > > > > enable this didn't work because I tried to attach them to the main mmu
> > > > > > > > > unit, see the related freedesktop issue [0]. After noticing in the
> > > > > > > > > downstream dt that the dc's are on a separate unit, I made it work.
> > > > > > > > > And so far, it seems to work just as well as Tegra186. Then when I was
> > > > > > > > > packaging up the change to submit, I found that this had been
> > > > > > > > > explicitly disabled. But I'm not seeing why. Am I missing some
> > > > > > > > > additional factors?
> > > > > > > >
> > > > > > > > This isn't seamless handoff to the Tegra DRM driver for display, but
> > > > > > > > rather to simple-framebuffer. While this does technically work, it also
> > > > > > > > causes a spew of SMMU faults during early boot because the firmware does
> > > > > > > > not properly pass the SMMU mapping information to the kernel.
> > > > > > > >
> > > > > > > > In a nutshell what happens is that the firmware sets up the display
> > > > > > > > controller to scan out from a reserved memory region, but it does so
> > > > > > > > without involving the SMMU, so it uses physical addresses directly. When
> > > > > > > > the kernel boots and the SMMU is enabled the continued accesses from
> > > > > > > > display hardware cause SMMU faults (because there is no mapping for the
> > > > > > > > framebuffer addresses).
> > > > > > > >
> > > > > > > > That said, we did solve these issues and this may not be happening
> > > > > > > > anymore with the most recent L4T releases, so it may be okay to revert
> > > > > > > > this now. We should find out exactly which release includes all the
> > > > > > > > needed changes so that it can be referenced in the commit message. I
> > > > > > > > want to avoid people running new kernels with an old L4T release and
> > > > > > > > then seeing these errors without any reference as to why that might
> > > > > > > > suddenly happen.
> > > > > > >
> > > > > > > For reference, I have rolled back my Android usecase to use the L4T
> > > > > > > r32.7.6 bootloaders on T194 for a variety of reasons. So I am using
> > > > > > > cboot as the final bootloader and not edk2 as in L4T r34/r35. I have a
> > > > > > > pending cboot patch to support simple-framebuffer handoff, but haven't
> > > > > > > fully verified it as tegra-drm is currently unable to takeover from
> > > > > > > simplefb like openrm does for t234. But all that to say that since I
> > > > > > > no longer use r35 for t194 I don't have the setup to easily verify
> > > > > > > which point release works here and what doesn't.
> > > > > >
> > > > > > Any further thoughts on this patch?
> > > > > >
> > > > > > Aaron
> > > > >
> > > > > FWIW,
> > > > >
> > > > > looks like the edk2 patch to update iommu-addresses --
> > > > >
> > > > > commit 6071946461389221d2314cbbae0377610b5b1f6a
> > > > > Author: Jan Bobek <jbobek@nvidia.com>
> > > > > Date:   Tue Mar 21 00:15:27 2023 +0000
> > > > >
> > > > >     feat(NvDisplayControllerDxe): update FDT with framebuffer info
> > > > >
> > > > >     On ready-to-boot and whenever FDT is installed, update FDT with
> > > > >     framebuffer mode information, base address and size.
> > > > >
> > > > >     Signed-off-by: Jan Bobek <jbobek@nvidia.com>
> > > > >     Reviewed-by: Ashish Singhal <ashishsingha@nvidia.com>
> > > > >
> > > > > is in since r36.2
> > > > >
> > > > > $ git tag --contains 6071946461389221d2314cbbae0377610b5b1f6a | grep "^r"
> > > > > r36.2
> > > > > r36.3.0
> > > > > r36.4.0
> > > > > r36.4.3
> > > > > r36.4.4
> > > > > r36.4.5
> > > > > r38.2
> > > > > r38.4
> > > > >
> > > > > Not so good for T194 since r36 only supports Orin.
> > > > >
> > > > > I'll look into getting this cherry-picked to r35.
> > > > >
> > > > > Mikko
> > > > >
> > > > >
> > > >
> > > > I looked into this and it appears a version of this is in r35, but it
> > > > only supports T234. However, I also found that at one point, L4T
> > > > bootloader configuration has been modified to place the display
> > > > controllers into SMMU bypass until otherwise configured by the kernel
> > > > -- which the kernel does in tegra_mc_probe_device.
> > > >
> > > > I think that means there is still potential for an issue where the
> > > > display continues to be on between tegra_mc_probe_device and tegradrm
> > > > reconfiguring it. However, I cannot reproduce that happening -- most
> > > > likely the display is being turned off before that because of a clock
> > > > or power domain being turned off.
> > > >
> > > > In any case, this means that we no longer need to pass the
> > > > framebuffer's information to the kernel. I think it would be good to
> > > > have some clarity to ensure the issue described above cannot happen,
> > > > but otherwise we should be able to enable IOMMU.
> > >
> > > The problem would happen if you enable some sort of early framebuffer
> > > support, such as simple-drm or simple-framebuffer. Maybe even efifb. I
> > > think it'd still be worth getting the iommu-addresses code into r35 if
> > > for nothing else but to have a bit more of a safety buffer for the
> > > future.
> > >
> > > If we don't and for some reason decide that we want early framebuffer
> > > support, it might be too late to get UEFI updated for Tegra194. I recall
> > > that the UEFI code for Tegra194 is different from the one for Tegra234,
> > > so it is probably not as trivial as a simple cherry-pick, but I'll try
> > > to do some digging and find the code that does this for Xavier.
> > 
> > Any updates on this?
> 
> FWIW, in my testing with L4T versions with UEFI firmware, I'm not seeing 
> any issues even if efifb is enabled. My inclination would be to merge, 
> and we can work on issues related to early framebuffer separately.
> 
> Outside adding support to r35, one option is to make it so TegraDRM has 
> to explicitly call tegra_mc_probe_device (not necessarily directly) when 
> it has quiesced the hardware during probe. This would not allow seamless 
> early framebuffer transition, but otherwise it should work. Implementing 
> this for tegra-smmu would also allow us to get rid of the IOMMU API 
> paths in TegraDRM and Host1x, which would be a great boon.

I did most of this work a long time ago and L4T just wasn't ready yet to
make use of all this cleanup potential. We can probably go find most of
the code and it might still be largely applicable.

It's a bit disappointing that this didn't go anywhere for the longest
time and all of a sudden most of it just seems to be irrelevant.

Thierry

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

[PATCH 2/2] arm64: tegra: Enable mmu on Tegra194 display controllers

[Aaron Kling]

These use a separate mmu instance compared to everything else currently
enabled for the soc.

Signed-off-by: Aaron Kling <webgeek1234@gmail.com>
---
 arch/arm64/boot/dts/nvidia/tegra194.dtsi | 6 +++++-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/arch/arm64/boot/dts/nvidia/tegra194.dtsi b/arch/arm64/boot/dts/nvidia/tegra194.dtsi
index 854ed6d46aa1d8eedcdfbae1fdde1374adf40337..e75b0af81ab76fec5b7531e9c0932a629cbd8768 100644
--- a/arch/arm64/boot/dts/nvidia/tegra194.dtsi
+++ b/arch/arm64/boot/dts/nvidia/tegra194.dtsi
@@ -1734,7 +1734,7 @@ bpmp-noc@d600000 {
 			status = "okay";
 		};
 
-		iommu@10000000 {
+		smmu_iso: iommu@10000000 {
 			compatible = "nvidia,tegra194-smmu", "nvidia,smmu-500";
 			reg = <0x0 0x10000000 0x0 0x800000>;
 			interrupts = <GIC_SPI 240 IRQ_TYPE_LEVEL_HIGH>,
@@ -1975,6 +1975,7 @@ display@15200000 {
 					interconnects = <&mc TEGRA194_MEMORY_CLIENT_NVDISPLAYR &emc>,
 							<&mc TEGRA194_MEMORY_CLIENT_NVDISPLAYR1 &emc>;
 					interconnect-names = "dma-mem", "read-1";
+					iommus = <&smmu_iso TEGRA194_SID_NVDISPLAY>;
 
 					nvidia,outputs = <&sor0 &sor1 &sor2 &sor3>;
 					nvidia,head = <0>;
@@ -1993,6 +1994,7 @@ display@15210000 {
 					interconnects = <&mc TEGRA194_MEMORY_CLIENT_NVDISPLAYR &emc>,
 							<&mc TEGRA194_MEMORY_CLIENT_NVDISPLAYR1 &emc>;
 					interconnect-names = "dma-mem", "read-1";
+					iommus = <&smmu_iso TEGRA194_SID_NVDISPLAY>;
 
 					nvidia,outputs = <&sor0 &sor1 &sor2 &sor3>;
 					nvidia,head = <1>;
@@ -2011,6 +2013,7 @@ display@15220000 {
 					interconnects = <&mc TEGRA194_MEMORY_CLIENT_NVDISPLAYR &emc>,
 							<&mc TEGRA194_MEMORY_CLIENT_NVDISPLAYR1 &emc>;
 					interconnect-names = "dma-mem", "read-1";
+					iommus = <&smmu_iso TEGRA194_SID_NVDISPLAY>;
 
 					nvidia,outputs = <&sor0 &sor1 &sor2 &sor3>;
 					nvidia,head = <2>;
@@ -2029,6 +2032,7 @@ display@15230000 {
 					interconnects = <&mc TEGRA194_MEMORY_CLIENT_NVDISPLAYR &emc>,
 							<&mc TEGRA194_MEMORY_CLIENT_NVDISPLAYR1 &emc>;
 					interconnect-names = "dma-mem", "read-1";
+					iommus = <&smmu_iso TEGRA194_SID_NVDISPLAY>;
 
 					nvidia,outputs = <&sor0 &sor1 &sor2 &sor3>;
 					nvidia,head = <3>;

-- 
2.51.0

[PATCH 2/2] arm64: tegra: Enable mmu on Tegra194 display controllers

[Aaron Kling via B4 Relay]

From: Aaron Kling <webgeek1234@gmail.com>

These use a separate mmu instance compared to everything else currently
enabled for the soc.

Signed-off-by: Aaron Kling <webgeek1234@gmail.com>
---
 arch/arm64/boot/dts/nvidia/tegra194.dtsi | 6 +++++-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/arch/arm64/boot/dts/nvidia/tegra194.dtsi b/arch/arm64/boot/dts/nvidia/tegra194.dtsi
index 854ed6d46aa1d8eedcdfbae1fdde1374adf40337..e75b0af81ab76fec5b7531e9c0932a629cbd8768 100644
--- a/arch/arm64/boot/dts/nvidia/tegra194.dtsi
+++ b/arch/arm64/boot/dts/nvidia/tegra194.dtsi
@@ -1734,7 +1734,7 @@ bpmp-noc@d600000 {
 			status = "okay";
 		};
 
-		iommu@10000000 {
+		smmu_iso: iommu@10000000 {
 			compatible = "nvidia,tegra194-smmu", "nvidia,smmu-500";
 			reg = <0x0 0x10000000 0x0 0x800000>;
 			interrupts = <GIC_SPI 240 IRQ_TYPE_LEVEL_HIGH>,
@@ -1975,6 +1975,7 @@ display@15200000 {
 					interconnects = <&mc TEGRA194_MEMORY_CLIENT_NVDISPLAYR &emc>,
 							<&mc TEGRA194_MEMORY_CLIENT_NVDISPLAYR1 &emc>;
 					interconnect-names = "dma-mem", "read-1";
+					iommus = <&smmu_iso TEGRA194_SID_NVDISPLAY>;
 
 					nvidia,outputs = <&sor0 &sor1 &sor2 &sor3>;
 					nvidia,head = <0>;
@@ -1993,6 +1994,7 @@ display@15210000 {
 					interconnects = <&mc TEGRA194_MEMORY_CLIENT_NVDISPLAYR &emc>,
 							<&mc TEGRA194_MEMORY_CLIENT_NVDISPLAYR1 &emc>;
 					interconnect-names = "dma-mem", "read-1";
+					iommus = <&smmu_iso TEGRA194_SID_NVDISPLAY>;
 
 					nvidia,outputs = <&sor0 &sor1 &sor2 &sor3>;
 					nvidia,head = <1>;
@@ -2011,6 +2013,7 @@ display@15220000 {
 					interconnects = <&mc TEGRA194_MEMORY_CLIENT_NVDISPLAYR &emc>,
 							<&mc TEGRA194_MEMORY_CLIENT_NVDISPLAYR1 &emc>;
 					interconnect-names = "dma-mem", "read-1";
+					iommus = <&smmu_iso TEGRA194_SID_NVDISPLAY>;
 
 					nvidia,outputs = <&sor0 &sor1 &sor2 &sor3>;
 					nvidia,head = <2>;
@@ -2029,6 +2032,7 @@ display@15230000 {
 					interconnects = <&mc TEGRA194_MEMORY_CLIENT_NVDISPLAYR &emc>,
 							<&mc TEGRA194_MEMORY_CLIENT_NVDISPLAYR1 &emc>;
 					interconnect-names = "dma-mem", "read-1";
+					iommus = <&smmu_iso TEGRA194_SID_NVDISPLAY>;
 
 					nvidia,outputs = <&sor0 &sor1 &sor2 &sor3>;
 					nvidia,head = <3>;

-- 
2.51.0