[PATCH v2 3/7] media: qcom: camss: Allow CSI2 PHY devices without CSIPHY resources

[Loic Poulain]

On Sat, Oct 31, 2026 at 3:14 PM Nihal Kumar Gupta
<nihal.gupta at oss.qualcomm.com> wrote:
>
>
>
> On 27-10-2026 22:30, Vladimir Zapolskiy wrote:
> > Please note that 'csiphy_res_phy' was introduced a few lines above
> > by this change, it's only purpose is to provide the needed supported
> > media formats, and this is unavoidable.
> >
>
> Right, agreed. Glymur uses the non-legacy path, but that path still uses
> camss->res->csiphy_res in msm_csiphy_subdev_init(), at least to get the
> CSIPHY id and supported media formats. That is why Glymur currently has
> a non-NULL csiphy_res even though the actual PHY programming is handled
> by the standalone CSI2 PHY driver.
>
> > This change follows the assumption that pixel formats from all
> > non-legacy PHYs are SDM845 compatible, that's true for this platform,
> > it is expected to be true for the most of approaching non-legacy
> > platforms, and on demand it may be changed later on.
> >
> > The current form likely is the most compact and the least invasive
> > change, which gets to the point of supporting CAMSS on platforms
> > with no CSIPHY resources given in the CAMSS driver.
> >
> > For instance, note, the recently proposed Glymur CAMSS [1] references
> > X1E CSIPHY resources, which is actually incorrect, since there is
> > no "csiphyX" I/O resources anymore for Glymur. This change can be
> > reused for Glymur as well, and its reference to X1E CSIPHYs can be
> > dropped, but any better proposal or improvement are welcome.
>
> The intention was not to describe CAMSS-owned CSIPHY I/O resources for
> Glymur. This also follows the earlier suggestion to reuse/fall back
> to the Hamoa/X1E CAMSS description where possible:
>
> https://lore.kernel.org/all/lepv7cgykrylficddcnnbii3kzxsiei3itcwc4ibq53s33rogi@ndnf7zrtu5ex/
>
> Moving Glymur to .csiphy_res = NULL is possible, but with this fallback
> the CSIPHY id comes from the CAMSS port number. Since Glymur uses
> CSIPHY ids 0, 1 and 4, that would also require Glymur-specific driver
> data and DT/binding updates to describe CSIPHY4 as CAMSS port 4.
>
> Bryan, Loic, do you think we need that change now, or should Glymur keep
> the current approach for this DTS series?

I see in the following in your Glymur series:
port at 3 {
   reg = <3>;
   camss_csiphy4_inep: endpoint {
   remote-endpoint = <&csiphy4_out_ep>;
};

Which CAMSS pipeline interface index/instance is CSIPHY4 connected to?
If it is connected to interface 4 on CAMSS side, then we should use
port at 4.

Regards,
Loic