* [PATCH v21 00/14] media: qcom: camss: Add Kaanapali support
@ 2026-10-12 6:45 ` Hangxiang Ma
0 siblings, 0 replies; 48+ messages in thread
From: Hangxiang Ma @ 2026-10-12 6:45 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,
Krzysztof Kozlowski, 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
PHY driver part for maintainer Vinod Koul (3):
[1] dt-bindings: phy: qcom,x1e80100-csi2-phy: Add Kaanapali CSI2 PHY
[2] phy: qcom-mipi-csi2: Parametrise the common status register offset
[3] phy: qcom-mipi-csi2: Add Kaanapali support
CAMSS driver and DTS part for maintainer Bryan O'Donoghue (11):
[1] media: qcom: camss: Issue stream-on REG_UPDATE from CSID
[2] media: dt-bindings: Add CAMSS device for Kaanapali
[3] media: qcom: camss: Add Kaanapali compatible
[4] media: qcom: camss: csiphy: Add support for v2.4.0 two-phase CSIPHY
[5] media: qcom: camss: csid: Add support for CSID 1080
[6] media: qcom: camss: vfe: Add support for VFE 1080
[7] media: qcom: camss: tpg: Add support for v2.4.0 TPG
[8] arm64: dts: qcom: kaanapali: Add CAMSS and CSIPHY block definitions
[9] arm64: dts: qcom: kaanapali: Add CCI controller nodes
[10] arm64: dts: qcom: kaanapali: Add camera MCLK pinctrl
[11] arm64: dts: qcom: kaanapali-mtp-camera-s5kjn5: Add DT overlay
Signed-off-by: Hangxiang Ma <hangxiang.ma@oss.qualcomm.com>
---
Changes in v21:
- Drop reg_update_after_csid_config flag. Skip the VFE-side stream-on
REG_UPDATE only when the connected CSID implements reg_update - bod
- Add address and size cell properties in camera node to avoid
potential warnings during compilation
- Link to v20: https://patch.msgid.link/20261010-kaanapali-camss-v20-0-63e98ce9ac0c@oss.qualcomm.com
Changes in v20:
- Remove the redundant null check for reg_update_clear in VFE - bod
- Define the port property for CSIPHY nodes and align the style of
CAMSS and CSIPHY nodes - bod
- Replace bias-pull-up and bias-pull-down with bias-disable for the
SCL/SDA pins of CCI nodes in TLMM, as internal weak pull is inproper
with existing board level pull up resistors - Loic
- Align the if-else condition in TPG version judgement and remove the
redundant comments in TPG code but describe the hardware changes in
commit description
- Add Kaanapali camera subsystem and S5KJN5 enablement dtso
- Link to v19: https://patch.msgid.link/20261008-kaanapali-camss-v19-0-b2c583ef50e0@oss.qualcomm.com
Changes in v19:
- Remove the internal CSIPHY hardware operations for CAMSS - bod
- Collect RBs tags from Bryan and Rob for CAMSS binding - bod/Rob
- Split the PHY and CAMSS into separate parts and document the
corresponding maintainers in cover letter - bod
- Link to v18: https://patch.msgid.link/20261003-kaanapali-camss-v18-0-87ba4ebe0db1@oss.qualcomm.com
Changes in v18:
- Rename CSID and VFE hardware version from Gen4 to 1080 - bod
- Correct the description for CAMSS ports in binding - Krzysztof
- Add lane count fallback path for CSID RX configuration - Sashiko
- Align the TFE lite line count with the commit description - Sashiko
- Use hyphenated pattern for MCLK node names - Sashiko
- Resolve conflicts introduced by Glymur in CSI2 PHY binding
- Correct the spelling mistakes in cover letter and enhance commit
description for compatible and CSIPHY
- Link to v17: https://lore.kernel.org/r/20260928-kaanapali-camss-v17-0-dcf3fd37f76c@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 (14):
dt-bindings: phy: qcom,x1e80100-csi2-phy: Add Kaanapali CSI2 PHY
phy: qcom-mipi-csi2: Parametrise the common status register offset
phy: qcom-mipi-csi2: Add Kaanapali support
media: qcom: camss: Issue stream-on REG_UPDATE from CSID
media: dt-bindings: Add CAMSS device for Kaanapali
media: qcom: camss: Add Kaanapali compatible
media: qcom: camss: csiphy: Add support for v2.4.0 two-phase CSIPHY
media: qcom: camss: csid: Add support for CSID 1080
media: qcom: camss: vfe: Add support for VFE 1080
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
arm64: dts: qcom: kaanapali-mtp-camera-s5kjn5: Add DT overlay
.../bindings/media/qcom,kaanapali-camss.yaml | 303 ++++++++
.../bindings/phy/qcom,x1e80100-csi2-phy.yaml | 4 +-
arch/arm64/boot/dts/qcom/Makefile | 5 +
.../boot/dts/qcom/kaanapali-mtp-camera-s5kjn5.dtso | 81 +++
arch/arm64/boot/dts/qcom/kaanapali-mtp.dts | 7 +
arch/arm64/boot/dts/qcom/kaanapali.dtsi | 761 +++++++++++++++++++++
drivers/media/platform/qcom/camss/Makefile | 2 +
.../media/platform/qcom/camss/camss-csid-1080.c | 395 +++++++++++
drivers/media/platform/qcom/camss/camss-csid-680.c | 3 +
.../media/platform/qcom/camss/camss-csid-gen3.c | 3 +
drivers/media/platform/qcom/camss/camss-csid.h | 9 +-
drivers/media/platform/qcom/camss/camss-tpg-gen1.c | 23 +-
drivers/media/platform/qcom/camss/camss-vfe-1080.c | 197 ++++++
drivers/media/platform/qcom/camss/camss-vfe.c | 39 +-
drivers/media/platform/qcom/camss/camss-vfe.h | 1 +
drivers/media/platform/qcom/camss/camss.c | 294 ++++++++
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 +
20 files changed, 2149 insertions(+), 14 deletions(-)
---
base-commit: c74ef2fbf60ff7e7b956c023a881e87502c1852a
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] 48+ messages in thread
* [PATCH v21 00/14] media: qcom: camss: Add Kaanapali support
@ 2026-10-12 6:45 ` Hangxiang Ma
0 siblings, 0 replies; 48+ messages in thread
From: Hangxiang Ma @ 2026-10-12 6:45 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,
Krzysztof Kozlowski, 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
PHY driver part for maintainer Vinod Koul (3):
[1] dt-bindings: phy: qcom,x1e80100-csi2-phy: Add Kaanapali CSI2 PHY
[2] phy: qcom-mipi-csi2: Parametrise the common status register offset
[3] phy: qcom-mipi-csi2: Add Kaanapali support
CAMSS driver and DTS part for maintainer Bryan O'Donoghue (11):
[1] media: qcom: camss: Issue stream-on REG_UPDATE from CSID
[2] media: dt-bindings: Add CAMSS device for Kaanapali
[3] media: qcom: camss: Add Kaanapali compatible
[4] media: qcom: camss: csiphy: Add support for v2.4.0 two-phase CSIPHY
[5] media: qcom: camss: csid: Add support for CSID 1080
[6] media: qcom: camss: vfe: Add support for VFE 1080
[7] media: qcom: camss: tpg: Add support for v2.4.0 TPG
[8] arm64: dts: qcom: kaanapali: Add CAMSS and CSIPHY block definitions
[9] arm64: dts: qcom: kaanapali: Add CCI controller nodes
[10] arm64: dts: qcom: kaanapali: Add camera MCLK pinctrl
[11] arm64: dts: qcom: kaanapali-mtp-camera-s5kjn5: Add DT overlay
Signed-off-by: Hangxiang Ma <hangxiang.ma@oss.qualcomm.com>
---
Changes in v21:
- Drop reg_update_after_csid_config flag. Skip the VFE-side stream-on
REG_UPDATE only when the connected CSID implements reg_update - bod
- Add address and size cell properties in camera node to avoid
potential warnings during compilation
- Link to v20: https://patch.msgid.link/20261010-kaanapali-camss-v20-0-63e98ce9ac0c@oss.qualcomm.com
Changes in v20:
- Remove the redundant null check for reg_update_clear in VFE - bod
- Define the port property for CSIPHY nodes and align the style of
CAMSS and CSIPHY nodes - bod
- Replace bias-pull-up and bias-pull-down with bias-disable for the
SCL/SDA pins of CCI nodes in TLMM, as internal weak pull is inproper
with existing board level pull up resistors - Loic
- Align the if-else condition in TPG version judgement and remove the
redundant comments in TPG code but describe the hardware changes in
commit description
- Add Kaanapali camera subsystem and S5KJN5 enablement dtso
- Link to v19: https://patch.msgid.link/20261008-kaanapali-camss-v19-0-b2c583ef50e0@oss.qualcomm.com
Changes in v19:
- Remove the internal CSIPHY hardware operations for CAMSS - bod
- Collect RBs tags from Bryan and Rob for CAMSS binding - bod/Rob
- Split the PHY and CAMSS into separate parts and document the
corresponding maintainers in cover letter - bod
- Link to v18: https://patch.msgid.link/20261003-kaanapali-camss-v18-0-87ba4ebe0db1@oss.qualcomm.com
Changes in v18:
- Rename CSID and VFE hardware version from Gen4 to 1080 - bod
- Correct the description for CAMSS ports in binding - Krzysztof
- Add lane count fallback path for CSID RX configuration - Sashiko
- Align the TFE lite line count with the commit description - Sashiko
- Use hyphenated pattern for MCLK node names - Sashiko
- Resolve conflicts introduced by Glymur in CSI2 PHY binding
- Correct the spelling mistakes in cover letter and enhance commit
description for compatible and CSIPHY
- Link to v17: https://lore.kernel.org/r/20260928-kaanapali-camss-v17-0-dcf3fd37f76c@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 (14):
dt-bindings: phy: qcom,x1e80100-csi2-phy: Add Kaanapali CSI2 PHY
phy: qcom-mipi-csi2: Parametrise the common status register offset
phy: qcom-mipi-csi2: Add Kaanapali support
media: qcom: camss: Issue stream-on REG_UPDATE from CSID
media: dt-bindings: Add CAMSS device for Kaanapali
media: qcom: camss: Add Kaanapali compatible
media: qcom: camss: csiphy: Add support for v2.4.0 two-phase CSIPHY
media: qcom: camss: csid: Add support for CSID 1080
media: qcom: camss: vfe: Add support for VFE 1080
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
arm64: dts: qcom: kaanapali-mtp-camera-s5kjn5: Add DT overlay
.../bindings/media/qcom,kaanapali-camss.yaml | 303 ++++++++
.../bindings/phy/qcom,x1e80100-csi2-phy.yaml | 4 +-
arch/arm64/boot/dts/qcom/Makefile | 5 +
.../boot/dts/qcom/kaanapali-mtp-camera-s5kjn5.dtso | 81 +++
arch/arm64/boot/dts/qcom/kaanapali-mtp.dts | 7 +
arch/arm64/boot/dts/qcom/kaanapali.dtsi | 761 +++++++++++++++++++++
drivers/media/platform/qcom/camss/Makefile | 2 +
.../media/platform/qcom/camss/camss-csid-1080.c | 395 +++++++++++
drivers/media/platform/qcom/camss/camss-csid-680.c | 3 +
.../media/platform/qcom/camss/camss-csid-gen3.c | 3 +
drivers/media/platform/qcom/camss/camss-csid.h | 9 +-
drivers/media/platform/qcom/camss/camss-tpg-gen1.c | 23 +-
drivers/media/platform/qcom/camss/camss-vfe-1080.c | 197 ++++++
drivers/media/platform/qcom/camss/camss-vfe.c | 39 +-
drivers/media/platform/qcom/camss/camss-vfe.h | 1 +
drivers/media/platform/qcom/camss/camss.c | 294 ++++++++
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 +
20 files changed, 2149 insertions(+), 14 deletions(-)
---
base-commit: c74ef2fbf60ff7e7b956c023a881e87502c1852a
change-id: 20260112-kaanapali-camss-73772d44eff7
Best regards,
--
Hangxiang Ma <hangxiang.ma@oss.qualcomm.com>
^ permalink raw reply [flat|nested] 48+ messages in thread
* [PATCH v21 01/14] dt-bindings: phy: qcom,x1e80100-csi2-phy: Add Kaanapali CSI2 PHY
2026-10-12 6:45 ` Hangxiang Ma
@ 2026-10-12 6:45 ` Hangxiang Ma
-1 siblings, 0 replies; 48+ messages in thread
From: Hangxiang Ma @ 2026-10-12 6:45 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,
Krzysztof Kozlowski
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>
Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
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 1f1e2a4993b2..6e9eb8e265df 100644
--- a/Documentation/devicetree/bindings/phy/qcom,x1e80100-csi2-phy.yaml
+++ b/Documentation/devicetree/bindings/phy/qcom,x1e80100-csi2-phy.yaml
@@ -17,7 +17,9 @@ description:
properties:
compatible:
oneOf:
- - const: qcom,x1e80100-csi2-phy
+ - enum:
+ - qcom,kaanapali-csi2-phy
+ - qcom,x1e80100-csi2-phy
- items:
- const: qcom,glymur-csi2-phy
- const: qcom,x1e80100-csi2-phy
--
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] 48+ messages in thread
* [PATCH v21 01/14] dt-bindings: phy: qcom,x1e80100-csi2-phy: Add Kaanapali CSI2 PHY
@ 2026-10-12 6:45 ` Hangxiang Ma
0 siblings, 0 replies; 48+ messages in thread
From: Hangxiang Ma @ 2026-10-12 6:45 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,
Krzysztof Kozlowski
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>
Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
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 1f1e2a4993b2..6e9eb8e265df 100644
--- a/Documentation/devicetree/bindings/phy/qcom,x1e80100-csi2-phy.yaml
+++ b/Documentation/devicetree/bindings/phy/qcom,x1e80100-csi2-phy.yaml
@@ -17,7 +17,9 @@ description:
properties:
compatible:
oneOf:
- - const: qcom,x1e80100-csi2-phy
+ - enum:
+ - qcom,kaanapali-csi2-phy
+ - qcom,x1e80100-csi2-phy
- items:
- const: qcom,glymur-csi2-phy
- const: qcom,x1e80100-csi2-phy
--
2.34.1
^ permalink raw reply related [flat|nested] 48+ messages in thread
* [PATCH v21 02/14] phy: qcom-mipi-csi2: Parametrise the common status register offset
2026-10-12 6:45 ` Hangxiang Ma
@ 2026-10-12 6:45 ` Hangxiang Ma
-1 siblings, 0 replies; 48+ messages in thread
From: Hangxiang Ma @ 2026-10-12 6:45 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.
Reviewed-by: Bryan O'Donoghue <bod@kernel.org>
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] 48+ messages in thread
* [PATCH v21 02/14] phy: qcom-mipi-csi2: Parametrise the common status register offset
@ 2026-10-12 6:45 ` Hangxiang Ma
0 siblings, 0 replies; 48+ messages in thread
From: Hangxiang Ma @ 2026-10-12 6:45 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.
Reviewed-by: Bryan O'Donoghue <bod@kernel.org>
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] 48+ messages in thread
* [PATCH v21 03/14] phy: qcom-mipi-csi2: Add Kaanapali support
2026-10-12 6:45 ` Hangxiang Ma
@ 2026-10-12 6:45 ` Hangxiang Ma
-1 siblings, 0 replies; 48+ messages in thread
From: Hangxiang Ma @ 2026-10-12 6:45 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 Kaanapali 3nm configuration for the standalone CSI2 DPHY
driver, including the Kaanapali common status offset and power domain.
Reviewed-by: Bryan O'Donoghue <bod@kernel.org>
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-core.c | 1 +
drivers/phy/qualcomm/phy-qcom-mipi-csi2.h | 1 +
3 files changed, 18 insertions(+)
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] 48+ messages in thread
* [PATCH v21 03/14] phy: qcom-mipi-csi2: Add Kaanapali support
@ 2026-10-12 6:45 ` Hangxiang Ma
0 siblings, 0 replies; 48+ messages in thread
From: Hangxiang Ma @ 2026-10-12 6:45 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 Kaanapali 3nm configuration for the standalone CSI2 DPHY
driver, including the Kaanapali common status offset and power domain.
Reviewed-by: Bryan O'Donoghue <bod@kernel.org>
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-core.c | 1 +
drivers/phy/qualcomm/phy-qcom-mipi-csi2.h | 1 +
3 files changed, 18 insertions(+)
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] 48+ messages in thread
* [PATCH v21 04/14] media: qcom: camss: Issue stream-on REG_UPDATE from CSID
2026-10-12 6:45 ` Hangxiang Ma
@ 2026-10-12 6:45 ` Hangxiang Ma
-1 siblings, 0 replies; 48+ messages in thread
From: Hangxiang Ma @ 2026-10-12 6:45 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
On stream-on, CAMSS starts the subdevices upstream from the video node
through their sink pads, so the VFE is started before the CSID.
Starting with CSID 680, the REG_UPDATE is issued through the CSID
rather than the VFE. However, vfe_enable_output_v2() still issues a
REG_UPDATE after queueing each initial buffer, before the CSID has
configured the stream. The VFE then never signals BUF_DONE. Therefore,
the CAMSS now issues the REG_UPDATE from configure_stream() on CSID 680
and CSID Gen3 instead. The operation happens after the RX configuration
and before the RDI path is enabled.
Skip the VFE-side stream-on REG_UPDATE only when the CSID connected to
the VFE sink pad implements the reg_update callback. Platforms whose
CSID does not provide this callback, as well as lines fed by ISPIF,
keep the existing VFE-side REG_UPDATE.
Signed-off-by: Hangxiang Ma <hangxiang.ma@oss.qualcomm.com>
---
drivers/media/platform/qcom/camss/camss-csid-680.c | 3 ++
.../media/platform/qcom/camss/camss-csid-gen3.c | 3 ++
drivers/media/platform/qcom/camss/camss-vfe.c | 37 +++++++++++++++++++++-
3 files changed, 42 insertions(+), 1 deletion(-)
diff --git a/drivers/media/platform/qcom/camss/camss-csid-680.c b/drivers/media/platform/qcom/camss/camss-csid-680.c
index 345a67c8fb94..556cdfef6207 100644
--- a/drivers/media/platform/qcom/camss/camss-csid-680.c
+++ b/drivers/media/platform/qcom/camss/camss-csid-680.c
@@ -296,6 +296,8 @@ static void __csid_configure_rdi_stream(struct csid_device *csid, u8 enable, u8
writel(val, csid->base + CSID_RDI_CFG0(port));
}
+static void csid_subdev_reg_update(struct csid_device *csid, int port_id, bool is_clear);
+
static void csid_configure_stream(struct csid_device *csid, u8 enable)
{
int i;
@@ -307,6 +309,7 @@ static void csid_configure_stream(struct csid_device *csid, u8 enable)
if (csid->phy.en_vc & BIT(i)) {
__csid_configure_rdi_stream(csid, enable, i, 0);
__csid_configure_rx(csid, &csid->phy, 0);
+ csid_subdev_reg_update(csid, i, false);
__csid_ctrl_rdi(csid, enable, i);
}
}
diff --git a/drivers/media/platform/qcom/camss/camss-csid-gen3.c b/drivers/media/platform/qcom/camss/camss-csid-gen3.c
index 0fdbf75fb27d..830c9c818d3d 100644
--- a/drivers/media/platform/qcom/camss/camss-csid-gen3.c
+++ b/drivers/media/platform/qcom/camss/camss-csid-gen3.c
@@ -219,6 +219,8 @@ static void __csid_configure_rdi_stream(struct csid_device *csid, u8 enable, u8
writel(val, csid->base + CSID_RDI_CFG0(port));
}
+static void csid_subdev_reg_update(struct csid_device *csid, int port_id, bool is_clear);
+
static void csid_configure_stream(struct csid_device *csid, u8 enable)
{
u8 i;
@@ -230,6 +232,7 @@ static void csid_configure_stream(struct csid_device *csid, u8 enable)
if (csid->phy.en_vc & BIT(i)) {
__csid_configure_rdi_stream(csid, enable, i, 0);
__csid_configure_rx(csid, &csid->phy, 0);
+ csid_subdev_reg_update(csid, i, false);
__csid_ctrl_rdi(csid, enable, i);
}
}
diff --git a/drivers/media/platform/qcom/camss/camss-vfe.c b/drivers/media/platform/qcom/camss/camss-vfe.c
index 2680a9914765..16a0b5663fe2 100644
--- a/drivers/media/platform/qcom/camss/camss-vfe.c
+++ b/drivers/media/platform/qcom/camss/camss-vfe.c
@@ -502,6 +502,37 @@ void vfe_buf_done(struct vfe_device *vfe, int wm)
spin_unlock_irqrestore(&vfe->output_lock, flags);
}
+/*
+ * vfe_upstream_csid_has_reg_update - Check whether the CSID feeding this line
+ * issues its own streamon RUP (i.e. its configure_stream does the RUP).
+ *
+ * The CSID->VFE link is created in camss.c for all CSIDs and VFEs, so the
+ * upstream entity of the sink pad is either a CSID (possibly with RUP) or an
+ * ISPIF (no RUP). Only enabled links are considered.
+ */
+static bool vfe_upstream_csid_has_reg_update(struct vfe_line *line)
+{
+ struct vfe_device *vfe = to_vfe(line);
+ struct camss *camss = vfe->camss;
+ struct media_pad *remote;
+ unsigned int i;
+
+ remote = media_pad_remote_pad_first(&line->pads[MSM_VFE_PAD_SINK]);
+ if (!remote || !is_media_entity_v4l2_subdev(remote->entity))
+ return false;
+
+ for (i = 0; i < camss->res->csid_num; i++) {
+ struct csid_device *csid = &camss->csid[i];
+
+ if (&csid->subdev.entity != remote->entity)
+ continue;
+
+ return !!csid->res->hw_ops->reg_update;
+ }
+
+ return false;
+}
+
int vfe_enable_output_v2(struct vfe_line *line)
{
struct vfe_device *vfe = to_vfe(line);
@@ -511,6 +542,7 @@ int vfe_enable_output_v2(struct vfe_line *line)
unsigned long flags;
unsigned int frame_skip = 0;
unsigned int i;
+ bool rup_in_csid;
sensor_pad = camss_find_sensor_pad(&line->subdev.entity);
if (sensor_pad) {
@@ -523,6 +555,8 @@ int vfe_enable_output_v2(struct vfe_line *line)
frame_skip = VFE_FRAME_DROP_VAL - 1;
}
+ rup_in_csid = vfe_upstream_csid_has_reg_update(line);
+
spin_lock_irqsave(&vfe->output_lock, flags);
ops->reg_update_clear(vfe, line->id);
@@ -552,7 +586,8 @@ 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 (!rup_in_csid)
+ ops->reg_update(vfe, line->id);
}
spin_unlock_irqrestore(&vfe->output_lock, flags);
--
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] 48+ messages in thread
* [PATCH v21 04/14] media: qcom: camss: Issue stream-on REG_UPDATE from CSID
@ 2026-10-12 6:45 ` Hangxiang Ma
0 siblings, 0 replies; 48+ messages in thread
From: Hangxiang Ma @ 2026-10-12 6:45 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
On stream-on, CAMSS starts the subdevices upstream from the video node
through their sink pads, so the VFE is started before the CSID.
Starting with CSID 680, the REG_UPDATE is issued through the CSID
rather than the VFE. However, vfe_enable_output_v2() still issues a
REG_UPDATE after queueing each initial buffer, before the CSID has
configured the stream. The VFE then never signals BUF_DONE. Therefore,
the CAMSS now issues the REG_UPDATE from configure_stream() on CSID 680
and CSID Gen3 instead. The operation happens after the RX configuration
and before the RDI path is enabled.
Skip the VFE-side stream-on REG_UPDATE only when the CSID connected to
the VFE sink pad implements the reg_update callback. Platforms whose
CSID does not provide this callback, as well as lines fed by ISPIF,
keep the existing VFE-side REG_UPDATE.
Signed-off-by: Hangxiang Ma <hangxiang.ma@oss.qualcomm.com>
---
drivers/media/platform/qcom/camss/camss-csid-680.c | 3 ++
.../media/platform/qcom/camss/camss-csid-gen3.c | 3 ++
drivers/media/platform/qcom/camss/camss-vfe.c | 37 +++++++++++++++++++++-
3 files changed, 42 insertions(+), 1 deletion(-)
diff --git a/drivers/media/platform/qcom/camss/camss-csid-680.c b/drivers/media/platform/qcom/camss/camss-csid-680.c
index 345a67c8fb94..556cdfef6207 100644
--- a/drivers/media/platform/qcom/camss/camss-csid-680.c
+++ b/drivers/media/platform/qcom/camss/camss-csid-680.c
@@ -296,6 +296,8 @@ static void __csid_configure_rdi_stream(struct csid_device *csid, u8 enable, u8
writel(val, csid->base + CSID_RDI_CFG0(port));
}
+static void csid_subdev_reg_update(struct csid_device *csid, int port_id, bool is_clear);
+
static void csid_configure_stream(struct csid_device *csid, u8 enable)
{
int i;
@@ -307,6 +309,7 @@ static void csid_configure_stream(struct csid_device *csid, u8 enable)
if (csid->phy.en_vc & BIT(i)) {
__csid_configure_rdi_stream(csid, enable, i, 0);
__csid_configure_rx(csid, &csid->phy, 0);
+ csid_subdev_reg_update(csid, i, false);
__csid_ctrl_rdi(csid, enable, i);
}
}
diff --git a/drivers/media/platform/qcom/camss/camss-csid-gen3.c b/drivers/media/platform/qcom/camss/camss-csid-gen3.c
index 0fdbf75fb27d..830c9c818d3d 100644
--- a/drivers/media/platform/qcom/camss/camss-csid-gen3.c
+++ b/drivers/media/platform/qcom/camss/camss-csid-gen3.c
@@ -219,6 +219,8 @@ static void __csid_configure_rdi_stream(struct csid_device *csid, u8 enable, u8
writel(val, csid->base + CSID_RDI_CFG0(port));
}
+static void csid_subdev_reg_update(struct csid_device *csid, int port_id, bool is_clear);
+
static void csid_configure_stream(struct csid_device *csid, u8 enable)
{
u8 i;
@@ -230,6 +232,7 @@ static void csid_configure_stream(struct csid_device *csid, u8 enable)
if (csid->phy.en_vc & BIT(i)) {
__csid_configure_rdi_stream(csid, enable, i, 0);
__csid_configure_rx(csid, &csid->phy, 0);
+ csid_subdev_reg_update(csid, i, false);
__csid_ctrl_rdi(csid, enable, i);
}
}
diff --git a/drivers/media/platform/qcom/camss/camss-vfe.c b/drivers/media/platform/qcom/camss/camss-vfe.c
index 2680a9914765..16a0b5663fe2 100644
--- a/drivers/media/platform/qcom/camss/camss-vfe.c
+++ b/drivers/media/platform/qcom/camss/camss-vfe.c
@@ -502,6 +502,37 @@ void vfe_buf_done(struct vfe_device *vfe, int wm)
spin_unlock_irqrestore(&vfe->output_lock, flags);
}
+/*
+ * vfe_upstream_csid_has_reg_update - Check whether the CSID feeding this line
+ * issues its own streamon RUP (i.e. its configure_stream does the RUP).
+ *
+ * The CSID->VFE link is created in camss.c for all CSIDs and VFEs, so the
+ * upstream entity of the sink pad is either a CSID (possibly with RUP) or an
+ * ISPIF (no RUP). Only enabled links are considered.
+ */
+static bool vfe_upstream_csid_has_reg_update(struct vfe_line *line)
+{
+ struct vfe_device *vfe = to_vfe(line);
+ struct camss *camss = vfe->camss;
+ struct media_pad *remote;
+ unsigned int i;
+
+ remote = media_pad_remote_pad_first(&line->pads[MSM_VFE_PAD_SINK]);
+ if (!remote || !is_media_entity_v4l2_subdev(remote->entity))
+ return false;
+
+ for (i = 0; i < camss->res->csid_num; i++) {
+ struct csid_device *csid = &camss->csid[i];
+
+ if (&csid->subdev.entity != remote->entity)
+ continue;
+
+ return !!csid->res->hw_ops->reg_update;
+ }
+
+ return false;
+}
+
int vfe_enable_output_v2(struct vfe_line *line)
{
struct vfe_device *vfe = to_vfe(line);
@@ -511,6 +542,7 @@ int vfe_enable_output_v2(struct vfe_line *line)
unsigned long flags;
unsigned int frame_skip = 0;
unsigned int i;
+ bool rup_in_csid;
sensor_pad = camss_find_sensor_pad(&line->subdev.entity);
if (sensor_pad) {
@@ -523,6 +555,8 @@ int vfe_enable_output_v2(struct vfe_line *line)
frame_skip = VFE_FRAME_DROP_VAL - 1;
}
+ rup_in_csid = vfe_upstream_csid_has_reg_update(line);
+
spin_lock_irqsave(&vfe->output_lock, flags);
ops->reg_update_clear(vfe, line->id);
@@ -552,7 +586,8 @@ 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 (!rup_in_csid)
+ ops->reg_update(vfe, line->id);
}
spin_unlock_irqrestore(&vfe->output_lock, flags);
--
2.34.1
^ permalink raw reply related [flat|nested] 48+ messages in thread
* [PATCH v21 05/14] media: dt-bindings: Add CAMSS device for Kaanapali
2026-10-12 6:45 ` Hangxiang Ma
@ 2026-10-12 6:45 ` Hangxiang Ma
-1 siblings, 0 replies; 48+ messages in thread
From: Hangxiang Ma @ 2026-10-12 6:45 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
Reviewed-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
Reviewed-by: Rob Herring (Arm) <robh@kernel.org>
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..e7f5ddd35b9d
--- /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. 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] 48+ messages in thread
* [PATCH v21 05/14] media: dt-bindings: Add CAMSS device for Kaanapali
@ 2026-10-12 6:45 ` Hangxiang Ma
0 siblings, 0 replies; 48+ messages in thread
From: Hangxiang Ma @ 2026-10-12 6:45 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
Reviewed-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
Reviewed-by: Rob Herring (Arm) <robh@kernel.org>
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..e7f5ddd35b9d
--- /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. 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] 48+ messages in thread
* [PATCH v21 06/14] media: qcom: camss: Add Kaanapali compatible
2026-10-12 6:45 ` Hangxiang Ma
@ 2026-10-12 6:45 ` Hangxiang Ma
-1 siblings, 0 replies; 48+ messages in thread
From: Hangxiang Ma @ 2026-10-12 6:45 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 currently includes only basic information.
Later changes will add 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 c54185c93a8a..fca3de214a92 100644
--- a/drivers/media/platform/qcom/camss/camss.c
+++ b/drivers/media/platform/qcom/camss/camss.c
@@ -38,6 +38,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 */
{
@@ -5576,6 +5590,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,
@@ -5810,6 +5831,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 7dc2fd9f03e0..0551211f7948 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] 48+ messages in thread
* [PATCH v21 06/14] media: qcom: camss: Add Kaanapali compatible
@ 2026-10-12 6:45 ` Hangxiang Ma
0 siblings, 0 replies; 48+ messages in thread
From: Hangxiang Ma @ 2026-10-12 6:45 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 currently includes only basic information.
Later changes will add 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 c54185c93a8a..fca3de214a92 100644
--- a/drivers/media/platform/qcom/camss/camss.c
+++ b/drivers/media/platform/qcom/camss/camss.c
@@ -38,6 +38,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 */
{
@@ -5576,6 +5590,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,
@@ -5810,6 +5831,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 7dc2fd9f03e0..0551211f7948 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] 48+ messages in thread
* [PATCH v21 07/14] media: qcom: camss: csiphy: Add support for v2.4.0 two-phase CSIPHY
2026-10-12 6:45 ` Hangxiang Ma
@ 2026-10-12 6:45 ` Hangxiang Ma
-1 siblings, 0 replies; 48+ messages in thread
From: Hangxiang Ma @ 2026-10-12 6:45 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, adds Kaanapali power domain and register
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>
---
drivers/media/platform/qcom/camss/camss.c | 47 +++++++++++++++++++++++++++++++
1 file changed, 47 insertions(+)
diff --git a/drivers/media/platform/qcom/camss/camss.c b/drivers/media/platform/qcom/camss/camss.c
index fca3de214a92..eeceb79c1e86 100644
--- a/drivers/media/platform/qcom/camss/camss.c
+++ b/drivers/media/platform/qcom/camss/camss.c
@@ -38,6 +38,51 @@
static const struct parent_dev_ops vfe_parent_dev_ops;
+static const struct camss_subdev_resources csiphy_res_kaanapali[] = {
+ /* CSIPHY0 */
+ {
+ .csiphy = {
+ .id = 0,
+ .formats = &csiphy_formats_sdm845
+ },
+ },
+ /* CSIPHY1 */
+ {
+ .csiphy = {
+ .id = 1,
+ .formats = &csiphy_formats_sdm845
+ },
+ },
+ /* CSIPHY2 */
+ {
+ .csiphy = {
+ .id = 2,
+ .formats = &csiphy_formats_sdm845
+ },
+ },
+ /* CSIPHY3 */
+ {
+ .csiphy = {
+ .id = 3,
+ .formats = &csiphy_formats_sdm845
+ },
+ },
+ /* CSIPHY4 */
+ {
+ .csiphy = {
+ .id = 4,
+ .formats = &csiphy_formats_sdm845
+ },
+ },
+ /* CSIPHY5 */
+ {
+ .csiphy = {
+ .id = 5,
+ .formats = &csiphy_formats_sdm845
+ },
+ },
+};
+
static const struct resources_icc icc_res_kaanapali[] = {
{
.name = "ahb",
@@ -5593,8 +5638,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 = {
--
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] 48+ messages in thread
* [PATCH v21 07/14] media: qcom: camss: csiphy: Add support for v2.4.0 two-phase CSIPHY
@ 2026-10-12 6:45 ` Hangxiang Ma
0 siblings, 0 replies; 48+ messages in thread
From: Hangxiang Ma @ 2026-10-12 6:45 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, adds Kaanapali power domain and register
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>
---
drivers/media/platform/qcom/camss/camss.c | 47 +++++++++++++++++++++++++++++++
1 file changed, 47 insertions(+)
diff --git a/drivers/media/platform/qcom/camss/camss.c b/drivers/media/platform/qcom/camss/camss.c
index fca3de214a92..eeceb79c1e86 100644
--- a/drivers/media/platform/qcom/camss/camss.c
+++ b/drivers/media/platform/qcom/camss/camss.c
@@ -38,6 +38,51 @@
static const struct parent_dev_ops vfe_parent_dev_ops;
+static const struct camss_subdev_resources csiphy_res_kaanapali[] = {
+ /* CSIPHY0 */
+ {
+ .csiphy = {
+ .id = 0,
+ .formats = &csiphy_formats_sdm845
+ },
+ },
+ /* CSIPHY1 */
+ {
+ .csiphy = {
+ .id = 1,
+ .formats = &csiphy_formats_sdm845
+ },
+ },
+ /* CSIPHY2 */
+ {
+ .csiphy = {
+ .id = 2,
+ .formats = &csiphy_formats_sdm845
+ },
+ },
+ /* CSIPHY3 */
+ {
+ .csiphy = {
+ .id = 3,
+ .formats = &csiphy_formats_sdm845
+ },
+ },
+ /* CSIPHY4 */
+ {
+ .csiphy = {
+ .id = 4,
+ .formats = &csiphy_formats_sdm845
+ },
+ },
+ /* CSIPHY5 */
+ {
+ .csiphy = {
+ .id = 5,
+ .formats = &csiphy_formats_sdm845
+ },
+ },
+};
+
static const struct resources_icc icc_res_kaanapali[] = {
{
.name = "ahb",
@@ -5593,8 +5638,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 = {
--
2.34.1
^ permalink raw reply related [flat|nested] 48+ messages in thread
* [PATCH v21 08/14] media: qcom: camss: csid: Add support for CSID 1080
2026-10-12 6:45 ` Hangxiang Ma
@ 2026-10-12 6:45 ` Hangxiang Ma
-1 siblings, 0 replies; 48+ messages in thread
From: Hangxiang Ma @ 2026-10-12 6:45 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 1080 hardware found on Kaanapali SoC.
Introduce CSID 1080 hardware resource descriptions and implement the
hardware-specific register programming, reset sequence, and BUF_DONE
interrupt handling.
CSID 1080 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-1080.c | 384 +++++++++++++++++++++
drivers/media/platform/qcom/camss/camss-csid.h | 9 +-
drivers/media/platform/qcom/camss/camss.c | 75 ++++
4 files changed, 468 insertions(+), 1 deletion(-)
diff --git a/drivers/media/platform/qcom/camss/Makefile b/drivers/media/platform/qcom/camss/Makefile
index 27898b3cc7d3..218ba3a95939 100644
--- a/drivers/media/platform/qcom/camss/Makefile
+++ b/drivers/media/platform/qcom/camss/Makefile
@@ -8,6 +8,7 @@ qcom-camss-objs += \
camss-csid-4-7.o \
camss-csid-340.o \
camss-csid-680.o \
+ camss-csid-1080.o \
camss-csid-gen2.o \
camss-csid-gen3.o \
camss-csiphy.o \
diff --git a/drivers/media/platform/qcom/camss/camss-csid-1080.c b/drivers/media/platform/qcom/camss/camss-csid-1080.c
new file mode 100644
index 000000000000..46e443e05195
--- /dev/null
+++ b/drivers/media/platform/qcom/camss/camss-csid-1080.c
@@ -0,0 +1,384 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * camss-csid-1080.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_1080 (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)
+{
+ u8 lane_cnt = phy->lane_cnt;
+ int val;
+
+ if (!lane_cnt)
+ lane_cnt = 4;
+
+ val = (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 1080 */
+ 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_1080; 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_1080; 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_1080; 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_1080 = {
+ .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..3c2d15a61836 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;
@@ -216,6 +222,7 @@ extern const struct csid_hw_ops csid_ops_4_1;
extern const struct csid_hw_ops csid_ops_4_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_1080;
extern const struct csid_hw_ops csid_ops_gen2;
extern const struct csid_hw_ops csid_ops_gen3;
diff --git a/drivers/media/platform/qcom/camss/camss.c b/drivers/media/platform/qcom/camss/camss.c
index eeceb79c1e86..261e6c837dd4 100644
--- a/drivers/media/platform/qcom/camss/camss.c
+++ b/drivers/media/platform/qcom/camss/camss.c
@@ -83,6 +83,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_1080,
+ .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_1080,
+ .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_1080,
+ .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_1080,
+ .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_1080,
+ .formats = &csid_formats_gen2
+ }
+ }
+};
+
static const struct resources_icc icc_res_kaanapali[] = {
{
.name = "ahb",
@@ -5639,9 +5712,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] 48+ messages in thread
* [PATCH v21 08/14] media: qcom: camss: csid: Add support for CSID 1080
@ 2026-10-12 6:45 ` Hangxiang Ma
0 siblings, 0 replies; 48+ messages in thread
From: Hangxiang Ma @ 2026-10-12 6:45 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 1080 hardware found on Kaanapali SoC.
Introduce CSID 1080 hardware resource descriptions and implement the
hardware-specific register programming, reset sequence, and BUF_DONE
interrupt handling.
CSID 1080 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-1080.c | 384 +++++++++++++++++++++
drivers/media/platform/qcom/camss/camss-csid.h | 9 +-
drivers/media/platform/qcom/camss/camss.c | 75 ++++
4 files changed, 468 insertions(+), 1 deletion(-)
diff --git a/drivers/media/platform/qcom/camss/Makefile b/drivers/media/platform/qcom/camss/Makefile
index 27898b3cc7d3..218ba3a95939 100644
--- a/drivers/media/platform/qcom/camss/Makefile
+++ b/drivers/media/platform/qcom/camss/Makefile
@@ -8,6 +8,7 @@ qcom-camss-objs += \
camss-csid-4-7.o \
camss-csid-340.o \
camss-csid-680.o \
+ camss-csid-1080.o \
camss-csid-gen2.o \
camss-csid-gen3.o \
camss-csiphy.o \
diff --git a/drivers/media/platform/qcom/camss/camss-csid-1080.c b/drivers/media/platform/qcom/camss/camss-csid-1080.c
new file mode 100644
index 000000000000..46e443e05195
--- /dev/null
+++ b/drivers/media/platform/qcom/camss/camss-csid-1080.c
@@ -0,0 +1,384 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * camss-csid-1080.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_1080 (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)
+{
+ u8 lane_cnt = phy->lane_cnt;
+ int val;
+
+ if (!lane_cnt)
+ lane_cnt = 4;
+
+ val = (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 1080 */
+ 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_1080; 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_1080; 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_1080; 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_1080 = {
+ .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..3c2d15a61836 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;
@@ -216,6 +222,7 @@ extern const struct csid_hw_ops csid_ops_4_1;
extern const struct csid_hw_ops csid_ops_4_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_1080;
extern const struct csid_hw_ops csid_ops_gen2;
extern const struct csid_hw_ops csid_ops_gen3;
diff --git a/drivers/media/platform/qcom/camss/camss.c b/drivers/media/platform/qcom/camss/camss.c
index eeceb79c1e86..261e6c837dd4 100644
--- a/drivers/media/platform/qcom/camss/camss.c
+++ b/drivers/media/platform/qcom/camss/camss.c
@@ -83,6 +83,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_1080,
+ .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_1080,
+ .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_1080,
+ .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_1080,
+ .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_1080,
+ .formats = &csid_formats_gen2
+ }
+ }
+};
+
static const struct resources_icc icc_res_kaanapali[] = {
{
.name = "ahb",
@@ -5639,9 +5712,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] 48+ messages in thread
* [PATCH v21 09/14] media: qcom: camss: vfe: Add support for VFE 1080
2026-10-12 6:45 ` Hangxiang Ma
@ 2026-10-12 6:45 ` Hangxiang Ma
-1 siblings, 0 replies; 48+ messages in thread
From: Hangxiang Ma @ 2026-10-12 6:45 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) 1080 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-1080.c | 197 +++++++++++++++++++++
drivers/media/platform/qcom/camss/camss-vfe.c | 2 +
drivers/media/platform/qcom/camss/camss-vfe.h | 1 +
drivers/media/platform/qcom/camss/camss.c | 148 ++++++++++++++++
5 files changed, 349 insertions(+)
diff --git a/drivers/media/platform/qcom/camss/Makefile b/drivers/media/platform/qcom/camss/Makefile
index 218ba3a95939..42a14e8fe1b7 100644
--- a/drivers/media/platform/qcom/camss/Makefile
+++ b/drivers/media/platform/qcom/camss/Makefile
@@ -26,6 +26,7 @@ qcom-camss-objs += \
camss-vfe-340.o \
camss-vfe-480.o \
camss-vfe-680.o \
+ camss-vfe-1080.o \
camss-vfe-gen1.o \
camss-vfe-gen3.o \
camss-vfe-vbif.o \
diff --git a/drivers/media/platform/qcom/camss/camss-vfe-1080.c b/drivers/media/platform/qcom/camss/camss-vfe-1080.c
new file mode 100644
index 000000000000..016857cd1025
--- /dev/null
+++ b/drivers/media/platform/qcom/camss/camss-vfe-1080.c
@@ -0,0 +1,197 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * camss-vfe-1080.c
+ *
+ * Qualcomm MSM Camera Subsystem - VFE (Video Front End) Module 1080
+ *
+ * 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-1080 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_1080 = {
+ .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_1080;
+}
+
+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_1080 = {
+ .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 16a0b5663fe2..58f62a2437a1 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:
@@ -2048,6 +2049,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..f0abc10f0e70 100644
--- a/drivers/media/platform/qcom/camss/camss-vfe.h
+++ b/drivers/media/platform/qcom/camss/camss-vfe.h
@@ -248,6 +248,7 @@ extern const struct vfe_hw_ops vfe_ops_170;
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_1080;
extern const struct vfe_hw_ops vfe_ops_gen3;
int vfe_get(struct vfe_device *vfe);
diff --git a/drivers/media/platform/qcom/camss/camss.c b/drivers/media/platform/qcom/camss/camss.c
index 261e6c837dd4..63030a0659d4 100644
--- a/drivers/media/platform/qcom/camss/camss.c
+++ b/drivers/media/platform/qcom/camss/camss.c
@@ -156,6 +156,152 @@ 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,
+ .has_pd = true,
+ .pd_name = "ife0",
+ .hw_ops = &vfe_ops_1080,
+ .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,
+ .has_pd = true,
+ .pd_name = "ife1",
+ .hw_ops = &vfe_ops_1080,
+ .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,
+ .has_pd = true,
+ .pd_name = "ife2",
+ .hw_ops = &vfe_ops_1080,
+ .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 = 3,
+ .is_lite = true,
+ .hw_ops = &vfe_ops_1080,
+ .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 = 3,
+ .is_lite = true,
+ .hw_ops = &vfe_ops_1080,
+ .formats_rdi = &vfe_formats_rdi_845,
+ .formats_pix = &vfe_formats_pix_845
+ }
+ },
+};
+
static const struct resources_icc icc_res_kaanapali[] = {
{
.name = "ahb",
@@ -5713,10 +5859,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] 48+ messages in thread
* [PATCH v21 09/14] media: qcom: camss: vfe: Add support for VFE 1080
@ 2026-10-12 6:45 ` Hangxiang Ma
0 siblings, 0 replies; 48+ messages in thread
From: Hangxiang Ma @ 2026-10-12 6:45 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) 1080 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-1080.c | 197 +++++++++++++++++++++
drivers/media/platform/qcom/camss/camss-vfe.c | 2 +
drivers/media/platform/qcom/camss/camss-vfe.h | 1 +
drivers/media/platform/qcom/camss/camss.c | 148 ++++++++++++++++
5 files changed, 349 insertions(+)
diff --git a/drivers/media/platform/qcom/camss/Makefile b/drivers/media/platform/qcom/camss/Makefile
index 218ba3a95939..42a14e8fe1b7 100644
--- a/drivers/media/platform/qcom/camss/Makefile
+++ b/drivers/media/platform/qcom/camss/Makefile
@@ -26,6 +26,7 @@ qcom-camss-objs += \
camss-vfe-340.o \
camss-vfe-480.o \
camss-vfe-680.o \
+ camss-vfe-1080.o \
camss-vfe-gen1.o \
camss-vfe-gen3.o \
camss-vfe-vbif.o \
diff --git a/drivers/media/platform/qcom/camss/camss-vfe-1080.c b/drivers/media/platform/qcom/camss/camss-vfe-1080.c
new file mode 100644
index 000000000000..016857cd1025
--- /dev/null
+++ b/drivers/media/platform/qcom/camss/camss-vfe-1080.c
@@ -0,0 +1,197 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * camss-vfe-1080.c
+ *
+ * Qualcomm MSM Camera Subsystem - VFE (Video Front End) Module 1080
+ *
+ * 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-1080 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_1080 = {
+ .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_1080;
+}
+
+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_1080 = {
+ .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 16a0b5663fe2..58f62a2437a1 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:
@@ -2048,6 +2049,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..f0abc10f0e70 100644
--- a/drivers/media/platform/qcom/camss/camss-vfe.h
+++ b/drivers/media/platform/qcom/camss/camss-vfe.h
@@ -248,6 +248,7 @@ extern const struct vfe_hw_ops vfe_ops_170;
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_1080;
extern const struct vfe_hw_ops vfe_ops_gen3;
int vfe_get(struct vfe_device *vfe);
diff --git a/drivers/media/platform/qcom/camss/camss.c b/drivers/media/platform/qcom/camss/camss.c
index 261e6c837dd4..63030a0659d4 100644
--- a/drivers/media/platform/qcom/camss/camss.c
+++ b/drivers/media/platform/qcom/camss/camss.c
@@ -156,6 +156,152 @@ 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,
+ .has_pd = true,
+ .pd_name = "ife0",
+ .hw_ops = &vfe_ops_1080,
+ .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,
+ .has_pd = true,
+ .pd_name = "ife1",
+ .hw_ops = &vfe_ops_1080,
+ .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,
+ .has_pd = true,
+ .pd_name = "ife2",
+ .hw_ops = &vfe_ops_1080,
+ .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 = 3,
+ .is_lite = true,
+ .hw_ops = &vfe_ops_1080,
+ .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 = 3,
+ .is_lite = true,
+ .hw_ops = &vfe_ops_1080,
+ .formats_rdi = &vfe_formats_rdi_845,
+ .formats_pix = &vfe_formats_pix_845
+ }
+ },
+};
+
static const struct resources_icc icc_res_kaanapali[] = {
{
.name = "ahb",
@@ -5713,10 +5859,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] 48+ messages in thread
* [PATCH v21 10/14] media: qcom: camss: tpg: Add support for v2.4.0 TPG
2026-10-12 6:45 ` Hangxiang Ma
@ 2026-10-12 6:45 ` Hangxiang Ma
-1 siblings, 0 replies; 48+ messages in thread
From: Hangxiang Ma @ 2026-10-12 6:45 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 the
TPG_CTRL_CMD register at offset 0x1f4 instead of the TEST_EN bit in
TPG_CTRL and the TPG_CLEAR register. Its output is routed into the
CSID 1080 RX through the CSI2 TPG mux, so the CSID selects the TPG as
the data source when a test pattern is selected.
Add the TPG resources to the Kaanapali camss resources so that the TPG
subdevices are created on this SoC.
Signed-off-by: Hangxiang Ma <hangxiang.ma@oss.qualcomm.com>
---
.../media/platform/qcom/camss/camss-csid-1080.c | 15 ++++++++++++--
drivers/media/platform/qcom/camss/camss-tpg-gen1.c | 23 ++++++++++++++++------
drivers/media/platform/qcom/camss/camss.c | 2 ++
3 files changed, 32 insertions(+), 8 deletions(-)
diff --git a/drivers/media/platform/qcom/camss/camss-csid-1080.c b/drivers/media/platform/qcom/camss/camss-csid-1080.c
index 46e443e05195..851b3cd712f5 100644
--- a/drivers/media/platform/qcom/camss/camss-csid-1080.c
+++ b/drivers/media/platform/qcom/camss/camss-csid-1080.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,6 +142,7 @@ 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;
u8 lane_cnt = phy->lane_cnt;
int val;
@@ -148,8 +151,16 @@ static void __csid_configure_rx(struct csid_device *csid,
val = (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..cabbb2638cf3 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,26 @@ 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) {
+ val |= FIELD_PREP(TPG_CTRL_TEST_EN, 1);
+ writel(val, tpg->base + TPG_CTRL);
+ } else {
+ writel(val, tpg->base + TPG_CTRL);
+ writel(TPG_CTRL_CMD_TEST_EN, tpg->base + TPG_CTRL_CMD);
+ }
return 0;
}
static int tpg_reset(struct tpg_device *tpg)
{
- writel(0, tpg->base + TPG_CTRL);
- writel(1, tpg->base + TPG_CLEAR);
+ 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 63030a0659d4..5db7e12a6f86 100644
--- a/drivers/media/platform/qcom/camss/camss.c
+++ b/drivers/media/platform/qcom/camss/camss.c
@@ -5858,11 +5858,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] 48+ messages in thread
* [PATCH v21 10/14] media: qcom: camss: tpg: Add support for v2.4.0 TPG
@ 2026-10-12 6:45 ` Hangxiang Ma
0 siblings, 0 replies; 48+ messages in thread
From: Hangxiang Ma @ 2026-10-12 6:45 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 the
TPG_CTRL_CMD register at offset 0x1f4 instead of the TEST_EN bit in
TPG_CTRL and the TPG_CLEAR register. Its output is routed into the
CSID 1080 RX through the CSI2 TPG mux, so the CSID selects the TPG as
the data source when a test pattern is selected.
Add the TPG resources to the Kaanapali camss resources so that the TPG
subdevices are created on this SoC.
Signed-off-by: Hangxiang Ma <hangxiang.ma@oss.qualcomm.com>
---
.../media/platform/qcom/camss/camss-csid-1080.c | 15 ++++++++++++--
drivers/media/platform/qcom/camss/camss-tpg-gen1.c | 23 ++++++++++++++++------
drivers/media/platform/qcom/camss/camss.c | 2 ++
3 files changed, 32 insertions(+), 8 deletions(-)
diff --git a/drivers/media/platform/qcom/camss/camss-csid-1080.c b/drivers/media/platform/qcom/camss/camss-csid-1080.c
index 46e443e05195..851b3cd712f5 100644
--- a/drivers/media/platform/qcom/camss/camss-csid-1080.c
+++ b/drivers/media/platform/qcom/camss/camss-csid-1080.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,6 +142,7 @@ 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;
u8 lane_cnt = phy->lane_cnt;
int val;
@@ -148,8 +151,16 @@ static void __csid_configure_rx(struct csid_device *csid,
val = (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..cabbb2638cf3 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,26 @@ 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) {
+ val |= FIELD_PREP(TPG_CTRL_TEST_EN, 1);
+ writel(val, tpg->base + TPG_CTRL);
+ } else {
+ writel(val, tpg->base + TPG_CTRL);
+ writel(TPG_CTRL_CMD_TEST_EN, tpg->base + TPG_CTRL_CMD);
+ }
return 0;
}
static int tpg_reset(struct tpg_device *tpg)
{
- writel(0, tpg->base + TPG_CTRL);
- writel(1, tpg->base + TPG_CLEAR);
+ 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 63030a0659d4..5db7e12a6f86 100644
--- a/drivers/media/platform/qcom/camss/camss.c
+++ b/drivers/media/platform/qcom/camss/camss.c
@@ -5858,11 +5858,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] 48+ messages in thread
* [PATCH v21 11/14] arm64: dts: qcom: kaanapali: Add CAMSS and CSIPHY block definitions
2026-10-12 6:45 ` Hangxiang Ma
@ 2026-10-12 6:45 ` Hangxiang Ma
-1 siblings, 0 replies; 48+ messages in thread
From: Hangxiang Ma @ 2026-10-12 6:45 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 | 402 ++++++++++++++++++++++++++++++++
1 file changed, 402 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/kaanapali.dtsi b/arch/arm64/boot/dts/qcom/kaanapali.dtsi
index e48a179d0722..fb282be07e07 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>
@@ -3597,6 +3598,385 @@ 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>;
+
+ camss_csiphy0_in_port: port@0 {
+ reg = <0>;
+ };
+
+ camss_csiphy1_in_port: port@1 {
+ reg = <1>;
+ };
+
+ camss_csiphy2_in_port: port@2 {
+ reg = <2>;
+ };
+
+ camss_csiphy3_in_port: port@3 {
+ reg = <3>;
+ };
+
+ camss_csiphy4_in_port: port@4 {
+ reg = <4>;
+ };
+
+ camss_csiphy5_in_port: 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";
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ csiphy0_in_port: port@0 {
+ reg = <0>;
+ };
+
+ csiphy0_out_port: port@1 {
+ reg = <1>;
+ };
+ };
+ };
+
+ 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";
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ csiphy1_in_port: port@0 {
+ reg = <0>;
+ };
+
+ csiphy1_out_port: port@1 {
+ reg = <1>;
+ };
+ };
+ };
+
+ 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";
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ csiphy2_in_port: port@0 {
+ reg = <0>;
+ };
+
+ csiphy2_out_port: port@1 {
+ reg = <1>;
+ };
+ };
+ };
+
+ 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";
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ csiphy3_in_port: port@0 {
+ reg = <0>;
+ };
+
+ csiphy3_out_port: port@1 {
+ reg = <1>;
+ };
+ };
+ };
+
+ 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";
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ csiphy4_in_port: port@0 {
+ reg = <0>;
+ };
+
+ csiphy4_out_port: port@1 {
+ reg = <1>;
+ };
+ };
+ };
+
+ 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";
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ csiphy5_in_port: port@0 {
+ reg = <0>;
+ };
+
+ csiphy5_out_port: port@1 {
+ reg = <1>;
+ };
+ };
+ };
+
camcc: clock-controller@956d000 {
compatible = "qcom,kaanapali-camcc";
reg = <0x0 0x0956d000 0x0 0x80000>;
@@ -6548,6 +6928,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] 48+ messages in thread
* [PATCH v21 11/14] arm64: dts: qcom: kaanapali: Add CAMSS and CSIPHY block definitions
@ 2026-10-12 6:45 ` Hangxiang Ma
0 siblings, 0 replies; 48+ messages in thread
From: Hangxiang Ma @ 2026-10-12 6:45 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 | 402 ++++++++++++++++++++++++++++++++
1 file changed, 402 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/kaanapali.dtsi b/arch/arm64/boot/dts/qcom/kaanapali.dtsi
index e48a179d0722..fb282be07e07 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>
@@ -3597,6 +3598,385 @@ 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>;
+
+ camss_csiphy0_in_port: port@0 {
+ reg = <0>;
+ };
+
+ camss_csiphy1_in_port: port@1 {
+ reg = <1>;
+ };
+
+ camss_csiphy2_in_port: port@2 {
+ reg = <2>;
+ };
+
+ camss_csiphy3_in_port: port@3 {
+ reg = <3>;
+ };
+
+ camss_csiphy4_in_port: port@4 {
+ reg = <4>;
+ };
+
+ camss_csiphy5_in_port: 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";
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ csiphy0_in_port: port@0 {
+ reg = <0>;
+ };
+
+ csiphy0_out_port: port@1 {
+ reg = <1>;
+ };
+ };
+ };
+
+ 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";
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ csiphy1_in_port: port@0 {
+ reg = <0>;
+ };
+
+ csiphy1_out_port: port@1 {
+ reg = <1>;
+ };
+ };
+ };
+
+ 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";
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ csiphy2_in_port: port@0 {
+ reg = <0>;
+ };
+
+ csiphy2_out_port: port@1 {
+ reg = <1>;
+ };
+ };
+ };
+
+ 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";
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ csiphy3_in_port: port@0 {
+ reg = <0>;
+ };
+
+ csiphy3_out_port: port@1 {
+ reg = <1>;
+ };
+ };
+ };
+
+ 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";
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ csiphy4_in_port: port@0 {
+ reg = <0>;
+ };
+
+ csiphy4_out_port: port@1 {
+ reg = <1>;
+ };
+ };
+ };
+
+ 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";
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ csiphy5_in_port: port@0 {
+ reg = <0>;
+ };
+
+ csiphy5_out_port: port@1 {
+ reg = <1>;
+ };
+ };
+ };
+
camcc: clock-controller@956d000 {
compatible = "qcom,kaanapali-camcc";
reg = <0x0 0x0956d000 0x0 0x80000>;
@@ -6548,6 +6928,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] 48+ messages in thread
* [PATCH v21 12/14] arm64: dts: qcom: kaanapali: Add CCI controller nodes
2026-10-12 6:45 ` Hangxiang Ma
@ 2026-10-12 6:45 ` Hangxiang Ma
-1 siblings, 0 replies; 48+ messages in thread
From: Hangxiang Ma @ 2026-10-12 6:45 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 fb282be07e07..62f02bff0227 100644
--- a/arch/arm64/boot/dts/qcom/kaanapali.dtsi
+++ b/arch/arm64/boot/dts/qcom/kaanapali.dtsi
@@ -3749,6 +3749,117 @@ camss_csiphy5_in_port: 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>;
@@ -4537,6 +4648,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-disable;
+ };
+
+ sda-pins {
+ pins = "gpio109";
+ function = "cci_i2c_sda";
+ drive-strength = <2>;
+ bias-disable;
+ };
+ };
+
+ cci0_i2c0_sleep: cci0-i2c0-sleep-state {
+ scl-pins {
+ pins = "gpio110";
+ function = "cci_i2c_scl";
+ drive-strength = <2>;
+ bias-disable;
+ };
+
+ sda-pins {
+ pins = "gpio109";
+ function = "cci_i2c_sda";
+ drive-strength = <2>;
+ bias-disable;
+ };
+ };
+
+ cci0_i2c1_default: cci0-i2c1-default-state {
+ scl-pins {
+ pins = "gpio112";
+ function = "cci_i2c_scl";
+ drive-strength = <2>;
+ bias-disable;
+ };
+
+ sda-pins {
+ pins = "gpio111";
+ function = "cci_i2c_sda";
+ drive-strength = <2>;
+ bias-disable;
+ };
+ };
+
+ cci0_i2c1_sleep: cci0-i2c1-sleep-state {
+ scl-pins {
+ pins = "gpio112";
+ function = "cci_i2c_scl";
+ drive-strength = <2>;
+ bias-disable;
+ };
+
+ sda-pins {
+ pins = "gpio111";
+ function = "cci_i2c_sda";
+ drive-strength = <2>;
+ bias-disable;
+ };
+ };
+
+ cci1_i2c0_default: cci1-i2c0-default-state {
+ scl-pins {
+ pins = "gpio114";
+ function = "cci_i2c_scl";
+ drive-strength = <2>;
+ bias-disable;
+ };
+
+ sda-pins {
+ pins = "gpio113";
+ function = "cci_i2c_sda";
+ drive-strength = <2>;
+ bias-disable;
+ };
+ };
+
+ cci1_i2c0_sleep: cci1-i2c0-sleep-state {
+ scl-pins {
+ pins = "gpio114";
+ function = "cci_i2c_scl";
+ drive-strength = <2>;
+ bias-disable;
+ };
+
+ sda-pins {
+ pins = "gpio113";
+ function = "cci_i2c_sda";
+ drive-strength = <2>;
+ bias-disable;
+ };
+ };
+
+ cci1_i2c1_default: cci1-i2c1-default-state {
+ scl-pins {
+ pins = "gpio160";
+ function = "cci_i2c_scl";
+ drive-strength = <2>;
+ bias-disable;
+ };
+
+ sda-pins {
+ pins = "gpio107";
+ function = "cci_i2c_sda";
+ drive-strength = <2>;
+ bias-disable;
+ };
+ };
+
+ cci1_i2c1_sleep: cci1-i2c1-sleep-state {
+ scl-pins {
+ pins = "gpio160";
+ function = "cci_i2c_scl";
+ drive-strength = <2>;
+ bias-disable;
+ };
+
+ sda-pins {
+ pins = "gpio107";
+ function = "cci_i2c_sda";
+ drive-strength = <2>;
+ bias-disable;
+ };
+ };
+
+ cci2_i2c0_default: cci2-i2c0-default-state {
+ scl-pins {
+ pins = "gpio149";
+ function = "cci_i2c_scl";
+ drive-strength = <2>;
+ bias-disable;
+ };
+
+ sda-pins {
+ pins = "gpio108";
+ function = "cci_i2c_sda";
+ drive-strength = <2>;
+ bias-disable;
+ };
+ };
+
+ cci2_i2c0_sleep: cci2-i2c0-sleep-state {
+ scl-pins {
+ pins = "gpio149";
+ function = "cci_i2c_scl";
+ drive-strength = <2>;
+ bias-disable;
+ };
+
+ sda-pins {
+ pins = "gpio108";
+ function = "cci_i2c_sda";
+ drive-strength = <2>;
+ bias-disable;
+ };
+ };
+
+ cci2_i2c1_default: cci2-i2c1-default-state {
+ scl-pins {
+ pins = "gpio116";
+ function = "cci_i2c_scl";
+ drive-strength = <2>;
+ bias-disable;
+ };
+
+ sda-pins {
+ pins = "gpio115";
+ function = "cci_i2c_sda";
+ drive-strength = <2>;
+ bias-disable;
+ };
+ };
+
+ cci2_i2c1_sleep: cci2-i2c1-sleep-state {
+ scl-pins {
+ pins = "gpio116";
+ function = "cci_i2c_scl";
+ drive-strength = <2>;
+ bias-disable;
+ };
+
+ sda-pins {
+ pins = "gpio115";
+ function = "cci_i2c_sda";
+ drive-strength = <2>;
+ bias-disable;
+ };
+ };
+
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] 48+ messages in thread
* [PATCH v21 12/14] arm64: dts: qcom: kaanapali: Add CCI controller nodes
@ 2026-10-12 6:45 ` Hangxiang Ma
0 siblings, 0 replies; 48+ messages in thread
From: Hangxiang Ma @ 2026-10-12 6:45 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 fb282be07e07..62f02bff0227 100644
--- a/arch/arm64/boot/dts/qcom/kaanapali.dtsi
+++ b/arch/arm64/boot/dts/qcom/kaanapali.dtsi
@@ -3749,6 +3749,117 @@ camss_csiphy5_in_port: 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>;
@@ -4537,6 +4648,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-disable;
+ };
+
+ sda-pins {
+ pins = "gpio109";
+ function = "cci_i2c_sda";
+ drive-strength = <2>;
+ bias-disable;
+ };
+ };
+
+ cci0_i2c0_sleep: cci0-i2c0-sleep-state {
+ scl-pins {
+ pins = "gpio110";
+ function = "cci_i2c_scl";
+ drive-strength = <2>;
+ bias-disable;
+ };
+
+ sda-pins {
+ pins = "gpio109";
+ function = "cci_i2c_sda";
+ drive-strength = <2>;
+ bias-disable;
+ };
+ };
+
+ cci0_i2c1_default: cci0-i2c1-default-state {
+ scl-pins {
+ pins = "gpio112";
+ function = "cci_i2c_scl";
+ drive-strength = <2>;
+ bias-disable;
+ };
+
+ sda-pins {
+ pins = "gpio111";
+ function = "cci_i2c_sda";
+ drive-strength = <2>;
+ bias-disable;
+ };
+ };
+
+ cci0_i2c1_sleep: cci0-i2c1-sleep-state {
+ scl-pins {
+ pins = "gpio112";
+ function = "cci_i2c_scl";
+ drive-strength = <2>;
+ bias-disable;
+ };
+
+ sda-pins {
+ pins = "gpio111";
+ function = "cci_i2c_sda";
+ drive-strength = <2>;
+ bias-disable;
+ };
+ };
+
+ cci1_i2c0_default: cci1-i2c0-default-state {
+ scl-pins {
+ pins = "gpio114";
+ function = "cci_i2c_scl";
+ drive-strength = <2>;
+ bias-disable;
+ };
+
+ sda-pins {
+ pins = "gpio113";
+ function = "cci_i2c_sda";
+ drive-strength = <2>;
+ bias-disable;
+ };
+ };
+
+ cci1_i2c0_sleep: cci1-i2c0-sleep-state {
+ scl-pins {
+ pins = "gpio114";
+ function = "cci_i2c_scl";
+ drive-strength = <2>;
+ bias-disable;
+ };
+
+ sda-pins {
+ pins = "gpio113";
+ function = "cci_i2c_sda";
+ drive-strength = <2>;
+ bias-disable;
+ };
+ };
+
+ cci1_i2c1_default: cci1-i2c1-default-state {
+ scl-pins {
+ pins = "gpio160";
+ function = "cci_i2c_scl";
+ drive-strength = <2>;
+ bias-disable;
+ };
+
+ sda-pins {
+ pins = "gpio107";
+ function = "cci_i2c_sda";
+ drive-strength = <2>;
+ bias-disable;
+ };
+ };
+
+ cci1_i2c1_sleep: cci1-i2c1-sleep-state {
+ scl-pins {
+ pins = "gpio160";
+ function = "cci_i2c_scl";
+ drive-strength = <2>;
+ bias-disable;
+ };
+
+ sda-pins {
+ pins = "gpio107";
+ function = "cci_i2c_sda";
+ drive-strength = <2>;
+ bias-disable;
+ };
+ };
+
+ cci2_i2c0_default: cci2-i2c0-default-state {
+ scl-pins {
+ pins = "gpio149";
+ function = "cci_i2c_scl";
+ drive-strength = <2>;
+ bias-disable;
+ };
+
+ sda-pins {
+ pins = "gpio108";
+ function = "cci_i2c_sda";
+ drive-strength = <2>;
+ bias-disable;
+ };
+ };
+
+ cci2_i2c0_sleep: cci2-i2c0-sleep-state {
+ scl-pins {
+ pins = "gpio149";
+ function = "cci_i2c_scl";
+ drive-strength = <2>;
+ bias-disable;
+ };
+
+ sda-pins {
+ pins = "gpio108";
+ function = "cci_i2c_sda";
+ drive-strength = <2>;
+ bias-disable;
+ };
+ };
+
+ cci2_i2c1_default: cci2-i2c1-default-state {
+ scl-pins {
+ pins = "gpio116";
+ function = "cci_i2c_scl";
+ drive-strength = <2>;
+ bias-disable;
+ };
+
+ sda-pins {
+ pins = "gpio115";
+ function = "cci_i2c_sda";
+ drive-strength = <2>;
+ bias-disable;
+ };
+ };
+
+ cci2_i2c1_sleep: cci2-i2c1-sleep-state {
+ scl-pins {
+ pins = "gpio116";
+ function = "cci_i2c_scl";
+ drive-strength = <2>;
+ bias-disable;
+ };
+
+ sda-pins {
+ pins = "gpio115";
+ function = "cci_i2c_sda";
+ drive-strength = <2>;
+ bias-disable;
+ };
+ };
+
hub_i2c0_data_clk: hub-i2c0-data-clk-state {
/* SDA, SCL */
pins = "gpio66", "gpio67";
--
2.34.1
^ permalink raw reply related [flat|nested] 48+ messages in thread
* [PATCH v21 13/14] arm64: dts: qcom: kaanapali: Add camera MCLK pinctrl
2026-10-12 6:45 ` Hangxiang Ma
@ 2026-10-12 6:45 ` Hangxiang Ma
-1 siblings, 0 replies; 48+ messages in thread
From: Hangxiang Ma @ 2026-10-12 6:45 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 62f02bff0227..63fae1bbfe66 100644
--- a/arch/arm64/boot/dts/qcom/kaanapali.dtsi
+++ b/arch/arm64/boot/dts/qcom/kaanapali.dtsi
@@ -4648,6 +4648,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] 48+ messages in thread
* [PATCH v21 13/14] arm64: dts: qcom: kaanapali: Add camera MCLK pinctrl
@ 2026-10-12 6:45 ` Hangxiang Ma
0 siblings, 0 replies; 48+ messages in thread
From: Hangxiang Ma @ 2026-10-12 6:45 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 62f02bff0227..63fae1bbfe66 100644
--- a/arch/arm64/boot/dts/qcom/kaanapali.dtsi
+++ b/arch/arm64/boot/dts/qcom/kaanapali.dtsi
@@ -4648,6 +4648,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] 48+ messages in thread
* [PATCH v21 14/14] arm64: dts: qcom: kaanapali-mtp-camera-s5kjn5: Add DT overlay
2026-10-12 6:45 ` Hangxiang Ma
@ 2026-10-12 6:45 ` Hangxiang Ma
-1 siblings, 0 replies; 48+ messages in thread
From: Hangxiang Ma @ 2026-10-12 6:45 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
Enable the S5KJN5 image sensor via CCI on Kaanapali MTP board.
The Kaanapali MTP board connect S5KJN5 with QUP I2C bus by default. This
DTBO enables S5KJN5 on CCI-0 interface connected to the CSIPHY2 in four
lane mode on a rework camera module.
Signed-off-by: Hangxiang Ma <hangxiang.ma@oss.qualcomm.com>
---
arch/arm64/boot/dts/qcom/Makefile | 5 ++
.../boot/dts/qcom/kaanapali-mtp-camera-s5kjn5.dtso | 81 ++++++++++++++++++++++
arch/arm64/boot/dts/qcom/kaanapali-mtp.dts | 7 ++
3 files changed, 93 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/Makefile b/arch/arm64/boot/dts/qcom/Makefile
index 88230c4e00ea..84b244d43e9e 100644
--- a/arch/arm64/boot/dts/qcom/Makefile
+++ b/arch/arm64/boot/dts/qcom/Makefile
@@ -48,6 +48,11 @@ dtb-$(CONFIG_ARCH_QCOM) += ipq9574-rdp449.dtb
dtb-$(CONFIG_ARCH_QCOM) += ipq9574-rdp453.dtb
dtb-$(CONFIG_ARCH_QCOM) += ipq9574-rdp454.dtb
dtb-$(CONFIG_ARCH_QCOM) += ipq9650-rdp488.dtb
+dtb-$(CONFIG_ARCH_QCOM) += kaanapali-mtp-camera-s5kjn5.dtbo
+
+kaanapali-mtp-camera-s5kjn5-dtbs := kaanapali-mtp.dtb kaanapali-mtp-camera-s5kjn5.dtbo
+
+dtb-$(CONFIG_ARCH_QCOM) += kaanapali-mtp-camera-s5kjn5.dtb
dtb-$(CONFIG_ARCH_QCOM) += kaanapali-mtp.dtb
dtb-$(CONFIG_ARCH_QCOM) += kaanapali-qrd.dtb
dtb-$(CONFIG_ARCH_QCOM) += lemans-evk.dtb
diff --git a/arch/arm64/boot/dts/qcom/kaanapali-mtp-camera-s5kjn5.dtso b/arch/arm64/boot/dts/qcom/kaanapali-mtp-camera-s5kjn5.dtso
new file mode 100644
index 000000000000..d0e39855e0e6
--- /dev/null
+++ b/arch/arm64/boot/dts/qcom/kaanapali-mtp-camera-s5kjn5.dtso
@@ -0,0 +1,81 @@
+// SPDX-License-Identifier: BSD-3-Clause
+/*
+ * Copyright (c) Qualcomm Technologies, Inc. and/or its subsidiaries.
+ */
+
+/dts-v1/;
+/plugin/;
+
+#include <dt-bindings/clock/qcom,kaanapali-cambistmclkcc.h>
+#include <dt-bindings/clock/qcom,kaanapali-camcc.h>
+#include <dt-bindings/gpio/gpio.h>
+#include <dt-bindings/media/video-interfaces.h>
+
+&camss {
+ status = "okay";
+};
+
+&camss_csiphy2_in_port {
+ camss_csiphy2_inep: endpoint {
+ data-lanes = <1 2 3 4>;
+ remote-endpoint = <&csiphy2_out_ep>;
+ };
+};
+
+&cci0 {
+ status = "okay";
+};
+
+&cci0_i2c1 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ camera@10 {
+ compatible = "samsung,s5kjn5";
+ reg = <0x10>;
+
+ reset-gpios = <&tlmm 3 GPIO_ACTIVE_LOW>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&cam_mclk2_default &cam_reset2_default>;
+
+ clocks = <&cambistmclkcc CAM_BIST_MCLK_CC_MCLK2_CLK>;
+ assigned-clocks = <&cambistmclkcc CAM_BIST_MCLK_CC_MCLK2_CLK>;
+ assigned-clock-rates = <19200000>;
+
+ vddio-supply = <&vreg_l4n_1p8>;
+ vddd-supply = <&vreg_l1m_1p0>;
+ vdda-supply = <&vreg_l4m_2p2>;
+ vddio1p2-supply = <&vreg_l2n_1p2>;
+ afvdd-supply = <&vreg_l7m_2p8>;
+
+ port {
+ s5kjn5_out_ep: endpoint {
+ data-lanes = <1 2 3 4>;
+ link-frequencies = /bits/ 64 <1248000000>;
+ remote-endpoint = <&csiphy2_in_ep>;
+ };
+ };
+ };
+};
+
+&csiphy2 {
+ vdda-0p9-supply = <&vreg_l3d_0p8>;
+ vdda-1p2-supply = <&vreg_l1d_1p2>;
+
+ status = "okay";
+};
+
+&csiphy2_in_port {
+ csiphy2_in_ep: endpoint {
+ bus-type = <MEDIA_BUS_TYPE_CSI2_DPHY>;
+ clock-lanes = <0>;
+ data-lanes = <1 2 3 4>;
+ remote-endpoint = <&s5kjn5_out_ep>;
+ };
+};
+
+&csiphy2_out_port {
+ csiphy2_out_ep: endpoint {
+ remote-endpoint = <&camss_csiphy2_inep>;
+ };
+};
diff --git a/arch/arm64/boot/dts/qcom/kaanapali-mtp.dts b/arch/arm64/boot/dts/qcom/kaanapali-mtp.dts
index 9eb02fd09dab..c70cd39bcb75 100644
--- a/arch/arm64/boot/dts/qcom/kaanapali-mtp.dts
+++ b/arch/arm64/boot/dts/qcom/kaanapali-mtp.dts
@@ -1243,6 +1243,13 @@ &tlmm {
<119 2>, /* SoCCP */
<144 4>; /* CXM UART */
+ cam_reset2_default: cam-reset2-default-state {
+ pins = "gpio3";
+ function = "gpio";
+ drive-strength = <16>;
+ bias-disable;
+ };
+
wlan_en: wlan-en-state {
pins = "gpio16";
function = "gpio";
--
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] 48+ messages in thread
* [PATCH v21 14/14] arm64: dts: qcom: kaanapali-mtp-camera-s5kjn5: Add DT overlay
@ 2026-10-12 6:45 ` Hangxiang Ma
0 siblings, 0 replies; 48+ messages in thread
From: Hangxiang Ma @ 2026-10-12 6:45 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
Enable the S5KJN5 image sensor via CCI on Kaanapali MTP board.
The Kaanapali MTP board connect S5KJN5 with QUP I2C bus by default. This
DTBO enables S5KJN5 on CCI-0 interface connected to the CSIPHY2 in four
lane mode on a rework camera module.
Signed-off-by: Hangxiang Ma <hangxiang.ma@oss.qualcomm.com>
---
arch/arm64/boot/dts/qcom/Makefile | 5 ++
.../boot/dts/qcom/kaanapali-mtp-camera-s5kjn5.dtso | 81 ++++++++++++++++++++++
arch/arm64/boot/dts/qcom/kaanapali-mtp.dts | 7 ++
3 files changed, 93 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/Makefile b/arch/arm64/boot/dts/qcom/Makefile
index 88230c4e00ea..84b244d43e9e 100644
--- a/arch/arm64/boot/dts/qcom/Makefile
+++ b/arch/arm64/boot/dts/qcom/Makefile
@@ -48,6 +48,11 @@ dtb-$(CONFIG_ARCH_QCOM) += ipq9574-rdp449.dtb
dtb-$(CONFIG_ARCH_QCOM) += ipq9574-rdp453.dtb
dtb-$(CONFIG_ARCH_QCOM) += ipq9574-rdp454.dtb
dtb-$(CONFIG_ARCH_QCOM) += ipq9650-rdp488.dtb
+dtb-$(CONFIG_ARCH_QCOM) += kaanapali-mtp-camera-s5kjn5.dtbo
+
+kaanapali-mtp-camera-s5kjn5-dtbs := kaanapali-mtp.dtb kaanapali-mtp-camera-s5kjn5.dtbo
+
+dtb-$(CONFIG_ARCH_QCOM) += kaanapali-mtp-camera-s5kjn5.dtb
dtb-$(CONFIG_ARCH_QCOM) += kaanapali-mtp.dtb
dtb-$(CONFIG_ARCH_QCOM) += kaanapali-qrd.dtb
dtb-$(CONFIG_ARCH_QCOM) += lemans-evk.dtb
diff --git a/arch/arm64/boot/dts/qcom/kaanapali-mtp-camera-s5kjn5.dtso b/arch/arm64/boot/dts/qcom/kaanapali-mtp-camera-s5kjn5.dtso
new file mode 100644
index 000000000000..d0e39855e0e6
--- /dev/null
+++ b/arch/arm64/boot/dts/qcom/kaanapali-mtp-camera-s5kjn5.dtso
@@ -0,0 +1,81 @@
+// SPDX-License-Identifier: BSD-3-Clause
+/*
+ * Copyright (c) Qualcomm Technologies, Inc. and/or its subsidiaries.
+ */
+
+/dts-v1/;
+/plugin/;
+
+#include <dt-bindings/clock/qcom,kaanapali-cambistmclkcc.h>
+#include <dt-bindings/clock/qcom,kaanapali-camcc.h>
+#include <dt-bindings/gpio/gpio.h>
+#include <dt-bindings/media/video-interfaces.h>
+
+&camss {
+ status = "okay";
+};
+
+&camss_csiphy2_in_port {
+ camss_csiphy2_inep: endpoint {
+ data-lanes = <1 2 3 4>;
+ remote-endpoint = <&csiphy2_out_ep>;
+ };
+};
+
+&cci0 {
+ status = "okay";
+};
+
+&cci0_i2c1 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ camera@10 {
+ compatible = "samsung,s5kjn5";
+ reg = <0x10>;
+
+ reset-gpios = <&tlmm 3 GPIO_ACTIVE_LOW>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&cam_mclk2_default &cam_reset2_default>;
+
+ clocks = <&cambistmclkcc CAM_BIST_MCLK_CC_MCLK2_CLK>;
+ assigned-clocks = <&cambistmclkcc CAM_BIST_MCLK_CC_MCLK2_CLK>;
+ assigned-clock-rates = <19200000>;
+
+ vddio-supply = <&vreg_l4n_1p8>;
+ vddd-supply = <&vreg_l1m_1p0>;
+ vdda-supply = <&vreg_l4m_2p2>;
+ vddio1p2-supply = <&vreg_l2n_1p2>;
+ afvdd-supply = <&vreg_l7m_2p8>;
+
+ port {
+ s5kjn5_out_ep: endpoint {
+ data-lanes = <1 2 3 4>;
+ link-frequencies = /bits/ 64 <1248000000>;
+ remote-endpoint = <&csiphy2_in_ep>;
+ };
+ };
+ };
+};
+
+&csiphy2 {
+ vdda-0p9-supply = <&vreg_l3d_0p8>;
+ vdda-1p2-supply = <&vreg_l1d_1p2>;
+
+ status = "okay";
+};
+
+&csiphy2_in_port {
+ csiphy2_in_ep: endpoint {
+ bus-type = <MEDIA_BUS_TYPE_CSI2_DPHY>;
+ clock-lanes = <0>;
+ data-lanes = <1 2 3 4>;
+ remote-endpoint = <&s5kjn5_out_ep>;
+ };
+};
+
+&csiphy2_out_port {
+ csiphy2_out_ep: endpoint {
+ remote-endpoint = <&camss_csiphy2_inep>;
+ };
+};
diff --git a/arch/arm64/boot/dts/qcom/kaanapali-mtp.dts b/arch/arm64/boot/dts/qcom/kaanapali-mtp.dts
index 9eb02fd09dab..c70cd39bcb75 100644
--- a/arch/arm64/boot/dts/qcom/kaanapali-mtp.dts
+++ b/arch/arm64/boot/dts/qcom/kaanapali-mtp.dts
@@ -1243,6 +1243,13 @@ &tlmm {
<119 2>, /* SoCCP */
<144 4>; /* CXM UART */
+ cam_reset2_default: cam-reset2-default-state {
+ pins = "gpio3";
+ function = "gpio";
+ drive-strength = <16>;
+ bias-disable;
+ };
+
wlan_en: wlan-en-state {
pins = "gpio16";
function = "gpio";
--
2.34.1
^ permalink raw reply related [flat|nested] 48+ messages in thread
* Re: [PATCH v21 14/14] arm64: dts: qcom: kaanapali-mtp-camera-s5kjn5: Add DT overlay
2026-10-12 6:45 ` Hangxiang Ma
@ 2026-10-12 6:57 ` sashiko-bot
-1 siblings, 0 replies; 48+ messages in thread
From: sashiko-bot @ 2026-10-12 6:57 UTC (permalink / raw)
To: Hangxiang Ma
Cc: vkoul, media-ci, robh, olteanv, linux-phy, devicetree, conor+dt,
neil.armstrong
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] dts: qcom: missing vddm-supply in s5kjn5 camera node
--
commit c1df83521b79d78bdf83d4c496be4b0e82a9f05c
Author: Hangxiang Ma <hangxiang.ma@oss.qualcomm.com>
arm64: dts: qcom: kaanapali-mtp-camera-s5kjn5: Add DT overlay
This commit enables the S5KJN5 image sensor via CCI on the Kaanapali MTP
board. It adds a device tree overlay for the camera module connected to
the CSIPHY2 interface in four lane mode.
> diff --git a/arch/arm64/boot/dts/qcom/kaanapali-mtp-camera-s5kjn5.dtso b/arch/arm64/boot/dts/qcom/kaanapali-mtp-camera-s5kjn5.dtso
> new file mode 100644
> index 0000000000000..d0e39855e0e62
> --- /dev/null
> +++ b/arch/arm64/boot/dts/qcom/kaanapali-mtp-camera-s5kjn5.dtso
[ ... ]
> +&cci0_i2c1 {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + camera@10 {
> + compatible = "samsung,s5kjn5";
> + reg = <0x10>;
> +
> + reset-gpios = <&tlmm 3 GPIO_ACTIVE_LOW>;
> + pinctrl-names = "default";
> + pinctrl-0 = <&cam_mclk2_default &cam_reset2_default>;
> +
> + clocks = <&cambistmclkcc CAM_BIST_MCLK_CC_MCLK2_CLK>;
> + assigned-clocks = <&cambistmclkcc CAM_BIST_MCLK_CC_MCLK2_CLK>;
> + assigned-clock-rates = <19200000>;
> +
> + vddio-supply = <&vreg_l4n_1p8>;
> + vddd-supply = <&vreg_l1m_1p0>;
> + vdda-supply = <&vreg_l4m_2p2>;
> + vddio1p2-supply = <&vreg_l2n_1p2>;
> + afvdd-supply = <&vreg_l7m_2p8>;
[Severity: High]
Does this device tree node omit the vddm-supply property?
Looking at the s5kjn5 driver in drivers/media/i2c/s5kjn5.c, it
unconditionally requires the "vddm" regulator during probe:
static const char * const s5kjn5_supply_names[] = {
"vddio",
"vddd",
"vddm",
"vdda",
"vddio1p2",
"afvdd",
};
Missing this property in the DT overlay will cause the driver probe to
fail with -ENODEV, or if the regulator core substitutes a dummy regulator,
the physical MIPI PHY power domain may remain unpowered, causing the sensor
to fail to stream.
> +
> + port {
> + s5kjn5_out_ep: endpoint {
> + data-lanes = <1 2 3 4>;
> + link-frequencies = /bits/ 64 <1248000000>;
> + remote-endpoint = <&csiphy2_in_ep>;
> + };
> + };
> + };
> +};
--
Sashiko AI review · https://sashiko.dev/#/patchset/20261011-kaanapali-camss-v21-0-04fd28d815c6@oss.qualcomm.com?part=14
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply [flat|nested] 48+ messages in thread
* Re: [PATCH v21 14/14] arm64: dts: qcom: kaanapali-mtp-camera-s5kjn5: Add DT overlay
@ 2026-10-12 6:57 ` sashiko-bot
0 siblings, 0 replies; 48+ messages in thread
From: sashiko-bot @ 2026-10-12 6:57 UTC (permalink / raw)
To: Hangxiang Ma
Cc: vkoul, media-ci, robh, olteanv, linux-phy, devicetree, conor+dt,
neil.armstrong
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] dts: qcom: missing vddm-supply in s5kjn5 camera node
--
commit c1df83521b79d78bdf83d4c496be4b0e82a9f05c
Author: Hangxiang Ma <hangxiang.ma@oss.qualcomm.com>
arm64: dts: qcom: kaanapali-mtp-camera-s5kjn5: Add DT overlay
This commit enables the S5KJN5 image sensor via CCI on the Kaanapali MTP
board. It adds a device tree overlay for the camera module connected to
the CSIPHY2 interface in four lane mode.
> diff --git a/arch/arm64/boot/dts/qcom/kaanapali-mtp-camera-s5kjn5.dtso b/arch/arm64/boot/dts/qcom/kaanapali-mtp-camera-s5kjn5.dtso
> new file mode 100644
> index 0000000000000..d0e39855e0e62
> --- /dev/null
> +++ b/arch/arm64/boot/dts/qcom/kaanapali-mtp-camera-s5kjn5.dtso
[ ... ]
> +&cci0_i2c1 {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + camera@10 {
> + compatible = "samsung,s5kjn5";
> + reg = <0x10>;
> +
> + reset-gpios = <&tlmm 3 GPIO_ACTIVE_LOW>;
> + pinctrl-names = "default";
> + pinctrl-0 = <&cam_mclk2_default &cam_reset2_default>;
> +
> + clocks = <&cambistmclkcc CAM_BIST_MCLK_CC_MCLK2_CLK>;
> + assigned-clocks = <&cambistmclkcc CAM_BIST_MCLK_CC_MCLK2_CLK>;
> + assigned-clock-rates = <19200000>;
> +
> + vddio-supply = <&vreg_l4n_1p8>;
> + vddd-supply = <&vreg_l1m_1p0>;
> + vdda-supply = <&vreg_l4m_2p2>;
> + vddio1p2-supply = <&vreg_l2n_1p2>;
> + afvdd-supply = <&vreg_l7m_2p8>;
[Severity: High]
Does this device tree node omit the vddm-supply property?
Looking at the s5kjn5 driver in drivers/media/i2c/s5kjn5.c, it
unconditionally requires the "vddm" regulator during probe:
static const char * const s5kjn5_supply_names[] = {
"vddio",
"vddd",
"vddm",
"vdda",
"vddio1p2",
"afvdd",
};
Missing this property in the DT overlay will cause the driver probe to
fail with -ENODEV, or if the regulator core substitutes a dummy regulator,
the physical MIPI PHY power domain may remain unpowered, causing the sensor
to fail to stream.
> +
> + port {
> + s5kjn5_out_ep: endpoint {
> + data-lanes = <1 2 3 4>;
> + link-frequencies = /bits/ 64 <1248000000>;
> + remote-endpoint = <&csiphy2_in_ep>;
> + };
> + };
> + };
> +};
--
Sashiko AI review · https://sashiko.dev/#/patchset/20261011-kaanapali-camss-v21-0-04fd28d815c6@oss.qualcomm.com?part=14
^ permalink raw reply [flat|nested] 48+ messages in thread
* Re: [PATCH v21 08/14] media: qcom: camss: csid: Add support for CSID 1080
2026-10-12 6:45 ` Hangxiang Ma
@ 2026-10-12 6:59 ` sashiko-bot
-1 siblings, 0 replies; 48+ messages in thread
From: sashiko-bot @ 2026-10-12 6:59 UTC (permalink / raw)
To: Hangxiang Ma
Cc: neil.armstrong, robh, olteanv, linux-phy, conor+dt, devicetree,
vkoul, media-ci
Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [High] media: qcom: camss: data race on aup_update and rup_update bitmasks
- [Medium] media: qcom: camss: missing RDIN IRQ mask initialization for CSID 1080
--
commit fed0f4820343d4e1580122110f1a96556fcee36c
Author: Hangxiang Ma <hangxiang.ma@oss.qualcomm.com>
media: qcom: camss: csid: Add support for CSID 1080
This commit adds support for the CSID 1080 hardware found on the
Kaanapali SoC. It introduces hardware resource descriptions, reset
sequences, and interrupt handling. It also updates the CSID interface
to handle separate RUP and AUP registers.
> diff --git a/drivers/media/platform/qcom/camss/camss-csid-1080.c b/drivers/media/platform/qcom/camss/camss-csid-1080.c
> new file mode 100644
> index 0000000000000..46e443e05195a
> --- /dev/null
> +++ b/drivers/media/platform/qcom/camss/camss-csid-1080.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);
[Severity: High]
Can these non-atomic bitwise operations race with the interrupt handler?
__csid_aup_rup_clear() runs in hardirq context via csid_isr(), modifying
both csid->aup_update and csid->rup_update.
Concurrently, __csid_aup_update() and __csid_reg_update() perform non-atomic
bitwise OR operations on these same shared bitmasks from process context
during csid_configure_stream().
Without synchronization such as spin_lock_irqsave() or using atomic bitops,
could process context overwrite the interrupt handler's modifications,
resurrecting cleared bits or dropping newly set bits? This might lead to
missed or redundant hardware updates.
> + writel(csid->rup_update, csid->base + CSID_RUP_CMD);
> +
> + __csid_aup_rup_trigger(csid);
> +}
[ ... ]
> +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_1080; 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)
[Severity: Medium]
Will this INFO_RUP_DONE status actually latch in hardware?
The CSID_CSI2_RDIN_IRQ_MASK macro is defined, but it doesn't seem to ever
be written to hardware to enable this interrupt during csid_reset() or
csid_configure_stream().
If the mask remains zero, the status bit might not be recorded. As a result,
csid_isr() would never observe INFO_RUP_DONE, failing to clear
csid->aup_update and leaking stale bitmasks across frames.
> + 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;
> +}
--
Sashiko AI review · https://sashiko.dev/#/patchset/20261011-kaanapali-camss-v21-0-04fd28d815c6@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] 48+ messages in thread
* Re: [PATCH v21 08/14] media: qcom: camss: csid: Add support for CSID 1080
@ 2026-10-12 6:59 ` sashiko-bot
0 siblings, 0 replies; 48+ messages in thread
From: sashiko-bot @ 2026-10-12 6:59 UTC (permalink / raw)
To: Hangxiang Ma
Cc: neil.armstrong, robh, olteanv, linux-phy, conor+dt, devicetree,
vkoul, media-ci
Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [High] media: qcom: camss: data race on aup_update and rup_update bitmasks
- [Medium] media: qcom: camss: missing RDIN IRQ mask initialization for CSID 1080
--
commit fed0f4820343d4e1580122110f1a96556fcee36c
Author: Hangxiang Ma <hangxiang.ma@oss.qualcomm.com>
media: qcom: camss: csid: Add support for CSID 1080
This commit adds support for the CSID 1080 hardware found on the
Kaanapali SoC. It introduces hardware resource descriptions, reset
sequences, and interrupt handling. It also updates the CSID interface
to handle separate RUP and AUP registers.
> diff --git a/drivers/media/platform/qcom/camss/camss-csid-1080.c b/drivers/media/platform/qcom/camss/camss-csid-1080.c
> new file mode 100644
> index 0000000000000..46e443e05195a
> --- /dev/null
> +++ b/drivers/media/platform/qcom/camss/camss-csid-1080.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);
[Severity: High]
Can these non-atomic bitwise operations race with the interrupt handler?
__csid_aup_rup_clear() runs in hardirq context via csid_isr(), modifying
both csid->aup_update and csid->rup_update.
Concurrently, __csid_aup_update() and __csid_reg_update() perform non-atomic
bitwise OR operations on these same shared bitmasks from process context
during csid_configure_stream().
Without synchronization such as spin_lock_irqsave() or using atomic bitops,
could process context overwrite the interrupt handler's modifications,
resurrecting cleared bits or dropping newly set bits? This might lead to
missed or redundant hardware updates.
> + writel(csid->rup_update, csid->base + CSID_RUP_CMD);
> +
> + __csid_aup_rup_trigger(csid);
> +}
[ ... ]
> +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_1080; 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)
[Severity: Medium]
Will this INFO_RUP_DONE status actually latch in hardware?
The CSID_CSI2_RDIN_IRQ_MASK macro is defined, but it doesn't seem to ever
be written to hardware to enable this interrupt during csid_reset() or
csid_configure_stream().
If the mask remains zero, the status bit might not be recorded. As a result,
csid_isr() would never observe INFO_RUP_DONE, failing to clear
csid->aup_update and leaking stale bitmasks across frames.
> + 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;
> +}
--
Sashiko AI review · https://sashiko.dev/#/patchset/20261011-kaanapali-camss-v21-0-04fd28d815c6@oss.qualcomm.com?part=8
^ permalink raw reply [flat|nested] 48+ messages in thread
* Re: [PATCH v21 14/14] arm64: dts: qcom: kaanapali-mtp-camera-s5kjn5: Add DT overlay
2026-10-12 6:57 ` sashiko-bot
@ 2026-10-12 6:59 ` Hangxiang Ma
-1 siblings, 0 replies; 48+ messages in thread
From: Hangxiang Ma @ 2026-10-12 6:59 UTC (permalink / raw)
To: sashiko-reviews
Cc: vkoul, media-ci, robh, olteanv, linux-phy, devicetree, conor+dt,
neil.armstrong
On 10/12/2026 2:57 PM, sashiko-bot@kernel.org wrote:
> Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
> - [High] dts: qcom: missing vddm-supply in s5kjn5 camera node
> --
>
> commit c1df83521b79d78bdf83d4c496be4b0e82a9f05c
> Author: Hangxiang Ma <hangxiang.ma@oss.qualcomm.com>
>
> arm64: dts: qcom: kaanapali-mtp-camera-s5kjn5: Add DT overlay
>
> This commit enables the S5KJN5 image sensor via CCI on the Kaanapali MTP
> board. It adds a device tree overlay for the camera module connected to
> the CSIPHY2 interface in four lane mode.
>
>> diff --git a/arch/arm64/boot/dts/qcom/kaanapali-mtp-camera-s5kjn5.dtso b/arch/arm64/boot/dts/qcom/kaanapali-mtp-camera-s5kjn5.dtso
>> new file mode 100644
>> index 0000000000000..d0e39855e0e62
>> --- /dev/null
>> +++ b/arch/arm64/boot/dts/qcom/kaanapali-mtp-camera-s5kjn5.dtso
> [ ... ]
>> +&cci0_i2c1 {
>> + #address-cells = <1>;
>> + #size-cells = <0>;
>> +
>> + camera@10 {
>> + compatible = "samsung,s5kjn5";
>> + reg = <0x10>;
>> +
>> + reset-gpios = <&tlmm 3 GPIO_ACTIVE_LOW>;
>> + pinctrl-names = "default";
>> + pinctrl-0 = <&cam_mclk2_default &cam_reset2_default>;
>> +
>> + clocks = <&cambistmclkcc CAM_BIST_MCLK_CC_MCLK2_CLK>;
>> + assigned-clocks = <&cambistmclkcc CAM_BIST_MCLK_CC_MCLK2_CLK>;
>> + assigned-clock-rates = <19200000>;
>> +
>> + vddio-supply = <&vreg_l4n_1p8>;
>> + vddd-supply = <&vreg_l1m_1p0>;
>> + vdda-supply = <&vreg_l4m_2p2>;
>> + vddio1p2-supply = <&vreg_l2n_1p2>;
>> + afvdd-supply = <&vreg_l7m_2p8>;
>
> [Severity: High]
> Does this device tree node omit the vddm-supply property?
>
> Looking at the s5kjn5 driver in drivers/media/i2c/s5kjn5.c, it
> unconditionally requires the "vddm" regulator during probe:
>
> static const char * const s5kjn5_supply_names[] = {
> "vddio",
> "vddd",
> "vddm",
> "vdda",
> "vddio1p2",
> "afvdd",
> };
>
> Missing this property in the DT overlay will cause the driver probe to
> fail with -ENODEV, or if the regulator core substitutes a dummy regulator,
> the physical MIPI PHY power domain may remain unpowered, causing the sensor
> to fail to stream.
>
>> +
>> + port {
>> + s5kjn5_out_ep: endpoint {
>> + data-lanes = <1 2 3 4>;
>> + link-frequencies = /bits/ 64 <1248000000>;
>> + remote-endpoint = <&csiphy2_in_ep>;
>> + };
>> + };
>> + };
>> +};
>
vddm is an optional power supply and on this JN5 daughter card we don't
this power rail.
---
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] 48+ messages in thread
* Re: [PATCH v21 14/14] arm64: dts: qcom: kaanapali-mtp-camera-s5kjn5: Add DT overlay
@ 2026-10-12 6:59 ` Hangxiang Ma
0 siblings, 0 replies; 48+ messages in thread
From: Hangxiang Ma @ 2026-10-12 6:59 UTC (permalink / raw)
To: sashiko-reviews
Cc: vkoul, media-ci, robh, olteanv, linux-phy, devicetree, conor+dt,
neil.armstrong
On 10/12/2026 2:57 PM, sashiko-bot@kernel.org wrote:
> Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
> - [High] dts: qcom: missing vddm-supply in s5kjn5 camera node
> --
>
> commit c1df83521b79d78bdf83d4c496be4b0e82a9f05c
> Author: Hangxiang Ma <hangxiang.ma@oss.qualcomm.com>
>
> arm64: dts: qcom: kaanapali-mtp-camera-s5kjn5: Add DT overlay
>
> This commit enables the S5KJN5 image sensor via CCI on the Kaanapali MTP
> board. It adds a device tree overlay for the camera module connected to
> the CSIPHY2 interface in four lane mode.
>
>> diff --git a/arch/arm64/boot/dts/qcom/kaanapali-mtp-camera-s5kjn5.dtso b/arch/arm64/boot/dts/qcom/kaanapali-mtp-camera-s5kjn5.dtso
>> new file mode 100644
>> index 0000000000000..d0e39855e0e62
>> --- /dev/null
>> +++ b/arch/arm64/boot/dts/qcom/kaanapali-mtp-camera-s5kjn5.dtso
> [ ... ]
>> +&cci0_i2c1 {
>> + #address-cells = <1>;
>> + #size-cells = <0>;
>> +
>> + camera@10 {
>> + compatible = "samsung,s5kjn5";
>> + reg = <0x10>;
>> +
>> + reset-gpios = <&tlmm 3 GPIO_ACTIVE_LOW>;
>> + pinctrl-names = "default";
>> + pinctrl-0 = <&cam_mclk2_default &cam_reset2_default>;
>> +
>> + clocks = <&cambistmclkcc CAM_BIST_MCLK_CC_MCLK2_CLK>;
>> + assigned-clocks = <&cambistmclkcc CAM_BIST_MCLK_CC_MCLK2_CLK>;
>> + assigned-clock-rates = <19200000>;
>> +
>> + vddio-supply = <&vreg_l4n_1p8>;
>> + vddd-supply = <&vreg_l1m_1p0>;
>> + vdda-supply = <&vreg_l4m_2p2>;
>> + vddio1p2-supply = <&vreg_l2n_1p2>;
>> + afvdd-supply = <&vreg_l7m_2p8>;
>
> [Severity: High]
> Does this device tree node omit the vddm-supply property?
>
> Looking at the s5kjn5 driver in drivers/media/i2c/s5kjn5.c, it
> unconditionally requires the "vddm" regulator during probe:
>
> static const char * const s5kjn5_supply_names[] = {
> "vddio",
> "vddd",
> "vddm",
> "vdda",
> "vddio1p2",
> "afvdd",
> };
>
> Missing this property in the DT overlay will cause the driver probe to
> fail with -ENODEV, or if the regulator core substitutes a dummy regulator,
> the physical MIPI PHY power domain may remain unpowered, causing the sensor
> to fail to stream.
>
>> +
>> + port {
>> + s5kjn5_out_ep: endpoint {
>> + data-lanes = <1 2 3 4>;
>> + link-frequencies = /bits/ 64 <1248000000>;
>> + remote-endpoint = <&csiphy2_in_ep>;
>> + };
>> + };
>> + };
>> +};
>
vddm is an optional power supply and on this JN5 daughter card we don't
this power rail.
---
Best Regards,
Hangxiang
^ permalink raw reply [flat|nested] 48+ messages in thread
* Re: [PATCH v21 06/14] media: qcom: camss: Add Kaanapali compatible
2026-10-12 6:45 ` Hangxiang Ma
@ 2026-10-12 7:00 ` sashiko-bot
-1 siblings, 0 replies; 48+ messages in thread
From: sashiko-bot @ 2026-10-12 7:00 UTC (permalink / raw)
To: Hangxiang Ma
Cc: neil.armstrong, robh, conor+dt, devicetree, olteanv, vkoul,
linux-phy, media-ci
Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [High] media: camss: missing DT port bounds check causes OOB array access on csiphy
- [High] media: camss: dev_pm_domain_detach() NULL pointer dereference on cleanup
--
commit 226a568dbea1991f8bda4c0b73de0c31f612545e
Author: Hangxiang Ma <hangxiang.ma@oss.qualcomm.com>
media: qcom: camss: Add Kaanapali compatible
Add CAMSS_KAANAPALI enum, Kaanapali compatible and Kaanapali CAMSS driver
private data. The private data currently includes only basic information.
Later changes will add CSIPHY, TPG, CSID and VFE resources.
> diff --git a/drivers/media/platform/qcom/camss/camss.c b/drivers/media/platform/qcom/camss/camss.c
> index c54185c93a8a9..fca3de214a922 100644
> --- a/drivers/media/platform/qcom/camss/camss.c
> +++ b/drivers/media/platform/qcom/camss/camss.c
[ ... ]
> @@ -5576,6 +5590,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),
> +};
> +
[Severity: High]
Can this empty csiphy configuration lead to an out-of-bounds array access on
the csiphy array?
In camss_parse_endpoint_node(), the device tree port number is assigned
directly to the interface ID without bounds checking against
camss->res->csiphy_num:
csd->interface.csiphy_id = vep.base.port;
Since kaanapali_resources omits csiphy_num, it defaults to 0. This causes
the camss->csiphy array to be dynamically allocated as a ZERO_SIZE_PTR.
If a device tree specifies an endpoint (even port = <0>), it evaluates to an
out-of-bounds access when the async subdevice binds in
camss_subdev_notifier_bound():
u8 id = csd->interface.csiphy_id;
struct csiphy_device *csiphy = &camss->csiphy[id];
csiphy->cfg.csi2 = &csd->interface.csi2;
Could this cause a regression leading to a kernel panic if the driver
processes a device tree containing endpoints for this compatible?
[Severity: High]
Can omitting vfe_num here lead to a NULL pointer dereference during power
domain cleanup?
During probe failure or driver removal, camss_genpd_cleanup() handles power
domain cleanup:
if (camss->genpd_num == 1)
return;
...
dev_pm_domain_detach(camss->genpd, true);
If the driver is booted with a device tree lacking PM domains, genpd_num
could be 0. This means camss_genpd_cleanup() will not exit early.
If camss->genpd was never successfully attached (for example, due to having
zero VFEs or no PM domains configured), it remains NULL.
Because dev_pm_domain_detach() lacks a check for a NULL dev pointer before
dereferencing dev->pm_domain, could this unconditional call cause a regression
when cleaning up?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20261011-kaanapali-camss-v21-0-04fd28d815c6@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] 48+ messages in thread
* Re: [PATCH v21 06/14] media: qcom: camss: Add Kaanapali compatible
@ 2026-10-12 7:00 ` sashiko-bot
0 siblings, 0 replies; 48+ messages in thread
From: sashiko-bot @ 2026-10-12 7:00 UTC (permalink / raw)
To: Hangxiang Ma
Cc: neil.armstrong, robh, conor+dt, devicetree, olteanv, vkoul,
linux-phy, media-ci
Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [High] media: camss: missing DT port bounds check causes OOB array access on csiphy
- [High] media: camss: dev_pm_domain_detach() NULL pointer dereference on cleanup
--
commit 226a568dbea1991f8bda4c0b73de0c31f612545e
Author: Hangxiang Ma <hangxiang.ma@oss.qualcomm.com>
media: qcom: camss: Add Kaanapali compatible
Add CAMSS_KAANAPALI enum, Kaanapali compatible and Kaanapali CAMSS driver
private data. The private data currently includes only basic information.
Later changes will add CSIPHY, TPG, CSID and VFE resources.
> diff --git a/drivers/media/platform/qcom/camss/camss.c b/drivers/media/platform/qcom/camss/camss.c
> index c54185c93a8a9..fca3de214a922 100644
> --- a/drivers/media/platform/qcom/camss/camss.c
> +++ b/drivers/media/platform/qcom/camss/camss.c
[ ... ]
> @@ -5576,6 +5590,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),
> +};
> +
[Severity: High]
Can this empty csiphy configuration lead to an out-of-bounds array access on
the csiphy array?
In camss_parse_endpoint_node(), the device tree port number is assigned
directly to the interface ID without bounds checking against
camss->res->csiphy_num:
csd->interface.csiphy_id = vep.base.port;
Since kaanapali_resources omits csiphy_num, it defaults to 0. This causes
the camss->csiphy array to be dynamically allocated as a ZERO_SIZE_PTR.
If a device tree specifies an endpoint (even port = <0>), it evaluates to an
out-of-bounds access when the async subdevice binds in
camss_subdev_notifier_bound():
u8 id = csd->interface.csiphy_id;
struct csiphy_device *csiphy = &camss->csiphy[id];
csiphy->cfg.csi2 = &csd->interface.csi2;
Could this cause a regression leading to a kernel panic if the driver
processes a device tree containing endpoints for this compatible?
[Severity: High]
Can omitting vfe_num here lead to a NULL pointer dereference during power
domain cleanup?
During probe failure or driver removal, camss_genpd_cleanup() handles power
domain cleanup:
if (camss->genpd_num == 1)
return;
...
dev_pm_domain_detach(camss->genpd, true);
If the driver is booted with a device tree lacking PM domains, genpd_num
could be 0. This means camss_genpd_cleanup() will not exit early.
If camss->genpd was never successfully attached (for example, due to having
zero VFEs or no PM domains configured), it remains NULL.
Because dev_pm_domain_detach() lacks a check for a NULL dev pointer before
dereferencing dev->pm_domain, could this unconditional call cause a regression
when cleaning up?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20261011-kaanapali-camss-v21-0-04fd28d815c6@oss.qualcomm.com?part=6
^ permalink raw reply [flat|nested] 48+ messages in thread
* Re: [PATCH v21 09/14] media: qcom: camss: vfe: Add support for VFE 1080
2026-10-12 6:45 ` Hangxiang Ma
@ 2026-10-12 7:00 ` sashiko-bot
-1 siblings, 0 replies; 48+ messages in thread
From: sashiko-bot @ 2026-10-12 7:00 UTC (permalink / raw)
To: Hangxiang Ma
Cc: vkoul, olteanv, media-ci, linux-phy, conor+dt, robh, devicetree,
neil.armstrong
Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [High] media: camss: hardcoded AUP_UPDATE count violates hardware constraint
- [High] media: camss: data race on csid->aup_update and rup_update
--
commit bab5581422e8c33728a37abe32648420503fc60c
Author: Hangxiang Ma <hangxiang.ma@oss.qualcomm.com>
media: qcom: camss: vfe: Add support for VFE 1080
Add support for the VFE (Video Front End) 1080 found on Kaanapali SoC.
> 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.
[Severity: High]
Does the current implementation actually enforce this requirement?
If userspace queues 1 buffer via V4L2 and calls STREAMON, the vb2_queue
lacks a min_queued_buffers limit in msm_video_register(). Consequently,
vfe_enable_output_v2() dynamically queues only 1 buffer to the hardware,
but csid_configure_stream() in camss-csid-1080.c unconditionally issues
CAMSS_INIT_BUF_COUNT (2) AUP_UPDATE commands.
Can this mismatch lead to write master state corruption or IOMMU faults
due to hardware desynchronization?
> diff --git a/drivers/media/platform/qcom/camss/camss-vfe-1080.c b/drivers/media/platform/qcom/camss/camss-vfe-1080.c
> new file mode 100644
> index 0000000000000..016857cd10251
> --- /dev/null
> +++ b/drivers/media/platform/qcom/camss/camss-vfe-1080.c
[ ... ]
> +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);
> +}
[Severity: High]
Does this introduce a data race on csid->aup_update and rup_update?
This call reaches __csid_aup_update() in process context. While local
interrupts are disabled via vfe->output_lock, there is no cross-CPU
synchronization.
Concurrently, csid_isr() fires in hardirq context (potentially on another CPU)
and calls __csid_aup_rup_clear(), which performs a bitwise clear on the same
state variables without holding a shared lock:
csid->aup_update &= ~CSID_RUP_AUP_RDI(port_id);
csid->rup_update &= ~CSID_RUP_AUP_RDI(port_id);
Can these concurrent non-atomic bitwise operations cause lost updates
and corrupt the CSID_AUP_CMD and CSID_RUP_CMD register states, leading
to stream stalls or hardware misconfiguration?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20261011-kaanapali-camss-v21-0-04fd28d815c6@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] 48+ messages in thread
* Re: [PATCH v21 09/14] media: qcom: camss: vfe: Add support for VFE 1080
@ 2026-10-12 7:00 ` sashiko-bot
0 siblings, 0 replies; 48+ messages in thread
From: sashiko-bot @ 2026-10-12 7:00 UTC (permalink / raw)
To: Hangxiang Ma
Cc: vkoul, olteanv, media-ci, linux-phy, conor+dt, robh, devicetree,
neil.armstrong
Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [High] media: camss: hardcoded AUP_UPDATE count violates hardware constraint
- [High] media: camss: data race on csid->aup_update and rup_update
--
commit bab5581422e8c33728a37abe32648420503fc60c
Author: Hangxiang Ma <hangxiang.ma@oss.qualcomm.com>
media: qcom: camss: vfe: Add support for VFE 1080
Add support for the VFE (Video Front End) 1080 found on Kaanapali SoC.
> 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.
[Severity: High]
Does the current implementation actually enforce this requirement?
If userspace queues 1 buffer via V4L2 and calls STREAMON, the vb2_queue
lacks a min_queued_buffers limit in msm_video_register(). Consequently,
vfe_enable_output_v2() dynamically queues only 1 buffer to the hardware,
but csid_configure_stream() in camss-csid-1080.c unconditionally issues
CAMSS_INIT_BUF_COUNT (2) AUP_UPDATE commands.
Can this mismatch lead to write master state corruption or IOMMU faults
due to hardware desynchronization?
> diff --git a/drivers/media/platform/qcom/camss/camss-vfe-1080.c b/drivers/media/platform/qcom/camss/camss-vfe-1080.c
> new file mode 100644
> index 0000000000000..016857cd10251
> --- /dev/null
> +++ b/drivers/media/platform/qcom/camss/camss-vfe-1080.c
[ ... ]
> +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);
> +}
[Severity: High]
Does this introduce a data race on csid->aup_update and rup_update?
This call reaches __csid_aup_update() in process context. While local
interrupts are disabled via vfe->output_lock, there is no cross-CPU
synchronization.
Concurrently, csid_isr() fires in hardirq context (potentially on another CPU)
and calls __csid_aup_rup_clear(), which performs a bitwise clear on the same
state variables without holding a shared lock:
csid->aup_update &= ~CSID_RUP_AUP_RDI(port_id);
csid->rup_update &= ~CSID_RUP_AUP_RDI(port_id);
Can these concurrent non-atomic bitwise operations cause lost updates
and corrupt the CSID_AUP_CMD and CSID_RUP_CMD register states, leading
to stream stalls or hardware misconfiguration?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20261011-kaanapali-camss-v21-0-04fd28d815c6@oss.qualcomm.com?part=9
^ permalink raw reply [flat|nested] 48+ messages in thread
* Re: [PATCH v21 04/14] media: qcom: camss: Issue stream-on REG_UPDATE from CSID
2026-10-12 6:45 ` Hangxiang Ma
@ 2026-10-12 7:01 ` sashiko-bot
-1 siblings, 0 replies; 48+ messages in thread
From: sashiko-bot @ 2026-10-12 7:01 UTC (permalink / raw)
To: Hangxiang Ma
Cc: vkoul, neil.armstrong, linux-phy, robh, media-ci, devicetree,
olteanv, conor+dt
Thank you for your contribution! Sashiko AI review found 3 potential issue(s) to consider:
- [High] media: qcom: camss: lost initial buffer due to skipped REG_UPDATE
- [High] media: data race on csid->reg_update in stream-on
- [High] media: camss: cross-routing breaks due to hardcoded VFE ID in reg_update
--
commit cb036f0b44cb6248a2bce2553092074a74c00d9a
Author: Hangxiang Ma <hangxiang.ma@oss.qualcomm.com>
Subject: media: qcom: camss: Issue stream-on REG_UPDATE from CSID
This patch moves the stream-on REG_UPDATE from the VFE to the CSID for
CSID 680 and CSID Gen3 platforms. It skips the VFE-side REG_UPDATE when
the upstream CSID implements the reg_update callback.
> diff --git a/drivers/media/platform/qcom/camss/camss-csid-gen3.c b/drivers/media/platform/qcom/camss/camss-csid-gen3.c
> index 0fdbf75fb27db..830c9c818d3d2 100644
> --- a/drivers/media/platform/qcom/camss/camss-csid-gen3.c
> +++ b/drivers/media/platform/qcom/camss/camss-csid-gen3.c
[ ... ]
> @@ -230,6 +232,7 @@ static void csid_configure_stream(struct csid_device *csid, u8 enable)
> if (csid->phy.en_vc & BIT(i)) {
> __csid_configure_rdi_stream(csid, enable, i, 0);
> __csid_configure_rx(csid, &csid->phy, 0);
> + csid_subdev_reg_update(csid, i, false);
> __csid_ctrl_rdi(csid, enable, i);
> }
> }
[Severity: High]
Does this new process-context call expose csid->reg_update to a data race?
Looking at csid_subdev_reg_update(), it performs non-atomic
read-modify-write operations on the shared csid->reg_update mask:
if (clear) {
csid->reg_update &= ~CSID_RUP_AUP_RDI(port_id);
} else {
csid->reg_update |= CSID_RUP_AUP_RDI(port_id);
writel(csid->reg_update, csid->base + CSID_RUP_AUP_CMD);
}
Concurrently, when the hardware generates a RUP_DONE interrupt, the
hardirq handler csid_isr() calls this same function:
if (val & RUP_DONE_IRQ_STATUS)
csid_subdev_reg_update(csid, i, true);
Since csid_configure_stream() is called in process context without holding
a spinlock or disabling local interrupts, couldn't csid_isr() preempt it
midway through its read-modify-write? This could cause corruptions to the
mask, leading to lost or unintended hardware register updates, which might
cause streams to fail to start or stop.
> diff --git a/drivers/media/platform/qcom/camss/camss-vfe.c b/drivers/media/platform/qcom/camss/camss-vfe.c
> index 2680a9914765f..16a0b5663fe2b 100644
> --- a/drivers/media/platform/qcom/camss/camss-vfe.c
> +++ b/drivers/media/platform/qcom/camss/camss-vfe.c
[ ... ]
> @@ -552,7 +586,8 @@ 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 (!rup_in_csid)
> + ops->reg_update(vfe, line->id);
> }
[Severity: High]
Will skipping the reg_update here cause the first queued buffer address to
be permanently lost?
During stream initialization, this loop runs CAMSS_INIT_BUF_COUNT (2) times.
The vfe_wm_update() callback writes the buffer's address to a single hardware
shadow register (for example, VFE_BUS_IMAGE_ADDR). Previously, reg_update()
was called after each write to latch the shadow register into the active
hardware queue.
With this patch, if rup_in_csid is true, reg_update() is skipped inside the
loop. This means the second iteration will overwrite the first buffer's
address in the shadow register before it is ever latched.
When the CSID eventually issues the single REG_UPDATE at stream-on, only
the address of buf[1] will be latched. The hardware will then write the
first captured frame to buf[1], but the driver's completion handler
vfe_buf_done() expects buf[0] and will return that uninitialized buffer
to userspace, resulting in silent data corruption and shifted frames.
[Severity: High]
Does this logic also need to be applied to the runtime buffer completion
path to prevent cross-routing failures?
While this patch correctly identifies the active upstream CSID for the
stream-on phase by traversing the media graph, it appears the runtime
path still uses the hardcoded ID.
In vfe_buf_done(), when buffers complete, the driver unconditionally invokes:
ops->vfe_wm_update(vfe, output->wm_idx[0],
output->buf[index]->addr[0], line);
ops->reg_update(vfe, line->id);
On Gen3 and 680 platforms, this routes through vfe_reg_update() to
camss_reg_update() using the hardcoded vfe->id:
camss_reg_update(vfe->camss, vfe->id, port_id, false);
If a user configures a cross-routed media graph linking CSID N to VFE M
(where N is not equal to M), this hardcoded routing means the register
updates for new buffers are sent to the wrong CSID. This leaves the active
CSID's shadow registers unlatched and potentially corrupts the unrelated
CSID's state, causing streams to freeze.
--
Sashiko AI review · https://sashiko.dev/#/patchset/20261011-kaanapali-camss-v21-0-04fd28d815c6@oss.qualcomm.com?part=4
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply [flat|nested] 48+ messages in thread
* Re: [PATCH v21 04/14] media: qcom: camss: Issue stream-on REG_UPDATE from CSID
@ 2026-10-12 7:01 ` sashiko-bot
0 siblings, 0 replies; 48+ messages in thread
From: sashiko-bot @ 2026-10-12 7:01 UTC (permalink / raw)
To: Hangxiang Ma
Cc: vkoul, neil.armstrong, linux-phy, robh, media-ci, devicetree,
olteanv, conor+dt
Thank you for your contribution! Sashiko AI review found 3 potential issue(s) to consider:
- [High] media: qcom: camss: lost initial buffer due to skipped REG_UPDATE
- [High] media: data race on csid->reg_update in stream-on
- [High] media: camss: cross-routing breaks due to hardcoded VFE ID in reg_update
--
commit cb036f0b44cb6248a2bce2553092074a74c00d9a
Author: Hangxiang Ma <hangxiang.ma@oss.qualcomm.com>
Subject: media: qcom: camss: Issue stream-on REG_UPDATE from CSID
This patch moves the stream-on REG_UPDATE from the VFE to the CSID for
CSID 680 and CSID Gen3 platforms. It skips the VFE-side REG_UPDATE when
the upstream CSID implements the reg_update callback.
> diff --git a/drivers/media/platform/qcom/camss/camss-csid-gen3.c b/drivers/media/platform/qcom/camss/camss-csid-gen3.c
> index 0fdbf75fb27db..830c9c818d3d2 100644
> --- a/drivers/media/platform/qcom/camss/camss-csid-gen3.c
> +++ b/drivers/media/platform/qcom/camss/camss-csid-gen3.c
[ ... ]
> @@ -230,6 +232,7 @@ static void csid_configure_stream(struct csid_device *csid, u8 enable)
> if (csid->phy.en_vc & BIT(i)) {
> __csid_configure_rdi_stream(csid, enable, i, 0);
> __csid_configure_rx(csid, &csid->phy, 0);
> + csid_subdev_reg_update(csid, i, false);
> __csid_ctrl_rdi(csid, enable, i);
> }
> }
[Severity: High]
Does this new process-context call expose csid->reg_update to a data race?
Looking at csid_subdev_reg_update(), it performs non-atomic
read-modify-write operations on the shared csid->reg_update mask:
if (clear) {
csid->reg_update &= ~CSID_RUP_AUP_RDI(port_id);
} else {
csid->reg_update |= CSID_RUP_AUP_RDI(port_id);
writel(csid->reg_update, csid->base + CSID_RUP_AUP_CMD);
}
Concurrently, when the hardware generates a RUP_DONE interrupt, the
hardirq handler csid_isr() calls this same function:
if (val & RUP_DONE_IRQ_STATUS)
csid_subdev_reg_update(csid, i, true);
Since csid_configure_stream() is called in process context without holding
a spinlock or disabling local interrupts, couldn't csid_isr() preempt it
midway through its read-modify-write? This could cause corruptions to the
mask, leading to lost or unintended hardware register updates, which might
cause streams to fail to start or stop.
> diff --git a/drivers/media/platform/qcom/camss/camss-vfe.c b/drivers/media/platform/qcom/camss/camss-vfe.c
> index 2680a9914765f..16a0b5663fe2b 100644
> --- a/drivers/media/platform/qcom/camss/camss-vfe.c
> +++ b/drivers/media/platform/qcom/camss/camss-vfe.c
[ ... ]
> @@ -552,7 +586,8 @@ 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 (!rup_in_csid)
> + ops->reg_update(vfe, line->id);
> }
[Severity: High]
Will skipping the reg_update here cause the first queued buffer address to
be permanently lost?
During stream initialization, this loop runs CAMSS_INIT_BUF_COUNT (2) times.
The vfe_wm_update() callback writes the buffer's address to a single hardware
shadow register (for example, VFE_BUS_IMAGE_ADDR). Previously, reg_update()
was called after each write to latch the shadow register into the active
hardware queue.
With this patch, if rup_in_csid is true, reg_update() is skipped inside the
loop. This means the second iteration will overwrite the first buffer's
address in the shadow register before it is ever latched.
When the CSID eventually issues the single REG_UPDATE at stream-on, only
the address of buf[1] will be latched. The hardware will then write the
first captured frame to buf[1], but the driver's completion handler
vfe_buf_done() expects buf[0] and will return that uninitialized buffer
to userspace, resulting in silent data corruption and shifted frames.
[Severity: High]
Does this logic also need to be applied to the runtime buffer completion
path to prevent cross-routing failures?
While this patch correctly identifies the active upstream CSID for the
stream-on phase by traversing the media graph, it appears the runtime
path still uses the hardcoded ID.
In vfe_buf_done(), when buffers complete, the driver unconditionally invokes:
ops->vfe_wm_update(vfe, output->wm_idx[0],
output->buf[index]->addr[0], line);
ops->reg_update(vfe, line->id);
On Gen3 and 680 platforms, this routes through vfe_reg_update() to
camss_reg_update() using the hardcoded vfe->id:
camss_reg_update(vfe->camss, vfe->id, port_id, false);
If a user configures a cross-routed media graph linking CSID N to VFE M
(where N is not equal to M), this hardcoded routing means the register
updates for new buffers are sent to the wrong CSID. This leaves the active
CSID's shadow registers unlatched and potentially corrupts the unrelated
CSID's state, causing streams to freeze.
--
Sashiko AI review · https://sashiko.dev/#/patchset/20261011-kaanapali-camss-v21-0-04fd28d815c6@oss.qualcomm.com?part=4
^ permalink raw reply [flat|nested] 48+ messages in thread
* Re: [PATCH v21 10/14] media: qcom: camss: tpg: Add support for v2.4.0 TPG
2026-10-12 6:45 ` Hangxiang Ma
@ 2026-10-12 7:01 ` sashiko-bot
-1 siblings, 0 replies; 48+ messages in thread
From: sashiko-bot @ 2026-10-12 7:01 UTC (permalink / raw)
To: Hangxiang Ma
Cc: devicetree, vkoul, conor+dt, olteanv, media-ci, linux-phy, robh,
neil.armstrong
Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [Medium] media: qcom: camss: csid: incorrect fallback to physical PHY when TPG disabled
- [Medium] media: qcom: camss: uninitialized hw_version used in tpg_reset
--
commit 83c15a87930a3b292c2eeb9b034d6436828fd5de
Author: Hangxiang Ma <hangxiang.ma@oss.qualcomm.com>
media: qcom: camss: tpg: Add support for v2.4.0 TPG
Add support for the TPG found on Kaanapali. This TPG uses hardware
version 2.4.0, which drives test-enable and reset through the
TPG_CTRL_CMD register at offset 0x1f4 instead of the TEST_EN bit in
TPG_CTRL and the TPG_CLEAR register. Its output is routed into the
CSID 1080 RX through the CSI2 TPG mux, so the CSID selects the TPG as
the data source when a test pattern is selected.
> diff --git a/drivers/media/platform/qcom/camss/camss-csid-1080.c b/drivers/media/platform/qcom/camss/camss-csid-1080.c
> index 46e443e05195a..851b3cd712f52 100644
> --- a/drivers/media/platform/qcom/camss/camss-csid-1080.c
> +++ b/drivers/media/platform/qcom/camss/camss-csid-1080.c
[ ... ]
> @@ -148,8 +151,16 @@ static void __csid_configure_rx(struct csid_device *csid,
>
> val = (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;
> + }
> +
[Severity: Medium]
When csid->tpg_linked is true, csid_link_setup() has already overwritten
phy->csiphy_id with the tpg->id. If a user leaves the TPG in the default
disabled mode (testgen.mode == TPG_PAYLOAD_MODE_DISABLED), does this
fallback to the else branch mistakenly use the tpg->id as a physical
CSIPHY index?
This appears to misconfigure the hardware to route data from a physical
camera sensor that happens to share the same numeric ID as the requested
TPG, silently bypassing the TPG entirely.
> 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 d29de5f93c18e..cabbb2638cf38 100644
> --- a/drivers/media/platform/qcom/camss/camss-tpg-gen1.c
> +++ b/drivers/media/platform/qcom/camss/camss-tpg-gen1.c
[ ... ]
> @@ -164,18 +167,26 @@ 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);
> + if (tpg->hw_version < TPG_HW_VER_2_4_0)
> + writel(0, tpg->base + TPG_CTRL);
[Severity: Medium]
Is tpg->hw_version properly initialized when this function is called for
the first time? Looking at tpg_set_power() in camss-tpg.c, it invokes
the reset callback before hw_version is populated on power-on:
tpg_set_power()
...
tpg->res->hw_ops->reset(tpg);
tpg->res->hw_ops->hw_version(tpg);
Since the struct is dynamically allocated and zeroed, the first
tpg_reset() will evaluate tpg->hw_version as 0. This satisfies the
condition and incorrectly executes the legacy write to TPG_CTRL even on
newer v2.4.0 hardware.
> +
> + writel(TPG_CTRL_CMD_HW_RESET, tpg->base + TPG_CTRL_CMD);
>
> return 0;
> }
--
Sashiko AI review · https://sashiko.dev/#/patchset/20261011-kaanapali-camss-v21-0-04fd28d815c6@oss.qualcomm.com?part=10
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply [flat|nested] 48+ messages in thread
* Re: [PATCH v21 10/14] media: qcom: camss: tpg: Add support for v2.4.0 TPG
@ 2026-10-12 7:01 ` sashiko-bot
0 siblings, 0 replies; 48+ messages in thread
From: sashiko-bot @ 2026-10-12 7:01 UTC (permalink / raw)
To: Hangxiang Ma
Cc: devicetree, vkoul, conor+dt, olteanv, media-ci, linux-phy, robh,
neil.armstrong
Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [Medium] media: qcom: camss: csid: incorrect fallback to physical PHY when TPG disabled
- [Medium] media: qcom: camss: uninitialized hw_version used in tpg_reset
--
commit 83c15a87930a3b292c2eeb9b034d6436828fd5de
Author: Hangxiang Ma <hangxiang.ma@oss.qualcomm.com>
media: qcom: camss: tpg: Add support for v2.4.0 TPG
Add support for the TPG found on Kaanapali. This TPG uses hardware
version 2.4.0, which drives test-enable and reset through the
TPG_CTRL_CMD register at offset 0x1f4 instead of the TEST_EN bit in
TPG_CTRL and the TPG_CLEAR register. Its output is routed into the
CSID 1080 RX through the CSI2 TPG mux, so the CSID selects the TPG as
the data source when a test pattern is selected.
> diff --git a/drivers/media/platform/qcom/camss/camss-csid-1080.c b/drivers/media/platform/qcom/camss/camss-csid-1080.c
> index 46e443e05195a..851b3cd712f52 100644
> --- a/drivers/media/platform/qcom/camss/camss-csid-1080.c
> +++ b/drivers/media/platform/qcom/camss/camss-csid-1080.c
[ ... ]
> @@ -148,8 +151,16 @@ static void __csid_configure_rx(struct csid_device *csid,
>
> val = (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;
> + }
> +
[Severity: Medium]
When csid->tpg_linked is true, csid_link_setup() has already overwritten
phy->csiphy_id with the tpg->id. If a user leaves the TPG in the default
disabled mode (testgen.mode == TPG_PAYLOAD_MODE_DISABLED), does this
fallback to the else branch mistakenly use the tpg->id as a physical
CSIPHY index?
This appears to misconfigure the hardware to route data from a physical
camera sensor that happens to share the same numeric ID as the requested
TPG, silently bypassing the TPG entirely.
> 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 d29de5f93c18e..cabbb2638cf38 100644
> --- a/drivers/media/platform/qcom/camss/camss-tpg-gen1.c
> +++ b/drivers/media/platform/qcom/camss/camss-tpg-gen1.c
[ ... ]
> @@ -164,18 +167,26 @@ 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);
> + if (tpg->hw_version < TPG_HW_VER_2_4_0)
> + writel(0, tpg->base + TPG_CTRL);
[Severity: Medium]
Is tpg->hw_version properly initialized when this function is called for
the first time? Looking at tpg_set_power() in camss-tpg.c, it invokes
the reset callback before hw_version is populated on power-on:
tpg_set_power()
...
tpg->res->hw_ops->reset(tpg);
tpg->res->hw_ops->hw_version(tpg);
Since the struct is dynamically allocated and zeroed, the first
tpg_reset() will evaluate tpg->hw_version as 0. This satisfies the
condition and incorrectly executes the legacy write to TPG_CTRL even on
newer v2.4.0 hardware.
> +
> + writel(TPG_CTRL_CMD_HW_RESET, tpg->base + TPG_CTRL_CMD);
>
> return 0;
> }
--
Sashiko AI review · https://sashiko.dev/#/patchset/20261011-kaanapali-camss-v21-0-04fd28d815c6@oss.qualcomm.com?part=10
^ permalink raw reply [flat|nested] 48+ messages in thread
* Re: [PATCH v21 07/14] media: qcom: camss: csiphy: Add support for v2.4.0 two-phase CSIPHY
2026-10-12 6:45 ` Hangxiang Ma
@ 2026-10-12 7:07 ` sashiko-bot
-1 siblings, 0 replies; 48+ messages in thread
From: sashiko-bot @ 2026-10-12 7:07 UTC (permalink / raw)
To: Hangxiang Ma
Cc: robh, devicetree, media-ci, neil.armstrong, olteanv, vkoul,
linux-phy, conor+dt
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] media: qcom: camss: NULL pointer dereference on malformed DT in legacy PHY fallback
--
commit b51422793e63d50b9c2d85f3e71a49c0f3bb4e69
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, adds 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 fca3de214a922..eeceb79c1e863 100644
> --- a/drivers/media/platform/qcom/camss/camss.c
> +++ b/drivers/media/platform/qcom/camss/camss.c
> @@ -38,6 +38,51 @@
>
> static const struct parent_dev_ops vfe_parent_dev_ops;
>
> +static const struct camss_subdev_resources csiphy_res_kaanapali[] = {
> + /* CSIPHY0 */
> + {
> + .csiphy = {
> + .id = 0,
> + .formats = &csiphy_formats_sdm845
> + },
[Severity: High]
What happens when a malformed device tree causes the driver to fall back to
legacy PHY mode?
If camss_detect_legacy_phy() encounters missing or differently named remote
endpoints, it defaults to leaving camss->legacy_phy set to true.
When this happens on Kaanapali platforms, camss_init_subdevices() invokes the
legacy initialization path:
drivers/media/platform/qcom/camss/camss.c:camss_init_subdevices() {
...
} else {
ret = msm_csiphy_subdev_init_legacy(camss,
&camss->csiphy[i],
&res->csiphy_res[i],
...
}
This legacy path unconditionally dereferences the hw_ops pointer:
drivers/media/platform/qcom/camss/camss-csiphy.c:msm_csiphy_subdev_init_legacy() {
...
csiphy->res = &res->csiphy;
ret = csiphy->res->hw_ops->init(csiphy);
...
}
Since hw_ops is left uninitialized (NULL) in the Kaanapali definitions, could
this result in a kernel panic during driver probe?
> + },
[ ... ]
--
Sashiko AI review · https://sashiko.dev/#/patchset/20261011-kaanapali-camss-v21-0-04fd28d815c6@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] 48+ messages in thread
* Re: [PATCH v21 07/14] media: qcom: camss: csiphy: Add support for v2.4.0 two-phase CSIPHY
@ 2026-10-12 7:07 ` sashiko-bot
0 siblings, 0 replies; 48+ messages in thread
From: sashiko-bot @ 2026-10-12 7:07 UTC (permalink / raw)
To: Hangxiang Ma
Cc: robh, devicetree, media-ci, neil.armstrong, olteanv, vkoul,
linux-phy, conor+dt
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] media: qcom: camss: NULL pointer dereference on malformed DT in legacy PHY fallback
--
commit b51422793e63d50b9c2d85f3e71a49c0f3bb4e69
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, adds 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 fca3de214a922..eeceb79c1e863 100644
> --- a/drivers/media/platform/qcom/camss/camss.c
> +++ b/drivers/media/platform/qcom/camss/camss.c
> @@ -38,6 +38,51 @@
>
> static const struct parent_dev_ops vfe_parent_dev_ops;
>
> +static const struct camss_subdev_resources csiphy_res_kaanapali[] = {
> + /* CSIPHY0 */
> + {
> + .csiphy = {
> + .id = 0,
> + .formats = &csiphy_formats_sdm845
> + },
[Severity: High]
What happens when a malformed device tree causes the driver to fall back to
legacy PHY mode?
If camss_detect_legacy_phy() encounters missing or differently named remote
endpoints, it defaults to leaving camss->legacy_phy set to true.
When this happens on Kaanapali platforms, camss_init_subdevices() invokes the
legacy initialization path:
drivers/media/platform/qcom/camss/camss.c:camss_init_subdevices() {
...
} else {
ret = msm_csiphy_subdev_init_legacy(camss,
&camss->csiphy[i],
&res->csiphy_res[i],
...
}
This legacy path unconditionally dereferences the hw_ops pointer:
drivers/media/platform/qcom/camss/camss-csiphy.c:msm_csiphy_subdev_init_legacy() {
...
csiphy->res = &res->csiphy;
ret = csiphy->res->hw_ops->init(csiphy);
...
}
Since hw_ops is left uninitialized (NULL) in the Kaanapali definitions, could
this result in a kernel panic during driver probe?
> + },
[ ... ]
--
Sashiko AI review · https://sashiko.dev/#/patchset/20261011-kaanapali-camss-v21-0-04fd28d815c6@oss.qualcomm.com?part=7
^ permalink raw reply [flat|nested] 48+ messages in thread
* Re: [PATCH v21 04/14] media: qcom: camss: Issue stream-on REG_UPDATE from CSID
2026-10-12 7:01 ` sashiko-bot
@ 2026-10-12 7:20 ` Hangxiang Ma
-1 siblings, 0 replies; 48+ messages in thread
From: Hangxiang Ma @ 2026-10-12 7:20 UTC (permalink / raw)
To: sashiko-reviews
Cc: vkoul, neil.armstrong, linux-phy, robh, media-ci, devicetree,
olteanv, conor+dt
On 10/12/2026 3:01 PM, sashiko-bot@kernel.org wrote:
> Thank you for your contribution! Sashiko AI review found 3 potential issue(s) to consider:
> - [High] media: qcom: camss: lost initial buffer due to skipped REG_UPDATE
> - [High] media: data race on csid->reg_update in stream-on
> - [High] media: camss: cross-routing breaks due to hardcoded VFE ID in reg_update
> --
>
> commit cb036f0b44cb6248a2bce2553092074a74c00d9a
> Author: Hangxiang Ma <hangxiang.ma@oss.qualcomm.com>
> Subject: media: qcom: camss: Issue stream-on REG_UPDATE from CSID
>
> This patch moves the stream-on REG_UPDATE from the VFE to the CSID for
> CSID 680 and CSID Gen3 platforms. It skips the VFE-side REG_UPDATE when
> the upstream CSID implements the reg_update callback.
>
>> diff --git a/drivers/media/platform/qcom/camss/camss-csid-gen3.c b/drivers/media/platform/qcom/camss/camss-csid-gen3.c
>> index 0fdbf75fb27db..830c9c818d3d2 100644
>> --- a/drivers/media/platform/qcom/camss/camss-csid-gen3.c
>> +++ b/drivers/media/platform/qcom/camss/camss-csid-gen3.c
>
> [ ... ]
>
>> @@ -230,6 +232,7 @@ static void csid_configure_stream(struct csid_device *csid, u8 enable)
>> if (csid->phy.en_vc & BIT(i)) {
>> __csid_configure_rdi_stream(csid, enable, i, 0);
>> __csid_configure_rx(csid, &csid->phy, 0);
>> + csid_subdev_reg_update(csid, i, false);
>> __csid_ctrl_rdi(csid, enable, i);
>> }
>> }
>
> [Severity: High]
> Does this new process-context call expose csid->reg_update to a data race?
>
> Looking at csid_subdev_reg_update(), it performs non-atomic
> read-modify-write operations on the shared csid->reg_update mask:
>
> if (clear) {
> csid->reg_update &= ~CSID_RUP_AUP_RDI(port_id);
> } else {
> csid->reg_update |= CSID_RUP_AUP_RDI(port_id);
> writel(csid->reg_update, csid->base + CSID_RUP_AUP_CMD);
> }
>
> Concurrently, when the hardware generates a RUP_DONE interrupt, the
> hardirq handler csid_isr() calls this same function:
>
> if (val & RUP_DONE_IRQ_STATUS)
> csid_subdev_reg_update(csid, i, true);
>
> Since csid_configure_stream() is called in process context without holding
> a spinlock or disabling local interrupts, couldn't csid_isr() preempt it
> midway through its read-modify-write? This could cause corruptions to the
> mask, leading to lost or unintended hardware register updates, which might
> cause streams to fail to start or stop.
>
I agree but this should relate to CAMSS framework design and now it
seems the CAMSS hasn't taken this into consideration. Future framework
upgrade will cover that but KNP series will still focus on enablement.
>> diff --git a/drivers/media/platform/qcom/camss/camss-vfe.c b/drivers/media/platform/qcom/camss/camss-vfe.c
>> index 2680a9914765f..16a0b5663fe2b 100644
>> --- a/drivers/media/platform/qcom/camss/camss-vfe.c
>> +++ b/drivers/media/platform/qcom/camss/camss-vfe.c
>
> [ ... ]
>
>> @@ -552,7 +586,8 @@ 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 (!rup_in_csid)
>> + ops->reg_update(vfe, line->id);
>> }
>
> [Severity: High]
> Will skipping the reg_update here cause the first queued buffer address to
> be permanently lost?
>
> During stream initialization, this loop runs CAMSS_INIT_BUF_COUNT (2) times.
> The vfe_wm_update() callback writes the buffer's address to a single hardware
> shadow register (for example, VFE_BUS_IMAGE_ADDR). Previously, reg_update()
> was called after each write to latch the shadow register into the active
> hardware queue.
>
> With this patch, if rup_in_csid is true, reg_update() is skipped inside the
> loop. This means the second iteration will overwrite the first buffer's
> address in the shadow register before it is ever latched.
>
> When the CSID eventually issues the single REG_UPDATE at stream-on, only
> the address of buf[1] will be latched. The hardware will then write the
> first captured frame to buf[1], but the driver's completion handler
> vfe_buf_done() expects buf[0] and will return that uninitialized buffer
> to userspace, resulting in silent data corruption and shifted frames.
>
No. We have tested on specific hardware like 680 and 1080 and no issue
is found. Actually, this is a recommended initialization sequence since
CSID 680. However, on Kaanapali platform, the requirement for sequence
order becomes strict and we have to follow that guidance. The reg_update
is split into two parts since 1080, rup_update and aup_update. The
CAMSS_INIT_BUF_COUNT should only impact the hardware starts from 1080
version. The previous generation won't be influenced.
> [Severity: High]
> Does this logic also need to be applied to the runtime buffer completion
> path to prevent cross-routing failures?
>
> While this patch correctly identifies the active upstream CSID for the
> stream-on phase by traversing the media graph, it appears the runtime
> path still uses the hardcoded ID.
>
> In vfe_buf_done(), when buffers complete, the driver unconditionally invokes:
>
> ops->vfe_wm_update(vfe, output->wm_idx[0],
> output->buf[index]->addr[0], line);
> ops->reg_update(vfe, line->id);
>
> On Gen3 and 680 platforms, this routes through vfe_reg_update() to
> camss_reg_update() using the hardcoded vfe->id:
>
> camss_reg_update(vfe->camss, vfe->id, port_id, false);
>
> If a user configures a cross-routed media graph linking CSID N to VFE M
> (where N is not equal to M), this hardcoded routing means the register
> updates for new buffers are sent to the wrong CSID. This leaves the active
> CSID's shadow registers unlatched and potentially corrupts the unrelated
> CSID's state, causing streams to freeze.
>
This should be one-one mapping for CSID and VFE. We have moved the
REG_UPDATE from VFE to CSID since 680 and the BUF_DONE event can be
found though CSID id. These two evidence from hardware can prove this
intentional one-one mapping design.
---
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] 48+ messages in thread
* Re: [PATCH v21 04/14] media: qcom: camss: Issue stream-on REG_UPDATE from CSID
@ 2026-10-12 7:20 ` Hangxiang Ma
0 siblings, 0 replies; 48+ messages in thread
From: Hangxiang Ma @ 2026-10-12 7:20 UTC (permalink / raw)
To: sashiko-reviews
Cc: vkoul, neil.armstrong, linux-phy, robh, media-ci, devicetree,
olteanv, conor+dt
On 10/12/2026 3:01 PM, sashiko-bot@kernel.org wrote:
> Thank you for your contribution! Sashiko AI review found 3 potential issue(s) to consider:
> - [High] media: qcom: camss: lost initial buffer due to skipped REG_UPDATE
> - [High] media: data race on csid->reg_update in stream-on
> - [High] media: camss: cross-routing breaks due to hardcoded VFE ID in reg_update
> --
>
> commit cb036f0b44cb6248a2bce2553092074a74c00d9a
> Author: Hangxiang Ma <hangxiang.ma@oss.qualcomm.com>
> Subject: media: qcom: camss: Issue stream-on REG_UPDATE from CSID
>
> This patch moves the stream-on REG_UPDATE from the VFE to the CSID for
> CSID 680 and CSID Gen3 platforms. It skips the VFE-side REG_UPDATE when
> the upstream CSID implements the reg_update callback.
>
>> diff --git a/drivers/media/platform/qcom/camss/camss-csid-gen3.c b/drivers/media/platform/qcom/camss/camss-csid-gen3.c
>> index 0fdbf75fb27db..830c9c818d3d2 100644
>> --- a/drivers/media/platform/qcom/camss/camss-csid-gen3.c
>> +++ b/drivers/media/platform/qcom/camss/camss-csid-gen3.c
>
> [ ... ]
>
>> @@ -230,6 +232,7 @@ static void csid_configure_stream(struct csid_device *csid, u8 enable)
>> if (csid->phy.en_vc & BIT(i)) {
>> __csid_configure_rdi_stream(csid, enable, i, 0);
>> __csid_configure_rx(csid, &csid->phy, 0);
>> + csid_subdev_reg_update(csid, i, false);
>> __csid_ctrl_rdi(csid, enable, i);
>> }
>> }
>
> [Severity: High]
> Does this new process-context call expose csid->reg_update to a data race?
>
> Looking at csid_subdev_reg_update(), it performs non-atomic
> read-modify-write operations on the shared csid->reg_update mask:
>
> if (clear) {
> csid->reg_update &= ~CSID_RUP_AUP_RDI(port_id);
> } else {
> csid->reg_update |= CSID_RUP_AUP_RDI(port_id);
> writel(csid->reg_update, csid->base + CSID_RUP_AUP_CMD);
> }
>
> Concurrently, when the hardware generates a RUP_DONE interrupt, the
> hardirq handler csid_isr() calls this same function:
>
> if (val & RUP_DONE_IRQ_STATUS)
> csid_subdev_reg_update(csid, i, true);
>
> Since csid_configure_stream() is called in process context without holding
> a spinlock or disabling local interrupts, couldn't csid_isr() preempt it
> midway through its read-modify-write? This could cause corruptions to the
> mask, leading to lost or unintended hardware register updates, which might
> cause streams to fail to start or stop.
>
I agree but this should relate to CAMSS framework design and now it
seems the CAMSS hasn't taken this into consideration. Future framework
upgrade will cover that but KNP series will still focus on enablement.
>> diff --git a/drivers/media/platform/qcom/camss/camss-vfe.c b/drivers/media/platform/qcom/camss/camss-vfe.c
>> index 2680a9914765f..16a0b5663fe2b 100644
>> --- a/drivers/media/platform/qcom/camss/camss-vfe.c
>> +++ b/drivers/media/platform/qcom/camss/camss-vfe.c
>
> [ ... ]
>
>> @@ -552,7 +586,8 @@ 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 (!rup_in_csid)
>> + ops->reg_update(vfe, line->id);
>> }
>
> [Severity: High]
> Will skipping the reg_update here cause the first queued buffer address to
> be permanently lost?
>
> During stream initialization, this loop runs CAMSS_INIT_BUF_COUNT (2) times.
> The vfe_wm_update() callback writes the buffer's address to a single hardware
> shadow register (for example, VFE_BUS_IMAGE_ADDR). Previously, reg_update()
> was called after each write to latch the shadow register into the active
> hardware queue.
>
> With this patch, if rup_in_csid is true, reg_update() is skipped inside the
> loop. This means the second iteration will overwrite the first buffer's
> address in the shadow register before it is ever latched.
>
> When the CSID eventually issues the single REG_UPDATE at stream-on, only
> the address of buf[1] will be latched. The hardware will then write the
> first captured frame to buf[1], but the driver's completion handler
> vfe_buf_done() expects buf[0] and will return that uninitialized buffer
> to userspace, resulting in silent data corruption and shifted frames.
>
No. We have tested on specific hardware like 680 and 1080 and no issue
is found. Actually, this is a recommended initialization sequence since
CSID 680. However, on Kaanapali platform, the requirement for sequence
order becomes strict and we have to follow that guidance. The reg_update
is split into two parts since 1080, rup_update and aup_update. The
CAMSS_INIT_BUF_COUNT should only impact the hardware starts from 1080
version. The previous generation won't be influenced.
> [Severity: High]
> Does this logic also need to be applied to the runtime buffer completion
> path to prevent cross-routing failures?
>
> While this patch correctly identifies the active upstream CSID for the
> stream-on phase by traversing the media graph, it appears the runtime
> path still uses the hardcoded ID.
>
> In vfe_buf_done(), when buffers complete, the driver unconditionally invokes:
>
> ops->vfe_wm_update(vfe, output->wm_idx[0],
> output->buf[index]->addr[0], line);
> ops->reg_update(vfe, line->id);
>
> On Gen3 and 680 platforms, this routes through vfe_reg_update() to
> camss_reg_update() using the hardcoded vfe->id:
>
> camss_reg_update(vfe->camss, vfe->id, port_id, false);
>
> If a user configures a cross-routed media graph linking CSID N to VFE M
> (where N is not equal to M), this hardcoded routing means the register
> updates for new buffers are sent to the wrong CSID. This leaves the active
> CSID's shadow registers unlatched and potentially corrupts the unrelated
> CSID's state, causing streams to freeze.
>
This should be one-one mapping for CSID and VFE. We have moved the
REG_UPDATE from VFE to CSID since 680 and the BUF_DONE event can be
found though CSID id. These two evidence from hardware can prove this
intentional one-one mapping design.
---
Best Regards,
Hangxiang
^ permalink raw reply [flat|nested] 48+ messages in thread
end of thread, other threads:[~2026-10-12 7:20 UTC | newest]
Thread overview: 48+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2026-10-12 6:45 [PATCH v21 00/14] media: qcom: camss: Add Kaanapali support Hangxiang Ma
2026-10-12 6:45 ` Hangxiang Ma
2026-10-12 6:45 ` [PATCH v21 01/14] dt-bindings: phy: qcom,x1e80100-csi2-phy: Add Kaanapali CSI2 PHY Hangxiang Ma
2026-10-12 6:45 ` Hangxiang Ma
2026-10-12 6:45 ` [PATCH v21 02/14] phy: qcom-mipi-csi2: Parametrise the common status register offset Hangxiang Ma
2026-10-12 6:45 ` Hangxiang Ma
2026-10-12 6:45 ` [PATCH v21 03/14] phy: qcom-mipi-csi2: Add Kaanapali support Hangxiang Ma
2026-10-12 6:45 ` Hangxiang Ma
2026-10-12 6:45 ` [PATCH v21 04/14] media: qcom: camss: Issue stream-on REG_UPDATE from CSID Hangxiang Ma
2026-10-12 6:45 ` Hangxiang Ma
2026-10-12 7:01 ` sashiko-bot
2026-10-12 7:01 ` sashiko-bot
2026-10-12 7:20 ` Hangxiang Ma
2026-10-12 7:20 ` Hangxiang Ma
2026-10-12 6:45 ` [PATCH v21 05/14] media: dt-bindings: Add CAMSS device for Kaanapali Hangxiang Ma
2026-10-12 6:45 ` Hangxiang Ma
2026-10-12 6:45 ` [PATCH v21 06/14] media: qcom: camss: Add Kaanapali compatible Hangxiang Ma
2026-10-12 6:45 ` Hangxiang Ma
2026-10-12 7:00 ` sashiko-bot
2026-10-12 7:00 ` sashiko-bot
2026-10-12 6:45 ` [PATCH v21 07/14] media: qcom: camss: csiphy: Add support for v2.4.0 two-phase CSIPHY Hangxiang Ma
2026-10-12 6:45 ` Hangxiang Ma
2026-10-12 7:07 ` sashiko-bot
2026-10-12 7:07 ` sashiko-bot
2026-10-12 6:45 ` [PATCH v21 08/14] media: qcom: camss: csid: Add support for CSID 1080 Hangxiang Ma
2026-10-12 6:45 ` Hangxiang Ma
2026-10-12 6:59 ` sashiko-bot
2026-10-12 6:59 ` sashiko-bot
2026-10-12 6:45 ` [PATCH v21 09/14] media: qcom: camss: vfe: Add support for VFE 1080 Hangxiang Ma
2026-10-12 6:45 ` Hangxiang Ma
2026-10-12 7:00 ` sashiko-bot
2026-10-12 7:00 ` sashiko-bot
2026-10-12 6:45 ` [PATCH v21 10/14] media: qcom: camss: tpg: Add support for v2.4.0 TPG Hangxiang Ma
2026-10-12 6:45 ` Hangxiang Ma
2026-10-12 7:01 ` sashiko-bot
2026-10-12 7:01 ` sashiko-bot
2026-10-12 6:45 ` [PATCH v21 11/14] arm64: dts: qcom: kaanapali: Add CAMSS and CSIPHY block definitions Hangxiang Ma
2026-10-12 6:45 ` Hangxiang Ma
2026-10-12 6:45 ` [PATCH v21 12/14] arm64: dts: qcom: kaanapali: Add CCI controller nodes Hangxiang Ma
2026-10-12 6:45 ` Hangxiang Ma
2026-10-12 6:45 ` [PATCH v21 13/14] arm64: dts: qcom: kaanapali: Add camera MCLK pinctrl Hangxiang Ma
2026-10-12 6:45 ` Hangxiang Ma
2026-10-12 6:45 ` [PATCH v21 14/14] arm64: dts: qcom: kaanapali-mtp-camera-s5kjn5: Add DT overlay Hangxiang Ma
2026-10-12 6:45 ` Hangxiang Ma
2026-10-12 6:57 ` sashiko-bot
2026-10-12 6:57 ` sashiko-bot
2026-10-12 6:59 ` Hangxiang Ma
2026-10-12 6:59 ` 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.