[MX25][MMC] mmc esdhc failure in 3.3

[Eric Bénard]

Hi,

Le Tue, 27 Mar 2012 11:33:57 +0200,
joancarles <joancarles at fqingenieria.es> a écrit :
> >> Interesting question is now why it worked on your older kernel? The 
> >> code
> >> around BROKEN_TIMEOUT is there for much longer, I'd think.
> >>
> > not in fact it seems to have been broken from a long time and I think
> > I'm responsible of that in 37865fe91582582a6f6c00652f6a2b1ff71f8a78
> > "mmc: sdhci-esdhc-imx: fix timeout on i.MX's sdhc"
> > because unlike the i.MX35 it seems that the i.MX25 manages to read
> > properly the partition table even without the timeout quirk and it
> > seems that I didn't do more extensive tests for this patch.
> 
> Might be unrelated, however I have been keeping my eyes on the fix of 
> ENGcm07207 quirk introduced with 16a790bcc. According to the 
> IMX25CE.pdf, to abort data transfers on the AHB, software can reset the 
> eSDHC by writing 1 to SYSCTL[24] (RSTA), which currently is not done 
> with SDHCI_QUIRK_NO_MULTIBLOCK. It sets the max_blk_count to 1 instead 
> of 65535. Not sure if this is also limiting the speed.
> 
I tried to increase max_blk_count and it breaks after a few tests.
Using an oscilloscope it seems we have a big latency between each
transfer which could explain the low throughput, I didn't have the
time to look deeper at this problem.

> I have tried putting the SD card into an ALL-in-One reader via USB and 
> I get 6MB/s read and 15MB/s write performance. Since I didn't know the 
> exact class of the card, this reassures me that there is nothing 
> substantially wrong with the card per se.
> 
> So, how can we find a solution to this speed issue? Also, do you plan 
> on submitting your patch to revert the timeout quirk for MX25?
> 
yes, I'm writing a proper commit message and will send it in a few
minutes.

Eric