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

Andy Green andy at
Sun May 11 09:46:25 CEST 2008

Hash: SHA1

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.

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.

|> | I'm not very sure if the irq handler is working for me. Maybe this is a
|> | cpu-bound limitation? What happens when I don't reduce f_max is that I
|> | get a data timeout with data ready set at the same time.
|> If you have GTA02 A5 and later, it will use irq; for A4 and earlier the
|> irq line is broken and it detects that and uses polling.  Otherwise
|> glamo irq is definitely solid for mmc, since I use sd card rootfs here
|> all day every day.

| This is a v6 phone.

Same as A5 for this purpose.

- -Andy
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora -


More information about the openmoko-kernel mailing list