[PATCH 1/2] ASoC: dt-bindings: nau8825: Add delay control for input path
Change the original fixed delay to the assignment from property. It will make more flexible to different platforms for avoiding pop noise at the beginning of recording.
Signed-off-by: David Lin CTLIN0@nuvoton.com --- Documentation/devicetree/bindings/sound/nau8825.txt | 3 +++ 1 file changed, 3 insertions(+)
diff --git a/Documentation/devicetree/bindings/sound/nau8825.txt b/Documentation/devicetree/bindings/sound/nau8825.txt index cb861aca8d40..a9c34526f4cb 100644 --- a/Documentation/devicetree/bindings/sound/nau8825.txt +++ b/Documentation/devicetree/bindings/sound/nau8825.txt @@ -74,6 +74,9 @@ Optional properties: - nuvoton,adcout-drive-strong: make the drive strength of ADCOUT IO PIN strong if set. Otherwise, the drive keeps normal strength.
+ - nuvoton,adc-delay-ms: Delay (in ms) to make input path stable and avoid pop noise. The + default value is 125 and range between 125 to 500 ms. + - clocks: list of phandle and clock specifier pairs according to common clock bindings for the clocks described in clock-names - clock-names: should include "mclk" for the MCLK master clock
Change the original fixed delay to the assignment from property. It will make more flexible to different platforms for avoiding pop noise at the beginning of recording.
Signed-off-by: David Lin CTLIN0@nuvoton.com --- sound/soc/codecs/nau8825.c | 8 +++++++- sound/soc/codecs/nau8825.h | 1 + 2 files changed, 8 insertions(+), 1 deletion(-)
diff --git a/sound/soc/codecs/nau8825.c b/sound/soc/codecs/nau8825.c index 4bffa9c20f2b..c4389f5fe603 100644 --- a/sound/soc/codecs/nau8825.c +++ b/sound/soc/codecs/nau8825.c @@ -919,7 +919,7 @@ static int nau8825_adc_event(struct snd_soc_dapm_widget *w,
switch (event) { case SND_SOC_DAPM_POST_PMU: - msleep(125); + msleep(nau8825->adc_delay); regmap_update_bits(nau8825->regmap, NAU8825_REG_ENA_CTRL, NAU8825_ENABLE_ADC, NAU8825_ENABLE_ADC); break; @@ -2752,6 +2752,7 @@ static void nau8825_print_device_properties(struct nau8825 *nau8825) dev_dbg(dev, "crosstalk-enable: %d\n", nau8825->xtalk_enable); dev_dbg(dev, "adcout-drive-strong: %d\n", nau8825->adcout_ds); + dev_dbg(dev, "adc-delay-ms: %d\n", nau8825->adc_delay); }
static int nau8825_read_device_properties(struct device *dev, @@ -2819,6 +2820,11 @@ static int nau8825_read_device_properties(struct device *dev, nau8825->xtalk_enable = device_property_read_bool(dev, "nuvoton,crosstalk-enable"); nau8825->adcout_ds = device_property_read_bool(dev, "nuvoton,adcout-drive-strong"); + ret = device_property_read_u32(dev, "nuvoton,adc-delay-ms", &nau8825->adc_delay); + if (ret) + nau8825->adc_delay = 125; + if (nau8825->adc_delay < 125 && nau8825->adc_delay > 500) + dev_warn(dev, "Please set the suitable delay time!\n");
nau8825->mclk = devm_clk_get(dev, "mclk"); if (PTR_ERR(nau8825->mclk) == -EPROBE_DEFER) { diff --git a/sound/soc/codecs/nau8825.h b/sound/soc/codecs/nau8825.h index 0c3a446e0e1a..44b62bc3880f 100644 --- a/sound/soc/codecs/nau8825.h +++ b/sound/soc/codecs/nau8825.h @@ -517,6 +517,7 @@ struct nau8825 { int xtalk_enable; bool xtalk_baktab_initialized; /* True if initialized. */ bool adcout_ds; + int adc_delay; };
int nau8825_enable_jack_detect(struct snd_soc_component *component,
On 14/04/2023 12:39, David Lin wrote:
Change the original fixed delay to the assignment from property. It will make more flexible to different platforms for avoiding pop noise at the beginning of recording.
Please use scripts/get_maintainers.pl to get a list of necessary people and lists to CC. It might happen, that command when run on an older kernel, gives you outdated entries. Therefore please be sure you base your patches on recent Linux kernel.
Signed-off-by: David Lin CTLIN0@nuvoton.com
Documentation/devicetree/bindings/sound/nau8825.txt | 3 +++ 1 file changed, 3 insertions(+)
diff --git a/Documentation/devicetree/bindings/sound/nau8825.txt b/Documentation/devicetree/bindings/sound/nau8825.txt index cb861aca8d40..a9c34526f4cb 100644 --- a/Documentation/devicetree/bindings/sound/nau8825.txt +++ b/Documentation/devicetree/bindings/sound/nau8825.txt @@ -74,6 +74,9 @@ Optional properties:
- nuvoton,adcout-drive-strong: make the drive strength of ADCOUT IO PIN strong if set. Otherwise, the drive keeps normal strength.
- nuvoton,adc-delay-ms: Delay (in ms) to make input path stable and avoid pop noise. The
default value is 125 and range between 125 to 500 ms.
Convert the binding to DT Schema first.
Best regards, Krzysztof
On Fri, Apr 14, 2023 at 02:34:19PM +0200, Krzysztof Kozlowski wrote:
On 14/04/2023 12:39, David Lin wrote:
- nuvoton,adc-delay-ms: Delay (in ms) to make input path stable and avoid pop noise. The
default value is 125 and range between 125 to 500 ms.
Convert the binding to DT Schema first.
That seems disproportionate for such a trivial change.
On 14/04/2023 15:46, Mark Brown wrote:
On Fri, Apr 14, 2023 at 02:34:19PM +0200, Krzysztof Kozlowski wrote:
On 14/04/2023 12:39, David Lin wrote:
- nuvoton,adc-delay-ms: Delay (in ms) to make input path stable and avoid pop noise. The
default value is 125 and range between 125 to 500 ms.Convert the binding to DT Schema first.
That seems disproportionate for such a trivial change.
What is the difference between: 1. Adding 2 or 3 new properties to TXT file without converting the file to DT Schema,
2. Adding 1 property in 2022 Sep. Then adding one more property now. Then adding another property in 3 months.
I don't see.
Every time the excuse is the same - it is just one property, so let's add it. Since this is second property, after we started enforcing DT schema, I don't think my request is disproportionate.
I think my request is reasonable.
Best regards, Krzysztof
On 14/04/2023 15:58, Krzysztof Kozlowski wrote:
On 14/04/2023 15:46, Mark Brown wrote:
On Fri, Apr 14, 2023 at 02:34:19PM +0200, Krzysztof Kozlowski wrote:
On 14/04/2023 12:39, David Lin wrote:
- nuvoton,adc-delay-ms: Delay (in ms) to make input path stable and avoid pop noise. The
default value is 125 and range between 125 to 500 ms.Convert the binding to DT Schema first.
That seems disproportionate for such a trivial change.
What is the difference between:
- Adding 2 or 3 new properties to TXT file without converting the file
to DT Schema,
- Adding 1 property in 2022 Sep. Then adding one more property now.
Then adding another property in 3 months.
I don't see.
Every time the excuse is the same - it is just one property, so let's add it. Since this is second property, after we started enforcing DT schema, I don't think my request is disproportionate.
BTW, the change from September was also sent to mailing lists ignoring Devicetree entirely. This does not help here, because now it looks like a pattern.
Best regards, Krzysztof
On Fri, Apr 14, 2023 at 03:58:06PM +0200, Krzysztof Kozlowski wrote:
On 14/04/2023 15:46, Mark Brown wrote:
That seems disproportionate for such a trivial change.
What is the difference between:
- Adding 2 or 3 new properties to TXT file without converting the file
to DT Schema,
- Adding 1 property in 2022 Sep. Then adding one more property now.
Then adding another property in 3 months.
I don't see.
Me either, but I also don't see an issue with this situation. If someone wants to convert to schema they'll get round to it, meanwhile the code isn't held up by that process.
Every time the excuse is the same - it is just one property, so let's add it. Since this is second property, after we started enforcing DT schema, I don't think my request is disproportionate.
I think my request is reasonable.
The schema conversion patches are very often disproportionately hard work, there's a lot of poorly communicated rules beyond whatever the tools actually check for.
On 4/15/2023 12:38 AM, Mark Brown wrote:
On Fri, Apr 14, 2023 at 03:58:06PM +0200, Krzysztof Kozlowski wrote:
On 14/04/2023 15:46, Mark Brown wrote:
That seems disproportionate for such a trivial change.
What is the difference between:
- Adding 2 or 3 new properties to TXT file without converting the file
to DT Schema, 2. Adding 1 property in 2022 Sep. Then adding one more property now. Then adding another property in 3 months. I don't see.
Me either, but I also don't see an issue with this situation. If someone wants to convert to schema they'll get round to it, meanwhile the code isn't held up by that process.
Every time the excuse is the same - it is just one property, so let's add it. Since this is second property, after we started enforcing DT schema, I don't think my request is disproportionate. I think my request is reasonable.
The schema conversion patches are very often disproportionately hard work, there's a lot of poorly communicated rules beyond whatever the tools actually check for.
Thanks to the comments from Krzysztof Kozlowski and Mark.
We will plan to gradually convert all txt files of codec driver of Nuvoton to yaml format.
________________________________ ________________________________ The privileged confidential information contained in this email is intended for use only by the addressees as indicated by the original sender of this email. If you are not the addressee indicated in this email or are not responsible for delivery of the email to such a person, please kindly reply to the sender indicating this fact and delete all copies of it from your computer and network server immediately. Your cooperation is highly appreciated. It is advised that any unauthorized use of confidential information of Nuvoton is strictly prohibited; and any information in this email irrelevant to the official business of Nuvoton shall be deemed as neither given nor endorsed by Nuvoton.
On Fri, 14 Apr 2023 18:39:42 +0800, David Lin wrote:
Change the original fixed delay to the assignment from property. It will make more flexible to different platforms for avoiding pop noise at the beginning of recording.
Applied to
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-next
Thanks!
[1/2] ASoC: dt-bindings: nau8825: Add delay control for input path commit: c26c5921e1a770e6c092c4d25dea19052bdfddab [2/2] ASoC: nau8825: Add delay control for input path commit: fc0b096c92918c2ba4d76411ea763fdeb2ef6b0d
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
participants (4)
-
AS50 CTLin0 -
David Lin
-
Krzysztof Kozlowski -
Mark Brown