All of lore.kernel.org
 help / color / mirror / Atom feed
From: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
To: Krishna Chaitanya Chundru <quic_krichai@quicinc.com>
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_ramkri@quicinc.com,
	swboyd@chromium.org, "Bjorn Helgaas" <bhelgaas@google.com>,
	"Saheed O. Bolarinwa" <refactormyself@gmail.com>,
	"Krzysztof Wilczyński" <kw@linux.com>,
	"Rajat Jain" <rajatja@google.com>,
	vidyas@nvidia.com, kenny@panix.com
Subject: Re: [PATCH v3] PCI/ASPM: Update LTR threshold based upon reported max latencies
Date: Thu, 2 Jun 2022 13:59:38 +0530	[thread overview]
Message-ID: <20220602082938.GA4936@thinkpad> (raw)
In-Reply-To: <91b75542-8e4c-5b91-bbfd-38ffc456c12e@quicinc.com>

On Wed, Jun 01, 2022 at 05:57:53PM +0530, Krishna Chaitanya Chundru wrote:
> [+cc kenny, vidya]
> 
> On 6/1/2022 5:53 PM, Krishna chaitanya chundru wrote:
> > In ASPM driver, LTR threshold scale and value is updating based on

s/is/are

s/updating/updated

> > tcommon_mode and t_poweron values. In kioxia NVMe L1.2 is failing due to
> > LTR threshold scale and value is greater values than max snoop/non-snoop

s/is/are

> > value.
> > 
> > Based on PCIe r4.1, sec 5.5.1, L1.2 substate must be entered when
> > reported snoop/no-snoop values is greather than or equal to
> > LTR_L1.2_THRESHOLD value.
> > 
> > Suggested-by: Prasad Malisetty  <quic_pmaliset@quicinc.com>
> > Signed-off-by: Krishna chaitanya chundru <quic_krichai@quicinc.com>

If you are inheriting the patch from Prasad, then you should still give the
authorship to him (unless the patch has changed significantly). You can add
your S-o-b tag to convey that you are carrying the patch from him.

> > ---
> > 
> > I am takking this patch forward as prasad is no more working with our org.
> > 
> > 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 | 22 +++++++++++++++++++++-
> >   1 file changed, 21 insertions(+), 1 deletion(-)
> > 
> > diff --git a/drivers/pci/pcie/aspm.c b/drivers/pci/pcie/aspm.c
> > index a96b742..4a15e50 100644
> > --- a/drivers/pci/pcie/aspm.c
> > +++ b/drivers/pci/pcie/aspm.c
> > @@ -465,10 +465,19 @@ static void aspm_calc_l1ss_info(struct pcie_link_state *link,
> >   	u32 ctl1 = 0, ctl2 = 0;
> >   	u32 pctl1, pctl2, cctl1, cctl2;
> >   	u32 pl1_2_enables, cl1_2_enables;
> > +	int ltr;

This could be u16 too.

> > +	u16 max_snoop_lat = 0, max_nosnoop_lat = 0;

No need to initialize these variables.

> >   	if (!(link->aspm_support & ASPM_STATE_L1_2_MASK))
> >   		return;
> > +	ltr = pci_find_ext_capability(child, PCI_EXT_CAP_ID_LTR);
> > +	if (!ltr)
> > +		return;

Is this capability implemented always?

> > +
> > +	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);
> > +
> >   	/* 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;
> > @@ -501,7 +510,18 @@ 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);
> > -	ctl1 |= t_common_mode << 8 | scale << 29 | value << 16;
> > +
> > +	/*
> > +	 * If the max snoop and no snoop latencies are '0', then avoid updating scale
> > +	 * and value.
> > +	 *

This looks fine but...

> > +	 * Based on PCIe r4.1, sec 5.5.1, L1.2 substate must be entered when reported
> > +	 * snoop/no-snoop values is greather than or equal to LTR_L1.2_THRESHOLD value.

s/is/are

What about this? What if the snoop/nosnoop latencies are not equal to zero and
lower than LTR_L1.2_THRESHOLD?

Thanks,
Mani

> > +	 */
> > +	if ((max_snoop_lat == 0) && (max_nosnoop_lat == 0))
> > +		ctl1 |= t_common_mode << 8;
> > +	else
> > +		ctl1 |= t_common_mode << 8 | scale << 29 | value << 16;
> >   	/* Some broken devices only support dword access to L1 SS */
> >   	pci_read_config_dword(parent, parent->l1ss + PCI_L1SS_CTL1, &pctl1);

-- 
மணிவண்ணன் சதாசிவம்

  reply	other threads:[~2022-06-02  8:29 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-03-07 18:59 [PATCH v2] [RFC PATCH] PCI: Update LTR threshold based on LTRME bit Prasad Malisetty
2022-03-17 19:07 ` Stephen Boyd
2022-04-05  6:24   ` Prasad Malisetty (Temp)
2022-04-05 18:57     ` Stephen Boyd
2022-04-05 16:08 ` Bjorn Helgaas
2022-04-12 22:46 ` Bjorn Helgaas
2022-06-01 12:23 ` [PATCH v3] PCI/ASPM: Update LTR threshold based upon reported max latencies Krishna chaitanya chundru
2022-06-01 12:27   ` Krishna Chaitanya Chundru
2022-06-02  8:29     ` Manivannan Sadhasivam [this message]
2022-06-02  9:59       ` Krishna Chaitanya Chundru
2022-06-03  7:54 ` [PATCH v4] " Krishna chaitanya chundru
2022-06-08 22:22   ` Stephen Boyd
2022-06-10  5:08   ` [PATCH v5] " Krishna chaitanya chundru
2022-06-15 13:23     ` Krishna Chaitanya Chundru
2022-07-15  8:28       ` Manivannan Sadhasivam
2022-07-15 11:28         ` Krishna Chaitanya Chundru
2022-06-15 17:39     ` Manivannan Sadhasivam

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20220602082938.GA4936@thinkpad \
    --to=manivannan.sadhasivam@linaro.org \
    --cc=bhelgaas@google.com \
    --cc=helgaas@kernel.org \
    --cc=kenny@panix.com \
    --cc=kw@linux.com \
    --cc=linux-arm-msm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=quic_krichai@quicinc.com \
    --cc=quic_ramkri@quicinc.com \
    --cc=quic_vbadigan@quicinc.com \
    --cc=rajatja@google.com \
    --cc=refactormyself@gmail.com \
    --cc=swboyd@chromium.org \
    --cc=vidyas@nvidia.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.