All of lore.kernel.org
 help / color / mirror / Atom feed
From: Stephen Warren <swarren@wwwdotorg.org>
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>,
	Grant Likely <grant.likely@secretlab.ca>,
	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: Wed, 04 Sep 2013 12:21:36 -0600	[thread overview]
Message-ID: <52277A30.8010102@wwwdotorg.org> (raw)
In-Reply-To: <20130903231922.GL3084@sirena.org.uk>

On 09/03/2013 05:19 PM, Mark Brown wrote:
> On Tue, Sep 03, 2013 at 01:25:09PM -0600, Stephen Warren wrote:
> 
>> 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.
> 
> I think either works - with DAIs there is a tendency (though not 
> universal) for devices to just have numbered interfaces which makes
> the numbers more natural.  I'm more concerned with the binding
> being legible than with what ends up physically written in there,
> the original reason for strings (apart from the fact that they're
> in the drivers already) was that there was a lot of resistance in
> the DT community to symbolic constants.  That would have lead to
> bindings which looked like line noise.

True.

>>> 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.
> 
> The complexity there comes from the device that's being used rather
> than the design of the sound card though - the fact that a SoC has
> an audio block with many DAIs shouldn't prevent it using the simple
> bindings if someone just hung a simple CODEC off one of the DAIs.

Yes, exactly.

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: Wed, 04 Sep 2013 12:21:36 -0600	[thread overview]
Message-ID: <52277A30.8010102@wwwdotorg.org> (raw)
In-Reply-To: <20130903231922.GL3084@sirena.org.uk>

On 09/03/2013 05:19 PM, Mark Brown wrote:
> On Tue, Sep 03, 2013 at 01:25:09PM -0600, Stephen Warren wrote:
> 
>> 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.
> 
> I think either works - with DAIs there is a tendency (though not 
> universal) for devices to just have numbered interfaces which makes
> the numbers more natural.  I'm more concerned with the binding
> being legible than with what ends up physically written in there,
> the original reason for strings (apart from the fact that they're
> in the drivers already) was that there was a lot of resistance in
> the DT community to symbolic constants.  That would have lead to
> bindings which looked like line noise.

True.

>>> 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.
> 
> The complexity there comes from the device that's being used rather
> than the design of the sound card though - the fact that a SoC has
> an audio block with many DAIs shouldn't prevent it using the simple
> bindings if someone just hung a simple CODEC off one of the DAIs.

Yes, exactly.

  reply	other threads:[~2013-09-04 18:21 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
2013-09-03 19:25       ` [alsa-devel] " 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 [this message]
2013-09-04 18:21           ` 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=52277A30.8010102@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.