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

[Loic Poulain]

On Thu, Nov 5, 2026 at 10:23 AM Krzysztof Kozlowski <krzk@xxxxxxxxxx> wrote:
>
> On 05/11/2026 10:18, Nihal Kumar Gupta wrote:
> >
> >
> > On 05-11-2026 13:03, Krzysztof Kozlowski wrote:
> >>>> What is the problem exactly you are solving?
> >>>>
> >>> The problem is that CSIPHY4 is connected to CAMSS interface 4, so the
> >>> graph should describe it as port@4, not port@2.
> >> Nothing like this is explained in commit msg.
> >>
> > I will update commit message to explain it better.
> >
> >>> The previous port@3 description only worked through the X1E80100 resource
> >>> table indirection:
> >>>
> >>>   port@3 -> csiphy_res[3] -> .csiphy.id = 4 -> CSID selects CSIPHY4
> >>>
> >>> New standalone PHY path:
> >>>   port@4 -> no csiphy_res[] lookup -> port number is id 4 -> CSID selects CSIPHY4
> >> Then this breaks existing users, no? Anyway, what stops you from having
> >> there proper mapping?
> >>
> > No existing upstream user should break here; this is still part of the Glymur
> > CAMSS enablement.
> >
> > This follows the earlier discussion that CSIPHY4 should use the
> > CAMSS-side interface index as its graph port number:
> >
> > https://lore.kernel.org/all/CAFEp6-23L+4+yzVxX815ZA2x1_tN8SpzL7ciNcb9b+gBT67AdQ@xxxxxxxxxxxxxx/
>
> Should use? Since when? Do you have DT maintainers ack on that?
>
> >
> >> Did you find any existing practice of numbering ports logical numbering
> >> in this device, but some other logic coming from datasheet? Where?
> >>
> >
> > Glymur has only CSIPHY0, CSIPHY1 and CSIPHY4; CSIPHY2 and CSIPHY3 are not
> > present on the SoC.
>
> Then CSIPHY4 is basically the third (so @2 counting from 0) input port,
> no? Not fifth.
> >
> > Using port@2 for CSIPHY4 would require a Glymur-specific port-to-CSIPHY mapping.
> > port@4 describes the CAMSS input directly and avoids introducing separate logical
> > numbering for Glymur.
>
> Seems you opened a new can of worms, so this needs proper justification.
> Again, do you see any recent preexisting DT review which would help to
> convince me? I know I usually ask not to use poor existing code as
> reason to do the same, but here I actually want to see proofs of current
> accepted practice.

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.

Regards,
Loic