TX2 NX and on-carrier mmc-socket

[juho.roine]

I’m adapting TX2 NX (Lanai) on a custom carrier-board with Jetpack version 32.5.1.

Problem: I cannot get the card mounted when booting with the card in place (=not hot-plugging it in when system is running)
When hot-plugging, it gets detected and mounted.

Question: where (which file and entry) should I add the reference for the mmc-card’s control gpio, in Lanai’s device-tree sources?

The carrier-board mmc-socket (sdhci@3440000) is verified to be working:

• It fully works with minor device-tree modifications on Xavier NX
• I can get the card detected and mounted when hot-plugging it also when using Lanai

I have added the corresponding cd-gpios entry to the device-tree and updated the pinmux with the correct pin functions.
I got it fully working with Xavier NX by adding gpio entry to regulator@106 block.
The similar modification (simply adding correct gpio entry to spmic_sd3) did not do the trick on Lanai.

The pins are:
CD: gpio 11 (configured as GPIO EE.02 in pinmux)
Control: gpio 7 (configured as GPIO U.00 in pinmux)

[JerryChang]

hello juho.roine,

could you please compare the kernel logs between hot-plugging and mounted when booting.
you shall have the same kernel API being called for the fail use-case.
thanks

[juho.roine]

Hi,

Here’s the corresponding dmesg lines:

[ 0.485095] vddio-ddr: at 1125 mV
[ 0.496964] vddio-3v3: 3300 mV
[ 0.497618] vddio-sdmmc1: 1800 <–> 3300 mV at 3300 mV
…
[ 34.060569] mmc1: card never left busy state
[ 34.065310] mmc1: error -110 whilst initialising SD card
[ 40.204551] mmc1: card never left busy state
[ 40.208877] mmc1: error -110 whilst initialising SD card
[ 46.364574] mmc1: card never left busy state
[ 46.368874] mmc1: error -110 whilst initialising SD card
…
(Here unplugged the card off and on and it gets detected.)
…
[ 62.545050] vdd-3v3-cvb: disabling
[ 62.545065] vdd-3v3-cvb: disabling
[ 62.545076] vdd-1v8-cvb: disabling
[ 62.545089] vdd_sys_en: disabling
[ 62.545115] spmic-ldo1: disabling
[ 62.545324] vddio-sdmmc1: disabling
[ 62.545491] vdd-sys-bl: disabling
[ 66.703565] mmc1: Disabling vmmc regulator
[ 68.873551] mmc1: hw tuning done …
[ 68.873583] mmc1: new ultra high speed SDR104 SDXC card at address 5048
[ 68.873919] mmcblk1: mmc1:5048 SD128 116 GiB
[ 68.877894] mmcblk1: p1 p2 p3 p4 p5 p6 p7 p8 p9 p10 p11

And here’s the related device tree nodes:

    sdhci@3440000 {
            status = "okay";
            cd-gpios = <&tegra_aon_gpio TEGRA_AON_GPIO(EE, 2) GPIO_ACTIVE_HIGH>;
            nvidia,cd-wakeup-capable;
            mmc-ocr-mask = <0>;
            sd-uhs-sdr104;
            sd-uhs-sdr50;
            sd-uhs-sdr25;
            sd-uhs-sdr12;
            mmc-ddr-1_8v;
            mmc-hs200-1_8v;
            disable-wp;
            qvmmc-supply = <&spmic_ldo3>;
            vmmc-supply = <&spmic_sd3>;
            /delete-property/ non-removable;
    };

    gpio@c2f0000 {
            mmc_enable {
                    gpio-hog;
                    output-high;
                    gpios = <TEGRA_AON_GPIO(U, 0) GPIO_ACTIVE_HIGH>;
                    label = "mmc-enable";
                    status = "okay";
            };
    };

[JerryChang]

hello juho.roine,

these messages indicate that the card went in an indeterminate state, it does not respond to the very first command during initialization.

@juho.roine

[ 34.060569] mmc1: card never left busy state
[ 34.065310] mmc1: error -110 whilst initialising SD card

so,
please have below workarounds to power cycling the card when it becomes unresponsive,
for example,

diff --git a/drivers/mmc/core/sd.c b/drivers/mmc/core/sd.c

@@ -792,8 +792,10 @@ int mmc_sd_get_cid(struct mmc_host *host, u32 ocr, u32 *cid, u32 *rocr)
                ocr |= SD_OCR_XPC;

        err = mmc_send_app_op_cond(host, ocr, rocr);
