linux-toradex.git/include/sound, branch v6.2-rc2 Linux kernel for Apalis and Colibri modules ALSA: hda/hdmi: fix stream-id config keep-alive for rt suspend 2022-12-09T11:06:15+00:00 Kai Vehmanen kai.vehmanen@linux.intel.com 2022-12-09T10:18:22+00:00 ee0b089d660021792e4ab4dda191b097ce1e964f When the new style KAE keep-alive implementation is used on compatible Intel hardware, the clocks are maintained when codec is in D3. The generic code in hda_cleanup_all_streams() can however interfere with generation of audio samples in this mode, by setting the stream and channel ids to zero. To get full benefit of the keepalive, set the new no_stream_clean_at_suspend quirk bit on affected Intel hardware. When this bit is set, stream cleanup is skipped in hda_call_codec_suspend(). Special handling is needed for the case when system goes to suspend. The stream id programming can be lost in this case. This will also cause codec->cvt_setups to be out of sync. Handle this by implementing custom suspend/resume handlers. If keep-alive is active for any converter, set the quirk flags no_stream_clean_at_suspend and forced_resume. Upon resume, keepalive programming is restored if needed. Fixes: 15175a4f2bbb ("ALSA: hda/hdmi: add keep-alive support for ADL-P and DG2") Signed-off-by: Kai Vehmanen <kai.vehmanen@linux.intel.com> Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Link: https://lore.kernel.org/r/20221209101822.3893675-4-kai.vehmanen@linux.intel.com Signed-off-by: Takashi Iwai <tiwai@suse.de> 
When the new style KAE keep-alive implementation is used on compatible
Intel hardware, the clocks are maintained when codec is in D3. The
generic code in hda_cleanup_all_streams() can however interfere with
generation of audio samples in this mode, by setting the stream and
channel ids to zero.

To get full benefit of the keepalive, set the new
no_stream_clean_at_suspend quirk bit on affected Intel hardware. When
this bit is set, stream cleanup is skipped in hda_call_codec_suspend().

Special handling is needed for the case when system goes to suspend. The
stream id programming can be lost in this case. This will also cause
codec->cvt_setups to be out of sync. Handle this by implementing custom
suspend/resume handlers. If keep-alive is active for any converter, set
the quirk flags no_stream_clean_at_suspend and forced_resume. Upon
resume, keepalive programming is restored if needed.

Fixes: 15175a4f2bbb ("ALSA: hda/hdmi: add keep-alive support for ADL-P and DG2")
Signed-off-by: Kai Vehmanen <kai.vehmanen@linux.intel.com>
Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Link: https://lore.kernel.org/r/20221209101822.3893675-4-kai.vehmanen@linux.intel.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Merge tag 'asoc-v6.2-2' of https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound into for-next 2022-12-09T08:50:13+00:00 Takashi Iwai tiwai@suse.de 2022-12-09T08:50:13+00:00 a587601b55df505f38b18832d941e47dbbf084ce ASoC: Updates for v6.2 A few more updates for v6.2 which can hopefully go into a later pull request, the bulk of these are fixes, minor cleanups or new board quirks - the one big bit that isn't is support for getting diagnostic data out of the Intel AVS firmwares. 
ASoC: Updates for v6.2

A few more updates for v6.2 which can hopefully go into a later pull
request, the bulk of these are fixes, minor cleanups or new board quirks
- the one big bit that isn't is support for getting diagnostic data out
of the Intel AVS firmwares.
Merge tag 'asoc-v6.2' of https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound into for-next 2022-12-06T10:13:26+00:00 Takashi Iwai tiwai@suse.de 2022-12-06T10:13:26+00:00 8ec2d95f50c06f5cf2a2b94bcdf47f494f91ad55 ASoC: Updates for v6.2 This is a fairly sedate release for the core code, but there's been a lot of driver work especially around the x86 platforms and device tree updates: - More cleanups of the DAPM code from Morimoto-san. - Factoring out of mapping hw_params onto SoundWire configuration by Charles Keepax. - The ever ongoing overhauls of the Intel DSP code continue, including support for loading libraries and probes with IPC4 on SOF. - Support for more sample formats on JZ4740. - Lots of device tree conversions and fixups. - Support for Allwinner D1, a range of AMD and Intel systems, Mediatek systems with multiple DMICs, Nuvoton NAU8318, NXP fsl_rpmsg and i.MX93, Qualcomm AudioReach Enable, MFC and SAL, RealTek RT1318 and Rockchip RK3588 There's more cross tree updates than usual, though all fairly minor: - Some OMAP board file updates that were depedencies for removing their providers in ASoC, as part of a wider effort removing the support for the relevant OMAP platforms. - A new I2C API required for updates to the new I2C probe API. - A DRM update making use of a new API for fixing the capabilities advertised via hdmi-codec. Since this is being sent early I might send some more stuff if you've not yet sent your pull request and there's more come in. 
ASoC: Updates for v6.2

