When firmware loading is disabled, gcc warns that the local
'fw' variable fails to get initialized:
sound/soc/codecs/sma1307.c: In function 'sma1307_setting_loaded.isra':
sound/soc/codecs/sma1307.c:1717:12: error: 'fw' is used uninitialized [-Werror=uninitialized]
1717 | if (!fw) {
| ^
sound/soc/codecs/sma1307.c:1712:32: note: 'fw' was declared here
1712 | const struct firmware *fw;
Check the return code from request_firmware() to ensure that the
firmware is correctly set, and drop the incorrect release_firmware()
on that uninitialized data.
Fixes: 576c57e6b4 ("ASoC: sma1307: Add driver for Iron Device SMA1307")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Link: https://patch.msgid.link/20241113175734.2443315-1-arnd@kernel.org
Signed-off-by: Mark Brown <broonie@kernel.org>
Simple Card Utils has simple_util_dai which is paired to snd_soc_dai,
and assmus that CPU/Codec DAI and its paired simple_util_dai are same
order for CPU/Codec
simple_util_dai[0] <--> snd_soc_dai[0]
simple_util_dai[1] <--> snd_soc_dai[1]
...
So, it is using same index in for_each loop.
(X) gets simple_util_dai
(Y) gets snd_soc_dai
(Y) for_each_rtd_cpu_dais(.., i, ..) {
(X)(A) udai = simple_props_to_dai_cpu(.., i);
}
(X) for_each_prop_dai_cpu(.., i, ...) {
(Y) dai = snd_soc_rtd_to_cpu(.., i);
...
}
But current Simple Card Utils didn't have simple_util_dai for
dummy DAI. So above (A) will get NULL pointer in such case.
This patch cares simple_util_dai for dummy DAI.
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Link: https://patch.msgid.link/87msi5maz3.wl-kuninori.morimoto.gx@renesas.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Fix an issue detected by the Smatch tool:
sound/soc/sof/ipc4-pcm.c: sof_ipc4_pcm_dai_link_fixup_rate()
error: uninitialized symbol 'be_rate'.
The warning highlights a case where `be_rate` could remain uninitialized
if `num_input_formats` is zero, which would cause undefined behavior
when setting `rate->min` and `rate->max` based on `be_rate`.
To address this issue, a `WARN_ON_ONCE(!num_input_formats)` check was
added to ensure `num_input_formats` is greater than zero. If this
condition fails, the function returns `-EINVAL`, preventing the use of
an uninitialized `be_rate`.
This change improves the robustness of the function by catching an
invalid state early and providing better feedback during development.
Signed-off-by: Suraj Sonawane <surajsonawane0215@gmail.com>
Link: https://patch.msgid.link/20241107063609.11627-1-surajsonawane0215@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
This codec only has one set of left and right DACs, remove the duplicate
DACs with duplicated bits controlling them as the userspace can set those
controls to mismatched value. This most likely does break userspace ABI,
but there seem to be no in-kernel users.
Signed-off-by: Marek Vasut <marex@denx.de>
Link: https://patch.msgid.link/20241108235453.196289-1-marex@denx.de
Signed-off-by: Mark Brown <broonie@kernel.org>
The audio graph card doesn't mark its subnodes such as multi {}, dpcm {}
and c2c {} as not requiring any suppliers. This causes a hang as Linux
waits for these phantom suppliers to show up on boot.
Make it clear these nodes have no suppliers.
Example error message:
[ 15.208558] platform 2034000.i2s: deferred probe pending: platform: wait for supplier /sound/multi
[ 15.208584] platform sound: deferred probe pending: asoc-audio-graph-card2: parse error
Signed-off-by: John Watts <contact@jookia.org>
Acked-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Link: https://patch.msgid.link/20241108-graph_dt_fix-v1-1-173e2f9603d6@jookia.org
Signed-off-by: Mark Brown <broonie@kernel.org>
Merge series from Peter Ujfalusi <peter.ujfalusi@linux.intel.com>:
Hi,
A recent attempt to fix a missing symbol when
CONFIG_SND_SOC_SDCA=m and CONFIG_SND_SOC_ACPI_INTEL_SDCA_QUIRKS=y
caused unmet direct dependency warning with randconig.
The reason is that SND_SOC_ACPI_INTEL_MATCH is needed to be compilable
even if ACPI is not selected, modules have dependency on exported
symbols from it.
The only solution for these kconfig dependencies seams to be to
only select SND_SOC_SDCA if ACPI is enabled from
SND_SOC_ACPI_INTEL_SDCA_QUIRKS.
Regards,
Peter
---
Peter Ujfalusi (2):
ASoC: Intel: Kconfig: Only select SND_SOC_SDCA if ACPI is enabled
ASoC: Intel: Kconfig: Revert make SND_SOC_ACPI_INTEL_MATCH depend on
ACPI
sound/soc/intel/Kconfig | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
--
2.47.0
Add STM32MP25 support for STM32 I2S.
On STM32MP25 the I2S driver does not manage I2S kernel clock rate
by choosing its parent clock, depending on audio stream rate.
The driver requests a rate change on I2S kernel clock instead.
It tries to set the higher possible rate, which is a multiple of
the audio stream rate and which gives an accuracy of at least 1000 ppm.
Signed-off-by: Olivier Moysan <olivier.moysan@foss.st.com>
Link: https://patch.msgid.link/20241107144712.1305638-3-olivier.moysan@foss.st.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Add STM32MP25 support for STM32 SAI.
On STM32MP25 the SAI driver does not manage SAI kernel clock rate
by chosing its parent clock, dependending on audio stream rate.
The driver requests a rate change on SAI kernel clock instead.
This rate change is performed with the following guidelines:
- Chose highest rate multiple of the audio stream
(Try to get clock accuracy within 1000 ppm)
- Ensure clock rate compatibility between SAI sub-blocks A&B
and between instances sharing the same flexgen.
Use clk_rate_exclusive API to fulfill this requirement.
The STM32 SAI peripheral does not support the DMA burst mode
on STM32MP25. Add a field in compatible structure to manage DMA
burst support capability.
Signed-off-by: Olivier Moysan <olivier.moysan@foss.st.com>
Link: https://patch.msgid.link/20241107155143.1340523-3-olivier.moysan@foss.st.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Merge series from Peter Ujfalusi <peter.ujfalusi@linux.intel.com>:
The PROBE_INFO (ext_manifest type 3) is not used by the kernel, but
at every tiem the firmware is loaded the following is printed in
info level (user visible):
unknown sof_ext_man header type 3 size 0x30
The type is known, but it is not handled, the print is misleading.
It has been reported that the DMA memory allocation for firmware download
can fail after extended period of uptime on systems with relatively small
amount of RAM when the system memory becomes fragmented.
The issue primarily happens when the system is waking up from system
suspend, swap might not be available and the MM system cannot move things
around to allow for successful allocation.
If the IMR boot is not supported then for each DSP boot we would need to
allocate the DMA buffer for firmware transfer, which can increase the
chances of the issue to be hit.
This patch adds support for allocating the DMA buffers once at first boot
time and keep it until the system is shut down, rebooted or the drivers
re-loaded and makes this as the default operation.
With persistent_cl_buffer module parameter the persistent Code Loader
DMA buffer can be disabled to fall back to on demand allocation.
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com>
Reviewed-by: Bard Liao <yung-chuan.liao@linux.intel.com>
Reviewed-by: Liam Girdwood <liam.r.girdwood@intel.com>
Reviewed-by: Kai Vehmanen <kai.vehmanen@linux.intel.com>
Link: https://patch.msgid.link/20241107121440.1472-1-peter.ujfalusi@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
The HDA specification states that the SDnLVI (Last Valid Index) must be at
least 1 (two BDLE entry).
Update the debug prints as well to provide better information.
While the LVI=0 worked so far without issues, it is better to align with
the specification to avoid unforeseen issues with FW loading.
Notes:
- The LVI > 0 rules is valid and honored for audio use cases
- LVI == 0 is used with software controlled (SPIB) transfers only for
firmware and library loading, which is permitted by the hardware
- This is not spelled out in the specification and it is better to avoid
cases
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com>
Reviewed-by: Liam Girdwood <liam.r.girdwood@intel.com>
Reviewed-by: Kai Vehmanen <kai.vehmanen@linux.intel.com>
Reviewed-by: Bard Liao <yung-chuan.liao@linux.intel.com>
Link: https://patch.msgid.link/20241107121532.3241-1-peter.ujfalusi@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Merge series from Bard Liao <yung-chuan.liao@linux.intel.com>:
Fix the ld.lld: error: undefined symbol: sdca_device_quirk_match issue
when CONFIG_SND_SOC_SDCA=m and CONFIG_SND_SOC_ACPI_INTEL_SDCA_QUIRKS=y.
On the Renesas RZ/G3S SMARC Carrier II board having a DA7212 codec (using
da7213 driver) connected to one SSIF-2 available on the Renesas RZ/G3S SoC
it has been discovered that using the runtime PM API for suspend/resume
(as will be proposed in the following commits) leads to the codec not
being propertly initialized after resume. This is because w/o
max_register populated to regmap_config the regcache_rbtree_sync()
breaks on base_reg > max condition and the regcache_sync_block() call is
skipped.
Fixes: ef5c2eba24 ("ASoC: codecs: Add da7213 codec")
Cc: stable@vger.kernel.org
Signed-off-by: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com>
Link: https://patch.msgid.link/20241106081826.1211088-23-claudiu.beznea.uj@bp.renesas.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Xiaomi Book Pro 14 2022 (MIA2210-AD) requires a quirk entry for its
internal microphone to be enabled.
This is likely due to similar reasons as seen previously on Redmi Book
14/15 Pro 2022 models (since they likely came with similar firmware):
- commit dcff8b7ca9 ("ASoC: amd: yc: Add Xiaomi Redmi Book Pro 15 2022
into DMI table")
- commit c1dd6bf619 ("ASoC: amd: yc: Add Xiaomi Redmi Book Pro 14 2022
into DMI table")
A quirk would likely be needed for Xiaomi Book Pro 15 2022 models, too.
However, I do not have such device on hand so I will leave it for now.
Signed-off-by: Mingcong Bai <jeffbai@aosc.io>
Link: https://patch.msgid.link/20241106024052.15748-1-jeffbai@aosc.io
Signed-off-by: Mark Brown <broonie@kernel.org>
