All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mark Brown <broonie@opensource.wolfsonmicro.com>
To: Liam Girdwood <lrg@slimlogic.co.uk>
Cc: alsa-devel@alsa-project.org
Subject: Re: [RFC don't apply] ASoC: Add support for optional auxiliary dailess codecs
Date: Thu, 25 Nov 2010 21:32:54 +0000	[thread overview]
Message-ID: <20101125213145.GB25162@opensource.wolfsonmicro.com> (raw)
In-Reply-To: <1290712703.3302.41.camel@odin>

On Thu, Nov 25, 2010 at 07:18:23PM +0000, Liam Girdwood wrote:
> On Thu, 2010-11-25 at 17:47 +0200, Jarkko Nikula wrote:

> > +	struct snd_soc_aux_dev *aux_dev;
> > +	int num_aux_devs;
> > +	struct snd_soc_pcm_runtime *rtd_aux;
> > +	int num_aux_rtd;

> Could we not just make this a new component type and have a list of aux
> devices ?

I'd certainly rather we didn't have to deal with the PCM runtime data
since obviously the main feature of these things is that there's no PCM
involved.  Need to review this properly to remind myself why we're doing
this...

> > +	/* find CODEC from registered CODECs*/
> > +	list_for_each_entry(codec, &codec_list, list) {
> > +		if (!strcmp(codec->name, aux_dev->codec_name)) {
> > +			if (codec->probed) {
> > +				dev_err(codec->dev,
> > +					"asoc: codec already probed");
> > +				ret = -EBUSY;
> > +				goto out;
> > +			}
> > +			break;
> > +		}
> > +	}

> Why do aux devices need to be coupled with CODECs here ? 

The way we've got things set up currently the CODEC isn't really just a
CODEC, it's got a bunch of other random services which are more generic
chip services associated with it like the register cache and the bias
management.  There's so much overlap between the devices that I'm not
sure that it's really worth splitting the types up too much at the root
level (CODEC is pretty much a superclass that has everything on it but
DMA).

Given how widely used snd_soc_codec is I'm not sure it's worth fixing
the naming thing here, especially since 99% of the time the device is
actually a CODEC.

  reply	other threads:[~2010-11-25 21:32 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-11-25 15:47 [RFC don't apply] ASoC: Add support for optional auxiliary dailess codecs Jarkko Nikula
2010-11-25 19:18 ` Liam Girdwood
2010-11-25 21:32   ` Mark Brown [this message]
2010-11-26  7:25     ` Jarkko Nikula
2010-11-26 12:19       ` Peter Ujfalusi
2010-11-26 13:35         ` Jarkko Nikula
2010-11-26 13:41           ` Mark Brown
2010-11-26 13:55             ` Peter Ujfalusi
2010-11-26 13:59               ` Mark Brown
2010-11-26 14:14               ` Jarkko Nikula
2010-11-28 11:50 ` Mark Brown
2010-11-30 14:43   ` 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=20101125213145.GB25162@opensource.wolfsonmicro.com \
    --to=broonie@opensource.wolfsonmicro.com \
    --cc=alsa-devel@alsa-project.org \
    --cc=lrg@slimlogic.co.uk \
    /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.