Add support for the RDI only CAMSS camera driver on SM8750. Enabling
RDI path involves adding the support for a set of CSIPHY, CSID and TFE
modules, with each TFE having multiple RDI ports. This hardware
architecture requires 'qdss_debug_xo' clock for CAMNOC to be functional.

SM8750 camera subsystem provides:
- 6 x CSIPHY (CSI Physical Layer)
- 3 x TPG (Test Pattern Generator)
- 3 x CSID (CSI Decoder)
- 2 x CSID Lite
- 3 x VFE (Video Front End), 5 RDI per VFE
- 2 x VFE Lite, 4 RDI per VFE Lite

This series has been tested using the following commands with S5KJN5 sensor.
- media-ctl --reset
- media-ctl -V '"msm_csiphy2":0[fmt:SGBRG10/4096x3072]'
- media-ctl -V '"msm_csid0":0[fmt:SGBRG10/4096x3072]'
- media-ctl -V '"msm_vfe0_rdi0":0[fmt:SGBRG10/4096x3072]'
- media-ctl -l '"msm_csiphy2":1->"msm_csid0":0[1]'
- media-ctl -l '"msm_csid0":1->"msm_vfe0_rdi0":0[1]'
- yavta  --capture=20 -I -n 5 -f SGBRG10P -s 4096x3072 -F  /dev/video0

Dependencies:
- https://lore.kernel.org/all/20260720-x1e-csi2-phy-v13-0-160c31958863@linaro.org/
- https://lore.kernel.org/all/20260708-b4-linux-next-25-03-13-dtsi-x1e80100-camss-v12-0-f8588da41f16@linaro.org/
- https://lore.kernel.org/all/20260720-kaanapali-camss-v15-0-c0b1c1167c5d@oss.qualcomm.com/

Signed-off-by: Hangxiang Ma <hangxiang.ma@oss.qualcomm.com>
---
Changes in v6:
- Drive the CSIPHY through the standalone phy-qcom-mipi-csi2 DPHY driver
  based on new split-csiphy arch, reusing the shared kaanapali resources.
- Add a dt-bindings patch describing the SM8750 CSI2 PHY with the
  "qcom,sm8750-csi2-phy", "qcom,kaanapali-csi2-phy" compatible
- Add TPG v2.3.0 support, reusing the Kaanapali TPG resources
- Link to v5: https://lore.kernel.org/r/20260601-add-support-for-camss-on-sm8750-v5-0-dac36a190de8@oss.qualcomm.com

Changes in v5:
- Add missing CSI2_RX_CFG0_PHY_SEL_BASE_IDX macro due to kaanapali
  series has merged it into gen4 driver
- Link to v4: https://lore.kernel.org/r/20260601-add-support-for-camss-on-sm8750-v4-0-1eb6f432cfd1@oss.qualcomm.com

Changes in v4:
- Update dependency to kaanapali camss v14 and rebase to resolve conflict
- Link to v3: https://lore.kernel.org/r/20260508-add-support-for-camss-on-sm8750-v3-0-fc6861a65c67@oss.qualcomm.com

Changes in v3:
- Revert binding from full hardware description to CAMSS-only scope for
  modular and incremental development - bod
- Rename icc path names and vfe clock names to drop redundancies - Krzysztof
- Separate port index from VC value in csid_configure_stream(). Previously
  vc was used as both the loop iterator and the hardware VC, causing
  misconfiguration on RDI path starting from 1 - bod
- Link to v2: https://lore.kernel.org/all/20260119-add-support-for-camss-on-sm8750-v2-0-3e06583a0a81@oss.qualcomm.com

Changes in v2:
- Rebase this series due to conflict - bod
- Add module descriptions in binding commit message and cover letter
- Update property names to align with previous generations - Krzysztof
- Update the vdd supply names with 0p88 to 0p9 in binding to keep such name
  style consistency - Krzysztof/Vladimir
- Add missing Kaanapali dependency - Krzysztof
- Add regulator current in csiphy resource due to interface changed - bod
- Make csid board level code style consistent and add comments to explain
  the differences between csid full and lite configurations - bod
