linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Neil Armstrong <narmstrong@baylibre.com>
To: Bjorn Helgaas <helgaas@kernel.org>
Cc: "Art Nikpal" <email2tema@gmail.com>,
	"Huacai Chen" <chenhuacai@gmail.com>,
	陈华才 <chenhuacai@loongson.cn>, "Yue Wang" <yue.wang@amlogic.com>,
	"Kevin Hilman" <khilman@baylibre.com>,
	"Lorenzo Pieralisi" <lorenzo.pieralisi@arm.com>,
	"Rob Herring" <robh@kernel.org>,
	"Krzysztof Wilczynski" <kw@linux.com>,
	"Jerome Brunet" <jbrunet@baylibre.com>,
	"Christian Hewitt" <christianshewitt@gmail.com>,
	"Martin Blumenstingl" <martin.blumenstingl@googlemail.com>,
	PCI <linux-pci@vger.kernel.org>,
	linux-arm-kernel <linux-arm-kernel@lists.infradead.org>,
	"open list:ARM/Amlogic Meson..."
	<linux-amlogic@lists.infradead.org>,
	LKML <linux-kernel@vger.kernel.org>,
	"Artem Lapkin" <art@khadas.com>, "Nick Xie" <nick@khadas.com>,
	"Gouwa Wang" <gouwa@khadas.com>
Subject: Re: [PATCH 0/4] PCI: replace dublicated MRRS limit quirks
Date: Wed, 7 Jul 2021 18:43:13 +0200	[thread overview]
Message-ID: <aab7db4a-df1f-280b-73d7-799161528fa2@baylibre.com> (raw)
In-Reply-To: <20210707155418.GA897940@bjorn-Precision-5520>

Hi,

On 07/07/2021 17:54, Bjorn Helgaas wrote:
> On Tue, Jul 06, 2021 at 11:54:05AM +0200, Neil Armstrong wrote:
>> In their Designware PCIe controller driver, amlogic sets the
>> Max_Payload_Size & Max_Read_Request_Size to 256:
>> https://elixir.bootlin.com/linux/latest/source/drivers/pci/controller/dwc/pci-meson.c#L260
>> https://elixir.bootlin.com/linux/latest/source/drivers/pci/controller/dwc/pci-meson.c#L276
>> in their root port PCIe Express Device Control Register.
>>
>> Looking at the Synopsys DW-PCIe Databook, Max_Payload_Size &
>> Max_Read_Request_Size are used to decompose into AXI burst, but it
>> seems the Max_Payload_Size & Max_Read_Request_Size are set by
>> default to 512 but the internal Max_Payload_Size_Supported is set to
>> 256, thus changing these values to 256 at runtime to match and
>> optimize bandwidth.
>>
>> It's said, "Reducing Outbound Decomposition" :
>>  - "Ensure that your application master does not generate bursts of
>>    size greater than or equal to Max_Payload_Size"
>>
>>  - "Program your PCIe system with a larger value of Max_Payload_Size
>>    without exceeding Max_Payload_Size_Supported"
>>
>>  - "Program your PCIe system with a larger value of Max_Read_Request
>>    without exceeding Max_Payload_Size_Supported:
>>
>> So leaving 512 in Max_Payload_Size & Max_Read_Request leads to
>> Outbound Decomposition which decreases PCIe link and degrades the
>> AXI bus by doubling the bursts, leading to this fix to avoid
>> overflowing the AXI bus.
>>
>> So it seems to be still needed, I assume this *should* be handled in
>> the core somehow to propagate these settings to child endpoints to
>> match the root port Max_Payload_Size & Max_Read_Request sizes.
>>
>> Maybe by adding a core function to set these values instead of using
>> the dw_pcie_find_capability() & dw_pcie_write/readl_dbi() helpers
>> and set a state on the root port to propagate the value ?
> 
> I don't have the Synopsys DW-PCIe Databook, so I'm lacking any
> context.  The above *seems* to say that MPS/MRRS settings affect AXI
> bus usage.

It does when the TLPs are directed to the RC.

> 
> The MPS and MRRS registers are defined to affect traffic on *PCIe*.  If
> a platform uses MPS and MRRS values to optimize transfers on non-PCIe
> links, that's a problem because the PCI core code that manages MPS and
> MRRS has no knowledge of those non-PCIe parts of the system.

Yes and no, it only affects PCIe in P2P, in non-P2P is will certainly affect
transfers on the internal SoC/Processor/Chip internal bus/fabric.

> You might be able to deal with this in Synopsys-specific code somehow,
> but it's going to be a bit of a hassle because I don't want it to make
> maintenance of the generic MPS/MRRS code harder.

I understand, but this is why these quirks are currently implemented in the
controller driver and only applies when the controller has been probed
and to each endpoint detected on this particular controller.

So we may continue having separate quirks for each controller if the core
isn't the right place to handle MPS/MRRS.

Neil

> Bjorn
> 


  reply	other threads:[~2021-07-07 16:43 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-06-19  6:39 [PATCH 0/4] PCI: replace dublicated MRRS limit quirks Artem Lapkin
2021-06-19  6:39 ` [PATCH 1/4] PCI: move Keystone and Loongson device IDs to pci_ids Artem Lapkin
2021-06-19  6:39 ` [PATCH 2/4] PCI: core: quirks: add mrrs_limit_quirk Artem Lapkin
2021-07-01 17:07   ` Rob Herring
2021-06-19  6:39 ` [PATCH 3/4] PCI: keystone move mrrs quirk to core Artem Lapkin
2021-06-19  6:39 ` [PATCH 4/4] PCI: loongson " Artem Lapkin
2021-07-01 15:46 ` [PATCH 0/4] PCI: replace dublicated MRRS limit quirks Bjorn Helgaas
2021-07-02  1:15   ` 陈华才
2021-07-05  8:35     ` Art Nikpal
2021-07-05 22:34       ` Krzysztof Wilczynski
2021-07-06  1:36       ` Huacai Chen
2021-07-06  6:06         ` Art Nikpal
2021-07-06  9:54           ` Neil Armstrong
2021-07-07 15:54             ` Bjorn Helgaas
2021-07-07 16:43               ` Neil Armstrong [this message]
2021-07-07 16:57                 ` Bjorn Helgaas
2021-07-07 17:21                   ` Bjorn Helgaas
2021-07-12  9:08                   ` Art Nikpal

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=aab7db4a-df1f-280b-73d7-799161528fa2@baylibre.com \
    --to=narmstrong@baylibre.com \
    --cc=art@khadas.com \
    --cc=chenhuacai@gmail.com \
    --cc=chenhuacai@loongson.cn \
    --cc=christianshewitt@gmail.com \
    --cc=email2tema@gmail.com \
    --cc=gouwa@khadas.com \
    --cc=helgaas@kernel.org \
    --cc=jbrunet@baylibre.com \
    --cc=khilman@baylibre.com \
    --cc=kw@linux.com \
    --cc=linux-amlogic@lists.infradead.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=lorenzo.pieralisi@arm.com \
    --cc=martin.blumenstingl@googlemail.com \
    --cc=nick@khadas.com \
    --cc=robh@kernel.org \
    --cc=yue.wang@amlogic.com \
    /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).