- Jan 21, 2020
-
-
Peter Ujfalusi authored
Split patch for review containing: defines, structs, io and low level functions and interrupt callbacks. DMA driver for Texas Instruments K3 NAVSS Unified DMA – Peripheral Root Complex (UDMA-P) The UDMA-P is intended to perform similar (but significantly upgraded) functions as the packet-oriented DMA used on previous SoC devices. The UDMA-P module supports the transmission and reception of various packet types. The UDMA-P is architected to facilitate the segmentation and reassembly of SoC DMA data structure compliant packets to/from smaller data blocks that are natively compatible with the specific requirements of each connected peripheral. Multiple Tx and Rx channels are provided within the DMA which allow multiple segmentation or reassembly operations to be ongoing. The DMA controller maintains state information for each of the channels which allows packet segmentation and reassembly operations to be time division multiplexed between channels in order to share t...
-
Peter Ujfalusi authored
New binding document for Texas Instruments K3 NAVSS Unified DMA – Peripheral Root Complex (UDMA-P). UDMA-P is introduced as part of the K3 architecture and can be found in AM654 and j721e. Signed-off-by:
Peter Ujfalusi <peter.ujfalusi@ti.com> Reviewed-by:
Rob Herring <robh@kernel.org> Tested-by:
Keerthy <j-keerthy@ti.com> Reviewed-by:
Grygorii Strashko <grygorii.strashko@ti.com> Link: https://lore.kernel.org/r/20191223110458.30766-10-peter.ujfalusi@ti.com Signed-off-by:
Vinod Koul <vkoul@kernel.org>
-
Peter Ujfalusi authored
In K3 architecture the DMA operates within threads. One end of the thread is UDMAP, the other is on the peripheral side. The UDMAP channel configuration depends on the needs of the remote endpoint and it can be differ from peripheral to peripheral. This patch adds database for am654 and j721e and small API to fetch the PSI-L endpoint configuration from the database which should only used by the DMA driver(s). Another API is added for native peripherals to give possibility to pass new configuration for the threads they are using, which is needed to be able to handle changes caused by different firmware loaded for the peripheral for example. Signed-off-by:
-
Peter Ujfalusi authored
The K3 DMA architecture uses CPPI5 (Communications Port Programming Interface) specified descriptors over PSI-L bus within NAVSS. The header provides helpers, macros to work with these descriptors in a consistent way. Signed-off-by:
-
Peter Ujfalusi authored
dmaengine_get_direction_text() can be useful when the direction is printed out. The text is easier to comprehend than the number. Signed-off-by:
-
Peter Ujfalusi authored
A DMA hardware can have big cache or FIFO and the amount of data sitting in the DMA fabric can be an interest for the clients. For example in audio we want to know the delay in the data flow and in case the DMA have significantly large FIFO/cache, it can affect the latenc/delay Signed-off-by:
Tero Kristo <t-kristo@ti.com> Tested-by:
-
Peter Ujfalusi authored
The metadata is best described as side band data or parameters traveling alongside the data DMAd by the DMA engine. It is data which is understood by the peripheral and the peripheral driver only, the DMA engine see it only as data block and it is not interpreting it in any way. The metadata can be different per descriptor as it is a parameter for the data being transferred. If the DMA supports per descriptor metadata it can implement the attach, get_ptr/set_len callbacks. Client drivers must only use either attach or get_ptr/set_len to avoid misconfiguration. Client driver can check if a given metadata mode is supported by the channel during probe time with dmaengine_is_metadata_mode_supported(chan, DESC_METADATA_CLIENT); dmaengine_is_metadata_mode_supported(chan, DESC_METADATA_ENGINE); and based on this information can use either mode. Wrappers are also added for the metadata_ops. To be used in DESC_METADATA_CLIENT mode: dmaengine_desc_attach_metadata() To be used in DESC_METADATA_ENGINE mode: dmaengine_desc_get_metadata_ptr() dmaengine_desc_set_metadata_len() Signed-off-by:
-
Peter Ujfalusi authored
Update the provider and client documentation with details about the metadata support. Signed-off-by:
-
Vinod Koul authored
This is for dependency of new TI ringacc dmaengine drivers Merge tag 'drivers_soc_for_5.6' into topic/ti SOC: TI Keystone Ring Accelerator driver The Ring Accelerator (RINGACC or RA) provides hardware acceleration to enable straightforward passing of work between a producer and a consumer. There is one RINGACC module per NAVSS on TI AM65x SoCs. Signed-off-by:
-
- Jan 15, 2020
-
-
Grygorii Strashko authored
The Ring Accelerator (RINGACC or RA) provides hardware acceleration to enable straightforward passing of work between a producer and a consumer. There is one RINGACC module per NAVSS on TI AM65x SoCs. The RINGACC converts constant-address read and write accesses to equivalent read or write accesses to a circular data structure in memory. The RINGACC eliminates the need for each DMA controller which needs to access ring elements from having to know the current state of the ring (base address, current offset). The DMA controller performs a read or write access to a specific address range (which maps to the source interface on the RINGACC) and the RINGACC replaces the address for the transaction with a new address which corresponds to the head or tail element of the ring (head for reads, tail for writes). Since the RINGACC maintains the state, multiple DMA controllers or channels are allowed to coherently share the same rings as applicable. The RINGACC is able to place data which is destined towards software into cached memory directly. Supported ring modes: - Ring Mode - Messaging Mode - Credentials Mode - Queue Manager Mode TI-SCI integration: Texas Instrument's System Control Interface (TI-SCI) Message Protocol now has control over Ringacc module resources management (RM) and Rings configuration. The corresponding support of TI-SCI Ringacc module RM protocol introduced as option through DT parameters: - ti,sci: phandle on TI-SCI firmware controller DT node - ti,sci-dev-id: TI-SCI device identifier as per TI-SCI firmware spec if both parameters present - Ringacc driver will configure/free/reset Rings using TI-SCI Message Ringacc RM Protocol. The Ringacc driver manages Rings allocation by itself now and requests TI-SCI firmware to allocate and configure specific Rings only. It's done this way because, Linux driver implements two stage Rings allocation and configuration (allocate ring and configure ring) while TI-SCI Message Protocol supports only one combined operation (allocate+configure). Signed-off-by:
Santosh Shilimkar <santosh.shilimkar@oracle.com>
-
Grygorii Strashko authored
The Ring Accelerator (RINGACC or RA) provides hardware acceleration to enable straightforward passing of work between a producer and a consumer. There is one RINGACC module per NAVSS on TI AM65x and j721e. This patch introduces RINGACC device tree bindings. Signed-off-by:
-
Logan Gunthorpe authored
On prep, a spin lock is taken and the next entry in the circular buffer is filled. On submit, the valid bit is set in the hardware descriptor and the lock is released. The DMA engine is started (if it's not already running) when the client calls dma_async_issue_pending(). Signed-off-by:
Logan Gunthorpe <logang@deltatee.com> Link: https://lore.kernel.org/r/20200103212021.2881-4-logang@deltatee.com Signed-off-by:
-
Logan Gunthorpe authored
Allocate DMA coherent memory for the ring of DMA descriptors and program the appropriate hardware registers. A tasklet is created which is triggered on an interrupt to process all the finished requests. Additionally, any remaining descriptors are aborted when the hardware is removed or the resources freed. Use an RCU pointer to synchronize PCI device unbind. Signed-off-by:
-
Logan Gunthorpe authored
Some PLX Switches can expose DMA engines via extra PCI functions on the upstream port. Each function will have one DMA channel. This patch is just the core PCI driver skeleton and dma engine registration. Signed-off-by:
-
- Dec 25, 2019
-
-
Sascha Hauer authored
The current descriptor is not on any list of the virtual DMA channel. Once sdma_terminate_all() is called when a descriptor is currently in flight then this one is forgotten to be freed. We have to call vchan_terminate_vdesc() on this descriptor to re-add it to the lists. Now that we also free the currently running descriptor we can (and actually have to) remove the current descriptor from its list also for the cyclic case. Signed-off-by:
Sascha Hauer <s.hauer@pengutronix.de> Reviewed-by:
Robin Gong <yibin.gong@nxp.com> Tested-by:
-
Sascha Hauer authored
In sdma_tx_status() we must first find the current sdma_desc. In cyclic mode we assume that this can always be found with vchan_find_desc(). This is true because do not remove the current descriptor from the desc_issued list: /* * Do not delete the node in desc_issued list in cyclic mode, otherwise * the desc allocated will never be freed in vchan_dma_desc_free_list */ if (!(sdmac->flags & IMX_DMA_SG_LOOP)) list_del(&vd->node); We will change this in the next step, so check if the current descriptor is the desired one also for the cyclic case. Signed-off-by:
-
Sascha Hauer authored
Rename sdma_disable_channel_async() after the hook it implements, like done for all other functions in the SDMA driver. Signed-off-by:
-
Sascha Hauer authored
vchan_dma_desc_free_list() basically open codes vchan_vdesc_fini() in its loop body. Call it directly rather than duplicating the code. Signed-off-by:
-
Sascha Hauer authored
All list operations are protected by &vc->lock. As vchan_vdesc_fini() is called unlocked add the missing locking around the list operations. Signed-off-by:
-
Sascha Hauer authored
vchan_vdesc_fini() shouldn't be called under a spin_lock. This is done in two places, once in vchan_terminate_vdesc() and once in vchan_synchronize(). Instead of freeing the vdesc right away, collect the aborted vdescs on a separate list and free them along with the other vdescs. The terminated descs are also freed in vchan_synchronize as done before this patch. Signed-off-by:
-
Sascha Hauer authored
vchan_dma_desc_free_list() basically open codes vchan_vdesc_fini() in the loop body. One difference is an additional debug message. As this isn't overly useful remove it. Signed-off-by:
-
Sascha Hauer authored
Originally freeing descriptors was split into a locked and an unlocked part. The locked part in vchan_get_all_descriptors() collected all descriptors on a separate list_head. This was done to allow iterating over that new list in vchan_dma_desc_free_list() without a lock held. This became broken in 13bb26ae ("dmaengine: virt-dma: don't always free descriptor upon completion"). With this commit vchan_dma_desc_free_list() no longer exclusively operates on the separate list, but starts to put descriptors which can be reused back on &vc->desc_allocated. This list operation should have been locked, but wasn't. In the mean time drivers started to call vchan_dma_desc_free_list() with their lock held so that we now have the situation that vchan_dma_desc_free_list() is called locked from some drivers and unlocked from others. To clean this up we have to do two things: 1. Add missing locking in vchan_dma_desc_free_list() 2. Make sure drivers call vchan_dma_desc_free_li...
-
Sascha Hauer authored
vchan_vdesc_fini() can't be called locked. Instead, call vchan_terminate_vdesc() which delays the freeing of the descriptor to vchan_synchronize(). Signed-off-by:
-
Vinod Koul authored
error log for dma_channel_table_init() failure pointed a mere "initialization failure", which is not very helpful message, so print additional details like function name and error code. Signed-off-by: -
Vinod Koul authored
We call dma_device_put() and module_put() after invoking .device_free_chan_resources callback, but we should also take care of router devices and invoke this after .route_free callback. So move it after .route_free Reviewed-by:
-
- Dec 23, 2019
-
-
Logan Gunthorpe authored
Don't allocate memory using the devm infrastructure and instead call kfree with the new dmaengine device_release call back. This ensures the structures are available until the last reference is dropped. We also need to ensure we call ioat_shutdown() in ioat_remove() so that all the channels are quiesced and further transaction fails. Signed-off-by:
Dave Jiang <dave.jiang@intel.com> Link: https://lore.kernel.org/r/20191216190120.21374-6-logang@deltatee.com Signed-off-by:
-
Logan Gunthorpe authored
Adding a reference count helps drivers to properly implement the unbind while in use case. References are taken and put every time a channel is allocated or freed. Once the final reference is put, the device is removed from the dma_device_list and a release callback function is called to signal the driver to free the memory. Signed-off-by:
-
Logan Gunthorpe authored
So it can be called by a release function which is needed higher up in the code. No functional changes intended. Signed-off-by:
-
Logan Gunthorpe authored
The module reference is taken to ensure the callbacks still exist when they are called. If the channel holds the last reference to the module, the module can disappear before device_free_chan_resources() is called and would cause a call into free'd memory. Signed-off-by:
-
Logan Gunthorpe authored
dma_chan_to_owner() dereferences the driver from the struct device to obtain the owner and call module_[get|put](). However, if the backing device is unbound before the dma_device is unregistered, the driver will be cleared and this will cause a NULL pointer dereference. Instead, store a pointer to the owner module in the dma_device struct so the module reference can be properly put when the channel is put, even if the backing device was destroyed first. This change helps to support a safer unbind of DMA engines. If the dma_device is unregistered in the driver's remove function, there's no guarantee that there are no existing clients and a users action may trigger the WARN_ONCE in dma_async_device_unregister() which is unlikely to leave the system in a consistent state. Instead, a better approach is to allow the backing driver to go away and fail any subsequent requests to it. Signed-off-by:
-
周琰杰 (Zhou Yanjie) authored
Add support for probing the dma-jz4780 driver on the X1830 Soc. Signed-off-by:
周琰杰 (Zhou Yanjie) <zhouyanjie@wanyeetech.com> Link: https://lore.kernel.org/r/1576591140-125668-4-git-send-email-zhouyanjie@wanyeetech.com Signed-off-by:
-
周琰杰 (Zhou Yanjie) authored
Add the dmaengine bindings for the X1830 Soc from Ingenic. Signed-off-by:
-
- Dec 18, 2019
-
-
Peng Ma authored
Our platforms(such as LS1021A, LS1012A, LS1043A, LS1046A, LS1028A) with below registers(CHCFG0 - CHCFG15) of eDMA as follows: *-----------------------------------------------------------* | Offset | OTHERS | LS1028A | |--------------|--------------------|-----------------------| | 0x0 | CHCFG0 | CHCFG3 | |--------------|--------------------|-----------------------| | 0x1 | CHCFG1 | CHCFG2 | |--------------|--------------------|-----------------------| | 0x2 | CHCFG2 | CHCFG1 | |--------------|--------------------|-----------------------| | 0x3 | CHCFG3 | CHCFG0 | |--------------|--------------------|-----------------------| | ... | ...... | ...... | |--------------|--------------------|-----------------------| | 0xC | CHCFG12 | CHCFG15 | |--------------|--------------------|-----------------------| | 0xD | CHCFG13 | CHCFG14 | |--------------|--------------------|-----------------------| | 0xE | CHCFG14 | CHCFG13 | |--------------|--------------------|-----------------------| | 0xF | CHCFG15 | CHCFG12 | *-----------------------------------------------------------* This patch is to improve edma driver to fit LS1028A platform. Signed-off-by:
Peng Ma <peng.ma@nxp.com> Reviewed-by:
-
Peng Ma authored
QORIQ LS1028A soc used fsl,vf610-edma, but it has a little bit different from others, so add new compatible to distinguish them. Signed-off-by:
-
Wei Yongjun authored
Fix to return negative error code -ENOMEM from the error handling case instead of 0, as done elsewhere in this function. Fixes: 2a03c131 ("dmaengine: ti: edma: add missed operations") Signed-off-by:
Wei Yongjun <weiyongjun1@huawei.com> Acked-by:
-
- Dec 11, 2019
-
-
Chuhong Yuan authored
The driver misses checking the result of devm_regmap_init_mmio(). Add a check to fix it. Fixes: fc15be39 ("dmaengine: axi-dmac: add regmap support") Signed-off-by:
Chuhong Yuan <hslester96@gmail.com> Reviewed-by:
Alexandru Ardelean <alexandru.ardelean@analog.com> Link: https://lore.kernel.org/r/20191209085711.16001-1-hslester96@gmail.com Signed-off-by:
-
- Dec 10, 2019
-
-
Geert Uytterhoeven authored
Signed-off-by:
Geert Uytterhoeven <geert+renesas@glider.be> Link: https://lore.kernel.org/r/20191206132435.29139-1-geert+renesas@glider.be Signed-off-by:
-
Ulf Hansson authored
It has turned out that it's in general a good idea for dmaengines to allow DMA requests during the entire dpm_suspend() phase. Therefore, convert the pl330 driver into using SET_LATE_SYSTEM_SLEEP_PM_OPS. Signed-off-by:
Ulf Hansson <ulf.hansson@linaro.org> Tested-by:
Marek Szyprowski <m.szyprowski@samsung.com> Link: https://lore.kernel.org/r/20191205143746.24873-3-ulf.hansson@linaro.org Signed-off-by:
-
Ulf Hansson authored
Let's drop the boilerplate code in the system suspend/resume callbacks and convert to use pm_runtime_force_suspend|resume(). This change also has a nice side effect, as pm_runtime_force_resume() may decide to leave the device in low power state, when that is feasible, thus avoiding to waste both time and energy during system resume. Signed-off-by:
-
Geert Uytterhoeven authored
Document support for the system DMA controller in the Renesas R-Car M3-W+ (R8A77961) SoC. No driver update is needed. Signed-off-by:
-
