linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Richard Zhu <hongxing.zhu@nxp.com>
To: "khalasa@piap.pl" <khalasa@piap.pl>, Bjorn Helgaas <helgaas@kernel.org>
Cc: "Krzysztof Wilczyński" <kw@linux.com>,
	"Bjorn Helgaas" <bhelgaas@google.com>,
	"linux-pci@vger.kernel.org" <linux-pci@vger.kernel.org>,
	"Artem Lapkin" <email2tema@gmail.com>,
	"Neil Armstrong" <narmstrong@baylibre.com>,
	"Huacai Chen" <chenhuacai@gmail.com>,
	"Rob Herring" <robh@kernel.org>,
	"Lorenzo Pieralisi" <lorenzo.pieralisi@arm.com>,
	"Lucas Stach" <l.stach@pengutronix.de>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: RE: [PATCH] PCIe: limit Max Read Request Size on i.MX to 512 bytes
Date: Mon, 16 Aug 2021 07:49:52 +0000	[thread overview]
Message-ID: <VI1PR04MB5853728C0FD18D19901138048CFD9@VI1PR04MB5853.eurprd04.prod.outlook.com> (raw)
In-Reply-To: <m3wnomynkm.fsf@t19.piap.pl>

Hi Krzysztof:
Regarding my understanding, that there should be decomposition operations if the
 Max_Read_Request_Size is larger than the Max_Payload_size specified by RC port.

The bit0 of AMBA Multiple Outbound Decomposed NP Sub-Requests Control Register(Offset:0x700 + 0x24)
 had been set to be 1b1 in default.

Note: The description of this bit.
Enable AMBA Multiple Outbound Decomposed NP Sub- Requests.
This bit when set to '0' disables the possibility of having multiple outstanding non-posted requests that
were derived from decomposition of an outbound AMBA request. See Supported AXI Burst Operations for
more details. You should not clear this register unless your application master is requesting an amount of read data
greater than Max_Read_Request_Size, and the remote device (or switch) is reordering completions that
have different tags

> -----Original Message-----
> From: khalasa@piap.pl <khalasa@piap.pl>
> Sent: Monday, August 16, 2021 1:19 PM
> To: Bjorn Helgaas <helgaas@kernel.org>
> Cc: Krzysztof Wilczyński <kw@linux.com>; Bjorn Helgaas
> <bhelgaas@google.com>; linux-pci@vger.kernel.org; Artem Lapkin
> <email2tema@gmail.com>; Neil Armstrong <narmstrong@baylibre.com>;
> Huacai Chen <chenhuacai@gmail.com>; Rob Herring <robh@kernel.org>;
> Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>; Richard Zhu
> <hongxing.zhu@nxp.com>; Lucas Stach <l.stach@pengutronix.de>;
> linux-kernel@vger.kernel.org
> Subject: Re: [PATCH] PCIe: limit Max Read Request Size on i.MX to 512 bytes
> 
> Bjorn Helgaas <helgaas@kernel.org> writes:
> 
> >> 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.
> 
> I meant there is always a limit - isn't Max_Read_Request_Size a limit?
> Device Control Register (Offset 08h) Bit Location 14:12
> Max_Read_Request_Size allows for max 4096 bytes, though two values are
> reserved, so there is room for some easy extension.
> 
> - non-ARM (non-DWC?) systems are limited to 4096 bytes
[Richard] Regarding to the descriptions listed above, I think that there should no limitations of the Max_payload_size of RC port.

> - DWC-based systems are limited to 128, 256, 512 bytes (are there
>   4096-byte ones?)
[Richard] The Max_payload_size can be configured from 128bytes to 4KB when integrate the DWC IP into the SOC.
On i.MX6 PCIe, this parameter is fixed set to 512 bytes.
BR
Richard
> 
> That's how I understand it, please correct me if I'm wrong.
> --
> Krzysztof "Chris" Hałasa
> 
> Sieć Badawcza Łukasiewicz
> Przemysłowy Instytut Automatyki i Pomiarów PIAP Al. Jerozolimskie 202,
> 02-486 Warszawa

  reply	other threads:[~2021-08-16  7:50 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-08-13  8:52 [PATCH] PCIe: limit Max Read Request Size on i.MX to 512 bytes 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
2021-08-16  5:18       ` Krzysztof Hałasa
2021-08-16  7:49         ` Richard Zhu [this message]
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:
  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=VI1PR04MB5853728C0FD18D19901138048CFD9@VI1PR04MB5853.eurprd04.prod.outlook.com \
    --to=hongxing.zhu@nxp.com \
    --cc=bhelgaas@google.com \
    --cc=chenhuacai@gmail.com \
    --cc=email2tema@gmail.com \
    --cc=helgaas@kernel.org \
    --cc=khalasa@piap.pl \
    --cc=kw@linux.com \
    --cc=l.stach@pengutronix.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=lorenzo.pieralisi@arm.com \
    --cc=narmstrong@baylibre.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 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).