On Sun, 14 May 2023 at 22:42, Martin Blumenstingl <martin.blumenstingl@xxxxxxxxxxxxxx> wrote: > > Hi Ulf, > > On Thu, May 11, 2023 at 12:43 PM Ulf Hansson <ulf.hansson@xxxxxxxxxx> wrote: > [...] > > > Indeed, removing mmc_set_clock() from mmc_select_hs200() also makes my > > > eMMC appear again on top of Linux 6.4-rc1. > > > See the attached diff in case it's not fully clear which > > > mmc_set_clock() call I removed. > > > > Thanks for the update! Removing that call restores mmc_select_hs200() > > to the previous behaviour - so thanks for confirming that this is > > working. > > > > However, to find the proper solution, I think we need to understand > > why we are hanging in the meson-mx-sdhc driver first. Here's a couple > > of follow up questions from me: > > > > 1) Before calling mmc_set_clock() what is the actual clock rate that > > has been set by the meson driver? > > > > 2) Does the call to mmc_set_clock() return or hang? Can we verify that > > the clock gets set correctly? > I used the attached diff to answer these two questions. See the > following log extract (full log is attached): > meson-mx-sdhc c1108e00.mmc: Trying to set MMC clock to 400000Hz > meson-mx-sdhc c1108e00.mmc: Actual MMC clock to 399812Hz > mmc1: mmc_select_hs200 switching to clock from card->ext_csd.hs_max_dtr... > meson-mx-sdhc c1108e00.mmc: Trying to set MMC clock to 52000000Hz > meson-mx-sdhc c1108e00.mmc: Actual MMC clock to 51000000Hz > mmc1: mmc_select_hs200 mmc_set_clock returned > > > 3) If 2) seems to work above, we need to figure out why > > mmc_switch_status() is hanging. If there is a problem with the eMMC > > card responding in-correctly, the host driver should return with an > > error code, right? > You're right: it's indeed hanging in mmc_switch_status() > I don't get any interrupts (timeout, CRC error, ...) for it. > Do you have any suggestions what to check next? So the mmc_switch_status() is sending a CMD13. Even if the card doesn't reply, I would expect that the meson mmc controller would raise some kind of error condition, probably via a timeout-irq. Did you verify that the driver is actually waiting for an IRQ to happen, which also means waiting for a CMD13 response? Kind regards Uffe
