- 11 Apr, 2022 14 commits
-
-
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 <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-15-ranjani.sridharan@linux.intel.comSigned-off-by:
Mark Brown <broonie@kernel.org>
-
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 12 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:
-
Srinivas Kandagatla authored
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: a61f3b4f ("ASoC: wcd934x: add support to wcd9340/wcd9341 codec") Signed-off-by:
Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Tested-by:
-
Yu Liao authored
scontrol doesn't get freed when kstrdup returns NULL. Fix by free iscontrol in that case. scontrol = kzalloc(sizeof(*scontrol), GFP_KERNEL); if (!scontrol) return -ENOMEM; scontrol->name = kstrdup(hdr->name, GFP_KERNEL); if (!scontrol->name) return -ENOMEM; Signed-off-by:Yu Liao <liaoyu15@huawei.com> Link: https://lore.kernel.org/r/20220318021616.2599630-1-liaoyu15@huawei.comSigned-off-by:
-
Pierre-Louis Bossart authored
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 BugLink: https://github.com/thesofproject/linux/issues/3535 Fixes: 311ce4fe ("ASoC: SOF: Add support for loading topologies") Signed-off-by:
-
Pierre-Louis Bossart authored
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. BugLink: https://github.com/thesofproject/linux/issues/3459Signed-off-by:
Rander Wang <rander.wang@intel.com> Reviewed-by:
-
- 06 Apr, 2022 4 commits
-
-
Stephen Kitt authored
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. Signed-off-by:Stephen Kitt <steve@sk2.org> Acked-by:
Charles Keepax <ckeepax@opensource.cirrus.com> Link: https://lore.kernel.org/r/20220405173952.2180743-1-steve@sk2.orgSigned-off-by:
-
Stephen Kitt authored
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. Signed-off-by:Fabio Estevam <festevam@gmail.com> Link: https://lore.kernel.org/r/20220405164031.2160888-1-steve@sk2.orgSigned-off-by:
-
Stephen Kitt authored
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. Signed-off-by:
-
Stephen Kitt authored
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. Signed-off-by:
-
