In etdm dai driver, dai_etdm_parse_of() function is used to parse dts
properties to get parameters. There are two for-loops which are
sepearately for all etdm and etdm input only cases. In etdm in only
loop, dai_id is not initialized, so it keeps the value intiliazed in
another loop.

In the patch, add the missing initialization to fix the unexpected
parsing problem.

Fixes: 1de9a54a ("ASoC: mediatek: mt8195: support etdm in platform driver")
Signed-off-by: Trevor Wu <trevor.wu@mediatek.com>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Link: https://lore.kernel.org/r/20230301110200.26177-3-trevor.wu@mediatek.comSigned-off-by: Mark Brown <broonie@kernel.org>

In etdm dai driver, dai_etdm_parse_of() function is used to parse dts
properties to get parameters. There are two for-loops which are
sepearately for all etdm and etdm input only cases. In etdm in only
loop, dai_id is not initialized, so it keeps the value intiliazed in
another loop.

In the patch, add the missing initialization to fix the unexpected
parsing problem.

Fixes: 2babb477 ("ASoC: mediatek: mt8188: support etdm in platform driver")
Signed-off-by: Trevor Wu <trevor.wu@mediatek.com>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Link: https://lore.kernel.org/r/20230301110200.26177-2-trevor.wu@mediatek.comSigned-off-by: Mark Brown <broonie@kernel.org>

Merge series from Mark Brown <broonie@kernel.org>:

This is a collection of fixes I came up after glancing through an
initial test run with the snappily named Kukui Jacuzzi SKU16 Chromebook
on KernelCI.  There are more issues flagged, this is just what I fixed
thus far.

Merge series from Claudiu Beznea <claudiu.beznea@microchip.com>:

To start capture on Microchip PDMC the enable bits for each supported
microphone need to be set. After this bit is set the PDMC starts to
receive data from microphones and it considers this data as valid data.
Thus if microphones are not ready the PDMC captures anyway data from its
lines. This data is interpreted by the human ear as poc noises.

To avoid this the following software workaround need to be applied when
starting capture:
1/ enable PDMC channel
2/ wait 150ms
3/ execute 16 dummy reads from RHR
4/ clear interrupts
5/ enable interrupts
6/ enable DMA channel

For this workaround to work step 6 need to be executed at the end.
For step 6 was added patch 1/3 from this series. With this, component
DAI driver sets its struct snd_soc_component_driver::start_dma_last = 1
and proper action is taken based on this flag when starting DAI trigger
vs DMA.

Merge series from Mark Brown <broonie@kernel.org>:

This is a collection of fixes I came up after glancing through an
initial test run with the snappily named Kukui Jacuzzi SKU16 Chromebook
on KernelCI.  There are more issues flagged, this is just what I fixed
thus far.

Merge series from Mark Brown <broonie@kernel.org>:

This is a collection of fixes I came up after glancing through an
initial test run with the Spherion Chromebook on KernelCI.  There are
more issues flagged, this is just what I fixed thus far - the volume
controls on the MT6359 have issues for example, and a lot of controls
aren't marked as Switches like they should be.

This model requires an additional detection quirk to enable the internal microphone.
Signed-off-by: Duc Anh Le <lub.the.studio@gmail.com>
Link: https://lore.kernel.org/r/20230227234921.7784-1-lub.the.studio@gmail.comSigned-off-by: Mark Brown <broonie@kernel.org>

Without gpiolib, this driver fails to link:

arm-linux-gnueabi-ld: sound/soc/codecs/zl38060.o: in function `chip_gpio_get':
zl38060.c:(.text+0x30): undefined reference to `gpiochip_get_data'
arm-linux-gnueabi-ld: sound/soc/codecs/zl38060.o: in function `zl38_spi_probe':
zl38060.c:(.text+0xa18): undefined reference to `devm_gpiochip_add_data_with_key'

This appears to have been in the driver since the start, but is hard to
hit in randconfig testing since gpiolib is almost always selected by something
else.

