linux-toradex.git/drivers/dma, branch v4.10-rc7

dmaengine: pl330: fix double lock

2017-01-25T10:05:11+00:00

The static bug finder EBA (http://www.iagoabal.eu/eba/) reported the
following double-lock bug:

    Double lock:
    1. spin_lock_irqsave(pch->lock, flags) at pl330_free_chan_resources:2236;
    2. call to function `pl330_release_channel' immediately after;
    3. call to function `dma_pl330_rqcb' in line 1753;
    4. spin_lock_irqsave(pch->lock, flags) at dma_pl330_rqcb:1505.

I have fixed it as suggested by Marek Szyprowski.

First, I have replaced `pch->lock' with `pl330->lock' in functions
`pl330_alloc_chan_resources' and `pl330_free_chan_resources'. This avoids
the double-lock by acquiring a different lock than `dma_pl330_rqcb'.

NOTE that, as a result, `pl330_free_chan_resources' executes
`list_splice_tail_init' on `pch->work_list' under lock `pl330->lock',
whereas in the rest of the code `pch->work_list' is protected by
`pch->lock'. I don't know if this may cause race conditions. Similarly
`pch->cyclic' is written by `pl330_alloc_chan_resources' under
`pl330->lock' but read by `pl330_tx_submit' under `pch->lock'.

Second, I have removed locking from `pl330_request_channel' and
`pl330_release_channel' functions. Function `pl330_request_channel' is
only called from `pl330_alloc_chan_resources', so the lock is already
held. Function `pl330_release_channel' is called from
`pl330_free_chan_resources', which already holds the lock, and from
`pl330_del'. Function `pl330_del' is called in an error path of
`pl330_probe' and at the end of `pl330_remove', but I assume that there
cannot be concurrent accesses to the protected data at those points.

Signed-off-by: Iago Abal 
Reviewed-by: Marek Szyprowski 
Signed-off-by: Vinod Koul

dmaengine: cppi41: Clean up pointless warnings

2017-01-25T06:00:50+00:00

With patches "dmaengine: cppi41: Fix runtime PM timeouts with USB mass
storage", and "dmaengine: cppi41: Fix oops in cppi41_runtime_resume",
the pm_runtime_get/put() in cppi41_irq() is no longer needed. We now
guarantee that cppi41 is enabled when dma is in use.

We can still get pointless error -115 when musb is configured as a
usb peripheral. That's because we should now check for the state of
is_suspended instead.

Let's just remove the now useless code and replace it with a WARN().

Signed-off-by: Tony Lindgren 
Signed-off-by: Vinod Koul

dmaengine: cppi41: Fix oops in cppi41_runtime_resume

2017-01-25T05:59:22+00:00

Commit fdea2d09b997 ("dmaengine: cppi41: Add basic PM runtime support")
together with recent MUSB changes allowed USB and DMA on BeagleBone to idle
when no cable is connected. But looks like few corner case issues still
remain.

Looks like just by re-plugging USB cable about ten or so times on BeagleBone
when configured in USB peripheral mode we can get warnings and eventually
trigger an oops in cppi41 DMA:

WARNING: CPU: 0 PID: 14 at drivers/dma/cppi41.c:1154 cppi41_runtime_suspend+
x28/0x38 [cppi41]
...

WARNING: CPU: 0 PID: 14 at drivers/dma/cppi41.c:452
push_desc_queue+0x94/0x9c [cppi41]
...

Unable to handle kernel NULL pointer dereference at virtual
address 00000104
pgd = c0004000
[00000104] *pgd=00000000
Internal error: Oops: 805 [#1] SMP ARM
...
[] (cppi41_runtime_resume [cppi41]) from []
(__rpm_callback+0xc0/0x214)
[] (__rpm_callback) from [] (rpm_callback+0x20/0x80)
[] (rpm_callback) from [] (rpm_resume+0x504/0x78c)
[] (rpm_resume) from [] (pm_runtime_work+0x60/0xa8)
[] (pm_runtime_work) from [] (process_one_work+0x2b4/0x808)

This is because of a race with runtime PM and cppi41_dma_issue_pending()
as reported by Alexandre Bailon  in earlier
set of patches. Based on mailing list discussions we however came to the
conclusion that a different fix from Alexandre's fix is needed in order
to guarantee that DMA is really active when we try to use it.

To fix the issue, we need to add a driver specific flag as we otherwise
can have -EINPROGRESS state set by runtime PM and can't rely on
pm_runtime_active() to tell us when we can use the DMA.

And we need to make sure the DMA transfers get triggered in the queued
order. So let's always queue the transfers, then flush the queue
from both cppi41_dma_issue_pending() and cppi41_runtime_resume()
as suggested by Grygorii Strashko  in an
earlier example patch.

For reference, this is also documented in Documentation/power/runtime_pm.txt
in the example at the end of the file as pointed out by Grygorii Strashko
.

Based on earlier patches from Alexandre Bailon 
and Grygorii Strashko  modified based on
testing and what was discussed on the mailing lists.

Fixes: fdea2d09b997 ("dmaengine: cppi41: Add basic PM runtime support")
Cc: Andy Shevchenko 
Cc: Bin Liu 
Cc: Grygorii Strashko 
Cc: Kevin Hilman 
Cc: Patrick Titiano 
Cc: Sergei Shtylyov 
Reported-by: Alexandre Bailon 
Signed-off-by: Tony Lindgren 
Tested-by: Bin Liu 
Signed-off-by: Vinod Koul

dmaengine: cppi41: Fix runtime PM timeouts with USB mass storage

2017-01-25T05:59:11+00:00

Commit fdea2d09b997 ("dmaengine: cppi41: Add basic PM runtime support")
added runtime PM support for cppi41, but had corner case issues. Some of
the issues were fixed with commit 098de42ad670 ("dmaengine: cppi41: Fix
unpaired pm runtime when only a USB hub is connected"). That fix however
caused a new regression where we can get error -115 messages with USB on
BeagleBone when connecting a USB mass storage device to a hub.

This is because when connecting a USB mass storage device to a hub, the
initial DMA transfers can take over 200ms to complete and cppi41
autosuspend delay times out.

To fix the issue, we want to implement refcounting for chan_busy array
that contains the active dma transfers. Increasing the autosuspend delay
won't help as that the delay could be potentially seconds, and it's best
to let the USB subsystem to deal with the timeouts on errors.

The earlier attempt for runtime PM was buggy as the pm_runtime_get/put()
calls could get unpaired easily as they did not follow the state of
the chan_busy array as described in commit 098de42ad670 ("dmaengine:
cppi41: Fix unpaired pm runtime when only a USB hub is connected".

Let's fix the issue by adding pm_runtime_get() to where a new transfer
is added to the chan_busy array, and calls to pm_runtime_put() where
chan_busy array entry is cleared. This prevents any autosuspend timeouts
from happening while dma transfers are active.

Fixes: 098de42ad670 ("dmaengine: cppi41: Fix unpaired pm runtime when
only a USB hub is connected")
Fixes: fdea2d09b997 ("dmaengine: cppi41: Add basic PM runtime support")
Cc: Andy Shevchenko 
Cc: Bin Liu 
Cc: Grygorii Strashko 
Cc: Kevin Hilman 
Cc: Patrick Titiano 
Cc: Sergei Shtylyov 
Signed-off-by: Tony Lindgren 
Tested-by: Bin Liu 
Signed-off-by: Vinod Koul

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

2017-01-13T06:44:28+00:00

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

dmaengine: omap-dma: Fix the port_window support

2017-01-10T05:38:01+00:00

We do not yet have users of port_window. The following errors were found
when converting the tusb6010_omap.c musb driver:

- The peripheral side must have SRC_/DST_PACKED disabled
- when configuring the burst for the peripheral side the memory side
  configuration were overwritten: d->csdp = ... -> d->csdp |= ...
- The EI and FI were configured for the wrong sides of the transfers.

With these changes and the converted tus6010_omap.c I was able to verify
that things are working as they expected to work.

Fixes: 201ac4861c19 ("dmaengine: omap-dma: Support for slave devices with data port window")
Signed-off-by: Peter Ujfalusi 
Signed-off-by: Vinod Koul

dmaengine: iota: ioat_alloc_chan_resources should not perform sleeping allocations.

2017-01-10T05:11:51+00:00

On a kernel with DEBUG_LOCKS, ioat_free_chan_resources triggers an
in_interrupt() warning.  With PROVE_LOCKING, it reports detecting a
SOFTIRQ-safe to SOFTIRQ-unsafe lock ordering in the same code path.

This is because dma_generic_alloc_coherent() checks if the GFP flags
permit blocking.  It allocates from different subsystems if blocking is
permitted.  The free path knows how to return the memory to the correct
allocator.  If GFP_KERNEL is specified then the alloc and free end up
going through cma_alloc(), which uses mutexes.

Given that ioat_free_chan_resources() can be called in interrupt
context, ioat_alloc_chan_resources() must specify GFP_NOWAIT so that the
allocations do not block and instead use an allocator that uses
spinlocks.

Signed-off-by: Krister Johansen 
Acked-by: Dave Jiang 
Signed-off-by: Vinod Koul

dmaengine: pl330: Fix runtime PM support for terminated transfers

2017-01-03T03:48:13+00:00

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

dmaengine: omap-dma: Fix dynamic lch_map allocation

2017-01-03T03:40:15+00:00

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 
Cc: stable@vger.kernel.org   # v4.9
Signed-off-by: Peter Ujfalusi 
Tested-by: Aaro Koskinen 
Signed-off-by: Vinod Koul

dmaengine: ti-dma-crossbar: Add some 'of_node_put()' in error path.

2017-01-02T05:07:26+00:00

Add some missing 'of_node_put()' in early exit error path.

Signed-off-by: Christophe JAILLET 
Signed-off-by: Vinod Koul