On Wed, Dec 03, 2014 at 01:21:37PM +0530, Jassi Brar wrote:
> because the reasoning above seems incorrect considering the following
> documentation...
>
> Documentation/crypto/async-tx-api.txt says
^^^^^^^^^^^^
async-tx-api is not the DMA slave API.
> " .... Once a driver-specific threshold is met the driver
> automatically issues pending operations. An application can force this
> event by calling async_tx_issue_pending_all(). ...."
^^^^^^^^^^^^^^^^^^^^^^^^^^
DMA slave users do not call this function. This documentation is not
relevant for DMA slave.
> include/linux/dmaengine.h says
> dma_async_tx_descriptor.tx_submit(): set the prepared descriptor(s)
> to be executed by the engine
It doesn't say when.
> so theoretically a driver, not starting transfer until
> issue_pending(), is "broken".
It isn't. DMA slave engine implementations have been needing the
issue_pending() call since their dawn, so it's something that they've
always needed.
> At best the patch@04abf5daf7d makes the driver slightly more
> complicated and the reason behind confusion such as in this thread.
That may be, and yes, it _might_ be worth discussing whether this should
be relaxed or not, but that should be done as a proposal, not trying to
hide it as a bug fix. It isn't.
--
FTTC broadband for 0.8mile line: currently at 9.5Mbps down 400kbps up
according to speedtest.net.
--
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
