Re: [PATCH v5 2/2] ASoC: codecs: nau8360: Add support for NAU83G60 amplifier

[YLCHANG2 <neo.chang70@gmail.com>]

On 7/2/26 23:15, Mark Brown wrote:
> On Tue, Jun 30, 2026 at 10:15:10AM +0800, Neo Chang wrote:
>> Add support for the Nuvoton NAU83G60 audio codec. The NAU83G60 is a
>> stereo 30W+30W smart amplifier with an integrated low-latency
>> Advanced Audio DSP.
>> +static const char *const tdm_data_length[] = { "16", "32" };
>> +
>> +static const char *const tdm_pdm_length[] = { "16", "32" };
>> +
>> +static const char *const tdm_data_n_length[] = { "8", "16" };
> I would expect TDM to be configured by set_tdm_slot() from the machine
> driver, not from userspace.  I see the driver does actually have a
> set_tdm_slot() operation...

Hi Mark,

Thanks for the feedback. Regarding the TDM configuration:
Our DSP functions require specific Slot mapping (e.g., Slot 0 for AECL, 
Slot 1 for AECR).
The standard set_tdm_slot() only defines active slots but doesn't handle 
the functional mapping.
We originally intended to allow dynamic mapping via UCM/userspacea and 
then apply these settings using set_tdm_slot().
How should we implement this mapping according to ASoC standards?
Should we define the default mapping during the codec probe stage,
or is there a preferred way to handle this via the machine driver?

>
>> +static int nau8360_read_device_properties(struct nau8360 *nau8360)
>> +{
>> +	ret = device_property_string_array_count(dev, "firmware-name");
>> +	if (ret != NAU8360_DSP_FW_NUM) {
>> +		dev_err(dev, "Missing or invalid firmware-name property in DT\n");
>> +		return -EINVAL;
>> +	}
>> +static int nau8360_i2c_probe(struct i2c_client *i2c)
>> +{
>> +	ret = nau8360_read_device_properties(nau8360);
>> +	if (ret)
>> +		return ret;
> This will fail the probe if we fail to read firmware-name from the DT so
> the firmware name is a required property in DT (and ACPI systems will
> have fun) even though it is not marked as such.  Either the driver needs
> to tolerate not having the name configured one way or another or the
> property needs to be mandatory in the bindings.
Since the DSP firmware is mandatory for the NAU83G60 to function,
I have updated the YAML binding to make firmware-name a required property.
To ensure robustness, I have also added a fallback mechanism in the 
driver to use default firmware paths
if reading the firmware-name property fails, ensuring the driver probe 
does not fail.