linux-stable.git/drivers/dma, branch v4.1.19

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

2016-03-04T15:25:43+00:00

[ Upstream commit ee1cdcdae59563535485a5f56ee72c894ab7d7ad ]

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

dmaengine: at_xdmac: fix resume for cyclic transfers

2016-02-03T21:23:19+00:00

[ Upstream commit 611dcadb01c89d1d3521450c05a4ded332e5a32d ]

When having cyclic transfers, the channel was paused when performing
suspend but was not correctly resumed.

Signed-off-by: Songjun Wu 
Signed-off-by: Ludovic Desroches 
Fixes: e1f7c9eee707 ("dmaengine: at_xdmac: creation of the atmel
eXtended DMA Controller driver")
Cc:  # 4.1 and later
Signed-off-by: Vinod Koul 

Signed-off-by: Sasha Levin

dmaengine: dw: fix cyclic transfer callbacks

2016-02-03T21:23:14+00:00

[ Upstream commit 2895b2cad6e7a95104cf396e5330054453382ae1 ]

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 
Cc: 
Signed-off-by: Sasha Levin

dmaengine: dw: fix cyclic transfer setup

2016-02-03T21:23:14+00:00

[ Upstream commit df3bb8a0e619d501cd13334c3e0586edcdcbc716 ]

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 
Cc: 
Signed-off-by: Sasha Levin

dmaengine: dw: properly read DWC_PARAMS register

2015-10-22T21:43:13+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: at_xdmac: fix transfer data width in at_xdmac_prep_slave_sg()

2015-08-17T03:52:16+00:00

commit 1c8a38b1268aebc1a903b21b11575077e02d2cf7 upstream.

This patch adds the missing update of the transfer data width in
at_xdmac_prep_slave_sg().

Indeed, for each item in the scatter-gather list, we check whether the
transfer length is aligned with the data width provided by
dmaengine_slave_config(). If so, we directly use this data width for the
current part of the transfer we are preparing. Otherwise, the data width
is reduced to 8 bits (1 byte). Of course, the actual number of register
accesses must also be updated to match the new data width.

So one chunk was missing in the original patch (see Fixes tag below): the
number of register accesses was correctly set to (len >> fixed_dwidth) in
mbr_ubc but the real data width was not updated in mbr_cfg. Since mbr_cfg
may change for each part of the scatter-gather transfer this also explains
why the original patch used the Descriptor View 2 instead of the
Descriptor View 1.

Let's take the example of a DMA transfer to write 8bit data into an Atmel
USART with FIFOs. When FIFOs are enabled in the USART, its Transmit
Holding Register (THR) works in multidata mode, that is to say that up to
4 8bit data can be written into the THR in a single 32bit access and it is
still possible to write only one data with a 8bit access. To take
advantage of this new feature, the DMA driver was modified to allow
multiple dwidths when doing slave transfers.
For instance, when the total length is 22 bytes, the USART driver splits
the transfer into 2 parts:

First part: 20 bytes transferred through 5 32bit writes into THR
Second part: 2 bytes transferred though 2 8bit writes into THR

For the second part, the data width was first set to 4_BYTES by the USART
driver thanks to dmaengine_slave_config() then at_xdmac_prep_slave_sg()
reduces this data width to 1_BYTE because the 2 byte length is not aligned
with the original 4_BYTES data width. Since the data width is modified,
the actual number of writes into THR must be set accordingly.

Signed-off-by: Cyrille Pitchen 
Fixes: 6d3a7d9e3ada ("dmaengine: at_xdmac: allow muliple dwidths when doing slave transfers")
Cc: stable@vger.kernel.org #4.0 and later
Acked-by: Nicolas Ferre 
Acked-by: Ludovic Desroches 
Signed-off-by: Vinod Koul 
Signed-off-by: Greg Kroah-Hartman

dmaengine: pl330: Really fix choppy sound because of wrong residue calculation

2015-08-17T03:52:11+00:00

commit 5dd90e5b91e0f5c925b12b132c7cd27538870256 upstream.

When pl330 driver was used during sound playback, after some time or
after a number of plays the sound became choppy or totally noisy. For
example on Odroid XU3 board the first four executions of aplay with
small WAVE worked fine, but fifth was unrecognizable with errors:
	$ aplay /usr/share/sounds/alsa/Front_Right.wava
	underrun!!! (at least 0.095 ms long)

Issue was caused by wrong residue reported by pl330 driver to
pcm_dmaengine for its cyclic dma transfers.

The pl330_tx_status(), residue reporting function, used a "last" flag in
a descriptor to indicate that there is no more data to send.

The pl330_tx_submit() iterated over descriptors trying to remove this
flag from them and then mark last descriptor as "last".  However when
iterating it actually removed the flag not from descriptors but always
from last of it (and then reset it). Thus effectively once some
descriptor was marked as last, then it stayed like this forever causing
residue to be reported too low.

Signed-off-by: Krzysztof Kozlowski 
Fixes: aee4d1fac887 ("dmaengine: pl330: improve pl330_tx_status() function")
Reported-by: gabriel@unseen.is
Suggested-by: Marek Szyprowski 
Tested-by: Lars-Peter Clausen 
Signed-off-by: Vinod Koul 
Signed-off-by: Greg Kroah-Hartman

dmaengine: pl330: Fix overflow when reporting residue in memcpy

2015-08-17T03:52:11+00:00

commit ae128293d97404f491dc76f1843c7adacfec3441 upstream.

During memcpy operations the residue was always set to an u32 overflowed
value.

In pl330_tx_status() function number of currently transferred bytes was
subtracted from internal "bytes_requested" field. However this
"bytes_requested" was not initialized at start to length of memcpy
buffer so transferred bytes were subtracted from 0 causing overflow.

Signed-off-by: Krzysztof Kozlowski 
Fixes: aee4d1fac887 ("dmaengine: pl330: improve pl330_tx_status() function")
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:12+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: Fix choppy sound because of unimplemented resume

2015-06-12T09:52:26+00:00

Some drivers implement only pause operation (no resuming). Example is
pl330 where pause is needed for getting residuum. pl330 does not support
resume operation, transfer must be stopped after pause.

However for slaves this is exposed always as "pause and resume" which
introduces subtle errors on Odroid U3 board (Exynos4412 with pl330).
After adding pause function to pl330 driver the audio playback
(utilizing DMA) gets choppy after some time (approximately 24 hours).

Fix this by exposing "cmd_pause" if and only if pause and resume are
implemented.

Signed-off-by: Krzysztof Kozlowski 
Reported-by: gabriel@unseen.is
Reported-by: Marek Szyprowski 
Cc: 
Fixes: 88987d2c7534 ("dmaengine: pl330: add DMA_PAUSE feature")
Acked-by: Maxime Ripard 
Signed-off-by: Vinod Koul