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 7D658C433EF for ; Tue, 7 Dec 2021 21:01: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-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:Message-ID:MIME-version:References: Subject:In-Reply-To:Cc:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=nsd3XUEq+8v5jDyxjdHk77ZQ+NIKPc8vyW3QhUWKdi4=; b=b7kk1pHpnncXKq CKRswILc2uiXBs5vb9DYUNuYXXuX8nHrqu6z3RmfB1Mupr7PYy3AA1d9fbj3cSnYRR6YhJtp6eatZ VCbhurnb2NbDQXqQWWPVXBIFYRiXuIpSQRLtcgpAxK65Y9Y69mpaJiT5HlUgLOH6bLRBLT4K9m4Bf 34oEKcJNvnhY7Gls2RpFKdhAAYkF5As7bcccXmXEsTeBBTB/w6QA+V2IRsGK5OUMrMrxiGAKH8chz Dcnlqs161buGXzKRfc1FniPPVv/zEPPIKSDE/YmGpkE2nuCmKwmqI5/nalp7rb2L582x9B+3frpbE icDys23tNgZkn4JaEMnw==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1muhaD-00A610-86; Tue, 07 Dec 2021 21:01:05 +0000 Received: from sibelius.xs4all.nl ([83.163.83.176]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1muhZy-00A5u0-K2; Tue, 07 Dec 2021 21:00:53 +0000 Received: from localhost (bloch.sibelius.xs4all.nl [local]) by bloch.sibelius.xs4all.nl (OpenSMTPD) with ESMTPA id 45929648; Tue, 7 Dec 2021 22:00:43 +0100 (CET) Date: Tue, 7 Dec 2021 22:00:43 +0100 (CET) From: Mark Kettenis To: Bjorn Helgaas Cc: qizhong.cheng@mediatek.com, ryder.lee@mediatek.com, jianjun.wang@mediatek.com, lorenzo.pieralisi@arm.com, kw@linux.com, bhelgaas@google.com, linux-pci@vger.kernel.org, linux-mediatek@lists.infradead.org, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, chuanjia.liu@mediatek.com, pali@kernel.org, maz@kernel.org, alyssa@rosenzweig.io, luca@lucaceresoli.net In-Reply-To: <20211207175416.GA42725@bhelgaas> (message from Bjorn Helgaas on Tue, 7 Dec 2021 11:54:16 -0600) Subject: Re: [RESEND PATCH v2] PCI: mediatek: Delay 100ms to wait power and clock to become stable References: <20211207175416.GA42725@bhelgaas> MIME-version: 1.0 Message-ID: X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20211207_130051_001519_461E15A3 X-CRM114-Status: GOOD ( 22.36 ) X-BeenThere: linux-mediatek@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: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: "Linux-mediatek" Errors-To: linux-mediatek-bounces+linux-mediatek=archiver.kernel.org@lists.infradead.org > Date: Tue, 7 Dec 2021 11:54:16 -0600 > From: Bjorn Helgaas > = > [+cc Marc, Alyssa, Mark, Luca for reset timing questions] Hi Bjorn, > On Tue, Dec 07, 2021 at 04:41:53PM +0800, qizhong cheng wrote: > > Described in PCIe CEM specification sections 2.2 (PERST# Signal) and > > 2.2.1 (Initial Power-Up (G3 to S0)). The deassertion of PERST# should > > be delayed 100ms (TPVPERL) for the power and clock to become stable. > > = > > Signed-off-by: qizhong cheng > > Acked-by: Pali Roh=E1r > > --- > > = > > v2: > > - Typo fix. > > - Rewrap into one paragraph. > = > 1) If you change something, even in the commit log or comments, it is > a new version, not a "RESEND". A "RESEND" means "I sent this quite a > while ago and didn't hear anything, so I'm sending the exact same > thing again in case the first one got lost." > = > 2) I suggested a subject line update, which apparently got missed. > Here's a better one: > = > PCI: mediatek: Assert PERST# for 100ms for power and clock to stabilize > = > 3) Most importantly, this needs to be reconciled with the similar > change to the apple driver: > = > https://lore.kernel.org/r/20211123180636.80558-2-maz@kernel.org > = > In the apple driver, we're doing: > = > - Assert PERST# > - Set up REFCLK > - Sleep 100us (T_perst-clk, CEM r5 2.2, 2.9.2) > - Deassert PERST# > - Sleep 100ms (not sure there's a name? PCIe r5 6.6.1) > = > But here in mediatek, we're doing: > = > - Assert PERST# > - Sleep 100ms (T_pvperl, CEM r5 2.2, 2.2.1, 2.9.2) > - Deassert PERST# > = > My questions: My understanding of the the Apple PCIe hardware is somewhat limited but: > - Where does apple enforce T_pvperl? I can't tell where power to > the slot is turned on. So far all available machines only have PCIe devices that are soldered onto the motherboard, so there are no "real" slots. As far as we can tell the PCIe power domain is already powered on at the point where the m1n1 bootloader takes control. There is a GPIO that controls power to some devices (WiFi, SDHC on the M1 Pro/Max laptops) and those devices are initially powered off. The Linux driver doesn't currently attempt to power these devices on, but U-Boot will power them on if the appropriate GPIO is defined in the device tree. The way this is specified in the device tree is still under discussion. > - Where does mediatek enforce the PCIe sec 6.6.1 delay after > deasserting PERST# and before config requests? > = > - Does either apple or mediatek support speeds greater than 5 GT/s, > and if so, shouldn't we start the sec 6.6.1 100ms delay *after* > Link training completes? The Apple hardware advertises support for 8 GT/s, but all the devices integrated on the Mac mini support only 2.5 GT/s or 5 GT/s. Hope this helps, Mark _______________________________________________ Linux-mediatek mailing list Linux-mediatek@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-mediatek