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

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>

show more ...

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

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
sc

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

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 <linus.walleij@linaro.org>
Tested-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Link: https://lore.kernel.org/r/20230620091113.33393-1-ulf.hansson@linaro.org

show more ...

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

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 <yann.gautier@fos

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

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 <yann.gautier@foss.st.com>
Link: https://lore.kernel.org/r/20230619115120.64474-4-yann.gautier@foss.st.com
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>

show more ...

mmc: mmci: add stm32_idmabsize_align parameter

The alignment for the IDMA size depends on the peripheral version, it
should then be configurable. Add stm32_idmabsize_align in the variant
structure.

mmc: mmci: add stm32_idmabsize_align parameter

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 <yann.gautier@foss.st.com>
Link: https://lore.kernel.org/r/20230619115120.64474-3-yann.gautier@foss.st.com
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>

show more ...

mmc: mmci: Break out a helper function

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 hel

mmc: mmci: Break out a helper function

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 <linus.walleij@linaro.org>
Link: https://lore.kernel.org/r/20230405-pl180-busydetect-fix-v7-9-69a7164f2a61@linaro.org
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>

show more ...

mmc: mmci: Use a switch statement machine

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: Lin

mmc: mmci: Use a switch statement machine

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 <linus.walleij@linaro.org>
Link: https://lore.kernel.org/r/20230405-pl180-busydetect-fix-v7-8-69a7164f2a61@linaro.org
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>

show more ...

mmc: mmci: Use state machine state as exit condition

Return true if and only if we reached the state
MMCI_BUSY_DONE in the ux500 ->busy_complete() callback.

Signed-off-by: Linus Walleij <linus.wall

mmc: mmci: Use state machine state as exit condition

Return true if and only if we reached the state
MMCI_BUSY_DONE in the ux500 ->busy_complete() callback.

Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Link: https://lore.kernel.org/r/20230405-pl180-busydetect-fix-v7-7-69a7164f2a61@linaro.org
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>

show more ...

mmc: mmci: Retry the busy start condition

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

mmc: mmci: Retry the busy start condition

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 <linus.walleij@linaro.org>
Link: https://lore.kernel.org/r/20230405-pl180-busydetect-fix-v7-6-69a7164f2a61@linaro.org
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>

show more ...

mmc: mmci: Make busy complete state machine explicit

This refactors the ->busy_complete() callback currently
only used by Ux500 and STM32 to handle busy detection on
hardware where one and the same

mmc: mmci: Make busy complete state machine explicit

This refactors the ->busy_complete() callback currently
only used by Ux500 and STM32 to handle busy detection on
hardware where one and the same IRQ is fired whether we get
a start or an end signal on busy detect.

The code is currently using the cached status from the
command IRQ in ->busy_status as a state to select what to
do next: if this state is non-zero we are waiting for
IRQs and if it is zero we treat the state as the starting
point for a busy detect wait cycle.

Make this explicit by creating a state machine where the
->busy_complete callback moves between three states.

The Ux500 busy detect code currently assumes this order:
we enable the busy detect IRQ, get a busy start IRQ, then a
busy end IRQ, and then we clear and mask this IRQ and
proceed.

We insert debug prints for unexpected states.

This works as before on most cards, however on a
problematic card that is not working with busy detect, and
which I have been debugging, the following happens a lot:

[ 3.380554] mmci-pl18x 80005000.mmc: no busy signalling in time
[ 3.387420] mmci-pl18x 80005000.mmc: no busy signalling in time
[ 3.394561] mmci-pl18x 80005000.mmc: lost busy status
when waiting for busy start IRQ

This probably means that the busy detect start IRQ has
already occurred when we start executing the
->busy_complete() callbacks, and the busy detect end IRQ
is counted as the start IRQ, and this is what is causing
the card to not be detected properly.

Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Link: https://lore.kernel.org/r/20230405-pl180-busydetect-fix-v7-5-69a7164f2a61@linaro.org
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>

show more ...

mmc: mmci: Break out error check in busy detect

The busy detect callback for Ux500 checks for an error
in the status in the first if() clause. The only practical
reason is that if an error occurs, t

