dmaengine: Switch back to struct platform_driver::remove()

After commit 0edb555a65d1 ("platform: Make platform_driver::remove()
return void") .remove() is (again) the right callback to implement for

dmaengine: Switch back to struct platform_driver::remove()

After commit 0edb555a65d1 ("platform: Make platform_driver::remove()
return void") .remove() is (again) the right callback to implement for
platform drivers.

Convert all platform drivers below drivers/dma after the previous
conversion commits apart from the wireless drivers to use .remove(),
with the eventual goal to drop struct platform_driver::remove_new(). As
.remove() and .remove_new() have the same prototypes, conversion is done
by just changing the structure member name in the driver initializer.

Signed-off-by: Uwe Kleine-König <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Vinod Koul <[email protected]>

show more ...

dmaengine: ti: cppi41: add missing MODULE_DESCRIPTION() macro

With ARCH=arm, make allmodconfig && make W=1 C=1 reports:
WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/dma/ti/cppi41.o

Add

dmaengine: ti: cppi41: add missing MODULE_DESCRIPTION() macro

With ARCH=arm, make allmodconfig && make W=1 C=1 reports:
WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/dma/ti/cppi41.o

Add the missing invocation of the MODULE_DESCRIPTION() macro.

Signed-off-by: Jeff Johnson <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Vinod Koul <[email protected]>

show more ...

dmaengine: ti: cppi41: Convert to platform remove callback returning void

The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to

dmaengine: ti: cppi41: Convert to platform remove callback returning void

The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do error handling by
returning an error code. However the value returned is ignored (apart
from emitting a warning) and this typically results in resource leaks.
To improve here there is a quest to make the remove callback return
void. In the first step of this quest all drivers are converted to
.remove_new() which already returns void. Eventually after all drivers
are converted, .remove_new() is renamed to .remove().

Trivially convert this driver from always returning zero in the remove
callback to the void returning variant.

Signed-off-by: Uwe Kleine-König <[email protected]>
Reviewed-by: Peter Ujfalusi <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Vinod Koul <[email protected]>

show more ...

dmaengine: drivers: Use devm_platform_ioremap_resource()

platform_get_resource() and devm_ioremap_resource() are wrapped up in the
devm_platform_ioremap_resource() helper. Use the helper and get rid

dmaengine: drivers: Use devm_platform_ioremap_resource()

platform_get_resource() and devm_ioremap_resource() are wrapped up in the
devm_platform_ioremap_resource() helper. Use the helper and get rid of the
local variable for struct resource *. We now have a function call less.

Signed-off-by: Tudor Ambarus <[email protected]>
Acked-by: Jernej Skrabec <[email protected]>
Acked-by: Peter Ujfalusi <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Vinod Koul <[email protected]>

show more ...

dmaengine: ti: deprecate '#dma-channels'

The generic property, used in most of the drivers and defined in generic
dma-common DT bindings, is 'dma-channels'. Switch to new property while
keeping bac

dmaengine: ti: deprecate '#dma-channels'

The generic property, used in most of the drivers and defined in generic
dma-common DT bindings, is 'dma-channels'. Switch to new property while
keeping backward compatibility.

Signed-off-by: Krzysztof Kozlowski <[email protected]>
Reviewed-by: Tony Lindgren <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Vinod Koul <[email protected]>

show more ...

dmaengine: ti: cleanup comments

Remove the second 'the'

Replacements
completetion to completion
seens to seen
pendling to pending
atleast to at least
tranfer to transfer
multibple to a multiple
tra

dmaengine: ti: cleanup comments

Remove the second 'the'

Replacements
completetion to completion
seens to seen
pendling to pending
atleast to at least
tranfer to transfer
multibple to a multiple
transfering to transferring

Signed-off-by: Tom Rix <[email protected]>
Acked-by: Peter Ujfalusi <[email protected]>
Reviewed-by: Randy Dunlap <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Vinod Koul <[email protected]>

show more ...

dmaengine: cppi41: Fix cppi41_dma_prep_slave_sg() when idle

Yegor Yefremov <[email protected]> reported that musb and ftdi
uart can fail for the first open of the uart unless connected usin

dmaengine: cppi41: Fix cppi41_dma_prep_slave_sg() when idle

Yegor Yefremov <[email protected]> reported that musb and ftdi
uart can fail for the first open of the uart unless connected using
a hub.

This is because the first dma call done by musb_ep_program() must wait
if cppi41 is PM runtime suspended. Otherwise musb_ep_program() continues
with other non-dma packets before the DMA transfer is started causing at
least ftdi uarts to fail to receive data.

Let's fix the issue by waking up cppi41 with PM runtime calls added to
cppi41_dma_prep_slave_sg() and return NULL if still idled. This way we
have musb_ep_program() continue with PIO until cppi41 is awake.

Fixes: fdea2d09b997 ("dmaengine: cppi41: Add basic PM runtime support")
Reported-by: Yegor Yefremov <[email protected]>
Signed-off-by: Tony Lindgren <[email protected]>
Cc: [email protected] # v4.9+
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Vinod Koul <[email protected]>

show more ...

treewide: Add SPDX license identifier for more missed files

Add SPDX license identifiers to all files which:

- Have no license information of any form

- Have MODULE_LICENCE("GPL*") inside which

treewide: Add SPDX license identifier for more missed files

Add SPDX license identifiers to all files which:

- Have no license information of any form

- Have MODULE_LICENCE("GPL*") inside which was used in the initial
scan/conversion to ignore the file

These files fall under the project license, GPL v2 only. The resulting SPDX
license identifier is:

GPL-2.0-only

Signed-off-by: Thomas Gleixner <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

show more ...

dmaengine: cppi41: delete channel from pending list when stop channel

The driver defines three states for a cppi channel.
- idle: .chan_busy == 0 && not in .pending list
- pending: .chan_busy == 0 &

dmaengine: cppi41: delete channel from pending list when stop channel

The driver defines three states for a cppi channel.
- idle: .chan_busy == 0 && not in .pending list
- pending: .chan_busy == 0 && in .pending list
- busy: .chan_busy == 1 && not in .pending list

There are cases in which the cppi channel could be in the pending state
when cppi41_dma_issue_pending() is called after cppi41_runtime_suspend()
is called.

cppi41_stop_chan() has a bug for these cases to set channels to idle state.
It only checks the .chan_busy flag, but not the .pending list, then later
when cppi41_runtime_resume() is called the channels in .pending list will
be transitioned to busy state.

Removing channels from the .pending list solves the problem.

Fixes: 975faaeb9985 ("dma: cppi41: start tear down only if channel is busy")
Cc: [email protected] # v3.15+
Signed-off-by: Bin Liu <[email protected]>
Reviewed-by: Peter Ujfalusi <[email protected]>
Signed-off-by: Vinod Koul <[email protected]>

show more ...

dmaengine: ti: New directory for Texas Instruments DMA drivers

Collect the Texas Instruments DMA drivers under drivers/dma/ti/

Signed-off-by: Peter Ujfalusi <[email protected]>
Signed-off-by: V

dmaengine: ti: New directory for Texas Instruments DMA drivers

Collect the Texas Instruments DMA drivers under drivers/dma/ti/

Signed-off-by: Peter Ujfalusi <[email protected]>
Signed-off-by: Vinod Koul <[email protected]>

show more ...