From: Bjorn Helgaas <helgaas@kernel.org>
To: Jim Quinlan <james.quinlan@broadcom.com>
Cc: "Bjorn Helgaas" <bhelgaas@google.com>,
"open list:PCI NATIVE HOST BRIDGE AND ENDPOINT DRIVERS"
<linux-pci@vger.kernel.org>,
"Nicolas Saenz Julienne" <nsaenz@kernel.org>,
"Lorenzo Pieralisi" <lorenzo.pieralisi@arm.com>,
"Cyril Brulebois" <kibi@debian.org>,
"Phil Elwell" <phil@raspberrypi.com>,
"maintainer:BROADCOM BCM7XXX ARM ARCHITECTURE"
<bcm-kernel-feedback-list@broadcom.com>,
"Florian Fainelli" <f.fainelli@gmail.com>,
"Jim Quinlan" <jim2101024@gmail.com>,
"Krzysztof Wilczyński" <kw@linux.com>,
"Lorenzo Pieralisi" <lpieralisi@kernel.org>,
"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 v6 3/5] PCI: brcmstb: Set higher value for internal bus timeout
Date: Mon, 14 Aug 2023 17:06:58 -0500 [thread overview]
Message-ID: <20230814220658.GA193031@bhelgaas> (raw)
In-Reply-To: <CA+-6iNzKB4vMkM4Qt6781GN-WwzCCdUYY3o=stgPSjQyJPr6vQ@mail.gmail.com>
On Mon, Aug 14, 2023 at 03:30:07PM -0400, Jim Quinlan wrote:
> On Fri, Jul 28, 2023 at 12:15 PM Jim Quinlan <james.quinlan@broadcom.com> wrote:
> > On Thu, Jul 27, 2023, 10:44 PM Lorenzo Pieralisi <lpieralisi@kernel.org> wrote:
> >> On Fri, Jun 23, 2023 at 10:40:56AM -0400, Jim Quinlan wrote:
> >> > 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.
> >> >
> >> > Signed-off-by: Jim Quinlan <james.quinlan@broadcom.com>
> >> > Tested-by: Florian Fainelli <f.fainelli@gmail.com>
> >> > ---
> >> > 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;
> >>
> >> Nit: you could define an offset for the TIMEOUT register, if that makes
> >> it any cleaner, up to you.
> >>
> >> > + u32 timeout_us = 4000000; /* 4 seconds, our setting for L1SS */
> >>
> >> It would be useful to describe why this has to be 4 seconds in case
> >> someone in the future will have to change it.
> >
> > IIRC our customer requested 2s and we doubled it. Bjorn, can you
> > please add this comment or a paraphrase of it before applying --
> > I'm currently on vacation.
>
> Is the above request okay with you? What is the status of these
> commits -- will they be applied to pci-next in the near future?
The "brcm,enable-l1ss" DT property is either unnecessary or an
indication of a hardware defect in the controller.
Requiring the property is a terrible user experience, completely
antithetical to the PCI compatibility story, and per the conversation
at [1], there are no known problems that would occur if we ignored
"brcm,enable-l1ss" and always configured mode (c) ("Bidirectional
CLKREQ# for L1SS capable devices").
Even when configured as mode (c), L1SS is not *always* enabled. It's
certainly not enabled before ASPM init, and users can always disable
L1SS whenever they desire via the sysfs interfaces or pcie_aspm=off,
so if there's some problem with running in mode (c) with L1SS
disabled, we're still likely to see it.
But if you want to require the DT property, I guess it's mainly an
issue for you and your customers.
So to answer your question, yes, I'm OK with this series.
Bjorn
[1] https://lore.kernel.org/r/20230428223500.23337-2-jim2101024@gmail.com
> >> > + /* 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 {
WARNING: multiple messages have this Message-ID (diff)
From: Bjorn Helgaas <helgaas@kernel.org>
To: Jim Quinlan <james.quinlan@broadcom.com>
Cc: "Bjorn Helgaas" <bhelgaas@google.com>,
"open list:PCI NATIVE HOST BRIDGE AND ENDPOINT DRIVERS"
<linux-pci@vger.kernel.org>,
"Nicolas Saenz Julienne" <nsaenz@kernel.org>,
"Lorenzo Pieralisi" <lorenzo.pieralisi@arm.com>,
"Cyril Brulebois" <kibi@debian.org>,
"Phil Elwell" <phil@raspberrypi.com>,
"maintainer:BROADCOM BCM7XXX ARM ARCHITECTURE"
<bcm-kernel-feedback-list@broadcom.com>,
"Florian Fainelli" <f.fainelli@gmail.com>,
"Jim Quinlan" <jim2101024@gmail.com>,
"Krzysztof Wilczyński" <kw@linux.com>,
"Lorenzo Pieralisi" <lpieralisi@kernel.org>,
"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 v6 3/5] PCI: brcmstb: Set higher value for internal bus timeout
Date: Mon, 14 Aug 2023 17:06:58 -0500 [thread overview]
Message-ID: <20230814220658.GA193031@bhelgaas> (raw)
In-Reply-To: <CA+-6iNzKB4vMkM4Qt6781GN-WwzCCdUYY3o=stgPSjQyJPr6vQ@mail.gmail.com>
On Mon, Aug 14, 2023 at 03:30:07PM -0400, Jim Quinlan wrote:
> On Fri, Jul 28, 2023 at 12:15 PM Jim Quinlan <james.quinlan@broadcom.com> wrote:
> > On Thu, Jul 27, 2023, 10:44 PM Lorenzo Pieralisi <lpieralisi@kernel.org> wrote:
> >> On Fri, Jun 23, 2023 at 10:40:56AM -0400, Jim Quinlan wrote:
> >> > 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.
> >> >
> >> > Signed-off-by: Jim Quinlan <james.quinlan@broadcom.com>
> >> > Tested-by: Florian Fainelli <f.fainelli@gmail.com>
> >> > ---
> >> > 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;
> >>
> >> Nit: you could define an offset for the TIMEOUT register, if that makes
> >> it any cleaner, up to you.
> >>
> >> > + u32 timeout_us = 4000000; /* 4 seconds, our setting for L1SS */
> >>
> >> It would be useful to describe why this has to be 4 seconds in case
> >> someone in the future will have to change it.
> >
> > IIRC our customer requested 2s and we doubled it. Bjorn, can you
> > please add this comment or a paraphrase of it before applying --
> > I'm currently on vacation.
>
> Is the above request okay with you? What is the status of these
> commits -- will they be applied to pci-next in the near future?
The "brcm,enable-l1ss" DT property is either unnecessary or an
indication of a hardware defect in the controller.
Requiring the property is a terrible user experience, completely
antithetical to the PCI compatibility story, and per the conversation
at [1], there are no known problems that would occur if we ignored
"brcm,enable-l1ss" and always configured mode (c) ("Bidirectional
CLKREQ# for L1SS capable devices").
Even when configured as mode (c), L1SS is not *always* enabled. It's
certainly not enabled before ASPM init, and users can always disable
L1SS whenever they desire via the sysfs interfaces or pcie_aspm=off,
so if there's some problem with running in mode (c) with L1SS
disabled, we're still likely to see it.
But if you want to require the DT property, I guess it's mainly an
issue for you and your customers.
So to answer your question, yes, I'm OK with this series.
Bjorn
[1] https://lore.kernel.org/r/20230428223500.23337-2-jim2101024@gmail.com
> >> > + /* 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 {
_______________________________________________
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-08-14 22:07 UTC|newest]
Thread overview: 55+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-06-23 14:40 [PATCH v6 0/5] PCI: brcmstb: Configure appropriate HW CLKREQ# mode Jim Quinlan
2023-06-23 14:40 ` Jim Quinlan
2023-06-23 14:40 ` Jim Quinlan
2023-06-23 14:40 ` [PATCH v6 1/5] dt-bindings: PCI: brcmstb: Add brcm,enable-l1ss property Jim Quinlan
2023-06-23 14:40 ` Jim Quinlan
2023-08-21 14:46 ` Lorenzo Pieralisi
2023-08-21 14:46 ` Lorenzo Pieralisi
2023-08-21 15:25 ` Jim Quinlan
2023-08-21 15:25 ` Jim Quinlan
2023-08-21 15:41 ` Lorenzo Pieralisi
2023-08-21 15:41 ` Lorenzo Pieralisi
2023-08-21 16:01 ` Jim Quinlan
2023-08-21 16:01 ` Jim Quinlan
2023-08-23 7:30 ` Lorenzo Pieralisi
2023-08-23 7:30 ` Lorenzo Pieralisi
2023-08-23 12:42 ` Bjorn Helgaas
2023-08-23 12:42 ` Bjorn Helgaas
2023-08-23 15:02 ` Jim Quinlan
2023-08-23 15:02 ` Jim Quinlan
2023-08-23 14:48 ` Rob Herring
2023-08-23 14:48 ` Rob Herring
2023-08-23 16:29 ` Lorenzo Pieralisi
2023-08-23 16:29 ` Lorenzo Pieralisi
2023-08-23 18:26 ` Manivannan Sadhasivam
2023-08-23 18:26 ` Manivannan Sadhasivam
2023-08-24 15:19 ` Jim Quinlan
2023-08-24 15:19 ` Jim Quinlan
2023-06-23 14:40 ` [PATCH v6 2/5] PCI: brcmstb: Configure HW CLKREQ# mode appropriate for downstream device Jim Quinlan
2023-06-23 14:40 ` Jim Quinlan
2023-09-05 20:24 ` Sam Edwards
2023-09-05 20:24 ` Sam Edwards
2023-06-23 14:40 ` [PATCH v6 3/5] PCI: brcmstb: Set higher value for internal bus timeout Jim Quinlan
2023-06-23 14:40 ` Jim Quinlan
2023-07-28 8:43 ` Lorenzo Pieralisi
2023-07-28 8:43 ` Lorenzo Pieralisi
[not found] ` <CA+-6iNzuNZ0TGUvSKsq3outKnCBTkqtxygKOuM4=J-CPxcBb2g@mail.gmail.com>
2023-08-14 19:30 ` Jim Quinlan
2023-08-14 19:30 ` Jim Quinlan
2023-08-14 22:06 ` Bjorn Helgaas [this message]
2023-08-14 22:06 ` Bjorn Helgaas
2023-08-15 12:34 ` Jim Quinlan
2023-08-15 12:34 ` Jim Quinlan
2023-06-23 14:40 ` [PATCH v6 4/5] PCI: brcmstb: Assert PERST# on BCM2711 Jim Quinlan
2023-06-23 14:40 ` Jim Quinlan
2023-06-23 14:40 ` [PATCH v6 5/5] PCI: brcmstb: Remove stale comment Jim Quinlan
2023-06-23 14:40 ` Jim Quinlan
2023-06-29 1:59 ` [PATCH v6 0/5] PCI: brcmstb: Configure appropriate HW CLKREQ# mode Cyril Brulebois
2023-06-29 1:59 ` Cyril Brulebois
2023-08-21 8:34 ` Lorenzo Pieralisi
2023-08-21 8:34 ` Lorenzo Pieralisi
2023-08-21 12:15 ` Jim Quinlan
2023-08-21 12:15 ` Jim Quinlan
2023-08-21 14:42 ` Lorenzo Pieralisi
2023-08-21 14:42 ` Lorenzo Pieralisi
2023-08-24 15:36 ` (subset) " Lorenzo Pieralisi
2023-08-24 15:36 ` Lorenzo Pieralisi
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=20230814220658.GA193031@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: link
Be 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.