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

dmaengine: dw: properly read DWC_PARAMS register

2015-10-28T02:13:05+00:00

[ Upstream commit 6bea0f6d1c47b07be88dfd93f013ae05fcb3d8bf ]

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: Sasha Levin

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

2015-07-04T03:02:28+00:00

[ Upstream commit 9136291f1dbc1d4d1cacd2840fb35f4f3ce16c46 ]

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 
Cc: stable@vger.kernel.org
Signed-off-by: Vinod Koul 
Signed-off-by: Sasha Levin

dmaengine: shdmac: avoid unused variable warnings

2015-06-28T17:39:26+00:00

[ Upstream commit 7d3beab16dd9eee86bb1a4dd05b51159fc7772f0 ]

This driver uses '#ifdef CONFIG_ARCH_SHMOBILE' and '#ifdef CONFIG_ARM'
interchangeably in its sh_dmae_probe function, which causes a build
warning when building for ARM without also enabling shmobile:

dma/sh/shdmac.c: In function sh_dmae_probe:
dma/sh/shdmac.c:696:6: warning: unused variable errirq [-Wunused-variable]
dma/sh/shdmac.c:695:16: warning: unused variable irqflags [-Wunused-variable]
dma/sh/shdmac.c: At top level:
dma/sh/shdmac.c:447:20: warning: sh_dmae_err defined but not used [-Wunused-function]

This changes all the #ifdef to test for CONFIG_ARCH_SHMOBILE to
avoid that warning. An earlier patch from Laurent had fixed the warning
for non-ARM case, but it still remained present in ARM randconfig builds.

Signed-off-by: Arnd Bergmann 
Fixes: 52d6a5ee101bf ("DMA: shdma: Fix warnings due to declared but unused symbols")
Acked-by: Laurent Pinchart 
Signed-off-by: Vinod Koul 
Signed-off-by: Sasha Levin

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

2015-04-24T21:13:54+00:00

[ Upstream commit 02d88b735f5a60f04dbf6d051b76e1877a0d0844 ]

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: 
CC: 
Signed-off-by: Vinod Koul 
Signed-off-by: Sasha Levin

dmaengine: edma: fix memory leak when terminating running transfers

2015-04-24T21:13:53+00:00

[ Upstream commit 5ca9e7ce6eebec53362ff779264143860ccf68cd ]

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: 
CC: 
Signed-off-by: Vinod Koul 
Signed-off-by: Sasha Levin

dmaengine: dw: append MODULE_ALIAS for platform driver

2015-04-17T00:11:45+00:00

[ Upstream commit a104a45ba7a51b5b4c5e8437020d9d48edf22f89 ]

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: Sasha Levin

Merge branch 'fixes' of git://git.infradead.org/users/vkoul/slave-dma

2014-11-22T00:24:27+00:00

Pull dmaengine fixes from Vinod Koul:
 "We have couple of fixes for dmaengine queued up:
   - dma mempcy fix for dma configuration of sun6i by Maxime
   - pl330 fixes: First the fixing allocation for data buffers by Liviu
     and then Jon's fixe for fifo width and usage"

* 'fixes' of git://git.infradead.org/users/vkoul/slave-dma:
  dmaengine: Fix allocation size for PL330 data buffer depth.
  dmaengine: pl330: Limit MFIFO usage for memcpy to avoid exhausting entries
  dmaengine: pl330: Align DMA memcpy operations to MFIFO width
  dmaengine: sun6i: Fix memcpy operation

dmaengine: Fix allocation size for PL330 data buffer depth.

2014-11-17T07:31:22+00:00

The datasheet for PL330 says that the data buffer value in the CRD
register is 10bits wide. However, the value stored is "minus one",
which the driver corrects for. Maximum value that the data buffer
depth can have is 1024 lines, which requires 11 bits for storage.

While making updates I found printing the peripheral ID as a hex
value to be more useful as the datasheet shows the values that way.

Signed-off-by: Liviu Dudau 
Signed-off-by: Vinod Koul

dmaengine: pl330: Limit MFIFO usage for memcpy to avoid exhausting entries

2014-11-17T07:31:20+00:00

The MFIFO is shared by all channels so restrict each memcpy to it's fair
share. This is being over cautious, but without a global view of DMA
channel usage on a system it's not possible to come up with a more
optimum safe limit.

Signed-off-by: Jon Medhurst 
Signed-off-by: Vinod Koul

dmaengine: pl330: Align DMA memcpy operations to MFIFO width

2014-11-17T07:31:09+00:00

The algorithm used for programming the DMA Controller doesn't take into
consideration the requirements of transfers that are not aligned to the
bus width. This failure may result in DMA transferring one too few MFIFO
entries (so too few bytes are copied) or the DMA trying to write one too
many MFIFO entries and hanging because this is never provided.

See "MFIFO Usage Overview" chapter in the the TRM for "CoreLink DMA
Controller DMA-330", Revision r1p1.

We work around these shortcomings by making sure we pick a burst size
and length which ensures no bursts straddle an MFIFO entry.

Signed-off-by: Jon Medhurst 
[squashed linker error "undefined reference to `__aeabi_uldivmod]
Reported-by: kbuild test robot 
Acked-by: Arnd Bergmann 
Signed-off-by: Vinod Koul