As per the reference manual, bit "L" should be set while bit "C"
should be cleared for the last buffer descriptor in the non-cyclic
chain, so that sdma can stop trying to find the next BD and end
the transfer.

In case of sdma_prep_slave_sg(), BD_LAST needs to be set and BD_CONT
be cleared for the last BD.
Signed-off-by: NShawn Guo <shawn.guo@freescale.com>
Signed-off-by: NSascha Hauer <s.hauer@pengutronix.de>

sdma_handle_channel_loop() is the handler of cyclic tx.  One period
success does not really mean the success of the tx.  Instead of
DMA_SUCCESS, DMA_IN_PROGRESS should be the one to tell.
Signed-off-by: NShawn Guo <shawn.guo@freescale.com>
Signed-off-by: NSascha Hauer <s.hauer@pengutronix.de>

The sdmac->status was designed to reflect the status of the tx,
so simply return it in sdma_tx_status().  Then dma client can call
dma_async_is_tx_complete() to know the status of the tx.
Signed-off-by: NShawn Guo <shawn.guo@freescale.com>
Signed-off-by: NSascha Hauer <s.hauer@pengutronix.de>

sdma_prep_dma_cyclic() sets sdmac->status to DMA_ERROR in err_out,
and sdma_prep_slave_sg() needs to do the same.  Otherwise,
sdmac->status stays at DMA_IN_PROGRESS, which will make the function
return immediately next time it gets called.
Signed-off-by: NShawn Guo <shawn.guo@freescale.com>
Signed-off-by: NSascha Hauer <s.hauer@pengutronix.de>

This is a leftover from the time that the driver did not have
sdma_prep_dma_cyclic callback and implemented sound dma as a looped
sg chain.  And it can be removed now.
Signed-off-by: NShawn Guo <shawn.guo@freescale.com>
Signed-off-by: NSascha Hauer <s.hauer@pengutronix.de>

The firmware framework gets initialized during fs_initcall time, so
we are not allowed to call request_firmware earlier.
Signed-off-by: NSascha Hauer <s.hauer@pengutronix.de>
Signed-off-by: NDan Williams <dan.j.williams@intel.com>

Currently while submitting scatterlists with more than one SG
entry the DMA buffer address from the first SG entry is inserted
into all initialized DMA buffer descriptors. This is due to the
typo in the for_each_sg() loop where the scatterlist pointer is
used for obtaining the DMA buffer address and _not_ the SG list
iterator.

As a result all received data will be written only into the first
DMA buffer while reading. While writing the data from the first
DMA buffer is send to the device multiple times. This caused
the filesystem destruction on the MMC card when using DMA in
mxcmmc driver.
Signed-off-by: NAnatolij Gustschin <agust@denx.de>
Acked-by: NSascha Hauer <s.hauer@pengutronix.de>
Signed-off-by: NDan Williams <dan.j.williams@intel.com>

The SDMA firmware consists of a ROM part and a RAM part.
The ROM part is always present in the SDMA engine and
is sufficient for many cases.
This patch allows to pass in platform data containing
the script addresses in ROM, so loading a firmware is
optional now.
Signed-off-by: NSascha Hauer <s.hauer@pengutronix.de>
Acked-by: NDan Williams <dan.j.williams@intel.com>

This patch adds support for the Freescale i.MX SDMA engine.

The SDMA engine is a scatter/gather DMA engine which is implemented
as a seperate coprocessor. SDMA needs its own firmware which is
requested using the standard request_firmware mechanism. The firmware
has different entry points for each peripheral type, so drivers
have to pass the peripheral type to the DMA engine which in turn
picks the correct firmware entry point from a table contained in
the firmware image itself.
The original Freescale code also supports support for transfering
data to the internal SRAM which needs different entry points to
the firmware. Support for this is currently not implemented. Also,
support for the ASRC (asymmetric sample rate converter) is skipped.

I took a very simple approach to implement dmaengine support. Only
a single descriptor is statically assigned to a each channel. This
means that transfers can't be queued up but only a single transfer
is in progress. This simplifies implementation a lot and is sufficient
for the usual device/memory transfers.
Signed-off-by: NSascha Hauer <s.hauer@pengutronix.de>
Reviewed-by: NLinus Walleij <linus.ml.walleij@gmail.com>
Signed-off-by: NDan Williams <dan.j.williams@intel.com>