kernel/linux.git/include/linux/of_dma.h, branch v6.6.131

of: Use SPDX license tag for DT files

2018-01-08T14:22:45+00:00

Convert remaining DT files to use SPDX-License-Identifier tags. Cc: Benjamin Herrenschmidt Cc: Guennadi Liakhovetski Cc: Paul Mackerras Cc: Pantelis Antoniou Reviewed-by: Frank Rowand Reviewed-by: Philippe Ombredanne Signed-off-by: Rob Herring

dmaengine: of_dma: Correct return code for of_dma_request_slave_channel in case !CONFIG_OF

2015-11-16T03:33:21+00:00

of_dma_request_slave_channel should return either pointer for valid dma_chan or ERR_PTR() error code, NULL is not expected to be returned. Signed-off-by: Peter Ujfalusi Acked-by: Arnd Bergmann Signed-off-by: Vinod Koul

dmaengine: OF DMAEngine API based on CONFIG_DMA_OF instead of CONFIG_OF

2015-10-01T02:09:55+00:00

5fa422c ("dmaengine: move drivers/of/dma.c -> drivers/dma/of-dma.c") moved OF base DMAEngine code to of-dma.c, then it based on CONFIG_DMA_OF. But, OF base DMAEngine API on of_dma.h still based on CONFIG_OF now. So, current kernel can't find OF base DMAEngine API if .config has CONFIG_OF, but not have CONFIG_DMA_OF. This patch tidyup it. Signed-off-by: Kuninori Morimoto Signed-off-by: Vinod Koul

dmaengine: of_dma: Support for DMA routers

2015-05-09T11:41:25+00:00

DMA routers are transparent devices used to mux DMA requests from peripherals to DMA controllers. They are used when the SoC integrates more devices with DMA requests then their controller can handle. DRA7x is one example of such SoC, where the sDMA can hanlde 128 DMA request lines, but in SoC level it has 205 DMA requests. The of_dma_router will be registered as of_dma_controller with special xlate function and additional parameters. The driver for the router is responsible to craft the dma_spec (in the of_dma_route_allocate callback) which can be used to requests a DMA channel from the real DMA controller. This way the router can be transparent for the system while remaining generic enough to be used in different environments. Signed-off-by: Peter Ujfalusi Signed-off-by: Vinod Koul

dmaengine: of: add common xlate function for matching by channel id

2014-07-25T18:51:41+00:00

This patch adds a new common OF dma xlate callback function which will match a channel by it's id. The binding expects one integer argument which it will use to lookup the channel by the id. Unlike of_dma_simple_xlate this function is able to handle a system with multiple DMA controllers. When registering the of dma provider with of_dma_controller_register a pointer to the dma_device struct which is associated with the dt node needs to passed as the data parameter. New function will use this pointer to match only channels which belong to the specified DMA controller. Signed-off-by: Alexander Popov Signed-off-by: Vinod Koul

dma: of: Remove check on always true condition

2013-06-12T02:19:19+00:00

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 Acked-by: Arnd Bergmann Signed-off-by: Vinod Koul

dma:of: Use a mutex to protect the of_dma_list

2013-05-02T16:20:38+00:00

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 Acked-by: Arnd Bergmann Signed-off-by: Vinod Koul

DMA: of: Constant names

2013-04-15T04:22:03+00:00

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 Signed-off-by: Vinod Koul

dmaengine: fix !of_dma compilation warning

2013-01-08T06:05:02+00:00

Reported-by: Stephen Rothwell Reported-by: Fengguang Wu Signed-off-by: Vinod Koul

of: dma: fix protection of DMA controller data stored by DMA helpers

2013-01-08T06:05:01+00:00

In the current implementation of the OF DMA helpers, read-copy-update (RCU) linked lists are being used for storing and accessing the DMA controller data. This part of implementation is based upon V2 of the DMA helpers by Nicolas [1]. During a recent review of RCU, it became apparent that the code is missing the required rcu_read_lock()/unlock() calls as well as synchronisation calls before freeing any memory protected by RCU. Having looked into adding the appropriate RCU calls to protect the DMA data it became apparent that with the current DMA helper implementation, using RCU is not as attractive as it may have been before. The main reasons being that ... 1. We need to protect the DMA data around calls to the xlate function. 2. The of_dma_simple_xlate() function calls the DMA engine function dma_request_channel() which employs a mutex and so could sleep. 3. The RCU read-side critical sections must not sleep and so we cannot hold an RCU read lock around the xlate function. Therefore, instead of using RCU, an alternative for this use-case is to employ a simple spinlock inconjunction with a usage count variable to keep track of how many current users of the DMA data structure there are. With this implementation, the DMA data cannot be freed until all current users of the DMA data are finished. This patch is based upon the DMA helpers fix for potential deadlock [2]. [1] http://article.gmane.org/gmane.linux.ports.arm.omap/73622 [2] http://marc.info/?l=linux-arm-kernel&m=134859982520984&w=2 Signed-off-by: Jon Hunter Signed-off-by: Vinod Koul