On Fri, Aug 25, 2023 at 2: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 ] > > 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 > > > > > > > > > > > > > > > > -- > > > > > மணிவண்ணன் சதாசிவம் > > > >
Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature
