- 19 May, 2022 22 commits
-
-
Amelie Delaunay authored
At any time, a DMA transfer can be suspended to be restarted later before the end of the DMA transfer. In order to restart from the point where the transfer was stopped, DMA_SxNDTR has to be read after disabling the channel by clearing the EN bit in DMA_SxCR register, to know the number of data items already collected. Peripheral and/or memory addresses have to be updated in order to adjust the address pointers. SxNDTR register has to be updated with the remaining number of data items to be transferred (the value read when the channel was disabled). Then the channel can be re-enabled to resume the transfer from the point it was suspended. If the channel was configured in circular or double-buffer mode, the circular or double-buffer mode must be disabled before re-enabling the channel to be able to reconfigure SxNDTR register and re-activate circular or double-buffer mode on next Transfer Complete interrupt where channel will be disabled by HW. This is due to the fact that on resume, re-writing SxNDTR register value updates internal HW auto-reload data counter, and then it truncates all next transfers after a pause/resume sequence. Signed-off-by:
Amelie Delaunay <amelie.delaunay@foss.st.com> Link: https://lore.kernel.org/r/20220505115611.38845-5-amelie.delaunay@foss.st.comSigned-off-by:
Vinod Koul <vkoul@kernel.org>
-
Amelie Delaunay authored
dmaengine framework offers device_pause and device_resume ops to pause an on-going transfer and resume it later. To avoid any misunderstanding with system sleep pm ops, rename pm ops into stm32_dma_pm_suspend and stm32_dma_pm_resume. Signed-off-by:
-
Amelie Delaunay authored
stm32_dma_handle_chan_done() is called on Transfer Complete interrupt. As DMA_SxSCR register is read in interrupt handler, pass the value as parameter of stm32_dma_handle_chan_done(). Also return directly if chan->desc is null to remove one ident level. Then, stm32_dma_configure_next_sg() is doing something only if Double-Buffer Mode (DBM) is enabled, so, check it is enabled prior calling stm32_dma_configure_next_sg(), to remove one ident level in stm32_dma_configure_next_sg(). Signed-off-by:
-
Amelie Delaunay authored
chan->next_sg is used to know which transfer will start after the ongoing one. It is incremented for each new transfer, either on transfer start for non-cyclic transfers, or on transfer complete interrupt for cyclic transfers. For cyclic transfer, when the last item is reached, chan->next_sg must be reinitialized to the first item. Signed-off-by:
-
Amelie Delaunay authored
One of the two DMA controllers managed by the DMAMUX can be used by the coprocessor. It is defined in the device tree with dma-masters. When the two DMA controllers are used by the main CPU, dma-masters = <&dma1, &dma2>; is specified in the device tree. When one of the controllers is used by coprocessor (so not managed by Linux), dma-masters = <&dma1>; is specified in the device tree. In this case, Linux driver must not reset the DMAMUX, because it could have been configured by the coprocessor to use the second DMA controller. count is the number of DMA controllers defined in dma-masters property. Reset only if resets property is found and valid in device tree, and if the two DMA controllers are under Linux control. Signed-off-by:
-
Vinod Koul authored
Add compatible and driver_data for GPI DMA engines found in Qualcomm SC7280. The driver_data contains ee_offset of 0x10000. Signed-off-by:
-
Krzysztof Kozlowski authored
The pl330 DMA controller on Exynos SoC (e.g. dma-controller@3880000 in Exynos5420) belongs to power domain, so allow such property. Reported-by:
Rob Herring <robh@kernel.org> Signed-off-by:
Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Acked-by:
-
Amelie Delaunay authored
If interrupt occurs while !chan->busy, it means channel has been disabled between the raise of the interruption and the read of status and ien, so, spurious interrupt can be silently discarded. Signed-off-by:
-
Amelie Delaunay authored
The parameter to pass back to the handler function when irq has been requested is a struct stm32_mdma_device pointer, not a struct stm32_mdma_chan pointer. Even if chan is reinit later in the function, remove this wrong initialization. Fixes: a4ffb13c ("dmaengine: Add STM32 MDMA driver") Signed-off-by:
-
Amelie Delaunay authored
GISR1 was described in a not up-to-date documentation when the stm32-mdma driver has been developed. This register has not been added in reference manual of STM32 SoC with MDMA, which have only 32 MDMA channels. So remove it from stm32-mdma driver. Fixes: a4ffb13c ("dmaengine: Add STM32 MDMA driver") Signed-off-by:
-
Krzysztof Kozlowski authored
The generic property, used in most of the drivers and defined in generic dma-common DT bindings, is 'dma-channels'. Switch to new property while keeping backward compatibility. Signed-off-by:
Tony Lindgren <tony@atomide.com> Link: https://lore.kernel.org/r/20220427161126.647073-4-krzysztof.kozlowski@linaro.orgSigned-off-by:
-
Krzysztof Kozlowski authored
The generic property, used in most of the drivers and defined in generic dma-common DT bindings, is 'dma-channels'. Switch to new property while keeping backward compatibility. Signed-off-by:
-
Krzysztof Kozlowski authored
The generic properties, used in most of the drivers and defined in generic dma-common DT bindings, are 'dma-channels' and 'dma-requests'. Switch to new properties while keeping backward compatibility. Signed-off-by:
-
Krzysztof Kozlowski authored
The generic properties, used in most of the drivers and defined in generic dma-common DT bindings, are 'dma-channels' and 'dma-requests'. Signed-off-by:
-
YueHaibing authored
drivers/dma/tegra186-gpc-dma.c: In function ‘tegra_dma_probe’: drivers/dma/tegra186-gpc-dma.c:1364:24: error: ‘struct iommu_fwspec’ has no member named ‘ids’ stream_id = iommu_spec->ids[0] & 0xffff; ^~ Make TEGRA186_GPC_DMA depends on IOMMU_API to fix this. Fixes: ee170280 ("dmaengine: tegra: Add tegra gpcdma driver") Signed-off-by:YueHaibing <yuehaibing@huawei.com> Link: https://lore.kernel.org/r/20220505093236.15076-1-yuehaibing@huawei.comSigned-off-by:
-
Miquel Raynal authored
The Renesas RZN1 DMA IP is very close to the original DW DMA IP, a DMA router has been introduced to handle the wiring options that have been added. Signed-off-by:
Miquel Raynal <miquel.raynal@bootlin.com> Reviewed-by:
Geert Uytterhoeven <geert+renesas@glider.be> Acked-by:
Andy Shevchenko <andriy.shevchenko@linux.intel.com> Acked-By:
-
Miquel Raynal authored
The clock controller device on r9a06g032 takes all the memory range that is described as being a system controller. This range contains many different (unrelated?) registers besides the ones belonging to the clock controller, that can necessitate to be accessed from other peripherals. For instance, the dmamux registers are there. The dmamux "device" will be described as a child node of the clock/system controller node, which means we need the top device driver (the clock controller driver in this case) to populate its children manually. In case of error when populating the children, we do not fail the probe on purpose to keep the clk driver up and running. Signed-off-by:
Stephen Boyd <sboyd@kernel.org> Reviewed-by:
-
Miquel Raynal authored
The Renesas RZN1 DMA IP is based on a DW core, with eg. an additional dmamux register located in the system control area which can take up to 32 requests (16 per DMA controller). Each DMA channel can be wired to two different peripherals. We need two additional information from the 'dmas' property: the channel (bit in the dmamux register) that must be accessed and the value of the mux for this channel. Signed-off-by:
Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Link: https://lore.kernel.org/r/20220427095653.91804-6-miquel.raynal@bootlin.comSigned-off-by:
-
Miquel Raynal authored
The dmamux register is located within the system controller. Without syscon, we need an extra helper in order to give write access to this register to a dmamux driver. Signed-off-by:
-
Miquel Raynal authored
Just like for the NAND controller that is also on this SoC, let's provide a SoC generic and a more specific couple of compatibles for the DMA controller. Signed-off-by:
-
Miquel Raynal authored
This system controller contains several registers that have nothing to do with the clock handling, like the DMA mux register. Describe this part of the system controller as a subnode. Signed-off-by:
-
Miquel Raynal authored
The Renesas RZN1 DMA IP is based on a DW core, with eg. an additional dmamux register located in the system control area which can take up to 32 requests (16 per DMA controller). Each DMA channel can be wired to two different peripherals. Signed-off-by:
-
- 16 May, 2022 16 commits
-
-
Minghao Chi authored
Calling synchronize_irq() right before free_irq() is quite useless. On one hand the IRQ can easily fire again before free_irq() is entered, on the other hand free_irq() itself calls synchronize_irq() internally (in a race condition free way), before any state associated with the IRQ is freed. Signed-off-by:
Minghao Chi <chi.minghao@zte.com.cn> Link: https://lore.kernel.org/r/20220516115412.1651772-1-chi.minghao@zte.com.cnAcked-by:
Dave Jiang <dave.jiang@intel.com> Signed-off-by:
-
Dave Jiang authored
When setting DMA_INTERRUPT capability, a callback function dma->device_prep_dma_interrupt() is needed to support this capability. Without setting the callback, dma_async_device_register() will fail dma capability check. Fixes: 4e5a4eb2 ("dmaengine: idxd: set DMA_INTERRUPT cap bit") Signed-off-by:
-
Krzysztof Kozlowski authored
The generic property, used in most of the drivers and defined in generic dma-common DT bindings, is 'dma-channels'. Switch to new property while keeping backward compatibility. Signed-off-by:
Baolin Wang <baolin.wang7@gmail.com> Link: https://lore.kernel.org/r/20220503065147.51728-3-krzysztof.kozlowski@linaro.orgSigned-off-by:
-
Krzysztof Kozlowski authored
The generic property, used in most of the drivers and defined in generic dma-common DT bindings, is 'dma-channels'. Signed-off-by:
-
Dave Jiang authored
Skip wq irq resources freeing when wq type is not kernel since the driver skips the irq alloction during wq enable. Add check in wq type check in idxd_wq_free_irq() to mirror idxd_wq_request_irq(). Fixes: 63c14ae6 ("dmaengine: idxd: refactor wq driver enable/disable operations") Reported-by:
Tony Zu <tony.zhu@intel.com> Tested-by:
-
Dave Jiang authored
Since idxd_register/unregister_dma_channel() are only called locally, make them static. Reported-by:
kernel test robot <lkp@intel.com> Signed-off-by:
-
Radhey Shyam Pandey authored
pm_runtime_resume_and_get() automatically handle dev->power.usage_count decrement on errors, so prefer using it and also implement it's error handling. Signed-off-by:
Radhey Shyam Pandey <radhey.shyam.pandey@xilinx.com> Link: https://lore.kernel.org/r/1652166762-18317-4-git-send-email-radhey.shyam.pandey@xilinx.comSigned-off-by:
-
Shravya Kumbham authored
Add condition to check the return value of dma_async_device_register and implement its error handling. Addresses-Coverity: Event check_return. Signed-off-by:
Shravya Kumbham <shravya.kumbham@xilinx.com> Signed-off-by:
Harini Katakam <harini.katakam@xilinx.com> Signed-off-by:
-
Radhey Shyam Pandey authored
In zynqmp_dma_alloc/free_chan_resources functions there is a potential overflow in the below expressions. dma_alloc_coherent(chan->dev, (2 * chan->desc_size * ZYNQMP_DMA_NUM_DESCS), &chan->desc_pool_p, GFP_KERNEL); dma_free_coherent(chan->dev,(2 * ZYNQMP_DMA_DESC_SIZE(chan) * ZYNQMP_DMA_NUM_DESCS), chan->desc_pool_v, chan->desc_pool_p); The arguments desc_size and ZYNQMP_DMA_NUM_DESCS were 32 bit. Though this overflow condition is not observed but it is a potential problem in the case of 32-bit multiplication. Hence fix it by changing the desc_size data type to size_t. In addition to coverity fix it also reuse ZYNQMP_DMA_DESC_SIZE macro in dma_alloc_coherent API argument. Addresses-Coverity: Event overflow_before_widen. Signed-off-by: -
Dave Jiang authored
idxd_wq_device_reset_cleanup() already calls idxd_wq_disable_cleanup(). There is no need to call idxd_wq_disable_cleanup() again in idxd_device_wqs_clear_state(). Remove redudant call from idxd_wq_device_reset_cleanup(). Fixes: 0dcfe41e ("dmanegine: idxd: cleanup all device related bits after disabling device") Signed-off-by:
-
Dave Jiang authored
Call idxd_wq_free_irq() in the drv_disable_wq() function before idxd_wq_reset() is called. Otherwise the wq type is reset and the irq does not get freed. Fixes: 63c14ae6 ("dmaengine: idxd: refactor wq driver enable/disable operations") Signed-off-by:
-
Dave Jiang authored
Jacob reported that with lockdep debug turned on, idxd_device_driver removal causes kernel splat from lock assert warning for idxd_device_wqs_clear_state(). Make sure idxd_device_wqs_clear_state() holds the wq lock for each wq when cleaning the wq state. Move the call outside of the device spinlock. Reported-by:
Jacob Pan <jacob.jun.pan@intel.com> Signed-off-by:
-
Dave Jiang authored
The idxd driver always gated the pasid enabling under a single knob and this assumption is incorrect. The pasid used for kernel operation can be independently toggled and has no dependency on the user pasid (and vice versa). Split the two so they are independent "enabled" flags. Signed-off-by:
-
Geert Uytterhoeven authored
Despite the name, R-Car V3U is the first member of the R-Car Gen4 family. Hence move its compatible value to the R-Car Gen4 section. Signed-off-by:
-
Christophe JAILLET authored
If a call to alloc_chrdev_region() fails, the already allocated resources are leaking. Add the needed error handling path to fix the leak. Fixes: 42d279f9 ("dmaengine: idxd: add char driver to expose submission portal to userland") Signed-off-by:
Christophe JAILLET <christophe.jaillet@wanadoo.fr> Acked-by:
-
Akhil R authored
Use platform_irq_get() instead platform_get_resource() for IRQ resource to fix the probe failure. platform_get_resource() fails to fetch the IRQ resource as it might not be ready at that time. platform_irq_get() is also the recommended way to get interrupt as it directly gives the IRQ number and no conversion from resource is required. Fixes: ee170280 ("dmaengine: tegra: Add tegra gpcdma driver") Reported-by:
Jonathan Hunter <jonathanh@nvidia.com> Signed-off-by:
Akhil R <akhilrajeev@nvidia.com> Acked-by:
Thierry Reding <treding@nvidia.com> Reviewed-by:
-
- 22 Apr, 2022 2 commits
-
-
Yunbo Yu authored
It is unnecessary to call spin_lock_bh() for that you are already in a tasklet. Signed-off-by:
Yunbo Yu <yuyunbo519@gmail.com> Link: https://lore.kernel.org/r/20220420122754.148359-1-yuyunbo519@gmail.comSigned-off-by:
-
Dave Jiang authored
Move the core driver operations from wq driver to the drv_enable_wq() and drv_disable_wq() functions. The move should reduce the wq driver's knowledge of the core driver operations and prevent code confusion for future wq drivers. Signed-off-by:
-
