Messages in this thread | | | Subject | Re: [RFC 1/1] drivers/dma/*: replace tasklets with workqueue | From | Allen Pais <> | Date | Wed, 25 May 2022 11:04:11 -0700 |
| |
>> >> 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. >
| |