Fix problem with A-Data 2GB microSD card - Revisited

Sean McNeil sean at mcneil.com
Sun May 11 10:00:21 CEST 2008


Andy Green wrote:
> Somebody in the thread at some point said:
> | Andy Green wrote:
> |> Somebody in the thread at some point said:
> |>
> |> |> I like the look of what this patch is doing, but do we really 
> need to
> |> |> limit ALL cards to ~10MHz instead of current 16MHz?  If the card
> |> itself
> |> |> can't handle 16MHz it should report that and the mmc layer will 
> limit
> |> |> what it asks for.  Or is this some signal quality issue for us,
> |> that the
> |> |> card can handle higher rates but not with our signals?
> |> |>
> |> | That is what I thought - that the mmc layer should be getting 
> something
> |> | that says what the card can do. I'm guessing these card say they are
> |> | high speed but are not. Or something like that. The card can 
> handle the
> |> | 16MHz rate when talking to the lower 1GB of data, so there is 
> something
> |> | odd here.
> |>
> |> Ah the timeout is measured in card clocks -- when you decrease card
> |> clock rate, you increase the absolute timeout.  If one of the NANDs in
> |> the card is slower about fetching data, it can make this situation.
> |>
> |> Try munging this
> |>
> |>     /* enforce timeout */
> |>     if (cmd->data) {
> |>         if (cmd->data->timeout_clks)
> |>             writew_dly(cmd->data->timeout_clks >> 4, /* / 16 clks */
> |>                     host->base + GLAMO_REG_MMC_TIMEOUT);
> |>         else
> |>             writew_dly(0xfff, host->base + GLAMO_REG_MMC_TIMEOUT);
> |>     } else
> |>         writew(0xfff, host->base + GLAMO_REG_MMC_TIMEOUT);
> |>
> |> into just
> |>
> |>     writew(0xfff, host->base + GLAMO_REG_MMC_TIMEOUT);
> |>
> |> to max out all timeouts.
> |>
> | This didn't help. with a 3 divisor on f_max I still get a status of
> |
> | 0x8310
>
> Hum.  A way to explain this is simply that the max timeout the Glamo can
> ~ handle is less than the time taken for the second 1GB of your card to
> deliver data, when the timeout is counted with a period of <100ns.
>
> What happens if we ignore the timeout bit if DRDY is set?  Normally
> timeout is just a way to stop waiting when a transfer is not happening
> or something fatal happened to the card in the meanwhile.  If data does
> come ready, we can just use it despite it took longer than the timeout.
I've tried that. I end up with corrupted data.
> It'd be a pity to force all cards down to 10MHz because of (so far) this
> one card: the 512MB cards I got from Openmoko don't exhibit this issue
> for example.
This happens with 2 identical A-Data 2GB cards on 2 v6 phones. I agree, 
though, and would like to get down to the bottom of this. What is 
setting f_max doing to the lower layer? Is it causing a pause between 
blocks? Is it programming a DMA clock?






More information about the openmoko-kernel mailing list