From: Mike Tipton <quic_mdtipton@quicinc.com>
To: Raviteja Laggyshetty <quic_rlaggysh@quicinc.com>
Cc: Georgi Djakov <djakov@kernel.org>, Rob Herring <robh@kernel.org>,
Krzysztof Kozlowski <krzk+dt@kernel.org>,
Conor Dooley <conor+dt@kernel.org>,
Bjorn Andersson <andersson@kernel.org>,
Konrad Dybcio <konradybcio@kernel.org>,
Odelu Kukatla <quic_okukatla@quicinc.com>,
"Jeff Johnson" <jeff.johnson@oss.qualcomm.com>,
Jagadeesh Kona <quic_jkona@quicinc.com>,
Sibi Sankar <quic_sibis@quicinc.com>,
<linux-arm-msm@vger.kernel.org>, <linux-pm@vger.kernel.org>,
<devicetree@vger.kernel.org>, <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH V9 4/7] interconnect: qcom: icc-rpmh: Add dynamic icc node id support
Date: Thu, 6 Mar 2025 19:53:57 -0800 [thread overview]
Message-ID: <20250307035357.GA7435@hu-mdtipton-lv.qualcomm.com> (raw)
In-Reply-To: <20250227155213.404-5-quic_rlaggysh@quicinc.com>
On Thu, Feb 27, 2025 at 03:52:10PM +0000, Raviteja Laggyshetty wrote:
> To facilitate dynamic node ID support, the driver now uses
> node pointers for links instead of static node IDs.
> Additionally, the default node ID is set to -1 to prompt
> the ICC framework for dynamic node ID allocation.
>
> Signed-off-by: Raviteja Laggyshetty <quic_rlaggysh@quicinc.com>
> ---
> drivers/interconnect/qcom/icc-rpmh.c | 16 ++++++++++++++--
> drivers/interconnect/qcom/icc-rpmh.h | 3 ++-
> 2 files changed, 16 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/interconnect/qcom/icc-rpmh.c b/drivers/interconnect/qcom/icc-rpmh.c
> index f2d63745be54..2e654917f535 100644
> --- a/drivers/interconnect/qcom/icc-rpmh.c
> +++ b/drivers/interconnect/qcom/icc-rpmh.c
> @@ -285,13 +285,25 @@ int qcom_icc_rpmh_probe(struct platform_device *pdev)
> ret = PTR_ERR(node);
> goto err_remove_nodes;
> }
> + qn->id = node->id;
>
> node->name = qn->name;
> node->data = qn;
> icc_node_add(node, provider);
>
> - for (j = 0; j < qn->num_links; j++)
> - icc_link_create(node, qn->links[j]);
> + for (j = 0; j < qn->num_links; j++) {
> + struct qcom_icc_node *qn_link_node = qn->link_nodes[j];
> + struct icc_node *link_node;
> +
> + if (qn_link_node) {
> + link_node = icc_node_create(qn_link_node->id);
> + qn_link_node->id = link_node->id;
> + icc_link_create(node, qn_link_node->id);
> + } else {
> + /* backward compatibility for target using static IDs */
> + icc_link_create(node, qn->links[j]);
> + }
> + }
>
> data->nodes[i] = node;
> }
> diff --git a/drivers/interconnect/qcom/icc-rpmh.h b/drivers/interconnect/qcom/icc-rpmh.h
> index 82344c734091..cf4aa69c707c 100644
> --- a/drivers/interconnect/qcom/icc-rpmh.h
> +++ b/drivers/interconnect/qcom/icc-rpmh.h
> @@ -95,7 +95,8 @@ struct qcom_icc_qosbox {
> struct qcom_icc_node {
> const char *name;
> u16 links[MAX_LINKS];
> - u16 id;
> + struct qcom_icc_node *link_nodes[MAX_LINKS];
This is very inefficient. MAX_LINKS = 128, which means we're adding an
additional 1KB *per-node*. The vast majority of nodes don't come
anywhere close to this number of links, so this is almost entirely
unused and wasted space.
As an example: sa8775p has 193 nodes, so we're adding 193K to the driver
from this alone. The current driver size is 84K, and the size after this
change is 283K.
Instead of embedding this array with a hardcoded size, we could point to
an array that's sized for the number of links required by the node:
- struct qcom_icc_node *link_nodes[MAX_LINKS];
+ struct qcom_icc_node **link_nodes;
Then when initializing the arrays, we could:
- .link_nodes = { &qns_a1noc_snoc },
+ .link_nodes = (struct qcom_icc_node *[]) { &qns_a1noc_snoc },
And for handling compatiblity with older drivers, we'd check for
link_nodes != NULL instead of checking the array indices.
Doing it this way would reduce the new sa8775p size from 283K to 88K.
A similar argument could be made for qcom_icc_node::links, since that's
also hardcoded to MAX_LINKS. But it's not quite as bad since it's an
array of u16 rather than an array of pointers. Still, if we implemented
similar changes for qcom_icc_node::links, then we'd save almost 256B
per-node, which for sa8775p would reduce the size by roughly another
50K. If we're ultimately planning on switching all the old drivers over
to link_nodes, then we could just wait and get rid of links entirely.
Regardless, optimizing links doesn't have to happen in this series, but
I don't want to further bloat the size from the addition of link_nodes.
> + int id;
> u16 num_links;
> u16 channels;
> u16 buswidth;
> --
> 2.43.0
>
>
next prev parent reply other threads:[~2025-03-07 3:54 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-02-27 15:52 [PATCH V9 0/7] Add EPSS L3 provider support on SA8775P SoC Raviteja Laggyshetty
2025-02-27 15:52 ` [PATCH V9 1/7] dt-bindings: interconnect: Add EPSS L3 compatible for SA8775P Raviteja Laggyshetty
2025-02-27 15:52 ` [PATCH V9 2/7] interconnect: core: Add dynamic id allocation support Raviteja Laggyshetty
2025-02-27 16:08 ` Dmitry Baryshkov
2025-03-04 5:53 ` Raviteja Laggyshetty
2025-02-27 15:52 ` [PATCH V9 3/7] interconnect: qcom: Add multidev EPSS L3 support Raviteja Laggyshetty
2025-02-27 16:09 ` Dmitry Baryshkov
2025-02-28 0:39 ` Bjorn Andersson
2025-02-27 15:52 ` [PATCH V9 4/7] interconnect: qcom: icc-rpmh: Add dynamic icc node id support Raviteja Laggyshetty
2025-02-27 16:16 ` Dmitry Baryshkov
2025-03-10 2:24 ` Raviteja Laggyshetty
2025-03-11 19:08 ` Dmitry Baryshkov
2025-03-07 3:53 ` Mike Tipton [this message]
2025-03-10 1:58 ` Raviteja Laggyshetty
2025-02-27 15:52 ` [PATCH V9 5/7] interconnect: qcom: sa8775p: " Raviteja Laggyshetty
2025-02-27 16:23 ` Dmitry Baryshkov
2025-03-04 6:20 ` Raviteja Laggyshetty
2025-02-28 0:32 ` Bjorn Andersson
2025-02-27 15:52 ` [PATCH V9 6/7] arm64: dts: qcom: sa8775p: add EPSS l3 interconnect provider Raviteja Laggyshetty
2025-02-27 15:52 ` [PATCH V9 7/7] arm64: dts: qcom: sa8775p: Add CPU OPP tables to scale DDR/L3 Raviteja Laggyshetty
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=20250307035357.GA7435@hu-mdtipton-lv.qualcomm.com \
--to=quic_mdtipton@quicinc.com \
--cc=andersson@kernel.org \
--cc=conor+dt@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=djakov@kernel.org \
--cc=jeff.johnson@oss.qualcomm.com \
--cc=konradybcio@kernel.org \
--cc=krzk+dt@kernel.org \
--cc=linux-arm-msm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=quic_jkona@quicinc.com \
--cc=quic_okukatla@quicinc.com \
--cc=quic_rlaggysh@quicinc.com \
--cc=quic_sibis@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®