All of lore.kernel.org
 help / color / mirror / Atom feed
From: Stephen Warren <swarren@wwwdotorg.org>
To: Lars-Peter Clausen <lars@metafoo.de>
Cc: devicetree@vger.kernel.org, alsa-devel@alsa-project.org,
	Liam Girdwood <lgirdwood@gmail.com>,
	Grant Likely <grant.likely@secretlab.ca>,
	Mark Brown <broonie@kernel.org>,
	Sascha Hauer <kernel@pengutronix.de>,
	Markus Pargmann <mpa@pengutronix.de>,
	Shawn Guo <shawn.guo@linaro.org>,
	linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH 2/3] ASoC: generic simple sound card DT bindings
Date: Tue, 03 Sep 2013 13:25:09 -0600	[thread overview]
Message-ID: <52263795.8010600@wwwdotorg.org> (raw)
In-Reply-To: <52220766.1040504@metafoo.de>

On 08/31/2013 09:10 AM, Lars-Peter Clausen wrote:
> On 08/31/2013 12:44 PM, Markus Pargmann wrote:
>> Simple sound card initialized using DT. When used with AC97, ac97-codec
>> is used to automatically discover the used codec.

>> diff --git a/Documentation/devicetree/bindings/sound/generic,simple-dt-card.txt b/Documentation/devicetree/bindings/sound/generic,simple-dt-card.txt

>> +ASoC Simple Sound Card

As Lars mentions below, we shouldn't have bindings for ASoC; we should
have bindings that describe the HW. Bindings are supposed to be
OS-agnostic, whereas "ASoC" is Linux-specific.

>> +
>> +A simple generic driver that connects a CPU DAI with a CODEC.
>> +
>> +Required properties:
>> + - compatible: "asoc-simple-card" used for standard ssi, codec
>> +   combinations, or "asoc-simple-ac97-card" to use ac97 to discover the
>> +   codec.
>> + - cpu-dai: CPU DAI connected to the codec.
>> +
>> +Required properties for "asoc-simple-card":
>> + - audio-codec: Codec phandle.
>> + - codec-dai-name: DAI name within the codec.
> 
> In my opinion this binding exposes way to much of the ASoC internal data
> structures. E.g. CODECs are referenced by phandle, but the DAI of the CODEC
> is reference by a string. This string is completely ASoC internal.

Mark has made the argument that (at least for CODEC analog pins) we can
simply put those strings into the binding document, and make them as
much a part of the binding as anything else. After all, (at least for
CODEC analog pins) the values are simply the names of the pins on the
package, as listed by the HW documentation itself.

We could presumably do the same thing for DAIs; in DT, use a
string-based DAI name derived directly from the HW documentation, rather
than the current intra-ASoC DAI name strings.

That said, I will admit that I personally don't really like the idea of
using strings in bindings. That opinion certainly isn't universal though.

> The
> binding also assumes that a CPU controller may have one DAI at most. In my
> opinion this binding ought to use the upcoming of_xlate stuff for ASoC
> components.

That restriction seems reasonable for a *simple* DT sound binding. For
more complex cards, one could presumably create more complex bindings,
be they generic bindings that cover arbitrary more complex cases, or
bindings for specific configurations that happen to include multiple DAIs.

WARNING: multiple messages have this Message-ID (diff)
From: swarren@wwwdotorg.org (Stephen Warren)
To: linux-arm-kernel@lists.infradead.org
Subject: [alsa-devel] [PATCH 2/3] ASoC: generic simple sound card DT bindings
Date: Tue, 03 Sep 2013 13:25:09 -0600	[thread overview]
Message-ID: <52263795.8010600@wwwdotorg.org> (raw)
In-Reply-To: <52220766.1040504@metafoo.de>

On 08/31/2013 09:10 AM, Lars-Peter Clausen wrote:
> On 08/31/2013 12:44 PM, Markus Pargmann wrote:
>> Simple sound card initialized using DT. When used with AC97, ac97-codec
>> is used to automatically discover the used codec.

