Re: Dynamic PCM and Tegra AHUB

[Stephen Warren <swarren@wwwdotorg.org>]

On 05/27/2012 04:33 PM, Mark Brown wrote:
> On Fri, May 25, 2012 at 06:23:48PM -0600, Stephen Warren wrote:
> 
>> It seems like the whole point of ASoC dynamic PCM is to represent the
>> AHUB core, and at least some of the surrounding boxes above, as an ASoC
>> CODEC.
> 
> No, not really though it could do.  It's really intended for cases where
> there's a much tighter coupling between the inputs and the outputs and
> where the AP needs to manage the DMA on both sides of the hub (it looks
> like that isn't the case from your diagram).  It wasn't especially
> intended to be used in CODEC devices at all.
> 
> Note that the dynamic PCM setup ends up with you having to define links
> between the components in the machine driver in a similar fashion to
> that which you're discussing below, though the format is different.
...
>> Alternatively, perhaps the DMA FIFOs should be registered as CPU DAIs
>> completely separately from the AHUB CODEC. The AHUB CIFs would then be
>> the DAIs registered by the AHUB CODEC. But then, the machine driver
> 
> This is what I'd expect.

OK, so perhaps I'm confusing codec<->codec links and dynamic PCM yet again.

Referring back to my earlier diagram, I assume that the DMA FIFO -> AHUB
CIF link would be a completely standard snd_soc_dai_link. There would be
another (set of) snd_soc_dai_link for the AHUB CIF -> I2S connections on
the right of the diagram, which would set snd_soc_dai_link.no_pcm=1.

So, in other words, snd_soc_dai_link.no_pcm=1 can end up being used
either for plain codec<->codec links, or dynamic PCM, whereas
snd_soc_dai_link.dynamic is most likely only used for dynamic PCM (I'd
kinda assumed that using the .no_pcm field implied dynamic PCM, but
perhaps that's not the case).