- Status Unconfirmed
- Percent Complete
- 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
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.
Loading...
Available keyboard shortcuts
- Alt + ⇧ Shift + l Login Dialog / Logout
- Alt + ⇧ Shift + a Add new task
- Alt + ⇧ Shift + m My searches
- Alt + ⇧ Shift + t focus taskid search
Tasklist
- o open selected task
- j move cursor down
- k move cursor up
Task Details
- n Next task
- p Previous task
- Alt + ⇧ Shift + e ↵ Enter Edit this task
- Alt + ⇧ Shift + w watch task
- Alt + ⇧ Shift + y Close Task
Task Editing
- Alt + ⇧ Shift + s save task
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?
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
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
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.
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.
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#9910doesn'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#9910for details regarding interrupt support. I didn't go beyond finding DMA0_MASK and took a guess at where 1-3 would be.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
.
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.