[alsa-devel] [PATCH 00/14] SPDIF support

[Russell King - ARM Linux]

On Mon, Sep 02, 2013 at 05:27:29PM +0100, Mark Brown wrote:
> On Mon, Sep 02, 2013 at 03:16:31PM +0100, Russell King - ARM Linux wrote:
> > On Mon, Sep 02, 2013 at 03:06:32PM +0100, Mark Brown wrote:
> 
> > > Yes, and this is one of the reasons for suggesting getting either/or
> > > support merged - it will help things like the binding definition
> > > progress (as well as being useful for any users with a S/PDIF only
> > > system).
> 
> > Sorry, but I believe the exact opposite:
> 
> > 1. The DAI link binding created for a dual-DAI driver is completely
> >    different from the DAI link binding for a DPCM driver.  The dual
> >    DAI link binding will have to be completely rewritten when the
> >    driver is converted to DPCM.
> 
> That seems like overstating the difficulties.  The updates for any new
> S/PDIF drivers will be pretty much the same as those for the existing
> I2S drivers and should just be mechanical changes, nothing too taxing.

Sorry, you need to explain more.

Here's the dual-DAI version:

                .name = "S/PDIF1",
                .stream_name = "IEC958 Playback",
                .platform_name = "mvebu-audio.1",
                .cpu_dai_name = "kirkwood-spdif.1",
                .codec_dai_name = "dit-hifi",
                .codec_name = "spdif-dit",

Here's the DPCM version:

        {
                .name = "S/PDIF1",
                .stream_name = "Audio Playback",
                .platform_name = "mvebu-audio.1",
                .cpu_dai_name = "mvebu-audio.1",
                .codec_name = "snd-soc-dummy",
                .codec_dai_name = "snd-soc-dummy-dai",
                .dynamic = 1,
        }, {
                .name = "Codec",
                .stream_name = "IEC958 Playback",
                .cpu_dai_name = "snd-soc-dummy-dai",
                .platform_name = "snd-soc-dummy",
                .no_pcm = 1,
                .codec_dai_name = "dit-hifi",
                .codec_name = "spdif-dit",
        },

The above are two completely different beasts.  Please explain how the DT
representation for those DAI links can be the same.

> > 2. When the driver is converted to DPCM, it must use DPCM for
> >    everything, otherwise it has no way to know which of SPDIF or I2S to
> >    enable.  The only way I know to work around that is to add additional
> >    routes to link up the AIF widgets, and that's the solution you're all
> >    telling me is not acceptable, as per the patch set at the start of
> >    this thread.
> 
> What we have been telling you is that if there is a DAI link present
> (there should be one for each physical DAI link) then this should be
> enough information for the framework to know that the two DAIs are
> linked and if any routes are needed in DAPM these should be added
> automatically in the same way that we add links for CODEC<->CODEC links
> at present.
> 
> It's been said to you off-list that having the links manually added
> but marking them for removal when the framework figures out how to do
> that should be OK.

Sorry, I just don't get this.  What you seem to be telling me here is to
forget DPCM, and just go with the dual DAI solution.

If I have separate CPU DAI links, then I can't do simultaneous operation,
because both DAI links are entirely separate entities which are activated
entirely separately.  The only way I know how to handle this is with the
patch set I've already posted.

We've been through this before: this is also not how Liam's example DPCM
driver works - please go back and look at those diagrams I drew you of
how Liam's driver is setup.  I've also said to you that from what I can
see, the routes are still required for DPCM - those routes are in Liam's
DPCM driver as well.