The current driver assumes the downstream devices can provide clkreq# for
ASPM. These commits accomodate devices w/ or w/o clkreq# and also handle
L1SS-capable devices.
The Raspian Linux folks have already been using a PCIe RC property
"brcm,enable-l1ss". These commits use the same property, in a
backward-compatible manner, and the implementaion adds more detail and also
automatically identifies devices w/o a clkreq# signal, i.e. most devices
plugged into an RPi CM4 IO board.
Jim Quinlan (3):
dt-bindings: PCI: brcmstb: Add two optional props
PCI: brcmstb: Clkreq# accomodations of downstream device
PCI: brcmstb: Allow setting the completion timeout
.../bindings/pci/brcm,stb-pcie.yaml | 12 +++
drivers/pci/controller/pcie-brcmstb.c | 93 +++++++++++++++++--
2 files changed, 95 insertions(+), 10 deletions(-)
base-commit: 99ddf2254febae9eab7fb0bcc02c5322243f5c49
--
2.17.1
The Broadcom STB/CM PCIe HW core, which is also used in RPi SOCs, may be
set into three mutually exclusive modes:
(a) No clkreq# expected or required, refclk is always available.
(b) Clkreq# is expected to be driven by downstream device when needed.
(c) Bidirectional clkreq# for L1SS capable devices.
Previously, only (b) was supported by the driver, as almost all STB boards
operate in this mode. But now there is interest in activating L1SS power
savings from STB customers, and also interest in accomodating mode (a) for
designs such as the RPi CM4 with IO board.
The HW can tell us when mode (a) mode is needed. But there is no easy way
to tell if L1SS mode is needed. Unfortunately, getting this wrong causes a
panic during boot time. So we rely on the DT prop "brcm,enable-l1ss" to
tell us when mode (c) is desired. This property has already been in
use by Raspian Linux, but this immplementation adds more details and
discerns between (a) and (b) automatically.
Link: https://bugzilla.kernel.org/show_bug.cgi?id=217276
Signed-off-by: Jim Quinlan <[email protected]>
---
drivers/pci/controller/pcie-brcmstb.c | 69 +++++++++++++++++++++++----
1 file changed, 59 insertions(+), 10 deletions(-)
diff --git a/drivers/pci/controller/pcie-brcmstb.c b/drivers/pci/controller/pcie-brcmstb.c
index edf283e2b5dd..129eee7bdbc1 100644
--- a/drivers/pci/controller/pcie-brcmstb.c
+++ b/drivers/pci/controller/pcie-brcmstb.c
@@ -48,10 +48,17 @@
#define PCIE_RC_CFG_PRIV1_LINK_CAPABILITY 0x04dc
#define PCIE_RC_CFG_PRIV1_LINK_CAPABILITY_ASPM_SUPPORT_MASK 0xc00
+#define PCIE_RC_CFG_PRIV1_ROOT_CAP 0x4f8
+#define PCIE_RC_CFG_PRIV1_ROOT_CAP_L1SS_MODE_MASK 0xf8
+
#define PCIE_RC_DL_MDIO_ADDR 0x1100
#define PCIE_RC_DL_MDIO_WR_DATA 0x1104
#define PCIE_RC_DL_MDIO_RD_DATA 0x1108
+#define PCIE_0_RC_PL_PHY_DBG_CLKREQ2_0 0x1e30
+#define CLKREQ2_0_CLKREQ_IN_CNT_MASK 0x3f000000
+#define CLKREQ2_0_CLKREQ_IN_MASK 0x40000000
+
#define PCIE_MISC_MISC_CTRL 0x4008
#define PCIE_MISC_MISC_CTRL_PCIE_RCB_64B_MODE_MASK 0x80
#define PCIE_MISC_MISC_CTRL_PCIE_RCB_MPS_MODE_MASK 0x400
@@ -121,9 +128,12 @@
#define PCIE_MISC_HARD_PCIE_HARD_DEBUG 0x4204
#define PCIE_MISC_HARD_PCIE_HARD_DEBUG_CLKREQ_DEBUG_ENABLE_MASK 0x2
+#define PCIE_MISC_HARD_PCIE_HARD_DEBUG_L1SS_ENABLE_MASK 0x200000
#define PCIE_MISC_HARD_PCIE_HARD_DEBUG_SERDES_IDDQ_MASK 0x08000000
#define PCIE_BMIPS_MISC_HARD_PCIE_HARD_DEBUG_SERDES_IDDQ_MASK 0x00800000
-
+#define PCIE_CLKREQ_MASK \
+ (PCIE_MISC_HARD_PCIE_HARD_DEBUG_CLKREQ_DEBUG_ENABLE_MASK | \
+ PCIE_MISC_HARD_PCIE_HARD_DEBUG_L1SS_ENABLE_MASK)
#define PCIE_INTR2_CPU_BASE 0x4300
#define PCIE_MSI_INTR2_BASE 0x4500
@@ -1024,13 +1034,58 @@ static int brcm_pcie_setup(struct brcm_pcie *pcie)
return 0;
}
+static void brcm_config_clkreq(struct brcm_pcie *pcie)
+{
+ bool l1ss = of_property_read_bool(pcie->np, "brcm,enable-l1ss");
+ void __iomem *base = pcie->base;
+ u32 clkreq_set, tmp = readl(base + PCIE_0_RC_PL_PHY_DBG_CLKREQ2_0);
+ bool clkreq_in_seen;
+
+ /*
+ * We have "seen" clkreq# if it is asserted or has been in the past.
+ * Note that the CLKREQ_IN_MASK is 1 if clkreq# is asserted.
+ */
+ clkreq_in_seen = !!(tmp & CLKREQ2_0_CLKREQ_IN_MASK) ||
+ !!FIELD_GET(CLKREQ2_0_CLKREQ_IN_CNT_MASK, tmp);
+
+ /* Start with safest setting where we provide refclk regardless */
+ clkreq_set = readl(pcie->base + PCIE_MISC_HARD_PCIE_HARD_DEBUG) &
+ ~PCIE_CLKREQ_MASK;
+
+ if (l1ss && IS_ENABLED(CONFIG_PCIEASPM)) {
+ /*
+ * Note: This (l1ss) mode may not meet requirement for
+ * Endpoints that require CLKREQ# assertion to clock active
+ * within 400ns.
+ */
+ clkreq_set |= PCIE_MISC_HARD_PCIE_HARD_DEBUG_L1SS_ENABLE_MASK;
+ dev_info(pcie->dev, "bi-dir clkreq; l1ss-capable devs only\n");
+ dev_info(pcie->dev, "ASPM policy must be set to powersupersave\n");
+ } else {
+ if (clkreq_in_seen && IS_ENABLED(CONFIG_PCIEASPM)) {
+ clkreq_set |= PCIE_MISC_HARD_PCIE_HARD_DEBUG_CLKREQ_DEBUG_ENABLE_MASK;
+ dev_info(pcie->dev, "uni-dir clkreq for ASPM\n");
+ } else {
+ dev_info(pcie->dev, "clkreq ignored; no ASPM\n");
+ /* Might as well unadvertise ASPM */
+ tmp = readl(base + PCIE_RC_CFG_PRIV1_LINK_CAPABILITY) &
+ ~PCIE_RC_CFG_PRIV1_LINK_CAPABILITY_ASPM_SUPPORT_MASK;
+ writel(tmp, base + PCIE_RC_CFG_PRIV1_LINK_CAPABILITY);
+ }
+ /* Setting the field to 2 unadvertises L1SS support */
+ tmp = readl(base + PCIE_RC_CFG_PRIV1_ROOT_CAP);
+ u32p_replace_bits(&tmp, 2, PCIE_RC_CFG_PRIV1_ROOT_CAP_L1SS_MODE_MASK);
+ writel(tmp, base + PCIE_RC_CFG_PRIV1_ROOT_CAP);
+ }
+ writel(clkreq_set, pcie->base + PCIE_MISC_HARD_PCIE_HARD_DEBUG);
+}
+
static int brcm_pcie_start_link(struct brcm_pcie *pcie)
{
struct device *dev = pcie->dev;
void __iomem *base = pcie->base;
u16 nlw, cls, lnksta;
bool ssc_good = false;
- u32 tmp;
int ret, i;
/* Unassert the fundamental reset */
@@ -1055,6 +1110,8 @@ static int brcm_pcie_start_link(struct brcm_pcie *pcie)
return -ENODEV;
}
+ brcm_config_clkreq(pcie);
+
if (pcie->gen)
brcm_pcie_set_gen(pcie, pcie->gen);
@@ -1073,14 +1130,6 @@ static int brcm_pcie_start_link(struct brcm_pcie *pcie)
pci_speed_string(pcie_link_speed[cls]), nlw,
ssc_good ? "(SSC)" : "(!SSC)");
- /*
- * Refclk from RC should be gated with CLKREQ# input when ASPM L0s,L1
- * is enabled => setting the CLKREQ_DEBUG_ENABLE field to 1.
- */
- tmp = readl(base + PCIE_MISC_HARD_PCIE_HARD_DEBUG);
- tmp |= PCIE_MISC_HARD_PCIE_HARD_DEBUG_CLKREQ_DEBUG_ENABLE_MASK;
- writel(tmp, base + PCIE_MISC_HARD_PCIE_HARD_DEBUG);
-
return 0;
}
--
2.17.1
Regarding "brcm,enable-l1ss":
The Broadcom STB/CM PCIe HW -- which is also used by RPi SOCs -- requires
the driver probe to configure one of three clkreq# modes:
(a) clkreq# driven by the RC
(b) clkreq# driven by the EP for ASPM L0s, L1
(c) bidirectional clkreq#, as used for L1 Substates (L1SS).
The HW can tell the difference between (a) and (b), but does not know
when to configure (c). Further, the HW will cause a CPU abort on boot if
guesses wrong regarding the need for (c). So we introduce the boolean
"brcm,enable-l1ss" property to indicate that (c) is desired. This
property is already present in the Raspian version of Linux, but the
driver implementaion that will follow adds more details and discerns
between (a) and (b).
Regarding "brcm,completion-timeout-msecs"
Our HW will cause a CPU abort if the L1SS exit time is longer than the
completion abort timeout. We've been asked to make this configurable, so
we are introducing "brcm,completion-abort-msecs".
Signed-off-by: Jim Quinlan <[email protected]>
---
.../devicetree/bindings/pci/brcm,stb-pcie.yaml | 12 ++++++++++++
1 file changed, 12 insertions(+)
diff --git a/Documentation/devicetree/bindings/pci/brcm,stb-pcie.yaml b/Documentation/devicetree/bindings/pci/brcm,stb-pcie.yaml
index 7e15aae7d69e..ef4ccc05b258 100644
--- a/Documentation/devicetree/bindings/pci/brcm,stb-pcie.yaml
+++ b/Documentation/devicetree/bindings/pci/brcm,stb-pcie.yaml
@@ -64,6 +64,18 @@ properties:
aspm-no-l0s: true
+ brcm,enable-l1ss:
+ description: Indicates that the downstream device is L1SS
+ capable and L1SS is desired, e.g. by setting
+ CONFIG_PCIEASPM_POWER_SUPERSAVE=y. Note that CLKREQ#
+ assertion to clock active must be within 400ns.
+ type: boolean
+
+ brcm,completion-timeout-msecs:
+ description: Number of msecs before completion timeout
+ abort occurs.
+ $ref: /schemas/types.yaml#/definitions/uint32
+
brcm,scb-sizes:
description: u64 giving the 64bit PCIe memory
viewport size of a memory controller. There may be up to
--
2.17.1
Since the STB PCIe HW will cause a CPU abort on a completion timeout abort,
we might as well extend the timeout limit. Further, different devices and
systems may requires a larger or smaller amount for L1SS exit.
Signed-off-by: Jim Quinlan <[email protected]>
---
drivers/pci/controller/pcie-brcmstb.c | 24 ++++++++++++++++++++++++
1 file changed, 24 insertions(+)
diff --git a/drivers/pci/controller/pcie-brcmstb.c b/drivers/pci/controller/pcie-brcmstb.c
index 129eee7bdbc1..92d78f4dfaae 100644
--- a/drivers/pci/controller/pcie-brcmstb.c
+++ b/drivers/pci/controller/pcie-brcmstb.c
@@ -1080,6 +1080,29 @@ static void brcm_config_clkreq(struct brcm_pcie *pcie)
writel(clkreq_set, pcie->base + PCIE_MISC_HARD_PCIE_HARD_DEBUG);
}
+static void brcm_config_completion_timeout(struct brcm_pcie *pcie)
+{
+ /* TIMEOUT register is two registers before RGR1_SW_INIT_1 */
+ const unsigned int REG_OFFSET = PCIE_RGR1_SW_INIT_1(pcie) - 8;
+ u32 timeout, timeout_msec = 1000;
+ u64 tmp64;
+ int ret;
+
+ ret = of_property_read_u32(pcie->np, "brcm,completion-abort-msecs",
+ &timeout_msec);
+
+ if (ret && ret != -EINVAL)
+ dev_err(pcie->dev, "bad 'brcm,completion-abort-msecs' prop\n");
+
+ /* Each unit in timeout register is 1/216,000,000 seconds */
+ tmp64 = (u64)216000 * timeout_msec;
+
+ /* Clamp the requested value before writing it */
+ timeout = tmp64 > 0xffffffff ? 0xffffffff : tmp64;
+ timeout = timeout < 0xffff ? 0xffff : timeout;
+ writel(timeout, pcie->base + REG_OFFSET);
+}
+
static int brcm_pcie_start_link(struct brcm_pcie *pcie)
{
struct device *dev = pcie->dev;
@@ -1110,6 +1133,7 @@ static int brcm_pcie_start_link(struct brcm_pcie *pcie)
return -ENODEV;
}
+ brcm_config_completion_timeout(pcie);
brcm_config_clkreq(pcie);
if (pcie->gen)
--
2.17.1
Hi Jim,
Am 06.04.23 um 14:46 schrieb Jim Quinlan:
> Regarding "brcm,enable-l1ss":
>
> The Broadcom STB/CM PCIe HW -- which is also used by RPi SOCs -- requires
> the driver probe to configure one of three clkreq# modes:
>
> (a) clkreq# driven by the RC
> (b) clkreq# driven by the EP for ASPM L0s, L1
> (c) bidirectional clkreq#, as used for L1 Substates (L1SS).
>
> The HW can tell the difference between (a) and (b), but does not know
> when to configure (c). Further, the HW will cause a CPU abort on boot if
> guesses wrong regarding the need for (c). So we introduce the boolean
> "brcm,enable-l1ss" property to indicate that (c) is desired. This
> property is already present in the Raspian version of Linux, but the
> driver implementaion that will follow adds more details and discerns
> between (a) and (b).
>
> Regarding "brcm,completion-timeout-msecs"
>
> Our HW will cause a CPU abort if the L1SS exit time is longer than the
> completion abort timeout. We've been asked to make this configurable, so
> we are introducing "brcm,completion-abort-msecs".
>
> Signed-off-by: Jim Quinlan <[email protected]>
> ---
> .../devicetree/bindings/pci/brcm,stb-pcie.yaml | 12 ++++++++++++
> 1 file changed, 12 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/pci/brcm,stb-pcie.yaml b/Documentation/devicetree/bindings/pci/brcm,stb-pcie.yaml
> index 7e15aae7d69e..ef4ccc05b258 100644
> --- a/Documentation/devicetree/bindings/pci/brcm,stb-pcie.yaml
> +++ b/Documentation/devicetree/bindings/pci/brcm,stb-pcie.yaml
> @@ -64,6 +64,18 @@ properties:
>
> aspm-no-l0s: true
>
> + brcm,enable-l1ss:
> + description: Indicates that the downstream device is L1SS
> + capable and L1SS is desired, e.g. by setting
> + CONFIG_PCIEASPM_POWER_SUPERSAVE=y. Note that CLKREQ#
not sure about this, but maybe we should avoid references to Linux
kernel config parameter in a DT binding. Since the driver already gaves
warning in case the DT parameter is present, but kernel config doesn't
fit, this should be enough.
> + assertion to clock active must be within 400ns.
> + type: boolean
> +
> + brcm,completion-timeout-msecs:
> + description: Number of msecs before completion timeout
> + abort occurs.
> + $ref: /schemas/types.yaml#/definitions/uint32
According to the driver at least 0 is not allowed, maybe we should
define minimum and maximum here and let dtbs_check take care of invalid
values?
Best regards
> +
> brcm,scb-sizes:
> description: u64 giving the 64bit PCIe memory
> viewport size of a memory controller. There may be up to
Hi Jim,
Am 06.04.23 um 14:46 schrieb Jim Quinlan:
> Since the STB PCIe HW will cause a CPU abort on a completion timeout abort,
> we might as well extend the timeout limit. Further, different devices and
> systems may requires a larger or smaller amount for L1SS exit.
>
> Signed-off-by: Jim Quinlan <[email protected]>
> ---
> drivers/pci/controller/pcie-brcmstb.c | 24 ++++++++++++++++++++++++
> 1 file changed, 24 insertions(+)
>
> diff --git a/drivers/pci/controller/pcie-brcmstb.c b/drivers/pci/controller/pcie-brcmstb.c
> index 129eee7bdbc1..92d78f4dfaae 100644
> --- a/drivers/pci/controller/pcie-brcmstb.c
> +++ b/drivers/pci/controller/pcie-brcmstb.c
> @@ -1080,6 +1080,29 @@ static void brcm_config_clkreq(struct brcm_pcie *pcie)
> writel(clkreq_set, pcie->base + PCIE_MISC_HARD_PCIE_HARD_DEBUG);
> }
>
> +static void brcm_config_completion_timeout(struct brcm_pcie *pcie)
> +{
> + /* TIMEOUT register is two registers before RGR1_SW_INIT_1 */
> + const unsigned int REG_OFFSET = PCIE_RGR1_SW_INIT_1(pcie) - 8;
> + u32 timeout, timeout_msec = 1000;
> + u64 tmp64;
> + int ret;
> +
> + ret = of_property_read_u32(pcie->np, "brcm,completion-abort-msecs",
> + &timeout_msec);
> +
> + if (ret && ret != -EINVAL)
> + dev_err(pcie->dev, "bad 'brcm,completion-abort-msecs' prop\n");
i'm not sure about the error behavior. If we want to proceed with
defaults in such a case, i would make this a warning and mention the
used defaults.
> +
> + /* Each unit in timeout register is 1/216,000,000 seconds */
> + tmp64 = (u64)216000 * timeout_msec;
> +
> + /* Clamp the requested value before writing it */
> + timeout = tmp64 > 0xffffffff ? 0xffffffff : tmp64;
> + timeout = timeout < 0xffff ? 0xffff : timeout;
Personally i'm not a huge fan of silently clamping wrong DT values.
Best regards
> + writel(timeout, pcie->base + REG_OFFSET);
> +}
> +
> static int brcm_pcie_start_link(struct brcm_pcie *pcie)
> {
> struct device *dev = pcie->dev;
> @@ -1110,6 +1133,7 @@ static int brcm_pcie_start_link(struct brcm_pcie *pcie)
> return -ENODEV;
> }
>
> + brcm_config_completion_timeout(pcie);
> brcm_config_clkreq(pcie);
>
> if (pcie->gen)
On Thu, Apr 6, 2023 at 11:39 AM Stefan Wahren <[email protected]> wrote:
>
> Hi Jim,
>
> Am 06.04.23 um 14:46 schrieb Jim Quinlan:
> > Regarding "brcm,enable-l1ss":
> >
> > The Broadcom STB/CM PCIe HW -- which is also used by RPi SOCs -- requires
> > the driver probe to configure one of three clkreq# modes:
> >
> > (a) clkreq# driven by the RC
> > (b) clkreq# driven by the EP for ASPM L0s, L1
> > (c) bidirectional clkreq#, as used for L1 Substates (L1SS).
> >
> > The HW can tell the difference between (a) and (b), but does not know
> > when to configure (c). Further, the HW will cause a CPU abort on boot if
> > guesses wrong regarding the need for (c). So we introduce the boolean
> > "brcm,enable-l1ss" property to indicate that (c) is desired. This
> > property is already present in the Raspian version of Linux, but the
> > driver implementaion that will follow adds more details and discerns
> > between (a) and (b).
> >
> > Regarding "brcm,completion-timeout-msecs"
> >
> > Our HW will cause a CPU abort if the L1SS exit time is longer than the
> > completion abort timeout. We've been asked to make this configurable, so
> > we are introducing "brcm,completion-abort-msecs".
> >
> > Signed-off-by: Jim Quinlan <[email protected]>
> > ---
> > .../devicetree/bindings/pci/brcm,stb-pcie.yaml | 12 ++++++++++++
> > 1 file changed, 12 insertions(+)
> >
> > diff --git a/Documentation/devicetree/bindings/pci/brcm,stb-pcie.yaml b/Documentation/devicetree/bindings/pci/brcm,stb-pcie.yaml
> > index 7e15aae7d69e..ef4ccc05b258 100644
> > --- a/Documentation/devicetree/bindings/pci/brcm,stb-pcie.yaml
> > +++ b/Documentation/devicetree/bindings/pci/brcm,stb-pcie.yaml
> > @@ -64,6 +64,18 @@ properties:
> >
> > aspm-no-l0s: true
> >
> > + brcm,enable-l1ss:
> > + description: Indicates that the downstream device is L1SS
> > + capable and L1SS is desired, e.g. by setting
> > + CONFIG_PCIEASPM_POWER_SUPERSAVE=y. Note that CLKREQ#
>
> not sure about this, but maybe we should avoid references to Linux
> kernel config parameter in a DT binding. Since the driver already gaves
> warning in case the DT parameter is present, but kernel config doesn't
> fit, this should be enough.
Hello Stefan,
I will remove this reference.
>
> > + assertion to clock active must be within 400ns.
> > + type: boolean
> > +
> > + brcm,completion-timeout-msecs:
> > + description: Number of msecs before completion timeout
> > + abort occurs.
> > + $ref: /schemas/types.yaml#/definitions/uint32
>
> According to the driver at least 0 is not allowed, maybe we should
> define minimum and maximum here and let dtbs_check take care of invalid
> values?
I'm not sure I follow what you mean about a zero value; the property
may have any value but the driver will clamp it
to a minimum of ~30msec. Regardless, I can add a "minimum: 30" line
to the YAML.
Thanks,
Jim Quinlan
Broadcom STB
>
> Best regards
>
> > +
> > brcm,scb-sizes:
> > description: u64 giving the 64bit PCIe memory
> > viewport size of a memory controller. There may be up to
On Thu, Apr 6, 2023 at 11:59 AM Stefan Wahren <[email protected]> wrote:
>
> Hi Jim,
>
> Am 06.04.23 um 14:46 schrieb Jim Quinlan:
> > Since the STB PCIe HW will cause a CPU abort on a completion timeout abort,
> > we might as well extend the timeout limit. Further, different devices and
> > systems may requires a larger or smaller amount for L1SS exit.
> >
> > Signed-off-by: Jim Quinlan <[email protected]>
> > ---
> > drivers/pci/controller/pcie-brcmstb.c | 24 ++++++++++++++++++++++++
> > 1 file changed, 24 insertions(+)
> >
> > diff --git a/drivers/pci/controller/pcie-brcmstb.c b/drivers/pci/controller/pcie-brcmstb.c
> > index 129eee7bdbc1..92d78f4dfaae 100644
> > --- a/drivers/pci/controller/pcie-brcmstb.c
> > +++ b/drivers/pci/controller/pcie-brcmstb.c
> > @@ -1080,6 +1080,29 @@ static void brcm_config_clkreq(struct brcm_pcie *pcie)
> > writel(clkreq_set, pcie->base + PCIE_MISC_HARD_PCIE_HARD_DEBUG);
> > }
> >
> > +static void brcm_config_completion_timeout(struct brcm_pcie *pcie)
> > +{
> > + /* TIMEOUT register is two registers before RGR1_SW_INIT_1 */
> > + const unsigned int REG_OFFSET = PCIE_RGR1_SW_INIT_1(pcie) - 8;
> > + u32 timeout, timeout_msec = 1000;
> > + u64 tmp64;
> > + int ret;
> > +
> > + ret = of_property_read_u32(pcie->np, "brcm,completion-abort-msecs",
> > + &timeout_msec);
> > +
> > + if (ret && ret != -EINVAL)
> > + dev_err(pcie->dev, "bad 'brcm,completion-abort-msecs' prop\n");
>
> i'm not sure about the error behavior. If we want to proceed with
> defaults in such a case, i would make this a warning and mention the
> used defaults.
Will do.
>
> > +
> > + /* Each unit in timeout register is 1/216,000,000 seconds */
> > + tmp64 = (u64)216000 * timeout_msec;
> > +
> > + /* Clamp the requested value before writing it */
> > + timeout = tmp64 > 0xffffffff ? 0xffffffff : tmp64;
> > + timeout = timeout < 0xffff ? 0xffff : timeout;
>
> Personally i'm not a huge fan of silently clamping wrong DT values.
I will add a warning with limit info on clamp and have the YAML min+max.
Thanks
Jim Quinlan
Broadcom STB
>
> Best regards
>
> > + writel(timeout, pcie->base + REG_OFFSET);
> > +}
> > +
> > static int brcm_pcie_start_link(struct brcm_pcie *pcie)
> > {
> > struct device *dev = pcie->dev;
> > @@ -1110,6 +1133,7 @@ static int brcm_pcie_start_link(struct brcm_pcie *pcie)
> > return -ENODEV;
> > }
> >
> > + brcm_config_completion_timeout(pcie);
> > brcm_config_clkreq(pcie);
> >
> > if (pcie->gen)
On 06/04/2023 14:46, Jim Quinlan wrote:
> Regarding "brcm,enable-l1ss":
>
> The Broadcom STB/CM PCIe HW -- which is also used by RPi SOCs -- requires
> the driver probe to configure one of three clkreq# modes:
>
> (a) clkreq# driven by the RC
> (b) clkreq# driven by the EP for ASPM L0s, L1
> (c) bidirectional clkreq#, as used for L1 Substates (L1SS).
>
> The HW can tell the difference between (a) and (b), but does not know
> when to configure (c). Further, the HW will cause a CPU abort on boot if
> guesses wrong regarding the need for (c). So we introduce the boolean
> "brcm,enable-l1ss" property to indicate that (c) is desired. This
> property is already present in the Raspian version of Linux, but the
> driver implementaion that will follow adds more details and discerns
> between (a) and (b).
>
> Regarding "brcm,completion-timeout-msecs"
>
> Our HW will cause a CPU abort if the L1SS exit time is longer than the
> completion abort timeout. We've been asked to make this configurable, so
> we are introducing "brcm,completion-abort-msecs".
>
> Signed-off-by: Jim Quinlan <[email protected]>
> ---
> .../devicetree/bindings/pci/brcm,stb-pcie.yaml | 12 ++++++++++++
> 1 file changed, 12 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/pci/brcm,stb-pcie.yaml b/Documentation/devicetree/bindings/pci/brcm,stb-pcie.yaml
> index 7e15aae7d69e..ef4ccc05b258 100644
> --- a/Documentation/devicetree/bindings/pci/brcm,stb-pcie.yaml
> +++ b/Documentation/devicetree/bindings/pci/brcm,stb-pcie.yaml
> @@ -64,6 +64,18 @@ properties:
>
> aspm-no-l0s: true
>
> + brcm,enable-l1ss:
> + description: Indicates that the downstream device is L1SS
> + capable and L1SS is desired, e.g. by setting
> + CONFIG_PCIEASPM_POWER_SUPERSAVE=y. Note that CLKREQ#
How does CONFIG_PCIEASPM_POWER_SUPERSAVE apply to *BSD?
> + assertion to clock active must be within 400ns.
> + type: boolean
> +
> + brcm,completion-timeout-msecs:
Use standard unit suffixes.
> + description: Number of msecs before completion timeout
> + abort occurs.
> + $ref: /schemas/types.yaml#/definitions/uint32
> +
> brcm,scb-sizes:
> description: u64 giving the 64bit PCIe memory
> viewport size of a memory controller. There may be up to
Best regards,
Krzysztof
On 06/04/2023 18:58, Jim Quinlan wrote:
> On Thu, Apr 6, 2023 at 11:39 AM Stefan Wahren <[email protected]> wrote:
>>
>> Hi Jim,
>>
>> Am 06.04.23 um 14:46 schrieb Jim Quinlan:
>>> Regarding "brcm,enable-l1ss":
>>>
>>> The Broadcom STB/CM PCIe HW -- which is also used by RPi SOCs -- requires
>>> the driver probe to configure one of three clkreq# modes:
>>>
>>> (a) clkreq# driven by the RC
>>> (b) clkreq# driven by the EP for ASPM L0s, L1
>>> (c) bidirectional clkreq#, as used for L1 Substates (L1SS).
>>>
>>> The HW can tell the difference between (a) and (b), but does not know
>>> when to configure (c). Further, the HW will cause a CPU abort on boot if
>>> guesses wrong regarding the need for (c). So we introduce the boolean
>>> "brcm,enable-l1ss" property to indicate that (c) is desired. This
>>> property is already present in the Raspian version of Linux, but the
>>> driver implementaion that will follow adds more details and discerns
>>> between (a) and (b).
>>>
>>> Regarding "brcm,completion-timeout-msecs"
>>>
>>> Our HW will cause a CPU abort if the L1SS exit time is longer than the
>>> completion abort timeout. We've been asked to make this configurable, so
>>> we are introducing "brcm,completion-abort-msecs".
>>>
>>> Signed-off-by: Jim Quinlan <[email protected]>
>>> ---
>>> .../devicetree/bindings/pci/brcm,stb-pcie.yaml | 12 ++++++++++++
>>> 1 file changed, 12 insertions(+)
>>>
>>> diff --git a/Documentation/devicetree/bindings/pci/brcm,stb-pcie.yaml b/Documentation/devicetree/bindings/pci/brcm,stb-pcie.yaml
>>> index 7e15aae7d69e..ef4ccc05b258 100644
>>> --- a/Documentation/devicetree/bindings/pci/brcm,stb-pcie.yaml
>>> +++ b/Documentation/devicetree/bindings/pci/brcm,stb-pcie.yaml
>>> @@ -64,6 +64,18 @@ properties:
>>>
>>> aspm-no-l0s: true
>>>
>>> + brcm,enable-l1ss:
>>> + description: Indicates that the downstream device is L1SS
>>> + capable and L1SS is desired, e.g. by setting
>>> + CONFIG_PCIEASPM_POWER_SUPERSAVE=y. Note that CLKREQ#
>>
>> not sure about this, but maybe we should avoid references to Linux
>> kernel config parameter in a DT binding. Since the driver already gaves
>> warning in case the DT parameter is present, but kernel config doesn't
>> fit, this should be enough.
>
> Hello Stefan,
> I will remove this reference.
>>
>>> + assertion to clock active must be within 400ns.
>>> + type: boolean
>>> +
>>> + brcm,completion-timeout-msecs:
>>> + description: Number of msecs before completion timeout
>>> + abort occurs.
>>> + $ref: /schemas/types.yaml#/definitions/uint32
>>
>> According to the driver at least 0 is not allowed, maybe we should
>> define minimum and maximum here and let dtbs_check take care of invalid
>> values?
> I'm not sure I follow what you mean about a zero value; the property
> may have any value but the driver will clamp it
> to a minimum of ~30msec. Regardless, I can add a "minimum: 30" line
> to the YAML.
If "completion" means Linux completion, then it is not suitable for DT
and entire property should be removed. If it is something else, then
explain here and commit msg. So far both refer to some completion...
Best regards,
Krzysztof
On 4/6/23 11:35, Krzysztof Kozlowski wrote:
> On 06/04/2023 18:58, Jim Quinlan wrote:
>> On Thu, Apr 6, 2023 at 11:39 AM Stefan Wahren <[email protected]> wrote:
>>>
>>> Hi Jim,
>>>
>>> Am 06.04.23 um 14:46 schrieb Jim Quinlan:
>>>> Regarding "brcm,enable-l1ss":
>>>>
>>>> The Broadcom STB/CM PCIe HW -- which is also used by RPi SOCs -- requires
>>>> the driver probe to configure one of three clkreq# modes:
>>>>
>>>> (a) clkreq# driven by the RC
>>>> (b) clkreq# driven by the EP for ASPM L0s, L1
>>>> (c) bidirectional clkreq#, as used for L1 Substates (L1SS).
>>>>
>>>> The HW can tell the difference between (a) and (b), but does not know
>>>> when to configure (c). Further, the HW will cause a CPU abort on boot if
>>>> guesses wrong regarding the need for (c). So we introduce the boolean
>>>> "brcm,enable-l1ss" property to indicate that (c) is desired. This
>>>> property is already present in the Raspian version of Linux, but the
>>>> driver implementaion that will follow adds more details and discerns
>>>> between (a) and (b).
>>>>
>>>> Regarding "brcm,completion-timeout-msecs"
>>>>
>>>> Our HW will cause a CPU abort if the L1SS exit time is longer than the
>>>> completion abort timeout. We've been asked to make this configurable, so
>>>> we are introducing "brcm,completion-abort-msecs".
>>>>
>>>> Signed-off-by: Jim Quinlan <[email protected]>
>>>> ---
>>>> .../devicetree/bindings/pci/brcm,stb-pcie.yaml | 12 ++++++++++++
>>>> 1 file changed, 12 insertions(+)
>>>>
>>>> diff --git a/Documentation/devicetree/bindings/pci/brcm,stb-pcie.yaml b/Documentation/devicetree/bindings/pci/brcm,stb-pcie.yaml
>>>> index 7e15aae7d69e..ef4ccc05b258 100644
>>>> --- a/Documentation/devicetree/bindings/pci/brcm,stb-pcie.yaml
>>>> +++ b/Documentation/devicetree/bindings/pci/brcm,stb-pcie.yaml
>>>> @@ -64,6 +64,18 @@ properties:
>>>>
>>>> aspm-no-l0s: true
>>>>
>>>> + brcm,enable-l1ss:
>>>> + description: Indicates that the downstream device is L1SS
>>>> + capable and L1SS is desired, e.g. by setting
>>>> + CONFIG_PCIEASPM_POWER_SUPERSAVE=y. Note that CLKREQ#
>>>
>>> not sure about this, but maybe we should avoid references to Linux
>>> kernel config parameter in a DT binding. Since the driver already gaves
>>> warning in case the DT parameter is present, but kernel config doesn't
>>> fit, this should be enough.
>>
>> Hello Stefan,
>> I will remove this reference.
>>>
>>>> + assertion to clock active must be within 400ns.
>>>> + type: boolean
>>>> +
>>>> + brcm,completion-timeout-msecs:
>>>> + description: Number of msecs before completion timeout
>>>> + abort occurs.
>>>> + $ref: /schemas/types.yaml#/definitions/uint32
>>>
>>> According to the driver at least 0 is not allowed, maybe we should
>>> define minimum and maximum here and let dtbs_check take care of invalid
>>> values?
>> I'm not sure I follow what you mean about a zero value; the property
>> may have any value but the driver will clamp it
>> to a minimum of ~30msec. Regardless, I can add a "minimum: 30" line
>> to the YAML.
>
> If "completion" means Linux completion, then it is not suitable for DT
> and entire property should be removed. If it is something else, then
> explain here and commit msg. So far both refer to some completion...
This is a PCIe root complex binding so completion needs to be understood
in the context of PCIe, that is the time needed for the root complex to
complete/finish/proceed with a PCIe transaction layer packet (TLP).
--
Florian
On 4/6/23 11:34, Krzysztof Kozlowski wrote:
> On 06/04/2023 14:46, Jim Quinlan wrote:
>> Regarding "brcm,enable-l1ss":
>>
>> The Broadcom STB/CM PCIe HW -- which is also used by RPi SOCs -- requires
>> the driver probe to configure one of three clkreq# modes:
>>
>> (a) clkreq# driven by the RC
>> (b) clkreq# driven by the EP for ASPM L0s, L1
>> (c) bidirectional clkreq#, as used for L1 Substates (L1SS).
>>
>> The HW can tell the difference between (a) and (b), but does not know
>> when to configure (c). Further, the HW will cause a CPU abort on boot if
>> guesses wrong regarding the need for (c). So we introduce the boolean
>> "brcm,enable-l1ss" property to indicate that (c) is desired. This
>> property is already present in the Raspian version of Linux, but the
>> driver implementaion that will follow adds more details and discerns
>> between (a) and (b).
>>
>> Regarding "brcm,completion-timeout-msecs"
>>
>> Our HW will cause a CPU abort if the L1SS exit time is longer than the
>> completion abort timeout. We've been asked to make this configurable, so
>> we are introducing "brcm,completion-abort-msecs".
>>
>> Signed-off-by: Jim Quinlan <[email protected]>
>> ---
>> .../devicetree/bindings/pci/brcm,stb-pcie.yaml | 12 ++++++++++++
>> 1 file changed, 12 insertions(+)
>>
>> diff --git a/Documentation/devicetree/bindings/pci/brcm,stb-pcie.yaml b/Documentation/devicetree/bindings/pci/brcm,stb-pcie.yaml
>> index 7e15aae7d69e..ef4ccc05b258 100644
>> --- a/Documentation/devicetree/bindings/pci/brcm,stb-pcie.yaml
>> +++ b/Documentation/devicetree/bindings/pci/brcm,stb-pcie.yaml
>> @@ -64,6 +64,18 @@ properties:
>>
>> aspm-no-l0s: true
>>
>> + brcm,enable-l1ss:
>> + description: Indicates that the downstream device is L1SS
>> + capable and L1SS is desired, e.g. by setting
>> + CONFIG_PCIEASPM_POWER_SUPERSAVE=y. Note that CLKREQ#
>
> How does CONFIG_PCIEASPM_POWER_SUPERSAVE apply to *BSD?
In other words, there should be no OS/Linux specific comments in a
Device Tree binding, which would be a friendlier and nicer way of
providing the same feedback.
--
Florian
On 06/04/2023 20:47, Florian Fainelli wrote:
>>>>> +
>>>>> + brcm,completion-timeout-msecs:
>>>>> + description: Number of msecs before completion timeout
>>>>> + abort occurs.
>>>>> + $ref: /schemas/types.yaml#/definitions/uint32
>>>>
>>>> According to the driver at least 0 is not allowed, maybe we should
>>>> define minimum and maximum here and let dtbs_check take care of invalid
>>>> values?
>>> I'm not sure I follow what you mean about a zero value; the property
>>> may have any value but the driver will clamp it
>>> to a minimum of ~30msec. Regardless, I can add a "minimum: 30" line
>>> to the YAML.
>>
>> If "completion" means Linux completion, then it is not suitable for DT
>> and entire property should be removed. If it is something else, then
>> explain here and commit msg. So far both refer to some completion...
>
> This is a PCIe root complex binding so completion needs to be understood
> in the context of PCIe, that is the time needed for the root complex to
> complete/finish/proceed with a PCIe transaction layer packet (TLP).
OK, so I assume keyword "completion" is well known term in PCI (although
for some reason no other bindings mention it).
Best regards,
Krzysztof
On 06/04/2023 20:53, Florian Fainelli wrote:
> On 4/6/23 11:34, Krzysztof Kozlowski wrote:
>> On 06/04/2023 14:46, Jim Quinlan wrote:
>>> Regarding "brcm,enable-l1ss":
>>>
>>> The Broadcom STB/CM PCIe HW -- which is also used by RPi SOCs -- requires
>>> the driver probe to configure one of three clkreq# modes:
>>>
>>> (a) clkreq# driven by the RC
>>> (b) clkreq# driven by the EP for ASPM L0s, L1
>>> (c) bidirectional clkreq#, as used for L1 Substates (L1SS).
>>>
>>> The HW can tell the difference between (a) and (b), but does not know
>>> when to configure (c). Further, the HW will cause a CPU abort on boot if
>>> guesses wrong regarding the need for (c). So we introduce the boolean
>>> "brcm,enable-l1ss" property to indicate that (c) is desired. This
>>> property is already present in the Raspian version of Linux, but the
>>> driver implementaion that will follow adds more details and discerns
>>> between (a) and (b).
>>>
>>> Regarding "brcm,completion-timeout-msecs"
>>>
>>> Our HW will cause a CPU abort if the L1SS exit time is longer than the
>>> completion abort timeout. We've been asked to make this configurable, so
>>> we are introducing "brcm,completion-abort-msecs".
>>>
>>> Signed-off-by: Jim Quinlan <[email protected]>
>>> ---
>>> .../devicetree/bindings/pci/brcm,stb-pcie.yaml | 12 ++++++++++++
>>> 1 file changed, 12 insertions(+)
>>>
>>> diff --git a/Documentation/devicetree/bindings/pci/brcm,stb-pcie.yaml b/Documentation/devicetree/bindings/pci/brcm,stb-pcie.yaml
>>> index 7e15aae7d69e..ef4ccc05b258 100644
>>> --- a/Documentation/devicetree/bindings/pci/brcm,stb-pcie.yaml
>>> +++ b/Documentation/devicetree/bindings/pci/brcm,stb-pcie.yaml
>>> @@ -64,6 +64,18 @@ properties:
>>>
>>> aspm-no-l0s: true
>>>
>>> + brcm,enable-l1ss:
>>> + description: Indicates that the downstream device is L1SS
>>> + capable and L1SS is desired, e.g. by setting
>>> + CONFIG_PCIEASPM_POWER_SUPERSAVE=y. Note that CLKREQ#
>>
>> How does CONFIG_PCIEASPM_POWER_SUPERSAVE apply to *BSD?
>
> In other words, there should be no OS/Linux specific comments in a
> Device Tree binding, which would be a friendlier and nicer way of
> providing the same feedback.
I want to give also the answer also why there should be no OS/Linux
specific comments, so the reader can stop a bit and think about it :)
Best regards,
Krzysztof
On Thu, Apr 06, 2023 at 08:46:23AM -0400, Jim Quinlan wrote:
> The Broadcom STB/CM PCIe HW core, which is also used in RPi SOCs, may be
> set into three mutually exclusive modes:
>
> (a) No clkreq# expected or required, refclk is always available.
> (b) Clkreq# is expected to be driven by downstream device when needed.
> (c) Bidirectional clkreq# for L1SS capable devices.
>
> Previously, only (b) was supported by the driver, as almost all STB boards
> operate in this mode. But now there is interest in activating L1SS power
> savings from STB customers, and also interest in accomodating mode (a) for
> designs such as the RPi CM4 with IO board.
>
> The HW can tell us when mode (a) mode is needed. But there is no easy way
> to tell if L1SS mode is needed. Unfortunately, getting this wrong causes a
> panic during boot time. So we rely on the DT prop "brcm,enable-l1ss" to
> tell us when mode (c) is desired. This property has already been in
> use by Raspian Linux, but this immplementation adds more details and
> discerns between (a) and (b) automatically.
>
> Link: https://bugzilla.kernel.org/show_bug.cgi?id=217276
> Signed-off-by: Jim Quinlan <[email protected]>
> + * We have "seen" clkreq# if it is asserted or has been in the past.
> + * Note that the CLKREQ_IN_MASK is 1 if clkreq# is asserted.
"CLKREQ#" to match PCIe spec and comments below.
> + if (l1ss && IS_ENABLED(CONFIG_PCIEASPM)) {
> + /*
> + * Note: This (l1ss) mode may not meet requirement for
> + * Endpoints that require CLKREQ# assertion to clock active
> + * within 400ns.
> + */
> + clkreq_set |= PCIE_MISC_HARD_PCIE_HARD_DEBUG_L1SS_ENABLE_MASK;
> + dev_info(pcie->dev, "bi-dir clkreq; l1ss-capable devs only\n");
> + dev_info(pcie->dev, "ASPM policy must be set to powersupersave\n");
Seems problematic since L1SS can be enabled/disabled at run-time:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/ABI/testing/sysfs-bus-pci?id=v6.2#n420
The simplistic answer is to advertise L1SS support if and only if you
can safely support it.
I don't know why this is an issue for this device but not others. Is
it because there's some problem in the way the board is designed? Or
(after skimming the bugzilla) maybe a problem with the plug-in cards?
Bjorn
On Thu, Apr 6, 2023 at 3:09 PM Bjorn Helgaas <[email protected]> wrote:
>
> On Thu, Apr 06, 2023 at 08:46:23AM -0400, Jim Quinlan wrote:
> > The Broadcom STB/CM PCIe HW core, which is also used in RPi SOCs, may be
> > set into three mutually exclusive modes:
> >
> > (a) No clkreq# expected or required, refclk is always available.
> > (b) Clkreq# is expected to be driven by downstream device when needed.
> > (c) Bidirectional clkreq# for L1SS capable devices.
> >
> > Previously, only (b) was supported by the driver, as almost all STB boards
> > operate in this mode. But now there is interest in activating L1SS power
> > savings from STB customers, and also interest in accomodating mode (a) for
> > designs such as the RPi CM4 with IO board.
> >
> > The HW can tell us when mode (a) mode is needed. But there is no easy way
> > to tell if L1SS mode is needed. Unfortunately, getting this wrong causes a
> > panic during boot time. So we rely on the DT prop "brcm,enable-l1ss" to
> > tell us when mode (c) is desired. This property has already been in
> > use by Raspian Linux, but this immplementation adds more details and
> > discerns between (a) and (b) automatically.
> >
> > Link: https://bugzilla.kernel.org/show_bug.cgi?id=217276
> > Signed-off-by: Jim Quinlan <[email protected]>
>
> > + * We have "seen" clkreq# if it is asserted or has been in the past.
> > + * Note that the CLKREQ_IN_MASK is 1 if clkreq# is asserted.
>
> "CLKREQ#" to match PCIe spec and comments below.
Will do.
>
> > + if (l1ss && IS_ENABLED(CONFIG_PCIEASPM)) {
> > + /*
> > + * Note: This (l1ss) mode may not meet requirement for
> > + * Endpoints that require CLKREQ# assertion to clock active
> > + * within 400ns.
> > + */
> > + clkreq_set |= PCIE_MISC_HARD_PCIE_HARD_DEBUG_L1SS_ENABLE_MASK;
> > + dev_info(pcie->dev, "bi-dir clkreq; l1ss-capable devs only\n");
> > + dev_info(pcie->dev, "ASPM policy must be set to powersupersave\n");
>
> Seems problematic since L1SS can be enabled/disabled at run-time:
>
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/ABI/testing/sysfs-bus-pci?id=v6.2#n420
Yes it is problematic. AFAICT there are no notifier chain for
changing modes; you probably don't want me to add one and neither do I
:-).
Our HW should shift gears when there is a change the standard L1SS
control field, but it does not -- more on this below.
>
> The simplistic answer is to advertise L1SS support if and only if you
> can safely support it.
We can only safely support it if we know a priori that (a) the
downstream device is ASPM capable and (b) the policy is set to
"power_supersave" and will not be changed.
For (a), I thought about having the RC probe "peek" at the downstream
devices capabilities, but that would require it to go through the
capability linked-list. I have a feeling that would not be approved
by you folks.
For (b), there is no way to know at RC probe-time that the policy is
going to be "power_supersave". This calculation happens after the RC
probe exits, and besides, pcie_aspm_get_policy() is a static function.
And as you mentioned, the ASPM policy may be changed at runtime.
That is the reason for the "brcm,enable-l1ss" property.
>
> I don't know why this is an issue for this device but not others. Is
> it because there's some problem in the way the board is designed? Or
> (after skimming the bugzilla) maybe a problem with the plug-in cards?
FWIW, it's not clear that all of the devices for drivers in
drivers/pci/controller/ support L1SS -- our driver had no mention of
ti until now.
However, I asked the PCIe HW design engineer a question similar to
yours; i.e. from looking at all of the drivers' code as well as
pcie/asmp.c, there doesn't seem to be any issue wrt seamlessly
switching between uni-dir and bi-dir CLKREQ# in response to ASPM
control settings. He just answered something on the lines that for
this design, one has to make a deliberate choice of L1SS or !L1SS and
stick with it.
Regards,
Jim Quinlan
Broadcom STB
>
> Bjorn
Hi Jim,
Jim Quinlan <[email protected]> (2023-04-06):
> The current driver assumes the downstream devices can provide clkreq# for
> ASPM. These commits accomodate devices w/ or w/o clkreq# and also handle
> L1SS-capable devices.
>
> The Raspian Linux folks have already been using a PCIe RC property
> "brcm,enable-l1ss". These commits use the same property, in a
> backward-compatible manner, and the implementaion adds more detail and also
> automatically identifies devices w/o a clkreq# signal, i.e. most devices
> plugged into an RPi CM4 IO board.
>
> Jim Quinlan (3):
> dt-bindings: PCI: brcmstb: Add two optional props
> PCI: brcmstb: Clkreq# accomodations of downstream device
> PCI: brcmstb: Allow setting the completion timeout
>
> .../bindings/pci/brcm,stb-pcie.yaml | 12 +++
> drivers/pci/controller/pcie-brcmstb.c | 93 +++++++++++++++++--
> 2 files changed, 95 insertions(+), 10 deletions(-)
>
>
> base-commit: 99ddf2254febae9eab7fb0bcc02c5322243f5c49
I've just verified with the exact same hardware as in Bugzilla#217276
that latest master (v6.3-rc5-137-gf2afccfefe7b) still gets a kernel
panic at boot, which goes away once those 3 patches are applied. Do you
need any extra information, log excerpt, or something like that?
Cheers,
--
Cyril Brulebois ([email protected]) <https://debamax.com/>
D-I release manager -- Release team member -- Freelance Consultant
Apologies to anyone who is seeing this for the second time. I forgot
to format as plain text on the first transmission.
Cyril Brulebois kindly provided me with Debian packages for the two
kernels he built and I tested them as well. I can confirm that the one
without the three patches still had the panic on power up and when a
PCIe device is present. Otherwise it booted without difficulty. The
kernel with three patches booted successfully on all tries both cold
and warm with a PCIe/NVME installed. I was also able to mount
partitions on the NVME driver and copy data off.
My hardware
CM4 with WiFi/BT, 8GG RAM and no eMMC.
(Official) I/O board
PCIe/NVME adapter card with Intel 670p SSD installed
32GB Samsung EVO Select SD card (boot device.)
Thanks to all who contributed to this fix.
On Thu, Apr 6, 2023 at 4:31 PM Cyril Brulebois <[email protected]> wrote:
>
> Hi Jim,
>
> Jim Quinlan <[email protected]> (2023-04-06):
> > The current driver assumes the downstream devices can provide clkreq# for
> > ASPM. These commits accomodate devices w/ or w/o clkreq# and also handle
> > L1SS-capable devices.
> >
> > The Raspian Linux folks have already been using a PCIe RC property
> > "brcm,enable-l1ss". These commits use the same property, in a
> > backward-compatible manner, and the implementaion adds more detail and also
> > automatically identifies devices w/o a clkreq# signal, i.e. most devices
> > plugged into an RPi CM4 IO board.
> >
> > Jim Quinlan (3):
> > dt-bindings: PCI: brcmstb: Add two optional props
> > PCI: brcmstb: Clkreq# accomodations of downstream device
> > PCI: brcmstb: Allow setting the completion timeout
> >
> > .../bindings/pci/brcm,stb-pcie.yaml | 12 +++
> > drivers/pci/controller/pcie-brcmstb.c | 93 +++++++++++++++++--
> > 2 files changed, 95 insertions(+), 10 deletions(-)
> >
> >
> > base-commit: 99ddf2254febae9eab7fb0bcc02c5322243f5c49
>
> I've just verified with the exact same hardware as in Bugzilla#217276
> that latest master (v6.3-rc5-137-gf2afccfefe7b) still gets a kernel
> panic at boot, which goes away once those 3 patches are applied. Do you
> need any extra information, log excerpt, or something like that?
>
>
> Cheers,
> --
> Cyril Brulebois ([email protected]) <https://debamax.com/>
> D-I release manager -- Release team member -- Freelance Consultant
--
Beautiful Sunny Winfield