The IPC message representation of an IPC4 differs from the IPC3 version
significantly.

The message for IPC4 should be written to the debugfs file in this form:
0-7 IPC4 header (2x u32)
8-  additional payload, if any

The reply is given back in the same form.

The message size limitation is the same as with the IPC3, only messages
which can fit to the mailbox can be injected (and received).
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com>
Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com>
Reviewed-by: Bard Liao <yung-chuan.liao@linux.intel.com>
Link: https://lore.kernel.org/r/20220506132647.18690-8-peter.ujfalusi@linux.intel.comSigned-off-by: Mark Brown <broonie@kernel.org>

Move out the code for sending the IPC message into a separate helper
function in preparation for support for handling IPC4 communication.
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com>
Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com>
Reviewed-by: Bard Liao <yung-chuan.liao@linux.intel.com>
Link: https://lore.kernel.org/r/20220506132647.18690-7-peter.ujfalusi@linux.intel.comSigned-off-by: Mark Brown <broonie@kernel.org>

In order to be able to send an IPC4 message, the
sof_client_ipc_tx_message() needs to parse the tx message differently to
extract the size.

The IPC notification registration is done by providing the notification
type and the whole message is passed to the client when a match is found.
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com>
Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com>
Reviewed-by: Bard Liao <yung-chuan.liao@linux.intel.com>
Link: https://lore.kernel.org/r/20220506132647.18690-6-peter.ujfalusi@linux.intel.comSigned-off-by: Mark Brown <broonie@kernel.org>

Provide a way for the client drivers to query the ipc_type used by the
firmware.
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com>
Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com>
Reviewed-by: Bard Liao <yung-chuan.liao@linux.intel.com>
Link: https://lore.kernel.org/r/20220506132647.18690-5-peter.ujfalusi@linux.intel.comSigned-off-by: Mark Brown <broonie@kernel.org>

Instead of using the SOF_IPC_MSG_MAX_SIZE as the maximum payload size for
and IPC message, use the provided API to query it.
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com>
Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com>
Reviewed-by: Bard Liao <yung-chuan.liao@linux.intel.com>
Link: https://lore.kernel.org/r/20220506132647.18690-4-peter.ujfalusi@linux.intel.comSigned-off-by: Mark Brown <broonie@kernel.org>

Instead of using the SOF_IPC_MSG_MAX_SIZE as the maximum payload size for
and IPC message, use the provided API to query it.
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com>
Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com>
Reviewed-by: Bard Liao <yung-chuan.liao@linux.intel.com>
Link: https://lore.kernel.org/r/20220506132647.18690-3-peter.ujfalusi@linux.intel.comSigned-off-by: Mark Brown <broonie@kernel.org>

Provide a way for the client drivers to query the maximum payload size of
an IPC message.
Currently clients do not have access to this information and they can only
use the SOF_IPC_MSG_MAX_SIZE defined value.
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com>
Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com>
Reviewed-by: Bard Liao <yung-chuan.liao@linux.intel.com>
Link: https://lore.kernel.org/r/20220506132647.18690-2-peter.ujfalusi@linux.intel.comSigned-off-by: Mark Brown <broonie@kernel.org>

Merge series from Nícolas F. R. A. Prado <nfraprado@collabora.com>:

These patches add properties that were missing on the dt-bindings of the
audio components used by mt8192-asurada. Namely the i2s-share
properties for the sound platform and the #sound-dai-cells on the
rt1015p and rt5682 codecs when they're referenced by the machine sound
node.

Nícolas F. R. A. Prado (3):
  ASoC: dt-bindings: mediatek: mt8192: Add i2s-share properties
  ASoC: dt-bindings: rt1015p: Add #sound-dai-cells
  ASoC: dt-bindings: rt5682: Add #sound-dai-cells

 Documentation/devicetree/bindings/sound/mt8192-afe-pcm.yaml  | 5 +++++
 Documentation/devicetree/bindings/sound/realtek,rt1015p.yaml | 3 +++
 Documentation/devicetree/bindings/sound/rt5682.txt           | 2 ++
 3 files changed, 10 insertions(+)

