On Mon, Jan 24, 2011 at 05:54:18PM -0000, Pawel Moll wrote:
$ git am 0001-arm-Improve-MMC-performance-on-Versatile-Express.patch
/ # uname -a Linux (none) 2.6.38-rc2+ #12 SMP Mon Jan 24 17:41:53 GMT 2011 armv7l GNU/Linux / # cat /dev/sda > /dev/null & / # dd if=/dev/mmcblk0 of=/dev/null bs=64k count=128 128+0 records in 128+0 records out 8388608 bytes (8.0MB) copied, 1.501529 seconds, 5.3MB/s
THERE IS NO ISSUE WITH MMCI. THE HARDWARE DOES NOT NEED "FIXING".
I'm really pleased you think so. It's always nice to have happy customers :-)
If you're flooding the system with USB traffic, enlargening the FIFO size won't help. Making the FIFO larger just decreases the _interrupt_ _latency_ requirements. It doesn't mean you can cope with the amount of data being transferred.
if (cycles-to-transfer-usb-packets + cycles-to-transfer-MMC-data > available-cpu-cycles) you_are_stuffed(even_with_larger_fifo);
So I'm not surprised that running USB and MMC at full speed results in MMC losing out. You will find that even with a larger FIFO, MMC will still lose out.
Why? The ISP1761 can store the packets without complaint, and the host CPU can read them when it's ready. As soon as one packet is read off the host, the next packet is probably sitting there waiting for the host CPU to read it. When the ISP1761 buffer becomes full, it can tell the device to stop sending data.
The result of that is the ISP1761 will be able to transfer data as fast as the host CPU can possibly go - to the exclusion of the MMC interface. No amount of FIFO (well, except several KB to cover the _largest_ size of MMC transfer we request) will resolve the problem of USB and MMC sharing the same CPU.