[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1j4ivued2q.fsf@starbuckisacylon.baylibre.com>
Date: Wed, 02 Jul 2025 19:07:25 +0200
From: Jerome Brunet <jbrunet@...libre.com>
To: Martin Blumenstingl <martin.blumenstingl@...glemail.com>
Cc: Anand Moon <linux.amoon@...il.com>, Da Xue <da@...re.computer>, Ulf
Hansson <ulf.hansson@...aro.org>, Neil Armstrong
<neil.armstrong@...aro.org>, Kevin Hilman <khilman@...libre.com>,
linux-mmc@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
linux-amlogic@...ts.infradead.org, linux-kernel@...r.kernel.org
Subject: Re: [RFC] mmc: meson-gx-mmc: add delay during poweroff
On Wed 02 Jul 2025 at 18:27, Martin Blumenstingl <martin.blumenstingl@...glemail.com> wrote:
> Hi Anand,
>
> On Tue, Jul 1, 2025 at 12:00 PM Anand Moon <linux.amoon@...il.com> wrote:
>>
>> Hi Da,
>>
>> On Sat, 28 Jun 2025 at 09:15, Da Xue <da@...re.computer> wrote:
>> >
>> > 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
Powered by blists - more mailing lists