The resource is checked in probe function, so there is
no need do this check in remove function.
Signed-off-by: Yang Yingliang <yangyingliang@huawei.com>
Link: https://lore.kernel.org/r/20220510124749.2663874-1-yangyingliang@huawei.comSigned-off-by: Mark Brown <broonie@kernel.org>

The driver should register a callback that will deal with the disabling
when it fails to probe.
Signed-off-by: Zheyu Ma <zheyuma97@gmail.com>
Link: https://lore.kernel.org/r/20220510053031.1685337-1-zheyuma97@gmail.comSigned-off-by: Mark Brown <broonie@kernel.org>

The ops are already part of the 'struct sdw_driver', it's unclear why
this was copied into the 'slave' structure - no other driver does so.
Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Link: https://lore.kernel.org/r/20220509185729.59884-1-pierre-louis.bossart@linux.intel.comSigned-off-by: Mark Brown <broonie@kernel.org>

Merge series from Charles Keepax <ckeepax@opensource.cirrus.com>:

Before componentisation any part registered as a CODEC would have
automatically supported both little and big endian, ie. the core
would duplicate any supported LE or BE PCM format to support the other
endian as well. As componentisation removed the distinction between
CODEC drivers and platform drivers, a flag was added to specify
if this behaviour is required for a particular component. However,
as most systems tend to use little endian the absence of the flag
is rarely noticed. Also the naming of the flag "endianness" is a
little unobvious as to if it should be applied to a particular
component.

This series adds a comment to better explain the meaning of the
flag and then tidys up the usage of the flag. A couple of uses
of the flag are removed where is has been used inappropriately
on the CPU side of the DAI link, this is clearly not valid in the
cases it has been used, and I suspect never would be valid. Then
some redundant formats are removed, since they would be covered by
existing endianness flags. And finally a bunch of devices that are
missing the flag have it added.

It is worth noting that since componenisation there are now a couple
of cases where it is not entire clear to me that the flag should
be applied to all CODECs as it was before. In those cases I haven't
updated the driver to add the flag and they are outlined here:

1) Build into the AP CODECs, these are actual silicon inside the main
processor and they typically receive audio directly from an internal
bus. It is not obvious to me that these can happily ignore endian. On
the CODEC side these include: jz4725b.c, jz4760.c, jz4770.c,
rk3328_codec.c, lpass-va-macro.c, lpass-rx-macro.c, lpass-tx-macro.c,
lpass-wsa-macro.c. There are also some examples of this scattered
around the various platform support directories in sound/soc.

2) Devices behind non-audio buses, SPI just moves bits and doesn't
really define an endian for audio data on the bus. Thus it seems the
CODEC probably can care about the endian. The only devices that fall
into this group (mostly for AoV) are: rt5514-spi.c, rt5677-spi.c,
cros_ec_codec.c (only the AoV).

3) CODECs with no DAIs, these could specify the flag and plenty of
them do; CODECs from the initial conversion to componentisation. But
the flag makes no difference here since there is nothing for it to
apply to. This includes purely analogue CODECs: aw8738.c, ssm2305.c,
tpa6130a2.c, tda7419.c, max9759.c, max9768.c, max9877.c, lm4857.c,
simple-mux.c, simple-amplifier.c. And devices that only do jack
detection: ts3a227e.c, mt6359-accdet.c.

If there are any opinions on adding the flag to any of those three
groups they would be greatfully received. But I am leaning towards
leaving 1,2 without endianness flags since it feels inappropriate,
and removing the endian flag from devices in catagory 3 that already
have it. Assuming no one objects to that I will do a follow up
series for that.

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

Hi,

The current IPC client infrastructure can only be used with IPC3.
This series carries updates for the core side of the client support to handle
IPC4 messages and updates the ipc message injector to be usable with IPC4.

The IPC flood test is only supported by SOF_IPC (IPC3), we are not going to
create the aux device for it at all if the firmware is using IPC4.

Regards,
Peter
---
Peter Ujfalusi (8):
  ASoC: SOF: sof-client: Add API to get the maximum IPC payload size
  ASoC: SOF: ipc-msg-injector: Query the maximum IPC payload size
  ASoC: SOF: sof-client-probes: Query the maximum IPC payload size
  ASoC: SOF: sof-client: Add API to get the ipc_type
  ASoC: SOF: sof-client: Add support IPC4 message sending
  ASoC: SOF: ipc-msg-injector: Separate the message sending
  ASoC: SOF: ipc-msg-injector: Add support for IPC4 messages
  ASoC: SOF: sof-client: IPC flood test can only work with SOF_IPC

 sound/soc/sof/sof-client-ipc-msg-injector.c | 181 ++++++++++++++++++--
 sound/soc/sof/sof-client-probes.c           |   5 +-
 sound/soc/sof/sof-client.c                  |  66 ++++++-
 sound/soc/sof/sof-client.h                  |   2 +
 4 files changed, 227 insertions(+), 27 deletions(-)

