Rockbox

  • Status Unconfirmed
  • Percent Complete
    0%
  • Task Type Patches
  • Category Drivers
  • Assigned To No-one
  • Operating System Sansa e200
  • Severity Low
  • Priority Very Low
  • Reported Version Daily build (which?)
  • Due in Version Undecided
  • Due Date Undecided
  • Votes
  • Private
Attached to Project: Rockbox
Opened by ahellmann - 2008-03-30

FS#8830 - Sansa: DMA support for sd-card data access (experimentary)

First approach, to add dma read/write disk access to the sansa.

There are some restrictions on the dma functionality with this patch:
- only stabile at 80MHz ⇒ cpu boost control added to the driver
- only on 16byte aligned data ptr ⇒ all data are copied to/from aligned memory
- no interrupt support ⇒ using polling method

At 30MHz the driver is much more stable with the following PLL settings:
PLL_CONTROL = 0x8a221e0c; /* 30 MHz = (48MHz/12*30) / 4 */
CLOCK_SOURCE = 0×40007777; /* source #1, #2, #3, #4: PLL (#4 active) */

Reading seems to be in general more reliable than writing of the cards.
The data throughput is a little worse than in the current implementation.
This is partly due to the data copying.
The sporadical ‘2bytes inserted’ problem with the USB file transfer is still
there. Interestingly @30MHz with the above settings, there is another problem:
sporadically ‘2bytes missing’ and ‘2bytes inserted’. Perhaps the DMA transfer
needs some more initialization for proper synchronization.

   sd_dma.diff (6.9 KiB)
rp commented on 2008-05-06 06:41

How much benefit would this bring if it would work flawless? because i have now an 8gb sdhc card and have all my music on it.
Is there a lot of cpu involved with the current implementation(SVN)?
How is your progress since this patch is 1 month old?

dan_a commented on 2008-05-27 23:52

I've just run the test_disk plugin on the latest SVN + this patch.

Without DMA:
Create: 27 files/s
Open: 54 files/s
Dirscan: 6269 fils/s
Delete: 56 files/s 

            Create  Write  Read (KB/sec)

512,A 276 266 925
512,U 272 268 916
4096,A 1462 1439 4499
4096,U 1478 1462 4494
1048576,A 3900 3881 9836
1048576,U 3915 4046 9138

With DMA:
Create: 25 files/s
Open: 55 files/s
Dirscan: 5784 files/s
Delete 51 files/s 

            Create  Write  Read (KB/sec)

512,A 252 252 830
512,U 265 269 803
4096,A 1324 1314 3742
4096,U 1374 1369 2664
1048576,A 4087 4079 7198
1048576,U 4031 4104 7013

This seems to show that working with DMA is slower than working without it. This is partly to be expected as the driver yields while waiting for the transfer to finish.

dreamlayers commented on 2008-12-24 05:36

You should probably flush_icache() before a read. The invalidate_icache() after a read does a flush and it can overwrite new data in memory with old data from the cache. Before a write you just need to flush.

MikeS commented on 2009-02-16 21:17

Reading from a card should entail aligning up to a cache line boundary, calling cpucache_invalidate, dma-ing up to a cache line boundary and then finishing trailing words with a manual read to avoid clobbering what the peripheral has written if writebacks take place in lines shared with adjacent buffers.

I'm curious what you mean by DMA not working reliably at 30MHz.  FS#9910  doesn't seem to have a reliability issue with DMA at 30MHz. There's something reported with H10 but I can't pin that on DMA at this time and I'm checking H10 at this moment. My guess is that it is scaling related when actually performing the switch.

See  FS#9910  for details regarding interrupt support. I didn't go beyond finding DMA0_MASK and took a guess at where 1-3 would be.

MikeS commented on 2009-02-19 22:49

This would need to be resynced. I grabbed DMA0 for playback and plan on DMA1 for recording as had been established to allocate lower numbered channels to audio since coldfire came on the scene(though meg-fx is breaking this "rule" but I may address that).

I might even work on it if Toni has abandoned this one. I'm sensing a pattern ;-).

MikeS commented on 2009-02-23 04:19

One thing is for sure, I'm not sure what the advantage is. I tried things out and had no problems with "DMA reliability" but even with not using an intermediate buffer it can only eek out a little more on some very large buffers in test_disk relative to current SVN performance. That's with a glitch still present that is on one particular album (can't figure what the problem is) that is unaffected by CPU frequency. Perhaps quieting CPU activity would silence digital noise a bit but I don't know about that yet. A caveat is it seems there really is only ONE core interrupt bit shared amongst all DMA units (ugh). Trying it with writing fails miserably. I'll let this one RIP unless I have nothing more worthwhile persuing.

Loading...

Available keyboard shortcuts

Tasklist

Task Details

Task Editing