From: Mark Brown <broonie@kernel.org>
To: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
Cc: Russell King - ARM Linux <linux@arm.linux.org.uk>,
Jean-Francois Moine <moinejf@free.fr>,
Liam Girdwood <lgirdwood@gmail.com>,
Jaroslav Kysela <perex@perex.cz>, Takashi Iwai <tiwai@suse.de>,
Rob Herring <rob.herring@calxeda.com>,
alsa-devel@alsa-project.org, linux-kernel@vger.kernel.org,
devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH v4 1/1] ASoc: kirkwood: add DT support to the mvebu audio subsystem
Date: Fri, 9 Aug 2013 12:39:40 +0100 [thread overview]
Message-ID: <20130809113940.GY6427@sirena.org.uk> (raw)
In-Reply-To: <5204CC04.4000401@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2246 bytes --]
On Fri, Aug 09, 2013 at 01:01:24PM +0200, Sebastian Hesselbarth wrote:
> And that is *the only thing* that keeps bugging me in Mark's replies -
> he *insists* on having that virtual audio nodes. I have nothing against
> it, except it should be *required* for every DT we have. DRM doesn't
> _need_ it, media doesn't _need_ it, but audio is so very special that it
> _requires_ you to have it described in DT?
> I understand that it may be required on some boards, especially if you
> create different sound-cards out of the IP available. Just like the
> DRM discussion we had - have a virtual node if there is no other sane
> way to describe it, but there is no strict requirement.
The problem here is that the extra effort comes from the board, not from
the individual components - any component would have to optionally
support having a card binding hanging off it (or the properties for a
simple link) so it's more consistent just to say we link everything from
a board node all the time. By the time you start adding all the things
like jacks and connected pins I'd expect you'd find you'd want to have
at least a sub node to organise everything.
Even things like buses aren't that clear - an I2S link can be a
fairly simple point to point link but it can also be a multi-master bus
or share some signals with other links. Things like DRM generally have
interconnects which are much more regular and less open to interesting
board design decisions, though even for media the last time I looked at
the bindings the individual links were getting DT nodes which is another
way to try to deal with things.
Let me once more renew my request that you go and read the previous
discussions on this stuff, we've been through this loop repeatedly.
> That is what I am doing on top of the audio-controller node and except
> that there is no helper to determine the names, yet. If ASoC would
> provide a snd_soc_simple_card_register_from_dt(...,device_node *), I
> wouldn't even have to parse the properties myself.
So extend Morimoto-san's work on the simple card for this - that's what
it's there for, it's doing exactly this job for non-DT systems but it
just didn't get DT support added yet. All the trivial cards should end
up using this.
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
next prev parent reply other threads:[~2013-08-09 11:40 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-08-08 11:22 Jean-Francois Moine
2013-08-09 8:23 ` Sebastian Hesselbarth
2013-08-09 9:06 ` Jean-Francois Moine
2013-08-09 9:30 ` Russell King - ARM Linux
2013-08-10 9:16 ` Thomas Petazzoni
2013-08-09 9:19 ` Mark Brown
2013-08-09 9:34 ` Sebastian Hesselbarth
2013-08-09 9:43 ` Russell King - ARM Linux
2013-08-09 10:30 ` [PATCH v4 1/1] ASoc: kirkwood: add DT support to the mvebu audio subsystem [OT] Jean-Francois Moine
2013-08-09 11:01 ` [PATCH v4 1/1] ASoc: kirkwood: add DT support to the mvebu audio subsystem Sebastian Hesselbarth
2013-08-09 11:39 ` Mark Brown [this message]
2013-08-09 13:09 ` Russell King - ARM Linux
2013-08-09 18:00 ` Mark Brown
2013-08-09 18:25 ` Russell King - ARM Linux
2013-08-09 19:44 ` Mark Brown
2013-08-09 20:38 ` Russell King - ARM Linux
2013-08-09 23:42 ` Mark Brown
2013-08-10 9:31 ` Russell King - ARM Linux
2013-08-10 11:12 ` Mark Brown
2013-08-09 10:05 ` [alsa-devel] " Lars-Peter Clausen
2013-08-09 10:18 ` 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=20130809113940.GY6427@sirena.org.uk \
--to=broonie@kernel.org \
--cc=alsa-devel@alsa-project.org \
--cc=devicetree@vger.kernel.org \
--cc=lgirdwood@gmail.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux@arm.linux.org.uk \
--cc=moinejf@free.fr \
--cc=perex@perex.cz \
--cc=rob.herring@calxeda.com \
--cc=sebastian.hesselbarth@gmail.com \
--cc=tiwai@suse.de \
/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
all inboxes | Powered by JetHome®