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

[PATCH v2] ASoC: nau8822: add spk boost and spk btl options
by Benjamin Marty 14 Oct '22

14 Oct '22

These two options are required to use the Speaker output on this codec to its full potential, when wiring up the Speaker in an BTL configuration. The Speaker Boost flag is explained in the Datasheet on page 80. The Speaker BTL flag is explained in the Datasheet on page 78. Signed-off-by: Benjamin Marty <info(a)benjaminmarty.ch> --- sound/soc/codecs/nau8822.c | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/sound/soc/codecs/nau8822.c b/sound/soc/codecs/nau8822.c index 1aef281a9972..812b8254f9a0 100644 --- a/sound/soc/codecs/nau8822.c +++ b/sound/soc/codecs/nau8822.c @@ -379,6 +379,12 @@ static const struct snd_kcontrol_new nau8822_snd_controls[] = { NAU8822_REG_DAC_CONTROL, 5, 1, 0), SOC_SINGLE("ADC 128x Oversampling Switch", NAU8822_REG_ADC_CONTROL, 5, 1, 0), + + SOC_SINGLE("Speaker Gain Boost Control", + NAU8822_REG_OUTPUT_CONTROL, 2, 1, 0), + + SOC_SINGLE("Speaker BTL Configuration", + NAU8822_REG_RIGHT_SPEAKER_CONTROL, 4, 1, 0), }; /* LMAIN and RMAIN Mixer */ -- 2.38.0

3 2

[PATCH] ASoC: nau8822: add spk boost and spk btl options
by Benjamin Marty 14 Oct '22

14 Oct '22

These two options are required to use the Speaker output on this codec to its full potential, when wiring up the Speaker in an BTL configuration. The Speaker Boost flag is explained in the Datasheet on page 80. The Speaker BTL flag is explained in the Datasheet on page 78. Signed-off-by: Benjamin Marty <info(a)benjaminmarty.ch> --- sound/soc/codecs/nau8822.c | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/sound/soc/codecs/nau8822.c b/sound/soc/codecs/nau8822.c index 1aef281a9972..812b8254f9a0 100644 --- a/sound/soc/codecs/nau8822.c +++ b/sound/soc/codecs/nau8822.c @@ -379,6 +379,12 @@ static const struct snd_kcontrol_new nau8822_snd_controls[] = { NAU8822_REG_DAC_CONTROL, 5, 1, 0), SOC_SINGLE("ADC 128x Oversampling Switch", NAU8822_REG_ADC_CONTROL, 5, 1, 0), + + SOC_SINGLE("Speaker Gain Boost Control", + NAU8822_REG_OUTPUT_CONTROL, 2, 1, 0), + + SOC_SINGLE("Speaker BTL Configuration", + NAU8822_REG_RIGHT_SPEAKER_CONTROL, 4, 1, 0), }; /* LMAIN and RMAIN Mixer */ -- 2.37.3

2 3

Re: Buffer overflow in AVS driver
by CoolStar Organization 14 Oct '22

14 Oct '22

