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

[Nihal Kumar Gupta <nihal.gupta@oss.qualcomm.com>]

On 09-11-2026 11:35, Nihal Kumar Gupta wrote:
>> So yes, we could argue that the port ID itself has no inherent
>> meaning, but it acquires meaning through the convention we define,
>> since we still need a way to map DT ports to CAMSS input IDs. What is
>> really changing here is the convention used to describe that mapping.
>> So, for Hamoa, ports { 0, 1, 2, 3 } would map to CAMSS PHY inputs { 0,
>> 1, 2, 4 }, while for Glymur, ports { 0, 1, 2 } would map to CAMSS PHY
>> inputs { 0, 1, 4 }.
>>
> Thanks Loic, Bryan, Krzysztof and Vladimir for the discussion.
> 
> Krzysztof, understood on the DT binding concern. I should have got clear DT
> maintainer agreement before proposing a binding semantic change, and I will
> keep that in mind for future changes.
> 
> Based on the discussion, I agree that for standalone PHY CAMSS DT input ports
> should be logical and linear. For Glymur, that means using ports@0-2 { 0, 1, 2 },
> and keep the mapping to hardware PHY indices { 0, 1, 4 } inside the driver.
> 
> Krzysztof, does this direction sound aligned to you? If yes, I will respin
> accordingly and make sure the commit message documents the logical-port to
> hardware-PHY mapping clearly.
> 

Krzysztof, the Glymur CAMSS binding is already merged, but no upstream
DTS consumes it yet. The current example uses port@3 for CSIPHY4.

For the binding, would you prefer keeping the existing "^port@[0-3]$"
range, or tightening it to "^port@[0-2]$" and using logical ports
port@0, port@1 and port@2 in the example?

The driver would then handle the mapping from logical port 2 to hardware
CSIPHY4.

>> If you look at the mdss_mdp ports in glymur.dtsi, you'll notice that
>> the ports are associated with their corresponding INTF numbers, and
>> interfaces that are not present are simply omitted. As a result, the
>> port numbering contains holes, for example {0, 4, 5, 6}.
>>
>>> Honestly I don’t see much value in continuing to treat port numbers as
>>> hardware mappings in DT now that standalone PHYs have landed.
>> As long as it is clearly documented in the binding, that should be
>> fine. We will need to introduce a mapping table for platforms that do
>> not expose the legacy PHY numbering, or otherwise derive the
>> corresponding information from 'somewhere'.

-- 
Regards,
Nihal Kumar Gupta