summaryrefslogtreecommitdiff
path: root/drivers/dma/ti
AgeCommit message (Collapse)Author
2026-01-09dm: core: Default to using DEVRES outside of xPLTom Rini
The devm alloc functions that we have may follow the Linux kernel model where allocations are (almost always) automatically free()'d. However, quite often we don't enable, in full U-Boot, the tracking and free()'ing functionality. This in turn leads to memory leaks because the driver author expects that since the functions have the same name as in the Linux Kernel they have the same behavior. In turn we then get functionally correct commits such as commit 00e1fed93c8c ("firmware: ti_sci: Fix memory leaks in devm_ti_sci_get_of_resource") that manually add these calls. Rather than manually tracking allocations and implementing free()s, rework things so that we follow expectations by enabling the DEVRES functionality (outside of xPL phases). This turns DEVRES from a prompted symbol to a symbol that must be select'd, and we now remove our non-managed alloc/free functions from outside of xPL builds. Reviewed-by: Michael Trimarchi <michael@amarulasolutions.com> Signed-off-by: Tom Rini <trini@konsulko.com>
2025-09-11dma: ti: k3-udma: fix dma_addr_t typecastsAnshul Dalal
dma_addr_t is used to store any valid DMA address which might not necessarily be the same size as host architecture's word size. Though various typecasts in k3's dma and usb driver expect dma_addr_t to be the same size as the word size. This leads the compiler to throw a "cast from pointer to integer of different size" warning when the condition is not met, for example when enabling CONFIG_DMA_ADDR_T_64BIT for the R5 core. Therefore this patch fixes the typecasts by using 'uintptr_t' as an intermediary type which is guaranteed to be the same size as void* on the host architecture. Thus, eliminating the compiler warning. Signed-off-by: Anshul Dalal <anshuld@ti.com>
2025-04-05arm: mach-k3: j721e: Split out J7200 SoC support from J721eAndrew Davis
Currently in j721e_init.c we check which firewalls to remove using the board configuration (e.g CONFIG_TARGET_J721E_R5_EVM). We do this as J721e and J7200 have different IP and firewalls but use the same SoC definition (SOC_K3_J721E) even though they are different SoCs. The idea was they would be similar enough that they both could use the same SoC config to help with common code sharing. Board checks would then be used differentiate. This has grown far too messy to maintain any more, especially now that there is more than one board using J721e (EVM, SK, Beagle AI64). As differentiation is done based on board, every one of these boards would have to have checks added for them. Instead let's split J7200 support out from J721e like how normal new SoC support is done. This patch touches several subsystems and could not be split much better as when we add SOC_K3_J7200 we want to make use of it in all spots that once used the combined SOC_K3_J721E so we can turn off SOC_K3_J721E when building for J7200 boards. Signed-off-by: Andrew Davis <afd@ti.com>
2025-02-28dma: ti: k3-udma: Avoid Memory leak issues during dma memcpyPrasanth Babu Mantena
During dma memcpy, bcdma descriptor gets allocated for each transaction and not freed after completion of that transaction. So, avoid the memory allocation for every transaction. Add one descriptor per dma device and allocate it once in resource setup. This descriptor can now be used for all dma memcpy transactions optimally. Signed-off-by: Prasanth Babu Mantena <p-mantena@ti.com>
2024-12-31dma: ti: k3-udma: Fix BCDMA probe by adding check for MMR_RFLOWPrasanth Babu Mantena
RFLOW config related MMR does not exist incase of BCDMA. Add check to bypass the RFLOW MMR extraction. Without this, the probe sequence fails checking for the MMR_RFLOW region, which is valid only for packet based DMA and obselete for BCDMA. Fixes: 5abb694d6016 ("dma: ti: k3-udma: Add support for native configuration of chan/flow") Signed-off-by: Prasanth Babu Mantena <p-mantena@ti.com> Tested-by: Jonathan Humphreys <j-humphreys@ti.com>
2024-10-17dma: ti: k3-udma: Move DMA channel[0] allocation to probe and add udma_remove()Santhosh Kumar K
Currently, the allocation of DMA channel[0] for memcpy is happening in udma_transfer() for every transfer, which leads to a huge overhead for each transfer, especially in case of nand page reads. So, move this allocation to udma_probe(), as a result, the allocation is done once during probe. Introduce udma_remove() for the cleanup of allocated channel during probe. Signed-off-by: Santhosh Kumar K <s-k6@ti.com> Signed-off-by: Prasanth Babu Mantena <p-mantena@ti.com>
2024-10-17dma: ti: k3-udma: Move udma_probe() below all APIsSanthosh Kumar K
The udma_probe() function was placed above many important APIs related to bcdma, pktdma, which restricts these APIs to be accessed during probe. So, move udma_probe() below all of them. Signed-off-by: Santhosh Kumar K <s-k6@ti.com> Signed-off-by: Prasanth Babu Mantena <p-mantena@ti.com>
2024-08-30dma: ti: k3-udma: Add support for native configuration of chan/flowKishon Vijay Abraham I
In absence of Device Manager (DM) services such as at R5 SPL stage, driver will have to natively setup TCHAN/RCHAN/RFLOW cfg registers. Existing UDMA driver performed the above mentioned configuration for UDMA. Add similar configuration for PKTDMA here. Reviewed-by: Alexander Sverdlin <alexander.sverdlin@siemens.com> Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com> Signed-off-by: Siddharth Vadapalli <s-vadapalli@ti.com> Signed-off-by: Chintan Vankar <c-vankar@ti.com>
2024-07-22drivers: dma: Remove duplicate newlinesMarek Vasut
Drop all duplicate newlines. No functional change. Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
2024-05-20Restore patch series "arm: dts: am62-beagleplay: Fix Beagleplay Ethernet"Tom Rini
As part of bringing the master branch back in to next, we need to allow for all of these changes to exist here. Reported-by: Jonas Karlman <jonas@kwiboo.se> Signed-off-by: Tom Rini <trini@konsulko.com>
2024-05-20Merge tag 'v2024.07-rc3' into nextTom Rini
Prepare v2024.07-rc3
2024-05-19Revert "Merge patch series "arm: dts: am62-beagleplay: Fix Beagleplay Ethernet""Tom Rini
When bringing in the series 'arm: dts: am62-beagleplay: Fix Beagleplay Ethernet"' I failed to notice that b4 noticed it was based on next and so took that as the base commit and merged that part of next to master. This reverts commit c8ffd1356d42223cbb8c86280a083cc3c93e6426, reversing changes made to 2ee6f3a5f7550de3599faef9704e166e5dcace35. Reported-by: Jonas Karlman <jonas@kwiboo.se> Signed-off-by: Tom Rini <trini@konsulko.com>
2024-05-15dma: ti: k3-udma: invalidate prepared buffers before pushing to recv ringMatthias Schiffer
Buffers must not have an unclean cache before being used for DMA - a pending write-back may corrupt the next dev-to-mem transfer otherwise. This was consistently noticeable during long TFTP transfers, when an ARP request is answered by U-Boot in the middle of the transfer: As U-Boot's arp_receive() reuses the receive buffer to prepare its reply packet, the beginning of one of the next incoming TFTP packets is overwritten by the ARP reply. The corrupted packet is ignored, but the TFTP transfer stalls for a few seconds until a timeout is detected and a retransmit is triggered. Signed-off-by: Matthias Schiffer <matthias.schiffer@ew.tq-group.com> Tested-by: Alexander Sverdlin <alexander.sverdlin@siemens.com>
2024-05-15dma: ti: k3-udma: add missing <net.h> includeMatthias Schiffer
net.h is needed for PKTBUFSRX. Without this definition, the driver will always use 4 RX buffers, causing am65-cpsw-nuss initialization to fail when a higher number of buffers is requested. Signed-off-by: Matthias Schiffer <matthias.schiffer@ew.tq-group.com>
2024-05-07dma: Remove <common.h> and add needed includesTom Rini
Remove <common.h> from this driver directory and when needed add missing include files directly. Signed-off-by: Tom Rini <trini@konsulko.com>
2024-03-13dma: ti: k3-udma: Add DMA PSIL mappings for AM62P and J722SVignesh Raghavendra
Add PSIL data for the AM62P and the J722S SoC family. The PSIL mapping for the J722S is the same except for the extra instances of the CSI-RX. So let's reuse the same file for both the AM62P and J722S. Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com> Signed-off-by: Ravi Gunasekaran <r-gunasekaran@ti.com> Signed-off-by: Vaishnav Achath <vaishnav.a@ti.com> Signed-off-by: Jayesh Choudhary <j-choudhary@ti.com> [bb@ti.com: rebased to U-Boot v2024.01] Signed-off-by: Bryan Brattlof <bb@ti.com>
2024-03-04dma: ti: k3-udma: Fix ring_idx to pair k3 nav ringsUdit Kumar
ring_idx was not correctly assigned in case of tflow_id is zero. Which leads to wrong pairing of DMA for drivers like OSPI. Fixes: 4312a1dfca26 ("dma: ti: k3-udma: Use ring_idx to pair k3 nav rings") Reviewed-by: Jai Luthra <j-luthra@ti.com> Signed-off-by: Udit Kumar <u-kumar1@ti.com>
2024-03-04dma: ti: k3-udma: Fix error handling for setup_resources() in udma_probe()Siddharth Vadapalli
In udma_probe() the return value of setup_resources() is stored in the u32 "ch_count" member of "struct udma_dev", due to which any negative return value which indicates an error is masked. Fix this by storing the return value of setup_resources() in the already declared integer variable "ret", followed by assigning it to the "ch_count" member of "struct udma_dev" in case of no error. While at it, change the "return ret" at the end of udma_probe() to a "return 0", to explicitly indicate that probe was successful. Fixes: a8837cf43839 ("dma: ti: k3-udma: Query DMA channels allocated from Resource Manager") Signed-off-by: Siddharth Vadapalli <s-vadapalli@ti.com> Reviewed-by: Dan Carpenter <dan.carpenter@linaro.org>
2024-03-04drivers: dma: Add support for J784S4 SoCApurva Nandan
Add support for DMA in J784S4 SoC. Signed-off-by: Jayesh Choudhary <j-choudhary@ti.com> Signed-off-by: Hari Nagalla <hnagalla@ti.com> Signed-off-by: Apurva Nandan <a-nandan@ti.com> Reviewed-by: Nishanth Menon <nm@ti.com> Reviewed-by: Roger Quadros <rogerq@kernel.org> Tested-by: Marcel Ziswiler <marcel.ziswiler@toradex.com> # AM69-SK
2024-02-06dma: ti: k3-udma: Use ring_idx to pair k3 nav ringsMD Danish Anwar
Use ring_idx to pair rings. ring_idx will be same as tx flow_id for all non-negative flow_ids. For negative flow_ids, ring_idx will be tchan->id added with bchan_cnt. Link: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/dma/ti/k3-udma.c?h=v6.8-rc2#n1686 Signed-off-by: MD Danish Anwar <danishanwar@ti.com> Reviewed-by: Ravi Gunasekaran <r-gunasekaran@ti.com>
2023-11-22dma: ti: k3-udma: Introduce DMA support for the am62axVignesh Raghavendra
In preparation for enabling ethernet for the am62ax family of SoCs, introduce the initial DMA channel settings for the am62ax Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com> [bb@ti.com: expanded on commit message] Signed-off-by: Bryan Brattlof <bb@ti.com> Signed-off-by: Nishanth Menon <nm@ti.com>
2023-11-10tree-wide: Replace http:// link with https:// link for ti.comNishanth Menon
Replace instances of http://www.ti.com with https://www.ti.com Signed-off-by: Nishanth Menon <nm@ti.com>
2023-10-13treewide: use dev_read_addr_*_ptr() where appropriateMatthias Schiffer
A follow-up to commit 842fb5de424e ("drivers: use devfdt_get_addr_size_index_ptr when cast to pointer") and commit 320a1938b6f7 ("drivers: use devfdt_get_addr_index_ptr when cast to pointer"). In addition to using the *_ptr variants of these functions where the address is cast to a pointer, this also changes devfdt_get_addr_*() to dev_read_addr_*() in a few places. Some variable and field types are changed from fdt_addr_t or phys_addr_t to void* where the cast was happening later. This patch fixes a number of compile warnings when building a 32bit U-Boot with CONFIG_PHYS_64BIT=y. In some places, it also fixes error handling where the return value of dev_read_addr() etc. was checked for NULL instead of FDT_ADDR_T_NONE. Signed-off-by: Matthias Schiffer <matthias.schiffer@ew.tq-group.com> Reviewed-by: Simon Glass <sjg@chromium.org>
2023-09-24common: Drop linux/printk.h from common headerSimon Glass
This old patch was marked as deferred. Bring it back to life, to continue towards the removal of common.h Move this out of the common header and include it only where needed. Signed-off-by: Simon Glass <sjg@chromium.org>
2023-08-15dma: ti: Update J21E PSIL endpoint information for MAIN CPSW0Suman Anna
The PSIL endpoint data for J721E currently covers only the MCU domain CPSW0 instance. Add the data for the MAIN domain CPSW0 as well to allow the MAIN domain Ethernet ports to be usable on any platform using J721E SoC. Additionally, since J721E's PSIL endpoint data is applicable to J7200 SoC as well, the MAIN CPSW0 instance on J7200 will also be usable now. Signed-off-by: Suman Anna <s-anna@ti.com> [s-vadapalli@ti.com: Update commit message indicating support for J7200] Signed-off-by: Siddharth Vadapalli <s-vadapalli@ti.com>
2023-03-22dma: ti: k3-udma: Fix channel hang on teardownVignesh Raghavendra
Setting RX flow error handling will stall the channel until descriptors are available to move RX data. Setting this bit causes issues when tearing down ethernet DMA channel at the end of TFTP transfer as unrelated network packets can cause teardown to stall indefinitely waiting for driver to queue add more desc leading to channel hang with error logs: udma_stop_dev2mem TIMEOUT ! udma_stop_dev2mem: peer not stopped TIMEOUT ! udma_stop_dev2mem TIMEOUT ! Fix this by clearing rx_error_handling similar to how its done for UDMA as part of udma_alloc_rchan_sci_req() This fixes occasional TFTP Failures seen when downloading multiple files one after the other on AM64/AM62 SoCs. Fixes: 9a92851c33e8 ("dma: ti: k3-udma: Add BCDMA and PKTDMA support") Reported-by: Nishanth Menon <nm@ti.com> Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
2022-10-18dma: Transfer dma_ops should use DMA address typesAndrew Davis
DMA operations should function on DMA addresses, not virtual addresses. Although these are usually the same in U-Boot, it is more correct to be explicit with our types here. Signed-off-by: Andrew Davis <afd@ti.com>
2022-10-06dma: ti: k3-udma: Fix 'SZ_64K’ undeclared errorDhruva Gole
Include linux/sizes.h because it defines SZ_64K which is used in many places inside k3-udma.c This fixes the error: ‘SZ_64K’ undeclared which appears during build time Signed-off-by: Dhruva Gole <d-gole@ti.com> Reviewed-by: Tom Rini <trini@konsulko.com>
2022-07-25arm: mach-k3: Rename SOC_K3_AM6 to SOC_K3_AM654Andrew Davis
The first AM6x device was the AM654x, but being the first we named it just AM6, since more devices have come out with this same prefix we should switch it to the normal convention of using the full name of the first compatibility device the series. This makes what device we are talking about more clear and matches all the K3 devices added since. Signed-off-by: Andrew Davis <afd@ti.com> Reviewed-by: Tom Rini <trini@konsulko.com>
2022-06-10dma: ti: Add PSIL data for AM62x DMASSVignesh Raghavendra
Add PSIL data for AM62x SoC. Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
2022-02-08drivers: dma: Add support for J721S2David Huang
Add support for DMA in J721S2 SoC. Signed-off-by: David Huang <d-huang@ti.com> Signed-off-by: Aswath Govindraju <a-govindraju@ti.com>
2022-01-15dma: ti: k3-udma: Fix rflow reservation for PKTDMAVignesh Raghavendra
Driver has a bug in that it uses rflow_in_use bitmap when setting up free rflow range from TISCI but use rflow_map for reservation in __udma_reserve_rflow() Fix this by dropping rflow_in_use bitmap array and use rflow_map for PKTDMA. BCDMA does not need rflow_in_use either. This fixes CPSW3g not able to get DMA channels at R5 SPL on AM64x Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
2021-08-31Kconfig: Remove all default n/no optionsMichal Simek
default n/no doesn't need to be specified. It is default option anyway. Signed-off-by: Michal Simek <michal.simek@xilinx.com> [trini: Rework FSP_USE_UPD portion] Signed-off-by: Tom Rini <trini@konsulko.com>
2021-06-11dma: ti: k3-udma: Add support for native configuration of chan/flowVignesh Raghavendra
In absence of Device Manager (DM) services such as at R5 SPL stage, driver will have to natively setup TCHAN/RCHAN/RFLOW cfg registers. Add support for the same. Note that we still need to send chan/flow cfg message to TIFS via TISCI client driver in order to open up firewalls around chan/flow but setting up of cfg registers is handled locally. U-Boot specific code is in a separate file included in main driver so as to maintain similarity with kernel driver in order to ease porting of code in future. Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com> Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com> Link: https://lore.kernel.org/r/20210607141753.28796-8-vigneshr@ti.com
2021-05-12dma: ti: k3-udma: Add BCDMA and PKTDMA supportVignesh Raghavendra
Sync BCDMA and PKTDMA support from Kernel for AM64 SoC Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
2021-05-12dma: ti: k3-psil-am64: Add AM64 PSIL endpoint dataVignesh Raghavendra
Add AM64 SoC specific channel mapping and endpoint data. Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
2021-05-12dma: ti: k3-psil: Extend PSIL EP data extension for AM64Vignesh Raghavendra
Extend PSIL EP data to include AM64 DMA specific information Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
2021-05-12dma: ti: k3-psil-am654: Drop unused PSIL EP static dataVignesh Raghavendra
ICSSG Ethernet driver uses two src threads per port (one per slice). Similarly CPSW uses one src thread. Drop PSIL EP static data for other src threads in order to reduce R5 SPL footprint. This makes AM65x board bootable again. Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
2020-12-13dm: treewide: Rename auto_alloc_size members to be shorterSimon Glass
This construct is quite long-winded. In earlier days it made some sense since auto-allocation was a strange concept. But with driver model now used pretty universally, we can shorten this to 'auto'. This reduces verbosity and makes it easier to read. Coincidentally it also ensures that every declaration is on one line, thus making dtoc's job easier. Signed-off-by: Simon Glass <sjg@chromium.org>
2020-10-12dma: ti: k3-udma: Reset the channel during releaseVignesh Raghavendra
Reset the channel completely during channel release in order to clear teardown bit before handing over to next user or jumping to Linux. Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com> Reviewed-by: Grygorii Strashko <grygorii.strashko@ti.com>
2020-07-13dma: ti: k3-udma: Switch to k3_ringacc_request_rings_pairVignesh Raghavendra
We only request ring pairs via K3 DMA driver, switch to use the new k3_ringacc_request_rings_pair() to simplify the code. As a good side effect, all boot stages now use exposed RING mode which avoid maintaining proxy mode for 32 bit R5 core. Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
2020-07-13dma: ti: k3-udma: Move RX descriptor ring entries to rflow structVignesh Raghavendra
In K3 UDMA architecture, RX rings are associated with RX flows rather than RX channels, therefore move the ring pointers to udma_rflow struct Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
2020-07-13dma: ti: k3-udma: Introduce udma_chan_config structVignesh Raghavendra
Encapsulate channel configuration in a separate struct so as to ease resetting of these fields with memset() and also to increase readability of the code. Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
2020-07-13dma: ti: k3-udma: Update driver to use static endpoint DataVignesh Raghavendra
Update driver to use static PSIL endpoint Data instead of DT. This will allow DT bindings to be in sync with kernel's DT. Note that this patch breaks networking and OSPI boot as driver changes are not backward compatible with existing DT. Subsequent commit will update the DT to make it compatible with updated driver. Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com> Reviewed-by: Grygorii Strashko <grygorii.strashko@ti.com>
2020-07-13dma: ti: Add static PSIL endpoint informationVignesh Raghavendra
Much of PSIL endpoint configuration for a given SoC can be known at compile time, therefore pass them for platform specific data instead of DT. Add per SoC's specific PSIL endpoint data. This is to bring driver in sync with upstream DT. Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com> Reviewed-by: Grygorii Strashko <grygorii.strashko@ti.com>
2020-05-18common: Drop linux/bitops.h from common headerSimon Glass
Move this uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
2020-05-18common: Drop log.h from common headerSimon Glass
Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
2020-05-18common: Drop net.h from common headerSimon Glass
Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
2020-03-03dma: ti: k3-udma: Mark flow id as valid parameter for RX channel configLokesh Vutla
When flow id is not marked as valid, sysfw reads the register value to get the range of flow ids that are supported. Then compares the flow range with the U-Boot's host id. This will definitely fail as board configuration doesn't assign the full range to U-Boot's host id. In order to work around this, mark the flow id as valid and pass range as 0. Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
2020-02-19dma-mapping: move dma_map_(un)single() to <linux/dma-mapping.h>Masahiro Yamada
The implementation of dma_map_single() and dma_unmap_single() is exactly the same for all the architectures that support them. Factor them out to <linux/dma-mapping.h>, and make all drivers to include <linux/dma-mapping.h> instead of <asm/dma-mapping.h>. If we need to differentiate them for some architectures, we can move the generic definitions to <asm-generic/dma-mapping.h>. Add some comments to the helpers. The concept is quite similar to the DMA-API of Linux kernel. Drivers are agnostic about what is going on behind the scene. Just call dma_map_single() before the DMA, and dma_unmap_single() after it. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>