-       if (err)
+       if (err) {
+               mmc_power_cycle(host, host->ocr_avail);
                return err;
+       }

        /*
         * In case CCS and S18A in the response is set, start Signal Voltage
@@ -1362,8 +1364,10 @@ int mmc_attach_sd(struct mmc_host *host)
        WARN_ON(!host->claimed);

        err = mmc_send_app_op_cond(host, 0, &ocr);
-       if (err)
+       if (err) {
+               mmc_power_cycle(host, host->ocr_avail);
                return err;
+       }

[juho.roine]

Ok, thanks for the patch will try it later today. Does this mean, the software does not power-cycle the device correctly normally or is this just a check to verify other configs? Shouldn’t the mmc voltage get controlled by gpio and that resetting the card?

Follow-up:
Can you provide an example, how to add control-gpio to sdhci@3440000? Currently the spmic_sd3 does not include gpios -endpoint, but I have added the corresponding gpio to gpio@c2f0000 and I am able to control the pin voltage by /sys/class/gpio interface. In Xavier NX’s default device tree, there is an obvious place to configure the pin, but such pre-made config does not exist for TX2 NX.

In other words,I mean, how to provide this info:

gpios = <TEGRA_AON_GPIO(U, 0) GPIO_ACTIVE_HIGH>;

to vmmc-supply -entity of sdhci@3440000 (lanai/kernel-dts/common/tegra186-p3636-0001-common.dtsi):

vmmc-supply = <&spmic_sd3>;

so that the mmc-driver gets to control the pin.

I have tried this, in lanai/kernel-dts/common/tegra186-p3636-0001-a00-spmic.dtsi:

spmic_sd3: sd3 {
     regulator-name = "vdd-3v3-sys";
     regulator-min-microvolt = <3300000>;
     regulator-max-microvolt = <3300000>;
     regulator-always-on; //Have tried with tese off too
     regulator-boot-on; //And this
     //Here correct?
     //gpios = <TEGRA_AON_GPIO(U, 0) GPIO_ACTIVE_HIGH>;
     maxim,active-fps-source = <MAX77620_FPS_SRC_DEF>;
};

[juho.roine]

Adding the suggested power cycle calls to the driver did not help.

[JerryChang]

hello juho.roine,

may I know what’s your failure rate when booting with the card in place.
please do check the hardware signaling to confirm the waveform works.
since your card fails to be detected, it’s the attach workaround to power cycle the card again.
thanks

[JerryChang]

hello juho.roine,

please check the mmc driver as below, it’s kernel API to get the regulators.
$L4T_Sources/r32.5.1/Linux_for_Tegra/source/public/kernel/kernel-4.9/drivers/mmc/core/core.c

int mmc_regulator_get_supply(struct mmc_host *mmc)
{
...
        mmc->supply.vmmc = devm_regulator_get_optional(dev, "vmmc");
        mmc->supply.vqmmc = devm_regulator_get_optional(dev, "vqmmc");

you would like to have mmc driver to control GPIO pin, right?
please use the kernel API, of_get_named_gpio(). to get the GPIO handler.
you should also see below for the APIs to control the pin.
i.e. $L4T_Sources/r32.5.1/Linux_for_Tegra/source/public/kernel/kernel-4.9/include/linux/gpio.h
thanks

[juho.roine]

Oh, I thought it already could control the gpio pin (or at least know what pin is wired).

For example for Xavier NX, in the file
platform/t19x/jakku/kernel-dts/common/tegra194-fixed-regulator-p3668.dtsi
exists the following segment for mmc-card voltage regulator:

p3668_vdd_sdmmc1_sw: regulator@106 {
compatible = “regulator-fixed”;
reg = <106>;
regulator-name = “vdd-sdmmc1-sw”;
regulator-min-microvolt = <3300000>;
regulator-max-microvolt = <3300000>;
gpio = <&tegra_main_gpio TEGRA194_MAIN_GPIO(G, 2) 0>;
enable-active-high;
};

If on custom carrier board, the card is powered by some other pin than gpio G.2, this is obvious place to change to the correct pin. And the card works with that change on Xavier NX.

Lanai’s corresponding entry is as follows:

spmic_sd3: sd3 {
regulator-name = “vdd-3v3-sys”;
regulator-min-microvolt = <3300000>;
regulator-max-microvolt = <3300000>;
regulator-always-on;
regulator-boot-on;
maxim,active-fps-source = <MAX77620_FPS_SRC_DEF>;
};

This does not have gpio entry predefined. Why? And where that should be added?

If the voltages are configured as follows (default):

sdhci@3440000 {
vqmmc-supply = <&spmic_ldo5>;
vmmc-supply = <&spmic_sd2>;
}

I get CRC errors instead of “Card never left busy state” errors.
Which regulator (3v3 or 1v8 to vmmc-supply) should be correct?

[juho.roine]

@JerryChang

may I know what’s your failure rate when booting with the card in place.

100% so far.

[JerryChang]

@juho.roine

is powered by some other pin than gpio G.2, this is obvious place to change to the correct pin

hello juho.roine,

you could just use the kernel API to toggle the GPIO pin from the kernel side directly.
thanks

[juho.roine]

Could you explain, what is the purpose of gpio entry on certain regulators, if it is not for controlling the voltage on pin?
For example, the following entry on platform/t19x/jakku/kernel-dts/common/tegra194-fixed-regulator-p3668.dtsi:

                p3668_vdd_sdmmc1_sw: regulator@106 {
                        compatible = "regulator-fixed";
                        reg = <106>;
                        regulator-name = "vdd-sdmmc1-sw";
                        regulator-min-microvolt = <3300000>;
                        regulator-max-microvolt = <3300000>;
                        gpio = <&tegra_main_gpio TEGRA194_MAIN_GPIO(G, 2) 0>;
                        enable-active-high;
                };

[JerryChang]

hello juho.roine,

may I know what’s your actual use-case?

[juho.roine]

@JerryChang

may I know what’s your actual use-case?

Use case related to the latter question is using mmc-socket on P3509 carrier board and Xavier NX.
The code snippet above is from the Xavier NX device tree source code, released by Nvidia.

Kernel documentation for fixed-regulator says:
Optional properties:
- gpio: gpio to use for enable control
So, the gpio is used for controlling the regulator’s voltage, right?

[JerryChang]

hello juho.roine,

it’s a General-Purpose Input/Output (GPIO) pin.

BTW,
it’s Xavier NX to use t19x series.
you should check below sources if you’re referring to device tree for TX2 NX platforms.
i.e. $L4T_Sources/r32.5.1/Linux_for_Tegra/source/public/hardware/nvidia/platform/t18x/lanai/kernel-dts/common/tegra186-p3636-0001-a00-power-tree.dtsi

[juho.roine]

Yes I know what GPIO means and that the mentioned snippet is for t19x, which is different from t18x.
This does not answer the question:
The purpose of the mentioned gpio entry can be understood two ways: Does the pin control the regulator on/off, or does the regulator control the pin state?

This is the situation:

• The custom carrier board, with Xavier NX module in place, and the gpio configured correctly(*
  → card works fine also when booting.
• The custom carrier board, with Xavier NX module in place, and the gpio configured incorrectly
  → card does not detect on boot but works when hot-plugged.
• The same custom carrier board, with Lanai module in place
  → card does not detect on boot but works when hot-plugged. (notice the similarity with the second scenario?)

(and yes, I also know the flashing commands and and device trees are different for Xavier and Lanai)

I’m trying to ask, do I need to provide a similar gpio entry to Lanai’s regulators. And if it’s not needed for Lanai, why it’s needed for Xavier NX then? (“They are different devices” is not answering the question)

*) by “gpio configured correctly”, I mean that the p3668_vdd_sdmmc1_sw has a gpio entry that points to the pin whose state enables/disables the voltage to external mmc-socket.

[WayneWWW]

Hi,

Could you share the board schematic and current full dts file here?
You can refer to this post.

TX2 NX - SD Card not found

Hi all, I’m working on our custom carrier board with TX2 NX SOM. When I test the SD card connection, the TX2 NX can not find it. (With Jetson Nano and Xavier NX, SD card works good.) nvidia@nvidia-tx2-nx:~$ dmesg | grep sd [ 0.000000] Kernel command line: console=ttyS0,115200 root=/dev/mmcblk0p1 rw rootwait rootfstype=ext4 console=ttyS0,115200n8 console=tty0 fbcon=map:0 net.ifnames=0 isolcpus=1-2 video=tegrafb no_console_suspend=1 earlycon=uart8250,mmio32,0x3100000 nvdumper_reserved=0x17…