Fixes: 52e8a94b ("ASoC: Add initial ZL38060 driver")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Link: https://lore.kernel.org/r/20230227085850.2503725-1-arnd@kernel.orgSigned-off-by: Mark Brown <broonie@kernel.org>

Without modification the AT91SAM9G20-EK has no capture support, none of the
inputs of the CODEC are wired to anything to useful and there are no paths
supporting loopback. Since the audio is clocked from the CODEC and the DAPM
inputs are marked as unusable this means that capture will fail to transfer
any data as the ADC path can't be powered up.

Flag this in the device description so apps don't see unusable capture
support, guarded with the existing optional define for mic input.
Reviewed-by: Claudiu Beznea <claudiu.beznea@microchip.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Link: https://lore.kernel.org/r/20230225-asoc-sam9g20ek-v1-1-9baeb4893142@kernel.orgSigned-off-by: Mark Brown <broonie@kernel.org>

The Sidetone_Positive_Gain_dB control reports a range of 0..100 as valid
but the put() function rejects anything larger than 24. Fix this.

There are numerous other problems with this control, the name is very non
idiomatic and it should be a TLV, but it's ABI so probably we should leave
those alone.
Reviewed-by: Nícolas F. R. A. Prado <nfraprado@collabora.com>
Tested-by: Nícolas F. R. A. Prado <nfraprado@collabora.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Link: https://lore.kernel.org/r/20230223-asoc-mt8192-quick-fixes-v1-4-9a85f90368e1@kernel.orgSigned-off-by: Mark Brown <broonie@kernel.org>

Reporting an error on invalid values is optional but helpful to userspace
so do so.
Reviewed-by: Nícolas F. R. A. Prado <nfraprado@collabora.com>
Tested-by: Nícolas F. R. A. Prado <nfraprado@collabora.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Link: https://lore.kernel.org/r/20230223-asoc-mt8192-quick-fixes-v1-3-9a85f90368e1@kernel.orgSigned-off-by: Mark Brown <broonie@kernel.org>

ALSA controls put() operations should return 1 if the value changed and 0
if it remains the same, fix the mt8192 driver to do so.
Reviewed-by: Nícolas F. R. A. Prado <nfraprado@collabora.com>
Tested-by: Nícolas F. R. A. Prado <nfraprado@collabora.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Link: https://lore.kernel.org/r/20230223-asoc-mt8192-quick-fixes-v1-2-9a85f90368e1@kernel.orgSigned-off-by: Mark Brown <broonie@kernel.org>

There are a lot of info level log messages in the mt8192 ADDA driver which
are trivially triggerable from userspace, many in normal operation. Remove
these to avoid spamming the console.
Reviewed-by: Nícolas F. R. A. Prado <nfraprado@collabora.com>
Tested-by: Nícolas F. R. A. Prado <nfraprado@collabora.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Link: https://lore.kernel.org/r/20230223-asoc-mt8192-quick-fixes-v1-1-9a85f90368e1@kernel.orgSigned-off-by: Mark Brown <broonie@kernel.org>

Microchip PDMC IP doesn't filter microphone noises on startup. By default,
it captures data received from digital microphones after
the MCHP_PDMC_MR.EN bits are set. Thus when enable is set on PDMC side the
digital microphones might not be ready yet and PDMC captures data from then
in this time. This data captured is poc noise. To avoid this the software
workaround is to the following:
1/ enable PDMC channel
2/ wait 150ms (on SAMA7G5-EK setup)
3/ execute 16 dummy reads from RHR
4/ clear interrupts
5/ enable interrupts
6/ enable DMA channel

Fixes: 50291652 ("ASoC: atmel: mchp-pdmc: add PDMC driver")
Signed-off-by: Claudiu Beznea <claudiu.beznea@microchip.com>
Link: https://lore.kernel.org/r/20230228110145.3770525-4-claudiu.beznea@microchip.comSigned-off-by: Mark Brown <broonie@kernel.org>

