Message-ID: <CA+-6iNy+xbT+5MG8mYhJyCR1=+PFrA2eopgkc_KGEqAycGKFjQ@mail.gmail.com>
Date:   Fri, 25 Aug 2023 14:16:13 -0400
From:   Jim Quinlan <james.quinlan@...adcom.com>
To:     Manivannan Sadhasivam <mani@...nel.org>
Cc:     Jim Quinlan <jim2101024@...il.com>, linux-pci@...r.kernel.org,
        Nicolas Saenz Julienne <nsaenz@...nel.org>,
        Bjorn Helgaas <bhelgaas@...gle.com>,
        Lorenzo Pieralisi <lorenzo.pieralisi@....com>,
        Cyril Brulebois <kibi@...ian.org>,
        Phil Elwell <phil@...pberrypi.com>,
        bcm-kernel-feedback-list@...adcom.com,
        Florian Fainelli <f.fainelli@...il.com>,
        Lorenzo Pieralisi <lpieralisi@...nel.org>,
        Krzysztof Wilczyński <kw@...ux.com>,
        Rob Herring <robh@...nel.org>,
        Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
        Conor Dooley <conor+dt@...nel.org>,
        "moderated list:BROADCOM BCM2711/BCM2835 ARM ARCHITECTURE" 
        <linux-rpi-kernel@...ts.infradead.org>,
        "moderated list:BROADCOM BCM2711/BCM2835 ARM ARCHITECTURE" 
        <linux-arm-kernel@...ts.infradead.org>,
        "open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS" 
        <devicetree@...r.kernel.org>,
        open list <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v5 1/5] dt-bindings: PCI: brcmstb: Add brcm,enable-l1ss property

On Fri, Aug 25, 2023 at 2:45 AM Manivannan Sadhasivam <mani@...nel.org> wrote:
>
> On Thu, Aug 24, 2023 at 10:55:02AM -0400, Jim Quinlan wrote:
> > On Wed, Aug 23, 2023 at 2:17 PM Manivannan Sadhasivam <mani@...nel.org> wrote:
> > >
> > > On Wed, Aug 23, 2023 at 09:09:25AM -0400, Jim Quinlan wrote:
> > > > On Wed, Aug 23, 2023 at 3:43 AM Manivannan Sadhasivam <mani@...nel.org> wrote:
> > > > >
> > > > > On Mon, May 08, 2023 at 06:01:21PM -0400, Jim Quinlan wrote:
> > > > > > This commit adds the boolean "brcm,enable-l1ss" property:
> > > > > >
> > > > > >   The Broadcom STB/CM PCIe HW -- a core that is also used by RPi SOCs --
> > > > > >   requires the driver probe() to deliberately place the HW one of three
> > > > > >   CLKREQ# modes:
> > > > > >
> > > > > >   (a) CLKREQ# driven by the RC unconditionally
> > > > > >   (b) CLKREQ# driven by the EP for ASPM L0s, L1
> > > > > >   (c) Bidirectional CLKREQ#, as used for L1 Substates (L1SS).
> > > > > >
> > > > > >   The HW+driver can tell the difference between downstream devices that
> > > > > >   need (a) and (b), but does not know when to configure (c).  All devices
> > > > > >   should work fine when the driver chooses (a) or (b), but (c) may be
> > > > > >   desired to realize the extra power savings that L1SS offers.  So we
> > > > > >   introduce the boolean "brcm,enable-l1ss" property to inform the driver
> > > > > >   that (c) is desired.  Setting this property only makes sense when the
> > > > > >   downstream device is L1SS-capable and the OS is configured to activate
> > > > > >   this mode (e.g. policy==powersupersave).
> > > > > >
> > > > > >   This property is already present in the Raspian version of Linux, but the
> > > > > >   upstream driver implementation that follows adds more details and
> > > > > >   discerns between (a) and (b).
> > > > > >
> > > > > > Signed-off-by: Jim Quinlan <jim2101024@...il.com>
> > > > > > Reviewed-by: Rob Herring <robh@...nel.org>
> > > > > > ---
> > > > > >  Documentation/devicetree/bindings/pci/brcm,stb-pcie.yaml | 9 +++++++++
> > > > > >  1 file changed, 9 insertions(+)
> > > > > >
> > > > > > diff --git a/Documentation/devicetree/bindings/pci/brcm,stb-pcie.yaml b/Documentation/devicetree/bindings/pci/brcm,stb-pcie.yaml
> > > > > > index 7e15aae7d69e..8b61c2179608 100644
> > > > > > --- a/Documentation/devicetree/bindings/pci/brcm,stb-pcie.yaml
> > > > > > +++ b/Documentation/devicetree/bindings/pci/brcm,stb-pcie.yaml
> > > > > > @@ -64,6 +64,15 @@ properties:
> > > > > >
> > > > > >    aspm-no-l0s: true
> > > > > >
> > > > > > +  brcm,enable-l1ss:
> > > > > > +    description: Indicates that PCIe L1SS power savings
> > > > > > +      are desired, the downstream device is L1SS-capable, and the
> > > > > > +      OS has been configured to enable this mode.  For boards
> > > > > > +      using a mini-card connector, this mode may not meet the
> > > > > > +      TCRLon maximum time of 400ns, as specified in 3.2.5.2.2
> > > > > > +      of the PCI Express Mini CEM 2.0 specification.
> > > > >
> > > > > As Lorenzo said, this property doesn't belong in DT. DT is supposed to specify
> > > > > the hardware capability and not system/OS behavior.
> > > >
> > > > The "brcm,enable-l1ss" does NOT configure the OS behavior.
> > > > It sets or not a mode bit to enable l1SS HW, whether or not the OS is
> > > > configured for L1SS.
> > > > It compensates for a problem in the PCIe core: the HW is not capable
> > > > of dynamically
> > > > switching between ASPM modes powersave and superpowersave.  I am actively
> > > > advocating for our HW to change but that will take years.
> > > >
> > >
> > > Okay, then I would say that the property name and commit message were a bit
> > > misleading.
> > >
> > > I had briefly gone through the driver patch now. As per my understanding, you
> > > have 2 modes in hw:
> > >
> > > 1. Clock PM - Refclk will be turned off by the host if CLKREQ# is deasserted by
> > > the device (driving high) when the link is in L1.
> > >
> > > 2. L1SS - CLKREQ# will be used to decide L1SS entry and exit by the host.
> >
> > No, there are three, as enumerated in the commit message of
> > "PCI: brcmstb: Configure HW CLKREQ# mode appropriate for downstream device"
> >
>
> Yeah, another one is refclk always on.
>
> > >
> > > Till now the driver only supported Clock PM through mode (1) but for supporting
> > > L1SS you need to enable mode (2). And you are using this property to select mode
> > > (2) when the L1SS supported devices are connected to the slot. Also, by
> > > selecting this mode, you are loosing the benefit of mode (1) as both are not
> > > compatible.
> > >
> > > My suggestion would be to just drop mode (1) and use mode (2) in the driver as
> > > most of the recent devices should support L1SS (ofc there are exemptions).
> > The disadvantage of this, as stated by the PCIe core HW designer, was
> > that "doing so means
> > we cannot enable the Cock Power Management capability since it may run afoul of
> > the Tclron requirement."
> >
>
> Ok.
>
> > I will attempt to press him on exactly what configurations and form
> > factors would be
> > vulnerable to this -- he was so convinced that it was a danger that he
> > is against
> > making L1SS mode the default.
> >
>
> Hmm. After looking at this problem in detail, it looks to me that you can still
> use DT but not with the property you proposed. Since these are hardware modes,
> you can have a single DT property that specifies the mode that the driver can
> use to configure the hw. It is similar to "phy-mode" property we have for the
> network controllers.
>
> So you should have the property defined as below in binding:
>
> brcm,clkreq-mode:
>   $ref: /schemas/types.yaml#/definitions/uint32
>   enum: [ 0, 1, 2 ]
>
> Then create definition for each mode in "include/dt-bindings/pci/brcm,stb.h".
>
> #define BRCM_STB_CLKREQ_CLOCK_PM        0
> #define BRCM_STB_CLKREQ_L1SS            1
> #define BRCM_STB_CLKREQ_ON              2
>
> If the property is not specified, the driver should use "Clock PM" as the
> default mode as it was doing earlier.
>
> Also, I think you can get rid of other checks in the driver (like PCIEASPM
> Kconfig, clkreq_seen etc...) and solely rely on this property to set the mode.
>
> What do you think?