This is a fairly sedate release for the core code, but there's been a
lot of driver work especially around the x86 platforms and device tree
updates:

 - More cleanups of the DAPM code from Morimoto-san.
 - Factoring out of mapping hw_params onto SoundWire configuration by
   Charles Keepax.
 - The ever ongoing overhauls of the Intel DSP code continue, including
   support for loading libraries and probes with IPC4 on SOF.
 - Support for more sample formats on JZ4740.
 - Lots of device tree conversions and fixups.
 - Support for Allwinner D1, a range of AMD and Intel systems, Mediatek
   systems with multiple DMICs, Nuvoton NAU8318, NXP fsl_rpmsg and
   i.MX93, Qualcomm AudioReach Enable, MFC and SAL, RealTek RT1318 and
   Rockchip RK3588

There's more cross tree updates than usual, though all fairly minor:

 - Some OMAP board file updates that were depedencies for removing their
   providers in ASoC, as part of a wider effort removing the support for
   the relevant OMAP platforms.
 - A new I2C API required for updates to the new I2C probe API.
 - A DRM update making use of a new API for fixing the capabilities
   advertised via hdmi-codec.

Since this is being sent early I might send some more stuff if you've
not yet sent your pull request and there's more come in.
ALSA: hda: Allow for compress stream to hdac_ext_stream assignment 2022-12-05T14:05:18+00:00 Cezary Rojewski cezary.rojewski@intel.com 2022-12-02T15:28:26+00:00 97d73d978271ade27fc751ad606f23c1c4c43678 Currently only PCM streams can enlist hdac_stream for their data transfer. Add cstream field to hdac_ext_stream to expose possibility of compress stream assignment in place of PCM one. Limited to HOST-type only as there no other users on the horizon. Signed-off-by: Cezary Rojewski <cezary.rojewski@intel.com> Acked-by: Takashi Iwai <tiwai@suse.de> Link: https://lore.kernel.org/r/20221202152841.672536-2-cezary.rojewski@intel.com Signed-off-by: Mark Brown <broonie@kernel.org> 
Currently only PCM streams can enlist hdac_stream for their data
transfer. Add cstream field to hdac_ext_stream to expose possibility of
compress stream assignment in place of PCM one.
Limited to HOST-type only as there no other users on the horizon.

Signed-off-by: Cezary Rojewski <cezary.rojewski@intel.com>
Acked-by: Takashi Iwai <tiwai@suse.de>
Link: https://lore.kernel.org/r/20221202152841.672536-2-cezary.rojewski@intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
ASoC/tda998x: Fix reporting of nonexistent capture streams 2022-12-04T17:01:50+00:00 Mark Brown broonie@kernel.org 2022-12-04T17:01:50+00:00 f19a2caaab073873f673a41ce366ac898f34f543 Merge series from Mark Brown <broonie@kernel.org>: The recently added pcm-test selftest has pointed out that systems with the tda998x driver end up advertising that they support capture when in reality as far as I can see the tda998x devices are transmit only. The DAIs registered through hdmi-codec are bidirectional, meaning that for I2S systems when combined with a typical bidrectional CPU DAI the overall capability of the PCM is bidirectional. In most cases the I2S links will clock OK but no useful audio will be returned which isn't so bad but we should still not advertise the useless capability, and some systems may notice problems for example due to pinmux management. This is happening due to the hdmi-codec helpers not providing any mechanism for indicating unidirectional audio so add one and use it in the tda998x driver. It is likely other hdmi-codec users are also affected but I don't have those systems to hand. Mark Brown (2): ASoC: hdmi-codec: Allow playback and capture to be disabled drm: tda99x: Don't advertise non-existent capture support drivers/gpu/drm/i2c/tda998x_drv.c | 2 ++ include/sound/hdmi-codec.h | 4 ++++ sound/soc/codecs/hdmi-codec.c | 30 +++++++++++++++++++++++++----- 3 files changed, 31 insertions(+), 5 deletions(-) base-commit: f0c4d9fc9cc9462659728d168387191387e903cc -- 2.30.2 
Merge series from Mark Brown <broonie@kernel.org>:

The recently added pcm-test selftest has pointed out that systems with
the tda998x driver end up advertising that they support capture when in
reality as far as I can see the tda998x devices are transmit only.  The
DAIs registered through hdmi-codec are bidirectional, meaning that for
I2S systems when combined with a typical bidrectional CPU DAI the
overall capability of the PCM is bidirectional.  In most cases the I2S
links will clock OK but no useful audio will be returned which isn't so
bad but we should still not advertise the useless capability, and some
systems may notice problems for example due to pinmux management.

This is happening due to the hdmi-codec helpers not providing any
mechanism for indicating unidirectional audio so add one and use it in
the tda998x driver.  It is likely other hdmi-codec users are also
affected but I don't have those systems to hand.

Mark Brown (2):
  ASoC: hdmi-codec: Allow playback and capture to be disabled
  drm: tda99x: Don't advertise non-existent capture support

 drivers/gpu/drm/i2c/tda998x_drv.c |  2 ++
 include/sound/hdmi-codec.h        |  4 ++++
 sound/soc/codecs/hdmi-codec.c     | 30 +++++++++++++++++++++++++-----
 3 files changed, 31 insertions(+), 5 deletions(-)

base-commit: f0c4d9fc9cc9462659728d168387191387e903cc
--
2.30.2
ASoC: hdmi-codec: Allow playback and capture to be disabled 2022-12-02T14:07:12+00:00 Mark Brown broonie@kernel.org 2022-11-30T18:46:43+00:00 f77a066f4ed307db93aafee621e2683c3bda98ce Currently the hdmi-codec driver always registers both playback and capture capabilities but for most systems there's no actual capture capability, usually HDMI is transmit only. Provide platform data which allows the users to indicate what is supported so that we don't end up advertising things to userspace that we can't actually support. In order to avoid breaking existing users the flags in platform data are a bit awkward and specify what should be disabled rather than doing the perhaps more expected thing and defaulting to not supporting capture. Reviewed-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Link: https://lore.kernel.org/r/20221130184644.464820-2-broonie@kernel.org Signed-off-by: Mark Brown <broonie@kernel.org> 
Currently the hdmi-codec driver always registers both playback and capture
capabilities but for most systems there's no actual capture capability,
usually HDMI is transmit only. Provide platform data which allows the users
to indicate what is supported so that we don't end up advertising things
to userspace that we can't actually support.

In order to avoid breaking existing users the flags in platform data are
a bit awkward and specify what should be disabled rather than doing the
perhaps more expected thing and defaulting to not supporting capture.

Reviewed-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
Link: https://lore.kernel.org/r/20221130184644.464820-2-broonie@kernel.org
Signed-off-by: Mark Brown <broonie@kernel.org>
ASoC: SOF: Add DAI configuration support for AMD platforms. 2022-11-29T12:56:09+00:00 V sujith kumar Reddy Vsujithkumar.Reddy@amd.com 2022-11-29T10:00:59+00:00 75af41991955205fa0958feb587ce22b35aaa7b0 Add support for configuring sp and hs DAI from topology. Signed-off-by: V sujith kumar Reddy <Vsujithkumar.Reddy@amd.com> Link: https://lore.kernel.org/r/20221129100102.826781-1-vsujithkumar.reddy@amd.corp-partner.google.com Signed-off-by: Mark Brown <broonie@kernel.org> 
Add support for configuring sp and hs DAI from topology.

