summaryrefslogtreecommitdiff
path: root/include/sound
AgeCommit message (Collapse)AuthorFilesLines
9 daysASoC: SDCA: Add flag for unused IRQsCharles Keepax1-0/+2
[ Upstream commit 775f5729b47d8737f4f98e0141f61b3358245398 ] Zero is a valid SDCA IRQ interrupt position so add a special value to indicate that the IRQ is not used. Reviewed-by: Bard Liao <yung-chuan.liao@linux.intel.com> Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com> Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.dev> Link: https://patch.msgid.link/20250624122844.2761627-6-ckeepax@opensource.cirrus.com Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
14 daysASoC: tas2781: Fix the wrong step for TLV on tas2781Baojun Xu1-1/+1
[ Upstream commit 9843cf7b6fd6f938c16fde51e86dd0e3ddbefb12 ] The step for TLV on tas2781, should be 50 (-0.5dB). Fixes: 678f38eba1f2 ("ASoC: tas2781: Add Header file for tas2781 driver") Signed-off-by: Baojun Xu <baojun.xu@ti.com> Link: https://patch.msgid.link/20250801021618.64627-1-baojun.xu@ti.com Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-07-17ASoC: soc-acpi: add get_function_tplg_files opsBard Liao1-0/+13
[ Upstream commit d1e70eed0b30bd2b15fc6c93b5701be564bbe353 ] We always use a single topology that contains all PCM devices belonging to a machine configuration. However, with SDCA, we want to be able to load function topologies based on the supported device functions. This change is in preparation for loading those function topologies. Signed-off-by: Bard Liao <yung-chuan.liao@linux.intel.com> Reviewed-by: Liam Girdwood <liam.r.girdwood@intel.com> Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com> Reviewed-by: Péter Ujfalusi <peter.ujfalusi@linux.intel.com> Link: https://patch.msgid.link/20250414063239.85200-4-yung-chuan.liao@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org> Stable-dep-of: a7528e9beadb ("ASoC: Intel: soc-acpi: arl: Correct order of cs42l43 matches") Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-06-19ASoC: Intel: avs: Read HW capabilities when possibleCezary Rojewski1-0/+1
[ Upstream commit b9a3ec604993074eb6f5d08b14fb7913d1fae48b ] Starting with LunarLake (LNL) and onward, some hardware capabilities are visible to the sound driver directly. At the same time, these may no longer be visible to the AudioDSP firmware. Update resource allocation function to rely on the registers when possible. Reviewed-by: Amadeusz Sławiński <amadeuszx.slawinski@linux.intel.com> Signed-off-by: Cezary Rojewski <cezary.rojewski@intel.com> Acked-by: Liam Girdwood <liam.r.girdwood@linux.intel.com> Link: https://patch.msgid.link/20250407112352.3720779-4-cezary.rojewski@intel.com Signed-off-by: Mark Brown <broonie@kernel.org> Stable-dep-of: 9e3285be55e6 ("ASoC: Intel: avs: Fix paths in MODULE_FIRMWARE hints") Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-06-19ALSA: hda: Allow to fetch hlink by IDCezary Rojewski1-0/+5
[ Upstream commit 318c9eef63dd30b59dc8d63c7205ae997aa1e524 ] Starting with LNL platform, Intel HDAudio Links carry IDs specifying non-HDAudio transfer type they help facilitate e.g.: 0xC0 for I2S as defined by AZX_REG_ML_LEPTR_ID_INTEL_SSP. The mechanism accounts for LEPTR register as it is Reserved if LCAP.ALT for given Link equals 0. Reviewed-by: Amadeusz Sławiński <amadeuszx.slawinski@linux.intel.com> Signed-off-by: Cezary Rojewski <cezary.rojewski@intel.com> Acked-by: Liam Girdwood <liam.r.girdwood@linux.intel.com> Link: https://patch.msgid.link/20250407112352.3720779-2-cezary.rojewski@intel.com Signed-off-by: Mark Brown <broonie@kernel.org> Stable-dep-of: 347c8d6db7c9 ("ASoC: Intel: avs: Fix PPLCxFMT calculation") Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-06-19ALSA: core: fix up bus match const issues.Greg Kroah-Hartman1-2/+2
[ Upstream commit 62f134ab190c5fd5c9f68fe638ad8e13bb8a4cb4 ] In commit d69d80484598 ("driver core: have match() callback in struct bus_type take a const *"), the match bus callback was changed to have the driver be a const pointer. Unfortunately that const attribute was thrown away when container_of() is called, which is not correct and was not caught by the compiler due to how container_of() is implemented. Fix this up by correctly preserving the const attribute of the driver passed to the bus match function which requires the hdac_driver match function to also take a const pointer for the driver structure. Cc: Jaroslav Kysela <perex@perex.cz> Cc: Takashi Iwai <tiwai@suse.com> Fixes: d69d80484598 ("driver core: have match() callback in struct bus_type take a const *") Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Link: https://patch.msgid.link/2025052204-hyphen-thermal-3e72@gregkh Signed-off-by: Takashi Iwai <tiwai@suse.de> Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-05-16ALSA: pcm: Fix race of buffer access at PCM OSS layerTakashi Iwai1-0/+2
The PCM OSS layer tries to clear the buffer with the silence data at initialization (or reconfiguration) of a stream with the explicit call of snd_pcm_format_set_silence() with runtime->dma_area. But this may lead to a UAF because the accessed runtime->dma_area might be freed concurrently, as it's performed outside the PCM ops. For avoiding it, move the code into the PCM core and perform it inside the buffer access lock, so that it won't be changed during the operation. Reported-by: syzbot+32d4647f551007595173@syzkaller.appspotmail.com Closes: https://lore.kernel.org/68164d8e.050a0220.11da1b.0019.GAE@google.com Cc: <stable@vger.kernel.org> Link: https://patch.msgid.link/20250516080817.20068-1-tiwai@suse.de Signed-off-by: Takashi Iwai <tiwai@suse.de>
2025-05-11ALSA: ump: Fix a typo of snd_ump_stream_msg_device_infoTakashi Iwai1-2/+2
s/devince/device/ It's used only internally, so no any behavior changes. Fixes: 37e0e14128e0 ("ALSA: ump: Support UMP Endpoint and Function Block parsing") Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Link: https://patch.msgid.link/20250511141147.10246-1-tiwai@suse.de Signed-off-by: Takashi Iwai <tiwai@suse.de>
2025-05-01Merge tag 'asoc-fix-v6.15-rc4' of ↵Takashi Iwai1-0/+1
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound into for-linus ASoC: Fixes for v6.15 A moderately large batch of fixes for v6.15, many driver specific including cleanups for the enabling of the Cirrus KUnit tests and a fix for a nasty crash on resume on AMD systems. We also have one core fix, for an ordering issue between DAPM and DPCM which could leave things incorrectly unpowered.
2025-05-01ASoC: intel/sdw_utils: Add volume limit to cs35l56 speakersStefan Binding1-0/+1
The volume control for cs35l56 speakers has a maximum gain of +12 dB. However, for many use cases, this can cause distorted audio, depending various factors, such as other signal-processing elements in the chain, for example if the audio passes through a gain control before reaching the amp or the signal path has been tuned for a particular maximum gain in the amp. In the case of systems which use the soc_sdw_* driver, audio will likely be distorted in all cases above 0 dB, therefore add a volume limit of 400, which is 0 dB maximum volume inside this driver. The volume limit should be applied to both soundwire and soundwire bridge configurations. Signed-off-by: Stefan Binding <sbinding@opensource.cirrus.com> Link: https://patch.msgid.link/20250430103134.24579-3-sbinding@opensource.cirrus.com Signed-off-by: Mark Brown <broonie@kernel.org>
2025-04-29ALSA: ump: Fix buffer overflow at UMP SysEx message conversionTakashi Iwai1-1/+1
The conversion function from MIDI 1.0 to UMP packet contains an internal buffer to keep the incoming MIDI bytes, and its size is 4, as it was supposed to be the max size for a MIDI1 UMP packet data. However, the implementation overlooked that SysEx is handled in a different format, and it can be up to 6 bytes, as found in do_convert_to_ump(). It leads eventually to a buffer overflow, and may corrupt the memory when a longer SysEx message is received. The fix is simply to extend the buffer size to 6 to fit with the SysEx UMP message. Fixes: 0b5288f5fe63 ("ALSA: ump: Add legacy raw MIDI support") Reported-by: Argusee <vr@darknavy.com> Link: https://patch.msgid.link/20250429124845.25128-1-tiwai@suse.de Signed-off-by: Takashi Iwai <tiwai@suse.de>
2025-04-01Merge tag 'soundwire-6.15-rc1' of ↵Linus Torvalds1-0/+69
git://git.kernel.org/pub/scm/linux/kernel/git/vkoul/soundwire Pull soundwire updates from Vinod Koul: - Support for SoundWire Bulk Register Access (BRA) protocol in core along with Intel driver support and ASoC bits required - AMD driver updates and support for ACP 7.0 and 7.1 platforms * tag 'soundwire-6.15-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/vkoul/soundwire: (28 commits) soundwire: take in count the bandwidth of a prepared stream ASoC: rt711-sdca: add DP0 support soundwire: debugfs: add interface for BPT/BRA transfers ASoC: SOF: Intel: hda-sdw-bpt: add CHAIN_DMA support soundwire: intel_ace2x: add BPT send_async/wait callbacks soundwire: intel: add BPT context definition ASoC: SOF: Intel: hda-sdw-bpt: add helpers for SoundWire BPT DMA soundwire: intel_auxdevice: add indirection for BPT send_async/wait soundwire: cadence: add BTP/BRA helpers to format data soundwire: bus: add bpt_stream pointer soundwire: bus: add send_async/wait APIs for BPT protocol soundwire: stream: reuse existing code for BPT stream soundwire: stream: special-case the bus compute_params() routine soundwire: stream: extend sdw_alloc_stream() to take 'type' parameter soundwire: extend sdw_stream_type to BPT soundwire: cadence: add BTP support for DP0 Documentation: driver: add SoundWire BRA description soundwire: amd: change the log level for command response log soundwire: slave: fix an OF node reference leak in soundwire slave device soundwire: Use str_enable_disable-like helpers ...
2025-03-28Merge tag 'drm-next-2025-03-28' of https://gitlab.freedesktop.org/drm/kernelLinus Torvalds1-0/+1
Pull drm updates from Dave Airlie: "Outside of drm there are some rust patches from Danilo who maintains that area in here, and some pieces for drm header check tests. The major things in here are a new driver supporting the touchbar displays on M1/M2, the nova-core stub driver which is just the vehicle for adding rust abstractions and start developing a real driver inside of. xe adds support for SVM with a non-driver specific SVM core abstraction that will hopefully be useful for other drivers, along with support for shrinking for TTM devices. I'm sure xe and AMD support new devices, but the pipeline depth on these things is hard to know what they end up being in the marketplace! uapi: - add mediatek tiled fourcc - add support for notifying userspace on device wedged new driver: - appletbdrm: support for Apple Touchbar displays on m1/m2 - nova-core: skeleton rust driver to develop nova inside off firmware: - add some rust firmware pieces rust: - add 'LocalModule' type alias component: - add helper to query bound status fbdev: - fbtft: remove access to page->index media: - cec: tda998x: import driver from drm dma-buf: - add fast path for single fence merging tests: - fix lockdep warnings atomic: - allow full modeset on connector changes - clarify semantics of allow_modeset and drm_atomic_helper_check - async-flip: support on arbitary planes - writeback: fix UAF - Document atomic-state history format-helper: - support ARGB8888 to ARGB4444 conversions buddy: - fix multi-root cleanup ci: - update IGT dp: - support extended wake timeout - mst: fix RAD to string conversion - increase DPCD eDP control CAP size to 5 bytes - add DPCD eDP v1.5 definition - add helpers for LTTPR transparent mode panic: - encode QR code according to Fido 2.2 scheduler: - add parameter struct for init - improve job peek/pop operations - optimise drm_sched_job struct layout ttm: - refactor pool allocation - add helpers for TTM shrinker panel-orientation: - add a bunch of new quirks panel: - convert panels to multi-style functions - edp: Add support for B140UAN04.4, BOE NV140FHM-NZ, CSW MNB601LS1-3, LG LP079QX1-SP0V, MNE007QS3-7, STA 116QHD024002, Starry 116KHD024006, Lenovo T14s Gen6 Snapdragon - himax-hx83102: Add support for CSOT PNA957QT1-1, Kingdisplay kd110n11-51ie, Starry 2082109qfh040022-50e - visionox-r66451: use multi-style MIPI-DSI functions - raydium-rm67200: Add driver for Raydium RM67200 - simple: Add support for BOE AV123Z7M-N17, BOE AV123Z7M-N17 - sony-td4353-jdi: Use MIPI-DSI multi-func interface - summit: Add driver for Apple Summit display panel - visionox-rm692e5: Add driver for Visionox RM692E5 bridge: - pass full atomic state to various callbacks - adv7511: Report correct capabilities - it6505: Fix HDCP V compare - snd65dsi86: fix device IDs - nwl-dsi: set bridge type - ti-sn65si83: add error recovery and set bridge type - synopsys: add HDMI audio support xe: - support device-wedged event - add mmap support for PCI memory barrier - perf pmu integration and expose per-engien activity - add EU stall sampling support - GPU SVM and Xe SVM implementation - use TTM shrinker - add survivability mode to allow the driver to do firmware updates in critical failure states - PXP HWDRM support for MTL and LNL - expose package/vram temps over hwmon - enable DP tunneling - drop mmio_ext abstraction - Reject BO evcition if BO is bound to current VM - Xe suballocator improvements - re-use display vmas when possible - add GuC Buffer Cache abstraction - PCI ID update for Panther Lake and Battlemage - Enable SRIOV for Panther Lake - Refactor VRAM manager location i915: - enable extends wake timeout - support device-wedged event - Enable DP 128b/132b SST DSC - FBC dirty rectangle support for display version 30+ - convert i915/xe to drm client setup - Compute HDMI PLLS for rates not in fixed tables - Allow DSB usage when PSR is enabled on LNL+ - Enable panel replay without full modeset - Enable async flips with compressed buffers on ICL+ - support luminance based brightness via DPCD for eDP - enable VRR enable/disable without full modeset - allow GuC SLPC default strategies on MTL+ for performance - lots of display refactoring in move to struct intel_display amdgpu: - add device wedged event - support async page flips on overlay planes - enable broadcast RGB drm property - add info ioctl for virt mode - OEM i2c support for RGB lights - GC 11.5.2 + 11.5.3 support - SDMA 6.1.3 support - NBIO 7.9.1 + 7.11.2 support - MMHUB 1.8.1 + 3.3.2 support - DCN 3.6.0 support - Add dynamic workload profile switching for GC 10-12 - support larger VBIOS sizes - Mark gttsize parameters as deprecated - Initial JPEG queue resset support amdkfd: - add KFD per process flags for setting precision - sync pasid values between KGD and KFD - improve GTT/VRAM handling for APUs - fix user queue validation on GC7/8 - SDMA queue reset support raedeon: - rs400 hyperz fix i2c: - td998x: drop platform_data, split driver into media and bridge ast: - transmitter chip detection refactoring - vbios display mode refactoring - astdp: fix connection status and filter unsupported modes - cursor handling refactoring imagination: - check job dependencies with sched helper ivpu: - improve command queue handling - use workqueue for IRQ handling - add support HW fault injection - locking fixes mgag200: - add support for G200eH5 msm: - dpu: add concurrent writeback support for DPU 10.x+ - use LTTPR helpers - GPU: - Fix obscure GMU suspend failure - Expose syncobj timeline support - Extend GPU devcoredump with pagetable info - a623 support - Fix a6xx gen1/gen2 indexed-register blocks in gpu snapshot / devcoredump - Display: - Add cpu-cfg interconnect paths on SM8560 and SM8650 - Introduce KMS OMMU fault handler, causing devcoredump snapshot - Fixed error pointer dereference in msm_kms_init_aspace() - DPU: - Fix mode_changing handling - Add writeback support on SM6150 (QCS615) - Fix DSC programming in 1:1:1 topology - Reworked hardware resource allocation, moving it to the CRTC code - Enabled support for Concurrent WriteBack (CWB) on SM8650 - Enabled CDM blocks on all relevant platforms - Reworked debugfs interface for BW/clocks debugging - Clear perf params before calculating bw - Support YUV formats on writeback - Fixed double inclusion - Fixed writeback in YUV formats when using cloned output, Dropped wb2_formats_rgb - Corrected dpu_crtc_check_mode_changed and struct dpu_encoder_virt kerneldocs - Fixed uninitialized variable in dpu_crtc_kickoff_clone_mode() - DSI: - DSC-related fixes - Rework clock programming - DSI PHY: - Fix 7nm (and lower) PHY programming - Add proper DT schema definitions for DSI PHY clocks - HDMI: - Rework the driver, enabling the use of the HDMI Connector framework - Bindings: - Added eDP PHY on SA8775P nouveau: - move drm_slave_encoder interface into driver - nvkm: refactor GSP RPC - use LTTPR helpers mediatek: - HDMI fixup and refinement - add MT8188 dsc compatible - MT8365 SoC support panthor: - Expose sizes of intenral BOs via fdinfo - Fix race between reset and suspend - Improve locking qaic: - Add support for AIC200 renesas: - Fix limits in DT bindings rockchip: - support rk3562-mali - rk3576: Add HDMI support - vop2: Add new display modes on RK3588 HDMI0 up to 4K - Don't change HDMI reference clock rate - Fix DT bindings - analogix_dp: add eDP support - fix shutodnw solomon: - Set SPI device table to silence warnings - Fix pixel and scanline encoding v3d: - handle clock vc4: - Use drm_exec - Use dma-resv for wait-BO ioctl - Remove seqno infrastructure virtgpu: - Support partial mappings of GEM objects - Reserve VGA resources during initialization - Fix UAF in virtgpu_dma_buf_free_obj() - Add panic support vkms: - Switch to a managed modesetting pipeline - Add support for ARGB8888 - fix UAf xlnx: - Set correct DMA segment size - use mutex guards - Fix error handling - Fix docs" * tag 'drm-next-2025-03-28' of https://gitlab.freedesktop.org/drm/kernel: (1762 commits) drm/amd/pm: Update feature list for smu_v13_0_6 drm/amdgpu: Add parameter documentation for amdgpu_sync_fence drm/amdgpu/discovery: optionally use fw based ip discovery drm/amdgpu/discovery: use specific ip_discovery.bin for legacy asics drm/amdgpu/discovery: check ip_discovery fw file available drm/amd/pm: Remove unnecessay UQ10 to UINT conversion drm/amd/pm: Remove unnecessay UQ10 to UINT conversion drm/amdgpu/sdma_v4_4_2: update VM flush implementation for SDMA drm/amdgpu: Optimize VM invalidation engine allocation and synchronize GPU TLB flush drm/amd/amdgpu: Increase max rings to enable SDMA page ring drm/amdgpu: Decode deferred error type in gfx aca bank parser drm/amdgpu/gfx11: Add Cleaner Shader Support for GFX11.5 GPUs drm/amdgpu/mes: clean up SDMA HQD loop drm/amdgpu/mes: enable compute pipes across all MEC drm/amdgpu/mes: drop MES 10.x leftovers drm/amdgpu/mes: optimize compute loop handling drm/amdgpu/sdma: guilty tracking is per instance drm/amdgpu/sdma: fix engine reset handling drm/amdgpu: remove invalid usage of sched.ready drm/amdgpu: add cleaner shader trace point ...
2025-03-24Merge tag 'asoc-v6.15' of ↵Takashi Iwai12-183/+1330
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound into for-next ASoC: Updates for v6.15 This is a very big release due to a combination of some big new work, mainly new drivers and generic SoundWire support, and some wide ranging cleanup work that made small changes to a lot of drivers. - Morimoto-san has completed the conversion to use modern terminology for the clocking configuration, and several other cleanups with narrower impact. - All the power management operation configuration was updated to use current idioms by Takashi Iwai. - Clarification of the control operations from Charles Keepax. - Prepartory work for more generic SoundWire SCDA controls from Charles Keepax. - Support for AMD ACP 7.x, AWINC WM88166, Everest ES8388, Intel AVS PEAKVOL and GAIN DSP modules Mediatek MT8188 DMIC, NXP i.MX95, nVidia Tegra interconnects, Rockchip RK3588 S/PDIF, Texas Instruments SN012776 and TAS5770L, and Wolfson WM8904 DMICs, Some changes from the tip tree adding APIs needed by the AMD code are included, these were unfortunately rebased in the tip tree after being pulled in. There's also some regmap changes supporting the SCDA work and some devres refactoring that was pulled in to support other changes.
2025-03-20ASoC: wm8904: Add DMIC and DRC supportMark Brown1-0/+3
Merge series from Francesco Dolcini <francesco@dolcini.it>: This patch series adds DMIC and DRC support to the WM8904 driver, a new of_ helper is added to simplify the driver code. DRC functionality is added in the same patch series to provide the necessary dynamic range control to make DMIC support useful. The WM8904 supports digital microphones on two of its inputs: IN1L/DMICDAT1 and IN1R/DMICDAT2. These two inputs can either be connected to an ADC or to the DMIC system. There is an ADC for each line, and only one DMIC block. This DMIC block is either connected to DMICDAT1 or to DMICDAT2. One DMIC data line supports two digital microphones via time multiplexing. The pin's functionality is decided during hardware design (IN1L vs DMICDAT1 and IN1R vs DMICDAT2). This is reflected in the Device Tree. If one line is analog and one is DMIC, we need to be able to switch between ADC and DMIC at runtime. The DMIC source is known from the Device Tree. If both are DMIC inputs, we need to be able to switch the DMIC source. There is no need to switch between ADC and DMIC at runtime. Therefore, kcontrols are dynamically added by the driver depending on its Device Tree configuration. This is a heavy rework of a previous patch series provided by Alifer Moraes and Pierluigi Passaro, https://lore.kernel.org/lkml/20220307141041.27538-1-alifer.m@variscite.com.
2025-03-20ASoC: wm8904: get platform data from DTErnest Van Hoecke1-0/+3
Read in optional codec-specific properties from the device tree. The platform_data structure is not populated when using device trees. This change parses optional dts properties to populate it. - wlf,in1l-as-dmicdat1 - wlf,in1r-as-dmicdat2 - wlf,gpio-cfg - wlf,micbias-cfg - wlf,drc-cfg-regs - wlf,drc-cfg-names - wlf,retune-mobile-cfg-regs - wlf,retune-mobile-cfg-names - wlf,retune-mobile-cfg-hz Datasheet: https://statics.cirrus.com/pubs/proDatasheet/WM8904_Rev4.1.pdf Signed-off-by: Ernest Van Hoecke <ernest.vanhoecke@toradex.com> Signed-off-by: Francesco Dolcini <francesco.dolcini@toradex.com> Reviewed-by: Charles Keepax <ckeepax@opensource.cirrus.com> Link: https://patch.msgid.link/20250319142059.46692-5-francesco@dolcini.it Signed-off-by: Mark Brown <broonie@kernel.org>
2025-03-19ASoC: ops: Remove snd_soc_put_volsw_range()Charles Keepax1-6/+4
With the addition of the soc_mixer_ctl_to_reg() helper it is now very clear that the only difference between snd_soc_put_volsw() and snd_soc_put_volsw_range() is that the former supports double controls with both values in the same register. As such we can combine both functions. Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com> Link: https://patch.msgid.link/20250318171459.3203730-11-ckeepax@opensource.cirrus.com Signed-off-by: Mark Brown <broonie@kernel.org>
2025-03-19ASoC: ops: Remove snd_soc_get_volsw_range()Charles Keepax1-6/+4
With the addition of the soc_mixer_reg_to_ctl() helper it is now very clear that the only difference between snd_soc_get_volsw() and snd_soc_get_volsw_range() is that the former supports double controls with both values in the same register. As such we can combine both functions. Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com> Link: https://patch.msgid.link/20250318171459.3203730-10-ckeepax@opensource.cirrus.com Signed-off-by: Mark Brown <broonie@kernel.org>
2025-03-19ASoC: ops: Remove snd_soc_info_volsw_range()Charles Keepax1-7/+5
The only difference between snd_soc_info_volsw() and snd_soc_info_volsw_range() is that the later will not force a 2 value control to be of type integer if the name ends in "Volume". The kernel currently contains no users of snd_soc_info_volsw_range() that would return a boolean control with this code, so the risk is quite low and it seems appropriate that it should contain volume control detection. So remove snd_soc_info_volsw_range() and point its users at snd_soc_info_volsw(). Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com> Link: https://patch.msgid.link/20250318171459.3203730-9-ckeepax@opensource.cirrus.com Signed-off-by: Mark Brown <broonie@kernel.org>
2025-03-19ASoC: tas2781: Support dsp firmware Alpha and Beta seaiesShenghao Ding2-3/+38
For calibration, basic version does not contain any calibration addresses, it depends on calibration tool to convey the addresses to the driver. Since Alpha and Beta firmware, all the calibration addresses are saved into the firmware. Signed-off-by: Shenghao Ding <shenghao-ding@ti.com> Reviewed-by: Mark Brown <broonie@kernel.org> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Takashi Iwai <tiwai@suse.de> Link: https://patch.msgid.link/20250313093238.1184-1-shenghao-ding@ti.com
2025-03-19Merge branch 'for-linus' into for-nextTakashi Iwai2-1/+35
Back-merge of 6.14 devel branch for further developments of TAS codecsBack-merge of 6.14 devel branch for further developments. Signed-off-by: Takashi Iwai <tiwai@suse.de>
2025-03-16ASoC: SDCA: Add support for GE Entity propertiesCharles Keepax1-0/+48
Add support for parsing the Group Entity properties from DisCo/ACPI. Group Entities allow control of several other Entities, typically Selector Units, from a single control. Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com> Link: https://patch.msgid.link/20250312172205.4152686-7-ckeepax@opensource.cirrus.com Signed-off-by: Mark Brown <broonie@kernel.org>
2025-03-16ASoC: SDCA: Add SDCA Control Range data access helperCharles Keepax1-0/+19
SDCA Ranges are two dimensional arrays of data associated with controls, add a helper to provide an x,y access mechanism to the data and a helper to locate a specific value inside a range. Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com> Link: https://patch.msgid.link/20250312172205.4152686-6-ckeepax@opensource.cirrus.com Signed-off-by: Mark Brown <broonie@kernel.org>
2025-03-16ASoC: SDCA: Add type flag for ControlsCharles Keepax1-0/+23
SDCA Controls come in a variety of data formats, to simplify later parsing work out this data type as the control is parsed and stash it for later use. Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com> Link: https://patch.msgid.link/20250312172205.4152686-5-ckeepax@opensource.cirrus.com Signed-off-by: Mark Brown <broonie@kernel.org>
2025-03-14ASoC: Merge up fixesMark Brown1-1/+4
Merge the for-6.14 to resolve conflicts with simple-card-utils.c due to parallel delveopment.
2025-03-12Backmerge tag 'v6.14-rc6' into drm-nextDave Airlie1-0/+31
This is a backmerge from Linux 6.14-rc6, needed for the nova PR. Signed-off-by: Dave Airlie <airlied@redhat.com>
2025-03-10ASoC: SOF: Intel: hda-sdw-bpt: add helpers for SoundWire BPT DMAPierre-Louis Bossart1-0/+69
Add SoundWire BPT DMA helpers as a separate module to avoid circular dependencies. For now this assumes no link DMA, only coupled mode. Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.dev> Signed-off-by: Bard Liao <yung-chuan.liao@linux.intel.com> Reviewed-by: Péter Ujfalusi <peter.ujfalusi@linux.intel.com> Reviewed-by: Liam Girdwood <liam.r.girdwood@intel.com> Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com> Acked-by: Mark Brown <broonie@kernel.org> Tested-by: shumingf@realtek.com Link: https://lore.kernel.org/r/20250227140615.8147-12-yung-chuan.liao@linux.intel.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2025-03-08ASoC: SOF: Intel: hda-mlink: Add support for mic privacy in VS SHIM registersPeter Ujfalusi1-0/+25
New register has been introduced with PTL in the vendor specific SHIM registers, outside of the IPs itself for microphone privacy status handling. Via the PVCCS register the current microphone privacy status can be checked and the interrupt generation on status change can be enabled/disabled. The status change interrupt is routed to the owner of the interface (DSP/host). The PVCCS is provided for each sublink under the IP to make it possible to control the interrupt generation per sublink. On status change the MDSTSCHG bit needs to be cleared for all sublink of the interface to be able to detect future changes in privacy. The status bit (MDSTS) is volatile in all PVCCS register, it reflects the current state of the GPIO signal. Microphone privacy is a hardware feature (if enabled and configured that way), the host has only passive, monitoring role. The added functions are generic to be future proof if the mic privacy support is extended beyond Soundwire and DMIC links. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com> Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com> Reviewed-by: Liam Girdwood <liam.r.girdwood@intel.com> Reviewed-by: Kai Vehmanen <kai.vehmanen@linux.intel.com> Link: https://patch.msgid.link/20250307112816.1495-7-peter.ujfalusi@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2025-03-08ASoC: SOF: ipc4: Add support for Intel HW managed mic privacy messagingPeter Ujfalusi1-0/+13
ACE3 (Panther Lake) introduced support for microphone privacy feature which can - in hardware - mute incoming audio data based on a state of a physical switch. The change in the privacy state is delivered through interface IP blocks and can only be handled by the link owner. In Intel platforms Soundwire is for example host owned, so the interrupt can only be handled by the host. Since the input stream is going to be muted by hardware, the host needs to send a message to firmware about the change in privacy so it can execute a fade out/in to enhance user experience. The support for microphone privacy can be queried from the HW_CONFIG data under the INTEL_MIC_PRIVACY_CAP tuple. This is Intel specific data, the core will pass it to platform code if the intel_configure_mic_privacy() callback is provided. Platform code can call sof_ipc4_mic_privacy_state_change() to send the IPC message to the firmware on state change. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com> Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com> Reviewed-by: Liam Girdwood <liam.r.girdwood@intel.com> Reviewed-by: Kai Vehmanen <kai.vehmanen@linux.intel.com> Link: https://patch.msgid.link/20250307112816.1495-6-peter.ujfalusi@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2025-03-06ASoC: soc-dai: add snd_soc_dai_mute_is_ctrled_at_trigger()Kuninori Morimoto1-1/+1
Adds snd_soc_dai_mute_is_ctrled_at_trigger() to judge dai->driver->ops->mute_unmute_on_trigger flags Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com> Link: https://patch.msgid.link/871pva6hs2.wl-kuninori.morimoto.gx@renesas.com Signed-off-by: Mark Brown <broonie@kernel.org>
2025-03-05ASoC: Merge up fixesMark Brown1-0/+31
Merge branch 'for-6.14' of https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound into asoc-6.15 to avoid a bunch of add/add conflicts.
2025-03-05ASoC: ops: Consistently treat platform_max as control valueCharles Keepax1-1/+4
This reverts commit 9bdd10d57a88 ("ASoC: ops: Shift tested values in snd_soc_put_volsw() by +min"), and makes some additional related updates. There are two ways the platform_max could be interpreted; the maximum register value, or the maximum value the control can be set to. The patch moved from treating the value as a control value to a register one. When the patch was applied it was technically correct as snd_soc_limit_volume() also used the register interpretation. However, even then most of the other usages treated platform_max as a control value, and snd_soc_limit_volume() has since been updated to also do so in commit fb9ad24485087 ("ASoC: ops: add correct range check for limiting volume"). That patch however, missed updating snd_soc_put_volsw() back to the control interpretation, and fixing snd_soc_info_volsw_range(). The control interpretation makes more sense as limiting is typically done from the machine driver, so it is appropriate to use the customer facing representation rather than the internal codec representation. Update all the code to consistently use this interpretation of platform_max. Finally, also add some comments to the soc_mixer_control struct to hopefully avoid further patches switching between the two approaches. Fixes: fb9ad24485087 ("ASoC: ops: add correct range check for limiting volume") Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com> Link: https://patch.msgid.link/20250228151456.3703342-1-ckeepax@opensource.cirrus.com Signed-off-by: Mark Brown <broonie@kernel.org>
2025-03-04ASoC: Tidy up SOC_DOUBLE_* and SOC_SINGLE_* helpersCharles Keepax2-43/+26
Re-implement SOC_DOUBLE_VALUE() in terms of SOC_DOUBLE_S_VALUE(). SOC_DOUBLE_S_VALUE() already had a minimum value so add this to SOC_DOUBLE_VALUE as well, this allows replacement of several hard coded value entries. Likewise update SOC_SINGLE_VALUE to match, which allows replacement of even more hard coded values. Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com> Link: https://patch.msgid.link/20250304140500.976127-14-ckeepax@opensource.cirrus.com Signed-off-by: Mark Brown <broonie@kernel.org>
2025-03-04Tidy up ASoC VALUE control macrosMark Brown2-55/+33
Merge series from Charles Keepax <ckeepax@opensource.cirrus.com>: Tidy up the ASoC control value macros. Fix some drivers that should be using core macros that aren't, combine the existing core macros to be a little more consistent in style, and update the core macros to use each other where possible.
2025-03-04ALSA: hda/realtek: Enable PC beep passthrough for HP EliteBook 855 G7Maciej S. Szmigiero1-0/+1
PC speaker works well on this platform in BIOS and in Linux until sound card drivers are loaded. Then it stops working. There seems to be a beep generator node at 0x1a in this CODEC (ALC269_TYPE_ALC215) but it seems to be only connected to capture mixers at nodes 0x22 and 0x23. If I unmute the mixer input for 0x1a at node 0x23 and start recording from its "ALC285 Analog" capture device I can clearly hear beeps in that recording. So the beep generator is indeed working properly, however I wasn't able to figure out any way to connect it to speakers. However, the bits in the "Passthrough Control" register (0x36) seems to work at least partially: by zeroing "B" and "h" and setting "S" I can at least make the PIT PC speaker output appear either in this laptop speakers or headphones (depending on whether they are connected or not). There are some caveats, however: * If the CODEC gets runtime-suspended the beeps stop so it needs HDA beep device for keeping it awake during beeping. * If the beep generator node is generating any beep the PC beep passthrough seems to be temporarily inhibited, so the HDA beep device has to be prevented from using the actual beep generator node - but the beep device is still necessary due to the previous point. * In contrast with other platforms here beep amplification has to be disabled otherwise the beeps output are WAY louder than they were on pure BIOS setup. Unless someone (from Realtek probably) knows how to make the beep generator node output appear in speakers / headphones using PC beep passthrough seems to be the only way to make PC speaker beeping actually work on this platform. Signed-off-by: Maciej S. Szmigiero <mail@maciej.szmigiero.name> Acked-by: kailang@realtek.com Link: https://patch.msgid.link/7461f695b4daed80f2fc4b1463ead47f04f9ad05.1739741254.git.mail@maciej.szmigiero.name Signed-off-by: Takashi Iwai <tiwai@suse.de>
2025-03-03ASoC: Tidy up SOC_DOUBLE_R_* helpersCharles Keepax1-18/+10
Re-implement SOC_DOUBLE_R_VALUE() in terms of SOC_DOUBLE_R_S_VALUE(). SOC_DOUBLE_R_S_VALUE() already had a minimum value so add this to SOC_DOUBLE_R_VALUE() as well, which makes SOC_DOUBLE_R_RANGE_VALUE() redundant, so its usage is replaced. Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com> Link: https://patch.msgid.link/20250303171424.444556-13-ckeepax@opensource.cirrus.com Signed-off-by: Mark Brown <broonie@kernel.org>
2025-03-03ASoC: dapm: Use ASoC control macros where possibleCharles Keepax1-40/+22
Update the DAPM kcontrol creation macros to use the ASoC macros where a helpful version exists. One minor fixup is required in adau17x1, the compiler doesn't like the extra level of macro indirection coupled with the inline struct definition. Make the struct definition explicit. Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com> Link: https://patch.msgid.link/20250303171424.444556-12-ckeepax@opensource.cirrus.com Signed-off-by: Mark Brown <broonie@kernel.org>
2025-03-03ASoC: dapm: Add missing SOC_DAPM_DOUBLE_R_TLV() helperCharles Keepax1-0/+7
A few drivers are open coding SOC_DAPM_DOUBLE_R_TLV() add a core helper and use that instead. Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com> Link: https://patch.msgid.link/20250303171424.444556-11-ckeepax@opensource.cirrus.com Signed-off-by: Mark Brown <broonie@kernel.org>
2025-03-03ASoC: Remove unused helper macroCharles Keepax1-3/+0
SOC_SINGLE_VALUE_EXT() has no users, so remove it. Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com> Link: https://patch.msgid.link/20250303171424.444556-2-ckeepax@opensource.cirrus.com Signed-off-by: Mark Brown <broonie@kernel.org>
2025-03-03ASoC: soc-dai: remove SND_SOC_DAIFMT_CB{MS}_CF{MS}Kuninori Morimoto1-6/+0
No drivers are using SND_SOC_DAIFMT_CB{MS}_CF{MS}. Let's remove it. Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com> Link: https://patch.msgid.link/875xkx8owm.wl-kuninori.morimoto.gx@renesas.com Signed-off-by: Mark Brown <broonie@kernel.org>
2025-02-27ASoC: SDCA: Add helper to write out defaults and fixed valuesCharles Keepax1-0/+4
The concept of an SDCA default value differs slightly from the regmap usage of the term. An SDCA default is a value that is parsed from DisCo and then written out to the hardware if no user value has superceded it. Add a helper function that will iterate through all the SDCA Controls and write out any default values. After these have been written out once they will exist in the cache and that will take care of any user values superceeding them. The code here also writes out any Controls with a fixed value as there is only one available value for these Controls there is no point in allowing the user to select them, simply treat them similarly to a default. Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com> Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.dev> Link: https://patch.msgid.link/20250217140159.2288784-5-ckeepax@opensource.cirrus.com Signed-off-by: Mark Brown <broonie@kernel.org>
2025-02-27ASoC: SDCA: Add regmap helpers for parsing for DisCo Constant valuesCharles Keepax1-0/+6
Add helpers to parse the DisCo Constant values from ACPI and populate an array of reg_defaults with these. This will allow drivers to access these ACPI specified values through the same interface as other registers that are physically present on the device, using the regmap cache. Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com> Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.dev> Link: https://patch.msgid.link/20250217140159.2288784-4-ckeepax@opensource.cirrus.com Signed-off-by: Mark Brown <broonie@kernel.org>
2025-02-27ASoC: SDCA: Add generic regmap SDCA helpersCharles Keepax1-0/+21
Add helper functions that SDCA drivers can use to calculate the properties of SDCA Controls (registers) specified through DisCo. Most of these are fairly obvious from the SDCA Access Modes. DisCo Constants, values which are specified in the ACPI rather than on the device, are handled as unreadable and unwritable registers. The intention is these will be populated in the register defaults table allowing drivers to read them normally. This means the drivers can be agnostic as to which values are DisCo Constants. Finally, support for SDCA Dual Ranked Controls is currently limited here, at the moment the current value will be used directly. Writing the current value directly is valid as per the specification although the synchronicity of updates across multiple registers is lost. Support for this will probably need to be added later. But its a fairly hard problem and doesn't need to be solved immediately. Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com> Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.dev> Link: https://patch.msgid.link/20250217140159.2288784-3-ckeepax@opensource.cirrus.com Signed-off-by: Mark Brown <broonie@kernel.org>
2025-02-26ASoC: tas2781: Clean up for some defineBaojun Xu1-10/+11
Do some clean up for some define in header file. Like change lower case in value, up case in define, space add in recommends, change date of files and add author. Signed-off-by: Baojun Xu <baojun.xu@ti.com> Link: https://patch.msgid.link/20250226144328.11645-1-baojun.xu@ti.com Signed-off-by: Mark Brown <broonie@kernel.org>
2025-02-25ASoC: cs35l56: Prevent races when soft-resetting using SPI controlRichard Fitzgerald1-0/+31
When SPI is used for control, the driver must hold the SPI bus lock while issuing the sequence of writes to perform a soft reset. >From the time the driver writes the SYSTEM_RESET command until the driver does a write to terminate the reset, there must not be any activity on the SPI bus lines. If there is any SPI activity during the soft-reset, another soft-reset will be triggered. The state of the SPI chip select is irrelevant. A repeated soft-reset does not in itself cause any problems, and it is not an infinite loop. The problem is a race between these resets and the driver polling for boot completion. There is a time window between soft resets where the driver could read HALO_STATE as 2 (fully booted) while the chip is actually soft-resetting. Although this window is small, it is long enough that it is possible to hit it in normal operation. To prevent this race and ensure the chip really is fully booted, the driver calls spi_bus_lock() to prevent other activity while resetting. It then issues the SYSTEM_RESET mailbox command. After allowing sufficient time for reset to take effect, the driver issues a PING mailbox command, which will force completion of the full soft-reset sequence. The SPI bus lock can then be rele