Re: [RFC] mmc: meson-gx-mmc: add delay during poweroff
From: Jerome Brunet <jbrunet@baylibre.com>
Date: 2025-07-02 17:07:28
Also in:
linux-amlogic, linux-mmc, lkml
On Wed 02 Jul 2025 at 18:27, Martin Blumenstingl [off-list ref] wrote:
Hi Anand, On Tue, Jul 1, 2025 at 12:00 PM Anand Moon [off-list ref] wrote:quoted
Hi Da, On Sat, 28 Jun 2025 at 09:15, Da Xue [off-list ref] wrote:quoted
Regulators controlling the SD card power need some settling time for SD cards to fully reset from UHS modes. The regulator framework seems to ignore falling times set in the device tree causing a few boards with the same hardware implementation to hang on reboot because the SD card still had some voltage and did not reset properly to be initialized again. Add a delay sufficiently long for the voltage to drop so that the SD card can reset properly. Otherwise the reboot will hang at missing SD card especially with Samsung cards.Although the driver defines reset identifiers such as RESET_SD_EMMC_A, RESET_SD_EMMC_B, and RESET_SD_EMMC_C, It does not implement proper reset controller functionality, specifically lacking support for reset_control_assert() and reset_control_deassert() operations.I think there's a misunderstanding: The meson-gx-mmc driver calls device_reset_optional() during .probe which will internally call reset_control_reset(). So I don't see a problem here. The patch seems more about power sequencing, where either the SD card or regulator used to power the SD card requires a certain amount of time (delay) when switching from ON -> OFF -> ON (my understanding is: without this delay the card sees ON -> ON which fails to update some state internally). To me it's not clear if this is a property of the SD spec or rather the regulator. Ulf, Jerome - any ideas / inputs from you?
If, as the description suggest, the regulator framework somehow ignore the timing set in DT, maybe this is what needs to be checked ? TBH I would suspect the delays before the regulator framework itself. Those assert/de-assert delays tend to be just copied from boards to boards. Maybe some boards need different delays. If those are too short for the actual HW, an ON -> OFF -> ON could result in a NOP.
Best regards, Martin
-- Jerome