Hi Cezary and Alicja, Just chiming in a bit regarding Geminilake since I figured it out on my end. I have been able to get AVS (at least my port anyways) to run on a Geminilake chromebook after re-signing + re-packing the DSP firmware with the community keys and updating my driver's topology generation to look for the correct SSP's on the NHLT. I dug through the older SKL module in Linux and I noticed the topologies for that specify a "mixer" module (I'm noting it creates an output and an input mixer and binds them together in between the HDA and I2S copier modules). Do these mixer modules do any volume adjustment / volume limiting? as I didn't see any configuration for the mixers aside from the audio format. --CoolStar On Mon, Oct 3, 2022 at 9:09 AM <alicja.michalska(a)tutanota.com> wrote: > Hello Cezary, Amadeusz and CoolStar. > > I'm sure you're waiting for update from me, but unfortunately I got really > sick with tonsillitis. Hopefully it clears up a bit tomorrow. > > I did some preliminary testing as CoolStar mentioned, but I would like to > compare results with GeminiLake Refresh board (google/octopus) that should > be arriving tomorrow. It also uses DA7219 + 2x max98357a (max98357a is a > mono amplifier, so there are two amplifiers on the board - one per channel). > > Just from multimeter measurements there's nothing out of ordinary. 5.12v > (so basically 5v) driving max98357a, resulting with 2.7v on speaker output > which is within spec. I'm still learning how to use an oscilloscope, but > I've noticed that Vpp parameter goes up to 2.4v if you set the volume to > 100% (I'm testing on google/reef baseboard which is ApolloLake N3350 with > DA7219 + 2x max98357a). If you set volume to ~66% it stays around 2v and > speakers don't heat up. > > Here you can see that even without any audio playing, left speaker is > significantly warmer than right one. I began playback with volume set to > 25%, then increased it to 65% and then 100%. Once speaker reaches 60*C, > it's permanently damaged. Working speaker has 3.7Ohm resistance, while > damaged one has 3.9Ohm. > You can also see a pair of max98357a's heating up in the background while > playing with volume set to 100% - they reach 40*C. > > https://elly.rocks/tmp/avs_fryingpan.mp4 > Speaking of which, reading trough the code I've noticed that you intend on > supporting GLK platform. We don't have firmware signed with community keys > (GLK doesn't accept Intel-signed keys) so I've been wondering - would it be > possible for you to provide such FW? > > It is really baffling to me, because as far as we both (CoolStar and me) > see, max98357a is a very simple amplifier controlled by setting GPIO pin > low or high. Conclusion would be that the problem lies in how AVS is > driving ADAU7002 or DA7219, but I'm definitely not in shape right now to > read trough AVS code once again. > > > Best regards, > Alicja Michalska > -- > Sent from Tutanota Client for Linux x86_64 > > > > Oct 2, 2022, 00:09 by coolstarorganization(a)gmail.com: > > > Hi Cezary, > > I was able to get a capture streams working. Thanks for the guidance > on the order of operations for that. For the final iteration of my driver > port I'm going to be grabbing data from the NHLT to populate topologies it > generates so that should have less hardcoding. > > > > Regarding the volume problem, Alicja here ran some tests with AVS on > linux with a scope connected to the output pins of the max98357a (we're > testing on various Skylake, Kaby Lake and Apollo Lake chromebooks -- I > unfortunately blew the left speaker on pantheon here during testing (and > Alicja blew a left speaker on snappy). We're using topology files grabbed > from Chrome OS's Apollo Lake image (I edited the virtual bus id to get it > working on Kaby Lake here), and it seems there's nothing referencing DSM > inside either the alsa configs or topology. > > --CoolStar > > > > On Thu, Sep 29, 2022 at 9:41 AM Rojewski, Cezary <> > cezary.rojewski(a)intel.com> > wrote: > > > >> > >> Hello, > >> > >> > >> > >> > >> > >> Indeed, there are means on dealing with volume problem you describe. > Not all of them are free though and we cannot share such to the community > without client’s ACK. > >> > >> > >> Judging by the max98357a, platform of yours is a Chromebook device, > perhaps AML-based, e.g.: Atlas. Said configuration contains the DSM module > which addresses the problem. The DSM topology and the configuration should > be available to public, so filtering google’s public domain should yield > positive results. > >> > >> > >> > >> > >> > >> I advise against hardcoding anything within the driver. Within a week > or two, tools for compiling the topology as well as several dozens of > examples should be present on the upstream, that is on the >> > github.com/thesofproject <http://github.com/thesofproject>>> . > >> > >> > >> But yes, there is a requirement for certain ordering of operations. In > general, you should be creating stuff from input to output (precisely in > that direction). For capture, input stands at BE side while for playback > it’s FE instead. There’s also part about configuring the actual hardware > that is represented in ASoC as a BE. Files: avs/path.c and avs/pcm.c should > provide the pattern you seek. > >> > >> > >> > >> > >> > >> > >> > >> > >> Kind regards, > >> > >> > >> Czarek > >> > >> > >> > >> > >> > >> From:>> CoolStar Organization <>> coolstarorganization(a)gmail.com>> > > >> >> Sent:>> Wednesday, September 28, 2022 11:17 PM > >> >> To:>> Rojewski, Cezary <>> cezary.rojewski(a)intel.com>> > > >> >> Cc:>> >> amadeuszx.slawinski(a)linux.intel.com > >> >> Subject:>> Re: Buffer overflow in AVS driver > >> > >> > >> > >> > >> Hi Czarek, > >> > >> > >> You can mention CoolStar in the Reported-by tag, as that’s the > pseudonym I go by. > >> > >> > >> > >> > >> > >> Also I had 2 questions regarding AVS. > >> > >> > >> > >> > >> > >> A friend and I both noticed on max98357a that increasing the volume in > the OS past 70% can destroy the speakers. Is there a module or something > that could be bound on the speaker path to limit the volume as max98357a > itself just has an on/off switch? (I noticed catpt has volume controls. > Maybe AVS’s updown mix?). > >> > >> > >> > >> > >> > >> Also, I managed to get my AVS port to output sound on another OS (I’m > not using topology files and am hard coding the path). However I noticed > I’ve been unable to record sound. I noticed for output streams the > initialization sequence is: > >> > >> > >> 1. Create pipeline 0 > >> > >> > >> 2. Create i2s link output path on pipeline 0 > >> > >> > >> 3. Grab HDA render stream & program BDL > >> > >> > >> 4. Create pipeline 1 > >> > >> > >> 5. Create HDA output path on pipeline 1 with virtual link address > (HDA stream tag - 1) > >> > >> > >> 6. Bind pipeline 1 to 0 > >> > >> > >> 7. Set pipeline 0 and then 1 to reset & paused > >> > >> > >> 8. Start HDA stream playback > >> > >> > >> 9. Set pipelines 1 and then 0 to running > >> > >> > >> > >> > >> > >> I’ve been attempting to do a similar setup for input (except with i2s > link input path, an HDA capture stream, and HDA input path) but I don’t see > any input. Is there a particular order for input initialization for it to > work? (Similar to how for the output I had to set up the HDA stream before > creating the HDA pipeline before I could get any sound output?) > >> > >> > >> > >> > >> > >> —CoolStar > >> > >> > >> > >> > >> > >> On Wed, Sep 28, 2022 at 1:09 PM Rojewski, Cezary <>> > cezary.rojewski(a)intel.com>> > wrote: > >> > >> > >>> > >>> Hello, > >>> > >>> > >>> > >>> > >>> > >>> Please excuse my delay in response. We appreciate the input – in > future, please do not be afraid to email us with alsa-devel in CC. It’s > easier to not have the mail missed that way. > >>> > >>> > >>> > >>> > >>> > >>> In regard to the actual bug, highly unlikely but indeed you’re > correct. While my response is delayed, patch fixing the problem in our > internal tree was not. Said patch should soon appear on the alsa-devel > mailing list. Are there any names that you would like us to mention in the > relevant commit message (through “Reported-by:” tag)?. > >>> > >>> > >>> > >>> > >>> > >>> Kind regards, > >>> > >>> > >>> Czarek > >>> > >>> > >>> > >>> > >>> > >>> From:>>> CoolStar Organization <>>> coolstarorganization(a)gmail.com>>> > > > >>> >>> Sent:>>> Saturday, September 10, 2022 10:00 PM > >>> >>> To:>>> Rojewski, Cezary <>>> cezary.rojewski(a)intel.com>>> >; > >>> amadeuszx.slawinski(a)linux.intel.com > >>> >>> Subject:>>> Buffer overflow in AVS driver > >>> > >>> > >>> > >>> > >>> Hi, > >>> > >>> > >>> I've been looking at porting the avs driver you've written to another > OS. During the process I noticed a potential buffer overflow issue in ipc.c. > >>> > >>> > >>> > >>> > >>> > >>> I noticed that ipc->rx.data is allocated a buffer of > `AVS_MAILBOX_SIZE` (or 4096 bytes) in the init, and this buffer is not > allocated anywhere else. In avs_dsp_receive_rx, if the msg type is set to a > large config get, it sets the size to the arbitrary value from the msg > struct without any checks, and then immediately does a memcpy to the buffer. > >>> > >>> > >>> > >>> > >>> > >>> I'd highly suggest putting a check to ensure this doesn't go larger > than AVS_MAILBOX_SIZE to avoid a buffer overflow as that could crash the > system (or potentially be a vulnerability to take over the host system if > an attacker somehow gets code execution on the DSP?) > >>> > >>> > >>> --CoolStar > >>> > >>> > >

