- Alsa-devel - mailman.alsa-project.org

[alsa-devel] Attempting to understand odd snd-usb-audio code and behavior
by Keith A. Milner 21 Aug '20

21 Aug '20

Over the last few weeks I've been trying to dig through the snd-usb-audio code to try to get an understanding of it. I've used ftrace and also a local version which I have heavily polluted with kprintf(KERN_INFO statements so I can track what it's doing in practice. I've been playing with this with some USB audio interfaces I have some which work, and some which don't, and trying to understand the differences and, ultimately, what I can do to make the non-functioning ones work. I've got to the point where I have a fairly good understanding of some parts, but I'm struggling to understand why the code is behaving as it does in practice. My observation when plugging the USB device in is that, as expected, it tries to build the audio device, and add components to it including attaching capture and playback streams. It seems to go through this phase without too many surprises, and we get to the standard dmesg output: usbcore: registered new interface driver snd-usb-audio After this, it gets confusing. It seems to open and close the PCMs (e.g, snd_usb_capture_open) several times in a row. Each time it sets up the hardware info, checks and sets the format and then closes the PCM. I don't see anything obviously different between most of these cycles. Here's an example my logging output (hopefully this will make sense): Aug 22 20:04:16 kerneldev kernel: [ 923.140789] Called: pcm.c - snd_usb_capture_open for pcm substream 0 Aug 22 20:04:16 kerneldev kernel: [ 923.140789] Called: pcm.c - snd_usb_pcm_open for pcm substream 0 Aug 22 20:04:16 kerneldev kernel: [ 923.140789] Setting up hw info Aug 22 20:04:16 kerneldev kernel: [ 923.140789] Checking format: Aug 22 20:04:16 kerneldev kernel: [ 923.140790] Interface number = 2 Aug 22 20:04:16 kerneldev kernel: [ 923.140790] alt setting = 1 Aug 22 20:04:16 kerneldev kernel: [ 923.140790] alt setting index = 1 Aug 22 20:04:16 kerneldev kernel: [ 923.140790] format type = 1 Aug 22 20:04:16 kerneldev kernel: [ 923.140790] frame size = 0 Aug 22 20:04:16 kerneldev kernel: [ 923.140791] Setting pt=125 ptmin=125 Aug 22 20:04:16 kerneldev kernel: [ 923.140792] Checking for unusual bit rates Aug 22 20:04:16 kerneldev kernel: [ 923.140794] Called: init.c - snd_card_file_remove Aug 22 20:04:16 kerneldev kernel: [ 923.140921] Called: pcm.c - snd_usb_hw_params for pcm substream 0 Aug 22 20:04:16 kerneldev kernel: [ 923.140945] Setting format: Aug 22 20:04:16 kerneldev kernel: [ 923.140945] Bytes per period = 8816 Aug 22 20:04:16 kerneldev kernel: [ 923.140945] Frames per period = 1102 Aug 22 20:04:16 kerneldev kernel: [ 923.140946] Periods per buffer = 4 Aug 22 20:04:16 kerneldev kernel: [ 923.140946] Channels = 2 Aug 22 20:04:16 kerneldev kernel: [ 923.140946] Rate = 44100 Aug 22 20:04:16 kerneldev kernel: [ 923.141279] Called: endpoint.c - snd_usb_add_endpoint of type 0 with direction 1 Aug 22 20:04:16 kerneldev kernel: [ 923.141292] Called: pcm.c - snd_usb_pcm_prepare for pcm substream 0 Aug 22 20:04:16 kerneldev kernel: [ 923.141293] Called: pcm.c - configure_endpoint Aug 22 20:04:16 kerneldev kernel: [ 923.141294] Called: endpoint.c - snd_usb_endpoint_set_params for endpoint 142, type 0 Aug 22 20:04:16 kerneldev kernel: [ 923.141294] Setting endpoint params for endpoint num 142 Aug 22 20:04:16 kerneldev kernel: [ 923.141294] channels=2 Aug 22 20:04:16 kerneldev kernel: [ 923.141294] period bytes=8816 Aug 22 20:04:16 kerneldev kernel: [ 923.141295] frames per period=1102 Aug 22 20:04:16 kerneldev kernel: [ 923.141295] periods per buffer=4 Aug 22 20:04:16 kerneldev kernel: [ 923.141296] Called: endpoint.c - data_ep_set_params for endpoint 142, type 0 Aug 22 20:04:16 kerneldev kernel: [ 923.141301] Called: pcm.c - snd_usb_pcm_prepare for pcm substream 0 Aug 22 20:04:16 kerneldev kernel: [ 923.142768] Called: init.c - snd_card_file_add Aug 22 20:04:16 kerneldev kernel: [ 923.142772] Called: init.c - snd_card_file_remove Aug 22 20:04:16 kerneldev kernel: [ 923.142774] Called: init.c - snd_card_file_add Aug 22 20:04:16 kerneldev kernel: [ 923.142830] Called: init.c - snd_card_file_remove Aug 22 20:04:16 kerneldev kernel: [ 923.142836] Called: pcm.c - snd_usb_hw_free for pcm substream 0 Aug 22 20:04:16 kerneldev kernel: [ 923.142837] Called: endpoint.c - snd_usb_endpoint_deactivate for endpoint 142, type 0 Aug 22 20:04:16 kerneldev kernel: [ 923.142846] Called: pcm.c - snd_usb_capture_close for pcm substream 0 Aug 22 20:04:16 kerneldev kernel: [ 923.146760] Called: init.c - snd_card_file_remove Aug 22 20:04:16 kerneldev kernel: [ 923.146834] Called: init.c - snd_card_file_add Aug 22 20:04:16 kerneldev kernel: [ 923.146838] Called: init.c - snd_card_file_remove Aug 22 20:04:16 kerneldev kernel: [ 923.146841] Called: init.c - snd_card_file_add Aug 22 20:04:16 kerneldev kernel: [ 923.146845] Called: init.c - snd_card_file_add Aug 22 20:04:16 kerneldev kernel: [ 923.146848] Called: pcm.c - snd_usb_capture_open for pcm substream 0 Aug 22 20:04:16 kerneldev kernel: [ 923.146849] Called: pcm.c - snd_usb_pcm_open for pcm substream 0 Aug 22 20:04:16 kerneldev kernel: [ 923.146849] Setting up hw info It seems to do this several times, before the behavior changing slightly, as it now starts to try to set the endpoint parameters and seems to leave the stream open. However, it then tries to open the stream and set the endpoint parameters again resulting in errors: Aug 22 20:22:00 kerneldev kernel: [ 1987.452945] Called: endpoint.c - snd_usb_endpoint_set_params for endpoint 142, type 0 Aug 22 20:22:00 kerneldev kernel: [ 1987.452945] Setting endpoint params for endpoint num 142 Aug 22 20:22:00 kerneldev kernel: [ 1987.452945] channels=2 Aug 22 20:22:00 kerneldev kernel: [ 1987.452945] period bytes=1768 Aug 22 20:22:00 kerneldev kernel: [ 1987.452946] frames per period=221 Aug 22 20:22:00 kerneldev kernel: [ 1987.452946] periods per buffer=593 Aug 22 20:22:00 kerneldev kernel: [ 1987.452947] usb 1-1: Unable to change format on ep #8e: already in use Maybe this is driven by hotplug or something, but it seems to be performing a lot of pointless activities. Eventually it seems to try to open the PCM playback or capture stream (with some devices it opens playback, with others capture) and then checks the pointer: Aug 22 20:22:00 kerneldev kernel: [ 1987.470194] Called: pcm.c - snd_usb_substream_playback_trigger for pcm substream 0 Aug 22 20:22:00 kerneldev kernel: [ 1987.470198] Called: pcm.c - snd_usb_pcm_pointer for pcm substream 0 Aug 22 20:22:00 kerneldev kernel: [ 1987.470198] Pointer is 0 Aug 22 20:22:00 kerneldev kernel: [ 1987.470656] Called: pcm.c - snd_usb_pcm_pointer for pcm substream 0 Aug 22 20:22:00 kerneldev kernel: [ 1987.470657] Pointer is 0 Aug 22 20:22:00 kerneldev kernel: [ 1987.470660] Called: pcm.c - snd_usb_pcm_pointer for pcm substream 0 Aug 22 20:22:00 kerneldev kernel: [ 1987.470660] Pointer is 0 Aug 22 20:22:05 kerneldev kernel: [ 1992.473567] Called: pcm.c - snd_usb_pcm_pointer for pcm substream 0 Aug 22 20:22:05 kerneldev kernel: [ 1992.473569] Pointer is 0 The above is from a non-working device. For a working device the pointer increments. Eventually this activity ends: Aug 22 20:22:05 kerneldev kernel: [ 1992.473575] Called: pcm.c - snd_usb_substream_playback_trigger for pcm substream 0 Aug 22 20:22:05 kerneldev kernel: [ 1992.473576] Called: endpoint.c - snd_usb_endpoint_stop for endpoint 142, type 0 Aug 22 20:22:05 kerneldev kernel: [ 1992.473578] Called: endpoint.c - snd_usb_endpoint_stop for endpoint 13, type 0 Aug 22 20:22:05 kerneldev kernel: [ 1992.473602] Called: pcm.c - snd_usb_hw_free for pcm substream 0 Aug 22 20:22:05 kerneldev kernel: [ 1992.503287] Called: endpoint.c - snd_usb_endpoint_deactivate for endpoint 142, type 0 Aug 22 20:22:05 kerneldev kernel: [ 1992.503288] Called: endpoint.c - snd_usb_endpoint_deactivate for endpoint 13, type 0 Aug 22 20:22:05 kerneldev kernel: [ 1992.503323] Called: pcm.c - snd_usb_playback_close for pcm substream 0 Aug 22 20:22:05 kerneldev kernel: [ 1992.503656] Called: init.c - snd_card_file_remove This seems as if it might be some sort of test of the PCMs, to make sure they are working. Certainly in non-working devices the pcm_pointer stays at zero and in working devices it increments. It also seems to try harder with some devices than others, even though the device descriptors seem very similar. Can anyone explain any of this to me, particularly why it's exhibiting this behaviour. I've uploaded one of the logs from a non-working device to Pastebin if anyone wants to look at a full example: https://pastebin.com/uBZEuQ57 Also, is this the best way to approach this, or are there other tools/techniques that can help? I've experimented with ftrace and that was useful, but didn't give the level of detail I wanted. Cheers, Keith

3 10

[PATCH 0/2] soundwire: fix port_ready[] dynamic allocation in
by Bard Liao 21 Aug '20

21 Aug '20

The existing code allocates memory for the total number of ports. This only works if the ports are contiguous, but will break if e.g. a Devices uses port0, 1, and 14. The port_ready[] array would contain 3 elements, which would lead to an out-of-bounds access. Conversely in other cases, the wrong port index would be used leading to timeouts on prepare. This can be fixed by allocating for the worst-case of 15 ports (DP0..DP14). In addition since the number is now fixed, we can use an array instead of a dynamic allocation. Pierre-Louis Bossart (2): soundwire: add definition for maximum number of ports soundwire: fix port_ready[] dynamic allocation in mipi_disco and ASoC codecs drivers/soundwire/mipi_disco.c | 18 +----------------- drivers/soundwire/slave.c | 4 ++++ include/linux/soundwire/sdw.h | 5 +++-- sound/soc/codecs/max98373-sdw.c | 15 +-------------- sound/soc/codecs/rt1308-sdw.c | 14 +------------- sound/soc/codecs/rt5682-sdw.c | 15 +-------------- sound/soc/codecs/rt700-sdw.c | 15 +-------------- sound/soc/codecs/rt711-sdw.c | 15 +-------------- sound/soc/codecs/rt715-sdw.c | 33 +-------------------------------- 9 files changed, 14 insertions(+), 120 deletions(-) -- 2.17.1

4 9

[PATCH v2] soundwire: SDCA: add helper macro to access controls
by Bard Liao 21 Aug '20

21 Aug '20

From: Pierre-Louis Bossart <pierre-louis.bossart(a)linux.intel.com> The upcoming SDCA (SoundWire Device Class Audio) specification defines a hiearchical encoding to interface with Class-defined capabilities, based on which audio function, entity, control and channel being used. The specification is not yet accessible to the general public but this information is released with explicit permission from the MIPI Board to avoid delays with SDCA support on Linux platforms. Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart(a)linux.intel.com> Reviewed-by: Rander Wang <rander.wang(a)linux.intel.com> Reviewed-by: Guennadi Liakhovetski <guennadi.liakhovetski(a)linux.intel.com> Signed-off-by: Bard Liao <yung-chuan.liao(a)linux.intel.com> --- Changelog: v2: - add SDW_SDCA_MBQ_CTL --- include/linux/soundwire/sdw_registers.h | 12 ++++++++++++ 1 file changed, 12 insertions(+) diff --git a/include/linux/soundwire/sdw_registers.h b/include/linux/soundwire/sdw_registers.h index 5d3c271af7d1..4517c0f65b4f 100644 --- a/include/linux/soundwire/sdw_registers.h +++ b/include/linux/soundwire/sdw_registers.h @@ -305,4 +305,16 @@ #define SDW_CASC_PORT_MASK_INTSTAT3 1 #define SDW_CASC_PORT_REG_OFFSET_INTSTAT3 2 +/* v1.2 device - SDCA address mapping */ +#define SDW_SDCA_CTL(fun, ent, ctl, ch) (BIT(30) | \ + (((fun) & 0x7) << 22) | \ + (((ent) & 0x40) << 15) | \ + (((ent) & 0x3f) << 7) | \ + (((ctl) & 0x30) << 15) | \ + (((ctl) & 0x0f) << 3) | \ + (((ch) & 0x38) << 12) | \ + ((ch) & 0x07)) + +#define SDW_SDCA_MBQ_CTL(reg) ((reg) | BIT(13)) + #endif /* __SDW_REGISTERS_H */ -- 2.17.1

3 3

[RESEND] ASoC: SOF: Intel: add build support for SoundWire
by Bard Liao 20 Aug '20

20 Aug '20

From: Pierre-Louis Bossart <pierre-louis.bossart(a)linux.intel.com> Select SoundWire capabilities on newer Intel platforms, starting with CannonLake/CoffeeLake/CometLake. As done for HDaudio, the SoundWire link is an opt-in capability. We explicitly test for ACPI to avoid warnings on unmet dependencies on the SoundWire side. Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart(a)linux.intel.com> Signed-off-by: Bard Liao <yung-chuan.liao(a)linux.intel.com> --- sound/soc/sof/intel/Kconfig | 29 +++++++++++++++++++++++++++++ 1 file changed, 29 insertions(+) diff --git a/sound/soc/sof/intel/Kconfig b/sound/soc/sof/intel/Kconfig index 3aaf25e4f766..f644010cc568 100644 --- a/sound/soc/sof/intel/Kconfig +++ b/sound/soc/sof/intel/Kconfig @@ -166,6 +166,7 @@ config SND_SOC_SOF_CANNONLAKE_SUPPORT config SND_SOC_SOF_CANNONLAKE tristate select SND_SOC_SOF_HDA_COMMON + select SND_SOC_SOF_INTEL_SOUNDWIRE_LINK_BASELINE help This option is not user-selectable but automagically handled by 'select' statements at a higher level @@ -181,6 +182,7 @@ config SND_SOC_SOF_COFFEELAKE_SUPPORT config SND_SOC_SOF_COFFEELAKE tristate select SND_SOC_SOF_HDA_COMMON + select SND_SOC_SOF_INTEL_SOUNDWIRE_LINK_BASELINE help This option is not user-selectable but automagically handled by 'select' statements at a higher level @@ -196,6 +198,7 @@ config SND_SOC_SOF_ICELAKE_SUPPORT config SND_SOC_SOF_ICELAKE tristate select SND_SOC_SOF_HDA_COMMON + select SND_SOC_SOF_INTEL_SOUNDWIRE_LINK_BASELINE help This option is not user-selectable but automagically handled by 'select' statements at a higher level @@ -203,6 +206,7 @@ config SND_SOC_SOF_ICELAKE config SND_SOC_SOF_COMETLAKE tristate select SND_SOC_SOF_HDA_COMMON + select SND_SOC_SOF_INTEL_SOUNDWIRE_LINK_BASELINE help This option is not user-selectable but automagically handled by 'select' statements at a higher level @@ -229,6 +233,7 @@ config SND_SOC_SOF_TIGERLAKE_SUPPORT config SND_SOC_SOF_TIGERLAKE tristate select SND_SOC_SOF_HDA_COMMON + select SND_SOC_SOF_INTEL_SOUNDWIRE_LINK_BASELINE help This option is not user-selectable but automagically handled by 'select' statements at a higher level @@ -244,6 +249,7 @@ config SND_SOC_SOF_ELKHARTLAKE_SUPPORT config SND_SOC_SOF_ELKHARTLAKE tristate select SND_SOC_SOF_HDA_COMMON + select SND_SOC_SOF_INTEL_SOUNDWIRE_LINK_BASELINE help This option is not user-selectable but automagically handled by 'select' statements at a higher level @@ -329,6 +335,29 @@ config SND_SOC_SOF_HDA This option is not user-selectable but automagically handled by 'select' statements at a higher level +config SND_SOC_SOF_INTEL_SOUNDWIRE_LINK + bool "SOF support for SoundWire" + depends on SOUNDWIRE && ACPI + help + This adds support for SoundWire with Sound Open Firmware + for Intel(R) platforms. + Say Y if you want to enable SoundWire links with SOF. + If unsure select "N". + +config SND_SOC_SOF_INTEL_SOUNDWIRE_LINK_BASELINE + tristate + select SND_SOC_SOF_INTEL_SOUNDWIRE if SND_SOC_SOF_INTEL_SOUNDWIRE_LINK + help + This option is not user-selectable but automagically handled by + 'select' statements at a higher level + +config SND_SOC_SOF_INTEL_SOUNDWIRE + tristate + select SOUNDWIRE_INTEL + help + This option is not user-selectable but automagically handled by + 'select' statements at a higher level + endif ## SND_SOC_SOF_INTEL_PCI endif ## SND_SOC_SOF_INTEL_TOPLEVEL -- 2.17.1

4 3

[RESEND] ASoC: SOF: Intel: hda: import SOUNDWIRE_INIT namespace
by Bard Liao 20 Aug '20

20 Aug '20

From: Pierre-Louis Bossart <pierre-louis.bossart(a)linux.intel.com> Make sure the SoundWire driver can be loaded Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart(a)linux.intel.com> Signed-off-by: Bard Liao <yung-chuan.liao(a)linux.intel.com> --- sound/soc/sof/intel/hda.c | 1 + 1 file changed, 1 insertion(+) diff --git a/sound/soc/sof/intel/hda.c b/sound/soc/sof/intel/hda.c index 63ca920c8e6e..c0b75d682750 100644 --- a/sound/soc/sof/intel/hda.c +++ b/sound/soc/sof/intel/hda.c @@ -1207,3 +1207,4 @@ MODULE_LICENSE("Dual BSD/GPL"); MODULE_IMPORT_NS(SND_SOC_SOF_HDA_AUDIO_CODEC); MODULE_IMPORT_NS(SND_SOC_SOF_HDA_AUDIO_CODEC_I915); MODULE_IMPORT_NS(SND_SOC_SOF_XTENSA); +MODULE_IMPORT_NS(SOUNDWIRE_INTEL_INIT); -- 2.17.1

2 1

[PATCH][next] ASoC: qcom: add missing out of memory check on drvdata->clks allocation
by Colin King 20 Aug '20

20 Aug '20

From: Colin Ian King <colin.king(a)canonical.com> Currently drvdata->clks is not being checked for an allocation failure, leading to potential null pointer dereferencing. Fix this by adding a check and returning -ENOMEM if an error occurred. Addresses-Coverity: ("Dereference null return value") Fixes: 1220f6a76e77 ("ASoC: qcom: Add common array to initialize soc based core clocks") Signed-off-by: Colin Ian King <colin.king(a)canonical.com> --- sound/soc/qcom/lpass-apq8016.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/sound/soc/qcom/lpass-apq8016.c b/sound/soc/qcom/lpass-apq8016.c index dd9e3dd014f6..5c8ae225cd5d 100644 --- a/sound/soc/qcom/lpass-apq8016.c +++ b/sound/soc/qcom/lpass-apq8016.c @@ -168,6 +168,8 @@ static int apq8016_lpass_init(struct platform_device *pdev) drvdata->clks = devm_kcalloc(dev, variant->num_clks, sizeof(*drvdata->clks), GFP_KERNEL); + if (!drvdata->clks) + return -ENOMEM; drvdata->num_clks = variant->num_clks; for (i = 0; i < drvdata->num_clks; i++) -- 2.27.0

3 2

Re: [PATCH v2 00/41] spi / fbdev / cpufreq / usb / mmc / hwmon / ARM: Prepare for multiplatform S3C
by Krzysztof Kozlowski 20 Aug '20

20 Aug '20

On Thu, Aug 06, 2020 at 08:19:32PM +0200, Krzysztof Kozlowski wrote: > Hi All, > > Shortly > ======= > This is a continuation of Arnd's work from 2019 [1]. The goal is to > cleanup, merge and finally make the Samsung S3C24xx and S3C64xx > architectures multiplatform. The multiplatform did not happen yet > here... just cleaning up and merging into one mach-s3c. > > I intend to take it through Samsung SoC tree so all Acks are welcomed. > > Changes since v1 > ================ > 1. Rebased, > 2. Addressed comments (including mine), > 3. Few new patches. > > Please see individual changelogs (per patch). > > [1] https://patchwork.kernel.org/project/linux-samsung-soc/list/?series=185855&… > Hi All, I applied second part of the set which finishes this step of S3C cleanup. Thanks to Arnd for the work! Best regards, Krzysztof

1 0

JamVOX usb soundcard works only after windows reboot
by Krabador 20 Aug '20

20 Aug '20

Hi alsa-devel team. This device from linux from 5.2 (my first plug) to now with 5.8.1, the only way to use it properly is to run linux after windows reboot. If linux is run at poweron, the device is correctly seen by the kernel but muted. Here the results of alsa-info.sh when card is working , not working, a diff, dmesg and lsusb -v https://paste.ee/p/YrJSP#pRmvQ58T7sCeulHr1ZSluw2cTQt7exsh Waiting to give more information, Best Regards.

1 1

[PATCH v6 0/2] Add mediatek codec mt6359 driver
by Jiaxin Yu 20 Aug '20

20 Aug '20

Add mediatek codec (MT6359) driver MT6359 support playback and capture feature. On downlink path, it includes three DACs for handset, headset, and lineout path. On unlink path, it includeds three ADCs for main mic, second mic, 3rd mic, and headset mic. By scenario, select *_MUX widget to create damp path. And by select mic_type_mux to choose DMIC/AMIC/.... For example, select these MUX widget to create headset path (1) DAC In Mux --> "Normal Path" (2) HP Mux --> "Audio Playback" v6 changes: 1. Remove the compatible string in mt6359codec because MFD should be registering the platform device. v5 changes: 1. Don't need to unregister the component whic is already relegated to devm. 2. patchwork link: https://patchwork.kernel.org/cover/11716387/ https://patchwork.kernel.org/patch/11717757/ https://patchwork.kernel.org/patch/11716491/ v4 changes: 1. Add a remove() function to undo regulator_enable(). 2. Removed unnecessary logs. 3. patchwork link: https://patchwork.kernel.org/cover/11715553/ https://patchwork.kernel.org/patch/11716015/ https://patchwork.kernel.org/patch/11715557/ v3 changes: 1. patchwork link: https://patchwork.kernel.org/cover/11714291/ https://patchwork.kernel.org/patch/11714295/ https://patchwork.kernel.org/patch/11714339/ v2 changes: 1. patchwork link: https://patchwork.kernel.org/cover/11706935/ https://patchwork.kernel.org/patch/11708865/ https://patchwork.kernel.org/patch/11706937/ v1 changes: 1.lkml link: https://lkml.org/lkml/2020/3/5/1257 Jiaxin Yu (2): ASoC: mediatek: mt6359: add codec driver dt-bindings: mediatek: mt6359: add codec document .../devicetree/bindings/sound/mt6359.yaml | 61 + sound/soc/codecs/Kconfig | 8 + sound/soc/codecs/Makefile | 2 + sound/soc/codecs/mt6359.c | 2753 +++++++++++++++++ sound/soc/codecs/mt6359.h | 2640 ++++++++++++++++ 5 files changed, 5464 insertions(+) create mode 100644 Documentation/devicetree/bindings/sound/mt6359.yaml create mode 100644 sound/soc/codecs/mt6359.c create mode 100644 sound/soc/codecs/mt6359.h -- 2.18.0

2 3

Request to pick up couple NVIDIA Tegra ASoC patches into 5.7 kernel
by Dmitry Osipenko 20 Aug '20

20 Aug '20

Hello, stable-kernel maintainers! Could you please cherry-pick these commits into the v5.7.x kernel? commit 0de6db30ef79b391cedd749801a49c485d2daf4b Author: Sowjanya Komatineni <skomatineni(a)nvidia.com> Date: Mon Jan 13 23:24:17 2020 -0800 ASoC: tegra: Use device managed resource APIs to get the clock commit 1e4e0bf136aa4b4aa59c1e6af19844bd6d807794 Author: Sowjanya Komatineni <skomatineni(a)nvidia.com> Date: Mon Jan 13 23:24:23 2020 -0800 ASoC: tegra: Add audio mclk parent configuration commit ff5d18cb04f4ecccbcf05b7f83ab6df2a0d95c16 Author: Sowjanya Komatineni <skomatineni(a)nvidia.com> Date: Mon Jan 13 23:24:24 2020 -0800 ASoC: tegra: Enable audio mclk during tegra_asoc_utils_init() It will fix a huge warnings splat during of kernel boot on NVIDIA Tegra SoCs. For some reason these patches haven't made into 5.7 when it was released and several people complained about the warnings. Thanks in advance!

3 3