From: Shimrra Shai shimrrashai@gmail.com
[ Upstream commit 33bc29123d26f7caa7d11f139e153e39104afc6c ]
Remove initialization of the DAC and mixer enablement bits from the es8323_probe routine. This really should be handled by the DAPM subsystem.
Signed-off-by: Shimrra Shai shimrrashai@gmail.com Link: https://patch.msgid.link/20250815042023.115485-2-shimrrashai@gmail.com Signed-off-by: Mark Brown broonie@kernel.org Signed-off-by: Sasha Levin sashal@kernel.org ---
LLM Generated explanations, may be completely bogus:
YES
- What changed - The unconditional write in `es8323_probe()` that sets `ES8323_DACCONTROL17` was removed: `snd_soc_component_write(component, ES8323_DACCONTROL17, 0xB8)` (sound/soc/codecs/es8323.c). This register holds the per‑path mixer gate and level bits for the DAC/mixer. - The rest of probe remains the same (clock fetch/enable, sane defaults via `ES8323_CONTROL2` and `ES8323_CHIPPOWER` writes).
- Why this is a bug fix - `ES8323_DACCONTROL17` includes the mixer enable bit (bit 7) and bypass volume field (bits 5:3). Writing `0xB8` in probe forces the left mixer gate on and sets the bypass level to its maximum, independent of any active audio route. - In ASoC, DAPM owns codec power/mixer gates. Hard‑enabling a mixer at probe bypasses DAPM, leading to: - Always‑on or prematurely‑on audio paths (increased idle power, potential clicks/pops at boot/resume). - Mismatched DAPM state vs. hardware state, undermining DAPM’s power sequencing and pop‑suppression. - The commit message explicitly states this should be handled by DAPM, which matches standard ASoC practice (compare the analogous ES8328 driver where DAPM controls `DACCONTROL17` via DAPM mixer widgets).
- Scope and risk assessment - Change is minimal and localized to `sound/soc/codecs/es8323.c` in `es8323_probe()`; no ABI or architectural changes. - It removes an unconditional register poke and defers control to existing DAPM routing, which is already the intended mechanism (the driver’s bias management and DAPM paths handle DAC/mixer power in normal operation). - Potential regression risk is low: only boards that implicitly relied on the incorrect “pre‑enabled” mixer/DAC at probe would notice a behavior change; correct machine drivers should rely on DAPM to enable paths when a stream is active.
- Stable criteria - Fixes a real, user‑visible issue (unnecessary power draw, audio artifacts, and DAPM miscoordination). - Small, self‑contained change with minimal regression risk. - No new features and no architectural churn; confined to the codec driver. - While there’s no explicit “Cc: stable” tag, this matches typical stable‑worthy ASoC fixes (removing stray probe‑time enables in favor of DAPM).
Conclusion: This is a safe, corrective change that aligns the driver with ASoC/DAPM design and should be backported to any stable trees that contain the ES8323 driver and its DAPM graph.
sound/soc/codecs/es8323.c | 1 - 1 file changed, 1 deletion(-)
diff --git a/sound/soc/codecs/es8323.c b/sound/soc/codecs/es8323.c index 70d348ff3b437..4c15fffda733c 100644 --- a/sound/soc/codecs/es8323.c +++ b/sound/soc/codecs/es8323.c @@ -632,7 +632,6 @@ static int es8323_probe(struct snd_soc_component *component)
snd_soc_component_write(component, ES8323_CONTROL2, 0x60); snd_soc_component_write(component, ES8323_CHIPPOWER, 0x00); - snd_soc_component_write(component, ES8323_DACCONTROL17, 0xB8);
return 0; }