Merge series from Peter Ujfalusi <peter.ujfalusi@linux.intel.com>:
Today I came across two regressions in next with SOF:
The topology would not load with a failure of creating playback DAI
the first patch is fixing this which was caused by a missing 'else' in the patch
After fixing the topology loading, the module unloading caused kernel panic.
The second patch is correcting that which is I likely caused by copy-paste to
set wrong unload callback for the graph element.
With these patches applied SOF is working on next and modules can be unloaded
My randconfig build setup ran into a rare build failure with
CONFIG_SND_SOC_SOF_INTEL_SOUNDWIRE_LINK_BASELINE=y
CONFIG_SND_SOC_SOF_INTEL_SOUNDWIRE=m
CONFIG_SOUNDWIRE=y
CONFIG_SOUNDWIRE_INTEL=m
CONFIG_SND_SOC_SOF_HDA=y
CONFIG_SND_SOC_SOF_INTEL_TGL=y
x86_64-linux-ld: sound/soc/sof/intel/hda.o: in function `hda_init_caps':
hda.c:(.text+0x691): undefined reference to `sdw_intel_cnl_hw_ops'
x86_64-linux-ld: hda.c:(.text+0x6f2): undefined reference to `sdw_intel_probe'
x86_64-linux-ld: sound/soc/sof/intel/hda.o: in function `hda_sdw_startup':
hda.c:(.text+0x1c40): undefined reference to `sdw_intel_startup'
x86_64-linux-ld: sound/soc/sof/intel/hda.o: in function `hda_sdw_process_wakeen':
hda.c:(.text+0x1cb6): undefined reference to `sdw_intel_process_wakeen_event'
x86_64-linux-ld: sound/soc/sof/intel/hda.o: in function `hda_dsp_interrupt_thread':
hda.c:(.text+0x1d67): undefined reference to `sdw_intel_thread'
x86_64-linux-ld: sound/soc/sof/intel/hda.o: in function `hda_dsp_remove':
hda.c:(.text+0x2655): undefined reference to `sdw_intel_exit'
My best understanding is that the definition of
SND_SOC_SOF_INTEL_SOUNDWIRE_LINK_BASELINE was intended to avoid this
problem, but got it wrong for the SND_SOC_SOF_INTEL_SOUNDWIRE=m case,
where the 'select' is meant to set SOUNDWIRE_INTEL to the value of
SND_SOC_SOF_INTEL_SOUNDWIRE_LINK_BASELINE rather than the intersection of
SND_SOC_SOF_INTEL_SOUNDWIRE_LINK_BASELINE and SND_SOC_SOF_INTEL_SOUNDWIRE.
Change the condition to check for SND_SOC_SOF_INTEL_SOUNDWIRE to be a
boolean rather than a tristate expression in order to propagate this
as intended.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Link: https://lore.kernel.org/r/20230202102247.806749-1-arnd@kernel.org
Signed-off-by: Mark Brown <broonie@kernel.org>
Some Smatch static checker warning like below was found.
sound/soc/mediatek/mt8188/mt8188-dai-etdm.c:2487
mt8188_dai_etdm_parse_of()
warn: 'ret' returned from snprintf() might be larger than 48
2479 for (i = 0; i < MT8188_AFE_IO_ETDM_NUM; i++) {
2480 dai_id = ETDM_TO_DAI_ID(i);
2481 etdm_data = afe_priv->dai_priv[dai_id];
2482
2483 ret = snprintf(prop, sizeof(prop),
2484 "mediatek,%s-multi-pin-mode",
2485 of_afe_etdms[i].name);
2486 if (ret < 0) {
--> 2487 dev_err(afe->dev, "%s snprintf
err=%d\n",
2488
In linux kernel, snprintf() never returns negatives. On the other hand,
the format string like "mediatek,%s-multi-pin-mode" must be smaller
than sizeof(prop)=48.
After discussing in the mail thread[1], I remove the dead code to fix
the Smatch warnings.
[1]: https://lore.kernel.org/all/Y9EdBg641tJDDrt%2F@kili/
Signed-off-by: Trevor Wu <trevor.wu@mediatek.com>
Link: https://lore.kernel.org/r/20230202103704.15626-1-trevor.wu@mediatek.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Merge series from Mario Limonciello <mario.limonciello@amd.com>:
It's been reported that a number of laptops have a low volume
level from the digital microphone compared to Windows.
AMD offers a register that can adjust the gain for PDM which is not
configured at maximum gain by default.
To fix this change the default for all 3 drivers to raise the gain
but also offer a module parameter. The module parameter can be used
for debugging if the gain is too high on a given laptop.
This is intentionally split into multiple patches for default and
parameter so that if the default really does behave better universally
we can bring it back to stable too later.
In case of regressions for any users that the new pdm_gain value is
too high and for additional debugging, introduce a module parameter
that would let them configure it.
This parameter should be removed in the future:
* If it's determined that the parameter is not needed, just hardcode
the correct value as before
* If users do end up using it to debug and report different values
we should introduce a config knob that can have policy set by ucm.
Signed-off-by: Mario Limonciello <mario.limonciello@amd.com>
Reviewed-by: Jaroslav Kysela <perex@perex.cz>
Link: https://lore.kernel.org/r/20230131184653.10216-7-mario.limonciello@amd.com
Signed-off-by: Mark Brown <broonie@kernel.org>
In case of regressions for any users that the new pdm_gain value is
too high and for additional debugging, introduce a module parameter
that would let them configure it.
This parameter should be removed in the future:
* If it's determined that the parameter is not needed, just hardcode
the correct value as before
* If users do end up using it to debug and report different values
we should introduce a config knob that can have policy set by ucm.
Signed-off-by: Mario Limonciello <mario.limonciello@amd.com>
Reviewed-by: Jaroslav Kysela <perex@perex.cz>
Link: https://lore.kernel.org/r/20230131184653.10216-5-mario.limonciello@amd.com
Signed-off-by: Mark Brown <broonie@kernel.org>
In case of regressions for any users that the new pdm_gain value is
too high and for additional debugging, introduce a module parameter
that would let them configure it.
This parameter should be removed in the future:
* If it's determined that the parameter is not needed, just hardcode
the correct value as before
* If users do end up using it to debug and report different values
we should introduce a config knob that can have policy set by ucm.
Signed-off-by: Mario Limonciello <mario.limonciello@amd.com>
Reviewed-by: Jaroslav Kysela <perex@perex.cz>
Link: https://lore.kernel.org/r/20230131184653.10216-3-mario.limonciello@amd.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Some SoC can't handle all requested hw rule. In such case, it will indicate
like below, but it is unclear why it didn't work to user.
This patch indicates warning in such case once, because player will try to
similar rule many times.
# aplay sound.wav
Playing WAVE 'sound.wav' : Signed 16 bit Little Endian, Rate 48000 Hz, Stereo
aplay: aplay.c: 1359: set_params: Assertion `err >= 0' failed.
Aborted by signal Aborted...
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Link: https://lore.kernel.org/r/87357q6t7b.wl-kuninori.morimoto.gx@renesas.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Merge series from Stefan Binding <sbinding@opensource.cirrus.com>:
The CS42L42 has a SoundWire interface for control and audio. This
chain of patches adds support for this.
Patches #1 .. #5 split out various changes to the existing code that
are needed for adding Soundwire. These are mostly around clocking and
supporting the separate probe and enumeration stages in SoundWire.
Patches #6 .. #8 actually adds the SoundWire handling.
Merge series from Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>:
struct snd_soc_dai need to have info for playback/capture,
but it is using "playback/capture_xxx" or "tx/tx_xxx" or array.
This kind of random definition is very difficult to read.
This patch-set add helper functions and each driver use it.
And cleanup the definition.
Merge series from Claudiu Beznea <claudiu.beznea@microchip.com>:
This series adds runtime PM support for Microchip SPDIFRX driver.
Along with it I added few fixes identified while going though the code
and playing with Microchip SPDIFRX controller.
Merge series from wangweidong.a@awinic.com:
The Awinic AW88395 is an I2S/TDM input, high efficiency
digital Smart K audio amplifier with an integrated 10.25V
smart boost converter.
Add a DT schema for describing Awinic AW88395 audio amplifiers. They are
controlled using I2C
Merge series from Herve Codina <herve.codina@bootlin.com>:
The Renesas IDT821034 codec is four channel PCM codec with on-chip
filters and programmable gain setting. It also provides SLIC
(Subscriber Line Interface Circuit) signals as GPIOs.
idle_bias_on was set because cs42l42 has a "VMID" type pseudo-midrail
supply (named FILT+), and these typically take a long time to charge.
But the driver never enabled pm_runtime so it would never have powered-
down the cs42l42 anyway.
In fact, FILT+ can charge to operating voltage within 12.5 milliseconds
of enabling HP or ADC. This time is already covered by the startup
delay of the HP/ADC.
The datasheet warning about FILT+ taking up to 1 second to charge only
applies in the special cases that either the PLL is started or
DETECT_MODE set to non-zero while both HP and ADC are off. The driver
never does either of these.
Removing idle_bias_on allows the Soundwire host controller to suspend
if there isn't a snd_soc_jack handler registered.
Signed-off-by: Richard Fitzgerald <rf@opensource.cirrus.com>
Signed-off-by: Stefan Binding <sbinding@opensource.cirrus.com>
Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Link: https://lore.kernel.org/r/20230127165111.3010960-8-sbinding@opensource.cirrus.com
Signed-off-by: Mark Brown <broonie@kernel.org>
This adds support for using CS42L42 as a SoundWire device.
SoundWire-specifics are kept separate from the I2S implementation as
much as possible, aiming to limit the risk of breaking the I2C+I2S
support.
There are some important differences in the silicon behaviour between
I2S and SoundWire mode that are reflected in the implementation:
- ASP (I2S) most not be used in SoundWire mode because the two interfaces
share pins.
- The SoundWire capture (record) port only supports 1 channel. It does
not have left-to-right duplication like the ASP.
- DP2 can only be prepared if the HP has powered-up. DP1 can only be
prepared if the ADC has powered-up. (This ordering restriction does
not exist for ASPs.) The SoundWire core port-prepare step is
triggered by the DAI-link prepare(). This happens before the
codec DAI prepare() or the DAPM sequence so these cannot be used
to enable HP/ADC. Instead the HP/ADC enable/disable are done during
the port_prep callback.
- The SRCs are an integral part of the audio chain but in silicon their
power control is linked to the ASP. There is no equivalent power link
to SoundWire DPs so the driver must take "manual" control of SRC power.
- The SoundWire control registers occupy the lower part of the SoundWire
address space so cs42l42 registers are offset by 0x8000 (non-paged) in
SoundWire mode.
- Register addresses are 8-bit paged in I2C mode but 16-bit unpaged in
SoundWire.
- Special procedures are needed on register read/writes to (a) ensure
that the previous internal bus transaction has completed, and
(b) handle delayed read results, when the read value could not be
returned within the SoundWire read command.
There are also some differences in driver implementation between I2S
and SoundWire operation:
- CS42L42 I2S does not runtime_suspend, but runtime_suspend/resume support
has been added into the driver in SoundWire mode as the most convenient
way to power-up the bus manager and to handle the unattach_request
condition, though the CS42L42 chip does not itself suspend or resume.
- Intel SoundWire host controllers have a low-power clock-stop mode that
requires resetting all peripherals when resuming. This means that the
interrupt registers will be reset in between the interrupt being
generated and the interrupt being handled, and since the interrupt
status is debounced, these values may not be accurate immediately,
and may cause spurious unplug events before settling.
- As in I2S mode, the PLL is only used while audio is active because
of clocking quirks in the silicon. For SoundWire the cs42l42_pll_config()
is deferred until the DAI prepare(), to allow the cs42l42_bus_config()
callback to set the SCLK.
Signed-off-by: Richard Fitzgerald <rf@opensource.cirrus.com>
Signed-off-by: Stefan Binding <sbinding@opensource.cirrus.com>
Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Link: https://lore.kernel.org/r/20230127165111.3010960-7-sbinding@opensource.cirrus.com
Signed-off-by: Mark Brown <broonie@kernel.org>
The chosen clocking configuration must give an internal MCLK (MCLKint)
that is an integer multiple of the sample rate.
On I2S each of the supported bit clock frequencies can only be generated
from one sample rate group (either the 44100 or the 48000) so the code
could use only the bitclock to look up a PLL config.
The relationship between sample rate and bitclock frequency is more
complex on Soundwire and so it is possible to set a frame shape to
generate a bitclock from the "wrong" group. For example 2*147 with a
48000 sample rate would give a bitclock of 14112000 which on I2S
could only be derived from a 44100 sample rate.
Signed-off-by: Richard Fitzgerald <rf@opensource.cirrus.com>
Signed-off-by: Stefan Binding <sbinding@opensource.cirrus.com>
Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Link: https://lore.kernel.org/r/20230127165111.3010960-4-sbinding@opensource.cirrus.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Currently, port_prep callback only has commands for PRE_PREP, PREP,
and POST_PREP, which doesn't directly say whether this is for a
prepare or deprepare call. Extend the command list enum to say
whether the call is for prepare or deprepare aswell.
Also remove SDW_OPS_PORT_PREP from sdw_port_prep_ops as this is unused,
and update this enum to be simpler and more consistent with enum
sdw_clk_stop_type.
Note: Currently, the only users of SDW_OPS_PORT_POST_PREP are codec
drivers sound/soc/codecs/wsa881x.c and sound/soc/codecs/wsa883x.c, both
of which seem to assume that POST_PREP only occurs after a prepare,
even though it would also have occurred after a deprepare. Since it
doesn't make sense to mark the port prepared after a deprepare, changing
the enum to separate PORT_DEPREP from PORT_PREP should make the check
for PORT_PREP in those drivers be more logical.
Signed-off-by: Stefan Binding <sbinding@opensource.cirrus.com>
Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Acked-By: Vinod Koul <vkoul@kernel.org>
Link: https://lore.kernel.org/r/20230127165111.3010960-2-sbinding@opensource.cirrus.com
Signed-off-by: Mark Brown <broonie@kernel.org>
