How can I get the MMC timing spec higher than sd high-speed?

[Tomáš Juřena]

Hello,

I am having difficulties with the MMC bus and the external SDIO wifi module. We are using the wifi module jody-w263 from U-blox with the OSD32MP1, and the communication with the module works, but it is quite slow. The wifi module is capable of SDR 104 and DDR50 communication speeds, but I add the support to the DTS, the communication is broken and the device returns the -110 while initializing.

How can I add support for higher speeds?

I attach the working dts, dmesg, ios and caps, and relevant schematic.

Any suggestion will be appreciated.

Best regards,

Tomáš.

[Olivier GALLIEN]

Hi @Tom�? Ju?ena​ ,

Sorry for late reply.

Where do you stand regarding this question ?

Looking at provided material we noticed 1 things as first hints :

• you wifi module is powered @1.8V but we notice in dts "vmmc-supply = <&v3v3>;"

This assumption is confirmed by dmesg trace which complain about power issues :

[ 3.127353] mmci-pl18x 48004000.sdmmc: allocated mmc-pwrseq

[ 3.131985] mmci-pl18x 48004000.sdmmc: mmc0: PL180 manf 53 rev1 at 0x48004000 irq 30,0 (pio)

[ 3.140299] v1v8_ldo1: voltage operation not allowed

[ 3.144886] mmci-pl18x 48004000.sdmmc: Voltage switch failed

[ 3.160524] mmci-pl18x 48004000.sdmmc: Voltage switch failed

[ 3.164764] v1v8_ldo1: voltage operation not allowed

[ 3.169671] mmci-pl18x 48004000.sdmmc: Voltage switch failed

[ 3.203258] mmci-pl18x 58007000.sdmmc: mmc1: PL180 manf 53 rev2 at 0x58007000 irq 36,0 (pio)

[ 3.212309] vdd: voltage operation not allowed

[ 3.215352] mmci-pl18x 58007000.sdmmc: Voltage switch failed

[ 3.230984] mmci-pl18x 58007000.sdmmc: Voltage switch failed

[ 3.235253] vdd: voltage operation not allowed

[ 3.239630] mmci-pl18x 58007000.sdmmc: Voltage switch failed

[ 3.264593] mmc0: new high speed SDIO card at address 0001

Let us know

Olivier

[Tomáš Juřena]

Hi Oliver,

thanks for the reply.

We tried to set the 1.8 V regulator to the vmmc-supply before, but the module was not recognized. Is this crucial? We assumed that the vqmmc-supply is the regulator, that we need to configure to have the higher speeds.

[PatrickF]

Hi,

did you use a level translator for the 1.8V wifi signals or the OSD32MP1 IOs are at 1.8V ?

When you mention 'quite slow', could you please precise, because classical SDIO high-speed should already provide a raw bandwidth of 25MB/s (200Mbit/s).

DDR50 could provide raw bandwidth of 50MB/s (400 Mbits/s)

SDR50 and SDR104 are not usable (see ES438).

Mybe your PLL root clock settings are limiting the choice done by the Linux driver. See this FAQ: https://community.st.com/s/article/FAQ-STM32MP1-how-to-setup-the-SDMMC-CK-clock-frequency-in-Linux

Regards,

[Bernard PUEL]

We saw 2 issues in the DT:

EMMC:

vmmc-supply = <&v3v3>;

vqmmc-supply = <&vdd>;

mmc-ddr-3_3v;

vdd being at 1,8v, it is not consistant with the others property (at 3,3v).

We don't have the emmc schematics but if the emmc is at 3,3v, the IOs have to be also at 3,3v.

WLAN:

vmmc-supply = <&v3v3>;

vqmmc-supply = <&v1v8_ldo1>;

mmc-pwrseq = <&wifi_pwrseq>;

Current declaration will force the driver to switch between 3,3v and 1,8v. But the IOs are statically supplied at 1,8v. So the driver has nothing to do. the "vqmmc-supply" property shall be removed from the DT.

[Tomáš Juřena]

Hello Bernard,

we have tried to set the regulators and eMMC driver properties correctly (mmc-ddr-1_8v and vqmmc-supply = <&vdd>), but the device did not boot. Because we thought that the vqmmc-supply is important, we ended with the weird configuration, as you correctly pointed out. When I remove the vqmmc-supply, the device boots, and in the /sys/kernel/debug/mmc1/ios is expected output:

