Commit Graph

109 Commits

Author SHA1 Message Date
Sascha Hauer
b9b3f82f94 dmaengine i.MX sdma: set maximum segment size for our device
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
2011-01-31 12:32:52 +01:00
Shawn Guo
d718f4ebdd dmaengine: imx-sdma: fix inconsistent naming in sdma_assign_cookie()
Variable name sdma and sdmac are consistently used as the pointer to
sdma_engine and sdma_channel respectively throughout the file.  The
patch fixes the inconsistency seen in function sdma_assign_cookie().

Signed-off-by: Shawn Guo <shawn.guo@freescale.com>
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
2011-01-29 22:35:10 -08:00
Shawn Guo
939fd4f077 dmaengine: imx-sdma: propagate error in sdma_probe() instead of returning 0
Signed-off-by: Shawn Guo <shawn.guo@freescale.com>
Acked-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
2011-01-29 19:34:10 -08:00
Sascha Hauer
6866fd3b72 dmaengine i.MX SDMA: Fix firmware loading
When loading the microcode to the SDMA engine we have to use
the ram_code_start_addr found in the firmware image. The copy
in the sdma engine is not initialized correctly. This is broken
since:
5b28aa3 dmaengine i.MX SDMA: Allow to run without firmware

Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
2011-01-29 16:14:49 -08:00
Russell King
1051b9f0f9 Merge branch 'for-rmk' of git://git.pengutronix.de/git/imx/linux-2.6 into devel-stable 2011-01-05 10:23:38 +00:00
Sascha Hauer
c989a7fc13 dmaengine i.MX SDMA: initialize on module_init
The firmware framework gets initialized during fs_initcall time, so
we are not allowed to call request_firmware earlier.

Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
2010-12-07 15:38:07 -08:00
Anatolij Gustschin
d2f5c276ea dmaengine: imx-sdma: fix bug in buffer descriptor initialization
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: Anatolij Gustschin <agust@denx.de>
Acked-by: Sascha Hauer <s.hauer@pengutronix.de>
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
2010-12-04 15:03:46 -08:00
Sascha Hauer
5b28aa319b dmaengine i.MX SDMA: Allow to run without firmware
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: Sascha Hauer <s.hauer@pengutronix.de>
Acked-by: Dan Williams <dan.j.williams@intel.com>
2010-12-03 11:04:54 +01:00
Sascha Hauer
1ec1e82f25 dmaengine: Add Freescale i.MX SDMA support
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: Sascha Hauer <s.hauer@pengutronix.de>
Reviewed-by: Linus Walleij <linus.ml.walleij@gmail.com>
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
2010-10-05 15:49:26 -07:00