kernel/drivers/mmc/host/mmci.c, branch linux-6.9.y

mmc: mmci: stm32: add SDIO in-band interrupt mode

2023-12-07T13:08:44Z

Add the support of SDIO in-band interrupt mode for STM32 and Ux500 variants. It allows the SD I/O card to interrupt the host on SDMMC_D1 data line. It is not enabled by default on Ux500 variant as this is unstable and Ux500 users should use out-of-band IRQs. Signed-off-by: Christophe Kerello Signed-off-by: Yann Gautier Reviewed-by: Linus Walleij Link: https://lore.kernel.org/r/20231108141637.119497-1-yann.gautier@foss.st.com Signed-off-by: Ulf Hansson

mmc: mmci: use peripheral flow control for STM32

2023-10-10T11:35:31Z

The STM32 SDMMC peripheral (at least for the STM32F429, STM32F469 and STM32F746, which are all the currently supported devices using periphid 0x00880180) requires DMA to be performed in peripheral flow controller mode. From the STM32F74/5 reference manual, section 35.3.2: "SDMMC host allows only to use the DMA in peripheral flow controller mode. DMA stream used to serve SDMMC must be configured in peripheral flow controller mode" This patch adds a variant option to control peripheral flow control and enables it for the STM32 variant. Signed-off-by: Ben Wolsieffer Reviewed-by: Linus Walleij Link: https://lore.kernel.org/r/20230928135644.1489691-1-ben.wolsieffer@hefring.com Signed-off-by: Ulf Hansson

mmc: mmci: Improve ux500 debug prints

2023-08-09T11:21:47Z

To conclude the ux500 busy timeout fixes, this improves the debug and error prints so we can see a bit what is going on. Here is a typical dmesg with these new debug messages enabled: [ 2.648864] mmci-pl18x 80005000.mmc: mmc2: PL180 manf 80 rev4 at 0x80005000 irq 81,0 (pio) [ 2.662750] mmci-pl18x 80005000.mmc: DMA channels RX dma0chan4, TX dma0chan5 [ 3.480407] mmci-pl18x 80005000.mmc: no busy signalling in time CMD06 [ 3.487457] mmci-pl18x 80005000.mmc: no busy signalling in time CMD06 [ 3.998321] mmci-pl18x 80005000.mmc: timeout in state waiting for end IRQ waiting for busy CMD06 [ 3.998535] mmc2: new DDR MMC card at address 0001 [ 4.000030] mmcblk2: mmc2:0001 M4G1YC 3.69 GiB [ 4.008361] mmcblk2: p1 p2 p3 p4 p5 p6 p7 p8 p9 p10 p11 p12 p13 p14 p15 p16 p17 p18 p19 p20 p21 p22 p23 p24 p25 [ 4.017700] mmcblk2boot0: mmc2:0001 M4G1YC 2.00 MiB [ 4.020477] mmcblk2boot1: mmc2:0001 M4G1YC 2.00 MiB [ 4.022125] mmcblk2rpmb: mmc2:0001 M4G1YC 128 KiB, chardev (246:0) [ 5.791381] mmci-pl18x 80005000.mmc: no busy signalling in time CMD06 [ 10.938568] mmci-pl18x 80005000.mmc: timeout in state waiting for end IRQ waiting for busy CMD06 [ 17.982849] mmci-pl18x 80005000.mmc: lost busy status when waiting for busy start IRQ CMD06 [ 18.683563] mmci-pl18x 80005000.mmc: no busy signalling in time CMD06 [ 19.385437] mmci-pl18x 80005000.mmc: no busy signalling in time CMD06 [ 20.493652] mmci-pl18x 80005000.mmc: no busy signalling in time CMD06 We see a lot of lost IRQs and the timeout always occur while waiting for the end IRQ, and then the busy status is *low* meaning the busy indication is already de-asserted. So busy signalling is missed in various ways for various reasons, sometimes it appears that IRQs are simply lost. One hypothesis is that this happens because the events happen so fast that they are transient, and since the MMCI state machine in effect is handling an edge trigger (rising or falling signal on DAT0) the internal logic will miss the event, because the state machine in the hardware is sampling the line, and will at times detect only the first event but miss the second, fireing only one IRQ. We print the second timeout error with dev_err() since it is pretty serious, the other events are so common and simple to handle that we can keep them at dev_dbg() level. Signed-off-by: Linus Walleij Link: https://lore.kernel.org/r/20230628191243.3632401-1-linus.walleij@linaro.org [Ulf: Fixup conflict in ux500_busy_timeout_work()] Signed-off-by: Ulf Hansson

