Re: [PATCH] mmc_core: fix data timeout for SEND_EXT_CSD

[Adrian Hunter]

ext Pierre Ossman wrote:
> On Wed, 11 Feb 2009 16:49:59 +0200
> Adrian Hunter <ext-adrian.hunter@xxxxxxxxx> wrote:
>
> > Commit 0d3e0460f307e84904968aad6cff97bd688583d8
> > "MMC: CSD and CID timeout values" inadvertently broke
> > the timeout for the MMC command SEND_EXT_CSD.
> >
> > This patch puts it back again.
> >
> > Signed-off-by: Adrian Hunter <ext-adrian.hunter@xxxxxxxxx>
> > ---
> >  drivers/mmc/core/mmc_ops.c |   16 ++++++++++------
> >  1 files changed, 10 insertions(+), 6 deletions(-)
> >
> > diff --git a/drivers/mmc/core/mmc_ops.c b/drivers/mmc/core/mmc_ops.c
> > index 9c50e6f..418a270 100644
> > --- a/drivers/mmc/core/mmc_ops.c
> > +++ b/drivers/mmc/core/mmc_ops.c
> > @@ -248,12 +248,16 @@ mmc_send_cxd_data(struct mmc_card *card, struct mmc_host *host,
> >
> >       sg_init_one(&sg, data_buf, len);
> >
> > -     /*
> > -      * The spec states that CSR and CID accesses have a timeout
> > -      * of 64 clock cycles.
> > -      */
> > -     data.timeout_ns = 0;
> > -     data.timeout_clks = 64;
> > +     if (!mmc_host_is_spi(host) && opcode == MMC_SEND_EXT_CSD)
> > +             mmc_set_data_timeout(&data, card);
> > +     else {
> > +             /*
> > +              * The spec states that CSR and CID accesses have a timeout
> > +              * of 64 clock cycles (8 for SPI).
> > +              */
> > +             data.timeout_ns = 0;
> > +             data.timeout_clks = 64;
> > +     }
> >
> >       mmc_wait_for_req(host, &mrq);
>
> I'm confused. Where did the 64 come from in the first place? That
> function will not be called for CID/CSD when !SPI. So the way I see it
> the code should be:
>
> if ((opcode == MMC_SEND_CSD) || (opcode == (MMC_SEND_CID)) {
>         data.timeout_ns = 0;
>         data.timeout_clks = 8;
> } else {
>         mmc_set_data_timeout(&data, card);
> }

Theoretically yes, it should be 8 not 64 - if all the SPI devices obey
the standard.  As I do not have an SPI device I did not feel comfortable
changing it.  Also 64 clocks is not a long time anyway, so it did not
seem to do any harm.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/