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 95822C32771 for ; Wed, 28 Sep 2022 10:39:13 +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: Content-Transfer-Encoding:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:In-Reply-To:From:References:Cc:To:Subject: MIME-Version:Date:Message-ID:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=DA8xSs2VTfISFbB6NeGWb1+eZQLxk5dX9fIn4ezZgw8=; b=UFkHzl6RCMCOyG ySvoThK8o2a4zT/UN95zs9yG7CdcZ1GaKdreY2/7FJ4esz272u2Q2vThtpvluz37Z6BHajXkuPEqN 0n0KyQFA7yxIGrrvOZnrbfpsfGwkEyL+RWbVgi6sq7jOTHtx8uPPtdoPh/emAi3LSFgji7hrXqjN/ fG2eluzAZB3e4E7iA7h/Su8c3VhR1VDb9h8XvpGdNXxg+a6lX1LTzfwBJgn/YzlmIE1qerpBkwkJZ ldkMXak5zA3rIlVk8xpDoG+WMsGM4GKU1KiHoVFs+DW3Fc0Lq5uK92niGHXBP4Ky2O8nJPNiWw3Bu Ni6Ye2WFO4vPtojKDSng==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1odUSM-00FgCn-OY; Wed, 28 Sep 2022 10:38:22 +0000 Received: from foss.arm.com ([217.140.110.172]) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1odUSJ-00Fg9z-N8; Wed, 28 Sep 2022 10:38:21 +0000 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 123F41595; Wed, 28 Sep 2022 03:38:25 -0700 (PDT) Received: from [10.57.65.170] (unknown [10.57.65.170]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 0EB9C3F792; Wed, 28 Sep 2022 03:38:16 -0700 (PDT) Message-ID: Date: Wed, 28 Sep 2022 11:37:54 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; rv:102.0) Gecko/20100101 Thunderbird/102.3.0 Subject: Re: [PATCH-next v1] arm64: dts: rockchip: Enable NVM Express PCIe controller on rock3a Content-Language: en-GB To: Chukun Pan Cc: linux.amoon@gmail.com, heiko@sntech.de, robh+dt@kernel.org, michael.riesch@wolfvision.net, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, linux-rockchip@lists.infradead.org, linux-arm-kernel@lists.infradead.org References: <20220928100520.3886-1-amadeus@jmu.edu.cn> From: Robin Murphy In-Reply-To: <20220928100520.3886-1-amadeus@jmu.edu.cn> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20220928_033819_828534_B8DFC8B6 X-CRM114-Status: GOOD ( 14.96 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On 2022-09-28 11:05, Chukun Pan wrote: > Hi, > > On 27-09-22, 18:47, Robin Murphy wrote: > >> (as a side note, is pcie2x1's vpcie3v3-supply as queued in -next >> actually correct? AFAICS the other socket is effectively powered >> straight from VCC3V3_SYS so shouldn't have needed VCC3V3_PCIE, >> but at least it's there now ready for this one) > > Thanks for the correction, I didn't notice this before. You are right, > the supply of pcie2x1 comes from VCC3V3_SYS. But if we change supply > of pcie2x1 to VCC3V3_SYS, it will cause pcie30phy to fail to initialize > normally. The error is the same as the following: > >> phy phy-fe8c0000.phy.4: rockchip_p3phy_rk3568_init: lock >> failed 0x6890000, check input refclk and power supply >> phy phy-fe8c0000.phy.4: phy init failed --> -110 >> rockchip-dw-pcie: probe of 3c0800000.pcie failed with error -110 > > If both vpcie3v3-supply of pcie2x1 and pcie3x2 use VCC3V3_PCIE like > the vendor kernel, they can initialized normally. Presumably that only works because you happen to be probing pcie2x1 first, so it's not robust if that is disabled or probes later. Looking again, it seems the answer was right there in the error message all along - the PCIe 3.0 phy wants its external reference clock describing correctly, and it's *that* clock which depends on VCC3V3_PI6C_03, which happens to be turned on in parallel with VCC3V3_PCIE. Cheers, Robin. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel