- 14 Sep, 2023 2 commits
-
-
Peter Ujfalusi authored
Move the out label to dump the message payload when the IPC message fails. The payload contains important information on what might have caused the error in firmware. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com> Reviewed-by: Bard Liao <yung-chuan.liao@linux.intel.com> Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Link: https://lore.kernel.org/r/20230914125115.30904-1-peter.ujfalusi@linux.intel.comSigned-off-by: Mark Brown <broonie@kernel.org>
-
Peter Ujfalusi authored
New code uses ENOTSUPP as per checkpatch recommendation: ENOTSUPP is not a SUSV4 error code, prefer EOPNOTSUPP Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com> Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Reviewed-by: Rander Wang <rander.wang@intel.com> Link: https://lore.kernel.org/r/20230914124943.24399-1-peter.ujfalusi@linux.intel.comSigned-off-by: Mark Brown <broonie@kernel.org>
-
- 13 Sep, 2023 4 commits
-
-
Marian Postevca authored
Fix prototype missing warning for acp3x_es83xx_init_ops() by including the header acp3x-es83xx.h Reported-by: kernel test robot <lkp@intel.com> Closes: https://lore.kernel.org/oe-kbuild-all/202309111220.g63yHDfH-lkp@intel.com/Signed-off-by: Marian Postevca <posteuca@mutex.one> Link: https://lore.kernel.org/r/20230913210916.2523-1-posteuca@mutex.oneSigned-off-by: Mark Brown <broonie@kernel.org>
-
Mark Brown authored
Merge series from Richard Fitzgerald <rf@opensource.cirrus.com>: The PCI device registers contain a subsystem ID (SSID), that is separate from the silicon ID. The PCI specification defines it thus: "They provide a mechanism for board vendors to distiguish their boards from one another even thought the boards may have the same PCI controller on them." This allows the driver for the silicon part to apply board-speficic settings based on this SSID. The CS35L56 driver uses this to select the correct firmware file for the board. The actual ID is part of the PCI register set of the host audio interface so this set of patches includes extracting the SSID from the Intel audio controller and passing it to the machine driver and then to ASoC components. Other PCI audio controllers will have the same SSID registers, so can use the same mechanism to pass the SSID.
-
Seven Lee authored
The patch helps save power by control MICBIAS. The headset's MICBIAS should be disabled without button requirement. Signed-off-by: Seven Lee <wtli@nuvoton.com> Link: https://lore.kernel.org/r/20230913064003.2925997-1-wtli@nuvoton.comSigned-off-by: Mark Brown <broonie@kernel.org>
-
Peter Ujfalusi authored
There is no need to use temporary strings to construct the kcontrol names, devm_kasprintf can be used to replace the snprintf + devm_kstrdup pairs. This change will also fixes the following compiler warning/error (W=1): sound/soc/codecs/hdac_hdmi.c: In function ‘hdac_hdmi_jack_port_init’: sound/soc/codecs/hdac_hdmi.c:1793:63: error: ‘ Switch’ directive output may be truncated writing 7 bytes into a region of size between 1 and 32 [-Werror=format-truncation=] 1793 | snprintf(kc_name, sizeof(kc_name), "%s Switch", xname); | ^~~~~~~ In function ‘create_fill_jack_kcontrols’, inlined from ‘hdac_hdmi_jack_port_init’ at sound/soc/codecs/hdac_hdmi.c:1871:8: sound/soc/codecs/hdac_hdmi.c:1793:25: note: ‘snprintf’ output between 8 and 39 bytes into a destination of size 32 1793 | snprintf(kc_name, sizeof(kc_name), "%s Switch", xname); | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ cc1: all warnings being treated as errors The warnings got brought to light by a recent patch upstream: commit 6d4ab2e9 ("extrawarn: enable format and stringop overflow warnings in W=1") Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com> Link: https://lore.kernel.org/r/20230913091325.16877-1-peter.ujfalusi@linux.intel.comSigned-off-by: Mark Brown <broonie@kernel.org>
-
- 12 Sep, 2023 8 commits
-
-
Richard Fitzgerald authored
If the driver properties do not define a cirrus,firmware-uid try to get the PCI SSID as the UID. On PCI-based systems the PCI SSID is used to uniquely identify the specific sound hardware. This is the standard mechanism for x86 systems and is the way to get a unique system identifier for systems that use the CS35L56 on SoundWire. For non-SoundWire systems there is no Windows equivalent of the ASoC driver in I2C/SPI mode. These would be: 1. HDA systems, which are handled by the HDA subsystem. 2. Linux-specific systems. 3. Composite devices where the cs35l56 is not present in ACPI and is configured using software nodes. Case 2 can use the firmware-uid property, though the PCI SSID is supported as an alternative, as it is the standard PCI mechanism. Case 3 is a SoundWire system where some other codec is the SoundWire bridge device and CS35L56 is not listed in ACPI. As these are SoundWire systems they will normally use the PCI SSID. Signed-off-by: Richard Fitzgerald <rf@opensource.cirrus.com> Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Link: https://lore.kernel.org/r/20230912163207.3498161-5-rf@opensource.cirrus.comSigned-off-by: Mark Brown <broonie@kernel.org>
-
Richard Fitzgerald authored
If the PCI SSID has been set in the struct snd_soc_acpi_mach_params, copy this to struct snd_soc_card so that it can be used by other ASoC components. This is important for components that must apply system-specific configuration. Signed-off-by: Richard Fitzgerald <rf@opensource.cirrus.com> Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Link: https://lore.kernel.org/r/20230912163207.3498161-4-rf@opensource.cirrus.comSigned-off-by: Mark Brown <broonie@kernel.org>
-
Richard Fitzgerald authored
Pass the PCI SSID of the audio interface through to the machine driver. This allows the machine driver to use the SSID to uniquely identify the specific hardware configuration and apply any platform-specific configuration. struct snd_sof_pdata is passed around inside the SOF code, but it then passes configuration information to the machine driver through struct snd_soc_acpi_mach and struct snd_soc_acpi_mach_params. So SSID information has been added to both snd_sof_pdata and snd_soc_acpi_mach_params. PCI does not define 0x0000 as an invalid value so we can't use zero to indicate that the struct member was not written. Instead a flag is included to indicate that a value has been written to the subsystem_vendor and subsystem_device members. sof_pci_probe() creates the struct snd_sof_pdata. It is passed a struct pci_dev so it can fill in the SSID value. sof_machine_check() finds the appropriate struct snd_soc_acpi_mach. It copies the SSID information across to the struct snd_soc_acpi_mach_params. This done before calling any custom set_mach_params() so that it could be used by the set_mach_params() callback to apply variant params. The machine driver receives the struct snd_soc_acpi_mach as its platform_data. Signed-off-by: Richard Fitzgerald <rf@opensource.cirrus.com> Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Link: https://lore.kernel.org/r/20230912163207.3498161-3-rf@opensource.cirrus.comSigned-off-by: Mark Brown <broonie@kernel.org>
-
Richard Fitzgerald authored
Add members to struct snd_soc_card to store the PCI subsystem ID (SSID) of the soundcard. The PCI specification provides two registers to store a vendor-specific SSID that can be read by drivers to uniquely identify a particular "soundcard". This is defined in the PCI specification to distinguish products that use the same silicon (and therefore have the same silicon ID) so that product-specific differences can be applied. PCI only defines 0xFFFF as an invalid value. 0x0000 is not defined as invalid. So the usual pattern of zero-filling the struct and then assuming a zero value unset will not work. A flag is included to indicate when the SSID information has been filled in. Unlike DMI information, which has a free-format entirely up to the vendor, the PCI SSID has a strictly defined format and a registry of vendor IDs. It is usual in Windows drivers that the SSID is used as the sole identifier of the specific end-product and the Windows driver contains tables mapping that to information about the hardware setup, rather than using ACPI properties. This SSID is important information for ASoC components that need to apply hardware-specific configuration on PCI-based systems. As the SSID is a generic part of the PCI specification and is treated as identifying the "soundcard", it is reasonable to include this information in struct snd_soc_card, instead of components inventing their own custom ways to pass this information around. Signed-off-by: Richard Fitzgerald <rf@opensource.cirrus.com> Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Link: https://lore.kernel.org/r/20230912163207.3498161-2-rf@opensource.cirrus.comSigned-off-by: Mark Brown <broonie@kernel.org>
-
Mark Brown authored
For the benefit of CI.
-
Kuninori Morimoto authored
The loop is not using "node", of_node_put(node) is not needed. Cc: Julia Lawall <julia.lawall@inria.fr> Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com> Link: https://lore.kernel.org/r/8734zlilmd.wl-kuninori.morimoto.gx@renesas.comSigned-off-by: Mark Brown <broonie@kernel.org>
-
Mark Brown authored
Merge series from Konrad Dybcio <konrad.dybcio@linaro.org>: Like most Qualcomm SoCs, SM6115 has a TX Macro. Only some minor changes were required.
-
August Wikerfors authored
Like the Lenovo 82TL and 82V2, the Lenovo 82QF (Yoga 7 14ARB7) and 82UG (Legion S7 16ARHA7) both need a quirk entry for the internal microphone to function. Commit c008323f ("ASoC: amd: yc: Fix a non-functional mic on Lenovo 82SJ") restricted the quirk that previously matched "82" to "82V2", breaking microphone functionality on these devices. Fix this by adding specific quirks for these models, as was done for the Lenovo 82TL. Fixes: c008323f ("ASoC: amd: yc: Fix a non-functional mic on Lenovo 82SJ") Closes: https://github.com/tomsom/yoga-linux/issues/51 Link: https://bugzilla.kernel.org/show_bug.cgi?id=208555#c780 Cc: stable@vger.kernel.org Signed-off-by: August Wikerfors <git@augustwikerfors.se> Link: https://lore.kernel.org/r/20230911213409.6106-1-git@augustwikerfors.seSigned-off-by: Mark Brown <broonie@kernel.org>
-
- 11 Sep, 2023 26 commits
-
-
Mark Brown authored
For some reason the JH7110 PWM DAC driver made it through build testing in spite of not being updated for the move of probe() to the ops struct. Make the required update. Signed-off-by: Mark Brown <broonie@kernel.org>
-
Mark Brown authored
Merge series from Biju Das <biju.das.jz@bp.renesas.com>: This patch series aims to add match data improvements for wm8580 driver. This patch series is only compile tested.
-
Mark Brown authored
Merge series from Linus Walleij <linus.walleij@linaro.org>: The Maxim devices are pretty straight-forward to convert over to use GPIO descriptors, so let's do it.
-
Mark Brown authored
Merge series from Biju Das <biju.das.jz@bp.renesas.com>: This patch series aims to add match data improvements for tlv320aic32x4 driver. This patch series is only compile tested.
-
Mark Brown authored
Merge series from Linus Walleij <linus.walleij@linaro.org>: The Maxim devices are pretty straight-forward to convert over to use GPIO descriptors, so let's do it.
-
Mark Brown authored
Merge series from Trevor Wu <trevor.wu@mediatek.com>: This series introduces dynamic pinctrl and adds support for the SOF on the mt8188-mt6359 machine driver.
-
Mark Brown authored
Merge series from Biju Das <biju.das.jz@bp.renesas.com>: This patch series aims to add match data improvements for ak4642 driver. This patch series is only compile tested.
-
Mark Brown authored
Merge series from Marian Postevca <posteuca@mutex.one>: This series adds support for a line of HUAWEI laptops with AMD CPUs that connect using the ACP3x module to a ES8336 CODEC. The CODEC driver must be extended to support the S32 LE format and the MCLK div by 2 option. MCLK div by 2 is needed for one specific SKU, which uses a 48Mhz MCLK, which seems to be too high of a frequency for the CODEC and must be divided by 2. The acp legacy driver must also be extended by using callbacks so that the more complicated handling of this specific CODEC can be moved outside the more generic ACP code.
-
Mark Brown authored
Merge series from Cristian Ciocaltea <cristian.ciocaltea@collabora.com>: This patch series contains several fixes and improvements to drivers based on the CS35l41 audio codec. It has been verified on Valve's Steam Deck, except the HDA related patches.
-
Mark Brown authored
Merge series from Hal Feng <hal.feng@starfivetech.com>: This patchset adds PWM-DAC audio support for the StarFive JH7110 SoC. The PWM-DAC module does not require a hardware codec, but a dummy codec is needed for the driver. The dummy spdif codec driver, which is already upstream, is compatible with the one which JH7110 PWM-DAC needed. So we use it as the dummy codec driver for the JH7110 PWM-DAC module.
-
Mark Brown authored
Merge series from Sameer Pujar <spujar@nvidia.com>: This small series fixes redundant PLLA updates that happen for each DAI link in the audio path. This helps to resolve DMIC clock issue seen on Jetson TX2 platform.
-
Shengjiu Wang authored
The rpmsg pcm device is a device which should support double buffering. Found this issue with pipewire. When there is no SNDRV_PCM_INFO_BATCH flag in driver, the pipewire will set headroom to be zero, and because rpmsg pcm device don't support residue report, when the latency setting is small, the "delay" always larger than "target" in alsa-pcm.c, that reading next period data is not scheduled on time. With SNDRV_PCM_INFO_BATCH flag in driver, the pipewire will select a smaller period size for device, then the task of reading next period data will be scheduled on time. Signed-off-by: Shengjiu Wang <shengjiu.wang@nxp.com> Link: https://lore.kernel.org/r/1694414287-13291-1-git-send-email-shengjiu.wang@nxp.comSigned-off-by: Mark Brown <broonie@kernel.org>
-
Cristian Ciocaltea authored
Replace the remaining dev_err() calls in probe() with dev_err_probe(), to improve consistency. Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com> Reviewed-by: Takashi Iwai <tiwai@suse.de> Link: https://lore.kernel.org/r/20230907171010.1447274-12-cristian.ciocaltea@collabora.comSigned-off-by: Mark Brown <broonie@kernel.org>
-
Cristian Ciocaltea authored
According to the documentation, drivers are responsible for undoing at removal time all runtime PM changes done during probing. Hence, add the missing calls to pm_runtime_dont_use_autosuspend(), which are necessary for undoing pm_runtime_use_autosuspend(). Fixes: 1873ebd3 ("ALSA: hda: cs35l41: Support Hibernation during Suspend") Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com> Reviewed-by: Takashi Iwai <tiwai@suse.de> Link: https://lore.kernel.org/r/20230907171010.1447274-11-cristian.ciocaltea@collabora.comSigned-off-by: Mark Brown <broonie@kernel.org>
-
Cristian Ciocaltea authored
If component_add() fails, probe() returns without calling pm_runtime_put(), which leaves the runtime PM usage counter incremented. Fix the issue by jumping to err_pm label and drop the now unnecessary pm_runtime_disable() call. Fixes: 7b2f3eb4 ("ALSA: hda: cs35l41: Add support for CS35L41 in HDA systems") Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com> Reviewed-by: Takashi Iwai <tiwai@suse.de> Link: https://lore.kernel.org/r/20230907171010.1447274-10-cristian.ciocaltea@collabora.comSigned-off-by: Mark Brown <broonie@kernel.org>
-
Cristian Ciocaltea authored
Make use of the recently introduced EXPORT_GPL_DEV_PM_OPS() macro, to conditionally export the runtime/system PM functions. Replace the old SET_{RUNTIME,SYSTEM_SLEEP,NOIRQ_SYSTEM_SLEEP}_PM_OPS() helpers with their modern alternatives and get rid of the now unnecessary '__maybe_unused' annotations on all PM functions. Additionally, use the pm_ptr() macro to fix the following errors when building with CONFIG_PM disabled: ERROR: modpost: "cs35l41_pm_ops" [sound/soc/codecs/snd-soc-cs35l41-spi.ko] undefined! ERROR: modpost: "cs35l41_pm_ops" [sound/soc/codecs/snd-soc-cs35l41-i2c.ko] undefined! Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com> Acked-by: Charles Keepax <ckeepax@opensource.cirrus.com> Reviewed-by: Takashi Iwai <tiwai@suse.de> Link: https://lore.kernel.org/r/20230907171010.1447274-9-cristian.ciocaltea@collabora.comSigned-off-by: Mark Brown <broonie@kernel.org>
-
Cristian Ciocaltea authored
Use dev_err_probe() helper where possible, to simplify error handling during probe. Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com> Acked-by: Charles Keepax <ckeepax@opensource.cirrus.com> Reviewed-by: Takashi Iwai <tiwai@suse.de> Link: https://lore.kernel.org/r/20230907171010.1447274-8-cristian.ciocaltea@collabora.comSigned-off-by: Mark Brown <broonie@kernel.org>
-
Cristian Ciocaltea authored
According to the documentation, drivers are responsible for undoing at removal time all runtime PM changes done during probing. Hence, add the missing calls to pm_runtime_dont_use_autosuspend(), which are necessary for undoing pm_runtime_use_autosuspend(). Note this would have been handled implicitly by devm_pm_runtime_enable(), but there is a need to continue using pm_runtime_enable()/pm_runtime_disable() in order to ensure the runtime PM is disabled as soon as the remove() callback is entered. Fixes: f517ba49 ("ASoC: cs35l41: Add support for hibernate memory retention mode") Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com> Reviewed-by: Takashi Iwai <tiwai@suse.de> Link: https://lore.kernel.org/r/20230907171010.1447274-7-cristian.ciocaltea@collabora.comSigned-off-by: Mark Brown <broonie@kernel.org>
-
Cristian Ciocaltea authored
The interrupt handler invokes pm_runtime_get_sync() without checking the returned error code. Add a proper verification and switch to pm_runtime_resume_and_get(), to avoid the need to call pm_runtime_put_noidle() for decrementing the PM usage counter before returning from the error condition. Fixes: f517ba49 ("ASoC: cs35l41: Add support for hibernate memory retention mode") Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com> Acked-by: Charles Keepax <ckeepax@opensource.cirrus.com> Reviewed-by: Takashi Iwai <tiwai@suse.de> Link: https://lore.kernel.org/r/20230907171010.1447274-6-cristian.ciocaltea@collabora.comSigned-off-by: Mark Brown <broonie@kernel.org>
-
Cristian Ciocaltea authored
Enabling the active/passive shared boosts requires setting SYNC_EN, but *not* before receiving the PLL Lock signal. Due to improper error handling, it was not obvious that waiting for the completion operation times out and, consequently, the shared boost is never activated. Further investigations revealed the signal is triggered while snd_pcm_start() is executed, right after receiving the SNDRV_PCM_TRIGGER_START command, which happens long after the SND_SOC_DAPM_PRE_PMU event handler is invoked as part of snd_pcm_prepare(). That is where cs35l41_global_enable() is called from. Increasing the wait duration doesn't help, as it only causes an unnecessary delay in the invocation of snd_pcm_start(). Moving the wait and the subsequent regmap operations to the SNDRV_PCM_TRIGGER_START callback is not a solution either, since they would be executed in an IRQ-off atomic context. Solve the issue by setting the SYNC_EN bit in PWR_CTRL3 register right after receiving the PLL Lock interrupt. Additionally, drop the unnecessary writes to PWR_CTRL1 register, part of the original mdsync_up_seq, which would have toggled GLOBAL_EN with unwanted consequences on PLL locking behavior. Fixes: f5030564 ("ALSA: cs35l41: Add shared boost feature") Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com> Reviewed-by: David Rhodes <david.rhodes@cirrus.com> Reviewed-by: Takashi Iwai <tiwai@suse.de> Link: https://lore.kernel.org/r/20230907171010.1447274-5-cristian.ciocaltea@collabora.comSigned-off-by: Mark Brown <broonie@kernel.org>
-
Cristian Ciocaltea authored
Technically, an interrupt handler can be called before probe() finishes its execution, hence ensure the pll_lock completion object is always initialized before being accessed in cs35l41_irq(). Fixes: f5030564 ("ALSA: cs35l41: Add shared boost feature") Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com> Acked-by: Charles Keepax <ckeepax@opensource.cirrus.com> Reviewed-by: Takashi Iwai <tiwai@suse.de> Link: https://lore.kernel.org/r/20230907171010.1447274-4-cristian.ciocaltea@collabora.comSigned-off-by: Mark Brown <broonie@kernel.org>
-
Cristian Ciocaltea authored
The return code of regmap_multi_reg_write() call related to "MDSYNC up" sequence is shadowed by the subsequent regmap_read_poll_timeout() invocation, which will hit a timeout in case the write operation above fails. Make sure cs35l41_global_enable() returns the correct error code instead of -ETIMEDOUT. Additionally, to be able to distinguish between the timeouts of wait_for_completion_timeout() and regmap_read_poll_timeout(), print an error message for the former and return immediately. This also avoids having to wait unnecessarily for the second time. Fixes: f8264c75 ("ALSA: cs35l41: Poll for Power Up/Down rather than waiting a fixed delay") Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com> Acked-by: Charles Keepax <ckeepax@opensource.cirrus.com> Reviewed-by: Takashi Iwai <tiwai@suse.de> Link: https://lore.kernel.org/r/20230907171010.1447274-3-cristian.ciocaltea@collabora.comSigned-off-by: Mark Brown <broonie@kernel.org>
-
Cristian Ciocaltea authored
The return code of regmap_multi_reg_write() call related to "MDSYNC down" sequence is shadowed by the subsequent wait_for_completion_timeout() invocation, which is expected to time timeout in case the write operation failed. Let cs35l41_global_enable() return the correct error code instead of -ETIMEDOUT. Fixes: f5030564 ("ALSA: cs35l41: Add shared boost feature") Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com> Acked-by: Charles Keepax <ckeepax@opensource.cirrus.com> Reviewed-by: Takashi Iwai <tiwai@suse.de> Link: https://lore.kernel.org/r/20230907171010.1447274-2-cristian.ciocaltea@collabora.comSigned-off-by: Mark Brown <broonie@kernel.org>
-
Linus Walleij authored
This driver is already using solely GPIO descriptors and do not need to include the legacy headers <linux/gpio.h> or <linux/of_gpio.h>. Drop them. Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Link: https://lore.kernel.org/r/20230911-descriptors-asoc-max-v2-7-b9d793fb768e@linaro.orgSigned-off-by: Mark Brown <broonie@kernel.org>
-
Linus Walleij authored
This driver is already using solely GPIO descriptors and do not need to include the legacy headers <linux/gpio.h> or <linux/of_gpio.h>. Drop them. Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Link: https://lore.kernel.org/r/20230911-descriptors-asoc-max-v2-6-b9d793fb768e@linaro.orgSigned-off-by: Mark Brown <broonie@kernel.org>
-
Linus Walleij authored
This driver is already using solely GPIO descriptors and do not need to include the legacy header <linux/gpio.h>. Drop it. Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Link: https://lore.kernel.org/r/20230911-descriptors-asoc-max-v2-5-b9d793fb768e@linaro.orgSigned-off-by: Mark Brown <broonie@kernel.org>
-