>> diff --git a/Documentation/devicetree/bindings/sound/generic,simple-dt-card.txt b/Documentation/devicetree/bindings/sound/generic,simple-dt-card.txt

>> +ASoC Simple Sound Card

As Lars mentions below, we shouldn't have bindings for ASoC; we should
have bindings that describe the HW. Bindings are supposed to be
OS-agnostic, whereas "ASoC" is Linux-specific.

>> +
>> +A simple generic driver that connects a CPU DAI with a CODEC.
>> +
>> +Required properties:
>> + - compatible: "asoc-simple-card" used for standard ssi, codec
>> +   combinations, or "asoc-simple-ac97-card" to use ac97 to discover the
>> +   codec.
>> + - cpu-dai: CPU DAI connected to the codec.
>> +
>> +Required properties for "asoc-simple-card":
>> + - audio-codec: Codec phandle.
>> + - codec-dai-name: DAI name within the codec.
> 
> In my opinion this binding exposes way to much of the ASoC internal data
> structures. E.g. CODECs are referenced by phandle, but the DAI of the CODEC
> is reference by a string. This string is completely ASoC internal.

Mark has made the argument that (at least for CODEC analog pins) we can
simply put those strings into the binding document, and make them as
much a part of the binding as anything else. After all, (at least for
CODEC analog pins) the values are simply the names of the pins on the
package, as listed by the HW documentation itself.

We could presumably do the same thing for DAIs; in DT, use a
string-based DAI name derived directly from the HW documentation, rather
than the current intra-ASoC DAI name strings.

That said, I will admit that I personally don't really like the idea of
using strings in bindings. That opinion certainly isn't universal though.

> The
> binding also assumes that a CPU controller may have one DAI at most. In my
> opinion this binding ought to use the upcoming of_xlate stuff for ASoC
> components.

That restriction seems reasonable for a *simple* DT sound binding. For
more complex cards, one could presumably create more complex bindings,
be they generic bindings that cover arbitrary more complex cases, or
bindings for specific configurations that happen to include multiple DAIs.

  parent reply	other threads:[~2013-09-03 19:25 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-08-31 10:44 [PATCH 0/3] ASoC: generic simple sound card DT bindings Markus Pargmann
2013-08-31 10:44 ` Markus Pargmann
2013-08-31 10:44 ` [PATCH 1/3] ASoC: generic: simple card, use private data Markus Pargmann
2013-08-31 10:44   ` Markus Pargmann
2013-08-31 10:44 ` [PATCH 2/3] ASoC: generic simple sound card DT bindings Markus Pargmann
2013-08-31 10:44   ` Markus Pargmann
2013-08-31 15:10   ` Lars-Peter Clausen
2013-08-31 15:10     ` [alsa-devel] " Lars-Peter Clausen
2013-09-02  8:13     ` Markus Pargmann
2013-09-02  8:13       ` [alsa-devel] " Markus Pargmann
2013-09-03 19:25     ` Stephen Warren [this message]
2013-09-03 19:25       ` Stephen Warren
2013-09-03 23:19       ` Mark Brown
2013-09-03 23:19         ` [alsa-devel] " Mark Brown
2013-09-04 18:21         ` Stephen Warren
2013-09-04 18:21           ` [alsa-devel] " Stephen Warren
2013-08-31 10:44 ` [PATCH 3/3] ASoC: fsl: Kconfig, visible config items for simple card Markus Pargmann
2013-08-31 10:44   ` Markus Pargmann

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=52263795.8010600@wwwdotorg.org \
    --to=swarren@wwwdotorg.org \
    --cc=alsa-devel@alsa-project.org \
    --cc=broonie@kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=grant.likely@secretlab.ca \
    --cc=kernel@pengutronix.de \
    --cc=lars@metafoo.de \
    --cc=lgirdwood@gmail.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=mpa@pengutronix.de \
    --cc=shawn.guo@linaro.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.