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@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

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.