PDMC can work with different types of microphones, thus different boards
could have different microphones. Depending on microphone type the PDMC
would need to wait longer or shorter period (at startup) than the default
chosen one to filter unwanted noise. Thus add microchip,startup-delay-us
binding to let PDMC users to specify startup delay.
Signed-off-by: Claudiu Beznea <claudiu.beznea@microchip.com>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Link: https://lore.kernel.org/r/20230228110145.3770525-3-claudiu.beznea@microchip.comSigned-off-by: Mark Brown <broonie@kernel.org>

Add option to start DMA component after DAI trigger. This is done
by filling the new struct snd_soc_component_driver::start_dma_last.
Signed-off-by: Claudiu Beznea <claudiu.beznea@microchip.com>
Link: https://lore.kernel.org/r/20230228110145.3770525-2-claudiu.beznea@microchip.comSigned-off-by: Mark Brown <broonie@kernel.org>

ALSA control put() operations should return 0 if the value changed so that
events can be generated appropriately for userspace but the custom control
in the MT8183 I2S DAI driver doesn't do that, fix it.
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Link: https://lore.kernel.org/r/20230224-asoc-mt8183-quick-fixes-v1-2-041f29419ed5@kernel.orgSigned-off-by: Mark Brown <broonie@kernel.org>

There is a lot of dev_info() logging in normal operation in the I2S DAI
driver, remove it to avoid spamming the console.
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Link: https://lore.kernel.org/r/20230224-asoc-mt8183-quick-fixes-v1-1-041f29419ed5@kernel.orgSigned-off-by: Mark Brown <broonie@kernel.org>

The HPx Mux enumerations define values 5, 6 and 7 but describe them as
"undefined" and map them to the value 0 on writing. Given the descriptions
and behaviour it seems that these values are invalid and should not be
present in the register, the current behaviour is detected as problematic
by mixer-test:

# # HPL Mux.0 expected 5 but read 0, is_volatile 0
# # HPL Mux.0 expected 6 but read 0, is_volatile 0
# # HPL Mux.0 expected 7 but read 0, is_volatile 0

Remove the values from the enumeration, this will prevent userspace setting
them.
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Link: https://lore.kernel.org/r/20230224-asoc-mt6358-quick-fixes-v1-3-747d9186be4b@kernel.orgSigned-off-by: Mark Brown <broonie@kernel.org>

Currently the Wake on Voice 2 control accepts and stores any value written
but it reports that only 0 and 1 are valid values. Reject any out of range
values written by userspace.
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Link: https://lore.kernel.org/r/20230224-asoc-mt6358-quick-fixes-v1-2-747d9186be4b@kernel.orgSigned-off-by: Mark Brown <broonie@kernel.org>

ALSA control put() operations should return 0 if the value changed so that
events can be generated appropriately for userspace but the custom control
for wake on voice stage 2 doesn't do this, fix it.
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Link: https://lore.kernel.org/r/20230224-asoc-mt6358-quick-fixes-v1-1-747d9186be4b@kernel.orgSigned-off-by: Mark Brown <broonie@kernel.org>

When we fail to obtain a DMA channel, don't return a blanket -EINVAL,
instead return the original error code if there's one. This makes
deferring work as it should. Also don't print an error message for
-EPROBE_DEFER.

Fixes: 4ec8179c ("ASoC: apple: mca: Postpone requesting of DMA channels")
Signed-off-by: Martin Povišer <povik+lin@cutebit.org>
Link: https://lore.kernel.org/r/20230224153302.45365-3-povik+lin@cutebit.orgSigned-off-by: Mark Brown <broonie@kernel.org>

Fix the reset sequence of reads and writes that we invoke from within
the early trigger. It looks like there never was a SERDES_CONF_SOME_RST
bit that should be involved in the reset sequence, and its presence in
the driver code is a mistake from earlier.

Instead, the reset sequence should go as follows: We should switch the
the SERDES unit's SYNC_SEL mux to the value of 7 (so outside the range
of 1...6 representing cluster's SYNCGEN units), then raise the RST bit
in SERDES_STATUS and wait for it to clear.

