* [PATCH v17 00/11] media: qcom: camss: Add Kaanapali support
@ 2026-09-29 6:00 ` Hangxiang Ma
0 siblings, 0 replies; 58+ messages in thread
From: Hangxiang Ma @ 2026-09-29 6:00 UTC (permalink / raw)
To: Bryan O'Donoghue, Vinod Koul, Neil Armstrong,
Manivannan Sadhasivam, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Bryan O'Donoghue, Vladimir Zapolskiy,
Loic Poulain, Mauro Carvalho Chehab, Bjorn Andersson,
Konrad Dybcio, Abel Vesa
Cc: linux-phy, linux-media, linux-arm-msm, devicetree, linux-kernel,
jeyaprakash.soundrapandian, Vijay Kumar Tumati, Hangxiang Ma,
Atiya Kailany, Konrad Dybcio
Add support for the RDI only CAMSS camera driver on Kaanapali. 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.
Kaanapali 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
Signed-off-by: Hangxiang Ma <hangxiang.ma@oss.qualcomm.com>
---
Changes in v17:
- Rebase due to CSIPHY re-arch dependencies merged - bod
- Remove redundant CSIPHY resources in CAMSS block
- Enhance the commit title description for CAMSS and CSIPHY blocks
- Collet RBs from Loic
- Link to v16: https://lore.kernel.org/r/20260915-kaanapali-camss-v16-0-c9f3f6f4180c@oss.qualcomm.com
Changes in v16:
- Remove RBs for binding, CSIPHY and CAMSS DT as tags stale due to
split-CSIPHY re-arch - Krzysztof
- Update CAMSS bindings and driver support for the standalone CSI2 PHY
provider and graph-based PHY lookup model - bod
- Add the CDM IOMMU stream and simplify CAMSS binding example part by
removing redundant subnodes - bod
- Improve commit descriptions for CAMSS compatible, CSID, VFE, TPG
- Clarify the common-status-offset change with x1e80100 compatibility
details and future SoC offset considerations
- Add Kaanapali camera DT descriptions, including CAMSS, six CSIPHYs,
three CCI controllers, camera-control I2C, and MCLK pinctrl states
- Rename I2C and MCLK pinctrl nodes to include interface identifiers
- Link to v15: https://lore.kernel.org/r/20260720-kaanapali-camss-v15-0-c0b1c1167c5d@oss.qualcomm.com
Changes in v15:
- Add TPG v2.4.0 support
- Drive the CSIPHY through the standalone phy-qcom-mipi-csi2 DPHY
driver, which let CAMSS csiphy_res only carry id, ops and formats
- Add a preparatory patch parametrising the PHY common status offset
- Add the mipi_csi2_dphy_3nm_kaanapali config and "qcom,kaanapali-csi2-phy"
based on the new split-csiphy arch
- Link to v14: https://lore.kernel.org/r/20260601-kaanapali-camss-v14-0-e76f26aa6691@oss.qualcomm.com
Changes in v14:
- Define 'CSI2_RX_CFG0_PHY_SEL_BASE_IDX' locally in camss-csid-gen4.c - bod
- Align csiphy lane registers value capitalization and case rule for 2.4.0
- Rebase this series due to conflict - bod
- Link to v13: https://lore.kernel.org/r/20260508-kaanapali-camss-v13-0-2541d8e55651@oss.qualcomm.com
Changes in v13:
- Remove prerequisite dependencies that have been merged upstream
- Remove redundant empty 'regulators' initializers in csid and vfe - bod
- 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 v12: https://lore.kernel.org/all/20260112-kaanapali-camss-v12-0-15b7af73401e@oss.qualcomm.com/
Changes in v12:
- Add CSIPHY regulator current due to regulator interface changed - bod
- Link to v11: https://lore.kernel.org/r/20260112-kaanapali-camss-v11-0-81e4f59a5d08@oss.qualcomm.com
Changes in v11:
- Rebase this series due to conflict - bod
- Update binding commit message to align with previous generations
- Link to v10: https://lore.kernel.org/r/20251211-add-support-for-camss-on-kaanapali-v10-0-39e8874dcd27@oss.qualcomm.com
Changes in v10:
- Update interconnect and CX domain AXI clock names to be consistent with
previous generations - bod
- Update the struct name for csiphy lane register settings to make it reusable
for other compatible chipsets
- Updated power domain names to IFE for consistency - Krzysztof
- Add description for acronyms listed in binding commit message - Dmitry
- Link to v9: https://lore.kernel.org/r/20251208-add-support-for-camss-on-kaanapali-v9-0-3fcd31258415@oss.qualcomm.com
Changes in v9:
- Updates the names of some of the resources in DT bindings to be consistent
with previous generations and improve the commit its message. The name
changes are also applied to csiphy and vfe camss resource lists - bod
- Link to v8: https://lore.kernel.org/r/20251130-add-support-for-camss-on-kaanapali-v8-0-143a8265e6e8@oss.qualcomm.com
Changes in v8:
- Change csid and vfe driver file names as 'gen4' to reuse for other SOCs - bod
- Add missing register descriptions to binding and cover letter commit log - bod
- Link to v7: https://lore.kernel.org/r/20251120-add-support-for-camss-on-kaanapali-v7-0-de27f9a67ce6@oss.qualcomm.com
Changes in v7:
- Add ICP SYS registers to camss binding - bod
- Rename 'is_deferred' to 'reg_update_after_csid_config' to do rup/aup
after csid config to make it clearer and simplify its call path - bod
- Remove unnecessary bitwise AND while configuring image address to bus- bod
- Tidy up a comment and a couple of hex values and csid/vfe - bod
- Link to v6: https://lore.kernel.org/r/20251113-add-support-for-camss-on-kaanapali-v6-0-1e6038785a8e@oss.qualcomm.com
Changes in v6:
- Modified the bindings to represent the whole of the camera hardware on
KNP than just what is exercised by the CAMSS driver by extending the
descriptions and the properties, the regs, clocks, interrupts, power
domains, iommus etc. In addition, use the word 'vfe' everywhere in the
bindings to be clear that all of those resources are referring to the
same front end modules. - Krzysztof/bod
- Change camss vfe power domain names to align with the binding file
- Link to v5: https://lore.kernel.org/r/20251030-add-support-for-camss-on-kaanapali-v5-0-f8e12bea3d02@oss.qualcomm.com
Changes in v5:
- Refine v4 change log - Krzysztof
- Fix typo by removing redundant numerical version in kaanapali camss binding
comment description - Krzysztof
- Add missing tags that should be posted with v4 revision - Krzysztof/Andi
- Link to v4: https://lore.kernel.org/r/20251028-add-support-for-camss-on-kaanapali-v4-0-7eb484c89585@oss.qualcomm.com
Changes in v4:
- Add detailed hardware descriptions and revise message title to follow the
standard comment format for kaanapali camss binding file - Krzysztof
- Format kaanapali camss binding file to keep style consistency, by reverting
power domain name from TFE to IFE and keeping clocks name order as last
generation - Krzysztof
- Separate the 1.2 and 0.9 voltage supply DT flags for each CSIPHY to allow
for arbitrary board design with common or unique supplies to each of the PHYs
in kaanapali camss binding example, based on v2 comments - bod/Vladimir
- Link to v3: https://lore.kernel.org/r/20251023-add-support-for-camss-on-kaanapali-v3-0-02abc9a107bf@oss.qualcomm.com
Changes in v3:
- Use the name 'ahb' for 'cam_top_ahb' clock in cci binding file - Vladimir
- Reduce and simplify CSIPHY supply, port properties in camss bindings - Vladimir
- Resolve the dependency issues in the camss bindings file using ephemeral
DT nodes - Vladimir/Dmitry
- Update hf mnoc name and bandwidth values for icc module - bod
- Split CSIPHY status macro changes into a separate patch series - bod
- Add clear functions for AUP/RUP update in csid and vfe for consistency - bod
- Clarify why the RUP and AUP register update process is deferred - bod
- Clarify the necessity to keep NRT clocks for vfe - Vijay
- Link to v2: https://lore.kernel.org/r/20251014-add-support-for-camss-on-kaanapali-v2-0-f5745ba2dff9@oss.qualcomm.com
Changes in v2:
- Aggregate CSI2_RX_CFG0_PHY_SEL_BASE_IDX definition into 'camss-csid.h' - bod
- Remove 'camss-csid-1080.h' and use 'camss-csid-gen3.h' header instead - bod
- Remove redundant code in 'camss-csid-1080.c' and align the namespaces - bod
- Slipt 'camnoc_rt_axi' clock in vfe matching list into a single patch - bod
- Add whole vfe write engine client mappings in comment - bod
- Remove hardcoded image buffer number but use 'CAMSS_INIT_BUF_COUNT' - bod
- Remove SoC specific logic for vfe ops->reg_update and add a new variable
to determine whether ops->reg_update is deferred or not - bod
- Add description to explain why 'qdss_debug_xo' should be retained - bod
- Add the procss node in csiphy register list comment - bod
- Rename the variable 'cmn_status_offset' to 'common_status_offset' and
align this with macro in csiphy register structure to avoid ambiguity - bod
- Aggregate Kaanapali items into the definition that introduced by
'qcom,qcm2290-cci' in cci binding file - Loic
- Format 'kaanpali-camss.yaml' binding file
- Link to v1: https://lore.kernel.org/r/20250924-knp-cam-v1-0-b72d6deea054@oss.qualcomm.com
---
Hangxiang Ma (11):
dt-bindings: phy: qcom,x1e80100-csi2-phy: Add Kaanapali CSI2 PHY
media: dt-bindings: Add CAMSS device for Kaanapali
media: qcom: camss: Add Kaanapali compatible
phy: qcom-mipi-csi2: Parametrise the common status register offset
media: qcom: camss: csiphy: Add support for v2.4.0 two-phase CSIPHY
media: qcom: camss: csid: Add support for CSID Gen4
media: qcom: camss: vfe: Add support for VFE Gen4
media: qcom: camss: tpg: Add support for v2.4.0 TPG
arm64: dts: qcom: kaanapali: Add CAMSS and CSIPHY block definitions
arm64: dts: qcom: kaanapali: Add CCI controller nodes
arm64: dts: qcom: kaanapali: Add camera MCLK pinctrl
.../bindings/media/qcom,kaanapali-camss.yaml | 303 +++++++++
.../bindings/phy/qcom,x1e80100-csi2-phy.yaml | 4 +-
arch/arm64/boot/dts/qcom/kaanapali.dtsi | 683 +++++++++++++++++++++
drivers/media/platform/qcom/camss/Makefile | 2 +
.../media/platform/qcom/camss/camss-csid-gen4.c | 391 ++++++++++++
drivers/media/platform/qcom/camss/camss-csid.h | 9 +-
drivers/media/platform/qcom/camss/camss-tpg-gen1.c | 27 +-
drivers/media/platform/qcom/camss/camss-vfe-gen4.c | 197 ++++++
drivers/media/platform/qcom/camss/camss-vfe.c | 9 +-
drivers/media/platform/qcom/camss/camss-vfe.h | 2 +
drivers/media/platform/qcom/camss/camss.c | 305 +++++++++
drivers/media/platform/qcom/camss/camss.h | 1 +
drivers/phy/qualcomm/phy-qcom-mipi-csi2-3ph-dphy.c | 32 +-
drivers/phy/qualcomm/phy-qcom-mipi-csi2-core.c | 1 +
drivers/phy/qualcomm/phy-qcom-mipi-csi2.h | 2 +
15 files changed, 1953 insertions(+), 15 deletions(-)
---
base-commit: 97952267cf371f4f1be0457b59a3fc5fdf7d3142
change-id: 20260112-kaanapali-camss-73772d44eff7
Best regards,
--
Hangxiang Ma <hangxiang.ma@oss.qualcomm.com>
^ permalink raw reply [flat|nested] 58+ messages in thread
* [PATCH v17 00/11] media: qcom: camss: Add Kaanapali support
@ 2026-09-29 6:00 ` Hangxiang Ma
0 siblings, 0 replies; 58+ messages in thread
From: Hangxiang Ma @ 2026-09-29 6:00 UTC (permalink / raw)
To: Bryan O'Donoghue, Vinod Koul, Neil Armstrong,
Manivannan Sadhasivam, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Bryan O'Donoghue, Vladimir Zapolskiy,
Loic Poulain, Mauro Carvalho Chehab, Bjorn Andersson,
Konrad Dybcio, Abel Vesa
Cc: linux-phy, linux-media, linux-arm-msm, devicetree, linux-kernel,
jeyaprakash.soundrapandian, Vijay Kumar Tumati, Hangxiang Ma,
Atiya Kailany, Konrad Dybcio
Add support for the RDI only CAMSS camera driver on Kaanapali. 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.
Kaanapali 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
Signed-off-by: Hangxiang Ma <hangxiang.ma@oss.qualcomm.com>
---
Changes in v17:
- Rebase due to CSIPHY re-arch dependencies merged - bod
- Remove redundant CSIPHY resources in CAMSS block
- Enhance the commit title description for CAMSS and CSIPHY blocks
- Collet RBs from Loic
- Link to v16: https://lore.kernel.org/r/20260915-kaanapali-camss-v16-0-c9f3f6f4180c@oss.qualcomm.com
Changes in v16:
- Remove RBs for binding, CSIPHY and CAMSS DT as tags stale due to
split-CSIPHY re-arch - Krzysztof
- Update CAMSS bindings and driver support for the standalone CSI2 PHY
provider and graph-based PHY lookup model - bod
- Add the CDM IOMMU stream and simplify CAMSS binding example part by
removing redundant subnodes - bod
- Improve commit descriptions for CAMSS compatible, CSID, VFE, TPG
- Clarify the common-status-offset change with x1e80100 compatibility
details and future SoC offset considerations
- Add Kaanapali camera DT descriptions, including CAMSS, six CSIPHYs,
three CCI controllers, camera-control I2C, and MCLK pinctrl states
- Rename I2C and MCLK pinctrl nodes to include interface identifiers
- Link to v15: https://lore.kernel.org/r/20260720-kaanapali-camss-v15-0-c0b1c1167c5d@oss.qualcomm.com
Changes in v15:
- Add TPG v2.4.0 support
- Drive the CSIPHY through the standalone phy-qcom-mipi-csi2 DPHY
driver, which let CAMSS csiphy_res only carry id, ops and formats
- Add a preparatory patch parametrising the PHY common status offset
- Add the mipi_csi2_dphy_3nm_kaanapali config and "qcom,kaanapali-csi2-phy"
based on the new split-csiphy arch
- Link to v14: https://lore.kernel.org/r/20260601-kaanapali-camss-v14-0-e76f26aa6691@oss.qualcomm.com
Changes in v14:
- Define 'CSI2_RX_CFG0_PHY_SEL_BASE_IDX' locally in camss-csid-gen4.c - bod
- Align csiphy lane registers value capitalization and case rule for 2.4.0
- Rebase this series due to conflict - bod
- Link to v13: https://lore.kernel.org/r/20260508-kaanapali-camss-v13-0-2541d8e55651@oss.qualcomm.com
Changes in v13:
- Remove prerequisite dependencies that have been merged upstream
- Remove redundant empty 'regulators' initializers in csid and vfe - bod
- 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 v12: https://lore.kernel.org/all/20260112-kaanapali-camss-v12-0-15b7af73401e@oss.qualcomm.com/
Changes in v12:
- Add CSIPHY regulator current due to regulator interface changed - bod
- Link to v11: https://lore.kernel.org/r/20260112-kaanapali-camss-v11-0-81e4f59a5d08@oss.qualcomm.com
Changes in v11:
- Rebase this series due to conflict - bod
- Update binding commit message to align with previous generations
- Link to v10: https://lore.kernel.org/r/20251211-add-support-for-camss-on-kaanapali-v10-0-39e8874dcd27@oss.qualcomm.com
Changes in v10:
- Update interconnect and CX domain AXI clock names to be consistent with
previous generations - bod
- Update the struct name for csiphy lane register settings to make it reusable
for other compatible chipsets
- Updated power domain names to IFE for consistency - Krzysztof
- Add description for acronyms listed in binding commit message - Dmitry
- Link to v9: https://lore.kernel.org/r/20251208-add-support-for-camss-on-kaanapali-v9-0-3fcd31258415@oss.qualcomm.com
Changes in v9:
- Updates the names of some of the resources in DT bindings to be consistent
with previous generations and improve the commit its message. The name
changes are also applied to csiphy and vfe camss resource lists - bod
- Link to v8: https://lore.kernel.org/r/20251130-add-support-for-camss-on-kaanapali-v8-0-143a8265e6e8@oss.qualcomm.com
Changes in v8:
- Change csid and vfe driver file names as 'gen4' to reuse for other SOCs - bod
- Add missing register descriptions to binding and cover letter commit log - bod
- Link to v7: https://lore.kernel.org/r/20251120-add-support-for-camss-on-kaanapali-v7-0-de27f9a67ce6@oss.qualcomm.com
Changes in v7:
- Add ICP SYS registers to camss binding - bod
- Rename 'is_deferred' to 'reg_update_after_csid_config' to do rup/aup
after csid config to make it clearer and simplify its call path - bod
- Remove unnecessary bitwise AND while configuring image address to bus- bod
- Tidy up a comment and a couple of hex values and csid/vfe - bod
- Link to v6: https://lore.kernel.org/r/20251113-add-support-for-camss-on-kaanapali-v6-0-1e6038785a8e@oss.qualcomm.com
Changes in v6:
- Modified the bindings to represent the whole of the camera hardware on
KNP than just what is exercised by the CAMSS driver by extending the
descriptions and the properties, the regs, clocks, interrupts, power
domains, iommus etc. In addition, use the word 'vfe' everywhere in the
bindings to be clear that all of those resources are referring to the
same front end modules. - Krzysztof/bod
- Change camss vfe power domain names to align with the binding file
- Link to v5: https://lore.kernel.org/r/20251030-add-support-for-camss-on-kaanapali-v5-0-f8e12bea3d02@oss.qualcomm.com
Changes in v5:
- Refine v4 change log - Krzysztof
- Fix typo by removing redundant numerical version in kaanapali camss binding
comment description - Krzysztof
- Add missing tags that should be posted with v4 revision - Krzysztof/Andi
- Link to v4: https://lore.kernel.org/r/20251028-add-support-for-camss-on-kaanapali-v4-0-7eb484c89585@oss.qualcomm.com
Changes in v4:
- Add detailed hardware descriptions and revise message title to follow the
standard comment format for kaanapali camss binding file - Krzysztof
- Format kaanapali camss binding file to keep style consistency, by reverting
power domain name from TFE to IFE and keeping clocks name order as last
generation - Krzysztof
- Separate the 1.2 and 0.9 voltage supply DT flags for each CSIPHY to allow
for arbitrary board design with common or unique supplies to each of the PHYs
in kaanapali camss binding example, based on v2 comments - bod/Vladimir
- Link to v3: https://lore.kernel.org/r/20251023-add-support-for-camss-on-kaanapali-v3-0-02abc9a107bf@oss.qualcomm.com
Changes in v3:
- Use the name 'ahb' for 'cam_top_ahb' clock in cci binding file - Vladimir
- Reduce and simplify CSIPHY supply, port properties in camss bindings - Vladimir
- Resolve the dependency issues in the camss bindings file using ephemeral
DT nodes - Vladimir/Dmitry
- Update hf mnoc name and bandwidth values for icc module - bod
- Split CSIPHY status macro changes into a separate patch series - bod
- Add clear functions for AUP/RUP update in csid and vfe for consistency - bod
- Clarify why the RUP and AUP register update process is deferred - bod
- Clarify the necessity to keep NRT clocks for vfe - Vijay
- Link to v2: https://lore.kernel.org/r/20251014-add-support-for-camss-on-kaanapali-v2-0-f5745ba2dff9@oss.qualcomm.com
Changes in v2:
- Aggregate CSI2_RX_CFG0_PHY_SEL_BASE_IDX definition into 'camss-csid.h' - bod
- Remove 'camss-csid-1080.h' and use 'camss-csid-gen3.h' header instead - bod
- Remove redundant code in 'camss-csid-1080.c' and align the namespaces - bod
- Slipt 'camnoc_rt_axi' clock in vfe matching list into a single patch - bod
- Add whole vfe write engine client mappings in comment - bod
- Remove hardcoded image buffer number but use 'CAMSS_INIT_BUF_COUNT' - bod
- Remove SoC specific logic for vfe ops->reg_update and add a new variable
to determine whether ops->reg_update is deferred or not - bod
- Add description to explain why 'qdss_debug_xo' should be retained - bod
- Add the procss node in csiphy register list comment - bod
- Rename the variable 'cmn_status_offset' to 'common_status_offset' and
align this with macro in csiphy register structure to avoid ambiguity - bod
- Aggregate Kaanapali items into the definition that introduced by
'qcom,qcm2290-cci' in cci binding file - Loic
- Format 'kaanpali-camss.yaml' binding file
- Link to v1: https://lore.kernel.org/r/20250924-knp-cam-v1-0-b72d6deea054@oss.qualcomm.com
---
Hangxiang Ma (11):
dt-bindings: phy: qcom,x1e80100-csi2-phy: Add Kaanapali CSI2 PHY
media: dt-bindings: Add CAMSS device for Kaanapali
media: qcom: camss: Add Kaanapali compatible
phy: qcom-mipi-csi2: Parametrise the common status register offset
media: qcom: camss: csiphy: Add support for v2.4.0 two-phase CSIPHY
media: qcom: camss: csid: Add support for CSID Gen4
media: qcom: camss: vfe: Add support for VFE Gen4
media: qcom: camss: tpg: Add support for v2.4.0 TPG
arm64: dts: qcom: kaanapali: Add CAMSS and CSIPHY block definitions
arm64: dts: qcom: kaanapali: Add CCI controller nodes
arm64: dts: qcom: kaanapali: Add camera MCLK pinctrl
.../bindings/media/qcom,kaanapali-camss.yaml | 303 +++++++++
.../bindings/phy/qcom,x1e80100-csi2-phy.yaml | 4 +-
arch/arm64/boot/dts/qcom/kaanapali.dtsi | 683 +++++++++++++++++++++
drivers/media/platform/qcom/camss/Makefile | 2 +
.../media/platform/qcom/camss/camss-csid-gen4.c | 391 ++++++++++++
drivers/media/platform/qcom/camss/camss-csid.h | 9 +-
drivers/media/platform/qcom/camss/camss-tpg-gen1.c | 27 +-
drivers/media/platform/qcom/camss/camss-vfe-gen4.c | 197 ++++++
drivers/media/platform/qcom/camss/camss-vfe.c | 9 +-
drivers/media/platform/qcom/camss/camss-vfe.h | 2 +
drivers/media/platform/qcom/camss/camss.c | 305 +++++++++
drivers/media/platform/qcom/camss/camss.h | 1 +
drivers/phy/qualcomm/phy-qcom-mipi-csi2-3ph-dphy.c | 32 +-
drivers/phy/qualcomm/phy-qcom-mipi-csi2-core.c | 1 +
drivers/phy/qualcomm/phy-qcom-mipi-csi2.h | 2 +
15 files changed, 1953 insertions(+), 15 deletions(-)
---
base-commit: 97952267cf371f4f1be0457b59a3fc5fdf7d3142
change-id: 20260112-kaanapali-camss-73772d44eff7
Best regards,
--
Hangxiang Ma <hangxiang.ma@oss.qualcomm.com>
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply [flat|nested] 58+ messages in thread
* [PATCH v17 01/11] dt-bindings: phy: qcom,x1e80100-csi2-phy: Add Kaanapali CSI2 PHY
2026-09-29 6:00 ` Hangxiang Ma
@ 2026-09-29 6:00 ` Hangxiang Ma
-1 siblings, 0 replies; 58+ messages in thread
From: Hangxiang Ma @ 2026-09-29 6:00 UTC (permalink / raw)
To: Bryan O'Donoghue, Vinod Koul, Neil Armstrong,
Manivannan Sadhasivam, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Bryan O'Donoghue, Vladimir Zapolskiy,
Loic Poulain, Mauro Carvalho Chehab, Bjorn Andersson,
Konrad Dybcio, Abel Vesa
Cc: linux-phy, linux-media, linux-arm-msm, devicetree, linux-kernel,
jeyaprakash.soundrapandian, Vijay Kumar Tumati, Hangxiang Ma
The Kaanapali CSI2 PHY is compatible with the existing x1e80100 CSI2
C-PHY/DPHY binding. Add the "qcom,kaanapali-csi2-phy" compatible.
Reviewed-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
Signed-off-by: Hangxiang Ma <hangxiang.ma@oss.qualcomm.com>
---
Documentation/devicetree/bindings/phy/qcom,x1e80100-csi2-phy.yaml | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/phy/qcom,x1e80100-csi2-phy.yaml b/Documentation/devicetree/bindings/phy/qcom,x1e80100-csi2-phy.yaml
index dc64af97da6c..24ca06b97656 100644
--- a/Documentation/devicetree/bindings/phy/qcom,x1e80100-csi2-phy.yaml
+++ b/Documentation/devicetree/bindings/phy/qcom,x1e80100-csi2-phy.yaml
@@ -16,7 +16,9 @@ description:
properties:
compatible:
- const: qcom,x1e80100-csi2-phy
+ enum:
+ - qcom,kaanapali-csi2-phy
+ - qcom,x1e80100-csi2-phy
reg:
maxItems: 1
--
2.34.1
^ permalink raw reply related [flat|nested] 58+ messages in thread
* [PATCH v17 01/11] dt-bindings: phy: qcom,x1e80100-csi2-phy: Add Kaanapali CSI2 PHY
@ 2026-09-29 6:00 ` Hangxiang Ma
0 siblings, 0 replies; 58+ messages in thread
From: Hangxiang Ma @ 2026-09-29 6:00 UTC (permalink / raw)
To: Bryan O'Donoghue, Vinod Koul, Neil Armstrong,
Manivannan Sadhasivam, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Bryan O'Donoghue, Vladimir Zapolskiy,
Loic Poulain, Mauro Carvalho Chehab, Bjorn Andersson,
Konrad Dybcio, Abel Vesa
Cc: linux-phy, linux-media, linux-arm-msm, devicetree, linux-kernel,
jeyaprakash.soundrapandian, Vijay Kumar Tumati, Hangxiang Ma
The Kaanapali CSI2 PHY is compatible with the existing x1e80100 CSI2
C-PHY/DPHY binding. Add the "qcom,kaanapali-csi2-phy" compatible.
Reviewed-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
Signed-off-by: Hangxiang Ma <hangxiang.ma@oss.qualcomm.com>
---
Documentation/devicetree/bindings/phy/qcom,x1e80100-csi2-phy.yaml | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/phy/qcom,x1e80100-csi2-phy.yaml b/Documentation/devicetree/bindings/phy/qcom,x1e80100-csi2-phy.yaml
index dc64af97da6c..24ca06b97656 100644
--- a/Documentation/devicetree/bindings/phy/qcom,x1e80100-csi2-phy.yaml
+++ b/Documentation/devicetree/bindings/phy/qcom,x1e80100-csi2-phy.yaml
@@ -16,7 +16,9 @@ description:
properties:
compatible:
- const: qcom,x1e80100-csi2-phy
+ enum:
+ - qcom,kaanapali-csi2-phy
+ - qcom,x1e80100-csi2-phy
reg:
maxItems: 1
--
2.34.1
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply related [flat|nested] 58+ messages in thread
* [PATCH v17 02/11] media: dt-bindings: Add CAMSS device for Kaanapali
2026-09-29 6:00 ` Hangxiang Ma
@ 2026-09-29 6:00 ` Hangxiang Ma
-1 siblings, 0 replies; 58+ messages in thread
From: Hangxiang Ma @ 2026-09-29 6:00 UTC (permalink / raw)
To: Bryan O'Donoghue, Vinod Koul, Neil Armstrong,
Manivannan Sadhasivam, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Bryan O'Donoghue, Vladimir Zapolskiy,
Loic Poulain, Mauro Carvalho Chehab, Bjorn Andersson,
Konrad Dybcio, Abel Vesa
Cc: linux-phy, linux-media, linux-arm-msm, devicetree, linux-kernel,
jeyaprakash.soundrapandian, Vijay Kumar Tumati, Hangxiang Ma
Add bindings for Camera Subsystem (CAMSS) on the Qualcomm Kaanapali
platform.
The Kaanapali platform 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
Signed-off-by: Hangxiang Ma <hangxiang.ma@oss.qualcomm.com>
---
.../bindings/media/qcom,kaanapali-camss.yaml | 303 +++++++++++++++++++++
1 file changed, 303 insertions(+)
diff --git a/Documentation/devicetree/bindings/media/qcom,kaanapali-camss.yaml b/Documentation/devicetree/bindings/media/qcom,kaanapali-camss.yaml
new file mode 100644
index 000000000000..1f8b18517e13
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/qcom,kaanapali-camss.yaml
@@ -0,0 +1,303 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/media/qcom,kaanapali-camss.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm Kaanapali Camera Subsystem (CAMSS)
+
+maintainers:
+ - Hangxiang Ma <hangxiang.ma@oss.qualcomm.com>
+
+description:
+ The CAMSS IP is a CSI decoder and ISP present on Qualcomm platforms.
+
+properties:
+ compatible:
+ const: qcom,kaanapali-camss
+
+ reg:
+ maxItems: 13
+
+ reg-names:
+ items:
+ - const: csid0
+ - const: csid1
+ - const: csid2
+ - const: csid_lite0
+ - const: csid_lite1
+ - const: csitpg0
+ - const: csitpg1
+ - const: csitpg2
+ - const: vfe0
+ - const: vfe1
+ - const: vfe2
+ - const: vfe_lite0
+ - const: vfe_lite1
+
+ clocks:
+ maxItems: 23
+
+ clock-names:
+ items:
+ - const: camnoc_nrt_axi
+ - const: camnoc_rt_axi
+ - const: cpas_ahb
+ - const: cpas_fast_ahb
+ - const: cpas_vfe0
+ - const: cpas_vfe1
+ - const: cpas_vfe2
+ - const: cpas_vfe_lite
+ - const: csid
+ - const: csid_csiphy_rx
+ - const: gcc_axi_hf
+ - const: gcc_axi_sf
+ - const: vfe0
+ - const: vfe0_fast_ahb
+ - const: vfe1
+ - const: vfe1_fast_ahb
+ - const: vfe2
+ - const: vfe2_fast_ahb
+ - const: vfe_lite
+ - const: vfe_lite_ahb
+ - const: vfe_lite_cphy_rx
+ - const: vfe_lite_csid
+ - const: qdss_debug_xo
+
+ interrupts:
+ maxItems: 10
+
+ interrupt-names:
+ items:
+ - const: csid0
+ - const: csid1
+ - const: csid2
+ - const: csid_lite0
+ - const: csid_lite1
+ - const: vfe0
+ - const: vfe1
+ - const: vfe2
+ - const: vfe_lite0
+ - const: vfe_lite1
+
+ interconnects:
+ maxItems: 2
+
+ interconnect-names:
+ items:
+ - const: ahb
+ - const: hf_mnoc
+
+ iommus:
+ items:
+ - description: S1 HLOS IFE non-protected stream
+
+ power-domains:
+ items:
+ - description: IFE0 GDSC - Global Distributed Switch Controller for IFE0.
+ - description: IFE1 GDSC - Global Distributed Switch Controller for IFE1.
+ - description: IFE2 GDSC - Global Distributed Switch Controller for IFE2.
+ - description: Titan Top GDSC - Titan ISP Block, Global Distributed Switch Controller.
+
+ power-domain-names:
+ items:
+ - const: ife0
+ - const: ife1
+ - const: ife2
+ - const: top
+
+ ports:
+ $ref: /schemas/graph.yaml#/properties/ports
+
+ description:
+ CSI input ports, one per CSID. Each port receives the CSI data
+ decoded by the matching CSIPHY.
+
+ patternProperties:
+ "^port@[0-5]$":
+ $ref: /schemas/graph.yaml#/$defs/port-base
+ unevaluatedProperties: false
+ description:
+ Input port for receiving CSI data from CSIPHY 0-5.
+
+ properties:
+ endpoint:
+ $ref: video-interfaces.yaml#
+ unevaluatedProperties: false
+
+ properties:
+ data-lanes:
+ minItems: 1
+ maxItems: 4
+
+ bus-type:
+ enum:
+ - 1 # MEDIA_BUS_TYPE_CSI2_CPHY
+ - 4 # MEDIA_BUS_TYPE_CSI2_DPHY
+
+ required:
+ - data-lanes
+
+required:
+ - compatible
+ - reg
+ - reg-names
+ - clocks
+ - clock-names
+ - interrupts
+ - interrupt-names
+ - interconnects
+ - interconnect-names
+ - iommus
+ - power-domains
+ - power-domain-names
+ - ports
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/qcom,kaanapali-gcc.h>
+ #include <dt-bindings/clock/qcom,kaanapali-camcc.h>
+ #include <dt-bindings/interconnect/qcom,icc.h>
+ #include <dt-bindings/interconnect/qcom,kaanapali-rpmh.h>
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ #include <dt-bindings/power/qcom,rpmhpd.h>
+
+ soc {
+ #address-cells = <2>;
+ #size-cells = <2>;
+
+ isp@9253000 {
+ compatible = "qcom,kaanapali-camss";
+
+ reg = <0x0 0x09253000 0x0 0x5e80>,
+ <0x0 0x09263000 0x0 0x5e80>,
+ <0x0 0x09273000 0x0 0x5e80>,
+ <0x0 0x092d3000 0x0 0x3880>,
+ <0x0 0x092e7000 0x0 0x3880>,
+ <0x0 0x093fd000 0x0 0x400>,
+ <0x0 0x093fe000 0x0 0x400>,
+ <0x0 0x093ff000 0x0 0x400>,
+ <0x0 0x09151000 0x0 0x20000>,
+ <0x0 0x09171000 0x0 0x20000>,
+ <0x0 0x09191000 0x0 0x20000>,
+ <0x0 0x092dc000 0x0 0x1300>,
+ <0x0 0x092f0000 0x0 0x1300>;
+
+ reg-names = "csid0",
+ "csid1",
+ "csid2",
+ "csid_lite0",
+ "csid_lite1",
+ "csitpg0",
+ "csitpg1",
+ "csitpg2",
+ "vfe0",
+ "vfe1",
+ "vfe2",
+ "vfe_lite0",
+ "vfe_lite1";
+
+ clocks = <&camcc CAM_CC_CAMNOC_NRT_AXI_CLK>,
+ <&camcc CAM_CC_CAMNOC_RT_AXI_CLK>,
+ <&camcc CAM_CC_CAM_TOP_AHB_CLK>,
+ <&camcc CAM_CC_CAM_TOP_FAST_AHB_CLK>,
+ <&camcc CAM_CC_CAMNOC_RT_TFE_0_MAIN_CLK>,
+ <&camcc CAM_CC_CAMNOC_RT_TFE_1_MAIN_CLK>,
+ <&camcc CAM_CC_CAMNOC_RT_TFE_2_MAIN_CLK>,
+ <&camcc CAM_CC_CAMNOC_RT_IFE_LITE_CLK>,
+ <&camcc CAM_CC_CSID_CLK>,
+ <&camcc CAM_CC_CSID_CSIPHY_RX_CLK>,
+ <&gcc GCC_CAMERA_HF_AXI_CLK>,
+ <&gcc GCC_CAMERA_SF_AXI_CLK>,
+ <&camcc CAM_CC_TFE_0_MAIN_CLK>,
+ <&camcc CAM_CC_TFE_0_MAIN_FAST_AHB_CLK>,
+ <&camcc CAM_CC_TFE_1_MAIN_CLK>,
+ <&camcc CAM_CC_TFE_1_MAIN_FAST_AHB_CLK>,
+ <&camcc CAM_CC_TFE_2_MAIN_CLK>,
+ <&camcc CAM_CC_TFE_2_MAIN_FAST_AHB_CLK>,
+ <&camcc CAM_CC_IFE_LITE_CLK>,
+ <&camcc CAM_CC_IFE_LITE_AHB_CLK>,
+ <&camcc CAM_CC_IFE_LITE_CPHY_RX_CLK>,
+ <&camcc CAM_CC_IFE_LITE_CSID_CLK>,
+ <&camcc CAM_CC_QDSS_DEBUG_XO_CLK>;
+
+ clock-names = "camnoc_nrt_axi",
+ "camnoc_rt_axi",
+ "cpas_ahb",
+ "cpas_fast_ahb",
+ "cpas_vfe0",
+ "cpas_vfe1",
+ "cpas_vfe2",
+ "cpas_vfe_lite",
+ "csid",
+ "csid_csiphy_rx",
+ "gcc_axi_hf",
+ "gcc_axi_sf",
+ "vfe0",
+ "vfe0_fast_ahb",
+ "vfe1",
+ "vfe1_fast_ahb",
+ "vfe2",
+ "vfe2_fast_ahb",
+ "vfe_lite",
+ "vfe_lite_ahb",
+ "vfe_lite_cphy_rx",
+ "vfe_lite_csid",
+ "qdss_debug_xo";
+
+ interrupts = <GIC_SPI 601 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 603 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 431 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 605 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 376 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 433 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 436 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 457 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 606 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 377 IRQ_TYPE_EDGE_RISING>;
+
+ interrupt-names = "csid0",
+ "csid1",
+ "csid2",
+ "csid_lite0",
+ "csid_lite1",
+ "vfe0",
+ "vfe1",
+ "vfe2",
+ "vfe_lite0",
+ "vfe_lite1";
+
+ interconnects = <&gem_noc MASTER_APPSS_PROC QCOM_ICC_TAG_ACTIVE_ONLY
+ &config_noc SLAVE_CAMERA_CFG QCOM_ICC_TAG_ACTIVE_ONLY>,
+ <&mmss_noc MASTER_CAMNOC_HF QCOM_ICC_TAG_ALWAYS
+ &mc_virt SLAVE_EBI1 QCOM_ICC_TAG_ALWAYS>;
+ interconnect-names = "ahb",
+ "hf_mnoc";
+
+ iommus = <&apps_smmu 0x1c00 0x00>;
+
+ power-domains = <&camcc CAM_CC_TFE_0_GDSC>,
+ <&camcc CAM_CC_TFE_1_GDSC>,
+ <&camcc CAM_CC_TFE_2_GDSC>,
+ <&camcc CAM_CC_TITAN_TOP_GDSC>;
+ power-domain-names = "ife0",
+ "ife1",
+ "ife2",
+ "top";
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+ camss_csiphy0_ep: endpoint {
+ data-lanes = <1 2 3 4>;
+ remote-endpoint = <&csiphy0_out>;
+ };
+ };
+ };
+ };
+ };
--
2.34.1
^ permalink raw reply related [flat|nested] 58+ messages in thread
* [PATCH v17 02/11] media: dt-bindings: Add CAMSS device for Kaanapali
@ 2026-09-29 6:00 ` Hangxiang Ma
0 siblings, 0 replies; 58+ messages in thread
From: Hangxiang Ma @ 2026-09-29 6:00 UTC (permalink / raw)
To: Bryan O'Donoghue, Vinod Koul, Neil Armstrong,
Manivannan Sadhasivam, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Bryan O'Donoghue, Vladimir Zapolskiy,
Loic Poulain, Mauro Carvalho Chehab, Bjorn Andersson,
Konrad Dybcio, Abel Vesa
Cc: linux-phy, linux-media, linux-arm-msm, devicetree, linux-kernel,
jeyaprakash.soundrapandian, Vijay Kumar Tumati, Hangxiang Ma
Add bindings for Camera Subsystem (CAMSS) on the Qualcomm Kaanapali
platform.
The Kaanapali platform 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
Signed-off-by: Hangxiang Ma <hangxiang.ma@oss.qualcomm.com>
---
.../bindings/media/qcom,kaanapali-camss.yaml | 303 +++++++++++++++++++++
1 file changed, 303 insertions(+)
diff --git a/Documentation/devicetree/bindings/media/qcom,kaanapali-camss.yaml b/Documentation/devicetree/bindings/media/qcom,kaanapali-camss.yaml
new file mode 100644
index 000000000000..1f8b18517e13
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/qcom,kaanapali-camss.yaml
@@ -0,0 +1,303 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/media/qcom,kaanapali-camss.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm Kaanapali Camera Subsystem (CAMSS)
+
+maintainers:
+ - Hangxiang Ma <hangxiang.ma@oss.qualcomm.com>
+
+description:
+ The CAMSS IP is a CSI decoder and ISP present on Qualcomm platforms.
+
+properties:
+ compatible:
+ const: qcom,kaanapali-camss
+
+ reg:
+ maxItems: 13
+
+ reg-names:
+ items:
+ - const: csid0
+ - const: csid1
+ - const: csid2
+ - const: csid_lite0
+ - const: csid_lite1
+ - const: csitpg0
+ - const: csitpg1
+ - const: csitpg2
+ - const: vfe0
+ - const: vfe1
+ - const: vfe2
+ - const: vfe_lite0
+ - const: vfe_lite1
+
+ clocks:
+ maxItems: 23
+
+ clock-names:
+ items:
+ - const: camnoc_nrt_axi
+ - const: camnoc_rt_axi
+ - const: cpas_ahb
+ - const: cpas_fast_ahb
+ - const: cpas_vfe0
+ - const: cpas_vfe1
+ - const: cpas_vfe2
+ - const: cpas_vfe_lite
+ - const: csid
+ - const: csid_csiphy_rx
+ - const: gcc_axi_hf
+ - const: gcc_axi_sf
+ - const: vfe0
+ - const: vfe0_fast_ahb
+ - const: vfe1
+ - const: vfe1_fast_ahb
+ - const: vfe2
+ - const: vfe2_fast_ahb
+ - const: vfe_lite
+ - const: vfe_lite_ahb
+ - const: vfe_lite_cphy_rx
+ - const: vfe_lite_csid
+ - const: qdss_debug_xo
+
+ interrupts:
+ maxItems: 10
+
+ interrupt-names:
+ items:
+ - const: csid0
+ - const: csid1
+ - const: csid2
+ - const: csid_lite0
+ - const: csid_lite1
+ - const: vfe0
+ - const: vfe1
+ - const: vfe2
+ - const: vfe_lite0
+ - const: vfe_lite1
+
+ interconnects:
+ maxItems: 2
+
+ interconnect-names:
+ items:
+ - const: ahb
+ - const: hf_mnoc
+
+ iommus:
+ items:
+ - description: S1 HLOS IFE non-protected stream
+
+ power-domains:
+ items:
+ - description: IFE0 GDSC - Global Distributed Switch Controller for IFE0.
+ - description: IFE1 GDSC - Global Distributed Switch Controller for IFE1.
+ - description: IFE2 GDSC - Global Distributed Switch Controller for IFE2.
+ - description: Titan Top GDSC - Titan ISP Block, Global Distributed Switch Controller.
+
+ power-domain-names:
+ items:
+ - const: ife0
+ - const: ife1
+ - const: ife2
+ - const: top
+
+ ports:
+ $ref: /schemas/graph.yaml#/properties/ports
+
+ description:
+ CSI input ports, one per CSID. Each port receives the CSI data
+ decoded by the matching CSIPHY.
+
+ patternProperties:
+ "^port@[0-5]$":
+ $ref: /schemas/graph.yaml#/$defs/port-base
+ unevaluatedProperties: false
+ description:
+ Input port for receiving CSI data from CSIPHY 0-5.
+
+ properties:
+ endpoint:
+ $ref: video-interfaces.yaml#
+ unevaluatedProperties: false
+
+ properties:
+ data-lanes:
+ minItems: 1
+ maxItems: 4
+
+ bus-type:
+ enum:
+ - 1 # MEDIA_BUS_TYPE_CSI2_CPHY
+ - 4 # MEDIA_BUS_TYPE_CSI2_DPHY
+
+ required:
+ - data-lanes
+
+required:
+ - compatible
+ - reg
+ - reg-names
+ - clocks
+ - clock-names
+ - interrupts
+ - interrupt-names
+ - interconnects
+ - interconnect-names
+ - iommus
+ - power-domains
+ - power-domain-names
+ - ports
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/qcom,kaanapali-gcc.h>
+ #include <dt-bindings/clock/qcom,kaanapali-camcc.h>
+ #include <dt-bindings/interconnect/qcom,icc.h>
+ #include <dt-bindings/interconnect/qcom,kaanapali-rpmh.h>
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ #include <dt-bindings/power/qcom,rpmhpd.h>
+
+ soc {
+ #address-cells = <2>;
+ #size-cells = <2>;
+
+ isp@9253000 {
+ compatible = "qcom,kaanapali-camss";
+
+ reg = <0x0 0x09253000 0x0 0x5e80>,
+ <0x0 0x09263000 0x0 0x5e80>,
+ <0x0 0x09273000 0x0 0x5e80>,
+ <0x0 0x092d3000 0x0 0x3880>,
+ <0x0 0x092e7000 0x0 0x3880>,
+ <0x0 0x093fd000 0x0 0x400>,
+ <0x0 0x093fe000 0x0 0x400>,
+ <0x0 0x093ff000 0x0 0x400>,
+ <0x0 0x09151000 0x0 0x20000>,
+ <0x0 0x09171000 0x0 0x20000>,
+ <0x0 0x09191000 0x0 0x20000>,
+ <0x0 0x092dc000 0x0 0x1300>,
+ <0x0 0x092f0000 0x0 0x1300>;
+
+ reg-names = "csid0",
+ "csid1",
+ "csid2",
+ "csid_lite0",
+ "csid_lite1",
+ "csitpg0",
+ "csitpg1",
+ "csitpg2",
+ "vfe0",
+ "vfe1",
+ "vfe2",
+ "vfe_lite0",
+ "vfe_lite1";
+
+ clocks = <&camcc CAM_CC_CAMNOC_NRT_AXI_CLK>,
+ <&camcc CAM_CC_CAMNOC_RT_AXI_CLK>,
+ <&camcc CAM_CC_CAM_TOP_AHB_CLK>,
+ <&camcc CAM_CC_CAM_TOP_FAST_AHB_CLK>,
+ <&camcc CAM_CC_CAMNOC_RT_TFE_0_MAIN_CLK>,
+ <&camcc CAM_CC_CAMNOC_RT_TFE_1_MAIN_CLK>,
+ <&camcc CAM_CC_CAMNOC_RT_TFE_2_MAIN_CLK>,
+ <&camcc CAM_CC_CAMNOC_RT_IFE_LITE_CLK>,
+ <&camcc CAM_CC_CSID_CLK>,
+ <&camcc CAM_CC_CSID_CSIPHY_RX_CLK>,
+ <&gcc GCC_CAMERA_HF_AXI_CLK>,
+ <&gcc GCC_CAMERA_SF_AXI_CLK>,
+ <&camcc CAM_CC_TFE_0_MAIN_CLK>,
+ <&camcc CAM_CC_TFE_0_MAIN_FAST_AHB_CLK>,
+ <&camcc CAM_CC_TFE_1_MAIN_CLK>,
+ <&camcc CAM_CC_TFE_1_MAIN_FAST_AHB_CLK>,
+ <&camcc CAM_CC_TFE_2_MAIN_CLK>,
+ <&camcc CAM_CC_TFE_2_MAIN_FAST_AHB_CLK>,
+ <&camcc CAM_CC_IFE_LITE_CLK>,
+ <&camcc CAM_CC_IFE_LITE_AHB_CLK>,
+ <&camcc CAM_CC_IFE_LITE_CPHY_RX_CLK>,
+ <&camcc CAM_CC_IFE_LITE_CSID_CLK>,
+ <&camcc CAM_CC_QDSS_DEBUG_XO_CLK>;
+
+ clock-names = "camnoc_nrt_axi",
+ "camnoc_rt_axi",
+ "cpas_ahb",
+ "cpas_fast_ahb",
+ "cpas_vfe0",
+ "cpas_vfe1",
+ "cpas_vfe2",
+ "cpas_vfe_lite",
+ "csid",
+ "csid_csiphy_rx",
+ "gcc_axi_hf",
+ "gcc_axi_sf",
+ "vfe0",
+ "vfe0_fast_ahb",
+ "vfe1",
+ "vfe1_fast_ahb",
+ "vfe2",
+ "vfe2_fast_ahb",
+ "vfe_lite",
+ "vfe_lite_ahb",
+ "vfe_lite_cphy_rx",
+ "vfe_lite_csid",
+ "qdss_debug_xo";
+
+ interrupts = <GIC_SPI 601 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 603 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 431 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 605 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 376 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 433 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 436 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 457 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 606 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 377 IRQ_TYPE_EDGE_RISING>;
+
+ interrupt-names = "csid0",
+ "csid1",
+ "csid2",
+ "csid_lite0",
+ "csid_lite1",
+ "vfe0",
+ "vfe1",
+ "vfe2",
+ "vfe_lite0",
+ "vfe_lite1";
+
+ interconnects = <&gem_noc MASTER_APPSS_PROC QCOM_ICC_TAG_ACTIVE_ONLY
+ &config_noc SLAVE_CAMERA_CFG QCOM_ICC_TAG_ACTIVE_ONLY>,
+ <&mmss_noc MASTER_CAMNOC_HF QCOM_ICC_TAG_ALWAYS
+ &mc_virt SLAVE_EBI1 QCOM_ICC_TAG_ALWAYS>;
+ interconnect-names = "ahb",
+ "hf_mnoc";
+
+ iommus = <&apps_smmu 0x1c00 0x00>;
+
+ power-domains = <&camcc CAM_CC_TFE_0_GDSC>,
+ <&camcc CAM_CC_TFE_1_GDSC>,
+ <&camcc CAM_CC_TFE_2_GDSC>,
+ <&camcc CAM_CC_TITAN_TOP_GDSC>;
+ power-domain-names = "ife0",
+ "ife1",
+ "ife2",
+ "top";
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+ camss_csiphy0_ep: endpoint {
+ data-lanes = <1 2 3 4>;
+ remote-endpoint = <&csiphy0_out>;
+ };
+ };
+ };
+ };
+ };
--
2.34.1
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply related [flat|nested] 58+ messages in thread
* [PATCH v17 03/11] media: qcom: camss: Add Kaanapali compatible
2026-09-29 6:00 ` Hangxiang Ma
@ 2026-09-29 6:00 ` Hangxiang Ma
-1 siblings, 0 replies; 58+ messages in thread
From: Hangxiang Ma @ 2026-09-29 6:00 UTC (permalink / raw)
To: Bryan O'Donoghue, Vinod Koul, Neil Armstrong,
Manivannan Sadhasivam, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Bryan O'Donoghue, Vladimir Zapolskiy,
Loic Poulain, Mauro Carvalho Chehab, Bjorn Andersson,
Konrad Dybcio, Abel Vesa
Cc: linux-phy, linux-media, linux-arm-msm, devicetree, linux-kernel,
jeyaprakash.soundrapandian, Vijay Kumar Tumati, Hangxiang Ma
Add CAMSS_KAANAPALI enum, Kaanapali compatible and Kaanapali CAMSS driver
private data, the private data just include some basic information
now, later changes will enumerate with CSIPHY, TPG, CSID and VFE
resources.
Reviewed-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
Reviewed-by: Loic Poulain <loic.poulain@oss.qualcomm.com>
Signed-off-by: Hangxiang Ma <hangxiang.ma@oss.qualcomm.com>
---
drivers/media/platform/qcom/camss/camss.c | 22 ++++++++++++++++++++++
drivers/media/platform/qcom/camss/camss.h | 1 +
2 files changed, 23 insertions(+)
diff --git a/drivers/media/platform/qcom/camss/camss.c b/drivers/media/platform/qcom/camss/camss.c
index 23f3cc30a15a..a528760487bd 100644
--- a/drivers/media/platform/qcom/camss/camss.c
+++ b/drivers/media/platform/qcom/camss/camss.c
@@ -34,6 +34,20 @@
static const struct parent_dev_ops vfe_parent_dev_ops;
+static const struct resources_icc icc_res_kaanapali[] = {
+ {
+ .name = "ahb",
+ .icc_bw_tbl.avg = 150000,
+ .icc_bw_tbl.peak = 300000,
+ },
+ /* Based on 4096 x 3072 30 FPS 2496 Mbps mode */
+ {
+ .name = "hf_mnoc",
+ .icc_bw_tbl.avg = 471860,
+ .icc_bw_tbl.peak = 925857,
+ }
+};
+
static const struct camss_subdev_resources csiphy_res_8x16[] = {
/* CSIPHY0 */
{
@@ -5500,6 +5514,13 @@ static void camss_remove(struct platform_device *pdev)
camss_genpd_cleanup(camss);
}
+static const struct camss_resources kaanapali_resources = {
+ .version = CAMSS_KAANAPALI,
+ .pd_name = "top",
+ .icc_res = icc_res_kaanapali,
+ .icc_path_num = ARRAY_SIZE(icc_res_kaanapali),
+};
+
static const struct camss_resources msm8916_resources = {
.version = CAMSS_8x16,
.csiphy_res = csiphy_res_8x16,
@@ -5733,6 +5754,7 @@ static const struct camss_resources x1e80100_resources = {
};
static const struct of_device_id camss_dt_match[] = {
+ { .compatible = "qcom,kaanapali-camss", .data = &kaanapali_resources },
{ .compatible = "qcom,msm8916-camss", .data = &msm8916_resources },
{ .compatible = "qcom,msm8939-camss", .data = &msm8939_resources },
{ .compatible = "qcom,msm8953-camss", .data = &msm8953_resources },
diff --git a/drivers/media/platform/qcom/camss/camss.h b/drivers/media/platform/qcom/camss/camss.h
index 93d691c8ac63..2c7a0218a82b 100644
--- a/drivers/media/platform/qcom/camss/camss.h
+++ b/drivers/media/platform/qcom/camss/camss.h
@@ -96,6 +96,7 @@ enum camss_version {
CAMSS_8550,
CAMSS_8650,
CAMSS_8775P,
+ CAMSS_KAANAPALI,
CAMSS_X1E80100,
};
--
2.34.1
^ permalink raw reply related [flat|nested] 58+ messages in thread
* [PATCH v17 03/11] media: qcom: camss: Add Kaanapali compatible
@ 2026-09-29 6:00 ` Hangxiang Ma
0 siblings, 0 replies; 58+ messages in thread
From: Hangxiang Ma @ 2026-09-29 6:00 UTC (permalink / raw)
To: Bryan O'Donoghue, Vinod Koul, Neil Armstrong,
Manivannan Sadhasivam, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Bryan O'Donoghue, Vladimir Zapolskiy,
Loic Poulain, Mauro Carvalho Chehab, Bjorn Andersson,
Konrad Dybcio, Abel Vesa
Cc: linux-phy, linux-media, linux-arm-msm, devicetree, linux-kernel,
jeyaprakash.soundrapandian, Vijay Kumar Tumati, Hangxiang Ma
Add CAMSS_KAANAPALI enum, Kaanapali compatible and Kaanapali CAMSS driver
private data, the private data just include some basic information
now, later changes will enumerate with CSIPHY, TPG, CSID and VFE
resources.
Reviewed-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
Reviewed-by: Loic Poulain <loic.poulain@oss.qualcomm.com>
Signed-off-by: Hangxiang Ma <hangxiang.ma@oss.qualcomm.com>
---
drivers/media/platform/qcom/camss/camss.c | 22 ++++++++++++++++++++++
drivers/media/platform/qcom/camss/camss.h | 1 +
2 files changed, 23 insertions(+)
diff --git a/drivers/media/platform/qcom/camss/camss.c b/drivers/media/platform/qcom/camss/camss.c
index 23f3cc30a15a..a528760487bd 100644
--- a/drivers/media/platform/qcom/camss/camss.c
+++ b/drivers/media/platform/qcom/camss/camss.c
@@ -34,6 +34,20 @@
static const struct parent_dev_ops vfe_parent_dev_ops;
+static const struct resources_icc icc_res_kaanapali[] = {
+ {
+ .name = "ahb",
+ .icc_bw_tbl.avg = 150000,
+ .icc_bw_tbl.peak = 300000,
+ },
+ /* Based on 4096 x 3072 30 FPS 2496 Mbps mode */
+ {
+ .name = "hf_mnoc",
+ .icc_bw_tbl.avg = 471860,
+ .icc_bw_tbl.peak = 925857,
+ }
+};
+
static const struct camss_subdev_resources csiphy_res_8x16[] = {
/* CSIPHY0 */
{
@@ -5500,6 +5514,13 @@ static void camss_remove(struct platform_device *pdev)
camss_genpd_cleanup(camss);
}
+static const struct camss_resources kaanapali_resources = {
+ .version = CAMSS_KAANAPALI,
+ .pd_name = "top",
+ .icc_res = icc_res_kaanapali,
+ .icc_path_num = ARRAY_SIZE(icc_res_kaanapali),
+};
+
static const struct camss_resources msm8916_resources = {
.version = CAMSS_8x16,
.csiphy_res = csiphy_res_8x16,
@@ -5733,6 +5754,7 @@ static const struct camss_resources x1e80100_resources = {
};
static const struct of_device_id camss_dt_match[] = {
+ { .compatible = "qcom,kaanapali-camss", .data = &kaanapali_resources },
{ .compatible = "qcom,msm8916-camss", .data = &msm8916_resources },
{ .compatible = "qcom,msm8939-camss", .data = &msm8939_resources },
{ .compatible = "qcom,msm8953-camss", .data = &msm8953_resources },
diff --git a/drivers/media/platform/qcom/camss/camss.h b/drivers/media/platform/qcom/camss/camss.h
index 93d691c8ac63..2c7a0218a82b 100644
--- a/drivers/media/platform/qcom/camss/camss.h
+++ b/drivers/media/platform/qcom/camss/camss.h
@@ -96,6 +96,7 @@ enum camss_version {
CAMSS_8550,
CAMSS_8650,
CAMSS_8775P,
+ CAMSS_KAANAPALI,
CAMSS_X1E80100,
};
--
2.34.1
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply related [flat|nested] 58+ messages in thread
* [PATCH v17 04/11] phy: qcom-mipi-csi2: Parametrise the common status register offset
2026-09-29 6:00 ` Hangxiang Ma
@ 2026-09-29 6:00 ` Hangxiang Ma
-1 siblings, 0 replies; 58+ messages in thread
From: Hangxiang Ma @ 2026-09-29 6:00 UTC (permalink / raw)
To: Bryan O'Donoghue, Vinod Koul, Neil Armstrong,
Manivannan Sadhasivam, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Bryan O'Donoghue, Vladimir Zapolskiy,
Loic Poulain, Mauro Carvalho Chehab, Bjorn Andersson,
Konrad Dybcio, Abel Vesa
Cc: linux-phy, linux-media, linux-arm-msm, devicetree, linux-kernel,
jeyaprakash.soundrapandian, Vijay Kumar Tumati, Hangxiang Ma
The CSI2 PHY common status registers are not at a fixed offset from the
common register block across SoCs: x1e80100 uses 0xb0 while other 3PH
v2.4.0 parts differ.
Replace the hard-coded 0xb0 in CSIPHY_3PH_CMN_CSI_COMMON_STATUSn() with
a per-SoC common_status_offset field in struct mipi_csi2phy_device_regs,
initialising x1e80100 to 0xb0 so behaviour is unchanged. This is a
no-functional-change preparation for describing other SoC offsets.
Signed-off-by: Hangxiang Ma <hangxiang.ma@oss.qualcomm.com>
---
drivers/phy/qualcomm/phy-qcom-mipi-csi2-3ph-dphy.c | 16 +++++++++++-----
drivers/phy/qualcomm/phy-qcom-mipi-csi2.h | 1 +
2 files changed, 12 insertions(+), 5 deletions(-)
diff --git a/drivers/phy/qualcomm/phy-qcom-mipi-csi2-3ph-dphy.c b/drivers/phy/qualcomm/phy-qcom-mipi-csi2-3ph-dphy.c
index 966d79c98f9b..8cd331cfb4b3 100644
--- a/drivers/phy/qualcomm/phy-qcom-mipi-csi2-3ph-dphy.c
+++ b/drivers/phy/qualcomm/phy-qcom-mipi-csi2-3ph-dphy.c
@@ -19,7 +19,8 @@
#define CSIPHY_3PH_CMN_CSI_COMMON_CTRL6_COMMON_PWRDN_B BIT(0)
#define CSIPHY_3PH_CMN_CSI_COMMON_CTRL6_SHOW_REV_ID BIT(1)
#define CSIPHY_3PH_CMN_CSI_COMMON_CTRL10_IRQ_CLEAR_CMD BIT(0)
-#define CSIPHY_3PH_CMN_CSI_COMMON_STATUSn(offset, n) ((offset) + 0xb0 + 0x4 * (n))
+#define CSIPHY_3PH_CMN_CSI_COMMON_STATUSn(offset, common_status_offset, n) \
+ ((offset) + (common_status_offset) + 0x4 * (n))
#define CSIPHY_2PH_LN_CSI_2PHASE_CTRL9n(n) ((0x200 * (n)) + 0x24)
@@ -176,19 +177,23 @@ static void phy_qcom_mipi_csi2_hw_version_read(struct mipi_csi2phy_device *csi2p
CSIPHY_3PH_CMN_CSI_COMMON_CTRLn(regs->common_regs_offset, 6));
tmp = readl_relaxed(csi2phy->base +
- CSIPHY_3PH_CMN_CSI_COMMON_STATUSn(regs->common_regs_offset, 12));
+ CSIPHY_3PH_CMN_CSI_COMMON_STATUSn(regs->common_regs_offset,
+ regs->common_status_offset, 12));
csi2phy->hw_version = tmp;
tmp = readl_relaxed(csi2phy->base +
- CSIPHY_3PH_CMN_CSI_COMMON_STATUSn(regs->common_regs_offset, 13));
+ CSIPHY_3PH_CMN_CSI_COMMON_STATUSn(regs->common_regs_offset,
+ regs->common_status_offset, 13));
csi2phy->hw_version |= (tmp << 8) & 0xFF00;
tmp = readl_relaxed(csi2phy->base +
- CSIPHY_3PH_CMN_CSI_COMMON_STATUSn(regs->common_regs_offset, 14));
+ CSIPHY_3PH_CMN_CSI_COMMON_STATUSn(regs->common_regs_offset,
+ regs->common_status_offset, 14));
csi2phy->hw_version |= (tmp << 16) & 0xFF0000;
tmp = readl_relaxed(csi2phy->base +
- CSIPHY_3PH_CMN_CSI_COMMON_STATUSn(regs->common_regs_offset, 15));
+ CSIPHY_3PH_CMN_CSI_COMMON_STATUSn(regs->common_regs_offset,
+ regs->common_status_offset, 15));
csi2phy->hw_version |= (tmp << 24) & 0xFF000000;
dev_dbg_once(csi2phy->dev, "CSIPHY 3PH HW Version = 0x%08x\n", csi2phy->hw_version);
@@ -375,6 +380,7 @@ const struct mipi_csi2phy_soc_cfg mipi_csi2_dphy_4nm_x1e = {
.init_seq = lane_regs_x1e80100,
.lane_array_size = ARRAY_SIZE(lane_regs_x1e80100),
.common_regs_offset = 0x1000,
+ .common_status_offset = 0xb0,
},
.supply_names = (const char **)x1e_supplies,
.num_supplies = ARRAY_SIZE(x1e_supplies),
diff --git a/drivers/phy/qualcomm/phy-qcom-mipi-csi2.h b/drivers/phy/qualcomm/phy-qcom-mipi-csi2.h
index 7e55ae007370..d6366f809e51 100644
--- a/drivers/phy/qualcomm/phy-qcom-mipi-csi2.h
+++ b/drivers/phy/qualcomm/phy-qcom-mipi-csi2.h
@@ -51,6 +51,7 @@ struct mipi_csi2phy_device_regs {
const struct mipi_csi2phy_lane_regs *init_seq;
const int lane_array_size;
const u32 common_regs_offset;
+ const u32 common_status_offset;
};
struct mipi_csi2_genpd {
--
2.34.1
^ permalink raw reply related [flat|nested] 58+ messages in thread
* [PATCH v17 04/11] phy: qcom-mipi-csi2: Parametrise the common status register offset
@ 2026-09-29 6:00 ` Hangxiang Ma
0 siblings, 0 replies; 58+ messages in thread
From: Hangxiang Ma @ 2026-09-29 6:00 UTC (permalink / raw)
To: Bryan O'Donoghue, Vinod Koul, Neil Armstrong,
Manivannan Sadhasivam, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Bryan O'Donoghue, Vladimir Zapolskiy,
Loic Poulain, Mauro Carvalho Chehab, Bjorn Andersson,
Konrad Dybcio, Abel Vesa
Cc: linux-phy, linux-media, linux-arm-msm, devicetree, linux-kernel,
jeyaprakash.soundrapandian, Vijay Kumar Tumati, Hangxiang Ma
The CSI2 PHY common status registers are not at a fixed offset from the
common register block across SoCs: x1e80100 uses 0xb0 while other 3PH
v2.4.0 parts differ.
Replace the hard-coded 0xb0 in CSIPHY_3PH_CMN_CSI_COMMON_STATUSn() with
a per-SoC common_status_offset field in struct mipi_csi2phy_device_regs,
initialising x1e80100 to 0xb0 so behaviour is unchanged. This is a
no-functional-change preparation for describing other SoC offsets.
Signed-off-by: Hangxiang Ma <hangxiang.ma@oss.qualcomm.com>
---
drivers/phy/qualcomm/phy-qcom-mipi-csi2-3ph-dphy.c | 16 +++++++++++-----
drivers/phy/qualcomm/phy-qcom-mipi-csi2.h | 1 +
2 files changed, 12 insertions(+), 5 deletions(-)
diff --git a/drivers/phy/qualcomm/phy-qcom-mipi-csi2-3ph-dphy.c b/drivers/phy/qualcomm/phy-qcom-mipi-csi2-3ph-dphy.c
index 966d79c98f9b..8cd331cfb4b3 100644
--- a/drivers/phy/qualcomm/phy-qcom-mipi-csi2-3ph-dphy.c
+++ b/drivers/phy/qualcomm/phy-qcom-mipi-csi2-3ph-dphy.c
@@ -19,7 +19,8 @@
#define CSIPHY_3PH_CMN_CSI_COMMON_CTRL6_COMMON_PWRDN_B BIT(0)
#define CSIPHY_3PH_CMN_CSI_COMMON_CTRL6_SHOW_REV_ID BIT(1)
#define CSIPHY_3PH_CMN_CSI_COMMON_CTRL10_IRQ_CLEAR_CMD BIT(0)
-#define CSIPHY_3PH_CMN_CSI_COMMON_STATUSn(offset, n) ((offset) + 0xb0 + 0x4 * (n))
+#define CSIPHY_3PH_CMN_CSI_COMMON_STATUSn(offset, common_status_offset, n) \
+ ((offset) + (common_status_offset) + 0x4 * (n))
#define CSIPHY_2PH_LN_CSI_2PHASE_CTRL9n(n) ((0x200 * (n)) + 0x24)
@@ -176,19 +177,23 @@ static void phy_qcom_mipi_csi2_hw_version_read(struct mipi_csi2phy_device *csi2p
CSIPHY_3PH_CMN_CSI_COMMON_CTRLn(regs->common_regs_offset, 6));
tmp = readl_relaxed(csi2phy->base +
- CSIPHY_3PH_CMN_CSI_COMMON_STATUSn(regs->common_regs_offset, 12));
+ CSIPHY_3PH_CMN_CSI_COMMON_STATUSn(regs->common_regs_offset,
+ regs->common_status_offset, 12));
csi2phy->hw_version = tmp;
tmp = readl_relaxed(csi2phy->base +
- CSIPHY_3PH_CMN_CSI_COMMON_STATUSn(regs->common_regs_offset, 13));
+ CSIPHY_3PH_CMN_CSI_COMMON_STATUSn(regs->common_regs_offset,
+ regs->common_status_offset, 13));
csi2phy->hw_version |= (tmp << 8) & 0xFF00;
tmp = readl_relaxed(csi2phy->base +
- CSIPHY_3PH_CMN_CSI_COMMON_STATUSn(regs->common_regs_offset, 14));
+ CSIPHY_3PH_CMN_CSI_COMMON_STATUSn(regs->common_regs_offset,
+ regs->common_status_offset, 14));
csi2phy->hw_version |= (tmp << 16) & 0xFF0000;
tmp = readl_relaxed(csi2phy->base +
- CSIPHY_3PH_CMN_CSI_COMMON_STATUSn(regs->common_regs_offset, 15));
+ CSIPHY_3PH_CMN_CSI_COMMON_STATUSn(regs->common_regs_offset,
+ regs->common_status_offset, 15));
csi2phy->hw_version |= (tmp << 24) & 0xFF000000;
dev_dbg_once(csi2phy->dev, "CSIPHY 3PH HW Version = 0x%08x\n", csi2phy->hw_version);
@@ -375,6 +380,7 @@ const struct mipi_csi2phy_soc_cfg mipi_csi2_dphy_4nm_x1e = {
.init_seq = lane_regs_x1e80100,
.lane_array_size = ARRAY_SIZE(lane_regs_x1e80100),
.common_regs_offset = 0x1000,
+ .common_status_offset = 0xb0,
},
.supply_names = (const char **)x1e_supplies,
.num_supplies = ARRAY_SIZE(x1e_supplies),
diff --git a/drivers/phy/qualcomm/phy-qcom-mipi-csi2.h b/drivers/phy/qualcomm/phy-qcom-mipi-csi2.h
index 7e55ae007370..d6366f809e51 100644
--- a/drivers/phy/qualcomm/phy-qcom-mipi-csi2.h
+++ b/drivers/phy/qualcomm/phy-qcom-mipi-csi2.h
@@ -51,6 +51,7 @@ struct mipi_csi2phy_device_regs {
const struct mipi_csi2phy_lane_regs *init_seq;
const int lane_array_size;
const u32 common_regs_offset;
+ const u32 common_status_offset;
};
struct mipi_csi2_genpd {
--
2.34.1
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply related [flat|nested] 58+ messages in thread
* [PATCH v17 05/11] media: qcom: camss: csiphy: Add support for v2.4.0 two-phase CSIPHY
2026-09-29 6:00 ` Hangxiang Ma
@ 2026-09-29 6:00 ` Hangxiang Ma
-1 siblings, 0 replies; 58+ messages in thread
From: Hangxiang Ma @ 2026-09-29 6:00 UTC (permalink / raw)
To: Bryan O'Donoghue, Vinod Koul, Neil Armstrong,
Manivannan Sadhasivam, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Bryan O'Donoghue, Vladimir Zapolskiy,
Loic Poulain, Mauro Carvalho Chehab, Bjorn Andersson,
Konrad Dybcio, Abel Vesa
Cc: linux-phy, linux-media, linux-arm-msm, devicetree, linux-kernel,
jeyaprakash.soundrapandian, Vijay Kumar Tumati, Hangxiang Ma
Add support for the v2.4.0 two-phase CSIPHY found on Kaanapali, where
the PHY is driven by the standalone phy-qcom-mipi-csi2 DPHY driver
rather than by CAMSS. Add the mipi_csi2_dphy_3nm_kaanapali configuration,
which reuses the x1e80100 lane sequence, clocks and supplies but selects
the v2.4.0 common status offset, adding Kaanapali power domain and
register the "qcom,kaanapali-csi2-phy" compatible.
Signed-off-by: Hangxiang Ma <hangxiang.ma@oss.qualcomm.com>
---
drivers/media/platform/qcom/camss/camss.c | 53 ++++++++++++++++++++++
drivers/phy/qualcomm/phy-qcom-mipi-csi2-3ph-dphy.c | 16 +++++++
drivers/phy/qualcomm/phy-qcom-mipi-csi2-core.c | 1 +
drivers/phy/qualcomm/phy-qcom-mipi-csi2.h | 1 +
4 files changed, 71 insertions(+)
diff --git a/drivers/media/platform/qcom/camss/camss.c b/drivers/media/platform/qcom/camss/camss.c
index a528760487bd..a0cd839c9948 100644
--- a/drivers/media/platform/qcom/camss/camss.c
+++ b/drivers/media/platform/qcom/camss/camss.c
@@ -34,6 +34,57 @@
static const struct parent_dev_ops vfe_parent_dev_ops;
+static const struct camss_subdev_resources csiphy_res_kaanapali[] = {
+ /* CSIPHY0 */
+ {
+ .csiphy = {
+ .id = 0,
+ .hw_ops = &csiphy_ops_3ph_1_0,
+ .formats = &csiphy_formats_sdm845
+ },
+ },
+ /* CSIPHY1 */
+ {
+ .csiphy = {
+ .id = 1,
+ .hw_ops = &csiphy_ops_3ph_1_0,
+ .formats = &csiphy_formats_sdm845
+ },
+ },
+ /* CSIPHY2 */
+ {
+ .csiphy = {
+ .id = 2,
+ .hw_ops = &csiphy_ops_3ph_1_0,
+ .formats = &csiphy_formats_sdm845
+ },
+ },
+ /* CSIPHY3 */
+ {
+ .csiphy = {
+ .id = 3,
+ .hw_ops = &csiphy_ops_3ph_1_0,
+ .formats = &csiphy_formats_sdm845
+ },
+ },
+ /* CSIPHY4 */
+ {
+ .csiphy = {
+ .id = 4,
+ .hw_ops = &csiphy_ops_3ph_1_0,
+ .formats = &csiphy_formats_sdm845
+ },
+ },
+ /* CSIPHY5 */
+ {
+ .csiphy = {
+ .id = 5,
+ .hw_ops = &csiphy_ops_3ph_1_0,
+ .formats = &csiphy_formats_sdm845
+ },
+ },
+};
+
static const struct resources_icc icc_res_kaanapali[] = {
{
.name = "ahb",
@@ -5517,8 +5568,10 @@ static void camss_remove(struct platform_device *pdev)
static const struct camss_resources kaanapali_resources = {
.version = CAMSS_KAANAPALI,
.pd_name = "top",
+ .csiphy_res = csiphy_res_kaanapali,
.icc_res = icc_res_kaanapali,
.icc_path_num = ARRAY_SIZE(icc_res_kaanapali),
+ .csiphy_num = ARRAY_SIZE(csiphy_res_kaanapali),
};
static const struct camss_resources msm8916_resources = {
diff --git a/drivers/phy/qualcomm/phy-qcom-mipi-csi2-3ph-dphy.c b/drivers/phy/qualcomm/phy-qcom-mipi-csi2-3ph-dphy.c
index 8cd331cfb4b3..658a39463104 100644
--- a/drivers/phy/qualcomm/phy-qcom-mipi-csi2-3ph-dphy.c
+++ b/drivers/phy/qualcomm/phy-qcom-mipi-csi2-3ph-dphy.c
@@ -389,3 +389,19 @@ const struct mipi_csi2phy_soc_cfg mipi_csi2_dphy_4nm_x1e = {
.genpds = x1e_genpds,
.num_genpds = ARRAY_SIZE(x1e_genpds),
};
+
+const struct mipi_csi2phy_soc_cfg mipi_csi2_dphy_3nm_kaanapali = {
+ .ops = &phy_qcom_mipi_csi2_ops_3ph_1_0,
+ .reg_info = {
+ .init_seq = lane_regs_x1e80100,
+ .lane_array_size = ARRAY_SIZE(lane_regs_x1e80100),
+ .common_regs_offset = 0x1000,
+ .common_status_offset = 0x138,
+ },
+ .supply_names = (const char **)x1e_supplies,
+ .num_supplies = ARRAY_SIZE(x1e_supplies),
+ .clk_names = (const char **)x1e_clks,
+ .num_clk = ARRAY_SIZE(x1e_clks),
+ .genpds = x1e_genpds,
+ .num_genpds = ARRAY_SIZE(x1e_genpds),
+};
diff --git a/drivers/phy/qualcomm/phy-qcom-mipi-csi2-core.c b/drivers/phy/qualcomm/phy-qcom-mipi-csi2-core.c
index c0a4fa20eaf0..aff9e66f0352 100644
--- a/drivers/phy/qualcomm/phy-qcom-mipi-csi2-core.c
+++ b/drivers/phy/qualcomm/phy-qcom-mipi-csi2-core.c
@@ -444,6 +444,7 @@ static int phy_qcom_mipi_csi2_probe(struct platform_device *pdev)
static const struct of_device_id phy_qcom_mipi_csi2_of_match_table[] = {
{ .compatible = "qcom,x1e80100-csi2-phy", .data = &mipi_csi2_dphy_4nm_x1e },
+ { .compatible = "qcom,kaanapali-csi2-phy", .data = &mipi_csi2_dphy_3nm_kaanapali },
{ }
};
MODULE_DEVICE_TABLE(of, phy_qcom_mipi_csi2_of_match_table);
diff --git a/drivers/phy/qualcomm/phy-qcom-mipi-csi2.h b/drivers/phy/qualcomm/phy-qcom-mipi-csi2.h
index d6366f809e51..2355a1db9b94 100644
--- a/drivers/phy/qualcomm/phy-qcom-mipi-csi2.h
+++ b/drivers/phy/qualcomm/phy-qcom-mipi-csi2.h
@@ -94,5 +94,6 @@ struct mipi_csi2phy_device {
};
extern const struct mipi_csi2phy_soc_cfg mipi_csi2_dphy_4nm_x1e;
+extern const struct mipi_csi2phy_soc_cfg mipi_csi2_dphy_3nm_kaanapali;
#endif /* __PHY_QCOM_MIPI_CSI2_H__ */
--
2.34.1
^ permalink raw reply related [flat|nested] 58+ messages in thread
* [PATCH v17 05/11] media: qcom: camss: csiphy: Add support for v2.4.0 two-phase CSIPHY
@ 2026-09-29 6:00 ` Hangxiang Ma
0 siblings, 0 replies; 58+ messages in thread
From: Hangxiang Ma @ 2026-09-29 6:00 UTC (permalink / raw)
To: Bryan O'Donoghue, Vinod Koul, Neil Armstrong,
Manivannan Sadhasivam, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Bryan O'Donoghue, Vladimir Zapolskiy,
Loic Poulain, Mauro Carvalho Chehab, Bjorn Andersson,
Konrad Dybcio, Abel Vesa
Cc: linux-phy, linux-media, linux-arm-msm, devicetree, linux-kernel,
jeyaprakash.soundrapandian, Vijay Kumar Tumati, Hangxiang Ma
Add support for the v2.4.0 two-phase CSIPHY found on Kaanapali, where
the PHY is driven by the standalone phy-qcom-mipi-csi2 DPHY driver
rather than by CAMSS. Add the mipi_csi2_dphy_3nm_kaanapali configuration,
which reuses the x1e80100 lane sequence, clocks and supplies but selects
the v2.4.0 common status offset, adding Kaanapali power domain and
register the "qcom,kaanapali-csi2-phy" compatible.
Signed-off-by: Hangxiang Ma <hangxiang.ma@oss.qualcomm.com>
---
drivers/media/platform/qcom/camss/camss.c | 53 ++++++++++++++++++++++
drivers/phy/qualcomm/phy-qcom-mipi-csi2-3ph-dphy.c | 16 +++++++
drivers/phy/qualcomm/phy-qcom-mipi-csi2-core.c | 1 +
drivers/phy/qualcomm/phy-qcom-mipi-csi2.h | 1 +
4 files changed, 71 insertions(+)
diff --git a/drivers/media/platform/qcom/camss/camss.c b/drivers/media/platform/qcom/camss/camss.c
index a528760487bd..a0cd839c9948 100644
--- a/drivers/media/platform/qcom/camss/camss.c
+++ b/drivers/media/platform/qcom/camss/camss.c
@@ -34,6 +34,57 @@
static const struct parent_dev_ops vfe_parent_dev_ops;
+static const struct camss_subdev_resources csiphy_res_kaanapali[] = {
+ /* CSIPHY0 */
+ {
+ .csiphy = {
+ .id = 0,
+ .hw_ops = &csiphy_ops_3ph_1_0,
+ .formats = &csiphy_formats_sdm845
+ },
+ },
+ /* CSIPHY1 */
+ {
+ .csiphy = {
+ .id = 1,
+ .hw_ops = &csiphy_ops_3ph_1_0,
+ .formats = &csiphy_formats_sdm845
+ },
+ },
+ /* CSIPHY2 */
+ {
+ .csiphy = {
+ .id = 2,
+ .hw_ops = &csiphy_ops_3ph_1_0,
+ .formats = &csiphy_formats_sdm845
+ },
+ },
+ /* CSIPHY3 */
+ {
+ .csiphy = {
+ .id = 3,
+ .hw_ops = &csiphy_ops_3ph_1_0,
+ .formats = &csiphy_formats_sdm845
+ },
+ },
+ /* CSIPHY4 */
+ {
+ .csiphy = {
+ .id = 4,
+ .hw_ops = &csiphy_ops_3ph_1_0,
+ .formats = &csiphy_formats_sdm845
+ },
+ },
+ /* CSIPHY5 */
+ {
+ .csiphy = {
+ .id = 5,
+ .hw_ops = &csiphy_ops_3ph_1_0,
+ .formats = &csiphy_formats_sdm845
+ },
+ },
+};
+
static const struct resources_icc icc_res_kaanapali[] = {
{
.name = "ahb",
@@ -5517,8 +5568,10 @@ static void camss_remove(struct platform_device *pdev)
static const struct camss_resources kaanapali_resources = {
.version = CAMSS_KAANAPALI,
.pd_name = "top",
+ .csiphy_res = csiphy_res_kaanapali,
.icc_res = icc_res_kaanapali,
.icc_path_num = ARRAY_SIZE(icc_res_kaanapali),
+ .csiphy_num = ARRAY_SIZE(csiphy_res_kaanapali),
};
static const struct camss_resources msm8916_resources = {
diff --git a/drivers/phy/qualcomm/phy-qcom-mipi-csi2-3ph-dphy.c b/drivers/phy/qualcomm/phy-qcom-mipi-csi2-3ph-dphy.c
index 8cd331cfb4b3..658a39463104 100644
--- a/drivers/phy/qualcomm/phy-qcom-mipi-csi2-3ph-dphy.c
+++ b/drivers/phy/qualcomm/phy-qcom-mipi-csi2-3ph-dphy.c
@@ -389,3 +389,19 @@ const struct mipi_csi2phy_soc_cfg mipi_csi2_dphy_4nm_x1e = {
.genpds = x1e_genpds,
.num_genpds = ARRAY_SIZE(x1e_genpds),
};
+
+const struct mipi_csi2phy_soc_cfg mipi_csi2_dphy_3nm_kaanapali = {
+ .ops = &phy_qcom_mipi_csi2_ops_3ph_1_0,
+ .reg_info = {
+ .init_seq = lane_regs_x1e80100,
+ .lane_array_size = ARRAY_SIZE(lane_regs_x1e80100),
+ .common_regs_offset = 0x1000,
+ .common_status_offset = 0x138,
+ },
+ .supply_names = (const char **)x1e_supplies,
+ .num_supplies = ARRAY_SIZE(x1e_supplies),
+ .clk_names = (const char **)x1e_clks,
+ .num_clk = ARRAY_SIZE(x1e_clks),
+ .genpds = x1e_genpds,
+ .num_genpds = ARRAY_SIZE(x1e_genpds),
+};
diff --git a/drivers/phy/qualcomm/phy-qcom-mipi-csi2-core.c b/drivers/phy/qualcomm/phy-qcom-mipi-csi2-core.c
index c0a4fa20eaf0..aff9e66f0352 100644
--- a/drivers/phy/qualcomm/phy-qcom-mipi-csi2-core.c
+++ b/drivers/phy/qualcomm/phy-qcom-mipi-csi2-core.c
@@ -444,6 +444,7 @@ static int phy_qcom_mipi_csi2_probe(struct platform_device *pdev)
static const struct of_device_id phy_qcom_mipi_csi2_of_match_table[] = {
{ .compatible = "qcom,x1e80100-csi2-phy", .data = &mipi_csi2_dphy_4nm_x1e },
+ { .compatible = "qcom,kaanapali-csi2-phy", .data = &mipi_csi2_dphy_3nm_kaanapali },
{ }
};
MODULE_DEVICE_TABLE(of, phy_qcom_mipi_csi2_of_match_table);
diff --git a/drivers/phy/qualcomm/phy-qcom-mipi-csi2.h b/drivers/phy/qualcomm/phy-qcom-mipi-csi2.h
index d6366f809e51..2355a1db9b94 100644
--- a/drivers/phy/qualcomm/phy-qcom-mipi-csi2.h
+++ b/drivers/phy/qualcomm/phy-qcom-mipi-csi2.h
@@ -94,5 +94,6 @@ struct mipi_csi2phy_device {
};
extern const struct mipi_csi2phy_soc_cfg mipi_csi2_dphy_4nm_x1e;
+extern const struct mipi_csi2phy_soc_cfg mipi_csi2_dphy_3nm_kaanapali;
#endif /* __PHY_QCOM_MIPI_CSI2_H__ */
--
2.34.1
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply related [flat|nested] 58+ messages in thread
* [PATCH v17 06/11] media: qcom: camss: csid: Add support for CSID Gen4
2026-09-29 6:00 ` Hangxiang Ma
@ 2026-09-29 6:00 ` Hangxiang Ma
-1 siblings, 0 replies; 58+ messages in thread
From: Hangxiang Ma @ 2026-09-29 6:00 UTC (permalink / raw)
To: Bryan O'Donoghue, Vinod Koul, Neil Armstrong,
Manivannan Sadhasivam, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Bryan O'Donoghue, Vladimir Zapolskiy,
Loic Poulain, Mauro Carvalho Chehab, Bjorn Andersson,
Konrad Dybcio, Abel Vesa
Cc: linux-phy, linux-media, linux-arm-msm, devicetree, linux-kernel,
jeyaprakash.soundrapandian, Vijay Kumar Tumati, Hangxiang Ma,
Atiya Kailany
Add support for the CSID Gen4 hardware found on Kaanapali SoC.
Introduce Gen4 resource descriptions and implement the hardware-specific
register programming, reset sequence, and BUF_DONE interrupt handling.
Gen4 splits RUP and AUP updates into separate registers and uses a SET
register to commit the updates. Update the CSID interface to support
both this scheme and the legacy combined reg_update mechanism.
Reviewed-by: Bryan O'Donoghue <bod@kernel.org>
Co-developed-by: Atiya Kailany <atiya.kailany@oss.qualcomm.com>
Signed-off-by: Atiya Kailany <atiya.kailany@oss.qualcomm.com>
Signed-off-by: Hangxiang Ma <hangxiang.ma@oss.qualcomm.com>
---
drivers/media/platform/qcom/camss/Makefile | 1 +
.../media/platform/qcom/camss/camss-csid-gen4.c | 380 +++++++++++++++++++++
drivers/media/platform/qcom/camss/camss-csid.h | 9 +-
drivers/media/platform/qcom/camss/camss.c | 75 ++++
4 files changed, 464 insertions(+), 1 deletion(-)
diff --git a/drivers/media/platform/qcom/camss/Makefile b/drivers/media/platform/qcom/camss/Makefile
index 27898b3cc7d3..cebfd947f28e 100644
--- a/drivers/media/platform/qcom/camss/Makefile
+++ b/drivers/media/platform/qcom/camss/Makefile
@@ -10,6 +10,7 @@ qcom-camss-objs += \
camss-csid-680.o \
camss-csid-gen2.o \
camss-csid-gen3.o \
+ camss-csid-gen4.o \
camss-csiphy.o \
camss-csiphy-2ph-1-0.o \
camss-csiphy-3ph-1-0.o \
diff --git a/drivers/media/platform/qcom/camss/camss-csid-gen4.c b/drivers/media/platform/qcom/camss/camss-csid-gen4.c
new file mode 100644
index 000000000000..4ff2f41f70f7
--- /dev/null
+++ b/drivers/media/platform/qcom/camss/camss-csid-gen4.c
@@ -0,0 +1,380 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * camss-csid-gen4.c
+ *
+ * Qualcomm MSM Camera Subsystem - CSID (CSI Decoder) Module
+ *
+ * Copyright (c) Qualcomm Technologies, Inc. and/or its subsidiaries.
+ */
+#include <linux/completion.h>
+#include <linux/delay.h>
+#include <linux/interrupt.h>
+#include <linux/io.h>
+#include <linux/kernel.h>
+#include <linux/of.h>
+
+#include "camss.h"
+#include "camss-csid.h"
+#include "camss-csid-gen3.h"
+
+/* Reset and Command Registers */
+#define CSID_RST_CFG 0x108
+#define RST_MODE BIT(0)
+#define RST_LOCATION BIT(4)
+
+/* Reset and Command Registers */
+#define CSID_RST_CMD 0x10C
+#define SELECT_HW_RST BIT(0)
+#define SELECT_IRQ_RST BIT(2)
+#define CSID_IRQ_CMD 0x110
+#define IRQ_CMD_CLEAR BIT(0)
+
+/* Register Update Commands, RUP/AUP */
+#define CSID_RUP_CMD 0x114
+#define CSID_AUP_CMD 0x118
+#define CSID_RUP_AUP_RDI(rdi) (BIT(8) << (rdi))
+#define CSID_RUP_AUP_CMD 0x11C
+#define RUP_SET BIT(0)
+#define MUP BIT(4)
+
+/* Top level interrupt registers */
+#define CSID_TOP_IRQ_STATUS 0x180
+#define CSID_TOP_IRQ_MASK 0x184
+#define CSID_TOP_IRQ_CLEAR 0x188
+#define INFO_RST_DONE BIT(0)
+#define CSI2_RX_IRQ_STATUS BIT(2)
+#define BUF_DONE_IRQ_STATUS BIT(3)
+
+/* Buffer done interrupt registers */
+#define CSID_BUF_DONE_IRQ_STATUS 0x1A0
+#define BUF_DONE_IRQ_STATUS_RDI_OFFSET 16
+#define CSID_BUF_DONE_IRQ_MASK 0x1A4
+#define CSID_BUF_DONE_IRQ_CLEAR 0x1A8
+#define CSID_BUF_DONE_IRQ_SET 0x1AC
+
+/* CSI2 RX interrupt registers */
+#define CSID_CSI2_RX_IRQ_STATUS 0x1B0
+#define CSID_CSI2_RX_IRQ_MASK 0x1B4
+#define CSID_CSI2_RX_IRQ_CLEAR 0x1B8
+#define CSID_CSI2_RX_IRQ_SET 0x1BC
+
+/* CSI2 RX Configuration */
+#define CSID_CSI2_RX_CFG0 0x880
+#define CSI2_RX_CFG0_NUM_ACTIVE_LANES 0
+#define CSI2_RX_CFG0_DL0_INPUT_SEL 4
+#define CSI2_RX_CFG0_PHY_NUM_SEL 20
+#define CSI2_RX_CFG0_PHY_SEL_BASE_IDX 1
+#define CSID_CSI2_RX_CFG1 0x884
+#define CSI2_RX_CFG1_ECC_CORRECTION_EN BIT(0)
+#define CSI2_RX_CFG1_VC_MODE BIT(2)
+
+#define MSM_CSID_MAX_SRC_STREAMS_GEN4 (csid_is_lite(csid) ? 4 : 5)
+
+/* RDI Configuration */
+#define CSID_RDI_CFG0(rdi) (csid_is_lite(csid) ?\
+ (0x3080 + 0x200 * (rdi)) :\
+ (0x5480 + 0x200 * (rdi)))
+#define RDI_CFG0_RETIME_BS BIT(5)
+#define RDI_CFG0_TIMESTAMP_EN BIT(6)
+#define RDI_CFG0_TIMESTAMP_STB_SEL BIT(8)
+#define RDI_CFG0_DECODE_FORMAT 12
+#define RDI_CFG0_DT 16
+#define RDI_CFG0_VC 22
+#define RDI_CFG0_EN BIT(31)
+
+/* RDI Control and Configuration */
+#define CSID_RDI_CTRL(rdi) (csid_is_lite(csid) ?\
+ (0x3088 + 0x200 * (rdi)) :\
+ (0x5488 + 0x200 * (rdi)))
+#define RDI_CTRL_START_CMD BIT(0)
+
+#define CSID_RDI_CFG1(rdi) (csid_is_lite(csid) ?\
+ (0x3094 + 0x200 * (rdi)) :\
+ (0x5494 + 0x200 * (rdi)))
+#define RDI_CFG1_DROP_H_EN BIT(5)
+#define RDI_CFG1_DROP_V_EN BIT(6)
+#define RDI_CFG1_CROP_H_EN BIT(7)
+#define RDI_CFG1_CROP_V_EN BIT(8)
+#define RDI_CFG1_PACKING_FORMAT_MIPI BIT(15)
+
+/* RDI Pixel Store Configuration */
+#define CSID_RDI_PIX_STORE_CFG0(rdi) (0x5498 + 0x200 * (rdi))
+#define RDI_PIX_STORE_CFG0_EN BIT(0)
+#define RDI_PIX_STORE_CFG0_MIN_HBI 1
+
+/* RDI IRQ Status in wrapper */
+#define CSID_CSI2_RDIN_IRQ_STATUS(rdi) (0x224 + (0x10 * (rdi)))
+#define CSID_CSI2_RDIN_IRQ_MASK(rdi) (0x228 + (0x10 * (rdi)))
+#define CSID_CSI2_RDIN_IRQ_CLEAR(rdi) (0x22C + (0x10 * (rdi)))
+#define INFO_RUP_DONE BIT(23)
+
+static void __csid_aup_rup_trigger(struct csid_device *csid)
+{
+ /* trigger SET in combined register */
+ writel(RUP_SET, csid->base + CSID_RUP_AUP_CMD);
+}
+
+static void __csid_aup_rup_clear(struct csid_device *csid, int port_id)
+{
+ /* Hardware clears the registers upon consuming the settings */
+ csid->aup_update &= ~CSID_RUP_AUP_RDI(port_id);
+ csid->rup_update &= ~CSID_RUP_AUP_RDI(port_id);
+}
+
+static void __csid_aup_update(struct csid_device *csid, int port_id)
+{
+ csid->aup_update |= CSID_RUP_AUP_RDI(port_id);
+ writel(csid->aup_update, csid->base + CSID_AUP_CMD);
+
+ __csid_aup_rup_trigger(csid);
+}
+
+static void __csid_reg_update(struct csid_device *csid, int port_id)
+{
+ csid->rup_update |= CSID_RUP_AUP_RDI(port_id);
+ writel(csid->rup_update, csid->base + CSID_RUP_CMD);
+
+ __csid_aup_rup_trigger(csid);
+}
+
+static void __csid_configure_rx(struct csid_device *csid,
+ struct csid_phy_config *phy)
+{
+ int val;
+
+ val = (phy->lane_cnt - 1) << CSI2_RX_CFG0_NUM_ACTIVE_LANES;
+ val |= phy->lane_assign << CSI2_RX_CFG0_DL0_INPUT_SEL;
+ val |= (phy->csiphy_id + CSI2_RX_CFG0_PHY_SEL_BASE_IDX)
+ << CSI2_RX_CFG0_PHY_NUM_SEL;
+ writel(val, csid->base + CSID_CSI2_RX_CFG0);
+
+ val = CSI2_RX_CFG1_ECC_CORRECTION_EN;
+ writel(val, csid->base + CSID_CSI2_RX_CFG1);
+}
+
+static void __csid_configure_rx_vc(struct csid_device *csid, int vc)
+{
+ int val;
+
+ if (vc > 3) {
+ val = readl(csid->base + CSID_CSI2_RX_CFG1);
+ val |= CSI2_RX_CFG1_VC_MODE;
+ writel(val, csid->base + CSID_CSI2_RX_CFG1);
+ }
+}
+
+static void __csid_ctrl_rdi(struct csid_device *csid, int enable, u8 rdi)
+{
+ int val = 0;
+
+ if (enable)
+ val = RDI_CTRL_START_CMD;
+
+ writel(val, csid->base + CSID_RDI_CTRL(rdi));
+}
+
+static void __csid_configure_rdi_pix_store(struct csid_device *csid, u8 rdi)
+{
+ u32 val;
+
+ /*
+ * Configure pixel store to allow absorption of hblanking or idle time.
+ * This helps with horizontal crop and prevents line buffer conflicts.
+ * Reset state is 0x8 which has MIN_HBI=4, we keep the default MIN_HBI
+ * and just enable the pixel store functionality.
+ */
+ val = (4 << RDI_PIX_STORE_CFG0_MIN_HBI) | RDI_PIX_STORE_CFG0_EN;
+ writel(val, csid->base + CSID_RDI_PIX_STORE_CFG0(rdi));
+}
+
+static void __csid_configure_rdi_stream(struct csid_device *csid, u8 enable, u8 port, u8 vc)
+{
+ u8 lane_cnt = csid->phy.lane_cnt;
+ u32 val;
+
+ /* Source pads matching RDI channels on hardware.
+ * E.g. Pad 1 -> RDI0, Pad 2 -> RDI1, etc.
+ */
+ struct v4l2_mbus_framefmt *input_format = &csid->fmt[MSM_CSID_PAD_FIRST_SRC + port];
+ const struct csid_format_info *format = csid_get_fmt_entry(csid->res->formats->formats,
+ csid->res->formats->nformats,
+ input_format->code);
+
+ if (!lane_cnt)
+ lane_cnt = 4;
+
+ val = RDI_CFG0_TIMESTAMP_EN;
+ val |= RDI_CFG0_TIMESTAMP_STB_SEL;
+ val |= RDI_CFG0_RETIME_BS;
+
+ /* note: for non-RDI path, this should be format->decode_format */
+ val |= DECODE_FORMAT_PAYLOAD_ONLY << RDI_CFG0_DECODE_FORMAT;
+ val |= vc << RDI_CFG0_VC;
+ val |= format->data_type << RDI_CFG0_DT;
+ writel(val, csid->base + CSID_RDI_CFG0(port));
+
+ val = RDI_CFG1_PACKING_FORMAT_MIPI;
+ writel(val, csid->base + CSID_RDI_CFG1(port));
+
+ /* Configure pixel store using dedicated register in gen4 */
+ if (!csid_is_lite(csid))
+ __csid_configure_rdi_pix_store(csid, port);
+
+ val = 0;
+ writel(val, csid->base + CSID_RDI_CTRL(port));
+
+ val = readl(csid->base + CSID_RDI_CFG0(port));
+
+ if (enable)
+ val |= RDI_CFG0_EN;
+
+ writel(val, csid->base + CSID_RDI_CFG0(port));
+}
+
+static void csid_configure_stream(struct csid_device *csid, u8 enable)
+{
+ u8 i, k;
+
+ __csid_configure_rx(csid, &csid->phy);
+
+ for (i = 0; i < MSM_CSID_MAX_SRC_STREAMS_GEN4; i++) {
+ if (csid->phy.en_vc & BIT(i)) {
+ __csid_configure_rdi_stream(csid, enable, i, 0);
+ __csid_configure_rx_vc(csid, 0);
+
+ for (k = 0; k < CAMSS_INIT_BUF_COUNT; k++)
+ __csid_aup_update(csid, i);
+
+ __csid_reg_update(csid, i);
+
+ __csid_ctrl_rdi(csid, enable, i);
+ }
+ }
+}
+
+static int csid_configure_testgen_pattern(struct csid_device *csid, s32 val)
+{
+ return 0;
+}
+
+static void csid_subdev_reg_update(struct csid_device *csid, int port_id,
+ bool clear)
+{
+ if (clear)
+ __csid_aup_rup_clear(csid, port_id);
+ else
+ __csid_aup_update(csid, port_id);
+}
+
+/**
+ * csid_isr - CSID module interrupt service routine
+ * @irq: Interrupt line
+ * @dev: CSID device
+ *
+ * Return IRQ_HANDLED on success
+ */
+static irqreturn_t csid_isr(int irq, void *dev)
+{
+ struct csid_device *csid = dev;
+ u32 val, buf_done_val;
+ u8 reset_done;
+ int i;
+
+ val = readl(csid->base + CSID_TOP_IRQ_STATUS);
+ writel(val, csid->base + CSID_TOP_IRQ_CLEAR);
+
+ reset_done = val & INFO_RST_DONE;
+
+ buf_done_val = readl(csid->base + CSID_BUF_DONE_IRQ_STATUS);
+ writel(buf_done_val, csid->base + CSID_BUF_DONE_IRQ_CLEAR);
+
+ for (i = 0; i < MSM_CSID_MAX_SRC_STREAMS_GEN4; i++) {
+ if (csid->phy.en_vc & BIT(i)) {
+ val = readl(csid->base + CSID_CSI2_RDIN_IRQ_STATUS(i));
+ writel(val, csid->base + CSID_CSI2_RDIN_IRQ_CLEAR(i));
+
+ if (val & INFO_RUP_DONE)
+ csid_subdev_reg_update(csid, i, true);
+
+ if (buf_done_val & BIT(BUF_DONE_IRQ_STATUS_RDI_OFFSET + i))
+ camss_buf_done(csid->camss, csid->id, i);
+ }
+ }
+
+ val = IRQ_CMD_CLEAR;
+ writel(val, csid->base + CSID_IRQ_CMD);
+
+ if (reset_done)
+ complete(&csid->reset_complete);
+
+ return IRQ_HANDLED;
+}
+
+/**
+ * csid_reset - Trigger reset on CSID module and wait to complete
+ * @csid: CSID device
+ *
+ * Return 0 on success or a negative error code otherwise
+ */
+static int csid_reset(struct csid_device *csid)
+{
+ unsigned long time;
+ u32 val;
+ int i;
+
+ reinit_completion(&csid->reset_complete);
+
+ val = INFO_RST_DONE | BUF_DONE_IRQ_STATUS;
+ writel(val, csid->base + CSID_TOP_IRQ_CLEAR);
+ writel(val, csid->base + CSID_TOP_IRQ_MASK);
+
+ val = 0;
+ for (i = 0; i < MSM_CSID_MAX_SRC_STREAMS_GEN4; i++) {
+ if (csid->phy.en_vc & BIT(i)) {
+ /*
+ * Only need to clear buf done IRQ status here,
+ * RUP done IRQ status will be cleared once isr
+ * strobe generated by CSID_RST_CMD
+ */
+ val |= BIT(BUF_DONE_IRQ_STATUS_RDI_OFFSET + i);
+ }
+ }
+ writel(val, csid->base + CSID_BUF_DONE_IRQ_CLEAR);
+ writel(val, csid->base + CSID_BUF_DONE_IRQ_MASK);
+
+ /* Clear all IRQ status with CLEAR bits set */
+ val = IRQ_CMD_CLEAR;
+ writel(val, csid->base + CSID_IRQ_CMD);
+
+ val = RST_LOCATION | RST_MODE;
+ writel(val, csid->base + CSID_RST_CFG);
+
+ val = SELECT_HW_RST | SELECT_IRQ_RST;
+ writel(val, csid->base + CSID_RST_CMD);
+
+ time = wait_for_completion_timeout(&csid->reset_complete,
+ msecs_to_jiffies(CSID_RESET_TIMEOUT_MS));
+
+ if (!time) {
+ dev_err(csid->camss->dev, "CSID reset timeout\n");
+ return -EIO;
+ }
+
+ return 0;
+}
+
+static void csid_subdev_init(struct csid_device *csid)
+{
+ csid->testgen.nmodes = CSID_PAYLOAD_MODE_DISABLED;
+}
+
+const struct csid_hw_ops csid_ops_gen4 = {
+ .configure_stream = csid_configure_stream,
+ .configure_testgen_pattern = csid_configure_testgen_pattern,
+ .hw_version = csid_hw_version,
+ .isr = csid_isr,
+ .reset = csid_reset,
+ .src_pad_code = csid_src_pad_code,
+ .subdev_init = csid_subdev_init,
+ .reg_update = csid_subdev_reg_update,
+};
diff --git a/drivers/media/platform/qcom/camss/camss-csid.h b/drivers/media/platform/qcom/camss/camss-csid.h
index 5296b10f6bac..4f31ad303c4e 100644
--- a/drivers/media/platform/qcom/camss/camss-csid.h
+++ b/drivers/media/platform/qcom/camss/camss-csid.h
@@ -154,7 +154,13 @@ struct csid_device {
void __iomem *base;
u32 irq;
char irq_name[30];
- u32 reg_update;
+ union {
+ u32 reg_update;
+ struct {
+ u32 rup_update;
+ u32 aup_update;
+ };
+ };
struct camss_clock *clock;
int nclocks;
struct regulator_bulk_data *supplies;
@@ -218,6 +224,7 @@ extern const struct csid_hw_ops csid_ops_340;
extern const struct csid_hw_ops csid_ops_680;
extern const struct csid_hw_ops csid_ops_gen2;
extern const struct csid_hw_ops csid_ops_gen3;
+extern const struct csid_hw_ops csid_ops_gen4;
/*
* csid_is_lite - Check if CSID is CSID lite.
diff --git a/drivers/media/platform/qcom/camss/camss.c b/drivers/media/platform/qcom/camss/camss.c
index a0cd839c9948..52cbbf424980 100644
--- a/drivers/media/platform/qcom/camss/camss.c
+++ b/drivers/media/platform/qcom/camss/camss.c
@@ -85,6 +85,79 @@ static const struct camss_subdev_resources csiphy_res_kaanapali[] = {
},
};
+static const struct camss_subdev_resources csid_res_kaanapali[] = {
+ /* CSID0 */
+ {
+ .clock = { "csid", "csid_csiphy_rx" },
+ .clock_rate = { { 400000000, 480000000 },
+ { 400000000, 480000000 } },
+ .reg = { "csid0" },
+ .interrupt = { "csid0" },
+ .csid = {
+ .is_lite = false,
+ .parent_dev_ops = &vfe_parent_dev_ops,
+ .hw_ops = &csid_ops_gen4,
+ .formats = &csid_formats_gen2
+ }
+ },
+ /* CSID1 */
+ {
+ .clock = { "csid", "csid_csiphy_rx" },
+ .clock_rate = { { 400000000, 480000000 },
+ { 400000000, 480000000 } },
+ .reg = { "csid1" },
+ .interrupt = { "csid1" },
+ .csid = {
+ .is_lite = false,
+ .parent_dev_ops = &vfe_parent_dev_ops,
+ .hw_ops = &csid_ops_gen4,
+ .formats = &csid_formats_gen2
+ }
+ },
+ /* CSID2 */
+ {
+ .clock = { "csid", "csid_csiphy_rx" },
+ .clock_rate = { { 400000000, 480000000 },
+ { 400000000, 480000000 } },
+ .reg = { "csid2" },
+ .interrupt = { "csid2" },
+ .csid = {
+ .is_lite = false,
+ .parent_dev_ops = &vfe_parent_dev_ops,
+ .hw_ops = &csid_ops_gen4,
+ .formats = &csid_formats_gen2
+ }
+ },
+ /* CSID_LITE0 */
+ {
+ .clock = { "vfe_lite_csid", "vfe_lite_cphy_rx" },
+ .clock_rate = { { 400000000, 480000000 },
+ { 400000000, 480000000 } },
+ .reg = { "csid_lite0" },
+ .interrupt = { "csid_lite0" },
+ .csid = {
+ .is_lite = true,
+ .parent_dev_ops = &vfe_parent_dev_ops,
+ .hw_ops = &csid_ops_gen4,
+ .formats = &csid_formats_gen2
+ }
+ },
+ /* CSID_LITE1 */
+ {
+ .clock = { "vfe_lite_csid", "vfe_lite_cphy_rx" },
+ .clock_rate = { { 400000000, 480000000 },
+ { 400000000, 480000000 } },
+ .reg = { "csid_lite1" },
+ .interrupt = { "csid_lite1" },
+ .csid = {
+ .is_lite = true,
+ .parent_dev_ops = &vfe_parent_dev_ops,
+ .hw_ops = &csid_ops_gen4,
+ .formats = &csid_formats_gen2
+ }
+ }
+};
+
static const struct resources_icc icc_res_kaanapali[] = {
{
.name = "ahb",
@@ -5569,9 +5642,11 @@ static const struct camss_resources kaanapali_resources = {
.version = CAMSS_KAANAPALI,
.pd_name = "top",
.csiphy_res = csiphy_res_kaanapali,
+ .csid_res = csid_res_kaanapali,
.icc_res = icc_res_kaanapali,
.icc_path_num = ARRAY_SIZE(icc_res_kaanapali),
.csiphy_num = ARRAY_SIZE(csiphy_res_kaanapali),
+ .csid_num = ARRAY_SIZE(csid_res_kaanapali),
};
static const struct camss_resources msm8916_resources = {
--
2.34.1
^ permalink raw reply related [flat|nested] 58+ messages in thread
* [PATCH v17 06/11] media: qcom: camss: csid: Add support for CSID Gen4
@ 2026-09-29 6:00 ` Hangxiang Ma
0 siblings, 0 replies; 58+ messages in thread
From: Hangxiang Ma @ 2026-09-29 6:00 UTC (permalink / raw)
To: Bryan O'Donoghue, Vinod Koul, Neil Armstrong,
Manivannan Sadhasivam, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Bryan O'Donoghue, Vladimir Zapolskiy,
Loic Poulain, Mauro Carvalho Chehab, Bjorn Andersson,
Konrad Dybcio, Abel Vesa
Cc: linux-phy, linux-media, linux-arm-msm, devicetree, linux-kernel,
jeyaprakash.soundrapandian, Vijay Kumar Tumati, Hangxiang Ma,
Atiya Kailany
Add support for the CSID Gen4 hardware found on Kaanapali SoC.
Introduce Gen4 resource descriptions and implement the hardware-specific
register programming, reset sequence, and BUF_DONE interrupt handling.
Gen4 splits RUP and AUP updates into separate registers and uses a SET
register to commit the updates. Update the CSID interface to support
both this scheme and the legacy combined reg_update mechanism.
Reviewed-by: Bryan O'Donoghue <bod@kernel.org>
Co-developed-by: Atiya Kailany <atiya.kailany@oss.qualcomm.com>
Signed-off-by: Atiya Kailany <atiya.kailany@oss.qualcomm.com>
Signed-off-by: Hangxiang Ma <hangxiang.ma@oss.qualcomm.com>
---
drivers/media/platform/qcom/camss/Makefile | 1 +
.../media/platform/qcom/camss/camss-csid-gen4.c | 380 +++++++++++++++++++++
drivers/media/platform/qcom/camss/camss-csid.h | 9 +-
drivers/media/platform/qcom/camss/camss.c | 75 ++++
4 files changed, 464 insertions(+), 1 deletion(-)
diff --git a/drivers/media/platform/qcom/camss/Makefile b/drivers/media/platform/qcom/camss/Makefile
index 27898b3cc7d3..cebfd947f28e 100644
--- a/drivers/media/platform/qcom/camss/Makefile
+++ b/drivers/media/platform/qcom/camss/Makefile
@@ -10,6 +10,7 @@ qcom-camss-objs += \
camss-csid-680.o \
camss-csid-gen2.o \
camss-csid-gen3.o \
+ camss-csid-gen4.o \
camss-csiphy.o \
camss-csiphy-2ph-1-0.o \
camss-csiphy-3ph-1-0.o \
diff --git a/drivers/media/platform/qcom/camss/camss-csid-gen4.c b/drivers/media/platform/qcom/camss/camss-csid-gen4.c
new file mode 100644
index 000000000000..4ff2f41f70f7
--- /dev/null
+++ b/drivers/media/platform/qcom/camss/camss-csid-gen4.c
@@ -0,0 +1,380 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * camss-csid-gen4.c
+ *
+ * Qualcomm MSM Camera Subsystem - CSID (CSI Decoder) Module
+ *
+ * Copyright (c) Qualcomm Technologies, Inc. and/or its subsidiaries.
+ */
+#include <linux/completion.h>
+#include <linux/delay.h>
+#include <linux/interrupt.h>
+#include <linux/io.h>
+#include <linux/kernel.h>
+#include <linux/of.h>
+
+#include "camss.h"
+#include "camss-csid.h"
+#include "camss-csid-gen3.h"
+
+/* Reset and Command Registers */
+#define CSID_RST_CFG 0x108
+#define RST_MODE BIT(0)
+#define RST_LOCATION BIT(4)
+
+/* Reset and Command Registers */
+#define CSID_RST_CMD 0x10C
+#define SELECT_HW_RST BIT(0)
+#define SELECT_IRQ_RST BIT(2)
+#define CSID_IRQ_CMD 0x110
+#define IRQ_CMD_CLEAR BIT(0)
+
+/* Register Update Commands, RUP/AUP */
+#define CSID_RUP_CMD 0x114
+#define CSID_AUP_CMD 0x118
+#define CSID_RUP_AUP_RDI(rdi) (BIT(8) << (rdi))
+#define CSID_RUP_AUP_CMD 0x11C
+#define RUP_SET BIT(0)
+#define MUP BIT(4)
+
+/* Top level interrupt registers */
+#define CSID_TOP_IRQ_STATUS 0x180
+#define CSID_TOP_IRQ_MASK 0x184
+#define CSID_TOP_IRQ_CLEAR 0x188
+#define INFO_RST_DONE BIT(0)
+#define CSI2_RX_IRQ_STATUS BIT(2)
+#define BUF_DONE_IRQ_STATUS BIT(3)
+
+/* Buffer done interrupt registers */
+#define CSID_BUF_DONE_IRQ_STATUS 0x1A0
+#define BUF_DONE_IRQ_STATUS_RDI_OFFSET 16
+#define CSID_BUF_DONE_IRQ_MASK 0x1A4
+#define CSID_BUF_DONE_IRQ_CLEAR 0x1A8
+#define CSID_BUF_DONE_IRQ_SET 0x1AC
+
+/* CSI2 RX interrupt registers */
+#define CSID_CSI2_RX_IRQ_STATUS 0x1B0
+#define CSID_CSI2_RX_IRQ_MASK 0x1B4
+#define CSID_CSI2_RX_IRQ_CLEAR 0x1B8
+#define CSID_CSI2_RX_IRQ_SET 0x1BC
+
+/* CSI2 RX Configuration */
+#define CSID_CSI2_RX_CFG0 0x880
+#define CSI2_RX_CFG0_NUM_ACTIVE_LANES 0
+#define CSI2_RX_CFG0_DL0_INPUT_SEL 4
+#define CSI2_RX_CFG0_PHY_NUM_SEL 20
+#define CSI2_RX_CFG0_PHY_SEL_BASE_IDX 1
+#define CSID_CSI2_RX_CFG1 0x884
+#define CSI2_RX_CFG1_ECC_CORRECTION_EN BIT(0)
+#define CSI2_RX_CFG1_VC_MODE BIT(2)
+
+#define MSM_CSID_MAX_SRC_STREAMS_GEN4 (csid_is_lite(csid) ? 4 : 5)
+
+/* RDI Configuration */
+#define CSID_RDI_CFG0(rdi) (csid_is_lite(csid) ?\
+ (0x3080 + 0x200 * (rdi)) :\
+ (0x5480 + 0x200 * (rdi)))
+#define RDI_CFG0_RETIME_BS BIT(5)
+#define RDI_CFG0_TIMESTAMP_EN BIT(6)
+#define RDI_CFG0_TIMESTAMP_STB_SEL BIT(8)
+#define RDI_CFG0_DECODE_FORMAT 12
+#define RDI_CFG0_DT 16
+#define RDI_CFG0_VC 22
+#define RDI_CFG0_EN BIT(31)
+
+/* RDI Control and Configuration */
+#define CSID_RDI_CTRL(rdi) (csid_is_lite(csid) ?\
+ (0x3088 + 0x200 * (rdi)) :\
+ (0x5488 + 0x200 * (rdi)))
+#define RDI_CTRL_START_CMD BIT(0)
+
+#define CSID_RDI_CFG1(rdi) (csid_is_lite(csid) ?\
+ (0x3094 + 0x200 * (rdi)) :\
+ (0x5494 + 0x200 * (rdi)))
+#define RDI_CFG1_DROP_H_EN BIT(5)
+#define RDI_CFG1_DROP_V_EN BIT(6)
+#define RDI_CFG1_CROP_H_EN BIT(7)
+#define RDI_CFG1_CROP_V_EN BIT(8)
+#define RDI_CFG1_PACKING_FORMAT_MIPI BIT(15)
+
+/* RDI Pixel Store Configuration */
+#define CSID_RDI_PIX_STORE_CFG0(rdi) (0x5498 + 0x200 * (rdi))
+#define RDI_PIX_STORE_CFG0_EN BIT(0)
+#define RDI_PIX_STORE_CFG0_MIN_HBI 1
+
+/* RDI IRQ Status in wrapper */
+#define CSID_CSI2_RDIN_IRQ_STATUS(rdi) (0x224 + (0x10 * (rdi)))
+#define CSID_CSI2_RDIN_IRQ_MASK(rdi) (0x228 + (0x10 * (rdi)))
+#define CSID_CSI2_RDIN_IRQ_CLEAR(rdi) (0x22C + (0x10 * (rdi)))
+#define INFO_RUP_DONE BIT(23)
+
+static void __csid_aup_rup_trigger(struct csid_device *csid)
+{
+ /* trigger SET in combined register */
+ writel(RUP_SET, csid->base + CSID_RUP_AUP_CMD);
+}
+
+static void __csid_aup_rup_clear(struct csid_device *csid, int port_id)
+{
+ /* Hardware clears the registers upon consuming the settings */
+ csid->aup_update &= ~CSID_RUP_AUP_RDI(port_id);
+ csid->rup_update &= ~CSID_RUP_AUP_RDI(port_id);
+}
+
+static void __csid_aup_update(struct csid_device *csid, int port_id)
+{
+ csid->aup_update |= CSID_RUP_AUP_RDI(port_id);
+ writel(csid->aup_update, csid->base + CSID_AUP_CMD);
+
+ __csid_aup_rup_trigger(csid);
+}
+
+static void __csid_reg_update(struct csid_device *csid, int port_id)
+{
+ csid->rup_update |= CSID_RUP_AUP_RDI(port_id);
+ writel(csid->rup_update, csid->base + CSID_RUP_CMD);
+
+ __csid_aup_rup_trigger(csid);
+}
+
+static void __csid_configure_rx(struct csid_device *csid,
+ struct csid_phy_config *phy)
+{
+ int val;
+
+ val = (phy->lane_cnt - 1) << CSI2_RX_CFG0_NUM_ACTIVE_LANES;
+ val |= phy->lane_assign << CSI2_RX_CFG0_DL0_INPUT_SEL;
+ val |= (phy->csiphy_id + CSI2_RX_CFG0_PHY_SEL_BASE_IDX)
+ << CSI2_RX_CFG0_PHY_NUM_SEL;
+ writel(val, csid->base + CSID_CSI2_RX_CFG0);
+
+ val = CSI2_RX_CFG1_ECC_CORRECTION_EN;
+ writel(val, csid->base + CSID_CSI2_RX_CFG1);
+}
+
+static void __csid_configure_rx_vc(struct csid_device *csid, int vc)
+{
+ int val;
+
+ if (vc > 3) {
+ val = readl(csid->base + CSID_CSI2_RX_CFG1);
+ val |= CSI2_RX_CFG1_VC_MODE;
+ writel(val, csid->base + CSID_CSI2_RX_CFG1);
+ }
+}
+
+static void __csid_ctrl_rdi(struct csid_device *csid, int enable, u8 rdi)
+{
+ int val = 0;
+
+ if (enable)
+ val = RDI_CTRL_START_CMD;
+
+ writel(val, csid->base + CSID_RDI_CTRL(rdi));
+}
+
+static void __csid_configure_rdi_pix_store(struct csid_device *csid, u8 rdi)
+{
+ u32 val;
+
+ /*
+ * Configure pixel store to allow absorption of hblanking or idle time.
+ * This helps with horizontal crop and prevents line buffer conflicts.
+ * Reset state is 0x8 which has MIN_HBI=4, we keep the default MIN_HBI
+ * and just enable the pixel store functionality.
+ */
+ val = (4 << RDI_PIX_STORE_CFG0_MIN_HBI) | RDI_PIX_STORE_CFG0_EN;
+ writel(val, csid->base + CSID_RDI_PIX_STORE_CFG0(rdi));
+}
+
+static void __csid_configure_rdi_stream(struct csid_device *csid, u8 enable, u8 port, u8 vc)
+{
+ u8 lane_cnt = csid->phy.lane_cnt;
+ u32 val;
+
+ /* Source pads matching RDI channels on hardware.
+ * E.g. Pad 1 -> RDI0, Pad 2 -> RDI1, etc.
+ */
+ struct v4l2_mbus_framefmt *input_format = &csid->fmt[MSM_CSID_PAD_FIRST_SRC + port];
+ const struct csid_format_info *format = csid_get_fmt_entry(csid->res->formats->formats,
+ csid->res->formats->nformats,
+ input_format->code);
+
+ if (!lane_cnt)
+ lane_cnt = 4;
+
+ val = RDI_CFG0_TIMESTAMP_EN;
+ val |= RDI_CFG0_TIMESTAMP_STB_SEL;
+ val |= RDI_CFG0_RETIME_BS;
+
+ /* note: for non-RDI path, this should be format->decode_format */
+ val |= DECODE_FORMAT_PAYLOAD_ONLY << RDI_CFG0_DECODE_FORMAT;
+ val |= vc << RDI_CFG0_VC;
+ val |= format->data_type << RDI_CFG0_DT;
+ writel(val, csid->base + CSID_RDI_CFG0(port));
+
+ val = RDI_CFG1_PACKING_FORMAT_MIPI;
+ writel(val, csid->base + CSID_RDI_CFG1(port));
+
+ /* Configure pixel store using dedicated register in gen4 */
+ if (!csid_is_lite(csid))
+ __csid_configure_rdi_pix_store(csid, port);
+
+ val = 0;
+ writel(val, csid->base + CSID_RDI_CTRL(port));
+
+ val = readl(csid->base + CSID_RDI_CFG0(port));
+
+ if (enable)
+ val |= RDI_CFG0_EN;
+
+ writel(val, csid->base + CSID_RDI_CFG0(port));
+}
+
+static void csid_configure_stream(struct csid_device *csid, u8 enable)
+{
+ u8 i, k;
+
+ __csid_configure_rx(csid, &csid->phy);
+
+ for (i = 0; i < MSM_CSID_MAX_SRC_STREAMS_GEN4; i++) {
+ if (csid->phy.en_vc & BIT(i)) {
+ __csid_configure_rdi_stream(csid, enable, i, 0);
+ __csid_configure_rx_vc(csid, 0);
+
+ for (k = 0; k < CAMSS_INIT_BUF_COUNT; k++)
+ __csid_aup_update(csid, i);
+
+ __csid_reg_update(csid, i);
+
+ __csid_ctrl_rdi(csid, enable, i);
+ }
+ }
+}
+
+static int csid_configure_testgen_pattern(struct csid_device *csid, s32 val)
+{
+ return 0;
+}
+
+static void csid_subdev_reg_update(struct csid_device *csid, int port_id,
+ bool clear)
+{
+ if (clear)
+ __csid_aup_rup_clear(csid, port_id);
+ else
+ __csid_aup_update(csid, port_id);
+}
+
+/**
+ * csid_isr - CSID module interrupt service routine
+ * @irq: Interrupt line
+ * @dev: CSID device
+ *
+ * Return IRQ_HANDLED on success
+ */
+static irqreturn_t csid_isr(int irq, void *dev)
+{
+ struct csid_device *csid = dev;
+ u32 val, buf_done_val;
+ u8 reset_done;
+ int i;
+
+ val = readl(csid->base + CSID_TOP_IRQ_STATUS);
+ writel(val, csid->base + CSID_TOP_IRQ_CLEAR);
+
+ reset_done = val & INFO_RST_DONE;
+
+ buf_done_val = readl(csid->base + CSID_BUF_DONE_IRQ_STATUS);
+ writel(buf_done_val, csid->base + CSID_BUF_DONE_IRQ_CLEAR);
+
+ for (i = 0; i < MSM_CSID_MAX_SRC_STREAMS_GEN4; i++) {
+ if (csid->phy.en_vc & BIT(i)) {
+ val = readl(csid->base + CSID_CSI2_RDIN_IRQ_STATUS(i));
+ writel(val, csid->base + CSID_CSI2_RDIN_IRQ_CLEAR(i));
+
+ if (val & INFO_RUP_DONE)
+ csid_subdev_reg_update(csid, i, true);
+
+ if (buf_done_val & BIT(BUF_DONE_IRQ_STATUS_RDI_OFFSET + i))
+ camss_buf_done(csid->camss, csid->id, i);
+ }
+ }
+
+ val = IRQ_CMD_CLEAR;
+ writel(val, csid->base + CSID_IRQ_CMD);
+
+ if (reset_done)
+ complete(&csid->reset_complete);
+
+ return IRQ_HANDLED;
+}
+
+/**
+ * csid_reset - Trigger reset on CSID module and wait to complete
+ * @csid: CSID device
+ *
+ * Return 0 on success or a negative error code otherwise
+ */
+static int csid_reset(struct csid_device *csid)
+{
+ unsigned long time;
+ u32 val;
+ int i;
+
+ reinit_completion(&csid->reset_complete);
+
+ val = INFO_RST_DONE | BUF_DONE_IRQ_STATUS;
+ writel(val, csid->base + CSID_TOP_IRQ_CLEAR);
+ writel(val, csid->base + CSID_TOP_IRQ_MASK);
+
+ val = 0;
+ for (i = 0; i < MSM_CSID_MAX_SRC_STREAMS_GEN4; i++) {
+ if (csid->phy.en_vc & BIT(i)) {
+ /*
+ * Only need to clear buf done IRQ status here,
+ * RUP done IRQ status will be cleared once isr
+ * strobe generated by CSID_RST_CMD
+ */
+ val |= BIT(BUF_DONE_IRQ_STATUS_RDI_OFFSET + i);
+ }
+ }
+ writel(val, csid->base + CSID_BUF_DONE_IRQ_CLEAR);
+ writel(val, csid->base + CSID_BUF_DONE_IRQ_MASK);
+
+ /* Clear all IRQ status with CLEAR bits set */
+ val = IRQ_CMD_CLEAR;
+ writel(val, csid->base + CSID_IRQ_CMD);
+
+ val = RST_LOCATION | RST_MODE;
+ writel(val, csid->base + CSID_RST_CFG);
+
+ val = SELECT_HW_RST | SELECT_IRQ_RST;
+ writel(val, csid->base + CSID_RST_CMD);
+
+ time = wait_for_completion_timeout(&csid->reset_complete,
+ msecs_to_jiffies(CSID_RESET_TIMEOUT_MS));
+
+ if (!time) {
+ dev_err(csid->camss->dev, "CSID reset timeout\n");
+ return -EIO;
+ }
+
+ return 0;
+}
+
+static void csid_subdev_init(struct csid_device *csid)
+{
+ csid->testgen.nmodes = CSID_PAYLOAD_MODE_DISABLED;
+}
+
+const struct csid_hw_ops csid_ops_gen4 = {
+ .configure_stream = csid_configure_stream,
+ .configure_testgen_pattern = csid_configure_testgen_pattern,
+ .hw_version = csid_hw_version,
+ .isr = csid_isr,
+ .reset = csid_reset,
+ .src_pad_code = csid_src_pad_code,
+ .subdev_init = csid_subdev_init,
+ .reg_update = csid_subdev_reg_update,
+};
diff --git a/drivers/media/platform/qcom/camss/camss-csid.h b/drivers/media/platform/qcom/camss/camss-csid.h
index 5296b10f6bac..4f31ad303c4e 100644
--- a/drivers/media/platform/qcom/camss/camss-csid.h
+++ b/drivers/media/platform/qcom/camss/camss-csid.h
@@ -154,7 +154,13 @@ struct csid_device {
void __iomem *base;
u32 irq;
char irq_name[30];
- u32 reg_update;
+ union {
+ u32 reg_update;
+ struct {
+ u32 rup_update;
+ u32 aup_update;
+ };
+ };
struct camss_clock *clock;
int nclocks;
struct regulator_bulk_data *supplies;
@@ -218,6 +224,7 @@ extern const struct csid_hw_ops csid_ops_340;
extern const struct csid_hw_ops csid_ops_680;
extern const struct csid_hw_ops csid_ops_gen2;
extern const struct csid_hw_ops csid_ops_gen3;
+extern const struct csid_hw_ops csid_ops_gen4;
/*
* csid_is_lite - Check if CSID is CSID lite.
diff --git a/drivers/media/platform/qcom/camss/camss.c b/drivers/media/platform/qcom/camss/camss.c
index a0cd839c9948..52cbbf424980 100644
--- a/drivers/media/platform/qcom/camss/camss.c
+++ b/drivers/media/platform/qcom/camss/camss.c
@@ -85,6 +85,79 @@ static const struct camss_subdev_resources csiphy_res_kaanapali[] = {
},
};
+static const struct camss_subdev_resources csid_res_kaanapali[] = {
+ /* CSID0 */
+ {
+ .clock = { "csid", "csid_csiphy_rx" },
+ .clock_rate = { { 400000000, 480000000 },
+ { 400000000, 480000000 } },
+ .reg = { "csid0" },
+ .interrupt = { "csid0" },
+ .csid = {
+ .is_lite = false,
+ .parent_dev_ops = &vfe_parent_dev_ops,
+ .hw_ops = &csid_ops_gen4,
+ .formats = &csid_formats_gen2
+ }
+ },
+ /* CSID1 */
+ {
+ .clock = { "csid", "csid_csiphy_rx" },
+ .clock_rate = { { 400000000, 480000000 },
+ { 400000000, 480000000 } },
+ .reg = { "csid1" },
+ .interrupt = { "csid1" },
+ .csid = {
+ .is_lite = false,
+ .parent_dev_ops = &vfe_parent_dev_ops,
+ .hw_ops = &csid_ops_gen4,
+ .formats = &csid_formats_gen2
+ }
+ },
+ /* CSID2 */
+ {
+ .clock = { "csid", "csid_csiphy_rx" },
+ .clock_rate = { { 400000000, 480000000 },
+ { 400000000, 480000000 } },
+ .reg = { "csid2" },
+ .interrupt = { "csid2" },
+ .csid = {
+ .is_lite = false,
+ .parent_dev_ops = &vfe_parent_dev_ops,
+ .hw_ops = &csid_ops_gen4,
+ .formats = &csid_formats_gen2
+ }
+ },
+ /* CSID_LITE0 */
+ {
+ .clock = { "vfe_lite_csid", "vfe_lite_cphy_rx" },
+ .clock_rate = { { 400000000, 480000000 },
+ { 400000000, 480000000 } },
+ .reg = { "csid_lite0" },
+ .interrupt = { "csid_lite0" },
+ .csid = {
+ .is_lite = true,
+ .parent_dev_ops = &vfe_parent_dev_ops,
+ .hw_ops = &csid_ops_gen4,
+ .formats = &csid_formats_gen2
+ }
+ },
+ /* CSID_LITE1 */
+ {
+ .clock = { "vfe_lite_csid", "vfe_lite_cphy_rx" },
+ .clock_rate = { { 400000000, 480000000 },
+ { 400000000, 480000000 } },
+ .reg = { "csid_lite1" },
+ .interrupt = { "csid_lite1" },
+ .csid = {
+ .is_lite = true,
+ .parent_dev_ops = &vfe_parent_dev_ops,
+ .hw_ops = &csid_ops_gen4,
+ .formats = &csid_formats_gen2
+ }
+ }
+};
+
static const struct resources_icc icc_res_kaanapali[] = {
{
.name = "ahb",
@@ -5569,9 +5642,11 @@ static const struct camss_resources kaanapali_resources = {
.version = CAMSS_KAANAPALI,
.pd_name = "top",
.csiphy_res = csiphy_res_kaanapali,
+ .csid_res = csid_res_kaanapali,
.icc_res = icc_res_kaanapali,
.icc_path_num = ARRAY_SIZE(icc_res_kaanapali),
.csiphy_num = ARRAY_SIZE(csiphy_res_kaanapali),
+ .csid_num = ARRAY_SIZE(csid_res_kaanapali),
};
static const struct camss_resources msm8916_resources = {
--
2.34.1
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply related [flat|nested] 58+ messages in thread
* [PATCH v17 07/11] media: qcom: camss: vfe: Add support for VFE Gen4
2026-09-29 6:00 ` Hangxiang Ma
@ 2026-09-29 6:00 ` Hangxiang Ma
-1 siblings, 0 replies; 58+ messages in thread
From: Hangxiang Ma @ 2026-09-29 6:00 UTC (permalink / raw)
To: Bryan O'Donoghue, Vinod Koul, Neil Armstrong,
Manivannan Sadhasivam, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Bryan O'Donoghue, Vladimir Zapolskiy,
Loic Poulain, Mauro Carvalho Chehab, Bjorn Andersson,
Konrad Dybcio, Abel Vesa
Cc: linux-phy, linux-media, linux-arm-msm, devicetree, linux-kernel,
jeyaprakash.soundrapandian, Vijay Kumar Tumati, Hangxiang Ma,
Atiya Kailany
Add support for the VFE (Video Front End) Gen4 found on Kaanapali SoC.
In the Kaanapali camera subsystem, the front-end blocks are referred to
as TFEs (Thin Front Ends). This driver continues to use the VFE naming
in some places to preserve consistency with the existing code and avoid
unnecessary renaming. Support is currently limited to three output lines,
matching the constraints of the CAMSS framework.
Kaanapali requires REG_UPDATE and AUP_UPDATE to be issued only after all
CSID configuration has completed. In addition, the number of AUP_UPDATE
requests must match the number of buffers queued to the write master
while it is being enabled.
Although real-time TFE traffic is routed through RT_CAMNOC, both
camnoc_rt_axi and camnoc_nrt_axi clocks must be enabled. This ensures
that the PDX_NOC, which sits downstream of both RT and NRT NOCs, exits
reset in a fully idle state.
Co-developed-by: Atiya Kailany <atiya.kailany@oss.qualcomm.com>
Signed-off-by: Atiya Kailany <atiya.kailany@oss.qualcomm.com>
Signed-off-by: Hangxiang Ma <hangxiang.ma@oss.qualcomm.com>
---
drivers/media/platform/qcom/camss/Makefile | 1 +
drivers/media/platform/qcom/camss/camss-vfe-gen4.c | 197 +++++++++++++++++++++
drivers/media/platform/qcom/camss/camss-vfe.c | 9 +-
drivers/media/platform/qcom/camss/camss-vfe.h | 2 +
drivers/media/platform/qcom/camss/camss.c | 153 ++++++++++++++++
5 files changed, 360 insertions(+), 2 deletions(-)
diff --git a/drivers/media/platform/qcom/camss/Makefile b/drivers/media/platform/qcom/camss/Makefile
index cebfd947f28e..b114ca37e36e 100644
--- a/drivers/media/platform/qcom/camss/Makefile
+++ b/drivers/media/platform/qcom/camss/Makefile
@@ -28,6 +28,7 @@ qcom-camss-objs += \
camss-vfe-680.o \
camss-vfe-gen1.o \
camss-vfe-gen3.o \
+ camss-vfe-gen4.o \
camss-vfe-vbif.o \
camss-video.o
diff --git a/drivers/media/platform/qcom/camss/camss-vfe-gen4.c b/drivers/media/platform/qcom/camss/camss-vfe-gen4.c
new file mode 100644
index 000000000000..d73d70898710
--- /dev/null
+++ b/drivers/media/platform/qcom/camss/camss-vfe-gen4.c
@@ -0,0 +1,197 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * camss-vfe-gen4.c
+ *
+ * Qualcomm MSM Camera Subsystem - VFE (Video Front End) Module gen4
+ *
+ * Copyright (c) Qualcomm Technologies, Inc. and/or its subsidiaries.
+ */
+#include <linux/interrupt.h>
+#include <linux/io.h>
+#include <linux/iopoll.h>
+
+#include "camss.h"
+#include "camss-vfe.h"
+
+/* VFE-gen4 Bus Register Base Addresses */
+#define BUS_REG_BASE (vfe_is_lite(vfe) ? 0x800 : 0x1000)
+
+#define VFE_BUS_WM_CGC_OVERRIDE (BUS_REG_BASE + 0x08)
+#define WM_CGC_OVERRIDE_ALL (0x7FFFFFF)
+
+#define VFE_BUS_WM_TEST_BUS_CTRL (BUS_REG_BASE + 0x128)
+
+#define VFE_BUS_WM_CFG(n) (BUS_REG_BASE + 0x500 + (n) * 0x100)
+#define WM_CFG_EN BIT(0)
+#define WM_VIR_FRM_EN BIT(1)
+#define WM_CFG_MODE BIT(16)
+#define VFE_BUS_WM_IMAGE_ADDR(n) (BUS_REG_BASE + 0x504 + (n) * 0x100)
+#define VFE_BUS_WM_FRAME_INCR(n) (BUS_REG_BASE + 0x508 + (n) * 0x100)
+#define VFE_BUS_WM_IMAGE_CFG_0(n) (BUS_REG_BASE + 0x50C + (n) * 0x100)
+#define WM_IMAGE_CFG_0_DEFAULT_WIDTH (0xFFFF)
+#define VFE_BUS_WM_IMAGE_CFG_2(n) (BUS_REG_BASE + 0x514 + (n) * 0x100)
+#define WM_IMAGE_CFG_2_DEFAULT_STRIDE (0xFFFF)
+#define VFE_BUS_WM_PACKER_CFG(n) (BUS_REG_BASE + 0x518 + (n) * 0x100)
+
+#define VFE_BUS_WM_IRQ_SUBSAMPLE_PERIOD(n) (BUS_REG_BASE + 0x530 + (n) * 0x100)
+#define VFE_BUS_WM_IRQ_SUBSAMPLE_PATTERN(n) (BUS_REG_BASE + 0x534 + (n) * 0x100)
+
+/* VFE lite has no such registers */
+#define VFE_BUS_WM_FRAMEDROP_PERIOD(n) (BUS_REG_BASE + 0x538 + (n) * 0x100)
+#define VFE_BUS_WM_FRAMEDROP_PATTERN(n) (BUS_REG_BASE + 0x53C + (n) * 0x100)
+
+#define VFE_BUS_WM_MMU_PREFETCH_CFG(n) (BUS_REG_BASE + 0x560 + (n) * 0x100)
+#define VFE_BUS_WM_MMU_PREFETCH_MAX_OFFSET(n) (BUS_REG_BASE + 0x564 + (n) * 0x100)
+
+/*
+ * IFE write master client IDs
+ *
+ * VIDEO_FULL 0
+ * VIDEO_DC4_Y 1
+ * VIDEO_DC4_C 2
+ * VIDEO_DC16_Y 3
+ * VIDEO_DC16_C 4
+ * DISPLAY_DS2_Y 5
+ * DISPLAY_DS2_C 6
+ * FD_Y 7
+ * FD_C 8
+ * PIXEL_RAW 9
+ * STATS_AEC_BG 10
+ * STATS_AEC_BHIST 11
+ * STATS_TINTLESS_BG 12
+ * STATS_AWB_BG 13
+ * STATS_AWB_BFW 14
+ * STATS_AF_BHIST 15
+ * STATS_ALSC_BG 16
+ * STATS_FLICKER_BAYERRS 17
+ * STATS_TMC_BHIST 18
+ * PDAF_0 19
+ * PDAF_1 20
+ * PDAF_2 21
+ * PDAF_3 22
+ * RDI0 23
+ * RDI1 24
+ * RDI2 25
+ * RDI3 26
+ * RDI4 27
+ *
+ * IFE Lite write master client IDs
+ *
+ * RDI0 0
+ * RDI1 1
+ * RDI2 2
+ * RDI3 3
+ * GAMMA 4
+ * STATES_BE 5
+ */
+#define RDI_WM(n) ((vfe_is_lite(vfe) ? 0x0 : 0x17) + (n))
+
+static void vfe_wm_start(struct vfe_device *vfe, u8 wm, struct vfe_line *line)
+{
+ struct v4l2_pix_format_mplane *pix =
+ &line->video_out.active_fmt.fmt.pix_mp;
+
+ wm = RDI_WM(wm);
+
+ /* no clock gating at bus input */
+ writel(WM_CGC_OVERRIDE_ALL, vfe->base + VFE_BUS_WM_CGC_OVERRIDE);
+
+ writel(0x0, vfe->base + VFE_BUS_WM_TEST_BUS_CTRL);
+
+ writel(ALIGN(pix->plane_fmt[0].bytesperline, 16) * pix->height >> 8,
+ vfe->base + VFE_BUS_WM_FRAME_INCR(wm));
+ writel((WM_IMAGE_CFG_0_DEFAULT_WIDTH & 0xFFFF),
+ vfe->base + VFE_BUS_WM_IMAGE_CFG_0(wm));
+ writel(WM_IMAGE_CFG_2_DEFAULT_STRIDE,
+ vfe->base + VFE_BUS_WM_IMAGE_CFG_2(wm));
+ writel(0, vfe->base + VFE_BUS_WM_PACKER_CFG(wm));
+
+ /* no dropped frames, one irq per frame */
+ if (!vfe_is_lite(vfe)) {
+ writel(0, vfe->base + VFE_BUS_WM_FRAMEDROP_PERIOD(wm));
+ writel(1, vfe->base + VFE_BUS_WM_FRAMEDROP_PATTERN(wm));
+ }
+
+ writel(0, vfe->base + VFE_BUS_WM_IRQ_SUBSAMPLE_PERIOD(wm));
+ writel(1, vfe->base + VFE_BUS_WM_IRQ_SUBSAMPLE_PATTERN(wm));
+
+ writel(1, vfe->base + VFE_BUS_WM_MMU_PREFETCH_CFG(wm));
+ writel(0xFFFFFFFF, vfe->base + VFE_BUS_WM_MMU_PREFETCH_MAX_OFFSET(wm));
+
+ writel(WM_CFG_EN | WM_CFG_MODE, vfe->base + VFE_BUS_WM_CFG(wm));
+}
+
+static void vfe_wm_stop(struct vfe_device *vfe, u8 wm)
+{
+ wm = RDI_WM(wm);
+ writel(0, vfe->base + VFE_BUS_WM_CFG(wm));
+}
+
+static void vfe_wm_update(struct vfe_device *vfe, u8 wm, u32 addr,
+ struct vfe_line *line)
+{
+ wm = RDI_WM(wm);
+ writel(addr >> 8, vfe->base + VFE_BUS_WM_IMAGE_ADDR(wm));
+
+ dev_dbg(vfe->camss->dev, "wm:%d, image buf addr:0x%x\n", wm, addr);
+}
+
+static void vfe_reg_update(struct vfe_device *vfe, enum vfe_line_id line_id)
+{
+ int port_id = line_id;
+
+ camss_reg_update(vfe->camss, vfe->id, port_id, false);
+}
+
+static inline void vfe_reg_update_clear(struct vfe_device *vfe,
+ enum vfe_line_id line_id)
+{
+ int port_id = line_id;
+
+ camss_reg_update(vfe->camss, vfe->id, port_id, true);
+}
+
+static const struct camss_video_ops vfe_video_ops_gen4 = {
+ .queue_buffer = vfe_queue_buffer_v2,
+ .flush_buffers = vfe_flush_buffers,
+};
+
+static void vfe_subdev_init(struct device *dev, struct vfe_device *vfe)
+{
+ vfe->video_ops = vfe_video_ops_gen4;
+}
+
+static void vfe_global_reset(struct vfe_device *vfe)
+{
+ vfe_isr_reset_ack(vfe);
+}
+
+static irqreturn_t vfe_isr(int irq, void *dev)
+{
+ /* nop */
+ return IRQ_HANDLED;
+}
+
+static int vfe_halt(struct vfe_device *vfe)
+{
+ /* rely on vfe_disable_output() to stop the VFE */
+ return 0;
+}
+
+const struct vfe_hw_ops vfe_ops_gen4 = {
+ .global_reset = vfe_global_reset,
+ .hw_version = vfe_hw_version,
+ .isr = vfe_isr,
+ .pm_domain_off = vfe_pm_domain_off,
+ .pm_domain_on = vfe_pm_domain_on,
+ .reg_update = vfe_reg_update,
+ .reg_update_clear = vfe_reg_update_clear,
+ .subdev_init = vfe_subdev_init,
+ .vfe_disable = vfe_disable,
+ .vfe_enable = vfe_enable_v2,
+ .vfe_halt = vfe_halt,
+ .vfe_wm_start = vfe_wm_start,
+ .vfe_wm_stop = vfe_wm_stop,
+ .vfe_buf_done = vfe_buf_done,
+ .vfe_wm_update = vfe_wm_update,
+};
diff --git a/drivers/media/platform/qcom/camss/camss-vfe.c b/drivers/media/platform/qcom/camss/camss-vfe.c
index c14d97a131f6..a268ff35d6d1 100644
--- a/drivers/media/platform/qcom/camss/camss-vfe.c
+++ b/drivers/media/platform/qcom/camss/camss-vfe.c
@@ -353,6 +353,7 @@ static u32 vfe_src_pad_code(struct vfe_line *line, u32 sink_code,
case CAMSS_8550:
case CAMSS_8650:
case CAMSS_8775P:
+ case CAMSS_KAANAPALI:
case CAMSS_X1E80100:
switch (sink_code) {
case MEDIA_BUS_FMT_YUYV8_1X16:
@@ -525,7 +526,8 @@ int vfe_enable_output_v2(struct vfe_line *line)
spin_lock_irqsave(&vfe->output_lock, flags);
- ops->reg_update_clear(vfe, line->id);
+ if (ops->reg_update_clear)
+ ops->reg_update_clear(vfe, line->id);
if (output->state > VFE_OUTPUT_RESERVED) {
dev_err(vfe->camss->dev,
@@ -552,7 +554,9 @@ int vfe_enable_output_v2(struct vfe_line *line)
output->gen2.active_num++;
ops->vfe_wm_update(vfe, output->wm_idx[0],
output->buf[i]->addr[0], line);
- ops->reg_update(vfe, line->id);
+
+ if (!vfe->res->reg_update_after_csid_config)
+ ops->reg_update(vfe, line->id);
}
spin_unlock_irqrestore(&vfe->output_lock, flags);
@@ -2017,6 +2021,7 @@ static int vfe_bpl_align_rdi(struct vfe_device *vfe)
case CAMSS_8550:
case CAMSS_8650:
case CAMSS_8775P:
+ case CAMSS_KAANAPALI:
case CAMSS_X1E80100:
ret = 16;
break;
diff --git a/drivers/media/platform/qcom/camss/camss-vfe.h b/drivers/media/platform/qcom/camss/camss-vfe.h
index ae9dad353a37..c402ef170c81 100644
--- a/drivers/media/platform/qcom/camss/camss-vfe.h
+++ b/drivers/media/platform/qcom/camss/camss-vfe.h
@@ -133,6 +133,7 @@ struct vfe_isr_ops {
struct vfe_subdev_resources {
bool is_lite;
+ bool reg_update_after_csid_config;
u8 line_num;
bool has_pd;
char *pd_name;
@@ -249,6 +250,7 @@ extern const struct vfe_hw_ops vfe_ops_340;
extern const struct vfe_hw_ops vfe_ops_480;
extern const struct vfe_hw_ops vfe_ops_680;
extern const struct vfe_hw_ops vfe_ops_gen3;
+extern const struct vfe_hw_ops vfe_ops_gen4;
int vfe_get(struct vfe_device *vfe);
void vfe_put(struct vfe_device *vfe);
diff --git a/drivers/media/platform/qcom/camss/camss.c b/drivers/media/platform/qcom/camss/camss.c
index 52cbbf424980..2f835cf2e32e 100644
--- a/drivers/media/platform/qcom/camss/camss.c
+++ b/drivers/media/platform/qcom/camss/camss.c
@@ -158,6 +158,157 @@ static const struct camss_subdev_resources csid_res_kaanapali[] = {
}
};
+/* In Kaanapali, CAMNOC requires all CPAS_TFEX clocks
+ * to operate on any TFE Full.
+ */
+static const struct camss_subdev_resources vfe_res_kaanapali[] = {
+ /* VFE0 - TFE Full */
+ {
+ .clock = { "gcc_axi_hf", "cpas_ahb", "cpas_fast_ahb",
+ "vfe0_fast_ahb", "vfe0",
+ "cpas_vfe0", "cpas_vfe1", "cpas_vfe2",
+ "camnoc_rt_axi", "camnoc_nrt_axi", "qdss_debug_xo" },
+ .clock_rate = { { 0 },
+ { 0 },
+ { 0 },
+ { 0 },
+ { 360280000, 480000000, 630000000, 716000000,
+ 833000000 },
+ { 0 },
+ { 0 },
+ { 0 },
+ { 200000000, 300000000, 400000000, 480000000 },
+ { 0 },
+ { 0 } },
+ .reg = { "vfe0" },
+ .interrupt = { "vfe0" },
+ .vfe = {
+ .line_num = 3,
+ .is_lite = false,
+ .reg_update_after_csid_config = true,
+ .has_pd = true,
+ .pd_name = "ife0",
+ .hw_ops = &vfe_ops_gen4,
+ .formats_rdi = &vfe_formats_rdi_845,
+ .formats_pix = &vfe_formats_pix_845
+ }
+ },
+ /* VFE1 - TFE Full */
+ {
+ .clock = { "gcc_axi_hf", "cpas_ahb", "cpas_fast_ahb",
+ "vfe1_fast_ahb", "vfe1",
+ "cpas_vfe0", "cpas_vfe1", "cpas_vfe2",
+ "camnoc_rt_axi", "camnoc_nrt_axi", "qdss_debug_xo" },
+ .clock_rate = { { 0 },
+ { 0 },
+ { 0 },
+ { 0 },
+ { 360280000, 480000000, 630000000, 716000000,
+ 833000000 },
+ { 0 },
+ { 0 },
+ { 0 },
+ { 200000000, 300000000, 400000000, 480000000 },
+ { 0 },
+ { 0 } },
+ .reg = { "vfe1" },
+ .interrupt = { "vfe1" },
+ .vfe = {
+ .line_num = 3,
+ .is_lite = false,
+ .reg_update_after_csid_config = true,
+ .has_pd = true,
+ .pd_name = "ife1",
+ .hw_ops = &vfe_ops_gen4,
+ .formats_rdi = &vfe_formats_rdi_845,
+ .formats_pix = &vfe_formats_pix_845
+ }
+ },
+ /* VFE2 - TFE Full */
+ {
+ .clock = { "gcc_axi_hf", "cpas_ahb", "cpas_fast_ahb",
+ "vfe2_fast_ahb", "vfe2",
+ "cpas_vfe0", "cpas_vfe1", "cpas_vfe2",
+ "camnoc_rt_axi", "camnoc_nrt_axi", "qdss_debug_xo" },
+ .clock_rate = { { 0 },
+ { 0 },
+ { 0 },
+ { 0 },
+ { 360280000, 480000000, 630000000, 716000000,
+ 833000000 },
+ { 0 },
+ { 0 },
+ { 0 },
+ { 200000000, 300000000, 400000000, 480000000 },
+ { 0 },
+ { 0 } },
+ .reg = { "vfe2" },
+ .interrupt = { "vfe2" },
+ .vfe = {
+ .line_num = 3,
+ .is_lite = false,
+ .reg_update_after_csid_config = true,
+ .has_pd = true,
+ .pd_name = "ife2",
+ .hw_ops = &vfe_ops_gen4,
+ .formats_rdi = &vfe_formats_rdi_845,
+ .formats_pix = &vfe_formats_pix_845
+ }
+ },
+ /* VFE3 - IFE Lite */
+ {
+ .clock = { "gcc_axi_hf", "cpas_ahb", "cpas_fast_ahb",
+ "vfe_lite_ahb", "vfe_lite",
+ "cpas_vfe_lite", "camnoc_rt_axi",
+ "camnoc_nrt_axi", "qdss_debug_xo" },
+ .clock_rate = { { 0 },
+ { 0 },
+ { 0 },
+ { 0 },
+ { 266666667, 400000000, 480000000 },
+ { 0 },
+ { 200000000, 300000000, 400000000, 480000000 },
+ { 0 },
+ { 0 } },
+ .reg = { "vfe_lite0" },
+ .interrupt = { "vfe_lite0" },
+ .vfe = {
+ .line_num = 4,
+ .is_lite = true,
+ .reg_update_after_csid_config = true,
+ .hw_ops = &vfe_ops_gen4,
+ .formats_rdi = &vfe_formats_rdi_845,
+ .formats_pix = &vfe_formats_pix_845
+ }
+ },
+ /* VFE4 - IFE Lite */
+ {
+ .clock = { "gcc_axi_hf", "cpas_ahb", "cpas_fast_ahb",
+ "vfe_lite_ahb", "vfe_lite",
+ "cpas_vfe_lite", "camnoc_rt_axi",
+ "camnoc_nrt_axi", "qdss_debug_xo" },
+ .clock_rate = { { 0 },
+ { 0 },
+ { 0 },
+ { 0 },
+ { 266666667, 400000000, 480000000 },
+ { 0 },
+ { 200000000, 300000000, 400000000, 480000000 },
+ { 0 },
+ { 0 } },
+ .reg = { "vfe_lite1" },
+ .interrupt = { "vfe_lite1" },
+ .vfe = {
+ .line_num = 4,
+ .is_lite = true,
+ .reg_update_after_csid_config = true,
+ .hw_ops = &vfe_ops_gen4,
+ .formats_rdi = &vfe_formats_rdi_845,
+ .formats_pix = &vfe_formats_pix_845
+ }
+ },
+};
+
static const struct resources_icc icc_res_kaanapali[] = {
{
.name = "ahb",
@@ -5643,10 +5794,12 @@ static const struct camss_resources kaanapali_resources = {
.pd_name = "top",
.csiphy_res = csiphy_res_kaanapali,
.csid_res = csid_res_kaanapali,
+ .vfe_res = vfe_res_kaanapali,
.icc_res = icc_res_kaanapali,
.icc_path_num = ARRAY_SIZE(icc_res_kaanapali),
.csiphy_num = ARRAY_SIZE(csiphy_res_kaanapali),
.csid_num = ARRAY_SIZE(csid_res_kaanapali),
+ .vfe_num = ARRAY_SIZE(vfe_res_kaanapali),
};
static const struct camss_resources msm8916_resources = {
--
2.34.1
^ permalink raw reply related [flat|nested] 58+ messages in thread
* [PATCH v17 07/11] media: qcom: camss: vfe: Add support for VFE Gen4
@ 2026-09-29 6:00 ` Hangxiang Ma
0 siblings, 0 replies; 58+ messages in thread
From: Hangxiang Ma @ 2026-09-29 6:00 UTC (permalink / raw)
To: Bryan O'Donoghue, Vinod Koul, Neil Armstrong,
Manivannan Sadhasivam, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Bryan O'Donoghue, Vladimir Zapolskiy,
Loic Poulain, Mauro Carvalho Chehab, Bjorn Andersson,
Konrad Dybcio, Abel Vesa
Cc: linux-phy, linux-media, linux-arm-msm, devicetree, linux-kernel,
jeyaprakash.soundrapandian, Vijay Kumar Tumati, Hangxiang Ma,
Atiya Kailany
Add support for the VFE (Video Front End) Gen4 found on Kaanapali SoC.
In the Kaanapali camera subsystem, the front-end blocks are referred to
as TFEs (Thin Front Ends). This driver continues to use the VFE naming
in some places to preserve consistency with the existing code and avoid
unnecessary renaming. Support is currently limited to three output lines,
matching the constraints of the CAMSS framework.
Kaanapali requires REG_UPDATE and AUP_UPDATE to be issued only after all
CSID configuration has completed. In addition, the number of AUP_UPDATE
requests must match the number of buffers queued to the write master
while it is being enabled.
Although real-time TFE traffic is routed through RT_CAMNOC, both
camnoc_rt_axi and camnoc_nrt_axi clocks must be enabled. This ensures
that the PDX_NOC, which sits downstream of both RT and NRT NOCs, exits
reset in a fully idle state.
Co-developed-by: Atiya Kailany <atiya.kailany@oss.qualcomm.com>
Signed-off-by: Atiya Kailany <atiya.kailany@oss.qualcomm.com>
Signed-off-by: Hangxiang Ma <hangxiang.ma@oss.qualcomm.com>
---
drivers/media/platform/qcom/camss/Makefile | 1 +
drivers/media/platform/qcom/camss/camss-vfe-gen4.c | 197 +++++++++++++++++++++
drivers/media/platform/qcom/camss/camss-vfe.c | 9 +-
drivers/media/platform/qcom/camss/camss-vfe.h | 2 +
drivers/media/platform/qcom/camss/camss.c | 153 ++++++++++++++++
5 files changed, 360 insertions(+), 2 deletions(-)
diff --git a/drivers/media/platform/qcom/camss/Makefile b/drivers/media/platform/qcom/camss/Makefile
index cebfd947f28e..b114ca37e36e 100644
--- a/drivers/media/platform/qcom/camss/Makefile
+++ b/drivers/media/platform/qcom/camss/Makefile
@@ -28,6 +28,7 @@ qcom-camss-objs += \
camss-vfe-680.o \
camss-vfe-gen1.o \
camss-vfe-gen3.o \
+ camss-vfe-gen4.o \
camss-vfe-vbif.o \
camss-video.o
diff --git a/drivers/media/platform/qcom/camss/camss-vfe-gen4.c b/drivers/media/platform/qcom/camss/camss-vfe-gen4.c
new file mode 100644
index 000000000000..d73d70898710
--- /dev/null
+++ b/drivers/media/platform/qcom/camss/camss-vfe-gen4.c
@@ -0,0 +1,197 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * camss-vfe-gen4.c
+ *
+ * Qualcomm MSM Camera Subsystem - VFE (Video Front End) Module gen4
+ *
+ * Copyright (c) Qualcomm Technologies, Inc. and/or its subsidiaries.
+ */
+#include <linux/interrupt.h>
+#include <linux/io.h>
+#include <linux/iopoll.h>
+
+#include "camss.h"
+#include "camss-vfe.h"
+
+/* VFE-gen4 Bus Register Base Addresses */
+#define BUS_REG_BASE (vfe_is_lite(vfe) ? 0x800 : 0x1000)
+
+#define VFE_BUS_WM_CGC_OVERRIDE (BUS_REG_BASE + 0x08)
+#define WM_CGC_OVERRIDE_ALL (0x7FFFFFF)
+
+#define VFE_BUS_WM_TEST_BUS_CTRL (BUS_REG_BASE + 0x128)
+
+#define VFE_BUS_WM_CFG(n) (BUS_REG_BASE + 0x500 + (n) * 0x100)
+#define WM_CFG_EN BIT(0)
+#define WM_VIR_FRM_EN BIT(1)
+#define WM_CFG_MODE BIT(16)
+#define VFE_BUS_WM_IMAGE_ADDR(n) (BUS_REG_BASE + 0x504 + (n) * 0x100)
+#define VFE_BUS_WM_FRAME_INCR(n) (BUS_REG_BASE + 0x508 + (n) * 0x100)
+#define VFE_BUS_WM_IMAGE_CFG_0(n) (BUS_REG_BASE + 0x50C + (n) * 0x100)
+#define WM_IMAGE_CFG_0_DEFAULT_WIDTH (0xFFFF)
+#define VFE_BUS_WM_IMAGE_CFG_2(n) (BUS_REG_BASE + 0x514 + (n) * 0x100)
+#define WM_IMAGE_CFG_2_DEFAULT_STRIDE (0xFFFF)
+#define VFE_BUS_WM_PACKER_CFG(n) (BUS_REG_BASE + 0x518 + (n) * 0x100)
+
+#define VFE_BUS_WM_IRQ_SUBSAMPLE_PERIOD(n) (BUS_REG_BASE + 0x530 + (n) * 0x100)
+#define VFE_BUS_WM_IRQ_SUBSAMPLE_PATTERN(n) (BUS_REG_BASE + 0x534 + (n) * 0x100)
+
+/* VFE lite has no such registers */
+#define VFE_BUS_WM_FRAMEDROP_PERIOD(n) (BUS_REG_BASE + 0x538 + (n) * 0x100)
+#define VFE_BUS_WM_FRAMEDROP_PATTERN(n) (BUS_REG_BASE + 0x53C + (n) * 0x100)
+
+#define VFE_BUS_WM_MMU_PREFETCH_CFG(n) (BUS_REG_BASE + 0x560 + (n) * 0x100)
+#define VFE_BUS_WM_MMU_PREFETCH_MAX_OFFSET(n) (BUS_REG_BASE + 0x564 + (n) * 0x100)
+
+/*
+ * IFE write master client IDs
+ *
+ * VIDEO_FULL 0
+ * VIDEO_DC4_Y 1
+ * VIDEO_DC4_C 2
+ * VIDEO_DC16_Y 3
+ * VIDEO_DC16_C 4
+ * DISPLAY_DS2_Y 5
+ * DISPLAY_DS2_C 6
+ * FD_Y 7
+ * FD_C 8
+ * PIXEL_RAW 9
+ * STATS_AEC_BG 10
+ * STATS_AEC_BHIST 11
+ * STATS_TINTLESS_BG 12
+ * STATS_AWB_BG 13
+ * STATS_AWB_BFW 14
+ * STATS_AF_BHIST 15
+ * STATS_ALSC_BG 16
+ * STATS_FLICKER_BAYERRS 17
+ * STATS_TMC_BHIST 18
+ * PDAF_0 19
+ * PDAF_1 20
+ * PDAF_2 21
+ * PDAF_3 22
+ * RDI0 23
+ * RDI1 24
+ * RDI2 25
+ * RDI3 26
+ * RDI4 27
+ *
+ * IFE Lite write master client IDs
+ *
+ * RDI0 0
+ * RDI1 1
+ * RDI2 2
+ * RDI3 3
+ * GAMMA 4
+ * STATES_BE 5
+ */
+#define RDI_WM(n) ((vfe_is_lite(vfe) ? 0x0 : 0x17) + (n))
+
+static void vfe_wm_start(struct vfe_device *vfe, u8 wm, struct vfe_line *line)
+{
+ struct v4l2_pix_format_mplane *pix =
+ &line->video_out.active_fmt.fmt.pix_mp;
+
+ wm = RDI_WM(wm);
+
+ /* no clock gating at bus input */
+ writel(WM_CGC_OVERRIDE_ALL, vfe->base + VFE_BUS_WM_CGC_OVERRIDE);
+
+ writel(0x0, vfe->base + VFE_BUS_WM_TEST_BUS_CTRL);
+
+ writel(ALIGN(pix->plane_fmt[0].bytesperline, 16) * pix->height >> 8,
+ vfe->base + VFE_BUS_WM_FRAME_INCR(wm));
+ writel((WM_IMAGE_CFG_0_DEFAULT_WIDTH & 0xFFFF),
+ vfe->base + VFE_BUS_WM_IMAGE_CFG_0(wm));
+ writel(WM_IMAGE_CFG_2_DEFAULT_STRIDE,
+ vfe->base + VFE_BUS_WM_IMAGE_CFG_2(wm));
+ writel(0, vfe->base + VFE_BUS_WM_PACKER_CFG(wm));
+
+ /* no dropped frames, one irq per frame */
+ if (!vfe_is_lite(vfe)) {
+ writel(0, vfe->base + VFE_BUS_WM_FRAMEDROP_PERIOD(wm));
+ writel(1, vfe->base + VFE_BUS_WM_FRAMEDROP_PATTERN(wm));
+ }
+
+ writel(0, vfe->base + VFE_BUS_WM_IRQ_SUBSAMPLE_PERIOD(wm));
+ writel(1, vfe->base + VFE_BUS_WM_IRQ_SUBSAMPLE_PATTERN(wm));
+
+ writel(1, vfe->base + VFE_BUS_WM_MMU_PREFETCH_CFG(wm));
+ writel(0xFFFFFFFF, vfe->base + VFE_BUS_WM_MMU_PREFETCH_MAX_OFFSET(wm));
+
+ writel(WM_CFG_EN | WM_CFG_MODE, vfe->base + VFE_BUS_WM_CFG(wm));
+}
+
+static void vfe_wm_stop(struct vfe_device *vfe, u8 wm)
+{
+ wm = RDI_WM(wm);
+ writel(0, vfe->base + VFE_BUS_WM_CFG(wm));
+}
+
+static void vfe_wm_update(struct vfe_device *vfe, u8 wm, u32 addr,
+ struct vfe_line *line)
+{
+ wm = RDI_WM(wm);
+ writel(addr >> 8, vfe->base + VFE_BUS_WM_IMAGE_ADDR(wm));
+
+ dev_dbg(vfe->camss->dev, "wm:%d, image buf addr:0x%x\n", wm, addr);
+}
+
+static void vfe_reg_update(struct vfe_device *vfe, enum vfe_line_id line_id)
+{
+ int port_id = line_id;
+
+ camss_reg_update(vfe->camss, vfe->id, port_id, false);
+}
+
+static inline void vfe_reg_update_clear(struct vfe_device *vfe,
+ enum vfe_line_id line_id)
+{
+ int port_id = line_id;
+
+ camss_reg_update(vfe->camss, vfe->id, port_id, true);
+}
+
+static const struct camss_video_ops vfe_video_ops_gen4 = {
+ .queue_buffer = vfe_queue_buffer_v2,
+ .flush_buffers = vfe_flush_buffers,
+};
+
+static void vfe_subdev_init(struct device *dev, struct vfe_device *vfe)
+{
+ vfe->video_ops = vfe_video_ops_gen4;
+}
+
+static void vfe_global_reset(struct vfe_device *vfe)
+{
+ vfe_isr_reset_ack(vfe);
+}
+
+static irqreturn_t vfe_isr(int irq, void *dev)
+{
+ /* nop */
+ return IRQ_HANDLED;
+}
+
+static int vfe_halt(struct vfe_device *vfe)
+{
+ /* rely on vfe_disable_output() to stop the VFE */
+ return 0;
+}
+
+const struct vfe_hw_ops vfe_ops_gen4 = {
+ .global_reset = vfe_global_reset,
+ .hw_version = vfe_hw_version,
+ .isr = vfe_isr,
+ .pm_domain_off = vfe_pm_domain_off,
+ .pm_domain_on = vfe_pm_domain_on,
+ .reg_update = vfe_reg_update,
+ .reg_update_clear = vfe_reg_update_clear,
+ .subdev_init = vfe_subdev_init,
+ .vfe_disable = vfe_disable,
+ .vfe_enable = vfe_enable_v2,
+ .vfe_halt = vfe_halt,
+ .vfe_wm_start = vfe_wm_start,
+ .vfe_wm_stop = vfe_wm_stop,
+ .vfe_buf_done = vfe_buf_done,
+ .vfe_wm_update = vfe_wm_update,
+};
diff --git a/drivers/media/platform/qcom/camss/camss-vfe.c b/drivers/media/platform/qcom/camss/camss-vfe.c
index c14d97a131f6..a268ff35d6d1 100644
--- a/drivers/media/platform/qcom/camss/camss-vfe.c
+++ b/drivers/media/platform/qcom/camss/camss-vfe.c
@@ -353,6 +353,7 @@ static u32 vfe_src_pad_code(struct vfe_line *line, u32 sink_code,
case CAMSS_8550:
case CAMSS_8650:
case CAMSS_8775P:
+ case CAMSS_KAANAPALI:
case CAMSS_X1E80100:
switch (sink_code) {
case MEDIA_BUS_FMT_YUYV8_1X16:
@@ -525,7 +526,8 @@ int vfe_enable_output_v2(struct vfe_line *line)
spin_lock_irqsave(&vfe->output_lock, flags);
- ops->reg_update_clear(vfe, line->id);
+ if (ops->reg_update_clear)
+ ops->reg_update_clear(vfe, line->id);
if (output->state > VFE_OUTPUT_RESERVED) {
dev_err(vfe->camss->dev,
@@ -552,7 +554,9 @@ int vfe_enable_output_v2(struct vfe_line *line)
output->gen2.active_num++;
ops->vfe_wm_update(vfe, output->wm_idx[0],
output->buf[i]->addr[0], line);
- ops->reg_update(vfe, line->id);
+
+ if (!vfe->res->reg_update_after_csid_config)
+ ops->reg_update(vfe, line->id);
}
spin_unlock_irqrestore(&vfe->output_lock, flags);
@@ -2017,6 +2021,7 @@ static int vfe_bpl_align_rdi(struct vfe_device *vfe)
case CAMSS_8550:
case CAMSS_8650:
case CAMSS_8775P:
+ case CAMSS_KAANAPALI:
case CAMSS_X1E80100:
ret = 16;
break;
diff --git a/drivers/media/platform/qcom/camss/camss-vfe.h b/drivers/media/platform/qcom/camss/camss-vfe.h
index ae9dad353a37..c402ef170c81 100644
--- a/drivers/media/platform/qcom/camss/camss-vfe.h
+++ b/drivers/media/platform/qcom/camss/camss-vfe.h
@@ -133,6 +133,7 @@ struct vfe_isr_ops {
struct vfe_subdev_resources {
bool is_lite;
+ bool reg_update_after_csid_config;
u8 line_num;
bool has_pd;
char *pd_name;
@@ -249,6 +250,7 @@ extern const struct vfe_hw_ops vfe_ops_340;
extern const struct vfe_hw_ops vfe_ops_480;
extern const struct vfe_hw_ops vfe_ops_680;
extern const struct vfe_hw_ops vfe_ops_gen3;
+extern const struct vfe_hw_ops vfe_ops_gen4;
int vfe_get(struct vfe_device *vfe);
void vfe_put(struct vfe_device *vfe);
diff --git a/drivers/media/platform/qcom/camss/camss.c b/drivers/media/platform/qcom/camss/camss.c
index 52cbbf424980..2f835cf2e32e 100644
--- a/drivers/media/platform/qcom/camss/camss.c
+++ b/drivers/media/platform/qcom/camss/camss.c
@@ -158,6 +158,157 @@ static const struct camss_subdev_resources csid_res_kaanapali[] = {
}
};
+/* In Kaanapali, CAMNOC requires all CPAS_TFEX clocks
+ * to operate on any TFE Full.
+ */
+static const struct camss_subdev_resources vfe_res_kaanapali[] = {
+ /* VFE0 - TFE Full */
+ {
+ .clock = { "gcc_axi_hf", "cpas_ahb", "cpas_fast_ahb",
+ "vfe0_fast_ahb", "vfe0",
+ "cpas_vfe0", "cpas_vfe1", "cpas_vfe2",
+ "camnoc_rt_axi", "camnoc_nrt_axi", "qdss_debug_xo" },
+ .clock_rate = { { 0 },
+ { 0 },
+ { 0 },
+ { 0 },
+ { 360280000, 480000000, 630000000, 716000000,
+ 833000000 },
+ { 0 },
+ { 0 },
+ { 0 },
+ { 200000000, 300000000, 400000000, 480000000 },
+ { 0 },
+ { 0 } },
+ .reg = { "vfe0" },
+ .interrupt = { "vfe0" },
+ .vfe = {
+ .line_num = 3,
+ .is_lite = false,
+ .reg_update_after_csid_config = true,
+ .has_pd = true,
+ .pd_name = "ife0",
+ .hw_ops = &vfe_ops_gen4,
+ .formats_rdi = &vfe_formats_rdi_845,
+ .formats_pix = &vfe_formats_pix_845
+ }
+ },
+ /* VFE1 - TFE Full */
+ {
+ .clock = { "gcc_axi_hf", "cpas_ahb", "cpas_fast_ahb",
+ "vfe1_fast_ahb", "vfe1",
+ "cpas_vfe0", "cpas_vfe1", "cpas_vfe2",
+ "camnoc_rt_axi", "camnoc_nrt_axi", "qdss_debug_xo" },
+ .clock_rate = { { 0 },
+ { 0 },
+ { 0 },
+ { 0 },
+ { 360280000, 480000000, 630000000, 716000000,
+ 833000000 },
+ { 0 },
+ { 0 },
+ { 0 },
+ { 200000000, 300000000, 400000000, 480000000 },
+ { 0 },
+ { 0 } },
+ .reg = { "vfe1" },
+ .interrupt = { "vfe1" },
+ .vfe = {
+ .line_num = 3,
+ .is_lite = false,
+ .reg_update_after_csid_config = true,
+ .has_pd = true,
+ .pd_name = "ife1",
+ .hw_ops = &vfe_ops_gen4,
+ .formats_rdi = &vfe_formats_rdi_845,
+ .formats_pix = &vfe_formats_pix_845
+ }
+ },
+ /* VFE2 - TFE Full */
+ {
+ .clock = { "gcc_axi_hf", "cpas_ahb", "cpas_fast_ahb",
+ "vfe2_fast_ahb", "vfe2",
+ "cpas_vfe0", "cpas_vfe1", "cpas_vfe2",
+ "camnoc_rt_axi", "camnoc_nrt_axi", "qdss_debug_xo" },
+ .clock_rate = { { 0 },
+ { 0 },
+ { 0 },
+ { 0 },
+ { 360280000, 480000000, 630000000, 716000000,
+ 833000000 },
+ { 0 },
+ { 0 },
+ { 0 },
+ { 200000000, 300000000, 400000000, 480000000 },
+ { 0 },
+ { 0 } },
+ .reg = { "vfe2" },
+ .interrupt = { "vfe2" },
+ .vfe = {
+ .line_num = 3,
+ .is_lite = false,
+ .reg_update_after_csid_config = true,
+ .has_pd = true,
+ .pd_name = "ife2",
+ .hw_ops = &vfe_ops_gen4,
+ .formats_rdi = &vfe_formats_rdi_845,
+ .formats_pix = &vfe_formats_pix_845
+ }
+ },
+ /* VFE3 - IFE Lite */
+ {
+ .clock = { "gcc_axi_hf", "cpas_ahb", "cpas_fast_ahb",
+ "vfe_lite_ahb", "vfe_lite",
+ "cpas_vfe_lite", "camnoc_rt_axi",
+ "camnoc_nrt_axi", "qdss_debug_xo" },
+ .clock_rate = { { 0 },
+ { 0 },
+ { 0 },
+ { 0 },
+ { 266666667, 400000000, 480000000 },
+ { 0 },
+ { 200000000, 300000000, 400000000, 480000000 },
+ { 0 },
+ { 0 } },
+ .reg = { "vfe_lite0" },
+ .interrupt = { "vfe_lite0" },
+ .vfe = {
+ .line_num = 4,
+ .is_lite = true,
+ .reg_update_after_csid_config = true,
+ .hw_ops = &vfe_ops_gen4,
+ .formats_rdi = &vfe_formats_rdi_845,
+ .formats_pix = &vfe_formats_pix_845
+ }
+ },
+ /* VFE4 - IFE Lite */
+ {
+ .clock = { "gcc_axi_hf", "cpas_ahb", "cpas_fast_ahb",
+ "vfe_lite_ahb", "vfe_lite",
+ "cpas_vfe_lite", "camnoc_rt_axi",
+ "camnoc_nrt_axi", "qdss_debug_xo" },
+ .clock_rate = { { 0 },
+ { 0 },
+ { 0 },
+ { 0 },
+ { 266666667, 400000000, 480000000 },
+ { 0 },
+ { 200000000, 300000000, 400000000, 480000000 },
+ { 0 },
+ { 0 } },
+ .reg = { "vfe_lite1" },
+ .interrupt = { "vfe_lite1" },
+ .vfe = {
+ .line_num = 4,
+ .is_lite = true,
+ .reg_update_after_csid_config = true,
+ .hw_ops = &vfe_ops_gen4,
+ .formats_rdi = &vfe_formats_rdi_845,
+ .formats_pix = &vfe_formats_pix_845
+ }
+ },
+};
+
static const struct resources_icc icc_res_kaanapali[] = {
{
.name = "ahb",
@@ -5643,10 +5794,12 @@ static const struct camss_resources kaanapali_resources = {
.pd_name = "top",
.csiphy_res = csiphy_res_kaanapali,
.csid_res = csid_res_kaanapali,
+ .vfe_res = vfe_res_kaanapali,
.icc_res = icc_res_kaanapali,
.icc_path_num = ARRAY_SIZE(icc_res_kaanapali),
.csiphy_num = ARRAY_SIZE(csiphy_res_kaanapali),
.csid_num = ARRAY_SIZE(csid_res_kaanapali),
+ .vfe_num = ARRAY_SIZE(vfe_res_kaanapali),
};
static const struct camss_resources msm8916_resources = {
--
2.34.1
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply related [flat|nested] 58+ messages in thread
* [PATCH v17 08/11] media: qcom: camss: tpg: Add support for v2.4.0 TPG
2026-09-29 6:00 ` Hangxiang Ma
@ 2026-09-29 6:00 ` Hangxiang Ma
-1 siblings, 0 replies; 58+ messages in thread
From: Hangxiang Ma @ 2026-09-29 6:00 UTC (permalink / raw)
To: Bryan O'Donoghue, Vinod Koul, Neil Armstrong,
Manivannan Sadhasivam, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Bryan O'Donoghue, Vladimir Zapolskiy,
Loic Poulain, Mauro Carvalho Chehab, Bjorn Andersson,
Konrad Dybcio, Abel Vesa
Cc: linux-phy, linux-media, linux-arm-msm, devicetree, linux-kernel,
jeyaprakash.soundrapandian, Vijay Kumar Tumati, Hangxiang Ma
Add support for the TPG found on Kaanapali. This TPG uses hardware
version 2.4.0, which drives test-enable and reset through a separate
TPG_CTRL_CMD register instead of TPG_CTRL, and routes its output into
the CSID gen4 RX via the CSI2 TPG mux.
Signed-off-by: Hangxiang Ma <hangxiang.ma@oss.qualcomm.com>
---
.../media/platform/qcom/camss/camss-csid-gen4.c | 15 ++++++++++--
drivers/media/platform/qcom/camss/camss-tpg-gen1.c | 27 +++++++++++++++++-----
drivers/media/platform/qcom/camss/camss.c | 2 ++
3 files changed, 36 insertions(+), 8 deletions(-)
diff --git a/drivers/media/platform/qcom/camss/camss-csid-gen4.c b/drivers/media/platform/qcom/camss/camss-csid-gen4.c
index 4ff2f41f70f7..bc52e4a1135c 100644
--- a/drivers/media/platform/qcom/camss/camss-csid-gen4.c
+++ b/drivers/media/platform/qcom/camss/camss-csid-gen4.c
@@ -63,6 +63,8 @@
#define CSI2_RX_CFG0_NUM_ACTIVE_LANES 0
#define CSI2_RX_CFG0_DL0_INPUT_SEL 4
#define CSI2_RX_CFG0_PHY_NUM_SEL 20
+#define CSI2_RX_CFG0_TPG_MUX_EN BIT(27)
+#define CSI2_RX_CFG0_TPG_MUX_SEL GENMASK(29, 28)
#define CSI2_RX_CFG0_PHY_SEL_BASE_IDX 1
#define CSID_CSI2_RX_CFG1 0x884
#define CSI2_RX_CFG1_ECC_CORRECTION_EN BIT(0)
@@ -140,12 +142,21 @@ static void __csid_reg_update(struct csid_device *csid, int port_id)
static void __csid_configure_rx(struct csid_device *csid,
struct csid_phy_config *phy)
{
+ struct camss *camss = csid->camss;
int val;
val = (phy->lane_cnt - 1) << CSI2_RX_CFG0_NUM_ACTIVE_LANES;
val |= phy->lane_assign << CSI2_RX_CFG0_DL0_INPUT_SEL;
- val |= (phy->csiphy_id + CSI2_RX_CFG0_PHY_SEL_BASE_IDX)
- << CSI2_RX_CFG0_PHY_NUM_SEL;
+
+ if (camss->tpg && csid->tpg_linked &&
+ camss->tpg[phy->csiphy_id].testgen.mode != TPG_PAYLOAD_MODE_DISABLED) {
+ val |= FIELD_PREP(CSI2_RX_CFG0_TPG_MUX_SEL, phy->csiphy_id + 1);
+ val |= CSI2_RX_CFG0_TPG_MUX_EN;
+ } else {
+ val |= (phy->csiphy_id + CSI2_RX_CFG0_PHY_SEL_BASE_IDX)
+ << CSI2_RX_CFG0_PHY_NUM_SEL;
+ }
+
writel(val, csid->base + CSID_CSI2_RX_CFG0);
val = CSI2_RX_CFG1_ECC_CORRECTION_EN;
diff --git a/drivers/media/platform/qcom/camss/camss-tpg-gen1.c b/drivers/media/platform/qcom/camss/camss-tpg-gen1.c
index d29de5f93c18..770a9e5d5ba5 100644
--- a/drivers/media/platform/qcom/camss/camss-tpg-gen1.c
+++ b/drivers/media/platform/qcom/camss/camss-tpg-gen1.c
@@ -22,6 +22,7 @@
#define TPG_HW_VER_2_0_0 TPG_HW_VER(2, 0, 0)
#define TPG_HW_VER_2_1_0 TPG_HW_VER(2, 1, 0)
+#define TPG_HW_VER_2_4_0 TPG_HW_VER(2, 4, 0)
#define TPG_HW_STATUS 0x4
@@ -33,7 +34,9 @@
# define TPG_CTRL_OVERLAP_SHDR_EN BIT(10)
# define TPG_CTRL_NUM_ACTIVE_VC GENMASK(31, 30)
-#define TPG_CLEAR 0x1F4
+#define TPG_CTRL_CMD 0x1F4
+# define TPG_CTRL_CMD_TEST_EN BIT(4)
+# define TPG_CTRL_CMD_HW_RESET BIT(0)
/* TPG VC-based registers */
#define TPG_VC_n_GAIN_CFG(n) (0x60 + (n) * 0x60)
@@ -164,18 +167,30 @@ static int tpg_stream_on(struct tpg_device *tpg)
}
/* Global TPG control */
- val = FIELD_PREP(TPG_CTRL_TEST_EN, 1) |
- FIELD_PREP(TPG_CTRL_NUM_ACTIVE_LANES, lane_cnt - 1) |
+ val = FIELD_PREP(TPG_CTRL_NUM_ACTIVE_LANES, lane_cnt - 1) |
FIELD_PREP(TPG_CTRL_NUM_ACTIVE_VC, last_vc);
- writel(val, tpg->base + TPG_CTRL);
+
+ if (tpg->hw_version >= TPG_HW_VER_2_4_0) {
+ writel(val, tpg->base + TPG_CTRL);
+ writel(TPG_CTRL_CMD_TEST_EN, tpg->base + TPG_CTRL_CMD);
+ } else {
+ val |= FIELD_PREP(TPG_CTRL_TEST_EN, 1);
+ writel(val, tpg->base + TPG_CTRL);
+ }
return 0;
}
static int tpg_reset(struct tpg_device *tpg)
{
- writel(0, tpg->base + TPG_CTRL);
- writel(1, tpg->base + TPG_CLEAR);
+ /*
+ * On TPG older than v2.4.0 test-enable lives in TPG_CTRL, so clear it
+ * first; v2.4.0+ drives both test-enable and reset through TPG_CTRL_CMD.
+ */
+ if (tpg->hw_version < TPG_HW_VER_2_4_0)
+ writel(0, tpg->base + TPG_CTRL);
+
+ writel(TPG_CTRL_CMD_HW_RESET, tpg->base + TPG_CTRL_CMD);
return 0;
}
diff --git a/drivers/media/platform/qcom/camss/camss.c b/drivers/media/platform/qcom/camss/camss.c
index 2f835cf2e32e..a14947a7ac89 100644
--- a/drivers/media/platform/qcom/camss/camss.c
+++ b/drivers/media/platform/qcom/camss/camss.c
@@ -5793,11 +5793,13 @@ static const struct camss_resources kaanapali_resources = {
.version = CAMSS_KAANAPALI,
.pd_name = "top",
.csiphy_res = csiphy_res_kaanapali,
+ .tpg_res = tpg_res_x1e80100,
.csid_res = csid_res_kaanapali,
.vfe_res = vfe_res_kaanapali,
.icc_res = icc_res_kaanapali,
.icc_path_num = ARRAY_SIZE(icc_res_kaanapali),
.csiphy_num = ARRAY_SIZE(csiphy_res_kaanapali),
+ .tpg_num = ARRAY_SIZE(tpg_res_x1e80100),
.csid_num = ARRAY_SIZE(csid_res_kaanapali),
.vfe_num = ARRAY_SIZE(vfe_res_kaanapali),
};
--
2.34.1
^ permalink raw reply related [flat|nested] 58+ messages in thread
* [PATCH v17 08/11] media: qcom: camss: tpg: Add support for v2.4.0 TPG
@ 2026-09-29 6:00 ` Hangxiang Ma
0 siblings, 0 replies; 58+ messages in thread
From: Hangxiang Ma @ 2026-09-29 6:00 UTC (permalink / raw)
To: Bryan O'Donoghue, Vinod Koul, Neil Armstrong,
Manivannan Sadhasivam, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Bryan O'Donoghue, Vladimir Zapolskiy,
Loic Poulain, Mauro Carvalho Chehab, Bjorn Andersson,
Konrad Dybcio, Abel Vesa
Cc: linux-phy, linux-media, linux-arm-msm, devicetree, linux-kernel,
jeyaprakash.soundrapandian, Vijay Kumar Tumati, Hangxiang Ma
Add support for the TPG found on Kaanapali. This TPG uses hardware
version 2.4.0, which drives test-enable and reset through a separate
TPG_CTRL_CMD register instead of TPG_CTRL, and routes its output into
the CSID gen4 RX via the CSI2 TPG mux.
Signed-off-by: Hangxiang Ma <hangxiang.ma@oss.qualcomm.com>
---
.../media/platform/qcom/camss/camss-csid-gen4.c | 15 ++++++++++--
drivers/media/platform/qcom/camss/camss-tpg-gen1.c | 27 +++++++++++++++++-----
drivers/media/platform/qcom/camss/camss.c | 2 ++
3 files changed, 36 insertions(+), 8 deletions(-)
diff --git a/drivers/media/platform/qcom/camss/camss-csid-gen4.c b/drivers/media/platform/qcom/camss/camss-csid-gen4.c
index 4ff2f41f70f7..bc52e4a1135c 100644
--- a/drivers/media/platform/qcom/camss/camss-csid-gen4.c
+++ b/drivers/media/platform/qcom/camss/camss-csid-gen4.c
@@ -63,6 +63,8 @@
#define CSI2_RX_CFG0_NUM_ACTIVE_LANES 0
#define CSI2_RX_CFG0_DL0_INPUT_SEL 4
#define CSI2_RX_CFG0_PHY_NUM_SEL 20
+#define CSI2_RX_CFG0_TPG_MUX_EN BIT(27)
+#define CSI2_RX_CFG0_TPG_MUX_SEL GENMASK(29, 28)
#define CSI2_RX_CFG0_PHY_SEL_BASE_IDX 1
#define CSID_CSI2_RX_CFG1 0x884
#define CSI2_RX_CFG1_ECC_CORRECTION_EN BIT(0)
@@ -140,12 +142,21 @@ static void __csid_reg_update(struct csid_device *csid, int port_id)
static void __csid_configure_rx(struct csid_device *csid,
struct csid_phy_config *phy)
{
+ struct camss *camss = csid->camss;
int val;
val = (phy->lane_cnt - 1) << CSI2_RX_CFG0_NUM_ACTIVE_LANES;
val |= phy->lane_assign << CSI2_RX_CFG0_DL0_INPUT_SEL;
- val |= (phy->csiphy_id + CSI2_RX_CFG0_PHY_SEL_BASE_IDX)
- << CSI2_RX_CFG0_PHY_NUM_SEL;
+
+ if (camss->tpg && csid->tpg_linked &&
+ camss->tpg[phy->csiphy_id].testgen.mode != TPG_PAYLOAD_MODE_DISABLED) {
+ val |= FIELD_PREP(CSI2_RX_CFG0_TPG_MUX_SEL, phy->csiphy_id + 1);
+ val |= CSI2_RX_CFG0_TPG_MUX_EN;
+ } else {
+ val |= (phy->csiphy_id + CSI2_RX_CFG0_PHY_SEL_BASE_IDX)
+ << CSI2_RX_CFG0_PHY_NUM_SEL;
+ }
+
writel(val, csid->base + CSID_CSI2_RX_CFG0);
val = CSI2_RX_CFG1_ECC_CORRECTION_EN;
diff --git a/drivers/media/platform/qcom/camss/camss-tpg-gen1.c b/drivers/media/platform/qcom/camss/camss-tpg-gen1.c
index d29de5f93c18..770a9e5d5ba5 100644
--- a/drivers/media/platform/qcom/camss/camss-tpg-gen1.c
+++ b/drivers/media/platform/qcom/camss/camss-tpg-gen1.c
@@ -22,6 +22,7 @@
#define TPG_HW_VER_2_0_0 TPG_HW_VER(2, 0, 0)
#define TPG_HW_VER_2_1_0 TPG_HW_VER(2, 1, 0)
+#define TPG_HW_VER_2_4_0 TPG_HW_VER(2, 4, 0)
#define TPG_HW_STATUS 0x4
@@ -33,7 +34,9 @@
# define TPG_CTRL_OVERLAP_SHDR_EN BIT(10)
# define TPG_CTRL_NUM_ACTIVE_VC GENMASK(31, 30)
-#define TPG_CLEAR 0x1F4
+#define TPG_CTRL_CMD 0x1F4
+# define TPG_CTRL_CMD_TEST_EN BIT(4)
+# define TPG_CTRL_CMD_HW_RESET BIT(0)
/* TPG VC-based registers */
#define TPG_VC_n_GAIN_CFG(n) (0x60 + (n) * 0x60)
@@ -164,18 +167,30 @@ static int tpg_stream_on(struct tpg_device *tpg)
}
/* Global TPG control */
- val = FIELD_PREP(TPG_CTRL_TEST_EN, 1) |
- FIELD_PREP(TPG_CTRL_NUM_ACTIVE_LANES, lane_cnt - 1) |
+ val = FIELD_PREP(TPG_CTRL_NUM_ACTIVE_LANES, lane_cnt - 1) |
FIELD_PREP(TPG_CTRL_NUM_ACTIVE_VC, last_vc);
- writel(val, tpg->base + TPG_CTRL);
+
+ if (tpg->hw_version >= TPG_HW_VER_2_4_0) {
+ writel(val, tpg->base + TPG_CTRL);
+ writel(TPG_CTRL_CMD_TEST_EN, tpg->base + TPG_CTRL_CMD);
+ } else {
+ val |= FIELD_PREP(TPG_CTRL_TEST_EN, 1);
+ writel(val, tpg->base + TPG_CTRL);
+ }
return 0;
}
static int tpg_reset(struct tpg_device *tpg)
{
- writel(0, tpg->base + TPG_CTRL);
- writel(1, tpg->base + TPG_CLEAR);
+ /*
+ * On TPG older than v2.4.0 test-enable lives in TPG_CTRL, so clear it
+ * first; v2.4.0+ drives both test-enable and reset through TPG_CTRL_CMD.
+ */
+ if (tpg->hw_version < TPG_HW_VER_2_4_0)
+ writel(0, tpg->base + TPG_CTRL);
+
+ writel(TPG_CTRL_CMD_HW_RESET, tpg->base + TPG_CTRL_CMD);
return 0;
}
diff --git a/drivers/media/platform/qcom/camss/camss.c b/drivers/media/platform/qcom/camss/camss.c
index 2f835cf2e32e..a14947a7ac89 100644
--- a/drivers/media/platform/qcom/camss/camss.c
+++ b/drivers/media/platform/qcom/camss/camss.c
@@ -5793,11 +5793,13 @@ static const struct camss_resources kaanapali_resources = {
.version = CAMSS_KAANAPALI,
.pd_name = "top",
.csiphy_res = csiphy_res_kaanapali,
+ .tpg_res = tpg_res_x1e80100,
.csid_res = csid_res_kaanapali,
.vfe_res = vfe_res_kaanapali,
.icc_res = icc_res_kaanapali,
.icc_path_num = ARRAY_SIZE(icc_res_kaanapali),
.csiphy_num = ARRAY_SIZE(csiphy_res_kaanapali),
+ .tpg_num = ARRAY_SIZE(tpg_res_x1e80100),
.csid_num = ARRAY_SIZE(csid_res_kaanapali),
.vfe_num = ARRAY_SIZE(vfe_res_kaanapali),
};
--
2.34.1
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply related [flat|nested] 58+ messages in thread
* [PATCH v17 09/11] arm64: dts: qcom: kaanapali: Add CAMSS and CSIPHY block definitions
2026-09-29 6:00 ` Hangxiang Ma
@ 2026-09-29 6:00 ` Hangxiang Ma
-1 siblings, 0 replies; 58+ messages in thread
From: Hangxiang Ma @ 2026-09-29 6:00 UTC (permalink / raw)
To: Bryan O'Donoghue, Vinod Koul, Neil Armstrong,
Manivannan Sadhasivam, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Bryan O'Donoghue, Vladimir Zapolskiy,
Loic Poulain, Mauro Carvalho Chehab, Bjorn Andersson,
Konrad Dybcio, Abel Vesa
Cc: linux-phy, linux-media, linux-arm-msm, devicetree, linux-kernel,
jeyaprakash.soundrapandian, Vijay Kumar Tumati, Hangxiang Ma
Describe the CAMSS and CSIPHY blocks on Kaanapali so that camera pipelines
can be enabled by board device trees.
The camera subsystem contains:
- 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
Signed-off-by: Hangxiang Ma <hangxiang.ma@oss.qualcomm.com>
---
arch/arm64/boot/dts/qcom/kaanapali.dtsi | 324 ++++++++++++++++++++++++++++++++
1 file changed, 324 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/kaanapali.dtsi b/arch/arm64/boot/dts/qcom/kaanapali.dtsi
index 3e63e6225108..7a80438bde57 100644
--- a/arch/arm64/boot/dts/qcom/kaanapali.dtsi
+++ b/arch/arm64/boot/dts/qcom/kaanapali.dtsi
@@ -20,6 +20,7 @@
#include <dt-bindings/interconnect/qcom,kaanapali-rpmh.h>
#include <dt-bindings/interrupt-controller/arm-gic.h>
#include <dt-bindings/mailbox/qcom-ipcc.h>
+#include <dt-bindings/phy/phy.h>
#include <dt-bindings/phy/phy-qcom-qmp.h>
#include <dt-bindings/power/qcom-rpmpd.h>
#include <dt-bindings/regulator/qcom,rpmh-regulator.h>
@@ -3595,6 +3596,307 @@ usb_dp_qmpphy_dp_in: endpoint {
};
};
+ camss: isp@9253000 {
+ compatible = "qcom,kaanapali-camss";
+
+ reg = <0x0 0x09253000 0x0 0x5e80>,
+ <0x0 0x09263000 0x0 0x5e80>,
+ <0x0 0x09273000 0x0 0x5e80>,
+ <0x0 0x092d3000 0x0 0x3880>,
+ <0x0 0x092e7000 0x0 0x3880>,
+ <0x0 0x093fd000 0x0 0x400>,
+ <0x0 0x093fe000 0x0 0x400>,
+ <0x0 0x093ff000 0x0 0x400>,
+ <0x0 0x09151000 0x0 0x20000>,
+ <0x0 0x09171000 0x0 0x20000>,
+ <0x0 0x09191000 0x0 0x20000>,
+ <0x0 0x092dc000 0x0 0x1300>,
+ <0x0 0x092f0000 0x0 0x1300>;
+
+ reg-names = "csid0",
+ "csid1",
+ "csid2",
+ "csid_lite0",
+ "csid_lite1",
+ "csitpg0",
+ "csitpg1",
+ "csitpg2",
+ "vfe0",
+ "vfe1",
+ "vfe2",
+ "vfe_lite0",
+ "vfe_lite1";
+
+ clocks = <&camcc CAM_CC_CAMNOC_NRT_AXI_CLK>,
+ <&camcc CAM_CC_CAMNOC_RT_AXI_CLK>,
+ <&camcc CAM_CC_CAM_TOP_AHB_CLK>,
+ <&camcc CAM_CC_CAM_TOP_FAST_AHB_CLK>,
+ <&camcc CAM_CC_CAMNOC_RT_TFE_0_MAIN_CLK>,
+ <&camcc CAM_CC_CAMNOC_RT_TFE_1_MAIN_CLK>,
+ <&camcc CAM_CC_CAMNOC_RT_TFE_2_MAIN_CLK>,
+ <&camcc CAM_CC_CAMNOC_RT_IFE_LITE_CLK>,
+ <&camcc CAM_CC_CSID_CLK>,
+ <&camcc CAM_CC_CSID_CSIPHY_RX_CLK>,
+ <&gcc GCC_CAMERA_HF_AXI_CLK>,
+ <&gcc GCC_CAMERA_SF_AXI_CLK>,
+ <&camcc CAM_CC_TFE_0_MAIN_CLK>,
+ <&camcc CAM_CC_TFE_0_MAIN_FAST_AHB_CLK>,
+ <&camcc CAM_CC_TFE_1_MAIN_CLK>,
+ <&camcc CAM_CC_TFE_1_MAIN_FAST_AHB_CLK>,
+ <&camcc CAM_CC_TFE_2_MAIN_CLK>,
+ <&camcc CAM_CC_TFE_2_MAIN_FAST_AHB_CLK>,
+ <&camcc CAM_CC_IFE_LITE_CLK>,
+ <&camcc CAM_CC_IFE_LITE_AHB_CLK>,
+ <&camcc CAM_CC_IFE_LITE_CPHY_RX_CLK>,
+ <&camcc CAM_CC_IFE_LITE_CSID_CLK>,
+ <&camcc CAM_CC_QDSS_DEBUG_XO_CLK>;
+
+ clock-names = "camnoc_nrt_axi",
+ "camnoc_rt_axi",
+ "cpas_ahb",
+ "cpas_fast_ahb",
+ "cpas_vfe0",
+ "cpas_vfe1",
+ "cpas_vfe2",
+ "cpas_vfe_lite",
+ "csid",
+ "csid_csiphy_rx",
+ "gcc_axi_hf",
+ "gcc_axi_sf",
+ "vfe0",
+ "vfe0_fast_ahb",
+ "vfe1",
+ "vfe1_fast_ahb",
+ "vfe2",
+ "vfe2_fast_ahb",
+ "vfe_lite",
+ "vfe_lite_ahb",
+ "vfe_lite_cphy_rx",
+ "vfe_lite_csid",
+ "qdss_debug_xo";
+
+ interrupts = <GIC_SPI 601 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 603 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 431 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 605 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 376 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 433 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 436 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 457 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 606 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 377 IRQ_TYPE_EDGE_RISING>;
+
+ interrupt-names = "csid0",
+ "csid1",
+ "csid2",
+ "csid_lite0",
+ "csid_lite1",
+ "vfe0",
+ "vfe1",
+ "vfe2",
+ "vfe_lite0",
+ "vfe_lite1";
+
+ interconnects = <&gem_noc MASTER_APPSS_PROC QCOM_ICC_TAG_ACTIVE_ONLY
+ &config_noc SLAVE_CAMERA_CFG QCOM_ICC_TAG_ACTIVE_ONLY>,
+ <&mmss_noc MASTER_CAMNOC_HF QCOM_ICC_TAG_ALWAYS
+ &mc_virt SLAVE_EBI1 QCOM_ICC_TAG_ALWAYS>;
+ interconnect-names = "ahb",
+ "hf_mnoc";
+
+ iommus = <&apps_smmu 0x1c00 0x00>;
+
+ power-domains = <&camcc CAM_CC_TFE_0_GDSC>,
+ <&camcc CAM_CC_TFE_1_GDSC>,
+ <&camcc CAM_CC_TFE_2_GDSC>,
+ <&camcc CAM_CC_TITAN_TOP_GDSC>;
+ power-domain-names = "ife0",
+ "ife1",
+ "ife2",
+ "top";
+
+ status = "disabled";
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+ };
+
+ port@1 {
+ reg = <1>;
+ };
+
+ port@2 {
+ reg = <2>;
+ };
+
+ port@3 {
+ reg = <3>;
+ };
+
+ port@4 {
+ reg = <4>;
+ };
+
+ port@5 {
+ reg = <5>;
+ };
+ };
+ };
+
+ csiphy0: phy@9523000 {
+ compatible = "qcom,kaanapali-csi2-phy";
+ reg = <0x0 0x09523000 0x0 0x2000>;
+
+ clocks = <&camcc CAM_CC_CSIPHY0_CLK>,
+ <&camcc CAM_CC_CSI0PHYTIMER_CLK>,
+ <&camcc CAM_CC_CORE_AHB_CLK>;
+ clock-names = "core",
+ "timer",
+ "ahb";
+
+ interrupts = <GIC_SPI 477 IRQ_TYPE_EDGE_RISING>;
+
+ operating-points-v2 = <&csiphy_mxc_opp_table>;
+
+ power-domains = <&camcc CAM_CC_TITAN_TOP_GDSC>,
+ <&rpmhpd RPMHPD_MMCX>,
+ <&rpmhpd RPMHPD_MXC>;
+ power-domain-names = "top",
+ "mmcx",
+ "mx";
+
+ status = "disabled";
+ };
+
+ csiphy1: phy@9525000 {
+ compatible = "qcom,kaanapali-csi2-phy";
+ reg = <0x0 0x09525000 0x0 0x2000>;
+
+ clocks = <&camcc CAM_CC_CSIPHY1_CLK>,
+ <&camcc CAM_CC_CSI1PHYTIMER_CLK>,
+ <&camcc CAM_CC_CORE_AHB_CLK>;
+ clock-names = "core",
+ "timer",
+ "ahb";
+
+ interrupts = <GIC_SPI 478 IRQ_TYPE_EDGE_RISING>;
+
+ operating-points-v2 = <&csiphy_mxc_opp_table>;
+
+ power-domains = <&camcc CAM_CC_TITAN_TOP_GDSC>,
+ <&rpmhpd RPMHPD_MMCX>,
+ <&rpmhpd RPMHPD_MXC>;
+ power-domain-names = "top",
+ "mmcx",
+ "mx";
+
+ status = "disabled";
+ };
+
+ csiphy2: phy@9527000 {
+ compatible = "qcom,kaanapali-csi2-phy";
+ reg = <0x0 0x09527000 0x0 0x2000>;
+
+ clocks = <&camcc CAM_CC_CSIPHY2_CLK>,
+ <&camcc CAM_CC_CSI2PHYTIMER_CLK>,
+ <&camcc CAM_CC_CORE_AHB_CLK>;
+ clock-names = "core",
+ "timer",
+ "ahb";
+
+ interrupts = <GIC_SPI 479 IRQ_TYPE_EDGE_RISING>;
+
+ operating-points-v2 = <&csiphy_mxc_opp_table>;
+
+ power-domains = <&camcc CAM_CC_TITAN_TOP_GDSC>,
+ <&rpmhpd RPMHPD_MMCX>,
+ <&rpmhpd RPMHPD_MXC>;
+ power-domain-names = "top",
+ "mmcx",
+ "mx";
+
+ status = "disabled";
+ };
+
+ csiphy3: phy@9529000 {
+ compatible = "qcom,kaanapali-csi2-phy";
+ reg = <0x0 0x09529000 0x0 0x2000>;
+
+ clocks = <&camcc CAM_CC_CSIPHY3_CLK>,
+ <&camcc CAM_CC_CSI3PHYTIMER_CLK>,
+ <&camcc CAM_CC_CORE_AHB_CLK>;
+ clock-names = "core",
+ "timer",
+ "ahb";
+
+ interrupts = <GIC_SPI 448 IRQ_TYPE_EDGE_RISING>;
+
+ operating-points-v2 = <&csiphy_mxc_opp_table>;
+
+ power-domains = <&camcc CAM_CC_TITAN_TOP_GDSC>,
+ <&rpmhpd RPMHPD_MMCX>,
+ <&rpmhpd RPMHPD_MXC>;
+ power-domain-names = "top",
+ "mmcx",
+ "mx";
+
+ status = "disabled";
+ };
+
+ csiphy4: phy@952b000 {
+ compatible = "qcom,kaanapali-csi2-phy";
+ reg = <0x0 0x0952b000 0x0 0x2000>;
+
+ clocks = <&camcc CAM_CC_CSIPHY4_CLK>,
+ <&camcc CAM_CC_CSI4PHYTIMER_CLK>,
+ <&camcc CAM_CC_CORE_AHB_CLK>;
+ clock-names = "core",
+ "timer",
+ "ahb";
+
+ interrupts = <GIC_SPI 122 IRQ_TYPE_EDGE_RISING>;
+
+ operating-points-v2 = <&csiphy_mxc_opp_table>;
+
+ power-domains = <&camcc CAM_CC_TITAN_TOP_GDSC>,
+ <&rpmhpd RPMHPD_MMCX>,
+ <&rpmhpd RPMHPD_MXC>;
+ power-domain-names = "top",
+ "mmcx",
+ "mx";
+
+ status = "disabled";
+ };
+
+ csiphy5: phy@952d000 {
+ compatible = "qcom,kaanapali-csi2-phy";
+ reg = <0x0 0x0952d000 0x0 0x2000>;
+
+ clocks = <&camcc CAM_CC_CSIPHY5_CLK>,
+ <&camcc CAM_CC_CSI5PHYTIMER_CLK>,
+ <&camcc CAM_CC_CORE_AHB_CLK>;
+ clock-names = "core",
+ "timer",
+ "ahb";
+
+ interrupts = <GIC_SPI 89 IRQ_TYPE_EDGE_RISING>;
+
+ operating-points-v2 = <&csiphy_mxc_opp_table>;
+
+ power-domains = <&camcc CAM_CC_TITAN_TOP_GDSC>,
+ <&rpmhpd RPMHPD_MMCX>,
+ <&rpmhpd RPMHPD_MXC>;
+ power-domain-names = "top",
+ "mmcx",
+ "mx";
+
+ status = "disabled";
+ };
+
camcc: clock-controller@956d000 {
compatible = "qcom,kaanapali-camcc";
reg = <0x0 0x0956d000 0x0 0x80000>;
@@ -6546,6 +6848,28 @@ pdp_tx: scp-sram-section@100 {
};
};
+ csiphy_mxc_opp_table: opp-table-mxc {
+ compatible = "operating-points-v2";
+
+ opp-300000000 {
+ opp-hz = /bits/ 64 <300000000>;
+ required-opps = <&rpmhpd_opp_low_svs_d1>,
+ <&rpmhpd_opp_low_svs_d1>;
+ };
+
+ opp-400000000 {
+ opp-hz = /bits/ 64 <400000000>;
+ required-opps = <&rpmhpd_opp_low_svs>,
+ <&rpmhpd_opp_low_svs>;
+ };
+
+ opp-480000000 {
+ opp-hz = /bits/ 64 <480000000>;
+ required-opps = <&rpmhpd_opp_low_svs>,
+ <&rpmhpd_opp_low_svs>;
+ };
+ };
+
thermal-zones {
cpullc-0-0-thermal {
thermal-sensors = <&tsens0 0>;
--
2.34.1
^ permalink raw reply related [flat|nested] 58+ messages in thread
* [PATCH v17 09/11] arm64: dts: qcom: kaanapali: Add CAMSS and CSIPHY block definitions
@ 2026-09-29 6:00 ` Hangxiang Ma
0 siblings, 0 replies; 58+ messages in thread
From: Hangxiang Ma @ 2026-09-29 6:00 UTC (permalink / raw)
To: Bryan O'Donoghue, Vinod Koul, Neil Armstrong,
Manivannan Sadhasivam, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Bryan O'Donoghue, Vladimir Zapolskiy,
Loic Poulain, Mauro Carvalho Chehab, Bjorn Andersson,
Konrad Dybcio, Abel Vesa
Cc: linux-phy, linux-media, linux-arm-msm, devicetree, linux-kernel,
jeyaprakash.soundrapandian, Vijay Kumar Tumati, Hangxiang Ma
Describe the CAMSS and CSIPHY blocks on Kaanapali so that camera pipelines
can be enabled by board device trees.
The camera subsystem contains:
- 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
Signed-off-by: Hangxiang Ma <hangxiang.ma@oss.qualcomm.com>
---
arch/arm64/boot/dts/qcom/kaanapali.dtsi | 324 ++++++++++++++++++++++++++++++++
1 file changed, 324 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/kaanapali.dtsi b/arch/arm64/boot/dts/qcom/kaanapali.dtsi
index 3e63e6225108..7a80438bde57 100644
--- a/arch/arm64/boot/dts/qcom/kaanapali.dtsi
+++ b/arch/arm64/boot/dts/qcom/kaanapali.dtsi
@@ -20,6 +20,7 @@
#include <dt-bindings/interconnect/qcom,kaanapali-rpmh.h>
#include <dt-bindings/interrupt-controller/arm-gic.h>
#include <dt-bindings/mailbox/qcom-ipcc.h>
+#include <dt-bindings/phy/phy.h>
#include <dt-bindings/phy/phy-qcom-qmp.h>
#include <dt-bindings/power/qcom-rpmpd.h>
#include <dt-bindings/regulator/qcom,rpmh-regulator.h>
@@ -3595,6 +3596,307 @@ usb_dp_qmpphy_dp_in: endpoint {
};
};
+ camss: isp@9253000 {
+ compatible = "qcom,kaanapali-camss";
+
+ reg = <0x0 0x09253000 0x0 0x5e80>,
+ <0x0 0x09263000 0x0 0x5e80>,
+ <0x0 0x09273000 0x0 0x5e80>,
+ <0x0 0x092d3000 0x0 0x3880>,
+ <0x0 0x092e7000 0x0 0x3880>,
+ <0x0 0x093fd000 0x0 0x400>,
+ <0x0 0x093fe000 0x0 0x400>,
+ <0x0 0x093ff000 0x0 0x400>,
+ <0x0 0x09151000 0x0 0x20000>,
+ <0x0 0x09171000 0x0 0x20000>,
+ <0x0 0x09191000 0x0 0x20000>,
+ <0x0 0x092dc000 0x0 0x1300>,
+ <0x0 0x092f0000 0x0 0x1300>;
+
+ reg-names = "csid0",
+ "csid1",
+ "csid2",
+ "csid_lite0",
+ "csid_lite1",
+ "csitpg0",
+ "csitpg1",
+ "csitpg2",
+ "vfe0",
+ "vfe1",
+ "vfe2",
+ "vfe_lite0",
+ "vfe_lite1";
+
+ clocks = <&camcc CAM_CC_CAMNOC_NRT_AXI_CLK>,
+ <&camcc CAM_CC_CAMNOC_RT_AXI_CLK>,
+ <&camcc CAM_CC_CAM_TOP_AHB_CLK>,
+ <&camcc CAM_CC_CAM_TOP_FAST_AHB_CLK>,
+ <&camcc CAM_CC_CAMNOC_RT_TFE_0_MAIN_CLK>,
+ <&camcc CAM_CC_CAMNOC_RT_TFE_1_MAIN_CLK>,
+ <&camcc CAM_CC_CAMNOC_RT_TFE_2_MAIN_CLK>,
+ <&camcc CAM_CC_CAMNOC_RT_IFE_LITE_CLK>,
+ <&camcc CAM_CC_CSID_CLK>,
+ <&camcc CAM_CC_CSID_CSIPHY_RX_CLK>,
+ <&gcc GCC_CAMERA_HF_AXI_CLK>,
+ <&gcc GCC_CAMERA_SF_AXI_CLK>,
+ <&camcc CAM_CC_TFE_0_MAIN_CLK>,
+ <&camcc CAM_CC_TFE_0_MAIN_FAST_AHB_CLK>,
+ <&camcc CAM_CC_TFE_1_MAIN_CLK>,
+ <&camcc CAM_CC_TFE_1_MAIN_FAST_AHB_CLK>,
+ <&camcc CAM_CC_TFE_2_MAIN_CLK>,
+ <&camcc CAM_CC_TFE_2_MAIN_FAST_AHB_CLK>,
+ <&camcc CAM_CC_IFE_LITE_CLK>,
+ <&camcc CAM_CC_IFE_LITE_AHB_CLK>,
+ <&camcc CAM_CC_IFE_LITE_CPHY_RX_CLK>,
+ <&camcc CAM_CC_IFE_LITE_CSID_CLK>,
+ <&camcc CAM_CC_QDSS_DEBUG_XO_CLK>;
+
+ clock-names = "camnoc_nrt_axi",
+ "camnoc_rt_axi",
+ "cpas_ahb",
+ "cpas_fast_ahb",
+ "cpas_vfe0",
+ "cpas_vfe1",
+ "cpas_vfe2",
+ "cpas_vfe_lite",
+ "csid",
+ "csid_csiphy_rx",
+ "gcc_axi_hf",
+ "gcc_axi_sf",
+ "vfe0",
+ "vfe0_fast_ahb",
+ "vfe1",
+ "vfe1_fast_ahb",
+ "vfe2",
+ "vfe2_fast_ahb",
+ "vfe_lite",
+ "vfe_lite_ahb",
+ "vfe_lite_cphy_rx",
+ "vfe_lite_csid",
+ "qdss_debug_xo";
+
+ interrupts = <GIC_SPI 601 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 603 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 431 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 605 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 376 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 433 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 436 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 457 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 606 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 377 IRQ_TYPE_EDGE_RISING>;
+
+ interrupt-names = "csid0",
+ "csid1",
+ "csid2",
+ "csid_lite0",
+ "csid_lite1",
+ "vfe0",
+ "vfe1",
+ "vfe2",
+ "vfe_lite0",
+ "vfe_lite1";
+
+ interconnects = <&gem_noc MASTER_APPSS_PROC QCOM_ICC_TAG_ACTIVE_ONLY
+ &config_noc SLAVE_CAMERA_CFG QCOM_ICC_TAG_ACTIVE_ONLY>,
+ <&mmss_noc MASTER_CAMNOC_HF QCOM_ICC_TAG_ALWAYS
+ &mc_virt SLAVE_EBI1 QCOM_ICC_TAG_ALWAYS>;
+ interconnect-names = "ahb",
+ "hf_mnoc";
+
+ iommus = <&apps_smmu 0x1c00 0x00>;
+
+ power-domains = <&camcc CAM_CC_TFE_0_GDSC>,
+ <&camcc CAM_CC_TFE_1_GDSC>,
+ <&camcc CAM_CC_TFE_2_GDSC>,
+ <&camcc CAM_CC_TITAN_TOP_GDSC>;
+ power-domain-names = "ife0",
+ "ife1",
+ "ife2",
+ "top";
+
+ status = "disabled";
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+ };
+
+ port@1 {
+ reg = <1>;
+ };
+
+ port@2 {
+ reg = <2>;
+ };
+
+ port@3 {
+ reg = <3>;
+ };
+
+ port@4 {
+ reg = <4>;
+ };
+
+ port@5 {
+ reg = <5>;
+ };
+ };
+ };
+
+ csiphy0: phy@9523000 {
+ compatible = "qcom,kaanapali-csi2-phy";
+ reg = <0x0 0x09523000 0x0 0x2000>;
+
+ clocks = <&camcc CAM_CC_CSIPHY0_CLK>,
+ <&camcc CAM_CC_CSI0PHYTIMER_CLK>,
+ <&camcc CAM_CC_CORE_AHB_CLK>;
+ clock-names = "core",
+ "timer",
+ "ahb";
+
+ interrupts = <GIC_SPI 477 IRQ_TYPE_EDGE_RISING>;
+
+ operating-points-v2 = <&csiphy_mxc_opp_table>;
+
+ power-domains = <&camcc CAM_CC_TITAN_TOP_GDSC>,
+ <&rpmhpd RPMHPD_MMCX>,
+ <&rpmhpd RPMHPD_MXC>;
+ power-domain-names = "top",
+ "mmcx",
+ "mx";
+
+ status = "disabled";
+ };
+
+ csiphy1: phy@9525000 {
+ compatible = "qcom,kaanapali-csi2-phy";
+ reg = <0x0 0x09525000 0x0 0x2000>;
+
+ clocks = <&camcc CAM_CC_CSIPHY1_CLK>,
+ <&camcc CAM_CC_CSI1PHYTIMER_CLK>,
+ <&camcc CAM_CC_CORE_AHB_CLK>;
+ clock-names = "core",
+ "timer",
+ "ahb";
+
+ interrupts = <GIC_SPI 478 IRQ_TYPE_EDGE_RISING>;
+
+ operating-points-v2 = <&csiphy_mxc_opp_table>;
+
+ power-domains = <&camcc CAM_CC_TITAN_TOP_GDSC>,
+ <&rpmhpd RPMHPD_MMCX>,
+ <&rpmhpd RPMHPD_MXC>;
+ power-domain-names = "top",
+ "mmcx",
+ "mx";
+
+ status = "disabled";
+ };
+
+ csiphy2: phy@9527000 {
+ compatible = "qcom,kaanapali-csi2-phy";
+ reg = <0x0 0x09527000 0x0 0x2000>;
+
+ clocks = <&camcc CAM_CC_CSIPHY2_CLK>,
+ <&camcc CAM_CC_CSI2PHYTIMER_CLK>,
+ <&camcc CAM_CC_CORE_AHB_CLK>;
+ clock-names = "core",
+ "timer",
+ "ahb";
+
+ interrupts = <GIC_SPI 479 IRQ_TYPE_EDGE_RISING>;
+
+ operating-points-v2 = <&csiphy_mxc_opp_table>;
+
+ power-domains = <&camcc CAM_CC_TITAN_TOP_GDSC>,
+ <&rpmhpd RPMHPD_MMCX>,
+ <&rpmhpd RPMHPD_MXC>;
+ power-domain-names = "top",
+ "mmcx",
+ "mx";
+
+ status = "disabled";
+ };
+
+ csiphy3: phy@9529000 {
+ compatible = "qcom,kaanapali-csi2-phy";
+ reg = <0x0 0x09529000 0x0 0x2000>;
+
+ clocks = <&camcc CAM_CC_CSIPHY3_CLK>,
+ <&camcc CAM_CC_CSI3PHYTIMER_CLK>,
+ <&camcc CAM_CC_CORE_AHB_CLK>;
+ clock-names = "core",
+ "timer",
+ "ahb";
+
+ interrupts = <GIC_SPI 448 IRQ_TYPE_EDGE_RISING>;
+
+ operating-points-v2 = <&csiphy_mxc_opp_table>;
+
+ power-domains = <&camcc CAM_CC_TITAN_TOP_GDSC>,
+ <&rpmhpd RPMHPD_MMCX>,
+ <&rpmhpd RPMHPD_MXC>;
+ power-domain-names = "top",
+ "mmcx",
+ "mx";
+
+ status = "disabled";
+ };
+
+ csiphy4: phy@952b000 {
+ compatible = "qcom,kaanapali-csi2-phy";
+ reg = <0x0 0x0952b000 0x0 0x2000>;
+
+ clocks = <&camcc CAM_CC_CSIPHY4_CLK>,
+ <&camcc CAM_CC_CSI4PHYTIMER_CLK>,
+ <&camcc CAM_CC_CORE_AHB_CLK>;
+ clock-names = "core",
+ "timer",
+ "ahb";
+
+ interrupts = <GIC_SPI 122 IRQ_TYPE_EDGE_RISING>;
+
+ operating-points-v2 = <&csiphy_mxc_opp_table>;
+
+ power-domains = <&camcc CAM_CC_TITAN_TOP_GDSC>,
+ <&rpmhpd RPMHPD_MMCX>,
+ <&rpmhpd RPMHPD_MXC>;
+ power-domain-names = "top",
+ "mmcx",
+ "mx";
+
+ status = "disabled";
+ };
+
+ csiphy5: phy@952d000 {
+ compatible = "qcom,kaanapali-csi2-phy";
+ reg = <0x0 0x0952d000 0x0 0x2000>;
+
+ clocks = <&camcc CAM_CC_CSIPHY5_CLK>,
+ <&camcc CAM_CC_CSI5PHYTIMER_CLK>,
+ <&camcc CAM_CC_CORE_AHB_CLK>;
+ clock-names = "core",
+ "timer",
+ "ahb";
+
+ interrupts = <GIC_SPI 89 IRQ_TYPE_EDGE_RISING>;
+
+ operating-points-v2 = <&csiphy_mxc_opp_table>;
+
+ power-domains = <&camcc CAM_CC_TITAN_TOP_GDSC>,
+ <&rpmhpd RPMHPD_MMCX>,
+ <&rpmhpd RPMHPD_MXC>;
+ power-domain-names = "top",
+ "mmcx",
+ "mx";
+
+ status = "disabled";
+ };
+
camcc: clock-controller@956d000 {
compatible = "qcom,kaanapali-camcc";
reg = <0x0 0x0956d000 0x0 0x80000>;
@@ -6546,6 +6848,28 @@ pdp_tx: scp-sram-section@100 {
};
};
+ csiphy_mxc_opp_table: opp-table-mxc {
+ compatible = "operating-points-v2";
+
+ opp-300000000 {
+ opp-hz = /bits/ 64 <300000000>;
+ required-opps = <&rpmhpd_opp_low_svs_d1>,
+ <&rpmhpd_opp_low_svs_d1>;
+ };
+
+ opp-400000000 {
+ opp-hz = /bits/ 64 <400000000>;
+ required-opps = <&rpmhpd_opp_low_svs>,
+ <&rpmhpd_opp_low_svs>;
+ };
+
+ opp-480000000 {
+ opp-hz = /bits/ 64 <480000000>;
+ required-opps = <&rpmhpd_opp_low_svs>,
+ <&rpmhpd_opp_low_svs>;
+ };
+ };
+
thermal-zones {
cpullc-0-0-thermal {
thermal-sensors = <&tsens0 0>;
--
2.34.1
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply related [flat|nested] 58+ messages in thread
* [PATCH v17 10/11] arm64: dts: qcom: kaanapali: Add CCI controller nodes
2026-09-29 6:00 ` Hangxiang Ma
@ 2026-09-29 6:00 ` Hangxiang Ma
-1 siblings, 0 replies; 58+ messages in thread
From: Hangxiang Ma @ 2026-09-29 6:00 UTC (permalink / raw)
To: Bryan O'Donoghue, Vinod Koul, Neil Armstrong,
Manivannan Sadhasivam, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Bryan O'Donoghue, Vladimir Zapolskiy,
Loic Poulain, Mauro Carvalho Chehab, Bjorn Andersson,
Konrad Dybcio, Abel Vesa
Cc: linux-phy, linux-media, linux-arm-msm, devicetree, linux-kernel,
jeyaprakash.soundrapandian, Vijay Kumar Tumati, Hangxiang Ma
Add the three Camera Control Interface (CCI) controllers present on the
Kaanapali SoC. Each controller provides two I2C hosts used for camera
sensor control, so define the controller nodes and their pinctrl states.
The first bus has two CCI bus master pinouts:
cci_i2c_sda0 = gpio109
cci_i2c_scl0 = gpio110
cci_i2c_sda1 = gpio111
cci_i2c_scl1 = gpio112
The second bus has two CCI bus master pinouts:
cci_i2c_sda3 = gpio113
cci_i2c_scl3 = gpio114
cci_i2c_sda4 = gpio107
cci_i2c_scl4 = gpio160
The third bus has two CCI bus master pinouts:
cci_i2c_sda5 = gpio108
cci_i2c_scl5 = gpio149
cci_i2c_sda6 = gpio115
cci_i2c_scl6 = gpio116
Reviewed-by: Vladimir Zapolskiy <vladimir.zapolskiy@linaro.org>
Signed-off-by: Hangxiang Ma <hangxiang.ma@oss.qualcomm.com>
---
arch/arm64/boot/dts/qcom/kaanapali.dtsi | 303 ++++++++++++++++++++++++++++++++
1 file changed, 303 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/kaanapali.dtsi b/arch/arm64/boot/dts/qcom/kaanapali.dtsi
index 7a80438bde57..c19945bc438e 100644
--- a/arch/arm64/boot/dts/qcom/kaanapali.dtsi
+++ b/arch/arm64/boot/dts/qcom/kaanapali.dtsi
@@ -3747,6 +3747,117 @@ port@5 {
};
};
+ cci0: cci@941b000 {
+ compatible = "qcom,kaanapali-cci", "qcom,msm8996-cci";
+ reg = <0x0 0x0941b000 0x0 0x1000>;
+
+ interrupts = <GIC_SPI 426 IRQ_TYPE_EDGE_RISING>;
+
+ clocks = <&camcc CAM_CC_CAM_TOP_AHB_CLK>,
+ <&camcc CAM_CC_CCI_0_CLK>;
+ clock-names = "ahb",
+ "cci";
+
+ power-domains = <&camcc CAM_CC_TITAN_TOP_GDSC>;
+
+ pinctrl-0 = <&cci0_i2c0_default &cci0_i2c1_default>;
+ pinctrl-1 = <&cci0_i2c0_sleep &cci0_i2c1_sleep>;
+ pinctrl-names = "default", "sleep";
+
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ status = "disabled";
+
+ cci0_i2c0: i2c-bus@0 {
+ reg = <0>;
+ clock-frequency = <1000000>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
+
+ cci0_i2c1: i2c-bus@1 {
+ reg = <1>;
+ clock-frequency = <1000000>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
+ };
+
+ cci1: cci@941c000 {
+ compatible = "qcom,kaanapali-cci", "qcom,msm8996-cci";
+ reg = <0x0 0x0941c000 0x0 0x1000>;
+
+ interrupts = <GIC_SPI 427 IRQ_TYPE_EDGE_RISING>;
+
+ clocks = <&camcc CAM_CC_CAM_TOP_AHB_CLK>,
+ <&camcc CAM_CC_CCI_1_CLK>;
+ clock-names = "ahb",
+ "cci";
+
+ power-domains = <&camcc CAM_CC_TITAN_TOP_GDSC>;
+
+ pinctrl-0 = <&cci1_i2c0_default &cci1_i2c1_default>;
+ pinctrl-1 = <&cci1_i2c0_sleep &cci1_i2c1_sleep>;
+ pinctrl-names = "default", "sleep";
+
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ status = "disabled";
+
+ cci1_i2c0: i2c-bus@0 {
+ reg = <0>;
+ clock-frequency = <1000000>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
+
+ cci1_i2c1: i2c-bus@1 {
+ reg = <1>;
+ clock-frequency = <1000000>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
+ };
+
+ cci2: cci@941d000 {
+ compatible = "qcom,kaanapali-cci", "qcom,msm8996-cci";
+ reg = <0x0 0x0941d000 0x0 0x1000>;
+
+ interrupts = <GIC_SPI 428 IRQ_TYPE_EDGE_RISING>;
+
+ clocks = <&camcc CAM_CC_CAM_TOP_AHB_CLK>,
+ <&camcc CAM_CC_CCI_2_CLK>;
+ clock-names = "ahb",
+ "cci";
+
+ power-domains = <&camcc CAM_CC_TITAN_TOP_GDSC>;
+
+ pinctrl-0 = <&cci2_i2c0_default &cci2_i2c1_default>;
+ pinctrl-1 = <&cci2_i2c0_sleep &cci2_i2c1_sleep>;
+ pinctrl-names = "default", "sleep";
+
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ status = "disabled";
+
+ cci2_i2c0: i2c-bus@0 {
+ reg = <0>;
+ clock-frequency = <1000000>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
+
+ cci2_i2c1: i2c-bus@1 {
+ reg = <1>;
+ clock-frequency = <1000000>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
+ };
+
csiphy0: phy@9523000 {
compatible = "qcom,kaanapali-csi2-phy";
reg = <0x0 0x09523000 0x0 0x2000>;
@@ -4457,6 +4568,198 @@ tlmm: pinctrl@f100000 {
#interrupt-cells = <2>;
wakeup-parent = <&pdc>;
+ cci0_i2c0_default: cci0-i2c0-default-state {
+ scl-pins {
+ pins = "gpio110";
+ function = "cci_i2c_scl";
+ drive-strength = <2>;
+ bias-pull-up;
+ };
+
+ sda-pins {
+ pins = "gpio109";
+ function = "cci_i2c_sda";
+ drive-strength = <2>;
+ bias-pull-up;
+ };
+ };
+
+ cci0_i2c0_sleep: cci0-i2c0-sleep-state {
+ scl-pins {
+ pins = "gpio110";
+ function = "cci_i2c_scl";
+ drive-strength = <2>;
+ bias-pull-down;
+ };
+
+ sda-pins {
+ pins = "gpio109";
+ function = "cci_i2c_sda";
+ drive-strength = <2>;
+ bias-pull-down;
+ };
+ };
+
+ cci0_i2c1_default: cci0-i2c1-default-state {
+ scl-pins {
+ pins = "gpio112";
+ function = "cci_i2c_scl";
+ drive-strength = <2>;
+ bias-pull-up;
+ };
+
+ sda-pins {
+ pins = "gpio111";
+ function = "cci_i2c_sda";
+ drive-strength = <2>;
+ bias-pull-up;
+ };
+ };
+
+ cci0_i2c1_sleep: cci0-i2c1-sleep-state {
+ scl-pins {
+ pins = "gpio112";
+ function = "cci_i2c_scl";
+ drive-strength = <2>;
+ bias-pull-down;
+ };
+
+ sda-pins {
+ pins = "gpio111";
+ function = "cci_i2c_sda";
+ drive-strength = <2>;
+ bias-pull-down;
+ };
+ };
+
+ cci1_i2c0_default: cci1-i2c0-default-state {
+ scl-pins {
+ pins = "gpio114";
+ function = "cci_i2c_scl";
+ drive-strength = <2>;
+ bias-pull-up;
+ };
+
+ sda-pins {
+ pins = "gpio113";
+ function = "cci_i2c_sda";
+ drive-strength = <2>;
+ bias-pull-up;
+ };
+ };
+
+ cci1_i2c0_sleep: cci1-i2c0-sleep-state {
+ scl-pins {
+ pins = "gpio114";
+ function = "cci_i2c_scl";
+ drive-strength = <2>;
+ bias-pull-down;
+ };
+
+ sda-pins {
+ pins = "gpio113";
+ function = "cci_i2c_sda";
+ drive-strength = <2>;
+ bias-pull-down;
+ };
+ };
+
+ cci1_i2c1_default: cci1-i2c1-default-state {
+ scl-pins {
+ pins = "gpio160";
+ function = "cci_i2c_scl";
+ drive-strength = <2>;
+ bias-pull-up;
+ };
+
+ sda-pins {
+ pins = "gpio107";
+ function = "cci_i2c_sda";
+ drive-strength = <2>;
+ bias-pull-up;
+ };
+ };
+
+ cci1_i2c1_sleep: cci1-i2c1-sleep-state {
+ scl-pins {
+ pins = "gpio160";
+ function = "cci_i2c_scl";
+ drive-strength = <2>;
+ bias-pull-down;
+ };
+
+ sda-pins {
+ pins = "gpio107";
+ function = "cci_i2c_sda";
+ drive-strength = <2>;
+ bias-pull-down;
+ };
+ };
+
+ cci2_i2c0_default: cci2-i2c0-default-state {
+ scl-pins {
+ pins = "gpio149";
+ function = "cci_i2c_scl";
+ drive-strength = <2>;
+ bias-pull-up;
+ };
+
+ sda-pins {
+ pins = "gpio108";
+ function = "cci_i2c_sda";
+ drive-strength = <2>;
+ bias-pull-up;
+ };
+ };
+
+ cci2_i2c0_sleep: cci2-i2c0-sleep-state {
+ scl-pins {
+ pins = "gpio149";
+ function = "cci_i2c_scl";
+ drive-strength = <2>;
+ bias-pull-down;
+ };
+
+ sda-pins {
+ pins = "gpio108";
+ function = "cci_i2c_sda";
+ drive-strength = <2>;
+ bias-pull-down;
+ };
+ };
+
+ cci2_i2c1_default: cci2-i2c1-default-state {
+ scl-pins {
+ pins = "gpio116";
+ function = "cci_i2c_scl";
+ drive-strength = <2>;
+ bias-pull-up;
+ };
+
+ sda-pins {
+ pins = "gpio115";
+ function = "cci_i2c_sda";
+ drive-strength = <2>;
+ bias-pull-up;
+ };
+ };
+
+ cci2_i2c1_sleep: cci2-i2c1-sleep-state {
+ scl-pins {
+ pins = "gpio116";
+ function = "cci_i2c_scl";
+ drive-strength = <2>;
+ bias-pull-down;
+ };
+
+ sda-pins {
+ pins = "gpio115";
+ function = "cci_i2c_sda";
+ drive-strength = <2>;
+ bias-pull-down;
+ };
+ };
+
hub_i2c0_data_clk: hub-i2c0-data-clk-state {
/* SDA, SCL */
pins = "gpio66", "gpio67";
--
2.34.1
^ permalink raw reply related [flat|nested] 58+ messages in thread
* [PATCH v17 10/11] arm64: dts: qcom: kaanapali: Add CCI controller nodes
@ 2026-09-29 6:00 ` Hangxiang Ma
0 siblings, 0 replies; 58+ messages in thread
From: Hangxiang Ma @ 2026-09-29 6:00 UTC (permalink / raw)
To: Bryan O'Donoghue, Vinod Koul, Neil Armstrong,
Manivannan Sadhasivam, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Bryan O'Donoghue, Vladimir Zapolskiy,
Loic Poulain, Mauro Carvalho Chehab, Bjorn Andersson,
Konrad Dybcio, Abel Vesa
Cc: linux-phy, linux-media, linux-arm-msm, devicetree, linux-kernel,
jeyaprakash.soundrapandian, Vijay Kumar Tumati, Hangxiang Ma
Add the three Camera Control Interface (CCI) controllers present on the
Kaanapali SoC. Each controller provides two I2C hosts used for camera
sensor control, so define the controller nodes and their pinctrl states.
The first bus has two CCI bus master pinouts:
cci_i2c_sda0 = gpio109
cci_i2c_scl0 = gpio110
cci_i2c_sda1 = gpio111
cci_i2c_scl1 = gpio112
The second bus has two CCI bus master pinouts:
cci_i2c_sda3 = gpio113
cci_i2c_scl3 = gpio114
cci_i2c_sda4 = gpio107
cci_i2c_scl4 = gpio160
The third bus has two CCI bus master pinouts:
cci_i2c_sda5 = gpio108
cci_i2c_scl5 = gpio149
cci_i2c_sda6 = gpio115
cci_i2c_scl6 = gpio116
Reviewed-by: Vladimir Zapolskiy <vladimir.zapolskiy@linaro.org>
Signed-off-by: Hangxiang Ma <hangxiang.ma@oss.qualcomm.com>
---
arch/arm64/boot/dts/qcom/kaanapali.dtsi | 303 ++++++++++++++++++++++++++++++++
1 file changed, 303 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/kaanapali.dtsi b/arch/arm64/boot/dts/qcom/kaanapali.dtsi
index 7a80438bde57..c19945bc438e 100644
--- a/arch/arm64/boot/dts/qcom/kaanapali.dtsi
+++ b/arch/arm64/boot/dts/qcom/kaanapali.dtsi
@@ -3747,6 +3747,117 @@ port@5 {
};
};
+ cci0: cci@941b000 {
+ compatible = "qcom,kaanapali-cci", "qcom,msm8996-cci";
+ reg = <0x0 0x0941b000 0x0 0x1000>;
+
+ interrupts = <GIC_SPI 426 IRQ_TYPE_EDGE_RISING>;
+
+ clocks = <&camcc CAM_CC_CAM_TOP_AHB_CLK>,
+ <&camcc CAM_CC_CCI_0_CLK>;
+ clock-names = "ahb",
+ "cci";
+
+ power-domains = <&camcc CAM_CC_TITAN_TOP_GDSC>;
+
+ pinctrl-0 = <&cci0_i2c0_default &cci0_i2c1_default>;
+ pinctrl-1 = <&cci0_i2c0_sleep &cci0_i2c1_sleep>;
+ pinctrl-names = "default", "sleep";
+
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ status = "disabled";
+
+ cci0_i2c0: i2c-bus@0 {
+ reg = <0>;
+ clock-frequency = <1000000>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
+
+ cci0_i2c1: i2c-bus@1 {
+ reg = <1>;
+ clock-frequency = <1000000>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
+ };
+
+ cci1: cci@941c000 {
+ compatible = "qcom,kaanapali-cci", "qcom,msm8996-cci";
+ reg = <0x0 0x0941c000 0x0 0x1000>;
+
+ interrupts = <GIC_SPI 427 IRQ_TYPE_EDGE_RISING>;
+
+ clocks = <&camcc CAM_CC_CAM_TOP_AHB_CLK>,
+ <&camcc CAM_CC_CCI_1_CLK>;
+ clock-names = "ahb",
+ "cci";
+
+ power-domains = <&camcc CAM_CC_TITAN_TOP_GDSC>;
+
+ pinctrl-0 = <&cci1_i2c0_default &cci1_i2c1_default>;
+ pinctrl-1 = <&cci1_i2c0_sleep &cci1_i2c1_sleep>;
+ pinctrl-names = "default", "sleep";
+
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ status = "disabled";
+
+ cci1_i2c0: i2c-bus@0 {
+ reg = <0>;
+ clock-frequency = <1000000>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
+
+ cci1_i2c1: i2c-bus@1 {
+ reg = <1>;
+ clock-frequency = <1000000>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
+ };
+
+ cci2: cci@941d000 {
+ compatible = "qcom,kaanapali-cci", "qcom,msm8996-cci";
+ reg = <0x0 0x0941d000 0x0 0x1000>;
+
+ interrupts = <GIC_SPI 428 IRQ_TYPE_EDGE_RISING>;
+
+ clocks = <&camcc CAM_CC_CAM_TOP_AHB_CLK>,
+ <&camcc CAM_CC_CCI_2_CLK>;
+ clock-names = "ahb",
+ "cci";
+
+ power-domains = <&camcc CAM_CC_TITAN_TOP_GDSC>;
+
+ pinctrl-0 = <&cci2_i2c0_default &cci2_i2c1_default>;
+ pinctrl-1 = <&cci2_i2c0_sleep &cci2_i2c1_sleep>;
+ pinctrl-names = "default", "sleep";
+
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ status = "disabled";
+
+ cci2_i2c0: i2c-bus@0 {
+ reg = <0>;
+ clock-frequency = <1000000>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
+
+ cci2_i2c1: i2c-bus@1 {
+ reg = <1>;
+ clock-frequency = <1000000>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
+ };
+
csiphy0: phy@9523000 {
compatible = "qcom,kaanapali-csi2-phy";
reg = <0x0 0x09523000 0x0 0x2000>;
@@ -4457,6 +4568,198 @@ tlmm: pinctrl@f100000 {
#interrupt-cells = <2>;
wakeup-parent = <&pdc>;
+ cci0_i2c0_default: cci0-i2c0-default-state {
+ scl-pins {
+ pins = "gpio110";
+ function = "cci_i2c_scl";
+ drive-strength = <2>;
+ bias-pull-up;
+ };
+
+ sda-pins {
+ pins = "gpio109";
+ function = "cci_i2c_sda";
+ drive-strength = <2>;
+ bias-pull-up;
+ };
+ };
+
+ cci0_i2c0_sleep: cci0-i2c0-sleep-state {
+ scl-pins {
+ pins = "gpio110";
+ function = "cci_i2c_scl";
+ drive-strength = <2>;
+ bias-pull-down;
+ };
+
+ sda-pins {
+ pins = "gpio109";
+ function = "cci_i2c_sda";
+ drive-strength = <2>;
+ bias-pull-down;
+ };
+ };
+
+ cci0_i2c1_default: cci0-i2c1-default-state {
+ scl-pins {
+ pins = "gpio112";
+ function = "cci_i2c_scl";
+ drive-strength = <2>;
+ bias-pull-up;
+ };
+
+ sda-pins {
+ pins = "gpio111";
+ function = "cci_i2c_sda";
+ drive-strength = <2>;
+ bias-pull-up;
+ };
+ };
+
+ cci0_i2c1_sleep: cci0-i2c1-sleep-state {
+ scl-pins {
+ pins = "gpio112";
+ function = "cci_i2c_scl";
+ drive-strength = <2>;
+ bias-pull-down;
+ };
+
+ sda-pins {
+ pins = "gpio111";
+ function = "cci_i2c_sda";
+ drive-strength = <2>;
+ bias-pull-down;
+ };
+ };
+
+ cci1_i2c0_default: cci1-i2c0-default-state {
+ scl-pins {
+ pins = "gpio114";
+ function = "cci_i2c_scl";
+ drive-strength = <2>;
+ bias-pull-up;
+ };
+
+ sda-pins {
+ pins = "gpio113";
+ function = "cci_i2c_sda";
+ drive-strength = <2>;
+ bias-pull-up;
+ };
+ };
+
+ cci1_i2c0_sleep: cci1-i2c0-sleep-state {
+ scl-pins {
+ pins = "gpio114";
+ function = "cci_i2c_scl";
+ drive-strength = <2>;
+ bias-pull-down;
+ };
+
+ sda-pins {
+ pins = "gpio113";
+ function = "cci_i2c_sda";
+ drive-strength = <2>;
+ bias-pull-down;
+ };
+ };
+
+ cci1_i2c1_default: cci1-i2c1-default-state {
+ scl-pins {
+ pins = "gpio160";
+ function = "cci_i2c_scl";
+ drive-strength = <2>;
+ bias-pull-up;
+ };
+
+ sda-pins {
+ pins = "gpio107";
+ function = "cci_i2c_sda";
+ drive-strength = <2>;
+ bias-pull-up;
+ };
+ };
+
+ cci1_i2c1_sleep: cci1-i2c1-sleep-state {
+ scl-pins {
+ pins = "gpio160";
+ function = "cci_i2c_scl";
+ drive-strength = <2>;
+ bias-pull-down;
+ };
+
+ sda-pins {
+ pins = "gpio107";
+ function = "cci_i2c_sda";
+ drive-strength = <2>;
+ bias-pull-down;
+ };
+ };
+
+ cci2_i2c0_default: cci2-i2c0-default-state {
+ scl-pins {
+ pins = "gpio149";
+ function = "cci_i2c_scl";
+ drive-strength = <2>;
+ bias-pull-up;
+ };
+
+ sda-pins {
+ pins = "gpio108";
+ function = "cci_i2c_sda";
+ drive-strength = <2>;
+ bias-pull-up;
+ };
+ };
+
+ cci2_i2c0_sleep: cci2-i2c0-sleep-state {
+ scl-pins {
+ pins = "gpio149";
+ function = "cci_i2c_scl";
+ drive-strength = <2>;
+ bias-pull-down;
+ };
+
+ sda-pins {
+ pins = "gpio108";
+ function = "cci_i2c_sda";
+ drive-strength = <2>;
+ bias-pull-down;
+ };
+ };
+
+ cci2_i2c1_default: cci2-i2c1-default-state {
+ scl-pins {
+ pins = "gpio116";
+ function = "cci_i2c_scl";
+ drive-strength = <2>;
+ bias-pull-up;
+ };
+
+ sda-pins {
+ pins = "gpio115";
+ function = "cci_i2c_sda";
+ drive-strength = <2>;
+ bias-pull-up;
+ };
+ };
+
+ cci2_i2c1_sleep: cci2-i2c1-sleep-state {
+ scl-pins {
+ pins = "gpio116";
+ function = "cci_i2c_scl";
+ drive-strength = <2>;
+ bias-pull-down;
+ };
+
+ sda-pins {
+ pins = "gpio115";
+ function = "cci_i2c_sda";
+ drive-strength = <2>;
+ bias-pull-down;
+ };
+ };
+
hub_i2c0_data_clk: hub-i2c0-data-clk-state {
/* SDA, SCL */
pins = "gpio66", "gpio67";
--
2.34.1
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply related [flat|nested] 58+ messages in thread
* [PATCH v17 11/11] arm64: dts: qcom: kaanapali: Add camera MCLK pinctrl
2026-09-29 6:00 ` Hangxiang Ma
@ 2026-09-29 6:00 ` Hangxiang Ma
-1 siblings, 0 replies; 58+ messages in thread
From: Hangxiang Ma @ 2026-09-29 6:00 UTC (permalink / raw)
To: Bryan O'Donoghue, Vinod Koul, Neil Armstrong,
Manivannan Sadhasivam, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Bryan O'Donoghue, Vladimir Zapolskiy,
Loic Poulain, Mauro Carvalho Chehab, Bjorn Andersson,
Konrad Dybcio, Abel Vesa
Cc: linux-phy, linux-media, linux-arm-msm, devicetree, linux-kernel,
jeyaprakash.soundrapandian, Vijay Kumar Tumati, Hangxiang Ma,
Konrad Dybcio
Add TLMM pinctrl states for the camera master clock GPIOs on Kaanapali so
camera sensor nodes can select the proper MCLK pin functions when enabled.
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Reviewed-by: Vladimir Zapolskiy <vladimir.zapolskiy@linaro.org>
Signed-off-by: Hangxiang Ma <hangxiang.ma@oss.qualcomm.com>
---
arch/arm64/boot/dts/qcom/kaanapali.dtsi | 56 +++++++++++++++++++++++++++++++++
1 file changed, 56 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/kaanapali.dtsi b/arch/arm64/boot/dts/qcom/kaanapali.dtsi
index c19945bc438e..bbcd5a622f0b 100644
--- a/arch/arm64/boot/dts/qcom/kaanapali.dtsi
+++ b/arch/arm64/boot/dts/qcom/kaanapali.dtsi
@@ -4568,6 +4568,62 @@ tlmm: pinctrl@f100000 {
#interrupt-cells = <2>;
wakeup-parent = <&pdc>;
+ cam_mclk0_default: cam-mclk0-default-state {
+ pins = "gpio89";
+ function = "cam_mclk";
+ drive-strength = <2>;
+ bias-disable;
+ };
+
+ cam_mclk1_default: cam-mclk1-default-state {
+ pins = "gpio90";
+ function = "cam_mclk";
+ drive-strength = <2>;
+ bias-disable;
+ };
+
+ cam_mclk2_default: cam-mclk2-default-state {
+ pins = "gpio91";
+ function = "cam_asc_mclk2";
+ drive-strength = <2>;
+ bias-disable;
+ };
+
+ cam_mclk3_default: cam_mclk3-default-state {
+ pins = "gpio92";
+ function = "cam_mclk";
+ drive-strength = <2>;
+ bias-disable;
+ };
+
+ cam_mclk4_default: cam_mclk4-default-state {
+ pins = "gpio93";
+ function = "cam_asc_mclk4";
+ drive-strength = <2>;
+ bias-disable;
+ };
+
+ cam_mclk5_default: cam_mclk5-default-state {
+ pins = "gpio94";
+ function = "cam_mclk";
+ drive-strength = <2>;
+ bias-disable;
+ };
+
+ cam_mclk6_default: cam_mclk6-default-state {
+ pins = "gpio95";
+ function = "cam_mclk";
+ drive-strength = <2>;
+ bias-disable;
+ };
+
+ cam_mclk7_default: cam_mclk7-default-state {
+ pins = "gpio96";
+ function = "cam_mclk";
+ drive-strength = <2>;
+ bias-disable;
+ };
+
cci0_i2c0_default: cci0-i2c0-default-state {
scl-pins {
pins = "gpio110";
--
2.34.1
^ permalink raw reply related [flat|nested] 58+ messages in thread
* [PATCH v17 11/11] arm64: dts: qcom: kaanapali: Add camera MCLK pinctrl
@ 2026-09-29 6:00 ` Hangxiang Ma
0 siblings, 0 replies; 58+ messages in thread
From: Hangxiang Ma @ 2026-09-29 6:00 UTC (permalink / raw)
To: Bryan O'Donoghue, Vinod Koul, Neil Armstrong,
Manivannan Sadhasivam, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Bryan O'Donoghue, Vladimir Zapolskiy,
Loic Poulain, Mauro Carvalho Chehab, Bjorn Andersson,
Konrad Dybcio, Abel Vesa
Cc: linux-phy, linux-media, linux-arm-msm, devicetree, linux-kernel,
jeyaprakash.soundrapandian, Vijay Kumar Tumati, Hangxiang Ma,
Konrad Dybcio
Add TLMM pinctrl states for the camera master clock GPIOs on Kaanapali so
camera sensor nodes can select the proper MCLK pin functions when enabled.
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Reviewed-by: Vladimir Zapolskiy <vladimir.zapolskiy@linaro.org>
Signed-off-by: Hangxiang Ma <hangxiang.ma@oss.qualcomm.com>
---
arch/arm64/boot/dts/qcom/kaanapali.dtsi | 56 +++++++++++++++++++++++++++++++++
1 file changed, 56 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/kaanapali.dtsi b/arch/arm64/boot/dts/qcom/kaanapali.dtsi
index c19945bc438e..bbcd5a622f0b 100644
--- a/arch/arm64/boot/dts/qcom/kaanapali.dtsi
+++ b/arch/arm64/boot/dts/qcom/kaanapali.dtsi
@@ -4568,6 +4568,62 @@ tlmm: pinctrl@f100000 {
#interrupt-cells = <2>;
wakeup-parent = <&pdc>;
+ cam_mclk0_default: cam-mclk0-default-state {
+ pins = "gpio89";
+ function = "cam_mclk";
+ drive-strength = <2>;
+ bias-disable;
+ };
+
+ cam_mclk1_default: cam-mclk1-default-state {
+ pins = "gpio90";
+ function = "cam_mclk";
+ drive-strength = <2>;
+ bias-disable;
+ };
+
+ cam_mclk2_default: cam-mclk2-default-state {
+ pins = "gpio91";
+ function = "cam_asc_mclk2";
+ drive-strength = <2>;
+ bias-disable;
+ };
+
+ cam_mclk3_default: cam_mclk3-default-state {
+ pins = "gpio92";
+ function = "cam_mclk";
+ drive-strength = <2>;
+ bias-disable;
+ };
+
+ cam_mclk4_default: cam_mclk4-default-state {
+ pins = "gpio93";
+ function = "cam_asc_mclk4";
+ drive-strength = <2>;
+ bias-disable;
+ };
+
+ cam_mclk5_default: cam_mclk5-default-state {
+ pins = "gpio94";
+ function = "cam_mclk";
+ drive-strength = <2>;
+ bias-disable;
+ };
+
+ cam_mclk6_default: cam_mclk6-default-state {
+ pins = "gpio95";
+ function = "cam_mclk";
+ drive-strength = <2>;
+ bias-disable;
+ };
+
+ cam_mclk7_default: cam_mclk7-default-state {
+ pins = "gpio96";
+ function = "cam_mclk";
+ drive-strength = <2>;
+ bias-disable;
+ };
+
cci0_i2c0_default: cci0-i2c0-default-state {
scl-pins {
pins = "gpio110";
--
2.34.1
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply related [flat|nested] 58+ messages in thread
* Re: [PATCH v17 11/11] arm64: dts: qcom: kaanapali: Add camera MCLK pinctrl
2026-09-29 6:00 ` Hangxiang Ma
@ 2026-09-29 6:07 ` sashiko-bot
-1 siblings, 0 replies; 58+ messages in thread
From: sashiko-bot @ 2026-09-29 6:07 UTC (permalink / raw)
To: Hangxiang Ma
Cc: media-ci, robh, devicetree, vkoul, linux-phy, olteanv,
neil.armstrong, conor+dt
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Low] dts: devicetree node names incorrectly use underscores
--
commit 185a6cf958fbea99362a9e2c9f3989dad4362d3c
Author: Hangxiang Ma <hangxiang.ma@oss.qualcomm.com>
arm64: dts: qcom: kaanapali: Add camera MCLK pinctrl
This commit adds TLMM pinctrl states for the camera master clock GPIOs on
Kaanapali so camera sensor nodes can select the proper MCLK pin functions
when enabled.
> diff --git a/arch/arm64/boot/dts/qcom/kaanapali.dtsi b/arch/arm64/boot/dts/qcom/kaanapali.dtsi
> index c19945bc438eb..bbcd5a622f0b2 100644
> --- a/arch/arm64/boot/dts/qcom/kaanapali.dtsi
> +++ b/arch/arm64/boot/dts/qcom/kaanapali.dtsi
[ ... ]
> + cam_mclk2_default: cam-mclk2-default-state {
> + pins = "gpio91";
> + function = "cam_asc_mclk2";
> + drive-strength = <2>;
> + bias-disable;
> + };
> +
> + cam_mclk3_default: cam_mclk3-default-state {
[Severity: Low]
Does this node name incorrectly use an underscore instead of a hyphen?
Devicetree node names conventionally use hyphens rather than underscores.
The previous nodes like cam-mclk0-default-state use the correct hyphenated
pattern.
Using an underscore here and in the subsequent cam_mclk4 through cam_mclk7
nodes will trigger dtc style warnings (node_name_chars_strict) and fail
standard devicetree style checks.
> + pins = "gpio92";
> + function = "cam_mclk";
> + drive-strength = <2>;
> + bias-disable;
> + };
[ ... ]
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260928-kaanapali-camss-v17-0-dcf3fd37f76c@oss.qualcomm.com?part=11
^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: [PATCH v17 11/11] arm64: dts: qcom: kaanapali: Add camera MCLK pinctrl
@ 2026-09-29 6:07 ` sashiko-bot
0 siblings, 0 replies; 58+ messages in thread
From: sashiko-bot @ 2026-09-29 6:07 UTC (permalink / raw)
To: Hangxiang Ma
Cc: media-ci, robh, devicetree, vkoul, linux-phy, olteanv,
neil.armstrong, conor+dt
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Low] dts: devicetree node names incorrectly use underscores
--
commit 185a6cf958fbea99362a9e2c9f3989dad4362d3c
Author: Hangxiang Ma <hangxiang.ma@oss.qualcomm.com>
arm64: dts: qcom: kaanapali: Add camera MCLK pinctrl
This commit adds TLMM pinctrl states for the camera master clock GPIOs on
Kaanapali so camera sensor nodes can select the proper MCLK pin functions
when enabled.
> diff --git a/arch/arm64/boot/dts/qcom/kaanapali.dtsi b/arch/arm64/boot/dts/qcom/kaanapali.dtsi
> index c19945bc438eb..bbcd5a622f0b2 100644
> --- a/arch/arm64/boot/dts/qcom/kaanapali.dtsi
> +++ b/arch/arm64/boot/dts/qcom/kaanapali.dtsi
[ ... ]
> + cam_mclk2_default: cam-mclk2-default-state {
> + pins = "gpio91";
> + function = "cam_asc_mclk2";
> + drive-strength = <2>;
> + bias-disable;
> + };
> +
> + cam_mclk3_default: cam_mclk3-default-state {
[Severity: Low]
Does this node name incorrectly use an underscore instead of a hyphen?
Devicetree node names conventionally use hyphens rather than underscores.
The previous nodes like cam-mclk0-default-state use the correct hyphenated
pattern.
Using an underscore here and in the subsequent cam_mclk4 through cam_mclk7
nodes will trigger dtc style warnings (node_name_chars_strict) and fail
standard devicetree style checks.
> + pins = "gpio92";
> + function = "cam_mclk";
> + drive-strength = <2>;
> + bias-disable;
> + };
[ ... ]
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260928-kaanapali-camss-v17-0-dcf3fd37f76c@oss.qualcomm.com?part=11
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: [PATCH v17 02/11] media: dt-bindings: Add CAMSS device for Kaanapali
2026-09-29 6:00 ` Hangxiang Ma
@ 2026-09-29 6:08 ` sashiko-bot
-1 siblings, 0 replies; 58+ messages in thread
From: sashiko-bot @ 2026-09-29 6:08 UTC (permalink / raw)
To: Hangxiang Ma
Cc: linux-phy, olteanv, media-ci, vkoul, neil.armstrong, devicetree,
conor+dt, robh
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Low] media: dt-bindings: contradictory port count description vs schema
--
commit eaf675a1ac25eea3cc950df0432cfe59f97c1517
Author: Hangxiang Ma <hangxiang.ma@oss.qualcomm.com>
media: dt-bindings: Add CAMSS device for Kaanapali
Add bindings for Camera Subsystem (CAMSS) on the Qualcomm Kaanapali
platform.
> diff --git a/Documentation/devicetree/bindings/media/qcom,kaanapali-camss.yaml b/Documentation/devicetree/bindings/media/qcom,kaanapali-camss.yaml
> new file mode 100644
> index 0000000000000..1f8b18517e13a
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/media/qcom,kaanapali-camss.yaml
[ ... ]
> + power-domain-names:
> + items:
> + - const: ife0
> + - const: ife1
> + - const: ife2
> + - const: top
> +
> + ports:
> + $ref: /schemas/graph.yaml#/properties/ports
> +
> + description:
> + CSI input ports, one per CSID. Each port receives the CSI data
> + decoded by the matching CSIPHY.
> +
> + patternProperties:
> + "^port@[0-5]$":
> + $ref: /schemas/graph.yaml#/$defs/port-base
> + unevaluatedProperties: false
> + description:
> + Input port for receiving CSI data from CSIPHY 0-5.
[Severity: Low]
Could this description be updated to clarify the port count?
The commit message indicates the platform has 5 CSIDs (3 regular, 2 lite)
and 6 CSIPHYs. The top-level description for the ports node states there is
"one per CSID", which would imply 5 ports. However, the schema allows 6 ports
("^port@[0-5]$") and the nested description mentions receiving data from
CSIPHY 0-5.
Does the "one per CSID" text need to be updated to match the hardware layout
allowed by the schema?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260928-kaanapali-camss-v17-0-dcf3fd37f76c@oss.qualcomm.com?part=2
^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: [PATCH v17 02/11] media: dt-bindings: Add CAMSS device for Kaanapali
@ 2026-09-29 6:08 ` sashiko-bot
0 siblings, 0 replies; 58+ messages in thread
From: sashiko-bot @ 2026-09-29 6:08 UTC (permalink / raw)
To: Hangxiang Ma
Cc: linux-phy, olteanv, media-ci, vkoul, neil.armstrong, devicetree,
conor+dt, robh
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Low] media: dt-bindings: contradictory port count description vs schema
--
commit eaf675a1ac25eea3cc950df0432cfe59f97c1517
Author: Hangxiang Ma <hangxiang.ma@oss.qualcomm.com>
media: dt-bindings: Add CAMSS device for Kaanapali
Add bindings for Camera Subsystem (CAMSS) on the Qualcomm Kaanapali
platform.
> diff --git a/Documentation/devicetree/bindings/media/qcom,kaanapali-camss.yaml b/Documentation/devicetree/bindings/media/qcom,kaanapali-camss.yaml
> new file mode 100644
> index 0000000000000..1f8b18517e13a
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/media/qcom,kaanapali-camss.yaml
[ ... ]
> + power-domain-names:
> + items:
> + - const: ife0
> + - const: ife1
> + - const: ife2
> + - const: top
> +
> + ports:
> + $ref: /schemas/graph.yaml#/properties/ports
> +
> + description:
> + CSI input ports, one per CSID. Each port receives the CSI data
> + decoded by the matching CSIPHY.
> +
> + patternProperties:
> + "^port@[0-5]$":
> + $ref: /schemas/graph.yaml#/$defs/port-base
> + unevaluatedProperties: false
> + description:
> + Input port for receiving CSI data from CSIPHY 0-5.
[Severity: Low]
Could this description be updated to clarify the port count?
The commit message indicates the platform has 5 CSIDs (3 regular, 2 lite)
and 6 CSIPHYs. The top-level description for the ports node states there is
"one per CSID", which would imply 5 ports. However, the schema allows 6 ports
("^port@[0-5]$") and the nested description mentions receiving data from
CSIPHY 0-5.
Does the "one per CSID" text need to be updated to match the hardware layout
allowed by the schema?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260928-kaanapali-camss-v17-0-dcf3fd37f76c@oss.qualcomm.com?part=2
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: [PATCH v17 09/11] arm64: dts: qcom: kaanapali: Add CAMSS and CSIPHY block definitions
2026-09-29 6:00 ` Hangxiang Ma
@ 2026-09-29 6:11 ` sashiko-bot
-1 siblings, 0 replies; 58+ messages in thread
From: sashiko-bot @ 2026-09-29 6:11 UTC (permalink / raw)
To: Hangxiang Ma
Cc: linux-phy, robh, conor+dt, media-ci, vkoul, neil.armstrong,
devicetree, olteanv
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] dts: missing #phy-cells in CSIPHY nodes breaks phy lookup
--
commit 0d5dc943d2ac26c65efdf11a56970db1bd7ff6f9
Author: Hangxiang Ma <hangxiang.ma@oss.qualcomm.com>
arm64: dts: qcom: kaanapali: Add CAMSS and CSIPHY block definitions
This commit adds device tree nodes for the CAMSS and CSIPHY blocks on the
Kaanapali platform. These definitions enable camera pipelines to be configured
and used by board-specific device trees.
> diff --git a/arch/arm64/boot/dts/qcom/kaanapali.dtsi b/arch/arm64/boot/dts/qcom/kaanapali.dtsi
> index 3e63e62251089..7a80438bde570 100644
> --- a/arch/arm64/boot/dts/qcom/kaanapali.dtsi
> +++ b/arch/arm64/boot/dts/qcom/kaanapali.dtsi
[ ... ]
> @@ -3595,6 +3596,307 @@ usb_dp_qmpphy_dp_in: endpoint {
> };
> };
>
> + camss: isp@9253000 {
[ ... ]
> + csiphy0: phy@9523000 {
> + compatible = "qcom,kaanapali-csi2-phy";
> + reg = <0x0 0x09523000 0x0 0x2000>;
[Severity: Medium]
Does this node need a #phy-cells property? The generic PHY framework requires
this for consumers to successfully probe.
The qcom,kaanapali-csi2-phy compatible binds to a generic PHY provider via
devm_of_phy_provider_register(dev, of_phy_simple_xlate). When a consumer
calls phy_get(), the PHY core invokes of_parse_phandle_with_args() to parse
the reference.
Without #phy-cells = <0>; in this and the other csiphy nodes (csiphy0 through
csiphy5) in arch/arm64/boot/dts/qcom/kaanapali.dtsi, the translation will fail,
leaving the consumer devices non-functional.
> +
> + clocks = <&camcc CAM_CC_CSIPHY0_CLK>,
> + <&camcc CAM_CC_CSI0PHYTIMER_CLK>,
> + <&camcc CAM_CC_CORE_AHB_CLK>;
[ ... ]
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260928-kaanapali-camss-v17-0-dcf3fd37f76c@oss.qualcomm.com?part=9
^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: [PATCH v17 09/11] arm64: dts: qcom: kaanapali: Add CAMSS and CSIPHY block definitions
@ 2026-09-29 6:11 ` sashiko-bot
0 siblings, 0 replies; 58+ messages in thread
From: sashiko-bot @ 2026-09-29 6:11 UTC (permalink / raw)
To: Hangxiang Ma
Cc: linux-phy, robh, conor+dt, media-ci, vkoul, neil.armstrong,
devicetree, olteanv
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] dts: missing #phy-cells in CSIPHY nodes breaks phy lookup
--
commit 0d5dc943d2ac26c65efdf11a56970db1bd7ff6f9
Author: Hangxiang Ma <hangxiang.ma@oss.qualcomm.com>
arm64: dts: qcom: kaanapali: Add CAMSS and CSIPHY block definitions
This commit adds device tree nodes for the CAMSS and CSIPHY blocks on the
Kaanapali platform. These definitions enable camera pipelines to be configured
and used by board-specific device trees.
> diff --git a/arch/arm64/boot/dts/qcom/kaanapali.dtsi b/arch/arm64/boot/dts/qcom/kaanapali.dtsi
> index 3e63e62251089..7a80438bde570 100644
> --- a/arch/arm64/boot/dts/qcom/kaanapali.dtsi
> +++ b/arch/arm64/boot/dts/qcom/kaanapali.dtsi
[ ... ]
> @@ -3595,6 +3596,307 @@ usb_dp_qmpphy_dp_in: endpoint {
> };
> };
>
> + camss: isp@9253000 {
[ ... ]
> + csiphy0: phy@9523000 {
> + compatible = "qcom,kaanapali-csi2-phy";
> + reg = <0x0 0x09523000 0x0 0x2000>;
[Severity: Medium]
Does this node need a #phy-cells property? The generic PHY framework requires
this for consumers to successfully probe.
The qcom,kaanapali-csi2-phy compatible binds to a generic PHY provider via
devm_of_phy_provider_register(dev, of_phy_simple_xlate). When a consumer
calls phy_get(), the PHY core invokes of_parse_phandle_with_args() to parse
the reference.
Without #phy-cells = <0>; in this and the other csiphy nodes (csiphy0 through
csiphy5) in arch/arm64/boot/dts/qcom/kaanapali.dtsi, the translation will fail,
leaving the consumer devices non-functional.
> +
> + clocks = <&camcc CAM_CC_CSIPHY0_CLK>,
> + <&camcc CAM_CC_CSI0PHYTIMER_CLK>,
> + <&camcc CAM_CC_CORE_AHB_CLK>;
[ ... ]
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260928-kaanapali-camss-v17-0-dcf3fd37f76c@oss.qualcomm.com?part=9
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: [PATCH v17 08/11] media: qcom: camss: tpg: Add support for v2.4.0 TPG
2026-09-29 6:00 ` Hangxiang Ma
@ 2026-09-29 6:12 ` sashiko-bot
-1 siblings, 0 replies; 58+ messages in thread
From: sashiko-bot @ 2026-09-29 6:12 UTC (permalink / raw)
To: Hangxiang Ma
Cc: media-ci, neil.armstrong, devicetree, conor+dt, linux-phy,
olteanv, robh, vkoul
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] media: camss: uninitialized tpg->hw_version used in tpg_reset()
--
commit e2a0aed20f3751127d25b2596032eac51d537c58
Author: Hangxiang Ma <hangxiang.ma@oss.qualcomm.com>
media: qcom: camss: tpg: Add support for v2.4.0 TPG
This commit adds support for the TPG hardware version 2.4.0 found on
Kaanapali. It updates the configuration and reset logic to use the new
TPG_CTRL_CMD register instead of TPG_CTRL.
> diff --git a/drivers/media/platform/qcom/camss/camss-tpg-gen1.c b/drivers/media/platform/qcom/camss/camss-tpg-gen1.c
> index d29de5f93c18e..770a9e5d5ba5f 100644
> --- a/drivers/media/platform/qcom/camss/camss-tpg-gen1.c
> +++ b/drivers/media/platform/qcom/camss/camss-tpg-gen1.c
[ ... ]
> @@ -164,18 +167,30 @@ static int tpg_stream_on(struct tpg_device *tpg)
[ ... ]
> static int tpg_reset(struct tpg_device *tpg)
> {
> - writel(0, tpg->base + TPG_CTRL);
> - writel(1, tpg->base + TPG_CLEAR);
> + /*
> + * On TPG older than v2.4.0 test-enable lives in TPG_CTRL, so clear it
> + * first; v2.4.0+ drives both test-enable and reset through TPG_CTRL_CMD.
> + */
> + if (tpg->hw_version < TPG_HW_VER_2_4_0)
> + writel(0, tpg->base + TPG_CTRL);
[Severity: Medium]
Will this execute the legacy reset logic on v2.4.0+ hardware during the
first power-on sequence?
When the driver powers up the device, tpg_set_power() calls the reset
function before calling hw_version():
drivers/media/platform/qcom/camss/camss-tpg.c:tpg_set_power() {
...
tpg->res->hw_ops->reset(tpg);
tpg->res->hw_ops->hw_version(tpg);
...
}
Because the tpg object is zero-initialized and tpg->hw_version is not
populated until after the reset function is called, tpg->hw_version
is strictly 0 during the first execution of tpg_reset().
Does this mean the condition here evaluates to true for all hardware
versions on the initial power-up, inadvertently causing an unintended
write to TPG_CTRL?
> +
> + writel(TPG_CTRL_CMD_HW_RESET, tpg->base + TPG_CTRL_CMD);
>
> return 0;
> }
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260928-kaanapali-camss-v17-0-dcf3fd37f76c@oss.qualcomm.com?part=8
^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: [PATCH v17 08/11] media: qcom: camss: tpg: Add support for v2.4.0 TPG
@ 2026-09-29 6:12 ` sashiko-bot
0 siblings, 0 replies; 58+ messages in thread
From: sashiko-bot @ 2026-09-29 6:12 UTC (permalink / raw)
To: Hangxiang Ma
Cc: media-ci, neil.armstrong, devicetree, conor+dt, linux-phy,
olteanv, robh, vkoul
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] media: camss: uninitialized tpg->hw_version used in tpg_reset()
--
commit e2a0aed20f3751127d25b2596032eac51d537c58
Author: Hangxiang Ma <hangxiang.ma@oss.qualcomm.com>
media: qcom: camss: tpg: Add support for v2.4.0 TPG
This commit adds support for the TPG hardware version 2.4.0 found on
Kaanapali. It updates the configuration and reset logic to use the new
TPG_CTRL_CMD register instead of TPG_CTRL.
> diff --git a/drivers/media/platform/qcom/camss/camss-tpg-gen1.c b/drivers/media/platform/qcom/camss/camss-tpg-gen1.c
> index d29de5f93c18e..770a9e5d5ba5f 100644
> --- a/drivers/media/platform/qcom/camss/camss-tpg-gen1.c
> +++ b/drivers/media/platform/qcom/camss/camss-tpg-gen1.c
[ ... ]
> @@ -164,18 +167,30 @@ static int tpg_stream_on(struct tpg_device *tpg)
[ ... ]
> static int tpg_reset(struct tpg_device *tpg)
> {
> - writel(0, tpg->base + TPG_CTRL);
> - writel(1, tpg->base + TPG_CLEAR);
> + /*
> + * On TPG older than v2.4.0 test-enable lives in TPG_CTRL, so clear it
> + * first; v2.4.0+ drives both test-enable and reset through TPG_CTRL_CMD.
> + */
> + if (tpg->hw_version < TPG_HW_VER_2_4_0)
> + writel(0, tpg->base + TPG_CTRL);
[Severity: Medium]
Will this execute the legacy reset logic on v2.4.0+ hardware during the
first power-on sequence?
When the driver powers up the device, tpg_set_power() calls the reset
function before calling hw_version():
drivers/media/platform/qcom/camss/camss-tpg.c:tpg_set_power() {
...
tpg->res->hw_ops->reset(tpg);
tpg->res->hw_ops->hw_version(tpg);
...
}
Because the tpg object is zero-initialized and tpg->hw_version is not
populated until after the reset function is called, tpg->hw_version
is strictly 0 during the first execution of tpg_reset().
Does this mean the condition here evaluates to true for all hardware
versions on the initial power-up, inadvertently causing an unintended
write to TPG_CTRL?
> +
> + writel(TPG_CTRL_CMD_HW_RESET, tpg->base + TPG_CTRL_CMD);
>
> return 0;
> }
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260928-kaanapali-camss-v17-0-dcf3fd37f76c@oss.qualcomm.com?part=8
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: [PATCH v17 05/11] media: qcom: camss: csiphy: Add support for v2.4.0 two-phase CSIPHY
2026-09-29 6:00 ` Hangxiang Ma
@ 2026-09-29 6:17 ` sashiko-bot
-1 siblings, 0 replies; 58+ messages in thread
From: sashiko-bot @ 2026-09-29 6:17 UTC (permalink / raw)
To: Hangxiang Ma
Cc: vkoul, neil.armstrong, linux-phy, robh, olteanv, media-ci,
devicetree, conor+dt
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Critical] media: camss: guaranteed NULL pointer dereference in msm_csiphy_subdev_init()
--
commit 3c87101a27e8d1c1d3a64a10ed465e1ed433c549
Author: Hangxiang Ma <hangxiang.ma@oss.qualcomm.com>
media: qcom: camss: csiphy: Add support for v2.4.0 two-phase CSIPHY
Add support for the v2.4.0 two-phase CSIPHY found on Kaanapali, where
the PHY is driven by the standalone phy-qcom-mipi-csi2 DPHY driver
rather than by CAMSS. Add the mipi_csi2_dphy_3nm_kaanapali configuration,
which reuses the x1e80100 lane sequence, clocks and supplies but selects
the v2.4.0 common status offset, adding Kaanapali power domain and
register the "qcom,kaanapali-csi2-phy" compatible.
> diff --git a/drivers/media/platform/qcom/camss/camss.c b/drivers/media/platform/qcom/camss/camss.c
> index a528760487bd9..a0cd839c9948a 100644
> --- a/drivers/media/platform/qcom/camss/camss.c
> +++ b/drivers/media/platform/qcom/camss/camss.c
> @@ -34,6 +34,57 @@
>
> static const struct parent_dev_ops vfe_parent_dev_ops;
>
> +static const struct camss_subdev_resources csiphy_res_kaanapali[] = {
> + /* CSIPHY0 */
> + {
> + .csiphy = {
> + .id = 0,
> + .hw_ops = &csiphy_ops_3ph_1_0,
> + .formats = &csiphy_formats_sdm845
> + },
> + },
[Severity: Critical]
Can this result in a NULL pointer dereference during device probe?
Because this Kaanapali resource definition completely omits the .reg array, it
implicitly initializes to NULL. However, it still binds legacy hardware
operations (&csiphy_ops_3ph_1_0) that expect MMIO mappings.
When the CAMSS probe unconditionally iterates over all csiphy_num entries
and invokes msm_csiphy_subdev_init() for each, it attempts to map the legacy
register space:
drivers/media/platform/qcom/camss/camss-csiphy.c:msm_csiphy_subdev_init() {
...
csiphy->base = devm_platform_ioremap_resource_byname(pdev, res->reg[0]);
...
}
Because .reg was omitted, res->reg[0] is NULL, which propagates down to
platform_get_resource_byname(). Since Kaanapali defines other named resources,
evaluating strcmp(r->name, NULL) with a NULL name argument can cause a crash.
Does the standalone PHY need to be consumed via the kernel's generic PHY
framework (e.g., devm_phy_get) instead of retaining legacy CAMSS ops that
assume direct MMIO control?
[ ... ]
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260928-kaanapali-camss-v17-0-dcf3fd37f76c@oss.qualcomm.com?part=5
^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: [PATCH v17 05/11] media: qcom: camss: csiphy: Add support for v2.4.0 two-phase CSIPHY
@ 2026-09-29 6:17 ` sashiko-bot
0 siblings, 0 replies; 58+ messages in thread
From: sashiko-bot @ 2026-09-29 6:17 UTC (permalink / raw)
To: Hangxiang Ma
Cc: vkoul, neil.armstrong, linux-phy, robh, olteanv, media-ci,
devicetree, conor+dt
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Critical] media: camss: guaranteed NULL pointer dereference in msm_csiphy_subdev_init()
--
commit 3c87101a27e8d1c1d3a64a10ed465e1ed433c549
Author: Hangxiang Ma <hangxiang.ma@oss.qualcomm.com>
media: qcom: camss: csiphy: Add support for v2.4.0 two-phase CSIPHY
Add support for the v2.4.0 two-phase CSIPHY found on Kaanapali, where
the PHY is driven by the standalone phy-qcom-mipi-csi2 DPHY driver
rather than by CAMSS. Add the mipi_csi2_dphy_3nm_kaanapali configuration,
which reuses the x1e80100 lane sequence, clocks and supplies but selects
the v2.4.0 common status offset, adding Kaanapali power domain and
register the "qcom,kaanapali-csi2-phy" compatible.
> diff --git a/drivers/media/platform/qcom/camss/camss.c b/drivers/media/platform/qcom/camss/camss.c
> index a528760487bd9..a0cd839c9948a 100644
> --- a/drivers/media/platform/qcom/camss/camss.c
> +++ b/drivers/media/platform/qcom/camss/camss.c
> @@ -34,6 +34,57 @@
>
> static const struct parent_dev_ops vfe_parent_dev_ops;
>
> +static const struct camss_subdev_resources csiphy_res_kaanapali[] = {
> + /* CSIPHY0 */
> + {
> + .csiphy = {
> + .id = 0,
> + .hw_ops = &csiphy_ops_3ph_1_0,
> + .formats = &csiphy_formats_sdm845
> + },
> + },
[Severity: Critical]
Can this result in a NULL pointer dereference during device probe?
Because this Kaanapali resource definition completely omits the .reg array, it
implicitly initializes to NULL. However, it still binds legacy hardware
operations (&csiphy_ops_3ph_1_0) that expect MMIO mappings.
When the CAMSS probe unconditionally iterates over all csiphy_num entries
and invokes msm_csiphy_subdev_init() for each, it attempts to map the legacy
register space:
drivers/media/platform/qcom/camss/camss-csiphy.c:msm_csiphy_subdev_init() {
...
csiphy->base = devm_platform_ioremap_resource_byname(pdev, res->reg[0]);
...
}
Because .reg was omitted, res->reg[0] is NULL, which propagates down to
platform_get_resource_byname(). Since Kaanapali defines other named resources,
evaluating strcmp(r->name, NULL) with a NULL name argument can cause a crash.
Does the standalone PHY need to be consumed via the kernel's generic PHY
framework (e.g., devm_phy_get) instead of retaining legacy CAMSS ops that
assume direct MMIO control?
[ ... ]
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260928-kaanapali-camss-v17-0-dcf3fd37f76c@oss.qualcomm.com?part=5
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: [PATCH v17 06/11] media: qcom: camss: csid: Add support for CSID Gen4
2026-09-29 6:00 ` Hangxiang Ma
@ 2026-09-29 6:17 ` sashiko-bot
-1 siblings, 0 replies; 58+ messages in thread
From: sashiko-bot @ 2026-09-29 6:17 UTC (permalink / raw)
To: Hangxiang Ma
Cc: neil.armstrong, vkoul, devicetree, linux-phy, media-ci, robh,
olteanv, conor+dt
Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [High] media: qcom/camss: data race on csid->aup_update and rup_update
- [Medium] media: qcom/camss: integer underflow in __csid_configure_rx
--
commit 611abdeb4b5da574ae292d1ff736d0d71f2f4ed2
Author: Hangxiang Ma <hangxiang.ma@oss.qualcomm.com>
media: qcom: camss: csid: Add support for CSID Gen4
Add support for the CSID Gen4 hardware found on Kaanapali SoC.
Introduce Gen4 resource descriptions and implement the hardware-specific
register programming, reset sequence, and BUF_DONE interrupt handling.
Gen4 splits RUP and AUP updates into separate registers and uses a SET
register to commit the updates. Update the CSID interface to support
both this scheme and the legacy combined reg_update mechanism.
> diff --git a/drivers/media/platform/qcom/camss/camss-csid-gen4.c b/drivers/media/platform/qcom/camss/camss-csid-gen4.c
> new file mode 100644
> index 0000000000000..4ff2f41f70f7e
> --- /dev/null
> +++ b/drivers/media/platform/qcom/camss/camss-csid-gen4.c
[ ... ]
> +static void __csid_aup_rup_clear(struct csid_device *csid, int port_id)
> +{
> + /* Hardware clears the registers upon consuming the settings */
> + csid->aup_update &= ~CSID_RUP_AUP_RDI(port_id);
> + csid->rup_update &= ~CSID_RUP_AUP_RDI(port_id);
> +}
> +
> +static void __csid_aup_update(struct csid_device *csid, int port_id)
> +{
> + csid->aup_update |= CSID_RUP_AUP_RDI(port_id);
> + writel(csid->aup_update, csid->base + CSID_AUP_CMD);
> +
> + __csid_aup_rup_trigger(csid);
> +}
> +
> +static void __csid_reg_update(struct csid_device *csid, int port_id)
> +{
> + csid->rup_update |= CSID_RUP_AUP_RDI(port_id);
> + writel(csid->rup_update, csid->base + CSID_RUP_CMD);
> +
> + __csid_aup_rup_trigger(csid);
> +}
[Severity: High]
Does this introduce a data race on csid->aup_update and csid->rup_update?
If a stream is configured in process context via csid_set_stream(),
__csid_aup_update() and __csid_reg_update() modify the shared state with
non-atomic bitwise operations (|=).
If an interrupt (such as RUP_DONE) fires concurrently for an already running
stream, csid_isr() will execute and call __csid_aup_rup_clear(), which modifies
the same variables using non-atomic bitwise clear operations (&= ~).
Because these bitwise operations lack locking, could the interrupt's
modifications be lost, causing the hardware to receive an invalid AUP/RUP
command mask? This might lead to broken streaming when dynamically configuring
multiple virtual channels.
> +
> +static void __csid_configure_rx(struct csid_device *csid,
> + struct csid_phy_config *phy)
> +{
> + int val;
> +
> + val = (phy->lane_cnt - 1) << CSI2_RX_CFG0_NUM_ACTIVE_LANES;
> + val |= phy->lane_assign << CSI2_RX_CFG0_DL0_INPUT_SEL;
> + val |= (phy->csiphy_id + CSI2_RX_CFG0_PHY_SEL_BASE_IDX)
> + << CSI2_RX_CFG0_PHY_NUM_SEL;
> + writel(val, csid->base + CSID_CSI2_RX_CFG0);
[Severity: Medium]
Can this code underflow if phy->lane_cnt is 0?
If the device tree incorrectly omits the data-lanes property, phy->lane_cnt can
evaluate to 0.
While __csid_configure_rdi_stream() provides a fallback for this scenario:
if (!lane_cnt)
lane_cnt = 4;
__csid_configure_rx() omits this check. If phy->lane_cnt is 0,
(phy->lane_cnt - 1) underflows to -1. This would result in writing 0xFFFFFFFF
to CSID_CSI2_RX_CFG0, clobbering all its fields.
Should there be a similar fallback or validation check here to prevent
hardware misconfiguration?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260928-kaanapali-camss-v17-0-dcf3fd37f76c@oss.qualcomm.com?part=6
^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: [PATCH v17 06/11] media: qcom: camss: csid: Add support for CSID Gen4
@ 2026-09-29 6:17 ` sashiko-bot
0 siblings, 0 replies; 58+ messages in thread
From: sashiko-bot @ 2026-09-29 6:17 UTC (permalink / raw)
To: Hangxiang Ma
Cc: neil.armstrong, vkoul, devicetree, linux-phy, media-ci, robh,
olteanv, conor+dt
Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [High] media: qcom/camss: data race on csid->aup_update and rup_update
- [Medium] media: qcom/camss: integer underflow in __csid_configure_rx
--
commit 611abdeb4b5da574ae292d1ff736d0d71f2f4ed2
Author: Hangxiang Ma <hangxiang.ma@oss.qualcomm.com>
media: qcom: camss: csid: Add support for CSID Gen4
Add support for the CSID Gen4 hardware found on Kaanapali SoC.
Introduce Gen4 resource descriptions and implement the hardware-specific
register programming, reset sequence, and BUF_DONE interrupt handling.
Gen4 splits RUP and AUP updates into separate registers and uses a SET
register to commit the updates. Update the CSID interface to support
both this scheme and the legacy combined reg_update mechanism.
> diff --git a/drivers/media/platform/qcom/camss/camss-csid-gen4.c b/drivers/media/platform/qcom/camss/camss-csid-gen4.c
> new file mode 100644
> index 0000000000000..4ff2f41f70f7e
> --- /dev/null
> +++ b/drivers/media/platform/qcom/camss/camss-csid-gen4.c
[ ... ]
> +static void __csid_aup_rup_clear(struct csid_device *csid, int port_id)
> +{
> + /* Hardware clears the registers upon consuming the settings */
> + csid->aup_update &= ~CSID_RUP_AUP_RDI(port_id);
> + csid->rup_update &= ~CSID_RUP_AUP_RDI(port_id);
> +}
> +
> +static void __csid_aup_update(struct csid_device *csid, int port_id)
> +{
> + csid->aup_update |= CSID_RUP_AUP_RDI(port_id);
> + writel(csid->aup_update, csid->base + CSID_AUP_CMD);
> +
> + __csid_aup_rup_trigger(csid);
> +}
> +
> +static void __csid_reg_update(struct csid_device *csid, int port_id)
> +{
> + csid->rup_update |= CSID_RUP_AUP_RDI(port_id);
> + writel(csid->rup_update, csid->base + CSID_RUP_CMD);
> +
> + __csid_aup_rup_trigger(csid);
> +}
[Severity: High]
Does this introduce a data race on csid->aup_update and csid->rup_update?
If a stream is configured in process context via csid_set_stream(),
__csid_aup_update() and __csid_reg_update() modify the shared state with
non-atomic bitwise operations (|=).
If an interrupt (such as RUP_DONE) fires concurrently for an already running
stream, csid_isr() will execute and call __csid_aup_rup_clear(), which modifies
the same variables using non-atomic bitwise clear operations (&= ~).
Because these bitwise operations lack locking, could the interrupt's
modifications be lost, causing the hardware to receive an invalid AUP/RUP
command mask? This might lead to broken streaming when dynamically configuring
multiple virtual channels.
> +
> +static void __csid_configure_rx(struct csid_device *csid,
> + struct csid_phy_config *phy)
> +{
> + int val;
> +
> + val = (phy->lane_cnt - 1) << CSI2_RX_CFG0_NUM_ACTIVE_LANES;
> + val |= phy->lane_assign << CSI2_RX_CFG0_DL0_INPUT_SEL;
> + val |= (phy->csiphy_id + CSI2_RX_CFG0_PHY_SEL_BASE_IDX)
> + << CSI2_RX_CFG0_PHY_NUM_SEL;
> + writel(val, csid->base + CSID_CSI2_RX_CFG0);
[Severity: Medium]
Can this code underflow if phy->lane_cnt is 0?
If the device tree incorrectly omits the data-lanes property, phy->lane_cnt can
evaluate to 0.
While __csid_configure_rdi_stream() provides a fallback for this scenario:
if (!lane_cnt)
lane_cnt = 4;
__csid_configure_rx() omits this check. If phy->lane_cnt is 0,
(phy->lane_cnt - 1) underflows to -1. This would result in writing 0xFFFFFFFF
to CSID_CSI2_RX_CFG0, clobbering all its fields.
Should there be a similar fallback or validation check here to prevent
hardware misconfiguration?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260928-kaanapali-camss-v17-0-dcf3fd37f76c@oss.qualcomm.com?part=6
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: [PATCH v17 07/11] media: qcom: camss: vfe: Add support for VFE Gen4
2026-09-29 6:00 ` Hangxiang Ma
@ 2026-09-29 6:17 ` sashiko-bot
-1 siblings, 0 replies; 58+ messages in thread
From: sashiko-bot @ 2026-09-29 6:17 UTC (permalink / raw)
To: Hangxiang Ma
Cc: conor+dt, vkoul, devicetree, olteanv, neil.armstrong, linux-phy,
robh, media-ci
Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [High] camss: hardware constraint violation due to unconditional AUP_UPDATE loop in CSID
- [High] camss: subsystem API violation where IFE Lite's 4th RDI line is incorrectly configured as PIX
--
commit def99c6cf972d2305c4c27701233f42e411f7857
Author: Hangxiang Ma <hangxiang.ma@oss.qualcomm.com>
media: qcom: camss: vfe: Add support for VFE Gen4
This commit adds support for the VFE Gen4 (TFE) found on the Kaanapali SoC.
It configures the hardware blocks and clock requirements, while deferring
REG_UPDATE and AUP_UPDATE until after CSID configuration completes.
> diff --git a/drivers/media/platform/qcom/camss/camss-vfe.c b/drivers/media/platform/qcom/camss/camss-vfe.c
> --- a/drivers/media/platform/qcom/camss/camss-vfe.c
> +++ b/drivers/media/platform/qcom/camss/camss-vfe.c
[ ... ]
> @@ -552,7 +554,9 @@ int vfe_enable_output_v2(struct vfe_line *line)
> output->gen2.active_num++;
> ops->vfe_wm_update(vfe, output->wm_idx[0],
> output->buf[i]->addr[0], line);
> - ops->reg_update(vfe, line->id);
> +
> + if (!vfe->res->reg_update_after_csid_config)
> + ops->reg_update(vfe, line->id);
> }
>
> spin_unlock_irqrestore(&vfe->output_lock, flags);
[Severity: High]
The commit message states: "the number of AUP_UPDATE requests must match the
number of buffers queued to the write master while it is being enabled."
In vfe_enable_output_v2(), the VFE loop shown above queues pending buffers
dynamically up to CAMSS_INIT_BUF_COUNT, but breaks early if userspace queued
fewer buffers. By setting reg_update_after_csid_config to true for Kaanapali,
this defers the update to CSID.
However, the corresponding CSID code at csid_configure_stream() in
camss-csid-gen4.c blindly issues AUP_UPDATEs matching the maximum buffer
count:
for (k = 0; k < CAMSS_INIT_BUF_COUNT; k++)
__csid_aup_update(csid, i);
If userspace queues fewer buffers before starting the stream, does this cause
a mismatch between the generated AUP_UPDATEs and the actually queued buffers,
violating the hardware constraint?
> diff --git a/drivers/media/platform/qcom/camss/camss.c b/drivers/media/platform/qcom/camss/camss.c
> --- a/drivers/media/platform/qcom/camss/camss.c
> +++ b/drivers/media/platform/qcom/camss/camss.c
[ ... ]
> @@ -158,6 +158,157 @@ static const struct camss_subdev_resources csid_res_kaanapali[] = {
[ ... ]
> + /* VFE3 - IFE Lite */
> + {
> + .clock = { "gcc_axi_hf", "cpas_ahb", "cpas_fast_ahb",
> + "vfe_lite_ahb", "vfe_lite",
> + "cpas_vfe_lite", "camnoc_rt_axi",
> + "camnoc_nrt_axi", "qdss_debug_xo" },
> + .clock_rate = { { 0 },
> + { 0 },
> + { 0 },
> + { 0 },
> + { 266666667, 400000000, 480000000 },
> + { 0 },
> + { 200000000, 300000000, 400000000, 480000000 },
> + { 0 },
> + { 0 } },
> + .reg = { "vfe_lite0" },
> + .interrupt = { "vfe_lite0" },
> + .vfe = {
> + .line_num = 4,
> + .is_lite = true,
[Severity: High]
The commit message explicitly states: "Support is currently limited to three
output lines, matching the constraints of the CAMSS framework."
But line_num is initialized to 4 for the IFE Lite blocks.
Since the CAMSS framework hardcodes VFE_LINE_PIX to index 3, does configuring
4 lines cause the 4th line (RDI3 with id 3) to be incorrectly subjected to
PIX-specific logic? For example, in vfe_try_format(), this would force a raw
RDI dump stream to use PIX format tables and validation:
if (line->id == VFE_LINE_PIX) {
struct v4l2_rect *rect;
rect = __vfe_get_crop(line, sd_state, which);
fmt->width = rect->width;
fmt->height = rect->height;
}
Is this initialization to 4 lines unintentional given the 3-line limit
mentioned in the commit?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260928-kaanapali-camss-v17-0-dcf3fd37f76c@oss.qualcomm.com?part=7
^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: [PATCH v17 07/11] media: qcom: camss: vfe: Add support for VFE Gen4
@ 2026-09-29 6:17 ` sashiko-bot
0 siblings, 0 replies; 58+ messages in thread
From: sashiko-bot @ 2026-09-29 6:17 UTC (permalink / raw)
To: Hangxiang Ma
Cc: conor+dt, vkoul, devicetree, olteanv, neil.armstrong, linux-phy,
robh, media-ci
Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [High] camss: hardware constraint violation due to unconditional AUP_UPDATE loop in CSID
- [High] camss: subsystem API violation where IFE Lite's 4th RDI line is incorrectly configured as PIX
--
commit def99c6cf972d2305c4c27701233f42e411f7857
Author: Hangxiang Ma <hangxiang.ma@oss.qualcomm.com>
media: qcom: camss: vfe: Add support for VFE Gen4
This commit adds support for the VFE Gen4 (TFE) found on the Kaanapali SoC.
It configures the hardware blocks and clock requirements, while deferring
REG_UPDATE and AUP_UPDATE until after CSID configuration completes.
> diff --git a/drivers/media/platform/qcom/camss/camss-vfe.c b/drivers/media/platform/qcom/camss/camss-vfe.c
> --- a/drivers/media/platform/qcom/camss/camss-vfe.c
> +++ b/drivers/media/platform/qcom/camss/camss-vfe.c
[ ... ]
> @@ -552,7 +554,9 @@ int vfe_enable_output_v2(struct vfe_line *line)
> output->gen2.active_num++;
> ops->vfe_wm_update(vfe, output->wm_idx[0],
> output->buf[i]->addr[0], line);
> - ops->reg_update(vfe, line->id);
> +
> + if (!vfe->res->reg_update_after_csid_config)
> + ops->reg_update(vfe, line->id);
> }
>
> spin_unlock_irqrestore(&vfe->output_lock, flags);
[Severity: High]
The commit message states: "the number of AUP_UPDATE requests must match the
number of buffers queued to the write master while it is being enabled."
In vfe_enable_output_v2(), the VFE loop shown above queues pending buffers
dynamically up to CAMSS_INIT_BUF_COUNT, but breaks early if userspace queued
fewer buffers. By setting reg_update_after_csid_config to true for Kaanapali,
this defers the update to CSID.
However, the corresponding CSID code at csid_configure_stream() in
camss-csid-gen4.c blindly issues AUP_UPDATEs matching the maximum buffer
count:
for (k = 0; k < CAMSS_INIT_BUF_COUNT; k++)
__csid_aup_update(csid, i);
If userspace queues fewer buffers before starting the stream, does this cause
a mismatch between the generated AUP_UPDATEs and the actually queued buffers,
violating the hardware constraint?
> diff --git a/drivers/media/platform/qcom/camss/camss.c b/drivers/media/platform/qcom/camss/camss.c
> --- a/drivers/media/platform/qcom/camss/camss.c
> +++ b/drivers/media/platform/qcom/camss/camss.c
[ ... ]
> @@ -158,6 +158,157 @@ static const struct camss_subdev_resources csid_res_kaanapali[] = {
[ ... ]
> + /* VFE3 - IFE Lite */
> + {
> + .clock = { "gcc_axi_hf", "cpas_ahb", "cpas_fast_ahb",
> + "vfe_lite_ahb", "vfe_lite",
> + "cpas_vfe_lite", "camnoc_rt_axi",
> + "camnoc_nrt_axi", "qdss_debug_xo" },
> + .clock_rate = { { 0 },
> + { 0 },
> + { 0 },
> + { 0 },
> + { 266666667, 400000000, 480000000 },
> + { 0 },
> + { 200000000, 300000000, 400000000, 480000000 },
> + { 0 },
> + { 0 } },
> + .reg = { "vfe_lite0" },
> + .interrupt = { "vfe_lite0" },
> + .vfe = {
> + .line_num = 4,
> + .is_lite = true,
[Severity: High]
The commit message explicitly states: "Support is currently limited to three
output lines, matching the constraints of the CAMSS framework."
But line_num is initialized to 4 for the IFE Lite blocks.
Since the CAMSS framework hardcodes VFE_LINE_PIX to index 3, does configuring
4 lines cause the 4th line (RDI3 with id 3) to be incorrectly subjected to
PIX-specific logic? For example, in vfe_try_format(), this would force a raw
RDI dump stream to use PIX format tables and validation:
if (line->id == VFE_LINE_PIX) {
struct v4l2_rect *rect;
rect = __vfe_get_crop(line, sd_state, which);
fmt->width = rect->width;
fmt->height = rect->height;
}
Is this initialization to 4 lines unintentional given the 3-line limit
mentioned in the commit?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260928-kaanapali-camss-v17-0-dcf3fd37f76c@oss.qualcomm.com?part=7
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: [PATCH v17 01/11] dt-bindings: phy: qcom,x1e80100-csi2-phy: Add Kaanapali CSI2 PHY
2026-09-29 6:00 ` Hangxiang Ma
@ 2026-09-30 10:33 ` Krzysztof Kozlowski
-1 siblings, 0 replies; 58+ messages in thread
From: Krzysztof Kozlowski @ 2026-09-30 10:33 UTC (permalink / raw)
To: Hangxiang Ma
Cc: Bryan O'Donoghue, Vinod Koul, Neil Armstrong,
Manivannan Sadhasivam, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Bryan O'Donoghue, Vladimir Zapolskiy,
Loic Poulain, Mauro Carvalho Chehab, Bjorn Andersson,
Konrad Dybcio, Abel Vesa, linux-phy, linux-media, linux-arm-msm,
devicetree, linux-kernel, jeyaprakash.soundrapandian,
Vijay Kumar Tumati
On Mon, Sep 28, 2026 at 11:00:27PM -0700, Hangxiang Ma wrote:
> The Kaanapali CSI2 PHY is compatible with the existing x1e80100 CSI2
> C-PHY/DPHY binding. Add the "qcom,kaanapali-csi2-phy" compatible.
>
> Reviewed-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
> Signed-off-by: Hangxiang Ma <hangxiang.ma@oss.qualcomm.com>
> ---
> Documentation/devicetree/bindings/phy/qcom,x1e80100-csi2-phy.yaml | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Best regards,
Krzysztof
^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: [PATCH v17 01/11] dt-bindings: phy: qcom,x1e80100-csi2-phy: Add Kaanapali CSI2 PHY
@ 2026-09-30 10:33 ` Krzysztof Kozlowski
0 siblings, 0 replies; 58+ messages in thread
From: Krzysztof Kozlowski @ 2026-09-30 10:33 UTC (permalink / raw)
To: Hangxiang Ma
Cc: Bryan O'Donoghue, Vinod Koul, Neil Armstrong,
Manivannan Sadhasivam, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Bryan O'Donoghue, Vladimir Zapolskiy,
Loic Poulain, Mauro Carvalho Chehab, Bjorn Andersson,
Konrad Dybcio, Abel Vesa, linux-phy, linux-media, linux-arm-msm,
devicetree, linux-kernel, jeyaprakash.soundrapandian,
Vijay Kumar Tumati
On Mon, Sep 28, 2026 at 11:00:27PM -0700, Hangxiang Ma wrote:
> The Kaanapali CSI2 PHY is compatible with the existing x1e80100 CSI2
> C-PHY/DPHY binding. Add the "qcom,kaanapali-csi2-phy" compatible.
>
> Reviewed-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
> Signed-off-by: Hangxiang Ma <hangxiang.ma@oss.qualcomm.com>
> ---
> Documentation/devicetree/bindings/phy/qcom,x1e80100-csi2-phy.yaml | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Best regards,
Krzysztof
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: [PATCH v17 02/11] media: dt-bindings: Add CAMSS device for Kaanapali
2026-09-29 6:00 ` Hangxiang Ma
@ 2026-09-30 10:34 ` Krzysztof Kozlowski
-1 siblings, 0 replies; 58+ messages in thread
From: Krzysztof Kozlowski @ 2026-09-30 10:34 UTC (permalink / raw)
To: Hangxiang Ma
Cc: Bryan O'Donoghue, Vinod Koul, Neil Armstrong,
Manivannan Sadhasivam, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Bryan O'Donoghue, Vladimir Zapolskiy,
Loic Poulain, Mauro Carvalho Chehab, Bjorn Andersson,
Konrad Dybcio, Abel Vesa, linux-phy, linux-media, linux-arm-msm,
devicetree, linux-kernel, jeyaprakash.soundrapandian,
Vijay Kumar Tumati
On Mon, Sep 28, 2026 at 11:00:28PM -0700, Hangxiang Ma wrote:
> Add bindings for Camera Subsystem (CAMSS) on the Qualcomm Kaanapali
> platform.
>
> The Kaanapali platform 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
>
> Signed-off-by: Hangxiang Ma <hangxiang.ma@oss.qualcomm.com>
Feedback from Sashiko looks reasonable and I do not see it being
responded to. Dropping from DT Patchwork.
Best regards,
Krzysztof
^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: [PATCH v17 02/11] media: dt-bindings: Add CAMSS device for Kaanapali
@ 2026-09-30 10:34 ` Krzysztof Kozlowski
0 siblings, 0 replies; 58+ messages in thread
From: Krzysztof Kozlowski @ 2026-09-30 10:34 UTC (permalink / raw)
To: Hangxiang Ma
Cc: Bryan O'Donoghue, Vinod Koul, Neil Armstrong,
Manivannan Sadhasivam, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Bryan O'Donoghue, Vladimir Zapolskiy,
Loic Poulain, Mauro Carvalho Chehab, Bjorn Andersson,
Konrad Dybcio, Abel Vesa, linux-phy, linux-media, linux-arm-msm,
devicetree, linux-kernel, jeyaprakash.soundrapandian,
Vijay Kumar Tumati
On Mon, Sep 28, 2026 at 11:00:28PM -0700, Hangxiang Ma wrote:
> Add bindings for Camera Subsystem (CAMSS) on the Qualcomm Kaanapali
> platform.
>
> The Kaanapali platform 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
>
> Signed-off-by: Hangxiang Ma <hangxiang.ma@oss.qualcomm.com>
Feedback from Sashiko looks reasonable and I do not see it being
responded to. Dropping from DT Patchwork.
Best regards,
Krzysztof
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: [PATCH v17 02/11] media: dt-bindings: Add CAMSS device for Kaanapali
2026-09-29 6:08 ` sashiko-bot
@ 2026-09-30 12:54 ` Hangxiang Ma
-1 siblings, 0 replies; 58+ messages in thread
From: Hangxiang Ma @ 2026-09-30 12:54 UTC (permalink / raw)
To: sashiko-reviews, Krzysztof Kozlowski
Cc: linux-phy, olteanv, media-ci, vkoul, neil.armstrong, devicetree,
conor+dt, robh
On 9/29/2026 2:08 PM, sashiko-bot@kernel.org wrote:
> Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
> - [Low] media: dt-bindings: contradictory port count description vs schema
> --
>
> commit eaf675a1ac25eea3cc950df0432cfe59f97c1517
> Author: Hangxiang Ma <hangxiang.ma@oss.qualcomm.com>
>
> media: dt-bindings: Add CAMSS device for Kaanapali
>
> Add bindings for Camera Subsystem (CAMSS) on the Qualcomm Kaanapali
> platform.
>
>> diff --git a/Documentation/devicetree/bindings/media/qcom,kaanapali-camss.yaml b/Documentation/devicetree/bindings/media/qcom,kaanapali-camss.yaml
>> new file mode 100644
>> index 0000000000000..1f8b18517e13a
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/media/qcom,kaanapali-camss.yaml
> [ ... ]
>> + power-domain-names:
>> + items:
>> + - const: ife0
>> + - const: ife1
>> + - const: ife2
>> + - const: top
>> +
>> + ports:
>> + $ref: /schemas/graph.yaml#/properties/ports
>> +
>> + description:
>> + CSI input ports, one per CSID. Each port receives the CSI data
>> + decoded by the matching CSIPHY.
>> +
>> + patternProperties:
>> + "^port@[0-5]$":
>> + $ref: /schemas/graph.yaml#/$defs/port-base
>> + unevaluatedProperties: false
>> + description:
>> + Input port for receiving CSI data from CSIPHY 0-5.
>
> [Severity: Low]
> Could this description be updated to clarify the port count?
>
> The commit message indicates the platform has 5 CSIDs (3 regular, 2 lite)
> and 6 CSIPHYs. The top-level description for the ports node states there is
> "one per CSID", which would imply 5 ports. However, the schema allows 6 ports
> ("^port@[0-5]$") and the nested description mentions receiving data from
> CSIPHY 0-5.
>
> Does the "one per CSID" text need to be updated to match the hardware layout
> allowed by the schema?
>
Exactly. It's reasonable to remove this misleading description "one per
CSID". We control that one-to-one CSIPHY and CSID mapping manually and
the real multiplexing result will be different.
Best Regards,
Hangxiang
^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: [PATCH v17 02/11] media: dt-bindings: Add CAMSS device for Kaanapali
@ 2026-09-30 12:54 ` Hangxiang Ma
0 siblings, 0 replies; 58+ messages in thread
From: Hangxiang Ma @ 2026-09-30 12:54 UTC (permalink / raw)
To: sashiko-reviews, Krzysztof Kozlowski
Cc: linux-phy, olteanv, media-ci, vkoul, neil.armstrong, devicetree,
conor+dt, robh
On 9/29/2026 2:08 PM, sashiko-bot@kernel.org wrote:
> Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
> - [Low] media: dt-bindings: contradictory port count description vs schema
> --
>
> commit eaf675a1ac25eea3cc950df0432cfe59f97c1517
> Author: Hangxiang Ma <hangxiang.ma@oss.qualcomm.com>
>
> media: dt-bindings: Add CAMSS device for Kaanapali
>
> Add bindings for Camera Subsystem (CAMSS) on the Qualcomm Kaanapali
> platform.
>
>> diff --git a/Documentation/devicetree/bindings/media/qcom,kaanapali-camss.yaml b/Documentation/devicetree/bindings/media/qcom,kaanapali-camss.yaml
>> new file mode 100644
>> index 0000000000000..1f8b18517e13a
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/media/qcom,kaanapali-camss.yaml
> [ ... ]
>> + power-domain-names:
>> + items:
>> + - const: ife0
>> + - const: ife1
>> + - const: ife2
>> + - const: top
>> +
>> + ports:
>> + $ref: /schemas/graph.yaml#/properties/ports
>> +
>> + description:
>> + CSI input ports, one per CSID. Each port receives the CSI data
>> + decoded by the matching CSIPHY.
>> +
>> + patternProperties:
>> + "^port@[0-5]$":
>> + $ref: /schemas/graph.yaml#/$defs/port-base
>> + unevaluatedProperties: false
>> + description:
>> + Input port for receiving CSI data from CSIPHY 0-5.
>
> [Severity: Low]
> Could this description be updated to clarify the port count?
>
> The commit message indicates the platform has 5 CSIDs (3 regular, 2 lite)
> and 6 CSIPHYs. The top-level description for the ports node states there is
> "one per CSID", which would imply 5 ports. However, the schema allows 6 ports
> ("^port@[0-5]$") and the nested description mentions receiving data from
> CSIPHY 0-5.
>
> Does the "one per CSID" text need to be updated to match the hardware layout
> allowed by the schema?
>
Exactly. It's reasonable to remove this misleading description "one per
CSID". We control that one-to-one CSIPHY and CSID mapping manually and
the real multiplexing result will be different.
Best Regards,
Hangxiang
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: [PATCH v17 05/11] media: qcom: camss: csiphy: Add support for v2.4.0 two-phase CSIPHY
2026-09-29 6:17 ` sashiko-bot
@ 2026-09-30 13:01 ` Hangxiang Ma
-1 siblings, 0 replies; 58+ messages in thread
From: Hangxiang Ma @ 2026-09-30 13:01 UTC (permalink / raw)
To: sashiko-reviews
Cc: vkoul, neil.armstrong, linux-phy, robh, olteanv, media-ci,
devicetree, conor+dt
On 9/29/2026 2:17 PM, sashiko-bot@kernel.org wrote:
> Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
> - [Critical] media: camss: guaranteed NULL pointer dereference in msm_csiphy_subdev_init()
> --
>
> commit 3c87101a27e8d1c1d3a64a10ed465e1ed433c549
> Author: Hangxiang Ma <hangxiang.ma@oss.qualcomm.com>
>
> media: qcom: camss: csiphy: Add support for v2.4.0 two-phase CSIPHY
>
> Add support for the v2.4.0 two-phase CSIPHY found on Kaanapali, where
> the PHY is driven by the standalone phy-qcom-mipi-csi2 DPHY driver
> rather than by CAMSS. Add the mipi_csi2_dphy_3nm_kaanapali configuration,
> which reuses the x1e80100 lane sequence, clocks and supplies but selects
> the v2.4.0 common status offset, adding Kaanapali power domain and
> register the "qcom,kaanapali-csi2-phy" compatible.
>
>> diff --git a/drivers/media/platform/qcom/camss/camss.c b/drivers/media/platform/qcom/camss/camss.c
>> index a528760487bd9..a0cd839c9948a 100644
>> --- a/drivers/media/platform/qcom/camss/camss.c
>> +++ b/drivers/media/platform/qcom/camss/camss.c
>> @@ -34,6 +34,57 @@
>>
>> static const struct parent_dev_ops vfe_parent_dev_ops;
>>
>> +static const struct camss_subdev_resources csiphy_res_kaanapali[] = {
>> + /* CSIPHY0 */
>> + {
>> + .csiphy = {
>> + .id = 0,
>> + .hw_ops = &csiphy_ops_3ph_1_0,
>> + .formats = &csiphy_formats_sdm845
>> + },
>> + },
>
> [Severity: Critical]
> Can this result in a NULL pointer dereference during device probe?
>
> Because this Kaanapali resource definition completely omits the .reg array, it
> implicitly initializes to NULL. However, it still binds legacy hardware
> operations (&csiphy_ops_3ph_1_0) that expect MMIO mappings.
>
> When the CAMSS probe unconditionally iterates over all csiphy_num entries
> and invokes msm_csiphy_subdev_init() for each, it attempts to map the legacy
> register space:
>
> drivers/media/platform/qcom/camss/camss-csiphy.c:msm_csiphy_subdev_init() {
> ...
> csiphy->base = devm_platform_ioremap_resource_byname(pdev, res->reg[0]);
> ...
> }
>
> Because .reg was omitted, res->reg[0] is NULL, which propagates down to
> platform_get_resource_byname(). Since Kaanapali defines other named resources,
> evaluating strcmp(r->name, NULL) with a NULL name argument can cause a crash.
>
> Does the standalone PHY need to be consumed via the kernel's generic PHY
> framework (e.g., devm_phy_get) instead of retaining legacy CAMSS ops that
> assume direct MMIO control?
>
> [ ... ]
>
Kaanapali use the re-arch CSIPHY framework so that the resources like
register, supply are now handled by a separate PHY driver. We don't need
to declare those redundant resources in CAMSS driver now.
Best Regards,
Hangxiang
^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: [PATCH v17 05/11] media: qcom: camss: csiphy: Add support for v2.4.0 two-phase CSIPHY
@ 2026-09-30 13:01 ` Hangxiang Ma
0 siblings, 0 replies; 58+ messages in thread
From: Hangxiang Ma @ 2026-09-30 13:01 UTC (permalink / raw)
To: sashiko-reviews
Cc: vkoul, neil.armstrong, linux-phy, robh, olteanv, media-ci,
devicetree, conor+dt
On 9/29/2026 2:17 PM, sashiko-bot@kernel.org wrote:
> Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
> - [Critical] media: camss: guaranteed NULL pointer dereference in msm_csiphy_subdev_init()
> --
>
> commit 3c87101a27e8d1c1d3a64a10ed465e1ed433c549
> Author: Hangxiang Ma <hangxiang.ma@oss.qualcomm.com>
>
> media: qcom: camss: csiphy: Add support for v2.4.0 two-phase CSIPHY
>
> Add support for the v2.4.0 two-phase CSIPHY found on Kaanapali, where
> the PHY is driven by the standalone phy-qcom-mipi-csi2 DPHY driver
> rather than by CAMSS. Add the mipi_csi2_dphy_3nm_kaanapali configuration,
> which reuses the x1e80100 lane sequence, clocks and supplies but selects
> the v2.4.0 common status offset, adding Kaanapali power domain and
> register the "qcom,kaanapali-csi2-phy" compatible.
>
>> diff --git a/drivers/media/platform/qcom/camss/camss.c b/drivers/media/platform/qcom/camss/camss.c
>> index a528760487bd9..a0cd839c9948a 100644
>> --- a/drivers/media/platform/qcom/camss/camss.c
>> +++ b/drivers/media/platform/qcom/camss/camss.c
>> @@ -34,6 +34,57 @@
>>
>> static const struct parent_dev_ops vfe_parent_dev_ops;
>>
>> +static const struct camss_subdev_resources csiphy_res_kaanapali[] = {
>> + /* CSIPHY0 */
>> + {
>> + .csiphy = {
>> + .id = 0,
>> + .hw_ops = &csiphy_ops_3ph_1_0,
>> + .formats = &csiphy_formats_sdm845
>> + },
>> + },
>
> [Severity: Critical]
> Can this result in a NULL pointer dereference during device probe?
>
> Because this Kaanapali resource definition completely omits the .reg array, it
> implicitly initializes to NULL. However, it still binds legacy hardware
> operations (&csiphy_ops_3ph_1_0) that expect MMIO mappings.
>
> When the CAMSS probe unconditionally iterates over all csiphy_num entries
> and invokes msm_csiphy_subdev_init() for each, it attempts to map the legacy
> register space:
>
> drivers/media/platform/qcom/camss/camss-csiphy.c:msm_csiphy_subdev_init() {
> ...
> csiphy->base = devm_platform_ioremap_resource_byname(pdev, res->reg[0]);
> ...
> }
>
> Because .reg was omitted, res->reg[0] is NULL, which propagates down to
> platform_get_resource_byname(). Since Kaanapali defines other named resources,
> evaluating strcmp(r->name, NULL) with a NULL name argument can cause a crash.
>
> Does the standalone PHY need to be consumed via the kernel's generic PHY
> framework (e.g., devm_phy_get) instead of retaining legacy CAMSS ops that
> assume direct MMIO control?
>
> [ ... ]
>
Kaanapali use the re-arch CSIPHY framework so that the resources like
register, supply are now handled by a separate PHY driver. We don't need
to declare those redundant resources in CAMSS driver now.
Best Regards,
Hangxiang
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: [PATCH v17 06/11] media: qcom: camss: csid: Add support for CSID Gen4
2026-09-29 6:17 ` sashiko-bot
@ 2026-09-30 13:54 ` Hangxiang Ma
-1 siblings, 0 replies; 58+ messages in thread
From: Hangxiang Ma @ 2026-09-30 13:54 UTC (permalink / raw)
To: sashiko-reviews
Cc: neil.armstrong, vkoul, devicetree, linux-phy, media-ci, robh,
olteanv, conor+dt
On 9/29/2026 2:17 PM, sashiko-bot@kernel.org wrote:
> Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
> - [High] media: qcom/camss: data race on csid->aup_update and rup_update
> - [Medium] media: qcom/camss: integer underflow in __csid_configure_rx
> --
>
> commit 611abdeb4b5da574ae292d1ff736d0d71f2f4ed2
> Author: Hangxiang Ma <hangxiang.ma@oss.qualcomm.com>
>
> media: qcom: camss: csid: Add support for CSID Gen4
>
> Add support for the CSID Gen4 hardware found on Kaanapali SoC.
>
> Introduce Gen4 resource descriptions and implement the hardware-specific
> register programming, reset sequence, and BUF_DONE interrupt handling.
>
> Gen4 splits RUP and AUP updates into separate registers and uses a SET
> register to commit the updates. Update the CSID interface to support
> both this scheme and the legacy combined reg_update mechanism.
>
>> diff --git a/drivers/media/platform/qcom/camss/camss-csid-gen4.c b/drivers/media/platform/qcom/camss/camss-csid-gen4.c
>> new file mode 100644
>> index 0000000000000..4ff2f41f70f7e
>> --- /dev/null
>> +++ b/drivers/media/platform/qcom/camss/camss-csid-gen4.c
> [ ... ]
>> +static void __csid_aup_rup_clear(struct csid_device *csid, int port_id)
>> +{
>> + /* Hardware clears the registers upon consuming the settings */
>> + csid->aup_update &= ~CSID_RUP_AUP_RDI(port_id);
>> + csid->rup_update &= ~CSID_RUP_AUP_RDI(port_id);
>> +}
>> +
>> +static void __csid_aup_update(struct csid_device *csid, int port_id)
>> +{
>> + csid->aup_update |= CSID_RUP_AUP_RDI(port_id);
>> + writel(csid->aup_update, csid->base + CSID_AUP_CMD);
>> +
>> + __csid_aup_rup_trigger(csid);
>> +}
>> +
>> +static void __csid_reg_update(struct csid_device *csid, int port_id)
>> +{
>> + csid->rup_update |= CSID_RUP_AUP_RDI(port_id);
>> + writel(csid->rup_update, csid->base + CSID_RUP_CMD);
>> +
>> + __csid_aup_rup_trigger(csid);
>> +}
>
> [Severity: High]
> Does this introduce a data race on csid->aup_update and csid->rup_update?
>
> If a stream is configured in process context via csid_set_stream(),
> __csid_aup_update() and __csid_reg_update() modify the shared state with
> non-atomic bitwise operations (|=).
>
> If an interrupt (such as RUP_DONE) fires concurrently for an already running
> stream, csid_isr() will execute and call __csid_aup_rup_clear(), which modifies
> the same variables using non-atomic bitwise clear operations (&= ~).
>
> Because these bitwise operations lack locking, could the interrupt's
> modifications be lost, causing the hardware to receive an invalid AUP/RUP
> command mask? This might lead to broken streaming when dynamically configuring
> multiple virtual channels.
>
Ack
>> +
>> +static void __csid_configure_rx(struct csid_device *csid,
>> + struct csid_phy_config *phy)
>> +{
>> + int val;
>> +
>> + val = (phy->lane_cnt - 1) << CSI2_RX_CFG0_NUM_ACTIVE_LANES;
>> + val |= phy->lane_assign << CSI2_RX_CFG0_DL0_INPUT_SEL;
>> + val |= (phy->csiphy_id + CSI2_RX_CFG0_PHY_SEL_BASE_IDX)
>> + << CSI2_RX_CFG0_PHY_NUM_SEL;
>> + writel(val, csid->base + CSID_CSI2_RX_CFG0);
>
> [Severity: Medium]
> Can this code underflow if phy->lane_cnt is 0?
>
> If the device tree incorrectly omits the data-lanes property, phy->lane_cnt can
> evaluate to 0.
>
> While __csid_configure_rdi_stream() provides a fallback for this scenario:
>
> if (!lane_cnt)
> lane_cnt = 4;
>
> __csid_configure_rx() omits this check. If phy->lane_cnt is 0,
> (phy->lane_cnt - 1) underflows to -1. This would result in writing 0xFFFFFFFF
> to CSID_CSI2_RX_CFG0, clobbering all its fields.
>
> Should there be a similar fallback or validation check here to prevent
> hardware misconfiguration?
>
Ack
Best Regards,
Hangxiang
^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: [PATCH v17 06/11] media: qcom: camss: csid: Add support for CSID Gen4
@ 2026-09-30 13:54 ` Hangxiang Ma
0 siblings, 0 replies; 58+ messages in thread
From: Hangxiang Ma @ 2026-09-30 13:54 UTC (permalink / raw)
To: sashiko-reviews
Cc: neil.armstrong, vkoul, devicetree, linux-phy, media-ci, robh,
olteanv, conor+dt
On 9/29/2026 2:17 PM, sashiko-bot@kernel.org wrote:
> Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
> - [High] media: qcom/camss: data race on csid->aup_update and rup_update
> - [Medium] media: qcom/camss: integer underflow in __csid_configure_rx
> --
>
> commit 611abdeb4b5da574ae292d1ff736d0d71f2f4ed2
> Author: Hangxiang Ma <hangxiang.ma@oss.qualcomm.com>
>
> media: qcom: camss: csid: Add support for CSID Gen4
>
> Add support for the CSID Gen4 hardware found on Kaanapali SoC.
>
> Introduce Gen4 resource descriptions and implement the hardware-specific
> register programming, reset sequence, and BUF_DONE interrupt handling.
>
> Gen4 splits RUP and AUP updates into separate registers and uses a SET
> register to commit the updates. Update the CSID interface to support
> both this scheme and the legacy combined reg_update mechanism.
>
>> diff --git a/drivers/media/platform/qcom/camss/camss-csid-gen4.c b/drivers/media/platform/qcom/camss/camss-csid-gen4.c
>> new file mode 100644
>> index 0000000000000..4ff2f41f70f7e
>> --- /dev/null
>> +++ b/drivers/media/platform/qcom/camss/camss-csid-gen4.c
> [ ... ]
>> +static void __csid_aup_rup_clear(struct csid_device *csid, int port_id)
>> +{
>> + /* Hardware clears the registers upon consuming the settings */
>> + csid->aup_update &= ~CSID_RUP_AUP_RDI(port_id);
>> + csid->rup_update &= ~CSID_RUP_AUP_RDI(port_id);
>> +}
>> +
>> +static void __csid_aup_update(struct csid_device *csid, int port_id)
>> +{
>> + csid->aup_update |= CSID_RUP_AUP_RDI(port_id);
>> + writel(csid->aup_update, csid->base + CSID_AUP_CMD);
>> +
>> + __csid_aup_rup_trigger(csid);
>> +}
>> +
>> +static void __csid_reg_update(struct csid_device *csid, int port_id)
>> +{
>> + csid->rup_update |= CSID_RUP_AUP_RDI(port_id);
>> + writel(csid->rup_update, csid->base + CSID_RUP_CMD);
>> +
>> + __csid_aup_rup_trigger(csid);
>> +}
>
> [Severity: High]
> Does this introduce a data race on csid->aup_update and csid->rup_update?
>
> If a stream is configured in process context via csid_set_stream(),
> __csid_aup_update() and __csid_reg_update() modify the shared state with
> non-atomic bitwise operations (|=).
>
> If an interrupt (such as RUP_DONE) fires concurrently for an already running
> stream, csid_isr() will execute and call __csid_aup_rup_clear(), which modifies
> the same variables using non-atomic bitwise clear operations (&= ~).
>
> Because these bitwise operations lack locking, could the interrupt's
> modifications be lost, causing the hardware to receive an invalid AUP/RUP
> command mask? This might lead to broken streaming when dynamically configuring
> multiple virtual channels.
>
Ack
>> +
>> +static void __csid_configure_rx(struct csid_device *csid,
>> + struct csid_phy_config *phy)
>> +{
>> + int val;
>> +
>> + val = (phy->lane_cnt - 1) << CSI2_RX_CFG0_NUM_ACTIVE_LANES;
>> + val |= phy->lane_assign << CSI2_RX_CFG0_DL0_INPUT_SEL;
>> + val |= (phy->csiphy_id + CSI2_RX_CFG0_PHY_SEL_BASE_IDX)
>> + << CSI2_RX_CFG0_PHY_NUM_SEL;
>> + writel(val, csid->base + CSID_CSI2_RX_CFG0);
>
> [Severity: Medium]
> Can this code underflow if phy->lane_cnt is 0?
>
> If the device tree incorrectly omits the data-lanes property, phy->lane_cnt can
> evaluate to 0.
>
> While __csid_configure_rdi_stream() provides a fallback for this scenario:
>
> if (!lane_cnt)
> lane_cnt = 4;
>
> __csid_configure_rx() omits this check. If phy->lane_cnt is 0,
> (phy->lane_cnt - 1) underflows to -1. This would result in writing 0xFFFFFFFF
> to CSID_CSI2_RX_CFG0, clobbering all its fields.
>
> Should there be a similar fallback or validation check here to prevent
> hardware misconfiguration?
>
Ack
Best Regards,
Hangxiang
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: [PATCH v17 07/11] media: qcom: camss: vfe: Add support for VFE Gen4
2026-09-29 6:17 ` sashiko-bot
@ 2026-09-30 14:07 ` Hangxiang Ma
-1 siblings, 0 replies; 58+ messages in thread
From: Hangxiang Ma @ 2026-09-30 14:07 UTC (permalink / raw)
To: sashiko-reviews
Cc: conor+dt, vkoul, devicetree, olteanv, neil.armstrong, linux-phy,
robh, media-ci
On 9/29/2026 2:17 PM, sashiko-bot@kernel.org wrote:
> Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
> - [High] camss: hardware constraint violation due to unconditional AUP_UPDATE loop in CSID
> - [High] camss: subsystem API violation where IFE Lite's 4th RDI line is incorrectly configured as PIX
> --
>
> commit def99c6cf972d2305c4c27701233f42e411f7857
> Author: Hangxiang Ma <hangxiang.ma@oss.qualcomm.com>
>
> media: qcom: camss: vfe: Add support for VFE Gen4
>
> This commit adds support for the VFE Gen4 (TFE) found on the Kaanapali SoC.
> It configures the hardware blocks and clock requirements, while deferring
> REG_UPDATE and AUP_UPDATE until after CSID configuration completes.
>
>> diff --git a/drivers/media/platform/qcom/camss/camss-vfe.c b/drivers/media/platform/qcom/camss/camss-vfe.c
>> --- a/drivers/media/platform/qcom/camss/camss-vfe.c
>> +++ b/drivers/media/platform/qcom/camss/camss-vfe.c
>
> [ ... ]
>
>> @@ -552,7 +554,9 @@ int vfe_enable_output_v2(struct vfe_line *line)
>> output->gen2.active_num++;
>> ops->vfe_wm_update(vfe, output->wm_idx[0],
>> output->buf[i]->addr[0], line);
>> - ops->reg_update(vfe, line->id);
>> +
>> + if (!vfe->res->reg_update_after_csid_config)
>> + ops->reg_update(vfe, line->id);
>> }
>>
>> spin_unlock_irqrestore(&vfe->output_lock, flags);
>
> [Severity: High]
> The commit message states: "the number of AUP_UPDATE requests must match the
> number of buffers queued to the write master while it is being enabled."
>
> In vfe_enable_output_v2(), the VFE loop shown above queues pending buffers
> dynamically up to CAMSS_INIT_BUF_COUNT, but breaks early if userspace queued
> fewer buffers. By setting reg_update_after_csid_config to true for Kaanapali,
> this defers the update to CSID.
>
> However, the corresponding CSID code at csid_configure_stream() in
> camss-csid-gen4.c blindly issues AUP_UPDATEs matching the maximum buffer
> count:
>
> for (k = 0; k < CAMSS_INIT_BUF_COUNT; k++)
> __csid_aup_update(csid, i);
>
> If userspace queues fewer buffers before starting the stream, does this cause
> a mismatch between the generated AUP_UPDATEs and the actually queued buffers,
> violating the hardware constraint?
>
No. The hardware accept this operation and no issue is found in tests.
>> diff --git a/drivers/media/platform/qcom/camss/camss.c b/drivers/media/platform/qcom/camss/camss.c
>> --- a/drivers/media/platform/qcom/camss/camss.c
>> +++ b/drivers/media/platform/qcom/camss/camss.c
>
> [ ... ]
>
>> @@ -158,6 +158,157 @@ static const struct camss_subdev_resources csid_res_kaanapali[] = {
>
> [ ... ]
>
>> + /* VFE3 - IFE Lite */
>> + {
>> + .clock = { "gcc_axi_hf", "cpas_ahb", "cpas_fast_ahb",
>> + "vfe_lite_ahb", "vfe_lite",
>> + "cpas_vfe_lite", "camnoc_rt_axi",
>> + "camnoc_nrt_axi", "qdss_debug_xo" },
>> + .clock_rate = { { 0 },
>> + { 0 },
>> + { 0 },
>> + { 0 },
>> + { 266666667, 400000000, 480000000 },
>> + { 0 },
>> + { 200000000, 300000000, 400000000, 480000000 },
>> + { 0 },
>> + { 0 } },
>> + .reg = { "vfe_lite0" },
>> + .interrupt = { "vfe_lite0" },
>> + .vfe = {
>> + .line_num = 4,
>> + .is_lite = true,
>
> [Severity: High]
> The commit message explicitly states: "Support is currently limited to three
> output lines, matching the constraints of the CAMSS framework."
>
> But line_num is initialized to 4 for the IFE Lite blocks.
>
> Since the CAMSS framework hardcodes VFE_LINE_PIX to index 3, does configuring
> 4 lines cause the 4th line (RDI3 with id 3) to be incorrectly subjected to
> PIX-specific logic? For example, in vfe_try_format(), this would force a raw
> RDI dump stream to use PIX format tables and validation:
>
> if (line->id == VFE_LINE_PIX) {
> struct v4l2_rect *rect;
> rect = __vfe_get_crop(line, sd_state, which);
> fmt->width = rect->width;
> fmt->height = rect->height;
> }
>
> Is this initialization to 4 lines unintentional given the 3-line limit
> mentioned in the commit?
>
It's acceptable to align with the commits. Actually this is a CAMSS
framework restriction which needs additional efforts. Will keep it the
same for TFE Full and TFE Lite in next revision.
Best Regards,
Hangxiang
^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: [PATCH v17 07/11] media: qcom: camss: vfe: Add support for VFE Gen4
@ 2026-09-30 14:07 ` Hangxiang Ma
0 siblings, 0 replies; 58+ messages in thread
From: Hangxiang Ma @ 2026-09-30 14:07 UTC (permalink / raw)
To: sashiko-reviews
Cc: conor+dt, vkoul, devicetree, olteanv, neil.armstrong, linux-phy,
robh, media-ci
On 9/29/2026 2:17 PM, sashiko-bot@kernel.org wrote:
> Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
> - [High] camss: hardware constraint violation due to unconditional AUP_UPDATE loop in CSID
> - [High] camss: subsystem API violation where IFE Lite's 4th RDI line is incorrectly configured as PIX
> --
>
> commit def99c6cf972d2305c4c27701233f42e411f7857
> Author: Hangxiang Ma <hangxiang.ma@oss.qualcomm.com>
>
> media: qcom: camss: vfe: Add support for VFE Gen4
>
> This commit adds support for the VFE Gen4 (TFE) found on the Kaanapali SoC.
> It configures the hardware blocks and clock requirements, while deferring
> REG_UPDATE and AUP_UPDATE until after CSID configuration completes.
>
>> diff --git a/drivers/media/platform/qcom/camss/camss-vfe.c b/drivers/media/platform/qcom/camss/camss-vfe.c
>> --- a/drivers/media/platform/qcom/camss/camss-vfe.c
>> +++ b/drivers/media/platform/qcom/camss/camss-vfe.c
>
> [ ... ]
>
>> @@ -552,7 +554,9 @@ int vfe_enable_output_v2(struct vfe_line *line)
>> output->gen2.active_num++;
>> ops->vfe_wm_update(vfe, output->wm_idx[0],
>> output->buf[i]->addr[0], line);
>> - ops->reg_update(vfe, line->id);
>> +
>> + if (!vfe->res->reg_update_after_csid_config)
>> + ops->reg_update(vfe, line->id);
>> }
>>
>> spin_unlock_irqrestore(&vfe->output_lock, flags);
>
> [Severity: High]
> The commit message states: "the number of AUP_UPDATE requests must match the
> number of buffers queued to the write master while it is being enabled."
>
> In vfe_enable_output_v2(), the VFE loop shown above queues pending buffers
> dynamically up to CAMSS_INIT_BUF_COUNT, but breaks early if userspace queued
> fewer buffers. By setting reg_update_after_csid_config to true for Kaanapali,
> this defers the update to CSID.
>
> However, the corresponding CSID code at csid_configure_stream() in
> camss-csid-gen4.c blindly issues AUP_UPDATEs matching the maximum buffer
> count:
>
> for (k = 0; k < CAMSS_INIT_BUF_COUNT; k++)
> __csid_aup_update(csid, i);
>
> If userspace queues fewer buffers before starting the stream, does this cause
> a mismatch between the generated AUP_UPDATEs and the actually queued buffers,
> violating the hardware constraint?
>
No. The hardware accept this operation and no issue is found in tests.
>> diff --git a/drivers/media/platform/qcom/camss/camss.c b/drivers/media/platform/qcom/camss/camss.c
>> --- a/drivers/media/platform/qcom/camss/camss.c
>> +++ b/drivers/media/platform/qcom/camss/camss.c
>
> [ ... ]
>
>> @@ -158,6 +158,157 @@ static const struct camss_subdev_resources csid_res_kaanapali[] = {
>
> [ ... ]
>
>> + /* VFE3 - IFE Lite */
>> + {
>> + .clock = { "gcc_axi_hf", "cpas_ahb", "cpas_fast_ahb",
>> + "vfe_lite_ahb", "vfe_lite",
>> + "cpas_vfe_lite", "camnoc_rt_axi",
>> + "camnoc_nrt_axi", "qdss_debug_xo" },
>> + .clock_rate = { { 0 },
>> + { 0 },
>> + { 0 },
>> + { 0 },
>> + { 266666667, 400000000, 480000000 },
>> + { 0 },
>> + { 200000000, 300000000, 400000000, 480000000 },
>> + { 0 },
>> + { 0 } },
>> + .reg = { "vfe_lite0" },
>> + .interrupt = { "vfe_lite0" },
>> + .vfe = {
>> + .line_num = 4,
>> + .is_lite = true,
>
> [Severity: High]
> The commit message explicitly states: "Support is currently limited to three
> output lines, matching the constraints of the CAMSS framework."
>
> But line_num is initialized to 4 for the IFE Lite blocks.
>
> Since the CAMSS framework hardcodes VFE_LINE_PIX to index 3, does configuring
> 4 lines cause the 4th line (RDI3 with id 3) to be incorrectly subjected to
> PIX-specific logic? For example, in vfe_try_format(), this would force a raw
> RDI dump stream to use PIX format tables and validation:
>
> if (line->id == VFE_LINE_PIX) {
> struct v4l2_rect *rect;
> rect = __vfe_get_crop(line, sd_state, which);
> fmt->width = rect->width;
> fmt->height = rect->height;
> }
>
> Is this initialization to 4 lines unintentional given the 3-line limit
> mentioned in the commit?
>
It's acceptable to align with the commits. Actually this is a CAMSS
framework restriction which needs additional efforts. Will keep it the
same for TFE Full and TFE Lite in next revision.
Best Regards,
Hangxiang
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: [PATCH v17 08/11] media: qcom: camss: tpg: Add support for v2.4.0 TPG
2026-09-29 6:12 ` sashiko-bot
@ 2026-09-30 14:12 ` Hangxiang Ma
-1 siblings, 0 replies; 58+ messages in thread
From: Hangxiang Ma @ 2026-09-30 14:12 UTC (permalink / raw)
To: sashiko-reviews
Cc: media-ci, neil.armstrong, devicetree, conor+dt, linux-phy,
olteanv, robh, vkoul
On 9/29/2026 2:12 PM, sashiko-bot@kernel.org wrote:
> Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
> - [Medium] media: camss: uninitialized tpg->hw_version used in tpg_reset()
> --
>
> commit e2a0aed20f3751127d25b2596032eac51d537c58
> Author: Hangxiang Ma <hangxiang.ma@oss.qualcomm.com>
>
> media: qcom: camss: tpg: Add support for v2.4.0 TPG
>
> This commit adds support for the TPG hardware version 2.4.0 found on
> Kaanapali. It updates the configuration and reset logic to use the new
> TPG_CTRL_CMD register instead of TPG_CTRL.
>
>> diff --git a/drivers/media/platform/qcom/camss/camss-tpg-gen1.c b/drivers/media/platform/qcom/camss/camss-tpg-gen1.c
>> index d29de5f93c18e..770a9e5d5ba5f 100644
>> --- a/drivers/media/platform/qcom/camss/camss-tpg-gen1.c
>> +++ b/drivers/media/platform/qcom/camss/camss-tpg-gen1.c
>
> [ ... ]
>
>> @@ -164,18 +167,30 @@ static int tpg_stream_on(struct tpg_device *tpg)
>
> [ ... ]
>
>> static int tpg_reset(struct tpg_device *tpg)
>> {
>> - writel(0, tpg->base + TPG_CTRL);
>> - writel(1, tpg->base + TPG_CLEAR);
>> + /*
>> + * On TPG older than v2.4.0 test-enable lives in TPG_CTRL, so clear it
>> + * first; v2.4.0+ drives both test-enable and reset through TPG_CTRL_CMD.
>> + */
>> + if (tpg->hw_version < TPG_HW_VER_2_4_0)
>> + writel(0, tpg->base + TPG_CTRL);
>
> [Severity: Medium]
> Will this execute the legacy reset logic on v2.4.0+ hardware during the
> first power-on sequence?
>
> When the driver powers up the device, tpg_set_power() calls the reset
> function before calling hw_version():
>
> drivers/media/platform/qcom/camss/camss-tpg.c:tpg_set_power() {
> ...
> tpg->res->hw_ops->reset(tpg);
> tpg->res->hw_ops->hw_version(tpg);
> ...
> }
>
> Because the tpg object is zero-initialized and tpg->hw_version is not
> populated until after the reset function is called, tpg->hw_version
> is strictly 0 during the first execution of tpg_reset().
>
> Does this mean the condition here evaluates to true for all hardware
> versions on the initial power-up, inadvertently causing an unintended
> write to TPG_CTRL?
>
>> +
>> + writel(TPG_CTRL_CMD_HW_RESET, tpg->base + TPG_CTRL_CMD);
>>
>> return 0;
>> }
>
No. The version data is always valid no matter the reset is called or not.
Best Regards,
Hangxiang
^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: [PATCH v17 08/11] media: qcom: camss: tpg: Add support for v2.4.0 TPG
@ 2026-09-30 14:12 ` Hangxiang Ma
0 siblings, 0 replies; 58+ messages in thread
From: Hangxiang Ma @ 2026-09-30 14:12 UTC (permalink / raw)
To: sashiko-reviews
Cc: media-ci, neil.armstrong, devicetree, conor+dt, linux-phy,
olteanv, robh, vkoul
On 9/29/2026 2:12 PM, sashiko-bot@kernel.org wrote:
> Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
> - [Medium] media: camss: uninitialized tpg->hw_version used in tpg_reset()
> --
>
> commit e2a0aed20f3751127d25b2596032eac51d537c58
> Author: Hangxiang Ma <hangxiang.ma@oss.qualcomm.com>
>
> media: qcom: camss: tpg: Add support for v2.4.0 TPG
>
> This commit adds support for the TPG hardware version 2.4.0 found on
> Kaanapali. It updates the configuration and reset logic to use the new
> TPG_CTRL_CMD register instead of TPG_CTRL.
>
>> diff --git a/drivers/media/platform/qcom/camss/camss-tpg-gen1.c b/drivers/media/platform/qcom/camss/camss-tpg-gen1.c
>> index d29de5f93c18e..770a9e5d5ba5f 100644
>> --- a/drivers/media/platform/qcom/camss/camss-tpg-gen1.c
>> +++ b/drivers/media/platform/qcom/camss/camss-tpg-gen1.c
>
> [ ... ]
>
>> @@ -164,18 +167,30 @@ static int tpg_stream_on(struct tpg_device *tpg)
>
> [ ... ]
>
>> static int tpg_reset(struct tpg_device *tpg)
>> {
>> - writel(0, tpg->base + TPG_CTRL);
>> - writel(1, tpg->base + TPG_CLEAR);
>> + /*
>> + * On TPG older than v2.4.0 test-enable lives in TPG_CTRL, so clear it
>> + * first; v2.4.0+ drives both test-enable and reset through TPG_CTRL_CMD.
>> + */
>> + if (tpg->hw_version < TPG_HW_VER_2_4_0)
>> + writel(0, tpg->base + TPG_CTRL);
>
> [Severity: Medium]
> Will this execute the legacy reset logic on v2.4.0+ hardware during the
> first power-on sequence?
>
> When the driver powers up the device, tpg_set_power() calls the reset
> function before calling hw_version():
>
> drivers/media/platform/qcom/camss/camss-tpg.c:tpg_set_power() {
> ...
> tpg->res->hw_ops->reset(tpg);
> tpg->res->hw_ops->hw_version(tpg);
> ...
> }
>
> Because the tpg object is zero-initialized and tpg->hw_version is not
> populated until after the reset function is called, tpg->hw_version
> is strictly 0 during the first execution of tpg_reset().
>
> Does this mean the condition here evaluates to true for all hardware
> versions on the initial power-up, inadvertently causing an unintended
> write to TPG_CTRL?
>
>> +
>> + writel(TPG_CTRL_CMD_HW_RESET, tpg->base + TPG_CTRL_CMD);
>>
>> return 0;
>> }
>
No. The version data is always valid no matter the reset is called or not.
Best Regards,
Hangxiang
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: [PATCH v17 09/11] arm64: dts: qcom: kaanapali: Add CAMSS and CSIPHY block definitions
2026-09-29 6:11 ` sashiko-bot
@ 2026-09-30 14:17 ` Hangxiang Ma
-1 siblings, 0 replies; 58+ messages in thread
From: Hangxiang Ma @ 2026-09-30 14:17 UTC (permalink / raw)
To: sashiko-reviews
Cc: linux-phy, robh, conor+dt, media-ci, vkoul, neil.armstrong,
devicetree, olteanv
On 9/29/2026 2:11 PM, sashiko-bot@kernel.org wrote:
> Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
> - [Medium] dts: missing #phy-cells in CSIPHY nodes breaks phy lookup
> --
>
> commit 0d5dc943d2ac26c65efdf11a56970db1bd7ff6f9
> Author: Hangxiang Ma <hangxiang.ma@oss.qualcomm.com>
>
> arm64: dts: qcom: kaanapali: Add CAMSS and CSIPHY block definitions
>
> This commit adds device tree nodes for the CAMSS and CSIPHY blocks on the
> Kaanapali platform. These definitions enable camera pipelines to be configured
> and used by board-specific device trees.
>
>> diff --git a/arch/arm64/boot/dts/qcom/kaanapali.dtsi b/arch/arm64/boot/dts/qcom/kaanapali.dtsi
>> index 3e63e62251089..7a80438bde570 100644
>> --- a/arch/arm64/boot/dts/qcom/kaanapali.dtsi
>> +++ b/arch/arm64/boot/dts/qcom/kaanapali.dtsi
>
> [ ... ]
>
>> @@ -3595,6 +3596,307 @@ usb_dp_qmpphy_dp_in: endpoint {
>> };
>> };
>>
>> + camss: isp@9253000 {
>
> [ ... ]
>
>> + csiphy0: phy@9523000 {
>> + compatible = "qcom,kaanapali-csi2-phy";
>> + reg = <0x0 0x09523000 0x0 0x2000>;
>
> [Severity: Medium]
> Does this node need a #phy-cells property? The generic PHY framework requires
> this for consumers to successfully probe.
>
> The qcom,kaanapali-csi2-phy compatible binds to a generic PHY provider via
> devm_of_phy_provider_register(dev, of_phy_simple_xlate). When a consumer
> calls phy_get(), the PHY core invokes of_parse_phandle_with_args() to parse
> the reference.
>
> Without #phy-cells = <0>; in this and the other csiphy nodes (csiphy0 through
> csiphy5) in arch/arm64/boot/dts/qcom/kaanapali.dtsi, the translation will fail,
> leaving the consumer devices non-functional.
>
>> +
>> + clocks = <&camcc CAM_CC_CSIPHY0_CLK>,
>> + <&camcc CAM_CC_CSI0PHYTIMER_CLK>,
>> + <&camcc CAM_CC_CORE_AHB_CLK>;
>
> [ ... ]
>
This node style aligns with the x1e80100 example:
https://lore.kernel.org/all/20260917-x1e-camss-csi2-phy-dtsi-v7-4-1a63eb35838b@linaro.org/
Best Regards,
Hangxiang
^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: [PATCH v17 09/11] arm64: dts: qcom: kaanapali: Add CAMSS and CSIPHY block definitions
@ 2026-09-30 14:17 ` Hangxiang Ma
0 siblings, 0 replies; 58+ messages in thread
From: Hangxiang Ma @ 2026-09-30 14:17 UTC (permalink / raw)
To: sashiko-reviews
Cc: linux-phy, robh, conor+dt, media-ci, vkoul, neil.armstrong,
devicetree, olteanv
On 9/29/2026 2:11 PM, sashiko-bot@kernel.org wrote:
> Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
> - [Medium] dts: missing #phy-cells in CSIPHY nodes breaks phy lookup
> --
>
> commit 0d5dc943d2ac26c65efdf11a56970db1bd7ff6f9
> Author: Hangxiang Ma <hangxiang.ma@oss.qualcomm.com>
>
> arm64: dts: qcom: kaanapali: Add CAMSS and CSIPHY block definitions
>
> This commit adds device tree nodes for the CAMSS and CSIPHY blocks on the
> Kaanapali platform. These definitions enable camera pipelines to be configured
> and used by board-specific device trees.
>
>> diff --git a/arch/arm64/boot/dts/qcom/kaanapali.dtsi b/arch/arm64/boot/dts/qcom/kaanapali.dtsi
>> index 3e63e62251089..7a80438bde570 100644
>> --- a/arch/arm64/boot/dts/qcom/kaanapali.dtsi
>> +++ b/arch/arm64/boot/dts/qcom/kaanapali.dtsi
>
> [ ... ]
>
>> @@ -3595,6 +3596,307 @@ usb_dp_qmpphy_dp_in: endpoint {
>> };
>> };
>>
>> + camss: isp@9253000 {
>
> [ ... ]
>
>> + csiphy0: phy@9523000 {
>> + compatible = "qcom,kaanapali-csi2-phy";
>> + reg = <0x0 0x09523000 0x0 0x2000>;
>
> [Severity: Medium]
> Does this node need a #phy-cells property? The generic PHY framework requires
> this for consumers to successfully probe.
>
> The qcom,kaanapali-csi2-phy compatible binds to a generic PHY provider via
> devm_of_phy_provider_register(dev, of_phy_simple_xlate). When a consumer
> calls phy_get(), the PHY core invokes of_parse_phandle_with_args() to parse
> the reference.
>
> Without #phy-cells = <0>; in this and the other csiphy nodes (csiphy0 through
> csiphy5) in arch/arm64/boot/dts/qcom/kaanapali.dtsi, the translation will fail,
> leaving the consumer devices non-functional.
>
>> +
>> + clocks = <&camcc CAM_CC_CSIPHY0_CLK>,
>> + <&camcc CAM_CC_CSI0PHYTIMER_CLK>,
>> + <&camcc CAM_CC_CORE_AHB_CLK>;
>
> [ ... ]
>
This node style aligns with the x1e80100 example:
https://lore.kernel.org/all/20260917-x1e-camss-csi2-phy-dtsi-v7-4-1a63eb35838b@linaro.org/
Best Regards,
Hangxiang
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: [PATCH v17 11/11] arm64: dts: qcom: kaanapali: Add camera MCLK pinctrl
2026-09-29 6:07 ` sashiko-bot
@ 2026-09-30 14:23 ` Hangxiang Ma
-1 siblings, 0 replies; 58+ messages in thread
From: Hangxiang Ma @ 2026-09-30 14:23 UTC (permalink / raw)
To: sashiko-reviews
Cc: media-ci, robh, devicetree, vkoul, linux-phy, olteanv,
neil.armstrong, conor+dt
On 9/29/2026 2:07 PM, sashiko-bot@kernel.org wrote:
> Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
> - [Low] dts: devicetree node names incorrectly use underscores
> --
>
> commit 185a6cf958fbea99362a9e2c9f3989dad4362d3c
> Author: Hangxiang Ma <hangxiang.ma@oss.qualcomm.com>
>
> arm64: dts: qcom: kaanapali: Add camera MCLK pinctrl
>
> This commit adds TLMM pinctrl states for the camera master clock GPIOs on
> Kaanapali so camera sensor nodes can select the proper MCLK pin functions
> when enabled.
>
>> diff --git a/arch/arm64/boot/dts/qcom/kaanapali.dtsi b/arch/arm64/boot/dts/qcom/kaanapali.dtsi
>> index c19945bc438eb..bbcd5a622f0b2 100644
>> --- a/arch/arm64/boot/dts/qcom/kaanapali.dtsi
>> +++ b/arch/arm64/boot/dts/qcom/kaanapali.dtsi
> [ ... ]
>> + cam_mclk2_default: cam-mclk2-default-state {
>> + pins = "gpio91";
>> + function = "cam_asc_mclk2";
>> + drive-strength = <2>;
>> + bias-disable;
>> + };
>> +
>> + cam_mclk3_default: cam_mclk3-default-state {
>
> [Severity: Low]
> Does this node name incorrectly use an underscore instead of a hyphen?
>
> Devicetree node names conventionally use hyphens rather than underscores.
> The previous nodes like cam-mclk0-default-state use the correct hyphenated
> pattern.
>
> Using an underscore here and in the subsequent cam_mclk4 through cam_mclk7
> nodes will trigger dtc style warnings (node_name_chars_strict) and fail
> standard devicetree style checks.
>
>> + pins = "gpio92";
>> + function = "cam_mclk";
>> + drive-strength = <2>;
>> + bias-disable;
>> + };
> [ ... ]
>
Yes. I change original names to align with Glymur style but makes this
mistake. Will fix it in next revision.
Best Regards,
Hangxiang
^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: [PATCH v17 11/11] arm64: dts: qcom: kaanapali: Add camera MCLK pinctrl
@ 2026-09-30 14:23 ` Hangxiang Ma
0 siblings, 0 replies; 58+ messages in thread
From: Hangxiang Ma @ 2026-09-30 14:23 UTC (permalink / raw)
To: sashiko-reviews
Cc: media-ci, robh, devicetree, vkoul, linux-phy, olteanv,
neil.armstrong, conor+dt
On 9/29/2026 2:07 PM, sashiko-bot@kernel.org wrote:
> Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
> - [Low] dts: devicetree node names incorrectly use underscores
> --
>
> commit 185a6cf958fbea99362a9e2c9f3989dad4362d3c
> Author: Hangxiang Ma <hangxiang.ma@oss.qualcomm.com>
>
> arm64: dts: qcom: kaanapali: Add camera MCLK pinctrl
>
> This commit adds TLMM pinctrl states for the camera master clock GPIOs on
> Kaanapali so camera sensor nodes can select the proper MCLK pin functions
> when enabled.
>
>> diff --git a/arch/arm64/boot/dts/qcom/kaanapali.dtsi b/arch/arm64/boot/dts/qcom/kaanapali.dtsi
>> index c19945bc438eb..bbcd5a622f0b2 100644
>> --- a/arch/arm64/boot/dts/qcom/kaanapali.dtsi
>> +++ b/arch/arm64/boot/dts/qcom/kaanapali.dtsi
> [ ... ]
>> + cam_mclk2_default: cam-mclk2-default-state {
>> + pins = "gpio91";
>> + function = "cam_asc_mclk2";
>> + drive-strength = <2>;
>> + bias-disable;
>> + };
>> +
>> + cam_mclk3_default: cam_mclk3-default-state {
>
> [Severity: Low]
> Does this node name incorrectly use an underscore instead of a hyphen?
>
> Devicetree node names conventionally use hyphens rather than underscores.
> The previous nodes like cam-mclk0-default-state use the correct hyphenated
> pattern.
>
> Using an underscore here and in the subsequent cam_mclk4 through cam_mclk7
> nodes will trigger dtc style warnings (node_name_chars_strict) and fail
> standard devicetree style checks.
>
>> + pins = "gpio92";
>> + function = "cam_mclk";
>> + drive-strength = <2>;
>> + bias-disable;
>> + };
> [ ... ]
>
Yes. I change original names to align with Glymur style but makes this
mistake. Will fix it in next revision.
Best Regards,
Hangxiang
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: [PATCH v17 06/11] media: qcom: camss: csid: Add support for CSID Gen4
2026-09-29 6:17 ` sashiko-bot
@ 2026-10-03 5:32 ` Hangxiang Ma
-1 siblings, 0 replies; 58+ messages in thread
From: Hangxiang Ma @ 2026-10-03 5:32 UTC (permalink / raw)
To: sashiko-reviews
Cc: neil.armstrong, vkoul, devicetree, linux-phy, media-ci, robh,
olteanv, conor+dt
On 9/29/2026 2:17 PM, sashiko-bot@kernel.org wrote:
> Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
> - [High] media: qcom/camss: data race on csid->aup_update and rup_update
> - [Medium] media: qcom/camss: integer underflow in __csid_configure_rx
> --
>
> commit 611abdeb4b5da574ae292d1ff736d0d71f2f4ed2
> Author: Hangxiang Ma <hangxiang.ma@oss.qualcomm.com>
>
> media: qcom: camss: csid: Add support for CSID Gen4
>
> Add support for the CSID Gen4 hardware found on Kaanapali SoC.
>
> Introduce Gen4 resource descriptions and implement the hardware-specific
> register programming, reset sequence, and BUF_DONE interrupt handling.
>
> Gen4 splits RUP and AUP updates into separate registers and uses a SET
> register to commit the updates. Update the CSID interface to support
> both this scheme and the legacy combined reg_update mechanism.
>
>> diff --git a/drivers/media/platform/qcom/camss/camss-csid-gen4.c b/drivers/media/platform/qcom/camss/camss-csid-gen4.c
>> new file mode 100644
>> index 0000000000000..4ff2f41f70f7e
>> --- /dev/null
>> +++ b/drivers/media/platform/qcom/camss/camss-csid-gen4.c
> [ ... ]
>> +static void __csid_aup_rup_clear(struct csid_device *csid, int port_id)
>> +{
>> + /* Hardware clears the registers upon consuming the settings */
>> + csid->aup_update &= ~CSID_RUP_AUP_RDI(port_id);
>> + csid->rup_update &= ~CSID_RUP_AUP_RDI(port_id);
>> +}
>> +
>> +static void __csid_aup_update(struct csid_device *csid, int port_id)
>> +{
>> + csid->aup_update |= CSID_RUP_AUP_RDI(port_id);
>> + writel(csid->aup_update, csid->base + CSID_AUP_CMD);
>> +
>> + __csid_aup_rup_trigger(csid);
>> +}
>> +
>> +static void __csid_reg_update(struct csid_device *csid, int port_id)
>> +{
>> + csid->rup_update |= CSID_RUP_AUP_RDI(port_id);
>> + writel(csid->rup_update, csid->base + CSID_RUP_CMD);
>> +
>> + __csid_aup_rup_trigger(csid);
>> +}
>
> [Severity: High]
> Does this introduce a data race on csid->aup_update and csid->rup_update?
>
> If a stream is configured in process context via csid_set_stream(),
> __csid_aup_update() and __csid_reg_update() modify the shared state with
> non-atomic bitwise operations (|=).
>
> If an interrupt (such as RUP_DONE) fires concurrently for an already running
> stream, csid_isr() will execute and call __csid_aup_rup_clear(), which modifies
> the same variables using non-atomic bitwise clear operations (&= ~).
>
> Because these bitwise operations lack locking, could the interrupt's
> modifications be lost, causing the hardware to receive an invalid AUP/RUP
> command mask? This might lead to broken streaming when dynamically configuring
> multiple virtual channels.
>
Additional reply for this. As this relates to CAMSS arch so that a
separate series will take care this. Kaanapali series will continue
focusing on the platform enabling. Thanks.
Best Regards,
Hangxiang
On Tue, Sep 29, 2026 at 2:17 PM <sashiko-bot@kernel.org> wrote:
>
> Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
> - [High] media: qcom/camss: data race on csid->aup_update and rup_update
> - [Medium] media: qcom/camss: integer underflow in __csid_configure_rx
> --
>
> commit 611abdeb4b5da574ae292d1ff736d0d71f2f4ed2
> Author: Hangxiang Ma <hangxiang.ma@oss.qualcomm.com>
>
> media: qcom: camss: csid: Add support for CSID Gen4
>
> Add support for the CSID Gen4 hardware found on Kaanapali SoC.
>
> Introduce Gen4 resource descriptions and implement the hardware-specific
> register programming, reset sequence, and BUF_DONE interrupt handling.
>
> Gen4 splits RUP and AUP updates into separate registers and uses a SET
> register to commit the updates. Update the CSID interface to support
> both this scheme and the legacy combined reg_update mechanism.
>
> > diff --git a/drivers/media/platform/qcom/camss/camss-csid-gen4.c b/drivers/media/platform/qcom/camss/camss-csid-gen4.c
> > new file mode 100644
> > index 0000000000000..4ff2f41f70f7e
> > --- /dev/null
> > +++ b/drivers/media/platform/qcom/camss/camss-csid-gen4.c
> [ ... ]
> > +static void __csid_aup_rup_clear(struct csid_device *csid, int port_id)
> > +{
> > + /* Hardware clears the registers upon consuming the settings */
> > + csid->aup_update &= ~CSID_RUP_AUP_RDI(port_id);
> > + csid->rup_update &= ~CSID_RUP_AUP_RDI(port_id);
> > +}
> > +
> > +static void __csid_aup_update(struct csid_device *csid, int port_id)
> > +{
> > + csid->aup_update |= CSID_RUP_AUP_RDI(port_id);
> > + writel(csid->aup_update, csid->base + CSID_AUP_CMD);
> > +
> > + __csid_aup_rup_trigger(csid);
> > +}
> > +
> > +static void __csid_reg_update(struct csid_device *csid, int port_id)
> > +{
> > + csid->rup_update |= CSID_RUP_AUP_RDI(port_id);
> > + writel(csid->rup_update, csid->base + CSID_RUP_CMD);
> > +
> > + __csid_aup_rup_trigger(csid);
> > +}
>
> [Severity: High]
> Does this introduce a data race on csid->aup_update and csid->rup_update?
>
> If a stream is configured in process context via csid_set_stream(),
> __csid_aup_update() and __csid_reg_update() modify the shared state with
> non-atomic bitwise operations (|=).
>
> If an interrupt (such as RUP_DONE) fires concurrently for an already running
> stream, csid_isr() will execute and call __csid_aup_rup_clear(), which modifies
> the same variables using non-atomic bitwise clear operations (&= ~).
>
> Because these bitwise operations lack locking, could the interrupt's
> modifications be lost, causing the hardware to receive an invalid AUP/RUP
> command mask? This might lead to broken streaming when dynamically configuring
> multiple virtual channels.
>
> > +
> > +static void __csid_configure_rx(struct csid_device *csid,
> > + struct csid_phy_config *phy)
> > +{
> > + int val;
> > +
> > + val = (phy->lane_cnt - 1) << CSI2_RX_CFG0_NUM_ACTIVE_LANES;
> > + val |= phy->lane_assign << CSI2_RX_CFG0_DL0_INPUT_SEL;
> > + val |= (phy->csiphy_id + CSI2_RX_CFG0_PHY_SEL_BASE_IDX)
> > + << CSI2_RX_CFG0_PHY_NUM_SEL;
> > + writel(val, csid->base + CSID_CSI2_RX_CFG0);
>
> [Severity: Medium]
> Can this code underflow if phy->lane_cnt is 0?
>
> If the device tree incorrectly omits the data-lanes property, phy->lane_cnt can
> evaluate to 0.
>
> While __csid_configure_rdi_stream() provides a fallback for this scenario:
>
> if (!lane_cnt)
> lane_cnt = 4;
>
> __csid_configure_rx() omits this check. If phy->lane_cnt is 0,
> (phy->lane_cnt - 1) underflows to -1. This would result in writing 0xFFFFFFFF
> to CSID_CSI2_RX_CFG0, clobbering all its fields.
>
> Should there be a similar fallback or validation check here to prevent
> hardware misconfiguration?
>
> --
> Sashiko AI review · https://sashiko.dev/#/patchset/20260928-kaanapali-camss-v17-0-dcf3fd37f76c@oss.qualcomm.com?part=6
^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: [PATCH v17 06/11] media: qcom: camss: csid: Add support for CSID Gen4
@ 2026-10-03 5:32 ` Hangxiang Ma
0 siblings, 0 replies; 58+ messages in thread
From: Hangxiang Ma @ 2026-10-03 5:32 UTC (permalink / raw)
To: sashiko-reviews
Cc: neil.armstrong, vkoul, devicetree, linux-phy, media-ci, robh,
olteanv, conor+dt
On 9/29/2026 2:17 PM, sashiko-bot@kernel.org wrote:
> Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
> - [High] media: qcom/camss: data race on csid->aup_update and rup_update
> - [Medium] media: qcom/camss: integer underflow in __csid_configure_rx
> --
>
> commit 611abdeb4b5da574ae292d1ff736d0d71f2f4ed2
> Author: Hangxiang Ma <hangxiang.ma@oss.qualcomm.com>
>
> media: qcom: camss: csid: Add support for CSID Gen4
>
> Add support for the CSID Gen4 hardware found on Kaanapali SoC.
>
> Introduce Gen4 resource descriptions and implement the hardware-specific
> register programming, reset sequence, and BUF_DONE interrupt handling.
>
> Gen4 splits RUP and AUP updates into separate registers and uses a SET
> register to commit the updates. Update the CSID interface to support
> both this scheme and the legacy combined reg_update mechanism.
>
>> diff --git a/drivers/media/platform/qcom/camss/camss-csid-gen4.c b/drivers/media/platform/qcom/camss/camss-csid-gen4.c
>> new file mode 100644
>> index 0000000000000..4ff2f41f70f7e
>> --- /dev/null
>> +++ b/drivers/media/platform/qcom/camss/camss-csid-gen4.c
> [ ... ]
>> +static void __csid_aup_rup_clear(struct csid_device *csid, int port_id)
>> +{
>> + /* Hardware clears the registers upon consuming the settings */
>> + csid->aup_update &= ~CSID_RUP_AUP_RDI(port_id);
>> + csid->rup_update &= ~CSID_RUP_AUP_RDI(port_id);
>> +}
>> +
>> +static void __csid_aup_update(struct csid_device *csid, int port_id)
>> +{
>> + csid->aup_update |= CSID_RUP_AUP_RDI(port_id);
>> + writel(csid->aup_update, csid->base + CSID_AUP_CMD);
>> +
>> + __csid_aup_rup_trigger(csid);
>> +}
>> +
>> +static void __csid_reg_update(struct csid_device *csid, int port_id)
>> +{
>> + csid->rup_update |= CSID_RUP_AUP_RDI(port_id);
>> + writel(csid->rup_update, csid->base + CSID_RUP_CMD);
>> +
>> + __csid_aup_rup_trigger(csid);
>> +}
>
> [Severity: High]
> Does this introduce a data race on csid->aup_update and csid->rup_update?
>
> If a stream is configured in process context via csid_set_stream(),
> __csid_aup_update() and __csid_reg_update() modify the shared state with
> non-atomic bitwise operations (|=).
>
> If an interrupt (such as RUP_DONE) fires concurrently for an already running
> stream, csid_isr() will execute and call __csid_aup_rup_clear(), which modifies
> the same variables using non-atomic bitwise clear operations (&= ~).
>
> Because these bitwise operations lack locking, could the interrupt's
> modifications be lost, causing the hardware to receive an invalid AUP/RUP
> command mask? This might lead to broken streaming when dynamically configuring
> multiple virtual channels.
>
Additional reply for this. As this relates to CAMSS arch so that a
separate series will take care this. Kaanapali series will continue
focusing on the platform enabling. Thanks.
Best Regards,
Hangxiang
On Tue, Sep 29, 2026 at 2:17 PM <sashiko-bot@kernel.org> wrote:
>
> Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
> - [High] media: qcom/camss: data race on csid->aup_update and rup_update
> - [Medium] media: qcom/camss: integer underflow in __csid_configure_rx
> --
>
> commit 611abdeb4b5da574ae292d1ff736d0d71f2f4ed2
> Author: Hangxiang Ma <hangxiang.ma@oss.qualcomm.com>
>
> media: qcom: camss: csid: Add support for CSID Gen4
>
> Add support for the CSID Gen4 hardware found on Kaanapali SoC.
>
> Introduce Gen4 resource descriptions and implement the hardware-specific
> register programming, reset sequence, and BUF_DONE interrupt handling.
>
> Gen4 splits RUP and AUP updates into separate registers and uses a SET
> register to commit the updates. Update the CSID interface to support
> both this scheme and the legacy combined reg_update mechanism.
>
> > diff --git a/drivers/media/platform/qcom/camss/camss-csid-gen4.c b/drivers/media/platform/qcom/camss/camss-csid-gen4.c
> > new file mode 100644
> > index 0000000000000..4ff2f41f70f7e
> > --- /dev/null
> > +++ b/drivers/media/platform/qcom/camss/camss-csid-gen4.c
> [ ... ]
> > +static void __csid_aup_rup_clear(struct csid_device *csid, int port_id)
> > +{
> > + /* Hardware clears the registers upon consuming the settings */
> > + csid->aup_update &= ~CSID_RUP_AUP_RDI(port_id);
> > + csid->rup_update &= ~CSID_RUP_AUP_RDI(port_id);
> > +}
> > +
> > +static void __csid_aup_update(struct csid_device *csid, int port_id)
> > +{
> > + csid->aup_update |= CSID_RUP_AUP_RDI(port_id);
> > + writel(csid->aup_update, csid->base + CSID_AUP_CMD);
> > +
> > + __csid_aup_rup_trigger(csid);
> > +}
> > +
> > +static void __csid_reg_update(struct csid_device *csid, int port_id)
> > +{
> > + csid->rup_update |= CSID_RUP_AUP_RDI(port_id);
> > + writel(csid->rup_update, csid->base + CSID_RUP_CMD);
> > +
> > + __csid_aup_rup_trigger(csid);
> > +}
>
> [Severity: High]
> Does this introduce a data race on csid->aup_update and csid->rup_update?
>
> If a stream is configured in process context via csid_set_stream(),
> __csid_aup_update() and __csid_reg_update() modify the shared state with
> non-atomic bitwise operations (|=).
>
> If an interrupt (such as RUP_DONE) fires concurrently for an already running
> stream, csid_isr() will execute and call __csid_aup_rup_clear(), which modifies
> the same variables using non-atomic bitwise clear operations (&= ~).
>
> Because these bitwise operations lack locking, could the interrupt's
> modifications be lost, causing the hardware to receive an invalid AUP/RUP
> command mask? This might lead to broken streaming when dynamically configuring
> multiple virtual channels.
>
> > +
> > +static void __csid_configure_rx(struct csid_device *csid,
> > + struct csid_phy_config *phy)
> > +{
> > + int val;
> > +
> > + val = (phy->lane_cnt - 1) << CSI2_RX_CFG0_NUM_ACTIVE_LANES;
> > + val |= phy->lane_assign << CSI2_RX_CFG0_DL0_INPUT_SEL;
> > + val |= (phy->csiphy_id + CSI2_RX_CFG0_PHY_SEL_BASE_IDX)
> > + << CSI2_RX_CFG0_PHY_NUM_SEL;
> > + writel(val, csid->base + CSID_CSI2_RX_CFG0);
>
> [Severity: Medium]
> Can this code underflow if phy->lane_cnt is 0?
>
> If the device tree incorrectly omits the data-lanes property, phy->lane_cnt can
> evaluate to 0.
>
> While __csid_configure_rdi_stream() provides a fallback for this scenario:
>
> if (!lane_cnt)
> lane_cnt = 4;
>
> __csid_configure_rx() omits this check. If phy->lane_cnt is 0,
> (phy->lane_cnt - 1) underflows to -1. This would result in writing 0xFFFFFFFF
> to CSID_CSI2_RX_CFG0, clobbering all its fields.
>
> Should there be a similar fallback or validation check here to prevent
> hardware misconfiguration?
>
> --
> Sashiko AI review · https://sashiko.dev/#/patchset/20260928-kaanapali-camss-v17-0-dcf3fd37f76c@oss.qualcomm.com?part=6
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply [flat|nested] 58+ messages in thread
end of thread, other threads:[~2026-10-03 5:33 UTC | newest]
Thread overview: 58+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2026-09-29 6:00 [PATCH v17 00/11] media: qcom: camss: Add Kaanapali support Hangxiang Ma
2026-09-29 6:00 ` Hangxiang Ma
2026-09-29 6:00 ` [PATCH v17 01/11] dt-bindings: phy: qcom,x1e80100-csi2-phy: Add Kaanapali CSI2 PHY Hangxiang Ma
2026-09-29 6:00 ` Hangxiang Ma
2026-09-30 10:33 ` Krzysztof Kozlowski
2026-09-30 10:33 ` Krzysztof Kozlowski
2026-09-29 6:00 ` [PATCH v17 02/11] media: dt-bindings: Add CAMSS device for Kaanapali Hangxiang Ma
2026-09-29 6:00 ` Hangxiang Ma
2026-09-29 6:08 ` sashiko-bot
2026-09-29 6:08 ` sashiko-bot
2026-09-30 12:54 ` Hangxiang Ma
2026-09-30 12:54 ` Hangxiang Ma
2026-09-30 10:34 ` Krzysztof Kozlowski
2026-09-30 10:34 ` Krzysztof Kozlowski
2026-09-29 6:00 ` [PATCH v17 03/11] media: qcom: camss: Add Kaanapali compatible Hangxiang Ma
2026-09-29 6:00 ` Hangxiang Ma
2026-09-29 6:00 ` [PATCH v17 04/11] phy: qcom-mipi-csi2: Parametrise the common status register offset Hangxiang Ma
2026-09-29 6:00 ` Hangxiang Ma
2026-09-29 6:00 ` [PATCH v17 05/11] media: qcom: camss: csiphy: Add support for v2.4.0 two-phase CSIPHY Hangxiang Ma
2026-09-29 6:00 ` Hangxiang Ma
2026-09-29 6:17 ` sashiko-bot
2026-09-29 6:17 ` sashiko-bot
2026-09-30 13:01 ` Hangxiang Ma
2026-09-30 13:01 ` Hangxiang Ma
2026-09-29 6:00 ` [PATCH v17 06/11] media: qcom: camss: csid: Add support for CSID Gen4 Hangxiang Ma
2026-09-29 6:00 ` Hangxiang Ma
2026-09-29 6:17 ` sashiko-bot
2026-09-29 6:17 ` sashiko-bot
2026-09-30 13:54 ` Hangxiang Ma
2026-09-30 13:54 ` Hangxiang Ma
2026-10-03 5:32 ` Hangxiang Ma
2026-10-03 5:32 ` Hangxiang Ma
2026-09-29 6:00 ` [PATCH v17 07/11] media: qcom: camss: vfe: Add support for VFE Gen4 Hangxiang Ma
2026-09-29 6:00 ` Hangxiang Ma
2026-09-29 6:17 ` sashiko-bot
2026-09-29 6:17 ` sashiko-bot
2026-09-30 14:07 ` Hangxiang Ma
2026-09-30 14:07 ` Hangxiang Ma
2026-09-29 6:00 ` [PATCH v17 08/11] media: qcom: camss: tpg: Add support for v2.4.0 TPG Hangxiang Ma
2026-09-29 6:00 ` Hangxiang Ma
2026-09-29 6:12 ` sashiko-bot
2026-09-29 6:12 ` sashiko-bot
2026-09-30 14:12 ` Hangxiang Ma
2026-09-30 14:12 ` Hangxiang Ma
2026-09-29 6:00 ` [PATCH v17 09/11] arm64: dts: qcom: kaanapali: Add CAMSS and CSIPHY block definitions Hangxiang Ma
2026-09-29 6:00 ` Hangxiang Ma
2026-09-29 6:11 ` sashiko-bot
2026-09-29 6:11 ` sashiko-bot
2026-09-30 14:17 ` Hangxiang Ma
2026-09-30 14:17 ` Hangxiang Ma
2026-09-29 6:00 ` [PATCH v17 10/11] arm64: dts: qcom: kaanapali: Add CCI controller nodes Hangxiang Ma
2026-09-29 6:00 ` Hangxiang Ma
2026-09-29 6:00 ` [PATCH v17 11/11] arm64: dts: qcom: kaanapali: Add camera MCLK pinctrl Hangxiang Ma
2026-09-29 6:00 ` Hangxiang Ma
2026-09-29 6:07 ` sashiko-bot
2026-09-29 6:07 ` sashiko-bot
2026-09-30 14:23 ` Hangxiang Ma
2026-09-30 14:23 ` Hangxiang Ma
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.