[PATCH v2 0/3] mmc: Add power_off_delay_us support

[PATCH v2 0/3] mmc: Add power_off_delay_us support

[Judith Mendez]

This series adds power_off_delay_us support for MMC controllers,
enabling boards to specify custom delays after MMC power off to work around
hardware issues such as slow RC circuites on MMC VDD rails.

Rather than adding host driver-specific workarounds, we abstract the
implementation into the MMC core and pickup the delay value with a device
tree property (power-off-delay-us). This allows any board with slow
power off requirements to configure the necessary delay without code
changes.

The solution is minimal and follows existing patterns as with
power_delay_ms. The allowed minimum value = 1us and maximum value=
10000000us. The default value is 1000us to not deviate from the
original 1ms delay set in mmc_power_off().

Requesting comments for how big the delay should be maxed at, currently
it is set to 10000000us, but not sure if this is too high. Testing
10000000us on AM65 EVM seems to not break SD boot so going with this
value as the max allowed value for now.

Link to v1:
https://lore.kernel.org/all/20260716232641.2659710-1-jm@ti.com/

Changes since v1:
- Add mmc_delay_us()
- Switch from ms to us implementation due to switch from
  post_power_on_delay_ms to power_off_delay_us
- Update commit messages to include more coverletter descriptions

Judith Mendez (3):
  dt-bindings: mmc: Add power-off-delay-us property
  mmc: core: Add mmc_delay_us() for microsecond precision delays
  mmc: core: Add power-off-delay-us support

 .../bindings/mmc/mmc-controller-common.yaml         | 10 ++++++++++
 drivers/mmc/core/core.c                             |  2 +-
 drivers/mmc/core/core.h                             | 13 +++++++++++++
 drivers/mmc/core/host.c                             |  8 ++++++++
 include/linux/mmc/host.h                            |  1 +
 5 files changed, 33 insertions(+), 1 deletion(-)

-- 
2.54.0

[PATCH v2 1/3] dt-bindings: mmc: Add power-off-delay-us property

[Judith Mendez]

Add power-off-delay-us property to MMC controller common.

This property shall be used to specify value of delay after
deasserting power during MMC power cycles. Default for delay
is 1000us but custom delay can be passed in to work around
hardware issues such as slow RC discharge on MMC VDD rails.

Signed-off-by: Judith Mendez <jm@ti.com>
---
Changes since v1:
- Change post-power-off-delay-ms to power-off-delay-us
- Fixup dt property description
- Fix check binding warnings and remove $ref
- Fix minimum from 0 to 1us
---
 .../devicetree/bindings/mmc/mmc-controller-common.yaml | 10 ++++++++++
 1 file changed, 10 insertions(+)

diff --git a/Documentation/devicetree/bindings/mmc/mmc-controller-common.yaml b/Documentation/devicetree/bindings/mmc/mmc-controller-common.yaml
index 3d7195e9461c3..2015292618c80 100644
--- a/Documentation/devicetree/bindings/mmc/mmc-controller-common.yaml
+++ b/Documentation/devicetree/bindings/mmc/mmc-controller-common.yaml
@@ -275,6 +275,16 @@ properties:
       not available.
     default: 10
 
+  power-off-delay-us:
+    description:
+      Delay in microseconds after card power is deasserted during a power
+      cycle to allow time for proper power discharge. Larger values can be
+      configured to work around hardware issues such as slow RC discharge
+      on MMC VDD rails.
+    minimum: 1
+    maximum: 10000000
+    default: 1000
+
   supports-cqe:
     $ref: /schemas/types.yaml#/definitions/flag
     description:
-- 
2.54.0

[PATCH v2 2/3] mmc: core: Add mmc_delay_us() for microsecond precision delays

[Judith Mendez]

Add mmc_delay_us() to support microsecond-granularity delays needed
in MMC framework. It uses 25% margin consistent with  mmc_delay() for
timing flexibility.

Signed-off-by: Judith Mendez <jm@ti.com>
---
Changes since v1:
- add patch 2/3
---
 drivers/mmc/core/core.h | 13 +++++++++++++
 1 file changed, 13 insertions(+)

diff --git a/drivers/mmc/core/core.h b/drivers/mmc/core/core.h
index a028b48be1644..55e9fb3bab9f7 100644
--- a/drivers/mmc/core/core.h
+++ b/drivers/mmc/core/core.h
@@ -73,6 +73,19 @@ static inline void mmc_delay(unsigned int ms)
 		msleep(ms);
 }
 
