Re: [alsa-devel] [PATCH 2/3] ASoC: core: Set the default I/O up try regmap.
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. signature.asc Description: Digital signature
Re: [alsa-devel] [PATCH 2/3] ASoC: core: Set the default I/O up try regmap.
On 02/28/2014 08:50 AM, li.xi...@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. 1143 sound/soc/codecs/cq93vc.c <> snd_soc_codec_set_cache_io(codec, 32, 32, SND_SOC_REGMAP); 2618 sound/soc/codecs/mc13783.c <> ret = snd_soc_codec_set_cache_io(codec, 8, 24, SND_SOC_REGMAP); 3 1765 sound/soc/codecs/wm5102.c <> ret = snd_soc_codec_set_cache_io(codec, 32, 16, SND_SOC_REGMAP); 4 1593 sound/soc/codecs/wm5110.c <> ret = snd_soc_codec_set_cache_io(codec, 32, 16, SND_SOC_REGMAP); 5 1510 sound/soc/codecs/wm8350.c <> snd_soc_codec_set_cache_io(codec, 8, 16, SND_SOC_REGMAP); 6 1322 sound/soc/codecs/wm8400.c <> snd_soc_codec_set_cache_io(codec, 8, 16, SND_SOC_REGMAP); 7 4004 sound/soc/codecs/wm8994.c <> snd_soc_codec_set_cache_io(codec, 16, 16, SND_SOC_REGMAP); 8 1058 sound/soc/codecs/wm8997.c <> 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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [alsa-devel] [PATCH 2/3] ASoC: core: Set the default I/O up try regmap.
> > 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. 1143 sound/soc/codecs/cq93vc.c <> snd_soc_codec_set_cache_io(codec, 32, 32, SND_SOC_REGMAP); 2618 sound/soc/codecs/mc13783.c <> ret = snd_soc_codec_set_cache_io(codec, 8, 24, SND_SOC_REGMAP); 3 1765 sound/soc/codecs/wm5102.c <> ret = snd_soc_codec_set_cache_io(codec, 32, 16, SND_SOC_REGMAP); 4 1593 sound/soc/codecs/wm5110.c <> ret = snd_soc_codec_set_cache_io(codec, 32, 16, SND_SOC_REGMAP); 5 1510 sound/soc/codecs/wm8350.c <> snd_soc_codec_set_cache_io(codec, 8, 16, SND_SOC_REGMAP); 6 1322 sound/soc/codecs/wm8400.c <> snd_soc_codec_set_cache_io(codec, 8, 16, SND_SOC_REGMAP); 7 4004 sound/soc/codecs/wm8994.c <> snd_soc_codec_set_cache_io(codec, 16, 16, SND_SOC_REGMAP); 8 1058 sound/soc/codecs/wm8997.c <> ret = snd_soc_codec_set_cache_io(codec, 32, 16, SND_SOC_REGMAP); Thanks, -- Best regards, Xiubo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [alsa-devel] [PATCH 2/3] ASoC: core: Set the default I/O up try regmap.
> > 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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [alsa-devel] [PATCH 2/3] ASoC: core: Set the default I/O up try regmap.
On 02/28/2014 08:08 AM, li.xi...@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 +, li.xi...@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. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [alsa-devel] [PATCH 2/3] ASoC: core: Set the default I/O up try regmap.
> Subject: Re: [PATCH 2/3] ASoC: core: Set the default I/O up try regmap. > > On Fri, Feb 28, 2014 at 04:00:38AM +, li.xi...@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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [alsa-devel] [PATCH 2/3] ASoC: core: Set the default I/O up try regmap.
On 02/28/2014 07:40 AM, li.xi...@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.xi...@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 +, li.xi...@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. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [alsa-devel] [PATCH 2/3] ASoC: core: Set the default I/O up try regmap.
> 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.xi...@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 +, li.xi...@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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [alsa-devel] [PATCH 2/3] ASoC: core: Set the default I/O up try regmap.
On 02/28/2014 06:56 AM, li.xi...@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 +, li.xi...@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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
