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

[Nihal Kumar Gupta]

On 05-11-2026 21:48, Loic Poulain wrote:
>>> 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 }.
>> The media-graph informs which PHY connects to which CSID. The
>> port-number in the DT really only identifies the fact a PHY input exists
>> - it should be considered a mux in front of the set of CSIDs with the
>> media-graph being the route.
>>
>> Since the route is runtime selectable, the media-graph is the boss, not DT.
>>
>> You can try this on any CAMSS device right now, PHYs connect
>> independently to CSI decoders.
>>
>> PHY_NUM_SEL is derived in the driver, not taken directly from the port
>> number: the port indexes csiphy_res[] and csiphy_res[port].csiphy.id is
>> the hardware PHY index, e.g. port@3 on x1e is CSIPHY4.
>>
>> More work should be done to represent the fact-of-life - the mux. This
>> was discussed extensively in the standalone PHY series.
>>
>> The ports being numbered with the PHYs was a consequence of the PHYs
>> living inside the CAMSS node - which we have the opportunity now to
>> break with and should.
>>
>> Port number in DT should just be a linear 0-X for the number of PHY
>> inputs. Which CSI decoder that port routes to is still a runtime selection.
> I think we're all aligned on that. Point was not about describing the
> runtime muxing or routing to the CSID, but rather about describing the
> CAMSS PHY input ID/link, which corresponds to the input of the CAMSS
> block (MUX input).
> 
> 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.

> 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