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

dmaengine: rcar-dmac: set scatter/gather max segment size

2019-11-24T07:20:30+00:00

[ Upstream commit 97d49c59e219acac576e16293a6b8cb99302f62f ]

Fix warning when running with CONFIG_DMA_API_DEBUG_SG=y by allocating a
device_dma_parameters structure and filling in the max segment size.

Signed-off-by: Wolfram Sang 
Signed-off-by: Vinod Koul 
Signed-off-by: Sasha Levin

dmaengine: ioat: fix prototype of ioat_enumerate_channels

2019-11-24T07:20:24+00:00

[ Upstream commit f4d34aa8c887a8a2d23ef546da0efa10e3f77241 ]

Signed-off-by: Rami Rosen 
Signed-off-by: Vinod Koul 
Signed-off-by: Sasha Levin

dmaengine: timb_dma: Use proper enum in td_prep_slave_sg

2019-11-24T07:19:46+00:00

[ Upstream commit 5e621f5d538985f010035c6f3e28c22829d36db1 ]

Clang warns when implicitly converting from one enumerated type to
another. Avoid this by using the equivalent value from the expected
type.

drivers/dma/timb_dma.c:548:27: warning: implicit conversion from
enumeration type 'enum dma_transfer_direction' to different enumeration
type 'enum dma_data_direction' [-Wenum-conversion]
                td_desc->desc_list_len, DMA_MEM_TO_DEV);
                                        ^~~~~~~~~~~~~~
1 warning generated.

Reported-by: Nick Desaulniers 
Signed-off-by: Nathan Chancellor 
Reviewed-by: Nick Desaulniers 
Signed-off-by: Vinod Koul 
Signed-off-by: Sasha Levin

dmaengine: at_xdmac: remove a stray bottom half unlock

2019-11-20T17:46:20+00:00

[ Upstream commit 0b515abb6b7eb08e90bdfc01fc8fbdd112c15d81 ]

We switched this code from spin_lock_bh() to vanilla spin_lock() but
there was one stray spin_unlock_bh() that was overlooked.  This
patch converts it to spin_unlock() as well.

Fixes: d8570d018f69 ("dmaengine: at_xdmac: move spin_lock_bh to spin_lock in tasklet")
Signed-off-by: Dan Carpenter 
Signed-off-by: Vinod Koul 
Signed-off-by: Sasha Levin

dmaengine: dma-jz4780: Further residue status fix

2019-11-20T17:46:17+00:00

[ Upstream commit 83ef4fb7556b6a673f755da670cbacab7e2c7f1b ]

Func jz4780_dma_desc_residue() expects the index to the next hw
descriptor as its last parameter. Caller func jz4780_dma_tx_status(),
however, applied modulus before passing it. When the current hw
descriptor was last in the list, the index passed became zero.

The resulting excess of reported residue especially caused problems
with cyclic DMA transfer clients, i.e. ALSA AIC audio output, which
rely on this for determining current DMA location within buffer.

Combined with the recent and related residue-reporting fixes, spurious
ALSA audio underruns on jz4770 hardware are now fixed.

Signed-off-by: Daniel Silsby 
Signed-off-by: Paul Cercueil 
Tested-by: Mathieu Malaterre 
Signed-off-by: Vinod Koul 
Signed-off-by: Sasha Levin

dmaengine: dma-jz4780: Don't depend on MACH_JZ4780

2019-11-20T17:46:16+00:00

[ Upstream commit c558ecd21c852c97ff98dc6c61f715ba420ec251 ]

If we make this driver depend on MACH_JZ4780, that means it can be
enabled only if we're building a kernel specially crafted for a
JZ4780-based board, while most GNU/Linux distributions will want one
generic MIPS kernel that works on multiple boards.

Signed-off-by: Paul Cercueil 
Signed-off-by: Vinod Koul 
Signed-off-by: Sasha Levin

dmaengine: sprd: Fix the possible memory leak issue

