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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




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);





[Index of Archives]     [ALSA User]     [Linux Audio Users]     [Pulse Audio]     [Kernel Archive]     [Asterisk PBX]     [Photo Sharing]     [Linux Sound]     [Video 4 Linux]     [Gimp]     [Yosemite News]

  Powered by Linux