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(-)
--
1.8.4
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 <[email protected]>
---
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 */
--
1.8.4
Signed-off-by: Xiubo Li <[email protected]>
---
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;
--
1.8.4
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 <[email protected]>
---
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);
--
1.8.4
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.
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.
On Thu, Feb 27, 2014 at 05:49:53PM +0800, Xiubo Li wrote:
> Signed-off-by: Xiubo Li <[email protected]>
Applied, thanks.
> 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, [email protected] 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, [email protected] 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, [email protected] 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, [email protected] 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, [email protected] 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, [email protected] 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, [email protected] 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, [email protected] 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, [email protected] 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, [email protected] 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, [email protected] 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, [email protected] 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, [email protected] 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.