Age | Commit message (Collapse) | Author |
|
Along with the conversion to PCM copy ops, use the iov_iter for the
pointer to be passed to the dmaengine process callback, too. It
avoids the direct reference of iter_iov_addr(), and it can potentially
help for the drivers to access memory properly (although both atmel
and stm drivers don't use the given buffer address at all for now).
Reviewed-by: Mark Brown <broonie@kernel.org>
Cc: Lars-Peter Clausen <lars@metafoo.de>
Cc: Claudiu Beznea <claudiu.beznea@microchip.com>
Cc: Olivier Moysan <olivier.moysan@foss.st.com>
Cc: Arnaud Pouliquen <arnaud.pouliquen@foss.st.com>
Link: https://lore.kernel.org/r/20230815190136.8987-23-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
For following the ALSA PCM core change, a new PCM copy ops is added
toe ASoC component framework: snd_soc_component_driver receives the
copy ops, and snd_soc_pcm_component_copy() helper is provided.
This also fixes a long-standing potential bug where the ASoC driver
covers only copy_user PCM callback and misses the copy from kernel
pointers (such as OSS PCM layer), too.
As of this patch, the old copy_user is still kept, but it'll be
dropped later after all drivers are converted.
Reviewed-by: Mark Brown <broonie@kernel.org>
Link: https://lore.kernel.org/r/20230815190136.8987-19-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
Add two more helpers for copying memory between iov_iter and iomem,
which will be used by the new PCM copy ops in a few drivers.
The existing helpers became wrappers of those now.
Note that copy_from/to_iter() returns the copied bytes, hence the
error condition is adjusted accordingly.
Link: https://lore.kernel.org/r/20230815190136.8987-4-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
iov_iter is a universal interface to copy the data chunk from/to
user-space and kernel in a unified manner. This API can fit for ALSA
PCM copy ops, too; we had to split to copy_user and copy_kernel in the
past, and those can be unified to a single ops with iov_iter.
This patch adds a new PCM copy ops that passes iov_iter for copying
both kernel and user-space in the same way. This patch touches only
the ALSA PCM core part, and the actual users will be replaced in the
following patches.
The expansion of iov_iter is done in the PCM core right before calling
each copy callback. It's a bit suboptimal, but I took this now as
it's the most straightforward replacement. The more conversion to
iov_iter in the caller side is a TODO for future.
As of now, the old copy_user and copy_kernel ops are still kept.
Once after all users are converted, we'll drop the old copy_user and
copy_kernel ops, too.
Link: https://lore.kernel.org/r/20230815190136.8987-3-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
Convert the RT5682S to use GPIO descriptors and drop the
legacy GPIO headers.
We remove the global GPIO number from the platform data,
but it is still possible to create board files using GPIO
descriptor tables, if desired.
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Link: https://lore.kernel.org/r/20230817-descriptors-asoc-rt-v2-5-02fa2ca3e5b0@linaro.org
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
Convert the RT5682 to use GPIO descriptors and drop the
legacy GPIO headers.
We remove the global GPIO number from the platform data,
but it is still possible to create board files using GPIO
descriptor tables, if desired.
Make sure to make sure SDW devices can associate with
an LDO1 EN descriptor too, if they so desire by putting
the lookup into the common code.
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Link: https://lore.kernel.org/r/20230817-descriptors-asoc-rt-v2-4-02fa2ca3e5b0@linaro.org
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
Convert the RT5668 to use GPIO descriptors and drop the
legacy GPIO headers.
We remove the global GPIO number from the platform data,
but it is still possible to create board files using GPIO
descriptor tables, if desired.
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Link: https://lore.kernel.org/r/20230817-descriptors-asoc-rt-v2-3-02fa2ca3e5b0@linaro.org
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
The RT5665 driver has some stub support for GPIO descriptors
going back to the initial driver commit, where there are
two GPIO descriptors for the LDO and headphone detection
defined in the device state. Well, let's make use of the
descriptor properly.
We remove the global GPIO number from the platform data,
but it is still possible to create board files using GPIO
descriptor tables, if desired.
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Link: https://lore.kernel.org/r/20230817-descriptors-asoc-rt-v2-2-02fa2ca3e5b0@linaro.org
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
Now all users of snd_device_intialize() are gone, let's drop it.
Reviewed-by: Jaroslav Kysela <perex@perex.cz>
Signed-off-by: Curtis Malainey <cujomalainey@chromium.org>
Tested-by: Curtis Malainey <cujomalainey@chromium.org>
Link: https://lore.kernel.org/r/20230816160252.23396-10-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
Embedding the struct device to snd_compr object may result in UAF when
the delayed kobj release is used. Like other devices, let's detach
the struct device from the snd_compr by allocating dynamically via
snd_device_alloc().
Reviewed-by: Jaroslav Kysela <perex@perex.cz>
Signed-off-by: Curtis Malainey <cujomalainey@chromium.org>
Tested-by: Curtis Malainey <cujomalainey@chromium.org>
Link: https://lore.kernel.org/r/20230816160252.23396-7-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
This patch detaches the struct device from the snd_rawmidi object by
allocating via snd_device_alloc(), just like done for other devices.
Reviewed-by: Jaroslav Kysela <perex@perex.cz>
Signed-off-by: Curtis Malainey <cujomalainey@chromium.org>
Tested-by: Curtis Malainey <cujomalainey@chromium.org>
Link: https://lore.kernel.org/r/20230816160252.23396-6-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
Like control and PCM devices, it's better to avoid the embedded struct
device for hwdep (although it's more or less well working), too.
Change it to allocate via snd_device_alloc(), and free the memory at
the common snd_hwdep_free().
Reviewed-by: Jaroslav Kysela <perex@perex.cz>
Signed-off-by: Curtis Malainey <cujomalainey@chromium.org>
Tested-by: Curtis Malainey <cujomalainey@chromium.org>
Link: https://lore.kernel.org/r/20230816160252.23396-5-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
So far we use the embedded struct device for each PCM substreams in
struct snd_pcm. This may result in UAF when the delayed kobj release
is used; each corresponding struct device is still accessed at the
(delayed) device release, while the snd_pcm object may be already
gone.
As a workaround, detach the struct device from the snd_pcm object by
allocating via the new snd_device_alloc() helper.
A caveat is that we store the PCM substream pointer to drvdata since
the device resume and others require the access to it.
This patch is based on the fix Curtis posted initially. In this
patch, the changes are split and use the new helper function instead.
Link: https://lore.kernel.org/r/20230801171928.1460120-1-cujomalainey@chromium.org
Reviewed-by: Jaroslav Kysela <perex@perex.cz>
Signed-off-by: Curtis Malainey <cujomalainey@chromium.org>
Tested-by: Curtis Malainey <cujomalainey@chromium.org>
Link: https://lore.kernel.org/r/20230816160252.23396-4-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
Embedding the ctl_dev in the snd_card object may result in UAF when
the delayed kobj release is used; at the delayed kobj release, it
still accesses the struct device itself while the card memory (that
embeds the struct device) may be already gone.
As a workaround, detach the struct device from the card object by
allocating via the new snd_device_alloc() helper. The rest are just
replacing ctl_dev access to the pointer.
This is based on the fix Curtis posted initially. In this patch, the
changes are split and use the new helper function instead.
Link: https://lore.kernel.org/r/20230801171928.1460120-1-cujomalainey@chromium.org
Reviewed-by: Jaroslav Kysela <perex@perex.cz>
Signed-off-by: Curtis Malainey <cujomalainey@chromium.org>
Tested-by: Curtis Malainey <cujomalainey@chromium.org>
Link: https://lore.kernel.org/r/20230816160252.23396-3-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
Introduce a new helper, snd_device_alloc(), for allocating a struct
device that is bound with the sound class. It's a replacement of
snd_device_initialize().
Reviewed-by: Jaroslav Kysela <perex@perex.cz>
Signed-off-by: Curtis Malainey <cujomalainey@chromium.org>
Tested-by: Curtis Malainey <cujomalainey@chromium.org>
Link: https://lore.kernel.org/r/20230816160252.23396-2-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
The existing soc-dapm code may add a prefix to control names, which in
some cases is useful but in others leads to long and confusing kcontrol
names such as "gain 2.1 Main Playback Volume".
This patch suggests an added flag to prevent the widget name prefix
from being added. That flag will be set in the topology file on a
per-widget basis.
The flag no_wname_in_kcontrol_name is added to struct snd_soc_dapm_widget,
and the logic in dapm_create_or_share_kcontrol() is changed to not to
add widget name if the flag is set.
Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com>
Reviewed-by: Bard Liao <yung-chuan.liao@linux.intel.com>
Signed-off-by: Jyri Sarha <jyri.sarha@intel.com>
Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Link: https://lore.kernel.org/r/20230814232325.86397-2-pierre-louis.bossart@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
Now, all drivers are using ops call backs.
Let's remove unused other call back functions.
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Link: https://lore.kernel.org/r/87cyzx9m4o.wl-kuninori.morimoto.gx@renesas.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
snd_soc_dai_driver has .ops for call back functions (A), but it also
has other call back functions (B). It is duplicated and confusable.
struct snd_soc_dai_driver {
...
^ int (*probe)(...);
| int (*remove)(...);
(B) int (*compress_new)(...);
| int (*pcm_new)(...);
v ...
(A) const struct snd_soc_dai_ops *ops;
...
}
This patch merges (B) into (A).
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Link: https://lore.kernel.org/r/87v8dpb0w6.wl-kuninori.morimoto.gx@renesas.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
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>
|
|
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.
|
|
We need to retrieve the current value to deal with the HDAudio
WAKEEN/WAKESTS setup.
Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Reviewed-by: Bard Liao <yung-chuan.liao@linux.intel.com>
Reviewed-by: Rander Wang <rander.wang@intel.com>
Link: https://lore.kernel.org/r/20230807210959.506849-18-pierre-louis.bossart@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
The UID field in snd_soc_acpi_link_adr is not documented, add kernel doc
for it.
Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com>
Link: https://lore.kernel.org/r/20230803162312.117771-1-ckeepax@opensource.cirrus.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>
|
|
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>
|
|
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound into for-next
ASoC: Updates for v6.6
Here's an initial batch of updates for ASoC for this release cycle.
We've got a bunch of new drivers in here, a bit of core work from
Morimoto-san and quite a lot of janitorial work. There's several
updates that pull in changes from other subsystems in order to build
on them:
- An adaptor to allow use of IIO DACs and ADCs in ASoC which pulls in
some IIO changes.
- Create a library function for intlog10() and use it in the NAU8825
driver.
- Include the ASoC tests, including the topology tests, in the default
KUnit full test coverage. This also involves enabling UML builds of
ALSA since that's the default KUnit test environment which pulls in
the addition of some stubs to the driver.
- More factoring out from Morimoto-san.
- Convert a lot of drivers to use the more modern maple tree register
cache.
- Support for AMD machines with MAX98388 and NAU8821, Cirrus Logic
CS35L36, Intel AVS machines with ES8336 and RT5663 and NXP i.MX93.
|
|
To enable the speaker output in external boost mode, 2 registers must
be set, one after another. The longer the time between the writes of
the two registers, the more likely, and more loudly a pop may occur.
To minimize this, an mbox command can be used to allow the firmware
to perform this action, minimizing any delay between write, thus
minimizing any pop or click as a result. The old method will remain
when running without firmware.
Acked-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Stefan Binding <sbinding@opensource.cirrus.com>
Link: https://lore.kernel.org/r/20230721151816.2080453-2-sbinding@opensource.cirrus.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
Move issuing of a CS35L56_MBOX_CMD_SHUTDOWN command and then waiting for
the DSP to reach CS35L56_HALO_STATE_SHUTDOWN in the register appropriate
for the hardware revision into a common function.
Signed-off-by: Simon Trimmer <simont@opensource.cirrus.com>
Signed-off-by: Richard Fitzgerald <rf@opensource.cirrus.com>
Acked-by: Mark Brown <broonie@kernel.org>
Link: https://lore.kernel.org/r/20230721132120.5523-10-rf@opensource.cirrus.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
Move the waits for CS35L56_CONTROL_PORT_READY_US into a common
function, and also allow a wider range of allowed wait times.
Signed-off-by: Simon Trimmer <simont@opensource.cirrus.com>
Signed-off-by: Richard Fitzgerald <rf@opensource.cirrus.com>
Acked-by: Mark Brown <broonie@kernel.org>
Link: https://lore.kernel.org/r/20230721132120.5523-9-rf@opensource.cirrus.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
Part of the initialization code in cs35l56_init() can be re-used
by the HDA driver so move it into a new function in the shared
library.
Signed-off-by: Richard Fitzgerald <rf@opensource.cirrus.com>
Acked-by: Mark Brown <broonie@kernel.org>
Link: https://lore.kernel.org/r/20230721132120.5523-8-rf@opensource.cirrus.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
Move the code that initialized the struct cs_dsp members
into the shared library so that the HDA driver can use it.
Signed-off-by: Richard Fitzgerald <rf@opensource.cirrus.com>
Acked-by: Mark Brown <broonie@kernel.org>
Link: https://lore.kernel.org/r/20230721132120.5523-7-rf@opensource.cirrus.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
The majority of runtime_suspend and runtime_resume handling
doesn't have anything specific to the ASoC driver, so can be
shared by the HDA driver. Move this code into the shared
library.
Signed-off-by: Richard Fitzgerald <rf@opensource.cirrus.com>
Acked-by: Mark Brown <broonie@kernel.org>
Link: https://lore.kernel.org/r/20230721132120.5523-6-rf@opensource.cirrus.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
Move the cs35l56 utility functions into the shared file so they are
available for use in HDA.
Signed-off-by: Simon Trimmer <simont@opensource.cirrus.com>
Signed-off-by: Richard Fitzgerald <rf@opensource.cirrus.com>
Acked-by: Mark Brown <broonie@kernel.org>
Link: https://lore.kernel.org/r/20230721132120.5523-5-rf@opensource.cirrus.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
The ASoC and HDA drivers have structures that contain some of the same
information - instead of maintaining two locations for this data the
drivers should share a common data structure as this will enable common
utility functions to be created.
The first step is to move the location of these members in the ASoC
driver.
Signed-off-by: Simon Trimmer <simont@opensource.cirrus.com>
Signed-off-by: Richard Fitzgerald <rf@opensource.cirrus.com>
Acked-by: Mark Brown <broonie@kernel.org>
Link: https://lore.kernel.org/r/20230721132120.5523-2-rf@opensource.cirrus.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
Add a new helper to add multiple vmaster followers in a shot. The
same function was open-coded in various places, and this helper
replaces them.
Link: https://lore.kernel.org/r/20230721071643.3631-2-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
A commonly seen pattern is to run snd_ctl_find_id() for a mixer
control element with a given string. Let's provide a standard helper
for achieving that for simplifying the code.
Link: https://lore.kernel.org/r/20230720082108.31346-2-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
ALSA: Make control API taking controls_rwsem consistently
A few ALSA control API helpers like snd_ctl_rename(), snd_ctl_remove()
and snd_ctl_find_*() suppose the callers taking card->controls_rwsem.
But it's error-prone and fragile. This patch set tries to change
those API functions to take the card->controls>rwsem internally by
themselves, so that the drivers don't need to take care of lockings.
After applying this patch set, only a couple of places still touch
card->controls_rwsem (which are OK-ish as they need for traversing the
control linked list).
Link: https://lore.kernel.org/r/20230718141304.1032-1-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
For reducing the unnecessary use of controls_rwsem in the drivers,
this patch adds a new variant for snd_ctl_find_*() helpers:
snd_ctl_find_id_locked() and snd_ctl_find_numid_locked() look for a
kctl element inside the card->controls_rwsem -- that is, doing the
very same as what snd_ctl_find_id() and snd_ctl_find_numid() did until
now. snd_ctl_find_id() and snd_ctl_find_numid() remain same,
i.e. still unlocked version, but they will be switched to locked
version once after all callers are replaced.
The patch also replaces the calls of snd_ctl_find_id() and
snd_ctl_find_numid() in a few places; all of those are places where we
know that the functions are called properly with controls_rwsem held.
All others are without rwsem (although they should have been).
After this patch, we'll turn on the locking in snd_ctl_find_id() and
snd_ctl_find_numid() to be more race-free.
Link: https://lore.kernel.org/r/20230718141304.1032-10-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
The id object passed to snd_ctl_find_id() is only read, and we can
mark it with const gracefully.
Link: https://lore.kernel.org/r/20230718141304.1032-9-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
The soft (firmware) registers for volume/mute/posture are not reset by
a chip soft-reset, so use a regmap patch to set them to defaults.
cs35l56_reread_firmware_registers() has been removed. Its intent was to
use whatever the firmware set as a default. But the driver now patches the
defaults to the registers.
Signed-off-by: Richard Fitzgerald <rf@opensource.cirrus.com>
Link: https://lore.kernel.org/r/20230718144625.39634-1-rf@opensource.cirrus.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
Pull cleanup of HD-audio PCI IDs.
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
Instead of using local macro to match PCI device, use global one. As
Apollolake is Broxton-P successor that made it to the market, be precise
and use APL shortcut. IS_CFL() macro is dropped as it is unused.
Acked-by: Mark Brown <broonie@kernel.org>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Reviewed-by: Cezary Rojewski <cezary.rojewski@intel.com>
Signed-off-by: Amadeusz Sławiński <amadeuszx.slawinski@linux.intel.com>
Link: https://lore.kernel.org/r/20230717114511.484999-9-amadeuszx.slawinski@linux.intel.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
Some HDA controllers require additional handling, so there are macros to
match them, however those are spread across multiple files. Add them all
in one place, so they can be reused.
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Acked-by: Mark Brown <broonie@kernel.org>
Reviewed-by: Cezary Rojewski <cezary.rojewski@intel.com>
Signed-off-by: Amadeusz Sławiński <amadeuszx.slawinski@linux.intel.com>
Link: https://lore.kernel.org/r/20230717114511.484999-6-amadeuszx.slawinski@linux.intel.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
Given that the filter is already set to neutral for PCM voices, the
only observable effect is that the Z1/Z2/FXBUS registers don't have a
stray bit set for negative numbers anymore. The bit is below the ones
significant for output, but it would mess with 32-bit sample
recombination, which we intend to add.
kX-project does that, but I had to figure out myself why.
Signed-off-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de>
Link: https://lore.kernel.org/r/20230715160802.326872-1-oswald.buddenhagen@gmx.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
85;95;0c
This uses IRQs to track spontaneous changes to the word clock source
register.
FWIW, that this can happen in the first place is the reason why it is
futile to lock the clock source mixer setting while the device is open -
we can't consistently control the rate anyway. Though arguably, we
should reset any open streams when that happens, as they become
corrupted anyway.
Signed-off-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de>
Link: https://lore.kernel.org/r/20230715160738.326832-1-oswald.buddenhagen@gmx.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
If CPU/Codec driver keeps its DAI node, we can directly identify actual
DAI by using snd_soc_get_dai_via_args().
This means we can use multi Component.
This patch enables multi Component support on Audio Graph Card/Card2.
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Link: https://lore.kernel.org/r/87a5w4o949.wl-kuninori.morimoto.gx@renesas.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
To use multi Component support, we need to check dai_args whether
Card could get DAI from args (CPU/Codec needs set dai_args on DAI driver).
If it could, we need to allocate dai_args for dlc.
This patch adds snd_soc_copy_dai_args() for it.
This is helper function for multi Component support.
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Link: https://lore.kernel.org/r/87bkgko94e.wl-kuninori.morimoto.gx@renesas.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
Current snd_soc_is_matching_component() checks "of_node" or "dai_args".
Thus coping "of_node" only is not enough to use CPU as Platform.
This patch adds snd_soc_dlc_use_cpu_as_platform() and help it.
This is helper function for multi Component support.
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Link: https://lore.kernel.org/r/87cz10o94k.wl-kuninori.morimoto.gx@renesas.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
To enable multi Component, Card driver need to get DAI via dai_args
to identify it. This patch adds snd_soc_get_dai_via_args() for it.
This is helper function for multi Component support.
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Link: https://lore.kernel.org/r/87edlgo94p.wl-kuninori.morimoto.gx@renesas.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
Current ASoC Card is using dlc (snd_soc_dai_link_component) to find
target DAI / Component to be used.
Current dlc has below 3 items to identify DAI / Component
(a) name for Component
(b) of_node for Component
(c) dai_name for DAI
(a) or (b) is used to identify target Component, and (c) is used
to identify DAI.
One of the biggest issue on it today is dlc needs "name matching"
for "dai_name" (c).
It was not a big deal when we were using platform_device, because we
could specify nessesary "dai_name" via its platform_data.
But we need to find DAI name pointer from whole registered datas and/or
each related driver somehow in case of DT, because we can't specify it.
Therefore, Card driver parses DT and assumes the DAI, and find its name
pointer. How to assume is based on each Component and/or Card.
Next biggest issue is Component node (a)/(b).
Basically, Component is registered when CPU/Codec driver was
probed() (X). Here, 1 Component is possible to have some DAIs.
int xxx_probe(struct platform_device *pdev)
{
...
(X) ret = devm_snd_soc_register_component(pdev->dev,
&component_driver,
&dai_driver, dai_driver_num);
...
}
The image of each data will be like below.
One note here is "driver" is included for later explanation.
+-driver------+
|+-component-+|
|| dai0||
|| dai1||
|| ...||
|+-----------+|
+-------------+
The point here is 1 driver has 1 Component, because basically driver
calles snd_soc_register_component() (= X) once.
Here is the very basic CPU/Codec connection image.
HW image SW image
+-- Board ------------+ +-card--------------------------+
|+-----+ +------+| |+-driver------+ +-driver------+|
|| CPU | <--> |CodecA|| ||+-component-+| |+-component-+||
|+-----+ +------+| ||| dai|<=>|dai |||
+---------------------+ ||+-----------+| |+-----------+||
|+-------------+ +-------------+|
+-------------------------------+
It will be very complex if it has multi DAIs.
Here is intuitive easy to understandable HW / SW example.
HW image SW image
+-- Board ---------------+ +-card--------------------------+
|+--------+ +------+| |+-driver------+ +-driver------+|
|| CPU ch0| <--> |CodecA|| ||+-component-+| |+-component-+||
|| | +------+| ||| ch0 dai|<=>|dai |||
|| | +------+| ||| || |+-----------+||
|| ch1| <--> |CodecB|| ||| || +-------------+|
|+--------+ +------+| ||| || +-driver------+|
+------------------------+ ||| || |+-component-+||
||| ch1 dai|<=>|dai |||
||+-----------+| |+-----------+||
|+-------------+ +-------------+|
+-------------------------------+
It will be handled as multi interface as "one Card".
card0,0: CPU-ch0 - CodecA
card0,1: CPU-ch1 - CodecB
^
But, here is the HW image example which will be more complex
+-- Basic Board ---------+
|+--------+ +------+|
|| CPU ch0| <--> |CodecA||
|| ch1| <-+ +------+|
|+--------+ | |
+-------------|----------+
+-- expansion board -----+
| | +------+|
| +->|CodecB||
| +------+|
+------------------------+
We intuitively think we want to handle these as "2 Sound Cards".
card0,0: CPU-ch0 - CodecA
card1,0: CPU-ch1 - CodecB
^
But below image which we can register today doesn't allow it,
because the same Component will be connected to both Card0/1,
but it will be rejected by (Z).
+-driver------+
|+-component-+|
+-card0-------------------------+
||| || +-driver------+|
||| || |+-component-+||
||| ch0 dai|<=>|dai |||
||| || |+-----------+||
||| || +-------------+|
+-------------------------------+
|| ||
+-card1-------------------------+
||| || +-driver------+|
||| || |+-component-+||
||| ch1 dai|<=>|dai |||
||| || |+-----------+||
||| || +-------------+|
+-------------------------------+
|+-----------+|
+-------------+
static int soc_probe_component()
{
...
if (component->card) {
(Z) if (component->card != card) {
dev_err(component->dev, ...);
return -ENODEV;
}
return 0;
}
...
}
So, how about to call snd_soc_register_component() (= X) multiple times
on probe() to avoid buplicated component->card limitation, to be like
below ?
+-driver------+
+-card0-------------------------+
|| | +-driver------+|
||+-component-+| |+-component-+||
||| ch0 dai|<=>|dai |||
||+-----------+| |+-----------+||
|| | +-------------+|
+-------------------------------+
| |
+-card1-------------------------+
|| | +-driver------+|
||+-component-+| |+-component-+||
||| ch1 dai|<=>|dai |||
||+-----------+| |+-----------+||
|| | +-------------+|
+-------------------------------+
+-------------+
Yes, looks good. But unfortunately it doesn't help us for now.
Let's see soc_component_to_node() and snd_soc_is_matching_component()
static struct device_node
*soc_component_to_node(struct snd_soc_component *component)
{
...
(A) of_node = component->dev->of_node;
...
}
static int snd_soc_is_matching_component(...)
{
...
(B) if (dlc->of_node && component_of_node != dlc->of_node)
...
}
dlc checkes "of_node" to identify target component (B),
but this "of_node" came from component->dev (A) which is added
by snd_soc_register_component() (X) on probe().
This means we can have different "component->card", but have same
"component->dev" in this case.
Even though we calls snd_soc_register_component() (= X) multiple times,
all Components have same driver's dev, thus it is impossible to
identified the Component.
And if it was impossible to identify Component, it is impossible to
identify DAI on current implementation.
So, how to handle above complex HW image today is 2 patterns.
One is handles it as "1 big sound card".
The SW image is like below.
SW image
+-card--------------------------+
|+-driver------+ +-driver------+|
||+-component-+| |+-component-+||
||| ch0 dai|<=>|dai |||
||| || |+-----------+||
||| || +-------------+|
||| || +-driver------+|
||| || |+-component-+||
||| ch1 dai|<->|dai |||
||+-----------+| |+-----------+||
|+-------------+ +-------------+|
+-------------------------------+
But the problem is not intuitive.
We want to handle it as "2 Cards".
2nd pattern is like below.
SW image
+-card0-------------------------+
|+-driver------+ +-driver------+|
||+-component-+| |+-component-+||
||| ch0 dai|<=>|dai |||
||+-----------+| |+-----------+||
|+-------------+ +-------------+|
+-------------------------------+
+-card1-------------------------+
|+-driver------+ +-driver------+|
||+-component-+| |+-component-+||
||| ch1 dai|<=>|dai |||
||+-----------+| |+-----------+||
|+-------------+ +-------------+|
+-------------------------------+
It handles as "2 Cards", but CPU part needs to be probed as 2 drivers.
It is also not intuitive.
To solve this issue, we need to have multi Component support.
In current implementation, we need to identify Component first
to identify DAI, and it is using name matching to identify DAI.
But how about to be enable to directly identify DAI by unique way
instead of name matching ? In such case, we can directly identify DAI,
then it can identify Component from DAI.
For example Simple-Card / Audio-Graph-Card case, it is specifying DAI
via its node.
Simple-Card
sound-dai = <&cpu-sound>;
Audio-Graph-Card
dais = <&cpu-sound>;
If each CPU/Codec driver keeps this property when probing,
we can identify DAI directly from Card.
Being able to identify DAI directly means being able to identify its
Component as well even though Component has same dev (= B).
This patch adds new "dai_node" for it.
To keeping compatibility, it checks "dai_node" first if it has,
otherwise, use existing method (name matching).
Link: https://lore.kernel.org/r/87fskz5yrr.wl-kuninori.morimoto.gx@renesas.com
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Link: https://lore.kernel.org/r/87fs5wo94v.wl-kuninori.morimoto.gx@renesas.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
Current ASoC is specifying and checking DAI name.
But where it came from and how to check was ambiguous.
This patch adds snd_soc_dai_name_get() / snd_soc_dlc_dai_is_match()
and makes it clear.
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Link: https://lore.kernel.org/r/87h6qco952.wl-kuninori.morimoto.gx@renesas.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|