[ Upstream commit e8343410ddf08fc36a9b9cc7c51a4e53a262d4c6 ]
Sometimes the stream may be stopped due to XRUN events, in which case
the userspace can call snd_pcm_drop() and snd_pcm_prepare() to stop and
start the stream again.
In these cases, we must wait for the DMA channel to synchronize before
marking the stream as prepared for playback, as the DMA channel gets
stopped by drop() without any synchronization. Make sure the ALSA core
synchronizes the DMA channel by adding a sync_stop() hook.
Reviewed-by: Peter Ujfalusi <peter.ujfalusi@gmail.com>
Signed-off-by: Jai Luthra <j-luthra@ti.com>
Link: https://lore.kernel.org/r/20240611-asoc_next-v3-1-fcfd84b12164@ti.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit 644eebdbbf1154c995d6319c133d7d5b898c5ed2 ]
Intel machine drivers are used by parent platform drivers based on
closed-source firmware (Atom/SST and catpt) and SOF-based ones.
In some cases for ACPI-based platforms, the behavior of machine
drivers needs to be modified depending on the parent type, typically
for card names and power management.
An initial solution based on passing a boolean flag as a platform
device parameter was tested earlier. Since it looked overkill, this
patch suggests instead a simple string comparison to identify an SOF
parent device/driver.
Suggested-by: Kai Vehmanen <kai.vehmanen@linux.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: Rander Wang <rander.wang@linux.intel.com>
Reviewed-by: Guennadi Liakhovetski <guennadi.liakhovetski@linux.intel.com>
Link: https://lore.kernel.org/r/20201112223825.39765-5-pierre-louis.bossart@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Stable-dep-of: 0cb3b7fd530b ("ASoC: Intel: Disable route checks for Skylake boards")
Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit 47f56e38a199bd45514b8e0142399cba4feeaf1a ]
Add members to struct snd_soc_card to store the PCI subsystem ID (SSID)
of the soundcard.
The PCI specification provides two registers to store a vendor-specific
SSID that can be read by drivers to uniquely identify a particular
"soundcard". This is defined in the PCI specification to distinguish
products that use the same silicon (and therefore have the same silicon
ID) so that product-specific differences can be applied.
PCI only defines 0xFFFF as an invalid value. 0x0000 is not defined as
invalid. So the usual pattern of zero-filling the struct and then
assuming a zero value unset will not work. A flag is included to
indicate when the SSID information has been filled in.
Unlike DMI information, which has a free-format entirely up to the vendor,
the PCI SSID has a strictly defined format and a registry of vendor IDs.
It is usual in Windows drivers that the SSID is used as the sole identifier
of the specific end-product and the Windows driver contains tables mapping
that to information about the hardware setup, rather than using ACPI
properties.
This SSID is important information for ASoC components that need to apply
hardware-specific configuration on PCI-based systems.
As the SSID is a generic part of the PCI specification and is treated as
identifying the "soundcard", it is reasonable to include this information
in struct snd_soc_card, instead of components inventing their own custom
ways to pass this information around.
Signed-off-by: Richard Fitzgerald <rf@opensource.cirrus.com>
Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Link: https://lore.kernel.org/r/20230912163207.3498161-2-rf@opensource.cirrus.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit e123036be377ddf628226a7c6d4f9af5efd113d3 ]
In the BE hw_params configuration, the existing code checks if any of the
existing FEs are prepared, running, paused or suspended - and skips the
configuration in those cases. This allows multiple calls of hw_params
which the ALSA state machine supports.
This check is not handled for the prepare stage, which can lead to the
same BE being prepared multiple times. This patch adds a check similar to
that of the hw_params, with the main difference being that the suspended
state is allowed: the ALSA state machine allows a transition from
suspended to prepared with hw_params skipped.
This problem was detected on Intel IPC4/SoundWire devices, where the BE
dailink .prepare stage is used to configure the SoundWire stream with a
bank switch. Multiple .prepare calls lead to conflicts with the .trigger
operation with IPC4 configurations. This problem was not detected earlier
on Intel devices, HDaudio BE dailinks detect that the link is already
prepared and skip the configuration, and for IPC3 devices there is no BE
trigger.
Link: https://github.com/thesofproject/sof/issues/7596
Signed-off-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com
Signed-off-by: Bard Liao <yung-chuan.liao@linux.intel.com
Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com
Link: https://lore.kernel.org/r/20230517185731.487124-1-pierre-louis.bossart@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org
Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit fdff966bfde7cf0c85562d2bfb1ff1ba83da5f7b ]
Add struct snd_pcm_substream forward declaration
Fixes: 078a85f280 ("ASoC: dapm: Only power up active channels from a DAI")
Signed-off-by: Lucas Tanure <lucas.tanure@collabora.com>
Reviewed-by: Charles Keepax <ckeepax@opensource.cirrus.com>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Link: https://lore.kernel.org/r/20230215132851.1626881-1-lucas.tanure@collabora.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit e8444560b4d9302a511f0996f4cfdf85b628f4ca upstream.
The HDAudio ASoC support relies on the set_tdm_slots() helper to store
the HDaudio stream tag in the tx_mask. This only works because of the
pre-existing order in soc-pcm.c, where the hw_params() is handled for
codec_dais *before* cpu_dais. When the order is reversed, the
stream_tag is used as a mask in the codec fixup functions:
/* fixup params based on TDM slot masks */
if (substream->stream == SNDRV_PCM_STREAM_PLAYBACK &&
codec_dai->tx_mask)
soc_pcm_codec_params_fixup(&codec_params,
codec_dai->tx_mask);
As a result of this confusion, the codec_params_fixup() ends-up
generating bad channel masks, depending on what stream_tag was
allocated.
We could add a flag to state that the tx_mask is really not a mask,
but it would be quite ugly to persist in overloading concepts.
Instead, this patch suggests a more generic get/set 'stream' API based
on the existing model for SoundWire. We can expand the concept to
store 'stream' opaque information that is specific to different DAI
types. In the case of HDAudio DAIs, we only need to store a stream tag
as an unsigned char pointer. The TDM rx_ and tx_masks should really
only be used to store masks.
Rename get_sdw_stream/set_sdw_stream callbacks and helpers as
get_stream/set_stream. No functionality change beyond the rename.
Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Reviewed-by: Rander Wang <rander.wang@intel.com>
Reviewed-by: Ranjani Sridharan <ranjani.sridharan@intel.com>
Signed-off-by: Bard Liao <yung-chuan.liao@linux.intel.com>
Acked-By: Vinod Koul <vkoul@kernel.org>
Link: https://lore.kernel.org/r/20211224021034.26635-5-yung-chuan.liao@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Cc: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
[ Upstream commit 12054f0ce8be7d2003ec068ab27c9eb608397b98 ]
snd_hdac_ext_stop_streams() has really nothing to do with the
extension, it just loops over the bus streams.
Move it to the hdac_stream layer and rename to remove the 'ext'
prefix and add the precision that the chip will also be stopped.
Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Reviewed-by: Kai Vehmanen <kai.vehmanen@intel.com>
Reviewed-by: Péter Ujfalusi <peter.ujfalusi@linux.intel.com>
Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com>
Reviewed-by: Cezary Rojewski <cezary.rojewski@intel.com>
Link: https://lore.kernel.org/r/20211216231128.344321-2-pierre-louis.bossart@linux.intel.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Stable-dep-of: 171107237246 ("ASoC: Intel: Skylake: Fix driver hang during shutdown")
Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit b5172e62458f8e6ff359e5f096044a488db90ac5 ]
Shifting signed 32-bit value by 31 bits is undefined, so changing
significant bit to unsigned. The UBSAN warning calltrace like below:
UBSAN: shift-out-of-bounds in sound/core/pcm_native.c:2676:21
left shift of 1 by 31 places cannot be represented in type 'int'
...
Call Trace:
<TASK>
dump_stack_lvl+0x8d/0xcf
ubsan_epilogue+0xa/0x44
__ubsan_handle_shift_out_of_bounds+0x1e7/0x208
snd_pcm_open_substream+0x9f0/0xa90
snd_pcm_oss_open.part.26+0x313/0x670
snd_pcm_oss_open+0x30/0x40
soundcore_open+0x18b/0x2e0
chrdev_open+0xe2/0x270
do_dentry_open+0x2f7/0x620
path_openat+0xd66/0xe70
do_filp_open+0xe3/0x170
do_sys_openat2+0x357/0x4a0
do_sys_open+0x87/0xd0
do_syscall_64+0x34/0x80
Fixes: 1da177e4c3 ("Linux-2.6.12-rc2")
Signed-off-by: Baisong Zhong <zhongbaisong@huawei.com>
Link: https://lore.kernel.org/r/20221121110044.3115686-1-zhongbaisong@huawei.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit 4a971e84a7ae10a38d875cd2d4e487c8d1682ca3 ]
For avoiding the potential deadlock via kill_fasync() call, use the
new fasync helpers to defer the invocation from the control API. Note
that it's merely a workaround.
Another note: although we haven't received reports about the deadlock
with the control API, the deadlock is still potentially possible, and
it's better to align the behavior with other core APIs (PCM and
timer); so let's move altogether.
Link: https://lore.kernel.org/r/20220728125945.29533-5-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit ef34a0ae7a2654bc9e58675e36898217fb2799d8 ]
Currently the call of kill_fasync() from an interrupt handler might
lead to potential spin deadlocks, as spotted by syzkaller.
Unfortunately, it's not so trivial to fix this lock chain as it's
involved with the tasklist_lock that is touched in allover places.
As a temporary workaround, this patch provides the way to defer the
async signal notification in a work. The new helper functions,
snd_fasync_helper() and snd_kill_faync() are replacements for
fasync_helper() and kill_fasync(), respectively. In addition,
snd_fasync_free() needs to be called at the destructor of the relevant
file object.
Link: https://lore.kernel.org/r/20220728125945.29533-2-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit 1b6a6fc5280e97559287b61eade2d4b363e836f2 ]
It is possible when using ASoC that input_dev is unregistered while
calling snd_jack_report, which causes NULL pointer dereference.
In order to prevent this serialize access to input_dev using mutex lock.
Signed-off-by: Amadeusz Sławiński <amadeuszx.slawinski@linux.intel.com>
Reviewed-by: Cezary Rojewski <cezary.rojewski@intel.com>
Link: https://lore.kernel.org/r/20220412091628.3056922-1-amadeuszx.slawinski@linux.intel.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit bc55cfd5718c7c23e5524582e9fa70b4d10f2433 upstream.
syzbot caught a potential deadlock between the PCM
runtime->buffer_mutex and the mm->mmap_lock. It was brought by the
recent fix to cover the racy read/write and other ioctls, and in that
commit, I overlooked a (hopefully only) corner case that may take the
revert lock, namely, the OSS mmap. The OSS mmap operation
exceptionally allows to re-configure the parameters inside the OSS
mmap syscall, where mm->mmap_mutex is already held. Meanwhile, the
copy_from/to_user calls at read/write operations also take the
mm->mmap_lock internally, hence it may lead to a AB/BA deadlock.
A similar problem was already seen in the past and we fixed it with a
refcount (in commit b248371628). The former fix covered only the
call paths with OSS read/write and OSS ioctls, while we need to cover
the concurrent access via both ALSA and OSS APIs now.
This patch addresses the problem above by replacing the buffer_mutex
lock in the read/write operations with a refcount similar as we've
used for OSS. The new field, runtime->buffer_accessing, keeps the
number of concurrent read/write operations. Unlike the former
buffer_mutex protection, this protects only around the
copy_from/to_user() calls; the other codes are basically protected by
the PCM stream lock. The refcount can be a negative, meaning blocked
by the ioctls. If a negative value is seen, the read/write aborts
with -EBUSY. In the ioctl side, OTOH, they check this refcount, too,
and set to a negative value for blocking unless it's already being
accessed.
Reported-by: syzbot+6e5c88838328e99c7e1c@syzkaller.appspotmail.com
Fixes: dca947d4d26d ("ALSA: pcm: Fix races among concurrent read/write and buffer changes")
Cc: <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/000000000000381a0d05db622a81@google.com
Link: https://lore.kernel.org/r/20220330120903.4738-1-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 92ee3c60ec9fe64404dc035e7c41277d74aa26cb upstream.
Currently we have neither proper check nor protection against the
concurrent calls of PCM hw_params and hw_free ioctls, which may result
in a UAF. Since the existing PCM stream lock can't be used for
protecting the whole ioctl operations, we need a new mutex to protect
those racy calls.
This patch introduced a new mutex, runtime->buffer_mutex, and applies
it to both hw_params and hw_free ioctl code paths. Along with it, the
both functions are slightly modified (the mmap_count check is moved
into the state-check block) for code simplicity.
Reported-by: Hu Jiahui <kirin.say@gmail.com>
Cc: <stable@vger.kernel.org>
Reviewed-by: Jaroslav Kysela <perex@perex.cz>
Link: https://lore.kernel.org/r/20220322170720.3529-2-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 868ddfcef31ff93ea8961b2e81ea7fe12f6f144b upstream.
The code for hdac_ext_stream seems inherited from hdac_stream, and
similar locking issues are present: the use of the bus->reg_lock
spinlock is inconsistent, with only writes to specific fields being
protected.
Apply similar fix as in hdac_stream by protecting all accesses to
'link_locked' and 'decoupled' fields, with a new helper
snd_hdac_ext_stream_decouple_locked() added to simplify code
changes.
Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Link: https://lore.kernel.org/r/20210924192417.169243-4-pierre-louis.bossart@linux.intel.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
[ Upstream commit c0f1886de7e173865f1a0fa7680a1c07954a987f ]
It seems that a few recent AMD systems show the codec configuration
errors at the early boot, while loading the driver at a later stage
works magically. Although the root cause of the error isn't clear,
it's certainly not bad to allow retrying the codec probe in such a
case if that helps.
This patch adds the capability for retrying the probe upon codec probe
errors on the certain AMD platforms. The probe_work is changed to a
delayed work, and at the secondary call, it'll jump to the codec
probing.
Note that, not only adding the re-probing, this includes the behavior
changes in the codec configuration function. Namely,
snd_hda_codec_configure() won't unregister the codec at errors any
longer. Instead, its caller, azx_codec_configure() unregisters the
codecs with the probe failures *if* any codec has been successfully
configured. If all codec probe failed, it doesn't unregister but let
it re-probed -- which is the most case we're seeing and this patch
tries to improve.
Even if the driver doesn't re-probe or give up, it will go to the
"free-all" error path, hence the leftover codecs shall be disabled /
deleted in anyway.
BugLink: https://bugzilla.suse.com/show_bug.cgi?id=1190801
Link: https://lore.kernel.org/r/20211006141940.2897-1-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit a864e8f159b13babf552aff14a5fbe11abc017e4 ]
Multiple bug reports report issues with the SOF and SST drivers when
dealing with single microphone cases.
We currently read the DMIC array information unconditionally but we
don't check that the configuration type is actually a mic array.
When the DMIC link does not rely on a mic array configuration, the
recommendation is to check the format information to infer the maximum
number of channels, and map this to the number of microphones.
This leaves a potential for a mismatch between actual microphones
available in hardware and what the ACPI table contains, but we have no
other source of information.
Note that single microphone configurations can alternatively be
handled with a 'mic array' configuration along with a 'vendor-defined'
geometry.
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=201251
BugLink: https://github.com/thesofproject/linux/issues/2725
Fixes: 7a33ea70e1 ('ALSA: hda: intel-nhlt: handle NHLT VENDOR_DEFINED DMIC geometry')
Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Reviewed-by: Guennadi Liakhovetski <guennadi.liakhovetski@intel.com>
Reviewed-by: Rander Wang <rander.wang@intel.com>
Reviewed-by: Kai Vehmanen <kai.vehmanen@linux.intel.com>
Link: https://lore.kernel.org/r/20210302000146.1177770-1-pierre-louis.bossart@linux.intel.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Sasha Levin <sashal@kernel.org>
A collection of driver specific fixes, mostly for x86 systems (or CODECs
used mostly on x86) and all for relatively minor issues, the biggest one
being fixing S24_LE format on Keem Bay systems.
-----BEGIN PGP SIGNATURE-----
iQEzBAABCgAdFiEEreZoqmdXGLWf4p/qJNaLcl1Uh9AFAl+2peUACgkQJNaLcl1U
h9COxAf/aq+7DrGjU1umHPD/zfS3ppjmN1hNCHBxqiCm1U9SBbBLGlnDMMcPqFQR
wS8SKdDfhKONA7q7fhGDvvFZd07r9HzIFra+9HVjuc5ouKlPkoETF8uDfXqAdOkM
sXkffe45Wh9DqWIPZOng8ZpKVGW6v3oUCAMrlx53t9LUT9Sd8oQrhsx3nwgr/CUb
SmZiBFF5kWpK8CgG82PuDlCHEnsI4SEatYqHtEMYRBfE0K8fzROye7e7WCKBsb/8
QaDf1RrQ599GXLMVJzbFsXpybBwaaP7LWkKCDHfQbAeKZ6EAWH0agbvUq2X1H2nm
/a3Th5SgL6Vm6KXYvIFGHyTq8rbPLg==
=OkNz
-----END PGP SIGNATURE-----
Merge tag 'asoc-fix-v5.10-rc4' of https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound into for-linus
ASoC: Fixes for v5.11
A collection of driver specific fixes, mostly for x86 systems (or CODECs
used mostly on x86) and all for relatively minor issues, the biggest one
being fixing S24_LE format on Keem Bay systems.
Add delay to fix pop noise from speaker.
Signed-off-by: Jack Yu <jack.yu@realtek.com>
Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Link: https://lore.kernel.org/r/20201105030804.31115-1-jack.yu@realtek.com
Signed-off-by: Mark Brown <broonie@kernel.org>
When building with W=2, there are lots of warnings about the
snd_kcontrol_new name field being an array of 'unsigned char'
but initialized to a string:
include/sound/soc.h:93:48: warning: pointer targets in initialization of 'const unsigned char *' from 'char *' differ in signedness [-Wpointer-sign]
Make it a regular 'char *' to avoid flooding the build log with this.
Fixes: 1da177e4c3 ("Linux-2.6.12-rc2")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Link: https://lore.kernel.org/r/20201026165715.3723704-1-arnd@kernel.org
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Kernel-doc markups should use this format:
identifier - description
There is a common comment marked, instead, with kernel-doc
notation.
Some identifiers have different names between their prototypes
and the kernel-doc markup.
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Acked-by: Mark Brown <broonie@kernel.org>
Link: https://lore.kernel.org/r/535182d6f55d7a7de293dda9676df68f5f60afc6.1603469755.git.mchehab+huawei@kernel.org
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Not a huge amount going on in the core for ASoC this time but quite a
lot of driver activity, especially for the Intel platforms:
- Replacement of the DSP driver for some older x86 systems with a new
one which was written with closer reference to the DSP firmware so
should hopefully be more robust and maintainable.
- A big batch of static checker and other fixes for the rest of the x86
DSP drivers.
- Cleanup of the error unwinding code from Morimoto-san, hopefully
making it more robust.
- Helpers for parsing auxiluary devices from the device tree from
Stephan Gerhold.
- New support for AllWinner A64, Cirrus Logic CS4234, Mediatek MT6359
Microchip S/PDIF TX and RX controllers, Realtek RT1015P, and Texas
Instruments J721E, TAS2110, TAS2564 and TAS2764
-----BEGIN PGP SIGNATURE-----
iQEzBAABCgAdFiEEreZoqmdXGLWf4p/qJNaLcl1Uh9AFAl+EToAACgkQJNaLcl1U
h9AVGwgAghl0dybTqjd1G0i0qOK5AXAdgZaDSstOI++xAd50i0LHlkEMN8/XTcMB
vks1Nt3NIF7E0DAECZ93ZMA3tSJItIuq4RPjFLBbQz7550xIA9G/h1ff9+piltmi
8M2HREH1J2z8HflSW5ZPy9sN0Vk71utni984WO/OI6tvWt2CxTTkOM6nt6p4TsKp
EIHU2rrxeZ+fh+qJrf3WXCsI3CCFAFtADYQO8LCNrZDkmosqRLDNQY/88C1Gy/Zo
d8SM2wrjc+BHDdxA3xSQxZmOq7XCe/7+fTluDYpoci9MvtL6QdlgfH2kqAwtqxRB
BG58pVJDGrW/68rRHUNl5ti4JL9F0g==
=4ONt
-----END PGP SIGNATURE-----
Merge tag 'asoc-v5.10' of https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound into for-linus
ASoC: Updates for v5.10
Not a huge amount going on in the core for ASoC this time but quite a
lot of driver activity, especially for the Intel platforms:
- Replacement of the DSP driver for some older x86 systems with a new
one which was written with closer reference to the DSP firmware so
should hopefully be more robust and maintainable.
- A big batch of static checker and other fixes for the rest of the x86
DSP drivers.
- Cleanup of the error unwinding code from Morimoto-san, hopefully
making it more robust.
- Helpers for parsing auxiluary devices from the device tree from
Stephan Gerhold.
- New support for AllWinner A64, Cirrus Logic CS4234, Mediatek MT6359
Microchip S/PDIF TX and RX controllers, Realtek RT1015P, and Texas
Instruments J721E, TAS2110, TAS2564 and TAS2764
In case HDA controller becomes active, but codec is runtime suspended,
jack detection is not successful and no interrupt is raised. This has
been observed with multiple Realtek codecs and HDA controllers from
different vendors. Bug does not occur if both codec and controller are
active, or both are in suspend. Bug can be easily hit on desktop systems
with no built-in speaker.
The problem can be fixed by powering up the codec once after every
controller runtime resume. Even if codec goes back to suspend later, the
jack detection will continue to work. Add a flag to 'hda_codec' to
describe codecs that require this flow from the controller driver.
Modify __azx_runtime_resume() to use pm_request_resume() to make the
intent clearer.
Mark all Realtek codecs with the new forced_resume flag.
BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=209379
Cc: Kailang Yang <kailang@realtek.com>
Co-developed-by: Kai-Heng Feng <kai.heng.feng@canonical.com>
Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com>
Signed-off-by: Kai Vehmanen <kai.vehmanen@linux.intel.com>
Cc: <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/20201012102704.794423-1-kai.vehmanen@linux.intel.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
byt-rt5640 is deprecated in favor of bytcr_rt5640 used by
sound/soc/intel/atom and SOF solutions both. Remove redundant machine
board and all related code.
Signed-off-by: Cezary Rojewski <cezary.rojewski@intel.com>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Acked-by: Liam Girdwood <liam.r.girdwood@intel.com>
Link: https://lore.kernel.org/r/20201006064907.16277-4-cezary.rojewski@intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
soc_pcm_open() does rollback when failed (A),
but, it is almost same as soc_pcm_close().
static int soc_pcm_open(xxx)
{
...
if (ret < 0)
goto xxx_err;
...
return 0;
^ config_err:
| ...
| rtd_startup_err:
(A) ...
| component_err:
| ...
v return ret;
}
The difference is
soc_pcm_close() is for all dai/component/substream,
rollback is for succeeded part only.
This kind of duplicated code can be a hotbed of bugs,
thus, we want to share soc_pcm_close() and rollback.
Now, soc_pcm_open/close() are handling
1) snd_soc_dai_startup/shutdown()
2) snd_soc_link_startup/shutdown()
3) snd_soc_component_module_get/put()
4) snd_soc_component_open/close()
=> 5) pm_runtime_put/get()
This patch is for 5) pm_runtime_put/get().
The idea of having bit-flag or counter is not enough for this purpose.
For example if one DAI is used for 2xPlaybacks for some reasons,
and if 1st Playback was succeeded but 2nd Playback was failed,
2nd Playback rollback doesn't need to call shutdown.
But it has succeeded bit-flag or counter via 1st Playback,
thus, 2nd Playback rollback will call unneeded shutdown.
And 1st Playback's necessary shutdown will not be called,
because bit-flag or counter was cleared by wrong 2nd Playback rollback.
To avoid such case, this patch marks substream pointer when get() was
succeeded. If rollback needed, it will check rollback flag and marked
substream pointer.
One note here is that it cares *current* get() only now.
but we might want to check *whole* marked substream in the future.
This patch is using macro named "push/pop", so that it can be easily
update.
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Link: https://lore.kernel.org/r/87h7ribwnb.wl-kuninori.morimoto.gx@renesas.com
Signed-off-by: Mark Brown <broonie@kernel.org>
soc_pcm_open() does rollback when failed (A),
but, it is almost same as soc_pcm_close().
static int soc_pcm_open(xxx)
{
...
if (ret < 0)
goto xxx_err;
...
return 0;
^ config_err:
| ...
| rtd_startup_err:
(A) ...
| component_err:
| ...
v return ret;
}
The difference is
soc_pcm_close() is for all dai/component/substream,
rollback is for succeeded part only.
This kind of duplicated code can be a hotbed of bugs,
thus, we want to share soc_pcm_close() and rollback.
Now, soc_pcm_open/close() are handling
1) snd_soc_dai_startup/shutdown()
2) snd_soc_link_startup/shutdown()
=> 3) snd_soc_component_module_get/put()
=> 4) snd_soc_component_open/close()
5) pm_runtime_put/get()
This patch is for 3) snd_soc_component_module_get/put()
4) snd_soc_component_open/close().
The idea of having bit-flag or counter is not enough for this purpose.
For example if one DAI is used for 2xPlaybacks for some reasons,
and if 1st Playback was succeeded but 2nd Playback was failed,
2nd Playback rollback doesn't need to call shutdown.
But it has succeeded bit-flag or counter via 1st Playback,
thus, 2nd Playback rollback will call unneeded shutdown.
And 1st Playback's necessary shutdown will not be called,
because bit-flag or counter was cleared by wrong 2nd Playback rollback.
To avoid such case, this patch marks substream pointer when open() was
succeeded. If rollback needed, it will check rollback flag and marked
substream pointer.
One note here is that it cares *current* open() only now.
but we might want to check *whole* marked substream in the future.
This patch is using macro named "push/pop", so that it can be easily
update.
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Link: https://lore.kernel.org/r/87imbybwno.wl-kuninori.morimoto.gx@renesas.com
Signed-off-by: Mark Brown <broonie@kernel.org>
soc_pcm_open() does rollback when failed (A),
but, it is almost same as soc_pcm_close().
static int soc_pcm_open(xxx)
{
...
if (ret < 0)
goto xxx_err;
...
return 0;
^ config_err:
| ...
| rtd_startup_err:
(A) ...
| component_err:
| ...
v return ret;
}
The difference is
soc_pcm_close() is for all dai/component/substream,
rollback is for succeeded part only.
This kind of duplicated code can be a hotbed of bugs,
thus, we want to share soc_pcm_close() and rollback.
Now, soc_pcm_open/close() are handling
1) snd_soc_dai_startup/shutdown()
=> 2) snd_soc_link_startup/shutdown()
3) snd_soc_component_module_get/put()
4) snd_soc_component_open/close()
5) pm_runtime_put/get()
This patch is for 2) snd_soc_link_startup/shutdown().
The idea of having bit-flag or counter is not enough for this purpose.
For example if one DAI is used for 2xPlaybacks for some reasons,
and if 1st Playback was succeeded but 2nd Playback was failed,
2nd Playback rollback doesn't need to call shutdown.
But it has succeeded bit-flag or counter via 1st Playback,
thus, 2nd Playback rollback will call unneeded shutdown.
And 1st Playback's necessary shutdown will not be called,
because bit-flag or counter was cleared by wrong 2nd Playback rollback.
To avoid such case, this patch marks substream pointer when startup() was
succeeded. If rollback needed, it will check rollback flag and marked
substream pointer.
One note here is that it cares *current* startup() only now.
but we might want to check *whole* marked substream in the future.
This patch is using macro named "push/pop", so that it can be easily
update.
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Link: https://lore.kernel.org/r/87k0webwnv.wl-kuninori.morimoto.gx@renesas.com
Signed-off-by: Mark Brown <broonie@kernel.org>
soc_pcm_open() does rollback when failed (A),
but, it is almost same as soc_pcm_close().
static int soc_pcm_open(xxx)
{
...
if (ret < 0)
goto xxx_err;
...
return 0;
^ config_err:
| ...
| rtd_startup_err:
(A) ...
| component_err:
| ...
v return ret;
}
The difference is
soc_pcm_close() is for all dai/component/substream,
rollback is for succeeded part only.
This kind of duplicated code can be a hotbed of bugs,
thus, we want to share soc_pcm_close() and rollback.
Now, soc_pcm_open/close() are handling
=> 1) snd_soc_dai_startup/shutdown()
2) snd_soc_link_startup/shutdown()
3) snd_soc_component_module_get/put()
4) snd_soc_component_open/close()
5) pm_runtime_put/get()
This patch is for 1) snd_soc_dai_startup/shutdown().
The idea of having bit-flag or counter is not enough for this purpose.
For example if one DAI is used for 2xPlaybacks for some reasons,
and if 1st Playback was succeeded but 2nd Playback was failed,
2nd Playback rollback doesn't need to call shutdown.
But it has succeeded bit-flag or counter via 1st Playback,
thus, 2nd Playback rollback will call unneeded shutdown.
And 1st Playback's necessary shutdown will not be called,
because bit-flag or counter was cleared by wrong 2nd Playback rollback.
To avoid such case, this patch marks substream pointer when startup() was
succeeded. If rollback needed, it will check rollback flag and marked
substream pointer.
One note here is that it cares *current* startup() only now.
but we might want to check *whole* marked substream in the future.
This patch is using macro named "push/pop", so that it can be easily
update.
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Link: https://lore.kernel.org/r/87lfgubwoc.wl-kuninori.morimoto.gx@renesas.com
Signed-off-by: Mark Brown <broonie@kernel.org>
The current SOF machine driver adds a name prefix for each codec,
mainly to differentiate ALSA controls for left and right amplifiers.
This is a good idea, but the machine driver duplicates some of the
information that already exists in ACPI descriptors, so add those
prefixes there. Follow-up patches will make use of the information
encoded in these tables and remove duplication.
Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Reviewed-by: Bard Liao <yung-chuan.liao@linux.intel.com>
Reviewed-by: Guennadi Liakhovetski <guennadi.liakhovetski@linux.intel.com>
Signed-off-by: Kai Vehmanen <kai.vehmanen@linux.intel.com>
Link: https://lore.kernel.org/r/20200923080514.3242858-4-kai.vehmanen@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Use set_jack ops to set jack so machine drivers do not need to include
hdmi-codec.h explicitly.
Signed-off-by: Cheng-Yi Chiang <cychiang@chromium.org>
Reviewed-by: Tzung-Bi Shih <tzungbi@google.com>
Link: https://lore.kernel.org/r/20200922062316.1172935-1-cychiang@chromium.org
Signed-off-by: Mark Brown <broonie@kernel.org>
To provide backward compatibility to older systems, the SOF HDA driver
allows user to specify which HDMI codec driver to use at runtime via
kernel parameter. This mechanism has a subtle flaw in that it assumes
the codec drivers not to be loaded when the SOF PCI driver is loaded.
The problem is rooted in use of the hdev->type field.
snd_hdac_ext_bus_device_init() initializes this field to HDA_DEV_ASOC.
This signals the HDA core that ASoC drivers should be considered in
driver matching (hda_bus_match()). The SOF and SST drivers continue by
overriding this field to HDA_DEV_LEGACY and proceeding to load driver
modules with request_module(). Correct drivers will get loaded and
attached.
If however the codec drivers are already loaded when
snd_hdac_ext_bus_device_init() is called, the matching will not work as
expected as device type is still set to HDA_DEV_ASOC. Specifically if
hdac-hdmi is attached when machine driver is configured to use hdac-hda,
this leads to out-of-bounds memory access in
hda_dsp_hdmi_build_controls().
Fix the issue by adding codec type as a parameter to
snd_hdac_ext_bus_device_init() and ensuring type is set correctly from
the start.
Fixes: 139c7febad ("ASoC: SOF: Intel: add support for snd-hda-codec-hdmi")
Signed-off-by: Kai Vehmanen <kai.vehmanen@linux.intel.com>
Reviewed-by: Guennadi Liakhovetski <guennadi.liakhovetski@linux.intel.com>
Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Link: https://lore.kernel.org/r/20200921100841.2882662-1-kai.vehmanen@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
On i.MX platforms PM is not managed via ACPI although CONFIG_ACPI
can be set. So, in order to correctly set the system target state
we introduce a flag for platforms that require to use acpi target
states.
Signed-off-by: Daniel Baluta <daniel.baluta@nxp.com>
Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com>
Signed-off-by: Kai Vehmanen <kai.vehmanen@linux.intel.com>
Link: https://lore.kernel.org/r/20200921105038.2909899-1-kai.vehmanen@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
This field will be used to compare ldc file with loaded fw version,
to assert validity of trace logs. Value used in sof-logger.
Signed-off-by: Karol Trzcinski <karolx.trzcinski@linux.intel.com>
Reviewed-by: Guennadi Liakhovetski <guennadi.liakhovetski@linux.intel.com>
Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Signed-off-by: Kai Vehmanen <kai.vehmanen@linux.intel.com>
Link: https://lore.kernel.org/r/20200917105633.2579047-3-kai.vehmanen@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
The tasklet is an old API that should be deprecated, usually can be
converted to another decent API. In ALSA core timer API, the
callbacks can be offlined to a tasklet when a flag is set in the timer
backend. It can be achieved gracefully with a work queued in the
high-prio system workqueue.
This patch replaces the usage of tasklet in ALSA timer API with a
simple work. Currently the tasklet feature is used only in the system
timer and hrtimer backends, so both are patched to use the new flag
name SNDRV_TIMER_HW_WORK, too.
Link: https://lore.kernel.org/r/20200903104131.21097-3-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
This series adds support for UUID based component identification
in SOF. UUIDs provide a more scalable alternative to the old
component type based approach to identify which DSP components
should be loaded.
More detailed description of UUID usage in SOF is available in:
https://thesofproject.github.io/latest/developer_guides/uuid/
UUID support is an incremental update to the SOF IPC interface. Driver
remains compatible with pre-UUID (ABI <3.17) firmware versions.
Keyon Jie (16):
ASoC: SOF: tokens: add token for component UUID
ASoC: SOF: add comp_ext to struct snd_sof_widget
ASoC: SOF: topology: create component extended tokens
ASoC: SOF: topology: parse comp_ext_tokens for all widgets
ASoC: SOF: use the sof_ipc_comp reserved bytes for extended data
ASoC: SOF: topology: add helper for setting up IPC component
ASoC: SOF: append extended data to sof_ipc_comp_dai
ASoC: SOF: append extended data to sof_ipc_comp_mixer
ASoC: SOF: append extended data to sof_ipc_comp_volume
ASoC: SOF: append extended data to sof_ipc_comp_host
ASoC: SOF: append extended data to sof_ipc_comp_src
ASoC: SOF: append extended data to sof_ipc_comp_asrc
ASoC: SOF: append extended data to sof_ipc_comp_tone
ASoC: SOF: append extended data to sof_ipc_comp_process
ASoC: SOF: append extended data to sof_ipc_comp_mux
ASoC: SOF: topology: make process type optional
include/sound/sof/topology.h | 12 +-
include/uapi/sound/sof/tokens.h | 1 +
sound/soc/sof/sof-audio.c | 23 +++-
sound/soc/sof/sof-audio.h | 3 +
sound/soc/sof/topology.c | 208 ++++++++++++++++++++------------
5 files changed, 161 insertions(+), 86 deletions(-)
--
2.27.0
Use the 32bit reserved member of the struct sof_ipc_comp as the extended
data length, this will help to minimize the ABI change for adding new
extended data to the struct sof_ipc_comp, usually only minor ABI version
bump needed for every update with this new solution.
Signed-off-by: Keyon Jie <yang.jie@linux.intel.com>
Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com>
Signed-off-by: Kai Vehmanen <kai.vehmanen@linux.intel.com>
Link: https://lore.kernel.org/r/20200904132744.1699575-6-kai.vehmanen@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Add member comp_ext to struct snd_sof_widget, which will be used for
topology extended tokens parsing.
Signed-off-by: Keyon Jie <yang.jie@linux.intel.com>
Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com>
Signed-off-by: Kai Vehmanen <kai.vehmanen@linux.intel.com>
Link: https://lore.kernel.org/r/20200904132744.1699575-3-kai.vehmanen@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Previous changes move to use ERR_PTR(-ENOTSUPP), but it's not clear
what implementations can return in case of errors. Explicitly document
that NULL is not a possible return value, only ERR_PTR with a negative
error code is valid.
Fixes: 308811a327 ('ASoC: soc-dai: return proper error for get_sdw_stream()')
Cc: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
Reported-by: Bard Liao <yung-chuan.liao@linux.intel.com>
Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Reviewed-by: Rander Wang <rander.wang@linux.intel.com>
Signed-off-by: Bard Liao <yung-chuan.liao@linux.intel.com>
Link: https://lore.kernel.org/r/20200904182854.3944-2-yung-chuan.liao@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Introduce for_each_rtd_dais_rollback macro which behaves exactly like
for_each_codec_dais_rollback and its cpu_dais equivalent but for all
dais instead.
Use newly added macro to fix soc_pcm_open error path and prevent
uninitialized dais from being cleaned-up.
Signed-off-by: Cezary Rojewski <cezary.rojewski@intel.com>
Fixes: 5d9fa03e6c ("ASoC: soc-pcm: tidyup soc_pcm_open() order")
Acked-by: Liam Girdwood <liam.r.girdwood@linux.intel.com>
Acked-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Link: https://lore.kernel.org/r/20200907111939.16169-1-cezary.rojewski@intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
commit 25612477d2 ("ASoC: soc-dai: set dai_link dpcm_ flags with a helper")
added snd_soc_dai_link_set_capabilities().
But it is using snd_soc_find_dai() (A) which is required client_mutex (B).
And client_mutex is soc-core.c local.
struct snd_soc_dai *snd_soc_find_dai(xxx)
{
...
(B) lockdep_assert_held(&client_mutex);
...
}
void snd_soc_dai_link_set_capabilities(xxx)
{
...
for_each_pcm_streams(direction) {
...
for_each_link_cpus(dai_link, i, cpu) {
(A) dai = snd_soc_find_dai(cpu);
...
}
...
for_each_link_codecs(dai_link, i, codec) {
(A) dai = snd_soc_find_dai(codec);
...
}
}
...
}
Because of these background, we will get WARNING if .config has CONFIG_LOCKDEP.
WARNING: CPU: 2 PID: 53 at sound/soc/soc-core.c:814 snd_soc_find_dai+0xf8/0x100
CPU: 2 PID: 53 Comm: kworker/2:1 Not tainted 5.7.0-rc1+ #328
Hardware name: Renesas H3ULCB Kingfisher board based on r8a77951 (DT)
Workqueue: events deferred_probe_work_func
pstate: 60000005 (nZCv daif -PAN -UAO)
pc : snd_soc_find_dai+0xf8/0x100
lr : snd_soc_find_dai+0xf4/0x100
...
Call trace:
snd_soc_find_dai+0xf8/0x100
snd_soc_dai_link_set_capabilities+0xa0/0x16c
graph_dai_link_of_dpcm+0x390/0x3c0
graph_for_each_link+0x134/0x200
graph_probe+0x144/0x230
platform_drv_probe+0x5c/0xb0
really_probe+0xe4/0x430
driver_probe_device+0x60/0xf4
snd_soc_find_dai() will be used from (X) CPU/Codec/Platform driver with
mutex lock, and (Y) Card driver without mutex lock.
This snd_soc_dai_link_set_capabilities() is for Card driver,
this means called without mutex.
This patch adds snd_soc_find_dai_with_mutex() to solve it.
Fixes: 25612477d2 ("ASoC: soc-dai: set dai_link dpcm_ flags with a helper")
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Link: https://lore.kernel.org/r/87blixvuab.wl-kuninori.morimoto.gx@renesas.com
Signed-off-by: Mark Brown <broonie@kernel.org>
commit 25612477d2 ("ASoC: soc-dai: set dai_link dpcm_ flags with a helper")
added snd_soc_dai_link_set_capabilities().
But it is using snd_soc_find_dai() (A) which is required client_mutex (B).
And client_mutex is soc-core.c local.
struct snd_soc_dai *snd_soc_find_dai(xxx)
{
...
(B) lockdep_assert_held(&client_mutex);
...
}
void snd_soc_dai_link_set_capabilities(xxx)
{
...
for_each_pcm_streams(direction) {
...
for_each_link_cpus(dai_link, i, cpu) {
(A) dai = snd_soc_find_dai(cpu);
...
}
...
for_each_link_codecs(dai_link, i, codec) {
(A) dai = snd_soc_find_dai(codec);
...
}
}
...
}
Because of these background, we will get WARNING if .config has CONFIG_LOCKDEP.
WARNING: CPU: 2 PID: 53 at sound/soc/soc-core.c:814 snd_soc_find_dai+0xf8/0x100
CPU: 2 PID: 53 Comm: kworker/2:1 Not tainted 5.7.0-rc1+ #328
Hardware name: Renesas H3ULCB Kingfisher board based on r8a77951 (DT)
Workqueue: events deferred_probe_work_func
pstate: 60000005 (nZCv daif -PAN -UAO)
pc : snd_soc_find_dai+0xf8/0x100
lr : snd_soc_find_dai+0xf4/0x100
...
Call trace:
snd_soc_find_dai+0xf8/0x100
snd_soc_dai_link_set_capabilities+0xa0/0x16c
graph_dai_link_of_dpcm+0x390/0x3c0
graph_for_each_link+0x134/0x200
graph_probe+0x144/0x230
platform_drv_probe+0x5c/0xb0
really_probe+0xe4/0x430
driver_probe_device+0x60/0xf4
snd_soc_find_dai() will be used from (X) CPU/Codec/Platform driver with
mutex lock, and (Y) Card driver without mutex lock.
This snd_soc_dai_link_set_capabilities() is for Card driver,
this means called without mutex.
This patch adds snd_soc_find_dai_with_mutex() to solve it.
Fixes: 25612477d2 ("ASoC: soc-dai: set dai_link dpcm_ flags with a helper")
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Link: https://lore.kernel.org/r/87blixvuab.wl-kuninori.morimoto.gx@renesas.com
Signed-off-by: Mark Brown <broonie@kernel.org>
It should be called VS_LTRP instead.
Reviewed-by: Guennadi Liakhovetski <guennadi.liakhovetski@linux.intel.com>
Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Signed-off-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com>
Reviewed-by: Takashi Iwai <tiwai@suse.de>
Link: https://lore.kernel.org/r/20200826184532.1612070-2-ranjani.sridharan@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
The debug ABI can be extracted from the extended manifest content.
This information known at build time does not need to be provided
in a mailbox.
Signed-off-by: Karol Trzcinski <karolx.trzcinski@linux.intel.com>
Reviewed-by: Kai Vehmanen <kai.vehmanen@linux.intel.com>
Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Reviewed-by: Guennadi Liakhovetski <guennadi.liakhovetski@linux.intel.com>
Signed-off-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com>
Link: https://lore.kernel.org/r/20200825235854.1588034-4-ranjani.sridharan@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
This step is needed to add possibility to pack sof_ipc_window inside
another one in used FW build tools - for example in extended manifest.
Structure reusability leads to easy parsing function reuse, so source
code is shorter and easier to maintain.
Using structures with constant size is less tricky and properly
supported by each toolchain by contrast to variable size elements.
This is minor ABI change - backward compatibility is kept.
Signed-off-by: Karol Trzcinski <karolx.trzcinski@linux.intel.com>
Reviewed-by: Guennadi Liakhovetski <guennadi.liakhovetski@linux.intel.com>
Reviewed-by: Kai Vehmanen <kai.vehmanen@linux.intel.com>
Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Signed-off-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com>
Link: https://lore.kernel.org/r/20200825235854.1588034-2-ranjani.sridharan@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
We use HDaudio and HDAudio, pick one to make searches easier.
No functionality change
Reported-by: Guennadi Liakhovetski <guennadi.liakhovetski@linux.intel.com>
Reviewed-by: Bard Liao <yung-chuan.liao@linux.intel.com>
Reviewed-by: Guennadi Liakhovetski <guennadi.liakhovetski@linux.intel.com>
Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Link: https://lore.kernel.org/r/20200824200912.46852-9-pierre-louis.bossart@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
