linux-pci.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Rob Herring <robh@kernel.org>
To: Serge Semin <fancer.lancer@gmail.com>
Cc: "Serge Semin" <Sergey.Semin@baikalelectronics.ru>,
	"Bjorn Helgaas" <bhelgaas@google.com>,
	"Lorenzo Pieralisi" <lorenzo.pieralisi@arm.com>,
	"Jingoo Han" <jingoohan1@gmail.com>,
	"Gustavo Pimentel" <gustavo.pimentel@synopsys.com>,
	"Krzysztof Kozlowski" <krzysztof.kozlowski+dt@linaro.org>,
	"Alexey Malahov" <Alexey.Malahov@baikalelectronics.ru>,
	"Pavel Parkhomenko" <Pavel.Parkhomenko@baikalelectronics.ru>,
	"Krzysztof Wilczyński" <kw@linux.com>,
	"Frank Li" <Frank.Li@nxp.com>,
	"Manivannan Sadhasivam" <manivannan.sadhasivam@linaro.org>,
	linux-pci@vger.kernel.org, devicetree@vger.kernel.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH v3 04/17] dt-bindings: PCI: dwc: Add max-link-speed common property
Date: Fri, 1 Jul 2022 08:44:24 -0600	[thread overview]
Message-ID: <20220701144424.GA804716-robh@kernel.org> (raw)
In-Reply-To: <20220619142720.tzfgefunvf3kirul@mobilestation>

On Sun, Jun 19, 2022 at 05:27:20PM +0300, Serge Semin wrote:
> On Wed, Jun 15, 2022 at 08:55:50AM -0600, Rob Herring wrote:
> > On Fri, Jun 10, 2022 at 11:56:52AM +0300, Serge Semin wrote:
> > > In accordance with [1] DW PCIe controllers support up to Gen5 link speed.
> > > Let's add the max-link-speed property upper bound to 5 then. The DT
> > > bindings of the particular devices are expected to setup more strict
> > > constraint on that parameter.
> > > 
> > > [1] Synopsys DesignWare Cores PCI Express Controller Databook, Version
> > > 5.40a, March 2019, p. 27
> > > 
> > > Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru>
> > > 
> > > ---
> > > 
> > > Changelog v3:
> > > - This is a new patch unpinned from the next one:
> > >   https://lore.kernel.org/linux-pci/20220503214638.1895-2-Sergey.Semin@baikalelectronics.ru/
> > >   by the Rob' request. (@Rob)
> > > ---
> > >  Documentation/devicetree/bindings/pci/snps,dw-pcie-common.yaml | 3 +++
> > >  Documentation/devicetree/bindings/pci/snps,dw-pcie-ep.yaml     | 2 ++
> > >  Documentation/devicetree/bindings/pci/snps,dw-pcie.yaml        | 1 +
> > >  3 files changed, 6 insertions(+)
> > > 
> > > diff --git a/Documentation/devicetree/bindings/pci/snps,dw-pcie-common.yaml b/Documentation/devicetree/bindings/pci/snps,dw-pcie-common.yaml
> > > index 627a5d6625ba..b2fbe886981b 100644
> > > --- a/Documentation/devicetree/bindings/pci/snps,dw-pcie-common.yaml
> > > +++ b/Documentation/devicetree/bindings/pci/snps,dw-pcie-common.yaml
> > > @@ -45,6 +45,9 @@ properties:
> > >        the peripheral devices available on the PCIe bus.
> > >      maxItems: 1
> > >  
> > > +  max-link-speed:
> > > +    maximum: 5
> > 
> 
> > Unless the default is less than the max, shouldn't the max here be 1 
> > less than the h/w max?
> 
> Why? AFAIU max-link-speed semantics it works as less-than-or-equal
> operator isn't it? The modern DW PCIe Root ports and Endpoints
> IP-cores support up to Gen5 PCIe speed including the Gen5 mode (see
> the CX_MAX_PCIE_SPEED IP-core synthesize paramter). It's reasonable to
> set the max-link-speed here to be in coherency with the IP-core
> reference manual.

