On Tue, Feb 02, 2010 at 02:02:44PM -0700, Dan Williams wrote: > Ira W. Snyder wrote: > > Fix locking. Use two queues in the driver, one for pending transacions, and > > one for transactions which are actually running on the hardware. Call > > dma_run_dependencies() on descriptor cleanup so that the async_tx API works > > correctly. > > I notice that fsldma diverges from other dma drivers in that the > callback is performed with interrupts disabled. MD/raid5 currently > assumes that interrupts are enabled in its callback routines (see > ops_complete_biofill()'s use of spin_lock_irq()). On top of these > changes can we align fsldma to the other raid offload drivers (mv_xor, > iop-adma, ioatdma) and provide callbacks with irq's enabled? > > I'll proceed with applying these patches as they obviously improve > things, but you will hit the irq problem when performing reads to a > degraded array. >
In the fsldma driver, all callbacks are run from tasklet (softirq) context. That's under local_irq_disable(), right? Hardirq's certainly aren't disabled there. Is a DMAEngine user expected to call the device_is_tx_complete() function until it returns that the DMA has completed? If so, it is pretty easy to switch to a workqueue instead of a tasklet to handle the callbacks. The cost is increased latency until the callbacks are processed. Would you want a driver-wide singlethreaded workqueue? A driver-wide multi-threaded workqueue? A workqueue per-device? A workqueue per-channel? This starts to get excessive, IMO. Ira _______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