+static inline void mmc_delay_us(unsigned int us)
+{
+	if (us < 1000) {
+		usleep_range(us, us + (us >> 2));
+	} else {
+		unsigned int rem_us = us % 1000;
+
+		msleep(us / 1000);
+		if (rem_us)
+			usleep_range(rem_us, rem_us + (rem_us >> 2));
+	}
+}
+
 void mmc_rescan(struct work_struct *work);
 void mmc_start_host(struct mmc_host *host);
 void __mmc_stop_host(struct mmc_host *host);
-- 
2.54.0

Re: [PATCH v2 2/3] mmc: core: Add mmc_delay_us() for microsecond precision delays

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [Medium] mmc_delay_us() incorrectly uses msleep() for short delays, causing massive oversleeping and destroying precision
- [Medium] mmc_delay_us() uses usleep_range() with zero slack for small delays and violates timer usage guidelines for <10us delays
--

--- Patch [2]: [PATCH v2 2/3] mmc: core: Add mmc_delay_us() for microsecond precision delays ---
commit c0ce7d5a46919cedbd3c712e3639e844d38294c9
Author: Judith Mendez <jm@ti.com>

mmc: core: Add mmc_delay_us() for microsecond precision delays
    
Add mmc_delay_us() to support microsecond-granularity delays needed
in MMC framework. It uses 25% margin consistent with  mmc_delay() for
timing flexibility.

> diff --git a/drivers/mmc/core/core.h b/drivers/mmc/core/core.h
> index a028b48be1644..55e9fb3bab9f7 100644
> --- a/drivers/mmc/core/core.h
> +++ b/drivers/mmc/core/core.h

[ ... ]

> @@ -73,6 +73,19 @@ static inline void mmc_delay(unsigned int ms)
>  		msleep(ms);
>  }
>  
> +static inline void mmc_delay_us(unsigned int us)
> +{
> +	if (us < 1000) {
> +		usleep_range(us, us + (us >> 2));

[Severity: Medium]
When us is less than 4, will this pass 0 slack to usleep_range()? For
example, if us is 2, this calls usleep_range(2, 2), which defeats timer
coalescing.

Also, for delays under 10us, should this use udelay() instead? Kernel
documentation recommends udelay() for delays < 10us because the context
switch overhead of usleep_range() often outweighs the delay itself.

> +	} else {
> +		unsigned int rem_us = us % 1000;
> +
> +		msleep(us / 1000);

[Severity: Medium]
Does using msleep() here break the expected microsecond precision?

On systems with a low HZ value (like HZ=100), msleep(1) will sleep for at
least 1 jiffy, which is 10ms. This can cause the function to oversleep by
10-20x the requested duration.

Kernel timers documentation generally recommends using usleep_range() for
delays up to 20ms instead of falling back to msleep() at 1ms.

> +		if (rem_us)
> +			usleep_range(rem_us, rem_us + (rem_us >> 2));

[Severity: Medium]
Similar to the issue above, if rem_us is less than 4, this provides 0 slack
to the hrtimer subsystem.

Additionally, splitting a mixed delay like 1500us into msleep(1) and
usleep_range(500, 625) forces two context switches. Since msleep() has high
variance, does the subsequent fine-grained usleep_range() actually improve
precision, or does it just add unnecessary overhead?

> +	}
> +}
> +
>  void mmc_rescan(struct work_struct *work);

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260722205701.372789-1-jm@ti.com?part=2

[PATCH v2 3/3] mmc: core: Add power-off-delay-us support

[Judith Mendez]

Add support for power-off-delay-us which shall be used to specify
value of delay after deasserting power during MMC power cycles.
Default for delay is 1000us but custom delay can be passed in to work
around hardware issues such as slow RC discharge on MMC VDD rails.

Signed-off-by: Judith Mendez <jm@ti.com>
---
Changes since v1:
- Move delay to mmc_power_off
- Fix dt checks and remove print
- Move from mmc_host struct to mmc_ios struct
- Rename post-power-off-delay-ms to power_off_delay_us
---
 drivers/mmc/core/core.c  | 2 +-
 drivers/mmc/core/host.c  | 8 ++++++++
 include/linux/mmc/host.h | 1 +
 3 files changed, 10 insertions(+), 1 deletion(-)

diff --git a/drivers/mmc/core/core.c b/drivers/mmc/core/core.c
index 29e80e5f928e9..9472041fe1c20 100644
--- a/drivers/mmc/core/core.c
+++ b/drivers/mmc/core/core.c
@@ -1388,7 +1388,7 @@ void mmc_power_off(struct mmc_host *host)
 	 * XO-1.5, require a short delay after poweroff before the card
 	 * can be successfully turned on again.
 	 */
