TMOD_TO is the transmit-only mode that doesn't put data into the receive
FIFO. Using TMOD_TO when the user doesn't want the received data saves
CPU time and memory bandwidth.

Signed-off-by: Phil Elwell <phil@raspberrypi.com>

TMOD_RO is the receive-only mode that doesn't require data in the
transmit FIFO in order to generate clock cycles. Using TMOD_RO when the
device doesn't care about the data sent to it saves CPU time and memory
bandwidth.

Signed-off-by: Phil Elwell <phil@raspberrypi.com>

Disabling the peripheral resets controller state which has a dangerous
side-effect of disabling the DMA handshake interface while it is active.
This can cause DMA channels to hang.

The error recovery pathway will wait for DMA to stop and reset the chip
anyway, so mask further FIFO interrupts and let the transfer finish
gracefully.

Signed-off-by: Jonathan Bell <jonathan@raspberrypi.com>

Channels 1-2 have a statically configured maximum MSIZE of 8, and
channels 3-8 have MSIZE set to 4. The DMAC "helpfully" silently
truncates bursts to the hardware supported maximum, so any FIFO read
operation with an oversized burst threshold will leave a residue of
threshold minus MSIZE rows.

As channel allocation is dynamic, this means every client needs to use a
maximum of 4 for burst length.

AXI AWLEN/ARLEN constraints aren't strictly related to MSIZE, except
that bursts won't be issued that are longer than MSIZE beats. Therefore,
it's a useful proxy to tell clients of the DMAC the hardware
limitations.

Signed-off-by: Jonathan Bell <jonathan@raspberrypi.com>

There's no real need to constrain MEM access widths to 32-bit (or
narrower), as the DMAC is intelligent enough to size memory accesses
appropriately. Wider accesses are more efficient.

Similarly, MEM burst lengths don't need to be a function of DEV burst
lengths - the DMAC packs/unpacks data into/from its internal channel
FIFOs appropriately. Longer accesses are more efficient.

However, the DMAC doesn't have complete support for unaligned accesses,
and blocks are always defined in integer multiples of SRC_WIDTH, so odd
source lengths or buffer alignments will prevent wide accesses being
used, as before.

There is an implicit requirement to limit requested DEV read burst
lengths to less than the hardware's maximum configured MSIZE - otherwise
RX data will be left over at the end of a block. There is no config
register that reports this value, so the AXI burst length parameter is
used to produce a facsimile of it. Warn if such a request arrives that
doesn't respect this.

Signed-off-by: Jonathan Bell <jonathan@raspberrypi.com>

This issue was due to a misconfiguration of the RP1 DMAC due to hardware
limitations, not the SPI driver (which was using the incorrect reported
maximum burst size to set the FIFO threshold).

This reverts commit 6aab06f.

Signed-off-by: Jonathan Bell <jonathan@raspberrypi.com>

If the associated DMA controller has lower burst length support than the
level the FIFO is set to, then bytes will be left in the RX FIFO at the
end of a DMA block - requiring a round-trip through the timeout interrupt
handler rather than an end-of-block DMA interrupt.

Signed-off-by: Jonathan Bell <jonathan@raspberrypi.com>

Do an end-run around ASoC in lieu of not being able to easily find the
associated DMA controller capabilities.

Signed-off-by: Jonathan Bell <jonathan@raspberrypi.com>

…ints

Valid ranges for the I2S peripheral's FIFO configuration include a depth
of 16 - unconditionally setting the burst length to 16 with a fifo
threshold of size/2 will cause under/overflows.

For DMA engines with restricted capabilities the requested burst length
and FIFO thresholds need to be adjusted downward accordingly.

Both the RX and TX FIFOs operate on "less-than" thresholds. Setting the
TX threshold to fifo_size minus burst means the FIFO is kept nearly-full.

Signed-off-by: Jonathan Bell <jonathan@raspberrypi.com>

The associated DMAC has channels that do not support longer bursts.

Signed-off-by: Jonathan Bell <jonathan@raspberrypi.com>