ASoC: SOF: sof-audio: preserve topology filename override in nocodec mode
If the topology filename is modified at a higher level, be it with a
DMI quirk or a kernel module parameter, we don't want to use the
default 'nocodec' topology name extracted from descriptors.
Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com> Reviewed-by: Daniel Baluta <daniel.baluta@nxp.com> Reviewed-by: Paul Olaru <paul.olaru@oss.nxp.com> Reviewed-by: Péter Ujfalusi <peter.ujfalusi@linux.intel.com> Link: https://lore.kernel.org/r/20220414184817.362215-8-pierre-louis.bossart@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
ASoC: SOF: sof-pci-dev: add parameter to override topology filename
The existing 'tplg_path' module parameter can be used to load
alternate firmware files, be it for development or to handle
OEM-specific or board-specific releases. However the topology filename
is either hard-coded in machine descriptors or modified by specific
DMI-quirks.
For additional flexibility, this patch adds the 'tplg_filename' module
parameter to override topology names.
To avoid any confusion between DMI- and parameter-override, a variable
rename is added.
Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com> Reviewed-by: Daniel Baluta <daniel.baluta@nxp.com> Reviewed-by: Paul Olaru <paul.olaru@oss.nxp.com> Reviewed-by: Péter Ujfalusi <peter.ujfalusi@linux.intel.com> Link: https://lore.kernel.org/r/20220414184817.362215-7-pierre-louis.bossart@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
ASoC: SOF: sof-pci-dev: add parameter to override firmware filename
The existing 'fw_path' module parameter can be used to load alternate
firmware files, be it for development or to handle OEM-specific or
board-specific releases. The firmware name is however non-modifiable
and defined by platform-specific descriptors.
For additional flexibility during development or enable quirks, this
patch adds the 'fw_filename' module parameter to override default
firmware names.
Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com> Reviewed-by: Daniel Baluta <daniel.baluta@nxp.com> Reviewed-by: Paul Olaru <paul.olaru@oss.nxp.com> Reviewed-by: Péter Ujfalusi <peter.ujfalusi@linux.intel.com> Link: https://lore.kernel.org/r/20220414184817.362215-6-pierre-louis.bossart@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
ASoC: SOF: add default IPC capability and file paths
This patch adds a default IPC type for each platform, along with file
paths to be used for each IPC type. To make reviews simpler, we only
modify platform descriptors in this table, the information will be
used in the next patch.
The Intel IPCv4 is only supported on Intel platforms after APL, and
not by default. In follow-up patches, support for SKL and KBL will be
added, and in those two cases the IPCv4 will be the default (and only
supported mode).
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> Reviewed-by: Péter Ujfalusi <peter.ujfalusi@linux.intel.com> Link: https://lore.kernel.org/r/20220414184817.362215-4-pierre-louis.bossart@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
ASoC: SOF: add definitions for different IPC types
Add enum type to allow for different types of IPCs. The IPCv4 is
intended for Intel only as a convergence path with firmware used in
Windows. Follow-up patches will introduce different abstractions with
.ops and different search paths for firmware and topology files.
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> Reviewed-by: Péter Ujfalusi <peter.ujfalusi@linux.intel.com> Link: https://lore.kernel.org/r/20220414184817.362215-2-pierre-louis.bossart@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
snd_soc_card_jack_new() allowed to create jack kcontrol without pins,
but did not create kcontrols. The jack would not have kcontrols if pins
were not going to be added.
This renames the old snd_soc_card_jack_new() to
snd_soc_card_jack_new_pins() for use when pins are provided or will be
added later. The new snd_soc_card_jack_new() appropriately creates a
jack for use without pins and adds a kcontrol.
Zheyu Ma [Sat, 9 Apr 2022 14:39:50 +0000 (22:39 +0800)]
ASoC: SOF: Intel: Check the bar size before remapping
The driver should use the pci_resource_len() to get the actual length of
pci bar, and compare it with the expect value. If the bar size is too
small (such as a broken device), the driver should return an error.
The driver, OMAP1 specific, now omits clk_prepare/unprepare() steps, not
supported by OMAP1 custom implementation of clock API. However, non-CCF
stubs of those functions exist for use on such platforms until converted
to CCF.
Update the driver to be compatible with CCF implementation of clock API.
Mark Brown [Tue, 12 Apr 2022 16:16:54 +0000 (17:16 +0100)]
ASoC: remaining simple i2c probe changes
Merge series from Stephen Kitt <steve@sk2.org>:
This series covers all the remaining changes to migrate
sound/soc/codecs i2c probes to probe_new, where the const struct
i2c_client * argument is unused; there are a few remaining files which
use the argument and will need i2c_match_id migration.
Mark Brown [Tue, 12 Apr 2022 16:16:52 +0000 (17:16 +0100)]
ASoC: SOF: Abstractions for top-level IPC ops
Merge series from Ranjani Sridharan <ranjani.sridharan@linux.intel.com>:
This series is continuation of the IPC abstraction in the SOF driver in
preparation for supporting the new IPC supported by the SOF firmware.
It introduces abstraction for top-level IPC ops for sending/receiving
regular and large IPC's.
Peter Ujfalusi (15):
ASoC: SOF: Add helper function to prepare and send an IPC message
ASoC: SOF: Add high level IPC IO callback definitions to ipc_ops
ASoC: SOF: ipc3: Implement the tx_msg IPC ops
ASoC: SOF: ipc3: Use sof_ipc3_tx_msg() internally for message sending
ASoC: SOF: ipc3: Implement the set_get_data IPC ops
ASoC: SOF: ipc3: Implement the get_reply IPC ops
ASoC: SOF: ipc3: Implement rx_msg IPC ops
ASoC: SOF: ipc: Separate the ops checks by functions/topics
ASoC: SOF: ipc: Add check for mandatory IPC message handling ops
ASoC: SOF: ipc: Use the get_reply ops in snd_sof_ipc_get_reply()
ASoC: SOF: ipc: Switch over to use the tx_msg and set_get_data ops
ASoC: SOF: ipc: Switch over to use the rx_msg ops
ASoC: SOF: Add widget_kcontrol_setup control ops for IPC3
ASoC: SOF: sof-audio: Use the widget_kcontrol_setup ops for kcontrol
set up
ASoC: SOF: ipc: Move the ipc_set_get_comp_data() local to ipc3-control
Mark Brown [Tue, 12 Apr 2022 16:16:51 +0000 (17:16 +0100)]
Allow detecting ACP6x DMIC via _DSD
Merge series from Mario Limonciello <mario.limonciello@amd.com>:
It's not possible to probe for the presence of a DMIC, so the ACP6x
machine driver currently has a hardcoded list of all the systems known
to have a DMIC connected to the ACP.
Although this design works it means that the acp6x driver needs to always
grow with more systems and worse, if an OEM introduces a new system there
will be a mismatch in time that even if the driver (otherwise) works fine
it needs their system added to the list to work.
So this series introduces a _DSD that OEMs can populate into the BIOS to
indicate presence of a DMIC.
ASoC: tegra186_asrc: mark runtime-pm functions as __maybe_unused
sound/soc/tegra/tegra186_asrc.c:90:12: error: ‘tegra186_asrc_runtime_resume’ defined but not used [-Werror=unused-function]
static int tegra186_asrc_runtime_resume(struct device *dev)
^~~~~~~~~~~~~~~~~~~~~~~~~~~~
sound/soc/tegra/tegra186_asrc.c:80:12: error: ‘tegra186_asrc_runtime_suspend’ defined but not used [-Werror=unused-function]
static int tegra186_asrc_runtime_suspend(struct device *dev)
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Mark these functions as __maybe_unused to avoid this kind of warning.
Fixes: a2df8c2d5b36 ("ASoC: tegra: Add Tegra186 based ASRC driver") Signed-off-by: YueHaibing <yuehaibing@huawei.com> Reviewed-by: Sameer Pujar <spujar@nvidia.com> Link: https://lore.kernel.org/r/20220411020908.580-1-yuehaibing@huawei.com Signed-off-by: Mark Brown <broonie@kernel.org>
Stephen Kitt [Tue, 5 Apr 2022 16:58:36 +0000 (18:58 +0200)]
ASoC: uda1380: use simple i2c probe function
The i2c probe functions here don't use the id information provided in
their second argument, so the single-parameter i2c probe function
("probe_new") can be used instead.
This avoids scanning the identifier tables during probes.
Stephen Kitt [Tue, 5 Apr 2022 16:58:35 +0000 (18:58 +0200)]
ASoC: ts3a227e: use simple i2c probe function
The i2c probe functions here don't use the id information provided in
their second argument, so the single-parameter i2c probe function
("probe_new") can be used instead.
This avoids scanning the identifier tables during probes.
Stephen Kitt [Tue, 5 Apr 2022 16:58:34 +0000 (18:58 +0200)]
ASoC: tlv320*: use simple i2c probe function
The i2c probe functions here don't use the id information provided in
their second argument, so the single-parameter i2c probe function
("probe_new") can be used instead.
This avoids scanning the identifier tables during probes.
Stephen Kitt [Tue, 5 Apr 2022 16:58:33 +0000 (18:58 +0200)]
ASoC: tda7419: use simple i2c probe function
The i2c probe functions here don't use the id information provided in
their second argument, so the single-parameter i2c probe function
("probe_new") can be used instead.
This avoids scanning the identifier tables during probes.
Stephen Kitt [Tue, 5 Apr 2022 16:58:32 +0000 (18:58 +0200)]
ASoC: tas*: use simple i2c probe function
The i2c probe functions here don't use the id information provided in
their second argument, so the single-parameter i2c probe function
("probe_new") can be used instead.
This avoids scanning the identifier tables during probes.
Stephen Kitt [Tue, 5 Apr 2022 16:58:31 +0000 (18:58 +0200)]
ASoC: sta*: use simple i2c probe function
The i2c probe functions here don't use the id information provided in
their second argument, so the single-parameter i2c probe function
("probe_new") can be used instead.
This avoids scanning the identifier tables during probes.
Stephen Kitt [Tue, 5 Apr 2022 16:58:30 +0000 (18:58 +0200)]
ASoC: pcm*: use simple i2c probe function
The i2c probe functions here don't use the id information provided in
their second argument, so the single-parameter i2c probe function
("probe_new") can be used instead.
This avoids scanning the identifier tables during probes.
Stephen Kitt [Tue, 5 Apr 2022 16:58:29 +0000 (18:58 +0200)]
ASoC: nau8*: use simple i2c probe function
The i2c probe functions here don't use the id information provided in
their second argument, so the single-parameter i2c probe function
("probe_new") can be used instead.
This avoids scanning the identifier tables during probes.
Stephen Kitt [Tue, 5 Apr 2022 16:58:28 +0000 (18:58 +0200)]
ASoC: ml26124: use simple i2c probe function
The i2c probe functions here don't use the id information provided in
their second argument, so the single-parameter i2c probe function
("probe_new") can be used instead.
This avoids scanning the identifier tables during probes.
Stephen Kitt [Tue, 5 Apr 2022 16:58:27 +0000 (18:58 +0200)]
ASoC: max9*: use simple i2c probe function
The i2c probe functions here don't use the id information provided in
their second argument, so the single-parameter i2c probe function
("probe_new") can be used instead.
This avoids scanning the identifier tables during probes.
Stephen Kitt [Tue, 5 Apr 2022 16:58:26 +0000 (18:58 +0200)]
ASoC: lm4857: use simple i2c probe function
The i2c probe functions here don't use the id information provided in
their second argument, so the single-parameter i2c probe function
("probe_new") can be used instead.
This avoids scanning the identifier tables during probes.
Stephen Kitt [Tue, 5 Apr 2022 16:58:25 +0000 (18:58 +0200)]
ASoC: es83*: use simple i2c probe function
The i2c probe functions here don't use the id information provided in
their second argument, so the single-parameter i2c probe function
("probe_new") can be used instead.
This avoids scanning the identifier tables during probes.
Stephen Kitt [Tue, 5 Apr 2022 16:58:24 +0000 (18:58 +0200)]
ASoC: cx2072x: use simple i2c probe function
The i2c probe functions here don't use the id information provided in
their second argument, so the single-parameter i2c probe function
("probe_new") can be used instead.
This avoids scanning the identifier tables during probes.
Stephen Kitt [Tue, 5 Apr 2022 16:58:23 +0000 (18:58 +0200)]
ASoC: ak4*: use simple i2c probe function
The i2c probe functions here don't use the id information provided in
their second argument, so the single-parameter i2c probe function
("probe_new") can be used instead.
This avoids scanning the identifier tables during probes.
ASoC: amd: Add driver data to acp6x machine driver
Currently all of the quirked systems use the same card and so the
DMI quirk list doesn't contain driver data.
Add driver data to these quirks and then check the data was present
or not. This will allow potentially setting quirks for systems with
faulty firmware that claims to have a DMIC but doesn't really.
Peter Ujfalusi [Tue, 5 Apr 2022 17:27:01 +0000 (10:27 -0700)]
ASoC: SOF: ipc: Separate the ops checks by functions/topics
Separate the mandatory ops checks by topics (pcm and topology for now) to
be able to provide intuitive feedback on the possible missing ops and to
make it easier to add new mandatory ops checks in the future.
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com> Reviewed-by: Daniel Baluta <daniel.baluta@nxp.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/20220405172708.122168-9-ranjani.sridharan@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
Peter Ujfalusi [Tue, 5 Apr 2022 17:26:58 +0000 (10:26 -0700)]
ASoC: SOF: ipc3: Implement the set_get_data IPC ops
Add the implementation for the set_get_data callback for handling large
data set and get.
The set_get_data() in IPC3 can be used only for component messages. The
function expects the caller to prepare the message behind the data pointer
for sending/receiving data. The callback only implements the needed code
to be able to split up a message if needed for transfer.
The set_get_data ops is based on the existing
snd_sof_ipc_set_get_comp_data() and sof_set_get_large_ctrl_data() but made
it generic entry point.
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com> Reviewed-by: Daniel Baluta <daniel.baluta@nxp.com> Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Reviewed-by: Bard Liao <yung-chuan.liao@linux.intel.com> Signed-off-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com> Link: https://lore.kernel.org/r/20220405172708.122168-6-ranjani.sridharan@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
Peter Ujfalusi [Tue, 5 Apr 2022 17:26:55 +0000 (10:26 -0700)]
ASoC: SOF: Add high level IPC IO callback definitions to ipc_ops
Add tx_msg(), rx_msg(), set_get_data() and get_reply() ops, which can
be used as a generic API for sending, receiving single messages and
to write and read large data.
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com> Reviewed-by: Daniel Baluta <daniel.baluta@nxp.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/20220405172708.122168-3-ranjani.sridharan@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
Peter Ujfalusi [Tue, 5 Apr 2022 17:26:54 +0000 (10:26 -0700)]
ASoC: SOF: Add helper function to prepare and send an IPC message
The new sof_ipc_send_msg() can be used by IPC dependent code to prepare
the ipc->msg for a new message transmission and then call in to platform
code to send the message.
Higher level code should be handling the completion and reply.
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com> Reviewed-by: Daniel Baluta <daniel.baluta@nxp.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/20220405172708.122168-2-ranjani.sridharan@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
Add support for using the rt5682s codec together with rt1015p on
mt8192-mt6359 machines. All configurations are shared with the rt5682
codec variant, so simply select the SND_SOC_RT5682S config to ensure the
codec is present and set the correct card name. The codec will be linked
to by pointing to it in the headset-codec property in the devicetree.
While at it, also create macros for the names of the different codec
variants supported by this driver, as well as rename occurrences of
rt1015p_rt5682 to rt1015p_rt5682x, since they are shared between rt5682
and rt5682s.
Signed-off-by: Jiaxin Yu <jiaxin.yu@mediatek.com> Reviewed-by: Tzung-Bi Shih <tzungbi@kernel.org> Reviewed-by: Nícolas F. R. A. Prado <nfraprado@collabora.com> Tested-by: Nícolas F. R. A. Prado <nfraprado@collabora.com> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Link: https://lore.kernel.org/r/20220408060552.26607-5-jiaxin.yu@mediatek.com Signed-off-by: Mark Brown <broonie@kernel.org>
ASoC: mediatek: mt8192: refactor for I2S8/I2S9 DAI links of headset
As part of the refactoring to allow the same machine driver to be used for
the rt1015(p) and rt5682(s) codecs on the MT8192 platform, parse the
rt5682(s) codec from the headset-codec property in the devicetree and wire
it to the I2S8 and I2S9 backends.
Signed-off-by: Jiaxin Yu <jiaxin.yu@mediatek.com> Reviewed-by: Tzung-Bi Shih <tzungbi@kernel.org> Reviewed-by: Nícolas F. R. A. Prado <nfraprado@collabora.com> Tested-by: Nícolas F. R. A. Prado <nfraprado@collabora.com> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Link: https://lore.kernel.org/r/20220408060552.26607-4-jiaxin.yu@mediatek.com Signed-off-by: Mark Brown <broonie@kernel.org>
ASoC: mediatek: mt8192: refactor for I2S3 DAI link of speaker
As part of the refactoring to allow the same machine driver to be used for
the rt1015(p) and rt5682(s) codecs on the MT8192 platform, parse the
rt1015(p) codecs from the speaker-codecs property in the devicetree and
wire them to the I2S3 backend, instead of hardcoding the links and
selecting through the compatible.
Signed-off-by: Jiaxin Yu <jiaxin.yu@mediatek.com> Reviewed-by: Tzung-Bi Shih <tzungbi@kernel.org> Reviewed-by: Nícolas F. R. A. Prado <nfraprado@collabora.com> Tested-by: Nícolas F. R. A. Prado <nfraprado@collabora.com> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Link: https://lore.kernel.org/r/20220408060552.26607-3-jiaxin.yu@mediatek.com Signed-off-by: Mark Brown <broonie@kernel.org>
ASoC: dt-bindings: mt8192-mt6359: add new compatible and new properties
1. Adds new compatible string "mt8192_mt6359_rt1015p_rt5682s" for machines
with rt1015p and rt5682s.
2. Adds new property "headset-codec" for getting headset codec.
3. Adds new property "speaker-codecs" for getting speaker codecs.
Signed-off-by: Jiaxin Yu <jiaxin.yu@mediatek.com> Reviewed-by: Rob Herring <robh@kernel.org> Reviewed-by: Nícolas F. R. A. Prado <nfraprado@collabora.com> Tested-by: Nícolas F. R. A. Prado <nfraprado@collabora.com> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Link: https://lore.kernel.org/r/20220408060552.26607-2-jiaxin.yu@mediatek.com Signed-off-by: Mark Brown <broonie@kernel.org>
Mark Brown [Fri, 8 Apr 2022 11:08:37 +0000 (12:08 +0100)]
Make headphone work on Huawei Matebook D15
Merge series from Mauro Carvalho Chehab <mchehab@kernel.org>:
Huawei Matebook D15 uses two different GPIOs are used to control the output:
- gpio0 controls the speaker output;
- gpio1 controls the headphone output.
Changing both at the same time cause spurious events that are mis-interpreted
as input events, causing troubles on apps. So, a delay is needed before turning
on such gpios.
Also, the headset microphone is connected to MIC1, instead of MIC2 port.
With this patch, plugging a headphone causes a jack event to trigger the speaker
supply, powering down the speaker and powering up the headphone output.
Removing the headphone also triggers the power supply, powering up the speaker
and powering down the headphone.
ASoC: Intel: sof_es8336: Add a quirk for Huawei Matebook D15
Based on experimental tests, Huawei Matebook D15 actually uses
both gpio0 and gpio1: the first one controls the speaker, while
the other one controls the headphone.
Also, the headset is mapped as MIC1, instead of MIC2.
Add mt8195 shutdown callback function implementation to ensure that
shutdown flow is called to shutdown dsp core, disable adsp clock, and
power off dsp sram correctly during reboot flow.
Signed-off-by: YC Hung <yc.hung@mediatek.com> Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com> Reviewed-by: Péter Ujfalusi <peter.ujfalusi@linux.intel.com> Link: https://lore.kernel.org/r/20220406194048.289787-3-pierre-louis.bossart@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
ASoC: codecs: wcd934x: do not switch off SIDO Buck when codec is in use
SIDO(Single-Inductor Dual-Ouput) Buck powers up both analog and digital
circuits along with internal memory, powering off this is the last thing
that codec should do when going to very low power.
Current code was powering off this Buck if there are no users of sysclk,
which is not correct. Powering off this buck will result in no register access.
This code path was never tested until recently after adding pm support
in SoundWire controller. Fix this by removing the buck poweroff when the
codec is active and also the code that is not used.
Without this patch all the read/write transactions will never complete and
results in SLIMBus Errors like:
qcom,slim-ngd qcom,slim-ngd.1: Tx:MT:0x0, MC:0x60, LA:0xcf failed:-110
wcd934x-codec wcd934x-codec.1.auto: ASoC: error at soc_component_read_no_lock
on wcd934x-codec.1.auto for register: [0x00000d05] -110
qcom,slim-ngd-ctrl 171c0000.slim: Error Interrupt received 0x82000000
Reported-by: Amit Pundir <amit.pundir@linaro.org> Fixes: a61f3b4f476e ("ASoC: wcd934x: add support to wcd9340/wcd9341 codec") Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Tested-by: Amit Pundir <amit.pundir@linaro.org> Link: https://lore.kernel.org/r/20220407094313.2880-1-srinivas.kandagatla@linaro.org Signed-off-by: Mark Brown <broonie@kernel.org>
ASoC: SOF: topology: cleanup dailinks on widget unload
We set the cpu_dai capture_ or playback_widget on widget_ready but
never clear them, which leads to failures when unloading/reloading a
topology in modprobe/rmmod tests
ASoC: rt711/5682: check if bus is active before deferred jack detection
This patch takes a defensive programming and paranoid approach in case
the parent device (SoundWire) is pm_runtime resumed but the rt711
device is not. In that case, during the attachment and initialization,
a jack detection workqueue can be scheduled. Since the pm_runtime
suspend routines will not be invoked, the sequence to cancel all
deferred work is not executed, and the jack detection could happen
after the bus stops operating, leading to a timeout.
This patch applies the same solution to rt5682, based on the
similarities between codec drivers. The race condition with rt5682 was
not detected experimentally though.
Stephen Kitt [Tue, 5 Apr 2022 17:39:52 +0000 (19:39 +0200)]
ASoC: wm8731: use simple i2c probe function
The i2c probe functions here don't use the id information provided in
their second argument, so the single-parameter i2c probe function
("probe_new") can be used instead.
This avoids scanning the identifier tables during probes.
Stephen Kitt [Tue, 5 Apr 2022 16:40:31 +0000 (18:40 +0200)]
ASoC: sgtl5000: use simple i2c probe function
The i2c probe functions here don't use the id information provided in
their second argument, so the single-parameter i2c probe function
("probe_new") can be used instead.
This avoids scanning the identifier tables during probes.
Stephen Kitt [Tue, 5 Apr 2022 17:11:58 +0000 (19:11 +0200)]
ASoC: rt1016: enable building
The rt1016 driver wasn't listed in Kconfig and Makefile, which AFAICT
means it isn't ever built. This patch adds the appropriate entries to
Kconfig and Makefile.
Stephen Kitt [Tue, 5 Apr 2022 16:36:18 +0000 (18:36 +0200)]
ASoC: pcm3060: use simple i2c probe function
The i2c probe functions here don't use the id information provided in
their second argument, so the single-parameter i2c probe function
("probe_new") can be used instead.
This avoids scanning the identifier tables during probes.
Stephen Kitt [Tue, 5 Apr 2022 13:03:26 +0000 (15:03 +0200)]
ASoC: rt*: use simple i2c probe function
The i2c probe functions here don't use the id information provided in
their second argument, so the single-parameter i2c probe function
("probe_new") can be used instead.
This avoids scanning the identifier tables during probes.
Stephen Kitt [Tue, 5 Apr 2022 16:34:00 +0000 (18:34 +0200)]
ASoC: tscs*: use simple i2c probe function
The i2c probe functions here don't use the id information provided in
their second argument, so the single-parameter i2c probe function
("probe_new") can be used instead.
This avoids scanning the identifier tables during probes.
Stephen Kitt [Tue, 5 Apr 2022 12:24:11 +0000 (14:24 +0200)]
ASoC: wm*: use simple i2c probe function
The i2c probe functions here don't use the id information provided in
their second argument, so the single-parameter i2c probe function
("probe_new") can be used instead.
wm8731.c is excluded and will be submitted separately.
This avoids scanning the identifier tables during probes.
Stephen Kitt [Tue, 5 Apr 2022 16:35:33 +0000 (18:35 +0200)]
ASoC: lm49xxx: use simple i2c probe function
The i2c probe functions here don't use the id information provided in
their second argument, so the single-parameter i2c probe function
("probe_new") can be used instead.
This avoids scanning the identifier tables during probes.
Stephen Kitt [Tue, 5 Apr 2022 16:37:50 +0000 (18:37 +0200)]
ASoC: mt6660: use simple i2c probe function
The i2c probe functions here don't use the id information provided in
their second argument, so the single-parameter i2c probe function
("probe_new") can be used instead.
This avoids scanning the identifier tables during probes.
Mark Brown [Wed, 6 Apr 2022 22:37:26 +0000 (23:37 +0100)]
ASoC: ak4613: add TDM256 test support
Merge series from Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>:
Renesas is the only user of ak4613 driver on upstream for now.
It has STEREO/TDM512/TDM256/TDM128 mode, but STEREO only is used,
because of Renesas board connection.
I noticed that I can test first 2ch out of TDM256 mode 8ch
Playback even in such a situation.
Ajye Huang [Thu, 24 Mar 2022 08:47:08 +0000 (16:47 +0800)]
ASoC: Intel: sof_rt5682: Add support for max98360a speaker amp on SSP2
Follow Intel's design to replace max98360a amp SSP2 reather than SSP1
by judging DMI_OEM_STRING in sof_rt5682_quirk_table struct.
And reusing max98357's topology since DAI setting could be leveraged.
Ahmad Fatoum [Tue, 5 Apr 2022 15:57:31 +0000 (17:57 +0200)]
ASoC: fsl_sai: fix 1:1 bclk:mclk ratio support
Refactoring in commit a50b7926d015 ("ASoC: fsl_sai: implement 1:1
bclk:mclk ratio support") led to the bypass never happening
as (ratio = 1) was caught in the existing if (ratio & 1) continue;
check. The correct check sequence instead is:
- skip all ratios lower than one and higher than 512
- skip all odd ratios except for 1:1
- skip 1:1 ratio if and only if !support_1_1_ratio
And for all others, calculate the appropriate divider. Adjust the
code to facilitate this.
Fixes: a50b7926d015 ("ASoC: fsl_sai: implement 1:1 bclk:mclk ratio support") Signed-off-by: Ahmad Fatoum <a.fatoum@pengutronix.de> Acked-by: Shengjiu Wang <shengjiu.wang@gmail.com> Reviewed-by: Sascha Hauer <s.hauer@pengutronix.de> Link: https://lore.kernel.org/r/20220405155731.745413-1-a.fatoum@pengutronix.de Signed-off-by: Mark Brown <broonie@kernel.org>
ASoC: simple-card-utils: Avoid NULL deref in asoc_simple_set_tdm()
Don't dereference simple_dai before it has been checked for NULL.
Signed-off-by: Richard Fitzgerald <rf@opensource.cirrus.com> Fixes: 1e974e5b82b3 ("ASoC: audio_graph_card2: Add support for variable slot widths") Reported-by: kernel test robot <lkp@intel.com> Reported-by: Dan Carpenter <dan.carpenter@oracle.com> Link: https://lore.kernel.org/r/20220404113252.1152659-1-rf@opensource.cirrus.com Signed-off-by: Mark Brown <broonie@kernel.org>
Merge series from Heiner Kallweit <hkallweit1@gmail.com>:
On a S905W-based system I get the following error:
debugfs: Directory 'c1105400.audio-controller' with parent 'P230-Q200' already present!
Turned out that multiple components having the same name triggers this
error in soc_init_component_debugfs(). The proposed solution allows
other drivers to adopt the same approach with minimal effort.
With the patch the error is gone and that's the debugfs entries.
On a S905W-based system I get the following error:
debugfs: Directory 'c1105400.audio-controller' with parent 'P230-Q200' already present!
Turned out that multiple components having the same name triggers this
error in soc_init_component_debugfs(). With the patch the error is gone
and that's the debugfs entries.
Heiner Kallweit [Wed, 9 Mar 2022 20:21:55 +0000 (21:21 +0100)]
ASoC: soc-core: add debugfs_prefix member to snd_soc_component_driver
Allow the component debugfs_prefix to be set from
snd_soc_component_driver. First use case is avoiding a duplicate
debugfs entry error in case a device has multiple components
which have the same name therefore.
Note that we don't set component->debugfs_prefix if it's set already.
That's needed because partially component->debugfs_prefix is set
before calling snd_soc_component_initialize().
ASoC: dt-bindings: lpass-cpu: Update clocks and power domain names for sc7280 platform
Update required clock-names used for MI2S primary path, VA macro's
codec memory path and HDMI path in sc7280 based platforms.
Update power domain names required for sc7280 platforms.
ASoC: qcom: dt-bindings: Update bindings for clocks in lpass digital codes
Update dt-bindings for clocks as per ADSP bypass solutions, in which macro
dcodec GDSCs are enabled using power domains in lpass digital codec drivers.
Signed-off-by: Srinivasa Rao Mandadapu <quic_srivasam@quicinc.com> Co-developed-by: Venkata Prasad Potturu <quic_potturu@quicinc.com> Signed-off-by: Venkata Prasad Potturu <quic_potturu@quicinc.com> Reviewed-by: Rob Herring <robh@kernel.org> Link: https://lore.kernel.org/r/1647852981-27895-2-git-send-email-quic_srivasam@quicinc.com Signed-off-by: Mark Brown <broonie@kernel.org>
AK4613 has STEREO/TDM512/TDM256/TDM128 mode.
Renesas is the only user of ak4613 on upstream for now,
and is using it as STEREO mode, because of board connection.
Thus, current driver is supporting STEREO mode only, and other
modes are not supported.
But I noticed that I can try first 2ch out of TDM256 mode 8ch
Playback even in such a situation.
But because of board connection, I can't test full TDM256 mode,
and/or other TDM mode. Thus I don't want to add new DT propaty for now.
This patch enables TDM256 mode test by "ifdef style",
but it has no effect to current supported STEREO mode.
You can define AK4613_ENABLE_TDM_TEST to try TDM256 mode.
Please don't hesitate to break current code if you can add full TDM256
and/or other TDM mode. You don't need to care compatibility with Renesas.