| Message ID | 20230508220126.16241-5-jim2101024@gmail.com (mailing list archive) |
|---|---|
| State | Superseded |
| Delegated to: | Krzysztof Wilczyński |
| Headers | show |
| Series | PCI: brcmstb: Configure appropriate HW CLKREQ# mode | expand |
Hi, Jim Quinlan <jim2101024@gmail.com> (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/20230411165919.23955-1-jim2101024@gmail.com/T/#m39ebab8bc2827b2304aeeff470a6c6a58f46f987 It would probably make sense to remove that [1] link entirely, to match the reference removal between v4 and v5. Cheers,
On Tue, May 9, 2023 at 3:51 AM Cyril Brulebois <kibi@debian.org> wrote: > > Hi, > > Jim Quinlan <jim2101024@gmail.com> (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/20230411165919.23955-1-jim2101024@gmail.com/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 (kibi@debian.org) <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/20230411165919.23955-1-jim2101024@gmail.com/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 <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 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/20230411165919.23955-1-jim2101024@gmail.com/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 <helgaas@kernel.org> 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/20230411165919.23955-1-jim2101024@gmail.com/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 <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 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 <helgaas@kernel.org> 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
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 */
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/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(+)