Re: [PATCH 1/4] interconnect: icc-clk: support N:1 master-to-slave topology

[Dmitry Baryshkov]

On Wed, Oct 07, 2026 at 12:20:44PM +0530, Kathiravan Thirumoorthy wrote:
> icc_clk_register() assumes each icc_clk_data entry describes a unique
> master/slave pair and creates both nodes for every entry. When several
> masters share the same slave_id, the shared slave node is created and
> added again on each later entry. icc_node_create() returns the existing
> node, so icc_node_add() hits WARN_ON(node->provider):
> 
>   WARNING: drivers/interconnect/core.c:1103 at icc_node_add+0x10c/0x120
>   Call trace:
>    icc_node_add+0x10c/0x120 (P)
>    icc_clk_register+0x1a4/0x214
>    devm_icc_clk_register+0x18/0x80
>    qcom_cc_really_probe+0x4c8/0x514
>    apss_ipq9650_probe+0xc0/0x108
> 
> This topology is needed on IPQ9650, where the silver and gold CPU
> clusters both vote on the single L3 clock through a shared SLAVE_L3
> node.

If you have a single L3 clock, why do you need multiple masters? Can't
each cluster get its own handle of same path and let icc core aggregate
those? You might need to have a different voting mechanism (i.e. vote on
the sum of bandwidths instead of voting on the max).

> The onecell table is also filled in registration order, so xlate only
> works when the node IDs happen to match that order. Size the table by
> the highest node ID, index it by ID, and skip slave creation when the
> node is already registered.
> 
> icc_clk_set() also passes only the requesting node's bandwidth to
> clk_set_rate(), so the last writer wins. A low vote from one master can
> then lower the clock below what another master asked for. Before setting
> the rate, take the highest peak bandwidth across all nodes that share
> the clock.
> 
> Signed-off-by: Kathiravan Thirumoorthy <kathiravan.thirumoorthy@xxxxxxxxxxxxxxxx>
> ---
>  drivers/interconnect/icc-clk.c | 45 +++++++++++++++++++++++++++++++++++-------
>  1 file changed, 38 insertions(+), 7 deletions(-)

-- 
With best wishes
Dmitry