On Fri, Aug 07, 2015 at 08:28:57PM -0400, Peter Hurley wrote:
> Even dma_get_slave_caps() returns _true_ for cmd_pause support; ok, that
> interface is pointless.
How about reporting that as a bug then, because if you look back in the
git history, as you are fully capable of, you will find that the slave
capability stuff went in _after_ omap-dma, and *many* DMA engine drivers
have not been updated. Here, let me do _your_ work for you:
commit cb8cea513c80db1dfe2dce468d2d0772005bb9a1
Author: Maxime Ripard <maxime.ripard@xxxxxxxxxxxxxxxxxx>
Date: Mon Nov 17 14:42:04 2014 +0100
dmaengine: Create a generic dma_slave_caps callback
commit 2dcdf570936168d488acf90be9b04a3d32dafce7
Author: Peter Ujfalusi <peter.ujfalusi@xxxxxx>
Date: Fri Sep 14 15:05:45 2012 +0300
dmaengine: omap: Add support for pause/resume in cyclic dma mode
Oh look, omap-dma pre-dates the creation of dma_slave_caps by over two
years!
However, it's *not* as trivial as you think: the dma_slave_caps() call
has no knowledge whether a channel will be used in cyclic mode or not,
or which direction it will be used. So, it really _can't_ report
whether pause mode is supported or not. So actually, this is something
that can't be fixed trivially, and was a detail missed when the slave
caps was reviewed (I probably missed the review or missed the point.)
So, how about you stop playing the blame game and trying to shovel your
shit onto DMA engine.
--
FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up
according to speedtest.net.
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
