To avoid misleading file names, use different names for INTEL_IPC4
firmware files.
Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Reviewed-by: Bard Liao <yung-chuan.liao@linux.intel.com>
Reviewed-by: Rander Wang <rander.wang@intel.com>
Reviewed-by: Péter Ujfalusi <peter.ujfalusi@linux.intel.com>
Reviewed-by: Chao Song <chao.song@intel.com>
Link: https://lore.kernel.org/r/20220414184817.362215-5-pierre-louis.bossart@linux.intel.comSigned-off-by: Mark Brown <broonie@kernel.org>

This patch adds a default IPC type for each platform, along with file
paths to be used for each IPC type. To make reviews simpler, we only
modify platform descriptors in this table, the information will be
used in the next patch.

The Intel IPCv4 is only supported on Intel platforms after APL, and
not by default. In follow-up patches, support for SKL and KBL will be
added, and in those two cases the IPCv4 will be the default (and only
supported mode).
Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Reviewed-by: Bard Liao <yung-chuan.liao@linux.intel.com>
Reviewed-by: Rander Wang <rander.wang@intel.com>
Reviewed-by: Péter Ujfalusi <peter.ujfalusi@linux.intel.com>
Link: https://lore.kernel.org/r/20220414184817.362215-4-pierre-louis.bossart@linux.intel.comSigned-off-by: Mark Brown <broonie@kernel.org>

With the addition of the IPCv4, we need the ability to select
different paths for firmware and topologies.

First add an indirection. Follow-up patches will add mechanisms to
select a default IPC or override it.

No functionality change in this patch.
Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Reviewed-by: Bard Liao <yung-chuan.liao@linux.intel.com>
Reviewed-by: Rander Wang <rander.wang@intel.com>
Reviewed-by: Péter Ujfalusi <peter.ujfalusi@linux.intel.com>
Link: https://lore.kernel.org/r/20220414184817.362215-3-pierre-louis.bossart@linux.intel.comSigned-off-by: Mark Brown <broonie@kernel.org>

Add enum type to allow for different types of IPCs. The IPCv4 is
intended for Intel only as a convergence path with firmware used in
Windows. Follow-up patches will introduce different abstractions with
.ops and different search paths for firmware and topology files.
Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Reviewed-by: Bard Liao <yung-chuan.liao@linux.intel.com>
Reviewed-by: Rander Wang <rander.wang@intel.com>
Reviewed-by: Péter Ujfalusi <peter.ujfalusi@linux.intel.com>
Link: https://lore.kernel.org/r/20220414184817.362215-2-pierre-louis.bossart@linux.intel.comSigned-off-by: Mark Brown <broonie@kernel.org>

snd_soc_card_jack_new() allowed to create jack kcontrol without pins,
but did not create kcontrols. The jack would not have kcontrols if pins
were not going to be added.

This renames the old snd_soc_card_jack_new() to
snd_soc_card_jack_new_pins() for use when pins are provided or will be
added later. The new snd_soc_card_jack_new() appropriately creates a
jack for use without pins and adds a kcontrol.
Signed-off-by: Akihiko Odaki <akihiko.odaki@gmail.com>
Link: https://lore.kernel.org/r/20220408041114.6024-1-akihiko.odaki@gmail.comSigned-off-by: Mark Brown <broonie@kernel.org>

The driver should use the pci_resource_len() to get the actual length of
pci bar, and compare it with the expect value. If the bar size is too
small (such as a broken device), the driver should return an error.
Signed-off-by: Zheyu Ma <zheyuma97@gmail.com>
Link: https://lore.kernel.org/r/20220409143950.2570186-1-zheyuma97@gmail.comSigned-off-by: Mark Brown <broonie@kernel.org>

The driver, OMAP1 specific, now omits clk_prepare/unprepare() steps, not
supported by OMAP1 custom implementation of clock API.  However, non-CCF
stubs of those functions exist for use on such platforms until converted
to CCF.

