[PATCH 0/2] media: qcom: camss: Use Glymur graph ports as CSIPHY IDs

[PATCH 0/2] media: qcom: camss: Use Glymur graph ports as CSIPHY IDs

[Nihal Kumar Gupta]

This follows up on the discussion around Glymur using standalone CSI2 PHY
nodes instead of the CAMSS CSIPHY resource table.

Glymur currently reuses the X1E80100 CAMSS resources. That works for
CSIPHY4 only because the X1E80100 resource table maps resource entry 3 to
CSIPHY id 4. After dropping the X1E80100 CSIPHY resource table, the
standalone PHY path uses the graph port number as the CSIPHY id, so
CSIPHY4 must be described as port@4.

Update the Glymur binding to allow ports 0, 1 and 4, then add
Glymur-specific CAMSS resources without reusing the X1E80100 CSIPHY
resource table.

Discussion:
https://lore.kernel.org/all/CAFEp6-23L+4+yzVxX815ZA2x1_tN8SpzL7ciNcb9b+gBT67AdQ@mail.gmail.com/

Depends-on: https://lore.kernel.org/all/20261026224957.1115370-1-vz@kernel.org/

Signed-off-by: Nihal Kumar Gupta <nihal.gupta@oss.qualcomm.com>
---
Nihal Kumar Gupta (2):
      dt-bindings: media: qcom,glymur-camss: Use CSIPHY indices for ports
      media: qcom: camss: Add Glymur specific resources

 .../devicetree/bindings/media/qcom,glymur-camss.yaml    |  6 +++---
 drivers/media/platform/qcom/camss/camss.c               | 17 ++++++++++++++++-
 2 files changed, 19 insertions(+), 4 deletions(-)
---
base-commit: 7649ba73f9e7e1e04d0b46213e39c79ae09dd55c
change-id: 20261102-glymur_camss-1cf83f4a447f

Best regards,
-- 
Nihal Kumar Gupta <nihal.gupta@oss.qualcomm.com>

[PATCH 1/2] dt-bindings: media: qcom,glymur-camss: Use CSIPHY indices for ports

[Nihal Kumar Gupta]

Glymur describes CSI2 PHYs as standalone nodes, but the CAMSS binding
still models CSIPHY4 as port@3 from the X1E80100 csiphy_res[] layout,
where entry 3 carried CSIPHY id 4.

Describe the hardware connection directly by allowing ports 0, 1 and 4,
and using port@4 for CSIPHY4.

Signed-off-by: Nihal Kumar Gupta <nihal.gupta@oss.qualcomm.com>
---
 Documentation/devicetree/bindings/media/qcom,glymur-camss.yaml | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/Documentation/devicetree/bindings/media/qcom,glymur-camss.yaml b/Documentation/devicetree/bindings/media/qcom,glymur-camss.yaml
index a0b77edc212319fad69113f3d55ca24f184d4b23..e23f43dfa4b51c1e44e57f31dc22b4312476365c 100644
--- a/Documentation/devicetree/bindings/media/qcom,glymur-camss.yaml
+++ b/Documentation/devicetree/bindings/media/qcom,glymur-camss.yaml
@@ -109,7 +109,7 @@ properties:
       CSI input ports.
 
     patternProperties:
-      "^port@[0-3]$":
+      "^port@[014]$":
         $ref: /schemas/graph.yaml#/$defs/port-base
         unevaluatedProperties: false
 
@@ -288,8 +288,8 @@ examples:
                     };
                 };
 
