linux-kernel - Re: [PATCH 1/2] ARM: Dove: Add the audio devices in DT

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20130830150841.GY6617@n2100.arm.linux.org.uk>
Date:	Fri, 30 Aug 2013 16:08:41 +0100
From:	Russell King - ARM Linux <linux@....linux.org.uk>
To:	Sebastian Hesselbarth <sebastian.hesselbarth@...il.com>
Cc:	Jean-Francois Moine <moinejf@...e.fr>,
	Thomas Petazzoni <thomas.petazzoni@...e-electrons.com>,
	Mark Rutland <mark.rutland@....com>,
	devicetree@...r.kernel.org, Jason Cooper <jason@...edaemon.net>,
	Pawel Moll <pawel.moll@....com>,
	Stephen Warren <swarren@...dotorg.org>,
	linux-kernel@...r.kernel.org,
	Rob Herring <rob.herring@...xeda.com>,
	Gregory CLEMENT <gregory.clement@...e-electrons.com>,
	linux-arm-kernel@...ts.infradead.org,
	Ian Campbell <ian.campbell@...rix.com>
Subject: Re: [PATCH 1/2] ARM: Dove: Add the audio devices in DT

On Thu, Aug 29, 2013 at 01:01:23PM +0200, Sebastian Hesselbarth wrote:
> Taking the sound node above:
>
> sound {
> 	compatible = "whatever-audio";
> 	...
> 	audio-codec = <&rt1234 1>, <&spdif 0>;
> 	audio-codec-names = "i2s", "spdifo";
> 	...
> };
>
> Each audio-codec phandle with arg links to one specific "port" at some
> "codec". The audio-codec-names property allows the ASoC driver to
> determine the local "ports" where the above codecs are connected.
> The dummy codecs are ASoC specific and must be added by the driver.

I think it's slightly more complicated than that.  Here's what needs to
be setup with DPCM - when it eventually works:

1. Two DAI links need to be setup:
1a:             .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,

1b:             .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",

   This separates the CPU DAI from the codec DAI - the important thing
   seems to be that the first entry (which connects the CPU DAI to the
   dummy codec) breaks the automatic DAPM routes between the CPU streams
   and the codec streams.

2. DAPM routes need to be created between the CPU DAI and Codec DAIs to
   wire the back together:

	static const struct snd_soc_dapm_route routes[] = {
	        { "spdif-Playback", NULL, "spdifdo" },
	};

"spdif-Playback" is the stream name in the spdif-dit codec (I had to change
the name from merely "Playback" as otherwise the route gets bound to the
dummy codec instead.)  "spdifdo" is the audio interface widget name in the
CPU DAI, which is connected to the CPU DAI playback stream.

So, if we wanted two codecs, one spdif and one i2s, we would need something
like this:

DAI links:
                .name = "CPU",
                .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 = "I2S",
                .stream_name = "PCM Playback",
                .cpu_dai_name = "snd-soc-dummy-dai",
                .platform_name = "snd-soc-dummy",
                .no_pcm = 1,
                .codec_dai_name = "i2s-codec-dai-name",
                .codec_name = "i2s-codec-name",
                .ops = &..._ops,

                .name = "SPDIF",
                .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",

with routes like this:

static const struct snd_soc_dapm_route routes[] = {
	{ "i2sdi", NULL, "i2s-codec-Capture" },
	{ "i2s-codec-Playback", NULL, "i2sdo" },
        { "spdif-Playback", NULL, "spdifdo" },
};

If we were to add support for SPDIF recording mode, then we'd need to add
an additional route for that.

The pitfalls here are:
1. if we are going to refer to codec streams in DAPM routes, we need all
   codec implementations to have unique names, or some way for DAPM routes
   to refer to specific codec streams.

2. being able to effectively represent this in DT.

I think we need a flag in DT to indicate a DPCM configuration, which would
trigger the creation of the first DAI link.  The second and (optionally)
third can be generated from knowing the codec DAI name and the codec
name.  I think we also need a way to specify arbitary DAPM routes in DT
as well.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/