- Remove redundant initialization for empty set in csid and vfe - bod
- Remove DTS patch due to conflict with camcc dependency. Will post it
  as an individual series.
- Update vfe commit message as renaming work done in Kaanapali series
- Revert change-id to v1 to avoid increasing reviewers' workload
- Link to v1: https://lore.kernel.org/r/20251126-add-support-for-camss-on-sm8750-v1-0-646fee2eb720@oss.qualcomm.com

---
Hangxiang Ma (7):
      dt-bindings: phy: qcom,x1e80100-csi2-phy: Add SM8750 CSI2 PHY
      media: dt-bindings: Add CAMSS device for SM8750
      media: qcom: camss: Add SM8750 compatible camss driver
      media: qcom: camss: csiphy: Add support for v2.3.0 two-phase CSIPHY
      media: qcom: camss: csid: Add support for CSID 980
      media: qcom: camss: vfe: Add support for VFE 980
      media: qcom: camss: tpg: Add support for v2.3.0 TPG

 .../bindings/media/qcom,sm8750-camss.yaml          | 427 +++++++++++++++++++
 .../bindings/phy/qcom,x1e80100-csi2-phy.yaml       |  10 +-
 drivers/media/platform/qcom/camss/Makefile         |   1 +
 drivers/media/platform/qcom/camss/camss-csid-980.c | 454 +++++++++++++++++++++
 drivers/media/platform/qcom/camss/camss-csid.h     |   1 +
 drivers/media/platform/qcom/camss/camss-tpg-gen1.c |   9 +-
 drivers/media/platform/qcom/camss/camss-vfe-gen4.c |  10 +-
 drivers/media/platform/qcom/camss/camss-vfe.c      |   2 +
 drivers/media/platform/qcom/camss/camss.c          | 103 +++++
 drivers/media/platform/qcom/camss/camss.h          |   1 +
 10 files changed, 1008 insertions(+), 10 deletions(-)
---
base-commit: 03cfefef0119410fc464d0d56e83626cb570b7a8
change-id: 20251126-add-support-for-camss-on-sm8750-506c4de36d88
prerequisite-change-id: 20250710-x1e-csi2-phy-f6434b651d3a:v13
prerequisite-patch-id: 2f70527d6a880f047a4858f75813420c81b4667a
prerequisite-patch-id: b797e1ad3e25f79b0bac8f885b2866206a6e0260
prerequisite-change-id: 20250313-b4-linux-next-25-03-13-dtsi-x1e80100-camss-1506f74bbd3a:v12
prerequisite-patch-id: 6e8e67cd3ab96a602971bbeeb7dfdeaf3f1426a2
prerequisite-patch-id: a7fbea14628b62a8de096dea420473b283010aba
prerequisite-patch-id: b6b6c4e7a5818e1b93fe2758902bd32d2be48509
prerequisite-patch-id: 6fb94a3fa54b9810ff6603960770011db1f0b2d6
prerequisite-patch-id: e31f60c0c41e5b6baa464339263a33e5b2d69fac
prerequisite-patch-id: 83a3c9f2c2478a4a3a9441f58c58d04b04cec44d
prerequisite-change-id: 20260112-kaanapali-camss-73772d44eff7:v15
prerequisite-patch-id: 322972f71789ddcc32cae5e94d71bdac75b0d571
prerequisite-patch-id: 92fb4faf61647d08ec71d038c1dcdc92f72c5f0a
prerequisite-patch-id: bd1bcd82db3b28174e1598ae285430568cf94134
prerequisite-patch-id: b347ad60c475f3035b04ec76741e0f1b5f095580
prerequisite-patch-id: 1d8b84bb0f1f86699b1f7699f3125ef5e4e2eb22
prerequisite-patch-id: ec8bcc12a96780388b1633deab8a9816d8e02617
prerequisite-patch-id: d6a128a29162994f73c84e0935607c1a02d8e988
prerequisite-patch-id: b5740c83f750d116dfe565b8ab70542e27c09e52

Best regards,
-- 
Hangxiang Ma <hangxiang.ma@oss.qualcomm.com>

