lkml.org 
[lkml]   [2010]   [Sep]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
DateWed, 22 Sep 2010 21:59:13 -0700
SubjectRe: [PATCH 11/12] DMAENGINE: let PL08X memcpy TXDs wait
FromDan Williams <>
On Tue, Aug 31, 2010 at 5:12 AM, Linus Walleij
<linus.walleij@stericsson.com> wrote:
> This change makes the memcpy transfers wait for a physical channel
> to become available if no free channel is available when the job
> is submitted. When the first physical channel fires its tasklet,
> it will spin over the memcpy channels to see if one of these is
> waiting.
>
> This is necessary to get the memcpy semantics right: the generic
> memcpy API assume transfers never fail, and with our oversubscribed
> physical channels this becomes a problem: sometimes submit would
> fail. This fixes it by letting the memcpy channels pull a free
> channel ASAP.
>
> The slave channels shall however *fail* if no channel is available
> since the device will then either fall back to some PIO mode or
> retry.
>

This patch does not sit right with me. It seems a bit arbitrary that
memcpy operations will be queued while slave operations are failed.
Is there anyway to know at prep time whether a subsequent submit will
fail? Are there any cases where a slave might want its operation
queued?

The prep routine is meant to guarantee that all the resources for a
transaction have been acquired. The only reason ->tx_submit() has a
return value is to support the net_dma usage model that uses opaque
cookies for tracking transactions.

If we make tx_submit() fallable we should go back and ensure that all
usages are prepared to handle failure.

--
Dan

sidenote: this driver needs to be converted to a dma descriptor pool
(allocated at device_alloc_chan_resources time), or at a minimum use
GFP_NOWAIT in device_prep_dma_memcpy because that routine may be
called from atomic contexts.


\
 
 \ /
  Last update: 2010-09-23 07:01    [from the cache]
©2003-2010