The values set by set_dai_fmt() and hw_params() seem to be tailored only
for 32-bit formats. Negotiate the correct ones in hw_params() callback
instead.

This was essentially copied from the OLPC kernel driver and tested to
fix wrong audio output for non-32bit formats. The documentation is not
available.
Signed-off-by: Lubomir Rintel <lkundrak@v3.sk>
Link: https://lore.kernel.org/r/20200511210134.1224532-10-lkundrak@v3.skSigned-off-by: Mark Brown <broonie@kernel.org>

Only turn on the Audio island when it's in use.

This requires keeping track of control register contents instead of
reloading them back from hardware, because they're lost when the power is
off.
Signed-off-by: Lubomir Rintel <lkundrak@v3.sk>
Link: https://lore.kernel.org/r/20200511210134.1224532-9-lkundrak@v3.skSigned-off-by: Mark Brown <broonie@kernel.org>

The driver enables the clocks without preparing them and disables
without unpreparing afterwards. Fix that.
Signed-off-by: Lubomir Rintel <lkundrak@v3.sk>
Link: https://lore.kernel.org/r/20200511210134.1224532-8-lkundrak@v3.skSigned-off-by: Mark Brown <broonie@kernel.org>

The "serial port" it represents is actually a SPI controller -- it's not
clear why would the audio serial interface embed it. We're only using
the mmio_base and clk fields.
Signed-off-by: Lubomir Rintel <lkundrak@v3.sk>
Link: https://lore.kernel.org/r/20200511210134.1224532-7-lkundrak@v3.skSigned-off-by: Mark Brown <broonie@kernel.org>

This makes the driver usable with the mmp_tdma drier via
soc-generic-dmaengine-pcm. This is conditionalized on DT node (support
for DT is added by a later patch).

A custom mmap callback that creates a NC mapping is used instead of the
default WC one, because with write-combining some bytes don't seem to
make it through for reasons unknown to me.
Signed-off-by: Lubomir Rintel <lkundrak@v3.sk>
Link: https://lore.kernel.org/r/20200511210134.1224532-6-lkundrak@v3.skSigned-off-by: Mark Brown <broonie@kernel.org>

This makes things simpler. There's no reason not to just embed the struct
snd_dmaengine_dai_dma_data in struct sspa_priv and do away with an
unnecessary kmalloc(). While at that, we can initialize the
snd_dmaengine_dai_dma_data structures earlier.

Let's also stop offsetting the source/destination of the DMA transfer by
phys_base. Firstly, it's never set and is always zero. Secondly, the
hardware actually ignores it, at least on a MMP2 and MMP3.
Signed-off-by: Lubomir Rintel <lkundrak@v3.sk>
Link: https://lore.kernel.org/r/20200511210134.1224532-5-lkundrak@v3.skSigned-off-by: Mark Brown <broonie@kernel.org>

"Transmit", not "Tansmit".
Signed-off-by: Lubomir Rintel <lkundrak@v3.sk>
Link: https://lore.kernel.org/r/20200511210134.1224532-4-lkundrak@v3.skSigned-off-by: Mark Brown <broonie@kernel.org>

If an error occurs after the call to 'omap_mcbsp_init()', the reference to
'mcbsp->fclk' must be decremented, as already done in the remove function.

This can be achieved easily by using the devm_ variant of 'clk_get()'
when the reference is taken in 'omap_mcbsp_init()'

This fixes the leak in the probe and has the side effect to simplify both
the error handling path of 'omap_mcbsp_init()' and the remove function.
Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Acked-by: Peter Ujfalusi <peter.ujflausi@ti.com>
Link: https://lore.kernel.org/r/20200512134325.252073-1-christophe.jaillet@wanadoo.frSigned-off-by: Mark Brown <broonie@kernel.org>

With 'ASoC: Intel: Skylake: Fix HDaudio and Dmic' series applied,
warning is no longer true. Remove it and update the description.
Signed-off-by: Cezary Rojewski <cezary.rojewski@intel.com>
Link: https://lore.kernel.org/r/20200506212114.8502-1-cezary.rojewski@intel.comSigned-off-by: Mark Brown <broonie@kernel.org>

The description below is already in use for rk3308.dtsi,
but was somehow never added to a document, so add
"rockchip,rk3308-i2s", "rockchip,rk3066-i2s"
for i2s nodes on a rk3308 platform to rockchip-i2s.yaml.
One of the rk3308 i2s nodes also has a different dma layout,
so change that as well.
Signed-off-by: Johan Jonker <jbx6244@gmail.com>
Link: https://lore.kernel.org/r/20200507113238.7904-1-jbx6244@gmail.comSigned-off-by: Mark Brown <broonie@kernel.org>

