| Message ID | 20230406124625.41325-3-jim2101024@gmail.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | PCI: brcmstb: Clkreq# accomodations of downstream device | expand |
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 <jim2101024@gmail.com> > + * 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 <helgaas@kernel.org> 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 <jim2101024@gmail.com> > > > + * 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
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; }
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 <jim2101024@gmail.com> --- drivers/pci/controller/pcie-brcmstb.c | 69 +++++++++++++++++++++++---- 1 file changed, 59 insertions(+), 10 deletions(-)