[2/3] ASoC: core: Set the default I/O up try regmap.
diff mbox

Message ID 1393494593-26310-3-git-send-email-Li.Xiubo@freescale.com
State Accepted
Commit fe2265e4833a3ebea426d748b5ecf8d3ff31edc8
Headers show

Commit Message

Xiubo Li Feb. 27, 2014, 9:49 a.m. UTC
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(-)

Comments

Mark Brown Feb. 28, 2014, 3:52 a.m. UTC | #1
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.
Xiubo Li Feb. 28, 2014, 4 a.m. UTC | #2
> 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
Mark Brown Feb. 28, 2014, 5:29 a.m. UTC | #3
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.
Xiubo Li Feb. 28, 2014, 5:56 a.m. UTC | #4
> 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
Lars-Peter Clausen Feb. 28, 2014, 6:38 a.m. UTC | #5
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
Xiubo Li Feb. 28, 2014, 6:40 a.m. UTC | #6
> 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
Lars-Peter Clausen Feb. 28, 2014, 6:46 a.m. UTC | #7
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.
Xiubo Li Feb. 28, 2014, 7:08 a.m. UTC | #8
> >>>> 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
Lars-Peter Clausen Feb. 28, 2014, 7:15 a.m. UTC | #9
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.
Xiubo Li Feb. 28, 2014, 7:18 a.m. UTC | #10
> 
> 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
Xiubo Li Feb. 28, 2014, 7:50 a.m. UTC | #11
> 
> 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
Lars-Peter Clausen Feb. 28, 2014, 8:15 a.m. UTC | #12
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
Mark Brown March 1, 2014, 4:07 a.m. UTC | #13
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.

Patch
diff mbox

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);