[PATCH v2 0/5] Few audio fixes on Tegra platforms
This series fixes some of the issues which were observed during an attempt to enhance automated test coverage on Jetson AGX Orin. Below is a short summary of the issues and fixes:
* Sample rate coversion failures above 48kHz. * AMX and ADX test cases failures due to incorrect byte mask. * Atomic sleep in RT5640 codec which is present on Jetson AGX Orin. * AHUB clock fixes on Tegra234 and previous chips. * Minor cleanups in ASRC and AHUB driver.
Changelog =========
v1 -> v2: --------- * Few patches got accepted in the original (v1) series. Now v2 addresses comments for remaining patches. * AMX/ADX byte map fix patch is updated with more details in the commit message and added TODO item in the driver to improve the logic. * For RT5640 codec patch, the threaded IRQ is used for only for rt5640_irq() and rt5640_jd_gpio_irq() is left untouched.
Sameer Pujar (2): ASoC: rt5640: Fix sleep in atomic context arm64: tegra: Update AHUB clock parent and rate
Sheetal (3): ASoC: tegra: Fix AMX byte map ASoC: tegra: Fix ADX byte map arm64: tegra: Update AHUB clock parent and rate on Tegra234
arch/arm64/boot/dts/nvidia/tegra186.dtsi | 3 ++- arch/arm64/boot/dts/nvidia/tegra194.dtsi | 3 ++- arch/arm64/boot/dts/nvidia/tegra210.dtsi | 3 ++- arch/arm64/boot/dts/nvidia/tegra234.dtsi | 3 ++- sound/soc/codecs/rt5640.c | 12 ++++++---- sound/soc/tegra/tegra210_adx.c | 34 +++++++++++++++++---------- sound/soc/tegra/tegra210_amx.c | 40 ++++++++++++++++++-------------- 7 files changed, 59 insertions(+), 39 deletions(-)
From: Sheetal sheetal@nvidia.com
Byte mask for channel-1 of stream-1 is not getting enabled and this causes failures during AMX use cases. This happens because the byte map value 0 matches the byte map array and put() callback returns without enabling the corresponding bits in the byte mask.
AMX supports 4 input streams and each stream can take a maximum of 16 channels. Each byte in the output frame is uniquely mapped to a byte in one of these 4 inputs. This mapping is done with the help of byte map array via user space control setting. The byte map array size in the driver is 16 and each array element is of size 4 bytes. This corresponds to 64 byte map values.
Each byte in the byte map array can have any value between 0 to 255 to enable the corresponding bits in the byte mask. The value 256 is used as a way to disable the byte map. However the byte map array element cannot store this value. The put() callback disables the byte mask for 256 value and byte map value is reset to 0 for this case. This causes problems during subsequent runs since put() callback, for value of 0, just returns without enabling the byte mask. In short, the problem is coming because 0 and 256 control values are stored as 0 in the byte map array.
Right now fix the put() callback by actually looking at the byte mask array state to identify if any change is needed and update the fields accordingly. The get() callback needs an update as well to return the correct control value that user has set before. Note that when user sets 256, the value is stored as 0 and byte mask is disabled. So byte mask state is used to either return 256 or the value from byte map array.
Given above, this looks bit complicated and all this happens because the byte map array is tightly packed and cannot actually store the 256 value. Right now the priority is to fix the existing failure and a TODO item is put to improve this logic.
Fixes: 8db78ace1ba8 ("ASoC: tegra: Fix kcontrol put callback in AMX") Cc: stable@vger.kernel.org Signed-off-by: Sheetal sheetal@nvidia.com Reviewed-by: Mohan Kumar D mkumard@nvidia.com Reviewed-by: Sameer Pujar spujar@nvidia.com --- sound/soc/tegra/tegra210_amx.c | 40 ++++++++++++++++++++++------------------ 1 file changed, 22 insertions(+), 18 deletions(-)
diff --git a/sound/soc/tegra/tegra210_amx.c b/sound/soc/tegra/tegra210_amx.c index 782a141..1798769 100644 --- a/sound/soc/tegra/tegra210_amx.c +++ b/sound/soc/tegra/tegra210_amx.c @@ -2,7 +2,7 @@ // // tegra210_amx.c - Tegra210 AMX driver // -// Copyright (c) 2021 NVIDIA CORPORATION. All rights reserved. +// Copyright (c) 2021-2023 NVIDIA CORPORATION. All rights reserved.
#include <linux/clk.h> #include <linux/device.h> @@ -203,10 +203,20 @@ static int tegra210_amx_get_byte_map(struct snd_kcontrol *kcontrol, else enabled = amx->byte_mask[0] & (1 << reg);
+ /* + * TODO: Simplify this logic to just return from bytes_map[] + * + * Presently below is required since bytes_map[] is + * tightly packed and cannot store the control value of 256. + * Byte mask state is used to know if 256 needs to be returned. + * Note that for control value of 256, the put() call stores 0 + * in the bytes_map[] and disables the corresponding bit in + * byte_mask[]. + */ if (enabled) ucontrol->value.integer.value[0] = bytes_map[reg]; else - ucontrol->value.integer.value[0] = 0; + ucontrol->value.integer.value[0] = 256;
return 0; } @@ -221,25 +231,19 @@ static int tegra210_amx_put_byte_map(struct snd_kcontrol *kcontrol, unsigned char *bytes_map = (unsigned char *)&amx->map; int reg = mc->reg; int value = ucontrol->value.integer.value[0]; + unsigned int mask_val = amx->byte_mask[reg / 32];
- if (value == bytes_map[reg]) + if (value >= 0 && value <= 255) + mask_val |= (1 << (reg % 32)); + else + mask_val &= ~(1 << (reg % 32)); + + if (mask_val == amx->byte_mask[reg / 32]) return 0;
- if (value >= 0 && value <= 255) { - /* Update byte map and enable slot */ - bytes_map[reg] = value; - if (reg > 31) - amx->byte_mask[1] |= (1 << (reg - 32)); - else - amx->byte_mask[0] |= (1 << reg); - } else { - /* Reset byte map and disable slot */ - bytes_map[reg] = 0; - if (reg > 31) - amx->byte_mask[1] &= ~(1 << (reg - 32)); - else - amx->byte_mask[0] &= ~(1 << reg); - } + /* Update byte map and slot */ + bytes_map[reg] = value % 256; + amx->byte_mask[reg / 32] = mask_val;
return 1; }
From: Sheetal sheetal@nvidia.com
Byte mask for channel-1 of stream-1 is not getting enabled and this causes failures during ADX use cases. This happens because the byte map value 0 matches the byte map array and put() callback returns without enabling the corresponding bits in the byte mask.
ADX supports 4 output streams and each stream can have a maximum of 16 channels. Each byte in the input frame is uniquely mapped to a byte in one of these 4 outputs. This mapping is done with the help of byte map array via user space control setting. The byte map array size in the driver is 16 and each array element is of size 4 bytes. This corresponds to 64 byte map values.
Each byte in the byte map array can have any value between 0 to 255 to enable the corresponding bits in the byte mask. The value 256 is used as a way to disable the byte map. However the byte map array element cannot store this value. The put() callback disables the byte mask for 256 value and byte map value is reset to 0 for this case. This causes problems during subsequent runs since put() callback, for value of 0, just returns without enabling the byte mask. In short, the problem is coming because 0 and 256 control values are stored as 0 in the byte map array.
Right now fix the put() callback by actually looking at the byte mask array state to identify if any change is needed and update the fields accordingly. The get() callback needs an update as well to return the correct control value that user has set before. Note that when user set 256, the value is stored as 0 and byte mask is disabled. So byte mask state is used to either return 256 or the value from byte map array.
Given above, this looks bit complicated and all this happens because the byte map array is tightly packed and cannot actually store the 256 value. Right now the priority is to fix the existing failure and a TODO item is put to improve this logic.
Fixes: 3c97881b8c8a ("ASoC: tegra: Fix kcontrol put callback in ADX") Cc: stable@vger.kernel.org Signed-off-by: Sheetal sheetal@nvidia.com Reviewed-by: Mohan Kumar D mkumard@nvidia.com Reviewed-by: Sameer Pujar spujar@nvidia.com --- sound/soc/tegra/tegra210_adx.c | 34 ++++++++++++++++++++++------------ 1 file changed, 22 insertions(+), 12 deletions(-)
diff --git a/sound/soc/tegra/tegra210_adx.c b/sound/soc/tegra/tegra210_adx.c index bd0b10c..7d003f0 100644 --- a/sound/soc/tegra/tegra210_adx.c +++ b/sound/soc/tegra/tegra210_adx.c @@ -2,7 +2,7 @@ // // tegra210_adx.c - Tegra210 ADX driver // -// Copyright (c) 2021 NVIDIA CORPORATION. All rights reserved. +// Copyright (c) 2021-2023 NVIDIA CORPORATION. All rights reserved.
#include <linux/clk.h> #include <linux/device.h> @@ -175,10 +175,20 @@ static int tegra210_adx_get_byte_map(struct snd_kcontrol *kcontrol, mc = (struct soc_mixer_control *)kcontrol->private_value; enabled = adx->byte_mask[mc->reg / 32] & (1 << (mc->reg % 32));
+ /* + * TODO: Simplify this logic to just return from bytes_map[] + * + * Presently below is required since bytes_map[] is + * tightly packed and cannot store the control value of 256. + * Byte mask state is used to know if 256 needs to be returned. + * Note that for control value of 256, the put() call stores 0 + * in the bytes_map[] and disables the corresponding bit in + * byte_mask[]. + */ if (enabled) ucontrol->value.integer.value[0] = bytes_map[mc->reg]; else - ucontrol->value.integer.value[0] = 0; + ucontrol->value.integer.value[0] = 256;
return 0; } @@ -192,19 +202,19 @@ static int tegra210_adx_put_byte_map(struct snd_kcontrol *kcontrol, int value = ucontrol->value.integer.value[0]; struct soc_mixer_control *mc = (struct soc_mixer_control *)kcontrol->private_value; + unsigned int mask_val = adx->byte_mask[mc->reg / 32];
- if (value == bytes_map[mc->reg]) + if (value >= 0 && value <= 255) + mask_val |= (1 << (mc->reg % 32)); + else + mask_val &= ~(1 << (mc->reg % 32)); + + if (mask_val == adx->byte_mask[mc->reg / 32]) return 0;
- if (value >= 0 && value <= 255) { - /* update byte map and enable slot */ - bytes_map[mc->reg] = value; - adx->byte_mask[mc->reg / 32] |= (1 << (mc->reg % 32)); - } else { - /* reset byte map and disable slot */ - bytes_map[mc->reg] = 0; - adx->byte_mask[mc->reg / 32] &= ~(1 << (mc->reg % 32)); - } + /* Update byte map and slot */ + bytes_map[mc->reg] = value % 256; + adx->byte_mask[mc->reg / 32] = mask_val;
return 1; }
Following prints are observed while testing audio on Jetson AGX Orin which has onboard RT5640 audio codec:
BUG: sleeping function called from invalid context at kernel/workqueue.c:3027 in_atomic(): 1, irqs_disabled(): 128, non_block: 0, pid: 0, name: swapper/0 preempt_count: 10001, expected: 0 RCU nest depth: 0, expected: 0 ------------[ cut here ]------------ WARNING: CPU: 0 PID: 0 at kernel/irq/handle.c:159 __handle_irq_event_percpu+0x1e0/0x270 ---[ end trace ad1c64905aac14a6 ]-
The IRQ handler rt5640_irq() runs in interrupt context and can sleep during cancel_delayed_work_sync().
Fix this by running IRQ handler, rt5640_irq(), in thread context. Hence replace request_irq() calls with devm_request_threaded_irq().
Fixes: 051dade34695 ("ASoC: rt5640: Fix the wrong state of JD1 and JD2") Cc: stable@vger.kernel.org Cc: Oder Chiou oder_chiou@realtek.com Signed-off-by: Sameer Pujar spujar@nvidia.com --- sound/soc/codecs/rt5640.c | 12 +++++++----- 1 file changed, 7 insertions(+), 5 deletions(-)
diff --git a/sound/soc/codecs/rt5640.c b/sound/soc/codecs/rt5640.c index 0ed4fa2..e24ed75 100644 --- a/sound/soc/codecs/rt5640.c +++ b/sound/soc/codecs/rt5640.c @@ -2567,9 +2567,10 @@ static void rt5640_enable_jack_detect(struct snd_soc_component *component, if (jack_data && jack_data->use_platform_clock) rt5640->use_platform_clock = jack_data->use_platform_clock;
- ret = request_irq(rt5640->irq, rt5640_irq, - IRQF_TRIGGER_RISING | IRQF_TRIGGER_FALLING | IRQF_ONESHOT, - "rt5640", rt5640); + ret = devm_request_threaded_irq(component->dev, rt5640->irq, + NULL, rt5640_irq, + IRQF_TRIGGER_RISING | IRQF_TRIGGER_FALLING | IRQF_ONESHOT, + "rt5640", rt5640); if (ret) { dev_warn(component->dev, "Failed to reguest IRQ %d: %d\n", rt5640->irq, ret); rt5640_disable_jack_detect(component); @@ -2622,8 +2623,9 @@ static void rt5640_enable_hda_jack_detect(
rt5640->jack = jack;
- ret = request_irq(rt5640->irq, rt5640_irq, - IRQF_TRIGGER_RISING | IRQF_ONESHOT, "rt5640", rt5640); + ret = devm_request_threaded_irq(component->dev, rt5640->irq, + NULL, rt5640_irq, IRQF_TRIGGER_RISING | IRQF_ONESHOT, + "rt5640", rt5640); if (ret) { dev_warn(component->dev, "Failed to reguest IRQ %d: %d\n", rt5640->irq, ret); rt5640->irq = -ENXIO;
From: Sameer Pujar
Sent: 29 June 2023 06:12
Following prints are observed while testing audio on Jetson AGX Orin which has onboard RT5640 audio codec:
BUG: sleeping function called from invalid context at kernel/workqueue.c:3027 in_atomic(): 1, irqs_disabled(): 128, non_block: 0, pid: 0, name: swapper/0 preempt_count: 10001, expected: 0 RCU nest depth: 0, expected: 0 ------------[ cut here ]------------ WARNING: CPU: 0 PID: 0 at kernel/irq/handle.c:159 __handle_irq_event_percpu+0x1e0/0x270 ---[ end trace ad1c64905aac14a6 ]-
The IRQ handler rt5640_irq() runs in interrupt context and can sleep during cancel_delayed_work_sync().
Fix this by running IRQ handler, rt5640_irq(), in thread context. Hence replace request_irq() calls with devm_request_threaded_irq().
My 'gut feel' is that this will just move the problem elsewhere.
If the ISR is responsible for adding audio buffers (etc) then it is also not unlikely that the scheduling delays in running a threaded ISR will cause audio glitches if the system is busy.
Fixes: 051dade34695 ("ASoC: rt5640: Fix the wrong state of JD1 and JD2") Cc: stable@vger.kernel.org Cc: Oder Chiou oder_chiou@realtek.com Signed-off-by: Sameer Pujar spujar@nvidia.com
sound/soc/codecs/rt5640.c | 12 +++++++----- 1 file changed, 7 insertions(+), 5 deletions(-)
diff --git a/sound/soc/codecs/rt5640.c b/sound/soc/codecs/rt5640.c index 0ed4fa2..e24ed75 100644 --- a/sound/soc/codecs/rt5640.c +++ b/sound/soc/codecs/rt5640.c @@ -2567,9 +2567,10 @@ static void rt5640_enable_jack_detect(struct snd_soc_component *component, if (jack_data && jack_data->use_platform_clock) rt5640->use_platform_clock = jack_data->use_platform_clock;
- ret = request_irq(rt5640->irq, rt5640_irq,
IRQF_TRIGGER_RISING | IRQF_TRIGGER_FALLING | IRQF_ONESHOT,"rt5640", rt5640);
- ret = devm_request_threaded_irq(component->dev, rt5640->irq,
NULL, rt5640_irq,IRQF_TRIGGER_RISING | IRQF_TRIGGER_FALLING | IRQF_ONESHOT,"rt5640", rt5640);
You need a comment saying this must be a threaded IRQ because the ISR calls cancel_delayed_work_sync().
David
if (ret) { dev_warn(component->dev, "Failed to reguest IRQ %d: %d\n", rt5640->irq, ret); rt5640_disable_jack_detect(component); @@ -2622,8 +2623,9 @@ static void rt5640_enable_hda_jack_detect(
rt5640->jack = jack;
- ret = request_irq(rt5640->irq, rt5640_irq,
IRQF_TRIGGER_RISING | IRQF_ONESHOT, "rt5640", rt5640);
- ret = devm_request_threaded_irq(component->dev, rt5640->irq,
NULL, rt5640_irq, IRQF_TRIGGER_RISING | IRQF_ONESHOT,"rt5640", rt5640);-- 2.7.4
- Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK Registration No: 1397386 (Wales)
On Thu, Jun 29, 2023 at 08:38:09AM +0000, David Laight wrote:
From: Sameer Pujar
Following prints are observed while testing audio on Jetson AGX Orin which has onboard RT5640 audio codec:
BUG: sleeping function called from invalid context at kernel/workqueue.c:3027 in_atomic(): 1, irqs_disabled(): 128, non_block: 0, pid: 0, name: swapper/0
My 'gut feel' is that this will just move the problem elsewhere.
If the ISR is responsible for adding audio buffers (etc) then it is also not unlikely that the scheduling delays in running a threaded ISR will cause audio glitches if the system is busy.
What makes you think this is anything to do with audio glitches? The bug is literally what is described, it is not valid to sleep in atomic contexts and if we ever actually try things are likely to go badly.
From: Mark Brown
Sent: 29 June 2023 11:11
On Thu, Jun 29, 2023 at 08:38:09AM +0000, David Laight wrote:
From: Sameer Pujar
Following prints are observed while testing audio on Jetson AGX Orin which has onboard RT5640 audio codec:
BUG: sleeping function called from invalid context at kernel/workqueue.c:3027 in_atomic(): 1, irqs_disabled(): 128, non_block: 0, pid: 0, name: swapper/0
My 'gut feel' is that this will just move the problem elsewhere.
If the ISR is responsible for adding audio buffers (etc) then it is also not unlikely that the scheduling delays in running a threaded ISR will cause audio glitches if the system is busy.
What makes you think this is anything to do with audio glitches? The bug is literally what is described, it is not valid to sleep in atomic contexts and if we ever actually try things are likely to go badly.
What I mean is that deferring the ISR to process context is likely to generate audio glitches on a busy system.
I realise that sleeping in an ISR goes badly wrong.
David
- Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK Registration No: 1397386 (Wales)
On Thu, Jun 29, 2023 at 10:21:06AM +0000, David Laight wrote:
From: Mark Brown
What makes you think this is anything to do with audio glitches? The bug is literally what is described, it is not valid to sleep in atomic contexts and if we ever actually try things are likely to go badly.
What I mean is that deferring the ISR to process context is likely to generate audio glitches on a busy system.
This is an I2C connected CODEC. We're not doing anything with it in atomic context, and nothing it does is going to be *that* latency sensitive.
From: Sheetal sheetal@nvidia.com
I2S data sanity tests fail beyond a bit clock frequency of 6.144MHz. This happens because the AHUB clock rate is too low and it shows 9.83MHz on boot.
The maximum rate of PLLA_OUT0 is 49.152MHz and is used to serve I/O clocks. It is recommended that AHUB clock operates higher than this. Thus fix this by using PLLP_OUT0 as parent clock for AHUB instead of PLLA_OUT0 and fix the rate to 81.6MHz.
Fixes: dc94a94daa39 ("arm64: tegra: Add audio devices on Tegra234") Cc: stable@vger.kernel.org Signed-off-by: Sheetal sheetal@nvidia.com Signed-off-by: Sameer Pujar spujar@nvidia.com Reviewed-by: Mohan Kumar D mkumard@nvidia.com --- arch/arm64/boot/dts/nvidia/tegra234.dtsi | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/nvidia/tegra234.dtsi b/arch/arm64/boot/dts/nvidia/tegra234.dtsi index f4974e8..0f12a8de 100644 --- a/arch/arm64/boot/dts/nvidia/tegra234.dtsi +++ b/arch/arm64/boot/dts/nvidia/tegra234.dtsi @@ -180,7 +180,8 @@ clocks = <&bpmp TEGRA234_CLK_AHUB>; clock-names = "ahub"; assigned-clocks = <&bpmp TEGRA234_CLK_AHUB>; - assigned-clock-parents = <&bpmp TEGRA234_CLK_PLLA_OUT0>; + assigned-clock-parents = <&bpmp TEGRA234_CLK_PLLP_OUT0>; + assigned-clock-rates = <81600000>; status = "disabled";
#address-cells = <2>;
I2S data sanity test failures are seen at lower AHUB clock rates on Tegra234. The Tegra194 uses the same clock relationship for AHUB and it is likely that similar issues would be seen. Thus update the AHUB clock parent and rates here as well for Tegra194, Tegra186 and Tegra210.
Fixes: 177208f7b06d ("arm64: tegra: Add DT binding for AHUB components") Cc: stable@vger.kernel.org Signed-off-by: Sameer Pujar spujar@nvidia.com --- arch/arm64/boot/dts/nvidia/tegra186.dtsi | 3 ++- arch/arm64/boot/dts/nvidia/tegra194.dtsi | 3 ++- arch/arm64/boot/dts/nvidia/tegra210.dtsi | 3 ++- 3 files changed, 6 insertions(+), 3 deletions(-)
diff --git a/arch/arm64/boot/dts/nvidia/tegra186.dtsi b/arch/arm64/boot/dts/nvidia/tegra186.dtsi index 7e4c496f..2b3bb5d 100644 --- a/arch/arm64/boot/dts/nvidia/tegra186.dtsi +++ b/arch/arm64/boot/dts/nvidia/tegra186.dtsi @@ -135,7 +135,8 @@ clocks = <&bpmp TEGRA186_CLK_AHUB>; clock-names = "ahub"; assigned-clocks = <&bpmp TEGRA186_CLK_AHUB>; - assigned-clock-parents = <&bpmp TEGRA186_CLK_PLL_A_OUT0>; + assigned-clock-parents = <&bpmp TEGRA186_CLK_PLLP_OUT0>; + assigned-clock-rates = <81600000>; #address-cells = <1>; #size-cells = <1>; ranges = <0x02900800 0x02900800 0x11800>; diff --git a/arch/arm64/boot/dts/nvidia/tegra194.dtsi b/arch/arm64/boot/dts/nvidia/tegra194.dtsi index 154fc8c..33f92b7 100644 --- a/arch/arm64/boot/dts/nvidia/tegra194.dtsi +++ b/arch/arm64/boot/dts/nvidia/tegra194.dtsi @@ -231,7 +231,8 @@ clocks = <&bpmp TEGRA194_CLK_AHUB>; clock-names = "ahub"; assigned-clocks = <&bpmp TEGRA194_CLK_AHUB>; - assigned-clock-parents = <&bpmp TEGRA194_CLK_PLLA_OUT0>; + assigned-clock-parents = <&bpmp TEGRA194_CLK_PLLP_OUT0>; + assigned-clock-rates = <81600000>; status = "disabled";
#address-cells = <2>; diff --git a/arch/arm64/boot/dts/nvidia/tegra210.dtsi b/arch/arm64/boot/dts/nvidia/tegra210.dtsi index 617583f..e7b4e30 100644 --- a/arch/arm64/boot/dts/nvidia/tegra210.dtsi +++ b/arch/arm64/boot/dts/nvidia/tegra210.dtsi @@ -1386,7 +1386,8 @@ clocks = <&tegra_car TEGRA210_CLK_D_AUDIO>; clock-names = "ahub"; assigned-clocks = <&tegra_car TEGRA210_CLK_D_AUDIO>; - assigned-clock-parents = <&tegra_car TEGRA210_CLK_PLL_A_OUT0>; + assigned-clock-parents = <&tegra_car TEGRA210_CLK_PLL_P>; + assigned-clock-rates = <81600000>; #address-cells = <1>; #size-cells = <1>; ranges = <0x702d0000 0x702d0000 0x0000e400>;
On Thu, 29 Jun 2023 10:42:12 +0530, Sameer Pujar wrote:
This series fixes some of the issues which were observed during an attempt to enhance automated test coverage on Jetson AGX Orin. Below is a short summary of the issues and fixes:
- Sample rate coversion failures above 48kHz.
- AMX and ADX test cases failures due to incorrect byte mask.
- Atomic sleep in RT5640 codec which is present on Jetson AGX Orin.
- AHUB clock fixes on Tegra234 and previous chips.
- Minor cleanups in ASRC and AHUB driver.
[...]
Applied to
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-next
Thanks!
[1/5] ASoC: tegra: Fix AMX byte map commit: 49bd7b08149417a30aa7d92c8c85b3518de44a76 [2/5] ASoC: tegra: Fix ADX byte map commit: 6dfe70be0b0dec0f9297811501bec26c05fd96ad [3/5] ASoC: rt5640: Fix sleep in atomic context commit: 70a6404ff610aa4889d98977da131c37f9ff9d1f
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
From: Thierry Reding treding@nvidia.com
On Thu, 29 Jun 2023 10:42:12 +0530, Sameer Pujar wrote:
This series fixes some of the issues which were observed during an attempt to enhance automated test coverage on Jetson AGX Orin. Below is a short summary of the issues and fixes:
- Sample rate coversion failures above 48kHz.
- AMX and ADX test cases failures due to incorrect byte mask.
- Atomic sleep in RT5640 codec which is present on Jetson AGX Orin.
- AHUB clock fixes on Tegra234 and previous chips.
- Minor cleanups in ASRC and AHUB driver.
[...]
Applied, thanks!
[4/5] arm64: tegra: Update AHUB clock parent and rate on Tegra234 commit: e483fe34adab3197558b7284044c1b26f5ede20e [5/5] arm64: tegra: Update AHUB clock parent and rate commit: dc6d5d85ed3a3fe566314f388bce4c71a26b1677
Best regards,
participants (4)
-
David Laight -
Mark Brown -
Sameer Pujar -
Thierry Reding