Messages in this thread | | | Subject | Re: [PATCH V2] ASoC: Intel: boards: Use FS as nau8825 sysclk in nau88125_* machine | From | Pierre-Louis Bossart <> | Date | Tue, 5 May 2020 10:00:03 -0500 |
| |
>>> 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? > > According to Intel, silicon has a limitation, on SKL/KBL only clk_id = > SKL_XTAL, .name = "xtal" is available for IO domain. > As mentioned in the commit: > MCLK is generated by using 24MHz Xtal directly or applying a divider > (so no way of achieving the rate required by audio format). > BCLK/FS is generated from 24MHz and uses dividers and additional > padding bits are used to match the clock source. > Next gen silicon has the possibility of using additional clock sources. > > Summing up, using MCLK from SKL to NAU88L25 is not an option. > The only option we found is to use BCLK and regen the required clock > rate by FLL on the NAU88l25 side.
Right, this 24 MHz is a recurring problem. But what I was asking was if the NAU8825 is fine working with e.g. a 2.4MHz bit clock. i.e. with 25 bit slots or padding at the end of the frame?
> >>> >>> 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? > > According to Ben, SKL had limitations in FW for managing the clk's > back in the days. > Can you point to the other driver you mention so we can cross check?
There are two KBL drivers that control the SSP clocks from the machine driver, but indeed I don't know if this would work on Firmware, it'd be a question for Lech/Cezary.
kbl_rt5663_max98927.c: ret = clk_prepare_enable(priv->mclk); kbl_rt5663_max98927.c: ret = clk_prepare_enable(priv->sclk); kbl_rt5663_rt5514_max98927.c: ret = clk_prepare_enable(priv->mclk); kbl_rt5663_rt5514_max98927.c: ret = clk_prepare_enable(priv->sclk); kbl_rt5663_rt5514_max98927.c: ret = clk_prepare_enable(priv->mclk);
| |