| Message ID | 1393494593-26310-3-git-send-email-Li.Xiubo@freescale.com (mailing list archive) |
|---|---|
| State | Accepted |
| Commit | fe2265e4833a3ebea426d748b5ecf8d3ff31edc8 |
| Headers | show |
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.
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);
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(-)