Re: [PATCH v2 2/2] Documentation: dmaengine: Add a documentation for the dma controller API
From: Vinod Koul
Date: Wed Oct 08 2014 - 08:52:30 EST
On Tue, Oct 07, 2014 at 06:05:15PM +0300, Laurent Pinchart wrote:
> > >
> > > Beware, it can be confusing when mixing "descriptors" and "hardware
> > > descriptors". The ones used by the DMA controller itself to describe the
> > > chunks of data (hardware descriptors) and the ones that would represent
> > > them in the driver (tx descriptors). However, it's true that both must
> > > be prepared by this set of functions.
> > There's a few "hardware" missing indeed, but we can't really avoid the
> > confusion here, since it does rely also on a dma_async_tx_descriptor.
> How about always specifying whether we refer to a "hardware descriptor" or a
> "transaction descriptor" ?
> > > >> + - You'll also need to set two fields in this structure:
> > > >> + + flags:
> > > >> + TODO: Can it be modified by the driver itself, or
> > > >> + should it be always the flags passed in the arguments
> > > >> +
> > > >> + + tx_submit: A pointer to a function you have to implement,
> > > >> + that is supposed to push the current descriptor
> > > >> + to a pending queue, waiting for issue_pending to
> > > >> + be called.
> > >
> > > The question remains: why wait when all the information is already
> > > prepared and available for the DMA controller to start the job?
> > > Actually, we don't wait in at_hdmac, just to be more efficient, but I
> > > known that we kind of break this "requirement"... But sorry, it is
> > > another discussion which should be lead elsewhere.
> From my recollection of a discussion I've had with Russell King, I believe the
> main reason to separate transaction submission (queueing) issue (start) is to
> let DMA engine drivers issuing several queued requests in one go when hardware
> supports chaining requests only when none of them are running. It's thus just
> an optimization. Russell, could you confirm (or infirm) that ?
There are few reasons
- Allow the dmaengine driver to collect and issue all pending txns in shot
(which is not happening today with drivers)
- Allow clients to prepare the txns ahead of time and send them when ready
> > It's just a guess, but maybe you might not be able to schedule the
> > transfer right away? Think about a very dumb 1-channel (or a more
> > realistic more-DRQ-than-channel) device. You might have all the
> > channels busy doing some other transfers, and it's not really part of
> > the client driver job to address that kind of contention: it just
> > wants to queue some work for a later transfer.
> Laurent Pinchart
> To unsubscribe from this list: send the line "unsubscribe dmaengine" in
> the body of a message to majordomo@xxxxxxxxxxxxxxx
> More majordomo info at http://vger.kernel.org/majordomo-info.html
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/