Received: by 2002:a05:6a10:8c0a:0:0:0:0 with SMTP id go10csp1926951pxb; Mon, 8 Mar 2021 09:34:29 -0800 (PST) X-Google-Smtp-Source: ABdhPJxV0uWznTdsg/uE/c5+nEP5Q2DkwTDMlw3OPNEdNnBBg2fkzpTCarJMm7IYFJkxqoqkeIEL X-Received: by 2002:a17:906:7e12:: with SMTP id e18mr16768611ejr.316.1615224869338; Mon, 08 Mar 2021 09:34:29 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1615224869; cv=none; d=google.com; s=arc-20160816; b=1FHp5Pbcsgp9bMyQWvuQuMaXmh+3lJTKrMo6Gfi2nm4QPFK4xmnuGkv3i9KByWliLW Xk/UkLxFu10D29iX8VTpkb8VnkV4qqNpXJdiFb6EyhNxP+jxF+aAqesTX5Z7z7bPe1PC H62D1C9UBjoJtpIHLgt6b59MfuPiEL7QeL63rBTJB2620k8ox5to69YZaBaYbUmCPsyk JPNAlwYfCeB+9E+vWcIRxptU2WcwB4VtCPNuI0IRl48XlMnTH1lE4qAMxav0Y1YsEH1k 085ddjg7VGlTQaiB0S7Wo/z1mZYmj84ekVe1Vfo+jrZDpPKVWLOXmzJyl9tdgwuVTqC1 OXVA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:dkim-signature; bh=1vN6k5pXokza2dBxBoaJoD8BYKPtCKRtAZbFCogTu4k=; b=H0wLx/wW5PSkFyIK5/NX+dAPmVIqoMfiw4SJpwbUdc3mRlGSsxSI2ocV8cgIkclm69 3LvscWbNpZshUcBNcuyOBrViZcRu4Dy/dSlqCMZouXEV9OyqI3lbpBVVcxdc3nROiABm 8qjZ/yIm0RVRSSTCB48WLisIVxYNu9qGo8/AGknr0FNwQ/y6QWnW7hW8XFT9P5TT504Z TvUZfkNBhHonCRW0hIwd0bIA5T4tcIc4zc5+bN19BT/XQRA90plmnp41vvp4UfejV2EY rM3sUPxEeRslo0W3l1sw6JZULK124xXI3oUUXz1D+PfxUFzUJlWYD/AoodSQiPI4schq /D6A== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=uzMcXdB9; 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=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id b18si7228522edh.13.2021.03.08.09.34.04; Mon, 08 Mar 2021 09:34:29 -0800 (PST) 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; dkim=pass header.i=@gmail.com header.s=20161025 header.b=uzMcXdB9; 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=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230125AbhCHRc2 (ORCPT + 99 others); Mon, 8 Mar 2021 12:32:28 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:40136 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230301AbhCHRcD (ORCPT ); Mon, 8 Mar 2021 12:32:03 -0500 Received: from mail-wr1-x42b.google.com (mail-wr1-x42b.google.com [IPv6:2a00:1450:4864:20::42b]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 06223C06174A; Mon, 8 Mar 2021 09:32:02 -0800 (PST) Received: by mail-wr1-x42b.google.com with SMTP id d15so12339473wrv.5; Mon, 08 Mar 2021 09:32:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=1vN6k5pXokza2dBxBoaJoD8BYKPtCKRtAZbFCogTu4k=; b=uzMcXdB9W0g3/ZzqbsUdTGkHnHhto0xQ0ZKxA6WLWZOAfmDO5zFTvvBnjRS6J7Ve2h 7ara4xxaM+MPvxBqK+rPRCCYPCdG+62lIjIfMd0W5ez17XMmvrhLiLMwrHMS/j20uaq2 VbXSXUAm62wZ0qqccLLQq3bbT+7mxYyPOidgu67rRGDm/KFOcmTFckvjYgP5uz660DyW 1L7ozkmQPZIxhtg/58TrgrV74I9QYq8mUoT6vNjgEksm37wtR0h4XQM7lFNjTzfT+05k r04dT+1u6QQN2q+QcAUjC3rrAg38lM/C3Xr/PxZWwBYT1Me0YwMqT0NZ0Kuwc4qGdBz5 GZNw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=1vN6k5pXokza2dBxBoaJoD8BYKPtCKRtAZbFCogTu4k=; b=LdshAGDehcfHxLL6MyzVYPP00loFKsKgD01kXRxwHjKTH5iNnkBRDEifeRgFb+BBwo iKmZtZBAVcK42EaC6lAfU6fMByrZZAYNxoiZ9nxzywVEKzEp1ry2dHNbWCWg1os/j7HO pXINirrfbvbDn2jE/PH7W+5QXfCtqjMZw2WpUaflVLdRD3K8ADOK6+w1XNRDR/CMg9xB sMA6VfbY9D3pIxQfGltFL9y5++jNwi+ThL2rlD3NtBv6ZL5nvHfbshCW2FIbCaY08SQ1 UpgvNor1j31y5ajtiCPX3wb9b+OsRwKqW+tM3qMxFmEMbvaSwizsGADAvMiFuz8Al4/D y3Dg== X-Gm-Message-State: AOAM532m2U9gnWEJ5d/nJ4vgOgkIvFvEg8J0fBw4H1ZvpY+emkk+CyQf UnCRsWUJ6XGPWm24Ul4tW1fE+1yY3ywA4RMv3aA= X-Received: by 2002:a5d:564b:: with SMTP id j11mr24184602wrw.326.1615224721526; Mon, 08 Mar 2021 09:32:01 -0800 (PST) MIME-Version: 1.0 References: <20210305190608.1834164-1-david.e.box@linux.intel.com> In-Reply-To: From: Rajneesh Bhardwaj Date: Mon, 8 Mar 2021 12:31:35 -0500 Message-ID: Subject: Re: [PATCH] platform/x86: intel_pmc: Ignore GBE LTR on Tiger Lake platforms To: "Limonciello, Mario" Cc: "David E. Box" , "hdegoede@redhat.com" , "mgross@linux.intel.com" , "sasha.neftin@intel.com" , "platform-driver-x86@vger.kernel.org" , "linux-kernel@vger.kernel.org" , "intel-wired-lan@lists.osuosl.org" Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Mar 8, 2021 at 12:20 PM Limonciello, Mario wrote: > > > > > [EXTERNAL EMAIL] > > > > Due to a HW limitation, the Latency Tolerance Reporting (LTR) value > > programmed in the Tiger Lake GBE controller is not large enough to allow > > the platform to enter Package C10, which in turn prevents the platform from > > achieving its low power target during suspend-to-idle. Ignore the GBE LTR > > value on Tiger Lake. LTR ignore functionality is currently performed solely > > by a debugfs write call. Split out the LTR code into its own function that > > can be called by both the debugfs writer and by this work around. > > > > Signed-off-by: David E. Box > > Reviewed-by: Sasha Neftin > > Cc: intel-wired-lan@lists.osuosl.org > > --- > > drivers/platform/x86/intel_pmc_core.c | 55 ++++++++++++++++++++------- > > 1 file changed, 42 insertions(+), 13 deletions(-) > > I feel like this driver change causes a weak reference between e1000e and intel_pmc_core. > It would mean significantly different behavior if you use e1000e but don't have PMC module > available for any reason. Can you elaborate what would change significantly? This is a FW/HW issue and the driver is just doing a work around to let the platform enter a deep idle state beyond PC10. If the system could enter PC10 and was denied entry by PMC only because of a bad LAN LTR, then that's purely an e1000e driver/GBE fw issue. > > In this case does it maybe make sense to at least use "imply" in the Kconfig for e1000e so > that selecting e1000e gets intel-pmc-core enabled too? This change would tell PMC to ignore GBE LTR, regardless of which GBE driver is selected. This doesn't bind e1000e. > > > > > diff --git a/drivers/platform/x86/intel_pmc_core.c > > b/drivers/platform/x86/intel_pmc_core.c > > index ee2f757515b0..ab31eb646a1a 100644 > > --- a/drivers/platform/x86/intel_pmc_core.c > > +++ b/drivers/platform/x86/intel_pmc_core.c > > @@ -863,34 +863,45 @@ static int pmc_core_pll_show(struct seq_file *s, void > > *unused) > > } > > DEFINE_SHOW_ATTRIBUTE(pmc_core_pll); > > > > -static ssize_t pmc_core_ltr_ignore_write(struct file *file, > > - const char __user *userbuf, > > - size_t count, loff_t *ppos) > > +static int pmc_core_write_ltr_ignore(u32 value) > > { > > struct pmc_dev *pmcdev = &pmc; > > const struct pmc_reg_map *map = pmcdev->map; > > - u32 val, buf_size, fd; > > - int err; > > - > > - buf_size = count < 64 ? count : 64; > > - > > - err = kstrtou32_from_user(userbuf, buf_size, 10, &val); > > - if (err) > > - return err; > > + u32 fd; > > + int err = 0; > > > > mutex_lock(&pmcdev->lock); > > > > - if (val > map->ltr_ignore_max) { > > + if (fls(value) > map->ltr_ignore_max) { > > err = -EINVAL; > > goto out_unlock; > > } > > > > fd = pmc_core_reg_read(pmcdev, map->ltr_ignore_offset); > > - fd |= (1U << val); > > + fd |= value; > > pmc_core_reg_write(pmcdev, map->ltr_ignore_offset, fd); > > > > out_unlock: > > mutex_unlock(&pmcdev->lock); > > + > > + return err; > > +} > > + > > +static ssize_t pmc_core_ltr_ignore_write(struct file *file, > > + const char __user *userbuf, > > + size_t count, loff_t *ppos) > > +{ > > + u32 buf_size, val; > > + int err; > > + > > + buf_size = count < 64 ? count : 64; > > + > > + err = kstrtou32_from_user(userbuf, buf_size, 10, &val); > > + if (err) > > + return err; > > + > > + err = pmc_core_write_ltr_ignore(1U << val); > > + > > return err == 0 ? count : err; > > } > > > > @@ -1189,6 +1200,15 @@ static int quirk_xtal_ignore(const struct dmi_system_id > > *id) > > return 0; > > } > > > > +static int quirk_ltr_ignore(u32 val) > > +{ > > + int err; > > + > > + err = pmc_core_write_ltr_ignore(val); > > + > > + return err; > > +} > > + > > static const struct dmi_system_id pmc_core_dmi_table[] = { > > { > > .callback = quirk_xtal_ignore, > > @@ -1244,6 +1264,15 @@ static int pmc_core_probe(struct platform_device *pdev) > > pmcdev->pmc_xram_read_bit = pmc_core_check_read_lock_bit(); > > dmi_check_system(pmc_core_dmi_table); > > > > + /* > > + * On TGL, due to a hardware limitation, the GBE LTR blocks PC10 when > > + * a cable is attached. Tell the PMC to ignore it. > > + */ > > + if (pmcdev->map == &tgl_reg_map) { > > + dev_dbg(&pdev->dev, "ignoring GBE LTR\n"); > > + quirk_ltr_ignore(1U << 3); > > + } > > + > > pmc_core_dbgfs_register(pmcdev); > > > > device_initialized = true; > > -- > > 2.25.1 > -- Thanks, Rajneesh