--
2.36.0

This reverts commit e056cf43 ("ASoC: dt-bindings: mediatek: mt8192: Add
i2s-share properties") which was merged while the property name and
definition were still being discussed. Revert the commit for now and a
follow up commit will re-add the property after it is further discussed
and reviewed.
Signed-off-by: Nícolas F. R. A. Prado <nfraprado@collabora.com>
Link: https://lore.kernel.org/r/20220509185625.580811-1-nfraprado@collabora.comSigned-off-by: Mark Brown <broonie@kernel.org>

Currently the dtrace only supported with SOF_IPC.
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/20220506130229.23354-1-peter.ujfalusi@linux.intel.comSigned-off-by: Mark Brown <broonie@kernel.org>

Log the error code when snd_soc_regster_card() fails, but fold in the
silencing of deferred probe errors.
Signed-off-by: Mark Brown <broonie@kernel.org>
Reviewed-by: Codrin Ciubotariu <codrin.ciubotariu@microchip.com>
Link: https://lore.kernel.org/r/20220506130349.451452-1-broonie@kernel.org

sound/soc/mediatek/mt8195/mt8195-mt6359.c:1639:32: warning: ‘mt8195_mt6359_max98390_rt5682_card’ defined but not used [-Wunused-variable]
 1639 | static struct mt8195_card_data mt8195_mt6359_max98390_rt5682_card = {
      |                                ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
sound/soc/mediatek/mt8195/mt8195-mt6359.c:1634:32: warning: ‘mt8195_mt6359_rt1011_rt5682_card’ defined but not used [-Wunused-variable]
 1634 | static struct mt8195_card_data mt8195_mt6359_rt1011_rt5682_card = {
      |                                ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
sound/soc/mediatek/mt8195/mt8195-mt6359.c:1629:32: warning: ‘mt8195_mt6359_rt1019_rt5682_card’ defined but not used [-Wunused-variable]
 1629 | static struct mt8195_card_data mt8195_mt6359_rt1019_rt5682_card = {
      |                                ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Since all users of this driver do need CONFIG_OF anyway, there is no
need to save a few bytes on kernel builds while CONFIG_OF disabled, so
just remove the #ifdef to fix this warning.

Fixes: 86a6b9c9 ("ASoC: mediatek: mt8195: add machine support for max98390 and rt5682")
Signed-off-by: YueHaibing <yuehaibing@huawei.com>
Acked-by: Arnd Bergmann <arnd@arndb.de>
Link: https://lore.kernel.org/r/20220509120918.9000-1-yuehaibing@huawei.comSigned-off-by: Mark Brown <broonie@kernel.org>

This adds devicetree support to the wm8940 codec driver.
With a DT-based kernel, there is no board-specific setting
to select the driver so allow it to be manually chosen.
Signed-off-by: Lukasz Majewski <lukma@denx.de>
Acked-by: Charles Keepax <ckeepax@opensource.cirrus.com>
Link: https://lore.kernel.org/r/20220509121055.31103-1-lukma@denx.deSigned-off-by: Mark Brown <broonie@kernel.org>

This commit provides documentation entry for wm8940 codec.
Signed-off-by: Lukasz Majewski <lukma@denx.de>
Acked-by: Charles Keepax <ckeepax@opensource.cirrus.com>
Link: https://lore.kernel.org/r/20220509121313.31216-1-lukma@denx.deSigned-off-by: Mark Brown <broonie@kernel.org>

Currently the ipc flood test is only supported with SOF_IPC.
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/20220506132647.18690-9-peter.ujfalusi@linux.intel.comSigned-off-by: Mark Brown <broonie@kernel.org>

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>

The endianness flag is used on the CODEC side to specify an
ambivalence to endian, typically because it is lost over the hardware
link. This device receives audio over a SoundWire DAI and as such
should have endianness applied.
Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com>
Link: https://lore.kernel.org/r/20220504170905.332415-39-ckeepax@opensource.cirrus.comSigned-off-by: Mark Brown <broonie@kernel.org>

The endianness flag is used on the CODEC side to specify an
ambivalence to endian, typically because it is lost over the hardware
link. This device receives audio over a SoundWire DAI and as such
should have endianness applied.
Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com>
Link: https://lore.kernel.org/r/20220504170905.332415-38-ckeepax@opensource.cirrus.comSigned-off-by: Mark Brown <broonie@kernel.org>

The endianness flag is used on the CODEC side to specify an
ambivalence to endian, typically because it is lost over the hardware
link. This device receives audio over a SoundWire DAI and as such
should have endianness applied.
Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com>
Link: https://lore.kernel.org/r/20220504170905.332415-37-ckeepax@opensource.cirrus.comSigned-off-by: Mark Brown <broonie@kernel.org>

The endianness flag is used on the CODEC side to specify an
ambivalence to endian, typically because it is lost over the hardware
link. This device receives audio over a SoundWire DAI and as such
should have endianness applied.
Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com>
Link: https://lore.kernel.org/r/20220504170905.332415-36-ckeepax@opensource.cirrus.comSigned-off-by: Mark Brown <broonie@kernel.org>

The endianness flag is used on the CODEC side to specify an
ambivalence to endian, typically because it is lost over the hardware
link. This device receives audio over a SoundWire DAI and as such
should have endianness applied.
Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com>
Link: https://lore.kernel.org/r/20220504170905.332415-35-ckeepax@opensource.cirrus.comSigned-off-by: Mark Brown <broonie@kernel.org>

The endianness flag is used on the CODEC side to specify an
ambivalence to endian, typically because it is lost over the hardware
link. This device receives audio over a SoundWire DAI and as such
should have endianness applied.
Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com>
Link: https://lore.kernel.org/r/20220504170905.332415-34-ckeepax@opensource.cirrus.comSigned-off-by: Mark Brown <broonie@kernel.org>

The endianness flag is used on the CODEC side to specify an
ambivalence to endian, typically because it is lost over the hardware
link. This device receives audio over a SoundWire DAI and as such
should have endianness applied.
Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com>
Link: https://lore.kernel.org/r/20220504170905.332415-33-ckeepax@opensource.cirrus.comSigned-off-by: Mark Brown <broonie@kernel.org>

The endianness flag is used on the CODEC side to specify an
ambivalence to endian, typically because it is lost over the hardware
link. This device receives audio over a SoundWire DAI and as such
should have endianness applied.
Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com>
Link: https://lore.kernel.org/r/20220504170905.332415-32-ckeepax@opensource.cirrus.comSigned-off-by: Mark Brown <broonie@kernel.org>

The endianness flag is used on the CODEC side to specify an
ambivalence to endian, typically because it is lost over the hardware
link. This device receives audio over a SoundWire DAI and as such
should have endianness applied.
Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com>
Link: https://lore.kernel.org/r/20220504170905.332415-31-ckeepax@opensource.cirrus.comSigned-off-by: Mark Brown <broonie@kernel.org>

The endianness flag is used on the CODEC side to specify an
ambivalence to endian, typically because it is lost over the hardware
link. This device receives audio over a SoundWire DAI and as such
should have endianness applied.
Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com>
Link: https://lore.kernel.org/r/20220504170905.332415-30-ckeepax@opensource.cirrus.comSigned-off-by: Mark Brown <broonie@kernel.org>

The endianness flag is used on the CODEC side to specify an
ambivalence to endian, typically because it is lost over the hardware
link. This device receives audio over a SLIMbus DAI and as such should
have endianness applied.
Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com>
Link: https://lore.kernel.org/r/20220504170905.332415-29-ckeepax@opensource.cirrus.comSigned-off-by: Mark Brown <broonie@kernel.org>

The endianness flag is used on the CODEC side to specify an
ambivalence to endian, typically because it is lost over the hardware
link. This device receives audio over a SLIMbus DAI and as such should
have endianness applied.
Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com>
Link: https://lore.kernel.org/r/20220504170905.332415-28-ckeepax@opensource.cirrus.comSigned-off-by: Mark Brown <broonie@kernel.org>

The endianness flag is used on the CODEC side to specify an
ambivalence to endian, typically because it is lost over the hardware
link. The i2s_rx component receives audio over an I2S DAI and as such
should have endianness applied.

A fixup is also required to use the width directly rather than relying
on the format in hw_params, now both little and big endian would be
supported.
Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com>
Link: https://lore.kernel.org/r/20220504170905.332415-27-ckeepax@opensource.cirrus.comSigned-off-by: Mark Brown <broonie@kernel.org>

The endianness flag is used on the CODEC side to specify an
ambivalence to endian, typically because it is lost over the hardware
link. This device receives audio over an I2S DAI and as such should
have endianness applied.

A fixup is also required to use the width directly rather than relying
on the format in hw_params, now both little and big endian would be
supported. It is worth noting this changes the behaviour of S24_LE to
use a word length of 24 rather than 32. This would appear to be a
correction since the fact S24_LE is stored as 32 bits should not be
presented over the bus.
Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com>
Link: https://lore.kernel.org/r/20220504170905.332415-26-ckeepax@opensource.cirrus.comSigned-off-by: Mark Brown <broonie@kernel.org>