Received: by 2002:a05:6358:d09b:b0:dc:cd0c:909e with SMTP id jc27csp1148287rwb; Fri, 18 Nov 2022 13:33:40 -0800 (PST) X-Google-Smtp-Source: AA0mqf6dOfFfz/diyn6/+roFKOaJkbbEHHRGa5lvfs3f0TQ89qSN8hRWyPbG9P87JsHMLfFgEMAF X-Received: by 2002:a17:90a:8d13:b0:213:c15:6f08 with SMTP id c19-20020a17090a8d1300b002130c156f08mr9455328pjo.134.1668807220267; Fri, 18 Nov 2022 13:33:40 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1668807220; cv=none; d=google.com; s=arc-20160816; b=snvMIP4oDu391vvPPvqj2Y2/jbvXL37qXxKY3NC3t1Fbm5ido1o500SYoUZ0N5Dn56 M8v9l3SJPep8jjsTeRO8cNL1tMMFDumo+O5xX1gHL78fEa+evhG/tJi6wKrfNWQW89tn RFyei1WvR6i6tmCZXqS6y9iMRraKZ1Gf74ANoSXFrjaS1LdyS2PSrTNvoTAFVJ1EcQml u62h0ZxbnvCBxbEjY0AU+sgAyJCM6qLnt08jReA8UZlj6AVZxvuCqZwM4YdIIa6Uxlyo jvWBRiCf2L/MrMfXEBWby28qgn0zu6nuxMe5dY/4GsphRECh2SE6Bk9l0oyNaLE+l8ea nlpw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:dkim-signature; bh=j6b228sSBdmEe622PJPDcidu4wKiIoq5NrJur1C1NIQ=; b=mOINCyDKgVR4MTd1+41LpR3P8YcQgMeWAIkEAVG65JylUryyzKyDPIjbaTwOhaWPgG VF+1qB4lWkvpgSMMS911X77djBnVOsqyrSWL3i08cI8Nonev3EuWufkwMYrAr4AMy/Bk LnHSjSHvgraN4qYGf/niQA9y4ejGyMsZCvE6nKMX6Y1TvG7y+1ZO7Ng3jkLLLUfGovpK mY6y+cI6L5yQajx5xFkdpnpA3z4ZAQGqb+bxgK7eyFZVmme2fhmynyTPBAwrOaSWcGnB fNSbPVSyL6oB5NGMmYGdFzXYxmlqPSozu0UOnNqSLjbd8RQO+BWU1tJQGrcD/bmldf1A Mwdw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@chromium.org header.s=google header.b=Rp2BQyog; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=chromium.org Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id r74-20020a632b4d000000b00457dc916cd8si4561991pgr.152.2022.11.18.13.33.28; Fri, 18 Nov 2022 13:33:40 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@chromium.org header.s=google header.b=Rp2BQyog; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=chromium.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230387AbiKRU1h (ORCPT + 90 others); Fri, 18 Nov 2022 15:27:37 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:60264 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229829AbiKRU1g (ORCPT ); Fri, 18 Nov 2022 15:27:36 -0500 Received: from mail-io1-xd34.google.com (mail-io1-xd34.google.com [IPv6:2607:f8b0:4864:20::d34]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 43E9F3A7 for ; Fri, 18 Nov 2022 12:27:34 -0800 (PST) Received: by mail-io1-xd34.google.com with SMTP id s10so4685559ioa.5 for ; Fri, 18 Nov 2022 12:27:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=j6b228sSBdmEe622PJPDcidu4wKiIoq5NrJur1C1NIQ=; b=Rp2BQyogGJZQ7ZJZU5zktR/shwNgmYdk+YIhpqwuoI1mEaAsPi6k4IGEGidbqcsErp 0amawcgipK1ioOyWiU/787JHnl9fgdRHjZv9gQE+OL3KOGlcI8HWVTbO9eAtWkRm+PYU EDs8AG73P2oeMBc/EOKlKeCXmggbkHjUzGX14= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=j6b228sSBdmEe622PJPDcidu4wKiIoq5NrJur1C1NIQ=; b=m/zIwpBvQPM9to0K8cO9mu+c4wDfQ/xWZ97dCCqTGjjhF6rKMhfk0T16zENsYT7oRb YgL6qgIJBsAhOvBYliLZxm/RjcmWlCiupq/LVNTxMKkxVYQ7pRgQaImbfI0wBuIp5ZK9 KURxtX8A09vN+UjF9PsKTxt4JMyyfeGimISaS7dPW6BUGqOx8P5EhaBGmUdhpGbqQKTg gq3/bSjVvaLimbHJgpecibQS+0sD/4ABNQF11x82RRNmbyLFMyIFg/xCWIFMqHHcGFID 9Ai0v1aexEc22LlXQbAi9nrn83TMEmLveM3nItovzFwGYvIPcqIDd+eKLbZhiVqcBeWE BGJA== X-Gm-Message-State: ANoB5pnMGcXyTOW/TmYKy7DFywpzLHtGI+lmvb5/JFbPLoWafHjv72iL 7RyKcJwxkyHGgMLxmSHCz+j96g== X-Received: by 2002:a5e:df46:0:b0:6bb:e329:fcd7 with SMTP id g6-20020a5edf46000000b006bbe329fcd7mr4127553ioq.206.1668803253589; Fri, 18 Nov 2022 12:27:33 -0800 (PST) Received: from localhost (30.23.70.34.bc.googleusercontent.com. [34.70.23.30]) by smtp.gmail.com with UTF8SMTPSA id o8-20020a056e0214c800b002f9f44625fbsm1512925ilk.52.2022.11.18.12.27.33 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 18 Nov 2022 12:27:33 -0800 (PST) Date: Fri, 18 Nov 2022 20:27:32 +0000 From: Matthias Kaehlcke To: Krishna chaitanya chundru Cc: helgaas@kernel.org, linux-pci@vger.kernel.org, linux-arm-msm@vger.kernel.org, linux-kernel@vger.kernel.org, quic_vbadigan@quicinc.com, quic_hemantk@quicinc.com, quic_nitegupt@quicinc.com, quic_skananth@quicinc.com, quic_ramkri@quicinc.com, manivannan.sadhasivam@linaro.org, swboyd@chromium.org, dmitry.baryshkov@linaro.org, Prasad Malisetty , Bjorn Helgaas , "Saheed O. Bolarinwa" , Vidya Sagar , Krzysztof =?utf-8?Q?Wilczy=C5=84ski?= , Kai-Heng Feng Subject: Re: [PATCH v7] PCI/ASPM: Update LTR threshold based upon reported max latencies Message-ID: References: <1663315719-21563-1-git-send-email-quic_krichai@quicinc.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <1663315719-21563-1-git-send-email-quic_krichai@quicinc.com> X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE, SPF_HELO_NONE,SPF_PASS autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Sep 16, 2022 at 01:38:37PM +0530, Krishna chaitanya chundru wrote: > In ASPM driver, LTR threshold scale and value are updated based on > tcommon_mode and t_poweron values. In Kioxia NVMe L1.2 is failing due to > LTR threshold scale and value are greater values than max snoop/non-snoop > value. > > Based on PCIe r4.1, sec 5.5.1, L1.2 substate must be entered when > reported snoop/no-snoop values is greater than or equal to > LTR_L1.2_THRESHOLD value. > > Signed-off-by: Prasad Malisetty > Signed-off-by: Krishna chaitanya chundru > Acked-by: Manivannan Sadhasivam > --- > > I am taking this patch forward as prasad is no more working with our org. > changes since v6: > - Rebasing with pci/next. > changes since v5: > - no changes, just reposting as standalone patch instead of reply to > previous patch. > Changes since v4: > - Replaced conditional statements with min and max. > changes since v3: > - Changed the logic to include this condition "snoop/nosnoop > latencies are not equal to zero and lower than LTR_L1.2_THRESHOLD" > Changes since v2: > - Replaced LTRME logic with max snoop/no-snoop latencies check. > Changes since v1: > - Added missing variable declaration in v1 patch > --- > drivers/pci/pcie/aspm.c | 30 ++++++++++++++++++++++++++++++ > 1 file changed, 30 insertions(+) > > diff --git a/drivers/pci/pcie/aspm.c b/drivers/pci/pcie/aspm.c > index 928bf64..2bb8470 100644 > --- a/drivers/pci/pcie/aspm.c > +++ b/drivers/pci/pcie/aspm.c > @@ -486,13 +486,35 @@ static void aspm_calc_l1ss_info(struct pcie_link_state *link, > { > struct pci_dev *child = link->downstream, *parent = link->pdev; > u32 val1, val2, scale1, scale2; > + u32 max_val, max_scale, max_snp_scale, max_snp_val, max_nsnp_scale, max_nsnp_val; > u32 t_common_mode, t_power_on, l1_2_threshold, scale, value; > u32 ctl1 = 0, ctl2 = 0; > u32 pctl1, pctl2, cctl1, cctl2; > + u16 ltr; > + u16 max_snoop_lat, max_nosnoop_lat; > > if (!(link->aspm_support & ASPM_STATE_L1_2_MASK)) > return; > > + ltr = pci_find_ext_capability(child, PCI_EXT_CAP_ID_LTR); > + if (!ltr) > + return; > + > + pci_read_config_word(child, ltr + PCI_LTR_MAX_SNOOP_LAT, &max_snoop_lat); > + pci_read_config_word(child, ltr + PCI_LTR_MAX_NOSNOOP_LAT, &max_nosnoop_lat); > + > + max_snp_scale = (max_snoop_lat & PCI_LTR_SCALE_MASK) >> PCI_LTR_SCALE_SHIFT; > + max_snp_val = max_snoop_lat & PCI_LTR_VALUE_MASK; > + > + max_nsnp_scale = (max_nosnoop_lat & PCI_LTR_SCALE_MASK) >> PCI_LTR_SCALE_SHIFT; > + max_nsnp_val = max_nosnoop_lat & PCI_LTR_VALUE_MASK; > + > + /* choose the greater max scale value between snoop and no snoop value*/ > + max_scale = max(max_snp_scale, max_nsnp_scale); > + > + /* choose the greater max value between snoop and no snoop scales */ > + max_val = max(max_snp_val, max_nsnp_val); I suppose the goal is to dermine the max of snoop/no-snoop latency. Taking the max of scale and value separately won't yield the correct result when the scale is different for snoop vs no-snoop. Instead you need to convert scale + value to ns and determine the max of that (as done for 't_power_on'). > + > /* Choose the greater of the two Port Common_Mode_Restore_Times */ > val1 = (parent_l1ss_cap & PCI_L1SS_CAP_CM_RESTORE_TIME) >> 8; > val2 = (child_l1ss_cap & PCI_L1SS_CAP_CM_RESTORE_TIME) >> 8; > @@ -525,6 +547,14 @@ static void aspm_calc_l1ss_info(struct pcie_link_state *link, > */ > l1_2_threshold = 2 + 4 + t_common_mode + t_power_on; > encode_l12_threshold(l1_2_threshold, &scale, &value); > + > + /* > + * Based on PCIe r4.1, sec 5.5.1, L1.2 substate must be entered when reported > + * snoop/no-snoop values are greater than or equal to LTR_L1.2_THRESHOLD value. > + */ > + scale = min(scale, max_scale); > + value = min(value, max_val); This is wrong for the same reason as above, as Bjorn also pointed out in an earlier comment. Even with the values calculated correctly I'm not sure it this is the right thing to do, but I know little about LTR. In any case this patch reduces power consumption of the Kioxia NVMe significantly, essentially by programming an LTR_L1.2_THRESHOLD of 0ns instead of 86ns. I just came across Bjorn's recent 'PCI/ASPM: Fix L1SS issues' series [1] that corrects the LTR_L1.2_THRESHOLD calculation and landed upstream, unfortunately it doesn't magically fix the issues with the Kioxia NVMe :( [1] https://lore.kernel.org/lkml/ca836507-50ca-13bc-ef88-7f69b1333c99@linux.intel.com/T/#m3f223b7e582052159de7538bcaf2bea6d2071472