Update the driver to be compatible with CCF implementation of clock API.
Signed-off-by: Janusz Krzysztofik <jmkrzyszt@gmail.com>
Acked-by: Peter Ujfalusi <peter.ujfalusi@gmail.com>
Link: https://lore.kernel.org/r/20220407191202.46206-1-jmkrzyszt@gmail.comSigned-off-by: Mark Brown <broonie@kernel.org>

Using pm_runtime_resume_and_get is more appropriate
for simplifing code
Reported-by: Zeal Robot <zealci@zte.com.cn>
Signed-off-by: Minghao Chi <chi.minghao@zte.com.cn>
Acked-by: Shengjiu Wang <shengjiu.wang@gmail.com>
Link: https://lore.kernel.org/r/20220412083000.2532711-1-chi.minghao@zte.com.cnSigned-off-by: Mark Brown <broonie@kernel.org>

The word "or" is useless and breaks yaml validation.
Signed-off-by: Corentin Labbe <clabbe@baylibre.com>
Link: https://lore.kernel.org/r/20220411194409.3390002-1-clabbe@baylibre.comSigned-off-by: Mark Brown <broonie@kernel.org>

Merge series from Stephen Kitt <steve@sk2.org>:

This series covers all the remaining changes to migrate
sound/soc/codecs i2c probes to probe_new, where the const struct
i2c_client * argument is unused; there are a few remaining files which
use the argument and will need i2c_match_id migration.

Merge series from Ranjani Sridharan <ranjani.sridharan@linux.intel.com>:

This series is continuation of the IPC abstraction in the SOF driver in
preparation for supporting the new IPC supported by the SOF firmware.
It introduces abstraction for top-level IPC ops for sending/receiving
regular and large IPC's.

Peter Ujfalusi (15):
  ASoC: SOF: Add helper function to prepare and send an IPC message
  ASoC: SOF: Add high level IPC IO callback definitions to ipc_ops
  ASoC: SOF: ipc3: Implement the tx_msg IPC ops
  ASoC: SOF: ipc3: Use sof_ipc3_tx_msg() internally for message sending
  ASoC: SOF: ipc3: Implement the set_get_data IPC ops
  ASoC: SOF: ipc3: Implement the get_reply IPC ops
  ASoC: SOF: ipc3: Implement rx_msg IPC ops
  ASoC: SOF: ipc: Separate the ops checks by functions/topics
  ASoC: SOF: ipc: Add check for mandatory IPC message handling ops
  ASoC: SOF: ipc: Use the get_reply ops in snd_sof_ipc_get_reply()
  ASoC: SOF: ipc: Switch over to use the tx_msg and set_get_data ops
  ASoC: SOF: ipc: Switch over to use the rx_msg ops
  ASoC: SOF: Add widget_kcontrol_setup control ops for IPC3
  ASoC: SOF: sof-audio: Use the widget_kcontrol_setup ops for kcontrol
    set up
  ASoC: SOF: ipc: Move the ipc_set_get_comp_data() local to ipc3-control

 sound/soc/sof/ipc.c          | 858 ++---------------------------------
 sound/soc/sof/ipc3-control.c | 131 +++++-
 sound/soc/sof/ipc3.c         | 682 +++++++++++++++++++++++++++-
 sound/soc/sof/sof-audio.c    |  54 +--
 sound/soc/sof/sof-audio.h    |   7 +-
 sound/soc/sof/sof-priv.h     |  28 +-
 6 files changed, 880 insertions(+), 880 deletions(-)

--
2.25.1

Merge series from Mario Limonciello <mario.limonciello@amd.com>:

It's not possible to probe for the presence of a DMIC, so the ACP6x
machine driver currently has a hardcoded list of all the systems known
to have a DMIC connected to the ACP.

Although this design works it means that the acp6x driver needs to always
grow with more systems and worse, if an OEM introduces a new system there
will be a mismatch in time that even if the driver (otherwise) works fine
it needs their system added to the list to work.

So this series introduces a _DSD that OEMs can populate into the BIOS to
indicate presence of a DMIC.

