arch/arm64/boot/dts/qcom/sm8450.dtsi | 41 ++++++++++--- arch/arm64/boot/dts/qcom/sm8550.dtsi | 63 ++++++++++++++----- arch/arm64/boot/dts/qcom/sm8650.dtsi | 63 ++++++++++++++----- arch/arm64/boot/dts/qcom/x1e80100.dtsi | 90 ++++++++++++++++++++++----- drivers/opp/core.c | 107 +++++++++++++++++++++++++++++++-- drivers/pci/controller/dwc/pcie-qcom.c | 7 ++- include/linux/pm_opp.h | 30 +++++++++ 7 files changed, 341 insertions(+), 60 deletions(-)
The existing OPP table in the device tree for PCIe is shared across
different link configurations such as data rates 8GT/s x2 and 16GT/s x1.
These configurations often operate at the same frequency, allowing them
to reuse the same OPP entries. However, 8GT/s and 16 GT/s may have
different characteristics beyond frequency—such as RPMh votes in QCOM
case, which cannot be represented accurately when sharing a single OPP.
In such cases, frequency alone is not sufficient to uniquely identify
an OPP. To support these scenarios, introduce a new API
dev_pm_opp_find_key_exact() that allows OPP lookup for set of keys like
frequency, level & bandwidth.
Signed-off-by: Krishna Chaitanya Chundru <krishna.chundru@oss.qualcomm.com>
---
Changes in v4:
- Included dtsi changes for all platforms.
- Made the changes as requested by Viresh like adding comments, some
coding styles etc.
- Link to v3: https://lore.kernel.org/r/20250819-opp_pcie-v3-0-f8bd7e05ce41@oss.qualcomm.com
Changes in v3:
- Always check for frequency match unless user doesn't pass it (Viresh).
- Make dev_pm_opp_key public and let user pass the key (Viresh).
- Include bandwidth as part of dev_pm_opp_key (Viresh).
- Link to v2: https://lore.kernel.org/r/20250818-opp_pcie-v2-0-071524d98967@oss.qualcomm.com
Changes in v2:
- Use opp-level to indentify data rate and use both frequency and level
to identify the OPP. (Viresh)
- Link to v1: https://lore.kernel.org/r/20250717-opp_pcie-v1-0-dde6f452571b@oss.qualcomm.com
---
Krishna Chaitanya Chundru (7):
OPP: Add support to find OPP for a set of keys
OPP: Move refcount and key update for readability in _opp_table_find_key()
arm64: dts: qcom: sm8450: Add opp-level to indicate PCIe data rates
arm64: dts: qcom: sm8550: Add opp-level to indicate PCIe data rates
arm64: dts: qcom: sm8650: Add opp-level to indicate PCIe data rates
arm64: dts: qcom: x1e80100: Add opp-level to indicate PCIe data rates
PCI: qcom: Use frequency and level based OPP lookup
arch/arm64/boot/dts/qcom/sm8450.dtsi | 41 ++++++++++---
arch/arm64/boot/dts/qcom/sm8550.dtsi | 63 ++++++++++++++-----
arch/arm64/boot/dts/qcom/sm8650.dtsi | 63 ++++++++++++++-----
arch/arm64/boot/dts/qcom/x1e80100.dtsi | 90 ++++++++++++++++++++++-----
drivers/opp/core.c | 107 +++++++++++++++++++++++++++++++--
drivers/pci/controller/dwc/pcie-qcom.c | 7 ++-
include/linux/pm_opp.h | 30 +++++++++
7 files changed, 341 insertions(+), 60 deletions(-)
---
base-commit: c17b750b3ad9f45f2b6f7e6f7f4679844244f0b9
change-id: 20250717-opp_pcie-793160b2b113
Best regards,
--
Krishna Chaitanya Chundru <krishna.chundru@oss.qualcomm.com>
On Wed, Aug 20, 2025 at 01:58:46PM +0530, Krishna Chaitanya Chundru wrote: > The existing OPP table in the device tree for PCIe is shared across > different link configurations such as data rates 8GT/s x2 and 16GT/s x1. > These configurations often operate at the same frequency, allowing them > to reuse the same OPP entries. However, 8GT/s and 16 GT/s may have > different characteristics beyond frequency—such as RPMh votes in QCOM > case, which cannot be represented accurately when sharing a single OPP. > > In such cases, frequency alone is not sufficient to uniquely identify > an OPP. To support these scenarios, introduce a new API > dev_pm_opp_find_key_exact() that allows OPP lookup for set of keys like > frequency, level & bandwidth. > > Signed-off-by: Krishna Chaitanya Chundru <krishna.chundru@oss.qualcomm.com> > --- > Changes in v4: > - Included dtsi changes for all platforms. > - Made the changes as requested by Viresh like adding comments, some > coding styles etc. > - Link to v3: https://lore.kernel.org/r/20250819-opp_pcie-v3-0-f8bd7e05ce41@oss.qualcomm.com > > Changes in v3: > - Always check for frequency match unless user doesn't pass it (Viresh). > - Make dev_pm_opp_key public and let user pass the key (Viresh). > - Include bandwidth as part of dev_pm_opp_key (Viresh). > - Link to v2: https://lore.kernel.org/r/20250818-opp_pcie-v2-0-071524d98967@oss.qualcomm.com > > Changes in v2: > - Use opp-level to indentify data rate and use both frequency and level > to identify the OPP. (Viresh) > - Link to v1: https://lore.kernel.org/r/20250717-opp_pcie-v1-0-dde6f452571b@oss.qualcomm.com > > --- > Krishna Chaitanya Chundru (7): > OPP: Add support to find OPP for a set of keys > OPP: Move refcount and key update for readability in _opp_table_find_key() Hi Krishna, Patch 2/7 is applied in linux-next (20250825) as commit b5323835f050 (OPP: Reorganize _opp_table_find_key()) which is causing regression on my board (lemans-evk (arm64)). Reverting the change is resolving the issue. Kernel log: Unable to handle kernel NULL pointer dereference at virtual address 0000000000000016 ... Call trace: _read_bw+0x0/0x10 (P) _find_key+0xb8/0x194 dev_pm_opp_find_bw_floor+0x54/0x8c bwmon_intr_thread+0x84/0x284 [icc_bwmon] irq_thread_fn+0x2c/0xa8 irq_thread+0x174/0x334 kthread+0x134/0x208 ret_from_fork+0x10/0x20 > arm64: dts: qcom: sm8450: Add opp-level to indicate PCIe data rates > arm64: dts: qcom: sm8550: Add opp-level to indicate PCIe data rates > arm64: dts: qcom: sm8650: Add opp-level to indicate PCIe data rates > arm64: dts: qcom: x1e80100: Add opp-level to indicate PCIe data rates > PCI: qcom: Use frequency and level based OPP lookup > > arch/arm64/boot/dts/qcom/sm8450.dtsi | 41 ++++++++++--- > arch/arm64/boot/dts/qcom/sm8550.dtsi | 63 ++++++++++++++----- > arch/arm64/boot/dts/qcom/sm8650.dtsi | 63 ++++++++++++++----- > arch/arm64/boot/dts/qcom/x1e80100.dtsi | 90 ++++++++++++++++++++++----- > drivers/opp/core.c | 107 +++++++++++++++++++++++++++++++-- > drivers/pci/controller/dwc/pcie-qcom.c | 7 ++- > include/linux/pm_opp.h | 30 +++++++++ > 7 files changed, 341 insertions(+), 60 deletions(-) > --- > base-commit: c17b750b3ad9f45f2b6f7e6f7f4679844244f0b9 > change-id: 20250717-opp_pcie-793160b2b113 > > Best regards, > -- > Krishna Chaitanya Chundru <krishna.chundru@oss.qualcomm.com> > -- Regards, Wasim
On 25-08-25, 22:14, Wasim Nazir wrote: > Patch 2/7 is applied in linux-next (20250825) as commit > b5323835f050 (OPP: Reorganize _opp_table_find_key()) which is causing > regression on my board (lemans-evk (arm64)). > Reverting the change is resolving the issue. > > Kernel log: > Unable to handle kernel NULL pointer dereference at virtual address 0000000000000016 > ... > Call trace: > _read_bw+0x0/0x10 (P) > _find_key+0xb8/0x194 > dev_pm_opp_find_bw_floor+0x54/0x8c > bwmon_intr_thread+0x84/0x284 [icc_bwmon] > irq_thread_fn+0x2c/0xa8 > irq_thread+0x174/0x334 > kthread+0x134/0x208 > ret_from_fork+0x10/0x20 Hmm, this happened because it is possible for the `opp` to be invalid (error) even if `_compare_floor()` returned true, if the target key is lower than the lowest freq of the table. Dropped the patch for now anyway. -- viresh
On 26-08-25, 10:50, Viresh Kumar wrote:
> On 25-08-25, 22:14, Wasim Nazir wrote:
> > Kernel log:
> > Unable to handle kernel NULL pointer dereference at virtual address 0000000000000016
> > ...
> > Call trace:
> > _read_bw+0x0/0x10 (P)
> > _find_key+0xb8/0x194
> > dev_pm_opp_find_bw_floor+0x54/0x8c
> > bwmon_intr_thread+0x84/0x284 [icc_bwmon]
> > irq_thread_fn+0x2c/0xa8
> > irq_thread+0x174/0x334
> > kthread+0x134/0x208
> > ret_from_fork+0x10/0x20
>
> Hmm, this happened because it is possible for the `opp` to be invalid
> (error) even if `_compare_floor()` returned true, if the target key is
> lower than the lowest freq of the table.
>
> Dropped the patch for now anyway.
Can you help me testing this over your failing branch please ?
diff --git a/drivers/opp/core.c b/drivers/opp/core.c
index 81fb7dd7f323..5b24255733b5 100644
--- a/drivers/opp/core.c
+++ b/drivers/opp/core.c
@@ -554,10 +554,10 @@ static struct dev_pm_opp *_opp_table_find_key(struct opp_table *opp_table,
list_for_each_entry(temp_opp, &opp_table->opp_list, node) {
if (temp_opp->available == available) {
if (compare(&opp, temp_opp, read(temp_opp, index), *key)) {
- *key = read(opp, index);
-
- /* Increment the reference count of OPP */
- dev_pm_opp_get(opp);
+ if (!IS_ERR(opp)) {
+ *key = read(opp, index);
+ dev_pm_opp_get(opp);
+ }
break;
}
}
--
viresh
On 26-08-25, 11:06, Viresh Kumar wrote:
> Can you help me testing this over your failing branch please ?
>
> diff --git a/drivers/opp/core.c b/drivers/opp/core.c
> index 81fb7dd7f323..5b24255733b5 100644
> --- a/drivers/opp/core.c
> +++ b/drivers/opp/core.c
> @@ -554,10 +554,10 @@ static struct dev_pm_opp *_opp_table_find_key(struct opp_table *opp_table,
> list_for_each_entry(temp_opp, &opp_table->opp_list, node) {
> if (temp_opp->available == available) {
> if (compare(&opp, temp_opp, read(temp_opp, index), *key)) {
> - *key = read(opp, index);
> -
> - /* Increment the reference count of OPP */
> - dev_pm_opp_get(opp);
> + if (!IS_ERR(opp)) {
> + *key = read(opp, index);
> + dev_pm_opp_get(opp);
> + }
There are other issues too, dropping the patch. Thanks.
--
viresh
© 2016 - 2025 Red Hat, Inc.