devicetree.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jean-Francois Moine <moinejf@free.fr>
To: Mark Brown <broonie@kernel.org>
Cc: devicetree@vger.kernel.org, alsa-devel@alsa-project.org,
	Lars-Peter Clausen <lars@metafoo.de>,
	Liam Girdwood <lgirdwood@gmail.com>,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH] ASoC: generic: add generic compound card with DT support
Date: Thu, 2 Jan 2014 18:50:55 +0100	[thread overview]
Message-ID: <20140102185055.76eb576e@armhf> (raw)
In-Reply-To: <20140102131045.GZ31886@sirena.org.uk>

On Thu, 2 Jan 2014 13:10:45 +0000
Mark Brown <broonie@kernel.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/
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

  reply	other threads:[~2014-01-02 17:50 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20131231113138.102044cf@armhf>
     [not found] ` <52C466E1.3030302@metafoo.de>
     [not found]   ` <20140101210814.31e3f3a9@armhf>
     [not found]     ` <52C4766B.8080000@metafoo.de>
2014-01-02  9:26       ` [alsa-devel] [PATCH] ASoC: generic: add generic compound card with DT support Jean-Francois Moine
2014-01-02 11:10         ` Mark Brown
2014-01-02 11:43           ` Jean-Francois Moine
2014-01-02 11:56             ` Mark Brown
2014-01-02 12:44               ` Jean-Francois Moine
2014-01-02 13:10                 ` Mark Brown
2014-01-02 17:50                   ` Jean-Francois Moine [this message]
2014-01-02 18:35                     ` Mark Brown

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20140102185055.76eb576e@armhf \
    --to=moinejf@free.fr \
    --cc=alsa-devel@alsa-project.org \
    --cc=broonie@kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=lars@metafoo.de \
    --cc=lgirdwood@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).