All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jim Quinlan <james.quinlan@broadcom.com>
To: Bjorn Helgaas <helgaas@kernel.org>
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:24:26 -0400	[thread overview]
Message-ID: <CA+-6iNwb6Cn-78BJ5URhwvDuYHg5b4X5h+WdMw-CB3nRs=pSYw@mail.gmail.com> (raw)
In-Reply-To: <20230430191323.GA388047@bhelgaas>

[-- Attachment #1: Type: text/plain, Size: 1411 bytes --]

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.

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?

Regards,
Jim

>
> Bjorn

[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 4210 bytes --]

WARNING: multiple messages have this Message-ID (diff)
From: Jim Quinlan <james.quinlan@broadcom.com>
To: Bjorn Helgaas <helgaas@kernel.org>
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:24:26 -0400	[thread overview]
Message-ID: <CA+-6iNwb6Cn-78BJ5URhwvDuYHg5b4X5h+WdMw-CB3nRs=pSYw@mail.gmail.com> (raw)
In-Reply-To: <20230430191323.GA388047@bhelgaas>


[-- Attachment #1.1: Type: text/plain, Size: 1411 bytes --]

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.

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?

Regards,
Jim

>
> Bjorn

[-- Attachment #1.2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 4210 bytes --]

[-- Attachment #2: Type: text/plain, Size: 176 bytes --]

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  reply	other threads:[~2023-04-30 21:24 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 [this message]
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 ` [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='CA+-6iNwb6Cn-78BJ5URhwvDuYHg5b4X5h+WdMw-CB3nRs=pSYw@mail.gmail.com' \
    --to=james.quinlan@broadcom.com \
    --cc=bcm-kernel-feedback-list@broadcom.com \
    --cc=bhelgaas@google.com \
    --cc=f.fainelli@gmail.com \
    --cc=helgaas@kernel.org \
    --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.