LKML Archive on
help / color / mirror / Atom feed
From: Lars-Peter Clausen <>
To: Jean-Francois Moine <>
Cc: Mark Brown <>,
	Kuninori Morimoto <>,,,
	Russell King - ARM Linux <>,, Jyri Sarha <>
Subject: Re: [alsa-devel] [PATCH v2 3/3] ASoC: add generic dt-card support
Date: Thu, 22 Jan 2015 20:25:39 +0100	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <20150122090723.50ac0156@armhf>

On 01/22/2015 09:07 AM, Jean-Francois Moine wrote:
> On Wed, 21 Jan 2015 21:14:07 +0100
> Lars-Peter Clausen <> wrote:
>> [...]
>>> +	card->dai_link->dai_fmt =
>>> +		snd_soc_of_parse_daifmt(of_cpu, "dt-audio-card,",
>>> +					NULL, NULL) &
>> This one does not seem to be in the bindings documentation.
> Sorry, I forgot to remove it from the patch.

Ah, too bad this was the part I was most interested in. I think that using 
the generic of graph framework as a unified way for expressing non-control 
links is a good idea, whether it be for audio, video or something else.

But I think there are some open questions that need to be address when 
coming up with a specification for audio so we do not have to write yet 
another incompatible DT spec in 3 months time.

One issue is how to deal with multi-point-to-multi-point links. I2S/TDM is a 
bus and can have more than one reader/writer.

The second issue is how to describe the clock and frame master 
relationships. Multiple different buses can share the same clock and frame 
generator. E.g. typically the capture and playback stream are linked in this 

How are we going to handle bus specific properties. Properties which are 
neither a property of either of the endpoints on the link, but of the link 

> BTW, the graph of port should also contain pieces of the audio specific
> hardware information as the ones found in the simple-card (clock,
> GPIO, ...). This information could be written as generic device node
> properties. i.e without any prefix.
> I was also wondering about some of these properties, as widgets and
> routing. They seem to be software information and Linux specific.
> Must these properties appear in the DTs?

Well last time I checked the speaker on my board was hardware not software 
and wasn't Linux specific either ;) Those widgets and routing represent the 
(typically analog) audio fabric on the board and are part of the hardware 
description. This is not even ASoC or devicetree specific, e.g. HDA uses a 
similar concept where the BIOS provides a description of which pins of the 
audio CODEC is connected to which speaker, microphone, etc. And especially 
on embedded boards the audio fabric can become quite complex.

Your example is a relative simple one where you do not have any additional 
audio fabric on the board itself.

- Lars

  parent reply	other threads:[~2015-01-22 19:25 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 [this message]
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
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:

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

  git send-email \ \ \ \ \ \ \ \ \ \ \

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