Re: [PATCH v2 2/3] interconnect: qcom: Add CAMNOC interconnect provider driver

[Konrad Dybcio]

On 9/9/26 2:58 PM, Gjorgji Rosikopulos (Consultant) wrote:
> Hi Krzysztof,
> 
> Thanks for the review.
> 
> On 8/27/2026 12:25 PM, Krzysztof Kozlowski wrote:
>> On Wed, Aug 19, 2026 at 12:32:10PM +0300, Atanas Filipov wrote:
>>> Add an ICC provider for the Qualcomm Camera NOC (CAMNOC). Multiple
>>> camera sub-devices share CAM_CC_CAMNOC_AXI_CLK; direct clk_set_rate()
>>> calls from each consumer cause a last-writer-wins race.
>>>
>>> Each consumer obtains an ICC path to SLAVE_CAMNOC_AXI and votes via
>>> icc_set_bw(). The ICC core aggregates votes (max peak_bw) and the
>>> set() callback converts the result to clk_set_rate(). Consumers
>>> encode the required frequency as peak_bw in kBps.
>>>
>>> Signed-off-by: Atanas Filipov <atanas.filipov@xxxxxxxxxxxxxxxx>
>>> ---

[...]

> Maybe those series should be marked as RFC. The basic idea is to manage clocks as interconnect providers,
> similar to this change: https://lore.kernel.org/all/20230512001334.2983048-3-dmitry.baryshkov@xxxxxxxxxx/
> 
> There is requirement to maintain higher clock rate on source clocks and some place to aggregate them.
> One example is camnoc axi clock which is used by jpeg, camss, ope and maybe other drivers.
> The interconnect has already functionality inplace to maintain higher
> bw per request which can be used for maintaining higher clock frequency from requested drivers.
> 
> One option is to use already available icc-clk provider, but we have to add many icc providers
> instead one provider with many ports.

icc-clk provides N clocks, it has M clients voting on each one and
avg/peak bandwidth aggregation happens at the icc core so this
should just work - or are we thinking about different problems?

Konrad