cancel
Showing results for 
Search instead for 
Did you mean: 

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

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

75 REPLIES 75

Hello,

thanks for your continuous support.

I have done what you asked for and I am attaching the log. Is quite huge because the eMMC is connected also using the MMC bus.

Hello,

I realized that I sent you the log without the sdmmc_vswitch patch (does nothing and returns 0). The correct log is attached.

Bernard PUEL
ST Employee

sorry but you need to have also:

sd-uhs-ddr50;

To force uhs mode. IT seems you don't have.

Bernard PUEL
ST Employee

No related to functional issue but I saw in this log and also in previous ones:

[  3.219869] mmci-pl18x 48004000.sdmmc: clocking block at 120000000 Hz

IT seems the SDMMC is clocked at 120MHz whereas it is supposed to be at 200Mhz (from your information above).

I thought that it is missing.

Just to make it clear, this log is generated with the following configuration:

&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>;
	sd-uhs-ddr50;
	vqmmc-supply = <&v1v8_ldo1>;
	mmc-pwrseq = <&wifi_pwrseq>;
	/* USER CODE END sdmmc3 */
};

sdmmc_vswitch

static int sdmmc_vswitch(struct mmci_host *host, struct mmc_ios *ios)
{
	unsigned long flags;
	u32 status;
	int ret = 0;
#if 0
	if (ios->signal_voltage == MMC_SIGNAL_VOLTAGE_180) {
		spin_lock_irqsave(&host->lock, flags);
		mmci_write_pwrreg(host, host->pwr_reg | MCI_STM32_VSWITCH);
		spin_unlock_irqrestore(&host->lock, flags);
 
		/* wait voltage switch completion while 10ms */
		ret = readl_relaxed_poll_timeout(host->base + MMCISTATUS,
						 status,
						 (status & MCI_STM32_VSWEND),
						 10, 10000);
 
		writel_relaxed(MCI_STM32_VSWENDC | MCI_STM32_CKSTOPC,
			       host->base + MMCICLEAR);
 
		spin_lock_irqsave(&host->lock, flags);
		mmci_write_pwrreg(host, host->pwr_reg &
				  ~(MCI_STM32_VSWITCHEN | MCI_STM32_VSWITCH));
		spin_unlock_irqrestore(&host->lock, flags);
	}
#endif
	return ret;
}

I saw that too, but not really sure, how it happened. The clock tree in cubeMX shows the value 200Mhz for SDMMC3.

Bernard PUEL
ST Employee

Could you please share the same but without the patch on sdmmc_vswitch() ?

We saw the init sequence looks better and the switch voltage procedure needs to be done (event if we will keep the same voltage).

Of course. The log is attached.

Bernard PUEL
ST Employee

For the clock strange value, could you please output the result of this command (just to double check RCC settings are ok):

> cat /sys/kernel/debug/clk/clk_summary

Bernard PUEL
ST Employee

For the last trace, we are a bit confused because looking at the 5.4.56 code version and the trace, we are seeing some mismatch (some inconsistency between the behavior and what is in the code).

What is the code you had backported from the kernel 5.10 in to your baseline (based on kernel 5.4.56) ?