Received: by 2002:a25:c593:0:0:0:0:0 with SMTP id v141csp645495ybe; Wed, 11 Sep 2019 02:27:56 -0700 (PDT) X-Google-Smtp-Source: APXvYqzt3zDRRh9hbAe4Z5ejSmtBeDdmq+2R8anvBR0Z4gtRNvrFUBKegmqJTlFlgokGd2J35jJK X-Received: by 2002:aa7:da8b:: with SMTP id q11mr35187788eds.19.1568194076688; Wed, 11 Sep 2019 02:27:56 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1568194076; cv=none; d=google.com; s=arc-20160816; b=rdQdVzgJAPGe6O5T4UMaRWjBh6mcLXrfAcV27o1cibPcr/8Js6YfLmL0S2sLnzfipt Lfi3Re22oPiEQZk5ZCQampvROx3WOdrU1uRnknM7F1xk+suhrQel7hPBxcqnuRd/Z9/u ZtNx5gH42a6ZNUv8kgmsiIa2ZGNlJh2UC/9/H8BEQRoraaKqS01/84oe9f62pMBx067G bQ94RuQjSPPDL7Z2Mq/V8PB1KSfdH6kSNqiuqUSLCvlyTCo2pstDP+Y2efWEAVuNUBA+ /oG5m3AVrbPO7GiDUhtIKlKCskskZbuIhM1nENNRM72pcV/ORlTrAMjD+NiRKJAVcMWz jGBA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=MfI8PRT0U5fm1+3oFuxOLGGlud2bAw+uX+QEXZX6OBw=; b=KnbXR5N71wVaAqf7qzWxx6dMtB7t/+Jf/ZEw6PTo28aZSHyVtVEMRZkOYOlyF317Ju FQDKLR7bxqdwPNfSgjZXdNzDxLokO3rS2pirvXb4qKrKQXMKhARP/6eiWuAupIIG4RV6 075QA+228Exi2/Soxl5tiRWTv3mfXk0fqH73Z1vWxKUu6rifLaw4iP8YsSOUs0uk5Nr7 5aXxCx3KoGvHUvhbGOIGL4qkFFejuZLIqp5IPOaDD0ZbNSCWyGa7Q43aZFkA+yqHRoXn CSBHSaQUOoFChft0oHw7IqGCbGL0pExkIGPAmFfaO0s1shA/xnkmyuttpazJ9YnqjDhi QLPw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id f20si10903427ejq.92.2019.09.11.02.27.32; Wed, 11 Sep 2019 02:27:56 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727461AbfIKJXO (ORCPT + 99 others); Wed, 11 Sep 2019 05:23:14 -0400 Received: from foss.arm.com ([217.140.110.172]:44230 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726889AbfIKJXO (ORCPT ); Wed, 11 Sep 2019 05:23:14 -0400 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 5F0FB337; Wed, 11 Sep 2019 02:23:13 -0700 (PDT) Received: from localhost (unknown [10.37.6.20]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id CA1923F71F; Wed, 11 Sep 2019 02:23:12 -0700 (PDT) Date: Wed, 11 Sep 2019 10:23:11 +0100 From: Andrew Murray To: Pankaj Dubey Cc: linux-pci@vger.kernel.org, linux-kernel@vger.kernel.org, Jingoo Han , gustavo.pimentel@synopsys.com, lorenzo.pieralisi@arm.com, Bjorn Helgaas , Anvesh Salveru Subject: Re: [PATCH 1/2] PCI: dwc: Add support to disable GEN3 equalization Message-ID: <20190911092310.GN9720@e119886-lin.cambridge.arm.com> References: <1568118302-10505-1-git-send-email-pankaj.dubey@samsung.com> <20190910135813.GK9720@e119886-lin.cambridge.arm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1+81 (426a6c1) (2018-08-26) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Sep 10, 2019 at 09:46:28PM +0530, Pankaj Dubey wrote: > On Tue, 10 Sep 2019 at 19:56, Andrew Murray wrote: > > > > On Tue, Sep 10, 2019 at 05:55:01PM +0530, Pankaj Dubey wrote: > > > From: Anvesh Salveru > > > > > > In some platforms, PCIe PHY may have issues which will prevent linkup > > > to happen in GEN3 or high speed. In case equalization fails, link will > > > fallback to GEN1. > > > > When you refer to "high speed", do you mean "higher speeds" as in GEN3, > > GEN4, etc? > > > > Yes. Will reword the commit message as "higher speeds" > > > > > > > Designware controller has support for disabling GEN3 equalization if > > > required. This patch enables the designware driver to disable the PCIe > > > GEN3 equalization by writing into PCIE_PORT_GEN3_RELATED. > > > > Thus limiting to GEN2 speeds max, right? > > > > Is the purpose of PORT_LOGIC_GEN3_EQ_DISABLE to disable GEN3 and above > > even though we advertise GEN3 and above speeds? I.e. the IP advertises > > GEN3 but the phy can't handle it, we can't change what the IP advertises > > and so we disable equalization to limit to GEN2? > > > > I notice many of the other dwc drivers (dra7xx, keystone, tegra194, imx6) > > seem to use the device tree to specify a max-link-speed and then impose > > that limit by changing the value in PCI_EXP_LNKCAP. Is your > > PORT_LOGIC_GEN3_EQ_DISABLE approach and alternative to the PCI_EXP_LNKCAP > > approach, or does your approach add something else? > > > > No, max speed will be still as per advertised by link or it will be > equal to the limited speed as per DT property if any. > This register will prohibit to perform all phases of equalization and > thus allowing link to happen in maximum supported/advertised speed. > > This is not to limit max link speed, this register helps link to > happen in higher speeds (GEN3/4) without going through equalization > phases. It is intended to use only if at all link fails to latch up in > GEN3/4 due to failure in equalization phases. I thought that for GEN3 and beyond equalization was *required* - with only phases 2 and 3 being optional. Therefore I'm suprised to see that if equalization does fail we continue to train the link anyway. Have I understood this correctly? Also are there any plans to provide patches to use this quirk on any drivers? > > > > > > > Platform drivers can disable equalization by setting the dwc_pci_quirk > > > flag DWC_EQUALIZATION_DISABLE. > > > > > > Signed-off-by: Anvesh Salveru > > > Signed-off-by: Pankaj Dubey > > > --- > > > drivers/pci/controller/dwc/pcie-designware.c | 7 +++++++ > > > drivers/pci/controller/dwc/pcie-designware.h | 7 +++++++ > > > 2 files changed, 14 insertions(+) > > > > > > diff --git a/drivers/pci/controller/dwc/pcie-designware.c b/drivers/pci/controller/dwc/pcie-designware.c > > > index 7d25102..bf82091 100644 > > > --- a/drivers/pci/controller/dwc/pcie-designware.c > > > +++ b/drivers/pci/controller/dwc/pcie-designware.c > > > @@ -466,4 +466,11 @@ void dw_pcie_setup(struct dw_pcie *pci) > > > break; > > > } > > > dw_pcie_writel_dbi(pci, PCIE_LINK_WIDTH_SPEED_CONTROL, val); > > > + > > > + val = dw_pcie_readl_dbi(pci, PCIE_PORT_GEN3_RELATED); > > > + > > > + if (pci->dwc_pci_quirk & DWC_EQUALIZATION_DISABLE) > > > + val |= PORT_LOGIC_GEN3_EQ_DISABLE; > > > + > > > + dw_pcie_writel_dbi(pci, PCIE_PORT_GEN3_RELATED, val); > > > > The problem here is that even when DWC_EQUALIZATION_DISABLE is not set > > the driver will read and write PCIE_PORT_GEN3_RELATED when it is not > > needed. How about something like: > > > > > + > > > + if (pci->dwc_pci_quirk & DWC_EQUALIZATION_DISABLE) { > > > + val = dw_pcie_readl_dbi(pci, PCIE_PORT_GEN3_RELATED); > > > + val |= PORT_LOGIC_GEN3_EQ_DISABLE; > > > + dw_pcie_writel_dbi(pci, PCIE_PORT_GEN3_RELATED, val); > > > + } > > > > Yes, before posting we taught about it, but then next patchset is > adding one more quirk and in that case we need to repeat read and > write under each if condition. I hope that repetition should be fine. I understand. I think the repetition is prefered over needlessly reading and writing registers. Given these quirks are so similar, I wouldn't have a problem with them being in the same patch. Thanks, Andrew Murray > > > > } > > > diff --git a/drivers/pci/controller/dwc/pcie-designware.h b/drivers/pci/controller/dwc/pcie-designware.h > > > index ffed084..a1453c5 100644 > > > --- a/drivers/pci/controller/dwc/pcie-designware.h > > > +++ b/drivers/pci/controller/dwc/pcie-designware.h > > > @@ -29,6 +29,9 @@ > > > #define LINK_WAIT_MAX_IATU_RETRIES 5 > > > #define LINK_WAIT_IATU 9 > > > > > > +/* Parameters for PCIe Quirks */ > > > +#define DWC_EQUALIZATION_DISABLE 0x1 > > > > How about using BIT(1) instead? Thus implying that you can combine > > quirks. > > > > Agreed. > > > Thanks, > > > > Andrew Murray > > > > > + > > > /* Synopsys-specific PCIe configuration registers */ > > > #define PCIE_PORT_LINK_CONTROL 0x710 > > > #define PORT_LINK_MODE_MASK GENMASK(21, 16) > > > @@ -60,6 +63,9 @@ > > > #define PCIE_MSI_INTR0_MASK 0x82C > > > #define PCIE_MSI_INTR0_STATUS 0x830 > > > > > > +#define PCIE_PORT_GEN3_RELATED 0x890 > > > +#define PORT_LOGIC_GEN3_EQ_DISABLE BIT(16) > > > + > > > #define PCIE_ATU_VIEWPORT 0x900 > > > #define PCIE_ATU_REGION_INBOUND BIT(31) > > > #define PCIE_ATU_REGION_OUTBOUND 0 > > > @@ -244,6 +250,7 @@ struct dw_pcie { > > > struct dw_pcie_ep ep; > > > const struct dw_pcie_ops *ops; > > > unsigned int version; > > > + unsigned int dwc_pci_quirk; > > > }; > > > > > > #define to_dw_pcie_from_pp(port) container_of((port), struct dw_pcie, pp) > > > -- > > > 2.7.4 > > >