Re: [PATCH] mmc: meson-gx: increase power-up delay

[Marc Gonzalez <marc.w.gonzalez@free.fr>]

On 16/03/2023 13:32, Marc Gonzalez wrote:

> On 15/03/2023 22:14, Heiner Kallweit wrote:
> 
>> 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()?
> 
> The first mmc_power_up() is called from:
> 
> [    0.916446]  mmc_power_up+0x2c/0xe4
> [    0.926186]  mmc_start_host+0x94/0xa0
> [    0.926197]  mmc_add_host+0x84/0xf0
> [    0.926205]  meson_mmc_probe+0x374/0x3f4
> [    0.933086]  platform_probe+0x68/0xe0
> [    0.940159]  really_probe+0xbc/0x2f0
> [    0.948008]  __driver_probe_device+0x78/0xe0
> [    0.955080]  driver_probe_device+0xd8/0x160
> [    0.955087]  __driver_attach_async_helper+0x4c/0xc0
> [    0.965689]  async_run_entry_fn+0x34/0xe0
> [    0.965699]  process_one_work+0x1cc/0x320
> [    0.972847]  worker_thread+0x14c/0x450
> [    0.972855]  kthread+0x10c/0x110
> [    1.018906]  ret_from_fork+0x10/0x20
> 
> 
> The second mmc_power_up() (prematurely exited) is called from:
> 
> [    1.061686]  mmc_power_up+0x2c/0xe4
> [    1.065136]  mmc_rescan+0x18c/0x310
> [    1.068586]  process_one_work+0x1cc/0x320
> [    1.072553]  worker_thread+0x14c/0x450
> [    1.076262]  kthread+0x10c/0x110
> [    1.086528]  ret_from_fork+0x10/0x20
> 
> 
> I'm confused about device_reset_optional() vs mmc_power_up().
> Do they both reset the controller?

NB: adding 500 ms delay after device_reset_optional() DOES NOT
fix the issue:

[    0.875494] >ffe03000.sd
[    0.875823] meson-gx-mmc ffe03000.sd: allocated mmc-pwrseq
[    1.027111] >ffe07000.mmc
[    1.027430] meson-gx-mmc ffe07000.mmc: allocated mmc-pwrseq
[    1.405170] +mmc2
[    1.405389] -mmc2
[    1.405413] <ffe03000.sd
[    1.405500] +mmc2
[    1.412957] Q
[    1.420317] R
[    1.422590] mmc2: YO no device WTF

We enter mmc_power_up at 1.405170
We enter mmc_attach_sdio at 1.412957
Empirically, 8 ms is not enough time for the SDIO bus to be ready.



Reverting to default power_delay_ms.

[    0.879842] >ffe03000.sd
[    0.880189] meson-gx-mmc ffe03000.sd: allocated mmc-pwrseq
[    1.031635] >ffe07000.mmc
[    1.031958] meson-gx-mmc ffe07000.mmc: allocated mmc-pwrseq
[    1.405284] +mmc2
[    1.430499] -mmc2
[    1.430525] <ffe03000.sd
[    1.430616] +mmc2
[    1.438065] Q
[    1.445404] R
[    1.447677] mmc2: YO no device WTF

We enter mmc_power_up at 1.405284
We enter mmc_attach_sdio at 1.438065
Empirically, 33 ms is not enough time for the SDIO bus to be ready.



Increasing power_delay_ms to 15.

[    0.879788] >ffe03000.sd
[    0.880092] meson-gx-mmc ffe03000.sd: allocated mmc-pwrseq
[    1.031437] >ffe07000.mmc
[    1.031767] meson-gx-mmc ffe07000.mmc: allocated mmc-pwrseq
[    1.405262] +mmc2
[    1.442981] -mmc2
[    1.443007] <ffe03000.sd
[    1.443099] +mmc2
[    1.450549] Q
[    1.565950] +mmc1
[    1.584306] mmc2: new ultra high speed SDR50 SDIO card at address 0001

We enter mmc_power_up at 1.405262
We enter mmc_attach_sdio at 1.450549
Empirically, 45 ms *is* enough time for the SDIO bus to be ready.


My gut feeling is that the problem with SDIO devices exists on all boards.
(I am well aware that I may be wrong.)

Would you be willing to test a small kernel?
I can provide a kernel defconfig and/or a buildroot defconfig.


Regards


_______________________________________________
linux-amlogic mailing list
linux-amlogic@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-amlogic