It is supposed to be an override for the default. Wouldn't the default 
always be the max the IP supports?

In any case, this max is only accurate for the current/latest version of 
the IP. For older versions, it's not an accurate limit. I think it 
should just be dropped and each controller needs to provide a limit.


> > >    num-lanes:
> > >      description:
> > >        Number of PCIe link lanes to use. Can be omitted should the already
> > > diff --git a/Documentation/devicetree/bindings/pci/snps,dw-pcie-ep.yaml b/Documentation/devicetree/bindings/pci/snps,dw-pcie-ep.yaml
> > > index dcd521aed213..fc3b5d4ac245 100644
> > > --- a/Documentation/devicetree/bindings/pci/snps,dw-pcie-ep.yaml
> > > +++ b/Documentation/devicetree/bindings/pci/snps,dw-pcie-ep.yaml
> > > @@ -55,4 +55,6 @@ examples:
> > >  
> > >        phys = <&pcie_phy0>, <&pcie_phy1>, <&pcie_phy2>, <&pcie_phy3>;
> > >        phy-names = "pcie0", "pcie1", "pcie2", "pcie3";
> > > +
> > > +      max-link-speed = <3>;
> > >      };
> > > diff --git a/Documentation/devicetree/bindings/pci/snps,dw-pcie.yaml b/Documentation/devicetree/bindings/pci/snps,dw-pcie.yaml
> > > index 4a5c8b933b52..01cedf51e0f8 100644
> > > --- a/Documentation/devicetree/bindings/pci/snps,dw-pcie.yaml
> > > +++ b/Documentation/devicetree/bindings/pci/snps,dw-pcie.yaml
> > > @@ -74,4 +74,5 @@ examples:
> > >        phy-names = "pcie";
> > >  
> > >        num-lanes = <1>;
> > > +      max-link-speed = <3>;
> > 
> 
> > This should give you an error because pci-bus.yaml only goes up to 4. 
> 
> I've set max-link-speed to "3" here. So no error will be caused neither
> by this schema nor by the pci-bus.yaml bindings.
> 
> * Though these examples won't be evaluated because the generic DW PCIe
> RP and EP schemas have been marked as "select: false".

Uh, I don't know what I was thinking...

