From: Bjorn Helgaas <helgaas@kernel.org> To: Jim Quinlan <jim2101024@gmail.com> Cc: linux-pci@vger.kernel.org, "Nicolas Saenz Julienne" <nsaenz@kernel.org>, "Bjorn Helgaas" <bhelgaas@google.com>, "Lorenzo Pieralisi" <lorenzo.pieralisi@arm.com>, "Cyril Brulebois" <kibi@debian.org>, "Phil Elwell" <phil@raspberrypi.com>, bcm-kernel-feedback-list@broadcom.com, james.quinlan@broadcom.com, "Florian Fainelli" <f.fainelli@gmail.com>, "Lorenzo Pieralisi" <lpieralisi@kernel.org>, "Krzysztof Wilczyński" <kw@linux.com>, "Rob Herring" <robh@kernel.org>, "moderated list:BROADCOM BCM2711/BCM2835 ARM ARCHITECTURE" <linux-rpi-kernel@lists.infradead.org>, "moderated list:BROADCOM BCM2711/BCM2835 ARM ARCHITECTURE" <linux-arm-kernel@lists.infradead.org>, "open list" <linux-kernel@vger.kernel.org> Subject: Re: [PATCH v1 2/3] PCI: brcmstb: Clkreq# accomodations of downstream device Date: Thu, 6 Apr 2023 14:09:53 -0500 [thread overview] Message-ID: <20230406190953.GA3723665@bhelgaas> (raw) In-Reply-To: <20230406124625.41325-3-jim2101024@gmail.com> 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
WARNING: multiple messages have this Message-ID (diff)
From: Bjorn Helgaas <helgaas@kernel.org> To: Jim Quinlan <jim2101024@gmail.com> Cc: linux-pci@vger.kernel.org, "Nicolas Saenz Julienne" <nsaenz@kernel.org>, "Bjorn Helgaas" <bhelgaas@google.com>, "Lorenzo Pieralisi" <lorenzo.pieralisi@arm.com>, "Cyril Brulebois" <kibi@debian.org>, "Phil Elwell" <phil@raspberrypi.com>, bcm-kernel-feedback-list@broadcom.com, james.quinlan@broadcom.com, "Florian Fainelli" <f.fainelli@gmail.com>, "Lorenzo Pieralisi" <lpieralisi@kernel.org>, "Krzysztof Wilczyński" <kw@linux.com>, "Rob Herring" <robh@kernel.org>, "moderated list:BROADCOM BCM2711/BCM2835 ARM ARCHITECTURE" <linux-rpi-kernel@lists.infradead.org>, "moderated list:BROADCOM BCM2711/BCM2835 ARM ARCHITECTURE" <linux-arm-kernel@lists.infradead.org>, "open list" <linux-kernel@vger.kernel.org> Subject: Re: [PATCH v1 2/3] PCI: brcmstb: Clkreq# accomodations of downstream device Date: Thu, 6 Apr 2023 14:09:53 -0500 [thread overview] Message-ID: <20230406190953.GA3723665@bhelgaas> (raw) In-Reply-To: <20230406124625.41325-3-jim2101024@gmail.com> 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 _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2023-04-06 19:10 UTC|newest] Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top 2023-04-06 12:46 [PATCH v1 0/3] PCI: brcmstb: Clkreq# accomodations of downstream device Jim Quinlan 2023-04-06 12:46 ` Jim Quinlan 2023-04-06 12:46 ` [PATCH v1 1/3] dt-bindings: PCI: brcmstb: Add two optional props Jim Quinlan 2023-04-06 12:46 ` Jim Quinlan 2023-04-06 15:39 ` Stefan Wahren 2023-04-06 15:39 ` Stefan Wahren 2023-04-06 16:58 ` Jim Quinlan 2023-04-06 16:58 ` Jim Quinlan 2023-04-06 18:35 ` Krzysztof Kozlowski 2023-04-06 18:35 ` Krzysztof Kozlowski 2023-04-06 18:47 ` Florian Fainelli 2023-04-06 18:47 ` Florian Fainelli 2023-04-06 18:53 ` Krzysztof Kozlowski 2023-04-06 18:53 ` Krzysztof Kozlowski 2023-04-06 18:34 ` Krzysztof Kozlowski 2023-04-06 18:34 ` Krzysztof Kozlowski 2023-04-06 18:53 ` Florian Fainelli 2023-04-06 18:53 ` Florian Fainelli 2023-04-06 18:54 ` Krzysztof Kozlowski 2023-04-06 18:54 ` Krzysztof Kozlowski 2023-04-06 12:46 ` [PATCH v1 2/3] PCI: brcmstb: Clkreq# accomodations of downstream device Jim Quinlan 2023-04-06 12:46 ` Jim Quinlan 2023-04-06 19:09 ` Bjorn Helgaas [this message] 2023-04-06 19:09 ` Bjorn Helgaas 2023-04-06 20:03 ` Jim Quinlan 2023-04-06 20:03 ` Jim Quinlan 2023-04-06 12:46 ` [PATCH v1 3/3] PCI: brcmstb: Allow setting the completion timeout Jim Quinlan 2023-04-06 12:46 ` Jim Quinlan 2023-04-06 15:59 ` Stefan Wahren 2023-04-06 15:59 ` Stefan Wahren 2023-04-06 17:15 ` Jim Quinlan 2023-04-06 17:15 ` Jim Quinlan 2023-04-06 21:31 ` [PATCH v1 0/3] PCI: brcmstb: Clkreq# accomodations of downstream device Cyril Brulebois 2023-04-06 21:31 ` Cyril Brulebois 2023-04-07 15:06 ` Hank Barta 2023-04-07 15:06 ` Hank Barta
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20230406190953.GA3723665@bhelgaas \ --to=helgaas@kernel.org \ --cc=bcm-kernel-feedback-list@broadcom.com \ --cc=bhelgaas@google.com \ --cc=f.fainelli@gmail.com \ --cc=james.quinlan@broadcom.com \ --cc=jim2101024@gmail.com \ --cc=kibi@debian.org \ --cc=kw@linux.com \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-pci@vger.kernel.org \ --cc=linux-rpi-kernel@lists.infradead.org \ --cc=lorenzo.pieralisi@arm.com \ --cc=lpieralisi@kernel.org \ --cc=nsaenz@kernel.org \ --cc=phil@raspberrypi.com \ --cc=robh@kernel.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.