1 0

Software volume control has very little effect on Behringer UMC204HD
by GitHub issues - edited 13 Oct '22

13 Oct '22

alsa-project/alsa-ucm-conf issue #230 was edited from Spanfile: I'm using a Behringer UMC204HD with its UCM profile and Pipewire. The profile works fine that it properly splits the interface's four output channels into two stereo line outputs, and Pipewire is properly using them. There aren't any issues with audio crackling, latency or the sort, but the software volume control is affecting the actual volume output very little. Only the first few "notches" from 0 to 10 change the volume noticeably, however the lowest volume it allows is still somewhat loud. From there on the rest of the range doesn't change the volume much at all. Using the Direct UCM profile lets the software volume control have much better range, but I need the Line A/B split in my setup so that profile is not an option. I haven't tried disabling UCM and configuring pro audio in Pipewire directly, but that doesn't sound like a proper fix. It may be intentional, however? [There has been a similar issue reported to Pipewire](https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/2643), but it's not exactly what I'm experiencing. [I've reported this issue to them as well.](https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/2765) Of course I could set the software volume to something static and control it from the interface, but the interface is physically out of reach from my hands and the software volume is easily controlled from my keyboard ;) Kernel: 6.0.1.arch1-1 Pipewire: 0.3.59 alsa-ucm-conf: 1.2.7.2 Desktop environment: GNOME (w/ GDM) Issue URL : https://github.com/alsa-project/alsa-ucm-conf/issues/230 Repository URL: https://github.com/alsa-project/alsa-ucm-conf