> 
> > 
> > I'm not really sure that limiting it in the common schema is too useful. 
> > We're going to be updating it one step at a time. Limiting it is really 
> > only helpful for specific implementations.
> > 
> 
> I disagree. As I said above the max PCIe speed limit set here has been
> taken from the HW reference manual so it describes the modern DW PCIe
> controllers capability. No mater what value is set by the pci-bus.yaml
> schema (eventually we'll get to have it increased to Gen5 too) we can
> use the DW PCIe-specific limitation here as a known upper capabilities
> bound.

The latest DWC IP is likely going to support the latest gen within some 
amount of time. With each bump, we're going to have to update 
pci-bus.yaml and then this one too. Yet neither really has any impact 
if we provide a per controller limit.

Rob

  parent reply	other threads:[~2022-07-01 14:44 UTC|newest]

Thread overview: 51+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-06-10  8:56 [PATCH v3 00/17] PCI: dwc: Add generic resources and Baikal-T1 support Serge Semin
2022-06-10  8:56 ` [PATCH v3 01/17] dt-bindings: PCI: dwc: Detach common RP/EP DT bindings Serge Semin
2022-06-10  8:56 ` [PATCH v3 02/17] dt-bindings: PCI: dwc: Remove bus node from the examples Serge Semin
2022-06-15 16:30   ` Rob Herring
2022-06-10  8:56 ` [PATCH v3 03/17] dt-bindings: PCI: dwc: Add phys/phy-names common properties Serge Semin
2022-06-10  8:56 ` [PATCH v3 04/17] dt-bindings: PCI: dwc: Add max-link-speed common property Serge Semin
2022-06-15 14:55   ` Rob Herring
2022-06-19 14:27     ` Serge Semin
2022-06-28 12:15       ` Serge Semin
2022-06-28 14:56         ` Rob Herring
2022-06-29  1:50           ` Serge Semin
2022-07-01 14:44       ` Rob Herring [this message]
2022-07-07 19:02         ` Serge Semin
2022-06-10  8:56 ` [PATCH v3 05/17] dt-bindings: PCI: dwc: Stop selecting generic bindings by default Serge Semin
2022-06-10  8:56 ` [PATCH v3 06/17] dt-bindings: PCI: dwc: Add max-functions EP property Serge Semin
2022-06-15 16:31   ` Rob Herring
2022-06-10  8:56 ` [PATCH v3 07/17] dt-bindings: PCI: dwc: Add interrupts/interrupt-names common properties Serge Semin
2022-06-15 15:32   ` Rob Herring
2022-06-19 16:37     ` Serge Semin
2022-06-28 12:18       ` Serge Semin
2022-07-07 19:25       ` Serge Semin
2022-06-10  8:56 ` [PATCH v3 08/17] dt-bindings: PCI: dwc: Add reg/reg-names " Serge Semin
2022-06-10  8:56 ` [PATCH v3 09/17] dt-bindings: PCI: dwc: Add clocks/resets " Serge Semin
2022-06-10  8:56 ` [PATCH v3 10/17] dt-bindings: PCI: dwc: Add dma-coherent property Serge Semin
2022-06-10  8:56 ` [PATCH v3 11/17] dt-bindings: PCI: dwc: Apply common schema to Rockchip DW PCIe nodes Serge Semin
2022-06-10 13:12   ` Rob Herring
2022-06-10 21:13     ` Serge Semin
2022-06-10  8:57 ` [PATCH v3 12/17] dt-bindings: PCI: dwc: Add Baikal-T1 PCIe Root Port bindings Serge Semin
2022-06-15 16:37   ` Rob Herring
2022-06-19 20:03     ` Serge Semin
2022-06-28 12:19       ` Serge Semin
2022-07-01 14:59       ` Rob Herring
2022-07-07 19:19         ` Serge Semin
2022-06-10  8:57 ` [PATCH v3 13/17] PCI: dwc: Introduce generic controller capabilities interface Serge Semin
2022-06-15 16:42   ` Rob Herring
2022-06-10  8:57 ` [PATCH v3 14/17] PCI: dwc: Introduce generic resources getter Serge Semin
2022-06-15 16:46   ` Rob Herring
2022-06-10  8:57 ` [PATCH v3 15/17] PCI: dwc: Combine iATU detection procedures Serge Semin
2022-06-15 16:47   ` Rob Herring
2022-06-10  8:57 ` [PATCH v3 16/17] PCI: dwc: Introduce generic platform clocks and resets Serge Semin
2022-06-10  8:57 ` [PATCH v3 17/17] PCI: dwc: Add Baikal-T1 PCIe controller support Serge Semin
2022-06-15 16:48   ` Bjorn Helgaas
2022-06-20 17:13     ` Serge Semin
2022-06-21 18:29       ` Bjorn Helgaas
2022-06-22 17:04         ` Serge Semin
2022-06-28 12:23           ` Serge Semin
2022-06-28 15:17             ` Bjorn Helgaas
2022-06-15 17:10   ` Rob Herring
2022-06-19 20:39     ` Serge Semin
2022-07-12 20:29       ` Rob Herring
2022-07-12 20:58         ` Serge Semin

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=20220701144424.GA804716-robh@kernel.org \
    --to=robh@kernel.org \
    --cc=Alexey.Malahov@baikalelectronics.ru \
    --cc=Frank.Li@nxp.com \
    --cc=Pavel.Parkhomenko@baikalelectronics.ru \
    --cc=Sergey.Semin@baikalelectronics.ru \
    --cc=bhelgaas@google.com \
    --cc=devicetree@vger.kernel.org \
    --cc=fancer.lancer@gmail.com \
    --cc=gustavo.pimentel@synopsys.com \
    --cc=jingoohan1@gmail.com \
    --cc=krzysztof.kozlowski+dt@linaro.org \
    --cc=kw@linux.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=lorenzo.pieralisi@arm.com \
    --cc=manivannan.sadhasivam@linaro.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).