Received-SPF: pass (google.com: domain of linux-kernel+bounces-62397-linux.lists.archive=gmail.com@vger.kernel.org designates 139.178.88.99 as permitted sender) client-ip=139.178.88.99;
Date: Mon, 12 Feb 2024 15:32:16 -0600
From: Bjorn Helgaas <helgaas@kernel.org>
To: Konrad Dybcio <konrad.dybcio@linaro.org>
Cc: Bjorn Andersson <andersson@kernel.org>,
	Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>,
	Lorenzo Pieralisi <lpieralisi@kernel.org>,
	Krzysztof =?utf-8?Q?Wilczy=C5=84ski?= <kw@linux.com>,
	Rob Herring <robh@kernel.org>, Bjorn Helgaas <bhelgaas@google.com>,
	Philipp Zabel <p.zabel@pengutronix.de>,
	linux-arm-msm@vger.kernel.org, linux-pci@vger.kernel.org,
	linux-kernel@vger.kernel.org,
	Johan Hovold <johan+linaro@kernel.org>,
	Bjorn Andersson <quic_bjorande@quicinc.com>
Subject: Re: [PATCH v2 3/3] PCI: qcom: properly implement RC shutdown/power up
Message-ID: <20240212213216.GA1145794@bhelgaas>
Precedence: bulk
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20240210-topic-8280_pcie-v2-3-1cef4b606883@linaro.org>

"Properly" is a noise word that suggests "we're doing it right this
time" but doesn't hint at what actually makes this better.

On Sat, Feb 10, 2024 at 06:10:07PM +0100, Konrad Dybcio wrote:
> Currently, we've only been minimizing the power draw while keeping the
> RC up at all times. This is suboptimal, as it draws a whole lot of power
> and prevents the SoC from power collapsing.

Is "power collapse" a technical term specific to this device, or is
there some more common term that could be used?  I assume the fact
that the RC remains powered precludes some lower power state of the
entire SoC?

> Implement full shutdown and re-initialization to allow for powering off
> the controller.
> 
> This is mainly indended for SC8280XP with a broken power rail setup,
> which requires a full RC shutdown/reinit in order to reach SoC-wide
> power collapse, but sleeping is generally better than not sleeping and
> less destructive suspend can be implemented later for platforms that
> support it.

s/indended/intended/

>  config PCIE_QCOM
>  	bool "Qualcomm PCIe controller (host mode)"
>  	depends on OF && (ARCH_QCOM || COMPILE_TEST)
> +	depends on QCOM_COMMAND_DB || QCOM_COMMAND_DB=n

Just out of curiosity since I'm not a Kconfig expert, what does
"depends on X || X=n" mean?  

I guess it's different from
"depends on (QCOM_COMMAND_DB || !QCOM_COMMAND_DB)", which I also see
used for QCOM_RPMH?

Does this reduce compile testing?  I see COMPILE_TEST mentioned in a
few other QCOM_COMMAND_DB dependencies.

> +	ret_l23 = readl_poll_timeout(pcie->parf + PARF_PM_STTS, val,
> +				     val & PM_ENTER_L23, 10000, 100000);

Are these timeout values rooted in some PCIe or Qcom spec?  Would be
nice to have a spec citation or other reason for choosing these
values.

> +	reset_control_assert(res->rst);
> +	usleep_range(2000, 2500);

Ditto, some kind of citation would be nice.

Bjorn