Re: [PATCH V2] ASoC: Intel: boards: Use FS as nau8825 sysclk in nau88125_* machine

On 5/1/20 2:31 PM, Radoslaw Biernacki wrote:

This single fix address two issues on machines with nau88125:

1. Audio distortion, due to lack of required clock rate on MCLK line
2. Loud audible "pops" on headphones if there is no sysclk during nau8825 playback power up sequence

Explanation for:

1. Due to Skylake HW limitation, MCLK pin can only output 24MHz clk rate (it can be only connected to XTAL parent clk). The BCLK pin can be driven by dividers and therefore FW is able to set it to rate required by chosen audio format. According to nau8825 datasheet, 256*FS sysclk gives the best audio quality and the only way to achieve this (taking into account the above limitations) its to regenerate the MCLK from BCLK on nau8825 side by FFL. Without required clk rate, audio is distorted by added harmonics.

The BCLK is going to be a multiple of 50 * Fs due to clocking restrictions. Can the codec regenerate a good-enough sysclk from this?

2. Currently Skylake does not output MCLK/FS when the back-end DAI op hw_param is called, so we cannot switch to MCLK/FS in hw_param. This patch reduces pop by letting nau8825 keep using its internal VCO clock during widget power up sequence, until SNDRV_PCM_TRIGGER_START when MCLK/FS is available. Once device resumes, the system will only enable power sequence for playback without doing hardware parameter, audio format, and PLL configure. In the mean time, the jack detecion sequence has changed PLL parameters and switched to internal clock. Thus, the playback signal distorted without correct PLL parameters. That is why we need to configure the PLL again in SNDRV_PCM_TRIGGER_RESUME case.

IIRC the FS can be controlled with the clk_ api with the Skylake driver, as done for some KBL platforms. Or is this not supported by the firmware used by this machine?

-static int skylake_nau8825_hw_params(struct snd_pcm_substream *substream,

• struct snd_pcm_hw_params *params)

+static int skylake_nau8825_trigger(struct snd_pcm_substream *substream, int cmd) { struct snd_soc_pcm_runtime *rtd = substream->private_data;

• struct snd_pcm_runtime *runtime = substream->runtime; struct snd_soc_dai *codec_dai = asoc_rtd_to_codec(rtd, 0);

• int ret;
• ret = snd_soc_dai_set_sysclk(codec_dai,

• 	NAU8825_CLK_MCLK, 24000000, SND_SOC_CLOCK_IN);
  

• int ret = 0;

• if (ret < 0)

• dev_err(rtd->dev, "snd_soc_dai_set_sysclk err = %d\n", ret);
  

• switch (cmd) {
• case SNDRV_PCM_TRIGGER_START:

• ret = snd_soc_dai_set_sysclk(codec_dai, NAU8825_CLK_FLL_FS, 0,
  

• 			     SND_SOC_CLOCK_IN);
  

• if (ret < 0) {
  

• 	dev_err(codec_dai->dev, "can't set FS clock %d\n", ret);
  

• 	break;
  

• }
  

• ret = snd_soc_dai_set_pll(codec_dai, 0, 0, runtime->rate,
  

• 			  runtime->rate * 256);
  

• if (ret < 0)
  

• 	dev_err(codec_dai->dev, "can't set FLL: %d\n", ret);
  

• break;
  

• case SNDRV_PCM_TRIGGER_RESUME:

• ret = snd_soc_dai_set_pll(codec_dai, 0, 0, runtime->rate,
  

• 			  runtime->rate * 256);
  

• if (ret < 0)
  

• 	dev_err(codec_dai->dev, "can't set FLL: %d\n", ret);
  

• msleep(20);
  

is there a reason why you'd need a msleep for resume and not for start?