linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
* [PATCH] mmc: dw_mmc: rockchip: Add DW_MCI_QUIRK_RETRY_DELAY
@ 2015-01-13 17:51 Doug Anderson
  2015-02-25  0:21 ` Doug Anderson
  0 siblings, 1 reply; 2+ messages in thread
From: Doug Anderson @ 2015-01-13 17:51 UTC (permalink / raw)
  To: linux-arm-kernel

We've seen at least one card that can get confused during all the
errors generated during tuning on rk3288.  These errors seem to go
away with DW_MCI_QUIRK_RETRY_DELAY.  That quirk is documented to be
for 2.11a and on rk3288 I believe we have 2.70a, but it seems to be
the same type of problem.

Specifically it looks like in certain error conditions (I saw this
with Response CRC errors) that data keeps showing up in the FIFO even
after the error is reported and the CD (command done) bit is set.  If
we don't wait for this data to finish transferring then it confuses
the next transaction.  In the specific failure case I ran into I found
that I could monitor the data_state_mc_busy bit and wait for it to
clear, but in other failure cases this bit was stuck at busy when we
saw an error.  Hence a generic big delay seems like the only option.

I have seen this on rk3288, but adding it as a quirk for all Rockchip
IP for now since most previous quirks have shown up on older IP as
well.

Signed-off-by: Doug Anderson <dianders@chromium.org>
---
NOTES:
* This is based atop Addy's patch (mmc: dw_mmc: add quirk for broken
data transfer over scheme) at
<https://patchwork.kernel.org/patch/5565431/>, but it would be trivial
to apply this patch without that one if that were desirable.
* If someone has a better solution to this problem, I'm all ears.

 drivers/mmc/host/dw_mmc-rockchip.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/mmc/host/dw_mmc-rockchip.c b/drivers/mmc/host/dw_mmc-rockchip.c
index ba92ebd..b4caf1a 100644
--- a/drivers/mmc/host/dw_mmc-rockchip.c
+++ b/drivers/mmc/host/dw_mmc-rockchip.c
@@ -74,7 +74,8 @@ static int dw_mci_rockchip_init(struct dw_mci *host)
 	host->sdio_id0 = 8;
 
 	/* It needs this quirk on all Rockchip SoCs */
-	host->pdata->quirks |= DW_MCI_QUIRK_BROKEN_DTO;
+	host->pdata->quirks |= DW_MCI_QUIRK_BROKEN_DTO |
+		DW_MCI_QUIRK_RETRY_DELAY;
 
 	return 0;
 }
-- 
2.2.0.rc0.207.ga3a616c

^ permalink raw reply related	[flat|nested] 2+ messages in thread

* [PATCH] mmc: dw_mmc: rockchip: Add DW_MCI_QUIRK_RETRY_DELAY
  2015-01-13 17:51 [PATCH] mmc: dw_mmc: rockchip: Add DW_MCI_QUIRK_RETRY_DELAY Doug Anderson
@ 2015-02-25  0:21 ` Doug Anderson
  0 siblings, 0 replies; 2+ messages in thread
From: Doug Anderson @ 2015-02-25  0:21 UTC (permalink / raw)
  To: linux-arm-kernel

Hi,

On Tue, Jan 13, 2015 at 9:51 AM, Doug Anderson <dianders@chromium.org> wrote:
> We've seen at least one card that can get confused during all the
> errors generated during tuning on rk3288.  These errors seem to go
> away with DW_MCI_QUIRK_RETRY_DELAY.  That quirk is documented to be
> for 2.11a and on rk3288 I believe we have 2.70a, but it seems to be
> the same type of problem.
>
> Specifically it looks like in certain error conditions (I saw this
> with Response CRC errors) that data keeps showing up in the FIFO even
> after the error is reported and the CD (command done) bit is set.  If
> we don't wait for this data to finish transferring then it confuses
> the next transaction.  In the specific failure case I ran into I found
> that I could monitor the data_state_mc_busy bit and wait for it to
> clear, but in other failure cases this bit was stuck at busy when we
> saw an error.  Hence a generic big delay seems like the only option.
>
> I have seen this on rk3288, but adding it as a quirk for all Rockchip
> IP for now since most previous quirks have shown up on older IP as
> well.
>
> Signed-off-by: Doug Anderson <dianders@chromium.org>
> ---
> NOTES:
> * This is based atop Addy's patch (mmc: dw_mmc: add quirk for broken
> data transfer over scheme) at
> <https://patchwork.kernel.org/patch/5565431/>, but it would be trivial
> to apply this patch without that one if that were desirable.
> * If someone has a better solution to this problem, I'm all ears.
>
>  drivers/mmc/host/dw_mmc-rockchip.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/mmc/host/dw_mmc-rockchip.c b/drivers/mmc/host/dw_mmc-rockchip.c
> index ba92ebd..b4caf1a 100644
> --- a/drivers/mmc/host/dw_mmc-rockchip.c
> +++ b/drivers/mmc/host/dw_mmc-rockchip.c
> @@ -74,7 +74,8 @@ static int dw_mci_rockchip_init(struct dw_mci *host)
>         host->sdio_id0 = 8;
>
>         /* It needs this quirk on all Rockchip SoCs */
> -       host->pdata->quirks |= DW_MCI_QUIRK_BROKEN_DTO;
> +       host->pdata->quirks |= DW_MCI_QUIRK_BROKEN_DTO |
> +               DW_MCI_QUIRK_RETRY_DELAY;
>
>         return 0;
>  }

All of my recent testing shows that with all of the other fixes Addy
and I have posted recently that this one is no longer needed.  I think
it can be considered Abandoned.

-Doug

^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2015-02-25  0:21 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2015-01-13 17:51 [PATCH] mmc: dw_mmc: rockchip: Add DW_MCI_QUIRK_RETRY_DELAY Doug Anderson
2015-02-25  0:21 ` Doug Anderson

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).