[...]
> >>> /*
> >>> - * 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. To keep track of having a
> >>> + * command in-progress, waiting for busy signaling to end,
> >>> + * store the status in host->busy_status.
> >>> + *
> >>> + * Note that, the card may need a couple of clock cycles before
> >>> + * it starts signaling busy on DAT0, hence re-read the
> >>> + * MMCISTATUS register here, to allow the busy bit to be set.
> >>> + * Potentially we may even need to poll the register for a
> >>> + * while, to allow it to be set, but tests indicates that it
> >>> + * isn't needed.
> >>> */
> >>> if (!host->busy_status &&
> >>> !(status & (MCI_CMDCRCFAIL|MCI_CMDTIMEOUT)) &&
> >>> (readl(base + MMCISTATUS) & host->variant->busy_detect_flag)) {
> >>>
> >>> - /* Clear the busy start IRQ */
> >>> - writel(host->variant->busy_detect_mask,
> >>> - host->base + MMCICLEAR);
> >> Why not clearing busy start event as soon as possible ? Maybe I am wrong
> >> but as far as I understand,
> >> we shall (always) enter that if condition before the one just above ?
> > Two things feel wrong about by clearing the IRQ here.
> >
> > 1) We have not yet unmasked the busy end IRQ and we don't have a bit
> > in the IRQ mask for the busy *start* IRQ (they are the same). Then we
> > are clearing an IRQ that we have not yet unmasked to receive, which
> > seems odd/wrong to me.
> > 2) Even if we clear it here, we are still receiving the busy start
> > IRQ, as described in my comment above.
>
> Ok, that makes sense ;)
>
> I guess what can be a bit confusing is that we have to unmask busy end
> irq before clearing busy start event.
> To better understand the sequence, purely for cosmetic, I wonder whether
> we shall not move that if condition before the first one where we clear
> the busy start event.
That is definitely a good idea, it should improve the understand of
the code/sequence. Let me re-spin a v3.
[...]
Kind regards
Uffe
