Re: [PATCH 1/2] dt-bindings: media: qcom,glymur-camss: Use CSIPHY indices for ports
From: Bryan O'Donoghue
Date: Thu Nov 05 2026 - 06:18:33 EST
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