path: root/firmware/SOURCES
diff options
authorCástor Muñoz <>2014-12-06 18:33:11 +0100
committerCástor Muñoz <>2015-10-07 06:15:03 +0200
commitd6ee2c9eafbf5381695d1c7eb01801855c85222b (patch)
treea6ae8fb8deeebfece6f110a0e44643fa8194662e /firmware/SOURCES
parent609cde94689b20098be1c36cc5157514b6dd63a4 (diff)
iPod Classic: introduce PL080 DMA controller driver
Motivation: This driver began as a set of functions to help to test and experiment with different DMA configurations. It is cumbersome, time consuming, and leads to mistakes to handle LLIs and DMA registers dispersed along the code. Later, i decided to adapt an old DMA queue driver written in the past for a similar (scatter-gather) controller, all task/queue code is based on the old driver. Finally, some cleaning and dmac_ch_get_info() function was added to complete RB needs. Description: - Generic, can be used by other targets including the same controller. Not difficult to adapt for other similar controllers if necesary. - Easy to experiment and compare results using different setups and/or queue algorithms: Multi-controller and fully configurable from an unique place. All task and LLI management is done by the driver, user only has to (statically) allocate them. - Two queue modes: QUEUE_NORMAL: each task in the queue is launched using a new DMA transfer once previous task is finished. QUEUE_LINK: when a task is queued, it is linked with the last queued task, creating a single continuous DMA transfer. New tasks must be queued while the channel is running, otherwise the continuous DMA transfer will be broken. On Classic, QUEUE_LINK mode is needed for I2S continuous transfers, QUEUE_NORMAL is used for LCD and could be useful in the future for I2C or UART (non-blocking serial debug) if necessary. - Robust DMA transfer progress info (peak meter), needs final testing, see below. Technical details about DMA progress: There are comments in the code related to the method actually used (sequence method), it reads progress without halting the DMA transfer. Althought the datasheet does not recommend to do that, the sequence method seems to be robust, I ran tests calling dmac_ch_get_info() millions of times and the results were always as expected (tests done at 2:1 CPU/AHB clock ratio, no other ratios were tried but probably sequence method will work for any typical ratio). This controller allows to halt the transfer and drain the DMAC FIFO, DMA requests are ignored when the DMA channel is halted. This method is not suitable for playback because FIFO is never drained to I2S peripheral (who raises the DMA requests). This method probably works for capture, the FIFO is drained to memory before halting. Another way is to disable (stop) the playback channel. When the channel is disabled, all FIFO data is lost. It is unknown how much the FIFO was filled when it was cleared, SRCADDR counter includes the lost data, therefore the only useful information is LINK and COUNT, that is the same information disponible when using the sequence method. At this point we must procced in the same way as in sequence method, in addition the playback channel should be relaunched (configure + start) after calculating real SRCADDR. The stop+relaunch method should work, it is a bit complicated, and not valid for all peripheral FIFO configurations (depending on stream rate). Moreover, due to the way the COUNT register is implemented in HW, I suspect that this method will fail when source and destination bus widths doesn't match. And more important, it is not easy to garantize that no sample is lost here or there, using the sequence method we can always be sure that playback is ok. Change-Id: Ib12a1e2992e2b6da4fc68431128c793a21b4b540
Diffstat (limited to 'firmware/SOURCES')
1 files changed, 1 insertions, 0 deletions
diff --git a/firmware/SOURCES b/firmware/SOURCES
index d3fb69f9e8..17f6ad7e0a 100644
--- a/firmware/SOURCES
+++ b/firmware/SOURCES
@@ -1598,6 +1598,7 @@ target/arm/s5l8702/ipod6g/power-ipod6g.c
#if 0 //TODO