[...]
> >>>
> >>> @@ -1298,6 +1310,10 @@ mmci_cmd_irq(struct mmci_host *host, struct mmc_command *cmd,
> >>> mmci_dma_error(host);
> >>>
> >>> mmci_stop_data(host);
> >>> + if (host->variant->cmdreg_stop && cmd->error) {
> >>> + mmci_stop_command(host);
> >>> + return;
> >>> + }
> >>
> >>> }
> >>
> >> In fact a cmd without host->data could fail with DPSM enabled.
> >> example:
> >> sent a cmd12 with MMC_RSP_BUSY flag (R1B command) and so no data.
> >> In sdmmc variant the MMCIDATATIMER is used to busy timeout.
> >> The DPSM is used to sample D0 line and is activated.
> >> the DTIMEOUT flag is set after when no end of busy received before the
> >> timeout. (DPSM stays in BUSY and wait for Abort)
> >
> > Oh, that I didn't know about! That make it quite complicated, I am afraid.
> >
> > To send a new CMD12 to clear the DPSM, because the previous CDM12
> > failed seems just wrong. Why would the second CMD12 succeed and not
> > timeout again, if you see what I mean.
> >
> > There are also other commands using R1B, that doesn't involve
> > transferring data. The CMD5 (sleep) for example. If any of these
> > commands would timeout, then why would a following CMD12 not do so as
> > well?
> >
> > To me, it seems like a reset of the controller is the only really sane
> > way of treating these scenarios, isn't it? Of course, it means we need
> > to be able to restore the state of the controller after such a reset
> > as well. Is this possible?
> >
>
> POV sdmmc hardware block the second cmd12 just allows to clear the DPSM
> (for stop abort cmd the R1B may not be set).
> I agree with you, if a command fail due to R1B (busy timeout) the better
> way is to reset the controller, protocol...
>
> Do to that we could call mmc_hw_reset function
> (drivers/mmc/core/core.c). However this function can't be call
> in irq context and ongoing request must be completed.
Actually, that is not really the purpose of that callback. That
callback is about resetting the card, however in some cases that may
involve some additional actions for the host.
>
> proposition:
> The host driver could set a error value (in cmd->error or data->error)
> like EDEADLK or ECONNRESET (to be defined)...
> The framework could check error value (for example in
> mmc_wait_for_req_done) and call mmc_hw_reset if needed.
Something along those lines sounds good to me, but I would rather add
a new separate callback, which main responsibility is to reset the
host HW.
>
> What do you think?
Well, even if the above sounds good and could benefit all hosts, the
suggestion/question I had earlier was more related to if you have a
special reset controller that can be used to reset the mmci IP!? We
have the drivers/reset/* subsystem that helps with these kind of
things.
In principle, if you have a reset controller, you should be able to
recover in the mmci driver, without having to involve the mmc core, if
you see what I mean.
[...]
Kind regards
Uffe
