> On 05/19/2021 4:25 PM Wolfram Sang <wsa@xxxxxxxxxx> 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@xxxxxxxx>
>
> 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
