* [PATCH v9 0/5] media: qcom: camss: Add Kaanapali support
@ 2025-12-08 12:39 Hangxiang Ma
2025-12-08 12:39 ` [PATCH v9 1/5] media: dt-bindings: Add CAMSS device for Kaanapali Hangxiang Ma
` (4 more replies)
0 siblings, 5 replies; 17+ messages in thread
From: Hangxiang Ma @ 2025-12-08 12:39 UTC (permalink / raw)
To: Loic Poulain, Robert Foss, Andi Shyti, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Todor Tomov,
Vladimir Zapolskiy, Mauro Carvalho Chehab, Bryan O'Donoghue
Cc: linux-arm-msm, devicetree, linux-kernel, linux-media,
Hangxiang Ma, Krzysztof Kozlowski, Atiya Kailany
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:
- 3 x VFE, 5 RDI per VFE
- 2 x VFE Lite, 4 RDI per VFE Lite
- 3 x CSID
- 2 x CSID Lite
- 6 x CSI PHY
- 2 x ICP
- 1 x IPE
- 2 x JPEG DMA & Downscaler
- 2 x JPEG Encoder
- 1 x OFE
- 5 x RT CDM
- 3 x TPG
This series has been tested using the following commands with a
downstream driver for S5KJN5 sensor.
- media-ctl --reset
- media-ctl -V '"msm_csiphy2":0[fmt:SGBRG10/4096x3072]'
- media-ctl -V '"msm_csid0":0[fmt:SGBRG10/4096x3072]'
- media-ctl -V '"msm_vfe0_rdi0":0[fmt:SGBRG10/4096x3072]'
- media-ctl -l '"msm_csiphy2":1->"msm_csid0":0[1]'
- media-ctl -l '"msm_csid0":1->"msm_vfe0_rdi0":0[1]'
- yavta --capture=20 -I -n 5 -f SGBRG10P -s 4096x3072 -F /dev/video0
Dependencies:
- https://lore.kernel.org/all/20251014-use-marco-to-denote-image-buffer-number-v1-1-f782e4cc622d@oss.qualcomm.com/
- https://lore.kernel.org/all/20251014-add-new-clock-in-vfe-matching-list-v1-1-0d965ccc8a3a@oss.qualcomm.com/
- https://lore.kernel.org/all/20251023-make-csiphy-status-macro-cross-platform-v1-1-5746446dfdc6@oss.qualcomm.com/
Signed-off-by: Hangxiang Ma <hangxiang.ma@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 (5):
media: dt-bindings: Add CAMSS device for Kaanapali
media: qcom: camss: Add Kaanapali compatible camss driver
media: qcom: camss: csiphy: Add support for v2.4.0 two-phase CSIPHY
media: qcom: camss: csid: Add support for CSID gen4
media: qcom: camss: vfe: Add support for VFE gen4
.../bindings/media/qcom,kaanapali-camss.yaml | 646 +++++++++++++++++++++
drivers/media/platform/qcom/camss/Makefile | 4 +-
drivers/media/platform/qcom/camss/camss-csid-680.c | 1 -
.../media/platform/qcom/camss/camss-csid-gen3.c | 1 -
.../media/platform/qcom/camss/camss-csid-gen4.c | 376 ++++++++++++
drivers/media/platform/qcom/camss/camss-csid.h | 11 +-
.../platform/qcom/camss/camss-csiphy-3ph-1-0.c | 124 ++++
drivers/media/platform/qcom/camss/camss-vfe-gen4.c | 197 +++++++
drivers/media/platform/qcom/camss/camss-vfe.c | 9 +-
drivers/media/platform/qcom/camss/camss-vfe.h | 2 +
drivers/media/platform/qcom/camss/camss.c | 352 +++++++++++
drivers/media/platform/qcom/camss/camss.h | 1 +
12 files changed, 1718 insertions(+), 6 deletions(-)
---
base-commit: b09b832c719df5e10f2560771fd38146f2b3fd7c
change-id: 20251008-add-support-for-camss-on-kaanapali-e5b6dbd5209e
prerequisite-change-id: 20251012-use-marco-to-denote-image-buffer-number-cbec071b8436:v1
prerequisite-patch-id: 3ac5d6703a9530eda884720c146b9444f90cf56b
prerequisite-change-id: 20251012-add-new-clock-in-vfe-matching-list-25fb1e378c49:v1
prerequisite-patch-id: aacb03b359fdf95977805f42918c0b6c39889e32
prerequisite-message-id: <20251130-make-csiphy-status-macro-cross-platform-v1-1-334664c6cf70@oss.qualcomm.com>
prerequisite-patch-id: 27c2ef96f0e747ec6b4bcf316d8802356e4cc3f4
Best regards,
--
Hangxiang Ma <hangxiang.ma@oss.qualcomm.com>
^ permalink raw reply [flat|nested] 17+ messages in thread
* [PATCH v9 1/5] media: dt-bindings: Add CAMSS device for Kaanapali
2025-12-08 12:39 [PATCH v9 0/5] media: qcom: camss: Add Kaanapali support Hangxiang Ma
@ 2025-12-08 12:39 ` Hangxiang Ma
2025-12-08 19:53 ` Dmitry Baryshkov
2025-12-08 12:39 ` [PATCH v9 2/5] media: qcom: camss: Add Kaanapali compatible camss driver Hangxiang Ma
` (3 subsequent siblings)
4 siblings, 1 reply; 17+ messages in thread
From: Hangxiang Ma @ 2025-12-08 12:39 UTC (permalink / raw)
To: Loic Poulain, Robert Foss, Andi Shyti, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Todor Tomov,
Vladimir Zapolskiy, Mauro Carvalho Chehab, Bryan O'Donoghue
Cc: linux-arm-msm, devicetree, linux-kernel, linux-media,
Hangxiang Ma, Krzysztof Kozlowski
Add bindings for qcom,kaanapali-camss to support the Camera Subsystem
(CAMSS) on the Qualcomm Kaanapali platform.
The Kaanapali platform provides:
- 3 x VFE, 5 RDI per VFE
- 2 x VFE Lite, 4 RDI per VFE Lite
- 3 x CSID
- 2 x CSID Lite
- 6 x CSIPHY
- 2 x ICP
- 1 x IPE
- 2 x JPEG DMA & Downscaler
- 2 x JPEG Encoder
- 1 x OFE
- 5 x RT CDM
- 3 x TPG
Reviewed-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
Reviewed-by: Krzysztof Kozlowski <krzk@kernel.org>
Signed-off-by: Hangxiang Ma <hangxiang.ma@oss.qualcomm.com>
---
.../bindings/media/qcom,kaanapali-camss.yaml | 646 +++++++++++++++++++++
1 file changed, 646 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..3b54620e14c6
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/qcom,kaanapali-camss.yaml
@@ -0,0 +1,646 @@
+# 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:
+ Kaanapali camera subsystem includes submodules such as CSIPHY (CSI Physical layer)
+ and CSID (CSI Decoder), which comply with the MIPI CSI2 protocol.
+
+ The subsystem also integrates a set of real-time image processing engines and their
+ associated configuration modules, as well as non-real-time engines.
+
+ Additionally, it encompasses a test pattern generator (TPG) submodule.
+
+properties:
+ compatible:
+ const: qcom,kaanapali-camss
+
+ reg:
+ items:
+ - description: Registers for CSID 0
+ - description: Registers for CSID 1
+ - description: Registers for CSID 2
+ - description: Registers for CSID Lite 0
+ - description: Registers for CSID Lite 1
+ - description: Registers for CSIPHY 0
+ - description: Registers for CSIPHY 1
+ - description: Registers for CSIPHY 2
+ - description: Registers for CSIPHY 3
+ - description: Registers for CSIPHY 4
+ - description: Registers for CSIPHY 5
+ - description: Registers for VFE (Video Front End) 0
+ - description: Registers for VFE 1
+ - description: Registers for VFE 2
+ - description: Registers for VFE Lite 0
+ - description: Registers for VFE Lite 1
+ - description: Registers for ICP (Imaging Control Processor) 0
+ - description: Registers for ICP 0 SYS
+ - description: Registers for ICP 1
+ - description: Registers for ICP 1 SYS
+ - description: Registers for IPE (Image Processing Engine)
+ - description: Registers for JPEG DMA & Downscaler
+ - description: Registers for JPEG Encoder
+ - description: Registers for OFE (Offline Front End)
+ - description: Registers for RT CDM (Camera Data Mover) 0
+ - description: Registers for RT CDM 1
+ - description: Registers for RT CDM 2
+ - description: Registers for RT CDM 3
+ - description: Registers for RT CDM 4
+ - description: Registers for TPG 0
+ - description: Registers for TPG 1
+ - description: Registers for TPG 2
+
+ reg-names:
+ items:
+ - const: csid0
+ - const: csid1
+ - const: csid2
+ - const: csid_lite0
+ - const: csid_lite1
+ - const: csiphy0
+ - const: csiphy1
+ - const: csiphy2
+ - const: csiphy3
+ - const: csiphy4
+ - const: csiphy5
+ - const: vfe0
+ - const: vfe1
+ - const: vfe2
+ - const: vfe_lite0
+ - const: vfe_lite1
+ - const: icp0
+ - const: icp0_sys
+ - const: icp1
+ - const: icp1_sys
+ - const: ipe
+ - const: jpeg_dma
+ - const: jpeg_enc
+ - const: ofe
+ - const: rt_cdm0
+ - const: rt_cdm1
+ - const: rt_cdm2
+ - const: rt_cdm3
+ - const: rt_cdm4
+ - const: tpg0
+ - const: tpg1
+ - const: tpg2
+
+ clocks:
+ maxItems: 60
+
+ clock-names:
+ items:
+ - const: camnoc_nrt_axi
+ - const: camnoc_rt_axi
+ - const: camnoc_rt_vfe0
+ - const: camnoc_rt_vfe1
+ - const: camnoc_rt_vfe2
+ - const: camnoc_rt_vfe_lite
+ - const: cpas_ahb
+ - const: cpas_fast_ahb
+ - const: csid
+ - const: csid_csiphy_rx
+ - const: csiphy0
+ - const: csiphy0_timer
+ - const: csiphy1
+ - const: csiphy1_timer
+ - const: csiphy2
+ - const: csiphy2_timer
+ - const: csiphy3
+ - const: csiphy3_timer
+ - const: csiphy4
+ - const: csiphy4_timer
+ - const: csiphy5
+ - const: csiphy5_timer
+ - const: gcc_axi_hf
+ - 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
+ - const: camnoc_ipe_nps
+ - const: camnoc_ofe
+ - const: gcc_axi_sf
+ - const: icp0
+ - const: icp0_ahb
+ - const: icp1
+ - const: icp1_ahb
+ - const: ipe_nps
+ - const: ipe_nps_ahb
+ - const: ipe_nps_fast_ahb
+ - const: ipe_pps
+ - const: ipe_pps_fast_ahb
+ - const: jpeg
+ - const: ofe_ahb
+ - const: ofe_anchor
+ - const: ofe_anchor_fast_ahb
+ - const: ofe_hdr
+ - const: ofe_hdr_fast_ahb
+ - const: ofe_main
+ - const: ofe_main_fast_ahb
+ - const: vfe0_bayer
+ - const: vfe0_bayer_fast_ahb
+ - const: vfe1_bayer
+ - const: vfe1_bayer_fast_ahb
+ - const: vfe2_bayer
+ - const: vfe2_bayer_fast_ahb
+
+ interrupts:
+ maxItems: 30
+
+ interrupt-names:
+ items:
+ - const: csid0
+ - const: csid1
+ - const: csid2
+ - const: csid_lite0
+ - const: csid_lite1
+ - const: csiphy0
+ - const: csiphy1
+ - const: csiphy2
+ - const: csiphy3
+ - const: csiphy4
+ - const: csiphy5
+ - const: vfe0
+ - const: vfe1
+ - const: vfe2
+ - const: vfe_lite0
+ - const: vfe_lite1
+ - const: camnoc_nrt
+ - const: camnoc_rt
+ - const: icp0
+ - const: icp1
+ - const: jpeg_dma
+ - const: jpeg_enc
+ - const: rt_cdm0
+ - const: rt_cdm1
+ - const: rt_cdm2
+ - const: rt_cdm3
+ - const: rt_cdm4
+ - const: tpg0
+ - const: tpg1
+ - const: tpg2
+
+ interconnects:
+ maxItems: 4
+
+ interconnect-names:
+ items:
+ - const: ahb
+ - const: hf_mnoc
+ - const: sf_icp_mnoc
+ - const: sf_mnoc
+
+ iommus:
+ items:
+ - description: VFE non-protected stream
+ - description: ICP0 shared stream
+ - description: ICP1 shared stream
+ - description: IPE CDM non-protected stream
+ - description: IPE non-protected stream
+ - description: JPEG non-protected stream
+ - description: OFE CDM non-protected stream
+ - description: OFE non-protected stream
+ - description: VFE / VFE Lite CDM non-protected stream
+
+ power-domains:
+ items:
+ - description:
+ VFE0 GDSC - Global Distributed Switch Controller for VFE0.
+ - description:
+ VFE1 GDSC - Global Distributed Switch Controller for VFE1.
+ - description:
+ VFE2 GDSC - Global Distributed Switch Controller for VFE2.
+ - description:
+ Titan GDSC - Global Distributed Switch Controller for the entire camss.
+ - description:
+ IPE GDSC - Global Distributed Switch Controller for IPE.
+ - description:
+ OFE GDSC - Block Global Distributed Switch Controller for OFE.
+
+ power-domain-names:
+ items:
+ - const: vfe0
+ - const: vfe1
+ - const: vfe2
+ - const: top
+ - const: ipe
+ - const: ofe
+
+ vdd-csiphy0-0p8-supply:
+ description:
+ Phandle to a 0.8V regulator supply to CSIPHY0 core block.
+
+ vdd-csiphy0-1p2-supply:
+ description:
+ Phandle to a 1.2V regulator supply to CSIPHY0 pll block.
+
+ vdd-csiphy1-0p8-supply:
+ description:
+ Phandle to a 0.8V regulator supply to CSIPHY1 core block.
+
+ vdd-csiphy1-1p2-supply:
+ description:
+ Phandle to a 1.2V regulator supply to CSIPHY1 pll block.
+
+ vdd-csiphy2-0p8-supply:
+ description:
+ Phandle to a 0.8V regulator supply to CSIPHY2 core block.
+
+ vdd-csiphy2-1p2-supply:
+ description:
+ Phandle to a 1.2V regulator supply to CSIPHY2 pll block.
+
+ vdd-csiphy3-0p8-supply:
+ description:
+ Phandle to a 0.8V regulator supply to CSIPHY3 core block.
+
+ vdd-csiphy3-1p2-supply:
+ description:
+ Phandle to a 1.2V regulator supply to CSIPHY3 pll block.
+
+ vdd-csiphy4-0p8-supply:
+ description:
+ Phandle to a 0.8V regulator supply to CSIPHY4 core block.
+
+ vdd-csiphy4-1p2-supply:
+ description:
+ Phandle to a 1.2V regulator supply to CSIPHY4 pll block.
+
+ vdd-csiphy5-0p8-supply:
+ description:
+ Phandle to a 0.8V regulator supply to CSIPHY5 core block.
+
+ vdd-csiphy5-1p2-supply:
+ description:
+ Phandle to a 1.2V regulator supply to CSIPHY5 pll block.
+
+ ports:
+ $ref: /schemas/graph.yaml#/properties/ports
+
+ description:
+ CSI input ports.
+
+patternProperties:
+ "^port@[0-5]$":
+ $ref: /schemas/graph.yaml#/$defs/port-base
+ unevaluatedProperties: false
+ description:
+ Input ports for receiving CSI data on CSIPHY 0-5.
+
+ properties:
+ endpoint:
+ $ref: video-interfaces.yaml#
+ unevaluatedProperties: false
+
+ properties:
+ data-lanes:
+ minItems: 1
+ maxItems: 4
+
+ required:
+ - data-lanes
+
+required:
+ - compatible
+ - reg
+ - reg-names
+ - clocks
+ - clock-names
+ - interrupts
+ - interrupt-names
+ - interconnects
+ - interconnect-names
+ - iommus
+ - power-domains
+ - power-domain-names
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interconnect/qcom,icc.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 0x09523000 0x0 0x2000>,
+ <0x0 0x09525000 0x0 0x2000>,
+ <0x0 0x09527000 0x0 0x2000>,
+ <0x0 0x09529000 0x0 0x2000>,
+ <0x0 0x0952b000 0x0 0x2000>,
+ <0x0 0x0952d000 0x0 0x2000>,
+ <0x0 0x09151000 0x0 0x20000>,
+ <0x0 0x09171000 0x0 0x20000>,
+ <0x0 0x09191000 0x0 0x20000>,
+ <0x0 0x092dc000 0x0 0x1300>,
+ <0x0 0x092f0000 0x0 0x1300>,
+ <0x0 0x0900e000 0x0 0x1000>,
+ <0x0 0x0900d000 0x0 0x1000>,
+ <0x0 0x0902e000 0x0 0x1000>,
+ <0x0 0x0902d000 0x0 0x1000>,
+ <0x0 0x090d7000 0x0 0x20000>,
+ <0x0 0x0904e000 0x0 0x1000>,
+ <0x0 0x0904d000 0x0 0x1000>,
+ <0x0 0x09057000 0x0 0x40000>,
+ <0x0 0x09147000 0x0 0x580>,
+ <0x0 0x09148000 0x0 0x580>,
+ <0x0 0x09149000 0x0 0x580>,
+ <0x0 0x0914a000 0x0 0x580>,
+ <0x0 0x0914b000 0x0 0x580>,
+ <0x0 0x093fd000 0x0 0x400>,
+ <0x0 0x093fe000 0x0 0x400>,
+ <0x0 0x093ff000 0x0 0x400>;
+ reg-names = "csid0",
+ "csid1",
+ "csid2",
+ "csid_lite0",
+ "csid_lite1",
+ "csiphy0",
+ "csiphy1",
+ "csiphy2",
+ "csiphy3",
+ "csiphy4",
+ "csiphy5",
+ "vfe0",
+ "vfe1",
+ "vfe2",
+ "vfe_lite0",
+ "vfe_lite1",
+ "icp0",
+ "icp0_sys",
+ "icp1",
+ "icp1_sys",
+ "ipe",
+ "jpeg_dma",
+ "jpeg_enc",
+ "ofe",
+ "rt_cdm0",
+ "rt_cdm1",
+ "rt_cdm2",
+ "rt_cdm3",
+ "rt_cdm4",
+ "tpg0",
+ "tpg1",
+ "tpg2";
+
+ clocks = <&camcc_cam_cc_camnoc_nrt_axi_clk>,
+ <&camcc_cam_cc_camnoc_rt_axi_clk>,
+ <&camcc_cam_cc_camnoc_rt_vfe_0_main_clk>,
+ <&camcc_cam_cc_camnoc_rt_vfe_1_main_clk>,
+ <&camcc_cam_cc_camnoc_rt_vfe_2_main_clk>,
+ <&camcc_cam_cc_camnoc_rt_vfe_lite_clk>,
+ <&camcc_cam_cc_cam_top_ahb_clk>,
+ <&camcc_cam_cc_cam_top_fast_ahb_clk>,
+ <&camcc_cam_cc_csid_clk>,
+ <&camcc_cam_cc_csid_csiphy_rx_clk>,
+ <&camcc_cam_cc_csiphy0_clk>,
+ <&camcc_cam_cc_csi0phytimer_clk>,
+ <&camcc_cam_cc_csiphy1_clk>,
+ <&camcc_cam_cc_csi1phytimer_clk>,
+ <&camcc_cam_cc_csiphy2_clk>,
+ <&camcc_cam_cc_csi2phytimer_clk>,
+ <&camcc_cam_cc_csiphy3_clk>,
+ <&camcc_cam_cc_csi3phytimer_clk>,
+ <&camcc_cam_cc_csiphy4_clk>,
+ <&camcc_cam_cc_csi4phytimer_clk>,
+ <&camcc_cam_cc_csiphy5_clk>,
+ <&camcc_cam_cc_csi5phytimer_clk>,
+ <&gcc_gcc_camera_hf_axi_clk>,
+ <&camcc_cam_cc_vfe_0_main_clk>,
+ <&camcc_cam_cc_vfe_0_main_fast_ahb_clk>,
+ <&camcc_cam_cc_vfe_1_main_clk>,
+ <&camcc_cam_cc_vfe_1_main_fast_ahb_clk>,
+ <&camcc_cam_cc_vfe_2_main_clk>,
+ <&camcc_cam_cc_vfe_2_main_fast_ahb_clk>,
+ <&camcc_cam_cc_vfe_lite_clk>,
+ <&camcc_cam_cc_vfe_lite_ahb_clk>,
+ <&camcc_cam_cc_vfe_lite_cphy_rx_clk>,
+ <&camcc_cam_cc_vfe_lite_csid_clk>,
+ <&camcc_cam_cc_qdss_debug_xo_clk>,
+ <&camcc_cam_cc_camnoc_nrt_ipe_nps_clk>,
+ <&camcc_cam_cc_camnoc_nrt_ofe_main_clk>,
+ <&gcc_gcc_camera_sf_axi_clk>,
+ <&camcc_cam_cc_icp_0_clk>,
+ <&camcc_cam_cc_icp_0_ahb_clk>,
+ <&camcc_cam_cc_icp_1_clk>,
+ <&camcc_cam_cc_icp_1_ahb_clk>,
+ <&camcc_cam_cc_ipe_nps_clk>,
+ <&camcc_cam_cc_ipe_nps_ahb_clk>,
+ <&camcc_cam_cc_ipe_nps_fast_ahb_clk>,
+ <&camcc_cam_cc_ipe_pps_clk>,
+ <&camcc_cam_cc_ipe_pps_fast_ahb_clk>,
+ <&camcc_cam_cc_jpeg_clk>,
+ <&camcc_cam_cc_ofe_ahb_clk>,
+ <&camcc_cam_cc_ofe_anchor_clk>,
+ <&camcc_cam_cc_ofe_anchor_fast_ahb_clk>,
+ <&camcc_cam_cc_ofe_hdr_clk>,
+ <&camcc_cam_cc_ofe_hdr_fast_ahb_clk>,
+ <&camcc_cam_cc_ofe_main_clk>,
+ <&camcc_cam_cc_ofe_main_fast_ahb_clk>,
+ <&camcc_cam_cc_vfe_0_bayer_clk>,
+ <&camcc_cam_cc_vfe_0_bayer_fast_ahb_clk>,
+ <&camcc_cam_cc_vfe_1_bayer_clk>,
+ <&camcc_cam_cc_vfe_1_bayer_fast_ahb_clk>,
+ <&camcc_cam_cc_vfe_2_bayer_clk>,
+ <&camcc_cam_cc_vfe_2_bayer_fast_ahb_clk>;
+ clock-names = "camnoc_nrt_axi",
+ "camnoc_rt_axi",
+ "camnoc_rt_vfe0",
+ "camnoc_rt_vfe1",
+ "camnoc_rt_vfe2",
+ "camnoc_rt_vfe_lite",
+ "cpas_ahb",
+ "cpas_fast_ahb",
+ "csid",
+ "csid_csiphy_rx",
+ "csiphy0",
+ "csiphy0_timer",
+ "csiphy1",
+ "csiphy1_timer",
+ "csiphy2",
+ "csiphy2_timer",
+ "csiphy3",
+ "csiphy3_timer",
+ "csiphy4",
+ "csiphy4_timer",
+ "csiphy5",
+ "csiphy5_timer",
+ "gcc_axi_hf",
+ "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",
+ "camnoc_ipe_nps",
+ "camnoc_ofe",
+ "gcc_axi_sf",
+ "icp0",
+ "icp0_ahb",
+ "icp1",
+ "icp1_ahb",
+ "ipe_nps",
+ "ipe_nps_ahb",
+ "ipe_nps_fast_ahb",
+ "ipe_pps",
+ "ipe_pps_fast_ahb",
+ "jpeg",
+ "ofe_ahb",
+ "ofe_anchor",
+ "ofe_anchor_fast_ahb",
+ "ofe_hdr",
+ "ofe_hdr_fast_ahb",
+ "ofe_main",
+ "ofe_main_fast_ahb",
+ "vfe0_bayer",
+ "vfe0_bayer_fast_ahb",
+ "vfe1_bayer",
+ "vfe1_bayer_fast_ahb",
+ "vfe2_bayer",
+ "vfe2_bayer_fast_ahb";
+
+ 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 477 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 478 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 479 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 448 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 122 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 89 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>,
+ <GIC_SPI 271 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 277 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 463 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 657 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 372 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 475 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 456 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 664 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 702 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 348 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 349 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 413 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 416 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 417 IRQ_TYPE_EDGE_RISING>;
+ interrupt-names = "csid0",
+ "csid1",
+ "csid2",
+ "csid_lite0",
+ "csid_lite1",
+ "csiphy0",
+ "csiphy1",
+ "csiphy2",
+ "csiphy3",
+ "csiphy4",
+ "csiphy5",
+ "vfe0",
+ "vfe1",
+ "vfe2",
+ "vfe_lite0",
+ "vfe_lite1",
+ "camnoc_nrt",
+ "camnoc_rt",
+ "icp0",
+ "icp1",
+ "jpeg_dma",
+ "jpeg_enc",
+ "rt_cdm0",
+ "rt_cdm1",
+ "rt_cdm2",
+ "rt_cdm3",
+ "rt_cdm4",
+ "tpg0",
+ "tpg1",
+ "tpg2";
+
+ 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>,
+ <&mmss_noc_master_camnoc_sf_icp QCOM_ICC_TAG_ALWAYS
+ &mc_virt_slave_ebi1 QCOM_ICC_TAG_ALWAYS>,
+ <&mmss_noc_master_camnoc_sf QCOM_ICC_TAG_ALWAYS
+ &mc_virt_slave_ebi1 QCOM_ICC_TAG_ALWAYS>;
+ interconnect-names = "ahb",
+ "hf_mnoc",
+ "sf_icp_mnoc",
+ "sf_mnoc";
+
+ iommus = <&apps_smmu 0x1c00 0x00>,
+ <&apps_smmu 0x18c0 0x00>,
+ <&apps_smmu 0x1980 0x00>,
+ <&apps_smmu 0x1840 0x00>,
+ <&apps_smmu 0x1800 0x00>,
+ <&apps_smmu 0x18a0 0x00>,
+ <&apps_smmu 0x1880 0x00>,
+ <&apps_smmu 0x1820 0x00>,
+ <&apps_smmu 0x1860 0x00>;
+
+ power-domains = <&camcc_cam_cc_vfe_0_gdsc>,
+ <&camcc_cam_cc_vfe_1_gdsc>,
+ <&camcc_cam_cc_vfe_2_gdsc>,
+ <&camcc_cam_cc_titan_top_gdsc>,
+ <&camcc_cam_cc_ipe_gdsc>,
+ <&camcc_cam_cc_ofe_gdsc>;
+ power-domain-names = "vfe0",
+ "vfe1",
+ "vfe2",
+ "top",
+ "ipe",
+ "ofe";
+
+ vdd-csiphy0-0p8-supply = <&vreg_0p8_supply>;
+ vdd-csiphy0-1p2-supply = <&vreg_1p2_supply>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+
+ csiphy_ep0: endpoint {
+ data-lanes = <0 1>;
+ remote-endpoint = <&sensor_ep>;
+ };
+ };
+ };
+ };
+ };
--
2.34.1
^ permalink raw reply related [flat|nested] 17+ messages in thread
* [PATCH v9 2/5] media: qcom: camss: Add Kaanapali compatible camss driver
2025-12-08 12:39 [PATCH v9 0/5] media: qcom: camss: Add Kaanapali support Hangxiang Ma
2025-12-08 12:39 ` [PATCH v9 1/5] media: dt-bindings: Add CAMSS device for Kaanapali Hangxiang Ma
@ 2025-12-08 12:39 ` Hangxiang Ma
2025-12-08 12:39 ` [PATCH v9 3/5] media: qcom: camss: csiphy: Add support for v2.4.0 two-phase CSIPHY Hangxiang Ma
` (2 subsequent siblings)
4 siblings, 0 replies; 17+ messages in thread
From: Hangxiang Ma @ 2025-12-08 12:39 UTC (permalink / raw)
To: Loic Poulain, Robert Foss, Andi Shyti, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Todor Tomov,
Vladimir Zapolskiy, Mauro Carvalho Chehab, Bryan O'Donoghue
Cc: linux-arm-msm, devicetree, linux-kernel, linux-media,
Hangxiang Ma
Add support for Kaanapali in the camss driver. Add high level resource
information along with the bus bandwidth votes. Module level detailed
resource information will be enumerated in the following patches of the
series.
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 | 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 2fbcd0e343aa..658d9c9183d4 100644
--- a/drivers/media/platform/qcom/camss/camss.c
+++ b/drivers/media/platform/qcom/camss/camss.c
@@ -34,6 +34,20 @@
static const struct parent_dev_ops vfe_parent_dev_ops;
+static const struct resources_icc icc_res_kaanapali[] = {
+ {
+ .name = "ahb",
+ .icc_bw_tbl.avg = 150000,
+ .icc_bw_tbl.peak = 300000,
+ },
+ /* Based on 4096 x 3072 30 FPS 2496 Mbps mode */
+ {
+ .name = "hf_mnoc",
+ .icc_bw_tbl.avg = 471860,
+ .icc_bw_tbl.peak = 925857,
+ },
+};
+
static const struct camss_subdev_resources csiphy_res_8x16[] = {
/* CSIPHY0 */
{
@@ -4291,6 +4305,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,
@@ -4467,6 +4488,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,msm8953-camss", .data = &msm8953_resources },
{ .compatible = "qcom,msm8996-camss", .data = &msm8996_resources },
diff --git a/drivers/media/platform/qcom/camss/camss.h b/drivers/media/platform/qcom/camss/camss.h
index 901f84efaf7d..876cd2a64cbe 100644
--- a/drivers/media/platform/qcom/camss/camss.h
+++ b/drivers/media/platform/qcom/camss/camss.h
@@ -90,6 +90,7 @@ enum camss_version {
CAMSS_845,
CAMSS_8550,
CAMSS_8775P,
+ CAMSS_KAANAPALI,
CAMSS_X1E80100,
};
--
2.34.1
^ permalink raw reply related [flat|nested] 17+ messages in thread
* [PATCH v9 3/5] media: qcom: camss: csiphy: Add support for v2.4.0 two-phase CSIPHY
2025-12-08 12:39 [PATCH v9 0/5] media: qcom: camss: Add Kaanapali support Hangxiang Ma
2025-12-08 12:39 ` [PATCH v9 1/5] media: dt-bindings: Add CAMSS device for Kaanapali Hangxiang Ma
2025-12-08 12:39 ` [PATCH v9 2/5] media: qcom: camss: Add Kaanapali compatible camss driver Hangxiang Ma
@ 2025-12-08 12:39 ` Hangxiang Ma
2025-12-08 12:39 ` [PATCH v9 4/5] media: qcom: camss: csid: Add support for CSID gen4 Hangxiang Ma
2025-12-08 12:39 ` [PATCH v9 5/5] media: qcom: camss: vfe: Add support for VFE gen4 Hangxiang Ma
4 siblings, 0 replies; 17+ messages in thread
From: Hangxiang Ma @ 2025-12-08 12:39 UTC (permalink / raw)
To: Loic Poulain, Robert Foss, Andi Shyti, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Todor Tomov,
Vladimir Zapolskiy, Mauro Carvalho Chehab, Bryan O'Donoghue
Cc: linux-arm-msm, devicetree, linux-kernel, linux-media,
Hangxiang Ma
Add more detailed resource information for CSIPHY devices in the camss
driver along with the support for v2.4.0 in the 2 phase CSIPHY driver
that is responsible for the PHY lane register configuration, module
reset and interrupt handling.
Reviewed-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
Signed-off-by: Hangxiang Ma <hangxiang.ma@oss.qualcomm.com>
---
.../platform/qcom/camss/camss-csiphy-3ph-1-0.c | 124 +++++++++++++++++++++
drivers/media/platform/qcom/camss/camss.c | 107 ++++++++++++++++++
2 files changed, 231 insertions(+)
diff --git a/drivers/media/platform/qcom/camss/camss-csiphy-3ph-1-0.c b/drivers/media/platform/qcom/camss/camss-csiphy-3ph-1-0.c
index 9b6a0535cdf8..5499f4141294 100644
--- a/drivers/media/platform/qcom/camss/camss-csiphy-3ph-1-0.c
+++ b/drivers/media/platform/qcom/camss/camss-csiphy-3ph-1-0.c
@@ -588,6 +588,123 @@ csiphy_lane_regs lane_regs_sm8550[] = {
{0x0C64, 0x7F, 0x00, CSIPHY_DEFAULT_PARAMS},
};
+/* 3nm 2PH v 2.4.0 2p5Gbps 4 lane DPHY mode */
+static const struct
+csiphy_lane_regs lane_regs_kaanapali[] = {
+ /* LN 0 */
+ {0x0094, 0x00, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x00A0, 0x00, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x0090, 0x0F, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x0098, 0x08, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x0094, 0x07, 0xd1, CSIPHY_DEFAULT_PARAMS},
+ {0x0030, 0x00, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x0000, 0x8C, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x0038, 0xFE, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x002C, 0x01, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x0034, 0x0F, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x001C, 0x0A, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x0014, 0x60, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x003C, 0xB8, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x0004, 0x0C, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x0020, 0x00, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x0008, 0x19, 0x00, CSIPHY_SETTLE_CNT_LOWER_BYTE},
+ {0x0010, 0x52, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x0094, 0xD7, 0x00, CSIPHY_SKEW_CAL},
+ {0x005C, 0x54, 0x00, CSIPHY_SKEW_CAL},
+ {0x0060, 0xFD, 0x00, CSIPHY_SKEW_CAL},
+ {0x0064, 0x7F, 0x00, CSIPHY_SKEW_CAL},
+
+ /* LN 2 */
+ {0x0494, 0x00, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x04A0, 0x00, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x0490, 0x0F, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x0498, 0x08, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x0494, 0x07, 0xd1, CSIPHY_DEFAULT_PARAMS},
+ {0x0430, 0x00, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x0400, 0x8C, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x0438, 0xFE, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x042C, 0x01, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x0434, 0x0F, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x041C, 0x0A, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x0414, 0x60, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x043C, 0xB8, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x0404, 0x0C, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x0420, 0x00, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x0408, 0x19, 0x00, CSIPHY_SETTLE_CNT_LOWER_BYTE},
+ {0x0410, 0x52, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x0494, 0xD7, 0x00, CSIPHY_SKEW_CAL},
+ {0x045C, 0x54, 0x00, CSIPHY_SKEW_CAL},
+ {0x0460, 0xFD, 0x00, CSIPHY_SKEW_CAL},
+ {0x0464, 0x7F, 0x00, CSIPHY_SKEW_CAL},
+
+ /* LN 4 */
+ {0x0894, 0x00, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x08A0, 0x00, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x0890, 0x0F, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x0898, 0x08, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x0894, 0x07, 0xd1, CSIPHY_DEFAULT_PARAMS},
+ {0x0830, 0x00, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x0800, 0x8C, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x0838, 0xFE, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x082C, 0x01, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x0834, 0x0F, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x081C, 0x0A, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x0814, 0x60, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x083C, 0xB8, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x0804, 0x0C, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x0820, 0x00, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x0808, 0x19, 0x00, CSIPHY_SETTLE_CNT_LOWER_BYTE},
+ {0x0810, 0x52, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x0894, 0xD7, 0x00, CSIPHY_SKEW_CAL},
+ {0x085C, 0x54, 0x00, CSIPHY_SKEW_CAL},
+ {0x0860, 0xFD, 0x00, CSIPHY_SKEW_CAL},
+ {0x0864, 0x7F, 0x00, CSIPHY_SKEW_CAL},
+
+ /* LN 6 */
+ {0x0C94, 0x00, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x0CA0, 0x00, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x0C90, 0x0F, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x0C98, 0x08, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x0C94, 0x07, 0xd1, CSIPHY_DEFAULT_PARAMS},
+ {0x0C30, 0x00, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x0C00, 0x8C, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x0C38, 0xFE, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x0C2C, 0x01, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x0C34, 0x0F, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x0C1C, 0x0A, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x0C14, 0x60, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x0C3C, 0xB8, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x0C04, 0x0C, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x0C20, 0x00, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x0C08, 0x19, 0x00, CSIPHY_SETTLE_CNT_LOWER_BYTE},
+ {0x0C10, 0x52, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x0C94, 0xD7, 0x00, CSIPHY_SKEW_CAL},
+ {0x0C5C, 0x54, 0x00, CSIPHY_SKEW_CAL},
+ {0x0C60, 0xFD, 0x00, CSIPHY_SKEW_CAL},
+ {0x0C64, 0x7F, 0x00, CSIPHY_SKEW_CAL},
+
+ /* LN CLK */
+ {0x0E94, 0x00, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x0EA0, 0x00, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x0E90, 0x0F, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x0E98, 0x08, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x0E94, 0x07, 0xd1, CSIPHY_DEFAULT_PARAMS},
+ {0x0E30, 0x00, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x0E28, 0x04, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x0E00, 0x80, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x0E0C, 0xFF, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x0E38, 0x1F, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x0E2C, 0x01, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x0E34, 0x0F, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x0E1C, 0x0A, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x0E14, 0x60, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x0E3C, 0xB8, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x0E04, 0x0C, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x0E20, 0x00, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x0E08, 0x19, 0x00, CSIPHY_SETTLE_CNT_LOWER_BYTE},
+ {0x0E10, 0x52, 0x00, CSIPHY_DEFAULT_PARAMS},
+};
+
/* 4nm 2PH v 2.1.2 2p5Gbps 4 lane DPHY mode */
static const struct
csiphy_lane_regs lane_regs_x1e80100[] = {
@@ -921,6 +1038,7 @@ static bool csiphy_is_gen2(u32 version)
case CAMSS_845:
case CAMSS_8550:
case CAMSS_8775P:
+ case CAMSS_KAANAPALI:
case CAMSS_X1E80100:
ret = true;
break;
@@ -1030,6 +1148,12 @@ static int csiphy_init(struct csiphy_device *csiphy)
regs->lane_regs = &lane_regs_sa8775p[0];
regs->lane_array_size = ARRAY_SIZE(lane_regs_sa8775p);
break;
+ case CAMSS_KAANAPALI:
+ regs->lane_regs = &lane_regs_kaanapali[0];
+ regs->lane_array_size = ARRAY_SIZE(lane_regs_kaanapali);
+ regs->offset = 0x1000;
+ regs->common_status_offset = 0x138;
+ break;
default:
break;
}
diff --git a/drivers/media/platform/qcom/camss/camss.c b/drivers/media/platform/qcom/camss/camss.c
index 658d9c9183d4..77ec9453d0a4 100644
--- a/drivers/media/platform/qcom/camss/camss.c
+++ b/drivers/media/platform/qcom/camss/camss.c
@@ -34,6 +34,111 @@
static const struct parent_dev_ops vfe_parent_dev_ops;
+static const struct camss_subdev_resources csiphy_res_kaanapali[] = {
+ /* CSIPHY0 */
+ {
+ .regulators = { "vdd-csiphy0-0p8", "vdd-csiphy0-1p2" },
+ .clock = { "csiphy0", "csiphy0_timer",
+ "cpas_ahb", "cpas_fast_ahb" },
+ .clock_rate = { { 400000000, 480000000 },
+ { 400000000 },
+ { 0 },
+ { 0 } },
+ .reg = { "csiphy0" },
+ .interrupt = { "csiphy0" },
+ .csiphy = {
+ .id = 0,
+ .hw_ops = &csiphy_ops_3ph_1_0,
+ .formats = &csiphy_formats_sdm845
+ }
+ },
+ /* CSIPHY1 */
+ {
+ .regulators = { "vdd-csiphy1-0p8", "vdd-csiphy1-1p2" },
+ .clock = { "csiphy1", "csiphy1_timer",
+ "cpas_ahb", "cpas_fast_ahb" },
+ .clock_rate = { { 400000000, 480000000 },
+ { 400000000 },
+ { 0 },
+ { 0 } },
+ .reg = { "csiphy1" },
+ .interrupt = { "csiphy1" },
+ .csiphy = {
+ .id = 1,
+ .hw_ops = &csiphy_ops_3ph_1_0,
+ .formats = &csiphy_formats_sdm845
+ }
+ },
+ /* CSIPHY2 */
+ {
+ .regulators = { "vdd-csiphy2-0p8", "vdd-csiphy2-1p2" },
+ .clock = { "csiphy2", "csiphy2_timer",
+ "cpas_ahb", "cpas_fast_ahb" },
+ .clock_rate = { { 400000000, 480000000 },
+ { 400000000 },
+ { 0 },
+ { 0 } },
+ .reg = { "csiphy2" },
+ .interrupt = { "csiphy2" },
+ .csiphy = {
+ .id = 2,
+ .hw_ops = &csiphy_ops_3ph_1_0,
+ .formats = &csiphy_formats_sdm845
+ }
+ },
+ /* CSIPHY3 */
+ {
+ .regulators = { "vdd-csiphy3-0p8", "vdd-csiphy3-1p2" },
+ .clock = { "csiphy3", "csiphy3_timer",
+ "cpas_ahb", "cpas_fast_ahb" },
+ .clock_rate = { { 400000000, 480000000 },
+ { 400000000 },
+ { 0 },
+ { 0 } },
+ .reg = { "csiphy3" },
+ .interrupt = { "csiphy3" },
+ .csiphy = {
+ .id = 3,
+ .hw_ops = &csiphy_ops_3ph_1_0,
+ .formats = &csiphy_formats_sdm845
+ }
+ },
+ /* CSIPHY4 */
+ {
+ .regulators = { "vdd-csiphy4-0p8", "vdd-csiphy4-1p2" },
+ .clock = { "csiphy4", "csiphy4_timer",
+ "cpas_ahb", "cpas_fast_ahb" },
+ .clock_rate = { { 400000000, 480000000 },
+ { 400000000 },
+ { 0 },
+ { 0 } },
+ .reg = { "csiphy4" },
+ .interrupt = { "csiphy4" },
+ .csiphy = {
+ .id = 4,
+ .hw_ops = &csiphy_ops_3ph_1_0,
+ .formats = &csiphy_formats_sdm845
+ }
+ },
+ /* CSIPHY5 */
+ {
+ .regulators = { "vdd-csiphy5-0p8", "vdd-csiphy5-1p2" },
+ .clock = { "csiphy5", "csiphy5_timer",
+ "cpas_ahb", "cpas_fast_ahb" },
+ .clock_rate = { { 400000000, 480000000 },
+ { 400000000 },
+ { 0 },
+ { 0 } },
+ .reg = { "csiphy5" },
+ .interrupt = { "csiphy5" },
+ .csiphy = {
+ .id = 5,
+ .hw_ops = &csiphy_ops_3ph_1_0,
+ .formats = &csiphy_formats_sdm845
+ }
+ },
+};
+
static const struct resources_icc icc_res_kaanapali[] = {
{
.name = "ahb",
@@ -4308,8 +4413,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] 17+ messages in thread
* [PATCH v9 4/5] media: qcom: camss: csid: Add support for CSID gen4
2025-12-08 12:39 [PATCH v9 0/5] media: qcom: camss: Add Kaanapali support Hangxiang Ma
` (2 preceding siblings ...)
2025-12-08 12:39 ` [PATCH v9 3/5] media: qcom: camss: csiphy: Add support for v2.4.0 two-phase CSIPHY Hangxiang Ma
@ 2025-12-08 12:39 ` Hangxiang Ma
2025-12-08 12:39 ` [PATCH v9 5/5] media: qcom: camss: vfe: Add support for VFE gen4 Hangxiang Ma
4 siblings, 0 replies; 17+ messages in thread
From: Hangxiang Ma @ 2025-12-08 12:39 UTC (permalink / raw)
To: Loic Poulain, Robert Foss, Andi Shyti, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Todor Tomov,
Vladimir Zapolskiy, Mauro Carvalho Chehab, Bryan O'Donoghue
Cc: linux-arm-msm, devicetree, linux-kernel, linux-media,
Hangxiang Ma, Atiya Kailany
Add more detailed resource information for CSID devices along with the
driver for CSID gen4 that is responsible for CSID register configuration,
module reset and IRQ handling for BUF_DONE events. And aggregate a common
definition 'CSI2_RX_CFG0_PHY_SEL_BASE_IDX' into csid header file.
In this CSID version, RUP and AUP update values are split into two
registers along with a SET register. Accordingly, enhance the CSID
interface to accommodate both the legacy combined reg_update and the
split RUP and AUP updates.
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-csid-680.c | 1 -
.../media/platform/qcom/camss/camss-csid-gen3.c | 1 -
.../media/platform/qcom/camss/camss-csid-gen4.c | 376 +++++++++++++++++++++
drivers/media/platform/qcom/camss/camss-csid.h | 11 +-
drivers/media/platform/qcom/camss/camss.c | 80 +++++
6 files changed, 467 insertions(+), 3 deletions(-)
diff --git a/drivers/media/platform/qcom/camss/Makefile b/drivers/media/platform/qcom/camss/Makefile
index 23960d02877d..738d57214056 100644
--- a/drivers/media/platform/qcom/camss/Makefile
+++ b/drivers/media/platform/qcom/camss/Makefile
@@ -10,6 +10,7 @@ qcom-camss-objs += \
camss-csid-680.o \
camss-csid-gen2.o \
camss-csid-gen3.o \
+ camss-csid-gen4.o \
camss-csiphy-2ph-1-0.o \
camss-csiphy-3ph-1-0.o \
camss-csiphy.o \
diff --git a/drivers/media/platform/qcom/camss/camss-csid-680.c b/drivers/media/platform/qcom/camss/camss-csid-680.c
index 3ad3a174bcfb..86134a23cd4e 100644
--- a/drivers/media/platform/qcom/camss/camss-csid-680.c
+++ b/drivers/media/platform/qcom/camss/camss-csid-680.c
@@ -101,7 +101,6 @@
#define CSI2_RX_CFG0_DL2_INPUT_SEL 12
#define CSI2_RX_CFG0_DL3_INPUT_SEL 16
#define CSI2_RX_CFG0_PHY_NUM_SEL 20
-#define CSI2_RX_CFG0_PHY_SEL_BASE_IDX 1
#define CSI2_RX_CFG0_PHY_TYPE_SEL 24
#define CSID_CSI2_RX_CFG1 0x204
diff --git a/drivers/media/platform/qcom/camss/camss-csid-gen3.c b/drivers/media/platform/qcom/camss/camss-csid-gen3.c
index 664245cf6eb0..f09b5575572a 100644
--- a/drivers/media/platform/qcom/camss/camss-csid-gen3.c
+++ b/drivers/media/platform/qcom/camss/camss-csid-gen3.c
@@ -103,7 +103,6 @@
#define CSID_RDI_IRQ_SUBSAMPLE_PERIOD(rdi) (csid_is_lite(csid) && IS_CSID_690(csid) ?\
(0x34C + 0x100 * (rdi)) :\
(0x54C + 0x100 * (rdi)))
-#define CSI2_RX_CFG0_PHY_SEL_BASE_IDX 1
static void __csid_configure_rx(struct csid_device *csid,
struct csid_phy_config *phy, int vc)
diff --git a/drivers/media/platform/qcom/camss/camss-csid-gen4.c b/drivers/media/platform/qcom/camss/camss-csid-gen4.c
new file mode 100644
index 000000000000..b000bd3e9c2e
--- /dev/null
+++ b/drivers/media/platform/qcom/camss/camss-csid-gen4.c
@@ -0,0 +1,376 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * camss-csid-gen4.c
+ *
+ * Qualcomm MSM Camera Subsystem - CSID (CSI Decoder) Module
+ *
+ * Copyright (c) Qualcomm Technologies, Inc. and/or its subsidiaries.
+ */
+#include <linux/completion.h>
+#include <linux/delay.h>
+#include <linux/interrupt.h>
+#include <linux/io.h>
+#include <linux/kernel.h>
+#include <linux/of.h>
+
+#include "camss.h"
+#include "camss-csid.h"
+#include "camss-csid-gen3.h"
+
+/* Reset and Command Registers */
+#define CSID_RST_CFG 0x108
+#define RST_MODE BIT(0)
+#define RST_LOCATION BIT(4)
+
+/* Reset and Command Registers */
+#define CSID_RST_CMD 0x10C
+#define SELECT_HW_RST BIT(0)
+#define SELECT_IRQ_RST BIT(2)
+#define CSID_IRQ_CMD 0x110
+#define IRQ_CMD_CLEAR BIT(0)
+
+/* Register Update Commands, RUP/AUP */
+#define CSID_RUP_CMD 0x114
+#define CSID_AUP_CMD 0x118
+#define CSID_RUP_AUP_RDI(rdi) (BIT(8) << (rdi))
+#define CSID_RUP_AUP_CMD 0x11C
+#define RUP_SET BIT(0)
+#define MUP BIT(4)
+
+/* Top level interrupt registers */
+#define CSID_TOP_IRQ_STATUS 0x180
+#define CSID_TOP_IRQ_MASK 0x184
+#define CSID_TOP_IRQ_CLEAR 0x188
+#define INFO_RST_DONE BIT(0)
+#define CSI2_RX_IRQ_STATUS BIT(2)
+#define BUF_DONE_IRQ_STATUS BIT(3)
+
+/* Buffer done interrupt registers */
+#define CSID_BUF_DONE_IRQ_STATUS 0x1A0
+#define BUF_DONE_IRQ_STATUS_RDI_OFFSET 16
+#define CSID_BUF_DONE_IRQ_MASK 0x1A4
+#define CSID_BUF_DONE_IRQ_CLEAR 0x1A8
+#define CSID_BUF_DONE_IRQ_SET 0x1AC
+
+/* CSI2 RX interrupt registers */
+#define CSID_CSI2_RX_IRQ_STATUS 0x1B0
+#define CSID_CSI2_RX_IRQ_MASK 0x1B4
+#define CSID_CSI2_RX_IRQ_CLEAR 0x1B8
+#define CSID_CSI2_RX_IRQ_SET 0x1BC
+
+/* CSI2 RX Configuration */
+#define CSID_CSI2_RX_CFG0 0x880
+#define CSI2_RX_CFG0_NUM_ACTIVE_LANES 0
+#define CSI2_RX_CFG0_DL0_INPUT_SEL 4
+#define CSI2_RX_CFG0_PHY_NUM_SEL 20
+#define CSID_CSI2_RX_CFG1 0x884
+#define CSI2_RX_CFG1_ECC_CORRECTION_EN BIT(0)
+#define CSI2_RX_CFG1_VC_MODE BIT(2)
+
+#define MSM_CSID_MAX_SRC_STREAMS_GEN4 (csid_is_lite(csid) ? 4 : 5)
+
+/* RDI Configuration */
+#define CSID_RDI_CFG0(rdi) \
+ ((csid_is_lite(csid) ? 0x3080 : 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 : 0x5488) + 0x200 * (rdi))
+#define RDI_CTRL_START_CMD BIT(0)
+
+#define CSID_RDI_CFG1(rdi) \
+ ((csid_is_lite(csid) ? 0x3094 : 0x5494) + 0x200 * (rdi))
+#define RDI_CFG1_DROP_H_EN BIT(5)
+#define RDI_CFG1_DROP_V_EN BIT(6)
+#define RDI_CFG1_CROP_H_EN BIT(7)
+#define RDI_CFG1_CROP_V_EN BIT(8)
+#define RDI_CFG1_PACKING_FORMAT_MIPI BIT(15)
+
+/* RDI Pixel Store Configuration */
+#define CSID_RDI_PIX_STORE_CFG0(rdi) (0x5498 + 0x200 * (rdi))
+#define RDI_PIX_STORE_CFG0_EN BIT(0)
+#define RDI_PIX_STORE_CFG0_MIN_HBI 1
+
+/* RDI IRQ Status in wrapper */
+#define CSID_CSI2_RDIN_IRQ_STATUS(rdi) (0x224 + (0x10 * (rdi)))
+#define CSID_CSI2_RDIN_IRQ_MASK(rdi) (0x228 + (0x10 * (rdi)))
+#define CSID_CSI2_RDIN_IRQ_CLEAR(rdi) (0x22C + (0x10 * (rdi)))
+#define INFO_RUP_DONE BIT(23)
+
+static void __csid_aup_rup_trigger(struct csid_device *csid)
+{
+ /* trigger SET in combined register */
+ writel(RUP_SET, csid->base + CSID_RUP_AUP_CMD);
+}
+
+static void __csid_aup_rup_clear(struct csid_device *csid, int port_id)
+{
+ /* Hardware clears the registers upon consuming the settings */
+ csid->aup_update &= ~CSID_RUP_AUP_RDI(port_id);
+ csid->rup_update &= ~CSID_RUP_AUP_RDI(port_id);
+}
+
+static void __csid_aup_update(struct csid_device *csid, int port_id)
+{
+ csid->aup_update |= CSID_RUP_AUP_RDI(port_id);
+ writel(csid->aup_update, csid->base + CSID_AUP_CMD);
+
+ __csid_aup_rup_trigger(csid);
+}
+
+static void __csid_reg_update(struct csid_device *csid, int port_id)
+{
+ csid->rup_update |= CSID_RUP_AUP_RDI(port_id);
+ writel(csid->rup_update, csid->base + CSID_RUP_CMD);
+
+ __csid_aup_rup_trigger(csid);
+}
+
+static void __csid_configure_rx(struct csid_device *csid,
+ struct csid_phy_config *phy)
+{
+ int val;
+
+ val = (phy->lane_cnt - 1) << CSI2_RX_CFG0_NUM_ACTIVE_LANES;
+ val |= phy->lane_assign << CSI2_RX_CFG0_DL0_INPUT_SEL;
+ val |= (phy->csiphy_id + CSI2_RX_CFG0_PHY_SEL_BASE_IDX)
+ << CSI2_RX_CFG0_PHY_NUM_SEL;
+ writel(val, csid->base + CSID_CSI2_RX_CFG0);
+
+ val = CSI2_RX_CFG1_ECC_CORRECTION_EN;
+ writel(val, csid->base + CSID_CSI2_RX_CFG1);
+}
+
+static void __csid_configure_rx_vc(struct csid_device *csid, int vc)
+{
+ int val;
+
+ if (vc > 3) {
+ val = readl(csid->base + CSID_CSI2_RX_CFG1);
+ val |= CSI2_RX_CFG1_VC_MODE;
+ writel(val, csid->base + CSID_CSI2_RX_CFG1);
+ }
+}
+
+static void __csid_ctrl_rdi(struct csid_device *csid, int enable, u8 rdi)
+{
+ int val = 0;
+
+ if (enable)
+ val = RDI_CTRL_START_CMD;
+
+ writel(val, csid->base + CSID_RDI_CTRL(rdi));
+}
+
+static void __csid_configure_rdi_pix_store(struct csid_device *csid, u8 rdi)
+{
+ u32 val;
+
+ /* Configure pixel store to allow absorption of hblanking or idle time.
+ * This helps with horizontal crop and prevents line buffer conflicts.
+ * Reset state is 0x8 which has MIN_HBI=4, we keep the default MIN_HBI
+ * and just enable the pixel store functionality.
+ */
+ val = (4 << RDI_PIX_STORE_CFG0_MIN_HBI) | RDI_PIX_STORE_CFG0_EN;
+ writel(val, csid->base + CSID_RDI_PIX_STORE_CFG0(rdi));
+}
+
+static void __csid_configure_rdi_stream(struct csid_device *csid, u8 enable, u8 vc)
+{
+ u32 val;
+ u8 lane_cnt = csid->phy.lane_cnt;
+
+ /* 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 + vc];
+ 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(vc));
+
+ val = RDI_CFG1_PACKING_FORMAT_MIPI;
+ writel(val, csid->base + CSID_RDI_CFG1(vc));
+
+ /* Configure pixel store using dedicated register in gen4 */
+ if (!csid_is_lite(csid))
+ __csid_configure_rdi_pix_store(csid, vc);
+
+ val = 0;
+ writel(val, csid->base + CSID_RDI_CTRL(vc));
+
+ val = readl(csid->base + CSID_RDI_CFG0(vc));
+
+ if (enable)
+ val |= RDI_CFG0_EN;
+
+ writel(val, csid->base + CSID_RDI_CFG0(vc));
+}
+
+static void csid_configure_stream(struct csid_device *csid, u8 enable)
+{
+ u8 i;
+ u8 vc;
+
+ __csid_configure_rx(csid, &csid->phy);
+
+ for (vc = 0; vc < MSM_CSID_MAX_SRC_STREAMS_GEN4; vc++) {
+ if (csid->phy.en_vc & BIT(vc)) {
+ __csid_configure_rdi_stream(csid, enable, vc);
+ __csid_configure_rx_vc(csid, vc);
+
+ for (i = 0; i < CAMSS_INIT_BUF_COUNT; i++)
+ __csid_aup_update(csid, vc);
+
+ __csid_reg_update(csid, vc);
+
+ __csid_ctrl_rdi(csid, enable, vc);
+ }
+ }
+}
+
+static int csid_configure_testgen_pattern(struct csid_device *csid, s32 val)
+{
+ return 0;
+}
+
+static void csid_subdev_reg_update(struct csid_device *csid, int port_id,
+ bool clear)
+{
+ if (clear)
+ __csid_aup_rup_clear(csid, port_id);
+ else
+ __csid_aup_update(csid, port_id);
+}
+
+/**
+ * csid_isr - CSID module interrupt service routine
+ * @irq: Interrupt line
+ * @dev: CSID device
+ *
+ * Return IRQ_HANDLED on success
+ */
+static irqreturn_t csid_isr(int irq, void *dev)
+{
+ struct csid_device *csid = dev;
+ u32 val, buf_done_val;
+ u8 reset_done;
+ int i;
+
+ val = readl(csid->base + CSID_TOP_IRQ_STATUS);
+ writel(val, csid->base + CSID_TOP_IRQ_CLEAR);
+
+ reset_done = val & INFO_RST_DONE;
+
+ buf_done_val = readl(csid->base + CSID_BUF_DONE_IRQ_STATUS);
+ writel(buf_done_val, csid->base + CSID_BUF_DONE_IRQ_CLEAR);
+
+ for (i = 0; i < MSM_CSID_MAX_SRC_STREAMS_GEN4; i++) {
+ if (csid->phy.en_vc & BIT(i)) {
+ val = readl(csid->base + CSID_CSI2_RDIN_IRQ_STATUS(i));
+ writel(val, csid->base + CSID_CSI2_RDIN_IRQ_CLEAR(i));
+
+ if (val & INFO_RUP_DONE)
+ csid_subdev_reg_update(csid, i, true);
+
+ if (buf_done_val & BIT(BUF_DONE_IRQ_STATUS_RDI_OFFSET + i))
+ camss_buf_done(csid->camss, csid->id, i);
+ }
+ }
+
+ val = IRQ_CMD_CLEAR;
+ writel(val, csid->base + CSID_IRQ_CMD);
+
+ if (reset_done)
+ complete(&csid->reset_complete);
+
+ return IRQ_HANDLED;
+}
+
+/**
+ * csid_reset - Trigger reset on CSID module and wait to complete
+ * @csid: CSID device
+ *
+ * Return 0 on success or a negative error code otherwise
+ */
+static int csid_reset(struct csid_device *csid)
+{
+ unsigned long time;
+ u32 val;
+ int i;
+
+ reinit_completion(&csid->reset_complete);
+
+ val = INFO_RST_DONE | BUF_DONE_IRQ_STATUS;
+ writel(val, csid->base + CSID_TOP_IRQ_CLEAR);
+ writel(val, csid->base + CSID_TOP_IRQ_MASK);
+
+ val = 0;
+ for (i = 0; i < MSM_CSID_MAX_SRC_STREAMS_GEN4; i++) {
+ if (csid->phy.en_vc & BIT(i)) {
+ /*
+ * Only need to clear buf done IRQ status here,
+ * RUP done IRQ status will be cleared once isr
+ * strobe generated by CSID_RST_CMD
+ */
+ val |= BIT(BUF_DONE_IRQ_STATUS_RDI_OFFSET + i);
+ }
+ }
+ writel(val, csid->base + CSID_BUF_DONE_IRQ_CLEAR);
+ writel(val, csid->base + CSID_BUF_DONE_IRQ_MASK);
+
+ /* Clear all IRQ status with CLEAR bits set */
+ val = IRQ_CMD_CLEAR;
+ writel(val, csid->base + CSID_IRQ_CMD);
+
+ val = RST_LOCATION | RST_MODE;
+ writel(val, csid->base + CSID_RST_CFG);
+
+ val = SELECT_HW_RST | SELECT_IRQ_RST;
+ writel(val, csid->base + CSID_RST_CMD);
+
+ time = wait_for_completion_timeout(&csid->reset_complete,
+ msecs_to_jiffies(CSID_RESET_TIMEOUT_MS));
+
+ if (!time) {
+ dev_err(csid->camss->dev, "CSID reset timeout\n");
+ return -EIO;
+ }
+
+ return 0;
+}
+
+static void csid_subdev_init(struct csid_device *csid)
+{
+ csid->testgen.nmodes = CSID_PAYLOAD_MODE_DISABLED;
+}
+
+const struct csid_hw_ops csid_ops_gen4 = {
+ .configure_stream = csid_configure_stream,
+ .configure_testgen_pattern = csid_configure_testgen_pattern,
+ .hw_version = csid_hw_version,
+ .isr = csid_isr,
+ .reset = csid_reset,
+ .src_pad_code = csid_src_pad_code,
+ .subdev_init = csid_subdev_init,
+ .reg_update = csid_subdev_reg_update,
+};
diff --git a/drivers/media/platform/qcom/camss/camss-csid.h b/drivers/media/platform/qcom/camss/camss-csid.h
index aedc96ed84b2..75a113050eb1 100644
--- a/drivers/media/platform/qcom/camss/camss-csid.h
+++ b/drivers/media/platform/qcom/camss/camss-csid.h
@@ -27,6 +27,8 @@
/* CSID hardware can demultiplex up to 4 outputs */
#define MSM_CSID_MAX_SRC_STREAMS 4
+/* CSIPHY to hardware PHY selector mapping */
+#define CSI2_RX_CFG0_PHY_SEL_BASE_IDX 1
#define CSID_RESET_TIMEOUT_MS 500
enum csid_testgen_mode {
@@ -154,7 +156,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;
@@ -217,6 +225,7 @@ extern const struct csid_hw_ops csid_ops_340;
extern const struct csid_hw_ops csid_ops_680;
extern const struct csid_hw_ops csid_ops_gen2;
extern const struct csid_hw_ops csid_ops_gen3;
+extern const struct csid_hw_ops csid_ops_gen4;
/*
* csid_is_lite - Check if CSID is CSID lite.
diff --git a/drivers/media/platform/qcom/camss/camss.c b/drivers/media/platform/qcom/camss/camss.c
index 77ec9453d0a4..a1c2dacd5e5f 100644
--- a/drivers/media/platform/qcom/camss/camss.c
+++ b/drivers/media/platform/qcom/camss/camss.c
@@ -139,6 +139,84 @@ static const struct camss_subdev_resources csiphy_res_kaanapali[] = {
},
};
+static const struct camss_subdev_resources csid_res_kaanapali[] = {
+ /* CSID0 */
+ {
+ .regulators = {},
+ .clock = { "csid", "csid_csiphy_rx" },
+ .clock_rate = { { 400000000, 480000000 },
+ { 400000000, 480000000 } },
+ .reg = { "csid0" },
+ .interrupt = { "csid0" },
+ .csid = {
+ .is_lite = false,
+ .parent_dev_ops = &vfe_parent_dev_ops,
+ .hw_ops = &csid_ops_gen4,
+ .formats = &csid_formats_gen2
+ }
+ },
+ /* CSID1 */
+ {
+ .regulators = {},
+ .clock = { "csid", "csid_csiphy_rx" },
+ .clock_rate = { { 400000000, 480000000 },
+ { 400000000, 480000000 } },
+ .reg = { "csid1" },
+ .interrupt = { "csid1" },
+ .csid = {
+ .is_lite = false,
+ .parent_dev_ops = &vfe_parent_dev_ops,
+ .hw_ops = &csid_ops_gen4,
+ .formats = &csid_formats_gen2
+ }
+ },
+ /* CSID2 */
+ {
+ .regulators = {},
+ .clock = { "csid", "csid_csiphy_rx" },
+ .clock_rate = { { 400000000, 480000000 },
+ { 400000000, 480000000 } },
+ .reg = { "csid2" },
+ .interrupt = { "csid2" },
+ .csid = {
+ .is_lite = false,
+ .parent_dev_ops = &vfe_parent_dev_ops,
+ .hw_ops = &csid_ops_gen4,
+ .formats = &csid_formats_gen2
+ }
+ },
+ /* CSID_LITE0 */
+ {
+ .regulators = {},
+ .clock = { "vfe_lite_csid", "vfe_lite_cphy_rx" },
+ .clock_rate = { { 400000000, 480000000 },
+ { 400000000, 480000000 } },
+ .reg = { "csid_lite0" },
+ .interrupt = { "csid_lite0" },
+ .csid = {
+ .is_lite = true,
+ .parent_dev_ops = &vfe_parent_dev_ops,
+ .hw_ops = &csid_ops_gen4,
+ .formats = &csid_formats_gen2
+ }
+ },
+ /* CSID_LITE1 */
+ {
+ .regulators = {},
+ .clock = { "vfe_lite_csid", "vfe_lite_cphy_rx" },
+ .clock_rate = { { 400000000, 480000000 },
+ { 400000000, 480000000 } },
+ .reg = { "csid_lite1" },
+ .interrupt = { "csid_lite1" },
+ .csid = {
+ .is_lite = true,
+ .parent_dev_ops = &vfe_parent_dev_ops,
+ .hw_ops = &csid_ops_gen4,
+ .formats = &csid_formats_gen2
+ }
+ }
+};
+
static const struct resources_icc icc_res_kaanapali[] = {
{
.name = "ahb",
@@ -4414,9 +4492,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] 17+ messages in thread
* [PATCH v9 5/5] media: qcom: camss: vfe: Add support for VFE gen4
2025-12-08 12:39 [PATCH v9 0/5] media: qcom: camss: Add Kaanapali support Hangxiang Ma
` (3 preceding siblings ...)
2025-12-08 12:39 ` [PATCH v9 4/5] media: qcom: camss: csid: Add support for CSID gen4 Hangxiang Ma
@ 2025-12-08 12:39 ` Hangxiang Ma
4 siblings, 0 replies; 17+ messages in thread
From: Hangxiang Ma @ 2025-12-08 12:39 UTC (permalink / raw)
To: Loic Poulain, Robert Foss, Andi Shyti, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Todor Tomov,
Vladimir Zapolskiy, Mauro Carvalho Chehab, Bryan O'Donoghue
Cc: linux-arm-msm, devicetree, linux-kernel, linux-media,
Hangxiang Ma, Atiya Kailany
Add Video Front End (VFE) version gen4 as found on the Kaanapali SoC.
The FULL front end modules in Kaanapali camera subsystem are called TFEs
(Thin Front End), however, retaining the name VFE at places to maintain
consistency and avoid unnecessary code changes.
This change limits the VFE output lines to 3 for now as constrained by
the CAMSS driver framework.
Kaanapali architecture requires for the REG_UPDATE and AUP_UPDATE to be
issued after all of the CSID configuration has been done. Additionally,
the number of AUP_UPDATEs should match the number of buffers enqueued to
the write master while it's being enabled.
Although the real time data from TFE goes through the RT_CAMNOC, we are
required to enable both the camnoc_rt_axi and camnoc_nrt_axi clocks for
the PDX_NOC, that follows both the RT and NRT NOCs in this architecture,
to ensure that both of the latter are idle after reset.
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 | 3 +-
drivers/media/platform/qcom/camss/camss-vfe-gen4.c | 197 +++++++++++++++++++++
drivers/media/platform/qcom/camss/camss-vfe.c | 9 +-
drivers/media/platform/qcom/camss/camss-vfe.h | 2 +
drivers/media/platform/qcom/camss/camss.c | 143 +++++++++++++++
5 files changed, 351 insertions(+), 3 deletions(-)
diff --git a/drivers/media/platform/qcom/camss/Makefile b/drivers/media/platform/qcom/camss/Makefile
index 738d57214056..985464295b3f 100644
--- a/drivers/media/platform/qcom/camss/Makefile
+++ b/drivers/media/platform/qcom/camss/Makefile
@@ -22,8 +22,9 @@ qcom-camss-objs += \
camss-vfe-340.o \
camss-vfe-480.o \
camss-vfe-680.o \
- camss-vfe-gen3.o \
camss-vfe-gen1.o \
+ camss-vfe-gen3.o \
+ camss-vfe-gen4.o \
camss-vfe.o \
camss-video.o \
camss-format.o \
diff --git a/drivers/media/platform/qcom/camss/camss-vfe-gen4.c b/drivers/media/platform/qcom/camss/camss-vfe-gen4.c
new file mode 100644
index 000000000000..d73d70898710
--- /dev/null
+++ b/drivers/media/platform/qcom/camss/camss-vfe-gen4.c
@@ -0,0 +1,197 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * camss-vfe-gen4.c
+ *
+ * Qualcomm MSM Camera Subsystem - VFE (Video Front End) Module gen4
+ *
+ * Copyright (c) Qualcomm Technologies, Inc. and/or its subsidiaries.
+ */
+#include <linux/interrupt.h>
+#include <linux/io.h>
+#include <linux/iopoll.h>
+
+#include "camss.h"
+#include "camss-vfe.h"
+
+/* VFE-gen4 Bus Register Base Addresses */
+#define BUS_REG_BASE (vfe_is_lite(vfe) ? 0x800 : 0x1000)
+
+#define VFE_BUS_WM_CGC_OVERRIDE (BUS_REG_BASE + 0x08)
+#define WM_CGC_OVERRIDE_ALL (0x7FFFFFF)
+
+#define VFE_BUS_WM_TEST_BUS_CTRL (BUS_REG_BASE + 0x128)
+
+#define VFE_BUS_WM_CFG(n) (BUS_REG_BASE + 0x500 + (n) * 0x100)
+#define WM_CFG_EN BIT(0)
+#define WM_VIR_FRM_EN BIT(1)
+#define WM_CFG_MODE BIT(16)
+#define VFE_BUS_WM_IMAGE_ADDR(n) (BUS_REG_BASE + 0x504 + (n) * 0x100)
+#define VFE_BUS_WM_FRAME_INCR(n) (BUS_REG_BASE + 0x508 + (n) * 0x100)
+#define VFE_BUS_WM_IMAGE_CFG_0(n) (BUS_REG_BASE + 0x50C + (n) * 0x100)
+#define WM_IMAGE_CFG_0_DEFAULT_WIDTH (0xFFFF)
+#define VFE_BUS_WM_IMAGE_CFG_2(n) (BUS_REG_BASE + 0x514 + (n) * 0x100)
+#define WM_IMAGE_CFG_2_DEFAULT_STRIDE (0xFFFF)
+#define VFE_BUS_WM_PACKER_CFG(n) (BUS_REG_BASE + 0x518 + (n) * 0x100)
+
+#define VFE_BUS_WM_IRQ_SUBSAMPLE_PERIOD(n) (BUS_REG_BASE + 0x530 + (n) * 0x100)
+#define VFE_BUS_WM_IRQ_SUBSAMPLE_PATTERN(n) (BUS_REG_BASE + 0x534 + (n) * 0x100)
+
+/* VFE lite has no such registers */
+#define VFE_BUS_WM_FRAMEDROP_PERIOD(n) (BUS_REG_BASE + 0x538 + (n) * 0x100)
+#define VFE_BUS_WM_FRAMEDROP_PATTERN(n) (BUS_REG_BASE + 0x53C + (n) * 0x100)
+
+#define VFE_BUS_WM_MMU_PREFETCH_CFG(n) (BUS_REG_BASE + 0x560 + (n) * 0x100)
+#define VFE_BUS_WM_MMU_PREFETCH_MAX_OFFSET(n) (BUS_REG_BASE + 0x564 + (n) * 0x100)
+
+/*
+ * IFE write master client IDs
+ *
+ * VIDEO_FULL 0
+ * VIDEO_DC4_Y 1
+ * VIDEO_DC4_C 2
+ * VIDEO_DC16_Y 3
+ * VIDEO_DC16_C 4
+ * DISPLAY_DS2_Y 5
+ * DISPLAY_DS2_C 6
+ * FD_Y 7
+ * FD_C 8
+ * PIXEL_RAW 9
+ * STATS_AEC_BG 10
+ * STATS_AEC_BHIST 11
+ * STATS_TINTLESS_BG 12
+ * STATS_AWB_BG 13
+ * STATS_AWB_BFW 14
+ * STATS_AF_BHIST 15
+ * STATS_ALSC_BG 16
+ * STATS_FLICKER_BAYERRS 17
+ * STATS_TMC_BHIST 18
+ * PDAF_0 19
+ * PDAF_1 20
+ * PDAF_2 21
+ * PDAF_3 22
+ * RDI0 23
+ * RDI1 24
+ * RDI2 25
+ * RDI3 26
+ * RDI4 27
+ *
+ * IFE Lite write master client IDs
+ *
+ * RDI0 0
+ * RDI1 1
+ * RDI2 2
+ * RDI3 3
+ * GAMMA 4
+ * STATES_BE 5
+ */
+#define RDI_WM(n) ((vfe_is_lite(vfe) ? 0x0 : 0x17) + (n))
+
+static void vfe_wm_start(struct vfe_device *vfe, u8 wm, struct vfe_line *line)
+{
+ struct v4l2_pix_format_mplane *pix =
+ &line->video_out.active_fmt.fmt.pix_mp;
+
+ wm = RDI_WM(wm);
+
+ /* no clock gating at bus input */
+ writel(WM_CGC_OVERRIDE_ALL, vfe->base + VFE_BUS_WM_CGC_OVERRIDE);
+
+ writel(0x0, vfe->base + VFE_BUS_WM_TEST_BUS_CTRL);
+
+ writel(ALIGN(pix->plane_fmt[0].bytesperline, 16) * pix->height >> 8,
+ vfe->base + VFE_BUS_WM_FRAME_INCR(wm));
+ writel((WM_IMAGE_CFG_0_DEFAULT_WIDTH & 0xFFFF),
+ vfe->base + VFE_BUS_WM_IMAGE_CFG_0(wm));
+ writel(WM_IMAGE_CFG_2_DEFAULT_STRIDE,
+ vfe->base + VFE_BUS_WM_IMAGE_CFG_2(wm));
+ writel(0, vfe->base + VFE_BUS_WM_PACKER_CFG(wm));
+
+ /* no dropped frames, one irq per frame */
+ if (!vfe_is_lite(vfe)) {
+ writel(0, vfe->base + VFE_BUS_WM_FRAMEDROP_PERIOD(wm));
+ writel(1, vfe->base + VFE_BUS_WM_FRAMEDROP_PATTERN(wm));
+ }
+
+ writel(0, vfe->base + VFE_BUS_WM_IRQ_SUBSAMPLE_PERIOD(wm));
+ writel(1, vfe->base + VFE_BUS_WM_IRQ_SUBSAMPLE_PATTERN(wm));
+
+ writel(1, vfe->base + VFE_BUS_WM_MMU_PREFETCH_CFG(wm));
+ writel(0xFFFFFFFF, vfe->base + VFE_BUS_WM_MMU_PREFETCH_MAX_OFFSET(wm));
+
+ writel(WM_CFG_EN | WM_CFG_MODE, vfe->base + VFE_BUS_WM_CFG(wm));
+}
+
+static void vfe_wm_stop(struct vfe_device *vfe, u8 wm)
+{
+ wm = RDI_WM(wm);
+ writel(0, vfe->base + VFE_BUS_WM_CFG(wm));
+}
+
+static void vfe_wm_update(struct vfe_device *vfe, u8 wm, u32 addr,
+ struct vfe_line *line)
+{
+ wm = RDI_WM(wm);
+ writel(addr >> 8, vfe->base + VFE_BUS_WM_IMAGE_ADDR(wm));
+
+ dev_dbg(vfe->camss->dev, "wm:%d, image buf addr:0x%x\n", wm, addr);
+}
+
+static void vfe_reg_update(struct vfe_device *vfe, enum vfe_line_id line_id)
+{
+ int port_id = line_id;
+
+ camss_reg_update(vfe->camss, vfe->id, port_id, false);
+}
+
+static inline void vfe_reg_update_clear(struct vfe_device *vfe,
+ enum vfe_line_id line_id)
+{
+ int port_id = line_id;
+
+ camss_reg_update(vfe->camss, vfe->id, port_id, true);
+}
+
+static const struct camss_video_ops vfe_video_ops_gen4 = {
+ .queue_buffer = vfe_queue_buffer_v2,
+ .flush_buffers = vfe_flush_buffers,
+};
+
+static void vfe_subdev_init(struct device *dev, struct vfe_device *vfe)
+{
+ vfe->video_ops = vfe_video_ops_gen4;
+}
+
+static void vfe_global_reset(struct vfe_device *vfe)
+{
+ vfe_isr_reset_ack(vfe);
+}
+
+static irqreturn_t vfe_isr(int irq, void *dev)
+{
+ /* nop */
+ return IRQ_HANDLED;
+}
+
+static int vfe_halt(struct vfe_device *vfe)
+{
+ /* rely on vfe_disable_output() to stop the VFE */
+ return 0;
+}
+
+const struct vfe_hw_ops vfe_ops_gen4 = {
+ .global_reset = vfe_global_reset,
+ .hw_version = vfe_hw_version,
+ .isr = vfe_isr,
+ .pm_domain_off = vfe_pm_domain_off,
+ .pm_domain_on = vfe_pm_domain_on,
+ .reg_update = vfe_reg_update,
+ .reg_update_clear = vfe_reg_update_clear,
+ .subdev_init = vfe_subdev_init,
+ .vfe_disable = vfe_disable,
+ .vfe_enable = vfe_enable_v2,
+ .vfe_halt = vfe_halt,
+ .vfe_wm_start = vfe_wm_start,
+ .vfe_wm_stop = vfe_wm_stop,
+ .vfe_buf_done = vfe_buf_done,
+ .vfe_wm_update = vfe_wm_update,
+};
diff --git a/drivers/media/platform/qcom/camss/camss-vfe.c b/drivers/media/platform/qcom/camss/camss-vfe.c
index 2753c2bb6c04..fd03e4fb5b5a 100644
--- a/drivers/media/platform/qcom/camss/camss-vfe.c
+++ b/drivers/media/platform/qcom/camss/camss-vfe.c
@@ -349,6 +349,7 @@ static u32 vfe_src_pad_code(struct vfe_line *line, u32 sink_code,
case CAMSS_845:
case CAMSS_8550:
case CAMSS_8775P:
+ case CAMSS_KAANAPALI:
case CAMSS_X1E80100:
switch (sink_code) {
case MEDIA_BUS_FMT_YUYV8_1X16:
@@ -521,7 +522,8 @@ int vfe_enable_output_v2(struct vfe_line *line)
spin_lock_irqsave(&vfe->output_lock, flags);
- ops->reg_update_clear(vfe, line->id);
+ if (ops->reg_update_clear)
+ ops->reg_update_clear(vfe, line->id);
if (output->state > VFE_OUTPUT_RESERVED) {
dev_err(vfe->camss->dev,
@@ -548,7 +550,9 @@ int vfe_enable_output_v2(struct vfe_line *line)
output->gen2.active_num++;
ops->vfe_wm_update(vfe, output->wm_idx[0],
output->buf[i]->addr[0], line);
- ops->reg_update(vfe, line->id);
+
+ if (!vfe->res->reg_update_after_csid_config)
+ ops->reg_update(vfe, line->id);
}
spin_unlock_irqrestore(&vfe->output_lock, flags);
@@ -1998,6 +2002,7 @@ static int vfe_bpl_align(struct vfe_device *vfe)
case CAMSS_845:
case CAMSS_8550:
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 0300efdb1c46..30c0c560fc5a 100644
--- a/drivers/media/platform/qcom/camss/camss-vfe.h
+++ b/drivers/media/platform/qcom/camss/camss-vfe.h
@@ -133,6 +133,7 @@ struct vfe_isr_ops {
struct vfe_subdev_resources {
bool is_lite;
+ bool reg_update_after_csid_config;
u8 line_num;
bool has_pd;
char *pd_name;
@@ -246,6 +247,7 @@ extern const struct vfe_hw_ops vfe_ops_340;
extern const struct vfe_hw_ops vfe_ops_480;
extern const struct vfe_hw_ops vfe_ops_680;
extern const struct vfe_hw_ops vfe_ops_gen3;
+extern const struct vfe_hw_ops vfe_ops_gen4;
int vfe_get(struct vfe_device *vfe);
void vfe_put(struct vfe_device *vfe);
diff --git a/drivers/media/platform/qcom/camss/camss.c b/drivers/media/platform/qcom/camss/camss.c
index a1c2dacd5e5f..c23c37cedc1c 100644
--- a/drivers/media/platform/qcom/camss/camss.c
+++ b/drivers/media/platform/qcom/camss/camss.c
@@ -217,6 +217,147 @@ static const struct camss_subdev_resources csid_res_kaanapali[] = {
}
};
+/* In Kaanapali, CAMNOC requires all CAMNOC_RT_TFEX clocks
+ * to operate on any TFE Full.
+ */
+static const struct camss_subdev_resources vfe_res_kaanapali[] = {
+ /* VFE0 - TFE Full */
+ {
+ .regulators = {},
+ .clock = { "gcc_axi_hf", "vfe0_fast_ahb", "vfe0",
+ "camnoc_rt_vfe0", "camnoc_rt_vfe1", "camnoc_rt_vfe2",
+ "camnoc_rt_axi", "camnoc_nrt_axi", "qdss_debug_xo" },
+ .clock_rate = { { 0 },
+ { 0 },
+ { 360280000, 480000000, 630000000, 716000000,
+ 833000000 },
+ { 0 },
+ { 0 },
+ { 0 },
+ { 200000000, 300000000, 400000000, 480000000 },
+ { 0 },
+ { 0 } },
+ .reg = { "vfe0" },
+ .interrupt = { "vfe0" },
+ .vfe = {
+ .line_num = 3,
+ .is_lite = false,
+ .reg_update_after_csid_config = true,
+ .has_pd = true,
+ .pd_name = "vfe0",
+ .hw_ops = &vfe_ops_gen4,
+ .formats_rdi = &vfe_formats_rdi_845,
+ .formats_pix = &vfe_formats_pix_845
+ }
+ },
+ /* VFE1 - TFE Full */
+ {
+ .regulators = {},
+ .clock = { "gcc_axi_hf", "vfe1_fast_ahb", "vfe1",
+ "camnoc_rt_vfe0", "camnoc_rt_vfe1", "camnoc_rt_vfe2",
+ "camnoc_rt_axi", "camnoc_nrt_axi", "qdss_debug_xo" },
+ .clock_rate = { { 0 },
+ { 0 },
+ { 360280000, 480000000, 630000000, 716000000,
+ 833000000 },
+ { 0 },
+ { 0 },
+ { 0 },
+ { 200000000, 300000000, 400000000, 480000000 },
+ { 0 },
+ { 0 } },
+ .reg = { "vfe1" },
+ .interrupt = { "vfe1" },
+ .vfe = {
+ .line_num = 3,
+ .is_lite = false,
+ .reg_update_after_csid_config = true,
+ .has_pd = true,
+ .pd_name = "vfe1",
+ .hw_ops = &vfe_ops_gen4,
+ .formats_rdi = &vfe_formats_rdi_845,
+ .formats_pix = &vfe_formats_pix_845
+ }
+ },
+ /* VFE2 - TFE Full */
+ {
+ .regulators = {},
+ .clock = { "gcc_axi_hf", "vfe2_fast_ahb", "vfe2",
+ "camnoc_rt_vfe0", "camnoc_rt_vfe1", "camnoc_rt_vfe2",
+ "camnoc_rt_axi", "camnoc_nrt_axi", "qdss_debug_xo" },
+ .clock_rate = { { 0 },
+ { 0 },
+ { 360280000, 480000000, 630000000, 716000000,
+ 833000000 },
+ { 0 },
+ { 0 },
+ { 0 },
+ { 200000000, 300000000, 400000000, 480000000 },
+ { 0 },
+ { 0 } },
+ .reg = { "vfe2" },
+ .interrupt = { "vfe2" },
+ .vfe = {
+ .line_num = 3,
+ .is_lite = false,
+ .reg_update_after_csid_config = true,
+ .has_pd = true,
+ .pd_name = "vfe2",
+ .hw_ops = &vfe_ops_gen4,
+ .formats_rdi = &vfe_formats_rdi_845,
+ .formats_pix = &vfe_formats_pix_845
+ }
+ },
+ /* VFE3 - IFE Lite */
+ {
+ .regulators = {},
+ .clock = { "gcc_axi_hf", "vfe_lite_ahb", "vfe_lite",
+ "camnoc_rt_vfe_lite", "camnoc_rt_axi",
+ "camnoc_nrt_axi", "qdss_debug_xo" },
+ .clock_rate = { { 0 },
+ { 0 },
+ { 266666667, 400000000, 480000000 },
+ { 0 },
+ { 200000000, 300000000, 400000000, 480000000 },
+ { 0 },
+ { 0 } },
+ .reg = { "vfe_lite0" },
+ .interrupt = { "vfe_lite0" },
+ .vfe = {
+ .line_num = 4,
+ .is_lite = true,
+ .reg_update_after_csid_config = true,
+ .hw_ops = &vfe_ops_gen4,
+ .formats_rdi = &vfe_formats_rdi_845,
+ .formats_pix = &vfe_formats_pix_845
+ }
+ },
+ /* VFE4 - IFE Lite */
+ {
+ .regulators = {},
+ .clock = { "gcc_axi_hf", "vfe_lite_ahb", "vfe_lite",
+ "camnoc_rt_vfe_lite", "camnoc_rt_axi",
+ "camnoc_nrt_axi", "qdss_debug_xo" },
+ .clock_rate = { { 0 },
+ { 0 },
+ { 266666667, 400000000, 480000000 },
+ { 0 },
+ { 200000000, 300000000, 400000000, 480000000 },
+ { 0 },
+ { 0 } },
+ .reg = { "vfe_lite1" },
+ .interrupt = { "vfe_lite1" },
+ .vfe = {
+ .line_num = 4,
+ .is_lite = true,
+ .reg_update_after_csid_config = true,
+ .hw_ops = &vfe_ops_gen4,
+ .formats_rdi = &vfe_formats_rdi_845,
+ .formats_pix = &vfe_formats_pix_845
+ }
+ },
+};
+
static const struct resources_icc icc_res_kaanapali[] = {
{
.name = "ahb",
@@ -4493,10 +4634,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] 17+ messages in thread
* Re: [PATCH v9 1/5] media: dt-bindings: Add CAMSS device for Kaanapali
2025-12-08 12:39 ` [PATCH v9 1/5] media: dt-bindings: Add CAMSS device for Kaanapali Hangxiang Ma
@ 2025-12-08 19:53 ` Dmitry Baryshkov
2025-12-08 21:03 ` Vijay Kumar Tumati
0 siblings, 1 reply; 17+ messages in thread
From: Dmitry Baryshkov @ 2025-12-08 19:53 UTC (permalink / raw)
To: Hangxiang Ma
Cc: Loic Poulain, Robert Foss, Andi Shyti, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Todor Tomov,
Vladimir Zapolskiy, Mauro Carvalho Chehab, Bryan O'Donoghue,
linux-arm-msm, devicetree, linux-kernel, linux-media,
Krzysztof Kozlowski
On Mon, Dec 08, 2025 at 04:39:47AM -0800, Hangxiang Ma wrote:
> Add bindings for qcom,kaanapali-camss to support the Camera Subsystem
> (CAMSS) on the Qualcomm Kaanapali platform.
>
> The Kaanapali platform provides:
>
> - 3 x VFE, 5 RDI per VFE
> - 2 x VFE Lite, 4 RDI per VFE Lite
> - 3 x CSID
> - 2 x CSID Lite
> - 6 x CSIPHY
> - 2 x ICP
> - 1 x IPE
> - 2 x JPEG DMA & Downscaler
> - 2 x JPEG Encoder
> - 1 x OFE
> - 5 x RT CDM
> - 3 x TPG
Please describe the acronyms.
>
> Reviewed-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
> Reviewed-by: Krzysztof Kozlowski <krzk@kernel.org>
> Signed-off-by: Hangxiang Ma <hangxiang.ma@oss.qualcomm.com>
> ---
> .../bindings/media/qcom,kaanapali-camss.yaml | 646 +++++++++++++++++++++
> 1 file changed, 646 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..3b54620e14c6
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/media/qcom,kaanapali-camss.yaml
> @@ -0,0 +1,646 @@
> +# 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:
> + Kaanapali camera subsystem includes submodules such as CSIPHY (CSI Physical layer)
> + and CSID (CSI Decoder), which comply with the MIPI CSI2 protocol.
> +
> + The subsystem also integrates a set of real-time image processing engines and their
> + associated configuration modules, as well as non-real-time engines.
> +
> + Additionally, it encompasses a test pattern generator (TPG) submodule.
> +
> +properties:
> + compatible:
> + const: qcom,kaanapali-camss
> +
> + reg:
> + items:
> + - description: Registers for CSID 0
> + - description: Registers for CSID 1
> + - description: Registers for CSID 2
> + - description: Registers for CSID Lite 0
> + - description: Registers for CSID Lite 1
> + - description: Registers for CSIPHY 0
> + - description: Registers for CSIPHY 1
> + - description: Registers for CSIPHY 2
> + - description: Registers for CSIPHY 3
> + - description: Registers for CSIPHY 4
> + - description: Registers for CSIPHY 5
> + - description: Registers for VFE (Video Front End) 0
> + - description: Registers for VFE 1
> + - description: Registers for VFE 2
> + - description: Registers for VFE Lite 0
> + - description: Registers for VFE Lite 1
> + - description: Registers for ICP (Imaging Control Processor) 0
> + - description: Registers for ICP 0 SYS
> + - description: Registers for ICP 1
> + - description: Registers for ICP 1 SYS
> + - description: Registers for IPE (Image Processing Engine)
> + - description: Registers for JPEG DMA & Downscaler
> + - description: Registers for JPEG Encoder
> + - description: Registers for OFE (Offline Front End)
> + - description: Registers for RT CDM (Camera Data Mover) 0
> + - description: Registers for RT CDM 1
> + - description: Registers for RT CDM 2
> + - description: Registers for RT CDM 3
> + - description: Registers for RT CDM 4
> + - description: Registers for TPG 0
> + - description: Registers for TPG 1
> + - description: Registers for TPG 2
> +
> + reg-names:
> + items:
> + - const: csid0
> + - const: csid1
> + - const: csid2
> + - const: csid_lite0
> + - const: csid_lite1
> + - const: csiphy0
> + - const: csiphy1
> + - const: csiphy2
> + - const: csiphy3
> + - const: csiphy4
> + - const: csiphy5
> + - const: vfe0
> + - const: vfe1
> + - const: vfe2
> + - const: vfe_lite0
> + - const: vfe_lite1
> + - const: icp0
> + - const: icp0_sys
> + - const: icp1
> + - const: icp1_sys
> + - const: ipe
> + - const: jpeg_dma
> + - const: jpeg_enc
> + - const: ofe
> + - const: rt_cdm0
> + - const: rt_cdm1
> + - const: rt_cdm2
> + - const: rt_cdm3
> + - const: rt_cdm4
> + - const: tpg0
> + - const: tpg1
> + - const: tpg2
> +
> + clocks:
> + maxItems: 60
> +
> + clock-names:
> + items:
> + - const: camnoc_nrt_axi
> + - const: camnoc_rt_axi
> + - const: camnoc_rt_vfe0
> + - const: camnoc_rt_vfe1
> + - const: camnoc_rt_vfe2
> + - const: camnoc_rt_vfe_lite
> + - const: cpas_ahb
> + - const: cpas_fast_ahb
> + - const: csid
> + - const: csid_csiphy_rx
> + - const: csiphy0
> + - const: csiphy0_timer
> + - const: csiphy1
> + - const: csiphy1_timer
> + - const: csiphy2
> + - const: csiphy2_timer
> + - const: csiphy3
> + - const: csiphy3_timer
> + - const: csiphy4
> + - const: csiphy4_timer
> + - const: csiphy5
> + - const: csiphy5_timer
> + - const: gcc_axi_hf
This clock (and gcc_axi_sf below) still have the gcc_ prefix and GCC name. Why?
It was pointed out in the previous review: clock names should be
describing their purpose, not their source.
> + - 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
> + - const: camnoc_ipe_nps
> + - const: camnoc_ofe
> + - const: gcc_axi_sf
> + - const: icp0
> + - const: icp0_ahb
> + - const: icp1
> + - const: icp1_ahb
> + - const: ipe_nps
> + - const: ipe_nps_ahb
> + - const: ipe_nps_fast_ahb
> + - const: ipe_pps
> + - const: ipe_pps_fast_ahb
> + - const: jpeg
> + - const: ofe_ahb
> + - const: ofe_anchor
> + - const: ofe_anchor_fast_ahb
> + - const: ofe_hdr
> + - const: ofe_hdr_fast_ahb
> + - const: ofe_main
> + - const: ofe_main_fast_ahb
> + - const: vfe0_bayer
> + - const: vfe0_bayer_fast_ahb
> + - const: vfe1_bayer
> + - const: vfe1_bayer_fast_ahb
> + - const: vfe2_bayer
> + - const: vfe2_bayer_fast_ahb
> +
> + interrupts:
> + maxItems: 30
> +
> + interrupt-names:
> + items:
> + - const: csid0
> + - const: csid1
> + - const: csid2
> + - const: csid_lite0
> + - const: csid_lite1
> + - const: csiphy0
> + - const: csiphy1
> + - const: csiphy2
> + - const: csiphy3
> + - const: csiphy4
> + - const: csiphy5
> + - const: vfe0
> + - const: vfe1
> + - const: vfe2
> + - const: vfe_lite0
> + - const: vfe_lite1
> + - const: camnoc_nrt
> + - const: camnoc_rt
> + - const: icp0
> + - const: icp1
> + - const: jpeg_dma
> + - const: jpeg_enc
> + - const: rt_cdm0
> + - const: rt_cdm1
> + - const: rt_cdm2
> + - const: rt_cdm3
> + - const: rt_cdm4
> + - const: tpg0
> + - const: tpg1
> + - const: tpg2
> +
> + interconnects:
> + maxItems: 4
> +
> + interconnect-names:
> + items:
> + - const: ahb
> + - const: hf_mnoc
> + - const: sf_icp_mnoc
> + - const: sf_mnoc
You know... Failure to look around is a sin. What are the names of
interconnects used by other devices? What do they actually describe?
This is an absolute NAK.
> +
> + iommus:
> + items:
> + - description: VFE non-protected stream
> + - description: ICP0 shared stream
> + - description: ICP1 shared stream
> + - description: IPE CDM non-protected stream
> + - description: IPE non-protected stream
> + - description: JPEG non-protected stream
> + - description: OFE CDM non-protected stream
> + - description: OFE non-protected stream
> + - description: VFE / VFE Lite CDM non-protected stream
This will map all IOMMUs to the same domain. Are you sure that this is
what we want? Or do we wait for iommu-maps to be fixed?
--
With best wishes
Dmitry
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH v9 1/5] media: dt-bindings: Add CAMSS device for Kaanapali
2025-12-08 19:53 ` Dmitry Baryshkov
@ 2025-12-08 21:03 ` Vijay Kumar Tumati
2025-12-08 22:48 ` Dmitry Baryshkov
0 siblings, 1 reply; 17+ messages in thread
From: Vijay Kumar Tumati @ 2025-12-08 21:03 UTC (permalink / raw)
To: Dmitry Baryshkov, Hangxiang Ma
Cc: Loic Poulain, Robert Foss, Andi Shyti, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Todor Tomov,
Vladimir Zapolskiy, Mauro Carvalho Chehab, Bryan O'Donoghue,
linux-arm-msm, devicetree, linux-kernel, linux-media,
Krzysztof Kozlowski
On 12/8/2025 11:53 AM, Dmitry Baryshkov wrote:
> On Mon, Dec 08, 2025 at 04:39:47AM -0800, Hangxiang Ma wrote:
>> Add bindings for qcom,kaanapali-camss to support the Camera Subsystem
>> (CAMSS) on the Qualcomm Kaanapali platform.
>>
>> The Kaanapali platform provides:
>>
>> - 3 x VFE, 5 RDI per VFE
>> - 2 x VFE Lite, 4 RDI per VFE Lite
>> - 3 x CSID
>> - 2 x CSID Lite
>> - 6 x CSIPHY
>> - 2 x ICP
>> - 1 x IPE
>> - 2 x JPEG DMA & Downscaler
>> - 2 x JPEG Encoder
>> - 1 x OFE
>> - 5 x RT CDM
>> - 3 x TPG
> Please describe the acronyms.
Ack.
>> Reviewed-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
>> Reviewed-by: Krzysztof Kozlowski <krzk@kernel.org>
>> Signed-off-by: Hangxiang Ma <hangxiang.ma@oss.qualcomm.com>
>> ---
>> .../bindings/media/qcom,kaanapali-camss.yaml | 646 +++++++++++++++++++++
>> 1 file changed, 646 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..3b54620e14c6
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/media/qcom,kaanapali-camss.yaml
>> @@ -0,0 +1,646 @@
>> +# 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:
>> + Kaanapali camera subsystem includes submodules such as CSIPHY (CSI Physical layer)
>> + and CSID (CSI Decoder), which comply with the MIPI CSI2 protocol.
>> +
>> + The subsystem also integrates a set of real-time image processing engines and their
>> + associated configuration modules, as well as non-real-time engines.
>> +
>> + Additionally, it encompasses a test pattern generator (TPG) submodule.
>> +
>> +properties:
>> + compatible:
>> + const: qcom,kaanapali-camss
>> +
>> + reg:
>> + items:
>> + - description: Registers for CSID 0
>> + - description: Registers for CSID 1
>> + - description: Registers for CSID 2
>> + - description: Registers for CSID Lite 0
>> + - description: Registers for CSID Lite 1
>> + - description: Registers for CSIPHY 0
>> + - description: Registers for CSIPHY 1
>> + - description: Registers for CSIPHY 2
>> + - description: Registers for CSIPHY 3
>> + - description: Registers for CSIPHY 4
>> + - description: Registers for CSIPHY 5
>> + - description: Registers for VFE (Video Front End) 0
>> + - description: Registers for VFE 1
>> + - description: Registers for VFE 2
>> + - description: Registers for VFE Lite 0
>> + - description: Registers for VFE Lite 1
>> + - description: Registers for ICP (Imaging Control Processor) 0
>> + - description: Registers for ICP 0 SYS
>> + - description: Registers for ICP 1
>> + - description: Registers for ICP 1 SYS
>> + - description: Registers for IPE (Image Processing Engine)
>> + - description: Registers for JPEG DMA & Downscaler
>> + - description: Registers for JPEG Encoder
>> + - description: Registers for OFE (Offline Front End)
>> + - description: Registers for RT CDM (Camera Data Mover) 0
>> + - description: Registers for RT CDM 1
>> + - description: Registers for RT CDM 2
>> + - description: Registers for RT CDM 3
>> + - description: Registers for RT CDM 4
>> + - description: Registers for TPG 0
>> + - description: Registers for TPG 1
>> + - description: Registers for TPG 2
>> +
>> + reg-names:
>> + items:
>> + - const: csid0
>> + - const: csid1
>> + - const: csid2
>> + - const: csid_lite0
>> + - const: csid_lite1
>> + - const: csiphy0
>> + - const: csiphy1
>> + - const: csiphy2
>> + - const: csiphy3
>> + - const: csiphy4
>> + - const: csiphy5
>> + - const: vfe0
>> + - const: vfe1
>> + - const: vfe2
>> + - const: vfe_lite0
>> + - const: vfe_lite1
>> + - const: icp0
>> + - const: icp0_sys
>> + - const: icp1
>> + - const: icp1_sys
>> + - const: ipe
>> + - const: jpeg_dma
>> + - const: jpeg_enc
>> + - const: ofe
>> + - const: rt_cdm0
>> + - const: rt_cdm1
>> + - const: rt_cdm2
>> + - const: rt_cdm3
>> + - const: rt_cdm4
>> + - const: tpg0
>> + - const: tpg1
>> + - const: tpg2
>> +
>> + clocks:
>> + maxItems: 60
>> +
>> + clock-names:
>> + items:
>> + - const: camnoc_nrt_axi
>> + - const: camnoc_rt_axi
>> + - const: camnoc_rt_vfe0
>> + - const: camnoc_rt_vfe1
>> + - const: camnoc_rt_vfe2
>> + - const: camnoc_rt_vfe_lite
>> + - const: cpas_ahb
>> + - const: cpas_fast_ahb
>> + - const: csid
>> + - const: csid_csiphy_rx
>> + - const: csiphy0
>> + - const: csiphy0_timer
>> + - const: csiphy1
>> + - const: csiphy1_timer
>> + - const: csiphy2
>> + - const: csiphy2_timer
>> + - const: csiphy3
>> + - const: csiphy3_timer
>> + - const: csiphy4
>> + - const: csiphy4_timer
>> + - const: csiphy5
>> + - const: csiphy5_timer
>> + - const: gcc_axi_hf
> This clock (and gcc_axi_sf below) still have the gcc_ prefix and GCC name. Why?
> It was pointed out in the previous review: clock names should be
> describing their purpose, not their source.
Hi Dmitry, let me add a bit more detail on this clock. As confirmed by
the HW team, the logic that runs based on this clock is still inside the
CAMNOC_PDX, just that it is on the CX / MMNOC domain side. Do you think
"axi_hf_cx" and "axi_sf_cx" makes sense?
>> + - 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
>> + - const: camnoc_ipe_nps
>> + - const: camnoc_ofe
>> + - const: gcc_axi_sf
>> + - const: icp0
>> + - const: icp0_ahb
>> + - const: icp1
>> + - const: icp1_ahb
>> + - const: ipe_nps
>> + - const: ipe_nps_ahb
>> + - const: ipe_nps_fast_ahb
>> + - const: ipe_pps
>> + - const: ipe_pps_fast_ahb
>> + - const: jpeg
>> + - const: ofe_ahb
>> + - const: ofe_anchor
>> + - const: ofe_anchor_fast_ahb
>> + - const: ofe_hdr
>> + - const: ofe_hdr_fast_ahb
>> + - const: ofe_main
>> + - const: ofe_main_fast_ahb
>> + - const: vfe0_bayer
>> + - const: vfe0_bayer_fast_ahb
>> + - const: vfe1_bayer
>> + - const: vfe1_bayer_fast_ahb
>> + - const: vfe2_bayer
>> + - const: vfe2_bayer_fast_ahb
>> +
>> + interrupts:
>> + maxItems: 30
>> +
>> + interrupt-names:
>> + items:
>> + - const: csid0
>> + - const: csid1
>> + - const: csid2
>> + - const: csid_lite0
>> + - const: csid_lite1
>> + - const: csiphy0
>> + - const: csiphy1
>> + - const: csiphy2
>> + - const: csiphy3
>> + - const: csiphy4
>> + - const: csiphy5
>> + - const: vfe0
>> + - const: vfe1
>> + - const: vfe2
>> + - const: vfe_lite0
>> + - const: vfe_lite1
>> + - const: camnoc_nrt
>> + - const: camnoc_rt
>> + - const: icp0
>> + - const: icp1
>> + - const: jpeg_dma
>> + - const: jpeg_enc
>> + - const: rt_cdm0
>> + - const: rt_cdm1
>> + - const: rt_cdm2
>> + - const: rt_cdm3
>> + - const: rt_cdm4
>> + - const: tpg0
>> + - const: tpg1
>> + - const: tpg2
>> +
>> + interconnects:
>> + maxItems: 4
>> +
>> + interconnect-names:
>> + items:
>> + - const: ahb
>> + - const: hf_mnoc
>> + - const: sf_icp_mnoc
>> + - const: sf_mnoc
> You know... Failure to look around is a sin. What are the names of
> interconnects used by other devices? What do they actually describe?
>
> This is an absolute NAK.
Please feel free to correct me here but, a couple things.
1. This is consistent with
Documentation/devicetree/bindings/media/qcom,qcm2290-camss.yaml. no?
2. If you are referring to some other targets that use, "cam_" prefix,
we may not need that , isn't it? If we look at these interconnects from
camera side, as you advised for other things like this?
>
>> +
>> + iommus:
>> + items:
>> + - description: VFE non-protected stream
>> + - description: ICP0 shared stream
>> + - description: ICP1 shared stream
>> + - description: IPE CDM non-protected stream
>> + - description: IPE non-protected stream
>> + - description: JPEG non-protected stream
>> + - description: OFE CDM non-protected stream
>> + - description: OFE non-protected stream
>> + - description: VFE / VFE Lite CDM non-protected stream
> This will map all IOMMUs to the same domain. Are you sure that this is
> what we want? Or do we wait for iommu-maps to be fixed?
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH v9 1/5] media: dt-bindings: Add CAMSS device for Kaanapali
2025-12-08 21:03 ` Vijay Kumar Tumati
@ 2025-12-08 22:48 ` Dmitry Baryshkov
2025-12-08 23:21 ` Vijay Kumar Tumati
0 siblings, 1 reply; 17+ messages in thread
From: Dmitry Baryshkov @ 2025-12-08 22:48 UTC (permalink / raw)
To: Vijay Kumar Tumati
Cc: Hangxiang Ma, Loic Poulain, Robert Foss, Andi Shyti, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Todor Tomov,
Vladimir Zapolskiy, Mauro Carvalho Chehab, Bryan O'Donoghue,
linux-arm-msm, devicetree, linux-kernel, linux-media,
Krzysztof Kozlowski
On Mon, Dec 08, 2025 at 01:03:06PM -0800, Vijay Kumar Tumati wrote:
>
> On 12/8/2025 11:53 AM, Dmitry Baryshkov wrote:
> > On Mon, Dec 08, 2025 at 04:39:47AM -0800, Hangxiang Ma wrote:
> > > Add bindings for qcom,kaanapali-camss to support the Camera Subsystem
> > > (CAMSS) on the Qualcomm Kaanapali platform.
> > >
> > > The Kaanapali platform provides:
> > >
> > > - 3 x VFE, 5 RDI per VFE
> > > - 2 x VFE Lite, 4 RDI per VFE Lite
> > > - 3 x CSID
> > > - 2 x CSID Lite
> > > - 6 x CSIPHY
> > > - 2 x ICP
> > > - 1 x IPE
> > > - 2 x JPEG DMA & Downscaler
> > > - 2 x JPEG Encoder
> > > - 1 x OFE
> > > - 5 x RT CDM
> > > - 3 x TPG
> > Please describe the acronyms.
> Ack.
> > > Reviewed-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
> > > Reviewed-by: Krzysztof Kozlowski <krzk@kernel.org>
> > > Signed-off-by: Hangxiang Ma <hangxiang.ma@oss.qualcomm.com>
> > > ---
> > > .../bindings/media/qcom,kaanapali-camss.yaml | 646 +++++++++++++++++++++
> > > 1 file changed, 646 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..3b54620e14c6
> > > --- /dev/null
> > > +++ b/Documentation/devicetree/bindings/media/qcom,kaanapali-camss.yaml
> > > @@ -0,0 +1,646 @@
> > > +# 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:
> > > + Kaanapali camera subsystem includes submodules such as CSIPHY (CSI Physical layer)
> > > + and CSID (CSI Decoder), which comply with the MIPI CSI2 protocol.
> > > +
> > > + The subsystem also integrates a set of real-time image processing engines and their
> > > + associated configuration modules, as well as non-real-time engines.
> > > +
> > > + Additionally, it encompasses a test pattern generator (TPG) submodule.
> > > +
> > > +properties:
> > > + compatible:
> > > + const: qcom,kaanapali-camss
> > > +
> > > + reg:
> > > + items:
> > > + - description: Registers for CSID 0
> > > + - description: Registers for CSID 1
> > > + - description: Registers for CSID 2
> > > + - description: Registers for CSID Lite 0
> > > + - description: Registers for CSID Lite 1
> > > + - description: Registers for CSIPHY 0
> > > + - description: Registers for CSIPHY 1
> > > + - description: Registers for CSIPHY 2
> > > + - description: Registers for CSIPHY 3
> > > + - description: Registers for CSIPHY 4
> > > + - description: Registers for CSIPHY 5
> > > + - description: Registers for VFE (Video Front End) 0
> > > + - description: Registers for VFE 1
> > > + - description: Registers for VFE 2
> > > + - description: Registers for VFE Lite 0
> > > + - description: Registers for VFE Lite 1
> > > + - description: Registers for ICP (Imaging Control Processor) 0
> > > + - description: Registers for ICP 0 SYS
> > > + - description: Registers for ICP 1
> > > + - description: Registers for ICP 1 SYS
> > > + - description: Registers for IPE (Image Processing Engine)
> > > + - description: Registers for JPEG DMA & Downscaler
> > > + - description: Registers for JPEG Encoder
> > > + - description: Registers for OFE (Offline Front End)
> > > + - description: Registers for RT CDM (Camera Data Mover) 0
> > > + - description: Registers for RT CDM 1
> > > + - description: Registers for RT CDM 2
> > > + - description: Registers for RT CDM 3
> > > + - description: Registers for RT CDM 4
> > > + - description: Registers for TPG 0
> > > + - description: Registers for TPG 1
> > > + - description: Registers for TPG 2
> > > +
> > > + reg-names:
> > > + items:
> > > + - const: csid0
> > > + - const: csid1
> > > + - const: csid2
> > > + - const: csid_lite0
> > > + - const: csid_lite1
> > > + - const: csiphy0
> > > + - const: csiphy1
> > > + - const: csiphy2
> > > + - const: csiphy3
> > > + - const: csiphy4
> > > + - const: csiphy5
> > > + - const: vfe0
> > > + - const: vfe1
> > > + - const: vfe2
> > > + - const: vfe_lite0
> > > + - const: vfe_lite1
> > > + - const: icp0
> > > + - const: icp0_sys
> > > + - const: icp1
> > > + - const: icp1_sys
> > > + - const: ipe
> > > + - const: jpeg_dma
> > > + - const: jpeg_enc
> > > + - const: ofe
> > > + - const: rt_cdm0
> > > + - const: rt_cdm1
> > > + - const: rt_cdm2
> > > + - const: rt_cdm3
> > > + - const: rt_cdm4
> > > + - const: tpg0
> > > + - const: tpg1
> > > + - const: tpg2
> > > +
> > > + clocks:
> > > + maxItems: 60
> > > +
> > > + clock-names:
> > > + items:
> > > + - const: camnoc_nrt_axi
> > > + - const: camnoc_rt_axi
> > > + - const: camnoc_rt_vfe0
> > > + - const: camnoc_rt_vfe1
> > > + - const: camnoc_rt_vfe2
> > > + - const: camnoc_rt_vfe_lite
> > > + - const: cpas_ahb
> > > + - const: cpas_fast_ahb
> > > + - const: csid
> > > + - const: csid_csiphy_rx
> > > + - const: csiphy0
> > > + - const: csiphy0_timer
> > > + - const: csiphy1
> > > + - const: csiphy1_timer
> > > + - const: csiphy2
> > > + - const: csiphy2_timer
> > > + - const: csiphy3
> > > + - const: csiphy3_timer
> > > + - const: csiphy4
> > > + - const: csiphy4_timer
> > > + - const: csiphy5
> > > + - const: csiphy5_timer
> > > + - const: gcc_axi_hf
> > This clock (and gcc_axi_sf below) still have the gcc_ prefix and GCC name. Why?
> > It was pointed out in the previous review: clock names should be
> > describing their purpose, not their source.
> Hi Dmitry, let me add a bit more detail on this clock. As confirmed by the
> HW team, the logic that runs based on this clock is still inside the
> CAMNOC_PDX, just that it is on the CX / MMNOC domain side. Do you think
> "axi_hf_cx" and "axi_sf_cx" makes sense?
Why? You are again describing the source. What is the function of?
bus_hf / bus_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
> > > + - const: camnoc_ipe_nps
> > > + - const: camnoc_ofe
> > > + - const: gcc_axi_sf
> > > + - const: icp0
> > > + - const: icp0_ahb
> > > + - const: icp1
> > > + - const: icp1_ahb
> > > + - const: ipe_nps
> > > + - const: ipe_nps_ahb
> > > + - const: ipe_nps_fast_ahb
> > > + - const: ipe_pps
> > > + - const: ipe_pps_fast_ahb
> > > + - const: jpeg
> > > + - const: ofe_ahb
> > > + - const: ofe_anchor
> > > + - const: ofe_anchor_fast_ahb
> > > + - const: ofe_hdr
> > > + - const: ofe_hdr_fast_ahb
> > > + - const: ofe_main
> > > + - const: ofe_main_fast_ahb
> > > + - const: vfe0_bayer
> > > + - const: vfe0_bayer_fast_ahb
> > > + - const: vfe1_bayer
> > > + - const: vfe1_bayer_fast_ahb
> > > + - const: vfe2_bayer
> > > + - const: vfe2_bayer_fast_ahb
> > > +
> > > + interrupts:
> > > + maxItems: 30
> > > +
> > > + interrupt-names:
> > > + items:
> > > + - const: csid0
> > > + - const: csid1
> > > + - const: csid2
> > > + - const: csid_lite0
> > > + - const: csid_lite1
> > > + - const: csiphy0
> > > + - const: csiphy1
> > > + - const: csiphy2
> > > + - const: csiphy3
> > > + - const: csiphy4
> > > + - const: csiphy5
> > > + - const: vfe0
> > > + - const: vfe1
> > > + - const: vfe2
> > > + - const: vfe_lite0
> > > + - const: vfe_lite1
> > > + - const: camnoc_nrt
> > > + - const: camnoc_rt
> > > + - const: icp0
> > > + - const: icp1
> > > + - const: jpeg_dma
> > > + - const: jpeg_enc
> > > + - const: rt_cdm0
> > > + - const: rt_cdm1
> > > + - const: rt_cdm2
> > > + - const: rt_cdm3
> > > + - const: rt_cdm4
> > > + - const: tpg0
> > > + - const: tpg1
> > > + - const: tpg2
> > > +
> > > + interconnects:
> > > + maxItems: 4
> > > +
> > > + interconnect-names:
> > > + items:
> > > + - const: ahb
> > > + - const: hf_mnoc
> > > + - const: sf_icp_mnoc
> > > + - const: sf_mnoc
> > You know... Failure to look around is a sin. What are the names of
> > interconnects used by other devices? What do they actually describe?
> >
> > This is an absolute NAK.
>
> Please feel free to correct me here but, a couple things.
>
> 1. This is consistent with
> Documentation/devicetree/bindings/media/qcom,qcm2290-camss.yaml. no?
I see that nobody noticed an issue with Agatti, Lemans and Monaco
bindings (Krzysztof?)
Usually interconnect names describe the blocks that are connected. Here
are the top results of a quick git grep of interconnect names through
arch/arm64/dts/qcom:
729 "qup-core",
717 "qup-config",
457 "qup-memory",
41 "usb-ddr",
41 "apps-usb",
39 "pcie-mem",
39 "cpu-pcie",
28 "sdhc-ddr",
28 "cpu-sdhc",
28 "cpu-cfg",
24 "mdp0-mem",
17 "memory",
14 "ufs-ddr",
14 "mdp1-mem",
14 "cpu-ufs",
13 "video-mem",
13 "gfx-mem",
I hope this gives you a pointer on how to name the interconnects.
>
> 2. If you are referring to some other targets that use, "cam_" prefix, we
> may not need that , isn't it? If we look at these interconnects from camera
> side, as you advised for other things like this?
See above.
>
> >
> > > +
> > > + iommus:
> > > + items:
> > > + - description: VFE non-protected stream
> > > + - description: ICP0 shared stream
> > > + - description: ICP1 shared stream
> > > + - description: IPE CDM non-protected stream
> > > + - description: IPE non-protected stream
> > > + - description: JPEG non-protected stream
> > > + - description: OFE CDM non-protected stream
> > > + - description: OFE non-protected stream
> > > + - description: VFE / VFE Lite CDM non-protected stream
> > This will map all IOMMUs to the same domain. Are you sure that this is
> > what we want? Or do we wait for iommu-maps to be fixed?
--
With best wishes
Dmitry
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH v9 1/5] media: dt-bindings: Add CAMSS device for Kaanapali
2025-12-08 22:48 ` Dmitry Baryshkov
@ 2025-12-08 23:21 ` Vijay Kumar Tumati
2025-12-10 17:50 ` Vijay Kumar Tumati
0 siblings, 1 reply; 17+ messages in thread
From: Vijay Kumar Tumati @ 2025-12-08 23:21 UTC (permalink / raw)
To: Dmitry Baryshkov
Cc: Hangxiang Ma, Loic Poulain, Robert Foss, Andi Shyti, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Todor Tomov,
Vladimir Zapolskiy, Mauro Carvalho Chehab, Bryan O'Donoghue,
linux-arm-msm, devicetree, linux-kernel, linux-media,
Krzysztof Kozlowski
On 12/8/2025 2:48 PM, Dmitry Baryshkov wrote:
> On Mon, Dec 08, 2025 at 01:03:06PM -0800, Vijay Kumar Tumati wrote:
>> On 12/8/2025 11:53 AM, Dmitry Baryshkov wrote:
>>> On Mon, Dec 08, 2025 at 04:39:47AM -0800, Hangxiang Ma wrote:
>>>> Add bindings for qcom,kaanapali-camss to support the Camera Subsystem
>>>> (CAMSS) on the Qualcomm Kaanapali platform.
>>>>
>>>> The Kaanapali platform provides:
>>>>
>>>> - 3 x VFE, 5 RDI per VFE
>>>> - 2 x VFE Lite, 4 RDI per VFE Lite
>>>> - 3 x CSID
>>>> - 2 x CSID Lite
>>>> - 6 x CSIPHY
>>>> - 2 x ICP
>>>> - 1 x IPE
>>>> - 2 x JPEG DMA & Downscaler
>>>> - 2 x JPEG Encoder
>>>> - 1 x OFE
>>>> - 5 x RT CDM
>>>> - 3 x TPG
>>> Please describe the acronyms.
>> Ack.
>>>> Reviewed-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
>>>> Reviewed-by: Krzysztof Kozlowski <krzk@kernel.org>
>>>> Signed-off-by: Hangxiang Ma <hangxiang.ma@oss.qualcomm.com>
>>>> ---
>>>> .../bindings/media/qcom,kaanapali-camss.yaml | 646 +++++++++++++++++++++
>>>> 1 file changed, 646 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..3b54620e14c6
>>>> --- /dev/null
>>>> +++ b/Documentation/devicetree/bindings/media/qcom,kaanapali-camss.yaml
>>>> @@ -0,0 +1,646 @@
>>>> +# 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:
>>>> + Kaanapali camera subsystem includes submodules such as CSIPHY (CSI Physical layer)
>>>> + and CSID (CSI Decoder), which comply with the MIPI CSI2 protocol.
>>>> +
>>>> + The subsystem also integrates a set of real-time image processing engines and their
>>>> + associated configuration modules, as well as non-real-time engines.
>>>> +
>>>> + Additionally, it encompasses a test pattern generator (TPG) submodule.
>>>> +
>>>> +properties:
>>>> + compatible:
>>>> + const: qcom,kaanapali-camss
>>>> +
>>>> + reg:
>>>> + items:
>>>> + - description: Registers for CSID 0
>>>> + - description: Registers for CSID 1
>>>> + - description: Registers for CSID 2
>>>> + - description: Registers for CSID Lite 0
>>>> + - description: Registers for CSID Lite 1
>>>> + - description: Registers for CSIPHY 0
>>>> + - description: Registers for CSIPHY 1
>>>> + - description: Registers for CSIPHY 2
>>>> + - description: Registers for CSIPHY 3
>>>> + - description: Registers for CSIPHY 4
>>>> + - description: Registers for CSIPHY 5
>>>> + - description: Registers for VFE (Video Front End) 0
>>>> + - description: Registers for VFE 1
>>>> + - description: Registers for VFE 2
>>>> + - description: Registers for VFE Lite 0
>>>> + - description: Registers for VFE Lite 1
>>>> + - description: Registers for ICP (Imaging Control Processor) 0
>>>> + - description: Registers for ICP 0 SYS
>>>> + - description: Registers for ICP 1
>>>> + - description: Registers for ICP 1 SYS
>>>> + - description: Registers for IPE (Image Processing Engine)
>>>> + - description: Registers for JPEG DMA & Downscaler
>>>> + - description: Registers for JPEG Encoder
>>>> + - description: Registers for OFE (Offline Front End)
>>>> + - description: Registers for RT CDM (Camera Data Mover) 0
>>>> + - description: Registers for RT CDM 1
>>>> + - description: Registers for RT CDM 2
>>>> + - description: Registers for RT CDM 3
>>>> + - description: Registers for RT CDM 4
>>>> + - description: Registers for TPG 0
>>>> + - description: Registers for TPG 1
>>>> + - description: Registers for TPG 2
>>>> +
>>>> + reg-names:
>>>> + items:
>>>> + - const: csid0
>>>> + - const: csid1
>>>> + - const: csid2
>>>> + - const: csid_lite0
>>>> + - const: csid_lite1
>>>> + - const: csiphy0
>>>> + - const: csiphy1
>>>> + - const: csiphy2
>>>> + - const: csiphy3
>>>> + - const: csiphy4
>>>> + - const: csiphy5
>>>> + - const: vfe0
>>>> + - const: vfe1
>>>> + - const: vfe2
>>>> + - const: vfe_lite0
>>>> + - const: vfe_lite1
>>>> + - const: icp0
>>>> + - const: icp0_sys
>>>> + - const: icp1
>>>> + - const: icp1_sys
>>>> + - const: ipe
>>>> + - const: jpeg_dma
>>>> + - const: jpeg_enc
>>>> + - const: ofe
>>>> + - const: rt_cdm0
>>>> + - const: rt_cdm1
>>>> + - const: rt_cdm2
>>>> + - const: rt_cdm3
>>>> + - const: rt_cdm4
>>>> + - const: tpg0
>>>> + - const: tpg1
>>>> + - const: tpg2
>>>> +
>>>> + clocks:
>>>> + maxItems: 60
>>>> +
>>>> + clock-names:
>>>> + items:
>>>> + - const: camnoc_nrt_axi
>>>> + - const: camnoc_rt_axi
>>>> + - const: camnoc_rt_vfe0
>>>> + - const: camnoc_rt_vfe1
>>>> + - const: camnoc_rt_vfe2
>>>> + - const: camnoc_rt_vfe_lite
>>>> + - const: cpas_ahb
>>>> + - const: cpas_fast_ahb
>>>> + - const: csid
>>>> + - const: csid_csiphy_rx
>>>> + - const: csiphy0
>>>> + - const: csiphy0_timer
>>>> + - const: csiphy1
>>>> + - const: csiphy1_timer
>>>> + - const: csiphy2
>>>> + - const: csiphy2_timer
>>>> + - const: csiphy3
>>>> + - const: csiphy3_timer
>>>> + - const: csiphy4
>>>> + - const: csiphy4_timer
>>>> + - const: csiphy5
>>>> + - const: csiphy5_timer
>>>> + - const: gcc_axi_hf
>>> This clock (and gcc_axi_sf below) still have the gcc_ prefix and GCC name. Why?
>>> It was pointed out in the previous review: clock names should be
>>> describing their purpose, not their source.
>> Hi Dmitry, let me add a bit more detail on this clock. As confirmed by the
>> HW team, the logic that runs based on this clock is still inside the
>> CAMNOC_PDX, just that it is on the CX / MMNOC domain side. Do you think
>> "axi_hf_cx" and "axi_sf_cx" makes sense?
> Why? You are again describing the source. What is the function of?
> bus_hf / bus_sf?
In what I proposed,
axi - represents that we are talking about the axi bus from camera
(against ahb bus).
hf - hf wrapper
cx - logic on the CX side of the bus in CAMNOC.
If you think that 'bus' (even looking from camera client side) by
default means AXI bus and 'hf' and 'sf' implicitly represent the CX side
(which, kind of, in the current design), then yes, "bus_hf" and "bus_sf"
makes sense. Do you advise us to go ahead with these?
>>>> + - 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
>>>> + - const: camnoc_ipe_nps
>>>> + - const: camnoc_ofe
>>>> + - const: gcc_axi_sf
>>>> + - const: icp0
>>>> + - const: icp0_ahb
>>>> + - const: icp1
>>>> + - const: icp1_ahb
>>>> + - const: ipe_nps
>>>> + - const: ipe_nps_ahb
>>>> + - const: ipe_nps_fast_ahb
>>>> + - const: ipe_pps
>>>> + - const: ipe_pps_fast_ahb
>>>> + - const: jpeg
>>>> + - const: ofe_ahb
>>>> + - const: ofe_anchor
>>>> + - const: ofe_anchor_fast_ahb
>>>> + - const: ofe_hdr
>>>> + - const: ofe_hdr_fast_ahb
>>>> + - const: ofe_main
>>>> + - const: ofe_main_fast_ahb
>>>> + - const: vfe0_bayer
>>>> + - const: vfe0_bayer_fast_ahb
>>>> + - const: vfe1_bayer
>>>> + - const: vfe1_bayer_fast_ahb
>>>> + - const: vfe2_bayer
>>>> + - const: vfe2_bayer_fast_ahb
>>>> +
>>>> + interrupts:
>>>> + maxItems: 30
>>>> +
>>>> + interrupt-names:
>>>> + items:
>>>> + - const: csid0
>>>> + - const: csid1
>>>> + - const: csid2
>>>> + - const: csid_lite0
>>>> + - const: csid_lite1
>>>> + - const: csiphy0
>>>> + - const: csiphy1
>>>> + - const: csiphy2
>>>> + - const: csiphy3
>>>> + - const: csiphy4
>>>> + - const: csiphy5
>>>> + - const: vfe0
>>>> + - const: vfe1
>>>> + - const: vfe2
>>>> + - const: vfe_lite0
>>>> + - const: vfe_lite1
>>>> + - const: camnoc_nrt
>>>> + - const: camnoc_rt
>>>> + - const: icp0
>>>> + - const: icp1
>>>> + - const: jpeg_dma
>>>> + - const: jpeg_enc
>>>> + - const: rt_cdm0
>>>> + - const: rt_cdm1
>>>> + - const: rt_cdm2
>>>> + - const: rt_cdm3
>>>> + - const: rt_cdm4
>>>> + - const: tpg0
>>>> + - const: tpg1
>>>> + - const: tpg2
>>>> +
>>>> + interconnects:
>>>> + maxItems: 4
>>>> +
>>>> + interconnect-names:
>>>> + items:
>>>> + - const: ahb
>>>> + - const: hf_mnoc
>>>> + - const: sf_icp_mnoc
>>>> + - const: sf_mnoc
>>> You know... Failure to look around is a sin. What are the names of
>>> interconnects used by other devices? What do they actually describe?
>>>
>>> This is an absolute NAK.
>> Please feel free to correct me here but, a couple things.
>>
>> 1. This is consistent with
>> Documentation/devicetree/bindings/media/qcom,qcm2290-camss.yaml. no?
> I see that nobody noticed an issue with Agatti, Lemans and Monaco
> bindings (Krzysztof?)
>
> Usually interconnect names describe the blocks that are connected. Here
> are the top results of a quick git grep of interconnect names through
> arch/arm64/dts/qcom:
>
> 729 "qup-core",
> 717 "qup-config",
> 457 "qup-memory",
> 41 "usb-ddr",
> 41 "apps-usb",
> 39 "pcie-mem",
> 39 "cpu-pcie",
> 28 "sdhc-ddr",
> 28 "cpu-sdhc",
> 28 "cpu-cfg",
> 24 "mdp0-mem",
> 17 "memory",
> 14 "ufs-ddr",
> 14 "mdp1-mem",
> 14 "cpu-ufs",
> 13 "video-mem",
> 13 "gfx-mem",
>
> I hope this gives you a pointer on how to name the interconnects.
>
>> 2. If you are referring to some other targets that use, "cam_" prefix, we
>> may not need that , isn't it? If we look at these interconnects from camera
>> side, as you advised for other things like this?
> See above.
I see, so the names cam-cfg, cam-hf-mem, cam-sf-mem, cam-sf-icp-mem
should be ok?
Or the other option, go exactly like
Documentation/devicetree/bindings/media/qcom,sc8280xp-camss.yaml.
What would you advise?
>
>>>> +
>>>> + iommus:
>>>> + items:
>>>> + - description: VFE non-protected stream
>>>> + - description: ICP0 shared stream
>>>> + - description: ICP1 shared stream
>>>> + - description: IPE CDM non-protected stream
>>>> + - description: IPE non-protected stream
>>>> + - description: JPEG non-protected stream
>>>> + - description: OFE CDM non-protected stream
>>>> + - description: OFE non-protected stream
>>>> + - description: VFE / VFE Lite CDM non-protected stream
>>> This will map all IOMMUs to the same domain. Are you sure that this is
>>> what we want? Or do we wait for iommu-maps to be fixed?
Thanks,
Vijay.
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH v9 1/5] media: dt-bindings: Add CAMSS device for Kaanapali
2025-12-08 23:21 ` Vijay Kumar Tumati
@ 2025-12-10 17:50 ` Vijay Kumar Tumati
2025-12-10 19:25 ` Dmitry Baryshkov
0 siblings, 1 reply; 17+ messages in thread
From: Vijay Kumar Tumati @ 2025-12-10 17:50 UTC (permalink / raw)
To: Dmitry Baryshkov
Cc: Hangxiang Ma, Loic Poulain, Robert Foss, Andi Shyti, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Todor Tomov,
Vladimir Zapolskiy, Mauro Carvalho Chehab, Bryan O'Donoghue,
linux-arm-msm, devicetree, linux-kernel, linux-media,
Krzysztof Kozlowski
On 12/8/2025 3:21 PM, Vijay Kumar Tumati wrote:
>
> On 12/8/2025 2:48 PM, Dmitry Baryshkov wrote:
>> On Mon, Dec 08, 2025 at 01:03:06PM -0800, Vijay Kumar Tumati wrote:
>>> On 12/8/2025 11:53 AM, Dmitry Baryshkov wrote:
>>>> On Mon, Dec 08, 2025 at 04:39:47AM -0800, Hangxiang Ma wrote:
>>>>> Add bindings for qcom,kaanapali-camss to support the Camera Subsystem
>>>>> (CAMSS) on the Qualcomm Kaanapali platform.
>>>>>
>>>>> The Kaanapali platform provides:
>>>>>
>>>>> - 3 x VFE, 5 RDI per VFE
>>>>> - 2 x VFE Lite, 4 RDI per VFE Lite
>>>>> - 3 x CSID
>>>>> - 2 x CSID Lite
>>>>> - 6 x CSIPHY
>>>>> - 2 x ICP
>>>>> - 1 x IPE
>>>>> - 2 x JPEG DMA & Downscaler
>>>>> - 2 x JPEG Encoder
>>>>> - 1 x OFE
>>>>> - 5 x RT CDM
>>>>> - 3 x TPG
>>>> Please describe the acronyms.
>>> Ack.
>>>>> Reviewed-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
>>>>> Reviewed-by: Krzysztof Kozlowski <krzk@kernel.org>
>>>>> Signed-off-by: Hangxiang Ma <hangxiang.ma@oss.qualcomm.com>
>>>>> ---
>>>>> .../bindings/media/qcom,kaanapali-camss.yaml | 646
>>>>> +++++++++++++++++++++
>>>>> 1 file changed, 646 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..3b54620e14c6
>>>>> --- /dev/null
>>>>> +++
>>>>> b/Documentation/devicetree/bindings/media/qcom,kaanapali-camss.yaml
>>>>> @@ -0,0 +1,646 @@
>>>>> +# 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:
>>>>> + Kaanapali camera subsystem includes submodules such as CSIPHY
>>>>> (CSI Physical layer)
>>>>> + and CSID (CSI Decoder), which comply with the MIPI CSI2 protocol.
>>>>> +
>>>>> + The subsystem also integrates a set of real-time image
>>>>> processing engines and their
>>>>> + associated configuration modules, as well as non-real-time
>>>>> engines.
>>>>> +
>>>>> + Additionally, it encompasses a test pattern generator (TPG)
>>>>> submodule.
>>>>> +
>>>>> +properties:
>>>>> + compatible:
>>>>> + const: qcom,kaanapali-camss
>>>>> +
>>>>> + reg:
>>>>> + items:
>>>>> + - description: Registers for CSID 0
>>>>> + - description: Registers for CSID 1
>>>>> + - description: Registers for CSID 2
>>>>> + - description: Registers for CSID Lite 0
>>>>> + - description: Registers for CSID Lite 1
>>>>> + - description: Registers for CSIPHY 0
>>>>> + - description: Registers for CSIPHY 1
>>>>> + - description: Registers for CSIPHY 2
>>>>> + - description: Registers for CSIPHY 3
>>>>> + - description: Registers for CSIPHY 4
>>>>> + - description: Registers for CSIPHY 5
>>>>> + - description: Registers for VFE (Video Front End) 0
>>>>> + - description: Registers for VFE 1
>>>>> + - description: Registers for VFE 2
>>>>> + - description: Registers for VFE Lite 0
>>>>> + - description: Registers for VFE Lite 1
>>>>> + - description: Registers for ICP (Imaging Control Processor) 0
>>>>> + - description: Registers for ICP 0 SYS
>>>>> + - description: Registers for ICP 1
>>>>> + - description: Registers for ICP 1 SYS
>>>>> + - description: Registers for IPE (Image Processing Engine)
>>>>> + - description: Registers for JPEG DMA & Downscaler
>>>>> + - description: Registers for JPEG Encoder
>>>>> + - description: Registers for OFE (Offline Front End)
>>>>> + - description: Registers for RT CDM (Camera Data Mover) 0
>>>>> + - description: Registers for RT CDM 1
>>>>> + - description: Registers for RT CDM 2
>>>>> + - description: Registers for RT CDM 3
>>>>> + - description: Registers for RT CDM 4
>>>>> + - description: Registers for TPG 0
>>>>> + - description: Registers for TPG 1
>>>>> + - description: Registers for TPG 2
>>>>> +
>>>>> + reg-names:
>>>>> + items:
>>>>> + - const: csid0
>>>>> + - const: csid1
>>>>> + - const: csid2
>>>>> + - const: csid_lite0
>>>>> + - const: csid_lite1
>>>>> + - const: csiphy0
>>>>> + - const: csiphy1
>>>>> + - const: csiphy2
>>>>> + - const: csiphy3
>>>>> + - const: csiphy4
>>>>> + - const: csiphy5
>>>>> + - const: vfe0
>>>>> + - const: vfe1
>>>>> + - const: vfe2
>>>>> + - const: vfe_lite0
>>>>> + - const: vfe_lite1
>>>>> + - const: icp0
>>>>> + - const: icp0_sys
>>>>> + - const: icp1
>>>>> + - const: icp1_sys
>>>>> + - const: ipe
>>>>> + - const: jpeg_dma
>>>>> + - const: jpeg_enc
>>>>> + - const: ofe
>>>>> + - const: rt_cdm0
>>>>> + - const: rt_cdm1
>>>>> + - const: rt_cdm2
>>>>> + - const: rt_cdm3
>>>>> + - const: rt_cdm4
>>>>> + - const: tpg0
>>>>> + - const: tpg1
>>>>> + - const: tpg2
>>>>> +
>>>>> + clocks:
>>>>> + maxItems: 60
>>>>> +
>>>>> + clock-names:
>>>>> + items:
>>>>> + - const: camnoc_nrt_axi
>>>>> + - const: camnoc_rt_axi
>>>>> + - const: camnoc_rt_vfe0
>>>>> + - const: camnoc_rt_vfe1
>>>>> + - const: camnoc_rt_vfe2
>>>>> + - const: camnoc_rt_vfe_lite
>>>>> + - const: cpas_ahb
>>>>> + - const: cpas_fast_ahb
>>>>> + - const: csid
>>>>> + - const: csid_csiphy_rx
>>>>> + - const: csiphy0
>>>>> + - const: csiphy0_timer
>>>>> + - const: csiphy1
>>>>> + - const: csiphy1_timer
>>>>> + - const: csiphy2
>>>>> + - const: csiphy2_timer
>>>>> + - const: csiphy3
>>>>> + - const: csiphy3_timer
>>>>> + - const: csiphy4
>>>>> + - const: csiphy4_timer
>>>>> + - const: csiphy5
>>>>> + - const: csiphy5_timer
>>>>> + - const: gcc_axi_hf
>>>> This clock (and gcc_axi_sf below) still have the gcc_ prefix and
>>>> GCC name. Why?
>>>> It was pointed out in the previous review: clock names should be
>>>> describing their purpose, not their source.
>>> Hi Dmitry, let me add a bit more detail on this clock. As confirmed
>>> by the
>>> HW team, the logic that runs based on this clock is still inside the
>>> CAMNOC_PDX, just that it is on the CX / MMNOC domain side. Do you think
>>> "axi_hf_cx" and "axi_sf_cx" makes sense?
>> Why? You are again describing the source. What is the function of?
>> bus_hf / bus_sf?
>
> In what I proposed,
>
> axi - represents that we are talking about the axi bus from camera
> (against ahb bus).
>
> hf - hf wrapper
>
> cx - logic on the CX side of the bus in CAMNOC.
>
> If you think that 'bus' (even looking from camera client side) by
> default means AXI bus and 'hf' and 'sf' implicitly represent the CX
> side (which, kind of, in the current design), then yes, "bus_hf" and
> "bus_sf" makes sense. Do you advise us to go ahead with these?
>
Ok, we will go ahead with "bus_hf" and "bus_sf". Hi @Bryan and others,
please let us know if you have any concerns with this.
>>>>> + - 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
>>>>> + - const: camnoc_ipe_nps
>>>>> + - const: camnoc_ofe
>>>>> + - const: gcc_axi_sf
>>>>> + - const: icp0
>>>>> + - const: icp0_ahb
>>>>> + - const: icp1
>>>>> + - const: icp1_ahb
>>>>> + - const: ipe_nps
>>>>> + - const: ipe_nps_ahb
>>>>> + - const: ipe_nps_fast_ahb
>>>>> + - const: ipe_pps
>>>>> + - const: ipe_pps_fast_ahb
>>>>> + - const: jpeg
>>>>> + - const: ofe_ahb
>>>>> + - const: ofe_anchor
>>>>> + - const: ofe_anchor_fast_ahb
>>>>> + - const: ofe_hdr
>>>>> + - const: ofe_hdr_fast_ahb
>>>>> + - const: ofe_main
>>>>> + - const: ofe_main_fast_ahb
>>>>> + - const: vfe0_bayer
>>>>> + - const: vfe0_bayer_fast_ahb
>>>>> + - const: vfe1_bayer
>>>>> + - const: vfe1_bayer_fast_ahb
>>>>> + - const: vfe2_bayer
>>>>> + - const: vfe2_bayer_fast_ahb
>>>>> +
>>>>> + interrupts:
>>>>> + maxItems: 30
>>>>> +
>>>>> + interrupt-names:
>>>>> + items:
>>>>> + - const: csid0
>>>>> + - const: csid1
>>>>> + - const: csid2
>>>>> + - const: csid_lite0
>>>>> + - const: csid_lite1
>>>>> + - const: csiphy0
>>>>> + - const: csiphy1
>>>>> + - const: csiphy2
>>>>> + - const: csiphy3
>>>>> + - const: csiphy4
>>>>> + - const: csiphy5
>>>>> + - const: vfe0
>>>>> + - const: vfe1
>>>>> + - const: vfe2
>>>>> + - const: vfe_lite0
>>>>> + - const: vfe_lite1
>>>>> + - const: camnoc_nrt
>>>>> + - const: camnoc_rt
>>>>> + - const: icp0
>>>>> + - const: icp1
>>>>> + - const: jpeg_dma
>>>>> + - const: jpeg_enc
>>>>> + - const: rt_cdm0
>>>>> + - const: rt_cdm1
>>>>> + - const: rt_cdm2
>>>>> + - const: rt_cdm3
>>>>> + - const: rt_cdm4
>>>>> + - const: tpg0
>>>>> + - const: tpg1
>>>>> + - const: tpg2
>>>>> +
>>>>> + interconnects:
>>>>> + maxItems: 4
>>>>> +
>>>>> + interconnect-names:
>>>>> + items:
>>>>> + - const: ahb
>>>>> + - const: hf_mnoc
>>>>> + - const: sf_icp_mnoc
>>>>> + - const: sf_mnoc
>>>> You know... Failure to look around is a sin. What are the names of
>>>> interconnects used by other devices? What do they actually describe?
>>>>
>>>> This is an absolute NAK.
>>> Please feel free to correct me here but, a couple things.
>>>
>>> 1. This is consistent with
>>> Documentation/devicetree/bindings/media/qcom,qcm2290-camss.yaml. no?
>> I see that nobody noticed an issue with Agatti, Lemans and Monaco
>> bindings (Krzysztof?)
>>
>> Usually interconnect names describe the blocks that are connected. Here
>> are the top results of a quick git grep of interconnect names through
>> arch/arm64/dts/qcom:
>>
>> 729 "qup-core",
>> 717 "qup-config",
>> 457 "qup-memory",
>> 41 "usb-ddr",
>> 41 "apps-usb",
>> 39 "pcie-mem",
>> 39 "cpu-pcie",
>> 28 "sdhc-ddr",
>> 28 "cpu-sdhc",
>> 28 "cpu-cfg",
>> 24 "mdp0-mem",
>> 17 "memory",
>> 14 "ufs-ddr",
>> 14 "mdp1-mem",
>> 14 "cpu-ufs",
>> 13 "video-mem",
>> 13 "gfx-mem",
>>
>> I hope this gives you a pointer on how to name the interconnects.
>>
>>> 2. If you are referring to some other targets that use, "cam_"
>>> prefix, we
>>> may not need that , isn't it? If we look at these interconnects from
>>> camera
>>> side, as you advised for other things like this?
>> See above.
>
> I see, so the names cam-cfg, cam-hf-mem, cam-sf-mem, cam-sf-icp-mem
> should be ok?
>
> Or the other option, go exactly like
> Documentation/devicetree/bindings/media/qcom,sc8280xp-camss.yaml.
>
> What would you advise?
>
To keep it consistent with the previous generations and still represent
the block name, we will go ahead with the style in
qcom,sc8280xp-camss.yaml. If anyone has any concerns, please do let us
know.
>>
>>>>> +
>>>>> + iommus:
>>>>> + items:
>>>>> + - description: VFE non-protected stream
>>>>> + - description: ICP0 shared stream
>>>>> + - description: ICP1 shared stream
>>>>> + - description: IPE CDM non-protected stream
>>>>> + - description: IPE non-protected stream
>>>>> + - description: JPEG non-protected stream
>>>>> + - description: OFE CDM non-protected stream
>>>>> + - description: OFE non-protected stream
>>>>> + - description: VFE / VFE Lite CDM non-protected stream
>>>> This will map all IOMMUs to the same domain. Are you sure that this is
>>>> what we want? Or do we wait for iommu-maps to be fixed?
>
Yes, when it is available, we can start using iommu-maps to create
separate context banks.
> Thanks,
>
> Vijay.
>
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH v9 1/5] media: dt-bindings: Add CAMSS device for Kaanapali
2025-12-10 17:50 ` Vijay Kumar Tumati
@ 2025-12-10 19:25 ` Dmitry Baryshkov
2025-12-10 19:36 ` Vijay Kumar Tumati
0 siblings, 1 reply; 17+ messages in thread
From: Dmitry Baryshkov @ 2025-12-10 19:25 UTC (permalink / raw)
To: Vijay Kumar Tumati
Cc: Hangxiang Ma, Loic Poulain, Robert Foss, Andi Shyti, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Todor Tomov,
Vladimir Zapolskiy, Mauro Carvalho Chehab, Bryan O'Donoghue,
linux-arm-msm, devicetree, linux-kernel, linux-media,
Krzysztof Kozlowski
On Wed, Dec 10, 2025 at 09:50:51AM -0800, Vijay Kumar Tumati wrote:
>
> On 12/8/2025 3:21 PM, Vijay Kumar Tumati wrote:
> >
> > On 12/8/2025 2:48 PM, Dmitry Baryshkov wrote:
> > > On Mon, Dec 08, 2025 at 01:03:06PM -0800, Vijay Kumar Tumati wrote:
> > > > On 12/8/2025 11:53 AM, Dmitry Baryshkov wrote:
> > > > > > + interconnects:
> > > > > > + maxItems: 4
> > > > > > +
> > > > > > + interconnect-names:
> > > > > > + items:
> > > > > > + - const: ahb
> > > > > > + - const: hf_mnoc
> > > > > > + - const: sf_icp_mnoc
> > > > > > + - const: sf_mnoc
> > > > > You know... Failure to look around is a sin. What are the names of
> > > > > interconnects used by other devices? What do they actually describe?
> > > > >
> > > > > This is an absolute NAK.
> > > > Please feel free to correct me here but, a couple things.
> > > >
> > > > 1. This is consistent with
> > > > Documentation/devicetree/bindings/media/qcom,qcm2290-camss.yaml. no?
> > > I see that nobody noticed an issue with Agatti, Lemans and Monaco
> > > bindings (Krzysztof?)
> > >
> > > Usually interconnect names describe the blocks that are connected. Here
> > > are the top results of a quick git grep of interconnect names through
> > > arch/arm64/dts/qcom:
> > >
> > > 729 "qup-core",
> > > 717 "qup-config",
> > > 457 "qup-memory",
> > > 41 "usb-ddr",
> > > 41 "apps-usb",
> > > 39 "pcie-mem",
> > > 39 "cpu-pcie",
> > > 28 "sdhc-ddr",
> > > 28 "cpu-sdhc",
> > > 28 "cpu-cfg",
> > > 24 "mdp0-mem",
> > > 17 "memory",
> > > 14 "ufs-ddr",
> > > 14 "mdp1-mem",
> > > 14 "cpu-ufs",
> > > 13 "video-mem",
> > > 13 "gfx-mem",
> > >
> > > I hope this gives you a pointer on how to name the interconnects.
> > >
> > > > 2. If you are referring to some other targets that use, "cam_"
> > > > prefix, we
> > > > may not need that , isn't it? If we look at these interconnects
> > > > from camera
> > > > side, as you advised for other things like this?
> > > See above.
> >
> > I see, so the names cam-cfg, cam-hf-mem, cam-sf-mem, cam-sf-icp-mem
> > should be ok?
> >
> > Or the other option, go exactly like
> > Documentation/devicetree/bindings/media/qcom,sc8280xp-camss.yaml.
> >
> > What would you advise?
> >
> To keep it consistent with the previous generations and still represent the
> block name, we will go ahead with the style in qcom,sc8280xp-camss.yaml. If
> anyone has any concerns, please do let us know.
Krzysztof, Bryan, your opinion? My preference would be to start using
sensible names, but I wouldn't enforce that.
> > >
> > > > > > +
> > > > > > + iommus:
> > > > > > + items:
> > > > > > + - description: VFE non-protected stream
> > > > > > + - description: ICP0 shared stream
> > > > > > + - description: ICP1 shared stream
> > > > > > + - description: IPE CDM non-protected stream
> > > > > > + - description: IPE non-protected stream
> > > > > > + - description: JPEG non-protected stream
> > > > > > + - description: OFE CDM non-protected stream
> > > > > > + - description: OFE non-protected stream
> > > > > > + - description: VFE / VFE Lite CDM non-protected stream
> > > > > This will map all IOMMUs to the same domain. Are you sure that this is
> > > > > what we want? Or do we wait for iommu-maps to be fixed?
> >
> Yes, when it is available, we can start using iommu-maps to create separate
> context banks.
It would be necessary to justify removing items from the list. Wouldn't
it be better to map only necessary SIDs now and add other later once we
have iommu-maps?
--
With best wishes
Dmitry
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH v9 1/5] media: dt-bindings: Add CAMSS device for Kaanapali
2025-12-10 19:25 ` Dmitry Baryshkov
@ 2025-12-10 19:36 ` Vijay Kumar Tumati
2025-12-10 21:45 ` Bryan O'Donoghue
0 siblings, 1 reply; 17+ messages in thread
From: Vijay Kumar Tumati @ 2025-12-10 19:36 UTC (permalink / raw)
To: Dmitry Baryshkov
Cc: Hangxiang Ma, Loic Poulain, Robert Foss, Andi Shyti, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Todor Tomov,
Vladimir Zapolskiy, Mauro Carvalho Chehab, Bryan O'Donoghue,
linux-arm-msm, devicetree, linux-kernel, linux-media,
Krzysztof Kozlowski
On 12/10/2025 11:25 AM, Dmitry Baryshkov wrote:
> On Wed, Dec 10, 2025 at 09:50:51AM -0800, Vijay Kumar Tumati wrote:
>> On 12/8/2025 3:21 PM, Vijay Kumar Tumati wrote:
>>> On 12/8/2025 2:48 PM, Dmitry Baryshkov wrote:
>>>> On Mon, Dec 08, 2025 at 01:03:06PM -0800, Vijay Kumar Tumati wrote:
>>>>> On 12/8/2025 11:53 AM, Dmitry Baryshkov wrote:
>>>>>>> + interconnects:
>>>>>>> + maxItems: 4
>>>>>>> +
>>>>>>> + interconnect-names:
>>>>>>> + items:
>>>>>>> + - const: ahb
>>>>>>> + - const: hf_mnoc
>>>>>>> + - const: sf_icp_mnoc
>>>>>>> + - const: sf_mnoc
>>>>>> You know... Failure to look around is a sin. What are the names of
>>>>>> interconnects used by other devices? What do they actually describe?
>>>>>>
>>>>>> This is an absolute NAK.
>>>>> Please feel free to correct me here but, a couple things.
>>>>>
>>>>> 1. This is consistent with
>>>>> Documentation/devicetree/bindings/media/qcom,qcm2290-camss.yaml. no?
>>>> I see that nobody noticed an issue with Agatti, Lemans and Monaco
>>>> bindings (Krzysztof?)
>>>>
>>>> Usually interconnect names describe the blocks that are connected. Here
>>>> are the top results of a quick git grep of interconnect names through
>>>> arch/arm64/dts/qcom:
>>>>
>>>> 729 "qup-core",
>>>> 717 "qup-config",
>>>> 457 "qup-memory",
>>>> 41 "usb-ddr",
>>>> 41 "apps-usb",
>>>> 39 "pcie-mem",
>>>> 39 "cpu-pcie",
>>>> 28 "sdhc-ddr",
>>>> 28 "cpu-sdhc",
>>>> 28 "cpu-cfg",
>>>> 24 "mdp0-mem",
>>>> 17 "memory",
>>>> 14 "ufs-ddr",
>>>> 14 "mdp1-mem",
>>>> 14 "cpu-ufs",
>>>> 13 "video-mem",
>>>> 13 "gfx-mem",
>>>>
>>>> I hope this gives you a pointer on how to name the interconnects.
>>>>
>>>>> 2. If you are referring to some other targets that use, "cam_"
>>>>> prefix, we
>>>>> may not need that , isn't it? If we look at these interconnects
>>>>> from camera
>>>>> side, as you advised for other things like this?
>>>> See above.
>>> I see, so the names cam-cfg, cam-hf-mem, cam-sf-mem, cam-sf-icp-mem
>>> should be ok?
>>>
>>> Or the other option, go exactly like
>>> Documentation/devicetree/bindings/media/qcom,sc8280xp-camss.yaml.
>>>
>>> What would you advise?
>>>
>> To keep it consistent with the previous generations and still represent the
>> block name, we will go ahead with the style in qcom,sc8280xp-camss.yaml. If
>> anyone has any concerns, please do let us know.
> Krzysztof, Bryan, your opinion? My preference would be to start using
> sensible names, but I wouldn't enforce that.
>
>>>>>>> +
>>>>>>> + iommus:
>>>>>>> + items:
>>>>>>> + - description: VFE non-protected stream
>>>>>>> + - description: ICP0 shared stream
>>>>>>> + - description: ICP1 shared stream
>>>>>>> + - description: IPE CDM non-protected stream
>>>>>>> + - description: IPE non-protected stream
>>>>>>> + - description: JPEG non-protected stream
>>>>>>> + - description: OFE CDM non-protected stream
>>>>>>> + - description: OFE non-protected stream
>>>>>>> + - description: VFE / VFE Lite CDM non-protected stream
>>>>>> This will map all IOMMUs to the same domain. Are you sure that this is
>>>>>> what we want? Or do we wait for iommu-maps to be fixed?
>> Yes, when it is available, we can start using iommu-maps to create separate
>> context banks.
> It would be necessary to justify removing items from the list. Wouldn't
> it be better to map only necessary SIDs now and add other later once we
> have iommu-maps?
I will let Bryan take the call on this. He was the one who wanted all
the SIDs in the bindings. Hi @Bryan, if you can kindly share your
thoughts on this and the interconnect naming, we will go ahead and push
rev 10 for this. I believe we have taken care of other things. Thank you.
>
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH v9 1/5] media: dt-bindings: Add CAMSS device for Kaanapali
2025-12-10 19:36 ` Vijay Kumar Tumati
@ 2025-12-10 21:45 ` Bryan O'Donoghue
2025-12-10 22:05 ` Bryan O'Donoghue
2025-12-10 23:34 ` Dmitry Baryshkov
0 siblings, 2 replies; 17+ messages in thread
From: Bryan O'Donoghue @ 2025-12-10 21:45 UTC (permalink / raw)
To: Vijay Kumar Tumati, Dmitry Baryshkov
Cc: Hangxiang Ma, Loic Poulain, Robert Foss, Andi Shyti, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Todor Tomov,
Vladimir Zapolskiy, Mauro Carvalho Chehab, linux-arm-msm,
devicetree, linux-kernel, linux-media, Krzysztof Kozlowski
On 10/12/2025 19:36, Vijay Kumar Tumati wrote:
>
> On 12/10/2025 11:25 AM, Dmitry Baryshkov wrote:
>> On Wed, Dec 10, 2025 at 09:50:51AM -0800, Vijay Kumar Tumati wrote:
>>> On 12/8/2025 3:21 PM, Vijay Kumar Tumati wrote:
>>>> On 12/8/2025 2:48 PM, Dmitry Baryshkov wrote:
>>>>> On Mon, Dec 08, 2025 at 01:03:06PM -0800, Vijay Kumar Tumati wrote:
>>>>>> On 12/8/2025 11:53 AM, Dmitry Baryshkov wrote:
>>>>>>>> + interconnects:
>>>>>>>> + maxItems: 4
>>>>>>>> +
>>>>>>>> + interconnect-names:
>>>>>>>> + items:
>>>>>>>> + - const: ahb
>>>>>>>> + - const: hf_mnoc
>>>>>>>> + - const: sf_icp_mnoc
>>>>>>>> + - const: sf_mnoc
>>>>>>> You know... Failure to look around is a sin. What are the names of
>>>>>>> interconnects used by other devices? What do they actually describe?
>>>>>>>
>>>>>>> This is an absolute NAK.
>>>>>> Please feel free to correct me here but, a couple things.
>>>>>>
>>>>>> 1. This is consistent with
>>>>>> Documentation/devicetree/bindings/media/qcom,qcm2290-camss.yaml. no?
>>>>> I see that nobody noticed an issue with Agatti, Lemans and Monaco
>>>>> bindings (Krzysztof?)
>>>>>
>>>>> Usually interconnect names describe the blocks that are connected.
>>>>> Here
>>>>> are the top results of a quick git grep of interconnect names through
>>>>> arch/arm64/dts/qcom:
>>>>>
>>>>> 729 "qup-core",
>>>>> 717 "qup-config",
>>>>> 457 "qup-memory",
>>>>> 41 "usb-ddr",
>>>>> 41 "apps-usb",
>>>>> 39 "pcie-mem",
>>>>> 39 "cpu-pcie",
>>>>> 28 "sdhc-ddr",
>>>>> 28 "cpu-sdhc",
>>>>> 28 "cpu-cfg",
>>>>> 24 "mdp0-mem",
>>>>> 17 "memory",
>>>>> 14 "ufs-ddr",
>>>>> 14 "mdp1-mem",
>>>>> 14 "cpu-ufs",
>>>>> 13 "video-mem",
>>>>> 13 "gfx-mem",
>>>>>
>>>>> I hope this gives you a pointer on how to name the interconnects.
>>>>>
>>>>>> 2. If you are referring to some other targets that use, "cam_"
>>>>>> prefix, we
>>>>>> may not need that , isn't it? If we look at these interconnects
>>>>>> from camera
>>>>>> side, as you advised for other things like this?
>>>>> See above.
>>>> I see, so the names cam-cfg, cam-hf-mem, cam-sf-mem, cam-sf-icp-mem
>>>> should be ok?
>>>>
>>>> Or the other option, go exactly like
>>>> Documentation/devicetree/bindings/media/qcom,sc8280xp-camss.yaml.
>>>>
>>>> What would you advise?
>>>>
>>> To keep it consistent with the previous generations and still
>>> represent the
>>> block name, we will go ahead with the style in qcom,sc8280xp-
>>> camss.yaml. If
>>> anyone has any concerns, please do let us know.
>> Krzysztof, Bryan, your opinion? My preference would be to start using
>> sensible names, but I wouldn't enforce that.
>>
>>>>>>>> +
>>>>>>>> + iommus:
>>>>>>>> + items:
>>>>>>>> + - description: VFE non-protected stream
>>>>>>>> + - description: ICP0 shared stream
>>>>>>>> + - description: ICP1 shared stream
>>>>>>>> + - description: IPE CDM non-protected stream
>>>>>>>> + - description: IPE non-protected stream
>>>>>>>> + - description: JPEG non-protected stream
>>>>>>>> + - description: OFE CDM non-protected stream
>>>>>>>> + - description: OFE non-protected stream
>>>>>>>> + - description: VFE / VFE Lite CDM non-protected stream
>>>>>>> This will map all IOMMUs to the same domain. Are you sure that
>>>>>>> this is
>>>>>>> what we want? Or do we wait for iommu-maps to be fixed?
>>> Yes, when it is available, we can start using iommu-maps to create
>>> separate
>>> context banks.
>> It would be necessary to justify removing items from the list. Wouldn't
>> it be better to map only necessary SIDs now and add other later once we
>> have iommu-maps?
> I will let Bryan take the call on this. He was the one who wanted all
> the SIDs in the bindings. Hi @Bryan, if you can kindly share your
> thoughts on this and the interconnect naming, we will go ahead and push
> rev 10 for this. I believe we have taken care of other things. Thank you.
>>
Since when are we delaying patches for future patches that may land never ?
I'm fine with whatever clock name changes you can agree with Krzysztof
but it seems a bit ironic to me to be given feedback to "align with
previous dts" to then have the result be further change.
I'd like a bit of stability and consistency TBH.
---
bod
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH v9 1/5] media: dt-bindings: Add CAMSS device for Kaanapali
2025-12-10 21:45 ` Bryan O'Donoghue
@ 2025-12-10 22:05 ` Bryan O'Donoghue
2025-12-10 23:32 ` Vijay Kumar Tumati
2025-12-10 23:34 ` Dmitry Baryshkov
1 sibling, 1 reply; 17+ messages in thread
From: Bryan O'Donoghue @ 2025-12-10 22:05 UTC (permalink / raw)
To: Vijay Kumar Tumati, Dmitry Baryshkov
Cc: Hangxiang Ma, Loic Poulain, Robert Foss, Andi Shyti, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Todor Tomov,
Vladimir Zapolskiy, Mauro Carvalho Chehab, linux-arm-msm,
devicetree, linux-kernel, linux-media, Krzysztof Kozlowski
On 10/12/2025 21:45, Bryan O'Donoghue wrote:
> On 10/12/2025 19:36, Vijay Kumar Tumati wrote:
>>
>> On 12/10/2025 11:25 AM, Dmitry Baryshkov wrote:
>>> On Wed, Dec 10, 2025 at 09:50:51AM -0800, Vijay Kumar Tumati wrote:
>>>> On 12/8/2025 3:21 PM, Vijay Kumar Tumati wrote:
>>>>> On 12/8/2025 2:48 PM, Dmitry Baryshkov wrote:
>>>>>> On Mon, Dec 08, 2025 at 01:03:06PM -0800, Vijay Kumar Tumati wrote:
>>>>>>> On 12/8/2025 11:53 AM, Dmitry Baryshkov wrote:
>>>>>>>>> + interconnects:
>>>>>>>>> + maxItems: 4
>>>>>>>>> +
>>>>>>>>> + interconnect-names:
>>>>>>>>> + items:
>>>>>>>>> + - const: ahb
>>>>>>>>> + - const: hf_mnoc
>>>>>>>>> + - const: sf_icp_mnoc
>>>>>>>>> + - const: sf_mnoc
>>>>>>>> You know... Failure to look around is a sin. What are the names of
>>>>>>>> interconnects used by other devices? What do they actually describe?
>>>>>>>>
>>>>>>>> This is an absolute NAK.
>>>>>>> Please feel free to correct me here but, a couple things.
>>>>>>>
>>>>>>> 1. This is consistent with
>>>>>>> Documentation/devicetree/bindings/media/qcom,qcm2290-camss.yaml. no?
>>>>>> I see that nobody noticed an issue with Agatti, Lemans and Monaco
>>>>>> bindings (Krzysztof?)
>>>>>>
>>>>>> Usually interconnect names describe the blocks that are connected.
>>>>>> Here
>>>>>> are the top results of a quick git grep of interconnect names through
>>>>>> arch/arm64/dts/qcom:
>>>>>>
>>>>>> 729 "qup-core",
>>>>>> 717 "qup-config",
>>>>>> 457 "qup-memory",
>>>>>> 41 "usb-ddr",
>>>>>> 41 "apps-usb",
>>>>>> 39 "pcie-mem",
>>>>>> 39 "cpu-pcie",
>>>>>> 28 "sdhc-ddr",
>>>>>> 28 "cpu-sdhc",
>>>>>> 28 "cpu-cfg",
>>>>>> 24 "mdp0-mem",
>>>>>> 17 "memory",
>>>>>> 14 "ufs-ddr",
>>>>>> 14 "mdp1-mem",
>>>>>> 14 "cpu-ufs",
>>>>>> 13 "video-mem",
>>>>>> 13 "gfx-mem",
>>>>>>
>>>>>> I hope this gives you a pointer on how to name the interconnects.
>>>>>>
>>>>>>> 2. If you are referring to some other targets that use, "cam_"
>>>>>>> prefix, we
>>>>>>> may not need that , isn't it? If we look at these interconnects
>>>>>>> from camera
>>>>>>> side, as you advised for other things like this?
>>>>>> See above.
>>>>> I see, so the names cam-cfg, cam-hf-mem, cam-sf-mem, cam-sf-icp-mem
>>>>> should be ok?
>>>>>
>>>>> Or the other option, go exactly like
>>>>> Documentation/devicetree/bindings/media/qcom,sc8280xp-camss.yaml.
>>>>>
>>>>> What would you advise?
>>>>>
>>>> To keep it consistent with the previous generations and still
>>>> represent the
>>>> block name, we will go ahead with the style in qcom,sc8280xp-
>>>> camss.yaml. If
>>>> anyone has any concerns, please do let us know.
>>> Krzysztof, Bryan, your opinion? My preference would be to start using
>>> sensible names, but I wouldn't enforce that.
>>>
>>>>>>>>> +
>>>>>>>>> + iommus:
>>>>>>>>> + items:
>>>>>>>>> + - description: VFE non-protected stream
>>>>>>>>> + - description: ICP0 shared stream
>>>>>>>>> + - description: ICP1 shared stream
>>>>>>>>> + - description: IPE CDM non-protected stream
>>>>>>>>> + - description: IPE non-protected stream
>>>>>>>>> + - description: JPEG non-protected stream
>>>>>>>>> + - description: OFE CDM non-protected stream
>>>>>>>>> + - description: OFE non-protected stream
>>>>>>>>> + - description: VFE / VFE Lite CDM non-protected stream
>>>>>>>> This will map all IOMMUs to the same domain. Are you sure that
>>>>>>>> this is
>>>>>>>> what we want? Or do we wait for iommu-maps to be fixed?
>>>> Yes, when it is available, we can start using iommu-maps to create
>>>> separate
>>>> context banks.
>>> It would be necessary to justify removing items from the list. Wouldn't
>>> it be better to map only necessary SIDs now and add other later once we
>>> have iommu-maps?
>> I will let Bryan take the call on this. He was the one who wanted all
>> the SIDs in the bindings. Hi @Bryan, if you can kindly share your
>> thoughts on this and the interconnect naming, we will go ahead and push
>> rev 10 for this. I believe we have taken care of other things. Thank you.
>>>
>
> Since when are we delaying patches for future patches that may land never ?
>
> I'm fine with whatever clock name changes you can agree with Krzysztof
> but it seems a bit ironic to me to be given feedback to "align with
> previous dts" to then have the result be further change.
>
> I'd like a bit of stability and consistency TBH.
>
> ---
> bod
>
My feedback is
- Include the full list of SIDs
- Stick to previous clock and interconnect names
Your other alternative is to suspend Kaanapali CAMSS unless/until
iommu-map is landed.
As I say though "change your patch until my other patch is landed" is
the opposite of how things are supposed to be done.
I recommend you focus on your own series. If iommu-map gets merged
first, adapt.
If not, don't delay your work to accommodate stuff that is up in the air
which for all you know may never land or may take six more months.
---
bod
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH v9 1/5] media: dt-bindings: Add CAMSS device for Kaanapali
2025-12-10 22:05 ` Bryan O'Donoghue
@ 2025-12-10 23:32 ` Vijay Kumar Tumati
0 siblings, 0 replies; 17+ messages in thread
From: Vijay Kumar Tumati @ 2025-12-10 23:32 UTC (permalink / raw)
To: Bryan O'Donoghue, Dmitry Baryshkov
Cc: Hangxiang Ma, Loic Poulain, Robert Foss, Andi Shyti, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Todor Tomov,
Vladimir Zapolskiy, Mauro Carvalho Chehab, linux-arm-msm,
devicetree, linux-kernel, linux-media, Krzysztof Kozlowski
On 12/10/2025 2:05 PM, Bryan O'Donoghue wrote:
> On 10/12/2025 21:45, Bryan O'Donoghue wrote:
>> On 10/12/2025 19:36, Vijay Kumar Tumati wrote:
>>>
>>> On 12/10/2025 11:25 AM, Dmitry Baryshkov wrote:
>>>> On Wed, Dec 10, 2025 at 09:50:51AM -0800, Vijay Kumar Tumati wrote:
>>>>> On 12/8/2025 3:21 PM, Vijay Kumar Tumati wrote:
>>>>>> On 12/8/2025 2:48 PM, Dmitry Baryshkov wrote:
>>>>>>> On Mon, Dec 08, 2025 at 01:03:06PM -0800, Vijay Kumar Tumati wrote:
>>>>>>>> On 12/8/2025 11:53 AM, Dmitry Baryshkov wrote:
>>>>>>>>>> + interconnects:
>>>>>>>>>> + maxItems: 4
>>>>>>>>>> +
>>>>>>>>>> + interconnect-names:
>>>>>>>>>> + items:
>>>>>>>>>> + - const: ahb
>>>>>>>>>> + - const: hf_mnoc
>>>>>>>>>> + - const: sf_icp_mnoc
>>>>>>>>>> + - const: sf_mnoc
>>>>>>>>> You know... Failure to look around is a sin. What are the
>>>>>>>>> names of
>>>>>>>>> interconnects used by other devices? What do they actually
>>>>>>>>> describe?
>>>>>>>>>
>>>>>>>>> This is an absolute NAK.
>>>>>>>> Please feel free to correct me here but, a couple things.
>>>>>>>>
>>>>>>>> 1. This is consistent with
>>>>>>>> Documentation/devicetree/bindings/media/qcom,qcm2290-camss.yaml.
>>>>>>>> no?
>>>>>>> I see that nobody noticed an issue with Agatti, Lemans and Monaco
>>>>>>> bindings (Krzysztof?)
>>>>>>>
>>>>>>> Usually interconnect names describe the blocks that are connected.
>>>>>>> Here
>>>>>>> are the top results of a quick git grep of interconnect names
>>>>>>> through
>>>>>>> arch/arm64/dts/qcom:
>>>>>>>
>>>>>>> 729 "qup-core",
>>>>>>> 717 "qup-config",
>>>>>>> 457 "qup-memory",
>>>>>>> 41 "usb-ddr",
>>>>>>> 41 "apps-usb",
>>>>>>> 39 "pcie-mem",
>>>>>>> 39 "cpu-pcie",
>>>>>>> 28 "sdhc-ddr",
>>>>>>> 28 "cpu-sdhc",
>>>>>>> 28 "cpu-cfg",
>>>>>>> 24 "mdp0-mem",
>>>>>>> 17 "memory",
>>>>>>> 14 "ufs-ddr",
>>>>>>> 14 "mdp1-mem",
>>>>>>> 14 "cpu-ufs",
>>>>>>> 13 "video-mem",
>>>>>>> 13 "gfx-mem",
>>>>>>>
>>>>>>> I hope this gives you a pointer on how to name the interconnects.
>>>>>>>
>>>>>>>> 2. If you are referring to some other targets that use, "cam_"
>>>>>>>> prefix, we
>>>>>>>> may not need that , isn't it? If we look at these interconnects
>>>>>>>> from camera
>>>>>>>> side, as you advised for other things like this?
>>>>>>> See above.
>>>>>> I see, so the names cam-cfg, cam-hf-mem, cam-sf-mem, cam-sf-icp-mem
>>>>>> should be ok?
>>>>>>
>>>>>> Or the other option, go exactly like
>>>>>> Documentation/devicetree/bindings/media/qcom,sc8280xp-camss.yaml.
>>>>>>
>>>>>> What would you advise?
>>>>>>
>>>>> To keep it consistent with the previous generations and still
>>>>> represent the
>>>>> block name, we will go ahead with the style in qcom,sc8280xp-
>>>>> camss.yaml. If
>>>>> anyone has any concerns, please do let us know.
>>>> Krzysztof, Bryan, your opinion? My preference would be to start using
>>>> sensible names, but I wouldn't enforce that.
>>>>
>>>>>>>>>> +
>>>>>>>>>> + iommus:
>>>>>>>>>> + items:
>>>>>>>>>> + - description: VFE non-protected stream
>>>>>>>>>> + - description: ICP0 shared stream
>>>>>>>>>> + - description: ICP1 shared stream
>>>>>>>>>> + - description: IPE CDM non-protected stream
>>>>>>>>>> + - description: IPE non-protected stream
>>>>>>>>>> + - description: JPEG non-protected stream
>>>>>>>>>> + - description: OFE CDM non-protected stream
>>>>>>>>>> + - description: OFE non-protected stream
>>>>>>>>>> + - description: VFE / VFE Lite CDM non-protected stream
>>>>>>>>> This will map all IOMMUs to the same domain. Are you sure that
>>>>>>>>> this is
>>>>>>>>> what we want? Or do we wait for iommu-maps to be fixed?
>>>>> Yes, when it is available, we can start using iommu-maps to create
>>>>> separate
>>>>> context banks.
>>>> It would be necessary to justify removing items from the list.
>>>> Wouldn't
>>>> it be better to map only necessary SIDs now and add other later
>>>> once we
>>>> have iommu-maps?
>>> I will let Bryan take the call on this. He was the one who wanted all
>>> the SIDs in the bindings. Hi @Bryan, if you can kindly share your
>>> thoughts on this and the interconnect naming, we will go ahead and push
>>> rev 10 for this. I believe we have taken care of other things. Thank
>>> you.
>>>>
>>
>> Since when are we delaying patches for future patches that may land
>> never ?
>>
>> I'm fine with whatever clock name changes you can agree with Krzysztof
>> but it seems a bit ironic to me to be given feedback to "align with
>> previous dts" to then have the result be further change.
>>
>> I'd like a bit of stability and consistency TBH.
>>
>> ---
>> bod
>>
>
> My feedback is
>
> - Include the full list of SIDs
> - Stick to previous clock and interconnect names
>
> Your other alternative is to suspend Kaanapali CAMSS unless/until
> iommu-map is landed.
>
> As I say though "change your patch until my other patch is landed" is
> the opposite of how things are supposed to be done.
>
> I recommend you focus on your own series. If iommu-map gets merged
> first, adapt.
>
> If not, don't delay your work to accommodate stuff that is up in the
> air which for all you know may never land or may take six more months.
>
> ---
> bod
Makes sense. Thanks Bryan, Dmitry. We will update this to,
Interconnect names: cam_ahb, cam_hf_mnoc, cam_sf_mnoc, cam_sf_icp_mnoc,
consistent with a set of previous generations.
CX domain AXI clock names: gcc_axi_hf, gcc_axi_sf, consistent with other
bindings.
We will post rev10 with these. Thanks.
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH v9 1/5] media: dt-bindings: Add CAMSS device for Kaanapali
2025-12-10 21:45 ` Bryan O'Donoghue
2025-12-10 22:05 ` Bryan O'Donoghue
@ 2025-12-10 23:34 ` Dmitry Baryshkov
1 sibling, 0 replies; 17+ messages in thread
From: Dmitry Baryshkov @ 2025-12-10 23:34 UTC (permalink / raw)
To: Bryan O'Donoghue
Cc: Vijay Kumar Tumati, Hangxiang Ma, Loic Poulain, Robert Foss,
Andi Shyti, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Todor Tomov, Vladimir Zapolskiy, Mauro Carvalho Chehab,
linux-arm-msm, devicetree, linux-kernel, linux-media,
Krzysztof Kozlowski
On Wed, Dec 10, 2025 at 09:45:56PM +0000, Bryan O'Donoghue wrote:
> On 10/12/2025 19:36, Vijay Kumar Tumati wrote:
> >
> > On 12/10/2025 11:25 AM, Dmitry Baryshkov wrote:
> > > On Wed, Dec 10, 2025 at 09:50:51AM -0800, Vijay Kumar Tumati wrote:
> > > > On 12/8/2025 3:21 PM, Vijay Kumar Tumati wrote:
> > > > > On 12/8/2025 2:48 PM, Dmitry Baryshkov wrote:
> > > > > > On Mon, Dec 08, 2025 at 01:03:06PM -0800, Vijay Kumar Tumati wrote:
> > > > > > > On 12/8/2025 11:53 AM, Dmitry Baryshkov wrote:
> > > > > > > > > + interconnects:
> > > > > > > > > + maxItems: 4
> > > > > > > > > +
> > > > > > > > > + interconnect-names:
> > > > > > > > > + items:
> > > > > > > > > + - const: ahb
> > > > > > > > > + - const: hf_mnoc
> > > > > > > > > + - const: sf_icp_mnoc
> > > > > > > > > + - const: sf_mnoc
> > > > > > > > You know... Failure to look around is a sin. What are the names of
> > > > > > > > interconnects used by other devices? What do they actually describe?
> > > > > > > >
> > > > > > > > This is an absolute NAK.
> > > > > > > Please feel free to correct me here but, a couple things.
> > > > > > >
> > > > > > > 1. This is consistent with
> > > > > > > Documentation/devicetree/bindings/media/qcom,qcm2290-camss.yaml. no?
> > > > > > I see that nobody noticed an issue with Agatti, Lemans and Monaco
> > > > > > bindings (Krzysztof?)
> > > > > >
> > > > > > Usually interconnect names describe the blocks that are
> > > > > > connected. Here
> > > > > > are the top results of a quick git grep of interconnect names through
> > > > > > arch/arm64/dts/qcom:
> > > > > >
> > > > > > 729 "qup-core",
> > > > > > 717 "qup-config",
> > > > > > 457 "qup-memory",
> > > > > > 41 "usb-ddr",
> > > > > > 41 "apps-usb",
> > > > > > 39 "pcie-mem",
> > > > > > 39 "cpu-pcie",
> > > > > > 28 "sdhc-ddr",
> > > > > > 28 "cpu-sdhc",
> > > > > > 28 "cpu-cfg",
> > > > > > 24 "mdp0-mem",
> > > > > > 17 "memory",
> > > > > > 14 "ufs-ddr",
> > > > > > 14 "mdp1-mem",
> > > > > > 14 "cpu-ufs",
> > > > > > 13 "video-mem",
> > > > > > 13 "gfx-mem",
> > > > > >
> > > > > > I hope this gives you a pointer on how to name the interconnects.
> > > > > >
> > > > > > > 2. If you are referring to some other targets that use, "cam_"
> > > > > > > prefix, we
> > > > > > > may not need that , isn't it? If we look at these interconnects
> > > > > > > from camera
> > > > > > > side, as you advised for other things like this?
> > > > > > See above.
> > > > > I see, so the names cam-cfg, cam-hf-mem, cam-sf-mem, cam-sf-icp-mem
> > > > > should be ok?
> > > > >
> > > > > Or the other option, go exactly like
> > > > > Documentation/devicetree/bindings/media/qcom,sc8280xp-camss.yaml.
> > > > >
> > > > > What would you advise?
> > > > >
> > > > To keep it consistent with the previous generations and still
> > > > represent the
> > > > block name, we will go ahead with the style in qcom,sc8280xp-
> > > > camss.yaml. If
> > > > anyone has any concerns, please do let us know.
> > > Krzysztof, Bryan, your opinion? My preference would be to start using
> > > sensible names, but I wouldn't enforce that.
> > >
> > > > > > > > > +
> > > > > > > > > + iommus:
> > > > > > > > > + items:
> > > > > > > > > + - description: VFE non-protected stream
> > > > > > > > > + - description: ICP0 shared stream
> > > > > > > > > + - description: ICP1 shared stream
> > > > > > > > > + - description: IPE CDM non-protected stream
> > > > > > > > > + - description: IPE non-protected stream
> > > > > > > > > + - description: JPEG non-protected stream
> > > > > > > > > + - description: OFE CDM non-protected stream
> > > > > > > > > + - description: OFE non-protected stream
> > > > > > > > > + - description: VFE / VFE Lite CDM non-protected stream
> > > > > > > > This will map all IOMMUs to the same domain. Are
> > > > > > > > you sure that this is
> > > > > > > > what we want? Or do we wait for iommu-maps to be fixed?
> > > > Yes, when it is available, we can start using iommu-maps to
> > > > create separate
> > > > context banks.
> > > It would be necessary to justify removing items from the list. Wouldn't
> > > it be better to map only necessary SIDs now and add other later once we
> > > have iommu-maps?
> > I will let Bryan take the call on this. He was the one who wanted all
> > the SIDs in the bindings. Hi @Bryan, if you can kindly share your
> > thoughts on this and the interconnect naming, we will go ahead and push
> > rev 10 for this. I believe we have taken care of other things. Thank
> > you.
> > >
>
> Since when are we delaying patches for future patches that may land never ?
>
> I'm fine with whatever clock name changes you can agree with Krzysztof but
> it seems a bit ironic to me to be given feedback to "align with previous
> dts" to then have the result be further change.
>
> I'd like a bit of stability and consistency TBH.
:-)
--
With best wishes
Dmitry
^ permalink raw reply [flat|nested] 17+ messages in thread
end of thread, other threads:[~2025-12-10 23:34 UTC | newest]
Thread overview: 17+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2025-12-08 12:39 [PATCH v9 0/5] media: qcom: camss: Add Kaanapali support Hangxiang Ma
2025-12-08 12:39 ` [PATCH v9 1/5] media: dt-bindings: Add CAMSS device for Kaanapali Hangxiang Ma
2025-12-08 19:53 ` Dmitry Baryshkov
2025-12-08 21:03 ` Vijay Kumar Tumati
2025-12-08 22:48 ` Dmitry Baryshkov
2025-12-08 23:21 ` Vijay Kumar Tumati
2025-12-10 17:50 ` Vijay Kumar Tumati
2025-12-10 19:25 ` Dmitry Baryshkov
2025-12-10 19:36 ` Vijay Kumar Tumati
2025-12-10 21:45 ` Bryan O'Donoghue
2025-12-10 22:05 ` Bryan O'Donoghue
2025-12-10 23:32 ` Vijay Kumar Tumati
2025-12-10 23:34 ` Dmitry Baryshkov
2025-12-08 12:39 ` [PATCH v9 2/5] media: qcom: camss: Add Kaanapali compatible camss driver Hangxiang Ma
2025-12-08 12:39 ` [PATCH v9 3/5] media: qcom: camss: csiphy: Add support for v2.4.0 two-phase CSIPHY Hangxiang Ma
2025-12-08 12:39 ` [PATCH v9 4/5] media: qcom: camss: csid: Add support for CSID gen4 Hangxiang Ma
2025-12-08 12:39 ` [PATCH v9 5/5] media: qcom: camss: vfe: Add support for VFE gen4 Hangxiang Ma
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox