- 02 Mar, 2020 7 commits
-
-
Peter Ujfalusi authored
In UDMA each channel can use different ATYPE value which tells UDMA how the addresses in the descriptors should be treated: 0: pointers are physical addresses (no translation) 1: pointers are intermediate addresses (PVU) 2: pointers are virtual addresses (SMMU) When virtualized environment is used then the dma binding should use additional cell to configure the desired ATYPE for the channel. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Reviewed-by: Rob Herring <robh@kernel.org> Link: https://lore.kernel.org/r/20200218143126.11361-2-peter.ujfalusi@ti.comSigned-off-by: Vinod Koul <vkoul@kernel.org>
-
Andy Shevchenko authored
There is no need to have 'break;' statement in the default case followed by return certain string literal when all other cases have returned the string literals. So, refactor it accordingly. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Reviewed-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Link: https://lore.kernel.org/r/20200226101842.29426-4-andriy.shevchenko@linux.intel.comSigned-off-by: Vinod Koul <vkoul@kernel.org>
-
Andy Shevchenko authored
It's obvious that 'else' keyword is redundant in the code like if (foo) return bar; else if (baz) ... Drop it for good. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Link: https://lore.kernel.org/r/20200226101842.29426-3-andriy.shevchenko@linux.intel.comSigned-off-by: Vinod Koul <vkoul@kernel.org>
-
Andy Shevchenko authored
When negative condition is in use we may decrease indentation level and make the main part of logic better visible. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Reviewed-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Link: https://lore.kernel.org/r/20200226101842.29426-2-andriy.shevchenko@linux.intel.comSigned-off-by: Vinod Koul <vkoul@kernel.org>
-
Andy Shevchenko authored
There is no need to have branch and temporary variable in the function. Simple convert it to be a set of bit and arithmetic operations. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Reviewed-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Link: https://lore.kernel.org/r/20200226101842.29426-1-andriy.shevchenko@linux.intel.comSigned-off-by: Vinod Koul <vkoul@kernel.org>
-
Dave Jiang authored
There are some capabilities for the device that are interesting to user apps that are interacting directly with the device. Expose gencap register in sysfs to allow that information. Signed-off-by: Dave Jiang <dave.jiang@intel.com> Link: https://lore.kernel.org/r/158256729399.55526.10842505054968710547.stgit@djiang5-desk3.ch.intel.comSigned-off-by: Vinod Koul <vkoul@kernel.org>
-
Dave Jiang authored
The returned result from the check_vma() function in the cdev ->mmap() call needs to be handled. Add the check and returning error. Fixes: 42d279f9 ("dmaengine: idxd: add char driver to expose submission portal to userland") Reported-by: Vinod Koul <vkoul@kernel.org> Signed-off-by: Dave Jiang <dave.jiang@intel.com> Link: https://lore.kernel.org/r/158264926659.9387.14325163515683047959.stgit@djiang5-desk3.ch.intel.comSigned-off-by: Vinod Koul <vkoul@kernel.org>
-
- 25 Feb, 2020 33 commits
-
-
Dmitry Osipenko authored
Technically it is possible that DMA could be misconfigured in a way that cyclic DMA transfer is processed slower than it takes to complete the cycle and in this case the DMA is getting aborted with a not very informative message about the problem, let's improve it. Suggested-by: Jon Hunter <jonathanh@nvidia.com> Signed-off-by: Dmitry Osipenko <digetx@gmail.com> Acked-by: Jon Hunter <jonathanh@nvidia.com> Link: https://lore.kernel.org/r/20200209163356.6439-20-digetx@gmail.comSigned-off-by: Vinod Koul <vkoul@kernel.org>
-
Dmitry Osipenko authored
Remove unused function argument from handle_continuous_head_request(). Signed-off-by: Dmitry Osipenko <digetx@gmail.com> Acked-by: Jon Hunter <jonathanh@nvidia.com> Link: https://lore.kernel.org/r/20200209163356.6439-19-digetx@gmail.comSigned-off-by: Vinod Koul <vkoul@kernel.org>
-
Dmitry Osipenko authored
There is nothing arch-specific in the driver's code, so let's enable compile-testing for the driver. Signed-off-by: Dmitry Osipenko <digetx@gmail.com> Acked-by: Jon Hunter <jonathanh@nvidia.com> Link: https://lore.kernel.org/r/20200209163356.6439-18-digetx@gmail.comSigned-off-by: Vinod Koul <vkoul@kernel.org>
-
Dmitry Osipenko authored
Tegra APB DMA driver is an Open Firmware driver, so it uses OF alias naming scheme which overrides MODULE_ALIAS, meaning that MODULE_ALIAS does nothing and could be removed safely. Signed-off-by: Dmitry Osipenko <digetx@gmail.com> Acked-by: Jon Hunter <jonathanh@nvidia.com> Link: https://lore.kernel.org/r/20200209163356.6439-17-digetx@gmail.comSigned-off-by: Vinod Koul <vkoul@kernel.org>
-
Dmitry Osipenko authored
The driver's removal was fixed by a recent commit and module load/unload is working well now, tested on Tegra30. Signed-off-by: Dmitry Osipenko <digetx@gmail.com> Acked-by: Jon Hunter <jonathanh@nvidia.com> Link: https://lore.kernel.org/r/20200209163356.6439-16-digetx@gmail.comSigned-off-by: Vinod Koul <vkoul@kernel.org>
-
Dmitry Osipenko authored
The DMA controller shall be released on driver's removal. Signed-off-by: Dmitry Osipenko <digetx@gmail.com> Acked-by: Jon Hunter <jonathanh@nvidia.com> Link: https://lore.kernel.org/r/20200209163356.6439-15-digetx@gmail.comSigned-off-by: Vinod Koul <vkoul@kernel.org>
-
Dmitry Osipenko authored
It is enough to check whether hardware is busy on suspend and to reset it across of suspend-resume because: 1. Channel's configuration is fully re-programmed on each DMA transfer anyways. 2. Context save-restore of an active channel won't end up well without pausing transfer prior to the context's saving, but note that every channel shall be idling at the time of suspend, so save-restore is not needed at all. 3. The only case where context save-restore may be useful is when channel is in a paused state during suspend. But channel's pausing could be supported only on Tegra114+ and this functionality wasn't implemented by the driver for years now because there is no need for it in upstream kernel. Signed-off-by: Dmitry Osipenko <digetx@gmail.com> Acked-by: Jon Hunter <jonathanh@nvidia.com> Link: https://lore.kernel.org/r/20200209163356.6439-14-digetx@gmail.comSigned-off-by: Vinod Koul <vkoul@kernel.org>
-
Dmitry Osipenko authored
It's a bit impractical to enable hardware's clock at the time of DMA channel's allocation because most of DMA client drivers allocate DMA channel at the time of the driver's probing, and thus, DMA clock is kept always-enabled in practice, defeating the whole purpose of runtime PM. Signed-off-by: Dmitry Osipenko <digetx@gmail.com> Acked-by: Jon Hunter <jonathanh@nvidia.com> Link: https://lore.kernel.org/r/20200209163356.6439-13-digetx@gmail.comSigned-off-by: Vinod Koul <vkoul@kernel.org>
-
Dmitry Osipenko authored
There are few place in the code which check whether pending_sg_req list is empty despite of the check already being done. Let's remove the duplicated checks to keep code clean. Signed-off-by: Dmitry Osipenko <digetx@gmail.com> Acked-by: Jon Hunter <jonathanh@nvidia.com> Link: https://lore.kernel.org/r/20200209163356.6439-12-digetx@gmail.comSigned-off-by: Vinod Koul <vkoul@kernel.org>
-
Dmitry Osipenko authored
The runtime PM is always available on all Tegra SoCs since the commit 40b2bb1b ("ARM: tegra: enforce PM requirement"), so there is no need to handle the case of unavailable RPM in the code anymore. Signed-off-by: Dmitry Osipenko <digetx@gmail.com> Acked-by: Jon Hunter <jonathanh@nvidia.com> Link: https://lore.kernel.org/r/20200209163356.6439-11-digetx@gmail.comSigned-off-by: Vinod Koul <vkoul@kernel.org>
-
Dmitry Osipenko authored
There is no need to re-initialize the already initialized variables. The tdc->config_init=false after driver's probe and after channel's freeing, so there is no need to re-initialize it on the channel's allocation. Signed-off-by: Dmitry Osipenko <digetx@gmail.com> Acked-by: Jon Hunter <jonathanh@nvidia.com> Link: https://lore.kernel.org/r/20200209163356.6439-10-digetx@gmail.comSigned-off-by: Vinod Koul <vkoul@kernel.org>
-
Dmitry Osipenko authored
This patch fixes few dozens of coding style problems reported by checkpatch and prettifies code where makes sense. Signed-off-by: Dmitry Osipenko <digetx@gmail.com> Acked-by: Jon Hunter <jonathanh@nvidia.com> Link: https://lore.kernel.org/r/20200209163356.6439-9-digetx@gmail.comSigned-off-by: Vinod Koul <vkoul@kernel.org>
-
Dmitry Osipenko authored
Use resource-managed variant of request_irq for brevity. Signed-off-by: Dmitry Osipenko <digetx@gmail.com> Acked-by: Jon Hunter <jonathanh@nvidia.com> Link: https://lore.kernel.org/r/20200209163356.6439-8-digetx@gmail.comSigned-off-by: Vinod Koul <vkoul@kernel.org>
-
Dmitry Osipenko authored
Use devm_platform_ioremap_resource to keep code cleaner a tad. Signed-off-by: Dmitry Osipenko <digetx@gmail.com> Acked-by: Jon Hunter <jonathanh@nvidia.com> Link: https://lore.kernel.org/r/20200209163356.6439-7-digetx@gmail.comSigned-off-by: Vinod Koul <vkoul@kernel.org>
-
Dmitry Osipenko authored
There is no need to kill tasklet when driver's probe fails because tasklet can't be scheduled at this time. It is also cleaner to kill tasklet on channel's freeing rather than to kill it on driver's removal, otherwise tasklet could perform a dummy execution after channel's releasing, which isn't very nice. Signed-off-by: Dmitry Osipenko <digetx@gmail.com> Acked-by: Jon Hunter <jonathanh@nvidia.com> Link: https://lore.kernel.org/r/20200209163356.6439-6-digetx@gmail.comSigned-off-by: Vinod Koul <vkoul@kernel.org>
-
Dmitry Osipenko authored
It's incorrect to check the channel's "busy" state without taking a lock. That shouldn't cause any real troubles, nevertheless it's always better not to have any race conditions in the code. Signed-off-by: Dmitry Osipenko <digetx@gmail.com> Acked-by: Jon Hunter <jonathanh@nvidia.com> Link: https://lore.kernel.org/r/20200209163356.6439-5-digetx@gmail.comSigned-off-by: Vinod Koul <vkoul@kernel.org>
-
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: Vinod Koul <vkoul@kernel.org>
-
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: Vinod Koul <vkoul@kernel.org>
-
Tudor Ambarus authored
device_alloc_chan_resources can sleep, use GFP_KERNEL flag. 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-9-tudor.ambarus@microchip.comSigned-off-by: Vinod Koul <vkoul@kernel.org>
-
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 <tudor.ambarus@microchip.com> Acked-by: Ludovic Desroches <ludovic.desroches@microchip.com> Link: https://lore.kernel.org/r/20200123140237.125799-8-tudor.ambarus@microchip.comSigned-off-by: Vinod Koul <vkoul@kernel.org>
-
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 <tudor.ambarus@microchip.com> Acked-by: Ludovic Desroches <ludovic.desroches@microchip.com> Link: https://lore.kernel.org/r/20200123140237.125799-7-tudor.ambarus@microchip.comSigned-off-by: Vinod Koul <vkoul@kernel.org>
-
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 <tudor.ambarus@microchip.com> Acked-by: Ludovic Desroches <ludovic.desroches@microchip.com> Link: https://lore.kernel.org/r/20200123140237.125799-6-tudor.ambarus@microchip.comSigned-off-by: Vinod Koul <vkoul@kernel.org>
-
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 <tudor.ambarus@microchip.com> Acked-by: Ludovic Desroches <ludovic.desroches@microchip.com> Link: https://lore.kernel.org/r/20200123140237.125799-5-tudor.ambarus@microchip.comSigned-off-by: Vinod Koul <vkoul@kernel.org>
-
Tudor Ambarus authored
Probably a leftover, drop it. 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-4-tudor.ambarus@microchip.comSigned-off-by: Vinod Koul <vkoul@kernel.org>
-
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 <tudor.ambarus@microchip.com> Acked-by: Ludovic Desroches <ludovic.desroches@microchip.com> Link: https://lore.kernel.org/r/20200123140237.125799-3-tudor.ambarus@microchip.comSigned-off-by: Vinod Koul <vkoul@kernel.org>
-
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 <tudor.ambarus@microchip.com> Acked-by: Ludovic Desroches <ludovic.desroches@microchip.com> Link: https://lore.kernel.org/r/20200123140237.125799-2-tudor.ambarus@microchip.comSigned-off-by: Vinod Koul <vkoul@kernel.org>
-
Tudor Ambarus authored
All members of the structure are initialized below in the function, there is no need to use kzalloc. 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-1-tudor.ambarus@microchip.comSigned-off-by: Vinod Koul <vkoul@kernel.org>
-
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: Vinod Koul <vkoul@kernel.org>
-
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: Radhey Shyam Pandey <radhey.shyam.pandey@xilinx.com> Link: https://lore.kernel.org/r/1580388865-9960-2-git-send-email-radhey.shyam.pandey@xilinx.comSigned-off-by: Vinod Koul <vkoul@kernel.org>
-
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: Vinod Koul <vkoul@kernel.org>
-
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 <amelie.delaunay@st.com> Link: https://lore.kernel.org/r/20200129153628.29329-8-amelie.delaunay@st.comSigned-off-by: Vinod Koul <vkoul@kernel.org>
-
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 <amelie.delaunay@st.com> Link: https://lore.kernel.org/r/20200129153628.29329-7-amelie.delaunay@st.comSigned-off-by: Vinod Koul <vkoul@kernel.org>
-