root@device:~# cat /sys/kernel/debug/mmc1/ios 
clock: 52000000 Hz
actual clock: 49500000 Hz
vdd: 21 (3.3 ~ 3.4 V)
bus mode: 2 (push-pull)
chip select: 0 (don't care)
power mode: 2 (on)
bus width: 3 (8 bits)
timing spec: 8 (mmc DDR52)
signal voltage: 1 (1.80 V)
driver type: 0 (driver type B)

Thanks for this.

Best regards,

Tomáš

[Bernard PUEL]

if EMMC IOs are at 1,8v, you will need to replace "mmc-ddr-3_3v" with "mmc-ddr-1_8v"

And

if the EMMC IOS are at 3,3v, you will need to replace "&vdd" with "&v3v3"

[Bernard PUEL]

I see vdd is 3,3v in your trace. Shouldn't it be 1,8v instead ?

[Tomáš Juřena]

No, the main supply is 3v3 but the communication logic (signal voltage) uses the 1v8. I attach the schematic of the eMMC.

[Bernard PUEL]

By the way, do you need further assistance or not ?

[Tomáš Juřena]

Yes, with your suggested change we were able only to fix the incorrect signal voltage to eMMC memory. The original issue with WiFi is still present and we are unable to switch to the DDR_50 mode. The current DT configuration looks like this:

&sdmmc3{
	pinctrl-names = "default", "opendrain", "sleep";
	pinctrl-0 = <&sdmmc3_pins_mx>;
	pinctrl-1 = <&sdmmc3_opendrain_pins_mx>;
	pinctrl-2 = <&sdmmc3_sleep_pins_mx>;
	status = "okay";
 
	/* USER CODE BEGIN sdmmc3 */
	arm,primecell-periphid = <0x10153180>;
	non-removable;
	no-sd;
	no-mmc;
	st,neg-edge;
	bus-width = <4>;
	vmmc-supply = <&v3v3>;
	vqmmc-supply = <&v1v8_ldo1>;
	mmc-pwrseq = <&wifi_pwrseq>;
	/* USER CODE END sdmmc3 */
};

If I remove the vqmmc-supply, and add sd-uhs-ddr50, the SDIO device is not initialized with this message: mmc0: error -110 whilst initialising SDIO card.

This message is shown also for cap-sd-highspeed, sd-uhs-sdr50, and sd-uhs-sdr25.

[Bernard PUEL]

For wlan:

you have to remove vqmmc-supply and that's all. You don't have to add any sdcard property.

you should have only this:

vmmc-supply = <&v3v3>;

mmc-pwrseq = <&wifi_pwrseq>;

For Emmc:

With this configuration only (you said it fails), could we get the full log ?

vmmc-supply = <&v3v3>;

 mmc-ddr-1_8v;

[Tomáš Juřena]

I have tried your suggestion but the wlan still uses the sd high-speed timing spec.

The sdmmc3 node looks like this:

&sdmmc3{
	pinctrl-names = "default", "opendrain", "sleep";
	pinctrl-0 = <&sdmmc3_pins_mx>;
	pinctrl-1 = <&sdmmc3_opendrain_pins_mx>;
	pinctrl-2 = <&sdmmc3_sleep_pins_mx>;
	status = "okay";
 
	/* USER CODE BEGIN sdmmc3 */
	arm,primecell-periphid = <0x10153180>;
	non-removable;
	no-sd;
	no-mmc;
	st,neg-edge;
	bus-width = <4>;
	vmmc-supply = <&v3v3>;
	/*vqmmc-supply = <&v1v8_ldo1>;*/
	mmc-pwrseq = <&wifi_pwrseq>;
	/* USER CODE END sdmmc3 */
};

and the /sys/kernel/debug/mmc0/ios:

clock: 50000000 Hz
actual clock: 34812988 Hz
vdd: 21 (3.3 ~ 3.4 V)
bus mode: 2 (push-pull)
chip select: 0 (don't care)
power mode: 2 (on)
bus width: 2 (4 bits)
timing spec: 2 (sd high-speed)
signal voltage: 0 (3.30 V)
driver type: 0 (driver type B)

[Bernard PUEL]

Sorry again I did not read rightly. On EMMC all is ok.

Please try WLAN sdmmc3 like described above.

[Bernard PUEL]

Ok. something I miss here. Let me check with experts and I'll come back to you.

[Bernard PUEL]

Signal voltage is not correct in sysfs (3,3v instead of 1,8v). Was it better with "vqmmc-supply = <&v1v8_ldo1>;" property ?

[Tomáš Juřena]

No, the signal voltage was 3v3.

[Bernard PUEL]

I/ For us the right config is this one (but you already said it was not working):

sd-uhs-ddr50;

vmmc-supply = <&v3v3>;

mmc-pwrseq = <&wifi_pwrseq>;

Now the Wlan chip and the stm32mp1 should negotiate the interface speed and maybe something is going wrong ...

Could you please with this config activate the traces in sdmmc ? (ie: root:~# echo "file drivers/mmc/* +p" > /sys/kernel/debug/dynamic_debug/control).

II/ We have seen one issue on your clock (not related to above issue):

clock: 50000000 Hz

actual clock: 34812988 Hz

Make sure your clock tree generate a clock close to 50MHz to get better performance (like for EMMC).

I assume you are on the lastest release (5.10 kernel).

[Tomáš Juřena]

I) I attached the dmesg output after enabling the debug and rebinding the driver.

II) We changed the peripheral clock setup so now the SDMMC3 uses the 200 MHz. This is divided by driver to the 50Mhz.

cat /sys/kernel/debug/mmc0/ios 
clock: 50000000 Hz
actual clock: 50000000 Hz

The kernel we use is 5.4.56 because the WLAN driver supports only kernels up to 5.5. Could this be related to the kernel version? I think we could use an open-source version of the driver in the 5.10 kernel release.