mmc: mmci: Improve ux500 debug prints

mmc: mmci: Improve ux500 debug prints

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 <linus.walleij@linaro.org>
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 <ulf.hansson@linaro.org>