[alsa-devel] [PATCH 0/3] To simplify the code for ASoC probe.
Xiubo Li (3): ASoC: io: Clean up snd_soc_codec_set_cache_io() ASoC: core: Set the default I/O up try regmap. ASoC: SGTL5000: Simplify ASoC probe code.
sound/soc/codecs/sgtl5000.c | 8 -------- sound/soc/soc-core.c | 8 ++++---- sound/soc/soc-io.c | 5 ----- 3 files changed, 4 insertions(+), 17 deletions(-)
Now that all users have been converted to regmap and the config.reg_bits and config.val_bits can be setted by each user through regmap core API. So these two params are redundant here.
Signed-off-by: Xiubo Li Li.Xiubo@freescale.com --- sound/soc/soc-io.c | 5 ----- 1 file changed, 5 deletions(-)
diff --git a/sound/soc/soc-io.c b/sound/soc/soc-io.c index add99e2..18353f1 100644 --- a/sound/soc/soc-io.c +++ b/sound/soc/soc-io.c @@ -88,16 +88,11 @@ int snd_soc_codec_set_cache_io(struct snd_soc_codec *codec, int addr_bits, int data_bits, enum snd_soc_control_type control) { - struct regmap_config config; int ret;
- memset(&config, 0, sizeof(config)); codec->write = hw_write; codec->read = hw_read;
- config.reg_bits = addr_bits; - config.val_bits = data_bits; - switch (control) { case SND_SOC_REGMAP: /* Device has made its own regmap arrangements */
On Thu, Feb 27, 2014 at 05:49:51PM +0800, Xiubo Li wrote:
Now that all users have been converted to regmap and the config.reg_bits and config.val_bits can be setted by each user through regmap core API. So these two params are redundant here.
Applied, thanks.
For most CODEC drivers which the REGMAP is used, the soc_probe_codec() will do the stuff work of snd_soc_codec_set_cache_io(), which the CODEC drivers' ASoC probe will do too, and almost at the same time.
This patch set the default I/O up try regmap, and then the CODEC drivers' stuff work of snd_soc_codec_set_cache_io() will be redundant, while if one CODEC driver needed to set it's own I/O, then it can rewrite the default ones. Then could we just discard the snd_soc_codec_set_cache_io() from the CODEC drivers' ASoC probe to simplify the code.
Signed-off-by: Xiubo Li Li.Xiubo@freescale.com --- sound/soc/soc-core.c | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/sound/soc/soc-core.c b/sound/soc/soc-core.c index e5a535b..c159a34 100644 --- a/sound/soc/soc-core.c +++ b/sound/soc/soc-core.c @@ -1137,6 +1137,10 @@ static int soc_probe_codec(struct snd_soc_card *card,
codec->dapm.idle_bias_off = driver->idle_bias_off;
+ /* Set the default I/O up try regmap */ + if (dev_get_regmap(codec->dev, NULL)) + snd_soc_codec_set_cache_io(codec, 0, 0, SND_SOC_REGMAP); + if (driver->probe) { ret = driver->probe(codec); if (ret < 0) { @@ -1150,10 +1154,6 @@ static int soc_probe_codec(struct snd_soc_card *card, codec->name); }
- /* If the driver didn't set I/O up try regmap */ - if (!codec->write && dev_get_regmap(codec->dev, NULL)) - snd_soc_codec_set_cache_io(codec, 0, 0, SND_SOC_REGMAP); - if (driver->controls) snd_soc_add_codec_controls(codec, driver->controls, driver->num_controls);
On Thu, Feb 27, 2014 at 05:49:52PM +0800, Xiubo Li wrote:
For most CODEC drivers which the REGMAP is used, the soc_probe_codec() will do the stuff work of snd_soc_codec_set_cache_io(), which the CODEC drivers' ASoC probe will do too, and almost at the same time.
Applied, thanks. I did a check of the drivers and it looks like they'll all be fine with this.
Subject: Re: [PATCH 2/3] ASoC: core: Set the default I/O up try regmap.
On Thu, Feb 27, 2014 at 05:49:52PM +0800, Xiubo Li wrote:
For most CODEC drivers which the REGMAP is used, the soc_probe_codec() will do the stuff work of snd_soc_codec_set_cache_io(), which the CODEC drivers' ASoC probe will do too, and almost at the same time.
Applied, thanks. I did a check of the drivers and it looks like they'll all be fine with this.
Yes.
I'll send another patches to applied to use this for another CODEC drivers. And there almost 80 files, Should I send them in one patch or split them into individual patch for each CODEC driver ?
Thanks,
-- Best Regards, Xiubo
On Fri, Feb 28, 2014 at 04:00:38AM +0000, Li.Xiubo@freescale.com wrote:
I'll send another patches to applied to use this for another CODEC drivers. And there almost 80 files, Should I send them in one patch or split them into individual patch for each CODEC driver ?
I'd suggest doing one patch that covers the boring drivers where the first thing they do is call set_cache_io() but split out the others into one patch per driver since the need more examination.
Subject: Re: [PATCH 2/3] ASoC: core: Set the default I/O up try regmap.
On Fri, Feb 28, 2014 at 04:00:38AM +0000, Li.Xiubo@freescale.com wrote:
I'll send another patches to applied to use this for another CODEC drivers. And there almost 80 files, Should I send them in one patch or split them
into
individual patch for each CODEC driver ?
I'd suggest doing one patch that covers the boring drivers where the first thing they do is call set_cache_io() but split out the others into one patch per driver since the need more examination.
Got it.
Thanks,
-- Best Regards, Xiubo
On 02/28/2014 06:56 AM, Li.Xiubo@freescale.com wrote:
Subject: Re: [PATCH 2/3] ASoC: core: Set the default I/O up try regmap.
On Fri, Feb 28, 2014 at 04:00:38AM +0000, Li.Xiubo@freescale.com wrote:
I'll send another patches to applied to use this for another CODEC drivers. And there almost 80 files, Should I send them in one patch or split them
into
individual patch for each CODEC driver ?
I'd suggest doing one patch that covers the boring drivers where the first thing they do is call set_cache_io() but split out the others into one patch per driver since the need more examination.
Got it.
Btw. be careful, just removing the set_cache_io() call will not work for all drivers. There are some MFD child devices which use regmap from the parent device. So dev_get_regmap() will return NULL for those.
- Lars
Subject: Re: [alsa-devel] [PATCH 2/3] ASoC: core: Set the default I/O up try regmap.
On 02/28/2014 06:56 AM, Li.Xiubo@freescale.com wrote:
Subject: Re: [PATCH 2/3] ASoC: core: Set the default I/O up try regmap.
On Fri, Feb 28, 2014 at 04:00:38AM +0000, Li.Xiubo@freescale.com wrote:
I'll send another patches to applied to use this for another CODEC drivers. And there almost 80 files, Should I send them in one patch or split them
into
individual patch for each CODEC driver ?
I'd suggest doing one patch that covers the boring drivers where the first thing they do is call set_cache_io() but split out the others into one patch per driver since the need more examination.
Got it.
Btw. be careful, just removing the set_cache_io() call will not work for all drivers. There are some MFD child devices which use regmap from the parent device. So dev_get_regmap() will return NULL for those.
@Lars,
Do you mean the CODEC drivers like wm5110 and wm8997 ?
Thanks,
-- Best Regards, Xiubo
On 02/28/2014 07:40 AM, Li.Xiubo@freescale.com wrote:
Subject: Re: [alsa-devel] [PATCH 2/3] ASoC: core: Set the default I/O up try regmap.
On 02/28/2014 06:56 AM, Li.Xiubo@freescale.com wrote:
Subject: Re: [PATCH 2/3] ASoC: core: Set the default I/O up try regmap.
On Fri, Feb 28, 2014 at 04:00:38AM +0000, Li.Xiubo@freescale.com wrote:
I'll send another patches to applied to use this for another CODEC drivers. And there almost 80 files, Should I send them in one patch or split them
into
individual patch for each CODEC driver ?
I'd suggest doing one patch that covers the boring drivers where the first thing they do is call set_cache_io() but split out the others into one patch per driver since the need more examination.
Got it.
Btw. be careful, just removing the set_cache_io() call will not work for all drivers. There are some MFD child devices which use regmap from the parent device. So dev_get_regmap() will return NULL for those.
@Lars,
Do you mean the CODEC drivers like wm5110 and wm8997 ?
Yes.
Subject: Re: [PATCH 2/3] ASoC: core: Set the default I/O up try regmap.
On Fri, Feb 28, 2014 at 04:00:38AM +0000, Li.Xiubo@freescale.com wrote:
I'll send another patches to applied to use this for another CODEC
drivers.
And there almost 80 files, Should I send them in one patch or split them
into
individual patch for each CODEC driver ?
I'd suggest doing one patch that covers the boring drivers where the first thing they do is call set_cache_io() but split out the others into one patch per driver since the need more examination.
Got it.
Btw. be careful, just removing the set_cache_io() call will not work for
all
drivers. There are some MFD child devices which use regmap from the parent device. So dev_get_regmap() will return NULL for those.
@Lars,
Do you mean the CODEC drivers like wm5110 and wm8997 ?
Yes.
I only found these two CODEC drivers using MFD who would get its parent's regmap.
Has I missed some ?
Thanks,
Best Regards, Xiubo
On 02/28/2014 08:08 AM, Li.Xiubo@freescale.com wrote:
Subject: Re: [PATCH 2/3] ASoC: core: Set the default I/O up try regmap.
On Fri, Feb 28, 2014 at 04:00:38AM +0000, Li.Xiubo@freescale.com wrote:
> I'll send another patches to applied to use this for another CODEC
drivers.
> And there almost 80 files, Should I send them in one patch or split them into > individual patch for each CODEC driver ?
I'd suggest doing one patch that covers the boring drivers where the first thing they do is call set_cache_io() but split out the others into one patch per driver since the need more examination.
Got it.
Btw. be careful, just removing the set_cache_io() call will not work for
all
drivers. There are some MFD child devices which use regmap from the parent device. So dev_get_regmap() will return NULL for those.
@Lars,
Do you mean the CODEC drivers like wm5110 and wm8997 ?
Yes.
I only found these two CODEC drivers using MFD who would get its parent's regmap.
Has I missed some ?
A quick grep reveals: mc13783.c: codec->control_data = dev_get_regmap(codec->dev->parent, NULL); si476x.c: codec->control_data = dev_get_regmap(codec->dev->parent, NULL); wm5102.c: codec->control_data = priv->core.arizona->regmap; wm5110.c: codec->control_data = priv->core.arizona->regmap; wm8997.c: codec->control_data = priv->core.arizona->regmap;
But there might be more.
A quick grep reveals: mc13783.c: codec->control_data = dev_get_regmap(codec->dev->parent, NULL); si476x.c: codec->control_data = dev_get_regmap(codec->dev->parent, NULL); wm5102.c: codec->control_data = priv->core.arizona->regmap; wm5110.c: codec->control_data = priv->core.arizona->regmap; wm8997.c: codec->control_data = priv->core.arizona->regmap;
But there might be more.
Yes, I'll check it more carefully...
Thanks very much.
Best Regards, Xiubo
A quick grep reveals: mc13783.c: codec->control_data = dev_get_regmap(codec->dev->parent, NULL); si476x.c: codec->control_data = dev_get_regmap(codec->dev->parent, NULL); wm5102.c: codec->control_data = priv->core.arizona->regmap; wm5110.c: codec->control_data = priv->core.arizona->regmap; wm8997.c: codec->control_data = priv->core.arizona->regmap;
But there might be more.
I have found the following ones, who are using MFD & set_cache_io.
1 143 sound/soc/codecs/cq93vc.c <<cq93vc_probe>> snd_soc_codec_set_cache_io(codec, 32, 32, SND_SOC_REGMAP); 2 618 sound/soc/codecs/mc13783.c <<mc13783_probe>> ret = snd_soc_codec_set_cache_io(codec, 8, 24, SND_SOC_REGMAP); 3 1765 sound/soc/codecs/wm5102.c <<wm5102_codec_probe>> ret = snd_soc_codec_set_cache_io(codec, 32, 16, SND_SOC_REGMAP); 4 1593 sound/soc/codecs/wm5110.c <<wm5110_codec_probe>> ret = snd_soc_codec_set_cache_io(codec, 32, 16, SND_SOC_REGMAP); 5 1510 sound/soc/codecs/wm8350.c <<wm8350_codec_probe>> snd_soc_codec_set_cache_io(codec, 8, 16, SND_SOC_REGMAP); 6 1322 sound/soc/codecs/wm8400.c <<wm8400_codec_probe>> snd_soc_codec_set_cache_io(codec, 8, 16, SND_SOC_REGMAP); 7 4004 sound/soc/codecs/wm8994.c <<wm8994_codec_probe>> snd_soc_codec_set_cache_io(codec, 16, 16, SND_SOC_REGMAP); 8 1058 sound/soc/codecs/wm8997.c <<wm8997_codec_probe>> ret = snd_soc_codec_set_cache_io(codec, 32, 16, SND_SOC_REGMAP);
Thanks,
-- Best regards, Xiubo
On 02/28/2014 08:50 AM, Li.Xiubo@freescale.com wrote:
A quick grep reveals: mc13783.c: codec->control_data = dev_get_regmap(codec->dev->parent, NULL); si476x.c: codec->control_data = dev_get_regmap(codec->dev->parent, NULL); wm5102.c: codec->control_data = priv->core.arizona->regmap; wm5110.c: codec->control_data = priv->core.arizona->regmap; wm8997.c: codec->control_data = priv->core.arizona->regmap;
But there might be more.
I have found the following ones, who are using MFD & set_cache_io.
1 143 sound/soc/codecs/cq93vc.c <<cq93vc_probe>> snd_soc_codec_set_cache_io(codec, 32, 32, SND_SOC_REGMAP); 2 618 sound/soc/codecs/mc13783.c <<mc13783_probe>> ret = snd_soc_codec_set_cache_io(codec, 8, 24, SND_SOC_REGMAP); 3 1765 sound/soc/codecs/wm5102.c <<wm5102_codec_probe>> ret = snd_soc_codec_set_cache_io(codec, 32, 16, SND_SOC_REGMAP); 4 1593 sound/soc/codecs/wm5110.c <<wm5110_codec_probe>> ret = snd_soc_codec_set_cache_io(codec, 32, 16, SND_SOC_REGMAP); 5 1510 sound/soc/codecs/wm8350.c <<wm8350_codec_probe>> snd_soc_codec_set_cache_io(codec, 8, 16, SND_SOC_REGMAP); 6 1322 sound/soc/codecs/wm8400.c <<wm8400_codec_probe>> snd_soc_codec_set_cache_io(codec, 8, 16, SND_SOC_REGMAP); 7 4004 sound/soc/codecs/wm8994.c <<wm8994_codec_probe>> snd_soc_codec_set_cache_io(codec, 16, 16, SND_SOC_REGMAP); 8 1058 sound/soc/codecs/wm8997.c <<wm8997_codec_probe>> ret = snd_soc_codec_set_cache_io(codec, 32, 16, SND_SOC_REGMAP);
Yes, I think that's almost all of them. si476x is missing, but I think that one is currently broken, as it doesn't call snd_soc_codec_set_cache_io() at all.
As to how to handle those, I think there was a plan to add the possibility to assign a regmap to a device, so that dev_get_regmap() returns the regmap struct that should be used, even though the device itself did not allocate the regmap. But I can't find the details. Mark may know more about this.
- Lars
On Fri, Feb 28, 2014 at 09:15:37AM +0100, Lars-Peter Clausen wrote:
Yes, I think that's almost all of them. si476x is missing, but I think that one is currently broken, as it doesn't call snd_soc_codec_set_cache_io() at all.
Probably, yeah - there were other problems with that driver that make me question if it ever worked properly IIRC. There is a default call to set cache I/O already but it relies on dev_get_regmap().
As to how to handle those, I think there was a plan to add the possibility to assign a regmap to a device, so that dev_get_regmap() returns the regmap struct that should be used, even though the device itself did not allocate the regmap. But I can't find the details. Mark may know more about this.
That's not for this and is likely to create confusion - that's for handling early init with syscon type devices, allowing the regmap to be created with no device and then have the device attached later. I'd need to look through and see what happens if two devices share a regmap, perhaps it'd actually be OK, but we can always just allow the regmap to be overridden at the ASoC level.
Signed-off-by: Xiubo Li Li.Xiubo@freescale.com --- sound/soc/codecs/sgtl5000.c | 8 -------- 1 file changed, 8 deletions(-)
diff --git a/sound/soc/codecs/sgtl5000.c b/sound/soc/codecs/sgtl5000.c index ab4754a..d3ed1be 100644 --- a/sound/soc/codecs/sgtl5000.c +++ b/sound/soc/codecs/sgtl5000.c @@ -1352,14 +1352,6 @@ static int sgtl5000_probe(struct snd_soc_codec *codec) int ret; struct sgtl5000_priv *sgtl5000 = snd_soc_codec_get_drvdata(codec);
- /* setup i2c data ops */ - codec->control_data = sgtl5000->regmap; - ret = snd_soc_codec_set_cache_io(codec, 16, 16, SND_SOC_REGMAP); - if (ret < 0) { - dev_err(codec->dev, "Failed to set cache I/O: %d\n", ret); - return ret; - } - ret = sgtl5000_enable_regulators(codec); if (ret) return ret;
On Thu, Feb 27, 2014 at 05:49:53PM +0800, Xiubo Li wrote:
Signed-off-by: Xiubo Li Li.Xiubo@freescale.com
Applied, thanks.
participants (4)
-
Lars-Peter Clausen -
Li.Xiubo＠freescale.com -
Mark Brown -
Xiubo Li