> I just subscribed here because this seems more appropriate than the
> forums for development-related discussion. I'm Boris Gjenero,
> dreamlayers on the forums and in the tracker.
> I got Ultra DMA working on my 5th generation 30 gig iPod. Mode 2 (33.3
> MB/s) seems stable, and it doesn't need CPU frequency boost. I've also
> used mode 4 (66.7 MB/s), but that required boosting and I didn't test it
Sound great. amiconn and I have speculated before about the cost in battery life imposed by PIO mode, but no one has had any idea how UDMA works on PP.
> While implementing this I significantly altered firmware/drivers/ata.c.
> I merged the read and write functions into a transfer function which
> can do both reads and writes with both PIO and DMA. This removes some
> code duplication and IMHO enhances writes by using "write multiple" and
> doing retries if needed.
> The main benefit I can see from DMA is somewhat faster buffer filling.
> For example, with one large unfragmented FLAC file and the FS#9621 FAT
> read-ahead patch, the initial load is about twice as fast with DMA.
> Test_disk says 1 meg reads are 14102 KB/s and writes aren't sped up. I
> suspect the reported read speed is from the drive's cache, not the
> media. (BTW. Why are PIO reads slower than PIO writes in test_disk?)
> The main cost of DMA is having to flush and invalidate the cache. It
> might be possible to only do that to part of the cache, but I haven't
> figured this out yet.
>I guess DMA might not decrease the PP5020's power
> consumption because the CPU is busy anyways due to polling, and the DMA
> hardware also uses power.
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.
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.
> I'm wondering how to proceed now. Is there interest in this, or is the
> current way good enough? Should I continue to work on my modified
> ata.c? Should I merge the DMA code with Rockbox with a minimum of
> change to ata.c and create a patch based on that?
I definitely want to see testing of this. Post it to the tracker so that people can try battery benching it.
It’s the same Hotmail®. If by “same” you mean up to 70% faster.
Received on 2008-12-24