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

Andy Green andy at
Sun May 11 09:02:27 CEST 2008

Hash: SHA1

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);
			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.

| 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.

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


More information about the openmoko-kernel mailing list