Hi Wolfram, On Wed, May 20, 2020 at 8:19 PM Geert Uytterhoeven <geert@xxxxxxxxxxxxxx> wrote: > On Wed, May 20, 2020 at 5:49 PM Wolfram Sang > <wsa+renesas@xxxxxxxxxxxxxxxxxxxx> wrote: > > On Wed, May 20, 2020 at 04:30:33PM +0200, Geert Uytterhoeven wrote: > > > On Tue, May 19, 2020 at 5:24 PM Ulf Hansson <ulf.hansson@xxxxxxxxxx> wrote: > > > > Before calling tmio_mmc_host_probe(), the caller is required to enable > > > > clocks for its device, as to make it accessible when reading/writing > > > > registers during probe. > > > > > > > > Therefore, the responsibility to disable these clocks, in the error path of > > > > ->probe() and during ->remove(), is better managed outside > > > > tmio_mmc_host_remove(). As a matter of fact, callers of > > > > tmio_mmc_host_remove() already expects this to be the behaviour. > > > > > > > > However, there's a problem with tmio_mmc_host_remove() when the Kconfig > > > > option, CONFIG_PM, is set. More precisely, tmio_mmc_host_remove() may then > > > > disable the clock via runtime PM, which leads to clock enable/disable > > > > imbalance problems, when the caller of tmio_mmc_host_remove() also tries to > > > > disable the same clocks. > > > > > > > > To solve the problem, let's make sure tmio_mmc_host_remove() leaves the > > > > device with clocks enabled, but also make sure to disable the IRQs, as we > > > > normally do at ->runtime_suspend(). > > > > > > > > Reported-by: Geert Uytterhoeven <geert+renesas@xxxxxxxxx> > > > > Reviewed-by: Wolfram Sang <wsa+renesas@xxxxxxxxxxxxxxxxxxxx> > > > > Tested-by: Wolfram Sang <wsa+renesas@xxxxxxxxxxxxxxxxxxxx> > > > > Signed-off-by: Ulf Hansson <ulf.hansson@xxxxxxxxxx> > > > > > > Tested-by: Geert Uytterhoeven <geert+renesas@xxxxxxxxx> > > > > > > (on R-Car Gen2, various Gen3, SH-Mobile AG5, R-Mobile A1, R-Mobile APE6, > > > RZ/A1, and RZ/A2) > > > > Thanks, Geert! If it is not too much to ask, could you try re-applying > > commit 7a7dab237027 ("mmc: tmio: remove workaround for NON_REMOVABLE") > > on top of all these patches and see if your NFS is still stalled? > > > > Sidenote: we still need to tackle the problem when SCC hangs because it > > has no clock. However, I am still interested if all the PM updates have > > an impact in the beaviour you observed here[1]. > > > > [1] https://patchwork.kernel.org/patch/11149285/ > > I reverted "[PATCH] WIP: clk: renesas: rcar-gen3: enable SDnH clk for HS > modes" (which I still had applied in my local tree), and reapplied "mmc: > tmio: remove workaround for NON_REMOVABLE", but I cannot reproduce the > issue, with or without the top 3 commits on mmc/next: > ff5a1a63febb0761 mmc: tmio: Further fixup runtime PM management at remove > 774c44ceff3c5b3f mmc: tmio: Make sure the PM domain is 'started' while probing > 4863bb62a87786ec mmc: renesas_sdhi: remove manual clk handling > > Let's see if I can bisect where it was fixed... Commit 9b0d6855e756b60d ("mmc: renesas_sdhi: enforce manual correction for Gen3") fixed it. However, there must be other later changes that have impact, as reverting 9b0d6855e756b60d and reapplying 7a7dab237027 on both mmc/next~3 and mmc/next gives a working system. Let's call it a day, no more bisecting today... Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@xxxxxxxxxxxxxx In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds