Thread (7 messages) 7 messages, 4 authors, 2025-07-03

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
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help