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

[Loic Poulain]

On Thu, Nov 5, 2026 at 4:46 PM Bryan O'Donoghue <bod@xxxxxxxxxx> wrote:
>
> On 05/11/2026 14:01, Loic Poulain wrote:
> >>> 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 }.
>
> 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 }.

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,
Loic