Re: [PATCH v3 2/4] dt-bindings: media: qcom: Add JPEG encoder binding
From: Vladimir Zapolskiy
Date: Mon Jun 29 2026 - 10:03:20 EST
Hi Atanas.
On 6/29/26 15:17, Atanas Filipov 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,jpeg-encoder.yaml | 160 ++++++++++++++++++
1 file changed, 160 insertions(+)
create mode 100644 Documentation/devicetree/bindings/media/qcom,jpeg-encoder.yaml
diff --git a/Documentation/devicetree/bindings/media/qcom,jpeg-encoder.yaml b/Documentation/devicetree/bindings/media/qcom,jpeg-encoder.yaml
new file mode 100644
index 000000000000..c8b4808054cb
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/qcom,jpeg-encoder.yaml
@@ -0,0 +1,160 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/media/qcom,jpeg-encoder.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm JPEG Encoder
+
+maintainers:
+ - Atanas Filipov <atanas.filipov@xxxxxxxxxxxxxxxx>
+
+description:
+ Qualcomm JPEG Encoder is the JPEG encode hardware present in Qualcomm SoCs.
+
+properties:
+ compatible:
+ enum:
+ - qcom,sm8250-jenc
+
+ 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
+
+ iommus:
+ description:
+ Two SMMU stream IDs for the JPEG hardware. The first entry is for
+ the JPEG core engine; the second is for the JPEG DMA/scale path.
+ The exact stream ID assignment is SoC-specific and not publicly
+ documented by Qualcomm.
+ minItems: 2
+ maxItems: 2
+
+ interconnects:
+ maxItems: 4
+
+ interconnect-names:
+ items:
+ - const: cpu-cfg
+ - const: hf-mnoc
+ - const: sf-mnoc
+ - const: icp-mnoc
+
+ operating-points-v2: true
+
+ opp-table:
+ type: object
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - clock-names
+ - interrupts
+ - power-domains
+ - iommus
+ - interconnects
+ - interconnect-names
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/qcom,camcc-sm8250.h>
+ #include <dt-bindings/clock/qcom,gcc-sm8250.h>
+ #include <dt-bindings/interconnect/qcom,sm8250.h>
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+
+ soc {
+ #address-cells = <2>;
+ #size-cells = <2>;
+
+ camss@ac6a000 {
+ compatible = "qcom,sm8250-camss";
+ reg = <0 0x0ac6a000 0 0x2000>;
+ #address-cells = <2>;
+ #size-cells = <2>;
+ ranges;
+
+ jpeg-encoder@ac53000 {
+ compatible = "qcom,sm8250-jenc";
+ reg = <0 0xac53000 0 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";
+ iommus = <&apps_smmu 0x2040 0x400>,
+ <&apps_smmu 0x2440 0x400>;
+
+ interconnects =
+ <&gem_noc MASTER_AMPSS_M0 0 &config_noc SLAVE_CAMERA_CFG 0>,
+ <&mmss_noc MASTER_CAMNOC_HF 0 &mc_virt SLAVE_EBI_CH0 0>,
+ <&mmss_noc MASTER_CAMNOC_SF 0 &mc_virt SLAVE_EBI_CH0 0>,
+ <&mmss_noc MASTER_CAMNOC_ICP 0 &mc_virt SLAVE_EBI_CH0 0>;
+ interconnect-names = "cpu-cfg",
+ "hf-mnoc",
+ "sf-mnoc",
+ "icp-mnoc";
Since the proper option for describing this hardware is to have it as
a child device tree node of CAMSS device tree node, which should serve
or be percepted as a bus, it makes no sense to repeat and moreover rename
bus/parent's resources, here is the list:
* "hf_axi", "sf_axi", "core_ahb", "cpas_ahb" and "cnoc_axi" clocks,
* Titan GDSC power domain and all four interconnects.
Only "jpeg" clock and iommus are left specific to the hardware description
of this IP under CAMSS, right? Thus, it should be reflected like this in
the dt description as well, and the complexity of shared resource management
has to be done in the driver, which might be tedious unfortunately, but
certainly doable.
+
+ operating-points-v2 = <&jpeg_opp_table>;
+
+ jpeg_opp_table: opp-table {
+ compatible = "operating-points-v2";
+
+ opp-300000000 {
+ opp-hz = /bits/ 64 <300000000>;
+ opp-level = <0>;
+ required-opps = <&rpmhpd_opp_svs>;
+ };
+
+ opp-400000000 {
+ opp-hz = /bits/ 64 <400000000>;
+ opp-level = <1>;
+ required-opps = <&rpmhpd_opp_svs>;
+ };
+
+ opp-480000000 {
+ opp-hz = /bits/ 64 <480000000>;
+ opp-level = <2>;
+ required-opps = <&rpmhpd_opp_svs_l1>;
+ };
+
+ opp-600000000 {
+ opp-hz = /bits/ 64 <600000000>;
+ opp-level = <3>;
+ required-opps = <&rpmhpd_opp_nom>;
+ };
+ };
+ };
+ };
+ };
--
Best wishes,
Vladimir