| Message ID | 20230419165721.29533-2-jim2101024@gmail.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | PCI: brcmstb: Configure appropriate HW CLKREQ# mode | expand |
On Wed, 19 Apr 2023 12:57:18 -0400, Jim Quinlan wrote: > This commit introduces two new properties: > > brcm,enable-l1ss (bool): > > 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==superpowersave). > > This property is already present in the Raspian version of Linux, but the > upstream driver implementaion that follows adds more details and discerns > between (a) and (b). > > brcm,completion-timeout-us (u32): > > Our HW will cause a CPU abort on any PCI transaction completion abort > error. It makes sense then to increase the timeout value for this type > of error in hopes that the response is merely delayed. Further, > L1SS-capable devices may have a long L1SS exit time and may require a > custom timeout value: we've been asked by our customers to make this > configurable for just this reason. > > Signed-off-by: Jim Quinlan <jim2101024@gmail.com> > --- > .../devicetree/bindings/pci/brcm,stb-pcie.yaml | 16 ++++++++++++++++ > 1 file changed, 16 insertions(+) > Reviewed-by: Rob Herring <robh@kernel.org>
diff --git a/Documentation/devicetree/bindings/pci/brcm,stb-pcie.yaml b/Documentation/devicetree/bindings/pci/brcm,stb-pcie.yaml index 7e15aae7d69e..239cc95545bd 100644 --- a/Documentation/devicetree/bindings/pci/brcm,stb-pcie.yaml +++ b/Documentation/devicetree/bindings/pci/brcm,stb-pcie.yaml @@ -64,6 +64,22 @@ 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.5 + of the PCI Express Mini CEM 2.0 specification. + type: boolean + + brcm,completion-timeout-us: + description: Number of microseconds before PCI transaction + completion timeout abort is signalled. + minimum: 16 + default: 1000000 + maximum: 19884107 + brcm,scb-sizes: description: u64 giving the 64bit PCIe memory viewport size of a memory controller. There may be up to
This commit introduces two new properties: brcm,enable-l1ss (bool): 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==superpowersave). This property is already present in the Raspian version of Linux, but the upstream driver implementaion that follows adds more details and discerns between (a) and (b). brcm,completion-timeout-us (u32): Our HW will cause a CPU abort on any PCI transaction completion abort error. It makes sense then to increase the timeout value for this type of error in hopes that the response is merely delayed. Further, L1SS-capable devices may have a long L1SS exit time and may require a custom timeout value: we've been asked by our customers to make this configurable for just this reason. Signed-off-by: Jim Quinlan <jim2101024@gmail.com> --- .../devicetree/bindings/pci/brcm,stb-pcie.yaml | 16 ++++++++++++++++ 1 file changed, 16 insertions(+)