[PATCH v2 0/2] ASoC: codecs: nau8360: Add DSP fallback and PEQ band initialization

[PATCH v2 0/2] ASoC: codecs: nau8360: Add DSP fallback and PEQ band initialization

[Neo Chang]

This patch series adds a fallback mechanism for the NAU8360 DSP during 
firmware load failure and ensures proper initialization for PEQ bands.

It includes the following changes:
- Fallback to bypass mode automatically when DSP firmware fails to load,
  ensuring basic audio playback remains functional.
- Set a default PEQ band number during DSP initialization to prevent
  invalid state or uninitialized parameters before user configuration
  is applied.

Changes in v2:
- Use snd_soc_component_update_bits() to prevent register overwriting.
(Reported by Sashiko AI)
- Fix missing bit shift for default PEQ band. (Reported by Sashiko AI)

Neo Chang (2):
  ASoC: codecs: nau8360: Set DAC path to bypass mode when DSP firmware
    load fails
  ASoC: codecs: nau8360: Add default PEQ band number for DSP init

 sound/soc/codecs/nau8360.c | 4 ++++
 1 file changed, 4 insertions(+)

-- 
2.25.1

[PATCH v2 1/2] ASoC: codecs: nau8360: Set DAC path to bypass mode when DSP firmware load fails

[Neo Chang]

Automatically route the DAC path to bypass mode if DSP firmware fails
to load, ensuring basic audio playback remains functional.

Signed-off-by: Neo Chang <YLCHANG2@nuvoton.com>
---
 sound/soc/codecs/nau8360.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/sound/soc/codecs/nau8360.c b/sound/soc/codecs/nau8360.c
index d7af2dffb749..8b75d3b9ebd6 100644
--- a/sound/soc/codecs/nau8360.c
+++ b/sound/soc/codecs/nau8360.c
@@ -1702,6 +1702,8 @@ static void nau8360_load_fw_work(struct work_struct *work)
 	if (ret) {
 		dev_err(nau8360->dev, "Failed to initialize DSP: %d\n", ret);
 		nau8360_dsp_enable(nau8360->regmap, false);
+		snd_soc_component_update_bits(cp, NAU8360_R12_PATH_CTRL,
+			NAU8360_DAC_SEL_MASK, NAU8360_DAC_SEL_BYP);
 		return;
 	}
 	nau8360->load_fw_done = true;
-- 
2.25.1

Re: [PATCH v2 1/2] ASoC: codecs: nau8360: Set DAC path to bypass mode when DSP firmware load fails

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [High] Directly modifying a DAPM-controlled routing register bypasses DAPM state tracking, leading to an aborted power sequence and complete audio playback failure.
- [High] Successful firmware load fails to restore the DAC path to DSP mode if it was previously set to bypass mode on failure.
--

commit 66908584f9a6b49d33fcb5f3e81314daeeff0253
Author: Neo Chang <YLCHANG2@nuvoton.com>

ASoC: codecs: nau8360: Set DAC path to bypass mode when DSP firmware load fails

Automatically route the DAC path to bypass mode if DSP firmware fails
to load, ensuring basic audio playback remains functional.

> diff --git a/sound/soc/codecs/nau8360.c b/sound/soc/codecs/nau8360.c
> index d7af2dffb749a..8b75d3b9ebd61 100644
> --- a/sound/soc/codecs/nau8360.c
> +++ b/sound/soc/codecs/nau8360.c
> @@ -1702,6 +1702,8 @@ static void nau8360_load_fw_work(struct work_struct *work)
>  	if (ret) {
>  		dev_err(nau8360->dev, "Failed to initialize DSP: %d\n", ret);
>  		nau8360_dsp_enable(nau8360->regmap, false);
> +		snd_soc_component_update_bits(cp, NAU8360_R12_PATH_CTRL,
> +			NAU8360_DAC_SEL_MASK, NAU8360_DAC_SEL_BYP);

[Severity: High]
Does directly modifying the routing register here bypass DAPM state tracking?

When userspace subsequently starts playback, DAPM's unmodified internal state
may still believe the path is set to DSP mode and power up the DSP Clock widget.

This would trigger nau8360_dsp_clock_event(), which sends an I2C command to the
explicitly halted DSP:

sound/soc/codecs/nau8360-dsp.c:nau8360_dsp_clock_event() {
	...
	if (SND_SOC_DAPM_EVENT_ON(event))
		ret = nau8360_send_dsp_broadcast(cp, NAU8360_DSP_CMD_CLK_RESTART);
	...
}

Could this cause the command to time out and abort the DAPM power sequence?

Additionally, does this direct register write bypass the lock and hardware state
machine updates normally handled by the mux control?

sound/soc/codecs/nau8360.c:nau8360_dac_mux_put_enum() {
	...
	mutex_lock(&nau8360->lock);

	ret = snd_soc_dapm_put_enum_double(kcontrol, ucontrol);
	if (ret <= 0)
		goto unlock;

	nau8360_dsp_switch(component, snd_soc_enum_item_to_val(e, item[0]));

unlock:
	mutex_unlock(&nau8360->lock);
	...
}

>  		return;
>  	}
>  	nau8360->load_fw_done = true;

[Severity: High]
If a firmware load successfully completes after a previous failure (for example,
on system resume), will the DAC path remain stuck in bypass mode?

It appears that if the hardware was forced into bypass mode during a previous
error, the success path does not restore NAU8360_R12_PATH_CTRL to match DAPM's
expected DSP mode.

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260904060035.196399-1-YLCHANG2@nuvoton.com?part=1

Re: [PATCH v2 1/2] ASoC: codecs: nau8360: Set DAC path to bypass mode when DSP firmware load fails

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 954 bytes --]

