- Sep 29, 2022
-
-
Bhupesh Sharma authored
As a user recently noted, the qcom,bam-dma binding document describes the msm8974 BAM DMA node in the 'example section' incorrectly. Fix the same by making it consistent with the node present inside 'qcom-msm8974' dts file, namely the 'reg' and 'interrupt' values which are incorrect in the 'example section'. While at it also make two additioanal minor cleanups: - mention Bjorn's new email ID in the document, and - add SDM845 in the comment line for the SoCs on which qcom,bam-v1.7.0 version is supported. Signed-off-by:
Bhupesh Sharma <bhupesh.sharma@linaro.org> Reviewed-by:
Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Link: https://lore.kernel.org/r/20220926112200.1948080-1-bhupesh.sharma@linaro.org Signed-off-by:
Vinod Koul <vkoul@kernel.org>
-
Deming Wang authored
remove the double word to. Signed-off-by:
Deming Wang <wangdeming@inspur.com> Acked-by:
Rob Herring <robh@kernel.org> Acked-by:
Peter Ujfalusi <peter.ujfalusi@gmail.com> Link: https://lore.kernel.org/r/20220920020721.2190-1-wangdeming@inspur.com Signed-off-by:
-
Gustavo A. R. Silva authored
Zero-length arrays are deprecated and we are moving towards adopting C99 flexible-array members, instead. So, replace zero-length arrays declarations in anonymous union with the new DECLARE_FLEX_ARRAY() helper macro. This helper allows for flexible-array members in unions. Link: https://github.com/KSPP/linux/issues/193 Link: https://github.com/KSPP/linux/issues/217 Link: https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html Signed-off-by:
Gustavo A. R. Silva <gustavoars@kernel.org> Reviewed-by:
Kees Cook <keescook@chromium.org> Link: https://lore.kernel.org/r/YzIdsJqsR3LH2qEK@work Signed-off-by:
-
Yuan Can authored
Since fault processing code has been removed, struct idxd_fault is not used any more and can be removed as well. Signed-off-by:
Yuan Can <yuancan@huawei.com> Link: https://lore.kernel.org/r/20220928014747.106808-1-yuancan@huawei.com Signed-off-by:
-
Geert Uytterhoeven authored
Document support for the Direct Memory Access Controllers (DMAC) in the Renesas R-Car V4H (R8A779G0) SoC. Signed-off-by:
Geert Uytterhoeven <geert+renesas@glider.be> Acked-by:
Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com> Link: https://lore.kernel.org/r/0a4d40092a51345003742725aea512a815d27e89.1664204526.git.geert+renesas@glider.be Signed-off-by:
-
Jerry Snitselaar authored
Now that idxd_wq_disable_cleanup() sets the workqueue state to IDXD_WQ_DISABLED, use a bitmap to track which workqueues have been enabled. This will then be used to determine which workqueues should be re-enabled when attempting a software reset to recover from a device halt state. Cc: Fenghua Yu <fenghua.yu@intel.com> Cc: Dave Jiang <dave.jiang@intel.com> Cc: Vinod Koul <vkoul@kernel.org> Signed-off-by:
Jerry Snitselaar <jsnitsel@redhat.com> Reviewed-by:
Dave Jiang <dave.jiang@intel.com> Link: https://lore.kernel.org/r/20220928154856.623545-3-jsnitsel@redhat.com Signed-off-by:
-
Jerry Snitselaar authored
If we are calling idxd_wq_disable_cleanup(), the workqueue should be in a disabled state. So set the workqueue state to IDXD_WQ_DISABLED so that the state reflects that. Currently if there is a device failure, and a software reset is attempted the workqueues will not be re-enabled due to idxd_wq_enable() seeing that state as already being IDXD_WQ_ENABLED. Cc: Fenghua Yu <fenghua.yu@intel.com> Cc: Dave Jiang <dave.jiang@intel.com> Cc: Vinod Koul <vkoul@kernel.org> Signed-off-by:
-
Shaomin Deng authored
Fix the double word "many" in comments. Signed-off-by:
Shaomin Deng <dengshaomin@cdjrlc.com> Link: https://lore.kernel.org/r/20220830150708.24507-1-dengshaomin@cdjrlc.com Signed-off-by:
-
Shaomin Deng authored
Delete the double word "many" in comments. Signed-off-by:
-
Tuo Cao authored
it is unnecessary to call read_lock_bh in a tasklet. Signed-off-by:
Tuo Cao <91tuocao@gmail.com> Link: https://lore.kernel.org/r/20220814131323.7029-1-91tuocao@gmail.com Signed-off-by:
-
Dario Binacchi authored
Driver registration fails on SOC imx8mn as its supplier, the clock control module, is probed later than subsys initcall level. This driver uses platform_driver_probe which is not compatible with deferred probing and won't be probed again later if probe function fails due to clock not being available at that time. This patch replaces the use of platform_driver_probe with platform_driver_register which will allow probing the driver later again when the clock control module will be available. The __init annotation has been dropped because it is not compatible with deferred probing. The code is not executed once and its memory cannot be freed. Fixes: a580b8c5 ("dmaengine: mxs-dma: add dma support for i.MX23/28") Co-developed-by:
Michael Trimarchi <michael@amarulasolutions.com> Signed-off-by:
Dario Binacchi <dario.binacchi@amarulasolutions.com> Acked-by:
Sascha Hauer <s.hauer@pengutronix.de> Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20220921170556.1055962-1-dario.binacchi@amarulasolutions.com Signed-off-by:
-
- Sep 05, 2022
-
-
Jean Delvare authored
Since commit 0166dc11 ("of: make CONFIG_OF user selectable"), it is possible to test-build any driver which depends on OF on any architecture by explicitly selecting OF. Therefore depending on COMPILE_TEST as an alternative is no longer needed. It is actually better to always build such drivers with OF enabled, so that the test builds are closer to how each driver will actually be built on its intended target. Building them without OF may not test much as the compiler will optimize out potentially large parts of the code. In the worst case, this could even pop false positive warnings. Dropping COMPILE_TEST here improves the quality of our testing and avoids wasting time on non-existent issues. Signed-off-by:
Jean Delvare <jdelvare@suse.de> Cc: Eugeniy Paltsev <Eugeniy.Paltsev@synopsys.com> Cc: Vinod Koul <vkoul@kernel.org> Link: https://lore.kernel.org/r/20220803223448.6f08095b@endymion.delvare Signed-off-by:
-
Tudor Ambarus authored
Add a cosmetic change and replace two if statements with a single if statement with two conditions. In case the optional txstate parameter is NULL, we return the dma_cookie_status, which is fine, no functional change required. Signed-off-by:
Tudor Ambarus <tudor.ambarus@microchip.com> Link: https://lore.kernel.org/r/20220802140630.243550-1-tudor.ambarus@microchip.com Signed-off-by:
-
Harini Katakam authored
txd.flags is unused and need not be updated. Signed-off-by:
Harini Katakam <harini.katakam@amd.com> Link: https://lore.kernel.org/r/20220802102232.17653-1-harini.katakam@amd.com Signed-off-by:
-
Christophe JAILLET authored
STM32_DMAMUX_MAX_DMA_REQUESTS is small (i.e. 32) and when the 'dma_inuse' bitmap is allocated, there is already a check that 'dma_req' is <= this limit. So, there is no good reason to dynamically allocate this bitmap. This just waste some memory and some cycles. Use DECLARE_BITMAP with the maximum bitmap size instead. Signed-off-by:
Christophe JAILLET <christophe.jaillet@wanadoo.fr> Link: https://lore.kernel.org/r/2d8c24359b2daa32ce0597a2949b7b2bebaf23de.1659211633.git.christophe.jaillet@wanadoo.fr Signed-off-by:
-
Jason Wang authored
The double `end' is duplicated in the comment, remove one. Signed-off-by:
Jason Wang <wangborong@cdjrlc.com> Link: https://lore.kernel.org/r/20220811120959.18752-1-wangborong@cdjrlc.com Signed-off-by:
-
ye xingchen authored
>From the coccinelle check: ./drivers/dma/sf-pdma/sf-pdma.c Error:line 409 is redundant because platform_get_irq() already prints an error ./drivers/dma/sf-pdma/sf-pdma.c Error:line 424 is redundant because platform_get_irq() already prints an error So,remove the unnecessary print function dev_err() Reported-by:
Zeal Robot <zealci@zte.com.cn> Signed-off-by:
ye xingchen <ye.xingchen@zte.com.cn> Link: https://lore.kernel.org/r/20220810062532.13425-1-ye.xingchen@zte.com.cn Signed-off-by:
-
Vaishnav Achath authored
UDMA_CHAN_RT_*BCNT_REG stores the real-time channel bytecount statistics. These registers are 32-bit hardware counters and the driver uses these counters to monitor the operational progress status for a channel, when transferring more than 4GB of data it was observed that these counters overflow and completion calculation of a operation gets affected and the transfer hangs indefinitely. This commit adds changes to decrease the byte count for every complete transaction so that these registers never overflow and the proper byte count statistics is maintained for ongoing transaction by the RT counters. Earlier uc->bcnt used to maintain a count of the completed bytes at driver side, since the RT counters maintain the statistics of current transaction now, the maintenance of uc->bcnt is not necessary. Signed-off-by:
Vaishnav Achath <vaishnav.a@ti.com> Acked-by:
-
AngeloGioacchino Del Regno authored
Add mediatek,mt6795-uart-dma to the compatibles list to support the MT6795 Helio X10 SoC's UART APDMA. Signed-off-by:
AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Acked-by:
-
Andy Shevchenko authored
For the sake of integrity, include headers we are direct user of. Signed-off-by:
Andy Shevchenko <andriy.shevchenko@linux.intel.com> Link: https://lore.kernel.org/r/20220713172235.22611-4-andriy.shevchenko@linux.intel.com Signed-off-by:
-
Andy Shevchenko authored
For the masks replace chain of BIT() macros by GENMASK(). While at it, explicitly include bits.h. Signed-off-by:
-
Andy Shevchenko authored
It's more cleanly to use for_each_set_bit() instead of opencoding it. Signed-off-by:
-
Andy Shevchenko authored
With help of devm_add_action_or_reset() we may finish conversion the driver to use managed resources. Signed-off-by:
-
Amelie Delaunay authored
STM32 MDMA can be triggered by STM32 DMA channels transfer complete. In case of non-null struct dma_slave_config .peripheral_size, it means the DMA client wants the DMA to trigger the MDMA. stm32-mdma driver gets the request id, the mask_addr, and the mask_data in struct stm32_mdma_dma_config passed by DMA with struct dma_slave_config .peripheral_config/.peripheral_size. Then, as DMA is configured in Double-Buffer mode, and MDMA channel will transfer data from/to SRAM to/from DDR, then bursts are optimized. Signed-off-by:
Amelie Delaunay <amelie.delaunay@foss.st.com> Link: https://lore.kernel.org/r/20220829154646.29867-7-amelie.delaunay@foss.st.com Signed-off-by:
-
Amelie Delaunay authored
STM32 MDMA can be triggered by STM32 DMA channels transfer complete. The "request line number" triggering STM32 MDMA is the STM32 DMAMUX channel id set by stm32-dmamux driver in dma_spec->args[3]. stm32-dma driver fills the struct stm32_dma_mdma_config used to configure the MDMA with struct dma_slave_config .peripheral_config/.peripheral_size. Signed-off-by:
-
Amelie Delaunay authored
STM32 DMAMUX is used with STM32 DMA1 and DMA2: - DMAMUX channels 0 to 7 are connected to DMA1 channels 0 to 7 - DMAMUX channels 8 to 15 are connected to DMA2 channels 0 to 7 STM32 MDMA can be triggered by DMA1 and DMA2 channels transfer complete, and the "request line number" is the DMAMUX channel id (e.g. DMA2 channel 0 triggers MDMA with request line 8). To well configure MDMA, set DMAMUX channel id in DMA features bitfield, so that DMA can update struct dma_slave_config peripheral_config properly. Signed-off-by:
-
Amelie Delaunay authored
STM32 DMA-MDMA chaining feature is available on STM32 SoCs which embed STM32 DMAMUX, DMA and MDMA controllers. It is the case on STM32MP1 SoCs but also on STM32H7 SoCs. But focus is on STM32MP1 SoCs, using DDR. This documentation aims to explain how to use STM32 DMA-MDMA chaining feature in drivers of STM32 peripheral having request lines on STM32 DMA. Signed-off-by:
-
Amelie Delaunay authored
Use the FIELD_{GET,PREP}() helpers, instead of defining custom macros implementing the same operations. Signed-off-by: -
Amelie Delaunay authored
Channels 0 to 3 flags are described in DMA_LISR and DMA_LIFCR (L as Low). Channels 4 to 7 flags are described in DMA_HISR and DMA_HIFCR (H as High). Macro STM32_DMA_ISR(n) returns the interrupt status register offset for the channel id (n). Macro STM32_DMA_IFCR(n) returns the interrupt flag clear register offset for the channel id (n). If chan->id % 4 = 2 or 3, then its flags are left-shifted by 16 bits. If chan->id % 4 = 1 or 3, then its flags are additionally left-shifted by 6 bits. If chan->id % 4 = 0, then its flags are not shifted. Macro STM32_DMA_FLAGS_SHIFT(n) returns the required shift to get or set the channel flags mask. Signed-off-by:
-
Jie Hai authored
Add myself as a maintainer for hisi_dma. Signed-off-by:
Jie Hai <haijie1@huawei.com> Acked-by:
Zhou Wang <wangzhou1@hisilicon.com> Link: https://lore.kernel.org/r/20220830062251.52993-8-haijie1@huawei.com Signed-off-by:
-
Jie Hai authored
This patch adds dump of registers with debugfs for HIP08 and HIP09 DMA driver. Signed-off-by:
-
Jie Hai authored
The HiSilicon IP08 and HiSilicon IP09 are DMA iEPs, they have the same pci device id but different pci revision. Unfortunately, they have different register layouts, so the origin driver cannot run on HiSilicon IP09 correctly. This patch enables the driver to adapt to HiSilicon IP09. HiSilicon IP09 offers 4 channels, each channel has a send queue, a complete queue and an interrupt to help to do tasks. This DMA engine can do memory copy between memory blocks. Signed-off-by:
-
Jie Hai authored
readl_relaxed_poll_timeout() uses magic numbers 10 and 1000, which indicate maximum time to sleep between reads in us and timeout in us, respectively. Use macros HISI_DMA_POLL_Q_STS_DELAY_US and HISI_DMA_POLL_Q_STS_TIME_OUT_US instead of these two numbers. Signed-off-by:
-
Jie Hai authored
When we get a DMA channel and try to use it in multiple threads it will cause oops and hanging the system. % echo 100 > /sys/module/dmatest/parameters/threads_per_chan % echo 100 > /sys/module/dmatest/parameters/iterations % echo 1 > /sys/module/dmatest/parameters/run [383493.327077] Unable to handle kernel paging request at virtual address dead000000000108 [383493.335103] Mem abort info: [383493.335103] ESR = 0x96000044 [383493.335105] EC = 0x25: DABT (current EL), IL = 32 bits [383493.335107] SET = 0, FnV = 0 [383493.335108] EA = 0, S1PTW = 0 [383493.335109] FSC = 0x04: level 0 translation fault [383493.335110] Data abort info: [383493.335111] ISV = 0, ISS = 0x00000044 [383493.364739] CM = 0, WnR = 1 [383493.367793] [dead000000000108] address between user and kernel address ranges [383493.375021] Internal error: Oops: 96000044 [#1] PREEMPT SMP [383493.437574] CPU: 63 PID: 27895 Comm: dma0chan0-copy2 Kdump: loaded Tainted: GO 5.17.0-rc4+ #2 [383493.457851] pstate: 204000c9 (nzCv daIF +PAN -UAO -TCO -DIT -SSBS BTYPE=--) [383493.465331] pc : vchan_tx_submit+0x64/0xa0 [383493.469957] lr : vchan_tx_submit+0x34/0xa0 This occurs because the transmission timed out, and that's due to data race. Each thread rewrite channels's descriptor as soon as device_issue_pending is called. It leads to the situation that the driver thinks that it uses the right descriptor in interrupt handler while channels's descriptor has been changed by other thread. The descriptor which in fact reported interrupt will not be handled any more, as well as its tx->callback. That's why timeout reports. With current fixes channels' descriptor changes it's value only when it has been used. A new descriptor is acquired from vc->desc_issued queue that is already filled with descriptors that are ready to be sent. Threads have no direct access to DMA channel descriptor. In case of channel's descriptor is busy, try to submit to HW again when a descriptor is completed. In this case, vc->desc_issued may be empty when hisi_dma_start_transfer is called, so delete error reporting on this. Now it is just possible to queue a descriptor for further processing. Fixes: e9f08b65 ("dmaengine: hisilicon: Add Kunpeng DMA engine support") Signed-off-by:
-
Jie Hai authored
After completion of data transfer of one or multiple descriptors, the completion status and the current head pointer to submission queue are written into the CQ and interrupt can be generated to inform the software. In interrupt process CQ is read and cq_head is updated. hisi_dma_irq updates cq_head only when the completion status is success. When an abnormal interrupt reports, cq_head will not update which will cause subsequent interrupt processes read the error CQ and never report the correct status. This patch updates cq_head whenever CQ is accessed. Fixes: e9f08b65 ("dmaengine: hisilicon: Add Kunpeng DMA engine support") Signed-off-by:
-
Jie Hai authored
When hisi_dma is unloaded or unbinded, all of channels should be disabled. This patch disables DMA channels when driver is unloaded or unbinded. Fixes: e9f08b65 ("dmaengine: hisilicon: Add Kunpeng DMA engine support") Signed-off-by:
-
Jerry Snitselaar authored
idxd_device_clear_state() now grabs the idxd->dev_lock itself, so don't grab the lock prior to calling it. This was seen in testing after dmar fault occurred on system, resulting in lockup stack traces. Cc: Fenghua Yu <fenghua.yu@intel.com> Cc: Dave Jiang <dave.jiang@intel.com> Cc: Vinod Koul <vkoul@kernel.org> Cc: dmaengine@vger.kernel.org Fixes: cf4ac3fe ("dmaengine: idxd: fix lockdep warning on device driver removal") Signed-off-by:
-
Luca Weiss authored
The Qualcomm SM6350 platform does, like the SM8450, provide a set of GPI controllers with an ee-offset of 0x10000. Add this to the driver. Signed-off-by:
Luca Weiss <luca.weiss@fairphone.com> Reviewed-by:
Bjorn Andersson <andersson@kernel.org> Link: https://lore.kernel.org/r/20220812082721.1125759-3-luca.weiss@fairphone.com Signed-off-by:
-
Luca Weiss authored
Document the compatible for GPI DMA controller on SM6350 SoC. Signed-off-by:
-
Rob Herring authored
The pl330 can be behind an IOMMU which is the case for Arm Juno board. Add the 'iommus' property allowing for 1 IOMMU entry per channel for writes and 1 IOMMU entry for reads. Signed-off-by:
-
