From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 48F00C79FB9 for ; Thu, 10 Sep 2026 09:52:18 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender:Content-Type: List-Subscribe:List-Help:List-Post:List-Archive:List-Unsubscribe:List-Id: In-Reply-To:References:To:From:Subject:Cc:Message-Id:Date:Mime-Version: Reply-To:Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date :Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=itXC/NtxwG/B0XbM5UXmbiiV7cwU8ePUQhHGZyDNvdQ=; b=4XpL0ukhmIoBjK444tcOfcm2De FLF36h65nqQAgkmYv3PArFrLFEtyDvdydyfppCYyQb7LQmOTkRLBuphovCwbu/lgb8ooXyxOazxbE FVx2w0ckm8sCPwAOvC+ygIELa3o27HQh9UHroXV9yPJ68Y2Sx8Pv8p+C79G5FfkRDo/p39rX+lO2y WpKEEtRL+EnqsVkC1K6aRHfIOQx1wiYbUbTTVCTub9UFmO1dTI28zSF4EmsWDN9YficJuVceXxzOJ JgnwjWshnCi96GBFRN55mYVilPk+Gda3LSw+3vM7W/fvs4HnpIninH4/CNz3cfAjTCAB+nWpwpeb3 iSObA2hw==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.99.1 #2 (Red Hat Linux)) id 1x4bRv-0000000DwSv-0Ixv; Thu, 10 Sep 2026 09:52:07 +0000 Received: from smtpbgbr2.qq.com ([54.207.22.56]) by bombadil.infradead.org with esmtps (Exim 4.99.1 #2 (Red Hat Linux)) id 1x4bRr-0000000DwQN-0I4e for linux-riscv@lists.infradead.org; Thu, 10 Sep 2026 09:52:05 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.spacemit.com; s=mxsw2412; t=1789033872; bh=/jYHDEeDj6mTSil5AM0ztwiU+xkuIqY7l4GjrURkwMI=; h=Mime-Version:Date:Message-Id:Subject:From:To; b=jlfHboencdVUt2pJfQtKOAB+6e5Ua3ZLRzn6l7ZA6XtNAEuWjYBlSCFNydW2y3CQp MztbtfMpdJ0Y5bYXe2KRkYYmqCUCzkmW2mF8Gk+HbznMuV8UAJtYD4jiTLXCtcYMsm 6nexYAq5iUD8UPtCIyKxNL97JzAtrEfD6kSshZp4= X-QQ-mid: esmtpsz17t1789033870t1eda2e6e X-QQ-Originating-IP: f5kVe9DZlbg/hxKYwteXDSAPYMlVF5XmHtXimArN3mo= Received: from = ( [120.237.158.181]) by bizesmtp.qq.com (ESMTP) with id ; Thu, 10 Sep 2026 17:51:07 +0800 (CST) X-QQ-SSF: 0000000000000000000000000000000 X-QQ-GoodBg: 0 X-BIZMAIL-ID: 9185703477099524702 EX-QQ-RecipientCnt: 41 Mime-Version: 1.0 Date: Thu, 10 Sep 2026 17:51:04 +0800 Message-Id: Cc: , , , , , "Yixun Lan" , "Longbin Li" Subject: Re: [PATCH v5 6/6] PCI: spacemit-k1: Add Spacemit K3 PCIe host controller support From: "Troy Mitchell" To: "Inochi Amaoto" , "Troy Mitchell" , "Jingoo Han" , "Manivannan Sadhasivam" , "Lorenzo Pieralisi" , =?utf-8?q?Krzysztof_Wilczy=C5=84ski?= , "Rob Herring" , "Bjorn Helgaas" , "Krzysztof Kozlowski" , "Conor Dooley" , "Yixun Lan" , "Paul Walmsley" , "Palmer Dabbelt" , "Albert Ou" , "Alexandre Ghiti" , "Frank Li" , "Niklas Cassel" , "Sherry Sun" , "Arnd Bergmann" , "Christian Bruel" , "Krishna Chaitanya Chundru" , "Senchuan Zhang" , "Alex Elder" , "Xincheng Zhang" , "Randolph Lin" , "Siddharth Vadapalli" , "Andy Shevchenko" , "Vidya Sagar" , "Neil Armstrong" , "Danilo Krummrich" , =?utf-8?b?VXdlIEtsZWluZS1Lw7ZuaWcgKFRoZSBDYXBhYmxlIEh1Yik=?= , "Pengpeng Hou" , "Anirudh Srinivasan" , "Gustavo Pimentel" X-Mailer: aerc 0.21.0-0-g5549850facc2 References: <20260907112606.465778-1-inochiama@gmail.com> <20260907112606.465778-7-inochiama@gmail.com> In-Reply-To: X-QQ-SENDSIZE: 520 Feedback-ID: esmtpsz:linux.spacemit.com:qybglogicsvrgz:qybglogicsvrgz3a-0 X-QQ-XMAILINFO: Nb/rFP+bFqfRNiLsXhvqF2ENneZoVNdNZ8dA2v4Ua/F3SG9Ob9QAWK6N 22Wl4CvyWhhc4Iw1TThY+ydbggIY3AoJ/FSLRZxi2he629oTJ9es/MmFAJ3AbcxBjTTuImF fCuLQ8S17lSZLrBcgul1PaOdsaKccXDOsP9v6hTXFticXIYGCFkSTVokWBHYjKQC41XDKh3 vWJScXMYPgs7qLwyHd9ugVrjuyMUhf2JTHO7AUT19f/fR1y0qQujZzG6dDrEtc/3X0WOOvU JieZAmPjs24uLHGBpUQjIBrGs5pa760S5oXbSKGWJVxG4E0SLoGfUWCBpo5O6q0FHKWFv1j j5G6Ai4jmt3h1UQBR3ctBh3v7UbRLIBEtkp/hZrLSjvpyMtoYBAP4xFYmlkvQH1KR82HNOf zZ1/GeyX71xgsZVn23yNFSOtYACN5hhPAny4zgH2r1Pur6RD/dO4/rLXInTkg6NLgZpJi4B /jVj6ps/rlupCXMVO8yIz6qbPpbU/KGNQn1O7Sif4c3dGpVdJ7tHruSvXFQ3b8Pta4wnno4 GffQbMzXCn1l6vuFMmoQ7QxnpnNbk4y+4ZBD733d4OZmfFYSfDf3I1C1RIXAJ6faaOXrYJ0 ze+TAOHWPpc4GdSLrTN1fSW2sewY5Uz3QXvE+XJ/PcOeHMewdD1Nhb5KGeJT4ZHpmxOvBMy 20JzJ/e9qhiwJIo1Qc+5X//fKTaPOFYCUzodTeq/ewSoMUtY2r2oLAHn+K+cdD4dD0V+dYo sJ2mw0Xk50fiGeHRHzZEOZXqrqsX/LmVAyqz89MzBNNgSUFq4XE5tlJH/tCSKhde3GYxNmf iwHYap6bVsGz4edix50kFNRyr9Szzx6KyeH3K/SYnZ6aLg+URpvFgKu2GrZv9HWYdFdyLjN RmYDoHTzv7PAAn5KKAecR2cyAqDI38KciEH7OD7UVQlhZ9KOjOBjY0gsyhvuVRmAHJkA4mV LTnsl3jUHJuLmtpytmaro9r/axuLFG4HdDVKwVlsQyKjtcF1X0hiu4w21+W/NkSJNz/DuYa 0cAD5F8TgfqjXjK/p/mr/yUxtLaOp8Zf8/C5tLEaB/394ZlKr9Tq4a8MX3VtHFRZWbzEMTE yT15VjNJkjJvI2cenlVjQlJAhfZpVOwxw== X-QQ-XMRINFO: Nq+8W0+stu50tPAe92KXseR0ZZmBTk3gLg== X-QQ-RECHKSPAM: 0 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.9.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20260910_025204_249323_1DF2BED6 X-CRM114-Status: GOOD ( 31.99 ) X-BeenThere: linux-riscv@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2585878903600981065==" Sender: "linux-riscv" Errors-To: linux-riscv-bounces+linux-riscv=archiver.kernel.org@lists.infradead.org --===============2585878903600981065== Content-Type: multipart/signed; boundary=a3226df17150e624bf4bd069700ca9c5fbc60f85bc86f72fb8331621a4e0; micalg=pgp-sha512; protocol="application/pgp-signature" --a3226df17150e624bf4bd069700ca9c5fbc60f85bc86f72fb8331621a4e0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=UTF-8 On Wed Sep 9, 2026 at 3:51 PM +08, Inochi Amaoto wrote: > On Mon, Sep 07, 2026 at 09:14:23PM +0800, Troy Mitchell wrote: >> On Mon, Sep 7, 2026 at 07:26:05PM +0800, Inochi Amaoto wrote: >> > [...] >> > >> > @@ -303,6 +316,116 @@ static int k1_pcie_parse_port(struct k1_pcie *k1= ) >> > [...] >> > >> > +static int k3_pcie_init(struct dw_pcie_rp *pp) >> > +{ >> > + struct dw_pcie *pci =3D to_dw_pcie_from_pp(pp); >> > + struct k1_pcie *k1 =3D to_k1_pcie(pci); >> > + u32 reset_ctrl =3D k1->pmu_off + PCIE_CLK_RESET_CONTROL; >> > + u32 val; >> > + int ret; >> > + >> > + regmap_clear_bits(k1->pmu, reset_ctrl, LTSSM_EN); >> > + >> > + k1_pcie_toggle_soft_reset(k1); >> > + >> > + /* K3: Set IGNORE_PERSTN and drive PERSTN_OE high (assert reset) */ >> > + regmap_update_bits(k1->pmu, k1->pmu_off + PCIE_CONTROL_LOGIC, >> > + PCIE_IGNORE_PERSTN | PCIE_PERSTN_OE | PCIE_PERSTN_OUT, >> > + PCIE_IGNORE_PERSTN | PCIE_PERSTN_OE); >> > + >> > + ret =3D k1_pcie_enable_resources(k1); >> > + if (ret) >> > + goto failed_resources; >> > + >> > + regmap_set_bits(k1->pmu, reset_ctrl, PCIE_AUX_PWR_DET); >> > + regmap_clear_bits(k1->pmu, reset_ctrl, APP_HOLD_PHY_RST); >> > + >> > + ret =3D phy_bulk_init(k1->phy_count, k1->phys); >> > + if (ret) >> > + goto failed_phy; >> > + >> > + msleep(PCIE_T_PVPERL_MS); >> > + >> > + regmap_set_bits(k1->pmu, k1->pmu_off + PCIE_CONTROL_LOGIC, >> > + PCIE_PERSTN_OUT | PCIE_PERSTN_OE); >> > + >>=20 >> Should we use pci->pe_rst when reset-gpios is provided, and keep the PMU= path as >> a fallback? The SDK handles both cases. The DWC core requests that GPIO = with >> GPIOD_OUT_HIGH, but this path only releases PERST# through the PMU, so a= n >> endpoint using the GPIO would remain in reset. >>=20 > > I do not think this should be included in this version. I found PICO-ITX > has no reset gpio support. This means I can not test this feature. > > I suggest adding this function when there is a board using this function. Agreed, we can defer GPIO reset support until a board needs it and we can test it. I checked again, and the SDK only added this support recently. It provides GPIO-controlled PERST# as an alternative to the native PERST# control through the PMU. > >> > [...] >> > >> > + /* Finally, as a workaround, disable ASPM L1 */ >> > + k1_pcie_disable_aspm_l1(k1); >> > + >> > + return 0; >> > + >>=20 >> Would we also need to configure IOMMU bypass during initialization? The = SDK sets >> the PCIe A/B/C bypass bits in PMUA_PCIE_SUBSYS_MGMT when there is no usa= ble >> iommu-map. The proposed K3 PCIe DTS has no iommu-map, and I could not fi= nd the >> corresponding bypass setup in this series. >>=20 >> Is bypass already guaranteed by firmware or the reset state, or should t= he >> driver set it here? My concern is that enumeration could succeed while e= ndpoint >> DMA still goes through an unconfigured IOMMU. >>=20 > > I think the firmware should mark it bypassed as the default, at least > I have notice this behavior, but I am not sure whether it is the builtin > firmware or the uboot do this trick. I checked the register specification. The PCIe A/B/C IOMMU bypass bits reset to 1, so bypass is the hardware reset default and does not require firmware to enable it. That resolves my concern. > >> > [...] >> > >> > +static int k3_pcie_parse_port(struct k1_pcie *k1) >> > +{ >> > + u32 status0, status1, status2; >> > + >> > + /* This register require a RAW for cleanup */ >> > + status0 =3D readl_relaxed(k1->link + K3_PHY_AHB_IRQSTATUS_INTX); >> > + status1 =3D readl_relaxed(k1->link + INTR_STATUS); >> > + status2 =3D readl_relaxed(k1->link + K3_ADDR_INTR_STATUS1); >> > + >> > + writel_relaxed(status0, k1->link + K3_PHY_AHB_IRQSTATUS_INTX); >> > + writel_relaxed(status1, k1->link + INTR_STATUS); >> > + writel_relaxed(status2, k1->link + K3_ADDR_INTR_STATUS1); >> > + >> > + return k1_pcie_parse_port(k1); >> > +} >> > + >>=20 >> Are these status registers accessible before the controller clocks are e= nabled >> and resets released? k3_pcie_parse_port() runs before dw_pcie_host_init(= ), which >> calls k3_pcie_init() to enable those resources. >>=20 > > Yes they can. It is something interesting. > >> The SDK uses the same ordering, but I am not sure whether it relies on f= irmware >> leaving the registers accessible. If so, would it be safer to move this = clearing >> into k3_pcie_init(), after enabling the resources? >>=20 > > In fact, I have no idea about which clock control this MMIO area, if it i= s dbi > clock (but I guest it is not), it is kind of weird for this clear and sho= uld > move to the init. Do you have some knowledge on this? I have not confirmed which clock controls this MMIO region yet. I have asked our clock team about its clock and reset dependencies and whether access before resource initialization is guaranteed. I will follow up once I have clarification. > > Regards, > Inochi --=20 Troy Mitchell --a3226df17150e624bf4bd069700ca9c5fbc60f85bc86f72fb8331621a4e0 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iIMEABYKACsWIQSL4Ay2cExaPXAQcU2YCe+A+TM0LwUCaqJ9iA0caUB0cm95LXku b3JnAAoJEJgJ74D5MzQvIEkBAI5lOSUmTC1KRnfbtQZq22dzmqYH4si4e04iOSyS qA0iAP4h5FpgcgN1hdhSj0naM37Eexy5IDGOkDub+ZEMcldRBQ== =7iXk -----END PGP SIGNATURE----- --a3226df17150e624bf4bd069700ca9c5fbc60f85bc86f72fb8331621a4e0-- --===============2585878903600981065== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ linux-riscv mailing list linux-riscv@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-riscv --===============2585878903600981065==--