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

[Kathiravan Thirumoorthy]

On 10/16/2026 7:42 PM, Konrad Dybcio wrote:
> On 10/7/26 8:50 AM, 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):
> [...]
>
> > -	return clk_set_rate(qn->clk, icc_units_to_bps(src->peak_bw));
> > +	/*
> > +	 * Multiple master nodes can share the same underlying clock (N:1
> > +	 * topology, e.g. several CPU clusters voting on one L3 clock).
> > +	 * Aggregate the peak bandwidth across all of them before setting
> > +	 * the rate, otherwise the last caller wins and can undervote what
> > +	 * another master already asked for.
> > +	 */
> > +	list_for_each_entry(node, &provider->nodes, node_list) {
> > +		struct icc_clk_node *n = node->data;
> > +
> > +		if (n && clk_is_match(n->clk, qn->clk))
> > +			rate = max(rate, icc_units_to_bps(node->peak_bw));
> > +	}
> GPT has the following concern:
>
> [P2] Recompute the shared clock rate when a master drops its vote
> drivers/interconnect/icc-clk.c:36-42
>
> The zero-bandwidth path returns before the new shared-clock aggregation.
> If one master had set the shared clock to a high rate and then drops its
> vote while another master still votes, the clock remains at the old,
> higher rate: the remaining master’s icc_clk_set() is not necessarily
> called. Recompute the maximum vote from all nodes sharing the clock on
> this path, and apply that rate when other masters still have votes.

Let me review this and get back.

> Konrad