summaryrefslogtreecommitdiffstats
AgeCommit message (Collapse)Author
2020-12-11dmaengine: ti: k3-udma: Initial support for K3 BCDMAPeter Ujfalusi
One of the DMAs introduced with AM64 is the Block Copy DMA (BCDMA). It serves similar purpose as K3 UDMAP channels in TR mode. The rings for the BCDMA is integrated within the DMA itself instead of using rings from the general purpose ringacc. A BCDMA have two different type of channels: - Block Copy Channels (bchan) - Split Channels (tchan and rchan) tchan and rchan can be used to service PSI-L peripherals, similarly to K3 UDMA channels. bchan can be only used for block copy operation (TR type15) like the paired K3 UDMA tchan/rchan configured in block copy mode. bchans can be also used to service peripherals directly if an external trigger is selected for the channel. Most of the driver code can be reused for BCDMA bchan/tchan/rchan support but new setup and allocation functions are needed to handle the differences between the DMAs. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Link: https://lore.kernel.org/r/20201208090440.31792-18-peter.ujfalusi@ti.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2020-12-11soc: ti: k3-ringacc: add AM64 DMA rings support.Grygorii Strashko
The DMAs in AM64 have built in rings compared to AM654/J721e/J7200 where a separate and generic ringacc is used. The ring SW interface is similar to ringacc with some major architectural differences, like They are part of the DMA (BCDMA or PKTDMA). They are dual mode rings are modeled as pair of Rings objects which has common configuration and memory buffer, but separate real-time control register sets for each direction mem2dev (forward) and dev2mem (reverse). The ringacc driver must be initialized for DMA rings use with k3_ringacc_dmarings_init() as it is not an independent device as ringacc is. AM64 rings must be requested only using k3_ringacc_request_rings_pair(), and forward ring must always be initialized/configured. After this any other Ringacc APIs can be used without any callers changes. Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com> Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Link: https://lore.kernel.org/r/20201208090440.31792-17-peter.ujfalusi@ti.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2020-12-11dmaengine: ti: Add support for k3 event routersPeter Ujfalusi
In k3 architecture a DMA channel (in TR momde) can be triggered by global events, origination from different modules. The events for triggers can be sent from any module which is connected to PSI-L fabric, but the event number to be sent is DMA channel specific, it is only known after the channel itself is requested. The router operation needs to be split up: - route_allocate: configure the dma_spec for the DMA and store the configuration which is needed for the router's input - set_event: callback used by the DMA driver to set the event number for the channel and enable the routing Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Link: https://lore.kernel.org/r/20201208090440.31792-16-peter.ujfalusi@ti.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2020-12-11dmaengine: ti: k3-psil: Add initial map for AM64Peter Ujfalusi
Add initial PSI-L map file for AM64. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Link: https://lore.kernel.org/r/20201208090440.31792-15-peter.ujfalusi@ti.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2020-12-11dmaengine: ti: k3-psil: Extend psil_endpoint_config for K3 PKTDMAPeter Ujfalusi
Additional fields needed for K3 PKTDMA to be able to handle the mapped channels (channels are locked to handle specific threads) and flow ranges for these mapped threads. PKTDMA also introduces tflow for tx channels which can not be found in K3 UDMA architecture. 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-14-peter.ujfalusi@ti.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2020-12-11dt-bindings: dma: ti: Add document for K3 PKTDMAPeter Ujfalusi
New binding document for Texas Instruments K3 Packet DMA (PKTDMA). PKTDMA is introduced as part of AM64. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Reviewed-by: Rob Herring <robh@kernel.org> Link: https://lore.kernel.org/r/20201208090440.31792-13-peter.ujfalusi@ti.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2020-12-11dt-bindings: dma: ti: Add document for K3 BCDMAPeter Ujfalusi
New binding document for Texas Instruments K3 Block Copy DMA (BCDMA). BCDMA is introduced as part of AM64. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Reviewed-by: Rob Herring <robh@kernel.org> Link: https://lore.kernel.org/r/20201208090440.31792-12-peter.ujfalusi@ti.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2020-12-11dmaengine: dmatest: Use dmaengine_get_dma_devicePeter Ujfalusi
By using the dmaengine_get_dma_device() to get the device for dma_api use, the dmatest can support per channel coherency if it is supported by the DMA controller. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Link: https://lore.kernel.org/r/20201208090440.31792-11-peter.ujfalusi@ti.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2020-12-11dmaengine: doc: client: Update for dmaengine_get_dma_device() usagePeter Ujfalusi
Client drivers should use the dmaengine_get_dma_device(chan) to get the device pointer which should be used for DMA API for allocations and mapping. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Link: https://lore.kernel.org/r/20201208090440.31792-10-peter.ujfalusi@ti.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2020-12-11dmaengine: Add support for per channel coherency handlingPeter Ujfalusi
If the DMA device supports per channel coherency configuration (a channel can be configured to have coherent or not coherent view) then a single device (the DMA controller's device) can not be used for dma_api for all channels as channels can have different coherency. Introduce custom_dma_mapping flag for the dma_chan and a new helper to get the device pointer to be used for dma_api for the given channel. Client drivers should be updated to be able to support per channel coherency by: - dma_map_single(chan->device->dev, ptr, size, DMA_TO_DEVICE); + struct device *dma_dev = dmaengine_get_dma_device(chan); + + dma_map_single(dma_dev, ptr, size, DMA_TO_DEVICE); Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Link: https://lore.kernel.org/r/20201208090440.31792-9-peter.ujfalusi@ti.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2020-12-11dmaengine: of-dma: Add support for optional router configuration callbackPeter Ujfalusi
Additional configuration for the DMA event router might be needed for a channel which can not be done during device_alloc_chan_resources callback since the router information is not yet present for the drivers. If there is a need for additional configuration for the channel if DMA router is in use, then the driver can implement the device_router_config callback. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Link: https://lore.kernel.org/r/20201208090440.31792-8-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 Ujfalusi
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 Ujfalusi
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 Ujfalusi
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-12-11dmaengine: ti: k3-udma: Add support for second resource range from sysfwPeter Ujfalusi
Resource allocation via sysfw can use up to two ranges per resource subtype to support more complex resource assignment, mainly for DMA channels. Take the second range also into consideration when setting up the maps for available resources. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Link: https://lore.kernel.org/r/20201208090440.31792-4-peter.ujfalusi@ti.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2020-12-11dmaengine: ti: k3-udma: Wait for peer teardown completion if supportedPeter Ujfalusi
Set the TDTYPE if it is supported on the platform (j721e) which will cause UDMAP to wait for the remote peer to finish the teardown before returning the teardown completed message. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Tested-by: Keerthy <j-keerthy@ti.com> Reviewed-by: Grygorii Strashko <grygorii.strashko@ti.com> Link: https://lore.kernel.org/r/20201208090440.31792-3-peter.ujfalusi@ti.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2020-12-11dmaengine: ti: k3-udma: Correct normal channel offset when uchan_cnt is not 0Peter Ujfalusi
According to different sections of the TRM, the hchan_cnt of CAP3 includes the number of uchan in UDMA, thus the start offset of the normal channels are hchan_cnt. Fixes: daf4ad0499aa4 ("dmaengine: ti: k3-udma: Query throughput level information from hardware") Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Link: https://lore.kernel.org/r/20201208090440.31792-2-peter.ujfalusi@ti.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2020-12-11Merge tag 'tags/drivers_soc_for_5.11' into dmaengine/nextVinod Koul
drivers: soc: TI SOC changes for 5.11 - ti_sci changes towards DMSS support - Static warning fixes - Kconfig update for Keystone ARM64 socs - AM64X SOC family support
2020-12-11dmaengine: stm32-mdma: rework interrupt handlerAmelie Delaunay
To avoid multiple entries in MDMA interrupt handler for each flag&interrupt enable, manage all flags set at once. Signed-off-by: Amelie Delaunay <amelie.delaunay@st.com> Link: https://lore.kernel.org/r/20201120143320.30367-5-amelie.delaunay@st.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2020-12-11dmaengine: stm32-dma: take address into account when computing max widthAmelie Delaunay
DMA_SxPAR or DMA_SxM0AR/M1AR registers have to be aligned on PSIZE or MSIZE respectively. This means that bus width needs to be forced to 1 byte when computed width is not aligned with address. Signed-off-by: Amelie Delaunay <amelie.delaunay@st.com> Link: https://lore.kernel.org/r/20201120143320.30367-4-amelie.delaunay@st.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2020-12-11dmaengine: stm32-dma: clean channel configuration when channel is freedAmelie Delaunay
When dma_channel_release is called, it means that the channel won't be used anymore with the configuration it had. To ensure a future client can safely use the channel after it has been released, clean the configuration done when channel was requested. Signed-off-by: Amelie Delaunay <amelie.delaunay@st.com> Link: https://lore.kernel.org/r/20201120143320.30367-3-amelie.delaunay@st.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2020-12-11dmaengine: stm32-dma: rework irq handler to manage error before xfer eventsAmelie Delaunay
To better understand error that can be detected by the DMA controller, manage the error flags before the transfer flags. This way, it is possible to know if the FIFO error flag is set for an over/underrun condition or a FIFO level error. When a FIFO over/underrun condition occurs, the data is not lost because peripheral request is not acknowledged by the stream until the over/ underrun condition is cleared. If this acknowledge takes too much time, the peripheral itself may detect an over/underrun condition of its internal buffer and data might be lost. That's why in case the FIFO error flag is set, we check if the channel is disabled or not, and if a Transfer Complete flag is set, which means that the channel is disabled because of the end of transfer. Because channel is disabled by hardware either by a FIFO level error, or by an end of transfer. Signed-off-by: Amelie Delaunay <amelie.delaunay@st.com> Link: https://lore.kernel.org/r/20201120143320.30367-2-amelie.delaunay@st.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2020-12-11dmaengine: bam_dma: fix return of bam_dma_irq()Parth Y Shah
While performing suspend/resume, we were getting below kernel crash. [ 54.541672] [FTS][Info]gesture suspend... [ 54.605256] [FTS][Error][GESTURE]Enter into gesture(suspend) failed! [ 54.605256] [ 58.345850] irq event 10: bogus return value fffffff3 ...... [ 58.345966] [<ffff0000080830f0>] el1_irq+0xb0/0x124 [ 58.345971] [<ffff000008085360>] arch_cpu_idle+0x10/0x18 [ 58.345975] [<ffff0000081077f4>] do_idle+0x1ac/0x1e0 [ 58.345979] [<ffff0000081079c8>] cpu_startup_entry+0x20/0x28 [ 58.345983] [<ffff000008a80ed0>] rest_init+0xd0/0xdc [ 58.345988] [<ffff0000091c0b48>] start_kernel+0x390/0x3a4 [ 58.345990] handlers: [ 58.345994] [<ffff0000085120d0>] bam_dma_irq The reason for the crash we found is, bam_dma_irq() was returning negative value when the device resumes in some conditions. In addition, the irq handler should have one of the below return values. IRQ_NONE interrupt was not from this device or was not handled IRQ_HANDLED interrupt was handled by this device IRQ_WAKE_THREAD handler requests to wake the handler thread Therefore, to resolve this crash, we have changed the return value to IRQ_NONE. Signed-off-by: Parth Y Shah <sparth1292@gmail.com> Link: https://lore.kernel.org/r/1607322820-7450-1-git-send-email-sparth1292@gmail.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2020-12-11dmaengine: idxd: add IAX configuration support in the IDXD driverDave Jiang
Add support to allow configuration of Intel Analytics Accelerator (IAX) in addition to the Intel Data Streaming Accelerator (DSA). The IAX hardware has the same configuration interface as DSA. The main difference is the type of operations it performs. We can support the DSA and IAX devices on the same driver with some tweaks. IAX has a 64B completion record that needs to be 64B aligned, as opposed to a 32B completion record that is 32B aligned for DSA. IAX also does not support token management. Signed-off-by: Dave Jiang <dave.jiang@intel.com> Link: https://lore.kernel.org/r/160564555488.1834439.4261958859935360473.stgit@djiang5-desk3.ch.intel.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2020-12-11dt-bindings: dma: mtk-apdma: add bindings for MT8516 SOCFabien Parent
Add bindings to APDMA for MT8516 SoC. MT8516 is compatible with MT6577. Signed-off-by: Fabien Parent <fparent@baylibre.com> Reviewed-by: Matthias Brugger <matthias.bgg@gmail.com> Acked-by: Rob Herring <robh@kernel.org> Link: https://lore.kernel.org/r/20201209114736.70625-1-fparent@baylibre.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2020-12-11dmaengine: qcom: Fix ADM driver kerneldoc markupJonathan McDowell
Update the kerneldoc function headers to fix build warnings: drivers/dma/qcom/qcom_adm.c:180: warning: Function parameter or member 'chan' not described in 'adm_free_chan' drivers/dma/qcom/qcom_adm.c:190: warning: Function parameter or member 'burst' not described in 'adm_get_blksize' drivers/dma/qcom/qcom_adm.c:466: warning: Function parameter or member 'chan' not described in 'adm_terminate_all' drivers/dma/qcom/qcom_adm.c:466: warning: Excess function parameter 'achan' description in 'adm_terminate_all' drivers/dma/qcom/qcom_adm.c:503: warning: Function parameter or member 'achan' not described in 'adm_start_dma' Signed-off-by: Jonathan McDowell <noodles@earth.li> Link: https://lore.kernel.org/r/20201126184602.GA1008@earth.li Signed-off-by: Vinod Koul <vkoul@kernel.org>
2020-12-10dmaengine: idxd: add ATS disable knob for work queuesDave Jiang
With the DSA spec 1.1 update, a knob to disable ATS for individually is introduced. Add enabling code to allow a system admin to make the configuration through sysfs. Signed-off-by: Dave Jiang <dave.jiang@intel.com> Link: https://lore.kernel.org/r/160530810593.1288392.2561048329116529566.stgit@djiang5-desk3.ch.intel.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2020-11-24dmaengine: ti: drop of_match_ptr and mark of_device_id table as maybe unusedKrzysztof Kozlowski
The driver can match only via the DT table so the main table should be always used and the of_match_ptr does not have any sense (this also allows ACPI matching via PRP0001, even though it is not relevant here). The secondary match of_device_id tables (passed to of_match_node) should be marked as maybe unused to fix compile testing (!CONFIG_OF on x86_64) warnings: drivers/dma/ti/dma-crossbar.c:125:34: warning: ‘ti_am335x_master_match’ defined but not used [-Wunused-const-variable=] drivers/dma/ti/dma-crossbar.c:22:34: warning: ‘ti_dma_xbar_match’ defined but not used [-Wunused-const-variable=] Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org> Link: https://lore.kernel.org/r/20201120162303.482126-6-krzk@kernel.org Signed-off-by: Vinod Koul <vkoul@kernel.org>
2020-11-24dmaengine: stm32: mark of_device_id table as maybe unusedKrzysztof Kozlowski
The driver uses a second of_device_id table in the probe() function by passing it to of_match_node(). This code will be a no-op for compile testing (!CONFIG_OF on x86_64): drivers/dma/stm32-dmamux.c:171:34: warning: ‘stm32_stm32dma_master_match’ defined but not used [-Wunused-const-variable=] Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org> Link: https://lore.kernel.org/r/20201120162303.482126-5-krzk@kernel.org Signed-off-by: Vinod Koul <vkoul@kernel.org>
2020-11-24dmaengine: sf: drop of_match_ptr from of_device_id tableKrzysztof Kozlowski
The driver can match only via the DT table so the table should be always used and the of_match_ptr does not have any sense (this also allows ACPI matching via PRP0001, even though it is not relevant here). This fixes compile warning (!CONFIG_OF on x86_64): drivers/dma/sf-pdma/sf-pdma.c:576:34: warning: ‘sf_pdma_dt_ids’ defined but not used [-Wunused-const-variable=] Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org> Link: https://lore.kernel.org/r/20201120162303.482126-4-krzk@kernel.org Signed-off-by: Vinod Koul <vkoul@kernel.org>
2020-11-24dmaengine: mv_xor: drop of_match_ptr from of_device_id tableKrzysztof Kozlowski
The driver can match only via the DT table so the table should be always used and the of_match_ptr does not have any sense (this also allows ACPI matching via PRP0001, even though it is not relevant here). This fixes compile warning (!CONFIG_OF on x86_64): drivers/dma/mv_xor.c:1281:34: warning: ‘mv_xor_dt_ids’ defined but not used [-Wunused-const-variable=] Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org> Link: https://lore.kernel.org/r/20201120162303.482126-3-krzk@kernel.org Signed-off-by: Vinod Koul <vkoul@kernel.org>
2020-11-24dmaengine: dw-axi-dmac: drop of_match_ptr from of_device_id tableKrzysztof Kozlowski
The driver can match only via the DT table so the table should be always used and the of_match_ptr does not have any sense (this also allows ACPI matching via PRP0001, even though it is not relevant here). This fixes compile warning (!CONFIG_OF on x86_64): drivers/dma/dw-axi-dmac/dw-axi-dmac-platform.c:984:34: warning: ‘dw_dma_of_id_table’ defined but not used [-Wunused-const-variable=] Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org> Link: https://lore.kernel.org/r/20201120162303.482126-2-krzk@kernel.org Signed-off-by: Vinod Koul <vkoul@kernel.org>
2020-11-24dmaengine: jz4780: drop of_match_ptr from of_device_id tableKrzysztof Kozlowski
The driver can match only via the DT table so the table should be always used and the of_match_ptr does not have any sense (this also allows ACPI matching via PRP0001, even though it is not relevant here). This fixes compile warning (!CONFIG_OF on x86_64): drivers/dma/dma-jz4780.c:1031:34: warning: ‘jz4780_dma_dt_match’ defined but not used [-Wunused-const-variable=] Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org> Link: https://lore.kernel.org/r/20201120162303.482126-1-krzk@kernel.org Signed-off-by: Vinod Koul <vkoul@kernel.org>
2020-11-24dmaengine: mxs-dma: Remove the unused .id_tableFabio Estevam
The mxs-dma driver is only used by DT platforms and the .id_table is unused. Get rid of it to simplify the code. Signed-off-by: Fabio Estevam <festevam@gmail.com> Link: https://lore.kernel.org/r/20201123193051.17285-1-festevam@gmail.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2020-11-24dmaengine: mv_xor_v2: Fix error return code in mv_xor_v2_probe()Zhihao Cheng
Return the corresponding error code when first_msi_entry() returns NULL in mv_xor_v2_probe(). Fixes: 19a340b1a820430 ("dmaengine: mv_xor_v2: new driver") Reported-by: Hulk Robot <hulkci@huawei.com> Signed-off-by: Zhihao Cheng <chengzhihao1@huawei.com> Link: https://lore.kernel.org/r/20201124010813.1939095-1-chengzhihao1@huawei.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2020-11-24dmaengine: imx-dma: Remove unused .id_tableFabio Estevam
Since 5.10-rc1 i.MX is a devicetree-only platform, so simplify the code by removing the unused non-DT support. Signed-off-by: Fabio Estevam <festevam@gmail.com> Link: https://lore.kernel.org/r/20201124143405.2764-1-festevam@gmail.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2020-11-24dmaengine: qcom: Add GPI dma driverVinod Koul
This controller provides DMAengine capabilities for a variety of peripheral buses such as I2C, UART, and SPI. By using GPI dmaengine driver, bus drivers can use a standardize interface that is protocol independent to transfer data between memory and peripheral. Link: https://lore.kernel.org/r/20201109085450.24843-4-vkoul@kernel.org Signed-off-by: Vinod Koul <vkoul@kernel.org>
2020-11-24dmaengine: add peripheral configurationVinod Koul
Some complex dmaengine controllers have capability to program the peripheral device, so pass on the peripheral configuration as part of dma_slave_config Link: https://lore.kernel.org/r/20201109085450.24843-3-vkoul@kernel.org Signed-off-by: Vinod Koul <vkoul@kernel.org>
2020-11-24dt-bindings: dmaengine: Document qcom,gpi dma bindingVinod Koul
Add devicetree binding documentation for GPI DMA controller implemented on Qualcomm SoCs Reviewed-by: Rob Herring <robh@kernel.org> Link: https://lore.kernel.org/r/20201109085450.24843-2-vkoul@kernel.org Signed-off-by: Vinod Koul <vkoul@kernel.org>
2020-11-24dmaengine: qcom: Add ADM driverJonathan McDowell
Add the DMA engine driver for the QCOM Application Data Mover (ADM) DMA controller found in the MSM8x60 and IPQ/APQ8064 platforms. The ADM supports both memory to memory transactions and memory to/from peripheral device transactions. The controller also provides flow control capabilities for transactions to/from peripheral devices. The initial release of this driver supports slave transfers to/from peripherals and also incorporates CRCI (client rate control interface) flow control. The hardware only supports a 32 bit physical address, so specifying !PHYS_ADDR_T_64BIT gives maximum COMPILE_TEST coverage without having to spend effort on kludging things in the code that will never actually be needed on real hardware. Signed-off-by: Andy Gross <agross@codeaurora.org> Signed-off-by: Thomas Pedersen <twp@codeaurora.org> Signed-off-by: Jonathan McDowell <noodles@earth.li> Link: https://lore.kernel.org/r/20201114140233.GM32650@earth.li Signed-off-by: Vinod Koul <vkoul@kernel.org>
2020-11-21drivers: soc: ti: knav_qmss_queue: Fix error return code in knav_queue_probeZhihao Cheng
Fix to return the error code from of_get_child_by_name() instaed of 0 in knav_queue_probe(). Fixes: 41f93af900a20d1a0a ("soc: ti: add Keystone Navigator QMSS driver") Reported-by: Hulk Robot <hulkci@huawei.com> Signed-off-by: Zhihao Cheng <chengzhihao1@huawei.com> Signed-off-by: Santosh Shilimkar <santosh.shilimkar@oracle.com>
2020-11-21soc: ti: Fix reference imbalance in knav_dma_probeZhang Qilong
The patch fix two reference leak. 1) pm_runtime_get_sync will increment pm usage counter even it failed. Forgetting to call put operation will result in reference leak. 2) The pm_runtime_enable will increase power disable depth. Thus a pairing decrement is needed on the error handling path to keep it balanced. We fix it by: 1) adding call pm_runtime_put_noidle or pm_runtime_put_sync in error handling. 2) adding pm_runtime_disable in error handling, to keep usage counter and disable depth balanced. Fixes: 88139ed030583 ("soc: ti: add Keystone Navigator DMA support") Signed-off-by: Zhang Qilong <zhangqilong3@huawei.com> Signed-off-by: Santosh Shilimkar <santosh.shilimkar@oracle.com>
2020-11-21soc: ti: pruss: Remove wrong check against *get_match_data return valueGrzegorz Jaszczyk
Since the of_device_get_match_data() doesn't return error code, remove wrong IS_ERR test. Proper check against NULL pointer is already done later before usage: if (data && data->...). Additionally, proceeding with empty device data is valid (e.g. in case of "ti,am3356-pruss"). Reported-by: Wei Yongjun <weiyongjun1@huawei.com> Signed-off-by: Grzegorz Jaszczyk <grzegorz.jaszczyk@linaro.org> Signed-off-by: Santosh Shilimkar <santosh.shilimkar@oracle.com>
2020-11-21soc: ti: Kconfig: Drop ARM64 SoC specific configsNishanth Menon
With the integration of chip-id detection scheme in kernel[1], there is no specific need to maintain multitudes of SoC specific config options, discussed as per [2], we have deprecated the usage in other places for v5.10-rc1. Drop the configuration for the follow on kernel. [1] drivers/soc/ti/k3-socinfo.c commit 907a2b7e2fc7 ("soc: ti: add k3 platforms chipid module driver") Signed-off-by: Nishanth Menon <nm@ti.com> Signed-off-by: Santosh Shilimkar <santosh.shilimkar@oracle.com>
2020-11-21soc: ti: k3-ringacc: Provide documentation for 'k3_ring's 'state'Lee Jones
Fixes the following W=1 kernel build warning(s): drivers/soc/ti/k3-ringacc.c:163: warning: Function parameter or member 'state' not described in 'k3_ring' Cc: Santosh Shilimkar <ssantosh@kernel.org> Signed-off-by: Lee Jones <lee.jones@linaro.org> Signed-off-by: Santosh Shilimkar <santosh.shilimkar@oracle.com>
2020-11-21soc: ti: wkup_m3_ipc: Document 'm3_ipc' parameter throughoutLee Jones
Fixes the following W=1 kernel build warning(s): drivers/soc/ti/wkup_m3_ipc.c:227: warning: Function parameter or member 'm3_ipc' not described in 'wkup_m3_set_mem_type' drivers/soc/ti/wkup_m3_ipc.c:236: warning: Function parameter or member 'm3_ipc' not described in 'wkup_m3_set_resume_address' drivers/soc/ti/wkup_m3_ipc.c:248: warning: Function parameter or member 'm3_ipc' not described in 'wkup_m3_request_pm_status' drivers/soc/ti/wkup_m3_ipc.c:268: warning: Function parameter or member 'm3_ipc' not described in 'wkup_m3_prepare_low_power' drivers/soc/ti/wkup_m3_ipc.c:322: warning: Function parameter or member 'm3_ipc' not described in 'wkup_m3_finish_low_power' drivers/soc/ti/wkup_m3_ipc.c:369: warning: Function parameter or member 'm3_ipc' not described in 'wkup_m3_set_rtc_only' drivers/soc/ti/wkup_m3_ipc.c:369: warning: Excess function parameter 'wkup_m3_wakeup' description in 'wkup_m3_set_rtc_only' Cc: Santosh Shilimkar <ssantosh@kernel.org> Cc: Dave Gerlach <d-gerlach@ti.com> Signed-off-by: Lee Jones <lee.jones@linaro.org> Signed-off-by: Santosh Shilimkar <santosh.shilimkar@oracle.com>
2020-11-21soc: ti: pm33xx: Remove set but unused variable 'ret'Lee Jones
Fixes the following W=1 kernel build warning(s): drivers/soc/ti/pm33xx.c: In function ‘am33xx_do_sram_idle’: drivers/soc/ti/pm33xx.c:138:6: warning: variable ‘ret’ set but not used [-Wunused-but-set-variable] Cc: Santosh Shilimkar <ssantosh@kernel.org> Signed-off-by: Lee Jones <lee.jones@linaro.org> Signed-off-by: Santosh Shilimkar <santosh.shilimkar@oracle.com>
2020-11-21soc: ti: knav_dma: Fix a kernel function doc formatting issueLee Jones
Fixes the following W=1 kernel build warning(s): drivers/soc/ti/knav_dma.c:507: warning: Function parameter or member 'channel' not described in 'knav_dma_close_channel' Cc: Santosh Shilimkar <ssantosh@kernel.org> Cc: Sandeep Nair <sandeep_n@ti.com> Cc: Cyril Chemparathy <cyril@ti.com> Signed-off-by: Lee Jones <lee.jones@linaro.org> Signed-off-by: Santosh Shilimkar <santosh.shilimkar@oracle.com>
2020-11-21soc: ti: knav_qmss_queue: Fix a whole host of function documentation issuesLee Jones
Fixes the following W=1 kernel build warning(s): drivers/soc/ti/knav_qmss_queue.c:528: warning: Function parameter or member 'flags' not described in 'knav_queue_open' drivers/soc/ti/knav_qmss_queue.c:528: warning: Function parameter or member 'id' not described in 'knav_queue_open' drivers/soc/ti/knav_qmss_queue.c:528: warning: Function parameter or member 'name' not described in 'knav_queue_open' drivers/soc/ti/knav_qmss_queue.c:551: warning: Excess function parameter 'qh' description in 'knav_queue_close' drivers/soc/ti/knav_qmss_queue.c:551: warning: Function parameter or member 'qhandle' not described in 'knav_queue_close' drivers/soc/ti/knav_qmss_queue.c:583: warning: Excess function parameter 'qh' description in 'knav_queue_device_control' drivers/soc/ti/knav_qmss_queue.c:583: warning: Function parameter or member 'arg' not described in 'knav_queue_device_control' drivers/soc/ti/knav_qmss_queue.c:583: warning: Function parameter or member 'cmd' not described in 'knav_queue_device_control' drivers/soc/ti/knav_qmss_queue.c:583: warning: Function parameter or member 'qhandle' not described in 'knav_queue_device_control' drivers/soc/ti/knav_qmss_queue.c:635: warning: Excess function parameter 'data' description in 'knav_queue_push' drivers/soc/ti/knav_qmss_queue.c:635: warning: Excess function parameter 'qh' description in 'knav_queue_push' drivers/soc/ti/knav_qmss_queue.c:635: warning: Function parameter or member 'dma' not described in 'knav_queue_push' drivers/soc/ti/knav_qmss_queue.c:635: warning: Function parameter or member 'flags' not described in 'knav_queue_push' drivers/soc/ti/knav_qmss_queue.c:635: warning: Function parameter or member 'qhandle' not described in 'knav_queue_push' drivers/soc/ti/knav_qmss_queue.c:635: warning: Function parameter or member 'size' not described in 'knav_queue_push' drivers/soc/ti/knav_qmss_queue.c:655: warning: Excess function parameter 'qh' description in 'knav_queue_pop' drivers/soc/ti/knav_qmss_queue.c:655: warning: Function parameter or member 'qhandle' not described in 'knav_queue_pop' drivers/soc/ti/knav_qmss_queue.c:655: warning: Function parameter or member 'size' not described in 'knav_queue_pop' drivers/soc/ti/knav_qmss_queue.c:759: warning: Function parameter or member 'name' not described in 'knav_pool_create' drivers/soc/ti/knav_qmss_queue.c:759: warning: Function parameter or member 'num_desc' not described in 'knav_pool_create' drivers/soc/ti/knav_qmss_queue.c:759: warning: Function parameter or member 'region_id' not described in 'knav_pool_create' drivers/soc/ti/knav_qmss_queue.c:862: warning: Excess function parameter 'pool' description in 'knav_pool_destroy' drivers/soc/ti/knav_qmss_queue.c:862: warning: Function parameter or member 'ph' not described in 'knav_pool_destroy' drivers/soc/ti/knav_qmss_queue.c:892: warning: Excess function parameter 'pool' description in 'knav_pool_desc_get' drivers/soc/ti/knav_qmss_queue.c:892: warning: Function parameter or member 'ph' not described in 'knav_pool_desc_get' drivers/soc/ti/knav_qmss_queue.c:911: warning: Excess function parameter 'pool' description in 'knav_pool_desc_put' drivers/soc/ti/knav_qmss_queue.c:911: warning: Function parameter or member 'desc' not described in 'knav_pool_desc_put' drivers/soc/ti/knav_qmss_queue.c:911: warning: Function parameter or member 'ph' not described in 'knav_pool_desc_put' drivers/soc/ti/knav_qmss_queue.c:931: warning: Excess function parameter 'pool' description in 'knav_pool_desc_map' drivers/soc/ti/knav_qmss_queue.c:931: warning: Function parameter or member 'desc' not described in 'knav_pool_desc_map' drivers/soc/ti/knav_qmss_queue.c:931: warning: Function parameter or member 'dma' not described in 'knav_pool_desc_map' drivers/soc/ti/knav_qmss_queue.c:931: warning: Function parameter or member 'dma_sz' not described in 'knav_pool_desc_map' drivers/soc/ti/knav_qmss_queue.c:931: warning: Function parameter or member 'ph' not described in 'knav_pool_desc_map' drivers/soc/ti/knav_qmss_queue.c:931: warning: Function parameter or member 'size' not described in 'knav_pool_desc_map' drivers/soc/ti/knav_qmss_queue.c:956: warning: Excess function parameter 'pool' description in 'knav_pool_desc_unmap' drivers/soc/ti/knav_qmss_queue.c:956: warning: Function parameter or member 'dma' not described in 'knav_pool_desc_unmap' drivers/soc/ti/knav_qmss_queue.c:956: warning: Function parameter or member 'dma_sz' not described in 'knav_pool_desc_unmap' drivers/soc/ti/knav_qmss_queue.c:956: warning: Function parameter or member 'ph' not described in 'knav_pool_desc_unmap' drivers/soc/ti/knav_qmss_queue.c:975: warning: Excess function parameter 'pool' description in 'knav_pool_count' drivers/soc/ti/knav_qmss_queue.c:975: warning: Function parameter or member 'ph' not described in 'knav_pool_count' Cc: Santosh Shilimkar <ssantosh@kernel.org> Cc: Sandeep Nair <sandeep_n@ti.com> Cc: Cyril Chemparathy <cyril@ti.com> Signed-off-by: Lee Jones <lee.jones@linaro.org> Signed-off-by: Santosh Shilimkar <santosh.shilimkar@oracle.com>
2020-11-21soc: ti: knav_qmss_queue: Remove set but unchecked variable 'ret'Lee Jones
Fixes the following W=1 kernel build warning(s): drivers/soc/ti/knav_qmss_queue.c: In function ‘knav_setup_queue_pools’: drivers/soc/ti/knav_qmss_queue.c:1310:6: warning: variable ‘ret’ set but not used [-Wunused-but-set-variable] Cc: Santosh Shilimkar <ssantosh@kernel.org> Cc: Sandeep Nair <sandeep_n@ti.com> Cc: Cyril Chemparathy <cyril@ti.com> Signed-off-by: Lee Jones <lee.jones@linaro.org> Signed-off-by: Santosh Shilimkar <santosh.shilimkar@oracle.com>
generated by cgit v1.2.3 (git 2.25.1) at 2024-08-18 15:18:42 +0000