- 10 Nov, 2022 1 commit
-
-
Mark Brown authored
Merge series from Nícolas F. R. A. Prado <nfraprado@collabora.com>: Some ASoC machine drivers for MediaTek platforms were not being registered to the module device table, preventing them to be automatically loaded when built as modules. This series adds the missing registration to the drivers.
-
- 09 Nov, 2022 9 commits
-
-
Nícolas F. R. A. Prado authored
Register the compatibles for this module on the module device table so it can be automatically loaded when a matching device is found on the system. Signed-off-by:
Nícolas F. R. A. Prado <nfraprado@collabora.com> Reviewed-by:
AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Tested-by:
Chen-Yu Tsai <wenst@chromium.org> Reviewed-by:
Mark Brown <broonie@kernel.org>
-
Nícolas F. R. A. Prado authored
Register the compatibles for this module on the module device table so it can be automatically loaded when a matching device is found on the system. Signed-off-by:
-
Nícolas F. R. A. Prado authored
Register the compatibles for this module on the module device table so it can be automatically loaded when a matching device is found on the system. Signed-off-by:
-
Nícolas F. R. A. Prado authored
Register the compatibles for this module on the module device table so it can be automatically loaded when a matching device is found on the system. Signed-off-by:
-
Nícolas F. R. A. Prado authored
Register the compatibles for this module on the module device table so it can be automatically loaded when a matching device is found on the system. Reviewed-by:
-
Nícolas F. R. A. Prado authored
Register the compatibles for this module on the module device table so it can be automatically loaded when a matching device is found on the system. Reviewed-by:
-
Nícolas F. R. A. Prado authored
Register the compatibles for this module on the module device table so it can be automatically loaded when a matching device is found on the system. Signed-off-by:
-
Nícolas F. R. A. Prado authored
Register the compatibles for this module on the module device table so it can be automatically loaded when a matching device is found on the system. Signed-off-by:
-
Nícolas F. R. A. Prado authored
Register the compatibles for this module on the module device table so it can be automatically loaded when a matching device is found on the system. Signed-off-by:
-
- 07 Nov, 2022 4 commits
-
-
Kai Vehmanen authored
The data received via iccmax stream is not used anywhere, so no need to allocate a big DMA buffer for it. This is especially important as the allocation is done even in cases where reload of the firmware is skipped and execution happens directly from the firmware stored in IMR. Signed-off-by:
Kai Vehmanen <kai.vehmanen@linux.intel.com> Reviewed-by:
Péter Ujfalusi <peter.ujfalusi@linux.intel.com> Reviewed-by:
Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Reviewed-by:
Ranjani Sridharan <ranjani.sridharan@linux.intel.com> Signed-off-by:
-
Peter Ujfalusi authored
During system suspend there is a chance that the running stream undergo an xrun and instead of the expected SNDRV_PCM_TRIGGER_SUSPEND trigger we will receive SNDRV_PCM_TRIGGER_STOP. The handling of SUSPEND and STOP triggers differ that case of the later the sof_pcm_stream_free() will be called with free_widget_list = false. But we must make sure that all active widgets and streams are free before entering suspend in order to be able to resume without error. We can utilize the tear_down_all_pipelines to put the system to an expected state and to fix the suspend/resume error. Signed-off-by:
Bard Liao <yung-chuan.liao@linux.intel.com> Link: https://lore.kernel.org/r/20221107084158.26629-1-peter.ujfalusi@linux.intel.comSigned-off-by:
-
Nícolas F. R. A. Prado authored
Register the compatibles for this module on the module device table so it can be automatically loaded when a matching device is found on the system. Signed-off-by:
-
Nícolas F. R. A. Prado authored
Register the compatibles for this module on the module device table so it can be automatically loaded when a matching device is found on the system. Signed-off-by:
-
- 04 Nov, 2022 1 commit
-
-
syed saba kareem authored
Pink Sardine is based on ACP6.3 architecture. This patch fixes the typo mistake acp6.2 -> acp6.3 Signed-off-by:
syed saba kareem <syed.sabakareem@amd.com> Link: https://lore.kernel.org/r/20221104121001.207992-1-Syed.SabaKareem@amd.comSigned-off-by:
-
- 03 Nov, 2022 8 commits
-
-
Mark Brown authored
Merge series from Ajye Huang <ajye_huang@compal.corp-partner.google.com>: Support selecting between front and rear microphones on some of the MediaTek platforms.
-
Colin Ian King authored
Don't populate the read-only const array uid_strings on the stack but instead make it static. Also makes the object code a little smaller. Signed-off-by:
Colin Ian King <colin.i.king@gmail.com> Link: https://lore.kernel.org/r/20221103120624.72583-1-colin.i.king@gmail.comSigned-off-by:
-
Maarten Zanders authored
During initialisation DAPM tries to read the state of the MUX being connected, resulting in this error log: input-mux: ASoC: error at soc_component_read_no_lock on input-mux: -5 Provide a read function which allows DAPM to read the state of the MUX. Signed-off-by:
Maarten Zanders <maarten.zanders@mind.be> Link: https://lore.kernel.org/r/20221028191303.166115-1-maarten.zanders@mind.beSigned-off-by:
-
Dmitry Torokhov authored
Switch the driver from legacy gpio API that is deprecated to the newer gpiod API that respects line polarities described in ACPI/DT. The driver still tries to support shared reset lines, by first trying to allocate the reset GPIO normally, and then non-exclusively, although the utility of such support is questionable, toggling reset line from one driver/instance will result in all chips being reset, potentially at an inopportune moment. Note that this change depends on commit fbbbcd17 ("gpiolib: of: add quirk for locating reset lines with legacy bindings") to translate request for "reset" GPIO to the legacy name "gpio-reset" in case when proper name is not used. Signed-off-by:
Dmitry Torokhov <dmitry.torokhov@gmail.com> Link: https://lore.kernel.org/r/20221102232004.1721864-3-dmitry.torokhov@gmail.comSigned-off-by:
-
Dmitry Torokhov authored
Signed-off-by:
-
Dmitry Torokhov authored
As of 0426370b ("ARM: dts: omap2420-n810: Correct the audio codec (tlv320aic33) node") the DTS properly specifies reset GPIO, and the device name in auxdata lookup table does not even match the one in device tree anymore, so stop instantiating it. Signed-off-by:
Tony Lindgren <tony@atomide.com> Link: https://lore.kernel.org/r/20221102232004.1721864-1-dmitry.torokhov@gmail.comSigned-off-by:
-
Ajye Huang authored
Having two DMICs, a front DMIC and a Rear DMIC, but only host audio input AUX port0 is used for these two Dmics. A "dmic-gpios" property is used for a mixer control to switch the dmic signal source between the Front and Rear Dmic. Refer to this one as an example, commit 3cfbf07c ("ASoC: qcom: sc7180: Modify machine driver for 2mic") Signed-off-by:
Ajye Huang <ajye_huang@compal.corp-partner.google.com> Reviewed-by:
-
Ajye Huang authored
Add a property "dmic-gpios" for switching between two MICs. Signed-off-by:
-
- 02 Nov, 2022 2 commits
-
-
Yang Yingliang authored
If snd_hdac_device_register() fails, 'codec' and name allocated in dev_set_name() called in snd_hdac_device_init() are leaked. Fix this by calling put_device(), so they can be freed in snd_hda_codec_dev_release() and kobject_cleanup(). Fixes: 829c6731 ("ASoC: SOF: Intel: Introduce HDA codec init and exit routines") Fixes: dfe66a18 ("ALSA: hdac_ext: add extended HDA bus") Suggested-by:
Cezary Rojewski <cezary.rojewski@intel.com> Signed-off-by:
Yang Yingliang <yangyingliang@huawei.com> Reviewed-by:
-
Yang Yingliang authored
If snd_hdac_device_register() fails, 'codec' and name allocated in dev_set_name() called in snd_hdac_device_init() are leaked. Fix this by calling put_device(), so they can be freed in snd_hda_codec_dev_release() and kobject_cleanup(). Fixes: e4746d94 ("ASoC: Intel: Skylake: Introduce HDA codec init and exit routines") Fixes: dfe66a18 ("ALSA: hdac_ext: add extended HDA bus") Suggested-by:
-
- 01 Nov, 2022 5 commits
-
-
Mark Brown authored
Merge series from Chancel Liu <chancel.liu@nxp.com>: This patchset supports MICFIL on i.MX93 platform.
-
Chancel Liu authored
On i.MX93 platform MICFIL uses eDMA. The maxburst should be set to the number of channels in eDMA multiple FIFO mode. Signed-off-by:
Chancel Liu <chancel.liu@nxp.com> Acked-by:
Shengjiu Wang <shengjiu.wang@gmail.com> Link: https://lore.kernel.org/r/20221028082750.991822-4-chancel.liu@nxp.comSigned-off-by:
-
Chancel Liu authored
Add compatible string and specific soc data to support MICFIL on i.MX93 platform. Signed-off-by:
-
Chancel Liu authored
Add compatible string "fsl,imx93-micfil" for i.MX93 platform Signed-off-by:
Rob Herring <robh@kernel.org> Link: https://lore.kernel.org/r/20221028082750.991822-2-chancel.liu@nxp.comSigned-off-by:
-
Peter Bergin authored
When trying to connect the device with the driver through device-tree it is not working. The of_device_id is defined in cs42xx8.c but is not correctly included in cs42xx8-i2c.c. Move of_device_id table to cs42xx8-i2c.c. Get cs42xx8_driver_data in cs42xx8_i2c_probe() and pass as argument to cs42xx8_probe(). Move error check if no driver data found to cs42xx8_i2c_probe(). Signed-off-by:
Peter Bergin <peter@berginkonsult.se> Acked-by:
Charles Keepax <ckeepax@opensource.cirrus.com> Link: https://lore.kernel.org/r/20221031203723.168177-1-peter@berginkonsult.seSigned-off-by:
-
- 31 Oct, 2022 10 commits
-
-
Pierre-Louis Bossart authored
Replace them with read8/write8 to avoid compilation issue on ARM. In hindsight this is more consistent with the read64/write64 helpers already used in SOF. Reported-by:
Nathan Chancellor <nathan@kernel.org> Link: https://lore.kernel.org/alsa-devel/Y1rTFrohLqaiZAy%2F@dev-arch.thelio-3990X/Signed-off-by:
-
Mark Brown authored
Merge series from Aidan MacDonald <aidanmacdonald.0x0@gmail.com>: A quick series to get rid of .set_sysclk() from jz4740-i2s. It wasn't used in practice so this shouldn't be troublesome for anyone, and fortunately there aren't any backward compatibility concerns. The actual rationale for removing it, as opposed to fixing the issues of the current DT bindings and implementation, is provided in the dt-bindings patch.
-
Mark Brown authored
Merge series from Peter Ujfalusi <peter.ujfalusi@linux.intel.com>: The probes (the ability of probing the audio data from firmware processing points or to receive stream of debug/trace information) is supported by IPC4 as well, but due to the differences between the two IPC version the low level setup and information we need for probing is different. This series will extend the existing probes support for IPC3 with IPC4 'backend'
-
Chen Zhongjin authored
snd_soc_util_exit() is called in __init snd_soc_init() for cleanup. Remove the __exit annotation for it to fix the build warning: WARNING: modpost: sound/soc/snd-soc-core.o: section mismatch in reference: init_module (section: .init.text) -> snd_soc_util_exit (section: .exit.text) Fixes: 6ec27c53 ("ASoC: core: Fix use-after-free in snd_soc_exit()") Signed-off-by:
Chen Zhongjin <chenzhongjin@huawei.com> Link: https://lore.kernel.org/r/20221031134031.256511-1-chenzhongjin@huawei.comSigned-off-by:
-
Jyri Sarha authored
Implement IPC operations for IPC4 messaging and add doxygen documentation for the functions. Signed-off-by:
Jyri Sarha <jyri.sarha@intel.com> Reviewed-by:
-
Jyri Sarha authored
Add sof_client_ipc4_find_module() for calling sof_ipc4_find_module_by_uuid() in sof client code. Signed-off-by:
-
Jyri Sarha authored
No need to duplicate set_get_data msg handling in clients. Signed-off-by:
-
Jyri Sarha authored
Declare an IPC ops struct for probes client device and move IPC3 functions behind it. Signed-off-by:
-
Jyri Sarha authored
Replace probes related [0] arrays, all found within unions, with DECLARE_FLEX_ARRAY() declarations. Signed-off-by:
-
Aidan MacDonald authored
The AIC needs only the first two clocks: "aic" is a gate that's used for gating the I2S controller when it's suspended, and "i2s" is the system clock, from which the bit and frame clocks are derived. Both clocks are therefore reasonably part of the AIC and should be passed to the OS. But the "ext" and "pll half" clocks are a little more questionable. It appears these bindings were introduced when the schema was first converted to YAML, but weren't present in the original .txt binding. They are intended to be the possible parent clocks of "i2s". The JZ4770 actually has three parents for its "i2s" clock, named "ext", "pll0", and "pll1" in the Linux driver. The JZ4780 has two parents but it doesn't have a "pll half" clock, instead it has an "i2s_pll" clock which behaves much differently to the actual "pll half" clock found on the JZ4740 & JZ4760. And there are other Ingenic SoCs that share the JZ4780's clock layout, eg, the X1000. Therefore, the bindings aren't really adequate for the JZ4770 and a bit misleading for the JZ4780. Either we should fix the bindings, or remove them entirely. This patch opts to remove the bindings. There is a good case to be made that "ext" and "pll half" don't belong here because they aren't directly used by the AIC. They are only used to set the parent of the "i2s" clock; they have no other effect on the AIC. A good way to think of it is in terms of how the AIC constrains clocks. The AIC can only generate the bit & frame clocks from the system clock in certain ratios. Setting the sample rate effectively constrains the frame clock, which, because of the clock dividers controlled by the AIC, translates to constraints on the "i2s" clock. Nothing in the AIC imposes a direct constraint on the parents of the "i2s" clock, and the AIC does not need to enable or disable the parents directly, so in principle the AIC doesn't need to be aware of the parent clocks at all. The choice of parent clock is still important, but the AIC doesn't have enough information to apply such constraints itself. The sound card does have that information because it knows how the AIC is connected to other components. We need to use other DT mechanisms to communicate those constraints at the sound card level, instead of passing the clocks through to the AIC, and inventing ad-hoc ways to plumb the constraints around behind the scenes. Signed-off-by:
Aidan MacDonald <aidanmacdonald.0x0@gmail.com> Acked-by:
Paul Cercueil <paul@crapouillou.net> Link: https://lore.kernel.org/r/20221028103418.17578-2-aidanmacdonald.0x0@gmail.comSigned-off-by:
-
