summaryrefslogtreecommitdiff
path: root/drivers/dma/ti/k3-udma-glue.c
AgeCommit message (Collapse)AuthorFilesLines
2022-11-08dmaengine: ti: k3-udma-glue: fix memory leak when register device failYang Yingliang1-0/+3
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: 5b65781d06ea ("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.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2020-12-11dmaengine: ti: k3-udma-glue: Add support for K3 PKTDMAVignesh Raghavendra1-38/+253
This commit adds support for PKTDMA in k3-udma glue driver. Use new psil_endpoint_config struct to get static data for a given channel or a flow during setup. Make sure that the RX flows being mapped to a RX channel is within the range of flows that is been allocated to that RX channel. Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com> Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Link: https://lore.kernel.org/r/20201208090440.31792-21-peter.ujfalusi@ti.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2020-12-11dmaengine: ti: k3-udma-glue: Configure the dma_dev for ringsPeter Ujfalusi1-0/+8
Rings in RING mode should be using the DMA device for DMA API as in this mode the ringacc will not access the ring memory in any ways, but the DMA is. Fix up the ring configuration and set the dma_dev unconditionally and let the ringacc driver to select the correct device to use for DMA API. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Reviewed-by: Grygorii Strashko <grygorii.strashko@ti.com> Link: https://lore.kernel.org/r/20201208090440.31792-7-peter.ujfalusi@ti.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2020-12-11dmaengine: ti: k3-udma-glue: Get the ringacc from udma_devPeter Ujfalusi1-5/+1
If of_xudma_dev_get() returns with the valid udma_dev then the driver already got the ringacc, there is no need to execute of_k3_ringacc_get_by_phandle() for each channel via the glue layer. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Reviewed-by: Grygorii Strashko <grygorii.strashko@ti.com> Link: https://lore.kernel.org/r/20201208090440.31792-6-peter.ujfalusi@ti.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2020-12-11dmaengine: ti: k3-udma-glue: Add function to get device pointer for DMA APIPeter Ujfalusi1-0/+14
Glue layer users should use the device of the DMA for DMA mapping and allocations as it is the DMA which accesses to descriptors and buffers, not the clients Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Reviewed-by: Grygorii Strashko <grygorii.strashko@ti.com> Link: https://lore.kernel.org/r/20201208090440.31792-5-peter.ujfalusi@ti.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2020-11-09dmaengine: ti: k3-udma-glue: move psi-l pairing in channel en/dis functionsGrygorii Strashko1-26/+38
The NAVSS UDMA will stuck if target IP module is disabled by PM while PSI-L threads are paired UDMA<->IP and no further transfers is possible. This could be the case for IPs J721E Main CPSW (cpsw9g). Hence, to avoid such situation do PSI-L threads pairing only when UDMA channel is going to be enabled as at this time DMA consumer module expected to be active already. Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com> Acked-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Link: https://lore.kernel.org/r/20201030203000.4281-1-grygorii.strashko@ti.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2020-10-24Merge tag 'armsoc-drivers' of ↵Linus Torvalds1-1/+1
git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc Pull ARM SoC-related driver updates from Olof Johansson: "Various driver updates for platforms. A bulk of this is smaller fixes or cleanups, but some of the new material this time around is: - Support for Nvidia Tegra234 SoC - Ring accelerator support for TI AM65x - PRUSS driver for TI platforms - Renesas support for R-Car V3U SoC - Reset support for Cortex-M4 processor on i.MX8MQ There are also new socinfo entries for a handful of different SoCs and platforms" * tag 'armsoc-drivers' of git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc: (131 commits) drm/mediatek: reduce clear event soc: mediatek: cmdq: add clear option in cmdq_pkt_wfe api soc: mediatek: cmdq: add jump function soc: mediatek: cmdq: add write_s_mask value function soc: mediatek: cmdq: add write_s value function soc: mediatek: cmdq: add read_s function soc: mediatek: cmdq: add write_s_mask function soc: mediatek: cmdq: add write_s function soc: mediatek: cmdq: add address shift in jump soc: mediatek: mtk-infracfg: Fix kerneldoc soc: amlogic: pm-domains: use always-on flag reset: sti: reset-syscfg: fix struct description warnings reset: imx7: add the cm4 reset for i.MX8MQ dt-bindings: reset: imx8mq: add m4 reset reset: Fix and extend kerneldoc reset: reset-zynqmp: Added support for Versal platform dt-bindings: reset: Updated binding for Versal reset driver reset: imx7: Support module build soc: fsl: qe: Remove unnessesary check in ucc_set_tdm_rxtx_clk soc: fsl: qman: convert to use be32_add_cpu() ...
2020-09-18dmaengine: ti: k3-udma-glue: fix channel enable functionsGrygorii Strashko1-14/+3
Now the K3 UDMA glue layer enable functions perform RMW operation on UDMA RX/TX RT_CTL registers to set EN bit and enable channel, which is incorrect, because only EN bit has to be set in those registers to enable channel (all other bits should be cleared 0). More over, this causes issues when bootloader leaves UDMA channel RX/TX RT_CTL registers in incorrect state - TDOWN bit set, for example. As result, UDMA channel will just perform teardown right after it's enabled. Hence, fix it by writing correct values (EN=1) directly in UDMA channel RX/TX RT_CTL registers in k3_udma_glue_enable_tx/rx_chn() functions. Fixes: d70241913413 ("dmaengine: ti: k3-udma: Add glue layer for non DMAengine users") Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com> Acked-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Link: https://lore.kernel.org/r/20200916120955.7963-1-grygorii.strashko@ti.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2020-09-12dmaengine: ti: k3-udma-glue: Fix parameters for rx ring pair requestPeter Ujfalusi1-1/+1
The original commit mixed up the forward and completion ring IDs for the rx flow configuration. Acked-by: Vinod Koul <vkoul@kernel.org> Reviewed-by: Grygorii Strashko <grygorii.strashko@ti.com> Fixes: 4927b1ab2047 ("dmaengine: ti: k3-udma: Switch to k3_ringacc_request_rings_pair") Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by: Santosh Shilimkar <santosh.shilimkar@oracle.com>
2020-08-07Merge tag 'dmaengine-5.9-rc1' of ↵Linus Torvalds1-41/+38
git://git.kernel.org/pub/scm/linux/kernel/git/vkoul/dmaengine Pull dmaengine updates from Vinod Koul: "Core: - Support out of order dma completion - Support for repeating transaction New controllers: - Support for Actions S700 DMA engine - Renesas R8A774E1, r8a7742 controller binding - New driver for Xilinx DPDMA controller Other: - Support of out of order dma completion in idxd driver - W=1 warning cleanup of subsystem - Updates to ti-k3-dma, dw, idxd drivers" * tag 'dmaengine-5.9-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/vkoul/dmaengine: (68 commits) dmaengine: dw: Don't include unneeded header to platform data header dmaengine: Actions: Add support for S700 DMA engine dmaengine: Actions: get rid of bit fields from dma descriptor dt-bindings: dmaengine: convert Actions Semi Owl SoCs bindings to yaml dmaengine: idxd: add missing invalid flags field to completion dmaengine: dw: Initialize max_sg_burst capability dmaengine: dw: Introduce max burst length hw config dmaengine: dw: Initialize min and max burst DMA device capability dmaengine: dw: Set DMA device max segment size parameter dmaengine: dw: Take HC_LLP flag into account for noLLP auto-config dmaengine: Introduce DMA-device device_caps callback dmaengine: Introduce max SG burst capability dmaengine: Introduce min burst length capability dt-bindings: dma: dw: Add max burst transaction length property dt-bindings: dma: dw: Convert DW DMAC to DT binding dmaengine: ti: k3-udma: Query throughput level information from hardware dmaengine: ti: k3-udma: Use defines for capabilities register parsing dmaengine: xilinx: dpdma: Fix kerneldoc warning dmaengine: xilinx: dpdma: add missing kernel doc dmaengine: xilinx: dpdma: remove comparison of unsigned expression ...
2020-07-25dmaengine: ti: k3-udma: Switch to k3_ringacc_request_rings_pairPeter Ujfalusi1-29/+13
We only request ring pairs via K3 DMA driver, switch to use the new k3_ringacc_request_rings_pair() to simplify the code. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com> Acked-by: Vinod Koul <vkoul@kernel.org> Signed-off-by: Santosh Shilimkar <santosh.shilimkar@oracle.com>
2020-07-15dmaengine: ti: k3-udma: Use common defines for TCHANRT/RCHANRT registersPeter Ujfalusi1-41/+38
The register offsets and functions are the same among TCHAN and RCHAN. Use generic, common names for them. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Reviewed-by: Grygorii Strashko <grygorii.strashko@ti.com> Link: https://lore.kernel.org/r/20200707102352.28773-4-peter.ujfalusi@ti.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2020-04-03Merge tag 'dmaengine-5.7-rc1' of git://git.infradead.org/users/vkoul/slave-dmaLinus Torvalds1-2/+16
Pull dmaengine updates from Vinod Koul: "Core: - Some code cleanup and optimization in core by Andy - Debugfs support for displaying dmaengine channels by Peter Drivers: - New driver for uniphier-xdmac controller - Updates to stm32 dma, mdma and dmamux drivers and PM support - More updates to idxd drivers - Bunch of changes in tegra-apb driver and cleaning up of pm functions - Bunch of spelling fixes and Replace zero-length array patches - Shutdown hook for fsl-dpaa2-qdma driver - Support for interleaved transfers for ti-edma and virtualization support for k3-dma driver - Support for reset and updates in xilinx_dma driver - Improvements and locking updates in at_hdma driver" * tag 'dmaengine-5.7-rc1' of git://git.infradead.org/users/vkoul/slave-dma: (89 commits) dt-bindings: dma: renesas,usb-dmac: add r8a77961 support dmaengine: uniphier-xdmac: Remove redandant error log for platform_get_irq dmaengine: tegra-apb: Improve DMA synchronization dmaengine: tegra-apb: Don't save/restore IRQ flags in interrupt handler dmaengine: tegra-apb: mark PM functions as __maybe_unused dmaengine: fix spelling mistake "exceds" -> "exceeds" dmaengine: sprd: Set request pending flag when DMA controller is active dmaengine: ppc4xx: Use scnprintf() for avoiding potential buffer overflow dmaengine: idxd: remove global token limit check dmaengine: idxd: reflect shadow copy of traffic class programming dmaengine: idxd: Merge definition of dsa_batch_desc into dsa_hw_desc dmaengine: Create debug directories for DMA devices dmaengine: ti: k3-udma: Implement custom dbg_summary_show for debugfs dmaengine: Add basic debugfs support dmaengine: fsl-dpaa2-qdma: remove set but not used variable 'dpaa2_qdma' dmaengine: ti: edma: fix null dereference because of a typo in pointer name dmaengine: fsl-dpaa2-qdma: Adding shutdown hook dmaengine: uniphier-xdmac: Add UniPhier external DMA controller driver dt-bindings: dmaengine: Add UniPhier external DMA controller bindings dmaengine: ti: k3-udma: Implement support for atype (for virtualization) ...
2020-03-23dmaengine: ti: k3-udma-glue: Fix an error handling path in ↵Christophe JAILLET1-10/+19
'k3_udma_glue_cfg_rx_flow()' All but one error handling paths in the 'k3_udma_glue_cfg_rx_flow()' function 'goto err' and call 'k3_udma_glue_release_rx_flow()'. This not correct because this function has a 'channel->flows_ready--;' at the end, but 'flows_ready' has not been incremented here, when we branch to the error handling path. In order to keep a correct value in 'flows_ready', un-roll 'k3_udma_glue_release_rx_flow()', simplify it, add some labels and branch at the correct places when an error is detected. Doing so, we also NULLify 'flow->udma_rflow' in a path that was lacking it. Fixes: d70241913413 ("dmaengine: ti: k3-udma: Add glue layer for non DMAengine user") Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr> Acked-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Link: https://lore.kernel.org/r/20200318191209.1267-1-christophe.jaillet@wanadoo.fr Signed-off-by: Vinod Koul <vkoul@kernel.org>
2020-03-02dmaengine: ti: k3-udma: Implement support for atype (for virtualization)Peter Ujfalusi1-2/+16
The DT for virtualized hosts have dma-cells == 2 where the second parameter is the ATYPE for the channel. In case of dma-cells == 1 we can configure the ATYPE as 0 (reset value). The ATYPE defined for j721e are: 0: pointers are physical addresses (no translation) 1: pointers are intermediate addresses (PVU) 2: pointers are virtual addresses (SMMU) Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Link: https://lore.kernel.org/r/20200218143126.11361-3-peter.ujfalusi@ti.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2020-01-21dmaengine: ti: k3-udma: Add glue layer for non DMAengine usersGrygorii Strashko1-0/+1198
Certain users can not use right now the DMAengine API due to missing features in the core. Prime example is Networking. These users can use the glue layer interface to avoid misuse of DMAengine API and when the core gains the needed features they can be converted to use generic API. The most prominent features the glue layer clients are depending on: - most PSI-L native peripheral use extra rflow ranges on a receive channel and depending on the peripheral's configuration packets from a single free descriptor ring is going to be received to different receive ring - it is also possible to have different free descriptor rings per rflow and an rflow can also support 4 additional free descriptor ring based on the size of the incoming packet - out of order completion of descriptors on a channel - when we have several queues to handle different priority packets the descriptors will be completed 'out-of-order' - the notion of prep_slave_sg is not matching with what the streaming type of operation is demanding for networking - Streaming type of operation - Ability to fill the free descriptor ring with descriptors in anticipation of incoming traffic and when a packet arrives UDMAP will form a packet and gives it to the client driver - the descriptors are not backed with exact size data buffers as we don't know the size of the packet we will receive, but as a generic pool of buffers to be used by the receive channel - NAPI type of operation (polling instead of interrupt driven transfer) - without this we can not sustain gigabit speeds and we need to support NAPI - not to limit this to networking, but other high performance operations Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com> Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Tested-by: Keerthy <j-keerthy@ti.com> Link: https://lore.kernel.org/r/20191223110458.30766-12-peter.ujfalusi@ti.com Signed-off-by: Vinod Koul <vkoul@kernel.org>