This fix an Oops happening on all platforms using the old dt bindings
(all platforms but da8xx).
This update cppi41_dma_probe() to use the index variable which is
required to keep compatibility between old and new dt bindings.
Fixes: 8e3ba95f41 ("dmaengine: cppi41: use managed functions devm_*()")
Reported-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Alexandre Bailon <abailon@baylibre.com>
Signed-off-by: Vinod Koul <vinod.koul@intel.com>
Commit 8e3ba95f41 ("dmaengine: cppi41: use managed functions devm_*()")
moved the code to devm_* but erranously changed a varible name, so fix it.
drivers/dma/cppi41.c:1052:5: error: 'struct cppi41_dd' has no member named 'qmrg_mem'
cdd->qmrg_mem = devm_ioremap_resource(dev, mem);
^
drivers/dma/cppi41.c:1053:16: error: 'struct cppi41_dd' has no member named 'qmrg_mem'
if (IS_ERR(cdd->qmrg_mem))
^
drivers/dma/cppi41.c:1054:21: error: 'struct cppi41_dd' has no member named 'qmrg_mem'
return PTR_ERR(cdd->qmrg_mem);
^
Fixes: 8e3ba95f41 ("dmaengine: cppi41: use managed functions devm_*()")
Reported-by: kbuild test robot <fengguang.wu@intel.com>
Signed-off-by: Vinod Koul <vinod.koul@intel.com>
This makes the error handling much more simpler than open-coding
everything and in addition makes the probe function smaller an tidier.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Vinod Koul <vinod.koul@intel.com>
It makes sense to set residue when channel is in progress. Otherwise it
should be 0 since transfer is completed. Meanwhile this patch doesn't
prevent to set residue value anyway.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Vinod Koul <vinod.koul@intel.com>
During the teardown of a RX channel, because there is only one
completion queue available for RX channel, descriptor of another
channel may be popped which will cause 2 warnings:
- the first one because we popped a wrong descriptor
(neither the channel's descriptor, nor the teardown descriptor).
- the second one happen during the teardown of another channel,
because we can't find the channel descriptor
(that is, the one that caused the first warning).
To avoid that, use one free queue instead of a transmit completion queue.
Note that fix doesn't fix all the teardown warnings:
I still get some when I run some corner case.
Signed-off-by: Alexandre Bailon <abailon@baylibre.com>
Signed-off-by: Vinod Koul <vinod.koul@intel.com>
The DA8xx has a CPPI 4.1 DMA controller.
This is add the glue layer required to make it work on DA8xx.
Signed-off-by: Alexandre Bailon <abailon@baylibre.com>
Signed-off-by: Vinod Koul <vinod.koul@intel.com>
All the platform code to manage IRQ has been moved to MUSB,
and now the interrupt handler is completely generic.
Remove the isr callback that is not useful anymore.
Signed-off-by: Alexandre Bailon <abailon@baylibre.com>
Signed-off-by: Vinod Koul <vinod.koul@intel.com>
Despite the driver is already using DT to get the number of channels,
init_sched() is using an hardcoded value to get it.
Use DT to get the number of channels.
Signed-off-by: Alexandre Bailon <abailon@baylibre.com>
Signed-off-by: Vinod Koul <vinod.koul@intel.com>
Some constants are defined and use by the driver whereas they are
specifics to AM335x.
Add new variables to the glue layer, initialize them with the constants,
and use them in the driver.
Signed-off-by: Alexandre Bailon <abailon@baylibre.com>
Signed-off-by: Vinod Koul <vinod.koul@intel.com>
Currently, only the AM335x is supported by the driver.
Though the driver has a glue layer to support different platforms,
some platform variable names are not prefixed with the platform name.
To facilitate the addition of a new platform,
rename some variables owned by the AM335x glue.
Signed-off-by: Alexandre Bailon <abailon@baylibre.com>
Signed-off-by: Vinod Koul <vinod.koul@intel.com>
In order to make CPPI 4.1 DMA driver more generic, accesses to USBSS
have been removed. So it is not required anymore to map the "glue"
register's.
Remove usbss_mem.
Signed-off-by: Alexandre Bailon <abailon@baylibre.com>
Signed-off-by: Vinod Koul <vinod.koul@intel.com>
Despite the CPPI 4.1 is a generic DMA, it is tied to USB.
On the DSPS, CPPI 4.1 interrupt's registers are in USBSS (the MUSB glue).
Currently, to enable / disable and clear interrupts, the CPPI 4.1 driver
maps and accesses to USBSS's register, which making CPPI 4.1 driver not
really generic.
Move the interrupt management to DSPS driver.
Signed-off-by: Alexandre Bailon <abailon@baylibre.com>
Acked-by: Vinod Koul <vinod.koul@intel.com>
Signed-off-by: Bin Liu <b-liu@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
With patches "dmaengine: cppi41: Fix runtime PM timeouts with USB mass
storage", and "dmaengine: cppi41: Fix oops in cppi41_runtime_resume",
the pm_runtime_get/put() in cppi41_irq() is no longer needed. We now
guarantee that cppi41 is enabled when dma is in use.
We can still get pointless error -115 when musb is configured as a
usb peripheral. That's because we should now check for the state of
is_suspended instead.
Let's just remove the now useless code and replace it with a WARN().
Signed-off-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Vinod Koul <vinod.koul@intel.com>
Commit fdea2d09b9 ("dmaengine: cppi41: Add basic PM runtime support")
together with recent MUSB changes allowed USB and DMA on BeagleBone to idle
when no cable is connected. But looks like few corner case issues still
remain.
Looks like just by re-plugging USB cable about ten or so times on BeagleBone
when configured in USB peripheral mode we can get warnings and eventually
trigger an oops in cppi41 DMA:
WARNING: CPU: 0 PID: 14 at drivers/dma/cppi41.c:1154 cppi41_runtime_suspend+
x28/0x38 [cppi41]
...
WARNING: CPU: 0 PID: 14 at drivers/dma/cppi41.c:452
push_desc_queue+0x94/0x9c [cppi41]
...
Unable to handle kernel NULL pointer dereference at virtual
address 00000104
pgd = c0004000
[00000104] *pgd=00000000
Internal error: Oops: 805 [#1] SMP ARM
...
[<bf0d92cc>] (cppi41_runtime_resume [cppi41]) from [<c0589838>]
(__rpm_callback+0xc0/0x214)
[<c0589838>] (__rpm_callback) from [<c05899ac>] (rpm_callback+0x20/0x80)
[<c05899ac>] (rpm_callback) from [<c0589460>] (rpm_resume+0x504/0x78c)
[<c0589460>] (rpm_resume) from [<c058a1a0>] (pm_runtime_work+0x60/0xa8)
[<c058a1a0>] (pm_runtime_work) from [<c0156120>] (process_one_work+0x2b4/0x808)
This is because of a race with runtime PM and cppi41_dma_issue_pending()
as reported by Alexandre Bailon <abailon@baylibre.com> in earlier
set of patches. Based on mailing list discussions we however came to the
conclusion that a different fix from Alexandre's fix is needed in order
to guarantee that DMA is really active when we try to use it.
To fix the issue, we need to add a driver specific flag as we otherwise
can have -EINPROGRESS state set by runtime PM and can't rely on
pm_runtime_active() to tell us when we can use the DMA.
And we need to make sure the DMA transfers get triggered in the queued
order. So let's always queue the transfers, then flush the queue
from both cppi41_dma_issue_pending() and cppi41_runtime_resume()
as suggested by Grygorii Strashko <grygorii.strashko@ti.com> in an
earlier example patch.
For reference, this is also documented in Documentation/power/runtime_pm.txt
in the example at the end of the file as pointed out by Grygorii Strashko
<grygorii.strashko@ti.com>.
Based on earlier patches from Alexandre Bailon <abailon@baylibre.com>
and Grygorii Strashko <grygorii.strashko@ti.com> modified based on
testing and what was discussed on the mailing lists.
Fixes: fdea2d09b9 ("dmaengine: cppi41: Add basic PM runtime support")
Cc: Andy Shevchenko <andy.shevchenko@gmail.com>
Cc: Bin Liu <b-liu@ti.com>
Cc: Grygorii Strashko <grygorii.strashko@ti.com>
Cc: Kevin Hilman <khilman@baylibre.com>
Cc: Patrick Titiano <ptitiano@baylibre.com>
Cc: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
Reported-by: Alexandre Bailon <abailon@baylibre.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
Tested-by: Bin Liu <b-liu@ti.com>
Signed-off-by: Vinod Koul <vinod.koul@intel.com>
Commit fdea2d09b9 ("dmaengine: cppi41: Add basic PM runtime support")
added runtime PM support for cppi41, but had corner case issues. Some of
the issues were fixed with commit 098de42ad6 ("dmaengine: cppi41: Fix
unpaired pm runtime when only a USB hub is connected"). That fix however
caused a new regression where we can get error -115 messages with USB on
BeagleBone when connecting a USB mass storage device to a hub.
This is because when connecting a USB mass storage device to a hub, the
initial DMA transfers can take over 200ms to complete and cppi41
autosuspend delay times out.
To fix the issue, we want to implement refcounting for chan_busy array
that contains the active dma transfers. Increasing the autosuspend delay
won't help as that the delay could be potentially seconds, and it's best
to let the USB subsystem to deal with the timeouts on errors.
The earlier attempt for runtime PM was buggy as the pm_runtime_get/put()
calls could get unpaired easily as they did not follow the state of
the chan_busy array as described in commit 098de42ad6 ("dmaengine:
cppi41: Fix unpaired pm runtime when only a USB hub is connected".
Let's fix the issue by adding pm_runtime_get() to where a new transfer
is added to the chan_busy array, and calls to pm_runtime_put() where
chan_busy array entry is cleared. This prevents any autosuspend timeouts
from happening while dma transfers are active.
Fixes: 098de42ad6 ("dmaengine: cppi41: Fix unpaired pm runtime when
only a USB hub is connected")
Fixes: fdea2d09b9 ("dmaengine: cppi41: Add basic PM runtime support")
Cc: Andy Shevchenko <andy.shevchenko@gmail.com>
Cc: Bin Liu <b-liu@ti.com>
Cc: Grygorii Strashko <grygorii.strashko@ti.com>
Cc: Kevin Hilman <khilman@baylibre.com>
Cc: Patrick Titiano <ptitiano@baylibre.com>
Cc: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
Tested-by: Bin Liu <b-liu@ti.com>
Signed-off-by: Vinod Koul <vinod.koul@intel.com>
Fix use of u32 instead of int for checking for negative errors values
as pointed out by Dan Carpenter <dan.carpenter@oracle.com>.
And while testing the PM runtime error path by randomly returning
failed values in runtime resume, I noticed two more places that need
fixing:
- If pm_runtime_get_sync() fails in probe, we still need to do
pm_runtime_put_sync() to keep the use count happy. We could call
pm_runtime_put_noidle() on the error path, but we're just going
to call pm_runtime_disable() after that so pm_runtime_put_sync()
will do what we want
- We should print an error if pm_runtime_get_sync() fails in
cppi41_dma_alloc_chan_resources() so we know where it happens
Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
Fixes: 740b4be3f7 ("dmaengine: cpp41: Fix handling of error path")
Signed-off-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Vinod Koul <vinod.koul@intel.com>
If we return early on pm_runtime_get() error, we need to also call
pm_runtime_put_noidle() as pointed out in a musb related thread
by Johan Hovold <johan@kernel.org>. This is to keep the PM runtime
use counts happy.
Fixes: fdea2d09b9 ("dmaengine: cppi41: Add basic PM runtime support")
Cc: Johan Hovold <johan@kernel.org>
Signed-off-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Vinod Koul <vinod.koul@intel.com>
On am335x with musb host we can end up with unpaired pm runtime calls
if a hub with no devices is connected and disconnected.
This is because of the conditional pm runtime calls which are always
a bad idea. Let's fix the issue by making them unconditional and
paired in each function.
Fixes: fdea2d09b9 ("dmaengine: cppi41: Add basic PM runtime support")
Signed-off-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Vinod Koul <vinod.koul@intel.com>
If musb controller is configured with USB peripherals and we have
enumerated with a USB host, we can get warnings on removal of the
modules:
WARNING: CPU: 0 PID: 1269 at drivers/dma/cppi41.c:391
cppi41_dma_free_chan_resources
Fix the issue by adding the missing pm_runtime_get to
cppi41_dma_free_chan_resources to make sure the pending work
list is cleared on removal.
Fixes: fdea2d09b9 ("dmaengine: cppi41: Add basic PM runtime support")
Signed-off-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Vinod Koul <vinod.koul@intel.com>
We can occasionally get -EINPROGRESS for pm_runtime_get. In that case
we can just continue as we're queueing transfers anyways when
pm_runtime_active is not set.
Fixes: fdea2d09b9 ("dmaengine: cppi41: Add basic PM runtime support")
Signed-off-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Vinod Koul <vinod.koul@intel.com>
When CONFIG_PM_SLEEP is disabled, we get a build error in
the cppi41 dmaengine driver, since the runtime-pm functions
are hidden within the wrong #ifdef:
drivers/dma/cppi41.c:1158:21: error: 'cppi41_runtime_suspend' undeclared here (not in a function)
This removes the #ifdef and instead uses __maybe_unused
annotations that cannot have this problem.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Fixes: fdea2d09b9 ("dmaengine: cppi41: Add basic PM runtime support")
Signed-off-by: Vinod Koul <vinod.koul@intel.com>
Let's keep the device enabled between cppi41_dma_issue_pending()
and dmaengine_desc_get_callback_invoke() and rely on the PM runtime
autoidle timeout elsewhere.
As the PM runtime is for whole device, not for each channel,
we need to queue pending transfers if the device is PM runtime
suspended. Then we start the pending transfers in PM runtime
resume.
Signed-off-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Vinod Koul <vinod.koul@intel.com>
Let's just move code from cppi41_dma_issue_pending() to
push_desc_queue() as that's the only call to push_desc_queue().
We want to do this for PM runtime as we need to call push_desc_queue()
also for pending queued transfers from PM runtime resume.
No functional changes, just moves code around.
Signed-off-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Vinod Koul <vinod.koul@intel.com>
This is in preperation of moving to a callback that provides results to the
callback for the transaction. The conversion will maintain current behavior
and the driver must convert to new callback mechanism at a later time in
order to receive results.
Signed-off-by: Dave Jiang <dave.jiang@intel.com>
Reviewed-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Vinod Koul <vinod.koul@intel.com>
