Received: by 2002:a5d:925a:0:0:0:0:0 with SMTP id e26csp210214iol; Thu, 9 Jun 2022 02:12:08 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxXvE0WpStKCuqFKBdLPy3X42/K0H/rxMEJrYpeP8ksSWWlpN4n0x3gN9me3buyIHWVQex1 X-Received: by 2002:a17:907:97d2:b0:6ff:288d:1bf2 with SMTP id js18-20020a17090797d200b006ff288d1bf2mr35418187ejc.664.1654765927808; Thu, 09 Jun 2022 02:12:07 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1654765927; cv=none; d=google.com; s=arc-20160816; b=JFdEnklyKzgWMZYfURyrP3GwmyvYCYC7C8hImskmJPK7yTdyNA9bPCmd8zbiWUxwTC kiWxC32Wh8wnSolOlM3Ti1xHypELz43uPWx7LLtEA8McZ40nReR4SFI5MSzaukJi3fua IsXATqGbk3L1w4H+O/xdpe7ncw8TNlET533NUveYVDWoKk/a1BMazpQa46205sZ55NRJ cZoJBPCewH06nW/9NQUDB11Duh7AmIfTdU82hj6mJYkK/U5p18L1ICtY8969ftbw7xkb Y4Fkx4GUqUDUENCmTDfBV3/8BJLwlAKLtJeQ+T/IuCDuHyTOsT0d0XQUh7IsC5yKkCaC 5Vsg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :user-agent:references:in-reply-to:date:cc:to:from:subject :message-id; bh=Tj7j3iJA7QkU5VBZu8B7M+46exhxBnpgcQW2lavoll0=; b=ITAudR6XqREydRG0Pv6eKnPJ3Th5ZLqPfZzXM4OGWknbJyYz06bj6krIJEQwO6aNRH 8P6oj+d97sFx7L2zSeodk5r7K8F/KOYYXBX0ExplQfwoIg6MoNU4IUrlf+zEy/kMJ+jS QjJBqpxul6f6pbZyQu4F78q6G2hZSCy1TRxhw05RuBX8cvha2XqchZ5kdAeE5ogd7pFu kyNuHgt7ljjay17yv+u1tJng1by37814RbfbkRd5UFlhJ127/GZGqGrrq1tbdvZFAjqm TF2/P4KTaESDMWSdE29T8gJ19T/iTla0JVIDdIozOXC3zp2enn5Pl8lVX7CAGBghUiRb 9Qrw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id l23-20020a056402345700b0042ddc8cda2csi23497319edc.48.2022.06.09.02.11.41; Thu, 09 Jun 2022 02:12:07 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S239328AbiFIHz3 (ORCPT + 99 others); Thu, 9 Jun 2022 03:55:29 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:59720 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S238994AbiFIHz1 (ORCPT ); Thu, 9 Jun 2022 03:55:27 -0400 Received: from metis.ext.pengutronix.de (metis.ext.pengutronix.de [IPv6:2001:67c:670:201:290:27ff:fe1d:cc33]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 43D3B2F0 for ; Thu, 9 Jun 2022 00:55:25 -0700 (PDT) Received: from gallifrey.ext.pengutronix.de ([2001:67c:670:201:5054:ff:fe8d:eefb] helo=[IPv6:::1]) by metis.ext.pengutronix.de with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1nzD0c-0002lU-Le; Thu, 09 Jun 2022 09:55:14 +0200 Message-ID: Subject: Re: [PATCH v9 6/8] PCI: imx6: Disable clocks and regulators after link is down From: Lucas Stach To: Hongxing Zhu , "bhelgaas@google.com" , "robh+dt@kernel.org" , "broonie@kernel.org" , "lorenzo.pieralisi@arm.com" , "jingoohan1@gmail.com" , "festevam@gmail.com" , "francesco.dolcini@toradex.com" Cc: "linux-pci@vger.kernel.org" , "linux-arm-kernel@lists.infradead.org" , "linux-kernel@vger.kernel.org" , "kernel@pengutronix.de" , dl-linux-imx Date: Thu, 09 Jun 2022 09:55:13 +0200 In-Reply-To: References: <1651801629-30223-1-git-send-email-hongxing.zhu@nxp.com> <1651801629-30223-7-git-send-email-hongxing.zhu@nxp.com> <5be4f4322e00e33fa9417280b0d74ecb7aab913e.camel@pengutronix.de> Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.40.4 (3.40.4-1.fc34) MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-SA-Exim-Connect-IP: 2001:67c:670:201:5054:ff:fe8d:eefb X-SA-Exim-Mail-From: l.stach@pengutronix.de X-SA-Exim-Scanned: No (on metis.ext.pengutronix.de); SAEximRunCond expanded to false X-PTX-Original-Recipient: linux-kernel@vger.kernel.org X-Spam-Status: No, score=-4.2 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_MED, SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE,URIBL_BLOCKED autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Am Donnerstag, dem 09.06.2022 um 06:17 +0000 schrieb Hongxing Zhu: > > -----Original Message----- > > From: Lucas Stach > > Sent: 2022年6月8日 15:35 > > To: Hongxing Zhu ; bhelgaas@google.com; > > robh+dt@kernel.org; broonie@kernel.org; lorenzo.pieralisi@arm.com; > > jingoohan1@gmail.com; festevam@gmail.com; > > francesco.dolcini@toradex.com > > Cc: linux-pci@vger.kernel.org; > > linux-arm-kernel@lists.infradead.org; > > linux-kernel@vger.kernel.org; kernel@pengutronix.de; dl-linux-imx > > > > Subject: Re: [PATCH v9 6/8] PCI: imx6: Disable clocks and > > regulators after link is > > down > > > > Am Freitag, dem 06.05.2022 um 09:47 +0800 schrieb Richard Zhu: > > > Since i.MX PCIe doesn't support hot-plug, reduce power > > > consumption as > > > much as possible by disabling clocks and regulators and returning > > > error when the link is down. > > > > > > Signed-off-by: Richard Zhu > > > --- > > >  drivers/pci/controller/dwc/pci-imx6.c | 19 +++++++++++++++---- > > >  1 file changed, 15 insertions(+), 4 deletions(-) > > > > > > diff --git a/drivers/pci/controller/dwc/pci-imx6.c > > > b/drivers/pci/controller/dwc/pci-imx6.c > > > index 3ce3993d5797..d122c12193a6 100644 > > > --- a/drivers/pci/controller/dwc/pci-imx6.c > > > +++ b/drivers/pci/controller/dwc/pci-imx6.c > > > @@ -845,7 +845,9 @@ static int imx6_pcie_start_link(struct > > > dw_pcie *pci) > > >   /* Start LTSSM. */ > > >   imx6_pcie_ltssm_enable(dev); > > > > > > - dw_pcie_wait_for_link(pci); > > > + ret = dw_pcie_wait_for_link(pci); > > > + if (ret) > > > + goto err_out; > > > > This adds back error handling that has been intentionally removed > > in > > f81f095e8771 ("PCI: imx6: Allow to probe when > > dw_pcie_wait_for_link() fails"). > > While I agree that disabling the clocks and regulators is the right > > thing to do > > when we don't manage to get a link, we should still allow the > > driver to probe, > > so please add a "ret = 0" to this newly added non-fatal error > > paths. > > > Thanks for your review comments. > There would be a long latency if the link is down and probe is > finished >  successfully. > Since the dw_pcie_wait_for_link() would be invoked twice in every > driver probe >  and resume operation later. Each dw_pcie_wait_for_link() would > consume about >  90,000*10 ~ 100,000*10 u-seconds. I'm afraid that such a long > latency would >  bring bad user experience. > > Here are the logs when probe is allowed when PCIe link is down: > [ 55.045954][ T1835] imx6q-pcie 5f000000.pcie: PM: calling > imx6_pcie_resume_noirq.742dfa074b40dca7ca925f0c49c905ec.cfi_jt+0x0/0x > 8 @ 1835, parent: bus@5f000000 > ... > [ 56.074566][ T1835] imx6q-pcie 5f000000.pcie: Phy link never came > up > [ 57.074816][ T1835] imx6q-pcie 5f000000.pcie: Phy link never came > up > ... > [ 57.182300][ T1835] imx6q-pcie 5f000000.pcie: PM: > imx6_pcie_resume_noirq.742dfa074b40dca7ca925f0c49c905ec.cfi_jt+0x0/0x > 8 returned 0 after 2136334 usecs > > [ 57.182347][ T1835] imx6q-pcie 5f010000.pcie: PM: calling > imx6_pcie_resume_noirq.742dfa074b40dca7ca925f0c49c905ec.cfi_jt+0x0/0x > 8 @ 1835, parent: bus@5f000000 > ... > [ 58.210584][ T1835] imx6q-pcie 5f010000.pcie: Phy link never came > up > [ 59.210831][ T1835] imx6q-pcie 5f010000.pcie: Phy link never came > up > ... > [ 59.318313][ T1835] imx6q-pcie 5f010000.pcie: PM: > imx6_pcie_resume_noirq.742dfa074b40dca7ca925f0c49c905ec.cfi_jt+0x0/0x > 8 returned 0 after 2135949 usecs > > So, I'm prefer that it's better to let the probe failed when link is > down. > How do you think about that? It different from the behavior of other platforms, that still show the root bridge in lspci, even if the link is down. I've seen people confused by this behavior. Come to think about it: does lspci work when all the clocks are disabled? The latency in the probe path is not that relevant, as it is done asynchronous, so it doesn't stall the boot process. You have a point on the suspend/resume path however. Maybe we need to remember the link state in suspend to know if resume should even do anything useful? Regards, Lucas > > > > > > >   if (pci->link_gen == 2) { > > >   /* Allow Gen2 mode after the link is up. */ @@ - > > > 876,12 +878,14 > > @@ > > > static int imx6_pcie_start_link(struct dw_pcie *pci) > > >   ret = > > > imx6_pcie_wait_for_speed_change(imx6_pcie); > > >   if (ret) { > > >   dev_err(dev, "Failed to bring > > > link up!\n"); > > > - goto err_reset_phy; > > > + goto err_out; > > >   } > > >   } > > > > > >   /* Make sure link training is finished as well! > > > */ > > > - dw_pcie_wait_for_link(pci); > > > + ret = dw_pcie_wait_for_link(pci); > > > + if (ret) > > > + goto err_out; > > >   } else { > > >   dev_info(dev, "Link: Gen2 disabled\n"); > > >   } > > > @@ -890,11 +894,18 @@ static int imx6_pcie_start_link(struct > > > dw_pcie > > *pci) > > >   dev_info(dev, "Link up, Gen%i\n", tmp & > > > PCI_EXP_LNKSTA_CLS); > > >   return 0; > > > > > > -err_reset_phy: > > > +err_out: > > >   dev_dbg(dev, "PHY DEBUG_R0=0x%08x DEBUG_R1=0x%08x\n", > > >   dw_pcie_readl_dbi(pci, PCIE_PORT_DEBUG0), > > >   dw_pcie_readl_dbi(pci, PCIE_PORT_DEBUG1)); > > >   imx6_pcie_reset_phy(imx6_pcie); > > > + imx6_pcie_clk_disable(imx6_pcie); > > > + if (imx6_pcie->phy != NULL) { > > > > Please use the more common if (imx6_pcie->phy) here. > > > Okay. Thanks. > > Best Regards > Richard Zhu > > > Regards, > > Lucas > > > > > + phy_power_off(imx6_pcie->phy); > > > + phy_exit(imx6_pcie->phy); > > > + } > > > + if (imx6_pcie->vpcie) > > > + regulator_disable(imx6_pcie->vpcie); > > >   return ret; > > >  } > > > > > >