LKML Archive on
help / color / mirror / Atom feed
From: Bjorn Helgaas <>
To: "Krzysztof Hałasa" <>
Cc: "Krzysztof Wilczyński" <>,
	"Bjorn Helgaas" <>,, "Artem Lapkin" <>,
	"Neil Armstrong" <>,
	"Huacai Chen" <>,
	"Rob Herring" <>,
	"Lorenzo Pieralisi" <>,
	"Richard Zhu" <>,
	"Lucas Stach" <>,
Subject: Re: [PATCH] PCIe: limit Max Read Request Size on i.MX to 512 bytes
Date: Fri, 13 Aug 2021 14:22:54 -0500	[thread overview]
Message-ID: <20210813192254.GA2604116@bjorn-Precision-5520> (raw)
In-Reply-To: <>

On Fri, Aug 13, 2021 at 02:09:51PM +0200, Krzysztof Hałasa wrote:
> Krzysztof, :-)
> > Would it be possible to implement this particular MRRS fix as a quirk
> > only for the i.MX6 controller?  Unless this is something that we need in
> > the core, a quirk would be preferred over something that changes the PCI
> > core.
> I have briefly considered it, but I think it would be *much* more
> complicated and error-prone. It also appears that there are more
> platforms which need it - the old CNS3xxx, which currently subverts the
> PCIE_BUS_PEER2PEER, the loongson, keystone, maybe all DWC PCIe.
> Multiplication of the "quirk" code doesn't really look good to me.
> TBH I don't think of this as of a "quirk" - all systems have MRRS
> limits, it just happens that these ones have their limit lower than 4096
> bytes. This isn't a limitation of a particular PCIe device, this is a
> common limit of the whole system.

Do you have a reference for this?  I don't see anything in the PCIe
spec that suggests platforms must limit MRRS, and it seems that only
these ARM-related controllers have this issue.  If there *is* a
platform connection here, we'll need some way to discover it, e.g.,
an ACPI _DSM method or similar.

The only guidance in the spec about setting MRRS is that:

  - Software must set Max_Read_Request_Size of an
    isochronous-configured device with a value that does not exceed
    the Max_Payload_Size set for the device (PCIe r5.0, sec

  - The Max_Read_Request_Size mechanism allows improved control of
    bandwidth allocation in systems where Quality of Service (QoS) is
    important for the target applications. For example, an arbitration
    scheme based on counting Requests (and not the sizes of those
    Requests) provides imprecise bandwidth allocation when some
    Requesters use much larger sizes than others. The
    Max_Read_Request_Size mechanism can be used to force more uniform
    allocation of bandwidth, by restricting the upper size of Read
    Requests (sec implementation note)

  reply	other threads:[~2021-08-13 19:22 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-08-13  8:52 Krzysztof Hałasa
2021-08-13 10:13 ` Krzysztof Wilczyński
2021-08-13 12:09   ` Krzysztof Hałasa
2021-08-13 19:22     ` Bjorn Helgaas [this message]
2021-08-16  5:18       ` Krzysztof Hałasa
2021-08-16  7:49         ` Richard Zhu
2021-08-16 11:18           ` Krzysztof Hałasa
2021-08-13 13:45 ` Rob Herring
2021-08-13 18:18   ` Krzysztof Hałasa

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:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20210813192254.GA2604116@bjorn-Precision-5520 \ \ \ \ \ \ \ \ \ \ \ \ \ \
    --subject='Re: [PATCH] PCIe: limit Max Read Request Size on i.MX to 512 bytes' \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).