[alsa-devel] Separate dma driver for cpu_dais

[Mark Brown]

On Wed, Feb 17, 2010 at 11:39:47AM +0900, jassi brar wrote:

>   The query concerns ASOC.

Please do remember to CC maintainers on things.  Mail that is sent to
the mailing list only is very likely to get missed.

> Currently we have one platform per card.
> What if my card has two dai_links with each cpu_dai fed data
> with different mechanism(one with system dma controller and
> the other with a dma dedicated to the Audio block). The cpu_dai's
> are tightly coupled and I don't wanna have separate socdev's for them.

Your platform driver would need to handle this.  

> Presently, I define a dma_id flag in snd_soc_dai, make the snd_soc_card
> point to a 'wrapper/muxed' platform driver that checks the dma_id flag and
> calls the relevant platform's callbacks. Of course, each cpu_dai initializes
> the dma_id to a unique value that corresponds to it's real dma mechanism.

Yes, that's fine - you could also set some function pointers for in an
ops structure in the driver private DMA data that gets passed through,
avoiding the need for switch statements but either way works.  This is
not really much different to supplying any other information about how
to set up the DMA for a given front end, it's just that the information
includes going down different code paths for different controllers.

> (For those curious to have a reference - I am talking about Samsung's SoCs
> <http://dev.odroid.com/wiki/odroid/pds/HardwareInformation/S5PC100_UM_REV101.pdf
> refer to figures on page-1635 & 1637>
> that have I2S controllers with h/w mixing capability and where
> 'secondary fifo' can be
> fed with I2S internal DMA controller with dedicated h/w ring buffer)

So.  Ideally for hardware mixing you'd represent the hardware mixing as
a device within ASoC but that's not currently supported - the multi
CODEC work should take care of it but it's not there yet.

However, the hardware mixing you've got there looks relatively simple so
it should work fine to just represent it as two external DAIs - it looks
like there's no sample rate or format conversion so the benefits of
having the mixing visible to ASoC are relatively minor, the main benefit
would be the ability to run the two DAIs inside the CPU at different
rates from the external DAI but the lack of conversion means that's not
possible anyway and the driver will have to constrain the second channel
to what the first is doing anyway.

Overall I don't see any immediate problem with supporting this in
mainline as-is from what I've looked at so far.