Until now, the icc-rpm driver unconditionally set QoS params, even on
empty requests. This is superfluous and the downstream counterpart does
not do it. Follow it by doing the same.
Signed-off-by: Konrad Dybcio <[email protected]>
---
drivers/interconnect/qcom/icc-rpm.c | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/drivers/interconnect/qcom/icc-rpm.c b/drivers/interconnect/qcom/icc-rpm.c
index 43b9ce0dcb6a..06e0fee547ab 100644
--- a/drivers/interconnect/qcom/icc-rpm.c
+++ b/drivers/interconnect/qcom/icc-rpm.c
@@ -193,6 +193,12 @@ static int qcom_icc_qos_set(struct icc_node *node, u64 sum_bw)
struct qcom_icc_provider *qp = to_qcom_provider(node->provider);
struct qcom_icc_node *qn = node->data;
+ /* Defer setting QoS until the first non-zero bandwidth request. */
+ if (!(node->avg_bw || node->peak_bw)) {
+ dev_dbg(node->provider->dev, "NOT Setting QoS for %s\n", qn->name);
+ return 0;
+ }
+
dev_dbg(node->provider->dev, "Setting QoS for %s\n", qn->name);
switch (qp->type) {
--
2.39.0
Currently, NOC_QOS_MODE_FIXED is defined as 0x0, which makes it the
"default" option (as that's what uninitialized members of partially
initialized structs are set to), which should really have been
NOC_QOS_MODE_INVALID, and that's what people (wrongly) assumed was
the case when .qos.qos_mode was not defined and what really makes
the most sense..
That resulted in {port 0, prio 0, areq_prio 0, urg_fwd = false, rpm-voted}
QoS being always voted for, because the code flow assumed "hey, it's fixed
QoS, so let's just roll with whatever parameters are set" [again, set by
partial struct initialization, as these fields were left unfilled by the
developers]. That is of course incorrect, and on many of these platforms
port 0 is MAS_APPS_PROC, which 9/10 times is supposed to be handled by
the ap_owned path, not to mention the rest of the parameters may differ.
Arguably, the APPS node is the most important one, next to EBI0..
The modes are defined as preprocessor constants. They are not used
anywhere outside the driver or sent to any remote processor outside
qcom_icc_set_noc_qos(), which is easily worked around.
Separate the type specified in driver data from the value sent to msmbus.
Make the former an enum for better mainainability.
This is an implicit fix for every SMD RPM ICC driver that didn't
explicitly specify NOC_QOS_MODE_INVALID on non-AP_owned nodes that
don't have QoS settings.
Fixes: 30c8fa3ec61a ("interconnect: qcom: Add MSM8916 interconnect provider driver")
Fixes: 6c6fe5d3dc5e ("interconnect: qcom: Add MSM8939 interconnect provider driver")
Fixes: 4e60a9568dc6 ("interconnect: qcom: add msm8974 driver")
Fixes: 7add937f5222 ("interconnect: qcom: Add MSM8996 interconnect provider driver")
Signed-off-by: Konrad Dybcio <[email protected]>
---
drivers/interconnect/qcom/icc-rpm.c | 23 +++++++++++++----------
drivers/interconnect/qcom/icc-rpm.h | 10 ++++++----
2 files changed, 19 insertions(+), 14 deletions(-)
diff --git a/drivers/interconnect/qcom/icc-rpm.c b/drivers/interconnect/qcom/icc-rpm.c
index a190a0a839c8..8ec1ca17816a 100644
--- a/drivers/interconnect/qcom/icc-rpm.c
+++ b/drivers/interconnect/qcom/icc-rpm.c
@@ -48,6 +48,10 @@
#define NOC_QOS_MODEn_ADDR(n) (0xc + (n * 0x1000))
#define NOC_QOS_MODEn_MASK 0x3
+#define NOC_QOS_MODE_INVALID_VAL -1
+#define NOC_QOS_MODE_FIXED_VAL 0x0
+#define NOC_QOS_MODE_BYPASS_VAL 0x2
+
static int qcom_icc_set_qnoc_qos(struct icc_node *src, u64 max_bw)
{
struct icc_provider *provider = src->provider;
@@ -155,7 +159,7 @@ static int qcom_icc_set_noc_qos(struct icc_node *src, u64 max_bw)
struct qcom_icc_provider *qp;
struct qcom_icc_node *qn;
struct icc_provider *provider;
- u32 mode = NOC_QOS_MODE_BYPASS;
+ u32 mode = NOC_QOS_MODE_BYPASS_VAL;
int rc = 0;
qn = src->data;
@@ -169,18 +173,17 @@ static int qcom_icc_set_noc_qos(struct icc_node *src, u64 max_bw)
return 0;
}
- if (qn->qos.qos_mode != NOC_QOS_MODE_INVALID)
- mode = qn->qos.qos_mode;
-
- if (mode == NOC_QOS_MODE_FIXED) {
- dev_dbg(src->provider->dev, "NoC QoS: %s: Set Fixed mode\n",
- qn->name);
+ if (qn->qos.qos_mode == NOC_QOS_MODE_FIXED) {
+ dev_dbg(src->provider->dev, "NoC QoS: %s: Set Fixed mode\n", qn->name);
+ mode = NOC_QOS_MODE_FIXED_VAL;
rc = qcom_icc_noc_set_qos_priority(qp, &qn->qos);
if (rc)
return rc;
- } else if (mode == NOC_QOS_MODE_BYPASS) {
- dev_dbg(src->provider->dev, "NoC QoS: %s: Set Bypass mode\n",
- qn->name);
+ } else if (qn->qos.qos_mode == NOC_QOS_MODE_BYPASS) {
+ dev_dbg(src->provider->dev, "NoC QoS: %s: Set Bypass mode\n", qn->name);
+ mode = NOC_QOS_MODE_BYPASS_VAL;
+ } else {
+ /* How did we get here? */
}
return regmap_update_bits(qp->regmap,
diff --git a/drivers/interconnect/qcom/icc-rpm.h b/drivers/interconnect/qcom/icc-rpm.h
index a49af844ab13..8ba1918d7997 100644
--- a/drivers/interconnect/qcom/icc-rpm.h
+++ b/drivers/interconnect/qcom/icc-rpm.h
@@ -97,10 +97,12 @@ struct qcom_icc_desc {
unsigned int qos_offset;
};
-/* Valid for both NoC and BIMC */
-#define NOC_QOS_MODE_INVALID -1
-#define NOC_QOS_MODE_FIXED 0x0
-#define NOC_QOS_MODE_BYPASS 0x2
+/* Valid for all bus types */
+enum qos_mode {
+ NOC_QOS_MODE_INVALID = 0,
+ NOC_QOS_MODE_FIXED,
+ NOC_QOS_MODE_BYPASS,
+};
int qnoc_probe(struct platform_device *pdev);
int qnoc_remove(struct platform_device *pdev);
--
2.39.0
Some nodes, like EBI0 (DDR) or L3/LLCC, may be connected over more than
one channel. This should be taken into account in bandwidth calcualtion,
as we're supposed to feed msmbus with the per-channel bandwidth. Add
support for specifying that and use it during bandwidth aggregation.
Signed-off-by: Konrad Dybcio <[email protected]>
---
drivers/interconnect/qcom/icc-rpm.c | 7 ++++++-
drivers/interconnect/qcom/icc-rpm.h | 2 ++
2 files changed, 8 insertions(+), 1 deletion(-)
diff --git a/drivers/interconnect/qcom/icc-rpm.c b/drivers/interconnect/qcom/icc-rpm.c
index 8ec1ca17816a..04fe742c25a3 100644
--- a/drivers/interconnect/qcom/icc-rpm.c
+++ b/drivers/interconnect/qcom/icc-rpm.c
@@ -328,6 +328,7 @@ static void qcom_icc_bus_aggregate(struct icc_provider *provider,
{
struct icc_node *node;
struct qcom_icc_node *qn;
+ u64 sum_avg[QCOM_ICC_NUM_BUCKETS];
int i;
/* Initialise aggregate values */
@@ -345,7 +346,11 @@ static void qcom_icc_bus_aggregate(struct icc_provider *provider,
list_for_each_entry(node, &provider->nodes, node_list) {
qn = node->data;
for (i = 0; i < QCOM_ICC_NUM_BUCKETS; i++) {
- agg_avg[i] += qn->sum_avg[i];
+ if (qn->channels)
+ sum_avg[i] = div_u64(qn->sum_avg[i], qn->channels);
+ else
+ sum_avg[i] = qn->sum_avg[i];
+ agg_avg[i] += sum_avg[i];
agg_peak[i] = max_t(u64, agg_peak[i], qn->max_peak[i]);
}
}
diff --git a/drivers/interconnect/qcom/icc-rpm.h b/drivers/interconnect/qcom/icc-rpm.h
index 8ba1918d7997..8aed5400afda 100644
--- a/drivers/interconnect/qcom/icc-rpm.h
+++ b/drivers/interconnect/qcom/icc-rpm.h
@@ -66,6 +66,7 @@ struct qcom_icc_qos {
* @id: a unique node identifier
* @links: an array of nodes where we can go next while traversing
* @num_links: the total number of @links
+ * @channels: number of channels at this node (e.g. DDR channels)
* @buswidth: width of the interconnect between a node and the bus (bytes)
* @sum_avg: current sum aggregate value of all avg bw requests
* @max_peak: current max aggregate value of all peak bw requests
@@ -78,6 +79,7 @@ struct qcom_icc_node {
u16 id;
const u16 *links;
u16 num_links;
+ u16 channels;
u16 buswidth;
u64 sum_avg[QCOM_ICC_NUM_BUCKETS];
u64 max_peak[QCOM_ICC_NUM_BUCKETS];
--
2.39.0
QoS parameters and RPM bandwidth requests are wholly separate. Setting one
should only depend on the description of the interconnect node and not
whether the other is present. If we vote through RPM, QoS parameters
should be set so that the bus controller can make better decisions.
If we don't vote through RPM, QoS parameters should be set regardless,
as we're requesting additional bandwidth by setting the interconnect
clock rates.
The Fixes tag references the commit in which this logic was added, it
has since been shuffled around to a different file, but it's the one
where it originates from.
Fixes: f80a1d414328 ("interconnect: qcom: Add SDM660 interconnect provider driver")
Signed-off-by: Konrad Dybcio <[email protected]>
---
drivers/interconnect/qcom/icc-rpm.c | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/interconnect/qcom/icc-rpm.c b/drivers/interconnect/qcom/icc-rpm.c
index 06e0fee547ab..a190a0a839c8 100644
--- a/drivers/interconnect/qcom/icc-rpm.c
+++ b/drivers/interconnect/qcom/icc-rpm.c
@@ -252,8 +252,10 @@ static int __qcom_icc_set(struct icc_node *n, struct qcom_icc_node *qn,
ret = qcom_icc_rpm_set(qn->mas_rpm_id, qn->slv_rpm_id, sum_bw);
if (ret)
return ret;
- } else if (qn->qos.qos_mode != -1) {
- /* set bandwidth directly from the AP */
+ }
+
+ if (qn->qos.qos_mode != NOC_QOS_MODE_INVALID) {
+ /* Set QoS params from the AP */
ret = qcom_icc_qos_set(n, sum_bw);
if (ret)
return ret;
--
2.39.0
On 03/01/2023 17:30, Konrad Dybcio wrote:
> Until now, the icc-rpm driver unconditionally set QoS params, even on
> empty requests. This is superfluous and the downstream counterpart does
> not do it. Follow it by doing the same.
>
> Signed-off-by: Konrad Dybcio <[email protected]>
> ---
> drivers/interconnect/qcom/icc-rpm.c | 6 ++++++
> 1 file changed, 6 insertions(+)
>
> diff --git a/drivers/interconnect/qcom/icc-rpm.c b/drivers/interconnect/qcom/icc-rpm.c
> index 43b9ce0dcb6a..06e0fee547ab 100644
> --- a/drivers/interconnect/qcom/icc-rpm.c
> +++ b/drivers/interconnect/qcom/icc-rpm.c
> @@ -193,6 +193,12 @@ static int qcom_icc_qos_set(struct icc_node *node, u64 sum_bw)
> struct qcom_icc_provider *qp = to_qcom_provider(node->provider);
> struct qcom_icc_node *qn = node->data;
>
> + /* Defer setting QoS until the first non-zero bandwidth request. */
> + if (!(node->avg_bw || node->peak_bw)) {
> + dev_dbg(node->provider->dev, "NOT Setting QoS for %s\n", qn->name);
> + return 0;
> + }
> +
> dev_dbg(node->provider->dev, "Setting QoS for %s\n", qn->name);
>
> switch (qp->type) {
Doesn't downstream clear the registers on a zero allocation request ?
https://git.codelinaro.org/clo/la/kernel/msm-3.18/-/blob/LA.BR.1.2.9-00810-8x09.0/drivers/platform/msm/msm_bus/msm_bus_bimc.c#L1302
https://git.codelinaro.org/clo/la/kernel/msm-3.18/-/blob/LA.BR.1.2.9-00810-8x09.0/drivers/platform/msm/msm_bus/msm_bus_bimc.c#L1318
https://git.codelinaro.org/clo/la/kernel/msm-3.18/-/blob/LA.BR.1.2.9-00810-8x09.0/drivers/platform/msm/msm_bus/msm_bus_bimc.c#L1367
msm_bus_bimc_set_qos_bw()
{
/* Only calculate if there's a requested bandwidth and window */
if (qbw->bw && qbw->ws) {
}else
/* Clear bandwidth registers */
set_qos_bw_regs(base, mas_index, 0, 0, 0, 0, 0);
}
---
bod
On 03/01/2023 23:43, Bryan O'Donoghue wrote:
> On 03/01/2023 17:30, Konrad Dybcio wrote:
> I agree your code does what it says on the tin but, whats the overall
> justification to depart from the downstream logic ?
>
> ---
> bod
and can we prove with a meaningful test a behaviour change ? Better
throughput ? Lower thermals ?
---
bod
On 03/01/2023 17:30, Konrad Dybcio wrote:
> QoS parameters and RPM bandwidth requests are wholly separate. Setting one
> should only depend on the description of the interconnect node and not
> whether the other is present. If we vote through RPM, QoS parameters
> should be set so that the bus controller can make better decisions.
Is that true ?
> If we don't vote through RPM, QoS parameters should be set regardless,
> as we're requesting additional bandwidth by setting the interconnect
> clock rates.
>
> The Fixes tag references the commit in which this logic was added, it
> has since been shuffled around to a different file, but it's the one
> where it originates from.
>
> Fixes: f80a1d414328 ("interconnect: qcom: Add SDM660 interconnect provider driver")
> Signed-off-by: Konrad Dybcio <[email protected]>
> ---
> drivers/interconnect/qcom/icc-rpm.c | 6 ++++--
> 1 file changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/interconnect/qcom/icc-rpm.c b/drivers/interconnect/qcom/icc-rpm.c
> index 06e0fee547ab..a190a0a839c8 100644
> --- a/drivers/interconnect/qcom/icc-rpm.c
> +++ b/drivers/interconnect/qcom/icc-rpm.c
> @@ -252,8 +252,10 @@ static int __qcom_icc_set(struct icc_node *n, struct qcom_icc_node *qn,
> ret = qcom_icc_rpm_set(qn->mas_rpm_id, qn->slv_rpm_id, sum_bw);
> if (ret)
> return ret;
> - } else if (qn->qos.qos_mode != -1) {
> - /* set bandwidth directly from the AP */
> + }
> +
> + if (qn->qos.qos_mode != NOC_QOS_MODE_INVALID) {
> + /* Set QoS params from the AP */
> ret = qcom_icc_qos_set(n, sum_bw);
> if (ret)
> return ret;
Taking the example of
static struct qcom_icc_node bimc_snoc_slv = {
.name = "bimc_snoc_slv",
.id = MSM8939_BIMC_SNOC_SLV,
.buswidth = 16,
.mas_rpm_id = -1,
.slv_rpm_id = 2,
.num_links = ARRAY_SIZE(bimc_snoc_slv_links),
.links = bimc_snoc_slv_links,
};
#define NOC_QOS_MODE_INVALID -1
ap_owned == false
qos_mode == NOC_QOS_MODE_FIXED
if (!qn->qos.ap_owned) {
/* bod: this will run */
/* send bandwidth request message to the RPM processor */
ret = qcom_icc_rpm_set(qn->mas_rpm_id, qn->slv_rpm_id, sum_bw);
if (ret)
return ret;
} else if (qn->qos.qos_mode != -1) {
/* bod: this will not run */
/* set bandwidth directly from the AP */
ret = qcom_icc_qos_set(n, sum_bw);
if (ret)
return ret;
}
and your proposed change
if (!qn->qos.ap_owned) {
/* bod: this will run */
/* send bandwidth request message to the RPM processor */
ret = qcom_icc_rpm_set(qn->mas_rpm_id, qn->slv_rpm_id, sum_bw);
if (ret)
return ret;
}
if (qn->qos.qos_mode != NOC_QOS_MODE_INVALID) {
/* bod: this will run */
/* set bandwidth directly from the AP */
ret = qcom_icc_qos_set(n, sum_bw);
if (ret)
return ret;
}
however if we look downstream we have the concept of ap_owned
https://git.codelinaro.org/clo/la/kernel/msm-3.18/-/blob/LA.BR.1.2.9-00810-8x09.0/drivers/platform/msm/msm_bus/msm_bus_fabric_adhoc.c#L194
https://git.codelinaro.org/clo/la/kernel/msm-3.18/-/blob/LA.BR.1.2.9-00810-8x09.0/drivers/platform/msm/msm_bus/msm_bus_fabric_adhoc.c#L208
In simple terms
if (node_info->ap_owned) {
ret = fabdev->noc_ops.set_bw(node_info,
} else {
ret = send_rpm_msg(node_device);
}
I agree your code does what it says on the tin but, whats the overall
justification to depart from the downstream logic ?
---
bod
On 4.01.2023 00:07, Bryan O'Donoghue wrote:
> On 03/01/2023 17:30, Konrad Dybcio wrote:
>> Until now, the icc-rpm driver unconditionally set QoS params, even on
>> empty requests. This is superfluous and the downstream counterpart does
>> not do it. Follow it by doing the same.
>>
>> Signed-off-by: Konrad Dybcio <[email protected]>
>> ---
>> drivers/interconnect/qcom/icc-rpm.c | 6 ++++++
>> 1 file changed, 6 insertions(+)
>>
>> diff --git a/drivers/interconnect/qcom/icc-rpm.c b/drivers/interconnect/qcom/icc-rpm.c
>> index 43b9ce0dcb6a..06e0fee547ab 100644
>> --- a/drivers/interconnect/qcom/icc-rpm.c
>> +++ b/drivers/interconnect/qcom/icc-rpm.c
>> @@ -193,6 +193,12 @@ static int qcom_icc_qos_set(struct icc_node *node, u64 sum_bw)
>> struct qcom_icc_provider *qp = to_qcom_provider(node->provider);
>> struct qcom_icc_node *qn = node->data;
>> + /* Defer setting QoS until the first non-zero bandwidth request. */
>> + if (!(node->avg_bw || node->peak_bw)) {
>> + dev_dbg(node->provider->dev, "NOT Setting QoS for %s\n", qn->name);
>> + return 0;
>> + }
>> +
>> dev_dbg(node->provider->dev, "Setting QoS for %s\n", qn->name);
>> switch (qp->type) {
>
> Doesn't downstream clear the registers on a zero allocation request ?
>
> https://git.codelinaro.org/clo/la/kernel/msm-3.18/-/blob/LA.BR.1.2.9-00810-8x09.0/drivers/platform/msm/msm_bus/msm_bus_bimc.c#L1302
>
> https://git.codelinaro.org/clo/la/kernel/msm-3.18/-/blob/LA.BR.1.2.9-00810-8x09.0/drivers/platform/msm/msm_bus/msm_bus_bimc.c#L1318
>
> https://git.codelinaro.org/clo/la/kernel/msm-3.18/-/blob/LA.BR.1.2.9-00810-8x09.0/drivers/platform/msm/msm_bus/msm_bus_bimc.c#L1367
>
> msm_bus_bimc_set_qos_bw()
> {
> /* Only calculate if there's a requested bandwidth and window */
> if (qbw->bw && qbw->ws) {
> }else
> /* Clear bandwidth registers */
> set_qos_bw_regs(base, mas_index, 0, 0, 0, 0, 0);
> }
Yes, looks like that's the case, but also it's only for BIMC, not
for NOC:
https://git.codelinaro.org/clo/la/kernel/msm-3.18/-/blob/LA.BR.1.2.9-00810-8x09.0/drivers/platform/msm/msm_bus/msm_bus_noc.c#L246
Moreover, it only concerns QoS parameters that are not supported on
mainline (Grant Period, Grant Count, Threshold Lo/Me/Hi) [1], so that
pretty much addresses your worries, I think..
And FWIW that's definitely not the case anymore for QNOC (and BIMC
for that matter) on msm-5.4:
https://github.com/sonyxperiadev/kernel/blob/aosp/LA.UM.9.14.r1/drivers/interconnect/qcom/icc-rpm.c#L217
Konrad
[1] Note: msm8939 seems to be a somewhat heavy user of these properties,
maybe it would be worth looking into implementing them?
>
> ---
> bod
On 4.01.2023 00:43, Bryan O'Donoghue wrote:
> On 03/01/2023 17:30, Konrad Dybcio wrote:
>> QoS parameters and RPM bandwidth requests are wholly separate. Setting one
>> should only depend on the description of the interconnect node and not
>> whether the other is present. If we vote through RPM, QoS parameters
>> should be set so that the bus controller can make better decisions.
>
> Is that true ?
>
>> If we don't vote through RPM, QoS parameters should be set regardless,
>> as we're requesting additional bandwidth by setting the interconnect
>> clock rates.
>>
>> The Fixes tag references the commit in which this logic was added, it
>> has since been shuffled around to a different file, but it's the one
>> where it originates from.
>>
>> Fixes: f80a1d414328 ("interconnect: qcom: Add SDM660 interconnect provider driver")
>> Signed-off-by: Konrad Dybcio <[email protected]>
>> ---
>> drivers/interconnect/qcom/icc-rpm.c | 6 ++++--
>> 1 file changed, 4 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/interconnect/qcom/icc-rpm.c b/drivers/interconnect/qcom/icc-rpm.c
>> index 06e0fee547ab..a190a0a839c8 100644
>> --- a/drivers/interconnect/qcom/icc-rpm.c
>> +++ b/drivers/interconnect/qcom/icc-rpm.c
>> @@ -252,8 +252,10 @@ static int __qcom_icc_set(struct icc_node *n, struct qcom_icc_node *qn,
>> ret = qcom_icc_rpm_set(qn->mas_rpm_id, qn->slv_rpm_id, sum_bw);
>> if (ret)
>> return ret;
>> - } else if (qn->qos.qos_mode != -1) {
>> - /* set bandwidth directly from the AP */
>> + }
>> +
>> + if (qn->qos.qos_mode != NOC_QOS_MODE_INVALID) {
>> + /* Set QoS params from the AP */
>> ret = qcom_icc_qos_set(n, sum_bw);
>> if (ret)
>> return ret;
>
> Taking the example of
>
> static struct qcom_icc_node bimc_snoc_slv = {
> .name = "bimc_snoc_slv",
> .id = MSM8939_BIMC_SNOC_SLV,
> .buswidth = 16,
> .mas_rpm_id = -1,
> .slv_rpm_id = 2,
> .num_links = ARRAY_SIZE(bimc_snoc_slv_links),
> .links = bimc_snoc_slv_links,
> };
>
> #define NOC_QOS_MODE_INVALID -1
> ap_owned == false
> qos_mode == NOC_QOS_MODE_FIXED
>
>
> if (!qn->qos.ap_owned) {
> /* bod: this will run */
> /* send bandwidth request message to the RPM processor */
> ret = qcom_icc_rpm_set(qn->mas_rpm_id, qn->slv_rpm_id, sum_bw);
> if (ret)
> return ret;
> } else if (qn->qos.qos_mode != -1) {
> /* bod: this will not run */
> /* set bandwidth directly from the AP */
> ret = qcom_icc_qos_set(n, sum_bw);
> if (ret)
> return ret;
> }
>
> and your proposed change
>
> if (!qn->qos.ap_owned) {
> /* bod: this will run */
> /* send bandwidth request message to the RPM processor */
> ret = qcom_icc_rpm_set(qn->mas_rpm_id, qn->slv_rpm_id, sum_bw);
> if (ret)
> return ret;
> }
>
> if (qn->qos.qos_mode != NOC_QOS_MODE_INVALID) {
> /* bod: this will run */
> /* set bandwidth directly from the AP */
> ret = qcom_icc_qos_set(n, sum_bw);
> if (ret)
> return ret;
> }
>
> however if we look downstream we have the concept of ap_owned
>
> https://git.codelinaro.org/clo/la/kernel/msm-3.18/-/blob/LA.BR.1.2.9-00810-8x09.0/drivers/platform/msm/msm_bus/msm_bus_fabric_adhoc.c#L194
>
> https://git.codelinaro.org/clo/la/kernel/msm-3.18/-/blob/LA.BR.1.2.9-00810-8x09.0/drivers/platform/msm/msm_bus/msm_bus_fabric_adhoc.c#L208
>
> In simple terms
> if (node_info->ap_owned) {
> ret = fabdev->noc_ops.set_bw(node_info,
> } else {
> ret = send_rpm_msg(node_device);
> }
>
> I agree your code does what it says on the tin but, whats the overall justification to depart from the downstream logic ?
Okay, so maybe it would be worth checking with Qualcomm what it's
supposed to do. On msm-5.4 setting QoS is done unconditionally,
no matter if the node has valid (!= -1) rpm mas/slv IDs.
https://github.com/sonyxperiadev/kernel/blob/aosp/LA.UM.9.14.r1/drivers/interconnect/qcom/icc-rpm.c#L97
It may be something that began with newer SoCs, or maybe the
carried-with-us-ever-since-3.4 chonky msm_bus driver had a bug..
or maybe the msm-5.4 interconnect impl has a bug.. We really
won't know unless somebody can confirm it for us..
My understanding would be such that the QoS parameters are always
set from the AP and RPM just scales the bandwidth on certain nodes,
like it scales power and frequency for some lines/devices. That
may or may not be true or might also depend on the SoC / RPM fw..
And even if RPM sets these values internally, it shouldn't hurt to
adjust them from AP again, but that would both deserve a different
comment and would be a rather bad design, as tuning the values
would require a rpm firmware update (and we know how vendors treat
firmware updates), so that might have been something qc engineers
took into account..
tldr: new soc good (*), old soc bad-or-no-effect (*), should ask QC
Konrad
>
> ---
> bod
On 4.01.2023 00:43, Bryan O'Donoghue wrote:
> On 03/01/2023 17:30, Konrad Dybcio wrote:
>> QoS parameters and RPM bandwidth requests are wholly separate. Setting one
>> should only depend on the description of the interconnect node and not
>> whether the other is present. If we vote through RPM, QoS parameters
>> should be set so that the bus controller can make better decisions.
>
> Is that true ?
>
>> If we don't vote through RPM, QoS parameters should be set regardless,
>> as we're requesting additional bandwidth by setting the interconnect
>> clock rates.
>>
>> The Fixes tag references the commit in which this logic was added, it
>> has since been shuffled around to a different file, but it's the one
>> where it originates from.
>>
>> Fixes: f80a1d414328 ("interconnect: qcom: Add SDM660 interconnect provider driver")
>> Signed-off-by: Konrad Dybcio <[email protected]>
>> ---
>> drivers/interconnect/qcom/icc-rpm.c | 6 ++++--
>> 1 file changed, 4 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/interconnect/qcom/icc-rpm.c b/drivers/interconnect/qcom/icc-rpm.c
>> index 06e0fee547ab..a190a0a839c8 100644
>> --- a/drivers/interconnect/qcom/icc-rpm.c
>> +++ b/drivers/interconnect/qcom/icc-rpm.c
>> @@ -252,8 +252,10 @@ static int __qcom_icc_set(struct icc_node *n, struct qcom_icc_node *qn,
>> ret = qcom_icc_rpm_set(qn->mas_rpm_id, qn->slv_rpm_id, sum_bw);
>> if (ret)
>> return ret;
>> - } else if (qn->qos.qos_mode != -1) {
>> - /* set bandwidth directly from the AP */
>> + }
>> +
>> + if (qn->qos.qos_mode != NOC_QOS_MODE_INVALID) {
>> + /* Set QoS params from the AP */
>> ret = qcom_icc_qos_set(n, sum_bw);
>> if (ret)
>> return ret;
>
> Taking the example of
>
> static struct qcom_icc_node bimc_snoc_slv = {
> .name = "bimc_snoc_slv",
> .id = MSM8939_BIMC_SNOC_SLV,
> .buswidth = 16,
> .mas_rpm_id = -1,
> .slv_rpm_id = 2,
> .num_links = ARRAY_SIZE(bimc_snoc_slv_links),
> .links = bimc_snoc_slv_links,
> };
>
> #define NOC_QOS_MODE_INVALID -1
> ap_owned == false
> qos_mode == NOC_QOS_MODE_FIXED
>
>
> if (!qn->qos.ap_owned) {
> /* bod: this will run */
> /* send bandwidth request message to the RPM processor */
> ret = qcom_icc_rpm_set(qn->mas_rpm_id, qn->slv_rpm_id, sum_bw);
> if (ret)
> return ret;
> } else if (qn->qos.qos_mode != -1) {
> /* bod: this will not run */
> /* set bandwidth directly from the AP */
> ret = qcom_icc_qos_set(n, sum_bw);
> if (ret)
> return ret;
> }
>
> and your proposed change
>
> if (!qn->qos.ap_owned) {
> /* bod: this will run */
> /* send bandwidth request message to the RPM processor */
> ret = qcom_icc_rpm_set(qn->mas_rpm_id, qn->slv_rpm_id, sum_bw);
> if (ret)
> return ret;
> }
>
> if (qn->qos.qos_mode != NOC_QOS_MODE_INVALID) {
> /* bod: this will run */
Also, this will not run with the next patch, perhaps i should
have ordered them differently (or perhaps the issue it solves
should have never been introduced :P).
Konrad
> /* set bandwidth directly from the AP */
> ret = qcom_icc_qos_set(n, sum_bw);
> if (ret)
> return ret;
> }
>
> however if we look downstream we have the concept of ap_owned
>
> https://git.codelinaro.org/clo/la/kernel/msm-3.18/-/blob/LA.BR.1.2.9-00810-8x09.0/drivers/platform/msm/msm_bus/msm_bus_fabric_adhoc.c#L194
>
> https://git.codelinaro.org/clo/la/kernel/msm-3.18/-/blob/LA.BR.1.2.9-00810-8x09.0/drivers/platform/msm/msm_bus/msm_bus_fabric_adhoc.c#L208
>
> In simple terms
> if (node_info->ap_owned) {
> ret = fabdev->noc_ops.set_bw(node_info,
> } else {
> ret = send_rpm_msg(node_device);
> }
>
> I agree your code does what it says on the tin but, whats the overall justification to depart from the downstream logic ?
>
> ---
> bod
On 04/01/2023 00:39, Konrad Dybcio wrote:
> tldr: new soc good (*), old soc bad-or-no-effect (*), should ask QC
I think this needs to be tested before application. If it is benign on <
kernel 5.4 SoCs then that's fine too but, it does need to be validated
as so.
I suspect there's no silicon dependency, it is probably "just how the
code was written" without any silicon dependency backing it up but, I
think we need to do the work to prove that before applying.
An RFT with some interconnect settings targeted for test on pre 5.4 and
post 5.4 SoCs would do.
---
bod