Hello Ulf, all,
For testing purpose, I cherry-picked your patch on top of a 4.19.30 basis.
(I apologize as it's a bit old. I miss time to do a rebase on current
linux-next right now.)
Unfortunately, I got a kernel crash applying it :(
As you may know, ST sta1295/sta1385 SoC embeds the same pl08x variant
than one in U8500.
So It looks like double-checking again mmci status to make sure busy
flag is still set
just before proceeding for busy end is required in our case.
Regards.
Jean-Nicolas.
On 7/15/19 6:42 PM, Ulf Hansson wrote:
> The MMCISTATUS register is read from the IRQ handler, mmci_irq(). For
> processing, its value is then passed as an in-parameter to mmci_cmd_irq().
>
> When dealing with busy detection, the MMCISTATUS register is being re-read,
> as to retrieve an updated value. However, this operation is likely costing
> more than it benefits, as the value was read only a few cycles ago. For
> this reason, let's simply drop the re-read and use the value from the
> in-parameter instead.
>
> Signed-off-by: Ulf Hansson <ulf.hansson@xxxxxxxxxx>
> ---
> drivers/mmc/host/mmci.c | 8 +++-----
> 1 file changed, 3 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/mmc/host/mmci.c b/drivers/mmc/host/mmci.c
> index 356833a606d5..5f35afc4dbf9 100644
> --- a/drivers/mmc/host/mmci.c
> +++ b/drivers/mmc/host/mmci.c
> @@ -1233,14 +1233,12 @@ mmci_cmd_irq(struct mmci_host *host, struct mmc_command *cmd,
> return;
>
> /*
> - * We were not busy, but we now got a busy response on
> - * something that was not an error, and we double-check
> - * that the special busy status bit is still set before
> - * proceeding.
> + * Before unmasking for the busy end IRQ, confirm that the
> + * command was sent successfully.
> */
> if (!host->busy_status &&
> !(status & (MCI_CMDCRCFAIL|MCI_CMDTIMEOUT)) &&
> - (readl(base + MMCISTATUS) & host->variant->busy_detect_flag)) {
> + (status & host->variant->busy_detect_flag)) {
>
> /* Clear the busy start IRQ */
> writel(host->variant->busy_detect_mask,
