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
Cástor Muñoz