[PATCH 0/2] media: qcom: camss: track PHY type and scale link frequency for C-PHY

[PATCH 0/2] media: qcom: camss: track PHY type and scale link frequency for C-PHY

[Anusha Arun Nandi]

This series lays the CAMSS-side groundwork for MIPI C-PHY sensors.

Patch 1 records whether a CSIPHY endpoint is D-PHY or C-PHY from its
device-tree bus-type property (instead of rejecting anything that
isn't D-PHY), storing it in struct csiphy_lanes_cfg.

Patch 2 threads that PHY type through to link-frequency calculation:
camss_get_link_freq() gains a cphy parameter and scales its per-lane
divisor to match C-PHY's 16-bits-per-7-symbols encoding (vs. D-PHY's
1 bit/symbol), and the CSID gen3 RX front-end's CSI2_RX_CFG0 register
is programmed with the matching PHY_TYPE_SEL bit so C-PHY streams are
actually decoded as C-PHY instead of silently defaulting to D-PHY.

Referenced using David's C-PHY support(v9)
Link: https://lore.kernel.org/all/20260617-qcom-cphy-v9-0-83da8a8e4e44@ixit.cz/
Depends-on: https://lore.kernel.org/all/20261017001116.2318647-1-anusha.nandi@oss.qualcomm.com/
Depends-on: https://lore.kernel.org/all/20261016235502.2274268-1-anusha.nandi@oss.qualcomm.com/

David Heidelberg (2):
  media: qcom: camss: csiphy: record PHY type from device-tree bus-type
  media: qcom: camss: account for C-PHY when calculating link frequency
  
Anusha Arun Nandi (2):
  media: qcom: camss: csiphy: record PHY type from device-tree bus-type
  media: qcom: camss: account for C-PHY when calculating link frequency

 .../platform/qcom/camss/camss-csid-gen3.c     |  2 ++
 .../media/platform/qcom/camss/camss-csid.c    |  4 ++-
 .../media/platform/qcom/camss/camss-csid.h    |  1 +
 .../media/platform/qcom/camss/camss-csiphy.c  |  8 +++---
 .../media/platform/qcom/camss/camss-csiphy.h  |  2 ++
 drivers/media/platform/qcom/camss/camss.c     | 25 +++++++++++++++----
 drivers/media/platform/qcom/camss/camss.h     |  2 +-
 7 files changed, 34 insertions(+), 10 deletions(-)


Best regards,
-- 
Anusha Arun Nandi <anusha.nandi@oss.qualcomm.com>
-- 
2.34.1

[PATCH 1/2] media: qcom: camss: csiphy: record PHY type from device-tree bus-type

[Anusha Arun Nandi]

The CSIPHY lane configuration only tracked D-PHY, and
camss_parse_endpoint_node() rejected any endpoint whose bus-type was
not V4L2_MBUS_CSI2_DPHY. To support C-PHY sensors, record the PHY type
(D-PHY or C-PHY) parsed from the device-tree endpoint bus-type into
struct csiphy_lanes_cfg, and accept C-PHY endpoints.

This is consumed by subsequent patches that adjust the link-frequency
calculation and PHY configuration for C-PHY operation. No functional
change for D-PHY: phy_cfg is set to V4L2_MBUS_CSI2_DPHY and existing
behaviour is retained.

Co-developed-by: David Heidelberg <david@ixit.cz>
Signed-off-by: David Heidelberg <david@ixit.cz>
Signed-off-by: Anusha Arun Nandi <anusha.nandi@oss.qualcomm.com>
---
 drivers/media/platform/qcom/camss/camss-csiphy.h | 2 ++
 drivers/media/platform/qcom/camss/camss.c        | 9 ++++++---
 2 files changed, 8 insertions(+), 3 deletions(-)

