Commit 7ac3404c2e ("ASoC: amd: acp: Map missing jack kcontrols") adds
card kcontrols and DAPM widgets corresponding to jacks for Headphone and
Headset Mic. But these were already being added in acp-legacy-mach.c and
acp-sof-mach.c, so this causes a probe error:
sof_mach rt5682s-hs-rt1019: control 2:0:0:Headphone Jack Switch:0 is already present
sof_mach rt5682s-hs-rt1019: ASoC: Failed to add Headphone Jack Switch: -16
sof_mach rt5682s-hs-rt1019: devm_snd_soc_register_card(sof-rt5682s-hs-rt1019) failed: -16
sof_mach: probe of rt5682s-hs-rt1019 failed with error -16
Removing the new duplicates from the common code might be enough to fix
the issue. But some of the codecs use different kcontrols and widgets.
NAU8821 alone has an "Int Mic". MAX98360A has a single "Spk", while
RT1019 has "Left Spk" and "Right Spk" (and two codec instances with name
prefixes).
Since there are per-codec differences, add the kcontrols and widgets
in the common code as each dai-link is being initialized, instead of in
the two machine drivers' probe().
Also, MAX98388 has Left and Right instances, but uses a single "SPK"
widget. That seems weird, so normalize it to use two widgets (one per
each instance like RT1019) while we're adding controls.
Fixes: 7ac3404c2e ("ASoC: amd: acp: Map missing jack kcontrols")
Signed-off-by: Alper Nebi Yasak <alpernebiyasak@gmail.com>
Link: https://lore.kernel.org/r/20230818080314.32991-1-alpernebiyasak@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
This patch will improve the depop function of CBJ detection before the headphone playback
when the system resumes.
We also want to complete the CBJ detection in the system-level resume function.
It could avoid triggering the detection at the playing state of headphones.
Signed-off-by: Shuming Fan <shumingf@realtek.com>
Link: https://lore.kernel.org/r/20230818023732.2153170-1-shumingf@realtek.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Merge series from Linus Walleij <linus.walleij@linaro.org>:
After dropping unused headers a few Realtek devices
actually using the GPIO descriptors remain.
Converting them to use optional GPIO descriptors is
pretty straight-forward.
Merge series from Richard Fitzgerald <rf@opensource.cirrus.com>:
These two patches add an ACPI HID and update the way the platform-
specific firmware identifier is extracted from the ACPI.
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>
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>
The RT5640 driver is already using GPIO descriptors for some
stuff, all that is needed is to convert the remaining LDO1
control line to also use descriptors.
Simplify the code using gpiod_get_optional() and drop the
special "of" parsing function: these descriptors need not
come from device tree and it's optional so hey.
Keep some NULL checks around the GPIO operations even though
gpiolib is essentially NULL-tolerant, because by checking
for whether we have a valid GPIO descriptor or not we can
avoid a 400 ms delay which is great.
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Link: https://lore.kernel.org/r/20230817-descriptors-asoc-rt-v2-1-02fa2ca3e5b0@linaro.org
Signed-off-by: Mark Brown <broonie@kernel.org>
Use a device property "cirrus,firmware-uid" to get the unique firmware
identifier instead of using ACPI _SUB. There aren't any products that use
_SUB.
There will not usually be a _SUB in Soundwire nodes. The ACPI can use a
_DSD section for custom properties.
There is also a need to support instantiating this driver using software
nodes. This is for systems where the CS35L56 is a back-end device and the
ACPI refers only to the front-end audio device - there will not be any ACPI
references to CS35L56.
Fixes: e496112529 ("ASoC: cs35l56: Add driver for Cirrus Logic CS35L56")
Signed-off-by: Maciej Strozek <mstrozek@opensource.cirrus.com>
Signed-off-by: Richard Fitzgerald <rf@opensource.cirrus.com>
Link: https://lore.kernel.org/r/20230817112712.16637-2-rf@opensource.cirrus.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Almost every board machine / sound cards has "audio-routing" and "model"
properties, so move them to common schema to have only one definition of
these properties.
For amlogic,gx-sound-card, drop the minItems: 2 from the
"audio-routing", because any limit here - lower or upper- is rather
meaningless. This will also fix `dtbs_check` warnings like:
meson-gxm-s912-libretech-pc.dtb: sound: audio-routing: ['AU2 INL', 'ACODEC LOLN', 'AU2 INR', 'ACODEC LORN', '7J4-14 LEFT', 'AU2 OUTL', '7J4-11 RIGHT', 'AU2 OUTR'] is too long
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Reviewed-by: Rob Herring <robh@kernel.org>
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Link: https://lore.kernel.org/r/20230810063300.20151-1-krzysztof.kozlowski@linaro.org
Signed-off-by: Mark Brown <broonie@kernel.org>
Before adding a new FW control, its name is checked against
existing controls list. But the string length in strncmp used
to compare controls names is taken from the list, so if beginnings
of the controls are matching, then the new control is not created.
For example, if CAL_R control already exists, CAL_R_SELECTED
is not created.
The fix is to compare string lengths as well.
Fixes: 6477960755 ("ASoC: wm_adsp: Move check for control existence")
Signed-off-by: Vlad Karpovich <vkarpovi@opensource.cirrus.com>
Link: https://lore.kernel.org/r/20230815172908.3454056-1-vkarpovi@opensource.cirrus.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Merge series from Richard Fitzgerald <rf@opensource.cirrus.com>:
Use the FIRMWARE_MISSING flag in the CS35L56 to determine whether it is
safe to download a firmware patch.
Merge series from Li Zetao <lizetao1@huawei.com>:
This patch set use the helper function devm_kmemdup() to replace
devm_kmalloc + memcpy, which is the same as implementing the function
separately.
Merge series from Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>:
The use of the widget name as a prefix for the kcontrol name is quite
useful in the case of multiple pipelines going to the same endpoint,
but it's overkill in simpler cases.
This patchset extends the existing DAPM code to drop the widget name
prefix and make the kcontrol names simpler when there's no possible
ambiguity, e.g. "gain.2.1 Main Playback Volume" becomes just "Main
Playback Volume".
Only attempt to download wmfw/bin files to a non-secured part if
it reports FIRMWARE_MISSING. If FIRMWARE_MISSING is false the
firmware has already been patched and overwriting the patch could
corrupt the running firmware.
For a secured part the wmfw/bin can be downloaded even if
FIRMWARE_MISSING is false, because they will only patch tunings.
Signed-off-by: Richard Fitzgerald <rf@opensource.cirrus.com>
Link: https://lore.kernel.org/r/20230815124826.5447-3-rf@opensource.cirrus.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Add a flag to wm_adsp_power_up() that indicates whether it should attempt
to find and load firmware files.
This is to support DSPs that have built-in firmware that may already have
been patched (for example, by the BIOS). In that case the patch must not
be overwritten because that could corrupt the running firmware.
Signed-off-by: Richard Fitzgerald <rf@opensource.cirrus.com>
Link: https://lore.kernel.org/r/20230815124826.5447-2-rf@opensource.cirrus.com
Signed-off-by: Mark Brown <broonie@kernel.org>
