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

[Bryan O'Donoghue <bryan.odonoghue@linaro.org>]

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