Messages in this thread | | | Subject | Re: [PATCH V2] ASoC: Intel: boards: Use FS as nau8825 sysclk in nau88125_* machine | From | Pierre-Louis Bossart <> | Date | Fri, 1 May 2020 15:16:35 -0500 |
| |
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?
| |