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.