Re: [RFC 4/7] ASoC: Add dmaengine PCM helper functions

[Mark Brown <broonie@opensource.wolfsonmicro.com>]

[-- Attachment #1.1: Type: text/plain, Size: 2122 bytes --]

On Wed, Feb 22, 2012 at 02:22:36PM +0000, Russell King - ARM Linux wrote:
> On Wed, Feb 22, 2012 at 01:39:39PM +0000, Mark Brown wrote:

> > Well, Vinod seemed to also think that dmaengine ought to be able to cope
> > with emulating this and I really don't see why it shouldn't be.  It does
> > know the capabilities of the underlying driver and it gets to look at
> > all the calls going into the driver before the driver does.  If ASoC can
> > interpose itself I don't see why dmaengine can't.

> Have you ever looked at the DMA engine drivers?  It's a total mess.

Not in enormous detail, no.

> Even something as basic as the DMA engine driver assigning a cookie to
> the descriptor is implemented in each driver in their own unique way.

> Completion of DMA descriptors is a similar thing - every driver implements
> this in their own unique way.

> The only really common thing in the DMA engine drivers is that they all
> share the same API.  Nothing much more than that is shared.

Plus they're going through a common vtable and accessors which is the
main thing here I expect.

> So, there's no way in hell that I want to see any more stuff pushed down
> into the DMA engine drivers until we have a proper DMA engine library in
> place to stop all this idiotic code duplication throughout every driver.
> Especially if it means everyone will be implementing their own cyclic
> emulation in their individual drivers.

I've not seen any suggestion from anyone that that's a good idea.

> So, there's a lot more here that DMA engine stuff needs to get fixed than
> just a simple "layer on top".

Well, if we can't do it with a layer in the dmaengine code then I don't
see how we could do it in ASoC either, presumably the issues that block
doing it in the dmaengine core code would also cause issues doing it in
ASoC?

I'm not saying there's nothing that needs fixing in the dmaengine code,
and like I say I'm not too worried about carrying things in ASoC if the
dmaengine code is intractably difficult, but I'm not sure that the
issues you're rasing aren't orthogonal to the issues with emulating
cyclic transfers.

[-- Attachment #1.2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]