maemo.org Bugzilla – Bug 2838
Transfer speeds to MMC/SD cards get very low on N800 with OS2008 when device idles
Last modified: 2009-01-07 15:11:59 UTC
You need to
before you can comment on or make changes to this bug.
STEPS TO REPRODUCE THE PROBLEM:
Try and read from an MMC or SD card
Transfer rates above 4.5MB/s
Transfer rates of about 4.5MB/s
EXTRA SOFTWARE INSTALLED:
With os2007, I benchmarked a number of cards and was getting transfer rates
exceeding 7MB/s and with my 48MHz patch, I could hit 13MB/s. Now, with OS2008,
all these cards are transfering at about 4.5MB/s.
Amazingly, if load is placed on the CPU, the transfer rate actually increases -
I've seen it go back up over 7MB/s with the right amount of load.
Seems like a problem with the cpu power saving logic. It's not speeding up to
cope with the data transfer.
It seems that the base problem is that the SD bus speed is calculated as a
fraction of the cpu speed and when idle, the cpu speed is 165MHz and the cpu
load of the transfer is not enough of a trigger to kick the speed up.
One way to address it might be to have a cpufreq hook to notice SD transfers
but the ideal fix would be to recalculate the SD bus divider. I have no idea if
the omap2 can do that.
*** This bug has been confirmed by popular vote. ***
Blog entry about this is at http://intr.overt.org/blog/?p=70 and custom kernel,
PATCHES and instructions at http://intr.overt.org/4.2008.23-mmc-kernel . Maybe
interesting to get this upstream.
(Philip, for future reference I'd prefer to also see the patches from your blog
linked here to keep this streamlined. ;-)
Nokia people have indicated they won't officially support 48MHz operation
because TI doesn't recommend using it - even though it seems to work for
everyone who's given me feedback.
Also, for the record, the 48MHz patch is a separate matter from the slow
transfers when the CPU is clocked down.
Comment from the Nokia BTS:
The clock MMC uses doesn't change when operating point changes -> INVALID. I
suspect that the ARM side could be clocked lower when the device is otherwise
idle (screen turned off etc) though and that's why transfer slows down.
So, I guess user would need to manually set fixed higher operating point
instead of having it in automatic mode, if one wants higher transfer speeds.
DVFS code won't be changed in this regards (not lowering ARM side clock while
there's still MMC operation ongoing) for Diablo.
Closing as INVALID for Diablo here too, as per last comment.
No idea about Fremantle plans on DVFS though and whether there will be some
changes or not. :-/
Pinged again in the internal report.
Ok, I don't want to be splitting hairs, but invalid is not the proper
resolution here. It is obvious that the speed can be increased quite easily.
wontfix would be a more proper resolution - at least that's admitting that
there are things that could be done to improve the situation, but they are too
risky to undertake (for some reason).
(In reply to comment #8)
> (for some reason).
That 'for some reason' is bricked and non-functional SD cards.
Arguably, this could also be marked FIXED for Fremantle, since the current
kernel code seems to suggest the MMC interface will be 48MHz from the start.
This isn't about the 48MHz MMC bus speed - it's about the fact that on an
otherwise idle system, the CPU will run at a sufficiently low speed that it
becomes the bottleneck, rather than the MMC bus.