linux-stable.git/drivers/dma, branch v3.16.40

dmaengine: dw: disable BLOCK IRQs for non-cyclic xfer

2016-03-04T10:26:40+00:00

commit ee1cdcdae59563535485a5f56ee72c894ab7d7ad upstream.

The commit 2895b2cad6e7 ("dmaengine: dw: fix cyclic transfer callbacks")
re-enabled BLOCK interrupts with regard to make cyclic transfers work. However,
this change becomes a regression for non-cyclic transfers as interrupt counters
under stress test had been grown enormously (approximately per 4-5 bytes in the
UART loop back test).

Taking into consideration above enable BLOCK interrupts if and only if channel
is programmed to perform cyclic transfer.

Fixes: 2895b2cad6e7 ("dmaengine: dw: fix cyclic transfer callbacks")
Signed-off-by: Andy Shevchenko 
Acked-by: Mans Rullgard 
Tested-by: Mans Rullgard 
Acked-by: Viresh Kumar 
Signed-off-by: Vinod Koul 
Signed-off-by: Luis Henriques

dmaengine: dw: fix cyclic transfer callbacks

2016-02-02T19:09:38+00:00

commit 2895b2cad6e7a95104cf396e5330054453382ae1 upstream.

Cyclic transfer callbacks rely on block completion interrupts which were
disabled in commit ff7b05f29fd4 ("dmaengine/dw_dmac: Don't handle block
interrupts").  This re-enables block interrupts so the cyclic callbacks
can work.  Other transfer types are not affected as they set the INT_EN
bit only on the last block.

Fixes: ff7b05f29fd4 ("dmaengine/dw_dmac: Don't handle block interrupts")
Signed-off-by: Mans Rullgard 
Reviewed-by: Viresh Kumar 
Signed-off-by: Vinod Koul 
Signed-off-by: Luis Henriques

dmaengine: dw: fix cyclic transfer setup

2016-02-02T19:09:37+00:00

commit df3bb8a0e619d501cd13334c3e0586edcdcbc716 upstream.

Commit 61e183f83069 ("dmaengine/dw_dmac: Reconfigure interrupt and
chan_cfg register on resume") moved some channel initialisation to
a new function which must be called before starting a transfer.

This updates dw_dma_cyclic_start() to use dwc_dostart() like the other
modes, thus ensuring dwc_initialize() gets called and removing some code
duplication.

Fixes: 61e183f83069 ("dmaengine/dw_dmac: Reconfigure interrupt and chan_cfg register on resume")
Signed-off-by: Mans Rullgard 
Reviewed-by: Viresh Kumar 
Signed-off-by: Vinod Koul 
Signed-off-by: Luis Henriques

dmaengine: dw: convert to __ffs()

2015-12-13T17:49:28+00:00

commit 39416677b95bf1ab8bbfa229ec7e511c96ad5d0c upstream.

We replace __fls() by __ffs() since we have to find a *minimum* data width that
satisfies both source and destination.

While here, rename dwc_fast_fls() to dwc_fast_ffs() which it really is.

Fixes: 4c2d56c574db (dw_dmac: introduce dwc_fast_fls())
Signed-off-by: Andy Shevchenko 
Signed-off-by: Vinod Koul 
Signed-off-by: Luis Henriques

dmaengine: dw: properly read DWC_PARAMS register

2015-10-28T10:33:11+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: Luis Henriques

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

2015-07-15T09:00:31+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 
[ luis: backported to 3.16:
  - function rename: mv_xor_slot_cleanup() -> __mv_xor_slot_cleanup()
  - adjusted context ]
Signed-off-by: Luis Henriques

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

2015-04-13T15:48:59+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: Luis Henriques

dmaengine: edma: fix memory leak when terminating running transfers

2015-04-13T15:48:58+00:00

commit 5ca9e7ce6eebec53362ff779264143860ccf68cd upstream.

If edma_terminate_all() was called while a transfer was running (i.e. after
edma_execute() but before edma_callback()) the echan->edesc was not freed.

This was due to the fact that a running transfer is on none of the
vchan lists: desc_submitted, desc_issued, desc_completed (edma_execute()
removes it from the desc_issued list), so the vchan_dma_desc_free_list()
called at the end of edma_terminate_all() didn't find it and didn't free it.

This bug was found on an AM1808 based hardware (very similar to da850evm,
however using the second MMC/SD controller), where intense operations on the SD
card wasted the device 128MB RAM within a couple of days.

Peter Ujfalusi:
The issue is even more severe since it affects cyclic (audio) transfers as
well. In this case starting/stopping audio will results memory leak.

Signed-off-by: Petr Kulhavy 
Signed-off-by: Peter Ujfalusi 
CC: 
Signed-off-by: Vinod Koul 
[ luis: backported to 3.16: adjusted context ]
Signed-off-by: Luis Henriques

dmaengine: dw: append MODULE_ALIAS for platform driver

2015-03-30T10:11:45+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: Luis Henriques

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

2014-10-05T20:41:11+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