1 0

Software volume control has very little effect on Behringer UMC204HD
by GitHub issues - edited 13 Oct '22

13 Oct '22

alsa-project/alsa-ucm-conf issue #230 was edited from Spanfile: I'm using a Behringer UMC204HD with Pipewire and its UCM profile. The profile works fine that it properly splits the interface's four output channels into two stereo line outputs, and Pipewire is properly using them. There aren't any issues with audio crackling, latency or the sort, but the software volume control is affecting the actual volume output very little. Only the first few "notches" from 0 to 10 change the volume noticeably, however the lowest volume it allows is still somewhat loud. From there on the rest of the range doesn't change the volume much at all. Using the Direct UCM profile lets the software volume control have much better range, but I need the Line A/B split in my setup so that profile is not an option. I haven't tried disabling UCM and configuring pro audio in Pipewire directly, but that doesn't sound like a proper fix. It may be intentional, however? [There has been a similar issue reported to Pipewire](https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/2643), but it's not exactly what I'm experiencing. [I've reported this issue to them as well.](https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/2765) Of course I could set the software volume to something static and control it from the interface, but the interface is physically out of reach from my hands and the software volume is easily controlled from my keyboard ;) Kernel: 6.0.1.arch1-1 Pipewire: 0.3.59 alsa-ucm-conf: 1.2.7.2 Desktop environment: GNOME (w/ GDM) Issue URL : https://github.com/alsa-project/alsa-ucm-conf/issues/230 Repository URL: https://github.com/alsa-project/alsa-ucm-conf

