All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Krzysztof Wilczyński" <kw@linux.com>
To: Krishna chaitanya chundru <quic_krichai@quicinc.com>
Cc: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>,
	Lorenzo Pieralisi <lpieralisi@kernel.org>,
	Rob Herring <robh@kernel.org>,
	Bjorn Helgaas <bhelgaas@google.com>,
	Krzysztof Kozlowski <krzk+dt@kernel.org>,
	Conor Dooley <conor+dt@kernel.org>,
	Bjorn Andersson <andersson@kernel.org>,
	quic_vbadigan@quicinc.com, quic_skananth@quicinc.com,
	quic_nitegupt@quicinc.com, linux-arm-msm@vger.kernel.org,
	linux-pci@vger.kernel.org, linux-kernel@vger.kernel.org,
	devicetree@vger.kernel.org,
	Bryan O'Donoghue <bryan.odonoghue@linaro.org>,
	Krzysztof Kozlowski <krzk@kernel.org>
Subject: Re: [PATCH v15 0/4] PCI: qcom: Add support for OPP
Date: Sat, 29 Jun 2024 06:00:47 +0900	[thread overview]
Message-ID: <20240628210047.GB2206339@rocinante> (raw)
In-Reply-To: <20240619-opp_support-v15-0-aa769a2173a3@quicinc.com>

Hello,

> This patch adds support for OPP to vote for the performance state of RPMH
> power domain based upon PCIe speed it got enumerated.
> 
> QCOM Resource Power Manager-hardened (RPMh) is a hardware block which
> maintains hardware state of a regulator by performing max aggregation of
> the requests made by all of the processors.
> 
> PCIe controller can operate on different RPMh performance state of power
> domain based up on the speed of the link. And this performance state varies
> from target to target.
> 
> It is manadate to scale the performance state based up on the PCIe speed
> link operates so that SoC can run under optimum power conditions.
> 
> Add Operating Performance Points(OPP) support to vote for RPMh state based
> upon GEN speed link is operating.
> 
> Before link up PCIe driver will vote for the maximum performance state.
> 
> As now we are adding ICC BW vote in OPP, the ICC BW voting depends both
> GEN speed and link width using opp-level to indicate the opp entry table
> will be difficult.
> 
> In PCIe certain gen speeds like 2.5GT/s x2 & 5.0 GT/s X1 or 8.0 GT/s x2 &
> 16GT/s x1 use same ICC bw if we use freq in the OPP table to represent the
> PCIe speed number of PCIe entries can reduced.
> 
> So going back to use freq in the OPP table instead of level.
> 
> To access PCIe registers of the host controller and endpoint PCIe
> BAR space, config space the CPU-PCIe ICC (interconnect) path should
> be voted otherwise it may lead to NoC (Network on chip) timeout.
> We are surviving because of other driver voting for this path.
> 
> As there is less access on this path compared to PCIe to mem path
> add minimum vote i.e 1KBps bandwidth always which is sufficient enough
> to keep the path active and is recommended by HW team.
> 
> In suspend to ram case there can be some DBI access. Except in suspend
> to ram case disable CPU-PCIe ICC path after register space access
> is done.

Applied to controller/qcom, thank you!

[01/03] PCI: qcom: Add ICC bandwidth vote for CPU to PCIe path
        https://git.kernel.org/pci/pci/c/18f331d9c6db

[02/03] PCI: Bring the PCIe speed to MBps logic to new pcie_dev_speed_mbps()
        https://git.kernel.org/pci/pci/c/4bf3029dc2a1

[03/03] PCI: qcom: Add OPP support to scale performance
        https://git.kernel.org/pci/pci/c/78b5f6f8855e

	Krzysztof

      parent reply	other threads:[~2024-06-28 21:00 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-06-19 15:11 [PATCH v15 0/4] PCI: qcom: Add support for OPP Krishna chaitanya chundru
2024-06-19 15:11 ` [PATCH v15 1/4] PCI: qcom: Add ICC bandwidth vote for CPU to PCIe path Krishna chaitanya chundru
2024-06-19 15:11 ` [PATCH v15 2/4] dt-bindings: pci: qcom: Add OPP table Krishna chaitanya chundru
2024-06-28 20:14   ` Krzysztof Wilczyński
2024-06-19 15:11 ` [PATCH v15 3/4] PCI: Bring the PCIe speed to MBps logic to new pcie_dev_speed_mbps() Krishna chaitanya chundru
2024-06-19 15:11 ` [PATCH v15 4/4] PCI: qcom: Add OPP support to scale performance Krishna chaitanya chundru
2024-06-28 21:00 ` Krzysztof Wilczyński [this message]

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=20240628210047.GB2206339@rocinante \
    --to=kw@linux.com \
    --cc=andersson@kernel.org \
    --cc=bhelgaas@google.com \
    --cc=bryan.odonoghue@linaro.org \
    --cc=conor+dt@kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=krzk+dt@kernel.org \
    --cc=krzk@kernel.org \
    --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=quic_krichai@quicinc.com \
    --cc=quic_nitegupt@quicinc.com \
    --cc=quic_skananth@quicinc.com \
    --cc=quic_vbadigan@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.