All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mark Brown <broonie@opensource.wolfsonmicro.com>
To: Barry Song <21cnbao@gmail.com>
Cc: "Cai, Cliff" <Cliff.Cai@analog.com>,
	alsa-devel@alsa-project.org,
	Mike Frysinger <vapier.adi@gmail.com>
Subject: Re: dev_* output functions and ASoC codecs
Date: Mon, 12 Oct 2009 11:48:49 +0100	[thread overview]
Message-ID: <20091012104849.GA7994@rakim.wolfsonmicro.main> (raw)
In-Reply-To: <3c17e3570910120334u6646b031vb5300645da8b6ce4@mail.gmail.com>

On Mon, Oct 12, 2009 at 06:34:56PM +0800, Barry Song wrote:
> On Mon, Oct 12, 2009 at 5:36 PM, Mark Brown

> In codec:
> "static struct snd_soc_codec *wm8903_codec" is a global variable to
> describe a codec.  The global variable limit the codec driver can only
> support one to work.

Right, currently the WM8903 driver only allows one instance - this will
be addressed in the future but for now the core doesn't really support
this.  Addressing this is the main reason why the drivers need to be
converted away from the old style of probing to using the device model
and supplying struct deviecs - without doing that it's not possible to
support more than one instance of the same CODEC.

> In CPU dai:
> in case there are two same I2S interfaces connecting two same wm8903,
> then an array with two elements for CPU dai is needed.

I'm sorry, I can't quite parse what you're saying here.  If you have two
CPU DAIs then you need an array to hold them but that seems self evident
so is presumably not what you mean?

> In machin driver:
> snd_soc_dai_link connect the multi same CPU dai and codec dai together.
> 
> If we don't use num_links =2, we need to call
> platform_device_alloc("soc-audio",...)/platform_device_add() twice
> with duplicated struct snd_soc_device.

Again, I'm not 100% clear what you're saying here.  If you have a CODEC
with two DAIs which you need to connect to two CPU drivers then you will
need two dai_links.  If you have two unrelated sound subsystems in your
system then you should end up with two separate sound devices at the
ALSA level.  I understand that this currently works OK, though it's not
really supported.

  reply	other threads:[~2009-10-12 10:48 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-10-06  0:18 dev_* output functions and ASoC codecs Mike Frysinger
2009-10-06 10:20 ` Mark Brown
2009-10-12  2:26   ` Barry Song
2009-10-12  9:36     ` Mark Brown
2009-10-12 10:34       ` Barry Song
2009-10-12 10:48         ` Mark Brown [this message]
2009-10-12 13:20           ` Barry Song
2009-10-12 14:20             ` Mark Brown
2009-10-13 10:09               ` Barry Song
2009-10-13 10:14                 ` Mark Brown
2009-10-20  5:27                   ` Barry Song
2009-10-20  9:52                     ` 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=20091012104849.GA7994@rakim.wolfsonmicro.main \
    --to=broonie@opensource.wolfsonmicro.com \
    --cc=21cnbao@gmail.com \
    --cc=Cliff.Cai@analog.com \
    --cc=alsa-devel@alsa-project.org \
    --cc=vapier.adi@gmail.com \
    /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.