alsa-devel.alsa-project.org archive mirror
 help / color / mirror / Atom feed
From: Russell King - ARM Linux <linux@arm.linux.org.uk>
To: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
Cc: Mark Brown <broonie@kernel.org>,
	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 10:43:40 +0100	[thread overview]
Message-ID: <20130809094340.GO23006@n2100.arm.linux.org.uk> (raw)
In-Reply-To: <5204B7A6.9050907@gmail.com>

On Fri, Aug 09, 2013 at 11:34:30AM +0200, Sebastian Hesselbarth wrote:
> Mark,
>
> I do understand there may be SoCs requiring sophisticated extra audio
> nodes, but Marvell SoCs don't. I prefer having a single node for the
> i2s controller *and* exploit the audio subsystem properties from that.
>
> For Marvell audio, we only need a single node for all three ASoC
> drivers. No other subsystem _requires_ you to have extra nodes for
> it's needs. If you can provide interrupts, just have an interrupt-
> controller property. If you can provide clocks, you can link to that
> very node - no virtual device node required. Even for media they
> do not insist on a virtual node but they do have generic properties
> you can exploit.

Certainly from the "DT is a hardware description" you are completely
correct.  The audio controller _should_ link directly to the codec,
because that's how the hardware is wired.  Remember though that there
are two outputs from the audio controller (please, call it audio
controller, not I2S controller) so you need to specify which of those
two outputs the "codec" is connected to.

I would say that's required irrespective of whether or not we have a
virtual node to aggregate the stuff together for ASoC's purposes (which
should not be part of the DT hardware description - it can be part of
the "software" configuration though.)

We may be able to have kirkwood-i2s.c (which I plan to rename to
mvebu-audio.c) automatically generate the snd_soc_card stuff from the
audio controller node.  Given that we need a more complex description
than the "simple" thing for DPCM, that might be overall the best
solution in any case (maybe calling out to a library which can be
shared between CPU DAI drivers to do this.)

Note that we do have another case not yet in tree, which is DRM, but
this case is different from that, because ASoC can cope with components
with independent initialisation.

  reply	other threads:[~2013-08-09  9:43 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-08-08 11:22 [PATCH v4 1/1] ASoc: kirkwood: add DT support to the mvebu audio subsystem 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 [this message]
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
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       ` Lars-Peter Clausen
2013-08-09 10:18         ` [alsa-devel] " 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=20130809094340.GO23006@n2100.arm.linux.org.uk \
    --to=linux@arm.linux.org.uk \
    --cc=alsa-devel@alsa-project.org \
    --cc=broonie@kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=lgirdwood@gmail.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --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;
as well as URLs for NNTP newsgroup(s).