Messages in this thread |  | | From | Aaron Kling <> | | Date | Mon, 6 Apr 2026 02:49:45 -0500 | | Subject | Re: [PATCH 1/2] Revert "arm64: tegra: Disable ISO SMMU for Tegra194" |
| |
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
|  |