Dmitry Baryshkov
adfa452f16
dma: gpi: remove spurious unlock in gpi_ch_init
...
[ Upstream commit 91d6a468e3 ]
gpi_ch_init() doesn't lock the ctrl_lock mutex, so there is no need to
unlock it too. Instead the mutex is handled by the function
gpi_alloc_chan_resources(), which properly locks and unlocks the mutex.
=====================================
WARNING: bad unlock balance detected!
6.3.0-rc5-00253-g99792582ded1-dirty #15 Not tainted
-------------------------------------
kworker/u16:0/9 is trying to release lock (&gpii->ctrl_lock) at:
[<ffffb99d04e1284c>] gpi_alloc_chan_resources+0x108/0x5bc
but there are no more locks to release!
other info that might help us debug this:
6 locks held by kworker/u16:0/9:
#0 : ffff575740010938 ((wq_completion)events_unbound){+.+.}-{0:0}, at: process_one_work+0x220/0x594
#1 : ffff80000809bdd0 (deferred_probe_work){+.+.}-{0:0}, at: process_one_work+0x220/0x594
#2 : ffff575740f2a0f8 (&dev->mutex){....}-{3:3}, at: __device_attach+0x38/0x188
#3 : ffff57574b5570f8 (&dev->mutex){....}-{3:3}, at: __device_attach+0x38/0x188
#4 : ffffb99d06a2f180 (of_dma_lock){+.+.}-{3:3}, at: of_dma_request_slave_channel+0x138/0x280
#5 : ffffb99d06a2ee20 (dma_list_mutex){+.+.}-{3:3}, at: dma_get_slave_channel+0x28/0x10c
stack backtrace:
CPU: 7 PID: 9 Comm: kworker/u16:0 Not tainted 6.3.0-rc5-00253-g99792582ded1-dirty #15
Hardware name: Google Pixel 3 (DT)
Workqueue: events_unbound deferred_probe_work_func
Call trace:
dump_backtrace+0xa0/0xfc
show_stack+0x18/0x24
dump_stack_lvl+0x60/0xac
dump_stack+0x18/0x24
print_unlock_imbalance_bug+0x130/0x148
lock_release+0x270/0x300
__mutex_unlock_slowpath+0x48/0x2cc
mutex_unlock+0x20/0x2c
gpi_alloc_chan_resources+0x108/0x5bc
dma_chan_get+0x84/0x188
dma_get_slave_channel+0x5c/0x10c
gpi_of_dma_xlate+0x110/0x1a0
of_dma_request_slave_channel+0x174/0x280
dma_request_chan+0x3c/0x2d4
geni_i2c_probe+0x544/0x63c
platform_probe+0x68/0xc4
really_probe+0x148/0x2ac
__driver_probe_device+0x78/0xe0
driver_probe_device+0x3c/0x160
__device_attach_driver+0xb8/0x138
bus_for_each_drv+0x84/0xe0
__device_attach+0x9c/0x188
device_initial_probe+0x14/0x20
bus_probe_device+0xac/0xb0
device_add+0x60c/0x7d8
of_device_add+0x44/0x60
of_platform_device_create_pdata+0x90/0x124
of_platform_bus_create+0x15c/0x3c8
of_platform_populate+0x58/0xf8
devm_of_platform_populate+0x58/0xbc
geni_se_probe+0xf0/0x164
platform_probe+0x68/0xc4
really_probe+0x148/0x2ac
__driver_probe_device+0x78/0xe0
driver_probe_device+0x3c/0x160
__device_attach_driver+0xb8/0x138
bus_for_each_drv+0x84/0xe0
__device_attach+0x9c/0x188
device_initial_probe+0x14/0x20
bus_probe_device+0xac/0xb0
deferred_probe_work_func+0x8c/0xc8
process_one_work+0x2bc/0x594
worker_thread+0x228/0x438
kthread+0x108/0x10c
ret_from_fork+0x10/0x20
Fixes: 5d0c3533a1 ("dmaengine: qcom: Add GPI dma driver")
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org >
Link: https://lore.kernel.org/r/20230409233355.453741-1-dmitry.baryshkov@linaro.org
Signed-off-by: Vinod Koul <vkoul@kernel.org >
Signed-off-by: Sasha Levin <sashal@kernel.org >
2023-05-11 23:17:35 +09:00
Vijaya Krishna Nivarthi
25e8ac233d
dmaengine: qcom: gpi: Set link_rx bit on GO TRE for rx operation
...
Rx operation on SPI GSI DMA is currently not working.
As per GSI spec, link_rx bit is to be set on GO TRE on tx
channel whenever there is going to be a DMA TRE on rx
channel. This is currently set for duplex operation only.
Set the bit for rx operation as well.
This is part of changes required to bring up Rx.
Fixes: 94b8f0e58f ("dmaengine: qcom: gpi: set chain and link flag for duplex")
Signed-off-by: Vijaya Krishna Nivarthi <quic_vnivarth@quicinc.com >
Reviewed-by: Douglas Anderson <dianders@chromium.org >
Link: https://lore.kernel.org/r/1671212293-14767-1-git-send-email-quic_vnivarth@quicinc.com
Signed-off-by: Vinod Koul <vkoul@kernel.org >
2022-12-28 12:26:11 +05:30
Krzysztof Kozlowski
88bc8ac63d
dmaengine: qcom: gpi: Document preferred SM6350 binding
...
Devices with ee offset of 0x10000 should rather bind with SM6350
compatible, so the list will not unnecessarily grow for compatible
devices.
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org >
Acked-by: Richard Acayan <mailingradian@gmail.com >
Link: https://lore.kernel.org/r/20221018230352.1238479-3-krzysztof.kozlowski@linaro.org
Signed-off-by: Vinod Koul <vkoul@kernel.org >
2022-10-19 18:19:01 +05:30
Richard Acayan
8527721ee6
dmaengine: qcom: deprecate redundant of_device_id entries
...
The drivers are transitioning from matching against lists of specific
compatible strings to matching against smaller lists of more generic
compatible strings. Add a message that the compatible strings with an
ee_offset of 0 are deprecated except for the SDM845 compatible string.
Signed-off-by: Richard Acayan <mailingradian@gmail.com >
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org >
Link: https://lore.kernel.org/r/20221018005740.23952-4-mailingradian@gmail.com
Signed-off-by: Vinod Koul <vkoul@kernel.org >
2022-10-19 18:18:12 +05:30
Tuo Cao
c10a7777dd
dmaengine: qcom: gpi: move read_lock_bh to read_lock in tasklet
...
it is unnecessary to call read_lock_bh in a tasklet.
Signed-off-by: Tuo Cao <91tuocao@gmail.com >
Link: https://lore.kernel.org/r/20220814131323.7029-1-91tuocao@gmail.com
Signed-off-by: Vinod Koul <vkoul@kernel.org >
2022-09-29 12:21:33 +05:30
Luca Weiss
5abef9d713
dmaengine: qcom: gpi: Add SM6350 support
...
The Qualcomm SM6350 platform does, like the SM8450, provide a set of GPI
controllers with an ee-offset of 0x10000. Add this to the driver.
Signed-off-by: Luca Weiss <luca.weiss@fairphone.com >
Reviewed-by: Bjorn Andersson <andersson@kernel.org >
Link: https://lore.kernel.org/r/20220812082721.1125759-3-luca.weiss@fairphone.com
Signed-off-by: Vinod Koul <vkoul@kernel.org >
2022-09-04 21:52:36 +05:30
Vinod Koul
c7399e6d3b
dmaengine: qcom: gpi: Add support for sc7280
...
Add compatible and driver_data for GPI DMA engines found in Qualcomm
SC7280. The driver_data contains ee_offset of 0x10000.
Signed-off-by: Vinod Koul <vkoul@kernel.org >
Link: https://lore.kernel.org/r/20220421121733.1829350-1-vkoul@kernel.org
Signed-off-by: Vinod Koul <vkoul@kernel.org >
2022-05-19 23:43:40 +05:30
Bjorn Andersson
d0a3ef6048
dmaengine: qcom: gpi: Add SM8350 support
...
The Qualcomm SM8350 platform does, like the SM8450, provide a set of GPI
controllers with an ee-offset of 0x10000. Add this to the driver.
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org >
Link: https://lore.kernel.org/r/20220412212959.2385085-1-bjorn.andersson@linaro.org
Signed-off-by: Vinod Koul <vkoul@kernel.org >
2022-04-13 17:55:36 +05:30
Vinod Koul
6316572cf3
dmaengine: qcom: gpi: Add support for ee_offset
...
Controller on newer SoCs like SM8450 have registers at at offset. Add
ee_offset to driver_data and add this compatible for the driver.
Signed-off-by: Vinod Koul <vkoul@kernel.org >
Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org >
Tested-by: Bjorn Andersson <bjorn.andersson@linaro.org >
Link: https://lore.kernel.org/r/20220406132508.1029348-3-vkoul@kernel.org
Signed-off-by: Vinod Koul <vkoul@kernel.org >
2022-04-13 17:54:39 +05:30
Vinod Koul
94b8f0e58f
dmaengine: qcom: gpi: set chain and link flag for duplex
...
Newer platforms seem to have strict requirement for TRE flags which
causes transaction to timeout. This was resolved to missing chain and
link flag for duplex spi transaction.
So add these two flags.
Signed-off-by: Vinod Koul <vkoul@kernel.org >
Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org >
Tested-by: Bjorn Andersson <bjorn.andersson@linaro.org >
Link: https://lore.kernel.org/r/20220406132508.1029348-1-vkoul@kernel.org
Signed-off-by: Vinod Koul <vkoul@kernel.org >
2022-04-13 17:54:39 +05:30
Xu Wang
2bfab6f8b4
dmaengine: qcom: gpi: Remove unnecessary print function dev_err()
...
The print function dev_err() is redundant because
platform_get_irq() already prints an error.
Signed-off-by: Xu Wang <vulab@iscas.ac.cn >
Link: https://lore.kernel.org/r/20211116013306.784-1-vulab@iscas.ac.cn
Signed-off-by: Vinod Koul <vkoul@kernel.org >
2021-11-22 12:29:04 +05:30
Konrad Dybcio
23e51f110f
dmaengine: qcom: gpi: Add SM8250 compatible
...
SM8250 seems to work just fine, so add a shiny new compatible for it.
Signed-off-by: Konrad Dybcio <konrad.dybcio@somainline.org >
Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org >
Link: https://lore.kernel.org/r/20210614235358.444834-2-konrad.dybcio@somainline.org
Signed-off-by: Vinod Koul <vkoul@kernel.org >
2021-06-16 16:06:10 +05:30
Felipe Balbi
0b0f93cf91
dt-bindings: dmaengine: qcom: gpi: add compatible for sm8150
...
No functional changes, just adding a new compatible for a diferent
SoC.
Signed-off-by: Felipe Balbi <felipe.balbi@microsoft.com >
Link: https://lore.kernel.org/r/20210417061951.2105530-2-balbi@kernel.org
Signed-off-by: Vinod Koul <vkoul@kernel.org >
2021-04-20 15:37:03 +05:30
Linus Torvalds
143983e585
Merge tag 'dmaengine-5.12-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/vkoul/dmaengine
...
Pull dmaengine updates from Vinod Koul:
"We have couple of drivers removed a new driver and bunch of new device
support and few updates to drivers for this round.
New drivers/devices:
- Intel LGM SoC DMA driver
- Actions Semi S500 DMA controller
- Renesas r8a779a0 dma controller
- Ingenic JZ4760(B) dma controller
- Intel KeemBay AxiDMA controller
Removed:
- Coh901318 dma driver
- Zte zx dma driver
- Sirfsoc dma driver
Updates:
- mmp_pdma, mmp_tdma gained module support
- imx-sdma become modern and dropped platform data support
- dw-axi driver gained slave and cyclic dma support"
* tag 'dmaengine-5.12-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/vkoul/dmaengine: (58 commits)
dmaengine: dw-axi-dmac: remove redundant null check on desc
dmaengine: xilinx_dma: Alloc tx descriptors GFP_NOWAIT
dmaengine: dw-axi-dmac: Virtually split the linked-list
dmaengine: dw-axi-dmac: Set constraint to the Max segment size
dmaengine: dw-axi-dmac: Add Intel KeemBay AxiDMA BYTE and HALFWORD registers
dmaengine: dw-axi-dmac: Add Intel KeemBay AxiDMA handshake
dmaengine: dw-axi-dmac: Add Intel KeemBay AxiDMA support
dmaengine: drivers: Kconfig: add HAS_IOMEM dependency to DW_AXI_DMAC
dmaengine: dw-axi-dmac: Add Intel KeemBay DMA register fields
dt-binding: dma: dw-axi-dmac: Add support for Intel KeemBay AxiDMA
dmaengine: dw-axi-dmac: Support burst residue granularity
dmaengine: dw-axi-dmac: Support of_dma_controller_register()
dmaegine: dw-axi-dmac: Support device_prep_dma_cyclic()
dmaengine: dw-axi-dmac: Support device_prep_slave_sg
dmaengine: dw-axi-dmac: Add device_config operation
dmaengine: dw-axi-dmac: Add device_synchronize() callback
dmaengine: dw-axi-dmac: move dma_pool_create() to alloc_chan_resources()
dmaengine: dw-axi-dmac: simplify descriptor management
dt-bindings: dma: Add YAML schemas for dw-axi-dmac
dmaengine: ti: k3-psil: optimize struct psil_endpoint_config for size
...
2021-02-23 15:05:10 -08:00
Xu Wang
9ee8f3d968
dmaengine: qcom: gpi: Remove unneeded semicolon
...
fix semicolon.cocci warning:
drivers/dma/qcom/gpi.c:1703:2-3: Unneeded semicolon
Signed-off-by: Xu Wang <vulab@iscas.ac.cn >
Link: https://lore.kernel.org/r/20210115100040.33364-1-vulab@iscas.ac.cn
Signed-off-by: Vinod Koul <vkoul@kernel.org >
2021-01-17 11:54:58 +05:30
Nathan Chancellor
0a6d3038d9
dmaengine: qcom: Always inline gpi_update_reg
...
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: 5d0c3533a1 ("dmaengine: qcom: Add GPI dma driver")
Link: https://github.com/ClangBuiltLinux/linux/issues/1243
Signed-off-by: Nathan Chancellor <natechancellor@gmail.com >
Link: https://lore.kernel.org/r/20210112191214.1264793-1-natechancellor@gmail.com
Signed-off-by: Vinod Koul <vkoul@kernel.org >
2021-01-13 16:51:17 +05:30
Arnd Bergmann
0bd1bf86ab
dmaengine: qcom: fix gpi undefined behavior
...
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: 5d0c3533a1 ("dmaengine: qcom: Add GPI dma driver")
Signed-off-by: Arnd Bergmann <arnd@arndb.de >
Link: https://lore.kernel.org/r/20210103135738.3741123-1-arnd@kernel.org
Signed-off-by: Vinod Koul <vkoul@kernel.org >
2021-01-04 18:08:36 +05:30
Xiaoming Ni
8fb28795fb
dmaengine: qcom: gpi: Fixes a format mismatch
...
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 <nixiaoming@huawei.com >
Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org >
Link: https://lore.kernel.org/r/20201218104137.59200-1-nixiaoming@huawei.com
Signed-off-by: Vinod Koul <vkoul@kernel.org >
2020-12-29 10:07:59 +05:30
Vinod Koul
5d0c3533a1
dmaengine: qcom: Add GPI dma driver
...
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-24 21:42:07 +05:30