[PATCH v3 6/6] phy: qcom-mipi-csi2: Add C-PHY support for X1E80100

[David Heidelberg]

On 16/10/2026 16:56, George Neacsu via B4 Relay wrote:
> From: George Neacsu <geocausa at gmail.com>
> 
> The CSI2 PHY schema already allows bus-type C-PHY, but the driver
> rejects it. Accept it on SoCs that provide a C-PHY sequence, with up to
> three trios and no lane polarities. The endpoint's bus-type now sets the
> PHY mode, set_mode() only accepts that mode, and in C-PHY mode
> configure() takes the symbol rate and keeps the matching link frequency,
> so clock scaling works as for D-PHY.
> 
> In C-PHY mode, lanes_enable() powers up the trios on the odd CTRL5 bits,
> skips the D-PHY lane polarities and writes the C-PHY sequence. The
> settle count is computed as for D-PHY: with a C-PHY link frequency of
> half the symbol rate, the unit interval in the existing formula is one
> symbol, which is also how David Heidelberg's CAMSS C-PHY series
> computes it.
> 
> The X1E80100 sequence is Qualcomm's for the v2.1.2 3PH PHY at 2.5 Gsps,
> taken from the downstream camera driver's GPL-2.0
> cam_csiphy_2_1_2_hwreg.h (csiphy_3ph_v2_1_2_reg, datarate_212_2p5Gsps
> and the 3PH reset exit), as the D-PHY sequence above it is. Its three
> settle count entries are the ones downstream marks as such. The trios
> sit in lane slots 1, 3 and 5, so the per-trio registers are written
> with a CSIPHY_LN_CTRLn() address macro.
> 
> Tested on the Surface Pro 11 (X1E80100), booting next-20261015 with
> this series, David Heidelberg's CAMSS C-PHY series v9 and two CAMSS
> patches on top: the IMX681 on CSIPHY2, one trio at 2.4 Gsym/s, streams
> 3844x2640 at 30 fps through CSID1 and an RDI, and its colour bars are
> byte-identical to the same pattern captured with an out-of-tree driver.
> The timer runs at 400 MHz and the computed settle count is 28. D-PHY is
> unchanged: an OV13858 on CSIPHY1 over four lanes streams at 29.9 fps.
> 
> Assisted-by: Claude:claude-opus-5-5
> Signed-off-by: George Neacsu <geocausa at gmail.com>
> ---
>   drivers/phy/qualcomm/phy-qcom-mipi-csi2-3ph-dphy.c | 168 ++++++++++++++++++++-
>   drivers/phy/qualcomm/phy-qcom-mipi-csi2-core.c     |  53 ++++++-
>   drivers/phy/qualcomm/phy-qcom-mipi-csi2.h          |   2 +
>   3 files changed, 212 insertions(+), 11 deletions(-)
> 
> diff --git a/drivers/phy/qualcomm/phy-qcom-mipi-csi2-3ph-dphy.c b/drivers/phy/qualcomm/phy-qcom-mipi-csi2-3ph-dphy.c
> index 84c45f67fd..f09ef9b41c 100644
> --- a/drivers/phy/qualcomm/phy-qcom-mipi-csi2-3ph-dphy.c
> +++ b/drivers/phy/qualcomm/phy-qcom-mipi-csi2-3ph-dphy.c
> @@ -22,6 +22,7 @@
>   #define CSIPHY_3PH_CMN_CSI_COMMON_STATUSn(offset, n)	((offset) + 0xb0 + 0x4 * (n))
>   
>   #define CSIPHY_2PH_LN_CSI_2PHASE_CTRL9n(n)		((0x200 * (n)) + 0x24)
> +#define CSIPHY_LN_CTRLn(ln, n)			((0x200 * (ln)) + 0x4 * (n))
>   
>   /*
>    * 3 phase CSI has 19 common status regs with only 0-10 being used
> @@ -161,6 +162,144 @@ mipi_csi2phy_lane_regs lane_regs_x1e80100[] = {
>   	{.reg_addr = 0x0c64, .reg_data = 0x7f, .param_type = CSIPHY_SKEW_CAL},
>   };
>   
> +/* Qualcomm's 2.5 Gsps settings, from the GPL-2.0 cam_csiphy_2_1_2_hwreg.h */
> +static const struct
> +mipi_csi2phy_lane_regs lane_regs_v2_1_2_cphy[] = {
> +	/* Power up lanes 3ph mode */
> +	{.reg_addr = 0x101c, .reg_data = 0x7a, .param_type = CSIPHY_DEFAULT_PARAMS},
> +	{.reg_addr = 0x1018, .reg_data = 0x01, .param_type = CSIPHY_DEFAULT_PARAMS},
> +
> +	/* datarate_212_2p5Gsps: AFE settings */
> +	{.reg_addr = CSIPHY_LN_CTRLn(1, 26), .reg_data = 0xf1, .param_type = CSIPHY_DEFAULT_PARAMS},

Thank you for the change. While the lane being decimal number is completely 
fine, I believe the register passed should stay in hex :)

Otherwise LGTM.

David

[...]

[...]