linux-kernel - Re: [alsa-devel] [PATCH] ASoC: generic: add generic compound card with DT support

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <20140102185055.76eb576e@armhf>
Date:	Thu, 2 Jan 2014 18:50:55 +0100
From:	Jean-Francois Moine <moinejf@...e.fr>
To:	Mark Brown <broonie@...nel.org>
Cc:	Lars-Peter Clausen <lars@...afoo.de>,
	Liam Girdwood <lgirdwood@...il.com>,
	alsa-devel@...a-project.org, linux-kernel@...r.kernel.org,
	devicetree@...r.kernel.org
Subject: Re: [alsa-devel] [PATCH] ASoC: generic: add generic compound card
 with DT support

On Thu, 2 Jan 2014 13:10:45 +0000
Mark Brown <broonie@...nel.org> wrote:

> On Thu, Jan 02, 2014 at 01:44:37PM +0100, Jean-Francois Moine wrote:
> 
> > I still don't understand. There is already such cases in the Cubox:
> > the S/PDIF output from the kirkwood audio controller is connected to
> > both the HDMI transmitter and the S/PDIF TOSLINK. So, in the audio
> > controller, the port @1 defines the S/PDIF DAI and the endpoints @0 and
> > @1 point to the remote DAIs, creating 2 snd DAI links:
> 
> > 	port@1 {
> > 		audio_hdmi_spdif: endpoint@0 {
> > 			remote-endpoint = <&hdmi_spdif_audio>;
> > 		};
> > 		audio_spdif: endpoint@1 {
> > 			remote-endpoint = <&spdif_audio>;
> > 		};
> > 	};
> 
> Oh, so the endpoints are virtual and that's supposed to be three things
> wired together rather than a single device with multiple links?  That's
> really not very clear from reading the above and seems cumbersome -
> every device will want to explicitly identify every other device on the
> link and any configuration is going to either need to be replicated on
> every device or we'll need to check lots of places for the configuation.
> It seems like this will be hard to work with.

No, the 'endpoint' <=> 'remote-endpoint' is a point to point relation.
Even if the sources and sinks are not explicitly defined, the way
the stream flows is easy to find: the main source is always in the
'audio-controller' node

	sound {
		compatible = "media-audio";
		audio-controller = <&audio1>;
	};

and, then, the controller ports are sources (CPU DAIs) and the
associated remote ports are sinks (CODEC DAIs).

With many levels, once the remote (sink) ports are identified, in the
devices where such sinks exist, the remaining ports are sources.

Usually, the devices don't have to know to which other device they are
connected, and, yes, the reverse pointer sink to source is not useful.

But the way (link) the audio stream comes from may be important to
know. This is the case for the HDMI CODEC which must tell the HDMI
transmitter from which hardware port(s) ('reg') it may get the audio
stream. That's why, the HDMI encoder has two endpoints in its audio
port, each endpoint being a different CODEC DAI.

-- 
Ken ar c'hentañ	|	      ** Breizh ha Linux atav! **
Jef		|		http://moinejf.free.fr/
--
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/