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

[Bryan O'Donoghue]

On 05/11/2026 09:53, Loic Poulain wrote:
> 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

Without reading this long thread - Hamoa hardware IDs are {0, 1, 2, 4} 
so Glymur is either like that or not please check yourselves.

I think Nihal says Glymur as 2 and 3 missing so suggest hardware numbers 
scheme follows established Hamoa scheme.

---
bod