Hi Mani,

I'm all for it; in fact this is quite similar to  my original design.
But then I decided to be backwards
compatible with RaspianOS's "brcm,enable-l1ss".

I will go in this direction for V7 and the only remaining issue is
what the default mode should
be and I will try my best to get time with the HW designer to weigh
the pros and cons.

Regards,
Jim Quinlan
Broadcom STB/CM

>
>
> - Mani
>
> > >
> > > But moving that decision to DT still doesn't seem right to me as the hardware
> > > supports both modes and you are (ab)using DT to choose one or the other.
> >
> > May be true, but there does not appear to be a Linux upstream-acceptable
> > way of doing this on the command line either; please see my recent post
> > on why this is so.
> >
> > There will be cases where we want to override the default setting, either by
> > command line or DT, but you folks have to give me a viable path on
> > how to do this with it actually being accepted.
> >
> > Regards,
> > Jim Quinlan
> > Broadcom STB/CM
> >
> > >
> > > - Mani
> > >
> > > > If this flag specifies
> > > > > whether the PCIe controller supports L1SS or not, then it is fine but apparantly
> > > > > this specifies that all downstream devices are L1SS capable which you cannot
> > > > > guarantee unless you poke into their LNKCAP during runtime.
> > > > Not true at all.  This setting affects only RC and whatever device is
> > > > connected to its single downstream
> > > > port.
> > > >
> > > > >
> > > > > You should handle this in the driver itself.
> > > >
> > > > The driver has no way of knowing if the PCI subsystem is going from power_save
> > > > to power_supersave or vice-versa -- there is no notification chain for this.  So
> > > > what you say is not currently possible from the driver's perspective.
> > > >
> > > > Perhaps you would be happy if we changed it to "l1ss-support" in the
> > > > spirit of the
> > > > existing "clkreq-support" PCI parameter?
> > > >
> > > > Regards,
> > > > Jim Quinlan
> > > > Broadcom STB/CMi
> > > >
> > > > >
> > > > > - Mani
> > > > >
> > > > > > +    type: boolean
> > > > > > +
> > > > > >    brcm,scb-sizes:
> > > > > >      description: u64 giving the 64bit PCIe memory
> > > > > >        viewport size of a memory controller.  There may be up to
> > > > > > --
> > > > > > 2.17.1
> > > > > >
> > > > >
> > > > > --
> > > > > மணிவண்ணன் சதாசிவம்
> > >
>

Download attachment "smime.p7s" of type "application/pkcs7-signature" (4210 bytes)

Powered by blists - more mailing lists