Re: [PATCH v3 3/3] arm64: dts: qcom: sm8250: add camcc interconnect cells

From: Atanas Filipov

Date: Wed Oct 28 2026 - 14:10:52 EST


On 10/20/2026 3:49 PM, Atanas Filipov wrote:
> On 10/20/2026 12:45 PM, Dmitry Baryshkov wrote:
>> 3. Add minimal VFE nodes and let camss use those. Converge towards the
>> split VFE (IFE) device tree.
>
> Agreed, I will take that up separately. To get it right the first
> time, could you clarify what "minimal" covers:

After going through the options discussed so far, I think the VFE
child nodes you suggested are the right approach for the per-VFE
votes. Below is a concrete proposal. It is separate from this series,
which stays limited to the icc-clk conversion as you asked.

Why a VFE node is needed, not only convenient:

- The VFEs need independent votes for three things: their own clock
rate, the MMCX level that rate requires, and their own bandwidth.
OPP is per device, so this needs one device per VFE.
- VFE and VFE Lite have different rate tables (on SM8250 vfe0/vfe1
350-720 MHz, vfe_lite0/vfe_lite1 400/480 MHz). A single
frequency-keyed OPP table in the CAMSS node cannot describe both.
- Today nothing scales MMCX with the VFE rates: camcc only applies
its fixed required-opps, and CAMSS sets no performance state.

Proposed minimal node, one per VFE, as a child of the camss node:

camss: camss@ac6a000 {
...
vfe0: vfe-0 {
compatible = "qcom,sm8250-vfe";
clocks = <&camcc CAM_CC_IFE_0_CLK>;
clock-names = "core";
power-domains = <&camcc IFE_0_GDSC>,
<&rpmhpd RPMHPD_MMCX>;
power-domain-names = "ife", "mmcx";
interconnects = <&mmss_noc MASTER_CAMNOC_HF 0
&mc_virt SLAVE_EBI_CH0 0>,
<&camcc MASTER_CAMCC_CAMNOC_AXI
&camcc SLAVE_CAMCC_CAMNOC_AXI>;
interconnect-names = "hf", "camnoc_axi";
operating-points-v2 = <&vfe_opp_table>;
};
...
};

- Only what is needed for the votes moves: the core clock, the
power domains, the OPP table with required-opps, and the
interconnect paths. reg, interrupts and the remaining clocks stay
in the camss node for now.
- VFE and VFE Lite get separate compatibles and separate OPP tables;
VFE nodes of the same kind share one table.
- CAMSS populates the children and uses each child device for
dev_pm_opp_set_rate() and its ICC path. The OPP core then sets the
clock and the MMCX level, genpd takes the highest level across the
VFEs and the other MMCX consumers, and the interconnect core
aggregates the bandwidth with the other camera consumers.
- Without the child nodes CAMSS keeps its current behaviour, so older
DTs keep working.

Child nodes keep the camss node as the single entry point and keep
the change small for existing DTs. reg and interrupts are not needed
for the votes, so I would leave them in the camss node; moving them
would only make the child nodes look complete without changing what
the driver can do.

Does this match what you had in mind?

--
Best regards,
Atanas