From: Bjorn Helgaas <helgaas@kernel.org> To: Jim Quinlan <james.quinlan@broadcom.com> Cc: "Jim Quinlan" <jim2101024@gmail.com>, 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, "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 v4 3/5] PCI: brcmstb: Set PCIe transaction completion timeout Date: Sun, 30 Apr 2023 17:38:49 -0500 [thread overview] Message-ID: <20230430223849.GA528725@bhelgaas> (raw) In-Reply-To: <CA+-6iNwb6Cn-78BJ5URhwvDuYHg5b4X5h+WdMw-CB3nRs=pSYw@mail.gmail.com> On Sun, Apr 30, 2023 at 05:24:26PM -0400, Jim Quinlan wrote: > On Sun, Apr 30, 2023 at 3:13 PM Bjorn Helgaas <helgaas@kernel.org> wrote: > > On Fri, Apr 28, 2023 at 06:34:57PM -0400, Jim Quinlan wrote: > > > Since the STB PCIe HW will cause a CPU abort on a PCIe transaction > > > completion timeout abort, we might as well extend the default timeout > > > limit. Further, different devices and systems may requires a larger or > > > smaller amount commensurate with their L1SS exit time, so the property > > > "brcm,completion-timeout-us" may be used to set a custom timeout value. > > > > s/requires/require/ > > > > AFAIK, other platforms do not tweak Configuration Timeout values based > > on L1SS exit time. Why is brcm different? > > Keep in mind that our Brcm PCIe HW signals a CPU abort on a PCIe > completion timeout. Other PCIe HW just returns 0xffffffff. Most does, but I'm pretty sure there are other controllers used on arm64 that signal CPU aborts, e.g., imx6q_pcie_abort_handler() seems similar. > I've been maintaining this driver for over eight years or so and we've > done fine with the HW default completion timeout value. > Only recently has a major customer requested that this timeout value > be changed, and their reason was so they could > avoid a CPU abort when using L1SS. > > Now we could set this value to a big number for all cases and not > require "brcm,completion-timeout-us". I cannot see any > downsides, other than another customer coming along asking us to > double the default or lessen it. > > But I'm certainly willing to do that -- would that be acceptable? That would be fine with me. Bjorn
WARNING: multiple messages have this Message-ID (diff)
From: Bjorn Helgaas <helgaas@kernel.org> To: Jim Quinlan <james.quinlan@broadcom.com> Cc: "Jim Quinlan" <jim2101024@gmail.com>, 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, "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 v4 3/5] PCI: brcmstb: Set PCIe transaction completion timeout Date: Sun, 30 Apr 2023 17:38:49 -0500 [thread overview] Message-ID: <20230430223849.GA528725@bhelgaas> (raw) In-Reply-To: <CA+-6iNwb6Cn-78BJ5URhwvDuYHg5b4X5h+WdMw-CB3nRs=pSYw@mail.gmail.com> On Sun, Apr 30, 2023 at 05:24:26PM -0400, Jim Quinlan wrote: > On Sun, Apr 30, 2023 at 3:13 PM Bjorn Helgaas <helgaas@kernel.org> wrote: > > On Fri, Apr 28, 2023 at 06:34:57PM -0400, Jim Quinlan wrote: > > > Since the STB PCIe HW will cause a CPU abort on a PCIe transaction > > > completion timeout abort, we might as well extend the default timeout > > > limit. Further, different devices and systems may requires a larger or > > > smaller amount commensurate with their L1SS exit time, so the property > > > "brcm,completion-timeout-us" may be used to set a custom timeout value. > > > > s/requires/require/ > > > > AFAIK, other platforms do not tweak Configuration Timeout values based > > on L1SS exit time. Why is brcm different? > > Keep in mind that our Brcm PCIe HW signals a CPU abort on a PCIe > completion timeout. Other PCIe HW just returns 0xffffffff. Most does, but I'm pretty sure there are other controllers used on arm64 that signal CPU aborts, e.g., imx6q_pcie_abort_handler() seems similar. > I've been maintaining this driver for over eight years or so and we've > done fine with the HW default completion timeout value. > Only recently has a major customer requested that this timeout value > be changed, and their reason was so they could > avoid a CPU abort when using L1SS. > > Now we could set this value to a big number for all cases and not > require "brcm,completion-timeout-us". I cannot see any > downsides, other than another customer coming along asking us to > double the default or lessen it. > > But I'm certainly willing to do that -- would that be acceptable? That would be fine with me. 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-30 22:38 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 [this message] 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 ` [PATCH v4 4/5] PCI: brcmstb: Don't assume 2711 bootloader leaves PERST# asserted Jim Quinlan 2023-04-28 22:34 ` 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=20230430223849.GA528725@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.