mmc: mmci: Add support for SW busy-end timeouts

2023-06-22T09:06:37Z

The ux500 variant doesn't have a HW based timeout to use for busy-end IRQs. To avoid hanging and waiting for the card to stop signaling busy, let's schedule a delayed work, according to the corresponding cmd->busy_timeout for the command. If the work gets to run, let's kick the IRQ handler to complete the currently running request/command. Reviewed-by: Linus Walleij Tested-by: Linus Walleij Signed-off-by: Ulf Hansson Link: https://lore.kernel.org/r/20230620091113.33393-1-ulf.hansson@linaro.org

mmc: mmci: Add support for sdmmc variant revision v3.0

2023-06-20T09:44:40Z

This is an update of the SDMMC revision v2.2, with just an increased FIFO size, from 64B to 1kB. Signed-off-by: Yann Gautier Link: https://lore.kernel.org/r/20230619115120.64474-4-yann.gautier@foss.st.com Signed-off-by: Ulf Hansson

mmc: mmci: add stm32_idmabsize_align parameter

2023-06-20T09:44:40Z

The alignment for the IDMA size depends on the peripheral version, it should then be configurable. Add stm32_idmabsize_align in the variant structure. And remove now unused (and wrong) MMCI_STM32_IDMABNDT_* macros. Signed-off-by: Yann Gautier Link: https://lore.kernel.org/r/20230619115120.64474-3-yann.gautier@foss.st.com Signed-off-by: Ulf Hansson

mmc: mmci: Break out a helper function

2023-06-19T11:14:26Z

These four lines clearing, masking and resetting the state of the busy detect state machine is repeated five times in the code so break this out to a small helper so things are easier to read. Signed-off-by: Linus Walleij Link: https://lore.kernel.org/r/20230405-pl180-busydetect-fix-v7-9-69a7164f2a61@linaro.org Signed-off-by: Ulf Hansson

mmc: mmci: Use a switch statement machine

2023-06-19T11:14:26Z

As is custom, use a big switch statement to transition between the edges of the state machine inside the ux500 ->busy_complete callback. Signed-off-by: Linus Walleij Link: https://lore.kernel.org/r/20230405-pl180-busydetect-fix-v7-8-69a7164f2a61@linaro.org Signed-off-by: Ulf Hansson

mmc: mmci: Use state machine state as exit condition

2023-06-19T11:14:26Z

Return true if and only if we reached the state MMCI_BUSY_DONE in the ux500 ->busy_complete() callback. Signed-off-by: Linus Walleij Link: https://lore.kernel.org/r/20230405-pl180-busydetect-fix-v7-7-69a7164f2a61@linaro.org Signed-off-by: Ulf Hansson

mmc: mmci: Retry the busy start condition

2023-06-19T11:14:26Z

This makes the ux500 ->busy_complete() callback re-read the status register 10 times while waiting for the busy signal to assert in the status register. If this does not happen, we bail out regarding the command completed already, i.e. before we managed to start to check the busy status. There is a comment in the code about this, let's just implement it to be certain that we can catch this glitch if it happens. Signed-off-by: Linus Walleij Link: https://lore.kernel.org/r/20230405-pl180-busydetect-fix-v7-6-69a7164f2a61@linaro.org Signed-off-by: Ulf Hansson