Re: [PATCH 0/4] media: qcom: camss: share VFE clock sources on SM8250

[Atanas Filipov]

On 23/10/2026 22:44, Bryan O'Donoghue wrote:
> On 23/10/2026 16:28, Atanas Filipov wrote:
>> The aggregation only covers the CAMSS VFEs. Drivers outside CAMSS that
>> use the same shared clock sources are not covered and are left to a
>> separate change.
>
> Lets discuss that change so. We need to represent shared clocks through
> CamNoC anyway right ?

Yes. The camera NoC AXI clock is shared by everything that writes
through the camera NoC: the CAMSS front ends, and offline engines such
as OPE and JPEG that are separate devices. Today no one aggregates
their requests.

I have posted two versions of this so far:

  - v2 added a CAMNOC interconnect provider with one port per client:
    https://lore.kernel.org/all/20260819093211.1436275-1-atanas.filipov@xxxxxxxxxxxxxxxx/
  - v3 exports the camcc camera NoC AXI RCG through icc-clk, as
    gcc-ipq9574 does:
    https://lore.kernel.org/all/20261016170701.1504338-1-atanas.filipov@xxxxxxxxxxxxxxxx/

On v3 Krzysztof objected that a clock is not an interconnect and
suggested fixing the clock framework instead. Dmitry asked to land
icc-clk first, then the optional CAMSS interconnect, then JPEG. Both
questions are still open. Gjorgji summarised the two options in this
thread.

This series does not depend on that choice. It only stops the VFEs
from overriding each other inside CAMSS. Once the camera NoC is
represented, the VFE stops setting the camera NoC AXI rate and votes
instead; I have that change ready on top of v3.

Which direction do you prefer: per-client ports in a CAMNOC provider
(v2), icc-clk on the camcc RCG (v3), or the clock framework?

Regards,
Atanas