--
2.36.0

Simplify the return expression.
Reported-by: Zeal Robot <zealci@zte.com.cn>
Signed-off-by: Minghao Chi <chi.minghao@zte.com.cn>
Link: https://lore.kernel.org/r/20220505022102.54650-1-chi.minghao@zte.com.cnSigned-off-by: Mark Brown <broonie@kernel.org>

Simplify the return expression.
Reported-by: Zeal Robot <zealci@zte.com.cn>
Signed-off-by: Minghao Chi <chi.minghao@zte.com.cn>
Link: https://lore.kernel.org/r/20220505021808.54337-1-chi.minghao@zte.com.cnSigned-off-by: Mark Brown <broonie@kernel.org>

Simplify the return expression.
Reported-by: Zeal Robot <zealci@zte.com.cn>
Signed-off-by: Minghao Chi <chi.minghao@zte.com.cn>
Link: https://lore.kernel.org/r/20220505021733.54275-1-chi.minghao@zte.com.cnSigned-off-by: Mark Brown <broonie@kernel.org>

The rt5682 codec can be pointed to through a sound-dai property to be
used as part of a machine sound driver. dtc expects #sound-dai-cells to
be defined in the codec's node in those cases, so add it in the
dt-binding and set it to 0.
Signed-off-by: Nícolas F. R. A. Prado <nfraprado@collabora.com>
Link: https://lore.kernel.org/r/20220429203039.2207848-4-nfraprado@collabora.comSigned-off-by: Mark Brown <broonie@kernel.org>

The rt1015p codec can be pointed to through a sound-dai property to be
used as part of a machine sound driver. dtc expects #sound-dai-cells to
be defined in the codec's node in those cases, so add it in the
dt-binding and set it to 0.
Signed-off-by: Nícolas F. R. A. Prado <nfraprado@collabora.com>
Link: https://lore.kernel.org/r/20220429203039.2207848-3-nfraprado@collabora.comSigned-off-by: Mark Brown <broonie@kernel.org>

The Mediatek AFE PCM controller for MT8192 allows sharing of an I2S bus
between two busses. Add a pattern for these properties in the
dt-binding.
Signed-off-by: Nícolas F. R. A. Prado <nfraprado@collabora.com>
Link: https://lore.kernel.org/r/20220429203039.2207848-2-nfraprado@collabora.comSigned-off-by: Mark Brown <broonie@kernel.org>

Merge series from Peter Ujfalusi <peter.ujfalusi@linux.intel.com>:

The series adds the basic IPC4 message handling code, implementing the ipc
callbacks.
Due to the difference between IPC3 and IPC4 messaging we need to introduce new
message container for IPC4, but the SOF internal callbacks and structures can be
kept as they were and leaving it for the IPC specific code to handle the
differences.

The series provides the foundation for both lowe level (sound/soc/sof/intel) and
high level IPC4 implementation (topologies, firmware loading, control handling,
etc).

Instead of custom data type re-use generic struct u16_fract.
No changes intended.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Acked-by: Charles Keepax <ckeepax@opensource.cirrus.com>
Link: https://lore.kernel.org/r/20220502120455.84386-1-andriy.shevchenko@linux.intel.comSigned-off-by: Mark Brown <broonie@kernel.org>

Remove the _SHIFT for the mask definition.

Fixes: 17f2142b ("ASoC: fsl_micfil: use GENMASK to define register bit fields")
Signed-off-by: Shengjiu Wang <shengjiu.wang@nxp.com>
Acked-by: Sascha Hauer <s.hauer@pengutronix.de>
Link: https://lore.kernel.org/r/1651736047-28809-1-git-send-email-shengjiu.wang@nxp.comSigned-off-by: Mark Brown <broonie@kernel.org>

