From: Jim Quinlan <jim2101024@gmail.com> To: 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, jim2101024@gmail.com, james.quinlan@broadcom.com Cc: "Florian Fainelli" <f.fainelli@gmail.com>, "Lorenzo Pieralisi" <lpieralisi@kernel.org>, "Krzysztof Wilczyński" <kw@linux.com>, "Rob Herring" <robh@kernel.org>, linux-rpi-kernel@lists.infradead.org (moderated list:BROADCOM BCM2711/BCM2835 ARM ARCHITECTURE), linux-arm-kernel@lists.infradead.org (moderated list:BROADCOM BCM2711/BCM2835 ARM ARCHITECTURE), linux-kernel@vger.kernel.org (open list) Subject: [PATCH v4 4/5] PCI: brcmstb: Don't assume 2711 bootloader leaves PERST# asserted Date: Fri, 28 Apr 2023 18:34:58 -0400 [thread overview] Message-ID: <20230428223500.23337-5-jim2101024@gmail.com> (raw) In-Reply-To: <20230428223500.23337-1-jim2101024@gmail.com> 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() time. This is not necessarily the case for the 2711/RPi bootloader. In addition, there is a failing test case [1] that may be caused by a deasserted PERST#. Finally, Raspian version of Linux does assert PERST# at probe() time. So, for 2711/RPi SOCs, do what Raspian does and assert PERST#. [1] https://lore.kernel.org/linux-pci/20230411165919.23955-1-jim2101024@gmail.com/T/#m39ebab8bc2827b2304aeeff470a6c6a58f46f987 Signed-off-by: Jim Quinlan <jim2101024@gmail.com> --- 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 c2cb683447ac..c486f4b979cc 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
WARNING: multiple messages have this Message-ID (diff)
From: Jim Quinlan <jim2101024@gmail.com> To: 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, jim2101024@gmail.com, james.quinlan@broadcom.com Cc: "Florian Fainelli" <f.fainelli@gmail.com>, "Lorenzo Pieralisi" <lpieralisi@kernel.org>, "Krzysztof Wilczyński" <kw@linux.com>, "Rob Herring" <robh@kernel.org>, linux-rpi-kernel@lists.infradead.org (moderated list:BROADCOM BCM2711/BCM2835 ARM ARCHITECTURE), linux-arm-kernel@lists.infradead.org (moderated list:BROADCOM BCM2711/BCM2835 ARM ARCHITECTURE), linux-kernel@vger.kernel.org (open list) Subject: [PATCH v4 4/5] PCI: brcmstb: Don't assume 2711 bootloader leaves PERST# asserted Date: Fri, 28 Apr 2023 18:34:58 -0400 [thread overview] Message-ID: <20230428223500.23337-5-jim2101024@gmail.com> (raw) In-Reply-To: <20230428223500.23337-1-jim2101024@gmail.com> 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() time. This is not necessarily the case for the 2711/RPi bootloader. In addition, there is a failing test case [1] that may be caused by a deasserted PERST#. Finally, Raspian version of Linux does assert PERST# at probe() time. So, for 2711/RPi SOCs, do what Raspian does and assert PERST#. [1] https://lore.kernel.org/linux-pci/20230411165919.23955-1-jim2101024@gmail.com/T/#m39ebab8bc2827b2304aeeff470a6c6a58f46f987 Signed-off-by: Jim Quinlan <jim2101024@gmail.com> --- 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 c2cb683447ac..c486f4b979cc 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 _______________________________________________ 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-28 22:35 UTC|newest] Thread overview: 49+ messages / expand[flat|nested] mbox.gz Atom feed top 2023-04-28 22:34 [PATCH v4 0/5] PCI: brcmstb: Configure appropriate HW CLKREQ# mode Jim Quinlan 2023-04-28 22:34 ` Jim Quinlan 2023-04-28 22:34 ` [PATCH v4 1/5] dt-bindings: PCI: brcmstb: brcm,{enable-l1ss,completion-timeout-us} props Jim Quinlan 2023-04-28 22:34 ` Jim Quinlan 2023-04-30 19:10 ` Bjorn Helgaas 2023-04-30 19:10 ` Bjorn Helgaas 2023-05-03 14:38 ` Jim Quinlan 2023-05-03 14:38 ` Jim Quinlan 2023-05-03 18:07 ` Bjorn Helgaas 2023-05-03 18:07 ` Bjorn Helgaas 2023-05-03 21:38 ` Jim Quinlan 2023-05-03 21:38 ` Jim Quinlan 2023-05-03 22:18 ` Bjorn Helgaas 2023-05-03 22:18 ` Bjorn Helgaas 2023-05-05 12:39 ` Jim Quinlan 2023-05-05 12:39 ` Jim Quinlan 2023-05-05 13:34 ` Bjorn Helgaas 2023-05-05 13:34 ` Bjorn Helgaas 2023-05-05 14:40 ` Jim Quinlan 2023-05-05 14:40 ` Jim Quinlan 2023-05-05 14:54 ` Bjorn Helgaas 2023-05-05 14:54 ` Bjorn Helgaas 2023-04-28 22:34 ` [PATCH v4 2/5] PCI: brcmstb: Configure HW CLKREQ# mode appropriate for downstream device Jim Quinlan 2023-04-28 22:34 ` Jim Quinlan 2023-05-03 6:09 ` Stefan Wahren 2023-05-03 6:09 ` Stefan Wahren 2023-04-28 22:34 ` [PATCH v4 3/5] PCI: brcmstb: Set PCIe transaction completion timeout Jim Quinlan 2023-04-28 22:34 ` Jim Quinlan 2023-04-30 19:13 ` Bjorn Helgaas 2023-04-30 19:13 ` Bjorn Helgaas 2023-04-30 21:24 ` Jim Quinlan 2023-04-30 21:24 ` Jim Quinlan 2023-04-30 22:38 ` Bjorn Helgaas 2023-04-30 22:38 ` Bjorn Helgaas 2023-05-01 20:55 ` Lukas Wunner 2023-05-03 14:06 ` Jim Quinlan 2023-05-03 14:06 ` Jim Quinlan 2023-05-03 6:06 ` Stefan Wahren 2023-05-03 6:06 ` Stefan Wahren 2023-04-28 22:34 ` Jim Quinlan [this message] 2023-04-28 22:34 ` [PATCH v4 4/5] PCI: brcmstb: Don't assume 2711 bootloader leaves PERST# asserted Jim Quinlan 2023-04-28 22:34 ` [PATCH v4 5/5] PCI: brcmstb: Remove stale comment Jim Quinlan 2023-04-28 22:34 ` Jim Quinlan 2023-05-02 23:15 ` [PATCH v4 0/5] PCI: brcmstb: Configure appropriate HW CLKREQ# mode Cyril Brulebois 2023-05-02 23:15 ` Cyril Brulebois 2023-05-03 18:10 ` Jim Quinlan 2023-05-03 18:10 ` Jim Quinlan 2023-05-03 19:10 ` Cyril Brulebois 2023-05-03 19:10 ` Cyril Brulebois
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=20230428223500.23337-5-jim2101024@gmail.com \ --to=jim2101024@gmail.com \ --cc=bcm-kernel-feedback-list@broadcom.com \ --cc=bhelgaas@google.com \ --cc=f.fainelli@gmail.com \ --cc=james.quinlan@broadcom.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.