user/sven/linux.git/drivers/dma, branch v4.1.6

dmaengine: at_xdmac: fix transfer data width in at_xdmac_prep_slave_sg()

2015-08-17T03:52:16Z

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:11Z

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:11Z

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:12Z

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:26Z

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

dmaengine: at_xdmac: rework slave configuration part

2015-06-08T10:57:09Z

Rework slave configuration part in order to more report wrong errors about the configuration. Only maxburst and addr width values are checked when doing the slave configuration. The validity of the channel configuration is done at prepare time. Signed-off-by: Ludovic Desroches Cc: stable@vger.kernel.org # 4.0 and later Signed-off-by: Vinod Koul

dmaengine: at_xdmac: lock fixes

2015-06-08T10:57:09Z

Using _bh variant for spin locks causes this kind of warning: Starting logging: ------------[ cut here ]------------ WARNING: CPU: 0 PID: 3 at /ssd_drive/linux/kernel/softirq.c:151 __local_bh_enable_ip+0xe8/0xf4() Modules linked in: CPU: 0 PID: 3 Comm: ksoftirqd/0 Not tainted 4.1.0-rc2+ #94 Hardware name: Atmel SAMA5 [] (unwind_backtrace) from [] (show_stack+0x10/0x14) [] (show_stack) from [] (warn_slowpath_common+0x80/0xac) [] (warn_slowpath_common) from [] (warn_slowpath_null+0x1c/0x24) [] (warn_slowpath_null) from [] (__local_bh_enable_ip+0xe8/0xf4) [] (__local_bh_enable_ip) from [] (at_xdmac_device_terminate_all+0xf4/0x100) [] (at_xdmac_device_terminate_all) from [] (atmel_complete_tx_dma+0x34/0xf4) [] (atmel_complete_tx_dma) from [] (at_xdmac_tasklet+0x14c/0x1ac) [] (at_xdmac_tasklet) from [] (tasklet_action+0x68/0xb4) [] (tasklet_action) from [] (__do_softirq+0xfc/0x238) [] (__do_softirq) from [] (run_ksoftirqd+0x28/0x34) [] (run_ksoftirqd) from [] (smpboot_thread_fn+0x138/0x18c) [] (smpboot_thread_fn) from [] (kthread+0xdc/0xf0) [] (kthread) from [] (ret_from_fork+0x14/0x34) ---[ end trace b57b14a99c1d8812 ]--- It comes from the fact that devices can called some code from the DMA controller with irq disabled. _bh variant is not intended to be used in this case since it can enable irqs. Switch to irqsave/irqrestore variant to avoid this situation. Signed-off-by: Ludovic Desroches Cc: stable@vger.kernel.org # 4.0 and later Signed-off-by: Vinod Koul

dmaengine: hsu: Fix memory leak when stopping a running transfer

2015-06-02T13:03:08Z

The vd->node is removed from the lists when the transfer started so the vchan_get_all_descriptors() will not find it. This results memory leak. Signed-off-by: Peter Ujfalusi [andy: fix the typo to prevent a compilation error] Signed-off-by: Andy Shevchenko Signed-off-by: Vinod Koul

dmaengine: pl330: Fix hang on dmaengine_terminate_all on certain boards

2015-05-22T12:31:03Z

The pl330 device could hang infinitely on certain boards when DMA channels are terminated. It was caused by lack of runtime resume when executing pl330_terminate_all() which calls the _stop() function. _stop() accesses device register and can loop infinitely while checking for device state. The hang was confirmed by Dinh Nguyen on Altera SOCFPGA Cyclone V board during boot. It can be also triggered with: $ echo 1 > /sys/module/dmatest/parameters/iterations $ echo dma1chan0 > /sys/module/dmatest/parameters/channel $ echo 1 > /sys/module/dmatest/parameters/run $ sleep 1 $ cat /sys/module/dmatest/parameters/run Reported-by: Dinh Nguyen Signed-off-by: Krzysztof Kozlowski Fixes: ae43b3289186 ("ARM: 8202/1: dmaengine: pl330: Add runtime Power Management support v12") Cc: Tested-by: Dinh Nguyen Signed-off-by: Vinod Koul

dmaengine: increment privatecnt when using dma_get_any_slave_channel

2015-04-29T11:17:57Z

Channels allocated via dma_get_any_slave_channel were not increasing the counter tracking private allocations. When these channels were released, privatecnt may erroneously fall to zero. The DMA device would then lose its DMA_PRIVATE cap and fail to allocate future private channels (via private_candidate) as any allocations still outstanding would incorrectly be seen as public allocations. Signed-off-by: Christopher Freeman Signed-off-by: Vinod Koul