On 11/12/2015 08:26 PM, Andy Shevchenko wrote:

On Fri, Nov 13, 2015 at 3:11 AM, Peter Hurley [off-list ref] wrote:

quoted

On 11/12/2015 07:41 PM, Andy Shevchenko wrote:

quoted

On Thu, Nov 12, 2015 at 10:22 PM, Peter Hurley [off-list ref] wrote:

quoted

On 11/12/2015 02:57 PM, One Thousand Gnomes wrote:

quoted

An illustrative (kernel-space) example is the mess that is dmaengine_pause().
Some DMA implementations provide the means to stop and restart DMA without
losing data and some DMA implementations do not. Unfortunately, some
advertise they support dmaengine_pause() but only for lossy uses like audio.
Because the api hides this, the query interface for pause support is
useless.

The DMA pause() call means only pause with possibility to resume.
There is a resume() call as well. Any driver which treats pause() as a
complete stop is buggy driver and should be fixed.

How about pause _without_ the possibility to resume?

https://groups.google.com/d/msg/linux.kernel/Abe0hfGcgsw/H0se55wC558J

Briefly what I got from the thread that Russell shows similar view on
the API, so that's why he was objecting to add pause/resume calls for
a specific hardware.

Not quite.

That dmaengine driver (omap-dma) advertises that it supports pause() via
dma_get_slave_caps(). And if you call it with a cyclic channel it will pause.
However, if you call dmaengine_pause() with a slave channel it returns an error
*because the hardware can't actually meet the criteria for dmaengine_pause()*
which is pause()/resume() without data loss.

IOW, there is no method of determining a priori if dmaengine_pause() will
categorically fail for a given transfer type.

Regards,
Peter Hurley