linux-toradex.git/drivers/dma, branch v3.14.57

dmaengine: dw: properly read DWC_PARAMS register

2015-10-22T21:39:17+00:00

commit 6bea0f6d1c47b07be88dfd93f013ae05fcb3d8bf upstream.

In case we have less than maximum allowed channels (8) and autoconfiguration is
enabled the DWC_PARAMS read is wrong because it uses different arithmetic to
what is needed for channel priority setup.

Re-do the caclulations properly. This now works on AVR32 board well.

Fixes: fed2574b3c9f (dw_dmac: introduce software emulation of LLP transfers)
Cc: yitian.bu@tangramtek.com
Signed-off-by: Andy Shevchenko 
Signed-off-by: Vinod Koul 
Signed-off-by: Greg Kroah-Hartman

dmaengine: mv_xor: bug fix for racing condition in descriptors cleanup

2015-08-03T16:29:57+00:00

commit 9136291f1dbc1d4d1cacd2840fb35f4f3ce16c46 upstream.

This patch fixes a bug in the XOR driver where the cleanup function can be
called and free descriptors that never been processed by the engine (which
result in data errors).

The cleanup function will free descriptors based on the ownership bit in
the descriptors.

Fixes: ff7b04796d98 ("dmaengine: DMA engine driver for Marvell XOR engine")
Signed-off-by: Lior Amsalem 
Signed-off-by: Maxime Ripard 
Reviewed-by: Ofer Heifetz 
Signed-off-by: Vinod Koul 
Signed-off-by: Greg Kroah-Hartman

dmaengine: omap-dma: Fix memory leak when terminating running transfer

2015-04-19T08:11:07+00:00

commit 02d88b735f5a60f04dbf6d051b76e1877a0d0844 upstream.

In omap_dma_start_desc the vdesc->node is removed from the virt-dma
framework managed lists (to be precise from the desc_issued list).
If a terminate_all comes before the transfer finishes the omap_desc will
not be freed up because it is not in any of the lists and we stopped the
DMA channel so the transfer will not going to complete.
There is no special sequence for leaking memory when using cyclic (audio)
transfer: with every start and stop of a cyclic transfer the driver leaks
struct omap_desc worth of memory.

Free up the allocated memory directly in omap_dma_terminate_all() since the
framework will not going to do that for us.

Signed-off-by: Peter Ujfalusi 
CC: 
Signed-off-by: Vinod Koul 
Signed-off-by: Greg Kroah-Hartman

dmaengine: dw: append MODULE_ALIAS for platform driver

2015-04-13T12:03:02+00:00

commit a104a45ba7a51b5b4c5e8437020d9d48edf22f89 upstream.

The commit 9cade1a46c77 (dma: dw: split driver to library part and platform
code) introduced a separate platform driver but missed to add a
MODULE_ALIAS("platform:dw_dmac"); to that module.

The patch adds this to get driver loaded automatically if platform device is
registered.

Reported-by: "Blin, Jerome" 
Fixes: 9cade1a46c77 (dma: dw: split driver to library part and platform code)
Signed-off-by: Andy Shevchenko 
Signed-off-by: Vinod Koul 
Signed-off-by: Greg Kroah-Hartman

dmaengine: dw: don't perform DMA when dmaengine_submit is called

2014-10-05T21:52:24+00:00

commit dd8ecfcac66b4485416b2d1df0ec4798b198d7d6 upstream.

Accordingly to discussion [1] and followed up documentation the DMA controller
driver shouldn't start any DMA operations when dmaengine_submit() is called.

This patch fixes the workflow in dw_dmac driver to follow the documentation.

[1] http://www.spinics.net/lists/arm-kernel/msg125987.html

Signed-off-by: Andy Shevchenko 
Signed-off-by: Vinod Koul 
Cc: "Petallo, MauriceX R" 
Signed-off-by: Greg Kroah-Hartman

dmaengine: dw: introduce dwc_dostart_first_queued() helper

2014-10-05T21:52:24+00:00

commit e7637c6c0382485f4d2e20715d058dae6f2b6a7c upstream.

We have a duplicate code which starts first descriptor in the queue. Let's make
this as a separate helper that can be used in future as well.

Signed-off-by: Andy Shevchenko 
Signed-off-by: Vinod Koul 
Cc: "Petallo, MauriceX R" 
Signed-off-by: Greg Kroah-Hartman

dmaengine: dw: went back to plain {request,free}_irq() calls

2014-06-07T17:28:26+00:00

commit 97977f7576a89cb9436c000ae703c0d515e748ac upstream.

The commit dbde5c29 "dw_dmac: use devm_* functions to simplify code" turns
probe function to use devm_* helpers and simultaneously brings a regression. We
need to ensure irq is disabled, followed by ensuring that don't schedule any
more tasklets and then its safe to use tasklet_kill().

The free_irq() will ensure that the irq is disabled and also wait till all
scheduled interrupts are executed by invoking synchronize_irq(). So we need to
only do tasklet_kill() after invoking free_irq().

Signed-off-by: Andy Shevchenko 
Signed-off-by: Vinod Koul 
Signed-off-by: Greg Kroah-Hartman

dma: mv_xor: Flush descriptors before activating a channel

2014-06-07T17:28:25+00:00

commit 5a9a55bf9157d3490b0c8c4c81d4708602c26e07 upstream.

We need to use writel() instead of writel_relaxed() when starting
a channel, to ensure all the descriptors have been flushed before
the activation.

While at it, remove the unneeded read-modify-write and make the
code simpler.

Signed-off-by: Lior Amsalem 
Signed-off-by: Ezequiel Garcia 
Signed-off-by: Dan Williams 
Signed-off-by: Greg Kroah-Hartman

dmaengine: fix dmaengine_unmap failure

2014-06-07T17:28:25+00:00

commit c1f43dd9c20d85e66c4d77e284f64ac114abe3f8 upstream.

The count which is used to get_unmap_data maybe not the same as the
count computed in dmaengine_unmap which causes to free data in a
wrong pool.

This patch fixes this issue by keeping the map count with unmap_data
structure and use this count to get the pool.

Signed-off-by: Xuelin Shi 
Signed-off-by: Dan Williams 
Signed-off-by: Greg Kroah-Hartman

dma: edma: fix incorrect SG list handling

2014-05-13T11:32:55+00:00

commit 5fc68a6cad658e45dca3e0a6607df3a8e5df4ef9 upstream.

The code to handle any length SG lists calls edma_resume()
even before edma_start() is called. This is incorrect
because edma_resume() enables edma events on the channel
after which CPU (in edma_start) cannot clear posted
events by writing to ECR (per the EDMA user's guide).

Because of this EDMA transfers fail to start if due
to some reason there is a pending EDMA event registered
even before EDMA transfers are started. This can happen if
an EDMA event is a byproduct of device initialization.

Fix this by calling edma_resume() only if it is not the
first batch of MAX_NR_SG elements.

Without this patch, MMC/SD fails to function on DA850 EVM
with DMA. The behaviour is triggered by specific IP and
this can explain why the issue was not reported before
(example with MMC/SD on AM335x).

Tested on DA850 EVM and AM335x EVM-SK using MMC/SD card.

Cc: Joel Fernandes 
Acked-by: Joel Fernandes 
Tested-by: Jon Ringle 
Tested-by: Alexander Holler 
Reported-by: Jon Ringle 
Signed-off-by: Sekhar Nori 
Signed-off-by: Vinod Koul 
Signed-off-by: Greg Kroah-Hartman