On 1/17/26 12:54 PM, Krzysztof Kozlowski wrote:
> On Fri, Jan 16, 2026 at 02:38:56PM +0100, Luca Weiss wrote:
>> Add Milos compatible for the CAMSS CCI interfaces.
>>
>> Signed-off-by: Luca Weiss <[email protected]>
>> ---
>> .../devicetree/bindings/i2c/qcom,i2c-cci.yaml | 18
>> ++++++++++++++++++
>> 1 file changed, 18 insertions(+)
>>
>> diff --git a/Documentation/devicetree/bindings/i2c/qcom,i2c-cci.yaml
>> b/Documentation/devicetree/bindings/i2c/qcom,i2c-cci.yaml
>> index a3fe1eea6aec..c57d81258fba 100644
>> --- a/Documentation/devicetree/bindings/i2c/qcom,i2c-cci.yaml
>> +++ b/Documentation/devicetree/bindings/i2c/qcom,i2c-cci.yaml
>> @@ -27,6 +27,7 @@ properties:
>> - items:
>> - enum:
>> - qcom,kaanapali-cci
>> + - qcom,milos-cci
>> - qcom,qcm2290-cci
>> - qcom,sa8775p-cci
>> - qcom,sc7280-cci
>> @@ -263,6 +264,23 @@ allOf:
>> - const: cpas_ahb
>> - const: cci
>>
>> + - if:
>> + properties:
>> + compatible:
>> + contains:
>> + enum:
>> + - qcom,milos-cci
>> + then:
>> + properties:
>> + clocks:
>> + minItems: 3
>> + maxItems: 3
>> + clock-names:
>> + items:
>> + - const: soc_ahb
>> + - const: cpas_ahb
>> + - const: cci
>
> Same comments as other discussion these days - I guess that soc_ahb
> serves the same purpose as camnoc_axi, so this is just last entri in the
> if:then: blocks.
>
> I really find this binding terrible - around six names for AHB - so I do
> not want another combination...
I dug up the CCI doc, it talks about the CCI having a CC_CCI_CLK clock ("cci"
here) and a CC_PBUS_CLK (AHB interface to the rest of the SoC).
The CAMSS TOP doc (for Milos specifically, but I would assume there's a
pattern) says that for access to CCI_0, I need to enable CAM_CC_CPAS_AHB_CLK
and CAM_CC_CCI_0_CLK. CPAS is a wrapper inside CAMSS that contains most of
the programmable IPs on there (notably not the CSIPHYs, at least not on this
platform)
It further mentions that GCC_SOC_AHB_CLK is required for *any* register
access within CAMSS. Perhaps it sits right in front of the xNoC-to-CAMNoC
interface.
This only enforces my imagination of CAMSS being a fully contained "bus"
(perhaps somewhat like AxNOC on 8996 represented with a simple-pm-bus)..
+Dmitry, myself and a number of our colleagues were deliberating how to
best represent the hardware going forward and I think we at some point waved
the idea of putting every camera subdevice under a "camss: bus@ {}"-type node,
which would hold the reference to the TITAN_TOP_GDSC. This seems fitting for
housing the SOC_AHB clock as well and therefore concluding this discussion.
Konrad
