Add Iris video codec to SM8750 SoC, which comes with significantly
different powering up sequence than previous SM8650, thus different
clocks and resets. For consistency keep existing clock and clock-names
naming, so the list shares common part.
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
---
qcom,sm8750-videocc bindings and clock headers dependency (will fail
build):
https://lore.kernel.org/all/20241206-sm8750_videocc-v1-0-5da6e7eea2bd@quicinc.com/
qcom,sm8750-iris bindings:
https://lore.kernel.org/r/20250714-sm8750-iris-v1-0-3006293a5bc7@linaro.org
---
arch/arm64/boot/dts/qcom/sm8750.dtsi | 112 +++++++++++++++++++++++++++++++++++
1 file changed, 112 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/sm8750.dtsi b/arch/arm64/boot/dts/qcom/sm8750.dtsi
index 4643705021c6ca095a16d8d7cc3adac920b21e82..b569f1dc347ec70f04ca9b1d19d8c0913dd02900 100644
--- a/arch/arm64/boot/dts/qcom/sm8750.dtsi
+++ b/arch/arm64/boot/dts/qcom/sm8750.dtsi
@@ -6,6 +6,7 @@
#include <dt-bindings/clock/qcom,rpmh.h>
#include <dt-bindings/clock/qcom,sm8750-gcc.h>
#include <dt-bindings/clock/qcom,sm8750-tcsr.h>
+#include <dt-bindings/clock/qcom,sm8750-videocc.h>
#include <dt-bindings/dma/qcom-gpi.h>
#include <dt-bindings/gpio/gpio.h>
#include <dt-bindings/interconnect/qcom,icc.h>
@@ -2581,6 +2582,117 @@ data-pins {
};
};
+ iris: video-codec@aa00000 {
+ compatible = "qcom,sm8750-iris";
+ reg = <0x0 0x0aa00000 0x0 0xf0000>;
+
+ clocks = <&gcc GCC_VIDEO_AXI0_CLK>,
+ <&videocc VIDEO_CC_MVS0C_CLK>,
+ <&videocc VIDEO_CC_MVS0_CLK>,
+ <&gcc GCC_VIDEO_AXI1_CLK>,
+ <&videocc VIDEO_CC_MVS0C_FREERUN_CLK>,
+ <&videocc VIDEO_CC_MVS0_FREERUN_CLK>;
+ clock-names = "iface",
+ "core",
+ "vcodec0_core",
+ "iface1",
+ "core_freerun",
+ "vcodec0_core_freerun";
+
+ dma-coherent;
+ iommus = <&apps_smmu 0x1940 0>,
+ <&apps_smmu 0x1947 0>;
+
+ interconnects = <&gem_noc MASTER_APPSS_PROC QCOM_ICC_TAG_ACTIVE_ONLY
+ &config_noc SLAVE_VENUS_CFG QCOM_ICC_TAG_ACTIVE_ONLY>,
+ <&mmss_noc MASTER_VIDEO_MVP QCOM_ICC_TAG_ALWAYS
+ &mc_virt SLAVE_EBI1 QCOM_ICC_TAG_ALWAYS>;
+ interconnect-names = "cpu-cfg",
+ "video-mem";
+
+ interrupts = <GIC_SPI 174 IRQ_TYPE_LEVEL_HIGH>;
+
+ memory-region = <&video_mem>;
+
+ operating-points-v2 = <&iris_opp_table>;
+
+ power-domains = <&videocc VIDEO_CC_MVS0C_GDSC>,
+ <&videocc VIDEO_CC_MVS0_GDSC>,
+ <&rpmhpd RPMHPD_MXC>,
+ <&rpmhpd RPMHPD_MMCX>;
+ power-domain-names = "venus",
+ "vcodec0",
+ "mxc",
+ "mmcx";
+
+ resets = <&gcc GCC_VIDEO_AXI0_CLK_ARES>,
+ <&gcc GCC_VIDEO_AXI1_CLK_ARES>,
+ <&videocc VIDEO_CC_MVS0C_FREERUN_CLK_ARES>,
+ <&videocc VIDEO_CC_MVS0_FREERUN_CLK_ARES>;
+ reset-names = "bus0",
+ "bus1",
+ "core",
+ "vcodec0_core";
+
+ /*
+ * IRIS firmware is signed by vendors, only
+ * enable in boards where the proper signed firmware
+ * is available.
+ */
+ status = "disabled";
+
+ iris_opp_table: opp-table {
+ compatible = "operating-points-v2";
+
+ opp-240000000 {
+ opp-hz = /bits/ 64 <240000000>;
+ required-opps = <&rpmhpd_opp_low_svs_d1>,
+ <&rpmhpd_opp_low_svs_d1>;
+ };
+
+ opp-338000000 {
+ opp-hz = /bits/ 64 <338000000>;
+ required-opps = <&rpmhpd_opp_low_svs>,
+ <&rpmhpd_opp_low_svs>;
+ };
+
+ opp-420000000 {
+ opp-hz = /bits/ 64 <420000000>;
+ required-opps = <&rpmhpd_opp_svs>,
+ <&rpmhpd_opp_svs>;
+ };
+
+ opp-444000000 {
+ opp-hz = /bits/ 64 <444000000>;
+ required-opps = <&rpmhpd_opp_svs_l1>,
+ <&rpmhpd_opp_svs_l1>;
+ };
+
+ opp-533333334 {
+ opp-hz = /bits/ 64 <533333334>;
+ required-opps = <&rpmhpd_opp_nom>,
+ <&rpmhpd_opp_nom>;
+ };
+
+ opp-630000000 {
+ opp-hz = /bits/ 64 <630000000>;
+ required-opps = <&rpmhpd_opp_turbo>,
+ <&rpmhpd_opp_turbo>;
+ };
+ };
+ };
+
+ videocc: clock-controller@aaf0000 {
+ compatible = "qcom,sm8750-videocc";
+ reg = <0x0 0x0aaf0000 0x0 0x10000>;
+ clocks = <&bi_tcxo_div2>,
+ <&gcc GCC_VIDEO_AHB_CLK>;
+ power-domains = <&rpmhpd RPMHPD_MMCX>;
+ #clock-cells = <1>;
+ #reset-cells = <1>;
+ #power-domain-cells = <1>;
+ };
+
pdc: interrupt-controller@b220000 {
compatible = "qcom,sm8750-pdc", "qcom,pdc";
reg = <0x0 0x0b220000 0x0 0x10000>, <0x0 0x164400f0 0x0 0x64>;
--
2.43.0On 14/07/2025 15:55, Krzysztof Kozlowski wrote:
> +
> + videocc: clock-controller@aaf0000 {
> + compatible = "qcom,sm8750-videocc";
> + reg = <0x0 0x0aaf0000 0x0 0x10000>;
> + clocks = <&bi_tcxo_div2>,
> + <&gcc GCC_VIDEO_AHB_CLK>;
> + power-domains = <&rpmhpd RPMHPD_MMCX>;
This is incomplete, need second power domain and I did not check against
qcom,sm8750-videocc schema before sending. I will send a v2 a bit later
(maybe some reviews pop up).
> + #clock-cells = <1>;
> + #reset-cells = <1>;
> + #power-domain-cells = <1>;
> + };
> +
> pdc: interrupt-controller@b220000 {
> compatible = "qcom,sm8750-pdc", "qcom,pdc";
> reg = <0x0 0x0b220000 0x0 0x10000>, <0x0 0x164400f0 0x0 0x64>;
>
Best regards,
Krzysztof
On 15/07/2025 11:32, Krzysztof Kozlowski wrote:
> On 14/07/2025 15:55, Krzysztof Kozlowski wrote:
>> +
>> + videocc: clock-controller@aaf0000 {
>> + compatible = "qcom,sm8750-videocc";
>> + reg = <0x0 0x0aaf0000 0x0 0x10000>;
>> + clocks = <&bi_tcxo_div2>,
>> + <&gcc GCC_VIDEO_AHB_CLK>;
>> + power-domains = <&rpmhpd RPMHPD_MMCX>;
>
> This is incomplete, need second power domain and I did not check against
> qcom,sm8750-videocc schema before sending. I will send a v2 a bit later
> (maybe some reviews pop up).
Heh, no. The DTS here is correct. The videocc bindings are not correct
(and that's not my patch).
Best regards,
Krzysztof
On 7/15/25 12:07 PM, Krzysztof Kozlowski wrote:
> On 15/07/2025 11:32, Krzysztof Kozlowski wrote:
>> On 14/07/2025 15:55, Krzysztof Kozlowski wrote:
>>> +
>>> + videocc: clock-controller@aaf0000 {
>>> + compatible = "qcom,sm8750-videocc";
>>> + reg = <0x0 0x0aaf0000 0x0 0x10000>;
>>> + clocks = <&bi_tcxo_div2>,
>>> + <&gcc GCC_VIDEO_AHB_CLK>;
>>> + power-domains = <&rpmhpd RPMHPD_MMCX>;
>>
>> This is incomplete, need second power domain and I did not check against
>> qcom,sm8750-videocc schema before sending. I will send a v2 a bit later
>> (maybe some reviews pop up).
>
> Heh, no. The DTS here is correct. The videocc bindings are not correct
> (and that's not my patch).
Well, you want two power domains here in either case..
Konrad
On 15/07/2025 12:09, Konrad Dybcio wrote:
> On 7/15/25 12:07 PM, Krzysztof Kozlowski wrote:
>> On 15/07/2025 11:32, Krzysztof Kozlowski wrote:
>>> On 14/07/2025 15:55, Krzysztof Kozlowski wrote:
>>>> +
>>>> + videocc: clock-controller@aaf0000 {
>>>> + compatible = "qcom,sm8750-videocc";
>>>> + reg = <0x0 0x0aaf0000 0x0 0x10000>;
>>>> + clocks = <&bi_tcxo_div2>,
>>>> + <&gcc GCC_VIDEO_AHB_CLK>;
>>>> + power-domains = <&rpmhpd RPMHPD_MMCX>;
>>>
>>> This is incomplete, need second power domain and I did not check against
>>> qcom,sm8750-videocc schema before sending. I will send a v2 a bit later
>>> (maybe some reviews pop up).
>>
>> Heh, no. The DTS here is correct. The videocc bindings are not correct
>> (and that's not my patch).
>
> Well, you want two power domains here in either case..
Are you sure? My point was one is correct and downstream confirms that
in their bindings (which is a poor argument, I know). Which one would be
the second? MM? We don't have such...
Best regards,
Krzysztof
On 7/15/25 12:34 PM, Krzysztof Kozlowski wrote:
> On 15/07/2025 12:09, Konrad Dybcio wrote:
>> On 7/15/25 12:07 PM, Krzysztof Kozlowski wrote:
>>> On 15/07/2025 11:32, Krzysztof Kozlowski wrote:
>>>> On 14/07/2025 15:55, Krzysztof Kozlowski wrote:
>>>>> +
>>>>> + videocc: clock-controller@aaf0000 {
>>>>> + compatible = "qcom,sm8750-videocc";
>>>>> + reg = <0x0 0x0aaf0000 0x0 0x10000>;
>>>>> + clocks = <&bi_tcxo_div2>,
>>>>> + <&gcc GCC_VIDEO_AHB_CLK>;
>>>>> + power-domains = <&rpmhpd RPMHPD_MMCX>;
>>>>
>>>> This is incomplete, need second power domain and I did not check against
>>>> qcom,sm8750-videocc schema before sending. I will send a v2 a bit later
>>>> (maybe some reviews pop up).
>>>
>>> Heh, no. The DTS here is correct. The videocc bindings are not correct
>>> (and that's not my patch).
>>
>> Well, you want two power domains here in either case..
> Are you sure? My point was one is correct and downstream confirms that
> in their bindings (which is a poor argument, I know). Which one would be
> the second? MM? We don't have such...
Historically clock controllers used a pair of CX/MX, with CX powering
the "meat" and MX powering the PLLs (& retention logic, IIUC).
Over time, CX was split into multiple usecase-specific domains (like
GFX), and we now have MMCX (or MM_CX - multimedia CX) for multimedia
hw specifically
In the downstream tree you're looking at, sun-regulators.dtsi aliases
VDD_MMCX_LEVEL as VDD_MM_LEVEL for $reasons, which is admittedly a
little confusing
MX has similarly been split into MXA (MX-Always [on]) and MXC
(MX-Collapsible). For Venus, you want the latter, as the hardware is
not crucial to the functioning of the SoC (the connection is of course
physically determined at SoC design stage, but it's a good heuristic
to keep in mind).
Konrad
On 15/07/2025 12:50, Konrad Dybcio wrote: >>>>>> + <&gcc GCC_VIDEO_AHB_CLK>; >>>>>> + power-domains = <&rpmhpd RPMHPD_MMCX>; >>>>> >>>>> This is incomplete, need second power domain and I did not check against >>>>> qcom,sm8750-videocc schema before sending. I will send a v2 a bit later >>>>> (maybe some reviews pop up). >>>> >>>> Heh, no. The DTS here is correct. The videocc bindings are not correct >>>> (and that's not my patch). >>> >>> Well, you want two power domains here in either case.. >> Are you sure? My point was one is correct and downstream confirms that >> in their bindings (which is a poor argument, I know). Which one would be >> the second? MM? We don't have such... > > Historically clock controllers used a pair of CX/MX, with CX powering > the "meat" and MX powering the PLLs (& retention logic, IIUC). > Over time, CX was split into multiple usecase-specific domains (like > GFX), and we now have MMCX (or MM_CX - multimedia CX) for multimedia > hw specifically > > In the downstream tree you're looking at, sun-regulators.dtsi aliases > VDD_MMCX_LEVEL as VDD_MM_LEVEL for $reasons, which is admittedly a > little confusing > > MX has similarly been split into MXA (MX-Always [on]) and MXC > (MX-Collapsible). For Venus, you want the latter, as the hardware is > not crucial to the functioning of the SoC (the connection is of course OK, so the binding is correct - the second entry is the MXC power domain. I'll fix this in v2. Thanks. Best regards, Krzysztof
On 7/15/2025 3:39 PM, Konrad Dybcio wrote:
> On 7/15/25 12:07 PM, Krzysztof Kozlowski wrote:
>> On 15/07/2025 11:32, Krzysztof Kozlowski wrote:
>>> On 14/07/2025 15:55, Krzysztof Kozlowski wrote:
>>>> +
>>>> + videocc: clock-controller@aaf0000 {
>>>> + compatible = "qcom,sm8750-videocc";
>>>> + reg = <0x0 0x0aaf0000 0x0 0x10000>;
>>>> + clocks = <&bi_tcxo_div2>,
>>>> + <&gcc GCC_VIDEO_AHB_CLK>;
>>>> + power-domains = <&rpmhpd RPMHPD_MMCX>;
>>>
>>> This is incomplete, need second power domain and I did not check against
>>> qcom,sm8750-videocc schema before sending. I will send a v2 a bit later
>>> (maybe some reviews pop up).
>>
>> Heh, no. The DTS here is correct. The videocc bindings are not correct
>> (and that's not my patch).
>
> Well, you want two power domains here in either case..
>
Videocc code changes are yet to be sent with the fixes.
--
Thanks,
Taniya Das
© 2016 - 2025 Red Hat, Inc.