Properly resetting the SERDES unit fixes frame desynchronization hazard
in case of long frames (longer than 4 used slots). The desynchronization
manifests itself by rotating the PCM channels.

Fixes: 3df5d0d9 ("ASoC: apple: mca: Start new platform driver")
Signed-off-by: Martin Povišer <povik+lin@cutebit.org>
Link: https://lore.kernel.org/r/20230224153302.45365-2-povik+lin@cutebit.orgSigned-off-by: Mark Brown <broonie@kernel.org>

From within the early trigger we are doing a reset of the SERDES unit,
but the final status read is on a bad address. Add the missing SERDES
unit offset in calculation of the address.

Fixes: 3df5d0d9 ("ASoC: apple: mca: Start new platform driver")
Signed-off-by: Martin Povišer <povik+lin@cutebit.org>
Link: https://lore.kernel.org/r/20230224153302.45365-1-povik+lin@cutebit.orgSigned-off-by: Mark Brown <broonie@kernel.org>

The regulators are supposed to be controlled through the
set_bias_level() component callback. Moreover, the regulators are not
enabled during probe and so, this would lead to a regulator unbalanced
use count.

Fixes: ca514c0f ("ASOC: Add ADAU7118 8 Channel PDM-to-I2S/TDM Converter driver")
Signed-off-by: Nuno Sá <nuno.sa@analog.com>
Link: https://lore.kernel.org/r/20230224104551.1139981-1-nuno.sa@analog.comSigned-off-by: Mark Brown <broonie@kernel.org>

The block found on Apple's M2 SoC is compatible with the existing driver
so add its per-SoC compatible.
Signed-off-by: Janne Grunau <j@jannau.net>
Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Acked-by: Martin Povišer <povik+lin@cutebit.org>
Link: https://lore.kernel.org/r/20230202-asahi-t8112-dt-v1-14-cb5442d1c229@jannau.netSigned-off-by: Mark Brown <broonie@kernel.org>

Add mtl_mx98360a_rt5682 driver data for Chrome Rex board support.
Signed-off-by: Dharageswari.R <dharageswari.r@intel.com>
Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com>
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com>
Link: https://lore.kernel.org/r/20230220080652.23136-1-peter.ujfalusi@linux.intel.comSigned-off-by: Mark Brown <broonie@kernel.org>

In mt8188_etdm_clk_src_sel_put() function, val retrieved by FIELD_PREP
is shifted to the corresponding bit filed, so it can compare with the
register value directly.

Originally, the redundant bit shift of the register value results in
the wrong comparison result, so we remove bit shift operation in the
patch.

Fixes: 2babb477 ("ASoC: mediatek: mt8188: support etdm in platform driver")
Signed-off-by: Trevor Wu <trevor.wu@mediatek.com>
Link: https://lore.kernel.org/r/20230215125017.16044-1-trevor.wu@mediatek.comSigned-off-by: Mark Brown <broonie@kernel.org>

This device can output mono, left or right.
LR data should be swapped to output right data.
Signed-off-by: Kiseok Jo <kiseok.jo@irondevice.com>
Link: https://lore.kernel.org/r/20230217004403.10220-1-kiseok.jo@irondevice.comSigned-off-by: Mark Brown <broonie@kernel.org>

Enables display microphone on the HP OMEN 16z-n000 (8A42) laptop
Signed-off-by: Joseph Hunkeler <jhunkeler@gmail.com>
Link: https://lore.kernel.org/r/20230216155007.26143-1-jhunkeler@gmail.comSigned-off-by: Mark Brown <broonie@kernel.org>

"BRG" stands for "Baud Rate Generator", but is frequently misspelled as
"RBG".
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Acked-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Link: https://lore.kernel.org/r/ac6365c17861d71fbc89d823089db4aafdb763ed.1676470202.git.geert+renesas@glider.beSigned-off-by: Mark Brown <broonie@kernel.org>

