Fix problem with A-Data 2GB microSD card - Revisited
sean at mcneil.com
Sun May 11 21:12:07 CEST 2008
Andy Green wrote:
> Somebody in the thread at some point said:
> | I see that it sets the GLAMO_REG_CLOCK_GEN8 to a clock divisor as a base
> | 0. So it looks like I'm setting it to 4 in my case. If this clock
> | divisor isn't base 0 but base 1 then this calculation would be off and
> | that would explain it. The card could be specifying a rate of 12MHz but
> | the only way we knock it down to that rate is if I set the f_max low
> | enough.
> I measured the clock with a 'scope when I wrote this code, the clock
> frequencies are pretty correct. If it thinks it issues 16.6MHz it
> really does.
> | What does the documentation say about this?
> For that register (TCLK = MMC CLK)
> RW TCLK divide ratio
> 00000000: 1:1
> 00000001: 2:1
> 00000010: 3:1
> | What is the reference clock?
> | The code assumes a 50MHz clock.
> I mentioned in the probe code
> host->clk_rate = 50000000; /* really it's 49152000 */
> The best way I heard to explain it yet is just a mismatch between the
> worst case slowness of that card and the biggest timeout the Glamo can
> express at the faster clock rates. If the timeout register had another
> nybble in its counter we would just have set it to FFFF and forgotten
> about it.
Ah, OK. Could this also be related to the length of the transfer? What
if I reduce the number of blocks that can be read/written at once?
Something with req_size or seg_size?
More information about the openmoko-kernel