[PATCH v5 1/5] dt-bindings: PCI: brcmstb: Add brcm,enable-l1ss property

Jim Quinlan james.quinlan at broadcom.com
Wed Aug 23 06:09:25 PDT 2023


On Wed, Aug 23, 2023 at 3:43 AM Manivannan Sadhasivam <mani at kernel.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 at gmail.com>
> > Reviewed-by: Rob Herring <robh at kernel.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.

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
> >
>
> --
> மணிவண்ணன் சதாசிவம்
-------------- next part --------------
An embedded message was scrubbed...
From: Florian Fainelli <messenger at webex.com>
Subject: Join me now in my Personal Room
Date: Tue, 22 Aug 2023 21:01:47 +0000 (UTC)
Size: 14769
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20230823/82a77a33/attachment-0001.eml>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4210 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20230823/82a77a33/attachment-0001.p7s>


More information about the linux-arm-kernel mailing list