Set DMA type for ti-bcdma controller for AM62-SK.
Acked-by: Peter Ujfalusi <peter.ujfalusi@gmail.com>
Signed-off-by: Jayesh Choudhary <j-choudhary@ti.com>
Signed-off-by: Jai Luthra <j-luthra@ti.com>
Link: https://lore.kernel.org/r/20220505111226.29217-1-j-luthra@ti.comSigned-off-by: Mark Brown <broonie@kernel.org>

Introduce the initial and mandatory IPC ops support for IPC4 to enable
IPC communication with this new IPC protocol.

This patch implements the following ops:
tx_msg, rx_msg, set_get_data and get_reply.
Co-developed-by: Rander Wang <rander.wang@intel.com>
Signed-off-by: Rander Wang <rander.wang@intel.com>
Co-developed-by: Bard Liao <yung-chuan.liao@linux.intel.com>
Signed-off-by: Bard Liao <yung-chuan.liao@linux.intel.com>
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com>
Reviewed-by: Bard Liao <yung-chuan.liao@linux.intel.com>
Reviewed-by: Rander Wang <rander.wang@intel.com>
Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com>
Link: https://lore.kernel.org/r/20220505094818.10346-4-peter.ujfalusi@linux.intel.comSigned-off-by: Mark Brown <broonie@kernel.org>

The header file contains essential structure definitions, description of
bit fields and bits in the ipc4 header and an internally used ipc4 message
container definition.
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com>
Reviewed-by: Bard Liao <yung-chuan.liao@linux.intel.com>
Reviewed-by: Rander Wang <rander.wang@intel.com>
Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com>
Link: https://lore.kernel.org/r/20220505094818.10346-3-peter.ujfalusi@linux.intel.comSigned-off-by: Mark Brown <broonie@kernel.org>

The rx_data pointer can be used by IPC implementations to pass the received
message (or part of the message, like the header) from platform code to
generic, high level IPC code.

IPC4 is going to be the first user of this as its implementation on Intel
platforms detaches the header and payload and the rx cannot be handled in
a similar way as it is implemented for ipc3.

If the rx_data is dynamically allocated, it is up to the platform code to
free it up.
After the message reception handling (rx_msg ops) returned, the pointer via
the msg->rx_data should be considered as invalid.
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com>
Reviewed-by: Bard Liao <yung-chuan.liao@linux.intel.com>
Reviewed-by: Rander Wang <rander.wang@intel.com>
Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com>
Link: https://lore.kernel.org/r/20220505094818.10346-2-peter.ujfalusi@linux.intel.comSigned-off-by: Mark Brown <broonie@kernel.org>

Do not disable the boost converter during probe. The silicon
contains functional default tunings so the boost converter can
be left at the chip default enabled state.
Signed-off-by: Richard Fitzgerald <rf@opensource.cirrus.com>
Link: https://lore.kernel.org/r/20220504134458.283780-1-rf@opensource.cirrus.comSigned-off-by: Mark Brown <broonie@kernel.org>

snd_dmaengine_pcm_register() can be passed a NULL pointer for the config
which means that the we have to test for pcm->config being non NULL
before accessing it. Make the code more straight forward by providing a
default config when none is passed. With this pcm->config is never NULL
and we can skip all the if (pcm->config) tests.
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
Link: https://lore.kernel.org/r/20220502131335.2604158-1-s.hauer@pengutronix.deSigned-off-by: Mark Brown <broonie@kernel.org>

Only the main IPC ops struct should be visible outside of IPC3 code to make
sure that the code is correctly abstracted.

Instead of keeping the ipc3-ops.h with only the high level ops struct
declaration, put the ipc3_ops to sof-priv.h and move all other ops struct
declaration into ipc3-priv.h

New IPC implementation should follow this route: the main IPC ops should be
declared in sof-priv.h and no other IPC version related header be used
for generic code.
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com>
Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com>
Reviewed-by: Bard Liao <yung-chuan.liao@linux.intel.com>
Link: https://lore.kernel.org/r/20220504102831.10071-1-peter.ujfalusi@linux.intel.comSigned-off-by: Mark Brown <broonie@kernel.org>

Cleanups for the dmaengine code build on top of current fixes.

