[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <9d6b7e9d-1656-408d-ae8b-4b3dc95ba905@oss.qualcomm.com>
Date: Mon, 20 Oct 2025 11:38:58 -0700
From: Vijay Kumar Tumati <vijay.tumati@....qualcomm.com>
To: Hangxiang Ma <hangxiang.ma@....qualcomm.com>,
Konrad Dybcio <konrad.dybcio@....qualcomm.com>,
Vladimir Zapolskiy <vladimir.zapolskiy@...aro.org>,
Loic Poulain <loic.poulain@....qualcomm.com>,
Robert Foss
<rfoss@...nel.org>, Andi Shyti <andi.shyti@...nel.org>,
Rob Herring <robh@...nel.org>,
Krzysztof Kozlowski <krzk+dt@...nel.org>,
Conor Dooley <conor+dt@...nel.org>, Todor Tomov <todor.too@...il.com>,
Mauro Carvalho Chehab <mchehab@...nel.org>,
Bryan O'Donoghue <bryan.odonoghue@...aro.org>
Cc: linux-i2c@...r.kernel.org, linux-arm-msm@...r.kernel.org,
devicetree@...r.kernel.org, linux-kernel@...r.kernel.org,
linux-media@...r.kernel.org, aiqun.yu@....qualcomm.com,
tingwei.zhang@....qualcomm.com, trilok.soni@....qualcomm.com,
yijie.yang@....qualcomm.com,
Jingyi Wang <jingyi.wang@....qualcomm.com>,
Atiya Kailany <atiya.kailany@....qualcomm.com>
Subject: Re: [PATCH v2 1/6] dt-bindings: i2c: qcom-cci: Document Kaanapali
compatible
On 10/19/2025 9:13 PM, Hangxiang Ma wrote:
> On 10/16/2025 3:56 PM, Konrad Dybcio wrote:
>> On 10/16/25 3:56 AM, Hangxiang Ma wrote:
>>> On 10/16/2025 3:30 AM, Vladimir Zapolskiy wrote:
>>>
>>>> On 10/15/25 05:56, Hangxiang Ma wrote:
>>>>> Add Kaanapali compatible consistent with CAMSS CCI interfaces. The
>>>>> list
>>>>> of clocks for Kaanapali requires its own compat string 'cam_top_ahb',
>>>>> aggregated into 'qcom,qcm2290-cci' node.
>>>>>
>>>>> Signed-off-by: Hangxiang Ma <hangxiang.ma@....qualcomm.com>
>>>>> ---
>>>>> Documentation/devicetree/bindings/i2c/qcom,i2c-cci.yaml | 6 +++++-
>>>>> 1 file changed, 5 insertions(+), 1 deletion(-)
>>>>>
>>>>> diff --git
>>>>> a/Documentation/devicetree/bindings/i2c/qcom,i2c-cci.yaml
>>>>> b/Documentation/devicetree/bindings/i2c/qcom,i2c-cci.yaml
>>>>> index 9bc99d736343..0140c423f6f4 100644
>>>>> --- a/Documentation/devicetree/bindings/i2c/qcom,i2c-cci.yaml
>>>>> +++ b/Documentation/devicetree/bindings/i2c/qcom,i2c-cci.yaml
>>>>> @@ -25,6 +25,7 @@ properties:
>>>>> - items:
>>>>> - enum:
>>>>> + - qcom,kaanapali-cci
>>>>> - qcom,qcm2290-cci
>>>>> - qcom,sa8775p-cci
>>>>> - qcom,sc7280-cci
>>>>> @@ -128,6 +129,7 @@ allOf:
>>>>> compatible:
>>>>> contains:
>>>>> enum:
>>>>> + - qcom,kaanapali-cci
>>>>> - qcom,qcm2290-cci
>>>>> then:
>>>>> properties:
>>>>> @@ -136,7 +138,9 @@ allOf:
>>>>> maxItems: 2
>>>>> clock-names:
>>>>> items:
>>>>> - - const: ahb
>>>>> + - enum:
>>>>> + - ahb
>>>>> + - cam_top_ahb
>>>>
>>>> Why is not to give the clock "ahb" name like on QCM2290?
>>>>
>>>> On QCM2290 the macro in front of the vlaue is GCC_CAMSS_TOP_AHB_CLK,
>>>> and name "ahb" is good for both, I believe.
>>>>
>>>>> - const: cci
>>>>> - if:
>>>>>
>>>>
>>>
>>> On Kaanapali the macro has been changed to CAM_CC_CAM_TOP_AHB_CLK.
>>> GCC clock domain doesn't manage the AHB clock but CAMCC does. I
>>> think it's better to create a new and more complete clock name to
>>> denote the differences between them.
>>
>> Are there any other "AHB" clocks going to this block?
>>
>> If not, then this is more confusing instead
>>
>> Konrad
>
> On 10/16/2025 6:40 PM, Krzysztof Kozlowski wrote:
>> On 16/10/2025 03:56, Hangxiang Ma wrote:
>>>>
>>>> On QCM2290 the macro in front of the vlaue is GCC_CAMSS_TOP_AHB_CLK,
>>>> and name "ahb" is good for both, I believe.
>>>>
>>>>> - const: cci
>>>>> - if:
>>>>>
>>>>
>>>
>>> On Kaanapali the macro has been changed to CAM_CC_CAM_TOP_AHB_CLK. GCC
>>
>>
>> It seems you do not see the difference between GCC output clock and
>> actual clock input so some other block.
>>
>>
>>
>> Best regards,
>> Krzysztof
>
> No more clocks will be added, at least for KNP. And I acknowledge the
> substance of AHB clock doesn't change. I will update and keep AHB
> clock name the same as QCM2290. Thanks for both of you. @Konrad
> @Krzysztof
>
> ---
> Hangxiang
There are several AHB clocks into the Titan subsystem, TOP AHB, core
(TFE, OFE, IPE, IFE Lit etc.)level AHBs and fast and / or slow AHB
variants of some of those, AHBs to the firmwares etc. It should be
similar for any architecture, if I am not wrong. So should we consider
using "cam_top_ahb" for it to be clear commonly for both Kaanapali and
2290? Thanks.
>
>
Powered by blists - more mailing lists