LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: Mark Brown <broonie@kernel.org>
To: Jean-Francois Moine <moinejf@free.fr>
Cc: Lars-Peter Clausen <lars@metafoo.de>,
	Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>,
	devicetree@vger.kernel.org, alsa-devel@alsa-project.org,
	Russell King - ARM Linux <linux@arm.linux.org.uk>,
	linux-kernel@vger.kernel.org, Jyri Sarha <jsarha@ti.com>
Subject: Re: [alsa-devel] [PATCH v2 3/3] ASoC: add generic dt-card support
Date: Sat, 7 Feb 2015 16:33:55 +0800	[thread overview]
Message-ID: <20150207083355.GA8054@finisterre.sirena.org.uk> (raw)
In-Reply-To: <20150203203130.5d1cfc42@armhf>

[-- Attachment #1: Type: text/plain, Size: 2601 bytes --]

On Tue, Feb 03, 2015 at 08:31:30PM +0100, Jean-Francois Moine wrote:
> Mark Brown <broonie@kernel.org> wrote:

> > So how does the simple controller interact with a more complex one given
> > that it's somehow picking some controller node to start from?

> A way to solve this problem could be to create only one card builder.
> This creation could be explicit (created by the first active audio
> controller) or implicit by the audio subsystem on the first controller or
> CODEC creation.

> Then, the card builder could scan all the DT looking for the audio
> ports and create one or more cards according to the graph
> connectivity.

How is this going to work with dynamically instantiated hardware like DT
overlays?

> > If you have a device with any sort of speaker or microphone, or any sort
> > of external connector for interfacing with an external device like a
> > headphone jack, then you have something that could be a widget.

> I know what are the widgets and routes, I was just wondering why they
> (especially the widgets) need to appear at the card level instead of
> just being declared in the DAIs (from the platform or the DT).

As previously and repeatedly discussed DAIs have no special place in
a general audio system and we can't base the entire system off them.
Which DAI should have the headphone jack connected to the analogue only
headphone driver in my system (there may not even be a way to route
digital audio to it)?  How does this work for off-SoC audio hubs where
there is a device with multiple DAIs connected to both one or more other
digital devices and the analogue?

Please go and research this if you're intending to work on generic
bindings, it gets extremely repetitive to have to go over this again and
again.  We already have simple-card to provide a binding for trivial
systems and don't want to end up with a never ending series of slightly
more complicated bindings which each cover slightly different sets of
systems in ways that users struggle to differentiate between.

> And the same question may also be raised about the audio formats, clocks,
> tdm's...

Similar things here - which of the two or more devices on a digital
audio link (yes, they're buses not point to point links) has the
configuration and how do we stitch them together?  How do we figure out
when and how to do runtime reconfiguration of the clock tree (which is
needed by some systems)?

Again, please do some research on this.  If you are trying to define
generic device tree bindings it is really important that you understand
what you are trying to model with those bindings.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

  reply	other threads:[~2015-02-07  8:34 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-01-21 19:27 [PATCH v2 0/3] ASoC: add audio card creation from graph of ports in DT Jean-Francois Moine
2015-01-20 18:47 ` [PATCH v2 1/3] ASoC: core: export snd_soc_get_dai_name Jean-Francois Moine
2015-01-20 19:16 ` [PATCH v2 3/3] ASoC: add generic dt-card support Jean-Francois Moine
2015-01-21 20:14   ` [alsa-devel] " Lars-Peter Clausen
2015-01-22  8:07     ` Jean-Francois Moine
2015-01-22 19:00       ` Mark Brown
2015-01-22 19:25       ` Lars-Peter Clausen
2015-01-23 12:15         ` Jean-Francois Moine
2015-01-23 13:56           ` Lars-Peter Clausen
2015-01-23 17:40             ` Mark Brown
2015-01-23 18:34             ` Jean-Francois Moine
2015-01-23 19:13               ` Mark Brown
2015-01-24  7:30                 ` Jean-Francois Moine
2015-02-03 16:47                   ` Mark Brown
2015-02-03 19:31                     ` Jean-Francois Moine
2015-02-07  8:33                       ` Mark Brown [this message]
2015-01-24 11:27               ` Lars-Peter Clausen
2015-01-24 13:18                 ` Jean-Francois Moine
2015-01-26 11:53                   ` Lars-Peter Clausen
2015-01-26 18:22                     ` Jean-Francois Moine
2015-01-21 19:10 ` [PATCH v2 2/3] Documentation: of: Document audio graph bindings Jean-Francois Moine

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=20150207083355.GA8054@finisterre.sirena.org.uk \
    --to=broonie@kernel.org \
    --cc=alsa-devel@alsa-project.org \
    --cc=devicetree@vger.kernel.org \
    --cc=jsarha@ti.com \
    --cc=kuninori.morimoto.gx@renesas.com \
    --cc=lars@metafoo.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux@arm.linux.org.uk \
    --cc=moinejf@free.fr \
    --subject='Re: [alsa-devel] [PATCH v2 3/3] ASoC: add generic dt-card support' \
    /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

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