media: qcom: camss: Add C-PHY support for sa8775p, sa8300 and sm8250

[PATCH 0/6] media: qcom: camss: Add C-PHY support for sa8775p, sa8300 and sm8250

Posted by Anusha Arun Nandi 1 week ago

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@ixit.cz/

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@ixit.cz/

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,
-- 
Anusha Arun Nandi <anusha.nandi@oss.qualcomm.com>

Re: [PATCH 0/6] media: qcom: camss: Add C-PHY support for sa8775p, sa8300 and sm8250

Posted by Bryan O'Donoghue 1 week ago

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@ixit.cz/
> 
> 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@ixit.cz/
> 
> 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@linaro.org

---
bod

Re: [PATCH 0/6] media: qcom: camss: Add C-PHY support for sa8775p, sa8300 and sm8250

Posted by Anusha Arun Nandi 4 days, 8 hours ago

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@ixit.cz/
>>
>> 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@ixit.cz/
>>
>> 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@linaro.org
> 
> ---
> 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.