Re: [PATCH v3 1/3] dt-bindings: clock: qcom,camcc-sm8250: add interconnect provider

[Bryan O'Donoghue]

On 28/10/2026 19:10, Atanas Filipov wrote:
> What clock votes cannot express is why I think the camera NoC is an
> interconnect:
>
>   - The camera NoC is a bus with several independent masters: the VFE
>     write ports, JPEG and OPE. They share it on the way to the MMSS NoC,
>     and the camnoc AXI clock sets its throughput.

I've always conceptually viewed the CamNoc as just another NoC that 
happens to live inside of the TITAN_TOP_GDSC power-island.

I think the trouble here is the CAMNOC_AXI_CLK is just one clock, it's 
not interconnecting any two things at all.

Noc entries in DT usually look like

interconnects = <&gem_noc MASTER_AMPSS_M0 0
		 &config_noc SLAVE_VENUS_CFG 0>,
		<&mmss_noc MASTER_VIDEO_P0 0 &mc_virt SLAVE_EBI_CH0 0>;
		interconnect-names = "cpu-cfg", "video-mem";

In the second case we're connecting an MMSS port to a DRAM port i.e. two 
completely separate producers/consumers and we have specific ports that 
RPM/RPMh is involved in managing.

Which is not the case for CamNoc - here really we have some shared 
clocks which we need to calculate across components within the Camera 
power-island.

In downstream the CPAs code does that.

- icc-clk would I think over-provision clocks
- CCF would as you've observed under-provision

- But a CPA's analog in upstream which components set/consume ?

That would work.

After all what we are doing here _is_ specific to how camera works. We 
don't really have many - any ? other examples in Qcom SoCs where we lump 
a number of different semi-independent components into one area - ICP, 
CDM, VFE, JPEG and ask them to share aggregated clocks - in a way that 
is specific to - guessing but - specific to how these components get 
modeled in silicon test benches.

My vote is to replicate CPAs in upstream with a CPA's icc provider driver.

The bandwidth calculations are already proven out in downstream and if 
we get it right - potentially its something downstream could switch to.

We could even use the interconnect API inside of the CPA's driver but, I 
think just doing votes via interconnect and icc_set_bw() into icc-clk in 
the drivers directly won't produce the same bandwidth calculations we 
have in downstream - which you may loathe downstream code but the clock 
calculations we'd assume are ~ a pretty good starting point.

So; make the CPAs driver an icc provider.

cpas_icc_set() could/should absorb the downstream cam_cpas_hw.c 
heuristic for calculating the aggregate clocks.

Its not represented in generic icc-clk right now and as we add in more 
clocks/SoCs this disparity will grow.

---
bod