linux-toradex.git/drivers/dma/sun4i-dma.c, branch v6.7-rc1

dmaengine: sun4i-dma: Convert to platform remove callback returning void

2023-09-28T07:40:55+00:00

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 
Acked-by: Jernej Skrabec 
Link: https://lore.kernel.org/r/20230919133207.1400430-46-u.kleine-koenig@pengutronix.de
Signed-off-by: Vinod Koul

dmaengine: drivers: Use devm_platform_ioremap_resource()

2023-01-18T16:46:47+00:00

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 
Acked-by: Jernej Skrabec 
Acked-by: Peter Ujfalusi 
Link: https://lore.kernel.org/r/20221110152528.7821-1-tudor.ambarus@microchip.com
Signed-off-by: Vinod Koul

dmaengine: sun4i: Set the maximum segment size

2022-07-05T13:04:26+00:00

The sun4i DMA engine supports transfer sizes up to 128k for normal DMA
and 16M for dedicated DMA, as documented in the A10 and A20 manuals.

Since this is larger than the default segment size limit (64k), exposing
the real limit reduces the number of transfers needed for a transaction.
However, because the device can only report one segment size limit, we
have to expose the smaller limit from normal DMA.

One complication is that the driver combines pairs of periodic transfers
to reduce programming overhead. This only works when the period size is
at most half of the maximum transfer size. With the default 64k segment
size limit, this was always the case, but for normal DMA it is no longer
guaranteed. Skip the optimization if the period is too long; even
without it, the overhead is less than before.

Signed-off-by: Samuel Holland 
Link: https://lore.kernel.org/r/20220621031350.36187-1-samuel@sholland.org
Signed-off-by: Vinod Koul

dmaengine: sun4i: Use list_move_tail instead of list_del/list_add_tail

2021-06-07T11:36:38+00:00

Using list_move_tail() instead of list_del() + list_add_tail().

Reported-by: Hulk Robot 
Signed-off-by: Zou Wei 
Acked-by: Maxime Ripard 
Link: https://lore.kernel.org/r/1623036035-30614-1-git-send-email-zou_wei@huawei.com
Signed-off-by: Vinod Koul

dmaengine: sun4i-dma: Demote obvious misuse of kerneldoc to standard comment blocks

2020-07-15T12:20:47+00:00

No attempt has been made to document any of the demoted functions here.

Fixes the following W=1 kernel build warning(s):

 drivers/dma/sun4i-dma.c:321: warning: Function parameter or member 'priv' not described in '__execute_vchan_pending'
 drivers/dma/sun4i-dma.c:321: warning: Function parameter or member 'vchan' not described in '__execute_vchan_pending'
 drivers/dma/sun4i-dma.c:435: warning: Function parameter or member 'chan' not described in 'generate_ndma_promise'
 drivers/dma/sun4i-dma.c:435: warning: Function parameter or member 'src' not described in 'generate_ndma_promise'
 drivers/dma/sun4i-dma.c:435: warning: Function parameter or member 'dest' not described in 'generate_ndma_promise'
 drivers/dma/sun4i-dma.c:435: warning: Function parameter or member 'len' not described in 'generate_ndma_promise'
 drivers/dma/sun4i-dma.c:435: warning: Function parameter or member 'sconfig' not described in 'generate_ndma_promise'
 drivers/dma/sun4i-dma.c:435: warning: Function parameter or member 'direction' not described in 'generate_ndma_promise'
 drivers/dma/sun4i-dma.c:501: warning: Function parameter or member 'chan' not described in 'generate_ddma_promise'
 drivers/dma/sun4i-dma.c:501: warning: Function parameter or member 'src' not described in 'generate_ddma_promise'
 drivers/dma/sun4i-dma.c:501: warning: Function parameter or member 'dest' not described in 'generate_ddma_promise'
 drivers/dma/sun4i-dma.c:501: warning: Function parameter or member 'len' not described in 'generate_ddma_promise'
 drivers/dma/sun4i-dma.c:501: warning: Function parameter or member 'sconfig' not described in 'generate_ddma_promise'
 drivers/dma/sun4i-dma.c:577: warning: Function parameter or member 'contract' not described in 'get_next_cyclic_promise'
 drivers/dma/sun4i-dma.c:596: warning: Function parameter or member 'vd' not described in 'sun4i_dma_free_contract'