On Tue, Jul 21, 2026 at 05:45:59AM -0700, Hangxiang Ma wrote:
> Add support for the RDI only CAMSS camera driver on SM8750. Enabling
> RDI path involves adding the support for a set of CSIPHY, CSID and TFE
> modules, with each TFE having multiple RDI ports. This hardware
> architecture requires 'qdss_debug_xo' clock for CAMNOC to be functional.
> 
> SM8750 camera subsystem provides:
> - 6 x CSIPHY (CSI Physical Layer)
> - 3 x TPG (Test Pattern Generator)
> - 3 x CSID (CSI Decoder)
> - 2 x CSID Lite
> - 3 x VFE (Video Front End), 5 RDI per VFE
> - 2 x VFE Lite, 4 RDI per VFE Lite
> 
> This series has been tested using the following commands with S5KJN5 sensor.
> - media-ctl --reset
> - media-ctl -V '"msm_csiphy2":0[fmt:SGBRG10/4096x3072]'
> - media-ctl -V '"msm_csid0":0[fmt:SGBRG10/4096x3072]'
> - media-ctl -V '"msm_vfe0_rdi0":0[fmt:SGBRG10/4096x3072]'
> - media-ctl -l '"msm_csiphy2":1->"msm_csid0":0[1]'
> - media-ctl -l '"msm_csid0":1->"msm_vfe0_rdi0":0[1]'
> - yavta  --capture=20 -I -n 5 -f SGBRG10P -s 4096x3072 -F  /dev/video0
> 
> Dependencies:
> - https://lore.kernel.org/all/20260720-x1e-csi2-phy-v13-0-160c31958863@linaro.org/
> - https://lore.kernel.org/all/20260708-b4-linux-next-25-03-13-dtsi-x1e80100-camss-v12-0-f8588da41f16@linaro.org/
> - https://lore.kernel.org/all/20260720-kaanapali-camss-v15-0-c0b1c1167c5d@oss.qualcomm.com/

None of these were cleared for merging. IOW, all received comments yet
you send work which depends on it.

This is exactly something Bjorn said a week ago or so. And then a few
other maintainers re-iterated. Exactly the same, nothing learnt.

Best regards,
Krzysztof

On 7/22/2026 3:00 PM, Krzysztof Kozlowski wrote:
> On Tue, Jul 21, 2026 at 05:45:59AM -0700, Hangxiang Ma wrote:
>> Add support for the RDI only CAMSS camera driver on SM8750. Enabling
>> RDI path involves adding the support for a set of CSIPHY, CSID and TFE
>> modules, with each TFE having multiple RDI ports. This hardware
>> architecture requires 'qdss_debug_xo' clock for CAMNOC to be functional.
>>
>> SM8750 camera subsystem provides:
>> - 6 x CSIPHY (CSI Physical Layer)
>> - 3 x TPG (Test Pattern Generator)
>> - 3 x CSID (CSI Decoder)
>> - 2 x CSID Lite
>> - 3 x VFE (Video Front End), 5 RDI per VFE
>> - 2 x VFE Lite, 4 RDI per VFE Lite
>>
>> This series has been tested using the following commands with S5KJN5 sensor.
>> - media-ctl --reset
>> - media-ctl -V '"msm_csiphy2":0[fmt:SGBRG10/4096x3072]'
>> - media-ctl -V '"msm_csid0":0[fmt:SGBRG10/4096x3072]'
>> - media-ctl -V '"msm_vfe0_rdi0":0[fmt:SGBRG10/4096x3072]'
>> - media-ctl -l '"msm_csiphy2":1->"msm_csid0":0[1]'
>> - media-ctl -l '"msm_csid0":1->"msm_vfe0_rdi0":0[1]'
>> - yavta  --capture=20 -I -n 5 -f SGBRG10P -s 4096x3072 -F  /dev/video0
>>
>> Dependencies:
>> - https://lore.kernel.org/all/20260720-x1e-csi2-phy-v13-0-160c31958863@linaro.org/
>> - https://lore.kernel.org/all/20260708-b4-linux-next-25-03-13-dtsi-x1e80100-camss-v12-0-f8588da41f16@linaro.org/
>> - https://lore.kernel.org/all/20260720-kaanapali-camss-v15-0-c0b1c1167c5d@oss.qualcomm.com/
> 
> None of these were cleared for merging. IOW, all received comments yet
> you send work which depends on it.
> 
> This is exactly something Bjorn said a week ago or so. And then a few
> other maintainers re-iterated. Exactly the same, nothing learnt.
> 
> Best regards,
> Krzysztof
> 
I understand the concern and agree that posting dependent work before 
the prerequisite series has been fully reviewed and cleared for merging 
is not ideal. The reason these series were posted at this stage was due 
to internal planning requirements and the need to keep work on other 
dependent platforms moving in parallel. The early review is aim to 
avoiding blocking them too much. That's a dilemma that I was asked to 
handle it in this way.

