kernel/linux.git/drivers/dma/qcom, branch linux-5.11.y

dmaengine: qcom: Always inline gpi_update_reg

2021-03-04T11:14:35+00:00

[ Upstream commit 0a6d3038d914b51d6860f23ea2b508590e8340de ] When building with CONFIG_UBSAN_UNSIGNED_OVERFLOW, clang decides not to inline gpi_update_reg, which causes a linkage failure around __bad_mask: ld.lld: error: undefined symbol: __bad_mask >>> referenced by bitfield.h:119 (include/linux/bitfield.h:119) >>> dma/qcom/gpi.o:(gpi_update_reg) in archive drivers/built-in.a >>> referenced by bitfield.h:119 (include/linux/bitfield.h:119) >>> dma/qcom/gpi.o:(gpi_update_reg) in archive drivers/built-in.a If gpi_update_reg is not inlined, the mask value will not be known at compile time so the check in field_multiplier stays in the final object file, causing the above linkage failure. Always inline gpi_update_reg so that this check can never fail. Fixes: 5d0c3533a19f ("dmaengine: qcom: Add GPI dma driver") Link: https://github.com/ClangBuiltLinux/linux/issues/1243 Signed-off-by: Nathan Chancellor Link: https://lore.kernel.org/r/20210112191214.1264793-1-natechancellor@gmail.com Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin

dmaengine: qcom: fix gpi undefined behavior

2021-01-04T12:38:36+00:00

gcc points out an incorrect error handling loop: drivers/dma/qcom/gpi.c: In function 'gpi_ch_init': drivers/dma/qcom/gpi.c:1254:15: error: iteration 2 invokes undefined behavior [-Werror=aggressive-loop-optimizations] 1254 | struct gpii *gpii = gchan->gpii; | ^~~~ drivers/dma/qcom/gpi.c:1951:2: note: within this loop 1951 | for (i = i - 1; i >= 0; i++) { | ^~~ Change the loop to correctly walk backwards through the initialized fields rather than off into the woods. Fixes: 5d0c3533a19f ("dmaengine: qcom: Add GPI dma driver") Signed-off-by: Arnd Bergmann Link: https://lore.kernel.org/r/20210103135738.3741123-1-arnd@kernel.org Signed-off-by: Vinod Koul

qcom: bam_dma: Delete useless kfree code

2020-12-29T04:38:00+00:00

The parameter of kfree function is NULL, so kfree code is useless, delete it. Therefore, goto expression is no longer needed, so simplify it. Signed-off-by: Zheng Yongjun Reviewed-by: Bjorn Andersson Link: https://lore.kernel.org/r/20201216130649.13979-1-zhengyongjun3@huawei.com Signed-off-by: Vinod Koul

dmaengine: qcom: gpi: Fixes a format mismatch

2020-12-29T04:37:59+00:00

drivers/dma/qcom/gpi.c:1419:3: warning: format '%lu' expects argument of type 'long unsigned int', but argument 8 has type 'size_t {aka unsigned int}' [-Wformat=] drivers/dma/qcom/gpi.c:1427:31: warning: format '%lu' expects argument of type 'long unsigned int', but argument 3 has type 'size_t {aka unsigned int}' [-Wformat=] drivers/dma/qcom/gpi.c:1447:3: warning: format '%llx' expects argument of type 'long long unsigned int', but argument 4 has type 'dma_addr_t {aka unsigned int}' [-Wformat=] drivers/dma/qcom/gpi.c:1447:3: warning: format '%llx' expects argument of type 'long long unsigned int', but argument 5 has type 'phys_addr_t {aka unsigned int}' [-Wformat=] Signed-off-by: Xiaoming Ni Reviewed-by: Bjorn Andersson Link: https://lore.kernel.org/r/20201218104137.59200-1-nixiaoming@huawei.com Signed-off-by: Vinod Koul

dmaengine: bam_dma: fix return of bam_dma_irq()

2020-12-11T14:18:28+00:00

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] [] el1_irq+0xb0/0x124 [ 58.345971] [] arch_cpu_idle+0x10/0x18 [ 58.345975] [] do_idle+0x1ac/0x1e0 [ 58.345979] [] cpu_startup_entry+0x20/0x28 [ 58.345983] [] rest_init+0xd0/0xdc [ 58.345988] [] start_kernel+0x390/0x3a4 [ 58.345990] handlers: [ 58.345994] [] 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 Link: https://lore.kernel.org/r/1607322820-7450-1-git-send-email-sparth1292@gmail.com Signed-off-by: Vinod Koul

dmaengine: qcom: Fix ADM driver kerneldoc markup

2020-12-11T13:36:47+00:00

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 Link: https://lore.kernel.org/r/20201126184602.GA1008@earth.li Signed-off-by: Vinod Koul

dmaengine: qcom: Add GPI dma driver

2020-11-24T16:12:07+00:00

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

dmaengine: qcom: Add ADM driver

2020-11-24T16:11:15+00:00

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 Signed-off-by: Thomas Pedersen Signed-off-by: Jonathan McDowell Link: https://lore.kernel.org/r/20201114140233.GM32650@earth.li Signed-off-by: Vinod Koul

dmaengine: qcom: bam_dma: fix kernel-doc style for tasklet

2020-10-08T09:48:41+00:00

Commit 00c4747a2f64 ("dmaengine: qcom: convert tasklets to use new tasklet_setup() API") updated driver to use new tasklet_setup() API but missed to update the documentation for the tasklet function. Fixes: 00c4747a2f64 ("dmaengine: qcom: convert tasklets to use new tasklet_setup() API") Link: https://lore.kernel.org/r/20201007083113.567559-3-vkoul@kernel.org Signed-off-by: Vinod Koul

dmaengine: qcom: convert tasklets to use new tasklet_setup() API

2020-09-18T06:49:07+00:00

In preparation for unconditionally passing the struct tasklet_struct pointer to all tasklet callbacks, switch to using the new tasklet_setup() and from_tasklet() to pass the tasklet pointer explicitly. Signed-off-by: Romain Perier Signed-off-by: Allen Pais Link: https://lore.kernel.org/r/20200831103542.305571-23-allen.lkml@gmail.com Signed-off-by: Vinod Koul