Andy Green wrote:
Somebody in the thread at some point said:
| Second try. It turns out I was just masking a problem and these
| particular cards can't run faster than /5 for f_max:
| + u8a[5] = crc7(0, &u8a[0], 5) | 0x01; /* CRC7 on first 5 bytes of
...
| - mmc->f_max = host->clk_rate / 3;
| + mmc->f_max = host->clk_rate / 5;
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.
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.
