- 11 Nov, 2022 3 commits
-
-
Tudor Ambarus authored
txstate is an optional parameter used to get a struct with auxilary transfer status information. When not provided the call to device_tx_status() should return the status of the dma cookie. Return the status of dma cookie when the txstate optional parameter is not provided. Signed-off-by:
Tudor Ambarus <tudor.ambarus@microchip.com> Acked-by:
Nicolas Ferre <nicolas.ferre@microchip.com> Link: https://lore.kernel.org/r/20221025090306.297886-1-tudor.ambarus@microchip.com Link: https://lore.kernel.org/r/20221025090306.297886-18-tudor.ambarus@microchip.comSigned-off-by:
Vinod Koul <vkoul@kernel.org>
-
Tudor Ambarus authored
The descriptor was already removed from the transfer list, there's no reason to keep the channel lock while printing desc info, thus do the prints without holding the lock. Signed-off-by:
-
Vinod Koul authored
Merge due to at_hdmac driver dependency
-
- 08 Nov, 2022 22 commits
-
-
Tudor Ambarus authored
dma_async_device_register() can fail, check the return code and display an error. Fixes: dc78baa2 ("dmaengine: at_hdmac: new driver for the Atmel AHB DMA Controller") Signed-off-by:
-
Tudor Ambarus authored
The iterator can not be greater than ATC_MAX_DSCR_TRIALS, as the for loop will stop when i == ATC_MAX_DSCR_TRIALS. While here, use the common "i" name for the iterator. Fixes: 93dce3a6 ("dmaengine: at_hdmac: fix residue computation") Signed-off-by:
-
Tudor Ambarus authored
at_hdmac uses __raw_writel for register writes. In the absence of a barrier, the CPU may reorder the register operations. Introduce a write memory barrier so that the CPU does not reorder the channel enable, thus the start of the transfer, without making sure that all the pre-required register fields are already written. Fixes: dc78baa2 ("dmaengine: at_hdmac: new driver for the Atmel AHB DMA Controller") Reported-by:
Peter Rosin <peda@axentia.se> Signed-off-by:
-
Tudor Ambarus authored
In case the controller detected an error, the code took the chance to move all the queued (submitted) descriptors to the active (issued) list. This was wrong as if there were any descriptors in the submitted list they were moved to the issued list without actually issuing them to the controller, thus a completion could be raised without even fireing the descriptor. Fixes: dc78baa2 ("dmaengine: at_hdmac: new driver for the Atmel AHB DMA Controller") Reported-by:
-
Tudor Ambarus authored
As it was before, the descriptor was issued to the hardware without adding it to the active (issued) list. This could result in a completion of other descriptor, or/and in the descriptor never being completed. Fixes: dc78baa2 ("dmaengine: at_hdmac: new driver for the Atmel AHB DMA Controller") Reported-by:
-
Tudor Ambarus authored
The tasklet (atc_advance_work()) did not held the channel lock when retrieving the first active descriptor, causing concurrency problems if issue_pending() was called in between. If issue_pending() was called exactly after the lock was released in the tasklet (atc_advance_work()), atc_chain_complete() could complete a descriptor for which the controller has not yet raised an interrupt. Fixes: dc78baa2 ("dmaengine: at_hdmac: new driver for the Atmel AHB DMA Controller") Reported-by:
-
Tudor Ambarus authored
There's no need to hold the channel lock when freeing the memset buf, as the operation has already completed. Free the memset buf without holding the channel lock. Fixes: 4d112426 ("dmaengine: hdmac: Add memset capabilities") Signed-off-by:
-
Tudor Ambarus authored
The descriptor was added to the free_list before calling the callback, which could result in reissuing of the same descriptor and calling of a single callback for both. Move the decriptor to the free list after the callback is invoked. Fixes: dc78baa2 ("dmaengine: at_hdmac: new driver for the Atmel AHB DMA Controller") Reported-by:
-
Tudor Ambarus authored
atc_complete_all() had concurrency bugs, thus remove it: 1/ atc_complete_all() in its entirety was buggy, as when the atchan->queue list (the one that contains descriptors that are not yet issued to the hardware) contained descriptors, it fired just the first from the atchan->queue, but moved all the desc from atchan->queue to atchan->active_list and considered them all as fired. This could result in calling the completion of a descriptor that was not yet issued to the hardware. 2/ when in tasklet at atc_advance_work() time, atchan->active_list was queried without holding the lock of the chan. This can result in atchan->active_list concurrency problems between the tasklet and issue_pending(). Fixes: dc78baa2 ("dmaengine: at_hdmac: new driver for the Atmel AHB DMA Controller") Reported-by:
-
Tudor Ambarus authored
Now that the complete callback call was removed from device_terminate_all(), we can protect the atchan->status with the channel lock. The atomic bitops on atchan->status do not substitute proper locking on the status, as one could still modify the status after the lock was dropped in atc_terminate_all() but before the atomic bitops were executed. Fixes: 078a6506 ("dmaengine: at_hdmac: Fix deadlocks") Reported-by:
-
Tudor Ambarus authored
The method was wrong because it violated the dmaengine API. For aborted transfers the complete callback should not be called. Fix the behavior and do not call the complete callback on device_terminate_all. Fixes: 808347f6 ("dmaengine: at_hdmac: add DMA slave transfers") Reported-by:
-
Tudor Ambarus authored
Multiple calls to atc_issue_pending() could result in a premature completion of a descriptor from the atchan->active list, as the method always completed the first active descriptor from the list. Instead, issue_pending() should just take the first transaction descriptor from the pending queue, move it to active_list and start the transfer. Fixes: dc78baa2 ("dmaengine: at_hdmac: new driver for the Atmel AHB DMA Controller") Reported-by:
-
Tudor Ambarus authored
Cyclic channels must too call issue_pending in order to start a transfer. Start the transfer in issue_pending regardless of the type of channel. This wrongly worked before, because in the past the transfer was started at tx_submit level when only a desc in the transfer list. Fixes: 53830cc7 ("dmaengine: at_hdmac: add cyclic DMA operation support") Reported-by:
-
Tudor Ambarus authored
tx_submit is supposed to push the current transaction descriptor to a pending queue, waiting for issue_pending() to be called. issue_pending() must start the transfer, not tx_submit(), thus remove atc_dostart() from atc_tx_submit(). Clients of at_xdmac that assume that tx_submit() starts the transfer must be updated and call dma_async_issue_pending() if they miss to call it. The vdbg print was moved to after the lock is released. It is desirable to do the prints without the lock held if possible, and because the if statement disappears there's no reason why to do the print while holding the lock. Fixes: dc78baa2 ("dmaengine: at_hdmac: new driver for the Atmel AHB DMA Controller") Reported-by:
-
Tudor Ambarus authored
Those hardware registers are all of 32 bits, while dma_addr_t ca be of type u64 or u32 depending on CONFIG_ARCH_DMA_ADDR_T_64BIT. Force u32 to comply with what the hardware expects. Fixes: dc78baa2 ("dmaengine: at_hdmac: new driver for the Atmel AHB DMA Controller") Signed-off-by:
-
Amelie Delaunay authored
When disabling dma channel, a TCF flag is set and as TCIE is enabled, an interrupt is raised. On a busy system, the interrupt may have latency and the user can ask for dmaengine_resume while stm32-dma driver has not yet managed the complete pause (backup of registers to restore state in resume). To avoid such a case, instead of waiting the interrupt to backup the registers, do it just after disabling the channel and discard Transfer Complete interrupt in case the channel is paused. Fixes: 099a9a94 ("dmaengine: stm32-dma: add device_pause/device_resume support") Signed-off-by:
Amelie Delaunay <amelie.delaunay@foss.st.com> Link: https://lore.kernel.org/r/20221024083611.132588-1-amelie.delaunay@foss.st.comSigned-off-by:
-
Yang Yingliang authored
If device_register() fails, it should call put_device() to give up reference, the name allocated in dev_set_name() can be freed in callback function kobject_cleanup(). Fixes: 5b65781d ("dmaengine: ti: k3-udma-glue: Add support for K3 PKTDMA") Signed-off-by:
Yang Yingliang <yangyingliang@huawei.com> Acked-by:
Peter Ujfalusi <peter.ujfalusi@gmail.com> Link: https://lore.kernel.org/r/20221020062827.2914148-1-yangyingliang@huawei.comSigned-off-by:
-
Christophe JAILLET authored
A clk_prepare_enable() call in the probe is not balanced by a corresponding clk_disable_unprepare() in the remove function. Add the missing call. Fixes: 3cd2c313 ("dmaengine: mv_xor_v2: Fix clock resource by adding a register clock") Signed-off-by:
Christophe JAILLET <christophe.jaillet@wanadoo.fr> Link: https://lore.kernel.org/r/e9e3837a680c9bd2438e4db2b83270c6c052d005.1666640987.git.christophe.jaillet@wanadoo.frSigned-off-by:
-
Martin Povišer authored
The of_xlate callback is supposed to return the channel after already having 'grabbed' it for private use, so fill that in. Fixes: b127315d ("dmaengine: apple-admac: Add Apple ADMAC driver") Signed-off-by:
Martin Povišer <povik+lin@cutebit.org> Link: https://lore.kernel.org/r/20221019132324.8585-1-povik+lin@cutebit.orgSigned-off-by:
-
Fengqian Gao authored
When IDXD is not configurable, that means its WQ, engine, and group configurations cannot be changed. But it can be disabled and its state should be set as disabled regardless it's configurable or not. Fix this by setting device state IDXD_DEV_DISABLED for read-only device as well in idxd_device_clear_state(). Fixes: cf4ac3fe ("dmaengine: idxd: fix lockdep warning on device driver removal") Signed-off-by:
Fengqian Gao <fengqian.gao@intel.com> Reviewed-by:
Xiaochen Shen <xiaochen.shen@intel.com> Reviewed-by:
Dave Jiang <dave.jiang@intel.com> Reviewed-by:
Fenghua Yu <fenghua.yu@intel.com> Link: https://lore.kernel.org/r/20220930032835.2290-1-fengqian.gao@intel.comSigned-off-by:
-
Xiaochen Shen authored
>From Intel IAA spec [1], Intel IAA does not support batch processing. Two batch related default values for IAA are incorrect in current code: (1) The max batch size of device is set during device initialization, that indicates batch is supported. It should be always 0 on IAA. (2) The max batch size of work queue is set to WQ_DEFAULT_MAX_BATCH (32) as the default value regardless of Intel DSA or IAA device during work queue setup and cleanup. It should be always 0 on IAA. Fix the issues by setting the max batch size of device and max batch size of work queue to 0 on IAA device, that means batch is not supported. [1]: https://cdrdv2.intel.com/v1/dl/getContent/721858 Fixes: 23084545 ("dmaengine: idxd: set max_xfer and max_batch for RO device") Fixes: 92452a72 ("dmaengine: idxd: set defaults for wq configs") Fixes: bfe1d560 ("dmaengine: idxd: Init and probe for Intel data accelerators") Signed-off-by: -
Doug Brown authored
The first IRQ is required, but IRQs 1 through (nb_phy_chans - 1) are optional, because on some platforms (e.g. PXA168) there is a single IRQ shared between all channels. This change inhibits a flood of "IRQ index # not found" messages at startup. Tested on a PXA168-based device. Fixes: 7723f4c5 ("driver core: platform: Add an error message to platform_get_irq*()") Signed-off-by:
Doug Brown <doug@schmorgal.com> Link: https://lore.kernel.org/r/20220906000709.52705-1-doug@schmorgal.comSigned-off-by:
-
- 04 Nov, 2022 8 commits
-
-
Yang Yingliang authored
Add missing devm_acpi_dma_controller_free() to devres.rst, it's introduced by commit 1b2e98bc ("dma: acpi-dma: introduce ACPI DMA helpers"). Fixes: 1b2e98bc ("dma: acpi-dma: introduce ACPI DMA helpers") Cc: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Cc: Mika Westerberg <mika.westerberg@linux.intel.com> Cc: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Cc: Vinod Koul <vinod.koul@intel.com> Cc: Jonathan Corbet <corbet@lwn.net> Signed-off-by:
Andy Shevchenko <andriy.shevchenko@linux.intel.com> Link: https://lore.kernel.org/r/20221102022701.1407289-1-yangyingliang@huawei.comSigned-off-by:
-
Adam Skladowski authored
Document the compatible for GPI DMA controller on SM6115 SoC. Signed-off-by:
Adam Skladowski <a39.skl@gmail.com> Signed-off-by:
Iskren Chernev <iskren.chernev@gmail.com> Acked-by:
Rob Herring <robh@kernel.org> Link: https://lore.kernel.org/r/20221030094258.486428-4-iskren.chernev@gmail.comSigned-off-by:
-
Xiaochen Shen authored
In current code, the following sysfs attributes are exposed to user to show or update the values: max_read_buffers (max_tokens) read_buffer_limit (token_limit) group/read_buffers_allowed (group/tokens_allowed) group/read_buffers_reserved (group/tokens_reserved) group/use_read_buffer_limit (group/use_token_limit) >From Intel IAA spec [1], Intel IAA does not support Read Buffer allocation control. So these sysfs attributes should not be supported on IAA device. Fix this issue by making these sysfs attributes invisible through is_visible() filter when the device is IAA. Add description in the ABI documentation to mention that these attributes are not visible when the device does not support Read Buffer allocation control. [1]: https://cdrdv2.intel.com/v1/dl/getContent/721858 Fixes: fde212e4 ("dmaengine: idxd: deprecate token sysfs attributes for read buffers") Fixes: c52ca478 ("dmaengine: idxd: add configuration component of driver") Signed-off-by:
-
Stephen Kitt authored
shdma-arm.h was introduced with commit 1e69653d ("DMA: shdma: add r8a73a4 DMAC data to the device ID table"), and its sole user was removed with commit a1978861 ("dmaengine: sh: Remove R-Mobile APE6 support"). The latter mentions r8a73a4.dtsi but shdma support was removed from that with commit cfda8203 ("ARM: dts: r8a73a4: Remove non-functional DMA support"), so it seems this is safe to remove. Signed-off-by:
Stephen Kitt <steve@sk2.org> Reviewed-by:
Geert Uytterhoeven <geert+renesas@glider.be> Link: https://lore.kernel.org/r/20221028115336.1052782-1-steve@sk2.orgSigned-off-by:
-
Radhey Shyam Pandey authored
document xilinx_dma_device_config() return value. Fixes below kernel-doc warning. xilinx_dma.c:1665: warning: No description found for return value of 'xilinx_dma_device_config' Signed-off-by:
Radhey Shyam Pandey <radhey.shyam.pandey@amd.com> Link: https://lore.kernel.org/r/1666683737-7668-3-git-send-email-radhey.shyam.pandey@amd.comSigned-off-by:
-
Radhey Shyam Pandey authored
Modify xilinx_dma_child_probe() return documentation to be inline with implementation i.e. can also return failure value on error. Signed-off-by:
-
Arnd Bergmann authored
The s3c24xx platform was removed and this driver is no longer needed. Signed-off-by:
Arnd Bergmann <arnd@arndb.de> Reviewed-by:
Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Link: https://lore.kernel.org/r/20221021203329.4143397-14-arnd@kernel.orgSigned-off-by:
-
Lukas Bulwahn authored
Commit cd0ab43e ("dmaengine: remove iop-adma driver") removes the driver's source code, but misses to remove the MAINTAINERS section. Hence, ./scripts/get_maintainer.pl --self-test=patterns complains about a broken file pattern. Remove the INTEL IOP-ADMA DMA DRIVER section pointing to the removed driver. Signed-off-by:
Lukas Bulwahn <lukas.bulwahn@gmail.com> Acked-by:
Dan Williams <dan.j.williams@intel.com> Link: https://lore.kernel.org/r/20221020082103.29218-1-lukas.bulwahn@gmail.comSigned-off-by:
-
- 19 Oct, 2022 7 commits
-
-
Arnd Bergmann authored
The iop32x platform was removed, so this driver is no longer needed. Cc: Dan Williams <dan.j.williams@intel.com> Signed-off-by:
-
Martin Povišer authored
There's a previously unknown part of the controller interface: We have to assign SRAM carveouts to channels to store their in-flight samples in. So, obtain the size of the SRAM from a read-only register and divide it into 2K blocks for allocation to channels. The FIFO depths we configure will always fit into 2K. (This fixes audio artifacts during simultaneous playback/capture on multiple channels -- which looking back is fully accounted for by having had the caches in the DMA controller overlap in memory.) Fixes: b127315d ("dmaengine: apple-admac: Add Apple ADMAC driver") Signed-off-by:
-
Xiaochen Shen authored
In current code, dev.max_batch_size and wq.max_batch_size attributes in sysfs are exposed to user to show or update the values. >From Intel IAA spec [1], Intel IAA does not support batch processing. So these sysfs attributes should not be supported on IAA device. Fix this issue by making the attributes of max_batch_size invisible in sysfs through is_visible() filter when the device is IAA. Add description in the ABI documentation to mention that the attributes are not visible when the device does not support batch. [1]: https://cdrdv2.intel.com/v1/dl/getContent/721858 Fixes: e7184b15 ("dmaengine: idxd: add support for configurable max wq batch size") Fixes: c52ca478 ("dmaengine: idxd: add configuration component of driver") Signed-off-by:
-
Uwe Kleine-König authored
The function idma64_remove() returns zero unconditionally. Make it return void. This is a preparation for making platform remove callbacks return void. Signed-off-by:
Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Link: https://lore.kernel.org/r/20221014161250.468687-1-u.kleine-koenig@pengutronix.deSigned-off-by:
-
Siarhei Volkau authored
The JZ4755 has 4 DMA channels per DMA unit, two idential DMA units. The JZ4755 has the similar DMA engine to JZ4725b and it has the same bug as JZ4725b, see commit a40c94be. At least the JZ_SOC_DATA_BREAK_LINKS flag make it work much better, although not ideal. Reviewed-by:
Paul Cercueil <paul@crapouillou.net> Tested-by:
Siarhei Volkau <lis8215@gmail.com> Signed-off-by:
-
Siarhei Volkau authored
Update documentation prior to adding driver changes. Acked-by:
-
Fenghua Yu authored
When the idxd_user_drv driver is bound to a Work Queue (WQ) device without IOMMU or with IOMMU Passthrough without Shared Virtual Addressing (SVA), the application gains direct access to physical memory via the device by programming physical address to a submitted descriptor. This allows direct userspace read and write access to arbitrary physical memory. This is inconsistent with the security goals of a good kernel API. Unlike vfio_pci driver, the IDXD char device driver does not provide any ways to pin user pages and translate the address from user VA to IOVA or PA without IOMMU SVA. Therefore the application has no way to instruct the device to perform DMA function. This makes the char device not usable for normal application usage. Since user type WQ without SVA cannot be used for normal application usage and presents the security issue, bind idxd_user_drv driver and enable user type WQ only when SVA is enabled (i.e. user PASID is enabled). Fixes: 448c3de8 ("dmaengine: idxd: create user driver for wq 'device'") Cc: stable@vger.kernel.org Suggested-by:
Arjan Van De Ven <arjan.van.de.ven@intel.com> Signed-off-by:
Jerry Snitselaar <jsnitsel@redhat.com> Link: https://lore.kernel.org/r/20221014222541.3912195-1-fenghua.yu@intel.comSigned-off-by:
-