2019-11-12T18:20:54+00:00

[ Upstream commit ec1ac309596a7bdf206743b092748205f6cd5720 ]

If we terminate the channel to free all descriptors associated with this
channel, we will leak the memory of current descriptor if the current
descriptor is not completed, since it had been deteled from the desc_issued
list and have not been added into the desc_completed list.

Thus we should check if current descriptor is completed or not, when freeing
the descriptors associated with one channel, if not, we should free it to
avoid this issue.

Fixes: 9b3b8171f7f4 ("dmaengine: sprd: Add Spreadtrum DMA driver")
Reported-by: Zhenfang Wang 
Tested-by: Zhenfang Wang 
Signed-off-by: Baolin Wang 
Link: https://lore.kernel.org/r/170dbbc6d5366b6fa974ce2d366652e23a334251.1570609788.git.baolin.wang@linaro.org
Signed-off-by: Vinod Koul 
Signed-off-by: Sasha Levin

dmaengine: xilinx_dma: Fix control reg update in vdma_channel_set_config

2019-11-12T18:20:53+00:00

[ Upstream commit 6c6de1ddb1be3840f2ed5cc9d009a622720940c9 ]

In vdma_channel_set_config clear the delay, frame count and master mask
before updating their new values. It avoids programming incorrect state
when input parameters are different from default.

Signed-off-by: Radhey Shyam Pandey 
Acked-by: Appana Durga Kedareswara rao 
Signed-off-by: Michal Simek 
Link: https://lore.kernel.org/r/1569495060-18117-3-git-send-email-radhey.shyam.pandey@xilinx.com
Signed-off-by: Vinod Koul 
Signed-off-by: Sasha Levin

dmaengine: cppi41: Fix cppi41_dma_prep_slave_sg() when idle

2019-11-06T12:06:21+00:00

commit bacdcb6675e170bb2e8d3824da220e10274f42a7 upstream.

Yegor Yefremov  reported that musb and ftdi
uart can fail for the first open of the uart unless connected using
a hub.

This is because the first dma call done by musb_ep_program() must wait
if cppi41 is PM runtime suspended. Otherwise musb_ep_program() continues
with other non-dma packets before the DMA transfer is started causing at
least ftdi uarts to fail to receive data.

Let's fix the issue by waking up cppi41 with PM runtime calls added to
cppi41_dma_prep_slave_sg() and return NULL if still idled. This way we
have musb_ep_program() continue with PIO until cppi41 is awake.

Fixes: fdea2d09b997 ("dmaengine: cppi41: Add basic PM runtime support")
Reported-by: Yegor Yefremov 
Signed-off-by: Tony Lindgren 
Cc: stable@vger.kernel.org # v4.9+
Link: https://lore.kernel.org/r/20191023153138.23442-1-tony@atomide.com
Signed-off-by: Vinod Koul 
Signed-off-by: Greg Kroah-Hartman

dmaengine: qcom: bam_dma: Fix resource leak

2019-11-06T12:06:21+00:00

commit 7667819385457b4aeb5fac94f67f52ab52cc10d5 upstream.

bam_dma_terminate_all() will leak resources if any of the transactions are
committed to the hardware (present in the desc fifo), and not complete.
Since bam_dma_terminate_all() does not cause the hardware to be updated,
the hardware will still operate on any previously committed transactions.
This can cause memory corruption if the memory for the transaction has been
reassigned, and will cause a sync issue between the BAM and its client(s).

Fix this by properly updating the hardware in bam_dma_terminate_all().

Fixes: e7c0fe2a5c84 ("dmaengine: add Qualcomm BAM dma driver")
Signed-off-by: Jeffrey Hugo 
Cc: stable@vger.kernel.org
Link: https://lore.kernel.org/r/20191017152606.34120-1-jeffrey.l.hugo@gmail.com
Signed-off-by: Vinod Koul 
Signed-off-by: Greg Kroah-Hartman