Re: [PATCH v4 4/5] arm64: dts: qcom: sm8250: Add JPEG encoder node
From: Atanas Filipov
Date: Mon Jul 13 2026 - 06:34:26 EST
On 7/6/2026 3:45 PM, Dmitry Baryshkov wrote:
On Mon, Jul 06, 2026 at 10:11:12AM +0300, Atanas Filipov wrote:
Add the JPEG encoder hardware node to the SM8250 device tree so the
qcom-jpeg V4L2 encoder driver can bind and operate on this platform.
Signed-off-by: Atanas Filipov <atanas.filipov@xxxxxxxxxxxxxxxx>
---
arch/arm64/boot/dts/qcom/sm8250.dtsi | 81 ++++++++++++++++++++++++++++
1 file changed, 81 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/sm8250.dtsi b/arch/arm64/boot/dts/qcom/sm8250.dtsi
index 7076720413ab..a089b706f60c 100644
--- a/arch/arm64/boot/dts/qcom/sm8250.dtsi
+++ b/arch/arm64/boot/dts/qcom/sm8250.dtsi
@@ -12,6 +12,7 @@
#include <dt-bindings/dma/qcom-gpi.h>
#include <dt-bindings/gpio/gpio.h>
#include <dt-bindings/interconnect/qcom,osm-l3.h>
+#include <dt-bindings/interconnect/qcom,icc.h>
#include <dt-bindings/interconnect/qcom,sm8250.h>
#include <dt-bindings/mailbox/qcom-ipcc.h>
#include <dt-bindings/phy/phy-qcom-qmp.h>
@@ -4471,6 +4472,10 @@ cci1_i2c1: i2c-bus@1 {
camss: camss@ac6a000 {
compatible = "qcom,sm8250-camss";
+ #address-cells = <2>;
+ #size-cells = <2>;
+ ranges;
+
status = "disabled";
reg = <0 0x0ac6a000 0 0x2000>,
@@ -4649,6 +4654,82 @@ port@5 {
reg = <5>;
};
};
+
+ jpeg-encoder@ac53000 {
+ compatible = "qcom,sm8250-jenc";
+
+ reg = <0 0x0ac53000 0 0x1000>;
0x0 instead of just 0
+
+ interrupts = <GIC_SPI 474 IRQ_TYPE_EDGE_RISING>;
+
+ 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";
What are the clock _inputs_ on the JPEG core side?
CAM_CC_JPEG_CLK is the JPEG-specific core clock. CAM_CC_CAMNOC_AXI_CLK
gates the CAMNOC data path and directly affects encode throughput.
+
+ interconnects = <&gem_noc MASTER_AMPSS_M0
+ QCOM_ICC_TAG_ACTIVE_ONLY
Put tags on the previous line (even if it is longer than 80 chars).
+ &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>;
+ 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>;
In downstream there is a dedicated CPAS driver that aggregates AHB/AXI
clock votes and bandwidth requests from all camera IP clients. No
equivalent exists in upstream. So, IMO a few approaches are possible:
1. A dedicated ICC provider that derives clock rates from bandwidth
requests — we have a successful experimental POC of this approach.
2. A dedicated driver similar to downstream CPAS.
3. The CAMSS-as-parent approach — trade-offs already discussed in this
thread.
Having each client set camnoc_axi rate independently is not a good
solution due to last-write-wins semantics. For JPEG specifically this
is a performance issue only — the encoder functions even at the parked
19.2 MHz — but it is a correctness problem in principle.
Until a proper aggregation mechanism exists upstream, the OPP table is
the only way to ensure camnoc_axi is at the correct frequency when JPEG
runs standalone.
Inside the DT example i saw bandwidth votes. Why are they gone from the
DT?
Same root cause — without a shared resource aggregation mechanism,
opp-peak/avg-kBps bandwidth votes have no effect today. Will be
revisited when such infrastructure is available upstream.
Best regards,
Atanas
+ };
+
+ 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>;
+ };
+ };
+ };
};
camcc: clock-controller@ad00000 {
--
2.34.1