From: "Ilpo Järvinen" <ilpo.jarvinen@linux.intel.com>
To: Krishna Chaitanya Chundru <krishna.chundru@oss.qualcomm.com>
Cc: "Bjorn Helgaas" <bhelgaas@google.com>,
"Jingoo Han" <jingoohan1@gmail.com>,
"Manivannan Sadhasivam" <manivannan.sadhasivam@linaro.org>,
"Lorenzo Pieralisi" <lpieralisi@kernel.org>,
"Krzysztof Wilczyński" <kw@linux.com>,
"Rob Herring" <robh@kernel.org>,
"Johannes Berg" <johannes@sipsolutions.net>,
"Jeff Johnson" <jjohnson@kernel.org>,
linux-pci@vger.kernel.org, LKML <linux-kernel@vger.kernel.org>,
linux-arm-msm@vger.kernel.org, mhi@lists.linux.dev,
linux-wireless@vger.kernel.org, ath11k@lists.infradead.org,
quic_jjohnson@quicinc.com, quic_pyarlaga@quicinc.com,
quic_vbadigan@quicinc.com, quic_vpernami@quicinc.com,
quic_mrana@quicinc.com
Subject: Re: [PATCH 2/8] PCI/bwctrl: Add support to scale bandwidth before & after link re-training
Date: Mon, 17 Feb 2025 11:28:49 +0200 (EET) [thread overview]
Message-ID: <f58ff91f-95a1-1a0d-91e9-972f0eeddd4c@linux.intel.com> (raw)
In-Reply-To: <20250217-mhi_bw_up-v1-2-9bad1e42bdb1@oss.qualcomm.com>
On Mon, 17 Feb 2025, Krishna Chaitanya Chundru wrote:
> If the driver wants to move to higher data rate/speed than the current data
> rate then the controller driver may need to change certain votes so that
> link may come up at requested data rate/speed like QCOM PCIe controllers
> need to change their RPMh (Resource Power Manager-hardened) state. Once
> link retraining is done controller drivers needs to adjust their votes
> based on the final data rate.
>
> Some controllers also may need to update their bandwidth voting like
> ICC bw votings etc.
>
> So, add pre_scale_bus_bw() & post_scale_bus_bw() op to call before & after
> the link re-train.
>
> In case of PCIe switch, if there is a request to change target speed for a
> downstream port then no need to call these function ops as these are
> outside the scope of the controller drivers.
>
> Signed-off-by: Krishna Chaitanya Chundru <krishna.chundru@oss.qualcomm.com>
> ---
> drivers/pci/pcie/bwctrl.c | 15 +++++++++++++++
> include/linux/pci.h | 2 ++
> 2 files changed, 17 insertions(+)
>
> diff --git a/drivers/pci/pcie/bwctrl.c b/drivers/pci/pcie/bwctrl.c
> index 0a5e7efbce2c..e3faa4d1f935 100644
> --- a/drivers/pci/pcie/bwctrl.c
> +++ b/drivers/pci/pcie/bwctrl.c
> @@ -161,6 +161,8 @@ static int pcie_bwctrl_change_speed(struct pci_dev *port, u16 target_speed, bool
> int pcie_set_target_speed(struct pci_dev *port, enum pci_bus_speed speed_req,
> bool use_lt)
> {
> + struct pci_host_bridge *host = pci_find_host_bridge(port->bus);
> + bool is_root = pci_is_root_bus(port->bus);
is_rootport ?
> struct pci_bus *bus = port->subordinate;
> u16 target_speed;
> int ret;
> @@ -173,6 +175,16 @@ int pcie_set_target_speed(struct pci_dev *port, enum pci_bus_speed speed_req,
>
> target_speed = pcie_bwctrl_select_speed(port, speed_req);
>
> + /*
> + * The controller driver may need to be scaled for targeted speed
> + * otherwise link might not come up at requested speed.
> + */
> + if (is_root && host->ops->pre_scale_bus_bw) {
> + ret = host->ops->pre_scale_bus_bw(host->bus, target_speed);
> + if (ret)
> + return ret;
> + }
> +
> scoped_guard(rwsem_read, &pcie_bwctrl_setspeed_rwsem) {
> struct pcie_bwctrl_data *data = port->link_bwctrl;
>
> @@ -197,6 +209,9 @@ int pcie_set_target_speed(struct pci_dev *port, enum pci_bus_speed speed_req,
> !list_empty(&bus->devices))
> ret = -EAGAIN;
>
> + if (is_root && host->ops->post_scale_bus_bw)
> + host->ops->post_scale_bus_bw(host->bus, pci_bus_speed2lnkctl2(bus->cur_bus_speed));
Is the naming of these callbacks too specific for your use case? Does PCIe
spec actually call changing the Target Speed "scaling bus bandwidth" or
something along those line?
> return ret;
> }
>
> diff --git a/include/linux/pci.h b/include/linux/pci.h
> index 47b31ad724fa..58f1de626c37 100644
> --- a/include/linux/pci.h
> +++ b/include/linux/pci.h
> @@ -804,6 +804,8 @@ struct pci_ops {
> void __iomem *(*map_bus)(struct pci_bus *bus, unsigned int devfn, int where);
> int (*read)(struct pci_bus *bus, unsigned int devfn, int where, int size, u32 *val);
> int (*write)(struct pci_bus *bus, unsigned int devfn, int where, int size, u32 val);
> + int (*pre_scale_bus_bw)(struct pci_bus *bus, int target_speed);
> + void (*post_scale_bus_bw)(struct pci_bus *bus, int current_speed);
Please document these, including the locking requirements.
--
i.
next prev parent reply other threads:[~2025-02-17 9:42 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-02-17 6:34 [PATCH 0/8] bus: mhi: host: Add support for mhi bus bw Krishna Chaitanya Chundru
2025-02-17 6:34 ` [PATCH 1/8] PCI: update current bus speed as part of pci_bus_add_devices() Krishna Chaitanya Chundru
2025-02-17 6:34 ` [PATCH 2/8] PCI/bwctrl: Add support to scale bandwidth before & after link re-training Krishna Chaitanya Chundru
2025-02-17 9:28 ` Ilpo Järvinen [this message]
2025-02-19 17:57 ` Krishna Chaitanya Chundru
2025-02-17 6:34 ` [PATCH 3/8] PCI: dwc: Implement .pre_scale_bus_bw() & .post_scale_bus_bw hook Krishna Chaitanya Chundru
2025-02-17 6:34 ` [PATCH 4/8] PCI: dwc: qcom: Update ICC & OPP votes based upon the requested speed Krishna Chaitanya Chundru
2025-02-18 0:36 ` kernel test robot
2025-02-18 22:07 ` Bjorn Helgaas
2025-02-19 17:58 ` Krishna Chaitanya Chundru
2025-02-19 18:27 ` Bjorn Helgaas
2025-02-17 6:34 ` [PATCH 5/8] bus: mhi: host: Add support to read MHI capabilities Krishna Chaitanya Chundru
2025-02-17 6:34 ` [PATCH 6/8] bus: mhi: host: Add support for Bandwidth scale Krishna Chaitanya Chundru
2025-02-17 9:17 ` Ilpo Järvinen
2025-02-19 18:02 ` Krishna Chaitanya Chundru
2025-02-17 10:55 ` kernel test robot
2025-02-17 6:34 ` [PATCH 7/8] PCI: Make pcie_link_speed variable public & export pci_set_target_speed() Krishna Chaitanya Chundru
2025-02-19 17:36 ` Jeff Johnson
2025-02-17 6:34 ` [PATCH 8/8] wifi: ath11k: add support for MHI bandwidth scaling Krishna Chaitanya Chundru
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=f58ff91f-95a1-1a0d-91e9-972f0eeddd4c@linux.intel.com \
--to=ilpo.jarvinen@linux.intel.com \
--cc=ath11k@lists.infradead.org \
--cc=bhelgaas@google.com \
--cc=jingoohan1@gmail.com \
--cc=jjohnson@kernel.org \
--cc=johannes@sipsolutions.net \
--cc=krishna.chundru@oss.qualcomm.com \
--cc=kw@linux.com \
--cc=linux-arm-msm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=linux-wireless@vger.kernel.org \
--cc=lpieralisi@kernel.org \
--cc=manivannan.sadhasivam@linaro.org \
--cc=mhi@lists.linux.dev \
--cc=quic_jjohnson@quicinc.com \
--cc=quic_mrana@quicinc.com \
--cc=quic_pyarlaga@quicinc.com \
--cc=quic_vbadigan@quicinc.com \
--cc=quic_vpernami@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.