alsa-devel.alsa-project.org archive mirror
 help / color / mirror / Atom feed
From: Jarkko Nikula <jhnikula@gmail.com>
To: Mark Brown <broonie@opensource.wolfsonmicro.com>
Cc: alsa-devel@alsa-project.org, Liam Girdwood <lrg@slimlogic.co.uk>
Subject: Re: [RFC] ASoC: multi-component: Add optional kcontrol prefix name for a DAI link
Date: Thu, 19 Aug 2010 18:20:49 +0300	[thread overview]
Message-ID: <20100819182049.3ecdd0bc.jhnikula@gmail.com> (raw)
In-Reply-To: <20100819135413.GA19582@opensource.wolfsonmicro.com>

On Thu, 19 Aug 2010 14:54:14 +0100
Mark Brown <broonie@opensource.wolfsonmicro.com> wrote:

> On Thu, Aug 19, 2010 at 02:44:51PM +0300, Jarkko Nikula wrote:
> 
> > kcontrol or name prefix still comes from dai_link->kcontrol_prefix
> > (where it should be per codec as pointer by Mark). And no drivers are
> > patched for snd_soc_add_controls, snd_soc_dapm_new_control,
> > snd_soc_dapm_new_controls and snd_soc_dapm_add_routes API changes.
> 
> It seems inelegant to have to bounce the prefix information through the
> CODEC driver - we're already supplying the CODEC when we register the
> controls so it seems like the core ought to be able to work out which
> controls need to be renamed from the machine description without needing
> this.
> 
Yeah, I agree. It would be best if there is no need to change API of
those functions but I haven't figured out yet how those functions
can see should they add prefix or not and what prefix.

So what we do in soc_probe_dai_link:

	cpu_dai->driver->probe
	codec->driver->probe
	-> Codec adds controls, widgets and routes (only controls
	are prefixed. E.g. "front.")
	platform->driver->probe
	codec_dai->driver->probe
	dai_link->init
	-> Machine adds controls, widgets and routes (no prefixes)
	-> Machine registers stuff from extra drivers (all
	controls, widgets and routes are prefixed per driver.
	E.g. "front-left-amp.", "front-right-amp." )

Codec and machine registrations are easy to separate e.g. by some flag
and use only codec->kcontrol_prefix and continue using unmodified API.

I think extra drivers could use own variants of those registration
functions that have the name_prefix argument (and core would call them
too). Then we don't need to patch all the codec and machine drivers.
Does this sound feasible?

> It seems best to have the data come from machine-specific config so that
> we can allow them to provide something that makes things clearer to
> users on the particular board.
> 
Pointer to some codec_name<->prefix table in struct snd_soc_card at
least eliminates the dai_link->kcontrol_prefix.

> > Codec:
> > - kcontrol prefix
> > - no widget name prefix (as they are per codec)
> > - no audio map prefix (as they are per codec)
> 
> Are you sure these are per CODEC?

I thought they and audio map of machine (registered in
dai_link->init) were per codec. Read that as I haven't tried with
second map yet in the test board :-)

Do you think there are some issues e.g. with multi-dai codecs that we
need to address?


-- 
Jarkko

  reply	other threads:[~2010-08-19 15:20 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-08-16  7:29 [RFC] ASoC: multi-component: Add optional kcontrol prefix name for a DAI link Jarkko Nikula
2010-08-16 10:07 ` Mark Brown
2010-08-16 10:53   ` Jarkko Nikula
2010-08-16 11:09     ` Mark Brown
2010-08-19 11:44       ` Jarkko Nikula
2010-08-19 13:54         ` Mark Brown
2010-08-19 15:20           ` Jarkko Nikula [this message]
2010-08-20  8:51             ` Jarkko Nikula
2010-08-23 14:46               ` Jarkko Nikula
2010-08-23 15:21               ` Mark Brown
2010-08-24  7:23                 ` Jarkko Nikula
2010-08-24 10:10                   ` Mark Brown
2010-08-25 10:59                     ` Jarkko Nikula
2010-08-26 13:32                       ` Mark Brown
2010-08-30 11:17                         ` Jarkko Nikula
2010-09-02 14:25                           ` Mark Brown
2010-09-03  7:55                             ` Jarkko Nikula
2010-09-03  9:33                               ` Mark Brown
2010-09-03 10:00                                 ` Liam Girdwood
2010-09-03 11:20                                   ` Jarkko Nikula

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=20100819182049.3ecdd0bc.jhnikula@gmail.com \
    --to=jhnikula@gmail.com \
    --cc=alsa-devel@alsa-project.org \
    --cc=broonie@opensource.wolfsonmicro.com \
    --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 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).