Signed-off-by: V sujith kumar Reddy <Vsujithkumar.Reddy@amd.com>
Link: https://lore.kernel.org/r/20221129100102.826781-1-vsujithkumar.reddy@amd.corp-partner.google.com
Signed-off-by: Mark Brown <broonie@kernel.org>
ASoC: Merge up fixes 2022-11-29T12:55:51+00:00 Mark Brown broonie@kernel.org 2022-11-29T12:55:12+00:00 aeb2e9c4eedc6fed264a51ca2ea17c83984d2a64 Merge the fixes branch up so we can apply further AMD work. 
Merge the fixes branch up so we can apply further AMD work.
sound: sdw: Add hw_params to SoundWire config helper function 2022-11-28T13:04:24+00:00 Charles Keepax ckeepax@opensource.cirrus.com 2022-11-23T16:54:24+00:00 e45875168d19051ebf0fc4b091da6256f3ea3669 The vast majority of the current users of the SoundWire framework have almost identical code for converting from hw_params to SoundWire configuration. Whilst complex devices might require more, it is very likely that most new devices will follow the same pattern. Save a little code by factoring this out into a helper function. Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com> Link: https://lore.kernel.org/r/20221123165432.594972-1-ckeepax@opensource.cirrus.com Signed-off-by: Mark Brown <broonie@kernel.org> 
The vast majority of the current users of the SoundWire framework
have almost identical code for converting from hw_params to SoundWire
configuration. Whilst complex devices might require more, it is very
likely that most new devices will follow the same pattern. Save a
little code by factoring this out into a helper function.

Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com>
Link: https://lore.kernel.org/r/20221123165432.594972-1-ckeepax@opensource.cirrus.com
Signed-off-by: Mark Brown <broonie@kernel.org>
ALSA: pcm: fix undefined behavior in bit shift for SNDRV_PCM_RATE_KNOT 2022-11-23T06:56:47+00:00 Baisong Zhong zhongbaisong@huawei.com 2022-11-21T11:00:44+00:00 b5172e62458f8e6ff359e5f096044a488db90ac5 Shifting signed 32-bit value by 31 bits is undefined, so changing significant bit to unsigned. The UBSAN warning calltrace like below: UBSAN: shift-out-of-bounds in sound/core/pcm_native.c:2676:21 left shift of 1 by 31 places cannot be represented in type 'int' ... Call Trace: <TASK> dump_stack_lvl+0x8d/0xcf ubsan_epilogue+0xa/0x44 __ubsan_handle_shift_out_of_bounds+0x1e7/0x208 snd_pcm_open_substream+0x9f0/0xa90 snd_pcm_oss_open.part.26+0x313/0x670 snd_pcm_oss_open+0x30/0x40 soundcore_open+0x18b/0x2e0 chrdev_open+0xe2/0x270 do_dentry_open+0x2f7/0x620 path_openat+0xd66/0xe70 do_filp_open+0xe3/0x170 do_sys_openat2+0x357/0x4a0 do_sys_open+0x87/0xd0 do_syscall_64+0x34/0x80 Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Signed-off-by: Baisong Zhong <zhongbaisong@huawei.com> Link: https://lore.kernel.org/r/20221121110044.3115686-1-zhongbaisong@huawei.com Signed-off-by: Takashi Iwai <tiwai@suse.de> 
Shifting signed 32-bit value by 31 bits is undefined, so changing
significant bit to unsigned. The UBSAN warning calltrace like below:

UBSAN: shift-out-of-bounds in sound/core/pcm_native.c:2676:21
left shift of 1 by 31 places cannot be represented in type 'int'
...
Call Trace:
 <TASK>
 dump_stack_lvl+0x8d/0xcf
 ubsan_epilogue+0xa/0x44
 __ubsan_handle_shift_out_of_bounds+0x1e7/0x208
 snd_pcm_open_substream+0x9f0/0xa90
 snd_pcm_oss_open.part.26+0x313/0x670
 snd_pcm_oss_open+0x30/0x40
 soundcore_open+0x18b/0x2e0
 chrdev_open+0xe2/0x270
 do_dentry_open+0x2f7/0x620
 path_openat+0xd66/0xe70
 do_filp_open+0xe3/0x170
 do_sys_openat2+0x357/0x4a0
 do_sys_open+0x87/0xd0
 do_syscall_64+0x34/0x80

Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
Signed-off-by: Baisong Zhong <zhongbaisong@huawei.com>
Link: https://lore.kernel.org/r/20221121110044.3115686-1-zhongbaisong@huawei.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>