Use the new EXPORT_SYMBOL_NS_GPL() for exports from the set of
drivers for cs35l45.
Signed-off-by: Richard Fitzgerald <rf@opensource.cirrus.com>
Link: https://lore.kernel.org/r/20220411165929.1302333-1-rf@opensource.cirrus.comSigned-off-by: Mark Brown <broonie@kernel.org>

sound/soc/tegra/tegra186_asrc.c:90:12: error: ‘tegra186_asrc_runtime_resume’ defined but not used [-Werror=unused-function]
 static int tegra186_asrc_runtime_resume(struct device *dev)
            ^~~~~~~~~~~~~~~~~~~~~~~~~~~~
sound/soc/tegra/tegra186_asrc.c:80:12: error: ‘tegra186_asrc_runtime_suspend’ defined but not used [-Werror=unused-function]
 static int tegra186_asrc_runtime_suspend(struct device *dev)
            ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Mark these functions as __maybe_unused to avoid this kind of warning.

Fixes: a2df8c2d ("ASoC: tegra: Add Tegra186 based ASRC driver")
Signed-off-by: YueHaibing <yuehaibing@huawei.com>
Reviewed-by: Sameer Pujar <spujar@nvidia.com>
Link: https://lore.kernel.org/r/20220411020908.580-1-yuehaibing@huawei.comSigned-off-by: Mark Brown <broonie@kernel.org>

Update PCI revision id check for the new YC platform varaint.
Signed-off-by: Vijendar Mukunda <Vijendar.Mukunda@amd.com>
Link: https://lore.kernel.org/r/20220411134119.1767646-1-Vijendar.Mukunda@amd.comSigned-off-by: Mark Brown <broonie@kernel.org>

The i2c probe functions here don't use the id information provided in
their second argument, so the single-parameter i2c probe function
("probe_new") can be used instead.

This avoids scanning the identifier tables during probes.
Signed-off-by: Stephen Kitt <steve@sk2.org>
Link: https://lore.kernel.org/r/20220405165836.2165310-15-steve@sk2.orgSigned-off-by: Mark Brown <broonie@kernel.org>

The i2c probe functions here don't use the id information provided in
their second argument, so the single-parameter i2c probe function
("probe_new") can be used instead.

This avoids scanning the identifier tables during probes.
Signed-off-by: Stephen Kitt <steve@sk2.org>
Link: https://lore.kernel.org/r/20220405165836.2165310-14-steve@sk2.orgSigned-off-by: Mark Brown <broonie@kernel.org>

The i2c probe functions here don't use the id information provided in
their second argument, so the single-parameter i2c probe function
("probe_new") can be used instead.

This avoids scanning the identifier tables during probes.
Signed-off-by: Stephen Kitt <steve@sk2.org>
Link: https://lore.kernel.org/r/20220405165836.2165310-13-steve@sk2.orgSigned-off-by: Mark Brown <broonie@kernel.org>

The i2c probe functions here don't use the id information provided in
their second argument, so the single-parameter i2c probe function
("probe_new") can be used instead.

This avoids scanning the identifier tables during probes.
Signed-off-by: Stephen Kitt <steve@sk2.org>
Link: https://lore.kernel.org/r/20220405165836.2165310-12-steve@sk2.orgSigned-off-by: Mark Brown <broonie@kernel.org>

The i2c probe functions here don't use the id information provided in
their second argument, so the single-parameter i2c probe function
("probe_new") can be used instead.

This avoids scanning the identifier tables during probes.
Signed-off-by: Stephen Kitt <steve@sk2.org>
Link: https://lore.kernel.org/r/20220405165836.2165310-11-steve@sk2.orgSigned-off-by: Mark Brown <broonie@kernel.org>

The i2c probe functions here don't use the id information provided in
their second argument, so the single-parameter i2c probe function
("probe_new") can be used instead.

This avoids scanning the identifier tables during probes.
Signed-off-by: Stephen Kitt <steve@sk2.org>
Link: https://lore.kernel.org/r/20220405165836.2165310-10-steve@sk2.orgSigned-off-by: Mark Brown <broonie@kernel.org>

