v5 -- Remove DT property "brcm,completion-timeout-us" from
"DT bindings" commit. Although this error may be reported
as a completion timeout, its cause was traced to an
internal bus timeout which may occur even when there is
no PCIe access being processed. We set a timeout of four
seconds only if we are operating in "L1SS CLKREQ#" mode.
-- Correct CEM 2.0 reference provided by HW engineer,
s/3.2.5.2.5/3.2.5.2.2/ (Bjorn)
-- Add newline to dev_info() string (Stefan)
-- Change variable rval to unsigned (Stefan)
-- s/implementaion/implementation/ (Bjorn)
-- s/superpowersave/powersupersave/ (Bjorn)
-- Slightly modify message on "PERST#" commit.
-- Rebase to torvalds master
v4 -- New commit that asserts PERST# for 2711/RPi SOCs at PCIe RC
driver probe() time. This is done in Raspian Linux and its
absence may be the cause of a failing test case.
-- New commit that removes stale comment.
v3 -- Rewrote commit msgs and comments refering panics if L1SS
is enabled/disabled; the code snippet that unadvertises L1SS
eliminates the panic scenario. (Bjorn)
-- Add reference for "400ns of CLKREQ# assertion" blurb (Bjorn)
-- Put binding names in DT commit Subject (Bjorn)
-- Add a verb to a commit's subject line (Bjorn)
-- s/accomodat(\w+)/accommodat$1/g (Bjorn)
-- Rewrote commit msgs and comments refering panics if L1SS
is enabled/disabled; the code snippet that unadvertises L1SS
eliminates the panic scenario. (Bjorn)
v2 -- Changed binding property 'brcm,completion-timeout-msec' to
'brcm,completion-timeout-us'. (StefanW for standard suffix).
-- Warn when clamping timeout value, and include clamped
region in message. Also add min and max in YAML. (StefanW)
-- Qualify description of "brcm,completion-timeout-us" so that
it refers to PCIe transactions. (StefanW)
-- Remvove mention of Linux specifics in binding description. (StefanW)
-- s/clkreq#/CLKREQ#/g (Bjorn)
-- Refactor completion-timeout-us code to compare max and min to
value given by the property (as opposed to the computed value).
v1 -- 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 (5):
dt-bindings: PCI: brcmstb: Add brcm,enable-l1ss property
PCI: brcmstb: Configure HW CLKREQ# mode appropriate for downstream
device
PCI: brcmstb: Set higher value for internal bus timeout
PCI: brcmstb: Don't assume 2711 bootloader leaves PERST# asserted
PCI: brcmstb: Remove stale comment
.../bindings/pci/brcm,stb-pcie.yaml | 9 ++
drivers/pci/controller/pcie-brcmstb.c | 91 ++++++++++++++++---
2 files changed, 89 insertions(+), 11 deletions(-)
base-commit: ac9a78681b921877518763ba0e89202254349d1b
--
2.17.1
The Broadcom STB/CM PCIe HW core, which is also used in RPi SOCs, must be
deliberately set by the RC probe() into one of 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/CM
boards operate in this mode. But now there is interest in activating L1SS
power savings from STB/CM customers, and also interest in accommodating
mode (a) for designs such as the RPi CM4 with IO board.
The HW+driver is able to tell us when mode (a) or (b) is needed. All
devices should be functional using the RC-driver selected (a) or (b) mode.
For those with L1SS-capable devices that desire the power savings that come
with mode (c) we rely on the DT prop "brcm,enable-l1ss". It would be nice
to do this automatically but there is no easy way to determine this at the
time the PCI RC driver executes its probe(). Using this mode only makes
sense when the downstream device is L1SS-capable and the OS has been
configured to activate L1SS (e.g. policy==powersupersave).
The "brcm,enable-l1ss" property has already been in use by Raspian Linux,
but this implementation adds more details and discerns between (a) and (b)
automatically.
Link: https://bugzilla.kernel.org/show_bug.cgi?id=217276
Tested-by: Florian Fainelli <[email protected]>
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..d30636a725d7 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: For boards using a mini-card connector, this mode
+ * (L1SS CLKREQ# 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.
+ */
+ clkreq_set |= PCIE_MISC_HARD_PCIE_HARD_DEBUG_L1SS_ENABLE_MASK;
+ dev_info(pcie->dev, "bi-dir CLKREQ# for L1SS power savings");
+ } 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 L0s, L1 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
During long periods of the PCIe RC HW being in an L1SS sleep state, there
may be a timeout on an internal bus access, even though there may not be
any PCIe access involved. Such a timeout will cause a subsequent CPU
abort.
So, when "brcm,enable-l1ss" is observed, we increase the timeout value to
four seconds instead of using its HW default.
Tested-by: Florian Fainelli <[email protected]>
Signed-off-by: Jim Quinlan <[email protected]>
---
drivers/pci/controller/pcie-brcmstb.c | 16 ++++++++++++++++
1 file changed, 16 insertions(+)
diff --git a/drivers/pci/controller/pcie-brcmstb.c b/drivers/pci/controller/pcie-brcmstb.c
index d30636a725d7..fe0415a98c63 100644
--- a/drivers/pci/controller/pcie-brcmstb.c
+++ b/drivers/pci/controller/pcie-brcmstb.c
@@ -1034,6 +1034,21 @@ static int brcm_pcie_setup(struct brcm_pcie *pcie)
return 0;
}
+/*
+ * This extends the timeout period for an access to an internal bus. This
+ * access timeout may occur during L1SS sleep periods even without the
+ * presence of a PCIe access.
+ */
+static void brcm_extend_rbus_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_us = 4000000; /* 4 seconds, our setting for L1SS */
+
+ /* Each unit in timeout register is 1/216,000,000 seconds */
+ writel(216 * timeout_us, pcie->base + REG_OFFSET);
+}
+
static void brcm_config_clkreq(struct brcm_pcie *pcie)
{
bool l1ss = of_property_read_bool(pcie->np, "brcm,enable-l1ss");
@@ -1059,6 +1074,7 @@ static void brcm_config_clkreq(struct brcm_pcie *pcie)
* of 400ns, as specified in 3.2.5.2.2 of the PCI Express
* Mini CEM 2.0 specification.
*/
+ brcm_extend_rbus_timeout(pcie);
clkreq_set |= PCIE_MISC_HARD_PCIE_HARD_DEBUG_L1SS_ENABLE_MASK;
dev_info(pcie->dev, "bi-dir CLKREQ# for L1SS power savings");
} else {
--
2.17.1
The current PCIe driver assumes PERST# is asserted when probe() is invoked.
The reasons are as follows:
(1) One Broadcom SOC (7278) causes a panic if the PERST# register is
written during this time window.
(2) If PERST# is deasserted at Linux probe() time, experience and QA
suspend/resume tests have shown that some endpoint devices fail if the
PERST# is pulsed (deasserted => asserted => deasserted) quickly in this
fashion, even though the timing is in accordance with their datasheets.
(3) Keeping things in reset tends to save power, if for some reason the
PCIe driver is not yet present.
Broadcom STB and CM SOCs bootloaders always have PERST# asserted at
probe(). This is not necessarily the case for the 2711/RPi bootloader,
so, for 2711/RPi SOCs, do what Raspian OS does and assert PERST#.
[1] https://lore.kernel.org/linux-pci/[email protected]/T/#m39ebab8bc2827b2304aeeff470a6c6a58f46f987
Signed-off-by: Jim Quinlan <[email protected]>
---
drivers/pci/controller/pcie-brcmstb.c | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/drivers/pci/controller/pcie-brcmstb.c b/drivers/pci/controller/pcie-brcmstb.c
index fe0415a98c63..7b698a9a851e 100644
--- a/drivers/pci/controller/pcie-brcmstb.c
+++ b/drivers/pci/controller/pcie-brcmstb.c
@@ -884,6 +884,11 @@ static int brcm_pcie_setup(struct brcm_pcie *pcie)
/* Reset the bridge */
pcie->bridge_sw_init_set(pcie, 1);
+
+ /* Ensure that PERST# is asserted; some bootloaders may deassert it. */
+ if (pcie->type == BCM2711)
+ pcie->perst_set(pcie, 1);
+
usleep_range(100, 200);
/* Take the bridge out of reset */
--
2.17.1
A comment says that Multi-MSI is not supported by the driver.
A past commit [1] added this feature, so the comment is
incorrect and is removed.
[1] commit 198acab1772f22f2 ("PCI: brcmstb: Enable Multi-MSI")
Signed-off-by: Jim Quinlan <[email protected]>
---
drivers/pci/controller/pcie-brcmstb.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/pci/controller/pcie-brcmstb.c b/drivers/pci/controller/pcie-brcmstb.c
index 7b698a9a851e..acd478edbe2f 100644
--- a/drivers/pci/controller/pcie-brcmstb.c
+++ b/drivers/pci/controller/pcie-brcmstb.c
@@ -449,7 +449,6 @@ static struct irq_chip brcm_msi_irq_chip = {
};
static struct msi_domain_info brcm_msi_domain_info = {
- /* Multi MSI is supported by the controller, but not by this driver */
.flags = (MSI_FLAG_USE_DEF_DOM_OPS | MSI_FLAG_USE_DEF_CHIP_OPS |
MSI_FLAG_MULTI_PCI_MSI),
.chip = &brcm_msi_irq_chip,
--
2.17.1
On 5/8/23 15:01, Jim Quinlan wrote:
> A comment says that Multi-MSI is not supported by the driver.
> A past commit [1] added this feature, so the comment is
> incorrect and is removed.
>
> [1] commit 198acab1772f22f2 ("PCI: brcmstb: Enable Multi-MSI")
>
> Signed-off-by: Jim Quinlan <[email protected]>
Acked-by: Florian Fainelli <[email protected]>
--
Florian
Hi Jim,
Jim Quinlan <[email protected]> (2023-05-08):
> v5 -- Remove DT property "brcm,completion-timeout-us" from
> "DT bindings" commit. Although this error may be reported
> as a completion timeout, its cause was traced to an
> internal bus timeout which may occur even when there is
> no PCIe access being processed. We set a timeout of four
> seconds only if we are operating in "L1SS CLKREQ#" mode.
> -- Correct CEM 2.0 reference provided by HW engineer,
> s/3.2.5.2.5/3.2.5.2.2/ (Bjorn)
> -- Add newline to dev_info() string (Stefan)
> -- Change variable rval to unsigned (Stefan)
> -- s/implementaion/implementation/ (Bjorn)
> -- s/superpowersave/powersupersave/ (Bjorn)
> -- Slightly modify message on "PERST#" commit.
> -- Rebase to torvalds master
Same results as with v4: looks good to me!
Using an official CM4 IO Board, I've successfully tested the same 9
setups as before, combining each:
- CM4 Lite Rev 1.0
- CM4 8/32 Rev 1.0
- CM4 4/32 Rev 1.1
with each off-the-shelf PCIe/USB adapter at my disposal:
- SupaHub PCE6U1C-R02, VER 006
- SupaHub PCE6U1C-R02, VER 006S
- Waveshare based on VIA VL805/806
Each system boots successfully, exposes the Kingston memory stick
plugged onto the PCIe/USB adapter, and happily reads data from it.
Note: I only tested each CM4 with the upgraded EEPROM (2023-01-11),
and without tweaking the DTB (i.e. without adding brcm,enable-l1ss).
Tested-By: Cyril Brulebois <[email protected]>
Cheers,
--
Cyril Brulebois ([email protected]) <https://debamax.com/>
D-I release manager -- Release team member -- Freelance Consultant
Hi,
Jim Quinlan <[email protected]> (2023-05-08):
> The current PCIe driver assumes PERST# is asserted when probe() is invoked.
> The reasons are as follows:
>
> (1) One Broadcom SOC (7278) causes a panic if the PERST# register is
> written during this time window.
>
> (2) If PERST# is deasserted at Linux probe() time, experience and QA
> suspend/resume tests have shown that some endpoint devices fail if the
> PERST# is pulsed (deasserted => asserted => deasserted) quickly in this
> fashion, even though the timing is in accordance with their datasheets.
>
> (3) Keeping things in reset tends to save power, if for some reason the
> PCIe driver is not yet present.
>
> Broadcom STB and CM SOCs bootloaders always have PERST# asserted at
> probe(). This is not necessarily the case for the 2711/RPi bootloader,
> so, for 2711/RPi SOCs, do what Raspian OS does and assert PERST#.
>
> [1] https://lore.kernel.org/linux-pci/[email protected]/T/#m39ebab8bc2827b2304aeeff470a6c6a58f46f987
It would probably make sense to remove that [1] link entirely, to match
the reference removal between v4 and v5.
Cheers,
--
Cyril Brulebois ([email protected]) <https://debamax.com/>
D-I release manager -- Release team member -- Freelance Consultant
On Tue, May 9, 2023 at 3:51 AM Cyril Brulebois <[email protected]> wrote:
>
> Hi,
>
> Jim Quinlan <[email protected]> (2023-05-08):
> > The current PCIe driver assumes PERST# is asserted when probe() is invoked.
> > The reasons are as follows:
> >
> > (1) One Broadcom SOC (7278) causes a panic if the PERST# register is
> > written during this time window.
> >
> > (2) If PERST# is deasserted at Linux probe() time, experience and QA
> > suspend/resume tests have shown that some endpoint devices fail if the
> > PERST# is pulsed (deasserted => asserted => deasserted) quickly in this
> > fashion, even though the timing is in accordance with their datasheets.
> >
> > (3) Keeping things in reset tends to save power, if for some reason the
> > PCIe driver is not yet present.
> >
> > Broadcom STB and CM SOCs bootloaders always have PERST# asserted at
> > probe(). This is not necessarily the case for the 2711/RPi bootloader,
> > so, for 2711/RPi SOCs, do what Raspian OS does and assert PERST#.
> >
> > [1] https://lore.kernel.org/linux-pci/[email protected]/T/#m39ebab8bc2827b2304aeeff470a6c6a58f46f987
>
> It would probably make sense to remove that [1] link entirely, to match
> the reference removal between v4 and v5.
Yep
>
>
> Cheers,
> --
> Cyril Brulebois ([email protected]) <https://debamax.com/>
> D-I release manager -- Release team member -- Freelance Consultant
On Tue, May 9, 2023 at 3:47 AM Cyril Brulebois <[email protected]> wrote:
>
> Hi Jim,
>
> Jim Quinlan <[email protected]> (2023-05-08):
> > v5 -- Remove DT property "brcm,completion-timeout-us" from
> > "DT bindings" commit. Although this error may be reported
> > as a completion timeout, its cause was traced to an
> > internal bus timeout which may occur even when there is
> > no PCIe access being processed. We set a timeout of four
> > seconds only if we are operating in "L1SS CLKREQ#" mode.
> > -- Correct CEM 2.0 reference provided by HW engineer,
> > s/3.2.5.2.5/3.2.5.2.2/ (Bjorn)
> > -- Add newline to dev_info() string (Stefan)
> > -- Change variable rval to unsigned (Stefan)
> > -- s/implementaion/implementation/ (Bjorn)
> > -- s/superpowersave/powersupersave/ (Bjorn)
> > -- Slightly modify message on "PERST#" commit.
> > -- Rebase to torvalds master
>
> Same results as with v4: looks good to me!
>
> Using an official CM4 IO Board, I've successfully tested the same 9
> setups as before, combining each:
> - CM4 Lite Rev 1.0
> - CM4 8/32 Rev 1.0
> - CM4 4/32 Rev 1.1
>
> with each off-the-shelf PCIe/USB adapter at my disposal:
> - SupaHub PCE6U1C-R02, VER 006
> - SupaHub PCE6U1C-R02, VER 006S
> - Waveshare based on VIA VL805/806
>
> Each system boots successfully, exposes the Kingston memory stick
> plugged onto the PCIe/USB adapter, and happily reads data from it.
>
> Note: I only tested each CM4 with the upgraded EEPROM (2023-01-11),
> and without tweaking the DTB (i.e. without adding brcm,enable-l1ss).
>
>
> Tested-By: Cyril Brulebois <[email protected]>
Thanks a lot for doing this Cyril!
>
>
> Cheers,
> --
> Cyril Brulebois ([email protected]) <https://debamax.com/>
> D-I release manager -- Release team member -- Freelance Consultant
Re subject, what does the patch actually *do*?
It looks like it "asserts PERST# on BCM2711", which I think would be
more informative than "don't assume 2711 bootloader leaves PERST#
asserted".
On Mon, May 08, 2023 at 06:01:24PM -0400, Jim Quinlan wrote:
> The current PCIe driver assumes PERST# is asserted when probe() is invoked.
> The reasons are as follows:
>
> (1) One Broadcom SOC (7278) causes a panic if the PERST# register is
> written during this time window.
>
> (2) If PERST# is deasserted at Linux probe() time, experience and QA
> suspend/resume tests have shown that some endpoint devices fail if the
> PERST# is pulsed (deasserted => asserted => deasserted) quickly in this
> fashion, even though the timing is in accordance with their datasheets.
>
> (3) Keeping things in reset tends to save power, if for some reason the
> PCIe driver is not yet present.
>
> Broadcom STB and CM SOCs bootloaders always have PERST# asserted at
> probe(). This is not necessarily the case for the 2711/RPi bootloader,
> so, for 2711/RPi SOCs, do what Raspian OS does and assert PERST#.
>
> [1] https://lore.kernel.org/linux-pci/[email protected]/T/#m39ebab8bc2827b2304aeeff470a6c6a58f46f987
Does this link go with something above? "[1]" isn't mentioned above.
I did look at that message, but the connection to this patch isn't
obvious to me.
> Signed-off-by: Jim Quinlan <[email protected]>
> ---
> drivers/pci/controller/pcie-brcmstb.c | 5 +++++
> 1 file changed, 5 insertions(+)
>
> diff --git a/drivers/pci/controller/pcie-brcmstb.c b/drivers/pci/controller/pcie-brcmstb.c
> index fe0415a98c63..7b698a9a851e 100644
> --- a/drivers/pci/controller/pcie-brcmstb.c
> +++ b/drivers/pci/controller/pcie-brcmstb.c
> @@ -884,6 +884,11 @@ static int brcm_pcie_setup(struct brcm_pcie *pcie)
>
> /* Reset the bridge */
> pcie->bridge_sw_init_set(pcie, 1);
> +
> + /* Ensure that PERST# is asserted; some bootloaders may deassert it. */
> + if (pcie->type == BCM2711)
> + pcie->perst_set(pcie, 1);
> +
> usleep_range(100, 200);
>
> /* Take the bridge out of reset */
> --
> 2.17.1
>
On Wed, May 10, 2023 at 05:26:13PM -0500, Bjorn Helgaas wrote:
> ...
> > [1] https://lore.kernel.org/linux-pci/[email protected]/T/#m39ebab8bc2827b2304aeeff470a6c6a58f46f987
>
> Does this link go with something above? "[1]" isn't mentioned above.
> I did look at that message, but the connection to this patch isn't
> obvious to me.
Sorry, I noticed after sending this that you and Cyril have already
taken care of this.
On Wed, May 10, 2023 at 6:26 PM Bjorn Helgaas <[email protected]> wrote:
>
> Re subject, what does the patch actually *do*?
>
> It looks like it "asserts PERST# on BCM2711", which I think would be
> more informative than "don't assume 2711 bootloader leaves PERST#
> asserted".
Do you have any other feedback on the other commits? I can change the
subject message as you like and the remove the stale footnote you and
Cyril noticed, and submit V6.
Thanks,
Jim Quinlan
Broadcom STB
>
> On Mon, May 08, 2023 at 06:01:24PM -0400, Jim Quinlan wrote:
> > The current PCIe driver assumes PERST# is asserted when probe() is invoked.
> > The reasons are as follows:
> >
> > (1) One Broadcom SOC (7278) causes a panic if the PERST# register is
> > written during this time window.
> >
> > (2) If PERST# is deasserted at Linux probe() time, experience and QA
> > suspend/resume tests have shown that some endpoint devices fail if the
> > PERST# is pulsed (deasserted => asserted => deasserted) quickly in this
> > fashion, even though the timing is in accordance with their datasheets.
> >
> > (3) Keeping things in reset tends to save power, if for some reason the
> > PCIe driver is not yet present.
> >
> > Broadcom STB and CM SOCs bootloaders always have PERST# asserted at
> > probe(). This is not necessarily the case for the 2711/RPi bootloader,
> > so, for 2711/RPi SOCs, do what Raspian OS does and assert PERST#.
> >
> > [1] https://lore.kernel.org/linux-pci/[email protected]/T/#m39ebab8bc2827b2304aeeff470a6c6a58f46f987
>
> Does this link go with something above? "[1]" isn't mentioned above.
> I did look at that message, but the connection to this patch isn't
> obvious to me.
>
> > Signed-off-by: Jim Quinlan <[email protected]>
> > ---
> > drivers/pci/controller/pcie-brcmstb.c | 5 +++++
> > 1 file changed, 5 insertions(+)
> >
> > diff --git a/drivers/pci/controller/pcie-brcmstb.c b/drivers/pci/controller/pcie-brcmstb.c
> > index fe0415a98c63..7b698a9a851e 100644
> > --- a/drivers/pci/controller/pcie-brcmstb.c
> > +++ b/drivers/pci/controller/pcie-brcmstb.c
> > @@ -884,6 +884,11 @@ static int brcm_pcie_setup(struct brcm_pcie *pcie)
> >
> > /* Reset the bridge */
> > pcie->bridge_sw_init_set(pcie, 1);
> > +
> > + /* Ensure that PERST# is asserted; some bootloaders may deassert it. */
> > + if (pcie->type == BCM2711)
> > + pcie->perst_set(pcie, 1);
> > +
> > usleep_range(100, 200);
> >
> > /* Take the bridge out of reset */
> > --
> > 2.17.1
> >
On Wed, May 10, 2023 at 06:46:45PM -0400, Jim Quinlan wrote:
> On Wed, May 10, 2023 at 6:26 PM Bjorn Helgaas <[email protected]> wrote:
> >
> > Re subject, what does the patch actually *do*?
> >
> > It looks like it "asserts PERST# on BCM2711", which I think would be
> > more informative than "don't assume 2711 bootloader leaves PERST#
> > asserted".
>
> Do you have any other feedback on the other commits? I can change the
> subject message as you like and the remove the stale footnote you and
> Cyril noticed, and submit V6.
Nope, and there's really no hurry. Trivial stuff like this can be easily
done when merging. I think two postings per week is plenty. Each new
posting takes work to look at, so it's a win to wait a bit and
accumulate non-trivial updates before reposting.
Bjorn