IF YOU WOULD LIKE TO GET AN ACCOUNT, please write an
email to Administrator. User accounts are meant only to access repo
and report issues and/or generate pull requests.
This is a purpose-specific Git hosting for
BaseALT
projects. Thank you for your understanding!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
Merge series from Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>:
These are cleanup patches for soc-dapm.c.
Each patches are not related, very random cleanup.
Current snd_soc_dapm_new_control_unlocked() error handling is wrong.
It is using "goto request_failed" (A), but error message is using
"w->name" (B) which is not yet created in such timing.
snd_soc_dapm_new_control_unlocked(xxx)
{
...
switch (w->id) {
case xxx:
...
if (IS_ERR(...)) {
ret = PTR_ERR(...);
(A) goto request_failed;
}
...
}
prefix = soc_dapm_prefix(...);
if (prefix)
(B) w->name = kasprintf(...);
else
(B) w->name = kstrdup_const(...);
...
(A) request_failed:
if (ret != -EPROBE_DEFER)
(B) dev_err(..., w->name, ...);
return ...;
}
we can create "w->name" at beginning of this function.
In such case, we need to call kfree_const(w->name) at error case.
This patch do these.
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Link: https://lore.kernel.org/r/87wnah8l7e.wl-kuninori.morimoto.gx@renesas.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Current snd_soc_dai_link_event_pre_pmu() is checking "config".
It is using dev_err() (A) if it was NULL, so we don't need to use
WARN_ON() (B) to check it, it is over-kill. This patch removes it.
(B) if (WARN_ON(!config)) {
(A) dev_err(...);
...
}
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Link: https://lore.kernel.org/r/87zgfd8l7s.wl-kuninori.morimoto.gx@renesas.com
Signed-off-by: Mark Brown <broonie@kernel.org>
This patch switches the driver away from legacy gpio/of_gpio API to
gpiod API, and removes use of of_get_named_gpio_flags() which I want to
make private to gpiolib.
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Link: https://lore.kernel.org/r/YxeaITtlJexygQo9@google.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Support devicetree by adding a snd_soc_of_mach array, specifying SOF
topologies for a generic MT8195 machine and for Google Tomato
Chromebooks.
Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Link: https://lore.kernel.org/r/20220906092727.37324-6-angelogioacchino.delregno@collabora.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Add the .mailbox_{read,write} generic callbacks for SOF IPC and, while
at it, also change the ipc_msg_data callback to use the SOF API
sof_ipc_msg_data() instead of the custom function mt8195_ipc_msg_data().
Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Link: https://lore.kernel.org/r/20220906092727.37324-4-angelogioacchino.delregno@collabora.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Here we're using function mtk_adsp_dump() from mtk-adsp-common:
explicitly import its namespace.
Fixes: 3a054f90e955 ("ASoC: SOF: mediatek: Add mt8195 debug dump")
Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Link: https://lore.kernel.org/r/20220906092727.37324-3-angelogioacchino.delregno@collabora.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Adding a probe callback on this snd_soc_card is required when
Sound Open Firmware support is desired, as we need to appropriately
populate the stream_name for SOF to be able to bind widgets.
Failing to do so will produce errors when applying the SOF topology
leading to card registration failure (so, no sound).
While at it, also make sure to fill the topology_shortname as required.
Fixes: 0caf1120c583 ("ASoC: mediatek: mt8195: extract SOF common code")
Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Link: https://lore.kernel.org/r/20220906092727.37324-2-angelogioacchino.delregno@collabora.com
Signed-off-by: Mark Brown <broonie@kernel.org>
The recent commit c11117b634f4 ("ALSA: usb-audio: Refcount multiple
accesses on the single clock") tries to manage the clock rate shared
by several endpoints. This was intended for avoiding the unmatched
rate by a different endpoint, but unfortunately, it introduced a
regression for PulseAudio and pipewire, too; those applications try to
probe the multiple possible rates (44.1k and 48kHz) and setting up the
normal rate fails but only the last rate is applied.
The cause is that the last sample rate is still left to the clock
reference even after closing the endpoint, and this value is still
used at the next open. It happens only when applications set up via
PCM prepare but don't start/stop the stream; the rate is reset when
the stream is stopped, but it's not cleared at close.
This patch addresses the issue above, simply by clearing the rate set
in the clock reference at the last close of each endpoint.
Fixes: c11117b634f4 ("ALSA: usb-audio: Refcount multiple accesses on the single clock")
Reported-by: Jason A. Donenfeld <Jason@zx2c4.com>
Tested-by: Jason A. Donenfeld <Jason@zx2c4.com>
Cc: <stable@vger.kernel.org>
Link: https://lore.kernel.org/all/YxXIWv8dYmg1tnXP@zx2c4.com/
Link: https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/2620
Link: https://lore.kernel.org/r/20220907100421.6443-1-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
The voice allocator sometimes begins allocating from near the end of the
array and then wraps around, however snd_emu10k1_pcm_channel_alloc()
accesses the newly allocated voices as if it never wrapped around.
This results in out of bounds access if the first voice has a high enough
index so that first_voice + requested_voice_count > NUM_G (64).
The more voices are requested, the more likely it is for this to occur.
This was initially discovered using PipeWire, however it can be reproduced
by calling aplay multiple times with 16 channels:
aplay -r 48000 -D plughw:CARD=Live,DEV=3 -c 16 /dev/zero
UBSAN: array-index-out-of-bounds in sound/pci/emu10k1/emupcm.c:127:40
index 65 is out of range for type 'snd_emu10k1_voice [64]'
CPU: 1 PID: 31977 Comm: aplay Tainted: G W IOE 6.0.0-rc2-emu10k1+ #7
Hardware name: ASUSTEK COMPUTER INC P5W DH Deluxe/P5W DH Deluxe, BIOS 3002 07/22/2010
Call Trace:
<TASK>
dump_stack_lvl+0x49/0x63
dump_stack+0x10/0x16
ubsan_epilogue+0x9/0x3f
__ubsan_handle_out_of_bounds.cold+0x44/0x49
snd_emu10k1_playback_hw_params+0x3bc/0x420 [snd_emu10k1]
snd_pcm_hw_params+0x29f/0x600 [snd_pcm]
snd_pcm_common_ioctl+0x188/0x1410 [snd_pcm]
? exit_to_user_mode_prepare+0x35/0x170
? do_syscall_64+0x69/0x90
? syscall_exit_to_user_mode+0x26/0x50
? do_syscall_64+0x69/0x90
? exit_to_user_mode_prepare+0x35/0x170
snd_pcm_ioctl+0x27/0x40 [snd_pcm]
__x64_sys_ioctl+0x95/0xd0
do_syscall_64+0x5c/0x90
? do_syscall_64+0x69/0x90
? do_syscall_64+0x69/0x90
entry_SYSCALL_64_after_hwframe+0x63/0xcd
Signed-off-by: Tasos Sahanidis <tasos@tasossah.com>
Cc: <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/3707dcab-320a-62ff-63c0-73fc201ef756@tasossah.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
The last fix for trying to recover the regression on AMD platforms,
unfortunately, leaded to yet another regression: it turned out that
IOMMUs don't like the usage of raw page allocations.
This is yet another attempt for addressing the log saga; at this time,
we re-use the existing buffer allocation mechanism with SG-pages
although we require only single pages. The SG buffer allocation
itself was confirmed to work for stream buffers, so it's relatively
easy to adapt for other places.
The only problem is: although the HD-audio code is accessing the
address directly via dmab->address field, SG-pages don't set up it.
For the ease of adaption, we now set up the dmab->addr field from the
address of the first page as default, so that it can run with the
HD-audio driver code as-is without the excessive call of
snd_sgbuf_get_addr() multiple times; that's the only change in the
memalloc helper side. The rest is nothing but a flip of the dma_type
field in the HD-audio side.
Fixes: a8d302a0b770 ("ALSA: memalloc: Revive x86-specific WC page allocations again")
Reported-by: Mikhail Gavrilov <mikhail.v.gavrilov@gmail.com>
Tested-by: Mikhail Gavrilov <mikhail.v.gavrilov@gmail.com>
Cc: <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/CABXGCsO+kB2t5QyHY-rUe76npr1m0-5JOtt8g8SiHUo34ur7Ww@mail.gmail.com
Link: https://bugzilla.kernel.org/show_bug.cgi?id=216112
Link: https://bugzilla.kernel.org/show_bug.cgi?id=216363
Link: https://lore.kernel.org/r/20220906090319.23358-1-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
There may be a bad USB audio device with a USB ID of (0x04fa, 0x4201) and
the number of it's interfaces less than 4, an out-of-bounds read bug occurs
when parsing the interface descriptor for this device.
Fix this by checking the number of interfaces.
Signed-off-by: Dongxiang Ke <kdx.glider@gmail.com>
Link: https://lore.kernel.org/r/20220906024928.10951-1-kdx.glider@gmail.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
AZA HW may send a burst read/write request crossing 4K memory boundary.
The 4KB boundary is not guaranteed by Tegra HDA HW. Make SW change to
include the flag AZX_DCAPS_4K_BDLE_BOUNDARY to align BDLE to 4K
boundary.
Signed-off-by: Mohan Kumar <mkumard@nvidia.com>
Link: https://lore.kernel.org/r/20220905172420.3801-1-mkumard@nvidia.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Merge series from Cezary Rojewski <cezary.rojewski@intel.com>:
Continuation of recent upstream discussion [1] regarding user string
tokenization.
First, parse_int_array_user() is introduced to allow for splitting
specified user string into a sequence of integers. Makes use of
get_options() internally so the parsing logic is not duplicated.
With that done, redundant parts of the sound driver are removed.
Originally similar functionality was added for the SOF sound driver. As
more users are on the horizon, it is desirable to update existing
string_helpers code and provide a unified solution.
Make use of global integer-array parsing helper instead of the internal
one as both serve same purpose. With that, both strsplit_u32() and
tokenize_input() become unused so remove them.
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Signed-off-by: Cezary Rojewski <cezary.rojewski@intel.com>
Link: https://lore.kernel.org/r/20220904102840.862395-3-cezary.rojewski@intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
The newly added stac_check_power_status() caused a compile warning
when CONFIG_SND_HDA_INPUT_BEEP is disabled. Fix it.
Fixes: 414d38ba8710 ("ALSA: hda/sigmatel: Keep power up while beep is enabled")
Reported-by: kernel test robot <lkp@intel.com>
Link: https://lore.kernel.org/r/20220905130630.2845-1-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
There is a small race window at snd_pcm_oss_sync() that is called from
OSS PCM SNDCTL_DSP_SYNC ioctl; namely the function calls
snd_pcm_oss_make_ready() at first, then takes the params_lock mutex
for the rest. When the stream is set up again by another thread
between them, it leads to inconsistency, and may result in unexpected
results such as NULL dereference of OSS buffer as a fuzzer spotted
recently.
The fix is simply to cover snd_pcm_oss_make_ready() call into the same
params_lock mutex with snd_pcm_oss_make_ready_locked() variant.
Reported-and-tested-by: butt3rflyh4ck <butterflyhuangxx@gmail.com>
Reviewed-by: Jaroslav Kysela <perex@perex.cz>
Cc: <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/CAFcO6XN7JDM4xSXGhtusQfS2mSBcx50VJKwQpCq=WeLt57aaZA@mail.gmail.com
Link: https://lore.kernel.org/r/20220905060714.22549-1-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Move the requesting of DMA channels further down from 'probe' to
'pcm_new'. This is to spare the allocated DMA channel resources as we
typically only ever use one or two of the clusters for PCM streaming.
Before we would request DMA channels for all clusters.
(This is prompted by a change in the Audio DMA Controller driver, which
will now be allocating cache SRAM to channels.)
Signed-off-by: Martin Povišer <povik+lin@cutebit.org>
Link: https://lore.kernel.org/r/20220905074030.1293-1-povik+lin@cutebit.org
Signed-off-by: Mark Brown <broonie@kernel.org>
From current design in sof_machine_check the SOF can only support
ACPI type machine.
In sof_machine_check if there is no ACPI machine exist, the function
will return -ENODEV directly, that's we don't expected if we do not
base on ACPI machine.
So we add a new function named sof_of_machine_select that we can pass
sof_machine_check and obtain info required by snd_sof_new_platform_drv.
Signed-off-by: Chunxu Li <chunxu.li@mediatek.com>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Link: https://lore.kernel.org/r/20220903032151.13664-1-chunxu.li@mediatek.com
Signed-off-by: Mark Brown <broonie@kernel.org>
The tracing capabilities for the speaker protection fw enabled via
commit c55b3e46cb99 ("ASoC: wm_adsp: Add trace caps to speaker
protection FW") are not be available on all platforms, such as the
Valve's Steam Deck which is based on the Halo Core DSP.
As a consequence, whenever the firmware is loaded, a rather misleading
'Failed to parse legacy: -19' error message is written to the kernel
ring buffer:
[ 288.977412] steamdeck kernel: cs35l41 spi-VLV1776:01: DSP1: Firmware version: 3
[ 288.978002] steamdeck kernel: cs35l41 spi-VLV1776:01: DSP1: cs35l41-dsp1-spk-prot.wmfw: Fri 02 Apr 2021 21:03:50 W. Europe Daylight Time
[ 289.094065] steamdeck kernel: cs35l41 spi-VLV1776:01: DSP1: Firmware: 400a4 vendor: 0x2 v0.33.0, 2 algorithms
[ 289.095073] steamdeck kernel: cs35l41 spi-VLV1776:01: DSP1: 0: ID cd v29.53.0 XM@94 YM@e
[ 289.095665] steamdeck kernel: cs35l41 spi-VLV1776:01: DSP1: 1: ID f20b v0.0.1 XM@170 YM@0
[ 289.096275] steamdeck kernel: cs35l41 spi-VLV1776:01: DSP1: Protection: C:\Users\ocanavan\Desktop\cirrusTune_july2021.bin
[ 291.172383] steamdeck kernel: cs35l41 spi-VLV1776:01: DSP1: Failed to parse legacy: -19
Update wm_adsp_buffer_init() to print a more descriptive info message
when wm_adsp_buffer_parse_legacy() returns -ENODEV.
Fixes: c55b3e46cb99 ("ASoC: wm_adsp: Add trace caps to speaker protection FW")
Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
Acked-by: Charles Keepax <ckeepax@opensource.cirrus.com>
Link: https://lore.kernel.org/r/20220825220530.1205141-1-cristian.ciocaltea@collabora.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Because the PWR_CTRL field is modeled as the power state of the DAC
widget, and at the same time it is used to implement mute/unmute, we
need some additional book-keeping to have the right end result no matter
the sequence of calls. Without this fix, one permanently mutes an
ongoing stream by toggling the associated speaker pin control.
(This mirrors commit 1e5907bcb3a3 ("ASoC: tas2770: Fix handling of
mute/unmute") which was a fix to the tas2770 driver.)
Signed-off-by: Martin Povišer <povik+lin@cutebit.org>
Link: https://lore.kernel.org/r/20220825142226.80929-3-povik+lin@cutebit.org
Signed-off-by: Mark Brown <broonie@kernel.org>
The driver is setting the PWR_CTRL field in both the set_bias_level
callback and on DAPM events of the DAC widget (and also in the
mute_stream method). Drop the set_bias_level callback altogether as the
power setting it does is in conflict with the other code paths.
(This mirrors commit c8a6ae3fe1c8 ("ASoC: tas2770: Drop conflicting
set_bias_level power setting") which was a fix to the tas2770 driver.)
Signed-off-by: Martin Povišer <povik+lin@cutebit.org>
Link: https://lore.kernel.org/r/20220825142226.80929-2-povik+lin@cutebit.org
Signed-off-by: Mark Brown <broonie@kernel.org>
Current dpcm_add_paths() is checking fe condition in loop (= A),
but fe condition (X) is not related to the loop (B).
(X) static int dpcm_add_paths(fe, stream, ...)
{
...
(B) for_each_dapm_widgets(list, i, widget) {
...
(A) if (!fe->dpcm[stream].runtime && !fe->fe_compr)
continue;
...
}
...
}
This patch checks fe condition at out of loop
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Link: https://lore.kernel.org/r/87pmgi4dz4.wl-kuninori.morimoto.gx@renesas.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Current soc-pcm.c has many similar code for error case.
This patch adds soc_pcm_ret() and share the code and error message.
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Link: https://lore.kernel.org/r/87r10y4dzb.wl-kuninori.morimoto.gx@renesas.com
Signed-off-by: Mark Brown <broonie@kernel.org>
commit 4bf2e385aa59c2fae ("ASoC: core: Init pcm runtime work early to
avoid warnings") has added generic close_delayed_work() which checks
close_delayed_work_func
static void close_delayed_work(...) {
...
=> if (rtd->close_delayed_work_func)
rtd->close_delayed_work_func(rtd);
}
So, we don't need to have NULL function for Codec2Codec.
=> static void codec2codec_close_delayed_work()
{
/*
* Currently nothing to do for c2c links
* Since c2c links are internal nodes in the DAPM graph and
* don't interface with the outside world or application layer
* we don't have to do any special handling on close.
*/
}
int soc_new_pcm(...)
{
...
if (rtd->dai_link->params)
=> rtd->close_delayed_work_func = codec2codec_close_delayed_work;
else
rtd->close_delayed_work_func = snd_soc_close_delayed_work;
...
}
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Link: https://lore.kernel.org/r/87sfle4dzk.wl-kuninori.morimoto.gx@renesas.com
Signed-off-by: Mark Brown <broonie@kernel.org>
As rsnd_mod_power_on() can return negative numbers,
it should be better to check the return value and
deal with the exception.
Fixes: e7d850dd10f4 ("ASoC: rsnd: use mod base common method on SSI-parent")
Signed-off-by: Jiasheng Jiang <jiasheng@iscas.ac.cn>
Acked-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Link: https://lore.kernel.org/r/20220902013030.3691266-1-jiasheng@iscas.ac.cn
Signed-off-by: Mark Brown <broonie@kernel.org>
In loopback_jiffies_timer_pos_update(), we are getting jiffies twice.
First time for playback, second time for capture. Jiffies can be updated
between these two calls and if the capture jiffies is larger, extra zeros
will be filled in the capture buffer.
Change to get jiffies once and use it for both playback and capture.
Signed-off-by: Pattara Teerapong <pteerapong@chromium.org>
Cc: <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/20220901144036.4049060-1-pteerapong@chromium.org
Signed-off-by: Takashi Iwai <tiwai@suse.de>
One of the former changes for the endpoint management was the more
consistent setup of endpoints at hw_params.
snd_usb_endpoint_configure() is a single function that does the full
setup, and it's called from both PCM hw_params and prepare callbacks.
Although the EP setup at the prepare phase is usually skipped (by
checking need_setup flag), it may be still effective in some cases
like suspend/resume that requires the interface setup again.
As it's a full and single setup, the invocation of
snd_usb_endpoint_configure() includes not only the USB interface setup
but also the buffer release and allocation. OTOH, doing the buffer
release and re-allocation at PCM prepare phase is rather superfluous,
and better to be done only in the hw_params phase.
For those optimizations, this patch splits the endpoint setup to two
phases: snd_usb_endpoint_set_params() and snd_usb_endpoint_prepare(),
to be called from hw_params and from prepare, respectively.
Note that this patch changes the driver operation slightly,
effectively moving the USB interface setup again to PCM prepare stage
instead of hw_params stage, while the buffer allocation and such
initializations are still done at hw_params stage.
And, the change of the USB interface setup timing (moving to prepare)
gave an interesting "fix", too: it was reported that the recent
kernels caused silent output at the beginning on playbacks on some
devices on Android, and this change casually fixed the regression.
It seems that those devices are picky about the sample rate change (or
the interface change?), and don't follow the too immediate rate
changes.
Meanwhile, Android operates the PCM in the following order:
- open, then hw_params with the possibly highest sample rate
- close without prepare
- re-open, hw_params with the normal sample rate
- prepare, and start streaming
This procedure ended up the hw_params twice with different rates, and
because the recent kernel did set up the sample rate twice one and
after, it screwed up the device. OTOH, the earlier kernels didn't set
up the USB interface at hw_params, hence this problem didn't appear.
Now, with this patch, the USB interface setup is again back to the
prepare phase, and it works around the problem automagically.
Although we should address the sample rate problem in a more solid
way in future, let's keep things working as before for now.
Fixes: bf6313a0ff76 ("ALSA: usb-audio: Refactor endpoint management")
Cc: <stable@vger.kernel.org>
Reported-by: chihhao chen <chihhao.chen@mediatek.com>
Link: https://lore.kernel.org/r/87e6d6ae69d68dc588ac9acc8c0f24d6188375c3.camel@mediatek.com
Link: https://lore.kernel.org/r/20220901124136.4984-1-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
The MCA driver selects COMMON_CLK, which leads to misconfiguration
on platforms with HAVE_LEGACY_CLK (under compile test). Kconfig catches
the conflict with the following warning:
WARNING: unmet direct dependencies detected for COMMON_CLK
Depends on [n]: !HAVE_LEGACY_CLK [=y]
Selected by [m]:
- SND_SOC_APPLE_MCA [=m] && SOUND [=m] && !UML && SND [=m] &&
SND_SOC [=m] && (ARCH_APPLE || COMPILE_TEST [=y])
Eventually the build fails with errors like:
>> drivers/clk/clk.c:867:6: error: redefinition of 'clk_unprepare'
867 | void clk_unprepare(struct clk *clk)
| ^~~~~~~~~~~~~
In file included from drivers/clk/clk.c:9:
include/linux/clk.h:303:20: note: previous definition of 'clk_unprepare' with type 'void(struct clk *)'
303 | static inline void clk_unprepare(struct clk *clk)
| ^~~~~~~~~~~~~
which appears to be because COMMON_CLK is selected but HAVE_CLK_PREPARE
is not. In the end it seems we had no business selecting COMMON_CLK from
an unrelated driver like that, so remove the selection. The linux/clk.h
API is there anyway.
Fixes: 3df5d0d97289 ("ASoC: apple: mca: Start new platform driver")
Reported-by: kernel test robot <lkp@intel.com>
Signed-off-by: Martin Povišer <povik+lin@cutebit.org>
Link: https://lore.kernel.org/r/20220901113415.27449-1-povik+lin@cutebit.org
Signed-off-by: Mark Brown <broonie@kernel.org>
The WCD934X codec is a Slimbus driver, so it must depend on SLIMBUS,
also for compile tests:
ERROR: modpost: "slim_stream_prepare" [sound/soc/codecs/snd-soc-wcd934x.ko] undefined!
Reported-by: kernel test robot <lkp@intel.com>
Fixes: 5b7f4e5de61b ("ASoC: codecs: allow compile testing without MFD drivers")
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Link: https://lore.kernel.org/r/20220901101458.365354-1-krzysztof.kozlowski@linaro.org
Signed-off-by: Mark Brown <broonie@kernel.org>
When the delayed registration is specified via either delayed_register
option or the quirk, we delay the invocation of snd_card_register()
until the given interface. But if a wrong value has been set there
and there are more interfaces over the given interface number,
snd_card_register() call would be missing for those interfaces.
This patch catches up those missing calls by fixing the comparison of
the interface number. Now the call is skipped only if the processed
interface is less than the given interface, instead of the exact
match.
Fixes: b70038ef4fea ("ALSA: usb-audio: Add delayed_register option")
Link: https://bugzilla.kernel.org/show_bug.cgi?id=216082
Link: https://lore.kernel.org/r/20220831125901.4660-2-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
The info message that was added in the commit a4aad5636c72 ("ALSA:
usb-audio: Inform devices that need delayed registration") is actually
useful to know the need for the delayed registration. However, it
turned out that this doesn't catch the all cases; namely, this warned
only when a PCM stream is attached onto the existing PCM instance, but
it doesn't count for a newly created PCM instance. This made
confusion as if there were no further delayed registration.
This patch moves the check to the code path for either adding a stream
or creating a PCM instance. Also, make it simpler by checking the
card->registered flag instead of querying each snd_device state.
Fixes: a4aad5636c72 ("ALSA: usb-audio: Inform devices that need delayed registration")
Link: https://bugzilla.kernel.org/show_bug.cgi?id=216082
Link: https://lore.kernel.org/r/20220831125901.4660-1-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Merge series from Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>:
Small number of cleanups that were either missed in previous versions
or detected by new cppcheck version.
Merge series from Laurentiu Mihalcea <laurentiu.mihalcea@nxp.com>:
The purpose of this patch series is to add support for
timestamping on capture direction using the compress
API.
This is simply done by splitting sof_compr_copy into 2
functions: sof_compr_copy_playback and sof_compr_copy_capture.
Each of these functions handles one of the possible directions:
capture or playback and is called in sof_compr_copy based on
the stream's direction.
The only difference between sof_compr_copy_playback and
sof_compr_copy_capture is the fact that on playback case
we need to copy data from user space and on capture we
need to copy data to user space.
sound/soc/ti/omap-mcbsp.c:617:10: style: Variable 'ret' is assigned a
value that is never used. [unreadVariable]
int ret = 0;
^
Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Reviewed-by: Bard Liao <yung-chuan.liao@linux.intel.com>
Reviewed-by: Kai Vehmanen <kai.vehmanen@linux.intel.com>
Reviewed-by: Chao Song <chao.song@intel.com>
Link: https://lore.kernel.org/r/20220822184239.169757-6-pierre-louis.bossart@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
cppcheck warning:
sound/soc/fsl/fsl_utils.c:127:10: style: Variable 'ret' is assigned a
value that is never used. [unreadVariable]
int ret = 0;
^
Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Reviewed-by: Bard Liao <yung-chuan.liao@linux.intel.com>
Reviewed-by: Kai Vehmanen <kai.vehmanen@linux.intel.com>
Reviewed-by: Chao Song <chao.song@intel.com>
Acked-by: Shengjiu Wang <shengjiu.wang@gmail.com>
Link: https://lore.kernel.org/r/20220822184239.169757-5-pierre-louis.bossart@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
cppcheck warning:
sound/soc/codecs/hdmi-codec.c:24:16: style: struct member
'hdmi_codec_channel_ma`p_table::map' is never used. [unusedStructMember]
unsigned char map; /* ALSA API channel map position */
^
Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Reviewed-by: Bard Liao <yung-chuan.liao@linux.intel.com>
Reviewed-by: Kai Vehmanen <kai.vehmanen@linux.intel.com>
Reviewed-by: Chao Song <chao.song@intel.com>
Link: https://lore.kernel.org/r/20220822184239.169757-2-pierre-louis.bossart@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Added a new copy function used to copy data to user buffer
in the case of compress capture.
Reviewed-by: Paul Olaru <paul.olaru@nxp.com>
Reviewed-by: Daniel Baluta <daniel.baluta@nxp.com>
Signed-off-by: Laurentiu Mihalcea <laurentiu.mihalcea@nxp.com>
Link: https://lore.kernel.org/r/20220822101502.17644-3-laurentiu.mihalcea@nxp.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Since we're preparing to add support for compress capture,
we need to move the content of sof_compr_copy into a
separate function which handles the playback direction just
like the initial sof_compr_copy.
Reviewed-by: Paul Olaru <paul.olaru@nxp.com>
Reviewed-by: Daniel Baluta <daniel.baluta@nxp.com>
Signed-off-by: Laurentiu Mihalcea <laurentiu.mihalcea@nxp.com>
Link: https://lore.kernel.org/r/20220822101502.17644-2-laurentiu.mihalcea@nxp.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Merge series from Syed Saba Kareem <Syed.SabaKareem@amd.com>:
Pink Sardine platform is new APU series based on acp6.2 design.
This patch set adds an ASoC driver for the ACP (Audio CoProcessor) block
on AMD Pink Sardine APU with DMIC endpoint support.
