Received: by 2002:a25:1985:0:0:0:0:0 with SMTP id 127csp1043549ybz; Fri, 1 May 2020 13:18:53 -0700 (PDT) X-Google-Smtp-Source: APiQypIsma4l6l76CRt5mhMUsjO3mfRCsVVmdK/pC/Ov8qRyNKzj1m1O71r9xwuhEn8JO/ehOe6f X-Received: by 2002:a17:907:210d:: with SMTP id qn13mr4950820ejb.376.1588364333161; Fri, 01 May 2020 13:18:53 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1588364333; cv=none; d=google.com; s=arc-20160816; b=nOFQTMfHyY0a9CiWkm1QEx+LnmxU60u+HwCTyWkOgG4hVG/KN2bJxZpd4hTnRiAatc P/2LZ7WU9XJV8FpwFQ3lZGZMJ6ru+R+8sdFPZj2SI40d8rGXQ0WPtYIXVoFjkDhBjkQU TxGcOHIWM/URkI7VQp1EgGxhRA4QO/tlOqPvRAw+djIq6oK1XeWkp7H3RaFwMJdjXYMn z+GulMH7JmmJ2FG3MZdO6W9VvNVJeTpH0J+Y4miJ8ki2BE++gqZkBGxRGfD/N4lN+jkT pDXQw3gBXjgUMmu5VJKEkwP+fT7nyeIEQOJn7w4XFQ73qPOthOoNhjlrGNAU0nI/NUzT WIdQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding :content-language:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject:ironport-sdr:ironport-sdr; bh=5UuoFKc1V7TbYTrPzRizIjrW1zvTvK7wKyFRpiQnKM0=; b=jqtuus19h1PGIEmFrvoaqdEHWqbZQNViLsu9ycSCQLheNay13VOYN5uG9Yx/sqftLe iKSj60IRcWHPJm9XRBuG4C3gEsIG66VNS9EhxBAA10gaivprtU70A3/2wDcFDYWiRNPY wAGjQEa9dVCqw8kdyZyVFAQkVEK2bnJIPyj1Rbs8+TzOccPIFmaE92+RLESS3AxbBQd8 9UyETAhiDSWRpuJVUTUi34rgLiu/aIm3sfNxH5+3E45CfwwL74LkoZ8OIckh95Aj8hw9 8dHYXdA2pd6KeWBgnbbDrpmjx2HzWmqIbiIEVhqLXnTOX+7P/x4PIWpfFY4p48BAje4Q IgsA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id m18si2384854eja.298.2020.05.01.13.18.29; Fri, 01 May 2020 13:18:53 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726344AbgEAUQi (ORCPT + 99 others); Fri, 1 May 2020 16:16:38 -0400 Received: from mga17.intel.com ([192.55.52.151]:39412 "EHLO mga17.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726045AbgEAUQi (ORCPT ); Fri, 1 May 2020 16:16:38 -0400 IronPort-SDR: JCnf0JR6QjquQtyWCvLzQybgHnCl2d0RNKxW2ix3/l1F5v9oDrFlOYPf28b4cRw559gxgBz4N3 fscpww/woeAg== X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga002.jf.intel.com ([10.7.209.21]) by fmsmga107.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 01 May 2020 13:16:37 -0700 IronPort-SDR: 1GzbZ0PLz8ewGXbhrI0UK885C79CRjvVf7gZORcwqO/LIVMBQf1s9CM8kxn22edyQqKkH8TQnh F4Um4u0bLAMg== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.73,340,1583222400"; d="scan'208";a="276914737" Received: from srodrig5-mobl2.amr.corp.intel.com (HELO [10.254.111.158]) ([10.254.111.158]) by orsmga002.jf.intel.com with ESMTP; 01 May 2020 13:16:35 -0700 Subject: Re: [PATCH V2] ASoC: Intel: boards: Use FS as nau8825 sysclk in nau88125_* machine To: Radoslaw Biernacki , Liam Girdwood , Jie Yang , Jaroslav Kysela , Takashi Iwai Cc: Lech Betlej , alsa-devel@alsa-project.org, Todd Broch , Harshapriya , John Hsu , linux-kernel@vger.kernel.org, michal.sienkiewicz@intel.com, Ben Zhang , Mac Chiang , Yong Zhi , Marcin Wojtas , Vamshi Krishna , Alex Levin References: <20200501193141.30293-1-rad@semihalf.com> From: Pierre-Louis Bossart Message-ID: <3ad44b75-387f-da75-d7b2-3a16ed00550c@linux.intel.com> Date: Fri, 1 May 2020 15:16:35 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 MIME-Version: 1.0 In-Reply-To: <20200501193141.30293-1-rad@semihalf.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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?