On Tue, 16 May 2023 at 22:45, Martin Blumenstingl
<martin.blumenstingl@xxxxxxxxxxxxxx> wrote:
>
> On Mon, May 15, 2023 at 11:44 AM Ulf Hansson <ulf.hansson@xxxxxxxxxx> wrote:
> [...]
> > > > 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?
> register 0x24 is ICTL (interrupt control) and 0x28 is ISTAT (interrupt status)
> ISTAT is all zeros and ICTL is 0x3067 which translates so:
> - BIT(0): RESP_OK
> - BIT(1): RESP_TIMEOUT
> - BIT(2): RESP_ERR_CRC
> - BIT(5): DATA_TIMEOUT
> - BIT(6): DATA_ERR_CRC
> - BIT(12): RXFIFO_FULL
> - BIT(13): TXFIFO_EMPTY
>
> I guess in this case BIT(1) RESP_TIMEOUT is the relevant one.
>
> register 0x04 is SEND and reads 0x4d which translates to:
> - CMD13
> - MMC_RSP_PRESENT (HAS_RESP, BIT(6))
> - no other flags (STOP, R1B, ...) are set
>
> Full register dump:
> # cat /sys/kernel/debug/regmap/c1108e00.mmc/registers
> 00: 00000900
> 04: 0000004d
> 08: e7ffe002
> 0c: 02f0003f
> 10: 0003f009
> 14: 03b81c00
> 18: 2c43bcf0
> 1c: e0000150
> 20: 00000000
> 24: 00003067
> 28: 00000000
> 2c: 00000000
> 30: 00000000
> 34: 00fe0cff
> 38: 0000100b
>
> In case you are curious, the driver is: drivers/mmc/host/meson-mx-sdhc-mmc.c
Thanks for sharing this data!
I assume the above registers indicate that we have sent the command
and are now waiting for an IRQ for a response/error, but we never
receive one.
To really figure out what is going on, I think we need to do some
additional low level debugging/testing.
I was looking at the commit message from e4bf1b0970ef ("mmc: host:
meson-mx-sdhc: new driver for the Amlogic Meson SDHC host"), which
indicates that the clock management is quite limited for this HW. For
example, the 51000000Hz isn't one of the supported frequencies. Could
that be the reason for the problem? Perhaps if we play with changing
the frequency to something that is considered supported - then can we
make this work?
Kind regards
Uffe
