diff mbox series

mmc: renesas_sdhi: increase suspend/resume latency limit

Message ID 20210514155318.16812-1-uli+renesas@fpond.eu (mailing list archive)
State Under Review
Delegated to: Geert Uytterhoeven
Headers show
Series mmc: renesas_sdhi: increase suspend/resume latency limit | expand

Commit Message

Ulrich Hecht May 14, 2021, 3:53 p.m. UTC
The TMIO core sets a very low latency limit (100 us), but when using R-Car
SDHI hosts with SD cards, I have observed typical latencies of around 20-30
ms. This prevents runtime PM from working properly, and the devices remain
on continuously.

This patch sets the default latency limit to 100 ms to avoid that.

Signed-off-by: Ulrich Hecht <uli+renesas@fpond.eu>
---
 drivers/mmc/host/renesas_sdhi_core.c | 4 ++++
 1 file changed, 4 insertions(+)

Comments

Wolfram Sang May 19, 2021, 2:25 p.m. UTC | #1
Hi Uli,

On Fri, May 14, 2021 at 05:53:18PM +0200, Ulrich Hecht wrote:
> The TMIO core sets a very low latency limit (100 us), but when using R-Car
> SDHI hosts with SD cards, I have observed typical latencies of around 20-30
> ms. This prevents runtime PM from working properly, and the devices remain
> on continuously.
> 
> This patch sets the default latency limit to 100 ms to avoid that.
> 
> Signed-off-by: Ulrich Hecht <uli+renesas@fpond.eu>

Well, yes, I can confirm that this helps wrt the "always-enabled" clock.
However, when removing UHS cards, I now see this regression:

[    8.659916] mmcblk2: mmc2:0001 00000 29.8 GiB 
[    8.677304]  mmcblk2: p1
[    9.622918] mmc2: tuning execution failed: -5
[    9.627385] mmc2: card 0001 removed

It is interesting to see the "execution failed" error when *removing*
the card. Before removing, access to the card seems fine. I haven't
checked further, so I can't say yet if this is a related or seperate but
now undiscovered issue.

Thanks for the work so far!

   Wolfram
Ulrich Hecht June 2, 2021, 3:40 p.m. UTC | #2
> On 05/19/2021 4:25 PM Wolfram Sang <wsa@kernel.org> wrote:
> On Fri, May 14, 2021 at 05:53:18PM +0200, Ulrich Hecht wrote:
> > The TMIO core sets a very low latency limit (100 us), but when using R-Car
> > SDHI hosts with SD cards, I have observed typical latencies of around 20-30
> > ms. This prevents runtime PM from working properly, and the devices remain
> > on continuously.
> > 
> > This patch sets the default latency limit to 100 ms to avoid that.
> > 
> > Signed-off-by: Ulrich Hecht <uli+renesas@fpond.eu>
> 
> Well, yes, I can confirm that this helps wrt the "always-enabled" clock.
> However, when removing UHS cards, I now see this regression:
> 
> [    8.659916] mmcblk2: mmc2:0001 00000 29.8 GiB 
> [    8.677304]  mmcblk2: p1
> [    9.622918] mmc2: tuning execution failed: -5
> [    9.627385] mmc2: card 0001 removed
> 
> It is interesting to see the "execution failed" error when *removing*
> the card. Before removing, access to the card seems fine. I haven't
> checked further, so I can't say yet if this is a related or seperate but
> now undiscovered issue.

I have traced this, and it seems to be triggered by mmc_sd_detect(), which is called by mmc_rescan() and does this:

[...]
        /*
         * Just check if our card has been removed.
         */
        err = _mmc_detect_card_removed(host);

        mmc_put_card(host->card, NULL);

        if (err) {
                mmc_sd_remove(host);
[...]

_mmc_detect_card_removed() calls mmc_sd_alive(), which tries to send a command to the SD card to see if it's still there, which in turn triggers the retune. IOW, this is expected to fail, and the error message is misleading.

CU
Uli
diff mbox series

Patch

diff --git a/drivers/mmc/host/renesas_sdhi_core.c b/drivers/mmc/host/renesas_sdhi_core.c
index 635bf31a6735..4f41616cc6bb 100644
--- a/drivers/mmc/host/renesas_sdhi_core.c
+++ b/drivers/mmc/host/renesas_sdhi_core.c
@@ -32,6 +32,7 @@ 
 #include <linux/pinctrl/pinctrl-state.h>
 #include <linux/platform_device.h>
 #include <linux/pm_domain.h>
+#include <linux/pm_qos.h>
 #include <linux/regulator/consumer.h>
 #include <linux/reset.h>
 #include <linux/sh_dma.h>
@@ -1147,6 +1148,9 @@  int renesas_sdhi_probe(struct platform_device *pdev,
 		host->ops.hs400_complete = renesas_sdhi_hs400_complete;
 	}
 
+	/* keep tmio_mmc_host_probe() from setting latency limit too low */
+	dev_pm_qos_expose_latency_limit(&pdev->dev, 100000);
+
 	ret = tmio_mmc_host_probe(host);
 	if (ret < 0)
 		goto edisclk;