Merge series from Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>:
The topology file and the machine driver rely on common definitions
for the dailink stream_name. To avoid any backwards-compatibility
problems, the machine driver stream names are set in stone and cannot
be modified.
This is problematic when we try to name some of the topology widgets
after the stream_name, since the widget name is limited to 44
characters
tools/include/uapi/sound/asound.h:#define SNDRV_CTL_ELEM_ID_NAME_MAXLEN 44
Existing examples include "Analog Playback and Capture" for HDaudio
dailinks, which leaves less than 20 chars to identify widgets/controls
with a meaningful name.
Since the 44-char limit is part of the UAPI definitions, we assumed
there is no way to increase it.
This patchset suggests instead a partial match which allows topology
files to use a shorter stream_name, which in turn allows for
self-explanatory widget names that comply with the 44-char limit.
This should not break any existing setup but with the introduction of
a partial match new dailinks should be named carefully to avoid
confusions between e.g. 'link1' and 'link10'. The last patch fixes
such an issue in the 'nocodec' test topology used by Intel.
Use pcm_for_each_format for the PCM format iteration and fix the
following sparse warnings.
sound/soc/ti/davinci-mcasp.c:1336:26: sparse: warning: restricted snd_pcm_format_t degrades to integer
sound/soc/ti/davinci-mcasp.c:1358:26: sparse: warning: restricted snd_pcm_format_t degrades to integer
sound/soc/ti/davinci-mcasp.c:1438:26: sparse: warning: restricted snd_pcm_format_t degrades to integer
No functional changes.
Signed-off-by: Min-Hua Chen <minhuadotchen@gmail.com>
Link: https://lore.kernel.org/r/20230519211636.3699-1-minhuadotchen@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
We have SOF and generic ACP support enabled for Vangogh platform
on some machines. Since we have same PCI id used for probing,
add check for machine configuration flag to avoid conflict with
newer pci drivers. Such machine flag has been initialized via
dmi match on few Vangogh based machines. If no flag is
specified probe and register older platform device.
Signed-off-by: Venkata Prasad Potturu <venkataprasad.potturu@amd.com>
Link: https://lore.kernel.org/r/20230530110802.674939-1-venkataprasad.potturu@amd.com
Signed-off-by: Mark Brown <broonie@kernel.org>
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.