-                port@3 {
-                    reg = <3>;
+                port@4 {
+                    reg = <4>;
                     camss_csiphy4_ep: endpoint {
                         data-lanes = <1 2 3 4>;
                         remote-endpoint = <&csiphy4_out>;

-- 
2.34.1

[PATCH 2/2] media: qcom: camss: Add Glymur specific resources

[Nihal Kumar Gupta]

Glymur uses the X1E80100 CAMSS resources, but its CSI2 PHYs are
described as standalone PHY nodes. Reusing the X1E80100 resources also
reuses csiphy_res[], where port@3 maps to CSIPHY id 4.

Add Glymur resource data without reusing the X1E80100 CSIPHY resource
table, so the standalone PHY path uses the graph port number as the
CSIPHY id.

Signed-off-by: Nihal Kumar Gupta <nihal.gupta@oss.qualcomm.com>
---
 drivers/media/platform/qcom/camss/camss.c | 17 ++++++++++++++++-
 1 file changed, 16 insertions(+), 1 deletion(-)

diff --git a/drivers/media/platform/qcom/camss/camss.c b/drivers/media/platform/qcom/camss/camss.c
index 1db66976e51b81edeb223cebb6bbe84995d102c2..4f705a056eedbc7b09d2630ee6284b8d768cc6d5 100644
--- a/drivers/media/platform/qcom/camss/camss.c
+++ b/drivers/media/platform/qcom/camss/camss.c
@@ -5800,6 +5800,21 @@ static void camss_remove(struct platform_device *pdev)
 	camss_genpd_cleanup(camss);
 }
 
+static const struct camss_resources glymur_resources = {
+	.version = CAMSS_X1E80100,
+	.pd_name = "top",
+	.tpg_res = tpg_res_x1e80100,
+	.csid_res = csid_res_x1e80100,
+	.vfe_res = vfe_res_x1e80100,
+	.csid_wrapper_res = &csid_wrapper_res_x1e80100,
+	.icc_res = icc_res_x1e80100,
+	.icc_path_num = ARRAY_SIZE(icc_res_x1e80100),
+	.csiphy_num = 5,
+	.tpg_num = ARRAY_SIZE(tpg_res_x1e80100),
+	.csid_num = ARRAY_SIZE(csid_res_x1e80100),
+	.vfe_num = ARRAY_SIZE(vfe_res_x1e80100),
+};
+
 static const struct camss_resources msm8916_resources = {
 	.version = CAMSS_8x16,
 	.csiphy_res = csiphy_res_8x16,
@@ -6049,6 +6064,7 @@ static const struct camss_resources x1e80100_resources = {
 };
 
 static const struct of_device_id camss_dt_match[] = {
+	{ .compatible = "qcom,glymur-camss", .data = &glymur_resources },
 	{ .compatible = "qcom,msm8916-camss", .data = &msm8916_resources },
 	{ .compatible = "qcom,msm8939-camss", .data = &msm8939_resources },
 	{ .compatible = "qcom,msm8953-camss", .data = &msm8953_resources },
@@ -6068,7 +6084,6 @@ static const struct of_device_id camss_dt_match[] = {
 	{ .compatible = "qcom,sm8550-camss", .data = &sm8550_resources },
 	{ .compatible = "qcom,sm8650-camss", .data = &sm8650_resources },
 	{ .compatible = "qcom,x1e80100-camss", .data = &x1e80100_resources },
-	{ .compatible = "qcom,glymur-camss", .data = &x1e80100_resources },
 	{ }
 };
 

-- 
2.34.1

Re: [PATCH 1/2] dt-bindings: media: qcom,glymur-camss: Use CSIPHY indices for ports

[Krzysztof Kozlowski]

On Mon, Nov 02, 2026 at 02:20:57PM +0530, Nihal Kumar Gupta wrote:
> Glymur describes CSI2 PHYs as standalone nodes, but the CAMSS binding
> still models CSIPHY4 as port@3 from the X1E80100 csiphy_res[] layout,
> where entry 3 carried CSIPHY id 4.

You also remove port 2 without explanation.


> 
> Describe the hardware connection directly by allowing ports 0, 1 and 4,
> and using port@4 for CSIPHY4.

All this is confusing, why do you introduce gaps? What is the reason?
Your datasheet naming does not matter.

Best regards,
Krzysztof

Re: [PATCH 2/2] media: qcom: camss: Add Glymur specific resources

[Krzysztof Kozlowski]

On Mon, Nov 02, 2026 at 02:20:58PM +0530, Nihal Kumar Gupta wrote:
> Glymur uses the X1E80100 CAMSS resources, but its CSI2 PHYs are
> described as standalone PHY nodes. Reusing the X1E80100 resources also
> reuses csiphy_res[], where port@3 maps to CSIPHY id 4.
> 
> Add Glymur resource data without reusing the X1E80100 CSIPHY resource
> table, so the standalone PHY path uses the graph port number as the
> CSIPHY id.
> 
> Signed-off-by: Nihal Kumar Gupta <nihal.gupta@oss.qualcomm.com>
> ---
>  drivers/media/platform/qcom/camss/camss.c | 17 ++++++++++++++++-
>  1 file changed, 16 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/media/platform/qcom/camss/camss.c b/drivers/media/platform/qcom/camss/camss.c
> index 1db66976e51b81edeb223cebb6bbe84995d102c2..4f705a056eedbc7b09d2630ee6284b8d768cc6d5 100644
> --- a/drivers/media/platform/qcom/camss/camss.c
> +++ b/drivers/media/platform/qcom/camss/camss.c
> @@ -5800,6 +5800,21 @@ static void camss_remove(struct platform_device *pdev)
>  	camss_genpd_cleanup(camss);
>  }
>  
> +static const struct camss_resources glymur_resources = {
> +	.version = CAMSS_X1E80100,
> +	.pd_name = "top",
> +	.tpg_res = tpg_res_x1e80100,
> +	.csid_res = csid_res_x1e80100,
> +	.vfe_res = vfe_res_x1e80100,
> +	.csid_wrapper_res = &csid_wrapper_res_x1e80100,
> +	.icc_res = icc_res_x1e80100,
> +	.icc_path_num = ARRAY_SIZE(icc_res_x1e80100),
> +	.csiphy_num = 5,

5? Your binding said three... Confusing.

> +	.tpg_num = ARRAY_SIZE(tpg_res_x1e80100),
> +	.csid_num = ARRAY_SIZE(csid_res_x1e80100),
> +	.vfe_num = ARRAY_SIZE(vfe_res_x1e80100),
> +};
> +
>  static const struct camss_resources msm8916_resources = {
>  	.version = CAMSS_8x16,
>  	.csiphy_res = csiphy_res_8x16,
> @@ -6049,6 +6064,7 @@ static const struct camss_resources x1e80100_resources = {
>  };
>  
>  static const struct of_device_id camss_dt_match[] = {
> +	{ .compatible = "qcom,glymur-camss", .data = &glymur_resources },
>  	{ .compatible = "qcom,msm8916-camss", .data = &msm8916_resources },
>  	{ .compatible = "qcom,msm8939-camss", .data = &msm8939_resources },
>  	{ .compatible = "qcom,msm8953-camss", .data = &msm8953_resources },
> @@ -6068,7 +6084,6 @@ static const struct of_device_id camss_dt_match[] = {
>  	{ .compatible = "qcom,sm8550-camss", .data = &sm8550_resources },
>  	{ .compatible = "qcom,sm8650-camss", .data = &sm8650_resources },
>  	{ .compatible = "qcom,x1e80100-camss", .data = &x1e80100_resources },
> -	{ .compatible = "qcom,glymur-camss", .data = &x1e80100_resources },

Why do you keep breaking the order...

>  	{ }
>  };
>  
> 
> -- 
> 2.34.1
> 

Re: [PATCH 1/2] dt-bindings: media: qcom,glymur-camss: Use CSIPHY indices for ports

[Nihal Kumar Gupta]

On 04-11-2026 19:22, Krzysztof Kozlowski wrote:
>> Glymur describes CSI2 PHYs as standalone nodes, but the CAMSS binding
>> still models CSIPHY4 as port@3 from the X1E80100 csiphy_res[] layout,
>> where entry 3 carried CSIPHY id 4.
> You also remove port 2 without explanation.
> 
> 
>> Describe the hardware connection directly by allowing ports 0, 1 and 4,
>> and using port@4 for CSIPHY4.
> All this is confusing, why do you introduce gaps? What is the reason?
> Your datasheet naming does not matter.

Glymur CAMSS has populated inputs for CSIPHY0, CSIPHY1 and CSIPHY4, so I
used a sparse pattern for those ports only.

That is confusing for the schema. I will allow the continuous range
port@0 through port@4 and keep the example limited to the populated
Glymur ports.

-- 
Regards,
Nihal Kumar Gupta

Re: [PATCH 2/2] media: qcom: camss: Add Glymur specific resources

[Nihal Kumar Gupta]

On 04-11-2026 19:24, Krzysztof Kozlowski wrote:
>> Glymur uses the X1E80100 CAMSS resources, but its CSI2 PHYs are
>> described as standalone PHY nodes. Reusing the X1E80100 resources also
>> reuses csiphy_res[], where port@3 maps to CSIPHY id 4.
>>
>> Add Glymur resource data without reusing the X1E80100 CSIPHY resource
>> table, so the standalone PHY path uses the graph port number as the
>> CSIPHY id.
>>
>> Signed-off-by: Nihal Kumar Gupta <nihal.gupta@oss.qualcomm.com>
>> ---
>>  drivers/media/platform/qcom/camss/camss.c | 17 ++++++++++++++++-
>>  1 file changed, 16 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/media/platform/qcom/camss/camss.c b/drivers/media/platform/qcom/camss/camss.c
>> index 1db66976e51b81edeb223cebb6bbe84995d102c2..4f705a056eedbc7b09d2630ee6284b8d768cc6d5 100644
>> --- a/drivers/media/platform/qcom/camss/camss.c
>> +++ b/drivers/media/platform/qcom/camss/camss.c
>> @@ -5800,6 +5800,21 @@ static void camss_remove(struct platform_device *pdev)
>>  	camss_genpd_cleanup(camss);
>>  }
>>  
>> +static const struct camss_resources glymur_resources = {
>> +	.version = CAMSS_X1E80100,
>> +	.pd_name = "top",
>> +	.tpg_res = tpg_res_x1e80100,
>> +	.csid_res = csid_res_x1e80100,
>> +	.vfe_res = vfe_res_x1e80100,
>> +	.csid_wrapper_res = &csid_wrapper_res_x1e80100,
>> +	.icc_res = icc_res_x1e80100,
>> +	.icc_path_num = ARRAY_SIZE(icc_res_x1e80100),
>> +	.csiphy_num = 5,
> 5? Your binding said three... Confusing.
> 

csiphy_num = 5 is needed to cover from port@0 to port@4; it is not
meant to describe three populated links.

>> +	.tpg_num = ARRAY_SIZE(tpg_res_x1e80100),
>> +	.csid_num = ARRAY_SIZE(csid_res_x1e80100),
>> +	.vfe_num = ARRAY_SIZE(vfe_res_x1e80100),
>> +};
>> +
>>  static const struct camss_resources msm8916_resources = {
>>  	.version = CAMSS_8x16,
>>  	.csiphy_res = csiphy_res_8x16,
>> @@ -6049,6 +6064,7 @@ static const struct camss_resources x1e80100_resources = {
>>  };
>>  
>>  static const struct of_device_id camss_dt_match[] = {
>> +	{ .compatible = "qcom,glymur-camss", .data = &glymur_resources },
>>  	{ .compatible = "qcom,msm8916-camss", .data = &msm8916_resources },
>>  	{ .compatible = "qcom,msm8939-camss", .data = &msm8939_resources },
>>  	{ .compatible = "qcom,msm8953-camss", .data = &msm8953_resources },
>> @@ -6068,7 +6084,6 @@ static const struct of_device_id camss_dt_match[] = {
>>  	{ .compatible = "qcom,sm8550-camss", .data = &sm8550_resources },
>>  	{ .compatible = "qcom,sm8650-camss", .data = &sm8650_resources },
>>  	{ .compatible = "qcom,x1e80100-camss", .data = &x1e80100_resources },
>> -	{ .compatible = "qcom,glymur-camss", .data = &x1e80100_resources },
> Why do you keep breaking the order...
> 

I placed qcom,glymur-camss there to keep the match table alphabetically
ordered, following Bryan's earlier comment about Glymur/Hawi ordering:

https://lore.kernel.org/all/23845ad3-dedd-4e24-803b-5abf3b030c4a@kernel.org/

I can move it before qcom,x1e80100-camss or keep at same place if that is preferred.

>>  	{ }
>>  };

-- 
Regards,
Nihal Kumar Gupta

Re: [PATCH 1/2] dt-bindings: media: qcom,glymur-camss: Use CSIPHY indices for ports

[Krzysztof Kozlowski]

On 04/11/2026 17:00, Nihal Kumar Gupta wrote:
> 
> 
> On 04-11-2026 19:22, Krzysztof Kozlowski wrote:
>>> Glymur describes CSI2 PHYs as standalone nodes, but the CAMSS binding
>>> still models CSIPHY4 as port@3 from the X1E80100 csiphy_res[] layout,
>>> where entry 3 carried CSIPHY id 4.
>> You also remove port 2 without explanation.
>>
>>
>>> Describe the hardware connection directly by allowing ports 0, 1 and 4,
>>> and using port@4 for CSIPHY4.
>> All this is confusing, why do you introduce gaps? What is the reason?
>> Your datasheet naming does not matter.
> 
> Glymur CAMSS has populated inputs for CSIPHY0, CSIPHY1 and CSIPHY4, so I
> used a sparse pattern for those ports only.

port@0 is CSIPHY0
port@1 is CSIPHY1
port@2 is CSIPHY4

What is the problem exactly you are solving?

> 
> That is confusing for the schema. I will allow the continuous range
> port@0 through port@4 and keep the example limited to the populated
> Glymur ports.
> 


Best regards,
Krzysztof

Re: [PATCH 1/2] dt-bindings: media: qcom,glymur-camss: Use CSIPHY indices for ports

[Nihal Kumar Gupta]

On 04-11-2026 21:42, Krzysztof Kozlowski wrote:
>>>> Glymur describes CSI2 PHYs as standalone nodes, but the CAMSS binding
>>>> still models CSIPHY4 as port@3 from the X1E80100 csiphy_res[] layout,
>>>> where entry 3 carried CSIPHY id 4.
>>> You also remove port 2 without explanation.
>>>
>>>
>>>> Describe the hardware connection directly by allowing ports 0, 1 and 4,
>>>> and using port@4 for CSIPHY4.
>>> All this is confusing, why do you introduce gaps? What is the reason?
>>> Your datasheet naming does not matter.
>> Glymur CAMSS has populated inputs for CSIPHY0, CSIPHY1 and CSIPHY4, so I
>> used a sparse pattern for those ports only.
> port@0 is CSIPHY0
> port@1 is CSIPHY1
> port@2 is CSIPHY4
> 
> What is the problem exactly you are solving?
> 

The problem is that CSIPHY4 is connected to CAMSS interface 4, so the
graph should describe it as port@4, not port@2.

The previous port@3 description only worked through the X1E80100 resource
table indirection:

  port@3 -> csiphy_res[3] -> .csiphy.id = 4 -> CSID selects CSIPHY4

New standalone PHY path:
  port@4 -> no csiphy_res[] lookup -> port number is id 4 -> CSID selects CSIPHY4

>> That is confusing for the schema. I will allow the continuous range
>> port@0 through port@4 and keep the example limited to the populated
>> Glymur ports.

-- 
Regards,
Nihal Kumar Gupta

Re: [PATCH 1/2] dt-bindings: media: qcom,glymur-camss: Use CSIPHY indices for ports

[Krzysztof Kozlowski]

On 05/11/2026 06:32, Nihal Kumar Gupta wrote:
>>
>> What is the problem exactly you are solving?
>>
> 
> The problem is that CSIPHY4 is connected to CAMSS interface 4, so the
> graph should describe it as port@4, not port@2.

Nothing like this is explained in commit msg.

> 
> The previous port@3 description only worked through the X1E80100 resource
> table indirection:
> 
>   port@3 -> csiphy_res[3] -> .csiphy.id = 4 -> CSID selects CSIPHY4
> 
> New standalone PHY path:
>   port@4 -> no csiphy_res[] lookup -> port number is id 4 -> CSID selects CSIPHY4

Then this breaks existing users, no? Anyway, what stops you from having
there proper mapping?

Did you find any existing practice of numbering ports logical numbering
in this device, but some other logic coming from datasheet? Where?


Best regards,
Krzysztof

Re: [PATCH 1/2] dt-bindings: media: qcom,glymur-camss: Use CSIPHY indices for ports

[Nihal Kumar Gupta]

On 05-11-2026 13:03, Krzysztof Kozlowski wrote:
>>> What is the problem exactly you are solving?
>>>
>> The problem is that CSIPHY4 is connected to CAMSS interface 4, so the
>> graph should describe it as port@4, not port@2.
> Nothing like this is explained in commit msg.
> 
I will update commit message to explain it better.

>> The previous port@3 description only worked through the X1E80100 resource
>> table indirection:
>>
>>   port@3 -> csiphy_res[3] -> .csiphy.id = 4 -> CSID selects CSIPHY4
>>
>> New standalone PHY path:
>>   port@4 -> no csiphy_res[] lookup -> port number is id 4 -> CSID selects CSIPHY4
> Then this breaks existing users, no? Anyway, what stops you from having
> there proper mapping?
> 
No existing upstream user should break here; this is still part of the Glymur
CAMSS enablement.

This follows the earlier discussion that CSIPHY4 should use the
CAMSS-side interface index as its graph port number:

https://lore.kernel.org/all/CAFEp6-23L+4+yzVxX815ZA2x1_tN8SpzL7ciNcb9b+gBT67AdQ@mail.gmail.com/

> Did you find any existing practice of numbering ports logical numbering
> in this device, but some other logic coming from datasheet? Where?
> 

Glymur has only CSIPHY0, CSIPHY1 and CSIPHY4; CSIPHY2 and CSIPHY3 are not
present on the SoC. 

Using port@2 for CSIPHY4 would require a Glymur-specific port-to-CSIPHY mapping.
port@4 describes the CAMSS input directly and avoids introducing separate logical
numbering for Glymur.

-- 
Regards,
Nihal Kumar Gupta

Re: [PATCH 1/2] dt-bindings: media: qcom,glymur-camss: Use CSIPHY indices for ports

[Krzysztof Kozlowski]

On 05/11/2026 10:18, Nihal Kumar Gupta wrote:
> 
> 
> On 05-11-2026 13:03, Krzysztof Kozlowski wrote:
>>>> What is the problem exactly you are solving?
>>>>
>>> The problem is that CSIPHY4 is connected to CAMSS interface 4, so the
>>> graph should describe it as port@4, not port@2.
>> Nothing like this is explained in commit msg.
>>
> I will update commit message to explain it better.
> 
>>> The previous port@3 description only worked through the X1E80100 resource
>>> table indirection:
>>>
>>>   port@3 -> csiphy_res[3] -> .csiphy.id = 4 -> CSID selects CSIPHY4
>>>
>>> New standalone PHY path:
>>>   port@4 -> no csiphy_res[] lookup -> port number is id 4 -> CSID selects CSIPHY4
>> Then this breaks existing users, no? Anyway, what stops you from having
>> there proper mapping?
>>
> No existing upstream user should break here; this is still part of the Glymur
> CAMSS enablement.
> 
> This follows the earlier discussion that CSIPHY4 should use the
> CAMSS-side interface index as its graph port number:
> 
> https://lore.kernel.org/all/CAFEp6-23L+4+yzVxX815ZA2x1_tN8SpzL7ciNcb9b+gBT67AdQ@mail.gmail.com/

Should use? Since when? Do you have DT maintainers ack on that?

> 
>> Did you find any existing practice of numbering ports logical numbering
>> in this device, but some other logic coming from datasheet? Where?
>>
> 
> Glymur has only CSIPHY0, CSIPHY1 and CSIPHY4; CSIPHY2 and CSIPHY3 are not
> present on the SoC. 

Then CSIPHY4 is basically the third (so @2 counting from 0) input port,
no? Not fifth.

> 
> Using port@2 for CSIPHY4 would require a Glymur-specific port-to-CSIPHY mapping.
> port@4 describes the CAMSS input directly and avoids introducing separate logical
> numbering for Glymur.

Seems you opened a new can of worms, so this needs proper justification.
Again, do you see any recent preexisting DT review which would help to
convince me? I know I usually ask not to use poor existing code as
reason to do the same, but here I actually want to see proofs of current
accepted practice.


Best regards,
Krzysztof

Re: [PATCH 1/2] dt-bindings: media: qcom,glymur-camss: Use CSIPHY indices for ports

[Loic Poulain]

On Thu, Nov 5, 2026 at 10:23 AM Krzysztof Kozlowski <krzk@kernel.org> wrote:
>
> On 05/11/2026 10:18, Nihal Kumar Gupta wrote:
> >
> >
> > On 05-11-2026 13:03, Krzysztof Kozlowski wrote:
> >>>> What is the problem exactly you are solving?
> >>>>
> >>> The problem is that CSIPHY4 is connected to CAMSS interface 4, so the
> >>> graph should describe it as port@4, not port@2.
> >> Nothing like this is explained in commit msg.
> >>
> > I will update commit message to explain it better.
> >
> >>> The previous port@3 description only worked through the X1E80100 resource
> >>> table indirection:
> >>>
> >>>   port@3 -> csiphy_res[3] -> .csiphy.id = 4 -> CSID selects CSIPHY4
> >>>
> >>> New standalone PHY path:
> >>>   port@4 -> no csiphy_res[] lookup -> port number is id 4 -> CSID selects CSIPHY4
> >> Then this breaks existing users, no? Anyway, what stops you from having
> >> there proper mapping?
> >>
> > No existing upstream user should break here; this is still part of the Glymur
> > CAMSS enablement.
> >
> > This follows the earlier discussion that CSIPHY4 should use the
> > CAMSS-side interface index as its graph port number:
> >
> > https://lore.kernel.org/all/CAFEp6-23L+4+yzVxX815ZA2x1_tN8SpzL7ciNcb9b+gBT67AdQ@mail.gmail.com/
>
> Should use? Since when? Do you have DT maintainers ack on that?
>
> >
> >> Did you find any existing practice of numbering ports logical numbering
> >> in this device, but some other logic coming from datasheet? Where?
> >>
> >
> > Glymur has only CSIPHY0, CSIPHY1 and CSIPHY4; CSIPHY2 and CSIPHY3 are not
> > present on the SoC.
>
> Then CSIPHY4 is basically the third (so @2 counting from 0) input port,
> no? Not fifth.
> >
> > Using port@2 for CSIPHY4 would require a Glymur-specific port-to-CSIPHY mapping.
> > port@4 describes the CAMSS input directly and avoids introducing separate logical
> > numbering for Glymur.
>
> Seems you opened a new can of worms, so this needs proper justification.
> Again, do you see any recent preexisting DT review which would help to
> convince me? I know I usually ask not to use poor existing code as
> reason to do the same, but here I actually want to see proofs of current
> accepted practice.

So some chipsets share the same IP blocks, with some block/phy
instances disabled. As a result, we need to decide whether we're
numbering based on active instances or on the actual hardware instance
index/offset. If we use active-instance numbering, then yes, it should
be @2 (CSIPHY4 being the third active instance). Alternatively, if the
port numbering is intended to reflect the hardware instance offset,
matching the register prop, then @4 would be more appropriate. It also
has the advantage of directly identifying the underlying hardware
instance, without requiring any additional driver-side mapping. In any
case, @3 is incorrect.

That said, since the bindings have already been merged in its current
form, we'll need to preserve backward compatibility when addressing
this.

Regards,
Loic

Re: [PATCH 1/2] dt-bindings: media: qcom,glymur-camss: Use CSIPHY indices for ports

[Bryan O'Donoghue]

On 05/11/2026 09:53, Loic Poulain wrote:
> On Thu, Nov 5, 2026 at 10:23 AM Krzysztof Kozlowski <krzk@kernel.org> wrote:
>>
>> On 05/11/2026 10:18, Nihal Kumar Gupta wrote:
>>>
>>>
>>> On 05-11-2026 13:03, Krzysztof Kozlowski wrote:
>>>>>> What is the problem exactly you are solving?
>>>>>>
>>>>> The problem is that CSIPHY4 is connected to CAMSS interface 4, so the
>>>>> graph should describe it as port@4, not port@2.
>>>> Nothing like this is explained in commit msg.
>>>>
>>> I will update commit message to explain it better.
>>>
>>>>> The previous port@3 description only worked through the X1E80100 resource
>>>>> table indirection:
>>>>>
>>>>>    port@3 -> csiphy_res[3] -> .csiphy.id = 4 -> CSID selects CSIPHY4
>>>>>
>>>>> New standalone PHY path:
>>>>>    port@4 -> no csiphy_res[] lookup -> port number is id 4 -> CSID selects CSIPHY4
>>>> Then this breaks existing users, no? Anyway, what stops you from having
>>>> there proper mapping?
>>>>
>>> No existing upstream user should break here; this is still part of the Glymur
>>> CAMSS enablement.
>>>
>>> This follows the earlier discussion that CSIPHY4 should use the
>>> CAMSS-side interface index as its graph port number:
>>>
>>> https://lore.kernel.org/all/CAFEp6-23L+4+yzVxX815ZA2x1_tN8SpzL7ciNcb9b+gBT67AdQ@mail.gmail.com/
>>
>> Should use? Since when? Do you have DT maintainers ack on that?
>>
>>>
>>>> Did you find any existing practice of numbering ports logical numbering
>>>> in this device, but some other logic coming from datasheet? Where?
>>>>
>>>
>>> Glymur has only CSIPHY0, CSIPHY1 and CSIPHY4; CSIPHY2 and CSIPHY3 are not
>>> present on the SoC.
>>
>> Then CSIPHY4 is basically the third (so @2 counting from 0) input port,
>> no? Not fifth.
>>>
>>> Using port@2 for CSIPHY4 would require a Glymur-specific port-to-CSIPHY mapping.
>>> port@4 describes the CAMSS input directly and avoids introducing separate logical
>>> numbering for Glymur.
>>
>> Seems you opened a new can of worms, so this needs proper justification.
>> Again, do you see any recent preexisting DT review which would help to
>> convince me? I know I usually ask not to use poor existing code as
>> reason to do the same, but here I actually want to see proofs of current
>> accepted practice.
> 
> So some chipsets share the same IP blocks, with some block/phy
> instances disabled. As a result, we need to decide whether we're
> numbering based on active instances or on the actual hardware instance
> index/offset. If we use active-instance numbering, then yes, it should
> be @2 (CSIPHY4 being the third active instance). Alternatively, if the
> port numbering is intended to reflect the hardware instance offset,
> matching the register prop, then @4 would be more appropriate. It also
> has the advantage of directly identifying the underlying hardware
> instance, without requiring any additional driver-side mapping. In any
> case, @3 is incorrect.
> 
> That said, since the bindings have already been merged in its current
> form, we'll need to preserve backward compatibility when addressing
> this.
> 
> Regards,
> Loic

Without reading this long thread - Hamoa hardware IDs are {0, 1, 2, 4} 
so Glymur is either like that or not please check yourselves.

I think Nihal says Glymur as 2 and 3 missing so suggest hardware numbers 
scheme follows established Hamoa scheme.

---
bod

Re: [PATCH 1/2] dt-bindings: media: qcom,glymur-camss: Use CSIPHY indices for ports

[Krzysztof Kozlowski]

On 05/11/2026 10:53, Loic Poulain wrote:
> So some chipsets share the same IP blocks, with some block/phy
> instances disabled. As a result, we need to decide whether we're
> numbering based on active instances or on the actual hardware instance
> index/offset. If we use active-instance numbering, then yes, it should
> be @2 (CSIPHY4 being the third active instance). Alternatively, if the
> port numbering is intended to reflect the hardware instance offset,
> matching the register prop, then @4 would be more appropriate. It also
> has the advantage of directly identifying the underlying hardware
> instance, without requiring any additional driver-side mapping. In any
> case, @3 is incorrect.
> 
> That said, since the bindings have already been merged in its current
> form, we'll need to preserve backward compatibility when addressing
> this.

This is the input port to camss, so how is it called in camss, not the
csi phy?


Best regards,
Krzysztof

Re: [PATCH 1/2] dt-bindings: media: qcom,glymur-camss: Use CSIPHY indices for ports

[Bryan O'Donoghue]

On 05/11/2026 10:45, Krzysztof Kozlowski wrote:
> On 05/11/2026 10:53, Loic Poulain wrote:
>> So some chipsets share the same IP blocks, with some block/phy
>> instances disabled. As a result, we need to decide whether we're
>> numbering based on active instances or on the actual hardware instance
>> index/offset. If we use active-instance numbering, then yes, it should
>> be @2 (CSIPHY4 being the third active instance). Alternatively, if the
>> port numbering is intended to reflect the hardware instance offset,
>> matching the register prop, then @4 would be more appropriate. It also
>> has the advantage of directly identifying the underlying hardware
>> instance, without requiring any additional driver-side mapping. In any
>> case, @3 is incorrect.
>>
>> That said, since the bindings have already been merged in its current
>> form, we'll need to preserve backward compatibility when addressing
>> this.
> 
> This is the input port to camss, so how is it called in camss, not the
> csi phy?
> 
> 
> Best regards,
> Krzysztof

When you have legacy PHYs the port number indicates the PHY - this has 
been the case since 2015.

With standalone PHYs the port number just means "input data port here" 
with no specific hardware mapping

Which to me implies the correct port numbering for systems which have a 
standalone PHY is {0, 1, 2}

On hamoa which supports both legacy and new we have to stick to the old 
way of {0, 1, 2, 4}

Since any PHY can mux to any CSI decoder the old port scheme should IMO 
be dropped for new standalone PHY DTs.

Not sure what to do about Glymur since the example is upstream already.

---
bod

Re: [PATCH 1/2] dt-bindings: media: qcom,glymur-camss: Use CSIPHY indices for ports

[Loic Poulain]

On Thu, Nov 5, 2026 at 11:45 AM Krzysztof Kozlowski <krzk@kernel.org> wrote:
>
> On 05/11/2026 10:53, Loic Poulain wrote:
> > So some chipsets share the same IP blocks, with some block/phy
> > instances disabled. As a result, we need to decide whether we're
> > numbering based on active instances or on the actual hardware instance
> > index/offset. If we use active-instance numbering, then yes, it should
> > be @2 (CSIPHY4 being the third active instance). Alternatively, if the
> > port numbering is intended to reflect the hardware instance offset,
> > matching the register prop, then @4 would be more appropriate. It also
> > has the advantage of directly identifying the underlying hardware
> > instance, without requiring any additional driver-side mapping. In any
> > case, @3 is incorrect.
> >
> > That said, since the bindings have already been merged in its current
> > form, we'll need to preserve backward compatibility when addressing
> > this.
>
> This is the input port to camss, so how is it called in camss, not the
> csi phy?

The CSIPHYs are connected to the CAMSS input ports, which can then be
multiplexed and routed to different CSIDs. The mux identifies its PHY
inputs using the hardware PHY IDs, so the CSIPHY4 is identified as the
CAMSS PHY4 input. In this configuration, PHY2 and PHY3 inputs are not
connected.

Regards,
Loic

Re: [PATCH 1/2] dt-bindings: media: qcom,glymur-camss: Use CSIPHY indices for ports

[Krzysztof Kozlowski]

On 05/11/2026 13:04, Loic Poulain wrote:
> On Thu, Nov 5, 2026 at 11:45 AM Krzysztof Kozlowski <krzk@kernel.org> wrote:
>>
>> On 05/11/2026 10:53, Loic Poulain wrote:
>>> So some chipsets share the same IP blocks, with some block/phy
>>> instances disabled. As a result, we need to decide whether we're
>>> numbering based on active instances or on the actual hardware instance
>>> index/offset. If we use active-instance numbering, then yes, it should
>>> be @2 (CSIPHY4 being the third active instance). Alternatively, if the
>>> port numbering is intended to reflect the hardware instance offset,
>>> matching the register prop, then @4 would be more appropriate. It also
>>> has the advantage of directly identifying the underlying hardware
>>> instance, without requiring any additional driver-side mapping. In any
>>> case, @3 is incorrect.
>>>
>>> That said, since the bindings have already been merged in its current
>>> form, we'll need to preserve backward compatibility when addressing
>>> this.
>>
>> This is the input port to camss, so how is it called in camss, not the
>> csi phy?
> 
> The CSIPHYs are connected to the CAMSS input ports, which can then be
> multiplexed and routed to different CSIDs. The mux identifies its PHY
> inputs using the hardware PHY IDs, so the CSIPHY4 is identified as the
> CAMSS PHY4 input. In this configuration, PHY2 and PHY3 inputs are not
> connected.

I could not find that information in Glymur HPG, but maybe I looked
wrong. CSID Wrapper lists CSID 0-2, not 0, 1 and 4, but again maybe I am
looking at wrong device description/interface...

Best regards,
Krzysztof

Re: [PATCH 1/2] dt-bindings: media: qcom,glymur-camss: Use CSIPHY indices for ports

[Loic Poulain]

On Thu, Nov 5, 2026 at 2:21 PM Krzysztof Kozlowski <krzk@kernel.org> wrote:
>
> On 05/11/2026 13:04, Loic Poulain wrote:
> > On Thu, Nov 5, 2026 at 11:45 AM Krzysztof Kozlowski <krzk@kernel.org> wrote:
> >>
> >> On 05/11/2026 10:53, Loic Poulain wrote:
> >>> So some chipsets share the same IP blocks, with some block/phy
> >>> instances disabled. As a result, we need to decide whether we're
> >>> numbering based on active instances or on the actual hardware instance
> >>> index/offset. If we use active-instance numbering, then yes, it should
> >>> be @2 (CSIPHY4 being the third active instance). Alternatively, if the
> >>> port numbering is intended to reflect the hardware instance offset,
> >>> matching the register prop, then @4 would be more appropriate. It also
> >>> has the advantage of directly identifying the underlying hardware
> >>> instance, without requiring any additional driver-side mapping. In any
> >>> case, @3 is incorrect.
> >>>
> >>> That said, since the bindings have already been merged in its current
> >>> form, we'll need to preserve backward compatibility when addressing
> >>> this.
> >>
> >> This is the input port to camss, so how is it called in camss, not the
> >> csi phy?
> >
> > The CSIPHYs are connected to the CAMSS input ports, which can then be
> > multiplexed and routed to different CSIDs. The mux identifies its PHY
> > inputs using the hardware PHY IDs, so the CSIPHY4 is identified as the
> > CAMSS PHY4 input. In this configuration, PHY2 and PHY3 inputs are not
> > connected.
>
> I could not find that information in Glymur HPG, but maybe I looked
> wrong. CSID Wrapper lists CSID 0-2, not 0, 1 and 4, but again maybe I am
> looking at wrong device description/interface...

Yes, there are three CSIDs (CSID0-2) and two CSID_LITEs
(CSID_LITE0-1). These blocks select the PHY source to be routed by
programming their PHY ID (PHY ID = PHY index + 1), as defined by the
PHY_NUM_SEL field in CSI2_RX_CFG0.

If the CAMSS port ID matches the PHY index, the port ID can be used
directly as a routing reference, which keeps the implementation
straightforward.

Alternatively, exposing logical port IDs such as { 0, 1, 2 } also
makes sense. In that case, the driver would simply maintain an
internal mapping table, for example mapping DT/logical ports { 0, 1, 2
} to PHY indices { 0, 1, 4 }. As long as we establish and document the
convention, either approach should work fine.

Today, the Glymur bindings define DT ports { 0, 1, 3 } to map to PHY
indices { 0, 1, 4 }. One could argue that this is already an
established convention, as it is documented in the bindings. However,
it is somewhat confusing.

Regards,
Loic