Details

This patch greatly improves SD driver performance, at the cost of memory.

The memory cost is zero for 8MB targets, because the sd buffer is used to IRAM, which is nearly unused as of now (this isn't visible in the RAM usage which rockbox-info.txt gives). It's about 10k for 2MB targets (additionally the buffer cannot be in IRAM on those).

It turns out that a big ( aligned_buffer at IRAM gives a huge (~250%) transfer rate increase over SVN. A 32*SECTOR_SIZE buffer gives good performance too, but is noticable slower. Using the passed buffer (if word aligned) directly together with cache coherency functions is very fast too, but only increases performance on aligned transfers.

So, I decided to use the fastest setting on 8MB Samsas (64*SECTOR_SIZE buffer at IRAM).
on 2MB samsas I used a combo of 32*SECTOR_SIZE and using the passed buffer directly (this saves 15k RAM, at the cost of speed, code complexity and messing with the caches).

There's 2 problems: a) This separates the way the driver works for the Samsas (not so much code wise, but logic wise), I don't really like that.
b) the code path for 2MB targets gives data and prefetch aborts on my clip, but works fine on my fuze. I have no idea why!

I honestly think the 2MB targets, being flash devices, should also use the fastest setting. That would cost 25k over SVN (this patch adds 10k anyway, so it's effectively only 15k more RAM), but I think the unified code paths and better performance are worth it IMO.

No, but I doubt it's noticeable. On my fuze, rebuffering takes ~1s with it, instead of ~2. With 128k mp3 it would rebuffer every 4 (and a few seconds) minutes, so the time spend on rebuffering is negible in either case. So, battery life could be incresed by a few minutes if at all.

Picture flow is definitely improved. I can't notice any "?" covers when scrolling very quickly anymore (those "?" appear for a) no album art for a particular album or b) didn't load the aa from the disk yet).