The i2c probe functions here don't use the id information provided in
their second argument, so the single-parameter i2c probe function
("probe_new") can be used instead.

This avoids scanning the identifier tables during probes.
Signed-off-by: Stephen Kitt <steve@sk2.org>
Link: https://lore.kernel.org/r/20220405165836.2165310-9-steve@sk2.orgSigned-off-by: Mark Brown <broonie@kernel.org>

The i2c probe functions here don't use the id information provided in
their second argument, so the single-parameter i2c probe function
("probe_new") can be used instead.

This avoids scanning the identifier tables during probes.
Signed-off-by: Stephen Kitt <steve@sk2.org>
Link: https://lore.kernel.org/r/20220405165836.2165310-8-steve@sk2.orgSigned-off-by: Mark Brown <broonie@kernel.org>

The i2c probe functions here don't use the id information provided in
their second argument, so the single-parameter i2c probe function
("probe_new") can be used instead.

This avoids scanning the identifier tables during probes.
Signed-off-by: Stephen Kitt <steve@sk2.org>
Link: https://lore.kernel.org/r/20220405165836.2165310-7-steve@sk2.orgSigned-off-by: Mark Brown <broonie@kernel.org>

The i2c probe functions here don't use the id information provided in
their second argument, so the single-parameter i2c probe function
("probe_new") can be used instead.

This avoids scanning the identifier tables during probes.
Signed-off-by: Stephen Kitt <steve@sk2.org>
Link: https://lore.kernel.org/r/20220405165836.2165310-6-steve@sk2.orgSigned-off-by: Mark Brown <broonie@kernel.org>

The i2c probe functions here don't use the id information provided in
their second argument, so the single-parameter i2c probe function
("probe_new") can be used instead.

This avoids scanning the identifier tables during probes.
Signed-off-by: Stephen Kitt <steve@sk2.org>
Link: https://lore.kernel.org/r/20220405165836.2165310-5-steve@sk2.orgSigned-off-by: Mark Brown <broonie@kernel.org>

The i2c probe functions here don't use the id information provided in
their second argument, so the single-parameter i2c probe function
("probe_new") can be used instead.

This avoids scanning the identifier tables during probes.
Signed-off-by: Stephen Kitt <steve@sk2.org>
Link: https://lore.kernel.org/r/20220405165836.2165310-4-steve@sk2.orgSigned-off-by: Mark Brown <broonie@kernel.org>

The i2c probe functions here don't use the id information provided in
their second argument, so the single-parameter i2c probe function
("probe_new") can be used instead.

This avoids scanning the identifier tables during probes.
Signed-off-by: Stephen Kitt <steve@sk2.org>
Link: https://lore.kernel.org/r/20220405165836.2165310-3-steve@sk2.orgSigned-off-by: Mark Brown <broonie@kernel.org>

The i2c probe functions here don't use the id information provided in
their second argument, so the single-parameter i2c probe function
("probe_new") can be used instead.

This avoids scanning the identifier tables during probes.
Signed-off-by: Stephen Kitt <steve@sk2.org>
Link: https://lore.kernel.org/r/20220405165836.2165310-2-steve@sk2.orgSigned-off-by: Mark Brown <broonie@kernel.org>

Currently the acp6x machine driver requires a hardcoded list of systems
that physically have DMIC connected.

To avoid having to continually add to an evergrowing list of systems add
support for a _DSD that can advertise this.

OEMs can add this _DSD to their BIOS under the ACP device to automatically
add the device to this driver without requiring any driver modifications.
Signed-off-by: Mario Limonciello <mario.limonciello@amd.com>
Link: https://lore.kernel.org/r/20220411134532.13538-3-mario.limonciello@amd.comSigned-off-by: Mark Brown <broonie@kernel.org>

Currently all of the quirked systems use the same card and so the
DMI quirk list doesn't contain driver data.

