public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Georgi Djakov <djakov@kernel.org>
To: Konrad Dybcio <konrad.dybcio@linaro.org>,
	Andy Gross <agross@kernel.org>,
	Bjorn Andersson <andersson@kernel.org>,
	Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Cc: Bryan O'Donoghue <bryan.odonoghue@linaro.org>,
	linux-arm-msm@vger.kernel.org, linux-pm@vger.kernel.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH v7 2/9] interconnect: qcom: rpm: Add support for specifying channel num
Date: Tue, 21 Mar 2023 16:49:24 +0200	[thread overview]
Message-ID: <b3ef4fb6-91c7-1730-ceef-22fa3ef08e4e@kernel.org> (raw)
In-Reply-To: <101834f0-e00c-5469-c8a5-59a00a5160a5@linaro.org>

On 21.03.23 16:23, Konrad Dybcio wrote:
> 
> 
> On 21.03.2023 15:21, Georgi Djakov wrote:
>> On 21.03.23 16:09, Konrad Dybcio wrote:
>>>
>>> On 21.03.2023 15:06, Georgi Djakov wrote:
>>>> Hi Konrad,
>>>>
>>>> Thanks for the patch!
>>>>
>>>> On 8.03.23 23:40, Konrad Dybcio wrote:
>>>>> 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.
>>>>>
>>>>
>>>> This looks good, but do you have any follow-up patch to use this and set
>>>> the channels in some driver?
>>> Yes, I have a couple of OOT drivers that are gonna make use of it.
>>> TBF it should have been sent separately from the QoS mess, but I
>>> don't think it's much of an issue to take it as-is.
>>>
>>> The aforementioned OOT drivers for MSM8998 and SM6375 will be
>>> submitted after we reach a consensus on how we want to ensure
>>> that each node is guaranteed to have its clocks enabled before
>>> access, among some other minor things.
>>
>> Yes, these QoS clocks are confusing. Maybe you can even submit them
>> without configuring any QoS stuff in first place? Does enabling QoS
>> actually show any benefits on these devices?
> Haven't tested that thoroughly to be honest. But I'll try to get
> some numbers.

I expect this to have impact only on some latency sensitive stuff like
modem or when there is heavy traffic flows. Maybe we can start without
QoS first and then add it on top as a next step?

BR,
Georgi

> 
> Konrad
>>
>> Thanks,
>> Georgi
>>
>>> Konrad
>>>>
>>>> BR,
>>>> Georgi
>>>>
>>>>> Reviewed-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
>>>>> Signed-off-by: Konrad Dybcio <konrad.dybcio@linaro.org>
>>>>> ---
>>>>>     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 35fd75ae70e3..27c4c6497994 100644
>>>>> --- a/drivers/interconnect/qcom/icc-rpm.c
>>>>> +++ b/drivers/interconnect/qcom/icc-rpm.c
>>>>> @@ -317,6 +317,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 */
>>>>> @@ -334,7 +335,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];
>>>>>
>>>>
>>


  reply	other threads:[~2023-03-21 14:49 UTC|newest]

Thread overview: 41+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-03-08 21:40 [PATCH v7 0/9] The great interconnecification fixation Konrad Dybcio
2023-03-08 21:40 ` [PATCH v7 1/9] interconnect: qcom: rpm: make QoS INVALID default Konrad Dybcio
2023-03-11 13:52   ` Dmitry Baryshkov
2023-03-08 21:40 ` [PATCH v7 2/9] interconnect: qcom: rpm: Add support for specifying channel num Konrad Dybcio
2023-03-11 13:54   ` Dmitry Baryshkov
2023-03-21 14:06   ` Georgi Djakov
2023-03-21 14:09     ` Konrad Dybcio
2023-03-21 14:21       ` Georgi Djakov
2023-03-21 14:23         ` Konrad Dybcio
2023-03-21 14:49           ` Georgi Djakov [this message]
2023-03-21 17:33             ` Konrad Dybcio
2023-03-08 21:40 ` [PATCH v7 3/9] interconnect: qcom: Sort kerneldoc entries Konrad Dybcio
2023-03-11 13:54   ` Dmitry Baryshkov
2023-03-08 21:40 ` [PATCH v7 4/9] interconnect: qcom: rpm: Rename icc desc clocks to bus_blocks Konrad Dybcio
2023-03-08 21:40 ` [PATCH v7 5/9] interconnect: qcom: rpm: Rename icc provider num_clocks to num_bus_clocks Konrad Dybcio
2023-03-08 21:40 ` [PATCH v7 6/9] interconnect: qcom: rpm: Handle interface clocks Konrad Dybcio
2023-03-10 14:21   ` Bryan O'Donoghue
2023-03-10 14:26     ` Konrad Dybcio
2023-03-10 16:47       ` Bryan O'Donoghue
2023-03-10 18:05         ` Konrad Dybcio
2023-03-11  0:16           ` Bryan O'Donoghue
2023-03-11  0:54             ` Konrad Dybcio
2023-03-11 12:11               ` Bryan O'Donoghue
2023-03-11 12:36                 ` Konrad Dybcio
2023-03-11 13:32                 ` Dmitry Baryshkov
2023-03-11 14:01   ` Dmitry Baryshkov
2023-03-11 14:29     ` Bryan O'Donoghue
2023-03-11 14:35       ` Dmitry Baryshkov
2023-03-11 14:38         ` Bryan O'Donoghue
2023-03-11 15:26           ` Dmitry Baryshkov
2023-03-21 13:58             ` Georgi Djakov
2023-03-21 14:11               ` Konrad Dybcio
2023-03-21 14:38                 ` Georgi Djakov
2023-03-21 17:38                   ` Georgi Djakov
2023-03-21 13:56   ` Georgi Djakov
2023-03-21 14:23     ` Konrad Dybcio
2023-03-08 21:40 ` [PATCH v7 7/9] interconnect: qcom: icc-rpm: Enforce 2 or 0 bus clocks Konrad Dybcio
2023-03-08 21:40 ` [PATCH v7 8/9] interconnect: qcom: rpm: Don't use clk_get_optional for bus clocks anymore Konrad Dybcio
2023-03-08 21:40 ` [PATCH v7 9/9] interconnect: qcom: msm8996: Promote to core_initcall Konrad Dybcio
2023-03-10 14:23   ` Bryan O'Donoghue
2023-03-10 14:27     ` 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=b3ef4fb6-91c7-1730-ceef-22fa3ef08e4e@kernel.org \
    --to=djakov@kernel.org \
    --cc=agross@kernel.org \
    --cc=andersson@kernel.org \
    --cc=bryan.odonoghue@linaro.org \
    --cc=dmitry.baryshkov@linaro.org \
    --cc=konrad.dybcio@linaro.org \
    --cc=linux-arm-msm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pm@vger.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox