Add new binding documentation for system clocks, functional clocks and
PEXTP0/1 and UFS reset controllers on MediaTek MT8196.

Reviewed-by: Nícolas F. R. A. Prado <nfraprado@collabora.com>
Co-developed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Signed-off-by: Laura Nao <laura.nao@collabora.com>
---
 .../bindings/clock/mediatek,mt8196-clock.yaml |  86 ++
 .../clock/mediatek,mt8196-sys-clock.yaml      |  81 ++
 .../dt-bindings/clock/mediatek,mt8196-clock.h | 802 ++++++++++++++++++
 .../reset/mediatek,mt8196-resets.h            |  26 +
 4 files changed, 995 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/clock/mediatek,mt8196-clock.yaml
 create mode 100644 Documentation/devicetree/bindings/clock/mediatek,mt8196-sys-clock.yaml
 create mode 100644 include/dt-bindings/clock/mediatek,mt8196-clock.h
 create mode 100644 include/dt-bindings/reset/mediatek,mt8196-resets.h

diff --git a/Documentation/devicetree/bindings/clock/mediatek,mt8196-clock.yaml b/Documentation/devicetree/bindings/clock/mediatek,mt8196-clock.yaml
new file mode 100644
index 000000000000..03ee0dff464b
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/mediatek,mt8196-clock.yaml
@@ -0,0 +1,86 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/clock/mediatek,mt8196-clock.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: MediaTek Functional Clock Controller for MT8196
+
+maintainers:
+  - Guangjie Song <guangjie.song@mediatek.com>
+  - Laura Nao <laura.nao@collabora.com>
+
+description: |
+  The clock architecture in MediaTek SoCs is structured like below:
+  PLLs -->
+          dividers -->
+                      muxes
+                           -->
+                              clock gate
+
+  The device nodes provide clock gate control in different IP blocks.
+
+properties:
+  compatible:
+    items:
+      - enum:
+          - mediatek,mt8196-imp-iic-wrap-c
+          - mediatek,mt8196-imp-iic-wrap-e
+          - mediatek,mt8196-imp-iic-wrap-n
+          - mediatek,mt8196-imp-iic-wrap-w
+          - mediatek,mt8196-mdpsys0
+          - mediatek,mt8196-mdpsys1
+          - mediatek,mt8196-pericfg-ao
+          - mediatek,mt8196-pextp0cfg-ao
+          - mediatek,mt8196-pextp1cfg-ao
+          - mediatek,mt8196-ufscfg-ao
+          - mediatek,mt8196-vencsys
+          - mediatek,mt8196-vencsys-c1
+          - mediatek,mt8196-vencsys-c2
+          - mediatek,mt8196-vdecsys
+          - mediatek,mt8196-vdecsys-soc
+          - mediatek,mt8196-vdisp-ao
+      - const: syscon
+
+  reg:
+    maxItems: 1
+
+  '#clock-cells':
+    const: 1
+
+  '#reset-cells':
+    const: 1
+    description:
+      Reset lines for PEXTP0/1 and UFS blocks.
+
+  mediatek,hardware-voter:
+    $ref: /schemas/types.yaml#/definitions/phandle
+    description:
+      On the MT8196 SoC, a Hardware Voter (HWV) backed by a fixed-function
+      MCU manages clock and power domain control across the AP and other
+      remote processors. By aggregating their votes, it ensures clocks are
+      safely enabled/disabled and power domains are active before register
+      access.
+
+required:
+  - compatible
+  - reg
+  - '#clock-cells'
+
+additionalProperties: false
+
+examples:
+  - |
+    pericfg_ao: clock-controller@16640000 {
+        compatible = "mediatek,mt8196-pericfg-ao", "syscon";
+        reg = <0x16640000 0x1000>;
+        mediatek,hardware-voter = <&scp_hwv>;
+        #clock-cells = <1>;
+    };
+  - |
+    pextp0cfg_ao: clock-controller@169b0000 {
+        compatible = "mediatek,mt8196-pextp0cfg-ao", "syscon";
+        reg = <0x169b0000 0x1000>;
+        #clock-cells = <1>;
+        #reset-cells = <1>;
+    };
diff --git a/Documentation/devicetree/bindings/clock/mediatek,mt8196-sys-clock.yaml b/Documentation/devicetree/bindings/clock/mediatek,mt8196-sys-clock.yaml
new file mode 100644
index 000000000000..2c958dd6e7b7
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/mediatek,mt8196-sys-clock.yaml
@@ -0,0 +1,81 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/clock/mediatek,mt8196-sys-clock.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: MediaTek System Clock Controller for MT8196
+
+maintainers:
+  - Guangjie Song <guangjie.song@mediatek.com>
+  - Laura Nao <laura.nao@collabora.com>
+
+description: |
+  The clock architecture in MediaTek SoCs is structured like below:
+  PLLs -->
+          dividers -->
+                      muxes
+                           -->
+                              clock gate
+
+  The apmixedsys, apmixedsys_gp2, vlpckgen, armpll, ccipll, mfgpll and ptppll
+  provide most of the PLLs which are generated from the SoC's 26MHZ crystal oscillator.
+  The topckgen, topckgen_gp2 and vlpckgen provide dividers and muxes which
+  provide the clock source to other IP blocks.
+
+properties:
+  compatible:
+    items:
+      - enum:
+          - mediatek,mt8196-apmixedsys
+          - mediatek,mt8196-armpll-b-pll-ctrl
+          - mediatek,mt8196-armpll-bl-pll-ctrl
+          - mediatek,mt8196-armpll-ll-pll-ctrl
+          - mediatek,mt8196-apmixedsys-gp2
+          - mediatek,mt8196-ccipll-pll-ctrl
+          - mediatek,mt8196-mfgpll-pll-ctrl
+          - mediatek,mt8196-mfgpll-sc0-pll-ctrl
+          - mediatek,mt8196-mfgpll-sc1-pll-ctrl
+          - mediatek,mt8196-ptppll-pll-ctrl
+          - mediatek,mt8196-topckgen
+          - mediatek,mt8196-topckgen-gp2
+          - mediatek,mt8196-vlpckgen
+      - const: syscon
+
+  reg:
+    maxItems: 1
+
+  '#clock-cells':
+    const: 1
+
+  mediatek,hardware-voter:
+    $ref: /schemas/types.yaml#/definitions/phandle
+    description:
+      On the MT8196 SoC, a Hardware Voter (HWV) backed by a fixed-function
+      MCU manages clock and power domain control across the AP and other
+      remote processors. By aggregating their votes, it ensures clocks are
+      safely enabled/disabled and power domains are active before register
+      access.
+
+required:
+  - compatible
+  - reg
+  - '#clock-cells'
+
+additionalProperties: false
+
+examples:
+  - |
+    apmixedsys_clk: syscon@10000800 {
+        compatible = "mediatek,mt8196-apmixedsys", "syscon";
+        reg = <0x10000800 0x1000>;
+        #clock-cells = <1>;
+    };
+  - |
+    topckgen: syscon@10000000 {
+        compatible = "mediatek,mt8196-topckgen", "syscon";
+        reg = <0x10000000 0x800>;
+        mediatek,hardware-voter = <&scp_hwv>;
+        #clock-cells = <1>;
+    };
+
diff --git a/include/dt-bindings/clock/mediatek,mt8196-clock.h b/include/dt-bindings/clock/mediatek,mt8196-clock.h
new file mode 100644
index 000000000000..e2b34e828e81
--- /dev/null
+++ b/include/dt-bindings/clock/mediatek,mt8196-clock.h
@@ -0,0 +1,802 @@
+/* SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause */
+/*
+ * Copyright (c) 2025 MediaTek Inc.
+ *                    Guangjie Song <guangjie.song@mediatek.com>
+ * Copyright (c) 2025 Collabora Ltd.
+ *                    Laura Nao <laura.nao@collabora.com>
+ */
+
+#ifndef _DT_BINDINGS_CLK_MT8196_H
+#define _DT_BINDINGS_CLK_MT8196_H
+
+/* CKSYS */
+#define CLK_TOP_AXI					0
+#define CLK_TOP_MEM_SUB					1
+#define CLK_TOP_IO_NOC					2
+#define CLK_TOP_P_AXI					3
+#define CLK_TOP_UFS_PEXTP0_AXI				4
+#define CLK_TOP_PEXTP1_USB_AXI				5
+#define CLK_TOP_P_FMEM_SUB				6
+#define CLK_TOP_PEXPT0_MEM_SUB				7
+#define CLK_TOP_PEXTP1_USB_MEM_SUB			8
+#define CLK_TOP_P_NOC					9
+#define CLK_TOP_EMI_N					10
+#define CLK_TOP_EMI_S					11
+#define CLK_TOP_AP2CONN_HOST				12
+#define CLK_TOP_ATB					13
+#define CLK_TOP_CIRQ					14
+#define CLK_TOP_PBUS_156M				15
+#define CLK_TOP_EFUSE					16
+#define CLK_TOP_MCL3GIC					17
+#define CLK_TOP_MCINFRA					18
+#define CLK_TOP_DSP					19
+#define CLK_TOP_MFG_REF					20
+#define CLK_TOP_MFG_EB					21
+#define CLK_TOP_UART					22
+#define CLK_TOP_SPI0_BCLK				23
+#define CLK_TOP_SPI1_BCLK				24
+#define CLK_TOP_SPI2_BCLK				25
+#define CLK_TOP_SPI3_BCLK				26
+#define CLK_TOP_SPI4_BCLK				27
+#define CLK_TOP_SPI5_BCLK				28
+#define CLK_TOP_SPI6_BCLK				29
+#define CLK_TOP_SPI7_BCLK				30
+#define CLK_TOP_MSDC30_1				31
+#define CLK_TOP_MSDC30_2				32
+#define CLK_TOP_DISP_PWM				33
+#define CLK_TOP_USB_TOP_1P				34
+#define CLK_TOP_USB_XHCI_1P				35
+#define CLK_TOP_USB_FMCNT_P1				36
+#define CLK_TOP_I2C_P					37
+#define CLK_TOP_I2C_EAST				38
+#define CLK_TOP_I2C_WEST				39
+#define CLK_TOP_I2C_NORTH				40
+#define CLK_TOP_AES_UFSFDE				41
+#define CLK_TOP_UFS					42
+#define CLK_TOP_AUD_1					43
+#define CLK_TOP_AUD_2					44
+#define CLK_TOP_ADSP					45
+#define CLK_TOP_ADSP_UARTHUB_B				46
+#define CLK_TOP_DPMAIF_MAIN				47
+#define CLK_TOP_PWM					48
+#define CLK_TOP_MCUPM					49
+#define CLK_TOP_IPSEAST					50
+#define CLK_TOP_TL					51
+#define CLK_TOP_TL_P1					52
+#define CLK_TOP_TL_P2					53
+#define CLK_TOP_EMI_INTERFACE_546			54
+#define CLK_TOP_SDF					55
+#define CLK_TOP_UARTHUB_BCLK				56
+#define CLK_TOP_DPSW_CMP_26M				57
+#define CLK_TOP_SMAP					58
+#define CLK_TOP_SSR_PKA					59
+#define CLK_TOP_SSR_DMA					60
+#define CLK_TOP_SSR_KDF					61
+#define CLK_TOP_SSR_RNG					62
+#define CLK_TOP_SPU0					63
+#define CLK_TOP_SPU1					64
+#define CLK_TOP_DXCC					65
+#define CLK_TOP_APLL_I2SIN0				66
+#define CLK_TOP_APLL_I2SIN1				67
+#define CLK_TOP_APLL_I2SIN2				68
+#define CLK_TOP_APLL_I2SIN3				69
+#define CLK_TOP_APLL_I2SIN4				70
+#define CLK_TOP_APLL_I2SIN6				71
+#define CLK_TOP_APLL_I2SOUT0				72
+#define CLK_TOP_APLL_I2SOUT1				73
+#define CLK_TOP_APLL_I2SOUT2				74
+#define CLK_TOP_APLL_I2SOUT3				75
+#define CLK_TOP_APLL_I2SOUT4				76
+#define CLK_TOP_APLL_I2SOUT6				77
+#define CLK_TOP_APLL_FMI2S				78
+#define CLK_TOP_APLL_TDMOUT				79
+#define CLK_TOP_APLL12_DIV_TDMOUT_M			80
+#define CLK_TOP_APLL12_DIV_TDMOUT_B			81
+#define CLK_TOP_MAINPLL_D3				82
+#define CLK_TOP_MAINPLL_D4				83
+#define CLK_TOP_MAINPLL_D4_D2				84
+#define CLK_TOP_MAINPLL_D4_D4				85
+#define CLK_TOP_MAINPLL_D4_D8				86
+#define CLK_TOP_MAINPLL_D5				87
+#define CLK_TOP_MAINPLL_D5_D2				88
+#define CLK_TOP_MAINPLL_D5_D4				89
+#define CLK_TOP_MAINPLL_D5_D8				90
+#define CLK_TOP_MAINPLL_D6				91
+#define CLK_TOP_MAINPLL_D6_D2				92
+#define CLK_TOP_MAINPLL_D7				93
+#define CLK_TOP_MAINPLL_D7_D2				94
+#define CLK_TOP_MAINPLL_D7_D4				95
+#define CLK_TOP_MAINPLL_D7_D8				96
+#define CLK_TOP_MAINPLL_D9				97
+#define CLK_TOP_UNIVPLL_D4				98
+#define CLK_TOP_UNIVPLL_D4_D2				99
+#define CLK_TOP_UNIVPLL_D4_D4				100
+#define CLK_TOP_UNIVPLL_D4_D8				101
+#define CLK_TOP_UNIVPLL_D5				102
+#define CLK_TOP_UNIVPLL_D5_D2				103
+#define CLK_TOP_UNIVPLL_D5_D4				104
+#define CLK_TOP_UNIVPLL_D6				105
+#define CLK_TOP_UNIVPLL_D6_D2				106
+#define CLK_TOP_UNIVPLL_D6_D4				107
+#define CLK_TOP_UNIVPLL_D6_D8				108
+#define CLK_TOP_UNIVPLL_D6_D16				109
+#define CLK_TOP_UNIVPLL_192M				110
+#define CLK_TOP_UNIVPLL_192M_D4				111
+#define CLK_TOP_UNIVPLL_192M_D8				112
+#define CLK_TOP_UNIVPLL_192M_D16			113
+#define CLK_TOP_UNIVPLL_192M_D32			114
+#define CLK_TOP_UNIVPLL_192M_D10			115
+#define CLK_TOP_TVDPLL1_D2				116
+#define CLK_TOP_MSDCPLL_D2				117
+#define CLK_TOP_OSC_D2					118
+#define CLK_TOP_OSC_D3					119
+#define CLK_TOP_OSC_D4					120
+#define CLK_TOP_OSC_D5					121
+#define CLK_TOP_OSC_D7					122
+#define CLK_TOP_OSC_D8					123
+#define CLK_TOP_OSC_D10					124
+#define CLK_TOP_OSC_D14					125
+#define CLK_TOP_OSC_D20					126
+#define CLK_TOP_OSC_D32					127
+#define CLK_TOP_OSC_D40					128
+#define CLK_TOP_SFLASH					129
+
+/* APMIXEDSYS */
+#define CLK_APMIXED_MAINPLL				0
+#define CLK_APMIXED_UNIVPLL				1
+#define CLK_APMIXED_MSDCPLL				2
+#define CLK_APMIXED_ADSPPLL				3
+#define CLK_APMIXED_EMIPLL				4
+#define CLK_APMIXED_EMIPLL2				5
+#define CLK_APMIXED_NET1PLL				6
+#define CLK_APMIXED_SGMIIPLL				7
+
+/* CKSYS_GP2 */
+#define CLK_TOP2_SENINF0				0
+#define CLK_TOP2_SENINF1				1
+#define CLK_TOP2_SENINF2				2
+#define CLK_TOP2_SENINF3				3
+#define CLK_TOP2_SENINF4				4
+#define CLK_TOP2_SENINF5				5
+#define CLK_TOP2_IMG1					6
+#define CLK_TOP2_IPE					7
+#define CLK_TOP2_CAM					8
+#define CLK_TOP2_CAMTM					9
+#define CLK_TOP2_DPE					10
+#define CLK_TOP2_VDEC					11
+#define CLK_TOP2_CCUSYS					12
+#define CLK_TOP2_CCUTM					13
+#define CLK_TOP2_VENC					14
+#define CLK_TOP2_DP1					15
+#define CLK_TOP2_DP0					16
+#define CLK_TOP2_DISP					17
+#define CLK_TOP2_MDP					18
+#define CLK_TOP2_MMINFRA				19
+#define CLK_TOP2_MMINFRA_SNOC				20
+#define CLK_TOP2_MMUP					21
+#define CLK_TOP2_MMINFRA_AO				22
+#define CLK_TOP2_MAINPLL2_D2				23
+#define CLK_TOP2_MAINPLL2_D3				24
+#define CLK_TOP2_MAINPLL2_D4				25
+#define CLK_TOP2_MAINPLL2_D4_D2				26
+#define CLK_TOP2_MAINPLL2_D4_D4				27
+#define CLK_TOP2_MAINPLL2_D5				28
+#define CLK_TOP2_MAINPLL2_D5_D2				29
+#define CLK_TOP2_MAINPLL2_D6				30
+#define CLK_TOP2_MAINPLL2_D6_D2				31
+#define CLK_TOP2_MAINPLL2_D7				32
+#define CLK_TOP2_MAINPLL2_D7_D2				33
+#define CLK_TOP2_MAINPLL2_D9				34
+#define CLK_TOP2_UNIVPLL2_D3				35
+#define CLK_TOP2_UNIVPLL2_D4				36
+#define CLK_TOP2_UNIVPLL2_D4_D2				37
+#define CLK_TOP2_UNIVPLL2_D5				38
+#define CLK_TOP2_UNIVPLL2_D5_D2				39
+#define CLK_TOP2_UNIVPLL2_D6				40
+#define CLK_TOP2_UNIVPLL2_D6_D2				41
+#define CLK_TOP2_UNIVPLL2_D6_D4				42
+#define CLK_TOP2_UNIVPLL2_D7				43
+#define CLK_TOP2_IMGPLL_D2				44
+#define CLK_TOP2_IMGPLL_D4				45
+#define CLK_TOP2_IMGPLL_D5				46
+#define CLK_TOP2_IMGPLL_D5_D2				47
+#define CLK_TOP2_MMPLL2_D3				48
+#define CLK_TOP2_MMPLL2_D4				49
+#define CLK_TOP2_MMPLL2_D4_D2				50
+#define CLK_TOP2_MMPLL2_D5				51
+#define CLK_TOP2_MMPLL2_D5_D2				52
+#define CLK_TOP2_MMPLL2_D6				53
+#define CLK_TOP2_MMPLL2_D6_D2				54
+#define CLK_TOP2_MMPLL2_D7				55
+#define CLK_TOP2_MMPLL2_D9				56
+#define CLK_TOP2_TVDPLL1_D4				57
+#define CLK_TOP2_TVDPLL1_D8				58
+#define CLK_TOP2_TVDPLL1_D16				59
+#define CLK_TOP2_TVDPLL2_D2				60
+#define CLK_TOP2_TVDPLL2_D4				61
+#define CLK_TOP2_TVDPLL2_D8				62
+#define CLK_TOP2_TVDPLL2_D16				63
+#define CLK_TOP2_DVO					64
+#define CLK_TOP2_DVO_FAVT				65
+#define CLK_TOP2_TVDPLL3_D2				66
+#define CLK_TOP2_TVDPLL3_D4				67
+#define CLK_TOP2_TVDPLL3_D8				68
+#define CLK_TOP2_TVDPLL3_D16				69
+
+/* APMIXEDSYS_GP2 */
+#define CLK_APMIXED2_MAINPLL2				0
+#define CLK_APMIXED2_UNIVPLL2				1
+#define CLK_APMIXED2_MMPLL2				2
+#define CLK_APMIXED2_IMGPLL				3
+#define CLK_APMIXED2_TVDPLL1				4
+#define CLK_APMIXED2_TVDPLL2				5
+#define CLK_APMIXED2_TVDPLL3				6
+
+/* IMP_IIC_WRAP_E */
+#define CLK_IMPE_I2C5					0
+
+/* IMP_IIC_WRAP_W */
+#define CLK_IMPW_I2C0					0
+#define CLK_IMPW_I2C3					1
+#define CLK_IMPW_I2C6					2
+#define CLK_IMPW_I2C10					3
+
+/* IMP_IIC_WRAP_N */
+#define CLK_IMPN_I2C1					0
+#define CLK_IMPN_I2C2					1
+#define CLK_IMPN_I2C4					2
+#define CLK_IMPN_I2C7					3
+#define CLK_IMPN_I2C8					4
+#define CLK_IMPN_I2C9					5
+
+/* IMP_IIC_WRAP_C */
+#define CLK_IMPC_I2C11					0
+#define CLK_IMPC_I2C12					1
+#define CLK_IMPC_I2C13					2
+#define CLK_IMPC_I2C14					3
+
+/* PERICFG_AO */
+#define CLK_PERI_AO_UART0_BCLK				0
+#define CLK_PERI_AO_UART1_BCLK				1
+#define CLK_PERI_AO_UART2_BCLK				2
+#define CLK_PERI_AO_UART3_BCLK				3
+#define CLK_PERI_AO_UART4_BCLK				4
+#define CLK_PERI_AO_UART5_BCLK				5
+#define CLK_PERI_AO_PWM_X16W_HCLK			6
+#define CLK_PERI_AO_PWM_X16W_BCLK			7
+#define CLK_PERI_AO_PWM_PWM_BCLK0			8
+#define CLK_PERI_AO_PWM_PWM_BCLK1			9
+#define CLK_PERI_AO_PWM_PWM_BCLK2			10
+#define CLK_PERI_AO_PWM_PWM_BCLK3			11
+#define CLK_PERI_AO_SPI0_BCLK				12
+#define CLK_PERI_AO_SPI1_BCLK				13
+#define CLK_PERI_AO_SPI2_BCLK				14
+#define CLK_PERI_AO_SPI3_BCLK				15
+#define CLK_PERI_AO_SPI4_BCLK				16
+#define CLK_PERI_AO_SPI5_BCLK				17
+#define CLK_PERI_AO_SPI6_BCLK				18
+#define CLK_PERI_AO_SPI7_BCLK				19
+#define CLK_PERI_AO_AP_DMA_X32W_BCLK			20
+#define CLK_PERI_AO_MSDC1_MSDC_SRC			21
+#define CLK_PERI_AO_MSDC1_HCLK				22
+#define CLK_PERI_AO_MSDC1_AXI				23
+#define CLK_PERI_AO_MSDC1_HCLK_WRAP			24
+#define CLK_PERI_AO_MSDC2_MSDC_SRC			25
+#define CLK_PERI_AO_MSDC2_HCLK				26
+#define CLK_PERI_AO_MSDC2_AXI				27
+#define CLK_PERI_AO_MSDC2_HCLK_WRAP			28
+#define CLK_PERI_AO_FLASHIF_FLASH			29
+#define CLK_PERI_AO_FLASHIF_27M				30
+#define CLK_PERI_AO_FLASHIF_DRAM			31
+#define CLK_PERI_AO_FLASHIF_AXI				32
+#define CLK_PERI_AO_FLASHIF_BCLK			33
+
+/* UFSCFG_AO */
+#define CLK_UFSAO_UNIPRO_TX_SYM				0
+#define CLK_UFSAO_UNIPRO_RX_SYM0			1
+#define CLK_UFSAO_UNIPRO_RX_SYM1			2
+#define CLK_UFSAO_UNIPRO_SYS				3
+#define CLK_UFSAO_UNIPRO_SAP				4
+#define CLK_UFSAO_PHY_SAP				5
+#define CLK_UFSAO_UFSHCI_UFS				6
+#define CLK_UFSAO_UFSHCI_AES				7
+
+/* PEXTP0CFG_AO */
+#define CLK_PEXT_PEXTP_MAC_P0_TL			0
+#define CLK_PEXT_PEXTP_MAC_P0_REF			1
+#define CLK_PEXT_PEXTP_PHY_P0_MCU_BUS			2
+#define CLK_PEXT_PEXTP_PHY_P0_PEXTP_REF			3
+#define CLK_PEXT_PEXTP_MAC_P0_AXI_250			4
+#define CLK_PEXT_PEXTP_MAC_P0_AHB_APB			5
+#define CLK_PEXT_PEXTP_MAC_P0_PL_P			6
+#define CLK_PEXT_PEXTP_VLP_AO_P0_LP			7
+
+/* PEXTP1CFG_AO */
+#define CLK_PEXT1_PEXTP_MAC_P1_TL			0
+#define CLK_PEXT1_PEXTP_MAC_P1_REF			1
+#define CLK_PEXT1_PEXTP_MAC_P2_TL			2
+#define CLK_PEXT1_PEXTP_MAC_P2_REF			3
+#define CLK_PEXT1_PEXTP_PHY_P1_MCU_BUS			4
+#define CLK_PEXT1_PEXTP_PHY_P1_PEXTP_REF		5
+#define CLK_PEXT1_PEXTP_PHY_P2_MCU_BUS			6
+#define CLK_PEXT1_PEXTP_PHY_P2_PEXTP_REF		7
+#define CLK_PEXT1_PEXTP_MAC_P1_AXI_250			8
+#define CLK_PEXT1_PEXTP_MAC_P1_AHB_APB			9
+#define CLK_PEXT1_PEXTP_MAC_P1_PL_P			10
+#define CLK_PEXT1_PEXTP_MAC_P2_AXI_250			11
+#define CLK_PEXT1_PEXTP_MAC_P2_AHB_APB			12
+#define CLK_PEXT1_PEXTP_MAC_P2_PL_P			13
+#define CLK_PEXT1_PEXTP_VLP_AO_P1_LP			14
+#define CLK_PEXT1_PEXTP_VLP_AO_P2_LP			15
+
+/* VLP_CKSYS */
+#define CLK_VLP_APLL1					0
+#define CLK_VLP_APLL2					1
+#define CLK_VLP_SCP					2
+#define CLK_VLP_SCP_SPI					3
+#define CLK_VLP_SCP_IIC					4
+#define CLK_VLP_SCP_IIC_HS				5
+#define CLK_VLP_PWRAP_ULPOSC				6
+#define CLK_VLP_SPMI_M_TIA_32K				7
+#define CLK_VLP_APXGPT_26M_B				8
+#define CLK_VLP_DPSW					9
+#define CLK_VLP_DPSW_CENTRAL				10
+#define CLK_VLP_SPMI_M_MST				11
+#define CLK_VLP_DVFSRC					12
+#define CLK_VLP_PWM_VLP					13
+#define CLK_VLP_AXI_VLP					14
+#define CLK_VLP_SYSTIMER_26M				15
+#define CLK_VLP_SSPM					16
+#define CLK_VLP_SRCK					17
+#define CLK_VLP_CAMTG0					18
+#define CLK_VLP_CAMTG1					19
+#define CLK_VLP_CAMTG2					20
+#define CLK_VLP_CAMTG3					21
+#define CLK_VLP_CAMTG4					22
+#define CLK_VLP_CAMTG5					23
+#define CLK_VLP_CAMTG6					24
+#define CLK_VLP_CAMTG7					25
+#define CLK_VLP_SSPM_26M				26
+#define CLK_VLP_ULPOSC_SSPM				27
+#define CLK_VLP_VLP_PBUS_26M				28
+#define CLK_VLP_DEBUG_ERR_FLAG				29
+#define CLK_VLP_DPMSRDMA				30
+#define CLK_VLP_VLP_PBUS_156M				31
+#define CLK_VLP_SPM					32
+#define CLK_VLP_MMINFRA					33
+#define CLK_VLP_USB_TOP					34
+#define CLK_VLP_USB_XHCI				35
+#define CLK_VLP_NOC_VLP					36
+#define CLK_VLP_AUDIO_H					37
+#define CLK_VLP_AUD_ENGEN1				38
+#define CLK_VLP_AUD_ENGEN2				39
+#define CLK_VLP_AUD_INTBUS				40
+#define CLK_VLP_SPVLP_26M				41
+#define CLK_VLP_SPU0_VLP				42
+#define CLK_VLP_SPU1_VLP				43
+#define CLK_VLP_APLL1_D4				44
+#define CLK_VLP_APLL1_D8				45
+#define CLK_VLP_APLL2_D4				46
+#define CLK_VLP_APLL2_D8				47
+
+/* DISPSYS_CONFIG */
+#define CLK_MM_CONFIG					0
+#define CLK_MM_DISP_MUTEX0				1
+#define CLK_MM_DISP_AAL0				2
+#define CLK_MM_DISP_AAL1				3
+#define CLK_MM_DISP_C3D0				4
+#define CLK_MM_DISP_C3D1				5
+#define CLK_MM_DISP_C3D2				6
+#define CLK_MM_DISP_C3D3				7
+#define CLK_MM_DISP_CCORR0				8
+#define CLK_MM_DISP_CCORR1				9
+#define CLK_MM_DISP_CCORR2				10
+#define CLK_MM_DISP_CCORR3				11
+#define CLK_MM_DISP_CHIST0				12
+#define CLK_MM_DISP_CHIST1				13
+#define CLK_MM_DISP_COLOR0				14
+#define CLK_MM_DISP_COLOR1				15
+#define CLK_MM_DISP_DITHER0				16
+#define CLK_MM_DISP_DITHER1				17
+#define CLK_MM_DISP_DLI_ASYNC0				18
+#define CLK_MM_DISP_DLI_ASYNC1				19
+#define CLK_MM_DISP_DLI_ASYNC2				20
+#define CLK_MM_DISP_DLI_ASYNC3				21
+#define CLK_MM_DISP_DLI_ASYNC4				22
+#define CLK_MM_DISP_DLI_ASYNC5				23
+#define CLK_MM_DISP_DLI_ASYNC6				24
+#define CLK_MM_DISP_DLI_ASYNC7				25
+#define CLK_MM_DISP_DLI_ASYNC8				26
+#define CLK_MM_DISP_DLI_ASYNC9				27
+#define CLK_MM_DISP_DLI_ASYNC10				28
+#define CLK_MM_DISP_DLI_ASYNC11				29
+#define CLK_MM_DISP_DLI_ASYNC12				30
+#define CLK_MM_DISP_DLI_ASYNC13				31
+#define CLK_MM_DISP_DLI_ASYNC14				32
+#define CLK_MM_DISP_DLI_ASYNC15				33
+#define CLK_MM_DISP_DLO_ASYNC0				34
+#define CLK_MM_DISP_DLO_ASYNC1				35
+#define CLK_MM_DISP_DLO_ASYNC2				36
+#define CLK_MM_DISP_DLO_ASYNC3				37
+#define CLK_MM_DISP_DLO_ASYNC4				38
+#define CLK_MM_DISP_DLO_ASYNC5				39
+#define CLK_MM_DISP_DLO_ASYNC6				40
+#define CLK_MM_DISP_DLO_ASYNC7				41
+#define CLK_MM_DISP_DLO_ASYNC8				42
+#define CLK_MM_DISP_GAMMA0				43
+#define CLK_MM_DISP_GAMMA1				44
+#define CLK_MM_MDP_AAL0					45
+#define CLK_MM_MDP_AAL1					46
+#define CLK_MM_MDP_RDMA0				47
+#define CLK_MM_DISP_POSTMASK0				48
+#define CLK_MM_DISP_POSTMASK1				49
+#define CLK_MM_MDP_RSZ0					50
+#define CLK_MM_MDP_RSZ1					51
+#define CLK_MM_DISP_SPR0				52
+#define CLK_MM_DISP_TDSHP0				53
+#define CLK_MM_DISP_TDSHP1				54
+#define CLK_MM_DISP_WDMA0				55
+#define CLK_MM_DISP_Y2R0				56
+#define CLK_MM_SMI_SUB_COMM0				57
+#define CLK_MM_DISP_FAKE_ENG0				58
+
+/* DISPSYS1_CONFIG */
+#define CLK_MM1_DISPSYS1_CONFIG				0
+#define CLK_MM1_DISPSYS1_S_CONFIG			1
+#define CLK_MM1_DISP_MUTEX0				2
+#define CLK_MM1_DISP_DLI_ASYNC20			3
+#define CLK_MM1_DISP_DLI_ASYNC21			4
+#define CLK_MM1_DISP_DLI_ASYNC22			5
+#define CLK_MM1_DISP_DLI_ASYNC23			6
+#define CLK_MM1_DISP_DLI_ASYNC24			7
+#define CLK_MM1_DISP_DLI_ASYNC25			8
+#define CLK_MM1_DISP_DLI_ASYNC26			9
+#define CLK_MM1_DISP_DLI_ASYNC27			10
+#define CLK_MM1_DISP_DLI_ASYNC28			11
+#define CLK_MM1_DISP_RELAY0				12
+#define CLK_MM1_DISP_RELAY1				13
+#define CLK_MM1_DISP_RELAY2				14
+#define CLK_MM1_DISP_RELAY3				15
+#define CLK_MM1_DISP_DP_INTF0				16
+#define CLK_MM1_DISP_DP_INTF1				17
+#define CLK_MM1_DISP_DSC_WRAP0				18
+#define CLK_MM1_DISP_DSC_WRAP1				19
+#define CLK_MM1_DISP_DSC_WRAP2				20
+#define CLK_MM1_DISP_DSC_WRAP3				21
+#define CLK_MM1_DISP_DSI0				22
+#define CLK_MM1_DISP_DSI1				23
+#define CLK_MM1_DISP_DSI2				24
+#define CLK_MM1_DISP_DVO0				25
+#define CLK_MM1_DISP_GDMA0				26
+#define CLK_MM1_DISP_MERGE0				27
+#define CLK_MM1_DISP_MERGE1				28
+#define CLK_MM1_DISP_MERGE2				29
+#define CLK_MM1_DISP_ODDMR0				30
+#define CLK_MM1_DISP_POSTALIGN0				31
+#define CLK_MM1_DISP_DITHER2				32
+#define CLK_MM1_DISP_R2Y0				33
+#define CLK_MM1_DISP_SPLITTER0				34
+#define CLK_MM1_DISP_SPLITTER1				35
+#define CLK_MM1_DISP_SPLITTER2				36
+#define CLK_MM1_DISP_SPLITTER3				37
+#define CLK_MM1_DISP_VDCM0				38
+#define CLK_MM1_DISP_WDMA1				39
+#define CLK_MM1_DISP_WDMA2				40
+#define CLK_MM1_DISP_WDMA3				41
+#define CLK_MM1_DISP_WDMA4				42
+#define CLK_MM1_MDP_RDMA1				43
+#define CLK_MM1_SMI_LARB0				44
+#define CLK_MM1_MOD1					45
+#define CLK_MM1_MOD2					46
+#define CLK_MM1_MOD3					47
+#define CLK_MM1_MOD4					48
+#define CLK_MM1_MOD5					49
+#define CLK_MM1_MOD6					50
+#define CLK_MM1_CG0					51
+#define CLK_MM1_CG1					52
+#define CLK_MM1_CG2					53
+#define CLK_MM1_CG3					54
+#define CLK_MM1_CG4					55
+#define CLK_MM1_CG5					56
+#define CLK_MM1_CG6					57
+#define CLK_MM1_CG7					58
+#define CLK_MM1_F26M					59
+
+/* OVLSYS_CONFIG */
+#define CLK_OVLSYS_CONFIG				0
+#define CLK_OVL_FAKE_ENG0				1
+#define CLK_OVL_FAKE_ENG1				2
+#define CLK_OVL_MUTEX0					3
+#define CLK_OVL_EXDMA0					4
+#define CLK_OVL_EXDMA1					5
+#define CLK_OVL_EXDMA2					6
+#define CLK_OVL_EXDMA3					7
+#define CLK_OVL_EXDMA4					8
+#define CLK_OVL_EXDMA5					9
+#define CLK_OVL_EXDMA6					10
+#define CLK_OVL_EXDMA7					11
+#define CLK_OVL_EXDMA8					12
+#define CLK_OVL_EXDMA9					13
+#define CLK_OVL_BLENDER0				14
+#define CLK_OVL_BLENDER1				15
+#define CLK_OVL_BLENDER2				16
+#define CLK_OVL_BLENDER3				17
+#define CLK_OVL_BLENDER4				18
+#define CLK_OVL_BLENDER5				19
+#define CLK_OVL_BLENDER6				20
+#define CLK_OVL_BLENDER7				21
+#define CLK_OVL_BLENDER8				22
+#define CLK_OVL_BLENDER9				23
+#define CLK_OVL_OUTPROC0				24
+#define CLK_OVL_OUTPROC1				25
+#define CLK_OVL_OUTPROC2				26
+#define CLK_OVL_OUTPROC3				27
+#define CLK_OVL_OUTPROC4				28
+#define CLK_OVL_OUTPROC5				29
+#define CLK_OVL_MDP_RSZ0				30
+#define CLK_OVL_MDP_RSZ1				31
+#define CLK_OVL_DISP_WDMA0				32
+#define CLK_OVL_DISP_WDMA1				33
+#define CLK_OVL_UFBC_WDMA0				34
+#define CLK_OVL_MDP_RDMA0				35
+#define CLK_OVL_MDP_RDMA1				36
+#define CLK_OVL_BWM0					37
+#define CLK_OVL_DLI0					38
+#define CLK_OVL_DLI1					39
+#define CLK_OVL_DLI2					40
+#define CLK_OVL_DLI3					41
+#define CLK_OVL_DLI4					42
+#define CLK_OVL_DLI5					43
+#define CLK_OVL_DLI6					44
+#define CLK_OVL_DLI7					45
+#define CLK_OVL_DLI8					46
+#define CLK_OVL_DLO0					47
+#define CLK_OVL_DLO1					48
+#define CLK_OVL_DLO2					49
+#define CLK_OVL_DLO3					50
+#define CLK_OVL_DLO4					51
+#define CLK_OVL_DLO5					52
+#define CLK_OVL_DLO6					53
+#define CLK_OVL_DLO7					54
+#define CLK_OVL_DLO8					55
+#define CLK_OVL_DLO9					56
+#define CLK_OVL_DLO10					57
+#define CLK_OVL_DLO11					58
+#define CLK_OVL_DLO12					59
+#define CLK_OVLSYS_RELAY0				60
+#define CLK_OVL_INLINEROT0				61
+#define CLK_OVL_SMI					62
+#define CLK_OVL_SMI_SMI					63
+
+
+/* OVLSYS1_CONFIG */
+#define CLK_OVL1_OVLSYS_CONFIG				0
+#define CLK_OVL1_OVL_FAKE_ENG0				1
+#define CLK_OVL1_OVL_FAKE_ENG1				2
+#define CLK_OVL1_OVL_MUTEX0				3
+#define CLK_OVL1_OVL_EXDMA0				4
+#define CLK_OVL1_OVL_EXDMA1				5
+#define CLK_OVL1_OVL_EXDMA2				6
+#define CLK_OVL1_OVL_EXDMA3				7
+#define CLK_OVL1_OVL_EXDMA4				8
+#define CLK_OVL1_OVL_EXDMA5				9
+#define CLK_OVL1_OVL_EXDMA6				10
+#define CLK_OVL1_OVL_EXDMA7				11
+#define CLK_OVL1_OVL_EXDMA8				12
+#define CLK_OVL1_OVL_EXDMA9				13
+#define CLK_OVL1_OVL_BLENDER0				14
+#define CLK_OVL1_OVL_BLENDER1				15
+#define CLK_OVL1_OVL_BLENDER2				16
+#define CLK_OVL1_OVL_BLENDER3				17
+#define CLK_OVL1_OVL_BLENDER4				18
+#define CLK_OVL1_OVL_BLENDER5				19
+#define CLK_OVL1_OVL_BLENDER6				20
+#define CLK_OVL1_OVL_BLENDER7				21
+#define CLK_OVL1_OVL_BLENDER8				22
+#define CLK_OVL1_OVL_BLENDER9				23
+#define CLK_OVL1_OVL_OUTPROC0				24
+#define CLK_OVL1_OVL_OUTPROC1				25
+#define CLK_OVL1_OVL_OUTPROC2				26
+#define CLK_OVL1_OVL_OUTPROC3				27
+#define CLK_OVL1_OVL_OUTPROC4				28
+#define CLK_OVL1_OVL_OUTPROC5				29
+#define CLK_OVL1_OVL_MDP_RSZ0				30
+#define CLK_OVL1_OVL_MDP_RSZ1				31
+#define CLK_OVL1_OVL_DISP_WDMA0				32
+#define CLK_OVL1_OVL_DISP_WDMA1				33
+#define CLK_OVL1_OVL_UFBC_WDMA0				34
+#define CLK_OVL1_OVL_MDP_RDMA0				35
+#define CLK_OVL1_OVL_MDP_RDMA1				36
+#define CLK_OVL1_OVL_BWM0				37
+#define CLK_OVL1_DLI0					38
+#define CLK_OVL1_DLI1					39
+#define CLK_OVL1_DLI2					40
+#define CLK_OVL1_DLI3					41
+#define CLK_OVL1_DLI4					42
+#define CLK_OVL1_DLI5					43
+#define CLK_OVL1_DLI6					44
+#define CLK_OVL1_DLI7					45
+#define CLK_OVL1_DLI8					46
+#define CLK_OVL1_DLO0					47
+#define CLK_OVL1_DLO1					48
+#define CLK_OVL1_DLO2					49
+#define CLK_OVL1_DLO3					50
+#define CLK_OVL1_DLO4					51
+#define CLK_OVL1_DLO5					52
+#define CLK_OVL1_DLO6					53
+#define CLK_OVL1_DLO7					54
+#define CLK_OVL1_DLO8					55
+#define CLK_OVL1_DLO9					56
+#define CLK_OVL1_DLO10					57
+#define CLK_OVL1_DLO11					58
+#define CLK_OVL1_DLO12					59
+#define CLK_OVL1_OVLSYS_RELAY0				60
+#define CLK_OVL1_OVL_INLINEROT0				61
+#define CLK_OVL1_SMI					62
+
+
+/* VDEC_SOC_GCON_BASE */
+#define CLK_VDE1_LARB1_CKEN				0
+#define CLK_VDE1_LAT_CKEN				1
+#define CLK_VDE1_LAT_ACTIVE				2
+#define CLK_VDE1_LAT_CKEN_ENG				3
+#define CLK_VDE1_VDEC_CKEN				4
+#define CLK_VDE1_VDEC_ACTIVE				5
+#define CLK_VDE1_VDEC_CKEN_ENG				6
+#define CLK_VDE1_VDEC_SOC_APTV_EN			7
+#define CLK_VDE1_VDEC_SOC_APTV_TOP_EN			8
+#define CLK_VDE1_VDEC_SOC_IPS_EN			9
+
+/* VDEC_GCON_BASE */
+#define CLK_VDE2_LARB1_CKEN				0
+#define CLK_VDE2_LAT_CKEN				1
+#define CLK_VDE2_LAT_ACTIVE				2
+#define CLK_VDE2_LAT_CKEN_ENG				3
+#define CLK_VDE2_VDEC_CKEN				4
+#define CLK_VDE2_VDEC_ACTIVE				5
+#define CLK_VDE2_VDEC_CKEN_ENG				6
+
+/* VENC_GCON */
+#define CLK_VEN1_CKE0_LARB				0
+#define CLK_VEN1_CKE1_VENC				1
+#define CLK_VEN1_CKE2_JPGENC				2
+#define CLK_VEN1_CKE3_JPGDEC				3
+#define CLK_VEN1_CKE4_JPGDEC_C1				4
+#define CLK_VEN1_CKE5_GALS				5
+#define CLK_VEN1_CKE29_VENC_ADAB_CTRL			6
+#define CLK_VEN1_CKE29_VENC_XPC_CTRL			7
+#define CLK_VEN1_CKE6_GALS_SRAM				8
+#define CLK_VEN1_RES_FLAT				9
+
+/* VENC_GCON_CORE1 */
+#define CLK_VEN2_CKE0_LARB				0
+#define CLK_VEN2_CKE1_VENC				1
+#define CLK_VEN2_CKE2_JPGENC				2
+#define CLK_VEN2_CKE3_JPGDEC				3
+#define CLK_VEN2_CKE5_GALS				4
+#define CLK_VEN2_CKE29_VENC_XPC_CTRL			5
+#define CLK_VEN2_CKE6_GALS_SRAM				6
+#define CLK_VEN2_RES_FLAT				7
+
+/* VENC_GCON_CORE2 */
+#define CLK_VEN_C2_CKE0_LARB				0
+#define CLK_VEN_C2_CKE1_VENC				1
+#define CLK_VEN_C2_CKE5_GALS				2
+#define CLK_VEN_C2_CKE29_VENC_XPC_CTRL			3
+#define CLK_VEN_C2_CKE6_GALS_SRAM			4
+#define CLK_VEN_C2_RES_FLAT				5
+
+/* MDPSYS_CONFIG */
+#define CLK_MDP_MDP_MUTEX0				0
+#define CLK_MDP_SMI0					1
+#define CLK_MDP_SMI0_SMI				2
+#define CLK_MDP_APB_BUS					3
+#define CLK_MDP_MDP_RDMA0				4
+#define CLK_MDP_MDP_RDMA1				5
+#define CLK_MDP_MDP_RDMA2				6
+#define CLK_MDP_MDP_BIRSZ0				7
+#define CLK_MDP_MDP_HDR0				8
+#define CLK_MDP_MDP_AAL0				9
+#define CLK_MDP_MDP_RSZ0				10
+#define CLK_MDP_MDP_RSZ2				11
+#define CLK_MDP_MDP_TDSHP0				12
+#define CLK_MDP_MDP_COLOR0				13
+#define CLK_MDP_MDP_WROT0				14
+#define CLK_MDP_MDP_WROT1				15
+#define CLK_MDP_MDP_WROT2				16
+#define CLK_MDP_MDP_FAKE_ENG0				17
+#define CLK_MDP_APB_DB					18
+#define CLK_MDP_MDP_DLI_ASYNC0				19
+#define CLK_MDP_MDP_DLI_ASYNC1				20
+#define CLK_MDP_MDP_DLO_ASYNC0				21
+#define CLK_MDP_MDP_DLO_ASYNC1				22
+#define CLK_MDP_MDP_DLI_ASYNC2				23
+#define CLK_MDP_MDP_DLO_ASYNC2				24
+#define CLK_MDP_MDP_DLO_ASYNC3				25
+#define CLK_MDP_IMG_DL_ASYNC0				26
+#define CLK_MDP_MDP_RROT0				27
+#define CLK_MDP_MDP_MERGE0				28
+#define CLK_MDP_MDP_C3D0				29
+#define CLK_MDP_MDP_FG0					30
+#define CLK_MDP_MDP_CLA2				31
+#define CLK_MDP_MDP_DLO_ASYNC4				32
+#define CLK_MDP_VPP_RSZ0				33
+#define CLK_MDP_VPP_RSZ1				34
+#define CLK_MDP_MDP_DLO_ASYNC5				35
+#define CLK_MDP_IMG0					36
+#define CLK_MDP_F26M					37
+#define CLK_MDP_IMG_DL_RELAY0				38
+#define CLK_MDP_IMG_DL_RELAY1				39
+
+/* MDPSYS1_CONFIG */
+#define CLK_MDP1_MDP_MUTEX0				0
+#define CLK_MDP1_SMI0					1
+#define CLK_MDP1_SMI0_SMI				2
+#define CLK_MDP1_APB_BUS				3
+#define CLK_MDP1_MDP_RDMA0				4
+#define CLK_MDP1_MDP_RDMA1				5
+#define CLK_MDP1_MDP_RDMA2				6
+#define CLK_MDP1_MDP_BIRSZ0				7
+#define CLK_MDP1_MDP_HDR0				8
+#define CLK_MDP1_MDP_AAL0				9
+#define CLK_MDP1_MDP_RSZ0				10
+#define CLK_MDP1_MDP_RSZ2				11
+#define CLK_MDP1_MDP_TDSHP0				12
+#define CLK_MDP1_MDP_COLOR0				13
+#define CLK_MDP1_MDP_WROT0				14
+#define CLK_MDP1_MDP_WROT1				15
+#define CLK_MDP1_MDP_WROT2				16
+#define CLK_MDP1_MDP_FAKE_ENG0				17
+#define CLK_MDP1_APB_DB					18
+#define CLK_MDP1_MDP_DLI_ASYNC0				19
+#define CLK_MDP1_MDP_DLI_ASYNC1				20
+#define CLK_MDP1_MDP_DLO_ASYNC0				21
+#define CLK_MDP1_MDP_DLO_ASYNC1				22
+#define CLK_MDP1_MDP_DLI_ASYNC2				23
+#define CLK_MDP1_MDP_DLO_ASYNC2				24
+#define CLK_MDP1_MDP_DLO_ASYNC3				25
+#define CLK_MDP1_IMG_DL_ASYNC0				26
+#define CLK_MDP1_MDP_RROT0				27
+#define CLK_MDP1_MDP_MERGE0				28
+#define CLK_MDP1_MDP_C3D0				29
+#define CLK_MDP1_MDP_FG0				30
+#define CLK_MDP1_MDP_CLA2				31
+#define CLK_MDP1_MDP_DLO_ASYNC4				32
+#define CLK_MDP1_VPP_RSZ0				33
+#define CLK_MDP1_VPP_RSZ1				34
+#define CLK_MDP1_MDP_DLO_ASYNC5				35
+#define CLK_MDP1_IMG0					36
+#define CLK_MDP1_F26M					37
+#define CLK_MDP1_IMG_DL_RELAY0				38
+#define CLK_MDP1_IMG_DL_RELAY1				39
+
+/* DISP_VDISP_AO_CONFIG */
+#define CLK_MM_V_DISP_VDISP_AO_CONFIG			0
+#define CLK_MM_V_DISP_DPC				1
+#define CLK_MM_V_SMI_SUB_SOMM0				2
+
+/* MFGPLL_PLL_CTRL */
+#define CLK_MFG_AO_MFGPLL				0
+
+/* MFGPLL_SC0_PLL_CTRL */
+#define CLK_MFGSC0_AO_MFGPLL_SC0			0
+
+/* MFGPLL_SC1_PLL_CTRL */
+#define CLK_MFGSC1_AO_MFGPLL_SC1			0
+
+/* CCIPLL_PLL_CTRL */
+#define CLK_CCIPLL					0
+
+/* ARMPLL_LL_PLL_CTRL */
+#define CLK_CPLL_ARMPLL_LL				0
+
+/* ARMPLL_BL_PLL_CTRL */
+#define CLK_CPBL_ARMPLL_BL				0
+
+/* ARMPLL_B_PLL_CTRL */
+#define CLK_CPB_ARMPLL_B				0
+
+/* PTPPLL_PLL_CTRL */
+#define CLK_PTPPLL					0
+
+#endif /* _DT_BINDINGS_CLK_MT8196_H */
diff --git a/include/dt-bindings/reset/mediatek,mt8196-resets.h b/include/dt-bindings/reset/mediatek,mt8196-resets.h
new file mode 100644
index 000000000000..46ced0850d91
--- /dev/null
+++ b/include/dt-bindings/reset/mediatek,mt8196-resets.h
@@ -0,0 +1,26 @@
+/* SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) */
+/*
+ * Copyright (c) 2025 Collabora Ltd.
+ * Author: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
+ */
+
+#ifndef _DT_BINDINGS_RESET_CONTROLLER_MT8196
+#define _DT_BINDINGS_RESET_CONTROLLER_MT8196
+
+/* PEXTP0 resets */
+#define MT8196_PEXTP0_RST0_PCIE0_MAC		0
+#define MT8196_PEXTP0_RST0_PCIE0_PHY		1
+
+/* PEXTP1 resets */
+#define MT8196_PEXTP1_RST0_PCIE1_MAC		0
+#define MT8196_PEXTP1_RST0_PCIE1_PHY		1
+#define MT8196_PEXTP1_RST0_PCIE2_MAC		2
+#define MT8196_PEXTP1_RST0_PCIE2_PHY		3
+
+/* UFS resets */
+#define MT8196_UFSAO_RST0_UFS_MPHY		0
+#define MT8196_UFSAO_RST1_UFS_UNIPRO		1
+#define MT8196_UFSAO_RST1_UFS_CRYPTO		2
+#define MT8196_UFSAO_RST1_UFSHCI		3
+
+#endif  /* _DT_BINDINGS_RESET_CONTROLLER_MT8196 */
-- 
2.39.5

On Wed, Jul 30, 2025 at 12:56:35PM +0200, Laura Nao wrote:
> Add new binding documentation for system clocks, functional clocks and
> PEXTP0/1 and UFS reset controllers on MediaTek MT8196.
> 
> Reviewed-by: Nícolas F. R. A. Prado <nfraprado@collabora.com>
> Co-developed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
> Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
> Signed-off-by: Laura Nao <laura.nao@collabora.com>
> ---
>  .../bindings/clock/mediatek,mt8196-clock.yaml |  86 ++
>  .../clock/mediatek,mt8196-sys-clock.yaml      |  81 ++
>  .../dt-bindings/clock/mediatek,mt8196-clock.h | 802 ++++++++++++++++++
>  .../reset/mediatek,mt8196-resets.h            |  26 +
>  4 files changed, 995 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/clock/mediatek,mt8196-clock.yaml
>  create mode 100644 Documentation/devicetree/bindings/clock/mediatek,mt8196-sys-clock.yaml
>  create mode 100644 include/dt-bindings/clock/mediatek,mt8196-clock.h
>  create mode 100644 include/dt-bindings/reset/mediatek,mt8196-resets.h
> 
> diff --git a/Documentation/devicetree/bindings/clock/mediatek,mt8196-clock.yaml b/Documentation/devicetree/bindings/clock/mediatek,mt8196-clock.yaml
> new file mode 100644
> index 000000000000..03ee0dff464b
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/clock/mediatek,mt8196-clock.yaml
> @@ -0,0 +1,86 @@
> +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/clock/mediatek,mt8196-clock.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: MediaTek Functional Clock Controller for MT8196
> +
> +maintainers:
> +  - Guangjie Song <guangjie.song@mediatek.com>
> +  - Laura Nao <laura.nao@collabora.com>
> +
> +description: |
> +  The clock architecture in MediaTek SoCs is structured like below:
> +  PLLs -->
> +          dividers -->
> +                      muxes
> +                           -->
> +                              clock gate
> +
> +  The device nodes provide clock gate control in different IP blocks.
> +
> +properties:
> +  compatible:
> +    items:
> +      - enum:
> +          - mediatek,mt8196-imp-iic-wrap-c
> +          - mediatek,mt8196-imp-iic-wrap-e
> +          - mediatek,mt8196-imp-iic-wrap-n
> +          - mediatek,mt8196-imp-iic-wrap-w
> +          - mediatek,mt8196-mdpsys0
> +          - mediatek,mt8196-mdpsys1
> +          - mediatek,mt8196-pericfg-ao
> +          - mediatek,mt8196-pextp0cfg-ao
> +          - mediatek,mt8196-pextp1cfg-ao
> +          - mediatek,mt8196-ufscfg-ao
> +          - mediatek,mt8196-vencsys
> +          - mediatek,mt8196-vencsys-c1
> +          - mediatek,mt8196-vencsys-c2
> +          - mediatek,mt8196-vdecsys
> +          - mediatek,mt8196-vdecsys-soc
> +          - mediatek,mt8196-vdisp-ao
> +      - const: syscon
> +
> +  reg:
> +    maxItems: 1
> +
> +  '#clock-cells':
> +    const: 1
> +
> +  '#reset-cells':
> +    const: 1
> +    description:
> +      Reset lines for PEXTP0/1 and UFS blocks.
> +
> +  mediatek,hardware-voter:
> +    $ref: /schemas/types.yaml#/definitions/phandle
> +    description:
> +      On the MT8196 SoC, a Hardware Voter (HWV) backed by a fixed-function
> +      MCU manages clock and power domain control across the AP and other
> +      remote processors. By aggregating their votes, it ensures clocks are
> +      safely enabled/disabled and power domains are active before register
> +      access.

I thought this was going away based on v2 discussion?

Rob

On 01/08/2025 15:57, Rob Herring wrote:
>> +  reg:
>> +    maxItems: 1
>> +
>> +  '#clock-cells':
>> +    const: 1
>> +
>> +  '#reset-cells':
>> +    const: 1
>> +    description:
>> +      Reset lines for PEXTP0/1 and UFS blocks.
>> +
>> +  mediatek,hardware-voter:
>> +    $ref: /schemas/types.yaml#/definitions/phandle
>> +    description:
>> +      On the MT8196 SoC, a Hardware Voter (HWV) backed by a fixed-function
>> +      MCU manages clock and power domain control across the AP and other
>> +      remote processors. By aggregating their votes, it ensures clocks are
>> +      safely enabled/disabled and power domains are active before register
>> +      access.
> 
> I thought this was going away based on v2 discussion?

Yes, I asked to drop it and do not include it in v3. There was also
discussion clarifying review.

I am really surprised that review meant nothing and code is still the same.

Best regards,
Krzysztof

Hi,

On 8/3/25 10:17, Krzysztof Kozlowski wrote:
> On 01/08/2025 15:57, Rob Herring wrote:
>>> +  reg:
>>> +    maxItems: 1
>>> +
>>> +  '#clock-cells':
>>> +    const: 1
>>> +
>>> +  '#reset-cells':
>>> +    const: 1
>>> +    description:
>>> +      Reset lines for PEXTP0/1 and UFS blocks.
>>> +
>>> +  mediatek,hardware-voter:
>>> +    $ref: /schemas/types.yaml#/definitions/phandle
>>> +    description:
>>> +      On the MT8196 SoC, a Hardware Voter (HWV) backed by a fixed-function
>>> +      MCU manages clock and power domain control across the AP and other
>>> +      remote processors. By aggregating their votes, it ensures clocks are
>>> +      safely enabled/disabled and power domains are active before register
>>> +      access.
>>
>> I thought this was going away based on v2 discussion?
>
> Yes, I asked to drop it and do not include it in v3. There was also
> discussion clarifying review.
>
> I am really surprised that review meant nothing and code is still the same.
>

This has been re-submitted as-is, following the outcome of the discussion 
here: https://lore.kernel.org/all/242bf682-cf8f-4469-8a0b-9ec982095f04@collabora.com/

We haven't found a viable alternative to the current approach so far, and
the thread outlines why other options don’t apply. I'm happy to continue 
the discussion there if anyone has further suggestions or ideas on how 
to address this.

Thanks,

Laura

> Best regards,
> Krzysztof

On 04/08/2025 10:35, Laura Nao wrote:
> Hi,
> 
> On 8/3/25 10:17, Krzysztof Kozlowski wrote:
>> On 01/08/2025 15:57, Rob Herring wrote:
>>>> +  reg:
>>>> +    maxItems: 1
>>>> +
>>>> +  '#clock-cells':
>>>> +    const: 1
>>>> +
>>>> +  '#reset-cells':
>>>> +    const: 1
>>>> +    description:
>>>> +      Reset lines for PEXTP0/1 and UFS blocks.
>>>> +
>>>> +  mediatek,hardware-voter:
>>>> +    $ref: /schemas/types.yaml#/definitions/phandle
>>>> +    description:
>>>> +      On the MT8196 SoC, a Hardware Voter (HWV) backed by a fixed-function
>>>> +      MCU manages clock and power domain control across the AP and other
>>>> +      remote processors. By aggregating their votes, it ensures clocks are
>>>> +      safely enabled/disabled and power domains are active before register
>>>> +      access.
>>>
>>> I thought this was going away based on v2 discussion?
>>
>> Yes, I asked to drop it and do not include it in v3. There was also
>> discussion clarifying review.
>>
>> I am really surprised that review meant nothing and code is still the same.
>>
> 
> This has been re-submitted as-is, following the outcome of the discussion 
> here: https://lore.kernel.org/all/242bf682-cf8f-4469-8a0b-9ec982095f04@collabora.com/
> 
> We haven't found a viable alternative to the current approach so far, and
> the thread outlines why other options don’t apply. I'm happy to continue 
> the discussion there if anyone has further suggestions or ideas on how 
> to address this.
> 

