From: Jaehoon Chung <jh80.chung@samsung.com>
To: Doug Anderson <dianders@chromium.org>
Cc: Chris Ball <cjb@laptop.org>, Will Newton <will.newton@gmail.com>,
Seungwon Jeon <tgih.jun@samsung.com>,
Bing Zhao <bzhao@marvell.com>,
Jaehoon Chung <jh80.chung@samsung.com>,
Ashok Nagarajan <asnagarajan@chromium.org>,
Paul Stewart <pstew@chromium.org>,
Olof Johansson <olof@lixom.net>,
linux-mmc@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] RFC: mmc: dw_mmc: Always go to STATE_DATA_BUSY from STATE_DATA_ERROR
Date: Mon, 18 Mar 2013 19:21:36 +0900 [thread overview]
Message-ID: <5146EAB0.1030705@samsung.com> (raw)
In-Reply-To: <1363382956-14557-1-git-send-email-dianders@chromium.org>
Hi Doug,
Great..i have found the problem like this.
I will check your patch..and share the result.
Best Regards,
Jaehoon Chung
On 03/16/2013 06:29 AM, Doug Anderson wrote:
> On a flaky piece of hardware that seems good at generating CRC errors,
> we have found that often times the CRC errors don't get reported
> properly when using CONFIG_MMC_DW_IDMAC (they get reported OK when
> using pio).
>
> The flow that happens is:
> 1. dw_mci_interrupt() fires and status=80b8, pending=8088 so that
> we hit (pending & DW_MCI_DATA_ERROR_FLAGS). We store 8088 in
> data_status and set EVENT_DATA_ERROR in host->pending_events
> 2. We schedule the tasklet and it runs.
> 3. We're in STATE_SENDING_DATA in the tasklet and see
> EVENT_DATA_ERROR so we dw_mci_stop_dma().
> 4. dw_mci_stop_dma() calls dw_mci_idmac_stop_dma() and
> dw_mci_dma_cleanup(). These stop dma but _don't_ set
> EVENT_XFER_COMPLETE (since we're host->using_dma).
> 5. data->stop is NULL so we don't send a stop command.
> 6. We move onto STATE_DATA_ERROR and loop again in the tasklet.
> 7. We hit STATE_DATA_ERROR but the transfer isn't done, so the tasklet
> stops.
>
> We never seem to get any additional DMA interrupts that cause
> EVENT_XFER_COMPLETE and restart the tasklet so we just hang. That
> doesn't seem surprising given that we've stopped DMA.
>
> We did put a print at the end of dw_mci_interrupt() to show the result
> of the "mci_readl(host, IDSTS)" and saw 0xa000 in the case of the
> above CRC error.
>
> A proposed fix for this is to ignore (but still clear) the
> EVENT_XFER_COMPLETE in STATE_DATA_ERROR in the tasklet.
>
> Reported-by: Bing Zhao <bzhao@marvell.com>
> Signed-off-by: Doug Anderson <dianders@chromium.org>
> ---
> drivers/mmc/host/dw_mmc.c | 5 +----
> 1 file changed, 1 insertion(+), 4 deletions(-)
>
> diff --git a/drivers/mmc/host/dw_mmc.c b/drivers/mmc/host/dw_mmc.c
> index 9834221..696b3bb 100644
> --- a/drivers/mmc/host/dw_mmc.c
> +++ b/drivers/mmc/host/dw_mmc.c
> @@ -1137,10 +1137,7 @@ static void dw_mci_tasklet_func(unsigned long priv)
> goto unlock;
>
> case STATE_DATA_ERROR:
> - if (!test_and_clear_bit(EVENT_XFER_COMPLETE,
> - &host->pending_events))
> - break;
> -
> + clear_bit(EVENT_XFER_COMPLETE, &host->pending_events);
> state = STATE_DATA_BUSY;
> break;
> }
>
next prev parent reply other threads:[~2013-03-18 10:21 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-03-15 21:29 [PATCH] RFC: mmc: dw_mmc: Always go to STATE_DATA_BUSY from STATE_DATA_ERROR Doug Anderson
2013-03-18 10:21 ` Jaehoon Chung [this message]
2013-03-26 18:06 ` Doug Anderson
2013-04-05 8:18 ` Jaehoon Chung
2013-04-08 5:10 ` Jaehoon Chung
2013-04-08 12:17 ` Seungwon Jeon
2013-04-08 23:09 ` Doug Anderson
2013-04-10 7:02 ` Seungwon Jeon
2013-04-10 8:51 ` Jaehoon Chung
2013-06-12 19:06 ` Doug Anderson
2013-06-18 12:36 ` Seungwon Jeon
2013-06-18 19:46 ` Bing Zhao
2013-06-18 19:52 ` Doug Anderson
2013-06-18 20:01 ` Bing Zhao
2013-06-21 3:33 ` Doug Anderson
2013-06-25 3:54 ` Bing Zhao
2013-06-26 1:53 ` Seungwon Jeon
2013-06-27 3:36 ` Jaehoon Chung
2013-06-27 18:18 ` Bing Zhao
2013-06-20 1:49 ` Jaehoon Chung
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5146EAB0.1030705@samsung.com \
--to=jh80.chung@samsung.com \
--cc=asnagarajan@chromium.org \
--cc=bzhao@marvell.com \
--cc=cjb@laptop.org \
--cc=dianders@chromium.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mmc@vger.kernel.org \
--cc=olof@lixom.net \
--cc=pstew@chromium.org \
--cc=tgih.jun@samsung.com \
--cc=will.newton@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.