> What about something like this?

> diff --git a/drivers/mmc/host/sdhci-pci-core.c b/drivers/mmc/host/sdhci-pci-core.c
> index 1f0bd723f011..0789df732e93 100644
> --- a/drivers/mmc/host/sdhci-pci-core.c
> +++ b/drivers/mmc/host/sdhci-pci-core.c
> @@ -610,8 +610,11 @@ static void sdhci_intel_set_power(struct sdhci_host *host, unsigned char mode,
 
>  	sdhci_set_power(host, mode, vdd);
 
> -	if (mode == MMC_POWER_OFF)
> +	if (mode == MMC_POWER_OFF) {
> +		if (slot->chip->pdev->device == PCI_DEVICE_ID_INTEL_APL_SD)
> +			usleep_range(15000, 17500);
>  		return;
> +	}
 
> 	/*
> 	 * Bus power might not enable after D3 -> D0 transition due to the

I talked to one of our digital hardware engineers who worked on this
issue. He believes that the issue is likely affecting more than just 
Apollo Lake devices and recommended keeping the delay for all of our
devices. Could something like this work?

--- a/drivers/mmc/host/sdhci.c
+++ b/drivers/mmc/host/sdhci.c
@@ -2176,6 +2176,9 @@ EXPORT_SYMBOL_GPL(sdhci_set_power_noreg);
 void sdhci_set_power(struct sdhci_host *host, unsigned char mode,
 		     unsigned short vdd)
 {
+	if (mode == MMC_POWER_OFF)
+		usleep_range(15000, 17500);
+
 	if (IS_ERR(host->mmc->supply.vmmc))
 		sdhci_set_power_noreg(host, mode, vdd);
 	else
  
Regards,
Erick

On 13/03/25 05:35, Erick Shepherd wrote:
>> What about something like this?
> 
>> diff --git a/drivers/mmc/host/sdhci-pci-core.c b/drivers/mmc/host/sdhci-pci-core.c
>> index 1f0bd723f011..0789df732e93 100644
>> --- a/drivers/mmc/host/sdhci-pci-core.c
>> +++ b/drivers/mmc/host/sdhci-pci-core.c
>> @@ -610,8 +610,11 @@ static void sdhci_intel_set_power(struct sdhci_host *host, unsigned char mode,
>  
>>  	sdhci_set_power(host, mode, vdd);
>  
>> -	if (mode == MMC_POWER_OFF)
>> +	if (mode == MMC_POWER_OFF) {
>> +		if (slot->chip->pdev->device == PCI_DEVICE_ID_INTEL_APL_SD)
>> +			usleep_range(15000, 17500);
>>  		return;
>> +	}
>  
>> 	/*
>> 	 * Bus power might not enable after D3 -> D0 transition due to the
> 
> I talked to one of our digital hardware engineers who worked on this
> issue. He believes that the issue is likely affecting more than just 
> Apollo Lake devices and recommended keeping the delay for all of our
> devices. Could something like this work?
> 
> --- a/drivers/mmc/host/sdhci.c
> +++ b/drivers/mmc/host/sdhci.c
> @@ -2176,6 +2176,9 @@ EXPORT_SYMBOL_GPL(sdhci_set_power_noreg);
>  void sdhci_set_power(struct sdhci_host *host, unsigned char mode,
>  		     unsigned short vdd)
>  {
> +	if (mode == MMC_POWER_OFF)
> +		usleep_range(15000, 17500);
> +
>  	if (IS_ERR(host->mmc->supply.vmmc))
>  		sdhci_set_power_noreg(host, mode, vdd);
>  	else

sdhci is used by a number of drivers (drivers/mmc/host/sdhci*)
that typically use the regulator framework to meet voltage
requirements. So that is not the right place to make changes.

It would be best to put the affected PCI device IDs into
sdhci_intel_set_power() as I showed.

> sdhci is used by a number of drivers (drivers/mmc/host/sdhci*)
> that typically use the regulator framework to meet voltage
> requirements. So that is not the right place to make changes.

> It would be best to put the affected PCI device IDs into
> sdhci_intel_set_power() as I showed.

I see, that makes sense. The majority of our devices are using either
Apollo Lake or Bay Trail host controllers. Would it be ok to expand
your solution to include both? I tested the following change on a few
of our devices and confirmed the delay is called. If this looks good I
can submit a V2 of this patch.

--- a/drivers/mmc/host/sdhci-pci-core.c
+++ b/drivers/mmc/host/sdhci-pci-core.c
@@ -610,9 +610,12 @@ static void sdhci_intel_set_power(struct sdhci_host *host, unsigned char mode,
 
 	sdhci_set_power(host, mode, vdd);
 
-	if (mode == MMC_POWER_OFF)
+	if (mode == MMC_POWER_OFF) {
+		if (slot->chip->pdev->device == PCI_DEVICE_ID_INTEL_APL_SD ||
+		    slot->chip->pdev->device == PCI_DEVICE_ID_INTEL_BYT_SD)
+			usleep_range(15000, 17500);
 		return;
-
+	}
 	/*
 	 * Bus power might not enable after D3 -> D0 transition due to the
 	 * present state not yet having propagated. Retry for up to 2ms.
-- 

Regards,
Erick

On 13/03/25 22:44, Erick Shepherd wrote:
>> sdhci is used by a number of drivers (drivers/mmc/host/sdhci*)
>> that typically use the regulator framework to meet voltage
>> requirements. So that is not the right place to make changes.
> 
>> It would be best to put the affected PCI device IDs into
>> sdhci_intel_set_power() as I showed.
> 
> I see, that makes sense. The majority of our devices are using either
> Apollo Lake or Bay Trail host controllers. Would it be ok to expand
> your solution to include both? I tested the following change on a few
> of our devices and confirmed the delay is called. If this looks good I
> can submit a V2 of this patch.
> 
> --- a/drivers/mmc/host/sdhci-pci-core.c
> +++ b/drivers/mmc/host/sdhci-pci-core.c
> @@ -610,9 +610,12 @@ static void sdhci_intel_set_power(struct sdhci_host *host, unsigned char mode,
>  
>  	sdhci_set_power(host, mode, vdd);
>  
> -	if (mode == MMC_POWER_OFF)
> +	if (mode == MMC_POWER_OFF) {
> +		if (slot->chip->pdev->device == PCI_DEVICE_ID_INTEL_APL_SD ||
> +		    slot->chip->pdev->device == PCI_DEVICE_ID_INTEL_BYT_SD)
> +			usleep_range(15000, 17500);
>  		return;
> -
> +	}
>  	/*
>  	 * Bus power might not enable after D3 -> D0 transition due to the
>  	 * present state not yet having propagated. Retry for up to 2ms.

That would be fine