Merge series from David Rau <David.Rau.opensource@dm.renesas.com>:
This patchset adds the support of DA7219 Jack insertion detection
polarity selection.
The first patch replaces the old txt binding with a new schema binding.
The second patch adds `dlg,jack-ins-det-pty` property for Jack
insertion detection polarity selection.
The last patch adds the driver support for this topic.
The series has been verified on the DA7219 development kit.
Merge series from Daniel Baluta <daniel.baluta@oss.nxp.com>:
This patch series provides better handling of cases where sending
a data blob to FW results in a validation error.
In this case we restore to the last good known value instead of keeping
the data that firwmare rejected.
Merge series from Trevor Wu <trevor.wu@mediatek.com>:
The patch series includes a kselftest fix and changes for extending
driver capability to support more use cases.
Merge series from Claudiu Beznea <claudiu.beznea@microchip.com>:
Series removes the pm_runtime.h inclusion in files where
APIs exported though pm_runtime.h are not used. In case
of files that make use of pm.h which comes form pm_runtime.h
added patch 2/2.
Merge series from Peter Ujfalusi <peter.ujfalusi@linux.intel.com>:
The following series will enable multicore support on MTL platforms similarly
to other Intel platforms.
The TGL patch is included to simplify the core_put implementation.
Multicore support can be enabled by updated topologies, with current set of
tplg files this series is not introducing any runtime change.
Originally, lineout playback source can only be DAC_3RD. Some SoC
masters only support stereo MTKAIF outputs, so lineout path can't be
used in such case.
MTKAIF connections are as follows.
MOSI0 -> DAC_L
MOSI1 -> DAC_R
MOSI2 -> DAC_3rd
In the patch, lineout playback source can be chosen between DAC_L and
DAC_3rd, so sound can be outputted via lineout even though SoC only
supports stereo MTKAIF outputs.
Signed-off-by: Trevor Wu <trevor.wu@mediatek.com>
Link: https://lore.kernel.org/r/20230508071532.21665-5-trevor.wu@mediatek.com
Signed-off-by: Mark Brown <broonie@kernel.org>
kselftest tries to read/write the default value. The default register
value of playback gain is 0x1F(mute), but max gain we specified is 0x12.
The range of the control is 0x0~0x12 and mute(0x1F) is only used in the
driver internally. To solve the problem, implement a new callback
mt6359_get_playback_volsw to report user configured volume instead of
the register value.
In addition, update max of "Headset Volume" to 0x12, so it can match the
maximum seen on latest data sheet.
Signed-off-by: Trevor Wu <trevor.wu@mediatek.com>
Link: https://lore.kernel.org/r/20230508071532.21665-3-trevor.wu@mediatek.com
Signed-off-by: Mark Brown <broonie@kernel.org>
The function is improved in the way that if the firmware returns a
validation error on the newly sent bytes, then the kernel will
automatically restore to the old bytes value for a given kcontrol.
This way, if the firmware rejects a data blob then the kernel will also
reject it, instead of saving it for the next suspend/resume cycle. The
old behaviour is that the kernel would save it anyway and on next
firmware boot it would apply the previously-rejected configuration,
leading to errors during playback.
Additionally, the function also saves previously validated
configurations, so that if the firmware does end up rejecting a new
bytes value the kernel can send an old, previously-valid configuration.
Reviewed-by: Daniel Baluta <daniel.baluta@nxp.com>
Reviewed-by: Péter Ujfalusi <peter.ujfalusi@linux.intel.com>
Signed-off-by: Paul Olaru <paul.olaru@nxp.com>
Signed-off-by: Daniel Baluta <daniel.baluta@nxp.com>
Link: https://lore.kernel.org/r/20230503081049.73847-3-daniel.baluta@oss.nxp.com
Signed-off-by: Mark Brown <broonie@kernel.org>
The function is improved in the way that if the firmware returns a
validation error on the newly sent bytes, then the kernel will
automatically restore to the old bytes value for a given kcontrol.
This way, if the firmware rejects a data blob then the kernel will also
reject it, instead of saving it for the next suspend/resume cycle. The
old behaviour is that the kernel would save it anyway and on next
firmware boot it would apply the previously-rejected configuration,
leading to errors during playback.
Additionally, the function also saves previously validated
configurations, so that if the firmware does end up rejecting a new
bytes value the kernel can send an old, previously-valid configuration.
Reviewed-by: Daniel Baluta <daniel.baluta@nxp.com>
Reviewed-by: Péter Ujfalusi <peter.ujfalusi@linux.intel.com>
Signed-off-by: Paul Olaru <paul.olaru@nxp.com>
Signed-off-by: Daniel Baluta <daniel.baluta@nxp.com>
Link: https://lore.kernel.org/r/20230503081049.73847-2-daniel.baluta@oss.nxp.com
Signed-off-by: Mark Brown <broonie@kernel.org>
hda_ipc4_pre_trigger() has two issues:
1. In the default case, we are returning without unlocking the mutex.
2. In case SNDRV_PCM_TRIGGER_STOP: when ret is less than zero it goes
to out, unlocks but returns zero instead of a negative value.
Fix this by changing the final return value to 'ret' instead of zero,
and initialize 'ret' to zero in the start of the function.
Fixes: 225f37b578 ("ASoC: SOF: ipc4-pcm: reset all pipelines during FE DAI hw_free")
Signed-off-by: Harshit Mogalapalli <harshit.m.mogalapalli@oracle.com>
Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com>
Link: https://lore.kernel.org/r/20230519064404.1659637-1-harshit.m.mogalapalli@oracle.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Merge series from Amadeusz Sławiński <amadeuszx.slawinski@linux.intel.com>:
Series of patches cleaning up error messages when loading topology. In
few places instead of logging in place of failure message is logged in
caller. Additionally there are places where both caller and failing
function log error, leading to unnecessary logs. Clean all of the above
up.
Merge series from Peter Ujfalusi <peter.ujfalusi@linux.intel.com>:
The MOD_INIT_INSTANCE message contains a CPC (Cycles Per Chunk/processing unit)
parameter.
This CPC value is used by the firmware to calculate the total cycles needed by
the enabled module instances and based on this it can decide to set the
frequency of the DSP core(s).
The manifest section of the firmware image contains a module configuration
section, where a per module table of configurations are listed with measured
CPC values as triplet of IBS/IBS/CPC (Input/Output buffer size - corresponding
to the selected audio format).
In case the CPC value is 0 (missing from the manifest or the
configuration cannot be matched) the firmware will force the DSP cores
to maximum speed to avoid audio glitches due to starvation. In these
cases the kernel will print a warning message to let the SOF developers
know about the gap and provide information to correct it with a firmware
update.
Merge series from Richard Fitzgerald <rf@opensource.cirrus.com>:
First two patches are bugfixes.
Third patch skips the overhead of rebooting the amp after applying
firmware files when we know that it isn't necessary.
Each time we go through dsp_work() it does a devm_kasprintf() to
allocate memory to hold the part name string. It's not strictly a memory
leak because devm will free it all if the driver is removed. But we keep
allocating more and more memory to hold the same string.
Move the allocation so that it is performed after the version and
secured state information is gathered and handle allocation errors.
Signed-off-by: Simon Trimmer <simont@opensource.cirrus.com>
Signed-off-by: Richard Fitzgerald <rf@opensource.cirrus.com>
Link: https://lore.kernel.org/r/Message-Id: <20230518150250.1121006-2-rf@opensource.cirrus.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Merge series from Paweł Anikiel <pan@semihalf.com>:
The Google Chameleon v3 is a device made for testing audio and video
paths of other devices. This patchset adds support for ASoC audio on
this device. It has two audio sources: HDMI audio from the it68051 chip
(RX only), and analog audio from the ssm2603 chip (RX and TX).
The patchset adds the ASoC platform and codec drivers.
Merge series from Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>:
Many SoundWire CODEC drivers store the device status in a member
variable in the driver data but never reference this, and in any case
the SoundWire core stores this information for drivers so it would be
redundant even if used.
