Messages in this thread |  | | | Date | Wed, 22 Sep 2010 21:59:13 -0700 | | Subject | Re: [PATCH 11/12] DMAENGINE: let PL08X memcpy TXDs wait | | From | Dan 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.
|  |