[alsa-devel] Dynamic PCM and Tegra AHUB

Mark Brown broonie at opensource.wolfsonmicro.com
Mon May 28 00:33:36 CEST 2012

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

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.

> then the codec_dai_name interpreted relative to that. Without a CPU-side
> separation between name/node and dai_name, that's not possible. So, I
> sent a patch for that in case this is the right approach.

I think it is, we've just never been encountering naming collisions on
the CPU side for obvious reasons.

> An alternative to expanding struct snd_soc_dai_link might be to add an
> API so the machine driver could ask the AHUB driver for the
> globally-unique name of each DAI it exposes, and write that into
> dai_link.cpu_dai_name. But if we have that API, we could use it for the
> codec-side of the link to, and just have .codec_dai_name and remove the
> .codec_name and .codec_of_node fields.

This seems bad, it's replacing data with code which is the wrong way

> 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.

> would need to include dai_links for all the DMA FIFO <-> CIF
> connections, which would end up duplicating that list of links into all
> Tegra machine drives (or perhaps sharing it in common code).

We should probably just have a "link blob" class of device which can be
used by things like SoCs (and may also be useful for things that have
lots of derivatives or modular components) and then either placed in the
machine driver automatically or referenced by the machine driver

Though with DT boards perhaps some DT include/refrence stuff can do this
transparently, I'd hope so but I'm not optimistic.

More information about the Alsa-devel mailing list