[PATCH 1/4] ASoC: fsl-asoc-card: add WM8904 support

[PATCH 1/4] ASoC: fsl-asoc-card: add WM8904 support

[Alifer Moraes]

From: Pierluigi Passaro <pierluigi.p@variscite.com>

The codec WM8904 can use internal FLL as PLL source.
Whenever the PLL source is not an external MCLK, this source
must be setup during hw_params callback otherwise the BCLK
could be wrongly evaluated.
The SND_SOC_BIAS_PREPARE event is raised after the hw_params
callback, so there is no need to set again PLL and SYSCLK and
actually there's no need at all the set_bias_level function.
Also, when esai is used, a dedicated snd_soc_dai_set_tdm_slot
call is required.

Signed-off-by: Pierluigi Passaro <pierluigi.p@variscite.com>
Signed-off by: Alifer Moraes <alifer.m@variscite.com>
---
 sound/soc/fsl/fsl-asoc-card.c | 47 +++++++++++++++++++++++++++++++++++
 1 file changed, 47 insertions(+)

diff --git a/sound/soc/fsl/fsl-asoc-card.c b/sound/soc/fsl/fsl-asoc-card.c
index 5ee945505281..817dbc1ec635 100644
--- a/sound/soc/fsl/fsl-asoc-card.c
+++ b/sound/soc/fsl/fsl-asoc-card.c
@@ -23,6 +23,7 @@
 #include "imx-audmux.h"
 
 #include "../codecs/sgtl5000.h"
+#include "../codecs/wm8904.h"
 #include "../codecs/wm8962.h"
 #include "../codecs/wm8960.h"
 #include "../codecs/wm8994.h"
@@ -257,6 +258,38 @@ static int fsl_asoc_card_hw_free(struct snd_pcm_substream *substream)
 		}
 	}
 
+	if (of_device_is_compatible(dev->of_node, "fsl,imx-audio-wm8904")) {
+		struct snd_soc_dai *codec_dai = asoc_rtd_to_codec(rtd, 0);
+		unsigned int pll_out;
+
+		ret = snd_soc_dai_set_tdm_slot(rtd->cpu_dai, 0, 0, 2,
+					       params_physical_width(params));
+		if (ret) {
+			dev_err(dev, "failed to set TDM slot for cpu dai\n");
+			return ret;
+		}
+
+		if (priv->sample_format == SNDRV_PCM_FORMAT_S24_LE)
+			pll_out = priv->sample_rate * 384;
+		else
+			pll_out = priv->sample_rate * 256;
+
+		ret = snd_soc_dai_set_pll(codec_dai, codec_priv->pll_id,
+					  codec_priv->pll_id,
+					  codec_priv->mclk_freq, pll_out);
+		if (ret) {
+			dev_err(dev, "failed to start FLL: %d\n", ret);
+			return ret;
+		}
+
+		ret = snd_soc_dai_set_sysclk(codec_dai, codec_priv->fll_id,
+					     pll_out, SND_SOC_CLOCK_IN);
+		if (ret) {
+			dev_err(dev, "failed to set SYSCLK: %d\n", ret);
+			return ret;
+		}
+	}
+
 	return 0;
 }
 
@@ -651,6 +684,19 @@ static int fsl_asoc_card_probe(struct platform_device *pdev)
 		priv->codec_priv.fll_id = WM8960_SYSCLK_AUTO;
 		priv->codec_priv.pll_id = WM8960_SYSCLK_AUTO;
 		priv->dai_fmt |= SND_SOC_DAIFMT_CBP_CFP;
+	} else if (of_device_is_compatible(np, "fsl,imx-audio-wm8904")) {
+		codec_dai_name = "wm8904-hifi";
+		priv->card.set_bias_level = NULL;
+		priv->codec_priv.mclk_id = WM8904_CLK_FLL;
+		priv->codec_priv.fll_id = WM8904_CLK_FLL;
+		priv->codec_priv.pll_id = WM8904_FLL_MCLK;
+		priv->dai_fmt |= SND_SOC_DAIFMT_CBM_CFM;
+		if (strstr(cpu_np->name, "esai")) {
+			priv->cpu_priv.sysclk_freq[TX] = priv->codec_priv.mclk_freq;
+			priv->cpu_priv.sysclk_freq[RX] = priv->codec_priv.mclk_freq;
+			priv->cpu_priv.sysclk_dir[TX] = SND_SOC_CLOCK_OUT;
+			priv->cpu_priv.sysclk_dir[RX] = SND_SOC_CLOCK_OUT;
+		}
 	} else if (of_device_is_compatible(np, "fsl,imx-audio-ac97")) {
 		codec_dai_name = "ac97-hifi";
 		priv->dai_fmt = SND_SOC_DAIFMT_AC97;
@@ -900,6 +946,7 @@ static const struct of_device_id fsl_asoc_card_dt_ids[] = {
 	{ .compatible = "fsl,imx-audio-tlv320aic32x4", },
 	{ .compatible = "fsl,imx-audio-tlv320aic31xx", },
 	{ .compatible = "fsl,imx-audio-sgtl5000", },
+	{ .compatible = "fsl,imx-audio-wm8904", },
 	{ .compatible = "fsl,imx-audio-wm8962", },
 	{ .compatible = "fsl,imx-audio-wm8960", },
 	{ .compatible = "fsl,imx-audio-mqs", },
-- 
2.25.1

[PATCH 1/4] ASoC: fsl-asoc-card: add WM8904 support

[Alifer Moraes]

From: Pierluigi Passaro <pierluigi.p@variscite.com>

The codec WM8904 can use internal FLL as PLL source.
Whenever the PLL source is not an external MCLK, this source
must be setup during hw_params callback otherwise the BCLK
could be wrongly evaluated.
The SND_SOC_BIAS_PREPARE event is raised after the hw_params
callback, so there is no need to set again PLL and SYSCLK and
actually there's no need at all the set_bias_level function.
Also, when esai is used, a dedicated snd_soc_dai_set_tdm_slot
call is required.

Signed-off-by: Pierluigi Passaro <pierluigi.p@variscite.com>
Signed-off by: Alifer Moraes <alifer.m@variscite.com>
---
 sound/soc/fsl/fsl-asoc-card.c | 47 +++++++++++++++++++++++++++++++++++
 1 file changed, 47 insertions(+)

diff --git a/sound/soc/fsl/fsl-asoc-card.c b/sound/soc/fsl/fsl-asoc-card.c
index 5ee945505281..817dbc1ec635 100644
--- a/sound/soc/fsl/fsl-asoc-card.c
+++ b/sound/soc/fsl/fsl-asoc-card.c
@@ -23,6 +23,7 @@
 #include "imx-audmux.h"
 
 #include "../codecs/sgtl5000.h"
+#include "../codecs/wm8904.h"
 #include "../codecs/wm8962.h"
 #include "../codecs/wm8960.h"
 #include "../codecs/wm8994.h"
@@ -257,6 +258,38 @@ static int fsl_asoc_card_hw_free(struct snd_pcm_substream *substream)
 		}
 	}
 
+	if (of_device_is_compatible(dev->of_node, "fsl,imx-audio-wm8904")) {
+		struct snd_soc_dai *codec_dai = asoc_rtd_to_codec(rtd, 0);
+		unsigned int pll_out;
+
+		ret = snd_soc_dai_set_tdm_slot(rtd->cpu_dai, 0, 0, 2,
+					       params_physical_width(params));
+		if (ret) {
+			dev_err(dev, "failed to set TDM slot for cpu dai\n");
+			return ret;
+		}
+
+		if (priv->sample_format == SNDRV_PCM_FORMAT_S24_LE)
+			pll_out = priv->sample_rate * 384;
+		else
+			pll_out = priv->sample_rate * 256;
+
+		ret = snd_soc_dai_set_pll(codec_dai, codec_priv->pll_id,
+					  codec_priv->pll_id,
+					  codec_priv->mclk_freq, pll_out);
+		if (ret) {
+			dev_err(dev, "failed to start FLL: %d\n", ret);
+			return ret;
+		}
+
+		ret = snd_soc_dai_set_sysclk(codec_dai, codec_priv->fll_id,
+					     pll_out, SND_SOC_CLOCK_IN);
+		if (ret) {
+			dev_err(dev, "failed to set SYSCLK: %d\n", ret);
+			return ret;
+		}
+	}
+
 	return 0;
 }
 
@@ -651,6 +684,19 @@ static int fsl_asoc_card_probe(struct platform_device *pdev)
 		priv->codec_priv.fll_id = WM8960_SYSCLK_AUTO;
 		priv->codec_priv.pll_id = WM8960_SYSCLK_AUTO;
 		priv->dai_fmt |= SND_SOC_DAIFMT_CBP_CFP;
+	} else if (of_device_is_compatible(np, "fsl,imx-audio-wm8904")) {
+		codec_dai_name = "wm8904-hifi";
+		priv->card.set_bias_level = NULL;
+		priv->codec_priv.mclk_id = WM8904_CLK_FLL;
+		priv->codec_priv.fll_id = WM8904_CLK_FLL;
+		priv->codec_priv.pll_id = WM8904_FLL_MCLK;
+		priv->dai_fmt |= SND_SOC_DAIFMT_CBM_CFM;
+		if (strstr(cpu_np->name, "esai")) {
+			priv->cpu_priv.sysclk_freq[TX] = priv->codec_priv.mclk_freq;
+			priv->cpu_priv.sysclk_freq[RX] = priv->codec_priv.mclk_freq;
+			priv->cpu_priv.sysclk_dir[TX] = SND_SOC_CLOCK_OUT;
+			priv->cpu_priv.sysclk_dir[RX] = SND_SOC_CLOCK_OUT;
+		}
 	} else if (of_device_is_compatible(np, "fsl,imx-audio-ac97")) {
 		codec_dai_name = "ac97-hifi";
 		priv->dai_fmt = SND_SOC_DAIFMT_AC97;
@@ -900,6 +946,7 @@ static const struct of_device_id fsl_asoc_card_dt_ids[] = {
 	{ .compatible = "fsl,imx-audio-tlv320aic32x4", },
 	{ .compatible = "fsl,imx-audio-tlv320aic31xx", },
 	{ .compatible = "fsl,imx-audio-sgtl5000", },
+	{ .compatible = "fsl,imx-audio-wm8904", },
 	{ .compatible = "fsl,imx-audio-wm8962", },
 	{ .compatible = "fsl,imx-audio-wm8960", },
 	{ .compatible = "fsl,imx-audio-mqs", },
-- 
2.25.1

[PATCH 1/4] ASoC: fsl-asoc-card: add WM8904 support

[Alifer Moraes]

From: Pierluigi Passaro <pierluigi.p@variscite.com>

The codec WM8904 can use internal FLL as PLL source.
Whenever the PLL source is not an external MCLK, this source
must be setup during hw_params callback otherwise the BCLK
could be wrongly evaluated.
The SND_SOC_BIAS_PREPARE event is raised after the hw_params
callback, so there is no need to set again PLL and SYSCLK and
actually there's no need at all the set_bias_level function.
Also, when esai is used, a dedicated snd_soc_dai_set_tdm_slot
call is required.

Signed-off-by: Pierluigi Passaro <pierluigi.p@variscite.com>
Signed-off by: Alifer Moraes <alifer.m@variscite.com>
---
 sound/soc/fsl/fsl-asoc-card.c | 47 +++++++++++++++++++++++++++++++++++
 1 file changed, 47 insertions(+)

diff --git a/sound/soc/fsl/fsl-asoc-card.c b/sound/soc/fsl/fsl-asoc-card.c
index 5ee945505281..817dbc1ec635 100644
--- a/sound/soc/fsl/fsl-asoc-card.c
+++ b/sound/soc/fsl/fsl-asoc-card.c
@@ -23,6 +23,7 @@
 #include "imx-audmux.h"
 
 #include "../codecs/sgtl5000.h"
+#include "../codecs/wm8904.h"
 #include "../codecs/wm8962.h"
 #include "../codecs/wm8960.h"
 #include "../codecs/wm8994.h"
@@ -257,6 +258,38 @@ static int fsl_asoc_card_hw_free(struct snd_pcm_substream *substream)
 		}
 	}
 
+	if (of_device_is_compatible(dev->of_node, "fsl,imx-audio-wm8904")) {
+		struct snd_soc_dai *codec_dai = asoc_rtd_to_codec(rtd, 0);
+		unsigned int pll_out;
+
+		ret = snd_soc_dai_set_tdm_slot(rtd->cpu_dai, 0, 0, 2,
+					       params_physical_width(params));
+		if (ret) {
+			dev_err(dev, "failed to set TDM slot for cpu dai\n");
+			return ret;
+		}
+
+		if (priv->sample_format == SNDRV_PCM_FORMAT_S24_LE)
+			pll_out = priv->sample_rate * 384;
+		else
+			pll_out = priv->sample_rate * 256;
+
+		ret = snd_soc_dai_set_pll(codec_dai, codec_priv->pll_id,
+					  codec_priv->pll_id,
+					  codec_priv->mclk_freq, pll_out);
+		if (ret) {
+			dev_err(dev, "failed to start FLL: %d\n", ret);
+			return ret;
+		}
+
+		ret = snd_soc_dai_set_sysclk(codec_dai, codec_priv->fll_id,
+					     pll_out, SND_SOC_CLOCK_IN);
+		if (ret) {
+			dev_err(dev, "failed to set SYSCLK: %d\n", ret);
+			return ret;
+		}
+	}
+
 	return 0;
 }
 
