All of lore.kernel.org
 help / color / mirror / Atom feed
From: Bjorn Helgaas <helgaas@kernel.org>
To: ansuelsmth@gmail.com
Cc: 'Rob Herring' <robh+dt@kernel.org>,
	'Sham Muthayyan' <smuthayy@codeaurora.org>,
	'Rob Herring' <robh@kernel.org>, 'Andy Gross' <agross@kernel.org>,
	'Bjorn Andersson' <bjorn.andersson@linaro.org>,
	'Bjorn Helgaas' <bhelgaas@google.com>,
	'Mark Rutland' <mark.rutland@arm.com>,
	'Stanimir Varbanov' <svarbanov@mm-sol.com>,
	'Lorenzo Pieralisi' <lorenzo.pieralisi@arm.com>,
	'Andrew Murray' <amurray@thegoodpenguin.co.uk>,
	'Philipp Zabel' <p.zabel@pengutronix.de>,
	linux-arm-msm@vger.kernel.org, linux-pci@vger.kernel.org,
	devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
	Varadarajan Narayanan <varada@codeaurora.org>
Subject: Re: R: [PATCH v5 11/11] PCI: qcom: Add Force GEN1 support
Date: Tue, 2 Jun 2020 12:28:21 -0500	[thread overview]
Message-ID: <20200602172821.GA829015@bjorn-Precision-5520> (raw)
In-Reply-To: <001101d63900$4c7aae60$e5700b20$@gmail.com>

[+cc Varada]

On Tue, Jun 02, 2020 at 07:07:27PM +0200, ansuelsmth@gmail.com wrote:
> > On Tue, Jun 02, 2020 at 01:53:52PM +0200, Ansuel Smith wrote:
> > > From: Sham Muthayyan <smuthayy@codeaurora.org>
> > >
> > > Add Force GEN1 support needed in some ipq8064 board that needs to
> > limit
> > > some PCIe line to gen1 for some hardware limitation. This is set by the
> > > max-link-speed binding and needed by some soc based on ipq8064. (for
> > > example Netgear R7800 router)
> > >
> > > Signed-off-by: Sham Muthayyan <smuthayy@codeaurora.org>
> > > Signed-off-by: Ansuel Smith <ansuelsmth@gmail.com>
> > > Reviewed-by: Rob Herring <robh@kernel.org>
> > > ---
> > >  drivers/pci/controller/dwc/pcie-qcom.c | 13 +++++++++++++
> > >  1 file changed, 13 insertions(+)
> > >
> > > diff --git a/drivers/pci/controller/dwc/pcie-qcom.c
> > b/drivers/pci/controller/dwc/pcie-qcom.c
> > > index 259b627bf890..0ce15d53c46e 100644
> > > --- a/drivers/pci/controller/dwc/pcie-qcom.c
> > > +++ b/drivers/pci/controller/dwc/pcie-qcom.c
> > > @@ -27,6 +27,7 @@
> > >  #include <linux/slab.h>
> > >  #include <linux/types.h>
> > >
> > > +#include "../../pci.h"
> > >  #include "pcie-designware.h"
> > >
> > >  #define PCIE20_PARF_SYS_CTRL			0x00
> > > @@ -99,6 +100,8 @@
> > >  #define PCIE20_v3_PARF_SLV_ADDR_SPACE_SIZE	0x358
> > >  #define SLV_ADDR_SPACE_SZ			0x10000000
> > >
> > > +#define PCIE20_LNK_CONTROL2_LINK_STATUS2	0xa0
> > > +
> > >  #define DEVICE_TYPE_RC				0x4
> > >
> > >  #define QCOM_PCIE_2_1_0_MAX_SUPPLY	3
> > > @@ -195,6 +198,7 @@ struct qcom_pcie {
> > >  	struct phy *phy;
> > >  	struct gpio_desc *reset;
> > >  	const struct qcom_pcie_ops *ops;
> > > +	int gen;
> > >  };
> > >
> > >  #define to_qcom_pcie(x)		dev_get_drvdata((x)->dev)
> > > @@ -395,6 +399,11 @@ static int qcom_pcie_init_2_1_0(struct
> > qcom_pcie *pcie)
> > >  	/* wait for clock acquisition */
> > >  	usleep_range(1000, 1500);
> > >
> > > +	if (pcie->gen == 1) {
> > > +		val = readl(pci->dbi_base +
> > PCIE20_LNK_CONTROL2_LINK_STATUS2);
> > > +		val |= 1;
> > 
> > Is this the same bit that's visible in config space as
> > PCI_EXP_LNKSTA_CLS_2_5GB?  Why not use that #define?
> > 
> > There are a bunch of other #defines in this file that look like
> > redefinitions of standard things:
> > 
> >   #define PCIE20_COMMAND_STATUS                   0x04
> >     Looks like PCI_COMMAND
> > 
> >   #define CMD_BME_VAL                             0x4
> >     Looks like PCI_COMMAND_MASTER
> > 
> >   #define PCIE20_DEVICE_CONTROL2_STATUS2          0x98
> >     Looks like (PCIE20_CAP + PCI_EXP_DEVCTL2)
> > 
> >   #define PCIE_CAP_CPL_TIMEOUT_DISABLE            0x10
> >     Looks like PCI_EXP_DEVCTL2_COMP_TMOUT_DIS
> > 
> >   #define PCIE20_CAP                              0x70
> >     This one is obviously device-specific
> > 
> >   #define PCIE20_CAP_LINK_CAPABILITIES            (PCIE20_CAP + 0xC)
> >     Looks like (PCIE20_CAP + PCI_EXP_LNKCAP)
> > 
> >   #define PCIE20_CAP_ACTIVE_STATE_LINK_PM_SUPPORT (BIT(10) |
> > BIT(11))
> >     Looks like PCI_EXP_LNKCAP_ASPMS
> > 
> >   #define PCIE20_CAP_LINK_1                       (PCIE20_CAP + 0x14)
> >   #define PCIE_CAP_LINK1_VAL                      0x2FD7F
> >     This looks like PCIE20_CAP_LINK_1 should be (PCIE20_CAP +
> >     PCI_EXP_SLTCAP), but "CAP_LINK_1" doesn't sound like the Slot
> >     Capabilities register, and I don't know what PCIE_CAP_LINK1_VAL
> >     means.
> 
> The define are used by ipq8074 and I really can't test the changes.
> Anyway it shouldn't make a difference use the define instead of the
> custom value so a patch should not harm anything... Problem is the
> last 2 define that we really don't know what they are about... How
> should I proceed? Change only the value related to
> PCI_EXP_LNKSTA_CLS_2_5GB or change all the other except the last 2?

I personally would change all the ones I mentioned above (in a
separate patch from the one that adds "max-link-speed" support).
Testing isn't a big deal because changing the #defines shouldn't
change the generated code at all.

PCIE20_CAP_LINK_1 / PCIE_CAP_LINK1_VAL looks like a potential bug or
at least a very misleading name.  I wouldn't touch it unless we can
figure out what's going on.

Looks like most of this was added by 5d76117f070d ("PCI: qcom: Add
support for IPQ8074 PCIe controller").  Shame on me for not asking
these questions at the time.

Sham, Varada, can you shed any light on PCIE20_CAP_LINK_1 and
PCIE_CAP_LINK1_VAL?

> > > +		writel(val, pci->dbi_base +
> > PCIE20_LNK_CONTROL2_LINK_STATUS2);
> > > +	}
> > >
> > >  	/* Set the Max TLP size to 2K, instead of using default of 4K */
> > >  	writel(CFG_REMOTE_RD_REQ_BRIDGE_SIZE_2K,
> > > @@ -1397,6 +1406,10 @@ static int qcom_pcie_probe(struct
> > platform_device *pdev)
> > >  		goto err_pm_runtime_put;
> > >  	}
> > >
> > > +	pcie->gen = of_pci_get_max_link_speed(pdev->dev.of_node);
> > > +	if (pcie->gen < 0)
> > > +		pcie->gen = 2;
> > > +
> > >  	res = platform_get_resource_byname(pdev, IORESOURCE_MEM,
> > "parf");
> > >  	pcie->parf = devm_ioremap_resource(dev, res);
> > >  	if (IS_ERR(pcie->parf)) {
> > > --
> > > 2.25.1
> > >
> 

  reply	other threads:[~2020-06-02 17:28 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-06-02 11:53 [PATCH v5 00/11] Multiple fixes in PCIe qcom driver Ansuel Smith
2020-06-02 11:53 ` [PATCH v5 01/11] PCI: qcom: Add missing ipq806x clocks in PCIe driver Ansuel Smith
2020-06-02 11:53 ` [PATCH v5 02/11] dt-bindings: PCI: qcom: Add missing clks Ansuel Smith
2020-06-02 11:53 ` [PATCH v5 03/11] PCI: qcom: Change duplicate PCI reset to phy reset Ansuel Smith
2020-06-02 11:53 ` [PATCH v5 04/11] PCI: qcom: Add missing reset for ipq806x Ansuel Smith
2020-06-02 11:53 ` [PATCH v5 05/11] dt-bindings: PCI: qcom: Add ext reset Ansuel Smith
2020-06-02 11:53 ` [PATCH v5 06/11] PCI: qcom: Use bulk clk api and assert on error Ansuel Smith
2020-06-02 11:53 ` [PATCH v5 07/11] PCI: qcom: Define some PARF params needed for ipq8064 SoC Ansuel Smith
2020-06-05 14:10   ` Sasha Levin
2020-06-06 16:30   ` Stanimir Varbanov
2020-06-02 11:53 ` [PATCH v5 08/11] PCI: qcom: Add support for tx term offset for rev 2.1.0 Ansuel Smith
2020-06-02 11:53 ` [PATCH v5 09/11] PCI: qcom: Add ipq8064 rev2 variant Ansuel Smith
2020-06-02 11:53 ` [PATCH v5 10/11] dt-bindings: PCI: qcom: Add ipq8064 rev 2 variant Ansuel Smith
2020-06-02 11:53 ` [PATCH v5 11/11] PCI: qcom: Add Force GEN1 support Ansuel Smith
2020-06-02 16:32   ` Bjorn Helgaas
2020-06-02 17:07     ` R: " ansuelsmth
2020-06-02 17:28       ` Bjorn Helgaas [this message]
2020-06-09 14:48         ` R: " ansuelsmth
2020-06-09 16:41           ` Bjorn Helgaas

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=20200602172821.GA829015@bjorn-Precision-5520 \
    --to=helgaas@kernel.org \
    --cc=agross@kernel.org \
    --cc=amurray@thegoodpenguin.co.uk \
    --cc=ansuelsmth@gmail.com \
    --cc=bhelgaas@google.com \
    --cc=bjorn.andersson@linaro.org \
    --cc=devicetree@vger.kernel.org \
    --cc=linux-arm-msm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=lorenzo.pieralisi@arm.com \
    --cc=mark.rutland@arm.com \
    --cc=p.zabel@pengutronix.de \
    --cc=robh+dt@kernel.org \
    --cc=robh@kernel.org \
    --cc=smuthayy@codeaurora.org \
    --cc=svarbanov@mm-sol.com \
    --cc=varada@codeaurora.org \
    /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.