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
[unhandled content-type:application/pgp-signature]