[lkml]   [2008]   [Mar]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH] pasemi_dma: Driver for PA Semi PWRficient on-chip DMAengine
On Thu, Mar 13, 2008 at 4:14 PM, Olof Johansson <> 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

> > > 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.
> > >
> >
> > 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.


 \ /
  Last update: 2008-03-14 01:09    [W:0.040 / U:7.444 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site