[alsa-devel] [RFC] ASoC: multi-component: Add optional kcontrol prefix name for a DAI link
This optional kcontrol_prefix allows to specify unique prefix for ALSA control names for each DAI link. This makes possible to have a sound card configuration with multiple DAIs and each of them using the same codec driver without name collision.
Currently name collision would occur if a codec driver tries to register a kcontrol with a same name for another DAI link.
Now it is possible to specify for instance "Front" and "Rear" prefixes and a sound card can have two separate controls like "Front.PCM Playback Volume" and "Rear.PCM Playback Volume". Those controls will then show as "Front.PCM" and "Rear.PCM" in ALSA mixer application.
Signed-off-by: Jarkko Nikula jhnikula@gmail.com --- include/sound/soc.h | 2 ++ sound/soc/soc-core.c | 13 +++++++++++-- sound/soc/soc-dapm.c | 28 ++++++++++++++++++++++------ 3 files changed, 35 insertions(+), 8 deletions(-)
diff --git a/include/sound/soc.h b/include/sound/soc.h index d31e8b7..9b83f7e 100644 --- a/include/sound/soc.h +++ b/include/sound/soc.h @@ -423,6 +423,7 @@ struct snd_soc_ops { /* SoC Audio Codec device */ struct snd_soc_codec { const char *name; + const char *kcontrol_prefix; int id; struct device *dev; struct snd_soc_codec_driver *driver; @@ -539,6 +540,7 @@ struct snd_soc_dai_link { const char *platform_name; /* for multi-platform */ const char *cpu_dai_name; const char *codec_dai_name; + const char *kcontrol_prefix; /* kcontrol prefix for multi-codec */
/* Keep DAI active over suspend */ unsigned int ignore_suspend:1; diff --git a/sound/soc/soc-core.c b/sound/soc/soc-core.c index a004876..f52eb2a 100644 --- a/sound/soc/soc-core.c +++ b/sound/soc/soc-core.c @@ -1289,6 +1289,7 @@ static int soc_probe_dai_link(struct snd_soc_card *card, int num) /* config components */ codec_dai->codec = codec; codec->card = card; + codec->kcontrol_prefix = dai_link->kcontrol_prefix; cpu_dai->platform = platform; rtd->card = card; rtd->dev.parent = card->dev; @@ -1903,14 +1904,22 @@ int snd_soc_add_controls(struct snd_soc_codec *codec, const struct snd_kcontrol_new *controls, int num_controls) { struct snd_card *card = codec->card->snd_card; + char prefixed_name[44], *name; int err, i;
for (i = 0; i < num_controls; i++) { const struct snd_kcontrol_new *control = &controls[i]; - err = snd_ctl_add(card, snd_soc_cnew(control, codec, NULL)); + if (codec->kcontrol_prefix) { + snprintf(prefixed_name, sizeof(prefixed_name), "%s.%s", + codec->kcontrol_prefix, control->name); + name = prefixed_name; + } else { + name = control->name; + } + err = snd_ctl_add(card, snd_soc_cnew(control, codec, name)); if (err < 0) { dev_err(codec->dev, "%s: Failed to add %s\n", - codec->name, control->name); + codec->name, name); return err; } } diff --git a/sound/soc/soc-dapm.c b/sound/soc/soc-dapm.c index 035cab8..5751f4f 100644 --- a/sound/soc/soc-dapm.c +++ b/sound/soc/soc-dapm.c @@ -327,6 +327,7 @@ static int dapm_new_mixer(struct snd_soc_codec *codec, int i, ret = 0; size_t name_len; struct snd_soc_dapm_path *path; + char prefix[10];
/* add kcontrol */ for (i = 0; i < w->num_kcontrols; i++) { @@ -347,6 +348,13 @@ static int dapm_new_mixer(struct snd_soc_codec *codec, name_len = strlen(w->kcontrols[i].name) + 1; if (w->id != snd_soc_dapm_mixer_named_ctl) name_len += 1 + strlen(w->name); + if (codec->kcontrol_prefix) { + name_len += 1 + strlen(codec->kcontrol_prefix); + snprintf(prefix, sizeof(prefix), "%s.", + codec->kcontrol_prefix); + } else { + prefix[0] = '\0'; + }
path->long_name = kmalloc(name_len, GFP_KERNEL);
@@ -355,12 +363,12 @@ static int dapm_new_mixer(struct snd_soc_codec *codec,
switch (w->id) { default: - snprintf(path->long_name, name_len, "%s %s", - w->name, w->kcontrols[i].name); + snprintf(path->long_name, name_len, "%s%s %s", + prefix, w->name, w->kcontrols[i].name); break; case snd_soc_dapm_mixer_named_ctl: - snprintf(path->long_name, name_len, "%s", - w->kcontrols[i].name); + snprintf(path->long_name, name_len, "%s%s", + prefix, w->kcontrols[i].name); break; }
@@ -388,6 +396,7 @@ static int dapm_new_mux(struct snd_soc_codec *codec, { struct snd_soc_dapm_path *path = NULL; struct snd_kcontrol *kcontrol; + char prefixed_name[44], *name; int ret = 0;
if (!w->num_kcontrols) { @@ -395,7 +404,14 @@ static int dapm_new_mux(struct snd_soc_codec *codec, return -EINVAL; }
- kcontrol = snd_soc_cnew(&w->kcontrols[0], w, w->name); + if (codec->kcontrol_prefix) { + snprintf(prefixed_name, sizeof(prefixed_name), "%s.%s", + codec->kcontrol_prefix, w->name); + name = prefixed_name; + } else { + name = w->name; + } + kcontrol = snd_soc_cnew(&w->kcontrols[0], w, name); ret = snd_ctl_add(codec->card->snd_card, kcontrol); if (ret < 0) goto err; @@ -406,7 +422,7 @@ static int dapm_new_mux(struct snd_soc_codec *codec, return ret;
err: - printk(KERN_ERR "asoc: failed to add kcontrol %s\n", w->name); + printk(KERN_ERR "asoc: failed to add kcontrol %s\n", name); return ret; }
On Mon, Aug 16, 2010 at 10:29:30AM +0300, Jarkko Nikula wrote:
This optional kcontrol_prefix allows to specify unique prefix for ALSA control names for each DAI link. This makes possible to have a sound card configuration with multiple DAIs and each of them using the same codec driver without name collision.
This isn't going to work in general - consider what happens for CODECs with multiple DAIs, or for devices with no DAIs at all like external analogue amps. We do need to do this but it probably needs to be per CODEC rather than per link I fear.
On Mon, 16 Aug 2010 11:07:05 +0100 Mark Brown broonie@opensource.wolfsonmicro.com wrote:
On Mon, Aug 16, 2010 at 10:29:30AM +0300, Jarkko Nikula wrote:
This optional kcontrol_prefix allows to specify unique prefix for ALSA control names for each DAI link. This makes possible to have a sound card configuration with multiple DAIs and each of them using the same codec driver without name collision.
This isn't going to work in general - consider what happens for CODECs with multiple DAIs, or for devices with no DAIs at all like external analogue amps. We do need to do this but it probably needs to be per CODEC rather than per link I fear.
Yeah, true, this is not going to work if there are multiple amplifiers that are registered for a same link.
Multi-DAI codecs are not so clear to me. I thought codecs are exporting different controls for different DAIs? Like "foo Playback Volume" and "bar Playback Volume".
But anyway, I'll try to look some better idea.
On Mon, Aug 16, 2010 at 01:53:28PM +0300, Jarkko Nikula wrote:
Multi-DAI codecs are not so clear to me. I thought codecs are exporting different controls for different DAIs? Like "foo Playback Volume" and "bar Playback Volume".
No, consider CODECs which support mixing signals between the two DAIs like the WM9713 or WM8994. You will normally have some controls for the very edge of the CODEC but for at the parts of the CODEC after mixing there's no way to distinguish based on the DAI.
On Mon, 16 Aug 2010 12:09:03 +0100 Mark Brown broonie@opensource.wolfsonmicro.com wrote:
On Mon, Aug 16, 2010 at 01:53:28PM +0300, Jarkko Nikula wrote:
Multi-DAI codecs are not so clear to me. I thought codecs are exporting different controls for different DAIs? Like "foo Playback Volume" and "bar Playback Volume".
No, consider CODECs which support mixing signals between the two DAIs like the WM9713 or WM8994. You will normally have some controls for the very edge of the CODEC but for at the parts of the CODEC after mixing there's no way to distinguish based on the DAI.
Here's the work in progress version of this RFC before trying to patch all the drivers. Previous version wasn't enough at all.
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.
But core ideas are here how different drivers should call those functions:
Codec: - kcontrol prefix - no widget name prefix (as they are per codec) - no audio map prefix (as they are per codec)
Machine: - no kcontrol prefix (they are anyway machine specific) - no widget name prefix (they are anyway machine specific) - no audio map prefix (since this is includes both codec widgets with no prefixes and extra driver widgets with prefixes)
Extra driver, e.g. amplifier registered to a codec in machine driver: - kcontrol prefix (this must be different than codec->kcontrol_prefix) - widget name prefix (ditto) - audio map prefix (ditto)
So codec drivers would pass prefix to snd_soc_add_controls and NULL to snd_soc_dapm_new_controls and snd_soc_dapm_add_routes.
Machine drivers will pass NULL to all.
Extra drivers will pass some own prefix from machine driver to all of those functions so that multiple instances could be registered to same codec.
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.
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.
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?
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?
On Thu, 19 Aug 2010 18:20:49 +0300 Jarkko Nikula jhnikula@gmail.com wrote:
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?
Ok, this was easy. I added functions variants that take the prefix and that core calls also. So _snd_soc_add_controls, _snd_soc_dapm_new_control, _snd_soc_dapm_new_controls and _snd_soc_dapm_add_routes.
This way there is no need to patch all existing drivers and core can prefix nicely codec kcontrols based on codec->probed flag. Then external drivers can use those function variants by passing custom prefix that is different than codec->kcontrol_prefix.
No other changes from previous version. I.e. dai_link->kcontrol_prefix hack is still here.
On Fri, 20 Aug 2010 11:51:44 +0300 Jarkko Nikula jhnikula@gmail.com wrote:
On Thu, 19 Aug 2010 18:20:49 +0300 Jarkko Nikula jhnikula@gmail.com wrote:
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?
Ok, this was easy. I added functions variants that take the prefix and that core calls also. So _snd_soc_add_controls, _snd_soc_dapm_new_control, _snd_soc_dapm_new_controls and _snd_soc_dapm_add_routes.
This way there is no need to patch all existing drivers and core can prefix nicely codec kcontrols based on codec->probed flag. Then external drivers can use those function variants by passing custom prefix that is different than codec->kcontrol_prefix.
No other changes from previous version. I.e. dai_link->kcontrol_prefix hack is still here.
Here's the recent version.
I removed dai_link->kcontrol_prefix hack from this version, removed one unused spuriously added variable and added pointer to optional name prefix map into struct snd_soc_card that is used to associate prefix to codec.
So if there's a machine with two bar-codecs, following code associated prefix 'b' to kcontrols of second codec.
static struct snd_soc_prefix_map foo_codec_prefix[] = { { .codec_name = "bar-codec.2", .kcontrol_prefix = "b", }, };
static struct snd_soc_card foo_sound_card = { .name = "FOO, .dai_link = foo_dai, .num_links = ARRAY_SIZE(foo_dai), .prefix_map = foo_codec_prefix, .num_prefixes = ARRAY_SIZE(foo_codec_prefix), };
On Fri, Aug 20, 2010 at 11:51:44AM +0300, Jarkko Nikula wrote:
Jarkko Nikula jhnikula@gmail.com wrote:
+int _snd_soc_dapm_new_control(struct snd_soc_codec *codec,
- const struct snd_soc_dapm_widget *widget,
- const char *name_prefix);
int snd_soc_dapm_new_control(struct snd_soc_codec *codec, const struct snd_soc_dapm_widget *widget); +int _snd_soc_dapm_new_controls(struct snd_soc_codec *codec,
- const struct snd_soc_dapm_widget *widget,
- int num, const char *name_prefix);
Best not in the header; these are not things individual drivers should be worrying their pretty little heads about. If they should be used by individual drivers then we need better names than just _.
@@ -539,6 +543,7 @@ struct snd_soc_dai_link { const char *platform_name; /* for multi-platform */ const char *cpu_dai_name; const char *codec_dai_name;
const char *kcontrol_prefix; /* kcontrol prefix for multi-codec */
/* Keep DAI active over suspend */ unsigned int ignore_suspend:1;
I don't see how a DAI link can ever be used to configure prefix names - there's just not any real association between DAI links and controls, and as soon as you hit mixing any that does exist gets lost. Probably a table of CODEC to prefix mappings would be better.
if (codec->kcontrol_prefix && !w->prefixed) {name_len += 1 + strlen(codec->kcontrol_prefix);snprintf(prefix, sizeof(prefix), "%s.",codec->kcontrol_prefix);
A space would probably be more idiomatic for the separator.
+int _snd_soc_dapm_add_routes(struct snd_soc_codec *codec,
const struct snd_soc_dapm_route *route, int num,const char *name_prefix){ int i, ret;
for (i = 0; i < num; i++) {
ret = snd_soc_dapm_add_route(codec, route);
ret = snd_soc_dapm_add_route(codec, route, name_prefix);
This one is a bit more fun. For this to work properly we need to consider what happens with the cross-device links in the DAI maps which means we need to able to cope with separate prefixes for the source and the sink.
On Mon, 23 Aug 2010 16:21:45 +0100 Mark Brown broonie@opensource.wolfsonmicro.com wrote:
+int _snd_soc_dapm_new_controls(struct snd_soc_codec *codec,
- const struct snd_soc_dapm_widget *widget,
- int num, const char *name_prefix);
Best not in the header; these are not things individual drivers should be worrying their pretty little heads about. If they should be used by individual drivers then we need better names than just _.
Yeah, I picked up _ prefix so that name indicates that these functions are more like for internal use and drivers should use them only exceptionally. What I'm thinking if we can rid of them completely.
_From your commit 26b01cc it looks like there's a work in progress to support DAI-less codecs/amplifiers. If that would be possible then there is no need to register controls from other drivers in machine DAI init. Well, CPU DAI controls are possible but they don't need a prefix I think.
@@ -539,6 +543,7 @@ struct snd_soc_dai_link { const char *platform_name; /* for multi-platform */ const char *cpu_dai_name; const char *codec_dai_name;
const char *kcontrol_prefix; /* kcontrol prefix for multi-codec */
/* Keep DAI active over suspend */ unsigned int ignore_suspend:1;
I don't see how a DAI link can ever be used to configure prefix names - there's just not any real association between DAI links and controls, and as soon as you hit mixing any that does exist gets lost. Probably a table of CODEC to prefix mappings would be better.
Sorry, I didn't emphasis this well enough that this hack was temporary just after your comment to first version and it got finally removed in yesterday's version :-)
if (codec->kcontrol_prefix && !w->prefixed) {name_len += 1 + strlen(codec->kcontrol_prefix);snprintf(prefix, sizeof(prefix), "%s.",codec->kcontrol_prefix);A space would probably be more idiomatic for the separator.
Ok, makes sense.
+int _snd_soc_dapm_add_routes(struct snd_soc_codec *codec,
const struct snd_soc_dapm_route *route, int num,const char *name_prefix){ int i, ret;
for (i = 0; i < num; i++) {
ret = snd_soc_dapm_add_route(codec, route);
ret = snd_soc_dapm_add_route(codec, route, name_prefix);This one is a bit more fun. For this to work properly we need to consider what happens with the cross-device links in the DAI maps which means we need to able to cope with separate prefixes for the source and the sink.
Prefixing is not problem I think since we can specify them in machine's audio map (like two mono amplifiers registered to 1st codec are prefixed below) but how to link DAPMs of two codec together?
static const struct snd_soc_dapm_route audio_map1[] = { {"Left AMP input", NULL, "LLOUT"}, {"Right AMP input, NULL, "RLOUT"}, {"Speaker", NULL, "Left AMP output"}, {"Speaker, NULL, "Right AMP output"},
{"Codec B Left input"}, NULL, "LLOUT"}, {"Codec B Right input"}, NULL, "RLOUT"}, };
static const struct snd_soc_dapm_route audio_map2[] = { {"foo bar", NULL, "Codec B Left input"}, {"foo bar", NULL, "Codec B Right input"}, };
On Tue, Aug 24, 2010 at 10:23:43AM +0300, Jarkko Nikula wrote:
Mark Brown broonie@opensource.wolfsonmicro.com wrote:
Best not in the header; these are not things individual drivers should be worrying their pretty little heads about. If they should be used by individual drivers then we need better names than just _.
Yeah, I picked up _ prefix so that name indicates that these functions are more like for internal use and drivers should use them only exceptionally. What I'm thinking if we can rid of them completely.
I figured.
From your commit 26b01cc it looks like there's a work in progress to support DAI-less codecs/amplifiers. If that would be possible then there is no need to register controls from other drivers in machine DAI
DAIless devices should work already.
init. Well, CPU DAI controls are possible but they don't need a prefix I think.
There might be an issue disambiguating against collisions with other drivers in the system, I guess.
I don't see how a DAI link can ever be used to configure prefix names - there's just not any real association between DAI links and controls, and as soon as you hit mixing any that does exist gets lost. Probably a table of CODEC to prefix mappings would be better.
Sorry, I didn't emphasis this well enough that this hack was temporary just after your comment to first version and it got finally removed in yesterday's version :-)
Yeah, I was writing my reply as you sent that.
This one is a bit more fun. For this to work properly we need to consider what happens with the cross-device links in the DAI maps which means we need to able to cope with separate prefixes for the source and the sink.
Prefixing is not problem I think since we can specify them in machine's audio map (like two mono amplifiers registered to 1st codec are prefixed below) but how to link DAPMs of two codec together?
We'll be fine just using the prefixed name in the machine drivers I think and not advertising the prefix-adding route add function.
On Tue, 24 Aug 2010 11:10:32 +0100 Mark Brown broonie@opensource.wolfsonmicro.com wrote:
DAIless devices should work already.
...
We'll be fine just using the prefixed name in the machine drivers I think and not advertising the prefix-adding route add function.
I went back to original idea that prefixes only kcontrols of codec and doesn't add any new API. So if we can have DAIless codec drivers (i.e. amplifiers) then there is no immediate need for prefixing widgets and routes.
Cross-device links and DAPM between them remains unsolved as this tries to solve only kcontrol name issue with multiple codecs only.
On Wed, Aug 25, 2010 at 01:59:22PM +0300, Jarkko Nikula wrote:
I went back to original idea that prefixes only kcontrols of codec and doesn't add any new API. So if we can have DAIless codec drivers (i.e. amplifiers) then there is no immediate need for prefixing widgets and routes.
Note that even DAIless drivers can have routing in them - see WM9090 for example.
Cross-device links and DAPM between them remains unsolved as this tries to solve only kcontrol name issue with multiple codecs only.
I really think anything along these lines needs to handle DAPM somehow - given that virtually every driver has DAPM support of some kind and there are some fairly standard pin names for things it's likely that you'll get the same issues there.
On Thu, 26 Aug 2010 14:32:29 +0100 Mark Brown broonie@opensource.wolfsonmicro.com wrote:
On Wed, Aug 25, 2010 at 01:59:22PM +0300, Jarkko Nikula wrote:
I went back to original idea that prefixes only kcontrols of codec and doesn't add any new API. So if we can have DAIless codec drivers (i.e. amplifiers) then there is no immediate need for prefixing widgets and routes.
Note that even DAIless drivers can have routing in them - see WM9090 for example.
I don't see it are there any problems. For me it looks the routes in WM9090 are unique and registered to own codec instance so there should not be route prefixing needed.
How these amplifier drivers are actually meant to be probed? Currently struct snd_soc_codec_driver->probe is called only from soc_probe_dai_link.
On Mon, Aug 30, 2010 at 02:17:29PM +0300, Jarkko Nikula wrote:
I don't see it are there any problems. For me it looks the routes in WM9090 are unique and registered to own codec instance so there should not be route prefixing needed.
Meh, right. DAPM isn't coping with things that cross CODECs really. This will need to be looked at.
How these amplifier drivers are actually meant to be probed? Currently struct snd_soc_codec_driver->probe is called only from soc_probe_dai_link.
We need to set up a list of anciliary devices which are registered without DAIs for this.
On Thu, 2 Sep 2010 15:25:18 +0100 Mark Brown broonie@opensource.wolfsonmicro.com wrote:
On Mon, Aug 30, 2010 at 02:17:29PM +0300, Jarkko Nikula wrote:
I don't see it are there any problems. For me it looks the routes in WM9090 are unique and registered to own codec instance so there should not be route prefixing needed.
Meh, right. DAPM isn't coping with things that cross CODECs really. This will need to be looked at.
How these amplifier drivers are actually meant to be probed? Currently struct snd_soc_codec_driver->probe is called only from soc_probe_dai_link.
We need to set up a list of anciliary devices which are registered without DAIs for this.
So we need to split these into three separate problems:
- Prefixing - DAPM linking between codecs - Registering DAIless codecs in machine drivers
What you think: is it better to hold my prefixing patch until DAPM linking is solved or can it be applied before? I mean if we need to go some global, not codec based DAPM, then there is need to prefix but not if DAPM remains per codec.
On Fri, Sep 03, 2010 at 10:55:32AM +0300, Jarkko Nikula wrote:
So we need to split these into three separate problems:
- Prefixing
- DAPM linking between codecs
- Registering DAIless codecs in machine drivers
What you think: is it better to hold my prefixing patch until DAPM linking is solved or can it be applied before? I mean if we need to go some global, not codec based DAPM, then there is need to prefix but not if DAPM remains per codec.
Well, the DAPM map needs to be global in some sense since it needs to flow between CODECs and we need board widgets which are definitely not fixed on an individual chip.
I think I'd like a firm idea of how the cross device DAPM works before we do anything with the prefixes since there's some overlap there (if only due to the fact that half the controls come from DAPM), even if the cross device DAPM doesn't actually work yet. I think your current code is probably going to work well with DAPM but I need to have a bit of a think about that over the weekend.
On Fri, 2010-09-03 at 10:33 +0100, Mark Brown wrote:
On Fri, Sep 03, 2010 at 10:55:32AM +0300, Jarkko Nikula wrote:
So we need to split these into three separate problems:
- Prefixing
- DAPM linking between codecs
- Registering DAIless codecs in machine drivers
What you think: is it better to hold my prefixing patch until DAPM linking is solved or can it be applied before? I mean if we need to go some global, not codec based DAPM, then there is need to prefix but not if DAPM remains per codec.
Well, the DAPM map needs to be global in some sense since it needs to flow between CODECs and we need board widgets which are definitely not fixed on an individual chip.
I think I'd like a firm idea of how the cross device DAPM works before we do anything with the prefixes since there's some overlap there (if only due to the fact that half the controls come from DAPM), even if the cross device DAPM doesn't actually work yet. I think your current code is probably going to work well with DAPM but I need to have a bit of a think about that over the weekend.
I've made some initial progress here with DAPM by de-coupling it from CODEC drivers. So I now have a struct dapm_context * in the codec, platform and machine drivers. I just now need to get some time to experiment with the best way to hook them all up.
It's currently in my L24.9 branch, although the patches are in need of clean up and squashing so are not ready for upstream yet.
Liam
On Fri, 03 Sep 2010 11:00:57 +0100 Liam Girdwood lrg@slimlogic.co.uk wrote:
I think I'd like a firm idea of how the cross device DAPM works before we do anything with the prefixes since there's some overlap there (if only due to the fact that half the controls come from DAPM), even if the cross device DAPM doesn't actually work yet. I think your current code is probably going to work well with DAPM but I need to have a bit of a think about that over the weekend.
Ok, sounds good. Doing DAPM first avoids that there is no then need to go back and forth with prefixing.
I've made some initial progress here with DAPM by de-coupling it from CODEC drivers. So I now have a struct dapm_context * in the codec, platform and machine drivers. I just now need to get some time to experiment with the best way to hook them all up.
It's currently in my L24.9 branch, although the patches are in need of clean up and squashing so are not ready for upstream yet.
Thanks for info. Have to give a try to it :-)
participants (3)
-
Jarkko Nikula -
Liam Girdwood -
Mark Brown