We have snd_soc_dai/dai_stream/component_active() macro
This patch uses it.
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com>
Link: https://lore.kernel.org/r/87tv0i58it.wl-kuninori.morimoto.gx@renesas.comSigned-off-by: Mark Brown <broonie@kernel.org>

We have snd_soc_dai/dai_stream/component_active() macro
This patch uses it.
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com>
Link: https://lore.kernel.org/r/87v9ky58iy.wl-kuninori.morimoto.gx@renesas.comSigned-off-by: Mark Brown <broonie@kernel.org>

We have snd_soc_dai/dai_stream/component_active() macro
This patch uses it.
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com>
Link: https://lore.kernel.org/r/87wo5e58j4.wl-kuninori.morimoto.gx@renesas.comSigned-off-by: Mark Brown <broonie@kernel.org>

We have snd_soc_dai/dai_stream/component_active() macro
This patch uses it.
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com>
Link: https://lore.kernel.org/r/87y2pu58ja.wl-kuninori.morimoto.gx@renesas.comSigned-off-by: Mark Brown <broonie@kernel.org>

We have snd_soc_dai/dai_stream/component_active() macro
This patch uses it.
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com>
Link: https://lore.kernel.org/r/87zhaa58je.wl-kuninori.morimoto.gx@renesas.comSigned-off-by: Mark Brown <broonie@kernel.org>

We have snd_soc_dai/dai_stream/component_active() macro
This patch uses it.
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com>
Link: https://lore.kernel.org/r/871rnm6n3z.wl-kuninori.morimoto.gx@renesas.comSigned-off-by: Mark Brown <broonie@kernel.org>

We have snd_soc_dai/dai_stream/component_active() macro
This patch uses it.
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com>
Link: https://lore.kernel.org/r/8736826n44.wl-kuninori.morimoto.gx@renesas.comSigned-off-by: Mark Brown <broonie@kernel.org>

Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com>
Link: https://lore.kernel.org/r/874ksi6n48.wl-kuninori.morimoto.gx@renesas.comSigned-off-by: Mark Brown <broonie@kernel.org>

Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com>
Link: https://lore.kernel.org/r/875zcy6n4d.wl-kuninori.morimoto.gx@renesas.comSigned-off-by: Mark Brown <broonie@kernel.org>

Current snd_soc_dai_action() is updating
dai->stream_active for Playback/Capture (A),
dai->active        for DAI (B)

        void snd_soc_dai_action(struct snd_soc_dai *dai,
                                int stream, int action)
        {
(A)             dai->stream_active[stream]      += action;
(B)             dai->active                     += action;
                dai->component->active          += action;
        }

But, these are very verbose, because we can calculate
DAI active from stream_active.

This patch adds snd_soc_dai_active() which calculate
DAI active from DAI stream_active.
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com>
Link: https://lore.kernel.org/r/877dxe6n4i.wl-kuninori.morimoto.gx@renesas.comSigned-off-by: Mark Brown <broonie@kernel.org>

soc-dapm.c :: snd_soc_dai_link_event_pre_pmu() / snd_soc_dai_link_event()
are directly updating dai->active without caring about
stream_active / component->active.
It is breaking xxx_active count balance.
This patch uses snd_soc_dai_action() for it.
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com>
Link: https://lore.kernel.org/r/878shu6n4n.wl-kuninori.morimoto.gx@renesas.comSigned-off-by: Mark Brown <broonie@kernel.org>

snd_soc_runtime_action() updates DAI's xxx_active.
We should update these in the same time, and
it can be implemented at soc-dai.c.
This patch adds snd_soc_dai_action() for it.
This is prepare for xxx_active cleanup.
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com>
Link: https://lore.kernel.org/r/87a72a6n4s.wl-kuninori.morimoto.gx@renesas.comSigned-off-by: Mark Brown <broonie@kernel.org>

snd_soc_runtime_activate()/deactivate() are implemented by global function
which are just calling snd_soc_runtime_action().
We can replace it to macro, and this patch do it.
This patch is prepare for xxx_active cleanup.
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com>
Link: https://lore.kernel.org/r/87blmq6n4y.wl-kuninori.morimoto.gx@renesas.comSigned-off-by: Mark Brown <broonie@kernel.org>

Add support for imx8qm.

Shengjiu Wang (2):
  ASoC: fsl_esai: introduce SoC specific data
  ASoC: fsl_esai: Add new compatible string for imx8qm