@@ -651,6 +684,19 @@ static int fsl_asoc_card_probe(struct platform_device *pdev)
 		priv->codec_priv.fll_id = WM8960_SYSCLK_AUTO;
 		priv->codec_priv.pll_id = WM8960_SYSCLK_AUTO;
 		priv->dai_fmt |= SND_SOC_DAIFMT_CBP_CFP;
+	} else if (of_device_is_compatible(np, "fsl,imx-audio-wm8904")) {
+		codec_dai_name = "wm8904-hifi";
+		priv->card.set_bias_level = NULL;
+		priv->codec_priv.mclk_id = WM8904_CLK_FLL;
+		priv->codec_priv.fll_id = WM8904_CLK_FLL;
+		priv->codec_priv.pll_id = WM8904_FLL_MCLK;
+		priv->dai_fmt |= SND_SOC_DAIFMT_CBM_CFM;
+		if (strstr(cpu_np->name, "esai")) {
+			priv->cpu_priv.sysclk_freq[TX] = priv->codec_priv.mclk_freq;
+			priv->cpu_priv.sysclk_freq[RX] = priv->codec_priv.mclk_freq;
+			priv->cpu_priv.sysclk_dir[TX] = SND_SOC_CLOCK_OUT;
+			priv->cpu_priv.sysclk_dir[RX] = SND_SOC_CLOCK_OUT;
+		}
 	} else if (of_device_is_compatible(np, "fsl,imx-audio-ac97")) {
 		codec_dai_name = "ac97-hifi";
 		priv->dai_fmt = SND_SOC_DAIFMT_AC97;
@@ -900,6 +946,7 @@ static const struct of_device_id fsl_asoc_card_dt_ids[] = {
 	{ .compatible = "fsl,imx-audio-tlv320aic32x4", },
 	{ .compatible = "fsl,imx-audio-tlv320aic31xx", },
 	{ .compatible = "fsl,imx-audio-sgtl5000", },
+	{ .compatible = "fsl,imx-audio-wm8904", },
 	{ .compatible = "fsl,imx-audio-wm8962", },
 	{ .compatible = "fsl,imx-audio-wm8960", },
 	{ .compatible = "fsl,imx-audio-mqs", },
-- 
2.25.1

[PATCH 2/4] ASoC: bindings: fsl-asoc-card: Add compatible string for wm8904

[Alifer Moraes]

Add compatible string for the wm8904 codec.

Signed-off-by: Alifer Moraes <alifer.m@variscite.com>
---
 Documentation/devicetree/bindings/sound/fsl-asoc-card.txt | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/Documentation/devicetree/bindings/sound/fsl-asoc-card.txt b/Documentation/devicetree/bindings/sound/fsl-asoc-card.txt
index 23d83fa7609f..edb7837e4963 100644
--- a/Documentation/devicetree/bindings/sound/fsl-asoc-card.txt
+++ b/Documentation/devicetree/bindings/sound/fsl-asoc-card.txt
@@ -44,6 +44,8 @@ The compatible list for this generic sound card currently:
 
  "fsl,imx-audio-wm8958"
 
+ "fsl,imx-audio-wm8904"
+
 Required properties:
 
   - compatible		: Contains one of entries in the compatible list.
-- 
2.25.1

[PATCH 2/4] ASoC: bindings: fsl-asoc-card: Add compatible string for wm8904

[Alifer Moraes]

Add compatible string for the wm8904 codec.

Signed-off-by: Alifer Moraes <alifer.m@variscite.com>
---
 Documentation/devicetree/bindings/sound/fsl-asoc-card.txt | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/Documentation/devicetree/bindings/sound/fsl-asoc-card.txt b/Documentation/devicetree/bindings/sound/fsl-asoc-card.txt
index 23d83fa7609f..edb7837e4963 100644
--- a/Documentation/devicetree/bindings/sound/fsl-asoc-card.txt
+++ b/Documentation/devicetree/bindings/sound/fsl-asoc-card.txt
@@ -44,6 +44,8 @@ The compatible list for this generic sound card currently:
 
  "fsl,imx-audio-wm8958"
 
+ "fsl,imx-audio-wm8904"
+
 Required properties:
 
   - compatible		: Contains one of entries in the compatible list.
-- 
2.25.1

[PATCH 2/4] ASoC: bindings: fsl-asoc-card: Add compatible string for wm8904

[Alifer Moraes]

Add compatible string for the wm8904 codec.

Signed-off-by: Alifer Moraes <alifer.m@variscite.com>
---
 Documentation/devicetree/bindings/sound/fsl-asoc-card.txt | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/Documentation/devicetree/bindings/sound/fsl-asoc-card.txt b/Documentation/devicetree/bindings/sound/fsl-asoc-card.txt
index 23d83fa7609f..edb7837e4963 100644
--- a/Documentation/devicetree/bindings/sound/fsl-asoc-card.txt
+++ b/Documentation/devicetree/bindings/sound/fsl-asoc-card.txt
@@ -44,6 +44,8 @@ The compatible list for this generic sound card currently:
 
  "fsl,imx-audio-wm8958"
 
+ "fsl,imx-audio-wm8904"
+
 Required properties:
 
   - compatible		: Contains one of entries in the compatible list.
-- 
2.25.1

[PATCH 3/4] ASoC: wm8904: extend device tree support

[Alifer Moraes]

From: Pierluigi Passaro <pierluigi.p@variscite.com>

The platform_data structure is not populated when using device trees.
This patch adds optional dts properties to allow populating it:
- gpio-cfg
- mic-cfg
- num-drc-cfgs
- drc-cfg-regs
- drc-cfg-names
- num-retune-mobile-cfgs
- retune-mobile-cfg-regs
- retune-mobile-cfg-names
- retune-mobile-cfg-rates

Signed-off-by: Pierluigi Passaro <pierluigi.p@variscite.com>
Signed-off-by: Alifer Moraes <alifer.m@variscite.com>
---
 .../devicetree/bindings/sound/wm8904.txt      |  53 ++++++++
 sound/soc/codecs/wm8904.c                     | 113 +++++++++++++++++-
 2 files changed, 164 insertions(+), 2 deletions(-)

diff --git a/Documentation/devicetree/bindings/sound/wm8904.txt b/Documentation/devicetree/bindings/sound/wm8904.txt
index 66bf261423b9..e3bfd3ec2905 100644
--- a/Documentation/devicetree/bindings/sound/wm8904.txt
+++ b/Documentation/devicetree/bindings/sound/wm8904.txt
@@ -9,6 +9,40 @@ Required properties:
   - clocks: reference to
     <Documentation/devicetree/bindings/clock/clock-bindings.txt>
 
+Optional properties:
+
+  - gpio-cfg: Default registers value for R121/122/123/124 (GPIO Control).
+    The list must be 4 entries long. If absent, the registers are set to 0.
+    If any entry has the value 0xffff, the related register won't be set.
+
+  - mic-cfg: Default registers value for R6/R7 (Mic Bias Control).
+    The list must be 2 entries long. If absent, the registers are set to 0.
+
+  - num-drc-cfgs: Number of available DRC modes from drc-cfg-regs property
+
+  - drc-cfg-regs: Default registers value for R40/41/42/43 (DRC)
+    The list must be (4 x num-drc-cfgs) entries long.
+    If absent or incomplete, DRC is disabled.
+
+  - drc-cfg-names: List of strings for the available DRC modes.
+    The list must be (num-drc-cfgs) entries long.
+    If absent or incomplete, DRC is disabled.
+
+  - num-retune-mobile-cfgs: Number of retune modes available from
+    retune-mobile-cfg-regs property
+
+  - retune-mobile-cfg-regs: Default registers value for R134/.../157 (EQ)
+    The list must be (24 x num-retune-mobile-cfgs) entries long.
+    If absent or incomplete, retune is disabled.
+
+  - retune-mobile-cfg-names: List of strings for the available retune modes.
+    The list must be (num-retune-mobile-cfgs) entries long.
+    If absent or incomplete, retune is disabled.
+
+  - retune-mobile-cfg-rates: List of rates for the available retune modes.
+    The list must be (num-retune-mobile-cfgs) entries long.
+    If absent or incomplete, retune is disabled.
+
 Pins on the device (for linking into audio routes):
 
   * IN1L
@@ -30,4 +64,23 @@ codec: wm8904@1a {
 	reg = <0x1a>;
 	clocks = <&pck0>;
 	clock-names = "mclk";
+	num-drc-cfgs = <5>;
+	drc-cfg-names = "default", "peaklimiter", "tradition", "soft", "music";
+	drc-cfg-regs =
+			/* coded default: KNEE_IP = KNEE_OP = 0, HI_COMP = LO_COMP = 1  */
+			<0x01af 0x3248 0x0000 0x0000>,
+			/* coded default: KNEE_IP = -24, KNEE_OP = -6, HI_COMP = 1/4, LO_COMP = 1 */
+			<0x04af 0x324b 0x0010 0x0408>,
+			/* coded default: KNEE_IP = -42, KNEE_OP = -3, HI_COMP = 0, LO_COMP = 1 */
+			<0x04af 0x324b 0x0028 0x0704>,
+			/* coded default: KNEE_IP = -45, KNEE_OP = -9, HI_COMP = 1/8, LO_COMP = 1 */
+			<0x04af 0x324b 0x0018 0x078c>,
+			/* coded default: KNEE_IP = -30, KNEE_OP = -10.5, HI_COMP = 1/4, LO_COMP = 1 */
+			<0x04af 0x324b 0x0010 0x050e>;
+	gpio-cfg = <
+		0x0018 /* GPIO1 => DMIC_CLK */
+		0xffff /* GPIO2 => don't touch */
+		0xffff /* GPIO3 => don't touch */
+		0xffff /* GPIO4 => don't touch */
+	>;
 };
diff --git a/sound/soc/codecs/wm8904.c b/sound/soc/codecs/wm8904.c
index a02a77fef360..4121771db104 100644
--- a/sound/soc/codecs/wm8904.c
+++ b/sound/soc/codecs/wm8904.c
@@ -2162,6 +2162,110 @@ static const struct of_device_id wm8904_of_match[] = {
 MODULE_DEVICE_TABLE(of, wm8904_of_match);
 #endif
 
+static int wm8904_set_pdata_from_of(struct i2c_client *i2c,
+				     struct wm8904_priv *wm8904)
+{
+	const struct device_node *np = i2c->dev.of_node;
+	struct wm8904_pdata *pdata;
+	bool drc_cfgs_is_valid = true;
+	bool retune_mobile_cfgs_is_valid = true;
+	int i, j, offset;
+	u32 val32;
+
+	pdata = devm_kzalloc(&i2c->dev, sizeof(*pdata), GFP_KERNEL);
+	if (!pdata)
+		return -ENOMEM;
+
+	if (of_property_read_u32_array(np, "gpio-cfg", pdata->gpio_cfg,
+					ARRAY_SIZE(pdata->gpio_cfg))) {
+		dev_dbg(&i2c->dev, "No 'gpio-cfg' property found\n");
+	}
+
+	if (of_property_read_u32_array(np, "mic-cfg", pdata->mic_cfg,
+					ARRAY_SIZE(pdata->mic_cfg))) {
+		dev_dbg(&i2c->dev, "No 'mic-cfg' property found\n");
+	}
+
+	if (of_property_read_s32(np, "num-drc-cfgs", &pdata->num_drc_cfgs)) {
+		dev_dbg(&i2c->dev, "No 'num-drc-cfgs' property found\n");
+	} else if (pdata->num_drc_cfgs < 0) {
+		dev_err(&i2c->dev, "Negative 'num-drc-cfgs' property found\n");
+		pdata->num_drc_cfgs = 0;
+	} else if (pdata->num_drc_cfgs > 0) {
+		pdata->drc_cfgs = devm_kzalloc(&i2c->dev,
+					       pdata->num_drc_cfgs * sizeof(struct wm8904_drc_cfg),
+					       GFP_KERNEL);
+		for (i = 0; i < pdata->num_drc_cfgs && drc_cfgs_is_valid; i++) {
+			offset = i * WM8904_DRC_REGS;
+			for (j = 0; j < WM8904_DRC_REGS && drc_cfgs_is_valid; j++) {
+				if (of_property_read_u32_index(np,
+							       "drc-cfg-regs",
+							       offset + j,
+							       &val32)) {
+					dev_err(&i2c->dev,
+						"Invalid 'drc-cfg-regs[%i,%i]' property found\n", i, j);
+					drc_cfgs_is_valid = false;
+				} else {
+					pdata->drc_cfgs[i].regs[j] = val32;
+				}
+			}
+			if (of_property_read_string_index(np, "drc-cfg-names", i,
+							  &pdata->drc_cfgs[i].name)) {
+				dev_err(&i2c->dev,
+					"Invalid 'drc-cfg-names[%i]' property found\n", i);
+				drc_cfgs_is_valid = false;
+			}
+		}
+	}
+	if (!drc_cfgs_is_valid) {
+		pdata->num_drc_cfgs = 0;
+	}
+
+	if (of_property_read_s32(np, "num-retune-mobile-cfgs", &pdata->num_retune_mobile_cfgs)) {
+		dev_dbg(&i2c->dev, "No 'num-retune-mobile-cfgs' property found\n");
+	} else if (pdata->num_retune_mobile_cfgs < 0) {
+		dev_err(&i2c->dev, "Negative 'num-retune-mobile-cfgs' property found\n");
+		pdata->num_retune_mobile_cfgs = 0;
+	} else if (pdata->num_retune_mobile_cfgs > 0) {
+		pdata->retune_mobile_cfgs = devm_kzalloc(&i2c->dev,
+			pdata->num_retune_mobile_cfgs * sizeof(struct wm8904_retune_mobile_cfg),
+			GFP_KERNEL);
+		for (i = 0; i < pdata->num_retune_mobile_cfgs && retune_mobile_cfgs_is_valid; i++) {
+			offset = i * WM8904_EQ_REGS;
+			for (j = 0; j < WM8904_EQ_REGS && retune_mobile_cfgs_is_valid; j++) {
+				if (of_property_read_u32_index(np, "retune-mobile-cfg-regs",
+							       offset + j, &val32)) {
+					dev_err(&i2c->dev,
+						"Invalid 'retune-mobile-cfg-regs[%i,%i]' property found\n",
+						i, j);
+					retune_mobile_cfgs_is_valid = false;
+				} else {
+					pdata->retune_mobile_cfgs[i].regs[j] = val32;
+				}
+			}
+			if (of_property_read_u32_index(np, "retune-mobile-cfg-rates", i,
+						       &pdata->retune_mobile_cfgs[i].rate)) {
+				dev_err(&i2c->dev,
+					"Invalid 'retune-mobile-cfg-rates[%i]' property found\n", i);
+				retune_mobile_cfgs_is_valid = false;
+			}
+			if (of_property_read_string_index(np, "retune-mobile-cfg-names",
+							  i, &pdata->retune_mobile_cfgs[i].name)) {
+				dev_err(&i2c->dev,
+					"Invalid 'retune-mobile-cfg-names[%i]' property found\n", i);
+				retune_mobile_cfgs_is_valid = false;
+			}
+		}
+	}
+	if (!retune_mobile_cfgs_is_valid) {
+		pdata->num_retune_mobile_cfgs = 0;
+	}
+
+	wm8904->pdata = pdata;
+
+	return 0;
+}
+
 static int wm8904_i2c_probe(struct i2c_client *i2c,
 			    const struct i2c_device_id *id)
 {
@@ -2196,12 +2300,17 @@ static int wm8904_i2c_probe(struct i2c_client *i2c,
 		if (match == NULL)
 			return -EINVAL;
 		wm8904->devtype = (enum wm8904_type)match->data;
+		ret = wm8904_set_pdata_from_of(i2c, wm8904);
+		if (ret != 0) {
+			dev_err(&i2c->dev, "Failed to set platform data from of: %d\n", ret);
+			return ret;
+		}
 	} else {
 		wm8904->devtype = id->driver_data;
+		wm8904->pdata = i2c->dev.platform_data;
 	}
 
 	i2c_set_clientdata(i2c, wm8904);
-	wm8904->pdata = i2c->dev.platform_data;
 
 	for (i = 0; i < ARRAY_SIZE(wm8904->supplies); i++)
 		wm8904->supplies[i].supply = wm8904_supply_names[i];
@@ -2272,7 +2381,7 @@ static int wm8904_i2c_probe(struct i2c_client *i2c,
 	/* Apply configuration from the platform data. */
 	if (wm8904->pdata) {
 		for (i = 0; i < WM8904_GPIO_REGS; i++) {
-			if (!wm8904->pdata->gpio_cfg[i])
+			if (wm8904->pdata->gpio_cfg[i] == 0xffff)
 				continue;
 
 			regmap_update_bits(wm8904->regmap,
-- 
2.25.1

[PATCH 3/4] ASoC: wm8904: extend device tree support

[Alifer Moraes]

From: Pierluigi Passaro <pierluigi.p@variscite.com>

The platform_data structure is not populated when using device trees.
This patch adds optional dts properties to allow populating it:
- gpio-cfg
- mic-cfg
- num-drc-cfgs
- drc-cfg-regs
- drc-cfg-names
- num-retune-mobile-cfgs
- retune-mobile-cfg-regs
- retune-mobile-cfg-names
- retune-mobile-cfg-rates

Signed-off-by: Pierluigi Passaro <pierluigi.p@variscite.com>
Signed-off-by: Alifer Moraes <alifer.m@variscite.com>
---
 .../devicetree/bindings/sound/wm8904.txt      |  53 ++++++++
 sound/soc/codecs/wm8904.c                     | 113 +++++++++++++++++-
 2 files changed, 164 insertions(+), 2 deletions(-)

diff --git a/Documentation/devicetree/bindings/sound/wm8904.txt b/Documentation/devicetree/bindings/sound/wm8904.txt
index 66bf261423b9..e3bfd3ec2905 100644
--- a/Documentation/devicetree/bindings/sound/wm8904.txt
+++ b/Documentation/devicetree/bindings/sound/wm8904.txt
@@ -9,6 +9,40 @@ Required properties:
   - clocks: reference to
     <Documentation/devicetree/bindings/clock/clock-bindings.txt>
 
+Optional properties:
+
+  - gpio-cfg: Default registers value for R121/122/123/124 (GPIO Control).
+    The list must be 4 entries long. If absent, the registers are set to 0.
+    If any entry has the value 0xffff, the related register won't be set.
+
+  - mic-cfg: Default registers value for R6/R7 (Mic Bias Control).
+    The list must be 2 entries long. If absent, the registers are set to 0.
+
+  - num-drc-cfgs: Number of available DRC modes from drc-cfg-regs property
+
+  - drc-cfg-regs: Default registers value for R40/41/42/43 (DRC)
+    The list must be (4 x num-drc-cfgs) entries long.
+    If absent or incomplete, DRC is disabled.
+
+  - drc-cfg-names: List of strings for the available DRC modes.
+    The list must be (num-drc-cfgs) entries long.
+    If absent or incomplete, DRC is disabled.
+
+  - num-retune-mobile-cfgs: Number of retune modes available from
+    retune-mobile-cfg-regs property
+
+  - retune-mobile-cfg-regs: Default registers value for R134/.../157 (EQ)
+    The list must be (24 x num-retune-mobile-cfgs) entries long.
+    If absent or incomplete, retune is disabled.
+
+  - retune-mobile-cfg-names: List of strings for the available retune modes.
+    The list must be (num-retune-mobile-cfgs) entries long.
+    If absent or incomplete, retune is disabled.
+
+  - retune-mobile-cfg-rates: List of rates for the available retune modes.
+    The list must be (num-retune-mobile-cfgs) entries long.
+    If absent or incomplete, retune is disabled.
+
 Pins on the device (for linking into audio routes):
 
   * IN1L
@@ -30,4 +64,23 @@ codec: wm8904@1a {
 	reg = <0x1a>;
 	clocks = <&pck0>;
 	clock-names = "mclk";
+	num-drc-cfgs = <5>;
+	drc-cfg-names = "default", "peaklimiter", "tradition", "soft", "music";
+	drc-cfg-regs =
+			/* coded default: KNEE_IP = KNEE_OP = 0, HI_COMP = LO_COMP = 1  */
+			<0x01af 0x3248 0x0000 0x0000>,
+			/* coded default: KNEE_IP = -24, KNEE_OP = -6, HI_COMP = 1/4, LO_COMP = 1 */
+			<0x04af 0x324b 0x0010 0x0408>,
+			/* coded default: KNEE_IP = -42, KNEE_OP = -3, HI_COMP = 0, LO_COMP = 1 */
+			<0x04af 0x324b 0x0028 0x0704>,
+			/* coded default: KNEE_IP = -45, KNEE_OP = -9, HI_COMP = 1/8, LO_COMP = 1 */
+			<0x04af 0x324b 0x0018 0x078c>,
+			/* coded default: KNEE_IP = -30, KNEE_OP = -10.5, HI_COMP = 1/4, LO_COMP = 1 */
+			<0x04af 0x324b 0x0010 0x050e>;
+	gpio-cfg = <
+		0x0018 /* GPIO1 => DMIC_CLK */
+		0xffff /* GPIO2 => don't touch */
+		0xffff /* GPIO3 => don't touch */
+		0xffff /* GPIO4 => don't touch */
+	>;
 };
diff --git a/sound/soc/codecs/wm8904.c b/sound/soc/codecs/wm8904.c
index a02a77fef360..4121771db104 100644
--- a/sound/soc/codecs/wm8904.c
+++ b/sound/soc/codecs/wm8904.c
@@ -2162,6 +2162,110 @@ static const struct of_device_id wm8904_of_match[] = {
 MODULE_DEVICE_TABLE(of, wm8904_of_match);
 #endif
 
+static int wm8904_set_pdata_from_of(struct i2c_client *i2c,
+				     struct wm8904_priv *wm8904)
+{
+	const struct device_node *np = i2c->dev.of_node;
+	struct wm8904_pdata *pdata;
+	bool drc_cfgs_is_valid = true;
+	bool retune_mobile_cfgs_is_valid = true;
+	int i, j, offset;
+	u32 val32;
+
+	pdata = devm_kzalloc(&i2c->dev, sizeof(*pdata), GFP_KERNEL);
+	if (!pdata)
+		return -ENOMEM;
+
+	if (of_property_read_u32_array(np, "gpio-cfg", pdata->gpio_cfg,
+					ARRAY_SIZE(pdata->gpio_cfg))) {
+		dev_dbg(&i2c->dev, "No 'gpio-cfg' property found\n");
+	}
+
+	if (of_property_read_u32_array(np, "mic-cfg", pdata->mic_cfg,
+					ARRAY_SIZE(pdata->mic_cfg))) {
+		dev_dbg(&i2c->dev, "No 'mic-cfg' property found\n");
+	}
+
+	if (of_property_read_s32(np, "num-drc-cfgs", &pdata->num_drc_cfgs)) {
+		dev_dbg(&i2c->dev, "No 'num-drc-cfgs' property found\n");
+	} else if (pdata->num_drc_cfgs < 0) {
+		dev_err(&i2c->dev, "Negative 'num-drc-cfgs' property found\n");
+		pdata->num_drc_cfgs = 0;
+	} else if (pdata->num_drc_cfgs > 0) {
+		pdata->drc_cfgs = devm_kzalloc(&i2c->dev,
+					       pdata->num_drc_cfgs * sizeof(struct wm8904_drc_cfg),
+					       GFP_KERNEL);
+		for (i = 0; i < pdata->num_drc_cfgs && drc_cfgs_is_valid; i++) {
+			offset = i * WM8904_DRC_REGS;
+			for (j = 0; j < WM8904_DRC_REGS && drc_cfgs_is_valid; j++) {
+				if (of_property_read_u32_index(np,
+							       "drc-cfg-regs",
+							       offset + j,
+							       &val32)) {
+					dev_err(&i2c->dev,
+						"Invalid 'drc-cfg-regs[%i,%i]' property found\n", i, j);
+					drc_cfgs_is_valid = false;
+				} else {
+					pdata->drc_cfgs[i].regs[j] = val32;
+				}
+			}
+			if (of_property_read_string_index(np, "drc-cfg-names", i,
+							  &pdata->drc_cfgs[i].name)) {
+				dev_err(&i2c->dev,
+					"Invalid 'drc-cfg-names[%i]' property found\n", i);
+				drc_cfgs_is_valid = false;
+			}
+		}
+	}
+	if (!drc_cfgs_is_valid) {
+		pdata->num_drc_cfgs = 0;
+	}
+
+	if (of_property_read_s32(np, "num-retune-mobile-cfgs", &pdata->num_retune_mobile_cfgs)) {
+		dev_dbg(&i2c->dev, "No 'num-retune-mobile-cfgs' property found\n");
+	} else if (pdata->num_retune_mobile_cfgs < 0) {
+		dev_err(&i2c->dev, "Negative 'num-retune-mobile-cfgs' property found\n");
+		pdata->num_retune_mobile_cfgs = 0;
+	} else if (pdata->num_retune_mobile_cfgs > 0) {
+		pdata->retune_mobile_cfgs = devm_kzalloc(&i2c->dev,
+			pdata->num_retune_mobile_cfgs * sizeof(struct wm8904_retune_mobile_cfg),
+			GFP_KERNEL);
+		for (i = 0; i < pdata->num_retune_mobile_cfgs && retune_mobile_cfgs_is_valid; i++) {
+			offset = i * WM8904_EQ_REGS;
+			for (j = 0; j < WM8904_EQ_REGS && retune_mobile_cfgs_is_valid; j++) {
+				if (of_property_read_u32_index(np, "retune-mobile-cfg-regs",
+							       offset + j, &val32)) {
+					dev_err(&i2c->dev,
+						"Invalid 'retune-mobile-cfg-regs[%i,%i]' property found\n",
+						i, j);
+					retune_mobile_cfgs_is_valid = false;
+				} else {
+					pdata->retune_mobile_cfgs[i].regs[j] = val32;
+				}
+			}
+			if (of_property_read_u32_index(np, "retune-mobile-cfg-rates", i,
+						       &pdata->retune_mobile_cfgs[i].rate)) {
+				dev_err(&i2c->dev,
+					"Invalid 'retune-mobile-cfg-rates[%i]' property found\n", i);
+				retune_mobile_cfgs_is_valid = false;
+			}
+			if (of_property_read_string_index(np, "retune-mobile-cfg-names",
+							  i, &pdata->retune_mobile_cfgs[i].name)) {
+				dev_err(&i2c->dev,
+					"Invalid 'retune-mobile-cfg-names[%i]' property found\n", i);
+				retune_mobile_cfgs_is_valid = false;
+			}
+		}
+	}
+	if (!retune_mobile_cfgs_is_valid) {
+		pdata->num_retune_mobile_cfgs = 0;
+	}
+
+	wm8904->pdata = pdata;
+
+	return 0;
+}
+
 static int wm8904_i2c_probe(struct i2c_client *i2c,
 			    const struct i2c_device_id *id)
 {
@@ -2196,12 +2300,17 @@ static int wm8904_i2c_probe(struct i2c_client *i2c,
 		if (match == NULL)
 			return -EINVAL;
 		wm8904->devtype = (enum wm8904_type)match->data;
+		ret = wm8904_set_pdata_from_of(i2c, wm8904);
+		if (ret != 0) {
+			dev_err(&i2c->dev, "Failed to set platform data from of: %d\n", ret);
+			return ret;
+		}
 	} else {
 		wm8904->devtype = id->driver_data;
+		wm8904->pdata = i2c->dev.platform_data;
 	}
 
 	i2c_set_clientdata(i2c, wm8904);
-	wm8904->pdata = i2c->dev.platform_data;
 
 	for (i = 0; i < ARRAY_SIZE(wm8904->supplies); i++)
 		wm8904->supplies[i].supply = wm8904_supply_names[i];
@@ -2272,7 +2381,7 @@ static int wm8904_i2c_probe(struct i2c_client *i2c,
 	/* Apply configuration from the platform data. */
 	if (wm8904->pdata) {
 		for (i = 0; i < WM8904_GPIO_REGS; i++) {
-			if (!wm8904->pdata->gpio_cfg[i])
+			if (wm8904->pdata->gpio_cfg[i] == 0xffff)
 				continue;
 
 			regmap_update_bits(wm8904->regmap,
-- 
2.25.1

[PATCH 3/4] ASoC: wm8904: extend device tree support

[Alifer Moraes]

From: Pierluigi Passaro <pierluigi.p@variscite.com>

The platform_data structure is not populated when using device trees.
This patch adds optional dts properties to allow populating it:
- gpio-cfg
- mic-cfg
- num-drc-cfgs
- drc-cfg-regs
- drc-cfg-names
- num-retune-mobile-cfgs
- retune-mobile-cfg-regs
- retune-mobile-cfg-names
- retune-mobile-cfg-rates

Signed-off-by: Pierluigi Passaro <pierluigi.p@variscite.com>
Signed-off-by: Alifer Moraes <alifer.m@variscite.com>
---
 .../devicetree/bindings/sound/wm8904.txt      |  53 ++++++++
 sound/soc/codecs/wm8904.c                     | 113 +++++++++++++++++-
 2 files changed, 164 insertions(+), 2 deletions(-)

diff --git a/Documentation/devicetree/bindings/sound/wm8904.txt b/Documentation/devicetree/bindings/sound/wm8904.txt
index 66bf261423b9..e3bfd3ec2905 100644
--- a/Documentation/devicetree/bindings/sound/wm8904.txt
+++ b/Documentation/devicetree/bindings/sound/wm8904.txt
@@ -9,6 +9,40 @@ Required properties:
   - clocks: reference to
     <Documentation/devicetree/bindings/clock/clock-bindings.txt>
 
+Optional properties:
+
+  - gpio-cfg: Default registers value for R121/122/123/124 (GPIO Control).
+    The list must be 4 entries long. If absent, the registers are set to 0.
+    If any entry has the value 0xffff, the related register won't be set.
+
+  - mic-cfg: Default registers value for R6/R7 (Mic Bias Control).
+    The list must be 2 entries long. If absent, the registers are set to 0.
+
+  - num-drc-cfgs: Number of available DRC modes from drc-cfg-regs property
+
+  - drc-cfg-regs: Default registers value for R40/41/42/43 (DRC)
+    The list must be (4 x num-drc-cfgs) entries long.
+    If absent or incomplete, DRC is disabled.
+
+  - drc-cfg-names: List of strings for the available DRC modes.
+    The list must be (num-drc-cfgs) entries long.
+    If absent or incomplete, DRC is disabled.
+
+  - num-retune-mobile-cfgs: Number of retune modes available from
+    retune-mobile-cfg-regs property
+
+  - retune-mobile-cfg-regs: Default registers value for R134/.../157 (EQ)
+    The list must be (24 x num-retune-mobile-cfgs) entries long.
+    If absent or incomplete, retune is disabled.
+
+  - retune-mobile-cfg-names: List of strings for the available retune modes.
+    The list must be (num-retune-mobile-cfgs) entries long.
+    If absent or incomplete, retune is disabled.
+
+  - retune-mobile-cfg-rates: List of rates for the available retune modes.
+    The list must be (num-retune-mobile-cfgs) entries long.
+    If absent or incomplete, retune is disabled.
+
 Pins on the device (for linking into audio routes):
 
   * IN1L
@@ -30,4 +64,23 @@ codec: wm8904@1a {
 	reg = <0x1a>;
 	clocks = <&pck0>;
 	clock-names = "mclk";
+	num-drc-cfgs = <5>;
+	drc-cfg-names = "default", "peaklimiter", "tradition", "soft", "music";
+	drc-cfg-regs =
+			/* coded default: KNEE_IP = KNEE_OP = 0, HI_COMP = LO_COMP = 1  */
+			<0x01af 0x3248 0x0000 0x0000>,
+			/* coded default: KNEE_IP = -24, KNEE_OP = -6, HI_COMP = 1/4, LO_COMP = 1 */
+			<0x04af 0x324b 0x0010 0x0408>,
+			/* coded default: KNEE_IP = -42, KNEE_OP = -3, HI_COMP = 0, LO_COMP = 1 */
+			<0x04af 0x324b 0x0028 0x0704>,
+			/* coded default: KNEE_IP = -45, KNEE_OP = -9, HI_COMP = 1/8, LO_COMP = 1 */
+			<0x04af 0x324b 0x0018 0x078c>,
+			/* coded default: KNEE_IP = -30, KNEE_OP = -10.5, HI_COMP = 1/4, LO_COMP = 1 */
+			<0x04af 0x324b 0x0010 0x050e>;
+	gpio-cfg = <
+		0x0018 /* GPIO1 => DMIC_CLK */
+		0xffff /* GPIO2 => don't touch */
+		0xffff /* GPIO3 => don't touch */
+		0xffff /* GPIO4 => don't touch */
+	>;
 };
diff --git a/sound/soc/codecs/wm8904.c b/sound/soc/codecs/wm8904.c
index a02a77fef360..4121771db104 100644
--- a/sound/soc/codecs/wm8904.c
+++ b/sound/soc/codecs/wm8904.c
@@ -2162,6 +2162,110 @@ static const struct of_device_id wm8904_of_match[] = {
 MODULE_DEVICE_TABLE(of, wm8904_of_match);
 #endif
 
+static int wm8904_set_pdata_from_of(struct i2c_client *i2c,
+				     struct wm8904_priv *wm8904)
+{
+	const struct device_node *np = i2c->dev.of_node;
+	struct wm8904_pdata *pdata;
+	bool drc_cfgs_is_valid = true;
+	bool retune_mobile_cfgs_is_valid = true;
+	int i, j, offset;
+	u32 val32;
+
+	pdata = devm_kzalloc(&i2c->dev, sizeof(*pdata), GFP_KERNEL);
+	if (!pdata)
+		return -ENOMEM;
+
+	if (of_property_read_u32_array(np, "gpio-cfg", pdata->gpio_cfg,
+					ARRAY_SIZE(pdata->gpio_cfg))) {
+		dev_dbg(&i2c->dev, "No 'gpio-cfg' property found\n");
+	}
+
+	if (of_property_read_u32_array(np, "mic-cfg", pdata->mic_cfg,
+					ARRAY_SIZE(pdata->mic_cfg))) {
+		dev_dbg(&i2c->dev, "No 'mic-cfg' property found\n");
+	}
+
+	if (of_property_read_s32(np, "num-drc-cfgs", &pdata->num_drc_cfgs)) {
+		dev_dbg(&i2c->dev, "No 'num-drc-cfgs' property found\n");
+	} else if (pdata->num_drc_cfgs < 0) {
+		dev_err(&i2c->dev, "Negative 'num-drc-cfgs' property found\n");
+		pdata->num_drc_cfgs = 0;
+	} else if (pdata->num_drc_cfgs > 0) {
+		pdata->drc_cfgs = devm_kzalloc(&i2c->dev,
+					       pdata->num_drc_cfgs * sizeof(struct wm8904_drc_cfg),
+					       GFP_KERNEL);
+		for (i = 0; i < pdata->num_drc_cfgs && drc_cfgs_is_valid; i++) {
+			offset = i * WM8904_DRC_REGS;
+			for (j = 0; j < WM8904_DRC_REGS && drc_cfgs_is_valid; j++) {
+				if (of_property_read_u32_index(np,
+							       "drc-cfg-regs",
+							       offset + j,
+							       &val32)) {
+					dev_err(&i2c->dev,
+						"Invalid 'drc-cfg-regs[%i,%i]' property found\n", i, j);
+					drc_cfgs_is_valid = false;
+				} else {
+					pdata->drc_cfgs[i].regs[j] = val32;
+				}
+			}
+			if (of_property_read_string_index(np, "drc-cfg-names", i,
+							  &pdata->drc_cfgs[i].name)) {
+				dev_err(&i2c->dev,
+					"Invalid 'drc-cfg-names[%i]' property found\n", i);
+				drc_cfgs_is_valid = false;
+			}
+		}
+	}
+	if (!drc_cfgs_is_valid) {
+		pdata->num_drc_cfgs = 0;
+	}
+
+	if (of_property_read_s32(np, "num-retune-mobile-cfgs", &pdata->num_retune_mobile_cfgs)) {
+		dev_dbg(&i2c->dev, "No 'num-retune-mobile-cfgs' property found\n");
+	} else if (pdata->num_retune_mobile_cfgs < 0) {
+		dev_err(&i2c->dev, "Negative 'num-retune-mobile-cfgs' property found\n");
+		pdata->num_retune_mobile_cfgs = 0;
+	} else if (pdata->num_retune_mobile_cfgs > 0) {
+		pdata->retune_mobile_cfgs = devm_kzalloc(&i2c->dev,
+			pdata->num_retune_mobile_cfgs * sizeof(struct wm8904_retune_mobile_cfg),
+			GFP_KERNEL);
+		for (i = 0; i < pdata->num_retune_mobile_cfgs && retune_mobile_cfgs_is_valid; i++) {
+			offset = i * WM8904_EQ_REGS;
+			for (j = 0; j < WM8904_EQ_REGS && retune_mobile_cfgs_is_valid; j++) {
+				if (of_property_read_u32_index(np, "retune-mobile-cfg-regs",
+							       offset + j, &val32)) {
+					dev_err(&i2c->dev,
+						"Invalid 'retune-mobile-cfg-regs[%i,%i]' property found\n",
+						i, j);
+					retune_mobile_cfgs_is_valid = false;
+				} else {
+					pdata->retune_mobile_cfgs[i].regs[j] = val32;
+				}
+			}
+			if (of_property_read_u32_index(np, "retune-mobile-cfg-rates", i,
+						       &pdata->retune_mobile_cfgs[i].rate)) {
+				dev_err(&i2c->dev,
+					"Invalid 'retune-mobile-cfg-rates[%i]' property found\n", i);
+				retune_mobile_cfgs_is_valid = false;
+			}
+			if (of_property_read_string_index(np, "retune-mobile-cfg-names",
+							  i, &pdata->retune_mobile_cfgs[i].name)) {
+				dev_err(&i2c->dev,
+					"Invalid 'retune-mobile-cfg-names[%i]' property found\n", i);
+				retune_mobile_cfgs_is_valid = false;
+			}
+		}
+	}
+	if (!retune_mobile_cfgs_is_valid) {
+		pdata->num_retune_mobile_cfgs = 0;
+	}
+
+	wm8904->pdata = pdata;
+
+	return 0;
+}
+
 static int wm8904_i2c_probe(struct i2c_client *i2c,
 			    const struct i2c_device_id *id)
 {
@@ -2196,12 +2300,17 @@ static int wm8904_i2c_probe(struct i2c_client *i2c,
 		if (match == NULL)
 			return -EINVAL;
 		wm8904->devtype = (enum wm8904_type)match->data;
+		ret = wm8904_set_pdata_from_of(i2c, wm8904);
+		if (ret != 0) {
+			dev_err(&i2c->dev, "Failed to set platform data from of: %d\n", ret);
+			return ret;
+		}
 	} else {
 		wm8904->devtype = id->driver_data;
+		wm8904->pdata = i2c->dev.platform_data;
 	}
 
 	i2c_set_clientdata(i2c, wm8904);
-	wm8904->pdata = i2c->dev.platform_data;
 
 	for (i = 0; i < ARRAY_SIZE(wm8904->supplies); i++)
 		wm8904->supplies[i].supply = wm8904_supply_names[i];
@@ -2272,7 +2381,7 @@ static int wm8904_i2c_probe(struct i2c_client *i2c,
 	/* Apply configuration from the platform data. */
 	if (wm8904->pdata) {
 		for (i = 0; i < WM8904_GPIO_REGS; i++) {
-			if (!wm8904->pdata->gpio_cfg[i])
+			if (wm8904->pdata->gpio_cfg[i] == 0xffff)
 				continue;
 
 			regmap_update_bits(wm8904->regmap,
-- 
2.25.1

[PATCH 4/4] ASoC: wm8904: add DMIC support

[Alifer Moraes]

From: Pierluigi Passaro <pierluigi.p@variscite.com>

The WM8904 codec supports both ADC and DMIC inputs.
Add dedicated controls to support the additional routing.

Signed-off-by: Pierluigi Passaro <pierluigi.p@variscite.com>
Signed-off by: Alifer Moraes <alifer.m@variscite.com>
---
 sound/soc/codecs/wm8904.c | 34 ++++++++++++++++++++++++++++++++++
 1 file changed, 34 insertions(+)

diff --git a/sound/soc/codecs/wm8904.c b/sound/soc/codecs/wm8904.c
index 4121771db104..c7987dc81e4d 100644
--- a/sound/soc/codecs/wm8904.c
+++ b/sound/soc/codecs/wm8904.c
@@ -837,6 +837,26 @@ static int out_pga_event(struct snd_soc_dapm_widget *w,
 	return 0;
 }
 
+static const char *dmic_text[] = {
+	"DMIC1", "DMIC2"
+};
+
+static SOC_ENUM_SINGLE_DECL(dmic_enum,
+			    WM8904_DIGITAL_MICROPHONE_0, 11, dmic_text);
+
+static const struct snd_kcontrol_new dmic_mux =
+	SOC_DAPM_ENUM("DMIC Mux", dmic_enum);
+
+static const char *cin_text[] = {
+	"ADC", "DMIC"
+};
+
+static SOC_ENUM_SINGLE_DECL(cin_enum,
+			    WM8904_DIGITAL_MICROPHONE_0, 12, cin_text);
+
+static const struct snd_kcontrol_new cin_mux =
+	SOC_DAPM_ENUM("Capture Input", cin_enum);
+
 static const char *input_mode_text[] = {
 	"Single-Ended", "Differential Line", "Differential Mic"
 };
@@ -930,6 +950,10 @@ SND_SOC_DAPM_INPUT("IN2R"),
 SND_SOC_DAPM_INPUT("IN3L"),
 SND_SOC_DAPM_INPUT("IN3R"),
 
+SND_SOC_DAPM_MUX("DMIC Mux", SND_SOC_NOPM, 0, 0, &dmic_mux),
+SND_SOC_DAPM_MUX("Left Capture Input", SND_SOC_NOPM, 0, 0, &cin_mux),
+SND_SOC_DAPM_MUX("Right Capture Input", SND_SOC_NOPM, 0, 0, &cin_mux),
+
 SND_SOC_DAPM_SUPPLY("MICBIAS", WM8904_MIC_BIAS_CONTROL_0, 0, 0, NULL, 0),
 
 SND_SOC_DAPM_MUX("Left Capture Mux", SND_SOC_NOPM, 0, 0, &lin_mux),
@@ -1093,11 +1117,21 @@ static const struct snd_soc_dapm_route adc_intercon[] = {
 	{ "AIFOUTL", NULL, "AIFOUTL Mux" },
 	{ "AIFOUTR", NULL, "AIFOUTR Mux" },
 
+	{ "DMIC Mux", "DMIC1", "IN1L" },
+	{ "DMIC Mux", "DMIC2", "IN1R" },
+
+	{ "Left Capture Input", "ADC", "Left Capture PGA" },
+	{ "Left Capture Input", "DMIC", "DMIC Mux" },
+	{ "Right Capture Input", "ADC", "Right Capture PGA" },
+	{ "Right Capture Input", "DMIC", "DMIC Mux" },
+
 	{ "ADCL", NULL, "CLK_DSP" },
 	{ "ADCL", NULL, "Left Capture PGA" },
+	{ "ADCL", NULL, "Left Capture Input" },
 
 	{ "ADCR", NULL, "CLK_DSP" },
 	{ "ADCR", NULL, "Right Capture PGA" },
+	{ "ADCR", NULL, "Right Capture Input" },
 };
 
 static const struct snd_soc_dapm_route dac_intercon[] = {
-- 
2.25.1

[PATCH 4/4] ASoC: wm8904: add DMIC support

[Alifer Moraes]

From: Pierluigi Passaro <pierluigi.p@variscite.com>

The WM8904 codec supports both ADC and DMIC inputs.
Add dedicated controls to support the additional routing.

Signed-off-by: Pierluigi Passaro <pierluigi.p@variscite.com>
Signed-off by: Alifer Moraes <alifer.m@variscite.com>
---
 sound/soc/codecs/wm8904.c | 34 ++++++++++++++++++++++++++++++++++
 1 file changed, 34 insertions(+)

diff --git a/sound/soc/codecs/wm8904.c b/sound/soc/codecs/wm8904.c
index 4121771db104..c7987dc81e4d 100644
--- a/sound/soc/codecs/wm8904.c
+++ b/sound/soc/codecs/wm8904.c
@@ -837,6 +837,26 @@ static int out_pga_event(struct snd_soc_dapm_widget *w,
 	return 0;
 }
 
+static const char *dmic_text[] = {
+	"DMIC1", "DMIC2"
+};
+
+static SOC_ENUM_SINGLE_DECL(dmic_enum,
+			    WM8904_DIGITAL_MICROPHONE_0, 11, dmic_text);
+
+static const struct snd_kcontrol_new dmic_mux =
+	SOC_DAPM_ENUM("DMIC Mux", dmic_enum);
+
+static const char *cin_text[] = {
+	"ADC", "DMIC"
+};
+
+static SOC_ENUM_SINGLE_DECL(cin_enum,
+			    WM8904_DIGITAL_MICROPHONE_0, 12, cin_text);
+
+static const struct snd_kcontrol_new cin_mux =
+	SOC_DAPM_ENUM("Capture Input", cin_enum);
+
 static const char *input_mode_text[] = {
 	"Single-Ended", "Differential Line", "Differential Mic"
 };
@@ -930,6 +950,10 @@ SND_SOC_DAPM_INPUT("IN2R"),
 SND_SOC_DAPM_INPUT("IN3L"),
 SND_SOC_DAPM_INPUT("IN3R"),
 
+SND_SOC_DAPM_MUX("DMIC Mux", SND_SOC_NOPM, 0, 0, &dmic_mux),
+SND_SOC_DAPM_MUX("Left Capture Input", SND_SOC_NOPM, 0, 0, &cin_mux),
+SND_SOC_DAPM_MUX("Right Capture Input", SND_SOC_NOPM, 0, 0, &cin_mux),
+
 SND_SOC_DAPM_SUPPLY("MICBIAS", WM8904_MIC_BIAS_CONTROL_0, 0, 0, NULL, 0),
 
 SND_SOC_DAPM_MUX("Left Capture Mux", SND_SOC_NOPM, 0, 0, &lin_mux),
@@ -1093,11 +1117,21 @@ static const struct snd_soc_dapm_route adc_intercon[] = {
 	{ "AIFOUTL", NULL, "AIFOUTL Mux" },
 	{ "AIFOUTR", NULL, "AIFOUTR Mux" },
 
+	{ "DMIC Mux", "DMIC1", "IN1L" },
+	{ "DMIC Mux", "DMIC2", "IN1R" },
+
+	{ "Left Capture Input", "ADC", "Left Capture PGA" },
+	{ "Left Capture Input", "DMIC", "DMIC Mux" },
+	{ "Right Capture Input", "ADC", "Right Capture PGA" },
+	{ "Right Capture Input", "DMIC", "DMIC Mux" },
+
 	{ "ADCL", NULL, "CLK_DSP" },
 	{ "ADCL", NULL, "Left Capture PGA" },
+	{ "ADCL", NULL, "Left Capture Input" },
 
 	{ "ADCR", NULL, "CLK_DSP" },
 	{ "ADCR", NULL, "Right Capture PGA" },
+	{ "ADCR", NULL, "Right Capture Input" },
 };
 
 static const struct snd_soc_dapm_route dac_intercon[] = {
-- 
2.25.1

[PATCH 4/4] ASoC: wm8904: add DMIC support

[Alifer Moraes]

From: Pierluigi Passaro <pierluigi.p@variscite.com>

The WM8904 codec supports both ADC and DMIC inputs.
Add dedicated controls to support the additional routing.

Signed-off-by: Pierluigi Passaro <pierluigi.p@variscite.com>
Signed-off by: Alifer Moraes <alifer.m@variscite.com>
---
 sound/soc/codecs/wm8904.c | 34 ++++++++++++++++++++++++++++++++++
 1 file changed, 34 insertions(+)

diff --git a/sound/soc/codecs/wm8904.c b/sound/soc/codecs/wm8904.c
index 4121771db104..c7987dc81e4d 100644
--- a/sound/soc/codecs/wm8904.c
+++ b/sound/soc/codecs/wm8904.c
@@ -837,6 +837,26 @@ static int out_pga_event(struct snd_soc_dapm_widget *w,
 	return 0;
 }
 
+static const char *dmic_text[] = {
+	"DMIC1", "DMIC2"
+};
+
+static SOC_ENUM_SINGLE_DECL(dmic_enum,
+			    WM8904_DIGITAL_MICROPHONE_0, 11, dmic_text);
+
+static const struct snd_kcontrol_new dmic_mux =
+	SOC_DAPM_ENUM("DMIC Mux", dmic_enum);
+
+static const char *cin_text[] = {
+	"ADC", "DMIC"
+};
+
+static SOC_ENUM_SINGLE_DECL(cin_enum,
+			    WM8904_DIGITAL_MICROPHONE_0, 12, cin_text);
+
+static const struct snd_kcontrol_new cin_mux =
+	SOC_DAPM_ENUM("Capture Input", cin_enum);
+
 static const char *input_mode_text[] = {
 	"Single-Ended", "Differential Line", "Differential Mic"
 };
@@ -930,6 +950,10 @@ SND_SOC_DAPM_INPUT("IN2R"),
 SND_SOC_DAPM_INPUT("IN3L"),
 SND_SOC_DAPM_INPUT("IN3R"),
 
+SND_SOC_DAPM_MUX("DMIC Mux", SND_SOC_NOPM, 0, 0, &dmic_mux),
+SND_SOC_DAPM_MUX("Left Capture Input", SND_SOC_NOPM, 0, 0, &cin_mux),
+SND_SOC_DAPM_MUX("Right Capture Input", SND_SOC_NOPM, 0, 0, &cin_mux),
+
 SND_SOC_DAPM_SUPPLY("MICBIAS", WM8904_MIC_BIAS_CONTROL_0, 0, 0, NULL, 0),
 
 SND_SOC_DAPM_MUX("Left Capture Mux", SND_SOC_NOPM, 0, 0, &lin_mux),
@@ -1093,11 +1117,21 @@ static const struct snd_soc_dapm_route adc_intercon[] = {
 	{ "AIFOUTL", NULL, "AIFOUTL Mux" },
 	{ "AIFOUTR", NULL, "AIFOUTR Mux" },
 
+	{ "DMIC Mux", "DMIC1", "IN1L" },
+	{ "DMIC Mux", "DMIC2", "IN1R" },
+
+	{ "Left Capture Input", "ADC", "Left Capture PGA" },
+	{ "Left Capture Input", "DMIC", "DMIC Mux" },
+	{ "Right Capture Input", "ADC", "Right Capture PGA" },
+	{ "Right Capture Input", "DMIC", "DMIC Mux" },
+
 	{ "ADCL", NULL, "CLK_DSP" },
 	{ "ADCL", NULL, "Left Capture PGA" },
+	{ "ADCL", NULL, "Left Capture Input" },
 
 	{ "ADCR", NULL, "CLK_DSP" },
 	{ "ADCR", NULL, "Right Capture PGA" },
+	{ "ADCR", NULL, "Right Capture Input" },
 };
 
 static const struct snd_soc_dapm_route dac_intercon[] = {
-- 
2.25.1

Re: [PATCH 3/4] ASoC: wm8904: extend device tree support

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 553 bytes --]

On Mon, Mar 07, 2022 at 11:10:40AM -0300, Alifer Moraes wrote:

> +  - num-drc-cfgs: Number of available DRC modes from drc-cfg-regs property
> +
> +  - drc-cfg-regs: Default registers value for R40/41/42/43 (DRC)
> +    The list must be (4 x num-drc-cfgs) entries long.
> +    If absent or incomplete, DRC is disabled.

What is the purpose of having num-drc-cfgs?  We can tell how large
drc-cfg-regs is so it just seems redundant.

> +  - num-retune-mobile-cfgs: Number of retune modes available from
> +    retune-mobile-cfg-regs property

Same here.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [PATCH 3/4] ASoC: wm8904: extend device tree support

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 553 bytes --]

On Mon, Mar 07, 2022 at 11:10:40AM -0300, Alifer Moraes wrote:

> +  - num-drc-cfgs: Number of available DRC modes from drc-cfg-regs property
> +
> +  - drc-cfg-regs: Default registers value for R40/41/42/43 (DRC)
> +    The list must be (4 x num-drc-cfgs) entries long.
> +    If absent or incomplete, DRC is disabled.

What is the purpose of having num-drc-cfgs?  We can tell how large
drc-cfg-regs is so it just seems redundant.

> +  - num-retune-mobile-cfgs: Number of retune modes available from
> +    retune-mobile-cfg-regs property

Same here.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [PATCH 3/4] ASoC: wm8904: extend device tree support

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 553 bytes --]

On Mon, Mar 07, 2022 at 11:10:40AM -0300, Alifer Moraes wrote:

> +  - num-drc-cfgs: Number of available DRC modes from drc-cfg-regs property
> +
> +  - drc-cfg-regs: Default registers value for R40/41/42/43 (DRC)
> +    The list must be (4 x num-drc-cfgs) entries long.
> +    If absent or incomplete, DRC is disabled.

What is the purpose of having num-drc-cfgs?  We can tell how large
drc-cfg-regs is so it just seems redundant.

> +  - num-retune-mobile-cfgs: Number of retune modes available from
> +    retune-mobile-cfg-regs property

Same here.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [PATCH 4/4] ASoC: wm8904: add DMIC support

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 364 bytes --]

On Mon, Mar 07, 2022 at 11:10:41AM -0300, Alifer Moraes wrote:

> +static const char *cin_text[] = {
> +	"ADC", "DMIC"
> +};
> +
> +static SOC_ENUM_SINGLE_DECL(cin_enum,
> +			    WM8904_DIGITAL_MICROPHONE_0, 12, cin_text);

Why would this be runtime selectable?  I'd expect the decision to use
an analogue or digital microphone to be made in the hardware design.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [PATCH 4/4] ASoC: wm8904: add DMIC support

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 364 bytes --]

On Mon, Mar 07, 2022 at 11:10:41AM -0300, Alifer Moraes wrote:

> +static const char *cin_text[] = {
> +	"ADC", "DMIC"
> +};
> +
> +static SOC_ENUM_SINGLE_DECL(cin_enum,
> +			    WM8904_DIGITAL_MICROPHONE_0, 12, cin_text);

Why would this be runtime selectable?  I'd expect the decision to use
an analogue or digital microphone to be made in the hardware design.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [PATCH 4/4] ASoC: wm8904: add DMIC support

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 364 bytes --]

On Mon, Mar 07, 2022 at 11:10:41AM -0300, Alifer Moraes wrote:

> +static const char *cin_text[] = {
> +	"ADC", "DMIC"
> +};
> +
> +static SOC_ENUM_SINGLE_DECL(cin_enum,
> +			    WM8904_DIGITAL_MICROPHONE_0, 12, cin_text);

Why would this be runtime selectable?  I'd expect the decision to use
an analogue or digital microphone to be made in the hardware design.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [PATCH 3/4] ASoC: wm8904: extend device tree support

[Rob Herring]

On Mon, Mar 07, 2022 at 11:10:40AM -0300, Alifer Moraes wrote:
> From: Pierluigi Passaro <pierluigi.p@variscite.com>
> 
> The platform_data structure is not populated when using device trees.
> This patch adds optional dts properties to allow populating it:
> - gpio-cfg
> - mic-cfg
> - num-drc-cfgs
> - drc-cfg-regs
> - drc-cfg-names
> - num-retune-mobile-cfgs
> - retune-mobile-cfg-regs
> - retune-mobile-cfg-names
> - retune-mobile-cfg-rates

If you want to add all this, convert to DT schema first. 

They all need vendor prefixes for starters.

> 
> Signed-off-by: Pierluigi Passaro <pierluigi.p@variscite.com>
> Signed-off-by: Alifer Moraes <alifer.m@variscite.com>
> ---
>  .../devicetree/bindings/sound/wm8904.txt      |  53 ++++++++
>  sound/soc/codecs/wm8904.c                     | 113 +++++++++++++++++-

Binding changes go in their own patches.

Re: [PATCH 3/4] ASoC: wm8904: extend device tree support

[Rob Herring]

On Mon, Mar 07, 2022 at 11:10:40AM -0300, Alifer Moraes wrote:
> From: Pierluigi Passaro <pierluigi.p@variscite.com>
> 
> The platform_data structure is not populated when using device trees.
> This patch adds optional dts properties to allow populating it:
> - gpio-cfg
> - mic-cfg
> - num-drc-cfgs
> - drc-cfg-regs
> - drc-cfg-names
> - num-retune-mobile-cfgs
> - retune-mobile-cfg-regs
> - retune-mobile-cfg-names
> - retune-mobile-cfg-rates

If you want to add all this, convert to DT schema first. 

They all need vendor prefixes for starters.

> 
> Signed-off-by: Pierluigi Passaro <pierluigi.p@variscite.com>
> Signed-off-by: Alifer Moraes <alifer.m@variscite.com>
> ---
>  .../devicetree/bindings/sound/wm8904.txt      |  53 ++++++++
>  sound/soc/codecs/wm8904.c                     | 113 +++++++++++++++++-

Binding changes go in their own patches.

Re: [PATCH 3/4] ASoC: wm8904: extend device tree support

[Rob Herring]

On Mon, Mar 07, 2022 at 11:10:40AM -0300, Alifer Moraes wrote:
> From: Pierluigi Passaro <pierluigi.p@variscite.com>
> 
> The platform_data structure is not populated when using device trees.
> This patch adds optional dts properties to allow populating it:
> - gpio-cfg
> - mic-cfg
> - num-drc-cfgs
> - drc-cfg-regs
> - drc-cfg-names
> - num-retune-mobile-cfgs
> - retune-mobile-cfg-regs
> - retune-mobile-cfg-names
> - retune-mobile-cfg-rates

If you want to add all this, convert to DT schema first. 

They all need vendor prefixes for starters.

> 
> Signed-off-by: Pierluigi Passaro <pierluigi.p@variscite.com>
> Signed-off-by: Alifer Moraes <alifer.m@variscite.com>
> ---
>  .../devicetree/bindings/sound/wm8904.txt      |  53 ++++++++
>  sound/soc/codecs/wm8904.c                     | 113 +++++++++++++++++-

Binding changes go in their own patches.

Re: [PATCH 1/4] ASoC: fsl-asoc-card: add WM8904 support

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 1635 bytes --]

On Mon, Mar 07, 2022 at 11:10:38AM -0300, Alifer Moraes wrote:
> From: Pierluigi Passaro <pierluigi.p@variscite.com>
> 
> The codec WM8904 can use internal FLL as PLL source.
> Whenever the PLL source is not an external MCLK, this source
> must be setup during hw_params callback otherwise the BCLK
> could be wrongly evaluated.
> The SND_SOC_BIAS_PREPARE event is raised after the hw_params
> callback, so there is no need to set again PLL and SYSCLK and
> actually there's no need at all the set_bias_level function.
> Also, when esai is used, a dedicated snd_soc_dai_set_tdm_slot

> Signed-off by: Alifer Moraes <alifer.m@variscite.com>
> 
> Signed-off-by: Pierluigi Passaro <pierluigi.p@variscite.com>

When you're sending a mail your signoff should come at the end of the
chain of signoffs - see submitting-patches.rst for details.

This breaks an arm64 defconfig build:

/mnt/kernel/sound/soc/fsl/fsl-asoc-card.c: In function 'fsl_asoc_card_hw_free':
/mnt/kernel/sound/soc/fsl/fsl-asoc-card.c:265:37: error: 'struct snd_soc_pcm_runtime' has no member named 'cpu_dai'
  265 |   ret = snd_soc_dai_set_tdm_slot(rtd->cpu_dai, 0, 0, 2,
      |                                     ^~
/mnt/kernel/sound/soc/fsl/fsl-asoc-card.c:266:35: error: 'params' undeclared (first use in this function); did you mean 'parameq'?
  266 |             params_physical_width(params));
      |                                   ^~~~~~
      |                                   parameq
/mnt/kernel/sound/soc/fsl/fsl-asoc-card.c:266:35: note: each undeclared identifier is reported only once for each function it appears in


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [PATCH 1/4] ASoC: fsl-asoc-card: add WM8904 support

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 1635 bytes --]

On Mon, Mar 07, 2022 at 11:10:38AM -0300, Alifer Moraes wrote:
> From: Pierluigi Passaro <pierluigi.p@variscite.com>
> 
> The codec WM8904 can use internal FLL as PLL source.
> Whenever the PLL source is not an external MCLK, this source
> must be setup during hw_params callback otherwise the BCLK
> could be wrongly evaluated.
> The SND_SOC_BIAS_PREPARE event is raised after the hw_params
> callback, so there is no need to set again PLL and SYSCLK and
> actually there's no need at all the set_bias_level function.
> Also, when esai is used, a dedicated snd_soc_dai_set_tdm_slot

> Signed-off by: Alifer Moraes <alifer.m@variscite.com>
> 
> Signed-off-by: Pierluigi Passaro <pierluigi.p@variscite.com>

When you're sending a mail your signoff should come at the end of the
chain of signoffs - see submitting-patches.rst for details.

This breaks an arm64 defconfig build:

/mnt/kernel/sound/soc/fsl/fsl-asoc-card.c: In function 'fsl_asoc_card_hw_free':
/mnt/kernel/sound/soc/fsl/fsl-asoc-card.c:265:37: error: 'struct snd_soc_pcm_runtime' has no member named 'cpu_dai'
  265 |   ret = snd_soc_dai_set_tdm_slot(rtd->cpu_dai, 0, 0, 2,
      |                                     ^~
/mnt/kernel/sound/soc/fsl/fsl-asoc-card.c:266:35: error: 'params' undeclared (first use in this function); did you mean 'parameq'?
  266 |             params_physical_width(params));
      |                                   ^~~~~~
      |                                   parameq
/mnt/kernel/sound/soc/fsl/fsl-asoc-card.c:266:35: note: each undeclared identifier is reported only once for each function it appears in


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [PATCH 1/4] ASoC: fsl-asoc-card: add WM8904 support

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 1635 bytes --]

On Mon, Mar 07, 2022 at 11:10:38AM -0300, Alifer Moraes wrote:
> From: Pierluigi Passaro <pierluigi.p@variscite.com>
> 
> The codec WM8904 can use internal FLL as PLL source.
> Whenever the PLL source is not an external MCLK, this source
> must be setup during hw_params callback otherwise the BCLK
> could be wrongly evaluated.
> The SND_SOC_BIAS_PREPARE event is raised after the hw_params
> callback, so there is no need to set again PLL and SYSCLK and
> actually there's no need at all the set_bias_level function.
> Also, when esai is used, a dedicated snd_soc_dai_set_tdm_slot

> Signed-off by: Alifer Moraes <alifer.m@variscite.com>
> 
> Signed-off-by: Pierluigi Passaro <pierluigi.p@variscite.com>

When you're sending a mail your signoff should come at the end of the
chain of signoffs - see submitting-patches.rst for details.

This breaks an arm64 defconfig build:

/mnt/kernel/sound/soc/fsl/fsl-asoc-card.c: In function 'fsl_asoc_card_hw_free':
/mnt/kernel/sound/soc/fsl/fsl-asoc-card.c:265:37: error: 'struct snd_soc_pcm_runtime' has no member named 'cpu_dai'
  265 |   ret = snd_soc_dai_set_tdm_slot(rtd->cpu_dai, 0, 0, 2,
      |                                     ^~
/mnt/kernel/sound/soc/fsl/fsl-asoc-card.c:266:35: error: 'params' undeclared (first use in this function); did you mean 'parameq'?
  266 |             params_physical_width(params));
      |                                   ^~~~~~
      |                                   parameq
/mnt/kernel/sound/soc/fsl/fsl-asoc-card.c:266:35: note: each undeclared identifier is reported only once for each function it appears in


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [PATCH 3/4] ASoC: wm8904: extend device tree support

[Pierluigi Passaro]

> > The platform_data structure is not populated when using device trees.
> > This patch adds optional dts properties to allow populating it:
> > - gpio-cfg
> > - mic-cfg
> > - num-drc-cfgs
> > - drc-cfg-regs
> > - drc-cfg-names
> > - num-retune-mobile-cfgs
> > - retune-mobile-cfg-regs
> > - retune-mobile-cfg-names
> > - retune-mobile-cfg-rates
> 
> If you want to add all this, convert to DT schema first. 
> They all need vendor prefixes for starters.

Beyond adding the vendor prefix, can you please add details or provide any reference about "convert to DT schema" ?

> > 
> > Signed-off-by: Pierluigi Passaro <pierluigi.p@variscite.com>
> > Signed-off-by: Alifer Moraes <alifer.m@variscite.com>
> > ---
> >  .../devicetree/bindings/sound/wm8904.txt      |  53 ++++++++
> >  sound/soc/codecs/wm8904.c                     | 113 +++++++++++++++++-
> 
> Binding changes go in their own patches.

Do you mean that C code and TXT documentation should be provided as separated patches ?

Thanks
Best Regards
Pier

Re: [PATCH 3/4] ASoC: wm8904: extend device tree support

[Pierluigi Passaro]

> > The platform_data structure is not populated when using device trees.
> > This patch adds optional dts properties to allow populating it:
> > - gpio-cfg
> > - mic-cfg
> > - num-drc-cfgs
> > - drc-cfg-regs
> > - drc-cfg-names
> > - num-retune-mobile-cfgs
> > - retune-mobile-cfg-regs
> > - retune-mobile-cfg-names
> > - retune-mobile-cfg-rates
> 
> If you want to add all this, convert to DT schema first. 
> They all need vendor prefixes for starters.

Beyond adding the vendor prefix, can you please add details or provide any reference about "convert to DT schema" ?

> > 
> > Signed-off-by: Pierluigi Passaro <pierluigi.p@variscite.com>
> > Signed-off-by: Alifer Moraes <alifer.m@variscite.com>
> > ---
> >  .../devicetree/bindings/sound/wm8904.txt      |  53 ++++++++
> >  sound/soc/codecs/wm8904.c                     | 113 +++++++++++++++++-
> 
> Binding changes go in their own patches.

Do you mean that C code and TXT documentation should be provided as separated patches ?

Thanks
Best Regards
Pier

Re: [PATCH 3/4] ASoC: wm8904: extend device tree support

[Pierluigi Passaro]

> > The platform_data structure is not populated when using device trees.
> > This patch adds optional dts properties to allow populating it:
> > - gpio-cfg
> > - mic-cfg
> > - num-drc-cfgs
> > - drc-cfg-regs
> > - drc-cfg-names
> > - num-retune-mobile-cfgs
> > - retune-mobile-cfg-regs
> > - retune-mobile-cfg-names
> > - retune-mobile-cfg-rates
> 
> If you want to add all this, convert to DT schema first. 
> They all need vendor prefixes for starters.

Beyond adding the vendor prefix, can you please add details or provide any reference about "convert to DT schema" ?

> > 
> > Signed-off-by: Pierluigi Passaro <pierluigi.p@variscite.com>
> > Signed-off-by: Alifer Moraes <alifer.m@variscite.com>
> > ---
> >  .../devicetree/bindings/sound/wm8904.txt      |  53 ++++++++
> >  sound/soc/codecs/wm8904.c                     | 113 +++++++++++++++++-
> 
> Binding changes go in their own patches.

Do you mean that C code and TXT documentation should be provided as separated patches ?

Thanks
Best Regards
Pier

Re: [PATCH 4/4] ASoC: wm8904: add DMIC support

[Pierluigi Passaro]

> > > > Just for my understanding, are you suggesting to set a device tree
> > > > property to force a fixed behavior in the driver ?

> > > Yes.

> > Why should we use a fixed behavior ?

> The things that are fixed by the design should be fixed.

> > > The device shares pins between the line inputs and the DMIC inputs so at
> > > least some of the configuration is going to be determinted at system
> > > design time, that will fix the usable values of at least one of the
> > > controls which ought to be reflected in the runtime behaviour.

> > In our design we use:
> > - pin 1: DMIC_CLK
> > - pin 24: LINEIN2R
> > - pin 26: LINEIN2L
> > - pin 27: DMIC_DATA

> > we have no pins shared among DMIC and LINEIN.

> This means that DMICDAT2 is not usefully selectable at runtime, you've
> got IN1 as digital and IN2 as analogue, so while the DMIC/ADC switch is
> useful the DMIC1/2 switch is not.

A customer could have the following working configuration
- pin 1: DMIC_CLK
- pin 24: LINEIN2R
- pin 25: DMICDAT2
- pin 26: LINEIN2L
- pin 27: DMICDAT1
with no shared pins: here there's the chance to select DMIC1, DMIC2 and
LINEIN2 at runtime: I can't find a reason for a fixed behavior.
Can you please elaborate ?

Re: [PATCH 4/4] ASoC: wm8904: add DMIC support

[Pierluigi Passaro]

> > > > Just for my understanding, are you suggesting to set a device tree
> > > > property to force a fixed behavior in the driver ?

> > > Yes.

> > Why should we use a fixed behavior ?

> The things that are fixed by the design should be fixed.

> > > The device shares pins between the line inputs and the DMIC inputs so at
> > > least some of the configuration is going to be determinted at system
> > > design time, that will fix the usable values of at least one of the
> > > controls which ought to be reflected in the runtime behaviour.

> > In our design we use:
> > - pin 1: DMIC_CLK
> > - pin 24: LINEIN2R
> > - pin 26: LINEIN2L
> > - pin 27: DMIC_DATA

> > we have no pins shared among DMIC and LINEIN.

> This means that DMICDAT2 is not usefully selectable at runtime, you've
> got IN1 as digital and IN2 as analogue, so while the DMIC/ADC switch is
> useful the DMIC1/2 switch is not.

A customer could have the following working configuration
- pin 1: DMIC_CLK
- pin 24: LINEIN2R
- pin 25: DMICDAT2
- pin 26: LINEIN2L
- pin 27: DMICDAT1
with no shared pins: here there's the chance to select DMIC1, DMIC2 and
LINEIN2 at runtime: I can't find a reason for a fixed behavior.
Can you please elaborate ?

Re: [PATCH 4/4] ASoC: wm8904: add DMIC support

[Pierluigi Passaro]

> > > > Just for my understanding, are you suggesting to set a device tree
> > > > property to force a fixed behavior in the driver ?

> > > Yes.

> > Why should we use a fixed behavior ?

> The things that are fixed by the design should be fixed.

> > > The device shares pins between the line inputs and the DMIC inputs so at
> > > least some of the configuration is going to be determinted at system
> > > design time, that will fix the usable values of at least one of the
> > > controls which ought to be reflected in the runtime behaviour.

> > In our design we use:
> > - pin 1: DMIC_CLK
> > - pin 24: LINEIN2R
> > - pin 26: LINEIN2L
> > - pin 27: DMIC_DATA

> > we have no pins shared among DMIC and LINEIN.

> This means that DMICDAT2 is not usefully selectable at runtime, you've
> got IN1 as digital and IN2 as analogue, so while the DMIC/ADC switch is
> useful the DMIC1/2 switch is not.

A customer could have the following working configuration
- pin 1: DMIC_CLK
- pin 24: LINEIN2R
- pin 25: DMICDAT2
- pin 26: LINEIN2L
- pin 27: DMICDAT1
with no shared pins: here there's the chance to select DMIC1, DMIC2 and
LINEIN2 at runtime: I can't find a reason for a fixed behavior.
Can you please elaborate ?

Re: [PATCH 4/4] ASoC: wm8904: add DMIC support

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 829 bytes --]

On Mon, Jun 20, 2022 at 07:53:56PM +0000, Pierluigi Passaro wrote:

> > This means that DMICDAT2 is not usefully selectable at runtime, you've
> > got IN1 as digital and IN2 as analogue, so while the DMIC/ADC switch is
> > useful the DMIC1/2 switch is not.

> A customer could have the following working configuration
> - pin 1: DMIC_CLK
> - pin 24: LINEIN2R
> - pin 25: DMICDAT2
> - pin 26: LINEIN2L
> - pin 27: DMICDAT1

> with no shared pins: here there's the chance to select DMIC1, DMIC2 and
> LINEIN2 at runtime: I can't find a reason for a fixed behavior.
> Can you please elaborate ?

So in that case the driver should offer the DMIC1/2 selection.  The
driver should be looking at which pins are wired up as DMICs and only
registering controls that can actually be used in the system based on
the pins that are wired up.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [PATCH 4/4] ASoC: wm8904: add DMIC support

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 829 bytes --]

On Mon, Jun 20, 2022 at 07:53:56PM +0000, Pierluigi Passaro wrote:

> > This means that DMICDAT2 is not usefully selectable at runtime, you've
> > got IN1 as digital and IN2 as analogue, so while the DMIC/ADC switch is
> > useful the DMIC1/2 switch is not.

> A customer could have the following working configuration
> - pin 1: DMIC_CLK
> - pin 24: LINEIN2R
> - pin 25: DMICDAT2
> - pin 26: LINEIN2L
> - pin 27: DMICDAT1

> with no shared pins: here there's the chance to select DMIC1, DMIC2 and
> LINEIN2 at runtime: I can't find a reason for a fixed behavior.
> Can you please elaborate ?

So in that case the driver should offer the DMIC1/2 selection.  The
driver should be looking at which pins are wired up as DMICs and only
registering controls that can actually be used in the system based on
the pins that are wired up.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [PATCH 4/4] ASoC: wm8904: add DMIC support

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 829 bytes --]

On Mon, Jun 20, 2022 at 07:53:56PM +0000, Pierluigi Passaro wrote:

> > This means that DMICDAT2 is not usefully selectable at runtime, you've
> > got IN1 as digital and IN2 as analogue, so while the DMIC/ADC switch is
> > useful the DMIC1/2 switch is not.

> A customer could have the following working configuration
> - pin 1: DMIC_CLK
> - pin 24: LINEIN2R
> - pin 25: DMICDAT2
> - pin 26: LINEIN2L
> - pin 27: DMICDAT1

> with no shared pins: here there's the chance to select DMIC1, DMIC2 and
> LINEIN2 at runtime: I can't find a reason for a fixed behavior.
> Can you please elaborate ?

So in that case the driver should offer the DMIC1/2 selection.  The
driver should be looking at which pins are wired up as DMICs and only
registering controls that can actually be used in the system based on
the pins that are wired up.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [PATCH 4/4] ASoC: wm8904: add DMIC support

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 931 bytes --]

On Mon, Jun 20, 2022 at 05:52:43PM +0000, Pierluigi Passaro wrote:
> > > Just for my understanding, are you suggesting to set a device tree
> > > property to force a fixed behavior in the driver ?

> > Yes.

> Why should we use a fixed behavior ?

The things that are fixed by the design should be fixed.

> > The device shares pins between the line inputs and the DMIC inputs so at
> > least some of the configuration is going to be determinted at system
> > design time, that will fix the usable values of at least one of the
> > controls which ought to be reflected in the runtime behaviour.

> In our design we use:
> - pin 1: DMIC_CLK
> - pin 24: LINEIN2R
> - pin 26: LINEIN2L
> - pin 27: DMIC_DATA

> we have no pins shared among DMIC and LINEIN.

This means that DMICDAT2 is not usefully selectable at runtime, you've
got IN1 as digital and IN2 as analogue, so while the DMIC/ADC switch is
useful the DMIC1/2 switch is not.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [PATCH 4/4] ASoC: wm8904: add DMIC support

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 931 bytes --]

On Mon, Jun 20, 2022 at 05:52:43PM +0000, Pierluigi Passaro wrote:
> > > Just for my understanding, are you suggesting to set a device tree
> > > property to force a fixed behavior in the driver ?

> > Yes.

> Why should we use a fixed behavior ?

The things that are fixed by the design should be fixed.

> > The device shares pins between the line inputs and the DMIC inputs so at
> > least some of the configuration is going to be determinted at system
> > design time, that will fix the usable values of at least one of the
> > controls which ought to be reflected in the runtime behaviour.

> In our design we use:
> - pin 1: DMIC_CLK
> - pin 24: LINEIN2R
> - pin 26: LINEIN2L
> - pin 27: DMIC_DATA

> we have no pins shared among DMIC and LINEIN.

This means that DMICDAT2 is not usefully selectable at runtime, you've
got IN1 as digital and IN2 as analogue, so while the DMIC/ADC switch is
useful the DMIC1/2 switch is not.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [PATCH 4/4] ASoC: wm8904: add DMIC support

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 931 bytes --]

On Mon, Jun 20, 2022 at 05:52:43PM +0000, Pierluigi Passaro wrote:
> > > Just for my understanding, are you suggesting to set a device tree
> > > property to force a fixed behavior in the driver ?

> > Yes.

> Why should we use a fixed behavior ?

The things that are fixed by the design should be fixed.

> > The device shares pins between the line inputs and the DMIC inputs so at
> > least some of the configuration is going to be determinted at system
> > design time, that will fix the usable values of at least one of the
> > controls which ought to be reflected in the runtime behaviour.

> In our design we use:
> - pin 1: DMIC_CLK
> - pin 24: LINEIN2R
> - pin 26: LINEIN2L
> - pin 27: DMIC_DATA

> we have no pins shared among DMIC and LINEIN.

This means that DMICDAT2 is not usefully selectable at runtime, you've
got IN1 as digital and IN2 as analogue, so while the DMIC/ADC switch is
useful the DMIC1/2 switch is not.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [PATCH 4/4] ASoC: wm8904: add DMIC support

[Pierluigi Passaro]

> > Just for my understanding, are you suggesting to set a device tree
> > property to force a fixed behavior in the driver ?

> Yes.

Why should we use a fixed behavior ?

> > WM8904 allows using both a DMIC and LINEIN, switching between one or
> > the other and this is how we currently use it.
> > Why the user should not be allowed to switch between DMIC and LINEIN ?

> The device shares pins between the line inputs and the DMIC inputs so at
> least some of the configuration is going to be determinted at system
> design time, that will fix the usable values of at least one of the
> controls which ought to be reflected in the runtime behaviour.

In our design we use:
- pin 1: DMIC_CLK
- pin 24: LINEIN2R
- pin 26: LINEIN2L
- pin 27: DMIC_DATA
we have no pins shared among DMIC and LINEIN.
We have several customer switching between DMIC and LINEIN at runtime.

> Please fix your mail client to word wrap within paragraphs at something
> substantially less than 80 columns.  Doing this makes your messages much
> easier to read and reply to.

I beg your pardon: it should be fixed now.

Re: [PATCH 4/4] ASoC: wm8904: add DMIC support

[Pierluigi Passaro]

> > Just for my understanding, are you suggesting to set a device tree
> > property to force a fixed behavior in the driver ?

> Yes.

Why should we use a fixed behavior ?

> > WM8904 allows using both a DMIC and LINEIN, switching between one or
> > the other and this is how we currently use it.
> > Why the user should not be allowed to switch between DMIC and LINEIN ?

> The device shares pins between the line inputs and the DMIC inputs so at
> least some of the configuration is going to be determinted at system
> design time, that will fix the usable values of at least one of the
> controls which ought to be reflected in the runtime behaviour.

In our design we use:
- pin 1: DMIC_CLK
- pin 24: LINEIN2R
- pin 26: LINEIN2L
- pin 27: DMIC_DATA
we have no pins shared among DMIC and LINEIN.
We have several customer switching between DMIC and LINEIN at runtime.

> Please fix your mail client to word wrap within paragraphs at something
> substantially less than 80 columns.  Doing this makes your messages much
> easier to read and reply to.

I beg your pardon: it should be fixed now.

Re: [PATCH 4/4] ASoC: wm8904: add DMIC support

[Pierluigi Passaro]

> > Just for my understanding, are you suggesting to set a device tree
> > property to force a fixed behavior in the driver ?

> Yes.

Why should we use a fixed behavior ?

> > WM8904 allows using both a DMIC and LINEIN, switching between one or
> > the other and this is how we currently use it.
> > Why the user should not be allowed to switch between DMIC and LINEIN ?

> The device shares pins between the line inputs and the DMIC inputs so at
> least some of the configuration is going to be determinted at system
> design time, that will fix the usable values of at least one of the
> controls which ought to be reflected in the runtime behaviour.

In our design we use:
- pin 1: DMIC_CLK
- pin 24: LINEIN2R
- pin 26: LINEIN2L
- pin 27: DMIC_DATA
we have no pins shared among DMIC and LINEIN.
We have several customer switching between DMIC and LINEIN at runtime.

> Please fix your mail client to word wrap within paragraphs at something
> substantially less than 80 columns.  Doing this makes your messages much
> easier to read and reply to.

I beg your pardon: it should be fixed now.

Re: [PATCH 4/4] ASoC: wm8904: add DMIC support

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 835 bytes --]

On Mon, Jun 20, 2022 at 03:30:45PM +0000, Pierluigi Passaro wrote:

> Just for my understanding, are you suggesting to set a device tree property to force a fixed behavior in the driver ?

Yes.

> WM8904 allows using both a DMIC and LINEIN, switching between one or the other and this is how we currently use it.
> Why the user should not be allowed to switch between DMIC and LINEIN ?

The device shares pins between the line inputs and the DMIC inputs so at
least some of the configuration is going to be determinted at system
design time, that will fix the usable values of at least one of the
controls which ought to be reflected in the runtime behaviour.

Please fix your mail client to word wrap within paragraphs at something
substantially less than 80 columns.  Doing this makes your messages much
easier to read and reply to.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [PATCH 4/4] ASoC: wm8904: add DMIC support

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 835 bytes --]

On Mon, Jun 20, 2022 at 03:30:45PM +0000, Pierluigi Passaro wrote:

> Just for my understanding, are you suggesting to set a device tree property to force a fixed behavior in the driver ?

Yes.

> WM8904 allows using both a DMIC and LINEIN, switching between one or the other and this is how we currently use it.
> Why the user should not be allowed to switch between DMIC and LINEIN ?

The device shares pins between the line inputs and the DMIC inputs so at
least some of the configuration is going to be determinted at system
design time, that will fix the usable values of at least one of the
controls which ought to be reflected in the runtime behaviour.

Please fix your mail client to word wrap within paragraphs at something
substantially less than 80 columns.  Doing this makes your messages much
easier to read and reply to.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [PATCH 4/4] ASoC: wm8904: add DMIC support

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 835 bytes --]

On Mon, Jun 20, 2022 at 03:30:45PM +0000, Pierluigi Passaro wrote:

> Just for my understanding, are you suggesting to set a device tree property to force a fixed behavior in the driver ?

Yes.

> WM8904 allows using both a DMIC and LINEIN, switching between one or the other and this is how we currently use it.
> Why the user should not be allowed to switch between DMIC and LINEIN ?

The device shares pins between the line inputs and the DMIC inputs so at
least some of the configuration is going to be determinted at system
design time, that will fix the usable values of at least one of the
controls which ought to be reflected in the runtime behaviour.

Please fix your mail client to word wrap within paragraphs at something
substantially less than 80 columns.  Doing this makes your messages much
easier to read and reply to.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [PATCH 4/4] ASoC: wm8904: add DMIC support

[Pierluigi Passaro]

> > > Via firmware description.

> > Can you please provide any reference approach in the kernel code ?

> git grep of_
> git grep fwnode_

> and I don't immediately remember what the prefix is for ACPI functions.

Just for my understanding, are you suggesting to set a device tree property to force a fixed behavior in the driver ?
WM8904 allows using both a DMIC and LINEIN, switching between one or the other and this is how we currently use it.
Why the user should not be allowed to switch between DMIC and LINEIN ?

Re: [PATCH 4/4] ASoC: wm8904: add DMIC support

[Pierluigi Passaro]

> > > Via firmware description.

> > Can you please provide any reference approach in the kernel code ?

> git grep of_
> git grep fwnode_

> and I don't immediately remember what the prefix is for ACPI functions.

Just for my understanding, are you suggesting to set a device tree property to force a fixed behavior in the driver ?
WM8904 allows using both a DMIC and LINEIN, switching between one or the other and this is how we currently use it.
Why the user should not be allowed to switch between DMIC and LINEIN ?

Re: [PATCH 4/4] ASoC: wm8904: add DMIC support

[Pierluigi Passaro]

> > > Via firmware description.

> > Can you please provide any reference approach in the kernel code ?

> git grep of_
> git grep fwnode_

> and I don't immediately remember what the prefix is for ACPI functions.

Just for my understanding, are you suggesting to set a device tree property to force a fixed behavior in the driver ?
WM8904 allows using both a DMIC and LINEIN, switching between one or the other and this is how we currently use it.
Why the user should not be allowed to switch between DMIC and LINEIN ?

Re: [PATCH 4/4] ASoC: wm8904: add DMIC support

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 272 bytes --]

On Mon, Jun 20, 2022 at 03:03:50PM +0000, Pierluigi Passaro wrote:

> > Via firmware description.

> Can you please provide any reference approach in the kernel code ?

git grep of_
git grep fwnode_

and I don't immediately remember what the prefix is for ACPI functions.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [PATCH 4/4] ASoC: wm8904: add DMIC support

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 272 bytes --]

On Mon, Jun 20, 2022 at 03:03:50PM +0000, Pierluigi Passaro wrote:

> > Via firmware description.

> Can you please provide any reference approach in the kernel code ?

git grep of_
git grep fwnode_

and I don't immediately remember what the prefix is for ACPI functions.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [PATCH 4/4] ASoC: wm8904: add DMIC support

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 272 bytes --]

On Mon, Jun 20, 2022 at 03:03:50PM +0000, Pierluigi Passaro wrote:

> > Via firmware description.

> Can you please provide any reference approach in the kernel code ?

git grep of_
git grep fwnode_

and I don't immediately remember what the prefix is for ACPI functions.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [PATCH 4/4] ASoC: wm8904: add DMIC support

[Pierluigi Passaro]

> > > > +static const char *cin_text[] = {
> > > > +     "ADC", "DMIC"
> > > > +};

> > > > +static SOC_ENUM_SINGLE_DECL(cin_enum,
> > > > +                         WM8904_DIGITAL_MICROPHONE_0, 12, cin_text);

> > > Why would this be runtime selectable?  I'd expect the decision to use
> > > an analogue or digital microphone to be made in the hardware design.

> > I agree that dedicated HW is required, but currently SW side there's no support at all.
> > This patch is aiming to provide a way to enable DMIC on boards using it.
> > Is this supposed to be managed in a different way ?

> Via firmware description.

Can you please provide any reference approach in the kernel code ?

Re: [PATCH 4/4] ASoC: wm8904: add DMIC support

[Pierluigi Passaro]

> > > > +static const char *cin_text[] = {
> > > > +     "ADC", "DMIC"
> > > > +};

> > > > +static SOC_ENUM_SINGLE_DECL(cin_enum,
> > > > +                         WM8904_DIGITAL_MICROPHONE_0, 12, cin_text);

> > > Why would this be runtime selectable?  I'd expect the decision to use
> > > an analogue or digital microphone to be made in the hardware design.

> > I agree that dedicated HW is required, but currently SW side there's no support at all.
> > This patch is aiming to provide a way to enable DMIC on boards using it.
> > Is this supposed to be managed in a different way ?

> Via firmware description.

Can you please provide any reference approach in the kernel code ?

Re: [PATCH 4/4] ASoC: wm8904: add DMIC support

[Pierluigi Passaro]

> > > > +static const char *cin_text[] = {
> > > > +     "ADC", "DMIC"
> > > > +};

> > > > +static SOC_ENUM_SINGLE_DECL(cin_enum,
> > > > +                         WM8904_DIGITAL_MICROPHONE_0, 12, cin_text);

> > > Why would this be runtime selectable?  I'd expect the decision to use
> > > an analogue or digital microphone to be made in the hardware design.

> > I agree that dedicated HW is required, but currently SW side there's no support at all.
> > This patch is aiming to provide a way to enable DMIC on boards using it.
> > Is this supposed to be managed in a different way ?

> Via firmware description.

Can you please provide any reference approach in the kernel code ?

Re: [PATCH 4/4] ASoC: wm8904: add DMIC support

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 679 bytes --]

On Mon, Jun 20, 2022 at 02:49:51PM +0000, Pierluigi Passaro wrote:

> > > +static const char *cin_text[] = {
> > > +     "ADC", "DMIC"
> > > +};

> > > +static SOC_ENUM_SINGLE_DECL(cin_enum,
> > > +                         WM8904_DIGITAL_MICROPHONE_0, 12, cin_text);

> > Why would this be runtime selectable?  I'd expect the decision to use
> > an analogue or digital microphone to be made in the hardware design.

> I agree that dedicated HW is required, but currently SW side there's no support at all.
> This patch is aiming to provide a way to enable DMIC on boards using it.
> Is this supposed to be managed in a different way ?

Via firmware description.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [PATCH 4/4] ASoC: wm8904: add DMIC support

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 679 bytes --]

