[PATCH 0/6] media: qcom: camss: Add C-PHY support for sa8775p, sa8300 and sm8250

[PATCH 0/6] media: qcom: camss: Add C-PHY support for sa8775p, sa8300 and sm8250

[Anusha Arun Nandi]

This series extends the Qualcomm CAMSS (Camera Subsystem) C-PHY support to
the Gen3 platforms, adding C-PHY mode configuration for sa8775p
(CAMSS_8775P) and sa8300 (CAMSS_8300), along with a dynamic, data-rate
specific C-PHY register programming mechanism.

It builds on David Heidelberg's C-PHY enablement work for Qualcomm
platforms:

  - Program the common control registers and prepare the CSID RX path
    to select between C-PHY and D-PHY for Gen3.
  - Add the sa8775p C-PHY 3ph lane register table and wire it up for
    sa8775p and sa8300.
  - Introduce a data-rate selection mechanism so the C-PHY PHY register
    overrides vary with the negotiated link (symbol) data rate, with
    tables for sa8775p/8300 (1.5/1.7/2.5/3.5/4.5 GSpS) and sm8250
    (2.5/3.5/4.5 GSpS).
  - Validate that the local (CSIPHY) and remote (sensor) endpoint
    bus-types agree, catching C-PHY/D-PHY mismatches early at probe.

Rebased on David Heidelberg's C-PHY series (v9):
  https://lore.kernel.org/all/20260617-qcom-cphy-v9-0-83da8a8e4e44@ixit.cz/

Tested on sm8250, sa8775p and sa8300, on top of the v4 revision of that series:
  https://lore.kernel.org/all/20260301-qcom-cphy-v4-0-e53316d2cc65@ixit.cz/

Anusha Arun Nandi (3):
  media: qcom: camss: Add sa8300 C-PHY 3ph lane config
  media: qcom: camss: Dynamic data-rate specific C-PHY register settings
  media: qcom: camss: validate local/remote endpoint bus-type

Jigarkumar Zala (3):
  media: qcom: camss: Program CSIPHY common control registers
  media: qcom: camss: Prepare CSID for C-PHY support in gen3
  media: qcom: camss: Add sa8775p C-PHY 3ph lane config

 .../platform/qcom/camss/camss-csid-gen3.c     |   2 +
 .../qcom/camss/camss-csiphy-3ph-1-0.c         | 394 +++++++++++++++++-
 .../media/platform/qcom/camss/camss-csiphy.h  |   6 +
 drivers/media/platform/qcom/camss/camss.c     |  28 +-
 4 files changed, 420 insertions(+), 10 deletions(-)
---
base-commit: 0e35b9b6ec0ffcc5e23cbdec09f5c622ad532b53
change-id: 20251109-qcom-cphy-bb8cbda1c644 

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

[PATCH 1/6] media: qcom: camss: Program CSIPHY common control registers

[Anusha Arun Nandi]

From: Jigarkumar Zala <jigarkumar.zala@oss.qualcomm.com>

Program the CSIPHY common-control registers during lane enable so
SA8775P uses the required 3-phase 1.5 Gsps reset-release values for
both C-PHY and D-PHY. Keep the existing reset-release value for the
other CAMSS variants.

Co-developed-by: Anusha Arun Nandi <anusha.nandi@oss.qualcomm.com>
Signed-off-by: Anusha Arun Nandi <anusha.nandi@oss.qualcomm.com>
Signed-off-by: Jigarkumar Zala <jigarkumar.zala@oss.qualcomm.com>
---
 .../qcom/camss/camss-csiphy-3ph-1-0.c         | 36 ++++++++++++++++---
 1 file changed, 31 insertions(+), 5 deletions(-)

diff --git a/drivers/media/platform/qcom/camss/camss-csiphy-3ph-1-0.c b/drivers/media/platform/qcom/camss/camss-csiphy-3ph-1-0.c
index 25a3554ef201..11b7a236e607 100644
--- a/drivers/media/platform/qcom/camss/camss-csiphy-3ph-1-0.c
+++ b/drivers/media/platform/qcom/camss/camss-csiphy-3ph-1-0.c
@@ -1031,8 +1031,6 @@ static void csiphy_reset(struct csiphy_device *csiphy)
 	writel_relaxed(0x1, csiphy->base +
 		      CSIPHY_3PH_CMN_CSI_COMMON_CTRLn(regs->offset, 0));
 	usleep_range(5000, 8000);
-	writel_relaxed(0x0, csiphy->base +
-		       CSIPHY_3PH_CMN_CSI_COMMON_CTRLn(regs->offset, 0));
 }
 
 static irqreturn_t csiphy_isr(int irq, void *dev)
