* [PATCH v2 1/6] dt-bindings: i2c: qcom-cci: Document Kaanapali compatible
2025-10-15 2:56 [PATCH v2 0/6] media: qcom: camss: Add Kaanapali support Hangxiang Ma
@ 2025-10-15 2:56 ` Hangxiang Ma
2025-10-15 19:30 ` Vladimir Zapolskiy
2025-10-15 2:56 ` [PATCH v2 2/6] dt-bindings: media: camss: Add qcom,kaanapali-camss binding Hangxiang Ma
` (4 subsequent siblings)
5 siblings, 1 reply; 46+ messages in thread
From: Hangxiang Ma @ 2025-10-15 2:56 UTC (permalink / raw)
To: Loic Poulain, Robert Foss, Andi Shyti, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Todor Tomov,
Vladimir Zapolskiy, Mauro Carvalho Chehab, Bryan O'Donoghue
Cc: linux-i2c, linux-arm-msm, devicetree, linux-kernel, linux-media,
aiqun.yu, tingwei.zhang, trilok.soni, yijie.yang, Jingyi Wang,
Atiya Kailany, Hangxiang Ma
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@oss.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
- const: cci
- if:
--
2.34.1
^ permalink raw reply related [flat|nested] 46+ messages in thread* Re: [PATCH v2 1/6] dt-bindings: i2c: qcom-cci: Document Kaanapali compatible
2025-10-15 2:56 ` [PATCH v2 1/6] dt-bindings: i2c: qcom-cci: Document Kaanapali compatible Hangxiang Ma
@ 2025-10-15 19:30 ` Vladimir Zapolskiy
2025-10-16 1:56 ` Hangxiang Ma
0 siblings, 1 reply; 46+ messages in thread
From: Vladimir Zapolskiy @ 2025-10-15 19:30 UTC (permalink / raw)
To: Hangxiang Ma, Loic Poulain, Robert Foss, Andi Shyti, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Todor Tomov,
Mauro Carvalho Chehab, Bryan O'Donoghue
Cc: linux-i2c, linux-arm-msm, devicetree, linux-kernel, linux-media,
aiqun.yu, tingwei.zhang, trilok.soni, yijie.yang, Jingyi Wang,
Atiya Kailany
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@oss.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:
>
--
Best wishes,
Vladimir
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: [PATCH v2 1/6] dt-bindings: i2c: qcom-cci: Document Kaanapali compatible
2025-10-15 19:30 ` Vladimir Zapolskiy
@ 2025-10-16 1:56 ` Hangxiang Ma
2025-10-16 7:54 ` Vladimir Zapolskiy
` (2 more replies)
0 siblings, 3 replies; 46+ messages in thread
From: Hangxiang Ma @ 2025-10-16 1:56 UTC (permalink / raw)
To: Vladimir Zapolskiy, Loic Poulain, Robert Foss, Andi Shyti,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Todor Tomov,
Mauro Carvalho Chehab, Bryan O'Donoghue
Cc: linux-i2c, linux-arm-msm, devicetree, linux-kernel, linux-media,
aiqun.yu, tingwei.zhang, trilok.soni, yijie.yang, Jingyi Wang,
Atiya Kailany
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@oss.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.
---
Hangxiang
^ permalink raw reply [flat|nested] 46+ messages in thread* Re: [PATCH v2 1/6] dt-bindings: i2c: qcom-cci: Document Kaanapali compatible
2025-10-16 1:56 ` Hangxiang Ma
@ 2025-10-16 7:54 ` Vladimir Zapolskiy
2025-10-16 7:56 ` Konrad Dybcio
2025-10-16 10:40 ` Krzysztof Kozlowski
2 siblings, 0 replies; 46+ messages in thread
From: Vladimir Zapolskiy @ 2025-10-16 7:54 UTC (permalink / raw)
To: Hangxiang Ma, Loic Poulain, Robert Foss, Andi Shyti, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Todor Tomov,
Mauro Carvalho Chehab, Bryan O'Donoghue
Cc: linux-i2c, linux-arm-msm, devicetree, linux-kernel, linux-media,
aiqun.yu, tingwei.zhang, trilok.soni, yijie.yang, Jingyi Wang,
Atiya Kailany
On 10/16/25 04:56, 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@oss.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.
Remember that you do not match the macro value here. Please provide an
explanation why the intorduced "cam_top_ahb" is anyhow better than the
already exisitng "ahb" name, or please stick to the existing name.
--
Best wishes,
Vladimir
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: [PATCH v2 1/6] dt-bindings: i2c: qcom-cci: Document Kaanapali compatible
2025-10-16 1:56 ` Hangxiang Ma
2025-10-16 7:54 ` Vladimir Zapolskiy
@ 2025-10-16 7:56 ` Konrad Dybcio
2025-10-20 4:13 ` Hangxiang Ma
2025-10-16 10:40 ` Krzysztof Kozlowski
2 siblings, 1 reply; 46+ messages in thread
From: Konrad Dybcio @ 2025-10-16 7:56 UTC (permalink / raw)
To: Hangxiang Ma, Vladimir Zapolskiy, Loic Poulain, Robert Foss,
Andi Shyti, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Todor Tomov, Mauro Carvalho Chehab, Bryan O'Donoghue
Cc: linux-i2c, linux-arm-msm, devicetree, linux-kernel, linux-media,
aiqun.yu, tingwei.zhang, trilok.soni, yijie.yang, Jingyi Wang,
Atiya Kailany
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@oss.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
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: [PATCH v2 1/6] dt-bindings: i2c: qcom-cci: Document Kaanapali compatible
2025-10-16 7:56 ` Konrad Dybcio
@ 2025-10-20 4:13 ` Hangxiang Ma
2025-10-20 18:38 ` Vijay Kumar Tumati
0 siblings, 1 reply; 46+ messages in thread
From: Hangxiang Ma @ 2025-10-20 4:13 UTC (permalink / raw)
To: Konrad Dybcio, Vladimir Zapolskiy, Loic Poulain, Robert Foss,
Andi Shyti, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Todor Tomov, Mauro Carvalho Chehab, Bryan O'Donoghue
Cc: linux-i2c, linux-arm-msm, devicetree, linux-kernel, linux-media,
aiqun.yu, tingwei.zhang, trilok.soni, yijie.yang, Jingyi Wang,
Atiya Kailany
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@oss.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
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: [PATCH v2 1/6] dt-bindings: i2c: qcom-cci: Document Kaanapali compatible
2025-10-20 4:13 ` Hangxiang Ma
@ 2025-10-20 18:38 ` Vijay Kumar Tumati
0 siblings, 0 replies; 46+ messages in thread
From: Vijay Kumar Tumati @ 2025-10-20 18:38 UTC (permalink / raw)
To: Hangxiang Ma, Konrad Dybcio, Vladimir Zapolskiy, Loic Poulain,
Robert Foss, Andi Shyti, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Todor Tomov, Mauro Carvalho Chehab,
Bryan O'Donoghue
Cc: linux-i2c, linux-arm-msm, devicetree, linux-kernel, linux-media,
aiqun.yu, tingwei.zhang, trilok.soni, yijie.yang, Jingyi Wang,
Atiya Kailany
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@oss.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.
>
>
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: [PATCH v2 1/6] dt-bindings: i2c: qcom-cci: Document Kaanapali compatible
2025-10-16 1:56 ` Hangxiang Ma
2025-10-16 7:54 ` Vladimir Zapolskiy
2025-10-16 7:56 ` Konrad Dybcio
@ 2025-10-16 10:40 ` Krzysztof Kozlowski
2 siblings, 0 replies; 46+ messages in thread
From: Krzysztof Kozlowski @ 2025-10-16 10:40 UTC (permalink / raw)
To: Hangxiang Ma, Vladimir Zapolskiy, Loic Poulain, Robert Foss,
Andi Shyti, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Todor Tomov, Mauro Carvalho Chehab, Bryan O'Donoghue
Cc: linux-i2c, linux-arm-msm, devicetree, linux-kernel, linux-media,
aiqun.yu, tingwei.zhang, trilok.soni, yijie.yang, Jingyi Wang,
Atiya Kailany
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
^ permalink raw reply [flat|nested] 46+ messages in thread
* [PATCH v2 2/6] dt-bindings: media: camss: Add qcom,kaanapali-camss binding
2025-10-15 2:56 [PATCH v2 0/6] media: qcom: camss: Add Kaanapali support Hangxiang Ma
2025-10-15 2:56 ` [PATCH v2 1/6] dt-bindings: i2c: qcom-cci: Document Kaanapali compatible Hangxiang Ma
@ 2025-10-15 2:56 ` Hangxiang Ma
2025-10-15 4:37 ` Rob Herring (Arm)
` (2 more replies)
2025-10-15 2:56 ` [PATCH v2 3/6] media: qcom: camss: Add Kaanapali compatible camss driver Hangxiang Ma
` (3 subsequent siblings)
5 siblings, 3 replies; 46+ messages in thread
From: Hangxiang Ma @ 2025-10-15 2:56 UTC (permalink / raw)
To: Loic Poulain, Robert Foss, Andi Shyti, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Todor Tomov,
Vladimir Zapolskiy, Mauro Carvalho Chehab, Bryan O'Donoghue
Cc: linux-i2c, linux-arm-msm, devicetree, linux-kernel, linux-media,
aiqun.yu, tingwei.zhang, trilok.soni, yijie.yang, Jingyi Wang,
Atiya Kailany, Hangxiang Ma
Add bindings for qcom,kaanapali-camss in order to support the camera
subsystem for Kaanapali.
Signed-off-by: Hangxiang Ma <hangxiang.ma@oss.qualcomm.com>
---
.../bindings/media/qcom,kaanapali-camss.yaml | 494 +++++++++++++++++++++
1 file changed, 494 insertions(+)
diff --git a/Documentation/devicetree/bindings/media/qcom,kaanapali-camss.yaml b/Documentation/devicetree/bindings/media/qcom,kaanapali-camss.yaml
new file mode 100644
index 000000000000..d04c21103cfd
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/qcom,kaanapali-camss.yaml
@@ -0,0 +1,494 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/media/qcom,kaanapali-camss.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm Kaanapali Camera Subsystem (CAMSS)
+
+maintainers:
+ - Hangxiang Ma <hangxiang.ma@oss.qualcomm.com>
+
+description:
+ The CAMSS IP is a CSI decoder and ISP present on Qualcomm platforms.
+
+properties:
+ compatible:
+ const: qcom,kaanapali-camss
+
+ reg:
+ maxItems: 16
+
+ reg-names:
+ items:
+ - const: csid0
+ - const: csid1
+ - const: csid2
+ - const: csid_lite0
+ - const: csid_lite1
+ - const: csiphy0
+ - const: csiphy1
+ - const: csiphy2
+ - const: csiphy3
+ - const: csiphy4
+ - const: csiphy5
+ - const: vfe0
+ - const: vfe1
+ - const: vfe2
+ - const: vfe_lite0
+ - const: vfe_lite1
+
+ clocks:
+ maxItems: 34
+
+ clock-names:
+ items:
+ - const: camnoc_nrt_axi
+ - const: camnoc_rt_axi
+ - const: camnoc_rt_vfe0
+ - const: camnoc_rt_vfe1
+ - const: camnoc_rt_vfe2
+ - const: camnoc_rt_vfe_lite
+ - const: cam_top_ahb
+ - const: cam_top_fast_ahb
+ - const: csid
+ - const: csid_csiphy_rx
+ - const: csiphy0
+ - const: csiphy0_timer
+ - const: csiphy1
+ - const: csiphy1_timer
+ - const: csiphy2
+ - const: csiphy2_timer
+ - const: csiphy3
+ - const: csiphy3_timer
+ - const: csiphy4
+ - const: csiphy4_timer
+ - const: csiphy5
+ - const: csiphy5_timer
+ - const: gcc_hf_axi
+ - const: qdss_debug_xo
+ - const: vfe0
+ - const: vfe0_fast_ahb
+ - const: vfe1
+ - const: vfe1_fast_ahb
+ - const: vfe2
+ - const: vfe2_fast_ahb
+ - const: vfe_lite
+ - const: vfe_lite_ahb
+ - const: vfe_lite_cphy_rx
+ - const: vfe_lite_csid
+
+ interrupts:
+ maxItems: 16
+ interrupt-names:
+ items:
+ - const: csid0
+ - const: csid1
+ - const: csid2
+ - const: csid_lite0
+ - const: csid_lite1
+ - const: csiphy0
+ - const: csiphy1
+ - const: csiphy2
+ - const: csiphy3
+ - const: csiphy4
+ - const: csiphy5
+ - const: vfe0
+ - const: vfe1
+ - const: vfe2
+ - const: vfe_lite0
+ - const: vfe_lite1
+
+ interconnects:
+ maxItems: 2
+
+ interconnect-names:
+ items:
+ - const: ahb
+ - const: hf_0_mnoc
+
+ iommus:
+ maxItems: 1
+
+ power-domains:
+ items:
+ - description:
+ TFE0 GDSC - Thin Front End, Global Distributed Switch Controller.
+ - description:
+ TFE1 GDSC - Thin Front End, Global Distributed Switch Controller.
+ - description:
+ TFE2 GDSC - Thin Front End, Global Distributed Switch Controller.
+ - description:
+ Titan GDSC - Titan ISP Block Global Distributed Switch Controller.
+
+ power-domain-names:
+ items:
+ - const: tfe0
+ - const: tfe1
+ - const: tfe2
+ - const: top
+
+ vdda-pll-supply:
+ description:
+ Phandle to 1.2V regulator supply to PHY refclk pll block.
+
+ vdda-phy0-supply:
+ description:
+ Phandle to 0.8V regulator supply to PHY core block.
+
+ vdda-phy1-supply:
+ description:
+ Phandle to 0.8V regulator supply to PHY core block.
+
+ vdda-phy2-supply:
+ description:
+ Phandle to 0.8V regulator supply to PHY core block.
+
+ vdda-phy3-supply:
+ description:
+ Phandle to 0.8V regulator supply to PHY core block.
+
+ vdda-phy4-supply:
+ description:
+ Phandle to 0.8V regulator supply to PHY core block.
+
+ vdda-phy5-supply:
+ description:
+ Phandle to 0.8V regulator supply to PHY core block.
+
+ ports:
+ $ref: /schemas/graph.yaml#/properties/ports
+
+ description:
+ CSI input ports.
+
+ properties:
+ port@0:
+ $ref: /schemas/graph.yaml#/$defs/port-base
+ unevaluatedProperties: false
+ description:
+ Input port for receiving CSI data on CSI0.
+
+ properties:
+ endpoint:
+ $ref: video-interfaces.yaml#
+ unevaluatedProperties: false
+
+ properties:
+ clock-lanes:
+ maxItems: 1
+
+ data-lanes:
+ minItems: 1
+ maxItems: 4
+
+ bus-type:
+ enum:
+ - 1 # MEDIA_BUS_TYPE_CSI2_CPHY
+ - 4 # MEDIA_BUS_TYPE_CSI2_DPHY
+
+ required:
+ - clock-lanes
+ - data-lanes
+
+ port@1:
+ $ref: /schemas/graph.yaml#/$defs/port-base
+ unevaluatedProperties: false
+ description:
+ Input port for receiving CSI data on CSI1.
+
+ properties:
+ endpoint:
+ $ref: video-interfaces.yaml#
+ unevaluatedProperties: false
+
+ properties:
+ clock-lanes:
+ maxItems: 1
+
+ data-lanes:
+ minItems: 1
+ maxItems: 4
+
+ bus-type:
+ enum:
+ - 1 # MEDIA_BUS_TYPE_CSI2_CPHY
+ - 4 # MEDIA_BUS_TYPE_CSI2_DPHY
+
+ required:
+ - clock-lanes
+ - data-lanes
+
+ port@2:
+ $ref: /schemas/graph.yaml#/$defs/port-base
+ unevaluatedProperties: false
+ description:
+ Input port for receiving CSI data on CSI2.
+
+ properties:
+ endpoint:
+ $ref: video-interfaces.yaml#
+ unevaluatedProperties: false
+
+ properties:
+ clock-lanes:
+ maxItems: 1
+
+ data-lanes:
+ minItems: 1
+ maxItems: 4
+
+ bus-type:
+ enum:
+ - 1 # MEDIA_BUS_TYPE_CSI2_CPHY
+ - 4 # MEDIA_BUS_TYPE_CSI2_DPHY
+
+ required:
+ - clock-lanes
+ - data-lanes
+
+ port@3:
+ $ref: /schemas/graph.yaml#/$defs/port-base
+ unevaluatedProperties: false
+ description:
+ Input port for receiving CSI data on CSI3.
+
+ properties:
+ endpoint:
+ $ref: video-interfaces.yaml#
+ unevaluatedProperties: false
+
+ properties:
+ clock-lanes:
+ maxItems: 1
+
+ data-lanes:
+ minItems: 1
+ maxItems: 4
+
+ bus-type:
+ enum:
+ - 1 # MEDIA_BUS_TYPE_CSI2_CPHY
+ - 4 # MEDIA_BUS_TYPE_CSI2_DPHY
+
+ required:
+ - clock-lanes
+ - data-lanes
+
+required:
+ - compatible
+ - reg
+ - reg-names
+ - clocks
+ - clock-names
+ - interrupts
+ - interrupt-names
+ - interconnects
+ - interconnect-names
+ - iommus
+ - power-domains
+ - power-domain-names
+ - vdda-pll-supply
+ - vdda-phy0-supply
+ - vdda-phy1-supply
+ - vdda-phy2-supply
+ - vdda-phy3-supply
+ - vdda-phy4-supply
+ - vdda-phy5-supply
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/qcom,rpmh.h>
+ #include <dt-bindings/clock/qcom,kaanapali-camcc.h>
+ #include <dt-bindings/clock/qcom,kaanapali-gcc.h>
+ #include <dt-bindings/interconnect/qcom,icc.h>
+ #include <dt-bindings/interconnect/qcom,kaanapali-rpmh.h>
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ #include <dt-bindings/power/qcom,rpmhpd.h>
+
+ soc {
+ #address-cells = <2>;
+ #size-cells = <2>;
+
+ camss: isp@9253000 {
+ compatible = "qcom,kaanapali-camss";
+
+ reg = <0x0 0x09253000 0x0 0x5e80>,
+ <0x0 0x09263000 0x0 0x5e80>,
+ <0x0 0x09273000 0x0 0x5e80>,
+ <0x0 0x092d3000 0x0 0x3880>,
+ <0x0 0x092e7000 0x0 0x3880>,
+ <0x0 0x09523000 0x0 0x2000>,
+ <0x0 0x09525000 0x0 0x2000>,
+ <0x0 0x09527000 0x0 0x2000>,
+ <0x0 0x09529000 0x0 0x2000>,
+ <0x0 0x0952b000 0x0 0x2000>,
+ <0x0 0x0952d000 0x0 0x2000>,
+ <0x0 0x09151000 0x0 0x20000>,
+ <0x0 0x09171000 0x0 0x20000>,
+ <0x0 0x09191000 0x0 0x20000>,
+ <0x0 0x092dc000 0x0 0x1300>,
+ <0x0 0x092f0000 0x0 0x1300>;
+ reg-names = "csid0",
+ "csid1",
+ "csid2",
+ "csid_lite0",
+ "csid_lite1",
+ "csiphy0",
+ "csiphy1",
+ "csiphy2",
+ "csiphy3",
+ "csiphy4",
+ "csiphy5",
+ "vfe0",
+ "vfe1",
+ "vfe2",
+ "vfe_lite0",
+ "vfe_lite1";
+
+ clocks = <&camcc CAM_CC_CAMNOC_NRT_AXI_CLK>,
+ <&camcc CAM_CC_CAMNOC_RT_AXI_CLK>,
+ <&camcc CAM_CC_CAMNOC_RT_TFE_0_MAIN_CLK>,
+ <&camcc CAM_CC_CAMNOC_RT_TFE_1_MAIN_CLK>,
+ <&camcc CAM_CC_CAMNOC_RT_TFE_2_MAIN_CLK>,
+ <&camcc CAM_CC_CAMNOC_RT_IFE_LITE_CLK>,
+ <&camcc CAM_CC_CAM_TOP_AHB_CLK>,
+ <&camcc CAM_CC_CAM_TOP_FAST_AHB_CLK>,
+ <&camcc CAM_CC_CSID_CLK>,
+ <&camcc CAM_CC_CSID_CSIPHY_RX_CLK>,
+ <&camcc CAM_CC_CSIPHY0_CLK>,
+ <&camcc CAM_CC_CSI0PHYTIMER_CLK>,
+ <&camcc CAM_CC_CSIPHY1_CLK>,
+ <&camcc CAM_CC_CSI1PHYTIMER_CLK>,
+ <&camcc CAM_CC_CSIPHY2_CLK>,
+ <&camcc CAM_CC_CSI2PHYTIMER_CLK>,
+ <&camcc CAM_CC_CSIPHY3_CLK>,
+ <&camcc CAM_CC_CSI3PHYTIMER_CLK>,
+ <&camcc CAM_CC_CSIPHY4_CLK>,
+ <&camcc CAM_CC_CSI4PHYTIMER_CLK>,
+ <&camcc CAM_CC_CSIPHY5_CLK>,
+ <&camcc CAM_CC_CSI5PHYTIMER_CLK>,
+ <&gcc GCC_CAMERA_HF_AXI_CLK>,
+ <&camcc CAM_CC_QDSS_DEBUG_XO_CLK>,
+ <&camcc CAM_CC_TFE_0_MAIN_CLK>,
+ <&camcc CAM_CC_TFE_0_MAIN_FAST_AHB_CLK>,
+ <&camcc CAM_CC_TFE_1_MAIN_CLK>,
+ <&camcc CAM_CC_TFE_1_MAIN_FAST_AHB_CLK>,
+ <&camcc CAM_CC_TFE_2_MAIN_CLK>,
+ <&camcc CAM_CC_TFE_2_MAIN_FAST_AHB_CLK>,
+ <&camcc CAM_CC_IFE_LITE_CLK>,
+ <&camcc CAM_CC_IFE_LITE_AHB_CLK>,
+ <&camcc CAM_CC_IFE_LITE_CPHY_RX_CLK>,
+ <&camcc CAM_CC_IFE_LITE_CSID_CLK>;
+ clock-names = "camnoc_nrt_axi",
+ "camnoc_rt_axi",
+ "camnoc_rt_vfe0",
+ "camnoc_rt_vfe1",
+ "camnoc_rt_vfe2",
+ "camnoc_rt_vfe_lite",
+ "cam_top_ahb",
+ "cam_top_fast_ahb",
+ "csid",
+ "csid_csiphy_rx",
+ "csiphy0",
+ "csiphy0_timer",
+ "csiphy1",
+ "csiphy1_timer",
+ "csiphy2",
+ "csiphy2_timer",
+ "csiphy3",
+ "csiphy3_timer",
+ "csiphy4",
+ "csiphy4_timer",
+ "csiphy5",
+ "csiphy5_timer",
+ "gcc_hf_axi",
+ "qdss_debug_xo",
+ "vfe0",
+ "vfe0_fast_ahb",
+ "vfe1",
+ "vfe1_fast_ahb",
+ "vfe2",
+ "vfe2_fast_ahb",
+ "vfe_lite",
+ "vfe_lite_ahb",
+ "vfe_lite_cphy_rx",
+ "vfe_lite_csid";
+
+ interrupts = <GIC_SPI 601 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 603 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 431 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 605 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 376 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 477 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 478 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 479 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 448 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 122 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 89 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 433 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 436 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 457 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 606 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 377 IRQ_TYPE_EDGE_RISING>;
+ interrupt-names = "csid0",
+ "csid1",
+ "csid2",
+ "csid_lite0",
+ "csid_lite1",
+ "csiphy0",
+ "csiphy1",
+ "csiphy2",
+ "csiphy3",
+ "csiphy4",
+ "csiphy5",
+ "vfe0",
+ "vfe1",
+ "vfe2",
+ "vfe_lite0",
+ "vfe_lite1";
+
+ interconnects = <&gem_noc MASTER_APPSS_PROC QCOM_ICC_TAG_ACTIVE_ONLY
+ &config_noc SLAVE_CAMERA_CFG QCOM_ICC_TAG_ACTIVE_ONLY>,
+ <&mmss_noc MASTER_CAMNOC_HF QCOM_ICC_TAG_ALWAYS
+ &mc_virt SLAVE_EBI1 QCOM_ICC_TAG_ALWAYS>;
+ interconnect-names = "ahb",
+ "hf_0_mnoc";
+
+ iommus = <&apps_smmu 0x1c00 0x00>;
+
+ power-domains = <&camcc CAM_CC_TFE_0_GDSC>,
+ <&camcc CAM_CC_TFE_1_GDSC>,
+ <&camcc CAM_CC_TFE_2_GDSC>,
+ <&camcc CAM_CC_TITAN_TOP_GDSC>;
+ power-domain-names = "tfe0",
+ "tfe1",
+ "tfe2",
+ "top";
+
+ vdda-pll-supply = <&vreg_l1d_1p2>;
+ vdda-phy0-supply = <&vreg_l3i_0p8>;
+ vdda-phy1-supply = <&vreg_l3i_0p8>;
+ vdda-phy2-supply = <&vreg_l3d_0p8>;
+ vdda-phy3-supply = <&vreg_l3i_0p8>;
+ vdda-phy4-supply = <&vreg_l3d_0p8>;
+ vdda-phy5-supply = <&vreg_l3i_0p8>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+
+ csiphy_ep0: endpoint {
+ clock-lanes = <7>;
+ data-lanes = <0 1>;
+ remote-endpoint = <&sensor_ep>;
+ };
+ };
+ };
+ };
+ };
--
2.34.1
^ permalink raw reply related [flat|nested] 46+ messages in thread* Re: [PATCH v2 2/6] dt-bindings: media: camss: Add qcom,kaanapali-camss binding
2025-10-15 2:56 ` [PATCH v2 2/6] dt-bindings: media: camss: Add qcom,kaanapali-camss binding Hangxiang Ma
@ 2025-10-15 4:37 ` Rob Herring (Arm)
2025-10-16 5:51 ` Krzysztof Kozlowski
2025-10-15 19:45 ` Vladimir Zapolskiy
2025-10-16 5:52 ` Krzysztof Kozlowski
2 siblings, 1 reply; 46+ messages in thread
From: Rob Herring (Arm) @ 2025-10-15 4:37 UTC (permalink / raw)
To: Hangxiang Ma
Cc: Loic Poulain, trilok.soni, Mauro Carvalho Chehab, linux-arm-msm,
Todor Tomov, Vladimir Zapolskiy, Krzysztof Kozlowski,
Conor Dooley, Robert Foss, linux-media, Atiya Kailany, Andi Shyti,
tingwei.zhang, Bryan O'Donoghue, aiqun.yu, linux-kernel,
Jingyi Wang, linux-i2c, yijie.yang, devicetree
On Tue, 14 Oct 2025 19:56:02 -0700, Hangxiang Ma wrote:
> Add bindings for qcom,kaanapali-camss in order to support the camera
> subsystem for Kaanapali.
>
> Signed-off-by: Hangxiang Ma <hangxiang.ma@oss.qualcomm.com>
> ---
> .../bindings/media/qcom,kaanapali-camss.yaml | 494 +++++++++++++++++++++
> 1 file changed, 494 insertions(+)
>
My bot found errors running 'make dt_binding_check' on your patch:
yamllint warnings/errors:
dtschema/dtc warnings/errors:
Documentation/devicetree/bindings/media/qcom,kaanapali-camss.example.dts:25:18: fatal error: dt-bindings/clock/qcom,kaanapali-camcc.h: No such file or directory
25 | #include <dt-bindings/clock/qcom,kaanapali-camcc.h>
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
compilation terminated.
make[2]: *** [scripts/Makefile.dtbs:132: Documentation/devicetree/bindings/media/qcom,kaanapali-camss.example.dtb] Error 1
make[2]: *** Waiting for unfinished jobs....
make[1]: *** [/builds/robherring/dt-review-ci/linux/Makefile:1525: dt_binding_check] Error 2
make: *** [Makefile:248: __sub-make] Error 2
doc reference errors (make refcheckdocs):
See https://patchwork.ozlabs.org/project/devicetree-bindings/patch/20251014-add-support-for-camss-on-kaanapali-v2-2-f5745ba2dff9@oss.qualcomm.com
The base for the series is generally the latest rc1. A different dependency
should be noted in *this* patch.
If you already ran 'make dt_binding_check' and didn't see the above
error(s), then make sure 'yamllint' is installed and dt-schema is up to
date:
pip3 install dtschema --upgrade
Please check and re-submit after running the above command yourself. Note
that DT_SCHEMA_FILES can be set to your schema file to speed up checking
your schema. However, it must be unset to test all examples with your schema.
^ permalink raw reply [flat|nested] 46+ messages in thread* Re: [PATCH v2 2/6] dt-bindings: media: camss: Add qcom,kaanapali-camss binding
2025-10-15 4:37 ` Rob Herring (Arm)
@ 2025-10-16 5:51 ` Krzysztof Kozlowski
0 siblings, 0 replies; 46+ messages in thread
From: Krzysztof Kozlowski @ 2025-10-16 5:51 UTC (permalink / raw)
To: Rob Herring (Arm), Hangxiang Ma
Cc: Loic Poulain, trilok.soni, Mauro Carvalho Chehab, linux-arm-msm,
Todor Tomov, Vladimir Zapolskiy, Krzysztof Kozlowski,
Conor Dooley, Robert Foss, linux-media, Atiya Kailany, Andi Shyti,
tingwei.zhang, Bryan O'Donoghue, aiqun.yu, linux-kernel,
Jingyi Wang, linux-i2c, yijie.yang, devicetree
On 15/10/2025 06:37, Rob Herring (Arm) wrote:
>
> On Tue, 14 Oct 2025 19:56:02 -0700, Hangxiang Ma wrote:
>> Add bindings for qcom,kaanapali-camss in order to support the camera
>> subsystem for Kaanapali.
>>
>> Signed-off-by: Hangxiang Ma <hangxiang.ma@oss.qualcomm.com>
>> ---
>> .../bindings/media/qcom,kaanapali-camss.yaml | 494 +++++++++++++++++++++
>> 1 file changed, 494 insertions(+)
>>
>
> My bot found errors running 'make dt_binding_check' on your patch:
>
> yamllint warnings/errors:
>
> dtschema/dtc warnings/errors:
> Documentation/devicetree/bindings/media/qcom,kaanapali-camss.example.dts:25:18: fatal error: dt-bindings/clock/qcom,kaanapali-camcc.h: No such file or directory
> 25 | #include <dt-bindings/clock/qcom,kaanapali-camcc.h>
> | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
This patch has completely unnecessary dependencies which makes it
untestable and unmergeable.
I won't be reviewing it.
Best regards,
Krzysztof
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: [PATCH v2 2/6] dt-bindings: media: camss: Add qcom,kaanapali-camss binding
2025-10-15 2:56 ` [PATCH v2 2/6] dt-bindings: media: camss: Add qcom,kaanapali-camss binding Hangxiang Ma
2025-10-15 4:37 ` Rob Herring (Arm)
@ 2025-10-15 19:45 ` Vladimir Zapolskiy
2025-10-15 21:43 ` Bryan O'Donoghue
` (2 more replies)
2025-10-16 5:52 ` Krzysztof Kozlowski
2 siblings, 3 replies; 46+ messages in thread
From: Vladimir Zapolskiy @ 2025-10-15 19:45 UTC (permalink / raw)
To: Hangxiang Ma, Loic Poulain, Robert Foss, Andi Shyti, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Todor Tomov,
Mauro Carvalho Chehab, Bryan O'Donoghue
Cc: linux-i2c, linux-arm-msm, devicetree, linux-kernel, linux-media,
aiqun.yu, tingwei.zhang, trilok.soni, yijie.yang, Jingyi Wang,
Atiya Kailany
On 10/15/25 05:56, Hangxiang Ma wrote:
> Add bindings for qcom,kaanapali-camss in order to support the camera
> subsystem for Kaanapali.
>
> Signed-off-by: Hangxiang Ma <hangxiang.ma@oss.qualcomm.com>
> ---
> .../bindings/media/qcom,kaanapali-camss.yaml | 494 +++++++++++++++++++++
> 1 file changed, 494 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/media/qcom,kaanapali-camss.yaml b/Documentation/devicetree/bindings/media/qcom,kaanapali-camss.yaml
> new file mode 100644
> index 000000000000..d04c21103cfd
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/media/qcom,kaanapali-camss.yaml
> @@ -0,0 +1,494 @@
> +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/media/qcom,kaanapali-camss.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Qualcomm Kaanapali Camera Subsystem (CAMSS)
> +
> +maintainers:
> + - Hangxiang Ma <hangxiang.ma@oss.qualcomm.com>
> +
> +description:
> + The CAMSS IP is a CSI decoder and ISP present on Qualcomm platforms.
> +
> +properties:
> + compatible:
> + const: qcom,kaanapali-camss
> +
> + reg:
> + maxItems: 16
> +
> + reg-names:
> + items:
> + - const: csid0
> + - const: csid1
> + - const: csid2
> + - const: csid_lite0
> + - const: csid_lite1
> + - const: csiphy0
> + - const: csiphy1
> + - const: csiphy2
> + - const: csiphy3
> + - const: csiphy4
> + - const: csiphy5
> + - const: vfe0
> + - const: vfe1
> + - const: vfe2
> + - const: vfe_lite0
> + - const: vfe_lite1
> +
> + clocks:
> + maxItems: 34
> +
> + clock-names:
> + items:
> + - const: camnoc_nrt_axi
> + - const: camnoc_rt_axi
> + - const: camnoc_rt_vfe0
> + - const: camnoc_rt_vfe1
> + - const: camnoc_rt_vfe2
> + - const: camnoc_rt_vfe_lite
> + - const: cam_top_ahb
> + - const: cam_top_fast_ahb
> + - const: csid
> + - const: csid_csiphy_rx
> + - const: csiphy0
> + - const: csiphy0_timer
> + - const: csiphy1
> + - const: csiphy1_timer
> + - const: csiphy2
> + - const: csiphy2_timer
> + - const: csiphy3
> + - const: csiphy3_timer
> + - const: csiphy4
> + - const: csiphy4_timer
> + - const: csiphy5
> + - const: csiphy5_timer
> + - const: gcc_hf_axi
> + - const: qdss_debug_xo
> + - const: vfe0
> + - const: vfe0_fast_ahb
> + - const: vfe1
> + - const: vfe1_fast_ahb
> + - const: vfe2
> + - const: vfe2_fast_ahb
> + - const: vfe_lite
> + - const: vfe_lite_ahb
> + - const: vfe_lite_cphy_rx
> + - const: vfe_lite_csid
The list of 'clock-names' values is not alphanumerically sorted.
> +
> + interrupts:
> + maxItems: 16
> + interrupt-names:
Missing empty line to separate properties.
> + items:
> + - const: csid0
> + - const: csid1
> + - const: csid2
> + - const: csid_lite0
> + - const: csid_lite1
> + - const: csiphy0
> + - const: csiphy1
> + - const: csiphy2
> + - const: csiphy3
> + - const: csiphy4
> + - const: csiphy5
> + - const: vfe0
> + - const: vfe1
> + - const: vfe2
> + - const: vfe_lite0
> + - const: vfe_lite1
> +
> + interconnects:
> + maxItems: 2
> +
> + interconnect-names:
> + items:
> + - const: ahb
> + - const: hf_0_mnoc
Please rename "hf_0_mnoc" to "hf_mnoc", see qcom,qcm2290-camss.yaml etc.
> +
> + iommus:
> + maxItems: 1
> +
> + power-domains:
> + items:
> + - description:
> + TFE0 GDSC - Thin Front End, Global Distributed Switch Controller.
> + - description:
> + TFE1 GDSC - Thin Front End, Global Distributed Switch Controller.
> + - description:
> + TFE2 GDSC - Thin Front End, Global Distributed Switch Controller.
> + - description:
> + Titan GDSC - Titan ISP Block Global Distributed Switch Controller.
> +
> + power-domain-names:
> + items:
> + - const: tfe0
> + - const: tfe1
> + - const: tfe2
Please remove all 'tfeX' power domains, they are not going to be utilized
any time soon.
When 'power-domains' list is just a single Titan GDSC, 'power-domain-names'
property is not needed.
> + - const: top
> +
> + vdda-pll-supply:
> + description:
> + Phandle to 1.2V regulator supply to PHY refclk pll block.
> +
> + vdda-phy0-supply:
> + description:
> + Phandle to 0.8V regulator supply to PHY core block.
> +
> + vdda-phy1-supply:
> + description:
> + Phandle to 0.8V regulator supply to PHY core block.
> +
> + vdda-phy2-supply:
> + description:
> + Phandle to 0.8V regulator supply to PHY core block.
> +
> + vdda-phy3-supply:
> + description:
> + Phandle to 0.8V regulator supply to PHY core block.
> +
> + vdda-phy4-supply:
> + description:
> + Phandle to 0.8V regulator supply to PHY core block.
> +
> + vdda-phy5-supply:
> + description:
> + Phandle to 0.8V regulator supply to PHY core block.
What is the difference between vdda-phyX-supply properties, why do you
need so many of them, when their descriptions say they are all the same?
> + ports:
> + $ref: /schemas/graph.yaml#/properties/ports
> +
> + description:
> + CSI input ports.
> +
> + properties:
> + port@0:
Please use
patternProperties:
"^port@[0-3]$":
> + $ref: /schemas/graph.yaml#/$defs/port-base
> + unevaluatedProperties: false
> + description:
> + Input port for receiving CSI data on CSI0.
> +
> + properties:
> + endpoint:
> + $ref: video-interfaces.yaml#
> + unevaluatedProperties: false
> +
> + properties:
> + clock-lanes:
> + maxItems: 1
Please remove 'clock-lanes' property, it is non-configurable, redundant
and tends to store some irrelevant value.
> +
> + data-lanes:
> + minItems: 1
> + maxItems: 4
> +
> + bus-type:
> + enum:
> + - 1 # MEDIA_BUS_TYPE_CSI2_CPHY
> + - 4 # MEDIA_BUS_TYPE_CSI2_DPHY
> +
> + required:
> + - clock-lanes
The 'clock-lanes' property is expected to be removed.
> + - data-lanes
> +
> + port@1:
> + $ref: /schemas/graph.yaml#/$defs/port-base
> + unevaluatedProperties: false
> + description:
> + Input port for receiving CSI data on CSI1.
> +
> + properties:
> + endpoint:
> + $ref: video-interfaces.yaml#
> + unevaluatedProperties: false
> +
> + properties:
> + clock-lanes:
> + maxItems: 1
> +
> + data-lanes:
> + minItems: 1
> + maxItems: 4
> +
> + bus-type:
> + enum:
> + - 1 # MEDIA_BUS_TYPE_CSI2_CPHY
> + - 4 # MEDIA_BUS_TYPE_CSI2_DPHY
> +
> + required:
> + - clock-lanes
> + - data-lanes
> +
> + port@2:
> + $ref: /schemas/graph.yaml#/$defs/port-base
> + unevaluatedProperties: false
> + description:
> + Input port for receiving CSI data on CSI2.
> +
> + properties:
> + endpoint:
> + $ref: video-interfaces.yaml#
> + unevaluatedProperties: false
> +
> + properties:
> + clock-lanes:
> + maxItems: 1
> +
> + data-lanes:
> + minItems: 1
> + maxItems: 4
> +
> + bus-type:
> + enum:
> + - 1 # MEDIA_BUS_TYPE_CSI2_CPHY
> + - 4 # MEDIA_BUS_TYPE_CSI2_DPHY
> +
> + required:
> + - clock-lanes
> + - data-lanes
> +
> + port@3:
> + $ref: /schemas/graph.yaml#/$defs/port-base
> + unevaluatedProperties: false
> + description:
> + Input port for receiving CSI data on CSI3.
> +
> + properties:
> + endpoint:
> + $ref: video-interfaces.yaml#
> + unevaluatedProperties: false
> +
> + properties:
> + clock-lanes:
> + maxItems: 1
> +
> + data-lanes:
> + minItems: 1
> + maxItems: 4
> +
> + bus-type:
> + enum:
> + - 1 # MEDIA_BUS_TYPE_CSI2_CPHY
> + - 4 # MEDIA_BUS_TYPE_CSI2_DPHY
> +
> + required:
> + - clock-lanes
> + - data-lanes
> +
> +required:
> + - compatible
> + - reg
> + - reg-names
> + - clocks
> + - clock-names
> + - interrupts
> + - interrupt-names
> + - interconnects
> + - interconnect-names
> + - iommus
> + - power-domains
> + - power-domain-names
> + - vdda-pll-supply
> + - vdda-phy0-supply
> + - vdda-phy1-supply
> + - vdda-phy2-supply
> + - vdda-phy3-supply
> + - vdda-phy4-supply
> + - vdda-phy5-supply
Please exclude supplies from the list of required properties.
> +
> +additionalProperties: false
> +
> +examples:
> + - |
> + #include <dt-bindings/clock/qcom,rpmh.h>
> + #include <dt-bindings/clock/qcom,kaanapali-camcc.h>
> + #include <dt-bindings/clock/qcom,kaanapali-gcc.h>
> + #include <dt-bindings/interconnect/qcom,icc.h>
> + #include <dt-bindings/interconnect/qcom,kaanapali-rpmh.h>
> + #include <dt-bindings/interrupt-controller/arm-gic.h>
> + #include <dt-bindings/power/qcom,rpmhpd.h>
Please keep the list of included headers sorted alphabetically.
> +
> + soc {
> + #address-cells = <2>;
> + #size-cells = <2>;
> +
> + camss: isp@9253000 {
> + compatible = "qcom,kaanapali-camss";
> +
> + reg = <0x0 0x09253000 0x0 0x5e80>,
> + <0x0 0x09263000 0x0 0x5e80>,
> + <0x0 0x09273000 0x0 0x5e80>,
> + <0x0 0x092d3000 0x0 0x3880>,
> + <0x0 0x092e7000 0x0 0x3880>,
> + <0x0 0x09523000 0x0 0x2000>,
> + <0x0 0x09525000 0x0 0x2000>,
> + <0x0 0x09527000 0x0 0x2000>,
> + <0x0 0x09529000 0x0 0x2000>,
> + <0x0 0x0952b000 0x0 0x2000>,
> + <0x0 0x0952d000 0x0 0x2000>,
> + <0x0 0x09151000 0x0 0x20000>,
> + <0x0 0x09171000 0x0 0x20000>,
> + <0x0 0x09191000 0x0 0x20000>,
> + <0x0 0x092dc000 0x0 0x1300>,
> + <0x0 0x092f0000 0x0 0x1300>;
> + reg-names = "csid0",
> + "csid1",
> + "csid2",
> + "csid_lite0",
> + "csid_lite1",
> + "csiphy0",
> + "csiphy1",
> + "csiphy2",
> + "csiphy3",
> + "csiphy4",
> + "csiphy5",
> + "vfe0",
> + "vfe1",
> + "vfe2",
> + "vfe_lite0",
> + "vfe_lite1";
> +
> + clocks = <&camcc CAM_CC_CAMNOC_NRT_AXI_CLK>,
> + <&camcc CAM_CC_CAMNOC_RT_AXI_CLK>,
> + <&camcc CAM_CC_CAMNOC_RT_TFE_0_MAIN_CLK>,
> + <&camcc CAM_CC_CAMNOC_RT_TFE_1_MAIN_CLK>,
> + <&camcc CAM_CC_CAMNOC_RT_TFE_2_MAIN_CLK>,
> + <&camcc CAM_CC_CAMNOC_RT_IFE_LITE_CLK>,
> + <&camcc CAM_CC_CAM_TOP_AHB_CLK>,
> + <&camcc CAM_CC_CAM_TOP_FAST_AHB_CLK>,
> + <&camcc CAM_CC_CSID_CLK>,
> + <&camcc CAM_CC_CSID_CSIPHY_RX_CLK>,
> + <&camcc CAM_CC_CSIPHY0_CLK>,
> + <&camcc CAM_CC_CSI0PHYTIMER_CLK>,
> + <&camcc CAM_CC_CSIPHY1_CLK>,
> + <&camcc CAM_CC_CSI1PHYTIMER_CLK>,
> + <&camcc CAM_CC_CSIPHY2_CLK>,
> + <&camcc CAM_CC_CSI2PHYTIMER_CLK>,
> + <&camcc CAM_CC_CSIPHY3_CLK>,
> + <&camcc CAM_CC_CSI3PHYTIMER_CLK>,
> + <&camcc CAM_CC_CSIPHY4_CLK>,
> + <&camcc CAM_CC_CSI4PHYTIMER_CLK>,
> + <&camcc CAM_CC_CSIPHY5_CLK>,
> + <&camcc CAM_CC_CSI5PHYTIMER_CLK>,
> + <&gcc GCC_CAMERA_HF_AXI_CLK>,
> + <&camcc CAM_CC_QDSS_DEBUG_XO_CLK>,
> + <&camcc CAM_CC_TFE_0_MAIN_CLK>,
> + <&camcc CAM_CC_TFE_0_MAIN_FAST_AHB_CLK>,
> + <&camcc CAM_CC_TFE_1_MAIN_CLK>,
> + <&camcc CAM_CC_TFE_1_MAIN_FAST_AHB_CLK>,
> + <&camcc CAM_CC_TFE_2_MAIN_CLK>,
> + <&camcc CAM_CC_TFE_2_MAIN_FAST_AHB_CLK>,
> + <&camcc CAM_CC_IFE_LITE_CLK>,
> + <&camcc CAM_CC_IFE_LITE_AHB_CLK>,
> + <&camcc CAM_CC_IFE_LITE_CPHY_RX_CLK>,
> + <&camcc CAM_CC_IFE_LITE_CSID_CLK>;
> + clock-names = "camnoc_nrt_axi",
> + "camnoc_rt_axi",
> + "camnoc_rt_vfe0",
> + "camnoc_rt_vfe1",
> + "camnoc_rt_vfe2",
> + "camnoc_rt_vfe_lite",
> + "cam_top_ahb",
> + "cam_top_fast_ahb",
> + "csid",
> + "csid_csiphy_rx",
> + "csiphy0",
> + "csiphy0_timer",
> + "csiphy1",
> + "csiphy1_timer",
> + "csiphy2",
> + "csiphy2_timer",
> + "csiphy3",
> + "csiphy3_timer",
> + "csiphy4",
> + "csiphy4_timer",
> + "csiphy5",
> + "csiphy5_timer",
> + "gcc_hf_axi",
> + "qdss_debug_xo",
> + "vfe0",
> + "vfe0_fast_ahb",
> + "vfe1",
> + "vfe1_fast_ahb",
> + "vfe2",
> + "vfe2_fast_ahb",
> + "vfe_lite",
> + "vfe_lite_ahb",
> + "vfe_lite_cphy_rx",
> + "vfe_lite_csid";
> +
> + interrupts = <GIC_SPI 601 IRQ_TYPE_EDGE_RISING>,
> + <GIC_SPI 603 IRQ_TYPE_EDGE_RISING>,
> + <GIC_SPI 431 IRQ_TYPE_EDGE_RISING>,
> + <GIC_SPI 605 IRQ_TYPE_EDGE_RISING>,
> + <GIC_SPI 376 IRQ_TYPE_EDGE_RISING>,
> + <GIC_SPI 477 IRQ_TYPE_EDGE_RISING>,
> + <GIC_SPI 478 IRQ_TYPE_EDGE_RISING>,
> + <GIC_SPI 479 IRQ_TYPE_EDGE_RISING>,
> + <GIC_SPI 448 IRQ_TYPE_EDGE_RISING>,
> + <GIC_SPI 122 IRQ_TYPE_EDGE_RISING>,
> + <GIC_SPI 89 IRQ_TYPE_EDGE_RISING>,
> + <GIC_SPI 433 IRQ_TYPE_EDGE_RISING>,
> + <GIC_SPI 436 IRQ_TYPE_EDGE_RISING>,
> + <GIC_SPI 457 IRQ_TYPE_EDGE_RISING>,
> + <GIC_SPI 606 IRQ_TYPE_EDGE_RISING>,
> + <GIC_SPI 377 IRQ_TYPE_EDGE_RISING>;
> + interrupt-names = "csid0",
> + "csid1",
> + "csid2",
> + "csid_lite0",
> + "csid_lite1",
> + "csiphy0",
> + "csiphy1",
> + "csiphy2",
> + "csiphy3",
> + "csiphy4",
> + "csiphy5",
> + "vfe0",
> + "vfe1",
> + "vfe2",
> + "vfe_lite0",
> + "vfe_lite1";
> +
> + interconnects = <&gem_noc MASTER_APPSS_PROC QCOM_ICC_TAG_ACTIVE_ONLY
> + &config_noc SLAVE_CAMERA_CFG QCOM_ICC_TAG_ACTIVE_ONLY>,
> + <&mmss_noc MASTER_CAMNOC_HF QCOM_ICC_TAG_ALWAYS
> + &mc_virt SLAVE_EBI1 QCOM_ICC_TAG_ALWAYS>;
> + interconnect-names = "ahb",
> + "hf_0_mnoc";
> +
> + iommus = <&apps_smmu 0x1c00 0x00>;
> +
> + power-domains = <&camcc CAM_CC_TFE_0_GDSC>,
> + <&camcc CAM_CC_TFE_1_GDSC>,
> + <&camcc CAM_CC_TFE_2_GDSC>,
> + <&camcc CAM_CC_TITAN_TOP_GDSC>;
> + power-domain-names = "tfe0",
> + "tfe1",
> + "tfe2",
> + "top";
> +
> + vdda-pll-supply = <&vreg_l1d_1p2>;
> + vdda-phy0-supply = <&vreg_l3i_0p8>;
> + vdda-phy1-supply = <&vreg_l3i_0p8>;
> + vdda-phy2-supply = <&vreg_l3d_0p8>;
> + vdda-phy3-supply = <&vreg_l3i_0p8>;
> + vdda-phy4-supply = <&vreg_l3d_0p8>;
> + vdda-phy5-supply = <&vreg_l3i_0p8>;
> +
> + ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + port@0 {
> + reg = <0>;
> +
> + csiphy_ep0: endpoint {
> + clock-lanes = <7>;
> + data-lanes = <0 1>;
> + remote-endpoint = <&sensor_ep>;
> + };
> + };
> + };
> + };
> + };
>
--
Best wishes,
Vladimir
^ permalink raw reply [flat|nested] 46+ messages in thread* Re: [PATCH v2 2/6] dt-bindings: media: camss: Add qcom,kaanapali-camss binding
2025-10-15 19:45 ` Vladimir Zapolskiy
@ 2025-10-15 21:43 ` Bryan O'Donoghue
2025-10-15 23:32 ` Vladimir Zapolskiy
2025-10-16 5:50 ` Krzysztof Kozlowski
2025-10-16 23:53 ` Vijay Kumar Tumati
2 siblings, 1 reply; 46+ messages in thread
From: Bryan O'Donoghue @ 2025-10-15 21:43 UTC (permalink / raw)
To: Vladimir Zapolskiy, Hangxiang Ma, Loic Poulain, Robert Foss,
Andi Shyti, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Todor Tomov, Mauro Carvalho Chehab
Cc: linux-i2c, linux-arm-msm, devicetree, linux-kernel, linux-media,
aiqun.yu, tingwei.zhang, trilok.soni, yijie.yang, Jingyi Wang,
Atiya Kailany
On 15/10/2025 20:45, Vladimir Zapolskiy wrote:
>> + power-domains:
>> + items:
>> + - description:
>> + TFE0 GDSC - Thin Front End, Global Distributed Switch
>> Controller.
>> + - description:
>> + TFE1 GDSC - Thin Front End, Global Distributed Switch
>> Controller.
>> + - description:
>> + TFE2 GDSC - Thin Front End, Global Distributed Switch
>> Controller.
>> + - description:
>> + Titan GDSC - Titan ISP Block Global Distributed Switch
>> Controller.
>> +
>> + power-domain-names:
>> + items:
>> + - const: tfe0
>> + - const: tfe1
>> + - const: tfe2
>
> Please remove all 'tfeX' power domains, they are not going to be utilized
> any time soon.
>
> When 'power-domains' list is just a single Titan GDSC, 'power-domain-names'
> property is not needed.
Each one of these TFEs powers an individually power-collapsible TFEs.
This is also so with the other xFE power-domains on previous SoC
generations.
You'll need the TFEx power-domain to process any data on TFEx with the
'lite' versions being tied to the TOP GDSC.
So please keep the power-domain list, TOP isn't enough.
---
bod
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: [PATCH v2 2/6] dt-bindings: media: camss: Add qcom,kaanapali-camss binding
2025-10-15 21:43 ` Bryan O'Donoghue
@ 2025-10-15 23:32 ` Vladimir Zapolskiy
2025-10-16 3:46 ` Vijay Kumar Tumati
0 siblings, 1 reply; 46+ messages in thread
From: Vladimir Zapolskiy @ 2025-10-15 23:32 UTC (permalink / raw)
To: Bryan O'Donoghue, Hangxiang Ma, Loic Poulain, Robert Foss,
Andi Shyti, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Todor Tomov, Mauro Carvalho Chehab
Cc: linux-i2c, linux-arm-msm, devicetree, linux-kernel, linux-media,
aiqun.yu, tingwei.zhang, trilok.soni, yijie.yang, Jingyi Wang,
Atiya Kailany
On 10/16/25 00:43, Bryan O'Donoghue wrote:
> On 15/10/2025 20:45, Vladimir Zapolskiy wrote:
>>> + power-domains:
>>> + items:
>>> + - description:
>>> + TFE0 GDSC - Thin Front End, Global Distributed Switch
>>> Controller.
>>> + - description:
>>> + TFE1 GDSC - Thin Front End, Global Distributed Switch
>>> Controller.
>>> + - description:
>>> + TFE2 GDSC - Thin Front End, Global Distributed Switch
>>> Controller.
>>> + - description:
>>> + Titan GDSC - Titan ISP Block Global Distributed Switch
>>> Controller.
>>> +
>>> + power-domain-names:
>>> + items:
>>> + - const: tfe0
>>> + - const: tfe1
>>> + - const: tfe2
>>
>> Please remove all 'tfeX' power domains, they are not going to be utilized
>> any time soon.
>>
>> When 'power-domains' list is just a single Titan GDSC, 'power-domain-names'
>> property is not needed.
>
> Each one of these TFEs powers an individually power-collapsible TFEs.
>
> This is also so with the other xFE power-domains on previous SoC
> generations.
This is false, for instance there is no management of SFEx power domains
in SM8550 or X1E80100 CAMSS in the upstrem, neither there is no management
of SBI, IPE, BPS, CPP and so on GDSC power domans given by CAMCCs.
TFEx is no more special, if it's unused, then it should not be added.
>
> You'll need the TFEx power-domain to process any data on TFEx with the
> 'lite' versions being tied to the TOP GDSC.
When it is needed, the documentation will be updated accordingly, right now
it is unknown what a data processing on TFEx looks like, it might happen
that there will be separate device tree nodes for TFEx.
TFEx power domains shall be removed right now, unti; a usecase in the upstream
CAMSS appears to use them, I haven't seen such code at the moment.
--
Best wishes,
Vladimir
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: [PATCH v2 2/6] dt-bindings: media: camss: Add qcom,kaanapali-camss binding
2025-10-15 23:32 ` Vladimir Zapolskiy
@ 2025-10-16 3:46 ` Vijay Kumar Tumati
2025-10-16 8:03 ` Vladimir Zapolskiy
0 siblings, 1 reply; 46+ messages in thread
From: Vijay Kumar Tumati @ 2025-10-16 3:46 UTC (permalink / raw)
To: Vladimir Zapolskiy, Bryan O'Donoghue, Hangxiang Ma,
Loic Poulain, Robert Foss, Andi Shyti, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Todor Tomov,
Mauro Carvalho Chehab
Cc: linux-i2c, linux-arm-msm, devicetree, linux-kernel, linux-media,
aiqun.yu, tingwei.zhang, trilok.soni, yijie.yang, Jingyi Wang,
Atiya Kailany
On 10/15/2025 4:32 PM, Vladimir Zapolskiy wrote:
> On 10/16/25 00:43, Bryan O'Donoghue wrote:
>> On 15/10/2025 20:45, Vladimir Zapolskiy wrote:
>>>> + power-domains:
>>>> + items:
>>>> + - description:
>>>> + TFE0 GDSC - Thin Front End, Global Distributed Switch
>>>> Controller.
>>>> + - description:
>>>> + TFE1 GDSC - Thin Front End, Global Distributed Switch
>>>> Controller.
>>>> + - description:
>>>> + TFE2 GDSC - Thin Front End, Global Distributed Switch
>>>> Controller.
>>>> + - description:
>>>> + Titan GDSC - Titan ISP Block Global Distributed Switch
>>>> Controller.
>>>> +
>>>> + power-domain-names:
>>>> + items:
>>>> + - const: tfe0
>>>> + - const: tfe1
>>>> + - const: tfe2
>>>
>>> Please remove all 'tfeX' power domains, they are not going to be
>>> utilized
>>> any time soon.
>>>
>>> When 'power-domains' list is just a single Titan GDSC,
>>> 'power-domain-names'
>>> property is not needed.
>>
>> Each one of these TFEs powers an individually power-collapsible TFEs.
>>
>> This is also so with the other xFE power-domains on previous SoC
>> generations.
>
> This is false, for instance there is no management of SFEx power domains
> in SM8550 or X1E80100 CAMSS in the upstrem, neither there is no
> management
> of SBI, IPE, BPS, CPP and so on GDSC power domans given by CAMCCs.
>
> TFEx is no more special, if it's unused, then it should not be added.
I agree with Bryan, if I understood the original comment correctly. This
is no different to the IFE0/1/2 GDSCs on SM8550. All the other modules
listed above (SFE, IPE, BPS etc.) are not supported by the CAMSS driver
and hence there is no management. However, we need to manage the TOP and
TFE0/1/2 GDSCs for the real time RDI paths.
>
>
>>
>> You'll need the TFEx power-domain to process any data on TFEx with the
>> 'lite' versions being tied to the TOP GDSC.
>
> When it is needed, the documentation will be updated accordingly,
> right now
> it is unknown what a data processing on TFEx looks like, it might happen
> that there will be separate device tree nodes for TFEx.
>
> TFEx power domains shall be removed right now, unti; a usecase in the
> upstream
> CAMSS appears to use them, I haven't seen such code at the moment.
>
We attach these power power domains by name in the corresponding driver.
For instance, the VFE driver attaches the TFE power domains mentioned
here and are exercised from vfe_set_power() -> vfe_get()
->vfe_pm_domain_on(). You can also see the related codes with '.has_pd'
and '.pd_name' properties in the CAMSS subdev resource structures. Hope
this clarifies.
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: [PATCH v2 2/6] dt-bindings: media: camss: Add qcom,kaanapali-camss binding
2025-10-16 3:46 ` Vijay Kumar Tumati
@ 2025-10-16 8:03 ` Vladimir Zapolskiy
0 siblings, 0 replies; 46+ messages in thread
From: Vladimir Zapolskiy @ 2025-10-16 8:03 UTC (permalink / raw)
To: Vijay Kumar Tumati, Bryan O'Donoghue, Hangxiang Ma,
Loic Poulain, Robert Foss, Andi Shyti, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Todor Tomov,
Mauro Carvalho Chehab
Cc: linux-i2c, linux-arm-msm, devicetree, linux-kernel, linux-media,
aiqun.yu, tingwei.zhang, trilok.soni, yijie.yang, Jingyi Wang,
Atiya Kailany
On 10/16/25 06:46, Vijay Kumar Tumati wrote:
>
> On 10/15/2025 4:32 PM, Vladimir Zapolskiy wrote:
>> On 10/16/25 00:43, Bryan O'Donoghue wrote:
>>> On 15/10/2025 20:45, Vladimir Zapolskiy wrote:
>>>>> + power-domains:
>>>>> + items:
>>>>> + - description:
>>>>> + TFE0 GDSC - Thin Front End, Global Distributed Switch
>>>>> Controller.
>>>>> + - description:
>>>>> + TFE1 GDSC - Thin Front End, Global Distributed Switch
>>>>> Controller.
>>>>> + - description:
>>>>> + TFE2 GDSC - Thin Front End, Global Distributed Switch
>>>>> Controller.
>>>>> + - description:
>>>>> + Titan GDSC - Titan ISP Block Global Distributed Switch
>>>>> Controller.
>>>>> +
>>>>> + power-domain-names:
>>>>> + items:
>>>>> + - const: tfe0
>>>>> + - const: tfe1
>>>>> + - const: tfe2
>>>>
>>>> Please remove all 'tfeX' power domains, they are not going to be
>>>> utilized
>>>> any time soon.
>>>>
>>>> When 'power-domains' list is just a single Titan GDSC,
>>>> 'power-domain-names'
>>>> property is not needed.
>>>
>>> Each one of these TFEs powers an individually power-collapsible TFEs.
>>>
>>> This is also so with the other xFE power-domains on previous SoC
>>> generations.
>>
>> This is false, for instance there is no management of SFEx power domains
>> in SM8550 or X1E80100 CAMSS in the upstrem, neither there is no
>> management
>> of SBI, IPE, BPS, CPP and so on GDSC power domans given by CAMCCs.
>>
>> TFEx is no more special, if it's unused, then it should not be added.
> I agree with Bryan, if I understood the original comment correctly. This
> is no different to the IFE0/1/2 GDSCs on SM8550. All the other modules
> listed above (SFE, IPE, BPS etc.) are not supported by the CAMSS driver
> and hence there is no management. However, we need to manage the TOP and
> TFE0/1/2 GDSCs for the real time RDI paths.
Agreed, at first glance I didn't find the management of the TFE power domains
in the driver's change 3/6 from this series, however now I see it was added
along with the 6/6 change.
This my comment is answered, thank you.
>>
>>>
>>> You'll need the TFEx power-domain to process any data on TFEx with the
>>> 'lite' versions being tied to the TOP GDSC.
>>
>> When it is needed, the documentation will be updated accordingly,
>> right now
>> it is unknown what a data processing on TFEx looks like, it might happen
>> that there will be separate device tree nodes for TFEx.
>>
>> TFEx power domains shall be removed right now, unti; a usecase in the
>> upstream
>> CAMSS appears to use them, I haven't seen such code at the moment.
>>
> We attach these power power domains by name in the corresponding driver.
> For instance, the VFE driver attaches the TFE power domains mentioned
> here and are exercised from vfe_set_power() -> vfe_get()
> ->vfe_pm_domain_on(). You can also see the related codes with '.has_pd'
> and '.pd_name' properties in the CAMSS subdev resource structures. Hope
> this clarifies.
>
--
Best wishes,
Vladimir
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: [PATCH v2 2/6] dt-bindings: media: camss: Add qcom,kaanapali-camss binding
2025-10-15 19:45 ` Vladimir Zapolskiy
2025-10-15 21:43 ` Bryan O'Donoghue
@ 2025-10-16 5:50 ` Krzysztof Kozlowski
2025-10-16 23:53 ` Vijay Kumar Tumati
2 siblings, 0 replies; 46+ messages in thread
From: Krzysztof Kozlowski @ 2025-10-16 5:50 UTC (permalink / raw)
To: Vladimir Zapolskiy, Hangxiang Ma, Loic Poulain, Robert Foss,
Andi Shyti, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Todor Tomov, Mauro Carvalho Chehab, Bryan O'Donoghue
Cc: linux-i2c, linux-arm-msm, devicetree, linux-kernel, linux-media,
aiqun.yu, tingwei.zhang, trilok.soni, yijie.yang, Jingyi Wang,
Atiya Kailany
On 15/10/2025 21:45, Vladimir Zapolskiy wrote:
> On 10/15/25 05:56, Hangxiang Ma wrote:
>> +
>> + clock-names:
>> + items:
>> + - const: camnoc_nrt_axi
>> + - const: camnoc_rt_axi
>> + - const: camnoc_rt_vfe0
>> + - const: camnoc_rt_vfe1
>> + - const: camnoc_rt_vfe2
>> + - const: camnoc_rt_vfe_lite
>> + - const: cam_top_ahb
>> + - const: cam_top_fast_ahb
>> + - const: csid
>> + - const: csid_csiphy_rx
>> + - const: csiphy0
>> + - const: csiphy0_timer
>> + - const: csiphy1
>> + - const: csiphy1_timer
>> + - const: csiphy2
>> + - const: csiphy2_timer
>> + - const: csiphy3
>> + - const: csiphy3_timer
>> + - const: csiphy4
>> + - const: csiphy4_timer
>> + - const: csiphy5
>> + - const: csiphy5_timer
>> + - const: gcc_hf_axi
>> + - const: qdss_debug_xo
>> + - const: vfe0
>> + - const: vfe0_fast_ahb
>> + - const: vfe1
>> + - const: vfe1_fast_ahb
>> + - const: vfe2
>> + - const: vfe2_fast_ahb
>> + - const: vfe_lite
>> + - const: vfe_lite_ahb
>> + - const: vfe_lite_cphy_rx
>> + - const: vfe_lite_csid
>
> The list of 'clock-names' values is not alphanumerically sorted.
We are not doing the same discussion fourth time.
NAK to above comment, stop bringing this up finally.
Best regards,
Krzysztof
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: [PATCH v2 2/6] dt-bindings: media: camss: Add qcom,kaanapali-camss binding
2025-10-15 19:45 ` Vladimir Zapolskiy
2025-10-15 21:43 ` Bryan O'Donoghue
2025-10-16 5:50 ` Krzysztof Kozlowski
@ 2025-10-16 23:53 ` Vijay Kumar Tumati
2025-10-17 0:27 ` Vladimir Zapolskiy
2 siblings, 1 reply; 46+ messages in thread
From: Vijay Kumar Tumati @ 2025-10-16 23:53 UTC (permalink / raw)
To: Vladimir Zapolskiy, Hangxiang Ma, Loic Poulain, Robert Foss,
Andi Shyti, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Todor Tomov, Mauro Carvalho Chehab, Bryan O'Donoghue
Cc: linux-i2c, linux-arm-msm, devicetree, linux-kernel, linux-media,
aiqun.yu, tingwei.zhang, trilok.soni, yijie.yang, Jingyi Wang,
Atiya Kailany
On 10/15/2025 12:45 PM, Vladimir Zapolskiy wrote:
> On 10/15/25 05:56, Hangxiang Ma wrote:
>> Add bindings for qcom,kaanapali-camss in order to support the camera
>> subsystem for Kaanapali.
>>
>> Signed-off-by: Hangxiang Ma <hangxiang.ma@oss.qualcomm.com>
>> ---
>> .../bindings/media/qcom,kaanapali-camss.yaml | 494
>> +++++++++++++++++++++
>> 1 file changed, 494 insertions(+)
>>
>> diff --git
>> a/Documentation/devicetree/bindings/media/qcom,kaanapali-camss.yaml
>> b/Documentation/devicetree/bindings/media/qcom,kaanapali-camss.yaml
>> new file mode 100644
>> index 000000000000..d04c21103cfd
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/media/qcom,kaanapali-camss.yaml
>> @@ -0,0 +1,494 @@
>> +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
>> +%YAML 1.2
>> +---
>> +$id: http://devicetree.org/schemas/media/qcom,kaanapali-camss.yaml#
>> +$schema: http://devicetree.org/meta-schemas/core.yaml#
>> +
>> +title: Qualcomm Kaanapali Camera Subsystem (CAMSS)
>> +
>> +maintainers:
>> + - Hangxiang Ma <hangxiang.ma@oss.qualcomm.com>
>> +
>> +description:
>> + The CAMSS IP is a CSI decoder and ISP present on Qualcomm platforms.
>> +
>> +properties:
>> + compatible:
>> + const: qcom,kaanapali-camss
>> +
>> + reg:
>> + maxItems: 16
>> +
>> + reg-names:
>> + items:
>> + - const: csid0
>> + - const: csid1
>> + - const: csid2
>> + - const: csid_lite0
>> + - const: csid_lite1
>> + - const: csiphy0
>> + - const: csiphy1
>> + - const: csiphy2
>> + - const: csiphy3
>> + - const: csiphy4
>> + - const: csiphy5
>> + - const: vfe0
>> + - const: vfe1
>> + - const: vfe2
>> + - const: vfe_lite0
>> + - const: vfe_lite1
>> +
>> + clocks:
>> + maxItems: 34
>> +
>> + clock-names:
>> + items:
>> + - const: camnoc_nrt_axi
>> + - const: camnoc_rt_axi
>> + - const: camnoc_rt_vfe0
>> + - const: camnoc_rt_vfe1
>> + - const: camnoc_rt_vfe2
>> + - const: camnoc_rt_vfe_lite
>> + - const: cam_top_ahb
>> + - const: cam_top_fast_ahb
>> + - const: csid
>> + - const: csid_csiphy_rx
>> + - const: csiphy0
>> + - const: csiphy0_timer
>> + - const: csiphy1
>> + - const: csiphy1_timer
>> + - const: csiphy2
>> + - const: csiphy2_timer
>> + - const: csiphy3
>> + - const: csiphy3_timer
>> + - const: csiphy4
>> + - const: csiphy4_timer
>> + - const: csiphy5
>> + - const: csiphy5_timer
>> + - const: gcc_hf_axi
>> + - const: qdss_debug_xo
>> + - const: vfe0
>> + - const: vfe0_fast_ahb
>> + - const: vfe1
>> + - const: vfe1_fast_ahb
>> + - const: vfe2
>> + - const: vfe2_fast_ahb
>> + - const: vfe_lite
>> + - const: vfe_lite_ahb
>> + - const: vfe_lite_cphy_rx
>> + - const: vfe_lite_csid
>
> The list of 'clock-names' values is not alphanumerically sorted.
>
>> +
>> + interrupts:
>> + maxItems: 16
>> + interrupt-names:
>
> Missing empty line to separate properties.
>
>> + items:
>> + - const: csid0
>> + - const: csid1
>> + - const: csid2
>> + - const: csid_lite0
>> + - const: csid_lite1
>> + - const: csiphy0
>> + - const: csiphy1
>> + - const: csiphy2
>> + - const: csiphy3
>> + - const: csiphy4
>> + - const: csiphy5
>> + - const: vfe0
>> + - const: vfe1
>> + - const: vfe2
>> + - const: vfe_lite0
>> + - const: vfe_lite1
>> +
>> + interconnects:
>> + maxItems: 2
>> +
>> + interconnect-names:
>> + items:
>> + - const: ahb
>> + - const: hf_0_mnoc
>
> Please rename "hf_0_mnoc" to "hf_mnoc", see qcom,qcm2290-camss.yaml etc.
>
>> +
>> + iommus:
>> + maxItems: 1
>> +
>> + power-domains:
>> + items:
>> + - description:
>> + TFE0 GDSC - Thin Front End, Global Distributed Switch
>> Controller.
>> + - description:
>> + TFE1 GDSC - Thin Front End, Global Distributed Switch
>> Controller.
>> + - description:
>> + TFE2 GDSC - Thin Front End, Global Distributed Switch
>> Controller.
>> + - description:
>> + Titan GDSC - Titan ISP Block Global Distributed Switch
>> Controller.
>> +
>> + power-domain-names:
>> + items:
>> + - const: tfe0
>> + - const: tfe1
>> + - const: tfe2
>
> Please remove all 'tfeX' power domains, they are not going to be utilized
> any time soon.
>
> When 'power-domains' list is just a single Titan GDSC,
> 'power-domain-names'
> property is not needed.
>
>> + - const: top
>> +
>> + vdda-pll-supply:
>> + description:
>> + Phandle to 1.2V regulator supply to PHY refclk pll block.
>> +
>> + vdda-phy0-supply:
>> + description:
>> + Phandle to 0.8V regulator supply to PHY core block.
>> +
>> + vdda-phy1-supply:
>> + description:
>> + Phandle to 0.8V regulator supply to PHY core block.
>> +
>> + vdda-phy2-supply:
>> + description:
>> + Phandle to 0.8V regulator supply to PHY core block.
>> +
>> + vdda-phy3-supply:
>> + description:
>> + Phandle to 0.8V regulator supply to PHY core block.
>> +
>> + vdda-phy4-supply:
>> + description:
>> + Phandle to 0.8V regulator supply to PHY core block.
>> +
>> + vdda-phy5-supply:
>> + description:
>> + Phandle to 0.8V regulator supply to PHY core block.
>
> What is the difference between vdda-phyX-supply properties, why do you
> need so many of them, when their descriptions say they are all the same?
Each of these supply power to a specific CSIPHY and could be different
based on the board architecture. But I agree that the description should
probably capture that than just relying on the name.
>
>> + ports:
>> + $ref: /schemas/graph.yaml#/properties/ports
>> +
>> + description:
>> + CSI input ports.
>> +
>> + properties:
>> + port@0:
>
> Please use
>
> patternProperties:
> "^port@[0-3]$":
>
>> + $ref: /schemas/graph.yaml#/$defs/port-base
>> + unevaluatedProperties: false
>> + description:
>> + Input port for receiving CSI data on CSI0.
>> +
>> + properties:
>> + endpoint:
>> + $ref: video-interfaces.yaml#
>> + unevaluatedProperties: false
>> +
>> + properties:
>> + clock-lanes:
>> + maxItems: 1
>
> Please remove 'clock-lanes' property, it is non-configurable, redundant
> and tends to store some irrelevant value.
>
>> +
>> + data-lanes:
>> + minItems: 1
>> + maxItems: 4
>> +
>> + bus-type:
>> + enum:
>> + - 1 # MEDIA_BUS_TYPE_CSI2_CPHY
>> + - 4 # MEDIA_BUS_TYPE_CSI2_DPHY
>> +
>> + required:
>> + - clock-lanes
>
> The 'clock-lanes' property is expected to be removed.
>
>> + - data-lanes
>> +
>> + port@1:
>> + $ref: /schemas/graph.yaml#/$defs/port-base
>> + unevaluatedProperties: false
>> + description:
>> + Input port for receiving CSI data on CSI1.
>> +
>> + properties:
>> + endpoint:
>> + $ref: video-interfaces.yaml#
>> + unevaluatedProperties: false
>> +
>> + properties:
>> + clock-lanes:
>> + maxItems: 1
>> +
>> + data-lanes:
>> + minItems: 1
>> + maxItems: 4
>> +
>> + bus-type:
>> + enum:
>> + - 1 # MEDIA_BUS_TYPE_CSI2_CPHY
>> + - 4 # MEDIA_BUS_TYPE_CSI2_DPHY
>> +
>> + required:
>> + - clock-lanes
>> + - data-lanes
>> +
>> + port@2:
>> + $ref: /schemas/graph.yaml#/$defs/port-base
>> + unevaluatedProperties: false
>> + description:
>> + Input port for receiving CSI data on CSI2.
>> +
>> + properties:
>> + endpoint:
>> + $ref: video-interfaces.yaml#
>> + unevaluatedProperties: false
>> +
>> + properties:
>> + clock-lanes:
>> + maxItems: 1
>> +
>> + data-lanes:
>> + minItems: 1
>> + maxItems: 4
>> +
>> + bus-type:
>> + enum:
>> + - 1 # MEDIA_BUS_TYPE_CSI2_CPHY
>> + - 4 # MEDIA_BUS_TYPE_CSI2_DPHY
>> +
>> + required:
>> + - clock-lanes
>> + - data-lanes
>> +
>> + port@3:
>> + $ref: /schemas/graph.yaml#/$defs/port-base
>> + unevaluatedProperties: false
>> + description:
>> + Input port for receiving CSI data on CSI3.
>> +
>> + properties:
>> + endpoint:
>> + $ref: video-interfaces.yaml#
>> + unevaluatedProperties: false
>> +
>> + properties:
>> + clock-lanes:
>> + maxItems: 1
>> +
>> + data-lanes:
>> + minItems: 1
>> + maxItems: 4
>> +
>> + bus-type:
>> + enum:
>> + - 1 # MEDIA_BUS_TYPE_CSI2_CPHY
>> + - 4 # MEDIA_BUS_TYPE_CSI2_DPHY
>> +
>> + required:
>> + - clock-lanes
>> + - data-lanes
>> +
>> +required:
>> + - compatible
>> + - reg
>> + - reg-names
>> + - clocks
>> + - clock-names
>> + - interrupts
>> + - interrupt-names
>> + - interconnects
>> + - interconnect-names
>> + - iommus
>> + - power-domains
>> + - power-domain-names
>> + - vdda-pll-supply
>> + - vdda-phy0-supply
>> + - vdda-phy1-supply
>> + - vdda-phy2-supply
>> + - vdda-phy3-supply
>> + - vdda-phy4-supply
>> + - vdda-phy5-supply
>
> Please exclude supplies from the list of required properties.
One of these supplies is required based which PHY the use case is being
run. Can you please advise how to handle that? Thanks.
>
>> +
>> +additionalProperties: false
>> +
>> +examples:
>> + - |
>> + #include <dt-bindings/clock/qcom,rpmh.h>
>> + #include <dt-bindings/clock/qcom,kaanapali-camcc.h>
>> + #include <dt-bindings/clock/qcom,kaanapali-gcc.h>
>> + #include <dt-bindings/interconnect/qcom,icc.h>
>> + #include <dt-bindings/interconnect/qcom,kaanapali-rpmh.h>
>> + #include <dt-bindings/interrupt-controller/arm-gic.h>
>> + #include <dt-bindings/power/qcom,rpmhpd.h>
>
> Please keep the list of included headers sorted alphabetically.
>
>> +
>> + soc {
>> + #address-cells = <2>;
>> + #size-cells = <2>;
>> +
>> + camss: isp@9253000 {
>> + compatible = "qcom,kaanapali-camss";
>> +
>> + reg = <0x0 0x09253000 0x0 0x5e80>,
>> + <0x0 0x09263000 0x0 0x5e80>,
>> + <0x0 0x09273000 0x0 0x5e80>,
>> + <0x0 0x092d3000 0x0 0x3880>,
>> + <0x0 0x092e7000 0x0 0x3880>,
>> + <0x0 0x09523000 0x0 0x2000>,
>> + <0x0 0x09525000 0x0 0x2000>,
>> + <0x0 0x09527000 0x0 0x2000>,
>> + <0x0 0x09529000 0x0 0x2000>,
>> + <0x0 0x0952b000 0x0 0x2000>,
>> + <0x0 0x0952d000 0x0 0x2000>,
>> + <0x0 0x09151000 0x0 0x20000>,
>> + <0x0 0x09171000 0x0 0x20000>,
>> + <0x0 0x09191000 0x0 0x20000>,
>> + <0x0 0x092dc000 0x0 0x1300>,
>> + <0x0 0x092f0000 0x0 0x1300>;
>> + reg-names = "csid0",
>> + "csid1",
>> + "csid2",
>> + "csid_lite0",
>> + "csid_lite1",
>> + "csiphy0",
>> + "csiphy1",
>> + "csiphy2",
>> + "csiphy3",
>> + "csiphy4",
>> + "csiphy5",
>> + "vfe0",
>> + "vfe1",
>> + "vfe2",
>> + "vfe_lite0",
>> + "vfe_lite1";
>> +
>> + clocks = <&camcc CAM_CC_CAMNOC_NRT_AXI_CLK>,
>> + <&camcc CAM_CC_CAMNOC_RT_AXI_CLK>,
>> + <&camcc CAM_CC_CAMNOC_RT_TFE_0_MAIN_CLK>,
>> + <&camcc CAM_CC_CAMNOC_RT_TFE_1_MAIN_CLK>,
>> + <&camcc CAM_CC_CAMNOC_RT_TFE_2_MAIN_CLK>,
>> + <&camcc CAM_CC_CAMNOC_RT_IFE_LITE_CLK>,
>> + <&camcc CAM_CC_CAM_TOP_AHB_CLK>,
>> + <&camcc CAM_CC_CAM_TOP_FAST_AHB_CLK>,
>> + <&camcc CAM_CC_CSID_CLK>,
>> + <&camcc CAM_CC_CSID_CSIPHY_RX_CLK>,
>> + <&camcc CAM_CC_CSIPHY0_CLK>,
>> + <&camcc CAM_CC_CSI0PHYTIMER_CLK>,
>> + <&camcc CAM_CC_CSIPHY1_CLK>,
>> + <&camcc CAM_CC_CSI1PHYTIMER_CLK>,
>> + <&camcc CAM_CC_CSIPHY2_CLK>,
>> + <&camcc CAM_CC_CSI2PHYTIMER_CLK>,
>> + <&camcc CAM_CC_CSIPHY3_CLK>,
>> + <&camcc CAM_CC_CSI3PHYTIMER_CLK>,
>> + <&camcc CAM_CC_CSIPHY4_CLK>,
>> + <&camcc CAM_CC_CSI4PHYTIMER_CLK>,
>> + <&camcc CAM_CC_CSIPHY5_CLK>,
>> + <&camcc CAM_CC_CSI5PHYTIMER_CLK>,
>> + <&gcc GCC_CAMERA_HF_AXI_CLK>,
>> + <&camcc CAM_CC_QDSS_DEBUG_XO_CLK>,
>> + <&camcc CAM_CC_TFE_0_MAIN_CLK>,
>> + <&camcc CAM_CC_TFE_0_MAIN_FAST_AHB_CLK>,
>> + <&camcc CAM_CC_TFE_1_MAIN_CLK>,
>> + <&camcc CAM_CC_TFE_1_MAIN_FAST_AHB_CLK>,
>> + <&camcc CAM_CC_TFE_2_MAIN_CLK>,
>> + <&camcc CAM_CC_TFE_2_MAIN_FAST_AHB_CLK>,
>> + <&camcc CAM_CC_IFE_LITE_CLK>,
>> + <&camcc CAM_CC_IFE_LITE_AHB_CLK>,
>> + <&camcc CAM_CC_IFE_LITE_CPHY_RX_CLK>,
>> + <&camcc CAM_CC_IFE_LITE_CSID_CLK>;
>> + clock-names = "camnoc_nrt_axi",
>> + "camnoc_rt_axi",
>> + "camnoc_rt_vfe0",
>> + "camnoc_rt_vfe1",
>> + "camnoc_rt_vfe2",
>> + "camnoc_rt_vfe_lite",
>> + "cam_top_ahb",
>> + "cam_top_fast_ahb",
>> + "csid",
>> + "csid_csiphy_rx",
>> + "csiphy0",
>> + "csiphy0_timer",
>> + "csiphy1",
>> + "csiphy1_timer",
>> + "csiphy2",
>> + "csiphy2_timer",
>> + "csiphy3",
>> + "csiphy3_timer",
>> + "csiphy4",
>> + "csiphy4_timer",
>> + "csiphy5",
>> + "csiphy5_timer",
>> + "gcc_hf_axi",
>> + "qdss_debug_xo",
>> + "vfe0",
>> + "vfe0_fast_ahb",
>> + "vfe1",
>> + "vfe1_fast_ahb",
>> + "vfe2",
>> + "vfe2_fast_ahb",
>> + "vfe_lite",
>> + "vfe_lite_ahb",
>> + "vfe_lite_cphy_rx",
>> + "vfe_lite_csid";
>> +
>> + interrupts = <GIC_SPI 601 IRQ_TYPE_EDGE_RISING>,
>> + <GIC_SPI 603 IRQ_TYPE_EDGE_RISING>,
>> + <GIC_SPI 431 IRQ_TYPE_EDGE_RISING>,
>> + <GIC_SPI 605 IRQ_TYPE_EDGE_RISING>,
>> + <GIC_SPI 376 IRQ_TYPE_EDGE_RISING>,
>> + <GIC_SPI 477 IRQ_TYPE_EDGE_RISING>,
>> + <GIC_SPI 478 IRQ_TYPE_EDGE_RISING>,
>> + <GIC_SPI 479 IRQ_TYPE_EDGE_RISING>,
>> + <GIC_SPI 448 IRQ_TYPE_EDGE_RISING>,
>> + <GIC_SPI 122 IRQ_TYPE_EDGE_RISING>,
>> + <GIC_SPI 89 IRQ_TYPE_EDGE_RISING>,
>> + <GIC_SPI 433 IRQ_TYPE_EDGE_RISING>,
>> + <GIC_SPI 436 IRQ_TYPE_EDGE_RISING>,
>> + <GIC_SPI 457 IRQ_TYPE_EDGE_RISING>,
>> + <GIC_SPI 606 IRQ_TYPE_EDGE_RISING>,
>> + <GIC_SPI 377 IRQ_TYPE_EDGE_RISING>;
>> + interrupt-names = "csid0",
>> + "csid1",
>> + "csid2",
>> + "csid_lite0",
>> + "csid_lite1",
>> + "csiphy0",
>> + "csiphy1",
>> + "csiphy2",
>> + "csiphy3",
>> + "csiphy4",
>> + "csiphy5",
>> + "vfe0",
>> + "vfe1",
>> + "vfe2",
>> + "vfe_lite0",
>> + "vfe_lite1";
>> +
>> + interconnects = <&gem_noc MASTER_APPSS_PROC
>> QCOM_ICC_TAG_ACTIVE_ONLY
>> + &config_noc SLAVE_CAMERA_CFG
>> QCOM_ICC_TAG_ACTIVE_ONLY>,
>> + <&mmss_noc MASTER_CAMNOC_HF
>> QCOM_ICC_TAG_ALWAYS
>> + &mc_virt SLAVE_EBI1 QCOM_ICC_TAG_ALWAYS>;
>> + interconnect-names = "ahb",
>> + "hf_0_mnoc";
>> +
>> + iommus = <&apps_smmu 0x1c00 0x00>;
>> +
>> + power-domains = <&camcc CAM_CC_TFE_0_GDSC>,
>> + <&camcc CAM_CC_TFE_1_GDSC>,
>> + <&camcc CAM_CC_TFE_2_GDSC>,
>> + <&camcc CAM_CC_TITAN_TOP_GDSC>;
>> + power-domain-names = "tfe0",
>> + "tfe1",
>> + "tfe2",
>> + "top";
>> +
>> + vdda-pll-supply = <&vreg_l1d_1p2>;
>> + vdda-phy0-supply = <&vreg_l3i_0p8>;
>> + vdda-phy1-supply = <&vreg_l3i_0p8>;
>> + vdda-phy2-supply = <&vreg_l3d_0p8>;
>> + vdda-phy3-supply = <&vreg_l3i_0p8>;
>> + vdda-phy4-supply = <&vreg_l3d_0p8>;
>> + vdda-phy5-supply = <&vreg_l3i_0p8>;
>> +
>> + ports {
>> + #address-cells = <1>;
>> + #size-cells = <0>;
>> +
>> + port@0 {
>> + reg = <0>;
>> +
>> + csiphy_ep0: endpoint {
>> + clock-lanes = <7>;
>> + data-lanes = <0 1>;
>> + remote-endpoint = <&sensor_ep>;
>> + };
>> + };
>> + };
>> + };
>> + };
>>
>
^ permalink raw reply [flat|nested] 46+ messages in thread* Re: [PATCH v2 2/6] dt-bindings: media: camss: Add qcom,kaanapali-camss binding
2025-10-16 23:53 ` Vijay Kumar Tumati
@ 2025-10-17 0:27 ` Vladimir Zapolskiy
2025-10-23 4:52 ` Vijay Kumar Tumati
0 siblings, 1 reply; 46+ messages in thread
From: Vladimir Zapolskiy @ 2025-10-17 0:27 UTC (permalink / raw)
To: Vijay Kumar Tumati, Hangxiang Ma, Loic Poulain, Robert Foss,
Andi Shyti, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Todor Tomov, Mauro Carvalho Chehab, Bryan O'Donoghue
Cc: linux-i2c, linux-arm-msm, devicetree, linux-kernel, linux-media,
aiqun.yu, tingwei.zhang, trilok.soni, yijie.yang, Jingyi Wang,
Atiya Kailany
On 10/17/25 02:53, Vijay Kumar Tumati wrote:
>
> On 10/15/2025 12:45 PM, Vladimir Zapolskiy wrote:
>> On 10/15/25 05:56, Hangxiang Ma wrote:
>>> Add bindings for qcom,kaanapali-camss in order to support the camera
>>> subsystem for Kaanapali.
>>>
>>> Signed-off-by: Hangxiang Ma <hangxiang.ma@oss.qualcomm.com>
>>> ---
>>> .../bindings/media/qcom,kaanapali-camss.yaml | 494
>>> +++++++++++++++++++++
>>> 1 file changed, 494 insertions(+)
>>>
>>> diff --git
>>> a/Documentation/devicetree/bindings/media/qcom,kaanapali-camss.yaml
>>> b/Documentation/devicetree/bindings/media/qcom,kaanapali-camss.yaml
>>> new file mode 100644
>>> index 000000000000..d04c21103cfd
>>> --- /dev/null
>>> +++ b/Documentation/devicetree/bindings/media/qcom,kaanapali-camss.yaml
>>> @@ -0,0 +1,494 @@
>>> +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
>>> +%YAML 1.2
>>> +---
>>> +$id: http://devicetree.org/schemas/media/qcom,kaanapali-camss.yaml#
>>> +$schema: http://devicetree.org/meta-schemas/core.yaml#
>>> +
>>> +title: Qualcomm Kaanapali Camera Subsystem (CAMSS)
>>> +
>>> +maintainers:
>>> + - Hangxiang Ma <hangxiang.ma@oss.qualcomm.com>
>>> +
>>> +description:
>>> + The CAMSS IP is a CSI decoder and ISP present on Qualcomm platforms.
>>> +
>>> +properties:
>>> + compatible:
>>> + const: qcom,kaanapali-camss
>>> +
>>> + reg:
>>> + maxItems: 16
>>> +
>>> + reg-names:
>>> + items:
>>> + - const: csid0
>>> + - const: csid1
>>> + - const: csid2
>>> + - const: csid_lite0
>>> + - const: csid_lite1
>>> + - const: csiphy0
>>> + - const: csiphy1
>>> + - const: csiphy2
>>> + - const: csiphy3
>>> + - const: csiphy4
>>> + - const: csiphy5
>>> + - const: vfe0
>>> + - const: vfe1
>>> + - const: vfe2
>>> + - const: vfe_lite0
>>> + - const: vfe_lite1
>>> +
>>> + clocks:
>>> + maxItems: 34
>>> +
>>> + clock-names:
>>> + items:
>>> + - const: camnoc_nrt_axi
>>> + - const: camnoc_rt_axi
>>> + - const: camnoc_rt_vfe0
>>> + - const: camnoc_rt_vfe1
>>> + - const: camnoc_rt_vfe2
>>> + - const: camnoc_rt_vfe_lite
>>> + - const: cam_top_ahb
>>> + - const: cam_top_fast_ahb
>>> + - const: csid
>>> + - const: csid_csiphy_rx
>>> + - const: csiphy0
>>> + - const: csiphy0_timer
>>> + - const: csiphy1
>>> + - const: csiphy1_timer
>>> + - const: csiphy2
>>> + - const: csiphy2_timer
>>> + - const: csiphy3
>>> + - const: csiphy3_timer
>>> + - const: csiphy4
>>> + - const: csiphy4_timer
>>> + - const: csiphy5
>>> + - const: csiphy5_timer
>>> + - const: gcc_hf_axi
>>> + - const: qdss_debug_xo
>>> + - const: vfe0
>>> + - const: vfe0_fast_ahb
>>> + - const: vfe1
>>> + - const: vfe1_fast_ahb
>>> + - const: vfe2
>>> + - const: vfe2_fast_ahb
>>> + - const: vfe_lite
>>> + - const: vfe_lite_ahb
>>> + - const: vfe_lite_cphy_rx
>>> + - const: vfe_lite_csid
>>
>> The list of 'clock-names' values is not alphanumerically sorted.
>>
>>> +
>>> + interrupts:
>>> + maxItems: 16
>>> + interrupt-names:
>>
>> Missing empty line to separate properties.
>>
>>> + items:
>>> + - const: csid0
>>> + - const: csid1
>>> + - const: csid2
>>> + - const: csid_lite0
>>> + - const: csid_lite1
>>> + - const: csiphy0
>>> + - const: csiphy1
>>> + - const: csiphy2
>>> + - const: csiphy3
>>> + - const: csiphy4
>>> + - const: csiphy5
>>> + - const: vfe0
>>> + - const: vfe1
>>> + - const: vfe2
>>> + - const: vfe_lite0
>>> + - const: vfe_lite1
>>> +
>>> + interconnects:
>>> + maxItems: 2
>>> +
>>> + interconnect-names:
>>> + items:
>>> + - const: ahb
>>> + - const: hf_0_mnoc
>>
>> Please rename "hf_0_mnoc" to "hf_mnoc", see qcom,qcm2290-camss.yaml etc.
>>
>>> +
>>> + iommus:
>>> + maxItems: 1
>>> +
>>> + power-domains:
>>> + items:
>>> + - description:
>>> + TFE0 GDSC - Thin Front End, Global Distributed Switch
>>> Controller.
>>> + - description:
>>> + TFE1 GDSC - Thin Front End, Global Distributed Switch
>>> Controller.
>>> + - description:
>>> + TFE2 GDSC - Thin Front End, Global Distributed Switch
>>> Controller.
>>> + - description:
>>> + Titan GDSC - Titan ISP Block Global Distributed Switch
>>> Controller.
>>> +
>>> + power-domain-names:
>>> + items:
>>> + - const: tfe0
>>> + - const: tfe1
>>> + - const: tfe2
>>
>> Please remove all 'tfeX' power domains, they are not going to be utilized
>> any time soon.
>>
>> When 'power-domains' list is just a single Titan GDSC,
>> 'power-domain-names'
>> property is not needed.
>>
>>> + - const: top
>>> +
>>> + vdda-pll-supply:
>>> + description:
>>> + Phandle to 1.2V regulator supply to PHY refclk pll block.
>>> +
>>> + vdda-phy0-supply:
>>> + description:
>>> + Phandle to 0.8V regulator supply to PHY core block.
>>> +
>>> + vdda-phy1-supply:
>>> + description:
>>> + Phandle to 0.8V regulator supply to PHY core block.
>>> +
>>> + vdda-phy2-supply:
>>> + description:
>>> + Phandle to 0.8V regulator supply to PHY core block.
>>> +
>>> + vdda-phy3-supply:
>>> + description:
>>> + Phandle to 0.8V regulator supply to PHY core block.
>>> +
>>> + vdda-phy4-supply:
>>> + description:
>>> + Phandle to 0.8V regulator supply to PHY core block.
>>> +
>>> + vdda-phy5-supply:
>>> + description:
>>> + Phandle to 0.8V regulator supply to PHY core block.
>>
>> What is the difference between vdda-phyX-supply properties, why do you
>> need so many of them, when their descriptions say they are all the same?
> Each of these supply power to a specific CSIPHY and could be different
> based on the board architecture. But I agree that the description should
> probably capture that than just relying on the name.
>>
>>> + ports:
>>> + $ref: /schemas/graph.yaml#/properties/ports
>>> +
>>> + description:
>>> + CSI input ports.
>>> +
>>> + properties:
>>> + port@0:
>>
>> Please use
>>
>> patternProperties:
>> "^port@[0-3]$":
>>
>>> + $ref: /schemas/graph.yaml#/$defs/port-base
>>> + unevaluatedProperties: false
>>> + description:
>>> + Input port for receiving CSI data on CSI0.
>>> +
>>> + properties:
>>> + endpoint:
>>> + $ref: video-interfaces.yaml#
>>> + unevaluatedProperties: false
>>> +
>>> + properties:
>>> + clock-lanes:
>>> + maxItems: 1
>>
>> Please remove 'clock-lanes' property, it is non-configurable, redundant
>> and tends to store some irrelevant value.
>>
>>> +
>>> + data-lanes:
>>> + minItems: 1
>>> + maxItems: 4
>>> +
>>> + bus-type:
>>> + enum:
>>> + - 1 # MEDIA_BUS_TYPE_CSI2_CPHY
>>> + - 4 # MEDIA_BUS_TYPE_CSI2_DPHY
>>> +
>>> + required:
>>> + - clock-lanes
>>
>> The 'clock-lanes' property is expected to be removed.
>>
>>> + - data-lanes
>>> +
>>> + port@1:
>>> + $ref: /schemas/graph.yaml#/$defs/port-base
>>> + unevaluatedProperties: false
>>> + description:
>>> + Input port for receiving CSI data on CSI1.
>>> +
>>> + properties:
>>> + endpoint:
>>> + $ref: video-interfaces.yaml#
>>> + unevaluatedProperties: false
>>> +
>>> + properties:
>>> + clock-lanes:
>>> + maxItems: 1
>>> +
>>> + data-lanes:
>>> + minItems: 1
>>> + maxItems: 4
>>> +
>>> + bus-type:
>>> + enum:
>>> + - 1 # MEDIA_BUS_TYPE_CSI2_CPHY
>>> + - 4 # MEDIA_BUS_TYPE_CSI2_DPHY
>>> +
>>> + required:
>>> + - clock-lanes
>>> + - data-lanes
>>> +
>>> + port@2:
>>> + $ref: /schemas/graph.yaml#/$defs/port-base
>>> + unevaluatedProperties: false
>>> + description:
>>> + Input port for receiving CSI data on CSI2.
>>> +
>>> + properties:
>>> + endpoint:
>>> + $ref: video-interfaces.yaml#
>>> + unevaluatedProperties: false
>>> +
>>> + properties:
>>> + clock-lanes:
>>> + maxItems: 1
>>> +
>>> + data-lanes:
>>> + minItems: 1
>>> + maxItems: 4
>>> +
>>> + bus-type:
>>> + enum:
>>> + - 1 # MEDIA_BUS_TYPE_CSI2_CPHY
>>> + - 4 # MEDIA_BUS_TYPE_CSI2_DPHY
>>> +
>>> + required:
>>> + - clock-lanes
>>> + - data-lanes
>>> +
>>> + port@3:
>>> + $ref: /schemas/graph.yaml#/$defs/port-base
>>> + unevaluatedProperties: false
>>> + description:
>>> + Input port for receiving CSI data on CSI3.
>>> +
>>> + properties:
>>> + endpoint:
>>> + $ref: video-interfaces.yaml#
>>> + unevaluatedProperties: false
>>> +
>>> + properties:
>>> + clock-lanes:
>>> + maxItems: 1
>>> +
>>> + data-lanes:
>>> + minItems: 1
>>> + maxItems: 4
>>> +
>>> + bus-type:
>>> + enum:
>>> + - 1 # MEDIA_BUS_TYPE_CSI2_CPHY
>>> + - 4 # MEDIA_BUS_TYPE_CSI2_DPHY
>>> +
>>> + required:
>>> + - clock-lanes
>>> + - data-lanes
>>> +
>>> +required:
>>> + - compatible
>>> + - reg
>>> + - reg-names
>>> + - clocks
>>> + - clock-names
>>> + - interrupts
>>> + - interrupt-names
>>> + - interconnects
>>> + - interconnect-names
>>> + - iommus
>>> + - power-domains
>>> + - power-domain-names
>>> + - vdda-pll-supply
>>> + - vdda-phy0-supply
>>> + - vdda-phy1-supply
>>> + - vdda-phy2-supply
>>> + - vdda-phy3-supply
>>> + - vdda-phy4-supply
>>> + - vdda-phy5-supply
>>
>> Please exclude supplies from the list of required properties.
> One of these supplies is required based which PHY the use case is being
> run. Can you please advise how to handle that? Thanks.
1. Please rename all of them, reference to qcom,x1e80100-camss.yaml,
qcom,qcm2290-camss.yaml or published on linux-media qcom,sm8650-camss.yaml
2. Remove all of them from the list of required properties, and in a board
specific dts file add only the neccesary ones, that's it.
--
Best wishes,
Vladimir
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: [PATCH v2 2/6] dt-bindings: media: camss: Add qcom,kaanapali-camss binding
2025-10-17 0:27 ` Vladimir Zapolskiy
@ 2025-10-23 4:52 ` Vijay Kumar Tumati
2025-10-23 11:13 ` Vladimir Zapolskiy
0 siblings, 1 reply; 46+ messages in thread
From: Vijay Kumar Tumati @ 2025-10-23 4:52 UTC (permalink / raw)
To: Vladimir Zapolskiy, Hangxiang Ma, Loic Poulain, Robert Foss,
Andi Shyti, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Todor Tomov, Mauro Carvalho Chehab, Bryan O'Donoghue
Cc: linux-i2c, linux-arm-msm, devicetree, linux-kernel, linux-media,
aiqun.yu, tingwei.zhang, trilok.soni, yijie.yang, Jingyi Wang,
Atiya Kailany
On 10/16/2025 5:27 PM, Vladimir Zapolskiy wrote:
> On 10/17/25 02:53, Vijay Kumar Tumati wrote:
>>
>> On 10/15/2025 12:45 PM, Vladimir Zapolskiy wrote:
>>> On 10/15/25 05:56, Hangxiang Ma wrote:
>>>> Add bindings for qcom,kaanapali-camss in order to support the camera
>>>> subsystem for Kaanapali.
>>>>
>>>> Signed-off-by: Hangxiang Ma <hangxiang.ma@oss.qualcomm.com>
>>>> ---
>>>> .../bindings/media/qcom,kaanapali-camss.yaml | 494
>>>> +++++++++++++++++++++
>>>> 1 file changed, 494 insertions(+)
>>>>
>>>> diff --git
>>>> a/Documentation/devicetree/bindings/media/qcom,kaanapali-camss.yaml
>>>> b/Documentation/devicetree/bindings/media/qcom,kaanapali-camss.yaml
>>>> new file mode 100644
>>>> index 000000000000..d04c21103cfd
>>>> --- /dev/null
>>>> +++
>>>> b/Documentation/devicetree/bindings/media/qcom,kaanapali-camss.yaml
>>>> @@ -0,0 +1,494 @@
>>>> +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
>>>> +%YAML 1.2
>>>> +---
>>>> +$id: http://devicetree.org/schemas/media/qcom,kaanapali-camss.yaml#
>>>> +$schema: http://devicetree.org/meta-schemas/core.yaml#
>>>> +
>>>> +title: Qualcomm Kaanapali Camera Subsystem (CAMSS)
>>>> +
>>>> +maintainers:
>>>> + - Hangxiang Ma <hangxiang.ma@oss.qualcomm.com>
>>>> +
>>>> +description:
>>>> + The CAMSS IP is a CSI decoder and ISP present on Qualcomm
>>>> platforms.
>>>> +
>>>> +properties:
>>>> + compatible:
>>>> + const: qcom,kaanapali-camss
>>>> +
>>>> + reg:
>>>> + maxItems: 16
>>>> +
>>>> + reg-names:
>>>> + items:
>>>> + - const: csid0
>>>> + - const: csid1
>>>> + - const: csid2
>>>> + - const: csid_lite0
>>>> + - const: csid_lite1
>>>> + - const: csiphy0
>>>> + - const: csiphy1
>>>> + - const: csiphy2
>>>> + - const: csiphy3
>>>> + - const: csiphy4
>>>> + - const: csiphy5
>>>> + - const: vfe0
>>>> + - const: vfe1
>>>> + - const: vfe2
>>>> + - const: vfe_lite0
>>>> + - const: vfe_lite1
>>>> +
>>>> + clocks:
>>>> + maxItems: 34
>>>> +
>>>> + clock-names:
>>>> + items:
>>>> + - const: camnoc_nrt_axi
>>>> + - const: camnoc_rt_axi
>>>> + - const: camnoc_rt_vfe0
>>>> + - const: camnoc_rt_vfe1
>>>> + - const: camnoc_rt_vfe2
>>>> + - const: camnoc_rt_vfe_lite
>>>> + - const: cam_top_ahb
>>>> + - const: cam_top_fast_ahb
>>>> + - const: csid
>>>> + - const: csid_csiphy_rx
>>>> + - const: csiphy0
>>>> + - const: csiphy0_timer
>>>> + - const: csiphy1
>>>> + - const: csiphy1_timer
>>>> + - const: csiphy2
>>>> + - const: csiphy2_timer
>>>> + - const: csiphy3
>>>> + - const: csiphy3_timer
>>>> + - const: csiphy4
>>>> + - const: csiphy4_timer
>>>> + - const: csiphy5
>>>> + - const: csiphy5_timer
>>>> + - const: gcc_hf_axi
>>>> + - const: qdss_debug_xo
>>>> + - const: vfe0
>>>> + - const: vfe0_fast_ahb
>>>> + - const: vfe1
>>>> + - const: vfe1_fast_ahb
>>>> + - const: vfe2
>>>> + - const: vfe2_fast_ahb
>>>> + - const: vfe_lite
>>>> + - const: vfe_lite_ahb
>>>> + - const: vfe_lite_cphy_rx
>>>> + - const: vfe_lite_csid
>>>
>>> The list of 'clock-names' values is not alphanumerically sorted.
>>>
>>>> +
>>>> + interrupts:
>>>> + maxItems: 16
>>>> + interrupt-names:
>>>
>>> Missing empty line to separate properties.
>>>
>>>> + items:
>>>> + - const: csid0
>>>> + - const: csid1
>>>> + - const: csid2
>>>> + - const: csid_lite0
>>>> + - const: csid_lite1
>>>> + - const: csiphy0
>>>> + - const: csiphy1
>>>> + - const: csiphy2
>>>> + - const: csiphy3
>>>> + - const: csiphy4
>>>> + - const: csiphy5
>>>> + - const: vfe0
>>>> + - const: vfe1
>>>> + - const: vfe2
>>>> + - const: vfe_lite0
>>>> + - const: vfe_lite1
>>>> +
>>>> + interconnects:
>>>> + maxItems: 2
>>>> +
>>>> + interconnect-names:
>>>> + items:
>>>> + - const: ahb
>>>> + - const: hf_0_mnoc
>>>
>>> Please rename "hf_0_mnoc" to "hf_mnoc", see qcom,qcm2290-camss.yaml
>>> etc.
>>>
>>>> +
>>>> + iommus:
>>>> + maxItems: 1
>>>> +
>>>> + power-domains:
>>>> + items:
>>>> + - description:
>>>> + TFE0 GDSC - Thin Front End, Global Distributed Switch
>>>> Controller.
>>>> + - description:
>>>> + TFE1 GDSC - Thin Front End, Global Distributed Switch
>>>> Controller.
>>>> + - description:
>>>> + TFE2 GDSC - Thin Front End, Global Distributed Switch
>>>> Controller.
>>>> + - description:
>>>> + Titan GDSC - Titan ISP Block Global Distributed Switch
>>>> Controller.
>>>> +
>>>> + power-domain-names:
>>>> + items:
>>>> + - const: tfe0
>>>> + - const: tfe1
>>>> + - const: tfe2
>>>
>>> Please remove all 'tfeX' power domains, they are not going to be
>>> utilized
>>> any time soon.
>>>
>>> When 'power-domains' list is just a single Titan GDSC,
>>> 'power-domain-names'
>>> property is not needed.
>>>
>>>> + - const: top
>>>> +
>>>> + vdda-pll-supply:
>>>> + description:
>>>> + Phandle to 1.2V regulator supply to PHY refclk pll block.
>>>> +
>>>> + vdda-phy0-supply:
>>>> + description:
>>>> + Phandle to 0.8V regulator supply to PHY core block.
>>>> +
>>>> + vdda-phy1-supply:
>>>> + description:
>>>> + Phandle to 0.8V regulator supply to PHY core block.
>>>> +
>>>> + vdda-phy2-supply:
>>>> + description:
>>>> + Phandle to 0.8V regulator supply to PHY core block.
>>>> +
>>>> + vdda-phy3-supply:
>>>> + description:
>>>> + Phandle to 0.8V regulator supply to PHY core block.
>>>> +
>>>> + vdda-phy4-supply:
>>>> + description:
>>>> + Phandle to 0.8V regulator supply to PHY core block.
>>>> +
>>>> + vdda-phy5-supply:
>>>> + description:
>>>> + Phandle to 0.8V regulator supply to PHY core block.
>>>
>>> What is the difference between vdda-phyX-supply properties, why do you
>>> need so many of them, when their descriptions say they are all the
>>> same?
>> Each of these supply power to a specific CSIPHY and could be different
>> based on the board architecture. But I agree that the description should
>> probably capture that than just relying on the name.
>>>
>>>> + ports:
>>>> + $ref: /schemas/graph.yaml#/properties/ports
>>>> +
>>>> + description:
>>>> + CSI input ports.
>>>> +
>>>> + properties:
>>>> + port@0:
>>>
>>> Please use
>>>
>>> patternProperties:
>>> "^port@[0-3]$":
>>>
>>>> + $ref: /schemas/graph.yaml#/$defs/port-base
>>>> + unevaluatedProperties: false
>>>> + description:
>>>> + Input port for receiving CSI data on CSI0.
>>>> +
>>>> + properties:
>>>> + endpoint:
>>>> + $ref: video-interfaces.yaml#
>>>> + unevaluatedProperties: false
>>>> +
>>>> + properties:
>>>> + clock-lanes:
>>>> + maxItems: 1
>>>
>>> Please remove 'clock-lanes' property, it is non-configurable, redundant
>>> and tends to store some irrelevant value.
>>>
>>>> +
>>>> + data-lanes:
>>>> + minItems: 1
>>>> + maxItems: 4
>>>> +
>>>> + bus-type:
>>>> + enum:
>>>> + - 1 # MEDIA_BUS_TYPE_CSI2_CPHY
>>>> + - 4 # MEDIA_BUS_TYPE_CSI2_DPHY
>>>> +
>>>> + required:
>>>> + - clock-lanes
>>>
>>> The 'clock-lanes' property is expected to be removed.
>>>
>>>> + - data-lanes
>>>> +
>>>> + port@1:
>>>> + $ref: /schemas/graph.yaml#/$defs/port-base
>>>> + unevaluatedProperties: false
>>>> + description:
>>>> + Input port for receiving CSI data on CSI1.
>>>> +
>>>> + properties:
>>>> + endpoint:
>>>> + $ref: video-interfaces.yaml#
>>>> + unevaluatedProperties: false
>>>> +
>>>> + properties:
>>>> + clock-lanes:
>>>> + maxItems: 1
>>>> +
>>>> + data-lanes:
>>>> + minItems: 1
>>>> + maxItems: 4
>>>> +
>>>> + bus-type:
>>>> + enum:
>>>> + - 1 # MEDIA_BUS_TYPE_CSI2_CPHY
>>>> + - 4 # MEDIA_BUS_TYPE_CSI2_DPHY
>>>> +
>>>> + required:
>>>> + - clock-lanes
>>>> + - data-lanes
>>>> +
>>>> + port@2:
>>>> + $ref: /schemas/graph.yaml#/$defs/port-base
>>>> + unevaluatedProperties: false
>>>> + description:
>>>> + Input port for receiving CSI data on CSI2.
>>>> +
>>>> + properties:
>>>> + endpoint:
>>>> + $ref: video-interfaces.yaml#
>>>> + unevaluatedProperties: false
>>>> +
>>>> + properties:
>>>> + clock-lanes:
>>>> + maxItems: 1
>>>> +
>>>> + data-lanes:
>>>> + minItems: 1
>>>> + maxItems: 4
>>>> +
>>>> + bus-type:
>>>> + enum:
>>>> + - 1 # MEDIA_BUS_TYPE_CSI2_CPHY
>>>> + - 4 # MEDIA_BUS_TYPE_CSI2_DPHY
>>>> +
>>>> + required:
>>>> + - clock-lanes
>>>> + - data-lanes
>>>> +
>>>> + port@3:
>>>> + $ref: /schemas/graph.yaml#/$defs/port-base
>>>> + unevaluatedProperties: false
>>>> + description:
>>>> + Input port for receiving CSI data on CSI3.
>>>> +
>>>> + properties:
>>>> + endpoint:
>>>> + $ref: video-interfaces.yaml#
>>>> + unevaluatedProperties: false
>>>> +
>>>> + properties:
>>>> + clock-lanes:
>>>> + maxItems: 1
>>>> +
>>>> + data-lanes:
>>>> + minItems: 1
>>>> + maxItems: 4
>>>> +
>>>> + bus-type:
>>>> + enum:
>>>> + - 1 # MEDIA_BUS_TYPE_CSI2_CPHY
>>>> + - 4 # MEDIA_BUS_TYPE_CSI2_DPHY
>>>> +
>>>> + required:
>>>> + - clock-lanes
>>>> + - data-lanes
>>>> +
>>>> +required:
>>>> + - compatible
>>>> + - reg
>>>> + - reg-names
>>>> + - clocks
>>>> + - clock-names
>>>> + - interrupts
>>>> + - interrupt-names
>>>> + - interconnects
>>>> + - interconnect-names
>>>> + - iommus
>>>> + - power-domains
>>>> + - power-domain-names
>>>> + - vdda-pll-supply
>>>> + - vdda-phy0-supply
>>>> + - vdda-phy1-supply
>>>> + - vdda-phy2-supply
>>>> + - vdda-phy3-supply
>>>> + - vdda-phy4-supply
>>>> + - vdda-phy5-supply
>>>
>>> Please exclude supplies from the list of required properties.
>> One of these supplies is required based which PHY the use case is being
>> run. Can you please advise how to handle that? Thanks.
>
> 1. Please rename all of them, reference to qcom,x1e80100-camss.yaml,
> qcom,qcm2290-camss.yaml or published on linux-media
> qcom,sm8650-camss.yaml
>
> 2. Remove all of them from the list of required properties, and in a
> board
> specific dts file add only the neccesary ones, that's it.
>
Thanks. We will try to follow the same for rev3. Just a caveat though.
If, for instance, two CSIPHYs have different 1.2 supplies and they are
required to be operated concurrently, it may be is a problem? as we can
put only one of those in the board specific DTS for the 1.2 supply node
(ex: vdd-csiphy-1p2 in SM2290). Is it not? However, if we don't have
such a use case requirement on the upstream may be it's OK. Thank you.
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: [PATCH v2 2/6] dt-bindings: media: camss: Add qcom,kaanapali-camss binding
2025-10-23 4:52 ` Vijay Kumar Tumati
@ 2025-10-23 11:13 ` Vladimir Zapolskiy
2025-10-23 18:06 ` Vijay Kumar Tumati
0 siblings, 1 reply; 46+ messages in thread
From: Vladimir Zapolskiy @ 2025-10-23 11:13 UTC (permalink / raw)
To: Vijay Kumar Tumati, Hangxiang Ma, Loic Poulain, Robert Foss,
Andi Shyti, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Todor Tomov, Mauro Carvalho Chehab, Bryan O'Donoghue
Cc: linux-i2c, linux-arm-msm, devicetree, linux-kernel, linux-media,
aiqun.yu, tingwei.zhang, trilok.soni, yijie.yang, Jingyi Wang,
Atiya Kailany
Hi Vijay.
On 10/23/25 07:52, Vijay Kumar Tumati wrote:
>
> On 10/16/2025 5:27 PM, Vladimir Zapolskiy wrote:
>> On 10/17/25 02:53, Vijay Kumar Tumati wrote:
>>>
>>> On 10/15/2025 12:45 PM, Vladimir Zapolskiy wrote:
>>>> On 10/15/25 05:56, Hangxiang Ma wrote:
>>>>> Add bindings for qcom,kaanapali-camss in order to support the camera
>>>>> subsystem for Kaanapali.
>>>>>
>>>>> Signed-off-by: Hangxiang Ma <hangxiang.ma@oss.qualcomm.com>
>>>>> ---
>>>>> .../bindings/media/qcom,kaanapali-camss.yaml | 494
>>>>> +++++++++++++++++++++
>>>>> 1 file changed, 494 insertions(+)
>>>>>
>>>>> diff --git
>>>>> a/Documentation/devicetree/bindings/media/qcom,kaanapali-camss.yaml
>>>>> b/Documentation/devicetree/bindings/media/qcom,kaanapali-camss.yaml
>>>>> new file mode 100644
>>>>> index 000000000000..d04c21103cfd
>>>>> --- /dev/null
>>>>> +++
>>>>> b/Documentation/devicetree/bindings/media/qcom,kaanapali-camss.yaml
>>>>> @@ -0,0 +1,494 @@
>>>>> +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
>>>>> +%YAML 1.2
>>>>> +---
>>>>> +$id: http://devicetree.org/schemas/media/qcom,kaanapali-camss.yaml#
>>>>> +$schema: http://devicetree.org/meta-schemas/core.yaml#
>>>>> +
>>>>> +title: Qualcomm Kaanapali Camera Subsystem (CAMSS)
>>>>> +
>>>>> +maintainers:
>>>>> + - Hangxiang Ma <hangxiang.ma@oss.qualcomm.com>
>>>>> +
>>>>> +description:
>>>>> + The CAMSS IP is a CSI decoder and ISP present on Qualcomm
>>>>> platforms.
>>>>> +
>>>>> +properties:
>>>>> + compatible:
>>>>> + const: qcom,kaanapali-camss
>>>>> +
>>>>> + reg:
>>>>> + maxItems: 16
>>>>> +
>>>>> + reg-names:
>>>>> + items:
>>>>> + - const: csid0
>>>>> + - const: csid1
>>>>> + - const: csid2
>>>>> + - const: csid_lite0
>>>>> + - const: csid_lite1
>>>>> + - const: csiphy0
>>>>> + - const: csiphy1
>>>>> + - const: csiphy2
>>>>> + - const: csiphy3
>>>>> + - const: csiphy4
>>>>> + - const: csiphy5
>>>>> + - const: vfe0
>>>>> + - const: vfe1
>>>>> + - const: vfe2
>>>>> + - const: vfe_lite0
>>>>> + - const: vfe_lite1
>>>>> +
>>>>> + clocks:
>>>>> + maxItems: 34
>>>>> +
>>>>> + clock-names:
>>>>> + items:
>>>>> + - const: camnoc_nrt_axi
>>>>> + - const: camnoc_rt_axi
>>>>> + - const: camnoc_rt_vfe0
>>>>> + - const: camnoc_rt_vfe1
>>>>> + - const: camnoc_rt_vfe2
>>>>> + - const: camnoc_rt_vfe_lite
>>>>> + - const: cam_top_ahb
>>>>> + - const: cam_top_fast_ahb
>>>>> + - const: csid
>>>>> + - const: csid_csiphy_rx
>>>>> + - const: csiphy0
>>>>> + - const: csiphy0_timer
>>>>> + - const: csiphy1
>>>>> + - const: csiphy1_timer
>>>>> + - const: csiphy2
>>>>> + - const: csiphy2_timer
>>>>> + - const: csiphy3
>>>>> + - const: csiphy3_timer
>>>>> + - const: csiphy4
>>>>> + - const: csiphy4_timer
>>>>> + - const: csiphy5
>>>>> + - const: csiphy5_timer
>>>>> + - const: gcc_hf_axi
>>>>> + - const: qdss_debug_xo
>>>>> + - const: vfe0
>>>>> + - const: vfe0_fast_ahb
>>>>> + - const: vfe1
>>>>> + - const: vfe1_fast_ahb
>>>>> + - const: vfe2
>>>>> + - const: vfe2_fast_ahb
>>>>> + - const: vfe_lite
>>>>> + - const: vfe_lite_ahb
>>>>> + - const: vfe_lite_cphy_rx
>>>>> + - const: vfe_lite_csid
>>>>
>>>> The list of 'clock-names' values is not alphanumerically sorted.
>>>>
>>>>> +
>>>>> + interrupts:
>>>>> + maxItems: 16
>>>>> + interrupt-names:
>>>>
>>>> Missing empty line to separate properties.
>>>>
>>>>> + items:
>>>>> + - const: csid0
>>>>> + - const: csid1
>>>>> + - const: csid2
>>>>> + - const: csid_lite0
>>>>> + - const: csid_lite1
>>>>> + - const: csiphy0
>>>>> + - const: csiphy1
>>>>> + - const: csiphy2
>>>>> + - const: csiphy3
>>>>> + - const: csiphy4
>>>>> + - const: csiphy5
>>>>> + - const: vfe0
>>>>> + - const: vfe1
>>>>> + - const: vfe2
>>>>> + - const: vfe_lite0
>>>>> + - const: vfe_lite1
>>>>> +
>>>>> + interconnects:
>>>>> + maxItems: 2
>>>>> +
>>>>> + interconnect-names:
>>>>> + items:
>>>>> + - const: ahb
>>>>> + - const: hf_0_mnoc
>>>>
>>>> Please rename "hf_0_mnoc" to "hf_mnoc", see qcom,qcm2290-camss.yaml
>>>> etc.
>>>>
>>>>> +
>>>>> + iommus:
>>>>> + maxItems: 1
>>>>> +
>>>>> + power-domains:
>>>>> + items:
>>>>> + - description:
>>>>> + TFE0 GDSC - Thin Front End, Global Distributed Switch
>>>>> Controller.
>>>>> + - description:
>>>>> + TFE1 GDSC - Thin Front End, Global Distributed Switch
>>>>> Controller.
>>>>> + - description:
>>>>> + TFE2 GDSC - Thin Front End, Global Distributed Switch
>>>>> Controller.
>>>>> + - description:
>>>>> + Titan GDSC - Titan ISP Block Global Distributed Switch
>>>>> Controller.
>>>>> +
>>>>> + power-domain-names:
>>>>> + items:
>>>>> + - const: tfe0
>>>>> + - const: tfe1
>>>>> + - const: tfe2
>>>>
>>>> Please remove all 'tfeX' power domains, they are not going to be
>>>> utilized
>>>> any time soon.
>>>>
>>>> When 'power-domains' list is just a single Titan GDSC,
>>>> 'power-domain-names'
>>>> property is not needed.
>>>>
>>>>> + - const: top
>>>>> +
>>>>> + vdda-pll-supply:
>>>>> + description:
>>>>> + Phandle to 1.2V regulator supply to PHY refclk pll block.
>>>>> +
>>>>> + vdda-phy0-supply:
>>>>> + description:
>>>>> + Phandle to 0.8V regulator supply to PHY core block.
>>>>> +
>>>>> + vdda-phy1-supply:
>>>>> + description:
>>>>> + Phandle to 0.8V regulator supply to PHY core block.
>>>>> +
>>>>> + vdda-phy2-supply:
>>>>> + description:
>>>>> + Phandle to 0.8V regulator supply to PHY core block.
>>>>> +
>>>>> + vdda-phy3-supply:
>>>>> + description:
>>>>> + Phandle to 0.8V regulator supply to PHY core block.
>>>>> +
>>>>> + vdda-phy4-supply:
>>>>> + description:
>>>>> + Phandle to 0.8V regulator supply to PHY core block.
>>>>> +
>>>>> + vdda-phy5-supply:
>>>>> + description:
>>>>> + Phandle to 0.8V regulator supply to PHY core block.
>>>>
>>>> What is the difference between vdda-phyX-supply properties, why do you
>>>> need so many of them, when their descriptions say they are all the
>>>> same?
>>> Each of these supply power to a specific CSIPHY and could be different
>>> based on the board architecture. But I agree that the description should
>>> probably capture that than just relying on the name.
>>>>
>>>>> + ports:
>>>>> + $ref: /schemas/graph.yaml#/properties/ports
>>>>> +
>>>>> + description:
>>>>> + CSI input ports.
>>>>> +
>>>>> + properties:
>>>>> + port@0:
>>>>
>>>> Please use
>>>>
>>>> patternProperties:
>>>> "^port@[0-3]$":
>>>>
>>>>> + $ref: /schemas/graph.yaml#/$defs/port-base
>>>>> + unevaluatedProperties: false
>>>>> + description:
>>>>> + Input port for receiving CSI data on CSI0.
>>>>> +
>>>>> + properties:
>>>>> + endpoint:
>>>>> + $ref: video-interfaces.yaml#
>>>>> + unevaluatedProperties: false
>>>>> +
>>>>> + properties:
>>>>> + clock-lanes:
>>>>> + maxItems: 1
>>>>
>>>> Please remove 'clock-lanes' property, it is non-configurable, redundant
>>>> and tends to store some irrelevant value.
>>>>
>>>>> +
>>>>> + data-lanes:
>>>>> + minItems: 1
>>>>> + maxItems: 4
>>>>> +
>>>>> + bus-type:
>>>>> + enum:
>>>>> + - 1 # MEDIA_BUS_TYPE_CSI2_CPHY
>>>>> + - 4 # MEDIA_BUS_TYPE_CSI2_DPHY
>>>>> +
>>>>> + required:
>>>>> + - clock-lanes
>>>>
>>>> The 'clock-lanes' property is expected to be removed.
>>>>
>>>>> + - data-lanes
>>>>> +
>>>>> + port@1:
>>>>> + $ref: /schemas/graph.yaml#/$defs/port-base
>>>>> + unevaluatedProperties: false
>>>>> + description:
>>>>> + Input port for receiving CSI data on CSI1.
>>>>> +
>>>>> + properties:
>>>>> + endpoint:
>>>>> + $ref: video-interfaces.yaml#
>>>>> + unevaluatedProperties: false
>>>>> +
>>>>> + properties:
>>>>> + clock-lanes:
>>>>> + maxItems: 1
>>>>> +
>>>>> + data-lanes:
>>>>> + minItems: 1
>>>>> + maxItems: 4
>>>>> +
>>>>> + bus-type:
>>>>> + enum:
>>>>> + - 1 # MEDIA_BUS_TYPE_CSI2_CPHY
>>>>> + - 4 # MEDIA_BUS_TYPE_CSI2_DPHY
>>>>> +
>>>>> + required:
>>>>> + - clock-lanes
>>>>> + - data-lanes
>>>>> +
>>>>> + port@2:
>>>>> + $ref: /schemas/graph.yaml#/$defs/port-base
>>>>> + unevaluatedProperties: false
>>>>> + description:
>>>>> + Input port for receiving CSI data on CSI2.
>>>>> +
>>>>> + properties:
>>>>> + endpoint:
>>>>> + $ref: video-interfaces.yaml#
>>>>> + unevaluatedProperties: false
>>>>> +
>>>>> + properties:
>>>>> + clock-lanes:
>>>>> + maxItems: 1
>>>>> +
>>>>> + data-lanes:
>>>>> + minItems: 1
>>>>> + maxItems: 4
>>>>> +
>>>>> + bus-type:
>>>>> + enum:
>>>>> + - 1 # MEDIA_BUS_TYPE_CSI2_CPHY
>>>>> + - 4 # MEDIA_BUS_TYPE_CSI2_DPHY
>>>>> +
>>>>> + required:
>>>>> + - clock-lanes
>>>>> + - data-lanes
>>>>> +
>>>>> + port@3:
>>>>> + $ref: /schemas/graph.yaml#/$defs/port-base
>>>>> + unevaluatedProperties: false
>>>>> + description:
>>>>> + Input port for receiving CSI data on CSI3.
>>>>> +
>>>>> + properties:
>>>>> + endpoint:
>>>>> + $ref: video-interfaces.yaml#
>>>>> + unevaluatedProperties: false
>>>>> +
>>>>> + properties:
>>>>> + clock-lanes:
>>>>> + maxItems: 1
>>>>> +
>>>>> + data-lanes:
>>>>> + minItems: 1
>>>>> + maxItems: 4
>>>>> +
>>>>> + bus-type:
>>>>> + enum:
>>>>> + - 1 # MEDIA_BUS_TYPE_CSI2_CPHY
>>>>> + - 4 # MEDIA_BUS_TYPE_CSI2_DPHY
>>>>> +
>>>>> + required:
>>>>> + - clock-lanes
>>>>> + - data-lanes
>>>>> +
>>>>> +required:
>>>>> + - compatible
>>>>> + - reg
>>>>> + - reg-names
>>>>> + - clocks
>>>>> + - clock-names
>>>>> + - interrupts
>>>>> + - interrupt-names
>>>>> + - interconnects
>>>>> + - interconnect-names
>>>>> + - iommus
>>>>> + - power-domains
>>>>> + - power-domain-names
>>>>> + - vdda-pll-supply
>>>>> + - vdda-phy0-supply
>>>>> + - vdda-phy1-supply
>>>>> + - vdda-phy2-supply
>>>>> + - vdda-phy3-supply
>>>>> + - vdda-phy4-supply
>>>>> + - vdda-phy5-supply
>>>>
>>>> Please exclude supplies from the list of required properties.
>>> One of these supplies is required based which PHY the use case is being
>>> run. Can you please advise how to handle that? Thanks.
>>
>> 1. Please rename all of them, reference to qcom,x1e80100-camss.yaml,
>> qcom,qcm2290-camss.yaml or published on linux-media
>> qcom,sm8650-camss.yaml
>>
>> 2. Remove all of them from the list of required properties, and in a
>> board
>> specific dts file add only the neccesary ones, that's it.
>>
> Thanks. We will try to follow the same for rev3. Just a caveat though.
> If, for instance, two CSIPHYs have different 1.2 supplies and they are
> required to be operated concurrently, it may be is a problem? as we can
It should not be a problem, you can add two regulators, and it's fine,
anyway all of them shall be optional properties, because it's unknown in
advance which ones are actually needed.
> put only one of those in the board specific DTS for the 1.2 supply node
> (ex: vdd-csiphy-1p2 in SM2290). Is it not? However, if we don't have
> such a use case requirement on the upstream may be it's OK. Thank you.
Link to the published SM8650 CAMSS dt bindings, please follow this model:
https://lore.kernel.org/linux-media/20251017031131.2232687-2-vladimir.zapolskiy@linaro.org/
Please note the chosen naming scheme, when the supply property names
follow the SoC pad namings one to one.
--
Best wishes,
Vladimir
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: [PATCH v2 2/6] dt-bindings: media: camss: Add qcom,kaanapali-camss binding
2025-10-23 11:13 ` Vladimir Zapolskiy
@ 2025-10-23 18:06 ` Vijay Kumar Tumati
2025-10-24 8:49 ` Bryan O'Donoghue
0 siblings, 1 reply; 46+ messages in thread
From: Vijay Kumar Tumati @ 2025-10-23 18:06 UTC (permalink / raw)
To: Vladimir Zapolskiy, Hangxiang Ma, Loic Poulain, Robert Foss,
Andi Shyti, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Todor Tomov, Mauro Carvalho Chehab, Bryan O'Donoghue
Cc: linux-i2c, linux-arm-msm, devicetree, linux-kernel, linux-media,
aiqun.yu, tingwei.zhang, trilok.soni, yijie.yang, Jingyi Wang,
Atiya Kailany
On 10/23/2025 4:13 AM, Vladimir Zapolskiy wrote:
> Hi Vijay.
>
> On 10/23/25 07:52, Vijay Kumar Tumati wrote:
>>
>> On 10/16/2025 5:27 PM, Vladimir Zapolskiy wrote:
>>> On 10/17/25 02:53, Vijay Kumar Tumati wrote:
>>>>
>>>> On 10/15/2025 12:45 PM, Vladimir Zapolskiy wrote:
>>>>> On 10/15/25 05:56, Hangxiang Ma wrote:
>>>>>> Add bindings for qcom,kaanapali-camss in order to support the camera
>>>>>> subsystem for Kaanapali.
>>>>>>
>>>>>> Signed-off-by: Hangxiang Ma <hangxiang.ma@oss.qualcomm.com>
>>>>>> ---
>>>>>> .../bindings/media/qcom,kaanapali-camss.yaml | 494
>>>>>> +++++++++++++++++++++
>>>>>> 1 file changed, 494 insertions(+)
>>>>>>
>>>>>> diff --git
>>>>>> a/Documentation/devicetree/bindings/media/qcom,kaanapali-camss.yaml
>>>>>> b/Documentation/devicetree/bindings/media/qcom,kaanapali-camss.yaml
>>>>>> new file mode 100644
>>>>>> index 000000000000..d04c21103cfd
>>>>>> --- /dev/null
>>>>>> +++
>>>>>> b/Documentation/devicetree/bindings/media/qcom,kaanapali-camss.yaml
>>>>>> @@ -0,0 +1,494 @@
>>>>>> +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
>>>>>> +%YAML 1.2
>>>>>> +---
>>>>>> +$id: http://devicetree.org/schemas/media/qcom,kaanapali-camss.yaml#
>>>>>> +$schema: http://devicetree.org/meta-schemas/core.yaml#
>>>>>> +
>>>>>> +title: Qualcomm Kaanapali Camera Subsystem (CAMSS)
>>>>>> +
>>>>>> +maintainers:
>>>>>> + - Hangxiang Ma <hangxiang.ma@oss.qualcomm.com>
>>>>>> +
>>>>>> +description:
>>>>>> + The CAMSS IP is a CSI decoder and ISP present on Qualcomm
>>>>>> platforms.
>>>>>> +
>>>>>> +properties:
>>>>>> + compatible:
>>>>>> + const: qcom,kaanapali-camss
>>>>>> +
>>>>>> + reg:
>>>>>> + maxItems: 16
>>>>>> +
>>>>>> + reg-names:
>>>>>> + items:
>>>>>> + - const: csid0
>>>>>> + - const: csid1
>>>>>> + - const: csid2
>>>>>> + - const: csid_lite0
>>>>>> + - const: csid_lite1
>>>>>> + - const: csiphy0
>>>>>> + - const: csiphy1
>>>>>> + - const: csiphy2
>>>>>> + - const: csiphy3
>>>>>> + - const: csiphy4
>>>>>> + - const: csiphy5
>>>>>> + - const: vfe0
>>>>>> + - const: vfe1
>>>>>> + - const: vfe2
>>>>>> + - const: vfe_lite0
>>>>>> + - const: vfe_lite1
>>>>>> +
>>>>>> + clocks:
>>>>>> + maxItems: 34
>>>>>> +
>>>>>> + clock-names:
>>>>>> + items:
>>>>>> + - const: camnoc_nrt_axi
>>>>>> + - const: camnoc_rt_axi
>>>>>> + - const: camnoc_rt_vfe0
>>>>>> + - const: camnoc_rt_vfe1
>>>>>> + - const: camnoc_rt_vfe2
>>>>>> + - const: camnoc_rt_vfe_lite
>>>>>> + - const: cam_top_ahb
>>>>>> + - const: cam_top_fast_ahb
>>>>>> + - const: csid
>>>>>> + - const: csid_csiphy_rx
>>>>>> + - const: csiphy0
>>>>>> + - const: csiphy0_timer
>>>>>> + - const: csiphy1
>>>>>> + - const: csiphy1_timer
>>>>>> + - const: csiphy2
>>>>>> + - const: csiphy2_timer
>>>>>> + - const: csiphy3
>>>>>> + - const: csiphy3_timer
>>>>>> + - const: csiphy4
>>>>>> + - const: csiphy4_timer
>>>>>> + - const: csiphy5
>>>>>> + - const: csiphy5_timer
>>>>>> + - const: gcc_hf_axi
>>>>>> + - const: qdss_debug_xo
>>>>>> + - const: vfe0
>>>>>> + - const: vfe0_fast_ahb
>>>>>> + - const: vfe1
>>>>>> + - const: vfe1_fast_ahb
>>>>>> + - const: vfe2
>>>>>> + - const: vfe2_fast_ahb
>>>>>> + - const: vfe_lite
>>>>>> + - const: vfe_lite_ahb
>>>>>> + - const: vfe_lite_cphy_rx
>>>>>> + - const: vfe_lite_csid
>>>>>
>>>>> The list of 'clock-names' values is not alphanumerically sorted.
>>>>>
>>>>>> +
>>>>>> + interrupts:
>>>>>> + maxItems: 16
>>>>>> + interrupt-names:
>>>>>
>>>>> Missing empty line to separate properties.
>>>>>
>>>>>> + items:
>>>>>> + - const: csid0
>>>>>> + - const: csid1
>>>>>> + - const: csid2
>>>>>> + - const: csid_lite0
>>>>>> + - const: csid_lite1
>>>>>> + - const: csiphy0
>>>>>> + - const: csiphy1
>>>>>> + - const: csiphy2
>>>>>> + - const: csiphy3
>>>>>> + - const: csiphy4
>>>>>> + - const: csiphy5
>>>>>> + - const: vfe0
>>>>>> + - const: vfe1
>>>>>> + - const: vfe2
>>>>>> + - const: vfe_lite0
>>>>>> + - const: vfe_lite1
>>>>>> +
>>>>>> + interconnects:
>>>>>> + maxItems: 2
>>>>>> +
>>>>>> + interconnect-names:
>>>>>> + items:
>>>>>> + - const: ahb
>>>>>> + - const: hf_0_mnoc
>>>>>
>>>>> Please rename "hf_0_mnoc" to "hf_mnoc", see qcom,qcm2290-camss.yaml
>>>>> etc.
>>>>>
>>>>>> +
>>>>>> + iommus:
>>>>>> + maxItems: 1
>>>>>> +
>>>>>> + power-domains:
>>>>>> + items:
>>>>>> + - description:
>>>>>> + TFE0 GDSC - Thin Front End, Global Distributed Switch
>>>>>> Controller.
>>>>>> + - description:
>>>>>> + TFE1 GDSC - Thin Front End, Global Distributed Switch
>>>>>> Controller.
>>>>>> + - description:
>>>>>> + TFE2 GDSC - Thin Front End, Global Distributed Switch
>>>>>> Controller.
>>>>>> + - description:
>>>>>> + Titan GDSC - Titan ISP Block Global Distributed Switch
>>>>>> Controller.
>>>>>> +
>>>>>> + power-domain-names:
>>>>>> + items:
>>>>>> + - const: tfe0
>>>>>> + - const: tfe1
>>>>>> + - const: tfe2
>>>>>
>>>>> Please remove all 'tfeX' power domains, they are not going to be
>>>>> utilized
>>>>> any time soon.
>>>>>
>>>>> When 'power-domains' list is just a single Titan GDSC,
>>>>> 'power-domain-names'
>>>>> property is not needed.
>>>>>
>>>>>> + - const: top
>>>>>> +
>>>>>> + vdda-pll-supply:
>>>>>> + description:
>>>>>> + Phandle to 1.2V regulator supply to PHY refclk pll block.
>>>>>> +
>>>>>> + vdda-phy0-supply:
>>>>>> + description:
>>>>>> + Phandle to 0.8V regulator supply to PHY core block.
>>>>>> +
>>>>>> + vdda-phy1-supply:
>>>>>> + description:
>>>>>> + Phandle to 0.8V regulator supply to PHY core block.
>>>>>> +
>>>>>> + vdda-phy2-supply:
>>>>>> + description:
>>>>>> + Phandle to 0.8V regulator supply to PHY core block.
>>>>>> +
>>>>>> + vdda-phy3-supply:
>>>>>> + description:
>>>>>> + Phandle to 0.8V regulator supply to PHY core block.
>>>>>> +
>>>>>> + vdda-phy4-supply:
>>>>>> + description:
>>>>>> + Phandle to 0.8V regulator supply to PHY core block.
>>>>>> +
>>>>>> + vdda-phy5-supply:
>>>>>> + description:
>>>>>> + Phandle to 0.8V regulator supply to PHY core block.
>>>>>
>>>>> What is the difference between vdda-phyX-supply properties, why do
>>>>> you
>>>>> need so many of them, when their descriptions say they are all the
>>>>> same?
>>>> Each of these supply power to a specific CSIPHY and could be different
>>>> based on the board architecture. But I agree that the description
>>>> should
>>>> probably capture that than just relying on the name.
>>>>>
>>>>>> + ports:
>>>>>> + $ref: /schemas/graph.yaml#/properties/ports
>>>>>> +
>>>>>> + description:
>>>>>> + CSI input ports.
>>>>>> +
>>>>>> + properties:
>>>>>> + port@0:
>>>>>
>>>>> Please use
>>>>>
>>>>> patternProperties:
>>>>> "^port@[0-3]$":
>>>>>
>>>>>> + $ref: /schemas/graph.yaml#/$defs/port-base
>>>>>> + unevaluatedProperties: false
>>>>>> + description:
>>>>>> + Input port for receiving CSI data on CSI0.
>>>>>> +
>>>>>> + properties:
>>>>>> + endpoint:
>>>>>> + $ref: video-interfaces.yaml#
>>>>>> + unevaluatedProperties: false
>>>>>> +
>>>>>> + properties:
>>>>>> + clock-lanes:
>>>>>> + maxItems: 1
>>>>>
>>>>> Please remove 'clock-lanes' property, it is non-configurable,
>>>>> redundant
>>>>> and tends to store some irrelevant value.
>>>>>
>>>>>> +
>>>>>> + data-lanes:
>>>>>> + minItems: 1
>>>>>> + maxItems: 4
>>>>>> +
>>>>>> + bus-type:
>>>>>> + enum:
>>>>>> + - 1 # MEDIA_BUS_TYPE_CSI2_CPHY
>>>>>> + - 4 # MEDIA_BUS_TYPE_CSI2_DPHY
>>>>>> +
>>>>>> + required:
>>>>>> + - clock-lanes
>>>>>
>>>>> The 'clock-lanes' property is expected to be removed.
>>>>>
>>>>>> + - data-lanes
>>>>>> +
>>>>>> + port@1:
>>>>>> + $ref: /schemas/graph.yaml#/$defs/port-base
>>>>>> + unevaluatedProperties: false
>>>>>> + description:
>>>>>> + Input port for receiving CSI data on CSI1.
>>>>>> +
>>>>>> + properties:
>>>>>> + endpoint:
>>>>>> + $ref: video-interfaces.yaml#
>>>>>> + unevaluatedProperties: false
>>>>>> +
>>>>>> + properties:
>>>>>> + clock-lanes:
>>>>>> + maxItems: 1
>>>>>> +
>>>>>> + data-lanes:
>>>>>> + minItems: 1
>>>>>> + maxItems: 4
>>>>>> +
>>>>>> + bus-type:
>>>>>> + enum:
>>>>>> + - 1 # MEDIA_BUS_TYPE_CSI2_CPHY
>>>>>> + - 4 # MEDIA_BUS_TYPE_CSI2_DPHY
>>>>>> +
>>>>>> + required:
>>>>>> + - clock-lanes
>>>>>> + - data-lanes
>>>>>> +
>>>>>> + port@2:
>>>>>> + $ref: /schemas/graph.yaml#/$defs/port-base
>>>>>> + unevaluatedProperties: false
>>>>>> + description:
>>>>>> + Input port for receiving CSI data on CSI2.
>>>>>> +
>>>>>> + properties:
>>>>>> + endpoint:
>>>>>> + $ref: video-interfaces.yaml#
>>>>>> + unevaluatedProperties: false
>>>>>> +
>>>>>> + properties:
>>>>>> + clock-lanes:
>>>>>> + maxItems: 1
>>>>>> +
>>>>>> + data-lanes:
>>>>>> + minItems: 1
>>>>>> + maxItems: 4
>>>>>> +
>>>>>> + bus-type:
>>>>>> + enum:
>>>>>> + - 1 # MEDIA_BUS_TYPE_CSI2_CPHY
>>>>>> + - 4 # MEDIA_BUS_TYPE_CSI2_DPHY
>>>>>> +
>>>>>> + required:
>>>>>> + - clock-lanes
>>>>>> + - data-lanes
>>>>>> +
>>>>>> + port@3:
>>>>>> + $ref: /schemas/graph.yaml#/$defs/port-base
>>>>>> + unevaluatedProperties: false
>>>>>> + description:
>>>>>> + Input port for receiving CSI data on CSI3.
>>>>>> +
>>>>>> + properties:
>>>>>> + endpoint:
>>>>>> + $ref: video-interfaces.yaml#
>>>>>> + unevaluatedProperties: false
>>>>>> +
>>>>>> + properties:
>>>>>> + clock-lanes:
>>>>>> + maxItems: 1
>>>>>> +
>>>>>> + data-lanes:
>>>>>> + minItems: 1
>>>>>> + maxItems: 4
>>>>>> +
>>>>>> + bus-type:
>>>>>> + enum:
>>>>>> + - 1 # MEDIA_BUS_TYPE_CSI2_CPHY
>>>>>> + - 4 # MEDIA_BUS_TYPE_CSI2_DPHY
>>>>>> +
>>>>>> + required:
>>>>>> + - clock-lanes
>>>>>> + - data-lanes
>>>>>> +
>>>>>> +required:
>>>>>> + - compatible
>>>>>> + - reg
>>>>>> + - reg-names
>>>>>> + - clocks
>>>>>> + - clock-names
>>>>>> + - interrupts
>>>>>> + - interrupt-names
>>>>>> + - interconnects
>>>>>> + - interconnect-names
>>>>>> + - iommus
>>>>>> + - power-domains
>>>>>> + - power-domain-names
>>>>>> + - vdda-pll-supply
>>>>>> + - vdda-phy0-supply
>>>>>> + - vdda-phy1-supply
>>>>>> + - vdda-phy2-supply
>>>>>> + - vdda-phy3-supply
>>>>>> + - vdda-phy4-supply
>>>>>> + - vdda-phy5-supply
>>>>>
>>>>> Please exclude supplies from the list of required properties.
>>>> One of these supplies is required based which PHY the use case is
>>>> being
>>>> run. Can you please advise how to handle that? Thanks.
>>>
>>> 1. Please rename all of them, reference to qcom,x1e80100-camss.yaml,
>>> qcom,qcm2290-camss.yaml or published on linux-media
>>> qcom,sm8650-camss.yaml
>>>
>>> 2. Remove all of them from the list of required properties, and in a
>>> board
>>> specific dts file add only the neccesary ones, that's it.
>>>
>> Thanks. We will try to follow the same for rev3. Just a caveat though.
>> If, for instance, two CSIPHYs have different 1.2 supplies and they are
>> required to be operated concurrently, it may be is a problem? as we can
>
> It should not be a problem, you can add two regulators, and it's fine,
> anyway all of them shall be optional properties, because it's unknown in
> advance which ones are actually needed.
>
>> put only one of those in the board specific DTS for the 1.2 supply node
>> (ex: vdd-csiphy-1p2 in SM2290). Is it not? However, if we don't have
>> such a use case requirement on the upstream may be it's OK. Thank you.
>
> Link to the published SM8650 CAMSS dt bindings, please follow this model:
> https://lore.kernel.org/linux-media/20251017031131.2232687-2-vladimir.zapolskiy@linaro.org/
>
>
> Please note the chosen naming scheme, when the supply property names
> follow the SoC pad namings one to one.
>
Thanks @Vladimir. Yes, this make sense if all of the reference and
customer boards follow the internal power grid design. But agreed that
this is all board specific. Please let us know your thoughts on the v3
bindings for KNP. They mimic the existing 2290 and x1e80100 bindings.
Thank you.
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: [PATCH v2 2/6] dt-bindings: media: camss: Add qcom,kaanapali-camss binding
2025-10-23 18:06 ` Vijay Kumar Tumati
@ 2025-10-24 8:49 ` Bryan O'Donoghue
0 siblings, 0 replies; 46+ messages in thread
From: Bryan O'Donoghue @ 2025-10-24 8:49 UTC (permalink / raw)
To: Vijay Kumar Tumati, Vladimir Zapolskiy, Hangxiang Ma,
Loic Poulain, Robert Foss, Andi Shyti, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Todor Tomov,
Mauro Carvalho Chehab
Cc: linux-i2c, linux-arm-msm, devicetree, linux-kernel, linux-media,
aiqun.yu, tingwei.zhang, trilok.soni, yijie.yang, Jingyi Wang,
Atiya Kailany
On 23/10/2025 19:06, Vijay Kumar Tumati wrote:
>
> On 10/23/2025 4:13 AM, Vladimir Zapolskiy wrote:
>> Hi Vijay.
>>
>> On 10/23/25 07:52, Vijay Kumar Tumati wrote:
>>>
>>> On 10/16/2025 5:27 PM, Vladimir Zapolskiy wrote:
>>>> On 10/17/25 02:53, Vijay Kumar Tumati wrote:
>>>>>
>>>>> On 10/15/2025 12:45 PM, Vladimir Zapolskiy wrote:
>>>>>> On 10/15/25 05:56, Hangxiang Ma wrote:
>>>>>>> Add bindings for qcom,kaanapali-camss in order to support the camera
>>>>>>> subsystem for Kaanapali.
>>>>>>>
>>>>>>> Signed-off-by: Hangxiang Ma <hangxiang.ma@oss.qualcomm.com>
>>>>>>> ---
>>>>>>> .../bindings/media/qcom,kaanapali-camss.yaml | 494
>>>>>>> +++++++++++++++++++++
>>>>>>> 1 file changed, 494 insertions(+)
>>>>>>>
>>>>>>> diff --git
>>>>>>> a/Documentation/devicetree/bindings/media/qcom,kaanapali-camss.yaml
>>>>>>> b/Documentation/devicetree/bindings/media/qcom,kaanapali-camss.yaml
>>>>>>> new file mode 100644
>>>>>>> index 000000000000..d04c21103cfd
>>>>>>> --- /dev/null
>>>>>>> +++
>>>>>>> b/Documentation/devicetree/bindings/media/qcom,kaanapali-camss.yaml
>>>>>>> @@ -0,0 +1,494 @@
>>>>>>> +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
>>>>>>> +%YAML 1.2
>>>>>>> +---
>>>>>>> +$id: http://devicetree.org/schemas/media/qcom,kaanapali-camss.yaml#
>>>>>>> +$schema: http://devicetree.org/meta-schemas/core.yaml#
>>>>>>> +
>>>>>>> +title: Qualcomm Kaanapali Camera Subsystem (CAMSS)
>>>>>>> +
>>>>>>> +maintainers:
>>>>>>> + - Hangxiang Ma <hangxiang.ma@oss.qualcomm.com>
>>>>>>> +
>>>>>>> +description:
>>>>>>> + The CAMSS IP is a CSI decoder and ISP present on Qualcomm
>>>>>>> platforms.
>>>>>>> +
>>>>>>> +properties:
>>>>>>> + compatible:
>>>>>>> + const: qcom,kaanapali-camss
>>>>>>> +
>>>>>>> + reg:
>>>>>>> + maxItems: 16
>>>>>>> +
>>>>>>> + reg-names:
>>>>>>> + items:
>>>>>>> + - const: csid0
>>>>>>> + - const: csid1
>>>>>>> + - const: csid2
>>>>>>> + - const: csid_lite0
>>>>>>> + - const: csid_lite1
>>>>>>> + - const: csiphy0
>>>>>>> + - const: csiphy1
>>>>>>> + - const: csiphy2
>>>>>>> + - const: csiphy3
>>>>>>> + - const: csiphy4
>>>>>>> + - const: csiphy5
>>>>>>> + - const: vfe0
>>>>>>> + - const: vfe1
>>>>>>> + - const: vfe2
>>>>>>> + - const: vfe_lite0
>>>>>>> + - const: vfe_lite1
>>>>>>> +
>>>>>>> + clocks:
>>>>>>> + maxItems: 34
>>>>>>> +
>>>>>>> + clock-names:
>>>>>>> + items:
>>>>>>> + - const: camnoc_nrt_axi
>>>>>>> + - const: camnoc_rt_axi
>>>>>>> + - const: camnoc_rt_vfe0
>>>>>>> + - const: camnoc_rt_vfe1
>>>>>>> + - const: camnoc_rt_vfe2
>>>>>>> + - const: camnoc_rt_vfe_lite
>>>>>>> + - const: cam_top_ahb
>>>>>>> + - const: cam_top_fast_ahb
>>>>>>> + - const: csid
>>>>>>> + - const: csid_csiphy_rx
>>>>>>> + - const: csiphy0
>>>>>>> + - const: csiphy0_timer
>>>>>>> + - const: csiphy1
>>>>>>> + - const: csiphy1_timer
>>>>>>> + - const: csiphy2
>>>>>>> + - const: csiphy2_timer
>>>>>>> + - const: csiphy3
>>>>>>> + - const: csiphy3_timer
>>>>>>> + - const: csiphy4
>>>>>>> + - const: csiphy4_timer
>>>>>>> + - const: csiphy5
>>>>>>> + - const: csiphy5_timer
>>>>>>> + - const: gcc_hf_axi
>>>>>>> + - const: qdss_debug_xo
>>>>>>> + - const: vfe0
>>>>>>> + - const: vfe0_fast_ahb
>>>>>>> + - const: vfe1
>>>>>>> + - const: vfe1_fast_ahb
>>>>>>> + - const: vfe2
>>>>>>> + - const: vfe2_fast_ahb
>>>>>>> + - const: vfe_lite
>>>>>>> + - const: vfe_lite_ahb
>>>>>>> + - const: vfe_lite_cphy_rx
>>>>>>> + - const: vfe_lite_csid
>>>>>>
>>>>>> The list of 'clock-names' values is not alphanumerically sorted.
>>>>>>
>>>>>>> +
>>>>>>> + interrupts:
>>>>>>> + maxItems: 16
>>>>>>> + interrupt-names:
>>>>>>
>>>>>> Missing empty line to separate properties.
>>>>>>
>>>>>>> + items:
>>>>>>> + - const: csid0
>>>>>>> + - const: csid1
>>>>>>> + - const: csid2
>>>>>>> + - const: csid_lite0
>>>>>>> + - const: csid_lite1
>>>>>>> + - const: csiphy0
>>>>>>> + - const: csiphy1
>>>>>>> + - const: csiphy2
>>>>>>> + - const: csiphy3
>>>>>>> + - const: csiphy4
>>>>>>> + - const: csiphy5
>>>>>>> + - const: vfe0
>>>>>>> + - const: vfe1
>>>>>>> + - const: vfe2
>>>>>>> + - const: vfe_lite0
>>>>>>> + - const: vfe_lite1
>>>>>>> +
>>>>>>> + interconnects:
>>>>>>> + maxItems: 2
>>>>>>> +
>>>>>>> + interconnect-names:
>>>>>>> + items:
>>>>>>> + - const: ahb
>>>>>>> + - const: hf_0_mnoc
>>>>>>
>>>>>> Please rename "hf_0_mnoc" to "hf_mnoc", see qcom,qcm2290-camss.yaml
>>>>>> etc.
>>>>>>
>>>>>>> +
>>>>>>> + iommus:
>>>>>>> + maxItems: 1
>>>>>>> +
>>>>>>> + power-domains:
>>>>>>> + items:
>>>>>>> + - description:
>>>>>>> + TFE0 GDSC - Thin Front End, Global Distributed Switch
>>>>>>> Controller.
>>>>>>> + - description:
>>>>>>> + TFE1 GDSC - Thin Front End, Global Distributed Switch
>>>>>>> Controller.
>>>>>>> + - description:
>>>>>>> + TFE2 GDSC - Thin Front End, Global Distributed Switch
>>>>>>> Controller.
>>>>>>> + - description:
>>>>>>> + Titan GDSC - Titan ISP Block Global Distributed Switch
>>>>>>> Controller.
>>>>>>> +
>>>>>>> + power-domain-names:
>>>>>>> + items:
>>>>>>> + - const: tfe0
>>>>>>> + - const: tfe1
>>>>>>> + - const: tfe2
>>>>>>
>>>>>> Please remove all 'tfeX' power domains, they are not going to be
>>>>>> utilized
>>>>>> any time soon.
>>>>>>
>>>>>> When 'power-domains' list is just a single Titan GDSC,
>>>>>> 'power-domain-names'
>>>>>> property is not needed.
>>>>>>
>>>>>>> + - const: top
>>>>>>> +
>>>>>>> + vdda-pll-supply:
>>>>>>> + description:
>>>>>>> + Phandle to 1.2V regulator supply to PHY refclk pll block.
>>>>>>> +
>>>>>>> + vdda-phy0-supply:
>>>>>>> + description:
>>>>>>> + Phandle to 0.8V regulator supply to PHY core block.
>>>>>>> +
>>>>>>> + vdda-phy1-supply:
>>>>>>> + description:
>>>>>>> + Phandle to 0.8V regulator supply to PHY core block.
>>>>>>> +
>>>>>>> + vdda-phy2-supply:
>>>>>>> + description:
>>>>>>> + Phandle to 0.8V regulator supply to PHY core block.
>>>>>>> +
>>>>>>> + vdda-phy3-supply:
>>>>>>> + description:
>>>>>>> + Phandle to 0.8V regulator supply to PHY core block.
>>>>>>> +
>>>>>>> + vdda-phy4-supply:
>>>>>>> + description:
>>>>>>> + Phandle to 0.8V regulator supply to PHY core block.
>>>>>>> +
>>>>>>> + vdda-phy5-supply:
>>>>>>> + description:
>>>>>>> + Phandle to 0.8V regulator supply to PHY core block.
>>>>>>
>>>>>> What is the difference between vdda-phyX-supply properties, why do
>>>>>> you
>>>>>> need so many of them, when their descriptions say they are all the
>>>>>> same?
>>>>> Each of these supply power to a specific CSIPHY and could be different
>>>>> based on the board architecture. But I agree that the description
>>>>> should
>>>>> probably capture that than just relying on the name.
>>>>>>
>>>>>>> + ports:
>>>>>>> + $ref: /schemas/graph.yaml#/properties/ports
>>>>>>> +
>>>>>>> + description:
>>>>>>> + CSI input ports.
>>>>>>> +
>>>>>>> + properties:
>>>>>>> + port@0:
>>>>>>
>>>>>> Please use
>>>>>>
>>>>>> patternProperties:
>>>>>> "^port@[0-3]$":
>>>>>>
>>>>>>> + $ref: /schemas/graph.yaml#/$defs/port-base
>>>>>>> + unevaluatedProperties: false
>>>>>>> + description:
>>>>>>> + Input port for receiving CSI data on CSI0.
>>>>>>> +
>>>>>>> + properties:
>>>>>>> + endpoint:
>>>>>>> + $ref: video-interfaces.yaml#
>>>>>>> + unevaluatedProperties: false
>>>>>>> +
>>>>>>> + properties:
>>>>>>> + clock-lanes:
>>>>>>> + maxItems: 1
>>>>>>
>>>>>> Please remove 'clock-lanes' property, it is non-configurable,
>>>>>> redundant
>>>>>> and tends to store some irrelevant value.
>>>>>>
>>>>>>> +
>>>>>>> + data-lanes:
>>>>>>> + minItems: 1
>>>>>>> + maxItems: 4
>>>>>>> +
>>>>>>> + bus-type:
>>>>>>> + enum:
>>>>>>> + - 1 # MEDIA_BUS_TYPE_CSI2_CPHY
>>>>>>> + - 4 # MEDIA_BUS_TYPE_CSI2_DPHY
>>>>>>> +
>>>>>>> + required:
>>>>>>> + - clock-lanes
>>>>>>
>>>>>> The 'clock-lanes' property is expected to be removed.
>>>>>>
>>>>>>> + - data-lanes
>>>>>>> +
>>>>>>> + port@1:
>>>>>>> + $ref: /schemas/graph.yaml#/$defs/port-base
>>>>>>> + unevaluatedProperties: false
>>>>>>> + description:
>>>>>>> + Input port for receiving CSI data on CSI1.
>>>>>>> +
>>>>>>> + properties:
>>>>>>> + endpoint:
>>>>>>> + $ref: video-interfaces.yaml#
>>>>>>> + unevaluatedProperties: false
>>>>>>> +
>>>>>>> + properties:
>>>>>>> + clock-lanes:
>>>>>>> + maxItems: 1
>>>>>>> +
>>>>>>> + data-lanes:
>>>>>>> + minItems: 1
>>>>>>> + maxItems: 4
>>>>>>> +
>>>>>>> + bus-type:
>>>>>>> + enum:
>>>>>>> + - 1 # MEDIA_BUS_TYPE_CSI2_CPHY
>>>>>>> + - 4 # MEDIA_BUS_TYPE_CSI2_DPHY
>>>>>>> +
>>>>>>> + required:
>>>>>>> + - clock-lanes
>>>>>>> + - data-lanes
>>>>>>> +
>>>>>>> + port@2:
>>>>>>> + $ref: /schemas/graph.yaml#/$defs/port-base
>>>>>>> + unevaluatedProperties: false
>>>>>>> + description:
>>>>>>> + Input port for receiving CSI data on CSI2.
>>>>>>> +
>>>>>>> + properties:
>>>>>>> + endpoint:
>>>>>>> + $ref: video-interfaces.yaml#
>>>>>>> + unevaluatedProperties: false
>>>>>>> +
>>>>>>> + properties:
>>>>>>> + clock-lanes:
>>>>>>> + maxItems: 1
>>>>>>> +
>>>>>>> + data-lanes:
>>>>>>> + minItems: 1
>>>>>>> + maxItems: 4
>>>>>>> +
>>>>>>> + bus-type:
>>>>>>> + enum:
>>>>>>> + - 1 # MEDIA_BUS_TYPE_CSI2_CPHY
>>>>>>> + - 4 # MEDIA_BUS_TYPE_CSI2_DPHY
>>>>>>> +
>>>>>>> + required:
>>>>>>> + - clock-lanes
>>>>>>> + - data-lanes
>>>>>>> +
>>>>>>> + port@3:
>>>>>>> + $ref: /schemas/graph.yaml#/$defs/port-base
>>>>>>> + unevaluatedProperties: false
>>>>>>> + description:
>>>>>>> + Input port for receiving CSI data on CSI3.
>>>>>>> +
>>>>>>> + properties:
>>>>>>> + endpoint:
>>>>>>> + $ref: video-interfaces.yaml#
>>>>>>> + unevaluatedProperties: false
>>>>>>> +
>>>>>>> + properties:
>>>>>>> + clock-lanes:
>>>>>>> + maxItems: 1
>>>>>>> +
>>>>>>> + data-lanes:
>>>>>>> + minItems: 1
>>>>>>> + maxItems: 4
>>>>>>> +
>>>>>>> + bus-type:
>>>>>>> + enum:
>>>>>>> + - 1 # MEDIA_BUS_TYPE_CSI2_CPHY
>>>>>>> + - 4 # MEDIA_BUS_TYPE_CSI2_DPHY
>>>>>>> +
>>>>>>> + required:
>>>>>>> + - clock-lanes
>>>>>>> + - data-lanes
>>>>>>> +
>>>>>>> +required:
>>>>>>> + - compatible
>>>>>>> + - reg
>>>>>>> + - reg-names
>>>>>>> + - clocks
>>>>>>> + - clock-names
>>>>>>> + - interrupts
>>>>>>> + - interrupt-names
>>>>>>> + - interconnects
>>>>>>> + - interconnect-names
>>>>>>> + - iommus
>>>>>>> + - power-domains
>>>>>>> + - power-domain-names
>>>>>>> + - vdda-pll-supply
>>>>>>> + - vdda-phy0-supply
>>>>>>> + - vdda-phy1-supply
>>>>>>> + - vdda-phy2-supply
>>>>>>> + - vdda-phy3-supply
>>>>>>> + - vdda-phy4-supply
>>>>>>> + - vdda-phy5-supply
>>>>>>
>>>>>> Please exclude supplies from the list of required properties.
>>>>> One of these supplies is required based which PHY the use case is
>>>>> being
>>>>> run. Can you please advise how to handle that? Thanks.
>>>>
>>>> 1. Please rename all of them, reference to qcom,x1e80100-camss.yaml,
>>>> qcom,qcm2290-camss.yaml or published on linux-media
>>>> qcom,sm8650-camss.yaml
>>>>
>>>> 2. Remove all of them from the list of required properties, and in a
>>>> board
>>>> specific dts file add only the neccesary ones, that's it.
>>>>
>>> Thanks. We will try to follow the same for rev3. Just a caveat though.
>>> If, for instance, two CSIPHYs have different 1.2 supplies and they are
>>> required to be operated concurrently, it may be is a problem? as we can
>>
>> It should not be a problem, you can add two regulators, and it's fine,
>> anyway all of them shall be optional properties, because it's unknown in
>> advance which ones are actually needed.
>>
>>> put only one of those in the board specific DTS for the 1.2 supply node
>>> (ex: vdd-csiphy-1p2 in SM2290). Is it not? However, if we don't have
>>> such a use case requirement on the upstream may be it's OK. Thank you.
>>
>> Link to the published SM8650 CAMSS dt bindings, please follow this model:
>> https://lore.kernel.org/linux-media/20251017031131.2232687-2-
>> vladimir.zapolskiy@linaro.org/
>>
>> Please note the chosen naming scheme, when the supply property names
>> follow the SoC pad namings one to one.
>>
> Thanks @Vladimir. Yes, this make sense if all of the reference and
> customer boards follow the internal power grid design. But agreed that
> this is all board specific. Please let us know your thoughts on the v3
> bindings for KNP. They mimic the existing 2290 and x1e80100 bindings.
> Thank you.
I'd expect to see both the 1p2 and 0p8 for each PHY listed in your bindings.
Without looking at the KNP docs it would be very strange to find the
PHYs share one of these power-rails as an external input from the PCB.
Even if they do, the established pattern for bindings is to describe
each as an individual rail.
Also including the voltage level is
- More consistent with other PHY bindings
- Information that is actually useful when reading a binding
or aligning a binding to a schematic.
---
bod
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: [PATCH v2 2/6] dt-bindings: media: camss: Add qcom,kaanapali-camss binding
2025-10-15 2:56 ` [PATCH v2 2/6] dt-bindings: media: camss: Add qcom,kaanapali-camss binding Hangxiang Ma
2025-10-15 4:37 ` Rob Herring (Arm)
2025-10-15 19:45 ` Vladimir Zapolskiy
@ 2025-10-16 5:52 ` Krzysztof Kozlowski
2 siblings, 0 replies; 46+ messages in thread
From: Krzysztof Kozlowski @ 2025-10-16 5:52 UTC (permalink / raw)
To: Hangxiang Ma, Loic Poulain, Robert Foss, Andi Shyti, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Todor Tomov,
Vladimir Zapolskiy, Mauro Carvalho Chehab, Bryan O'Donoghue
Cc: linux-i2c, linux-arm-msm, devicetree, linux-kernel, linux-media,
aiqun.yu, tingwei.zhang, trilok.soni, yijie.yang, Jingyi Wang,
Atiya Kailany
On 15/10/2025 04:56, Hangxiang Ma wrote:
> Add bindings for qcom,kaanapali-camss in order to support the camera
> subsystem for Kaanapali.
>
> Signed-off-by: Hangxiang Ma <hangxiang.ma@oss.qualcomm.com>
> ---
> .../bindings/media/qcom,kaanapali-camss.yaml | 494 +++++++++++++++++++++
> 1 file changed, 494 insertions(+)
Unresolved comment from Dmitry. Again, your plans don't matter the
community.
Best regards,
Krzysztof
^ permalink raw reply [flat|nested] 46+ messages in thread
* [PATCH v2 3/6] media: qcom: camss: Add Kaanapali compatible camss driver
2025-10-15 2:56 [PATCH v2 0/6] media: qcom: camss: Add Kaanapali support Hangxiang Ma
2025-10-15 2:56 ` [PATCH v2 1/6] dt-bindings: i2c: qcom-cci: Document Kaanapali compatible Hangxiang Ma
2025-10-15 2:56 ` [PATCH v2 2/6] dt-bindings: media: camss: Add qcom,kaanapali-camss binding Hangxiang Ma
@ 2025-10-15 2:56 ` Hangxiang Ma
2025-10-16 8:55 ` Bryan O'Donoghue
2025-10-15 2:56 ` [PATCH v2 4/6] media: qcom: camss: csiphy: Add support for v2.4.0 two-phase CSIPHY Hangxiang Ma
` (2 subsequent siblings)
5 siblings, 1 reply; 46+ messages in thread
From: Hangxiang Ma @ 2025-10-15 2:56 UTC (permalink / raw)
To: Loic Poulain, Robert Foss, Andi Shyti, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Todor Tomov,
Vladimir Zapolskiy, Mauro Carvalho Chehab, Bryan O'Donoghue
Cc: linux-i2c, linux-arm-msm, devicetree, linux-kernel, linux-media,
aiqun.yu, tingwei.zhang, trilok.soni, yijie.yang, Jingyi Wang,
Atiya Kailany, Hangxiang Ma
Add support for kaanapali in the camss driver. Add high level resource
information along with the bus bandwidth votes. Module level detailed
resource information will be enumerated in the following patches of the
series.
Signed-off-by: Hangxiang Ma <hangxiang.ma@oss.qualcomm.com>
---
drivers/media/platform/qcom/camss/camss.c | 22 ++++++++++++++++++++++
drivers/media/platform/qcom/camss/camss.h | 1 +
2 files changed, 23 insertions(+)
diff --git a/drivers/media/platform/qcom/camss/camss.c b/drivers/media/platform/qcom/camss/camss.c
index 2fbcd0e343aa..4a5caf54c116 100644
--- a/drivers/media/platform/qcom/camss/camss.c
+++ b/drivers/media/platform/qcom/camss/camss.c
@@ -34,6 +34,20 @@
static const struct parent_dev_ops vfe_parent_dev_ops;
+static const struct resources_icc icc_res_kaanapali[] = {
+ /* Based on 4096 x 3072 30 FPS 2496 Mbps mode */
+ {
+ .name = "ahb",
+ .icc_bw_tbl.avg = 925857,
+ .icc_bw_tbl.peak = 925857,
+ },
+ {
+ .name = "hf_0_mnoc",
+ .icc_bw_tbl.avg = 925857,
+ .icc_bw_tbl.peak = 925857,
+ },
+};
+
static const struct camss_subdev_resources csiphy_res_8x16[] = {
/* CSIPHY0 */
{
@@ -4291,6 +4305,13 @@ static void camss_remove(struct platform_device *pdev)
camss_genpd_cleanup(camss);
}
+static const struct camss_resources kaanapali_resources = {
+ .version = CAMSS_KAANAPALI,
+ .pd_name = "top",
+ .icc_res = icc_res_kaanapali,
+ .icc_path_num = ARRAY_SIZE(icc_res_kaanapali),
+};
+
static const struct camss_resources msm8916_resources = {
.version = CAMSS_8x16,
.csiphy_res = csiphy_res_8x16,
@@ -4467,6 +4488,7 @@ static const struct camss_resources x1e80100_resources = {
};
static const struct of_device_id camss_dt_match[] = {
+ { .compatible = "qcom,kaanapali-camss", .data = &kaanapali_resources },
{ .compatible = "qcom,msm8916-camss", .data = &msm8916_resources },
{ .compatible = "qcom,msm8953-camss", .data = &msm8953_resources },
{ .compatible = "qcom,msm8996-camss", .data = &msm8996_resources },
diff --git a/drivers/media/platform/qcom/camss/camss.h b/drivers/media/platform/qcom/camss/camss.h
index 901f84efaf7d..876cd2a64cbe 100644
--- a/drivers/media/platform/qcom/camss/camss.h
+++ b/drivers/media/platform/qcom/camss/camss.h
@@ -90,6 +90,7 @@ enum camss_version {
CAMSS_845,
CAMSS_8550,
CAMSS_8775P,
+ CAMSS_KAANAPALI,
CAMSS_X1E80100,
};
--
2.34.1
^ permalink raw reply related [flat|nested] 46+ messages in thread* Re: [PATCH v2 3/6] media: qcom: camss: Add Kaanapali compatible camss driver
2025-10-15 2:56 ` [PATCH v2 3/6] media: qcom: camss: Add Kaanapali compatible camss driver Hangxiang Ma
@ 2025-10-16 8:55 ` Bryan O'Donoghue
2025-10-20 6:45 ` Hangxiang Ma
0 siblings, 1 reply; 46+ messages in thread
From: Bryan O'Donoghue @ 2025-10-16 8:55 UTC (permalink / raw)
To: Hangxiang Ma, Loic Poulain, Robert Foss, Andi Shyti, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Todor Tomov,
Vladimir Zapolskiy, Mauro Carvalho Chehab
Cc: linux-i2c, linux-arm-msm, devicetree, linux-kernel, linux-media,
aiqun.yu, tingwei.zhang, trilok.soni, yijie.yang, Jingyi Wang,
Atiya Kailany
On 15/10/2025 03:56, Hangxiang Ma wrote:
> +static const struct resources_icc icc_res_kaanapali[] = {
> + /* Based on 4096 x 3072 30 FPS 2496 Mbps mode */
> + {
> + .name = "ahb",
> + .icc_bw_tbl.avg = 925857,
> + .icc_bw_tbl.peak = 925857,
> + },
Looking at other implementations I realise we've been adding avg and
peak without too much review however, wouldn't 925857 / 2 => 462928 be a
better value for the average ?
---
bod
^ permalink raw reply [flat|nested] 46+ messages in thread* Re: [PATCH v2 3/6] media: qcom: camss: Add Kaanapali compatible camss driver
2025-10-16 8:55 ` Bryan O'Donoghue
@ 2025-10-20 6:45 ` Hangxiang Ma
2025-10-20 13:38 ` Vijay Kumar Tumati
0 siblings, 1 reply; 46+ messages in thread
From: Hangxiang Ma @ 2025-10-20 6:45 UTC (permalink / raw)
To: Bryan O'Donoghue, Loic Poulain, Robert Foss, Andi Shyti,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Todor Tomov,
Vladimir Zapolskiy, Mauro Carvalho Chehab
Cc: linux-i2c, linux-arm-msm, devicetree, linux-kernel, linux-media,
aiqun.yu, tingwei.zhang, trilok.soni, yijie.yang, Jingyi Wang,
Atiya Kailany
On 10/16/2025 4:55 PM, Bryan O'Donoghue wrote:
> On 15/10/2025 03:56, Hangxiang Ma wrote:
>> +static const struct resources_icc icc_res_kaanapali[] = {
>> + /* Based on 4096 x 3072 30 FPS 2496 Mbps mode */
>> + {
>> + .name = "ahb",
>> + .icc_bw_tbl.avg = 925857,
>> + .icc_bw_tbl.peak = 925857,
>> + },
>
> Looking at other implementations I realise we've been adding avg and
> peak without too much review however, wouldn't 925857 / 2 => 462928 be a
> better value for the average ?
>
> ---
> bod
Ack. Thanks.
---
Hangxiang
^ permalink raw reply [flat|nested] 46+ messages in thread* Re: [PATCH v2 3/6] media: qcom: camss: Add Kaanapali compatible camss driver
2025-10-20 6:45 ` Hangxiang Ma
@ 2025-10-20 13:38 ` Vijay Kumar Tumati
2025-10-20 18:18 ` Bryan O'Donoghue
0 siblings, 1 reply; 46+ messages in thread
From: Vijay Kumar Tumati @ 2025-10-20 13:38 UTC (permalink / raw)
To: Hangxiang Ma, Bryan O'Donoghue, Loic Poulain, Robert Foss,
Andi Shyti, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Todor Tomov, Vladimir Zapolskiy, Mauro Carvalho Chehab
Cc: linux-i2c, linux-arm-msm, devicetree, linux-kernel, linux-media,
aiqun.yu, tingwei.zhang, trilok.soni, yijie.yang, Jingyi Wang,
Atiya Kailany
On 10/19/2025 11:45 PM, Hangxiang Ma wrote:
> On 10/16/2025 4:55 PM, Bryan O'Donoghue wrote:
>> On 15/10/2025 03:56, Hangxiang Ma wrote:
>>> +static const struct resources_icc icc_res_kaanapali[] = {
>>> + /* Based on 4096 x 3072 30 FPS 2496 Mbps mode */
>>> + {
>>> + .name = "ahb",
>>> + .icc_bw_tbl.avg = 925857,
>>> + .icc_bw_tbl.peak = 925857,
>>> + },
>>
>> Looking at other implementations I realise we've been adding avg and
>> peak without too much review however, wouldn't 925857 / 2 => 462928
>> be a better value for the average ?
>>
>> ---
>> bod
>
> Ack. Thanks.
Just adding my thoughts on this, as you know the peak/avg bandwidth
should primarily depends on the sensor data rate and additionally, the
average BW vote should depend on the buffer sizes in the NIUs/NOCs and
(although irrelevant here) whether it's an RT or NRT module (file system
reads/writes from the NRT modules can be averaged and controlled
better). Fundamentally, the votes from all modules go into the
calculation of the DDR clock. The current driver does not take into
account anything. So either way, it is not ideal I think. We can discuss
and come up with a cleaner approach in a different patch series covering
all chip sets. Thanks.
>
> ---
> Hangxiang
>
^ permalink raw reply [flat|nested] 46+ messages in thread* Re: [PATCH v2 3/6] media: qcom: camss: Add Kaanapali compatible camss driver
2025-10-20 13:38 ` Vijay Kumar Tumati
@ 2025-10-20 18:18 ` Bryan O'Donoghue
0 siblings, 0 replies; 46+ messages in thread
From: Bryan O'Donoghue @ 2025-10-20 18:18 UTC (permalink / raw)
To: Vijay Kumar Tumati, Hangxiang Ma, Loic Poulain, Robert Foss,
Andi Shyti, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Todor Tomov, Vladimir Zapolskiy, Mauro Carvalho Chehab
Cc: linux-i2c, linux-arm-msm, devicetree, linux-kernel, linux-media,
aiqun.yu, tingwei.zhang, trilok.soni, yijie.yang, Jingyi Wang,
Atiya Kailany
On 20/10/2025 14:38, Vijay Kumar Tumati wrote:
>>
>> Ack. Thanks.
> Just adding my thoughts on this, as you know the peak/avg bandwidth
> should primarily depends on the sensor data rate and additionally, the
> average BW vote should depend on the buffer sizes in the NIUs/NOCs and
> (although irrelevant here) whether it's an RT or NRT module (file system
> reads/writes from the NRT modules can be averaged and controlled
> better). Fundamentally, the votes from all modules go into the
> calculation of the DDR clock. The current driver does not take into
> account anything. So either way, it is not ideal I think. We can discuss
> and come up with a cleaner approach in a different patch series covering
> all chip sets. Thanks.
Yeah we can.
But please put something more sensible in for v3.
---
bod
^ permalink raw reply [flat|nested] 46+ messages in thread
* [PATCH v2 4/6] media: qcom: camss: csiphy: Add support for v2.4.0 two-phase CSIPHY
2025-10-15 2:56 [PATCH v2 0/6] media: qcom: camss: Add Kaanapali support Hangxiang Ma
` (2 preceding siblings ...)
2025-10-15 2:56 ` [PATCH v2 3/6] media: qcom: camss: Add Kaanapali compatible camss driver Hangxiang Ma
@ 2025-10-15 2:56 ` Hangxiang Ma
2025-10-16 8:59 ` Bryan O'Donoghue
2025-10-15 2:56 ` [PATCH v2 5/6] media: qcom: camss: csid: Add support for CSID 1080 Hangxiang Ma
2025-10-15 2:56 ` [PATCH v2 6/6] media: qcom: camss: vfe: Add support for VFE 1080 Hangxiang Ma
5 siblings, 1 reply; 46+ messages in thread
From: Hangxiang Ma @ 2025-10-15 2:56 UTC (permalink / raw)
To: Loic Poulain, Robert Foss, Andi Shyti, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Todor Tomov,
Vladimir Zapolskiy, Mauro Carvalho Chehab, Bryan O'Donoghue
Cc: linux-i2c, linux-arm-msm, devicetree, linux-kernel, linux-media,
aiqun.yu, tingwei.zhang, trilok.soni, yijie.yang, Jingyi Wang,
Atiya Kailany, Hangxiang Ma
Add more detailed resource information for CSIPHY devices in the camss
driver along with the support for v2.4.0 in the 2 phase CSIPHY driver
that is responsible for the PHY lane register configuration, module
reset and interrupt handling.
Add 'common_status_offset' variable in 'csidphy_device_regs' structure,
which accommodates the offset between common registers and status
registers. Because this specific offset in Kaanapali registers differs
from other versions.
Signed-off-by: Hangxiang Ma <hangxiang.ma@oss.qualcomm.com>
---
.../platform/qcom/camss/camss-csiphy-3ph-1-0.c | 147 ++++++++++++++++++++-
drivers/media/platform/qcom/camss/camss-csiphy.h | 1 +
drivers/media/platform/qcom/camss/camss.c | 107 +++++++++++++++
3 files changed, 249 insertions(+), 6 deletions(-)
diff --git a/drivers/media/platform/qcom/camss/camss-csiphy-3ph-1-0.c b/drivers/media/platform/qcom/camss/camss-csiphy-3ph-1-0.c
index a229ba04b158..192636d02b32 100644
--- a/drivers/media/platform/qcom/camss/camss-csiphy-3ph-1-0.c
+++ b/drivers/media/platform/qcom/camss/camss-csiphy-3ph-1-0.c
@@ -46,7 +46,8 @@
#define CSIPHY_3PH_CMN_CSI_COMMON_CTRL5_CLK_ENABLE BIT(7)
#define CSIPHY_3PH_CMN_CSI_COMMON_CTRL6_COMMON_PWRDN_B BIT(0)
#define CSIPHY_3PH_CMN_CSI_COMMON_CTRL6_SHOW_REV_ID BIT(1)
-#define CSIPHY_3PH_CMN_CSI_COMMON_STATUSn(offset, n) ((offset) + 0xb0 + 0x4 * (n))
+#define CSIPHY_3PH_CMN_CSI_COMMON_STATUSn(offset, common_status_offset, n) \
+ ((offset) + (common_status_offset) + 0x4 * (n))
#define CSIPHY_DEFAULT_PARAMS 0
#define CSIPHY_LANE_ENABLE 1
@@ -587,6 +588,123 @@ csiphy_lane_regs lane_regs_sm8550[] = {
{0x0C64, 0x7F, 0x00, CSIPHY_DEFAULT_PARAMS},
};
+/* 3nm 2PH v 2.4.0 2p5Gbps 4 lane DPHY mode */
+static const struct
+csiphy_lane_regs lane_regs_kaanapali[] = {
+ /* LN 0 */
+ {0x0094, 0x00, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x00A0, 0x00, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x0090, 0x0F, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x0098, 0x08, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x0094, 0x07, 0xd1, CSIPHY_DEFAULT_PARAMS},
+ {0x0030, 0x00, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x0000, 0x8C, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x0038, 0xFE, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x002C, 0x01, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x0034, 0x0F, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x001C, 0x0A, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x0014, 0x60, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x003C, 0xB8, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x0004, 0x0C, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x0020, 0x00, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x0008, 0x19, 0x00, CSIPHY_SETTLE_CNT_LOWER_BYTE},
+ {0x0010, 0x52, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x0094, 0xD7, 0x00, CSIPHY_SKEW_CAL},
+ {0x005C, 0x54, 0x00, CSIPHY_SKEW_CAL},
+ {0x0060, 0xFD, 0x00, CSIPHY_SKEW_CAL},
+ {0x0064, 0x7F, 0x00, CSIPHY_SKEW_CAL},
+
+ /* LN 2 */
+ {0x0494, 0x00, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x04A0, 0x00, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x0490, 0x0F, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x0498, 0x08, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x0494, 0x07, 0xd1, CSIPHY_DEFAULT_PARAMS},
+ {0x0430, 0x00, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x0400, 0x8C, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x0438, 0xFE, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x042C, 0x01, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x0434, 0x0F, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x041C, 0x0A, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x0414, 0x60, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x043C, 0xB8, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x0404, 0x0C, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x0420, 0x00, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x0408, 0x19, 0x00, CSIPHY_SETTLE_CNT_LOWER_BYTE},
+ {0x0410, 0x52, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x0494, 0xD7, 0x00, CSIPHY_SKEW_CAL},
+ {0x045C, 0x54, 0x00, CSIPHY_SKEW_CAL},
+ {0x0460, 0xFD, 0x00, CSIPHY_SKEW_CAL},
+ {0x0464, 0x7F, 0x00, CSIPHY_SKEW_CAL},
+
+ /* LN 4 */
+ {0x0894, 0x00, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x08A0, 0x00, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x0890, 0x0F, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x0898, 0x08, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x0894, 0x07, 0xd1, CSIPHY_DEFAULT_PARAMS},
+ {0x0830, 0x00, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x0800, 0x8C, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x0838, 0xFE, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x082C, 0x01, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x0834, 0x0F, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x081C, 0x0A, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x0814, 0x60, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x083C, 0xB8, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x0804, 0x0C, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x0820, 0x00, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x0808, 0x19, 0x00, CSIPHY_SETTLE_CNT_LOWER_BYTE},
+ {0x0810, 0x52, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x0894, 0xD7, 0x00, CSIPHY_SKEW_CAL},
+ {0x085C, 0x54, 0x00, CSIPHY_SKEW_CAL},
+ {0x0860, 0xFD, 0x00, CSIPHY_SKEW_CAL},
+ {0x0864, 0x7F, 0x00, CSIPHY_SKEW_CAL},
+
+ /* LN 6 */
+ {0x0C94, 0x00, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x0CA0, 0x00, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x0C90, 0x0F, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x0C98, 0x08, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x0C94, 0x07, 0xd1, CSIPHY_DEFAULT_PARAMS},
+ {0x0C30, 0x00, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x0C00, 0x8C, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x0C38, 0xFE, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x0C2C, 0x01, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x0C34, 0x0F, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x0C1C, 0x0A, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x0C14, 0x60, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x0C3C, 0xB8, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x0C04, 0x0C, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x0C20, 0x00, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x0C08, 0x19, 0x00, CSIPHY_SETTLE_CNT_LOWER_BYTE},
+ {0x0C10, 0x52, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x0C94, 0xD7, 0x00, CSIPHY_SKEW_CAL},
+ {0x0C5C, 0x54, 0x00, CSIPHY_SKEW_CAL},
+ {0x0C60, 0xFD, 0x00, CSIPHY_SKEW_CAL},
+ {0x0C64, 0x7F, 0x00, CSIPHY_SKEW_CAL},
+
+ /* LN CLK */
+ {0x0E94, 0x00, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x0EA0, 0x00, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x0E90, 0x0F, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x0E98, 0x08, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x0E94, 0x07, 0xd1, CSIPHY_DEFAULT_PARAMS},
+ {0x0E30, 0x00, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x0E28, 0x04, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x0E00, 0x80, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x0E0C, 0xFF, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x0E38, 0x1F, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x0E2C, 0x01, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x0E34, 0x0F, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x0E1C, 0x0A, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x0E14, 0x60, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x0E3C, 0xB8, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x0E04, 0x0C, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x0E20, 0x00, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x0E08, 0x19, 0x00, CSIPHY_SETTLE_CNT_LOWER_BYTE},
+ {0x0E10, 0x52, 0x00, CSIPHY_DEFAULT_PARAMS},
+};
+
/* 4nm 2PH v 2.1.2 2p5Gbps 4 lane DPHY mode */
static const struct
csiphy_lane_regs lane_regs_x1e80100[] = {
@@ -714,13 +832,21 @@ static void csiphy_hw_version_read(struct csiphy_device *csiphy,
CSIPHY_3PH_CMN_CSI_COMMON_CTRLn(regs->offset, 6));
hw_version = readl_relaxed(csiphy->base +
- CSIPHY_3PH_CMN_CSI_COMMON_STATUSn(regs->offset, 12));
+ CSIPHY_3PH_CMN_CSI_COMMON_STATUSn(
+ regs->offset,
+ regs->common_status_offset, 12));
hw_version |= readl_relaxed(csiphy->base +
- CSIPHY_3PH_CMN_CSI_COMMON_STATUSn(regs->offset, 13)) << 8;
+ CSIPHY_3PH_CMN_CSI_COMMON_STATUSn(
+ regs->offset,
+ regs->common_status_offset, 13)) << 8;
hw_version |= readl_relaxed(csiphy->base +
- CSIPHY_3PH_CMN_CSI_COMMON_STATUSn(regs->offset, 14)) << 16;
+ CSIPHY_3PH_CMN_CSI_COMMON_STATUSn(
+ regs->offset,
+ regs->common_status_offset, 14)) << 16;
hw_version |= readl_relaxed(csiphy->base +
- CSIPHY_3PH_CMN_CSI_COMMON_STATUSn(regs->offset, 15)) << 24;
+ CSIPHY_3PH_CMN_CSI_COMMON_STATUSn(
+ regs->offset,
+ regs->common_status_offset, 15)) << 24;
dev_dbg(dev, "CSIPHY 3PH HW Version = 0x%08x\n", hw_version);
}
@@ -749,7 +875,8 @@ static irqreturn_t csiphy_isr(int irq, void *dev)
for (i = 0; i < 11; i++) {
int c = i + 22;
u8 val = readl_relaxed(csiphy->base +
- CSIPHY_3PH_CMN_CSI_COMMON_STATUSn(regs->offset, i));
+ CSIPHY_3PH_CMN_CSI_COMMON_STATUSn(regs->offset,
+ regs->common_status_offset, i));
writel_relaxed(val, csiphy->base +
CSIPHY_3PH_CMN_CSI_COMMON_CTRLn(regs->offset, c));
@@ -915,6 +1042,7 @@ static bool csiphy_is_gen2(u32 version)
case CAMSS_845:
case CAMSS_8550:
case CAMSS_8775P:
+ case CAMSS_KAANAPALI:
case CAMSS_X1E80100:
ret = true;
break;
@@ -989,6 +1117,7 @@ static int csiphy_init(struct csiphy_device *csiphy)
csiphy->regs = regs;
regs->offset = 0x800;
+ regs->common_status_offset = 0xb0;
switch (csiphy->camss->res->version) {
case CAMSS_845:
@@ -1023,6 +1152,12 @@ static int csiphy_init(struct csiphy_device *csiphy)
regs->lane_regs = &lane_regs_sa8775p[0];
regs->lane_array_size = ARRAY_SIZE(lane_regs_sa8775p);
break;
+ case CAMSS_KAANAPALI:
+ regs->lane_regs = &lane_regs_kaanapali[0];
+ regs->lane_array_size = ARRAY_SIZE(lane_regs_kaanapali);
+ regs->offset = 0x1000;
+ regs->common_status_offset = 0x138;
+ break;
default:
break;
}
diff --git a/drivers/media/platform/qcom/camss/camss-csiphy.h b/drivers/media/platform/qcom/camss/camss-csiphy.h
index 895f80003c44..2d5054819df7 100644
--- a/drivers/media/platform/qcom/camss/camss-csiphy.h
+++ b/drivers/media/platform/qcom/camss/camss-csiphy.h
@@ -90,6 +90,7 @@ struct csiphy_device_regs {
const struct csiphy_lane_regs *lane_regs;
int lane_array_size;
u32 offset;
+ u32 common_status_offset;
};
struct csiphy_device {
diff --git a/drivers/media/platform/qcom/camss/camss.c b/drivers/media/platform/qcom/camss/camss.c
index 4a5caf54c116..542122fba825 100644
--- a/drivers/media/platform/qcom/camss/camss.c
+++ b/drivers/media/platform/qcom/camss/camss.c
@@ -34,6 +34,111 @@
static const struct parent_dev_ops vfe_parent_dev_ops;
+static const struct camss_subdev_resources csiphy_res_kaanapali[] = {
+ /* CSIPHY0 */
+ {
+ .regulators = { "vdda-phy0", "vdda-pll" },
+ .clock = { "csiphy0", "csiphy0_timer",
+ "cam_top_ahb", "cam_top_fast_ahb" },
+ .clock_rate = { { 400000000, 480000000 },
+ { 400000000 },
+ { 0 },
+ { 0 } },
+ .reg = { "csiphy0" },
+ .interrupt = { "csiphy0" },
+ .csiphy = {
+ .id = 0,
+ .hw_ops = &csiphy_ops_3ph_1_0,
+ .formats = &csiphy_formats_sdm845
+ }
+ },
+ /* CSIPHY1 */
+ {
+ .regulators = { "vdda-phy1", "vdda-pll" },
+ .clock = { "csiphy1", "csiphy1_timer",
+ "cam_top_ahb", "cam_top_fast_ahb" },
+ .clock_rate = { { 400000000, 480000000 },
+ { 400000000 },
+ { 0 },
+ { 0 } },
+ .reg = { "csiphy1" },
+ .interrupt = { "csiphy1" },
+ .csiphy = {
+ .id = 1,
+ .hw_ops = &csiphy_ops_3ph_1_0,
+ .formats = &csiphy_formats_sdm845
+ }
+ },
+ /* CSIPHY2 */
+ {
+ .regulators = { "vdda-phy2", "vdda-pll" },
+ .clock = { "csiphy2", "csiphy2_timer",
+ "cam_top_ahb", "cam_top_fast_ahb" },
+ .clock_rate = { { 400000000, 480000000 },
+ { 400000000 },
+ { 0 },
+ { 0 } },
+ .reg = { "csiphy2" },
+ .interrupt = { "csiphy2" },
+ .csiphy = {
+ .id = 2,
+ .hw_ops = &csiphy_ops_3ph_1_0,
+ .formats = &csiphy_formats_sdm845
+ }
+ },
+ /* CSIPHY3 */
+ {
+ .regulators = { "vdda-phy3", "vdda-pll" },
+ .clock = { "csiphy3", "csiphy3_timer",
+ "cam_top_ahb", "cam_top_fast_ahb" },
+ .clock_rate = { { 400000000, 480000000 },
+ { 400000000 },
+ { 0 },
+ { 0 } },
+ .reg = { "csiphy3" },
+ .interrupt = { "csiphy3" },
+ .csiphy = {
+ .id = 3,
+ .hw_ops = &csiphy_ops_3ph_1_0,
+ .formats = &csiphy_formats_sdm845
+ }
+ },
+ /* CSIPHY4 */
+ {
+ .regulators = { "vdda-phy4", "vdda-pll" },
+ .clock = { "csiphy4", "csiphy4_timer",
+ "cam_top_ahb", "cam_top_fast_ahb" },
+ .clock_rate = { { 400000000, 480000000 },
+ { 400000000 },
+ { 0 },
+ { 0 } },
+ .reg = { "csiphy4" },
+ .interrupt = { "csiphy4" },
+ .csiphy = {
+ .id = 4,
+ .hw_ops = &csiphy_ops_3ph_1_0,
+ .formats = &csiphy_formats_sdm845
+ }
+ },
+ /* CSIPHY5 */
+ {
+ .regulators = { "vdda-phy5", "vdda-pll" },
+ .clock = { "csiphy5", "csiphy5_timer",
+ "cam_top_ahb", "cam_top_fast_ahb" },
+ .clock_rate = { { 400000000, 480000000 },
+ { 400000000 },
+ { 0 },
+ { 0 } },
+ .reg = { "csiphy5" },
+ .interrupt = { "csiphy5" },
+ .csiphy = {
+ .id = 5,
+ .hw_ops = &csiphy_ops_3ph_1_0,
+ .formats = &csiphy_formats_sdm845
+ }
+ },
+};
+
static const struct resources_icc icc_res_kaanapali[] = {
/* Based on 4096 x 3072 30 FPS 2496 Mbps mode */
{
@@ -4308,8 +4413,10 @@ static void camss_remove(struct platform_device *pdev)
static const struct camss_resources kaanapali_resources = {
.version = CAMSS_KAANAPALI,
.pd_name = "top",
+ .csiphy_res = csiphy_res_kaanapali,
.icc_res = icc_res_kaanapali,
.icc_path_num = ARRAY_SIZE(icc_res_kaanapali),
+ .csiphy_num = ARRAY_SIZE(csiphy_res_kaanapali),
};
static const struct camss_resources msm8916_resources = {
--
2.34.1
^ permalink raw reply related [flat|nested] 46+ messages in thread* Re: [PATCH v2 4/6] media: qcom: camss: csiphy: Add support for v2.4.0 two-phase CSIPHY
2025-10-15 2:56 ` [PATCH v2 4/6] media: qcom: camss: csiphy: Add support for v2.4.0 two-phase CSIPHY Hangxiang Ma
@ 2025-10-16 8:59 ` Bryan O'Donoghue
2025-10-16 23:10 ` Vijay Kumar Tumati
0 siblings, 1 reply; 46+ messages in thread
From: Bryan O'Donoghue @ 2025-10-16 8:59 UTC (permalink / raw)
To: Hangxiang Ma, Loic Poulain, Robert Foss, Andi Shyti, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Todor Tomov,
Vladimir Zapolskiy, Mauro Carvalho Chehab
Cc: linux-i2c, linux-arm-msm, devicetree, linux-kernel, linux-media,
aiqun.yu, tingwei.zhang, trilok.soni, yijie.yang, Jingyi Wang,
Atiya Kailany
On 15/10/2025 03:56, Hangxiang Ma wrote:
> Add more detailed resource information for CSIPHY devices in the camss
> driver along with the support for v2.4.0 in the 2 phase CSIPHY driver
> that is responsible for the PHY lane register configuration, module
> reset and interrupt handling.
>
> Add 'common_status_offset' variable in 'csidphy_device_regs' structure,
> which accommodates the offset between common registers and status
> registers. Because this specific offset in Kaanapali registers differs
> from other versions.
>
> Signed-off-by: Hangxiang Ma <hangxiang.ma@oss.qualcomm.com>
> ---
> .../platform/qcom/camss/camss-csiphy-3ph-1-0.c | 147 ++++++++++++++++++++-
> drivers/media/platform/qcom/camss/camss-csiphy.h | 1 +
> drivers/media/platform/qcom/camss/camss.c | 107 +++++++++++++++
> 3 files changed, 249 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/media/platform/qcom/camss/camss-csiphy-3ph-1-0.c b/drivers/media/platform/qcom/camss/camss-csiphy-3ph-1-0.c
> index a229ba04b158..192636d02b32 100644
> --- a/drivers/media/platform/qcom/camss/camss-csiphy-3ph-1-0.c
> +++ b/drivers/media/platform/qcom/camss/camss-csiphy-3ph-1-0.c
> @@ -46,7 +46,8 @@
> #define CSIPHY_3PH_CMN_CSI_COMMON_CTRL5_CLK_ENABLE BIT(7)
> #define CSIPHY_3PH_CMN_CSI_COMMON_CTRL6_COMMON_PWRDN_B BIT(0)
> #define CSIPHY_3PH_CMN_CSI_COMMON_CTRL6_SHOW_REV_ID BIT(1)
> -#define CSIPHY_3PH_CMN_CSI_COMMON_STATUSn(offset, n) ((offset) + 0xb0 + 0x4 * (n))
> +#define CSIPHY_3PH_CMN_CSI_COMMON_STATUSn(offset, common_status_offset, n) \
> + ((offset) + (common_status_offset) + 0x4 * (n))
>
> #define CSIPHY_DEFAULT_PARAMS 0
> #define CSIPHY_LANE_ENABLE 1
> @@ -587,6 +588,123 @@ csiphy_lane_regs lane_regs_sm8550[] = {
> {0x0C64, 0x7F, 0x00, CSIPHY_DEFAULT_PARAMS},
> };
>
> +/* 3nm 2PH v 2.4.0 2p5Gbps 4 lane DPHY mode */
I'll again ask for a declaration of the process node this PHY sequence
is fabbed on.
> +static const struct
> +csiphy_lane_regs lane_regs_kaanapali[] = {
> + /* LN 0 */
> + {0x0094, 0x00, 0x00, CSIPHY_DEFAULT_PARAMS},
> + {0x00A0, 0x00, 0x00, CSIPHY_DEFAULT_PARAMS},
> + {0x0090, 0x0F, 0x00, CSIPHY_DEFAULT_PARAMS},
> + {0x0098, 0x08, 0x00, CSIPHY_DEFAULT_PARAMS},
> + {0x0094, 0x07, 0xd1, CSIPHY_DEFAULT_PARAMS},
> + {0x0030, 0x00, 0x00, CSIPHY_DEFAULT_PARAMS},
> + {0x0000, 0x8C, 0x00, CSIPHY_DEFAULT_PARAMS},
> + {0x0038, 0xFE, 0x00, CSIPHY_DEFAULT_PARAMS},
> + {0x002C, 0x01, 0x00, CSIPHY_DEFAULT_PARAMS},
> + {0x0034, 0x0F, 0x00, CSIPHY_DEFAULT_PARAMS},
> + {0x001C, 0x0A, 0x00, CSIPHY_DEFAULT_PARAMS},
> + {0x0014, 0x60, 0x00, CSIPHY_DEFAULT_PARAMS},
> + {0x003C, 0xB8, 0x00, CSIPHY_DEFAULT_PARAMS},
> + {0x0004, 0x0C, 0x00, CSIPHY_DEFAULT_PARAMS},
> + {0x0020, 0x00, 0x00, CSIPHY_DEFAULT_PARAMS},
> + {0x0008, 0x19, 0x00, CSIPHY_SETTLE_CNT_LOWER_BYTE},
> + {0x0010, 0x52, 0x00, CSIPHY_DEFAULT_PARAMS},
> + {0x0094, 0xD7, 0x00, CSIPHY_SKEW_CAL},
> + {0x005C, 0x54, 0x00, CSIPHY_SKEW_CAL},
> + {0x0060, 0xFD, 0x00, CSIPHY_SKEW_CAL},
> + {0x0064, 0x7F, 0x00, CSIPHY_SKEW_CAL},
> +
> + /* LN 2 */
> + {0x0494, 0x00, 0x00, CSIPHY_DEFAULT_PARAMS},
> + {0x04A0, 0x00, 0x00, CSIPHY_DEFAULT_PARAMS},
> + {0x0490, 0x0F, 0x00, CSIPHY_DEFAULT_PARAMS},
> + {0x0498, 0x08, 0x00, CSIPHY_DEFAULT_PARAMS},
> + {0x0494, 0x07, 0xd1, CSIPHY_DEFAULT_PARAMS},
> + {0x0430, 0x00, 0x00, CSIPHY_DEFAULT_PARAMS},
> + {0x0400, 0x8C, 0x00, CSIPHY_DEFAULT_PARAMS},
> + {0x0438, 0xFE, 0x00, CSIPHY_DEFAULT_PARAMS},
> + {0x042C, 0x01, 0x00, CSIPHY_DEFAULT_PARAMS},
> + {0x0434, 0x0F, 0x00, CSIPHY_DEFAULT_PARAMS},
> + {0x041C, 0x0A, 0x00, CSIPHY_DEFAULT_PARAMS},
> + {0x0414, 0x60, 0x00, CSIPHY_DEFAULT_PARAMS},
> + {0x043C, 0xB8, 0x00, CSIPHY_DEFAULT_PARAMS},
> + {0x0404, 0x0C, 0x00, CSIPHY_DEFAULT_PARAMS},
> + {0x0420, 0x00, 0x00, CSIPHY_DEFAULT_PARAMS},
> + {0x0408, 0x19, 0x00, CSIPHY_SETTLE_CNT_LOWER_BYTE},
> + {0x0410, 0x52, 0x00, CSIPHY_DEFAULT_PARAMS},
> + {0x0494, 0xD7, 0x00, CSIPHY_SKEW_CAL},
> + {0x045C, 0x54, 0x00, CSIPHY_SKEW_CAL},
> + {0x0460, 0xFD, 0x00, CSIPHY_SKEW_CAL},
> + {0x0464, 0x7F, 0x00, CSIPHY_SKEW_CAL},
> +
> + /* LN 4 */
> + {0x0894, 0x00, 0x00, CSIPHY_DEFAULT_PARAMS},
> + {0x08A0, 0x00, 0x00, CSIPHY_DEFAULT_PARAMS},
> + {0x0890, 0x0F, 0x00, CSIPHY_DEFAULT_PARAMS},
> + {0x0898, 0x08, 0x00, CSIPHY_DEFAULT_PARAMS},
> + {0x0894, 0x07, 0xd1, CSIPHY_DEFAULT_PARAMS},
> + {0x0830, 0x00, 0x00, CSIPHY_DEFAULT_PARAMS},
> + {0x0800, 0x8C, 0x00, CSIPHY_DEFAULT_PARAMS},
> + {0x0838, 0xFE, 0x00, CSIPHY_DEFAULT_PARAMS},
> + {0x082C, 0x01, 0x00, CSIPHY_DEFAULT_PARAMS},
> + {0x0834, 0x0F, 0x00, CSIPHY_DEFAULT_PARAMS},
> + {0x081C, 0x0A, 0x00, CSIPHY_DEFAULT_PARAMS},
> + {0x0814, 0x60, 0x00, CSIPHY_DEFAULT_PARAMS},
> + {0x083C, 0xB8, 0x00, CSIPHY_DEFAULT_PARAMS},
> + {0x0804, 0x0C, 0x00, CSIPHY_DEFAULT_PARAMS},
> + {0x0820, 0x00, 0x00, CSIPHY_DEFAULT_PARAMS},
> + {0x0808, 0x19, 0x00, CSIPHY_SETTLE_CNT_LOWER_BYTE},
> + {0x0810, 0x52, 0x00, CSIPHY_DEFAULT_PARAMS},
> + {0x0894, 0xD7, 0x00, CSIPHY_SKEW_CAL},
> + {0x085C, 0x54, 0x00, CSIPHY_SKEW_CAL},
> + {0x0860, 0xFD, 0x00, CSIPHY_SKEW_CAL},
> + {0x0864, 0x7F, 0x00, CSIPHY_SKEW_CAL},
> +
> + /* LN 6 */
> + {0x0C94, 0x00, 0x00, CSIPHY_DEFAULT_PARAMS},
> + {0x0CA0, 0x00, 0x00, CSIPHY_DEFAULT_PARAMS},
> + {0x0C90, 0x0F, 0x00, CSIPHY_DEFAULT_PARAMS},
> + {0x0C98, 0x08, 0x00, CSIPHY_DEFAULT_PARAMS},
> + {0x0C94, 0x07, 0xd1, CSIPHY_DEFAULT_PARAMS},
> + {0x0C30, 0x00, 0x00, CSIPHY_DEFAULT_PARAMS},
> + {0x0C00, 0x8C, 0x00, CSIPHY_DEFAULT_PARAMS},
> + {0x0C38, 0xFE, 0x00, CSIPHY_DEFAULT_PARAMS},
> + {0x0C2C, 0x01, 0x00, CSIPHY_DEFAULT_PARAMS},
> + {0x0C34, 0x0F, 0x00, CSIPHY_DEFAULT_PARAMS},
> + {0x0C1C, 0x0A, 0x00, CSIPHY_DEFAULT_PARAMS},
> + {0x0C14, 0x60, 0x00, CSIPHY_DEFAULT_PARAMS},
> + {0x0C3C, 0xB8, 0x00, CSIPHY_DEFAULT_PARAMS},
> + {0x0C04, 0x0C, 0x00, CSIPHY_DEFAULT_PARAMS},
> + {0x0C20, 0x00, 0x00, CSIPHY_DEFAULT_PARAMS},
> + {0x0C08, 0x19, 0x00, CSIPHY_SETTLE_CNT_LOWER_BYTE},
> + {0x0C10, 0x52, 0x00, CSIPHY_DEFAULT_PARAMS},
> + {0x0C94, 0xD7, 0x00, CSIPHY_SKEW_CAL},
> + {0x0C5C, 0x54, 0x00, CSIPHY_SKEW_CAL},
> + {0x0C60, 0xFD, 0x00, CSIPHY_SKEW_CAL},
> + {0x0C64, 0x7F, 0x00, CSIPHY_SKEW_CAL},
> +
> + /* LN CLK */
> + {0x0E94, 0x00, 0x00, CSIPHY_DEFAULT_PARAMS},
> + {0x0EA0, 0x00, 0x00, CSIPHY_DEFAULT_PARAMS},
> + {0x0E90, 0x0F, 0x00, CSIPHY_DEFAULT_PARAMS},
> + {0x0E98, 0x08, 0x00, CSIPHY_DEFAULT_PARAMS},
> + {0x0E94, 0x07, 0xd1, CSIPHY_DEFAULT_PARAMS},
> + {0x0E30, 0x00, 0x00, CSIPHY_DEFAULT_PARAMS},
> + {0x0E28, 0x04, 0x00, CSIPHY_DEFAULT_PARAMS},
> + {0x0E00, 0x80, 0x00, CSIPHY_DEFAULT_PARAMS},
> + {0x0E0C, 0xFF, 0x00, CSIPHY_DEFAULT_PARAMS},
> + {0x0E38, 0x1F, 0x00, CSIPHY_DEFAULT_PARAMS},
> + {0x0E2C, 0x01, 0x00, CSIPHY_DEFAULT_PARAMS},
> + {0x0E34, 0x0F, 0x00, CSIPHY_DEFAULT_PARAMS},
> + {0x0E1C, 0x0A, 0x00, CSIPHY_DEFAULT_PARAMS},
> + {0x0E14, 0x60, 0x00, CSIPHY_DEFAULT_PARAMS},
> + {0x0E3C, 0xB8, 0x00, CSIPHY_DEFAULT_PARAMS},
> + {0x0E04, 0x0C, 0x00, CSIPHY_DEFAULT_PARAMS},
> + {0x0E20, 0x00, 0x00, CSIPHY_DEFAULT_PARAMS},
> + {0x0E08, 0x19, 0x00, CSIPHY_SETTLE_CNT_LOWER_BYTE},
> + {0x0E10, 0x52, 0x00, CSIPHY_DEFAULT_PARAMS},
> +};
> +
> /* 4nm 2PH v 2.1.2 2p5Gbps 4 lane DPHY mode */
> static const struct
> csiphy_lane_regs lane_regs_x1e80100[] = {
> @@ -714,13 +832,21 @@ static void csiphy_hw_version_read(struct csiphy_device *csiphy,
> CSIPHY_3PH_CMN_CSI_COMMON_CTRLn(regs->offset, 6));
>
> hw_version = readl_relaxed(csiphy->base +
> - CSIPHY_3PH_CMN_CSI_COMMON_STATUSn(regs->offset, 12));
> + CSIPHY_3PH_CMN_CSI_COMMON_STATUSn(
> + regs->offset,
> + regs->common_status_offset, 12));
> hw_version |= readl_relaxed(csiphy->base +
> - CSIPHY_3PH_CMN_CSI_COMMON_STATUSn(regs->offset, 13)) << 8;
> + CSIPHY_3PH_CMN_CSI_COMMON_STATUSn(
> + regs->offset,
> + regs->common_status_offset, 13)) << 8;
> hw_version |= readl_relaxed(csiphy->base +
> - CSIPHY_3PH_CMN_CSI_COMMON_STATUSn(regs->offset, 14)) << 16;
> + CSIPHY_3PH_CMN_CSI_COMMON_STATUSn(
> + regs->offset,
> + regs->common_status_offset, 14)) << 16;
> hw_version |= readl_relaxed(csiphy->base +
> - CSIPHY_3PH_CMN_CSI_COMMON_STATUSn(regs->offset, 15)) << 24;
> + CSIPHY_3PH_CMN_CSI_COMMON_STATUSn(
> + regs->offset,
> + regs->common_status_offset, 15)) << 24;
This change should be separated from the addition of the PHY init
sequence into its own patch so we can arbitrate that patch standalone on
its merits.
I have questions like "why do this" and "how does this affect other
hardware" which a commit log for a change like this should spell out.
>
> dev_dbg(dev, "CSIPHY 3PH HW Version = 0x%08x\n", hw_version);
> }
> @@ -749,7 +875,8 @@ static irqreturn_t csiphy_isr(int irq, void *dev)
> for (i = 0; i < 11; i++) {
> int c = i + 22;
> u8 val = readl_relaxed(csiphy->base +
> - CSIPHY_3PH_CMN_CSI_COMMON_STATUSn(regs->offset, i));
> + CSIPHY_3PH_CMN_CSI_COMMON_STATUSn(regs->offset,
> + regs->common_status_offset, i));
>
> writel_relaxed(val, csiphy->base +
> CSIPHY_3PH_CMN_CSI_COMMON_CTRLn(regs->offset, c));
> @@ -915,6 +1042,7 @@ static bool csiphy_is_gen2(u32 version)
> case CAMSS_845:
> case CAMSS_8550:
> case CAMSS_8775P:
> + case CAMSS_KAANAPALI:
> case CAMSS_X1E80100:
> ret = true;
> break;
> @@ -989,6 +1117,7 @@ static int csiphy_init(struct csiphy_device *csiphy)
>
> csiphy->regs = regs;
> regs->offset = 0x800;
> + regs->common_status_offset = 0xb0;
>
> switch (csiphy->camss->res->version) {
> case CAMSS_845:
> @@ -1023,6 +1152,12 @@ static int csiphy_init(struct csiphy_device *csiphy)
> regs->lane_regs = &lane_regs_sa8775p[0];
> regs->lane_array_size = ARRAY_SIZE(lane_regs_sa8775p);
> break;
> + case CAMSS_KAANAPALI:
> + regs->lane_regs = &lane_regs_kaanapali[0];
> + regs->lane_array_size = ARRAY_SIZE(lane_regs_kaanapali);
> + regs->offset = 0x1000;
> + regs->common_status_offset = 0x138;
> + break;
> default:
> break;
> }
> diff --git a/drivers/media/platform/qcom/camss/camss-csiphy.h b/drivers/media/platform/qcom/camss/camss-csiphy.h
> index 895f80003c44..2d5054819df7 100644
> --- a/drivers/media/platform/qcom/camss/camss-csiphy.h
> +++ b/drivers/media/platform/qcom/camss/camss-csiphy.h
> @@ -90,6 +90,7 @@ struct csiphy_device_regs {
> const struct csiphy_lane_regs *lane_regs;
> int lane_array_size;
> u32 offset;
> + u32 common_status_offset;
> };
>
> struct csiphy_device {
> diff --git a/drivers/media/platform/qcom/camss/camss.c b/drivers/media/platform/qcom/camss/camss.c
> index 4a5caf54c116..542122fba825 100644
> --- a/drivers/media/platform/qcom/camss/camss.c
> +++ b/drivers/media/platform/qcom/camss/camss.c
> @@ -34,6 +34,111 @@
>
> static const struct parent_dev_ops vfe_parent_dev_ops;
>
> +static const struct camss_subdev_resources csiphy_res_kaanapali[] = {
> + /* CSIPHY0 */
> + {
> + .regulators = { "vdda-phy0", "vdda-pll" },
> + .clock = { "csiphy0", "csiphy0_timer",
> + "cam_top_ahb", "cam_top_fast_ahb" },
> + .clock_rate = { { 400000000, 480000000 },
> + { 400000000 },
> + { 0 },
> + { 0 } },
> + .reg = { "csiphy0" },
> + .interrupt = { "csiphy0" },
> + .csiphy = {
> + .id = 0,
> + .hw_ops = &csiphy_ops_3ph_1_0,
> + .formats = &csiphy_formats_sdm845
> + }
> + },
> + /* CSIPHY1 */
> + {
> + .regulators = { "vdda-phy1", "vdda-pll" },
> + .clock = { "csiphy1", "csiphy1_timer",
> + "cam_top_ahb", "cam_top_fast_ahb" },
> + .clock_rate = { { 400000000, 480000000 },
> + { 400000000 },
> + { 0 },
> + { 0 } },
> + .reg = { "csiphy1" },
> + .interrupt = { "csiphy1" },
> + .csiphy = {
> + .id = 1,
> + .hw_ops = &csiphy_ops_3ph_1_0,
> + .formats = &csiphy_formats_sdm845
> + }
> + },
> + /* CSIPHY2 */
> + {
> + .regulators = { "vdda-phy2", "vdda-pll" },
> + .clock = { "csiphy2", "csiphy2_timer",
> + "cam_top_ahb", "cam_top_fast_ahb" },
> + .clock_rate = { { 400000000, 480000000 },
> + { 400000000 },
> + { 0 },
> + { 0 } },
> + .reg = { "csiphy2" },
> + .interrupt = { "csiphy2" },
> + .csiphy = {
> + .id = 2,
> + .hw_ops = &csiphy_ops_3ph_1_0,
> + .formats = &csiphy_formats_sdm845
> + }
> + },
> + /* CSIPHY3 */
> + {
> + .regulators = { "vdda-phy3", "vdda-pll" },
> + .clock = { "csiphy3", "csiphy3_timer",
> + "cam_top_ahb", "cam_top_fast_ahb" },
> + .clock_rate = { { 400000000, 480000000 },
> + { 400000000 },
> + { 0 },
> + { 0 } },
> + .reg = { "csiphy3" },
> + .interrupt = { "csiphy3" },
> + .csiphy = {
> + .id = 3,
> + .hw_ops = &csiphy_ops_3ph_1_0,
> + .formats = &csiphy_formats_sdm845
> + }
> + },
> + /* CSIPHY4 */
> + {
> + .regulators = { "vdda-phy4", "vdda-pll" },
> + .clock = { "csiphy4", "csiphy4_timer",
> + "cam_top_ahb", "cam_top_fast_ahb" },
> + .clock_rate = { { 400000000, 480000000 },
> + { 400000000 },
> + { 0 },
> + { 0 } },
> + .reg = { "csiphy4" },
> + .interrupt = { "csiphy4" },
> + .csiphy = {
> + .id = 4,
> + .hw_ops = &csiphy_ops_3ph_1_0,
> + .formats = &csiphy_formats_sdm845
> + }
> + },
> + /* CSIPHY5 */
> + {
> + .regulators = { "vdda-phy5", "vdda-pll" },
> + .clock = { "csiphy5", "csiphy5_timer",
> + "cam_top_ahb", "cam_top_fast_ahb" },
> + .clock_rate = { { 400000000, 480000000 },
> + { 400000000 },
> + { 0 },
> + { 0 } },
> + .reg = { "csiphy5" },
> + .interrupt = { "csiphy5" },
> + .csiphy = {
> + .id = 5,
> + .hw_ops = &csiphy_ops_3ph_1_0,
> + .formats = &csiphy_formats_sdm845
> + }
> + },
> +};
> +
> static const struct resources_icc icc_res_kaanapali[] = {
> /* Based on 4096 x 3072 30 FPS 2496 Mbps mode */
> {
> @@ -4308,8 +4413,10 @@ static void camss_remove(struct platform_device *pdev)
> static const struct camss_resources kaanapali_resources = {
> .version = CAMSS_KAANAPALI,
> .pd_name = "top",
> + .csiphy_res = csiphy_res_kaanapali,
> .icc_res = icc_res_kaanapali,
> .icc_path_num = ARRAY_SIZE(icc_res_kaanapali),
> + .csiphy_num = ARRAY_SIZE(csiphy_res_kaanapali),
> };
>
> static const struct camss_resources msm8916_resources = {
>
^ permalink raw reply [flat|nested] 46+ messages in thread* Re: [PATCH v2 4/6] media: qcom: camss: csiphy: Add support for v2.4.0 two-phase CSIPHY
2025-10-16 8:59 ` Bryan O'Donoghue
@ 2025-10-16 23:10 ` Vijay Kumar Tumati
2025-10-17 10:55 ` Bryan O'Donoghue
0 siblings, 1 reply; 46+ messages in thread
From: Vijay Kumar Tumati @ 2025-10-16 23:10 UTC (permalink / raw)
To: Bryan O'Donoghue, Hangxiang Ma, Loic Poulain, Robert Foss,
Andi Shyti, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Todor Tomov, Vladimir Zapolskiy, Mauro Carvalho Chehab
Cc: linux-i2c, linux-arm-msm, devicetree, linux-kernel, linux-media,
aiqun.yu, tingwei.zhang, trilok.soni, yijie.yang, Jingyi Wang,
Atiya Kailany
On 10/16/2025 1:59 AM, Bryan O'Donoghue wrote:
> On 15/10/2025 03:56, Hangxiang Ma wrote:
>> Add more detailed resource information for CSIPHY devices in the camss
>> driver along with the support for v2.4.0 in the 2 phase CSIPHY driver
>> that is responsible for the PHY lane register configuration, module
>> reset and interrupt handling.
>>
>> Add 'common_status_offset' variable in 'csidphy_device_regs' structure,
>> which accommodates the offset between common registers and status
>> registers. Because this specific offset in Kaanapali registers differs
>> from other versions.
>>
>> Signed-off-by: Hangxiang Ma <hangxiang.ma@oss.qualcomm.com>
>> ---
>> .../platform/qcom/camss/camss-csiphy-3ph-1-0.c | 147
>> ++++++++++++++++++++-
>> drivers/media/platform/qcom/camss/camss-csiphy.h | 1 +
>> drivers/media/platform/qcom/camss/camss.c | 107
>> +++++++++++++++
>> 3 files changed, 249 insertions(+), 6 deletions(-)
>>
>> diff --git a/drivers/media/platform/qcom/camss/camss-csiphy-3ph-1-0.c
>> b/drivers/media/platform/qcom/camss/camss-csiphy-3ph-1-0.c
>> index a229ba04b158..192636d02b32 100644
>> --- a/drivers/media/platform/qcom/camss/camss-csiphy-3ph-1-0.c
>> +++ b/drivers/media/platform/qcom/camss/camss-csiphy-3ph-1-0.c
>> @@ -46,7 +46,8 @@
>> #define CSIPHY_3PH_CMN_CSI_COMMON_CTRL5_CLK_ENABLE BIT(7)
>> #define CSIPHY_3PH_CMN_CSI_COMMON_CTRL6_COMMON_PWRDN_B BIT(0)
>> #define CSIPHY_3PH_CMN_CSI_COMMON_CTRL6_SHOW_REV_ID BIT(1)
>> -#define CSIPHY_3PH_CMN_CSI_COMMON_STATUSn(offset, n) ((offset) +
>> 0xb0 + 0x4 * (n))
>> +#define CSIPHY_3PH_CMN_CSI_COMMON_STATUSn(offset,
>> common_status_offset, n) \
>> + ((offset) + (common_status_offset) + 0x4 * (n))
>> #define CSIPHY_DEFAULT_PARAMS 0
>> #define CSIPHY_LANE_ENABLE 1
>> @@ -587,6 +588,123 @@ csiphy_lane_regs lane_regs_sm8550[] = {
>> {0x0C64, 0x7F, 0x00, CSIPHY_DEFAULT_PARAMS},
>> };
>> +/* 3nm 2PH v 2.4.0 2p5Gbps 4 lane DPHY mode */
>
> I'll again ask for a declaration of the process node this PHY sequence
> is fabbed on.
>
@Bryan, sorry, is this something other than "/* 3nm 2PH v 2.4.0 2p5Gbps
4 lane DPHY mode */" ?
>> +static const struct
>> +csiphy_lane_regs lane_regs_kaanapali[] = {
>> + /* LN 0 */
>> + {0x0094, 0x00, 0x00, CSIPHY_DEFAULT_PARAMS},
>> + {0x00A0, 0x00, 0x00, CSIPHY_DEFAULT_PARAMS},
>> + {0x0090, 0x0F, 0x00, CSIPHY_DEFAULT_PARAMS},
>> + {0x0098, 0x08, 0x00, CSIPHY_DEFAULT_PARAMS},
>> + {0x0094, 0x07, 0xd1, CSIPHY_DEFAULT_PARAMS},
>> + {0x0030, 0x00, 0x00, CSIPHY_DEFAULT_PARAMS},
>> + {0x0000, 0x8C, 0x00, CSIPHY_DEFAULT_PARAMS},
>> + {0x0038, 0xFE, 0x00, CSIPHY_DEFAULT_PARAMS},
>> + {0x002C, 0x01, 0x00, CSIPHY_DEFAULT_PARAMS},
>> + {0x0034, 0x0F, 0x00, CSIPHY_DEFAULT_PARAMS},
>> + {0x001C, 0x0A, 0x00, CSIPHY_DEFAULT_PARAMS},
>> + {0x0014, 0x60, 0x00, CSIPHY_DEFAULT_PARAMS},
>> + {0x003C, 0xB8, 0x00, CSIPHY_DEFAULT_PARAMS},
>> + {0x0004, 0x0C, 0x00, CSIPHY_DEFAULT_PARAMS},
>> + {0x0020, 0x00, 0x00, CSIPHY_DEFAULT_PARAMS},
>> + {0x0008, 0x19, 0x00, CSIPHY_SETTLE_CNT_LOWER_BYTE},
>> + {0x0010, 0x52, 0x00, CSIPHY_DEFAULT_PARAMS},
>> + {0x0094, 0xD7, 0x00, CSIPHY_SKEW_CAL},
>> + {0x005C, 0x54, 0x00, CSIPHY_SKEW_CAL},
>> + {0x0060, 0xFD, 0x00, CSIPHY_SKEW_CAL},
>> + {0x0064, 0x7F, 0x00, CSIPHY_SKEW_CAL},
>> +
>> + /* LN 2 */
>> + {0x0494, 0x00, 0x00, CSIPHY_DEFAULT_PARAMS},
>> + {0x04A0, 0x00, 0x00, CSIPHY_DEFAULT_PARAMS},
>> + {0x0490, 0x0F, 0x00, CSIPHY_DEFAULT_PARAMS},
>> + {0x0498, 0x08, 0x00, CSIPHY_DEFAULT_PARAMS},
>> + {0x0494, 0x07, 0xd1, CSIPHY_DEFAULT_PARAMS},
>> + {0x0430, 0x00, 0x00, CSIPHY_DEFAULT_PARAMS},
>> + {0x0400, 0x8C, 0x00, CSIPHY_DEFAULT_PARAMS},
>> + {0x0438, 0xFE, 0x00, CSIPHY_DEFAULT_PARAMS},
>> + {0x042C, 0x01, 0x00, CSIPHY_DEFAULT_PARAMS},
>> + {0x0434, 0x0F, 0x00, CSIPHY_DEFAULT_PARAMS},
>> + {0x041C, 0x0A, 0x00, CSIPHY_DEFAULT_PARAMS},
>> + {0x0414, 0x60, 0x00, CSIPHY_DEFAULT_PARAMS},
>> + {0x043C, 0xB8, 0x00, CSIPHY_DEFAULT_PARAMS},
>> + {0x0404, 0x0C, 0x00, CSIPHY_DEFAULT_PARAMS},
>> + {0x0420, 0x00, 0x00, CSIPHY_DEFAULT_PARAMS},
>> + {0x0408, 0x19, 0x00, CSIPHY_SETTLE_CNT_LOWER_BYTE},
>> + {0x0410, 0x52, 0x00, CSIPHY_DEFAULT_PARAMS},
>> + {0x0494, 0xD7, 0x00, CSIPHY_SKEW_CAL},
>> + {0x045C, 0x54, 0x00, CSIPHY_SKEW_CAL},
>> + {0x0460, 0xFD, 0x00, CSIPHY_SKEW_CAL},
>> + {0x0464, 0x7F, 0x00, CSIPHY_SKEW_CAL},
>> +
>> + /* LN 4 */
>> + {0x0894, 0x00, 0x00, CSIPHY_DEFAULT_PARAMS},
>> + {0x08A0, 0x00, 0x00, CSIPHY_DEFAULT_PARAMS},
>> + {0x0890, 0x0F, 0x00, CSIPHY_DEFAULT_PARAMS},
>> + {0x0898, 0x08, 0x00, CSIPHY_DEFAULT_PARAMS},
>> + {0x0894, 0x07, 0xd1, CSIPHY_DEFAULT_PARAMS},
>> + {0x0830, 0x00, 0x00, CSIPHY_DEFAULT_PARAMS},
>> + {0x0800, 0x8C, 0x00, CSIPHY_DEFAULT_PARAMS},
>> + {0x0838, 0xFE, 0x00, CSIPHY_DEFAULT_PARAMS},
>> + {0x082C, 0x01, 0x00, CSIPHY_DEFAULT_PARAMS},
>> + {0x0834, 0x0F, 0x00, CSIPHY_DEFAULT_PARAMS},
>> + {0x081C, 0x0A, 0x00, CSIPHY_DEFAULT_PARAMS},
>> + {0x0814, 0x60, 0x00, CSIPHY_DEFAULT_PARAMS},
>> + {0x083C, 0xB8, 0x00, CSIPHY_DEFAULT_PARAMS},
>> + {0x0804, 0x0C, 0x00, CSIPHY_DEFAULT_PARAMS},
>> + {0x0820, 0x00, 0x00, CSIPHY_DEFAULT_PARAMS},
>> + {0x0808, 0x19, 0x00, CSIPHY_SETTLE_CNT_LOWER_BYTE},
>> + {0x0810, 0x52, 0x00, CSIPHY_DEFAULT_PARAMS},
>> + {0x0894, 0xD7, 0x00, CSIPHY_SKEW_CAL},
>> + {0x085C, 0x54, 0x00, CSIPHY_SKEW_CAL},
>> + {0x0860, 0xFD, 0x00, CSIPHY_SKEW_CAL},
>> + {0x0864, 0x7F, 0x00, CSIPHY_SKEW_CAL},
>> +
>> + /* LN 6 */
>> + {0x0C94, 0x00, 0x00, CSIPHY_DEFAULT_PARAMS},
>> + {0x0CA0, 0x00, 0x00, CSIPHY_DEFAULT_PARAMS},
>> + {0x0C90, 0x0F, 0x00, CSIPHY_DEFAULT_PARAMS},
>> + {0x0C98, 0x08, 0x00, CSIPHY_DEFAULT_PARAMS},
>> + {0x0C94, 0x07, 0xd1, CSIPHY_DEFAULT_PARAMS},
>> + {0x0C30, 0x00, 0x00, CSIPHY_DEFAULT_PARAMS},
>> + {0x0C00, 0x8C, 0x00, CSIPHY_DEFAULT_PARAMS},
>> + {0x0C38, 0xFE, 0x00, CSIPHY_DEFAULT_PARAMS},
>> + {0x0C2C, 0x01, 0x00, CSIPHY_DEFAULT_PARAMS},
>> + {0x0C34, 0x0F, 0x00, CSIPHY_DEFAULT_PARAMS},
>> + {0x0C1C, 0x0A, 0x00, CSIPHY_DEFAULT_PARAMS},
>> + {0x0C14, 0x60, 0x00, CSIPHY_DEFAULT_PARAMS},
>> + {0x0C3C, 0xB8, 0x00, CSIPHY_DEFAULT_PARAMS},
>> + {0x0C04, 0x0C, 0x00, CSIPHY_DEFAULT_PARAMS},
>> + {0x0C20, 0x00, 0x00, CSIPHY_DEFAULT_PARAMS},
>> + {0x0C08, 0x19, 0x00, CSIPHY_SETTLE_CNT_LOWER_BYTE},
>> + {0x0C10, 0x52, 0x00, CSIPHY_DEFAULT_PARAMS},
>> + {0x0C94, 0xD7, 0x00, CSIPHY_SKEW_CAL},
>> + {0x0C5C, 0x54, 0x00, CSIPHY_SKEW_CAL},
>> + {0x0C60, 0xFD, 0x00, CSIPHY_SKEW_CAL},
>> + {0x0C64, 0x7F, 0x00, CSIPHY_SKEW_CAL},
>> +
>> + /* LN CLK */
>> + {0x0E94, 0x00, 0x00, CSIPHY_DEFAULT_PARAMS},
>> + {0x0EA0, 0x00, 0x00, CSIPHY_DEFAULT_PARAMS},
>> + {0x0E90, 0x0F, 0x00, CSIPHY_DEFAULT_PARAMS},
>> + {0x0E98, 0x08, 0x00, CSIPHY_DEFAULT_PARAMS},
>> + {0x0E94, 0x07, 0xd1, CSIPHY_DEFAULT_PARAMS},
>> + {0x0E30, 0x00, 0x00, CSIPHY_DEFAULT_PARAMS},
>> + {0x0E28, 0x04, 0x00, CSIPHY_DEFAULT_PARAMS},
>> + {0x0E00, 0x80, 0x00, CSIPHY_DEFAULT_PARAMS},
>> + {0x0E0C, 0xFF, 0x00, CSIPHY_DEFAULT_PARAMS},
>> + {0x0E38, 0x1F, 0x00, CSIPHY_DEFAULT_PARAMS},
>> + {0x0E2C, 0x01, 0x00, CSIPHY_DEFAULT_PARAMS},
>> + {0x0E34, 0x0F, 0x00, CSIPHY_DEFAULT_PARAMS},
>> + {0x0E1C, 0x0A, 0x00, CSIPHY_DEFAULT_PARAMS},
>> + {0x0E14, 0x60, 0x00, CSIPHY_DEFAULT_PARAMS},
>> + {0x0E3C, 0xB8, 0x00, CSIPHY_DEFAULT_PARAMS},
>> + {0x0E04, 0x0C, 0x00, CSIPHY_DEFAULT_PARAMS},
>> + {0x0E20, 0x00, 0x00, CSIPHY_DEFAULT_PARAMS},
>> + {0x0E08, 0x19, 0x00, CSIPHY_SETTLE_CNT_LOWER_BYTE},
>> + {0x0E10, 0x52, 0x00, CSIPHY_DEFAULT_PARAMS},
>> +};
>> +
>> /* 4nm 2PH v 2.1.2 2p5Gbps 4 lane DPHY mode */
>> static const struct
>> csiphy_lane_regs lane_regs_x1e80100[] = {
>> @@ -714,13 +832,21 @@ static void csiphy_hw_version_read(struct
>> csiphy_device *csiphy,
>> CSIPHY_3PH_CMN_CSI_COMMON_CTRLn(regs->offset, 6));
>> hw_version = readl_relaxed(csiphy->base +
>> - CSIPHY_3PH_CMN_CSI_COMMON_STATUSn(regs->offset, 12));
>> + CSIPHY_3PH_CMN_CSI_COMMON_STATUSn(
>> + regs->offset,
>> + regs->common_status_offset, 12));
>> hw_version |= readl_relaxed(csiphy->base +
>> - CSIPHY_3PH_CMN_CSI_COMMON_STATUSn(regs->offset, 13)) << 8;
>> + CSIPHY_3PH_CMN_CSI_COMMON_STATUSn(
>> + regs->offset,
>> + regs->common_status_offset, 13)) << 8;
>> hw_version |= readl_relaxed(csiphy->base +
>> - CSIPHY_3PH_CMN_CSI_COMMON_STATUSn(regs->offset, 14)) << 16;
>> + CSIPHY_3PH_CMN_CSI_COMMON_STATUSn(
>> + regs->offset,
>> + regs->common_status_offset, 14)) << 16;
>> hw_version |= readl_relaxed(csiphy->base +
>> - CSIPHY_3PH_CMN_CSI_COMMON_STATUSn(regs->offset, 15)) << 24;
>> + CSIPHY_3PH_CMN_CSI_COMMON_STATUSn(
>> + regs->offset,
>> + regs->common_status_offset, 15)) << 24;
>
> This change should be separated from the addition of the PHY init
> sequence into its own patch so we can arbitrate that patch standalone
> on its merits.
>
> I have questions like "why do this" and "how does this affect other
> hardware" which a commit log for a change like this should spell out.
There are three offsets in the picture here wrt the CSIPHY instance base
address
1. First offset to the common registers of the PHY, 'regs->offset' (that
follows the lane registers)
2. Second offset to the status registers within the common registers .
This has been historically the same and hard coded
in 'CSIPHY_3PH_CMN_CSI_COMMON_STATUSn' to 0xb0 but this is now changing
on Kaanapali.
3. Third set of offsets (12, 13, 14 and 15) are to the version registers
within the status registers.
This change merely generalizes the CSIPHY_3PH_CMN_CSI_COMMON_STATUSn
macro for chip sets with different second offset using
"regs->common_status_offset". There should not be any impact to the
other chip sets, for which it is set to the same 0xb0 in csiphy_init().
Please advise if you still think it requires a patch series for itself
and we can do that. Thanks.
>
>> dev_dbg(dev, "CSIPHY 3PH HW Version = 0x%08x\n", hw_version);
>> }
>> @@ -749,7 +875,8 @@ static irqreturn_t csiphy_isr(int irq, void *dev)
>> for (i = 0; i < 11; i++) {
>> int c = i + 22;
>> u8 val = readl_relaxed(csiphy->base +
>> - CSIPHY_3PH_CMN_CSI_COMMON_STATUSn(regs->offset, i));
>> + CSIPHY_3PH_CMN_CSI_COMMON_STATUSn(regs->offset,
>> + regs->common_status_offset, i));
>> writel_relaxed(val, csiphy->base +
>> CSIPHY_3PH_CMN_CSI_COMMON_CTRLn(regs->offset, c));
>> @@ -915,6 +1042,7 @@ static bool csiphy_is_gen2(u32 version)
>> case CAMSS_845:
>> case CAMSS_8550:
>> case CAMSS_8775P:
>> + case CAMSS_KAANAPALI:
>> case CAMSS_X1E80100:
>> ret = true;
>> break;
>> @@ -989,6 +1117,7 @@ static int csiphy_init(struct csiphy_device
>> *csiphy)
>> csiphy->regs = regs;
>> regs->offset = 0x800;
>> + regs->common_status_offset = 0xb0;
>> switch (csiphy->camss->res->version) {
>> case CAMSS_845:
>> @@ -1023,6 +1152,12 @@ static int csiphy_init(struct csiphy_device
>> *csiphy)
>> regs->lane_regs = &lane_regs_sa8775p[0];
>> regs->lane_array_size = ARRAY_SIZE(lane_regs_sa8775p);
>> break;
>> + case CAMSS_KAANAPALI:
>> + regs->lane_regs = &lane_regs_kaanapali[0];
>> + regs->lane_array_size = ARRAY_SIZE(lane_regs_kaanapali);
>> + regs->offset = 0x1000;
>> + regs->common_status_offset = 0x138;
>> + break;
>> default:
>> break;
>> }
>> diff --git a/drivers/media/platform/qcom/camss/camss-csiphy.h
>> b/drivers/media/platform/qcom/camss/camss-csiphy.h
>> index 895f80003c44..2d5054819df7 100644
>> --- a/drivers/media/platform/qcom/camss/camss-csiphy.h
>> +++ b/drivers/media/platform/qcom/camss/camss-csiphy.h
>> @@ -90,6 +90,7 @@ struct csiphy_device_regs {
>> const struct csiphy_lane_regs *lane_regs;
>> int lane_array_size;
>> u32 offset;
>> + u32 common_status_offset;
>> };
>> struct csiphy_device {
>> diff --git a/drivers/media/platform/qcom/camss/camss.c
>> b/drivers/media/platform/qcom/camss/camss.c
>> index 4a5caf54c116..542122fba825 100644
>> --- a/drivers/media/platform/qcom/camss/camss.c
>> +++ b/drivers/media/platform/qcom/camss/camss.c
>> @@ -34,6 +34,111 @@
>> static const struct parent_dev_ops vfe_parent_dev_ops;
>> +static const struct camss_subdev_resources csiphy_res_kaanapali[] = {
>> + /* CSIPHY0 */
>> + {
>> + .regulators = { "vdda-phy0", "vdda-pll" },
>> + .clock = { "csiphy0", "csiphy0_timer",
>> + "cam_top_ahb", "cam_top_fast_ahb" },
>> + .clock_rate = { { 400000000, 480000000 },
>> + { 400000000 },
>> + { 0 },
>> + { 0 } },
>> + .reg = { "csiphy0" },
>> + .interrupt = { "csiphy0" },
>> + .csiphy = {
>> + .id = 0,
>> + .hw_ops = &csiphy_ops_3ph_1_0,
>> + .formats = &csiphy_formats_sdm845
>> + }
>> + },
>> + /* CSIPHY1 */
>> + {
>> + .regulators = { "vdda-phy1", "vdda-pll" },
>> + .clock = { "csiphy1", "csiphy1_timer",
>> + "cam_top_ahb", "cam_top_fast_ahb" },
>> + .clock_rate = { { 400000000, 480000000 },
>> + { 400000000 },
>> + { 0 },
>> + { 0 } },
>> + .reg = { "csiphy1" },
>> + .interrupt = { "csiphy1" },
>> + .csiphy = {
>> + .id = 1,
>> + .hw_ops = &csiphy_ops_3ph_1_0,
>> + .formats = &csiphy_formats_sdm845
>> + }
>> + },
>> + /* CSIPHY2 */
>> + {
>> + .regulators = { "vdda-phy2", "vdda-pll" },
>> + .clock = { "csiphy2", "csiphy2_timer",
>> + "cam_top_ahb", "cam_top_fast_ahb" },
>> + .clock_rate = { { 400000000, 480000000 },
>> + { 400000000 },
>> + { 0 },
>> + { 0 } },
>> + .reg = { "csiphy2" },
>> + .interrupt = { "csiphy2" },
>> + .csiphy = {
>> + .id = 2,
>> + .hw_ops = &csiphy_ops_3ph_1_0,
>> + .formats = &csiphy_formats_sdm845
>> + }
>> + },
>> + /* CSIPHY3 */
>> + {
>> + .regulators = { "vdda-phy3", "vdda-pll" },
>> + .clock = { "csiphy3", "csiphy3_timer",
>> + "cam_top_ahb", "cam_top_fast_ahb" },
>> + .clock_rate = { { 400000000, 480000000 },
>> + { 400000000 },
>> + { 0 },
>> + { 0 } },
>> + .reg = { "csiphy3" },
>> + .interrupt = { "csiphy3" },
>> + .csiphy = {
>> + .id = 3,
>> + .hw_ops = &csiphy_ops_3ph_1_0,
>> + .formats = &csiphy_formats_sdm845
>> + }
>> + },
>> + /* CSIPHY4 */
>> + {
>> + .regulators = { "vdda-phy4", "vdda-pll" },
>> + .clock = { "csiphy4", "csiphy4_timer",
>> + "cam_top_ahb", "cam_top_fast_ahb" },
>> + .clock_rate = { { 400000000, 480000000 },
>> + { 400000000 },
>> + { 0 },
>> + { 0 } },
>> + .reg = { "csiphy4" },
>> + .interrupt = { "csiphy4" },
>> + .csiphy = {
>> + .id = 4,
>> + .hw_ops = &csiphy_ops_3ph_1_0,
>> + .formats = &csiphy_formats_sdm845
>> + }
>> + },
>> + /* CSIPHY5 */
>> + {
>> + .regulators = { "vdda-phy5", "vdda-pll" },
>> + .clock = { "csiphy5", "csiphy5_timer",
>> + "cam_top_ahb", "cam_top_fast_ahb" },
>> + .clock_rate = { { 400000000, 480000000 },
>> + { 400000000 },
>> + { 0 },
>> + { 0 } },
>> + .reg = { "csiphy5" },
>> + .interrupt = { "csiphy5" },
>> + .csiphy = {
>> + .id = 5,
>> + .hw_ops = &csiphy_ops_3ph_1_0,
>> + .formats = &csiphy_formats_sdm845
>> + }
>> + },
>> +};
>> +
>> static const struct resources_icc icc_res_kaanapali[] = {
>> /* Based on 4096 x 3072 30 FPS 2496 Mbps mode */
>> {
>> @@ -4308,8 +4413,10 @@ static void camss_remove(struct
>> platform_device *pdev)
>> static const struct camss_resources kaanapali_resources = {
>> .version = CAMSS_KAANAPALI,
>> .pd_name = "top",
>> + .csiphy_res = csiphy_res_kaanapali,
>> .icc_res = icc_res_kaanapali,
>> .icc_path_num = ARRAY_SIZE(icc_res_kaanapali),
>> + .csiphy_num = ARRAY_SIZE(csiphy_res_kaanapali),
>> };
>> static const struct camss_resources msm8916_resources = {
>>
>
>
^ permalink raw reply [flat|nested] 46+ messages in thread* Re: [PATCH v2 4/6] media: qcom: camss: csiphy: Add support for v2.4.0 two-phase CSIPHY
2025-10-16 23:10 ` Vijay Kumar Tumati
@ 2025-10-17 10:55 ` Bryan O'Donoghue
0 siblings, 0 replies; 46+ messages in thread
From: Bryan O'Donoghue @ 2025-10-17 10:55 UTC (permalink / raw)
To: Vijay Kumar Tumati, Hangxiang Ma, Loic Poulain, Robert Foss,
Andi Shyti, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Todor Tomov, Vladimir Zapolskiy, Mauro Carvalho Chehab
Cc: linux-i2c, linux-arm-msm, devicetree, linux-kernel, linux-media,
aiqun.yu, tingwei.zhang, trilok.soni, yijie.yang, Jingyi Wang,
Atiya Kailany
On 17/10/2025 00:10, Vijay Kumar Tumati wrote:
>
> There are three offsets in the picture here wrt the CSIPHY instance base
> address
>
> 1. First offset to the common registers of the PHY, 'regs->offset' (that
> follows the lane registers)
>
> 2. Second offset to the status registers within the common registers .
> This has been historically the same and hard coded
> in 'CSIPHY_3PH_CMN_CSI_COMMON_STATUSn' to 0xb0 but this is now changing
> on Kaanapali.
>
> 3. Third set of offsets (12, 13, 14 and 15) are to the version registers
> within the status registers.
>
> This change merely generalizes the CSIPHY_3PH_CMN_CSI_COMMON_STATUSn
> macro for chip sets with different second offset using "regs-
> >common_status_offset". There should not be any impact to the other
> chip sets, for which it is set to the same 0xb0 in csiphy_init().
>
> Please advise if you still think it requires a patch series for itself
> and we can do that. Thanks.
This should be a separate patch yes.
---
bod
^ permalink raw reply [flat|nested] 46+ messages in thread
* [PATCH v2 5/6] media: qcom: camss: csid: Add support for CSID 1080
2025-10-15 2:56 [PATCH v2 0/6] media: qcom: camss: Add Kaanapali support Hangxiang Ma
` (3 preceding siblings ...)
2025-10-15 2:56 ` [PATCH v2 4/6] media: qcom: camss: csiphy: Add support for v2.4.0 two-phase CSIPHY Hangxiang Ma
@ 2025-10-15 2:56 ` Hangxiang Ma
2025-10-16 9:12 ` Bryan O'Donoghue
2025-10-16 10:04 ` Bryan O'Donoghue
2025-10-15 2:56 ` [PATCH v2 6/6] media: qcom: camss: vfe: Add support for VFE 1080 Hangxiang Ma
5 siblings, 2 replies; 46+ messages in thread
From: Hangxiang Ma @ 2025-10-15 2:56 UTC (permalink / raw)
To: Loic Poulain, Robert Foss, Andi Shyti, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Todor Tomov,
Vladimir Zapolskiy, Mauro Carvalho Chehab, Bryan O'Donoghue
Cc: linux-i2c, linux-arm-msm, devicetree, linux-kernel, linux-media,
aiqun.yu, tingwei.zhang, trilok.soni, yijie.yang, Jingyi Wang,
Atiya Kailany, Hangxiang Ma
Add more detailed resource information for CSID devices along with the
driver for CSID 1080 that is responsible for CSID register
configuration, module reset and IRQ handling for BUF_DONE events. And
aggregate a common definition 'CSI2_RX_CFG0_PHY_SEL_BASE_IDX' into csid
header file.
In this CSID version, RUP and AUP update values are split into two
registers along with a SET register. Accordingly , enhance the CSID
interface to accommodate both the legacy combined reg_update and the
split RUP and AUP updates.
Co-developed-by: Atiya Kailany <atiya.kailany@oss.qualcomm.com>
Signed-off-by: Atiya Kailany <atiya.kailany@oss.qualcomm.com>
Signed-off-by: Hangxiang Ma <hangxiang.ma@oss.qualcomm.com>
---
drivers/media/platform/qcom/camss/Makefile | 1 +
.../media/platform/qcom/camss/camss-csid-1080.c | 371 +++++++++++++++++++++
drivers/media/platform/qcom/camss/camss-csid-680.c | 1 -
.../media/platform/qcom/camss/camss-csid-gen3.c | 1 -
drivers/media/platform/qcom/camss/camss-csid.h | 12 +-
drivers/media/platform/qcom/camss/camss.c | 80 +++++
6 files changed, 463 insertions(+), 3 deletions(-)
diff --git a/drivers/media/platform/qcom/camss/Makefile b/drivers/media/platform/qcom/camss/Makefile
index 23960d02877d..3a7ed4f5a004 100644
--- a/drivers/media/platform/qcom/camss/Makefile
+++ b/drivers/media/platform/qcom/camss/Makefile
@@ -8,6 +8,7 @@ qcom-camss-objs += \
camss-csid-4-7.o \
camss-csid-340.o \
camss-csid-680.o \
+ camss-csid-1080.o \
camss-csid-gen2.o \
camss-csid-gen3.o \
camss-csiphy-2ph-1-0.o \
diff --git a/drivers/media/platform/qcom/camss/camss-csid-1080.c b/drivers/media/platform/qcom/camss/camss-csid-1080.c
new file mode 100644
index 000000000000..165fbf1998ed
--- /dev/null
+++ b/drivers/media/platform/qcom/camss/camss-csid-1080.c
@@ -0,0 +1,371 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * camss-csid-1080.c
+ *
+ * Qualcomm MSM Camera Subsystem - CSID (CSI Decoder) Module
+ *
+ * Copyright (c) Qualcomm Technologies, Inc. and/or its subsidiaries.
+ */
+#include <linux/completion.h>
+#include <linux/delay.h>
+#include <linux/interrupt.h>
+#include <linux/io.h>
+#include <linux/kernel.h>
+#include <linux/of.h>
+
+#include "camss.h"
+#include "camss-csid.h"
+#include "camss-csid-gen3.h"
+
+/* Reset and Command Registers */
+#define CSID_RST_CFG 0x108
+#define RST_MODE BIT(0)
+#define RST_LOCATION BIT(4)
+
+/* Reset and Command Registers */
+#define CSID_RST_CMD 0x10C
+#define SELECT_HW_RST BIT(0)
+#define SELECT_IRQ_RST BIT(2)
+#define CSID_IRQ_CMD 0x110
+#define IRQ_CMD_CLEAR BIT(0)
+
+/* Register Update Commands, RUP/AUP */
+#define CSID_RUP_CMD 0x114
+#define RUP_RDIN BIT(8)
+#define CSID_AUP_CMD 0x118
+#define AUP_RDIN BIT(8)
+#define CSID_RUP_AUP_CMD 0x11C
+#define RUP_SET BIT(0)
+#define MUP BIT(4)
+
+/* Top level interrupt registers */
+#define CSID_TOP_IRQ_STATUS 0x180
+#define CSID_TOP_IRQ_MASK 0x184
+#define CSID_TOP_IRQ_CLEAR 0x188
+#define INFO_RST_DONE BIT(0)
+#define CSI2_RX_IRQ_STATUS BIT(2)
+#define BUF_DONE_IRQ_STATUS BIT(3)
+
+/* Buffer done interrupt registers */
+#define CSID_BUF_DONE_IRQ_STATUS 0x1A0
+#define BUF_DONE_IRQ_STATUS_RDI_OFFSET 16
+#define CSID_BUF_DONE_IRQ_MASK 0x1A4
+#define CSID_BUF_DONE_IRQ_CLEAR 0x1A8
+#define CSID_BUF_DONE_IRQ_SET 0x1AC
+
+/* CSI2 RX interrupt registers */
+#define CSID_CSI2_RX_IRQ_STATUS 0x1B0
+#define CSID_CSI2_RX_IRQ_MASK 0x1B4
+#define CSID_CSI2_RX_IRQ_CLEAR 0x1B8
+#define CSID_CSI2_RX_IRQ_SET 0x1BC
+
+/* CSI2 RX Configuration */
+#define CSID_CSI2_RX_CFG0 0x880
+#define CSI2_RX_CFG0_NUM_ACTIVE_LANES 0
+#define CSI2_RX_CFG0_DL0_INPUT_SEL 4
+#define CSI2_RX_CFG0_PHY_NUM_SEL 20
+#define CSID_CSI2_RX_CFG1 0x884
+#define CSI2_RX_CFG1_ECC_CORRECTION_EN BIT(0)
+#define CSI2_RX_CFG1_VC_MODE BIT(2)
+
+#define MSM_CSID_MAX_SRC_STREAMS_1080 (csid_is_lite(csid) ? 4 : 5)
+
+/* RDI Configuration */
+#define CSID_RDI_CFG0(rdi) \
+ ((csid_is_lite(csid) ? 0x3080 : 0x5480) + 0x200 * (rdi))
+#define RDI_CFG0_RETIME_BS BIT(5)
+#define RDI_CFG0_TIMESTAMP_EN BIT(6)
+#define RDI_CFG0_TIMESTAMP_STB_SEL BIT(8)
+#define RDI_CFG0_DECODE_FORMAT 12
+#define RDI_CFG0_DT 16
+#define RDI_CFG0_VC 22
+#define RDI_CFG0_EN BIT(31)
+
+/* RDI Control and Configuration */
+#define CSID_RDI_CTRL(rdi) \
+ ((csid_is_lite(csid) ? 0x3088 : 0x5488) + 0x200 * (rdi))
+#define RDI_CTRL_START_CMD BIT(0)
+
+#define CSID_RDI_CFG1(rdi) \
+ ((csid_is_lite(csid) ? 0x3094 : 0x5494) + 0x200 * (rdi))
+#define RDI_CFG1_DROP_H_EN BIT(5)
+#define RDI_CFG1_DROP_V_EN BIT(6)
+#define RDI_CFG1_CROP_H_EN BIT(7)
+#define RDI_CFG1_CROP_V_EN BIT(8)
+#define RDI_CFG1_PACKING_FORMAT_MIPI BIT(15)
+
+/* RDI Pixel Store Configuration */
+#define CSID_RDI_PIX_STORE_CFG0(rdi) (0x5498 + 0x200 * (rdi))
+#define RDI_PIX_STORE_CFG0_EN BIT(0)
+#define RDI_PIX_STORE_CFG0_MIN_HBI 1
+
+/* RDI IRQ Status in wrapper */
+#define CSID_CSI2_RDIN_IRQ_STATUS(rdi) (0x224 + (0x10 * (rdi)))
+#define CSID_CSI2_RDIN_IRQ_MASK(rdi) (0x228 + (0x10 * (rdi)))
+#define CSID_CSI2_RDIN_IRQ_CLEAR(rdi) (0x22C + (0x10 * (rdi)))
+#define INFO_RUP_DONE BIT(23)
+
+static void __csid_aup_rup_trigger(struct csid_device *csid)
+{
+ /* trigger SET in combined register */
+ writel(RUP_SET, csid->base + CSID_RUP_AUP_CMD);
+}
+
+static void __csid_aup_update(struct csid_device *csid, int port_id)
+{
+ csid->aup_update |= AUP_RDIN << port_id;
+ writel(csid->aup_update, csid->base + CSID_AUP_CMD);
+
+ __csid_aup_rup_trigger(csid);
+}
+
+static void __csid_reg_update(struct csid_device *csid, int port_id)
+{
+ csid->rup_update |= RUP_RDIN << port_id;
+ writel(csid->rup_update, csid->base + CSID_RUP_CMD);
+
+ __csid_aup_rup_trigger(csid);
+}
+
+static void __csid_configure_rx(struct csid_device *csid,
+ struct csid_phy_config *phy)
+{
+ int val;
+
+ val = (phy->lane_cnt - 1) << CSI2_RX_CFG0_NUM_ACTIVE_LANES;
+ val |= phy->lane_assign << CSI2_RX_CFG0_DL0_INPUT_SEL;
+ val |= (phy->csiphy_id + CSI2_RX_CFG0_PHY_SEL_BASE_IDX)
+ << CSI2_RX_CFG0_PHY_NUM_SEL;
+ writel(val, csid->base + CSID_CSI2_RX_CFG0);
+
+ val = CSI2_RX_CFG1_ECC_CORRECTION_EN;
+ writel(val, csid->base + CSID_CSI2_RX_CFG1);
+}
+
+static void __csid_configure_rx_vc(struct csid_device *csid, int vc)
+{
+ int val;
+
+ if (vc > 3) {
+ val = readl(csid->base + CSID_CSI2_RX_CFG1);
+ val |= CSI2_RX_CFG1_VC_MODE;
+ writel(val, csid->base + CSID_CSI2_RX_CFG1);
+ }
+}
+
+static void __csid_ctrl_rdi(struct csid_device *csid, int enable, u8 rdi)
+{
+ int val = 0;
+
+ if (enable)
+ val = RDI_CTRL_START_CMD;
+
+ writel(val, csid->base + CSID_RDI_CTRL(rdi));
+}
+
+static void __csid_configure_rdi_pix_store(struct csid_device *csid, u8 rdi)
+{
+ u32 val;
+
+ /* Configure pixel store to allow absorption of hblanking or idle time.
+ * This helps with horizontal crop and prevents line buffer conflicts.
+ * Reset state is 0x8 which has MIN_HBI=4, we keep the default MIN_HBI
+ * and just enable the pixel store functionality.
+ */
+ val = (4 << RDI_PIX_STORE_CFG0_MIN_HBI) | RDI_PIX_STORE_CFG0_EN;
+ writel(val, csid->base + CSID_RDI_PIX_STORE_CFG0(rdi));
+}
+
+static void __csid_configure_rdi_stream(struct csid_device *csid, u8 enable, u8 vc)
+{
+ u32 val;
+ u8 lane_cnt = csid->phy.lane_cnt;
+
+ /* Source pads matching RDI channels on hardware.
+ * E.g. Pad 1 -> RDI0, Pad 2 -> RDI1, etc.
+ */
+ struct v4l2_mbus_framefmt *input_format = &csid->fmt[MSM_CSID_PAD_FIRST_SRC + vc];
+ const struct csid_format_info *format = csid_get_fmt_entry(csid->res->formats->formats,
+ csid->res->formats->nformats,
+ input_format->code);
+
+ if (!lane_cnt)
+ lane_cnt = 4;
+
+ val = RDI_CFG0_TIMESTAMP_EN;
+ val |= RDI_CFG0_TIMESTAMP_STB_SEL;
+ val |= RDI_CFG0_RETIME_BS;
+
+ /* note: for non-RDI path, this should be format->decode_format */
+ val |= DECODE_FORMAT_PAYLOAD_ONLY << RDI_CFG0_DECODE_FORMAT;
+ val |= vc << RDI_CFG0_VC;
+ val |= format->data_type << RDI_CFG0_DT;
+ writel(val, csid->base + CSID_RDI_CFG0(vc));
+
+ val = RDI_CFG1_PACKING_FORMAT_MIPI;
+ writel(val, csid->base + CSID_RDI_CFG1(vc));
+
+ /* Configure pixel store using dedicated register in 1080 */
+ if (!csid_is_lite(csid))
+ __csid_configure_rdi_pix_store(csid, vc);
+
+ val = 0;
+ writel(val, csid->base + CSID_RDI_CTRL(vc));
+
+ val = readl(csid->base + CSID_RDI_CFG0(vc));
+
+ if (enable)
+ val |= RDI_CFG0_EN;
+
+ writel(val, csid->base + CSID_RDI_CFG0(vc));
+}
+
+static void csid_configure_stream_1080(struct csid_device *csid, u8 enable)
+{
+ u8 i;
+ u8 vc;
+
+ __csid_configure_rx(csid, &csid->phy);
+
+ for (vc = 0; vc < MSM_CSID_MAX_SRC_STREAMS_1080; vc++) {
+ if (csid->phy.en_vc & BIT(vc)) {
+ __csid_configure_rdi_stream(csid, enable, vc);
+ __csid_configure_rx_vc(csid, vc);
+
+ for (i = 0; i < CAMSS_INIT_BUF_COUNT; i++)
+ __csid_aup_update(csid, vc);
+
+ __csid_reg_update(csid, vc);
+
+ __csid_ctrl_rdi(csid, enable, vc);
+ }
+ }
+}
+
+static int csid_configure_testgen_pattern_1080(struct csid_device *csid,
+ s32 val)
+{
+ return 0;
+}
+
+static void csid_subdev_reg_update_1080(struct csid_device *csid, int port_id,
+ bool clear)
+{
+ /* No explicit clear required */
+ if (!clear)
+ __csid_aup_update(csid, port_id);
+}
+
+/**
+ * csid_isr - CSID module interrupt service routine
+ * @irq: Interrupt line
+ * @dev: CSID device
+ *
+ * Return IRQ_HANDLED on success
+ */
+static irqreturn_t csid_isr_1080(int irq, void *dev)
+{
+ struct csid_device *csid = dev;
+ u32 val, buf_done_val;
+ u8 reset_done;
+ int i;
+
+ val = readl(csid->base + CSID_TOP_IRQ_STATUS);
+ writel(val, csid->base + CSID_TOP_IRQ_CLEAR);
+
+ reset_done = val & INFO_RST_DONE;
+
+ buf_done_val = readl(csid->base + CSID_BUF_DONE_IRQ_STATUS);
+ writel(buf_done_val, csid->base + CSID_BUF_DONE_IRQ_CLEAR);
+
+ for (i = 0; i < MSM_CSID_MAX_SRC_STREAMS_1080; i++)
+ if (csid->phy.en_vc & BIT(i)) {
+ val = readl(csid->base + CSID_CSI2_RDIN_IRQ_STATUS(i));
+ writel(val, csid->base + CSID_CSI2_RDIN_IRQ_CLEAR(i));
+
+ if (buf_done_val & BIT(BUF_DONE_IRQ_STATUS_RDI_OFFSET + i)) {
+ /*
+ * buf done and RUP IRQ have been moved to CSID from VFE.
+ * Once CSID received buf done, need notify VFE of this
+ * event and trigger VFE to handle buf done process.
+ */
+ camss_buf_done(csid->camss, csid->id, i);
+ }
+ }
+
+ val = IRQ_CMD_CLEAR;
+ writel(val, csid->base + CSID_IRQ_CMD);
+
+ if (reset_done)
+ complete(&csid->reset_complete);
+
+ return IRQ_HANDLED;
+}
+
+/**
+ * csid_reset - Trigger reset on CSID module and wait to complete
+ * @csid: CSID device
+ *
+ * Return 0 on success or a negative error code otherwise
+ */
+static int csid_reset_1080(struct csid_device *csid)
+{
+ unsigned long time;
+ u32 val;
+ int i;
+
+ reinit_completion(&csid->reset_complete);
+
+ val = INFO_RST_DONE | BUF_DONE_IRQ_STATUS;
+ writel(val, csid->base + CSID_TOP_IRQ_CLEAR);
+ writel(val, csid->base + CSID_TOP_IRQ_MASK);
+
+ val = 0;
+ for (i = 0; i < MSM_CSID_MAX_SRC_STREAMS_1080; i++) {
+ if (csid->phy.en_vc & BIT(i)) {
+ /* Only need to clear Buffer Done IRQ Status here,
+ * RUP Done IRQ Status will be cleared once isr
+ * strobe generated by CSID_RST_CMD
+ */
+ val |= BIT(BUF_DONE_IRQ_STATUS_RDI_OFFSET + i);
+ }
+ }
+ writel(val, csid->base + CSID_BUF_DONE_IRQ_CLEAR);
+ writel(val, csid->base + CSID_BUF_DONE_IRQ_MASK);
+
+ /* Clear all IRQ status with CLEAR bits set */
+ val = IRQ_CMD_CLEAR;
+ writel(val, csid->base + CSID_IRQ_CMD);
+
+ val = RST_LOCATION | RST_MODE;
+ writel(val, csid->base + CSID_RST_CFG);
+
+ val = SELECT_HW_RST | SELECT_IRQ_RST;
+ writel(val, csid->base + CSID_RST_CMD);
+
+ time = wait_for_completion_timeout(&csid->reset_complete,
+ msecs_to_jiffies(CSID_RESET_TIMEOUT_MS));
+
+ if (!time) {
+ dev_err(csid->camss->dev, "CSID reset timeout\n");
+ return -EIO;
+ }
+
+ return 0;
+}
+
+static void csid_subdev_init_1080(struct csid_device *csid)
+{
+ csid->testgen.nmodes = CSID_PAYLOAD_MODE_DISABLED;
+}
+
+const struct csid_hw_ops csid_ops_1080 = {
+ .configure_stream = csid_configure_stream_1080,
+ .configure_testgen_pattern = csid_configure_testgen_pattern_1080,
+ .hw_version = csid_hw_version,
+ .isr = csid_isr_1080,
+ .reset = csid_reset_1080,
+ .src_pad_code = csid_src_pad_code,
+ .subdev_init = csid_subdev_init_1080,
+ .reg_update = csid_subdev_reg_update_1080,
+};
diff --git a/drivers/media/platform/qcom/camss/camss-csid-680.c b/drivers/media/platform/qcom/camss/camss-csid-680.c
index 3ad3a174bcfb..86134a23cd4e 100644
--- a/drivers/media/platform/qcom/camss/camss-csid-680.c
+++ b/drivers/media/platform/qcom/camss/camss-csid-680.c
@@ -101,7 +101,6 @@
#define CSI2_RX_CFG0_DL2_INPUT_SEL 12
#define CSI2_RX_CFG0_DL3_INPUT_SEL 16
#define CSI2_RX_CFG0_PHY_NUM_SEL 20
-#define CSI2_RX_CFG0_PHY_SEL_BASE_IDX 1
#define CSI2_RX_CFG0_PHY_TYPE_SEL 24
#define CSID_CSI2_RX_CFG1 0x204
diff --git a/drivers/media/platform/qcom/camss/camss-csid-gen3.c b/drivers/media/platform/qcom/camss/camss-csid-gen3.c
index 664245cf6eb0..f09b5575572a 100644
--- a/drivers/media/platform/qcom/camss/camss-csid-gen3.c
+++ b/drivers/media/platform/qcom/camss/camss-csid-gen3.c
@@ -103,7 +103,6 @@
#define CSID_RDI_IRQ_SUBSAMPLE_PERIOD(rdi) (csid_is_lite(csid) && IS_CSID_690(csid) ?\
(0x34C + 0x100 * (rdi)) :\
(0x54C + 0x100 * (rdi)))
-#define CSI2_RX_CFG0_PHY_SEL_BASE_IDX 1
static void __csid_configure_rx(struct csid_device *csid,
struct csid_phy_config *phy, int vc)
diff --git a/drivers/media/platform/qcom/camss/camss-csid.h b/drivers/media/platform/qcom/camss/camss-csid.h
index aedc96ed84b2..b5ceb456a394 100644
--- a/drivers/media/platform/qcom/camss/camss-csid.h
+++ b/drivers/media/platform/qcom/camss/camss-csid.h
@@ -27,8 +27,11 @@
/* CSID hardware can demultiplex up to 4 outputs */
#define MSM_CSID_MAX_SRC_STREAMS 4
+/* CSIPHY to hardware PHY selector mapping */
+#define CSI2_RX_CFG0_PHY_SEL_BASE_IDX 1
#define CSID_RESET_TIMEOUT_MS 500
+
enum csid_testgen_mode {
CSID_PAYLOAD_MODE_DISABLED = 0,
CSID_PAYLOAD_MODE_INCREMENTING = 1,
@@ -154,7 +157,13 @@ struct csid_device {
void __iomem *base;
u32 irq;
char irq_name[30];
- u32 reg_update;
+ union {
+ u32 reg_update;
+ struct {
+ u32 rup_update;
+ u32 aup_update;
+ };
+ };
struct camss_clock *clock;
int nclocks;
struct regulator_bulk_data *supplies;
@@ -215,6 +224,7 @@ extern const struct csid_hw_ops csid_ops_4_1;
extern const struct csid_hw_ops csid_ops_4_7;
extern const struct csid_hw_ops csid_ops_340;
extern const struct csid_hw_ops csid_ops_680;
+extern const struct csid_hw_ops csid_ops_1080;
extern const struct csid_hw_ops csid_ops_gen2;
extern const struct csid_hw_ops csid_ops_gen3;
diff --git a/drivers/media/platform/qcom/camss/camss.c b/drivers/media/platform/qcom/camss/camss.c
index 542122fba825..74a8ad3cb728 100644
--- a/drivers/media/platform/qcom/camss/camss.c
+++ b/drivers/media/platform/qcom/camss/camss.c
@@ -139,6 +139,84 @@ static const struct camss_subdev_resources csiphy_res_kaanapali[] = {
},
};
+static const struct camss_subdev_resources csid_res_kaanapali[] = {
+ /* CSID0 */
+ {
+ .regulators = {},
+ .clock = { "csid", "csid_csiphy_rx" },
+ .clock_rate = { { 400000000, 480000000 },
+ { 400000000, 480000000 } },
+ .reg = { "csid0" },
+ .interrupt = { "csid0" },
+ .csid = {
+ .is_lite = false,
+ .parent_dev_ops = &vfe_parent_dev_ops,
+ .hw_ops = &csid_ops_1080,
+ .formats = &csid_formats_gen2
+ }
+ },
+ /* CSID1 */
+ {
+ .regulators = {},
+ .clock = { "csid", "csid_csiphy_rx" },
+ .clock_rate = { { 400000000, 480000000 },
+ { 400000000, 480000000 } },
+ .reg = { "csid1" },
+ .interrupt = { "csid1" },
+ .csid = {
+ .is_lite = false,
+ .parent_dev_ops = &vfe_parent_dev_ops,
+ .hw_ops = &csid_ops_1080,
+ .formats = &csid_formats_gen2
+ }
+ },
+ /* CSID2 */
+ {
+ .regulators = {},
+ .clock = { "csid", "csid_csiphy_rx" },
+ .clock_rate = { { 400000000, 480000000 },
+ { 400000000, 480000000 } },
+ .reg = { "csid2" },
+ .interrupt = { "csid2" },
+ .csid = {
+ .is_lite = false,
+ .parent_dev_ops = &vfe_parent_dev_ops,
+ .hw_ops = &csid_ops_1080,
+ .formats = &csid_formats_gen2
+ }
+ },
+ /* CSID_LITE0 */
+ {
+ .regulators = {},
+ .clock = { "vfe_lite_csid", "vfe_lite_cphy_rx" },
+ .clock_rate = { { 400000000, 480000000 },
+ { 400000000, 480000000 } },
+ .reg = { "csid_lite0" },
+ .interrupt = { "csid_lite0" },
+ .csid = {
+ .is_lite = true,
+ .parent_dev_ops = &vfe_parent_dev_ops,
+ .hw_ops = &csid_ops_1080,
+ .formats = &csid_formats_gen2
+ }
+ },
+ /* CSID_LITE1 */
+ {
+ .regulators = {},
+ .clock = { "vfe_lite_csid", "vfe_lite_cphy_rx" },
+ .clock_rate = { { 400000000, 480000000 },
+ { 400000000, 480000000 } },
+ .reg = { "csid_lite1" },
+ .interrupt = { "csid_lite1" },
+ .csid = {
+ .is_lite = true,
+ .parent_dev_ops = &vfe_parent_dev_ops,
+ .hw_ops = &csid_ops_1080,
+ .formats = &csid_formats_gen2
+ }
+ }
+};
+
static const struct resources_icc icc_res_kaanapali[] = {
/* Based on 4096 x 3072 30 FPS 2496 Mbps mode */
{
@@ -4414,9 +4492,11 @@ static const struct camss_resources kaanapali_resources = {
.version = CAMSS_KAANAPALI,
.pd_name = "top",
.csiphy_res = csiphy_res_kaanapali,
+ .csid_res = csid_res_kaanapali,
.icc_res = icc_res_kaanapali,
.icc_path_num = ARRAY_SIZE(icc_res_kaanapali),
.csiphy_num = ARRAY_SIZE(csiphy_res_kaanapali),
+ .csid_num = ARRAY_SIZE(csid_res_kaanapali),
};
static const struct camss_resources msm8916_resources = {
--
2.34.1
^ permalink raw reply related [flat|nested] 46+ messages in thread* Re: [PATCH v2 5/6] media: qcom: camss: csid: Add support for CSID 1080
2025-10-15 2:56 ` [PATCH v2 5/6] media: qcom: camss: csid: Add support for CSID 1080 Hangxiang Ma
@ 2025-10-16 9:12 ` Bryan O'Donoghue
2025-10-20 5:59 ` Hangxiang Ma
2025-10-16 10:04 ` Bryan O'Donoghue
1 sibling, 1 reply; 46+ messages in thread
From: Bryan O'Donoghue @ 2025-10-16 9:12 UTC (permalink / raw)
To: Hangxiang Ma, Loic Poulain, Robert Foss, Andi Shyti, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Todor Tomov,
Vladimir Zapolskiy, Mauro Carvalho Chehab
Cc: linux-i2c, linux-arm-msm, devicetree, linux-kernel, linux-media,
aiqun.yu, tingwei.zhang, trilok.soni, yijie.yang, Jingyi Wang,
Atiya Kailany
On 15/10/2025 03:56, Hangxiang Ma wrote:
> + for (i = 0; i < MSM_CSID_MAX_SRC_STREAMS_1080; i++)
> + if (csid->phy.en_vc & BIT(i)) {
> + val = readl(csid->base + CSID_CSI2_RDIN_IRQ_STATUS(i));
> + writel(val, csid->base + CSID_CSI2_RDIN_IRQ_CLEAR(i));
> +
> + if (buf_done_val & BIT(BUF_DONE_IRQ_STATUS_RDI_OFFSET + i)) {
> + /*
> + * buf done and RUP IRQ have been moved to CSID from VFE.
> + * Once CSID received buf done, need notify VFE of this
> + * event and trigger VFE to handle buf done process.
> + */
> + camss_buf_done(csid->camss, csid->id, i);
> + }
> + }
> +
A multi-liner like this should be
for (i = 0; i < MSM_CSID_MAX_SRC_STREAMS_1080; i++) {
/* etc */
}
in fact csid_reset_1080() does the right thing, please replicate.
^ permalink raw reply [flat|nested] 46+ messages in thread* Re: [PATCH v2 5/6] media: qcom: camss: csid: Add support for CSID 1080
2025-10-16 9:12 ` Bryan O'Donoghue
@ 2025-10-20 5:59 ` Hangxiang Ma
0 siblings, 0 replies; 46+ messages in thread
From: Hangxiang Ma @ 2025-10-20 5:59 UTC (permalink / raw)
To: Bryan O'Donoghue, Loic Poulain, Robert Foss, Andi Shyti,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Todor Tomov,
Vladimir Zapolskiy, Mauro Carvalho Chehab
Cc: linux-i2c, linux-arm-msm, devicetree, linux-kernel, linux-media,
aiqun.yu, tingwei.zhang, trilok.soni, yijie.yang, Jingyi Wang,
Atiya Kailany
On 10/16/2025 5:12 PM, Bryan O'Donoghue wrote:
> On 15/10/2025 03:56, Hangxiang Ma wrote:
>> + for (i = 0; i < MSM_CSID_MAX_SRC_STREAMS_1080; i++)
>> + if (csid->phy.en_vc & BIT(i)) {
>> + val = readl(csid->base + CSID_CSI2_RDIN_IRQ_STATUS(i));
>> + writel(val, csid->base + CSID_CSI2_RDIN_IRQ_CLEAR(i));
>> +
>> + if (buf_done_val & BIT(BUF_DONE_IRQ_STATUS_RDI_OFFSET +
>> i)) {
>> + /*
>> + * buf done and RUP IRQ have been moved to CSID from
>> VFE.
>> + * Once CSID received buf done, need notify VFE of this
>> + * event and trigger VFE to handle buf done process.
>> + */
>> + camss_buf_done(csid->camss, csid->id, i);
>> + }
>> + }
>> +
> A multi-liner like this should be
>
> for (i = 0; i < MSM_CSID_MAX_SRC_STREAMS_1080; i++) {
> /* etc */
> }
>
> in fact csid_reset_1080() does the right thing, please replicate.
>
Ack. Thanks.
---
Hangxiang
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: [PATCH v2 5/6] media: qcom: camss: csid: Add support for CSID 1080
2025-10-15 2:56 ` [PATCH v2 5/6] media: qcom: camss: csid: Add support for CSID 1080 Hangxiang Ma
2025-10-16 9:12 ` Bryan O'Donoghue
@ 2025-10-16 10:04 ` Bryan O'Donoghue
2025-10-16 10:18 ` Bryan O'Donoghue
2025-10-16 22:55 ` Vijay Kumar Tumati
1 sibling, 2 replies; 46+ messages in thread
From: Bryan O'Donoghue @ 2025-10-16 10:04 UTC (permalink / raw)
To: Hangxiang Ma, Loic Poulain, Robert Foss, Andi Shyti, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Todor Tomov,
Vladimir Zapolskiy, Mauro Carvalho Chehab
Cc: linux-i2c, linux-arm-msm, devicetree, linux-kernel, linux-media,
aiqun.yu, tingwei.zhang, trilok.soni, yijie.yang, Jingyi Wang,
Atiya Kailany
On 15/10/2025 03:56, Hangxiang Ma wrote:
> Add more detailed resource information for CSID devices along with the
> driver for CSID 1080 that is responsible for CSID register
> configuration, module reset and IRQ handling for BUF_DONE events. And
> aggregate a common definition 'CSI2_RX_CFG0_PHY_SEL_BASE_IDX' into csid
> header file.
>
> In this CSID version, RUP and AUP update values are split into two
> registers along with a SET register. Accordingly , enhance the CSID
> interface to accommodate both the legacy combined reg_update and the
> split RUP and AUP updates.
>
> Co-developed-by: Atiya Kailany <atiya.kailany@oss.qualcomm.com>
> Signed-off-by: Atiya Kailany <atiya.kailany@oss.qualcomm.com>
> Signed-off-by: Hangxiang Ma <hangxiang.ma@oss.qualcomm.com>
> ---
> drivers/media/platform/qcom/camss/Makefile | 1 +
> .../media/platform/qcom/camss/camss-csid-1080.c | 371 +++++++++++++++++++++
> drivers/media/platform/qcom/camss/camss-csid-680.c | 1 -
> .../media/platform/qcom/camss/camss-csid-gen3.c | 1 -
> drivers/media/platform/qcom/camss/camss-csid.h | 12 +-
> drivers/media/platform/qcom/camss/camss.c | 80 +++++
> 6 files changed, 463 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/media/platform/qcom/camss/Makefile b/drivers/media/platform/qcom/camss/Makefile
> index 23960d02877d..3a7ed4f5a004 100644
> --- a/drivers/media/platform/qcom/camss/Makefile
> +++ b/drivers/media/platform/qcom/camss/Makefile
> @@ -8,6 +8,7 @@ qcom-camss-objs += \
> camss-csid-4-7.o \
> camss-csid-340.o \
> camss-csid-680.o \
> + camss-csid-1080.o \
> camss-csid-gen2.o \
> camss-csid-gen3.o \
> camss-csiphy-2ph-1-0.o \
> diff --git a/drivers/media/platform/qcom/camss/camss-csid-1080.c b/drivers/media/platform/qcom/camss/camss-csid-1080.c
> new file mode 100644
> index 000000000000..165fbf1998ed
> --- /dev/null
> +++ b/drivers/media/platform/qcom/camss/camss-csid-1080.c
> @@ -0,0 +1,371 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * camss-csid-1080.c
> + *
> + * Qualcomm MSM Camera Subsystem - CSID (CSI Decoder) Module
> + *
> + * Copyright (c) Qualcomm Technologies, Inc. and/or its subsidiaries.
> + */
> +#include <linux/completion.h>
> +#include <linux/delay.h>
> +#include <linux/interrupt.h>
> +#include <linux/io.h>
> +#include <linux/kernel.h>
> +#include <linux/of.h>
> +
> +#include "camss.h"
> +#include "camss-csid.h"
> +#include "camss-csid-gen3.h"
> +
> +/* Reset and Command Registers */
> +#define CSID_RST_CFG 0x108
> +#define RST_MODE BIT(0)
> +#define RST_LOCATION BIT(4)
> +
> +/* Reset and Command Registers */
> +#define CSID_RST_CMD 0x10C
> +#define SELECT_HW_RST BIT(0)
> +#define SELECT_IRQ_RST BIT(2)
> +#define CSID_IRQ_CMD 0x110
> +#define IRQ_CMD_CLEAR BIT(0)
> +
> +/* Register Update Commands, RUP/AUP */
> +#define CSID_RUP_CMD 0x114
> +#define RUP_RDIN BIT(8)
> +#define CSID_AUP_CMD 0x118
> +#define AUP_RDIN BIT(8)
> +#define CSID_RUP_AUP_CMD 0x11C
> +#define RUP_SET BIT(0)
> +#define MUP BIT(4)
> +
> +/* Top level interrupt registers */
> +#define CSID_TOP_IRQ_STATUS 0x180
> +#define CSID_TOP_IRQ_MASK 0x184
> +#define CSID_TOP_IRQ_CLEAR 0x188
> +#define INFO_RST_DONE BIT(0)
> +#define CSI2_RX_IRQ_STATUS BIT(2)
> +#define BUF_DONE_IRQ_STATUS BIT(3)
> +
> +/* Buffer done interrupt registers */
> +#define CSID_BUF_DONE_IRQ_STATUS 0x1A0
> +#define BUF_DONE_IRQ_STATUS_RDI_OFFSET 16
> +#define CSID_BUF_DONE_IRQ_MASK 0x1A4
> +#define CSID_BUF_DONE_IRQ_CLEAR 0x1A8
> +#define CSID_BUF_DONE_IRQ_SET 0x1AC
> +
> +/* CSI2 RX interrupt registers */
> +#define CSID_CSI2_RX_IRQ_STATUS 0x1B0
> +#define CSID_CSI2_RX_IRQ_MASK 0x1B4
> +#define CSID_CSI2_RX_IRQ_CLEAR 0x1B8
> +#define CSID_CSI2_RX_IRQ_SET 0x1BC
> +
> +/* CSI2 RX Configuration */
> +#define CSID_CSI2_RX_CFG0 0x880
> +#define CSI2_RX_CFG0_NUM_ACTIVE_LANES 0
> +#define CSI2_RX_CFG0_DL0_INPUT_SEL 4
> +#define CSI2_RX_CFG0_PHY_NUM_SEL 20
> +#define CSID_CSI2_RX_CFG1 0x884
> +#define CSI2_RX_CFG1_ECC_CORRECTION_EN BIT(0)
> +#define CSI2_RX_CFG1_VC_MODE BIT(2)
> +
> +#define MSM_CSID_MAX_SRC_STREAMS_1080 (csid_is_lite(csid) ? 4 : 5)
> +
> +/* RDI Configuration */
> +#define CSID_RDI_CFG0(rdi) \
> + ((csid_is_lite(csid) ? 0x3080 : 0x5480) + 0x200 * (rdi))
> +#define RDI_CFG0_RETIME_BS BIT(5)
> +#define RDI_CFG0_TIMESTAMP_EN BIT(6)
> +#define RDI_CFG0_TIMESTAMP_STB_SEL BIT(8)
> +#define RDI_CFG0_DECODE_FORMAT 12
> +#define RDI_CFG0_DT 16
> +#define RDI_CFG0_VC 22
> +#define RDI_CFG0_EN BIT(31)
> +
> +/* RDI Control and Configuration */
> +#define CSID_RDI_CTRL(rdi) \
> + ((csid_is_lite(csid) ? 0x3088 : 0x5488) + 0x200 * (rdi))
> +#define RDI_CTRL_START_CMD BIT(0)
> +
> +#define CSID_RDI_CFG1(rdi) \
> + ((csid_is_lite(csid) ? 0x3094 : 0x5494) + 0x200 * (rdi))
> +#define RDI_CFG1_DROP_H_EN BIT(5)
> +#define RDI_CFG1_DROP_V_EN BIT(6)
> +#define RDI_CFG1_CROP_H_EN BIT(7)
> +#define RDI_CFG1_CROP_V_EN BIT(8)
> +#define RDI_CFG1_PACKING_FORMAT_MIPI BIT(15)
> +
> +/* RDI Pixel Store Configuration */
> +#define CSID_RDI_PIX_STORE_CFG0(rdi) (0x5498 + 0x200 * (rdi))
> +#define RDI_PIX_STORE_CFG0_EN BIT(0)
> +#define RDI_PIX_STORE_CFG0_MIN_HBI 1
> +
> +/* RDI IRQ Status in wrapper */
> +#define CSID_CSI2_RDIN_IRQ_STATUS(rdi) (0x224 + (0x10 * (rdi)))
> +#define CSID_CSI2_RDIN_IRQ_MASK(rdi) (0x228 + (0x10 * (rdi)))
> +#define CSID_CSI2_RDIN_IRQ_CLEAR(rdi) (0x22C + (0x10 * (rdi)))
> +#define INFO_RUP_DONE BIT(23)
> +
> +static void __csid_aup_rup_trigger(struct csid_device *csid)
> +{
> + /* trigger SET in combined register */
> + writel(RUP_SET, csid->base + CSID_RUP_AUP_CMD);
> +}
> +
> +static void __csid_aup_update(struct csid_device *csid, int port_id)
> +{
> + csid->aup_update |= AUP_RDIN << port_id;
> + writel(csid->aup_update, csid->base + CSID_AUP_CMD);
> +
> + __csid_aup_rup_trigger(csid);
> +}
> +
> +static void __csid_reg_update(struct csid_device *csid, int port_id)
> +{
> + csid->rup_update |= RUP_RDIN << port_id;
> + writel(csid->rup_update, csid->base + CSID_RUP_CMD);
> +
> + __csid_aup_rup_trigger(csid);
> +}
> +
> +static void __csid_configure_rx(struct csid_device *csid,
> + struct csid_phy_config *phy)
> +{
> + int val;
> +
> + val = (phy->lane_cnt - 1) << CSI2_RX_CFG0_NUM_ACTIVE_LANES;
> + val |= phy->lane_assign << CSI2_RX_CFG0_DL0_INPUT_SEL;
> + val |= (phy->csiphy_id + CSI2_RX_CFG0_PHY_SEL_BASE_IDX)
> + << CSI2_RX_CFG0_PHY_NUM_SEL;
> + writel(val, csid->base + CSID_CSI2_RX_CFG0);
> +
> + val = CSI2_RX_CFG1_ECC_CORRECTION_EN;
> + writel(val, csid->base + CSID_CSI2_RX_CFG1);
> +}
> +
> +static void __csid_configure_rx_vc(struct csid_device *csid, int vc)
> +{
> + int val;
> +
> + if (vc > 3) {
> + val = readl(csid->base + CSID_CSI2_RX_CFG1);
> + val |= CSI2_RX_CFG1_VC_MODE;
> + writel(val, csid->base + CSID_CSI2_RX_CFG1);
> + }
> +}
> +
> +static void __csid_ctrl_rdi(struct csid_device *csid, int enable, u8 rdi)
> +{
> + int val = 0;
> +
> + if (enable)
> + val = RDI_CTRL_START_CMD;
> +
> + writel(val, csid->base + CSID_RDI_CTRL(rdi));
> +}
> +
> +static void __csid_configure_rdi_pix_store(struct csid_device *csid, u8 rdi)
> +{
> + u32 val;
> +
> + /* Configure pixel store to allow absorption of hblanking or idle time.
> + * This helps with horizontal crop and prevents line buffer conflicts.
> + * Reset state is 0x8 which has MIN_HBI=4, we keep the default MIN_HBI
> + * and just enable the pixel store functionality.
> + */
> + val = (4 << RDI_PIX_STORE_CFG0_MIN_HBI) | RDI_PIX_STORE_CFG0_EN;
> + writel(val, csid->base + CSID_RDI_PIX_STORE_CFG0(rdi));
> +}
> +
> +static void __csid_configure_rdi_stream(struct csid_device *csid, u8 enable, u8 vc)
> +{
> + u32 val;
> + u8 lane_cnt = csid->phy.lane_cnt;
> +
> + /* Source pads matching RDI channels on hardware.
> + * E.g. Pad 1 -> RDI0, Pad 2 -> RDI1, etc.
> + */
> + struct v4l2_mbus_framefmt *input_format = &csid->fmt[MSM_CSID_PAD_FIRST_SRC + vc];
> + const struct csid_format_info *format = csid_get_fmt_entry(csid->res->formats->formats,
> + csid->res->formats->nformats,
> + input_format->code);
> +
> + if (!lane_cnt)
> + lane_cnt = 4;
> +
> + val = RDI_CFG0_TIMESTAMP_EN;
> + val |= RDI_CFG0_TIMESTAMP_STB_SEL;
> + val |= RDI_CFG0_RETIME_BS;
> +
> + /* note: for non-RDI path, this should be format->decode_format */
> + val |= DECODE_FORMAT_PAYLOAD_ONLY << RDI_CFG0_DECODE_FORMAT;
> + val |= vc << RDI_CFG0_VC;
> + val |= format->data_type << RDI_CFG0_DT;
> + writel(val, csid->base + CSID_RDI_CFG0(vc));
> +
> + val = RDI_CFG1_PACKING_FORMAT_MIPI;
> + writel(val, csid->base + CSID_RDI_CFG1(vc));
> +
> + /* Configure pixel store using dedicated register in 1080 */
> + if (!csid_is_lite(csid))
> + __csid_configure_rdi_pix_store(csid, vc);
> +
> + val = 0;
> + writel(val, csid->base + CSID_RDI_CTRL(vc));
> +
> + val = readl(csid->base + CSID_RDI_CFG0(vc));
> +
> + if (enable)
> + val |= RDI_CFG0_EN;
> +
> + writel(val, csid->base + CSID_RDI_CFG0(vc));
> +}
> +
> +static void csid_configure_stream_1080(struct csid_device *csid, u8 enable)
> +{
> + u8 i;
> + u8 vc;
> +
> + __csid_configure_rx(csid, &csid->phy);
> +
> + for (vc = 0; vc < MSM_CSID_MAX_SRC_STREAMS_1080; vc++) {
> + if (csid->phy.en_vc & BIT(vc)) {
> + __csid_configure_rdi_stream(csid, enable, vc);
> + __csid_configure_rx_vc(csid, vc);
> +
> + for (i = 0; i < CAMSS_INIT_BUF_COUNT; i++)
> + __csid_aup_update(csid, vc);
> +
> + __csid_reg_update(csid, vc);
> +
> + __csid_ctrl_rdi(csid, enable, vc);
> + }
> + }
> +}
> +
> +static int csid_configure_testgen_pattern_1080(struct csid_device *csid,
> + s32 val)
> +{
> + return 0;
> +}
> +
> +static void csid_subdev_reg_update_1080(struct csid_device *csid, int port_id,
> + bool clear)
> +{
> + /* No explicit clear required */
> + if (!clear)
> + __csid_aup_update(csid, port_id);
> +}
> +
> +/**
> + * csid_isr - CSID module interrupt service routine
> + * @irq: Interrupt line
> + * @dev: CSID device
> + *
> + * Return IRQ_HANDLED on success
> + */
> +static irqreturn_t csid_isr_1080(int irq, void *dev)
> +{
> + struct csid_device *csid = dev;
> + u32 val, buf_done_val;
> + u8 reset_done;
> + int i;
> +
> + val = readl(csid->base + CSID_TOP_IRQ_STATUS);
> + writel(val, csid->base + CSID_TOP_IRQ_CLEAR);
> +
> + reset_done = val & INFO_RST_DONE;
> +
> + buf_done_val = readl(csid->base + CSID_BUF_DONE_IRQ_STATUS);
> + writel(buf_done_val, csid->base + CSID_BUF_DONE_IRQ_CLEAR);
> +
> + for (i = 0; i < MSM_CSID_MAX_SRC_STREAMS_1080; i++)
> + if (csid->phy.en_vc & BIT(i)) {
> + val = readl(csid->base + CSID_CSI2_RDIN_IRQ_STATUS(i));
> + writel(val, csid->base + CSID_CSI2_RDIN_IRQ_CLEAR(i));
> +
> + if (buf_done_val & BIT(BUF_DONE_IRQ_STATUS_RDI_OFFSET + i)) {
> + /*
> + * buf done and RUP IRQ have been moved to CSID from VFE.
> + * Once CSID received buf done, need notify VFE of this
> + * event and trigger VFE to handle buf done process.
> + */
> + camss_buf_done(csid->camss, csid->id, i);
> + }
> + }
> +
> + val = IRQ_CMD_CLEAR;
> + writel(val, csid->base + CSID_IRQ_CMD);
> +
> + if (reset_done)
> + complete(&csid->reset_complete);
> +
> + return IRQ_HANDLED;
> +}
> +
> +/**
> + * csid_reset - Trigger reset on CSID module and wait to complete
> + * @csid: CSID device
> + *
> + * Return 0 on success or a negative error code otherwise
> + */
> +static int csid_reset_1080(struct csid_device *csid)
> +{
> + unsigned long time;
> + u32 val;
> + int i;
> +
> + reinit_completion(&csid->reset_complete);
> +
> + val = INFO_RST_DONE | BUF_DONE_IRQ_STATUS;
> + writel(val, csid->base + CSID_TOP_IRQ_CLEAR);
> + writel(val, csid->base + CSID_TOP_IRQ_MASK);
> +
> + val = 0;
> + for (i = 0; i < MSM_CSID_MAX_SRC_STREAMS_1080; i++) {
> + if (csid->phy.en_vc & BIT(i)) {
> + /* Only need to clear Buffer Done IRQ Status here,
> + * RUP Done IRQ Status will be cleared once isr
> + * strobe generated by CSID_RST_CMD
> + */
> + val |= BIT(BUF_DONE_IRQ_STATUS_RDI_OFFSET + i);
> + }
> + }
> + writel(val, csid->base + CSID_BUF_DONE_IRQ_CLEAR);
> + writel(val, csid->base + CSID_BUF_DONE_IRQ_MASK);
> +
> + /* Clear all IRQ status with CLEAR bits set */
> + val = IRQ_CMD_CLEAR;
> + writel(val, csid->base + CSID_IRQ_CMD);
> +
> + val = RST_LOCATION | RST_MODE;
> + writel(val, csid->base + CSID_RST_CFG);
> +
> + val = SELECT_HW_RST | SELECT_IRQ_RST;
> + writel(val, csid->base + CSID_RST_CMD);
> +
> + time = wait_for_completion_timeout(&csid->reset_complete,
> + msecs_to_jiffies(CSID_RESET_TIMEOUT_MS));
> +
> + if (!time) {
> + dev_err(csid->camss->dev, "CSID reset timeout\n");
> + return -EIO;
> + }
> +
> + return 0;
> +}
> +
> +static void csid_subdev_init_1080(struct csid_device *csid)
> +{
> + csid->testgen.nmodes = CSID_PAYLOAD_MODE_DISABLED;
> +}
> +
> +const struct csid_hw_ops csid_ops_1080 = {
> + .configure_stream = csid_configure_stream_1080,
> + .configure_testgen_pattern = csid_configure_testgen_pattern_1080,
> + .hw_version = csid_hw_version,
> + .isr = csid_isr_1080,
> + .reset = csid_reset_1080,
> + .src_pad_code = csid_src_pad_code,
> + .subdev_init = csid_subdev_init_1080,
> + .reg_update = csid_subdev_reg_update_1080,
> +};
> diff --git a/drivers/media/platform/qcom/camss/camss-csid-680.c b/drivers/media/platform/qcom/camss/camss-csid-680.c
> index 3ad3a174bcfb..86134a23cd4e 100644
> --- a/drivers/media/platform/qcom/camss/camss-csid-680.c
> +++ b/drivers/media/platform/qcom/camss/camss-csid-680.c
> @@ -101,7 +101,6 @@
> #define CSI2_RX_CFG0_DL2_INPUT_SEL 12
> #define CSI2_RX_CFG0_DL3_INPUT_SEL 16
> #define CSI2_RX_CFG0_PHY_NUM_SEL 20
> -#define CSI2_RX_CFG0_PHY_SEL_BASE_IDX 1
> #define CSI2_RX_CFG0_PHY_TYPE_SEL 24
>
> #define CSID_CSI2_RX_CFG1 0x204
> diff --git a/drivers/media/platform/qcom/camss/camss-csid-gen3.c b/drivers/media/platform/qcom/camss/camss-csid-gen3.c
> index 664245cf6eb0..f09b5575572a 100644
> --- a/drivers/media/platform/qcom/camss/camss-csid-gen3.c
> +++ b/drivers/media/platform/qcom/camss/camss-csid-gen3.c
> @@ -103,7 +103,6 @@
> #define CSID_RDI_IRQ_SUBSAMPLE_PERIOD(rdi) (csid_is_lite(csid) && IS_CSID_690(csid) ?\
> (0x34C + 0x100 * (rdi)) :\
> (0x54C + 0x100 * (rdi)))
> -#define CSI2_RX_CFG0_PHY_SEL_BASE_IDX 1
>
> static void __csid_configure_rx(struct csid_device *csid,
> struct csid_phy_config *phy, int vc)
> diff --git a/drivers/media/platform/qcom/camss/camss-csid.h b/drivers/media/platform/qcom/camss/camss-csid.h
> index aedc96ed84b2..b5ceb456a394 100644
> --- a/drivers/media/platform/qcom/camss/camss-csid.h
> +++ b/drivers/media/platform/qcom/camss/camss-csid.h
> @@ -27,8 +27,11 @@
> /* CSID hardware can demultiplex up to 4 outputs */
> #define MSM_CSID_MAX_SRC_STREAMS 4
>
> +/* CSIPHY to hardware PHY selector mapping */
> +#define CSI2_RX_CFG0_PHY_SEL_BASE_IDX 1
> #define CSID_RESET_TIMEOUT_MS 500
>
> +
deadline
> enum csid_testgen_mode {
> CSID_PAYLOAD_MODE_DISABLED = 0,
> CSID_PAYLOAD_MODE_INCREMENTING = 1,
> @@ -154,7 +157,13 @@ struct csid_device {
> void __iomem *base;
> u32 irq;
> char irq_name[30];
> - u32 reg_update;
> + union {
> + u32 reg_update;
> + struct {
> + u32 rup_update;
> + u32 aup_update;
> + };
> + };
Hrmm. This code looks funny..
Leaving the wisdom of a Union aside - I started looking at this code to
see if there was a circumstance where there might be a parallel logical
use.. but would be fine as rup_update and aup_update are contiguous in
the struct but, then I saw this.
drivers/media/platform/qcom/camss/camss-csid-gen3.c: csid->reg_update
&= ~CSID_RUP_AUP_RDI(port_id);
drivers/media/platform/qcom/camss/camss-csid-gen3.c: csid->reg_update
|= CSID_RUP_AUP_RDI(port_id);
and this in your code
λ ~/Development/qualcomm/qlt-kernel/
linux-stable/master-reviews-oct15-25* grep aup_update
drivers/media/platform/qcom/camss/*
drivers/media/platform/qcom/camss/camss-csid-1080.c:static void
__csid_aup_update(struct csid_device *csid, int port_id)
drivers/media/platform/qcom/camss/camss-csid-1080.c: csid->aup_update |=
AUP_RDIN << port_id;
drivers/media/platform/qcom/camss/camss-csid-1080.c:
writel(csid->aup_update, csid->base + CSID_AUP_CMD);
drivers/media/platform/qcom/camss/camss-csid-1080.c:
__csid_aup_update(csid, vc);
drivers/media/platform/qcom/camss/camss-csid-1080.c:
__csid_aup_update(csid, port_id);
drivers/media/platform/qcom/camss/camss-csid.h: u32 aup_update;
λ ~/Development/qualcomm/qlt-kernel/
linux-stable/master-reviews-oct15-25* grep rup_update
drivers/media/platform/qcom/camss/*
drivers/media/platform/qcom/camss/camss-csid-1080.c: csid->rup_update |=
RUP_RDIN << port_id;
drivers/media/platform/qcom/camss/camss-csid-1080.c:
writel(csid->rup_update, csid->base + CSID_RUP_CMD);
drivers/media/platform/qcom/camss/camss-csid.h: u32 rup_update;
All that seems to happen here is bits get set that never get unset in
anyway.
How is that correct ?
---
bod
^ permalink raw reply [flat|nested] 46+ messages in thread* Re: [PATCH v2 5/6] media: qcom: camss: csid: Add support for CSID 1080
2025-10-16 10:04 ` Bryan O'Donoghue
@ 2025-10-16 10:18 ` Bryan O'Donoghue
2025-10-16 22:03 ` Vijay Kumar Tumati
2025-10-16 22:55 ` Vijay Kumar Tumati
1 sibling, 1 reply; 46+ messages in thread
From: Bryan O'Donoghue @ 2025-10-16 10:18 UTC (permalink / raw)
To: Hangxiang Ma, Loic Poulain, Robert Foss, Andi Shyti, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Todor Tomov,
Vladimir Zapolskiy, Mauro Carvalho Chehab
Cc: linux-i2c, linux-arm-msm, devicetree, linux-kernel, linux-media,
aiqun.yu, tingwei.zhang, trilok.soni, yijie.yang, Jingyi Wang,
Atiya Kailany
On 16/10/2025 11:04, Bryan O'Donoghue wrote:
> drivers/media/platform/qcom/camss/camss-csid-gen3.c: csid-
> >reg_update &= ~CSID_RUP_AUP_RDI(port_id);
> drivers/media/platform/qcom/camss/camss-csid-gen3.c: csid-
> >reg_update |= CSID_RUP_AUP_RDI(port_id);
>
> and this in your code
>
>
> λ ~/Development/qualcomm/qlt-kernel/ linux-stable/master-reviews-
> oct15-25* grep aup_update drivers/media/platform/qcom/camss/*
>
> drivers/media/platform/qcom/camss/camss-csid-1080.c:static void
> __csid_aup_update(struct csid_device *csid, int port_id)
> drivers/media/platform/qcom/camss/camss-csid-1080.c: csid->aup_update
> |= AUP_RDIN << port_id;
And now that I see the code side-by-side - also please use the
established macros and/or write a new macro to follow the established
pattern.
There's virtually no good argument to replicate a bit shift or twiddle -
that can be functionally decomposed and encapsulated in one place and
subsequently reused.
---
bod
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: [PATCH v2 5/6] media: qcom: camss: csid: Add support for CSID 1080
2025-10-16 10:18 ` Bryan O'Donoghue
@ 2025-10-16 22:03 ` Vijay Kumar Tumati
0 siblings, 0 replies; 46+ messages in thread
From: Vijay Kumar Tumati @ 2025-10-16 22:03 UTC (permalink / raw)
To: Bryan O'Donoghue, Hangxiang Ma, Loic Poulain, Robert Foss,
Andi Shyti, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Todor Tomov, Vladimir Zapolskiy, Mauro Carvalho Chehab
Cc: linux-i2c, linux-arm-msm, devicetree, linux-kernel, linux-media,
aiqun.yu, tingwei.zhang, trilok.soni, yijie.yang, Jingyi Wang,
Atiya Kailany
On 10/16/2025 3:18 AM, Bryan O'Donoghue wrote:
> On 16/10/2025 11:04, Bryan O'Donoghue wrote:
>> drivers/media/platform/qcom/camss/camss-csid-gen3.c: csid-
>> >reg_update &= ~CSID_RUP_AUP_RDI(port_id);
>> drivers/media/platform/qcom/camss/camss-csid-gen3.c: csid-
>> >reg_update |= CSID_RUP_AUP_RDI(port_id);
>>
>> and this in your code
>>
>>
>> λ ~/Development/qualcomm/qlt-kernel/ linux-stable/master-reviews-
>> oct15-25* grep aup_update drivers/media/platform/qcom/camss/*
>>
>> drivers/media/platform/qcom/camss/camss-csid-1080.c:static void
>> __csid_aup_update(struct csid_device *csid, int port_id)
>> drivers/media/platform/qcom/camss/camss-csid-1080.c: csid->aup_update
>> |= AUP_RDIN << port_id;
>
> And now that I see the code side-by-side - also please use the
> established macros and/or write a new macro to follow the established
> pattern.
>
> There's virtually no good argument to replicate a bit shift or twiddle
> - that can be functionally decomposed and encapsulated in one place
> and subsequently reused.
>
> ---
> bod
>
Hi @Bryan, sure. Both are essentially shift + twiddle, just that in this
patch, both are happening in one place. Where as in gen3, the shift is
happening inside the macro. The other difference is that on Kaanapali,
RUP and AUP update registers are separated and hence need to be handled
separately. But I understand your point about the consistency. We will
modify the 1080 macros to be consistent with gen3. OR we can add two
macros commonly in csid.h that takes both the base bit (RDI0) offset
within those registers and also the port ID to return a value with the
bit set, just that gen3 file will have to call them separately from
within "csid_subdev_reg_update". Please let us know if you would like
this. Thanks.
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: [PATCH v2 5/6] media: qcom: camss: csid: Add support for CSID 1080
2025-10-16 10:04 ` Bryan O'Donoghue
2025-10-16 10:18 ` Bryan O'Donoghue
@ 2025-10-16 22:55 ` Vijay Kumar Tumati
1 sibling, 0 replies; 46+ messages in thread
From: Vijay Kumar Tumati @ 2025-10-16 22:55 UTC (permalink / raw)
To: Bryan O'Donoghue, Hangxiang Ma, Loic Poulain, Robert Foss,
Andi Shyti, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Todor Tomov, Vladimir Zapolskiy, Mauro Carvalho Chehab
Cc: linux-i2c, linux-arm-msm, devicetree, linux-kernel, linux-media,
aiqun.yu, tingwei.zhang, trilok.soni, yijie.yang, Jingyi Wang,
Atiya Kailany
On 10/16/2025 3:04 AM, Bryan O'Donoghue wrote:
> On 15/10/2025 03:56, Hangxiang Ma wrote:
>> Add more detailed resource information for CSID devices along with the
>> driver for CSID 1080 that is responsible for CSID register
>> configuration, module reset and IRQ handling for BUF_DONE events. And
>> aggregate a common definition 'CSI2_RX_CFG0_PHY_SEL_BASE_IDX' into csid
>> header file.
>>
>> In this CSID version, RUP and AUP update values are split into two
>> registers along with a SET register. Accordingly , enhance the CSID
>> interface to accommodate both the legacy combined reg_update and the
>> split RUP and AUP updates.
>>
>> Co-developed-by: Atiya Kailany <atiya.kailany@oss.qualcomm.com>
>> Signed-off-by: Atiya Kailany <atiya.kailany@oss.qualcomm.com>
>> Signed-off-by: Hangxiang Ma <hangxiang.ma@oss.qualcomm.com>
>> ---
>> drivers/media/platform/qcom/camss/Makefile | 1 +
>> .../media/platform/qcom/camss/camss-csid-1080.c | 371
>> +++++++++++++++++++++
>> drivers/media/platform/qcom/camss/camss-csid-680.c | 1 -
>> .../media/platform/qcom/camss/camss-csid-gen3.c | 1 -
>> drivers/media/platform/qcom/camss/camss-csid.h | 12 +-
>> drivers/media/platform/qcom/camss/camss.c | 80 +++++
>> 6 files changed, 463 insertions(+), 3 deletions(-)
>>
>> diff --git a/drivers/media/platform/qcom/camss/Makefile
>> b/drivers/media/platform/qcom/camss/Makefile
>> index 23960d02877d..3a7ed4f5a004 100644
>> --- a/drivers/media/platform/qcom/camss/Makefile
>> +++ b/drivers/media/platform/qcom/camss/Makefile
>> @@ -8,6 +8,7 @@ qcom-camss-objs += \
>> camss-csid-4-7.o \
>> camss-csid-340.o \
>> camss-csid-680.o \
>> + camss-csid-1080.o \
>> camss-csid-gen2.o \
>> camss-csid-gen3.o \
>> camss-csiphy-2ph-1-0.o \
>> diff --git a/drivers/media/platform/qcom/camss/camss-csid-1080.c
>> b/drivers/media/platform/qcom/camss/camss-csid-1080.c
>> new file mode 100644
>> index 000000000000..165fbf1998ed
>> --- /dev/null
>> +++ b/drivers/media/platform/qcom/camss/camss-csid-1080.c
>> @@ -0,0 +1,371 @@
>> +// SPDX-License-Identifier: GPL-2.0
>> +/*
>> + * camss-csid-1080.c
>> + *
>> + * Qualcomm MSM Camera Subsystem - CSID (CSI Decoder) Module
>> + *
>> + * Copyright (c) Qualcomm Technologies, Inc. and/or its subsidiaries.
>> + */
>> +#include <linux/completion.h>
>> +#include <linux/delay.h>
>> +#include <linux/interrupt.h>
>> +#include <linux/io.h>
>> +#include <linux/kernel.h>
>> +#include <linux/of.h>
>> +
>> +#include "camss.h"
>> +#include "camss-csid.h"
>> +#include "camss-csid-gen3.h"
>> +
>> +/* Reset and Command Registers */
>> +#define CSID_RST_CFG 0x108
>> +#define RST_MODE BIT(0)
>> +#define RST_LOCATION BIT(4)
>> +
>> +/* Reset and Command Registers */
>> +#define CSID_RST_CMD 0x10C
>> +#define SELECT_HW_RST BIT(0)
>> +#define SELECT_IRQ_RST BIT(2)
>> +#define CSID_IRQ_CMD 0x110
>> +#define IRQ_CMD_CLEAR BIT(0)
>> +
>> +/* Register Update Commands, RUP/AUP */
>> +#define CSID_RUP_CMD 0x114
>> +#define RUP_RDIN BIT(8)
>> +#define CSID_AUP_CMD 0x118
>> +#define AUP_RDIN BIT(8)
>> +#define CSID_RUP_AUP_CMD 0x11C
>> +#define RUP_SET BIT(0)
>> +#define MUP BIT(4)
>> +
>> +/* Top level interrupt registers */
>> +#define CSID_TOP_IRQ_STATUS 0x180
>> +#define CSID_TOP_IRQ_MASK 0x184
>> +#define CSID_TOP_IRQ_CLEAR 0x188
>> +#define INFO_RST_DONE BIT(0)
>> +#define CSI2_RX_IRQ_STATUS BIT(2)
>> +#define BUF_DONE_IRQ_STATUS BIT(3)
>> +
>> +/* Buffer done interrupt registers */
>> +#define CSID_BUF_DONE_IRQ_STATUS 0x1A0
>> +#define BUF_DONE_IRQ_STATUS_RDI_OFFSET 16
>> +#define CSID_BUF_DONE_IRQ_MASK 0x1A4
>> +#define CSID_BUF_DONE_IRQ_CLEAR 0x1A8
>> +#define CSID_BUF_DONE_IRQ_SET 0x1AC
>> +
>> +/* CSI2 RX interrupt registers */
>> +#define CSID_CSI2_RX_IRQ_STATUS 0x1B0
>> +#define CSID_CSI2_RX_IRQ_MASK 0x1B4
>> +#define CSID_CSI2_RX_IRQ_CLEAR 0x1B8
>> +#define CSID_CSI2_RX_IRQ_SET 0x1BC
>> +
>> +/* CSI2 RX Configuration */
>> +#define CSID_CSI2_RX_CFG0 0x880
>> +#define CSI2_RX_CFG0_NUM_ACTIVE_LANES 0
>> +#define CSI2_RX_CFG0_DL0_INPUT_SEL 4
>> +#define CSI2_RX_CFG0_PHY_NUM_SEL 20
>> +#define CSID_CSI2_RX_CFG1 0x884
>> +#define CSI2_RX_CFG1_ECC_CORRECTION_EN BIT(0)
>> +#define CSI2_RX_CFG1_VC_MODE BIT(2)
>> +
>> +#define MSM_CSID_MAX_SRC_STREAMS_1080 (csid_is_lite(csid) ? 4 : 5)
>> +
>> +/* RDI Configuration */
>> +#define CSID_RDI_CFG0(rdi) \
>> + ((csid_is_lite(csid) ? 0x3080 : 0x5480) + 0x200 * (rdi))
>> +#define RDI_CFG0_RETIME_BS BIT(5)
>> +#define RDI_CFG0_TIMESTAMP_EN BIT(6)
>> +#define RDI_CFG0_TIMESTAMP_STB_SEL BIT(8)
>> +#define RDI_CFG0_DECODE_FORMAT 12
>> +#define RDI_CFG0_DT 16
>> +#define RDI_CFG0_VC 22
>> +#define RDI_CFG0_EN BIT(31)
>> +
>> +/* RDI Control and Configuration */
>> +#define CSID_RDI_CTRL(rdi) \
>> + ((csid_is_lite(csid) ? 0x3088 : 0x5488) + 0x200 * (rdi))
>> +#define RDI_CTRL_START_CMD BIT(0)
>> +
>> +#define CSID_RDI_CFG1(rdi) \
>> + ((csid_is_lite(csid) ? 0x3094 : 0x5494) + 0x200 * (rdi))
>> +#define RDI_CFG1_DROP_H_EN BIT(5)
>> +#define RDI_CFG1_DROP_V_EN BIT(6)
>> +#define RDI_CFG1_CROP_H_EN BIT(7)
>> +#define RDI_CFG1_CROP_V_EN BIT(8)
>> +#define RDI_CFG1_PACKING_FORMAT_MIPI BIT(15)
>> +
>> +/* RDI Pixel Store Configuration */
>> +#define CSID_RDI_PIX_STORE_CFG0(rdi) (0x5498 + 0x200 * (rdi))
>> +#define RDI_PIX_STORE_CFG0_EN BIT(0)
>> +#define RDI_PIX_STORE_CFG0_MIN_HBI 1
>> +
>> +/* RDI IRQ Status in wrapper */
>> +#define CSID_CSI2_RDIN_IRQ_STATUS(rdi) (0x224 + (0x10 * (rdi)))
>> +#define CSID_CSI2_RDIN_IRQ_MASK(rdi) (0x228 + (0x10 *
>> (rdi)))
>> +#define CSID_CSI2_RDIN_IRQ_CLEAR(rdi) (0x22C + (0x10 * (rdi)))
>> +#define INFO_RUP_DONE BIT(23)
>> +
>> +static void __csid_aup_rup_trigger(struct csid_device *csid)
>> +{
>> + /* trigger SET in combined register */
>> + writel(RUP_SET, csid->base + CSID_RUP_AUP_CMD);
>> +}
>> +
>> +static void __csid_aup_update(struct csid_device *csid, int port_id)
>> +{
>> + csid->aup_update |= AUP_RDIN << port_id;
>> + writel(csid->aup_update, csid->base + CSID_AUP_CMD);
>> +
>> + __csid_aup_rup_trigger(csid);
>> +}
>> +
>> +static void __csid_reg_update(struct csid_device *csid, int port_id)
>> +{
>> + csid->rup_update |= RUP_RDIN << port_id;
>> + writel(csid->rup_update, csid->base + CSID_RUP_CMD);
>> +
>> + __csid_aup_rup_trigger(csid);
>> +}
>> +
>> +static void __csid_configure_rx(struct csid_device *csid,
>> + struct csid_phy_config *phy)
>> +{
>> + int val;
>> +
>> + val = (phy->lane_cnt - 1) << CSI2_RX_CFG0_NUM_ACTIVE_LANES;
>> + val |= phy->lane_assign << CSI2_RX_CFG0_DL0_INPUT_SEL;
>> + val |= (phy->csiphy_id + CSI2_RX_CFG0_PHY_SEL_BASE_IDX)
>> + << CSI2_RX_CFG0_PHY_NUM_SEL;
>> + writel(val, csid->base + CSID_CSI2_RX_CFG0);
>> +
>> + val = CSI2_RX_CFG1_ECC_CORRECTION_EN;
>> + writel(val, csid->base + CSID_CSI2_RX_CFG1);
>> +}
>> +
>> +static void __csid_configure_rx_vc(struct csid_device *csid, int vc)
>> +{
>> + int val;
>> +
>> + if (vc > 3) {
>> + val = readl(csid->base + CSID_CSI2_RX_CFG1);
>> + val |= CSI2_RX_CFG1_VC_MODE;
>> + writel(val, csid->base + CSID_CSI2_RX_CFG1);
>> + }
>> +}
>> +
>> +static void __csid_ctrl_rdi(struct csid_device *csid, int enable, u8
>> rdi)
>> +{
>> + int val = 0;
>> +
>> + if (enable)
>> + val = RDI_CTRL_START_CMD;
>> +
>> + writel(val, csid->base + CSID_RDI_CTRL(rdi));
>> +}
>> +
>> +static void __csid_configure_rdi_pix_store(struct csid_device *csid,
>> u8 rdi)
>> +{
>> + u32 val;
>> +
>> + /* Configure pixel store to allow absorption of hblanking or
>> idle time.
>> + * This helps with horizontal crop and prevents line buffer
>> conflicts.
>> + * Reset state is 0x8 which has MIN_HBI=4, we keep the default
>> MIN_HBI
>> + * and just enable the pixel store functionality.
>> + */
>> + val = (4 << RDI_PIX_STORE_CFG0_MIN_HBI) | RDI_PIX_STORE_CFG0_EN;
>> + writel(val, csid->base + CSID_RDI_PIX_STORE_CFG0(rdi));
>> +}
>> +
>> +static void __csid_configure_rdi_stream(struct csid_device *csid, u8
>> enable, u8 vc)
>> +{
>> + u32 val;
>> + u8 lane_cnt = csid->phy.lane_cnt;
>> +
>> + /* Source pads matching RDI channels on hardware.
>> + * E.g. Pad 1 -> RDI0, Pad 2 -> RDI1, etc.
>> + */
>> + struct v4l2_mbus_framefmt *input_format =
>> &csid->fmt[MSM_CSID_PAD_FIRST_SRC + vc];
>> + const struct csid_format_info *format =
>> csid_get_fmt_entry(csid->res->formats->formats,
>> + csid->res->formats->nformats,
>> + input_format->code);
>> +
>> + if (!lane_cnt)
>> + lane_cnt = 4;
>> +
>> + val = RDI_CFG0_TIMESTAMP_EN;
>> + val |= RDI_CFG0_TIMESTAMP_STB_SEL;
>> + val |= RDI_CFG0_RETIME_BS;
>> +
>> + /* note: for non-RDI path, this should be format->decode_format */
>> + val |= DECODE_FORMAT_PAYLOAD_ONLY << RDI_CFG0_DECODE_FORMAT;
>> + val |= vc << RDI_CFG0_VC;
>> + val |= format->data_type << RDI_CFG0_DT;
>> + writel(val, csid->base + CSID_RDI_CFG0(vc));
>> +
>> + val = RDI_CFG1_PACKING_FORMAT_MIPI;
>> + writel(val, csid->base + CSID_RDI_CFG1(vc));
>> +
>> + /* Configure pixel store using dedicated register in 1080 */
>> + if (!csid_is_lite(csid))
>> + __csid_configure_rdi_pix_store(csid, vc);
>> +
>> + val = 0;
>> + writel(val, csid->base + CSID_RDI_CTRL(vc));
>> +
>> + val = readl(csid->base + CSID_RDI_CFG0(vc));
>> +
>> + if (enable)
>> + val |= RDI_CFG0_EN;
>> +
>> + writel(val, csid->base + CSID_RDI_CFG0(vc));
>> +}
>> +
>> +static void csid_configure_stream_1080(struct csid_device *csid, u8
>> enable)
>> +{
>> + u8 i;
>> + u8 vc;
>> +
>> + __csid_configure_rx(csid, &csid->phy);
>> +
>> + for (vc = 0; vc < MSM_CSID_MAX_SRC_STREAMS_1080; vc++) {
>> + if (csid->phy.en_vc & BIT(vc)) {
>> + __csid_configure_rdi_stream(csid, enable, vc);
>> + __csid_configure_rx_vc(csid, vc);
>> +
>> + for (i = 0; i < CAMSS_INIT_BUF_COUNT; i++)
>> + __csid_aup_update(csid, vc);
>> +
>> + __csid_reg_update(csid, vc);
>> +
>> + __csid_ctrl_rdi(csid, enable, vc);
>> + }
>> + }
>> +}
>> +
>> +static int csid_configure_testgen_pattern_1080(struct csid_device
>> *csid,
>> + s32 val)
>> +{
>> + return 0;
>> +}
>> +
>> +static void csid_subdev_reg_update_1080(struct csid_device *csid,
>> int port_id,
>> + bool clear)
>> +{
>> + /* No explicit clear required */
>> + if (!clear)
>> + __csid_aup_update(csid, port_id);
>> +}
>> +
>> +/**
>> + * csid_isr - CSID module interrupt service routine
>> + * @irq: Interrupt line
>> + * @dev: CSID device
>> + *
>> + * Return IRQ_HANDLED on success
>> + */
>> +static irqreturn_t csid_isr_1080(int irq, void *dev)
>> +{
>> + struct csid_device *csid = dev;
>> + u32 val, buf_done_val;
>> + u8 reset_done;
>> + int i;
>> +
>> + val = readl(csid->base + CSID_TOP_IRQ_STATUS);
>> + writel(val, csid->base + CSID_TOP_IRQ_CLEAR);
>> +
>> + reset_done = val & INFO_RST_DONE;
>> +
>> + buf_done_val = readl(csid->base + CSID_BUF_DONE_IRQ_STATUS);
>> + writel(buf_done_val, csid->base + CSID_BUF_DONE_IRQ_CLEAR);
>> +
>> + for (i = 0; i < MSM_CSID_MAX_SRC_STREAMS_1080; i++)
>> + if (csid->phy.en_vc & BIT(i)) {
>> + val = readl(csid->base + CSID_CSI2_RDIN_IRQ_STATUS(i));
>> + writel(val, csid->base + CSID_CSI2_RDIN_IRQ_CLEAR(i));
>> +
>> + if (buf_done_val & BIT(BUF_DONE_IRQ_STATUS_RDI_OFFSET +
>> i)) {
>> + /*
>> + * buf done and RUP IRQ have been moved to CSID from
>> VFE.
>> + * Once CSID received buf done, need notify VFE of this
>> + * event and trigger VFE to handle buf done process.
>> + */
>> + camss_buf_done(csid->camss, csid->id, i);
>> + }
>> + }
>> +
>> + val = IRQ_CMD_CLEAR;
>> + writel(val, csid->base + CSID_IRQ_CMD);
>> +
>> + if (reset_done)
>> + complete(&csid->reset_complete);
>> +
>> + return IRQ_HANDLED;
>> +}
>> +
>> +/**
>> + * csid_reset - Trigger reset on CSID module and wait to complete
>> + * @csid: CSID device
>> + *
>> + * Return 0 on success or a negative error code otherwise
>> + */
>> +static int csid_reset_1080(struct csid_device *csid)
>> +{
>> + unsigned long time;
>> + u32 val;
>> + int i;
>> +
>> + reinit_completion(&csid->reset_complete);
>> +
>> + val = INFO_RST_DONE | BUF_DONE_IRQ_STATUS;
>> + writel(val, csid->base + CSID_TOP_IRQ_CLEAR);
>> + writel(val, csid->base + CSID_TOP_IRQ_MASK);
>> +
>> + val = 0;
>> + for (i = 0; i < MSM_CSID_MAX_SRC_STREAMS_1080; i++) {
>> + if (csid->phy.en_vc & BIT(i)) {
>> + /* Only need to clear Buffer Done IRQ Status here,
>> + * RUP Done IRQ Status will be cleared once isr
>> + * strobe generated by CSID_RST_CMD
>> + */
>> + val |= BIT(BUF_DONE_IRQ_STATUS_RDI_OFFSET + i);
>> + }
>> + }
>> + writel(val, csid->base + CSID_BUF_DONE_IRQ_CLEAR);
>> + writel(val, csid->base + CSID_BUF_DONE_IRQ_MASK);
>> +
>> + /* Clear all IRQ status with CLEAR bits set */
>> + val = IRQ_CMD_CLEAR;
>> + writel(val, csid->base + CSID_IRQ_CMD);
>> +
>> + val = RST_LOCATION | RST_MODE;
>> + writel(val, csid->base + CSID_RST_CFG);
>> +
>> + val = SELECT_HW_RST | SELECT_IRQ_RST;
>> + writel(val, csid->base + CSID_RST_CMD);
>> +
>> + time = wait_for_completion_timeout(&csid->reset_complete,
>> + msecs_to_jiffies(CSID_RESET_TIMEOUT_MS));
>> +
>> + if (!time) {
>> + dev_err(csid->camss->dev, "CSID reset timeout\n");
>> + return -EIO;
>> + }
>> +
>> + return 0;
>> +}
>> +
>> +static void csid_subdev_init_1080(struct csid_device *csid)
>> +{
>> + csid->testgen.nmodes = CSID_PAYLOAD_MODE_DISABLED;
>> +}
>> +
>> +const struct csid_hw_ops csid_ops_1080 = {
>> + .configure_stream = csid_configure_stream_1080,
>> + .configure_testgen_pattern = csid_configure_testgen_pattern_1080,
>> + .hw_version = csid_hw_version,
>> + .isr = csid_isr_1080,
>> + .reset = csid_reset_1080,
>> + .src_pad_code = csid_src_pad_code,
>> + .subdev_init = csid_subdev_init_1080,
>> + .reg_update = csid_subdev_reg_update_1080,
>> +};
>> diff --git a/drivers/media/platform/qcom/camss/camss-csid-680.c
>> b/drivers/media/platform/qcom/camss/camss-csid-680.c
>> index 3ad3a174bcfb..86134a23cd4e 100644
>> --- a/drivers/media/platform/qcom/camss/camss-csid-680.c
>> +++ b/drivers/media/platform/qcom/camss/camss-csid-680.c
>> @@ -101,7 +101,6 @@
>> #define CSI2_RX_CFG0_DL2_INPUT_SEL 12
>> #define CSI2_RX_CFG0_DL3_INPUT_SEL 16
>> #define CSI2_RX_CFG0_PHY_NUM_SEL 20
>> -#define CSI2_RX_CFG0_PHY_SEL_BASE_IDX 1
>> #define CSI2_RX_CFG0_PHY_TYPE_SEL 24
>> #define CSID_CSI2_RX_CFG1 0x204
>> diff --git a/drivers/media/platform/qcom/camss/camss-csid-gen3.c
>> b/drivers/media/platform/qcom/camss/camss-csid-gen3.c
>> index 664245cf6eb0..f09b5575572a 100644
>> --- a/drivers/media/platform/qcom/camss/camss-csid-gen3.c
>> +++ b/drivers/media/platform/qcom/camss/camss-csid-gen3.c
>> @@ -103,7 +103,6 @@
>> #define CSID_RDI_IRQ_SUBSAMPLE_PERIOD(rdi) (csid_is_lite(csid) &&
>> IS_CSID_690(csid) ?\
>> (0x34C + 0x100 * (rdi)) :\
>> (0x54C + 0x100 * (rdi)))
>> -#define CSI2_RX_CFG0_PHY_SEL_BASE_IDX 1
>> static void __csid_configure_rx(struct csid_device *csid,
>> struct csid_phy_config *phy, int vc)
>> diff --git a/drivers/media/platform/qcom/camss/camss-csid.h
>> b/drivers/media/platform/qcom/camss/camss-csid.h
>> index aedc96ed84b2..b5ceb456a394 100644
>> --- a/drivers/media/platform/qcom/camss/camss-csid.h
>> +++ b/drivers/media/platform/qcom/camss/camss-csid.h
>> @@ -27,8 +27,11 @@
>> /* CSID hardware can demultiplex up to 4 outputs */
>> #define MSM_CSID_MAX_SRC_STREAMS 4
>> +/* CSIPHY to hardware PHY selector mapping */
>> +#define CSI2_RX_CFG0_PHY_SEL_BASE_IDX 1
>> #define CSID_RESET_TIMEOUT_MS 500
>> +
>
> deadline
>
>> enum csid_testgen_mode {
>> CSID_PAYLOAD_MODE_DISABLED = 0,
>> CSID_PAYLOAD_MODE_INCREMENTING = 1,
>> @@ -154,7 +157,13 @@ struct csid_device {
>> void __iomem *base;
>> u32 irq;
>> char irq_name[30];
>> - u32 reg_update;
>> + union {
>> + u32 reg_update;
>> + struct {
>> + u32 rup_update;
>> + u32 aup_update;
>> + };
>> + };
>
> Hrmm. This code looks funny..
>
> Leaving the wisdom of a Union aside - I started looking at this code
> to see if there was a circumstance where there might be a parallel
> logical use.. but would be fine as rup_update and aup_update are
> contiguous in the struct but, then I saw this.
>
> drivers/media/platform/qcom/camss/camss-csid-gen3.c: csid->reg_update
> &= ~CSID_RUP_AUP_RDI(port_id);
> drivers/media/platform/qcom/camss/camss-csid-gen3.c: csid->reg_update
> |= CSID_RUP_AUP_RDI(port_id);
>
> and this in your code
>
>
> λ ~/Development/qualcomm/qlt-kernel/
> linux-stable/master-reviews-oct15-25* grep aup_update
> drivers/media/platform/qcom/camss/*
>
> drivers/media/platform/qcom/camss/camss-csid-1080.c:static void
> __csid_aup_update(struct csid_device *csid, int port_id)
> drivers/media/platform/qcom/camss/camss-csid-1080.c: csid->aup_update
> |= AUP_RDIN << port_id;
> drivers/media/platform/qcom/camss/camss-csid-1080.c:
> writel(csid->aup_update, csid->base + CSID_AUP_CMD);
> drivers/media/platform/qcom/camss/camss-csid-1080.c:
> __csid_aup_update(csid, vc);
> drivers/media/platform/qcom/camss/camss-csid-1080.c:
> __csid_aup_update(csid, port_id);
> drivers/media/platform/qcom/camss/camss-csid.h: u32
> aup_update;
>
> λ ~/Development/qualcomm/qlt-kernel/
> linux-stable/master-reviews-oct15-25* grep rup_update
> drivers/media/platform/qcom/camss/*
>
> drivers/media/platform/qcom/camss/camss-csid-1080.c: csid->rup_update
> |= RUP_RDIN << port_id;
> drivers/media/platform/qcom/camss/camss-csid-1080.c:
> writel(csid->rup_update, csid->base + CSID_RUP_CMD);
> drivers/media/platform/qcom/camss/camss-csid.h: u32
> rup_update;
>
> All that seems to happen here is bits get set that never get unset in
> anyway.
>
> How is that correct ?
>
> ---
> bod
>
Actually, I partly agree with you here. Typically, on any architecture,
software is only required to set the SET bits whenever there is a reg
update for a path and the hardware takes care of clearing it after
latching to the updated registers upon the next SOF. The only reason why
we need to maintain a global variable is to make sure that if the
RUP/AUP is set for one path and on another thread, we need to set
RUP/AUP for another path within the same SOF time, if such a concurrency
is supported with camss. The ideal place to clear the global flags is
when RUP done is received but then we need to take care of the race
condition between RUP/AUP set threads and clear threads. I don't see
other drivers are doing that right now. Do you think it is reasonable to
address this across the camss driver in a follow up and dedicated patch
series? The way it is right now, I think there is no functional issue.
Please correct me if I am wrong. Or we can clear the global variables
for a path upon RUP done of that path, to be consistent with other
drivers. Please advise.
^ permalink raw reply [flat|nested] 46+ messages in thread
* [PATCH v2 6/6] media: qcom: camss: vfe: Add support for VFE 1080
2025-10-15 2:56 [PATCH v2 0/6] media: qcom: camss: Add Kaanapali support Hangxiang Ma
` (4 preceding siblings ...)
2025-10-15 2:56 ` [PATCH v2 5/6] media: qcom: camss: csid: Add support for CSID 1080 Hangxiang Ma
@ 2025-10-15 2:56 ` Hangxiang Ma
2025-10-16 10:09 ` Bryan O'Donoghue
5 siblings, 1 reply; 46+ messages in thread
From: Hangxiang Ma @ 2025-10-15 2:56 UTC (permalink / raw)
To: Loic Poulain, Robert Foss, Andi Shyti, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Todor Tomov,
Vladimir Zapolskiy, Mauro Carvalho Chehab, Bryan O'Donoghue
Cc: linux-i2c, linux-arm-msm, devicetree, linux-kernel, linux-media,
aiqun.yu, tingwei.zhang, trilok.soni, yijie.yang, Jingyi Wang,
Atiya Kailany, Hangxiang Ma
Add Video Front End (VFE) version 1080 as found on the Kaanapali SoC.
The FULL front end modules in Kaanapali camera subsystem are called TFEs
(Thin Front End), however, retaining the name VFE at places to maintain
consistency and avoid unnecessary code changes.
This change limits the VFE output lines to 3 for now as constrained by
the CAMSS driver framework.
Co-developed-by: Atiya Kailany <atiya.kailany@oss.qualcomm.com>
Signed-off-by: Atiya Kailany <atiya.kailany@oss.qualcomm.com>
Signed-off-by: Hangxiang Ma <hangxiang.ma@oss.qualcomm.com>
---
drivers/media/platform/qcom/camss/Makefile | 1 +
drivers/media/platform/qcom/camss/camss-vfe-1080.c | 188 +++++++++++++++++++++
drivers/media/platform/qcom/camss/camss-vfe.c | 10 +-
drivers/media/platform/qcom/camss/camss-vfe.h | 2 +
drivers/media/platform/qcom/camss/camss.c | 143 ++++++++++++++++
5 files changed, 342 insertions(+), 2 deletions(-)
diff --git a/drivers/media/platform/qcom/camss/Makefile b/drivers/media/platform/qcom/camss/Makefile
index 3a7ed4f5a004..dc41b0d6dc21 100644
--- a/drivers/media/platform/qcom/camss/Makefile
+++ b/drivers/media/platform/qcom/camss/Makefile
@@ -22,6 +22,7 @@ qcom-camss-objs += \
camss-vfe-340.o \
camss-vfe-480.o \
camss-vfe-680.o \
+ camss-vfe-1080.o \
camss-vfe-gen3.o \
camss-vfe-gen1.o \
camss-vfe.o \
diff --git a/drivers/media/platform/qcom/camss/camss-vfe-1080.c b/drivers/media/platform/qcom/camss/camss-vfe-1080.c
new file mode 100644
index 000000000000..5637e85a7786
--- /dev/null
+++ b/drivers/media/platform/qcom/camss/camss-vfe-1080.c
@@ -0,0 +1,188 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * camss-vfe-1080.c
+ *
+ * Qualcomm MSM Camera Subsystem - VFE (Video Front End) Module v1080
+ *
+ * Copyright (c) Qualcomm Technologies, Inc. and/or its subsidiaries.
+ */
+#include <linux/interrupt.h>
+#include <linux/io.h>
+#include <linux/iopoll.h>
+
+#include "camss.h"
+#include "camss-vfe.h"
+
+/* VFE-1080 Bus Register Base Addresses */
+#define BUS_REG_BASE (vfe_is_lite(vfe) ? 0x800 : 0x1000)
+
+#define VFE_BUS_WM_CGC_OVERRIDE (BUS_REG_BASE + 0x08)
+#define WM_CGC_OVERRIDE_ALL (0x7FFFFFF)
+
+#define VFE_BUS_WM_TEST_BUS_CTRL (BUS_REG_BASE + 0x128)
+
+#define VFE_BUS_WM_CFG(n) (BUS_REG_BASE + 0x500 + (n) * 0x100)
+#define WM_CFG_EN BIT(0)
+#define WM_VIR_FRM_EN BIT(1)
+#define WM_CFG_MODE BIT(16)
+#define VFE_BUS_WM_IMAGE_ADDR(n) (BUS_REG_BASE + 0x504 + (n) * 0x100)
+#define VFE_BUS_WM_FRAME_INCR(n) (BUS_REG_BASE + 0x508 + (n) * 0x100)
+#define VFE_BUS_WM_IMAGE_CFG_0(n) (BUS_REG_BASE + 0x50c + (n) * 0x100)
+#define WM_IMAGE_CFG_0_DEFAULT_WIDTH (0xFFFF)
+#define VFE_BUS_WM_IMAGE_CFG_2(n) (BUS_REG_BASE + 0x514 + (n) * 0x100)
+#define WM_IMAGE_CFG_2_DEFAULT_STRIDE (0xFFFF)
+#define VFE_BUS_WM_PACKER_CFG(n) (BUS_REG_BASE + 0x518 + (n) * 0x100)
+
+#define VFE_BUS_WM_IRQ_SUBSAMPLE_PERIOD(n) (BUS_REG_BASE + 0x530 + (n) * 0x100)
+#define VFE_BUS_WM_IRQ_SUBSAMPLE_PATTERN(n) (BUS_REG_BASE + 0x534 + (n) * 0x100)
+
+/* VFE lite has no such registers */
+#define VFE_BUS_WM_FRAMEDROP_PERIOD(n) (BUS_REG_BASE + 0x538 + (n) * 0x100)
+#define VFE_BUS_WM_FRAMEDROP_PATTERN(n) (BUS_REG_BASE + 0x53c + (n) * 0x100)
+
+#define VFE_BUS_WM_MMU_PREFETCH_CFG(n) (BUS_REG_BASE + 0x560 + (n) * 0x100)
+#define VFE_BUS_WM_MMU_PREFETCH_MAX_OFFSET(n) (BUS_REG_BASE + 0x564 + (n) * 0x100)
+
+/*
+ * IFE write master client IDs
+ *
+ * VIDEO_FULL 0
+ * VIDEO_DC4_Y 1
+ * VIDEO_DC4_C 2
+ * VIDEO_DC16_Y 3
+ * VIDEO_DC16_C 4
+ * DISPLAY_DS2_Y 5
+ * DISPLAY_DS2_C 6
+ * FD_Y 7
+ * FD_C 8
+ * PIXEL_RAW 9
+ * STATS_AEC_BG 10
+ * STATS_AEC_BHIST 11
+ * STATS_TINTLESS_BG 12
+ * STATS_AWB_BG 13
+ * STATS_AWB_BFW 14
+ * STATS_AF_BHIST 15
+ * STATS_ALSC_BG 16
+ * STATS_FLICKER_BAYERRS 17
+ * STATS_TMC_BHIST 18
+ * PDAF_0 19
+ * PDAF_1 20
+ * PDAF_2 21
+ * PDAF_3 22
+ * RDI0 23
+ * RDI1 24
+ * RDI2 25
+ * RDI3 26
+ * RDI4 27
+ *
+ * IFE Lite write master client IDs
+ *
+ * RDI0 0
+ * RDI1 1
+ * RDI2 2
+ * RDI3 3
+ * GAMMA 4
+ * STATES_BE 5
+ */
+#define RDI_WM(n) ((vfe_is_lite(vfe) ? 0x0 : 0x17) + (n))
+
+static void vfe_wm_start_1080(struct vfe_device *vfe, u8 wm, struct vfe_line *line)
+{
+ struct v4l2_pix_format_mplane *pix =
+ &line->video_out.active_fmt.fmt.pix_mp;
+
+ wm = RDI_WM(wm);
+
+ /* no clock gating at bus input */
+ writel(WM_CGC_OVERRIDE_ALL, vfe->base + VFE_BUS_WM_CGC_OVERRIDE);
+
+ writel(0x0, vfe->base + VFE_BUS_WM_TEST_BUS_CTRL);
+
+ writel(ALIGN(pix->plane_fmt[0].bytesperline, 16) * pix->height >> 8,
+ vfe->base + VFE_BUS_WM_FRAME_INCR(wm));
+ writel((WM_IMAGE_CFG_0_DEFAULT_WIDTH & 0xFFFF),
+ vfe->base + VFE_BUS_WM_IMAGE_CFG_0(wm));
+ writel(WM_IMAGE_CFG_2_DEFAULT_STRIDE,
+ vfe->base + VFE_BUS_WM_IMAGE_CFG_2(wm));
+ writel(0, vfe->base + VFE_BUS_WM_PACKER_CFG(wm));
+
+ /* no dropped frames, one irq per frame */
+ if (!vfe_is_lite(vfe)) {
+ writel(0, vfe->base + VFE_BUS_WM_FRAMEDROP_PERIOD(wm));
+ writel(1, vfe->base + VFE_BUS_WM_FRAMEDROP_PATTERN(wm));
+ }
+
+ writel(0, vfe->base + VFE_BUS_WM_IRQ_SUBSAMPLE_PERIOD(wm));
+ writel(1, vfe->base + VFE_BUS_WM_IRQ_SUBSAMPLE_PATTERN(wm));
+
+ writel(1, vfe->base + VFE_BUS_WM_MMU_PREFETCH_CFG(wm));
+ writel(0xFFFFFFFF, vfe->base + VFE_BUS_WM_MMU_PREFETCH_MAX_OFFSET(wm));
+
+ writel(WM_CFG_EN | WM_CFG_MODE, vfe->base + VFE_BUS_WM_CFG(wm));
+}
+
+static void vfe_wm_stop_1080(struct vfe_device *vfe, u8 wm)
+{
+ wm = RDI_WM(wm);
+ writel(0, vfe->base + VFE_BUS_WM_CFG(wm));
+}
+
+static void vfe_wm_update_1080(struct vfe_device *vfe, u8 wm, u32 addr,
+ struct vfe_line *line)
+{
+ wm = RDI_WM(wm);
+ writel((addr >> 8) & 0xFFFFFFFF, vfe->base + VFE_BUS_WM_IMAGE_ADDR(wm));
+
+ dev_dbg(vfe->camss->dev, "wm:%d, image buf addr:0x%x\n", wm, addr);
+}
+
+static void vfe_reg_update_1080(struct vfe_device *vfe, enum vfe_line_id line_id)
+{
+ int port_id = line_id;
+
+ camss_reg_update(vfe->camss, vfe->id, port_id, false);
+}
+
+static const struct camss_video_ops vfe_video_ops_1080 = {
+ .queue_buffer = vfe_queue_buffer_v2,
+ .flush_buffers = vfe_flush_buffers,
+};
+
+static void vfe_subdev_init_1080(struct device *dev, struct vfe_device *vfe)
+{
+ vfe->video_ops = vfe_video_ops_1080;
+}
+
+static void vfe_global_reset_1080(struct vfe_device *vfe)
+{
+ vfe_isr_reset_ack(vfe);
+}
+
+static irqreturn_t vfe_isr_1080(int irq, void *dev)
+{
+ /* nop */
+ return IRQ_HANDLED;
+}
+
+static int vfe_halt_1080(struct vfe_device *vfe)
+{
+ /* rely on vfe_disable_output() to stop the VFE */
+ return 0;
+}
+
+const struct vfe_hw_ops vfe_ops_1080 = {
+ .global_reset = vfe_global_reset_1080,
+ .hw_version = vfe_hw_version,
+ .isr = vfe_isr_1080,
+ .pm_domain_off = vfe_pm_domain_off,
+ .pm_domain_on = vfe_pm_domain_on,
+ .reg_update = vfe_reg_update_1080,
+ .subdev_init = vfe_subdev_init_1080,
+ .vfe_disable = vfe_disable,
+ .vfe_enable = vfe_enable_v2,
+ .vfe_halt = vfe_halt_1080,
+ .vfe_wm_start = vfe_wm_start_1080,
+ .vfe_wm_stop = vfe_wm_stop_1080,
+ .vfe_buf_done = vfe_buf_done,
+ .vfe_wm_update = vfe_wm_update_1080,
+};
diff --git a/drivers/media/platform/qcom/camss/camss-vfe.c b/drivers/media/platform/qcom/camss/camss-vfe.c
index 2753c2bb6c04..0084a1a1e71d 100644
--- a/drivers/media/platform/qcom/camss/camss-vfe.c
+++ b/drivers/media/platform/qcom/camss/camss-vfe.c
@@ -349,6 +349,7 @@ static u32 vfe_src_pad_code(struct vfe_line *line, u32 sink_code,
case CAMSS_845:
case CAMSS_8550:
case CAMSS_8775P:
+ case CAMSS_KAANAPALI:
case CAMSS_X1E80100:
switch (sink_code) {
case MEDIA_BUS_FMT_YUYV8_1X16:
@@ -521,7 +522,8 @@ int vfe_enable_output_v2(struct vfe_line *line)
spin_lock_irqsave(&vfe->output_lock, flags);
- ops->reg_update_clear(vfe, line->id);
+ if (ops->reg_update_clear)
+ ops->reg_update_clear(vfe, line->id);
if (output->state > VFE_OUTPUT_RESERVED) {
dev_err(vfe->camss->dev,
@@ -548,7 +550,10 @@ int vfe_enable_output_v2(struct vfe_line *line)
output->gen2.active_num++;
ops->vfe_wm_update(vfe, output->wm_idx[0],
output->buf[i]->addr[0], line);
- ops->reg_update(vfe, line->id);
+
+ /* Deferring the reg update until after CSID config */
+ if (!vfe->camss->res->vfe_res[vfe->id].vfe.is_deferred)
+ ops->reg_update(vfe, line->id);
}
spin_unlock_irqrestore(&vfe->output_lock, flags);
@@ -1998,6 +2003,7 @@ static int vfe_bpl_align(struct vfe_device *vfe)
case CAMSS_845:
case CAMSS_8550:
case CAMSS_8775P:
+ case CAMSS_KAANAPALI:
case CAMSS_X1E80100:
ret = 16;
break;
diff --git a/drivers/media/platform/qcom/camss/camss-vfe.h b/drivers/media/platform/qcom/camss/camss-vfe.h
index 0300efdb1c46..47851362edd4 100644
--- a/drivers/media/platform/qcom/camss/camss-vfe.h
+++ b/drivers/media/platform/qcom/camss/camss-vfe.h
@@ -133,6 +133,7 @@ struct vfe_isr_ops {
struct vfe_subdev_resources {
bool is_lite;
+ bool is_deferred;
u8 line_num;
bool has_pd;
char *pd_name;
@@ -245,6 +246,7 @@ extern const struct vfe_hw_ops vfe_ops_170;
extern const struct vfe_hw_ops vfe_ops_340;
extern const struct vfe_hw_ops vfe_ops_480;
extern const struct vfe_hw_ops vfe_ops_680;
+extern const struct vfe_hw_ops vfe_ops_1080;
extern const struct vfe_hw_ops vfe_ops_gen3;
int vfe_get(struct vfe_device *vfe);
diff --git a/drivers/media/platform/qcom/camss/camss.c b/drivers/media/platform/qcom/camss/camss.c
index 74a8ad3cb728..033fdaaff7f5 100644
--- a/drivers/media/platform/qcom/camss/camss.c
+++ b/drivers/media/platform/qcom/camss/camss.c
@@ -217,6 +217,147 @@ static const struct camss_subdev_resources csid_res_kaanapali[] = {
}
};
+/* In Kaanapali, CAMNOC requires all CAMNOC_RT_TFEX clocks
+ * to operate on any TFE Full.
+ */
+static const struct camss_subdev_resources vfe_res_kaanapali[] = {
+ /* VFE0 - TFE Full */
+ {
+ .regulators = {},
+ .clock = { "gcc_hf_axi", "vfe0_fast_ahb", "vfe0",
+ "camnoc_rt_vfe0", "camnoc_rt_vfe1", "camnoc_rt_vfe2",
+ "camnoc_rt_axi", "camnoc_nrt_axi", "qdss_debug_xo" },
+ .clock_rate = { { 0 },
+ { 0 },
+ { 360280000, 480000000, 630000000, 716000000,
+ 833000000 },
+ { 0 },
+ { 0 },
+ { 0 },
+ { 200000000, 300000000, 400000000, 480000000 },
+ { 0 },
+ { 0 } },
+ .reg = { "vfe0" },
+ .interrupt = { "vfe0" },
+ .vfe = {
+ .line_num = 3,
+ .is_lite = false,
+ .is_deferred = true,
+ .has_pd = true,
+ .pd_name = "tfe0",
+ .hw_ops = &vfe_ops_1080,
+ .formats_rdi = &vfe_formats_rdi_845,
+ .formats_pix = &vfe_formats_pix_845
+ }
+ },
+ /* VFE1 - TFE Full */
+ {
+ .regulators = {},
+ .clock = { "gcc_hf_axi", "vfe1_fast_ahb", "vfe1",
+ "camnoc_rt_vfe0", "camnoc_rt_vfe1", "camnoc_rt_vfe2",
+ "camnoc_rt_axi", "camnoc_nrt_axi", "qdss_debug_xo" },
+ .clock_rate = { { 0 },
+ { 0 },
+ { 360280000, 480000000, 630000000, 716000000,
+ 833000000 },
+ { 0 },
+ { 0 },
+ { 0 },
+ { 200000000, 300000000, 400000000, 480000000 },
+ { 0 },
+ { 0 } },
+ .reg = { "vfe1" },
+ .interrupt = { "vfe1" },
+ .vfe = {
+ .line_num = 3,
+ .is_lite = false,
+ .is_deferred = true,
+ .has_pd = true,
+ .pd_name = "tfe1",
+ .hw_ops = &vfe_ops_1080,
+ .formats_rdi = &vfe_formats_rdi_845,
+ .formats_pix = &vfe_formats_pix_845
+ }
+ },
+ /* VFE2 - TFE Full */
+ {
+ .regulators = {},
+ .clock = { "gcc_hf_axi", "vfe2_fast_ahb", "vfe2",
+ "camnoc_rt_vfe0", "camnoc_rt_vfe1", "camnoc_rt_vfe2",
+ "camnoc_rt_axi", "camnoc_nrt_axi", "qdss_debug_xo" },
+ .clock_rate = { { 0 },
+ { 0 },
+ { 360280000, 480000000, 630000000, 716000000,
+ 833000000 },
+ { 0 },
+ { 0 },
+ { 0 },
+ { 200000000, 300000000, 400000000, 480000000 },
+ { 0 },
+ { 0 } },
+ .reg = { "vfe2" },
+ .interrupt = { "vfe2" },
+ .vfe = {
+ .line_num = 3,
+ .is_lite = false,
+ .is_deferred = true,
+ .has_pd = true,
+ .pd_name = "tfe2",
+ .hw_ops = &vfe_ops_1080,
+ .formats_rdi = &vfe_formats_rdi_845,
+ .formats_pix = &vfe_formats_pix_845
+ }
+ },
+ /* VFE3 - IFE Lite */
+ {
+ .regulators = {},
+ .clock = { "gcc_hf_axi", "vfe_lite_ahb", "vfe_lite",
+ "camnoc_rt_vfe_lite", "camnoc_rt_axi",
+ "camnoc_nrt_axi", "qdss_debug_xo" },
+ .clock_rate = { { 0 },
+ { 0 },
+ { 266666667, 400000000, 480000000 },
+ { 0 },
+ { 200000000, 300000000, 400000000, 480000000 },
+ { 0 },
+ { 0 } },
+ .reg = { "vfe_lite0" },
+ .interrupt = { "vfe_lite0" },
+ .vfe = {
+ .line_num = 4,
+ .is_lite = true,
+ .is_deferred = true,
+ .hw_ops = &vfe_ops_1080,
+ .formats_rdi = &vfe_formats_rdi_845,
+ .formats_pix = &vfe_formats_pix_845
+ }
+ },
+ /* VFE4 - IFE Lite */
+ {
+ .regulators = {},
+ .clock = { "gcc_hf_axi", "vfe_lite_ahb", "vfe_lite",
+ "camnoc_rt_vfe_lite", "camnoc_rt_axi",
+ "camnoc_nrt_axi", "qdss_debug_xo" },
+ .clock_rate = { { 0 },
+ { 0 },
+ { 266666667, 400000000, 480000000 },
+ { 0 },
+ { 200000000, 300000000, 400000000, 480000000 },
+ { 0 },
+ { 0 } },
+ .reg = { "vfe_lite1" },
+ .interrupt = { "vfe_lite1" },
+ .vfe = {
+ .line_num = 4,
+ .is_lite = true,
+ .is_deferred = true,
+ .hw_ops = &vfe_ops_1080,
+ .formats_rdi = &vfe_formats_rdi_845,
+ .formats_pix = &vfe_formats_pix_845
+ }
+ },
+};
+
static const struct resources_icc icc_res_kaanapali[] = {
/* Based on 4096 x 3072 30 FPS 2496 Mbps mode */
{
@@ -4493,10 +4634,12 @@ static const struct camss_resources kaanapali_resources = {
.pd_name = "top",
.csiphy_res = csiphy_res_kaanapali,
.csid_res = csid_res_kaanapali,
+ .vfe_res = vfe_res_kaanapali,
.icc_res = icc_res_kaanapali,
.icc_path_num = ARRAY_SIZE(icc_res_kaanapali),
.csiphy_num = ARRAY_SIZE(csiphy_res_kaanapali),
.csid_num = ARRAY_SIZE(csid_res_kaanapali),
+ .vfe_num = ARRAY_SIZE(vfe_res_kaanapali),
};
static const struct camss_resources msm8916_resources = {
--
2.34.1
^ permalink raw reply related [flat|nested] 46+ messages in thread* Re: [PATCH v2 6/6] media: qcom: camss: vfe: Add support for VFE 1080
2025-10-15 2:56 ` [PATCH v2 6/6] media: qcom: camss: vfe: Add support for VFE 1080 Hangxiang Ma
@ 2025-10-16 10:09 ` Bryan O'Donoghue
2025-10-16 10:33 ` Hangxiang Ma
0 siblings, 1 reply; 46+ messages in thread
From: Bryan O'Donoghue @ 2025-10-16 10:09 UTC (permalink / raw)
To: Hangxiang Ma, Loic Poulain, Robert Foss, Andi Shyti, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Todor Tomov,
Vladimir Zapolskiy, Mauro Carvalho Chehab
Cc: linux-i2c, linux-arm-msm, devicetree, linux-kernel, linux-media,
aiqun.yu, tingwei.zhang, trilok.soni, yijie.yang, Jingyi Wang,
Atiya Kailany
On 15/10/2025 03:56, Hangxiang Ma wrote:
> +
> + /* Deferring the reg update until after CSID config */
> + if (!vfe->camss->res->vfe_res[vfe->id].vfe.is_deferred)
> + ops->reg_update(vfe, line->id);
> }
But why ?
---
bod
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: [PATCH v2 6/6] media: qcom: camss: vfe: Add support for VFE 1080
2025-10-16 10:09 ` Bryan O'Donoghue
@ 2025-10-16 10:33 ` Hangxiang Ma
2025-10-16 10:54 ` Bryan O'Donoghue
0 siblings, 1 reply; 46+ messages in thread
From: Hangxiang Ma @ 2025-10-16 10:33 UTC (permalink / raw)
To: Bryan O'Donoghue, Loic Poulain, Robert Foss, Andi Shyti,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Todor Tomov,
Vladimir Zapolskiy, Mauro Carvalho Chehab
Cc: linux-i2c, linux-arm-msm, devicetree, linux-kernel, linux-media,
aiqun.yu, tingwei.zhang, trilok.soni, yijie.yang, Jingyi Wang,
Atiya Kailany
On 10/16/2025 6:09 PM, Bryan O'Donoghue wrote:
> On 15/10/2025 03:56, Hangxiang Ma wrote:
>> +
>> + /* Deferring the reg update until after CSID config */
>> + if (!vfe->camss->res->vfe_res[vfe->id].vfe.is_deferred)
>> + ops->reg_update(vfe, line->id);
>> }
>
> But why ?
>
> ---
> bod
That a story. When testing the RDI path on Kaanapali, we found one image
buffer starved at 19/20 stage. We want to capture 20 images but only 19
received.
On Kaanapali, the AUP and RUP are split into two separate registers not
a single one. Maybe this hardware change impacts something. Calling
ops->reg_update() in vfe_enable_output_v2 function only applies one
buffer address. The downstream code defers AUP and RUP to CSID
configuration stage. We mimic that and find it can solve this issue.
---
Hangxiang
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: [PATCH v2 6/6] media: qcom: camss: vfe: Add support for VFE 1080
2025-10-16 10:33 ` Hangxiang Ma
@ 2025-10-16 10:54 ` Bryan O'Donoghue
2025-10-16 23:28 ` Vijay Kumar Tumati
0 siblings, 1 reply; 46+ messages in thread
From: Bryan O'Donoghue @ 2025-10-16 10:54 UTC (permalink / raw)
To: Hangxiang Ma, Loic Poulain, Robert Foss, Andi Shyti, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Todor Tomov,
Vladimir Zapolskiy, Mauro Carvalho Chehab
Cc: linux-i2c, linux-arm-msm, devicetree, linux-kernel, linux-media,
aiqun.yu, tingwei.zhang, trilok.soni, yijie.yang, Jingyi Wang,
Atiya Kailany
On 16/10/2025 11:33, Hangxiang Ma wrote:
>> But why ?
>>
>> ---
>> bod
> That a story. When testing the RDI path on Kaanapali, we found one image
> buffer starved at 19/20 stage. We want to capture 20 images but only 19
> received.
>
> On Kaanapali, the AUP and RUP are split into two separate registers not
> a single one. Maybe this hardware change impacts something. Calling
> ops->reg_update() in vfe_enable_output_v2 function only applies one
> buffer address. The downstream code defers AUP and RUP to CSID
> configuration stage. We mimic that and find it can solve this issue.
>
> ---
> Hangxiang
So this is the type of interesting detail that I'd go looking for in a
commit log, a comment in the code or a footnote in the cover letter.
One or two sentences in the commit log will do.
---
bod
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: [PATCH v2 6/6] media: qcom: camss: vfe: Add support for VFE 1080
2025-10-16 10:54 ` Bryan O'Donoghue
@ 2025-10-16 23:28 ` Vijay Kumar Tumati
0 siblings, 0 replies; 46+ messages in thread
From: Vijay Kumar Tumati @ 2025-10-16 23:28 UTC (permalink / raw)
To: Bryan O'Donoghue, Hangxiang Ma, Loic Poulain, Robert Foss,
Andi Shyti, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Todor Tomov, Vladimir Zapolskiy, Mauro Carvalho Chehab
Cc: linux-i2c, linux-arm-msm, devicetree, linux-kernel, linux-media,
aiqun.yu, tingwei.zhang, trilok.soni, yijie.yang, Jingyi Wang,
Atiya Kailany
On 10/16/2025 3:54 AM, Bryan O'Donoghue wrote:
> On 16/10/2025 11:33, Hangxiang Ma wrote:
>>> But why ?
>>>
>>> ---
>>> bod
>> That a story. When testing the RDI path on Kaanapali, we found one image
>> buffer starved at 19/20 stage. We want to capture 20 images but only 19
>> received.
>>
>> On Kaanapali, the AUP and RUP are split into two separate registers not
>> a single one. Maybe this hardware change impacts something. Calling
>> ops->reg_update() in vfe_enable_output_v2 function only applies one
>> buffer address. The downstream code defers AUP and RUP to CSID
>> configuration stage. We mimic that and find it can solve this issue.
>>
>> ---
>> Hangxiang
>
> So this is the type of interesting detail that I'd go looking for in a
> commit log, a comment in the code or a footnote in the cover letter.
>
> One or two sentences in the commit log will do.
>
> ---
> bod
>
@Bryan, let me throw a bit more light here. I don't think the 19/20
buffers issue or the AUP-RUP register separation has anything to do
about this (at least not the first for sure). Fundamentally, on
Kaanapali architecture (or any architecture for that matter), the HW
guidance is to issue the reg_update (corresponding register write) after
all of the CSID configuration registers are written. It had always been
working for other chip sets to write to this register first and then
write the CSID registers but Kaanapali seems to have very strict
dependency in the hardware about this sequence and with the original
sequence, no RUP DONE or BUF DONE events are received at all. Hence the
need for this change. The 19/20 buffer issue that Hangxiang mentioned
about is a follow up of this where we enqueue two buffers to the RDI
write master from 'vfe_enable_output_v2()' but issue only one AUP update
after the CSID config. That was when we needed to add
'CAMSS_INIT_BUF_COUNT' and use consistently at both places. Hope this
makes sense now. Please let us know if you have any questions still.
Thank you.
^ permalink raw reply [flat|nested] 46+ messages in thread