[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <168211049118.1749998.10567032742795047284.robh@kernel.org>
Date: Fri, 21 Apr 2023 15:54:51 -0500
From: Rob Herring <robh@...nel.org>
To: Jim Quinlan <jim2101024@...il.com>
Cc: linux-rpi-kernel@...ts.infradead.org,
Lorenzo Pieralisi <lorenzo.pieralisi@....com>,
Lorenzo Pieralisi <lpieralisi@...nel.org>,
Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
devicetree@...r.kernel.org, linux-kernel@...r.kernel.org,
Phil Elwell <phil@...pberrypi.com>, james.quinlan@...adcom.com,
Cyril Brulebois <kibi@...ian.org>,
Florian Fainelli <f.fainelli@...il.com>,
Nicolas Saenz Julienne <nsaenz@...nel.org>,
Krzysztof WilczyĆski <kw@...ux.com>,
linux-pci@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
Bjorn Helgaas <bhelgaas@...gle.com>,
bcm-kernel-feedback-list@...adcom.com
Subject: Re: [PATCH v3 1/3] dt-bindings: PCI: brcmstb:
brcm,{enable-l1ss,completion-timeout-us} props
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@...il.com>
> ---
> .../devicetree/bindings/pci/brcm,stb-pcie.yaml | 16 ++++++++++++++++
> 1 file changed, 16 insertions(+)
>
Reviewed-by: Rob Herring <robh@...nel.org>
Powered by blists - more mailing lists