- 12 Apr, 2022 2 commits
-
-
Mark Brown authored
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 sound/soc/sof/ipc.c | 858 ++--------------------------------- sound/soc/sof/ipc3-control.c | 131 +++++- sound/soc/sof/ipc3.c | 682 +++++++++++++++++++++++++++- sound/soc/sof/sof-audio.c | 54 +-- sound/soc/sof/sof-audio.h | 7 +- sound/soc/sof/sof-priv.h | 28 +- 6 files changed, 880 insertions(+), 880 deletions(-) -- 2.25.1 -
Mark Brown authored
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.
-
- 11 Apr, 2022 20 commits
-
-
Richard Fitzgerald authored
Use the new EXPORT_SYMBOL_NS_GPL() for exports from the set of drivers for cs35l45. Signed-off-by:
Richard Fitzgerald <rf@opensource.cirrus.com> Link: https://lore.kernel.org/r/20220411165929.1302333-1-rf@opensource.cirrus.comSigned-off-by:
Mark Brown <broonie@kernel.org>
-
YueHaibing authored
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: a2df8c2d ("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.comSigned-off-by:
-
Vijendar Mukunda authored
Update PCI revision id check for the new YC platform varaint. Signed-off-by:
Vijendar Mukunda <Vijendar.Mukunda@amd.com> Link: https://lore.kernel.org/r/20220411134119.1767646-1-Vijendar.Mukunda@amd.comSigned-off-by:
-
Mario Limonciello authored
Currently the acp6x machine driver requires a hardcoded list of systems that physically have DMIC connected. To avoid having to continually add to an evergrowing list of systems add support for a _DSD that can advertise this. OEMs can add this _DSD to their BIOS under the ACP device to automatically add the device to this driver without requiring any driver modifications. Signed-off-by:
Mario Limonciello <mario.limonciello@amd.com> Link: https://lore.kernel.org/r/20220411134532.13538-3-mario.limonciello@amd.comSigned-off-by:
-
Mario Limonciello authored
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. Signed-off-by:
-
Peter Ujfalusi authored
The snd_sof_ipc_set_get_comp_data() only used for kcontrol data update and it is an IPC3 message parsing function. Move it out from the generic ipc.c to ipc3-control.c and rename it to better describe it's function. 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-16-ranjani.sridharan@linux.intel.comSigned-off-by:
-
Peter Ujfalusi authored
Remove the local implementation and switch to the IPC neutral ops to set up the kcontrols associated with the swidget. The set up call uses snd_sof_ipc_set_get_comp_data() which is largely an IPC3 parsing function. Signed-off-by:
-
Peter Ujfalusi authored
Define and set the widget_kcontrol_setup control IPC ops for IPC3. The widget_kcontrol_setup callback can be used to set up all kcontrols associated with the swidget. Signed-off-by:
-
Peter Ujfalusi authored
Use the new ops for handling message reception. Signed-off-by:
-
Peter Ujfalusi authored
Use the new ops for sending messages and to handle large component data set get operation. Signed-off-by:
-
Peter Ujfalusi authored
Use the get_reply ops to allow IPC dependent handling of the reply message. Signed-off-by:
-
Peter Ujfalusi authored
Make sure that the mandatory IPC message handling ops are provided by the IPC implementation. Signed-off-by:
-
Peter Ujfalusi authored
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 authored
Add the implementation for the rx_msg callback to handle message reception for IPC3. The implementation is equivalent to the currently used code in ipc.c Signed-off-by:
-
Peter Ujfalusi authored
Add the implementation for the get_reply callback to copy the reply message from mailbox to msg->reply_data buffer. The implementation is equivalent to the currently used code in ipc.c Signed-off-by:
-
Peter Ujfalusi authored
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:
Bard Liao <yung-chuan.liao@linux.intel.com> Signed-off-by:
-
Peter Ujfalusi authored
Instead of using sof_ipc_tx_message() for sending message, use the sof_ipc3_tx_msg() directly within ipc3.c Signed-off-by:
-
Peter Ujfalusi authored
Add the implementation for the IPC3 tx_msg callback for sending a single IPC message. The implementation is equivalent to the currently used code in ipc.c Signed-off-by:
-
Peter Ujfalusi authored
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 authored
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:
-
- 08 Apr, 2022 10 commits
-
-
Raphael-Xu authored
update tas27xx.yaml to support either TAS2764 or TAS2780 Signed-off-by:
Raphael-Xu <13691752556@139.com> Link: https://lore.kernel.org/r/20220408141119.958-2-13691752556@139.comSigned-off-by:
-
Raphael-Xu authored
rename tas2764.yaml to tas27xx.yaml Signed-off-by:
-
Mark Brown authored
Merge series from Jiaxin Yu <jiaxin.yu@mediatek.com>: The series reuses mt8192-mt6359-rt1015-rt5682.c for supporting machine driver with rt1015p speaker amplifier and rt5682s headset codec.
-
Lv Ruyi authored
Fix the following coccicheck review: ./sound/soc/mediatek/mt8195/mt8195-mt6359.c:1657:1-2: mt8195_mt6359_dt_match is not NULL terminated at line 1657 Fixes: 86a6b9c9 ("ASoC: mediatek: mt8195: add machine support for max98390 and rt5682") Reported-by:
Zeal Robot <zealci@zte.com.cn> Signed-off-by:
Lv Ruyi <lv.ruyi@zte.com.cn> Link: https://lore.kernel.org/r/20220408100309.2495462-1-lv.ruyi@zte.com.cnSigned-off-by:
-
Mark Brown authored
Pull in wm8731 fix. Signed-off-by: -
Jiaxin Yu authored
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:
AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Link: https://lore.kernel.org/r/20220408060552.26607-5-jiaxin.yu@mediatek.comSigned-off-by:
-
Jiaxin Yu authored
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 authored
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 authored
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:
Rob Herring <robh@kernel.org> Reviewed-by:
-
Mark Brown authored
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. The headset microphone also works.
-
- 07 Apr, 2022 8 commits
-
-
Mauro Carvalho Chehab authored
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. So, add a quirk for it. Signed-off-by:
Mauro Carvalho Chehab <mchehab@kernel.org> Acked-by:
-
Mauro Carvalho Chehab authored
The headset/internal mic can either be routed as mic1/mic2 or vice-versa. By default, the driver assumes that the headset is mapped as mic2, but not all devices map this way. So, add a quirk to support changing it to mic1, using mic2 for the internal analog mic (if any). Signed-off-by:
-
Mauro Carvalho Chehab authored
Some devices may use both gpio0 and gpio1 to independently switch the speaker and the headphone. Add support for that. Acked-by:
Hans de Goede <hdegoede@redhat.com> Signed-off-by:
-
Pierre-Louis Bossart authored
In preparation for the support of an additional gpio for headphone control, rename GPIOs to make explicit references to speakers and gpio0 or gpio1. No functionality change. Signed-off-by:
-
YC Hung authored
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:
-
YC Hung authored
Add shutdown callback function for SOF OF device and call snd_sof_device_shutdown in sof_of_shutdown callback for DSP shutdown sequence. Signed-off-by:
-
Zheyu Ma authored
When the driver fails during probing, the driver should disable the regulator, not just handle it in wm8731_hw_init(). The following log reveals it: [ 17.812483] WARNING: CPU: 1 PID: 364 at drivers/regulator/core.c:2257 _regulator_put+0x3ec/0x4e0 [ 17.815958] RIP: 0010:_regulator_put+0x3ec/0x4e0 [ 17.824467] Call Trace: [ 17.824774] <TASK> [ 17.825040] regulator_bulk_free+0x82/0xe0 [ 17.825514] devres_release_group+0x319/0x3d0 [ 17.825882] i2c_device_probe+0x766/0x940 [ 17.829198] i2c_register_driver+0xb5/0x130 Signed-off-by:
Zheyu Ma <zheyuma97@gmail.com> Link: https://lore.kernel.org/r/20220405121038.4094051-1-zheyuma97@gmail.comSigned-off-by:
-
Chao Song authored
The left speaker of max98373 uses spk_r_endpoint, and right speaker uses spk_l_endpoint, this is obviously wrong. This patch corrects the endpoints for max98373 codec. Signed-off-by:
Chao Song <chao.song@linux.intel.com> Signed-off-by:
-