-	mmc_delay(1);
+	mmc_delay_us(host->ios.power_off_delay_us);
 }
 
 void mmc_power_cycle(struct mmc_host *host, u32 ocr)
diff --git a/drivers/mmc/core/host.c b/drivers/mmc/core/host.c
index b7ce3137d4529..fac50a2860211 100644
--- a/drivers/mmc/core/host.c
+++ b/drivers/mmc/core/host.c
@@ -421,6 +421,13 @@ int mmc_of_parse(struct mmc_host *host)
 	device_property_read_u32(dev, "post-power-on-delay-ms",
 				 &host->ios.power_delay_ms);
 
+	device_property_read_u32(dev, "power-off-delay-us",
+				 &host->ios.power_off_delay_us);
+	if (host->ios.power_off_delay_us < 1)
+		host->ios.power_off_delay_us = 1000;
+	if (host->ios.power_off_delay_us > 10000000)
+		host->ios.power_off_delay_us = 10000000;
+
 	return mmc_pwrseq_alloc(host);
 }
 
@@ -574,6 +581,7 @@ struct mmc_host *mmc_alloc_host(int extra, struct device *dev)
 
 	host->fixed_drv_type = -EINVAL;
 	host->ios.power_delay_ms = 10;
+	host->ios.power_off_delay_us = 1000;
 	host->ios.power_mode = MMC_POWER_UNDEFINED;
 
 	return host;
diff --git a/include/linux/mmc/host.h b/include/linux/mmc/host.h
index ba84f02c2a101..714417466707c 100644
--- a/include/linux/mmc/host.h
+++ b/include/linux/mmc/host.h
@@ -23,6 +23,7 @@ struct mmc_ios {
 	unsigned int	clock;			/* clock rate */
 	unsigned short	vdd;
 	unsigned int	power_delay_ms;		/* waiting for stable power */
+	unsigned int	power_off_delay_us;	/* waiting for power discharge */
 
 /* vdd stores the bit number of the selected voltage range from below. */
 
-- 
2.54.0

Re: [PATCH v2 3/3] mmc: core: Add power-off-delay-us support

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] Replacing `mmc_delay(1)` with `mmc_delay_us(host->ios.power_off_delay_us)` (which defaults to 1000) inadvertently changes the underlying timer mechanism from `usleep_range` to `msleep(1)`, introducing a latency regression of up to ~20ms per power-off cycle.
--

--- Patch [3]: [PATCH v2 3/3] mmc: core: Add power-off-delay-us support ---
commit 028a9284e6d11b892584840a7f05aeed49d66b60
Author: Judith Mendez <jm@ti.com>

mmc: core: Add power-off-delay-us support

This commit adds support for power-off-delay-us to specify a custom delay
after deasserting power during MMC power cycles. The default delay is set
to 1000us, but can be overridden to work around hardware issues.

> diff --git a/drivers/mmc/core/core.c b/drivers/mmc/core/core.c
> --- a/drivers/mmc/core/core.c
> +++ b/drivers/mmc/core/core.c
> @@ -1388,7 +1388,7 @@ void mmc_power_off(struct mmc_host *host)
>  	 * XO-1.5, require a short delay after poweroff before the card
>  	 * can be successfully turned on again.
>  	 */
> -	mmc_delay(1);
> +	mmc_delay_us(host->ios.power_off_delay_us);

[Severity: Medium]
Does this change introduce a latency regression during power management
operations?

The default value for power_off_delay_us is 1000. When mmc_delay_us() is
called with 1000 or greater, it falls into the msleep() path:

drivers/mmc/core/core.h:mmc_delay_us() {
	if (us < 1000) {
		usleep_range(us, us + (us >> 2));
	} else {
		unsigned int rem_us = us % 1000;

		msleep(us / 1000);
		if (rem_us)
			usleep_range(rem_us, rem_us + (rem_us >> 2));
	}
}

This effectively calls msleep(1), which uses jiffy-based timeouts. On
systems where HZ=100, this can delay execution by up to 20ms per power-off
cycle. The original mmc_delay(1) call correctly used the high-resolution
usleep_range(1000, 1250) timer mechanism.

Could the threshold for mmc_delay_us() be adjusted, or could usleep_range()
be used to avoid an unintended jiffy-based sleep?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260722205701.372789-1-jm@ti.com?part=3