diff --git a/drivers/media/platform/qcom/camss/camss-csiphy.h b/drivers/media/platform/qcom/camss/camss-csiphy.h
index 8c3319f2ca1c..fff504d2d489 100644
--- a/drivers/media/platform/qcom/camss/camss-csiphy.h
+++ b/drivers/media/platform/qcom/camss/camss-csiphy.h
@@ -35,11 +35,13 @@ struct csiphy_lane {
  * @num_data: number of data lanes
  * @data:     data lanes configuration
  * @clk:      clock lane configuration (only for D-PHY)
+ * @phy_cfg:  PHY type in use (D-PHY or C-PHY)
  */
 struct csiphy_lanes_cfg {
 	int num_data;
 	struct csiphy_lane *data;
 	struct csiphy_lane clk;
+	enum v4l2_mbus_type phy_cfg;
 };
 
 struct csiphy_csi2_cfg {
diff --git a/drivers/media/platform/qcom/camss/camss.c b/drivers/media/platform/qcom/camss/camss.c
index 07f7bed9591d..c888e78256b3 100644
--- a/drivers/media/platform/qcom/camss/camss.c
+++ b/drivers/media/platform/qcom/camss/camss.c
@@ -4756,10 +4756,12 @@ static int camss_parse_endpoint_node(struct device *dev,
 		return ret;
 
 	/*
-	 * Most SoCs support both D-PHY and C-PHY standards, but currently only
-	 * D-PHY is supported in the driver.
+	 * Most SoCs support both D-PHY and C-PHY standards. Record the PHY type
+	 * in use so that later stages (link-frequency calculation and PHY
+	 * configuration) can account for the encoding differences between them.
 	 */
-	if (vep.bus_type != V4L2_MBUS_CSI2_DPHY) {
+	if (vep.bus_type != V4L2_MBUS_CSI2_DPHY &&
+	    vep.bus_type != V4L2_MBUS_CSI2_CPHY) {
 		dev_err(dev, "Unsupported bus type %d\n", vep.bus_type);
 		return -EINVAL;
 	}
@@ -4767,6 +4769,7 @@ static int camss_parse_endpoint_node(struct device *dev,
 	csd->interface.csiphy_id = vep.base.port;
 
 	mipi_csi2 = &vep.bus.mipi_csi2;
+	lncfg->phy_cfg = vep.bus_type;
 	lncfg->clk.pos = mipi_csi2->clock_lane;
 	lncfg->clk.pol = mipi_csi2->lane_polarities[0];
 	lncfg->num_data = mipi_csi2->num_data_lanes;
-- 
2.34.1

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

[Anusha Arun Nandi]

The link-frequency divisor differs between D-PHY and C-PHY: D-PHY
carries one bit per symbol while C-PHY encodes 16 bits per 7 symbols
(~2.28 bits/symbol), as described in the MIPI CSI-2 specification.
Extend camss_get_link_freq() with a cphy parameter and scale the
per-lane divisor accordingly.

Thread the PHY type through the CSIPHY (via lane_cfg->phy_cfg) and CSID
(via a new csid_phy_config.cphy flag, populated from the linked
CSIPHY's lane configuration) call sites. The TPG path is always D-PHY.

No functional change for D-PHY: cphy is false and the divisor reduces
to the previous 2 * lanes with unscaled bpp.

Also program the CSID gen3 RX front-end's CSI2_RX_CFG0 PHY_TYPE_SEL
bit (24) from the same csid->phy.cphy flag, so C-PHY streams are
decoded as C-PHY instead of silently defaulting to D-PHY (RX counters
increment but no packets/frames are ever assembled and buf_done never
fires).

Co-developed-by: David Heidelberg <david@ixit.cz>
Signed-off-by: David Heidelberg <david@ixit.cz>
Signed-off-by: Anusha Arun Nandi <anusha.nandi@oss.qualcomm.com>
---
 .../media/platform/qcom/camss/camss-csid-gen3.c  |  2 ++
 drivers/media/platform/qcom/camss/camss-csid.c   |  4 +++-
 drivers/media/platform/qcom/camss/camss-csid.h   |  1 +
 drivers/media/platform/qcom/camss/camss-csiphy.c |  8 +++++---
 drivers/media/platform/qcom/camss/camss.c        | 16 ++++++++++++++--
 drivers/media/platform/qcom/camss/camss.h        |  2 +-
 6 files changed, 26 insertions(+), 7 deletions(-)

diff --git a/drivers/media/platform/qcom/camss/camss-csid-gen3.c b/drivers/media/platform/qcom/camss/camss-csid-gen3.c
index 0fdbf75fb27d..6eaeb1ba7462 100644
--- a/drivers/media/platform/qcom/camss/camss-csid-gen3.c
+++ b/drivers/media/platform/qcom/camss/camss-csid-gen3.c
@@ -66,6 +66,7 @@
 #define		CSI2_RX_CFG0_VC_MODE		3
 #define		CSI2_RX_CFG0_DL0_INPUT_SEL	4
 #define		CSI2_RX_CFG0_PHY_NUM_SEL	20
+#define		CSI2_RX_CFG0_PHY_TYPE_SEL	24
 #define		CSI2_RX_CFG0_TPG_MUX_EN		BIT(27)
 #define		CSI2_RX_CFG0_TPG_MUX_SEL	GENMASK(29, 28)
 
@@ -115,6 +116,7 @@ static void __csid_configure_rx(struct csid_device *csid,
 
 	camss = csid->camss;
 	val = (phy->lane_cnt - 1) << CSI2_RX_CFG0_NUM_ACTIVE_LANES;
+	val |= phy->cphy << CSI2_RX_CFG0_PHY_TYPE_SEL;
 	val |= phy->lane_assign << CSI2_RX_CFG0_DL0_INPUT_SEL;
 
 	if (camss->tpg && csid->tpg_linked &&
diff --git a/drivers/media/platform/qcom/camss/camss-csid.c b/drivers/media/platform/qcom/camss/camss-csid.c
index a00791b00feb..321bb3c86c56 100644
--- a/drivers/media/platform/qcom/camss/camss-csid.c
+++ b/drivers/media/platform/qcom/camss/camss-csid.c
@@ -547,7 +547,7 @@ static int csid_set_clock_rates(struct csid_device *csid)
 	fmt = csid_get_fmt_entry(csid->res->formats->formats, csid->res->formats->nformats,
 				 csid->fmt[MSM_CSIPHY_PAD_SINK].code);
 	link_freq = camss_get_link_freq(&csid->subdev.entity, fmt->bpp,
-					csid->phy.lane_cnt);
+					csid->phy.lane_cnt, csid->phy.cphy);
 	if (link_freq < 0)
 		link_freq = 0;
 
@@ -1279,6 +1279,7 @@ static int csid_link_setup(struct media_entity *entity,
 			csid->phy.lane_cnt = tpg->res->lane_cnt;
 			csid->phy.csiphy_id = tpg->id;
 			csid->phy.lane_assign = csid_get_lane_assign(NULL, csid->phy.lane_cnt);
+			csid->phy.cphy = false;
 			csid->tpg_linked = true;
 		} else {
 			csiphy = v4l2_get_subdevdata(sd);
@@ -1293,6 +1294,7 @@ static int csid_link_setup(struct media_entity *entity,
 			lane_cfg = &csiphy->cfg.csi2->lane_cfg;
 			csid->phy.lane_cnt = lane_cfg->num_data;
 			csid->phy.lane_assign = csid_get_lane_assign(lane_cfg, lane_cfg->num_data);
+			csid->phy.cphy = (lane_cfg->phy_cfg == V4L2_MBUS_CSI2_CPHY);
 			csid->tpg_linked = false;
 		}
 	}
diff --git a/drivers/media/platform/qcom/camss/camss-csid.h b/drivers/media/platform/qcom/camss/camss-csid.h
index 5296b10f6bac..00e2669db64c 100644
--- a/drivers/media/platform/qcom/camss/camss-csid.h
+++ b/drivers/media/platform/qcom/camss/camss-csid.h
@@ -70,6 +70,7 @@ struct csid_phy_config {
 	u32 lane_assign;
 	u32 en_vc;
 	u8 need_vc_update;
+	bool cphy;
 };
 
 struct csid_device;
diff --git a/drivers/media/platform/qcom/camss/camss-csiphy.c b/drivers/media/platform/qcom/camss/camss-csiphy.c
index f99eea2ef228..60d58becc7c5 100644
--- a/drivers/media/platform/qcom/camss/camss-csiphy.c
+++ b/drivers/media/platform/qcom/camss/camss-csiphy.c
@@ -146,8 +146,9 @@ static int csiphy_set_clock_rates_legacy(struct csiphy_device *csiphy)
 	u8 bpp = csiphy_get_bpp(csiphy->res->formats->formats, csiphy->res->formats->nformats,
 				csiphy->fmt[MSM_CSIPHY_PAD_SINK].code);
 	u8 num_lanes = csiphy->cfg.csi2->lane_cfg.num_data;
+	const bool cphy = (csiphy->cfg.csi2->lane_cfg.phy_cfg == V4L2_MBUS_CSI2_CPHY);
 
-	link_freq = camss_get_link_freq(&csiphy->subdev.entity, bpp, num_lanes);
+	link_freq = camss_get_link_freq(&csiphy->subdev.entity, bpp, num_lanes, cphy);
 	if (link_freq < 0)
 		link_freq  = 0;
 
@@ -272,9 +273,10 @@ static int csiphy_stream_on_legacy(struct csiphy_device *csiphy)
 	u8 bpp = csiphy_get_bpp(csiphy->res->formats->formats, csiphy->res->formats->nformats,
 				csiphy->fmt[MSM_CSIPHY_PAD_SINK].code);
 	u8 num_lanes = csiphy->cfg.csi2->lane_cfg.num_data;
+	const bool cphy = (csiphy->cfg.csi2->lane_cfg.phy_cfg == V4L2_MBUS_CSI2_CPHY);
 	u8 val;
 
-	link_freq = camss_get_link_freq(&csiphy->subdev.entity, bpp, num_lanes);
+	link_freq = camss_get_link_freq(&csiphy->subdev.entity, bpp, num_lanes, cphy);
 
 	if (link_freq < 0) {
 		dev_err(csiphy->camss->dev,
@@ -336,7 +338,7 @@ static int csiphy_stream_on(struct csiphy_device *csiphy)
 
 	dphy_cfg = &dphy_opts.mipi_dphy;
 
-	link_freq = camss_get_link_freq(&csiphy->subdev.entity, bpp, num_lanes);
+	link_freq = camss_get_link_freq(&csiphy->subdev.entity, bpp, num_lanes, false);
 
 	if (link_freq <= 0) {
 		dev_err(dev,
diff --git a/drivers/media/platform/qcom/camss/camss.c b/drivers/media/platform/qcom/camss/camss.c
index c888e78256b3..d525358afa04 100644
--- a/drivers/media/platform/qcom/camss/camss.c
+++ b/drivers/media/platform/qcom/camss/camss.c
@@ -32,6 +32,15 @@
 #define CAMSS_CLOCK_MARGIN_NUMERATOR 105
 #define CAMSS_CLOCK_MARGIN_DENOMINATOR 100
 
+/*
+ * C-PHY encodes data at 16/7 ~ 2.28 bits/symbol, whereas D-PHY does not encode
+ * data (16/16 = 1 bit/symbol). Scale the per-lane divisor accordingly when
+ * deriving the link frequency from the sensor pixel rate.
+ */
+#define CAMSS_COMMON_PHY_DIVIDENT 16
+#define CAMSS_CPHY_DIVISOR 7
+#define CAMSS_DPHY_DIVISOR 16
+
 static const struct parent_dev_ops vfe_parent_dev_ops;
 
 static const struct camss_subdev_resources csiphy_res_8x16[] = {
@@ -4624,19 +4633,22 @@ struct media_pad *camss_find_sensor_pad(struct media_entity *entity)
  * @entity: Media entity in the current pipeline
  * @bpp: Number of bits per pixel for the current format
  * @lanes: Number of lanes in the link to the sensor
+ * @cphy: True if C-PHY encoding is used
  *
  * Return link frequency on success or a negative error code otherwise
  */
 s64 camss_get_link_freq(struct media_entity *entity, unsigned int bpp,
-			unsigned int lanes)
+			unsigned int lanes, const bool cphy)
 {
 	struct media_pad *sensor_pad;
+	unsigned int div = lanes * 2 * (cphy ? CAMSS_CPHY_DIVISOR :
+					       CAMSS_DPHY_DIVISOR);
 
 	sensor_pad = camss_find_sensor_pad(entity);
 	if (!sensor_pad)
 		return -ENODEV;
 
-	return v4l2_get_link_freq(sensor_pad, bpp, 2 * lanes);
+	return v4l2_get_link_freq(sensor_pad, CAMSS_COMMON_PHY_DIVIDENT * bpp, div);
 }
 
 /*
diff --git a/drivers/media/platform/qcom/camss/camss.h b/drivers/media/platform/qcom/camss/camss.h
index ba3d51d9c0bf..f7ee2ae792c9 100644
--- a/drivers/media/platform/qcom/camss/camss.h
+++ b/drivers/media/platform/qcom/camss/camss.h
@@ -170,7 +170,7 @@ int camss_enable_clocks(int nclocks, struct camss_clock *clock,
 void camss_disable_clocks(int nclocks, struct camss_clock *clock);
 struct media_pad *camss_find_sensor_pad(struct media_entity *entity);
 s64 camss_get_link_freq(struct media_entity *entity, unsigned int bpp,
-			unsigned int lanes);
+			unsigned int lanes, const bool cphy);
 int camss_get_pixel_clock(struct media_entity *entity, u64 *pixel_clock);
 int camss_pm_domain_on(struct camss *camss, int id);
 void camss_pm_domain_off(struct camss *camss, int id);
-- 
2.34.1

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

[George Neacsu]

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

Re: [PATCH 0/2] media: qcom: camss: track PHY type and scale link frequency for C-PHY

[Nihal Kumar Gupta]

On 17-10-2026 09:22, Anusha Arun Nandi wrote:
> Depends-on: https://lore.kernel.org/all/20261017001116.2318647-1-anusha.nandi@oss.qualcomm.com/

This Depends-on is in the wrong series. 
The driver should not depend on the DTS.
-- 
Regards,
Nihal Kumar Gupta

Re: [PATCH 0/2] media: qcom: camss: track PHY type and scale link frequency for C-PHY

[Krzysztof Kozlowski]

On 17/10/2026 19:30, Nihal Kumar Gupta wrote:
> 
> 
> On 17-10-2026 09:22, Anusha Arun Nandi wrote:
>> Depends-on: https://lore.kernel.org/all/20261017001116.2318647-1-anusha.nandi@oss.qualcomm.com/
> 
> This Depends-on is in the wrong series. 
> The driver should not depend on the DTS.

Good point. If dependency is true, then this patchset is just broken.

Best regards,
Krzysztof