On Mon, Jun 20, 2022 at 02:49:51PM +0000, Pierluigi Passaro wrote:

> > > +static const char *cin_text[] = {
> > > +     "ADC", "DMIC"
> > > +};

> > > +static SOC_ENUM_SINGLE_DECL(cin_enum,
> > > +                         WM8904_DIGITAL_MICROPHONE_0, 12, cin_text);

> > Why would this be runtime selectable?  I'd expect the decision to use
> > an analogue or digital microphone to be made in the hardware design.

> I agree that dedicated HW is required, but currently SW side there's no support at all.
> This patch is aiming to provide a way to enable DMIC on boards using it.
> Is this supposed to be managed in a different way ?

Via firmware description.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [PATCH 4/4] ASoC: wm8904: add DMIC support

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 679 bytes --]

On Mon, Jun 20, 2022 at 02:49:51PM +0000, Pierluigi Passaro wrote:

> > > +static const char *cin_text[] = {
> > > +     "ADC", "DMIC"
> > > +};

> > > +static SOC_ENUM_SINGLE_DECL(cin_enum,
> > > +                         WM8904_DIGITAL_MICROPHONE_0, 12, cin_text);

> > Why would this be runtime selectable?  I'd expect the decision to use
> > an analogue or digital microphone to be made in the hardware design.

