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@xxxxxxx/
>
> 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@xxxxxxx/
>
> 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@xxxxxxxxxx

---
bod