Re: [PATCH RFC 0/6] phy/media: Add generic MIPI C-PHY support to CSI-2 stack
From: Jigarkumar Zala
Date: Tue Oct 27 2026 - 19:48:45 EST
Hi Bryan,
Thanks a lot for your suggestion regarding file structuring and naming convention.
However, we think that having the separate file will make it more functionality oriented distinction. It is easier for addition and maintenance.
Also, we would like to propose to remove 3ph from the file name convention as this is misleading the operation. DPHY is 2ph, whereas CPHY is 3ph.
We are proposing to have a naming like phy-qcom-mipi-csi2-dphy.c and phy-qcom-mipi-csi2-cphy.c as the names, DPHY and CPHY are sufficient to understand the 2ph or 3ph operational mode.
Kindly provide your suggestion.
Thanks,
JZ
On 10/17/2026 4:39 PM, Bryan O'Donoghue wrote:
On 17/10/2026 18:13, Nihal Kumar Gupta wrote:
George posted a C-PHY series [1] which we are currently reviewing.
As discussed with Bryan, this series shares our independent
implementation so the approaches can be compared.
Two aspects covered here are not in [1]:
- Settle count calculation derived from sensor-reported T_PREPARE and
T_PREAMBLE timing via get_mbus_config(). [1] left this as an open
question.
- Data rate based register sequence selection using effective bit
rate (link_freq * 32 / 7). [1] noted downstream does this but
deferred it; this series implements it.
MIPI CSI-2 operates over two physical layer variants. D-PHY uses a
dedicated differential clock lane with up to four data lanes. C-PHY
encodes the clock within the data stream across up to three wire
trios, eliminating the dedicated clock lane.
Patch 1 extends the generic PHY framework with PHY_MODE_MIPI_CPHY
and struct phy_configure_opts_mipi_cphy.
Patch 2 adds t_prepare_ns and t_preamble_ns fields to the CSI-2
media bus configuration and extends CAMSS to forward them to the PHY
provider for settle count calculation. Sensor drivers must implement
get_mbus_config() and return non-zero values in nanoseconds; stream-on
returns -EINVAL otherwise. The strictness is deliberate: C-PHY settle
timing is symbol-rate-range specific and no safe value can be derived
from link frequency alone. A conservative fallback could be added if
reviewers prefer.
Patches 3-6 extend the Qualcomm CSIPHY driver: refactor D-PHY
register storage to accommodate C-PHY, accept C-PHY mode with
multiple data rate table selection, compute settle count, and add
lane power mask support for C-PHY trios.
C-PHY encodes 16 bits per 7 symbols, so the effective bit rate is:
bit_rate = link_freq * 2 * 16 / 7 = link_freq * 32 / 7
where link_freq is symbol_rate / 2 as reported by the sensor via
get_mbus_config(). The rate-table entry whose bandwidth first meets
or exceeds bit_rate is selected.
The settle count defines how many timer clock cycles the CSIPHY
receiver waits before scanning for C-PHY sync. It is computed from
the sensor's T_PREPARE and T_PREAMBLE timing. The /3 factor reflects
that C-PHY distributes the preamble sequence across three trios:
settle_cnt = (t_prepare_ns + t_preamble_ns / 3) * timer_clk_rate / 1e9
D-PHY settle count is unchanged from before this series.
[1] https://lore.kernel.org/all/20261016-x1e-cphy-rfc-v3-0-40a346a72153@xxxxxxxxx/
Signed-off-by: Nihal Kumar Gupta <nihal.gupta@xxxxxxxxxxxxxxxx>
---
Nihal Kumar Gupta (6):
phy: core: Add MIPI C-PHY configurations
media: qcom: camss: Add C-PHY timing fields and get config from sensor
phy: qcom: mipi-csi2: Split D-PHY register settings
phy: qcom: mipi-csi2: Accept C-PHY mode and add register sequence
phy: qcom: mipi-csi2: Add C-PHY settle calculation
phy: qcom: mipi-csi2: Add lane mask calculation for C-PHY
drivers/media/platform/qcom/camss/camss-csiphy.c | 90 +++++++++---
drivers/media/platform/qcom/camss/camss-csiphy.h | 2 +
drivers/media/platform/qcom/camss/camss.c | 8 +-
drivers/phy/qualcomm/phy-qcom-mipi-csi2-3ph-dphy.c | 159 +++++++++++++++++----
So on thing I notice about this series and like is that there's a small change to the existing 3ph-dphy.c
- Since it supports 3ph-cphy the file should be renamed
3ph-cphy-dphy.c (or something)
- I like the progressive nature of he changes in this series
as structurally the right way to add stuff in. Small digestable
commits
- I think the missing piece here is data_lanes[] and lane_polarities[]
per the other series from Qcom
- Another thing is the other series from Anusha has
a more advanced mipi_ops data-structure for CPHY.
Basically I like the approach taken in this series for a smaller change to the phy-qcom-mipi-csi2-3ph-dphy.c file.
I'd like the best of both series - I think there is alot to resolve on lanes, data-lanes and lane-polarities in the other series and looking at this series, it seems to me we don't need a separate phy-qcom-mipi-csi2-3ph-cphy.c, I think Konrad observed in George's series that really the file deals with 3-phase PHYs and that seems true enough.
Please work out between yourself and Anusha what's next.
If possible I would prefer to contain 3ph CPHY and DPHY to one file as is done here - at the same time the definition of CPHY ops and lane mappings is closer to the spec in the other series.
I think either you should take Anusha's structs and lane definitions or Anusha should take your approach to minimal change to the phy-qcom-mipi-csi2-3ph-dphy.c renaming it.
One of you needs to pick up the patches from the other one.
George can land his stuff on top then.
drivers/phy/qualcomm/phy-qcom-mipi-csi2-core.c | 51 +++++--
drivers/phy/qualcomm/phy-qcom-mipi-csi2.h | 25 +++-
include/linux/phy/phy.h | 47 ++++++
include/media/v4l2-mediabus.h | 2 +
8 files changed, 315 insertions(+), 69 deletions(-)
---
base-commit: 2efb7a11f1aa4d2dc285fe2680cca22cb9f72f64
change-id: 20261017-cphy_support-2ce4d656e631
Best regards,
--
Nihal Kumar Gupta <nihal.gupta@xxxxxxxxxxxxxxxx>