The constraint is propagate to Front End Bitstream
for Front End and Back End share same snd_soc_pcm_runtime.

The constraint is not needed for Back End Bitstream
when there is be_hw_params_fixup() defined.

Signed-off-by: Shengjiu Wang <shengjiu.wang@nxp.com>
Tested-by: Fabio Estevam <festevam@denx.de>
---
 sound/soc/codecs/wm8524.c | 8 +++++---
 1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/sound/soc/codecs/wm8524.c b/sound/soc/codecs/wm8524.c
index 81f858f6bd67..442a59857875 100644
--- a/sound/soc/codecs/wm8524.c
+++ b/sound/soc/codecs/wm8524.c
@@ -61,6 +61,7 @@ static int wm8524_startup(struct snd_pcm_substream *substream,
 {
 	struct snd_soc_component *component = dai->component;
 	struct wm8524_priv *wm8524 = snd_soc_component_get_drvdata(component);
+	struct snd_soc_pcm_runtime *rtd = substream->private_data;
 
 	/* The set of sample rates that can be supported depends on the
 	 * MCLK supplied to the CODEC - enforce this.
@@ -71,9 +72,10 @@ static int wm8524_startup(struct snd_pcm_substream *substream,
 		return -EINVAL;
 	}
 
-	snd_pcm_hw_constraint_list(substream->runtime, 0,
-				   SNDRV_PCM_HW_PARAM_RATE,
-				   &wm8524->rate_constraint);
+	if (!rtd->dai_link->be_hw_params_fixup)
+		snd_pcm_hw_constraint_list(substream->runtime, 0,
+					   SNDRV_PCM_HW_PARAM_RATE,
+					   &wm8524->rate_constraint);
 
 	gpiod_set_value_cansleep(wm8524->mute, 1);
 
-- 
2.17.1

On Tue, Apr 12, 2022 at 05:13:46PM +0800, Shengjiu Wang wrote:
> The constraint is propagate to Front End Bitstream
> for Front End and Back End share same snd_soc_pcm_runtime.

> The constraint is not needed for Back End Bitstream
> when there is be_hw_params_fixup() defined.

> -	snd_pcm_hw_constraint_list(substream->runtime, 0,
> -				   SNDRV_PCM_HW_PARAM_RATE,
> -				   &wm8524->rate_constraint);
> +	if (!rtd->dai_link->be_hw_params_fixup)
> +		snd_pcm_hw_constraint_list(substream->runtime, 0,
> +					   SNDRV_PCM_HW_PARAM_RATE,
> +					   &wm8524->rate_constraint);

This applies in general to constraints set by the CODEC, it's not
something that should be fixed at the driver level.  Peering into the
runtime to see if DPCM is doing anything isn't a great solution here,
nor is having to open code it into the driver.  I already had it in the
back of my head to generalise the set constraints based on sysclk
pattern into the core, that might be productive here.