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
next prev parent 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).