dma_request_slave_channel() simply returns NULL whenever DMA channel
lookup fails. Lookup could fail for two distinct reasons:
a) No DMA specification exists for the channel name.
This includes situations where no DMA specifications exist at all, or
other general lookup problems.
b) A DMA specification does exist, yet the driver for that channel is not
yet registered.
Case (b) should trigger deferred probe in client drivers. However, since
they have no way to differentiate the two situations, it cannot.
Implement new function dma_request_slave_channel_reason(), which performs
identically to dma_request_slave_channel(), except that it returns an
error-pointer rather than NULL, which allows callers to detect when
deferred probe should occur.
Eventually, all drivers should be converted to this new API, the old API
removed, and the new API renamed to the more desirable name. This patch
doesn't convert the existing API and all drivers in one go, since some
drivers call dma_request_slave_channel() then dma_request_channel() if
that fails. That would require either modifying dma_request_channel() in
the same way, or adding extra error-handling code to all affected
drivers, and there are close to 100 drivers using the other API, rather
than just the 15-20 or so that use dma_request_slave_channel(), which
might be tenable in a single patch.
acpi_dma_request_slave_chan_by_name() doesn't currently implement
deferred probe. It should, but this will be addressed later.
Acked-by: Dan Williams <dan.j.williams@intel.com>
Signed-off-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Vinod Koul <vinod.koul@intel.com>
Both of_dma_nbcells field of the of_dma_controller and the args_count field of
the dma_spec are initialized by parsing the #dma-cells attribute of their device
tree node. So if the device tree nodes of a DMA controller and the dma_spec
match this means that of_dma_nbcells and args_count will also match. So the
second test in the of_dma_find_controller loop is redundant because given the
first test yields true the second test will also yield true. So we can safely
remove the test whether of_dma_nbcells matches args_count. Since this was the
last user of the of_dma_nbcells field we can remove it altogether.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Acked-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Vinod Koul <vinod.koul@intel.com>
There is no sensible reason why #dma-cells shouldn't be allowed to be 0. It is
completely up to the DMA controller how many additional parameters, besides the
phandle, it needs to identify a channel. E.g. for DMA controller with only one
channel or for DMA controllers which don't have a restriction on which channel
can be used for which peripheral it completely legitimate to not require any
additional parameters.
Also fixes the following warning:
drivers/dma/of-dma.c: In function 'of_dma_controller_register':
drivers/dma/of-dma.c:67:7: warning: 'nbcells' may be used uninitialized in this function
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Acked-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Vinod Koul <vinod.koul@intel.com>
Currently the OF DMA code uses a spin lock to protect the of_dma_list from
concurrent access and a per controller reference count to protect the controller
from being freed while a request operation is in progress. If
of_dma_controller_free() is called for a controller who's reference count is not
zero it will return -EBUSY and not remove the controller. This is fine up until
here, but leaves the question what the caller of of_dma_controller_free() is
supposed to do if the controller couldn't be freed. The only viable solution
for the caller is to spin on of_dma_controller_free() until it returns success.
E.g.
do {
ret = of_dma_controller_free(dev->of_node)
} while (ret != -EBUSY);
This is rather ugly and unnecessary and none of the current users of
of_dma_controller_free() check it's return value anyway. Instead protect the
list by a mutex. The mutex will be held as long as a request operation is in
progress. So if of_dma_controller_free() is called while a request operation is
in progress it will be put to sleep and only wake up once the request operation
has finished.
This means that it is no longer possible to register or unregister OF DMA
controllers from a context where it's not possible to sleep. But I doubt that
we'll ever need this.
Also rename of_dma_get_controller back to of_dma_find_controller.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Acked-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Vinod Koul <vinod.koul@intel.com>
of_dma_request_slave_channel() currently does not drop the reference to the
dma_spec of_node if no DMA controller matching the of_node could be found. This
patch fixes it by always calling of_node_put().
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Acked-by: Arnd Bergmann <arnd@arndb.de>
Reviewed-by: Jon Hunter <jon-hunter@ti.com>
Signed-off-by: Vinod Koul <vinod.koul@intel.com>
list_for_each_entry is able to handle empty lists just fine, there is no need
to make sure that the list is non empty.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Vinod Koul <vinod.koul@intel.com>
In of_dma_controller_register() routine we are calling of_get_property() as an
parameter to be32_to_cpup(). In case the property doesn't exist we will get a
crash.
This patch changes this code to check if we got a valid property first and then
runs be32_to_cpup() on it.
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Vinod Koul <vinod.koul@intel.com>
No DMA of-function alters the name, so this patch changes the name arguments
to be constant. Most drivers will probably request DMA channels using a
constant name.
Signed-off-by: Markus Pargmann <mpa@pengutronix.de>
Signed-off-by: Vinod Koul <vinod.koul@intel.com>
It's possible to have an inconsistency in the list due to unprotected operation
on it. The patch adds a proper locking on the list operation.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Acked-by: Rob Herring <rob.herring@calxeda.com>
Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Vinod Koul <vinod.koul@intel.com>
The memory allocated to ofdma might be a leakage when error occurs.
Signed-off-by: Cong Ding <dinggnu@gmail.com>
Signed-off-by: Vinod Koul <vinod.koul@intel.com>
