[PATCH] Revert "arm64: tegra: Add interconnect properties for Tegra210"

[PATCH] Revert "arm64: tegra: Add interconnect properties for Tegra210"

[Jon Hunter]

Commit 59a42707a094 ("arm64: tegra: Add interconnect properties for
Tegra210") populated interconnect properties for Tegra210 and this is
preventing the Tegra DRM driver from probing successfully. The following
error is observed on boot ...

 drm drm: failed to initialize 54240000.dc: -517

For now revert this change, until a fix is available.

Fixes: 59a42707a094 ("arm64: tegra: Add interconnect properties for Tegra210")
Signed-off-by: Jon Hunter <jonathanh@nvidia.com>
---
 arch/arm64/boot/dts/nvidia/tegra210.dtsi | 24 ------------------------
 1 file changed, 24 deletions(-)

diff --git a/arch/arm64/boot/dts/nvidia/tegra210.dtsi b/arch/arm64/boot/dts/nvidia/tegra210.dtsi
index 709da31d5785..137aa8375257 100644
--- a/arch/arm64/boot/dts/nvidia/tegra210.dtsi
+++ b/arch/arm64/boot/dts/nvidia/tegra210.dtsi
@@ -202,19 +202,6 @@ dc@54200000 {
 
 			nvidia,outputs = <&dsia &dsib &sor0 &sor1>;
 			nvidia,head = <0>;
-
-			interconnects = <&mc TEGRA210_MC_DISPLAY0A &emc>,
-					<&mc TEGRA210_MC_DISPLAY0B &emc>,
-					<&mc TEGRA210_MC_DISPLAY0C &emc>,
-					<&mc TEGRA210_MC_DISPLAYHC &emc>,
-					<&mc TEGRA210_MC_DISPLAYD &emc>,
-					<&mc TEGRA210_MC_DISPLAYT &emc>;
-			interconnect-names = "wina",
-					     "winb",
-					     "winc",
-					     "cursor",
-					     "wind",
-					     "wint";
 		};
 
 		dc@54240000 {
@@ -230,15 +217,6 @@ dc@54240000 {
 
 			nvidia,outputs = <&dsia &dsib &sor0 &sor1>;
 			nvidia,head = <1>;
-
-			interconnects = <&mc TEGRA210_MC_DISPLAY0AB &emc>,
-					<&mc TEGRA210_MC_DISPLAY0BB &emc>,
-					<&mc TEGRA210_MC_DISPLAY0CB &emc>,
-					<&mc TEGRA210_MC_DISPLAYHCB &emc>;
-			interconnect-names = "wina",
-					     "winb",
-					     "winc",
-					     "cursor";
 		};
 
 		dsia: dsi@54300000 {
@@ -1052,7 +1030,6 @@ mc: memory-controller@70019000 {
 
 		#iommu-cells = <1>;
 		#reset-cells = <1>;
-		#interconnect-cells = <1>;
 	};
 
 	emc: external-memory-controller@7001b000 {
@@ -1066,7 +1043,6 @@ emc: external-memory-controller@7001b000 {
 		nvidia,memory-controller = <&mc>;
 		operating-points-v2 = <&emc_icc_dvfs_opp_table>;
 
-		#interconnect-cells = <0>;
 		#cooling-cells = <2>;
 	};
 
-- 
2.43.0

Re: [PATCH] Revert "arm64: tegra: Add interconnect properties for Tegra210"

[Aaron Kling]

On Wed, Dec 17, 2025 at 4:48 AM Jon Hunter <jonathanh@nvidia.com> wrote:
>
> Commit 59a42707a094 ("arm64: tegra: Add interconnect properties for
> Tegra210") populated interconnect properties for Tegra210 and this is
> preventing the Tegra DRM driver from probing successfully. The following
> error is observed on boot ...
>
>  drm drm: failed to initialize 54240000.dc: -517
>
> For now revert this change, until a fix is available.
>
> Fixes: 59a42707a094 ("arm64: tegra: Add interconnect properties for Tegra210")
> Signed-off-by: Jon Hunter <jonathanh@nvidia.com>
> ---
>  arch/arm64/boot/dts/nvidia/tegra210.dtsi | 24 ------------------------
>  1 file changed, 24 deletions(-)
>
> diff --git a/arch/arm64/boot/dts/nvidia/tegra210.dtsi b/arch/arm64/boot/dts/nvidia/tegra210.dtsi
> index 709da31d5785..137aa8375257 100644
> --- a/arch/arm64/boot/dts/nvidia/tegra210.dtsi
> +++ b/arch/arm64/boot/dts/nvidia/tegra210.dtsi
> @@ -202,19 +202,6 @@ dc@54200000 {
>
>                         nvidia,outputs = <&dsia &dsib &sor0 &sor1>;
>                         nvidia,head = <0>;
> -
> -                       interconnects = <&mc TEGRA210_MC_DISPLAY0A &emc>,
> -                                       <&mc TEGRA210_MC_DISPLAY0B &emc>,
> -                                       <&mc TEGRA210_MC_DISPLAY0C &emc>,
> -                                       <&mc TEGRA210_MC_DISPLAYHC &emc>,
> -                                       <&mc TEGRA210_MC_DISPLAYD &emc>,
> -                                       <&mc TEGRA210_MC_DISPLAYT &emc>;
> -                       interconnect-names = "wina",
> -                                            "winb",
> -                                            "winc",
> -                                            "cursor",
> -                                            "wind",
> -                                            "wint";
>                 };
>
>                 dc@54240000 {
> @@ -230,15 +217,6 @@ dc@54240000 {
>
>                         nvidia,outputs = <&dsia &dsib &sor0 &sor1>;
>                         nvidia,head = <1>;
> -
> -                       interconnects = <&mc TEGRA210_MC_DISPLAY0AB &emc>,
> -                                       <&mc TEGRA210_MC_DISPLAY0BB &emc>,
> -                                       <&mc TEGRA210_MC_DISPLAY0CB &emc>,
> -                                       <&mc TEGRA210_MC_DISPLAYHCB &emc>;
> -                       interconnect-names = "wina",
> -                                            "winb",
> -                                            "winc",
> -                                            "cursor";
>                 };
>
>                 dsia: dsi@54300000 {
> @@ -1052,7 +1030,6 @@ mc: memory-controller@70019000 {
>
>                 #iommu-cells = <1>;
>                 #reset-cells = <1>;
> -               #interconnect-cells = <1>;
>         };
>
>         emc: external-memory-controller@7001b000 {
> @@ -1066,7 +1043,6 @@ emc: external-memory-controller@7001b000 {
>                 nvidia,memory-controller = <&mc>;
>                 operating-points-v2 = <&emc_icc_dvfs_opp_table>;
>
> -               #interconnect-cells = <0>;
>                 #cooling-cells = <2>;
>         };
>
> --
> 2.43.0
>

A little bit of documentation on this, should someone read the list to
see what happened. The original report of the failure is here [0] and
only occurred when the tegra210-emc driver fails to probe. After this
report, the related code change [1] to tegra210-emc which registers
the driver to icc was silently dropped from -next, but these dt
changes remained. So now these interconnect routes do cause tegra-drm
to universally fail on tegra210.

Aaron

[0] https://lore.kernel.org/all/56aed0ec-b104-4612-8901-3f6f95e0afab@nvidia.com/
[1] https://lore.kernel.org/all/20251027-t210-actmon-p2-v6-1-1c4bd227d676@gmail.com/

Re: [PATCH] Revert "arm64: tegra: Add interconnect properties for Tegra210"

[Aaron Kling]

On Wed, Dec 17, 2025 at 12:20 PM Aaron Kling <webgeek1234@gmail.com> wrote:
>
> On Wed, Dec 17, 2025 at 4:48 AM Jon Hunter <jonathanh@nvidia.com> wrote:
> >
> > Commit 59a42707a094 ("arm64: tegra: Add interconnect properties for
> > Tegra210") populated interconnect properties for Tegra210 and this is
> > preventing the Tegra DRM driver from probing successfully. The following
> > error is observed on boot ...
> >
> >  drm drm: failed to initialize 54240000.dc: -517
> >
> > For now revert this change, until a fix is available.
> >
> > Fixes: 59a42707a094 ("arm64: tegra: Add interconnect properties for Tegra210")
> > Signed-off-by: Jon Hunter <jonathanh@nvidia.com>
> > ---
> >  arch/arm64/boot/dts/nvidia/tegra210.dtsi | 24 ------------------------
> >  1 file changed, 24 deletions(-)
> >
> > diff --git a/arch/arm64/boot/dts/nvidia/tegra210.dtsi b/arch/arm64/boot/dts/nvidia/tegra210.dtsi
> > index 709da31d5785..137aa8375257 100644
> > --- a/arch/arm64/boot/dts/nvidia/tegra210.dtsi
> > +++ b/arch/arm64/boot/dts/nvidia/tegra210.dtsi
> > @@ -202,19 +202,6 @@ dc@54200000 {
> >
> >                         nvidia,outputs = <&dsia &dsib &sor0 &sor1>;
> >                         nvidia,head = <0>;
> > -
> > -                       interconnects = <&mc TEGRA210_MC_DISPLAY0A &emc>,
> > -                                       <&mc TEGRA210_MC_DISPLAY0B &emc>,
> > -                                       <&mc TEGRA210_MC_DISPLAY0C &emc>,
> > -                                       <&mc TEGRA210_MC_DISPLAYHC &emc>,
> > -                                       <&mc TEGRA210_MC_DISPLAYD &emc>,
> > -                                       <&mc TEGRA210_MC_DISPLAYT &emc>;
> > -                       interconnect-names = "wina",
> > -                                            "winb",
> > -                                            "winc",
> > -                                            "cursor",
> > -                                            "wind",
> > -                                            "wint";
> >                 };
> >
> >                 dc@54240000 {
> > @@ -230,15 +217,6 @@ dc@54240000 {
> >
> >                         nvidia,outputs = <&dsia &dsib &sor0 &sor1>;
> >                         nvidia,head = <1>;
> > -
> > -                       interconnects = <&mc TEGRA210_MC_DISPLAY0AB &emc>,
> > -                                       <&mc TEGRA210_MC_DISPLAY0BB &emc>,
> > -                                       <&mc TEGRA210_MC_DISPLAY0CB &emc>,
> > -                                       <&mc TEGRA210_MC_DISPLAYHCB &emc>;
> > -                       interconnect-names = "wina",
> > -                                            "winb",
> > -                                            "winc",
> > -                                            "cursor";
> >                 };
> >
> >                 dsia: dsi@54300000 {
> > @@ -1052,7 +1030,6 @@ mc: memory-controller@70019000 {
> >
> >                 #iommu-cells = <1>;
> >                 #reset-cells = <1>;
> > -               #interconnect-cells = <1>;
> >         };
> >
> >         emc: external-memory-controller@7001b000 {
> > @@ -1066,7 +1043,6 @@ emc: external-memory-controller@7001b000 {
> >                 nvidia,memory-controller = <&mc>;
> >                 operating-points-v2 = <&emc_icc_dvfs_opp_table>;
> >
> > -               #interconnect-cells = <0>;
> >                 #cooling-cells = <2>;
> >         };
> >
> > --
> > 2.43.0
> >
>
> A little bit of documentation on this, should someone read the list to
> see what happened. The original report of the failure is here [0] and
> only occurred when the tegra210-emc driver fails to probe. After this
> report, the related code change [1] to tegra210-emc which registers
> the driver to icc was silently dropped from -next, but these dt
> changes remained. So now these interconnect routes do cause tegra-drm
> to universally fail on tegra210.
>
> Aaron
>
> [0] https://lore.kernel.org/all/56aed0ec-b104-4612-8901-3f6f95e0afab@nvidia.com/
> [1] https://lore.kernel.org/all/20251027-t210-actmon-p2-v6-1-1c4bd227d676@gmail.com/

There may be another option here. I'm beginning to think there will
not be any way to set the icc routes for the dc's while the emc driver
can fail to probe. The next best thing looks to be just dropping the
interconnect nodes from the dc nodes and leaving the rest of the
original commit in place. Then reland the tegra210-emc driver change.
This should put the no-emc case back to where it was, while allowing
actmon to do its scaling when emc is available. And I will move to the
dc icc routes to downstream dt's, where I tightly control that emc is
available.

Does this sound reasonable? If so, I will go stage the changes and
verify that it works as intended.

Aaron

Re: [PATCH] Revert "arm64: tegra: Add interconnect properties for Tegra210"

[Thierry Reding]

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

On Wed, Dec 17, 2025 at 02:42:58PM -0600, Aaron Kling wrote:
> On Wed, Dec 17, 2025 at 12:20 PM Aaron Kling <webgeek1234@gmail.com> wrote:
> >
> > On Wed, Dec 17, 2025 at 4:48 AM Jon Hunter <jonathanh@nvidia.com> wrote:
> > >
> > > Commit 59a42707a094 ("arm64: tegra: Add interconnect properties for
> > > Tegra210") populated interconnect properties for Tegra210 and this is
> > > preventing the Tegra DRM driver from probing successfully. The following
> > > error is observed on boot ...
> > >
> > >  drm drm: failed to initialize 54240000.dc: -517
> > >
> > > For now revert this change, until a fix is available.
> > >
> > > Fixes: 59a42707a094 ("arm64: tegra: Add interconnect properties for Tegra210")
> > > Signed-off-by: Jon Hunter <jonathanh@nvidia.com>
> > > ---
> > >  arch/arm64/boot/dts/nvidia/tegra210.dtsi | 24 ------------------------
> > >  1 file changed, 24 deletions(-)
> > >
> > > diff --git a/arch/arm64/boot/dts/nvidia/tegra210.dtsi b/arch/arm64/boot/dts/nvidia/tegra210.dtsi
> > > index 709da31d5785..137aa8375257 100644
> > > --- a/arch/arm64/boot/dts/nvidia/tegra210.dtsi
> > > +++ b/arch/arm64/boot/dts/nvidia/tegra210.dtsi
> > > @@ -202,19 +202,6 @@ dc@54200000 {
> > >
> > >                         nvidia,outputs = <&dsia &dsib &sor0 &sor1>;
> > >                         nvidia,head = <0>;
> > > -
> > > -                       interconnects = <&mc TEGRA210_MC_DISPLAY0A &emc>,
> > > -                                       <&mc TEGRA210_MC_DISPLAY0B &emc>,
> > > -                                       <&mc TEGRA210_MC_DISPLAY0C &emc>,
> > > -                                       <&mc TEGRA210_MC_DISPLAYHC &emc>,
> > > -                                       <&mc TEGRA210_MC_DISPLAYD &emc>,
> > > -                                       <&mc TEGRA210_MC_DISPLAYT &emc>;
> > > -                       interconnect-names = "wina",
> > > -                                            "winb",
> > > -                                            "winc",
> > > -                                            "cursor",
> > > -                                            "wind",
> > > -                                            "wint";
> > >                 };
> > >
> > >                 dc@54240000 {
> > > @@ -230,15 +217,6 @@ dc@54240000 {
> > >
> > >                         nvidia,outputs = <&dsia &dsib &sor0 &sor1>;
> > >                         nvidia,head = <1>;
> > > -
> > > -                       interconnects = <&mc TEGRA210_MC_DISPLAY0AB &emc>,
> > > -                                       <&mc TEGRA210_MC_DISPLAY0BB &emc>,
> > > -                                       <&mc TEGRA210_MC_DISPLAY0CB &emc>,
> > > -                                       <&mc TEGRA210_MC_DISPLAYHCB &emc>;
> > > -                       interconnect-names = "wina",
> > > -                                            "winb",
> > > -                                            "winc",
> > > -                                            "cursor";
> > >                 };
> > >
> > >                 dsia: dsi@54300000 {
> > > @@ -1052,7 +1030,6 @@ mc: memory-controller@70019000 {
> > >
> > >                 #iommu-cells = <1>;
> > >                 #reset-cells = <1>;
> > > -               #interconnect-cells = <1>;
> > >         };
> > >
> > >         emc: external-memory-controller@7001b000 {
> > > @@ -1066,7 +1043,6 @@ emc: external-memory-controller@7001b000 {
> > >                 nvidia,memory-controller = <&mc>;
> > >                 operating-points-v2 = <&emc_icc_dvfs_opp_table>;
> > >
> > > -               #interconnect-cells = <0>;
> > >                 #cooling-cells = <2>;
> > >         };
> > >
> > > --
> > > 2.43.0
> > >
> >
> > A little bit of documentation on this, should someone read the list to
> > see what happened. The original report of the failure is here [0] and
> > only occurred when the tegra210-emc driver fails to probe. After this
> > report, the related code change [1] to tegra210-emc which registers
> > the driver to icc was silently dropped from -next, but these dt
> > changes remained. So now these interconnect routes do cause tegra-drm
> > to universally fail on tegra210.
> >
> > Aaron
> >
> > [0] https://lore.kernel.org/all/56aed0ec-b104-4612-8901-3f6f95e0afab@nvidia.com/
> > [1] https://lore.kernel.org/all/20251027-t210-actmon-p2-v6-1-1c4bd227d676@gmail.com/
> 
> There may be another option here. I'm beginning to think there will
> not be any way to set the icc routes for the dc's while the emc driver
> can fail to probe. The next best thing looks to be just dropping the
> interconnect nodes from the dc nodes and leaving the rest of the
> original commit in place. Then reland the tegra210-emc driver change.
> This should put the no-emc case back to where it was, while allowing
> actmon to do its scaling when emc is available. And I will move to the
> dc icc routes to downstream dt's, where I tightly control that emc is
> available.
> 
> Does this sound reasonable? If so, I will go stage the changes and
> verify that it works as intended.

Let's go with the revert for now, since that clearly documents where
things go wrong and it can be easily reapplied once the root cause has
been resolved.

It's a bit unfortunate that we don't have a way of making these
interconnect properties optional. If EMC fails to probe for whatever
reason, I think the assumption should be that it doesn't do any dynamic
scaling of the EMC frequency and hence the entire ICC stuff isn't needed
and should just be no-ops.

On the other hand, other than the patches getting reverted, there's
really no good reason for the EMC driver to fail to provide them, hence
I think once that's been restored we can apply this again and then that
should be the end of it.

Thierry

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

Re: [PATCH] Revert "arm64: tegra: Add interconnect properties for Tegra210"

[Aaron Kling]

On Thu, Dec 18, 2025 at 6:00 AM Thierry Reding <thierry.reding@gmail.com> wrote:
>
> On Wed, Dec 17, 2025 at 02:42:58PM -0600, Aaron Kling wrote:
> > On Wed, Dec 17, 2025 at 12:20 PM Aaron Kling <webgeek1234@gmail.com> wrote:
> > >
> > > On Wed, Dec 17, 2025 at 4:48 AM Jon Hunter <jonathanh@nvidia.com> wrote:
> > > >
> > > > Commit 59a42707a094 ("arm64: tegra: Add interconnect properties for
> > > > Tegra210") populated interconnect properties for Tegra210 and this is
> > > > preventing the Tegra DRM driver from probing successfully. The following
> > > > error is observed on boot ...
> > > >
> > > >  drm drm: failed to initialize 54240000.dc: -517
> > > >
> > > > For now revert this change, until a fix is available.
> > > >
> > > > Fixes: 59a42707a094 ("arm64: tegra: Add interconnect properties for Tegra210")
> > > > Signed-off-by: Jon Hunter <jonathanh@nvidia.com>
> > > > ---
> > > >  arch/arm64/boot/dts/nvidia/tegra210.dtsi | 24 ------------------------
> > > >  1 file changed, 24 deletions(-)
> > > >
> > > > diff --git a/arch/arm64/boot/dts/nvidia/tegra210.dtsi b/arch/arm64/boot/dts/nvidia/tegra210.dtsi
> > > > index 709da31d5785..137aa8375257 100644
> > > > --- a/arch/arm64/boot/dts/nvidia/tegra210.dtsi
> > > > +++ b/arch/arm64/boot/dts/nvidia/tegra210.dtsi
> > > > @@ -202,19 +202,6 @@ dc@54200000 {
> > > >
> > > >                         nvidia,outputs = <&dsia &dsib &sor0 &sor1>;
> > > >                         nvidia,head = <0>;
> > > > -
> > > > -                       interconnects = <&mc TEGRA210_MC_DISPLAY0A &emc>,
> > > > -                                       <&mc TEGRA210_MC_DISPLAY0B &emc>,
> > > > -                                       <&mc TEGRA210_MC_DISPLAY0C &emc>,
> > > > -                                       <&mc TEGRA210_MC_DISPLAYHC &emc>,
> > > > -                                       <&mc TEGRA210_MC_DISPLAYD &emc>,
> > > > -                                       <&mc TEGRA210_MC_DISPLAYT &emc>;
> > > > -                       interconnect-names = "wina",
> > > > -                                            "winb",
> > > > -                                            "winc",
> > > > -                                            "cursor",
> > > > -                                            "wind",
> > > > -                                            "wint";
> > > >                 };
> > > >
> > > >                 dc@54240000 {
> > > > @@ -230,15 +217,6 @@ dc@54240000 {
> > > >
> > > >                         nvidia,outputs = <&dsia &dsib &sor0 &sor1>;
> > > >                         nvidia,head = <1>;
> > > > -
> > > > -                       interconnects = <&mc TEGRA210_MC_DISPLAY0AB &emc>,
> > > > -                                       <&mc TEGRA210_MC_DISPLAY0BB &emc>,
> > > > -                                       <&mc TEGRA210_MC_DISPLAY0CB &emc>,
> > > > -                                       <&mc TEGRA210_MC_DISPLAYHCB &emc>;
> > > > -                       interconnect-names = "wina",
> > > > -                                            "winb",
> > > > -                                            "winc",
> > > > -                                            "cursor";
> > > >                 };
> > > >
> > > >                 dsia: dsi@54300000 {
> > > > @@ -1052,7 +1030,6 @@ mc: memory-controller@70019000 {
> > > >
> > > >                 #iommu-cells = <1>;
> > > >                 #reset-cells = <1>;
> > > > -               #interconnect-cells = <1>;
> > > >         };
> > > >
> > > >         emc: external-memory-controller@7001b000 {
> > > > @@ -1066,7 +1043,6 @@ emc: external-memory-controller@7001b000 {
> > > >                 nvidia,memory-controller = <&mc>;
> > > >                 operating-points-v2 = <&emc_icc_dvfs_opp_table>;
> > > >
> > > > -               #interconnect-cells = <0>;
> > > >                 #cooling-cells = <2>;
> > > >         };
> > > >
> > > > --
> > > > 2.43.0
> > > >
> > >
> > > A little bit of documentation on this, should someone read the list to
> > > see what happened. The original report of the failure is here [0] and
> > > only occurred when the tegra210-emc driver fails to probe. After this
> > > report, the related code change [1] to tegra210-emc which registers
> > > the driver to icc was silently dropped from -next, but these dt
> > > changes remained. So now these interconnect routes do cause tegra-drm
> > > to universally fail on tegra210.
> > >
> > > Aaron
> > >
> > > [0] https://lore.kernel.org/all/56aed0ec-b104-4612-8901-3f6f95e0afab@nvidia.com/
> > > [1] https://lore.kernel.org/all/20251027-t210-actmon-p2-v6-1-1c4bd227d676@gmail.com/
> >
> > There may be another option here. I'm beginning to think there will
> > not be any way to set the icc routes for the dc's while the emc driver
> > can fail to probe. The next best thing looks to be just dropping the
> > interconnect nodes from the dc nodes and leaving the rest of the
> > original commit in place. Then reland the tegra210-emc driver change.
> > This should put the no-emc case back to where it was, while allowing
> > actmon to do its scaling when emc is available. And I will move to the
> > dc icc routes to downstream dt's, where I tightly control that emc is
> > available.
> >
> > Does this sound reasonable? If so, I will go stage the changes and
> > verify that it works as intended.
>
> Let's go with the revert for now, since that clearly documents where
> things go wrong and it can be easily reapplied once the root cause has
> been resolved.
>
> It's a bit unfortunate that we don't have a way of making these
> interconnect properties optional. If EMC fails to probe for whatever
> reason, I think the assumption should be that it doesn't do any dynamic
> scaling of the EMC frequency and hence the entire ICC stuff isn't needed
> and should just be no-ops.
>
> On the other hand, other than the patches getting reverted, there's
> really no good reason for the EMC driver to fail to provide them, hence
> I think once that's been restored we can apply this again and then that
> should be the end of it.

Except that the tegra210-emc driver fails to probe at all if the
bootloader does not copy reserved-memory table node? Which per Jon,
the Nvidia regression bench does not do. And neither will a normal L4T
install using a mainline kernel and dt via extlinux or u-boot. I have
to put the mainline kernel on DTB and use a kernel in an android boot
image, which causes nvtboot-cpu to set the dt table reserved memory
node directly. Which is perfectly fine for my android use case, but
not so much for anyone just trying to boot a Linux distro.

I have wondered how the reserved memory dt tables were verified when
that support was initially added. And if the regression bench can be
set up like that. Because right now, emc fails to probe there, meaning
there's no test coverage for the driver.

Aaron

Re: [PATCH] Revert "arm64: tegra: Add interconnect properties for Tegra210"

[Jon Hunter]

On 18/12/2025 19:07, Aaron Kling wrote:
> On Thu, Dec 18, 2025 at 6:00 AM Thierry Reding <thierry.reding@gmail.com> wrote:
>>
>> On Wed, Dec 17, 2025 at 02:42:58PM -0600, Aaron Kling wrote:
>>> On Wed, Dec 17, 2025 at 12:20 PM Aaron Kling <webgeek1234@gmail.com> wrote:
>>>>
>>>> On Wed, Dec 17, 2025 at 4:48 AM Jon Hunter <jonathanh@nvidia.com> wrote:
>>>>>
>>>>> Commit 59a42707a094 ("arm64: tegra: Add interconnect properties for
>>>>> Tegra210") populated interconnect properties for Tegra210 and this is
>>>>> preventing the Tegra DRM driver from probing successfully. The following
>>>>> error is observed on boot ...
>>>>>
>>>>>   drm drm: failed to initialize 54240000.dc: -517
>>>>>
>>>>> For now revert this change, until a fix is available.
>>>>>
>>>>> Fixes: 59a42707a094 ("arm64: tegra: Add interconnect properties for Tegra210")
>>>>> Signed-off-by: Jon Hunter <jonathanh@nvidia.com>
>>>>> ---
>>>>>   arch/arm64/boot/dts/nvidia/tegra210.dtsi | 24 ------------------------
>>>>>   1 file changed, 24 deletions(-)
>>>>>
>>>>> diff --git a/arch/arm64/boot/dts/nvidia/tegra210.dtsi b/arch/arm64/boot/dts/nvidia/tegra210.dtsi
>>>>> index 709da31d5785..137aa8375257 100644
>>>>> --- a/arch/arm64/boot/dts/nvidia/tegra210.dtsi
>>>>> +++ b/arch/arm64/boot/dts/nvidia/tegra210.dtsi
>>>>> @@ -202,19 +202,6 @@ dc@54200000 {
>>>>>
>>>>>                          nvidia,outputs = <&dsia &dsib &sor0 &sor1>;
>>>>>                          nvidia,head = <0>;
>>>>> -
>>>>> -                       interconnects = <&mc TEGRA210_MC_DISPLAY0A &emc>,
>>>>> -                                       <&mc TEGRA210_MC_DISPLAY0B &emc>,
>>>>> -                                       <&mc TEGRA210_MC_DISPLAY0C &emc>,
>>>>> -                                       <&mc TEGRA210_MC_DISPLAYHC &emc>,
>>>>> -                                       <&mc TEGRA210_MC_DISPLAYD &emc>,
>>>>> -                                       <&mc TEGRA210_MC_DISPLAYT &emc>;
>>>>> -                       interconnect-names = "wina",
>>>>> -                                            "winb",
>>>>> -                                            "winc",
>>>>> -                                            "cursor",
>>>>> -                                            "wind",
>>>>> -                                            "wint";
>>>>>                  };
>>>>>
>>>>>                  dc@54240000 {
>>>>> @@ -230,15 +217,6 @@ dc@54240000 {
>>>>>
>>>>>                          nvidia,outputs = <&dsia &dsib &sor0 &sor1>;
>>>>>                          nvidia,head = <1>;
>>>>> -
>>>>> -                       interconnects = <&mc TEGRA210_MC_DISPLAY0AB &emc>,
>>>>> -                                       <&mc TEGRA210_MC_DISPLAY0BB &emc>,
>>>>> -                                       <&mc TEGRA210_MC_DISPLAY0CB &emc>,
>>>>> -                                       <&mc TEGRA210_MC_DISPLAYHCB &emc>;
>>>>> -                       interconnect-names = "wina",
>>>>> -                                            "winb",
>>>>> -                                            "winc",
>>>>> -                                            "cursor";
>>>>>                  };
>>>>>
>>>>>                  dsia: dsi@54300000 {
>>>>> @@ -1052,7 +1030,6 @@ mc: memory-controller@70019000 {
>>>>>
>>>>>                  #iommu-cells = <1>;
>>>>>                  #reset-cells = <1>;
>>>>> -               #interconnect-cells = <1>;
>>>>>          };
>>>>>
>>>>>          emc: external-memory-controller@7001b000 {
>>>>> @@ -1066,7 +1043,6 @@ emc: external-memory-controller@7001b000 {
>>>>>                  nvidia,memory-controller = <&mc>;
>>>>>                  operating-points-v2 = <&emc_icc_dvfs_opp_table>;
>>>>>
>>>>> -               #interconnect-cells = <0>;
>>>>>                  #cooling-cells = <2>;
>>>>>          };
>>>>>
>>>>> --
>>>>> 2.43.0
>>>>>
>>>>
>>>> A little bit of documentation on this, should someone read the list to
>>>> see what happened. The original report of the failure is here [0] and
>>>> only occurred when the tegra210-emc driver fails to probe. After this
>>>> report, the related code change [1] to tegra210-emc which registers
>>>> the driver to icc was silently dropped from -next, but these dt
>>>> changes remained. So now these interconnect routes do cause tegra-drm
>>>> to universally fail on tegra210.
>>>>
>>>> Aaron
>>>>
>>>> [0] https://lore.kernel.org/all/56aed0ec-b104-4612-8901-3f6f95e0afab@nvidia.com/
>>>> [1] https://lore.kernel.org/all/20251027-t210-actmon-p2-v6-1-1c4bd227d676@gmail.com/
>>>
>>> There may be another option here. I'm beginning to think there will
>>> not be any way to set the icc routes for the dc's while the emc driver
>>> can fail to probe. The next best thing looks to be just dropping the
>>> interconnect nodes from the dc nodes and leaving the rest of the
>>> original commit in place. Then reland the tegra210-emc driver change.
>>> This should put the no-emc case back to where it was, while allowing
>>> actmon to do its scaling when emc is available. And I will move to the
>>> dc icc routes to downstream dt's, where I tightly control that emc is
>>> available.
>>>
>>> Does this sound reasonable? If so, I will go stage the changes and
>>> verify that it works as intended.
>>
>> Let's go with the revert for now, since that clearly documents where
>> things go wrong and it can be easily reapplied once the root cause has
>> been resolved.
>>
>> It's a bit unfortunate that we don't have a way of making these
>> interconnect properties optional. If EMC fails to probe for whatever
>> reason, I think the assumption should be that it doesn't do any dynamic
>> scaling of the EMC frequency and hence the entire ICC stuff isn't needed
>> and should just be no-ops.
>>
>> On the other hand, other than the patches getting reverted, there's
>> really no good reason for the EMC driver to fail to provide them, hence
>> I think once that's been restored we can apply this again and then that
>> should be the end of it.
> 
> Except that the tegra210-emc driver fails to probe at all if the
> bootloader does not copy reserved-memory table node? Which per Jon,
> the Nvidia regression bench does not do. And neither will a normal L4T
> install using a mainline kernel and dt via extlinux or u-boot. I have
> to put the mainline kernel on DTB and use a kernel in an android boot
> image, which causes nvtboot-cpu to set the dt table reserved memory
> node directly. Which is perfectly fine for my android use case, but
> not so much for anyone just trying to boot a Linux distro.

I am lost. I was not able to follow the above. Our current testing 
simply boots the upstream kernel + upstream DTB.

> I have wondered how the reserved memory dt tables were verified when
> that support was initially added. And if the regression bench can be
> set up like that. Because right now, emc fails to probe there, meaning
> there's no test coverage for the driver.

We have limited testing, but it is better than nothing. We are always 
open to more testing. I avoid the downstream device-trees because of 
compatibility issues. And avoid the bootloader making modifications to 
the upstream device-tree. I understand that might limit some features, 
but as you can see those have not been supported upstream yet.

Jon

-- 
nvpublic

Re: [PATCH] Revert "arm64: tegra: Add interconnect properties for Tegra210"

[Aaron Kling]

On Fri, Dec 19, 2025 at 4:59 AM Jon Hunter <jonathanh@nvidia.com> wrote:
>
>
>
> On 18/12/2025 19:07, Aaron Kling wrote:
> > On Thu, Dec 18, 2025 at 6:00 AM Thierry Reding <thierry.reding@gmail.com> wrote:
> >>
> >> On Wed, Dec 17, 2025 at 02:42:58PM -0600, Aaron Kling wrote:
> >>> On Wed, Dec 17, 2025 at 12:20 PM Aaron Kling <webgeek1234@gmail.com> wrote:
> >>>>
> >>>> On Wed, Dec 17, 2025 at 4:48 AM Jon Hunter <jonathanh@nvidia.com> wrote:
> >>>>>
> >>>>> Commit 59a42707a094 ("arm64: tegra: Add interconnect properties for
> >>>>> Tegra210") populated interconnect properties for Tegra210 and this is
> >>>>> preventing the Tegra DRM driver from probing successfully. The following
> >>>>> error is observed on boot ...
> >>>>>
> >>>>>   drm drm: failed to initialize 54240000.dc: -517
> >>>>>
> >>>>> For now revert this change, until a fix is available.
> >>>>>
> >>>>> Fixes: 59a42707a094 ("arm64: tegra: Add interconnect properties for Tegra210")
> >>>>> Signed-off-by: Jon Hunter <jonathanh@nvidia.com>
> >>>>> ---
> >>>>>   arch/arm64/boot/dts/nvidia/tegra210.dtsi | 24 ------------------------
> >>>>>   1 file changed, 24 deletions(-)
> >>>>>
> >>>>> diff --git a/arch/arm64/boot/dts/nvidia/tegra210.dtsi b/arch/arm64/boot/dts/nvidia/tegra210.dtsi
> >>>>> index 709da31d5785..137aa8375257 100644
> >>>>> --- a/arch/arm64/boot/dts/nvidia/tegra210.dtsi
> >>>>> +++ b/arch/arm64/boot/dts/nvidia/tegra210.dtsi
> >>>>> @@ -202,19 +202,6 @@ dc@54200000 {
> >>>>>
> >>>>>                          nvidia,outputs = <&dsia &dsib &sor0 &sor1>;
> >>>>>                          nvidia,head = <0>;
> >>>>> -
> >>>>> -                       interconnects = <&mc TEGRA210_MC_DISPLAY0A &emc>,
> >>>>> -                                       <&mc TEGRA210_MC_DISPLAY0B &emc>,
> >>>>> -                                       <&mc TEGRA210_MC_DISPLAY0C &emc>,
> >>>>> -                                       <&mc TEGRA210_MC_DISPLAYHC &emc>,
> >>>>> -                                       <&mc TEGRA210_MC_DISPLAYD &emc>,
> >>>>> -                                       <&mc TEGRA210_MC_DISPLAYT &emc>;
> >>>>> -                       interconnect-names = "wina",
> >>>>> -                                            "winb",
> >>>>> -                                            "winc",
> >>>>> -                                            "cursor",
> >>>>> -                                            "wind",
> >>>>> -                                            "wint";
> >>>>>                  };
> >>>>>
> >>>>>                  dc@54240000 {
> >>>>> @@ -230,15 +217,6 @@ dc@54240000 {
> >>>>>
> >>>>>                          nvidia,outputs = <&dsia &dsib &sor0 &sor1>;
> >>>>>                          nvidia,head = <1>;
> >>>>> -
> >>>>> -                       interconnects = <&mc TEGRA210_MC_DISPLAY0AB &emc>,
> >>>>> -                                       <&mc TEGRA210_MC_DISPLAY0BB &emc>,
> >>>>> -                                       <&mc TEGRA210_MC_DISPLAY0CB &emc>,
> >>>>> -                                       <&mc TEGRA210_MC_DISPLAYHCB &emc>;
> >>>>> -                       interconnect-names = "wina",
> >>>>> -                                            "winb",
> >>>>> -                                            "winc",
> >>>>> -                                            "cursor";
> >>>>>                  };
> >>>>>
> >>>>>                  dsia: dsi@54300000 {
> >>>>> @@ -1052,7 +1030,6 @@ mc: memory-controller@70019000 {
> >>>>>
> >>>>>                  #iommu-cells = <1>;
> >>>>>                  #reset-cells = <1>;
> >>>>> -               #interconnect-cells = <1>;
> >>>>>          };
> >>>>>
> >>>>>          emc: external-memory-controller@7001b000 {
> >>>>> @@ -1066,7 +1043,6 @@ emc: external-memory-controller@7001b000 {
> >>>>>                  nvidia,memory-controller = <&mc>;
> >>>>>                  operating-points-v2 = <&emc_icc_dvfs_opp_table>;
> >>>>>
> >>>>> -               #interconnect-cells = <0>;
> >>>>>                  #cooling-cells = <2>;
> >>>>>          };
> >>>>>
> >>>>> --
> >>>>> 2.43.0
> >>>>>
> >>>>
> >>>> A little bit of documentation on this, should someone read the list to
> >>>> see what happened. The original report of the failure is here [0] and
> >>>> only occurred when the tegra210-emc driver fails to probe. After this
> >>>> report, the related code change [1] to tegra210-emc which registers
> >>>> the driver to icc was silently dropped from -next, but these dt
> >>>> changes remained. So now these interconnect routes do cause tegra-drm
> >>>> to universally fail on tegra210.
> >>>>
> >>>> Aaron
> >>>>
> >>>> [0] https://lore.kernel.org/all/56aed0ec-b104-4612-8901-3f6f95e0afab@nvidia.com/
> >>>> [1] https://lore.kernel.org/all/20251027-t210-actmon-p2-v6-1-1c4bd227d676@gmail.com/
> >>>
> >>> There may be another option here. I'm beginning to think there will
> >>> not be any way to set the icc routes for the dc's while the emc driver
> >>> can fail to probe. The next best thing looks to be just dropping the
> >>> interconnect nodes from the dc nodes and leaving the rest of the
> >>> original commit in place. Then reland the tegra210-emc driver change.
> >>> This should put the no-emc case back to where it was, while allowing
> >>> actmon to do its scaling when emc is available. And I will move to the
> >>> dc icc routes to downstream dt's, where I tightly control that emc is
> >>> available.
> >>>
> >>> Does this sound reasonable? If so, I will go stage the changes and
> >>> verify that it works as intended.
> >>
> >> Let's go with the revert for now, since that clearly documents where
> >> things go wrong and it can be easily reapplied once the root cause has
> >> been resolved.
> >>
> >> It's a bit unfortunate that we don't have a way of making these
> >> interconnect properties optional. If EMC fails to probe for whatever
> >> reason, I think the assumption should be that it doesn't do any dynamic
> >> scaling of the EMC frequency and hence the entire ICC stuff isn't needed
> >> and should just be no-ops.
> >>
> >> On the other hand, other than the patches getting reverted, there's
> >> really no good reason for the EMC driver to fail to provide them, hence
> >> I think once that's been restored we can apply this again and then that
> >> should be the end of it.
> >
> > Except that the tegra210-emc driver fails to probe at all if the
> > bootloader does not copy reserved-memory table node? Which per Jon,
> > the Nvidia regression bench does not do. And neither will a normal L4T
> > install using a mainline kernel and dt via extlinux or u-boot. I have
> > to put the mainline kernel on DTB and use a kernel in an android boot
> > image, which causes nvtboot-cpu to set the dt table reserved memory
> > node directly. Which is perfectly fine for my android use case, but
> > not so much for anyone just trying to boot a Linux distro.
>
> I am lost. I was not able to follow the above. Our current testing
> simply boots the upstream kernel + upstream DTB.

Per the conversation on the p3450 mts bug workaround patch [0], the
conclusion was reached that the regression test setup does not pass
the emc tables to a mainline kernel. And as I described earlier in
that thread, neither will a normal L4T install. Which means the
tegra210-emc driver will always fail to probe unless the device is
flashed in the way I do for Android. If there's another way to get
that reserved ram node passed to a mainline kernel, I am unaware of
it.

> > I have wondered how the reserved memory dt tables were verified when
> > that support was initially added. And if the regression bench can be
> > set up like that. Because right now, emc fails to probe there, meaning
> > there's no test coverage for the driver.
>
> We have limited testing, but it is better than nothing. We are always
> open to more testing. I avoid the downstream device-trees because of
> compatibility issues. And avoid the bootloader making modifications to
> the upstream device-tree. I understand that might limit some features,
> but as you can see those have not been supported upstream yet.

This isn't about upstream or downstream device trees, it's about what
the bootloader sets to the in-ram dt during boot, namely for this
case: the emc tables reserved ram node. Which is currently supported
by tegra210-emc.

Aaron

[0] https://lore.kernel.org/all/00c5e342-50c7-44e6-89d3-3b879742c204@nvidia.com/

Re: [PATCH] Revert "arm64: tegra: Add interconnect properties for Tegra210"

[Nicolas Chauvet]

Le ven. 19 déc. 2025 à 11:59, Jon Hunter <jonathanh@nvidia.com> a écrit :
>
>
>
> On 18/12/2025 19:07, Aaron Kling wrote:
> > On Thu, Dec 18, 2025 at 6:00 AM Thierry Reding <thierry.reding@gmail.com> wrote:
> >>
> >> On Wed, Dec 17, 2025 at 02:42:58PM -0600, Aaron Kling wrote:
> >>> On Wed, Dec 17, 2025 at 12:20 PM Aaron Kling <webgeek1234@gmail.com> wrote:
> >>>>
> >>>> On Wed, Dec 17, 2025 at 4:48 AM Jon Hunter <jonathanh@nvidia.com> wrote:
> >>>>>
> >>>>> Commit 59a42707a094 ("arm64: tegra: Add interconnect properties for
> >>>>> Tegra210") populated interconnect properties for Tegra210 and this is
> >>>>> preventing the Tegra DRM driver from probing successfully. The following
> >>>>> error is observed on boot ...
> >>>>>
> >>>>>   drm drm: failed to initialize 54240000.dc: -517
> >>>>>
> >>>>> For now revert this change, until a fix is available.
> >>>>>
> >>>>> Fixes: 59a42707a094 ("arm64: tegra: Add interconnect properties for Tegra210")
> >>>>> Signed-off-by: Jon Hunter <jonathanh@nvidia.com>
> >>>>> ---
> >>>>>   arch/arm64/boot/dts/nvidia/tegra210.dtsi | 24 ------------------------
> >>>>>   1 file changed, 24 deletions(-)
> >>>>>
> >>>>> diff --git a/arch/arm64/boot/dts/nvidia/tegra210.dtsi b/arch/arm64/boot/dts/nvidia/tegra210.dtsi
> >>>>> index 709da31d5785..137aa8375257 100644
> >>>>> --- a/arch/arm64/boot/dts/nvidia/tegra210.dtsi
> >>>>> +++ b/arch/arm64/boot/dts/nvidia/tegra210.dtsi
> >>>>> @@ -202,19 +202,6 @@ dc@54200000 {
> >>>>>
> >>>>>                          nvidia,outputs = <&dsia &dsib &sor0 &sor1>;
> >>>>>                          nvidia,head = <0>;
> >>>>> -
> >>>>> -                       interconnects = <&mc TEGRA210_MC_DISPLAY0A &emc>,
> >>>>> -                                       <&mc TEGRA210_MC_DISPLAY0B &emc>,
> >>>>> -                                       <&mc TEGRA210_MC_DISPLAY0C &emc>,
> >>>>> -                                       <&mc TEGRA210_MC_DISPLAYHC &emc>,
> >>>>> -                                       <&mc TEGRA210_MC_DISPLAYD &emc>,
> >>>>> -                                       <&mc TEGRA210_MC_DISPLAYT &emc>;
> >>>>> -                       interconnect-names = "wina",
> >>>>> -                                            "winb",
> >>>>> -                                            "winc",
> >>>>> -                                            "cursor",
> >>>>> -                                            "wind",
> >>>>> -                                            "wint";
> >>>>>                  };
> >>>>>
> >>>>>                  dc@54240000 {
> >>>>> @@ -230,15 +217,6 @@ dc@54240000 {
> >>>>>
> >>>>>                          nvidia,outputs = <&dsia &dsib &sor0 &sor1>;
> >>>>>                          nvidia,head = <1>;
> >>>>> -
> >>>>> -                       interconnects = <&mc TEGRA210_MC_DISPLAY0AB &emc>,
> >>>>> -                                       <&mc TEGRA210_MC_DISPLAY0BB &emc>,
> >>>>> -                                       <&mc TEGRA210_MC_DISPLAY0CB &emc>,
> >>>>> -                                       <&mc TEGRA210_MC_DISPLAYHCB &emc>;
> >>>>> -                       interconnect-names = "wina",
> >>>>> -                                            "winb",
> >>>>> -                                            "winc",
> >>>>> -                                            "cursor";
> >>>>>                  };
> >>>>>
> >>>>>                  dsia: dsi@54300000 {
> >>>>> @@ -1052,7 +1030,6 @@ mc: memory-controller@70019000 {
> >>>>>
> >>>>>                  #iommu-cells = <1>;
> >>>>>                  #reset-cells = <1>;
> >>>>> -               #interconnect-cells = <1>;
> >>>>>          };
> >>>>>
> >>>>>          emc: external-memory-controller@7001b000 {
> >>>>> @@ -1066,7 +1043,6 @@ emc: external-memory-controller@7001b000 {
> >>>>>                  nvidia,memory-controller = <&mc>;
> >>>>>                  operating-points-v2 = <&emc_icc_dvfs_opp_table>;
> >>>>>
> >>>>> -               #interconnect-cells = <0>;
> >>>>>                  #cooling-cells = <2>;
> >>>>>          };
> >>>>>
> >>>>> --
> >>>>> 2.43.0
> >>>>>
> >>>>
> >>>> A little bit of documentation on this, should someone read the list to
> >>>> see what happened. The original report of the failure is here [0] and
> >>>> only occurred when the tegra210-emc driver fails to probe. After this
> >>>> report, the related code change [1] to tegra210-emc which registers
> >>>> the driver to icc was silently dropped from -next, but these dt
> >>>> changes remained. So now these interconnect routes do cause tegra-drm
> >>>> to universally fail on tegra210.
> >>>>
> >>>> Aaron
> >>>>
> >>>> [0] https://lore.kernel.org/all/56aed0ec-b104-4612-8901-3f6f95e0afab@nvidia.com/
> >>>> [1] https://lore.kernel.org/all/20251027-t210-actmon-p2-v6-1-1c4bd227d676@gmail.com/
> >>>
> >>> There may be another option here. I'm beginning to think there will
> >>> not be any way to set the icc routes for the dc's while the emc driver
> >>> can fail to probe. The next best thing looks to be just dropping the
> >>> interconnect nodes from the dc nodes and leaving the rest of the
> >>> original commit in place. Then reland the tegra210-emc driver change.
> >>> This should put the no-emc case back to where it was, while allowing
> >>> actmon to do its scaling when emc is available. And I will move to the
> >>> dc icc routes to downstream dt's, where I tightly control that emc is
> >>> available.
> >>>
> >>> Does this sound reasonable? If so, I will go stage the changes and
> >>> verify that it works as intended.
> >>
> >> Let's go with the revert for now, since that clearly documents where
> >> things go wrong and it can be easily reapplied once the root cause has
> >> been resolved.
> >>
> >> It's a bit unfortunate that we don't have a way of making these
> >> interconnect properties optional. If EMC fails to probe for whatever
> >> reason, I think the assumption should be that it doesn't do any dynamic
> >> scaling of the EMC frequency and hence the entire ICC stuff isn't needed
> >> and should just be no-ops.
> >>
> >> On the other hand, other than the patches getting reverted, there's
> >> really no good reason for the EMC driver to fail to provide them, hence
> >> I think once that's been restored we can apply this again and then that
> >> should be the end of it.
> >
> > Except that the tegra210-emc driver fails to probe at all if the
> > bootloader does not copy reserved-memory table node? Which per Jon,
> > the Nvidia regression bench does not do. And neither will a normal L4T
> > install using a mainline kernel and dt via extlinux or u-boot. I have
> > to put the mainline kernel on DTB and use a kernel in an android boot
> > image, which causes nvtboot-cpu to set the dt table reserved memory
> > node directly. Which is perfectly fine for my android use case, but
> > not so much for anyone just trying to boot a Linux distro.
>
> I am lost. I was not able to follow the above. Our current testing
> simply boots the upstream kernel + upstream DTB.

With this revert, I have tegra drm back on 6.19-rc4 kernel.

But I also have this error that did not appear on 6.18:
"tegra210-emc 7001b000.external-memory-controller: failed to get
nominal EMC table: -19"

My boot flow is the latest L4T 32.7.6, upstream U-Boot 2025.01 and EFI boot.
U-Boot mentions:
Found DTB: nvidia/tegra210-p2371-2180.dtb
copying carveout for /host1x@50000000/dc@54200000...
copying carveout for /host1x@50000000/dc@54240000...
copying carveout for /external-memory-controller@7001b000..

That said, comparing in-tree dtb and runtime only shows few diffs.
(are more changes expected ?)

dtdiff /boot/dtbs/nvidia/tegra210-p2371-2180.dtb /proc/device-tree
--- /dev/fd/63    2026-01-05 21:20:39.956415634 +0100
+++ /dev/fd/62    2026-01-05 21:20:39.956415634 +0100
@@ -2207,6 +2207,12 @@
     };

     chosen {
+        bootargs = "BOOT_IMAGE=(hd0,msdos2)/vmlinuz-arm64
root=UUID=9bdc914f-f5c9-42cb-a4e9-9f3387f8d480 ro
rootflags=subvol=root console=ttyS0,115200 selinux=0 fbcon=rotate:3";
+        linux,uefi-mmap-desc-size = <0x28>;
+        linux,uefi-mmap-desc-ver = <0x01>;
+        linux,uefi-mmap-size = <0x528>;
+        linux,uefi-mmap-start = <0x00 0xfb568068>;
+        linux,uefi-system-table = <0x00 0xfed2bf80>;
         stdout-path = "serial0:115200n8";

         framebuffer {
---

Re: [PATCH] Revert "arm64: tegra: Add interconnect properties for Tegra210"

[Aaron Kling]

On Mon, Jan 5, 2026 at 2:27 PM Nicolas Chauvet <kwizart@gmail.com> wrote:
>
> Le ven. 19 déc. 2025 à 11:59, Jon Hunter <jonathanh@nvidia.com> a écrit :
> >
> >
> >
> > On 18/12/2025 19:07, Aaron Kling wrote:
> > > On Thu, Dec 18, 2025 at 6:00 AM Thierry Reding <thierry.reding@gmail.com> wrote:
> > >>
> > >> On Wed, Dec 17, 2025 at 02:42:58PM -0600, Aaron Kling wrote:
> > >>> On Wed, Dec 17, 2025 at 12:20 PM Aaron Kling <webgeek1234@gmail.com> wrote:
> > >>>>
> > >>>> On Wed, Dec 17, 2025 at 4:48 AM Jon Hunter <jonathanh@nvidia.com> wrote:
> > >>>>>
> > >>>>> Commit 59a42707a094 ("arm64: tegra: Add interconnect properties for
> > >>>>> Tegra210") populated interconnect properties for Tegra210 and this is
> > >>>>> preventing the Tegra DRM driver from probing successfully. The following
> > >>>>> error is observed on boot ...
> > >>>>>
> > >>>>>   drm drm: failed to initialize 54240000.dc: -517
> > >>>>>
> > >>>>> For now revert this change, until a fix is available.
> > >>>>>
> > >>>>> Fixes: 59a42707a094 ("arm64: tegra: Add interconnect properties for Tegra210")
> > >>>>> Signed-off-by: Jon Hunter <jonathanh@nvidia.com>
> > >>>>> ---
> > >>>>>   arch/arm64/boot/dts/nvidia/tegra210.dtsi | 24 ------------------------
> > >>>>>   1 file changed, 24 deletions(-)
> > >>>>>
> > >>>>> diff --git a/arch/arm64/boot/dts/nvidia/tegra210.dtsi b/arch/arm64/boot/dts/nvidia/tegra210.dtsi
> > >>>>> index 709da31d5785..137aa8375257 100644
> > >>>>> --- a/arch/arm64/boot/dts/nvidia/tegra210.dtsi
> > >>>>> +++ b/arch/arm64/boot/dts/nvidia/tegra210.dtsi
> > >>>>> @@ -202,19 +202,6 @@ dc@54200000 {
> > >>>>>
> > >>>>>                          nvidia,outputs = <&dsia &dsib &sor0 &sor1>;
> > >>>>>                          nvidia,head = <0>;
> > >>>>> -
> > >>>>> -                       interconnects = <&mc TEGRA210_MC_DISPLAY0A &emc>,
> > >>>>> -                                       <&mc TEGRA210_MC_DISPLAY0B &emc>,
> > >>>>> -                                       <&mc TEGRA210_MC_DISPLAY0C &emc>,
> > >>>>> -                                       <&mc TEGRA210_MC_DISPLAYHC &emc>,
> > >>>>> -                                       <&mc TEGRA210_MC_DISPLAYD &emc>,
> > >>>>> -                                       <&mc TEGRA210_MC_DISPLAYT &emc>;
> > >>>>> -                       interconnect-names = "wina",
> > >>>>> -                                            "winb",
> > >>>>> -                                            "winc",
> > >>>>> -                                            "cursor",
> > >>>>> -                                            "wind",
> > >>>>> -                                            "wint";
> > >>>>>                  };
> > >>>>>
> > >>>>>                  dc@54240000 {
> > >>>>> @@ -230,15 +217,6 @@ dc@54240000 {
> > >>>>>
> > >>>>>                          nvidia,outputs = <&dsia &dsib &sor0 &sor1>;
> > >>>>>                          nvidia,head = <1>;
> > >>>>> -
> > >>>>> -                       interconnects = <&mc TEGRA210_MC_DISPLAY0AB &emc>,
> > >>>>> -                                       <&mc TEGRA210_MC_DISPLAY0BB &emc>,
> > >>>>> -                                       <&mc TEGRA210_MC_DISPLAY0CB &emc>,
> > >>>>> -                                       <&mc TEGRA210_MC_DISPLAYHCB &emc>;
> > >>>>> -                       interconnect-names = "wina",
> > >>>>> -                                            "winb",
> > >>>>> -                                            "winc",
> > >>>>> -                                            "cursor";
> > >>>>>                  };
> > >>>>>
> > >>>>>                  dsia: dsi@54300000 {
> > >>>>> @@ -1052,7 +1030,6 @@ mc: memory-controller@70019000 {
> > >>>>>
> > >>>>>                  #iommu-cells = <1>;
> > >>>>>                  #reset-cells = <1>;
> > >>>>> -               #interconnect-cells = <1>;
> > >>>>>          };
> > >>>>>
> > >>>>>          emc: external-memory-controller@7001b000 {
> > >>>>> @@ -1066,7 +1043,6 @@ emc: external-memory-controller@7001b000 {
> > >>>>>                  nvidia,memory-controller = <&mc>;
> > >>>>>                  operating-points-v2 = <&emc_icc_dvfs_opp_table>;
> > >>>>>
> > >>>>> -               #interconnect-cells = <0>;
> > >>>>>                  #cooling-cells = <2>;
> > >>>>>          };
> > >>>>>
> > >>>>> --
> > >>>>> 2.43.0
> > >>>>>
> > >>>>
> > >>>> A little bit of documentation on this, should someone read the list to
> > >>>> see what happened. The original report of the failure is here [0] and
> > >>>> only occurred when the tegra210-emc driver fails to probe. After this
> > >>>> report, the related code change [1] to tegra210-emc which registers
> > >>>> the driver to icc was silently dropped from -next, but these dt
> > >>>> changes remained. So now these interconnect routes do cause tegra-drm
> > >>>> to universally fail on tegra210.
> > >>>>
> > >>>> Aaron
> > >>>>
> > >>>> [0] https://lore.kernel.org/all/56aed0ec-b104-4612-8901-3f6f95e0afab@nvidia.com/
> > >>>> [1] https://lore.kernel.org/all/20251027-t210-actmon-p2-v6-1-1c4bd227d676@gmail.com/
> > >>>
> > >>> There may be another option here. I'm beginning to think there will
> > >>> not be any way to set the icc routes for the dc's while the emc driver
> > >>> can fail to probe. The next best thing looks to be just dropping the
> > >>> interconnect nodes from the dc nodes and leaving the rest of the
> > >>> original commit in place. Then reland the tegra210-emc driver change.
> > >>> This should put the no-emc case back to where it was, while allowing
> > >>> actmon to do its scaling when emc is available. And I will move to the
> > >>> dc icc routes to downstream dt's, where I tightly control that emc is
> > >>> available.
> > >>>
> > >>> Does this sound reasonable? If so, I will go stage the changes and
> > >>> verify that it works as intended.
> > >>
> > >> Let's go with the revert for now, since that clearly documents where
> > >> things go wrong and it can be easily reapplied once the root cause has
> > >> been resolved.
> > >>
> > >> It's a bit unfortunate that we don't have a way of making these
> > >> interconnect properties optional. If EMC fails to probe for whatever
> > >> reason, I think the assumption should be that it doesn't do any dynamic
> > >> scaling of the EMC frequency and hence the entire ICC stuff isn't needed
> > >> and should just be no-ops.
> > >>
> > >> On the other hand, other than the patches getting reverted, there's
> > >> really no good reason for the EMC driver to fail to provide them, hence
> > >> I think once that's been restored we can apply this again and then that
> > >> should be the end of it.
> > >
> > > Except that the tegra210-emc driver fails to probe at all if the
> > > bootloader does not copy reserved-memory table node? Which per Jon,
> > > the Nvidia regression bench does not do. And neither will a normal L4T
> > > install using a mainline kernel and dt via extlinux or u-boot. I have
> > > to put the mainline kernel on DTB and use a kernel in an android boot
> > > image, which causes nvtboot-cpu to set the dt table reserved memory
> > > node directly. Which is perfectly fine for my android use case, but
> > > not so much for anyone just trying to boot a Linux distro.
> >
> > I am lost. I was not able to follow the above. Our current testing
> > simply boots the upstream kernel + upstream DTB.
>
> With this revert, I have tegra drm back on 6.19-rc4 kernel.
>
> But I also have this error that did not appear on 6.18:
> "tegra210-emc 7001b000.external-memory-controller: failed to get
> nominal EMC table: -19"

I'm not sure what between 6.18 and -next would change this. I would
expect your setup to see this on older kernel versions too. Does the
emc driver fully probe and does scaling work for you on 6.18?

> My boot flow is the latest L4T 32.7.6, upstream U-Boot 2025.01 and EFI boot.
> U-Boot mentions:
> Found DTB: nvidia/tegra210-p2371-2180.dtb
> copying carveout for /host1x@50000000/dc@54200000...
> copying carveout for /host1x@50000000/dc@54240000...
> copying carveout for /external-memory-controller@7001b000..
>
> That said, comparing in-tree dtb and runtime only shows few diffs.
> (are more changes expected ?)
>
> dtdiff /boot/dtbs/nvidia/tegra210-p2371-2180.dtb /proc/device-tree
> --- /dev/fd/63    2026-01-05 21:20:39.956415634 +0100
> +++ /dev/fd/62    2026-01-05 21:20:39.956415634 +0100
> @@ -2207,6 +2207,12 @@
>      };
>
>      chosen {
> +        bootargs = "BOOT_IMAGE=(hd0,msdos2)/vmlinuz-arm64
> root=UUID=9bdc914f-f5c9-42cb-a4e9-9f3387f8d480 ro
> rootflags=subvol=root console=ttyS0,115200 selinux=0 fbcon=rotate:3";
> +        linux,uefi-mmap-desc-size = <0x28>;
> +        linux,uefi-mmap-desc-ver = <0x01>;
> +        linux,uefi-mmap-size = <0x528>;
> +        linux,uefi-mmap-start = <0x00 0xfb568068>;
> +        linux,uefi-system-table = <0x00 0xfed2bf80>;
>          stdout-path = "serial0:115200n8";
>
>          framebuffer {

For emc scaling to work with the current tegra210-emc driver, a
memory-region property needs added by the bootloader to
external-memory-controller@7001b000, pointing to emc-table regions
that it added to the reserved-memory node.

Aaron

Re: [PATCH] Revert "arm64: tegra: Add interconnect properties for Tegra210"

[Nicolas Chauvet]

Le mer. 7 janv. 2026 à 20:50, Aaron Kling <webgeek1234@gmail.com> a écrit :
>
> On Mon, Jan 5, 2026 at 2:27 PM Nicolas Chauvet <kwizart@gmail.com> wrote:
> >
> > Le ven. 19 déc. 2025 à 11:59, Jon Hunter <jonathanh@nvidia.com> a écrit :
> > >
> > >
> > >
> > > On 18/12/2025 19:07, Aaron Kling wrote:
> > > > On Thu, Dec 18, 2025 at 6:00 AM Thierry Reding <thierry.reding@gmail.com> wrote:
> > > >>
> > > >> On Wed, Dec 17, 2025 at 02:42:58PM -0600, Aaron Kling wrote:
> > > >>> On Wed, Dec 17, 2025 at 12:20 PM Aaron Kling <webgeek1234@gmail.com> wrote:
> > > >>>>
> > > >>>> On Wed, Dec 17, 2025 at 4:48 AM Jon Hunter <jonathanh@nvidia.com> wrote:
> > > >>>>>
> > > >>>>> Commit 59a42707a094 ("arm64: tegra: Add interconnect properties for
> > > >>>>> Tegra210") populated interconnect properties for Tegra210 and this is
> > > >>>>> preventing the Tegra DRM driver from probing successfully. The following
> > > >>>>> error is observed on boot ...
> > > >>>>>
> > > >>>>>   drm drm: failed to initialize 54240000.dc: -517
> > > >>>>>
> > > >>>>> For now revert this change, until a fix is available.
> > > >>>>>
> > > >>>>> Fixes: 59a42707a094 ("arm64: tegra: Add interconnect properties for Tegra210")
> > > >>>>> Signed-off-by: Jon Hunter <jonathanh@nvidia.com>
> > > >>>>> ---
> > > >>>>>   arch/arm64/boot/dts/nvidia/tegra210.dtsi | 24 ------------------------
> > > >>>>>   1 file changed, 24 deletions(-)
> > > >>>>>
> > > >>>>> diff --git a/arch/arm64/boot/dts/nvidia/tegra210.dtsi b/arch/arm64/boot/dts/nvidia/tegra210.dtsi
> > > >>>>> index 709da31d5785..137aa8375257 100644
> > > >>>>> --- a/arch/arm64/boot/dts/nvidia/tegra210.dtsi
> > > >>>>> +++ b/arch/arm64/boot/dts/nvidia/tegra210.dtsi
> > > >>>>> @@ -202,19 +202,6 @@ dc@54200000 {
> > > >>>>>
> > > >>>>>                          nvidia,outputs = <&dsia &dsib &sor0 &sor1>;
> > > >>>>>                          nvidia,head = <0>;
> > > >>>>> -
> > > >>>>> -                       interconnects = <&mc TEGRA210_MC_DISPLAY0A &emc>,
> > > >>>>> -                                       <&mc TEGRA210_MC_DISPLAY0B &emc>,
> > > >>>>> -                                       <&mc TEGRA210_MC_DISPLAY0C &emc>,
> > > >>>>> -                                       <&mc TEGRA210_MC_DISPLAYHC &emc>,
> > > >>>>> -                                       <&mc TEGRA210_MC_DISPLAYD &emc>,
> > > >>>>> -                                       <&mc TEGRA210_MC_DISPLAYT &emc>;
> > > >>>>> -                       interconnect-names = "wina",
> > > >>>>> -                                            "winb",
> > > >>>>> -                                            "winc",
> > > >>>>> -                                            "cursor",
> > > >>>>> -                                            "wind",
> > > >>>>> -                                            "wint";
> > > >>>>>                  };
> > > >>>>>
> > > >>>>>                  dc@54240000 {
> > > >>>>> @@ -230,15 +217,6 @@ dc@54240000 {
> > > >>>>>
> > > >>>>>                          nvidia,outputs = <&dsia &dsib &sor0 &sor1>;
> > > >>>>>                          nvidia,head = <1>;
> > > >>>>> -
> > > >>>>> -                       interconnects = <&mc TEGRA210_MC_DISPLAY0AB &emc>,
> > > >>>>> -                                       <&mc TEGRA210_MC_DISPLAY0BB &emc>,
> > > >>>>> -                                       <&mc TEGRA210_MC_DISPLAY0CB &emc>,
> > > >>>>> -                                       <&mc TEGRA210_MC_DISPLAYHCB &emc>;
> > > >>>>> -                       interconnect-names = "wina",
> > > >>>>> -                                            "winb",
> > > >>>>> -                                            "winc",
> > > >>>>> -                                            "cursor";
> > > >>>>>                  };
> > > >>>>>
> > > >>>>>                  dsia: dsi@54300000 {
> > > >>>>> @@ -1052,7 +1030,6 @@ mc: memory-controller@70019000 {
> > > >>>>>
> > > >>>>>                  #iommu-cells = <1>;
> > > >>>>>                  #reset-cells = <1>;
> > > >>>>> -               #interconnect-cells = <1>;
> > > >>>>>          };
> > > >>>>>
> > > >>>>>          emc: external-memory-controller@7001b000 {
> > > >>>>> @@ -1066,7 +1043,6 @@ emc: external-memory-controller@7001b000 {
> > > >>>>>                  nvidia,memory-controller = <&mc>;
> > > >>>>>                  operating-points-v2 = <&emc_icc_dvfs_opp_table>;
> > > >>>>>
> > > >>>>> -               #interconnect-cells = <0>;
> > > >>>>>                  #cooling-cells = <2>;
> > > >>>>>          };
> > > >>>>>
> > > >>>>> --
> > > >>>>> 2.43.0
> > > >>>>>
> > > >>>>
> > > >>>> A little bit of documentation on this, should someone read the list to
> > > >>>> see what happened. The original report of the failure is here [0] and
> > > >>>> only occurred when the tegra210-emc driver fails to probe. After this
> > > >>>> report, the related code change [1] to tegra210-emc which registers
> > > >>>> the driver to icc was silently dropped from -next, but these dt
> > > >>>> changes remained. So now these interconnect routes do cause tegra-drm
> > > >>>> to universally fail on tegra210.
> > > >>>>
> > > >>>> Aaron
> > > >>>>
> > > >>>> [0] https://lore.kernel.org/all/56aed0ec-b104-4612-8901-3f6f95e0afab@nvidia.com/
> > > >>>> [1] https://lore.kernel.org/all/20251027-t210-actmon-p2-v6-1-1c4bd227d676@gmail.com/
> > > >>>
> > > >>> There may be another option here. I'm beginning to think there will
> > > >>> not be any way to set the icc routes for the dc's while the emc driver
> > > >>> can fail to probe. The next best thing looks to be just dropping the
> > > >>> interconnect nodes from the dc nodes and leaving the rest of the
> > > >>> original commit in place. Then reland the tegra210-emc driver change.
> > > >>> This should put the no-emc case back to where it was, while allowing
> > > >>> actmon to do its scaling when emc is available. And I will move to the
> > > >>> dc icc routes to downstream dt's, where I tightly control that emc is
> > > >>> available.
> > > >>>
> > > >>> Does this sound reasonable? If so, I will go stage the changes and
> > > >>> verify that it works as intended.
> > > >>
> > > >> Let's go with the revert for now, since that clearly documents where
> > > >> things go wrong and it can be easily reapplied once the root cause has
> > > >> been resolved.
> > > >>
> > > >> It's a bit unfortunate that we don't have a way of making these
> > > >> interconnect properties optional. If EMC fails to probe for whatever
> > > >> reason, I think the assumption should be that it doesn't do any dynamic
> > > >> scaling of the EMC frequency and hence the entire ICC stuff isn't needed
> > > >> and should just be no-ops.
> > > >>
> > > >> On the other hand, other than the patches getting reverted, there's
> > > >> really no good reason for the EMC driver to fail to provide them, hence
> > > >> I think once that's been restored we can apply this again and then that
> > > >> should be the end of it.
> > > >
> > > > Except that the tegra210-emc driver fails to probe at all if the
> > > > bootloader does not copy reserved-memory table node? Which per Jon,
> > > > the Nvidia regression bench does not do. And neither will a normal L4T
> > > > install using a mainline kernel and dt via extlinux or u-boot. I have
> > > > to put the mainline kernel on DTB and use a kernel in an android boot
> > > > image, which causes nvtboot-cpu to set the dt table reserved memory
> > > > node directly. Which is perfectly fine for my android use case, but
> > > > not so much for anyone just trying to boot a Linux distro.
> > >
> > > I am lost. I was not able to follow the above. Our current testing
> > > simply boots the upstream kernel + upstream DTB.
> >
> > With this revert, I have tegra drm back on 6.19-rc4 kernel.
> >
> > But I also have this error that did not appear on 6.18:
> > "tegra210-emc 7001b000.external-memory-controller: failed to get
> > nominal EMC table: -19"
>
> I'm not sure what between 6.18 and -next would change this. I would
> expect your setup to see this on older kernel versions too. Does the
> emc driver fully probe and does scaling work for you on 6.18?
>
> > My boot flow is the latest L4T 32.7.6, upstream U-Boot 2025.01 and EFI boot.
> > U-Boot mentions:
> > Found DTB: nvidia/tegra210-p2371-2180.dtb
> > copying carveout for /host1x@50000000/dc@54200000...
> > copying carveout for /host1x@50000000/dc@54240000...
> > copying carveout for /external-memory-controller@7001b000..
> >
> > That said, comparing in-tree dtb and runtime only shows few diffs.
> > (are more changes expected ?)
> >
> > dtdiff /boot/dtbs/nvidia/tegra210-p2371-2180.dtb /proc/device-tree
> > --- /dev/fd/63    2026-01-05 21:20:39.956415634 +0100
> > +++ /dev/fd/62    2026-01-05 21:20:39.956415634 +0100
> > @@ -2207,6 +2207,12 @@
> >      };
> >
> >      chosen {
> > +        bootargs = "BOOT_IMAGE=(hd0,msdos2)/vmlinuz-arm64
> > root=UUID=9bdc914f-f5c9-42cb-a4e9-9f3387f8d480 ro
> > rootflags=subvol=root console=ttyS0,115200 selinux=0 fbcon=rotate:3";
> > +        linux,uefi-mmap-desc-size = <0x28>;
> > +        linux,uefi-mmap-desc-ver = <0x01>;
> > +        linux,uefi-mmap-size = <0x528>;
> > +        linux,uefi-mmap-start = <0x00 0xfb568068>;
> > +        linux,uefi-system-table = <0x00 0xfed2bf80>;
> >          stdout-path = "serial0:115200n8";
> >
> >          framebuffer {
>
> For emc scaling to work with the current tegra210-emc driver, a
> memory-region property needs added by the bootloader to
> external-memory-controller@7001b000, pointing to emc-table regions
> that it added to the reserved-memory node.

Okay, I got what was the issue on my side, my grub loader entry had a
"devicetree /dtbs/nvidia/tegra210-p2371-2180.dtb" line that prevented
for my self compiled kernel to have the trained emc-tables and other
options from bootloader.

Also I had to point the /boot/dtb symlink to /boot/dtbs where my
kernel installed dtbs are located. Now the fedora grub loads the more
recent dtb everywhere (which is a separate issue).

Now I had the training table rights:
See also:
dtdiff /boot/dtbs/nvidia/tegra210-p2371-2180.dtb /proc/device-tree
....
@@ -2355,6 +2364,8 @@
                clocks = <0x03 0x39>;
                compatible = "nvidia,tegra210-emc";
                interrupts = <0x00 0x4e 0x04>;
+               memory-region = <0x17b 0x17c>;
+               memory-region-names = "nominal", "derated";
                nvidia,memory-controller = <0x0d>;
                operating-points-v2 = <0x35>;
                phandle = <0x16>;
@@ -3270,7 +3281,7 @@

        memory@80000000 {
                device_type = "memory";
-               reg = <0x00 0x80000000 0x01 0x00>;
+               reg = <0x00 0x80000000 0x00 0x7ee00000 0x01 0x00 0x00
0x7f200000>;
        };

        mipi@700e3000 {
@@ -5664,6 +5675,18 @@
                #size-cells = <0x02>;
                ranges;

+               emc-table@83400000 {
+                       compatible = "nvidia,tegra210-emc-table";
+                       phandle = <0x17b>;
+                       reg = <0x00 0x83400000 0x00 0x10000>;
+               };
+
+               emc-table@83410000 {
+                       compatible = "nvidia,tegra210-emc-table";
+                       phandle = <0x17c>;
+                       reg = <0x00 0x83410000 0x00 0x10000>;
+               };
+
                framebuffer@92cb5000 {
                        iommu-addresses = <0xec 0x00 0x92cb5000 0x00 0x800000>;
                        phandle = <0x17>;

Re: [PATCH] Revert "arm64: tegra: Add interconnect properties for Tegra210"

[Thierry Reding]

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

On Wed, Dec 17, 2025 at 10:47:44AM +0000, Jon Hunter wrote:
> Commit 59a42707a094 ("arm64: tegra: Add interconnect properties for
> Tegra210") populated interconnect properties for Tegra210 and this is
> preventing the Tegra DRM driver from probing successfully. The following
> error is observed on boot ...
> 
>  drm drm: failed to initialize 54240000.dc: -517
> 
> For now revert this change, until a fix is available.
> 
> Fixes: 59a42707a094 ("arm64: tegra: Add interconnect properties for Tegra210")
> Signed-off-by: Jon Hunter <jonathanh@nvidia.com>
> ---
>  arch/arm64/boot/dts/nvidia/tegra210.dtsi | 24 ------------------------
>  1 file changed, 24 deletions(-)

Hi Arnd,

this is the only patch that I think we need in v6.19 for now, so do you
want me to send a PR or would you rather pick this up directly?

Here's a link to the patchwork for this, for convenience:

	https://patchwork.ozlabs.org/project/linux-tegra/patch/20251217104744.184153-1-jonathanh@nvidia.com/

Acked-by: Thierry Reding <treding@nvidia.com>

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

Re: [PATCH] Revert "arm64: tegra: Add interconnect properties for Tegra210"

[Jon Hunter]

Hi Arnd,

On 18/12/2025 11:56, Thierry Reding wrote:
> On Wed, Dec 17, 2025 at 10:47:44AM +0000, Jon Hunter wrote:
>> Commit 59a42707a094 ("arm64: tegra: Add interconnect properties for
>> Tegra210") populated interconnect properties for Tegra210 and this is
>> preventing the Tegra DRM driver from probing successfully. The following
>> error is observed on boot ...
>>
>>   drm drm: failed to initialize 54240000.dc: -517
>>
>> For now revert this change, until a fix is available.
>>
>> Fixes: 59a42707a094 ("arm64: tegra: Add interconnect properties for Tegra210")
>> Signed-off-by: Jon Hunter <jonathanh@nvidia.com>
>> ---
>>   arch/arm64/boot/dts/nvidia/tegra210.dtsi | 24 ------------------------
>>   1 file changed, 24 deletions(-)
> 
> Hi Arnd,
> 
> this is the only patch that I think we need in v6.19 for now, so do you
> want me to send a PR or would you rather pick this up directly?
> 
> Here's a link to the patchwork for this, for convenience:
> 
> 	https://patchwork.ozlabs.org/project/linux-tegra/patch/20251217104744.184153-1-jonathanh@nvidia.com/
> 
> Acked-by: Thierry Reding <treding@nvidia.com>


Please can you let us know if you can pick this up as a fix for v6.19? 
This is still the only fix we have outstanding that needs to be merged.

Thanks!
Jon

-- 
nvpublic

Re: [PATCH] Revert "arm64: tegra: Add interconnect properties for Tegra210"

[Arnd Bergmann]

On Thu, Jan 15, 2026, at 10:50, Jon Hunter wrote:
> Hi Arnd,
>
> On 18/12/2025 11:56, Thierry Reding wrote:
>> On Wed, Dec 17, 2025 at 10:47:44AM +0000, Jon Hunter wrote:
>>> Commit 59a42707a094 ("arm64: tegra: Add interconnect properties for
>>> Tegra210") populated interconnect properties for Tegra210 and this is
>>> preventing the Tegra DRM driver from probing successfully. The following
>>> error is observed on boot ...
>>>
>>>   drm drm: failed to initialize 54240000.dc: -517
>>>
>>> For now revert this change, until a fix is available.
>>>
>>> Fixes: 59a42707a094 ("arm64: tegra: Add interconnect properties for Tegra210")
>>> Signed-off-by: Jon Hunter <jonathanh@nvidia.com>
>>> ---
>>>   arch/arm64/boot/dts/nvidia/tegra210.dtsi | 24 ------------------------
>>>   1 file changed, 24 deletions(-)
>> 
>> Hi Arnd,
>> 
>> this is the only patch that I think we need in v6.19 for now, so do you
>> want me to send a PR or would you rather pick this up directly?
>> 
>> Here's a link to the patchwork for this, for convenience:
>> 
>> 	https://patchwork.ozlabs.org/project/linux-tegra/patch/20251217104744.184153-1-jonathanh@nvidia.com/
>> 
>> Acked-by: Thierry Reding <treding@nvidia.com>
>
>
> Please can you let us know if you can pick this up as a fix for v6.19? 
> This is still the only fix we have outstanding that needs to be merged.

Sorry I missed the earlier message. I've applied it now, but in
the future please forward patches to soc@lists.linux.dev if you
want make sure they don't get lost. A pull request or a separate
patch works just as well, but sending it to the list means it
shows up in patchwork[1].

     Arnd

[1] https://patchwork.kernel.org/project/linux-soc/list/

Re: [PATCH] Revert "arm64: tegra: Add interconnect properties for Tegra210"

[Thierry Reding]

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

On Thu, Jan 15, 2026 at 05:41:51PM +0100, Arnd Bergmann wrote:
> On Thu, Jan 15, 2026, at 10:50, Jon Hunter wrote:
> > Hi Arnd,
> >
> > On 18/12/2025 11:56, Thierry Reding wrote:
> >> On Wed, Dec 17, 2025 at 10:47:44AM +0000, Jon Hunter wrote:
> >>> Commit 59a42707a094 ("arm64: tegra: Add interconnect properties for
> >>> Tegra210") populated interconnect properties for Tegra210 and this is
> >>> preventing the Tegra DRM driver from probing successfully. The following
> >>> error is observed on boot ...
> >>>
> >>>   drm drm: failed to initialize 54240000.dc: -517
> >>>
> >>> For now revert this change, until a fix is available.
> >>>
> >>> Fixes: 59a42707a094 ("arm64: tegra: Add interconnect properties for Tegra210")
> >>> Signed-off-by: Jon Hunter <jonathanh@nvidia.com>
> >>> ---
> >>>   arch/arm64/boot/dts/nvidia/tegra210.dtsi | 24 ------------------------
> >>>   1 file changed, 24 deletions(-)
> >> 
> >> Hi Arnd,
> >> 
> >> this is the only patch that I think we need in v6.19 for now, so do you
> >> want me to send a PR or would you rather pick this up directly?
> >> 
> >> Here's a link to the patchwork for this, for convenience:
> >> 
> >> 	https://patchwork.ozlabs.org/project/linux-tegra/patch/20251217104744.184153-1-jonathanh@nvidia.com/
> >> 
> >> Acked-by: Thierry Reding <treding@nvidia.com>
> >
> >
> > Please can you let us know if you can pick this up as a fix for v6.19? 
> > This is still the only fix we have outstanding that needs to be merged.
> 
> Sorry I missed the earlier message. I've applied it now, but in
> the future please forward patches to soc@lists.linux.dev if you
> want make sure they don't get lost. A pull request or a separate
> patch works just as well, but sending it to the list means it
> shows up in patchwork[1].
> 
>      Arnd
> 
> [1] https://patchwork.kernel.org/project/linux-soc/list/

Thanks Arnd. I'll keep that list in mind for the future.

Thierry

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