There are 2 issues here:
   - if one of the 'of_parse_phandle' fails, calling 'mop500_of_node_put()'
     is a no-op because the 'mop500_dai_links' structure has not been
     initialized yet, so the referenced are not decremented
   - The reference stored in 'mop500_dai_links[i].codecs' is refcounted
     only once in the probe and must be decremented only once.

Fixes: 39013bd6 ("ASoC: Ux500: Dispose of device nodes correctly")
Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Link: https://lore.kernel.org/r/20200512100705.246349-1-christophe.jaillet@wanadoo.frSigned-off-by: Mark Brown <broonie@kernel.org>

The current codebase makes use of the zero-length array language
extension to the C90 standard, but the preferred mechanism to declare
variable-length types such as these ones is a flexible array member[1][2],
introduced in C99:

struct foo {
        int stuff;
        struct boo array[];
};

By making use of the mechanism above, we will get a compiler warning
in case the flexible array does not occur last in the structure, which
will help us prevent some kind of undefined behavior bugs from being
inadvertently introduced[3] to the codebase from now on.

Also, notice that, dynamic memory allocations won't be affected by
this change:

"Flexible array members have incomplete type, and so the sizeof operator
may not be applied. As a quirk of the original implementation of
zero-length arrays, sizeof evaluates to zero."[1]

sizeof(flexible-array-member) triggers a warning because flexible array
members have incomplete type[1]. There are some instances of code in
which the sizeof operator is being incorrectly/erroneously applied to
zero-length arrays and the result is zero. Such instances may be hiding
some bugs. So, this work (flexible-array member conversions) will also
help to get completely rid of those sorts of issues.

This issue was found with the help of Coccinelle.

[1] https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html
[2] https://github.com/KSPP/linux/issues/21
[3] commit 76497732 ("cxgb3/l2t: Fix undefined behaviour")
Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
Acked-by: Cezary Rojewski <cezary.rojewski@intel.com>
Link: https://lore.kernel.org/r/20200511174647.GA17318@embeddedorSigned-off-by: Mark Brown <broonie@kernel.org>

Merge branch 'for-5.7' of https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound into asoc-5.8

It does nothing, because the corresponding bit s not flipped on in .formats
and the audio SRAM DMA engine is not able to handle 20-bit transfers
anyway.
Signed-off-by: Lubomir Rintel <lkundrak@v3.sk>
Link: https://lore.kernel.org/r/20200511210134.1224532-3-lkundrak@v3.skSigned-off-by: Mark Brown <broonie@kernel.org>

The hw_params() callback handles the 3-byte format, not
SNDRV_PCM_FMTBIT_S24_LE.
Signed-off-by: Lubomir Rintel <lkundrak@v3.sk>
Link: https://lore.kernel.org/r/20200511210134.1224532-2-lkundrak@v3.skSigned-off-by: Mark Brown <broonie@kernel.org>

In order to fix issue described in:
"ASoC: Intel: sst: ipc command timeout"
https://patchwork.kernel.org/patch/11482829/

use readq function, which is meant to read 64 bit values from registers.
On 32 bit platforms it falls back to two readl calls.
Reported-by: Brent Lu <brent.lu@intel.com>
Signed-off-by: Amadeusz Sławiński <amadeuszx.slawinski@linux.intel.com>
Tested-by: Brent Lu <brent.lu@intel.com>
Acked-by: Cezary Rojewski <cezary.rojewski@intel.com>
Link: https://lore.kernel.org/r/20200507133405.32251-2-amadeuszx.slawinski@linux.intel.comSigned-off-by: Mark Brown <broonie@kernel.org>

Baytrail has 64 bit registers, so we should use *read64* to read from it
and then use proper mask values to check status.
Signed-off-by: Amadeusz Sławiński <amadeuszx.slawinski@linux.intel.com>
Tested-by: Brent Lu <brent.lu@intel.com>
Acked-by: Cezary Rojewski <cezary.rojewski@intel.com>
Link: https://lore.kernel.org/r/20200507133405.32251-1-amadeuszx.slawinski@linux.intel.comSigned-off-by: Mark Brown <broonie@kernel.org>