1 0

[PATCH] ASoC: rt5682s: Fix the TDM Tx settings
by derek.fang＠realtek.com 13 Oct '22

13 Oct '22

From: Derek Fang <derek.fang(a)realtek.com> Complete the missing and correct the TDM Tx settings. Signed-off-by: Derek Fang <derek.fang(a)realtek.com> --- sound/soc/codecs/rt5682s.c | 15 +++++++++++++-- sound/soc/codecs/rt5682s.h | 1 + 2 files changed, 14 insertions(+), 2 deletions(-) diff --git a/sound/soc/codecs/rt5682s.c b/sound/soc/codecs/rt5682s.c index 3b91a3442c68..5199d3bbaf0b 100644 --- a/sound/soc/codecs/rt5682s.c +++ b/sound/soc/codecs/rt5682s.c @@ -1981,7 +1981,7 @@ static int rt5682s_set_tdm_slot(struct snd_soc_dai *dai, unsigned int tx_mask, unsigned int rx_mask, int slots, int slot_width) { struct snd_soc_component *component = dai->component; - unsigned int cl, val = 0; + unsigned int cl, val = 0, tx_slotnum; if (tx_mask || rx_mask) snd_soc_component_update_bits(component, @@ -1990,6 +1990,16 @@ static int rt5682s_set_tdm_slot(struct snd_soc_dai *dai, unsigned int tx_mask, snd_soc_component_update_bits(component, RT5682S_TDM_ADDA_CTRL_2, RT5682S_TDM_EN, 0); + /* Tx slot configuration */ + tx_slotnum = hweight_long(tx_mask); + if (tx_slotnum) { + if (tx_slotnum > slots) { + dev_err(component->dev, "Invalid or oversized Tx slots.\n"); + return -EINVAL; + } + val |= (tx_slotnum - 1) << RT5682S_TDM_ADC_DL_SFT; + } + switch (slots) { case 4: val |= RT5682S_TDM_TX_CH_4; @@ -2010,7 +2020,8 @@ static int rt5682s_set_tdm_slot(struct snd_soc_dai *dai, unsigned int tx_mask, } snd_soc_component_update_bits(component, RT5682S_TDM_CTRL, - RT5682S_TDM_TX_CH_MASK | RT5682S_TDM_RX_CH_MASK, val); + RT5682S_TDM_TX_CH_MASK | RT5682S_TDM_RX_CH_MASK | + RT5682S_TDM_ADC_DL_MASK, val); switch (slot_width) { case 8: diff --git a/sound/soc/codecs/rt5682s.h b/sound/soc/codecs/rt5682s.h index 824dc6543c18..45464a041765 100644 --- a/sound/soc/codecs/rt5682s.h +++ b/sound/soc/codecs/rt5682s.h @@ -899,6 +899,7 @@ #define RT5682S_TDM_RX_CH_8 (0x3 << 8) #define RT5682S_TDM_ADC_LCA_MASK (0x7 << 4) #define RT5682S_TDM_ADC_LCA_SFT 4 +#define RT5682S_TDM_ADC_DL_MASK (0x3 << 0) #define RT5682S_TDM_ADC_DL_SFT 0 /* TDM control 2 (0x007a) */ -- 2.17.1

2 1

[PATCH] ASoC: rt1019: Fix the TDM settings
by derek.fang＠realtek.com 13 Oct '22

13 Oct '22

From: Derek Fang <derek.fang(a)realtek.com> Complete the missing and correct the TDM settings. Signed-off-by: Derek Fang <derek.fang(a)realtek.com> --- sound/soc/codecs/rt1019.c | 20 +++++++++++--------- sound/soc/codecs/rt1019.h | 6 ++++++ 2 files changed, 17 insertions(+), 9 deletions(-) diff --git a/sound/soc/codecs/rt1019.c b/sound/soc/codecs/rt1019.c index b66bfecbb879..49f527c61a7a 100644 --- a/sound/soc/codecs/rt1019.c +++ b/sound/soc/codecs/rt1019.c @@ -391,18 +391,18 @@ static int rt1019_set_tdm_slot(struct snd_soc_dai *dai, unsigned int tx_mask, unsigned int rx_mask, int slots, int slot_width) { struct snd_soc_component *component = dai->component; - unsigned int val = 0, rx_slotnum; + unsigned int cn = 0, cl = 0, rx_slotnum; int ret = 0, first_bit; switch (slots) { case 4: - val |= RT1019_I2S_TX_4CH; + cn = RT1019_I2S_TX_4CH; break; case 6: - val |= RT1019_I2S_TX_6CH; + cn = RT1019_I2S_TX_6CH; break; case 8: - val |= RT1019_I2S_TX_8CH; + cn = RT1019_I2S_TX_8CH; break; case 2: break; @@ -412,16 +412,16 @@ static int rt1019_set_tdm_slot(struct snd_soc_dai *dai, unsigned int tx_mask, switch (slot_width) { case 20: - val |= RT1019_I2S_DL_20; + cl = RT1019_TDM_CL_20; break; case 24: - val |= RT1019_I2S_DL_24; + cl = RT1019_TDM_CL_24; break; case 32: - val |= RT1019_I2S_DL_32; + cl = RT1019_TDM_CL_32; break; case 8: - val |= RT1019_I2S_DL_8; + cl = RT1019_TDM_CL_8; break; case 16: break; @@ -470,8 +470,10 @@ static int rt1019_set_tdm_slot(struct snd_soc_dai *dai, unsigned int tx_mask, goto _set_tdm_err_; } + snd_soc_component_update_bits(component, RT1019_TDM_1, + RT1019_TDM_CL_MASK, cl); snd_soc_component_update_bits(component, RT1019_TDM_2, - RT1019_I2S_CH_TX_MASK | RT1019_I2S_DF_MASK, val); + RT1019_I2S_CH_TX_MASK, cn); _set_tdm_err_: return ret; diff --git a/sound/soc/codecs/rt1019.h b/sound/soc/codecs/rt1019.h index 64df831eeb72..48ba15efb48d 100644 --- a/sound/soc/codecs/rt1019.h +++ b/sound/soc/codecs/rt1019.h @@ -95,6 +95,12 @@ #define RT1019_TDM_BCLK_MASK (0x1 << 6) #define RT1019_TDM_BCLK_NORM (0x0 << 6) #define RT1019_TDM_BCLK_INV (0x1 << 6) +#define RT1019_TDM_CL_MASK (0x7) +#define RT1019_TDM_CL_8 (0x4) +#define RT1019_TDM_CL_32 (0x3) +#define RT1019_TDM_CL_24 (0x2) +#define RT1019_TDM_CL_20 (0x1) +#define RT1019_TDM_CL_16 (0x0) /* 0x0401 TDM Control-2 */ #define RT1019_I2S_CH_TX_MASK (0x3 << 6) -- 2.17.1

2 1

[PATCH] ASoC: qcom: lpass-cpu: mark HDMI TX registers as volatile
by Srinivasa Rao Mandadapu 13 Oct '22

13 Oct '22

From: Srinivasa Rao Mandadapu <srivasam(a)qualcomm.corp-partner.google.com> Update HDMI volatile registers list as DMA, Channel Selection registers , vbit control registers are being reflected by hardware DP port disconnection. This update is required to fix no display and no sound issue observed after reconnecting TAMA/SANWA DP cables. Once DP cable is unplugged, DMA control registers are being reset by hardware, however at second plugin, new dma control values does not updated to the dma hardware registers since new register value and cached values at the time of first plugin are same. Signed-off-by: Srinivasa Rao Mandadapu <srivasam(a)qualcomm.corp-partner.google.com> --- sound/soc/qcom/lpass-cpu.c | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/sound/soc/qcom/lpass-cpu.c b/sound/soc/qcom/lpass-cpu.c index 8a56f38..99a3b44 100644 --- a/sound/soc/qcom/lpass-cpu.c +++ b/sound/soc/qcom/lpass-cpu.c @@ -782,10 +782,18 @@ static bool lpass_hdmi_regmap_volatile(struct device *dev, unsigned int reg) return true; if (reg == LPASS_HDMI_TX_LEGACY_ADDR(v)) return true; + if (reg == LPASS_HDMI_TX_VBIT_CTL_ADDR(v)) + return true; for (i = 0; i < v->hdmi_rdma_channels; ++i) { if (reg == LPAIF_HDMI_RDMACURR_REG(v, i)) return true; + if (reg == LPASS_HDMI_TX_DMA_ADDR(v, i)) + return true; + if (reg == LPASS_HDMI_TX_CH_LSB_ADDR(v, i)) + return true; + if (reg == LPASS_HDMI_TX_CH_MSB_ADDR(v, i)) + return true; } return false; } -- 2.7.4

3 2

[PATCH] ASoC: wm8962: Add an event handler for TEMP_HP and TEMP_SPK
by Xiaolei Wang 13 Oct '22

13 Oct '22

In wm8962 driver, the WM8962_ADDITIONAL_CONTROL_4 is used as a volatile register, but this register mixes a bunch of volatile status bits and a bunch of non-volatile control bits. The dapm widgets TEMP_HP and TEMP_SPK leverages the control bits in this register. After the wm8962 probe, the regmap will bet set to cache only mode, then a read error like below would be triggered when trying to read the initial power state of the dapm widgets TEMP_HP and TEMP_SPK. wm8962 0-001a: ASoC: error at soc_component_read_no_lock on wm8962.0-001a: -16 In order to fix this issue, we add event handler to actually power up/down these widgets. With this change, we also need to explicitly power off these widgets in the wm8962 probe since they are enabled by default. Signed-off-by: Xiaolei Wang <xiaolei.wang(a)windriver.com> --- sound/soc/codecs/wm8962.c | 54 +++++++++++++++++++++++++++++++++++++-- 1 file changed, 52 insertions(+), 2 deletions(-) diff --git a/sound/soc/codecs/wm8962.c b/sound/soc/codecs/wm8962.c index 398c448ea854..6df06fba4377 100644 --- a/sound/soc/codecs/wm8962.c +++ b/sound/soc/codecs/wm8962.c @@ -1840,6 +1840,49 @@ SOC_SINGLE_TLV("SPKOUTR Mixer DACR Volume", WM8962_SPEAKER_MIXER_5, 4, 1, 0, inmix_tlv), }; +static int tp_event(struct snd_soc_dapm_widget *w, + struct snd_kcontrol *kcontrol, int event) +{ + int ret, reg, val, mask; + struct snd_soc_component *component = snd_soc_dapm_to_component(w->dapm); + + ret = pm_runtime_resume_and_get(component->dev); + if (ret < 0) { + dev_err(component->dev, "Failed to resume device: %d\n", ret); + return ret; + } + + reg = WM8962_ADDITIONAL_CONTROL_4; + + if (!strcmp(w->name, "TEMP_HP")) { + mask = WM8962_TEMP_ENA_HP_MASK; + val = WM8962_TEMP_ENA_HP; + } else if (!strcmp(w->name, "TEMP_SPK")) { + mask = WM8962_TEMP_ENA_SPK_MASK; + val = WM8962_TEMP_ENA_SPK; + } else { + pm_runtime_put(component->dev); + return -EINVAL; + } + + switch (event) { + case SND_SOC_DAPM_POST_PMD: + val = 0; + fallthrough; + case SND_SOC_DAPM_POST_PMU: + ret = snd_soc_component_update_bits(component, reg, mask, val); + break; + default: + WARN(1, "Invalid event %d\n", event); + pm_runtime_put(component->dev); + return -EINVAL; + } + + pm_runtime_put(component->dev); + + return 0; +} + static int cp_event(struct snd_soc_dapm_widget *w, struct snd_kcontrol *kcontrol, int event) { @@ -2140,8 +2183,10 @@ SND_SOC_DAPM_SUPPLY("TOCLK", WM8962_ADDITIONAL_CONTROL_1, 0, 0, NULL, 0), SND_SOC_DAPM_SUPPLY_S("DSP2", 1, WM8962_DSP2_POWER_MANAGEMENT, WM8962_DSP2_ENA_SHIFT, 0, dsp2_event, SND_SOC_DAPM_POST_PMU | SND_SOC_DAPM_PRE_PMD), -SND_SOC_DAPM_SUPPLY("TEMP_HP", WM8962_ADDITIONAL_CONTROL_4, 2, 0, NULL, 0), -SND_SOC_DAPM_SUPPLY("TEMP_SPK", WM8962_ADDITIONAL_CONTROL_4, 1, 0, NULL, 0), +SND_SOC_DAPM_SUPPLY("TEMP_HP", SND_SOC_NOPM, 0, 0, tp_event, + SND_SOC_DAPM_POST_PMU|SND_SOC_DAPM_POST_PMD), +SND_SOC_DAPM_SUPPLY("TEMP_SPK", SND_SOC_NOPM, 0, 0, tp_event, + SND_SOC_DAPM_POST_PMU|SND_SOC_DAPM_POST_PMD), SND_SOC_DAPM_MIXER("INPGAL", WM8962_LEFT_INPUT_PGA_CONTROL, 4, 0, inpgal, ARRAY_SIZE(inpgal)), @@ -3763,6 +3808,11 @@ static int wm8962_i2c_probe(struct i2c_client *i2c) if (ret < 0) goto err_pm_runtime; + regmap_update_bits(wm8962->regmap, WM8962_ADDITIONAL_CONTROL_4, + WM8962_TEMP_ENA_HP_MASK, 0); + regmap_update_bits(wm8962->regmap, WM8962_ADDITIONAL_CONTROL_4, + WM8962_TEMP_ENA_SPK_MASK, 0); + regcache_cache_only(wm8962->regmap, true); /* The drivers should power up as needed */ -- 2.25.1

4 3

Software volume control has very little effect on Behringer UMC204HD
by GitHub issues - opened 13 Oct '22

13 Oct '22

alsa-project/alsa-ucm-conf issue #230 was opened from Spanfile: I'm using a Behringer UMC204HD with Pipewire and its UCM profile. The profile works fine that it properly splits the interface's four output channels into two stereo line outputs, and Pipewire is properly using them. There aren't any issues with audio crackling, latency or the sort, but the software volume control is affecting the actual volume output very little. Only the first few "notches" from 0 to 10 change the volume noticeably, however the lowest volume it allows is still somewhat loud. From there on the rest of the range doesn't change the volume much at all. According to the Pipewire developers, this issue likely falls within the ALSA territory. Using the Direct UCM profile lets the software volume control have much better range, but I need the Line A/B split in my setup so that profile is not an option. I haven't tried disabling UCM and configuring pro audio in Pipewire directly, but that doesn't sound like a proper fix. It may be intentional, however? [There has been a similar issue reported to Pipewire](https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/2643), but it's not exactly what I'm experiencing. Of course I could set the software volume to something static and control it from the interface, but the interface is physically out of reach from my hands and the software volume is easily controlled from my keyboard ;) Kernel: 6.0.1.arch1-1 Pipewire: 0.3.59 alsa-ucm-conf: 1.2.7.2 Desktop environment: GNOME (w/ GDM) Issue URL : https://github.com/alsa-project/alsa-ucm-conf/issues/230 Repository URL: https://github.com/alsa-project/alsa-ucm-conf

1 0