linux/drivers/dma/dmaengine.c, branch v4.7

Merge branch 'topic/core' into for-linus

2016-05-17T04:43:40Z

dmaengine: core: Use IS_ENABLED() instead of checking for built-in or module

2016-05-14T08:02:03Z

The IS_ENABLED() macro checks if a Kconfig symbol has been enabled either built-in or as a module, use that macro instead of open coding the same. Signed-off-by: Javier Martinez Canillas Signed-off-by: Vinod Koul

dmaengine: slave means at least one of DMA_SLAVE, DMA_CYCLIC

2016-05-12T05:44:56Z

When check for capabilities recognize slave support by either DMA_SLAVE or DMA_CYCLIC bit set. If we don't do that the user can't get a normally worked DMA support for engines that doesn't have one of the mentioned bits set. Signed-off-by: Andy Shevchenko Signed-off-by: Vinod Koul

dmaengine: core: Revert back to pr_debug in __dma_request_channel()

2016-04-13T15:39:21Z

Commit ef859312c3a1 ("dmaengine: core: Use dev_ functions for debug and error prints") wasn't quite right in __dma_request_channel() by claiming that all pr_ prints have valid DMA channel pointer. Obviously it is not true as __dma_request_channel() is looking for a channel and returns NULL if it does not find it. Prevent this potential NULL pointer dereference by reverting back to pr_debug(). Signed-off-by: Jarkko Nikula Reported-by: Dan Carpenter Signed-off-by: Vinod Koul

dmaengine: add DMA_CYCLIC to dma_get_slave_caps

2016-04-05T22:31:33Z

dma_get_slave_caps() API only checked for slave capability where we use slave capabilities for cyclic dma operations as well, so we should add the cyclic case here too. Signed-off-by: Vinod Koul

dmaengine: core: Use dev_ functions for debug and error prints

2016-04-04T13:19:06Z

According to dmaengine kerneldoc the struct dma_chan has always a non-NULL pointer to DMA device and a test in dma_async_device_register() validates that DMA device must also point to struct device. All pr_ prints except one in dma_channel_table_init() have valid DMA channel or DMA device pointer available which allow convert them to use dev_ functions and thus able to show the associated DMA device. Signed-off-by: Jarkko Nikula Signed-off-by: Vinod Koul

dmaengine: core: expose max burst capability to clients

2016-02-09T03:31:41Z

This patch add max_burst to dma_get_slave_caps for clients to get the burst capability of slave dma controller. Signed-off-by: Shawn Lin Signed-off-by: Caesar Wang Signed-off-by: Vinod Koul

Merge branch 'topic/async' into for-linus

2016-01-06T09:47:47Z

Merge branch 'topic/univ_api' into for-linus

2016-01-06T09:47:32Z

dmaengine: core: Introduce new, universal API to request a channel

2015-12-18T05:47:26Z

The two API function can cover most, if not all current APIs used to request a channel. With minimal effort dmaengine drivers, platforms and dmaengine user drivers can be converted to use the two function. struct dma_chan *dma_request_chan_by_mask(const dma_cap_mask_t *mask); To request any channel matching with the requested capabilities, can be used to request channel for memcpy, memset, xor, etc where no hardware synchronization is needed. struct dma_chan *dma_request_chan(struct device *dev, const char *name); To request a slave channel. The dma_request_chan() will try to find the channel via DT, ACPI or in case if the kernel booted in non DT/ACPI mode it will use a filter lookup table and retrieves the needed information from the dma_slave_map provided by the DMA drivers. This legacy mode needs changes in platform code, in dmaengine drivers and finally the dmaengine user drivers can be converted: For each dmaengine driver an array of DMA device, slave and the parameter for the filter function needs to be added: static const struct dma_slave_map da830_edma_map[] = { { "davinci-mcasp.0", "rx", EDMA_FILTER_PARAM(0, 0) }, { "davinci-mcasp.0", "tx", EDMA_FILTER_PARAM(0, 1) }, { "davinci-mcasp.1", "rx", EDMA_FILTER_PARAM(0, 2) }, { "davinci-mcasp.1", "tx", EDMA_FILTER_PARAM(0, 3) }, { "davinci-mcasp.2", "rx", EDMA_FILTER_PARAM(0, 4) }, { "davinci-mcasp.2", "tx", EDMA_FILTER_PARAM(0, 5) }, { "spi_davinci.0", "rx", EDMA_FILTER_PARAM(0, 14) }, { "spi_davinci.0", "tx", EDMA_FILTER_PARAM(0, 15) }, { "da830-mmc.0", "rx", EDMA_FILTER_PARAM(0, 16) }, { "da830-mmc.0", "tx", EDMA_FILTER_PARAM(0, 17) }, { "spi_davinci.1", "rx", EDMA_FILTER_PARAM(0, 18) }, { "spi_davinci.1", "tx", EDMA_FILTER_PARAM(0, 19) }, }; This information is going to be needed by the dmaengine driver, so modification to the platform_data is needed, and the driver map should be added to the pdata of the DMA driver: da8xx_edma0_pdata.slave_map = da830_edma_map; da8xx_edma0_pdata.slavecnt = ARRAY_SIZE(da830_edma_map); The DMA driver then needs to configure the needed device -> filter_fn mapping before it registers with dma_async_device_register() : ecc->dma_slave.filter_map.map = info->slave_map; ecc->dma_slave.filter_map.mapcnt = info->slavecnt; ecc->dma_slave.filter_map.fn = edma_filter_fn; When neither DT or ACPI lookup is available the dma_request_chan() will try to match the requester's device name with the filter_map's list of device names, when a match found it will use the information from the dma_slave_map to get the channel with the dma_get_channel() internal function. Signed-off-by: Peter Ujfalusi Reviewed-by: Arnd Bergmann Signed-off-by: Vinod Koul