Hi
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.
I will redo your tests in a jiffy, however the latency issues worry me
a wee bit.
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.
The latency we can see here in the oscilloscope is tremendous between
two CMD24: 8ms! What is causing this? It is certainly unrelated to the
MULTIBLOCK feature. Having a clock at 33.25MHz, our maximal read, as
confirmed by dd is:
33.25[MHz] * 4[bits data] / 8[bits/Byte] * 30 [us write] / 8000 [us
sleep] =~ 60KB/s
So, what's keeping the driver 8ms from sending the data??? Any pointers
on where I could twiddle some bits in the driver? Where do I start
looking?
Cheers
--
Joan C. Abelaira
--
To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
