Fix problem with A-Data 2GB microSD card - Revisited
Andy Green
andy at openmoko.com
Sun May 11 10:20:46 CEST 2008
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Somebody in the thread at some point said:
|> 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.
Whoo.
|> 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?
No it's doing something pretty mundane, setting a ceiling for the clock
rate that will be requested of this mmc driver from the mmc layer. It
won't ask for faster than 10MHz with /5 when you set that, despite the
card says it can handle faster.
In turn this just fixes the MMC clock generated by the Glamo to the
10MHz requested by the MMC layer.
And the Glamo timeout counter (max 4095 x 16 clocks) is counted out
using this MMC clock. Therefore when you slow the MMC clock, you allow
more absolute time to pass before the timeout fires, which I guess is
the magic ingredient here; the card is slow to access the last 1GB for
some internal reason. But we tried cranking the timeout to the max also
and that isn't enough.
Since I didn't see a way to identify cards that behave like this other
than seeing them time out, the only solution that we have at the moment
to make it happy is to crank down the clock, which is a shame.
- -Andy
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org
iEYEARECAAYFAkgmrF4ACgkQOjLpvpq7dMpXOgCfdNNAFQWr31V7yk0NUGRQpXMc
ycIAn1/+GkdNWUvlLaNpRgVDiCeJka+l
=2HUq
-----END PGP SIGNATURE-----
More information about the openmoko-kernel
mailing list