> I agree that dedicated HW is required, but currently SW side there's no support at all.
> This patch is aiming to provide a way to enable DMIC on boards using it.
> Is this supposed to be managed in a different way ?

Via firmware description.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [PATCH 4/4] ASoC: wm8904: add DMIC support

[Pierluigi Passaro]

Hi All,

> > +static const char *cin_text[] = {
> > +     "ADC", "DMIC"
> > +};
> > +
> > +static SOC_ENUM_SINGLE_DECL(cin_enum,
> > +                         WM8904_DIGITAL_MICROPHONE_0, 12, cin_text);
> 
> Why would this be runtime selectable?  I'd expect the decision to use
> an analogue or digital microphone to be made in the hardware design.

I agree that dedicated HW is required, but currently SW side there's no support at all.
This patch is aiming to provide a way to enable DMIC on boards using it.
Is this supposed to be managed in a different way ?

Thanks
Best Regards
Pier

Re: [PATCH 4/4] ASoC: wm8904: add DMIC support

[Pierluigi Passaro]

Hi All,

> > +static const char *cin_text[] = {
> > +     "ADC", "DMIC"
> > +};
> > +
> > +static SOC_ENUM_SINGLE_DECL(cin_enum,
> > +                         WM8904_DIGITAL_MICROPHONE_0, 12, cin_text);
> 
> Why would this be runtime selectable?  I'd expect the decision to use
> an analogue or digital microphone to be made in the hardware design.

I agree that dedicated HW is required, but currently SW side there's no support at all.
This patch is aiming to provide a way to enable DMIC on boards using it.
Is this supposed to be managed in a different way ?

Thanks
Best Regards
Pier

Re: [PATCH 4/4] ASoC: wm8904: add DMIC support

[Pierluigi Passaro]

Hi All,

> > +static const char *cin_text[] = {
> > +     "ADC", "DMIC"
> > +};
> > +
> > +static SOC_ENUM_SINGLE_DECL(cin_enum,
> > +                         WM8904_DIGITAL_MICROPHONE_0, 12, cin_text);
> 
> Why would this be runtime selectable?  I'd expect the decision to use
> an analogue or digital microphone to be made in the hardware design.

I agree that dedicated HW is required, but currently SW side there's no support at all.
This patch is aiming to provide a way to enable DMIC on boards using it.
Is this supposed to be managed in a different way ?

Thanks
Best Regards
Pier