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

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

quoted

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

quoted

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.

Thanks, that clears things up as I was indeed looking at a gpio
regulator while this is a fixed regulator!

quoted

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.

Yep, for fixed regulators there's an "off-on-delay-us" device-tree
property (which translates to "off_on_delay" in the code).
Its implementation is smart enough to not waste time by adding delays
at runtime by implementing: on -> off + remember time -> wait
remaining time + on (meaning: if there was enough time between off and
the second on there's no additional wait) [0]. On system shutdown it
will not add any delay unfortunately (where Linux loses control over
time-keeping), meaning we can end up with too little waiting time.

Yes, this is evident on quite a few Amlogic boards but occurred rarely
enough that it can be overlooked but never-the-less should be
addressed.

On our SM1 board, this occurs more often than not. With this patch, we
can reboot the loop indefinitely.

Also my understanding is that it's not something that can be fixed in
u-boot or TF-A. This is because bootrom already has trouble reading
the next stage from an SD card (which is a valid boot media).

Correct, not fixable in TF-A or u-boot.

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