Odroid-C1 regression with commit 4bc31edebde5 ("mmc: core: Set HS clock speed before sending HS CMD13")

[Ulf Hansson]

On Sun, 14 May 2023 at 22:42, Martin Blumenstingl
<martin.blumenstingl at googlemail.com> wrote:
>
> Hi Ulf,
>
> On Thu, May 11, 2023 at 12:43 PM Ulf Hansson <ulf.hansson at linaro.org> 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