linux-kernel - Re: [PATCH v5 2/3] arm64: tegra: Add interconnect properties to Tegra210 device-tree

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CALHNRZ8Hc+kqWVCjTZvtJ+hBrsgpjO9EySOQFfLaLHvt9P_reg@mail.gmail.com>
Date: Fri, 21 Nov 2025 13:32:02 -0600
From: Aaron Kling <webgeek1234@...il.com>
To: Jon Hunter <jonathanh@...dia.com>
Cc: Rob Herring <robh@...nel.org>, Krzysztof Kozlowski <krzk+dt@...nel.org>, 
	Conor Dooley <conor+dt@...nel.org>, Thierry Reding <thierry.reding@...il.com>, 
	devicetree@...r.kernel.org, linux-tegra@...r.kernel.org, 
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH v5 2/3] arm64: tegra: Add interconnect properties to
 Tegra210 device-tree

On Fri, Nov 21, 2025 at 5:24 AM Jon Hunter <jonathanh@...dia.com> wrote:
>
>
> On 22/10/2025 04:13, Aaron Kling via B4 Relay wrote:
> > From: Aaron Kling <webgeek1234@...il.com>
> >
> > Add interconnect properties to the Memory Controller, External Memory
> > Controller and the Display Controller nodes in order to describe hardware
> > interconnection.
> >
> > Signed-off-by: Aaron Kling <webgeek1234@...il.com>
> > ---
> >   arch/arm64/boot/dts/nvidia/tegra210.dtsi | 24 ++++++++++++++++++++++++
> >   1 file changed, 24 insertions(+)
> >
> > diff --git a/arch/arm64/boot/dts/nvidia/tegra210.dtsi b/arch/arm64/boot/dts/nvidia/tegra210.dtsi
> > index 6da10db893add44a98fde1666c382511212fd43c..2fcc7a28690f7100d49e8b93c4fb77de7947b002 100644
> > --- a/arch/arm64/boot/dts/nvidia/tegra210.dtsi
> > +++ b/arch/arm64/boot/dts/nvidia/tegra210.dtsi
> > @@ -202,6 +202,19 @@ dc@...00000 {
> >
> >                       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@...40000 {
> > @@ -217,6 +230,15 @@ dc@...40000 {
> >
> >                       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@...00000 {
> > @@ -990,6 +1012,7 @@ mc: memory-controller@...19000 {
> >
> >               #iommu-cells = <1>;
> >               #reset-cells = <1>;
> > +             #interconnect-cells = <1>;
> >       };
> >
> >       emc: external-memory-controller@...1b000 {
> > @@ -1001,6 +1024,7 @@ emc: external-memory-controller@...1b000 {
> >               clock-names = "emc";
> >               interrupts = <GIC_SPI 78 IRQ_TYPE_LEVEL_HIGH>;
> >               nvidia,memory-controller = <&mc>;
> > +             #interconnect-cells = <0>;
> >               #cooling-cells = <2>;
> >       };
>
>
> I am seeing another failure on -next for Tegra210 and bisect is point to
> this commit ...
>
> # first bad commit: [3cad4369399a31277e9e20de723c665b30cba574] arm64:
> tegra: Add interconnect properties for Tegra210
>
> The tegra-tests [0] devices test is failing and after this commit the
> DRM device is no longer bound to the driver.

Upon research, this one appears to be a bit more complicated. The dc
code in tegra-drm sets up an icc connection per plane to emc, I
presume in order to prevent underruns. If the icc path exists in the
dt, but the emc driver has not added itself to icc, then dc will
infinitely defer [0]. And per earlier statements on this list, the
regression test setup for Tegra210 does not pass emc training data
from the bootloader to the kernel, meaning the emc driver fails to
probe.

I am not sure how to handle this. As far as I know, the previous archs
that the dc icc code was originally written for wouldn't ever have the
emc driver fail, because the untrained tables are in the kernel dt,
meaning that the driver could at least load that. On Tegra210 since
the dt tables were rejected, there's nothing for the driver to fall
back on, so it is possible to have a hard failure.

Does anyone have ideas on how to handle this? To allow dc to report
icc bw on Tegra210, but not fail probe if the emc is missing? Making
the icc path lookup non-fatal isn't really an option.

Aaron

[0] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/gpu/drm/tegra/plane.c?h=v6.18-rc6#n778