On Fri, Aug 25, 2023 at 1:45 AM Manivannan Sadhasivam <mani@xxxxxxxxxx> 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@xxxxxxxxxx> 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@xxxxxxxxxx> 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@xxxxxxxxx> > > > > > > Reviewed-by: Rob Herring <robh@xxxxxxxxxx> > > > > > > --- > > > > > > 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 ] Is this really Broadcom specific? Rob
