> -----Original Message-----
> From: linux-mmc-owner@xxxxxxxxxxxxxxx <linux-mmc-owner@xxxxxxxxxxxxxxx>
> On Behalf Of Adrian Hunter
> Sent: Thursday, November 21, 2019 7:36 PM
> To: Y.b. Lu <yangbo.lu@xxxxxxx>; Ulf Hansson <ulf.hansson@xxxxxxxxxx>
> Cc: linux-mmc@xxxxxxxxxxxxxxx
> Subject: Re: [PATCH] mmc: sdhci: fix up CMD12 sending
>
> On 21/11/19 4:21 AM, Y.b. Lu wrote:
> > Hi,
> >
> >> -----Original Message-----
> >> From: Ulf Hansson <ulf.hansson@xxxxxxxxxx>
> >> Sent: Thursday, November 14, 2019 9:54 PM
> >> To: Y.b. Lu <yangbo.lu@xxxxxxx>
> >> Cc: linux-mmc@xxxxxxxxxxxxxxx; Adrian Hunter
> >> <adrian.hunter@xxxxxxxxx>
> >> Subject: Re: [PATCH] mmc: sdhci: fix up CMD12 sending
> >>
> >> On Thu, 14 Nov 2019 at 12:18, Yangbo Lu <yangbo.lu@xxxxxxx> wrote:
> >>>
> >>> The STOP command is disabled for multiple blocks r/w commands with
> >>> auto CMD12, when start to send. However, if there is data error,
> >>> software still needs to send CMD12 according to SD spec.
> >>> This patch is to allow software CMD12 sending for this case.
> >>>
> >>> Signed-off-by: Yangbo Lu <yangbo.lu@xxxxxxx>
> >>> ---
> >>> drivers/mmc/host/sdhci.c | 17 +++--------------
> >>> 1 file changed, 3 insertions(+), 14 deletions(-)
> >>>
> >>> diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
> >>> index
> >>> 09cdbe8..3041c39 100644
> >>> --- a/drivers/mmc/host/sdhci.c
> >>> +++ b/drivers/mmc/host/sdhci.c
> >>> @@ -1326,12 +1326,12 @@ static void sdhci_finish_data(struct
> >>> sdhci_host *host)
> >>>
> >>> /*
> >>> * Need to send CMD12 if -
> >>> - * a) open-ended multiblock transfer (no CMD23)
> >>> + * a) open-ended multiblock transfer not using auto CMD12
> >>> + (no
> >>> + CMD23)
> >>> * b) error in multiblock transfer
> >>> */
> >>> if (data->stop &&
> >>> - (data->error ||
> >>> - !data->mrq->sbc)) {
> >>> + ((!data->mrq->sbc && !sdhci_auto_cmd12(host, data->mrq))
> ||
> >>> + data->error)) {
> >>
> >> Per your other reply to this thread, I don't think there is any harm
> >> in always sending a CMD12 if there is an error, at least from the card's point
> of view.
> >>
> >> The worst thing that can happen is that there are two CMD12 sent to
> >> the card and I don't think that is a problem for the error path.
> >>
> >> My only concern, is to understand if $subject patch causes other
> >> changes in behaviours for the SDHCI driver. Let's see what Adrian thinks.
> >
> > [Y.b. Lu] Yes. The purpose is to avoid no CMD12 sent if get data error. That
> will makes block driver failed at block r/w recovery when sending CMD13 to
> get status.
> > Our platform on some boards at old kernel 4.14 seems to hit this case.
> >
> > Hi Adrian,
> > Could you help to review the changes?
>
> I don't think the auto-cmd12 error handling was ever done properly, so it will
> take we a while to review it.
[Y.b. Lu] Thanks Adrian.
I am confused where the initial error recovery should start for multi-block r/w (with AUTO CMD12) error.
I can see two places which may send CMD12.
1. In sdhci_finish_data(), as my patch changes, I think for data->error, the CMD12 should be sent.
2. In mmc_blk_mq_rw_recovery() in block.c, CMD13 will be sent with one more retry (retuning may happen), before CMD12.
And I doubt the recovery 1 if we can still use CC/TC/DTOE interrupts to check CMD12 success or not (or we should just poll DAT0), for data error in tuning mode.
Thanks.
