Re: [PATCH 2/2] media: qcom: camss: account for C-PHY when calculating link frequency

From: Anusha Arun Nandi

Date: Mon Oct 19 2026 - 18:35:47 EST


Hi George,

Thanks for testing this on X1E80100 and tracking down the csid_ops_680
path, really appreciate the thorough analysis and the control run
confirming both front and rear capture work correctly.

Let's fold the CSID-680 line into this patch. I'll add:

val |= phy->cphy << CSI2_RX_CFG0_PHY_TYPE_SEL;

before the CSID_CSI2_RX_CFG0 write in camss-csid-680.c alongside the
existing gen3 change, so both receiver paths are covered in one go.

I'll send out a revised version shortly. Feel free to add your Tested-by
tag when I post it.

Best Regards,
Anusha


On 10/17/2026 3:12 AM, George Neacsu wrote:
> Hi Anusha,
>
> I tested the CAMSS pieces on X1E80100 and found one extra receiver path
> that needs the C-PHY select.
>
> X1E80100 uses csid_ops_680, not the gen3 CSID path changed here. The
> C-PHY flag reaches struct csid_phy_config correctly, but
> camss-csid-680.c leaves CSI2_RX_CFG0.PHY_TYPE_SEL clear, so the front
> IMX681 stream is decoded as D-PHY and capture times out with a zero-byte
> buffer.
>
> The equivalent change for CSID 680 is just:
>
> val |= phy->cphy << CSI2_RX_CFG0_PHY_TYPE_SEL;
>
> before writing CSID_CSI2_RX_CFG0. With that line, the register reads
> back 0x01300000 on CSID1 and 3844x2640 RAW10 capture succeeds from the
> IMX681 over one C-PHY trio. The rear OV13858 still captures over four
> D-PHY lanes.
>
> I also ran a control with your posted CAMSS/qcom-mipi-csi2 module code,
> plus only the X1E PHY table and this CSID-680 select: both front and rear
> capture successfully.
>
> Would you prefer to fold the CSID-680 line into this patch? I have a
> clean follow-up commit ready if you would rather I send it separately.
>
> Thanks,
> George