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 Best regards, Martin