Remove the sleep control in IRQ thread
and create an individual task to handel it for Jack plug in event.

This commit improves the control of ground switches in the AAD IRQ.
Signed-off-by: David Rau <David.Rau.opensource@dm.renesas.com>
Link: https://lore.kernel.org/r/20230215101045.21456-1-David.Rau.opensource@dm.renesas.comSigned-off-by: Mark Brown <broonie@kernel.org>

With the switching to dev_err_probe(), during the conversion
of GPIO calls, the return code is passed is a paratemer to it.
At the same time a copy'n'paste mistake was made, so the wrong
variable has been taken for the error reporting. Fix this.

Fixes: 3ee0d39c ("ASoC: soc-ac97: Convert to agnostic GPIO API")
Reported-by: kernel test robot <lkp@intel.com>
Reported-by: Dan Carpenter <error27@gmail.com>
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Link: https://lore.kernel.org/r/20230215132343.35547-1-andriy.shevchenko@linux.intel.comSigned-off-by: Mark Brown <broonie@kernel.org>

Add struct snd_pcm_substream forward declaration

Fixes: 078a85f2 ("ASoC: dapm: Only power up active channels from a DAI")
Signed-off-by: Lucas Tanure <lucas.tanure@collabora.com>
Reviewed-by: Charles Keepax <ckeepax@opensource.cirrus.com>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Link: https://lore.kernel.org/r/20230215132851.1626881-1-lucas.tanure@collabora.comSigned-off-by: Mark Brown <broonie@kernel.org>

Now tables isn't a separate module, definitely no need to have a
separate namespace for it.
Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com>
Link: https://lore.kernel.org/r/20230215105818.3315925-2-ckeepax@opensource.cirrus.comSigned-off-by: Mark Brown <broonie@kernel.org>

There is no reason to have a separate module for the tables file it just
holds regmap callbacks and register patches used by the main part of the
driver. Remove the separate module and merge it into the main driver
module.
Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com>
Link: https://lore.kernel.org/r/20230215105818.3315925-1-ckeepax@opensource.cirrus.comSigned-off-by: Mark Brown <broonie@kernel.org>

The of_gpio.h is going to be removed. In preparation of that convert
the driver to the agnostic API.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Link: https://lore.kernel.org/r/20230213161713.1450-1-andriy.shevchenko@linux.intel.comSigned-off-by: Mark Brown <broonie@kernel.org>

SSI is supporting both "PIO mode" and "DMA mode", thus "dmas/dma-names"
are not mandatory property. Drop these from rcar_sound,ssi's required:.
This is prepare for Gen4 support. See more details on Link

Link: https://lore.kernel.org/all/87zg9vk0ex.wl-kuninori.morimoto.gx@renesas.com/#r
Link: https://lore.kernel.org/all/87r0v2uvm7.wl-kuninori.morimoto.gx@renesas.com/#r
Link: https://lore.kernel.org/all/87r0v1t02h.wl-kuninori.morimoto.gx@renesas.com/#r
Link: https://lore.kernel.org/all/87y1p7bpma.wl-kuninori.morimoto.gx@renesas.com/#rSigned-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Link: https://lore.kernel.org/r/87r0uu8g8x.wl-kuninori.morimoto.gx@renesas.comSigned-off-by: Mark Brown <broonie@kernel.org>

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

The following series will enable the the Low Power Audio (LPA)
playback on Intel platforms when using IPC4.

The support is closely follows how IPC3 supports similar use case.

All depending patches are upstream and our CI have been testing
this feature for some time without issues.

Simplify code by using min helper macro for logical evaluation and value
assignment. The change also facilitates code realignment for improved
readability.
Proposed change is identified using minmax.cocci Coccinelle script.
Signed-off-by: Deepak R Varma <drv@mailo.com>
Link: https://lore.kernel.org/r/Y+p2Hn0nrtHiKwPR@ubun2204.myguest.virtualbox.orgSigned-off-by: Mark Brown <broonie@kernel.org>