--- /dev/null
+From 0ff4e8c61b794a4bf6c854ab071a1abaaa80f358 Mon Sep 17 00:00:00 2001
+From: "S.j. Wang" <shengjiu.wang@nxp.com>
+Date: Wed, 27 Feb 2019 06:31:12 +0000
+Subject: ASoC: fsl_esai: fix channel swap issue when stream starts
+
+From: S.j. Wang <shengjiu.wang@nxp.com>
+
+commit 0ff4e8c61b794a4bf6c854ab071a1abaaa80f358 upstream.
+
+There is very low possibility ( < 0.1% ) that channel swap happened
+in beginning when multi output/input pin is enabled. The issue is
+that hardware can't send data to correct pin in the beginning with
+the normal enable flow.
+
+This is hardware issue, but there is no errata, the workaround flow
+is that: Each time playback/recording, firstly clear the xSMA/xSMB,
+then enable TE/RE, then enable xSMB and xSMA (xSMB must be enabled
+before xSMA). Which is to use the xSMA as the trigger start register,
+previously the xCR_TE or xCR_RE is the bit for starting.
+
+Fixes commit 43d24e76b698 ("ASoC: fsl_esai: Add ESAI CPU DAI driver")
+Cc: <stable@vger.kernel.org>
+Reviewed-by: Fabio Estevam <festevam@gmail.com>
+Acked-by: Nicolin Chen <nicoleotsuka@gmail.com>
+Signed-off-by: Shengjiu Wang <shengjiu.wang@nxp.com>
+Signed-off-by: Mark Brown <broonie@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ sound/soc/fsl/fsl_esai.c | 47 +++++++++++++++++++++++++++++++++++++----------
+ 1 file changed, 37 insertions(+), 10 deletions(-)
+
+--- a/sound/soc/fsl/fsl_esai.c
++++ b/sound/soc/fsl/fsl_esai.c
+@@ -59,6 +59,8 @@ struct fsl_esai {
+ u32 fifo_depth;
+ u32 slot_width;
+ u32 slots;
++ u32 tx_mask;
++ u32 rx_mask;
+ u32 hck_rate[2];
+ u32 sck_rate[2];
+ bool hck_dir[2];
+@@ -359,21 +361,13 @@ static int fsl_esai_set_dai_tdm_slot(str
+ regmap_update_bits(esai_priv->regmap, REG_ESAI_TCCR,
+ ESAI_xCCR_xDC_MASK, ESAI_xCCR_xDC(slots));
+
+- regmap_update_bits(esai_priv->regmap, REG_ESAI_TSMA,
+- ESAI_xSMA_xS_MASK, ESAI_xSMA_xS(tx_mask));
+- regmap_update_bits(esai_priv->regmap, REG_ESAI_TSMB,
+- ESAI_xSMB_xS_MASK, ESAI_xSMB_xS(tx_mask));
+-
+ regmap_update_bits(esai_priv->regmap, REG_ESAI_RCCR,
+ ESAI_xCCR_xDC_MASK, ESAI_xCCR_xDC(slots));
+
+- regmap_update_bits(esai_priv->regmap, REG_ESAI_RSMA,
+- ESAI_xSMA_xS_MASK, ESAI_xSMA_xS(rx_mask));
+- regmap_update_bits(esai_priv->regmap, REG_ESAI_RSMB,
+- ESAI_xSMB_xS_MASK, ESAI_xSMB_xS(rx_mask));
+-
+ esai_priv->slot_width = slot_width;
+ esai_priv->slots = slots;
++ esai_priv->tx_mask = tx_mask;
++ esai_priv->rx_mask = rx_mask;
+
+ return 0;
+ }
+@@ -594,6 +588,7 @@ static int fsl_esai_trigger(struct snd_p
+ bool tx = substream->stream == SNDRV_PCM_STREAM_PLAYBACK;
+ u8 i, channels = substream->runtime->channels;
+ u32 pins = DIV_ROUND_UP(channels, esai_priv->slots);
++ u32 mask;
+
+ switch (cmd) {
+ case SNDRV_PCM_TRIGGER_START:
+@@ -606,15 +601,38 @@ static int fsl_esai_trigger(struct snd_p
+ for (i = 0; tx && i < channels; i++)
+ regmap_write(esai_priv->regmap, REG_ESAI_ETDR, 0x0);
+
++ /*
++ * When set the TE/RE in the end of enablement flow, there
++ * will be channel swap issue for multi data line case.
++ * In order to workaround this issue, we switch the bit
++ * enablement sequence to below sequence
++ * 1) clear the xSMB & xSMA: which is done in probe and
++ * stop state.
++ * 2) set TE/RE
++ * 3) set xSMB
++ * 4) set xSMA: xSMA is the last one in this flow, which
++ * will trigger esai to start.
++ */
+ regmap_update_bits(esai_priv->regmap, REG_ESAI_xCR(tx),
+ tx ? ESAI_xCR_TE_MASK : ESAI_xCR_RE_MASK,
+ tx ? ESAI_xCR_TE(pins) : ESAI_xCR_RE(pins));
++ mask = tx ? esai_priv->tx_mask : esai_priv->rx_mask;
++
++ regmap_update_bits(esai_priv->regmap, REG_ESAI_xSMB(tx),
++ ESAI_xSMB_xS_MASK, ESAI_xSMB_xS(mask));
++ regmap_update_bits(esai_priv->regmap, REG_ESAI_xSMA(tx),
++ ESAI_xSMA_xS_MASK, ESAI_xSMA_xS(mask));
++
+ break;
+ case SNDRV_PCM_TRIGGER_SUSPEND:
+ case SNDRV_PCM_TRIGGER_STOP:
+ case SNDRV_PCM_TRIGGER_PAUSE_PUSH:
+ regmap_update_bits(esai_priv->regmap, REG_ESAI_xCR(tx),
+ tx ? ESAI_xCR_TE_MASK : ESAI_xCR_RE_MASK, 0);
++ regmap_update_bits(esai_priv->regmap, REG_ESAI_xSMA(tx),
++ ESAI_xSMA_xS_MASK, 0);
++ regmap_update_bits(esai_priv->regmap, REG_ESAI_xSMB(tx),
++ ESAI_xSMB_xS_MASK, 0);
+
+ /* Disable and reset FIFO */
+ regmap_update_bits(esai_priv->regmap, REG_ESAI_xFCR(tx),
+@@ -904,6 +922,15 @@ static int fsl_esai_probe(struct platfor
+ return ret;
+ }
+
++ esai_priv->tx_mask = 0xFFFFFFFF;
++ esai_priv->rx_mask = 0xFFFFFFFF;
++
++ /* Clear the TSMA, TSMB, RSMA, RSMB */
++ regmap_write(esai_priv->regmap, REG_ESAI_TSMA, 0);
++ regmap_write(esai_priv->regmap, REG_ESAI_TSMB, 0);
++ regmap_write(esai_priv->regmap, REG_ESAI_RSMA, 0);
++ regmap_write(esai_priv->regmap, REG_ESAI_RSMB, 0);
++
+ ret = devm_snd_soc_register_component(&pdev->dev, &fsl_esai_component,
+ &fsl_esai_dai, 1);
+ if (ret) {
--- /dev/null
+From 6147e136ff5071609b54f18982dea87706288e21 Mon Sep 17 00:00:00 2001
+From: Arnd Bergmann <arnd@arndb.de>
+Date: Fri, 5 Apr 2019 18:38:53 -0700
+Subject: include/linux/bitrev.h: fix constant bitrev
+
+From: Arnd Bergmann <arnd@arndb.de>
+
+commit 6147e136ff5071609b54f18982dea87706288e21 upstream.
+
+clang points out with hundreds of warnings that the bitrev macros have a
+problem with constant input:
+
+ drivers/hwmon/sht15.c:187:11: error: variable '__x' is uninitialized when used within its own initialization
+ [-Werror,-Wuninitialized]
+ u8 crc = bitrev8(data->val_status & 0x0F);
+ ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ include/linux/bitrev.h:102:21: note: expanded from macro 'bitrev8'
+ __constant_bitrev8(__x) : \
+ ~~~~~~~~~~~~~~~~~~~^~~~
+ include/linux/bitrev.h:67:11: note: expanded from macro '__constant_bitrev8'
+ u8 __x = x; \
+ ~~~ ^
+
+Both the bitrev and the __constant_bitrev macros use an internal
+variable named __x, which goes horribly wrong when passing one to the
+other.
+
+The obvious fix is to rename one of the variables, so this adds an extra
+'_'.
+
+It seems we got away with this because
+
+ - there are only a few drivers using bitrev macros
+
+ - usually there are no constant arguments to those
+
+ - when they are constant, they tend to be either 0 or (unsigned)-1
+ (drivers/isdn/i4l/isdnhdlc.o, drivers/iio/amplifiers/ad8366.c) and
+ give the correct result by pure chance.
+
+In fact, the only driver that I could find that gets different results
+with this is drivers/net/wan/slic_ds26522.c, which in turn is a driver
+for fairly rare hardware (adding the maintainer to Cc for testing).
+
+Link: http://lkml.kernel.org/r/20190322140503.123580-1-arnd@arndb.de
+Fixes: 556d2f055bf6 ("ARM: 8187/1: add CONFIG_HAVE_ARCH_BITREVERSE to support rbit instruction")
+Signed-off-by: Arnd Bergmann <arnd@arndb.de>
+Reviewed-by: Nick Desaulniers <ndesaulniers@google.com>
+Cc: Zhao Qiang <qiang.zhao@nxp.com>
+Cc: Yalin Wang <yalin.wang@sonymobile.com>
+Cc: <stable@vger.kernel.org>
+Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
+Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ include/linux/bitrev.h | 36 ++++++++++++++++++------------------
+ 1 file changed, 18 insertions(+), 18 deletions(-)
+
+--- a/include/linux/bitrev.h
++++ b/include/linux/bitrev.h
+@@ -31,32 +31,32 @@ static inline u32 __bitrev32(u32 x)
+
+ #define __constant_bitrev32(x) \
+ ({ \
+- u32 __x = x; \
+- __x = (__x >> 16) | (__x << 16); \
+- __x = ((__x & (u32)0xFF00FF00UL) >> 8) | ((__x & (u32)0x00FF00FFUL) << 8); \
+- __x = ((__x & (u32)0xF0F0F0F0UL) >> 4) | ((__x & (u32)0x0F0F0F0FUL) << 4); \
+- __x = ((__x & (u32)0xCCCCCCCCUL) >> 2) | ((__x & (u32)0x33333333UL) << 2); \
+- __x = ((__x & (u32)0xAAAAAAAAUL) >> 1) | ((__x & (u32)0x55555555UL) << 1); \
+- __x; \
++ u32 ___x = x; \
++ ___x = (___x >> 16) | (___x << 16); \
++ ___x = ((___x & (u32)0xFF00FF00UL) >> 8) | ((___x & (u32)0x00FF00FFUL) << 8); \
++ ___x = ((___x & (u32)0xF0F0F0F0UL) >> 4) | ((___x & (u32)0x0F0F0F0FUL) << 4); \
++ ___x = ((___x & (u32)0xCCCCCCCCUL) >> 2) | ((___x & (u32)0x33333333UL) << 2); \
++ ___x = ((___x & (u32)0xAAAAAAAAUL) >> 1) | ((___x & (u32)0x55555555UL) << 1); \
++ ___x; \
+ })
+
+ #define __constant_bitrev16(x) \
+ ({ \
+- u16 __x = x; \
+- __x = (__x >> 8) | (__x << 8); \
+- __x = ((__x & (u16)0xF0F0U) >> 4) | ((__x & (u16)0x0F0FU) << 4); \
+- __x = ((__x & (u16)0xCCCCU) >> 2) | ((__x & (u16)0x3333U) << 2); \
+- __x = ((__x & (u16)0xAAAAU) >> 1) | ((__x & (u16)0x5555U) << 1); \
+- __x; \
++ u16 ___x = x; \
++ ___x = (___x >> 8) | (___x << 8); \
++ ___x = ((___x & (u16)0xF0F0U) >> 4) | ((___x & (u16)0x0F0FU) << 4); \
++ ___x = ((___x & (u16)0xCCCCU) >> 2) | ((___x & (u16)0x3333U) << 2); \
++ ___x = ((___x & (u16)0xAAAAU) >> 1) | ((___x & (u16)0x5555U) << 1); \
++ ___x; \
+ })
+
+ #define __constant_bitrev8(x) \
+ ({ \
+- u8 __x = x; \
+- __x = (__x >> 4) | (__x << 4); \
+- __x = ((__x & (u8)0xCCU) >> 2) | ((__x & (u8)0x33U) << 2); \
+- __x = ((__x & (u8)0xAAU) >> 1) | ((__x & (u8)0x55U) << 1); \
+- __x; \
++ u8 ___x = x; \
++ ___x = (___x >> 4) | (___x << 4); \
++ ___x = ((___x & (u8)0xCCU) >> 2) | ((___x & (u8)0x33U) << 2); \
++ ___x = ((___x & (u8)0xAAU) >> 1) | ((___x & (u8)0x55U) << 1); \
++ ___x; \
+ })
+
+ #define bitrev32(x) \
--- /dev/null
+From d006e95b5561f708d0385e9677ffe2c46f2ae345 Mon Sep 17 00:00:00 2001
+From: Helge Deller <deller@gmx.de>
+Date: Tue, 2 Apr 2019 12:13:27 +0200
+Subject: parisc: Detect QEMU earlier in boot process
+
+From: Helge Deller <deller@gmx.de>
+
+commit d006e95b5561f708d0385e9677ffe2c46f2ae345 upstream.
+
+While adding LASI support to QEMU, I noticed that the QEMU detection in
+the kernel happens much too late. For example, when a LASI chip is found
+by the kernel, it registers the LASI LED driver as well. But when we
+run on QEMU it makes sense to avoid spending unnecessary CPU cycles, so
+we need to access the running_on_QEMU flag earlier than before.
+
+This patch now makes the QEMU detection the fist task of the Linux
+kernel by moving it to where the kernel enters the C-coding.
+
+Fixes: 310d82784fb4 ("parisc: qemu idle sleep support")
+Signed-off-by: Helge Deller <deller@gmx.de>
+Cc: stable@vger.kernel.org # v4.14+
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ arch/parisc/kernel/process.c | 6 ------
+ arch/parisc/kernel/setup.c | 3 +++
+ 2 files changed, 3 insertions(+), 6 deletions(-)
+
+--- a/arch/parisc/kernel/process.c
++++ b/arch/parisc/kernel/process.c
+@@ -206,12 +206,6 @@ void __cpuidle arch_cpu_idle(void)
+
+ static int __init parisc_idle_init(void)
+ {
+- const char *marker;
+-
+- /* check QEMU/SeaBIOS marker in PAGE0 */
+- marker = (char *) &PAGE0->pad0;
+- running_on_qemu = (memcmp(marker, "SeaBIOS", 8) == 0);
+-
+ if (!running_on_qemu)
+ cpu_idle_poll_ctrl(1);
+
+--- a/arch/parisc/kernel/setup.c
++++ b/arch/parisc/kernel/setup.c
+@@ -403,6 +403,9 @@ void start_parisc(void)
+ int ret, cpunum;
+ struct pdc_coproc_cfg coproc_cfg;
+
++ /* check QEMU/SeaBIOS marker in PAGE0 */
++ running_on_qemu = (memcmp(&PAGE0->pad0, "SeaBIOS", 8) == 0);
++
+ cpunum = smp_processor_id();
+
+ set_firmware_width_unlocked();
net-ethtool-not-call-vzalloc-for-zero-sized-memory-request.patch
ip6_tunnel-match-to-arphrd_tunnel6-for-dev-type.patch
alsa-seq-fix-oob-reads-from-strlcpy.patch
+parisc-detect-qemu-earlier-in-boot-process.patch
+include-linux-bitrev.h-fix-constant-bitrev.patch
+asoc-fsl_esai-fix-channel-swap-issue-when-stream-starts.patch
projects / thirdparty / kernel / stable-queue.git / commitdiff
