All of lore.kernel.org
 help / color / mirror / Atom feed
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 Wilczyński" <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
Date: Mon, 12 Feb 2024 15:32:16 -0600	[thread overview]
Message-ID: <20240212213216.GA1145794@bhelgaas> (raw)
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

  reply	other threads:[~2024-02-12 21:32 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-02-10 17:10 [PATCH v2 0/3] Qualcomm PCIe RC shutdown & reinit Konrad Dybcio
2024-02-10 17:10 ` [PATCH v2 1/3] PCI: qcom: reshuffle reset logic in 2_7_0 .init Konrad Dybcio
2024-02-12 21:14   ` Bjorn Helgaas
2024-02-15 11:51     ` Konrad Dybcio
2024-02-10 17:10 ` [PATCH v2 2/3] PCI: qcom: Read back PARF_LTSSM register Konrad Dybcio
2024-02-12 21:17   ` Bjorn Helgaas
2024-02-14 21:35     ` Konrad Dybcio
2024-02-14 22:28       ` Bjorn Helgaas
2024-02-15 10:21         ` Konrad Dybcio
2024-02-15 16:11           ` Bjorn Helgaas
2024-02-15 18:44             ` Konrad Dybcio
2024-02-16  6:52               ` Johan Hovold
2024-03-15 10:16                 ` Konrad Dybcio
2024-03-15 11:16                   ` Manivannan Sadhasivam
2024-03-15 16:47                   ` Johan Hovold
2024-03-27 19:37                     ` Konrad Dybcio
2024-03-27 19:38                       ` Konrad Dybcio
2024-02-10 17:10 ` [PATCH v2 3/3] PCI: qcom: properly implement RC shutdown/power up Konrad Dybcio
2024-02-12 21:32   ` Bjorn Helgaas [this message]
2024-02-14 21:33     ` Konrad Dybcio
2024-02-15  7:13       ` Johan Hovold
2024-02-15 10:22         ` Konrad Dybcio
2024-02-20  4:12   ` Krishna Chaitanya Chundru
2024-03-27 19:37     ` Konrad Dybcio

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20240212213216.GA1145794@bhelgaas \
    --to=helgaas@kernel.org \
    --cc=andersson@kernel.org \
    --cc=bhelgaas@google.com \
    --cc=johan+linaro@kernel.org \
    --cc=konrad.dybcio@linaro.org \
    --cc=kw@linux.com \
    --cc=linux-arm-msm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=lpieralisi@kernel.org \
    --cc=manivannan.sadhasivam@linaro.org \
    --cc=p.zabel@pengutronix.de \
    --cc=quic_bjorande@quicinc.com \
    --cc=robh@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.