As part of the ongoing i2c transition to the simple probe
("probe_new"), this patch uses i2c_match_id to retrieve the
driver_data for the probed device. The id parameter is thus no longer
necessary and the simple probe can be used instead.

The i2c id table is moved up before the probe function, as suggested
by Wolfram Sang.
Signed-off-by: Stephen Kitt <steve@sk2.org>
Link: https://lore.kernel.org/r/20220501171009.45060-1-steve@sk2.orgSigned-off-by: Mark Brown <broonie@kernel.org>

If preparing/enabling the pclk fails, the probe function should
unprepare and disable the previously prepared and enabled mclk,
which it doesn't do. This commit rectifies this.

Fixes: c3275903 ("ASoC: rockchip: support ACODEC for rk3328")
Signed-off-by: Nicolas Frattaroli <frattaroli.nicolas@gmail.com>
Reviewed-by: Katsuhiro Suzuki <katsuhiro@katsuster.net>
Link: https://lore.kernel.org/r/20220427172310.138638-1-frattaroli.nicolas@gmail.comSigned-off-by: Mark Brown <broonie@kernel.org>

During probe, determine if the chip is in fact an ADAU1761
even though an ADAU1361 is specified, and perform additional
operations to enable the ADAU1761 to behave as an ADAU1361,
i.e. disregarding the DSP and setting up routing and PM
transparently.

This enables either chip to be mounted when an ADAU1361 is specified.
Signed-off-by: Ricard Wanderlof <ricardw@axis.com>
Link: https://lore.kernel.org/r/alpine.DEB.2.21.2204281841290.5574@lnxricardw1.se.axis.comSigned-off-by: Mark Brown <broonie@kernel.org>

It is possible to craft a topology where sof_get_control_data() would do
out of bounds access because it expects that it is only called when the
payload is bytes type.
Confusingly it also handles other types of controls, but the payload
parsing implementation is only valid for bytes.

Fix the code to count the non bytes controls and instead of storing a
pointer to sof_abi_hdr in sof_widget_data (which is only valid for bytes),
store the pointer to the data itself and add a new member to save the size
of the data.

In case of non bytes controls we store the pointer to the chanv itself,
which is just an array of values at the end.

In case of bytes control, drop the wrong cdata->data (wdata[i].pdata) check
against NULL since it is incorrect and invalid in this context.
The data is pointing to the end of cdata struct, so it should never be
null.
Reported-by: Sergey Senozhatsky <senozhatsky@chromium.org>
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com>
Reviewed-by: Sergey Senozhatsky <senozhatsky@chromium.org>
Tested-by: Sergey Senozhatsky <senozhatsky@chromium.org>
Link: https://lore.kernel.org/r/20220427185221.28928-1-peter.ujfalusi@linux.intel.comSigned-off-by: Mark Brown <broonie@kernel.org>

The driver has a custom put function for "DSP Voice Wake Up" which does
not generate event notifications on change, instead returning 0. Since we
already exit early in the case that there is no change this can be fixed
by unconditionally returning 1 at the end of the function.
Signed-off-by: Mark Brown <broonie@kernel.org>
Cc: stable@vger.kernel.org
Link: https://lore.kernel.org/r/20220428162444.3883147-1-broonie@kernel.orgSigned-off-by: Mark Brown <broonie@kernel.org>

DAPM tracks and reports the value presented to the user from DAPM controls
separately to the register value, these may diverge during initialisation
or when an autodisable control is in use.

When writing DAPM controls we currently report that a change has occurred
if either the DAPM value or the value stored in the register has changed,
meaning that if the two are out of sync we may appear to report a spurious
event to userspace. Since we use this folded in value for nothing other
than the value reported to userspace simply drop the folding in of the
register change.
Signed-off-by: Mark Brown <broonie@kernel.org>
Link: https://lore.kernel.org/r/20220428161833.3690050-1-broonie@kernel.orgSigned-off-by: Mark Brown <broonie@kernel.org>

