[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <VI1PR04MB5853728C0FD18D19901138048CFD9@VI1PR04MB5853.eurprd04.prod.outlook.com>
Date: Mon, 16 Aug 2021 07:49:52 +0000
From: Richard Zhu <hongxing.zhu@....com>
To: "khalasa@...p.pl" <khalasa@...p.pl>,
Bjorn Helgaas <helgaas@...nel.org>
CC: Krzysztof Wilczyński <kw@...ux.com>,
Bjorn Helgaas <bhelgaas@...gle.com>,
"linux-pci@...r.kernel.org" <linux-pci@...r.kernel.org>,
Artem Lapkin <email2tema@...il.com>,
Neil Armstrong <narmstrong@...libre.com>,
Huacai Chen <chenhuacai@...il.com>,
Rob Herring <robh@...nel.org>,
Lorenzo Pieralisi <lorenzo.pieralisi@....com>,
Lucas Stach <l.stach@...gutronix.de>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: RE: [PATCH] PCIe: limit Max Read Request Size on i.MX to 512 bytes
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@...p.pl <khalasa@...p.pl>
> Sent: Monday, August 16, 2021 1:19 PM
> To: Bjorn Helgaas <helgaas@...nel.org>
> Cc: Krzysztof Wilczyński <kw@...ux.com>; Bjorn Helgaas
> <bhelgaas@...gle.com>; linux-pci@...r.kernel.org; Artem Lapkin
> <email2tema@...il.com>; Neil Armstrong <narmstrong@...libre.com>;
> Huacai Chen <chenhuacai@...il.com>; Rob Herring <robh@...nel.org>;
> Lorenzo Pieralisi <lorenzo.pieralisi@....com>; Richard Zhu
> <hongxing.zhu@....com>; Lucas Stach <l.stach@...gutronix.de>;
> linux-kernel@...r.kernel.org
> Subject: Re: [PATCH] PCIe: limit Max Read Request Size on i.MX to 512 bytes
>
> Bjorn Helgaas <helgaas@...nel.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
Powered by blists - more mailing lists