#
e54df523 |
|
24-Jan-2024 |
Siddharth Vadapalli <s-vadapalli@ti.com> |
dmaengine: ti: k3-udma-glue: Add function to request RX chan for thread ID The existing function k3_udma_glue_request_remote_rx_chn() supports requesting an RX DMA channel and flow by the name of the RX DMA channel. Add support to request RX DMA channel for a given thread ID in the form of a new function named k3_udma_glue_request_remote_rx_chn_for_thread_id(). Also, export it for use by drivers which are probed by alternate methods (non device-tree) but still wish to make use of the existing DMA APIs. Such drivers could be informed about the thread ID corresponding to the RX DMA channel by RPMsg for example. Since the new function k3_udma_glue_request_remote_rx_chn_for_thread_id() reuses most of the code in k3_udma_glue_request_remote_rx_chn(), create a new function named k3_udma_glue_request_remote_rx_chn_common() for the common code. Signed-off-by: Siddharth Vadapalli <s-vadapalli@ti.com> Acked-by: Peter Ujfalusi <peter.ujfalusi@gmail.com> Link: https://lore.kernel.org/r/20240124124319.820002-5-s-vadapalli@ti.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
|
#
7cbf7f4b |
|
24-Jan-2024 |
Siddharth Vadapalli <s-vadapalli@ti.com> |
dmaengine: ti: k3-udma-glue: Add function to request TX chan for thread ID The existing function k3_udma_glue_request_tx_chn() supports requesting a TX DMA channel by its name. Add a new function to request TX DMA channel for a given thread ID, named k3_udma_glue_request_tx_chn_for_thread_id(). Also, export it for use by drivers which are probed by alternate methods (non device-tree) but still wish to make use of the existing DMA APIs. Such drivers could be informed about the thread ID corresponding to the TX DMA channel by RPMsg for example. Since the new function k3_udma_glue_request_tx_chn_for_thread_id() reuses most of the code in k3_udma_glue_request_tx_chn(), create a new function for the common code, named k3_udma_glue_request_tx_chn_common(). Signed-off-by: Siddharth Vadapalli <s-vadapalli@ti.com> Acked-by: Peter Ujfalusi <peter.ujfalusi@gmail.com> Link: https://lore.kernel.org/r/20240124124319.820002-4-s-vadapalli@ti.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
|
#
7edd7a2f |
|
24-Jan-2024 |
Siddharth Vadapalli <s-vadapalli@ti.com> |
dmaengine: ti: k3-udma-glue: Update name for remote RX channel device A single RX Channel can have multiple flows. It is possible that a single device requests multiple flows on the same RX Channel. In such cases, the existing implementation of naming the device on the basis of the RX Channel can result in duplicate names. The existing implementation only uses the RX Channel source thread when naming, which implies duplicate names when different flows are being requested on the same RX Channel. In order to avoid duplicate names, include the RX flow as well in the name. Signed-off-by: Siddharth Vadapalli <s-vadapalli@ti.com> Acked-by: Peter Ujfalusi <peter.ujfalusi@gmail.com> Link: https://lore.kernel.org/r/20240124124319.820002-3-s-vadapalli@ti.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
|
#
81a1f90f |
|
24-Jan-2024 |
Siddharth Vadapalli <s-vadapalli@ti.com> |
dmaengine: ti: k3-udma-glue: Add function to parse channel by ID The existing helper function of_k3_udma_glue_parse() fetches the DMA Channel thread ID from the device-tree node. This makes it necessary to have a device-tree node with the Channel thread IDs populated. However, in the case where the thread ID is known by alternate methods (an example being that of Firmware running on remote core sharing details of the thread IDs), there is no equivalent function to implement the functionality of the existing of_k3_udma_glue_parse() function. In such cases, the driver utilizing the DMA APIs might not even have a device-tree node to begin with, since it could be probed with other methods (RPMsg-Bus for example). Add the of_k3_udma_glue_parse_chn_by_id() helper function which accepts the thread ID as an argument, thereby making it unnecessary to have a device-tree node for obtaining the thread ID. Since of_k3_udma_glue_parse() and of_k3_udma_glue_parse_chn_by_id() share a lot of code in common, create a new function to handle the common code which is named as of_k3_udma_glue_parse_chn_common(). Signed-off-by: Siddharth Vadapalli <s-vadapalli@ti.com> Acked-by: Peter Ujfalusi <peter.ujfalusi@gmail.com> Link: https://lore.kernel.org/r/20240124124319.820002-2-s-vadapalli@ti.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
|
#
f9a1d321 |
|
26-Sep-2023 |
Dan Carpenter <dan.carpenter@linaro.org> |
dmaengine: ti: k3-udma-glue: clean up k3_udma_glue_tx_get_irq() return The k3_udma_glue_tx_get_irq() function currently returns negative error codes on error, zero on error and positive values for success. This complicates life for the callers who need to propagate the error code. Also GCC will not warn about unsigned comparisons when you check: if (unsigned_irq <= 0) All the callers have been fixed now but let's just make this easy going forward. Signed-off-by: Dan Carpenter <dan.carpenter@linaro.org> Reviewed-by: Roger Quadros <rogerq@kernel.org> Acked-by: Vinod Koul <vkoul@kernel.org> Signed-off-by: David S. Miller <davem@davemloft.net>
|
#
56b0a668 |
|
29-Sep-2022 |
Kevin Hilman <khilman@baylibre.com> |
dmaengine: ti: convert k3-udma to module Currently k3-udma driver is built as separate platform drivers with a shared probe and identical code path, just differnet platform data. To enable to build as module, convert the separate platform driver into a single module_platform_driver with the data selection done via compatible string and of_match. The separate of_match tables are also combined into a single table to avoid the multiple calls to of_match_node() Since all modern TI platforms using this are DT enabled, the removal of separate platform_drivers should have no functional change. Acked-by: Peter Ujfalusi <peter.ujfalusi@gmail.com> Signed-off-by: Kevin Hilman <khilman@baylibre.com> Link: https://lore.kernel.org/r/20220929234820.940048-3-khilman@baylibre.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
|
#
ac2b9f34 |
|
20-Oct-2022 |
Yang Yingliang <yangyingliang@huawei.com> |
dmaengine: ti: k3-udma-glue: fix memory leak when register device fail 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>
|
#
5b65781d |
|
08-Dec-2020 |
Vignesh Raghavendra <vigneshr@ti.com> |
dmaengine: ti: k3-udma-glue: Add support for K3 PKTDMA 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>
|
#
d553e2ab |
|
08-Dec-2020 |
Peter Ujfalusi <peter.ujfalusi@ti.com> |
dmaengine: ti: k3-udma-glue: Configure the dma_dev for rings 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>
|
#
aa8a4c4e |
|
08-Dec-2020 |
Peter Ujfalusi <peter.ujfalusi@ti.com> |
dmaengine: ti: k3-udma-glue: Get the ringacc from udma_dev 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>
|
#
426506a7 |
|
08-Dec-2020 |
Peter Ujfalusi <peter.ujfalusi@ti.com> |
dmaengine: ti: k3-udma-glue: Add function to get device pointer for DMA API 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>
|
#
69973b48 |
|
30-Oct-2020 |
Grygorii Strashko <grygorii.strashko@ti.com> |
dmaengine: ti: k3-udma-glue: move psi-l pairing in channel en/dis functions 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>
|
#
52c74d3d |
|
16-Sep-2020 |
Grygorii Strashko <grygorii.strashko@ti.com> |
dmaengine: ti: k3-udma-glue: fix channel enable functions 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>
|
#
6259c844 |
|
11-Sep-2020 |
Peter Ujfalusi <peter.ujfalusi@ti.com> |
dmaengine: ti: k3-udma-glue: Fix parameters for rx ring pair request 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>
|
#
4927b1ab |
|
24-Jul-2020 |
Peter Ujfalusi <peter.ujfalusi@ti.com> |
dmaengine: ti: k3-udma: Switch to k3_ringacc_request_rings_pair 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>
|
#
bc7e5523 |
|
07-Jul-2020 |
Peter Ujfalusi <peter.ujfalusi@ti.com> |
dmaengine: ti: k3-udma: Use common defines for TCHANRT/RCHANRT registers 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>
|
#
018af9be |
|
18-Mar-2020 |
Christophe JAILLET <christophe.jaillet@wanadoo.fr> |
dmaengine: ti: k3-udma-glue: Fix an error handling path in '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>
|
#
0ebcf1a2 |
|
18-Feb-2020 |
Peter Ujfalusi <peter.ujfalusi@ti.com> |
dmaengine: ti: k3-udma: Implement support for atype (for virtualization) 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>
|
#
d7024191 |
|
23-Dec-2019 |
Grygorii Strashko <grygorii.strashko@ti.com> |
dmaengine: ti: k3-udma: Add glue layer for non DMAengine users 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>
|