The WM8994_MICBIAS register is not available in the WM1811 CODEC so skip
initialization of that register for that device.
This suppresses an error during boot:
"wm8994-codec: ASoC: error at snd_soc_component_update_bits on wm8994-codec"
Signed-off-by: Sylwester Nawrocki <[email protected]>
---
sound/soc/codecs/wm8994.c | 2 ++
sound/soc/codecs/wm_hubs.c | 3 +++
sound/soc/codecs/wm_hubs.h | 1 +
3 files changed, 6 insertions(+)
diff --git a/sound/soc/codecs/wm8994.c b/sound/soc/codecs/wm8994.c
index 038be66..b3ba053 100644
--- a/sound/soc/codecs/wm8994.c
+++ b/sound/soc/codecs/wm8994.c
@@ -4193,11 +4193,13 @@ static int wm8994_component_probe(struct snd_soc_component *component)
wm8994->hubs.dcs_readback_mode = 2;
break;
}
+ wm8994->hubs.micd_scthr = true;
break;
case WM8958:
wm8994->hubs.dcs_readback_mode = 1;
wm8994->hubs.hp_startup_mode = 1;
+ wm8994->hubs.micd_scthr = true;
switch (control->revision) {
case 0:
diff --git a/sound/soc/codecs/wm_hubs.c b/sound/soc/codecs/wm_hubs.c
index 891effe..0c88184 100644
--- a/sound/soc/codecs/wm_hubs.c
+++ b/sound/soc/codecs/wm_hubs.c
@@ -1223,6 +1223,9 @@ int wm_hubs_handle_analogue_pdata(struct snd_soc_component *component,
snd_soc_component_update_bits(component, WM8993_ADDITIONAL_CONTROL,
WM8993_LINEOUT2_FB, WM8993_LINEOUT2_FB);
+ if (!hubs->micd_scthr)
+ return 0;
+
snd_soc_component_update_bits(component, WM8993_MICBIAS,
WM8993_JD_SCTHR_MASK | WM8993_JD_THR_MASK |
WM8993_MICB1_LVL | WM8993_MICB2_LVL,
diff --git a/sound/soc/codecs/wm_hubs.h b/sound/soc/codecs/wm_hubs.h
index 4b8e5f0..988b29e 100644
--- a/sound/soc/codecs/wm_hubs.h
+++ b/sound/soc/codecs/wm_hubs.h
@@ -27,6 +27,7 @@ struct wm_hubs_data {
int hp_startup_mode;
int series_startup;
int no_series_update;
+ bool micd_scthr;
bool no_cache_dac_hp_direct;
struct list_head dcs_cache;
--
2.7.4
When the wm8958_mic_detect, wm8994_mic_detect functions get called from
the machine driver, e.g. from the card's late_probe() callback, the CODEC
device may be PM runtime suspended and any regmap writes have no effect.
Add PM runtime calls to these functions to ensure the device registers
are updated as expected.
This suppresses an error during boot
"wm8994-codec: ASoC: error at snd_soc_component_update_bits on wm8994-codec"
caused by the regmap access error due to the cache_only flag being set.
Signed-off-by: Sylwester Nawrocki <[email protected]>
---
sound/soc/codecs/wm8994.c | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/sound/soc/codecs/wm8994.c b/sound/soc/codecs/wm8994.c
index b3ba053..fc9ea19 100644
--- a/sound/soc/codecs/wm8994.c
+++ b/sound/soc/codecs/wm8994.c
@@ -3514,6 +3514,8 @@ int wm8994_mic_detect(struct snd_soc_component *component, struct snd_soc_jack *
return -EINVAL;
}
+ pm_runtime_get_sync(component->dev);
+
switch (micbias) {
case 1:
micdet = &wm8994->micdet[0];
@@ -3561,6 +3563,8 @@ int wm8994_mic_detect(struct snd_soc_component *component, struct snd_soc_jack *
snd_soc_dapm_sync(dapm);
+ pm_runtime_put(component->dev);
+
return 0;
}
EXPORT_SYMBOL_GPL(wm8994_mic_detect);
@@ -3932,6 +3936,8 @@ int wm8958_mic_detect(struct snd_soc_component *component, struct snd_soc_jack *
return -EINVAL;
}
+ pm_runtime_get_sync(component->dev);
+
if (jack) {
snd_soc_dapm_force_enable_pin(dapm, "CLK_SYS");
snd_soc_dapm_sync(dapm);
@@ -4000,6 +4006,8 @@ int wm8958_mic_detect(struct snd_soc_component *component, struct snd_soc_jack *
snd_soc_dapm_sync(dapm);
}
+ pm_runtime_put(component->dev);
+
return 0;
}
EXPORT_SYMBOL_GPL(wm8958_mic_detect);
--
2.7.4
On Thu, Aug 27, 2020 at 07:33:56PM +0200, Sylwester Nawrocki wrote:
> The WM8994_MICBIAS register is not available in the WM1811 CODEC so skip
> initialization of that register for that device.
> This suppresses an error during boot:
> "wm8994-codec: ASoC: error at snd_soc_component_update_bits on wm8994-codec"
>
> Signed-off-by: Sylwester Nawrocki <[email protected]>
> ---
> sound/soc/codecs/wm8994.c | 2 ++
> sound/soc/codecs/wm_hubs.c | 3 +++
> sound/soc/codecs/wm_hubs.h | 1 +
> 3 files changed, 6 insertions(+)
Acked-by: Krzysztof Kozlowski <[email protected]>
Best regards,
Krzysztof
On Thu, Aug 27, 2020 at 07:33:57PM +0200, Sylwester Nawrocki wrote:
> When the wm8958_mic_detect, wm8994_mic_detect functions get called from
> the machine driver, e.g. from the card's late_probe() callback, the CODEC
> device may be PM runtime suspended and any regmap writes have no effect.
> Add PM runtime calls to these functions to ensure the device registers
> are updated as expected.
> This suppresses an error during boot
> "wm8994-codec: ASoC: error at snd_soc_component_update_bits on wm8994-codec"
> caused by the regmap access error due to the cache_only flag being set.
>
> Signed-off-by: Sylwester Nawrocki <[email protected]>
> ---
> sound/soc/codecs/wm8994.c | 8 ++++++++
> 1 file changed, 8 insertions(+)
>
> diff --git a/sound/soc/codecs/wm8994.c b/sound/soc/codecs/wm8994.c
> index b3ba053..fc9ea19 100644
> --- a/sound/soc/codecs/wm8994.c
> +++ b/sound/soc/codecs/wm8994.c
> @@ -3514,6 +3514,8 @@ int wm8994_mic_detect(struct snd_soc_component *component, struct snd_soc_jack *
> return -EINVAL;
> }
>
> + pm_runtime_get_sync(component->dev);
The driver enables PM runtime unconditionally so you should probably
handle the error code here. I know that driver does not do it in other
cases but it should not be a reason to multiple this pattern... unless
it really does not matter as there are no runtime PM ops?
Best regards,
Krzysztof
On 28.08.2020 08:48, Krzysztof Kozlowski wrote:
>> diff --git a/sound/soc/codecs/wm8994.c b/sound/soc/codecs/wm8994.c
>> index b3ba053..fc9ea19 100644
>> --- a/sound/soc/codecs/wm8994.c
>> +++ b/sound/soc/codecs/wm8994.c
>> @@ -3514,6 +3514,8 @@ int wm8994_mic_detect(struct snd_soc_component *component, struct snd_soc_jack *
>> return -EINVAL;
>> }
>>
>> + pm_runtime_get_sync(component->dev);
> The driver enables PM runtime unconditionally so you should probably
> handle the error code here. I know that driver does not do it in other
> cases but it should not be a reason to multiple this pattern... unless
> it really does not matter as there are no runtime PM ops?
The regmap is provided by the parent MFD device (drivers/mfd/wm8994-core.c)
and that is where those runtime PM calls get propagated, we could possibly
get en error if there is something wrong with resuming the parent device.
If you don't mind I would prefer to omit the return value tests in that
fix patch. Existing callers of the wm89*_mic_detect() functions are
ignoring the return value anyway. Probably the checks could be added
in a separate patch.
--
Thanks,
Sylwester
On Fri, Aug 28, 2020 at 10:50:33AM +0200, Sylwester Nawrocki wrote:
> On 28.08.2020 08:48, Krzysztof Kozlowski wrote:
> >> diff --git a/sound/soc/codecs/wm8994.c b/sound/soc/codecs/wm8994.c
> >> index b3ba053..fc9ea19 100644
> >> --- a/sound/soc/codecs/wm8994.c
> >> +++ b/sound/soc/codecs/wm8994.c
> >> @@ -3514,6 +3514,8 @@ int wm8994_mic_detect(struct snd_soc_component *component, struct snd_soc_jack *
> >> return -EINVAL;
> >> }
> >>
> >> + pm_runtime_get_sync(component->dev);
>
> > The driver enables PM runtime unconditionally so you should probably
> > handle the error code here. I know that driver does not do it in other
> > cases but it should not be a reason to multiple this pattern... unless
> > it really does not matter as there are no runtime PM ops?
>
> The regmap is provided by the parent MFD device (drivers/mfd/wm8994-core.c)
> and that is where those runtime PM calls get propagated, we could possibly
> get en error if there is something wrong with resuming the parent device.
>
> If you don't mind I would prefer to omit the return value tests in that
> fix patch. Existing callers of the wm89*_mic_detect() functions are
> ignoring the return value anyway. Probably the checks could be added
> in a separate patch.
I don't mind.
Acked-by: Krzysztof Kozlowski <[email protected]>
Best regards,
Krzysztof
On Thu, Aug 27, 2020 at 07:33:56PM +0200, Sylwester Nawrocki wrote:
> The WM8994_MICBIAS register is not available in the WM1811 CODEC so skip
> initialization of that register for that device.
> This suppresses an error during boot:
> "wm8994-codec: ASoC: error at snd_soc_component_update_bits on wm8994-codec"
>
> Signed-off-by: Sylwester Nawrocki <[email protected]>
> ---
Acked-by: Charles Keepax <[email protected]>
Thanks,
Charles
On Thu, Aug 27, 2020 at 07:33:57PM +0200, Sylwester Nawrocki wrote:
> When the wm8958_mic_detect, wm8994_mic_detect functions get called from
> the machine driver, e.g. from the card's late_probe() callback, the CODEC
> device may be PM runtime suspended and any regmap writes have no effect.
> Add PM runtime calls to these functions to ensure the device registers
> are updated as expected.
> This suppresses an error during boot
> "wm8994-codec: ASoC: error at snd_soc_component_update_bits on wm8994-codec"
> caused by the regmap access error due to the cache_only flag being set.
>
> Signed-off-by: Sylwester Nawrocki <[email protected]>
> ---
Acked-by: Charles Keepax <[email protected]>
Thanks,
Charles
On Thu, 27 Aug 2020 19:33:56 +0200, Sylwester Nawrocki wrote:
> The WM8994_MICBIAS register is not available in the WM1811 CODEC so skip
> initialization of that register for that device.
> This suppresses an error during boot:
> "wm8994-codec: ASoC: error at snd_soc_component_update_bits on wm8994-codec"
Applied to
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-next
Thanks!
[1/2] ASoC: wm8994: Skip setting of the WM8994_MICBIAS register for WM1811
commit: 811c5494436789e7149487c06e0602b507ce274b
[2/2] ASoC: wm8994: Ensure the device is resumed in wm89xx_mic_detect functions
commit: f5a2cda4f1db89776b64c4f0f2c2ac609527ac70
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.
You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.
If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.
Please add any relevant lists and maintainers to the CCs when replying
to this mail.
Thanks,
Mark