From: Boris Gjenero <boris.gjenero_at_gmail.com>
Date: Wed, 24 Dec 2008 20:41:58 -0500

On 24/12/2008 2:46 AM, Mike . wrote:
> This sounds like a pretty big improvement. Even if CPU time isn't
> decreased, the higher transfer rate would still give a large improvement
> in battery life due to faster spin down of the disk. Compared to
> boosting, the disk uses a very large amount of power.

I understand, and I see why this code is important. Currently I use
mode 2 without any extra boosts. If someone wants to examine Ultra DMA
mode 4 with boosting, the timing value is 0x80003071.

> One question about caching though, PP has DRAM aliases available that
> should be uncached (theres an uncached preprocessor define for it). Can
> you use these instead of flushing? I would expect it to be faster then
> flushing.

DMA transfers data to/from DRAM without involving the cache. I don't
think the uncached alias would make any difference in the code I am
working on. Instead, throughout Rockbox, whenever data from the disk is
read and whenever data going to the disk is written, it would have to be
done via the uncached alias. This may be okay for some things, but it
would probably be too slow for codecs.

(The 0x10000000 being added to the address is because Rockbox remaps the
RAM from 0x10000000 to 0, and DMA requires a physical address.)

If partial cache invalidation and flushing cannot be figured out, I
think the best thing to do would be to minimize the amount of flushes by
reading more at a time or another mechanism.

> I definitely want to see testing of this. Post it to the tracker so that
> people can try battery benching it.

Because of all the interest, I've posted a preliminary patch at:
http://www.rockbox.org/tracker/task/9708

I've decided to redo the patch with minimum changes to ata.c. That
should speed the progress of this patch. I think the refactoring I'm
doing is a good idea, but it can be a separate task.

-- 
Boris

Received on 2008-12-25