The previous fix for event generation for custom controls compared the
value already in the register with the value being written, missing the
logic that only applies the value to the register when the control is
already enabled. Fix this, compare the value cached in the driver data
rather than the register.

This should really be an autodisable control rather than open coded.
Signed-off-by: Mark Brown <broonie@kernel.org>
Link: https://lore.kernel.org/r/20220428113221.15326-1-broonie@kernel.orgSigned-off-by: Mark Brown <broonie@kernel.org>

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

This series includes last few remaining miscellaneous patches to prepare
for the introduction of new IPC version, IPC4, in the SOF driver. The changes
include new IPC ops for topology parsing to set up the volume table, prepare
the widgets for set up and free the routes. The remaining patches introduce
new fields in the existing data structures for use in IPC4 and align the flows
for widget/route set up so that they are common for both IPC3 and IPC4.

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

This series introduces IPC abstraction for FW loading in the SOF driver
in preparation for supporting the new IPC version in the SOF firmware.

This patch adds mt8195 dsp document. The dsp is used for Sound Open
Firmware driver node. It includes registers,  clocks, memory regions,
and mailbox for dsp.
Signed-off-by: yc.hung <yc.hung@mediatek.com>
Reviewed-by: Rob Herring <robh@kernel.org>
Link: https://lore.kernel.org/r/20220106064847.15588-1-yc.hung@mediatek.comSigned-off-by: Mark Brown <broonie@kernel.org>

Fix the missing pci_release_regions() before return
from sof_pci_probe() in the error handling case.

Fixes: 4bfbbb76 ("ASOC: SOF: pci: add ipc_type override for Intel IPC4 tests")
Reported-by: Hulk Robot <hulkci@huawei.com>
Signed-off-by: Yang Yingliang <yangyingliang@huawei.com>
Link: https://lore.kernel.org/r/20220426132539.416676-1-yangyingliang@huawei.comSigned-off-by: Mark Brown <broonie@kernel.org>

Execute the firmware information query on the first boot if it is
available.
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com>
Reviewed-by: Bard Liao <yung-chuan.liao@linux.intel.com>
Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Reviewed-by: Rander Wang <rander.wang@intel.com>
Signed-off-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com>
Link: https://lore.kernel.org/r/20220425221129.124615-11-ranjani.sridharan@linux.intel.comSigned-off-by: Mark Brown <broonie@kernel.org>

The snd_sof_parse_module_memcpy() is no longer used and we have the
implementation of it in ipc3-loader.c which is a default mode to load
module(s) with IPC3 if the snd_sof_load_firmware_memcpy() is used for
loading the firmware.
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com>
Reviewed-by: Bard Liao <yung-chuan.liao@linux.intel.com>
Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Reviewed-by: Rander Wang <rander.wang@intel.com>
Signed-off-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com>
Link: https://lore.kernel.org/r/20220425221129.124615-10-ranjani.sridharan@linux.intel.comSigned-off-by: Mark Brown <broonie@kernel.org>

The used firmware loader (snd_sof_load_firmware_memcpy) can use the generic
module loading, which is by default uses the same implementation as the
snd_sof_parse_module_memcpy.

No need to set the callback for this platform.
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com>
Reviewed-by: Bard Liao <yung-chuan.liao@linux.intel.com>
Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Reviewed-by: Rander Wang <rander.wang@intel.com>
Signed-off-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com>
Link: https://lore.kernel.org/r/20220425221129.124615-9-ranjani.sridharan@linux.intel.comSigned-off-by: Mark Brown <broonie@kernel.org>

The used firmware loader (snd_sof_load_firmware_memcpy) can use the generic
module loading, which is by default uses the same implementation as the
snd_sof_parse_module_memcpy.

No need to set the callback for these platforms.
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com>
Reviewed-by: Bard Liao <yung-chuan.liao@linux.intel.com>
Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Reviewed-by: Rander Wang <rander.wang@intel.com>
Signed-off-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com>
Link: https://lore.kernel.org/r/20220425221129.124615-8-ranjani.sridharan@linux.intel.comSigned-off-by: Mark Brown <broonie@kernel.org>