diff options
author | 2019-10-23 08:31:38 -0700 | |
---|---|---|
committer | 2019-10-23 21:15:21 +0530 | |
commit | bacdcb6675e170bb2e8d3824da220e10274f42a7 (patch) | |
tree | cec456f7693c0ec24b38acc8a15fda8d45db7d9b /mm | |
parent | dmaengine: qcom: bam_dma: Fix resource leak (diff) | |
download | linux-bacdcb6675e170bb2e8d3824da220e10274f42a7.tar.gz linux-bacdcb6675e170bb2e8d3824da220e10274f42a7.tar.bz2 linux-bacdcb6675e170bb2e8d3824da220e10274f42a7.zip |
dmaengine: cppi41: Fix cppi41_dma_prep_slave_sg() when idle
Yegor Yefremov <yegorslists@googlemail.com> 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 <yegorslists@googlemail.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
Cc: stable@vger.kernel.org # v4.9+
Link: https://lore.kernel.org/r/20191023153138.23442-1-tony@atomide.com
Signed-off-by: Vinod Koul <vkoul@kernel.org>
Diffstat (limited to 'mm')
0 files changed, 0 insertions, 0 deletions