And where is any of that resolution/new facts in the commit msg? You
must clearly reflect long discussions like that in the commit msg.

There was no objection from Chen to use clocks or power domains as I
requested. The objection was about DUPLICATING interfaces or nodes.

And what was the resolution:

"Regarding that to be a single clock controller,"

So where is the clock controller? I still see HW voter!


Best regards,
Krzysztof

Il 04/08/25 11:16, Krzysztof Kozlowski ha scritto:
> On 04/08/2025 10:35, Laura Nao wrote:
>> Hi,
>>
>> On 8/3/25 10:17, Krzysztof Kozlowski wrote:
>>> On 01/08/2025 15:57, Rob Herring wrote:
>>>>> +  reg:
>>>>> +    maxItems: 1
>>>>> +
>>>>> +  '#clock-cells':
>>>>> +    const: 1
>>>>> +
>>>>> +  '#reset-cells':
>>>>> +    const: 1
>>>>> +    description:
>>>>> +      Reset lines for PEXTP0/1 and UFS blocks.
>>>>> +
>>>>> +  mediatek,hardware-voter:
>>>>> +    $ref: /schemas/types.yaml#/definitions/phandle
>>>>> +    description:
>>>>> +      On the MT8196 SoC, a Hardware Voter (HWV) backed by a fixed-function
>>>>> +      MCU manages clock and power domain control across the AP and other
>>>>> +      remote processors. By aggregating their votes, it ensures clocks are
>>>>> +      safely enabled/disabled and power domains are active before register
>>>>> +      access.
>>>>
>>>> I thought this was going away based on v2 discussion?
>>>
>>> Yes, I asked to drop it and do not include it in v3. There was also
>>> discussion clarifying review.
>>>
>>> I am really surprised that review meant nothing and code is still the same.
>>>
>>
>> This has been re-submitted as-is, following the outcome of the discussion
>> here: https://lore.kernel.org/all/242bf682-cf8f-4469-8a0b-9ec982095f04@collabora.com/
>>
>> We haven't found a viable alternative to the current approach so far, and
>> the thread outlines why other options don’t apply. I'm happy to continue
>> the discussion there if anyone has further suggestions or ideas on how
>> to address this.
>>
> 
> And where is any of that resolution/new facts in the commit msg? You
> must clearly reflect long discussions like that in the commit msg.

On that, I agree. That's a miss.

> 
> There was no objection from Chen to use clocks or power domains as I
> requested.

Sorry Krzysztof, but now I really think that you don't understand the basics of
MediaTek SoCs and how they're split in hardware - and I'm sorry again, but to me
it really looks like that you're not even trying to understand it.

> The objection was about DUPLICATING interfaces or nodes.

I don't see that duplication. The interface to each clock controller for each
of the hardware subdomains of each controller is scattered all around the (broken
by hardware and by concept, if you missed that in the discussion) HW Voter MMIO.

There are multiple clock controllers in the hardware.
Each of those has its own interface to the HWV.

And there are some that require you to write to both its HWV interface and to the
clock controller specific MMIO at the same time for the same operation. I explained
that in the big discussion that Laura linked.

> 
> And what was the resolution:
> 
> "Regarding that to be a single clock controller,"
> 
> So where is the clock controller? I still see HW voter!

"especially the mux-gate clocks can't really be put in one single clock controller
because to manage those we have to write to the HWV *and* to the clock controller
MMIO"

Clarifying that, "the clock controller" -> "each clock controller of each hardware
subdomain" (not a single clock controller, excuse my bad wording).

Regards,
Angelo

On 04/08/2025 11:27, AngeloGioacchino Del Regno wrote:
> Il 04/08/25 11:16, Krzysztof Kozlowski ha scritto:
>> On 04/08/2025 10:35, Laura Nao wrote:
>>> Hi,
>>>
>>> On 8/3/25 10:17, Krzysztof Kozlowski wrote:
>>>> On 01/08/2025 15:57, Rob Herring wrote:
>>>>>> +  reg:
>>>>>> +    maxItems: 1
>>>>>> +
>>>>>> +  '#clock-cells':
>>>>>> +    const: 1
>>>>>> +
>>>>>> +  '#reset-cells':
>>>>>> +    const: 1
>>>>>> +    description:
>>>>>> +      Reset lines for PEXTP0/1 and UFS blocks.
>>>>>> +
>>>>>> +  mediatek,hardware-voter:
>>>>>> +    $ref: /schemas/types.yaml#/definitions/phandle
>>>>>> +    description:
>>>>>> +      On the MT8196 SoC, a Hardware Voter (HWV) backed by a fixed-function
>>>>>> +      MCU manages clock and power domain control across the AP and other
>>>>>> +      remote processors. By aggregating their votes, it ensures clocks are
>>>>>> +      safely enabled/disabled and power domains are active before register
>>>>>> +      access.
>>>>>
>>>>> I thought this was going away based on v2 discussion?
>>>>
>>>> Yes, I asked to drop it and do not include it in v3. There was also
>>>> discussion clarifying review.
>>>>
>>>> I am really surprised that review meant nothing and code is still the same.
>>>>
>>>
>>> This has been re-submitted as-is, following the outcome of the discussion
>>> here: https://lore.kernel.org/all/242bf682-cf8f-4469-8a0b-9ec982095f04@collabora.com/
>>>
>>> We haven't found a viable alternative to the current approach so far, and
>>> the thread outlines why other options don’t apply. I'm happy to continue
>>> the discussion there if anyone has further suggestions or ideas on how
>>> to address this.
>>>
>>
>> And where is any of that resolution/new facts in the commit msg? You
>> must clearly reflect long discussions like that in the commit msg.
> 
> On that, I agree. That's a miss.
> 
>>
>> There was no objection from Chen to use clocks or power domains as I
>> requested.
> 
> Sorry Krzysztof, but now I really think that you don't understand the basics of
> MediaTek SoCs and how they're split in hardware - and I'm sorry again, but to me
> it really looks like that you're not even trying to understand it.

There is no DTS here. No diagrams or some simplified drawings to help me
understand.

> 
>> The objection was about DUPLICATING interfaces or nodes.
> 
> I don't see that duplication. The interface to each clock controller for each
> of the hardware subdomains of each controller is scattered all around the (broken
> by hardware and by concept, if you missed that in the discussion) HW Voter MMIO.
> 
> There are multiple clock controllers in the hardware.
> Each of those has its own interface to the HWV.
> 
> And there are some that require you to write to both its HWV interface and to the
> clock controller specific MMIO at the same time for the same operation. I explained
> that in the big discussion that Laura linked.

That's not what property description says. I discussed that part. Your
description says - to aggregate votes.

Above you say that control is split between two different MMIO blocks.

Aggregating votes is exactly what we discussed last time and you should
not use custom phandle for it.

Maybe it is just the name, so avoid all the confusing "votes" if this is
not voting system. If this is a voting system, then don't use custom
phandles.

Best regards,
Krzysztof

Il 04/08/25 13:01, Krzysztof Kozlowski ha scritto:
> On 04/08/2025 11:27, AngeloGioacchino Del Regno wrote:
>> Il 04/08/25 11:16, Krzysztof Kozlowski ha scritto:
>>> On 04/08/2025 10:35, Laura Nao wrote:
>>>> Hi,
>>>>
>>>> On 8/3/25 10:17, Krzysztof Kozlowski wrote:
>>>>> On 01/08/2025 15:57, Rob Herring wrote:
>>>>>>> +  reg:
>>>>>>> +    maxItems: 1
>>>>>>> +
>>>>>>> +  '#clock-cells':
>>>>>>> +    const: 1
>>>>>>> +
>>>>>>> +  '#reset-cells':
>>>>>>> +    const: 1
>>>>>>> +    description:
>>>>>>> +      Reset lines for PEXTP0/1 and UFS blocks.
>>>>>>> +
>>>>>>> +  mediatek,hardware-voter:
>>>>>>> +    $ref: /schemas/types.yaml#/definitions/phandle
>>>>>>> +    description:
>>>>>>> +      On the MT8196 SoC, a Hardware Voter (HWV) backed by a fixed-function
>>>>>>> +      MCU manages clock and power domain control across the AP and other
>>>>>>> +      remote processors. By aggregating their votes, it ensures clocks are
>>>>>>> +      safely enabled/disabled and power domains are active before register
>>>>>>> +      access.
>>>>>>
>>>>>> I thought this was going away based on v2 discussion?
>>>>>
>>>>> Yes, I asked to drop it and do not include it in v3. There was also
>>>>> discussion clarifying review.
>>>>>
>>>>> I am really surprised that review meant nothing and code is still the same.
>>>>>
>>>>
>>>> This has been re-submitted as-is, following the outcome of the discussion
>>>> here: https://lore.kernel.org/all/242bf682-cf8f-4469-8a0b-9ec982095f04@collabora.com/
>>>>
>>>> We haven't found a viable alternative to the current approach so far, and
>>>> the thread outlines why other options don’t apply. I'm happy to continue
>>>> the discussion there if anyone has further suggestions or ideas on how
>>>> to address this.
>>>>
>>>
>>> And where is any of that resolution/new facts in the commit msg? You
>>> must clearly reflect long discussions like that in the commit msg.
>>
>> On that, I agree. That's a miss.
>>
>>>
>>> There was no objection from Chen to use clocks or power domains as I
>>> requested.
>>
>> Sorry Krzysztof, but now I really think that you don't understand the basics of
>> MediaTek SoCs and how they're split in hardware - and I'm sorry again, but to me
>> it really looks like that you're not even trying to understand it.
> 
> There is no DTS here. No diagrams or some simplified drawings to help me
> understand.
> 
>>
>>> The objection was about DUPLICATING interfaces or nodes.
>>
>> I don't see that duplication. The interface to each clock controller for each
>> of the hardware subdomains of each controller is scattered all around the (broken
>> by hardware and by concept, if you missed that in the discussion) HW Voter MMIO.
>>
>> There are multiple clock controllers in the hardware.
>> Each of those has its own interface to the HWV.
>>
>> And there are some that require you to write to both its HWV interface and to the
>> clock controller specific MMIO at the same time for the same operation. I explained
>> that in the big discussion that Laura linked.
> 
> That's not what property description says. I discussed that part. Your
> description says - to aggregate votes.
> 

Yes. That is what the datasheets say, but read down there.

> Above you say that control is split between two different MMIO blocks.
> 

Also yes.

> Aggregating votes is exactly what we discussed last time and you should
> not use custom phandle for it.
> 

We discussed about aggregating votes, yes, in software - this instead is a
*broken* hardware that does the aggregation internally and does not require
nor want external drivers to do the aggregation.

> Maybe it is just the name, so avoid all the confusing "votes" if this is
> not voting system. If this is a voting system, then don't use custom
> phandles.

Being it fundamentally *broken*, this being a voting system is what the hardware
initially wanted to be - but effectively, since it requires YOU to:
  - Make sure that power supplies are turned on, if not, turn them on by "touching"
    HW registers (so, without any assistance from the voter MCU), if any;
  - Turn on parent clocks manually, if any, before using the "voter mcu" to try
    to ungate that clock; and
    - Enable the "FENC" manually, after the mcu says that the clock was ungated.

in the current state, it is just an hardware managed refcounting system and
nothing else, because the MCU seems to be unfinished, hence, again, b r o k e n.

Note that by "manually" I always mean "with direct writes to a clock controller's
registerS, and without any automation/assistance from the HWV MCU".

We're using the "hardware-voter" name because this is how MediaTek calls it in the
datasheets, and no it doesn't really *deserve* that name for what it is exactly in
MT8196 and MT6991.

And mind you - if using the "interconnect" property for this means that we have to
add an interconnect driver for it, no, we will not do that, as placing a software
vote that votes clocks in a a voter MCU that does exactly what the interconnect
driver would do - then requiring virtual/fake clocks - is not a good solution.

So, what should we do then?

Change it to "mediatek,clock-hw-refcounter", and adding a comment to the binding
saying that this is called "Hardware Voter (HWV)" in the datasheets?

Or is using the "interconnect" property without any driver in the interconnect API
actually legit? - Because to me it doesn't look like being legit (and if it is, it
shouldn't be, as I'm sure that everyone would expect an interconnect API driver
when encountering an "interconnect" property in DT), and if so, we should just add
a new "hw-interconnect" or "interconnect-hw" instead to not create confusion.

Regards,
Angelo

> 
> Best regards,
> Krzysztof

On 04/08/2025 15:27, AngeloGioacchino Del Regno wrote:
> 
> We discussed about aggregating votes, yes, in software - this instead is a
> *broken* hardware that does the aggregation internally and does not require
> nor want external drivers to do the aggregation.
> 
>> Maybe it is just the name, so avoid all the confusing "votes" if this is
>> not voting system. If this is a voting system, then don't use custom
>> phandles.
> 
> Being it fundamentally *broken*, this being a voting system is what the hardware
> initially wanted to be - but effectively, since it requires YOU to:
>   - Make sure that power supplies are turned on, if not, turn them on by "touching"
>     HW registers (so, without any assistance from the voter MCU), if any;
>   - Turn on parent clocks manually, if any, before using the "voter mcu" to try
>     to ungate that clock; and
>     - Enable the "FENC" manually, after the mcu says that the clock was ungated.


I understand that "YOU" as Linux driver, when you want to do something
(e.g. toggle) a clock?
If so this looks a lot like power domain, although with some differences.

> 
> in the current state, it is just an hardware managed refcounting system and
> nothing else, because the MCU seems to be unfinished, hence, again, b r o k e n.
> 
> Note that by "manually" I always mean "with direct writes to a clock controller's
> registerS, and without any automation/assistance from the HWV MCU".
> 
> We're using the "hardware-voter" name because this is how MediaTek calls it in the
> datasheets, and no it doesn't really *deserve* that name for what it is exactly in
> MT8196 and MT6991.

Please capture most/all of this in the property description, so it will
be clear that we treat it as some sort of exception and other users of
that property would need similar rationale.

I am asking for this because I do not want this to be re-used for any
other work which would represent something like real voting for
resources. I want it to be clear for whoever looks at it later during
new SoC bringup.

If you send the same code as v4, the same commit msg, just like Laura
did twice in v2 and v3, I will just keep NAKing via mutt macro because
it's a waste of my time.

> 
> And mind you - if using the "interconnect" property for this means that we have to
> add an interconnect driver for it, no, we will not do that, as placing a software

Existing driver(s) can be as well interconnect providers. Same with
power domains.

I do not talk here how you should implement this in the drivers.

> vote that votes clocks in a a voter MCU that does exactly what the interconnect

What is a "software vote"? How did you encode it in DT? Via that phandle?

> driver would do - then requiring virtual/fake clocks - is not a good solution.

We do not add "software votes" in DT as separate properties, because
they are "software". So maybe that's another problem here...

> 
> So, what should we do then?
> 
> Change it to "mediatek,clock-hw-refcounter", and adding a comment to the binding
> saying that this is called "Hardware Voter (HWV)" in the datasheets?
> 
> Or is using the "interconnect" property without any driver in the interconnect API
> actually legit? - Because to me it doesn't look like being legit (and if it is, it
> shouldn't be, as I'm sure that everyone would expect an interconnect API driver
> when encountering an "interconnect" property in DT), and if so, we should just add

Why you would not add any interconnect driver for interconnect API?
Look, the current phandle allows you to poke in some other MMIO space
for the purpose of enabling the clock FOO? So interconnect or power
domains or whatever allows you to have existing or new driver to receive
xlate() and, when requested resources associated with clock FOO.

Instead of the FOO clock driver poking resources, you do
clk_prepare_enable() or pm_domain or icc_enable().



Best regards,
Krzysztof

Il 04/08/25 15:58, Krzysztof Kozlowski ha scritto:
> On 04/08/2025 15:27, AngeloGioacchino Del Regno wrote:
>>
>> We discussed about aggregating votes, yes, in software - this instead is a
>> *broken* hardware that does the aggregation internally and does not require
>> nor want external drivers to do the aggregation.
>>
>>> Maybe it is just the name, so avoid all the confusing "votes" if this is
>>> not voting system. If this is a voting system, then don't use custom
>>> phandles.
>>
>> Being it fundamentally *broken*, this being a voting system is what the hardware
>> initially wanted to be - but effectively, since it requires YOU to:
>>    - Make sure that power supplies are turned on, if not, turn them on by "touching"
>>      HW registers (so, without any assistance from the voter MCU), if any;
>>    - Turn on parent clocks manually, if any, before using the "voter mcu" to try
>>      to ungate that clock; and
>>      - Enable the "FENC" manually, after the mcu says that the clock was ungated.
> 
> 
> I understand that "YOU" as Linux driver, when you want to do something
> (e.g. toggle) a clock?

"you" == Linux driver, yes.

> If so this looks a lot like power domain, although with some differences.
> 

A power domain ungates power to something.

These are clocks, giving a (x) (M)Hz signal to something.

>>
>> in the current state, it is just an hardware managed refcounting system and
>> nothing else, because the MCU seems to be unfinished, hence, again, b r o k e n.
>>
>> Note that by "manually" I always mean "with direct writes to a clock controller's
>> registerS, and without any automation/assistance from the HWV MCU".
>>
>> We're using the "hardware-voter" name because this is how MediaTek calls it in the
>> datasheets, and no it doesn't really *deserve* that name for what it is exactly in
>> MT8196 and MT6991.
> 
> Please capture most/all of this in the property description, so it will
> be clear that we treat it as some sort of exception and other users of
> that property would need similar rationale.
> 
> I am asking for this because I do not want this to be re-used for any
> other work which would represent something like real voting for
> resources. I want it to be clear for whoever looks at it later during
> new SoC bringup.

Okay, now that sounds reasonable, and that sounds like a clear suggestion with
a clear action to take.

Perfect.

Laura, please do exactly that.

P.S.: I understand what you're trying to do here, and I agree; preventing stuff
like this for things that aren't as broken as this is completely right.

> 
> If you send the same code as v4, the same commit msg, just like Laura
> did twice in v2 and v3, I will just keep NAKing via mutt macro because
> it's a waste of my time.
> 

My time isn't infinite, either :-)

>>
>> And mind you - if using the "interconnect" property for this means that we have to
>> add an interconnect driver for it, no, we will not do that, as placing a software
> 
> Existing driver(s) can be as well interconnect providers. Same with
> power domains.
> 
> I do not talk here how you should implement this in the drivers.
> 
>> vote that votes clocks in a a voter MCU that does exactly what the interconnect
> 
> What is a "software vote"? How did you encode it in DT? Via that phandle?
> 
>> driver would do - then requiring virtual/fake clocks - is not a good solution.
> 
> We do not add "software votes" in DT as separate properties, because
> they are "software". So maybe that's another problem here...
> 

Indeed - the point is, the only way to make this *broken* thing to work with an
interconnect provider would be to place a software vote to place a vote in the HW
voter, which would be ugly and wrong.

But anyway, a solution was reached. Let's just stop and avoid useless discussions
about what X could be if hardware Y wasn't broken; that'd be just a waste of time.

Regards,
Angelo

>>
>> So, what should we do then?
>>
>> Change it to "mediatek,clock-hw-refcounter", and adding a comment to the binding
>> saying that this is called "Hardware Voter (HWV)" in the datasheets?
>>
>> Or is using the "interconnect" property without any driver in the interconnect API
>> actually legit? - Because to me it doesn't look like being legit (and if it is, it
>> shouldn't be, as I'm sure that everyone would expect an interconnect API driver
>> when encountering an "interconnect" property in DT), and if so, we should just add
> 
> Why you would not add any interconnect driver for interconnect API?
> Look, the current phandle allows you to poke in some other MMIO space
> for the purpose of enabling the clock FOO? So interconnect or power
> domains or whatever allows you to have existing or new driver to receive
> xlate() and, when requested resources associated with clock FOO.
> 
> Instead of the FOO clock driver poking resources, you do
> clk_prepare_enable() or pm_domain or icc_enable().
> 
> 
> 
> Best regards,
> Krzysztof

On 04/08/2025 16:15, AngeloGioacchino Del Regno wrote:
> Il 04/08/25 15:58, Krzysztof Kozlowski ha scritto:
>> On 04/08/2025 15:27, AngeloGioacchino Del Regno wrote:
>>>
>>> We discussed about aggregating votes, yes, in software - this instead is a
>>> *broken* hardware that does the aggregation internally and does not require
>>> nor want external drivers to do the aggregation.
>>>
>>>> Maybe it is just the name, so avoid all the confusing "votes" if this is
>>>> not voting system. If this is a voting system, then don't use custom
>>>> phandles.
>>>
>>> Being it fundamentally *broken*, this being a voting system is what the hardware
>>> initially wanted to be - but effectively, since it requires YOU to:
>>>    - Make sure that power supplies are turned on, if not, turn them on by "touching"
>>>      HW registers (so, without any assistance from the voter MCU), if any;
>>>    - Turn on parent clocks manually, if any, before using the "voter mcu" to try
>>>      to ungate that clock; and
>>>      - Enable the "FENC" manually, after the mcu says that the clock was ungated.
>>
>>
>> I understand that "YOU" as Linux driver, when you want to do something
>> (e.g. toggle) a clock?
> 
> "you" == Linux driver, yes.
> 
>> If so this looks a lot like power domain, although with some differences.
>>
> 
> A power domain ungates power to something.

Does more, it is not a simple supply.

> 
> These are clocks, giving a (x) (M)Hz signal to something.

Your earlier message about "YOU" said:

"   - Make sure that power supplies are turned on, if not, turn them on
by "touching"
     HW registers (so, without any assistance from the voter MCU), if any;"

so not a simple clocks stuff.

Best regards,
Krzysztof

Il 04/08/25 16:21, Krzysztof Kozlowski ha scritto:
> On 04/08/2025 16:15, AngeloGioacchino Del Regno wrote:
>> Il 04/08/25 15:58, Krzysztof Kozlowski ha scritto:
>>> On 04/08/2025 15:27, AngeloGioacchino Del Regno wrote:
>>>>
>>>> We discussed about aggregating votes, yes, in software - this instead is a
>>>> *broken* hardware that does the aggregation internally and does not require
>>>> nor want external drivers to do the aggregation.
>>>>
>>>>> Maybe it is just the name, so avoid all the confusing "votes" if this is
>>>>> not voting system. If this is a voting system, then don't use custom
>>>>> phandles.
>>>>
>>>> Being it fundamentally *broken*, this being a voting system is what the hardware
>>>> initially wanted to be - but effectively, since it requires YOU to:
>>>>     - Make sure that power supplies are turned on, if not, turn them on by "touching"
>>>>       HW registers (so, without any assistance from the voter MCU), if any;
>>>>     - Turn on parent clocks manually, if any, before using the "voter mcu" to try
>>>>       to ungate that clock; and
>>>>       - Enable the "FENC" manually, after the mcu says that the clock was ungated.
>>>
>>>
>>> I understand that "YOU" as Linux driver, when you want to do something
>>> (e.g. toggle) a clock?
>>
>> "you" == Linux driver, yes.
>>
>>> If so this looks a lot like power domain, although with some differences.
>>>
>>
>> A power domain ungates power to something.
> 
> Does more, it is not a simple supply.
> 

