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áš.

[Bernard PUEL]

Hello Tomas,

I see this trace:

[  3.273770] mmci-pl18x 48004000.sdmmc: mmc_regulator_set_vqmmc: found vmmc voltage range of 3300000-3400000uV

Are you sure you have "vqmmc-supply = <&v1v8_ldo1>;" in your devicetree ?

[Tomáš Juřena]

Hello,

yes, this line is there. I am attaching the dts file, that is in the yocto build directory (i.e. <yocto_build>/tmp-glibc/work/stm32mp157c_tevogs_v3_mx-ostl-linux-gnueabi/linux-stm32mp/5.4.56-r0/linux-5.4.56/arch/arm/). I also attach the decompiled dts that I took from the build dir and the dtb itself so you can check it. The v1v8_ldo1 regulator has the phandle number 0x2b and the same value is referenced in the vqmmc-supply of the sdmmc@48004000 node.

p.s.: in the decompiled file I had found the max-frequency is 120 Mhz, so I guess it is the default value, if not specified in the dts.

[Bernard PUEL]

Hello Tomas,

Thanks for the information.

kindly apply this new debug patch on top of all the rest and send me back the log.

I think we are not so far be we are still missing one trick ...

[Tomáš Juřena]

Hi Bernard,

glad to hear that and thank you for your support.

The log is attached.

[Bernard PUEL]

new tentative patch + more traces in case of failure, please apply the 2 patches on top of previous ones.

[Tomáš Juřena]

The boot log.

[Bernard PUEL]

new debug trace. Thanks for your patience.

[Tomáš Juřena]

Hello Bernard,

I am sending the log with the last patch.

[Bernard PUEL]

HEre is a workaround patch. I will explain later on ...

[Tomáš Juřena]

This patch did it. Thank you very much for your help, I will contact the u-blox and NXP tech support for details about this irregularity to standard.

root@tevogs-ruX:~# ip link
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: wwan0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP mode DEFAULT group default qlen 1000
 link/ether 02:08:05:21:00:0b brd ff:ff:ff:ff:ff:ff
3: mlan0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000
 link/ether cc:f9:57:e0:91:b5 brd ff:ff:ff:ff:ff:ff
4: uap0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP mode DEFAULT group default qlen 1000
 link/ether cc:f9:57:e0:92:b5 brd ff:ff:ff:ff:ff:ff
5: wfd0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000
 link/ether ce:f9:57:e0:91:b5 brd ff:ff:ff:ff:ff:ff
root@tevogs-ruX:~# cat /sys/kernel/debug/mmc0/ios 
clock: 50000000 Hz
actual clock: 50000000 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: 7 (sd uhs DDR50)
signal voltage: 0 (3.30 V)
driver type: 0 (driver type B)

Unfortunately, it did not solve the issue with slow communication as we expected. Any guesses why is it still slower than the Toradex in SD mode and 22 Mhz clock frequency?

[Bernard PUEL]

This new patch will skip voltage switch procedure.

From the SDIO spec:

3.1.2 Initialization by I/O Aware Host

...

A host that supports UHS-I sets S18R to 1 in the argument of CMD5 to request a change of the signal voltage to 1.8V. If the card supports UHS-I and the current signal voltage is 3.3V, S18A is set to 1 in the R4 response. If the signal voltage is already 1.8V, the card sets S18A to 0 so that host maintains the current signal voltage. UHS-I is supported in SD mode and S18A is always 0 in SPI mode.

But your wlan chipset is already at 1,8v on the I/O and it puts the S18A bit (bit 24 of OCR register) at 1.

So if this workaround patch works, you may ask your wlan chipset support why this procedure (S18A bit set to 1) is initiated by the chipset whereas it should not.

[Bernard PUEL]

Hello Tomas,

The corrective patches (not the workaround) were some backport from Kernel 5.10 into 5.4 kernel you are using. These patches will be added to the next V2.1.3 maintenance release.

The fact the wlan bandwidth is the same with a sdio interface speed x2 make me think about framework not optimized but without real clue.

Maybe good to raise also the point on your wlan chipset vendor. They may have done some private optimization on toradex board ?

Did you check your code reference and firmware between the 2 setups ?

On DK2 we have not optimized anything on wlan.

[Tomáš Juřena]

Hello Bernard,

I have already written an email to local u-blox support, but have not received any response yet.

Can I somehow measure/debug the performance of the SDIO?

The firmware and driver code was the same, so no difference there. I will check their kernel if I find anything interesting.

[Gregory PLANCHON]

Hello,

we have fixed our Wlan issue.

In order to obtain correct performances, we must add in the device tree, at the level of the brcmf node, these commands:

brcmf: bcrmf@1 {
		reg = <1>;
		compatible = "brcm,bcm4329-fmac";
+		interrupt-parent = <&gpiod>;
+		interrupts = <0 IRQ_TYPE_LEVEL_HIGH>; /* WL_HOST_WAKE */
+		interrupt-names = "host-wake";
	};

if you have any other question don't hesitate.

Regards,

Grégory