From: Niklas Cassel <cassel@kernel.org>
To: Shawn Lin <shawn.lin@rock-chips.com>
Cc: Hans Zhang <18255117159@163.com>,
lpieralisi@kernel.org, kw@linux.com, bhelgaas@google.com,
heiko@sntech.de, manivannan.sadhasivam@linaro.org,
robh@kernel.org, jingoohan1@gmail.com,
thomas.richard@bootlin.com, linux-pci@vger.kernel.org,
linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-rockchip@lists.infradead.org
Subject: Re: [PATCH] PCI: dw-rockchip: Configure max payload size on host init
Date: Thu, 17 Apr 2025 09:22:12 +0200 [thread overview]
Message-ID: <aACsJPkSDOHbRAJM@ryzen> (raw)
In-Reply-To: <85643fe4-c7df-4d64-e852-60b66892470a@rock-chips.com>
On Thu, Apr 17, 2025 at 03:08:34PM +0800, Shawn Lin wrote:
> 在 2025/04/17 星期四 15:04, Niklas Cassel 写道:
> > Hello Hans,
> >
> > On Wed, Apr 16, 2025 at 11:19:26PM +0800, Hans Zhang wrote:
> > > The RK3588's PCIe controller defaults to a 128-byte max payload size,
> > > but its hardware capability actually supports 256 bytes. This results
> > > in suboptimal performance with devices that support larger payloads.
> >
> > Patch looks good to me, but please always reference the TRM when you can.
> >
> > Before this patch:
> > DevCap: MaxPayload 256 bytes
> > DevCtl: MaxPayload 128 bytes
> >
> >
> > As per rk3588 TRM, section "11.4.3.8 DSP_PCIE_CAP Detail Registers Description"
> >
> > DevCap is per the register description of DSP_PCIE_CAP_DEVICE_CAPABILITIES_REG,
> > field PCIE_CAP_MAX_PAYLOAD_SIZE.
> > Which claims that the value after reset is 0x1 (256B).
> >
> > DevCtl is per the register description of
> > DSP_PCIE_CAP_DEVICE_CONTROL_DEVICE_STATUS, field PCIE_CAP_MAX_PAYLOAD_SIZE_CS.
> > Which claims that the reset value is 0x0 (128B).
> >
> > Both of these match the values above.
> >
> > As per the description of PCIE_CAP_MAX_PAYLOAD_SIZE_CS:
> > "Permissible values that
> > can be programmed are indicated by the Max_Payload_Size
> > Supported field (PCIE_CAP_MAX_PAYLOAD_SIZE) in the Device
> > Capabilities (DEVICE_CAPABILITIES_REG) register (for more
> > details, see section 7.5.3.3 of PCI Express Base Specification)."
> >
> > So your patch looks good.
> >
> > I guess I'm mostly surprised that the e.g. pci_configure_mps() does not
> > already set DevCtl to the max(DevCap.MPS of the host, DevCap.MPS of the
> > endpoint).
> >
> > Apparently pci_configure_mps() only decreases MPS from the reset values?
> > It never increases it?
> >
>
> Actually it does:
>
> https://github.com/torvalds/linux/blob/master/Documentation/admin-guide/kernel-parameters.txt#L4757
If that is the case, then explain the before/after with Hans lspci output here:
https://lore.kernel.org/linux-pci/bb40385c-6839-484c-90b2-d6c7ecb95ba9@163.com/
His patch changes the default value of DevCtl.MPS (from 128B to 256B), but if
pci_configure_mps() can bump DevCtl.MPS to a higher value, his patch should not
be needed, since the EP (an NVMe SSD in his case) has DevCap.MPS 512B, and the
RC itself has DevCap.MPS 256B.
Seems like we are missing something here.
Kind regards,
Niklas
next prev parent reply other threads:[~2025-04-17 7:24 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-04-16 15:19 [PATCH] PCI: dw-rockchip: Configure max payload size on host init Hans Zhang
2025-04-16 20:40 ` Bjorn Helgaas
2025-04-17 2:19 ` Hans Zhang
2025-04-17 6:01 ` Niklas Cassel
2025-04-17 6:47 ` Hans Zhang
2025-04-17 6:53 ` Niklas Cassel
2025-04-17 7:04 ` Niklas Cassel
2025-04-17 7:08 ` Shawn Lin
2025-04-17 7:22 ` Niklas Cassel [this message]
2025-04-17 7:25 ` Shawn Lin
2025-04-17 7:48 ` Niklas Cassel
2025-04-17 8:07 ` Hans Zhang
2025-04-17 8:39 ` Niklas Cassel
2025-04-17 9:48 ` Hans Zhang
2025-04-17 9:54 ` Niklas Cassel
2025-04-17 16:52 ` Bjorn Helgaas
2025-04-18 12:33 ` Hans Zhang
2025-04-18 14:55 ` Niklas Cassel
2025-04-18 16:21 ` Bjorn Helgaas
2025-04-18 17:21 ` Hans Zhang
2025-04-21 14:53 ` Manivannan Sadhasivam
2025-04-21 15:59 ` Hans Zhang
2025-04-21 14:48 ` Manivannan Sadhasivam
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=aACsJPkSDOHbRAJM@ryzen \
--to=cassel@kernel.org \
--cc=18255117159@163.com \
--cc=bhelgaas@google.com \
--cc=heiko@sntech.de \
--cc=jingoohan1@gmail.com \
--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-rockchip@lists.infradead.org \
--cc=lpieralisi@kernel.org \
--cc=manivannan.sadhasivam@linaro.org \
--cc=robh@kernel.org \
--cc=shawn.lin@rock-chips.com \
--cc=thomas.richard@bootlin.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