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

[alsa-devel] MOTU Midi Express XT
by holger＠dehnhardt.org 02 Jan '26

02 Jan '26

I own a MOTU Midi Express XT 8x8 interface which is connected through the parallel port. Recently I upgraded my system and the new motherboard does not have an ISA parallel port anymore... So I bought a PCI parallel port extension card - hoping that it will work with the ALSA driver (mtpav). So I changed the interrupt an port address in modules.conf but the driver is no longer recognized as an ALSA driver even though it loads without errors. As the device still perfectly fits my needs I would like to modify the driver to get it working again. Can anyone give me advice what should be changed in the drivers code to make it work on a pci port? Thanks Holger

4 14

[alsa-devel] Applied "ASoC: tlv320aic32x4: Model CODEC_CLKIN in CCF" to the asoc tree
by Mark Brown 29 Dec '25

29 Dec '25

The patch ASoC: tlv320aic32x4: Model CODEC_CLKIN in CCF has been applied to the asoc tree at https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git 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 fd2df3aeafa4b4cc468d58e147e0822967034b71 Mon Sep 17 00:00:00 2001 From: Annaliese McDermond <nh6z(a)nh6z.net> Date: Thu, 21 Mar 2019 17:58:46 -0700 Subject: [PATCH] ASoC: tlv320aic32x4: Model CODEC_CLKIN in CCF Model and manage codec clock input as a component in the Core Clock Framework. This should allow us to do some more complex clock management and power control. Also, some of the on-board chip clocks can be exposed to the outside, and this change will make those clocks easier to consume by other parts of the kernel. Signed-off-by: Annaliese McDermond <nh6z(a)nh6z.net> Signed-off-by: Mark Brown <broonie(a)kernel.org> --- sound/soc/codecs/tlv320aic32x4-clk.c | 34 ++++++++++++++++++++++++++++ sound/soc/codecs/tlv320aic32x4.c | 18 +++++++++++---- 2 files changed, 47 insertions(+), 5 deletions(-) diff --git a/sound/soc/codecs/tlv320aic32x4-clk.c b/sound/soc/codecs/tlv320aic32x4-clk.c index 5e495fc8d931..cded85009c8c 100644 --- a/sound/soc/codecs/tlv320aic32x4-clk.c +++ b/sound/soc/codecs/tlv320aic32x4-clk.c @@ -265,6 +265,30 @@ static const struct clk_ops aic32x4_pll_ops = { .get_parent = clk_aic32x4_pll_get_parent, }; +static int clk_aic32x4_codec_clkin_set_parent(struct clk_hw *hw, u8 index) +{ + struct clk_aic32x4 *mux = to_clk_aic32x4(hw); + + return regmap_update_bits(mux->regmap, + AIC32X4_CLKMUX, + AIC32X4_CODEC_CLKIN_MASK, index << AIC32X4_CODEC_CLKIN_SHIFT); +} + +static u8 clk_aic32x4_codec_clkin_get_parent(struct clk_hw *hw) +{ + struct clk_aic32x4 *mux = to_clk_aic32x4(hw); + unsigned int val; + + regmap_read(mux->regmap, AIC32X4_CLKMUX, &val); + + return (val & AIC32X4_CODEC_CLKIN_MASK) >> AIC32X4_CODEC_CLKIN_SHIFT; +} + +static const struct clk_ops aic32x4_codec_clkin_ops = { + .set_parent = clk_aic32x4_codec_clkin_set_parent, + .get_parent = clk_aic32x4_codec_clkin_get_parent, +}; + static struct aic32x4_clkdesc aic32x4_clkdesc_array[] = { { .name = "pll", @@ -274,6 +298,14 @@ static struct aic32x4_clkdesc aic32x4_clkdesc_array[] = { .ops = &aic32x4_pll_ops, .reg = 0, }, + { + .name = "codec_clkin", + .parent_names = + (const char *[]) { "mclk", "bclk", "gpio", "pll" }, + .num_parents = 4, + .ops = &aic32x4_codec_clkin_ops, + .reg = 0, + }, }; static struct clk *aic32x4_register_clk(struct device *dev, @@ -314,6 +346,8 @@ int aic32x4_register_clocks(struct device *dev, const char *mclk_name) */ aic32x4_clkdesc_array[0].parent_names = (const char* []) { mclk_name, "bclk", "gpio", "din" }; + aic32x4_clkdesc_array[1].parent_names = + (const char *[]) { mclk_name, "bclk", "gpio", "pll" }; for (i = 0; i < ARRAY_SIZE(aic32x4_clkdesc_array); ++i) aic32x4_register_clk(dev, &aic32x4_clkdesc_array[i]); diff --git a/sound/soc/codecs/tlv320aic32x4.c b/sound/soc/codecs/tlv320aic32x4.c index 7cf8c7cedfe1..5496e4e080f4 100644 --- a/sound/soc/codecs/tlv320aic32x4.c +++ b/sound/soc/codecs/tlv320aic32x4.c @@ -735,12 +735,9 @@ static int aic32x4_setup_clocks(struct snd_soc_component *component, aic32x4_set_processing_blocks(component, aic32x4_divs[i].r_block, aic32x4_divs[i].p_block); - /* PLL as CODEC_CLKIN */ - snd_soc_component_update_bits(component, AIC32X4_CLKMUX, - AIC32X4_CODEC_CLKIN_MASK, - AIC32X4_CODEC_CLKIN_PLL << AIC32X4_CODEC_CLKIN_SHIFT); /* DAC_MOD_CLK as BDIV_CLKIN */ - snd_soc_component_update_bits(component, AIC32X4_IFACE3, AIC32X4_BDIVCLK_MASK, + snd_soc_component_update_bits(component, AIC32X4_IFACE3, + AIC32X4_BDIVCLK_MASK, AIC32X4_DACMOD2BCLK << AIC32X4_BDIVCLK_SHIFT); /* NDAC divider value */ @@ -987,6 +984,15 @@ static int aic32x4_component_probe(struct snd_soc_component *component) { struct aic32x4_priv *aic32x4 = snd_soc_component_get_drvdata(component); u32 tmp_reg; + int ret; + + struct clk_bulk_data clocks[] = { + { .id = "codec_clkin" }, + }; + + ret = devm_clk_bulk_get(component->dev, ARRAY_SIZE(clocks), clocks); + if (ret) + return ret; if (gpio_is_valid(aic32x4->rstn_gpio)) { ndelay(10); @@ -999,6 +1005,8 @@ static int aic32x4_component_probe(struct snd_soc_component *component) if (aic32x4->setup) aic32x4_setup_gpios(component); + clk_set_parent(clocks[0].clk, clocks[1].clk); + /* Power platform configuration */ if (aic32x4->power_cfg & AIC32X4_PWR_MICBIAS_2075_LDOIN) { snd_soc_component_write(component, AIC32X4_MICBIAS, -- 2.20.1

8 9

[alsa-devel] View alsa-lib plugins setup for any app?
by Eliot Blennerhassett 05 Dec '25

05 Dec '25

Greetings, running aplay -v will show the plugin chain setup. /proc/asound/card/pcm/* shows hw and sw params for the card driver when in use by any app Is there any way to show the alsa-lib plugin settings a-la aplay for an arbitrary application? thanks -- Eliot

4 8

[PATCH] ASoC: wm8994: Prevent access to invalid VU register bits on WM1811
by Sylwester Nawrocki 20 Nov '25

20 Nov '25

The ADC2 and DAC2 are not available on WM1811 device. This patch moves the ADC2, DAC2 VU bitfields to a separate array so we can skip accessing them and avoid unreadable register access on WM1811. This allows to get rid of warnings during boot like: wm8994-codec: ASoC: error at soc_component_read_no_lock on wm8994-codec: -5 Signed-off-by: Sylwester Nawrocki <s.nawrocki(a)samsung.com> --- sound/soc/codecs/wm8994.c | 60 ++++++++++++++++++++++++++++----------- 1 file changed, 44 insertions(+), 16 deletions(-) diff --git a/sound/soc/codecs/wm8994.c b/sound/soc/codecs/wm8994.c index a84ae879d37e..038be667c1a6 100644 --- a/sound/soc/codecs/wm8994.c +++ b/sound/soc/codecs/wm8994.c @@ -43,10 +43,12 @@ #define WM8994_NUM_DRC 3 #define WM8994_NUM_EQ 3 -static struct { +struct wm8994_reg_mask { unsigned int reg; unsigned int mask; -} wm8994_vu_bits[] = { +}; + +static struct wm8994_reg_mask wm8994_vu_bits[] = { { WM8994_LEFT_LINE_INPUT_1_2_VOLUME, WM8994_IN1_VU }, { WM8994_RIGHT_LINE_INPUT_1_2_VOLUME, WM8994_IN1_VU }, { WM8994_LEFT_LINE_INPUT_3_4_VOLUME, WM8994_IN2_VU }, @@ -60,14 +62,10 @@ static struct { { WM8994_AIF1_DAC1_LEFT_VOLUME, WM8994_AIF1DAC1_VU }, { WM8994_AIF1_DAC1_RIGHT_VOLUME, WM8994_AIF1DAC1_VU }, - { WM8994_AIF1_DAC2_LEFT_VOLUME, WM8994_AIF1DAC2_VU }, - { WM8994_AIF1_DAC2_RIGHT_VOLUME, WM8994_AIF1DAC2_VU }, { WM8994_AIF2_DAC_LEFT_VOLUME, WM8994_AIF2DAC_VU }, { WM8994_AIF2_DAC_RIGHT_VOLUME, WM8994_AIF2DAC_VU }, { WM8994_AIF1_ADC1_LEFT_VOLUME, WM8994_AIF1ADC1_VU }, { WM8994_AIF1_ADC1_RIGHT_VOLUME, WM8994_AIF1ADC1_VU }, - { WM8994_AIF1_ADC2_LEFT_VOLUME, WM8994_AIF1ADC2_VU }, - { WM8994_AIF1_ADC2_RIGHT_VOLUME, WM8994_AIF1ADC2_VU }, { WM8994_AIF2_ADC_LEFT_VOLUME, WM8994_AIF2ADC_VU }, { WM8994_AIF2_ADC_RIGHT_VOLUME, WM8994_AIF1ADC2_VU }, { WM8994_DAC1_LEFT_VOLUME, WM8994_DAC1_VU }, @@ -76,6 +74,14 @@ static struct { { WM8994_DAC2_RIGHT_VOLUME, WM8994_DAC2_VU }, }; +/* VU bitfields for ADC2, DAC2 not available on WM1811 */ +static struct wm8994_reg_mask wm8994_adc2_dac2_vu_bits[] = { + { WM8994_AIF1_DAC2_LEFT_VOLUME, WM8994_AIF1DAC2_VU }, + { WM8994_AIF1_DAC2_RIGHT_VOLUME, WM8994_AIF1DAC2_VU }, + { WM8994_AIF1_ADC2_LEFT_VOLUME, WM8994_AIF1ADC2_VU }, + { WM8994_AIF1_ADC2_RIGHT_VOLUME, WM8994_AIF1ADC2_VU }, +}; + static int wm8994_drc_base[] = { WM8994_AIF1_DRC1_1, WM8994_AIF1_DRC2_1, @@ -1030,6 +1036,26 @@ static bool wm8994_check_class_w_digital(struct snd_soc_component *component) return true; } +static void wm8994_update_vu_bits(struct snd_soc_component *component) +{ + struct wm8994_priv *wm8994 = snd_soc_component_get_drvdata(component); + struct wm8994 *control = wm8994->wm8994; + int i; + + for (i = 0; i < ARRAY_SIZE(wm8994_vu_bits); i++) + snd_soc_component_write(component, wm8994_vu_bits[i].reg, + snd_soc_component_read(component, + wm8994_vu_bits[i].reg)); + if (control->type == WM1811) + return; + + for (i = 0; i < ARRAY_SIZE(wm8994_adc2_dac2_vu_bits); i++) + snd_soc_component_write(component, + wm8994_adc2_dac2_vu_bits[i].reg, + snd_soc_component_read(component, + wm8994_adc2_dac2_vu_bits[i].reg)); +} + static int aif_mclk_set(struct snd_soc_component *component, int aif, bool enable) { struct wm8994_priv *wm8994 = snd_soc_component_get_drvdata(component); @@ -1076,7 +1102,7 @@ static int aif1clk_ev(struct snd_soc_dapm_widget *w, struct wm8994_priv *wm8994 = snd_soc_component_get_drvdata(component); struct wm8994 *control = wm8994->wm8994; int mask = WM8994_AIF1DAC1L_ENA | WM8994_AIF1DAC1R_ENA; - int ret, i; + int ret; int dac; int adc; int val; @@ -1144,10 +1170,7 @@ static int aif1clk_ev(struct snd_soc_dapm_widget *w, break; case SND_SOC_DAPM_POST_PMU: - for (i = 0; i < ARRAY_SIZE(wm8994_vu_bits); i++) - snd_soc_component_write(component, wm8994_vu_bits[i].reg, - snd_soc_component_read(component, - wm8994_vu_bits[i].reg)); + wm8994_update_vu_bits(component); break; case SND_SOC_DAPM_PRE_PMD: @@ -1181,7 +1204,7 @@ static int aif2clk_ev(struct snd_soc_dapm_widget *w, struct snd_kcontrol *kcontrol, int event) { struct snd_soc_component *component = snd_soc_dapm_to_component(w->dapm); - int ret, i; + int ret; int dac; int adc; int val; @@ -1237,10 +1260,7 @@ static int aif2clk_ev(struct snd_soc_dapm_widget *w, break; case SND_SOC_DAPM_POST_PMU: - for (i = 0; i < ARRAY_SIZE(wm8994_vu_bits); i++) - snd_soc_component_write(component, wm8994_vu_bits[i].reg, - snd_soc_component_read(component, - wm8994_vu_bits[i].reg)); + wm8994_update_vu_bits(component); break; case SND_SOC_DAPM_PRE_PMD: @@ -4346,6 +4366,14 @@ static int wm8994_component_probe(struct snd_soc_component *component) wm8994_vu_bits[i].mask, wm8994_vu_bits[i].mask); + if (control->type != WM1811) { + for (i = 0; i < ARRAY_SIZE(wm8994_adc2_dac2_vu_bits); i++) + snd_soc_component_update_bits(component, + wm8994_adc2_dac2_vu_bits[i].reg, + wm8994_adc2_dac2_vu_bits[i].mask, + wm8994_adc2_dac2_vu_bits[i].mask); + } + /* Set the low bit of the 3D stereo depth so TLV matches */ snd_soc_component_update_bits(component, WM8994_AIF1_DAC1_FILTERS_2, 1 << WM8994_AIF1DAC1_3D_GAIN_SHIFT, -- 2.17.1

4 3

[alsa-devel] ASoC TDM channel re-mapping
by Edward Cragg 17 Jun '25

17 Jun '25

Hi, We have an ASoC driver in which we have added support for TDM over an I2S interface. We would like to have the capability of re-mapping the channel ordering, for which i know there is a callback in place to start this process, set_channel_map. The only backend implementation of this is using the ALSA API and the .copy handler in an ALSA PCM driver to mutate data copied out of ALSA before it's DMA'd to hardware. This is in sound/soc/blackfin/bf5xx-i2s-pcm.c The problem we have is that the driver we're using currently uses a dmaengine based PCM driver, and i'm not sure whether this is compatible with using the .copy callback, without reimplementing the driver entirely as an ALSA PCM driver. Since there aren't very many examples in mainline, I was hoping to ask for advice for the best way of doing this. I wondered: - Would it be possible to add a functional copy callback using a dmaengine based PCM driver? - Otherwise, would there be a good way to implement channel remapping in a TDM frame using the dmaengine based PCM driver? or - Would the best way indeed be to reimplement the PCM driver as a normal ALSA PCM driver? Thanks, Ed Cragg

2 2

[alsa-devel] Error patching file pcm_native.c
by Delusion's Master 20 Nov '24

20 Nov '24

Hi, first of all I apologize in case you receive multiple copies of this message, but I forgot to specify a subject in the original mail. I have a problem compiling the latest alsa driver snapshots. Specifically, it's a problem when patching pcm_native.c: [..] copying file alsa-kernel/core/info.c patching file info.c copying file alsa-kernel/core/pcm.c patching file pcm.c Hunk #3 succeeded at 739 (offset 2 lines). Hunk #5 succeeded at 954 (offset 2 lines). Hunk #7 succeeded at 1045 (offset 2 lines). copying file alsa-kernel/core/pcm_native.c patching file pcm_native.c Hunk #4 succeeded at 1544 (offset -25 lines). Hunk #5 succeeded at 2827 (offset 12 lines). Hunk #6 succeeded at 2878 (offset 10 lines). Hunk #7 FAILED at 2906. Hunk #8 FAILED at 2922. Hunk #9 succeeded at 2915 (offset -23 lines). Hunk #10 succeeded at 3036 (offset 10 lines). Hunk #11 succeeded at 3027 (offset -23 lines). Hunk #12 succeeded at 3074 (offset 10 lines). Hunk #13 succeeded at 3098 (offset -23 lines). Hunk #14 succeeded at 3143 (offset 10 lines). Hunk #15 succeeded at 3124 (offset -23 lines). Hunk #16 succeeded at 3214 (offset 10 lines). Hunk #17 succeeded at 3208 (offset -23 lines). Hunk #18 succeeded at 3271 (offset 10 lines). Hunk #19 succeeded at 3304 (offset -23 lines). Hunk #20 succeeded at 3386 (offset 10 lines). Hunk #21 succeeded at 3411 (offset -23 lines). Hunk #22 succeeded at 3456 (offset 10 lines). Hunk #23 succeeded at 3450 (offset -23 lines). Hunk #24 succeeded at 3525 (offset 10 lines). Hunk #25 succeeded at 3644 (offset -23 lines). 2 out of 25 hunks FAILED -- saving rejects to file pcm_native.c.rej make[2]: *** [pcm_native.c] Error 1 It's some days I get this, but I waited to report this since I thought it could be a temporary problem. My OS is Fedora 11 x86_64. Previous snapshots didn't give me this problem, but I can't say which one broke the compilation, since I usually try updated snapshots only at kernel updates. I searched for this error and the only relevant report I could find is this one: http://mailman.alsa-project.org/pipermail/alsa-devel/2009-April/016420.html a report from last April. What could the problem be? Thanks _________________________________________________________________ Invite your mail contacts to join your friends list with Windows Live Spaces. It's easy! http://spaces.live.com/spacesapi.aspx?wx_action=create&wx_url=/friends.aspx…

3 10

[alsa-devel] [RFC PATCH 00/10] Add support for DMA and audio codec of F1C100s
by Mesih Kilinc 23 Oct '24

23 Oct '24

This is RFC patchset for Allwinner suniv F1C100s to support DMA and audio codec. Allwinner F1C100s has a audio codec that has necessary digital and analog parts. It has r-l headphone output and microphone, line, r-l FM inputs. ADC can capture any inputs and also output channels via mux. Any input channels or DAC samples can feed output channels. Add support for this audio codec. F1C100s utilizes DMA channels to send and receive ADC-DAC samples. So DMA support needed. Patch 1~5 adds support for DMA. Suniv F1C100s has very similar DMA to sun4i. But there is some dissimilarities also. Suniv features a DMA reset bit in clock control unit. It has smaller number of DMA channels. Several registers has different addresses. It's max burst size is 4 instead of 8. Also DMA endpoint numbers are different. Patch 6 adds DMA max burst option to sun4i-codec. Patch 7~8 Add support for suniv F1C100s audio codec. Patch 9 adds audio codec to suniv-f1c100s.dtsi Patch 10 adds audio codec support to Lichee Pi Nano board. Thanks! Mesih Kilinc (10): dma-engine: sun4i: Add a quirk to support different chips dma-engine: sun4i: Add has_reset option to quirk dt-bindings: dmaengine: Add Allwinner suniv F1C100s DMA dma-engine: sun4i: Add support for Allwinner suniv F1C100s ARM: dts: suniv: f1c100s: Add support for DMA ASoC: sun4i-codec: Add DMA Max Burst field dt-bindigs: sound: Add Allwinner suniv F1C100s Audio Codec ASoC: sun4i-codec: Add support for Allwinner suniv F1C100s ARM: dts: suniv: f1c100s: Add support for Audio Codec ARM: dts: suniv: f1c100s: Activate Audio Codec for Lichee Pi Nano .../devicetree/bindings/dma/sun4i-dma.txt | 4 +- .../devicetree/bindings/sound/sun4i-codec.txt | 5 + arch/arm/boot/dts/suniv-f1c100s-licheepi-nano.dts | 8 + arch/arm/boot/dts/suniv-f1c100s.dtsi | 25 ++ drivers/dma/Kconfig | 4 +- drivers/dma/sun4i-dma.c | 221 ++++++++++-- sound/soc/sunxi/sun4i-codec.c | 371 ++++++++++++++++++++- 7 files changed, 601 insertions(+), 37 deletions(-) -- 2.7.4

5 18

[alsa-devel] unsupported variant of snd_hda_intel
by Alexandre 04 Jul '24

04 Jul '24

Hello, I have an Acer Aspire 4736G laptop. The soundcard that is shipped in this laptop is intel-hda based as shown (actually it's a realtek): cat /proc/asound/cards 0 [Intel ]: HDA-Intel - HDA Intel HDA Intel at 0x9b300000 irq 46 Basic sound output is correct but few feature are missing: - internal mic seems to be found but do not works. - sound output stop working when trying to send it using HDMI output - heads do not work when plugged neither when forcing pulseaudio to use it. I have an ubuntu 10.10 which is shipped with alsa 1.0.23. I have googled around and tried loading the snd-hda-intel with several parameters () as found in HD-Audio-Models.txt to no avail. cat /proc/asound/pcm 00-00: ALC888 Analog : ALC888 Analog : playback 1 : capture 1 00-01: ALC888 Digital : ALC888 Digital : playback 1 00-03: NVIDIA HDMI : NVIDIA HDMI : playback 1 Where can I begin to help implement the support for this sound card? I have very skills in developement in general but am ready to try if it is not to hard (I supose I can use previous code for similar models).. I just need a shepherd. Thanks

4 4

[alsa-devel] echo-cancellation plugin advice?
by Max Klein 27 Oct '23

27 Oct '23

> Well, asym wouldn't be the answer. Basically you'll need to open two > slave PCMs in one plugin. So, it's no simple filter-type plugin. > It's doable, but not easy as it sounds, I guess. Takashi, can you please further explain why asym is not the solution and what you see as a problem? I am also trying to figure out if it would be possible to create such a plugin for ALSA? I am still searching for some good starting points on how to write an ALSA plugin... Jean-Marc Valin (http://lists.linuxaudio.org/pipermail/linux-audio-dev/2005-June/012454.html) already released his work as part of speex but as far I know there is no plugin that has been made out of it? Thanks for any hint! -- NEU: FreePhone 3-fach-Flat mit kostenlosem Smartphone! Jetzt informieren: http://mobile.1und1.de/?ac=OM.PW.PW003K20328T7073a

3 2

[alsa-devel] [PATCH 0/6] ASoC: mediatek: mt8183: support DP audio
by Tzung-Bi Shih 24 Nov '22

24 Nov '22

(This series depends on https://lore.kernel.org/patchwork/patch/1126819/ which has not applied to the maintainer's tree yet.) This series makes mt8183-mt6358-ts3a227-max98357 support DP (display port) audio output. ASoC: hdmi-codec: add PCM trigger operator - add a PCM trigger callback if codec driver is interested in PCM events. drm: bridge: it6505: bridge to hdmi-codec - add audio feature support of it6505. - bridge to hdmi-codec so that ASoC can use the audio feature. - defer the "enabling" after receiving PCM START or RESUME event. ASoC: dt-bindings: mt8183: add a property "mediatek,hdmi-codec" ASoC: mediatek: mt8183: use hdmi-codec - bind to hdmi-codec in mt8183-mt6358-ts3a227-max98357. drm: bridge: it6505: report connector status ASoC: mediatek: mt8183: support HDMI jack reporting - use the mechanism from the following patch https://mailman.alsa-project.org/pipermail/alsa-devel/2019-September/155302… to report jack status (from DRM to ASoC). Allen Chen (1): drm: bridge: it6505: bridge to hdmi-codec Tzung-Bi Shih (5): ASoC: hdmi-codec: add PCM trigger operator ASoC: dt-bindings: mt8183: add a property "mediatek,hdmi-codec" ASoC: mediatek: mt8183: use hdmi-codec drm: bridge: it6505: report connector status ASoC: mediatek: mt8183: support HDMI jack reporting .../sound/mt8183-mt6358-ts3a227-max98357.txt | 2 + drivers/gpu/drm/bridge/ite-it6505.c | 191 +++++++++++++++++- include/sound/hdmi-codec.h | 13 ++ sound/soc/codecs/hdmi-codec.c | 31 +++ sound/soc/mediatek/Kconfig | 3 +- .../mt8183/mt8183-mt6358-ts3a227-max98357.c | 36 +++- 6 files changed, 266 insertions(+), 10 deletions(-) -- 2.23.0.866.gb869b98d4c-goog

3 9