[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20220214090826.GA7063@francesco-nb.int.toradex.com>
Date: Mon, 14 Feb 2022 10:08:26 +0100
From: Francesco Dolcini <francesco.dolcini@...adex.com>
To: Hongxing Zhu <hongxing.zhu@....com>
Cc: Francesco Dolcini <francesco.dolcini@...adex.com>,
"l.stach@...gutronix.de" <l.stach@...gutronix.de>,
"bhelgaas@...gle.com" <bhelgaas@...gle.com>,
"broonie@...nel.org" <broonie@...nel.org>,
"lorenzo.pieralisi@....com" <lorenzo.pieralisi@....com>,
"jingoohan1@...il.com" <jingoohan1@...il.com>,
"festevam@...il.com" <festevam@...il.com>,
"linux-pci@...r.kernel.org" <linux-pci@...r.kernel.org>,
dl-linux-imx <linux-imx@....com>,
"linux-arm-kernel@...ts.infradead.org"
<linux-arm-kernel@...ts.infradead.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"kernel@...gutronix.de" <kernel@...gutronix.de>
Subject: Re: [PATCH v6 5/8] PCI: imx6: Refine the regulator usage
On Mon, Feb 14, 2022 at 04:52:25AM +0000, Hongxing Zhu wrote:
> > > This commit is not just cleaning up the regulator usage as you state
> > > in the commit message, this is removing the vpcie regulator_disable
> > > from imx6_pcie_assert_core_reset().
> > >
> > > I would not do it, this is called for example on the shutdown callback
> > > where it makes sense.
> > Hi Francesco:
> > Thanks for your review.
> > Do you means that we should keep regulator_disable() here?
> > Okay, I would change it later.
> Hi Francesco:
> One more complementary that we can't disable this regulator here, because
> that the regulator might not be enabled at all.
>
> But in the case of suspend/resume operations, the regulator_disable() should
> be invoked behind of imx6_pcie_assert_core_reset () in resume callback to
> balance the enable/disable usage counter.
Understood, please do not forget about the imx6_pcie_shutdown() path,
having this regulator switched off there is important IMO.
A small side comment on the topic, at the moment suspend/resume is
not working correctly for me when the PCIe port is connected to a
switch, after resume only the upstream port is working correctly.
The issue is present on the current mainline driver, but also on
the downstream NXP kernel. Not sure what's the problem and at the
moment is not a priority for me to investigate.
Francesco
Powered by blists - more mailing lists