Yes, does more, but still manages power, and not clocks.

>>
>> These are clocks, giving a (x) (M)Hz signal to something.
> 
> Your earlier message about "YOU" said:
> 
> "   - Make sure that power supplies are turned on, if not, turn them on
> by "touching"
>       HW registers (so, without any assistance from the voter MCU), if any;"
> 
> so not a simple clocks stuff.

That's a characteristic of MediaTek's clock controllers: each hardware macroblock
needs to be powered in order to be able to enable clocks.

This is nothing new in MT8196/MT6991, it's how MediaTek SoCs have always been split
by hardware, and it's like that since ages.

Some other SoCs have the clock controllers always powered on - MediaTek doesn't.

On 04/08/2025 15:58, Krzysztof Kozlowski wrote:
>>
>> So, what should we do then?
>>
>> Change it to "mediatek,clock-hw-refcounter", and adding a comment to the binding
>> saying that this is called "Hardware Voter (HWV)" in the datasheets?
>>
>> Or is using the "interconnect" property without any driver in the interconnect API
>> actually legit? - Because to me it doesn't look like being legit (and if it is, it
>> shouldn't be, as I'm sure that everyone would expect an interconnect API driver
>> when encountering an "interconnect" property in DT), and if so, we should just add
> 
> Why you would not add any interconnect driver for interconnect API?
> Look, the current phandle allows you to poke in some other MMIO space
> for the purpose of enabling the clock FOO? So interconnect or power
> domains or whatever allows you to have existing or new driver to receive
> xlate() and, when requested resources associated with clock FOO.

Something got here cut. Last sentence is supposed to be:

"So interconnect or power
domains or whatever allows you to have existing or new driver to receive
xlate() and, when requested, toggle the resources associated with clock
FOO."

> 
> Instead of the FOO clock driver poking resources, you do
> clk_prepare_enable() or pm_domain or icc_enable().

I looked now at the driver and see your clock drivers poking via regmap
to other MMIO. That's exactly usecase of syscon and exactly the pattern
*we are usually discouraging*. It's limited, non-scalable and vendor-driven.

If this was a power domain provider then:
1. Your clock drivers would only do runtime PM.
2. Your MCU would be the power domain controller doing whatever is
necessary - toggling these set/clr bits - when given clock is enabled.
And it really looks like what you described...


Best regards,
Krzysztof

Il 04/08/25 16:19, Krzysztof Kozlowski ha scritto:
> On 04/08/2025 15:58, Krzysztof Kozlowski wrote:
>>>
>>> So, what should we do then?
>>>
>>> Change it to "mediatek,clock-hw-refcounter", and adding a comment to the binding
>>> saying that this is called "Hardware Voter (HWV)" in the datasheets?
>>>
>>> Or is using the "interconnect" property without any driver in the interconnect API
>>> actually legit? - Because to me it doesn't look like being legit (and if it is, it
>>> shouldn't be, as I'm sure that everyone would expect an interconnect API driver
>>> when encountering an "interconnect" property in DT), and if so, we should just add
>>
>> Why you would not add any interconnect driver for interconnect API?
>> Look, the current phandle allows you to poke in some other MMIO space
>> for the purpose of enabling the clock FOO? So interconnect or power
>> domains or whatever allows you to have existing or new driver to receive
>> xlate() and, when requested resources associated with clock FOO.
> 
> Something got here cut. Last sentence is supposed to be:
> 
> "So interconnect or power
> domains or whatever allows you to have existing or new driver to receive
> xlate() and, when requested, toggle the resources associated with clock
> FOO."
> 
>>
>> Instead of the FOO clock driver poking resources, you do
>> clk_prepare_enable() or pm_domain or icc_enable().
> 
> I looked now at the driver and see your clock drivers poking via regmap
> to other MMIO. That's exactly usecase of syscon and exactly the pattern
> *we are usually discouraging*. It's limited, non-scalable and vendor-driven.
> 

If the HWV wasn't BROKEN, I'd be the first one to go for generic stuff, but
since it is what it is, adding bloat to generic, non vendor-driven APIs would
be bad.

> If this was a power domain provider then:
> 1. Your clock drivers would only do runtime PM.

The clock drivers would have to get a list of power domain that is *equal to*
(in their amount) the list of clocks.
But then those are not power domains, as those registers in the MCU are ONLY
ungating a clock and nothing else in the current state of the hardware.

> 2. Your MCU would be the power domain controller doing whatever is
> necessary - toggling these set/clr bits - when given clock is enabled.

That MCU does support power domain voting (for two power domains in the main
PD Controller, and for all power domains in the multimedia PD controller), and
this is something completely separated from the *clock* controllers.

Just to make the picture complete for you: the power domains that this MCU can
manage are not in any way related to the clocks that it can manage. At all.

> And it really looks like what you described...
> 
> 
> Best regards,
> Krzysztof

On 04/08/2025 16:31, AngeloGioacchino Del Regno wrote:
> Il 04/08/25 16:19, Krzysztof Kozlowski ha scritto:
>> On 04/08/2025 15:58, Krzysztof Kozlowski wrote:
>>>>
>>>> So, what should we do then?
>>>>
>>>> Change it to "mediatek,clock-hw-refcounter", and adding a comment to the binding
>>>> saying that this is called "Hardware Voter (HWV)" in the datasheets?
>>>>
>>>> Or is using the "interconnect" property without any driver in the interconnect API
>>>> actually legit? - Because to me it doesn't look like being legit (and if it is, it
>>>> shouldn't be, as I'm sure that everyone would expect an interconnect API driver
>>>> when encountering an "interconnect" property in DT), and if so, we should just add
>>>
>>> Why you would not add any interconnect driver for interconnect API?
>>> Look, the current phandle allows you to poke in some other MMIO space
>>> for the purpose of enabling the clock FOO? So interconnect or power
>>> domains or whatever allows you to have existing or new driver to receive
>>> xlate() and, when requested resources associated with clock FOO.
>>
>> Something got here cut. Last sentence is supposed to be:
>>
>> "So interconnect or power
>> domains or whatever allows you to have existing or new driver to receive
>> xlate() and, when requested, toggle the resources associated with clock
>> FOO."
>>
>>>
>>> Instead of the FOO clock driver poking resources, you do
>>> clk_prepare_enable() or pm_domain or icc_enable().
>>
>> I looked now at the driver and see your clock drivers poking via regmap
>> to other MMIO. That's exactly usecase of syscon and exactly the pattern
>> *we are usually discouraging*. It's limited, non-scalable and vendor-driven.
>>
> 
> If the HWV wasn't BROKEN, I'd be the first one to go for generic stuff, but
> since it is what it is, adding bloat to generic, non vendor-driven APIs would
> be bad.
> 
>> If this was a power domain provider then:
>> 1. Your clock drivers would only do runtime PM.
> 
> The clock drivers would have to get a list of power domain that is *equal to*
> (in their amount) the list of clocks.
> But then those are not power domains, as those registers in the MCU are ONLY
> ungating a clock and nothing else in the current state of the hardware.
> 
>> 2. Your MCU would be the power domain controller doing whatever is
>> necessary - toggling these set/clr bits - when given clock is enabled.
> 
> That MCU does support power domain voting (for two power domains in the main
> PD Controller, and for all power domains in the multimedia PD controller), and
> this is something completely separated from the *clock* controllers.
> 
> Just to make the picture complete for you: the power domains that this MCU can
> manage are not in any way related to the clocks that it can manage. At all.


OK, thanks for explanations. Please rephrase commit msg and property
description in v4. I am fine in using "hardware voter" terminology in
some places, so it will match datasheet, but I want to make it clear
that it is not voting for resources how we usually understand it. It's
just syscon stuff, poking in other system-like device registers because
hardware is like that.


Best regards,
Krzysztof

Il 04/08/25 16:33, Krzysztof Kozlowski ha scritto:
> On 04/08/2025 16:31, AngeloGioacchino Del Regno wrote:
>> Il 04/08/25 16:19, Krzysztof Kozlowski ha scritto:
>>> On 04/08/2025 15:58, Krzysztof Kozlowski wrote:
>>>>>
>>>>> So, what should we do then?
>>>>>
>>>>> Change it to "mediatek,clock-hw-refcounter", and adding a comment to the binding
>>>>> saying that this is called "Hardware Voter (HWV)" in the datasheets?
>>>>>
>>>>> Or is using the "interconnect" property without any driver in the interconnect API
>>>>> actually legit? - Because to me it doesn't look like being legit (and if it is, it
>>>>> shouldn't be, as I'm sure that everyone would expect an interconnect API driver
>>>>> when encountering an "interconnect" property in DT), and if so, we should just add
>>>>
>>>> Why you would not add any interconnect driver for interconnect API?
>>>> Look, the current phandle allows you to poke in some other MMIO space
>>>> for the purpose of enabling the clock FOO? So interconnect or power
>>>> domains or whatever allows you to have existing or new driver to receive
>>>> xlate() and, when requested resources associated with clock FOO.
>>>
>>> Something got here cut. Last sentence is supposed to be:
>>>
>>> "So interconnect or power
>>> domains or whatever allows you to have existing or new driver to receive
>>> xlate() and, when requested, toggle the resources associated with clock
>>> FOO."
>>>
>>>>
>>>> Instead of the FOO clock driver poking resources, you do
>>>> clk_prepare_enable() or pm_domain or icc_enable().
>>>
>>> I looked now at the driver and see your clock drivers poking via regmap
>>> to other MMIO. That's exactly usecase of syscon and exactly the pattern
>>> *we are usually discouraging*. It's limited, non-scalable and vendor-driven.
>>>
>>
>> If the HWV wasn't BROKEN, I'd be the first one to go for generic stuff, but
>> since it is what it is, adding bloat to generic, non vendor-driven APIs would
>> be bad.
>>
>>> If this was a power domain provider then:
>>> 1. Your clock drivers would only do runtime PM.
>>
>> The clock drivers would have to get a list of power domain that is *equal to*
>> (in their amount) the list of clocks.
>> But then those are not power domains, as those registers in the MCU are ONLY
>> ungating a clock and nothing else in the current state of the hardware.
>>
>>> 2. Your MCU would be the power domain controller doing whatever is
>>> necessary - toggling these set/clr bits - when given clock is enabled.
>>
>> That MCU does support power domain voting (for two power domains in the main
>> PD Controller, and for all power domains in the multimedia PD controller), and
>> this is something completely separated from the *clock* controllers.
>>
>> Just to make the picture complete for you: the power domains that this MCU can
>> manage are not in any way related to the clocks that it can manage. At all.
> 
> 
> OK, thanks for explanations. Please rephrase commit msg and property
> description in v4. I am fine in using "hardware voter" terminology in
> some places, so it will match datasheet, but I want to make it clear
> that it is not voting for resources how we usually understand it. It's
> just syscon stuff, poking in other system-like device registers because
> hardware is like that.
> 

I'm happy that we finally reached a conclusion that works for both of us, and
I am sorry that all this went on for weeks with (very) long discussions.

Thanks for that.

Regards,
Angelo

> 
> Best regards,
> Krzysztof

On 30/07/2025 12:56, Laura Nao wrote:
> +
> +  mediatek,hardware-voter:
> +    $ref: /schemas/types.yaml#/definitions/phandle
> +    description:
> +      On the MT8196 SoC, a Hardware Voter (HWV) backed by a fixed-function
> +      MCU manages clock and power domain control across the AP and other
> +      remote processors. By aggregating their votes, it ensures clocks are
> +      safely enabled/disabled and power domains are active before register
> +      access.


No improvements, I already commented on this.

I also said:

"I already commented on this, so don't send v3 with the same."

NAK


Best regards,
Krzysztof