Re: [PATCH v5 1/3] dt-bindings: media: qcom: Add JPEG encoder binding
From: Atanas Filipov
Date: Tue Jul 28 2026 - 06:09:24 EST
On 7/28/2026 12:18 PM, Loic Poulain wrote:
On Tue, Jul 28, 2026 at 10:25 AM Atanas FilipovYou are correct. Looking at the JPEG-to-CAMNOC integration diagram
<atanas.filipov@xxxxxxxxxxxxxxxx> wrote:
Add device-tree binding for the Qualcomm JPEG encoder hardware block
present in SM8250 (Kona) SoCs.
The JPEG encoder is a standalone hardware IP within the camera subsystem
that performs JPEG compression in memory-to-memory fashion. It is
separate from the CAMSS ISP pipeline and has its own register space,
interrupt, clocks, power domain, IOMMU streams, and interconnect paths.
Signed-off-by: Atanas Filipov <atanas.filipov@xxxxxxxxxxxxxxxx>
---
.../bindings/media/qcom,sm8250-jpeg-enc.yaml | 154 ++++++++++++++++++
1 file changed, 154 insertions(+)
create mode 100644 Documentation/devicetree/bindings/media/qcom,sm8250-jpeg-enc.yaml
diff --git a/Documentation/devicetree/bindings/media/qcom,sm8250-jpeg-enc.yaml b/Documentation/devicetree/bindings/media/qcom,sm8250-jpeg-enc.yaml
new file mode 100644
index 000000000000..6aa2613bbf3b
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/qcom,sm8250-jpeg-enc.yaml
@@ -0,0 +1,154 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/media/qcom,sm8250-jpeg-enc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm JPEG Encoder
+
+maintainers:
+ - Atanas Filipov <atanas.filipov@xxxxxxxxxxxxxxxx>
+ - Gjorgji Rosikopulos <gjorgji.rosikopulos@xxxxxxxxxxxxxxxx>
+
+description:
+ Qualcomm JPEG Encoder is the JPEG encode hardware present in Qualcomm SoCs.
+ The encoder is a standalone hardware IP within the camera subsystem that
+ performs JPEG compression in memory-to-memory fashion.
+
+properties:
+ compatible:
+ enum:
+ - qcom,sm8250-jpeg-enc
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ clocks:
+ maxItems: 6
+
+ clock-names:
+ items:
+ - const: hf_axi
+ - const: sf_axi
+ - const: core_ahb
+ - const: cpas_ahb
+ - const: cnoc_axi
+ - const: jpeg
+
+ power-domains:
+ maxItems: 1
+
+ interconnects:
+ maxItems: 3
+
+ interconnect-names:
+ items:
+ - const: cpu-cfg
+ - const: hf-mnoc
+ - const: sf-mnoc
+
+ iommus:
+ description:
+ SMMU stream ID for the JPEG hardware. The stream ID 0x2040 is used
+ for the JPEG core engine on SM8250.
+ maxItems: 1
+
+ operating-points-v2: true
+
+ opp-table:
+ type: object
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - clock-names
+ - interrupts
+ - power-domains
+ - interconnects
+ - interconnect-names
+ - iommus
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/qcom,camcc-sm8250.h>
+ #include <dt-bindings/clock/qcom,gcc-sm8250.h>
+ #include <dt-bindings/interconnect/qcom,icc.h>
+ #include <dt-bindings/interconnect/qcom,sm8250.h>
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ #include <dt-bindings/power/qcom,rpmhpd.h>
+
+ jpeg-encoder@ac53000 {
+ compatible = "qcom,sm8250-jpeg-enc";
+ reg = <0x0ac53000 0x1000>;
+
+ interrupts = <GIC_SPI 474 IRQ_TYPE_EDGE_RISING>;
+
+ power-domains = <&camcc TITAN_TOP_GDSC>;
+
+ clocks = <&gcc GCC_CAMERA_HF_AXI_CLK>,
+ <&gcc GCC_CAMERA_SF_AXI_CLK>,
+ <&camcc CAM_CC_CORE_AHB_CLK>,
+ <&camcc CAM_CC_CPAS_AHB_CLK>,
+ <&camcc CAM_CC_CAMNOC_AXI_CLK>,
+ <&camcc CAM_CC_JPEG_CLK>;
+ clock-names = "hf_axi",
+ "sf_axi",
+ "core_ahb",
+ "cpas_ahb",
+ "cnoc_axi",
+ "jpeg";
+
+ interconnects = <&gem_noc MASTER_AMPSS_M0 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_EBI_CH0 QCOM_ICC_TAG_ALWAYS>,
+ <&mmss_noc MASTER_CAMNOC_SF QCOM_ICC_TAG_ALWAYS
+ &mc_virt SLAVE_EBI_CH0 QCOM_ICC_TAG_ALWAYS>;
Do you really need both SF and HF? HF is usually for the real-time
hardware macros (capture).
(same questions for axi clocks).
in the Titan JPEG HPG (Figure 3-2-2), JPEG_ENC and JPEG_DMA are
wired to the SF priority arbiter and exit through QNS_CAMNOC_1 and
QNS_CAMNOC_2 under CAMNOC_SF_QXCLK. The HF ports (QNS_CAMNOC_3,
QNS_CAMNOC_4 under CAMNOC_HF_QXCLK) are for the IFE real-time
capture path.
I will validate on hardware and if functionality is confirmed I will
remove hf-mnoc and GCC_CAMERA_HF_AXI_CLK / hf_axi in v6.
Regards,
Atanas
+ interconnect-names = "cpu-cfg",
+ "hf-mnoc",
+ "sf-mnoc";
+
+ iommus = <&apps_smmu 0x2040 0x400>;
+
+ operating-points-v2 = <&jpeg_opp_table>;
+
+ jpeg_opp_table: opp-table {
+ compatible = "operating-points-v2";
+
+ opp-100000000 {
+ opp-hz = /bits/ 64 <400000000>,
+ /bits/ 64 <100000000>;
+ required-opps = <&rpmhpd_opp_min_svs>;
+ };
+
+ opp-200000000 {
+ opp-hz = /bits/ 64 <400000000>,
+ /bits/ 64 <200000000>;
+ required-opps = <&rpmhpd_opp_low_svs>;
+ };
+
+ opp-400000000 {
+ opp-hz = /bits/ 64 <400000000>,
+ /bits/ 64 <400000000>;
+ required-opps = <&rpmhpd_opp_svs>;
+ };
+
+ opp-480000000 {
+ opp-hz = /bits/ 64 <400000000>,
+ /bits/ 64 <480000000>;
+ required-opps = <&rpmhpd_opp_svs_l1>;
+ };
+
+ opp-600000000 {
+ opp-hz = /bits/ 64 <400000000>,
+ /bits/ 64 <600000000>;
+ required-opps = <&rpmhpd_opp_nom>;
+ };
+ };
+ };
--
2.34.1