Merge/sound upstream 20230808 #4513
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Rename get_sdw_dailink_info to simply get_dailink_info and have it also return the number of codecs present. Then hoist the allocation of the codec conf structure up into sof_card_dai_links_create. This saves an extra loop through the adr_link array, allows us to get rid of sof_card_codec_conf_alloc and makes the allocation more explicit. Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com> Reviewed-by: Bard Liao <yung-chuan.liao@linux.intel.com> Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com> Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Link: https://lore.kernel.org/r/20230731214257.444605-23-pierre-louis.bossart@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
Hoist the handling logic for group_generated up to the sof_card_dai_links_create level. This avoids the need to pass the array through multiple levels of functions. Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com> Reviewed-by: Bard Liao <yung-chuan.liao@linux.intel.com> Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com> Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Link: https://lore.kernel.org/r/20230731214257.444605-24-pierre-louis.bossart@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
Start removing Intel-specific arguments to make that function usable by other SOC vendors. Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Reviewed-by: Rander Wang <rander.wang@intel.com> Reviewed-by: Bard Liao <yung-chuan.liao@linux.intel.com> Link: https://lore.kernel.org/r/20230731213242.434594-2-pierre-louis.bossart@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
Move existing function in common library to make sure the code can be reused by other SoC vendors. No functionality change outside of the move and added prefix. Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Reviewed-by: Rander Wang <rander.wang@intel.com> Reviewed-by: Bard Liao <yung-chuan.liao@linux.intel.com> Link: https://lore.kernel.org/r/20230731213242.434594-3-pierre-louis.bossart@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
use 'part_id' to follow MIPI/SoundWire wording and use more consistent %#x format. Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Reviewed-by: Rander Wang <rander.wang@intel.com> Reviewed-by: Bard Liao <yung-chuan.liao@linux.intel.com> Link: https://lore.kernel.org/r/20230731213242.434594-4-pierre-louis.bossart@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
For MediaTek AFE, DAI DMA can support different bitwidths compared to the BE DAI. Therefore, it is preferable to obtain the BE frame format from the DAI_CONFIG. Reviewed-by: Yaochun Hung <yc.hung@mediatek.com> Reviewed-by: Daniel Baluta <daniel.baluta@nxp.com> Signed-off-by: Trevor Wu <trevor.wu@mediatek.com> Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Link: https://lore.kernel.org/r/20230731213242.434594-5-pierre-louis.bossart@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
The switch component was never completed and sat half empty for over 3 years. It was recently deleted. For modern components this would require not change in the kernel but since this was a legacy allocation from the enum days of IPC3 we should mark the respective enum as deprecated. The splitter component was never even got a source file in the firmware. Therefore also delete it since this is not needed. Reviewed-by: Bard Liao <yung-chuan.liao@linux.intel.com> Signed-off-by: Curtis Malainey <cujomalainey@chromium.org> Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Link: https://lore.kernel.org/r/20230731213242.434594-6-pierre-louis.bossart@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
The following warning was reported when running stress-mode enabled xdp_redirect_cpu with some RT threads: ------------[ cut here ]------------ WARNING: CPU: 4 PID: 65 at kernel/bpf/cpumap.c:135 CPU: 4 PID: 65 Comm: kworker/4:1 Not tainted 6.5.0-rc2+ #1 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996) Workqueue: events cpu_map_kthread_stop RIP: 0010:put_cpu_map_entry+0xda/0x220 ...... Call Trace: <TASK> ? show_regs+0x65/0x70 ? __warn+0xa5/0x240 ...... ? put_cpu_map_entry+0xda/0x220 cpu_map_kthread_stop+0x41/0x60 process_one_work+0x6b0/0xb80 worker_thread+0x96/0x720 kthread+0x1a5/0x1f0 ret_from_fork+0x3a/0x70 ret_from_fork_asm+0x1b/0x30 </TASK> The root cause is the same as commit 4369016 ("bpf: cpumap: Fix memory leak in cpu_map_update_elem"). The kthread is stopped prematurely by kthread_stop() in cpu_map_kthread_stop(), and kthread() doesn't call cpu_map_kthread_run() at all but XDP program has already queued some frames or skbs into ptr_ring. So when __cpu_map_ring_cleanup() checks the ptr_ring, it will find it was not emptied and report a warning. An alternative fix is to use __cpu_map_ring_cleanup() to drop these pending frames or skbs when kthread_stop() returns -EINTR, but it may confuse the user, because these frames or skbs have been handled correctly by XDP program. So instead of dropping these frames or skbs, just make sure the per-cpu kthread is running before __cpu_map_entry_alloc() returns. After apply the fix, the error handle for kthread_stop() will be unnecessary because it will always return 0, so just remove it. Fixes: 6710e11 ("bpf: introduce new bpf cpu map type BPF_MAP_TYPE_CPUMAP") Signed-off-by: Hou Tao <houtao1@huawei.com> Reviewed-by: Pu Lehui <pulehui@huawei.com> Acked-by: Jesper Dangaard Brouer <hawk@kernel.org> Link: https://lore.kernel.org/r/20230729095107.1722450-2-houtao@huaweicloud.com Signed-off-by: Martin KaFai Lau <martin.lau@kernel.org>
The following warning was reported when running xdp_redirect_cpu with both skb-mode and stress-mode enabled: ------------[ cut here ]------------ Incorrect XDP memory type (-2128176192) usage WARNING: CPU: 7 PID: 1442 at net/core/xdp.c:405 Modules linked in: CPU: 7 PID: 1442 Comm: kworker/7:0 Tainted: G 6.5.0-rc2+ #1 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996) Workqueue: events __cpu_map_entry_free RIP: 0010:__xdp_return+0x1e4/0x4a0 ...... Call Trace: <TASK> ? show_regs+0x65/0x70 ? __warn+0xa5/0x240 ? __xdp_return+0x1e4/0x4a0 ...... xdp_return_frame+0x4d/0x150 __cpu_map_entry_free+0xf9/0x230 process_one_work+0x6b0/0xb80 worker_thread+0x96/0x720 kthread+0x1a5/0x1f0 ret_from_fork+0x3a/0x70 ret_from_fork_asm+0x1b/0x30 </TASK> The reason for the warning is twofold. One is due to the kthread cpu_map_kthread_run() is stopped prematurely. Another one is __cpu_map_ring_cleanup() doesn't handle skb mode and treats skbs in ptr_ring as XDP frames. Prematurely-stopped kthread will be fixed by the preceding patch and ptr_ring will be empty when __cpu_map_ring_cleanup() is called. But as the comments in __cpu_map_ring_cleanup() said, handling and freeing skbs in ptr_ring as well to "catch any broken behaviour gracefully". Fixes: 11941f8 ("bpf: cpumap: Implement generic cpumap") Signed-off-by: Hou Tao <houtao1@huawei.com> Acked-by: Jesper Dangaard Brouer <hawk@kernel.org> Link: https://lore.kernel.org/r/20230729095107.1722450-3-houtao@huaweicloud.com Signed-off-by: Martin KaFai Lau <martin.lau@kernel.org>
Hou Tao says: ==================== The patchset fixes two reported warning in cpu-map when running xdp_redirect_cpu and some RT threads concurrently. Patch #1 fixes the warning in __cpu_map_ring_cleanup() when kthread is stopped prematurely. Patch #2 fixes the warning in __xdp_return() when there are pending skbs in ptr_ring. Please see individual patches for more details. And comments are always welcome. ==================== Signed-off-by: Martin KaFai Lau <martin.lau@kernel.org>
…after-free When u32_change() is called on an existing filter, the whole tcf_result struct is always copied into the new instance of the filter. This causes a problem when updating a filter bound to a class, as tcf_unbind_filter() is always called on the old instance in the success path, decreasing filter_cnt of the still referenced class and allowing it to be deleted, leading to a use-after-free. Fix this by no longer copying the tcf_result struct from the old filter. Fixes: de5df63 ("net: sched: cls_u32 changes to knode must appear atomic to readers") Reported-by: valis <sec@valis.email> Reported-by: M A Ramdhan <ramdhan@starlabs.sg> Signed-off-by: valis <sec@valis.email> Signed-off-by: Jamal Hadi Salim <jhs@mojatatu.com> Reviewed-by: Victor Nogueira <victor@mojatatu.com> Reviewed-by: Pedro Tammela <pctammela@mojatatu.com> Reviewed-by: M A Ramdhan <ramdhan@starlabs.sg> Link: https://lore.kernel.org/r/20230729123202.72406-2-jhs@mojatatu.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
…fter-free When fw_change() is called on an existing filter, the whole tcf_result struct is always copied into the new instance of the filter. This causes a problem when updating a filter bound to a class, as tcf_unbind_filter() is always called on the old instance in the success path, decreasing filter_cnt of the still referenced class and allowing it to be deleted, leading to a use-after-free. Fix this by no longer copying the tcf_result struct from the old filter. Fixes: e35a8ee ("net: sched: fw use RCU") Reported-by: valis <sec@valis.email> Reported-by: Bing-Jhong Billy Jheng <billy@starlabs.sg> Signed-off-by: valis <sec@valis.email> Signed-off-by: Jamal Hadi Salim <jhs@mojatatu.com> Reviewed-by: Victor Nogueira <victor@mojatatu.com> Reviewed-by: Pedro Tammela <pctammela@mojatatu.com> Reviewed-by: M A Ramdhan <ramdhan@starlabs.sg> Link: https://lore.kernel.org/r/20230729123202.72406-3-jhs@mojatatu.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
…e-after-free When route4_change() is called on an existing filter, the whole tcf_result struct is always copied into the new instance of the filter. This causes a problem when updating a filter bound to a class, as tcf_unbind_filter() is always called on the old instance in the success path, decreasing filter_cnt of the still referenced class and allowing it to be deleted, leading to a use-after-free. Fix this by no longer copying the tcf_result struct from the old filter. Fixes: 1109c00 ("net: sched: RCU cls_route") Reported-by: valis <sec@valis.email> Reported-by: Bing-Jhong Billy Jheng <billy@starlabs.sg> Signed-off-by: valis <sec@valis.email> Signed-off-by: Jamal Hadi Salim <jhs@mojatatu.com> Reviewed-by: Victor Nogueira <victor@mojatatu.com> Reviewed-by: Pedro Tammela <pctammela@mojatatu.com> Reviewed-by: M A Ramdhan <ramdhan@starlabs.sg> Link: https://lore.kernel.org/r/20230729123202.72406-4-jhs@mojatatu.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
…oute' valis says: ==================== net/sched Bind logic fixes for cls_fw, cls_u32 and cls_route Three classifiers (cls_fw, cls_u32 and cls_route) always copy tcf_result struct into the new instance of the filter on update. This causes a problem when updating a filter bound to a class, as tcf_unbind_filter() is always called on the old instance in the success path, decreasing filter_cnt of the still referenced class and allowing it to be deleted, leading to a use-after-free. This patch set fixes this issue in all affected classifiers by no longer copying the tcf_result struct from the old filter. ==================== Link: https://lore.kernel.org/r/20230729123202.72406-1-jhs@mojatatu.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Msg length should be obtained from value written to AUX_CH_CTL register rather than from enum type of the register. Commit 0cad796 ("drm/i915: Use REG_BIT() & co. for AUX CH registers") incorrectly calculates the msg_length from reg type and yields below warning in intel_gvt_i2c_handle_aux_ch_write(): "i915 0000:00:02.0: drm_WARN_ON(msg_length != 4)". Fixes: 0cad796 ("drm/i915: Use REG_BIT() & co. for AUX CH registers") Signed-off-by: Yan Zhao <yan.y.zhao@intel.com> Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20230731112033.7275-1-yan.y.zhao@intel.com Reviewed-by: Zhenyu Wang <zhenyuw@linux.intel.com>
If scanning all PMUs the placeholder is still necessary if no core PMU is found. This situation occurs in perf test's parse-events test, when uncore events appear before core. Fixes: 628eaa4 ("perf pmus: Add placeholder core PMU") Signed-off-by: Ian Rogers <irogers@google.com> Tested-by: Thomas Richter <tmricht@linux.ibm.com> Cc: Adrian Hunter <adrian.hunter@intel.com> Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com> Cc: Ian Rogers <irogers@google.com> Cc: Ingo Molnar <mingo@redhat.com> Cc: James Clark <james.clark@arm.com> Cc: Jiri Olsa <jolsa@kernel.org> Cc: Kan Liang <kan.liang@linux.intel.com> Cc: Mark Rutland <mark.rutland@arm.com> Cc: Namhyung Kim <namhyung@kernel.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Ravi Bangoria <ravi.bangoria@amd.com> Cc: Rob Herring <robh@kernel.org> Link: https://lore.kernel.org/r/20230706183705.601412-1-irogers@google.com Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
test__checkevent_complex_name will use an "event" format which if not present, such as with a placeholder PMU, will cause test failures. Skip the test in this case to avoid failures in restricted environments. Add perf_pmu__has_format utility as a general PMU utility. Fixes: 628eaa4 ("perf pmus: Add placeholder core PMU") Signed-off-by: Ian Rogers <irogers@google.com> Tested-by: Thomas Richter <tmricht@linux.ibm.com> Cc: Adrian Hunter <adrian.hunter@intel.com> Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com> Cc: Ian Rogers <irogers@google.com> Cc: Ingo Molnar <mingo@redhat.com> Cc: James Clark <james.clark@arm.com> Cc: Jiri Olsa <jolsa@kernel.org> Cc: Kan Liang <kan.liang@linux.intel.com> Cc: Mark Rutland <mark.rutland@arm.com> Cc: Namhyung Kim <namhyung@kernel.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Ravi Bangoria <ravi.bangoria@amd.com> Cc: Rob Herring <robh@kernel.org> Link: https://lore.kernel.org/r/20230706183705.601412-2-irogers@google.com Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Move the call to cs_dsp_run() in cs35l56_hda_fw_load() so that it is after the CS35L56 has been reset/reinit'd and the regmap cache has been synced. cs_dsp_run() syncs up ALSA control cache values with the DSP memory so this must not be done until the firmware has reinitialized. Signed-off-by: Richard Fitzgerald <rf@opensource.cirrus.com> Link: https://lore.kernel.org/r/20230731165726.7940-2-rf@opensource.cirrus.com Signed-off-by: Takashi Iwai <tiwai@suse.de>
Only call regcache_mark_dirty() in cs35l56_hda_fw_load() if the CS35L56 was SYSTEM_RESET. recache_mark_dirty() changes the behaviour of regcache_sync() to write out cache values that are not the default value, and skip cache values that are the default. AUDIO_REINIT does not reset the registers. regcache_mark_dirty() after AUDIO_REINIT could cause the regcache_sync() to sync registers incorrectly because it will assume that all registers have reset to default. Signed-off-by: Richard Fitzgerald <rf@opensource.cirrus.com> Link: https://lore.kernel.org/r/20230731165726.7940-3-rf@opensource.cirrus.com Signed-off-by: Takashi Iwai <tiwai@suse.de>
When firmware is reloaded after a system resume cs_dsp_power_down() should be called before calling cs_dsp_power_up(). The fw_patched flag should also be cleared and only set again if the firmware download succeeded. Signed-off-by: Richard Fitzgerald <rf@opensource.cirrus.com> Link: https://lore.kernel.org/r/20230731165726.7940-4-rf@opensource.cirrus.com Signed-off-by: Takashi Iwai <tiwai@suse.de>
Always call cs_dsp_power_up() and cs_dsp_run() in cs35l56_hda_fw_load() even if there aren't any firmware files to download. Also, if there aren't any firmware files to download there is no need to do cs35l56_firmware_shutdown() and cs35l56_system_reset(). If there aren't any firmware files there's no need to write anything to the CS35L56 registers to make it work - it will already be running the ROM firmware. So it's not strictly necessary to start cs_dsp. But it's perfectly ok to call cs_dsp_power_up() and cs_dsp_run() without downloading any firmware. This avoids having to support a state where audio is playing but cs_dsp is not running. Signed-off-by: Richard Fitzgerald <rf@opensource.cirrus.com> Link: https://lore.kernel.org/r/20230731165726.7940-5-rf@opensource.cirrus.com Signed-off-by: Takashi Iwai <tiwai@suse.de>
…ove() In cs35l56_hda_unbind() cs_dsp_power_down() must be called to cleanup before calling cs_dsp_remove cs_dsp_remove(). Signed-off-by: Richard Fitzgerald <rf@opensource.cirrus.com> Link: https://lore.kernel.org/r/20230731165726.7940-6-rf@opensource.cirrus.com Signed-off-by: Takashi Iwai <tiwai@suse.de>
… path If cs35l56_hda_fw_load() successfully called cs_dsp_power_up() the error path must balance that with a call to cs_dsp_power_down(). Signed-off-by: Richard Fitzgerald <rf@opensource.cirrus.com> Link: https://lore.kernel.org/r/20230731165726.7940-7-rf@opensource.cirrus.com Signed-off-by: Takashi Iwai <tiwai@suse.de>
A RAM firmware can only be downloaded if the CS35L56 is currently running from ROM firmware. The driver must not try to overwrite the RAM if the CS35L56 is already running from that RAM. Firmware can be downloaded in these two cases: - The BIOS has already patched the firmware (secured mode). In this case the firmware files will only contain tunings that are safe to overwrite. - The CS35L56 is running the built-in ROM firmware. After a RAM firmware has been downloaded it can only be cleared by hard resetting CS35L56. Some systems only hard-reset during power-on and do not give the driver control of hard reset. Signed-off-by: Richard Fitzgerald <rf@opensource.cirrus.com> Link: https://lore.kernel.org/r/20230731165726.7940-8-rf@opensource.cirrus.com Signed-off-by: Takashi Iwai <tiwai@suse.de>
A tuning patch is always needed to enable the ASP audio port. If the BIOS did not patch the firmware, then it is mandatory to have a .bin file. Signed-off-by: Richard Fitzgerald <rf@opensource.cirrus.com> Link: https://lore.kernel.org/r/20230731165726.7940-9-rf@opensource.cirrus.com Signed-off-by: Takashi Iwai <tiwai@suse.de>
The ACPI nodes for CS35L56 can contain an extra I2CSerialBusV2 that is not a real device, it is an alias address. This alias address will not be in the cirrus,dev-index array, so reject any instantions with a device address not found in the array. Signed-off-by: Richard Fitzgerald <rf@opensource.cirrus.com> Link: https://lore.kernel.org/r/20230731165726.7940-10-rf@opensource.cirrus.com Signed-off-by: Takashi Iwai <tiwai@suse.de>
Disabling preemption in sock_map_sk_acquire conflicts with GFP_ATOMIC allocation later in sk_psock_init_link on PREEMPT_RT kernels, since GFP_ATOMIC might sleep on RT (see bpf: Make BPF and PREEMPT_RT co-exist patchset notes for details). This causes calling bpf_map_update_elem on BPF_MAP_TYPE_SOCKMAP maps to BUG (sleeping function called from invalid context) on RT kernels. preempt_disable was introduced together with lock_sk and rcu_read_lock in commit 99ba2b5 ("bpf: sockhash, disallow bpf_tcp_close and update in parallel"), probably to match disabled migration of BPF programs, and is no longer necessary. Remove preempt_disable to fix BUG in sock_map_update_common on RT. Signed-off-by: Tomas Glozar <tglozar@redhat.com> Reviewed-by: Jakub Sitnicki <jakub@cloudflare.com> Link: https://lore.kernel.org/all/20200224140131.461979697@linutronix.de/ Fixes: 99ba2b5 ("bpf: sockhash, disallow bpf_tcp_close and update in parallel") Reviewed-by: John Fastabend <john.fastabend@gmail.com> Link: https://lore.kernel.org/r/20230728064411.305576-1-tglozar@redhat.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
When handling deduplicated compressed data, there can be multiple decompressed extents pointing to the same compressed data in one shot. In such cases, the bvecs which belong to the longest extent will be selected as the primary bvecs for real decompressors to decode and the other duplicated bvecs will be directly copied from the primary bvecs. Previously, only relative offsets of the longest extent were checked to decompress the primary bvecs. On rare occasions, it can be incorrect if there are several extents with the same start relative offset. As a result, some short bvecs could be selected for decompression and then cause data corruption. For example, as Shijie Sun reported off-list, considering the following extents of a file: 117: 903345.. 915250 | 11905 : 385024.. 389120 | 4096 ... 119: 919729.. 930323 | 10594 : 385024.. 389120 | 4096 ... 124: 968881.. 980786 | 11905 : 385024.. 389120 | 4096 The start relative offset is the same: 2225, but extent 119 (919729.. 930323) is shorter than the others. Let's restrict the bvec length in addition to the start offset if bvecs are not full. Reported-by: Shijie Sun <sunshijie@xiaomi.com> Fixes: 5c2a642 ("erofs: introduce partial-referenced pclusters") Tested-by Shijie Sun <sunshijie@xiaomi.com> Reviewed-by: Yue Hu <huyue2@coolpad.com> Reviewed-by: Chao Yu <chao@kernel.org> Signed-off-by: Gao Xiang <hsiangkao@linux.alibaba.com> Link: https://lore.kernel.org/r/20230719065459.60083-1-hsiangkao@linux.alibaba.com
Previously, .kill_sb() will be called only after fill_super fails. It will be changed [1]. Besides, checking for s_magic in erofs_kill_sb() is unnecessary from any point of view. Let's get rid of it now. [1] https://lore.kernel.org/r/20230731-flugbereit-wohnlage-78acdf95ab7e@brauner Signed-off-by: Gao Xiang <hsiangkao@linux.alibaba.com> Reviewed-by: Christoph Hellwig <hch@lst.de> Acked-by: Christian Brauner <brauner@kernel.org> Link: https://lore.kernel.org/r/20230801014737.28614-1-hsiangkao@linux.alibaba.com
Fix the 'NV' definition postfix that is supposed to be INV. Take the chance to also order properly the registers based on their address and call the GEN12_GFX_CCS_AUX_INV address as GEN12_CCS_AUX_INV like all the other similar registers. Remove also VD1, VD3 and VE1 registers that don't exist and add BCS0 and CCS0. Signed-off-by: Andi Shyti <andi.shyti@linux.intel.com> Cc: <stable@vger.kernel.org> # v5.8+ Reviewed-by: Nirmoy Das <nirmoy.das@intel.com> Reviewed-by: Andrzej Hajda <andrzej.hajda@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230725001950.1014671-2-andi.shyti@linux.intel.com (cherry picked from commit 2f0b927) Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
The CS42142 soundwire codec button mapping is corrected to handle the button detection correctly. Fixes: 43cdea0 ("ASoC: Intel: sof_sdw: Add helper function for cs42l42 codec") Signed-off-by: jairaj-arava <jairaj.arava@intel.com> Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com> Reviewed-by: Bard Liao <yung-chuan.liao@linux.intel.com> Link: https://lore.kernel.org/r/20230807215000.515846-2-pierre-louis.bossart@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
Merge series from Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>: This patchset first fixes a number of errors made in the hda-mlink support, then adds Lunar Lake definitions. The main contribution is the hda-dai changes where the HDaudio DMA is now used for SSP, DMIC and SoundWire. In previous hardware the GPDMA (aka DesignWare) was used and controlled by the audio firmware. The volume of code is minimized with the abstraction added in previous kernel cycles. Due to cross-dependencies between ASoC and SoundWire trees, the full support for jack detection will be deferred to the next kernel cycle. There's not much point to ask for a sync of the two trees to support one patch for each tree - we are at -rc5 already.
Trigger callback is not the best place for buffer iterator initialization, so move it out to the prepare callback, where it have to be. Minor enhancement: remove blank line. Signed-off-by: Ivan Orlov <ivan.orlov0322@gmail.com> Link: https://lore.kernel.org/r/20230804110740.9867-1-ivan.orlov0322@gmail.com Signed-off-by: Takashi Iwai <tiwai@suse.de>
Remove redundant definitions of DEVNAME and CARD_NAME, as they're not useful. The former is not used anywhere, and the latter is used only in module parameters descriptions. Signed-off-by: Ivan Orlov <ivan.orlov0322@gmail.com> Link: https://lore.kernel.org/r/20230804110740.9867-2-ivan.orlov0322@gmail.com Signed-off-by: Takashi Iwai <tiwai@suse.de>
These declarations is never used since beginning of git history. Signed-off-by: Yue Haibing <yuehaibing@huawei.com> Link: https://lore.kernel.org/r/20230807141513.31440-1-yuehaibing@huawei.com Signed-off-by: Takashi Iwai <tiwai@suse.de>
`strncpy` is deprecated for use on NUL-terminated destination strings [1]. A suitable replacement is `strscpy` [2] due to the fact that it guarantees NUL-termination on its destination buffer argument which is _not_ the case for `strncpy`! It should be noted that the current implementation is unlikely to have a bug because `drv_name` is a string literal with a size of 9 while `card->driver` has a size of 16. However, it is probably worthwhile to switch to a more robust and less ambiguous interface. [1]: www.kernel.org/doc/html/latest/process/deprecated.html#strncpy-on-nul-terminated-strings [2]: https://manpages.debian.org/testing/linux-manual-4.8/strscpy.9.en.html Link: KSPP#90 Cc: linux-hardening@vger.kernel.org Signed-off-by: Justin Stitt <justinstitt@google.com> Link: https://lore.kernel.org/r/20230807-sound-pci-hda-v1-1-6d9cdcd085ca@google.com Signed-off-by: Takashi Iwai <tiwai@suse.de>
With IPC3, we reset hw_params during the stop trigger, so we should also clean up the link DMA during the stop trigger. Fixes: 1bf83fa ("ASoC: SOF: Intel: hda-dai: Do not perform DMA cleanup during stop") Closes: thesofproject#4455 Closes: thesofproject#4482 Closes: https://bugzilla.kernel.org/show_bug.cgi?id=217673 Signed-off-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com> Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Reviewed-by: Rander Wang <rander.wang@intel.com> Reviewed-by: Péter Ujfalusi <peter.ujfalusi@linux.intel.com> Reviewed-by: Guennadi Liakhovetski <guennadi.liakhovetski@linux.intel.com> Reviewed-by: Bard Liao <yung-chuan.liao@linux.intel.com> Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com> Link: https://lore.kernel.org/r/20230808110627.32375-1-peter.ujfalusi@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
… Out The RT5682, RT1015 and RT1015p codecs used in this driver do not seem capable of distinguishing Line Out connections from Headphone, but the driver configures its jack object as if it can. Remove the wrong value from the jack creation call to avoid any confusion. Signed-off-by: Alper Nebi Yasak <alpernebiyasak@gmail.com> Reviewed-by: Akihiko Odaki <akihiko.odaki@daynix.com> Tested-by: Akihiko Odaki <akihiko.odaki@daynix.com> Link: https://lore.kernel.org/r/20230805162216.441410-1-alpernebiyasak@gmail.com Signed-off-by: Mark Brown <broonie@kernel.org>
plbossart
requested review from
RanderWang,
naveen-manohar,
ryans-lee,
shumingfan,
oder-chiou,
jack-cy-yu,
lgirdwood,
ranj063,
kv2019i,
dbaluta,
bardliao,
ujfalusi,
vijendarmukunda,
kuanhsuncheng and
yaochunhung
as code owners
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Lots of SOF commits merged, quick merge to flush the pipeline. sof-dev-rebase-20230808 pushed