On Wed, Jul 2, 2025 at 2:40 PM Martin Blumenstingl
[off-list ref] wrote:

On Wed, Jul 2, 2025 at 7:22 PM Da Xue [off-list ref] wrote:

quoted

On Wed, Jul 2, 2025 at 1:07 PM Jerome Brunet [off-list ref] wrote:
...

quoted

If, as the description suggest, the regulator framework somehow ignore
the timing set in DT, maybe this is what needs to be checked ?

The regulator framework only cares about timing for regulator on.
Regulator off just turns off the regulator and returns without delay.

There's an exception to this: gpio-regulators without an enable-gpios
property. My understanding is that regulator_disable() is a no-op in
that case (meson_mmc_set_ios() even has a comment above the
switch/case statement), see [0].

quoted

The code makes incorrect assumptions. Then the kernel resets the board
without having enough time.

Can you please name the board you're testing? I'm worried that I'll be
looking at one .dts but you're looking at another one.

https://github.com/libre-computer-project/libretech-linux/blob/master/arch/arm64/boot/dts/amlogic/meson-libretech-cottonwood.dtsi#L481

vcc_card is a gpio regulator that gets toggled on->off->on.

I traced the regulator framework a few weeks ago and forgot the final
regulator disable function call, but that call basically returned
immediately while the regulator-enable function complement had delays
implemented.

Best regards,
Martin


[0] https://elixir.bootlin.com/linux/v6.15/source/drivers/regulator/core.c#L2980