> > >> The only generic interface to execute asynchronously in the BH context is > > >> tasklet; however, it's marked deprecated and has some design flaws. To > > >> replace tasklets, BH workqueue support was recently added. A BH workqueue > > >> behaves similarly to regular workqueues except that the queued work items > > >> are executed in the BH context. > > > > > > Thanks for conversion, am happy with BH alternative as it helps in > > > dmaengine where we need shortest possible time between tasklet and > > > interrupt handling to maximize dma performance > > > > I still feel that we want something different for dmaengine, > > at least in the long run. As we have discussed in the past, > > the tasklet context in these drivers is what the callbacks > > from the dma client device is run in, and a lot of these probably > > want something other than tasklet context, e.g. just call > > complete() on a client-provided completion structure. > > > > Instead of open-coding the use of the system_bh_wq in each > > dmaengine, how about we start with a custom WQ_BH > > specifically for the dmaengine subsystem and wrap them > > inside of another interface. > > > > Since almost every driver associates the tasklet with the > > dma_chan, we could go one step further and add the > > work_queue structure directly into struct dma_chan, > > with the wrapper operating on the dma_chan rather than > > the work_queue. > > I think that is very great idea. having this wrapped in dma_chan would > be very good way as well > > Am not sure if Allen is up for it :-) Thanks Arnd, I know we did speak about this at LPC. I did start working on using completion. I dropped it as I thought it would be easier to move to workqueues. Vinod, I would like to give this a shot and put out a RFC, I would really appreciate review and feedback. Thanks, Allen > > -- > ~Vinod >
