Re: [PATCH v4 3/5] PCI: brcmstb: Set PCIe transaction completion timeout

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]


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@xxxxxxxxxx> 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

> 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.


[Index of Archives]     [DMA Engine]     [Linux Coverity]     [Linux USB]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [Greybus]

  Powered by Linux