From nobody Mon Feb 9 09:35:05 2026 Received: from m16.mail.163.com (m16.mail.163.com [220.197.31.3]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 68A412356D0; Sat, 10 May 2025 15:57:15 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=220.197.31.3 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1746892639; cv=none; b=uaX0a0HvrrhVPD1cSCHvwoPTktXDvOA0XlOiVV78Wa9SYF3fuoZIgwnZ73ZG/ipBNvTHYT0vf62bTtmI0gemfXw1sBRDViOODbq8WD0vWY95bLoEtae1VS0KaL618IWccGcLgz9KP14aMr7983t8hNMfaeywW5uDSa7+8R/nHYU= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1746892639; c=relaxed/simple; bh=Th4wjNWotwdbEtbNrNTOq3O36Clo9NwxnFQYmWYaNMA=; h=From:To:Cc:Subject:Date:Message-Id:In-Reply-To:References: MIME-Version; b=suUDgDdW2888IGvbcdsZaAyH2mL8VOsbAe0WK3AYCYPNBh+8sf67MAm+DwH+5m4fxl0oYjEftVGmagGkinhFGYverp4G0JcKliTyvNRlFMswck9pMY9TLChYeL+nvCVwGkUAN5NdYsy5if5mVXrOaafgpRCYGIoeoyw8f9y7jQ0= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=163.com; spf=pass smtp.mailfrom=163.com; dkim=pass (1024-bit key) header.d=163.com header.i=@163.com header.b=GgdHW93t; arc=none smtp.client-ip=220.197.31.3 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=163.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=163.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=163.com header.i=@163.com header.b="GgdHW93t" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=163.com; s=s110527; h=From:To:Subject:Date:Message-Id:MIME-Version; bh=rt Q9WMCTmJv+q//MSyeDx5RtHg7RmBudAr1AhWxe120=; b=GgdHW93tUx77vORi6x qW3SWpBZzIQzA640G4HC/eJr+guTwrSZ56s/WKUQJ4dFtd25xbmMjYQJ8ySP9LTh VIZDtAi6xtj9o13MDLozc2EkxpXhOt0YipS+diVVKeKB6pHv368tH+34QX35nWXX LadrG+oUr7BxwmPcT4JV2lwCc= Received: from localhost.localdomain (unknown []) by gzga-smtp-mtada-g0-2 (Coremail) with SMTP id _____wDXjxsYdx9ormDlAQ--.43845S3; Sat, 10 May 2025 23:56:10 +0800 (CST) From: Hans Zhang <18255117159@163.com> To: lpieralisi@kernel.org, kw@linux.com, bhelgaas@google.com, heiko@sntech.de, manivannan.sadhasivam@linaro.org, yue.wang@Amlogic.com Cc: pali@kernel.org, neil.armstrong@linaro.org, robh@kernel.org, jingoohan1@gmail.com, khilman@baylibre.com, jbrunet@baylibre.com, martin.blumenstingl@googlemail.com, linux-pci@vger.kernel.org, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-amlogic@lists.infradead.org, linux-rockchip@lists.infradead.org, Hans Zhang <18255117159@163.com>, Niklas Cassel Subject: [PATCH v4 1/2] PCI: Configure root port MPS during host probing Date: Sat, 10 May 2025 23:56:06 +0800 Message-Id: <20250510155607.390687-2-18255117159@163.com> X-Mailer: git-send-email 2.25.1 In-Reply-To: <20250510155607.390687-1-18255117159@163.com> References: <20250510155607.390687-1-18255117159@163.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-CM-TRANSID: _____wDXjxsYdx9ormDlAQ--.43845S3 X-Coremail-Antispam: 1Uf129KBjvJXoWxWw4xWw4rWF4kKr48uFW5GFg_yoWruw1rpa y3XFWSyrZ7GF1fWan3Ja109r15trsav343trZxGw1ruw15AFy8KrWaya1rJas7GrZ7ZFyY vr90qry8uan5ZFJanT9S1TB71UUUUU7qnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDUYxBIdaVFxhVjvjDU0xZFpf9x0pEwZ25UUUUU= X-CM-SenderInfo: rpryjkyvrrlimvzbiqqrwthudrp/1tbiOhNJo2gfbZ-YXQABsC Content-Type: text/plain; charset="utf-8" Current PCIe initialization logic may leave root ports operating with non-optimal Maximum Payload Size (MPS) settings. While downstream device configuration is handled during bus enumeration, root port MPS values inherited from firmware or hardware defaults might not utilize the full capabilities supported by the controller hardware. This can result is uboptimal data transfer efficiency across the PCIe hierarchy. During host controller probing phase, when PCIe bus tuning is enabled, the implementation now configures root port MPS settings to their hardware-supported maximum values. By iterating through bridge devices under the root bus and identifying PCIe root ports, each port's MPS is set to 128 << pcie_mpss to match the device's maximum supported payload size. The Max Read Request Size (MRRS) is subsequently adjusted through existing companion logic to maintain compatibility with PCIe specifications. Explicit initialization at host probing stage ensures consistent PCIe topology configuration before downstream devices perform their own MPS negotiations. This proactive approach addresses platform-specific requirements where controller drivers depend on properly initialized root port settings, while maintaining backward compatibility through PCIE_BUS_TUNE_OFF conditional checks. Hardware capabilities are fully utilized without altering existing device negotiation behaviors. Suggested-by: Niklas Cassel Signed-off-by: Hans Zhang <18255117159@163.com> Reviewed-by: Niklas Cassel --- drivers/pci/probe.c | 72 ++++++++++++++++++++++++++------------------- 1 file changed, 41 insertions(+), 31 deletions(-) diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c index 364fa2a514f8..1f67c03d170a 100644 --- a/drivers/pci/probe.c +++ b/drivers/pci/probe.c @@ -2149,6 +2149,37 @@ int pci_setup_device(struct pci_dev *dev) return 0; } =20 +static void pcie_write_mps(struct pci_dev *dev, int mps) +{ + int rc; + + if (pcie_bus_config =3D=3D PCIE_BUS_PERFORMANCE) { + mps =3D 128 << dev->pcie_mpss; + + if (pci_pcie_type(dev) !=3D PCI_EXP_TYPE_ROOT_PORT && + dev->bus->self) + + /* + * For "Performance", the assumption is made that + * downstream communication will never be larger than + * the MRRS. So, the MPS only needs to be configured + * for the upstream communication. This being the case, + * walk from the top down and set the MPS of the child + * to that of the parent bus. + * + * Configure the device MPS with the smaller of the + * device MPSS or the bridge MPS (which is assumed to be + * properly configured at this point to the largest + * allowable MPS based on its parent bus). + */ + mps =3D min(mps, pcie_get_mps(dev->bus->self)); + } + + rc =3D pcie_set_mps(dev, mps); + if (rc) + pci_err(dev, "Failed attempting to set the MPS\n"); +} + static void pci_configure_mps(struct pci_dev *dev) { struct pci_dev *bridge =3D pci_upstream_bridge(dev); @@ -2178,6 +2209,16 @@ static void pci_configure_mps(struct pci_dev *dev) return; } =20 + /* + * Unless MPS strategy is PCIE_BUS_TUNE_OFF (don't touch MPS at all), + * start off by setting root ports' MPS to MPSS. Depending on the MPS + * strategy, and the MPSS of the devices below the root port, the MPS + * of the root port might get overridden later. + */ + if (pci_pcie_type(dev) =3D=3D PCI_EXP_TYPE_ROOT_PORT && + pcie_bus_config !=3D PCIE_BUS_TUNE_OFF) + pcie_write_mps(dev, 128 << dev->pcie_mpss); + if (!bridge || !pci_is_pcie(bridge)) return; =20 @@ -2875,37 +2916,6 @@ static int pcie_find_smpss(struct pci_dev *dev, void= *data) return 0; } =20 -static void pcie_write_mps(struct pci_dev *dev, int mps) -{ - int rc; - - if (pcie_bus_config =3D=3D PCIE_BUS_PERFORMANCE) { - mps =3D 128 << dev->pcie_mpss; - - if (pci_pcie_type(dev) !=3D PCI_EXP_TYPE_ROOT_PORT && - dev->bus->self) - - /* - * For "Performance", the assumption is made that - * downstream communication will never be larger than - * the MRRS. So, the MPS only needs to be configured - * for the upstream communication. This being the case, - * walk from the top down and set the MPS of the child - * to that of the parent bus. - * - * Configure the device MPS with the smaller of the - * device MPSS or the bridge MPS (which is assumed to be - * properly configured at this point to the largest - * allowable MPS based on its parent bus). - */ - mps =3D min(mps, pcie_get_mps(dev->bus->self)); - } - - rc =3D pcie_set_mps(dev, mps); - if (rc) - pci_err(dev, "Failed attempting to set the MPS\n"); -} - static void pcie_write_mrrs(struct pci_dev *dev) { int rc, mrrs; --=20 2.25.1 From nobody Mon Feb 9 09:35:05 2026 Received: from m16.mail.163.com (m16.mail.163.com [220.197.31.2]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 6B7C71F0982; Sat, 10 May 2025 15:57:10 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=220.197.31.2 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1746892635; cv=none; b=E3SpXh+bUMbotVUCfIt/9hRVnYDlLs7IJXXcW1802Qa1lDy59INkt/80idvXWSF2E7CoWn3qSTTKkZAzbyq+yTpPZ8uDHBkJrwIFhDlNErjqNmZqs+QJsaWlKzXY+ZMVUgGflyJRyW+EPvDC33a7U46YN6mSwX3PoarFGn6+D7o= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1746892635; c=relaxed/simple; bh=YbY4BzhwwS0Bs97W2qpZD/tuPkcUHS6xrK4/be/t7fU=; h=From:To:Cc:Subject:Date:Message-Id:In-Reply-To:References: MIME-Version; b=KIR3aiVSXGfEI2IUr5KbeJpr6G0rPGIU7bBDyrUK41YvTU+qB5Poy5T/Gv3r7oR9d81sngdOcuQzd+YS5r8bHDVdSqp+5iXj/LyAndPyO64yXxW1krjNwNDvRIINs+ooSXOOr9rs4cyhP3+gWRAQPGewF3DtSCR5q31SO23PPoo= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=163.com; spf=pass smtp.mailfrom=163.com; dkim=pass (1024-bit key) header.d=163.com header.i=@163.com header.b=GEqct7cD; arc=none smtp.client-ip=220.197.31.2 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=163.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=163.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=163.com header.i=@163.com header.b="GEqct7cD" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=163.com; s=s110527; h=From:To:Subject:Date:Message-Id:MIME-Version; bh=E2 ofUgHGCmm1xPAFMa2TsfZAr9ZO/RTFbitpv1wF7q0=; b=GEqct7cD2x6TeWs/1+ CvwrTM6aZ8kOl3lZkymWL5+X6StJ8S0xqQh9WK87mgeWKH8YpkaXSmti1EuPmo+z +uNcZW3XP4YXMi40xmCQP4EfRwI9DOfMzN92NFxcwa+PpzF2N3uUXaaYqRQcmhjm LWAmx7cihinHZg9/S++j1u+wk= Received: from localhost.localdomain (unknown []) by gzga-smtp-mtada-g0-2 (Coremail) with SMTP id _____wDXjxsYdx9ormDlAQ--.43845S4; Sat, 10 May 2025 23:56:11 +0800 (CST) From: Hans Zhang <18255117159@163.com> To: lpieralisi@kernel.org, kw@linux.com, bhelgaas@google.com, heiko@sntech.de, manivannan.sadhasivam@linaro.org, yue.wang@Amlogic.com Cc: pali@kernel.org, neil.armstrong@linaro.org, robh@kernel.org, jingoohan1@gmail.com, khilman@baylibre.com, jbrunet@baylibre.com, martin.blumenstingl@googlemail.com, linux-pci@vger.kernel.org, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-amlogic@lists.infradead.org, linux-rockchip@lists.infradead.org, Hans Zhang <18255117159@163.com> Subject: [PATCH v4 2/2] PCI: dwc: Remove redundant MPS configuration Date: Sat, 10 May 2025 23:56:07 +0800 Message-Id: <20250510155607.390687-3-18255117159@163.com> X-Mailer: git-send-email 2.25.1 In-Reply-To: <20250510155607.390687-1-18255117159@163.com> References: <20250510155607.390687-1-18255117159@163.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-CM-TRANSID: _____wDXjxsYdx9ormDlAQ--.43845S4 X-Coremail-Antispam: 1Uf129KBjvJXoW7KF4xuw4xXFWDJw43WF4xtFb_yoW8Cr1fpF y3Xrsa9F18Jr45WF4qkan5Cay3tasxCry7JF9Ig3yfuFyayFsrXa4ayFWSkFyxXrW293WS kr98K3y8C3W5trUanT9S1TB71UUUUU7qnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDUYxBIdaVFxhVjvjDU0xZFpf9x0z_rWrfUUUUU= X-CM-SenderInfo: rpryjkyvrrlimvzbiqqrwthudrp/1tbiOhNJo2gfbZ-YXQADsA Content-Type: text/plain; charset="utf-8" The Meson PCIe controller driver manually configures maximum payload size (MPS) through meson_set_max_payload, duplicating functionality now centralized in the PCI core. Deprecating redundant code simplifies the driver and aligns it with the consolidated MPS management strategy, improving long-term maintainability. Signed-off-by: Hans Zhang <18255117159@163.com> Reviewed-by: Niklas Cassel --- drivers/pci/controller/dwc/pci-meson.c | 17 ----------------- 1 file changed, 17 deletions(-) diff --git a/drivers/pci/controller/dwc/pci-meson.c b/drivers/pci/controlle= r/dwc/pci-meson.c index db9482a113e9..126f38ed453d 100644 --- a/drivers/pci/controller/dwc/pci-meson.c +++ b/drivers/pci/controller/dwc/pci-meson.c @@ -261,22 +261,6 @@ static int meson_size_to_payload(struct meson_pcie *mp= , int size) return fls(size) - 8; } =20 -static void meson_set_max_payload(struct meson_pcie *mp, int size) -{ - struct dw_pcie *pci =3D &mp->pci; - u32 val; - u16 offset =3D dw_pcie_find_capability(pci, PCI_CAP_ID_EXP); - int max_payload_size =3D meson_size_to_payload(mp, size); - - val =3D dw_pcie_readl_dbi(pci, offset + PCI_EXP_DEVCTL); - val &=3D ~PCI_EXP_DEVCTL_PAYLOAD; - dw_pcie_writel_dbi(pci, offset + PCI_EXP_DEVCTL, val); - - val =3D dw_pcie_readl_dbi(pci, offset + PCI_EXP_DEVCTL); - val |=3D PCIE_CAP_MAX_PAYLOAD_SIZE(max_payload_size); - dw_pcie_writel_dbi(pci, offset + PCI_EXP_DEVCTL, val); -} - static void meson_set_max_rd_req_size(struct meson_pcie *mp, int size) { struct dw_pcie *pci =3D &mp->pci; @@ -381,7 +365,6 @@ static int meson_pcie_host_init(struct dw_pcie_rp *pp) =20 pp->bridge->ops =3D &meson_pci_ops; =20 - meson_set_max_payload(mp, MAX_PAYLOAD_SIZE); meson_set_max_rd_req_size(mp, MAX_READ_REQ_SIZE); =20 return 0; --=20 2.25.1