SSI BUSIF buffer is possible to overflow or underflow, especially in a
hypervisor environment. If there is no interrupt support, it will eventually
lead to errors in pcm data.
This patch adds overflow and underflow interrupt support for SSI BUSIF buffer.
Reported-by: Chen Li <licheng0822@thundersoft.com>
Signed-off-by: Yongbo Zhang <giraffesnn123@gmail.com>
Tested-by: Chen Li <licheng0822@thundersoft.com>
Acked-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Link: https://lore.kernel.org/r/20200512093003.28332-1-giraffesnn123@gmail.comSigned-off-by: Mark Brown <broonie@kernel.org>

Fix to return negative error code -ENOMEM from the IPC init error
handling case instead of 0, as done elsewhere in this function.

Fixes: c16211d6 ("ASoC: SOF: Add Sound Open Firmware driver core")
Reported-by: Hulk Robot <hulkci@huawei.com>
Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com>
Link: https://lore.kernel.org/r/20200509093337.78897-1-weiyongjun1@huawei.comSigned-off-by: Mark Brown <broonie@kernel.org>

Sets headset button maps.
Signed-off-by: Tzung-Bi Shih <tzungbi@google.com>
Link: https://lore.kernel.org/r/20200511044000.86161-1-tzungbi@google.comSigned-off-by: Mark Brown <broonie@kernel.org>

The wov_hotword_model_put() function has multiple large variables on
its stack, the largest of which is the result of SHASH_DESC_ON_STACK().
In total, this exceeds the warning limit for 32-bit architectures:

sound/soc/codecs/cros_ec_codec.c:776:12: error: stack frame size of 1152 bytes in function 'wov_hotword_model_put' [-Werror,-Wframe-larger-than=]

The function already has a dynamic crypto_alloc_shash() allocation, so
using kmalloc() for the descriptor is correct as well and does not
introduce any additional failure scenarios. With this, the stack usage
of wov_hotword_model_put() gets reduced to 480 bytes in my test
configuration.

Fixes: b6bc07d4 ("ASoC: cros_ec_codec: support WoV")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Reviewed-by: Tzung-Bi Shih <tzungbi@google.com>
Link: https://lore.kernel.org/r/20200507213405.1869430-1-arnd@arndb.deSigned-off-by: Mark Brown <broonie@kernel.org>

The current codebase makes use of the zero-length array language
extension to the C90 standard, but the preferred mechanism to declare
variable-length types such as these ones is a flexible array member[1][2],
introduced in C99:

struct foo {
        int stuff;
        struct boo array[];
};

By making use of the mechanism above, we will get a compiler warning
in case the flexible array does not occur last in the structure, which
will help us prevent some kind of undefined behavior bugs from being
inadvertently introduced[3] to the codebase from now on.

Also, notice that, dynamic memory allocations won't be affected by
this change:

"Flexible array members have incomplete type, and so the sizeof operator
may not be applied. As a quirk of the original implementation of
zero-length arrays, sizeof evaluates to zero."[1]

sizeof(flexible-array-member) triggers a warning because flexible array
members have incomplete type[1]. There are some instances of code in
which the sizeof operator is being incorrectly/erroneously applied to
zero-length arrays and the result is zero. Such instances may be hiding
some bugs. So, this work (flexible-array member conversions) will also
help to get completely rid of those sorts of issues.

This issue was found with the help of Coccinelle.

[1] https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html
[2] https://github.com/KSPP/linux/issues/21
[3] commit 76497732 ("cxgb3/l2t: Fix undefined behaviour")
Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
Link: https://lore.kernel.org/r/20200507192228.GA16355@embeddedorSigned-off-by: Mark Brown <broonie@kernel.org>

When CONFIG_SND_SOC_SOF_BAYTRAIL is not set, gcc warns:

sound/soc/sof/intel/byt.c:85:41: warning: ‘cht_debugfs’ defined but not used [-Wunused-const-variable=]
 static const struct snd_sof_debugfs_map cht_debugfs[] = {
                                         ^~~~~~~~~~~
Move the variable inside #ifdef
Reported-by: Hulk Robot <hulkci@huawei.com>
Suggested-by: Joe Perches <joe@perches.com>
Signed-off-by: YueHaibing <yuehaibing@huawei.com>
Link: https://lore.kernel.org/r/20200507072735.16588-1-yuehaibing@huawei.comSigned-off-by: Mark Brown <broonie@kernel.org>

Fix the following warning:

sound/soc/fsl/fsl_asrc.c:157:5: warning:
symbol 'fsl_asrc_request_pair' was not declared. Should it be static?
sound/soc/fsl/fsl_asrc.c:200:6: warning:
symbol 'fsl_asrc_release_pair' was not declared. Should it be static?
Reported-by: Hulk Robot <hulkci@huawei.com>
Signed-off-by: ChenTao <chentao107@huawei.com>
Link: https://lore.kernel.org/r/20200507022959.183739-1-chentao107@huawei.comSigned-off-by: Mark Brown <broonie@kernel.org>

The patch adds the devicetree file for the rt1016.
Signed-off-by: Oder Chiou <oder_chiou@realtek.com>
Link: https://lore.kernel.org/r/20200507021539.7133-2-oder_chiou@realtek.comSigned-off-by: Mark Brown <broonie@kernel.org>

The patch adds the rt1016 support.
Signed-off-by: Oder Chiou <oder_chiou@realtek.com>
Link: https://lore.kernel.org/r/20200507021539.7133-1-oder_chiou@realtek.comSigned-off-by: Mark Brown <broonie@kernel.org>

Using devm_snd_soc_register_component() can make the code
shorter and cleaner.
Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com>
Link: https://lore.kernel.org/r/20200507094335.14302-1-weiyongjun1@huawei.comSigned-off-by: Mark Brown <broonie@kernel.org>

platform_get_irq() returns negative value on error instead of 0.
Signed-off-by: Tzung-Bi Shih <tzungbi@google.com>
Link: https://lore.kernel.org/r/20200507015442.191336-1-tzungbi@google.comSigned-off-by: Mark Brown <broonie@kernel.org>

If the function platform_get_irq() failed, the negative value
returned will not be detected here. So fix error handling in
mt6797_afe_pcm_dev_probe(). And when get irq failed, the function
platform_get_irq() logs an error message, so remove redundant
message here.
Signed-off-by: Zhang Shengju <zhangshengju@cmss.chinamobile.com>
Signed-off-by: Tang Bin <tangbin@cmss.chinamobile.com>
Link: https://lore.kernel.org/r/20200506143009.13368-1-tangbin@cmss.chinamobile.comSigned-off-by: Mark Brown <broonie@kernel.org>

Simultaneous capture on dmic and headset mic is having
issue with high hw_level being reported.

Issue Can be reproduced by:
arecord -D hw:2,0 -f dat -d 60 /tmp/test0 &
arecord -D hw:2,2 -f dat -d 60 /tmp/test1 &
cat /proc/asound/card2/pcm?c/sub0/status

Actual issue is :
When we open one capture stream on one instance lets say I2S_SP and then
once again if we open other capture on other instance lets say I2S_BT while
first capture is in progress and when we try to read the status of both
running instances by below command cat /proc/asound/card2/pcm?c/sub0/status
we observe that avail_max is being doubled on first opened
capture(I2S_SP in the example).

This is because our previous implementation was like when any instance is
opened it gets initialized in dma_open irrespective of on what instance it
called open.

For example:
First I2S_SP called opened it initializes both SP/BT capture streams
irrespective of on which instance the stream opened.next time I2S_BT
called opened and it initializes both SP/BT this corrupts the behaviour .

So with this patch the stream gets initialized only on specific instance
when ever it gets opened calls hw_params.

This rectifies the issue.
Signed-off-by: Ravulapati Vishnu vardhan rao <Vishnuvardhanrao.Ravulapati@amd.com>
Signed-off-by: Akshu Agrawal <akshu.agrawal@amd.com>
Link: https://lore.kernel.org/r/20200506102602.140790-1-akshu.agrawal@amd.comSigned-off-by: Mark Brown <broonie@kernel.org>

The LPASS hardware allows configuring the MI2S SD lines to use
when playing/recording audio. However, at the moment the lpass-cpu
driver has SD0 hard-coded for mono/stereo (or additional fixed
SD lines for more channels).

For weird reasons there seems to be hardware that uses one of the
other SD lines for mono/stereo. For example, some Samsung devices
use an external Speaker amplifier connected to Quaternary MI2S.
For some reason, the SD line for audio playback was connected to
SD1 rather than SD0. (I have no idea why...)
At the moment, the lpass-cpu driver cannot be configured to work
for the Speaker on these devices.

The q6afe driver already allows configuring the MI2S SD lines
through the "qcom,sd-lines" device tree property, but this works
only when routing audio through the ADSP.

This commit adds a very similar configuration for the lpass-cpu driver.
It is now possible to add additional subnodes to the lpass device in
the device tree, to configure the SD lines for playback and/or capture.
E.g. for the Samsung devices mentioned above:

&lpass {
	dai@3 {
		reg = <MI2S_QUATERNARY>;
		qcom,playback-sd-lines = <1>;
	};
};

qcom,playback/capture-sd-lines takes a list of SD lines (0-3)
in the same format as the q6afe driver. (The difference here is that
q6afe has separate DAIs for playback/capture, while lpass-cpu has one
for both...)

For backwards compatibility with older device trees, the lpass-cpu driver
defaults to LPAIF_I2SCTL_MODE_8CH if the subnode for a DAI is missing.
This is equivalent to the previous behavior: Up to 8 channels can be
configured, and SD0/QUAT01 will be chosen when setting up a stream
with fewer channels.

This allows the speaker to work on Samsung MSM8916 devices
that use an external speaker amplifier.
Signed-off-by: Stephan Gerhold <stephan@gerhold.net>
Cc: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
Link: https://lore.kernel.org/r/20200425184657.121991-2-stephan@gerhold.netSigned-off-by: Mark Brown <broonie@kernel.org>

The lpass-cpu driver now allows configuring the MI2S SD lines
by defining subnodes for one of the DAIs.

Document this in the device tree bindings.
Signed-off-by: Stephan Gerhold <stephan@gerhold.net>
Link: https://lore.kernel.org/r/20200425184657.121991-1-stephan@gerhold.netSigned-off-by: Mark Brown <broonie@kernel.org>

Allow 32bit sample with this codec.
Signed-off-by: Shengjiu Wang <shengjiu.wang@nxp.com>
Link: https://lore.kernel.org/r/cff745cc041c5208910821f0740f988926af8a66.1574418380.git.shengjiu.wang@nxp.comSigned-off-by: Mark Brown <broonie@kernel.org>

Use the defined variable "dev" to make the code cleaner.
Signed-off-by: Zhang Shengju <zhangshengju@cmss.chinamobile.com>
Signed-off-by: Tang Bin <tangbin@cmss.chinamobile.com>
Link: https://lore.kernel.org/r/20200504065947.12172-1-tangbin@cmss.chinamobile.comSigned-off-by: Mark Brown <broonie@kernel.org>

Add condition to prevent SoC providing bclk in ratio of 50 times of sample rate.
Signed-off-by: Jack Yu <jack.yu@realtek.com>
Link: https://lore.kernel.org/r/20200504112013.2499-1-jack.yu@realtek.comSigned-off-by: Mark Brown <broonie@kernel.org>

The patch adds the K bypass for the PLL parameters.
Signed-off-by: Oder Chiou <oder_chiou@realtek.com>
Link: https://lore.kernel.org/r/20200504074007.13002-2-oder_chiou@realtek.comSigned-off-by: Mark Brown <broonie@kernel.org>

Without this the previously written value was written to this reg,
which caused the different configuration registers to be reset.
Signed-off-by: Chris Garren <cdgarren@indesign-llc.com>
Link: https://lore.kernel.org/r/1588599820-57994-1-git-send-email-cdgarren@indesign-llc.comSigned-off-by: Mark Brown <broonie@kernel.org>

The 'pengutronix' address is defunct for years. Use the proper contact
address.
Signed-off-by: Wolfram Sang <wsa@kernel.org>
Link: https://lore.kernel.org/r/20200502142646.19033-1-wsa@kernel.orgSigned-off-by: Mark Brown <broonie@kernel.org>

During S3 test, the following error was observed:

[ 726.174237] i2c_designware i2c_designware.0: platform_pm_resume+0x0/0x3d returned 0 after 0 usecs
[ 726.184187] max98373 i2c-MX98373:00: calling max98373_resume+0x0/0x30 [snd_soc_max98373] @ 12698, parent: i2c-11
[ 726.195589] max98373 i2c-MX98373:00: Reset command failed. (ret:-16)

When calling regmap_update_bits(), since map->reg_update_bits is NULL,
_regmap_read() is entered with the following logic:

	if (!map->cache_bypass) {
		ret = regcache_read(map, reg, val);
		if (ret == 0)
			return 0;
	}

	if (map->cache_only)
		return -EBUSY;

regcache_read() hits -EINVAL because MAX98373_R2000_SW_RESET is volatile,
as map->cache_only is set by codec suspend, thus -EBUSY is returned.
Fix by moving max98373_reset() after cache_only set to false in max98373_resume().
Signed-off-by: Yong Zhi <yong.zhi@intel.com>
Link: https://lore.kernel.org/r/1588376661-29799-1-git-send-email-yong.zhi@intel.comSigned-off-by: Mark Brown <broonie@kernel.org>

The patch changes the devicetree file mode correctly.
Signed-off-by: Oder Chiou <oder_chiou@realtek.com>
Link: https://lore.kernel.org/r/20200504074007.13002-1-oder_chiou@realtek.comSigned-off-by: Mark Brown <broonie@kernel.org>