[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.053 / U:2.904 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site