On 15.03.2023 16:27, Jerome Brunet wrote: > > On Wed 15 Mar 2023 at 11:20, Marc Gonzalez <marc.w.gonzalez@xxxxxxx> wrote: > >> On 14/03/2023 20:45, Heiner Kallweit wrote: >> >>> On 14.03.2023 18:24, Marc Gonzalez wrote: >>> >>>> With the default power-up delay, on small kernels, the host probes >>>> too soon, and mmc_send_io_op_cond() times out. >>> >>> Looking at mmc_power_up() and how power_delay_ms is used >>> I wonder what you mean with "host probes too soon". >> >> Hello Heiner, >> >> Thanks for your interest in my patch! :) >> >> I should have added a link to the thread that led to the patch. >> https://patchwork.kernel.org/project/linux-wireless/patch/c1a215cf-94be-871b-2a8a-3cc381588f83@xxxxxxx/ >> Start at "I have run into another issue." >> >> Basically, I have an S905X2-based board. >> I built a small kernel for it (with only a few drivers), that boots really fast. >> >> mmc2 (SDIO controller hooked to WiFi chip) would not probe at all, >> unless I added lots of printks. >> Basically, calling mmc_send_io_op_cond() too soon after the controller >> has been reset leads to the CMD5 request timing out. >> >> > > I tend to agree with Heiner here. > This patch is backing a contraint only reported on your design in the > driver of every AML SoC supported, for every MMC controller. > > I think you should look first in your vmmc and vqmmc regulators and > their setup times. > > "fixed-regulator" have properties which might be interesting to you, > like > * startup-delay-us > * off-on-delay-us > >>> Are you sure that the additional delay is needed for the Amlogic MMC >>> block IP in general? Or could it be that your issue is caused by >>> a specific regulator and you need to add a delay there? >> >> The eternal question... >> >> I have only one type of board. (Actually, I have a reference design >> that is slightly different, so I should test on that one as well.) >> Let me ask few more questions: You said that the issue is with a SDIO card. How about eMMC and sdcard, does the issue occur for them too? Then you mention "too soon after reset", but add a delay to power-up. If the delay would be needed after reset, then shouldn't it be in meson_mmc_probe() after the call to device_reset_optional()? >> In vendor kernels, they add delays to the WiFi drivers. >> Maybe they have run into the issue, and they're just fixing the symptom? >> >> Default value for ios.power_delay_ms is 10 ms. >> msleep(ios.power_delay_ms) is called twice in mmc_power_up(). >> So raising the delay from 10 to 20 adds 20 ms >> to the latency of initializing SDIO/SD/MMC controllers. >> >> Would you be willing to test if the problem manifests on your board? >> >> Regards >
