- 25 Feb, 2020 22 commits
-
-
Dmitry Osipenko authored
The ISR tasklet could be kept scheduled after DMA transfer termination, let's add synchronization hook which blocks until tasklet is finished. Signed-off-by:
Dmitry Osipenko <digetx@gmail.com> Acked-by:
Jon Hunter <jonathanh@nvidia.com> Link: https://lore.kernel.org/r/20200209163356.6439-4-digetx@gmail.comSigned-off-by:
Vinod Koul <vkoul@kernel.org>
-
Peter Ujfalusi authored
Add basic interleaved support via EDMA. Signed-off-by:
Peter Ujfalusi <peter.ujfalusi@ti.com> Link: https://lore.kernel.org/r/20200210094455.3615-1-peter.ujfalusi@ti.comSigned-off-by:
-
Tudor Ambarus authored
Tasklets run with all the interrupts enabled. This means that we should replace all the (already present) spin_lock_irqsave() uses in the tasklet with spin_lock_irq() to protect being interrupted by a IRQ which tries to get the same lock (via calls to device_prep_dma_* for example). spin_lock and spin_lock_bh in tasklets are not enough to protect from IRQs, update these to spin_lock_irq(). at_xdmac_advance_work() can be called with all the interrupts enabled (when called from tasklet), or with interrupts disabled (when called from at_xdmac_issue_pending). Move the locking in the callers to be able to use spin_lock_irq() and spin_lock_irqsave() for these cases. Signed-off-by:
Tudor Ambarus <tudor.ambarus@microchip.com> Acked-by:
Ludovic Desroches <ludovic.desroches@microchip.com> Link: https://lore.kernel.org/r/20200123140237.125799-10-tudor.ambarus@microchip.comSigned-off-by:
-
Tudor Ambarus authored
device_alloc_chan_resources can sleep, use GFP_KERNEL flag. Signed-off-by:
-
Tudor Ambarus authored
There is no need for locking in device_alloc_chan_resources(), the DMA core takes care of it by using a dma_list_mutex around the DMA devices. Signed-off-by:
-
Tudor Ambarus authored
The code in cause is already in the else case of 'if (at_xdmac_chan_is_cyclic(atchan))', drop the redundant check. Signed-off-by:
-
Tudor Ambarus authored
Fix the following deadlocks: 1/ atc_handle_cyclic() and atc_chain_complete() called dmaengine_desc_get_callback_invoke() while wrongly holding the atchan->lock. Clients can set the callback to dmaengine_terminate_sync() which will end up trying to get the same lock, thus a deadlock occurred. 2/ dma_run_dependencies() was called with the atchan->lock held, but the method calls device_issue_pending() which tries to get the same lock, and so a deadlock occurred. The driver must not hold the lock when invoking the callback or when running dependencies. Releasing the spinlock within a called function before calling the callback is not a nice thing to do -> called functions become non-atomic when called within an atomic region. Thus the lock is now taken in the child routines whereever is needed. Signed-off-by:
-
Tudor Ambarus authored
Avoids sleeping without depleting the emergency pool. The rationale being that in most cases a dma device is either offloading an operation that will automatically fallback to software when the descriptor allocation fails, or we can simply poll and wait for the dma device to release some in use descriptors. Signed-off-by:
-
Tudor Ambarus authored
Probably a leftover, drop it. Signed-off-by:
-
Tudor Ambarus authored
Having a list of descriptors allocated for the channel at device_alloc_chan_resources() time is a sign for bad free usage. Return err and add a debug message in case the channel is not free from a previous use. atchan->descs_allocated becomes useless, get rid of it. More, drop the error message in atc_desc_get() because now it would introduce an extra if statement. The callers of atc_desc_get() already print error messages in case the callee fails, no one is hurt. Signed-off-by:
-
Tudor Ambarus authored
There is no need for locking in device_alloc_chan_resources(), the DMA core takes care of it by using a dma_list_mutex around the DMA devices. Signed-off-by:
-
Tudor Ambarus authored
All members of the structure are initialized below in the function, there is no need to use kzalloc. Signed-off-by:
-
Radhey Shyam Pandey authored
In overlay application we noticed that dma channel node probe order is inverted i.e s2mm channel is probed first followed by mm2s channel. The reason for this inversion is fdtoverlay utility which uses a function called fdt_add_subnode(*). It stores the subnodes after the properties, this has the effect of inserting the new subnode before any others and the end result is a reversal. Because of this inverted channel probe order, the node probed first is assigned a '0' index instead of Channel ID should be '0' for tx and '1' for rx and dmatest client using the DT convention fails in dma transfer as channel are swapped. To fix above behavior and make channel assignment index independent of probe order, always assign mm2s channel at '0' index and the s2mm channel at IP specific fixed offset derived from the max_channels count. Signed-off-by:
Radhey Shyam Pandey <radhey.shyam.pandey@xilinx.com> Link: https://lore.kernel.org/r/1580388865-9960-3-git-send-email-radhey.shyam.pandey@xilinx.comSigned-off-by:
-
Radhey Shyam Pandey authored
Extend dma_config structure to store the max channel count. This input is used to populate dma device channel nodes at the fixed offset. It serves as a preparatory patch for removing dma channel DT node order dependency, added in the subsequent commit. Signed-off-by:
-
Amelie Delaunay authored
To avoid race with vchan_complete, use the race free way to terminate running transfer. Move vdesc->node list_del in stm32_dma_start_transfer instead of in stm32_mdma_chan_complete to avoid another race in vchan_dma_desc_free_list. Signed-off-by:
Amelie Delaunay <amelie.delaunay@st.com> Link: https://lore.kernel.org/r/20200129153628.29329-9-amelie.delaunay@st.comSigned-off-by:
-
Amelie Delaunay authored
This patch fixes BUG: sleeping function called from invalid context in stm32_dma_disable_chan function. The goal of this function is to force channel disable if it has not been disabled by hardware. This consists in clearing STM32_DMA_SCR_EN bit and read it as 0 to ensure the channel is well disabled and the last transfer is over. In previous implementation, the waiting loop was based on a do...while (1) with a call to cond_resched to give the scheduler a chance to run a higher priority process. But in some conditions, stm32_dma_disable_chan can be called while preemption is disabled, on a stm32_dma_stop call for example. So cond_resched must not be used. To avoid this, use readl_relaxed_poll_timeout_atomic to poll STM32_DMA_SCR_EN bit cleared. Signed-off-by:
-
Amelie Delaunay authored
This patch adds copy_align property in accordance with hardware restriction. Signed-off-by:
Ludovic Barre <ludovic.barre@st.com> Signed-off-by:
-
Amelie Delaunay authored
This patch adds dma_set_max_seg_size to define sg dma constraint. This constraint may be taken into account by client to scatter/gather its buffer. Signed-off-by:
-
Pierre-Yves MORDRET authored
Enable client to resubmit already processed descriptors in order to save descriptor creation time. Signed-off-by:
Pierre-Yves MORDRET <pierre-yves.mordret@st.com> Signed-off-by:
-
Etienne Carriere authored
Change STM32 DMA driver to defer its probe operation when reset controller is expected but has not been probed yet when DMA device is probed. Changes error traces when failing to get a system resource so that it is not printed on failure with deferred probing. Signed-off-by:
Etienne Carriere <etienne.carriere@st.com> Signed-off-by:
-
Etienne Carriere authored
Remove reset controller reference from device instance since it is used only at probe time. Signed-off-by:
-
Pierre-Yves MORDRET authored
Add suspend/resume power management relying on PM Runtime engine. Signed-off-by:
-
- 24 Feb, 2020 11 commits
-
-
Radhey Shyam Pandey authored
Reset DMA channel after stop to ensure that pending transfers and FIFOs in the datapath are flushed or completed. It also cleanup the terminate path and removes stop for the cyclic mode as after the reset stop is not required. This fixes intermittent data verification failure when xilinx dma test the client is stressed and loaded/unloaded multiple times. Signed-off-by:
-
Etienne Carriere authored
Changes STM32 DMAMUX driver to defer its probe operation when reset controller is expected but has not been probed yet. Changes error traces when failing to get a system resource so that it is not printed on failure with deferred probing. Signed-off-by:
-
Etienne Carriere authored
Remove reset controller reference from device instance since it is used only at probe time. Signed-off-by:
-
Etienne Carriere authored
This change ensures the DMAMUX device is reset only once it is clocked and that clock is released in a safe state when probe operation fails. Signed-off-by:
-
Pierre-Yves MORDRET authored
Add suspend/resume power management relying on PM Runtime engine. Signed-off-by:
-
Amelie Delaunay authored
To avoid race with vchan_complete, use the race free way to terminate running transfer. Move vdesc->node list_del in stm32_mdma_start_transfer instead of in stm32_mdma_xfer_end to avoid another race in vchan_dma_desc_free_list. Signed-off-by:
-
Pierre-Yves MORDRET authored
Enable descriptor reuse to allow client to resubmit already processed descriptors in order to save descriptor creation time. Signed-off-by:
-
Amelie Delaunay authored
This patch changes error log when failing to get the clock so that it is not printed on failure with probe deferring. It also defers probe when reset controller is expected but has not been probed yet when MDMA device is probed. Signed-off-by:
-
Etienne Carriere authored
This patch disables the clock in case of error during probe. The unneeded err_unregister label is renamed err_clk instead. Signed-off-by:
-
Etienne Carriere authored
Remove reset controller reference from device instance since it is used only at probe time. Signed-off-by:
-
Pierre-Yves MORDRET authored
Add suspend/resume power management relying on PM Runtime engine. Signed-off-by:
-
- 19 Feb, 2020 4 commits
-
-
Gustavo A. R. Silva authored
The current codebase makes use of the zero-length array language extension to the C90 standard, but the preferred mechanism to declare variable-length types such as these ones is a flexible array member[1][2], introduced in C99: struct foo { int stuff; struct boo array[]; }; By making use of the mechanism above, we will get a compiler warning in case the flexible array does not occur last in the structure, which will help us prevent some kind of undefined behavior bugs from being inadvertently introduced[3] to the codebase from now on. Also, notice that, dynamic memory allocations won't be affected by this change: "Flexible array members have incomplete type, and so the sizeof operator may not be applied. As a quirk of the original implementation of zero-length arrays, sizeof evaluates to zero."[1] This issue was found with the help of Coccinelle. [1] https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html [2] https://github.com/KSPP/linux/issues/21 [3] commit 76497732 ("cxgb3/l2t: Fix undefined behaviour") Signed-off-by:Gustavo A. R. Silva <gustavo@embeddedor.com> Link: https://lore.kernel.org/r/20200214171302.GA20586@embeddedorSigned-off-by:
-
Gustavo A. R. Silva authored
The current codebase makes use of the zero-length array language extension to the C90 standard, but the preferred mechanism to declare variable-length types such as these ones is a flexible array member[1][2], introduced in C99: struct foo { int stuff; struct boo array[]; }; By making use of the mechanism above, we will get a compiler warning in case the flexible array does not occur last in the structure, which will help us prevent some kind of undefined behavior bugs from being inadvertently introduced[3] to the codebase from now on. Also, notice that, dynamic memory allocations won't be affected by this change: "Flexible array members have incomplete type, and so the sizeof operator may not be applied. As a quirk of the original implementation of zero-length arrays, sizeof evaluates to zero."[1] This issue was found with the help of Coccinelle. [1] https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html [2] https://github.com/KSPP/linux/issues/21 [3] commit 76497732 ("cxgb3/l2t: Fix undefined behaviour") Signed-off-by: -
Gustavo A. R. Silva authored
The current codebase makes use of the zero-length array language extension to the C90 standard, but the preferred mechanism to declare variable-length types such as these ones is a flexible array member[1][2], introduced in C99: struct foo { int stuff; struct boo array[]; }; By making use of the mechanism above, we will get a compiler warning in case the flexible array does not occur last in the structure, which will help us prevent some kind of undefined behavior bugs from being inadvertently introduced[3] to the codebase from now on. Also, notice that, dynamic memory allocations won't be affected by this change: "Flexible array members have incomplete type, and so the sizeof operator may not be applied. As a quirk of the original implementation of zero-length arrays, sizeof evaluates to zero."[1] This issue was found with the help of Coccinelle. [1] https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html [2] https://github.com/KSPP/linux/issues/21 [3] commit 76497732 ("cxgb3/l2t: Fix undefined behaviour") Signed-off-by:Baolin Wang <baolin.wang7@gmail.com> Link: https://lore.kernel.org/r/20200214171536.GA24077@embeddedorSigned-off-by:
-
Gustavo A. R. Silva authored
The current codebase makes use of the zero-length array language extension to the C90 standard, but the preferred mechanism to declare variable-length types such as these ones is a flexible array member[1][2], introduced in C99: struct foo { int stuff; struct boo array[]; }; By making use of the mechanism above, we will get a compiler warning in case the flexible array does not occur last in the structure, which will help us prevent some kind of undefined behavior bugs from being inadvertently introduced[3] to the codebase from now on. Also, notice that, dynamic memory allocations won't be affected by this change: "Flexible array members have incomplete type, and so the sizeof operator may not be applied. As a quirk of the original implementation of zero-length arrays, sizeof evaluates to zero."[1] This issue was found with the help of Coccinelle. [1] https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html [2] https://github.com/KSPP/linux/issues/21 [3] commit 76497732 ("cxgb3/l2t: Fix undefined behaviour") Signed-off-by:
-
- 17 Feb, 2020 1 commit
-
-
Vinod Koul authored
Commit 6ebb827f ("dmaengine: sun4i: use 'linear_mode' in sun4i_dma_prep_dma_cyclic") updated the condition but introduced a semi colon this making this statement have no effect, so add the bitwise OR to fix it" Fixes: 6ebb827f ("dmaengine: sun4i: use 'linear_mode' in sun4i_dma_prep_dma_cyclic") Reported-by:
Stephen Rothwell <sfr@canb.auug.org.au> Link: https://lore.kernel.org/r/20200214044609.2215861-1-vkoul@kernel.orgSigned-off-by:
-
- 13 Feb, 2020 2 commits
-
-
chenqiwu authored
Use a new API devm_platform_ioremap_resource() to simplify code. Signed-off-by:
chenqiwu <chenqiwu@xiaomi.com> Acked-by:
-
YueHaibing authored
drivers/dma/sun4i-dma.c: In function sun4i_dma_prep_dma_cyclic: drivers/dma/sun4i-dma.c:672:24: warning: variable linear_mode set but not used [-Wunused-but-set-variable] commit ffc079a4 ("dmaengine: sun4i: Add support for cyclic requests with dedicated DMA") involved this, explicitly using the value makes the code more readable. Reported-by:
Hulk Robot <hulkci@huawei.com> Signed-off-by:
YueHaibing <yuehaibing@huawei.com> Link: https://lore.kernel.org/r/20200207024445.44600-1-yuehaibing@huawei.comSigned-off-by:
-
