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

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
 target/arm/s5l8702/kernel-s5l8702.c
 target/arm/s5l8702/system-s5l8702.c
 target/arm/s5l8702/gpio-s5l8702.c
+target/arm/s5l8702/pl080.c
 target/arm/s5l8702/ipod6g/lcd-ipod6g.c
 target/arm/s5l8702/ipod6g/lcd-asm-ipod6g.S
 #if 0 //TODO