Signed-off-by: Lee Jones 
Acked-by: Chen-Yu Tsai 
Cc: Maxime Ripard 
Cc: Chen-Yu Tsai 
Cc: "Emilio López" 
Link: https://lore.kernel.org/r/20200714111546.1755231-10-lee.jones@linaro.org
Signed-off-by: Vinod Koul

dmaengine: sun4i: set the linear_mode properly

2020-02-17T06:51:08+00:00

Commit 6ebb827f7aad ("dmaengine: sun4i: use 'linear_mode' in
sun4i_dma_prep_dma_cyclic") updated the condition but introduced a semi
colon this making this statement have no effect, so add the bitwise OR
to fix it"

Fixes: 6ebb827f7aad ("dmaengine: sun4i: use 'linear_mode' in sun4i_dma_prep_dma_cyclic")
Reported-by: Stephen Rothwell 
Link: https://lore.kernel.org/r/20200214044609.2215861-1-vkoul@kernel.org
Signed-off-by: Vinod Koul

dmaengine: sun4i: use 'linear_mode' in sun4i_dma_prep_dma_cyclic

2020-02-13T15:08:53+00:00

drivers/dma/sun4i-dma.c: In function sun4i_dma_prep_dma_cyclic:
drivers/dma/sun4i-dma.c:672:24: warning:
 variable linear_mode set but not used [-Wunused-but-set-variable]

commit ffc079a4accc ("dmaengine: sun4i: Add support for cyclic requests with dedicated DMA")
involved this, explicitly using the value makes the code more readable.

Reported-by: Hulk Robot 
Signed-off-by: YueHaibing 
Link: https://lore.kernel.org/r/20200207024445.44600-1-yuehaibing@huawei.com
Signed-off-by: Vinod Koul

dmaengine: sun4i: Add support for cyclic requests with dedicated DMA

2020-01-21T08:34:29+00:00

Currently the cyclic transfers can be used only with normal DMAs. They
can be used by pcm_dmaengine module, which is required for implementing
sound with sun4i-hdmi encoder. This is so because the controller can
accept audio only from a dedicated DMA.

This patch enables them, following the existing style for the
scatter/gather type transfers.

Signed-off-by: Stefan Mavrodiev 
Acked-by: Maxime Ripard 
Link: https://lore.kernel.org/r/20200110141140.28527-2-stefan@olimex.com
Signed-off-by: Vinod Koul

dmaengine: virt-dma: Add missing locking

2019-12-26T04:34:18+00:00

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 13bb26ae8850 ("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_list() unlocked

This needs to be done atomically, so in this patch the locking is added
and all drivers are fixed.

Signed-off-by: Sascha Hauer 
Reviewed-by: Peter Ujfalusi 
Tested-by: Peter Ujfalusi 
Reviewed-by: Green Wan 
Tested-by: Green Wan 
Link: https://lore.kernel.org/r/20191216105328.15198-3-s.hauer@pengutronix.de
Signed-off-by: Vinod Koul

dmaengine: Remove dev_err() usage after platform_get_irq()

2019-07-31T15:20:53+00:00

We don't need dev_err() messages when platform_get_irq() fails now that
platform_get_irq() prints an error message itself when something goes
wrong. Let's remove these prints with a simple semantic patch.

// 
@@
expression ret;
struct platform_device *E;
@@

ret =
(
platform_get_irq(E, ...)
|
platform_get_irq_byname(E, ...)
);

if ( \( ret < 0 \| ret <= 0 \) )
{
(
-if (ret != -EPROBE_DEFER)
-{ ...
-dev_err(...);
-... }
|
...
-dev_err(...);
)
...
}
// 

While we're here, remove braces on if statements that only have one
statement (manually).

Cc: Vinod Koul 
Cc: Dan Williams 
Cc: dmaengine@vger.kernel.org
Cc: Greg Kroah-Hartman 
Signed-off-by: Stephen Boyd 
Link: https://lore.kernel.org/r/20190730181557.90391-11-swboyd@chromium.org
Signed-off-by: Vinod Koul