On Fri, Sep 04, 2026 at 02:00:34PM +0800, Neo Chang wrote:
> Automatically route the DAC path to bypass mode if DSP firmware fails
> to load, ensuring basic audio playback remains functional.

> @@ -1702,6 +1702,8 @@ static void nau8360_load_fw_work(struct work_struct *work)
>  	if (ret) {
>  		dev_err(nau8360->dev, "Failed to initialize DSP: %d\n", ret);
>  		nau8360_dsp_enable(nau8360->regmap, false);
> +		snd_soc_component_update_bits(cp, NAU8360_R12_PATH_CTRL,
> +			NAU8360_DAC_SEL_MASK, NAU8360_DAC_SEL_BYP);
>  		return;

We don't generally do things like this, we rely on the user to fix up
their configuration, but equally we don't have a good mechanism to flag
problems with firmware download to the user.  It's not something we
really expect to go wrong.

Since the register being updated here is a user visible control if this
does kick in we should also generate an event on the DAC Source control
so userspace knows something happened.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [PATCH v2 1/2] ASoC: codecs: nau8360: Set DAC path to bypass mode when DSP firmware load fails

[YLCHANG2]

On 9/5/26 01:47, Mark Brown wrote:
> On Fri, Sep 04, 2026 at 02:00:34PM +0800, Neo Chang wrote:
>> Automatically route the DAC path to bypass mode if DSP firmware fails
>> to load, ensuring basic audio playback remains functional.
>> @@ -1702,6 +1702,8 @@ static void nau8360_load_fw_work(struct work_struct *work)
>>   	if (ret) {
>>   		dev_err(nau8360->dev, "Failed to initialize DSP: %d\n", ret);
>>   		nau8360_dsp_enable(nau8360->regmap, false);
>> +		snd_soc_component_update_bits(cp, NAU8360_R12_PATH_CTRL,
>> +			NAU8360_DAC_SEL_MASK, NAU8360_DAC_SEL_BYP);
>>   		return;
> We don't generally do things like this, we rely on the user to fix up
> their configuration, but equally we don't have a good mechanism to flag
> problems with firmware download to the user.  It's not something we
> really expect to go wrong.
>
> Since the register being updated here is a user visible control if this
> does kick in we should also generate an event on the DAC Source control
> so userspace knows something happened.
Hi Mark,
Thank you for your review and suggestion.
I will remove the register update (NAU8360_DAC_SEL_BYP) during firmware 
loading.
Instead, I will add the following check in nau8360_dac_mux_put_enum() to 
warn the user and block the path switch
if the DSP firmware is not ready:

int ret = 0;
//....
mutex_lock(&nau8360->lock);

if (item[0] == NAU8360_DAC_SRC_DSP && !nau8360->load_fw_done) {
     dev_warn(nau8360->dev, "Cannot enable DSP: Firmware not ready or 
disabled\n");
     mutex_unlock(&nau8360->lock);
     return ret;
}

Re: [PATCH v2 1/2] ASoC: codecs: nau8360: Set DAC path to bypass mode when DSP firmware load fails

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 379 bytes --]

On Mon, Sep 07, 2026 at 11:45:10AM +0800, YLCHANG2 wrote:

> Thank you for your review and suggestion.
> I will remove the register update (NAU8360_DAC_SEL_BYP) during firmware
> loading.
> Instead, I will add the following check in nau8360_dac_mux_put_enum() to
> warn the user and block the path switch
> if the DSP firmware is not ready:

That seems like a sensible approach.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

[PATCH v2 2/2] ASoC: codecs: nau8360: Add default PEQ band number for DSP init

[Neo Chang]

Set a default PEQ band number during DSP initialization to prevent
invalid state or uninitialized parameters before user configuration
is applied.

Signed-off-by: Neo Chang <YLCHANG2@nuvoton.com>
---
 sound/soc/codecs/nau8360.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/sound/soc/codecs/nau8360.c b/sound/soc/codecs/nau8360.c
index 8b75d3b9ebd6..2c4375e81415 100644
--- a/sound/soc/codecs/nau8360.c
+++ b/sound/soc/codecs/nau8360.c
@@ -1602,6 +1602,8 @@ static void nau8360_coeff_set_def(struct nau8360 *nau8360)
 			i * NAU8360_TOT_BAND_COE_RANGE, 0x20);
 	}
 	nau8360_peq_mem_enable(regmap, false);
+	regmap_update_bits(regmap, NAU8360_R9D_PEQ_CTL, NAU8360_PEQ_BAND_MASK,
+		NAU8360_PEQ_BAND_8 << NAU8360_PEQ_BAND_SFT);
 	mutex_unlock(&nau8360->lock);
 }
 
-- 
2.25.1

Re: (subset) [PATCH v2 0/2] ASoC: codecs: nau8360: Add DSP fallback and PEQ band initialization

[Mark Brown]

On Fri, 04 Sep 2026 14:00:33 +0800, Neo Chang wrote:
> ASoC: codecs: nau8360: Add DSP fallback and PEQ band initialization
> 
> This patch series adds a fallback mechanism for the NAU8360 DSP during
> firmware load failure and ensures proper initialization for PEQ bands.
> 
> It includes the following changes:
> - Fallback to bypass mode automatically when DSP firmware fails to load,
>   ensuring basic audio playback remains functional.
> - Set a default PEQ band number during DSP initialization to prevent
>   invalid state or uninitialized parameters before user configuration
>   is applied.
> 
> [...]

Applied to

   https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-7.4

Thanks!

[2/2] ASoC: codecs: nau8360: Add default PEQ band number for DSP init
      https://git.kernel.org/broonie/sound/c/366e4d4f0ca8

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