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

From: Nihal Kumar Gupta

Date: Wed Nov 04 2026 - 11:11:44 EST




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@xxxxxxxxxxxxxxxx>
>> ---
>> 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@xxxxxxxxxx/

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

>> { }
>> };

--
Regards,
Nihal Kumar Gupta