cancel
Showing results for 
Search instead for 
Did you mean: 

stm32mp156C-DK2: amixer sound configuration "invalid argument"

AVazquez
Associate III

Hi all!

I am testing the audio configuration for the stm32mp156C-Dk2, with lastest demo(4.0.1-openstlinux-5.15-yocto-kirkstone-mp1-v22.06.15).

I followed the sound card configuration [tutorial](https://wiki.st.com/stm32mpu/wiki/Soundcard_configuration) and I can't configurate correctly somes controls.

E.g (Analog Playback Volume)

root@stm32mp1:~# amixer -c STM32MP15DK cset name='Analog Playback Volume' '204','204'
amixer: Control sysdefault:0 element write error: Invalid argument
 
root@stm32mp1:~# amixer -c STM32MP15DK cset name='Analog Playback Volume' '100','100'
numid=3,iface=MIXER,name='Analog Playback Volume'
  ; type=INTEGER,access=rw---R--,values=2,min=0,max=228,step=0
  : values=100,100
  | dBscale-min=-102.00dB,step=0.50dB,mute=0

In this case, the max argument is 228 but when I try it with the value 204, it says: "invalid argument" but with other lower value it works...

This also happen with others controls.

What is the reason for this to happen?

Regards!

Thanks!

This discussion is locked. Please start a new topic to ask your question.
1 ACCEPTED SOLUTION

Accepted Solutions
Grodriguez
Senior

This is actually a bug that was introduced in the upstream kernel, in commit 4f1e50d6a9cf9c1b8c859d449b5031cacfa8404e ("ASoC: ops: Reject out of bounds values in snd_soc_put_volsw_sx()"). The problem is described in this thread: https://lore.kernel.org/all/Yph8C3bRxcr6ogW7@sirena.org.uk/T/

The following patch should fix it:

https://lore.kernel.org/all/20220511134137.169575-1-broonie@kernel.org/

Note, that patch series also has an additional patch to apply bounds checking to the second channel:

https://lore.kernel.org/all/20220511134137.169575-2-broonie@kernel.org/

That 2nd channel patch is broken; if you apply it, make sure to also apply this fix:

https://lore.kernel.org/all/20221125162348.1288005-1-ckeepax@opensource.cirrus.com/

Guillermo

View solution in original post

3 REPLIES 3
Grodriguez
Senior

This is actually a bug that was introduced in the upstream kernel, in commit 4f1e50d6a9cf9c1b8c859d449b5031cacfa8404e ("ASoC: ops: Reject out of bounds values in snd_soc_put_volsw_sx()"). The problem is described in this thread: https://lore.kernel.org/all/Yph8C3bRxcr6ogW7@sirena.org.uk/T/

The following patch should fix it:

https://lore.kernel.org/all/20220511134137.169575-1-broonie@kernel.org/

Note, that patch series also has an additional patch to apply bounds checking to the second channel:

https://lore.kernel.org/all/20220511134137.169575-2-broonie@kernel.org/

That 2nd channel patch is broken; if you apply it, make sure to also apply this fix:

https://lore.kernel.org/all/20221125162348.1288005-1-ckeepax@opensource.cirrus.com/

Guillermo

Grodriguez
Senior

Additionally, if your kernel has this patch applied:

https://lore.kernel.org/all/20220602162119.3393857-7-ckeepax@opensource.cirrus.com/

This is wrong and breaks the volume range for the "PGA Volume" control. The following patch reverts this:

https://lore.kernel.org/all/20221125163748.1288942-2-ckeepax@opensource.cirrus.com/

Full discussion here:

https://lore.kernel.org/all/20221128171622.GI105268@ediswmail.ad.cirrus.com/

Guillermo

Thanks @Grodriguez​ , this solves the problem completely.

I hope they will integrate these patches in a future release.

Cheers.

Alejandro.