Add driver data to these quirks and then check the data was present
or not.  This will allow potentially setting quirks for systems with
faulty firmware that claims to have a DMIC but doesn't really.
Signed-off-by: Mario Limonciello <mario.limonciello@amd.com>
Link: https://lore.kernel.org/r/20220411134532.13538-2-mario.limonciello@amd.comSigned-off-by: Mark Brown <broonie@kernel.org>

The snd_sof_ipc_set_get_comp_data() only used for kcontrol data update
and it is an IPC3 message parsing function.

Move it out from the generic ipc.c to ipc3-control.c and rename it to
better describe it's function.
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com>
Reviewed-by: Daniel Baluta <daniel.baluta@nxp.com>
Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Signed-off-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com>
Link: https://lore.kernel.org/r/20220405172708.122168-16-ranjani.sridharan@linux.intel.comSigned-off-by: Mark Brown <broonie@kernel.org>

Remove the local implementation and switch to the IPC neutral ops to
set up the kcontrols associated with the swidget.

The set up call uses snd_sof_ipc_set_get_comp_data() which is largely an
IPC3 parsing function.
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com>
Reviewed-by: Daniel Baluta <daniel.baluta@nxp.com>
Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Signed-off-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com>
Link: https://lore.kernel.org/r/20220405172708.122168-15-ranjani.sridharan@linux.intel.comSigned-off-by: Mark Brown <broonie@kernel.org>

Define and set the widget_kcontrol_setup control IPC ops for IPC3.

The widget_kcontrol_setup callback can be used to set up all
kcontrols associated with the swidget.
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com>
Reviewed-by: Daniel Baluta <daniel.baluta@nxp.com>
Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Signed-off-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com>
Link: https://lore.kernel.org/r/20220405172708.122168-14-ranjani.sridharan@linux.intel.comSigned-off-by: Mark Brown <broonie@kernel.org>

Use the new ops for handling message reception.
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com>
Reviewed-by: Daniel Baluta <daniel.baluta@nxp.com>
Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Signed-off-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com>
Link: https://lore.kernel.org/r/20220405172708.122168-13-ranjani.sridharan@linux.intel.comSigned-off-by: Mark Brown <broonie@kernel.org>

Use the new ops for sending messages and to handle large component data
set get operation.
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com>
Reviewed-by: Daniel Baluta <daniel.baluta@nxp.com>
Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Signed-off-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com>
Link: https://lore.kernel.org/r/20220405172708.122168-12-ranjani.sridharan@linux.intel.comSigned-off-by: Mark Brown <broonie@kernel.org>

Use the get_reply ops to allow IPC dependent handling of the reply message.
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com>
Reviewed-by: Daniel Baluta <daniel.baluta@nxp.com>
Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Signed-off-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com>
Link: https://lore.kernel.org/r/20220405172708.122168-11-ranjani.sridharan@linux.intel.comSigned-off-by: Mark Brown <broonie@kernel.org>

Make sure that the mandatory IPC message handling ops are provided by the
IPC implementation.
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com>
Reviewed-by: Daniel Baluta <daniel.baluta@nxp.com>
Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Signed-off-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com>
Link: https://lore.kernel.org/r/20220405172708.122168-10-ranjani.sridharan@linux.intel.comSigned-off-by: Mark Brown <broonie@kernel.org>

Separate the mandatory ops checks by topics (pcm and topology for now) to
be able to provide intuitive feedback on the possible missing ops and to
make it easier to add new mandatory ops checks in the future.
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com>
Reviewed-by: Daniel Baluta <daniel.baluta@nxp.com>
Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Signed-off-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com>
Link: https://lore.kernel.org/r/20220405172708.122168-9-ranjani.sridharan@linux.intel.comSigned-off-by: Mark Brown <broonie@kernel.org>

Add the implementation for the rx_msg callback to handle message reception
for IPC3.

The implementation is equivalent to the currently used code in ipc.c
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com>
Reviewed-by: Daniel Baluta <daniel.baluta@nxp.com>
Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Signed-off-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com>
Link: https://lore.kernel.org/r/20220405172708.122168-8-ranjani.sridharan@linux.intel.comSigned-off-by: Mark Brown <broonie@kernel.org>