mmc: mmci: Break out error check in busy detect

The busy detect callback for Ux500 checks for an error
in the status in the first if() clause. The only practical
reason is that if an error occurs, the if()-clause is not
executed, and the code falls through to the last
if()-clause if (host->busy_status) which will clear and
disable the irq. Make this explicit instead: it is easier
to read.

Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Link: https://lore.kernel.org/r/20230405-pl180-busydetect-fix-v7-4-69a7164f2a61@linaro.org
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>

show more ...

mmc: mmci: Stash status while waiting for busy

Some interesting flags can arrive while we are waiting for
the first busy detect IRQ so OR then onto the stashed
flags so they are not missed.

Signed-

mmc: mmci: Stash status while waiting for busy

Some interesting flags can arrive while we are waiting for
the first busy detect IRQ so OR then onto the stashed
flags so they are not missed.

Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Link: https://lore.kernel.org/r/20230405-pl180-busydetect-fix-v7-3-69a7164f2a61@linaro.org
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>

show more ...

mmc: mmci: Unwind big if() clause

This does two things: firsr replace the hard-to-read long
if-expression:

if (!host->busy_status && !(status & err_msk) &&
(readl(base + MMCISTATUS) & host-

mmc: mmci: Unwind big if() clause

This does two things: firsr replace the hard-to-read long
if-expression:

if (!host->busy_status && !(status & err_msk) &&
(readl(base + MMCISTATUS) & host->variant->busy_detect_flag)) {

With the more readable:

if (!host->busy_status && !(status & err_msk)) {
status = readl(base + MMCISTATUS);
if (status & host->variant->busy_detect_flag) {

Second notice that the re-read MMCISTATUS register is now
stored into the status variable, using logic OR because what
if something else changed too?

While we are at it, explain what the function is doing.

Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Link: https://lore.kernel.org/r/20230405-pl180-busydetect-fix-v7-2-69a7164f2a61@linaro.org
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>

show more ...

mmc: mmci: Clear busy_status when starting command

If we are starting a command which can generate a busy
response, then clear the variable host->busy_status
if the variant is using a ->busy_complet

mmc: mmci: Clear busy_status when starting command

If we are starting a command which can generate a busy
response, then clear the variable host->busy_status
if the variant is using a ->busy_complete callback.

We are lucky that the member is zero by default and
hopefully always gets cleared in the ->busy_complete
callback even on errors, but it's just fragile so
make sure it is always initialized to zero.

Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Link: https://lore.kernel.org/r/20230405-pl180-busydetect-fix-v7-1-69a7164f2a61@linaro.org
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>

show more ...

mmc: mmci: stm32: fix max busy timeout calculation

The way that the timeout is currently calculated could lead to a u64
timeout value in mmci_start_command(). This value is then cast in a u32
regist

mmc: mmci: stm32: fix max busy timeout calculation

The way that the timeout is currently calculated could lead to a u64
timeout value in mmci_start_command(). This value is then cast in a u32
register that leads to mmc erase failed issue with some SD cards.

Fixes: 8266c585f489 ("mmc: mmci: add hardware busy timeout feature")
Signed-off-by: Yann Gautier <yann.gautier@foss.st.com>
Signed-off-by: Christophe Kerello <christophe.kerello@foss.st.com>
Cc: stable@vger.kernel.org
Link: https://lore.kernel.org/r/20230613134146.418016-1-yann.gautier@foss.st.com
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>

show more ...

mmc: mmci: Set PROBE_PREFER_ASYNCHRONOUS

All mmc host drivers should have the asynchronous probe option enabled, but
it seems like we failed to set it for mmci, so let's do that now.

Fixes: 21b2cec

mmc: mmci: Set PROBE_PREFER_ASYNCHRONOUS

All mmc host drivers should have the asynchronous probe option enabled, but
it seems like we failed to set it for mmci, so let's do that now.

Fixes: 21b2cec61c04 ("mmc: Set PROBE_PREFER_ASYNCHRONOUS for drivers that existed in v4.4")
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Tested-by: Linus Walleij <linus.walleij@linaro.org>
Tested-by: Yann Gautier <yann.gautier@foss.st.com>
Cc: stable@vger.kernel.org
Link: https://lore.kernel.org/r/20230612143730.210390-1-ulf.hansson@linaro.org

show more ...

mmc: Use of_property_read_bool() for boolean properties

It is preferred to use typed property access functions (i.e.
of_property_read_<type> functions) rather than low-level
of_get_property/of_find_

mmc: Use of_property_read_bool() for boolean properties

It is preferred to use typed property access functions (i.e.
of_property_read_<type> functions) rather than low-level
of_get_property/of_find_property functions for reading properties.
Convert reading boolean properties to to of_property_read_bool().

Signed-off-by: Rob Herring <robh@kernel.org>
Link: https://lore.kernel.org/r/20230310144715.1543836-1-robh@kernel.org
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>

show more ...

mmc: mmci: fix return value check of mmc_add_host()

mmc_add_host() may return error, if we ignore its return value,
it will lead two issues:
1. The memory that allocated in mmc_alloc_host() is leake

mmc: mmci: fix return value check of mmc_add_host()

mmc_add_host() may return error, if we ignore its return value,
it will lead two issues:
1. The memory that allocated in mmc_alloc_host() is leaked.
2. In the remove() path, mmc_remove_host() will be called to
delete device, but it's not added yet, it will lead a kernel
crash because of null-ptr-deref in device_del().

So fix this by checking the return value and goto error path which
will call mmc_free_host().

Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
Signed-off-by: Yang Yingliang <yangyingliang@huawei.com>
Link: https://lore.kernel.org/r/20221109133539.3275664-1-yangyingliang@huawei.com
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>

show more ...

mmc: mmci: Fix typo in comment

Delete the redundant word 'is'.

Signed-off-by: Xiang wangx <wangxiang@cdjrlc.com>
Link: https://lore.kernel.org/r/20220608130847.46359-1-wangxiang@cdjrlc.com
Signed-o

mmc: mmci: Fix typo in comment

Delete the redundant word 'is'.

Signed-off-by: Xiang wangx <wangxiang@cdjrlc.com>
Link: https://lore.kernel.org/r/20220608130847.46359-1-wangxiang@cdjrlc.com
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>

show more ...

mmc: mmci: Remove custom ios handler

The custom boardfile ios handler isn't used anywhere in the
kernel. Delete it.

Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Link: https://lore.kernel

mmc: mmci: Remove custom ios handler

The custom boardfile ios handler isn't used anywhere in the
kernel. Delete it.

Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Link: https://lore.kernel.org/r/20220427125557.1608825-1-linus.walleij@linaro.org
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>

show more ...

mmc: mmci: Break IRQ status loop when all zero

We iterate an extra time through the IRQ status handling
loop despite nothing had fired. Enabling the debug prints:

mmci-pl18x 80005000.mmc: op 01 arg

mmc: mmci: Break IRQ status loop when all zero

We iterate an extra time through the IRQ status handling
loop despite nothing had fired. Enabling the debug prints:

mmci-pl18x 80005000.mmc: op 01 arg 00000000 flags 000000e1
mmci-pl18x 80005000.mmc: irq0 (data+cmd) 00000001
mmci-pl18x 80005000.mmc: irq0 (data+cmd) 00000000
mmci-pl18x 80005000.mmc: op 01 arg 40ff8080 flags 000000e1
mmci-pl18x 80005000.mmc: irq0 (data+cmd) 00000001
mmci-pl18x 80005000.mmc: irq0 (data+cmd) 00000000

It is pointless to loop through the function when status
is zero. Just break the loop if the status is zero.

Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Link: https://lore.kernel.org/r/20220416224549.627623-1-linus.walleij@linaro.org
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>

show more ...

mmc: mmci: increase stm32 sdmmcv2 clock max freq

The variant->f_max is dependent on the IP, not on the SoC where it is
embedded. Set the max frequency of its source clock to 267MHz.
The frequency us

mmc: mmci: increase stm32 sdmmcv2 clock max freq

The variant->f_max is dependent on the IP, not on the SoC where it is
embedded. Set the max frequency of its source clock to 267MHz.
The frequency used will be limited by the IOs max frequency, set in the
SoC device tree.

Signed-off-by: Yann Gautier <yann.gautier@foss.st.com>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Link: https://lore.kernel.org/r/20211215141727.4901-3-yann.gautier@foss.st.com
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>

show more ...

mmc: mmci: Add support for sdmmc variant revision v2.2

The change is only hardware, and does not need driver change:
Added hardware flow control during transmit packet with variable delay.
The new i

mmc: mmci: Add support for sdmmc variant revision v2.2

The change is only hardware, and does not need driver change:
Added hardware flow control during transmit packet with variable delay.
The new id is then added to the ids list structure.

Signed-off-by: Yann Gautier <yann.gautier@foss.st.com>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Link: https://lore.kernel.org/r/20211215141727.4901-2-yann.gautier@foss.st.com
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>

show more ...

mmc: mmci: Add small comment about reset thread

Put a small comment before assigning IRQ_WAKE_THREAD
telling us what is going on.

Cc: Russell King <linux@armlinux.org.uk>
Cc: Yann Gautier <yann.gau

mmc: mmci: Add small comment about reset thread

Put a small comment before assigning IRQ_WAKE_THREAD
telling us what is going on.

Cc: Russell King <linux@armlinux.org.uk>
Cc: Yann Gautier <yann.gautier@foss.st.com>
Cc: Ludovic Barre <ludovic.barre@st.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Link: https://lore.kernel.org/r/20210921143359.1738149-1-linus.walleij@linaro.org
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>

show more ...

mmc: mmci: De-assert reset on probe

If we find a reset handle when probing the MMCI block,
make sure the reset is de-asserted. It could happen that
a hardware has reset asserted at boot.

Cc: Russel

mmc: mmci: De-assert reset on probe

If we find a reset handle when probing the MMCI block,
make sure the reset is de-asserted. It could happen that
a hardware has reset asserted at boot.

Cc: Russell King <linux@armlinux.org.uk>
Cc: Yann Gautier <yann.gautier@foss.st.com>
Cc: Ludovic Barre <ludovic.barre@st.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Tested-by: Yann Gautier <yann.gautier@foss.st.com>
Link: https://lore.kernel.org/r/20210630102408.3543024-1-linus.walleij@linaro.org
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>

show more ...

mmc: mmci: Add MMC_CAP_NEED_RSP_BUSY for the stm32 variants

An issue has been observed on STM32MP157C-EV1 board, with an erase command
with secure erase argument, ending up waiting for ~4 hours befo

mmc: mmci: Add MMC_CAP_NEED_RSP_BUSY for the stm32 variants

An issue has been observed on STM32MP157C-EV1 board, with an erase command
with secure erase argument, ending up waiting for ~4 hours before timeout.

The requested busy timeout from the mmc core ends up with 14784000ms (~4
hours), but the supported host->max_busy_timeout is 86767ms, which leads to
that the core switch to use an R1 response in favor of the R1B and polls
for busy with the host->card_busy() ops. In this case the polling doesn't
work as expected, as we never detects that the card stops signaling busy,
which leads to the following message:

mmc1: Card stuck being busy! __mmc_poll_for_busy

The problem boils done to that the stm32 variants can't use R1 responses in
favor of R1B responses, as it leads to an internal state machine in the
controller to get stuck. To continue to process requests, it would need to
be reset.

To fix this problem, let's set MMC_CAP_NEED_RSP_BUSY for the stm32 variant,
which prevent the mmc core from switching to R1 responses. Additionally,
let's cap the cmd->busy_timeout to the host->max_busy_timeout, thus rely on
86767ms to be sufficient (~66 seconds was need for this test case).

Fixes: 94fe2580a2f3 ("mmc: core: Enable erase/discard/trim support for all mmc hosts")
Signed-off-by: Yann Gautier <yann.gautier@foss.st.com>
Link: https://lore.kernel.org/r/20210225145454.12780-1-yann.gautier@foss.st.com
Cc: stable@vger.kernel.org
[Ulf: Simplified the code and extended the commit message]
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>

show more ...