Messages in this thread | | | Date | Thu, 13 Mar 2008 17:06:19 -0700 | From | "Dan Williams" <> | Subject | Re: [PATCH] pasemi_dma: Driver for PA Semi PWRficient on-chip DMAengine |
| |
On Thu, Mar 13, 2008 at 4:14 PM, Olof Johansson <olof@lixom.net> wrote: > > Dummy descriptors that do nothing but cause an interrupt is the intent. > > Well, it'd be slightly more efficient to do add the interrupt attribute > to the last issued descriptor when it's known in advance. If the > underlying driver doesn't support it, adding a separate descriptor would > be a good fallback. >
When it is known in advance the interrupt attribute *is* set, otherwise the descriptor may already be in flight.
> Anyway, this isn't likely to be a performance bottleneck. If it turns > out to be, I'll refactor it and submit patches. >
Would not hurt to have another pair of eyes on this part of the code. A rewrite of the channel switch mechanism is currently pending in async_tx.git#upstream.
[..] > > > Can't do that if it's called both from the polling as well as the IRQ > > > context, it'd need to hold off irqs. I.e. once I add the DMA_INTERRUPT > > > support it will be needed. > > > > > > > ...do it in a tasklet. > > Why? That just adds overhead and latency. >
The original ioat_dma code used nothing heavier than spin_lock_bh. Async_tx now assumes that local_bh_disable prevents races with any channel's cleanup routine. Clients can place the same kind of code in an async_tx callback as they would in a timer callback. The assumption is that code using async_tx can afford its extra overhead, which is true for raid. This is also why you don't see async_memcpy calls in net_dma.
-- Dan
| |