Re: [PATCH v6 1/3] dt-bindings: media: qcom: Add JPEG encoder binding
From: Atanas Filipov
Date: Sun Aug 02 2026 - 09:54:12 EST
On 8/1/2026 10:48 PM, Loic Poulain wrote:
On Fri, Jul 31, 2026 at 9:27 PM Gjorgji Rosikopulos (Consultant)
<gjorgji.rosikopulos@xxxxxxxxxxxxxxxx> wrote:
Hi Dmitry, Atanas,
On 7/30/2026 7:24 PM, Atanas Filipov wrote:
On 7/30/2026 6:39 PM, Dmitry Baryshkov wrote:
On Thu, Jul 30, 2026 at 06:05:22PM +0300, 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,sm8250-jpeg-enc.yaml | 156 ++++++++++++++++++
1 file changed, 156 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..70f573100573
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/qcom,sm8250-jpeg-enc.yaml
@@ -0,0 +1,156 @@
+# 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>
+
+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: 5
+
+ clock-names:
+ items:
+ - const: sf_axi
+ - const: core_ahb
+ - const: cpas_ahb
+ - const: cnoc_axi
+ - const: jpeg
+
+ power-domains:
+ maxItems: 3
+
+ power-domain-names:
+ items:
+ - const: titan_top
+ - const: mmcx
+ - const: mx
+
+ interconnects:
+ maxItems: 2
+
+ interconnect-names:
+ items:
+ - const: cpu-cfg
+ - 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
+ - power-domain-names
+ - 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>,
+ <&rpmhpd RPMHPD_MMCX>,
+ <&rpmhpd RPMHPD_MX>;
+ power-domain-names = "titan_top", "mmcx", "mx";
+
+ clocks = <&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 = "sf_axi",
+ "core_ahb",
+ "cpas_ahb",
+ "cnoc_axi",
+ "jpeg";
What are the pin input names for these clocks on the JPEG side? Can we
use a better name?
The name of the the clock on jpeg side(based on documentation we have) is
cam_cc_jpeg_clk, There was comment from Krzysztof "https://lkml.org/lkml/2026/5/15/1112";
to drop cam and clk, so it remains cc_jpeg or only jpeg.
As i can see in ope patches ope_clk is named as "core", do we have some general
guidance how to name those clocks? or if you have any preference or proposal it will
be included in next patchset.
In ope series I named the clocks based on OPE block PoV ant its
function, so usually the main function clock (the one you named jpeg
above) is the 'core' clock, the AHB is usually for clocking the
'config' bus and the axi one is usually for the actual 'data' bus.
IMO, it's clearer like that.
Thank you for the feedback. I'll make the necessary changes in next version.
In my opinion, there is no such thing as a better name; the only
important thing is that it matches the HW documentation. As can be seen
from the clock names in the FW shown above. So, could you be more
specific about which names you would like to see used here?
Regards,
Atanas
+
+ 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_SF QCOM_ICC_TAG_ALWAYS
+ &mc_virt SLAVE_EBI_CH0 QCOM_ICC_TAG_ALWAYS>;
+ interconnect-names = "cpu-cfg",
+ "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>;
So, you've identified the issue earlier. The shared clocks need to be
scaled, taking all users in account. Please come up with the solution
too.
One proposal is to have camnoc icc clock provider, there is implementation
available and it will be posted, What is the preference to have different
patchset or to have camnoc icc provider as part of this patchset new version?
Regards,
~Gjorgji