linux-toradex.git/drivers/dma, branch v4.9.7

dmaengine: pl330: Fix runtime PM support for terminated transfers

2017-01-26T07:24:45+00:00

commit 5c9e6c2b2ba3ec3a442e2fb5b4286498f8b4dcb7 upstream.

PL330 DMA engine driver is leaking a runtime reference after any terminated
DMA transactions. This patch fixes this issue by tracking runtime PM state
of the device and making additional call to pm_runtime_put() in terminate_all
callback if needed.

Fixes: ae43b3289186 ("ARM: 8202/1: dmaengine: pl330: Add runtime Power Management support v12")
Signed-off-by: Marek Szyprowski 
Reviewed-by: Krzysztof Kozlowski 
Signed-off-by: Vinod Koul 
Signed-off-by: Greg Kroah-Hartman

dmaengine: rcar-dmac: unmap slave resource when channel is freed

2017-01-26T07:24:45+00:00

commit 3139dc8ded6f27552a248d23fe9f086e3027fa12 upstream.

The slave mapping should be removed together with other channel
resources when the channel is freed. If it's not unmapped it will hang
around forever after the channel is freed.

Fixes: 9f878603dbdb7db3 ("dmaengine: rcar-dmac: add iommu support for slave transfers")
Reported-by: Laurent Pinchart 
Signed-off-by: Niklas Söderlund 
Reviewed-by: Laurent Pinchart 
Signed-off-by: Vinod Koul 
Signed-off-by: Greg Kroah-Hartman

dmaengine: omap-dma: Fix dynamic lch_map allocation

2017-01-19T19:18:03+00:00

commit 836c3ce2566fb8c1754f8d7c9534cad9bc8a6879 upstream.

The original patch did not done what it was supposed to be doing and even
worst it broke legacy boot (OMAP1).

The lch_map size should be the number of available logical channels in sDMA
and the od->dma_requests should store the number of available DMA request
lines usable in sDMA.

In legacy mode we do not have a way to get the DMA request count, in that
case we use OMAP_SDMA_REQUESTS (127), despite the fact that OMAP1510 have
only 31 DMA request line.

Fixes: 2d1a9a946fae ("dmaengine: omap-dma: Dynamically allocate memory for lch_map")
Reported-by: Aaro Koskinen 
Signed-off-by: Peter Ujfalusi 
Tested-by: Aaro Koskinen 
Signed-off-by: Vinod Koul 
Signed-off-by: Greg Kroah-Hartman

dmaengine: cppi41: More PM runtime fixes

2016-11-17T10:39:23+00:00

Fix use of u32 instead of int for checking for negative errors values
as pointed out by Dan Carpenter .

And while testing the PM runtime error path by randomly returning
failed values in runtime resume, I noticed two more places that need
fixing:

- If pm_runtime_get_sync() fails in probe, we still need to do
  pm_runtime_put_sync() to keep the use count happy. We could call
  pm_runtime_put_noidle() on the error path, but we're just going
  to call pm_runtime_disable() after that so pm_runtime_put_sync()
  will do what we want

- We should print an error if pm_runtime_get_sync() fails in
  cppi41_dma_alloc_chan_resources() so we know where it happens

Reported-by: Dan Carpenter 
Fixes: 740b4be3f742 ("dmaengine: cpp41: Fix handling of error path")
Signed-off-by: Tony Lindgren 
Signed-off-by: Vinod Koul

dmaengine: cpp41: Fix handling of error path

2016-11-14T08:30:16+00:00

If we return early on pm_runtime_get() error, we need to also call
pm_runtime_put_noidle() as pointed out in a musb related thread
by Johan Hovold . This is to keep the PM runtime
use counts happy.

Fixes: fdea2d09b997 ("dmaengine: cppi41: Add basic PM runtime support")
Cc: Johan Hovold 
Signed-off-by: Tony Lindgren 
Signed-off-by: Vinod Koul

dmaengine: cppi41: Fix unpaired pm runtime when only a USB hub is connected

2016-11-14T05:27:32+00:00

On am335x with musb host we can end up with unpaired pm runtime calls
if a hub with no devices is connected and disconnected.

This is because of the conditional pm runtime calls which are always
a bad idea. Let's fix the issue by making them unconditional and
paired in each function.

Fixes: fdea2d09b997 ("dmaengine: cppi41: Add basic PM runtime support")
Signed-off-by: Tony Lindgren 
Signed-off-by: Vinod Koul

dmaengine: cppi41: Fix list not empty warning on module removal

2016-11-14T05:27:21+00:00

If musb controller is configured with USB peripherals and we have
enumerated with a USB host, we can get warnings on removal of the
modules:

WARNING: CPU: 0 PID: 1269 at drivers/dma/cppi41.c:391
cppi41_dma_free_chan_resources

Fix the issue by adding the missing pm_runtime_get to
cppi41_dma_free_chan_resources to make sure the pending work
list is cleared on removal.

Fixes: fdea2d09b997 ("dmaengine: cppi41: Add basic PM runtime support")
Signed-off-by: Tony Lindgren 
Signed-off-by: Vinod Koul

dmaengine: sun6i: fix the uninitialized value for v_lli

2016-11-14T05:05:58+00:00

dma_pool_alloc does not initialize the value of the newly allocated
block for the v_lli, and the uninitilize value make the tests failed
which is on pine64 with dmatest.
we can fix it just change the "|=" to "=" for the v_lli->cfg.

Signed-off-by: Hao Zhang 
Acked-by: Maxime Ripard 
Signed-off-by: Vinod Koul

dmaengine: mmp_tdma: add missing select GENERIC_ALLOCATOR in Kconfig

2016-10-18T15:02:56+00:00

There are some compilation errors when CONFIG_MMP_TDMA is enabled and
CONFIG_GENERIC_ALLOCATOR is disabled:

drivers/built-in.o: In function `mmp_tdma_prep_dma_cyclic':
mmp_tdma.c:(.text+0x7890e): undefined reference to `gen_pool_dma_alloc'
drivers/built-in.o: In function `mmp_tdma_free_chan_resources':
mmp_tdma.c:(.text+0x78aca): undefined reference to `gen_pool_free'
drivers/built-in.o: In function `mmp_tdma_probe':
mmp_tdma.c:(.text+0x78ea8): undefined reference to `of_gen_pool_get'

This commit fix this problem by selecting GENERIC_ALLOCATOR when
CONFIG_MMP_TDMA is enabled.

Signed-off-by: Jérémy Lefaure 
Signed-off-by: Vinod Koul

dmaengine: edma: Fix error return code in edma_alloc_chan_resources()

2016-10-18T14:48:14+00:00

Fix to return a negative error code from the error handling
case instead of 0, as done elsewhere in this function.

Signed-off-by: Wei Yongjun 
Signed-off-by: Vinod Koul