On Thu, Aug 16, 2012 at 11:29:12PM +0100, Russell King wrote:

On Thu, Aug 16, 2012 at 05:44:29PM -0400, Matt Porter wrote:

quoted

Add a DMA engine driver for the TI EDMA controller. This driver
is implemented as a wrapper around the existing DaVinci private
DMA implementation. This approach allows for incremental conversion
of each peripheral driver to the DMA engine API. The EDMA driver
supports slave transfers but does not yet support cyclic transfers.

Have you looked at the virt-dma support?  That should allow you to
avoid some common errors, like forgetting that stuff submitted but
not issued should not be started even if the channel is currently
running.

I had previously skimmed it a bit and wrote it off as a helper for
certain types of controllers. On your suggestion, I looked into it
in detail and it does look to be a nice improvement on handling those
types of errors...some of which I noticed were not being handled
properly in my v1 version. I did a quick and dirty conversion of the
EDMA driver to use virt-dma now and it also results in simplified
handling of the descriptors and about a 10% code reduction. I'll do
some clean up on this virt-dma-enabled version and post v2.

One thing to note is that although I'm borrowing a lot from how you
did the omap-dma.c driver, the EDMA implementation of issue_pending()
cannot schedule a tasklet to send the descriptor to the hardware. The
client drivers have to be sure that dma_async_issue_pending() results
in the PaRAM set been written to the h/w before the driver specific
DMA reqs are enabled. Enabling the DMA req before the PaRAM set is
programmed results in an event error condition on this h/w. Ideally
there would be a dma_status state to reflect that a descriptor has
actually been written to the h/w so that client drivers can safely
enable dma reqs where this is a requirement.

Thanks,
Matt