However, I understand that this can create additional review overhead 
and confusion regarding the status of the prerequisite work. Will 
transfer your concern internally to try to avoid other colleagues 
posting more series that has much long chain dependencies.

Apologies for the inconvenience, and thanks for the feedback.

Best regards,
Hangxiang

On 22/07/2026 10:02, Hangxiang Ma wrote:
> On 7/22/2026 3:00 PM, Krzysztof Kozlowski wrote:
>> On Tue, Jul 21, 2026 at 05:45:59AM -0700, Hangxiang Ma wrote:
>>> Add support for the RDI only CAMSS camera driver on SM8750. Enabling
>>> RDI path involves adding the support for a set of CSIPHY, CSID and TFE
>>> modules, with each TFE having multiple RDI ports. This hardware
>>> architecture requires 'qdss_debug_xo' clock for CAMNOC to be functional.
>>>
>>> SM8750 camera subsystem provides:
>>> - 6 x CSIPHY (CSI Physical Layer)
>>> - 3 x TPG (Test Pattern Generator)
>>> - 3 x CSID (CSI Decoder)
>>> - 2 x CSID Lite
>>> - 3 x VFE (Video Front End), 5 RDI per VFE
>>> - 2 x VFE Lite, 4 RDI per VFE Lite
>>>
>>> This series has been tested using the following commands with S5KJN5 sensor.
>>> - media-ctl --reset
>>> - media-ctl -V '"msm_csiphy2":0[fmt:SGBRG10/4096x3072]'
>>> - media-ctl -V '"msm_csid0":0[fmt:SGBRG10/4096x3072]'
>>> - media-ctl -V '"msm_vfe0_rdi0":0[fmt:SGBRG10/4096x3072]'
>>> - media-ctl -l '"msm_csiphy2":1->"msm_csid0":0[1]'
>>> - media-ctl -l '"msm_csid0":1->"msm_vfe0_rdi0":0[1]'
>>> - yavta  --capture=20 -I -n 5 -f SGBRG10P -s 4096x3072 -F  /dev/video0
>>>
>>> Dependencies:
>>> - https://lore.kernel.org/all/20260720-x1e-csi2-phy-v13-0-160c31958863@linaro.org/
>>> - https://lore.kernel.org/all/20260708-b4-linux-next-25-03-13-dtsi-x1e80100-camss-v12-0-f8588da41f16@linaro.org/
>>> - https://lore.kernel.org/all/20260720-kaanapali-camss-v15-0-c0b1c1167c5d@oss.qualcomm.com/
>>
>> None of these were cleared for merging. IOW, all received comments yet
>> you send work which depends on it.
>>
>> This is exactly something Bjorn said a week ago or so. And then a few
>> other maintainers re-iterated. Exactly the same, nothing learnt.
>>
>> Best regards,
>> Krzysztof
>>
> I understand the concern and agree that posting dependent work before 
> the prerequisite series has been fully reviewed and cleared for merging 
> is not ideal. The reason these series were posted at this stage was due 
> to internal planning requirements and the need to keep work on other 

But upstream open-source community does not care about your internal
planning requirements.

Your internal planning is not a valid reason to do anything here.

> dependent platforms moving in parallel. The early review is aim to 

Then why isn't this marked as early review? How early review of
unfinished unmergeable work is supposed to be called? There is very
clear naming required for such work.

> avoiding blocking them too much. That's a dilemma that I was asked to 
> handle it in this way.

Best regards,
Krzysztof