@@ -1343,9 +1341,37 @@ static void csiphy_lanes_enable(struct csiphy_device *csiphy,
 	writel_relaxed(val, csiphy->base +
 		       CSIPHY_3PH_CMN_CSI_COMMON_CTRLn(regs->offset, 6));
 
-	val = 0x02;
-	writel_relaxed(val, csiphy->base +
-		       CSIPHY_3PH_CMN_CSI_COMMON_CTRLn(regs->offset, 7));
+	switch (csiphy->camss->res->version) {
+	case CAMSS_8300:
+	case CAMSS_8775P:
+		if (c->phy_cfg == V4L2_MBUS_CSI2_CPHY) {
+			val = 0x5A;
+			writel_relaxed(val, csiphy->base +
+				       CSIPHY_3PH_CMN_CSI_COMMON_CTRLn(regs->offset, 7));
+			val = 0xE;
+			writel_relaxed(val, csiphy->base +
+				       CSIPHY_3PH_CMN_CSI_COMMON_CTRLn(regs->offset, 0));
+		} else {
+			val = 0x02;
+			writel_relaxed(val, csiphy->base +
+				       CSIPHY_3PH_CMN_CSI_COMMON_CTRLn(regs->offset, 7));
+			writel_relaxed(val, csiphy->base +
+				       CSIPHY_3PH_CMN_CSI_COMMON_CTRLn(regs->offset, 0));
+		}
+		break;
+	case CAMSS_7280:
+	case CAMSS_8250:
+	case CAMSS_8280XP:
+	case CAMSS_845:
+	default:
+		val = 0x02;
+		writel_relaxed(val, csiphy->base +
+			       CSIPHY_3PH_CMN_CSI_COMMON_CTRLn(regs->offset, 7));
+		val = 0x0;
+		writel_relaxed(val, csiphy->base +
+			       CSIPHY_3PH_CMN_CSI_COMMON_CTRLn(regs->offset, 0));
+		break;
+	}
 
 	val = 0x00;
 	writel_relaxed(val, csiphy->base +
-- 
2.34.1

[PATCH 2/6] media: qcom: camss: Prepare CSID for C-PHY support in gen3

[Anusha Arun Nandi]

From: Jigarkumar Zala <jigarkumar.zala@oss.qualcomm.com>

Program the gen3 CSID CSI2 RX PHY type field from the configured PHY
type. The RX path needs this value to distinguish C-PHY from D-PHY
input, so leaving it at the default makes C-PHY configuration
incomplete.

Co-developed-by: Anusha Arun Nandi <anusha.nandi@oss.qualcomm.com>
Signed-off-by: Anusha Arun Nandi <anusha.nandi@oss.qualcomm.com>
Signed-off-by: Jigarkumar Zala <jigarkumar.zala@oss.qualcomm.com>
---
 drivers/media/platform/qcom/camss/camss-csid-gen3.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/media/platform/qcom/camss/camss-csid-gen3.c b/drivers/media/platform/qcom/camss/camss-csid-gen3.c
index 0fdbf75fb27d..a9c7934907a8 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->phy_sel << CSI2_RX_CFG0_PHY_TYPE_SEL;
 	val |= phy->lane_assign << CSI2_RX_CFG0_DL0_INPUT_SEL;
 
 	if (camss->tpg && csid->tpg_linked &&
-- 
2.34.1

[PATCH 3/6] media: qcom: camss: Add sa8775p C-PHY 3ph lane config

[Anusha Arun Nandi]

From: Jigarkumar Zala <jigarkumar.zala@oss.qualcomm.com>

Add the lane_regs_sa8775p_3ph[] register table for the
sa8775p Gen3 CSIPHY at 1.5 Gsps, and select it in csiphy_lanes_enable() for
CAMSS_8775P when the endpoint is configured for C-PHY, falling back to the
existing sa8775p D-PHY table otherwise.

Co-developed-by: Anusha Arun Nandi <anusha.nandi@oss.qualcomm.com>
Signed-off-by: Anusha Arun Nandi <anusha.nandi@oss.qualcomm.com>
Signed-off-by: Jigarkumar Zala <jigarkumar.zala@oss.qualcomm.com>
---
 .../qcom/camss/camss-csiphy-3ph-1-0.c         | 111 +++++++++++++++++-
 1 file changed, 110 insertions(+), 1 deletion(-)

diff --git a/drivers/media/platform/qcom/camss/camss-csiphy-3ph-1-0.c b/drivers/media/platform/qcom/camss/camss-csiphy-3ph-1-0.c
index 11b7a236e607..8f1e70ad2b7d 100644
--- a/drivers/media/platform/qcom/camss/camss-csiphy-3ph-1-0.c
+++ b/drivers/media/platform/qcom/camss/camss-csiphy-3ph-1-0.c
@@ -56,6 +56,12 @@
 	(0x0300 + ((n) * 0x4))
 #define CSIPHY_LN5_CSI_3PH_CTRLn_ADDR(n) \
 	(0x0500 + ((n) * 0x4))
+#define CSIPHY_LN9_CSI_3PH_CTRLn_ADDR(n) \
+	(0x0900 + ((n) * 0x4))
+#define CSIPHY_LN10_CSI_3PH_CTRLn_ADDR(n) \
+	(0x0A00 + ((n) * 0x4))
+#define CSIPHY_LN11_CSI_3PH_CTRLn_ADDR(n) \
+	(0x0B00 + ((n) * 0x4))
 
 #define CSIPHY_DEFAULT_PARAMS		0
 #define CSIPHY_LANE_ENABLE		1
@@ -152,6 +158,101 @@ csiphy_lane_regs lane_regs_sa8775p[] = {
 	{0x0664, 0x7F, 0x00, CSIPHY_DEFAULT_PARAMS},
 };
 
+/* GEN3 3PH sa8775p 1.5Gsps */
+/* 3 entries: 3 lanes (C-PHY) */
+static const struct
+csiphy_lane_regs lane_regs_sa8775p_3ph[] = {
+	{CSIPHY_LN1_CSI_3PH_CTRLn_ADDR(26), 0x80, 0x00, CSIPHY_DEFAULT_PARAMS},
+	{CSIPHY_LN1_CSI_3PH_CTRLn_ADDR(27), 0x25, 0x00, CSIPHY_DEFAULT_PARAMS},
+	{CSIPHY_LN1_CSI_3PH_CTRLn_ADDR(23), 0xC8, 0x00, CSIPHY_DEFAULT_PARAMS},
+	{CSIPHY_LN1_CSI_3PH_CTRLn_ADDR(3),  0x08, 0x00, CSIPHY_SETTLE_CNT_LOWER_BYTE},
+	{CSIPHY_LN1_CSI_3PH_CTRLn_ADDR(34), 0x00, 0x00, CSIPHY_DEFAULT_PARAMS},
+	{CSIPHY_LN1_CSI_3PH_CTRLn_ADDR(35), 0x7F, 0x00, CSIPHY_DEFAULT_PARAMS},
+	{CSIPHY_LN1_CSI_3PH_CTRLn_ADDR(36), 0x7F, 0x00, CSIPHY_DEFAULT_PARAMS},
+	{CSIPHY_LN1_CSI_3PH_CTRLn_ADDR(6),  0x3E, 0x00, CSIPHY_DEFAULT_PARAMS},
+	{CSIPHY_LN1_CSI_3PH_CTRLn_ADDR(7),  0x41, 0x00, CSIPHY_DEFAULT_PARAMS},
+	{CSIPHY_LN1_CSI_3PH_CTRLn_ADDR(9),  0x7F, 0x00, CSIPHY_DEFAULT_PARAMS},
+	{CSIPHY_LN1_CSI_3PH_CTRLn_ADDR(11), 0x00, 0x00, CSIPHY_DEFAULT_PARAMS},
+	{CSIPHY_LN1_CSI_3PH_CTRLn_ADDR(17), 0xB2, 0x00, CSIPHY_DEFAULT_PARAMS},
+	{CSIPHY_LN1_CSI_3PH_CTRLn_ADDR(51), 0x41, 0x00, CSIPHY_DEFAULT_PARAMS},
+	{CSIPHY_LN1_CSI_3PH_CTRLn_ADDR(25), 0x33, 0x00, CSIPHY_DEFAULT_PARAMS},
+	{CSIPHY_LN1_CSI_3PH_CTRLn_ADDR(55), 0x50, 0x00, CSIPHY_DEFAULT_PARAMS},
+	{CSIPHY_LN3_CSI_3PH_CTRLn_ADDR(26), 0x80, 0x00, CSIPHY_DEFAULT_PARAMS},
+	{CSIPHY_LN3_CSI_3PH_CTRLn_ADDR(27), 0x25, 0x00, CSIPHY_DEFAULT_PARAMS},
+	{CSIPHY_LN3_CSI_3PH_CTRLn_ADDR(23), 0xC8, 0x00, CSIPHY_DEFAULT_PARAMS},
+	{CSIPHY_LN3_CSI_3PH_CTRLn_ADDR(1),  0x06, 0x00, CSIPHY_DEFAULT_PARAMS},
+	{CSIPHY_LN3_CSI_3PH_CTRLn_ADDR(3),  0x08, 0x00, CSIPHY_SETTLE_CNT_LOWER_BYTE},
+	{CSIPHY_LN3_CSI_3PH_CTRLn_ADDR(2),  0x00, 0x00, CSIPHY_SETTLE_CNT_HIGHER_BYTE},
+	{CSIPHY_LN3_CSI_3PH_CTRLn_ADDR(5),  0x20, 0x00, CSIPHY_DEFAULT_PARAMS},
+	{CSIPHY_LN3_CSI_3PH_CTRLn_ADDR(20), 0x00, 0x00, CSIPHY_DEFAULT_PARAMS},
+	{CSIPHY_LN3_CSI_3PH_CTRLn_ADDR(34), 0x00, 0x00, CSIPHY_DEFAULT_PARAMS},
+	{CSIPHY_LN3_CSI_3PH_CTRLn_ADDR(35), 0x7F, 0x00, CSIPHY_DEFAULT_PARAMS},
+	{CSIPHY_LN3_CSI_3PH_CTRLn_ADDR(36), 0x7F, 0x00, CSIPHY_DEFAULT_PARAMS},
+	{CSIPHY_LN3_CSI_3PH_CTRLn_ADDR(6),  0x3E, 0x00, CSIPHY_DEFAULT_PARAMS},
+	{CSIPHY_LN3_CSI_3PH_CTRLn_ADDR(7),  0x41, 0x00, CSIPHY_DEFAULT_PARAMS},
+	{CSIPHY_LN3_CSI_3PH_CTRLn_ADDR(8),  0x41, 0x00, CSIPHY_DEFAULT_PARAMS},
+	{CSIPHY_LN3_CSI_3PH_CTRLn_ADDR(9),  0x7F, 0x00, CSIPHY_DEFAULT_PARAMS},
+	{CSIPHY_LN3_CSI_3PH_CTRLn_ADDR(10), 0x00, 0x00, CSIPHY_DEFAULT_PARAMS},
+	{CSIPHY_LN3_CSI_3PH_CTRLn_ADDR(11), 0x00, 0x00, CSIPHY_DEFAULT_PARAMS},
+	{CSIPHY_LN3_CSI_3PH_CTRLn_ADDR(17), 0xB2, 0x00, CSIPHY_DEFAULT_PARAMS},
+	{CSIPHY_LN3_CSI_3PH_CTRLn_ADDR(24), 0x02, 0x00, CSIPHY_DEFAULT_PARAMS},
+	{CSIPHY_LN3_CSI_3PH_CTRLn_ADDR(51), 0x41, 0x00, CSIPHY_DEFAULT_PARAMS},
+	{CSIPHY_LN3_CSI_3PH_CTRLn_ADDR(25), 0x33, 0x00, CSIPHY_DEFAULT_PARAMS},
+	{CSIPHY_LN3_CSI_3PH_CTRLn_ADDR(55), 0x50, 0x00, CSIPHY_DEFAULT_PARAMS},
+	{CSIPHY_LN5_CSI_3PH_CTRLn_ADDR(26), 0x80, 0x00, CSIPHY_DEFAULT_PARAMS},
+	{CSIPHY_LN5_CSI_3PH_CTRLn_ADDR(27), 0x25, 0x00, CSIPHY_DEFAULT_PARAMS},
+	{CSIPHY_LN5_CSI_3PH_CTRLn_ADDR(23), 0xC8, 0x00, CSIPHY_DEFAULT_PARAMS},
+	{CSIPHY_LN5_CSI_3PH_CTRLn_ADDR(1),  0x06, 0x00, CSIPHY_DEFAULT_PARAMS},
+	{CSIPHY_LN5_CSI_3PH_CTRLn_ADDR(3),  0x08, 0x00, CSIPHY_SETTLE_CNT_LOWER_BYTE},
+	{CSIPHY_LN5_CSI_3PH_CTRLn_ADDR(2),  0x00, 0x00, CSIPHY_SETTLE_CNT_HIGHER_BYTE},
+	{CSIPHY_LN5_CSI_3PH_CTRLn_ADDR(5),  0x20, 0x00, CSIPHY_DEFAULT_PARAMS},
+	{CSIPHY_LN5_CSI_3PH_CTRLn_ADDR(20), 0x00, 0x00, CSIPHY_DEFAULT_PARAMS},
+	{CSIPHY_LN5_CSI_3PH_CTRLn_ADDR(34), 0x00, 0x00, CSIPHY_DEFAULT_PARAMS},
+	{CSIPHY_LN5_CSI_3PH_CTRLn_ADDR(35), 0x7F, 0x00, CSIPHY_DEFAULT_PARAMS},
+	{CSIPHY_LN5_CSI_3PH_CTRLn_ADDR(36), 0x7F, 0x00, CSIPHY_DEFAULT_PARAMS},
+	{CSIPHY_LN5_CSI_3PH_CTRLn_ADDR(6),  0x3E, 0x00, CSIPHY_DEFAULT_PARAMS},
+	{CSIPHY_LN5_CSI_3PH_CTRLn_ADDR(7),  0x41, 0x00, CSIPHY_DEFAULT_PARAMS},
+	{CSIPHY_LN5_CSI_3PH_CTRLn_ADDR(8),  0x41, 0x00, CSIPHY_DEFAULT_PARAMS},
+	{CSIPHY_LN5_CSI_3PH_CTRLn_ADDR(9),  0x7F, 0x00, CSIPHY_DEFAULT_PARAMS},
+	{CSIPHY_LN5_CSI_3PH_CTRLn_ADDR(10), 0x00, 0x00, CSIPHY_DEFAULT_PARAMS},
+	{CSIPHY_LN5_CSI_3PH_CTRLn_ADDR(11), 0x00, 0x00, CSIPHY_DEFAULT_PARAMS},
+	{CSIPHY_LN5_CSI_3PH_CTRLn_ADDR(17), 0xB2, 0x00, CSIPHY_DEFAULT_PARAMS},
+	{CSIPHY_LN5_CSI_3PH_CTRLn_ADDR(24), 0x02, 0x00, CSIPHY_DEFAULT_PARAMS},
+	{CSIPHY_LN5_CSI_3PH_CTRLn_ADDR(51), 0x41, 0x00, CSIPHY_DEFAULT_PARAMS},
+	{CSIPHY_LN5_CSI_3PH_CTRLn_ADDR(25), 0x33, 0x00, CSIPHY_DEFAULT_PARAMS},
+	{CSIPHY_LN5_CSI_3PH_CTRLn_ADDR(55), 0x50, 0x00, CSIPHY_DEFAULT_PARAMS},
+	{CSIPHY_LN9_CSI_3PH_CTRLn_ADDR(33), 0x20, 0x00, CSIPHY_DEFAULT_PARAMS},
+	{CSIPHY_LN9_CSI_3PH_CTRLn_ADDR(34), 0x05, 0x00, CSIPHY_DEFAULT_PARAMS},
+	{CSIPHY_LN9_CSI_3PH_CTRLn_ADDR(32), 0x61, 0x00, CSIPHY_DEFAULT_PARAMS},
+	{CSIPHY_LN9_CSI_3PH_CTRLn_ADDR(44), 0x01, 0x00, CSIPHY_DEFAULT_PARAMS},
+	{CSIPHY_LN9_CSI_3PH_CTRLn_ADDR(45), 0x08, 0x00, CSIPHY_DEFAULT_PARAMS},
+	{CSIPHY_LN10_CSI_3PH_CTRLn_ADDR(33), 0x20, 0x00, CSIPHY_DEFAULT_PARAMS},
+	{CSIPHY_LN10_CSI_3PH_CTRLn_ADDR(34), 0x05, 0x00, CSIPHY_DEFAULT_PARAMS},
+	{CSIPHY_LN10_CSI_3PH_CTRLn_ADDR(32), 0x61, 0x00, CSIPHY_DEFAULT_PARAMS},
+	{CSIPHY_LN10_CSI_3PH_CTRLn_ADDR(44), 0x01, 0x00, CSIPHY_DEFAULT_PARAMS},
+	{CSIPHY_LN10_CSI_3PH_CTRLn_ADDR(45), 0x08, 0x00, CSIPHY_DEFAULT_PARAMS},
+	{CSIPHY_LN11_CSI_3PH_CTRLn_ADDR(33), 0x20, 0x00, CSIPHY_DEFAULT_PARAMS},
+	{CSIPHY_LN11_CSI_3PH_CTRLn_ADDR(34), 0x05, 0x00, CSIPHY_DEFAULT_PARAMS},
+	{CSIPHY_LN11_CSI_3PH_CTRLn_ADDR(32), 0x61, 0x00, CSIPHY_DEFAULT_PARAMS},
+	{CSIPHY_LN11_CSI_3PH_CTRLn_ADDR(44), 0x01, 0x00, CSIPHY_DEFAULT_PARAMS},
+	{CSIPHY_LN11_CSI_3PH_CTRLn_ADDR(45), 0x08, 0x00, CSIPHY_DEFAULT_PARAMS},
+	{CSIPHY_LN1_CSI_3PH_CTRLn_ADDR(23), 0x46, 0x00, CSIPHY_DEFAULT_PARAMS},
+	{CSIPHY_LN1_CSI_3PH_CTRLn_ADDR(26), 0x80, 0x00, CSIPHY_DEFAULT_PARAMS},
+	{CSIPHY_LN1_CSI_3PH_CTRLn_ADDR(27), 0x25, 0x00, CSIPHY_DEFAULT_PARAMS},
+	{CSIPHY_LN1_CSI_3PH_CTRLn_ADDR(3),  0x24, 0x00, CSIPHY_SETTLE_CNT_LOWER_BYTE},
+	{CSIPHY_LN3_CSI_3PH_CTRLn_ADDR(23), 0x46, 0x00, CSIPHY_DEFAULT_PARAMS},
+	{CSIPHY_LN3_CSI_3PH_CTRLn_ADDR(26), 0x80, 0x00, CSIPHY_DEFAULT_PARAMS},
+	{CSIPHY_LN3_CSI_3PH_CTRLn_ADDR(27), 0x25, 0x00, CSIPHY_DEFAULT_PARAMS},
+	{CSIPHY_LN3_CSI_3PH_CTRLn_ADDR(3),  0x24, 0x00, CSIPHY_SETTLE_CNT_LOWER_BYTE},
+	{CSIPHY_LN5_CSI_3PH_CTRLn_ADDR(23), 0x46, 0x00, CSIPHY_DEFAULT_PARAMS},
+	{CSIPHY_LN5_CSI_3PH_CTRLn_ADDR(26), 0x80, 0x00, CSIPHY_DEFAULT_PARAMS},
+	{CSIPHY_LN5_CSI_3PH_CTRLn_ADDR(27), 0x25, 0x00, CSIPHY_DEFAULT_PARAMS},
+	{CSIPHY_LN5_CSI_3PH_CTRLn_ADDR(3),  0x24, 0x00, CSIPHY_SETTLE_CNT_LOWER_BYTE},
+	{CSIPHY_LN9_CSI_3PH_CTRLn_ADDR(45), 0x08, 0x00, CSIPHY_DEFAULT_PARAMS},
+	{CSIPHY_LN10_CSI_3PH_CTRLn_ADDR(45), 0x08, 0x00, CSIPHY_DEFAULT_PARAMS},
+	{CSIPHY_LN11_CSI_3PH_CTRLn_ADDR(45), 0x08, 0x00, CSIPHY_DEFAULT_PARAMS},
+};
+
 /* GEN2 1.0 2PH */
 /* 5 entries: clock + 4 lanes */
 static const struct
@@ -1315,7 +1416,6 @@ static void csiphy_lanes_enable(struct csiphy_device *csiphy,
 		}
 		break;
 	case CAMSS_8300:
-	case CAMSS_8775P:
 		if (c->phy_cfg == V4L2_MBUS_CSI2_DPHY) {
 			regs->lane_regs = &lane_regs_sa8775p[0];
 			regs->lane_array_size = ARRAY_SIZE(lane_regs_sa8775p);
@@ -1324,6 +1424,15 @@ static void csiphy_lanes_enable(struct csiphy_device *csiphy,
 			regs->lane_array_size = 0;
 		}
 		break;
+	case CAMSS_8775P:
+		if (c->phy_cfg == V4L2_MBUS_CSI2_CPHY) {
+			regs->lane_regs = &lane_regs_sa8775p_3ph[0];
+			regs->lane_array_size = ARRAY_SIZE(lane_regs_sa8775p_3ph);
+		} else {
+			regs->lane_regs = &lane_regs_sa8775p[0];
+			regs->lane_array_size = ARRAY_SIZE(lane_regs_sa8775p);
+		}
+		break;
 	default:
 		break;
 	}
-- 
2.34.1

[PATCH 4/6] media: qcom: camss: Add sa8300 C-PHY 3ph lane config

[Anusha Arun Nandi]

Share the C-PHY/D-PHY lane_regs selection for CAMSS_8300 so
the sa8300 platform uses the same 3ph handling as CAMSS_8775P. Also drop
CAMSS_8300 from the missing-C-PHY-table guard now that a C-PHY table is
provided.

Co-developed-by: Jigarkumar Zala <jigarkumar.zala@oss.qualcomm.com>
Signed-off-by: Jigarkumar Zala <jigarkumar.zala@oss.qualcomm.com>
Signed-off-by: Anusha Arun Nandi <anusha.nandi@oss.qualcomm.com>
---
 drivers/media/platform/qcom/camss/camss-csiphy-3ph-1-0.c | 8 --------
 1 file changed, 8 deletions(-)

diff --git a/drivers/media/platform/qcom/camss/camss-csiphy-3ph-1-0.c b/drivers/media/platform/qcom/camss/camss-csiphy-3ph-1-0.c
index 8f1e70ad2b7d..0d5d4d4410f2 100644
--- a/drivers/media/platform/qcom/camss/camss-csiphy-3ph-1-0.c
+++ b/drivers/media/platform/qcom/camss/camss-csiphy-3ph-1-0.c
@@ -1416,14 +1416,6 @@ static void csiphy_lanes_enable(struct csiphy_device *csiphy,
 		}
 		break;
 	case CAMSS_8300:
-		if (c->phy_cfg == V4L2_MBUS_CSI2_DPHY) {
-			regs->lane_regs = &lane_regs_sa8775p[0];
-			regs->lane_array_size = ARRAY_SIZE(lane_regs_sa8775p);
-		} else if (c->phy_cfg == V4L2_MBUS_CSI2_CPHY) {
-			regs->lane_regs = NULL;
-			regs->lane_array_size = 0;
-		}
-		break;
 	case CAMSS_8775P:
 		if (c->phy_cfg == V4L2_MBUS_CSI2_CPHY) {
 			regs->lane_regs = &lane_regs_sa8775p_3ph[0];
-- 
2.34.1

[PATCH 5/6] media: qcom: camss: Dynamic data-rate specific C-PHY register settings

[Anusha Arun Nandi]

The C-PHY PHY register configuration needs to vary with the link
(symbol) data rate. Until now only a single base lane_regs table was
applied per platform, regardless of the negotiated rate.

Introduce a data-rate selection mechanism for C-PHY:

 - Add struct data_rate_reg_info describing a per-bandwidth register
   override table.
 - Add csiphy_cphy_data_rate_config(), which selects the first table
   entry whose bandwidth satisfies the required PHY data rate (derived
   from the resolved link frequency) and writes those overrides on top
   of the base lane_regs configuration. The settle-count parameter
   types are handled specially. When the link frequency cannot be
   resolved, it falls back to the lowest supported rate.

 - Add per-data-rate register tables and data_rate_settings tables for
   sa8775p and 8300(1.5/1.7/2.5/3.5/4.5 GSpS)
   and sm8250 (2.5/3.5/4.5 GSpS).

 - Select the appropriate data-rate settings table in
   csiphy_lanes_enable() for both platforms when the endpoint is
   configured for C-PHY.

Co-developed-by: Jigarkumar Zala <jigarkumar.zala@oss.qualcomm.com>
Signed-off-by: Jigarkumar Zala <jigarkumar.zala@oss.qualcomm.com>
Signed-off-by: Anusha Arun Nandi <anusha.nandi@oss.qualcomm.com>
---
 .../qcom/camss/camss-csiphy-3ph-1-0.c         | 249 ++++++++++++++++++
 .../media/platform/qcom/camss/camss-csiphy.h  |   6 +
 2 files changed, 255 insertions(+)

diff --git a/drivers/media/platform/qcom/camss/camss-csiphy-3ph-1-0.c b/drivers/media/platform/qcom/camss/camss-csiphy-3ph-1-0.c
index 0d5d4d4410f2..77484cbb6c15 100644
--- a/drivers/media/platform/qcom/camss/camss-csiphy-3ph-1-0.c
+++ b/drivers/media/platform/qcom/camss/camss-csiphy-3ph-1-0.c
@@ -72,6 +72,8 @@
 #define CSIPHY_3PH_REGS			6
 #define CSIPHY_SKEW_CAL			7
 
+#define CSIPHY_CPHY_DATA_RATE_DEFAULT_IDX	0
+
 struct csiphy_lane_regs {
 	s32 reg_addr;
 	s32 reg_data;
@@ -236,6 +238,9 @@ csiphy_lane_regs lane_regs_sa8775p_3ph[] = {
 	{CSIPHY_LN11_CSI_3PH_CTRLn_ADDR(32), 0x61, 0x00, CSIPHY_DEFAULT_PARAMS},
 	{CSIPHY_LN11_CSI_3PH_CTRLn_ADDR(44), 0x01, 0x00, CSIPHY_DEFAULT_PARAMS},
 	{CSIPHY_LN11_CSI_3PH_CTRLn_ADDR(45), 0x08, 0x00, CSIPHY_DEFAULT_PARAMS},
+};
+
+struct csiphy_lane_regs datarate_sa8775p_3ph_1p5Gsps[] = {
 	{CSIPHY_LN1_CSI_3PH_CTRLn_ADDR(23), 0x46, 0x00, CSIPHY_DEFAULT_PARAMS},
 	{CSIPHY_LN1_CSI_3PH_CTRLn_ADDR(26), 0x80, 0x00, CSIPHY_DEFAULT_PARAMS},
 	{CSIPHY_LN1_CSI_3PH_CTRLn_ADDR(27), 0x25, 0x00, CSIPHY_DEFAULT_PARAMS},
@@ -253,6 +258,183 @@ csiphy_lane_regs lane_regs_sa8775p_3ph[] = {
 	{CSIPHY_LN11_CSI_3PH_CTRLn_ADDR(45), 0x08, 0x00, CSIPHY_DEFAULT_PARAMS},
 };
 
+struct csiphy_lane_regs datarate_sa8775p_3ph_1p7Gsps[] = {
+	{CSIPHY_LN1_CSI_3PH_CTRLn_ADDR(23), 0x56, 0x00, CSIPHY_DEFAULT_PARAMS},
+	{CSIPHY_LN1_CSI_3PH_CTRLn_ADDR(26), 0xAE, 0x00, CSIPHY_DEFAULT_PARAMS},
+	{CSIPHY_LN1_CSI_3PH_CTRLn_ADDR(27), 0x65, 0x00, CSIPHY_DEFAULT_PARAMS},
+	{CSIPHY_LN1_CSI_3PH_CTRLn_ADDR(3),  0x12, 0x00, CSIPHY_SETTLE_CNT_LOWER_BYTE},
+	{CSIPHY_LN3_CSI_3PH_CTRLn_ADDR(23), 0x56, 0x00, CSIPHY_DEFAULT_PARAMS},
+	{CSIPHY_LN3_CSI_3PH_CTRLn_ADDR(26), 0xAE, 0x00, CSIPHY_DEFAULT_PARAMS},
+	{CSIPHY_LN3_CSI_3PH_CTRLn_ADDR(27), 0x65, 0x00, CSIPHY_DEFAULT_PARAMS},
+	{CSIPHY_LN3_CSI_3PH_CTRLn_ADDR(3),  0x12, 0x00, CSIPHY_SETTLE_CNT_LOWER_BYTE},
+	{CSIPHY_LN5_CSI_3PH_CTRLn_ADDR(23), 0x56, 0x00, CSIPHY_DEFAULT_PARAMS},
+	{CSIPHY_LN5_CSI_3PH_CTRLn_ADDR(26), 0xAE, 0x00, CSIPHY_DEFAULT_PARAMS},
+	{CSIPHY_LN5_CSI_3PH_CTRLn_ADDR(27), 0x65, 0x00, CSIPHY_DEFAULT_PARAMS},
+	{CSIPHY_LN5_CSI_3PH_CTRLn_ADDR(3),  0x12, 0x00, CSIPHY_SETTLE_CNT_LOWER_BYTE},
+	{CSIPHY_LN9_CSI_3PH_CTRLn_ADDR(45),  0x08, 0x00, CSIPHY_DEFAULT_PARAMS},
+	{CSIPHY_LN10_CSI_3PH_CTRLn_ADDR(45), 0x08, 0x00, CSIPHY_DEFAULT_PARAMS},
+	{CSIPHY_LN11_CSI_3PH_CTRLn_ADDR(45), 0x08, 0x00, CSIPHY_DEFAULT_PARAMS},
+};
+
+struct csiphy_lane_regs datarate_sa8775p_3ph_2p5Gsps[] = {
+	{CSIPHY_LN1_CSI_3PH_CTRLn_ADDR(26), 0x80, 0x00, CSIPHY_DEFAULT_PARAMS},
+	{CSIPHY_LN1_CSI_3PH_CTRLn_ADDR(23), 0xC8, 0x00, CSIPHY_DEFAULT_PARAMS},
+	{CSIPHY_LN1_CSI_3PH_CTRLn_ADDR(27), 0x25, 0x00, CSIPHY_DEFAULT_PARAMS},
+	{CSIPHY_LN1_CSI_3PH_CTRLn_ADDR(3),  0x08, 0x00, CSIPHY_SETTLE_CNT_LOWER_BYTE},
+	{CSIPHY_LN3_CSI_3PH_CTRLn_ADDR(26), 0x80, 0x00, CSIPHY_DEFAULT_PARAMS},
+	{CSIPHY_LN3_CSI_3PH_CTRLn_ADDR(23), 0xC8, 0x00, CSIPHY_DEFAULT_PARAMS},
+	{CSIPHY_LN3_CSI_3PH_CTRLn_ADDR(27), 0x25, 0x00, CSIPHY_DEFAULT_PARAMS},
+	{CSIPHY_LN3_CSI_3PH_CTRLn_ADDR(3),  0x08, 0x00, CSIPHY_SETTLE_CNT_LOWER_BYTE},
+	{CSIPHY_LN5_CSI_3PH_CTRLn_ADDR(26), 0x80, 0x00, CSIPHY_DEFAULT_PARAMS},
+	{CSIPHY_LN5_CSI_3PH_CTRLn_ADDR(23), 0xC8, 0x00, CSIPHY_DEFAULT_PARAMS},
+	{CSIPHY_LN5_CSI_3PH_CTRLn_ADDR(27), 0x25, 0x00, CSIPHY_DEFAULT_PARAMS},
+	{CSIPHY_LN5_CSI_3PH_CTRLn_ADDR(3),  0x08, 0x00, CSIPHY_SETTLE_CNT_LOWER_BYTE},
+	{CSIPHY_LN9_CSI_3PH_CTRLn_ADDR(45),  0x08, 0x00, CSIPHY_DEFAULT_PARAMS},
+	{CSIPHY_LN9_CSI_3PH_CTRLn_ADDR(34),  0x05, 0x00, CSIPHY_DEFAULT_PARAMS},
+	{CSIPHY_LN10_CSI_3PH_CTRLn_ADDR(45), 0x08, 0x00, CSIPHY_DEFAULT_PARAMS},
+	{CSIPHY_LN10_CSI_3PH_CTRLn_ADDR(34), 0x05, 0x00, CSIPHY_DEFAULT_PARAMS},
+	{CSIPHY_LN11_CSI_3PH_CTRLn_ADDR(45), 0x08, 0x00, CSIPHY_DEFAULT_PARAMS},
+	{CSIPHY_LN11_CSI_3PH_CTRLn_ADDR(34), 0x05, 0x00, CSIPHY_DEFAULT_PARAMS},
+};
+
+struct csiphy_lane_regs datarate_sa8775p_3ph_3p5Gsps[] = {
+	{CSIPHY_LN1_CSI_3PH_CTRLn_ADDR(26), 0x80, 0x00, CSIPHY_DEFAULT_PARAMS},
+	{CSIPHY_LN1_CSI_3PH_CTRLn_ADDR(23), 0x46, 0x00, CSIPHY_DEFAULT_PARAMS},
+	{CSIPHY_LN1_CSI_3PH_CTRLn_ADDR(27), 0x25, 0x00, CSIPHY_DEFAULT_PARAMS},
+	{CSIPHY_LN1_CSI_3PH_CTRLn_ADDR(3),  0x08, 0x00, CSIPHY_SETTLE_CNT_LOWER_BYTE},
+	{CSIPHY_LN3_CSI_3PH_CTRLn_ADDR(26), 0x80, 0x00, CSIPHY_DEFAULT_PARAMS},
+	{CSIPHY_LN3_CSI_3PH_CTRLn_ADDR(23), 0x46, 0x00, CSIPHY_DEFAULT_PARAMS},
+	{CSIPHY_LN3_CSI_3PH_CTRLn_ADDR(27), 0x25, 0x00, CSIPHY_DEFAULT_PARAMS},
+	{CSIPHY_LN3_CSI_3PH_CTRLn_ADDR(3),  0x08, 0x00, CSIPHY_SETTLE_CNT_LOWER_BYTE},
+	{CSIPHY_LN5_CSI_3PH_CTRLn_ADDR(26), 0x80, 0x00, CSIPHY_DEFAULT_PARAMS},
+	{CSIPHY_LN5_CSI_3PH_CTRLn_ADDR(23), 0x46, 0x00, CSIPHY_DEFAULT_PARAMS},
+	{CSIPHY_LN5_CSI_3PH_CTRLn_ADDR(27), 0x25, 0x00, CSIPHY_DEFAULT_PARAMS},
+	{CSIPHY_LN5_CSI_3PH_CTRLn_ADDR(3),  0x08, 0x00, CSIPHY_SETTLE_CNT_LOWER_BYTE},
+	{CSIPHY_LN9_CSI_3PH_CTRLn_ADDR(45),  0x05, 0x00, CSIPHY_DEFAULT_PARAMS},
+	{CSIPHY_LN9_CSI_3PH_CTRLn_ADDR(34),  0x05, 0x00, CSIPHY_DEFAULT_PARAMS},
+	{CSIPHY_LN10_CSI_3PH_CTRLn_ADDR(45), 0x05, 0x00, CSIPHY_DEFAULT_PARAMS},
+	{CSIPHY_LN10_CSI_3PH_CTRLn_ADDR(34), 0x05, 0x00, CSIPHY_DEFAULT_PARAMS},
+	{CSIPHY_LN11_CSI_3PH_CTRLn_ADDR(45), 0x05, 0x00, CSIPHY_DEFAULT_PARAMS},
+	{CSIPHY_LN11_CSI_3PH_CTRLn_ADDR(34), 0x05, 0x00, CSIPHY_DEFAULT_PARAMS},
+};
+
+struct csiphy_lane_regs datarate_sa8775p_3ph_4p5Gsps[] = {
+	{CSIPHY_LN1_CSI_3PH_CTRLn_ADDR(26), 0x80, 0x00, CSIPHY_DEFAULT_PARAMS},
+	{CSIPHY_LN1_CSI_3PH_CTRLn_ADDR(23), 0x46, 0x00, CSIPHY_DEFAULT_PARAMS},
+	{CSIPHY_LN1_CSI_3PH_CTRLn_ADDR(27), 0x25, 0x00, CSIPHY_DEFAULT_PARAMS},
+	{CSIPHY_LN1_CSI_3PH_CTRLn_ADDR(3),  0x08, 0x00, CSIPHY_SETTLE_CNT_LOWER_BYTE},
+	{CSIPHY_LN3_CSI_3PH_CTRLn_ADDR(26), 0x80, 0x00, CSIPHY_DEFAULT_PARAMS},
+	{CSIPHY_LN3_CSI_3PH_CTRLn_ADDR(23), 0x46, 0x00, CSIPHY_DEFAULT_PARAMS},
+	{CSIPHY_LN3_CSI_3PH_CTRLn_ADDR(27), 0x25, 0x00, CSIPHY_DEFAULT_PARAMS},
+	{CSIPHY_LN3_CSI_3PH_CTRLn_ADDR(3),  0x08, 0x00, CSIPHY_SETTLE_CNT_LOWER_BYTE},
+	{CSIPHY_LN5_CSI_3PH_CTRLn_ADDR(26), 0x80, 0x00, CSIPHY_DEFAULT_PARAMS},
+	{CSIPHY_LN5_CSI_3PH_CTRLn_ADDR(23), 0x46, 0x00, CSIPHY_DEFAULT_PARAMS},
+	{CSIPHY_LN5_CSI_3PH_CTRLn_ADDR(27), 0x25, 0x00, CSIPHY_DEFAULT_PARAMS},
+	{CSIPHY_LN5_CSI_3PH_CTRLn_ADDR(3),  0x08, 0x00, CSIPHY_SETTLE_CNT_LOWER_BYTE},
+	{CSIPHY_LN9_CSI_3PH_CTRLn_ADDR(45),  0x02, 0x00, CSIPHY_DEFAULT_PARAMS},
+	{CSIPHY_LN9_CSI_3PH_CTRLn_ADDR(34),  0x05, 0x00, CSIPHY_DEFAULT_PARAMS},
+	{CSIPHY_LN10_CSI_3PH_CTRLn_ADDR(45), 0x02, 0x00, CSIPHY_DEFAULT_PARAMS},
+	{CSIPHY_LN10_CSI_3PH_CTRLn_ADDR(34), 0x05, 0x00, CSIPHY_DEFAULT_PARAMS},
+	{CSIPHY_LN11_CSI_3PH_CTRLn_ADDR(45), 0x02, 0x00, CSIPHY_DEFAULT_PARAMS},
+	{CSIPHY_LN11_CSI_3PH_CTRLn_ADDR(34), 0x05, 0x00, CSIPHY_DEFAULT_PARAMS},
+};
+
+static struct data_rate_reg_info data_rate_settings_sa8775p_3ph[] = {
+	{
+		/* 1.5 GSpS */
+		.bandwidth = 1500000000,
+		.data_rate_reg_array_size = ARRAY_SIZE(datarate_sa8775p_3ph_1p5Gsps),
+		.data_rate_reg_array = datarate_sa8775p_3ph_1p5Gsps,
+	},
+	{
+		/* 1.7 GSpS */
+		.bandwidth = 1700000000,
+		.data_rate_reg_array_size = ARRAY_SIZE(datarate_sa8775p_3ph_1p7Gsps),
+		.data_rate_reg_array = datarate_sa8775p_3ph_1p7Gsps,
+	},
+	{
+		/* 2.5 GSpS */
+		.bandwidth = 2500000000,
+		.data_rate_reg_array_size = ARRAY_SIZE(datarate_sa8775p_3ph_2p5Gsps),
+		.data_rate_reg_array = datarate_sa8775p_3ph_2p5Gsps,
+	},
+	{
+		/* 3.5 GSpS */
+		.bandwidth = 3500000000,
+		.data_rate_reg_array_size = ARRAY_SIZE(datarate_sa8775p_3ph_3p5Gsps),
+		.data_rate_reg_array = datarate_sa8775p_3ph_3p5Gsps,
+	},
+	{
+		/* 4.5 GSpS */
+		.bandwidth = 4500000000,
+		.data_rate_reg_array_size = ARRAY_SIZE(datarate_sa8775p_3ph_4p5Gsps),
+		.data_rate_reg_array = datarate_sa8775p_3ph_4p5Gsps,
+	},
+};
+
+struct csiphy_lane_regs datarate_sm8250_3ph_2p5Gsps[] = {
+	{0x144, 0x32, 0x00, CSIPHY_DEFAULT_PARAMS},
+	{0x164, 0x0B, 0x00, CSIPHY_DEFAULT_PARAMS},
+	{0x16C, 0x25, 0x00, CSIPHY_DEFAULT_PARAMS},
+	{0x344, 0x32, 0x00, CSIPHY_DEFAULT_PARAMS},
+	{0x364, 0x0B, 0x00, CSIPHY_DEFAULT_PARAMS},
+	{0x36C, 0x25, 0x00, CSIPHY_DEFAULT_PARAMS},
+	{0x544, 0x32, 0x00, CSIPHY_DEFAULT_PARAMS},
+	{0x564, 0x0B, 0x00, CSIPHY_DEFAULT_PARAMS},
+	{0x56C, 0x25, 0x00, CSIPHY_DEFAULT_PARAMS},
+};
+
+struct csiphy_lane_regs datarate_sm8250_3ph_3p5Gsps[] = {
+	{0x144, 0xB2, 0x00, CSIPHY_DEFAULT_PARAMS},
+	{0x164, 0x33, 0x00, CSIPHY_DEFAULT_PARAMS},
+	{0x16C, 0x1D, 0x00, CSIPHY_DEFAULT_PARAMS},
+	{0x9B4, 0x03, 0x01, CSIPHY_DEFAULT_PARAMS},
+	{0x344, 0xB2, 0x00, CSIPHY_DEFAULT_PARAMS},
+	{0x364, 0x33, 0x00, CSIPHY_DEFAULT_PARAMS},
+	{0x36C, 0x1D, 0x00, CSIPHY_DEFAULT_PARAMS},
+	{0xAB4, 0x03, 0x01, CSIPHY_DEFAULT_PARAMS},
+	{0x544, 0xB2, 0x00, CSIPHY_DEFAULT_PARAMS},
+	{0x564, 0x33, 0x00, CSIPHY_DEFAULT_PARAMS},
+	{0x56C, 0x1D, 0x00, CSIPHY_DEFAULT_PARAMS},
+	{0xBB4, 0x03, 0x01, CSIPHY_DEFAULT_PARAMS},
+};
+
+struct csiphy_lane_regs datarate_sm8250_3ph_4p5Gsps[] = {
+	{0x144, 0xB2, 0x00, CSIPHY_DEFAULT_PARAMS},
+	{0x164, 0x33, 0x00, CSIPHY_DEFAULT_PARAMS},
+	{0x16C, 0x25, 0x00, CSIPHY_DEFAULT_PARAMS},
+	{0x9B4, 0x02, 0x01, CSIPHY_DEFAULT_PARAMS},
+	{0x344, 0xB2, 0x00, CSIPHY_DEFAULT_PARAMS},
+	{0x364, 0x33, 0x00, CSIPHY_DEFAULT_PARAMS},
+	{0x36C, 0x25, 0x00, CSIPHY_DEFAULT_PARAMS},
+	{0xAB4, 0x02, 0x01, CSIPHY_DEFAULT_PARAMS},
+	{0x544, 0xB2, 0x00, CSIPHY_DEFAULT_PARAMS},
+	{0x564, 0x33, 0x00, CSIPHY_DEFAULT_PARAMS},
+	{0x56C, 0x25, 0x00, CSIPHY_DEFAULT_PARAMS},
+	{0xBB4, 0x02, 0x01, CSIPHY_DEFAULT_PARAMS},
+};
+
+static struct data_rate_reg_info data_rate_settings_sm8250_3ph[] = {
+	{
+		/* 2.5 GSpS */
+		.bandwidth = 2500000000,
+		.data_rate_reg_array_size = ARRAY_SIZE(datarate_sm8250_3ph_2p5Gsps),
+		.data_rate_reg_array = datarate_sm8250_3ph_2p5Gsps,
+	},
+	{
+		/* 3.5 GSpS */
+		.bandwidth = 3500000000,
+		.data_rate_reg_array_size = ARRAY_SIZE(datarate_sm8250_3ph_3p5Gsps),
+		.data_rate_reg_array = datarate_sm8250_3ph_3p5Gsps,
+	},
+	{
+		/* 4.5 GSpS */
+		.bandwidth = 4500000000,
+		.data_rate_reg_array_size = ARRAY_SIZE(datarate_sm8250_3ph_4p5Gsps),
+		.data_rate_reg_array = datarate_sm8250_3ph_4p5Gsps,
+	},
+};
+
 /* GEN2 1.0 2PH */
 /* 5 entries: clock + 4 lanes */
 static const struct
@@ -1257,6 +1439,60 @@ static void csiphy_gen1_config_lanes(struct csiphy_device *csiphy,
 	writel_relaxed(val, csiphy->base + CSIPHY_3PH_LNn_MISC1(l));
 }
 
+/*
+ * csiphy_cphy_data_rate_config - Apply data-rate specific C-PHY overrides
+ *
+ * Applied on top of the base lane_regs. Selects the first table entry whose
+ * bandwidth >= the data rate derived from @link_freq (highest entry if none
+ * qualifies, default entry if @link_freq is unknown) and writes its overrides.
+ */
+static void csiphy_cphy_data_rate_config(struct csiphy_device *csiphy,
+					 struct data_rate_reg_info *settings,
+					 size_t num_settings,
+					 s64 link_freq, u8 settle_cnt)
+{
+	struct device *dev = csiphy->camss->dev;
+	const struct csiphy_lane_regs *r;
+	size_t idx, i;
+	u32 val;
+
+	if (!settings || !num_settings)
+		return;
+
+	if (!link_freq) {
+		/* Link frequency unknown; use the default (lowest) entry. */
+		idx = CSIPHY_CPHY_DATA_RATE_DEFAULT_IDX;
+	} else {
+		/* First entry that satisfies the rate, else the highest. */
+		for (idx = 0; idx < num_settings; idx++) {
+			if (settings[idx].bandwidth >= link_freq)
+				break;
+		}
+	}
+
+	dev_dbg(dev,
+		"CSIPHY using specific bandwidth %llu bits/s (entry %zu) for link_freq %lld\n",
+		settings[idx].bandwidth, idx, link_freq);
+
+	r = settings[idx].data_rate_reg_array;
+	for (i = 0; i < settings[idx].data_rate_reg_array_size; i++, r++) {
+		switch (r->csiphy_param_type) {
+		case CSIPHY_SETTLE_CNT_LOWER_BYTE:
+			val = settle_cnt & 0xff;
+			break;
+		case CSIPHY_SETTLE_CNT_HIGHER_BYTE:
+			val = (settle_cnt >> 8) & 0xff;
+			break;
+		default:
+			val = r->reg_data;
+			break;
+		}
+		writel_relaxed(val, csiphy->base + r->reg_addr);
+		if (r->delay_us)
+			udelay(r->delay_us);
+	}
+}
+
 static void csiphy_gen2_config_lanes(struct csiphy_device *csiphy,
 				     u8 settle_cnt)
 {
@@ -1336,6 +1572,8 @@ static void csiphy_lanes_enable(struct csiphy_device *csiphy,
 {
 	struct csiphy_lanes_cfg *c = &cfg->csi2->lane_cfg;
 	struct csiphy_device_regs *regs = csiphy->regs;
+	struct data_rate_reg_info *data_rate_settings = NULL;
+	size_t num_data_rate_settings = 0;
 	u8 settle_cnt;
 	u8 val;
 	int i;
@@ -1420,6 +1658,8 @@ static void csiphy_lanes_enable(struct csiphy_device *csiphy,
 		if (c->phy_cfg == V4L2_MBUS_CSI2_CPHY) {
 			regs->lane_regs = &lane_regs_sa8775p_3ph[0];
 			regs->lane_array_size = ARRAY_SIZE(lane_regs_sa8775p_3ph);
+			data_rate_settings = data_rate_settings_sa8775p_3ph;
+			num_data_rate_settings = ARRAY_SIZE(data_rate_settings_sa8775p_3ph);
 		} else {
 			regs->lane_regs = &lane_regs_sa8775p[0];
 			regs->lane_array_size = ARRAY_SIZE(lane_regs_sa8775p);
@@ -1483,6 +1723,15 @@ static void csiphy_lanes_enable(struct csiphy_device *csiphy,
 	else
 		csiphy_gen1_config_lanes(csiphy, cfg, settle_cnt);
 
+	/*
+	 * For C-PHY platforms with a data-rate settings table, apply the
+	 * data-rate specific overrides on top of the base lane_regs config.
+	 */
+	if (c->phy_cfg == V4L2_MBUS_CSI2_CPHY && data_rate_settings)
+		csiphy_cphy_data_rate_config(csiphy, data_rate_settings,
+					     num_data_rate_settings,
+					     link_freq, settle_cnt);
+
 	/* IRQ_MASK registers - disable all interrupts */
 	for (i = 11; i < 22; i++) {
 		writel_relaxed(0, csiphy->base +
diff --git a/drivers/media/platform/qcom/camss/camss-csiphy.h b/drivers/media/platform/qcom/camss/camss-csiphy.h
index 2ebb307be18b..6578802823d3 100644
--- a/drivers/media/platform/qcom/camss/camss-csiphy.h
+++ b/drivers/media/platform/qcom/camss/camss-csiphy.h
@@ -62,6 +62,12 @@ struct csiphy_formats {
 	const struct csiphy_format_info *formats;
 };
 
+struct data_rate_reg_info {
+	u64 bandwidth;
+	ssize_t  data_rate_reg_array_size;
+	struct csiphy_lane_regs *data_rate_reg_array;
+};
+
 struct csiphy_device;
 
 struct csiphy_hw_ops {
-- 
2.34.1

[PATCH 6/6] media: qcom: camss: validate local/remote endpoint bus-type

[Anusha Arun Nandi]

A link is invalid if the local CSIPHY endpoint and the remote sensor
endpoint describe different bus types. Such a mismatch can otherwise go
undetected until later probe or streaming failures.

Parse the remote endpoint in camss_parse_endpoint_node() and compare its
bus-type with the local endpoint. Reject the link with -EINVAL if the two
ends disagree, so C-PHY/D-PHY mismatches are caught early during probe.

Co-developed-by: Jigarkumar Zala <jigarkumar.zala@oss.qualcomm.com>
Signed-off-by: Jigarkumar Zala <jigarkumar.zala@oss.qualcomm.com>
Signed-off-by: Anusha Arun Nandi <anusha.nandi@oss.qualcomm.com>
---
 drivers/media/platform/qcom/camss/camss.c | 28 ++++++++++++++++++++++-
 1 file changed, 27 insertions(+), 1 deletion(-)

diff --git a/drivers/media/platform/qcom/camss/camss.c b/drivers/media/platform/qcom/camss/camss.c
index ebf8f21b5fa2..8013aafde6a9 100644
--- a/drivers/media/platform/qcom/camss/camss.c
+++ b/drivers/media/platform/qcom/camss/camss.c
@@ -4757,7 +4757,9 @@ static int camss_parse_endpoint_node(struct device *dev,
 {
 	struct csiphy_lanes_cfg *lncfg = &csd->interface.csi2.lane_cfg;
 	struct v4l2_mbus_config_mipi_csi2 *mipi_csi2;
-	struct v4l2_fwnode_endpoint vep = { { 0 } };
+	struct v4l2_fwnode_endpoint vep = { .bus_type = V4L2_MBUS_UNKNOWN };
+	struct v4l2_fwnode_endpoint remote_vep = { .bus_type = V4L2_MBUS_UNKNOWN };
+	struct fwnode_handle *remote_ep;
 	unsigned int i;
 	int ret;
 
@@ -4774,6 +4776,30 @@ static int camss_parse_endpoint_node(struct device *dev,
 		return -EINVAL;
 	}
 
+	/* Get the remote (sensor) endpoint handle, e.g. imx686_ep1 */
+	remote_ep = fwnode_graph_get_remote_endpoint(ep);
+	if (!remote_ep) {
+		dev_dbg(dev, "No remote endpoint found for %pfw\n", ep);
+		return -ENODEV;
+	}
+
+	/* Parse the remote bus type and release the handle */
+	ret = v4l2_fwnode_endpoint_parse(remote_ep, &remote_vep);
+	fwnode_handle_put(remote_ep);
+	if (ret) {
+		dev_dbg(dev, "Failed to parse remote endpoint\n");
+		return ret;
+	}
+
+	/* The local (CSIPHY) and remote (sensor) ends must agree */
+	if (vep.bus_type != remote_vep.bus_type) {
+		dev_dbg(dev, "Bus type mismatch! Local (CSI-PHY): %u, Remote (Sensor): %u\n",
+			vep.bus_type, remote_vep.bus_type);
+		return -EINVAL;
+	}
+
+	dev_dbg(dev, "Verified link: both ends use bus-type %u\n", vep.bus_type);
+
 	csd->interface.csiphy_id = vep.base.port;
 
 	mipi_csi2 = &vep.bus.mipi_csi2;
-- 
2.34.1

Re: [PATCH 0/6] media: qcom: camss: Add C-PHY support for sa8775p, sa8300 and sm8250

[Bryan O'Donoghue]

On 18/07/2026 00:13, Anusha Arun Nandi wrote:
> This series extends the Qualcomm CAMSS (Camera Subsystem) C-PHY support to
> the Gen3 platforms, adding C-PHY mode configuration for sa8775p
> (CAMSS_8775P) and sa8300 (CAMSS_8300), along with a dynamic, data-rate
> specific C-PHY register programming mechanism.
> 
> It builds on David Heidelberg's C-PHY enablement work for Qualcomm
> platforms:
> 
>    - Program the common control registers and prepare the CSID RX path
>      to select between C-PHY and D-PHY for Gen3.
>    - Add the sa8775p C-PHY 3ph lane register table and wire it up for
>      sa8775p and sa8300.
>    - Introduce a data-rate selection mechanism so the C-PHY PHY register
>      overrides vary with the negotiated link (symbol) data rate, with
>      tables for sa8775p/8300 (1.5/1.7/2.5/3.5/4.5 GSpS) and sm8250
>      (2.5/3.5/4.5 GSpS).
>    - Validate that the local (CSIPHY) and remote (sensor) endpoint
>      bus-types agree, catching C-PHY/D-PHY mismatches early at probe.
> 
> Rebased on David Heidelberg's C-PHY series (v9):
>    https://lore.kernel.org/all/20260617-qcom-cphy-v9-0-83da8a8e4e44@ixit.cz/
> 
> Tested on sm8250, sa8775p and sa8300, on top of the v4 revision of that series:
>    https://lore.kernel.org/all/20260301-qcom-cphy-v4-0-e53316d2cc65@ixit.cz/
> 
> Anusha Arun Nandi (3):
>    media: qcom: camss: Add sa8300 C-PHY 3ph lane config
>    media: qcom: camss: Dynamic data-rate specific C-PHY register settings
>    media: qcom: camss: validate local/remote endpoint bus-type
> 
> Jigarkumar Zala (3):
>    media: qcom: camss: Program CSIPHY common control registers
>    media: qcom: camss: Prepare CSID for C-PHY support in gen3
>    media: qcom: camss: Add sa8775p C-PHY 3ph lane config
> 
>   .../platform/qcom/camss/camss-csid-gen3.c     |   2 +
>   .../qcom/camss/camss-csiphy-3ph-1-0.c         | 394 +++++++++++++++++-
>   .../media/platform/qcom/camss/camss-csiphy.h  |   6 +
>   drivers/media/platform/qcom/camss/camss.c     |  28 +-
>   4 files changed, 420 insertions(+), 10 deletions(-)
> ---
> base-commit: 0e35b9b6ec0ffcc5e23cbdec09f5c622ad532b53
> change-id: 20251109-qcom-cphy-bb8cbda1c644
> 
> Best regards,

This is great work, thank you.

That said, I think CPHY embedded in CAMSS is the wrong architectural 
direction.

I was thinking we could add in David's CPHY stuff as a holding position 
and also because its at v9 BUT if that means adding three more SoCs 
ontop of that... that won't fly.

I understand its a priority for you to get this stuff upstream but, I 
think this _shouldn't_ be done at the expense of adding up more and more 
technical debt.

CPHY as a monolith in CAMSS is technical debt and adding it in to the 
existing CAMSS as monolith is just a shortcut around a problem - that we 
haven't merged the CSIPHY rewrite yet.

CPHY should land in the new driver.

Aside from anything else - upstream Linux needs CPHY definitions that 
make sense for the community.

inspiron14p-linux:linux (arm64-laptops-v7.2-rc2-camss-v9*) $ grep dphy 
include/linux/phy* -r
include/linux/phy/phy.h:#include <linux/phy/phy-mipi-dphy.h>
include/linux/phy/phy.h: * @mipi_dphy:	Configuration set applicable for 
phys supporting
include/linux/phy/phy.h:	struct phy_configure_opts_mipi_dphy	mipi_dphy;
include/linux/phy/phy-mipi-dphy.h: * struct phy_configure_opts_mipi_dphy 
- MIPI D-PHY configuration set
include/linux/phy/phy-mipi-dphy.h:struct phy_configure_opts_mipi_dphy {
include/linux/phy/phy-mipi-dphy.h:int 
phy_mipi_dphy_get_default_config(unsigned long pixel_clock,
include/linux/phy/phy-mipi-dphy.h:				    struct 
phy_configure_opts_mipi_dphy *cfg);
include/linux/phy/phy-mipi-dphy.h:int 
phy_mipi_dphy_get_default_config_for_hsclk(unsigned long long hs_clk_rate,
include/linux/phy/phy-mipi-dphy.h:					      struct 
phy_configure_opts_mipi_dphy *cfg);
include/linux/phy/phy-mipi-dphy.h:int 
phy_mipi_dphy_config_validate(struct phy_configure_opts_mipi_dphy *cfg);
inspiron14p-linux:linux (arm64-laptops-v7.2-rc2-camss-v9*) $ grep cphy 
include/linux/phy* -r

Lets do _that_ work even if it takes a few cycles. Great to see qcom 
engaging with CPHY - IMO if we do it right in the qcom stack it will 
establish a good base for others to follow.

I'll go ahead and ask David nicely to rework his stuff into this new 
driver. Very nicely, we like him.

https://lore.kernel.org/all/220260718-x1e-csi2-phy-v10-0-5720a7888953@linaro.org

---
bod

Re: [PATCH 1/6] media: qcom: camss: Program CSIPHY common control registers

[Loic Poulain]

On Sat, Jul 18, 2026 at 1:13 AM Anusha Arun Nandi
<anusha.nandi@oss.qualcomm.com> wrote:
>
> From: Jigarkumar Zala <jigarkumar.zala@oss.qualcomm.com>
>
> Program the CSIPHY common-control registers during lane enable so
> SA8775P uses the required 3-phase 1.5 Gsps reset-release values for
> both C-PHY and D-PHY. Keep the existing reset-release value for the
> other CAMSS variants.
>
> Co-developed-by: Anusha Arun Nandi <anusha.nandi@oss.qualcomm.com>
> Signed-off-by: Anusha Arun Nandi <anusha.nandi@oss.qualcomm.com>
> Signed-off-by: Jigarkumar Zala <jigarkumar.zala@oss.qualcomm.com>
> ---
>  .../qcom/camss/camss-csiphy-3ph-1-0.c         | 36 ++++++++++++++++---
>  1 file changed, 31 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/media/platform/qcom/camss/camss-csiphy-3ph-1-0.c b/drivers/media/platform/qcom/camss/camss-csiphy-3ph-1-0.c
> index 25a3554ef201..11b7a236e607 100644
> --- a/drivers/media/platform/qcom/camss/camss-csiphy-3ph-1-0.c
> +++ b/drivers/media/platform/qcom/camss/camss-csiphy-3ph-1-0.c
> @@ -1031,8 +1031,6 @@ static void csiphy_reset(struct csiphy_device *csiphy)
>         writel_relaxed(0x1, csiphy->base +
>                       CSIPHY_3PH_CMN_CSI_COMMON_CTRLn(regs->offset, 0));
>         usleep_range(5000, 8000);
> -       writel_relaxed(0x0, csiphy->base +
> -                      CSIPHY_3PH_CMN_CSI_COMMON_CTRLn(regs->offset, 0));
>  }
>
>  static irqreturn_t csiphy_isr(int irq, void *dev)
> @@ -1343,9 +1341,37 @@ static void csiphy_lanes_enable(struct csiphy_device *csiphy,
>         writel_relaxed(val, csiphy->base +
>                        CSIPHY_3PH_CMN_CSI_COMMON_CTRLn(regs->offset, 6));
>
> -       val = 0x02;
> -       writel_relaxed(val, csiphy->base +
> -                      CSIPHY_3PH_CMN_CSI_COMMON_CTRLn(regs->offset, 7));
> +       switch (csiphy->camss->res->version) {
> +       case CAMSS_8300:
> +       case CAMSS_8775P:
> +               if (c->phy_cfg == V4L2_MBUS_CSI2_CPHY) {
> +                       val = 0x5A;
> +                       writel_relaxed(val, csiphy->base +
> +                                      CSIPHY_3PH_CMN_CSI_COMMON_CTRLn(regs->offset, 7));
> +                       val = 0xE;
> +                       writel_relaxed(val, csiphy->base +
> +                                      CSIPHY_3PH_CMN_CSI_COMMON_CTRLn(regs->offset, 0));
> +               } else {
> +                       val = 0x02;
> +                       writel_relaxed(val, csiphy->base +
> +                                      CSIPHY_3PH_CMN_CSI_COMMON_CTRLn(regs->offset, 7));
> +                       writel_relaxed(val, csiphy->base +
> +                                      CSIPHY_3PH_CMN_CSI_COMMON_CTRLn(regs->offset, 0));
> +               }
> +               break;
> +       case CAMSS_7280:
> +       case CAMSS_8250:
> +       case CAMSS_8280XP:
> +       case CAMSS_845:
> +       default:
> +               val = 0x02;
> +               writel_relaxed(val, csiphy->base +
> +                              CSIPHY_3PH_CMN_CSI_COMMON_CTRLn(regs->offset, 7));
> +               val = 0x0;
> +               writel_relaxed(val, csiphy->base +
> +                              CSIPHY_3PH_CMN_CSI_COMMON_CTRLn(regs->offset, 0));
> +               break;
> +       }

I don't really like this big camss-version switch case with magic,
which also introduces more magic values. Maybe we should have a
different version of csiphy_lanes_enable, based on the phy compatible
or revision.

>
>         val = 0x00;
>         writel_relaxed(val, csiphy->base +
> --
> 2.34.1
>
>

Re: [PATCH 1/6] media: qcom: camss: Program CSIPHY common control registers

[Bryan O'Donoghue]

On 20/07/2026 08:56, Loic Poulain wrote:
> On Sat, Jul 18, 2026 at 1:13 AM Anusha Arun Nandi
> <anusha.nandi@oss.qualcomm.com> wrote:
>>
>> From: Jigarkumar Zala <jigarkumar.zala@oss.qualcomm.com>
>>
>> Program the CSIPHY common-control registers during lane enable so
>> SA8775P uses the required 3-phase 1.5 Gsps reset-release values for
>> both C-PHY and D-PHY. Keep the existing reset-release value for the
>> other CAMSS variants.
>>
>> Co-developed-by: Anusha Arun Nandi <anusha.nandi@oss.qualcomm.com>
>> Signed-off-by: Anusha Arun Nandi <anusha.nandi@oss.qualcomm.com>
>> Signed-off-by: Jigarkumar Zala <jigarkumar.zala@oss.qualcomm.com>
>> ---
>>   .../qcom/camss/camss-csiphy-3ph-1-0.c         | 36 ++++++++++++++++---
>>   1 file changed, 31 insertions(+), 5 deletions(-)
>>
>> diff --git a/drivers/media/platform/qcom/camss/camss-csiphy-3ph-1-0.c b/drivers/media/platform/qcom/camss/camss-csiphy-3ph-1-0.c
>> index 25a3554ef201..11b7a236e607 100644
>> --- a/drivers/media/platform/qcom/camss/camss-csiphy-3ph-1-0.c
>> +++ b/drivers/media/platform/qcom/camss/camss-csiphy-3ph-1-0.c
>> @@ -1031,8 +1031,6 @@ static void csiphy_reset(struct csiphy_device *csiphy)
>>          writel_relaxed(0x1, csiphy->base +
>>                        CSIPHY_3PH_CMN_CSI_COMMON_CTRLn(regs->offset, 0));
>>          usleep_range(5000, 8000);
>> -       writel_relaxed(0x0, csiphy->base +
>> -                      CSIPHY_3PH_CMN_CSI_COMMON_CTRLn(regs->offset, 0));
>>   }
>>
>>   static irqreturn_t csiphy_isr(int irq, void *dev)
>> @@ -1343,9 +1341,37 @@ static void csiphy_lanes_enable(struct csiphy_device *csiphy,
>>          writel_relaxed(val, csiphy->base +
>>                         CSIPHY_3PH_CMN_CSI_COMMON_CTRLn(regs->offset, 6));
>>
>> -       val = 0x02;
>> -       writel_relaxed(val, csiphy->base +
>> -                      CSIPHY_3PH_CMN_CSI_COMMON_CTRLn(regs->offset, 7));
>> +       switch (csiphy->camss->res->version) {
>> +       case CAMSS_8300:
>> +       case CAMSS_8775P:
>> +               if (c->phy_cfg == V4L2_MBUS_CSI2_CPHY) {
>> +                       val = 0x5A;
>> +                       writel_relaxed(val, csiphy->base +
>> +                                      CSIPHY_3PH_CMN_CSI_COMMON_CTRLn(regs->offset, 7));
>> +                       val = 0xE;
>> +                       writel_relaxed(val, csiphy->base +
>> +                                      CSIPHY_3PH_CMN_CSI_COMMON_CTRLn(regs->offset, 0));
>> +               } else {
>> +                       val = 0x02;
>> +                       writel_relaxed(val, csiphy->base +
>> +                                      CSIPHY_3PH_CMN_CSI_COMMON_CTRLn(regs->offset, 7));
>> +                       writel_relaxed(val, csiphy->base +
>> +                                      CSIPHY_3PH_CMN_CSI_COMMON_CTRLn(regs->offset, 0));
>> +               }
>> +               break;
>> +       case CAMSS_7280:
>> +       case CAMSS_8250:
>> +       case CAMSS_8280XP:
>> +       case CAMSS_845:
>> +       default:
>> +               val = 0x02;
>> +               writel_relaxed(val, csiphy->base +
>> +                              CSIPHY_3PH_CMN_CSI_COMMON_CTRLn(regs->offset, 7));
>> +               val = 0x0;
>> +               writel_relaxed(val, csiphy->base +
>> +                              CSIPHY_3PH_CMN_CSI_COMMON_CTRLn(regs->offset, 0));
>> +               break;
>> +       }
> 
> I don't really like this big camss-version switch case with magic,
> which also introduces more magic values. Maybe we should have a
> different version of csiphy_lanes_enable, based on the phy compatible
> or revision.
No.

Just move all of this logic into the new CSIPHY driver. I won't be 
merging more technical debt here.

---
bod

Re: [PATCH 0/6] media: qcom: camss: Add C-PHY support for sa8775p, sa8300 and sm8250

[Anusha Arun Nandi]

On 7/17/2026 7:45 PM, Bryan O'Donoghue wrote:
> On 18/07/2026 00:13, Anusha Arun Nandi wrote:
>> This series extends the Qualcomm CAMSS (Camera Subsystem) C-PHY
>> support to
>> the Gen3 platforms, adding C-PHY mode configuration for sa8775p
>> (CAMSS_8775P) and sa8300 (CAMSS_8300), along with a dynamic, data-rate
>> specific C-PHY register programming mechanism.
>>
>> It builds on David Heidelberg's C-PHY enablement work for Qualcomm
>> platforms:
>>
>>    - Program the common control registers and prepare the CSID RX path
>>      to select between C-PHY and D-PHY for Gen3.
>>    - Add the sa8775p C-PHY 3ph lane register table and wire it up for
>>      sa8775p and sa8300.
>>    - Introduce a data-rate selection mechanism so the C-PHY PHY register
>>      overrides vary with the negotiated link (symbol) data rate, with
>>      tables for sa8775p/8300 (1.5/1.7/2.5/3.5/4.5 GSpS) and sm8250
>>      (2.5/3.5/4.5 GSpS).
>>    - Validate that the local (CSIPHY) and remote (sensor) endpoint
>>      bus-types agree, catching C-PHY/D-PHY mismatches early at probe.
>>
>> Rebased on David Heidelberg's C-PHY series (v9):
>>    https://lore.kernel.org/all/20260617-qcom-cphy-
>> v9-0-83da8a8e4e44@ixit.cz/
>>
>> Tested on sm8250, sa8775p and sa8300, on top of the v4 revision of
>> that series:
>>    https://lore.kernel.org/all/20260301-qcom-cphy-v4-0-
>> e53316d2cc65@ixit.cz/
>>
>> Anusha Arun Nandi (3):
>>    media: qcom: camss: Add sa8300 C-PHY 3ph lane config
>>    media: qcom: camss: Dynamic data-rate specific C-PHY register settings
>>    media: qcom: camss: validate local/remote endpoint bus-type
>>
>> Jigarkumar Zala (3):
>>    media: qcom: camss: Program CSIPHY common control registers
>>    media: qcom: camss: Prepare CSID for C-PHY support in gen3
>>    media: qcom: camss: Add sa8775p C-PHY 3ph lane config
>>
>>   .../platform/qcom/camss/camss-csid-gen3.c     |   2 +
>>   .../qcom/camss/camss-csiphy-3ph-1-0.c         | 394 +++++++++++++++++-
>>   .../media/platform/qcom/camss/camss-csiphy.h  |   6 +
>>   drivers/media/platform/qcom/camss/camss.c     |  28 +-
>>   4 files changed, 420 insertions(+), 10 deletions(-)
>> ---
>> base-commit: 0e35b9b6ec0ffcc5e23cbdec09f5c622ad532b53
>> change-id: 20251109-qcom-cphy-bb8cbda1c644
>>
>> Best regards,
> 
> This is great work, thank you.
> 
> That said, I think CPHY embedded in CAMSS is the wrong architectural
> direction.
> 
> I was thinking we could add in David's CPHY stuff as a holding position
> and also because its at v9 BUT if that means adding three more SoCs
> ontop of that... that won't fly.
> 
> I understand its a priority for you to get this stuff upstream but, I
> think this _shouldn't_ be done at the expense of adding up more and more
> technical debt.
> 
> CPHY as a monolith in CAMSS is technical debt and adding it in to the
> existing CAMSS as monolith is just a shortcut around a problem - that we
> haven't merged the CSIPHY rewrite yet.
> 
> CPHY should land in the new driver.
> 
> Aside from anything else - upstream Linux needs CPHY definitions that
> make sense for the community.
> 
> inspiron14p-linux:linux (arm64-laptops-v7.2-rc2-camss-v9*) $ grep dphy
> include/linux/phy* -r
> include/linux/phy/phy.h:#include <linux/phy/phy-mipi-dphy.h>
> include/linux/phy/phy.h: * @mipi_dphy:    Configuration set applicable
> for phys supporting
> include/linux/phy/phy.h:    struct phy_configure_opts_mipi_dphy   
> mipi_dphy;
> include/linux/phy/phy-mipi-dphy.h: * struct phy_configure_opts_mipi_dphy
> - MIPI D-PHY configuration set
> include/linux/phy/phy-mipi-dphy.h:struct phy_configure_opts_mipi_dphy {
> include/linux/phy/phy-mipi-dphy.h:int
> phy_mipi_dphy_get_default_config(unsigned long pixel_clock,
> include/linux/phy/phy-mipi-dphy.h:                    struct
> phy_configure_opts_mipi_dphy *cfg);
> include/linux/phy/phy-mipi-dphy.h:int
> phy_mipi_dphy_get_default_config_for_hsclk(unsigned long long hs_clk_rate,
> include/linux/phy/phy-mipi-dphy.h:                          struct
> phy_configure_opts_mipi_dphy *cfg);
> include/linux/phy/phy-mipi-dphy.h:int
> phy_mipi_dphy_config_validate(struct phy_configure_opts_mipi_dphy *cfg);
> inspiron14p-linux:linux (arm64-laptops-v7.2-rc2-camss-v9*) $ grep cphy
> include/linux/phy* -r
> 
> Lets do _that_ work even if it takes a few cycles. Great to see qcom
> engaging with CPHY - IMO if we do it right in the qcom stack it will
> establish a good base for others to follow.
> 
> I'll go ahead and ask David nicely to rework his stuff into this new
> driver. Very nicely, we like him.
> 
> https://lore.kernel.org/all/220260718-x1e-csi2-phy-
> v10-0-5720a7888953@linaro.org
> 
> ---
> bod

Thank you for the feedback! We plan to rebase this series once David's
updated patches are ready and we will align with the new driver
direction. In the next revision, we will address the review comments
raised here, along with Loic's feedback and the concern raised by
another contributor regarding larger bandwidth handling.

Re: [PATCH 1/6] media: qcom: camss: Program CSIPHY common control registers

[Anusha Arun Nandi]

On 7/20/2026 12:56 AM, Loic Poulain wrote:
> On Sat, Jul 18, 2026 at 1:13 AM Anusha Arun Nandi
> <anusha.nandi@oss.qualcomm.com> wrote:
>>
>> From: Jigarkumar Zala <jigarkumar.zala@oss.qualcomm.com>
>>
>> Program the CSIPHY common-control registers during lane enable so
>> SA8775P uses the required 3-phase 1.5 Gsps reset-release values for
>> both C-PHY and D-PHY. Keep the existing reset-release value for the
>> other CAMSS variants.
>>
>> Co-developed-by: Anusha Arun Nandi <anusha.nandi@oss.qualcomm.com>
>> Signed-off-by: Anusha Arun Nandi <anusha.nandi@oss.qualcomm.com>
>> Signed-off-by: Jigarkumar Zala <jigarkumar.zala@oss.qualcomm.com>
>> ---
>>  .../qcom/camss/camss-csiphy-3ph-1-0.c         | 36 ++++++++++++++++---
>>  1 file changed, 31 insertions(+), 5 deletions(-)
>>
>> diff --git a/drivers/media/platform/qcom/camss/camss-csiphy-3ph-1-0.c b/drivers/media/platform/qcom/camss/camss-csiphy-3ph-1-0.c
>> index 25a3554ef201..11b7a236e607 100644
>> --- a/drivers/media/platform/qcom/camss/camss-csiphy-3ph-1-0.c
>> +++ b/drivers/media/platform/qcom/camss/camss-csiphy-3ph-1-0.c
>> @@ -1031,8 +1031,6 @@ static void csiphy_reset(struct csiphy_device *csiphy)
>>         writel_relaxed(0x1, csiphy->base +
>>                       CSIPHY_3PH_CMN_CSI_COMMON_CTRLn(regs->offset, 0));
>>         usleep_range(5000, 8000);
>> -       writel_relaxed(0x0, csiphy->base +
>> -                      CSIPHY_3PH_CMN_CSI_COMMON_CTRLn(regs->offset, 0));
>>  }
>>
>>  static irqreturn_t csiphy_isr(int irq, void *dev)
>> @@ -1343,9 +1341,37 @@ static void csiphy_lanes_enable(struct csiphy_device *csiphy,
>>         writel_relaxed(val, csiphy->base +
>>                        CSIPHY_3PH_CMN_CSI_COMMON_CTRLn(regs->offset, 6));
>>
>> -       val = 0x02;
>> -       writel_relaxed(val, csiphy->base +
>> -                      CSIPHY_3PH_CMN_CSI_COMMON_CTRLn(regs->offset, 7));
>> +       switch (csiphy->camss->res->version) {
>> +       case CAMSS_8300:
>> +       case CAMSS_8775P:
>> +               if (c->phy_cfg == V4L2_MBUS_CSI2_CPHY) {
>> +                       val = 0x5A;
>> +                       writel_relaxed(val, csiphy->base +
>> +                                      CSIPHY_3PH_CMN_CSI_COMMON_CTRLn(regs->offset, 7));
>> +                       val = 0xE;
>> +                       writel_relaxed(val, csiphy->base +
>> +                                      CSIPHY_3PH_CMN_CSI_COMMON_CTRLn(regs->offset, 0));
>> +               } else {
>> +                       val = 0x02;
>> +                       writel_relaxed(val, csiphy->base +
>> +                                      CSIPHY_3PH_CMN_CSI_COMMON_CTRLn(regs->offset, 7));
>> +                       writel_relaxed(val, csiphy->base +
>> +                                      CSIPHY_3PH_CMN_CSI_COMMON_CTRLn(regs->offset, 0));
>> +               }
>> +               break;
>> +       case CAMSS_7280:
>> +       case CAMSS_8250:
>> +       case CAMSS_8280XP:
>> +       case CAMSS_845:
>> +       default:
>> +               val = 0x02;
>> +               writel_relaxed(val, csiphy->base +
>> +                              CSIPHY_3PH_CMN_CSI_COMMON_CTRLn(regs->offset, 7));
>> +               val = 0x0;
>> +               writel_relaxed(val, csiphy->base +
>> +                              CSIPHY_3PH_CMN_CSI_COMMON_CTRLn(regs->offset, 0));
>> +               break;
>> +       }
> 
> I don't really like this big camss-version switch case with magic,
> which also introduces more magic values. Maybe we should have a
> different version of csiphy_lanes_enable, based on the phy compatible
> or revision.
> 
Thank you for the feedback! We agree with your suggestion and will
refactor this to use a version-specific implementation of
csiphy_lanes_enable, based on the PHY compatible or revision, in the
upcoming patchset.>>
>>         val = 0x00;
>>         writel_relaxed(val, csiphy->base +
>> --
>> 2.34.1
>>
>>

Re: [PATCH 1/6] media: qcom: camss: Program CSIPHY common control registers

[Bryan O'Donoghue]

On 20/07/2026 20:38, Anusha Arun Nandi wrote:
>> I don't really like this big camss-version switch case with magic,
>> which also introduces more magic values. Maybe we should have a
>> different version of csiphy_lanes_enable, based on the phy compatible
>> or revision.
>>
> Thank you for the feedback! We agree with your suggestion and will
> refactor this to use a version-specific implementation of
> csiphy_lanes_enable, based on the PHY compatible or revision, in the
> upcoming patchset.

Hmm.

Please don't do that. Instead work with David to get CPHY support into 
the dedicated driver - including whatever additional work is required - 
perhaps nothing more than reusing the existing dphy_opts structure for 
cphy purposes.

Proceeding in the direction elucidated above would mean inclusion of 
four CPHYs into the exiting infrastructure - that's not "stopgap" that's 
established precedent.

A big no from me I'm afraid.

There's a real upstream gap to be addresses for CPHY. Let's address it 
not work-around it in a specific way for our platform.

I'd expect to see some kind of subset of


include/linux/phy/phy-mipi-cphy.h
struct phy_configure_opts_mipi_cphy

or perhaps we can reuse/abuse struct phy_configure_opts_mipi_dphy - for 
example could it be changed into a generic structure to contain both 
cphy and dphy data - with an appropriate name change ?

My feeling is a phy_configure_opts_mipi_cphy structure is required but, 
perhaps both cphy and dphy can exist in one structure or in a union of 
structs.

TBD

deckard@sagittarius-a: /home/deckard/Development/qualcomm/qlt-kernel 
git:(arm64-laptops-v7.2-rc1-camss-v6-ife-bringup) ✗
➜   grep dphy include/* -r
include/drm/bridge/dw_mipi_dsi.h:struct dw_mipi_dsi_dphy_timing {
include/drm/bridge/dw_mipi_dsi.h:			 struct dw_mipi_dsi_dphy_timing 
*timing);
include/linux/phy/phy.h:#include <linux/phy/phy-mipi-dphy.h>
include/linux/phy/phy.h: * @mipi_dphy:	Configuration set applicable for 
phys supporting
include/linux/phy/phy.h:	struct phy_configure_opts_mipi_dphy	mipi_dphy;
include/linux/phy/phy-mipi-dphy.h: * struct phy_configure_opts_mipi_dphy 
- MIPI D-PHY configuration set
include/linux/phy/phy-mipi-dphy.h:struct phy_configure_opts_mipi_dphy {
include/linux/phy/phy-mipi-dphy.h:int 
phy_mipi_dphy_get_default_config(unsigned long pixel_clock,
include/linux/phy/phy-mipi-dphy.h:				    struct 
phy_configure_opts_mipi_dphy *cfg);
include/linux/phy/phy-mipi-dphy.h:int 
phy_mipi_dphy_get_default_config_for_hsclk(unsigned long long hs_clk_rate,
include/linux/phy/phy-mipi-dphy.h:					      struct 
phy_configure_opts_mipi_dphy *cfg);
include/linux/phy/phy-mipi-dphy.h:int 
phy_mipi_dphy_config_validate(struct phy_configure_opts_mipi_dphy *cfg);
include/linux/platform_data/media/mmp-camera.h:enum dphy3_algo {
include/linux/platform_data/media/mmp-camera.h:	int dphy[3];		/* DPHY: 
CSI2_DPHY3, CSI2_DPHY5, CSI2_DPHY6 */
include/linux/platform_data/media/mmp-camera.h:	enum dphy3_algo 
dphy3_algo;	/* algos for calculate CSI2_DPHY3 */
include/media/ipu-bridge.h:	u32 dphylinkenfuses;
deckard@sagittarius-a: /home/deckard/Development/qualcomm/qlt-kernel 
git:(arm64-laptops-v7.2-rc1-camss-v6-ife-bringup) ✗
➜   grep cphy include/* -r
include/media/v4l2-mediabus.h: * enum 
v4l2_mbus_csi2_cphy_line_orders_type - CSI-2 C-PHY line order
include/media/v4l2-mediabus.h:enum v4l2_mbus_csi2_cphy_line_orders_type {
include/media/v4l2-mediabus.h:	enum v4l2_mbus_csi2_cphy_line_orders_type 
line_orders[V4L2_MBUS_CSI2_MAX_DATA_LANES];

deckard@sagittarius-a: /home/deckard/Development/qualcomm/qlt-kernel 
git:(arm64-laptops-v7.2-rc1-camss-v6-ife-bringup) ✗
➜

But to be 100% - I'm fully against burying inline CPHY code into CAMSS.

The long term objective of cleaning things up and reducing technical 
debt can't be realised by - adding more technical debt.

And I'll reiterate the right-thing-to-do (tm) is to expand the kernel's 
understanding/definition of PHYs to encompass CPHY for the benefit of 
users and the entire community - instead of a qcom-specific hack.

---
bod

Re: [PATCH 1/6] media: qcom: camss: Program CSIPHY common control registers

[Anusha Arun Nandi]

On 7/20/2026 1:06 PM, Bryan O'Donoghue wrote:
> On 20/07/2026 20:38, Anusha Arun Nandi wrote:
>>> I don't really like this big camss-version switch case with magic,
>>> which also introduces more magic values. Maybe we should have a
>>> different version of csiphy_lanes_enable, based on the phy compatible
>>> or revision.
>>>
>> Thank you for the feedback! We agree with your suggestion and will
>> refactor this to use a version-specific implementation of
>> csiphy_lanes_enable, based on the PHY compatible or revision, in the
>> upcoming patchset.
> 
> Hmm.
> 
> Please don't do that. Instead work with David to get CPHY support into
> the dedicated driver - including whatever additional work is required -
> perhaps nothing more than reusing the existing dphy_opts structure for
> cphy purposes.
> 
> Proceeding in the direction elucidated above would mean inclusion of
> four CPHYs into the exiting infrastructure - that's not "stopgap" that's
> established precedent.
> 
> A big no from me I'm afraid.
> 
> There's a real upstream gap to be addresses for CPHY. Let's address it
> not work-around it in a specific way for our platform.
> 
> I'd expect to see some kind of subset of
> 
> 
> include/linux/phy/phy-mipi-cphy.h
> struct phy_configure_opts_mipi_cphy
> 
> or perhaps we can reuse/abuse struct phy_configure_opts_mipi_dphy - for
> example could it be changed into a generic structure to contain both
> cphy and dphy data - with an appropriate name change ?
> 
> My feeling is a phy_configure_opts_mipi_cphy structure is required but,
> perhaps both cphy and dphy can exist in one structure or in a union of
> structs.
> 
> TBD
> 
> deckard@sagittarius-a: /home/deckard/Development/qualcomm/qlt-kernel
> git:(arm64-laptops-v7.2-rc1-camss-v6-ife-bringup) ✗
> ➜   grep dphy include/* -r
> include/drm/bridge/dw_mipi_dsi.h:struct dw_mipi_dsi_dphy_timing {
> include/drm/bridge/dw_mipi_dsi.h:             struct
> dw_mipi_dsi_dphy_timing *timing);
> include/linux/phy/phy.h:#include <linux/phy/phy-mipi-dphy.h>
> include/linux/phy/phy.h: * @mipi_dphy:    Configuration set applicable
> for phys supporting
> include/linux/phy/phy.h:    struct phy_configure_opts_mipi_dphy   
> mipi_dphy;
> include/linux/phy/phy-mipi-dphy.h: * struct phy_configure_opts_mipi_dphy
> - MIPI D-PHY configuration set
> include/linux/phy/phy-mipi-dphy.h:struct phy_configure_opts_mipi_dphy {
> include/linux/phy/phy-mipi-dphy.h:int
> phy_mipi_dphy_get_default_config(unsigned long pixel_clock,
> include/linux/phy/phy-mipi-dphy.h:                    struct
> phy_configure_opts_mipi_dphy *cfg);
> include/linux/phy/phy-mipi-dphy.h:int
> phy_mipi_dphy_get_default_config_for_hsclk(unsigned long long hs_clk_rate,
> include/linux/phy/phy-mipi-dphy.h:                          struct
> phy_configure_opts_mipi_dphy *cfg);
> include/linux/phy/phy-mipi-dphy.h:int
> phy_mipi_dphy_config_validate(struct phy_configure_opts_mipi_dphy *cfg);
> include/linux/platform_data/media/mmp-camera.h:enum dphy3_algo {
> include/linux/platform_data/media/mmp-camera.h:    int dphy[3];        /
> * DPHY: CSI2_DPHY3, CSI2_DPHY5, CSI2_DPHY6 */
> include/linux/platform_data/media/mmp-camera.h:    enum dphy3_algo
> dphy3_algo;    /* algos for calculate CSI2_DPHY3 */
> include/media/ipu-bridge.h:    u32 dphylinkenfuses;
> deckard@sagittarius-a: /home/deckard/Development/qualcomm/qlt-kernel
> git:(arm64-laptops-v7.2-rc1-camss-v6-ife-bringup) ✗
> ➜   grep cphy include/* -r
> include/media/v4l2-mediabus.h: * enum
> v4l2_mbus_csi2_cphy_line_orders_type - CSI-2 C-PHY line order
> include/media/v4l2-mediabus.h:enum v4l2_mbus_csi2_cphy_line_orders_type {
> include/media/v4l2-mediabus.h:    enum
> v4l2_mbus_csi2_cphy_line_orders_type
> line_orders[V4L2_MBUS_CSI2_MAX_DATA_LANES];
> 
> deckard@sagittarius-a: /home/deckard/Development/qualcomm/qlt-kernel
> git:(arm64-laptops-v7.2-rc1-camss-v6-ife-bringup) ✗
> ➜
> 
> But to be 100% - I'm fully against burying inline CPHY code into CAMSS.
> 
> The long term objective of cleaning things up and reducing technical
> debt can't be realised by - adding more technical debt.
> 
> And I'll reiterate the right-thing-to-do (tm) is to expand the kernel's
> understanding/definition of PHYs to encompass CPHY for the benefit of
> users and the entire community - instead of a qcom-specific hack.
> 
> ---
> bod

We understand your concern here. We will work with David to integrate
C-PHY support into the dedicated driver infrastructure, and explore the
appropriate path for a phy_configure_opts_mipi_cphy structure — whether
as a standalone header or as an extension of the existing
phy_configure_opts_mipi_dphy structure. Thank you for the detailed feedback.