Jetpack 5.1 - enabling sdhci@3440000 DTB causes kernel soft lockup (on devkit)

[eh-steve]

Hello,

We’re developing a custom carrier board with an SD card reader for sdhci@3440000.

Card detect pin is wired to GPIO S4 (pin 211), and vdd enable pin is using GPIO CC3 (pin 130) at 3v3.

Our DTS patch (against R35.2.1) looks like:

===================================================================
diff --git a/sources/hardware/nvidia/platform/t19x/jakku/kernel-dts/common/tegra194-fixed-regulator-p3668.dtsi b/hardware/nvidia/platform/t19x/jakku/kernel-dts/common/tegra194-fixed-regulator-p3668.dtsi
--- a/hardware/nvidia/platform/t19x/jakku/kernel-dts/common/tegra194-fixed-regulator-p3668.dtsi	(revision 7916e3ef869a31c84aed52532ed7ba8f17a94235)
+++ b/hardware/nvidia/platform/t19x/jakku/kernel-dts/common/tegra194-fixed-regulator-p3668.dtsi	(date 1679366370618)
@@ -35,6 +35,16 @@
 			enable-active-high;
 		};

+		vdd_sdmmc3_sw: regulator@103 {
+			compatible = "regulator-fixed";
+			reg = <103>;
+			regulator-name = "vdd-sdmmc3-sw";
+			regulator-min-microvolt = <3300000>;
+			regulator-max-microvolt = <3300000>;
+			gpio = <&tegra_main_gpio TEGRA194_AON_GPIO(CC, 3) 0>;
+			enable-active-high;
+		};
+
 		p3668_vdd_1v8_sd: regulator@104 {
 			compatible = "regulator-fixed";
 			reg = <104>;
===================================================================
diff --git a/hardware/nvidia/platform/t19x/jakku/kernel-dts/common/tegra194-p3668-common.dtsi b/hardware/nvidia/platform/t19x/jakku/kernel-dts/common/tegra194-p3668-common.dtsi
--- a/hardware/nvidia/platform/t19x/jakku/kernel-dts/common/tegra194-p3668-common.dtsi	(revision 7916e3ef869a31c84aed52532ed7ba8f17a94235)
+++ b/hardware/nvidia/platform/t19x/jakku/kernel-dts/common/tegra194-p3668-common.dtsi	(date 1679366650082)
@@ -328,6 +328,15 @@
 		status = "okay";
 	};

+        sdmmc3: sdhci@3440000 {
+                mmc-ocr-mask = <0x0>;
+                cd-inverted;
+                cd-gpios = <&tegra_main_gpio TEGRA194_MAIN_GPIO(S, 4) 0>;
+                nvidia,cd-wakeup-capable;
+                vmmc-supply = <&vdd_sdmmc3_sw>;
+                status = "okay";
+        };
+
 	tegra-hsp@b950000 {
 		status = "okay";
 	};

Attached are the complete boot logs with this DTB patch applied (devkit, nothing else connected):

soft_lockup_boot.log (102.2 KB)

If the regulator@103 DT node is removed, the lockups don’t occur, and the enable pin can be controlled by exporting the GPIO via sysfs (verified with a scope), but the sdhci driver doesn’t create a device when a card is inserted and the enable pin is turned on.

Running on kernel 4.9 (R32.7.3) and applying an equivalent patch (line numbers are different in this version), the lockups do not occur, and the sdhci driver correctly adds a /dev/mmc1 device.

Has R35.2.1 been tested/verified with sdhci@3440000?

[WayneWWW]

The problem looks not related to sdhci. Whole error log does not have error stack dump from sdhci driver…

The problem is TEGRA194_AON_GPIO is not part of tegra_main_gpio

[eh-steve]

Ah, so it’s the bringup of the aon GPIO device happening after the sdhci?

[WayneWWW]

Yes, the GPIO you wrote in regulator is wrong. Any kind of driver uses this regulator might trigger this error. Not directly from sdhci.

[eh-steve]

Was the AON device previously brought up earlier in the boot (or by bootloader?) in R32.7.3?

[WayneWWW]

My point is you should write tegra_aon_gpio but not tegra_main_gpio if this is GPIO from AON group.

[eh-steve]

🤦🏻‍♂️

[eh-steve]

Changing the GPIO device base has stopped the soft lockups, thanks.

The behaviour change between R32.7.3 and R35.2.1 seems to be that in the older version, using the wrong GPIO device for a given GPIO pin was allowed (and would just access the number for that GPIO, which would be a random unrelated pin, not even exposed on the SODIMM, in our case (gpio base + 19)), but in the new version, the gpio-ranges have been tightened up and presumably accessing pin out of range causes a lockup?