VE suffers from serious problem with MMC transfers - low performance,
errors when other IO peripherals (especially USB) are used at the
same time etc.
It all boils down to the MMC controller short FIFO and - in result -
timing constrains. The most problematic case - USB driver hogging
CPU and MMC FIFO under/overruns in the result - can be mitigated on
SMP system by distributing interrupts handling for these peripherals
between cores.
With this, the MMC card clock can be safely (at least it looks like
it) increased to 1.5MHz, improving performance.
Signed-off-by: Pawel Moll <pawel.moll(a)arm.com>
---
arch/arm/mach-vexpress/v2m.c | 14 ++++++++++++++
1 files changed, 14 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-vexpress/v2m.c b/arch/arm/mach-vexpress/v2m.c
index 4b5af01..300ac72 100644
--- a/arch/arm/mach-vexpress/v2m.c
+++ b/arch/arm/mach-vexpress/v2m.c
@@ -244,6 +244,7 @@ static unsigned int v2m_mmci_status(struct device *dev)
static struct mmci_platform_data v2m_mmci_data = {
.ocr_mask = MMC_VDD_32_33|MMC_VDD_33_34,
.status = v2m_mmci_status,
+ .f_max = 1500000,
};
static AMBA_DEVICE(aaci, "mb:aaci", V2M_AACI, NULL);
@@ -391,6 +392,19 @@ static void __init v2m_init(void)
for (i = 0; i < ARRAY_SIZE(v2m_amba_devs); i++)
amba_device_register(v2m_amba_devs[i], &iomem_resource);
+ /* WARNING: HACK HACK HACK!
+ *
+ * MMCI cell has very tight timing requirements regarding interrupt
+ * handling (fractions of millisecond), while the USB host controller
+ * interrupt handler can hog the CPU for more then 1 millisecond!
+ *
+ * To mitigate the problem on SMP systems, we can set CPU affinities
+ * of these interrupts to different cores... */
+ BUG_ON(v2m_usb_resources[1].flags != IORESOURCE_IRQ);
+ irq_set_affinity(v2m_usb_resources[1].start, cpumask_of(0));
+ irq_set_affinity(mmci_device.irq[0], cpumask_of(1));
+ irq_set_affinity(mmci_device.irq[1], cpumask_of(1));
+
pm_power_off = v2m_power_off;
arm_pm_restart = v2m_restart;
--
1.6.3.3
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.
Hi,
I just tried to create an SD image for the beagle with l-m-c from bzr.
The kernel command-line ends up containing 'console=tty0
console=NONE,115200n8'. Board configuration problem?
Overriding l-m-c with --console ttyO2 doesn't work since it is added
before the other consoles, so doesn't end up getting input. Shouldn't
it be the last console added in the list?
Regards,
Amit
Dechesne, Nicolas wrote:
> I actually wrote the instructions on the wiki above. but you need to use the full bzr+ssh:// link
as I put on the wiki. i have not been able to use shorthand link using
lp: type of link.
If you have the http_proxy environment variable set to something that
allows outgoing http, and if you have a recent bzr (from eg Ubuntu
Maverick) then lp urls should work through a proxy. You can set the
proxy variable in the GNOME Proxy control panel, or just eg from your
.bashrc:
export http_proxy=http://proxy.example.com:8080/
But it may be simpler to just use bzr+ssh.
Some of the ssh urls are different, for example to get a default
source package branch you need eg
bzr log bzr+ssh://bazaar.launchpad.net/+branch/ubuntu/maverick/bash
If you have any other problems please don't hesitate to ask in
#launchpad on irc, or http://answers.launchpad.net/launchpad/
--
Martin