Changes in v2
- drop the 0002 patch in v1, the dma relate limitation should
  be done in dma driver, or define a new DMA API for it.

 .../devicetree/bindings/sound/fsl,esai.txt    |  1 +
 sound/soc/fsl/fsl_esai.c                      | 46 +++++++++++++++----
 2 files changed, 38 insertions(+), 9 deletions(-)

--
2.21.0

The CrOS EC codec driver uses SHA-256 explicitly, and not in a
performance critical manner, so there is really no point in using
the SHASH crypto API here. Let's switch to the library API instead.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Reviewed-by: Tzung-Bi Shih <tzungbi@google.com>
Cc: Cheng-Yi Chiang <cychiang@chromium.org>
Cc: Enric Balletbo i Serra <enric.balletbo@collabora.com>
Cc: Guenter Roeck <groeck@chromium.org>
Cc: Benson Leung <bleung@chromium.org>
Cc: Liam Girdwood <lgirdwood@gmail.com>
Cc: Mark Brown <broonie@kernel.org>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Eric Biggers <ebiggers@kernel.org>
Cc: Herbert Xu <herbert@gondor.apana.org.au>
Cc: Tzung-Bi Shih <tzungbi@google.com>
Link: https://lore.kernel.org/r/20200515100309.20795-1-ardb@kernel.orgSigned-off-by: Mark Brown <broonie@kernel.org>

Add new compatible string "fsl,imx8qm-esai" in the binding document.
Signed-off-by: Shengjiu Wang <shengjiu.wang@nxp.com>
Acked-by: Rob Herring <robh@kernel.org>
Link: https://lore.kernel.org/r/fade597f6fb7e0ef9eb1185b491eaa46a9d287e3.1589537601.git.shengjiu.wang@nxp.comSigned-off-by: Mark Brown <broonie@kernel.org>

Introduce a SoC specific data structure which contains the
differences between the different SoCs.
This makes it easier to support more differences without having
to introduce a new if/else each time.
Signed-off-by: Shengjiu Wang <shengjiu.wang@nxp.com>
Acked-by: Nicolin Chen <nicoleotsuka@gmail.com>
Link: https://lore.kernel.org/r/c188279975bd216995904f9bf8a84c7887b759a0.1589537601.git.shengjiu.wang@nxp.comSigned-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

Configure the PDM sampling edges based on the values from the firmware.
Signed-off-by: Dan Murphy <dmurphy@ti.com>
Link: https://lore.kernel.org/r/20200514123338.20392-3-dmurphy@ti.comSigned-off-by: Mark Brown <broonie@kernel.org>

Add a device tree property to configure the PDM sampling edge for each
digital microphone.
Signed-off-by: Dan Murphy <dmurphy@ti.com>
CC: Rob Herring <robh@kernel.org>
Link: https://lore.kernel.org/r/20200514123338.20392-2-dmurphy@ti.comSigned-off-by: Mark Brown <broonie@kernel.org>

Add ALSA controls to configure the PDM clocks.
The clocks need to be configurable to accommodate various microphones
that use clocks for low power/low resolution modes to high power/high
resolution modes.
Signed-off-by: Dan Murphy <dmurphy@ti.com>
Link: https://lore.kernel.org/r/20200514123338.20392-1-dmurphy@ti.comSigned-off-by: Mark Brown <broonie@kernel.org>

The device tree binding declares the ti,mic-bias-source and the
ti,vref-source properties as u32.  The code reads them as u8 which is
incorrect.  Since the device tree binding indicates them as u32 the
conde needs to be updated to read u32.

In addition the bias source needs to be shifted 4 bits to
correctly write the register.

driver family")

Fixes: 37bde5acf040 ("ASoC: tlv320adcx140: Add the tlv320adcx140 codec
Signed-off-by: Dan Murphy <dmurphy@ti.com>
Link: https://lore.kernel.org/r/20200513142807.11802-1-dmurphy@ti.comSigned-off-by: Mark Brown <broonie@kernel.org>

When CLOCKING2 is non-volatile register, we need force clear
the WM8962_SYSCLK_ENA bit after reset, for the value in cache
maybe 0 but in hardware it is 1. Otherwise there will issue
as below statement in driver.

/* SYSCLK defaults to on; make sure it is off so we can safely
 * write to registers if the device is declocked.

Fixes: c38b6085 ("ASoC: wm8962: set CLOCKING2 as non-volatile register")
Signed-off-by: Shengjiu Wang <shengjiu.wang@nxp.com>
Acked-by: Charles Keepax <ckeepax@opensource.cirrus.com>
Link: https://lore.kernel.org/r/1589347835-20554-1-git-send-email-shengjiu.wang@nxp.comSigned-off-by: Mark Brown <broonie@kernel.org>

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>