All of lore.kernel.org
 help / color / mirror / Atom feed
From: Bjorn Helgaas <helgaas@kernel.org>
To: Kishon Vijay Abraham I <kishon@ti.com>
Cc: Tom Joseph <tjoseph@cadence.com>, Rob Herring <robh@kernel.org>,
	Bjorn Helgaas <bhelgaas@google.com>,
	Nadeem Athani <nadeem@cadence.com>,
	linux-omap@vger.kernel.org, linux-pci@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org, mparab@cadence.com,
	sjakhade@cadence.com, pthombar@cadence.com
Subject: Re: [PATCH v5] PCI: cadence: Retrain Link to work around Gen2 training defect.
Date: Tue, 15 Dec 2020 17:30:28 -0600	[thread overview]
Message-ID: <20201215233028.GA336802@bjorn-Precision-5520> (raw)
In-Reply-To: <20201215070009.27937-1-kishon@ti.com>

On Tue, Dec 15, 2020 at 12:30:09PM +0530, Kishon Vijay Abraham I wrote:
> From: Nadeem Athani <nadeem@cadence.com>
> 
> Cadence controller will not initiate autonomous speed change if strapped as
> Gen2. The Retrain Link bit is set as quirk to enable this speed change.
> 
> Signed-off-by: Nadeem Athani <nadeem@cadence.com>
> [kishon@ti.com: Enable the workaround for TI's J721E SoC]
> Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
> ---
> Hi Lorenzo,
> The previous version of the patch can be found at [1].
> I slightly re-worked the patch from Nadeem
> *) Removed additional Link Up Check
> *) Removed quirk from pcie-cadence-plat.c
> *) Also removed additional compatible
>    "cdns,cdns-pcie-host-quirk-retrain" added in that series
> *) Enabled the quirk for J721E
> [1] -> http://lore.kernel.org/r/20201211144236.3825-1-nadeem@cadence.com
> 
>  drivers/pci/controller/cadence/pci-j721e.c    |  3 +
>  .../controller/cadence/pcie-cadence-host.c    | 67 ++++++++++++++-----
>  drivers/pci/controller/cadence/pcie-cadence.h | 11 ++-
>  3 files changed, 62 insertions(+), 19 deletions(-)
> 
> diff --git a/drivers/pci/controller/cadence/pci-j721e.c b/drivers/pci/controller/cadence/pci-j721e.c
> index dac1ac8a7615..baf729850cb1 100644
> --- a/drivers/pci/controller/cadence/pci-j721e.c
> +++ b/drivers/pci/controller/cadence/pci-j721e.c
> @@ -64,6 +64,7 @@ enum j721e_pcie_mode {
>  
>  struct j721e_pcie_data {
>  	enum j721e_pcie_mode	mode;
> +	bool			quirk_retrain_flag;
>  };
>  
>  static inline u32 j721e_pcie_user_readl(struct j721e_pcie *pcie, u32 offset)
> @@ -280,6 +281,7 @@ static struct pci_ops cdns_ti_pcie_host_ops = {
>  
>  static const struct j721e_pcie_data j721e_pcie_rc_data = {
>  	.mode = PCI_MODE_RC,
> +	.quirk_retrain_flag = true,
>  };
>  
>  static const struct j721e_pcie_data j721e_pcie_ep_data = {
> @@ -388,6 +390,7 @@ static int j721e_pcie_probe(struct platform_device *pdev)
>  
>  		bridge->ops = &cdns_ti_pcie_host_ops;
>  		rc = pci_host_bridge_priv(bridge);
> +		rc->quirk_retrain_flag = data->quirk_retrain_flag;
>  
>  		cdns_pcie = &rc->pcie;
>  		cdns_pcie->dev = dev;
> diff --git a/drivers/pci/controller/cadence/pcie-cadence-host.c b/drivers/pci/controller/cadence/pcie-cadence-host.c
> index 811c1cb2e8de..773c0d1137ed 100644
> --- a/drivers/pci/controller/cadence/pcie-cadence-host.c
> +++ b/drivers/pci/controller/cadence/pcie-cadence-host.c
> @@ -77,6 +77,50 @@ static struct pci_ops cdns_pcie_host_ops = {
>  	.write		= pci_generic_config_write,
>  };
>  
> +static int cdns_pcie_host_wait_for_link(struct cdns_pcie *pcie)
> +{
> +	struct device *dev = pcie->dev;
> +	int retries;
> +
> +	/* Check if the link is up or not */
> +	for (retries = 0; retries < LINK_WAIT_MAX_RETRIES; retries++) {
> +		if (cdns_pcie_link_up(pcie)) {

- cdns_pcie_link_up() always returns "true" except for j721e_pcie_ops.
  Is it really true that we can assume the link is up otherwise?

- Where did the LINK_WAIT_* values come from?  Are they derived from
  something in the PCIe spec?

- Is the LINK_WAIT timeout related to LINK_RETRAIN_TIMEOUT?

- If the PCI core does a link retrain, e.g., in pcie_retrain_link(),
  does that work correctly on this device?

[I see now that this patch only *moves* this code without changing it.
But I'm still curious.]

> +			dev_info(dev, "Link up\n");
> +			return 0;
> +		}
> +		usleep_range(LINK_WAIT_USLEEP_MIN, LINK_WAIT_USLEEP_MAX);
> +	}
> +
> +	return -ETIMEDOUT;
> +}
> +
> +static void cdns_pcie_retrain(struct cdns_pcie *pcie)
> +{
> +	u32 lnk_cap_sls, pcie_cap_off = CDNS_PCIE_RP_CAP_OFFSET;
> +	u16 lnk_stat, lnk_ctl;
> +
> +	/*
> +	 * Set retrain bit if current speed is 2.5 GB/s,
> +	 * but the PCIe root port support is > 2.5 GB/s.
> +	 */
> +
> +	lnk_cap_sls = cdns_pcie_readl(pcie, (CDNS_PCIE_RP_BASE + pcie_cap_off +
> +					     PCI_EXP_LNKCAP));
> +	if ((lnk_cap_sls & PCI_EXP_LNKCAP_SLS) <= PCI_EXP_LNKCAP_SLS_2_5GB)
> +		return;
> +
> +	lnk_stat = cdns_pcie_rp_readw(pcie, pcie_cap_off + PCI_EXP_LNKSTA);
> +	if ((lnk_stat & PCI_EXP_LNKSTA_CLS) == PCI_EXP_LNKSTA_CLS_2_5GB) {
> +		lnk_ctl = cdns_pcie_rp_readw(pcie,
> +					     pcie_cap_off + PCI_EXP_LNKCTL);
> +		lnk_ctl |= PCI_EXP_LNKCTL_RL;
> +		cdns_pcie_rp_writew(pcie, pcie_cap_off + PCI_EXP_LNKCTL,
> +				    lnk_ctl);
> +
> +		if (cdns_pcie_host_wait_for_link(pcie))
> +			return;
> +	}
> +}
>  
>  static int cdns_pcie_host_init_root_port(struct cdns_pcie_rc *rc)
>  {
> @@ -398,23 +442,6 @@ static int cdns_pcie_host_init(struct device *dev,
>  	return cdns_pcie_host_init_address_translation(rc);
>  }
>  
> -static int cdns_pcie_host_wait_for_link(struct cdns_pcie *pcie)
> -{
> -	struct device *dev = pcie->dev;
> -	int retries;
> -
> -	/* Check if the link is up or not */
> -	for (retries = 0; retries < LINK_WAIT_MAX_RETRIES; retries++) {
> -		if (cdns_pcie_link_up(pcie)) {
> -			dev_info(dev, "Link up\n");
> -			return 0;
> -		}
> -		usleep_range(LINK_WAIT_USLEEP_MIN, LINK_WAIT_USLEEP_MAX);
> -	}
> -
> -	return -ETIMEDOUT;
> -}

This piece looks like a pure move of cdns_pcie_host_wait_for_link()
with no other changes.  It would be nicer to split that to a separate
patch so it doesn't obscure what's really happening in this patch.

>  int cdns_pcie_host_setup(struct cdns_pcie_rc *rc)
>  {
>  	struct device *dev = rc->pcie.dev;
> @@ -458,8 +485,12 @@ int cdns_pcie_host_setup(struct cdns_pcie_rc *rc)
>  	}
>  
>  	ret = cdns_pcie_host_wait_for_link(pcie);
> -	if (ret)
> +	if (ret) {
>  		dev_dbg(dev, "PCIe link never came up\n");
> +	} else {
> +		if (rc->quirk_retrain_flag)
> +			cdns_pcie_retrain(pcie);
> +	}
>  
>  	for (bar = RP_BAR0; bar <= RP_NO_BAR; bar++)
>  		rc->avail_ib_bar[bar] = true;
> diff --git a/drivers/pci/controller/cadence/pcie-cadence.h b/drivers/pci/controller/cadence/pcie-cadence.h
> index 30eba6cafe2c..0f29128a5d0a 100644
> --- a/drivers/pci/controller/cadence/pcie-cadence.h
> +++ b/drivers/pci/controller/cadence/pcie-cadence.h
> @@ -119,7 +119,7 @@
>   * Root Port Registers (PCI configuration space for the root port function)
>   */
>  #define CDNS_PCIE_RP_BASE	0x00200000
> -
> +#define CDNS_PCIE_RP_CAP_OFFSET 0xc0
>  
>  /*
>   * Address Translation Registers
> @@ -291,6 +291,7 @@ struct cdns_pcie {
>   * @device_id: PCI device ID
>   * @avail_ib_bar: Satus of RP_BAR0, RP_BAR1 and	RP_NO_BAR if it's free or
>   *                available
> + * @quirk_retrain_flag: Retrain link as quirk for PCIe Gen2
>   */
>  struct cdns_pcie_rc {
>  	struct cdns_pcie	pcie;
> @@ -299,6 +300,7 @@ struct cdns_pcie_rc {
>  	u32			vendor_id;
>  	u32			device_id;
>  	bool			avail_ib_bar[CDNS_PCIE_RP_MAX_IB];
> +	bool			quirk_retrain_flag;
>  };
>  
>  /**
> @@ -414,6 +416,13 @@ static inline void cdns_pcie_rp_writew(struct cdns_pcie *pcie,
>  	cdns_pcie_write_sz(addr, 0x2, value);
>  }
>  
> +static inline u16 cdns_pcie_rp_readw(struct cdns_pcie *pcie, u32 reg)
> +{
> +	void __iomem *addr = pcie->reg_base + CDNS_PCIE_RP_BASE + reg;
> +
> +	return cdns_pcie_read_sz(addr, 0x2);
> +}
> +
>  /* Endpoint Function register access */
>  static inline void cdns_pcie_ep_fn_writeb(struct cdns_pcie *pcie, u8 fn,
>  					  u32 reg, u8 value)
> -- 
> 2.17.1
> 

WARNING: multiple messages have this Message-ID (diff)
From: Bjorn Helgaas <helgaas@kernel.org>
To: Kishon Vijay Abraham I <kishon@ti.com>
Cc: Rob Herring <robh@kernel.org>, Nadeem Athani <nadeem@cadence.com>,
	mparab@cadence.com, linux-pci@vger.kernel.org,
	pthombar@cadence.com, linux-kernel@vger.kernel.org,
	Tom Joseph <tjoseph@cadence.com>,
	sjakhade@cadence.com, Bjorn Helgaas <bhelgaas@google.com>,
	linux-omap@vger.kernel.org, linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH v5] PCI: cadence: Retrain Link to work around Gen2 training defect.
Date: Tue, 15 Dec 2020 17:30:28 -0600	[thread overview]
Message-ID: <20201215233028.GA336802@bjorn-Precision-5520> (raw)
In-Reply-To: <20201215070009.27937-1-kishon@ti.com>

On Tue, Dec 15, 2020 at 12:30:09PM +0530, Kishon Vijay Abraham I wrote:
> From: Nadeem Athani <nadeem@cadence.com>
> 
> Cadence controller will not initiate autonomous speed change if strapped as
> Gen2. The Retrain Link bit is set as quirk to enable this speed change.
> 
> Signed-off-by: Nadeem Athani <nadeem@cadence.com>
> [kishon@ti.com: Enable the workaround for TI's J721E SoC]
> Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
> ---
> Hi Lorenzo,
> The previous version of the patch can be found at [1].
> I slightly re-worked the patch from Nadeem
> *) Removed additional Link Up Check
> *) Removed quirk from pcie-cadence-plat.c
> *) Also removed additional compatible
>    "cdns,cdns-pcie-host-quirk-retrain" added in that series
> *) Enabled the quirk for J721E
> [1] -> http://lore.kernel.org/r/20201211144236.3825-1-nadeem@cadence.com
> 
>  drivers/pci/controller/cadence/pci-j721e.c    |  3 +
>  .../controller/cadence/pcie-cadence-host.c    | 67 ++++++++++++++-----
>  drivers/pci/controller/cadence/pcie-cadence.h | 11 ++-
>  3 files changed, 62 insertions(+), 19 deletions(-)
> 
> diff --git a/drivers/pci/controller/cadence/pci-j721e.c b/drivers/pci/controller/cadence/pci-j721e.c
> index dac1ac8a7615..baf729850cb1 100644
> --- a/drivers/pci/controller/cadence/pci-j721e.c
> +++ b/drivers/pci/controller/cadence/pci-j721e.c
> @@ -64,6 +64,7 @@ enum j721e_pcie_mode {
>  
>  struct j721e_pcie_data {
>  	enum j721e_pcie_mode	mode;
> +	bool			quirk_retrain_flag;
>  };
>  
>  static inline u32 j721e_pcie_user_readl(struct j721e_pcie *pcie, u32 offset)
> @@ -280,6 +281,7 @@ static struct pci_ops cdns_ti_pcie_host_ops = {
>  
>  static const struct j721e_pcie_data j721e_pcie_rc_data = {
>  	.mode = PCI_MODE_RC,
> +	.quirk_retrain_flag = true,
>  };
>  
>  static const struct j721e_pcie_data j721e_pcie_ep_data = {
> @@ -388,6 +390,7 @@ static int j721e_pcie_probe(struct platform_device *pdev)
>  
>  		bridge->ops = &cdns_ti_pcie_host_ops;
>  		rc = pci_host_bridge_priv(bridge);
> +		rc->quirk_retrain_flag = data->quirk_retrain_flag;
>  
>  		cdns_pcie = &rc->pcie;
>  		cdns_pcie->dev = dev;
> diff --git a/drivers/pci/controller/cadence/pcie-cadence-host.c b/drivers/pci/controller/cadence/pcie-cadence-host.c
> index 811c1cb2e8de..773c0d1137ed 100644
> --- a/drivers/pci/controller/cadence/pcie-cadence-host.c
> +++ b/drivers/pci/controller/cadence/pcie-cadence-host.c
> @@ -77,6 +77,50 @@ static struct pci_ops cdns_pcie_host_ops = {
>  	.write		= pci_generic_config_write,
>  };
>  
> +static int cdns_pcie_host_wait_for_link(struct cdns_pcie *pcie)
> +{
> +	struct device *dev = pcie->dev;
> +	int retries;
> +
> +	/* Check if the link is up or not */
> +	for (retries = 0; retries < LINK_WAIT_MAX_RETRIES; retries++) {
> +		if (cdns_pcie_link_up(pcie)) {

- cdns_pcie_link_up() always returns "true" except for j721e_pcie_ops.
  Is it really true that we can assume the link is up otherwise?

- Where did the LINK_WAIT_* values come from?  Are they derived from
  something in the PCIe spec?

- Is the LINK_WAIT timeout related to LINK_RETRAIN_TIMEOUT?

- If the PCI core does a link retrain, e.g., in pcie_retrain_link(),
  does that work correctly on this device?

[I see now that this patch only *moves* this code without changing it.
But I'm still curious.]

> +			dev_info(dev, "Link up\n");
> +			return 0;
> +		}
> +		usleep_range(LINK_WAIT_USLEEP_MIN, LINK_WAIT_USLEEP_MAX);
> +	}
> +
> +	return -ETIMEDOUT;
> +}
> +
> +static void cdns_pcie_retrain(struct cdns_pcie *pcie)
> +{
> +	u32 lnk_cap_sls, pcie_cap_off = CDNS_PCIE_RP_CAP_OFFSET;
> +	u16 lnk_stat, lnk_ctl;
> +
> +	/*
> +	 * Set retrain bit if current speed is 2.5 GB/s,
> +	 * but the PCIe root port support is > 2.5 GB/s.
> +	 */
> +
> +	lnk_cap_sls = cdns_pcie_readl(pcie, (CDNS_PCIE_RP_BASE + pcie_cap_off +
> +					     PCI_EXP_LNKCAP));
> +	if ((lnk_cap_sls & PCI_EXP_LNKCAP_SLS) <= PCI_EXP_LNKCAP_SLS_2_5GB)
> +		return;
> +
> +	lnk_stat = cdns_pcie_rp_readw(pcie, pcie_cap_off + PCI_EXP_LNKSTA);
> +	if ((lnk_stat & PCI_EXP_LNKSTA_CLS) == PCI_EXP_LNKSTA_CLS_2_5GB) {
> +		lnk_ctl = cdns_pcie_rp_readw(pcie,
> +					     pcie_cap_off + PCI_EXP_LNKCTL);
> +		lnk_ctl |= PCI_EXP_LNKCTL_RL;
> +		cdns_pcie_rp_writew(pcie, pcie_cap_off + PCI_EXP_LNKCTL,
> +				    lnk_ctl);
> +
> +		if (cdns_pcie_host_wait_for_link(pcie))
> +			return;
> +	}
> +}
>  
>  static int cdns_pcie_host_init_root_port(struct cdns_pcie_rc *rc)
>  {
> @@ -398,23 +442,6 @@ static int cdns_pcie_host_init(struct device *dev,
>  	return cdns_pcie_host_init_address_translation(rc);
>  }
>  
> -static int cdns_pcie_host_wait_for_link(struct cdns_pcie *pcie)
> -{
> -	struct device *dev = pcie->dev;
> -	int retries;
> -
> -	/* Check if the link is up or not */
> -	for (retries = 0; retries < LINK_WAIT_MAX_RETRIES; retries++) {
> -		if (cdns_pcie_link_up(pcie)) {
> -			dev_info(dev, "Link up\n");
> -			return 0;
> -		}
> -		usleep_range(LINK_WAIT_USLEEP_MIN, LINK_WAIT_USLEEP_MAX);
> -	}
> -
> -	return -ETIMEDOUT;
> -}

This piece looks like a pure move of cdns_pcie_host_wait_for_link()
with no other changes.  It would be nicer to split that to a separate
patch so it doesn't obscure what's really happening in this patch.

>  int cdns_pcie_host_setup(struct cdns_pcie_rc *rc)
>  {
>  	struct device *dev = rc->pcie.dev;
> @@ -458,8 +485,12 @@ int cdns_pcie_host_setup(struct cdns_pcie_rc *rc)
>  	}
>  
>  	ret = cdns_pcie_host_wait_for_link(pcie);
> -	if (ret)
> +	if (ret) {
>  		dev_dbg(dev, "PCIe link never came up\n");
> +	} else {
> +		if (rc->quirk_retrain_flag)
> +			cdns_pcie_retrain(pcie);
> +	}
>  
>  	for (bar = RP_BAR0; bar <= RP_NO_BAR; bar++)
>  		rc->avail_ib_bar[bar] = true;
> diff --git a/drivers/pci/controller/cadence/pcie-cadence.h b/drivers/pci/controller/cadence/pcie-cadence.h
> index 30eba6cafe2c..0f29128a5d0a 100644
> --- a/drivers/pci/controller/cadence/pcie-cadence.h
> +++ b/drivers/pci/controller/cadence/pcie-cadence.h
> @@ -119,7 +119,7 @@
>   * Root Port Registers (PCI configuration space for the root port function)
>   */
>  #define CDNS_PCIE_RP_BASE	0x00200000
> -
> +#define CDNS_PCIE_RP_CAP_OFFSET 0xc0
>  
>  /*
>   * Address Translation Registers
> @@ -291,6 +291,7 @@ struct cdns_pcie {
>   * @device_id: PCI device ID
>   * @avail_ib_bar: Satus of RP_BAR0, RP_BAR1 and	RP_NO_BAR if it's free or
>   *                available
> + * @quirk_retrain_flag: Retrain link as quirk for PCIe Gen2
>   */
>  struct cdns_pcie_rc {
>  	struct cdns_pcie	pcie;
> @@ -299,6 +300,7 @@ struct cdns_pcie_rc {
>  	u32			vendor_id;
>  	u32			device_id;
>  	bool			avail_ib_bar[CDNS_PCIE_RP_MAX_IB];
> +	bool			quirk_retrain_flag;
>  };
>  
>  /**
> @@ -414,6 +416,13 @@ static inline void cdns_pcie_rp_writew(struct cdns_pcie *pcie,
>  	cdns_pcie_write_sz(addr, 0x2, value);
>  }
>  
> +static inline u16 cdns_pcie_rp_readw(struct cdns_pcie *pcie, u32 reg)
> +{
> +	void __iomem *addr = pcie->reg_base + CDNS_PCIE_RP_BASE + reg;
> +
> +	return cdns_pcie_read_sz(addr, 0x2);
> +}
> +
>  /* Endpoint Function register access */
>  static inline void cdns_pcie_ep_fn_writeb(struct cdns_pcie *pcie, u8 fn,
>  					  u32 reg, u8 value)
> -- 
> 2.17.1
> 

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  parent reply	other threads:[~2020-12-16  0:08 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-12-15  7:00 [PATCH v5] PCI: cadence: Retrain Link to work around Gen2 training defect Kishon Vijay Abraham I
2020-12-15  7:00 ` Kishon Vijay Abraham I
2020-12-15 15:53 ` Rob Herring
2020-12-15 15:53   ` Rob Herring
2020-12-16 15:01   ` Kishon Vijay Abraham I
2020-12-16 15:01     ` Kishon Vijay Abraham I
2020-12-16 17:01     ` Rob Herring
2020-12-16 17:01       ` Rob Herring
2020-12-18 14:42       ` Kishon Vijay Abraham I
2020-12-18 14:42         ` Kishon Vijay Abraham I
2020-12-18 17:31         ` Rob Herring
2020-12-18 17:31           ` Rob Herring
2020-12-15 23:30 ` Bjorn Helgaas [this message]
2020-12-15 23:30   ` Bjorn Helgaas
2020-12-21  9:55   ` Athani Nadeem Ladkhan
2020-12-21  9:55     ` Athani Nadeem Ladkhan

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=20201215233028.GA336802@bjorn-Precision-5520 \
    --to=helgaas@kernel.org \
    --cc=bhelgaas@google.com \
    --cc=kishon@ti.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-omap@vger.kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=mparab@cadence.com \
    --cc=nadeem@cadence.com \
    --cc=pthombar@cadence.com \
    --cc=robh@kernel.org \
    --cc=sjakhade@cadence.com \
    --cc=tjoseph@cadence.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.