>> >> Thank you Linus, Arnd, Vincent and David for the feedback. >> >> This is a lot more than a just conversion of API’s. I am in the process >> Of replacing tasklets with threaded irq’s and hopefully that should be >> A better solution than using workqueues. > > I don't think that is much better for the case of the DMA engine > callbacks than the work queue, the problem I pointed out here > is scheduling into task context, which may be too expensive > in some cases, but whether it is or not depends on the slave > driver, not the dmaengine driver. Fair point. Deferring all callbacks to task context is not the ideal Way forward. I will work on the approach you shared, >1. add helper functions to call the callback functions from a >tasklet locally defined in drivers/dma/dmaengine.c to allow >deferring it from hardirq context >2. Change all tasklets that are not part of the callback >mechanism to work queue functions, I only see >xilinx_dpdma_chan_err_task in the patch, but there >may be more >3. change all drivers to move their custom tasklets back into >hardirq context and instead call the new helper for deferring >the callback. >4. Extend the dmaengine callback API to let slave drivers >pick hardirq, tasklet or task context for the callback. >task context can mean either a workqueue, or a threaded >IRQ here, with the default remaining the tasklet version. >5. Change slave drivers to pick either hardirq or task context >depending on their requirements >6. Remove the tasklet version. Thanks. > > Even if all the slave drivers are better off using task context > (threaded irq or workqueue), you need to look at the slave > drivers first before you can convert the dmaengine drivers. >
