> Subject: Re: AW: [PATCH] mmc: Fix missing 1 ms delay after mmc > power up > > Hi Peng, > > On Di, 2025-11-18 at 12:56 +0800, Peng Fan wrote: > > On Mon, Nov 10, 2025 at 08:46:39PM +0000, Christoph Stoidner > wrote: > > > Hi Peng, thanks for your feedback. > > > > > > > Hi Christoph > > > > > > > > Thanks for your patch. > > > > > > > > > Subject: [PATCH] mmc: Fix missing 1 ms delay after mmc power > up > > > ... > > > > > + udelay(2000); > > > > > > > > Per spec, > > > > From Figure 6-4: Power-up Diagram of Card the 1ms is > voltageSupply > > > > ramp up time, so I am thinking the fix should be in your regulator > > > > side, saying startup-delay-us property in your regulator node. > > > > > > True, this could also be handled via the regulator?s DTS properties, > > > and some boards already do that. However, from my point of view, > > > that?s not the right place for this particular delay. > > > > > > The SD specification distinguishes between two different delays (see > > > Figure 6-5 ?Power-Up Diagram (Host)? in SD Spec 6.00, ?6.4.1): > > > > > > 1) "Power ramp up" > > > 2) "Stable voltage delay" > > > > > > The first one (power ramp up) is regulator-specific and should > > > indeed be covered by the regulator?s startup-delay-us property in > > > the device tree. > > > But this patch is about the second one - the "stable voltage delay". > > > > > > That delay is completely independent of any regulator/voltage- > > > supply or board characteristics; it is a constant 1ms delay by the > > > SD interface itself to ensure correct card initialization timing. > > > Decoupling it from the regulators would make board-code > developers > > > live easier, and can make U-Boot?s MMC initialization more robust > > > across all boards. > > > > > > What do you think about that? > > > > Sorry for late. > > Thanks for explaining this, this is reasonable. I am thinking it might > > be better if we add ios.post_power_delay_ms for your platform. > > you mean we should introduce the DTS property > post_power_delay_ms for mmc and then use it in our platform's DTS? > > But a DTS property is actually what I want to avoid, because that delay > is nothing platform-specific and should be solved all for one in the > mmc subsystem drivers/mmc/mmc.c itself. > > What's the reason why you prefer a DTS property?
You message seems breaks the mail thread. So my script not able to retrieve the message thread from patchwork. I just don't like to add delays. Reading the spec again, I am fine with your changes. Thanks, Peng. > > Regards, > Christoph > > > > > Regards > > Peng > > > > > > > > Regards, > > > Christoph > > > > > > > Thanks, > > > > Peng. > > > > > > > > > + return ret; > > > ...
