[PATCH v2 00/20] Add minimal Tensor/GS101 SoC support and Oriole/Pixel6 board

[PATCH v2 00/20] Add minimal Tensor/GS101 SoC support and Oriole/Pixel6 board

[Peter Griffin]

Hi folks,

Firstly, thanks to everyone who reviewed the v1 series! V2 incorporates all
the review feedback received so far.

This series adds initial SoC support for the GS101 SoC and also initial board
support for Pixel 6 phone (Oriole).

The gs101 / Tensor SoC is also used in Pixel6a (bluejay) and Pixel 6 Pro
(raven) phones. Currently DT is added for the gs101 SoC and Oriole.
As you can see from the patches the SoC is based on a Samsung Exynos SoC,
and therefore lots of the low level Exynos drivers can be re-used.

The support added in this series consists of:
* cpus
* pinctrl
* some CCF implementation
* watchdog
* uart
* gpio

This is enough to boot through to a busybox initramfs and shell using an
upstream kernel though :) More platform support will be added over the
following weeks and months.

Note 1: I've removed the dtbo overlay from v2 submission and will re-submit once
I have appropriate documentation for it.

Note 2: I've left the bootargs in dts with earlycon for now, for two reasons.
1) The bootloader hangs if bootargs isn't present in the dtb as it tries to
re-write this with additional bootargs.
2) there is a issue whereby the full serial console doesn't come up properly
if earlycon isn't also specified. This issue needs further investigation.

Note 3: In `dt-bindings: pinctrl: samsung: add google,gs101-pinctrl compatible`
I tried to narrow the interrupts check to google,gs101-pinctrl but I still see
a warning:
gs101-oriole.dtb: pinctrl@174d0000: interrupts: [[0, 0, 4],[..] is too long

If anyone can educate me on what I've done wrong here it would be most
appreciated!

kind regards,

Peter.

Changes since v1:
 - Remove irq/gs101.h and replace macros with irq numbers globally
 - exynos-pmu - keep alphabetical order
 - add cmu_apm to clock bindings documentation
 - sysreg bindings - remove superfluous `google,gs101-sysreg`
 - watchdog bindings - Alphanumerical order, update gs201 comment
 - samsung,pinctrl.yaml - add new "if:then:else:" to narrow for google SoC
 - samsung,pinctrl-wakeup-interrupt.yaml - Alphanumerical order
 - samsung,pinctrl- add google,gs101-wakeup-eint compatible
 - clk-pll: fixup typos
 - clk-gs101: fix kernel test robot warnings (add 2 new clocks,dividers,gate)
 - clk-gs101: fix alphabetical order
 - clk-gs101: cmu_apm: fixup typo and missing empty entry
 - clk-gs101: cmu_misc: remove clocks that were being registerred twice
 - pinctrl: filter sel: rename/reorder variables, add comment for FLTCON bitfield
 - pinctrl: filter sel: avoid setting reserved bits by loop over FLTCON1 pins as well
 - pinctrl: gs101: rename bank_type_6/7 structs to be more specific, split from filter
 - watchdog: s3c2410_wdt: remove dev_info prints
 - gs101.dtsi/oriole.dts: order by unit node, remove underscores from node name, blank lines
   add SoC node, split dts and dtsi into separate patches, remove 'DVT' suffix
 - gs101-oriole.dtso: Remove overlay until board_id is documented properly
 - Add GS101_PIN_* macros to gs101-pinctrl.h instead of using Exynos ones
 - gpio-keys: update linux,code to use input-event-code macros
 - add dedicated gs101-uart compatible

Peter Griffin (20):
  dt-bindings: soc: samsung: exynos-pmu: Add gs101 compatible
  dt-bindings: clock: Add Google gs101 clock management unit bindings
  dt-bindings: soc: google: exynos-sysreg: add dedicated SYSREG
    compatibles to GS101
  dt-bindings: watchdog: Document Google gs101 & gs201 watchdog bindings
  dt-bindings: arm: google: Add bindings for Google ARM platforms
  dt-bindings: pinctrl: samsung: add google,gs101-pinctrl compatible
  dt-bindings: pinctrl: samsung: add gs101-wakeup-eint compatible
  dt-bindings: serial: samsung: Add google-gs101-uart compatible
  clk: samsung: clk-pll: Add support for pll_{0516,0517,518}
  clk: samsung: clk-gs101: Add cmu_top registers, plls, mux and gates
  clk: samsung: clk-gs101: add CMU_APM support
  clk: samsung: clk-gs101: Add support for CMU_MISC clock unit
  pinctrl: samsung: Add filter selection support for alive banks
  pinctrl: samsung: Add gs101 SoC pinctrl configuration
  watchdog: s3c2410_wdt: Add support for Google tensor SoCs
  tty: serial: samsung: Add gs101 compatible and SoC data
  arm64: dts: google: Add initial Google gs101 SoC support
  arm64: dts: google: Add initial Oriole/pixel 6 board support
  arm64: defconfig: Enable Google Tensor SoC
  MAINTAINERS: add entry for Google Tensor SoC

 .../devicetree/bindings/arm/google.yaml       |   46 +
 .../bindings/clock/google,gs101-clock.yaml    |  125 +
 .../samsung,pinctrl-wakeup-interrupt.yaml     |    2 +
 .../bindings/pinctrl/samsung,pinctrl.yaml     |   19 +
 .../bindings/serial/samsung_uart.yaml         |    2 +
 .../bindings/soc/samsung/exynos-pmu.yaml      |    2 +
 .../soc/samsung/samsung,exynos-sysreg.yaml    |    6 +
 .../bindings/watchdog/samsung-wdt.yaml        |   10 +-
 MAINTAINERS                                   |   10 +
 arch/arm64/Kconfig.platforms                  |    6 +
 arch/arm64/boot/dts/Makefile                  |    1 +
 arch/arm64/boot/dts/google/Makefile           |    4 +
 arch/arm64/boot/dts/google/gs101-oriole.dts   |   79 +
 arch/arm64/boot/dts/google/gs101-pinctrl.dtsi | 1275 ++++++++++
 arch/arm64/boot/dts/google/gs101-pinctrl.h    |   32 +
 arch/arm64/boot/dts/google/gs101.dtsi         |  503 ++++
 arch/arm64/configs/defconfig                  |    1 +
 drivers/clk/samsung/Kconfig                   |    9 +
 drivers/clk/samsung/Makefile                  |    2 +
 drivers/clk/samsung/clk-gs101.c               | 2164 +++++++++++++++++
 drivers/clk/samsung/clk-pll.c                 |    9 +-
 drivers/clk/samsung/clk-pll.h                 |    3 +
 .../pinctrl/samsung/pinctrl-exynos-arm64.c    |  163 ++
 drivers/pinctrl/samsung/pinctrl-exynos.c      |   84 +-
 drivers/pinctrl/samsung/pinctrl-exynos.h      |   41 +
 drivers/pinctrl/samsung/pinctrl-samsung.c     |    4 +
 drivers/pinctrl/samsung/pinctrl-samsung.h     |   24 +
 drivers/tty/serial/samsung_tty.c              |   12 +
 drivers/watchdog/s3c2410_wdt.c                |  104 +-
 include/dt-bindings/clock/google,gs101.h      |  232 ++
 30 files changed, 4961 insertions(+), 13 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/arm/google.yaml
 create mode 100644 Documentation/devicetree/bindings/clock/google,gs101-clock.yaml
 create mode 100644 arch/arm64/boot/dts/google/Makefile
 create mode 100644 arch/arm64/boot/dts/google/gs101-oriole.dts
 create mode 100644 arch/arm64/boot/dts/google/gs101-pinctrl.dtsi
 create mode 100644 arch/arm64/boot/dts/google/gs101-pinctrl.h
 create mode 100644 arch/arm64/boot/dts/google/gs101.dtsi
 create mode 100644 drivers/clk/samsung/clk-gs101.c
 create mode 100644 include/dt-bindings/clock/google,gs101.h

-- 
2.42.0.609.gbb76f46606-goog

[PATCH v2 00/20] Add minimal Tensor/GS101 SoC support and Oriole/Pixel6 board

[Peter Griffin]

Hi folks,

Firstly, thanks to everyone who reviewed the v1 series! V2 incorporates all
the review feedback received so far.

This series adds initial SoC support for the GS101 SoC and also initial board
support for Pixel 6 phone (Oriole).

The gs101 / Tensor SoC is also used in Pixel6a (bluejay) and Pixel 6 Pro
(raven) phones. Currently DT is added for the gs101 SoC and Oriole.
As you can see from the patches the SoC is based on a Samsung Exynos SoC,
and therefore lots of the low level Exynos drivers can be re-used.

The support added in this series consists of:
* cpus
* pinctrl
* some CCF implementation
* watchdog
* uart
* gpio

This is enough to boot through to a busybox initramfs and shell using an
upstream kernel though :) More platform support will be added over the
following weeks and months.

Note 1: I've removed the dtbo overlay from v2 submission and will re-submit once
I have appropriate documentation for it.

Note 2: I've left the bootargs in dts with earlycon for now, for two reasons.
1) The bootloader hangs if bootargs isn't present in the dtb as it tries to
re-write this with additional bootargs.
2) there is a issue whereby the full serial console doesn't come up properly
if earlycon isn't also specified. This issue needs further investigation.

Note 3: In `dt-bindings: pinctrl: samsung: add google,gs101-pinctrl compatible`
I tried to narrow the interrupts check to google,gs101-pinctrl but I still see
a warning:
gs101-oriole.dtb: pinctrl@174d0000: interrupts: [[0, 0, 4],[..] is too long

If anyone can educate me on what I've done wrong here it would be most
appreciated!

kind regards,

Peter.

Changes since v1:
 - Remove irq/gs101.h and replace macros with irq numbers globally
 - exynos-pmu - keep alphabetical order
 - add cmu_apm to clock bindings documentation
 - sysreg bindings - remove superfluous `google,gs101-sysreg`
 - watchdog bindings - Alphanumerical order, update gs201 comment
 - samsung,pinctrl.yaml - add new "if:then:else:" to narrow for google SoC
 - samsung,pinctrl-wakeup-interrupt.yaml - Alphanumerical order
 - samsung,pinctrl- add google,gs101-wakeup-eint compatible
 - clk-pll: fixup typos
 - clk-gs101: fix kernel test robot warnings (add 2 new clocks,dividers,gate)
 - clk-gs101: fix alphabetical order
 - clk-gs101: cmu_apm: fixup typo and missing empty entry
 - clk-gs101: cmu_misc: remove clocks that were being registerred twice
 - pinctrl: filter sel: rename/reorder variables, add comment for FLTCON bitfield
 - pinctrl: filter sel: avoid setting reserved bits by loop over FLTCON1 pins as well
 - pinctrl: gs101: rename bank_type_6/7 structs to be more specific, split from filter
 - watchdog: s3c2410_wdt: remove dev_info prints
 - gs101.dtsi/oriole.dts: order by unit node, remove underscores from node name, blank lines
   add SoC node, split dts and dtsi into separate patches, remove 'DVT' suffix
 - gs101-oriole.dtso: Remove overlay until board_id is documented properly
 - Add GS101_PIN_* macros to gs101-pinctrl.h instead of using Exynos ones
 - gpio-keys: update linux,code to use input-event-code macros
 - add dedicated gs101-uart compatible

Peter Griffin (20):
  dt-bindings: soc: samsung: exynos-pmu: Add gs101 compatible
  dt-bindings: clock: Add Google gs101 clock management unit bindings
  dt-bindings: soc: google: exynos-sysreg: add dedicated SYSREG
    compatibles to GS101
  dt-bindings: watchdog: Document Google gs101 & gs201 watchdog bindings
  dt-bindings: arm: google: Add bindings for Google ARM platforms
  dt-bindings: pinctrl: samsung: add google,gs101-pinctrl compatible
  dt-bindings: pinctrl: samsung: add gs101-wakeup-eint compatible
  dt-bindings: serial: samsung: Add google-gs101-uart compatible
  clk: samsung: clk-pll: Add support for pll_{0516,0517,518}
  clk: samsung: clk-gs101: Add cmu_top registers, plls, mux and gates
  clk: samsung: clk-gs101: add CMU_APM support
  clk: samsung: clk-gs101: Add support for CMU_MISC clock unit
  pinctrl: samsung: Add filter selection support for alive banks
  pinctrl: samsung: Add gs101 SoC pinctrl configuration
  watchdog: s3c2410_wdt: Add support for Google tensor SoCs
  tty: serial: samsung: Add gs101 compatible and SoC data
  arm64: dts: google: Add initial Google gs101 SoC support
  arm64: dts: google: Add initial Oriole/pixel 6 board support
  arm64: defconfig: Enable Google Tensor SoC
  MAINTAINERS: add entry for Google Tensor SoC

 .../devicetree/bindings/arm/google.yaml       |   46 +
 .../bindings/clock/google,gs101-clock.yaml    |  125 +
 .../samsung,pinctrl-wakeup-interrupt.yaml     |    2 +
 .../bindings/pinctrl/samsung,pinctrl.yaml     |   19 +
 .../bindings/serial/samsung_uart.yaml         |    2 +
 .../bindings/soc/samsung/exynos-pmu.yaml      |    2 +
 .../soc/samsung/samsung,exynos-sysreg.yaml    |    6 +
 .../bindings/watchdog/samsung-wdt.yaml        |   10 +-
 MAINTAINERS                                   |   10 +
 arch/arm64/Kconfig.platforms                  |    6 +
 arch/arm64/boot/dts/Makefile                  |    1 +
 arch/arm64/boot/dts/google/Makefile           |    4 +
 arch/arm64/boot/dts/google/gs101-oriole.dts   |   79 +
 arch/arm64/boot/dts/google/gs101-pinctrl.dtsi | 1275 ++++++++++
 arch/arm64/boot/dts/google/gs101-pinctrl.h    |   32 +
 arch/arm64/boot/dts/google/gs101.dtsi         |  503 ++++
 arch/arm64/configs/defconfig                  |    1 +
 drivers/clk/samsung/Kconfig                   |    9 +
 drivers/clk/samsung/Makefile                  |    2 +
 drivers/clk/samsung/clk-gs101.c               | 2164 +++++++++++++++++
 drivers/clk/samsung/clk-pll.c                 |    9 +-
 drivers/clk/samsung/clk-pll.h                 |    3 +
 .../pinctrl/samsung/pinctrl-exynos-arm64.c    |  163 ++
 drivers/pinctrl/samsung/pinctrl-exynos.c      |   84 +-
 drivers/pinctrl/samsung/pinctrl-exynos.h      |   41 +
 drivers/pinctrl/samsung/pinctrl-samsung.c     |    4 +
 drivers/pinctrl/samsung/pinctrl-samsung.h     |   24 +
 drivers/tty/serial/samsung_tty.c              |   12 +
 drivers/watchdog/s3c2410_wdt.c                |  104 +-
 include/dt-bindings/clock/google,gs101.h      |  232 ++
 30 files changed, 4961 insertions(+), 13 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/arm/google.yaml
 create mode 100644 Documentation/devicetree/bindings/clock/google,gs101-clock.yaml
 create mode 100644 arch/arm64/boot/dts/google/Makefile
 create mode 100644 arch/arm64/boot/dts/google/gs101-oriole.dts
 create mode 100644 arch/arm64/boot/dts/google/gs101-pinctrl.dtsi
 create mode 100644 arch/arm64/boot/dts/google/gs101-pinctrl.h
 create mode 100644 arch/arm64/boot/dts/google/gs101.dtsi
 create mode 100644 drivers/clk/samsung/clk-gs101.c
 create mode 100644 include/dt-bindings/clock/google,gs101.h

-- 
2.42.0.609.gbb76f46606-goog


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH v2 01/20] dt-bindings: soc: samsung: exynos-pmu: Add gs101 compatible

[Peter Griffin]

Add gs101-pmu compatible to the bindings documentation.

Signed-off-by: Peter Griffin <peter.griffin@linaro.org>
---
 Documentation/devicetree/bindings/soc/samsung/exynos-pmu.yaml | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/Documentation/devicetree/bindings/soc/samsung/exynos-pmu.yaml b/Documentation/devicetree/bindings/soc/samsung/exynos-pmu.yaml
index e1d716df5dfa..9e497c310532 100644
--- a/Documentation/devicetree/bindings/soc/samsung/exynos-pmu.yaml
+++ b/Documentation/devicetree/bindings/soc/samsung/exynos-pmu.yaml
@@ -15,6 +15,7 @@ select:
     compatible:
       contains:
         enum:
+          - google,gs101-pmu
           - samsung,exynos3250-pmu
           - samsung,exynos4210-pmu
           - samsung,exynos4212-pmu
@@ -35,6 +36,7 @@ properties:
     oneOf:
       - items:
           - enum:
+              - google,gs101-pmu
               - samsung,exynos3250-pmu
               - samsung,exynos4210-pmu
               - samsung,exynos4212-pmu
-- 
2.42.0.609.gbb76f46606-goog

[PATCH v2 01/20] dt-bindings: soc: samsung: exynos-pmu: Add gs101 compatible

[Peter Griffin]

Add gs101-pmu compatible to the bindings documentation.

Signed-off-by: Peter Griffin <peter.griffin@linaro.org>
---
 Documentation/devicetree/bindings/soc/samsung/exynos-pmu.yaml | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/Documentation/devicetree/bindings/soc/samsung/exynos-pmu.yaml b/Documentation/devicetree/bindings/soc/samsung/exynos-pmu.yaml
index e1d716df5dfa..9e497c310532 100644
--- a/Documentation/devicetree/bindings/soc/samsung/exynos-pmu.yaml
+++ b/Documentation/devicetree/bindings/soc/samsung/exynos-pmu.yaml
@@ -15,6 +15,7 @@ select:
     compatible:
       contains:
         enum:
+          - google,gs101-pmu
           - samsung,exynos3250-pmu
           - samsung,exynos4210-pmu
           - samsung,exynos4212-pmu
@@ -35,6 +36,7 @@ properties:
     oneOf:
       - items:
           - enum:
+              - google,gs101-pmu
               - samsung,exynos3250-pmu
               - samsung,exynos4210-pmu
               - samsung,exynos4212-pmu
-- 
2.42.0.609.gbb76f46606-goog


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH v2 02/20] dt-bindings: clock: Add Google gs101 clock management unit bindings

[Peter Griffin]

Provide dt-schema documentation for Google gs101 SoC clock controller.
Currently this adds support for cmu_top, cmu_misc and cmu_apm.

Signed-off-by: Peter Griffin <peter.griffin@linaro.org>
---
 .../bindings/clock/google,gs101-clock.yaml    | 125 ++++++++++
 include/dt-bindings/clock/google,gs101.h      | 232 ++++++++++++++++++
 2 files changed, 357 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/clock/google,gs101-clock.yaml
 create mode 100644 include/dt-bindings/clock/google,gs101.h

diff --git a/Documentation/devicetree/bindings/clock/google,gs101-clock.yaml b/Documentation/devicetree/bindings/clock/google,gs101-clock.yaml
new file mode 100644
index 000000000000..f74494594b3b
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/google,gs101-clock.yaml
@@ -0,0 +1,125 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/clock/google,gs101-clock.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Google GS101 SoC clock controller
+
+maintainers:
+  - Peter Griffin <peter.griffin@linaro.org>
+
+description: |
+  Google GS101 clock controller is comprised of several CMU units, generating
+  clocks for different domains. Those CMU units are modeled as separate device
+  tree nodes, and might depend on each other. The root clock in that clock tree
+  is OSCCLK (24.576 MHz). That external clock must be defined as a fixed-rate
+  clock in dts.
+
+  CMU_TOP is a top-level CMU, where all base clocks are prepared using PLLs and
+  dividers; all other leaf clocks (other CMUs) are usually derived from CMU_TOP.
+
+  Each clock is assigned an identifier and client nodes can use this identifier
+  to specify the clock which they consume. All clocks available for usage
+  in clock consumer nodes are defined as preprocessor macros in
+  'dt-bindings/clock/gs101.h' header.
+
+properties:
+  compatible:
+    enum:
+      - google,gs101-cmu-top
+      - google,gs101-cmu-apm
+      - google,gs101-cmu-misc
+
+  clocks:
+    minItems: 1
+    maxItems: 2
+
+  clock-names:
+    minItems: 1
+    maxItems: 2
+
+  "#clock-cells":
+    const: 1
+
+  reg:
+    maxItems: 1
+
+allOf:
+  - if:
+      properties:
+        compatible:
+          contains:
+            const: google,gs101-cmu-top
+
+    then:
+      properties:
+        clocks:
+          items:
+            - description: External reference clock (24.576 MHz)
+
+        clock-names:
+          items:
+            - const: oscclk
+
+  - if:
+      properties:
+        compatible:
+          contains:
+            const: google,gs101-cmu-misc
+
+    then:
+      properties:
+        clocks:
+          items:
+            - description: External reference clock (24.576 MHz)
+            - description: Misc bus clock (from CMU_TOP)
+
+        clock-names:
+          items:
+            - const: oscclk
+            - const: dout_cmu_misc_bus
+
+  - if:
+      properties:
+        compatible:
+          contains:
+            const: google,gs101-cmu-apm
+
+    then:
+      properties:
+        clocks:
+          items:
+            - description: External reference clock (24.576 MHz)
+
+        clock-names:
+          items:
+            - const: oscclk
+
+required:
+  - compatible
+  - "#clock-cells"
+  - clocks
+  - clock-names
+  - reg
+
+additionalProperties: false
+
+examples:
+  # Clock controller node for CMU_TOP
+  - |
+    #include <dt-bindings/clock/google,gs101.h>
+    soc {
+        #address-cells = <2>;
+        #size-cells = <1>;
+
+        cmu_top: clock-controller@1e080000 {
+            compatible = "google,gs101-cmu-top";
+            reg = <0x0 0x1e080000 0x8000>;
+            #clock-cells = <1>;
+            clocks = <&ext_24_5m>;
+            clock-names = "oscclk";
+        };
+    };
+
+...
diff --git a/include/dt-bindings/clock/google,gs101.h b/include/dt-bindings/clock/google,gs101.h
new file mode 100644
index 000000000000..7765ba68f734
--- /dev/null
+++ b/include/dt-bindings/clock/google,gs101.h
@@ -0,0 +1,232 @@
+/* SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) */
+/*
+ * Copyright (C) 2023 Linaro Ltd.
+ * Author: Peter Griffin <peter.griffin@linaro.org>
+ *
+ * Device Tree binding constants for Google gs101 clock controller.
+ */
+
+#ifndef _DT_BINDINGS_CLOCK_GOOGLE_GS101_H
+#define _DT_BINDINGS_CLOCK_GOOGLE_GS101_H
+
+/* CMU_TOP PLL*/
+#define CLK_FOUT_SHARED0_PLL		1
+#define CLK_FOUT_SHARED1_PLL		2
+#define CLK_FOUT_SHARED2_PLL		3
+#define CLK_FOUT_SHARED3_PLL		4
+#define CLK_FOUT_SPARE_PLL		5
+
+/* CMU_TOP MUX*/
+#define CLK_MOUT_SHARED0_PLL		6
+#define CLK_MOUT_SHARED1_PLL		7
+#define CLK_MOUT_SHARED2_PLL		8
+#define CLK_MOUT_SHARED3_PLL		9
+#define CLK_MOUT_SPARE_PLL		10
+#define CLK_MOUT_BUS0_BUS		11
+#define CLK_MOUT_CMU_BOOST		12
+#define CLK_MOUT_BUS1_BUS		13
+#define CLK_MOUT_BUS2_BUS		14
+#define CLK_MOUT_CORE_BUS		15
+#define CLK_MOUT_EH_BUS			16
+#define CLK_MOUT_CPUCL2_SWITCH		17
+#define CLK_MOUT_CPUCL1_SWITCH		18
+#define CLK_MOUT_CPUCL0_SWITCH		19
+#define CLK_MOUT_CPUCL0_DBG		20
+#define CLK_MOUT_CMU_HPM		21
+#define CLK_MOUT_G3D_SWITCH		22
+#define CLK_MOUT_G3D_GLB		23
+#define CLK_MOUT_DPU_BUS		24
+#define CLK_MOUT_DISP_BUS		25
+#define CLK_MOUT_G2D_G2D		26
+#define CLK_MOUT_G2D_MSCL		27
+#define CLK_MOUT_HSI0_USB31DRD		28
+#define CLK_MOUT_HSI0_BUS		29
+#define CLK_MOUT_HSI0_DPGTC		30
+#define CLK_MOUT_HSI0_USBDPDGB		31
+#define CLK_MOUT_HSI1_BUS		32
+#define CLK_MOUT_HSI1_PCIE		33
+#define CLK_MOUT_HSI2_BUS		34
+#define CLK_MOUT_HSI2_PCIE		35
+#define CLK_MOUT_HSI2_UFS_EMBD		36
+#define CLK_MOUT_HSI2_MMC_CARD		37
+#define CLK_MOUT_CSIS			38
+#define CLK_MOUT_PDP_BUS		39
+#define CLK_MOUT_PDP_VRA		40
+#define CLK_MOUT_IPP_BUS		41
+#define CLK_MOUT_G3AA			42
+#define CLK_MOUT_ITP			43
+#define CLK_MOUT_DNS_BUS		44
+#define CLK_MOUT_TNR_BUS		45
+#define CLK_MOUT_MCSC_ITSC		46
+#define CLK_MOUT_MCSC_MCSC		47
+#define CLK_MOUT_GDC_SCSC		48
+#define CLK_MOUT_GDC_GDC0		49
+#define CLK_MOUT_GDC_GDC1		50
+#define CLK_MOUT_MFC_MFC		51
+#define CLK_MOUT_MIF_SWITCH		52
+#define CLK_MOUT_MIF_BUS		53
+#define CLK_MOUT_MISC_BUS		54
+#define CLK_MOUT_MISC_SSS		55
+#define CLK_MOUT_PERIC0_IP		56
+#define CLK_MOUT_PERIC0_BUS		57
+#define CLK_MOUT_PERIC1_IP		58
+#define CLK_MOUT_PERIC1_BUS		59
+#define CLK_MOUT_TPU_TPU		60
+#define CLK_MOUT_TPU_TPUCTL		61
+#define CLK_MOUT_TPU_BUS		62
+#define CLK_MOUT_TPU_UART		63
+#define CLK_MOUT_TPU_HPM		64
+#define CLK_MOUT_BO_BUS			65
+#define CLK_MOUT_G3D_BUSD		66
+
+/* CMU_TOP Dividers*/
+#define CLK_DOUT_SHARED0_DIV3		67
+#define CLK_DOUT_SHARED0_DIV2		68
+#define CLK_DOUT_SHARED0_DIV4		69
+#define CLK_DOUT_SHARED0_DIV5		70
+#define CLK_DOUT_SHARED1_DIV3		71
+#define CLK_DOUT_SHARED1_DIV2		72
+#define CLK_DOUT_SHARED1_DIV4		73
+#define CLK_DOUT_SHARED2_DIV2		74
+#define CLK_DOUT_SHARED3_DIV2		75
+#define CLK_DOUT_BUS0_BUS		76
+#define CLK_DOUT_CMU_BOOST		77
+#define CLK_DOUT_BUS1_BUS		78
+#define CLK_DOUT_BUS2_BUS		79
+#define CLK_DOUT_CORE_BUS		80
+#define CLK_DOUT_EH_BUS			81
+#define CLK_DOUT_CPUCL2_SWITCH		82
+#define CLK_DOUT_CPUCL1_SWITCH		83
+#define CLK_DOUT_CPUCL0_SWITCH		84
+#define CLK_DOUT_CPUCL0_DBG		85
+#define CLK_DOUT_CMU_HPM		86
+#define CLK_DOUT_G3D_SWITCH		87
+#define CLK_DOUT_G3D_GLB		88
+#define CLK_DOUT_DPU_BUS		89
+#define CLK_DOUT_DISP_BUS		90
+#define CLK_DOUT_G2D_G2D		91
+#define CLK_DOUT_G2D_MSCL		92
+#define CLK_DOUT_HSI0_USB31DRD		93
+#define CLK_DOUT_HSI0_BUS		94
+#define CLK_DOUT_HSI0_DPGTC		95
+#define CLK_DOUT_HSI0_USBDPDGB		96
+#define CLK_DOUT_HSI1_BUS		97
+#define CLK_DOUT_HSI1_PCIE		98
+#define CLK_DOUT_HSI2_BUS		100
+#define CLK_DOUT_HSI2_PCIE		101
+#define CLK_DOUT_HSI2_UFS_EMBD		102
+#define CLK_DOUT_HSI2_MMC_CARD		103
+#define CLK_DOUT_CSIS			104
+#define CLK_DOUT_PDP_BUS		105
+#define CLK_DOUT_PDP_VRA		106
+#define CLK_DOUT_IPP_BUS		107
+#define CLK_DOUT_G3AA			108
+#define CLK_DOUT_ITP			109
+#define CLK_DOUT_DNS_BUS		110
+#define CLK_DOUT_TNR_BUS		111
+#define CLK_DOUT_MCSC_ITSC		112
+#define CLK_DOUT_MCSC_MCSC		113
+#define CLK_DOUT_GDC_SCSC		114
+#define CLK_DOUT_GDC_GDC0		115
+#define CLK_DOUT_GDC_GDC1		116
+#define CLK_DOUT_MFC_MFC		117
+#define CLK_DOUT_MIF_BUS		118
+#define CLK_DOUT_MISC_BUS		119
+#define CLK_DOUT_MISC_SSS		120
+#define CLK_DOUT_PERIC0_BUS		121
+#define CLK_DOUT_PERIC0_IP		122
+#define CLK_DOUT_PERIC1_BUS		123
+#define CLK_DOUT_PERIC1_IP		124
+#define CLK_DOUT_TPU_TPU		125
+#define CLK_DOUT_TPU_TPUCTL		126
+#define CLK_DOUT_TPU_BUS		127
+#define CLK_DOUT_TPU_UART		128
+#define CLK_DOUT_TPU_HPM		129
+#define CLK_DOUT_BO_BUS			130
+
+/* CMU_TOP Gates*/
+#define CLK_GOUT_BUS0_BUS		131
+#define CLK_GOUT_BUS1_BUS		132
+#define CLK_GOUT_BUS2_BUS		133
+#define CLK_GOUT_CORE_BUS		134
+#define CLK_GOUT_EH_BUS			135
+#define CLK_GOUT_CPUCL2_SWITCH		136
+#define CLK_GOUT_CPUCL1_SWITCH		137
+#define CLK_GOUT_CPUCL0_SWITCH		138
+#define CLK_GOUT_CPUCL0_DBG		139
+#define CLK_GOUT_CMU_HPM		140
+#define CLK_GOUT_G3D_SWITCH		141
+#define CLK_GOUT_G3D_GLB		142
+#define CLK_GOUT_DPU_BUS		143
+#define CLK_GOUT_DISP_BUS		144
+#define CLK_GOUT_G2D_G2D		145
+#define CLK_GOUT_G2D_MSCL		146
+#define CLK_GOUT_HSI0_USB31DRD		147
+#define CLK_GOUT_HSI0_BUS		148
+#define CLK_GOUT_HSI0_DPGTC		149
+#define CLK_GOUT_HSI0_USBDPDGB		150
+#define CLK_GOUT_HSI1_BUS		151
+#define CLK_GOUT_HSI1_PCIE		152
+#define CLK_GOUT_HSI2_BUS		153
+#define CLK_GOUT_HSI2_PCIE		154
+#define CLK_GOUT_HSI2_UFS_EMBD		155
+#define CLK_GOUT_HSI2_MMC_CARD		156
+#define CLK_GOUT_CSIS			157
+#define CLK_GOUT_PDP_BUS		158
+#define CLK_GOUT_PDP_VRA		159
+#define CLK_GOUT_IPP_BUS		160
+#define CLK_GOUT_G3AA			161
+#define CLK_GOUT_ITP			162
+#define CLK_GOUT_DNS_BUS		163
+#define CLK_GOUT_TNR_BUS		164
+#define CLK_GOUT_MCSC_ITSC		165
+#define CLK_GOUT_MCSC_MCSC		166
+#define CLK_GOUT_GDC_SCSC		167
+#define CLK_GOUT_GDC_GDC0		168
+#define CLK_GOUT_GDC_GDC1		169
+#define CLK_GOUT_MFC_MFC		170
+#define CLK_GOUT_MIF_SWITCH		171
+#define CLK_GOUT_MIF_BUS		172
+#define CLK_GOUT_MISC_BUS		173
+#define CLK_GOUT_MISC_SSS		174
+#define CLK_GOUT_PERIC0_BUS		175
+#define CLK_GOUT_PERIC0_IP		176
+#define CLK_GOUT_PERIC1_BUS		177
+#define CLK_GOUT_PERIC1_IP		178
+#define CLK_GOUT_TPU_TPU		179
+#define CLK_GOUT_TPU_TPUCTL		180
+#define CLK_GOUT_TPU_BUS		181
+#define CLK_GOUT_TPU_UART		182
+#define CLK_GOUT_TPU_HPM		183
+#define CLK_GOUT_BO_BUS			184
+#define CLK_GOUT_CMU_BOOST		185
+
+/* CMU_APM */
+
+#define CLK_MOUT_APM_FUNC					1
+#define CLK_MOUT_APM_FUNCSRC					2
+#define CLK_DOUT_APM_BOOST					3
+#define CLK_DOUT_APM_USI0_UART					4
+#define CLK_DOUT_APM_USI0_USI					5
+#define CLK_DOUT_APM_USI1_UART					6
+#define CLK_GOUT_APM_FUNC					7
+#define CLK_GOUT_APM_UID_APBIF_GPIO_ALIVE_IPCLKPORT_PCLK	8
+#define CLK_GOUT_APM_UID_APBIF_GPIO_FAR_ALIVE_IPCLKPORT_PCLK	9
+#define CLK_GOUT_APM_UID_APBIF_PMU_ALIVE_IPCLKPORT_PCLK		10
+#define CLK_GOUT_APM_UID_SYSREG_APM_IPCLKPORT_PCLK		11
+#define CLK_APM_PLL_DIV2_APM					12
+#define CLK_APM_PLL_DIV4_APM					13
+#define CLK_APM_PLL_DIV16_APM					14
+
+/* CMU_MISC */
+
+#define CLK_MOUT_MISC_BUS_USER					1
+#define CLK_MOUT_MISC_SSS_USER					2
+#define CLK_DOUT_MISC_BUSP					3
+#define CLK_DOUT_MISC_GIC					4
+#define CLK_GOUT_MISC_PCLK					5
+#define CLK_GOUT_MISC_SYSREG_PCLK				6
+#define CLK_GOUT_MISC_WDT_CLUSTER0				7
+#define CLK_GOUT_MISC_WDT_CLUSTER1				8
+
+#endif /* _DT_BINDINGS_CLOCK_GOOGLE_GS101_H */
-- 
2.42.0.609.gbb76f46606-goog

[PATCH v2 02/20] dt-bindings: clock: Add Google gs101 clock management unit bindings

[Peter Griffin]

Provide dt-schema documentation for Google gs101 SoC clock controller.
Currently this adds support for cmu_top, cmu_misc and cmu_apm.

Signed-off-by: Peter Griffin <peter.griffin@linaro.org>
---
 .../bindings/clock/google,gs101-clock.yaml    | 125 ++++++++++
 include/dt-bindings/clock/google,gs101.h      | 232 ++++++++++++++++++
 2 files changed, 357 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/clock/google,gs101-clock.yaml
 create mode 100644 include/dt-bindings/clock/google,gs101.h

diff --git a/Documentation/devicetree/bindings/clock/google,gs101-clock.yaml b/Documentation/devicetree/bindings/clock/google,gs101-clock.yaml
new file mode 100644
index 000000000000..f74494594b3b
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/google,gs101-clock.yaml
@@ -0,0 +1,125 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/clock/google,gs101-clock.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Google GS101 SoC clock controller
+
+maintainers:
+  - Peter Griffin <peter.griffin@linaro.org>
+
+description: |
+  Google GS101 clock controller is comprised of several CMU units, generating
+  clocks for different domains. Those CMU units are modeled as separate device
+  tree nodes, and might depend on each other. The root clock in that clock tree
+  is OSCCLK (24.576 MHz). That external clock must be defined as a fixed-rate
+  clock in dts.
+
+  CMU_TOP is a top-level CMU, where all base clocks are prepared using PLLs and
+  dividers; all other leaf clocks (other CMUs) are usually derived from CMU_TOP.
+
+  Each clock is assigned an identifier and client nodes can use this identifier
+  to specify the clock which they consume. All clocks available for usage
+  in clock consumer nodes are defined as preprocessor macros in
+  'dt-bindings/clock/gs101.h' header.
+
+properties:
+  compatible:
+    enum:
+      - google,gs101-cmu-top
+      - google,gs101-cmu-apm
+      - google,gs101-cmu-misc
+
+  clocks:
+    minItems: 1
+    maxItems: 2
+
+  clock-names:
+    minItems: 1
+    maxItems: 2
+
+  "#clock-cells":
+    const: 1
+
+  reg:
+    maxItems: 1
+
+allOf:
+  - if:
+      properties:
+        compatible:
+          contains:
+            const: google,gs101-cmu-top
+
+    then:
+      properties:
+        clocks:
+          items:
+            - description: External reference clock (24.576 MHz)
+
+        clock-names:
+          items:
+            - const: oscclk
+
+  - if:
+      properties:
+        compatible:
+          contains:
+            const: google,gs101-cmu-misc
+
+    then:
+      properties:
+        clocks:
+          items:
+            - description: External reference clock (24.576 MHz)
+            - description: Misc bus clock (from CMU_TOP)
+
+        clock-names:
+          items:
+            - const: oscclk
+            - const: dout_cmu_misc_bus
+
+  - if:
+      properties:
+        compatible:
+          contains:
+            const: google,gs101-cmu-apm
+
+    then:
+      properties:
+        clocks:
+          items:
+            - description: External reference clock (24.576 MHz)
+
+        clock-names:
+          items:
+            - const: oscclk
+
+required:
+  - compatible
+  - "#clock-cells"
+  - clocks
+  - clock-names
+  - reg
+
+additionalProperties: false
+
+examples:
+  # Clock controller node for CMU_TOP
+  - |
+    #include <dt-bindings/clock/google,gs101.h>
+    soc {
+        #address-cells = <2>;
+        #size-cells = <1>;
+
+        cmu_top: clock-controller@1e080000 {
+            compatible = "google,gs101-cmu-top";
+            reg = <0x0 0x1e080000 0x8000>;
+            #clock-cells = <1>;
+            clocks = <&ext_24_5m>;
+            clock-names = "oscclk";
+        };
+    };
+
+...
diff --git a/include/dt-bindings/clock/google,gs101.h b/include/dt-bindings/clock/google,gs101.h
new file mode 100644
index 000000000000..7765ba68f734
--- /dev/null
+++ b/include/dt-bindings/clock/google,gs101.h
@@ -0,0 +1,232 @@
+/* SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) */
+/*
+ * Copyright (C) 2023 Linaro Ltd.
+ * Author: Peter Griffin <peter.griffin@linaro.org>
+ *
+ * Device Tree binding constants for Google gs101 clock controller.
+ */
+
+#ifndef _DT_BINDINGS_CLOCK_GOOGLE_GS101_H
+#define _DT_BINDINGS_CLOCK_GOOGLE_GS101_H
+
+/* CMU_TOP PLL*/
+#define CLK_FOUT_SHARED0_PLL		1
+#define CLK_FOUT_SHARED1_PLL		2
+#define CLK_FOUT_SHARED2_PLL		3
+#define CLK_FOUT_SHARED3_PLL		4
+#define CLK_FOUT_SPARE_PLL		5
+
+/* CMU_TOP MUX*/
+#define CLK_MOUT_SHARED0_PLL		6
+#define CLK_MOUT_SHARED1_PLL		7
+#define CLK_MOUT_SHARED2_PLL		8
+#define CLK_MOUT_SHARED3_PLL		9
+#define CLK_MOUT_SPARE_PLL		10
+#define CLK_MOUT_BUS0_BUS		11
+#define CLK_MOUT_CMU_BOOST		12
+#define CLK_MOUT_BUS1_BUS		13
+#define CLK_MOUT_BUS2_BUS		14
+#define CLK_MOUT_CORE_BUS		15
+#define CLK_MOUT_EH_BUS			16
+#define CLK_MOUT_CPUCL2_SWITCH		17
+#define CLK_MOUT_CPUCL1_SWITCH		18
+#define CLK_MOUT_CPUCL0_SWITCH		19
+#define CLK_MOUT_CPUCL0_DBG		20
+#define CLK_MOUT_CMU_HPM		21
+#define CLK_MOUT_G3D_SWITCH		22
+#define CLK_MOUT_G3D_GLB		23
+#define CLK_MOUT_DPU_BUS		24
+#define CLK_MOUT_DISP_BUS		25
+#define CLK_MOUT_G2D_G2D		26
+#define CLK_MOUT_G2D_MSCL		27
+#define CLK_MOUT_HSI0_USB31DRD		28
+#define CLK_MOUT_HSI0_BUS		29
+#define CLK_MOUT_HSI0_DPGTC		30
+#define CLK_MOUT_HSI0_USBDPDGB		31
+#define CLK_MOUT_HSI1_BUS		32
+#define CLK_MOUT_HSI1_PCIE		33
+#define CLK_MOUT_HSI2_BUS		34
+#define CLK_MOUT_HSI2_PCIE		35
+#define CLK_MOUT_HSI2_UFS_EMBD		36
+#define CLK_MOUT_HSI2_MMC_CARD		37
+#define CLK_MOUT_CSIS			38
+#define CLK_MOUT_PDP_BUS		39
+#define CLK_MOUT_PDP_VRA		40
+#define CLK_MOUT_IPP_BUS		41
+#define CLK_MOUT_G3AA			42
+#define CLK_MOUT_ITP			43
+#define CLK_MOUT_DNS_BUS		44
+#define CLK_MOUT_TNR_BUS		45
+#define CLK_MOUT_MCSC_ITSC		46
+#define CLK_MOUT_MCSC_MCSC		47
+#define CLK_MOUT_GDC_SCSC		48
+#define CLK_MOUT_GDC_GDC0		49
+#define CLK_MOUT_GDC_GDC1		50
+#define CLK_MOUT_MFC_MFC		51
+#define CLK_MOUT_MIF_SWITCH		52
+#define CLK_MOUT_MIF_BUS		53
+#define CLK_MOUT_MISC_BUS		54
+#define CLK_MOUT_MISC_SSS		55
+#define CLK_MOUT_PERIC0_IP		56
+#define CLK_MOUT_PERIC0_BUS		57
+#define CLK_MOUT_PERIC1_IP		58
+#define CLK_MOUT_PERIC1_BUS		59
+#define CLK_MOUT_TPU_TPU		60
+#define CLK_MOUT_TPU_TPUCTL		61
+#define CLK_MOUT_TPU_BUS		62
+#define CLK_MOUT_TPU_UART		63
+#define CLK_MOUT_TPU_HPM		64
+#define CLK_MOUT_BO_BUS			65
+#define CLK_MOUT_G3D_BUSD		66
+
+/* CMU_TOP Dividers*/
+#define CLK_DOUT_SHARED0_DIV3		67
+#define CLK_DOUT_SHARED0_DIV2		68
+#define CLK_DOUT_SHARED0_DIV4		69
+#define CLK_DOUT_SHARED0_DIV5		70
+#define CLK_DOUT_SHARED1_DIV3		71
+#define CLK_DOUT_SHARED1_DIV2		72
+#define CLK_DOUT_SHARED1_DIV4		73
+#define CLK_DOUT_SHARED2_DIV2		74
+#define CLK_DOUT_SHARED3_DIV2		75
+#define CLK_DOUT_BUS0_BUS		76
+#define CLK_DOUT_CMU_BOOST		77
+#define CLK_DOUT_BUS1_BUS		78
+#define CLK_DOUT_BUS2_BUS		79
+#define CLK_DOUT_CORE_BUS		80
+#define CLK_DOUT_EH_BUS			81
+#define CLK_DOUT_CPUCL2_SWITCH		82
+#define CLK_DOUT_CPUCL1_SWITCH		83
+#define CLK_DOUT_CPUCL0_SWITCH		84
+#define CLK_DOUT_CPUCL0_DBG		85
+#define CLK_DOUT_CMU_HPM		86
+#define CLK_DOUT_G3D_SWITCH		87
+#define CLK_DOUT_G3D_GLB		88
+#define CLK_DOUT_DPU_BUS		89
+#define CLK_DOUT_DISP_BUS		90
+#define CLK_DOUT_G2D_G2D		91
+#define CLK_DOUT_G2D_MSCL		92
+#define CLK_DOUT_HSI0_USB31DRD		93
+#define CLK_DOUT_HSI0_BUS		94
+#define CLK_DOUT_HSI0_DPGTC		95
+#define CLK_DOUT_HSI0_USBDPDGB		96
+#define CLK_DOUT_HSI1_BUS		97
+#define CLK_DOUT_HSI1_PCIE		98
+#define CLK_DOUT_HSI2_BUS		100
+#define CLK_DOUT_HSI2_PCIE		101
+#define CLK_DOUT_HSI2_UFS_EMBD		102
+#define CLK_DOUT_HSI2_MMC_CARD		103
+#define CLK_DOUT_CSIS			104
+#define CLK_DOUT_PDP_BUS		105
+#define CLK_DOUT_PDP_VRA		106
+#define CLK_DOUT_IPP_BUS		107
+#define CLK_DOUT_G3AA			108
+#define CLK_DOUT_ITP			109
+#define CLK_DOUT_DNS_BUS		110
+#define CLK_DOUT_TNR_BUS		111
+#define CLK_DOUT_MCSC_ITSC		112
+#define CLK_DOUT_MCSC_MCSC		113
+#define CLK_DOUT_GDC_SCSC		114
+#define CLK_DOUT_GDC_GDC0		115
+#define CLK_DOUT_GDC_GDC1		116
+#define CLK_DOUT_MFC_MFC		117
+#define CLK_DOUT_MIF_BUS		118
+#define CLK_DOUT_MISC_BUS		119
+#define CLK_DOUT_MISC_SSS		120
+#define CLK_DOUT_PERIC0_BUS		121
+#define CLK_DOUT_PERIC0_IP		122
+#define CLK_DOUT_PERIC1_BUS		123
+#define CLK_DOUT_PERIC1_IP		124
+#define CLK_DOUT_TPU_TPU		125
+#define CLK_DOUT_TPU_TPUCTL		126
+#define CLK_DOUT_TPU_BUS		127
+#define CLK_DOUT_TPU_UART		128
+#define CLK_DOUT_TPU_HPM		129
+#define CLK_DOUT_BO_BUS			130
+
+/* CMU_TOP Gates*/
+#define CLK_GOUT_BUS0_BUS		131
+#define CLK_GOUT_BUS1_BUS		132
+#define CLK_GOUT_BUS2_BUS		133
+#define CLK_GOUT_CORE_BUS		134
+#define CLK_GOUT_EH_BUS			135
+#define CLK_GOUT_CPUCL2_SWITCH		136
+#define CLK_GOUT_CPUCL1_SWITCH		137
+#define CLK_GOUT_CPUCL0_SWITCH		138
+#define CLK_GOUT_CPUCL0_DBG		139
+#define CLK_GOUT_CMU_HPM		140
+#define CLK_GOUT_G3D_SWITCH		141
+#define CLK_GOUT_G3D_GLB		142
+#define CLK_GOUT_DPU_BUS		143
+#define CLK_GOUT_DISP_BUS		144
+#define CLK_GOUT_G2D_G2D		145
+#define CLK_GOUT_G2D_MSCL		146
+#define CLK_GOUT_HSI0_USB31DRD		147
+#define CLK_GOUT_HSI0_BUS		148
+#define CLK_GOUT_HSI0_DPGTC		149
+#define CLK_GOUT_HSI0_USBDPDGB		150
+#define CLK_GOUT_HSI1_BUS		151
+#define CLK_GOUT_HSI1_PCIE		152
+#define CLK_GOUT_HSI2_BUS		153
+#define CLK_GOUT_HSI2_PCIE		154
+#define CLK_GOUT_HSI2_UFS_EMBD		155
+#define CLK_GOUT_HSI2_MMC_CARD		156
+#define CLK_GOUT_CSIS			157
+#define CLK_GOUT_PDP_BUS		158
+#define CLK_GOUT_PDP_VRA		159
+#define CLK_GOUT_IPP_BUS		160
+#define CLK_GOUT_G3AA			161
+#define CLK_GOUT_ITP			162
+#define CLK_GOUT_DNS_BUS		163
+#define CLK_GOUT_TNR_BUS		164
+#define CLK_GOUT_MCSC_ITSC		165
+#define CLK_GOUT_MCSC_MCSC		166
+#define CLK_GOUT_GDC_SCSC		167
+#define CLK_GOUT_GDC_GDC0		168
+#define CLK_GOUT_GDC_GDC1		169
+#define CLK_GOUT_MFC_MFC		170
+#define CLK_GOUT_MIF_SWITCH		171
+#define CLK_GOUT_MIF_BUS		172
+#define CLK_GOUT_MISC_BUS		173
+#define CLK_GOUT_MISC_SSS		174
+#define CLK_GOUT_PERIC0_BUS		175
+#define CLK_GOUT_PERIC0_IP		176
+#define CLK_GOUT_PERIC1_BUS		177
+#define CLK_GOUT_PERIC1_IP		178
+#define CLK_GOUT_TPU_TPU		179
+#define CLK_GOUT_TPU_TPUCTL		180
+#define CLK_GOUT_TPU_BUS		181
+#define CLK_GOUT_TPU_UART		182
+#define CLK_GOUT_TPU_HPM		183
+#define CLK_GOUT_BO_BUS			184
+#define CLK_GOUT_CMU_BOOST		185
+
+/* CMU_APM */
+
+#define CLK_MOUT_APM_FUNC					1
+#define CLK_MOUT_APM_FUNCSRC					2
+#define CLK_DOUT_APM_BOOST					3
+#define CLK_DOUT_APM_USI0_UART					4
+#define CLK_DOUT_APM_USI0_USI					5
+#define CLK_DOUT_APM_USI1_UART					6
+#define CLK_GOUT_APM_FUNC					7
+#define CLK_GOUT_APM_UID_APBIF_GPIO_ALIVE_IPCLKPORT_PCLK	8
+#define CLK_GOUT_APM_UID_APBIF_GPIO_FAR_ALIVE_IPCLKPORT_PCLK	9
+#define CLK_GOUT_APM_UID_APBIF_PMU_ALIVE_IPCLKPORT_PCLK		10
+#define CLK_GOUT_APM_UID_SYSREG_APM_IPCLKPORT_PCLK		11
+#define CLK_APM_PLL_DIV2_APM					12
+#define CLK_APM_PLL_DIV4_APM					13
+#define CLK_APM_PLL_DIV16_APM					14
+
+/* CMU_MISC */
+
+#define CLK_MOUT_MISC_BUS_USER					1
+#define CLK_MOUT_MISC_SSS_USER					2
+#define CLK_DOUT_MISC_BUSP					3
+#define CLK_DOUT_MISC_GIC					4
+#define CLK_GOUT_MISC_PCLK					5
+#define CLK_GOUT_MISC_SYSREG_PCLK				6
+#define CLK_GOUT_MISC_WDT_CLUSTER0				7
+#define CLK_GOUT_MISC_WDT_CLUSTER1				8
+
+#endif /* _DT_BINDINGS_CLOCK_GOOGLE_GS101_H */
-- 
2.42.0.609.gbb76f46606-goog


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH v2 03/20] dt-bindings: soc: google: exynos-sysreg: add dedicated SYSREG compatibles to GS101

[Peter Griffin]

GS101 has three different SYSREG controllers, add dedicated
compatibles for them to the documentation.

Signed-off-by: Peter Griffin <peter.griffin@linaro.org>
---
 .../bindings/soc/samsung/samsung,exynos-sysreg.yaml         | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/Documentation/devicetree/bindings/soc/samsung/samsung,exynos-sysreg.yaml b/Documentation/devicetree/bindings/soc/samsung/samsung,exynos-sysreg.yaml
index 163e912e9cad..dbd12a97faad 100644
--- a/Documentation/devicetree/bindings/soc/samsung/samsung,exynos-sysreg.yaml
+++ b/Documentation/devicetree/bindings/soc/samsung/samsung,exynos-sysreg.yaml
@@ -30,6 +30,12 @@ properties:
               - samsung,exynos5433-fsys-sysreg
           - const: samsung,exynos5433-sysreg
           - const: syscon
+      - items:
+          - enum:
+              - google,gs101-peric0-sysreg
+              - google,gs101-peric1-sysreg
+              - google,gs101-apm-sysreg
+          - const: syscon
       - items:
           - enum:
               - samsung,exynos5433-sysreg
-- 
2.42.0.609.gbb76f46606-goog

[PATCH v2 03/20] dt-bindings: soc: google: exynos-sysreg: add dedicated SYSREG compatibles to GS101

[Peter Griffin]

GS101 has three different SYSREG controllers, add dedicated
compatibles for them to the documentation.

Signed-off-by: Peter Griffin <peter.griffin@linaro.org>
---
 .../bindings/soc/samsung/samsung,exynos-sysreg.yaml         | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/Documentation/devicetree/bindings/soc/samsung/samsung,exynos-sysreg.yaml b/Documentation/devicetree/bindings/soc/samsung/samsung,exynos-sysreg.yaml
index 163e912e9cad..dbd12a97faad 100644
--- a/Documentation/devicetree/bindings/soc/samsung/samsung,exynos-sysreg.yaml
+++ b/Documentation/devicetree/bindings/soc/samsung/samsung,exynos-sysreg.yaml
@@ -30,6 +30,12 @@ properties:
               - samsung,exynos5433-fsys-sysreg
           - const: samsung,exynos5433-sysreg
           - const: syscon
+      - items:
+          - enum:
+              - google,gs101-peric0-sysreg
+              - google,gs101-peric1-sysreg
+              - google,gs101-apm-sysreg
+          - const: syscon
       - items:
           - enum:
               - samsung,exynos5433-sysreg
-- 
2.42.0.609.gbb76f46606-goog


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH v2 04/20] dt-bindings: watchdog: Document Google gs101 & gs201 watchdog bindings

[Peter Griffin]

Add the "google,gs101-wdt" and "google,gs201-wdt" compatibles to the
dt-schema documentation.

gs101 SoC has two CPU clusters and each cluster has its own dedicated
watchdog timer (similar to exynos850 and exynosautov9 SoCs).

These WDT instances are controlled using different bits in PMU
registers.

Signed-off-by: Peter Griffin <peter.griffin@linaro.org>
---
 .../devicetree/bindings/watchdog/samsung-wdt.yaml      | 10 ++++++++--
 1 file changed, 8 insertions(+), 2 deletions(-)

diff --git a/Documentation/devicetree/bindings/watchdog/samsung-wdt.yaml b/Documentation/devicetree/bindings/watchdog/samsung-wdt.yaml
index 8fb6656ba0c2..67c8767f0499 100644
--- a/Documentation/devicetree/bindings/watchdog/samsung-wdt.yaml
+++ b/Documentation/devicetree/bindings/watchdog/samsung-wdt.yaml
@@ -17,6 +17,8 @@ description: |+
 properties:
   compatible:
     enum:
+      - google,gs101-wdt                      # for Google gs101
+      - google,gs201-wdt                      # for Google gs201
       - samsung,s3c2410-wdt                   # for S3C2410
       - samsung,s3c6410-wdt                   # for S3C6410, S5PV210 and Exynos4
       - samsung,exynos5250-wdt                # for Exynos5250
@@ -42,13 +44,13 @@ properties:
   samsung,cluster-index:
     $ref: /schemas/types.yaml#/definitions/uint32
     description:
-      Index of CPU cluster on which watchdog is running (in case of Exynos850)
+      Index of CPU cluster on which watchdog is running (in case of Exynos850 or Google gsx01)
 
   samsung,syscon-phandle:
     $ref: /schemas/types.yaml#/definitions/phandle
     description:
       Phandle to the PMU system controller node (in case of Exynos5250,
-      Exynos5420, Exynos7 and Exynos850).
+      Exynos5420, Exynos7, Exynos850 and gsx01).
 
 required:
   - compatible
@@ -69,6 +71,8 @@ allOf:
               - samsung,exynos7-wdt
               - samsung,exynos850-wdt
               - samsung,exynosautov9-wdt
+              - google,gs101-wdt
+              - google,gs201-wdt
     then:
       required:
         - samsung,syscon-phandle
@@ -79,6 +83,8 @@ allOf:
             enum:
               - samsung,exynos850-wdt
               - samsung,exynosautov9-wdt
+              - google,gs101-wdt
+              - google,gs201-wdt
     then:
       properties:
         clocks:
-- 
2.42.0.609.gbb76f46606-goog

[PATCH v2 04/20] dt-bindings: watchdog: Document Google gs101 & gs201 watchdog bindings

[Peter Griffin]

Add the "google,gs101-wdt" and "google,gs201-wdt" compatibles to the
dt-schema documentation.

gs101 SoC has two CPU clusters and each cluster has its own dedicated
watchdog timer (similar to exynos850 and exynosautov9 SoCs).

These WDT instances are controlled using different bits in PMU
registers.

Signed-off-by: Peter Griffin <peter.griffin@linaro.org>
---
 .../devicetree/bindings/watchdog/samsung-wdt.yaml      | 10 ++++++++--
 1 file changed, 8 insertions(+), 2 deletions(-)

diff --git a/Documentation/devicetree/bindings/watchdog/samsung-wdt.yaml b/Documentation/devicetree/bindings/watchdog/samsung-wdt.yaml
index 8fb6656ba0c2..67c8767f0499 100644
--- a/Documentation/devicetree/bindings/watchdog/samsung-wdt.yaml
+++ b/Documentation/devicetree/bindings/watchdog/samsung-wdt.yaml
@@ -17,6 +17,8 @@ description: |+
 properties:
   compatible:
     enum:
+      - google,gs101-wdt                      # for Google gs101
+      - google,gs201-wdt                      # for Google gs201
       - samsung,s3c2410-wdt                   # for S3C2410
       - samsung,s3c6410-wdt                   # for S3C6410, S5PV210 and Exynos4
       - samsung,exynos5250-wdt                # for Exynos5250
@@ -42,13 +44,13 @@ properties:
   samsung,cluster-index:
     $ref: /schemas/types.yaml#/definitions/uint32
     description:
-      Index of CPU cluster on which watchdog is running (in case of Exynos850)
+      Index of CPU cluster on which watchdog is running (in case of Exynos850 or Google gsx01)
 
   samsung,syscon-phandle:
     $ref: /schemas/types.yaml#/definitions/phandle
     description:
       Phandle to the PMU system controller node (in case of Exynos5250,
-      Exynos5420, Exynos7 and Exynos850).
+      Exynos5420, Exynos7, Exynos850 and gsx01).
 
 required:
   - compatible
@@ -69,6 +71,8 @@ allOf:
               - samsung,exynos7-wdt
               - samsung,exynos850-wdt
               - samsung,exynosautov9-wdt
+              - google,gs101-wdt
+              - google,gs201-wdt
     then:
       required:
         - samsung,syscon-phandle
@@ -79,6 +83,8 @@ allOf:
             enum:
               - samsung,exynos850-wdt
               - samsung,exynosautov9-wdt
+              - google,gs101-wdt
+              - google,gs201-wdt
     then:
       properties:
         clocks:
-- 
2.42.0.609.gbb76f46606-goog


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH v2 05/20] dt-bindings: arm: google: Add bindings for Google ARM platforms

[Peter Griffin]

This introduces bindings and dt-schema for the Google tensor SoCs.
Currently just gs101 and pixel 6 are supported.

Signed-off-by: Peter Griffin <peter.griffin@linaro.org>
Reviewed-by: Rob Herring <robh@kernel.org>
---
 .../devicetree/bindings/arm/google.yaml       | 46 +++++++++++++++++++
 1 file changed, 46 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/arm/google.yaml

diff --git a/Documentation/devicetree/bindings/arm/google.yaml b/Documentation/devicetree/bindings/arm/google.yaml
new file mode 100644
index 000000000000..167945e4d5ee
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/google.yaml
@@ -0,0 +1,46 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/arm/google.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Google Tensor platforms
+
+maintainers:
+  - Peter Griffin <peter.griffin@linaro.org>
+
+description: |
+  ARM platforms using SoCs designed by Google branded "Tensor" used in Pixel
+  devices.
+
+  Currently upstream this is devices using "gs101" SoC which is found in Pixel
+  6, Pixel 6 Pro and Pixel 6a.
+
+  Google have a few different names for the SoC.
+  - Marketing name ("Tensor")
+  - Codename ("Whitechapel")
+  - SoC ID ("gs101")
+  - Die ID ("S5P9845");
+
+  Likewise there are a couple of names for the actual device
+  - Marketing name ("Pixel 6")
+  - Codename ("Oriole")
+
+  Devicetrees should use the lowercased SoC ID and lowercased board codename.
+  e.g. gs101 and gs101-oriole
+
+properties:
+  $nodename:
+    const: '/'
+  compatible:
+    oneOf:
+
+      - description: Google Pixel 6 / Oriole
+        items:
+          - enum:
+              - google,gs101-oriole
+          - const: google,gs101
+
+additionalProperties: true
+
+...
-- 
2.42.0.609.gbb76f46606-goog

[PATCH v2 05/20] dt-bindings: arm: google: Add bindings for Google ARM platforms

[Peter Griffin]

This introduces bindings and dt-schema for the Google tensor SoCs.
Currently just gs101 and pixel 6 are supported.

Signed-off-by: Peter Griffin <peter.griffin@linaro.org>
Reviewed-by: Rob Herring <robh@kernel.org>
---
 .../devicetree/bindings/arm/google.yaml       | 46 +++++++++++++++++++
 1 file changed, 46 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/arm/google.yaml

diff --git a/Documentation/devicetree/bindings/arm/google.yaml b/Documentation/devicetree/bindings/arm/google.yaml
new file mode 100644
index 000000000000..167945e4d5ee
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/google.yaml
@@ -0,0 +1,46 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/arm/google.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Google Tensor platforms
+
+maintainers:
+  - Peter Griffin <peter.griffin@linaro.org>
+
+description: |
+  ARM platforms using SoCs designed by Google branded "Tensor" used in Pixel
+  devices.
+
+  Currently upstream this is devices using "gs101" SoC which is found in Pixel
+  6, Pixel 6 Pro and Pixel 6a.
+
+  Google have a few different names for the SoC.
+  - Marketing name ("Tensor")
+  - Codename ("Whitechapel")
+  - SoC ID ("gs101")
+  - Die ID ("S5P9845");
+
+  Likewise there are a couple of names for the actual device
+  - Marketing name ("Pixel 6")
+  - Codename ("Oriole")
+
+  Devicetrees should use the lowercased SoC ID and lowercased board codename.
+  e.g. gs101 and gs101-oriole
+
+properties:
+  $nodename:
+    const: '/'
+  compatible:
+    oneOf:
+
+      - description: Google Pixel 6 / Oriole
+        items:
+          - enum:
+              - google,gs101-oriole
+          - const: google,gs101
+
+additionalProperties: true
+
+...
-- 
2.42.0.609.gbb76f46606-goog


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH v2 06/20] dt-bindings: pinctrl: samsung: add google,gs101-pinctrl compatible

[Peter Griffin]

Add the "google,gs101-pinctrl" compatible to the dt-schema bindings
documentation.

Add maxItems of 50 for the interrupts property as gs101 can have
multiple irqs.

Signed-off-by: Peter Griffin <peter.griffin@linaro.org>
---
 .../bindings/pinctrl/samsung,pinctrl.yaml     | 19 +++++++++++++++++++
 1 file changed, 19 insertions(+)

diff --git a/Documentation/devicetree/bindings/pinctrl/samsung,pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/samsung,pinctrl.yaml
index 26614621774a..2464bc43aacb 100644
--- a/Documentation/devicetree/bindings/pinctrl/samsung,pinctrl.yaml
+++ b/Documentation/devicetree/bindings/pinctrl/samsung,pinctrl.yaml
@@ -35,6 +35,7 @@ properties:
 
   compatible:
     enum:
+      - google,gs101-pinctrl
       - samsung,s3c2412-pinctrl
       - samsung,s3c2416-pinctrl
       - samsung,s3c2440-pinctrl
@@ -134,6 +135,24 @@ allOf:
           minItems: 1
           maxItems: 1
 
+  - if:
+      properties:
+        compatible:
+          contains:
+            const: google,gs101-pinctrl
+    then:
+      properties:
+        interrupts:
+          description:
+            Required for external wakeup interrupts. List all external
+            wakeup interrupts supported by this bank.
+          minItems: 1
+          maxItems: 50
+    else:
+      properties:
+        interrupts:
+          maxItems: 1
+
 additionalProperties: false
 
 examples:
-- 
2.42.0.609.gbb76f46606-goog

[PATCH v2 06/20] dt-bindings: pinctrl: samsung: add google,gs101-pinctrl compatible

[Peter Griffin]

Add the "google,gs101-pinctrl" compatible to the dt-schema bindings
documentation.

Add maxItems of 50 for the interrupts property as gs101 can have
multiple irqs.

Signed-off-by: Peter Griffin <peter.griffin@linaro.org>
---
 .../bindings/pinctrl/samsung,pinctrl.yaml     | 19 +++++++++++++++++++
 1 file changed, 19 insertions(+)

diff --git a/Documentation/devicetree/bindings/pinctrl/samsung,pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/samsung,pinctrl.yaml
index 26614621774a..2464bc43aacb 100644
--- a/Documentation/devicetree/bindings/pinctrl/samsung,pinctrl.yaml
+++ b/Documentation/devicetree/bindings/pinctrl/samsung,pinctrl.yaml
@@ -35,6 +35,7 @@ properties:
 
   compatible:
     enum:
+      - google,gs101-pinctrl
       - samsung,s3c2412-pinctrl
       - samsung,s3c2416-pinctrl
       - samsung,s3c2440-pinctrl
@@ -134,6 +135,24 @@ allOf:
           minItems: 1
           maxItems: 1
 
+  - if:
+      properties:
+        compatible:
+          contains:
+            const: google,gs101-pinctrl
+    then:
+      properties:
+        interrupts:
+          description:
+            Required for external wakeup interrupts. List all external
+            wakeup interrupts supported by this bank.
+          minItems: 1
+          maxItems: 50
+    else:
+      properties:
+        interrupts:
+          maxItems: 1
+
 additionalProperties: false
 
 examples:
-- 
2.42.0.609.gbb76f46606-goog


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH v2 07/20] dt-bindings: pinctrl: samsung: add gs101-wakeup-eint compatible

[Peter Griffin]

gs101 is similar to newer Exynos SoCs like Exynos850 and ExynosAutov9
where more than one pin controller can do external wake-up interrupt.
So add a dedicated compatible for it.

Signed-off-by: Peter Griffin <peter.griffin@linaro.org>
---
 .../bindings/pinctrl/samsung,pinctrl-wakeup-interrupt.yaml      | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/Documentation/devicetree/bindings/pinctrl/samsung,pinctrl-wakeup-interrupt.yaml b/Documentation/devicetree/bindings/pinctrl/samsung,pinctrl-wakeup-interrupt.yaml
index 1de91a51234d..7cddce761c46 100644
--- a/Documentation/devicetree/bindings/pinctrl/samsung,pinctrl-wakeup-interrupt.yaml
+++ b/Documentation/devicetree/bindings/pinctrl/samsung,pinctrl-wakeup-interrupt.yaml
@@ -29,6 +29,7 @@ description: |
 properties:
   compatible:
     enum:
+      - google,gs101-wakeup-eint
       - samsung,s3c2410-wakeup-eint
       - samsung,s3c2412-wakeup-eint
       - samsung,s3c64xx-wakeup-eint
@@ -99,6 +100,7 @@ allOf:
             enum:
               - samsung,exynos850-wakeup-eint
               - samsung,exynosautov9-wakeup-eint
+              - google,gs101-wakeup-eint
     then:
       properties:
         interrupts: false
-- 
2.42.0.609.gbb76f46606-goog

[PATCH v2 07/20] dt-bindings: pinctrl: samsung: add gs101-wakeup-eint compatible

[Peter Griffin]

gs101 is similar to newer Exynos SoCs like Exynos850 and ExynosAutov9
where more than one pin controller can do external wake-up interrupt.
So add a dedicated compatible for it.

Signed-off-by: Peter Griffin <peter.griffin@linaro.org>
---
 .../bindings/pinctrl/samsung,pinctrl-wakeup-interrupt.yaml      | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/Documentation/devicetree/bindings/pinctrl/samsung,pinctrl-wakeup-interrupt.yaml b/Documentation/devicetree/bindings/pinctrl/samsung,pinctrl-wakeup-interrupt.yaml
index 1de91a51234d..7cddce761c46 100644
--- a/Documentation/devicetree/bindings/pinctrl/samsung,pinctrl-wakeup-interrupt.yaml
+++ b/Documentation/devicetree/bindings/pinctrl/samsung,pinctrl-wakeup-interrupt.yaml
@@ -29,6 +29,7 @@ description: |
 properties:
   compatible:
     enum:
+      - google,gs101-wakeup-eint
       - samsung,s3c2410-wakeup-eint
       - samsung,s3c2412-wakeup-eint
       - samsung,s3c64xx-wakeup-eint
@@ -99,6 +100,7 @@ allOf:
             enum:
               - samsung,exynos850-wakeup-eint
               - samsung,exynosautov9-wakeup-eint
+              - google,gs101-wakeup-eint
     then:
       properties:
         interrupts: false
-- 
2.42.0.609.gbb76f46606-goog


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH v2 08/20] dt-bindings: serial: samsung: Add google-gs101-uart compatible

[Peter Griffin]

Add dedicated google-gs101-uart compatible to the dt-schema for
representing uart of the Google Tensor gs101 SoC.

Signed-off-by: Peter Griffin <peter.griffin@linaro.org>
---
 Documentation/devicetree/bindings/serial/samsung_uart.yaml | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/Documentation/devicetree/bindings/serial/samsung_uart.yaml b/Documentation/devicetree/bindings/serial/samsung_uart.yaml
index 8bd88d5cbb11..72471ebe5734 100644
--- a/Documentation/devicetree/bindings/serial/samsung_uart.yaml
+++ b/Documentation/devicetree/bindings/serial/samsung_uart.yaml
@@ -19,11 +19,13 @@ properties:
   compatible:
     oneOf:
       - items:
+          - const: google,gs101-uart
           - const: samsung,exynosautov9-uart
           - const: samsung,exynos850-uart
       - enum:
           - apple,s5l-uart
           - axis,artpec8-uart
+          - google,gs101-uart
           - samsung,s3c2410-uart
           - samsung,s3c2412-uart
           - samsung,s3c2440-uart
-- 
2.42.0.609.gbb76f46606-goog

[PATCH v2 08/20] dt-bindings: serial: samsung: Add google-gs101-uart compatible

[Peter Griffin]

Add dedicated google-gs101-uart compatible to the dt-schema for
representing uart of the Google Tensor gs101 SoC.

Signed-off-by: Peter Griffin <peter.griffin@linaro.org>
---
 Documentation/devicetree/bindings/serial/samsung_uart.yaml | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/Documentation/devicetree/bindings/serial/samsung_uart.yaml b/Documentation/devicetree/bindings/serial/samsung_uart.yaml
index 8bd88d5cbb11..72471ebe5734 100644
--- a/Documentation/devicetree/bindings/serial/samsung_uart.yaml
+++ b/Documentation/devicetree/bindings/serial/samsung_uart.yaml
@@ -19,11 +19,13 @@ properties:
   compatible:
     oneOf:
       - items:
+          - const: google,gs101-uart
           - const: samsung,exynosautov9-uart
           - const: samsung,exynos850-uart
       - enum:
           - apple,s5l-uart
           - axis,artpec8-uart
+          - google,gs101-uart
           - samsung,s3c2410-uart
           - samsung,s3c2412-uart
           - samsung,s3c2440-uart
-- 
2.42.0.609.gbb76f46606-goog


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH v2 09/20] clk: samsung: clk-pll: Add support for pll_{0516,0517,518}

[Peter Griffin]

These plls are found in the Tensor gs101 SoC found in the Pixel 6.

pll0516x: Integer PLL with high frequency
pll0517x: Integer PLL with middle frequency
pll0518x: Integer PLL with low frequency

PLL0516x
FOUT = (MDIV * 2 * FIN)/PDIV * 2^SDIV)

PLL0517x and PLL0518x
FOUT = (MDIV * FIN)/PDIV*2^SDIV)

The PLLs are similar enough to pll_0822x that the same code can handle
both. The main difference is the change in the fout formula for the
high frequency 0516 pll.

Locktime for 516,517 & 518 is 150 the same as the pll_0822x lock factor.
MDIV, SDIV PDIV masks and bit shifts are also the same as 0822x.

When defining the PLL the "con" parameter should be set to CON3
register, like this

PLL(pll_0517x, CLK_FOUT_SHARED0_PLL, "fout_shared0_pll", "oscclk",
    PLL_LOCKTIME_PLL_SHARED0, PLL_CON3_PLL_SHARED0,
    NULL),

Signed-off-by: Peter Griffin <peter.griffin@linaro.org>
---
 drivers/clk/samsung/clk-pll.c | 9 ++++++++-
 drivers/clk/samsung/clk-pll.h | 3 +++
 2 files changed, 11 insertions(+), 1 deletion(-)

diff --git a/drivers/clk/samsung/clk-pll.c b/drivers/clk/samsung/clk-pll.c
index 74934c6182ce..4ef9fea2a425 100644
--- a/drivers/clk/samsung/clk-pll.c
+++ b/drivers/clk/samsung/clk-pll.c
@@ -442,7 +442,11 @@ static unsigned long samsung_pll0822x_recalc_rate(struct clk_hw *hw,
 	pdiv = (pll_con3 >> PLL0822X_PDIV_SHIFT) & PLL0822X_PDIV_MASK;
 	sdiv = (pll_con3 >> PLL0822X_SDIV_SHIFT) & PLL0822X_SDIV_MASK;
 
-	fvco *= mdiv;
+	if (pll->type == pll_0516x)
+		fvco = fvco * 2 * mdiv;
+	else
+		fvco *= mdiv;
+
 	do_div(fvco, (pdiv << sdiv));
 
 	return (unsigned long)fvco;
@@ -1316,6 +1320,9 @@ static void __init _samsung_clk_register_pll(struct samsung_clk_provider *ctx,
 	case pll_1417x:
 	case pll_0818x:
 	case pll_0822x:
+	case pll_0516x:
+	case pll_0517x:
+	case pll_0518x:
 		pll->enable_offs = PLL0822X_ENABLE_SHIFT;
 		pll->lock_offs = PLL0822X_LOCK_STAT_SHIFT;
 		if (!pll->rate_table)
diff --git a/drivers/clk/samsung/clk-pll.h b/drivers/clk/samsung/clk-pll.h
index 0725d485c6ee..ffd3d52c0dec 100644
--- a/drivers/clk/samsung/clk-pll.h
+++ b/drivers/clk/samsung/clk-pll.h
@@ -38,6 +38,9 @@ enum samsung_pll_type {
 	pll_0822x,
 	pll_0831x,
 	pll_142xx,
+	pll_0516x,
+	pll_0517x,
+	pll_0518x,
 };
 
 #define PLL_RATE(_fin, _m, _p, _s, _k, _ks) \
-- 
2.42.0.609.gbb76f46606-goog

[PATCH v2 09/20] clk: samsung: clk-pll: Add support for pll_{0516,0517,518}

[Peter Griffin]

These plls are found in the Tensor gs101 SoC found in the Pixel 6.

pll0516x: Integer PLL with high frequency
pll0517x: Integer PLL with middle frequency
pll0518x: Integer PLL with low frequency

PLL0516x
FOUT = (MDIV * 2 * FIN)/PDIV * 2^SDIV)

PLL0517x and PLL0518x
FOUT = (MDIV * FIN)/PDIV*2^SDIV)

The PLLs are similar enough to pll_0822x that the same code can handle
both. The main difference is the change in the fout formula for the
high frequency 0516 pll.

Locktime for 516,517 & 518 is 150 the same as the pll_0822x lock factor.
MDIV, SDIV PDIV masks and bit shifts are also the same as 0822x.

When defining the PLL the "con" parameter should be set to CON3
register, like this

PLL(pll_0517x, CLK_FOUT_SHARED0_PLL, "fout_shared0_pll", "oscclk",
    PLL_LOCKTIME_PLL_SHARED0, PLL_CON3_PLL_SHARED0,
    NULL),

Signed-off-by: Peter Griffin <peter.griffin@linaro.org>
---
 drivers/clk/samsung/clk-pll.c | 9 ++++++++-
 drivers/clk/samsung/clk-pll.h | 3 +++
 2 files changed, 11 insertions(+), 1 deletion(-)

diff --git a/drivers/clk/samsung/clk-pll.c b/drivers/clk/samsung/clk-pll.c
index 74934c6182ce..4ef9fea2a425 100644
--- a/drivers/clk/samsung/clk-pll.c
+++ b/drivers/clk/samsung/clk-pll.c
@@ -442,7 +442,11 @@ static unsigned long samsung_pll0822x_recalc_rate(struct clk_hw *hw,
 	pdiv = (pll_con3 >> PLL0822X_PDIV_SHIFT) & PLL0822X_PDIV_MASK;
 	sdiv = (pll_con3 >> PLL0822X_SDIV_SHIFT) & PLL0822X_SDIV_MASK;
 
-	fvco *= mdiv;
+	if (pll->type == pll_0516x)
+		fvco = fvco * 2 * mdiv;
+	else
+		fvco *= mdiv;
+
 	do_div(fvco, (pdiv << sdiv));
 
 	return (unsigned long)fvco;
@@ -1316,6 +1320,9 @@ static void __init _samsung_clk_register_pll(struct samsung_clk_provider *ctx,
 	case pll_1417x:
 	case pll_0818x:
 	case pll_0822x:
+	case pll_0516x:
+	case pll_0517x:
+	case pll_0518x:
 		pll->enable_offs = PLL0822X_ENABLE_SHIFT;
 		pll->lock_offs = PLL0822X_LOCK_STAT_SHIFT;
 		if (!pll->rate_table)
diff --git a/drivers/clk/samsung/clk-pll.h b/drivers/clk/samsung/clk-pll.h
index 0725d485c6ee..ffd3d52c0dec 100644
--- a/drivers/clk/samsung/clk-pll.h
+++ b/drivers/clk/samsung/clk-pll.h
@@ -38,6 +38,9 @@ enum samsung_pll_type {
 	pll_0822x,
 	pll_0831x,
 	pll_142xx,
+	pll_0516x,
+	pll_0517x,
+	pll_0518x,
 };
 
 #define PLL_RATE(_fin, _m, _p, _s, _k, _ks) \
-- 
2.42.0.609.gbb76f46606-goog


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH v2 10/20] clk: samsung: clk-gs101: Add cmu_top registers, plls, mux and gates

[Peter Griffin]

CMU_TOP is the top level clock management unit which contains PLLs, muxes
and gates that feed the other clock management units.

Signed-off-by: Peter Griffin <peter.griffin@linaro.org>
---
 drivers/clk/samsung/Kconfig     |    9 +
 drivers/clk/samsung/Makefile    |    2 +
 drivers/clk/samsung/clk-gs101.c | 1551 +++++++++++++++++++++++++++++++
 3 files changed, 1562 insertions(+)
 create mode 100644 drivers/clk/samsung/clk-gs101.c

diff --git a/drivers/clk/samsung/Kconfig b/drivers/clk/samsung/Kconfig
index 76a494e95027..14362ec9c543 100644
--- a/drivers/clk/samsung/Kconfig
+++ b/drivers/clk/samsung/Kconfig
@@ -12,6 +12,7 @@ config COMMON_CLK_SAMSUNG
 	select EXYNOS_5410_COMMON_CLK if ARM && SOC_EXYNOS5410
 	select EXYNOS_5420_COMMON_CLK if ARM && SOC_EXYNOS5420
 	select EXYNOS_ARM64_COMMON_CLK if ARM64 && ARCH_EXYNOS
+	select GOOGLE_GS101_COMMON_CLK if ARM64 && ARCH_GOOGLE_TENSOR
 	select TESLA_FSD_COMMON_CLK if ARM64 && ARCH_TESLA_FSD
 
 config S3C64XX_COMMON_CLK
@@ -95,6 +96,14 @@ config EXYNOS_CLKOUT
 	  status of the certains clocks from SoC, but it could also be tied to
 	  other devices as an input clock.
 
+config GOOGLE_GS101_COMMON_CLK
+	bool "Google gs101 clock controller support" if COMPILE_TEST
+	depends on COMMON_CLK_SAMSUNG
+	depends on EXYNOS_ARM64_COMMON_CLK
+	help
+	  Support for the clock controller present on the Google gs101 SoC.
+	  Choose Y here only if you build for this SoC.
+
 config TESLA_FSD_COMMON_CLK
 	bool "Tesla FSD clock controller support" if COMPILE_TEST
 	depends on COMMON_CLK_SAMSUNG
diff --git a/drivers/clk/samsung/Makefile b/drivers/clk/samsung/Makefile
index ebbeacabe88f..49146937d957 100644
--- a/drivers/clk/samsung/Makefile
+++ b/drivers/clk/samsung/Makefile
@@ -21,6 +21,8 @@ obj-$(CONFIG_EXYNOS_ARM64_COMMON_CLK)	+= clk-exynos7.o
 obj-$(CONFIG_EXYNOS_ARM64_COMMON_CLK)	+= clk-exynos7885.o
 obj-$(CONFIG_EXYNOS_ARM64_COMMON_CLK)	+= clk-exynos850.o
 obj-$(CONFIG_EXYNOS_ARM64_COMMON_CLK)	+= clk-exynosautov9.o
+obj-$(CONFIG_GOOGLE_GS101_COMMON_CLK)	+= clk-gs101.o
 obj-$(CONFIG_S3C64XX_COMMON_CLK)	+= clk-s3c64xx.o
 obj-$(CONFIG_S5PV210_COMMON_CLK)	+= clk-s5pv210.o clk-s5pv210-audss.o
 obj-$(CONFIG_TESLA_FSD_COMMON_CLK)	+= clk-fsd.o
+
diff --git a/drivers/clk/samsung/clk-gs101.c b/drivers/clk/samsung/clk-gs101.c
new file mode 100644
index 000000000000..e2c62754b1eb
--- /dev/null
+++ b/drivers/clk/samsung/clk-gs101.c
@@ -0,0 +1,1551 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Copyright (C) 2023 Linaro Ltd.
+ * Author: Peter Griffin <peter.griffin@linaro.org>
+ *
+ * Common Clock Framework support for GS101.
+ */
+
+#include <linux/clk.h>
+#include <linux/clk-provider.h>
+#include <linux/of.h>
+#include <linux/of_device.h>
+#include <linux/platform_device.h>
+
+#include <dt-bindings/clock/google,gs101.h>
+
+#include "clk.h"
+#include "clk-exynos-arm64.h"
+
+/* NOTE: Must be equal to the last clock ID increased by one */
+#define TOP_NR_CLK                     (CLK_GOUT_CMU_BOOST + 1)
+
+/* ---- CMU_TOP ------------------------------------------------------------- */
+
+/* Register Offset definitions for CMU_TOP (0x1e080000) */
+
+#define PLL_LOCKTIME_PLL_SHARED0			0x0000
+#define PLL_LOCKTIME_PLL_SHARED1			0x0004
+#define PLL_LOCKTIME_PLL_SHARED2			0x0008
+#define PLL_LOCKTIME_PLL_SHARED3			0x000c
+#define PLL_LOCKTIME_PLL_SPARE				0x0010
+#define PLL_CON0_PLL_SHARED0				0x0100
+#define PLL_CON1_PLL_SHARED0				0x0104
+#define PLL_CON2_PLL_SHARED0				0x0108
+#define PLL_CON3_PLL_SHARED0				0x010c
+#define PLL_CON4_PLL_SHARED0				0x0110
+#define PLL_CON0_PLL_SHARED1				0x0140
+#define PLL_CON1_PLL_SHARED1				0x0144
+#define PLL_CON2_PLL_SHARED1				0x0148
+#define PLL_CON3_PLL_SHARED1				0x014c
+#define PLL_CON4_PLL_SHARED1				0x0150
+#define PLL_CON0_PLL_SHARED2				0x0180
+#define PLL_CON1_PLL_SHARED2				0x0184
+#define PLL_CON2_PLL_SHARED2				0x0188
+#define PLL_CON3_PLL_SHARED2				0x018c
+#define PLL_CON4_PLL_SHARED2				0x0190
+#define PLL_CON0_PLL_SHARED3				0x01c0
+#define PLL_CON1_PLL_SHARED3				0x01c4
+#define PLL_CON2_PLL_SHARED3				0x01c8
+#define PLL_CON3_PLL_SHARED3				0x01cc
+#define PLL_CON4_PLL_SHARED3				0x01d0
+#define PLL_CON0_PLL_SPARE				0x0200
+#define PLL_CON1_PLL_SPARE				0x0204
+#define PLL_CON2_PLL_SPARE				0x0208
+#define PLL_CON3_PLL_SPARE				0x020c
+#define PLL_CON4_PLL_SPARE				0x0210
+#define CMU_CMU_TOP_CONTROLLER_OPTION			0x0800
+#define CLKOUT_CON_BLK_CMU_CMU_TOP_CLKOUT0		0x0810
+#define CMU_HCHGEN_CLKMUX_CMU_BOOST			0x0840
+#define CMU_HCHGEN_CLKMUX_TOP_BOOST			0x0844
+#define CMU_HCHGEN_CLKMUX				0x0850
+#define POWER_FAIL_DETECT_PLL				0x0864
+#define EARLY_WAKEUP_FORCED_0_ENABLE			0x0870
+#define EARLY_WAKEUP_FORCED_1_ENABLE			0x0874
+#define EARLY_WAKEUP_APM_CTRL				0x0878
+#define EARLY_WAKEUP_CLUSTER0_CTRL			0x087c
+#define EARLY_WAKEUP_DPU_CTRL				0x0880
+#define EARLY_WAKEUP_CSIS_CTRL				0x0884
+#define EARLY_WAKEUP_APM_DEST				0x0890
+#define EARLY_WAKEUP_CLUSTER0_DEST			0x0894
+#define EARLY_WAKEUP_DPU_DEST				0x0898
+#define EARLY_WAKEUP_CSIS_DEST				0x089c
+#define EARLY_WAKEUP_SW_TRIG_APM			0x08c0
+#define EARLY_WAKEUP_SW_TRIG_APM_SET			0x08c4
+#define EARLY_WAKEUP_SW_TRIG_APM_CLEAR			0x08c8
+#define EARLY_WAKEUP_SW_TRIG_CLUSTER0			0x08d0
+#define EARLY_WAKEUP_SW_TRIG_CLUSTER0_SET		0x08d4
+#define EARLY_WAKEUP_SW_TRIG_CLUSTER0_CLEAR		0x08d8
+#define EARLY_WAKEUP_SW_TRIG_DPU			0x08e0
+#define EARLY_WAKEUP_SW_TRIG_DPU_SET			0x08e4
+#define EARLY_WAKEUP_SW_TRIG_DPU_CLEAR			0x08e8
+#define EARLY_WAKEUP_SW_TRIG_CSIS			0x08f0
+#define EARLY_WAKEUP_SW_TRIG_CSIS_SET			0x08f4
+#define EARLY_WAKEUP_SW_TRIG_CSIS_CLEAR			0x08f8
+
+#define CLK_CON_MUX_MUX_CLKCMU_BO_BUS			0x1000
+#define CLK_CON_MUX_MUX_CLKCMU_BUS0_BUS			0x1004
+#define CLK_CON_MUX_MUX_CLKCMU_BUS1_BUS			0x1008
+#define CLK_CON_MUX_MUX_CLKCMU_BUS2_BUS			0x100c
+#define CLK_CON_MUX_MUX_CLKCMU_CIS_CLK0			0x1010
+#define CLK_CON_MUX_MUX_CLKCMU_CIS_CLK1			0x1014
+#define CLK_CON_MUX_MUX_CLKCMU_CIS_CLK2			0x1018
+#define CLK_CON_MUX_MUX_CLKCMU_CIS_CLK3			0x101c
+#define CLK_CON_MUX_MUX_CLKCMU_CIS_CLK4			0x1020
+#define CLK_CON_MUX_MUX_CLKCMU_CIS_CLK5			0x1024
+#define CLK_CON_MUX_MUX_CLKCMU_CIS_CLK6			0x1028
+#define CLK_CON_MUX_MUX_CLKCMU_CIS_CLK7			0x102c
+#define CLK_CON_MUX_MUX_CLKCMU_CMU_BOOST		0x1030
+#define CLK_CON_MUX_MUX_CLKCMU_CMU_BOOST_OPTION1	0x1034
+#define CLK_CON_MUX_MUX_CLKCMU_CORE_BUS			0x1038
+#define CLK_CON_MUX_MUX_CLKCMU_CPUCL0_DBG		0x103c
+#define CLK_CON_MUX_MUX_CLKCMU_CPUCL0_SWITCH		0x1040
+#define CLK_CON_MUX_MUX_CLKCMU_CPUCL1_SWITCH		0x1044
+#define CLK_CON_MUX_MUX_CLKCMU_CPUCL2_SWITCH		0x1048
+#define CLK_CON_MUX_MUX_CLKCMU_CSIS_BUS			0x104c
+#define CLK_CON_MUX_MUX_CLKCMU_DISP_BUS			0x1050
+#define CLK_CON_MUX_MUX_CLKCMU_DNS_BUS			0x1054
+#define CLK_CON_MUX_MUX_CLKCMU_DPU_BUS			0x1058
+#define CLK_CON_MUX_MUX_CLKCMU_EH_BUS			0x105c
+#define CLK_CON_MUX_MUX_CLKCMU_G2D_G2D			0x1060
+#define CLK_CON_MUX_MUX_CLKCMU_G2D_MSCL			0x1064
+#define CLK_CON_MUX_MUX_CLKCMU_G3AA_G3AA		0x1068
+#define CLK_CON_MUX_MUX_CLKCMU_G3D_BUSD			0x106c
+#define CLK_CON_MUX_MUX_CLKCMU_G3D_GLB			0x1070
+#define CLK_CON_MUX_MUX_CLKCMU_G3D_SWITCH		0x1074
+#define CLK_CON_MUX_MUX_CLKCMU_GDC_GDC0			0x1078
+#define CLK_CON_MUX_MUX_CLKCMU_GDC_GDC1			0x107c
+#define CLK_CON_MUX_MUX_CLKCMU_GDC_SCSC			0x1080
+#define CLK_CON_MUX_MUX_CLKCMU_HPM			0x1084
+#define CLK_CON_MUX_MUX_CLKCMU_HSI0_BUS			0x1088
+#define CLK_CON_MUX_MUX_CLKCMU_HSI0_DPGTC		0x108c
+#define CLK_CON_MUX_MUX_CLKCMU_HSI0_USB31DRD		0x1090
+#define CLK_CON_MUX_MUX_CLKCMU_HSI0_USBDPDBG		0x1094
+#define CLK_CON_MUX_MUX_CLKCMU_HSI1_BUS			0x1098
+#define CLK_CON_MUX_MUX_CLKCMU_HSI1_PCIE		0x109c
+#define CLK_CON_MUX_MUX_CLKCMU_HSI2_BUS			0x10a0
+#define CLK_CON_MUX_MUX_CLKCMU_HSI2_MMC_CARD		0x10a4
+#define CLK_CON_MUX_MUX_CLKCMU_HSI2_PCIE		0x10a8
+#define CLK_CON_MUX_MUX_CLKCMU_HSI2_UFS_EMBD		0x10ac
+#define CLK_CON_MUX_MUX_CLKCMU_IPP_BUS			0x10b0
+#define CLK_CON_MUX_MUX_CLKCMU_ITP_BUS			0x10b4
+#define CLK_CON_MUX_MUX_CLKCMU_MCSC_ITSC		0x10b8
+#define CLK_CON_MUX_MUX_CLKCMU_MCSC_MCSC		0x10bc
+#define CLK_CON_MUX_MUX_CLKCMU_MFC_MFC			0x10c0
+#define CLK_CON_MUX_MUX_CLKCMU_MIF_BUSP			0x10c4
+#define CLK_CON_MUX_MUX_CLKCMU_MIF_SWITCH		0x10c8
+#define CLK_CON_MUX_MUX_CLKCMU_MISC_BUS			0x10cc
+#define CLK_CON_MUX_MUX_CLKCMU_MISC_SSS			0x10d0
+#define CLK_CON_MUX_MUX_CLKCMU_PDP_BUS			0x10d4
+#define CLK_CON_MUX_MUX_CLKCMU_PDP_VRA			0x10d8
+#define CLK_CON_MUX_MUX_CLKCMU_PERIC0_BUS		0x10dc
+#define CLK_CON_MUX_MUX_CLKCMU_PERIC0_IP		0x10e0
+#define CLK_CON_MUX_MUX_CLKCMU_PERIC1_BUS		0x10e4
+#define CLK_CON_MUX_MUX_CLKCMU_PERIC1_IP		0x10e8
+#define CLK_CON_MUX_MUX_CLKCMU_TNR_BUS			0x10ec
+#define CLK_CON_MUX_MUX_CLKCMU_TOP_BOOST_OPTION1	0x10f0
+#define CLK_CON_MUX_MUX_CLKCMU_TOP_CMUREF		0x10f4
+#define CLK_CON_MUX_MUX_CLKCMU_TPU_BUS			0x10f8
+#define CLK_CON_MUX_MUX_CLKCMU_TPU_TPU			0x10fc
+#define CLK_CON_MUX_MUX_CLKCMU_TPU_TPUCTL		0x1100
+#define CLK_CON_MUX_MUX_CLKCMU_TPU_UART			0x1104
+#define CLK_CON_MUX_MUX_CMU_CMUREF			0x1108
+
+#define CLK_CON_DIV_CLKCMU_BO_BUS			0x1800
+#define CLK_CON_DIV_CLKCMU_BUS0_BUS			0x1804
+#define CLK_CON_DIV_CLKCMU_BUS1_BUS			0x1808
+#define CLK_CON_DIV_CLKCMU_BUS2_BUS			0x180c
+#define CLK_CON_DIV_CLKCMU_CIS_CLK0			0x1810
+#define CLK_CON_DIV_CLKCMU_CIS_CLK1			0x1814
+#define CLK_CON_DIV_CLKCMU_CIS_CLK2			0x1818
+#define CLK_CON_DIV_CLKCMU_CIS_CLK3			0x181c
+#define CLK_CON_DIV_CLKCMU_CIS_CLK4			0x1820
+#define CLK_CON_DIV_CLKCMU_CIS_CLK5			0x1824
+#define CLK_CON_DIV_CLKCMU_CIS_CLK6			0x1828
+#define CLK_CON_DIV_CLKCMU_CIS_CLK7			0x182c
+#define CLK_CON_DIV_CLKCMU_CORE_BUS			0x1830
+#define CLK_CON_DIV_CLKCMU_CPUCL0_DBG			0x1834
+#define CLK_CON_DIV_CLKCMU_CPUCL0_SWITCH		0x1838
+#define CLK_CON_DIV_CLKCMU_CPUCL1_SWITCH		0x183c
+#define CLK_CON_DIV_CLKCMU_CPUCL2_SWITCH		0x1840
+#define CLK_CON_DIV_CLKCMU_CSIS_BUS			0x1844
+#define CLK_CON_DIV_CLKCMU_DISP_BUS			0x1848
+#define CLK_CON_DIV_CLKCMU_DNS_BUS			0x184c
+#define CLK_CON_DIV_CLKCMU_DPU_BUS			0x1850
+#define CLK_CON_DIV_CLKCMU_EH_BUS			0x1854
+#define CLK_CON_DIV_CLKCMU_G2D_G2D			0x1858
+#define CLK_CON_DIV_CLKCMU_G2D_MSCL			0x185c
+#define CLK_CON_DIV_CLKCMU_G3AA_G3AA			0x1860
+#define CLK_CON_DIV_CLKCMU_G3D_BUSD			0x1864
+#define CLK_CON_DIV_CLKCMU_G3D_GLB			0x1868
+#define CLK_CON_DIV_CLKCMU_G3D_SWITCH			0x186c
+#define CLK_CON_DIV_CLKCMU_GDC_GDC0			0x1870
+#define CLK_CON_DIV_CLKCMU_GDC_GDC1			0x1874
+#define CLK_CON_DIV_CLKCMU_GDC_SCSC			0x1878
+#define CLK_CON_DIV_CLKCMU_HPM				0x187c
+#define CLK_CON_DIV_CLKCMU_HSI0_BUS			0x1880
+#define CLK_CON_DIV_CLKCMU_HSI0_DPGTC			0x1884
+#define CLK_CON_DIV_CLKCMU_HSI0_USB31DRD		0x1888
+#define CLK_CON_DIV_CLKCMU_HSI0_USBDPDBG		0x188c
+#define CLK_CON_DIV_CLKCMU_HSI1_BUS			0x1890
+#define CLK_CON_DIV_CLKCMU_HSI1_PCIE			0x1894
+#define CLK_CON_DIV_CLKCMU_HSI2_BUS			0x1898
+#define CLK_CON_DIV_CLKCMU_HSI2_MMC_CARD		0x189c
+#define CLK_CON_DIV_CLKCMU_HSI2_PCIE			0x18a0
+#define CLK_CON_DIV_CLKCMU_HSI2_UFS_EMBD		0x18a4
+#define CLK_CON_DIV_CLKCMU_IPP_BUS			0x18a8
+#define CLK_CON_DIV_CLKCMU_ITP_BUS			0x18ac
+#define CLK_CON_DIV_CLKCMU_MCSC_ITSC			0x18b0
+#define CLK_CON_DIV_CLKCMU_MCSC_MCSC			0x18b4
+#define CLK_CON_DIV_CLKCMU_MFC_MFC			0x18b8
+#define CLK_CON_DIV_CLKCMU_MIF_BUSP			0x18bc
+#define CLK_CON_DIV_CLKCMU_MISC_BUS			0x18c0
+#define CLK_CON_DIV_CLKCMU_MISC_SSS			0x18c4
+#define CLK_CON_DIV_CLKCMU_OTP				0x18c8
+#define CLK_CON_DIV_CLKCMU_PDP_BUS			0x18cc
+#define CLK_CON_DIV_CLKCMU_PDP_VRA			0x18d0
+#define CLK_CON_DIV_CLKCMU_PERIC0_BUS			0x18d4
+#define CLK_CON_DIV_CLKCMU_PERIC0_IP			0x18d8
+#define CLK_CON_DIV_CLKCMU_PERIC1_BUS			0x18dc
+#define CLK_CON_DIV_CLKCMU_PERIC1_IP			0x18e0
+#define CLK_CON_DIV_CLKCMU_TNR_BUS			0x18e4
+#define CLK_CON_DIV_CLKCMU_TPU_BUS			0x18e8
+#define CLK_CON_DIV_CLKCMU_TPU_TPU			0x18ec
+#define CLK_CON_DIV_CLKCMU_TPU_TPUCTL			0x18f0
+#define CLK_CON_DIV_CLKCMU_TPU_UART			0x18f4
+#define CLK_CON_DIV_DIV_CLKCMU_CMU_BOOST		0x18f8
+#define CLK_CON_DIV_DIV_CLK_CMU_CMUREF			0x18fc
+#define CLK_CON_DIV_PLL_SHARED0_DIV2			0x1900
+#define CLK_CON_DIV_PLL_SHARED0_DIV3			0x1904
+#define CLK_CON_DIV_PLL_SHARED0_DIV4			0x1908
+#define CLK_CON_DIV_PLL_SHARED0_DIV5			0x190c
+#define CLK_CON_DIV_PLL_SHARED1_DIV2			0x1910
+#define CLK_CON_DIV_PLL_SHARED1_DIV3			0x1914
+#define CLK_CON_DIV_PLL_SHARED1_DIV4			0x1918
+#define CLK_CON_DIV_PLL_SHARED2_DIV2			0x191c
+#define CLK_CON_DIV_PLL_SHARED3_DIV2			0x1920
+
+/* CLK_CON_GAT_UPDATES */
+#define CLK_CON_GAT_CLKCMU_BUS0_BOOST			0x2000
+#define CLK_CON_GAT_CLKCMU_BUS1_BOOST			0x2004
+#define CLK_CON_GAT_CLKCMU_BUS2_BOOST			0x2008
+#define CLK_CON_GAT_CLKCMU_CORE_BOOST			0x200c
+#define CLK_CON_GAT_CLKCMU_CPUCL0_BOOST			0x2010
+#define CLK_CON_GAT_CLKCMU_CPUCL1_BOOST			0x2014
+#define CLK_CON_GAT_CLKCMU_CPUCL2_BOOST			0x2018
+#define CLK_CON_GAT_CLKCMU_MIF_BOOST			0x201c
+#define CLK_CON_GAT_CLKCMU_MIF_SWITCH			0x2020
+#define CLK_CON_GAT_GATE_CLKCMU_BO_BUS			0x2024
+#define CLK_CON_GAT_GATE_CLKCMU_BUS0_BUS		0x2028
+#define CLK_CON_GAT_GATE_CLKCMU_BUS1_BUS		0x202c
+#define CLK_CON_GAT_GATE_CLKCMU_BUS2_BUS		0x2030
+#define CLK_CON_GAT_GATE_CLKCMU_CIS_CLK0		0x2034
+#define CLK_CON_GAT_GATE_CLKCMU_CIS_CLK1		0x2038
+#define CLK_CON_GAT_GATE_CLKCMU_CIS_CLK2		0x203c
+#define CLK_CON_GAT_GATE_CLKCMU_CIS_CLK3		0x2040
+#define CLK_CON_GAT_GATE_CLKCMU_CIS_CLK4		0x2044
+#define CLK_CON_GAT_GATE_CLKCMU_CIS_CLK5		0x2048
+#define CLK_CON_GAT_GATE_CLKCMU_CIS_CLK6		0x204c
+#define CLK_CON_GAT_GATE_CLKCMU_CIS_CLK7		0x2050
+#define CLK_CON_GAT_GATE_CLKCMU_CMU_BOOST		0x2054
+#define CLK_CON_GAT_GATE_CLKCMU_CORE_BUS		0x2058
+#define CLK_CON_GAT_GATE_CLKCMU_CPUCL0_DBG_BUS		0x205c
+#define CLK_CON_GAT_GATE_CLKCMU_CPUCL0_SWITCH		0x2060
+#define CLK_CON_GAT_GATE_CLKCMU_CPUCL1_SWITCH		0x2064
+#define CLK_CON_GAT_GATE_CLKCMU_CPUCL2_SWITCH		0x2068
+#define CLK_CON_GAT_GATE_CLKCMU_CSIS_BUS		0x206c
+#define CLK_CON_GAT_GATE_CLKCMU_DISP_BUS		0x2070
+#define CLK_CON_GAT_GATE_CLKCMU_DNS_BUS			0x2074
+#define CLK_CON_GAT_GATE_CLKCMU_DPU_BUS			0x2078
+#define CLK_CON_GAT_GATE_CLKCMU_EH_BUS			0x207c
+#define CLK_CON_GAT_GATE_CLKCMU_G2D_G2D			0x2080
+#define CLK_CON_GAT_GATE_CLKCMU_G2D_MSCL		0x2084
+#define CLK_CON_GAT_GATE_CLKCMU_G3AA_G3AA		0x2088
+#define CLK_CON_GAT_GATE_CLKCMU_G3D_BUSD		0x208c
+#define CLK_CON_GAT_GATE_CLKCMU_G3D_GLB			0x2090
+#define CLK_CON_GAT_GATE_CLKCMU_G3D_SWITCH		0x2094
+#define CLK_CON_GAT_GATE_CLKCMU_GDC_GDC0		0x2098
+#define CLK_CON_GAT_GATE_CLKCMU_GDC_GDC1		0x209c
+#define CLK_CON_GAT_GATE_CLKCMU_GDC_SCSC		0x20a0
+#define CLK_CON_GAT_GATE_CLKCMU_HPM			0x20a4
+#define CLK_CON_GAT_GATE_CLKCMU_HSI0_BUS		0x20a8
+#define CLK_CON_GAT_GATE_CLKCMU_HSI0_DPGTC		0x20ac
+#define CLK_CON_GAT_GATE_CLKCMU_HSI0_USB31DRD		0x20b0
+#define CLK_CON_GAT_GATE_CLKCMU_HSI0_USBDPDBG		0x20b4
+#define CLK_CON_GAT_GATE_CLKCMU_HSI1_BUS		0x20b8
+#define CLK_CON_GAT_GATE_CLKCMU_HSI1_PCIE		0x20bc
+#define CLK_CON_GAT_GATE_CLKCMU_HSI2_BUS		0x20c0
+#define CLK_CON_GAT_GATE_CLKCMU_HSI2_MMCCARD		0x20c4
+#define CLK_CON_GAT_GATE_CLKCMU_HSI2_PCIE		0x20c8
+#define CLK_CON_GAT_GATE_CLKCMU_HSI2_UFS_EMBD		0x20cc
+#define CLK_CON_GAT_GATE_CLKCMU_IPP_BUS			0x20d0
+#define CLK_CON_GAT_GATE_CLKCMU_ITP_BUS			0x20d4
+#define CLK_CON_GAT_GATE_CLKCMU_MCSC_ITSC		0x20d8
+#define CLK_CON_GAT_GATE_CLKCMU_MCSC_MCSC		0x20dc
+#define CLK_CON_GAT_GATE_CLKCMU_MFC_MFC			0x20e0
+#define CLK_CON_GAT_GATE_CLKCMU_MIF_BUSP		0x20e4
+#define CLK_CON_GAT_GATE_CLKCMU_MISC_BUS		0x20e8
+#define CLK_CON_GAT_GATE_CLKCMU_MISC_SSS		0x20ec
+#define CLK_CON_GAT_GATE_CLKCMU_PDP_BUS			0x20f0
+#define CLK_CON_GAT_GATE_CLKCMU_PDP_VRA			0x20f4
+#define CLK_CON_GAT_GATE_CLKCMU_PERIC0_BUS		0x20f8
+#define CLK_CON_GAT_GATE_CLKCMU_PERIC0_IP		0x20fc
+#define CLK_CON_GAT_GATE_CLKCMU_PERIC1_BUS		0x2100
+#define CLK_CON_GAT_GATE_CLKCMU_PERIC1_IP		0x2104
+#define CLK_CON_GAT_GATE_CLKCMU_TNR_BUS			0x2108
+#define CLK_CON_GAT_GATE_CLKCMU_TOP_CMUREF		0x210c
+#define CLK_CON_GAT_GATE_CLKCMU_TPU_BUS			0x2110
+#define CLK_CON_GAT_GATE_CLKCMU_TPU_TPU			0x2114
+#define CLK_CON_GAT_GATE_CLKCMU_TPU_TPUCTL		0x2118
+#define CLK_CON_GAT_GATE_CLKCMU_TPU_UART		0x211c
+
+#define DMYQCH_CON_CMU_TOP_CMUREF_QCH			0x3000
+#define DMYQCH_CON_DFTMUX_CMU_QCH_CIS_CLK0		0x3004
+#define DMYQCH_CON_DFTMUX_CMU_QCH_CIS_CLK1		0x3008
+#define DMYQCH_CON_DFTMUX_CMU_QCH_CIS_CLK2		0x300c
+#define DMYQCH_CON_DFTMUX_CMU_QCH_CIS_CLK3		0x3010
+#define DMYQCH_CON_DFTMUX_CMU_QCH_CIS_CLK4		0x3014
+#define DMYQCH_CON_DFTMUX_CMU_QCH_CIS_CLK5		0x3018
+#define DMYQCH_CON_DFTMUX_CMU_QCH_CIS_CLK6		0x301c
+#define DMYQCH_CON_DFTMUX_CMU_QCH_CIS_CLK7		0x3020
+#define DMYQCH_CON_OTP_QCH				0x3024
+#define QUEUE_CTRL_REG_BLK_CMU_CMU_TOP			0x3c00
+#define QUEUE_ENTRY0_BLK_CMU_CMU_TOP			0x3c10
+#define QUEUE_ENTRY1_BLK_CMU_CMU_TOP			0x3c14
+#define QUEUE_ENTRY2_BLK_CMU_CMU_TOP			0x3c18
+#define QUEUE_ENTRY3_BLK_CMU_CMU_TOP			0x3c1c
+#define QUEUE_ENTRY4_BLK_CMU_CMU_TOP			0x3c20
+#define QUEUE_ENTRY5_BLK_CMU_CMU_TOP			0x3c24
+#define QUEUE_ENTRY6_BLK_CMU_CMU_TOP			0x3c28
+#define QUEUE_ENTRY7_BLK_CMU_CMU_TOP			0x3c2c
+#define MIFMIRROR_QUEUE_CTRL_REG			0x3e00
+#define MIFMIRROR_QUEUE_ENTRY0				0x3e10
+#define MIFMIRROR_QUEUE_ENTRY1				0x3e14
+#define MIFMIRROR_QUEUE_ENTRY2				0x3e18
+#define MIFMIRROR_QUEUE_ENTRY3				0x3e1c
+#define MIFMIRROR_QUEUE_ENTRY4				0x3e20
+#define MIFMIRROR_QUEUE_ENTRY5				0x3e24
+#define MIFMIRROR_QUEUE_ENTRY6				0x3e28
+#define MIFMIRROR_QUEUE_ENTRY7				0x3e2c
+#define MIFMIRROR_QUEUE_BUSY				0x3e30
+#define GENERALIO_ACD_CHANNEL_0				0x3f00
+#define GENERALIO_ACD_CHANNEL_1				0x3f04
+#define GENERALIO_ACD_CHANNEL_2				0x3f08
+#define GENERALIO_ACD_CHANNEL_3				0x3f0c
+#define GENERALIO_ACD_MASK				0x3f14
+
+static const unsigned long cmu_top_clk_regs[] __initconst = {
+	PLL_LOCKTIME_PLL_SHARED0,
+	PLL_LOCKTIME_PLL_SHARED1,
+	PLL_LOCKTIME_PLL_SHARED2,
+	PLL_LOCKTIME_PLL_SHARED3,
+	PLL_LOCKTIME_PLL_SPARE,
+	PLL_CON0_PLL_SHARED0,
+	PLL_CON1_PLL_SHARED0,
+	PLL_CON2_PLL_SHARED0,
+	PLL_CON3_PLL_SHARED0,
+	PLL_CON4_PLL_SHARED0,
+	PLL_CON0_PLL_SHARED1,
+	PLL_CON1_PLL_SHARED1,
+	PLL_CON2_PLL_SHARED1,
+	PLL_CON3_PLL_SHARED1,
+	PLL_CON4_PLL_SHARED1,
+	PLL_CON0_PLL_SHARED2,
+	PLL_CON1_PLL_SHARED2,
+	PLL_CON2_PLL_SHARED2,
+	PLL_CON3_PLL_SHARED2,
+	PLL_CON4_PLL_SHARED2,
+	PLL_CON0_PLL_SHARED3,
+	PLL_CON1_PLL_SHARED3,
+	PLL_CON2_PLL_SHARED3,
+	PLL_CON3_PLL_SHARED3,
+	PLL_CON4_PLL_SHARED3,
+	PLL_CON0_PLL_SPARE,
+	PLL_CON1_PLL_SPARE,
+	PLL_CON2_PLL_SPARE,
+	PLL_CON3_PLL_SPARE,
+	PLL_CON4_PLL_SPARE,
+	CMU_CMU_TOP_CONTROLLER_OPTION,
+	CLKOUT_CON_BLK_CMU_CMU_TOP_CLKOUT0,
+	CMU_HCHGEN_CLKMUX_CMU_BOOST,
+	CMU_HCHGEN_CLKMUX_TOP_BOOST,
+	CMU_HCHGEN_CLKMUX,
+	POWER_FAIL_DETECT_PLL,
+	EARLY_WAKEUP_FORCED_0_ENABLE,
+	EARLY_WAKEUP_FORCED_1_ENABLE,
+	EARLY_WAKEUP_APM_CTRL,
+	EARLY_WAKEUP_CLUSTER0_CTRL,
+	EARLY_WAKEUP_DPU_CTRL,
+	EARLY_WAKEUP_CSIS_CTRL,
+	EARLY_WAKEUP_APM_DEST,
+	EARLY_WAKEUP_CLUSTER0_DEST,
+	EARLY_WAKEUP_DPU_DEST,
+	EARLY_WAKEUP_CSIS_DEST,
+	EARLY_WAKEUP_SW_TRIG_APM,
+	EARLY_WAKEUP_SW_TRIG_APM_SET,
+	EARLY_WAKEUP_SW_TRIG_APM_CLEAR,
+	EARLY_WAKEUP_SW_TRIG_CLUSTER0,
+	EARLY_WAKEUP_SW_TRIG_CLUSTER0_SET,
+	EARLY_WAKEUP_SW_TRIG_CLUSTER0_CLEAR,
+	EARLY_WAKEUP_SW_TRIG_DPU,
+	EARLY_WAKEUP_SW_TRIG_DPU_SET,
+	EARLY_WAKEUP_SW_TRIG_DPU_CLEAR,
+	EARLY_WAKEUP_SW_TRIG_CSIS,
+	EARLY_WAKEUP_SW_TRIG_CSIS_SET,
+	EARLY_WAKEUP_SW_TRIG_CSIS_CLEAR,
+	CLK_CON_MUX_MUX_CLKCMU_BO_BUS,
+	CLK_CON_MUX_MUX_CLKCMU_BUS0_BUS,
+	CLK_CON_MUX_MUX_CLKCMU_BUS1_BUS,
+	CLK_CON_MUX_MUX_CLKCMU_BUS2_BUS,
+	CLK_CON_MUX_MUX_CLKCMU_CIS_CLK0,
+	CLK_CON_MUX_MUX_CLKCMU_CIS_CLK1,
+	CLK_CON_MUX_MUX_CLKCMU_CIS_CLK2,
+	CLK_CON_MUX_MUX_CLKCMU_CIS_CLK3,
+	CLK_CON_MUX_MUX_CLKCMU_CIS_CLK4,
+	CLK_CON_MUX_MUX_CLKCMU_CIS_CLK5,
+	CLK_CON_MUX_MUX_CLKCMU_CIS_CLK6,
+	CLK_CON_MUX_MUX_CLKCMU_CIS_CLK7,
+	CLK_CON_MUX_MUX_CLKCMU_CMU_BOOST,
+	CLK_CON_MUX_MUX_CLKCMU_CMU_BOOST_OPTION1,
+	CLK_CON_MUX_MUX_CLKCMU_CORE_BUS,
+	CLK_CON_MUX_MUX_CLKCMU_CPUCL0_DBG,
+	CLK_CON_MUX_MUX_CLKCMU_CPUCL0_SWITCH,
+	CLK_CON_MUX_MUX_CLKCMU_CPUCL1_SWITCH,
+	CLK_CON_MUX_MUX_CLKCMU_CPUCL2_SWITCH,
+	CLK_CON_MUX_MUX_CLKCMU_CSIS_BUS,
+	CLK_CON_MUX_MUX_CLKCMU_DISP_BUS,
+	CLK_CON_MUX_MUX_CLKCMU_DNS_BUS,
+	CLK_CON_MUX_MUX_CLKCMU_DPU_BUS,
+	CLK_CON_MUX_MUX_CLKCMU_EH_BUS,
+	CLK_CON_MUX_MUX_CLKCMU_G2D_G2D,
+	CLK_CON_MUX_MUX_CLKCMU_G2D_MSCL,
+	CLK_CON_MUX_MUX_CLKCMU_G3AA_G3AA,
+	CLK_CON_MUX_MUX_CLKCMU_G3D_BUSD,
+	CLK_CON_MUX_MUX_CLKCMU_G3D_GLB,
+	CLK_CON_MUX_MUX_CLKCMU_G3D_SWITCH,
+	CLK_CON_MUX_MUX_CLKCMU_GDC_GDC0,
+	CLK_CON_MUX_MUX_CLKCMU_GDC_GDC1,
+	CLK_CON_MUX_MUX_CLKCMU_GDC_SCSC,
+	CLK_CON_MUX_MUX_CLKCMU_HPM,
+	CLK_CON_MUX_MUX_CLKCMU_HSI0_BUS,
+	CLK_CON_MUX_MUX_CLKCMU_HSI0_DPGTC,
+	CLK_CON_MUX_MUX_CLKCMU_HSI0_USB31DRD,
+	CLK_CON_MUX_MUX_CLKCMU_HSI0_USBDPDBG,
+	CLK_CON_MUX_MUX_CLKCMU_HSI1_BUS,
+	CLK_CON_MUX_MUX_CLKCMU_HSI1_PCIE,
+	CLK_CON_MUX_MUX_CLKCMU_HSI2_BUS,
+	CLK_CON_MUX_MUX_CLKCMU_HSI2_MMC_CARD,
+	CLK_CON_MUX_MUX_CLKCMU_HSI2_PCIE,
+	CLK_CON_MUX_MUX_CLKCMU_HSI2_UFS_EMBD,
+	CLK_CON_MUX_MUX_CLKCMU_IPP_BUS,
+	CLK_CON_MUX_MUX_CLKCMU_ITP_BUS,
+	CLK_CON_MUX_MUX_CLKCMU_MCSC_ITSC,
+	CLK_CON_MUX_MUX_CLKCMU_MCSC_MCSC,
+	CLK_CON_MUX_MUX_CLKCMU_MFC_MFC,
+	CLK_CON_MUX_MUX_CLKCMU_MIF_BUSP,
+	CLK_CON_MUX_MUX_CLKCMU_MIF_SWITCH,
+	CLK_CON_MUX_MUX_CLKCMU_MISC_BUS,
+	CLK_CON_MUX_MUX_CLKCMU_MISC_SSS,
+	CLK_CON_MUX_MUX_CLKCMU_PDP_BUS,
+	CLK_CON_MUX_MUX_CLKCMU_PDP_VRA,
+	CLK_CON_MUX_MUX_CLKCMU_PERIC0_BUS,
+	CLK_CON_MUX_MUX_CLKCMU_PERIC0_IP,
+	CLK_CON_MUX_MUX_CLKCMU_PERIC1_BUS,
+	CLK_CON_MUX_MUX_CLKCMU_PERIC1_IP,
+	CLK_CON_MUX_MUX_CLKCMU_TNR_BUS,
+	CLK_CON_MUX_MUX_CLKCMU_TOP_BOOST_OPTION1,
+	CLK_CON_MUX_MUX_CLKCMU_TOP_CMUREF,
+	CLK_CON_MUX_MUX_CLKCMU_TPU_BUS,
+	CLK_CON_MUX_MUX_CLKCMU_TPU_TPU,
+	CLK_CON_MUX_MUX_CLKCMU_TPU_TPUCTL,
+	CLK_CON_MUX_MUX_CLKCMU_TPU_UART,
+	CLK_CON_MUX_MUX_CMU_CMUREF,
+	CLK_CON_DIV_CLKCMU_BO_BUS,
+	CLK_CON_DIV_CLKCMU_BUS0_BUS,
+	CLK_CON_DIV_CLKCMU_BUS1_BUS,
+	CLK_CON_DIV_CLKCMU_BUS2_BUS,
+	CLK_CON_DIV_CLKCMU_CIS_CLK0,
+	CLK_CON_DIV_CLKCMU_CIS_CLK1,
+	CLK_CON_DIV_CLKCMU_CIS_CLK2,
+	CLK_CON_DIV_CLKCMU_CIS_CLK3,
+	CLK_CON_DIV_CLKCMU_CIS_CLK4,
+	CLK_CON_DIV_CLKCMU_CIS_CLK5,
+	CLK_CON_DIV_CLKCMU_CIS_CLK6,
+	CLK_CON_DIV_CLKCMU_CIS_CLK7,
+	CLK_CON_DIV_CLKCMU_CORE_BUS,
+	CLK_CON_DIV_CLKCMU_CPUCL0_DBG,
+	CLK_CON_DIV_CLKCMU_CPUCL0_SWITCH,
+	CLK_CON_DIV_CLKCMU_CPUCL1_SWITCH,
+	CLK_CON_DIV_CLKCMU_CPUCL2_SWITCH,
+	CLK_CON_DIV_CLKCMU_CSIS_BUS,
+	CLK_CON_DIV_CLKCMU_DISP_BUS,
+	CLK_CON_DIV_CLKCMU_DNS_BUS,
+	CLK_CON_DIV_CLKCMU_DPU_BUS,
+	CLK_CON_DIV_CLKCMU_EH_BUS,
+	CLK_CON_DIV_CLKCMU_G2D_G2D,
+	CLK_CON_DIV_CLKCMU_G2D_MSCL,
+	CLK_CON_DIV_CLKCMU_G3AA_G3AA,
+	CLK_CON_DIV_CLKCMU_G3D_BUSD,
+	CLK_CON_DIV_CLKCMU_G3D_GLB,
+	CLK_CON_DIV_CLKCMU_G3D_SWITCH,
+	CLK_CON_DIV_CLKCMU_GDC_GDC0,
+	CLK_CON_DIV_CLKCMU_GDC_GDC1,
+	CLK_CON_DIV_CLKCMU_GDC_SCSC,
+	CLK_CON_DIV_CLKCMU_HPM,
+	CLK_CON_DIV_CLKCMU_HSI0_BUS,
+	CLK_CON_DIV_CLKCMU_HSI0_DPGTC,
+	CLK_CON_DIV_CLKCMU_HSI0_USB31DRD,
+	CLK_CON_DIV_CLKCMU_HSI0_USBDPDBG,
+	CLK_CON_DIV_CLKCMU_HSI1_BUS,
+	CLK_CON_DIV_CLKCMU_HSI1_PCIE,
+	CLK_CON_DIV_CLKCMU_HSI2_BUS,
+	CLK_CON_DIV_CLKCMU_HSI2_MMC_CARD,
+	CLK_CON_DIV_CLKCMU_HSI2_PCIE,
+	CLK_CON_DIV_CLKCMU_HSI2_UFS_EMBD,
+	CLK_CON_DIV_CLKCMU_IPP_BUS,
+	CLK_CON_DIV_CLKCMU_ITP_BUS,
+	CLK_CON_DIV_CLKCMU_MCSC_ITSC,
+	CLK_CON_DIV_CLKCMU_MCSC_MCSC,
+	CLK_CON_DIV_CLKCMU_MFC_MFC,
+	CLK_CON_DIV_CLKCMU_MIF_BUSP,
+	CLK_CON_DIV_CLKCMU_MISC_BUS,
+	CLK_CON_DIV_CLKCMU_MISC_SSS,
+	CLK_CON_DIV_CLKCMU_OTP,
+	CLK_CON_DIV_CLKCMU_PDP_BUS,
+	CLK_CON_DIV_CLKCMU_PDP_VRA,
+	CLK_CON_DIV_CLKCMU_PERIC0_BUS,
+	CLK_CON_DIV_CLKCMU_PERIC0_IP,
+	CLK_CON_DIV_CLKCMU_PERIC1_BUS,
+	CLK_CON_DIV_CLKCMU_PERIC1_IP,
+	CLK_CON_DIV_CLKCMU_TNR_BUS,
+	CLK_CON_DIV_CLKCMU_TPU_BUS,
+	CLK_CON_DIV_CLKCMU_TPU_TPU,
+	CLK_CON_DIV_CLKCMU_TPU_TPUCTL,
+	CLK_CON_DIV_CLKCMU_TPU_UART,
+	CLK_CON_DIV_DIV_CLKCMU_CMU_BOOST,
+	CLK_CON_DIV_DIV_CLK_CMU_CMUREF,
+	CLK_CON_DIV_PLL_SHARED0_DIV2,
+	CLK_CON_DIV_PLL_SHARED0_DIV3,
+	CLK_CON_DIV_PLL_SHARED0_DIV4,
+	CLK_CON_DIV_PLL_SHARED0_DIV5,
+	CLK_CON_DIV_PLL_SHARED1_DIV2,
+	CLK_CON_DIV_PLL_SHARED1_DIV3,
+	CLK_CON_DIV_PLL_SHARED1_DIV4,
+	CLK_CON_DIV_PLL_SHARED2_DIV2,
+	CLK_CON_DIV_PLL_SHARED3_DIV2,
+	CLK_CON_GAT_CLKCMU_BUS0_BOOST,
+	CLK_CON_GAT_CLKCMU_BUS1_BOOST,
+	CLK_CON_GAT_CLKCMU_BUS2_BOOST,
+	CLK_CON_GAT_CLKCMU_CORE_BOOST,
+	CLK_CON_GAT_CLKCMU_CPUCL0_BOOST,
+	CLK_CON_GAT_CLKCMU_CPUCL1_BOOST,
+	CLK_CON_GAT_CLKCMU_CPUCL2_BOOST,
+	CLK_CON_GAT_CLKCMU_MIF_BOOST,
+	CLK_CON_GAT_CLKCMU_MIF_SWITCH,
+	CLK_CON_GAT_GATE_CLKCMU_BO_BUS,
+	CLK_CON_GAT_GATE_CLKCMU_BUS0_BUS,
+	CLK_CON_GAT_GATE_CLKCMU_BUS1_BUS,
+	CLK_CON_GAT_GATE_CLKCMU_BUS2_BUS,
+	CLK_CON_GAT_GATE_CLKCMU_CIS_CLK0,
+	CLK_CON_GAT_GATE_CLKCMU_CIS_CLK1,
+	CLK_CON_GAT_GATE_CLKCMU_CIS_CLK2,
+	CLK_CON_GAT_GATE_CLKCMU_CIS_CLK3,
+	CLK_CON_GAT_GATE_CLKCMU_CIS_CLK4,
+	CLK_CON_GAT_GATE_CLKCMU_CIS_CLK5,
+	CLK_CON_GAT_GATE_CLKCMU_CIS_CLK6,
+	CLK_CON_GAT_GATE_CLKCMU_CIS_CLK7,
+	CLK_CON_GAT_GATE_CLKCMU_CMU_BOOST,
+	CLK_CON_GAT_GATE_CLKCMU_CORE_BUS,
+	CLK_CON_GAT_GATE_CLKCMU_CPUCL0_DBG_BUS,
+	CLK_CON_GAT_GATE_CLKCMU_CPUCL0_SWITCH,
+	CLK_CON_GAT_GATE_CLKCMU_CPUCL1_SWITCH,
+	CLK_CON_GAT_GATE_CLKCMU_CPUCL2_SWITCH,
+	CLK_CON_GAT_GATE_CLKCMU_CSIS_BUS,
+	CLK_CON_GAT_GATE_CLKCMU_DISP_BUS,
+	CLK_CON_GAT_GATE_CLKCMU_DNS_BUS,
+	CLK_CON_GAT_GATE_CLKCMU_DPU_BUS,
+	CLK_CON_GAT_GATE_CLKCMU_EH_BUS,
+	CLK_CON_GAT_GATE_CLKCMU_G2D_G2D,
+	CLK_CON_GAT_GATE_CLKCMU_G2D_MSCL,
+	CLK_CON_GAT_GATE_CLKCMU_G3AA_G3AA,
+	CLK_CON_GAT_GATE_CLKCMU_G3D_BUSD,
+	CLK_CON_GAT_GATE_CLKCMU_G3D_GLB,
+	CLK_CON_GAT_GATE_CLKCMU_G3D_SWITCH,
+	CLK_CON_GAT_GATE_CLKCMU_GDC_GDC0,
+	CLK_CON_GAT_GATE_CLKCMU_GDC_GDC1,
+	CLK_CON_GAT_GATE_CLKCMU_GDC_SCSC,
+	CLK_CON_GAT_GATE_CLKCMU_HPM,
+	CLK_CON_GAT_GATE_CLKCMU_HSI0_BUS,
+	CLK_CON_GAT_GATE_CLKCMU_HSI0_DPGTC,
+	CLK_CON_GAT_GATE_CLKCMU_HSI0_USB31DRD,
+	CLK_CON_GAT_GATE_CLKCMU_HSI0_USBDPDBG,
+	CLK_CON_GAT_GATE_CLKCMU_HSI1_BUS,
+	CLK_CON_GAT_GATE_CLKCMU_HSI1_PCIE,
+	CLK_CON_GAT_GATE_CLKCMU_HSI2_BUS,
+	CLK_CON_GAT_GATE_CLKCMU_HSI2_MMCCARD,
+	CLK_CON_GAT_GATE_CLKCMU_HSI2_PCIE,
+	CLK_CON_GAT_GATE_CLKCMU_HSI2_UFS_EMBD,
+	CLK_CON_GAT_GATE_CLKCMU_IPP_BUS,
+	CLK_CON_GAT_GATE_CLKCMU_ITP_BUS,
+	CLK_CON_GAT_GATE_CLKCMU_MCSC_ITSC,
+	CLK_CON_GAT_GATE_CLKCMU_MCSC_MCSC,
+	CLK_CON_GAT_GATE_CLKCMU_MFC_MFC,
+	CLK_CON_GAT_GATE_CLKCMU_MIF_BUSP,
+	CLK_CON_GAT_GATE_CLKCMU_MISC_BUS,
+	CLK_CON_GAT_GATE_CLKCMU_MISC_SSS,
+	CLK_CON_GAT_GATE_CLKCMU_PDP_BUS,
+	CLK_CON_GAT_GATE_CLKCMU_PDP_VRA,
+	CLK_CON_GAT_GATE_CLKCMU_PERIC0_BUS,
+	CLK_CON_GAT_GATE_CLKCMU_PERIC0_IP,
+	CLK_CON_GAT_GATE_CLKCMU_PERIC1_BUS,
+	CLK_CON_GAT_GATE_CLKCMU_PERIC1_IP,
+	CLK_CON_GAT_GATE_CLKCMU_TNR_BUS,
+	CLK_CON_GAT_GATE_CLKCMU_TOP_CMUREF,
+	CLK_CON_GAT_GATE_CLKCMU_TPU_BUS,
+	CLK_CON_GAT_GATE_CLKCMU_TPU_TPU,
+	CLK_CON_GAT_GATE_CLKCMU_TPU_TPUCTL,
+	CLK_CON_GAT_GATE_CLKCMU_TPU_UART,
+	DMYQCH_CON_CMU_TOP_CMUREF_QCH,
+	DMYQCH_CON_DFTMUX_CMU_QCH_CIS_CLK0,
+	DMYQCH_CON_DFTMUX_CMU_QCH_CIS_CLK1,
+	DMYQCH_CON_DFTMUX_CMU_QCH_CIS_CLK2,
+	DMYQCH_CON_DFTMUX_CMU_QCH_CIS_CLK3,
+	DMYQCH_CON_DFTMUX_CMU_QCH_CIS_CLK4,
+	DMYQCH_CON_DFTMUX_CMU_QCH_CIS_CLK5,
+	DMYQCH_CON_DFTMUX_CMU_QCH_CIS_CLK6,
+	DMYQCH_CON_DFTMUX_CMU_QCH_CIS_CLK7,
+	DMYQCH_CON_OTP_QCH,
+	QUEUE_CTRL_REG_BLK_CMU_CMU_TOP,
+	QUEUE_ENTRY0_BLK_CMU_CMU_TOP,
+	QUEUE_ENTRY1_BLK_CMU_CMU_TOP,
+	QUEUE_ENTRY2_BLK_CMU_CMU_TOP,
+	QUEUE_ENTRY3_BLK_CMU_CMU_TOP,
+	QUEUE_ENTRY4_BLK_CMU_CMU_TOP,
+	QUEUE_ENTRY5_BLK_CMU_CMU_TOP,
+	QUEUE_ENTRY6_BLK_CMU_CMU_TOP,
+	QUEUE_ENTRY7_BLK_CMU_CMU_TOP,
+	MIFMIRROR_QUEUE_CTRL_REG,
+	MIFMIRROR_QUEUE_ENTRY0,
+	MIFMIRROR_QUEUE_ENTRY1,
+	MIFMIRROR_QUEUE_ENTRY2,
+	MIFMIRROR_QUEUE_ENTRY3,
+	MIFMIRROR_QUEUE_ENTRY4,
+	MIFMIRROR_QUEUE_ENTRY5,
+	MIFMIRROR_QUEUE_ENTRY6,
+	MIFMIRROR_QUEUE_ENTRY7,
+	MIFMIRROR_QUEUE_BUSY,
+	GENERALIO_ACD_CHANNEL_0,
+	GENERALIO_ACD_CHANNEL_1,
+	GENERALIO_ACD_CHANNEL_2,
+	GENERALIO_ACD_CHANNEL_3,
+	GENERALIO_ACD_MASK,
+};
+
+static const struct samsung_pll_clock cmu_top_pll_clks[] __initconst = {
+	/* CMU_TOP_PURECLKCOMP */
+	PLL(pll_0517x, CLK_FOUT_SHARED0_PLL, "fout_shared0_pll", "oscclk",
+	    PLL_LOCKTIME_PLL_SHARED0, PLL_CON3_PLL_SHARED0,
+	    NULL),
+	PLL(pll_0517x, CLK_FOUT_SHARED1_PLL, "fout_shared1_pll", "oscclk",
+	    PLL_LOCKTIME_PLL_SHARED1, PLL_CON3_PLL_SHARED1,
+	    NULL),
+	PLL(pll_0518x, CLK_FOUT_SHARED2_PLL, "fout_shared2_pll", "oscclk",
+	    PLL_LOCKTIME_PLL_SHARED2, PLL_CON3_PLL_SHARED2,
+	    NULL),
+	PLL(pll_0518x, CLK_FOUT_SHARED3_PLL, "fout_shared3_pll", "oscclk",
+	    PLL_LOCKTIME_PLL_SHARED3, PLL_CON3_PLL_SHARED3,
+	    NULL),
+	PLL(pll_0518x, CLK_FOUT_SPARE_PLL, "fout_spare_pll", "oscclk",
+	    PLL_LOCKTIME_PLL_SPARE, PLL_CON3_PLL_SPARE,
+	    NULL),
+};
+
+/* List of parent clocks for Muxes in CMU_TOP */
+PNAME(mout_shared0_pll_p)	= { "oscclk", "fout_shared0_pll" };
+PNAME(mout_shared1_pll_p)	= { "oscclk", "fout_shared1_pll" };
+PNAME(mout_shared2_pll_p)	= { "oscclk", "fout_shared2_pll" };
+PNAME(mout_shared3_pll_p)	= { "oscclk", "fout_shared3_pll" };
+PNAME(mout_spare_pll_p)		= { "oscclk", "fout_spare_pll" };
+
+/* List of parent clocks for Muxes in CMU_TOP: for CMU_BUS0 */
+PNAME(mout_cmu_bus0_bus_p)	= { "dout_shared0_div4", "dout_shared1_div4",
+				    "dout_shared2_div2", "dout_shared3_div2",
+				    "fout_spare_pll" };
+
+PNAME(mout_cmu_cmu_boost_p)	= { "dout_shared0_div4", "dout_shared1_div4",
+				    "dout_shared2_div2", "dout_shared3_div2" };
+
+/* List of parent clocks for Muxes in CMU_TOP: for CMU_BUS1 */
+PNAME(mout_cmu_bus1_bus_p)	= { "dout_shared0_div3", "fout_shared3_pll",
+				    "dout_shared1_div3", "dout_shared0_div4",
+				    "dout_shared1_div4", "dout_shared2_div2",
+				    "fout_spare_pll" };
+
+/* List of parent clocks for Muxes in CMU_TOP: for CMU_BUS2 */
+PNAME(mout_cmu_bus2_bus_p)	= { "dout_shared0_div2", "dout_shared1_div2",
+				    "fout_shared2_pll", "fout_shared3_pll",
+				    "dout_shared0_div3", "dout_shared1_div3",
+				    "dout_shared0_div5", "fout_spare_pll" };
+
+/* List of parent clocks for Muxes in CMU_TOP: for CMU_CORE */
+PNAME(mout_cmu_core_bus_p)	= { "dout_shared0_div2", "dout_shared1_div2",
+				    "fout_shared2_pll", "fout_shared3_pll",
+				    "dout_shared0_div3", "dout_shared1_div3",
+				    "dout_shared0_div5", "fout_spare_pll" };
+
+/* List of parent clocks for Muxes in CMU_TOP: for CMU_EH */
+PNAME(mout_cmu_eh_bus_p)	= { "dout_shared0_div2", "dout_shared1_div2",
+				    "fout_shared2_pll", "fout_shared3_pll",
+				    "dout_shared0_div3", "dout_shared1_div3",
+				    "dout_shared0_div5", "fout_spare_pll" };
+
+/* List of parent clocks for Muxes in CMU_TOP: for CMU_CPUCL2 */
+PNAME(mout_cmu_cpucl2_switch_p)	= { "fout_shared1_pll", "dout_shared0_div2",
+				    "dout_shared1_div2", "fout_shared2_pll",
+				    "fout_shared3_pll", "dout_shared0_div3",
+				    "dout_shared1_div3", "fout_spare_pll" };
+
+/* List of parent clocks for Muxes in CMU_TOP: for CMU_CPUCL1 */
+PNAME(mout_cmu_cpucl1_switch_p)	= { "fout_shared1_pll", "dout_shared0_div2",
+				    "dout_shared1_div2", "fout_shared2_pll",
+				    "fout_shared3_pll", "dout_shared0_div3",
+				    "dout_shared1_div3", "fout_spare_pll" };
+
+/* List of parent clocks for Muxes in CMU_TOP: for CMU_CPUCL0 */
+PNAME(mout_cmu_cpucl0_switch_p)	= { "fout_shared1_pll", "dout_shared0_div2",
+				    "dout_shared1_div2", "fout_shared2_pll",
+				    "fout_shared3_pll", "dout_shared0_div3",
+				    "dout_shared1_div3", "fout_spare_pll" };
+
+PNAME(mout_cmu_cpucl0_dbg_p)	= { "fout_shared2_pll", "fout_shared3_pll",
+				    "dout_shared0_div4", "dout_shared1_div4",
+				    "dout_shared2_div2", "fout_spare_pll" };
+
+PNAME(mout_cmu_hpm_p)		= { "oscclk", "dout_shared1_div3",
+				    "dout_shared0_div4", "dout_shared2_div2" };
+
+/* List of parent clocks for Muxes in CMU_TOP: for CMU_G3D */
+PNAME(mout_cmu_g3d_switch_p)	= { "fout_shared2_pll", "dout_shared0_div3",
+				    "fout_shared3_pll", "dout_shared1_div3",
+				    "dout_shared0_div4", "dout_shared1_div4",
+				    "fout_spare_pll" };
+
+PNAME(mout_cmu_g3d_busd_p)	= { "dout_shared0_div2", "dout_shared1_div2",
+				    "fout_shared2_pll", "fout_shared3_pll",
+				    "dout_shared0_div3", "dout_shared1_div3",
+				    "dout_shared0_div4", "fout_spare_pll" };
+
+PNAME(mout_cmu_g3d_glb_p)	= { "dout_shared0_div2", "dout_shared1_div2",
+				    "fout_shared2_pll", "fout_shared3_pll",
+				    "dout_shared0_div3", "dout_shared1_div3",
+				    "dout_shared0_div4", "fout_spare_pll" };
+
+/* List of parent clocks for Muxes in CMU_TOP: for CMU_DPU */
+PNAME(mout_cmu_dpu_p)		= { "dout_shared0_div3", "fout_shared3_pll",
+				    "dout_shared1_div3", "dout_shared0_div4",
+				    "dout_shared1_div4", "dout_shared2_div2",
+				    "fout_spare_pll" };
+
+/* List of parent clocks for Muxes in CMU_TOP: for CMU_DISP */
+PNAME(mout_cmu_disp_bus_p)	= { "dout_shared0_div3", "fout_shared3_pll",
+				    "dout_shared1_div3", "dout_shared0_div4",
+				    "dout_shared1_div4", "dout_shared2_div2",
+				    "fout_spare_pll" };
+
+/* List of parent clocks for Muxes in CMU_TOP: for CMU_G2D */
+PNAME(mout_cmu_g2d_g2d_p)	= { "dout_shared0_div3", "fout_shared3_pll",
+				    "dout_shared1_div3", "dout_shared0_div4",
+				    "dout_shared1_div4", "dout_shared2_div2",
+				    "fout_spare_pll" };
+
+PNAME(mout_cmu_g2d_mscl_p)	= { "dout_shared0_div4", "dout_shared1_div4",
+				    "dout_shared2_div2", "dout_shared3_div2",
+				    "fout_spare_pll" };
+
+/* List of parent clocks for Muxes in CMU_TOP: for CMU_HSI0 */
+PNAME(mout_cmu_hsi0_usb31drd_p)	= { "oscclk", "dout_shared2_div2" };
+
+PNAME(mout_cmu_hsi0_bus_p)	= { "dout_shared0_div4", "dout_shared1_div4",
+				    "dout_shared2_div2", "dout_shared3_div2",
+				    "fout_spare_pll" };
+
+PNAME(mout_cmu_hsi0_dpgtc_p)	= { "oscclk", "dout_shared0_div4",
+				    "dout_shared2_div2", "fout_spare_pll" };
+
+PNAME(mout_cmu_hsi0_usbdpdbg_p)	= { "oscclk", "dout_shared2_div2" };
+
+/* List of parent clocks for Muxes in CMU_TOP: for CMU_HSI1 */
+PNAME(mout_cmu_hsi1_bus_p)	= { "dout_shared0_div4", "dout_shared1_div4",
+				    "dout_shared2_div2", "dout_shared3_div2",
+				    "fout_spare_pll" };
+
+PNAME(mout_cmu_hsi1_pcie_p)	= { "oscclk", "dout_shared2_div2" };
+
+/* List of parent clocks for Muxes in CMU_TOP: for CMU_HSI2 */
+PNAME(mout_cmu_hsi2_bus_p)	= { "dout_shared0_div4", "dout_shared1_div4",
+				    "dout_shared2_div2", "dout_shared3_div2",
+				    "fout_spare_pll" };
+
+PNAME(mout_cmu_hsi2_pcie0_p)	= { "oscclk", "dout_shared2_div2" };
+
+PNAME(mout_cmu_hsi2_ufs_embd_p)	= { "oscclk", "dout_shared0_div4",
+				    "dout_shared2_div2", "fout_spare_pll" };
+
+PNAME(mout_cmu_hsi2_mmc_card_p)	= { "fout_shared2_pll", "fout_shared3_pll",
+				    "dout_shared0_div4", "fout_spare_pll" };
+
+/* List of parent clocks for Muxes in CMU_TOP: for CMU_CSIS */
+PNAME(mout_cmu_csis_bus_p)	= { "dout_shared0_div3", "fout_shared3_pll",
+				    "dout_shared1_div3", "dout_shared0_div4",
+				    "dout_shared1_div4", "dout_shared2_div2",
+				    "fout_spare_pll" };
+
+/* List of parent clocks for Muxes in CMU_TOP: for CMU_PDP */
+PNAME(mout_cmu_pdp_bus_p)	= { "dout_shared0_div3", "fout_shared3_pll",
+				    "dout_shared1_div3", "dout_shared0_div4",
+				    "dout_shared1_div4", "dout_shared2_div2",
+				    "fout_spare_pll" };
+
+PNAME(mout_cmu_pdp_vra_p)	= { "fout_shared2_pll", "dout_shared0_div3",
+				    "fout_shared3_pll", "dout_shared1_div3",
+				    "dout_shared0_div4", "dout_shared1_div4",
+				    "fout_spare_pll" };
+
+/* List of parent clocks for Muxes in CMU_TOP: for CMU_IPP */
+PNAME(mout_cmu_ipp_bus_p)	= { "dout_shared0_div3", "fout_shared3_pll",
+				    "dout_shared1_div3", "dout_shared0_div4",
+				    "dout_shared1_div4", "dout_shared2_div2",
+				    "fout_spare_pll" };
+
+/* List of parent clocks for Muxes in CMU_TOP: for CMU_G3AA */
+PNAME(mout_cmu_g3aa_p)		= { "dout_shared0_div3", "fout_shared3_pll",
+				    "dout_shared1_div3", "dout_shared0_div4",
+				    "dout_shared1_div4", "dout_shared2_div2",
+				    "fout_spare_pll" };
+
+/* List of parent clocks for Muxes in CMU_TOP: for CMU_ITP */
+PNAME(mout_cmu_itp_bus_p)	= { "dout_shared0_div3", "fout_shared3_pll",
+				    "dout_shared1_div3", "dout_shared0_div4",
+				    "dout_shared1_div4", "dout_shared2_div2",
+				    "fout_spare_pll" };
+
+/* List of parent clocks for Muxes in CMU_TOP: for CMU_DNS */
+PNAME(mout_cmu_dns_bus_p)	= { "dout_shared0_div3", "fout_shared3_pll",
+				    "dout_shared1_div3", "dout_shared0_div4",
+				    "dout_shared1_div4", "dout_shared2_div2",
+				    "fout_spare_pll" };
+
+/* List of parent clocks for Muxes in CMU_TOP: for CMU_TNR */
+PNAME(mout_cmu_tnr_bus_p)	= { "dout_shared0_div3", "fout_shared3_pll",
+				    "dout_shared1_div3", "dout_shared0_div4",
+				    "dout_shared1_div4", "dout_shared2_div2",
+				    "fout_spare_pll" };
+
+/* List of parent clocks for Muxes in CMU_TOP: for CMU_MCSC */
+PNAME(mout_cmu_mcsc_itsc_p)	= { "dout_shared0_div3", "fout_shared3_pll",
+				    "dout_shared1_div3", "dout_shared0_div4",
+				    "dout_shared1_div4", "dout_shared2_div2",
+				    "fout_spare_pll" };
+
+PNAME(mout_cmu_mcsc_mcsc_p)	= { "dout_shared0_div3", "fout_shared3_pll",
+				    "dout_shared1_div3", "dout_shared0_div4",
+				    "dout_shared1_div4", "dout_shared2_div2",
+				    "fout_spare_pll" };
+
+/* List of parent clocks for Muxes in CMU_TOP: for CMU_GDC */
+PNAME(mout_cmu_gdc_scsc_p)	= { "dout_shared0_div3", "fout_shared3_pll",
+				    "dout_shared1_div3", "dout_shared0_div4",
+				    "dout_shared1_div4", "dout_shared2_div2",
+				    "fout_spare_pll" };
+
+PNAME(mout_cmu_gdc_gdc0_p)	= { "dout_shared0_div3", "fout_shared3_pll",
+				    "dout_shared1_div3", "dout_shared0_div4",
+				    "dout_shared1_div4", "dout_shared2_div2",
+				    "fout_spare_pll" };
+
+PNAME(mout_cmu_gdc_gdc1_p)	= { "dout_shared0_div3", "fout_shared3_pll",
+				    "dout_shared1_div3", "dout_shared0_div4",
+				    "dout_shared1_div4", "dout_shared2_div2",
+				    "fout_spare_pll" };
+
+/* List of parent clocks for Muxes in CMU_TOP: for CMU_MFC */
+PNAME(mout_cmu_mfc_mfc_p)	= { "dout_shared0_div3", "fout_shared3_pll",
+				    "dout_shared1_div3", "dout_shared0_div4",
+				    "dout_shared1_div4", "dout_shared2_div2",
+				    "fout_spare_pll" };
+
+/* List of parent clocks for Muxes in CMU_TOP: for DDRPHY0/1/2/3 */
+
+PNAME(mout_cmu_mif_switch_p)	= { "fout_shared0_pll", "fout_shared1_pll",
+				    "dout_shared0_div2", "dout_shared1_div2",
+				    "fout_shared2_pll", "dout_shared0_div3",
+				    "fout_shared3_pll", "fout_spare_pll" };
+
+/* List of parent clocks for Muxes in CMU_TOP: for CMU_MIF0/1/2/3 */
+PNAME(mout_cmu_mif_busp_p)	= { "dout_shared0_div4", "dout_shared1_div4",
+				    "dout_shared0_div5", "fout_spare_pll" };
+
+/* List of parent clocks for Muxes in CMU_TOP: for CMU_MISC */
+PNAME(mout_cmu_misc_bus_p)	= { "dout_shared0_div4", "dout_shared2_div2",
+				    "dout_shared3_div2", "fout_spare_pll" };
+PNAME(mout_cmu_misc_sss_p)	= { "dout_shared0_div4", "dout_shared2_div2",
+				    "dout_shared3_div2", "fout_spare_pll" };
+
+/* List of parent clocks for Muxes in CMU_TOP: for CMU_PERIC0 */
+PNAME(mout_cmu_peric0_bus_p)	= { "dout_shared0_div4", "dout_shared2_div2",
+				    "dout_shared3_div2", "fout_spare_pll" };
+PNAME(mout_cmu_peric0_ip_p)	= { "dout_shared0_div4", "dout_shared2_div2",
+				    "dout_shared3_div2", "fout_spare_pll" };
+
+/* List of parent clocks for Muxes in CMU_TOP: for CMU_PERIC1 */
+PNAME(mout_cmu_peric1_bus_p)	= { "dout_shared0_div4", "dout_shared2_div2",
+				    "dout_shared3_div2", "fout_spare_pll" };
+PNAME(mout_cmu_peric1_ip_p)	= { "dout_shared0_div4", "dout_shared2_div2",
+				    "dout_shared3_div2", "fout_spare_pll" };
+
+/* List of parent clocks for Muxes in CMU_TOP: for CMU_TPU */
+PNAME(mout_cmu_tpu_tpu_p)	= { "dout_shared0_div2", "dout_shared1_div2",
+				    "fout_shared2_pll", "fout_shared3_pll",
+				    "dout_shared0_div3", "dout_shared1_div3",
+				    "dout_shared0_div4", "fout_spare_pll" };
+
+PNAME(mout_cmu_tpu_tpuctl_p)	= { "dout_shared0_div2", "dout_shared1_div2",
+				    "fout_shared2_pll", "fout_shared3_pll",
+				    "dout_shared0_div3", "dout_shared1_div3",
+				    "dout_shared0_div4", "fout_spare_pll" };
+
+PNAME(mout_cmu_tpu_bus_p)	= { "dout_shared0_div2", "dout_shared1_div2",
+				    "fout_shared2_pll", "fout_shared3_pll",
+				    "dout_shared0_div3", "dout_shared1_div3",
+				    "dout_shared0_div4", "fout_spare_pll" };
+
+PNAME(mout_cmu_tpu_uart_p)	= { "dout_shared0_div4", "dout_shared2_div2",
+				    "dout_shared3_div2", "fout_spare_pll" };
+
+/* List of parent clocks for Muxes in CMU_TOP: for CMU_BO */
+PNAME(mout_cmu_bo_bus_p)	= { "fout_shared2_pll", "dout_shared0_div3",
+				    "fout_shared3_pll", "dout_shared1_div3",
+				    "dout_shared0_div4", "dout_shared1_div4",
+				    "fout_spare_pll" };
+
+/* gs101 */
+static const struct samsung_mux_clock cmu_top_mux_clks[] __initconst = {
+	/* CMU_TOP_PURECLKCOMP */
+	MUX(CLK_MOUT_SHARED0_PLL, "mout_shared0_pll", mout_shared0_pll_p,
+	    PLL_CON0_PLL_SHARED0, 4, 1),
+	MUX(CLK_MOUT_SHARED1_PLL, "mout_shared1_pll", mout_shared1_pll_p,
+	    PLL_CON0_PLL_SHARED1, 4, 1),
+	MUX(CLK_MOUT_SHARED2_PLL, "mout_shared2_pll", mout_shared2_pll_p,
+	    PLL_CON0_PLL_SHARED2, 4, 1),
+	MUX(CLK_MOUT_SHARED3_PLL, "mout_shared3_pll", mout_shared3_pll_p,
+	    PLL_CON0_PLL_SHARED3, 4, 1),
+	MUX(CLK_MOUT_SPARE_PLL, "mout_spare_pll", mout_spare_pll_p,
+	    PLL_CON0_PLL_SPARE, 4, 1),
+
+	/* BUS0 */
+	MUX(CLK_MOUT_BUS0_BUS, "mout_cmu_bus0_bus", mout_cmu_bus0_bus_p,
+	    CLK_CON_MUX_MUX_CLKCMU_BUS0_BUS, 0, 2),
+	MUX(CLK_MOUT_CMU_BOOST, "mout_cmu_boost", mout_cmu_cmu_boost_p,
+	    CLK_CON_MUX_MUX_CLKCMU_CMU_BOOST, 0, 2),
+
+	/* BUS1 */
+	MUX(CLK_MOUT_BUS1_BUS, "mout_cmu_bus1_bus", mout_cmu_bus1_bus_p,
+	    CLK_CON_MUX_MUX_CLKCMU_BUS1_BUS, 0, 2),
+
+	/* BUS2 */
+	MUX(CLK_MOUT_BUS2_BUS, "mout_cmu_bus2_bus", mout_cmu_bus2_bus_p,
+	    CLK_CON_MUX_MUX_CLKCMU_BUS2_BUS, 0, 2),
+
+	/* CORE */
+	MUX(CLK_MOUT_CORE_BUS, "mout_cmu_core_bus", mout_cmu_core_bus_p,
+	    CLK_CON_MUX_MUX_CLKCMU_CORE_BUS, 0, 2),
+
+	/* EH */
+	MUX(CLK_MOUT_EH_BUS, "mout_cmu_eh_bus", mout_cmu_eh_bus_p,
+	    CLK_CON_MUX_MUX_CLKCMU_CORE_BUS, 0, 2),
+
+	/* CPUCL{0,1,2,} */
+	MUX(CLK_MOUT_CPUCL2_SWITCH, "mout_cmu_cpucl2_switch", mout_cmu_cpucl2_switch_p,
+	    CLK_CON_MUX_MUX_CLKCMU_CPUCL2_SWITCH, 0, 2),
+
+	MUX(CLK_MOUT_CPUCL1_SWITCH, "mout_cmu_cpucl1_switch", mout_cmu_cpucl1_switch_p,
+	    CLK_CON_MUX_MUX_CLKCMU_CPUCL1_SWITCH, 0, 2),
+
+	MUX(CLK_MOUT_CPUCL0_SWITCH, "mout_cmu_cpucl0_switch", mout_cmu_cpucl0_switch_p,
+	    CLK_CON_MUX_MUX_CLKCMU_CPUCL0_SWITCH, 0, 2),
+
+	MUX(CLK_MOUT_CPUCL0_DBG, "mout_cmu_cpucl0_dbg", mout_cmu_cpucl0_dbg_p,
+	    CLK_CON_DIV_CLKCMU_CPUCL0_DBG, 0, 2),
+
+	MUX(CLK_MOUT_CMU_HPM, "mout_cmu_hpm", mout_cmu_hpm_p,
+	    CLK_CON_MUX_MUX_CLKCMU_HPM, 0, 2),
+
+	/* G3D */
+	MUX(CLK_MOUT_G3D_SWITCH, "mout_cmu_g3d_switch", mout_cmu_g3d_switch_p,
+	    CLK_CON_MUX_MUX_CLKCMU_G3D_SWITCH, 0, 2),
+
+	MUX(CLK_MOUT_G3D_BUSD, "mout_cmu_g3d_busd", mout_cmu_g3d_busd_p,
+	    CLK_CON_MUX_MUX_CLKCMU_G3D_BUSD, 0, 2),
+
+	MUX(CLK_MOUT_G3D_GLB, "mout_cmu_g3d_glb", mout_cmu_g3d_glb_p,
+	    CLK_CON_MUX_MUX_CLKCMU_G3D_GLB, 0, 2),
+	/* DPU */
+	MUX(CLK_MOUT_DPU_BUS, "mout_cmu_dpu_bus", mout_cmu_dpu_p,
+	    CLK_CON_MUX_MUX_CLKCMU_DPU_BUS, 0, 2),
+
+	/* DISP */
+	MUX(CLK_MOUT_DISP_BUS, "mout_cmu_disp_bus", mout_cmu_disp_bus_p,
+	    CLK_CON_MUX_MUX_CLKCMU_DISP_BUS, 0, 2),
+
+	/* G2D */
+	MUX(CLK_MOUT_G2D_G2D, "mout_cmu_g2d_g2d", mout_cmu_g2d_g2d_p,
+	    CLK_CON_MUX_MUX_CLKCMU_G2D_G2D, 0, 2),
+
+	MUX(CLK_MOUT_G2D_MSCL, "mout_cmu_g2d_mscl", mout_cmu_g2d_mscl_p,
+	    CLK_CON_MUX_MUX_CLKCMU_G2D_MSCL, 0, 2),
+
+	/* HSI0 */
+	MUX(CLK_MOUT_HSI0_USB31DRD, "mout_cmu_hsi0_usb31drd", mout_cmu_hsi0_usb31drd_p,
+	    CLK_CON_MUX_MUX_CLKCMU_HSI0_USB31DRD, 0, 2),
+
+	MUX(CLK_MOUT_HSI0_BUS, "mout_cmu_hsi0_bus", mout_cmu_hsi0_bus_p,
+	    CLK_CON_MUX_MUX_CLKCMU_HSI0_BUS, 0, 2),
+
+	MUX(CLK_MOUT_HSI0_DPGTC, "mout_cmu_hsi0_dpgtc", mout_cmu_hsi0_dpgtc_p,
+	    CLK_CON_MUX_MUX_CLKCMU_HSI0_DPGTC, 0, 2),
+
+	MUX(CLK_MOUT_HSI0_USBDPDGB, "mout_cmu_hsi0_usbdpdbg", mout_cmu_hsi0_usbdpdbg_p,
+	    CLK_CON_MUX_MUX_CLKCMU_HSI0_USBDPDBG, 0, 2),
+
+	/* HSI1 */
+	MUX(CLK_MOUT_HSI1_BUS, "mout_cmu_hsi1_bus", mout_cmu_hsi1_bus_p,
+	    CLK_CON_MUX_MUX_CLKCMU_HSI1_BUS, 0, 2),
+
+	MUX(CLK_MOUT_HSI1_PCIE, "mout_cmu_hsi1_pcie", mout_cmu_hsi1_pcie_p,
+	    CLK_CON_MUX_MUX_CLKCMU_HSI1_PCIE, 0, 2),
+	/* HSI2 */
+	MUX(CLK_MOUT_HSI2_BUS, "mout_cmu_hsi2_bus", mout_cmu_hsi2_bus_p,
+	    CLK_CON_MUX_MUX_CLKCMU_HSI2_BUS, 0, 2),
+
+	MUX(CLK_MOUT_HSI2_PCIE, "mout_cmu_hsi2_pcie", mout_cmu_hsi2_pcie0_p,
+	    CLK_CON_MUX_MUX_CLKCMU_HSI2_PCIE, 0, 2),
+
+	MUX(CLK_MOUT_HSI2_UFS_EMBD, "mout_cmu_hsi2_ufs_embd", mout_cmu_hsi2_ufs_embd_p,
+	    CLK_CON_MUX_MUX_CLKCMU_HSI2_UFS_EMBD, 0, 2),
+
+	MUX(CLK_MOUT_HSI2_MMC_CARD, "mout_cmu_hsi2_mmc_card", mout_cmu_hsi2_mmc_card_p,
+	    CLK_CON_MUX_MUX_CLKCMU_HSI2_MMC_CARD, 0, 2),
+
+	/* CSIS */
+	MUX(CLK_MOUT_CSIS, "mout_cmu_csis_bus", mout_cmu_csis_bus_p,
+	    CLK_CON_MUX_MUX_CLKCMU_CSIS_BUS, 0, 2),
+
+	/* PDP */
+	MUX(CLK_MOUT_PDP_BUS, "mout_cmu_pdp_bus", mout_cmu_pdp_bus_p,
+	    CLK_CON_MUX_MUX_CLKCMU_PDP_BUS, 0, 2),
+
+	/* PDP */
+	MUX(CLK_MOUT_PDP_VRA, "mout_cmu_pdp_vra", mout_cmu_pdp_vra_p,
+	    CLK_CON_MUX_MUX_CLKCMU_PDP_VRA, 0, 2),
+
+	/* IPP */
+	MUX(CLK_MOUT_IPP_BUS, "mout_cmu_ipp_bus", mout_cmu_ipp_bus_p,
+	    CLK_CON_MUX_MUX_CLKCMU_IPP_BUS, 0, 2),
+
+	/* G3AA */
+	MUX(CLK_MOUT_G3AA, "mout_cmu_g3aa", mout_cmu_g3aa_p,
+	    CLK_CON_MUX_MUX_CLKCMU_G3AA_G3AA, 0, 2),
+
+	/* ITP */
+	MUX(CLK_MOUT_ITP, "mout_cmu_itp_bus", mout_cmu_itp_bus_p,
+	    CLK_CON_MUX_MUX_CLKCMU_ITP_BUS, 0, 2),
+
+	/* DNS */
+	MUX(CLK_MOUT_DNS_BUS, "mout_cmu_dns_bus", mout_cmu_dns_bus_p,
+	    CLK_CON_MUX_MUX_CLKCMU_DNS_BUS, 0, 2),
+
+	/* TNR */
+	MUX(CLK_MOUT_TNR_BUS, "mout_cmu_tnr_bus", mout_cmu_tnr_bus_p,
+	    CLK_CON_MUX_MUX_CLKCMU_TNR_BUS, 0, 2),
+
+	/* MCSC*/
+	MUX(CLK_MOUT_MCSC_ITSC, "mout_cmu_mcsc_itsc", mout_cmu_mcsc_itsc_p,
+	    CLK_CON_MUX_MUX_CLKCMU_MCSC_ITSC, 0, 2),
+
+	MUX(CLK_MOUT_MCSC_MCSC, "mout_cmu_mcsc_mcsc", mout_cmu_mcsc_mcsc_p,
+	    CLK_CON_MUX_MUX_CLKCMU_MCSC_MCSC, 0, 2),
+
+	/* GDC */
+	MUX(CLK_MOUT_GDC_SCSC, "mout_cmu_gdc_scsc", mout_cmu_gdc_scsc_p,
+	    CLK_CON_MUX_MUX_CLKCMU_GDC_SCSC, 0, 2),
+
+	MUX(CLK_MOUT_GDC_GDC0, "mout_cmu_gdc_gdc0", mout_cmu_gdc_gdc0_p,
+	    CLK_CON_MUX_MUX_CLKCMU_GDC_GDC0, 0, 2),
+
+	MUX(CLK_MOUT_GDC_GDC1, "mout_cmu_gdc_gdc1", mout_cmu_gdc_gdc1_p,
+	    CLK_CON_MUX_MUX_CLKCMU_GDC_GDC1, 0, 2),
+
+	/* MFC */
+	MUX(CLK_MOUT_MFC_MFC, "mout_cmu_mfc_mfc", mout_cmu_mfc_mfc_p,
+	    CLK_CON_MUX_MUX_CLKCMU_MFC_MFC, 0, 2),
+
+	/* DDRPHY0/1/2/3 */
+	MUX(CLK_MOUT_MIF_SWITCH, "mout_cmu_mif_switch", mout_cmu_mif_switch_p,
+	    CLK_CON_MUX_MUX_CLKCMU_MIF_SWITCH, 0, 2),
+
+	/* MIF0/1/2/3 */
+	MUX(CLK_MOUT_MIF_BUS, "mout_cmu_mif_busp", mout_cmu_mif_busp_p,
+	    CLK_CON_MUX_MUX_CLKCMU_MIF_BUSP, 0, 2),
+
+	/* MISC */
+	MUX(CLK_MOUT_MISC_BUS, "mout_cmu_misc_bus", mout_cmu_misc_bus_p,
+	    CLK_CON_MUX_MUX_CLKCMU_MISC_BUS, 0, 2),
+	MUX(CLK_MOUT_MISC_SSS, "mout_cmu_misc_sss", mout_cmu_misc_sss_p,
+	    CLK_CON_MUX_MUX_CLKCMU_MISC_SSS, 0, 2),
+
+	/* PERI0 */
+	MUX(CLK_MOUT_PERIC0_IP, "mout_cmu_peric0_ip", mout_cmu_peric0_ip_p,
+	    CLK_CON_MUX_MUX_CLKCMU_PERIC0_IP, 0, 2),
+	MUX(CLK_MOUT_PERIC0_BUS, "mout_cmu_peric0_bus", mout_cmu_peric0_bus_p,
+	    CLK_CON_MUX_MUX_CLKCMU_PERIC0_BUS, 0, 2),
+	/* PERI1 */
+	MUX(CLK_MOUT_PERIC1_IP, "mout_cmu_peric1_ip", mout_cmu_peric1_ip_p,
+	    CLK_CON_MUX_MUX_CLKCMU_PERIC0_IP, 0, 2),
+	MUX(CLK_MOUT_PERIC1_BUS, "mout_cmu_peric1_bus", mout_cmu_peric1_bus_p,
+	    CLK_CON_MUX_MUX_CLKCMU_PERIC0_BUS, 0, 2),
+
+	/* TPU */
+	MUX(CLK_MOUT_TPU_TPU, "mout_cmu_tpu_tpu", mout_cmu_tpu_tpu_p,
+	    CLK_CON_MUX_MUX_CLKCMU_TPU_TPU, 0, 2),
+
+	MUX(CLK_MOUT_TPU_TPUCTL, "mout_cmu_tpu_tpuctl", mout_cmu_tpu_tpuctl_p,
+	    CLK_CON_MUX_MUX_CLKCMU_TPU_TPUCTL, 0, 2),
+
+	MUX(CLK_MOUT_TPU_BUS, "mout_cmu_tpu_bus", mout_cmu_tpu_bus_p,
+	    CLK_CON_MUX_MUX_CLKCMU_TPU_BUS, 0, 2),
+
+	MUX(CLK_MOUT_TPU_UART, "mout_cmu_tpu_uart", mout_cmu_tpu_uart_p,
+	    CLK_CON_MUX_MUX_CLKCMU_TPU_UART, 0, 2),
+
+	/* BO */
+	MUX(CLK_MOUT_BO_BUS, "mout_cmu_bo_bus", mout_cmu_bo_bus_p,
+	    CLK_CON_MUX_MUX_CLKCMU_BO_BUS, 0, 2),
+};
+
+static const struct samsung_div_clock cmu_top_div_clks[] __initconst = {
+	/* CMU_TOP_PURECLKCOMP */
+	DIV(CLK_DOUT_SHARED0_DIV3, "dout_shared0_div3", "mout_shared0_pll",
+	    CLK_CON_DIV_PLL_SHARED0_DIV3, 0, 2),
+	DIV(CLK_DOUT_SHARED0_DIV2, "dout_shared0_div2", "mout_shared0_pll",
+	    CLK_CON_DIV_PLL_SHARED0_DIV2, 0, 1),
+	DIV(CLK_DOUT_SHARED0_DIV5, "dout_shared0_div5", "mout_shared0_pll",
+	    CLK_CON_DIV_PLL_SHARED0_DIV5, 0, 2),
+	DIV(CLK_DOUT_SHARED0_DIV4, "dout_shared0_div4", "dout_shared0_div2",
+	    CLK_CON_DIV_PLL_SHARED0_DIV4, 0, 1),
+
+	DIV(CLK_DOUT_SHARED1_DIV2, "dout_shared1_div2", "mout_shared1_pll",
+	    CLK_CON_DIV_PLL_SHARED1_DIV2, 0, 1),
+	DIV(CLK_DOUT_SHARED1_DIV3, "dout_shared1_div3", "mout_shared1_pll",
+	    CLK_CON_DIV_PLL_SHARED1_DIV3, 0, 2),
+	DIV(CLK_DOUT_SHARED1_DIV4, "dout_shared1_div4", "mout_shared1_pll",
+	    CLK_CON_DIV_PLL_SHARED1_DIV4, 0, 1),
+
+	DIV(CLK_DOUT_SHARED2_DIV2, "dout_shared2_div2", "mout_shared2_pll",
+	    CLK_CON_DIV_PLL_SHARED2_DIV2, 0, 1),
+
+	DIV(CLK_DOUT_SHARED3_DIV2, "dout_shared3_div2", "mout_shared3_pll",
+	    CLK_CON_DIV_PLL_SHARED3_DIV2, 0, 1),
+
+	/* BUS0 */
+	DIV(CLK_DOUT_BUS0_BUS, "dout_cmu_bus0_bus_div", "gout_cmu_bus0_bus",
+	    CLK_CON_DIV_CLKCMU_BUS0_BUS, 0, 4),
+	DIV(CLK_DOUT_CMU_BOOST, "dout_cmu_boost", "gout_cmu_cmu_boost",
+	    CLK_CON_DIV_DIV_CLKCMU_CMU_BOOST, 0, 2),
+
+	/* BUS1 */
+	DIV(CLK_DOUT_BUS1_BUS, "dout_cmu_bus1_bus", "gout_cmu_bus1_bus",
+	    CLK_CON_DIV_CLKCMU_BUS1_BUS, 0, 4),
+
+	/* BUS2 */
+	DIV(CLK_DOUT_BUS2_BUS, "dout_cmu_bus2_bus", "gout_cmu_bus2_bus",
+	    CLK_CON_DIV_CLKCMU_BUS2_BUS, 0, 4),
+
+	/* CORE */
+	DIV(CLK_DOUT_CORE_BUS, "dout_cmu_core_bus", "gout_cmu_core_bus",
+	    CLK_CON_DIV_CLKCMU_CORE_BUS, 0, 4),
+
+	/* EH */
+	DIV(CLK_DOUT_EH_BUS, "dout_cmu_eh_bus", "gout_cmu_eh_bus",
+	    CLK_CON_DIV_CLKCMU_EH_BUS, 0, 4),
+
+	/* CPUCL{0,1,2,} */
+	DIV(CLK_DOUT_CPUCL2_SWITCH, "dout_cmu_cpucl2_switch", "gout_cmu_cpucl2_switch",
+	    CLK_CON_DIV_CLKCMU_CPUCL2_SWITCH, 0, 3),
+
+	DIV(CLK_DOUT_CPUCL1_SWITCH, "dout_cmu_cpucl1_switch", "gout_cmu_cpucl1_switch",
+	    CLK_CON_DIV_CLKCMU_CPUCL1_SWITCH, 0, 3),
+
+	DIV(CLK_DOUT_CPUCL0_SWITCH, "dout_cmu_cpucl0_switch", "gout_cmu_cpucl0_switch",
+	    CLK_CON_DIV_CLKCMU_CPUCL0_SWITCH, 0, 3),
+
+	DIV(CLK_DOUT_CPUCL0_DBG, "dout_cmu_cpucl0_dbg", "gout_cmu_cpucl0_dbg",
+	    CLK_CON_DIV_CLKCMU_CPUCL0_DBG, 0, 4),
+
+	DIV(CLK_DOUT_CMU_HPM, "dout_cmu_hpm", "gout_cmu_hpm",
+	    CLK_CON_DIV_CLKCMU_HPM, 0, 2),
+
+	/* G3D */
+	DIV(CLK_DOUT_G3D_SWITCH, "dout_cmu_g3d_switch", "gout_cmu_g3d_switch",
+	    CLK_CON_DIV_CLKCMU_G3D_SWITCH, 0, 3),
+
+	DIV(CLK_DOUT_G3D_SWITCH, "dout_cmu_g3d_busd", "gout_cmu_g3d_busd",
+	    CLK_CON_DIV_CLKCMU_G3D_BUSD, 0, 4),
+
+	DIV(CLK_DOUT_G3D_GLB, "dout_cmu_g3d_glb", "gout_cmu_g3d_glb",
+	    CLK_CON_DIV_CLKCMU_G3D_GLB, 0, 4),
+
+	/* DPU */
+	DIV(CLK_DOUT_DPU_BUS, "dout_cmu_dpu_bus", "gout_cmu_dpu_bus",
+	    CLK_CON_DIV_CLKCMU_DPU_BUS, 0, 4),
+
+	/* DISP */
+	DIV(CLK_DOUT_DISP_BUS, "dout_cmu_disp_bus", "gout_cmu_disp_bus",
+	    CLK_CON_DIV_CLKCMU_DISP_BUS, 0, 4),
+
+	/* G2D */
+	DIV(CLK_DOUT_G2D_G2D, "dout_cmu_g2d_g2d", "gout_cmu_g2d_g2d",
+	    CLK_CON_DIV_CLKCMU_G2D_G2D, 0, 4),
+
+	DIV(CLK_DOUT_G2D_MSCL, "dout_cmu_g2d_mscl", "gout_cmu_g2d_mscl",
+	    CLK_CON_DIV_CLKCMU_G2D_MSCL, 0, 4),
+
+	/* HSI0 */
+	DIV(CLK_DOUT_HSI0_USB31DRD, "dout_cmu_hsi0_usb31drd", "gout_cmu_hsi0_usb31drd",
+	    CLK_CON_DIV_CLKCMU_HSI0_USB31DRD, 0, 5),
+
+	DIV(CLK_DOUT_HSI0_BUS, "dout_cmu_hsi0_bus", "gout_cmu_hsi0_bus",
+	    CLK_CON_DIV_CLKCMU_HSI0_BUS, 0, 4),
+
+	DIV(CLK_DOUT_HSI0_DPGTC, "dout_cmu_hsi0_dpgtc", "gout_cmu_hsi0_dpgtc",
+	    CLK_CON_DIV_CLKCMU_HSI0_DPGTC, 0, 4),
+
+	/* TODO register exists but all lower bits are reserved */
+	DIV(CLK_DOUT_HSI0_USBDPDGB, "dout_cmu_hsi0_usbdpdbg", "gout_cmu_hsi0_usbdpdbg",
+	    CLK_CON_DIV_CLKCMU_HSI0_USBDPDBG, 0, 0),
+
+	/* HSI1 */
+	DIV(CLK_DOUT_HSI1_BUS, "dout_cmu_hsi1_bus", "gout_cmu_hsi1_bus",
+	    CLK_CON_DIV_CLKCMU_HSI1_BUS, 0, 4),
+
+	DIV(CLK_DOUT_HSI1_PCIE, "dout_cmu_hsi1_pcie", "gout_cmu_hsi1_pcie",
+	    CLK_CON_DIV_CLKCMU_HSI1_PCIE, 0, 3),
+	/* HSI2 */
+	DIV(CLK_DOUT_HSI2_BUS, "dout_cmu_hsi2_bus", "gout_cmu_hsi2_bus",
+	    CLK_CON_DIV_CLKCMU_HSI2_BUS, 0, 4),
+
+	DIV(CLK_DOUT_HSI2_PCIE, "dout_cmu_hsi2_pcie", "gout_cmu_hsi2_pcie",
+	    CLK_CON_DIV_CLKCMU_HSI2_PCIE, 0, 3),
+
+	DIV(CLK_DOUT_HSI2_UFS_EMBD, "dout_cmu_hsi2_ufs_embd", "gout_cmu_hsi2_ufs_embd",
+	    CLK_CON_DIV_CLKCMU_HSI2_UFS_EMBD, 0, 4),
+
+	DIV(CLK_DOUT_HSI2_MMC_CARD, "dout_cmu_hsi2_mmc_card", "gout_cmu_hsi2_mmc_card",
+	    CLK_CON_DIV_CLKCMU_HSI2_MMC_CARD, 0, 9),
+
+	/* CSIS */
+	DIV(CLK_DOUT_CSIS, "dout_cmu_csis_bus", "gout_cmu_csis_bus",
+	    CLK_CON_DIV_CLKCMU_CSIS_BUS, 0, 4),
+
+	/* PDP */
+	DIV(CLK_DOUT_PDP_BUS, "dout_cmu_pdp_bus", "gout_cmu_pdp_bus",
+	    CLK_CON_DIV_CLKCMU_PDP_BUS, 0, 4),
+
+	DIV(CLK_DOUT_PDP_VRA, "dout_cmu_pdp_vra", "gout_cmu_pdp_vra",
+	    CLK_CON_DIV_CLKCMU_PDP_VRA, 0, 4),
+
+	/* IPP */
+	DIV(CLK_DOUT_IPP_BUS, "dout_cmu_ipp_bus", "gout_cmu_ipp_bus",
+	    CLK_CON_DIV_CLKCMU_IPP_BUS, 0, 4),
+
+	/* G3AA */
+	DIV(CLK_DOUT_G3AA, "dout_cmu_g3aa", "gout_cmu_g3aa",
+	    CLK_CON_DIV_CLKCMU_G3AA_G3AA, 0, 4),
+
+	/* ITP */
+	DIV(CLK_DOUT_ITP, "dout_cmu_itp_bus", "gout_cmu_itp_bus",
+	    CLK_CON_DIV_CLKCMU_ITP_BUS, 0, 4),
+
+	/* DNS */
+	DIV(CLK_DOUT_DNS_BUS, "dout_cmu_dns_bus", "gout_cmu_dns_bus",
+	    CLK_CON_DIV_CLKCMU_DNS_BUS, 0, 4),
+
+	/* TNR */
+	DIV(CLK_DOUT_TNR_BUS, "dout_cmu_tnr_bus", "gout_cmu_tnr_bus",
+	    CLK_CON_DIV_CLKCMU_TNR_BUS, 0, 4),
+
+	/* MCSC*/
+	DIV(CLK_DOUT_MCSC_ITSC, "dout_cmu_mcsc_itsc", "gout_cmu_mcsc_itsc",
+	    CLK_CON_DIV_CLKCMU_MCSC_ITSC, 0, 4),
+
+	DIV(CLK_DOUT_MCSC_MCSC, "dout_cmu_mcsc_mcsc", "gout_cmu_mcsc_mcsc",
+	    CLK_CON_DIV_CLKCMU_MCSC_MCSC, 0, 4),
+
+	/* GDC */
+	DIV(CLK_DOUT_GDC_SCSC, "dout_cmu_gdc_scsc", "gout_cmu_gdc_scsc",
+	    CLK_CON_DIV_CLKCMU_GDC_SCSC, 0, 4),
+
+	DIV(CLK_DOUT_GDC_GDC0, "dout_cmu_gdc_gdc0", "gout_cmu_gdc_gdc0",
+	    CLK_CON_DIV_CLKCMU_GDC_GDC0, 0, 4),
+
+	DIV(CLK_DOUT_GDC_GDC1, "dout_cmu_gdc_gdc1", "gout_cmu_gdc_gdc1",
+	    CLK_CON_DIV_CLKCMU_GDC_GDC1, 0, 4),
+
+	/* MFC */
+	DIV(CLK_DOUT_MFC_MFC, "dout_cmu_mfc_mfc", "gout_cmu_mfc_mfc",
+	    CLK_CON_DIV_CLKCMU_MFC_MFC, 0, 4),
+
+	/* MIF0/1/2/3 */
+	DIV(CLK_DOUT_MIF_BUS, "dout_cmu_mif_busp", "gout_cmu_mif_busp",
+	    CLK_CON_DIV_CLKCMU_MIF_BUSP, 0, 4),
+
+	/* MISC */
+	DIV(CLK_DOUT_MISC_BUS, "dout_cmu_misc_bus", "gout_cmu_misc_bus",
+	    CLK_CON_DIV_CLKCMU_MISC_BUS, 0, 4),
+	DIV(CLK_DOUT_MISC_SSS, "dout_cmu_misc_sss", "gout_cmu_misc_sss",
+	    CLK_CON_DIV_CLKCMU_MISC_SSS, 0, 4),
+
+	/* PERI0 */
+	DIV(CLK_DOUT_PERIC0_BUS, "dout_cmu_peric0_bus", "gout_cmu_peric0_bus",
+	    CLK_CON_DIV_CLKCMU_PERIC0_BUS, 0, 4),
+	DIV(CLK_DOUT_PERIC0_IP, "dout_cmu_peric0_ip", "gout_cmu_peric0_ip",
+	    CLK_CON_DIV_CLKCMU_PERIC0_IP, 0, 4),
+
+	/* PERI1 */
+	DIV(CLK_DOUT_PERIC1_BUS, "dout_cmu_peric1_bus", "gout_cmu_peric1_bus",
+	    CLK_CON_DIV_CLKCMU_PERIC1_BUS, 0, 4),
+	DIV(CLK_DOUT_PERIC1_IP, "dout_cmu_peric1_ip", "gout_cmu_peric1_ip",
+	    CLK_CON_DIV_CLKCMU_PERIC1_IP, 0, 4),
+
+	/* TPU */
+	DIV(CLK_DOUT_TPU_TPU, "dout_cmu_tpu_tpu", "gout_cmu_tpu_tpu",
+	    CLK_CON_DIV_CLKCMU_TPU_TPU, 0, 4),
+
+	DIV(CLK_DOUT_TPU_TPUCTL, "dout_cmu_tpu_tpuctl", "gout_cmu_tpu_tpuctl",
+	    CLK_CON_DIV_CLKCMU_TPU_TPUCTL, 0, 4),
+
+	DIV(CLK_DOUT_TPU_BUS, "dout_cmu_tpu_bus", "gout_cmu_tpu_bus",
+	    CLK_CON_DIV_CLKCMU_TPU_BUS, 0, 4),
+
+	DIV(CLK_DOUT_TPU_UART, "dout_cmu_tpu_uart", "gout_cmu_tpu_uart",
+	    CLK_CON_DIV_CLKCMU_TPU_UART, 0, 4),
+
+	/* BO */
+	DIV(CLK_DOUT_BO_BUS, "dout_cmu_bo_bus", "gout_cmu_bo_bus",
+	    CLK_CON_DIV_CLKCMU_BO_BUS, 0, 4),
+
+};
+
+static const struct samsung_gate_clock cmu_top_gate_clks[] __initconst = {
+	/* BUS0 */
+	GATE(CLK_GOUT_BUS0_BUS, "gout_cmu_bus0_bus", "mout_cmu_bus0_bus",
+	     CLK_CON_GAT_GATE_CLKCMU_BUS0_BUS, 21, 0, 0),
+
+	/* BUS1 */
+	GATE(CLK_GOUT_BUS1_BUS, "gout_cmu_bus1_bus", "mout_cmu_bus1_bus",
+	     CLK_CON_GAT_GATE_CLKCMU_BUS1_BUS, 21, 0, 0),
+
+	/* BUS2 */
+	GATE(CLK_GOUT_BUS2_BUS, "gout_cmu_bus2_bus", "mout_cmu_bus2_bus",
+	     CLK_CON_GAT_GATE_CLKCMU_BUS2_BUS, 21, 0, 0),
+
+	/* CORE */
+	GATE(CLK_GOUT_CORE_BUS, "gout_cmu_core_bus", "mout_cmu_core_bus",
+	     CLK_CON_GAT_GATE_CLKCMU_CORE_BUS, 21, 0, 0),
+
+	/* EH */
+	GATE(CLK_GOUT_EH_BUS, "gout_cmu_eh_bus", "mout_cmu_eh_bus",
+	     CLK_CON_GAT_GATE_CLKCMU_EH_BUS, 21, 0, 0),
+
+	/* CPUCL{0,1,2,} */
+	GATE(CLK_GOUT_CPUCL2_SWITCH, "gout_cmu_cpucl2_switch", "mout_cmu_cpucl2_switch",
+	     CLK_CON_GAT_GATE_CLKCMU_CPUCL2_SWITCH, 21, 0, 0),
+
+	GATE(CLK_GOUT_CPUCL1_SWITCH, "gout_cmu_cpucl1_switch", "mout_cmu_cpucl1_switch",
+	     CLK_CON_GAT_GATE_CLKCMU_CPUCL1_SWITCH, 21, 0, 0),
+
+	GATE(CLK_GOUT_CPUCL0_SWITCH, "gout_cmu_cpucl0_switch", "mout_cmu_cpucl0_switch",
+	     CLK_CON_GAT_GATE_CLKCMU_CPUCL0_SWITCH, 21, 0, 0),
+
+	GATE(CLK_GOUT_CPUCL0_DBG, "gout_cmu_cpucl0_dbg", "mout_cmu_cpucl0_dbg",
+	     CLK_CON_GAT_GATE_CLKCMU_CPUCL0_DBG_BUS, 21, 0, 0),
+
+	GATE(CLK_GOUT_CMU_HPM, "gout_cmu_hpm", "mout_cmu_hpm",
+	     CLK_CON_GAT_GATE_CLKCMU_HPM, 21, 0, 0),
+
+	/* G3D */
+	GATE(CLK_GOUT_G3D_SWITCH, "gout_cmu_g3d_switch", "mout_cmu_g3d_switch",
+	     CLK_CON_GAT_GATE_CLKCMU_G3D_SWITCH, 21, 0, 0),
+
+	GATE(CLK_GOUT_G3D_SWITCH, "gout_cmu_g3d_busd", "mout_cmu_g3d_busd",
+	     CLK_CON_GAT_GATE_CLKCMU_G3D_BUSD, 21, 0, 0),
+
+	GATE(CLK_GOUT_G3D_GLB, "gout_cmu_g3d_glb", "mout_cmu_g3d_glb",
+	     CLK_CON_GAT_GATE_CLKCMU_G3D_GLB, 21, 0, 0),
+	/* DPU */
+	GATE(CLK_GOUT_DPU_BUS, "gout_cmu_dpu_bus", "mout_cmu_dpu_bus",
+	     CLK_CON_GAT_GATE_CLKCMU_DPU_BUS, 21, 0, 0),
+	/* DISP */
+	GATE(CLK_GOUT_DISP_BUS, "gout_cmu_disp_bus", "mout_cmu_disp_bus",
+	     CLK_CON_GAT_GATE_CLKCMU_DISP_BUS, 21, 0, 0),
+
+	/* G2D */
+	GATE(CLK_GOUT_G2D_G2D, "gout_cmu_g2d_g2d", "mout_cmu_g2d_g2d",
+	     CLK_CON_GAT_GATE_CLKCMU_G2D_G2D, 21, 0, 0),
+
+	GATE(CLK_GOUT_G2D_MSCL, "gout_cmu_g2d_mscl", "mout_cmu_g2d_mscl",
+	     CLK_CON_GAT_GATE_CLKCMU_G2D_MSCL, 21, 0, 0),
+	/* HSI0 */
+	GATE(CLK_GOUT_HSI0_USB31DRD, "gout_cmu_hsi0_usb31drd", "mout_cmu_hsi0_usb31drd",
+	     CLK_CON_GAT_GATE_CLKCMU_HSI0_USB31DRD, 21, 0, 0),
+
+	GATE(CLK_GOUT_HSI0_BUS, "gout_cmu_hsi0_bus", "mout_cmu_hsi0_bus",
+	     CLK_CON_GAT_GATE_CLKCMU_HSI0_BUS, 21, 0, 0),
+
+	GATE(CLK_GOUT_HSI0_DPGTC, "gout_cmu_hsi0_dpgtc", "mout_cmu_hsi0_dpgtc",
+	     CLK_CON_GAT_GATE_CLKCMU_HSI0_DPGTC, 21, 0, 0),
+
+	GATE(CLK_GOUT_HSI0_USBDPDGB, "gout_cmu_hsi0_usbdpdbg", "mout_cmu_hsi0_usbdpdbg",
+	     CLK_CON_GAT_GATE_CLKCMU_HSI0_USBDPDBG, 21, 0, 0),
+	/* HSI1 */
+	GATE(CLK_GOUT_HSI1_BUS, "gout_cmu_hsi1_bus", "mout_cmu_hsi1_bus",
+	     CLK_CON_GAT_GATE_CLKCMU_HSI1_BUS, 21, 0, 0),
+
+	GATE(CLK_GOUT_HSI1_PCIE, "gout_cmu_hsi1_pcie", "mout_cmu_hsi1_pcie",
+	     CLK_CON_GAT_GATE_CLKCMU_HSI1_PCIE, 21, 0, 0),
+	/* HSI2 */
+	GATE(CLK_GOUT_HSI2_BUS, "gout_cmu_hsi2_bus", "mout_cmu_hsi2_bus",
+	     CLK_CON_GAT_GATE_CLKCMU_HSI2_BUS, 21, 0, 0),
+	GATE(CLK_GOUT_HSI2_PCIE, "gout_cmu_hsi2_pcie", "mout_cmu_hsi2_pcie",
+	     CLK_CON_GAT_GATE_CLKCMU_HSI2_PCIE, 21, 0, 0),
+
+	GATE(CLK_GOUT_HSI2_UFS_EMBD, "gout_cmu_hsi2_ufs_embd", "mout_cmu_hsi2_ufs_embd",
+	     CLK_CON_GAT_GATE_CLKCMU_HSI2_UFS_EMBD, 21, 0, 0),
+	GATE(CLK_GOUT_HSI2_MMC_CARD, "gout_cmu_hsi2_mmc_card", "mout_cmu_hsi2_mmc_card",
+	     CLK_CON_GAT_GATE_CLKCMU_HSI2_MMCCARD, 21, 0, 0),
+	/* CSIS */
+	GATE(CLK_GOUT_CSIS, "gout_cmu_csis_bus", "mout_cmu_csis_bus",
+	     CLK_CON_GAT_GATE_CLKCMU_CSIS_BUS, 21, 0, 0),
+	/* PDP */
+	GATE(CLK_GOUT_PDP_BUS, "gout_cmu_pdp_bus", "mout_cmu_pdp_bus",
+	     CLK_CON_GAT_GATE_CLKCMU_PDP_BUS, 21, 0, 0),
+
+	GATE(CLK_GOUT_PDP_VRA, "gout_cmu_pdp_vra", "mout_cmu_pdp_vra",
+	     CLK_CON_GAT_GATE_CLKCMU_PDP_BUS, 21, 0, 0),
+
+	/* IPP */
+	GATE(CLK_GOUT_IPP_BUS, "gout_cmu_ipp_bus", "mout_cmu_ipp_bus",
+	     CLK_CON_GAT_GATE_CLKCMU_IPP_BUS, 21, 0, 0),
+	/* G3AA */
+	GATE(CLK_GOUT_G3AA, "gout_cmu_g3aa", "mout_cmu_g3aa",
+	     CLK_CON_MUX_MUX_CLKCMU_G3AA_G3AA, 21, 0, 0),
+
+	/* ITP */
+	GATE(CLK_GOUT_ITP, "gout_cmu_itp_bus", "mout_cmu_itp_bus",
+	     CLK_CON_GAT_GATE_CLKCMU_ITP_BUS, 21, 0, 0),
+
+	/* DNS */
+	GATE(CLK_GOUT_DNS_BUS, "gout_cmu_dns_bus", "mout_cmu_dns_bus",
+	     CLK_CON_GAT_GATE_CLKCMU_DNS_BUS, 21, 0, 0),
+
+	/* TNR */
+	GATE(CLK_GOUT_TNR_BUS, "gout_cmu_tnr_bus", "mout_cmu_tnr_bus",
+	     CLK_CON_GAT_GATE_CLKCMU_TNR_BUS, 21, 0, 0),
+
+	/* MCSC*/
+	GATE(CLK_GOUT_MCSC_ITSC, "gout_cmu_mcsc_itsc", "mout_cmu_mcsc_itsc",
+	     CLK_CON_GAT_GATE_CLKCMU_MCSC_ITSC, 21, 0, 0),
+
+	GATE(CLK_GOUT_MCSC_MCSC, "gout_cmu_mcsc_mcsc", "mout_cmu_mcsc_mcsc",
+	     CLK_CON_GAT_GATE_CLKCMU_MCSC_MCSC, 21, 0, 0),
+
+	/* GDC */
+	GATE(CLK_GOUT_GDC_SCSC, "gout_cmu_gdc_scsc", "mout_cmu_gdc_scsc",
+	     CLK_CON_GAT_GATE_CLKCMU_GDC_SCSC, 21, 0, 0),
+
+	GATE(CLK_GOUT_GDC_GDC0, "gout_cmu_gdc_gdc0", "mout_cmu_gdc_gdc0",
+	     CLK_CON_GAT_GATE_CLKCMU_GDC_GDC0, 21, 0, 0),
+
+	GATE(CLK_GOUT_GDC_GDC1, "gout_cmu_gdc_gdc1", "mout_cmu_gdc_gdc1",
+	     CLK_CON_GAT_GATE_CLKCMU_GDC_GDC1, 21, 0, 0),
+
+	/* MFC */
+	GATE(CLK_GOUT_MFC_MFC, "gout_cmu_mfc_mfc", "mout_cmu_mfc_mfc",
+	     CLK_CON_GAT_GATE_CLKCMU_MFC_MFC, 21, 0, 0),
+
+	/* DDRPHY0/1/2/3 */
+	GATE(CLK_GOUT_MIF_SWITCH, "gout_cmu_mif_switch", "mout_cmu_mif_switch",
+	     CLK_CON_GAT_CLKCMU_MIF_SWITCH, 21, 0, 0),
+
+	/* MIF0/1/2/3 */
+	GATE(CLK_GOUT_MIF_BUS, "gout_cmu_mif_busp", "mout_cmu_mif_busp",
+	     CLK_CON_GAT_GATE_CLKCMU_MIF_BUSP, 21, 0, 0),
+
+	GATE(CLK_GOUT_CMU_BOOST, "gout_cmu_cmu_boost", "mout_cmu_boost",
+	     CLK_CON_GAT_GATE_CLKCMU_CMU_BOOST, 21, 0, 0),
+
+	/* MISC */
+	GATE(CLK_GOUT_MISC_BUS, "gout_cmu_misc_bus", "mout_cmu_misc_bus",
+	     CLK_CON_GAT_GATE_CLKCMU_MISC_BUS, 21, 0, 0),
+	GATE(CLK_GOUT_MISC_SSS, "gout_cmu_misc_sss", "mout_cmu_misc_sss",
+	     CLK_CON_GAT_GATE_CLKCMU_MISC_SSS, 21, 0, 0),
+
+	/* PERI0 */
+	GATE(CLK_GOUT_PERIC0_BUS, "gout_cmu_peric0_bus", "mout_cmu_peric0_bus",
+	     CLK_CON_GAT_GATE_CLKCMU_PERIC0_BUS, 21, 0, 0),
+	GATE(CLK_GOUT_PERIC0_IP, "gout_cmu_peric0_ip", "mout_cmu_peric0_ip",
+	     CLK_CON_GAT_GATE_CLKCMU_PERIC0_IP, 21, 0, 0),
+
+	/* PERI1 */
+	GATE(CLK_GOUT_PERIC1_BUS, "gout_cmu_peric1_bus", "mout_cmu_peric1_bus",
+	     CLK_CON_GAT_GATE_CLKCMU_PERIC1_BUS, 21, 0, 0),
+	GATE(CLK_GOUT_PERIC1_IP, "gout_cmu_peric1_ip", "mout_cmu_peric1_ip",
+	     CLK_CON_GAT_GATE_CLKCMU_PERIC1_IP, 21, 0, 0),
+
+	/* TPU */
+	GATE(CLK_GOUT_TPU_TPU, "gout_cmu_tpu_tpu", "mout_cmu_tpu_tpu",
+	     CLK_CON_GAT_GATE_CLKCMU_TPU_TPU, 21, 0, 0),
+	GATE(CLK_GOUT_TPU_TPUCTL, "gout_cmu_tpu_tpuctl", "mout_cmu_tpu_tpuctl",
+	     CLK_CON_GAT_GATE_CLKCMU_TPU_TPUCTL, 21, 0, 0),
+	GATE(CLK_GOUT_TPU_BUS, "gout_cmu_tpu_bus", "mout_cmu_tpu_bus",
+	     CLK_CON_GAT_GATE_CLKCMU_TPU_BUS, 21, 0, 0),
+	GATE(CLK_GOUT_TPU_UART, "gout_cmu_tpu_uart", "mout_cmu_tpu_uart",
+	     CLK_CON_GAT_GATE_CLKCMU_TPU_UART, 21, 0, 0),
+
+	/* BO */
+	GATE(CLK_GOUT_BO_BUS, "gout_cmu_bo_bus", "mout_cmu_bo_bus",
+	     CLK_CON_GAT_GATE_CLKCMU_BO_BUS, 21, 0, 0),
+
+};
+
+static const struct samsung_cmu_info top_cmu_info __initconst = {
+	.pll_clks		= cmu_top_pll_clks,
+	.nr_pll_clks		= ARRAY_SIZE(cmu_top_pll_clks),
+	.mux_clks		= cmu_top_mux_clks,
+	.nr_mux_clks		= ARRAY_SIZE(cmu_top_mux_clks),
+	.div_clks		= cmu_top_div_clks,
+	.nr_div_clks		= ARRAY_SIZE(cmu_top_div_clks),
+	.gate_clks		= cmu_top_gate_clks,
+	.nr_gate_clks		= ARRAY_SIZE(cmu_top_gate_clks),
+	.nr_clk_ids		= TOP_NR_CLK,
+	.clk_regs		= cmu_top_clk_regs,
+	.nr_clk_regs		= ARRAY_SIZE(cmu_top_clk_regs),
+};
+
+static void __init gs101_cmu_top_init(struct device_node *np)
+{
+	exynos_arm64_register_cmu(NULL, np, &top_cmu_info);
+}
+
+/* Register CMU_TOP early, as it's a dependency for other early domains */
+CLK_OF_DECLARE(gs101_cmu_top, "google,gs101-cmu-top",
+	       gs101_cmu_top_init);
-- 
2.42.0.609.gbb76f46606-goog

[PATCH v2 10/20] clk: samsung: clk-gs101: Add cmu_top registers, plls, mux and gates

[Peter Griffin]

CMU_TOP is the top level clock management unit which contains PLLs, muxes
and gates that feed the other clock management units.

Signed-off-by: Peter Griffin <peter.griffin@linaro.org>
---
 drivers/clk/samsung/Kconfig     |    9 +
 drivers/clk/samsung/Makefile    |    2 +
 drivers/clk/samsung/clk-gs101.c | 1551 +++++++++++++++++++++++++++++++
 3 files changed, 1562 insertions(+)
 create mode 100644 drivers/clk/samsung/clk-gs101.c

diff --git a/drivers/clk/samsung/Kconfig b/drivers/clk/samsung/Kconfig
index 76a494e95027..14362ec9c543 100644
--- a/drivers/clk/samsung/Kconfig
+++ b/drivers/clk/samsung/Kconfig
@@ -12,6 +12,7 @@ config COMMON_CLK_SAMSUNG
 	select EXYNOS_5410_COMMON_CLK if ARM && SOC_EXYNOS5410
 	select EXYNOS_5420_COMMON_CLK if ARM && SOC_EXYNOS5420
 	select EXYNOS_ARM64_COMMON_CLK if ARM64 && ARCH_EXYNOS
+	select GOOGLE_GS101_COMMON_CLK if ARM64 && ARCH_GOOGLE_TENSOR
 	select TESLA_FSD_COMMON_CLK if ARM64 && ARCH_TESLA_FSD
 
 config S3C64XX_COMMON_CLK
@@ -95,6 +96,14 @@ config EXYNOS_CLKOUT
 	  status of the certains clocks from SoC, but it could also be tied to
 	  other devices as an input clock.
 
+config GOOGLE_GS101_COMMON_CLK
+	bool "Google gs101 clock controller support" if COMPILE_TEST
+	depends on COMMON_CLK_SAMSUNG
+	depends on EXYNOS_ARM64_COMMON_CLK
+	help
+	  Support for the clock controller present on the Google gs101 SoC.
+	  Choose Y here only if you build for this SoC.
+
 config TESLA_FSD_COMMON_CLK
 	bool "Tesla FSD clock controller support" if COMPILE_TEST
 	depends on COMMON_CLK_SAMSUNG
diff --git a/drivers/clk/samsung/Makefile b/drivers/clk/samsung/Makefile
index ebbeacabe88f..49146937d957 100644
--- a/drivers/clk/samsung/Makefile
+++ b/drivers/clk/samsung/Makefile
@@ -21,6 +21,8 @@ obj-$(CONFIG_EXYNOS_ARM64_COMMON_CLK)	+= clk-exynos7.o
 obj-$(CONFIG_EXYNOS_ARM64_COMMON_CLK)	+= clk-exynos7885.o
 obj-$(CONFIG_EXYNOS_ARM64_COMMON_CLK)	+= clk-exynos850.o
 obj-$(CONFIG_EXYNOS_ARM64_COMMON_CLK)	+= clk-exynosautov9.o
+obj-$(CONFIG_GOOGLE_GS101_COMMON_CLK)	+= clk-gs101.o
 obj-$(CONFIG_S3C64XX_COMMON_CLK)	+= clk-s3c64xx.o
 obj-$(CONFIG_S5PV210_COMMON_CLK)	+= clk-s5pv210.o clk-s5pv210-audss.o
 obj-$(CONFIG_TESLA_FSD_COMMON_CLK)	+= clk-fsd.o
+
diff --git a/drivers/clk/samsung/clk-gs101.c b/drivers/clk/samsung/clk-gs101.c
new file mode 100644
index 000000000000..e2c62754b1eb
--- /dev/null
+++ b/drivers/clk/samsung/clk-gs101.c
@@ -0,0 +1,1551 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Copyright (C) 2023 Linaro Ltd.
+ * Author: Peter Griffin <peter.griffin@linaro.org>
+ *
+ * Common Clock Framework support for GS101.
+ */
+
+#include <linux/clk.h>
+#include <linux/clk-provider.h>
+#include <linux/of.h>
+#include <linux/of_device.h>
+#include <linux/platform_device.h>
+
+#include <dt-bindings/clock/google,gs101.h>
+
+#include "clk.h"
+#include "clk-exynos-arm64.h"
+
+/* NOTE: Must be equal to the last clock ID increased by one */
+#define TOP_NR_CLK                     (CLK_GOUT_CMU_BOOST + 1)
+
+/* ---- CMU_TOP ------------------------------------------------------------- */
+
+/* Register Offset definitions for CMU_TOP (0x1e080000) */
+
+#define PLL_LOCKTIME_PLL_SHARED0			0x0000
+#define PLL_LOCKTIME_PLL_SHARED1			0x0004
+#define PLL_LOCKTIME_PLL_SHARED2			0x0008
+#define PLL_LOCKTIME_PLL_SHARED3			0x000c
+#define PLL_LOCKTIME_PLL_SPARE				0x0010
+#define PLL_CON0_PLL_SHARED0				0x0100
+#define PLL_CON1_PLL_SHARED0				0x0104
+#define PLL_CON2_PLL_SHARED0				0x0108
+#define PLL_CON3_PLL_SHARED0				0x010c
+#define PLL_CON4_PLL_SHARED0				0x0110
+#define PLL_CON0_PLL_SHARED1				0x0140
+#define PLL_CON1_PLL_SHARED1				0x0144
+#define PLL_CON2_PLL_SHARED1				0x0148
+#define PLL_CON3_PLL_SHARED1				0x014c
+#define PLL_CON4_PLL_SHARED1				0x0150
+#define PLL_CON0_PLL_SHARED2				0x0180
+#define PLL_CON1_PLL_SHARED2				0x0184
+#define PLL_CON2_PLL_SHARED2				0x0188
+#define PLL_CON3_PLL_SHARED2				0x018c
+#define PLL_CON4_PLL_SHARED2				0x0190
+#define PLL_CON0_PLL_SHARED3				0x01c0
+#define PLL_CON1_PLL_SHARED3				0x01c4
+#define PLL_CON2_PLL_SHARED3				0x01c8
+#define PLL_CON3_PLL_SHARED3				0x01cc
+#define PLL_CON4_PLL_SHARED3				0x01d0
+#define PLL_CON0_PLL_SPARE				0x0200
+#define PLL_CON1_PLL_SPARE				0x0204
+#define PLL_CON2_PLL_SPARE				0x0208
+#define PLL_CON3_PLL_SPARE				0x020c
+#define PLL_CON4_PLL_SPARE				0x0210
+#define CMU_CMU_TOP_CONTROLLER_OPTION			0x0800
+#define CLKOUT_CON_BLK_CMU_CMU_TOP_CLKOUT0		0x0810
+#define CMU_HCHGEN_CLKMUX_CMU_BOOST			0x0840
+#define CMU_HCHGEN_CLKMUX_TOP_BOOST			0x0844
+#define CMU_HCHGEN_CLKMUX				0x0850
+#define POWER_FAIL_DETECT_PLL				0x0864
+#define EARLY_WAKEUP_FORCED_0_ENABLE			0x0870
+#define EARLY_WAKEUP_FORCED_1_ENABLE			0x0874
+#define EARLY_WAKEUP_APM_CTRL				0x0878
+#define EARLY_WAKEUP_CLUSTER0_CTRL			0x087c
+#define EARLY_WAKEUP_DPU_CTRL				0x0880
+#define EARLY_WAKEUP_CSIS_CTRL				0x0884
+#define EARLY_WAKEUP_APM_DEST				0x0890
+#define EARLY_WAKEUP_CLUSTER0_DEST			0x0894
+#define EARLY_WAKEUP_DPU_DEST				0x0898
+#define EARLY_WAKEUP_CSIS_DEST				0x089c
+#define EARLY_WAKEUP_SW_TRIG_APM			0x08c0
+#define EARLY_WAKEUP_SW_TRIG_APM_SET			0x08c4
+#define EARLY_WAKEUP_SW_TRIG_APM_CLEAR			0x08c8
+#define EARLY_WAKEUP_SW_TRIG_CLUSTER0			0x08d0
+#define EARLY_WAKEUP_SW_TRIG_CLUSTER0_SET		0x08d4
+#define EARLY_WAKEUP_SW_TRIG_CLUSTER0_CLEAR		0x08d8
+#define EARLY_WAKEUP_SW_TRIG_DPU			0x08e0
+#define EARLY_WAKEUP_SW_TRIG_DPU_SET			0x08e4
+#define EARLY_WAKEUP_SW_TRIG_DPU_CLEAR			0x08e8
+#define EARLY_WAKEUP_SW_TRIG_CSIS			0x08f0
+#define EARLY_WAKEUP_SW_TRIG_CSIS_SET			0x08f4
+#define EARLY_WAKEUP_SW_TRIG_CSIS_CLEAR			0x08f8
+
+#define CLK_CON_MUX_MUX_CLKCMU_BO_BUS			0x1000
+#define CLK_CON_MUX_MUX_CLKCMU_BUS0_BUS			0x1004
+#define CLK_CON_MUX_MUX_CLKCMU_BUS1_BUS			0x1008
+#define CLK_CON_MUX_MUX_CLKCMU_BUS2_BUS			0x100c
+#define CLK_CON_MUX_MUX_CLKCMU_CIS_CLK0			0x1010
+#define CLK_CON_MUX_MUX_CLKCMU_CIS_CLK1			0x1014
+#define CLK_CON_MUX_MUX_CLKCMU_CIS_CLK2			0x1018
+#define CLK_CON_MUX_MUX_CLKCMU_CIS_CLK3			0x101c
+#define CLK_CON_MUX_MUX_CLKCMU_CIS_CLK4			0x1020
+#define CLK_CON_MUX_MUX_CLKCMU_CIS_CLK5			0x1024
+#define CLK_CON_MUX_MUX_CLKCMU_CIS_CLK6			0x1028
+#define CLK_CON_MUX_MUX_CLKCMU_CIS_CLK7			0x102c
+#define CLK_CON_MUX_MUX_CLKCMU_CMU_BOOST		0x1030
+#define CLK_CON_MUX_MUX_CLKCMU_CMU_BOOST_OPTION1	0x1034
+#define CLK_CON_MUX_MUX_CLKCMU_CORE_BUS			0x1038
+#define CLK_CON_MUX_MUX_CLKCMU_CPUCL0_DBG		0x103c
+#define CLK_CON_MUX_MUX_CLKCMU_CPUCL0_SWITCH		0x1040
+#define CLK_CON_MUX_MUX_CLKCMU_CPUCL1_SWITCH		0x1044
+#define CLK_CON_MUX_MUX_CLKCMU_CPUCL2_SWITCH		0x1048
+#define CLK_CON_MUX_MUX_CLKCMU_CSIS_BUS			0x104c
+#define CLK_CON_MUX_MUX_CLKCMU_DISP_BUS			0x1050
+#define CLK_CON_MUX_MUX_CLKCMU_DNS_BUS			0x1054
+#define CLK_CON_MUX_MUX_CLKCMU_DPU_BUS			0x1058
+#define CLK_CON_MUX_MUX_CLKCMU_EH_BUS			0x105c
+#define CLK_CON_MUX_MUX_CLKCMU_G2D_G2D			0x1060
+#define CLK_CON_MUX_MUX_CLKCMU_G2D_MSCL			0x1064
+#define CLK_CON_MUX_MUX_CLKCMU_G3AA_G3AA		0x1068
+#define CLK_CON_MUX_MUX_CLKCMU_G3D_BUSD			0x106c
+#define CLK_CON_MUX_MUX_CLKCMU_G3D_GLB			0x1070
+#define CLK_CON_MUX_MUX_CLKCMU_G3D_SWITCH		0x1074
+#define CLK_CON_MUX_MUX_CLKCMU_GDC_GDC0			0x1078
+#define CLK_CON_MUX_MUX_CLKCMU_GDC_GDC1			0x107c
+#define CLK_CON_MUX_MUX_CLKCMU_GDC_SCSC			0x1080
+#define CLK_CON_MUX_MUX_CLKCMU_HPM			0x1084
+#define CLK_CON_MUX_MUX_CLKCMU_HSI0_BUS			0x1088
+#define CLK_CON_MUX_MUX_CLKCMU_HSI0_DPGTC		0x108c
+#define CLK_CON_MUX_MUX_CLKCMU_HSI0_USB31DRD		0x1090
+#define CLK_CON_MUX_MUX_CLKCMU_HSI0_USBDPDBG		0x1094
+#define CLK_CON_MUX_MUX_CLKCMU_HSI1_BUS			0x1098
+#define CLK_CON_MUX_MUX_CLKCMU_HSI1_PCIE		0x109c
+#define CLK_CON_MUX_MUX_CLKCMU_HSI2_BUS			0x10a0
+#define CLK_CON_MUX_MUX_CLKCMU_HSI2_MMC_CARD		0x10a4
+#define CLK_CON_MUX_MUX_CLKCMU_HSI2_PCIE		0x10a8
+#define CLK_CON_MUX_MUX_CLKCMU_HSI2_UFS_EMBD		0x10ac
+#define CLK_CON_MUX_MUX_CLKCMU_IPP_BUS			0x10b0
+#define CLK_CON_MUX_MUX_CLKCMU_ITP_BUS			0x10b4
+#define CLK_CON_MUX_MUX_CLKCMU_MCSC_ITSC		0x10b8
+#define CLK_CON_MUX_MUX_CLKCMU_MCSC_MCSC		0x10bc
+#define CLK_CON_MUX_MUX_CLKCMU_MFC_MFC			0x10c0
+#define CLK_CON_MUX_MUX_CLKCMU_MIF_BUSP			0x10c4
+#define CLK_CON_MUX_MUX_CLKCMU_MIF_SWITCH		0x10c8
+#define CLK_CON_MUX_MUX_CLKCMU_MISC_BUS			0x10cc
+#define CLK_CON_MUX_MUX_CLKCMU_MISC_SSS			0x10d0
+#define CLK_CON_MUX_MUX_CLKCMU_PDP_BUS			0x10d4
+#define CLK_CON_MUX_MUX_CLKCMU_PDP_VRA			0x10d8
+#define CLK_CON_MUX_MUX_CLKCMU_PERIC0_BUS		0x10dc
+#define CLK_CON_MUX_MUX_CLKCMU_PERIC0_IP		0x10e0
+#define CLK_CON_MUX_MUX_CLKCMU_PERIC1_BUS		0x10e4
+#define CLK_CON_MUX_MUX_CLKCMU_PERIC1_IP		0x10e8
+#define CLK_CON_MUX_MUX_CLKCMU_TNR_BUS			0x10ec
+#define CLK_CON_MUX_MUX_CLKCMU_TOP_BOOST_OPTION1	0x10f0
+#define CLK_CON_MUX_MUX_CLKCMU_TOP_CMUREF		0x10f4
+#define CLK_CON_MUX_MUX_CLKCMU_TPU_BUS			0x10f8
+#define CLK_CON_MUX_MUX_CLKCMU_TPU_TPU			0x10fc
+#define CLK_CON_MUX_MUX_CLKCMU_TPU_TPUCTL		0x1100
+#define CLK_CON_MUX_MUX_CLKCMU_TPU_UART			0x1104
+#define CLK_CON_MUX_MUX_CMU_CMUREF			0x1108
+
+#define CLK_CON_DIV_CLKCMU_BO_BUS			0x1800
+#define CLK_CON_DIV_CLKCMU_BUS0_BUS			0x1804
+#define CLK_CON_DIV_CLKCMU_BUS1_BUS			0x1808
+#define CLK_CON_DIV_CLKCMU_BUS2_BUS			0x180c
+#define CLK_CON_DIV_CLKCMU_CIS_CLK0			0x1810
+#define CLK_CON_DIV_CLKCMU_CIS_CLK1			0x1814
+#define CLK_CON_DIV_CLKCMU_CIS_CLK2			0x1818
+#define CLK_CON_DIV_CLKCMU_CIS_CLK3			0x181c
+#define CLK_CON_DIV_CLKCMU_CIS_CLK4			0x1820
+#define CLK_CON_DIV_CLKCMU_CIS_CLK5			0x1824
+#define CLK_CON_DIV_CLKCMU_CIS_CLK6			0x1828
+#define CLK_CON_DIV_CLKCMU_CIS_CLK7			0x182c
+#define CLK_CON_DIV_CLKCMU_CORE_BUS			0x1830
+#define CLK_CON_DIV_CLKCMU_CPUCL0_DBG			0x1834
+#define CLK_CON_DIV_CLKCMU_CPUCL0_SWITCH		0x1838
+#define CLK_CON_DIV_CLKCMU_CPUCL1_SWITCH		0x183c
+#define CLK_CON_DIV_CLKCMU_CPUCL2_SWITCH		0x1840
+#define CLK_CON_DIV_CLKCMU_CSIS_BUS			0x1844
+#define CLK_CON_DIV_CLKCMU_DISP_BUS			0x1848
+#define CLK_CON_DIV_CLKCMU_DNS_BUS			0x184c
+#define CLK_CON_DIV_CLKCMU_DPU_BUS			0x1850
+#define CLK_CON_DIV_CLKCMU_EH_BUS			0x1854
+#define CLK_CON_DIV_CLKCMU_G2D_G2D			0x1858
+#define CLK_CON_DIV_CLKCMU_G2D_MSCL			0x185c
+#define CLK_CON_DIV_CLKCMU_G3AA_G3AA			0x1860
+#define CLK_CON_DIV_CLKCMU_G3D_BUSD			0x1864
+#define CLK_CON_DIV_CLKCMU_G3D_GLB			0x1868
+#define CLK_CON_DIV_CLKCMU_G3D_SWITCH			0x186c
+#define CLK_CON_DIV_CLKCMU_GDC_GDC0			0x1870
+#define CLK_CON_DIV_CLKCMU_GDC_GDC1			0x1874
+#define CLK_CON_DIV_CLKCMU_GDC_SCSC			0x1878
+#define CLK_CON_DIV_CLKCMU_HPM				0x187c
+#define CLK_CON_DIV_CLKCMU_HSI0_BUS			0x1880
+#define CLK_CON_DIV_CLKCMU_HSI0_DPGTC			0x1884
+#define CLK_CON_DIV_CLKCMU_HSI0_USB31DRD		0x1888
+#define CLK_CON_DIV_CLKCMU_HSI0_USBDPDBG		0x188c
+#define CLK_CON_DIV_CLKCMU_HSI1_BUS			0x1890
+#define CLK_CON_DIV_CLKCMU_HSI1_PCIE			0x1894
+#define CLK_CON_DIV_CLKCMU_HSI2_BUS			0x1898
+#define CLK_CON_DIV_CLKCMU_HSI2_MMC_CARD		0x189c
+#define CLK_CON_DIV_CLKCMU_HSI2_PCIE			0x18a0
+#define CLK_CON_DIV_CLKCMU_HSI2_UFS_EMBD		0x18a4
+#define CLK_CON_DIV_CLKCMU_IPP_BUS			0x18a8
+#define CLK_CON_DIV_CLKCMU_ITP_BUS			0x18ac
+#define CLK_CON_DIV_CLKCMU_MCSC_ITSC			0x18b0
+#define CLK_CON_DIV_CLKCMU_MCSC_MCSC			0x18b4
+#define CLK_CON_DIV_CLKCMU_MFC_MFC			0x18b8
+#define CLK_CON_DIV_CLKCMU_MIF_BUSP			0x18bc
+#define CLK_CON_DIV_CLKCMU_MISC_BUS			0x18c0
+#define CLK_CON_DIV_CLKCMU_MISC_SSS			0x18c4
+#define CLK_CON_DIV_CLKCMU_OTP				0x18c8
+#define CLK_CON_DIV_CLKCMU_PDP_BUS			0x18cc
+#define CLK_CON_DIV_CLKCMU_PDP_VRA			0x18d0
+#define CLK_CON_DIV_CLKCMU_PERIC0_BUS			0x18d4
+#define CLK_CON_DIV_CLKCMU_PERIC0_IP			0x18d8
+#define CLK_CON_DIV_CLKCMU_PERIC1_BUS			0x18dc
+#define CLK_CON_DIV_CLKCMU_PERIC1_IP			0x18e0
+#define CLK_CON_DIV_CLKCMU_TNR_BUS			0x18e4
+#define CLK_CON_DIV_CLKCMU_TPU_BUS			0x18e8
+#define CLK_CON_DIV_CLKCMU_TPU_TPU			0x18ec
+#define CLK_CON_DIV_CLKCMU_TPU_TPUCTL			0x18f0
+#define CLK_CON_DIV_CLKCMU_TPU_UART			0x18f4
+#define CLK_CON_DIV_DIV_CLKCMU_CMU_BOOST		0x18f8
+#define CLK_CON_DIV_DIV_CLK_CMU_CMUREF			0x18fc
+#define CLK_CON_DIV_PLL_SHARED0_DIV2			0x1900
+#define CLK_CON_DIV_PLL_SHARED0_DIV3			0x1904
+#define CLK_CON_DIV_PLL_SHARED0_DIV4			0x1908
+#define CLK_CON_DIV_PLL_SHARED0_DIV5			0x190c
+#define CLK_CON_DIV_PLL_SHARED1_DIV2			0x1910
+#define CLK_CON_DIV_PLL_SHARED1_DIV3			0x1914
+#define CLK_CON_DIV_PLL_SHARED1_DIV4			0x1918
+#define CLK_CON_DIV_PLL_SHARED2_DIV2			0x191c
+#define CLK_CON_DIV_PLL_SHARED3_DIV2			0x1920
+
+/* CLK_CON_GAT_UPDATES */
+#define CLK_CON_GAT_CLKCMU_BUS0_BOOST			0x2000
+#define CLK_CON_GAT_CLKCMU_BUS1_BOOST			0x2004
+#define CLK_CON_GAT_CLKCMU_BUS2_BOOST			0x2008
+#define CLK_CON_GAT_CLKCMU_CORE_BOOST			0x200c
+#define CLK_CON_GAT_CLKCMU_CPUCL0_BOOST			0x2010
+#define CLK_CON_GAT_CLKCMU_CPUCL1_BOOST			0x2014
+#define CLK_CON_GAT_CLKCMU_CPUCL2_BOOST			0x2018
+#define CLK_CON_GAT_CLKCMU_MIF_BOOST			0x201c
+#define CLK_CON_GAT_CLKCMU_MIF_SWITCH			0x2020
+#define CLK_CON_GAT_GATE_CLKCMU_BO_BUS			0x2024
+#define CLK_CON_GAT_GATE_CLKCMU_BUS0_BUS		0x2028
+#define CLK_CON_GAT_GATE_CLKCMU_BUS1_BUS		0x202c
+#define CLK_CON_GAT_GATE_CLKCMU_BUS2_BUS		0x2030
+#define CLK_CON_GAT_GATE_CLKCMU_CIS_CLK0		0x2034
+#define CLK_CON_GAT_GATE_CLKCMU_CIS_CLK1		0x2038
+#define CLK_CON_GAT_GATE_CLKCMU_CIS_CLK2		0x203c
+#define CLK_CON_GAT_GATE_CLKCMU_CIS_CLK3		0x2040
+#define CLK_CON_GAT_GATE_CLKCMU_CIS_CLK4		0x2044
+#define CLK_CON_GAT_GATE_CLKCMU_CIS_CLK5		0x2048
+#define CLK_CON_GAT_GATE_CLKCMU_CIS_CLK6		0x204c
+#define CLK_CON_GAT_GATE_CLKCMU_CIS_CLK7		0x2050
+#define CLK_CON_GAT_GATE_CLKCMU_CMU_BOOST		0x2054
+#define CLK_CON_GAT_GATE_CLKCMU_CORE_BUS		0x2058
+#define CLK_CON_GAT_GATE_CLKCMU_CPUCL0_DBG_BUS		0x205c
+#define CLK_CON_GAT_GATE_CLKCMU_CPUCL0_SWITCH		0x2060
+#define CLK_CON_GAT_GATE_CLKCMU_CPUCL1_SWITCH		0x2064
+#define CLK_CON_GAT_GATE_CLKCMU_CPUCL2_SWITCH		0x2068
+#define CLK_CON_GAT_GATE_CLKCMU_CSIS_BUS		0x206c
+#define CLK_CON_GAT_GATE_CLKCMU_DISP_BUS		0x2070
+#define CLK_CON_GAT_GATE_CLKCMU_DNS_BUS			0x2074
+#define CLK_CON_GAT_GATE_CLKCMU_DPU_BUS			0x2078
+#define CLK_CON_GAT_GATE_CLKCMU_EH_BUS			0x207c
+#define CLK_CON_GAT_GATE_CLKCMU_G2D_G2D			0x2080
+#define CLK_CON_GAT_GATE_CLKCMU_G2D_MSCL		0x2084
+#define CLK_CON_GAT_GATE_CLKCMU_G3AA_G3AA		0x2088
+#define CLK_CON_GAT_GATE_CLKCMU_G3D_BUSD		0x208c
+#define CLK_CON_GAT_GATE_CLKCMU_G3D_GLB			0x2090
+#define CLK_CON_GAT_GATE_CLKCMU_G3D_SWITCH		0x2094
+#define CLK_CON_GAT_GATE_CLKCMU_GDC_GDC0		0x2098
+#define CLK_CON_GAT_GATE_CLKCMU_GDC_GDC1		0x209c
+#define CLK_CON_GAT_GATE_CLKCMU_GDC_SCSC		0x20a0
+#define CLK_CON_GAT_GATE_CLKCMU_HPM			0x20a4
+#define CLK_CON_GAT_GATE_CLKCMU_HSI0_BUS		0x20a8
+#define CLK_CON_GAT_GATE_CLKCMU_HSI0_DPGTC		0x20ac
+#define CLK_CON_GAT_GATE_CLKCMU_HSI0_USB31DRD		0x20b0
+#define CLK_CON_GAT_GATE_CLKCMU_HSI0_USBDPDBG		0x20b4
+#define CLK_CON_GAT_GATE_CLKCMU_HSI1_BUS		0x20b8
+#define CLK_CON_GAT_GATE_CLKCMU_HSI1_PCIE		0x20bc
+#define CLK_CON_GAT_GATE_CLKCMU_HSI2_BUS		0x20c0
+#define CLK_CON_GAT_GATE_CLKCMU_HSI2_MMCCARD		0x20c4
+#define CLK_CON_GAT_GATE_CLKCMU_HSI2_PCIE		0x20c8
+#define CLK_CON_GAT_GATE_CLKCMU_HSI2_UFS_EMBD		0x20cc
+#define CLK_CON_GAT_GATE_CLKCMU_IPP_BUS			0x20d0
+#define CLK_CON_GAT_GATE_CLKCMU_ITP_BUS			0x20d4
+#define CLK_CON_GAT_GATE_CLKCMU_MCSC_ITSC		0x20d8
+#define CLK_CON_GAT_GATE_CLKCMU_MCSC_MCSC		0x20dc
+#define CLK_CON_GAT_GATE_CLKCMU_MFC_MFC			0x20e0
+#define CLK_CON_GAT_GATE_CLKCMU_MIF_BUSP		0x20e4
+#define CLK_CON_GAT_GATE_CLKCMU_MISC_BUS		0x20e8
+#define CLK_CON_GAT_GATE_CLKCMU_MISC_SSS		0x20ec
+#define CLK_CON_GAT_GATE_CLKCMU_PDP_BUS			0x20f0
+#define CLK_CON_GAT_GATE_CLKCMU_PDP_VRA			0x20f4
+#define CLK_CON_GAT_GATE_CLKCMU_PERIC0_BUS		0x20f8
+#define CLK_CON_GAT_GATE_CLKCMU_PERIC0_IP		0x20fc
+#define CLK_CON_GAT_GATE_CLKCMU_PERIC1_BUS		0x2100
+#define CLK_CON_GAT_GATE_CLKCMU_PERIC1_IP		0x2104
+#define CLK_CON_GAT_GATE_CLKCMU_TNR_BUS			0x2108
+#define CLK_CON_GAT_GATE_CLKCMU_TOP_CMUREF		0x210c
+#define CLK_CON_GAT_GATE_CLKCMU_TPU_BUS			0x2110
+#define CLK_CON_GAT_GATE_CLKCMU_TPU_TPU			0x2114
+#define CLK_CON_GAT_GATE_CLKCMU_TPU_TPUCTL		0x2118
+#define CLK_CON_GAT_GATE_CLKCMU_TPU_UART		0x211c
+
+#define DMYQCH_CON_CMU_TOP_CMUREF_QCH			0x3000
+#define DMYQCH_CON_DFTMUX_CMU_QCH_CIS_CLK0		0x3004
+#define DMYQCH_CON_DFTMUX_CMU_QCH_CIS_CLK1		0x3008
+#define DMYQCH_CON_DFTMUX_CMU_QCH_CIS_CLK2		0x300c
+#define DMYQCH_CON_DFTMUX_CMU_QCH_CIS_CLK3		0x3010
+#define DMYQCH_CON_DFTMUX_CMU_QCH_CIS_CLK4		0x3014
+#define DMYQCH_CON_DFTMUX_CMU_QCH_CIS_CLK5		0x3018
+#define DMYQCH_CON_DFTMUX_CMU_QCH_CIS_CLK6		0x301c
+#define DMYQCH_CON_DFTMUX_CMU_QCH_CIS_CLK7		0x3020
+#define DMYQCH_CON_OTP_QCH				0x3024
+#define QUEUE_CTRL_REG_BLK_CMU_CMU_TOP			0x3c00
+#define QUEUE_ENTRY0_BLK_CMU_CMU_TOP			0x3c10
+#define QUEUE_ENTRY1_BLK_CMU_CMU_TOP			0x3c14
+#define QUEUE_ENTRY2_BLK_CMU_CMU_TOP			0x3c18
+#define QUEUE_ENTRY3_BLK_CMU_CMU_TOP			0x3c1c
+#define QUEUE_ENTRY4_BLK_CMU_CMU_TOP			0x3c20
+#define QUEUE_ENTRY5_BLK_CMU_CMU_TOP			0x3c24
+#define QUEUE_ENTRY6_BLK_CMU_CMU_TOP			0x3c28
+#define QUEUE_ENTRY7_BLK_CMU_CMU_TOP			0x3c2c
+#define MIFMIRROR_QUEUE_CTRL_REG			0x3e00
+#define MIFMIRROR_QUEUE_ENTRY0				0x3e10
+#define MIFMIRROR_QUEUE_ENTRY1				0x3e14
+#define MIFMIRROR_QUEUE_ENTRY2				0x3e18
+#define MIFMIRROR_QUEUE_ENTRY3				0x3e1c
+#define MIFMIRROR_QUEUE_ENTRY4				0x3e20
+#define MIFMIRROR_QUEUE_ENTRY5				0x3e24
+#define MIFMIRROR_QUEUE_ENTRY6				0x3e28
+#define MIFMIRROR_QUEUE_ENTRY7				0x3e2c
+#define MIFMIRROR_QUEUE_BUSY				0x3e30
+#define GENERALIO_ACD_CHANNEL_0				0x3f00
+#define GENERALIO_ACD_CHANNEL_1				0x3f04
+#define GENERALIO_ACD_CHANNEL_2				0x3f08
+#define GENERALIO_ACD_CHANNEL_3				0x3f0c
+#define GENERALIO_ACD_MASK				0x3f14
+
+static const unsigned long cmu_top_clk_regs[] __initconst = {
+	PLL_LOCKTIME_PLL_SHARED0,
+	PLL_LOCKTIME_PLL_SHARED1,
+	PLL_LOCKTIME_PLL_SHARED2,
+	PLL_LOCKTIME_PLL_SHARED3,
+	PLL_LOCKTIME_PLL_SPARE,
+	PLL_CON0_PLL_SHARED0,
+	PLL_CON1_PLL_SHARED0,
+	PLL_CON2_PLL_SHARED0,
+	PLL_CON3_PLL_SHARED0,
+	PLL_CON4_PLL_SHARED0,
+	PLL_CON0_PLL_SHARED1,
+	PLL_CON1_PLL_SHARED1,
+	PLL_CON2_PLL_SHARED1,
+	PLL_CON3_PLL_SHARED1,
+	PLL_CON4_PLL_SHARED1,
+	PLL_CON0_PLL_SHARED2,
+	PLL_CON1_PLL_SHARED2,
+	PLL_CON2_PLL_SHARED2,
+	PLL_CON3_PLL_SHARED2,
+	PLL_CON4_PLL_SHARED2,
+	PLL_CON0_PLL_SHARED3,
+	PLL_CON1_PLL_SHARED3,
+	PLL_CON2_PLL_SHARED3,
+	PLL_CON3_PLL_SHARED3,
+	PLL_CON4_PLL_SHARED3,
+	PLL_CON0_PLL_SPARE,
+	PLL_CON1_PLL_SPARE,
+	PLL_CON2_PLL_SPARE,
+	PLL_CON3_PLL_SPARE,
+	PLL_CON4_PLL_SPARE,
+	CMU_CMU_TOP_CONTROLLER_OPTION,
+	CLKOUT_CON_BLK_CMU_CMU_TOP_CLKOUT0,
+	CMU_HCHGEN_CLKMUX_CMU_BOOST,
+	CMU_HCHGEN_CLKMUX_TOP_BOOST,
+	CMU_HCHGEN_CLKMUX,
+	POWER_FAIL_DETECT_PLL,
+	EARLY_WAKEUP_FORCED_0_ENABLE,
+	EARLY_WAKEUP_FORCED_1_ENABLE,
+	EARLY_WAKEUP_APM_CTRL,
+	EARLY_WAKEUP_CLUSTER0_CTRL,
+	EARLY_WAKEUP_DPU_CTRL,
+	EARLY_WAKEUP_CSIS_CTRL,
+	EARLY_WAKEUP_APM_DEST,
+	EARLY_WAKEUP_CLUSTER0_DEST,
+	EARLY_WAKEUP_DPU_DEST,
+	EARLY_WAKEUP_CSIS_DEST,
+	EARLY_WAKEUP_SW_TRIG_APM,
+	EARLY_WAKEUP_SW_TRIG_APM_SET,
+	EARLY_WAKEUP_SW_TRIG_APM_CLEAR,
+	EARLY_WAKEUP_SW_TRIG_CLUSTER0,
+	EARLY_WAKEUP_SW_TRIG_CLUSTER0_SET,
+	EARLY_WAKEUP_SW_TRIG_CLUSTER0_CLEAR,
+	EARLY_WAKEUP_SW_TRIG_DPU,
+	EARLY_WAKEUP_SW_TRIG_DPU_SET,
+	EARLY_WAKEUP_SW_TRIG_DPU_CLEAR,
+	EARLY_WAKEUP_SW_TRIG_CSIS,
+	EARLY_WAKEUP_SW_TRIG_CSIS_SET,
+	EARLY_WAKEUP_SW_TRIG_CSIS_CLEAR,
+	CLK_CON_MUX_MUX_CLKCMU_BO_BUS,
+	CLK_CON_MUX_MUX_CLKCMU_BUS0_BUS,
+	CLK_CON_MUX_MUX_CLKCMU_BUS1_BUS,
+	CLK_CON_MUX_MUX_CLKCMU_BUS2_BUS,
+	CLK_CON_MUX_MUX_CLKCMU_CIS_CLK0,
+	CLK_CON_MUX_MUX_CLKCMU_CIS_CLK1,
+	CLK_CON_MUX_MUX_CLKCMU_CIS_CLK2,
+	CLK_CON_MUX_MUX_CLKCMU_CIS_CLK3,
+	CLK_CON_MUX_MUX_CLKCMU_CIS_CLK4,
+	CLK_CON_MUX_MUX_CLKCMU_CIS_CLK5,
+	CLK_CON_MUX_MUX_CLKCMU_CIS_CLK6,
+	CLK_CON_MUX_MUX_CLKCMU_CIS_CLK7,
+	CLK_CON_MUX_MUX_CLKCMU_CMU_BOOST,
+	CLK_CON_MUX_MUX_CLKCMU_CMU_BOOST_OPTION1,
+	CLK_CON_MUX_MUX_CLKCMU_CORE_BUS,
+	CLK_CON_MUX_MUX_CLKCMU_CPUCL0_DBG,
+	CLK_CON_MUX_MUX_CLKCMU_CPUCL0_SWITCH,
+	CLK_CON_MUX_MUX_CLKCMU_CPUCL1_SWITCH,
+	CLK_CON_MUX_MUX_CLKCMU_CPUCL2_SWITCH,
+	CLK_CON_MUX_MUX_CLKCMU_CSIS_BUS,
+	CLK_CON_MUX_MUX_CLKCMU_DISP_BUS,
+	CLK_CON_MUX_MUX_CLKCMU_DNS_BUS,
+	CLK_CON_MUX_MUX_CLKCMU_DPU_BUS,
+	CLK_CON_MUX_MUX_CLKCMU_EH_BUS,
+	CLK_CON_MUX_MUX_CLKCMU_G2D_G2D,
+	CLK_CON_MUX_MUX_CLKCMU_G2D_MSCL,
+	CLK_CON_MUX_MUX_CLKCMU_G3AA_G3AA,
+	CLK_CON_MUX_MUX_CLKCMU_G3D_BUSD,
+	CLK_CON_MUX_MUX_CLKCMU_G3D_GLB,
+	CLK_CON_MUX_MUX_CLKCMU_G3D_SWITCH,
+	CLK_CON_MUX_MUX_CLKCMU_GDC_GDC0,
+	CLK_CON_MUX_MUX_CLKCMU_GDC_GDC1,
+	CLK_CON_MUX_MUX_CLKCMU_GDC_SCSC,
+	CLK_CON_MUX_MUX_CLKCMU_HPM,
+	CLK_CON_MUX_MUX_CLKCMU_HSI0_BUS,
+	CLK_CON_MUX_MUX_CLKCMU_HSI0_DPGTC,
+	CLK_CON_MUX_MUX_CLKCMU_HSI0_USB31DRD,
+	CLK_CON_MUX_MUX_CLKCMU_HSI0_USBDPDBG,
+	CLK_CON_MUX_MUX_CLKCMU_HSI1_BUS,
+	CLK_CON_MUX_MUX_CLKCMU_HSI1_PCIE,
+	CLK_CON_MUX_MUX_CLKCMU_HSI2_BUS,
+	CLK_CON_MUX_MUX_CLKCMU_HSI2_MMC_CARD,
+	CLK_CON_MUX_MUX_CLKCMU_HSI2_PCIE,
+	CLK_CON_MUX_MUX_CLKCMU_HSI2_UFS_EMBD,
+	CLK_CON_MUX_MUX_CLKCMU_IPP_BUS,
+	CLK_CON_MUX_MUX_CLKCMU_ITP_BUS,
+	CLK_CON_MUX_MUX_CLKCMU_MCSC_ITSC,
+	CLK_CON_MUX_MUX_CLKCMU_MCSC_MCSC,
+	CLK_CON_MUX_MUX_CLKCMU_MFC_MFC,
+	CLK_CON_MUX_MUX_CLKCMU_MIF_BUSP,
+	CLK_CON_MUX_MUX_CLKCMU_MIF_SWITCH,
+	CLK_CON_MUX_MUX_CLKCMU_MISC_BUS,
+	CLK_CON_MUX_MUX_CLKCMU_MISC_SSS,
+	CLK_CON_MUX_MUX_CLKCMU_PDP_BUS,
+	CLK_CON_MUX_MUX_CLKCMU_PDP_VRA,
+	CLK_CON_MUX_MUX_CLKCMU_PERIC0_BUS,
+	CLK_CON_MUX_MUX_CLKCMU_PERIC0_IP,
+	CLK_CON_MUX_MUX_CLKCMU_PERIC1_BUS,
+	CLK_CON_MUX_MUX_CLKCMU_PERIC1_IP,
+	CLK_CON_MUX_MUX_CLKCMU_TNR_BUS,
+	CLK_CON_MUX_MUX_CLKCMU_TOP_BOOST_OPTION1,
+	CLK_CON_MUX_MUX_CLKCMU_TOP_CMUREF,
+	CLK_CON_MUX_MUX_CLKCMU_TPU_BUS,
+	CLK_CON_MUX_MUX_CLKCMU_TPU_TPU,
+	CLK_CON_MUX_MUX_CLKCMU_TPU_TPUCTL,
+	CLK_CON_MUX_MUX_CLKCMU_TPU_UART,
+	CLK_CON_MUX_MUX_CMU_CMUREF,
+	CLK_CON_DIV_CLKCMU_BO_BUS,
+	CLK_CON_DIV_CLKCMU_BUS0_BUS,
+	CLK_CON_DIV_CLKCMU_BUS1_BUS,
+	CLK_CON_DIV_CLKCMU_BUS2_BUS,
+	CLK_CON_DIV_CLKCMU_CIS_CLK0,
+	CLK_CON_DIV_CLKCMU_CIS_CLK1,
+	CLK_CON_DIV_CLKCMU_CIS_CLK2,
+	CLK_CON_DIV_CLKCMU_CIS_CLK3,
+	CLK_CON_DIV_CLKCMU_CIS_CLK4,
+	CLK_CON_DIV_CLKCMU_CIS_CLK5,
+	CLK_CON_DIV_CLKCMU_CIS_CLK6,
+	CLK_CON_DIV_CLKCMU_CIS_CLK7,
+	CLK_CON_DIV_CLKCMU_CORE_BUS,
+	CLK_CON_DIV_CLKCMU_CPUCL0_DBG,
+	CLK_CON_DIV_CLKCMU_CPUCL0_SWITCH,
+	CLK_CON_DIV_CLKCMU_CPUCL1_SWITCH,
+	CLK_CON_DIV_CLKCMU_CPUCL2_SWITCH,
+	CLK_CON_DIV_CLKCMU_CSIS_BUS,
+	CLK_CON_DIV_CLKCMU_DISP_BUS,
+	CLK_CON_DIV_CLKCMU_DNS_BUS,
+	CLK_CON_DIV_CLKCMU_DPU_BUS,
+	CLK_CON_DIV_CLKCMU_EH_BUS,
+	CLK_CON_DIV_CLKCMU_G2D_G2D,
+	CLK_CON_DIV_CLKCMU_G2D_MSCL,
+	CLK_CON_DIV_CLKCMU_G3AA_G3AA,
+	CLK_CON_DIV_CLKCMU_G3D_BUSD,
+	CLK_CON_DIV_CLKCMU_G3D_GLB,
+	CLK_CON_DIV_CLKCMU_G3D_SWITCH,
+	CLK_CON_DIV_CLKCMU_GDC_GDC0,
+	CLK_CON_DIV_CLKCMU_GDC_GDC1,
+	CLK_CON_DIV_CLKCMU_GDC_SCSC,
+	CLK_CON_DIV_CLKCMU_HPM,
+	CLK_CON_DIV_CLKCMU_HSI0_BUS,
+	CLK_CON_DIV_CLKCMU_HSI0_DPGTC,
+	CLK_CON_DIV_CLKCMU_HSI0_USB31DRD,
+	CLK_CON_DIV_CLKCMU_HSI0_USBDPDBG,
+	CLK_CON_DIV_CLKCMU_HSI1_BUS,
+	CLK_CON_DIV_CLKCMU_HSI1_PCIE,
+	CLK_CON_DIV_CLKCMU_HSI2_BUS,
+	CLK_CON_DIV_CLKCMU_HSI2_MMC_CARD,
+	CLK_CON_DIV_CLKCMU_HSI2_PCIE,
+	CLK_CON_DIV_CLKCMU_HSI2_UFS_EMBD,
+	CLK_CON_DIV_CLKCMU_IPP_BUS,
+	CLK_CON_DIV_CLKCMU_ITP_BUS,
+	CLK_CON_DIV_CLKCMU_MCSC_ITSC,
+	CLK_CON_DIV_CLKCMU_MCSC_MCSC,
+	CLK_CON_DIV_CLKCMU_MFC_MFC,
+	CLK_CON_DIV_CLKCMU_MIF_BUSP,
+	CLK_CON_DIV_CLKCMU_MISC_BUS,
+	CLK_CON_DIV_CLKCMU_MISC_SSS,
+	CLK_CON_DIV_CLKCMU_OTP,
+	CLK_CON_DIV_CLKCMU_PDP_BUS,
+	CLK_CON_DIV_CLKCMU_PDP_VRA,
+	CLK_CON_DIV_CLKCMU_PERIC0_BUS,
+	CLK_CON_DIV_CLKCMU_PERIC0_IP,
+	CLK_CON_DIV_CLKCMU_PERIC1_BUS,
+	CLK_CON_DIV_CLKCMU_PERIC1_IP,
+	CLK_CON_DIV_CLKCMU_TNR_BUS,
+	CLK_CON_DIV_CLKCMU_TPU_BUS,
+	CLK_CON_DIV_CLKCMU_TPU_TPU,
+	CLK_CON_DIV_CLKCMU_TPU_TPUCTL,
+	CLK_CON_DIV_CLKCMU_TPU_UART,
+	CLK_CON_DIV_DIV_CLKCMU_CMU_BOOST,
+	CLK_CON_DIV_DIV_CLK_CMU_CMUREF,
+	CLK_CON_DIV_PLL_SHARED0_DIV2,
+	CLK_CON_DIV_PLL_SHARED0_DIV3,
+	CLK_CON_DIV_PLL_SHARED0_DIV4,
+	CLK_CON_DIV_PLL_SHARED0_DIV5,
+	CLK_CON_DIV_PLL_SHARED1_DIV2,
+	CLK_CON_DIV_PLL_SHARED1_DIV3,
+	CLK_CON_DIV_PLL_SHARED1_DIV4,
+	CLK_CON_DIV_PLL_SHARED2_DIV2,
+	CLK_CON_DIV_PLL_SHARED3_DIV2,
+	CLK_CON_GAT_CLKCMU_BUS0_BOOST,
+	CLK_CON_GAT_CLKCMU_BUS1_BOOST,
+	CLK_CON_GAT_CLKCMU_BUS2_BOOST,
+	CLK_CON_GAT_CLKCMU_CORE_BOOST,
+	CLK_CON_GAT_CLKCMU_CPUCL0_BOOST,
+	CLK_CON_GAT_CLKCMU_CPUCL1_BOOST,
+	CLK_CON_GAT_CLKCMU_CPUCL2_BOOST,
+	CLK_CON_GAT_CLKCMU_MIF_BOOST,
+	CLK_CON_GAT_CLKCMU_MIF_SWITCH,
+	CLK_CON_GAT_GATE_CLKCMU_BO_BUS,
+	CLK_CON_GAT_GATE_CLKCMU_BUS0_BUS,
+	CLK_CON_GAT_GATE_CLKCMU_BUS1_BUS,
+	CLK_CON_GAT_GATE_CLKCMU_BUS2_BUS,
+	CLK_CON_GAT_GATE_CLKCMU_CIS_CLK0,
+	CLK_CON_GAT_GATE_CLKCMU_CIS_CLK1,
+	CLK_CON_GAT_GATE_CLKCMU_CIS_CLK2,
+	CLK_CON_GAT_GATE_CLKCMU_CIS_CLK3,
+	CLK_CON_GAT_GATE_CLKCMU_CIS_CLK4,
+	CLK_CON_GAT_GATE_CLKCMU_CIS_CLK5,
+	CLK_CON_GAT_GATE_CLKCMU_CIS_CLK6,
+	CLK_CON_GAT_GATE_CLKCMU_CIS_CLK7,
+	CLK_CON_GAT_GATE_CLKCMU_CMU_BOOST,
+	CLK_CON_GAT_GATE_CLKCMU_CORE_BUS,
+	CLK_CON_GAT_GATE_CLKCMU_CPUCL0_DBG_BUS,
+	CLK_CON_GAT_GATE_CLKCMU_CPUCL0_SWITCH,
+	CLK_CON_GAT_GATE_CLKCMU_CPUCL1_SWITCH,
+	CLK_CON_GAT_GATE_CLKCMU_CPUCL2_SWITCH,
+	CLK_CON_GAT_GATE_CLKCMU_CSIS_BUS,
+	CLK_CON_GAT_GATE_CLKCMU_DISP_BUS,
+	CLK_CON_GAT_GATE_CLKCMU_DNS_BUS,
+	CLK_CON_GAT_GATE_CLKCMU_DPU_BUS,
+	CLK_CON_GAT_GATE_CLKCMU_EH_BUS,
+	CLK_CON_GAT_GATE_CLKCMU_G2D_G2D,
+	CLK_CON_GAT_GATE_CLKCMU_G2D_MSCL,
+	CLK_CON_GAT_GATE_CLKCMU_G3AA_G3AA,
+	CLK_CON_GAT_GATE_CLKCMU_G3D_BUSD,
+	CLK_CON_GAT_GATE_CLKCMU_G3D_GLB,
+	CLK_CON_GAT_GATE_CLKCMU_G3D_SWITCH,
+	CLK_CON_GAT_GATE_CLKCMU_GDC_GDC0,
+	CLK_CON_GAT_GATE_CLKCMU_GDC_GDC1,
+	CLK_CON_GAT_GATE_CLKCMU_GDC_SCSC,
+	CLK_CON_GAT_GATE_CLKCMU_HPM,
+	CLK_CON_GAT_GATE_CLKCMU_HSI0_BUS,
+	CLK_CON_GAT_GATE_CLKCMU_HSI0_DPGTC,
+	CLK_CON_GAT_GATE_CLKCMU_HSI0_USB31DRD,
+	CLK_CON_GAT_GATE_CLKCMU_HSI0_USBDPDBG,
+	CLK_CON_GAT_GATE_CLKCMU_HSI1_BUS,
+	CLK_CON_GAT_GATE_CLKCMU_HSI1_PCIE,
+	CLK_CON_GAT_GATE_CLKCMU_HSI2_BUS,
+	CLK_CON_GAT_GATE_CLKCMU_HSI2_MMCCARD,
+	CLK_CON_GAT_GATE_CLKCMU_HSI2_PCIE,
+	CLK_CON_GAT_GATE_CLKCMU_HSI2_UFS_EMBD,
+	CLK_CON_GAT_GATE_CLKCMU_IPP_BUS,
+	CLK_CON_GAT_GATE_CLKCMU_ITP_BUS,
+	CLK_CON_GAT_GATE_CLKCMU_MCSC_ITSC,
+	CLK_CON_GAT_GATE_CLKCMU_MCSC_MCSC,
+	CLK_CON_GAT_GATE_CLKCMU_MFC_MFC,
+	CLK_CON_GAT_GATE_CLKCMU_MIF_BUSP,
+	CLK_CON_GAT_GATE_CLKCMU_MISC_BUS,
+	CLK_CON_GAT_GATE_CLKCMU_MISC_SSS,
+	CLK_CON_GAT_GATE_CLKCMU_PDP_BUS,
+	CLK_CON_GAT_GATE_CLKCMU_PDP_VRA,
+	CLK_CON_GAT_GATE_CLKCMU_PERIC0_BUS,
+	CLK_CON_GAT_GATE_CLKCMU_PERIC0_IP,
+	CLK_CON_GAT_GATE_CLKCMU_PERIC1_BUS,
+	CLK_CON_GAT_GATE_CLKCMU_PERIC1_IP,
+	CLK_CON_GAT_GATE_CLKCMU_TNR_BUS,
+	CLK_CON_GAT_GATE_CLKCMU_TOP_CMUREF,
+	CLK_CON_GAT_GATE_CLKCMU_TPU_BUS,
+	CLK_CON_GAT_GATE_CLKCMU_TPU_TPU,
+	CLK_CON_GAT_GATE_CLKCMU_TPU_TPUCTL,
+	CLK_CON_GAT_GATE_CLKCMU_TPU_UART,
+	DMYQCH_CON_CMU_TOP_CMUREF_QCH,
+	DMYQCH_CON_DFTMUX_CMU_QCH_CIS_CLK0,
+	DMYQCH_CON_DFTMUX_CMU_QCH_CIS_CLK1,
+	DMYQCH_CON_DFTMUX_CMU_QCH_CIS_CLK2,
+	DMYQCH_CON_DFTMUX_CMU_QCH_CIS_CLK3,
+	DMYQCH_CON_DFTMUX_CMU_QCH_CIS_CLK4,
+	DMYQCH_CON_DFTMUX_CMU_QCH_CIS_CLK5,
+	DMYQCH_CON_DFTMUX_CMU_QCH_CIS_CLK6,
+	DMYQCH_CON_DFTMUX_CMU_QCH_CIS_CLK7,
+	DMYQCH_CON_OTP_QCH,
+	QUEUE_CTRL_REG_BLK_CMU_CMU_TOP,
+	QUEUE_ENTRY0_BLK_CMU_CMU_TOP,
+	QUEUE_ENTRY1_BLK_CMU_CMU_TOP,
+	QUEUE_ENTRY2_BLK_CMU_CMU_TOP,
+	QUEUE_ENTRY3_BLK_CMU_CMU_TOP,
+	QUEUE_ENTRY4_BLK_CMU_CMU_TOP,
+	QUEUE_ENTRY5_BLK_CMU_CMU_TOP,
+	QUEUE_ENTRY6_BLK_CMU_CMU_TOP,
+	QUEUE_ENTRY7_BLK_CMU_CMU_TOP,
+	MIFMIRROR_QUEUE_CTRL_REG,
+	MIFMIRROR_QUEUE_ENTRY0,
+	MIFMIRROR_QUEUE_ENTRY1,
+	MIFMIRROR_QUEUE_ENTRY2,
+	MIFMIRROR_QUEUE_ENTRY3,
+	MIFMIRROR_QUEUE_ENTRY4,
+	MIFMIRROR_QUEUE_ENTRY5,
+	MIFMIRROR_QUEUE_ENTRY6,
+	MIFMIRROR_QUEUE_ENTRY7,
+	MIFMIRROR_QUEUE_BUSY,
+	GENERALIO_ACD_CHANNEL_0,
+	GENERALIO_ACD_CHANNEL_1,
+	GENERALIO_ACD_CHANNEL_2,
+	GENERALIO_ACD_CHANNEL_3,
+	GENERALIO_ACD_MASK,
+};
+
+static const struct samsung_pll_clock cmu_top_pll_clks[] __initconst = {
+	/* CMU_TOP_PURECLKCOMP */
+	PLL(pll_0517x, CLK_FOUT_SHARED0_PLL, "fout_shared0_pll", "oscclk",
+	    PLL_LOCKTIME_PLL_SHARED0, PLL_CON3_PLL_SHARED0,
+	    NULL),
+	PLL(pll_0517x, CLK_FOUT_SHARED1_PLL, "fout_shared1_pll", "oscclk",
+	    PLL_LOCKTIME_PLL_SHARED1, PLL_CON3_PLL_SHARED1,
+	    NULL),
+	PLL(pll_0518x, CLK_FOUT_SHARED2_PLL, "fout_shared2_pll", "oscclk",
+	    PLL_LOCKTIME_PLL_SHARED2, PLL_CON3_PLL_SHARED2,
+	    NULL),
+	PLL(pll_0518x, CLK_FOUT_SHARED3_PLL, "fout_shared3_pll", "oscclk",
+	    PLL_LOCKTIME_PLL_SHARED3, PLL_CON3_PLL_SHARED3,
+	    NULL),
+	PLL(pll_0518x, CLK_FOUT_SPARE_PLL, "fout_spare_pll", "oscclk",
+	    PLL_LOCKTIME_PLL_SPARE, PLL_CON3_PLL_SPARE,
+	    NULL),
+};
+
+/* List of parent clocks for Muxes in CMU_TOP */
+PNAME(mout_shared0_pll_p)	= { "oscclk", "fout_shared0_pll" };
+PNAME(mout_shared1_pll_p)	= { "oscclk", "fout_shared1_pll" };
+PNAME(mout_shared2_pll_p)	= { "oscclk", "fout_shared2_pll" };
+PNAME(mout_shared3_pll_p)	= { "oscclk", "fout_shared3_pll" };
+PNAME(mout_spare_pll_p)		= { "oscclk", "fout_spare_pll" };
+
+/* List of parent clocks for Muxes in CMU_TOP: for CMU_BUS0 */
+PNAME(mout_cmu_bus0_bus_p)	= { "dout_shared0_div4", "dout_shared1_div4",
+				    "dout_shared2_div2", "dout_shared3_div2",
+				    "fout_spare_pll" };
+
+PNAME(mout_cmu_cmu_boost_p)	= { "dout_shared0_div4", "dout_shared1_div4",
+				    "dout_shared2_div2", "dout_shared3_div2" };
+
+/* List of parent clocks for Muxes in CMU_TOP: for CMU_BUS1 */
+PNAME(mout_cmu_bus1_bus_p)	= { "dout_shared0_div3", "fout_shared3_pll",
+				    "dout_shared1_div3", "dout_shared0_div4",
+				    "dout_shared1_div4", "dout_shared2_div2",
+				    "fout_spare_pll" };
+
+/* List of parent clocks for Muxes in CMU_TOP: for CMU_BUS2 */
+PNAME(mout_cmu_bus2_bus_p)	= { "dout_shared0_div2", "dout_shared1_div2",
+				    "fout_shared2_pll", "fout_shared3_pll",
+				    "dout_shared0_div3", "dout_shared1_div3",
+				    "dout_shared0_div5", "fout_spare_pll" };
+
+/* List of parent clocks for Muxes in CMU_TOP: for CMU_CORE */
+PNAME(mout_cmu_core_bus_p)	= { "dout_shared0_div2", "dout_shared1_div2",
+				    "fout_shared2_pll", "fout_shared3_pll",
+				    "dout_shared0_div3", "dout_shared1_div3",
+				    "dout_shared0_div5", "fout_spare_pll" };
+
+/* List of parent clocks for Muxes in CMU_TOP: for CMU_EH */
+PNAME(mout_cmu_eh_bus_p)	= { "dout_shared0_div2", "dout_shared1_div2",
+				    "fout_shared2_pll", "fout_shared3_pll",
+				    "dout_shared0_div3", "dout_shared1_div3",
+				    "dout_shared0_div5", "fout_spare_pll" };
+
+/* List of parent clocks for Muxes in CMU_TOP: for CMU_CPUCL2 */
+PNAME(mout_cmu_cpucl2_switch_p)	= { "fout_shared1_pll", "dout_shared0_div2",
+				    "dout_shared1_div2", "fout_shared2_pll",
+				    "fout_shared3_pll", "dout_shared0_div3",
+				    "dout_shared1_div3", "fout_spare_pll" };
+
+/* List of parent clocks for Muxes in CMU_TOP: for CMU_CPUCL1 */
+PNAME(mout_cmu_cpucl1_switch_p)	= { "fout_shared1_pll", "dout_shared0_div2",
+				    "dout_shared1_div2", "fout_shared2_pll",
+				    "fout_shared3_pll", "dout_shared0_div3",
+				    "dout_shared1_div3", "fout_spare_pll" };
+
+/* List of parent clocks for Muxes in CMU_TOP: for CMU_CPUCL0 */
+PNAME(mout_cmu_cpucl0_switch_p)	= { "fout_shared1_pll", "dout_shared0_div2",
+				    "dout_shared1_div2", "fout_shared2_pll",
+				    "fout_shared3_pll", "dout_shared0_div3",
+				    "dout_shared1_div3", "fout_spare_pll" };
+
+PNAME(mout_cmu_cpucl0_dbg_p)	= { "fout_shared2_pll", "fout_shared3_pll",
+				    "dout_shared0_div4", "dout_shared1_div4",
+				    "dout_shared2_div2", "fout_spare_pll" };
+
+PNAME(mout_cmu_hpm_p)		= { "oscclk", "dout_shared1_div3",
+				    "dout_shared0_div4", "dout_shared2_div2" };
+
+/* List of parent clocks for Muxes in CMU_TOP: for CMU_G3D */
+PNAME(mout_cmu_g3d_switch_p)	= { "fout_shared2_pll", "dout_shared0_div3",
+				    "fout_shared3_pll", "dout_shared1_div3",
+				    "dout_shared0_div4", "dout_shared1_div4",
+				    "fout_spare_pll" };
+
+PNAME(mout_cmu_g3d_busd_p)	= { "dout_shared0_div2", "dout_shared1_div2",
+				    "fout_shared2_pll", "fout_shared3_pll",
+				    "dout_shared0_div3", "dout_shared1_div3",
+				    "dout_shared0_div4", "fout_spare_pll" };
+
+PNAME(mout_cmu_g3d_glb_p)	= { "dout_shared0_div2", "dout_shared1_div2",
+				    "fout_shared2_pll", "fout_shared3_pll",
+				    "dout_shared0_div3", "dout_shared1_div3",
+				    "dout_shared0_div4", "fout_spare_pll" };
+
+/* List of parent clocks for Muxes in CMU_TOP: for CMU_DPU */
+PNAME(mout_cmu_dpu_p)		= { "dout_shared0_div3", "fout_shared3_pll",
+				    "dout_shared1_div3", "dout_shared0_div4",
+				    "dout_shared1_div4", "dout_shared2_div2",
+				    "fout_spare_pll" };
+
+/* List of parent clocks for Muxes in CMU_TOP: for CMU_DISP */
+PNAME(mout_cmu_disp_bus_p)	= { "dout_shared0_div3", "fout_shared3_pll",
+				    "dout_shared1_div3", "dout_shared0_div4",
+				    "dout_shared1_div4", "dout_shared2_div2",
+				    "fout_spare_pll" };
+
+/* List of parent clocks for Muxes in CMU_TOP: for CMU_G2D */
+PNAME(mout_cmu_g2d_g2d_p)	= { "dout_shared0_div3", "fout_shared3_pll",
+				    "dout_shared1_div3", "dout_shared0_div4",
+				    "dout_shared1_div4", "dout_shared2_div2",
+				    "fout_spare_pll" };
+
+PNAME(mout_cmu_g2d_mscl_p)	= { "dout_shared0_div4", "dout_shared1_div4",
+				    "dout_shared2_div2", "dout_shared3_div2",
+				    "fout_spare_pll" };
+
+/* List of parent clocks for Muxes in CMU_TOP: for CMU_HSI0 */
+PNAME(mout_cmu_hsi0_usb31drd_p)	= { "oscclk", "dout_shared2_div2" };
+
+PNAME(mout_cmu_hsi0_bus_p)	= { "dout_shared0_div4", "dout_shared1_div4",
+				    "dout_shared2_div2", "dout_shared3_div2",
+				    "fout_spare_pll" };
+
+PNAME(mout_cmu_hsi0_dpgtc_p)	= { "oscclk", "dout_shared0_div4",
+				    "dout_shared2_div2", "fout_spare_pll" };
+
+PNAME(mout_cmu_hsi0_usbdpdbg_p)	= { "oscclk", "dout_shared2_div2" };
+
+/* List of parent clocks for Muxes in CMU_TOP: for CMU_HSI1 */
+PNAME(mout_cmu_hsi1_bus_p)	= { "dout_shared0_div4", "dout_shared1_div4",
+				    "dout_shared2_div2", "dout_shared3_div2",
+				    "fout_spare_pll" };
+
+PNAME(mout_cmu_hsi1_pcie_p)	= { "oscclk", "dout_shared2_div2" };
+
+/* List of parent clocks for Muxes in CMU_TOP: for CMU_HSI2 */
+PNAME(mout_cmu_hsi2_bus_p)	= { "dout_shared0_div4", "dout_shared1_div4",
+				    "dout_shared2_div2", "dout_shared3_div2",
+				    "fout_spare_pll" };
+
+PNAME(mout_cmu_hsi2_pcie0_p)	= { "oscclk", "dout_shared2_div2" };
+
+PNAME(mout_cmu_hsi2_ufs_embd_p)	= { "oscclk", "dout_shared0_div4",
+				    "dout_shared2_div2", "fout_spare_pll" };
+
+PNAME(mout_cmu_hsi2_mmc_card_p)	= { "fout_shared2_pll", "fout_shared3_pll",
+				    "dout_shared0_div4", "fout_spare_pll" };
+
+/* List of parent clocks for Muxes in CMU_TOP: for CMU_CSIS */
+PNAME(mout_cmu_csis_bus_p)	= { "dout_shared0_div3", "fout_shared3_pll",
+				    "dout_shared1_div3", "dout_shared0_div4",
+				    "dout_shared1_div4", "dout_shared2_div2",
+				    "fout_spare_pll" };
+
+/* List of parent clocks for Muxes in CMU_TOP: for CMU_PDP */
+PNAME(mout_cmu_pdp_bus_p)	= { "dout_shared0_div3", "fout_shared3_pll",
+				    "dout_shared1_div3", "dout_shared0_div4",
+				    "dout_shared1_div4", "dout_shared2_div2",
+				    "fout_spare_pll" };
+
+PNAME(mout_cmu_pdp_vra_p)	= { "fout_shared2_pll", "dout_shared0_div3",
+				    "fout_shared3_pll", "dout_shared1_div3",
+				    "dout_shared0_div4", "dout_shared1_div4",
+				    "fout_spare_pll" };
+
+/* List of parent clocks for Muxes in CMU_TOP: for CMU_IPP */
+PNAME(mout_cmu_ipp_bus_p)	= { "dout_shared0_div3", "fout_shared3_pll",
+				    "dout_shared1_div3", "dout_shared0_div4",
+				    "dout_shared1_div4", "dout_shared2_div2",
+				    "fout_spare_pll" };
+
+/* List of parent clocks for Muxes in CMU_TOP: for CMU_G3AA */
+PNAME(mout_cmu_g3aa_p)		= { "dout_shared0_div3", "fout_shared3_pll",
+				    "dout_shared1_div3", "dout_shared0_div4",
+				    "dout_shared1_div4", "dout_shared2_div2",
+				    "fout_spare_pll" };
+
+/* List of parent clocks for Muxes in CMU_TOP: for CMU_ITP */
+PNAME(mout_cmu_itp_bus_p)	= { "dout_shared0_div3", "fout_shared3_pll",
+				    "dout_shared1_div3", "dout_shared0_div4",
+				    "dout_shared1_div4", "dout_shared2_div2",
+				    "fout_spare_pll" };
+
+/* List of parent clocks for Muxes in CMU_TOP: for CMU_DNS */
+PNAME(mout_cmu_dns_bus_p)	= { "dout_shared0_div3", "fout_shared3_pll",
+				    "dout_shared1_div3", "dout_shared0_div4",
+				    "dout_shared1_div4", "dout_shared2_div2",
+				    "fout_spare_pll" };
+
+/* List of parent clocks for Muxes in CMU_TOP: for CMU_TNR */
+PNAME(mout_cmu_tnr_bus_p)	= { "dout_shared0_div3", "fout_shared3_pll",
+				    "dout_shared1_div3", "dout_shared0_div4",
+				    "dout_shared1_div4", "dout_shared2_div2",
+				    "fout_spare_pll" };
+
+/* List of parent clocks for Muxes in CMU_TOP: for CMU_MCSC */
+PNAME(mout_cmu_mcsc_itsc_p)	= { "dout_shared0_div3", "fout_shared3_pll",
+				    "dout_shared1_div3", "dout_shared0_div4",
+				    "dout_shared1_div4", "dout_shared2_div2",
+				    "fout_spare_pll" };
+
+PNAME(mout_cmu_mcsc_mcsc_p)	= { "dout_shared0_div3", "fout_shared3_pll",
+				    "dout_shared1_div3", "dout_shared0_div4",
+				    "dout_shared1_div4", "dout_shared2_div2",
+				    "fout_spare_pll" };
+
+/* List of parent clocks for Muxes in CMU_TOP: for CMU_GDC */
+PNAME(mout_cmu_gdc_scsc_p)	= { "dout_shared0_div3", "fout_shared3_pll",
+				    "dout_shared1_div3", "dout_shared0_div4",
+				    "dout_shared1_div4", "dout_shared2_div2",
+				    "fout_spare_pll" };
+
+PNAME(mout_cmu_gdc_gdc0_p)	= { "dout_shared0_div3", "fout_shared3_pll",
+				    "dout_shared1_div3", "dout_shared0_div4",
+				    "dout_shared1_div4", "dout_shared2_div2",
+				    "fout_spare_pll" };
+
+PNAME(mout_cmu_gdc_gdc1_p)	= { "dout_shared0_div3", "fout_shared3_pll",
+				    "dout_shared1_div3", "dout_shared0_div4",
+				    "dout_shared1_div4", "dout_shared2_div2",
+				    "fout_spare_pll" };
+
+/* List of parent clocks for Muxes in CMU_TOP: for CMU_MFC */
+PNAME(mout_cmu_mfc_mfc_p)	= { "dout_shared0_div3", "fout_shared3_pll",
+				    "dout_shared1_div3", "dout_shared0_div4",
+				    "dout_shared1_div4", "dout_shared2_div2",
+				    "fout_spare_pll" };
+
+/* List of parent clocks for Muxes in CMU_TOP: for DDRPHY0/1/2/3 */
+
+PNAME(mout_cmu_mif_switch_p)	= { "fout_shared0_pll", "fout_shared1_pll",
+				    "dout_shared0_div2", "dout_shared1_div2",
+				    "fout_shared2_pll", "dout_shared0_div3",
+				    "fout_shared3_pll", "fout_spare_pll" };
+
+/* List of parent clocks for Muxes in CMU_TOP: for CMU_MIF0/1/2/3 */
+PNAME(mout_cmu_mif_busp_p)	= { "dout_shared0_div4", "dout_shared1_div4",
+				    "dout_shared0_div5", "fout_spare_pll" };
+
+/* List of parent clocks for Muxes in CMU_TOP: for CMU_MISC */
+PNAME(mout_cmu_misc_bus_p)	= { "dout_shared0_div4", "dout_shared2_div2",
+				    "dout_shared3_div2", "fout_spare_pll" };
+PNAME(mout_cmu_misc_sss_p)	= { "dout_shared0_div4", "dout_shared2_div2",
+				    "dout_shared3_div2", "fout_spare_pll" };
+
+/* List of parent clocks for Muxes in CMU_TOP: for CMU_PERIC0 */
+PNAME(mout_cmu_peric0_bus_p)	= { "dout_shared0_div4", "dout_shared2_div2",
+				    "dout_shared3_div2", "fout_spare_pll" };
+PNAME(mout_cmu_peric0_ip_p)	= { "dout_shared0_div4", "dout_shared2_div2",
+				    "dout_shared3_div2", "fout_spare_pll" };
+
+/* List of parent clocks for Muxes in CMU_TOP: for CMU_PERIC1 */
+PNAME(mout_cmu_peric1_bus_p)	= { "dout_shared0_div4", "dout_shared2_div2",
+				    "dout_shared3_div2", "fout_spare_pll" };
+PNAME(mout_cmu_peric1_ip_p)	= { "dout_shared0_div4", "dout_shared2_div2",
+				    "dout_shared3_div2", "fout_spare_pll" };
+
+/* List of parent clocks for Muxes in CMU_TOP: for CMU_TPU */
+PNAME(mout_cmu_tpu_tpu_p)	= { "dout_shared0_div2", "dout_shared1_div2",
+				    "fout_shared2_pll", "fout_shared3_pll",
+				    "dout_shared0_div3", "dout_shared1_div3",
+				    "dout_shared0_div4", "fout_spare_pll" };
+
+PNAME(mout_cmu_tpu_tpuctl_p)	= { "dout_shared0_div2", "dout_shared1_div2",
+				    "fout_shared2_pll", "fout_shared3_pll",
+				    "dout_shared0_div3", "dout_shared1_div3",
+				    "dout_shared0_div4", "fout_spare_pll" };
+
+PNAME(mout_cmu_tpu_bus_p)	= { "dout_shared0_div2", "dout_shared1_div2",
+				    "fout_shared2_pll", "fout_shared3_pll",
+				    "dout_shared0_div3", "dout_shared1_div3",
+				    "dout_shared0_div4", "fout_spare_pll" };
+
+PNAME(mout_cmu_tpu_uart_p)	= { "dout_shared0_div4", "dout_shared2_div2",
+				    "dout_shared3_div2", "fout_spare_pll" };
+
+/* List of parent clocks for Muxes in CMU_TOP: for CMU_BO */
+PNAME(mout_cmu_bo_bus_p)	= { "fout_shared2_pll", "dout_shared0_div3",
+				    "fout_shared3_pll", "dout_shared1_div3",
+				    "dout_shared0_div4", "dout_shared1_div4",
+				    "fout_spare_pll" };
+
+/* gs101 */
+static const struct samsung_mux_clock cmu_top_mux_clks[] __initconst = {
+	/* CMU_TOP_PURECLKCOMP */
+	MUX(CLK_MOUT_SHARED0_PLL, "mout_shared0_pll", mout_shared0_pll_p,
+	    PLL_CON0_PLL_SHARED0, 4, 1),
+	MUX(CLK_MOUT_SHARED1_PLL, "mout_shared1_pll", mout_shared1_pll_p,
+	    PLL_CON0_PLL_SHARED1, 4, 1),
+	MUX(CLK_MOUT_SHARED2_PLL, "mout_shared2_pll", mout_shared2_pll_p,
+	    PLL_CON0_PLL_SHARED2, 4, 1),
+	MUX(CLK_MOUT_SHARED3_PLL, "mout_shared3_pll", mout_shared3_pll_p,
+	    PLL_CON0_PLL_SHARED3, 4, 1),
+	MUX(CLK_MOUT_SPARE_PLL, "mout_spare_pll", mout_spare_pll_p,
+	    PLL_CON0_PLL_SPARE, 4, 1),
+
+	/* BUS0 */
+	MUX(CLK_MOUT_BUS0_BUS, "mout_cmu_bus0_bus", mout_cmu_bus0_bus_p,
+	    CLK_CON_MUX_MUX_CLKCMU_BUS0_BUS, 0, 2),
+	MUX(CLK_MOUT_CMU_BOOST, "mout_cmu_boost", mout_cmu_cmu_boost_p,
+	    CLK_CON_MUX_MUX_CLKCMU_CMU_BOOST, 0, 2),
+
+	/* BUS1 */
+	MUX(CLK_MOUT_BUS1_BUS, "mout_cmu_bus1_bus", mout_cmu_bus1_bus_p,
+	    CLK_CON_MUX_MUX_CLKCMU_BUS1_BUS, 0, 2),
+
+	/* BUS2 */
+	MUX(CLK_MOUT_BUS2_BUS, "mout_cmu_bus2_bus", mout_cmu_bus2_bus_p,
+	    CLK_CON_MUX_MUX_CLKCMU_BUS2_BUS, 0, 2),
+
+	/* CORE */
+	MUX(CLK_MOUT_CORE_BUS, "mout_cmu_core_bus", mout_cmu_core_bus_p,
+	    CLK_CON_MUX_MUX_CLKCMU_CORE_BUS, 0, 2),
+
+	/* EH */
+	MUX(CLK_MOUT_EH_BUS, "mout_cmu_eh_bus", mout_cmu_eh_bus_p,
+	    CLK_CON_MUX_MUX_CLKCMU_CORE_BUS, 0, 2),
+
+	/* CPUCL{0,1,2,} */
+	MUX(CLK_MOUT_CPUCL2_SWITCH, "mout_cmu_cpucl2_switch", mout_cmu_cpucl2_switch_p,
+	    CLK_CON_MUX_MUX_CLKCMU_CPUCL2_SWITCH, 0, 2),
+
+	MUX(CLK_MOUT_CPUCL1_SWITCH, "mout_cmu_cpucl1_switch", mout_cmu_cpucl1_switch_p,
+	    CLK_CON_MUX_MUX_CLKCMU_CPUCL1_SWITCH, 0, 2),
+
+	MUX(CLK_MOUT_CPUCL0_SWITCH, "mout_cmu_cpucl0_switch", mout_cmu_cpucl0_switch_p,
+	    CLK_CON_MUX_MUX_CLKCMU_CPUCL0_SWITCH, 0, 2),
+
+	MUX(CLK_MOUT_CPUCL0_DBG, "mout_cmu_cpucl0_dbg", mout_cmu_cpucl0_dbg_p,
+	    CLK_CON_DIV_CLKCMU_CPUCL0_DBG, 0, 2),
+
+	MUX(CLK_MOUT_CMU_HPM, "mout_cmu_hpm", mout_cmu_hpm_p,
+	    CLK_CON_MUX_MUX_CLKCMU_HPM, 0, 2),
+
+	/* G3D */
+	MUX(CLK_MOUT_G3D_SWITCH, "mout_cmu_g3d_switch", mout_cmu_g3d_switch_p,
+	    CLK_CON_MUX_MUX_CLKCMU_G3D_SWITCH, 0, 2),
+
+	MUX(CLK_MOUT_G3D_BUSD, "mout_cmu_g3d_busd", mout_cmu_g3d_busd_p,
+	    CLK_CON_MUX_MUX_CLKCMU_G3D_BUSD, 0, 2),
+
+	MUX(CLK_MOUT_G3D_GLB, "mout_cmu_g3d_glb", mout_cmu_g3d_glb_p,
+	    CLK_CON_MUX_MUX_CLKCMU_G3D_GLB, 0, 2),
+	/* DPU */
+	MUX(CLK_MOUT_DPU_BUS, "mout_cmu_dpu_bus", mout_cmu_dpu_p,
+	    CLK_CON_MUX_MUX_CLKCMU_DPU_BUS, 0, 2),
+
+	/* DISP */
+	MUX(CLK_MOUT_DISP_BUS, "mout_cmu_disp_bus", mout_cmu_disp_bus_p,
+	    CLK_CON_MUX_MUX_CLKCMU_DISP_BUS, 0, 2),
+
+	/* G2D */
+	MUX(CLK_MOUT_G2D_G2D, "mout_cmu_g2d_g2d", mout_cmu_g2d_g2d_p,
+	    CLK_CON_MUX_MUX_CLKCMU_G2D_G2D, 0, 2),
+
+	MUX(CLK_MOUT_G2D_MSCL, "mout_cmu_g2d_mscl", mout_cmu_g2d_mscl_p,
+	    CLK_CON_MUX_MUX_CLKCMU_G2D_MSCL, 0, 2),
+
+	/* HSI0 */
+	MUX(CLK_MOUT_HSI0_USB31DRD, "mout_cmu_hsi0_usb31drd", mout_cmu_hsi0_usb31drd_p,
+	    CLK_CON_MUX_MUX_CLKCMU_HSI0_USB31DRD, 0, 2),
+
+	MUX(CLK_MOUT_HSI0_BUS, "mout_cmu_hsi0_bus", mout_cmu_hsi0_bus_p,
+	    CLK_CON_MUX_MUX_CLKCMU_HSI0_BUS, 0, 2),
+
+	MUX(CLK_MOUT_HSI0_DPGTC, "mout_cmu_hsi0_dpgtc", mout_cmu_hsi0_dpgtc_p,
+	    CLK_CON_MUX_MUX_CLKCMU_HSI0_DPGTC, 0, 2),
+
+	MUX(CLK_MOUT_HSI0_USBDPDGB, "mout_cmu_hsi0_usbdpdbg", mout_cmu_hsi0_usbdpdbg_p,
+	    CLK_CON_MUX_MUX_CLKCMU_HSI0_USBDPDBG, 0, 2),
+
+	/* HSI1 */
+	MUX(CLK_MOUT_HSI1_BUS, "mout_cmu_hsi1_bus", mout_cmu_hsi1_bus_p,
+	    CLK_CON_MUX_MUX_CLKCMU_HSI1_BUS, 0, 2),
+
+	MUX(CLK_MOUT_HSI1_PCIE, "mout_cmu_hsi1_pcie", mout_cmu_hsi1_pcie_p,
+	    CLK_CON_MUX_MUX_CLKCMU_HSI1_PCIE, 0, 2),
+	/* HSI2 */
+	MUX(CLK_MOUT_HSI2_BUS, "mout_cmu_hsi2_bus", mout_cmu_hsi2_bus_p,
+	    CLK_CON_MUX_MUX_CLKCMU_HSI2_BUS, 0, 2),
+
+	MUX(CLK_MOUT_HSI2_PCIE, "mout_cmu_hsi2_pcie", mout_cmu_hsi2_pcie0_p,
+	    CLK_CON_MUX_MUX_CLKCMU_HSI2_PCIE, 0, 2),
+
+	MUX(CLK_MOUT_HSI2_UFS_EMBD, "mout_cmu_hsi2_ufs_embd", mout_cmu_hsi2_ufs_embd_p,
+	    CLK_CON_MUX_MUX_CLKCMU_HSI2_UFS_EMBD, 0, 2),
+
+	MUX(CLK_MOUT_HSI2_MMC_CARD, "mout_cmu_hsi2_mmc_card", mout_cmu_hsi2_mmc_card_p,
+	    CLK_CON_MUX_MUX_CLKCMU_HSI2_MMC_CARD, 0, 2),
+
+	/* CSIS */
+	MUX(CLK_MOUT_CSIS, "mout_cmu_csis_bus", mout_cmu_csis_bus_p,
+	    CLK_CON_MUX_MUX_CLKCMU_CSIS_BUS, 0, 2),
+
+	/* PDP */
+	MUX(CLK_MOUT_PDP_BUS, "mout_cmu_pdp_bus", mout_cmu_pdp_bus_p,
+	    CLK_CON_MUX_MUX_CLKCMU_PDP_BUS, 0, 2),
+
+	/* PDP */
+	MUX(CLK_MOUT_PDP_VRA, "mout_cmu_pdp_vra", mout_cmu_pdp_vra_p,
+	    CLK_CON_MUX_MUX_CLKCMU_PDP_VRA, 0, 2),
+
+	/* IPP */
+	MUX(CLK_MOUT_IPP_BUS, "mout_cmu_ipp_bus", mout_cmu_ipp_bus_p,
+	    CLK_CON_MUX_MUX_CLKCMU_IPP_BUS, 0, 2),
+
+	/* G3AA */
+	MUX(CLK_MOUT_G3AA, "mout_cmu_g3aa", mout_cmu_g3aa_p,
+	    CLK_CON_MUX_MUX_CLKCMU_G3AA_G3AA, 0, 2),
+
+	/* ITP */
+	MUX(CLK_MOUT_ITP, "mout_cmu_itp_bus", mout_cmu_itp_bus_p,
+	    CLK_CON_MUX_MUX_CLKCMU_ITP_BUS, 0, 2),
+
+	/* DNS */
+	MUX(CLK_MOUT_DNS_BUS, "mout_cmu_dns_bus", mout_cmu_dns_bus_p,
+	    CLK_CON_MUX_MUX_CLKCMU_DNS_BUS, 0, 2),
+
+	/* TNR */
+	MUX(CLK_MOUT_TNR_BUS, "mout_cmu_tnr_bus", mout_cmu_tnr_bus_p,
+	    CLK_CON_MUX_MUX_CLKCMU_TNR_BUS, 0, 2),
+
+	/* MCSC*/
+	MUX(CLK_MOUT_MCSC_ITSC, "mout_cmu_mcsc_itsc", mout_cmu_mcsc_itsc_p,
+	    CLK_CON_MUX_MUX_CLKCMU_MCSC_ITSC, 0, 2),
+
+	MUX(CLK_MOUT_MCSC_MCSC, "mout_cmu_mcsc_mcsc", mout_cmu_mcsc_mcsc_p,
+	    CLK_CON_MUX_MUX_CLKCMU_MCSC_MCSC, 0, 2),
+
+	/* GDC */
+	MUX(CLK_MOUT_GDC_SCSC, "mout_cmu_gdc_scsc", mout_cmu_gdc_scsc_p,
+	    CLK_CON_MUX_MUX_CLKCMU_GDC_SCSC, 0, 2),
+
+	MUX(CLK_MOUT_GDC_GDC0, "mout_cmu_gdc_gdc0", mout_cmu_gdc_gdc0_p,
+	    CLK_CON_MUX_MUX_CLKCMU_GDC_GDC0, 0, 2),
+
+	MUX(CLK_MOUT_GDC_GDC1, "mout_cmu_gdc_gdc1", mout_cmu_gdc_gdc1_p,
+	    CLK_CON_MUX_MUX_CLKCMU_GDC_GDC1, 0, 2),
+
+	/* MFC */
+	MUX(CLK_MOUT_MFC_MFC, "mout_cmu_mfc_mfc", mout_cmu_mfc_mfc_p,
+	    CLK_CON_MUX_MUX_CLKCMU_MFC_MFC, 0, 2),
+
+	/* DDRPHY0/1/2/3 */
+	MUX(CLK_MOUT_MIF_SWITCH, "mout_cmu_mif_switch", mout_cmu_mif_switch_p,
+	    CLK_CON_MUX_MUX_CLKCMU_MIF_SWITCH, 0, 2),
+
+	/* MIF0/1/2/3 */
+	MUX(CLK_MOUT_MIF_BUS, "mout_cmu_mif_busp", mout_cmu_mif_busp_p,
+	    CLK_CON_MUX_MUX_CLKCMU_MIF_BUSP, 0, 2),
+
+	/* MISC */
+	MUX(CLK_MOUT_MISC_BUS, "mout_cmu_misc_bus", mout_cmu_misc_bus_p,
+	    CLK_CON_MUX_MUX_CLKCMU_MISC_BUS, 0, 2),
+	MUX(CLK_MOUT_MISC_SSS, "mout_cmu_misc_sss", mout_cmu_misc_sss_p,
+	    CLK_CON_MUX_MUX_CLKCMU_MISC_SSS, 0, 2),
+
+	/* PERI0 */
+	MUX(CLK_MOUT_PERIC0_IP, "mout_cmu_peric0_ip", mout_cmu_peric0_ip_p,
+	    CLK_CON_MUX_MUX_CLKCMU_PERIC0_IP, 0, 2),
+	MUX(CLK_MOUT_PERIC0_BUS, "mout_cmu_peric0_bus", mout_cmu_peric0_bus_p,
+	    CLK_CON_MUX_MUX_CLKCMU_PERIC0_BUS, 0, 2),
+	/* PERI1 */
+	MUX(CLK_MOUT_PERIC1_IP, "mout_cmu_peric1_ip", mout_cmu_peric1_ip_p,
+	    CLK_CON_MUX_MUX_CLKCMU_PERIC0_IP, 0, 2),
+	MUX(CLK_MOUT_PERIC1_BUS, "mout_cmu_peric1_bus", mout_cmu_peric1_bus_p,
+	    CLK_CON_MUX_MUX_CLKCMU_PERIC0_BUS, 0, 2),
+
+	/* TPU */
+	MUX(CLK_MOUT_TPU_TPU, "mout_cmu_tpu_tpu", mout_cmu_tpu_tpu_p,
+	    CLK_CON_MUX_MUX_CLKCMU_TPU_TPU, 0, 2),
+
+	MUX(CLK_MOUT_TPU_TPUCTL, "mout_cmu_tpu_tpuctl", mout_cmu_tpu_tpuctl_p,
+	    CLK_CON_MUX_MUX_CLKCMU_TPU_TPUCTL, 0, 2),
+
+	MUX(CLK_MOUT_TPU_BUS, "mout_cmu_tpu_bus", mout_cmu_tpu_bus_p,
+	    CLK_CON_MUX_MUX_CLKCMU_TPU_BUS, 0, 2),
+
+	MUX(CLK_MOUT_TPU_UART, "mout_cmu_tpu_uart", mout_cmu_tpu_uart_p,
+	    CLK_CON_MUX_MUX_CLKCMU_TPU_UART, 0, 2),
+
+	/* BO */
+	MUX(CLK_MOUT_BO_BUS, "mout_cmu_bo_bus", mout_cmu_bo_bus_p,
+	    CLK_CON_MUX_MUX_CLKCMU_BO_BUS, 0, 2),
+};
+
+static const struct samsung_div_clock cmu_top_div_clks[] __initconst = {
+	/* CMU_TOP_PURECLKCOMP */
+	DIV(CLK_DOUT_SHARED0_DIV3, "dout_shared0_div3", "mout_shared0_pll",
+	    CLK_CON_DIV_PLL_SHARED0_DIV3, 0, 2),
+	DIV(CLK_DOUT_SHARED0_DIV2, "dout_shared0_div2", "mout_shared0_pll",
+	    CLK_CON_DIV_PLL_SHARED0_DIV2, 0, 1),
+	DIV(CLK_DOUT_SHARED0_DIV5, "dout_shared0_div5", "mout_shared0_pll",
+	    CLK_CON_DIV_PLL_SHARED0_DIV5, 0, 2),
+	DIV(CLK_DOUT_SHARED0_DIV4, "dout_shared0_div4", "dout_shared0_div2",
+	    CLK_CON_DIV_PLL_SHARED0_DIV4, 0, 1),
+
+	DIV(CLK_DOUT_SHARED1_DIV2, "dout_shared1_div2", "mout_shared1_pll",
+	    CLK_CON_DIV_PLL_SHARED1_DIV2, 0, 1),
+	DIV(CLK_DOUT_SHARED1_DIV3, "dout_shared1_div3", "mout_shared1_pll",
+	    CLK_CON_DIV_PLL_SHARED1_DIV3, 0, 2),
+	DIV(CLK_DOUT_SHARED1_DIV4, "dout_shared1_div4", "mout_shared1_pll",
+	    CLK_CON_DIV_PLL_SHARED1_DIV4, 0, 1),
+
+	DIV(CLK_DOUT_SHARED2_DIV2, "dout_shared2_div2", "mout_shared2_pll",
+	    CLK_CON_DIV_PLL_SHARED2_DIV2, 0, 1),
+
+	DIV(CLK_DOUT_SHARED3_DIV2, "dout_shared3_div2", "mout_shared3_pll",
+	    CLK_CON_DIV_PLL_SHARED3_DIV2, 0, 1),
+
+	/* BUS0 */
+	DIV(CLK_DOUT_BUS0_BUS, "dout_cmu_bus0_bus_div", "gout_cmu_bus0_bus",
+	    CLK_CON_DIV_CLKCMU_BUS0_BUS, 0, 4),
+	DIV(CLK_DOUT_CMU_BOOST, "dout_cmu_boost", "gout_cmu_cmu_boost",
+	    CLK_CON_DIV_DIV_CLKCMU_CMU_BOOST, 0, 2),
+
+	/* BUS1 */
+	DIV(CLK_DOUT_BUS1_BUS, "dout_cmu_bus1_bus", "gout_cmu_bus1_bus",
+	    CLK_CON_DIV_CLKCMU_BUS1_BUS, 0, 4),
+
+	/* BUS2 */
+	DIV(CLK_DOUT_BUS2_BUS, "dout_cmu_bus2_bus", "gout_cmu_bus2_bus",
+	    CLK_CON_DIV_CLKCMU_BUS2_BUS, 0, 4),
+
+	/* CORE */
+	DIV(CLK_DOUT_CORE_BUS, "dout_cmu_core_bus", "gout_cmu_core_bus",
+	    CLK_CON_DIV_CLKCMU_CORE_BUS, 0, 4),
+
+	/* EH */
+	DIV(CLK_DOUT_EH_BUS, "dout_cmu_eh_bus", "gout_cmu_eh_bus",
+	    CLK_CON_DIV_CLKCMU_EH_BUS, 0, 4),
+
+	/* CPUCL{0,1,2,} */
+	DIV(CLK_DOUT_CPUCL2_SWITCH, "dout_cmu_cpucl2_switch", "gout_cmu_cpucl2_switch",
+	    CLK_CON_DIV_CLKCMU_CPUCL2_SWITCH, 0, 3),
+
+	DIV(CLK_DOUT_CPUCL1_SWITCH, "dout_cmu_cpucl1_switch", "gout_cmu_cpucl1_switch",
+	    CLK_CON_DIV_CLKCMU_CPUCL1_SWITCH, 0, 3),
+
+	DIV(CLK_DOUT_CPUCL0_SWITCH, "dout_cmu_cpucl0_switch", "gout_cmu_cpucl0_switch",
+	    CLK_CON_DIV_CLKCMU_CPUCL0_SWITCH, 0, 3),
+
+	DIV(CLK_DOUT_CPUCL0_DBG, "dout_cmu_cpucl0_dbg", "gout_cmu_cpucl0_dbg",
+	    CLK_CON_DIV_CLKCMU_CPUCL0_DBG, 0, 4),
+
+	DIV(CLK_DOUT_CMU_HPM, "dout_cmu_hpm", "gout_cmu_hpm",
+	    CLK_CON_DIV_CLKCMU_HPM, 0, 2),
+
+	/* G3D */
+	DIV(CLK_DOUT_G3D_SWITCH, "dout_cmu_g3d_switch", "gout_cmu_g3d_switch",
+	    CLK_CON_DIV_CLKCMU_G3D_SWITCH, 0, 3),
+
+	DIV(CLK_DOUT_G3D_SWITCH, "dout_cmu_g3d_busd", "gout_cmu_g3d_busd",
+	    CLK_CON_DIV_CLKCMU_G3D_BUSD, 0, 4),
+
+	DIV(CLK_DOUT_G3D_GLB, "dout_cmu_g3d_glb", "gout_cmu_g3d_glb",
+	    CLK_CON_DIV_CLKCMU_G3D_GLB, 0, 4),
+
+	/* DPU */
+	DIV(CLK_DOUT_DPU_BUS, "dout_cmu_dpu_bus", "gout_cmu_dpu_bus",
+	    CLK_CON_DIV_CLKCMU_DPU_BUS, 0, 4),
+
+	/* DISP */
+	DIV(CLK_DOUT_DISP_BUS, "dout_cmu_disp_bus", "gout_cmu_disp_bus",
+	    CLK_CON_DIV_CLKCMU_DISP_BUS, 0, 4),
+
+	/* G2D */
+	DIV(CLK_DOUT_G2D_G2D, "dout_cmu_g2d_g2d", "gout_cmu_g2d_g2d",
+	    CLK_CON_DIV_CLKCMU_G2D_G2D, 0, 4),
+
+	DIV(CLK_DOUT_G2D_MSCL, "dout_cmu_g2d_mscl", "gout_cmu_g2d_mscl",
+	    CLK_CON_DIV_CLKCMU_G2D_MSCL, 0, 4),
+
+	/* HSI0 */
+	DIV(CLK_DOUT_HSI0_USB31DRD, "dout_cmu_hsi0_usb31drd", "gout_cmu_hsi0_usb31drd",
+	    CLK_CON_DIV_CLKCMU_HSI0_USB31DRD, 0, 5),
+
+	DIV(CLK_DOUT_HSI0_BUS, "dout_cmu_hsi0_bus", "gout_cmu_hsi0_bus",
+	    CLK_CON_DIV_CLKCMU_HSI0_BUS, 0, 4),
+
+	DIV(CLK_DOUT_HSI0_DPGTC, "dout_cmu_hsi0_dpgtc", "gout_cmu_hsi0_dpgtc",
+	    CLK_CON_DIV_CLKCMU_HSI0_DPGTC, 0, 4),
+
+	/* TODO register exists but all lower bits are reserved */
+	DIV(CLK_DOUT_HSI0_USBDPDGB, "dout_cmu_hsi0_usbdpdbg", "gout_cmu_hsi0_usbdpdbg",
+	    CLK_CON_DIV_CLKCMU_HSI0_USBDPDBG, 0, 0),
+
+	/* HSI1 */
+	DIV(CLK_DOUT_HSI1_BUS, "dout_cmu_hsi1_bus", "gout_cmu_hsi1_bus",
+	    CLK_CON_DIV_CLKCMU_HSI1_BUS, 0, 4),
+
+	DIV(CLK_DOUT_HSI1_PCIE, "dout_cmu_hsi1_pcie", "gout_cmu_hsi1_pcie",
+	    CLK_CON_DIV_CLKCMU_HSI1_PCIE, 0, 3),
+	/* HSI2 */
+	DIV(CLK_DOUT_HSI2_BUS, "dout_cmu_hsi2_bus", "gout_cmu_hsi2_bus",
+	    CLK_CON_DIV_CLKCMU_HSI2_BUS, 0, 4),
+
+	DIV(CLK_DOUT_HSI2_PCIE, "dout_cmu_hsi2_pcie", "gout_cmu_hsi2_pcie",
+	    CLK_CON_DIV_CLKCMU_HSI2_PCIE, 0, 3),
+
+	DIV(CLK_DOUT_HSI2_UFS_EMBD, "dout_cmu_hsi2_ufs_embd", "gout_cmu_hsi2_ufs_embd",
+	    CLK_CON_DIV_CLKCMU_HSI2_UFS_EMBD, 0, 4),
+
+	DIV(CLK_DOUT_HSI2_MMC_CARD, "dout_cmu_hsi2_mmc_card", "gout_cmu_hsi2_mmc_card",
+	    CLK_CON_DIV_CLKCMU_HSI2_MMC_CARD, 0, 9),
+
+	/* CSIS */
+	DIV(CLK_DOUT_CSIS, "dout_cmu_csis_bus", "gout_cmu_csis_bus",
+	    CLK_CON_DIV_CLKCMU_CSIS_BUS, 0, 4),
+
+	/* PDP */
+	DIV(CLK_DOUT_PDP_BUS, "dout_cmu_pdp_bus", "gout_cmu_pdp_bus",
+	    CLK_CON_DIV_CLKCMU_PDP_BUS, 0, 4),
+
+	DIV(CLK_DOUT_PDP_VRA, "dout_cmu_pdp_vra", "gout_cmu_pdp_vra",
+	    CLK_CON_DIV_CLKCMU_PDP_VRA, 0, 4),
+
+	/* IPP */
+	DIV(CLK_DOUT_IPP_BUS, "dout_cmu_ipp_bus", "gout_cmu_ipp_bus",
+	    CLK_CON_DIV_CLKCMU_IPP_BUS, 0, 4),
+
+	/* G3AA */
+	DIV(CLK_DOUT_G3AA, "dout_cmu_g3aa", "gout_cmu_g3aa",
+	    CLK_CON_DIV_CLKCMU_G3AA_G3AA, 0, 4),
+
+	/* ITP */
+	DIV(CLK_DOUT_ITP, "dout_cmu_itp_bus", "gout_cmu_itp_bus",
+	    CLK_CON_DIV_CLKCMU_ITP_BUS, 0, 4),
+
+	/* DNS */
+	DIV(CLK_DOUT_DNS_BUS, "dout_cmu_dns_bus", "gout_cmu_dns_bus",
+	    CLK_CON_DIV_CLKCMU_DNS_BUS, 0, 4),
+
+	/* TNR */
+	DIV(CLK_DOUT_TNR_BUS, "dout_cmu_tnr_bus", "gout_cmu_tnr_bus",
+	    CLK_CON_DIV_CLKCMU_TNR_BUS, 0, 4),
+
+	/* MCSC*/
+	DIV(CLK_DOUT_MCSC_ITSC, "dout_cmu_mcsc_itsc", "gout_cmu_mcsc_itsc",
+	    CLK_CON_DIV_CLKCMU_MCSC_ITSC, 0, 4),
+
+	DIV(CLK_DOUT_MCSC_MCSC, "dout_cmu_mcsc_mcsc", "gout_cmu_mcsc_mcsc",
+	    CLK_CON_DIV_CLKCMU_MCSC_MCSC, 0, 4),
+
+	/* GDC */
+	DIV(CLK_DOUT_GDC_SCSC, "dout_cmu_gdc_scsc", "gout_cmu_gdc_scsc",
+	    CLK_CON_DIV_CLKCMU_GDC_SCSC, 0, 4),
+
+	DIV(CLK_DOUT_GDC_GDC0, "dout_cmu_gdc_gdc0", "gout_cmu_gdc_gdc0",
+	    CLK_CON_DIV_CLKCMU_GDC_GDC0, 0, 4),
+
+	DIV(CLK_DOUT_GDC_GDC1, "dout_cmu_gdc_gdc1", "gout_cmu_gdc_gdc1",
+	    CLK_CON_DIV_CLKCMU_GDC_GDC1, 0, 4),
+
+	/* MFC */
+	DIV(CLK_DOUT_MFC_MFC, "dout_cmu_mfc_mfc", "gout_cmu_mfc_mfc",
+	    CLK_CON_DIV_CLKCMU_MFC_MFC, 0, 4),
+
+	/* MIF0/1/2/3 */
+	DIV(CLK_DOUT_MIF_BUS, "dout_cmu_mif_busp", "gout_cmu_mif_busp",
+	    CLK_CON_DIV_CLKCMU_MIF_BUSP, 0, 4),
+
+	/* MISC */
+	DIV(CLK_DOUT_MISC_BUS, "dout_cmu_misc_bus", "gout_cmu_misc_bus",
+	    CLK_CON_DIV_CLKCMU_MISC_BUS, 0, 4),
+	DIV(CLK_DOUT_MISC_SSS, "dout_cmu_misc_sss", "gout_cmu_misc_sss",
+	    CLK_CON_DIV_CLKCMU_MISC_SSS, 0, 4),
+
+	/* PERI0 */
+	DIV(CLK_DOUT_PERIC0_BUS, "dout_cmu_peric0_bus", "gout_cmu_peric0_bus",
+	    CLK_CON_DIV_CLKCMU_PERIC0_BUS, 0, 4),
+	DIV(CLK_DOUT_PERIC0_IP, "dout_cmu_peric0_ip", "gout_cmu_peric0_ip",
+	    CLK_CON_DIV_CLKCMU_PERIC0_IP, 0, 4),
+
+	/* PERI1 */
+	DIV(CLK_DOUT_PERIC1_BUS, "dout_cmu_peric1_bus", "gout_cmu_peric1_bus",
+	    CLK_CON_DIV_CLKCMU_PERIC1_BUS, 0, 4),
+	DIV(CLK_DOUT_PERIC1_IP, "dout_cmu_peric1_ip", "gout_cmu_peric1_ip",
+	    CLK_CON_DIV_CLKCMU_PERIC1_IP, 0, 4),
+
+	/* TPU */
+	DIV(CLK_DOUT_TPU_TPU, "dout_cmu_tpu_tpu", "gout_cmu_tpu_tpu",
+	    CLK_CON_DIV_CLKCMU_TPU_TPU, 0, 4),
+
+	DIV(CLK_DOUT_TPU_TPUCTL, "dout_cmu_tpu_tpuctl", "gout_cmu_tpu_tpuctl",
+	    CLK_CON_DIV_CLKCMU_TPU_TPUCTL, 0, 4),
+
+	DIV(CLK_DOUT_TPU_BUS, "dout_cmu_tpu_bus", "gout_cmu_tpu_bus",
+	    CLK_CON_DIV_CLKCMU_TPU_BUS, 0, 4),
+
+	DIV(CLK_DOUT_TPU_UART, "dout_cmu_tpu_uart", "gout_cmu_tpu_uart",
+	    CLK_CON_DIV_CLKCMU_TPU_UART, 0, 4),
+
+	/* BO */
+	DIV(CLK_DOUT_BO_BUS, "dout_cmu_bo_bus", "gout_cmu_bo_bus",
+	    CLK_CON_DIV_CLKCMU_BO_BUS, 0, 4),
+
+};
+
+static const struct samsung_gate_clock cmu_top_gate_clks[] __initconst = {
+	/* BUS0 */
+	GATE(CLK_GOUT_BUS0_BUS, "gout_cmu_bus0_bus", "mout_cmu_bus0_bus",
+	     CLK_CON_GAT_GATE_CLKCMU_BUS0_BUS, 21, 0, 0),
+
+	/* BUS1 */
+	GATE(CLK_GOUT_BUS1_BUS, "gout_cmu_bus1_bus", "mout_cmu_bus1_bus",
+	     CLK_CON_GAT_GATE_CLKCMU_BUS1_BUS, 21, 0, 0),
+
+	/* BUS2 */
+	GATE(CLK_GOUT_BUS2_BUS, "gout_cmu_bus2_bus", "mout_cmu_bus2_bus",
+	     CLK_CON_GAT_GATE_CLKCMU_BUS2_BUS, 21, 0, 0),
+
+	/* CORE */
+	GATE(CLK_GOUT_CORE_BUS, "gout_cmu_core_bus", "mout_cmu_core_bus",
+	     CLK_CON_GAT_GATE_CLKCMU_CORE_BUS, 21, 0, 0),
+
+	/* EH */
+	GATE(CLK_GOUT_EH_BUS, "gout_cmu_eh_bus", "mout_cmu_eh_bus",
+	     CLK_CON_GAT_GATE_CLKCMU_EH_BUS, 21, 0, 0),
+
+	/* CPUCL{0,1,2,} */
+	GATE(CLK_GOUT_CPUCL2_SWITCH, "gout_cmu_cpucl2_switch", "mout_cmu_cpucl2_switch",
+	     CLK_CON_GAT_GATE_CLKCMU_CPUCL2_SWITCH, 21, 0, 0),
+
+	GATE(CLK_GOUT_CPUCL1_SWITCH, "gout_cmu_cpucl1_switch", "mout_cmu_cpucl1_switch",
+	     CLK_CON_GAT_GATE_CLKCMU_CPUCL1_SWITCH, 21, 0, 0),
+
+	GATE(CLK_GOUT_CPUCL0_SWITCH, "gout_cmu_cpucl0_switch", "mout_cmu_cpucl0_switch",
+	     CLK_CON_GAT_GATE_CLKCMU_CPUCL0_SWITCH, 21, 0, 0),
+
+	GATE(CLK_GOUT_CPUCL0_DBG, "gout_cmu_cpucl0_dbg", "mout_cmu_cpucl0_dbg",
+	     CLK_CON_GAT_GATE_CLKCMU_CPUCL0_DBG_BUS, 21, 0, 0),
+
+	GATE(CLK_GOUT_CMU_HPM, "gout_cmu_hpm", "mout_cmu_hpm",
+	     CLK_CON_GAT_GATE_CLKCMU_HPM, 21, 0, 0),
+
+	/* G3D */
+	GATE(CLK_GOUT_G3D_SWITCH, "gout_cmu_g3d_switch", "mout_cmu_g3d_switch",
+	     CLK_CON_GAT_GATE_CLKCMU_G3D_SWITCH, 21, 0, 0),
+
+	GATE(CLK_GOUT_G3D_SWITCH, "gout_cmu_g3d_busd", "mout_cmu_g3d_busd",
+	     CLK_CON_GAT_GATE_CLKCMU_G3D_BUSD, 21, 0, 0),
+
+	GATE(CLK_GOUT_G3D_GLB, "gout_cmu_g3d_glb", "mout_cmu_g3d_glb",
+	     CLK_CON_GAT_GATE_CLKCMU_G3D_GLB, 21, 0, 0),
+	/* DPU */
+	GATE(CLK_GOUT_DPU_BUS, "gout_cmu_dpu_bus", "mout_cmu_dpu_bus",
+	     CLK_CON_GAT_GATE_CLKCMU_DPU_BUS, 21, 0, 0),
+	/* DISP */
+	GATE(CLK_GOUT_DISP_BUS, "gout_cmu_disp_bus", "mout_cmu_disp_bus",
+	     CLK_CON_GAT_GATE_CLKCMU_DISP_BUS, 21, 0, 0),
+
+	/* G2D */
+	GATE(CLK_GOUT_G2D_G2D, "gout_cmu_g2d_g2d", "mout_cmu_g2d_g2d",
+	     CLK_CON_GAT_GATE_CLKCMU_G2D_G2D, 21, 0, 0),
+
+	GATE(CLK_GOUT_G2D_MSCL, "gout_cmu_g2d_mscl", "mout_cmu_g2d_mscl",
+	     CLK_CON_GAT_GATE_CLKCMU_G2D_MSCL, 21, 0, 0),
+	/* HSI0 */
+	GATE(CLK_GOUT_HSI0_USB31DRD, "gout_cmu_hsi0_usb31drd", "mout_cmu_hsi0_usb31drd",
+	     CLK_CON_GAT_GATE_CLKCMU_HSI0_USB31DRD, 21, 0, 0),
+
+	GATE(CLK_GOUT_HSI0_BUS, "gout_cmu_hsi0_bus", "mout_cmu_hsi0_bus",
+	     CLK_CON_GAT_GATE_CLKCMU_HSI0_BUS, 21, 0, 0),
+
+	GATE(CLK_GOUT_HSI0_DPGTC, "gout_cmu_hsi0_dpgtc", "mout_cmu_hsi0_dpgtc",
+	     CLK_CON_GAT_GATE_CLKCMU_HSI0_DPGTC, 21, 0, 0),
+
+	GATE(CLK_GOUT_HSI0_USBDPDGB, "gout_cmu_hsi0_usbdpdbg", "mout_cmu_hsi0_usbdpdbg",
+	     CLK_CON_GAT_GATE_CLKCMU_HSI0_USBDPDBG, 21, 0, 0),
+	/* HSI1 */
+	GATE(CLK_GOUT_HSI1_BUS, "gout_cmu_hsi1_bus", "mout_cmu_hsi1_bus",
+	     CLK_CON_GAT_GATE_CLKCMU_HSI1_BUS, 21, 0, 0),
+
+	GATE(CLK_GOUT_HSI1_PCIE, "gout_cmu_hsi1_pcie", "mout_cmu_hsi1_pcie",
+	     CLK_CON_GAT_GATE_CLKCMU_HSI1_PCIE, 21, 0, 0),
+	/* HSI2 */
+	GATE(CLK_GOUT_HSI2_BUS, "gout_cmu_hsi2_bus", "mout_cmu_hsi2_bus",
+	     CLK_CON_GAT_GATE_CLKCMU_HSI2_BUS, 21, 0, 0),
+	GATE(CLK_GOUT_HSI2_PCIE, "gout_cmu_hsi2_pcie", "mout_cmu_hsi2_pcie",
+	     CLK_CON_GAT_GATE_CLKCMU_HSI2_PCIE, 21, 0, 0),
+
+	GATE(CLK_GOUT_HSI2_UFS_EMBD, "gout_cmu_hsi2_ufs_embd", "mout_cmu_hsi2_ufs_embd",
+	     CLK_CON_GAT_GATE_CLKCMU_HSI2_UFS_EMBD, 21, 0, 0),
+	GATE(CLK_GOUT_HSI2_MMC_CARD, "gout_cmu_hsi2_mmc_card", "mout_cmu_hsi2_mmc_card",
+	     CLK_CON_GAT_GATE_CLKCMU_HSI2_MMCCARD, 21, 0, 0),
+	/* CSIS */
+	GATE(CLK_GOUT_CSIS, "gout_cmu_csis_bus", "mout_cmu_csis_bus",
+	     CLK_CON_GAT_GATE_CLKCMU_CSIS_BUS, 21, 0, 0),
+	/* PDP */
+	GATE(CLK_GOUT_PDP_BUS, "gout_cmu_pdp_bus", "mout_cmu_pdp_bus",
+	     CLK_CON_GAT_GATE_CLKCMU_PDP_BUS, 21, 0, 0),
+
+	GATE(CLK_GOUT_PDP_VRA, "gout_cmu_pdp_vra", "mout_cmu_pdp_vra",
+	     CLK_CON_GAT_GATE_CLKCMU_PDP_BUS, 21, 0, 0),
+
+	/* IPP */
+	GATE(CLK_GOUT_IPP_BUS, "gout_cmu_ipp_bus", "mout_cmu_ipp_bus",
+	     CLK_CON_GAT_GATE_CLKCMU_IPP_BUS, 21, 0, 0),
+	/* G3AA */
+	GATE(CLK_GOUT_G3AA, "gout_cmu_g3aa", "mout_cmu_g3aa",
+	     CLK_CON_MUX_MUX_CLKCMU_G3AA_G3AA, 21, 0, 0),
+
+	/* ITP */
+	GATE(CLK_GOUT_ITP, "gout_cmu_itp_bus", "mout_cmu_itp_bus",
+	     CLK_CON_GAT_GATE_CLKCMU_ITP_BUS, 21, 0, 0),
+
+	/* DNS */
+	GATE(CLK_GOUT_DNS_BUS, "gout_cmu_dns_bus", "mout_cmu_dns_bus",
+	     CLK_CON_GAT_GATE_CLKCMU_DNS_BUS, 21, 0, 0),
+
+	/* TNR */
+	GATE(CLK_GOUT_TNR_BUS, "gout_cmu_tnr_bus", "mout_cmu_tnr_bus",
+	     CLK_CON_GAT_GATE_CLKCMU_TNR_BUS, 21, 0, 0),
+
+	/* MCSC*/
+	GATE(CLK_GOUT_MCSC_ITSC, "gout_cmu_mcsc_itsc", "mout_cmu_mcsc_itsc",
+	     CLK_CON_GAT_GATE_CLKCMU_MCSC_ITSC, 21, 0, 0),
+
+	GATE(CLK_GOUT_MCSC_MCSC, "gout_cmu_mcsc_mcsc", "mout_cmu_mcsc_mcsc",
+	     CLK_CON_GAT_GATE_CLKCMU_MCSC_MCSC, 21, 0, 0),
+
+	/* GDC */
+	GATE(CLK_GOUT_GDC_SCSC, "gout_cmu_gdc_scsc", "mout_cmu_gdc_scsc",
+	     CLK_CON_GAT_GATE_CLKCMU_GDC_SCSC, 21, 0, 0),
+
+	GATE(CLK_GOUT_GDC_GDC0, "gout_cmu_gdc_gdc0", "mout_cmu_gdc_gdc0",
+	     CLK_CON_GAT_GATE_CLKCMU_GDC_GDC0, 21, 0, 0),
+
+	GATE(CLK_GOUT_GDC_GDC1, "gout_cmu_gdc_gdc1", "mout_cmu_gdc_gdc1",
+	     CLK_CON_GAT_GATE_CLKCMU_GDC_GDC1, 21, 0, 0),
+
+	/* MFC */
+	GATE(CLK_GOUT_MFC_MFC, "gout_cmu_mfc_mfc", "mout_cmu_mfc_mfc",
+	     CLK_CON_GAT_GATE_CLKCMU_MFC_MFC, 21, 0, 0),
+
+	/* DDRPHY0/1/2/3 */
+	GATE(CLK_GOUT_MIF_SWITCH, "gout_cmu_mif_switch", "mout_cmu_mif_switch",
+	     CLK_CON_GAT_CLKCMU_MIF_SWITCH, 21, 0, 0),
+
+	/* MIF0/1/2/3 */
+	GATE(CLK_GOUT_MIF_BUS, "gout_cmu_mif_busp", "mout_cmu_mif_busp",
+	     CLK_CON_GAT_GATE_CLKCMU_MIF_BUSP, 21, 0, 0),
+
+	GATE(CLK_GOUT_CMU_BOOST, "gout_cmu_cmu_boost", "mout_cmu_boost",
+	     CLK_CON_GAT_GATE_CLKCMU_CMU_BOOST, 21, 0, 0),
+
+	/* MISC */
+	GATE(CLK_GOUT_MISC_BUS, "gout_cmu_misc_bus", "mout_cmu_misc_bus",
+	     CLK_CON_GAT_GATE_CLKCMU_MISC_BUS, 21, 0, 0),
+	GATE(CLK_GOUT_MISC_SSS, "gout_cmu_misc_sss", "mout_cmu_misc_sss",
+	     CLK_CON_GAT_GATE_CLKCMU_MISC_SSS, 21, 0, 0),
+
+	/* PERI0 */
+	GATE(CLK_GOUT_PERIC0_BUS, "gout_cmu_peric0_bus", "mout_cmu_peric0_bus",
+	     CLK_CON_GAT_GATE_CLKCMU_PERIC0_BUS, 21, 0, 0),
+	GATE(CLK_GOUT_PERIC0_IP, "gout_cmu_peric0_ip", "mout_cmu_peric0_ip",
+	     CLK_CON_GAT_GATE_CLKCMU_PERIC0_IP, 21, 0, 0),
+
+	/* PERI1 */
+	GATE(CLK_GOUT_PERIC1_BUS, "gout_cmu_peric1_bus", "mout_cmu_peric1_bus",
+	     CLK_CON_GAT_GATE_CLKCMU_PERIC1_BUS, 21, 0, 0),
+	GATE(CLK_GOUT_PERIC1_IP, "gout_cmu_peric1_ip", "mout_cmu_peric1_ip",
+	     CLK_CON_GAT_GATE_CLKCMU_PERIC1_IP, 21, 0, 0),
+
+	/* TPU */
+	GATE(CLK_GOUT_TPU_TPU, "gout_cmu_tpu_tpu", "mout_cmu_tpu_tpu",
+	     CLK_CON_GAT_GATE_CLKCMU_TPU_TPU, 21, 0, 0),
+	GATE(CLK_GOUT_TPU_TPUCTL, "gout_cmu_tpu_tpuctl", "mout_cmu_tpu_tpuctl",
+	     CLK_CON_GAT_GATE_CLKCMU_TPU_TPUCTL, 21, 0, 0),
+	GATE(CLK_GOUT_TPU_BUS, "gout_cmu_tpu_bus", "mout_cmu_tpu_bus",
+	     CLK_CON_GAT_GATE_CLKCMU_TPU_BUS, 21, 0, 0),
+	GATE(CLK_GOUT_TPU_UART, "gout_cmu_tpu_uart", "mout_cmu_tpu_uart",
+	     CLK_CON_GAT_GATE_CLKCMU_TPU_UART, 21, 0, 0),
+
+	/* BO */
+	GATE(CLK_GOUT_BO_BUS, "gout_cmu_bo_bus", "mout_cmu_bo_bus",
+	     CLK_CON_GAT_GATE_CLKCMU_BO_BUS, 21, 0, 0),
+
+};
+
+static const struct samsung_cmu_info top_cmu_info __initconst = {
+	.pll_clks		= cmu_top_pll_clks,
+	.nr_pll_clks		= ARRAY_SIZE(cmu_top_pll_clks),
+	.mux_clks		= cmu_top_mux_clks,
+	.nr_mux_clks		= ARRAY_SIZE(cmu_top_mux_clks),
+	.div_clks		= cmu_top_div_clks,
+	.nr_div_clks		= ARRAY_SIZE(cmu_top_div_clks),
+	.gate_clks		= cmu_top_gate_clks,
+	.nr_gate_clks		= ARRAY_SIZE(cmu_top_gate_clks),
+	.nr_clk_ids		= TOP_NR_CLK,
+	.clk_regs		= cmu_top_clk_regs,
+	.nr_clk_regs		= ARRAY_SIZE(cmu_top_clk_regs),
+};
+
+static void __init gs101_cmu_top_init(struct device_node *np)
+{
+	exynos_arm64_register_cmu(NULL, np, &top_cmu_info);
+}
+
+/* Register CMU_TOP early, as it's a dependency for other early domains */
+CLK_OF_DECLARE(gs101_cmu_top, "google,gs101-cmu-top",
+	       gs101_cmu_top_init);
-- 
2.42.0.609.gbb76f46606-goog


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH v2 11/20] clk: samsung: clk-gs101: add CMU_APM support

[Peter Griffin]

This patch adds all the registers for the APM clock controller unit.

We register all the muxes and dividers, but only a few of the
gates currently for PMU and GPIO.

One clock is marked CLK_IS_CRITICAL because the system
hangs if this clock is disabled.

Signed-off-by: Peter Griffin <peter.griffin@linaro.org>
---
 drivers/clk/samsung/clk-gs101.c | 301 ++++++++++++++++++++++++++++++++
 1 file changed, 301 insertions(+)

diff --git a/drivers/clk/samsung/clk-gs101.c b/drivers/clk/samsung/clk-gs101.c
index e2c62754b1eb..525f95e60665 100644
--- a/drivers/clk/samsung/clk-gs101.c
+++ b/drivers/clk/samsung/clk-gs101.c
@@ -19,6 +19,7 @@
 
 /* NOTE: Must be equal to the last clock ID increased by one */
 #define TOP_NR_CLK                     (CLK_GOUT_CMU_BOOST + 1)
+#define APM_NR_CLK                     (CLK_APM_PLL_DIV16_APM + 1)
 
 /* ---- CMU_TOP ------------------------------------------------------------- */
 
@@ -1549,3 +1550,303 @@ static void __init gs101_cmu_top_init(struct device_node *np)
 /* Register CMU_TOP early, as it's a dependency for other early domains */
 CLK_OF_DECLARE(gs101_cmu_top, "google,gs101-cmu-top",
 	       gs101_cmu_top_init);
+
+/* ---- CMU_APM ------------------------------------------------------------- */
+/* Register Offset definitions for CMU_APM (0x17400000) */
+#define APM_CMU_APM_CONTROLLER_OPTION							0x0800
+#define CLKOUT_CON_BLK_APM_CMU_APM_CLKOUT0						0x0810
+#define CLK_CON_MUX_MUX_CLKCMU_APM_FUNC							0x1000
+#define CLK_CON_MUX_MUX_CLKCMU_APM_FUNCSRC						0x1004
+#define CLK_CON_DIV_DIV_CLK_APM_BOOST							0x1800
+#define CLK_CON_DIV_DIV_CLK_APM_USI0_UART						0x1804
+#define CLK_CON_DIV_DIV_CLK_APM_USI0_USI						0x1808
+#define CLK_CON_DIV_DIV_CLK_APM_USI1_UART						0x180c
+#define CLK_CON_GAT_CLK_BLK_APM_UID_APM_CMU_APM_IPCLKPORT_PCLK				0x2000
+#define CLK_CON_GAT_CLK_BUS0_BOOST_OPTION1						0x2004
+#define CLK_CON_GAT_CLK_CMU_BOOST_OPTION1						0x2008
+#define CLK_CON_GAT_CLK_CORE_BOOST_OPTION1						0x200c
+#define CLK_CON_GAT_GATE_CLKCMU_APM_FUNC						0x2010
+#define CLK_CON_GAT_GOUT_BLK_APM_UID_APBIF_GPIO_ALIVE_IPCLKPORT_PCLK			0x2014
+#define CLK_CON_GAT_GOUT_BLK_APM_UID_APBIF_GPIO_FAR_ALIVE_IPCLKPORT_PCLK		0x2018
+#define CLK_CON_GAT_GOUT_BLK_APM_UID_APBIF_PMU_ALIVE_IPCLKPORT_PCLK			0x201c
+#define CLK_CON_GAT_GOUT_BLK_APM_UID_APBIF_RTC_IPCLKPORT_PCLK				0x2020
+#define CLK_CON_GAT_GOUT_BLK_APM_UID_APBIF_TRTC_IPCLKPORT_PCLK				0x2024
+#define CLK_CON_GAT_GOUT_BLK_APM_UID_APM_USI0_UART_IPCLKPORT_IPCLK			0x2028
+#define CLK_CON_GAT_GOUT_BLK_APM_UID_APM_USI0_UART_IPCLKPORT_PCLK			0x202c
+#define CLK_CON_GAT_GOUT_BLK_APM_UID_APM_USI0_USI_IPCLKPORT_IPCLK			0x2030
+#define CLK_CON_GAT_GOUT_BLK_APM_UID_APM_USI0_USI_IPCLKPORT_PCLK			0x2034
+#define CLK_CON_GAT_GOUT_BLK_APM_UID_APM_USI1_UART_IPCLKPORT_IPCLK			0x2038
+#define CLK_CON_GAT_GOUT_BLK_APM_UID_APM_USI1_UART_IPCLKPORT_PCLK			0x203c
+#define CLK_CON_GAT_GOUT_BLK_APM_UID_D_TZPC_APM_IPCLKPORT_PCLK				0x2040
+#define CLK_CON_GAT_GOUT_BLK_APM_UID_GPC_APM_IPCLKPORT_PCLK				0x2044
+#define CLK_CON_GAT_GOUT_BLK_APM_UID_GREBEINTEGRATION_IPCLKPORT_HCLK			0x2048
+#define CLK_CON_GAT_GOUT_BLK_APM_UID_INTMEM_IPCLKPORT_ACLK				0x204c
+#define CLK_CON_GAT_GOUT_BLK_APM_UID_INTMEM_IPCLKPORT_PCLK				0x2050
+#define CLK_CON_GAT_GOUT_BLK_APM_UID_LHM_AXI_G_SWD_IPCLKPORT_I_CLK			0x2054
+#define CLK_CON_GAT_GOUT_BLK_APM_UID_LHM_AXI_P_AOCAPM_IPCLKPORT_I_CLK			0x2058
+#define CLK_CON_GAT_GOUT_BLK_APM_UID_LHM_AXI_P_APM_IPCLKPORT_I_CLK			0x205c
+#define CLK_CON_GAT_GOUT_BLK_APM_UID_LHS_AXI_D_APM_IPCLKPORT_I_CLK			0x2060
+#define CLK_CON_GAT_GOUT_BLK_APM_UID_LHS_AXI_G_DBGCORE_IPCLKPORT_I_CLK			0x2064
+#define CLK_CON_GAT_GOUT_BLK_APM_UID_LHS_AXI_G_SCAN2DRAM_IPCLKPORT_I_CLK		0x2068
+#define CLK_CON_GAT_GOUT_BLK_APM_UID_MAILBOX_APM_AOC_IPCLKPORT_PCLK			0x206c
+#define CLK_CON_GAT_GOUT_BLK_APM_UID_MAILBOX_APM_AP_IPCLKPORT_PCLK			0x2070
+#define CLK_CON_GAT_GOUT_BLK_APM_UID_MAILBOX_APM_GSA_IPCLKPORT_PCLK			0x2074
+#define CLK_CON_GAT_GOUT_BLK_APM_UID_MAILBOX_APM_SWD_IPCLKPORT_PCLK			0x207c
+#define CLK_CON_GAT_GOUT_BLK_APM_UID_MAILBOX_APM_TPU_IPCLKPORT_PCLK			0x2080
+#define CLK_CON_GAT_GOUT_BLK_APM_UID_MAILBOX_AP_AOC_IPCLKPORT_PCLK			0x2084
+#define CLK_CON_GAT_GOUT_BLK_APM_UID_MAILBOX_AP_DBGCORE_IPCLKPORT_PCLK			0x2088
+#define CLK_CON_GAT_GOUT_BLK_APM_UID_PMU_INTR_GEN_IPCLKPORT_PCLK			0x208c
+#define CLK_CON_GAT_GOUT_BLK_APM_UID_ROM_CRC32_HOST_IPCLKPORT_ACLK			0x2090
+#define CLK_CON_GAT_GOUT_BLK_APM_UID_ROM_CRC32_HOST_IPCLKPORT_PCLK			0x2094
+#define CLK_CON_GAT_GOUT_BLK_APM_UID_RSTNSYNC_CLK_APM_BUS_IPCLKPORT_CLK			0x2098
+#define CLK_CON_GAT_GOUT_BLK_APM_UID_RSTNSYNC_CLK_APM_USI0_UART_IPCLKPORT_CLK		0x209c
+#define CLK_CON_GAT_GOUT_BLK_APM_UID_RSTNSYNC_CLK_APM_USI0_USI_IPCLKPORT_CLK		0x20a0
+#define CLK_CON_GAT_GOUT_BLK_APM_UID_RSTNSYNC_CLK_APM_USI1_UART_IPCLKPORT_CLK		0x20a4
+#define CLK_CON_GAT_GOUT_BLK_APM_UID_SPEEDY_APM_IPCLKPORT_PCLK				0x20a8
+#define CLK_CON_GAT_GOUT_BLK_APM_UID_SPEEDY_SUB_APM_IPCLKPORT_PCLK			0x20ac
+#define CLK_CON_GAT_GOUT_BLK_APM_UID_SSMT_D_APM_IPCLKPORT_ACLK				0x20b0
+#define CLK_CON_GAT_GOUT_BLK_APM_UID_SSMT_D_APM_IPCLKPORT_PCLK				0x20b4
+#define CLK_CON_GAT_GOUT_BLK_APM_UID_SSMT_G_DBGCORE_IPCLKPORT_ACLK			0x20b8
+#define CLK_CON_GAT_GOUT_BLK_APM_UID_SSMT_G_DBGCORE_IPCLKPORT_PCLK			0x20bc
+#define CLK_CON_GAT_GOUT_BLK_APM_UID_SS_DBGCORE_IPCLKPORT_SS_DBGCORE_IPCLKPORT_HCLK	0x20c0
+#define CLK_CON_GAT_GOUT_BLK_APM_UID_SYSMMU_D_APM_IPCLKPORT_CLK_S2			0x20c4
+#define CLK_CON_GAT_GOUT_BLK_APM_UID_SYSREG_APM_IPCLKPORT_PCLK				0x20cc
+#define CLK_CON_GAT_GOUT_BLK_APM_UID_UASC_APM_IPCLKPORT_ACLK				0x20d0
+#define CLK_CON_GAT_GOUT_BLK_APM_UID_UASC_APM_IPCLKPORT_PCLK				0x20d4
+#define CLK_CON_GAT_GOUT_BLK_APM_UID_UASC_DBGCORE_IPCLKPORT_ACLK			0x20d8
+#define CLK_CON_GAT_GOUT_BLK_APM_UID_UASC_DBGCORE_IPCLKPORT_PCLK			0x20dc
+#define CLK_CON_GAT_GOUT_BLK_APM_UID_UASC_G_SWD_IPCLKPORT_ACLK				0x20e0
+#define CLK_CON_GAT_GOUT_BLK_APM_UID_UASC_G_SWD_IPCLKPORT_PCLK				0x20e4
+#define CLK_CON_GAT_GOUT_BLK_APM_UID_UASC_P_AOCAPM_IPCLKPORT_ACLK			0x20e8
+#define CLK_CON_GAT_GOUT_BLK_APM_UID_UASC_P_AOCAPM_IPCLKPORT_PCLK			0x20ec
+#define CLK_CON_GAT_GOUT_BLK_APM_UID_UASC_P_APM_IPCLKPORT_ACLK				0x20f0
+#define CLK_CON_GAT_GOUT_BLK_APM_UID_UASC_P_APM_IPCLKPORT_PCLK				0x20f4
+#define CLK_CON_GAT_GOUT_BLK_APM_UID_WDT_APM_IPCLKPORT_PCLK				0x20f8
+#define CLK_CON_GAT_GOUT_BLK_APM_UID_XIU_DP_APM_IPCLKPORT_ACLK				0x20fc
+#define PCH_CON_LHM_AXI_G_SWD_PCH			0x3000
+#define PCH_CON_LHM_AXI_P_AOCAPM_PCH			0x3004
+#define PCH_CON_LHM_AXI_P_APM_PCH			0x3008
+#define PCH_CON_LHS_AXI_D_APM_PCH			0x300c
+#define PCH_CON_LHS_AXI_G_DBGCORE_PCH			0x3010
+#define PCH_CON_LHS_AXI_G_SCAN2DRAM_PCH			0x3014
+#define QCH_CON_APBIF_GPIO_ALIVE_QCH			0x3018
+#define QCH_CON_APBIF_GPIO_FAR_ALIVE_QCH		0x301c
+#define QCH_CON_APBIF_PMU_ALIVE_QCH			0x3020
+#define QCH_CON_APBIF_RTC_QCH				0x3024
+#define QCH_CON_APBIF_TRTC_QCH				0x3028
+#define QCH_CON_APM_CMU_APM_QCH				0x302c
+#define QCH_CON_APM_USI0_UART_QCH			0x3030
+#define QCH_CON_APM_USI0_USI_QCH			0x3034
+#define QCH_CON_APM_USI1_UART_QCH			0x3038
+#define QCH_CON_D_TZPC_APM_QCH				0x303c
+#define QCH_CON_GPC_APM_QCH				0x3040
+#define QCH_CON_GREBEINTEGRATION_QCH_DBG		0x3044
+#define QCH_CON_GREBEINTEGRATION_QCH_GREBE		0x3048
+#define QCH_CON_INTMEM_QCH				0x304c
+#define QCH_CON_LHM_AXI_G_SWD_QCH			0x3050
+#define QCH_CON_LHM_AXI_P_AOCAPM_QCH			0x3054
+#define QCH_CON_LHM_AXI_P_APM_QCH			0x3058
+#define QCH_CON_LHS_AXI_D_APM_QCH			0x305c
+#define QCH_CON_LHS_AXI_G_DBGCORE_QCH			0x3060
+#define QCH_CON_LHS_AXI_G_SCAN2DRAM_QCH			0x3064
+#define QCH_CON_MAILBOX_APM_AOC_QCH			0x3068
+#define QCH_CON_MAILBOX_APM_AP_QCH			0x306c
+#define QCH_CON_MAILBOX_APM_GSA_QCH			0x3070
+#define QCH_CON_MAILBOX_APM_SWD_QCH			0x3078
+#define QCH_CON_MAILBOX_APM_TPU_QCH			0x307c
+#define QCH_CON_MAILBOX_AP_AOC_QCH			0x3080
+#define QCH_CON_MAILBOX_AP_DBGCORE_QCH			0x3084
+#define QCH_CON_PMU_INTR_GEN_QCH			0x3088
+#define QCH_CON_ROM_CRC32_HOST_QCH			0x308c
+#define QCH_CON_RSTNSYNC_CLK_APM_BUS_QCH_GREBE		0x3090
+#define QCH_CON_RSTNSYNC_CLK_APM_BUS_QCH_GREBE_DBG	0x3094
+#define QCH_CON_SPEEDY_APM_QCH				0x3098
+#define QCH_CON_SPEEDY_SUB_APM_QCH			0x309c
+#define QCH_CON_SSMT_D_APM_QCH				0x30a0
+#define QCH_CON_SSMT_G_DBGCORE_QCH			0x30a4
+#define QCH_CON_SS_DBGCORE_QCH_DBG			0x30a8
+#define QCH_CON_SS_DBGCORE_QCH_GREBE			0x30ac
+#define QCH_CON_SYSMMU_D_APM_QCH			0x30b0
+#define QCH_CON_SYSREG_APM_QCH				0x30b8
+#define QCH_CON_UASC_APM_QCH				0x30bc
+#define QCH_CON_UASC_DBGCORE_QCH			0x30c0
+#define QCH_CON_UASC_G_SWD_QCH				0x30c4
+#define QCH_CON_UASC_P_AOCAPM_QCH			0x30c8
+#define QCH_CON_UASC_P_APM_QCH				0x30cc
+#define QCH_CON_WDT_APM_QCH				0x30d0
+#define QUEUE_CTRL_REG_BLK_APM_CMU_APM			0x3c00
+
+static const unsigned long apm_clk_regs[] __initconst = {
+	APM_CMU_APM_CONTROLLER_OPTION,
+	CLKOUT_CON_BLK_APM_CMU_APM_CLKOUT0,
+	CLK_CON_MUX_MUX_CLKCMU_APM_FUNC,
+	CLK_CON_MUX_MUX_CLKCMU_APM_FUNCSRC,
+	CLK_CON_DIV_DIV_CLK_APM_BOOST,
+	CLK_CON_DIV_DIV_CLK_APM_USI0_UART,
+	CLK_CON_DIV_DIV_CLK_APM_USI0_USI,
+	CLK_CON_DIV_DIV_CLK_APM_USI1_UART,
+	CLK_CON_GAT_CLK_BLK_APM_UID_APM_CMU_APM_IPCLKPORT_PCLK,
+	CLK_CON_GAT_CLK_BUS0_BOOST_OPTION1,
+	CLK_CON_GAT_CLK_CMU_BOOST_OPTION1,
+	CLK_CON_GAT_CLK_CORE_BOOST_OPTION1,
+	CLK_CON_GAT_GATE_CLKCMU_APM_FUNC,
+	CLK_CON_GAT_GOUT_BLK_APM_UID_APBIF_GPIO_ALIVE_IPCLKPORT_PCLK,
+	CLK_CON_GAT_GOUT_BLK_APM_UID_APBIF_GPIO_FAR_ALIVE_IPCLKPORT_PCLK,
+	CLK_CON_GAT_GOUT_BLK_APM_UID_APBIF_PMU_ALIVE_IPCLKPORT_PCLK,
+	CLK_CON_GAT_GOUT_BLK_APM_UID_APBIF_RTC_IPCLKPORT_PCLK,
+	CLK_CON_GAT_GOUT_BLK_APM_UID_APBIF_TRTC_IPCLKPORT_PCLK,
+	CLK_CON_GAT_GOUT_BLK_APM_UID_APM_USI0_UART_IPCLKPORT_IPCLK,
+	CLK_CON_GAT_GOUT_BLK_APM_UID_APM_USI0_UART_IPCLKPORT_PCLK,
+	CLK_CON_GAT_GOUT_BLK_APM_UID_APM_USI0_USI_IPCLKPORT_IPCLK,
+	CLK_CON_GAT_GOUT_BLK_APM_UID_APM_USI0_USI_IPCLKPORT_PCLK,
+	CLK_CON_GAT_GOUT_BLK_APM_UID_APM_USI1_UART_IPCLKPORT_IPCLK,
+	CLK_CON_GAT_GOUT_BLK_APM_UID_APM_USI1_UART_IPCLKPORT_PCLK,
+	CLK_CON_GAT_GOUT_BLK_APM_UID_D_TZPC_APM_IPCLKPORT_PCLK,
+	CLK_CON_GAT_GOUT_BLK_APM_UID_GPC_APM_IPCLKPORT_PCLK,
+	CLK_CON_GAT_GOUT_BLK_APM_UID_GREBEINTEGRATION_IPCLKPORT_HCLK,
+	CLK_CON_GAT_GOUT_BLK_APM_UID_INTMEM_IPCLKPORT_ACLK,
+	CLK_CON_GAT_GOUT_BLK_APM_UID_INTMEM_IPCLKPORT_PCLK,
+	CLK_CON_GAT_GOUT_BLK_APM_UID_LHM_AXI_G_SWD_IPCLKPORT_I_CLK,
+	CLK_CON_GAT_GOUT_BLK_APM_UID_LHM_AXI_P_AOCAPM_IPCLKPORT_I_CLK,
+	CLK_CON_GAT_GOUT_BLK_APM_UID_LHM_AXI_P_APM_IPCLKPORT_I_CLK,
+	CLK_CON_GAT_GOUT_BLK_APM_UID_LHS_AXI_D_APM_IPCLKPORT_I_CLK,
+	CLK_CON_GAT_GOUT_BLK_APM_UID_LHS_AXI_G_DBGCORE_IPCLKPORT_I_CLK,
+	CLK_CON_GAT_GOUT_BLK_APM_UID_LHS_AXI_G_SCAN2DRAM_IPCLKPORT_I_CLK,
+	CLK_CON_GAT_GOUT_BLK_APM_UID_MAILBOX_APM_AOC_IPCLKPORT_PCLK,
+	CLK_CON_GAT_GOUT_BLK_APM_UID_MAILBOX_APM_AP_IPCLKPORT_PCLK,
+	CLK_CON_GAT_GOUT_BLK_APM_UID_MAILBOX_APM_GSA_IPCLKPORT_PCLK,
+	CLK_CON_GAT_GOUT_BLK_APM_UID_MAILBOX_APM_SWD_IPCLKPORT_PCLK,
+	CLK_CON_GAT_GOUT_BLK_APM_UID_MAILBOX_APM_TPU_IPCLKPORT_PCLK,
+	CLK_CON_GAT_GOUT_BLK_APM_UID_MAILBOX_AP_AOC_IPCLKPORT_PCLK,
+	CLK_CON_GAT_GOUT_BLK_APM_UID_MAILBOX_AP_DBGCORE_IPCLKPORT_PCLK,
+	CLK_CON_GAT_GOUT_BLK_APM_UID_PMU_INTR_GEN_IPCLKPORT_PCLK,
+	CLK_CON_GAT_GOUT_BLK_APM_UID_ROM_CRC32_HOST_IPCLKPORT_ACLK,
+	CLK_CON_GAT_GOUT_BLK_APM_UID_ROM_CRC32_HOST_IPCLKPORT_PCLK,
+	CLK_CON_GAT_GOUT_BLK_APM_UID_RSTNSYNC_CLK_APM_BUS_IPCLKPORT_CLK,
+	CLK_CON_GAT_GOUT_BLK_APM_UID_RSTNSYNC_CLK_APM_USI0_UART_IPCLKPORT_CLK,
+	CLK_CON_GAT_GOUT_BLK_APM_UID_RSTNSYNC_CLK_APM_USI0_USI_IPCLKPORT_CLK,
+	CLK_CON_GAT_GOUT_BLK_APM_UID_RSTNSYNC_CLK_APM_USI1_UART_IPCLKPORT_CLK,
+	CLK_CON_GAT_GOUT_BLK_APM_UID_SPEEDY_APM_IPCLKPORT_PCLK,
+	CLK_CON_GAT_GOUT_BLK_APM_UID_SPEEDY_SUB_APM_IPCLKPORT_PCLK,
+	CLK_CON_GAT_GOUT_BLK_APM_UID_SSMT_D_APM_IPCLKPORT_ACLK,
+	CLK_CON_GAT_GOUT_BLK_APM_UID_SSMT_D_APM_IPCLKPORT_PCLK,
+	CLK_CON_GAT_GOUT_BLK_APM_UID_SSMT_G_DBGCORE_IPCLKPORT_ACLK,
+	CLK_CON_GAT_GOUT_BLK_APM_UID_SSMT_G_DBGCORE_IPCLKPORT_PCLK,
+	CLK_CON_GAT_GOUT_BLK_APM_UID_SS_DBGCORE_IPCLKPORT_SS_DBGCORE_IPCLKPORT_HCLK,
+	CLK_CON_GAT_GOUT_BLK_APM_UID_SYSMMU_D_APM_IPCLKPORT_CLK_S2,
+	CLK_CON_GAT_GOUT_BLK_APM_UID_SYSREG_APM_IPCLKPORT_PCLK,
+	CLK_CON_GAT_GOUT_BLK_APM_UID_UASC_APM_IPCLKPORT_ACLK,
+	CLK_CON_GAT_GOUT_BLK_APM_UID_UASC_APM_IPCLKPORT_PCLK,
+	CLK_CON_GAT_GOUT_BLK_APM_UID_UASC_DBGCORE_IPCLKPORT_ACLK,
+	CLK_CON_GAT_GOUT_BLK_APM_UID_UASC_DBGCORE_IPCLKPORT_PCLK,
+	CLK_CON_GAT_GOUT_BLK_APM_UID_UASC_G_SWD_IPCLKPORT_ACLK,
+	CLK_CON_GAT_GOUT_BLK_APM_UID_UASC_G_SWD_IPCLKPORT_PCLK,
+	CLK_CON_GAT_GOUT_BLK_APM_UID_UASC_P_AOCAPM_IPCLKPORT_ACLK,
+	CLK_CON_GAT_GOUT_BLK_APM_UID_UASC_P_AOCAPM_IPCLKPORT_PCLK,
+	CLK_CON_GAT_GOUT_BLK_APM_UID_UASC_P_APM_IPCLKPORT_ACLK,
+	CLK_CON_GAT_GOUT_BLK_APM_UID_UASC_P_APM_IPCLKPORT_PCLK,
+	CLK_CON_GAT_GOUT_BLK_APM_UID_WDT_APM_IPCLKPORT_PCLK,
+	CLK_CON_GAT_GOUT_BLK_APM_UID_XIU_DP_APM_IPCLKPORT_ACLK,
+};
+
+PNAME(mout_apm_func_p)	= { "oscclk_apmgsa", "mout_apm_funcsrc", "pad_clk_apm" };
+PNAME(mout_apm_funcsrc_p) = { "pll_alv_div2_apm", "pll_alv_div4_apm", "pll_alv_div16_apm" };
+
+static const struct samsung_fixed_rate_clock apm_fixed_clks[] __initconst = {
+	FRATE(CLK_APM_PLL_DIV2_APM, "clk_apm_pll_div2_apm", NULL, 0, 393216000),
+	FRATE(CLK_APM_PLL_DIV4_APM, "clk_apm_pll_div4_apm", NULL, 0, 196608000),
+	FRATE(CLK_APM_PLL_DIV16_APM, "clk_apm_pll_div16_apm", NULL, 0, 49152000),
+};
+
+static const struct samsung_mux_clock apm_mux_clks[] __initconst = {
+	MUX(CLK_MOUT_APM_FUNC, "mout_apm_func", mout_apm_func_p,
+	    CLK_CON_MUX_MUX_CLKCMU_APM_FUNC, 4, 1),
+	MUX(CLK_MOUT_APM_FUNCSRC, "mout_apm_funcsrc", mout_apm_funcsrc_p,
+	    CLK_CON_MUX_MUX_CLKCMU_APM_FUNCSRC, 3, 1),
+};
+
+static const struct samsung_div_clock apm_div_clks[] __initconst = {
+	DIV(CLK_DOUT_APM_BOOST, "dout_apm_boost", "gout_apm_func",
+	    CLK_CON_DIV_DIV_CLK_APM_BOOST, 0, 1),
+	DIV(CLK_DOUT_APM_USI0_UART, "dout_apm_usi0_uart", "gout_apm_func",
+	    CLK_CON_DIV_DIV_CLK_APM_USI0_UART, 0, 7),
+	DIV(CLK_DOUT_APM_USI0_USI, "dout_apm_usi0_usi", "gout_apm_func",
+	    CLK_CON_DIV_DIV_CLK_APM_USI0_USI, 0, 7),
+	DIV(CLK_DOUT_APM_USI1_UART, "dout_apm_usi1_uart", "gout_apm_func",
+	    CLK_CON_DIV_DIV_CLK_APM_USI1_UART, 0, 7),
+};
+
+static const struct samsung_gate_clock apm_gate_clks[] __initconst = {
+	GATE(CLK_GOUT_APM_FUNC, "gout_apm_func", "mout_apm_func",
+	     CLK_CON_GAT_GATE_CLKCMU_APM_FUNC, 21, 0, 0),
+
+	GATE(CLK_GOUT_APM_UID_APBIF_GPIO_ALIVE_IPCLKPORT_PCLK,
+	     "gout_apm_gpio_alive_ipclkport_pclk", "gout_apm_func",
+	     CLK_CON_GAT_GOUT_BLK_APM_UID_APBIF_GPIO_ALIVE_IPCLKPORT_PCLK,
+	     21, 0, 0),
+
+	GATE(CLK_GOUT_APM_UID_APBIF_GPIO_FAR_ALIVE_IPCLKPORT_PCLK,
+	     "gout_apm_gpio_far_alive_ipclkport_pclk", "gout_apm_func",
+	     CLK_CON_GAT_GOUT_BLK_APM_UID_APBIF_GPIO_FAR_ALIVE_IPCLKPORT_PCLK,
+	     21, 0, 0),
+
+	GATE(CLK_GOUT_APM_UID_APBIF_PMU_ALIVE_IPCLKPORT_PCLK,
+	     "gout_apm_pmu_alive_ipclkport_pclk", "gout_apm_func",
+	     CLK_CON_GAT_GOUT_BLK_APM_UID_APBIF_PMU_ALIVE_IPCLKPORT_PCLK,
+	     21, CLK_IS_CRITICAL, 0),
+
+	GATE(CLK_GOUT_APM_UID_SYSREG_APM_IPCLKPORT_PCLK,
+	     "gout_apm_sysreg_apm_ipclkport_pclk", "gout_apm_func",
+	     CLK_CON_GAT_GOUT_BLK_APM_UID_SYSREG_APM_IPCLKPORT_PCLK,
+	     21, 0, 0),
+};
+
+static const struct samsung_cmu_info apm_cmu_info __initconst = {
+	.mux_clks		= apm_mux_clks,
+	.nr_mux_clks		= ARRAY_SIZE(apm_mux_clks),
+	.div_clks		= apm_div_clks,
+	.nr_div_clks		= ARRAY_SIZE(apm_div_clks),
+	.gate_clks		= apm_gate_clks,
+	.nr_gate_clks		= ARRAY_SIZE(apm_gate_clks),
+	.fixed_clks		= apm_fixed_clks,
+	.nr_fixed_clks		= ARRAY_SIZE(apm_fixed_clks),
+	.nr_clk_ids		= APM_NR_CLK,
+	.clk_regs		= apm_clk_regs,
+	.nr_clk_regs		= ARRAY_SIZE(apm_clk_regs),
+};
+
+/* ---- platform_driver ----------------------------------------------------- */
+
+static int __init gs101_cmu_probe(struct platform_device *pdev)
+{
+	const struct samsung_cmu_info *info;
+	struct device *dev = &pdev->dev;
+
+	info = of_device_get_match_data(dev);
+	exynos_arm64_register_cmu(dev, dev->of_node, info);
+
+	return 0;
+}
+
+static const struct of_device_id gs101_cmu_of_match[] = {
+	{
+		.compatible = "google,gs101-cmu-apm",
+		.data = &apm_cmu_info,
+	}, {
+	},
+};
+
+static struct platform_driver gs101_cmu_driver __refdata = {
+	.driver	= {
+		.name = "gs101-cmu",
+		.of_match_table = gs101_cmu_of_match,
+		.suppress_bind_attrs = true,
+	},
+	.probe = gs101_cmu_probe,
+};
+
+static int __init gs101_cmu_init(void)
+{
+	return platform_driver_register(&gs101_cmu_driver);
+}
+core_initcall(gs101_cmu_init);
-- 
2.42.0.609.gbb76f46606-goog

[PATCH v2 11/20] clk: samsung: clk-gs101: add CMU_APM support

[Peter Griffin]

This patch adds all the registers for the APM clock controller unit.

We register all the muxes and dividers, but only a few of the
gates currently for PMU and GPIO.

One clock is marked CLK_IS_CRITICAL because the system
hangs if this clock is disabled.

Signed-off-by: Peter Griffin <peter.griffin@linaro.org>
---
 drivers/clk/samsung/clk-gs101.c | 301 ++++++++++++++++++++++++++++++++
 1 file changed, 301 insertions(+)

diff --git a/drivers/clk/samsung/clk-gs101.c b/drivers/clk/samsung/clk-gs101.c
index e2c62754b1eb..525f95e60665 100644
--- a/drivers/clk/samsung/clk-gs101.c
+++ b/drivers/clk/samsung/clk-gs101.c
@@ -19,6 +19,7 @@
 
 /* NOTE: Must be equal to the last clock ID increased by one */
 #define TOP_NR_CLK                     (CLK_GOUT_CMU_BOOST + 1)
+#define APM_NR_CLK                     (CLK_APM_PLL_DIV16_APM + 1)
 
 /* ---- CMU_TOP ------------------------------------------------------------- */
 
@@ -1549,3 +1550,303 @@ static void __init gs101_cmu_top_init(struct device_node *np)
 /* Register CMU_TOP early, as it's a dependency for other early domains */
 CLK_OF_DECLARE(gs101_cmu_top, "google,gs101-cmu-top",
 	       gs101_cmu_top_init);
+
+/* ---- CMU_APM ------------------------------------------------------------- */
+/* Register Offset definitions for CMU_APM (0x17400000) */
+#define APM_CMU_APM_CONTROLLER_OPTION							0x0800
+#define CLKOUT_CON_BLK_APM_CMU_APM_CLKOUT0						0x0810
+#define CLK_CON_MUX_MUX_CLKCMU_APM_FUNC							0x1000
+#define CLK_CON_MUX_MUX_CLKCMU_APM_FUNCSRC						0x1004
+#define CLK_CON_DIV_DIV_CLK_APM_BOOST							0x1800
+#define CLK_CON_DIV_DIV_CLK_APM_USI0_UART						0x1804
+#define CLK_CON_DIV_DIV_CLK_APM_USI0_USI						0x1808
+#define CLK_CON_DIV_DIV_CLK_APM_USI1_UART						0x180c
+#define CLK_CON_GAT_CLK_BLK_APM_UID_APM_CMU_APM_IPCLKPORT_PCLK				0x2000
+#define CLK_CON_GAT_CLK_BUS0_BOOST_OPTION1						0x2004
+#define CLK_CON_GAT_CLK_CMU_BOOST_OPTION1						0x2008
+#define CLK_CON_GAT_CLK_CORE_BOOST_OPTION1						0x200c
+#define CLK_CON_GAT_GATE_CLKCMU_APM_FUNC						0x2010
+#define CLK_CON_GAT_GOUT_BLK_APM_UID_APBIF_GPIO_ALIVE_IPCLKPORT_PCLK			0x2014
+#define CLK_CON_GAT_GOUT_BLK_APM_UID_APBIF_GPIO_FAR_ALIVE_IPCLKPORT_PCLK		0x2018
+#define CLK_CON_GAT_GOUT_BLK_APM_UID_APBIF_PMU_ALIVE_IPCLKPORT_PCLK			0x201c
+#define CLK_CON_GAT_GOUT_BLK_APM_UID_APBIF_RTC_IPCLKPORT_PCLK				0x2020
+#define CLK_CON_GAT_GOUT_BLK_APM_UID_APBIF_TRTC_IPCLKPORT_PCLK				0x2024
+#define CLK_CON_GAT_GOUT_BLK_APM_UID_APM_USI0_UART_IPCLKPORT_IPCLK			0x2028
+#define CLK_CON_GAT_GOUT_BLK_APM_UID_APM_USI0_UART_IPCLKPORT_PCLK			0x202c
+#define CLK_CON_GAT_GOUT_BLK_APM_UID_APM_USI0_USI_IPCLKPORT_IPCLK			0x2030
+#define CLK_CON_GAT_GOUT_BLK_APM_UID_APM_USI0_USI_IPCLKPORT_PCLK			0x2034
+#define CLK_CON_GAT_GOUT_BLK_APM_UID_APM_USI1_UART_IPCLKPORT_IPCLK			0x2038
+#define CLK_CON_GAT_GOUT_BLK_APM_UID_APM_USI1_UART_IPCLKPORT_PCLK			0x203c
+#define CLK_CON_GAT_GOUT_BLK_APM_UID_D_TZPC_APM_IPCLKPORT_PCLK				0x2040
+#define CLK_CON_GAT_GOUT_BLK_APM_UID_GPC_APM_IPCLKPORT_PCLK				0x2044
+#define CLK_CON_GAT_GOUT_BLK_APM_UID_GREBEINTEGRATION_IPCLKPORT_HCLK			0x2048
+#define CLK_CON_GAT_GOUT_BLK_APM_UID_INTMEM_IPCLKPORT_ACLK				0x204c
+#define CLK_CON_GAT_GOUT_BLK_APM_UID_INTMEM_IPCLKPORT_PCLK				0x2050
+#define CLK_CON_GAT_GOUT_BLK_APM_UID_LHM_AXI_G_SWD_IPCLKPORT_I_CLK			0x2054
+#define CLK_CON_GAT_GOUT_BLK_APM_UID_LHM_AXI_P_AOCAPM_IPCLKPORT_I_CLK			0x2058
+#define CLK_CON_GAT_GOUT_BLK_APM_UID_LHM_AXI_P_APM_IPCLKPORT_I_CLK			0x205c
+#define CLK_CON_GAT_GOUT_BLK_APM_UID_LHS_AXI_D_APM_IPCLKPORT_I_CLK			0x2060
+#define CLK_CON_GAT_GOUT_BLK_APM_UID_LHS_AXI_G_DBGCORE_IPCLKPORT_I_CLK			0x2064
+#define CLK_CON_GAT_GOUT_BLK_APM_UID_LHS_AXI_G_SCAN2DRAM_IPCLKPORT_I_CLK		0x2068
+#define CLK_CON_GAT_GOUT_BLK_APM_UID_MAILBOX_APM_AOC_IPCLKPORT_PCLK			0x206c
+#define CLK_CON_GAT_GOUT_BLK_APM_UID_MAILBOX_APM_AP_IPCLKPORT_PCLK			0x2070
+#define CLK_CON_GAT_GOUT_BLK_APM_UID_MAILBOX_APM_GSA_IPCLKPORT_PCLK			0x2074
+#define CLK_CON_GAT_GOUT_BLK_APM_UID_MAILBOX_APM_SWD_IPCLKPORT_PCLK			0x207c
+#define CLK_CON_GAT_GOUT_BLK_APM_UID_MAILBOX_APM_TPU_IPCLKPORT_PCLK			0x2080
+#define CLK_CON_GAT_GOUT_BLK_APM_UID_MAILBOX_AP_AOC_IPCLKPORT_PCLK			0x2084
+#define CLK_CON_GAT_GOUT_BLK_APM_UID_MAILBOX_AP_DBGCORE_IPCLKPORT_PCLK			0x2088
+#define CLK_CON_GAT_GOUT_BLK_APM_UID_PMU_INTR_GEN_IPCLKPORT_PCLK			0x208c
+#define CLK_CON_GAT_GOUT_BLK_APM_UID_ROM_CRC32_HOST_IPCLKPORT_ACLK			0x2090
+#define CLK_CON_GAT_GOUT_BLK_APM_UID_ROM_CRC32_HOST_IPCLKPORT_PCLK			0x2094
+#define CLK_CON_GAT_GOUT_BLK_APM_UID_RSTNSYNC_CLK_APM_BUS_IPCLKPORT_CLK			0x2098
+#define CLK_CON_GAT_GOUT_BLK_APM_UID_RSTNSYNC_CLK_APM_USI0_UART_IPCLKPORT_CLK		0x209c
+#define CLK_CON_GAT_GOUT_BLK_APM_UID_RSTNSYNC_CLK_APM_USI0_USI_IPCLKPORT_CLK		0x20a0
+#define CLK_CON_GAT_GOUT_BLK_APM_UID_RSTNSYNC_CLK_APM_USI1_UART_IPCLKPORT_CLK		0x20a4
+#define CLK_CON_GAT_GOUT_BLK_APM_UID_SPEEDY_APM_IPCLKPORT_PCLK				0x20a8
+#define CLK_CON_GAT_GOUT_BLK_APM_UID_SPEEDY_SUB_APM_IPCLKPORT_PCLK			0x20ac
+#define CLK_CON_GAT_GOUT_BLK_APM_UID_SSMT_D_APM_IPCLKPORT_ACLK				0x20b0
+#define CLK_CON_GAT_GOUT_BLK_APM_UID_SSMT_D_APM_IPCLKPORT_PCLK				0x20b4
+#define CLK_CON_GAT_GOUT_BLK_APM_UID_SSMT_G_DBGCORE_IPCLKPORT_ACLK			0x20b8
+#define CLK_CON_GAT_GOUT_BLK_APM_UID_SSMT_G_DBGCORE_IPCLKPORT_PCLK			0x20bc
+#define CLK_CON_GAT_GOUT_BLK_APM_UID_SS_DBGCORE_IPCLKPORT_SS_DBGCORE_IPCLKPORT_HCLK	0x20c0
+#define CLK_CON_GAT_GOUT_BLK_APM_UID_SYSMMU_D_APM_IPCLKPORT_CLK_S2			0x20c4
+#define CLK_CON_GAT_GOUT_BLK_APM_UID_SYSREG_APM_IPCLKPORT_PCLK				0x20cc
+#define CLK_CON_GAT_GOUT_BLK_APM_UID_UASC_APM_IPCLKPORT_ACLK				0x20d0
+#define CLK_CON_GAT_GOUT_BLK_APM_UID_UASC_APM_IPCLKPORT_PCLK				0x20d4
+#define CLK_CON_GAT_GOUT_BLK_APM_UID_UASC_DBGCORE_IPCLKPORT_ACLK			0x20d8
+#define CLK_CON_GAT_GOUT_BLK_APM_UID_UASC_DBGCORE_IPCLKPORT_PCLK			0x20dc
+#define CLK_CON_GAT_GOUT_BLK_APM_UID_UASC_G_SWD_IPCLKPORT_ACLK				0x20e0
+#define CLK_CON_GAT_GOUT_BLK_APM_UID_UASC_G_SWD_IPCLKPORT_PCLK				0x20e4
+#define CLK_CON_GAT_GOUT_BLK_APM_UID_UASC_P_AOCAPM_IPCLKPORT_ACLK			0x20e8
+#define CLK_CON_GAT_GOUT_BLK_APM_UID_UASC_P_AOCAPM_IPCLKPORT_PCLK			0x20ec
+#define CLK_CON_GAT_GOUT_BLK_APM_UID_UASC_P_APM_IPCLKPORT_ACLK				0x20f0
+#define CLK_CON_GAT_GOUT_BLK_APM_UID_UASC_P_APM_IPCLKPORT_PCLK				0x20f4
+#define CLK_CON_GAT_GOUT_BLK_APM_UID_WDT_APM_IPCLKPORT_PCLK				0x20f8
+#define CLK_CON_GAT_GOUT_BLK_APM_UID_XIU_DP_APM_IPCLKPORT_ACLK				0x20fc
+#define PCH_CON_LHM_AXI_G_SWD_PCH			0x3000
+#define PCH_CON_LHM_AXI_P_AOCAPM_PCH			0x3004
+#define PCH_CON_LHM_AXI_P_APM_PCH			0x3008
+#define PCH_CON_LHS_AXI_D_APM_PCH			0x300c
+#define PCH_CON_LHS_AXI_G_DBGCORE_PCH			0x3010
+#define PCH_CON_LHS_AXI_G_SCAN2DRAM_PCH			0x3014
+#define QCH_CON_APBIF_GPIO_ALIVE_QCH			0x3018
+#define QCH_CON_APBIF_GPIO_FAR_ALIVE_QCH		0x301c
+#define QCH_CON_APBIF_PMU_ALIVE_QCH			0x3020
+#define QCH_CON_APBIF_RTC_QCH				0x3024
+#define QCH_CON_APBIF_TRTC_QCH				0x3028
+#define QCH_CON_APM_CMU_APM_QCH				0x302c
+#define QCH_CON_APM_USI0_UART_QCH			0x3030
+#define QCH_CON_APM_USI0_USI_QCH			0x3034
+#define QCH_CON_APM_USI1_UART_QCH			0x3038
+#define QCH_CON_D_TZPC_APM_QCH				0x303c
+#define QCH_CON_GPC_APM_QCH				0x3040
+#define QCH_CON_GREBEINTEGRATION_QCH_DBG		0x3044
+#define QCH_CON_GREBEINTEGRATION_QCH_GREBE		0x3048
+#define QCH_CON_INTMEM_QCH				0x304c
+#define QCH_CON_LHM_AXI_G_SWD_QCH			0x3050
+#define QCH_CON_LHM_AXI_P_AOCAPM_QCH			0x3054
+#define QCH_CON_LHM_AXI_P_APM_QCH			0x3058
+#define QCH_CON_LHS_AXI_D_APM_QCH			0x305c
+#define QCH_CON_LHS_AXI_G_DBGCORE_QCH			0x3060
+#define QCH_CON_LHS_AXI_G_SCAN2DRAM_QCH			0x3064
+#define QCH_CON_MAILBOX_APM_AOC_QCH			0x3068
+#define QCH_CON_MAILBOX_APM_AP_QCH			0x306c
+#define QCH_CON_MAILBOX_APM_GSA_QCH			0x3070
+#define QCH_CON_MAILBOX_APM_SWD_QCH			0x3078
+#define QCH_CON_MAILBOX_APM_TPU_QCH			0x307c
+#define QCH_CON_MAILBOX_AP_AOC_QCH			0x3080
+#define QCH_CON_MAILBOX_AP_DBGCORE_QCH			0x3084
+#define QCH_CON_PMU_INTR_GEN_QCH			0x3088
+#define QCH_CON_ROM_CRC32_HOST_QCH			0x308c
+#define QCH_CON_RSTNSYNC_CLK_APM_BUS_QCH_GREBE		0x3090
+#define QCH_CON_RSTNSYNC_CLK_APM_BUS_QCH_GREBE_DBG	0x3094
+#define QCH_CON_SPEEDY_APM_QCH				0x3098
+#define QCH_CON_SPEEDY_SUB_APM_QCH			0x309c
+#define QCH_CON_SSMT_D_APM_QCH				0x30a0
+#define QCH_CON_SSMT_G_DBGCORE_QCH			0x30a4
+#define QCH_CON_SS_DBGCORE_QCH_DBG			0x30a8
+#define QCH_CON_SS_DBGCORE_QCH_GREBE			0x30ac
+#define QCH_CON_SYSMMU_D_APM_QCH			0x30b0
+#define QCH_CON_SYSREG_APM_QCH				0x30b8
+#define QCH_CON_UASC_APM_QCH				0x30bc
+#define QCH_CON_UASC_DBGCORE_QCH			0x30c0
+#define QCH_CON_UASC_G_SWD_QCH				0x30c4
+#define QCH_CON_UASC_P_AOCAPM_QCH			0x30c8
+#define QCH_CON_UASC_P_APM_QCH				0x30cc
+#define QCH_CON_WDT_APM_QCH				0x30d0
+#define QUEUE_CTRL_REG_BLK_APM_CMU_APM			0x3c00
+
+static const unsigned long apm_clk_regs[] __initconst = {
+	APM_CMU_APM_CONTROLLER_OPTION,
+	CLKOUT_CON_BLK_APM_CMU_APM_CLKOUT0,
+	CLK_CON_MUX_MUX_CLKCMU_APM_FUNC,
+	CLK_CON_MUX_MUX_CLKCMU_APM_FUNCSRC,
+	CLK_CON_DIV_DIV_CLK_APM_BOOST,
+	CLK_CON_DIV_DIV_CLK_APM_USI0_UART,
+	CLK_CON_DIV_DIV_CLK_APM_USI0_USI,
+	CLK_CON_DIV_DIV_CLK_APM_USI1_UART,
+	CLK_CON_GAT_CLK_BLK_APM_UID_APM_CMU_APM_IPCLKPORT_PCLK,
+	CLK_CON_GAT_CLK_BUS0_BOOST_OPTION1,
+	CLK_CON_GAT_CLK_CMU_BOOST_OPTION1,
+	CLK_CON_GAT_CLK_CORE_BOOST_OPTION1,
+	CLK_CON_GAT_GATE_CLKCMU_APM_FUNC,
+	CLK_CON_GAT_GOUT_BLK_APM_UID_APBIF_GPIO_ALIVE_IPCLKPORT_PCLK,
+	CLK_CON_GAT_GOUT_BLK_APM_UID_APBIF_GPIO_FAR_ALIVE_IPCLKPORT_PCLK,
+	CLK_CON_GAT_GOUT_BLK_APM_UID_APBIF_PMU_ALIVE_IPCLKPORT_PCLK,
+	CLK_CON_GAT_GOUT_BLK_APM_UID_APBIF_RTC_IPCLKPORT_PCLK,
+	CLK_CON_GAT_GOUT_BLK_APM_UID_APBIF_TRTC_IPCLKPORT_PCLK,
+	CLK_CON_GAT_GOUT_BLK_APM_UID_APM_USI0_UART_IPCLKPORT_IPCLK,
+	CLK_CON_GAT_GOUT_BLK_APM_UID_APM_USI0_UART_IPCLKPORT_PCLK,
+	CLK_CON_GAT_GOUT_BLK_APM_UID_APM_USI0_USI_IPCLKPORT_IPCLK,
+	CLK_CON_GAT_GOUT_BLK_APM_UID_APM_USI0_USI_IPCLKPORT_PCLK,
+	CLK_CON_GAT_GOUT_BLK_APM_UID_APM_USI1_UART_IPCLKPORT_IPCLK,
+	CLK_CON_GAT_GOUT_BLK_APM_UID_APM_USI1_UART_IPCLKPORT_PCLK,
+	CLK_CON_GAT_GOUT_BLK_APM_UID_D_TZPC_APM_IPCLKPORT_PCLK,
+	CLK_CON_GAT_GOUT_BLK_APM_UID_GPC_APM_IPCLKPORT_PCLK,
+	CLK_CON_GAT_GOUT_BLK_APM_UID_GREBEINTEGRATION_IPCLKPORT_HCLK,
+	CLK_CON_GAT_GOUT_BLK_APM_UID_INTMEM_IPCLKPORT_ACLK,
+	CLK_CON_GAT_GOUT_BLK_APM_UID_INTMEM_IPCLKPORT_PCLK,
+	CLK_CON_GAT_GOUT_BLK_APM_UID_LHM_AXI_G_SWD_IPCLKPORT_I_CLK,
+	CLK_CON_GAT_GOUT_BLK_APM_UID_LHM_AXI_P_AOCAPM_IPCLKPORT_I_CLK,
+	CLK_CON_GAT_GOUT_BLK_APM_UID_LHM_AXI_P_APM_IPCLKPORT_I_CLK,
+	CLK_CON_GAT_GOUT_BLK_APM_UID_LHS_AXI_D_APM_IPCLKPORT_I_CLK,
+	CLK_CON_GAT_GOUT_BLK_APM_UID_LHS_AXI_G_DBGCORE_IPCLKPORT_I_CLK,
+	CLK_CON_GAT_GOUT_BLK_APM_UID_LHS_AXI_G_SCAN2DRAM_IPCLKPORT_I_CLK,
+	CLK_CON_GAT_GOUT_BLK_APM_UID_MAILBOX_APM_AOC_IPCLKPORT_PCLK,
+	CLK_CON_GAT_GOUT_BLK_APM_UID_MAILBOX_APM_AP_IPCLKPORT_PCLK,
+	CLK_CON_GAT_GOUT_BLK_APM_UID_MAILBOX_APM_GSA_IPCLKPORT_PCLK,
+	CLK_CON_GAT_GOUT_BLK_APM_UID_MAILBOX_APM_SWD_IPCLKPORT_PCLK,
+	CLK_CON_GAT_GOUT_BLK_APM_UID_MAILBOX_APM_TPU_IPCLKPORT_PCLK,
+	CLK_CON_GAT_GOUT_BLK_APM_UID_MAILBOX_AP_AOC_IPCLKPORT_PCLK,
+	CLK_CON_GAT_GOUT_BLK_APM_UID_MAILBOX_AP_DBGCORE_IPCLKPORT_PCLK,
+	CLK_CON_GAT_GOUT_BLK_APM_UID_PMU_INTR_GEN_IPCLKPORT_PCLK,
+	CLK_CON_GAT_GOUT_BLK_APM_UID_ROM_CRC32_HOST_IPCLKPORT_ACLK,
+	CLK_CON_GAT_GOUT_BLK_APM_UID_ROM_CRC32_HOST_IPCLKPORT_PCLK,
+	CLK_CON_GAT_GOUT_BLK_APM_UID_RSTNSYNC_CLK_APM_BUS_IPCLKPORT_CLK,
+	CLK_CON_GAT_GOUT_BLK_APM_UID_RSTNSYNC_CLK_APM_USI0_UART_IPCLKPORT_CLK,
+	CLK_CON_GAT_GOUT_BLK_APM_UID_RSTNSYNC_CLK_APM_USI0_USI_IPCLKPORT_CLK,
+	CLK_CON_GAT_GOUT_BLK_APM_UID_RSTNSYNC_CLK_APM_USI1_UART_IPCLKPORT_CLK,
+	CLK_CON_GAT_GOUT_BLK_APM_UID_SPEEDY_APM_IPCLKPORT_PCLK,
+	CLK_CON_GAT_GOUT_BLK_APM_UID_SPEEDY_SUB_APM_IPCLKPORT_PCLK,
+	CLK_CON_GAT_GOUT_BLK_APM_UID_SSMT_D_APM_IPCLKPORT_ACLK,
+	CLK_CON_GAT_GOUT_BLK_APM_UID_SSMT_D_APM_IPCLKPORT_PCLK,
+	CLK_CON_GAT_GOUT_BLK_APM_UID_SSMT_G_DBGCORE_IPCLKPORT_ACLK,
+	CLK_CON_GAT_GOUT_BLK_APM_UID_SSMT_G_DBGCORE_IPCLKPORT_PCLK,
+	CLK_CON_GAT_GOUT_BLK_APM_UID_SS_DBGCORE_IPCLKPORT_SS_DBGCORE_IPCLKPORT_HCLK,
+	CLK_CON_GAT_GOUT_BLK_APM_UID_SYSMMU_D_APM_IPCLKPORT_CLK_S2,
+	CLK_CON_GAT_GOUT_BLK_APM_UID_SYSREG_APM_IPCLKPORT_PCLK,
+	CLK_CON_GAT_GOUT_BLK_APM_UID_UASC_APM_IPCLKPORT_ACLK,
+	CLK_CON_GAT_GOUT_BLK_APM_UID_UASC_APM_IPCLKPORT_PCLK,
+	CLK_CON_GAT_GOUT_BLK_APM_UID_UASC_DBGCORE_IPCLKPORT_ACLK,
+	CLK_CON_GAT_GOUT_BLK_APM_UID_UASC_DBGCORE_IPCLKPORT_PCLK,
+	CLK_CON_GAT_GOUT_BLK_APM_UID_UASC_G_SWD_IPCLKPORT_ACLK,
+	CLK_CON_GAT_GOUT_BLK_APM_UID_UASC_G_SWD_IPCLKPORT_PCLK,
+	CLK_CON_GAT_GOUT_BLK_APM_UID_UASC_P_AOCAPM_IPCLKPORT_ACLK,
+	CLK_CON_GAT_GOUT_BLK_APM_UID_UASC_P_AOCAPM_IPCLKPORT_PCLK,
+	CLK_CON_GAT_GOUT_BLK_APM_UID_UASC_P_APM_IPCLKPORT_ACLK,
+	CLK_CON_GAT_GOUT_BLK_APM_UID_UASC_P_APM_IPCLKPORT_PCLK,
+	CLK_CON_GAT_GOUT_BLK_APM_UID_WDT_APM_IPCLKPORT_PCLK,
+	CLK_CON_GAT_GOUT_BLK_APM_UID_XIU_DP_APM_IPCLKPORT_ACLK,
+};
+
+PNAME(mout_apm_func_p)	= { "oscclk_apmgsa", "mout_apm_funcsrc", "pad_clk_apm" };
+PNAME(mout_apm_funcsrc_p) = { "pll_alv_div2_apm", "pll_alv_div4_apm", "pll_alv_div16_apm" };
+
+static const struct samsung_fixed_rate_clock apm_fixed_clks[] __initconst = {
+	FRATE(CLK_APM_PLL_DIV2_APM, "clk_apm_pll_div2_apm", NULL, 0, 393216000),
+	FRATE(CLK_APM_PLL_DIV4_APM, "clk_apm_pll_div4_apm", NULL, 0, 196608000),
+	FRATE(CLK_APM_PLL_DIV16_APM, "clk_apm_pll_div16_apm", NULL, 0, 49152000),
+};
+
+static const struct samsung_mux_clock apm_mux_clks[] __initconst = {
+	MUX(CLK_MOUT_APM_FUNC, "mout_apm_func", mout_apm_func_p,
+	    CLK_CON_MUX_MUX_CLKCMU_APM_FUNC, 4, 1),
+	MUX(CLK_MOUT_APM_FUNCSRC, "mout_apm_funcsrc", mout_apm_funcsrc_p,
+	    CLK_CON_MUX_MUX_CLKCMU_APM_FUNCSRC, 3, 1),
+};
+
+static const struct samsung_div_clock apm_div_clks[] __initconst = {
+	DIV(CLK_DOUT_APM_BOOST, "dout_apm_boost", "gout_apm_func",
+	    CLK_CON_DIV_DIV_CLK_APM_BOOST, 0, 1),
+	DIV(CLK_DOUT_APM_USI0_UART, "dout_apm_usi0_uart", "gout_apm_func",
+	    CLK_CON_DIV_DIV_CLK_APM_USI0_UART, 0, 7),
+	DIV(CLK_DOUT_APM_USI0_USI, "dout_apm_usi0_usi", "gout_apm_func",
+	    CLK_CON_DIV_DIV_CLK_APM_USI0_USI, 0, 7),
+	DIV(CLK_DOUT_APM_USI1_UART, "dout_apm_usi1_uart", "gout_apm_func",
+	    CLK_CON_DIV_DIV_CLK_APM_USI1_UART, 0, 7),
+};
+
+static const struct samsung_gate_clock apm_gate_clks[] __initconst = {
+	GATE(CLK_GOUT_APM_FUNC, "gout_apm_func", "mout_apm_func",
+	     CLK_CON_GAT_GATE_CLKCMU_APM_FUNC, 21, 0, 0),
+
+	GATE(CLK_GOUT_APM_UID_APBIF_GPIO_ALIVE_IPCLKPORT_PCLK,
+	     "gout_apm_gpio_alive_ipclkport_pclk", "gout_apm_func",
+	     CLK_CON_GAT_GOUT_BLK_APM_UID_APBIF_GPIO_ALIVE_IPCLKPORT_PCLK,
+	     21, 0, 0),
+
+	GATE(CLK_GOUT_APM_UID_APBIF_GPIO_FAR_ALIVE_IPCLKPORT_PCLK,
+	     "gout_apm_gpio_far_alive_ipclkport_pclk", "gout_apm_func",
+	     CLK_CON_GAT_GOUT_BLK_APM_UID_APBIF_GPIO_FAR_ALIVE_IPCLKPORT_PCLK,
+	     21, 0, 0),
+
+	GATE(CLK_GOUT_APM_UID_APBIF_PMU_ALIVE_IPCLKPORT_PCLK,
+	     "gout_apm_pmu_alive_ipclkport_pclk", "gout_apm_func",
+	     CLK_CON_GAT_GOUT_BLK_APM_UID_APBIF_PMU_ALIVE_IPCLKPORT_PCLK,
+	     21, CLK_IS_CRITICAL, 0),
+
+	GATE(CLK_GOUT_APM_UID_SYSREG_APM_IPCLKPORT_PCLK,
+	     "gout_apm_sysreg_apm_ipclkport_pclk", "gout_apm_func",
+	     CLK_CON_GAT_GOUT_BLK_APM_UID_SYSREG_APM_IPCLKPORT_PCLK,
+	     21, 0, 0),
+};
+
+static const struct samsung_cmu_info apm_cmu_info __initconst = {
+	.mux_clks		= apm_mux_clks,
+	.nr_mux_clks		= ARRAY_SIZE(apm_mux_clks),
+	.div_clks		= apm_div_clks,
+	.nr_div_clks		= ARRAY_SIZE(apm_div_clks),
+	.gate_clks		= apm_gate_clks,
+	.nr_gate_clks		= ARRAY_SIZE(apm_gate_clks),
+	.fixed_clks		= apm_fixed_clks,
+	.nr_fixed_clks		= ARRAY_SIZE(apm_fixed_clks),
+	.nr_clk_ids		= APM_NR_CLK,
+	.clk_regs		= apm_clk_regs,
+	.nr_clk_regs		= ARRAY_SIZE(apm_clk_regs),
+};
+
+/* ---- platform_driver ----------------------------------------------------- */
+
+static int __init gs101_cmu_probe(struct platform_device *pdev)
+{
+	const struct samsung_cmu_info *info;
+	struct device *dev = &pdev->dev;
+
+	info = of_device_get_match_data(dev);
+	exynos_arm64_register_cmu(dev, dev->of_node, info);
+
+	return 0;
+}
+
+static const struct of_device_id gs101_cmu_of_match[] = {
+	{
+		.compatible = "google,gs101-cmu-apm",
+		.data = &apm_cmu_info,
+	}, {
+	},
+};
+
+static struct platform_driver gs101_cmu_driver __refdata = {
+	.driver	= {
+		.name = "gs101-cmu",
+		.of_match_table = gs101_cmu_of_match,
+		.suppress_bind_attrs = true,
+	},
+	.probe = gs101_cmu_probe,
+};
+
+static int __init gs101_cmu_init(void)
+{
+	return platform_driver_register(&gs101_cmu_driver);
+}
+core_initcall(gs101_cmu_init);
-- 
2.42.0.609.gbb76f46606-goog


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH v2 12/20] clk: samsung: clk-gs101: Add support for CMU_MISC clock unit

[Peter Griffin]

CMU Misc clocks IPs such as Watchdog. Add support for the
muxes, dividers and gates in this CMU.

Signed-off-by: Peter Griffin <peter.griffin@linaro.org>
---
 drivers/clk/samsung/clk-gs101.c | 312 ++++++++++++++++++++++++++++++++
 1 file changed, 312 insertions(+)

diff --git a/drivers/clk/samsung/clk-gs101.c b/drivers/clk/samsung/clk-gs101.c
index 525f95e60665..bf2bd8cd39d0 100644
--- a/drivers/clk/samsung/clk-gs101.c
+++ b/drivers/clk/samsung/clk-gs101.c
@@ -20,6 +20,7 @@
 /* NOTE: Must be equal to the last clock ID increased by one */
 #define TOP_NR_CLK                     (CLK_GOUT_CMU_BOOST + 1)
 #define APM_NR_CLK                     (CLK_APM_PLL_DIV16_APM + 1)
+#define MISC_NR_CLK                    (CLK_GOUT_MISC_WDT_CLUSTER1 + 1)
 
 /* ---- CMU_TOP ------------------------------------------------------------- */
 
@@ -1815,6 +1816,314 @@ static const struct samsung_cmu_info apm_cmu_info __initconst = {
 	.nr_clk_regs		= ARRAY_SIZE(apm_clk_regs),
 };
 
+/* ---- CMU_MISC ------------------------------------------------------------- */
+/* Register Offset definitions for CMU_MISC (0x10010000) */
+#define PLL_CON0_MUX_CLKCMU_MISC_BUS_USER	0x0600
+#define PLL_CON1_MUX_CLKCMU_MISC_BUS_USER	0x0604
+#define PLL_CON0_MUX_CLKCMU_MISC_SSS_USER	0x0610
+#define PLL_CON1_MUX_CLKCMU_MISC_SSS_USER	0x0614
+#define MISC_CMU_MISC_CONTROLLER_OPTION		0x0800
+#define CLKOUT_CON_BLK_MISC_CMU_MISC_CLKOUT0	0x0810
+#define CLK_CON_MUX_MUX_CLK_MISC_GIC		0x1000
+#define CLK_CON_DIV_DIV_CLK_MISC_BUSP		0x1800
+#define CLK_CON_DIV_DIV_CLK_MISC_GIC		0x1804
+#define CLK_CON_GAT_CLK_BLK_MISC_UID_MISC_CMU_MISC_IPCLKPORT_PCLK		0x2000
+#define CLK_CON_GAT_CLK_BLK_MISC_UID_OTP_CON_BIRA_IPCLKPORT_I_OSCCLK		0x2004
+#define CLK_CON_GAT_CLK_BLK_MISC_UID_OTP_CON_BISR_IPCLKPORT_I_OSCCLK		0x2008
+#define CLK_CON_GAT_CLK_BLK_MISC_UID_OTP_CON_TOP_IPCLKPORT_I_OSCCLK		0x200c
+#define CLK_CON_GAT_CLK_BLK_MISC_UID_RSTNSYNC_CLK_MISC_OSCCLK_IPCLKPORT_CLK	0x2010
+#define CLK_CON_GAT_GOUT_BLK_MISC_UID_ADM_AHB_SSS_IPCLKPORT_HCLKM		0x2014
+#define CLK_CON_GAT_GOUT_BLK_MISC_UID_AD_APB_DIT_IPCLKPORT_PCLKM		0x2018
+#define CLK_CON_GAT_GOUT_BLK_MISC_UID_AD_APB_PUF_IPCLKPORT_PCLKM		0x201c
+#define CLK_CON_GAT_GOUT_BLK_MISC_UID_DIT_IPCLKPORT_ICLKL2A			0x2020
+#define CLK_CON_GAT_GOUT_BLK_MISC_UID_D_TZPC_MISC_IPCLKPORT_PCLK		0x2024
+#define CLK_CON_GAT_GOUT_BLK_MISC_UID_GIC_IPCLKPORT_GICCLK			0x2028
+#define CLK_CON_GAT_GOUT_BLK_MISC_UID_GPC_MISC_IPCLKPORT_PCLK			0x202c
+#define CLK_CON_GAT_GOUT_BLK_MISC_UID_LHM_AST_ICC_CPUGIC_IPCLKPORT_I_CLK	0x2030
+#define CLK_CON_GAT_GOUT_BLK_MISC_UID_LHM_AXI_D_SSS_IPCLKPORT_I_CLK		0x2034
+#define CLK_CON_GAT_GOUT_BLK_MISC_UID_LHM_AXI_P_GIC_IPCLKPORT_I_CLK		0x2038
+#define CLK_CON_GAT_GOUT_BLK_MISC_UID_LHM_AXI_P_MISC_IPCLKPORT_I_CLK		0x203c
+#define CLK_CON_GAT_GOUT_BLK_MISC_UID_LHS_ACEL_D_MISC_IPCLKPORT_I_CLK		0x2040
+#define CLK_CON_GAT_GOUT_BLK_MISC_UID_LHS_AST_IRI_GICCPU_IPCLKPORT_I_CLK	0x2044
+#define CLK_CON_GAT_GOUT_BLK_MISC_UID_LHS_AXI_D_SSS_IPCLKPORT_I_CLK		0x2048
+#define CLK_CON_GAT_GOUT_BLK_MISC_UID_MCT_IPCLKPORT_PCLK			0x204c
+#define CLK_CON_GAT_GOUT_BLK_MISC_UID_OTP_CON_BIRA_IPCLKPORT_PCLK		0x2050
+#define CLK_CON_GAT_GOUT_BLK_MISC_UID_OTP_CON_BISR_IPCLKPORT_PCLK		0x2054
+#define CLK_CON_GAT_GOUT_BLK_MISC_UID_OTP_CON_TOP_IPCLKPORT_PCLK		0x2058
+#define CLK_CON_GAT_GOUT_BLK_MISC_UID_PDMA_IPCLKPORT_ACLK			0x205c
+#define CLK_CON_GAT_GOUT_BLK_MISC_UID_PPMU_DMA_IPCLKPORT_ACLK			0x2060
+#define CLK_CON_GAT_GOUT_BLK_MISC_UID_PPMU_MISC_IPCLKPORT_ACLK			0x2064
+#define CLK_CON_GAT_GOUT_BLK_MISC_UID_PPMU_MISC_IPCLKPORT_PCLK			0x2068
+#define CLK_CON_GAT_GOUT_BLK_MISC_UID_PUF_IPCLKPORT_I_CLK			0x206c
+#define CLK_CON_GAT_GOUT_BLK_MISC_UID_QE_DIT_IPCLKPORT_ACLK			0x2070
+#define CLK_CON_GAT_GOUT_BLK_MISC_UID_QE_DIT_IPCLKPORT_PCLK			0x2074
+#define CLK_CON_GAT_GOUT_BLK_MISC_UID_QE_PDMA_IPCLKPORT_ACLK			0x2078
+#define CLK_CON_GAT_GOUT_BLK_MISC_UID_QE_PDMA_IPCLKPORT_PCLK			0x207c
+#define CLK_CON_GAT_GOUT_BLK_MISC_UID_QE_PPMU_DMA_IPCLKPORT_ACLK		0x2080
+#define CLK_CON_GAT_GOUT_BLK_MISC_UID_QE_PPMU_DMA_IPCLKPORT_PCLK		0x2084
+#define CLK_CON_GAT_GOUT_BLK_MISC_UID_QE_RTIC_IPCLKPORT_ACLK			0x2088
+#define CLK_CON_GAT_GOUT_BLK_MISC_UID_QE_RTIC_IPCLKPORT_PCLK			0x208c
+#define CLK_CON_GAT_GOUT_BLK_MISC_UID_QE_SPDMA_IPCLKPORT_ACLK			0x2090
+#define CLK_CON_GAT_GOUT_BLK_MISC_UID_QE_SPDMA_IPCLKPORT_PCLK			0x2094
+#define CLK_CON_GAT_GOUT_BLK_MISC_UID_QE_SSS_IPCLKPORT_ACLK			0x2098
+#define CLK_CON_GAT_GOUT_BLK_MISC_UID_QE_SSS_IPCLKPORT_PCLK			0x209c
+#define CLK_CON_GAT_GOUT_BLK_MISC_UID_RSTNSYNC_CLK_MISC_BUSD_IPCLKPORT_CLK	0x20a0
+#define CLK_CON_GAT_GOUT_BLK_MISC_UID_RSTNSYNC_CLK_MISC_BUSP_IPCLKPORT_CLK	0x20a4
+#define CLK_CON_GAT_GOUT_BLK_MISC_UID_RSTNSYNC_CLK_MISC_GIC_IPCLKPORT_CLK	0x20a8
+#define CLK_CON_GAT_GOUT_BLK_MISC_UID_RSTNSYNC_CLK_MISC_SSS_IPCLKPORT_CLK	0x20ac
+#define CLK_CON_GAT_GOUT_BLK_MISC_UID_RTIC_IPCLKPORT_I_ACLK			0x20b0
+#define CLK_CON_GAT_GOUT_BLK_MISC_UID_RTIC_IPCLKPORT_I_PCLK			0x20b4
+#define CLK_CON_GAT_GOUT_BLK_MISC_UID_SPDMA_IPCLKPORT_ACLK			0x20b8
+#define CLK_CON_GAT_GOUT_BLK_MISC_UID_SSMT_DIT_IPCLKPORT_ACLK			0x20bc
+#define CLK_CON_GAT_GOUT_BLK_MISC_UID_SSMT_DIT_IPCLKPORT_PCLK			0x20c0
+#define CLK_CON_GAT_GOUT_BLK_MISC_UID_SSMT_PDMA_IPCLKPORT_ACLK			0x20c4
+#define CLK_CON_GAT_GOUT_BLK_MISC_UID_SSMT_PDMA_IPCLKPORT_PCLK			0x20c8
+#define CLK_CON_GAT_GOUT_BLK_MISC_UID_SSMT_PPMU_DMA_IPCLKPORT_ACLK		0x20cc
+#define CLK_CON_GAT_GOUT_BLK_MISC_UID_SSMT_PPMU_DMA_IPCLKPORT_PCLK		0x20d0
+#define CLK_CON_GAT_GOUT_BLK_MISC_UID_SSMT_RTIC_IPCLKPORT_ACLK			0x20d4
+#define CLK_CON_GAT_GOUT_BLK_MISC_UID_SSMT_RTIC_IPCLKPORT_PCLK			0x20d8
+#define CLK_CON_GAT_GOUT_BLK_MISC_UID_SSMT_SPDMA_IPCLKPORT_ACLK			0x20dc
+#define CLK_CON_GAT_GOUT_BLK_MISC_UID_SSMT_SPDMA_IPCLKPORT_PCLK			0x20e0
+#define CLK_CON_GAT_GOUT_BLK_MISC_UID_SSMT_SSS_IPCLKPORT_ACLK			0x20e4
+#define CLK_CON_GAT_GOUT_BLK_MISC_UID_SSMT_SSS_IPCLKPORT_PCLK			0x20e8
+#define CLK_CON_GAT_GOUT_BLK_MISC_UID_SSS_IPCLKPORT_I_ACLK			0x20ec
+#define CLK_CON_GAT_GOUT_BLK_MISC_UID_SSS_IPCLKPORT_I_PCLK			0x20f0
+#define CLK_CON_GAT_GOUT_BLK_MISC_UID_SYSMMU_MISC_IPCLKPORT_CLK_S2		0x20f4
+#define CLK_CON_GAT_GOUT_BLK_MISC_UID_SYSMMU_SSS_IPCLKPORT_CLK_S1		0x20f8
+#define CLK_CON_GAT_GOUT_BLK_MISC_UID_SYSREG_MISC_IPCLKPORT_PCLK		0x20fc
+#define CLK_CON_GAT_GOUT_BLK_MISC_UID_TMU_SUB_IPCLKPORT_PCLK			0x2100
+#define CLK_CON_GAT_GOUT_BLK_MISC_UID_TMU_TOP_IPCLKPORT_PCLK			0x2104
+#define CLK_CON_GAT_GOUT_BLK_MISC_UID_WDT_CLUSTER0_IPCLKPORT_PCLK		0x2108
+#define CLK_CON_GAT_GOUT_BLK_MISC_UID_WDT_CLUSTER1_IPCLKPORT_PCLK		0x210c
+#define CLK_CON_GAT_GOUT_BLK_MISC_UID_XIU_D_MISC_IPCLKPORT_ACLK			0x2110
+#define DMYQCH_CON_PPMU_DMA_QCH			0x3000
+#define DMYQCH_CON_PUF_QCH			0x3004
+#define PCH_CON_LHM_AXI_D_SSS_PCH		0x300c
+#define PCH_CON_LHM_AXI_P_GIC_PCH		0x3010
+#define PCH_CON_LHM_AXI_P_MISC_PCH		0x3014
+#define PCH_CON_LHS_ACEL_D_MISC_PCH		0x3018
+#define PCH_CON_LHS_AST_IRI_GICCPU_PCH		0x301c
+#define PCH_CON_LHS_AXI_D_SSS_PCH		0x3020
+#define QCH_CON_ADM_AHB_SSS_QCH			0x3024
+#define QCH_CON_DIT_QCH				0x3028
+#define QCH_CON_GIC_QCH				0x3030
+#define QCH_CON_LHM_AST_ICC_CPUGIC_QCH		0x3038
+#define QCH_CON_LHM_AXI_D_SSS_QCH		0x303c
+#define QCH_CON_LHM_AXI_P_GIC_QCH		0x3040
+#define QCH_CON_LHM_AXI_P_MISC_QCH		0x3044
+#define QCH_CON_LHS_ACEL_D_MISC_QCH		0x3048
+#define QCH_CON_LHS_AST_IRI_GICCPU_QCH		0x304c
+#define QCH_CON_LHS_AXI_D_SSS_QCH		0x3050
+#define QCH_CON_MCT_QCH				0x3054
+#define QCH_CON_MISC_CMU_MISC_QCH		0x3058
+#define QCH_CON_OTP_CON_BIRA_QCH		0x305c
+#define QCH_CON_OTP_CON_BISR_QCH		0x3060
+#define QCH_CON_OTP_CON_TOP_QCH			0x3064
+#define QCH_CON_PDMA_QCH			0x3068
+#define QCH_CON_PPMU_MISC_QCH			0x306c
+#define QCH_CON_QE_DIT_QCH			0x3070
+#define QCH_CON_QE_PDMA_QCH			0x3074
+#define QCH_CON_QE_PPMU_DMA_QCH			0x3078
+#define QCH_CON_QE_RTIC_QCH			0x307c
+#define QCH_CON_QE_SPDMA_QCH			0x3080
+#define QCH_CON_QE_SSS_QCH			0x3084
+#define QCH_CON_RTIC_QCH			0x3088
+#define QCH_CON_SPDMA_QCH			0x308c
+#define QCH_CON_SSMT_DIT_QCH			0x3090
+#define QCH_CON_SSMT_PDMA_QCH			0x3094
+#define QCH_CON_SSMT_PPMU_DMA_QCH		0x3098
+#define QCH_CON_SSMT_RTIC_QCH			0x309c
+#define QCH_CON_SSMT_SPDMA_QCH			0x30a0
+#define QCH_CON_SSMT_SSS_QCH			0x30a4
+#define QCH_CON_SSS_QCH				0x30a8
+#define QCH_CON_SYSMMU_MISC_QCH			0x30ac
+#define QCH_CON_SYSMMU_SSS_QCH			0x30b0
+#define QCH_CON_SYSREG_MISC_QCH			0x30b4
+#define QCH_CON_TMU_SUB_QCH			0x30b8
+#define QCH_CON_TMU_TOP_QCH			0x30bc
+#define QCH_CON_WDT_CLUSTER0_QCH		0x30c0
+#define QCH_CON_WDT_CLUSTER1_QCH		0x30c4
+#define QUEUE_CTRL_REG_BLK_MISC_CMU_MISC	0x3c00
+
+static const unsigned long misc_clk_regs[] __initconst = {
+	PLL_CON0_MUX_CLKCMU_MISC_BUS_USER,
+	PLL_CON1_MUX_CLKCMU_MISC_BUS_USER,
+	PLL_CON0_MUX_CLKCMU_MISC_SSS_USER,
+	PLL_CON1_MUX_CLKCMU_MISC_SSS_USER,
+	MISC_CMU_MISC_CONTROLLER_OPTION,
+	CLKOUT_CON_BLK_MISC_CMU_MISC_CLKOUT0,
+	CLK_CON_MUX_MUX_CLK_MISC_GIC,
+	CLK_CON_DIV_DIV_CLK_MISC_BUSP,
+	CLK_CON_DIV_DIV_CLK_MISC_GIC,
+	CLK_CON_GAT_CLK_BLK_MISC_UID_MISC_CMU_MISC_IPCLKPORT_PCLK,
+	CLK_CON_GAT_CLK_BLK_MISC_UID_OTP_CON_BIRA_IPCLKPORT_I_OSCCLK,
+	CLK_CON_GAT_CLK_BLK_MISC_UID_OTP_CON_BISR_IPCLKPORT_I_OSCCLK,
+	CLK_CON_GAT_CLK_BLK_MISC_UID_OTP_CON_TOP_IPCLKPORT_I_OSCCLK,
+	CLK_CON_GAT_CLK_BLK_MISC_UID_RSTNSYNC_CLK_MISC_OSCCLK_IPCLKPORT_CLK,
+	CLK_CON_GAT_GOUT_BLK_MISC_UID_ADM_AHB_SSS_IPCLKPORT_HCLKM,
+	CLK_CON_GAT_GOUT_BLK_MISC_UID_AD_APB_DIT_IPCLKPORT_PCLKM,
+	CLK_CON_GAT_GOUT_BLK_MISC_UID_AD_APB_PUF_IPCLKPORT_PCLKM,
+	CLK_CON_GAT_GOUT_BLK_MISC_UID_DIT_IPCLKPORT_ICLKL2A,
+	CLK_CON_GAT_GOUT_BLK_MISC_UID_D_TZPC_MISC_IPCLKPORT_PCLK,
+	CLK_CON_GAT_GOUT_BLK_MISC_UID_GIC_IPCLKPORT_GICCLK,
+	CLK_CON_GAT_GOUT_BLK_MISC_UID_GPC_MISC_IPCLKPORT_PCLK,
+	CLK_CON_GAT_GOUT_BLK_MISC_UID_LHM_AST_ICC_CPUGIC_IPCLKPORT_I_CLK,
+	CLK_CON_GAT_GOUT_BLK_MISC_UID_LHM_AXI_D_SSS_IPCLKPORT_I_CLK,
+	CLK_CON_GAT_GOUT_BLK_MISC_UID_LHM_AXI_P_GIC_IPCLKPORT_I_CLK,
+	CLK_CON_GAT_GOUT_BLK_MISC_UID_LHM_AXI_P_MISC_IPCLKPORT_I_CLK,
+	CLK_CON_GAT_GOUT_BLK_MISC_UID_LHS_ACEL_D_MISC_IPCLKPORT_I_CLK,
+	CLK_CON_GAT_GOUT_BLK_MISC_UID_LHS_AST_IRI_GICCPU_IPCLKPORT_I_CLK,
+	CLK_CON_GAT_GOUT_BLK_MISC_UID_LHS_AXI_D_SSS_IPCLKPORT_I_CLK,
+	CLK_CON_GAT_GOUT_BLK_MISC_UID_MCT_IPCLKPORT_PCLK,
+	CLK_CON_GAT_GOUT_BLK_MISC_UID_OTP_CON_BIRA_IPCLKPORT_PCLK,
+	CLK_CON_GAT_GOUT_BLK_MISC_UID_OTP_CON_BISR_IPCLKPORT_PCLK,
+	CLK_CON_GAT_GOUT_BLK_MISC_UID_OTP_CON_TOP_IPCLKPORT_PCLK,
+	CLK_CON_GAT_GOUT_BLK_MISC_UID_PDMA_IPCLKPORT_ACLK,
+	CLK_CON_GAT_GOUT_BLK_MISC_UID_PPMU_DMA_IPCLKPORT_ACLK,
+	CLK_CON_GAT_GOUT_BLK_MISC_UID_PPMU_MISC_IPCLKPORT_ACLK,
+	CLK_CON_GAT_GOUT_BLK_MISC_UID_PPMU_MISC_IPCLKPORT_PCLK,
+	CLK_CON_GAT_GOUT_BLK_MISC_UID_PUF_IPCLKPORT_I_CLK,
+	CLK_CON_GAT_GOUT_BLK_MISC_UID_QE_DIT_IPCLKPORT_ACLK,
+	CLK_CON_GAT_GOUT_BLK_MISC_UID_QE_DIT_IPCLKPORT_PCLK,
+	CLK_CON_GAT_GOUT_BLK_MISC_UID_QE_PDMA_IPCLKPORT_ACLK,
+	CLK_CON_GAT_GOUT_BLK_MISC_UID_QE_PDMA_IPCLKPORT_PCLK,
+	CLK_CON_GAT_GOUT_BLK_MISC_UID_QE_PPMU_DMA_IPCLKPORT_ACLK,
+	CLK_CON_GAT_GOUT_BLK_MISC_UID_QE_PPMU_DMA_IPCLKPORT_PCLK,
+	CLK_CON_GAT_GOUT_BLK_MISC_UID_QE_RTIC_IPCLKPORT_ACLK,
+	CLK_CON_GAT_GOUT_BLK_MISC_UID_QE_RTIC_IPCLKPORT_PCLK,
+	CLK_CON_GAT_GOUT_BLK_MISC_UID_QE_SPDMA_IPCLKPORT_ACLK,
+	CLK_CON_GAT_GOUT_BLK_MISC_UID_QE_SPDMA_IPCLKPORT_PCLK,
+	CLK_CON_GAT_GOUT_BLK_MISC_UID_QE_SSS_IPCLKPORT_ACLK,
+	CLK_CON_GAT_GOUT_BLK_MISC_UID_QE_SSS_IPCLKPORT_PCLK,
+	CLK_CON_GAT_GOUT_BLK_MISC_UID_RSTNSYNC_CLK_MISC_BUSD_IPCLKPORT_CLK,
+	CLK_CON_GAT_GOUT_BLK_MISC_UID_RSTNSYNC_CLK_MISC_BUSP_IPCLKPORT_CLK,
+	CLK_CON_GAT_GOUT_BLK_MISC_UID_RSTNSYNC_CLK_MISC_GIC_IPCLKPORT_CLK,
+	CLK_CON_GAT_GOUT_BLK_MISC_UID_RSTNSYNC_CLK_MISC_SSS_IPCLKPORT_CLK,
+	CLK_CON_GAT_GOUT_BLK_MISC_UID_RTIC_IPCLKPORT_I_ACLK,
+	CLK_CON_GAT_GOUT_BLK_MISC_UID_RTIC_IPCLKPORT_I_PCLK,
+	CLK_CON_GAT_GOUT_BLK_MISC_UID_SPDMA_IPCLKPORT_ACLK,
+	CLK_CON_GAT_GOUT_BLK_MISC_UID_SSMT_DIT_IPCLKPORT_ACLK,
+	CLK_CON_GAT_GOUT_BLK_MISC_UID_SSMT_DIT_IPCLKPORT_PCLK,
+	CLK_CON_GAT_GOUT_BLK_MISC_UID_SSMT_PDMA_IPCLKPORT_ACLK,
+	CLK_CON_GAT_GOUT_BLK_MISC_UID_SSMT_PDMA_IPCLKPORT_PCLK,
+	CLK_CON_GAT_GOUT_BLK_MISC_UID_SSMT_PPMU_DMA_IPCLKPORT_ACLK,
+	CLK_CON_GAT_GOUT_BLK_MISC_UID_SSMT_PPMU_DMA_IPCLKPORT_PCLK,
+	CLK_CON_GAT_GOUT_BLK_MISC_UID_SSMT_RTIC_IPCLKPORT_ACLK,
+	CLK_CON_GAT_GOUT_BLK_MISC_UID_SSMT_RTIC_IPCLKPORT_PCLK,
+	CLK_CON_GAT_GOUT_BLK_MISC_UID_SSMT_SPDMA_IPCLKPORT_ACLK,
+	CLK_CON_GAT_GOUT_BLK_MISC_UID_SSMT_SPDMA_IPCLKPORT_PCLK,
+	CLK_CON_GAT_GOUT_BLK_MISC_UID_SSMT_SSS_IPCLKPORT_ACLK,
+	CLK_CON_GAT_GOUT_BLK_MISC_UID_SSMT_SSS_IPCLKPORT_PCLK,
+	CLK_CON_GAT_GOUT_BLK_MISC_UID_SSS_IPCLKPORT_I_ACLK,
+	CLK_CON_GAT_GOUT_BLK_MISC_UID_SSS_IPCLKPORT_I_PCLK,
+	CLK_CON_GAT_GOUT_BLK_MISC_UID_SYSMMU_MISC_IPCLKPORT_CLK_S2,
+	CLK_CON_GAT_GOUT_BLK_MISC_UID_SYSMMU_SSS_IPCLKPORT_CLK_S1,
+	CLK_CON_GAT_GOUT_BLK_MISC_UID_SYSREG_MISC_IPCLKPORT_PCLK,
+	CLK_CON_GAT_GOUT_BLK_MISC_UID_TMU_SUB_IPCLKPORT_PCLK,
+	CLK_CON_GAT_GOUT_BLK_MISC_UID_TMU_TOP_IPCLKPORT_PCLK,
+	CLK_CON_GAT_GOUT_BLK_MISC_UID_WDT_CLUSTER0_IPCLKPORT_PCLK,
+	CLK_CON_GAT_GOUT_BLK_MISC_UID_WDT_CLUSTER1_IPCLKPORT_PCLK,
+	CLK_CON_GAT_GOUT_BLK_MISC_UID_XIU_D_MISC_IPCLKPORT_ACLK,
+	DMYQCH_CON_PPMU_DMA_QCH,
+	DMYQCH_CON_PUF_QCH,
+	PCH_CON_LHM_AXI_D_SSS_PCH,
+	PCH_CON_LHM_AXI_P_GIC_PCH,
+	PCH_CON_LHM_AXI_P_MISC_PCH,
+	PCH_CON_LHS_ACEL_D_MISC_PCH,
+	PCH_CON_LHS_AST_IRI_GICCPU_PCH,
+	PCH_CON_LHS_AXI_D_SSS_PCH,
+	QCH_CON_ADM_AHB_SSS_QCH,
+	QCH_CON_DIT_QCH,
+	QCH_CON_GIC_QCH,
+	QCH_CON_LHM_AST_ICC_CPUGIC_QCH,
+	QCH_CON_LHM_AXI_D_SSS_QCH,
+	QCH_CON_LHM_AXI_P_GIC_QCH,
+	QCH_CON_LHM_AXI_P_MISC_QCH,
+	QCH_CON_LHS_ACEL_D_MISC_QCH,
+	QCH_CON_LHS_AST_IRI_GICCPU_QCH,
+	QCH_CON_LHS_AXI_D_SSS_QCH,
+	QCH_CON_MCT_QCH,
+	QCH_CON_MISC_CMU_MISC_QCH,
+	QCH_CON_OTP_CON_BIRA_QCH,
+	QCH_CON_OTP_CON_BISR_QCH,
+	QCH_CON_OTP_CON_TOP_QCH,
+	QCH_CON_PDMA_QCH,
+	QCH_CON_PPMU_MISC_QCH,
+	QCH_CON_QE_DIT_QCH,
+	QCH_CON_QE_PDMA_QCH,
+	QCH_CON_QE_PPMU_DMA_QCH,
+	QCH_CON_QE_RTIC_QCH,
+	QCH_CON_QE_SPDMA_QCH,
+	QCH_CON_QE_SSS_QCH,
+	QCH_CON_RTIC_QCH,
+	QCH_CON_SPDMA_QCH,
+	QCH_CON_SSMT_DIT_QCH,
+	QCH_CON_SSMT_PDMA_QCH,
+	QCH_CON_SSMT_PPMU_DMA_QCH,
+	QCH_CON_SSMT_RTIC_QCH,
+	QCH_CON_SSMT_SPDMA_QCH,
+	QCH_CON_SSMT_SSS_QCH,
+	QCH_CON_SSS_QCH,
+	QCH_CON_SYSMMU_MISC_QCH,
+	QCH_CON_SYSMMU_SSS_QCH,
+	QCH_CON_SYSREG_MISC_QCH,
+	QCH_CON_TMU_SUB_QCH,
+	QCH_CON_TMU_TOP_QCH,
+	QCH_CON_WDT_CLUSTER0_QCH,
+	QCH_CON_WDT_CLUSTER1_QCH,
+	QUEUE_CTRL_REG_BLK_MISC_CMU_MISC,
+};
+
+/* List of parent clocks for Muxes in CMU_MISC */
+PNAME(mout_misc_bus_user_p)		= { "oscclk", "dout_cmu_misc_bus" };
+PNAME(mout_misc_sss_user_p)		= { "oscclk", "dout_cmu_misc_sss" };
+
+static const struct samsung_mux_clock misc_mux_clks[] __initconst = {
+	MUX(CLK_MOUT_MISC_BUS_USER, "mout_misc_bus_user", mout_misc_bus_user_p,
+	    PLL_CON0_MUX_CLKCMU_MISC_BUS_USER, 4, 1),
+	MUX(CLK_MOUT_MISC_SSS_USER, "mout_misc_sss_user", mout_misc_sss_user_p,
+	    PLL_CON0_MUX_CLKCMU_MISC_SSS_USER, 4, 1),
+};
+
+static const struct samsung_div_clock misc_div_clks[] __initconst = {
+	DIV(CLK_DOUT_MISC_BUSP, "dout_misc_busp", "mout_misc_bus_user",
+	    CLK_CON_DIV_DIV_CLK_MISC_BUSP, 0, 3),
+	DIV(CLK_DOUT_MISC_GIC, "dout_misc_gic", "mout_misc_bus_user",
+	    CLK_CON_DIV_DIV_CLK_MISC_GIC, 0, 3),
+};
+
+static const struct samsung_gate_clock misc_gate_clks[] __initconst = {
+	GATE(CLK_GOUT_MISC_PCLK, "gout_misc_pclk", "dout_misc_busp",
+	     CLK_CON_GAT_CLK_BLK_MISC_UID_MISC_CMU_MISC_IPCLKPORT_PCLK,
+	     21, 0, 0),
+
+	GATE(CLK_GOUT_MISC_SYSREG_PCLK, "gout_misc_sysreg_pclk", "dout_misc_busp",
+	     CLK_CON_GAT_GOUT_BLK_MISC_UID_SYSREG_MISC_IPCLKPORT_PCLK,
+	     21, 0, 0),
+
+	GATE(CLK_GOUT_MISC_WDT_CLUSTER0, "gout_misc_wdt_cluster0", "dout_misc_busp",
+	     CLK_CON_GAT_GOUT_BLK_MISC_UID_WDT_CLUSTER0_IPCLKPORT_PCLK,
+	     21, 0, 0),
+
+	GATE(CLK_GOUT_MISC_WDT_CLUSTER1, "gout_misc_wdt_cluster1", "dout_misc_busp",
+	     CLK_CON_GAT_GOUT_BLK_MISC_UID_WDT_CLUSTER1_IPCLKPORT_PCLK,
+	     21, 0, 0),
+
+};
+
+static const struct samsung_cmu_info misc_cmu_info __initconst = {
+	.mux_clks		= misc_mux_clks,
+	.nr_mux_clks		= ARRAY_SIZE(misc_mux_clks),
+	.div_clks		= misc_div_clks,
+	.nr_div_clks		= ARRAY_SIZE(misc_div_clks),
+	.gate_clks		= misc_gate_clks,
+	.nr_gate_clks		= ARRAY_SIZE(misc_gate_clks),
+	.nr_clk_ids		= MISC_NR_CLK,
+	.clk_regs		= misc_clk_regs,
+	.nr_clk_regs		= ARRAY_SIZE(misc_clk_regs),
+	.clk_name		= "dout_misc_bus",
+};
+
 /* ---- platform_driver ----------------------------------------------------- */
 
 static int __init gs101_cmu_probe(struct platform_device *pdev)
@@ -1832,6 +2141,9 @@ static const struct of_device_id gs101_cmu_of_match[] = {
 	{
 		.compatible = "google,gs101-cmu-apm",
 		.data = &apm_cmu_info,
+	}, {
+		.compatible = "google,gs101-cmu-misc",
+		.data = &misc_cmu_info,
 	}, {
 	},
 };
-- 
2.42.0.609.gbb76f46606-goog

[PATCH v2 12/20] clk: samsung: clk-gs101: Add support for CMU_MISC clock unit

[Peter Griffin]

CMU Misc clocks IPs such as Watchdog. Add support for the
muxes, dividers and gates in this CMU.

Signed-off-by: Peter Griffin <peter.griffin@linaro.org>
---
 drivers/clk/samsung/clk-gs101.c | 312 ++++++++++++++++++++++++++++++++
 1 file changed, 312 insertions(+)

diff --git a/drivers/clk/samsung/clk-gs101.c b/drivers/clk/samsung/clk-gs101.c
index 525f95e60665..bf2bd8cd39d0 100644
--- a/drivers/clk/samsung/clk-gs101.c
+++ b/drivers/clk/samsung/clk-gs101.c
@@ -20,6 +20,7 @@
 /* NOTE: Must be equal to the last clock ID increased by one */
 #define TOP_NR_CLK                     (CLK_GOUT_CMU_BOOST + 1)
 #define APM_NR_CLK                     (CLK_APM_PLL_DIV16_APM + 1)
+#define MISC_NR_CLK                    (CLK_GOUT_MISC_WDT_CLUSTER1 + 1)
 
 /* ---- CMU_TOP ------------------------------------------------------------- */
 
@@ -1815,6 +1816,314 @@ static const struct samsung_cmu_info apm_cmu_info __initconst = {
 	.nr_clk_regs		= ARRAY_SIZE(apm_clk_regs),
 };
 
+/* ---- CMU_MISC ------------------------------------------------------------- */
+/* Register Offset definitions for CMU_MISC (0x10010000) */
+#define PLL_CON0_MUX_CLKCMU_MISC_BUS_USER	0x0600
+#define PLL_CON1_MUX_CLKCMU_MISC_BUS_USER	0x0604
+#define PLL_CON0_MUX_CLKCMU_MISC_SSS_USER	0x0610
+#define PLL_CON1_MUX_CLKCMU_MISC_SSS_USER	0x0614
+#define MISC_CMU_MISC_CONTROLLER_OPTION		0x0800
+#define CLKOUT_CON_BLK_MISC_CMU_MISC_CLKOUT0	0x0810
+#define CLK_CON_MUX_MUX_CLK_MISC_GIC		0x1000
+#define CLK_CON_DIV_DIV_CLK_MISC_BUSP		0x1800
+#define CLK_CON_DIV_DIV_CLK_MISC_GIC		0x1804
+#define CLK_CON_GAT_CLK_BLK_MISC_UID_MISC_CMU_MISC_IPCLKPORT_PCLK		0x2000
+#define CLK_CON_GAT_CLK_BLK_MISC_UID_OTP_CON_BIRA_IPCLKPORT_I_OSCCLK		0x2004
+#define CLK_CON_GAT_CLK_BLK_MISC_UID_OTP_CON_BISR_IPCLKPORT_I_OSCCLK		0x2008
+#define CLK_CON_GAT_CLK_BLK_MISC_UID_OTP_CON_TOP_IPCLKPORT_I_OSCCLK		0x200c
+#define CLK_CON_GAT_CLK_BLK_MISC_UID_RSTNSYNC_CLK_MISC_OSCCLK_IPCLKPORT_CLK	0x2010
+#define CLK_CON_GAT_GOUT_BLK_MISC_UID_ADM_AHB_SSS_IPCLKPORT_HCLKM		0x2014
+#define CLK_CON_GAT_GOUT_BLK_MISC_UID_AD_APB_DIT_IPCLKPORT_PCLKM		0x2018
+#define CLK_CON_GAT_GOUT_BLK_MISC_UID_AD_APB_PUF_IPCLKPORT_PCLKM		0x201c
+#define CLK_CON_GAT_GOUT_BLK_MISC_UID_DIT_IPCLKPORT_ICLKL2A			0x2020
+#define CLK_CON_GAT_GOUT_BLK_MISC_UID_D_TZPC_MISC_IPCLKPORT_PCLK		0x2024
+#define CLK_CON_GAT_GOUT_BLK_MISC_UID_GIC_IPCLKPORT_GICCLK			0x2028
+#define CLK_CON_GAT_GOUT_BLK_MISC_UID_GPC_MISC_IPCLKPORT_PCLK			0x202c
+#define CLK_CON_GAT_GOUT_BLK_MISC_UID_LHM_AST_ICC_CPUGIC_IPCLKPORT_I_CLK	0x2030
+#define CLK_CON_GAT_GOUT_BLK_MISC_UID_LHM_AXI_D_SSS_IPCLKPORT_I_CLK		0x2034
+#define CLK_CON_GAT_GOUT_BLK_MISC_UID_LHM_AXI_P_GIC_IPCLKPORT_I_CLK		0x2038
+#define CLK_CON_GAT_GOUT_BLK_MISC_UID_LHM_AXI_P_MISC_IPCLKPORT_I_CLK		0x203c
+#define CLK_CON_GAT_GOUT_BLK_MISC_UID_LHS_ACEL_D_MISC_IPCLKPORT_I_CLK		0x2040
+#define CLK_CON_GAT_GOUT_BLK_MISC_UID_LHS_AST_IRI_GICCPU_IPCLKPORT_I_CLK	0x2044
+#define CLK_CON_GAT_GOUT_BLK_MISC_UID_LHS_AXI_D_SSS_IPCLKPORT_I_CLK		0x2048
+#define CLK_CON_GAT_GOUT_BLK_MISC_UID_MCT_IPCLKPORT_PCLK			0x204c
+#define CLK_CON_GAT_GOUT_BLK_MISC_UID_OTP_CON_BIRA_IPCLKPORT_PCLK		0x2050
+#define CLK_CON_GAT_GOUT_BLK_MISC_UID_OTP_CON_BISR_IPCLKPORT_PCLK		0x2054
+#define CLK_CON_GAT_GOUT_BLK_MISC_UID_OTP_CON_TOP_IPCLKPORT_PCLK		0x2058
+#define CLK_CON_GAT_GOUT_BLK_MISC_UID_PDMA_IPCLKPORT_ACLK			0x205c
+#define CLK_CON_GAT_GOUT_BLK_MISC_UID_PPMU_DMA_IPCLKPORT_ACLK			0x2060
+#define CLK_CON_GAT_GOUT_BLK_MISC_UID_PPMU_MISC_IPCLKPORT_ACLK			0x2064
+#define CLK_CON_GAT_GOUT_BLK_MISC_UID_PPMU_MISC_IPCLKPORT_PCLK			0x2068
+#define CLK_CON_GAT_GOUT_BLK_MISC_UID_PUF_IPCLKPORT_I_CLK			0x206c
+#define CLK_CON_GAT_GOUT_BLK_MISC_UID_QE_DIT_IPCLKPORT_ACLK			0x2070
+#define CLK_CON_GAT_GOUT_BLK_MISC_UID_QE_DIT_IPCLKPORT_PCLK			0x2074
+#define CLK_CON_GAT_GOUT_BLK_MISC_UID_QE_PDMA_IPCLKPORT_ACLK			0x2078
+#define CLK_CON_GAT_GOUT_BLK_MISC_UID_QE_PDMA_IPCLKPORT_PCLK			0x207c
+#define CLK_CON_GAT_GOUT_BLK_MISC_UID_QE_PPMU_DMA_IPCLKPORT_ACLK		0x2080
+#define CLK_CON_GAT_GOUT_BLK_MISC_UID_QE_PPMU_DMA_IPCLKPORT_PCLK		0x2084
+#define CLK_CON_GAT_GOUT_BLK_MISC_UID_QE_RTIC_IPCLKPORT_ACLK			0x2088
+#define CLK_CON_GAT_GOUT_BLK_MISC_UID_QE_RTIC_IPCLKPORT_PCLK			0x208c
+#define CLK_CON_GAT_GOUT_BLK_MISC_UID_QE_SPDMA_IPCLKPORT_ACLK			0x2090
+#define CLK_CON_GAT_GOUT_BLK_MISC_UID_QE_SPDMA_IPCLKPORT_PCLK			0x2094
+#define CLK_CON_GAT_GOUT_BLK_MISC_UID_QE_SSS_IPCLKPORT_ACLK			0x2098
+#define CLK_CON_GAT_GOUT_BLK_MISC_UID_QE_SSS_IPCLKPORT_PCLK			0x209c
+#define CLK_CON_GAT_GOUT_BLK_MISC_UID_RSTNSYNC_CLK_MISC_BUSD_IPCLKPORT_CLK	0x20a0
+#define CLK_CON_GAT_GOUT_BLK_MISC_UID_RSTNSYNC_CLK_MISC_BUSP_IPCLKPORT_CLK	0x20a4
+#define CLK_CON_GAT_GOUT_BLK_MISC_UID_RSTNSYNC_CLK_MISC_GIC_IPCLKPORT_CLK	0x20a8
+#define CLK_CON_GAT_GOUT_BLK_MISC_UID_RSTNSYNC_CLK_MISC_SSS_IPCLKPORT_CLK	0x20ac
+#define CLK_CON_GAT_GOUT_BLK_MISC_UID_RTIC_IPCLKPORT_I_ACLK			0x20b0
+#define CLK_CON_GAT_GOUT_BLK_MISC_UID_RTIC_IPCLKPORT_I_PCLK			0x20b4
+#define CLK_CON_GAT_GOUT_BLK_MISC_UID_SPDMA_IPCLKPORT_ACLK			0x20b8
+#define CLK_CON_GAT_GOUT_BLK_MISC_UID_SSMT_DIT_IPCLKPORT_ACLK			0x20bc
+#define CLK_CON_GAT_GOUT_BLK_MISC_UID_SSMT_DIT_IPCLKPORT_PCLK			0x20c0
+#define CLK_CON_GAT_GOUT_BLK_MISC_UID_SSMT_PDMA_IPCLKPORT_ACLK			0x20c4
+#define CLK_CON_GAT_GOUT_BLK_MISC_UID_SSMT_PDMA_IPCLKPORT_PCLK			0x20c8
+#define CLK_CON_GAT_GOUT_BLK_MISC_UID_SSMT_PPMU_DMA_IPCLKPORT_ACLK		0x20cc
+#define CLK_CON_GAT_GOUT_BLK_MISC_UID_SSMT_PPMU_DMA_IPCLKPORT_PCLK		0x20d0
+#define CLK_CON_GAT_GOUT_BLK_MISC_UID_SSMT_RTIC_IPCLKPORT_ACLK			0x20d4
+#define CLK_CON_GAT_GOUT_BLK_MISC_UID_SSMT_RTIC_IPCLKPORT_PCLK			0x20d8
+#define CLK_CON_GAT_GOUT_BLK_MISC_UID_SSMT_SPDMA_IPCLKPORT_ACLK			0x20dc
+#define CLK_CON_GAT_GOUT_BLK_MISC_UID_SSMT_SPDMA_IPCLKPORT_PCLK			0x20e0
+#define CLK_CON_GAT_GOUT_BLK_MISC_UID_SSMT_SSS_IPCLKPORT_ACLK			0x20e4
+#define CLK_CON_GAT_GOUT_BLK_MISC_UID_SSMT_SSS_IPCLKPORT_PCLK			0x20e8
+#define CLK_CON_GAT_GOUT_BLK_MISC_UID_SSS_IPCLKPORT_I_ACLK			0x20ec
+#define CLK_CON_GAT_GOUT_BLK_MISC_UID_SSS_IPCLKPORT_I_PCLK			0x20f0
+#define CLK_CON_GAT_GOUT_BLK_MISC_UID_SYSMMU_MISC_IPCLKPORT_CLK_S2		0x20f4
+#define CLK_CON_GAT_GOUT_BLK_MISC_UID_SYSMMU_SSS_IPCLKPORT_CLK_S1		0x20f8
+#define CLK_CON_GAT_GOUT_BLK_MISC_UID_SYSREG_MISC_IPCLKPORT_PCLK		0x20fc
+#define CLK_CON_GAT_GOUT_BLK_MISC_UID_TMU_SUB_IPCLKPORT_PCLK			0x2100
+#define CLK_CON_GAT_GOUT_BLK_MISC_UID_TMU_TOP_IPCLKPORT_PCLK			0x2104
+#define CLK_CON_GAT_GOUT_BLK_MISC_UID_WDT_CLUSTER0_IPCLKPORT_PCLK		0x2108
+#define CLK_CON_GAT_GOUT_BLK_MISC_UID_WDT_CLUSTER1_IPCLKPORT_PCLK		0x210c
+#define CLK_CON_GAT_GOUT_BLK_MISC_UID_XIU_D_MISC_IPCLKPORT_ACLK			0x2110
+#define DMYQCH_CON_PPMU_DMA_QCH			0x3000
+#define DMYQCH_CON_PUF_QCH			0x3004
+#define PCH_CON_LHM_AXI_D_SSS_PCH		0x300c
+#define PCH_CON_LHM_AXI_P_GIC_PCH		0x3010
+#define PCH_CON_LHM_AXI_P_MISC_PCH		0x3014
+#define PCH_CON_LHS_ACEL_D_MISC_PCH		0x3018
+#define PCH_CON_LHS_AST_IRI_GICCPU_PCH		0x301c
+#define PCH_CON_LHS_AXI_D_SSS_PCH		0x3020
+#define QCH_CON_ADM_AHB_SSS_QCH			0x3024
+#define QCH_CON_DIT_QCH				0x3028
+#define QCH_CON_GIC_QCH				0x3030
+#define QCH_CON_LHM_AST_ICC_CPUGIC_QCH		0x3038
+#define QCH_CON_LHM_AXI_D_SSS_QCH		0x303c
+#define QCH_CON_LHM_AXI_P_GIC_QCH		0x3040
+#define QCH_CON_LHM_AXI_P_MISC_QCH		0x3044
+#define QCH_CON_LHS_ACEL_D_MISC_QCH		0x3048
+#define QCH_CON_LHS_AST_IRI_GICCPU_QCH		0x304c
+#define QCH_CON_LHS_AXI_D_SSS_QCH		0x3050
+#define QCH_CON_MCT_QCH				0x3054
+#define QCH_CON_MISC_CMU_MISC_QCH		0x3058
+#define QCH_CON_OTP_CON_BIRA_QCH		0x305c
+#define QCH_CON_OTP_CON_BISR_QCH		0x3060
+#define QCH_CON_OTP_CON_TOP_QCH			0x3064
+#define QCH_CON_PDMA_QCH			0x3068
+#define QCH_CON_PPMU_MISC_QCH			0x306c
+#define QCH_CON_QE_DIT_QCH			0x3070
+#define QCH_CON_QE_PDMA_QCH			0x3074
+#define QCH_CON_QE_PPMU_DMA_QCH			0x3078
+#define QCH_CON_QE_RTIC_QCH			0x307c
+#define QCH_CON_QE_SPDMA_QCH			0x3080
+#define QCH_CON_QE_SSS_QCH			0x3084
+#define QCH_CON_RTIC_QCH			0x3088
+#define QCH_CON_SPDMA_QCH			0x308c
+#define QCH_CON_SSMT_DIT_QCH			0x3090
+#define QCH_CON_SSMT_PDMA_QCH			0x3094
+#define QCH_CON_SSMT_PPMU_DMA_QCH		0x3098
+#define QCH_CON_SSMT_RTIC_QCH			0x309c
+#define QCH_CON_SSMT_SPDMA_QCH			0x30a0
+#define QCH_CON_SSMT_SSS_QCH			0x30a4
+#define QCH_CON_SSS_QCH				0x30a8
+#define QCH_CON_SYSMMU_MISC_QCH			0x30ac
+#define QCH_CON_SYSMMU_SSS_QCH			0x30b0
+#define QCH_CON_SYSREG_MISC_QCH			0x30b4
+#define QCH_CON_TMU_SUB_QCH			0x30b8
+#define QCH_CON_TMU_TOP_QCH			0x30bc
+#define QCH_CON_WDT_CLUSTER0_QCH		0x30c0
+#define QCH_CON_WDT_CLUSTER1_QCH		0x30c4
+#define QUEUE_CTRL_REG_BLK_MISC_CMU_MISC	0x3c00
+
+static const unsigned long misc_clk_regs[] __initconst = {
+	PLL_CON0_MUX_CLKCMU_MISC_BUS_USER,
+	PLL_CON1_MUX_CLKCMU_MISC_BUS_USER,
+	PLL_CON0_MUX_CLKCMU_MISC_SSS_USER,
+	PLL_CON1_MUX_CLKCMU_MISC_SSS_USER,
+	MISC_CMU_MISC_CONTROLLER_OPTION,
+	CLKOUT_CON_BLK_MISC_CMU_MISC_CLKOUT0,
+	CLK_CON_MUX_MUX_CLK_MISC_GIC,
+	CLK_CON_DIV_DIV_CLK_MISC_BUSP,
+	CLK_CON_DIV_DIV_CLK_MISC_GIC,
+	CLK_CON_GAT_CLK_BLK_MISC_UID_MISC_CMU_MISC_IPCLKPORT_PCLK,
+	CLK_CON_GAT_CLK_BLK_MISC_UID_OTP_CON_BIRA_IPCLKPORT_I_OSCCLK,
+	CLK_CON_GAT_CLK_BLK_MISC_UID_OTP_CON_BISR_IPCLKPORT_I_OSCCLK,
+	CLK_CON_GAT_CLK_BLK_MISC_UID_OTP_CON_TOP_IPCLKPORT_I_OSCCLK,
+	CLK_CON_GAT_CLK_BLK_MISC_UID_RSTNSYNC_CLK_MISC_OSCCLK_IPCLKPORT_CLK,
+	CLK_CON_GAT_GOUT_BLK_MISC_UID_ADM_AHB_SSS_IPCLKPORT_HCLKM,
+	CLK_CON_GAT_GOUT_BLK_MISC_UID_AD_APB_DIT_IPCLKPORT_PCLKM,
+	CLK_CON_GAT_GOUT_BLK_MISC_UID_AD_APB_PUF_IPCLKPORT_PCLKM,
+	CLK_CON_GAT_GOUT_BLK_MISC_UID_DIT_IPCLKPORT_ICLKL2A,
+	CLK_CON_GAT_GOUT_BLK_MISC_UID_D_TZPC_MISC_IPCLKPORT_PCLK,
+	CLK_CON_GAT_GOUT_BLK_MISC_UID_GIC_IPCLKPORT_GICCLK,
+	CLK_CON_GAT_GOUT_BLK_MISC_UID_GPC_MISC_IPCLKPORT_PCLK,
+	CLK_CON_GAT_GOUT_BLK_MISC_UID_LHM_AST_ICC_CPUGIC_IPCLKPORT_I_CLK,
+	CLK_CON_GAT_GOUT_BLK_MISC_UID_LHM_AXI_D_SSS_IPCLKPORT_I_CLK,
+	CLK_CON_GAT_GOUT_BLK_MISC_UID_LHM_AXI_P_GIC_IPCLKPORT_I_CLK,
+	CLK_CON_GAT_GOUT_BLK_MISC_UID_LHM_AXI_P_MISC_IPCLKPORT_I_CLK,
+	CLK_CON_GAT_GOUT_BLK_MISC_UID_LHS_ACEL_D_MISC_IPCLKPORT_I_CLK,
+	CLK_CON_GAT_GOUT_BLK_MISC_UID_LHS_AST_IRI_GICCPU_IPCLKPORT_I_CLK,
+	CLK_CON_GAT_GOUT_BLK_MISC_UID_LHS_AXI_D_SSS_IPCLKPORT_I_CLK,
+	CLK_CON_GAT_GOUT_BLK_MISC_UID_MCT_IPCLKPORT_PCLK,
+	CLK_CON_GAT_GOUT_BLK_MISC_UID_OTP_CON_BIRA_IPCLKPORT_PCLK,
+	CLK_CON_GAT_GOUT_BLK_MISC_UID_OTP_CON_BISR_IPCLKPORT_PCLK,
+	CLK_CON_GAT_GOUT_BLK_MISC_UID_OTP_CON_TOP_IPCLKPORT_PCLK,
+	CLK_CON_GAT_GOUT_BLK_MISC_UID_PDMA_IPCLKPORT_ACLK,
+	CLK_CON_GAT_GOUT_BLK_MISC_UID_PPMU_DMA_IPCLKPORT_ACLK,
+	CLK_CON_GAT_GOUT_BLK_MISC_UID_PPMU_MISC_IPCLKPORT_ACLK,
+	CLK_CON_GAT_GOUT_BLK_MISC_UID_PPMU_MISC_IPCLKPORT_PCLK,
+	CLK_CON_GAT_GOUT_BLK_MISC_UID_PUF_IPCLKPORT_I_CLK,
+	CLK_CON_GAT_GOUT_BLK_MISC_UID_QE_DIT_IPCLKPORT_ACLK,
+	CLK_CON_GAT_GOUT_BLK_MISC_UID_QE_DIT_IPCLKPORT_PCLK,
+	CLK_CON_GAT_GOUT_BLK_MISC_UID_QE_PDMA_IPCLKPORT_ACLK,
+	CLK_CON_GAT_GOUT_BLK_MISC_UID_QE_PDMA_IPCLKPORT_PCLK,
+	CLK_CON_GAT_GOUT_BLK_MISC_UID_QE_PPMU_DMA_IPCLKPORT_ACLK,
+	CLK_CON_GAT_GOUT_BLK_MISC_UID_QE_PPMU_DMA_IPCLKPORT_PCLK,
+	CLK_CON_GAT_GOUT_BLK_MISC_UID_QE_RTIC_IPCLKPORT_ACLK,
+	CLK_CON_GAT_GOUT_BLK_MISC_UID_QE_RTIC_IPCLKPORT_PCLK,
+	CLK_CON_GAT_GOUT_BLK_MISC_UID_QE_SPDMA_IPCLKPORT_ACLK,
+	CLK_CON_GAT_GOUT_BLK_MISC_UID_QE_SPDMA_IPCLKPORT_PCLK,
+	CLK_CON_GAT_GOUT_BLK_MISC_UID_QE_SSS_IPCLKPORT_ACLK,
+	CLK_CON_GAT_GOUT_BLK_MISC_UID_QE_SSS_IPCLKPORT_PCLK,
+	CLK_CON_GAT_GOUT_BLK_MISC_UID_RSTNSYNC_CLK_MISC_BUSD_IPCLKPORT_CLK,
+	CLK_CON_GAT_GOUT_BLK_MISC_UID_RSTNSYNC_CLK_MISC_BUSP_IPCLKPORT_CLK,
+	CLK_CON_GAT_GOUT_BLK_MISC_UID_RSTNSYNC_CLK_MISC_GIC_IPCLKPORT_CLK,
+	CLK_CON_GAT_GOUT_BLK_MISC_UID_RSTNSYNC_CLK_MISC_SSS_IPCLKPORT_CLK,
+	CLK_CON_GAT_GOUT_BLK_MISC_UID_RTIC_IPCLKPORT_I_ACLK,
+	CLK_CON_GAT_GOUT_BLK_MISC_UID_RTIC_IPCLKPORT_I_PCLK,
+	CLK_CON_GAT_GOUT_BLK_MISC_UID_SPDMA_IPCLKPORT_ACLK,
+	CLK_CON_GAT_GOUT_BLK_MISC_UID_SSMT_DIT_IPCLKPORT_ACLK,
+	CLK_CON_GAT_GOUT_BLK_MISC_UID_SSMT_DIT_IPCLKPORT_PCLK,
+	CLK_CON_GAT_GOUT_BLK_MISC_UID_SSMT_PDMA_IPCLKPORT_ACLK,
+	CLK_CON_GAT_GOUT_BLK_MISC_UID_SSMT_PDMA_IPCLKPORT_PCLK,
+	CLK_CON_GAT_GOUT_BLK_MISC_UID_SSMT_PPMU_DMA_IPCLKPORT_ACLK,
+	CLK_CON_GAT_GOUT_BLK_MISC_UID_SSMT_PPMU_DMA_IPCLKPORT_PCLK,
+	CLK_CON_GAT_GOUT_BLK_MISC_UID_SSMT_RTIC_IPCLKPORT_ACLK,
+	CLK_CON_GAT_GOUT_BLK_MISC_UID_SSMT_RTIC_IPCLKPORT_PCLK,
+	CLK_CON_GAT_GOUT_BLK_MISC_UID_SSMT_SPDMA_IPCLKPORT_ACLK,
+	CLK_CON_GAT_GOUT_BLK_MISC_UID_SSMT_SPDMA_IPCLKPORT_PCLK,
+	CLK_CON_GAT_GOUT_BLK_MISC_UID_SSMT_SSS_IPCLKPORT_ACLK,
+	CLK_CON_GAT_GOUT_BLK_MISC_UID_SSMT_SSS_IPCLKPORT_PCLK,
+	CLK_CON_GAT_GOUT_BLK_MISC_UID_SSS_IPCLKPORT_I_ACLK,
+	CLK_CON_GAT_GOUT_BLK_MISC_UID_SSS_IPCLKPORT_I_PCLK,
+	CLK_CON_GAT_GOUT_BLK_MISC_UID_SYSMMU_MISC_IPCLKPORT_CLK_S2,
+	CLK_CON_GAT_GOUT_BLK_MISC_UID_SYSMMU_SSS_IPCLKPORT_CLK_S1,
+	CLK_CON_GAT_GOUT_BLK_MISC_UID_SYSREG_MISC_IPCLKPORT_PCLK,
+	CLK_CON_GAT_GOUT_BLK_MISC_UID_TMU_SUB_IPCLKPORT_PCLK,
+	CLK_CON_GAT_GOUT_BLK_MISC_UID_TMU_TOP_IPCLKPORT_PCLK,
+	CLK_CON_GAT_GOUT_BLK_MISC_UID_WDT_CLUSTER0_IPCLKPORT_PCLK,
+	CLK_CON_GAT_GOUT_BLK_MISC_UID_WDT_CLUSTER1_IPCLKPORT_PCLK,
+	CLK_CON_GAT_GOUT_BLK_MISC_UID_XIU_D_MISC_IPCLKPORT_ACLK,
+	DMYQCH_CON_PPMU_DMA_QCH,
+	DMYQCH_CON_PUF_QCH,
+	PCH_CON_LHM_AXI_D_SSS_PCH,
+	PCH_CON_LHM_AXI_P_GIC_PCH,
+	PCH_CON_LHM_AXI_P_MISC_PCH,
+	PCH_CON_LHS_ACEL_D_MISC_PCH,
+	PCH_CON_LHS_AST_IRI_GICCPU_PCH,
+	PCH_CON_LHS_AXI_D_SSS_PCH,
+	QCH_CON_ADM_AHB_SSS_QCH,
+	QCH_CON_DIT_QCH,
+	QCH_CON_GIC_QCH,
+	QCH_CON_LHM_AST_ICC_CPUGIC_QCH,
+	QCH_CON_LHM_AXI_D_SSS_QCH,
+	QCH_CON_LHM_AXI_P_GIC_QCH,
+	QCH_CON_LHM_AXI_P_MISC_QCH,
+	QCH_CON_LHS_ACEL_D_MISC_QCH,
+	QCH_CON_LHS_AST_IRI_GICCPU_QCH,
+	QCH_CON_LHS_AXI_D_SSS_QCH,
+	QCH_CON_MCT_QCH,
+	QCH_CON_MISC_CMU_MISC_QCH,
+	QCH_CON_OTP_CON_BIRA_QCH,
+	QCH_CON_OTP_CON_BISR_QCH,
+	QCH_CON_OTP_CON_TOP_QCH,
+	QCH_CON_PDMA_QCH,
+	QCH_CON_PPMU_MISC_QCH,
+	QCH_CON_QE_DIT_QCH,
+	QCH_CON_QE_PDMA_QCH,
+	QCH_CON_QE_PPMU_DMA_QCH,
+	QCH_CON_QE_RTIC_QCH,
+	QCH_CON_QE_SPDMA_QCH,
+	QCH_CON_QE_SSS_QCH,
+	QCH_CON_RTIC_QCH,
+	QCH_CON_SPDMA_QCH,
+	QCH_CON_SSMT_DIT_QCH,
+	QCH_CON_SSMT_PDMA_QCH,
+	QCH_CON_SSMT_PPMU_DMA_QCH,
+	QCH_CON_SSMT_RTIC_QCH,
+	QCH_CON_SSMT_SPDMA_QCH,
+	QCH_CON_SSMT_SSS_QCH,
+	QCH_CON_SSS_QCH,
+	QCH_CON_SYSMMU_MISC_QCH,
+	QCH_CON_SYSMMU_SSS_QCH,
+	QCH_CON_SYSREG_MISC_QCH,
+	QCH_CON_TMU_SUB_QCH,
+	QCH_CON_TMU_TOP_QCH,
+	QCH_CON_WDT_CLUSTER0_QCH,
+	QCH_CON_WDT_CLUSTER1_QCH,
+	QUEUE_CTRL_REG_BLK_MISC_CMU_MISC,
+};
+
+/* List of parent clocks for Muxes in CMU_MISC */
+PNAME(mout_misc_bus_user_p)		= { "oscclk", "dout_cmu_misc_bus" };
+PNAME(mout_misc_sss_user_p)		= { "oscclk", "dout_cmu_misc_sss" };
+
+static const struct samsung_mux_clock misc_mux_clks[] __initconst = {
+	MUX(CLK_MOUT_MISC_BUS_USER, "mout_misc_bus_user", mout_misc_bus_user_p,
+	    PLL_CON0_MUX_CLKCMU_MISC_BUS_USER, 4, 1),
+	MUX(CLK_MOUT_MISC_SSS_USER, "mout_misc_sss_user", mout_misc_sss_user_p,
+	    PLL_CON0_MUX_CLKCMU_MISC_SSS_USER, 4, 1),
+};
+
+static const struct samsung_div_clock misc_div_clks[] __initconst = {
+	DIV(CLK_DOUT_MISC_BUSP, "dout_misc_busp", "mout_misc_bus_user",
+	    CLK_CON_DIV_DIV_CLK_MISC_BUSP, 0, 3),
+	DIV(CLK_DOUT_MISC_GIC, "dout_misc_gic", "mout_misc_bus_user",
+	    CLK_CON_DIV_DIV_CLK_MISC_GIC, 0, 3),
+};
+
+static const struct samsung_gate_clock misc_gate_clks[] __initconst = {
+	GATE(CLK_GOUT_MISC_PCLK, "gout_misc_pclk", "dout_misc_busp",
+	     CLK_CON_GAT_CLK_BLK_MISC_UID_MISC_CMU_MISC_IPCLKPORT_PCLK,
+	     21, 0, 0),
+
+	GATE(CLK_GOUT_MISC_SYSREG_PCLK, "gout_misc_sysreg_pclk", "dout_misc_busp",
+	     CLK_CON_GAT_GOUT_BLK_MISC_UID_SYSREG_MISC_IPCLKPORT_PCLK,
+	     21, 0, 0),
+
+	GATE(CLK_GOUT_MISC_WDT_CLUSTER0, "gout_misc_wdt_cluster0", "dout_misc_busp",
+	     CLK_CON_GAT_GOUT_BLK_MISC_UID_WDT_CLUSTER0_IPCLKPORT_PCLK,
+	     21, 0, 0),
+
+	GATE(CLK_GOUT_MISC_WDT_CLUSTER1, "gout_misc_wdt_cluster1", "dout_misc_busp",
+	     CLK_CON_GAT_GOUT_BLK_MISC_UID_WDT_CLUSTER1_IPCLKPORT_PCLK,
+	     21, 0, 0),
+
+};
+
+static const struct samsung_cmu_info misc_cmu_info __initconst = {
+	.mux_clks		= misc_mux_clks,
+	.nr_mux_clks		= ARRAY_SIZE(misc_mux_clks),
+	.div_clks		= misc_div_clks,
+	.nr_div_clks		= ARRAY_SIZE(misc_div_clks),
+	.gate_clks		= misc_gate_clks,
+	.nr_gate_clks		= ARRAY_SIZE(misc_gate_clks),
+	.nr_clk_ids		= MISC_NR_CLK,
+	.clk_regs		= misc_clk_regs,
+	.nr_clk_regs		= ARRAY_SIZE(misc_clk_regs),
+	.clk_name		= "dout_misc_bus",
+};
+
 /* ---- platform_driver ----------------------------------------------------- */
 
 static int __init gs101_cmu_probe(struct platform_device *pdev)
@@ -1832,6 +2141,9 @@ static const struct of_device_id gs101_cmu_of_match[] = {
 	{
 		.compatible = "google,gs101-cmu-apm",
 		.data = &apm_cmu_info,
+	}, {
+		.compatible = "google,gs101-cmu-misc",
+		.data = &misc_cmu_info,
 	}, {
 	},
 };
-- 
2.42.0.609.gbb76f46606-goog


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH v2 13/20] pinctrl: samsung: Add filter selection support for alive banks

[Peter Griffin]

Newer Exynos SoCs have a filter selection register on alive bank pins.
This allows the selection of a digital or delay filter for each pin. If
the filter selection register is not available then the default filter
(digital) is applied.

On suspend we apply the analog filter to all pins in the bank, and on
resume the digital filter is reapplied to all pins in the bank.

Signed-off-by: Peter Griffin <peter.griffin@linaro.org>
---
 drivers/pinctrl/samsung/pinctrl-exynos.c  | 82 ++++++++++++++++++++++-
 drivers/pinctrl/samsung/pinctrl-exynos.h  |  7 ++
 drivers/pinctrl/samsung/pinctrl-samsung.c |  2 +
 drivers/pinctrl/samsung/pinctrl-samsung.h | 23 +++++++
 4 files changed, 113 insertions(+), 1 deletion(-)

diff --git a/drivers/pinctrl/samsung/pinctrl-exynos.c b/drivers/pinctrl/samsung/pinctrl-exynos.c
index a8212fc126bf..800831aa8357 100644
--- a/drivers/pinctrl/samsung/pinctrl-exynos.c
+++ b/drivers/pinctrl/samsung/pinctrl-exynos.c
@@ -269,6 +269,68 @@ struct exynos_eint_gpio_save {
 	u32 eint_mask;
 };
 
+static void exynos_eint_flt_config(struct samsung_pinctrl_drv_data *d,
+				   struct samsung_pin_bank *bank, int filter)
+{
+	unsigned int flt_reg, flt_con = 0;
+	unsigned int val, shift;
+	int i;
+	int loop_cnt;
+
+	/*
+	 * This function sets the desired filter (digital or delay) to
+	 * every pin in the bank. Note the filter selection bitfield is
+	 * only found on alive banks. The FLTCON register has the
+	 * following layout
+	 *
+	 * BitfieldName[PinNum][Bit:Bit]
+	 *
+	 * FLT_EN[3][31] FLT_SEL[3][30] FLT_WIDTH[3][29:24]
+	 * FLT_EN[2][23] FLT_SEL[2][22] FLT_WIDTH[2][21:16]
+	 * FLT_EN[1][15] FLT_SEL[1][14] FLT_WIDTH[1][13:8]
+	 * FLT_EN[0][7]  FLT_SEL[0][6]  FLT_WIDTH[0][5:0]
+	 */
+
+	flt_con |= EXYNOS9_FLTCON_EN;
+
+	if (filter)
+		flt_con |= EXYNOS9_FLTCON_SEL_DIGITAL;
+
+	flt_reg = EXYNOS_GPIO_EFLTCON_OFFSET + bank->fltcon_offset;
+
+	if (bank->nr_pins > EXYNOS9_FLTCON_NR_PIN)
+		/*
+		 * if nr_pins > 4, we should set FLTCON0 register fully.
+		 * (pin0 ~ 3). So loop 4 times in case of FLTCON0.
+		 */
+		loop_cnt = EXYNOS9_FLTCON_NR_PIN;
+	else
+		loop_cnt = bank->nr_pins;
+
+	val = readl(d->virt_base + flt_reg);
+
+	for (i = 0; i < loop_cnt; i++) {
+		shift = i * EXYNOS9_FLTCON_LEN;
+		val &= ~(EXYNOS9_FLTCON_MASK << shift);
+		val |= (flt_con << shift);
+	}
+
+	writel(val, d->virt_base + flt_reg);
+
+	/* loop for FLTCON1 pin 4 ~ 7 */
+	if (bank->nr_pins > EXYNOS9_FLTCON_NR_PIN) {
+		val = readl(d->virt_base + flt_reg + 0x4);
+		loop_cnt = (bank->nr_pins - EXYNOS9_FLTCON_NR_PIN);
+
+		for (i = 0; i < loop_cnt; i++) {
+			shift = i * EXYNOS9_FLTCON_LEN;
+			val &= ~(EXYNOS9_FLTCON_MASK << shift);
+			val |= (flt_con << shift);
+		}
+		writel(val, d->virt_base + flt_reg + 0x4);
+	}
+}
+
 /*
  * exynos_eint_gpio_init() - setup handling of external gpio interrupts.
  * @d: driver data of samsung pinctrl driver.
@@ -321,6 +383,9 @@ __init int exynos_eint_gpio_init(struct samsung_pinctrl_drv_data *d)
 			goto err_domains;
 		}
 
+		/* Set Delay Analog Filter */
+		if (bank->fltcon_type != FLT_DEFAULT)
+			exynos_eint_flt_config(d, bank, EXYNOS9_FLTCON_SEL_DELAY);
 	}
 
 	return 0;
@@ -555,6 +620,10 @@ __init int exynos_eint_wkup_init(struct samsung_pinctrl_drv_data *d)
 		if (bank->eint_type != EINT_TYPE_WKUP)
 			continue;
 
+		/* Set Digital Filter */
+		if (bank->fltcon_type != FLT_DEFAULT)
+			exynos_eint_flt_config(d, bank, EXYNOS9_FLTCON_SEL_DIGITAL);
+
 		bank->irq_chip = devm_kmemdup(dev, irq_chip, sizeof(*irq_chip),
 					      GFP_KERNEL);
 		if (!bank->irq_chip) {
@@ -658,6 +727,7 @@ static void exynos_pinctrl_suspend_bank(
 void exynos_pinctrl_suspend(struct samsung_pinctrl_drv_data *drvdata)
 {
 	struct samsung_pin_bank *bank = drvdata->pin_banks;
+	struct samsung_pinctrl_drv_data *d = bank->drvdata;
 	struct exynos_irq_chip *irq_chip = NULL;
 	int i;
 
@@ -665,6 +735,9 @@ void exynos_pinctrl_suspend(struct samsung_pinctrl_drv_data *drvdata)
 		if (bank->eint_type == EINT_TYPE_GPIO)
 			exynos_pinctrl_suspend_bank(drvdata, bank);
 		else if (bank->eint_type == EINT_TYPE_WKUP) {
+			/* Setting Delay (Analog) Filter */
+			if (bank->fltcon_type != FLT_DEFAULT)
+				exynos_eint_flt_config(d, bank, EXYNOS9_FLTCON_SEL_DELAY);
 			if (!irq_chip) {
 				irq_chip = bank->irq_chip;
 				irq_chip->set_eint_wakeup_mask(drvdata,
@@ -707,11 +780,18 @@ static void exynos_pinctrl_resume_bank(
 void exynos_pinctrl_resume(struct samsung_pinctrl_drv_data *drvdata)
 {
 	struct samsung_pin_bank *bank = drvdata->pin_banks;
+	struct samsung_pinctrl_drv_data *d = bank->drvdata;
 	int i;
 
 	for (i = 0; i < drvdata->nr_banks; ++i, ++bank)
-		if (bank->eint_type == EINT_TYPE_GPIO)
+		if (bank->eint_type == EINT_TYPE_GPIO) {
 			exynos_pinctrl_resume_bank(drvdata, bank);
+		} else if (bank->eint_type == EINT_TYPE_WKUP ||
+			bank->eint_type == EINT_TYPE_WKUP_MUX) {
+			/* Set Digital Filter */
+			if (bank->fltcon_type != FLT_DEFAULT)
+				exynos_eint_flt_config(d, bank, EXYNOS9_FLTCON_SEL_DIGITAL);
+		}
 }
 
 static void exynos_retention_enable(struct samsung_pinctrl_drv_data *drvdata)
diff --git a/drivers/pinctrl/samsung/pinctrl-exynos.h b/drivers/pinctrl/samsung/pinctrl-exynos.h
index 7bd6d82c9f36..63b2426ad5d6 100644
--- a/drivers/pinctrl/samsung/pinctrl-exynos.h
+++ b/drivers/pinctrl/samsung/pinctrl-exynos.h
@@ -50,6 +50,13 @@
 
 #define EXYNOS_EINT_MAX_PER_BANK	8
 #define EXYNOS_EINT_NR_WKUP_EINT
+/* EINT filter configuration */
+#define EXYNOS9_FLTCON_EN		BIT(7)
+#define EXYNOS9_FLTCON_SEL_DIGITAL	BIT(6)
+#define EXYNOS9_FLTCON_SEL_DELAY	0
+#define EXYNOS9_FLTCON_MASK		0xff
+#define EXYNOS9_FLTCON_LEN		8
+#define EXYNOS9_FLTCON_NR_PIN		4
 
 #define EXYNOS_PIN_BANK_EINTN(pins, reg, id)		\
 	{						\
diff --git a/drivers/pinctrl/samsung/pinctrl-samsung.c b/drivers/pinctrl/samsung/pinctrl-samsung.c
index e54847040b4a..449f8109d8b5 100644
--- a/drivers/pinctrl/samsung/pinctrl-samsung.c
+++ b/drivers/pinctrl/samsung/pinctrl-samsung.c
@@ -1104,6 +1104,8 @@ samsung_pinctrl_get_soc_data(struct samsung_pinctrl_drv_data *d,
 		bank->eint_func = bdata->eint_func;
 		bank->eint_type = bdata->eint_type;
 		bank->eint_mask = bdata->eint_mask;
+		bank->fltcon_type = bdata->fltcon_type;
+		bank->fltcon_offset = bdata->fltcon_offset;
 		bank->eint_offset = bdata->eint_offset;
 		bank->name = bdata->name;
 
diff --git a/drivers/pinctrl/samsung/pinctrl-samsung.h b/drivers/pinctrl/samsung/pinctrl-samsung.h
index 9af93e3d8d9f..de2ca8e8b378 100644
--- a/drivers/pinctrl/samsung/pinctrl-samsung.h
+++ b/drivers/pinctrl/samsung/pinctrl-samsung.h
@@ -82,6 +82,21 @@ enum eint_type {
 	EINT_TYPE_WKUP_MUX,
 };
 
+/**
+ * enum fltcon_type - filter selection
+ * @FLT_DEFAULT: filter not selectable, default digital filter
+ * @FLT_SELECT: filter selectable (digital or delay)
+ *
+ * Some banks on some SoCs (gs101 and possibly others) have a selectable
+ * filter on alive banks of 'delay/analog' or 'digital'. If the filter
+ * selection is not available then the default filter is used (digital).
+ */
+
+enum fltcon_type {
+	FLT_DEFAULT,
+	FLT_SELECTABLE,
+};
+
 /* maximum length of a pin in pin descriptor (example: "gpa0-0") */
 #define PIN_NAME_LENGTH	10
 
@@ -122,6 +137,8 @@ struct samsung_pin_bank_type {
  * @eint_type: type of the external interrupt supported by the bank.
  * @eint_mask: bit mask of pins which support EINT function.
  * @eint_offset: SoC-specific EINT register or interrupt offset of bank.
+ * @fltcon_type: whether the filter (delay/digital) is selectable
+ * @fltcon_offset: SoC-specific EINT filter control register offset of bank.
  * @name: name to be prefixed for each pin in this pin bank.
  */
 struct samsung_pin_bank_data {
@@ -133,6 +150,8 @@ struct samsung_pin_bank_data {
 	enum eint_type	eint_type;
 	u32		eint_mask;
 	u32		eint_offset;
+	enum fltcon_type fltcon_type;
+	u32		fltcon_offset;
 	const char	*name;
 };
 
@@ -147,6 +166,8 @@ struct samsung_pin_bank_data {
  * @eint_type: type of the external interrupt supported by the bank.
  * @eint_mask: bit mask of pins which support EINT function.
  * @eint_offset: SoC-specific EINT register or interrupt offset of bank.
+ * @fltcon_type: whether the filter (delay/digital) is selectable
+ * @fltcon_offset: SoC-specific EINT filter control register offset of bank.
  * @name: name to be prefixed for each pin in this pin bank.
  * @pin_base: starting pin number of the bank.
  * @soc_priv: per-bank private data for SoC-specific code.
@@ -169,6 +190,8 @@ struct samsung_pin_bank {
 	enum eint_type	eint_type;
 	u32		eint_mask;
 	u32		eint_offset;
+	enum fltcon_type fltcon_type;
+	u32		fltcon_offset;
 	const char	*name;
 
 	u32		pin_base;
-- 
2.42.0.609.gbb76f46606-goog

[PATCH v2 13/20] pinctrl: samsung: Add filter selection support for alive banks

[Peter Griffin]

Newer Exynos SoCs have a filter selection register on alive bank pins.
This allows the selection of a digital or delay filter for each pin. If
the filter selection register is not available then the default filter
(digital) is applied.

On suspend we apply the analog filter to all pins in the bank, and on
resume the digital filter is reapplied to all pins in the bank.

Signed-off-by: Peter Griffin <peter.griffin@linaro.org>
---
 drivers/pinctrl/samsung/pinctrl-exynos.c  | 82 ++++++++++++++++++++++-
 drivers/pinctrl/samsung/pinctrl-exynos.h  |  7 ++
 drivers/pinctrl/samsung/pinctrl-samsung.c |  2 +
 drivers/pinctrl/samsung/pinctrl-samsung.h | 23 +++++++
 4 files changed, 113 insertions(+), 1 deletion(-)

diff --git a/drivers/pinctrl/samsung/pinctrl-exynos.c b/drivers/pinctrl/samsung/pinctrl-exynos.c
index a8212fc126bf..800831aa8357 100644
--- a/drivers/pinctrl/samsung/pinctrl-exynos.c
+++ b/drivers/pinctrl/samsung/pinctrl-exynos.c
@@ -269,6 +269,68 @@ struct exynos_eint_gpio_save {
 	u32 eint_mask;
 };
 
+static void exynos_eint_flt_config(struct samsung_pinctrl_drv_data *d,
+				   struct samsung_pin_bank *bank, int filter)
+{
+	unsigned int flt_reg, flt_con = 0;
+	unsigned int val, shift;
+	int i;
+	int loop_cnt;
+
+	/*
+	 * This function sets the desired filter (digital or delay) to
+	 * every pin in the bank. Note the filter selection bitfield is
+	 * only found on alive banks. The FLTCON register has the
+	 * following layout
+	 *
+	 * BitfieldName[PinNum][Bit:Bit]
+	 *
+	 * FLT_EN[3][31] FLT_SEL[3][30] FLT_WIDTH[3][29:24]
+	 * FLT_EN[2][23] FLT_SEL[2][22] FLT_WIDTH[2][21:16]
+	 * FLT_EN[1][15] FLT_SEL[1][14] FLT_WIDTH[1][13:8]
+	 * FLT_EN[0][7]  FLT_SEL[0][6]  FLT_WIDTH[0][5:0]
+	 */
+
+	flt_con |= EXYNOS9_FLTCON_EN;
+
+	if (filter)
+		flt_con |= EXYNOS9_FLTCON_SEL_DIGITAL;
+
+	flt_reg = EXYNOS_GPIO_EFLTCON_OFFSET + bank->fltcon_offset;
+
+	if (bank->nr_pins > EXYNOS9_FLTCON_NR_PIN)
+		/*
+		 * if nr_pins > 4, we should set FLTCON0 register fully.
+		 * (pin0 ~ 3). So loop 4 times in case of FLTCON0.
+		 */
+		loop_cnt = EXYNOS9_FLTCON_NR_PIN;
+	else
+		loop_cnt = bank->nr_pins;
+
+	val = readl(d->virt_base + flt_reg);
+
+	for (i = 0; i < loop_cnt; i++) {
+		shift = i * EXYNOS9_FLTCON_LEN;
+		val &= ~(EXYNOS9_FLTCON_MASK << shift);
+		val |= (flt_con << shift);
+	}
+
+	writel(val, d->virt_base + flt_reg);
+
+	/* loop for FLTCON1 pin 4 ~ 7 */
+	if (bank->nr_pins > EXYNOS9_FLTCON_NR_PIN) {
+		val = readl(d->virt_base + flt_reg + 0x4);
+		loop_cnt = (bank->nr_pins - EXYNOS9_FLTCON_NR_PIN);
+
+		for (i = 0; i < loop_cnt; i++) {
+			shift = i * EXYNOS9_FLTCON_LEN;
+			val &= ~(EXYNOS9_FLTCON_MASK << shift);
+			val |= (flt_con << shift);
+		}
+		writel(val, d->virt_base + flt_reg + 0x4);
+	}
+}
+
 /*
  * exynos_eint_gpio_init() - setup handling of external gpio interrupts.
  * @d: driver data of samsung pinctrl driver.
@@ -321,6 +383,9 @@ __init int exynos_eint_gpio_init(struct samsung_pinctrl_drv_data *d)
 			goto err_domains;
 		}
 
+		/* Set Delay Analog Filter */
+		if (bank->fltcon_type != FLT_DEFAULT)
+			exynos_eint_flt_config(d, bank, EXYNOS9_FLTCON_SEL_DELAY);
 	}
 
 	return 0;
@@ -555,6 +620,10 @@ __init int exynos_eint_wkup_init(struct samsung_pinctrl_drv_data *d)
 		if (bank->eint_type != EINT_TYPE_WKUP)
 			continue;
 
+		/* Set Digital Filter */
+		if (bank->fltcon_type != FLT_DEFAULT)
+			exynos_eint_flt_config(d, bank, EXYNOS9_FLTCON_SEL_DIGITAL);
+
 		bank->irq_chip = devm_kmemdup(dev, irq_chip, sizeof(*irq_chip),
 					      GFP_KERNEL);
 		if (!bank->irq_chip) {
@@ -658,6 +727,7 @@ static void exynos_pinctrl_suspend_bank(
 void exynos_pinctrl_suspend(struct samsung_pinctrl_drv_data *drvdata)
 {
 	struct samsung_pin_bank *bank = drvdata->pin_banks;
+	struct samsung_pinctrl_drv_data *d = bank->drvdata;
 	struct exynos_irq_chip *irq_chip = NULL;
 	int i;
 
@@ -665,6 +735,9 @@ void exynos_pinctrl_suspend(struct samsung_pinctrl_drv_data *drvdata)
 		if (bank->eint_type == EINT_TYPE_GPIO)
 			exynos_pinctrl_suspend_bank(drvdata, bank);
 		else if (bank->eint_type == EINT_TYPE_WKUP) {
+			/* Setting Delay (Analog) Filter */
+			if (bank->fltcon_type != FLT_DEFAULT)
+				exynos_eint_flt_config(d, bank, EXYNOS9_FLTCON_SEL_DELAY);
 			if (!irq_chip) {
 				irq_chip = bank->irq_chip;
 				irq_chip->set_eint_wakeup_mask(drvdata,
@@ -707,11 +780,18 @@ static void exynos_pinctrl_resume_bank(
 void exynos_pinctrl_resume(struct samsung_pinctrl_drv_data *drvdata)
 {
 	struct samsung_pin_bank *bank = drvdata->pin_banks;
+	struct samsung_pinctrl_drv_data *d = bank->drvdata;
 	int i;
 
 	for (i = 0; i < drvdata->nr_banks; ++i, ++bank)
-		if (bank->eint_type == EINT_TYPE_GPIO)
+		if (bank->eint_type == EINT_TYPE_GPIO) {
 			exynos_pinctrl_resume_bank(drvdata, bank);
+		} else if (bank->eint_type == EINT_TYPE_WKUP ||
+			bank->eint_type == EINT_TYPE_WKUP_MUX) {
+			/* Set Digital Filter */
+			if (bank->fltcon_type != FLT_DEFAULT)
+				exynos_eint_flt_config(d, bank, EXYNOS9_FLTCON_SEL_DIGITAL);
+		}
 }
 
 static void exynos_retention_enable(struct samsung_pinctrl_drv_data *drvdata)
diff --git a/drivers/pinctrl/samsung/pinctrl-exynos.h b/drivers/pinctrl/samsung/pinctrl-exynos.h
index 7bd6d82c9f36..63b2426ad5d6 100644
--- a/drivers/pinctrl/samsung/pinctrl-exynos.h
+++ b/drivers/pinctrl/samsung/pinctrl-exynos.h
@@ -50,6 +50,13 @@
 
 #define EXYNOS_EINT_MAX_PER_BANK	8
 #define EXYNOS_EINT_NR_WKUP_EINT
+/* EINT filter configuration */
+#define EXYNOS9_FLTCON_EN		BIT(7)
+#define EXYNOS9_FLTCON_SEL_DIGITAL	BIT(6)
+#define EXYNOS9_FLTCON_SEL_DELAY	0
+#define EXYNOS9_FLTCON_MASK		0xff
+#define EXYNOS9_FLTCON_LEN		8
+#define EXYNOS9_FLTCON_NR_PIN		4
 
 #define EXYNOS_PIN_BANK_EINTN(pins, reg, id)		\
 	{						\
diff --git a/drivers/pinctrl/samsung/pinctrl-samsung.c b/drivers/pinctrl/samsung/pinctrl-samsung.c
index e54847040b4a..449f8109d8b5 100644
--- a/drivers/pinctrl/samsung/pinctrl-samsung.c
+++ b/drivers/pinctrl/samsung/pinctrl-samsung.c
@@ -1104,6 +1104,8 @@ samsung_pinctrl_get_soc_data(struct samsung_pinctrl_drv_data *d,
 		bank->eint_func = bdata->eint_func;
 		bank->eint_type = bdata->eint_type;
 		bank->eint_mask = bdata->eint_mask;
+		bank->fltcon_type = bdata->fltcon_type;
+		bank->fltcon_offset = bdata->fltcon_offset;
 		bank->eint_offset = bdata->eint_offset;
 		bank->name = bdata->name;
 
diff --git a/drivers/pinctrl/samsung/pinctrl-samsung.h b/drivers/pinctrl/samsung/pinctrl-samsung.h
index 9af93e3d8d9f..de2ca8e8b378 100644
--- a/drivers/pinctrl/samsung/pinctrl-samsung.h
+++ b/drivers/pinctrl/samsung/pinctrl-samsung.h
@@ -82,6 +82,21 @@ enum eint_type {
 	EINT_TYPE_WKUP_MUX,
 };
 
+/**
+ * enum fltcon_type - filter selection
+ * @FLT_DEFAULT: filter not selectable, default digital filter
+ * @FLT_SELECT: filter selectable (digital or delay)
+ *
+ * Some banks on some SoCs (gs101 and possibly others) have a selectable
+ * filter on alive banks of 'delay/analog' or 'digital'. If the filter
+ * selection is not available then the default filter is used (digital).
+ */
+
+enum fltcon_type {
+	FLT_DEFAULT,
+	FLT_SELECTABLE,
+};
+
 /* maximum length of a pin in pin descriptor (example: "gpa0-0") */
 #define PIN_NAME_LENGTH	10
 
@@ -122,6 +137,8 @@ struct samsung_pin_bank_type {
  * @eint_type: type of the external interrupt supported by the bank.
  * @eint_mask: bit mask of pins which support EINT function.
  * @eint_offset: SoC-specific EINT register or interrupt offset of bank.
+ * @fltcon_type: whether the filter (delay/digital) is selectable
+ * @fltcon_offset: SoC-specific EINT filter control register offset of bank.
  * @name: name to be prefixed for each pin in this pin bank.
  */
 struct samsung_pin_bank_data {
@@ -133,6 +150,8 @@ struct samsung_pin_bank_data {
 	enum eint_type	eint_type;
 	u32		eint_mask;
 	u32		eint_offset;
+	enum fltcon_type fltcon_type;
+	u32		fltcon_offset;
 	const char	*name;
 };
 
@@ -147,6 +166,8 @@ struct samsung_pin_bank_data {
  * @eint_type: type of the external interrupt supported by the bank.
  * @eint_mask: bit mask of pins which support EINT function.
  * @eint_offset: SoC-specific EINT register or interrupt offset of bank.
+ * @fltcon_type: whether the filter (delay/digital) is selectable
+ * @fltcon_offset: SoC-specific EINT filter control register offset of bank.
  * @name: name to be prefixed for each pin in this pin bank.
  * @pin_base: starting pin number of the bank.
  * @soc_priv: per-bank private data for SoC-specific code.
@@ -169,6 +190,8 @@ struct samsung_pin_bank {
 	enum eint_type	eint_type;
 	u32		eint_mask;
 	u32		eint_offset;
+	enum fltcon_type fltcon_type;
+	u32		fltcon_offset;
 	const char	*name;
 
 	u32		pin_base;
-- 
2.42.0.609.gbb76f46606-goog


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH v2 14/20] pinctrl: samsung: Add gs101 SoC pinctrl configuration

[Peter Griffin]

Add support for the pin-controller found on the gs101 SoC used in
Pixel 6 phones.

Signed-off-by: Peter Griffin <peter.griffin@linaro.org>
---
 .../pinctrl/samsung/pinctrl-exynos-arm64.c    | 163 ++++++++++++++++++
 drivers/pinctrl/samsung/pinctrl-exynos.c      |   2 +
 drivers/pinctrl/samsung/pinctrl-exynos.h      |  34 ++++
 drivers/pinctrl/samsung/pinctrl-samsung.c     |   2 +
 drivers/pinctrl/samsung/pinctrl-samsung.h     |   1 +
 5 files changed, 202 insertions(+)

diff --git a/drivers/pinctrl/samsung/pinctrl-exynos-arm64.c b/drivers/pinctrl/samsung/pinctrl-exynos-arm64.c
index cb965cf93705..db47001d1b35 100644
--- a/drivers/pinctrl/samsung/pinctrl-exynos-arm64.c
+++ b/drivers/pinctrl/samsung/pinctrl-exynos-arm64.c
@@ -796,3 +796,166 @@ const struct samsung_pinctrl_of_match_data fsd_of_data __initconst = {
 	.ctrl		= fsd_pin_ctrl,
 	.num_ctrl	= ARRAY_SIZE(fsd_pin_ctrl),
 };
+
+/*
+ * bank type for non-alive type
+ * (CON bit field: 4, DAT bit field: 1, PUD bit field: 4, DRV bit field: 4)
+ * (CONPDN bit field: 2, PUDPDN bit field: 4)
+ */
+static struct samsung_pin_bank_type gs101_bank_type_off  = {
+	.fld_width = { 4, 1, 4, 4, 2, 4, },
+	.reg_offset = { 0x00, 0x04, 0x08, 0x0c, 0x10, 0x14, },
+};
+
+/*
+ * bank type for alive type
+ * (CON bit field: 4, DAT bit field: 1, PUD bit field: 4, DRV bit field: 4)
+ */
+static const struct samsung_pin_bank_type gs101_bank_type_alive = {
+	.fld_width = { 4, 1, 4, 4, },
+	.reg_offset = { 0x00, 0x04, 0x08, 0x0c, },
+};
+
+/* pin banks of gs101 pin-controller (ALIVE) */
+static const struct samsung_pin_bank_data gs101_pin_alive[] = {
+	EXYNOS9_PIN_BANK_EINTW(gs101_bank_type_alive, 8, 0x0, "gpa0", 0x00, 0x00, FLT_SELECTABLE),
+	EXYNOS9_PIN_BANK_EINTW(gs101_bank_type_alive, 7, 0x20, "gpa1", 0x04, 0x08, FLT_SELECTABLE),
+	EXYNOS9_PIN_BANK_EINTW(gs101_bank_type_alive, 5, 0x40, "gpa2", 0x08, 0x10, FLT_SELECTABLE),
+	EXYNOS9_PIN_BANK_EINTW(gs101_bank_type_alive, 4, 0x60, "gpa3", 0x0c, 0x18, FLT_SELECTABLE),
+	EXYNOS9_PIN_BANK_EINTW(gs101_bank_type_alive, 4, 0x80, "gpa4", 0x10, 0x1c, FLT_SELECTABLE),
+	EXYNOS9_PIN_BANK_EINTW(gs101_bank_type_alive, 7, 0xa0, "gpa5", 0x14, 0x20, FLT_SELECTABLE),
+	EXYNOS9_PIN_BANK_EINTW(gs101_bank_type_alive, 8, 0xc0, "gpa9", 0x18, 0x28, FLT_SELECTABLE),
+	EXYNOS9_PIN_BANK_EINTW(gs101_bank_type_alive, 2, 0xe0, "gpa10", 0x1c, 0x30, FLT_SELECTABLE),
+};
+
+/* pin banks of gs101 pin-controller (FAR_ALIVE) */
+static const struct samsung_pin_bank_data gs101_pin_far_alive[] = {
+	EXYNOS9_PIN_BANK_EINTW(gs101_bank_type_alive, 8, 0x0, "gpa6", 0x00, 0x00, FLT_SELECTABLE),
+	EXYNOS9_PIN_BANK_EINTW(gs101_bank_type_alive, 4, 0x20, "gpa7", 0x04, 0x08, FLT_SELECTABLE),
+	EXYNOS9_PIN_BANK_EINTW(gs101_bank_type_alive, 8, 0x40, "gpa8", 0x08, 0x0c, FLT_SELECTABLE),
+	EXYNOS9_PIN_BANK_EINTW(gs101_bank_type_alive, 2, 0x60, "gpa11", 0x0c, 0x14, FLT_SELECTABLE),
+};
+
+/* pin banks of gs101 pin-controller (GSACORE) */
+static const struct samsung_pin_bank_data gs101_pin_gsacore[] = {
+	EXYNOS9_PIN_BANK_EINTG(gs101_bank_type_off, 2, 0x0, "gps0", 0x00, 0x00, FLT_DEFAULT),
+	EXYNOS9_PIN_BANK_EINTG(gs101_bank_type_off, 8, 0x20, "gps1", 0x04, 0x04, FLT_DEFAULT),
+	EXYNOS9_PIN_BANK_EINTG(gs101_bank_type_off, 3, 0x40, "gps2", 0x08, 0x0c, FLT_DEFAULT),
+};
+
+/* pin banks of gs101 pin-controller (GSACTRL) */
+static const struct samsung_pin_bank_data gs101_pin_gsactrl[] = {
+	EXYNOS9_PIN_BANK_EINTW(gs101_bank_type_alive, 6, 0x0, "gps3", 0x00, 0x00, FLT_DEFAULT),
+};
+
+/* pin banks of gs101 pin-controller (PERIC0) */
+static const struct samsung_pin_bank_data gs101_pin_peric0[] = {
+	EXYNOS9_PIN_BANK_EINTG(gs101_bank_type_off, 5, 0x0, "gpp0", 0x00, 0x00, FLT_DEFAULT),
+	EXYNOS9_PIN_BANK_EINTG(gs101_bank_type_off, 4, 0x20, "gpp1", 0x04, 0x08, FLT_DEFAULT),
+	EXYNOS9_PIN_BANK_EINTG(gs101_bank_type_off, 4, 0x40, "gpp2", 0x08, 0x0c, FLT_DEFAULT),
+	EXYNOS9_PIN_BANK_EINTG(gs101_bank_type_off, 2, 0x60, "gpp3", 0x0c, 0x10, FLT_DEFAULT),
+	EXYNOS9_PIN_BANK_EINTG(gs101_bank_type_off, 4, 0x80, "gpp4", 0x10, 0x14, FLT_DEFAULT),
+	EXYNOS9_PIN_BANK_EINTG(gs101_bank_type_off, 2, 0xa0, "gpp5", 0x14, 0x18, FLT_DEFAULT),
+	EXYNOS9_PIN_BANK_EINTG(gs101_bank_type_off, 4, 0xc0, "gpp6", 0x18, 0x1c, FLT_DEFAULT),
+	EXYNOS9_PIN_BANK_EINTG(gs101_bank_type_off, 2, 0xe0, "gpp7", 0x1c, 0x20, FLT_DEFAULT),
+	EXYNOS9_PIN_BANK_EINTG(gs101_bank_type_off, 4, 0x100, "gpp8", 0x20, 0x24, FLT_DEFAULT),
+	EXYNOS9_PIN_BANK_EINTG(gs101_bank_type_off, 2, 0x120, "gpp9", 0x24, 0x28, FLT_DEFAULT),
+	EXYNOS9_PIN_BANK_EINTG(gs101_bank_type_off, 4, 0x140, "gpp10", 0x28, 0x2c, FLT_DEFAULT),
+	EXYNOS9_PIN_BANK_EINTG(gs101_bank_type_off, 2, 0x160, "gpp11", 0x2c, 0x30, FLT_DEFAULT),
+	EXYNOS9_PIN_BANK_EINTG(gs101_bank_type_off, 4, 0x180, "gpp12", 0x30, 0x34, FLT_DEFAULT),
+	EXYNOS9_PIN_BANK_EINTG(gs101_bank_type_off, 2, 0x1a0, "gpp13", 0x34, 0x38, FLT_DEFAULT),
+	EXYNOS9_PIN_BANK_EINTG(gs101_bank_type_off, 4, 0x1c0, "gpp14", 0x38, 0x3c, FLT_DEFAULT),
+	EXYNOS9_PIN_BANK_EINTG(gs101_bank_type_off, 2, 0x1e0, "gpp15", 0x3c, 0x40, FLT_DEFAULT),
+	EXYNOS9_PIN_BANK_EINTG(gs101_bank_type_off, 4, 0x200, "gpp16", 0x40, 0x44, FLT_DEFAULT),
+	EXYNOS9_PIN_BANK_EINTG(gs101_bank_type_off, 2, 0x220, "gpp17", 0x44, 0x48, FLT_DEFAULT),
+	EXYNOS9_PIN_BANK_EINTG(gs101_bank_type_off, 4, 0x240, "gpp18", 0x48, 0x4c, FLT_DEFAULT),
+	EXYNOS9_PIN_BANK_EINTG(gs101_bank_type_off, 4, 0x260, "gpp19", 0x4c, 0x50, FLT_DEFAULT),
+};
+
+/* pin banks of gs101 pin-controller (PERIC1) */
+static const struct samsung_pin_bank_data gs101_pin_peric1[] = {
+	EXYNOS9_PIN_BANK_EINTG(gs101_bank_type_off, 8, 0x0, "gpp20", 0x00, 0x00, FLT_DEFAULT),
+	EXYNOS9_PIN_BANK_EINTG(gs101_bank_type_off, 4, 0x20, "gpp21", 0x04, 0x08, FLT_DEFAULT),
+	EXYNOS9_PIN_BANK_EINTG(gs101_bank_type_off, 2, 0x40, "gpp22", 0x08, 0x0c, FLT_DEFAULT),
+	EXYNOS9_PIN_BANK_EINTG(gs101_bank_type_off, 8, 0x60, "gpp23", 0x0c, 0x10, FLT_DEFAULT),
+	EXYNOS9_PIN_BANK_EINTG(gs101_bank_type_off, 4, 0x80, "gpp24", 0x10, 0x18, FLT_DEFAULT),
+	EXYNOS9_PIN_BANK_EINTG(gs101_bank_type_off, 4, 0xa0, "gpp25", 0x14, 0x1c, FLT_DEFAULT),
+	EXYNOS9_PIN_BANK_EINTG(gs101_bank_type_off, 5, 0xc0, "gpp26", 0x18, 0x20, FLT_DEFAULT),
+	EXYNOS9_PIN_BANK_EINTG(gs101_bank_type_off, 4, 0xe0, "gpp27", 0x1c, 0x28, FLT_DEFAULT),
+};
+
+/* pin banks of gs101 pin-controller (HSI1) */
+static const struct samsung_pin_bank_data gs101_pin_hsi1[] = {
+	EXYNOS9_PIN_BANK_EINTG(gs101_bank_type_off, 6, 0x0, "gph0", 0x00, 0x00, FLT_DEFAULT),
+	EXYNOS9_PIN_BANK_EINTG(gs101_bank_type_off, 7, 0x20, "gph1", 0x04, 0x08, FLT_DEFAULT),
+};
+
+/* pin banks of gs101 pin-controller (HSI2) */
+static const struct samsung_pin_bank_data gs101_pin_hsi2[] = {
+	EXYNOS9_PIN_BANK_EINTG(gs101_bank_type_off, 6, 0x0, "gph2", 0x00, 0x00, FLT_DEFAULT),
+	EXYNOS9_PIN_BANK_EINTG(gs101_bank_type_off, 2, 0x20, "gph3", 0x04, 0x08, FLT_DEFAULT),
+	EXYNOS9_PIN_BANK_EINTG(gs101_bank_type_off, 6, 0x40, "gph4", 0x08, 0x0c, FLT_DEFAULT),
+};
+
+static const struct samsung_pin_ctrl gs101_pin_ctrl[] __initconst = {
+	{
+		/* pin banks of gs101 pin-controller (ALIVE) */
+		.pin_banks	= gs101_pin_alive,
+		.nr_banks	= ARRAY_SIZE(gs101_pin_alive),
+		.eint_gpio_init = exynos_eint_gpio_init,
+		.eint_wkup_init = exynos_eint_wkup_init,
+		.suspend	= exynos_pinctrl_suspend,
+		.resume		= exynos_pinctrl_resume,
+	}, {
+		/* pin banks of gs101 pin-controller (FAR_ALIVE) */
+		.pin_banks	= gs101_pin_far_alive,
+		.nr_banks	= ARRAY_SIZE(gs101_pin_far_alive),
+		.eint_gpio_init = exynos_eint_gpio_init,
+		.eint_wkup_init = exynos_eint_wkup_init,
+		.suspend	= exynos_pinctrl_suspend,
+		.resume		= exynos_pinctrl_resume,
+	}, {
+		/* pin banks of gs101 pin-controller (GSACORE) */
+		.pin_banks	= gs101_pin_gsacore,
+		.nr_banks	= ARRAY_SIZE(gs101_pin_gsacore),
+		.eint_gpio_init = exynos_eint_gpio_init,
+	}, {
+		/* pin banks of gs101 pin-controller (GSACTRL) */
+		.pin_banks	= gs101_pin_gsactrl,
+		.nr_banks	= ARRAY_SIZE(gs101_pin_gsactrl),
+		.eint_gpio_init = exynos_eint_gpio_init,
+	}, {
+		/* pin banks of gs101 pin-controller (PERIC0) */
+		.pin_banks	= gs101_pin_peric0,
+		.nr_banks	= ARRAY_SIZE(gs101_pin_peric0),
+		.eint_gpio_init = exynos_eint_gpio_init,
+		.suspend	= exynos_pinctrl_suspend,
+		.resume		= exynos_pinctrl_resume,
+	}, {
+		/* pin banks of gs101 pin-controller (PERIC1) */
+		.pin_banks	= gs101_pin_peric1,
+		.nr_banks	= ARRAY_SIZE(gs101_pin_peric1),
+		.eint_gpio_init = exynos_eint_gpio_init,
+		.suspend	= exynos_pinctrl_suspend,
+		.resume	= exynos_pinctrl_resume,
+	}, {
+		/* pin banks of gs101 pin-controller (HSI1) */
+		.pin_banks	= gs101_pin_hsi1,
+		.nr_banks	= ARRAY_SIZE(gs101_pin_hsi1),
+		.eint_gpio_init = exynos_eint_gpio_init,
+		.suspend	= exynos_pinctrl_suspend,
+		.resume		= exynos_pinctrl_resume,
+	}, {
+		/* pin banks of gs101 pin-controller (HSI2) */
+		.pin_banks	= gs101_pin_hsi2,
+		.nr_banks	= ARRAY_SIZE(gs101_pin_hsi2),
+		.eint_gpio_init = exynos_eint_gpio_init,
+		.suspend	= exynos_pinctrl_suspend,
+		.resume		= exynos_pinctrl_resume,
+	},
+};
+
+const struct samsung_pinctrl_of_match_data gs101_of_data __initconst = {
+	.ctrl		= gs101_pin_ctrl,
+	.num_ctrl	= ARRAY_SIZE(gs101_pin_ctrl),
+};
diff --git a/drivers/pinctrl/samsung/pinctrl-exynos.c b/drivers/pinctrl/samsung/pinctrl-exynos.c
index 800831aa8357..014f0c37f97f 100644
--- a/drivers/pinctrl/samsung/pinctrl-exynos.c
+++ b/drivers/pinctrl/samsung/pinctrl-exynos.c
@@ -533,6 +533,8 @@ static const struct of_device_id exynos_wkup_irq_ids[] = {
 			.data = &exynos7_wkup_irq_chip },
 	{ .compatible = "samsung,exynosautov9-wakeup-eint",
 			.data = &exynos7_wkup_irq_chip },
+	{ .compatible = "google,gs101-wakeup-eint",
+			.data = &exynos7_wkup_irq_chip },
 	{ }
 };
 
diff --git a/drivers/pinctrl/samsung/pinctrl-exynos.h b/drivers/pinctrl/samsung/pinctrl-exynos.h
index 63b2426ad5d6..0dd013654bd2 100644
--- a/drivers/pinctrl/samsung/pinctrl-exynos.h
+++ b/drivers/pinctrl/samsung/pinctrl-exynos.h
@@ -147,6 +147,40 @@
 		.name		= id				\
 	}
 
+#define EXYNOS9_PIN_BANK_EINTN(types, pins, reg, id)	\
+	{						\
+		.type		= &types,		\
+		.pctl_offset	= reg,			\
+		.nr_pins	= pins,			\
+		.eint_type	= EINT_TYPE_NONE,	\
+		.fltcon_type	= FLT_DEFAULT		\
+		.name		= id			\
+	}
+
+#define EXYNOS9_PIN_BANK_EINTG(types, pins, reg, id, offs, fltcon_offs, fltcontype) \
+	{						\
+		.type		= &types,		\
+		.pctl_offset	= reg,			\
+		.nr_pins	= pins,			\
+		.eint_type	= EINT_TYPE_GPIO,	\
+		.eint_offset	= offs,			\
+		.fltcon_type    = fltcontype,		\
+		.fltcon_offset	= fltcon_offs,		\
+		.name		= id			\
+	}
+
+#define EXYNOS9_PIN_BANK_EINTW(types, pins, reg, id, offs, fltcon_offs, fltcontype) \
+	{						\
+		.type		= &types,		\
+		.pctl_offset	= reg,			\
+		.nr_pins	= pins,			\
+		.eint_type	= EINT_TYPE_WKUP,	\
+		.eint_offset	= offs,			\
+		.fltcon_type    = fltcontype,		\
+		.fltcon_offset	= fltcon_offs,		\
+		.name		= id			\
+	}
+
 /**
  * struct exynos_weint_data: irq specific data for all the wakeup interrupts
  * generated by the external wakeup interrupt controller.
diff --git a/drivers/pinctrl/samsung/pinctrl-samsung.c b/drivers/pinctrl/samsung/pinctrl-samsung.c
index 449f8109d8b5..12176f98440d 100644
--- a/drivers/pinctrl/samsung/pinctrl-samsung.c
+++ b/drivers/pinctrl/samsung/pinctrl-samsung.c
@@ -1321,6 +1321,8 @@ static const struct of_device_id samsung_pinctrl_dt_match[] = {
 		.data = &exynosautov9_of_data },
 	{ .compatible = "tesla,fsd-pinctrl",
 		.data = &fsd_of_data },
+	{ .compatible = "google,gs101-pinctrl",
+		.data = &gs101_of_data },
 #endif
 #ifdef CONFIG_PINCTRL_S3C64XX
 	{ .compatible = "samsung,s3c64xx-pinctrl",
diff --git a/drivers/pinctrl/samsung/pinctrl-samsung.h b/drivers/pinctrl/samsung/pinctrl-samsung.h
index de2ca8e8b378..e62e909fb10d 100644
--- a/drivers/pinctrl/samsung/pinctrl-samsung.h
+++ b/drivers/pinctrl/samsung/pinctrl-samsung.h
@@ -374,6 +374,7 @@ extern const struct samsung_pinctrl_of_match_data exynos7885_of_data;
 extern const struct samsung_pinctrl_of_match_data exynos850_of_data;
 extern const struct samsung_pinctrl_of_match_data exynosautov9_of_data;
 extern const struct samsung_pinctrl_of_match_data fsd_of_data;
+extern const struct samsung_pinctrl_of_match_data gs101_of_data;
 extern const struct samsung_pinctrl_of_match_data s3c64xx_of_data;
 extern const struct samsung_pinctrl_of_match_data s3c2412_of_data;
 extern const struct samsung_pinctrl_of_match_data s3c2416_of_data;
-- 
2.42.0.609.gbb76f46606-goog

[PATCH v2 14/20] pinctrl: samsung: Add gs101 SoC pinctrl configuration

[Peter Griffin]

Add support for the pin-controller found on the gs101 SoC used in
Pixel 6 phones.

Signed-off-by: Peter Griffin <peter.griffin@linaro.org>
---
 .../pinctrl/samsung/pinctrl-exynos-arm64.c    | 163 ++++++++++++++++++
 drivers/pinctrl/samsung/pinctrl-exynos.c      |   2 +
 drivers/pinctrl/samsung/pinctrl-exynos.h      |  34 ++++
 drivers/pinctrl/samsung/pinctrl-samsung.c     |   2 +
 drivers/pinctrl/samsung/pinctrl-samsung.h     |   1 +
 5 files changed, 202 insertions(+)

diff --git a/drivers/pinctrl/samsung/pinctrl-exynos-arm64.c b/drivers/pinctrl/samsung/pinctrl-exynos-arm64.c
index cb965cf93705..db47001d1b35 100644
--- a/drivers/pinctrl/samsung/pinctrl-exynos-arm64.c
+++ b/drivers/pinctrl/samsung/pinctrl-exynos-arm64.c
@@ -796,3 +796,166 @@ const struct samsung_pinctrl_of_match_data fsd_of_data __initconst = {
 	.ctrl		= fsd_pin_ctrl,
 	.num_ctrl	= ARRAY_SIZE(fsd_pin_ctrl),
 };
+
+/*
+ * bank type for non-alive type
+ * (CON bit field: 4, DAT bit field: 1, PUD bit field: 4, DRV bit field: 4)
+ * (CONPDN bit field: 2, PUDPDN bit field: 4)
+ */
+static struct samsung_pin_bank_type gs101_bank_type_off  = {
+	.fld_width = { 4, 1, 4, 4, 2, 4, },
+	.reg_offset = { 0x00, 0x04, 0x08, 0x0c, 0x10, 0x14, },
+};
+
+/*
+ * bank type for alive type
+ * (CON bit field: 4, DAT bit field: 1, PUD bit field: 4, DRV bit field: 4)
+ */
+static const struct samsung_pin_bank_type gs101_bank_type_alive = {
+	.fld_width = { 4, 1, 4, 4, },
+	.reg_offset = { 0x00, 0x04, 0x08, 0x0c, },
+};
+
+/* pin banks of gs101 pin-controller (ALIVE) */
+static const struct samsung_pin_bank_data gs101_pin_alive[] = {
+	EXYNOS9_PIN_BANK_EINTW(gs101_bank_type_alive, 8, 0x0, "gpa0", 0x00, 0x00, FLT_SELECTABLE),
+	EXYNOS9_PIN_BANK_EINTW(gs101_bank_type_alive, 7, 0x20, "gpa1", 0x04, 0x08, FLT_SELECTABLE),
+	EXYNOS9_PIN_BANK_EINTW(gs101_bank_type_alive, 5, 0x40, "gpa2", 0x08, 0x10, FLT_SELECTABLE),
+	EXYNOS9_PIN_BANK_EINTW(gs101_bank_type_alive, 4, 0x60, "gpa3", 0x0c, 0x18, FLT_SELECTABLE),
+	EXYNOS9_PIN_BANK_EINTW(gs101_bank_type_alive, 4, 0x80, "gpa4", 0x10, 0x1c, FLT_SELECTABLE),
+	EXYNOS9_PIN_BANK_EINTW(gs101_bank_type_alive, 7, 0xa0, "gpa5", 0x14, 0x20, FLT_SELECTABLE),
+	EXYNOS9_PIN_BANK_EINTW(gs101_bank_type_alive, 8, 0xc0, "gpa9", 0x18, 0x28, FLT_SELECTABLE),
+	EXYNOS9_PIN_BANK_EINTW(gs101_bank_type_alive, 2, 0xe0, "gpa10", 0x1c, 0x30, FLT_SELECTABLE),
+};
+
+/* pin banks of gs101 pin-controller (FAR_ALIVE) */
+static const struct samsung_pin_bank_data gs101_pin_far_alive[] = {
+	EXYNOS9_PIN_BANK_EINTW(gs101_bank_type_alive, 8, 0x0, "gpa6", 0x00, 0x00, FLT_SELECTABLE),
+	EXYNOS9_PIN_BANK_EINTW(gs101_bank_type_alive, 4, 0x20, "gpa7", 0x04, 0x08, FLT_SELECTABLE),
+	EXYNOS9_PIN_BANK_EINTW(gs101_bank_type_alive, 8, 0x40, "gpa8", 0x08, 0x0c, FLT_SELECTABLE),
+	EXYNOS9_PIN_BANK_EINTW(gs101_bank_type_alive, 2, 0x60, "gpa11", 0x0c, 0x14, FLT_SELECTABLE),
+};
+
+/* pin banks of gs101 pin-controller (GSACORE) */
+static const struct samsung_pin_bank_data gs101_pin_gsacore[] = {
+	EXYNOS9_PIN_BANK_EINTG(gs101_bank_type_off, 2, 0x0, "gps0", 0x00, 0x00, FLT_DEFAULT),
+	EXYNOS9_PIN_BANK_EINTG(gs101_bank_type_off, 8, 0x20, "gps1", 0x04, 0x04, FLT_DEFAULT),
+	EXYNOS9_PIN_BANK_EINTG(gs101_bank_type_off, 3, 0x40, "gps2", 0x08, 0x0c, FLT_DEFAULT),
+};
+
+/* pin banks of gs101 pin-controller (GSACTRL) */
+static const struct samsung_pin_bank_data gs101_pin_gsactrl[] = {
+	EXYNOS9_PIN_BANK_EINTW(gs101_bank_type_alive, 6, 0x0, "gps3", 0x00, 0x00, FLT_DEFAULT),
+};
+
+/* pin banks of gs101 pin-controller (PERIC0) */
+static const struct samsung_pin_bank_data gs101_pin_peric0[] = {
+	EXYNOS9_PIN_BANK_EINTG(gs101_bank_type_off, 5, 0x0, "gpp0", 0x00, 0x00, FLT_DEFAULT),
+	EXYNOS9_PIN_BANK_EINTG(gs101_bank_type_off, 4, 0x20, "gpp1", 0x04, 0x08, FLT_DEFAULT),
+	EXYNOS9_PIN_BANK_EINTG(gs101_bank_type_off, 4, 0x40, "gpp2", 0x08, 0x0c, FLT_DEFAULT),
+	EXYNOS9_PIN_BANK_EINTG(gs101_bank_type_off, 2, 0x60, "gpp3", 0x0c, 0x10, FLT_DEFAULT),
+	EXYNOS9_PIN_BANK_EINTG(gs101_bank_type_off, 4, 0x80, "gpp4", 0x10, 0x14, FLT_DEFAULT),
+	EXYNOS9_PIN_BANK_EINTG(gs101_bank_type_off, 2, 0xa0, "gpp5", 0x14, 0x18, FLT_DEFAULT),
+	EXYNOS9_PIN_BANK_EINTG(gs101_bank_type_off, 4, 0xc0, "gpp6", 0x18, 0x1c, FLT_DEFAULT),
+	EXYNOS9_PIN_BANK_EINTG(gs101_bank_type_off, 2, 0xe0, "gpp7", 0x1c, 0x20, FLT_DEFAULT),
+	EXYNOS9_PIN_BANK_EINTG(gs101_bank_type_off, 4, 0x100, "gpp8", 0x20, 0x24, FLT_DEFAULT),
+	EXYNOS9_PIN_BANK_EINTG(gs101_bank_type_off, 2, 0x120, "gpp9", 0x24, 0x28, FLT_DEFAULT),
+	EXYNOS9_PIN_BANK_EINTG(gs101_bank_type_off, 4, 0x140, "gpp10", 0x28, 0x2c, FLT_DEFAULT),
+	EXYNOS9_PIN_BANK_EINTG(gs101_bank_type_off, 2, 0x160, "gpp11", 0x2c, 0x30, FLT_DEFAULT),
+	EXYNOS9_PIN_BANK_EINTG(gs101_bank_type_off, 4, 0x180, "gpp12", 0x30, 0x34, FLT_DEFAULT),
+	EXYNOS9_PIN_BANK_EINTG(gs101_bank_type_off, 2, 0x1a0, "gpp13", 0x34, 0x38, FLT_DEFAULT),
+	EXYNOS9_PIN_BANK_EINTG(gs101_bank_type_off, 4, 0x1c0, "gpp14", 0x38, 0x3c, FLT_DEFAULT),
+	EXYNOS9_PIN_BANK_EINTG(gs101_bank_type_off, 2, 0x1e0, "gpp15", 0x3c, 0x40, FLT_DEFAULT),
+	EXYNOS9_PIN_BANK_EINTG(gs101_bank_type_off, 4, 0x200, "gpp16", 0x40, 0x44, FLT_DEFAULT),
+	EXYNOS9_PIN_BANK_EINTG(gs101_bank_type_off, 2, 0x220, "gpp17", 0x44, 0x48, FLT_DEFAULT),
+	EXYNOS9_PIN_BANK_EINTG(gs101_bank_type_off, 4, 0x240, "gpp18", 0x48, 0x4c, FLT_DEFAULT),
+	EXYNOS9_PIN_BANK_EINTG(gs101_bank_type_off, 4, 0x260, "gpp19", 0x4c, 0x50, FLT_DEFAULT),
+};
+
+/* pin banks of gs101 pin-controller (PERIC1) */
+static const struct samsung_pin_bank_data gs101_pin_peric1[] = {
+	EXYNOS9_PIN_BANK_EINTG(gs101_bank_type_off, 8, 0x0, "gpp20", 0x00, 0x00, FLT_DEFAULT),
+	EXYNOS9_PIN_BANK_EINTG(gs101_bank_type_off, 4, 0x20, "gpp21", 0x04, 0x08, FLT_DEFAULT),
+	EXYNOS9_PIN_BANK_EINTG(gs101_bank_type_off, 2, 0x40, "gpp22", 0x08, 0x0c, FLT_DEFAULT),
+	EXYNOS9_PIN_BANK_EINTG(gs101_bank_type_off, 8, 0x60, "gpp23", 0x0c, 0x10, FLT_DEFAULT),
+	EXYNOS9_PIN_BANK_EINTG(gs101_bank_type_off, 4, 0x80, "gpp24", 0x10, 0x18, FLT_DEFAULT),
+	EXYNOS9_PIN_BANK_EINTG(gs101_bank_type_off, 4, 0xa0, "gpp25", 0x14, 0x1c, FLT_DEFAULT),
+	EXYNOS9_PIN_BANK_EINTG(gs101_bank_type_off, 5, 0xc0, "gpp26", 0x18, 0x20, FLT_DEFAULT),
+	EXYNOS9_PIN_BANK_EINTG(gs101_bank_type_off, 4, 0xe0, "gpp27", 0x1c, 0x28, FLT_DEFAULT),
+};
+
+/* pin banks of gs101 pin-controller (HSI1) */
+static const struct samsung_pin_bank_data gs101_pin_hsi1[] = {
+	EXYNOS9_PIN_BANK_EINTG(gs101_bank_type_off, 6, 0x0, "gph0", 0x00, 0x00, FLT_DEFAULT),
+	EXYNOS9_PIN_BANK_EINTG(gs101_bank_type_off, 7, 0x20, "gph1", 0x04, 0x08, FLT_DEFAULT),
+};
+
+/* pin banks of gs101 pin-controller (HSI2) */
+static const struct samsung_pin_bank_data gs101_pin_hsi2[] = {
+	EXYNOS9_PIN_BANK_EINTG(gs101_bank_type_off, 6, 0x0, "gph2", 0x00, 0x00, FLT_DEFAULT),
+	EXYNOS9_PIN_BANK_EINTG(gs101_bank_type_off, 2, 0x20, "gph3", 0x04, 0x08, FLT_DEFAULT),
+	EXYNOS9_PIN_BANK_EINTG(gs101_bank_type_off, 6, 0x40, "gph4", 0x08, 0x0c, FLT_DEFAULT),
+};
+
+static const struct samsung_pin_ctrl gs101_pin_ctrl[] __initconst = {
+	{
+		/* pin banks of gs101 pin-controller (ALIVE) */
+		.pin_banks	= gs101_pin_alive,
+		.nr_banks	= ARRAY_SIZE(gs101_pin_alive),
+		.eint_gpio_init = exynos_eint_gpio_init,
+		.eint_wkup_init = exynos_eint_wkup_init,
+		.suspend	= exynos_pinctrl_suspend,
+		.resume		= exynos_pinctrl_resume,
+	}, {
+		/* pin banks of gs101 pin-controller (FAR_ALIVE) */
+		.pin_banks	= gs101_pin_far_alive,
+		.nr_banks	= ARRAY_SIZE(gs101_pin_far_alive),
+		.eint_gpio_init = exynos_eint_gpio_init,
+		.eint_wkup_init = exynos_eint_wkup_init,
+		.suspend	= exynos_pinctrl_suspend,
+		.resume		= exynos_pinctrl_resume,
+	}, {
+		/* pin banks of gs101 pin-controller (GSACORE) */
+		.pin_banks	= gs101_pin_gsacore,
+		.nr_banks	= ARRAY_SIZE(gs101_pin_gsacore),
+		.eint_gpio_init = exynos_eint_gpio_init,
+	}, {
+		/* pin banks of gs101 pin-controller (GSACTRL) */
+		.pin_banks	= gs101_pin_gsactrl,
+		.nr_banks	= ARRAY_SIZE(gs101_pin_gsactrl),
+		.eint_gpio_init = exynos_eint_gpio_init,
+	}, {
+		/* pin banks of gs101 pin-controller (PERIC0) */
+		.pin_banks	= gs101_pin_peric0,
+		.nr_banks	= ARRAY_SIZE(gs101_pin_peric0),
+		.eint_gpio_init = exynos_eint_gpio_init,
+		.suspend	= exynos_pinctrl_suspend,
+		.resume		= exynos_pinctrl_resume,
+	}, {
+		/* pin banks of gs101 pin-controller (PERIC1) */
+		.pin_banks	= gs101_pin_peric1,
+		.nr_banks	= ARRAY_SIZE(gs101_pin_peric1),
+		.eint_gpio_init = exynos_eint_gpio_init,
+		.suspend	= exynos_pinctrl_suspend,
+		.resume	= exynos_pinctrl_resume,
+	}, {
+		/* pin banks of gs101 pin-controller (HSI1) */
+		.pin_banks	= gs101_pin_hsi1,
+		.nr_banks	= ARRAY_SIZE(gs101_pin_hsi1),
+		.eint_gpio_init = exynos_eint_gpio_init,
+		.suspend	= exynos_pinctrl_suspend,
+		.resume		= exynos_pinctrl_resume,
+	}, {
+		/* pin banks of gs101 pin-controller (HSI2) */
+		.pin_banks	= gs101_pin_hsi2,
+		.nr_banks	= ARRAY_SIZE(gs101_pin_hsi2),
+		.eint_gpio_init = exynos_eint_gpio_init,
+		.suspend	= exynos_pinctrl_suspend,
+		.resume		= exynos_pinctrl_resume,
+	},
+};
+
+const struct samsung_pinctrl_of_match_data gs101_of_data __initconst = {
+	.ctrl		= gs101_pin_ctrl,
+	.num_ctrl	= ARRAY_SIZE(gs101_pin_ctrl),
+};
diff --git a/drivers/pinctrl/samsung/pinctrl-exynos.c b/drivers/pinctrl/samsung/pinctrl-exynos.c
index 800831aa8357..014f0c37f97f 100644
--- a/drivers/pinctrl/samsung/pinctrl-exynos.c
+++ b/drivers/pinctrl/samsung/pinctrl-exynos.c
@@ -533,6 +533,8 @@ static const struct of_device_id exynos_wkup_irq_ids[] = {
 			.data = &exynos7_wkup_irq_chip },
 	{ .compatible = "samsung,exynosautov9-wakeup-eint",
 			.data = &exynos7_wkup_irq_chip },
+	{ .compatible = "google,gs101-wakeup-eint",
+			.data = &exynos7_wkup_irq_chip },
 	{ }
 };
 
diff --git a/drivers/pinctrl/samsung/pinctrl-exynos.h b/drivers/pinctrl/samsung/pinctrl-exynos.h
index 63b2426ad5d6..0dd013654bd2 100644
--- a/drivers/pinctrl/samsung/pinctrl-exynos.h
+++ b/drivers/pinctrl/samsung/pinctrl-exynos.h
@@ -147,6 +147,40 @@
 		.name		= id				\
 	}
 
+#define EXYNOS9_PIN_BANK_EINTN(types, pins, reg, id)	\
+	{						\
+		.type		= &types,		\
+		.pctl_offset	= reg,			\
+		.nr_pins	= pins,			\
+		.eint_type	= EINT_TYPE_NONE,	\
+		.fltcon_type	= FLT_DEFAULT		\
+		.name		= id			\
+	}
+
+#define EXYNOS9_PIN_BANK_EINTG(types, pins, reg, id, offs, fltcon_offs, fltcontype) \
+	{						\
+		.type		= &types,		\
+		.pctl_offset	= reg,			\
+		.nr_pins	= pins,			\
+		.eint_type	= EINT_TYPE_GPIO,	\
+		.eint_offset	= offs,			\
+		.fltcon_type    = fltcontype,		\
+		.fltcon_offset	= fltcon_offs,		\
+		.name		= id			\
+	}
+
+#define EXYNOS9_PIN_BANK_EINTW(types, pins, reg, id, offs, fltcon_offs, fltcontype) \
+	{						\
+		.type		= &types,		\
+		.pctl_offset	= reg,			\
+		.nr_pins	= pins,			\
+		.eint_type	= EINT_TYPE_WKUP,	\
+		.eint_offset	= offs,			\
+		.fltcon_type    = fltcontype,		\
+		.fltcon_offset	= fltcon_offs,		\
+		.name		= id			\
+	}
+
 /**
  * struct exynos_weint_data: irq specific data for all the wakeup interrupts
  * generated by the external wakeup interrupt controller.
diff --git a/drivers/pinctrl/samsung/pinctrl-samsung.c b/drivers/pinctrl/samsung/pinctrl-samsung.c
index 449f8109d8b5..12176f98440d 100644
--- a/drivers/pinctrl/samsung/pinctrl-samsung.c
+++ b/drivers/pinctrl/samsung/pinctrl-samsung.c
@@ -1321,6 +1321,8 @@ static const struct of_device_id samsung_pinctrl_dt_match[] = {
 		.data = &exynosautov9_of_data },
 	{ .compatible = "tesla,fsd-pinctrl",
 		.data = &fsd_of_data },
+	{ .compatible = "google,gs101-pinctrl",
+		.data = &gs101_of_data },
 #endif
 #ifdef CONFIG_PINCTRL_S3C64XX
 	{ .compatible = "samsung,s3c64xx-pinctrl",
diff --git a/drivers/pinctrl/samsung/pinctrl-samsung.h b/drivers/pinctrl/samsung/pinctrl-samsung.h
index de2ca8e8b378..e62e909fb10d 100644
--- a/drivers/pinctrl/samsung/pinctrl-samsung.h
+++ b/drivers/pinctrl/samsung/pinctrl-samsung.h
@@ -374,6 +374,7 @@ extern const struct samsung_pinctrl_of_match_data exynos7885_of_data;
 extern const struct samsung_pinctrl_of_match_data exynos850_of_data;
 extern const struct samsung_pinctrl_of_match_data exynosautov9_of_data;
 extern const struct samsung_pinctrl_of_match_data fsd_of_data;
+extern const struct samsung_pinctrl_of_match_data gs101_of_data;
 extern const struct samsung_pinctrl_of_match_data s3c64xx_of_data;
 extern const struct samsung_pinctrl_of_match_data s3c2412_of_data;
 extern const struct samsung_pinctrl_of_match_data s3c2416_of_data;
-- 
2.42.0.609.gbb76f46606-goog


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH v2 15/20] watchdog: s3c2410_wdt: Add support for Google tensor SoCs

[Peter Griffin]

This patch adds the compatibles and drvdata for the Google
gs101 & gs201 SoCs found in Pixel 6 and Pixel 7 phones. Similar
to Exynos850 it has two watchdog instances, one for each cluster
and has some control bits in PMU registers.

The watchdog IP found in gs101 SoCs also supports a few
additional bits/features in the WTCON register which we add
support for and an additional register detailed below.

dbgack-mask - Enables masking WDT interrupt and reset request
according to asserted DBGACK input

windowed-mode - Enabled Windowed watchdog mode

Windowed watchdog mode also has an additional register WTMINCNT.
If windowed watchdog is enabled and you reload WTCNT when the
value is greater than WTMINCNT, it prompts interrupt or reset
request as if the watchdog time has expired.

Signed-off-by: Peter Griffin <peter.griffin@linaro.org>
---
 drivers/watchdog/s3c2410_wdt.c | 104 ++++++++++++++++++++++++++++++---
 1 file changed, 95 insertions(+), 9 deletions(-)

diff --git a/drivers/watchdog/s3c2410_wdt.c b/drivers/watchdog/s3c2410_wdt.c
index 0b4bd883ff28..08a775c01c57 100644
--- a/drivers/watchdog/s3c2410_wdt.c
+++ b/drivers/watchdog/s3c2410_wdt.c
@@ -31,12 +31,14 @@
 #define S3C2410_WTDAT		0x04
 #define S3C2410_WTCNT		0x08
 #define S3C2410_WTCLRINT	0x0c
-
+#define S3C2410_WTMINCNT	0x10
 #define S3C2410_WTCNT_MAXCNT	0xffff
 
-#define S3C2410_WTCON_RSTEN	(1 << 0)
-#define S3C2410_WTCON_INTEN	(1 << 2)
-#define S3C2410_WTCON_ENABLE	(1 << 5)
+#define S3C2410_WTCON_RSTEN		(1 << 0)
+#define S3C2410_WTCON_INTEN		(1 << 2)
+#define S3C2410_WTCON_ENABLE		(1 << 5)
+#define S3C2410_WTCON_DBGACK_MASK	(1 << 16)
+#define S3C2410_WTCON_WINDOWED_WD	(1 << 20)
 
 #define S3C2410_WTCON_DIV16	(0 << 3)
 #define S3C2410_WTCON_DIV32	(1 << 3)
@@ -67,6 +69,12 @@
 #define EXYNOSAUTOV9_CLUSTER0_WDTRESET_BIT	25
 #define EXYNOSAUTOV9_CLUSTER1_WDTRESET_BIT	24
 
+#define GS_CLUSTER0_NONCPU_OUT			0x1220
+#define GS_CLUSTER1_NONCPU_OUT			0x1420
+#define GS_CLUSTER0_NONCPU_INT_EN		0x1244
+#define GS_CLUSTER1_NONCPU_INT_EN		0x1444
+#define GS_CLUSTER2_NONCPU_INT_EN		0x1644
+#define GS_RST_STAT_REG_OFFSET			0x3B44
 /**
  * DOC: Quirk flags for different Samsung watchdog IP-cores
  *
@@ -106,6 +114,8 @@
 #define QUIRK_HAS_PMU_RST_STAT			(1 << 2)
 #define QUIRK_HAS_PMU_AUTO_DISABLE		(1 << 3)
 #define QUIRK_HAS_PMU_CNT_EN			(1 << 4)
+#define QUIRK_HAS_DBGACK_BIT			(1 << 5)
+#define QUIRK_HAS_WTMINCNT_REG			(1 << 6)
 
 /* These quirks require that we have a PMU register map */
 #define QUIRKS_HAVE_PMUREG \
@@ -263,6 +273,54 @@ static const struct s3c2410_wdt_variant drv_data_exynosautov9_cl1 = {
 		  QUIRK_HAS_PMU_RST_STAT | QUIRK_HAS_PMU_CNT_EN,
 };
 
+static const struct s3c2410_wdt_variant drv_data_gs101_cl0 = {
+	.mask_reset_reg = GS_CLUSTER0_NONCPU_INT_EN,
+	.mask_bit = 2,
+	.mask_reset_inv = true,
+	.rst_stat_reg = GS_RST_STAT_REG_OFFSET,
+	.rst_stat_bit = 0,
+	.cnt_en_reg = GS_CLUSTER0_NONCPU_OUT,
+	.cnt_en_bit = 8,
+	.quirks = QUIRK_HAS_PMU_RST_STAT | QUIRK_HAS_PMU_MASK_RESET | QUIRK_HAS_PMU_CNT_EN |
+		  QUIRK_HAS_WTCLRINT_REG | QUIRK_HAS_DBGACK_BIT | QUIRK_HAS_WTMINCNT_REG,
+};
+
+static const struct s3c2410_wdt_variant drv_data_gs101_cl1 = {
+	.mask_reset_reg = GS_CLUSTER1_NONCPU_INT_EN,
+	.mask_bit = 2,
+	.mask_reset_inv = true,
+	.rst_stat_reg = GS_RST_STAT_REG_OFFSET,
+	.rst_stat_bit = 1,
+	.cnt_en_reg = GS_CLUSTER1_NONCPU_OUT,
+	.cnt_en_bit = 7,
+	.quirks = QUIRK_HAS_PMU_RST_STAT | QUIRK_HAS_PMU_MASK_RESET | QUIRK_HAS_PMU_CNT_EN |
+		  QUIRK_HAS_WTCLRINT_REG | QUIRK_HAS_DBGACK_BIT | QUIRK_HAS_WTMINCNT_REG,
+};
+
+static const struct s3c2410_wdt_variant drv_data_gs201_cl0 = {
+	.mask_reset_reg = GS_CLUSTER0_NONCPU_INT_EN,
+	.mask_bit = 2,
+	.mask_reset_inv = true,
+	.rst_stat_reg = GS_RST_STAT_REG_OFFSET,
+	.rst_stat_bit = 0,
+	.cnt_en_reg = GS_CLUSTER0_NONCPU_OUT,
+	.cnt_en_bit = 8,
+	.quirks = QUIRK_HAS_PMU_RST_STAT | QUIRK_HAS_PMU_MASK_RESET | QUIRK_HAS_PMU_CNT_EN |
+		  QUIRK_HAS_WTCLRINT_REG | QUIRK_HAS_DBGACK_BIT | QUIRK_HAS_WTMINCNT_REG,
+};
+
+static const struct s3c2410_wdt_variant drv_data_gs201_cl1 = {
+	.mask_reset_reg = GS_CLUSTER1_NONCPU_INT_EN,
+	.mask_bit = 2,
+	.mask_reset_inv = true,
+	.rst_stat_reg = GS_RST_STAT_REG_OFFSET,
+	.rst_stat_bit = 1,
+	.cnt_en_reg = GS_CLUSTER1_NONCPU_OUT,
+	.cnt_en_bit = 7,
+	.quirks = QUIRK_HAS_PMU_RST_STAT | QUIRK_HAS_PMU_MASK_RESET | QUIRK_HAS_PMU_CNT_EN |
+		  QUIRK_HAS_WTCLRINT_REG | QUIRK_HAS_DBGACK_BIT | QUIRK_HAS_WTMINCNT_REG,
+};
+
 static const struct of_device_id s3c2410_wdt_match[] = {
 	{ .compatible = "samsung,s3c2410-wdt",
 	  .data = &drv_data_s3c2410 },
@@ -278,6 +336,10 @@ static const struct of_device_id s3c2410_wdt_match[] = {
 	  .data = &drv_data_exynos850_cl0 },
 	{ .compatible = "samsung,exynosautov9-wdt",
 	  .data = &drv_data_exynosautov9_cl0 },
+	{ .compatible = "google,gs101-wdt",
+	  .data = &drv_data_gs101_cl0 },
+	{ .compatible = "google,gs201-wdt",
+	  .data = &drv_data_gs201_cl0 },
 	{},
 };
 MODULE_DEVICE_TABLE(of, s3c2410_wdt_match);
@@ -375,6 +437,21 @@ static int s3c2410wdt_enable(struct s3c2410_wdt *wdt, bool en)
 	return 0;
 }
 
+static void s3c2410wdt_mask_dbgack(struct s3c2410_wdt *wdt, bool mask)
+{
+	unsigned long wtcon;
+
+	if (!(wdt->drv_data->quirks & QUIRK_HAS_DBGACK_BIT))
+		return;
+
+	wtcon = readl(wdt->reg_base + S3C2410_WTCON);
+	if (mask)
+		wtcon |= S3C2410_WTCON_DBGACK_MASK;
+	else
+		wtcon &= ~S3C2410_WTCON_DBGACK_MASK;
+	writel(wtcon, wdt->reg_base + S3C2410_WTCON);
+}
+
 static int s3c2410wdt_keepalive(struct watchdog_device *wdd)
 {
 	struct s3c2410_wdt *wdt = watchdog_get_drvdata(wdd);
@@ -585,9 +662,11 @@ s3c2410_get_wdt_drv_data(struct platform_device *pdev, struct s3c2410_wdt *wdt)
 	}
 
 #ifdef CONFIG_OF
-	/* Choose Exynos850/ExynosAutov9 driver data w.r.t. cluster index */
+	/* Choose Exynos850/ExynosAutov9/gsx01 driver data w.r.t. cluster index */
 	if (variant == &drv_data_exynos850_cl0 ||
-	    variant == &drv_data_exynosautov9_cl0) {
+	    variant == &drv_data_exynosautov9_cl0 ||
+	    variant == &drv_data_gs101_cl0 ||
+	    variant == &drv_data_gs201_cl0) {
 		u32 index;
 		int err;
 
@@ -600,9 +679,14 @@ s3c2410_get_wdt_drv_data(struct platform_device *pdev, struct s3c2410_wdt *wdt)
 		case 0:
 			break;
 		case 1:
-			variant = (variant == &drv_data_exynos850_cl0) ?
-				&drv_data_exynos850_cl1 :
-				&drv_data_exynosautov9_cl1;
+			if (variant == &drv_data_exynos850_cl0)
+				variant = &drv_data_exynos850_cl1;
+			else if (variant == &drv_data_exynosautov9_cl0)
+				variant = &drv_data_exynosautov9_cl1;
+			else if (variant == &drv_data_gs101_cl0)
+				variant = &drv_data_gs101_cl1;
+			else if (variant == &drv_data_gs201_cl0)
+				variant = &drv_data_gs201_cl1;
 			break;
 		default:
 			return dev_err_probe(dev, -EINVAL, "wrong cluster index: %u\n", index);
@@ -700,6 +784,8 @@ static int s3c2410wdt_probe(struct platform_device *pdev)
 	wdt->wdt_device.bootstatus = s3c2410wdt_get_bootstatus(wdt);
 	wdt->wdt_device.parent = dev;
 
+	s3c2410wdt_mask_dbgack(wdt, true);
+
 	/*
 	 * If "tmr_atboot" param is non-zero, start the watchdog right now. Also
 	 * set WDOG_HW_RUNNING bit, so that watchdog core can kick the watchdog.
-- 
2.42.0.609.gbb76f46606-goog

[PATCH v2 15/20] watchdog: s3c2410_wdt: Add support for Google tensor SoCs

[Peter Griffin]

This patch adds the compatibles and drvdata for the Google
gs101 & gs201 SoCs found in Pixel 6 and Pixel 7 phones. Similar
to Exynos850 it has two watchdog instances, one for each cluster
and has some control bits in PMU registers.

The watchdog IP found in gs101 SoCs also supports a few
additional bits/features in the WTCON register which we add
support for and an additional register detailed below.

dbgack-mask - Enables masking WDT interrupt and reset request
according to asserted DBGACK input

windowed-mode - Enabled Windowed watchdog mode

Windowed watchdog mode also has an additional register WTMINCNT.
If windowed watchdog is enabled and you reload WTCNT when the
value is greater than WTMINCNT, it prompts interrupt or reset
request as if the watchdog time has expired.

Signed-off-by: Peter Griffin <peter.griffin@linaro.org>
---
 drivers/watchdog/s3c2410_wdt.c | 104 ++++++++++++++++++++++++++++++---
 1 file changed, 95 insertions(+), 9 deletions(-)

diff --git a/drivers/watchdog/s3c2410_wdt.c b/drivers/watchdog/s3c2410_wdt.c
index 0b4bd883ff28..08a775c01c57 100644
--- a/drivers/watchdog/s3c2410_wdt.c
+++ b/drivers/watchdog/s3c2410_wdt.c
@@ -31,12 +31,14 @@
 #define S3C2410_WTDAT		0x04
 #define S3C2410_WTCNT		0x08
 #define S3C2410_WTCLRINT	0x0c
-
+#define S3C2410_WTMINCNT	0x10
 #define S3C2410_WTCNT_MAXCNT	0xffff
 
-#define S3C2410_WTCON_RSTEN	(1 << 0)
-#define S3C2410_WTCON_INTEN	(1 << 2)
-#define S3C2410_WTCON_ENABLE	(1 << 5)
+#define S3C2410_WTCON_RSTEN		(1 << 0)
+#define S3C2410_WTCON_INTEN		(1 << 2)
+#define S3C2410_WTCON_ENABLE		(1 << 5)
+#define S3C2410_WTCON_DBGACK_MASK	(1 << 16)
+#define S3C2410_WTCON_WINDOWED_WD	(1 << 20)
 
 #define S3C2410_WTCON_DIV16	(0 << 3)
 #define S3C2410_WTCON_DIV32	(1 << 3)
@@ -67,6 +69,12 @@
 #define EXYNOSAUTOV9_CLUSTER0_WDTRESET_BIT	25
 #define EXYNOSAUTOV9_CLUSTER1_WDTRESET_BIT	24
 
+#define GS_CLUSTER0_NONCPU_OUT			0x1220
+#define GS_CLUSTER1_NONCPU_OUT			0x1420
+#define GS_CLUSTER0_NONCPU_INT_EN		0x1244
+#define GS_CLUSTER1_NONCPU_INT_EN		0x1444
+#define GS_CLUSTER2_NONCPU_INT_EN		0x1644
+#define GS_RST_STAT_REG_OFFSET			0x3B44
 /**
  * DOC: Quirk flags for different Samsung watchdog IP-cores
  *
@@ -106,6 +114,8 @@
 #define QUIRK_HAS_PMU_RST_STAT			(1 << 2)
 #define QUIRK_HAS_PMU_AUTO_DISABLE		(1 << 3)
 #define QUIRK_HAS_PMU_CNT_EN			(1 << 4)
+#define QUIRK_HAS_DBGACK_BIT			(1 << 5)
+#define QUIRK_HAS_WTMINCNT_REG			(1 << 6)
 
 /* These quirks require that we have a PMU register map */
 #define QUIRKS_HAVE_PMUREG \
@@ -263,6 +273,54 @@ static const struct s3c2410_wdt_variant drv_data_exynosautov9_cl1 = {
 		  QUIRK_HAS_PMU_RST_STAT | QUIRK_HAS_PMU_CNT_EN,
 };
 
+static const struct s3c2410_wdt_variant drv_data_gs101_cl0 = {
+	.mask_reset_reg = GS_CLUSTER0_NONCPU_INT_EN,
+	.mask_bit = 2,
+	.mask_reset_inv = true,
+	.rst_stat_reg = GS_RST_STAT_REG_OFFSET,
+	.rst_stat_bit = 0,
+	.cnt_en_reg = GS_CLUSTER0_NONCPU_OUT,
+	.cnt_en_bit = 8,
+	.quirks = QUIRK_HAS_PMU_RST_STAT | QUIRK_HAS_PMU_MASK_RESET | QUIRK_HAS_PMU_CNT_EN |
+		  QUIRK_HAS_WTCLRINT_REG | QUIRK_HAS_DBGACK_BIT | QUIRK_HAS_WTMINCNT_REG,
+};
+
+static const struct s3c2410_wdt_variant drv_data_gs101_cl1 = {
+	.mask_reset_reg = GS_CLUSTER1_NONCPU_INT_EN,
+	.mask_bit = 2,
+	.mask_reset_inv = true,
+	.rst_stat_reg = GS_RST_STAT_REG_OFFSET,
+	.rst_stat_bit = 1,
+	.cnt_en_reg = GS_CLUSTER1_NONCPU_OUT,
+	.cnt_en_bit = 7,
+	.quirks = QUIRK_HAS_PMU_RST_STAT | QUIRK_HAS_PMU_MASK_RESET | QUIRK_HAS_PMU_CNT_EN |
+		  QUIRK_HAS_WTCLRINT_REG | QUIRK_HAS_DBGACK_BIT | QUIRK_HAS_WTMINCNT_REG,
+};
+
+static const struct s3c2410_wdt_variant drv_data_gs201_cl0 = {
+	.mask_reset_reg = GS_CLUSTER0_NONCPU_INT_EN,
+	.mask_bit = 2,
+	.mask_reset_inv = true,
+	.rst_stat_reg = GS_RST_STAT_REG_OFFSET,
+	.rst_stat_bit = 0,
+	.cnt_en_reg = GS_CLUSTER0_NONCPU_OUT,
+	.cnt_en_bit = 8,
+	.quirks = QUIRK_HAS_PMU_RST_STAT | QUIRK_HAS_PMU_MASK_RESET | QUIRK_HAS_PMU_CNT_EN |
+		  QUIRK_HAS_WTCLRINT_REG | QUIRK_HAS_DBGACK_BIT | QUIRK_HAS_WTMINCNT_REG,
+};
+
+static const struct s3c2410_wdt_variant drv_data_gs201_cl1 = {
+	.mask_reset_reg = GS_CLUSTER1_NONCPU_INT_EN,
+	.mask_bit = 2,
+	.mask_reset_inv = true,
+	.rst_stat_reg = GS_RST_STAT_REG_OFFSET,
+	.rst_stat_bit = 1,
+	.cnt_en_reg = GS_CLUSTER1_NONCPU_OUT,
+	.cnt_en_bit = 7,
+	.quirks = QUIRK_HAS_PMU_RST_STAT | QUIRK_HAS_PMU_MASK_RESET | QUIRK_HAS_PMU_CNT_EN |
+		  QUIRK_HAS_WTCLRINT_REG | QUIRK_HAS_DBGACK_BIT | QUIRK_HAS_WTMINCNT_REG,
+};
+
 static const struct of_device_id s3c2410_wdt_match[] = {
 	{ .compatible = "samsung,s3c2410-wdt",
 	  .data = &drv_data_s3c2410 },
@@ -278,6 +336,10 @@ static const struct of_device_id s3c2410_wdt_match[] = {
 	  .data = &drv_data_exynos850_cl0 },
 	{ .compatible = "samsung,exynosautov9-wdt",
 	  .data = &drv_data_exynosautov9_cl0 },
+	{ .compatible = "google,gs101-wdt",
+	  .data = &drv_data_gs101_cl0 },
+	{ .compatible = "google,gs201-wdt",
+	  .data = &drv_data_gs201_cl0 },
 	{},
 };
 MODULE_DEVICE_TABLE(of, s3c2410_wdt_match);
@@ -375,6 +437,21 @@ static int s3c2410wdt_enable(struct s3c2410_wdt *wdt, bool en)
 	return 0;
 }
 
+static void s3c2410wdt_mask_dbgack(struct s3c2410_wdt *wdt, bool mask)
+{
+	unsigned long wtcon;
+
+	if (!(wdt->drv_data->quirks & QUIRK_HAS_DBGACK_BIT))
+		return;
+
+	wtcon = readl(wdt->reg_base + S3C2410_WTCON);
+	if (mask)
+		wtcon |= S3C2410_WTCON_DBGACK_MASK;
+	else
+		wtcon &= ~S3C2410_WTCON_DBGACK_MASK;
+	writel(wtcon, wdt->reg_base + S3C2410_WTCON);
+}
+
 static int s3c2410wdt_keepalive(struct watchdog_device *wdd)
 {
 	struct s3c2410_wdt *wdt = watchdog_get_drvdata(wdd);
@@ -585,9 +662,11 @@ s3c2410_get_wdt_drv_data(struct platform_device *pdev, struct s3c2410_wdt *wdt)
 	}
 
 #ifdef CONFIG_OF
-	/* Choose Exynos850/ExynosAutov9 driver data w.r.t. cluster index */
+	/* Choose Exynos850/ExynosAutov9/gsx01 driver data w.r.t. cluster index */
 	if (variant == &drv_data_exynos850_cl0 ||
-	    variant == &drv_data_exynosautov9_cl0) {
+	    variant == &drv_data_exynosautov9_cl0 ||
+	    variant == &drv_data_gs101_cl0 ||
+	    variant == &drv_data_gs201_cl0) {
 		u32 index;
 		int err;
 
@@ -600,9 +679,14 @@ s3c2410_get_wdt_drv_data(struct platform_device *pdev, struct s3c2410_wdt *wdt)
 		case 0:
 			break;
 		case 1:
-			variant = (variant == &drv_data_exynos850_cl0) ?
-				&drv_data_exynos850_cl1 :
-				&drv_data_exynosautov9_cl1;
+			if (variant == &drv_data_exynos850_cl0)
+				variant = &drv_data_exynos850_cl1;
+			else if (variant == &drv_data_exynosautov9_cl0)
+				variant = &drv_data_exynosautov9_cl1;
+			else if (variant == &drv_data_gs101_cl0)
+				variant = &drv_data_gs101_cl1;
+			else if (variant == &drv_data_gs201_cl0)
+				variant = &drv_data_gs201_cl1;
 			break;
 		default:
 			return dev_err_probe(dev, -EINVAL, "wrong cluster index: %u\n", index);
@@ -700,6 +784,8 @@ static int s3c2410wdt_probe(struct platform_device *pdev)
 	wdt->wdt_device.bootstatus = s3c2410wdt_get_bootstatus(wdt);
 	wdt->wdt_device.parent = dev;
 
+	s3c2410wdt_mask_dbgack(wdt, true);
+
 	/*
 	 * If "tmr_atboot" param is non-zero, start the watchdog right now. Also
 	 * set WDOG_HW_RUNNING bit, so that watchdog core can kick the watchdog.
-- 
2.42.0.609.gbb76f46606-goog


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH v2 16/20] tty: serial: samsung: Add gs101 compatible and SoC data

[Peter Griffin]

Add serial driver data for Google Tensor gs101 SoC.

Signed-off-by: Peter Griffin <peter.griffin@linaro.org>
---
 drivers/tty/serial/samsung_tty.c | 12 ++++++++++++
 1 file changed, 12 insertions(+)

diff --git a/drivers/tty/serial/samsung_tty.c b/drivers/tty/serial/samsung_tty.c
index 07fb8a9dac63..79a1a184d5c1 100644
--- a/drivers/tty/serial/samsung_tty.c
+++ b/drivers/tty/serial/samsung_tty.c
@@ -2597,14 +2597,21 @@ static const struct s3c24xx_serial_drv_data exynos850_serial_drv_data = {
 	.fifosize = { 256, 64, 64, 64 },
 };
 
+static const struct s3c24xx_serial_drv_data gs101_serial_drv_data = {
+	EXYNOS_COMMON_SERIAL_DRV_DATA(),
+	.fifosize = { 256, 64, 64, 64 },
+};
+
 #define EXYNOS4210_SERIAL_DRV_DATA (&exynos4210_serial_drv_data)
 #define EXYNOS5433_SERIAL_DRV_DATA (&exynos5433_serial_drv_data)
 #define EXYNOS850_SERIAL_DRV_DATA (&exynos850_serial_drv_data)
+#define GS101_SERIAL_DRV_DATA (&gs101_serial_drv_data)
 
 #else
 #define EXYNOS4210_SERIAL_DRV_DATA NULL
 #define EXYNOS5433_SERIAL_DRV_DATA NULL
 #define EXYNOS850_SERIAL_DRV_DATA NULL
+#define GS101_SERIAL_DRV_DATA NULL
 #endif
 
 #ifdef CONFIG_ARCH_APPLE
@@ -2688,6 +2695,9 @@ static const struct platform_device_id s3c24xx_serial_driver_ids[] = {
 	}, {
 		.name		= "artpec8-uart",
 		.driver_data	= (kernel_ulong_t)ARTPEC8_SERIAL_DRV_DATA,
+	}, {
+		.name		= "gs101-uart",
+		.driver_data	= (kernel_ulong_t)GS101_SERIAL_DRV_DATA,
 	},
 	{ },
 };
@@ -2709,6 +2719,8 @@ static const struct of_device_id s3c24xx_uart_dt_match[] = {
 		.data = EXYNOS850_SERIAL_DRV_DATA },
 	{ .compatible = "axis,artpec8-uart",
 		.data = ARTPEC8_SERIAL_DRV_DATA },
+	{ .compatible = "google,gs101-uart",
+		.data =  GS101_SERIAL_DRV_DATA },
 	{},
 };
 MODULE_DEVICE_TABLE(of, s3c24xx_uart_dt_match);
-- 
2.42.0.609.gbb76f46606-goog

[PATCH v2 16/20] tty: serial: samsung: Add gs101 compatible and SoC data

[Peter Griffin]

Add serial driver data for Google Tensor gs101 SoC.

Signed-off-by: Peter Griffin <peter.griffin@linaro.org>
---
 drivers/tty/serial/samsung_tty.c | 12 ++++++++++++
 1 file changed, 12 insertions(+)

diff --git a/drivers/tty/serial/samsung_tty.c b/drivers/tty/serial/samsung_tty.c
index 07fb8a9dac63..79a1a184d5c1 100644
--- a/drivers/tty/serial/samsung_tty.c
+++ b/drivers/tty/serial/samsung_tty.c
@@ -2597,14 +2597,21 @@ static const struct s3c24xx_serial_drv_data exynos850_serial_drv_data = {
 	.fifosize = { 256, 64, 64, 64 },
 };
 
+static const struct s3c24xx_serial_drv_data gs101_serial_drv_data = {
+	EXYNOS_COMMON_SERIAL_DRV_DATA(),
+	.fifosize = { 256, 64, 64, 64 },
+};
+
 #define EXYNOS4210_SERIAL_DRV_DATA (&exynos4210_serial_drv_data)
 #define EXYNOS5433_SERIAL_DRV_DATA (&exynos5433_serial_drv_data)
 #define EXYNOS850_SERIAL_DRV_DATA (&exynos850_serial_drv_data)
+#define GS101_SERIAL_DRV_DATA (&gs101_serial_drv_data)
 
 #else
 #define EXYNOS4210_SERIAL_DRV_DATA NULL
 #define EXYNOS5433_SERIAL_DRV_DATA NULL
 #define EXYNOS850_SERIAL_DRV_DATA NULL
+#define GS101_SERIAL_DRV_DATA NULL
 #endif
 
 #ifdef CONFIG_ARCH_APPLE
@@ -2688,6 +2695,9 @@ static const struct platform_device_id s3c24xx_serial_driver_ids[] = {
 	}, {
 		.name		= "artpec8-uart",
 		.driver_data	= (kernel_ulong_t)ARTPEC8_SERIAL_DRV_DATA,
+	}, {
+		.name		= "gs101-uart",
+		.driver_data	= (kernel_ulong_t)GS101_SERIAL_DRV_DATA,
 	},
 	{ },
 };
@@ -2709,6 +2719,8 @@ static const struct of_device_id s3c24xx_uart_dt_match[] = {
 		.data = EXYNOS850_SERIAL_DRV_DATA },
 	{ .compatible = "axis,artpec8-uart",
 		.data = ARTPEC8_SERIAL_DRV_DATA },
+	{ .compatible = "google,gs101-uart",
+		.data =  GS101_SERIAL_DRV_DATA },
 	{},
 };
 MODULE_DEVICE_TABLE(of, s3c24xx_uart_dt_match);
-- 
2.42.0.609.gbb76f46606-goog


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH v2 17/20] arm64: dts: google: Add initial Google gs101 SoC support

[Peter Griffin]

Google gs101 SoC is ARMv8 mobile SoC found in the Pixel 6,
(oriole) Pixel 6a (bluejay) and Pixel 6 pro (raven) mobile
phones. It features:
* 4xA55 little cluster
* 2xA76 Mid cluster
* 2xX1 Big cluster

This commit adds the basic device tree for gs101 (SoC).
Further platform support will be added over time.

Signed-off-by: Peter Griffin <peter.griffin@linaro.org>
---
 arch/arm64/Kconfig.platforms                  |    6 +
 arch/arm64/boot/dts/Makefile                  |    1 +
 arch/arm64/boot/dts/google/gs101-pinctrl.dtsi | 1275 +++++++++++++++++
 arch/arm64/boot/dts/google/gs101-pinctrl.h    |   32 +
 arch/arm64/boot/dts/google/gs101.dtsi         |  503 +++++++
 5 files changed, 1817 insertions(+)
 create mode 100644 arch/arm64/boot/dts/google/gs101-pinctrl.dtsi
 create mode 100644 arch/arm64/boot/dts/google/gs101-pinctrl.h
 create mode 100644 arch/arm64/boot/dts/google/gs101.dtsi

diff --git a/arch/arm64/Kconfig.platforms b/arch/arm64/Kconfig.platforms
index 6069120199bb..a5ed1b719488 100644
--- a/arch/arm64/Kconfig.platforms
+++ b/arch/arm64/Kconfig.platforms
@@ -107,6 +107,12 @@ config ARCH_EXYNOS
 	help
 	  This enables support for ARMv8 based Samsung Exynos SoC family.
 
+config ARCH_GOOGLE_TENSOR
+	bool "Google Tensor SoC fmaily"
+	depends on ARCH_EXYNOS
+	help
+	  Support for ARMv8 based Google Tensor platforms.
+
 config ARCH_SPARX5
 	bool "Microchip Sparx5 SoC family"
 	select PINCTRL
diff --git a/arch/arm64/boot/dts/Makefile b/arch/arm64/boot/dts/Makefile
index 30dd6347a929..a4ee7b628114 100644
--- a/arch/arm64/boot/dts/Makefile
+++ b/arch/arm64/boot/dts/Makefile
@@ -13,6 +13,7 @@ subdir-y += broadcom
 subdir-y += cavium
 subdir-y += exynos
 subdir-y += freescale
+subdir-y += google
 subdir-y += hisilicon
 subdir-y += intel
 subdir-y += lg
diff --git a/arch/arm64/boot/dts/google/gs101-pinctrl.dtsi b/arch/arm64/boot/dts/google/gs101-pinctrl.dtsi
new file mode 100644
index 000000000000..ba88000c3ed8
--- /dev/null
+++ b/arch/arm64/boot/dts/google/gs101-pinctrl.dtsi
@@ -0,0 +1,1275 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * GS101 SoC pin-mux and pin-config device tree source
+ *
+ * Copyright 2019-2023 Google LLC
+ *
+ */
+
+#include "gs101-pinctrl.h"
+
+/* GPIO_ALIVE */
+&pinctrl_0 {
+	gpa0: gpa0-gpio-bank {
+		gpio-controller;
+		#gpio-cells = <2>;
+		interrupt-controller;
+		#interrupt-cells = <2>;
+		interrupt-parent = <&gic>;
+		interrupts = <GIC_SPI 0 IRQ_TYPE_LEVEL_HIGH>,
+			   <GIC_SPI 1 IRQ_TYPE_LEVEL_HIGH>,
+			   <GIC_SPI 2 IRQ_TYPE_LEVEL_HIGH>,
+			   <GIC_SPI 3 IRQ_TYPE_LEVEL_HIGH>,
+			   <GIC_SPI 4 IRQ_TYPE_LEVEL_HIGH>,
+			   <GIC_SPI 5 IRQ_TYPE_LEVEL_HIGH>,
+			   <GIC_SPI 6 IRQ_TYPE_LEVEL_HIGH>,
+			   <GIC_SPI 7 IRQ_TYPE_LEVEL_HIGH>;
+	};
+
+	gpa1: gpa1-gpio-bank {
+		gpio-controller;
+		#gpio-cells = <2>;
+		interrupt-controller;
+		#interrupt-cells = <2>;
+		interrupt-parent = <&gic>;
+		interrupts = <GIC_SPI 8 IRQ_TYPE_LEVEL_HIGH>,
+			   <GIC_SPI 9 IRQ_TYPE_LEVEL_HIGH>,
+			   <GIC_SPI 10 IRQ_TYPE_LEVEL_HIGH>,
+			   <GIC_SPI 11 IRQ_TYPE_LEVEL_HIGH>,
+			   <GIC_SPI 12 IRQ_TYPE_LEVEL_HIGH>,
+			   <GIC_SPI 13 IRQ_TYPE_LEVEL_HIGH>,
+			   <GIC_SPI 14 IRQ_TYPE_LEVEL_HIGH>;
+	};
+
+	gpa2: gpa2-gpio-bank {
+		gpio-controller;
+		#gpio-cells = <2>;
+		interrupt-controller;
+		#interrupt-cells = <2>;
+		interrupt-parent = <&gic>;
+		interrupts = <GIC_SPI 15 IRQ_TYPE_LEVEL_HIGH>,
+			   <GIC_SPI 16 IRQ_TYPE_LEVEL_HIGH>,
+			   <GIC_SPI 17 IRQ_TYPE_LEVEL_HIGH>,
+			   <GIC_SPI 18 IRQ_TYPE_LEVEL_HIGH>,
+			   <GIC_SPI 19 IRQ_TYPE_LEVEL_HIGH>;
+	};
+
+	gpa3: gpa3-gpio-bank {
+		gpio-controller;
+		#gpio-cells = <2>;
+		interrupt-controller;
+		#interrupt-cells = <2>;
+		interrupt-parent = <&gic>;
+		interrupts = <GIC_SPI 20 IRQ_TYPE_LEVEL_HIGH>,
+			   <GIC_SPI 21 IRQ_TYPE_LEVEL_HIGH>,
+			   <GIC_SPI 22 IRQ_TYPE_LEVEL_HIGH>,
+			   <GIC_SPI 23 IRQ_TYPE_LEVEL_HIGH>;
+	};
+
+	gpa4: gpa4-gpio-bank {
+		gpio-controller;
+		#gpio-cells = <2>;
+		interrupt-controller;
+		#interrupt-cells = <2>;
+		interrupt-parent = <&gic>;
+		interrupts = <GIC_SPI 24 IRQ_TYPE_LEVEL_HIGH>,
+			   <GIC_SPI 25 IRQ_TYPE_LEVEL_HIGH>,
+			   <GIC_SPI 26 IRQ_TYPE_LEVEL_HIGH>,
+			   <GIC_SPI 27 IRQ_TYPE_LEVEL_HIGH>;
+	};
+
+	gpa5: gpa5-gpio-bank  {
+		gpio-controller;
+		#gpio-cells = <2>;
+		interrupt-controller;
+		#interrupt-cells = <2>;
+		interrupts = <GIC_SPI 28 IRQ_TYPE_LEVEL_HIGH>,
+			   <GIC_SPI 29 IRQ_TYPE_LEVEL_HIGH>,
+			   <GIC_SPI 30 IRQ_TYPE_LEVEL_HIGH>,
+			   <GIC_SPI 31 IRQ_TYPE_LEVEL_HIGH>,
+			   <GIC_SPI 32 IRQ_TYPE_LEVEL_HIGH>,
+			   <GIC_SPI 33 IRQ_TYPE_LEVEL_HIGH>,
+			   <GIC_SPI 34 IRQ_TYPE_LEVEL_HIGH>;
+	};
+
+	gpa9: gpa9-gpio-bank  {
+		gpio-controller;
+		#gpio-cells = <2>;
+		interrupt-controller;
+		#interrupt-cells = <2>;
+		interrupts = <GIC_SPI 35 IRQ_TYPE_LEVEL_HIGH>,
+			   <GIC_SPI 36 IRQ_TYPE_LEVEL_HIGH>,
+			   <GIC_SPI 37 IRQ_TYPE_LEVEL_HIGH>,
+			   <GIC_SPI 38 IRQ_TYPE_LEVEL_HIGH>,
+			   <GIC_SPI 39 IRQ_TYPE_LEVEL_HIGH>,
+			   <GIC_SPI 40 IRQ_TYPE_LEVEL_HIGH>,
+			   <GIC_SPI 41 IRQ_TYPE_LEVEL_HIGH>,
+			   <GIC_SPI 42 IRQ_TYPE_LEVEL_HIGH>;
+	};
+
+	gpa10: gpa10-gpio-bank  {
+		gpio-controller;
+		#gpio-cells = <2>;
+		interrupt-controller;
+		#interrupt-cells = <2>;
+		interrupts = <GIC_SPI 43 IRQ_TYPE_LEVEL_HIGH>,
+			   <GIC_SPI 44 IRQ_TYPE_LEVEL_HIGH>;
+	};
+
+	uart15_bus: uart15-bus-pins {
+	       samsung,pins = "gpa2-3", "gpa2-4";
+	       samsung,pin-function = <2>;
+	       samsung,pin-pud = <0>;
+	};
+
+	uart16_bus: uart16-bus-pins {
+	       samsung,pins = "gpa3-0", "gpa3-1", "gpa3-2", "gpa3-3";
+	       samsung,pin-function = <GS101_PIN_FUNC_2>;
+	       samsung,pin-pud = <GS101_PIN_PULL_NONE>;
+	};
+
+	uart16_bus_rts: uart1-bus-rts-pins {
+		samsung,pins = "gpa3-2";
+		samsung,pin-function = <GS101_PIN_FUNC_OUTPUT>;
+		samsung,pin-pud = <GS101_PIN_PULL_NONE>;
+		samsung,pin-val = <1>;
+	};
+
+	uart16_bus_tx_dat: uart1-bus-tx-dat-pins {
+		samsung,pins = "gpa3-1";
+		samsung,pin-val = <1>;
+	};
+
+	uart16_bus_tx_con: uart1-bus-tx-con-pins {
+		samsung,pins = "gpa3-1";
+		samsung,pin-function = <1>;
+	};
+
+	uart17_bus: uart17-bus-pins {
+	       samsung,pins = "gpa4-0", "gpa4-1", "gpa4-2", "gpa4-3";
+	       samsung,pin-function = <2>;
+	       samsung,pin-pud = <0>;
+	};
+
+	spi15_bus: spi15-bus-pins {
+		samsung,pins = "gpa4-0", "gpa4-1", "gpa4-2";
+		samsung,pin-function = <GS101_PIN_FUNC_2>;
+		samsung,pin-pud = <GS101_PIN_PULL_NONE>;
+		samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
+	};
+
+	spi15_cs: spi15-cs-pins {
+		samsung,pins = "gpa4-3";
+		samsung,pin-function = <GS101_PIN_FUNC_OUTPUT>;
+		samsung,pin-pud = <GS101_PIN_PULL_NONE>;
+		samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
+	};
+};
+
+/* GPIO_FAR_ALIVE */
+&pinctrl_1 {
+	gpa6: gpa6-gpio-bank {
+		gpio-controller;
+		#gpio-cells = <2>;
+		interrupt-controller;
+		#interrupt-cells = <2>;
+		interrupt-parent = <&gic>;
+		interrupts = <GIC_SPI 45 IRQ_TYPE_LEVEL_HIGH>,
+			   <GIC_SPI 46 IRQ_TYPE_LEVEL_HIGH>,
+			   <GIC_SPI 47 IRQ_TYPE_LEVEL_HIGH>,
+			   <GIC_SPI 48 IRQ_TYPE_LEVEL_HIGH>,
+			   <GIC_SPI 49 IRQ_TYPE_LEVEL_HIGH>,
+			   <GIC_SPI 50 IRQ_TYPE_LEVEL_HIGH>,
+			   <GIC_SPI 51 IRQ_TYPE_LEVEL_HIGH>,
+			   <GIC_SPI 52 IRQ_TYPE_LEVEL_HIGH>;
+	};
+
+	gpa7: gpa7-gpio-bank {
+		gpio-controller;
+		#gpio-cells = <2>;
+		interrupt-controller;
+		#interrupt-cells = <2>;
+		interrupt-parent = <&gic>;
+		interrupts = <GIC_SPI 53 IRQ_TYPE_LEVEL_HIGH>,
+			   <GIC_SPI 54 IRQ_TYPE_LEVEL_HIGH>,
+			   <GIC_SPI 55 IRQ_TYPE_LEVEL_HIGH>,
+			   <GIC_SPI 56 IRQ_TYPE_LEVEL_HIGH>;
+	};
+
+	gpa8: gpa8-gpio-bank {
+		gpio-controller;
+		#gpio-cells = <2>;
+		interrupt-controller;
+		#interrupt-cells = <2>;
+		interrupt-parent = <&gic>;
+		interrupts = <GIC_SPI 57 IRQ_TYPE_LEVEL_HIGH>,
+			   <GIC_SPI 58 IRQ_TYPE_LEVEL_HIGH>,
+			   <GIC_SPI 59 IRQ_TYPE_LEVEL_HIGH>,
+			   <GIC_SPI 60 IRQ_TYPE_LEVEL_HIGH>,
+			   <GIC_SPI 61 IRQ_TYPE_LEVEL_HIGH>,
+			   <GIC_SPI 62 IRQ_TYPE_LEVEL_HIGH>,
+			   <GIC_SPI 63 IRQ_TYPE_LEVEL_HIGH>,
+			   <GIC_SPI 64 IRQ_TYPE_LEVEL_HIGH>;
+	};
+
+	gpa11: gpa11-gpio-bank {
+		gpio-controller;
+		#gpio-cells = <2>;
+		interrupt-controller;
+		#interrupt-cells = <2>;
+		interrupt-parent = <&gic>;
+		interrupts = <GIC_SPI 65 IRQ_TYPE_LEVEL_HIGH>,
+			   <GIC_SPI 66 IRQ_TYPE_LEVEL_HIGH>;
+	};
+};
+
+/* GPIO_GSACORE */
+&pinctrl_2 {
+	gps0: gps0-gpio-bank {
+		gpio-controller;
+		#gpio-cells = <2>;
+		interrupt-controller;
+		#interrupt-cells = <2>;
+	};
+
+	gps1: gps1-gpio-bank {
+		gpio-controller;
+		#gpio-cells = <2>;
+		interrupt-controller;
+		#interrupt-cells = <2>;
+	};
+
+	gps2: gps2-gpio-bank {
+		gpio-controller;
+		#gpio-cells = <2>;
+		interrupt-controller;
+		#interrupt-cells = <2>;
+	};
+};
+
+/* GPIO_GSACTRL */
+&pinctrl_3 {
+	gps3: gps3-gpio-bank {
+		gpio-controller;
+		#gpio-cells = <2>;
+		interrupt-controller;
+		#interrupt-cells = <2>;
+	};
+};
+
+/* GPIO_HSI1 */
+&pinctrl_6 {
+	gph0: gph0-gpio-bank {
+		gpio-controller;
+		#gpio-cells = <2>;
+		interrupt-controller;
+		#interrupt-cells = <2>;
+	};
+
+	gph1: gph1-gpio-bank {
+		gpio-controller;
+		#gpio-cells = <2>;
+		interrupt-controller;
+		#interrupt-cells = <2>;
+	};
+
+	pcie0_clkreq: pcie0-clkreq-pins{
+		samsung,pins = "gph0-1";
+		samsung,pin-function = <2>;
+		samsung,pin-pud = <3>;
+		samsung,pin-drv = <GS101_PIN_DRV_10_MA>;
+		samsung,pin-con-pdn = <3>;
+		samsung,pin-pud-pdn = <3>;
+	};
+
+	pcie0_perst: pcie0-perst-pins {
+		samsung,pins = "gph0-0";
+		samsung,pin-function = <1>;
+		samsung,pin-drv = <GS101_PIN_DRV_10_MA>;
+		samsung,pin-con-pdn = <3>;
+	};
+};
+
+/* GPIO_HSI2 */
+&pinctrl_7 {
+	gph2: gph2-gpio-bank {
+		gpio-controller;
+		#gpio-cells = <2>;
+		interrupt-controller;
+		#interrupt-cells = <2>;
+	};
+
+	gph3: gph3-gpio-bank {
+		gpio-controller;
+		#gpio-cells = <2>;
+		interrupt-controller;
+		#interrupt-cells = <2>;
+	};
+
+	gph4: gph4-gpio-bank {
+		gpio-controller;
+		#gpio-cells = <2>;
+		interrupt-controller;
+		#interrupt-cells = <2>;
+	};
+
+	sd2_clk: sd2-clk-pins {
+		samsung,pins = "gph4-0";
+		samsung,pin-function = <2>;
+		samsung,pin-pud = <0>;
+		samsung,pin-drv = <GS101_PIN_DRV_7_5_MA>;
+	};
+
+	sd2_cmd: sd2-cmd-pins {
+		samsung,pins = "gph4-1";
+		samsung,pin-function = <2>;
+		samsung,pin-pud = <3>;
+		samsung,pin-drv = <GS101_PIN_DRV_7_5_MA>;
+	};
+
+	sd2_bus1: sd2-bus-width1-pins {
+		samsung,pins = "gph4-2";
+		samsung,pin-function = <2>;
+		samsung,pin-pud = <3>;
+		samsung,pin-drv = <GS101_PIN_DRV_7_5_MA>;
+	};
+
+	sd2_bus4: sd2-bus-width4-pins {
+		samsung,pins = "gph4-3", "gph4-4", "gph4-5";
+		samsung,pin-function = <2>;
+		samsung,pin-pud = <3>;
+		samsung,pin-drv = <GS101_PIN_DRV_7_5_MA>;
+	};
+
+	sd2_clk_fast_slew_rate_1x: sd2-clk-fast-slew-rate-1x-pins {
+		samsung,pins = "gph4-0";
+		samsung,pin-function = <2>;
+		samsung,pin-pud = <0>;
+		samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
+	};
+
+	sd2_clk_fast_slew_rate_2x: sd2-clk-fast-slew-rate-2x-pins {
+		samsung,pins = "gph4-0";
+		samsung,pin-function = <2>;
+		samsung,pin-pud = <0>;
+		samsung,pin-drv = <GS101_PIN_DRV_5_MA>;
+	};
+
+	sd2_clk_fast_slew_rate_3x: sd2-clk-fast-slew-rate-3x-pins {
+		samsung,pins = "gph4-0";
+		samsung,pin-function = <2>;
+		samsung,pin-pud = <0>;
+		samsung,pin-drv = <GS101_PIN_DRV_7_5_MA>;
+	};
+
+	sd2_clk_fast_slew_rate_4x: sd2-clk-fast-slew-rate-4x-pins {
+		samsung,pins = "gph4-0";
+		samsung,pin-function = <2>;
+		samsung,pin-pud = <0>;
+		samsung,pin-drv = <GS101_PIN_DRV_10_MA>;
+	};
+
+	ufs_rst_n: ufs-rst-n-pins {
+		samsung,pins = "gph3-1";
+		samsung,pin-function = <2>;
+		samsung,pin-pud = <0>;
+		samsung,pin-con-pdn = <3>;
+		samsung,pin-pud-pdn = <0>;
+	};
+
+	ufs_refclk_out: ufs-refclk-out-pins {
+		samsung,pins = "gph3-0";
+		samsung,pin-function = <2>;
+		samsung,pin-pud = <0>;
+		samsung,pin-con-pdn = <3>;
+		samsung,pin-pud-pdn = <0>;
+	};
+
+	pcie1_clkreq: pcie1-clkreq-pins {
+		samsung,pins = "gph2-1";
+		samsung,pin-function = <2>;
+		samsung,pin-pud = <3>;
+		samsung,pin-drv = <GS101_PIN_DRV_10_MA>;
+		samsung,pin-con-pdn = <3>;
+		samsung,pin-pud-pdn = <3>;
+	};
+
+	pcie1_perst: pcie1-perst-pins {
+		samsung,pins = "gph2-0";
+		samsung,pin-function = <1>;
+		samsung,pin-drv = <GS101_PIN_DRV_10_MA>;
+		samsung,pin-con-pdn = <3>;
+	};
+};
+
+/* GPIO_PERIC0 */
+&pinctrl_4 {
+	gpp0: gpp0-gpio-bank {
+		gpio-controller;
+		#gpio-cells = <2>;
+		interrupt-controller;
+		#interrupt-cells = <2>;
+	};
+
+	gpp1: gpp1-gpio-bank {
+		gpio-controller;
+		#gpio-cells = <2>;
+		interrupt-controller;
+		#interrupt-cells = <2>;
+	};
+
+	gpp2: gpp2-gpio-bank {
+		gpio-controller;
+		#gpio-cells = <2>;
+		interrupt-controller;
+		#interrupt-cells = <2>;
+	};
+
+	gpp3: gpp3-gpio-bank {
+		gpio-controller;
+		#gpio-cells = <2>;
+		interrupt-controller;
+		#interrupt-cells = <2>;
+	};
+
+	gpp4: gpp4-gpio-bank {
+		gpio-controller;
+		#gpio-cells = <2>;
+		interrupt-controller;
+		#interrupt-cells = <2>;
+	};
+
+	gpp5: gpp5-gpio-bank {
+		gpio-controller;
+		#gpio-cells = <2>;
+		interrupt-controller;
+		#interrupt-cells = <2>;
+	};
+
+	gpp6: gpp6-gpio-bank {
+		gpio-controller;
+		#gpio-cells = <2>;
+		interrupt-controller;
+		#interrupt-cells = <2>;
+	};
+
+	gpp7: gpp7-gpio-bank {
+		gpio-controller;
+		#gpio-cells = <2>;
+		interrupt-controller;
+		#interrupt-cells = <2>;
+	};
+
+	gpp8: gpp8-gpio-bank {
+		gpio-controller;
+		#gpio-cells = <2>;
+		interrupt-controller;
+		#interrupt-cells = <2>;
+	};
+
+	gpp9: gpp9-gpio-bank {
+		gpio-controller;
+		#gpio-cells = <2>;
+		interrupt-controller;
+		#interrupt-cells = <2>;
+	};
+
+	gpp10: gpp10-gpio-bank {
+		gpio-controller;
+		#gpio-cells = <2>;
+		interrupt-controller;
+		#interrupt-cells = <2>;
+	};
+
+	gpp11: gpp11-gpio-bank {
+		gpio-controller;
+		#gpio-cells = <2>;
+		interrupt-controller;
+		#interrupt-cells = <2>;
+	};
+
+	gpp12: gpp12-gpio-bank {
+		gpio-controller;
+		#gpio-cells = <2>;
+		interrupt-controller;
+		#interrupt-cells = <2>;
+	};
+
+	gpp13: gpp13-gpio-bank {
+		gpio-controller;
+		#gpio-cells = <2>;
+		interrupt-controller;
+		#interrupt-cells = <2>;
+	};
+
+	gpp14: gpp14-gpio-bank {
+		gpio-controller;
+		#gpio-cells = <2>;
+		interrupt-controller;
+		#interrupt-cells = <2>;
+	};
+
+	gpp15: gpp15-gpio-bank {
+		gpio-controller;
+		#gpio-cells = <2>;
+		interrupt-controller;
+		#interrupt-cells = <2>;
+	};
+
+	gpp16: gpp16-gpio-bank {
+		gpio-controller;
+		#gpio-cells = <2>;
+		interrupt-controller;
+		#interrupt-cells = <2>;
+	};
+
+	gpp17: gpp17-gpio-bank {
+		gpio-controller;
+		#gpio-cells = <2>;
+		interrupt-controller;
+		#interrupt-cells = <2>;
+	};
+
+	gpp18: gpp18-gpio-bank {
+		gpio-controller;
+		#gpio-cells = <2>;
+		interrupt-controller;
+		#interrupt-cells = <2>;
+	};
+
+	gpp19: gpp19-gpio-bank {
+		gpio-controller;
+		#gpio-cells = <2>;
+		interrupt-controller;
+		#interrupt-cells = <2>;
+	};
+
+	/* USI_PERIC0_UART_DBG */
+	uart0_bus: uart0-bus-pins {
+		samsung,pins = "gpp1-2", "gpp1-3";
+		samsung,pin-function = <2>;
+		samsung,pin-pud = <0>;
+	};
+
+	disp_te_pri_on: disp-te-pri-on-pins {
+		samsung,pins = "gpp0-3";
+		samsung,pin-function = <0xf>;
+	};
+
+	disp_te_pri_off: disp-te-pri-off-pins {
+		samsung,pins = "gpp0-3";
+		samsung,pin-function = <0>;
+	};
+
+	disp_te_sec_on: disp-te-sec-on-pins {
+		samsung,pins = "gpp0-4";
+		samsung,pin-function = <0xf>;
+	};
+
+	disp_te_sec_off: disp-te-sec-off-pins {
+		samsung,pins = "gpp0-4";
+		samsung,pin-function = <0>;
+	};
+
+	sensor_mclk1_out: sensor-mclk1-out-pins {
+		samsung,pins = "gpp3-0";
+		samsung,pin-function = <GS101_PIN_FUNC_OUTPUT>;
+		samsung,pin-pud = <GS101_PIN_PULL_DOWN>;
+		samsung,pin-drv = <GS101_PIN_DRV_5_MA>;
+	};
+
+	sensor_mclk1_fn: sensor-mclk1-fn-pins {
+		samsung,pins = "gpp3-0";
+		samsung,pin-function = <GS101_PIN_FUNC_2>;
+		samsung,pin-pud = <GS101_PIN_PULL_NONE>;
+		samsung,pin-drv = <GS101_PIN_DRV_5_MA>;
+	};
+
+	sensor_mclk2_out: sensor-mclk2-out-pins {
+		samsung,pins = "gpp5-0";
+		samsung,pin-function = <GS101_PIN_FUNC_OUTPUT>;
+		samsung,pin-pud = <GS101_PIN_PULL_DOWN>;
+		samsung,pin-drv = <GS101_PIN_DRV_5_MA>;
+	};
+
+	sensor_mclk2_fn: sensor-mclk2-fn-pins {
+		samsung,pins = "gpp5-0";
+		samsung,pin-function = <GS101_PIN_FUNC_2>;
+		samsung,pin-pud = <GS101_PIN_PULL_NONE>;
+		samsung,pin-drv = <GS101_PIN_DRV_5_MA>;
+	};
+
+	sensor_mclk3_out: sensor-mclk3-out-pins {
+		samsung,pins = "gpp7-0";
+		samsung,pin-function = <GS101_PIN_FUNC_OUTPUT>;
+		samsung,pin-pud = <GS101_PIN_PULL_DOWN>;
+		samsung,pin-drv = <GS101_PIN_DRV_5_MA>;
+	};
+
+	sensor_mclk3_fn: sensor-mclk3-fn-pins {
+		samsung,pins = "gpp7-0";
+		samsung,pin-function = <GS101_PIN_FUNC_2>;
+		samsung,pin-pud = <GS101_PIN_PULL_NONE>;
+		samsung,pin-drv = <GS101_PIN_DRV_5_MA>;
+	};
+
+	sensor_mclk4_out: sensor-mclk4-out-pins {
+		samsung,pins = "gpp9-0";
+		samsung,pin-function = <GS101_PIN_FUNC_OUTPUT>;
+		samsung,pin-pud = <GS101_PIN_PULL_DOWN>;
+		samsung,pin-drv = <GS101_PIN_DRV_5_MA>;
+	};
+
+	sensor_mclk4_fn: sensor-mclk4-fn-pins {
+		samsung,pins = "gpp9-0";
+		samsung,pin-function = <GS101_PIN_FUNC_2>;
+		samsung,pin-pud = <GS101_PIN_PULL_NONE>;
+		samsung,pin-drv = <GS101_PIN_DRV_5_MA>;
+	};
+
+	sensor_mclk5_out: sensor-mclk5-out-pins {
+		samsung,pins = "gpp11-0";
+		samsung,pin-function = <GS101_PIN_FUNC_OUTPUT>;
+		samsung,pin-pud = <GS101_PIN_PULL_DOWN>;
+		samsung,pin-drv = <GS101_PIN_DRV_5_MA>;
+	};
+
+	sensor_mclk5_fn: sensor-mclk5-fn-pins {
+		samsung,pins = "gpp11-0";
+		samsung,pin-function = <GS101_PIN_FUNC_2>;
+		samsung,pin-pud = <GS101_PIN_PULL_NONE>;
+		samsung,pin-drv = <GS101_PIN_DRV_5_MA>;
+	};
+
+	sensor_mclk6_out: sensor-mclk6-out-pins {
+		samsung,pins = "gpp13-0";
+		samsung,pin-function = <GS101_PIN_FUNC_OUTPUT>;
+		samsung,pin-pud = <GS101_PIN_PULL_DOWN>;
+		samsung,pin-drv = <GS101_PIN_DRV_5_MA>;
+	};
+
+	sensor_mclk6_fn: sensor-mclk6-fn-pins {
+		samsung,pins = "gpp13-0";
+		samsung,pin-function = <GS101_PIN_FUNC_2>;
+		samsung,pin-pud = <GS101_PIN_PULL_NONE>;
+		samsung,pin-drv = <GS101_PIN_DRV_5_MA>;
+	};
+
+	sensor_mclk7_out: sensor-mclk7-out-pins {
+		samsung,pins = "gpp15-0";
+		samsung,pin-function = <GS101_PIN_FUNC_OUTPUT>;
+		samsung,pin-pud = <GS101_PIN_PULL_DOWN>;
+		samsung,pin-drv = <GS101_PIN_DRV_5_MA>;
+	};
+
+	sensor_mclk7_fn: sensor-mclk7-fn-pins {
+		samsung,pins = "gpp15-0";
+		samsung,pin-function = <GS101_PIN_FUNC_2>;
+		samsung,pin-pud = <GS101_PIN_PULL_NONE>;
+		samsung,pin-drv = <GS101_PIN_DRV_5_MA>;
+	};
+
+	sensor_mclk8_out: sensor-mclk8-out-pins {
+		samsung,pins = "gpp17-0";
+		samsung,pin-function = <GS101_PIN_FUNC_OUTPUT>;
+		samsung,pin-pud = <GS101_PIN_PULL_DOWN>;
+		samsung,pin-drv = <GS101_PIN_DRV_5_MA>;
+	};
+
+	sensor_mclk8_fn: sensor-mclk8-fn-pins {
+		samsung,pins = "gpp17-0";
+		samsung,pin-function = <GS101_PIN_FUNC_2>;
+		samsung,pin-pud = <GS101_PIN_PULL_NONE>;
+		samsung,pin-drv = <GS101_PIN_DRV_5_MA>;
+	};
+
+	hsi2c14_bus: hsi2c14-bus-pins {
+		samsung,pins = "gpp18-0", "gpp18-1";
+		samsung,pin-function = <2>;
+		samsung,pin-pud = <0>;
+		samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
+	};
+
+	uart14_bus_single: uart14-bus-pins {
+		samsung,pins = "gpp18-0", "gpp18-1",
+			       "gpp18-2", "gpp18-3";
+		samsung,pin-function = <2>;
+		samsung,pin-pud = <0>;
+	};
+
+	spi14_bus: spi14-bus-pins {
+		samsung,pins = "gpp18-0", "gpp18-1", "gpp18-2";
+		samsung,pin-function = <2>;
+		samsung,pin-pud = <0>;
+		samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
+	};
+
+	spi14_cs: spi14-cs-pins {
+		samsung,pins = "gpp18-3";
+		samsung,pin-function = <1>;
+		samsung,pin-pud = <0>;
+		samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
+	};
+
+	spi14_cs_func: spi14-cs-func-pins {
+		samsung,pins = "gpp18-3";
+		samsung,pin-function = <2>;
+		samsung,pin-pud = <0>;
+		samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
+	};
+
+	hsi2c8_bus: hsi2c8-bus-pins {
+		samsung,pins = "gpp16-0", "gpp16-1";
+		samsung,pin-function = <GS101_PIN_FUNC_3>;
+		samsung,pin-pud = <GS101_PIN_PULL_NONE>;
+		samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
+		samsung,pin-pud-pdn = <GS101_PIN_PDN_OUT0>;
+	};
+
+	uart8_bus_single: uart8-bus-pins {
+		samsung,pins = "gpp16-0", "gpp16-1", "gpp16-2",
+			       "gpp16-3";
+		samsung,pin-function = <3>;
+		samsung,pin-pud = <0>;
+	};
+
+	spi8_bus: spi8-bus-pins {
+		samsung,pins = "gpp16-0", "gpp16-1", "gpp16-2";
+		samsung,pin-function = <3>;
+		samsung,pin-pud = <0>;
+		samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
+	};
+
+	spi8_cs: spi8-cs-pins {
+		samsung,pins = "gpp16-3";
+		samsung,pin-function = <1>;
+		samsung,pin-pud = <0>;
+		samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
+	};
+
+	spi8_cs_func: spi8-cs-func-pins {
+		samsung,pins = "gpp16-3";
+		samsung,pin-function = <3>;
+		samsung,pin-pud = <0>;
+		samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
+	};
+
+	hsi2c7_bus: hsi2c7-bus-pins {
+		samsung,pins = "gpp14-0", "gpp14-1";
+		samsung,pin-function = <3>;
+		samsung,pin-pud = <0>;
+		samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
+	};
+
+	uart7_bus_single: uart7-bus-pins {
+		samsung,pins = "gpp14-0", "gpp14-1",
+			       "gpp14-2", "gpp14-3";
+		samsung,pin-function = <3>;
+		samsung,pin-pud = <0>;
+	};
+
+	spi7_bus: spi7-bus-pins {
+		samsung,pins = "gpp14-0", "gpp14-1", "gpp14-2";
+		samsung,pin-function = <3>;
+		samsung,pin-pud = <0>;
+		samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
+	};
+
+	spi7_cs: spi7-cs-pins {
+		samsung,pins = "gpp14-3";
+		samsung,pin-function = <1>;
+		samsung,pin-pud = <0>;
+		samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
+	};
+
+	spi7_cs_func: spi7-cs-func-pins {
+		samsung,pins = "gpp14-3";
+		samsung,pin-function = <3>;
+		samsung,pin-pud = <0>;
+		samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
+	};
+
+	hsi2c6_bus: hsi2c6-bus-pins {
+		samsung,pins = "gpp12-0", "gpp12-1";
+		samsung,pin-function = <3>;
+		samsung,pin-pud = <0>;
+		samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
+	};
+
+	uart6_bus_single: uart6-bus-pins {
+		samsung,pins = "gpp12-0", "gpp12-1",
+			       "gpp12-2", "gpp12-3";
+		samsung,pin-function = <3>;
+		samsung,pin-pud = <0>;
+	};
+
+	spi6_bus: spi6-bus-pins {
+		samsung,pins = "gpp12-0", "gpp12-1", "gpp12-2";
+		samsung,pin-function = <3>;
+		samsung,pin-pud = <0>;
+		samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
+	};
+
+	spi6_cs: spi6-cs-pins {
+		samsung,pins = "gpp12-3";
+		samsung,pin-function = <1>;
+		samsung,pin-pud = <0>;
+		samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
+	};
+
+	spi6_cs_func: spi6-cs-func-pins {
+		samsung,pins = "gpp12-3";
+		samsung,pin-function = <3>;
+		samsung,pin-pud = <0>;
+		samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
+	};
+
+	hsi2c5_bus: hsi2c5-bus-pins {
+		samsung,pins = "gpp10-0", "gpp10-1";
+		samsung,pin-function = <3>;
+		samsung,pin-pud = <0>;
+		samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
+	};
+
+	uart5_bus_single: uart5-bus-pins {
+		samsung,pins = "gpp10-0", "gpp10-1",
+			       "gpp10-2", "gpp10-3";
+		samsung,pin-function = <3>;
+		samsung,pin-pud = <0>;
+	};
+
+	spi5_bus: spi5-bus-pins {
+		samsung,pins = "gpp10-0", "gpp10-1", "gpp10-2";
+		samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
+		samsung,pin-function = <GS101_PIN_FUNC_3>;
+		samsung,pin-pud = <GS101_PIN_PULL_NONE>;
+		samsung,pin-con-pdn = <GS101_PIN_PDN_PREV>;
+		samsung,pin-pud-pdn = <GS101_PIN_PULL_NONE>;
+	};
+
+	spi5_cs_func: spi5-cs-func-pins {
+		samsung,pins = "gpp10-3";
+		samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
+		samsung,pin-function = <GS101_PIN_FUNC_3>;
+		samsung,pin-pud = <GS101_PIN_PULL_NONE>;
+		samsung,pin-con-pdn = <GS101_PIN_PDN_PREV>;
+		samsung,pin-pud-pdn = <GS101_PIN_PULL_NONE>;
+	};
+
+	hsi2c4_bus: hsi2c4-bus-pins {
+		samsung,pins = "gpp8-0", "gpp8-1";
+		samsung,pin-function = <3>;
+		samsung,pin-pud = <0>;
+		samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
+	};
+
+	uart4_bus_single: uart4-bus-pins {
+		samsung,pins = "gpp8-0", "gpp8-1",
+			       "gpp8-2", "gpp8-3";
+		samsung,pin-function = <3>;
+		samsung,pin-pud = <0>;
+	};
+
+	spi4_bus: spi4-bus-pins {
+		samsung,pins = "gpp8-0", "gpp8-1", "gpp8-2";
+		samsung,pin-function = <3>;
+		samsung,pin-pud = <0>;
+		samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
+	};
+
+	spi4_cs: spi4-cs-pins {
+		samsung,pins = "gpp8-3";
+		samsung,pin-function = <1>;
+		samsung,pin-pud = <0>;
+		samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
+	};
+
+	spi4_cs_func: spi4-cs-func-pins {
+		samsung,pins = "gpp8-3";
+		samsung,pin-function = <3>;
+		samsung,pin-pud = <0>;
+		samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
+	};
+
+	hsi2c3_bus: hsi2c3-bus-pins {
+		samsung,pins = "gpp6-0", "gpp6-1";
+		samsung,pin-function = <3>;
+		samsung,pin-pud = <0>;
+		samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
+	};
+
+	uart3_bus_single: uart3-bus-pins {
+		samsung,pins = "gpp6-0", "gpp6-1",
+			       "gpp6-2", "gpp6-3";
+		samsung,pin-function = <3>;
+		samsung,pin-pud = <0>;
+	};
+
+	spi3_bus: spi3-bus-pins {
+		samsung,pins = "gpp6-0", "gpp6-1", "gpp6-2";
+		samsung,pin-function = <3>;
+		samsung,pin-pud = <0>;
+		samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
+	};
+
+	spi3_cs: spi3-cs-pins {
+		samsung,pins = "gpp6-3";
+		samsung,pin-function = <1>;
+		samsung,pin-pud = <0>;
+		samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
+	};
+
+	spi3_cs_func: spi3-cs-func-pins {
+		samsung,pins = "gpp6-3";
+		samsung,pin-function = <3>;
+		samsung,pin-pud = <0>;
+		samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
+	};
+
+	hsi2c2_bus: hsi2c2-bus-pins {
+		samsung,pins = "gpp4-0", "gpp4-1";
+		samsung,pin-function = <3>;
+		samsung,pin-pud = <0>;
+		samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
+	};
+
+	uart2_bus_single: uart2-bus-pins {
+		samsung,pins = "gpp4-0", "gpp4-1",
+			       "gpp4-2", "gpp4-3";
+		samsung,pin-function = <3>;
+		samsung,pin-pud = <0>;
+	};
+
+	spi2_bus: spi2-bus-pins {
+		samsung,pins = "gpp4-0", "gpp4-1", "gpp4-2";
+		samsung,pin-function = <3>;
+		samsung,pin-pud = <0>;
+		samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
+	};
+
+	spi2_cs: spi2-cs-pins {
+		samsung,pins = "gpp4-3";
+		samsung,pin-function = <1>;
+		samsung,pin-pud = <0>;
+		samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
+	};
+
+	spi2_cs_func: spi2-cs-func-pins {
+		samsung,pins = "gpp4-3";
+		samsung,pin-function = <3>;
+		samsung,pin-pud = <0>;
+		samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
+	};
+
+	hsi2c1_bus: hsi2c1-bus-pins {
+		samsung,pins = "gpp2-0", "gpp2-1";
+		samsung,pin-function = <3>;
+		samsung,pin-pud = <0>;
+		samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
+	};
+
+	uart1_bus_single: uart1-bus-pins {
+		samsung,pins = "gpp2-0", "gpp2-1",
+			       "gpp2-2", "gpp2-3";
+		samsung,pin-function = <3>;
+		samsung,pin-pud = <0>;
+	};
+
+	spi1_bus: spi1-bus-pins {
+		samsung,pins = "gpp2-0", "gpp2-1", "gpp2-2";
+		samsung,pin-function = <3>;
+		samsung,pin-pud = <0>;
+		samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
+	};
+
+	spi1_cs: spi1-cs-pins {
+		samsung,pins = "gpp2-3";
+		samsung,pin-function = <1>;
+		samsung,pin-pud = <0>;
+		samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
+	};
+
+	spi1_cs_func: spi1-cs-func-pins {
+		samsung,pins = "gpp2-3";
+		samsung,pin-function = <3>;
+		samsung,pin-pud = <0>;
+		samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
+	};
+};
+
+/* GPIO_PERIC1 */
+&pinctrl_5 {
+	gpp20: gpp20-gpio-bank {
+		gpio-controller;
+		#gpio-cells = <2>;
+		interrupt-controller;
+		#interrupt-cells = <2>;
+	};
+
+	gpp21: gpp21-gpio-bank {
+		gpio-controller;
+		#gpio-cells = <2>;
+		interrupt-controller;
+		#interrupt-cells = <2>;
+	};
+
+	gpp22: gpp22-gpio-bank {
+		gpio-controller;
+		#gpio-cells = <2>;
+		interrupt-controller;
+		#interrupt-cells = <2>;
+	};
+
+	gpp23: gpp23-gpio-bank {
+		gpio-controller;
+		#gpio-cells = <2>;
+		interrupt-controller;
+		#interrupt-cells = <2>;
+	};
+
+	gpp24: gpp24-gpio-bank {
+		gpio-controller;
+		#gpio-cells = <2>;
+		interrupt-controller;
+		#interrupt-cells = <2>;
+	};
+
+	gpp25: gpp25-gpio-bank {
+		gpio-controller;
+		#gpio-cells = <2>;
+		interrupt-controller;
+		#interrupt-cells = <2>;
+	};
+
+	gpp26: gpp26-gpio-bank {
+		gpio-controller;
+		#gpio-cells = <2>;
+		interrupt-controller;
+		#interrupt-cells = <2>;
+	};
+
+	gpp27: gpp27-gpio-bank {
+		gpio-controller;
+		#gpio-cells = <2>;
+		interrupt-controller;
+		#interrupt-cells = <2>;
+	};
+
+	hsi2c13_bus: hsi2c13-bus-pins  {
+		samsung,pins = "gpp25-0", "gpp25-1";
+		samsung,pin-function = <2>;
+		samsung,pin-pud = <0>;
+		samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
+	};
+
+	uart13_bus_single: uart13-bus-pins {
+	       samsung,pins = "gpp25-0", "gpp25-1",
+			      "gpp25-2", "gpp25-3";
+	       samsung,pin-function = <2>;
+	       samsung,pin-pud = <0>;
+	};
+
+	spi13_bus: spi13-bus-pins {
+		samsung,pins = "gpp25-0", "gpp25-1", "gpp25-2";
+		samsung,pin-function = <2>;
+		samsung,pin-pud = <0>;
+		samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
+	};
+
+	spi13_cs: spi13-cs-pins {
+		samsung,pins = "gpp25-3";
+		samsung,pin-function = <1>;
+		samsung,pin-pud = <0>;
+		samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
+	};
+
+	spi13_cs_func: spi13-cs-func-pins {
+		samsung,pins = "gpp25-3";
+		samsung,pin-function = <2>;
+		samsung,pin-pud = <0>;
+		samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
+	};
+
+	hsi2c12_bus: hsi2c12-bus-pins {
+		samsung,pins = "gpp23-4", "gpp23-5";
+		samsung,pin-function = <2>;
+		samsung,pin-pud = <0>;
+		samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
+	};
+
+	uart12_bus_single: uart12-bus-pins {
+		samsung,pins = "gpp23-4", "gpp23-5",
+			       "gpp23-6", "gpp23-7";
+		samsung,pin-function = <2>;
+		samsung,pin-pud = <0>;
+	};
+
+	spi12_bus: spi12-bus-pins {
+		samsung,pins = "gpp23-4", "gpp23-5", "gpp23-6";
+		samsung,pin-function = <2>;
+		samsung,pin-pud = <0>;
+		samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
+	};
+
+	spi14_cs2: spi14-cs2-pins {
+		samsung,pins = "gpp23-6";
+		samsung,pin-function = <GS101_PIN_FUNC_OUTPUT>;
+		samsung,pin-pud = <GS101_PIN_PULL_NONE>;
+		samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
+	};
+
+	spi12_cs: spi12-cs-pins {
+		samsung,pins = "gpp23-7";
+		samsung,pin-function = <1>;
+		samsung,pin-pud = <0>;
+		samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
+	};
+
+	spi12_cs_func: spi12-cs-func-pins {
+		samsung,pins = "gpp23-7";
+		samsung,pin-function = <2>;
+		samsung,pin-pud = <0>;
+		samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
+	};
+
+	hsi2c11_bus: hsi2c11-bus-pins {
+		samsung,pins = "gpp23-0", "gpp23-1";
+		samsung,pin-function = <2>;
+		samsung,pin-pud = <0>;
+		samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
+	};
+
+	uart11_bus_single: uart11-bus-pins {
+		samsung,pins = "gpp23-0", "gpp23-1",
+			       "gpp23-2", "gpp23-3";
+		samsung,pin-function = <2>;
+		samsung,pin-pud = <0>;
+	};
+
+	spi11_bus: spi11-bus-pins {
+		samsung,pins = "gpp23-0", "gpp23-1", "gpp23-2";
+		samsung,pin-function = <2>;
+		samsung,pin-pud = <0>;
+		samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
+	};
+
+	spi11_cs: spi11-cs-pins {
+		samsung,pins = "gpp23-3";
+		samsung,pin-function = <1>;
+		samsung,pin-pud = <0>;
+		samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
+	};
+
+	spi11_cs_func: spi11-cs-func-pins {
+		samsung,pins = "gpp23-3";
+		samsung,pin-function = <2>;
+		samsung,pin-pud = <0>;
+		samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
+	};
+
+	hsi2c10_bus: hsi2c10-bus-pins {
+		samsung,pins = "gpp21-0", "gpp21-1";
+		samsung,pin-function = <2>;
+		samsung,pin-pud = <0>;
+		samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
+	};
+
+	uart10_bus_single: uart10-bus-pins {
+		samsung,pins = "gpp21-0", "gpp21-1",
+			       "gpp21-2", "gpp21-3";
+		samsung,pin-function = <2>;
+		samsung,pin-pud = <0>;
+	};
+
+	spi10_bus: spi10-bus-pins {
+		samsung,pins = "gpp21-0", "gpp21-1", "gpp21-2";
+		samsung,pin-function = <2>;
+		samsung,pin-pud = <0>;
+		samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
+	};
+
+	spi10_cs: spi10-cs-pins {
+		samsung,pins = "gpp21-3";
+		samsung,pin-function = <1>;
+		samsung,pin-pud = <0>;
+		samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
+	};
+
+	spi10_cs_func: spi10-cs-func-pins {
+		samsung,pins = "gpp21-3";
+		samsung,pin-function = <2>;
+		samsung,pin-pud = <0>;
+		samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
+	};
+
+	hsi2c9_bus: hsi2c9-bus-pins {
+		samsung,pins = "gpp20-4", "gpp20-5";
+		samsung,pin-function = <2>;
+		samsung,pin-pud = <0>;
+		samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
+	};
+
+	uart9_bus_single: uart9-bus-pins {
+		samsung,pins = "gpp20-4", "gpp20-5",
+			       "gpp20-6", "gpp20-7";
+		samsung,pin-function = <2>;
+		samsung,pin-pud = <0>;
+	};
+
+	spi9_bus: spi9-bus-pins {
+		samsung,pins = "gpp20-4", "gpp20-5", "gpp20-6";
+		samsung,pin-function = <2>;
+		samsung,pin-pud = <0>;
+		samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
+	};
+
+	spi9_cs: spi9-cs-pins {
+		samsung,pins = "gpp20-7";
+		samsung,pin-function = <1>;
+		samsung,pin-pud = <0>;
+		samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
+	};
+
+	spi9_cs_func: spi9-cs-func-pins {
+		samsung,pins = "gpp20-7";
+		samsung,pin-function = <2>;
+		samsung,pin-pud = <0>;
+		samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
+	};
+
+	hsi2c0_bus: hsi2c0-bus-pins {
+		samsung,pins = "gpp20-0", "gpp20-1";
+		samsung,pin-function = <3>;
+		samsung,pin-pud = <0>;
+		samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
+	};
+
+	uart0_bus_single: uart0-bus-pins {
+		samsung,pins = "gpp20-0", "gpp20-1",
+			       "gpp20-2", "gpp20-3";
+		samsung,pin-function = <3>;
+		samsung,pin-pud = <0>;
+	};
+
+	spi0_bus: spi0-bus-pins {
+		samsung,pins = "gpp20-0", "gpp20-1", "gpp20-2";
+		samsung,pin-function = <3>;
+		samsung,pin-pud = <0>;
+		samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
+	};
+
+	spi0_cs: spi0-cs-pins {
+		samsung,pins = "gpp20-3";
+		samsung,pin-function = <1>;
+		samsung,pin-pud = <0>;
+		samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
+	};
+
+	spi0_cs_func: spi0-cs-func-pins {
+		samsung,pins = "gpp20-3";
+		samsung,pin-function = <3>;
+		samsung,pin-pud = <0>;
+		samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
+	};
+};
+
diff --git a/arch/arm64/boot/dts/google/gs101-pinctrl.h b/arch/arm64/boot/dts/google/gs101-pinctrl.h
new file mode 100644
index 000000000000..16c54888f4bb
--- /dev/null
+++ b/arch/arm64/boot/dts/google/gs101-pinctrl.h
@@ -0,0 +1,32 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/*
+ * Pinctrl binding constants for GS101
+ *
+ * Copyright (c) 2020-2023 Google, LLC.
+ */
+
+#ifndef __DT_BINDINGS_PINCTRL_GS101_H__
+#define __DT_BINDINGS_PINCTRL_GS101_H__
+
+#define GS101_PIN_PULL_NONE		0
+#define GS101_PIN_PULL_DOWN		1
+#define GS101_PIN_PULL_UP		3
+
+/* Pin function in power down mode */
+#define GS101_PIN_PDN_OUT0		0
+#define GS101_PIN_PDN_OUT1		1
+#define GS101_PIN_PDN_INPUT		2
+#define GS101_PIN_PDN_PREV		3
+
+/* GS101 drive strengths */
+#define GS101_PIN_DRV_2_5_MA		0
+#define GS101_PIN_DRV_5_MA		1
+#define GS101_PIN_DRV_7_5_MA		2
+#define GS101_PIN_DRV_10_MA		3
+
+#define GS101_PIN_FUNC_INPUT		0
+#define GS101_PIN_FUNC_OUTPUT		1
+#define GS101_PIN_FUNC_2		2
+#define GS101_PIN_FUNC_3		3
+
+#endif /* __DT_BINDINGS_PINCTRL_GS101_H__ */
diff --git a/arch/arm64/boot/dts/google/gs101.dtsi b/arch/arm64/boot/dts/google/gs101.dtsi
new file mode 100644
index 000000000000..28b18c594350
--- /dev/null
+++ b/arch/arm64/boot/dts/google/gs101.dtsi
@@ -0,0 +1,503 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * GS101 SoC
+ *
+ * Copyright 2019-2023 Google LLC
+ *
+ */
+
+#include <dt-bindings/clock/google,gs101.h>
+#include <dt-bindings/gpio/gpio.h>
+#include <dt-bindings/interrupt-controller/arm-gic.h>
+
+/ {
+	compatible = "google,gs101";
+	#address-cells = <2>;
+	#size-cells = <1>;
+
+	interrupt-parent = <&gic>;
+
+	aliases {
+		pinctrl0 = &pinctrl_0;
+		pinctrl1 = &pinctrl_1;
+		pinctrl2 = &pinctrl_2;
+		pinctrl3 = &pinctrl_3;
+		pinctrl4 = &pinctrl_4;
+		pinctrl5 = &pinctrl_5;
+		pinctrl6 = &pinctrl_6;
+		pinctrl7 = &pinctrl_7;
+	};
+
+	arm-pmu {
+		compatible = "arm,armv8-pmuv3";
+		interrupts = <GIC_PPI 7 (GIC_CPU_MASK_SIMPLE(8) | IRQ_TYPE_LEVEL_HIGH)>;
+	};
+
+	dsu-pmu-0 {
+		compatible = "arm,dsu-pmu";
+		interrupts = <GIC_SPI 257 IRQ_TYPE_LEVEL_HIGH>;
+		cpus = <&cpu0>, <&cpu1>, <&cpu2>, <&cpu3>,
+		       <&cpu4>, <&cpu5>, <&cpu6>, <&cpu7>;
+	};
+
+	/* TODO replace with CCF clock */
+	dummy_clk: oscillator {
+		compatible = "fixed-clock";
+		#clock-cells = <0>;
+		clock-frequency = <12345>;
+		clock-output-names = "pclk";
+	};
+
+	cpus {
+		#address-cells = <2>;
+		#size-cells = <0>;
+
+		cpu-map {
+			cluster0 {
+				core0 {
+					cpu = <&cpu0>;
+				};
+				core1 {
+					cpu = <&cpu1>;
+				};
+				core2 {
+					cpu = <&cpu2>;
+				};
+				core3 {
+					cpu = <&cpu3>;
+				};
+			};
+
+			cluster1 {
+				core0 {
+					cpu = <&cpu4>;
+				};
+				core1 {
+					cpu = <&cpu5>;
+				};
+			};
+
+			cluster2 {
+				core0 {
+					cpu = <&cpu6>;
+				};
+				core1 {
+					cpu = <&cpu7>;
+				};
+			};
+		};
+
+		cpu0: cpu@0 {
+			device_type = "cpu";
+			compatible = "arm,armv8";
+			reg = <0x0 0x0000>;
+			enable-method = "psci";
+			cpu-idle-states =  <&ANANKE_CPU_SLEEP>;
+			capacity-dmips-mhz = <250>;
+			dynamic-power-coefficient = <70>;
+		};
+
+		cpu1: cpu@100 {
+			device_type = "cpu";
+			compatible = "arm,armv8";
+			reg = <0x0 0x0100>;
+			enable-method = "psci";
+			cpu-idle-states =  <&ANANKE_CPU_SLEEP>;
+			capacity-dmips-mhz = <250>;
+			dynamic-power-coefficient = <70>;
+		};
+
+		cpu2: cpu@200 {
+			device_type = "cpu";
+			compatible = "arm,armv8";
+			reg = <0x0 0x0200>;
+			enable-method = "psci";
+			cpu-idle-states =  <&ANANKE_CPU_SLEEP>;
+			capacity-dmips-mhz = <250>;
+			dynamic-power-coefficient = <70>;
+		};
+
+		cpu3: cpu@300 {
+			device_type = "cpu";
+			compatible = "arm,armv8";
+			reg = <0x0 0x0300>;
+			enable-method = "psci";
+			cpu-idle-states =  <&ANANKE_CPU_SLEEP>;
+			capacity-dmips-mhz = <250>;
+			dynamic-power-coefficient = <70>;
+		};
+
+		cpu4: cpu@400 {
+			device_type = "cpu";
+			compatible = "arm,armv8";
+			reg = <0x0 0x0400>;
+			enable-method = "psci";
+			cpu-idle-states =  <&ENYO_CPU_SLEEP>;
+			capacity-dmips-mhz = <620>;
+			dynamic-power-coefficient = <284>;
+		};
+
+		cpu5: cpu@500 {
+			device_type = "cpu";
+			compatible = "arm,armv8";
+			reg = <0x0 0x0500>;
+			enable-method = "psci";
+			cpu-idle-states =  <&ENYO_CPU_SLEEP>;
+			capacity-dmips-mhz = <620>;
+			dynamic-power-coefficient = <284>;
+		};
+
+		cpu6: cpu@600 {
+			device_type = "cpu";
+			compatible = "arm,armv8";
+			reg = <0x0 0x0600>;
+			enable-method = "psci";
+			cpu-idle-states =  <&HERA_CPU_SLEEP>;
+			capacity-dmips-mhz = <1024>;
+			dynamic-power-coefficient = <650>;
+		};
+
+		cpu7: cpu@700 {
+			device_type = "cpu";
+			compatible = "arm,armv8";
+			reg = <0x0 0x0700>;
+			enable-method = "psci";
+			cpu-idle-states =  <&HERA_CPU_SLEEP>;
+			capacity-dmips-mhz = <1024>;
+			dynamic-power-coefficient = <650>;
+		};
+
+		idle-states {
+			entry-method = "psci";
+
+			ANANKE_CPU_SLEEP: cpu-ananke-sleep {
+				idle-state-name = "c2";
+				compatible = "arm,idle-state";
+				arm,psci-suspend-param = <0x0010000>;
+				entry-latency-us = <70>;
+				exit-latency-us = <160>;
+				min-residency-us = <2000>;
+			};
+
+			ENYO_CPU_SLEEP: cpu-enyo-sleep {
+				idle-state-name = "c2";
+				compatible = "arm,idle-state";
+				arm,psci-suspend-param = <0x0010000>;
+				entry-latency-us = <150>;
+				exit-latency-us = <190>;
+				min-residency-us = <2500>;
+			};
+
+			HERA_CPU_SLEEP: cpu-hera-sleep {
+				idle-state-name = "c2";
+				compatible = "arm,idle-state";
+				arm,psci-suspend-param = <0x0010000>;
+				entry-latency-us = <235>;
+				exit-latency-us = <220>;
+				min-residency-us = <3500>;
+			};
+		};
+	};
+
+	/* bootloader requires ect node */
+	ect {
+		parameter_address = <0x90000000>;
+		parameter_size = <0x53000>;
+	};
+
+	ext_24_5m: clock-1 {
+		compatible = "fixed-clock";
+		#clock-cells = <0>;
+		clock-frequency = <24576000>;
+		clock-output-names = "oscclk";
+	};
+
+	ext_200m: clock-2 {
+		compatible = "fixed-clock";
+		#clock-cells = <0>;
+		clock-frequency = <200000000>;
+		clock-output-names = "ext-200m";
+	};
+
+	psci {
+		compatible = "arm,psci-1.0";
+		method = "smc";
+	};
+
+	reserved_memory: reserved-memory {
+		#address-cells = <2>;
+		#size-cells = <1>;
+		ranges;
+
+		gsa_reserved_protected: gsa@90200000 {
+			reg = <0x0 0x90200000 0x400000>;
+			no-map;
+		};
+
+		tpu_fw_reserved: tpu-fw@93000000 {
+			reg = <0x0 0x93000000 0x1000000>;
+			no-map;
+		};
+
+		aoc_reserve: aoc@94000000 {
+			reg = <0x0 0x94000000 0x03000000>;
+			no-map;
+		};
+
+		abl_reserved: abl@f8800000 {
+			reg = <0x0 0xf8800000 0x02000000>;
+			no-map;
+		};
+
+		dss_log_reserved: dss-log-reserved@fd3f0000 {
+			reg = <0 0xfd3f0000 0x0000e000>;
+			no-map;
+		};
+
+		debug_kinfo_reserved: debug-kinfo-reserved@fd3fe000 {
+			reg = <0 0xfd3fe000 0x00001000>;
+			no-map;
+		};
+
+		bldr_log_reserved: bldr-log-reserved@fd800000 {
+			reg = <0 0xfd800000 0x00100000>;
+			no-map;
+		};
+
+		bldr_log_hist_reserved: bldr-log-hist-reserved@fd900000 {
+			reg = <0 0xfd900000 0x00002000>;
+			no-map;
+		};
+	};
+
+	timer {
+		compatible = "arm,armv8-timer";
+		interrupts = <GIC_PPI 13 (GIC_CPU_MASK_SIMPLE(8) | IRQ_TYPE_LEVEL_LOW)>,
+			     <GIC_PPI 14 (GIC_CPU_MASK_SIMPLE(8) | IRQ_TYPE_LEVEL_LOW)>,
+			     <GIC_PPI 11 (GIC_CPU_MASK_SIMPLE(8) | IRQ_TYPE_LEVEL_LOW)>,
+			     <GIC_PPI 10 (GIC_CPU_MASK_SIMPLE(8) | IRQ_TYPE_LEVEL_LOW)>;
+		clock-frequency = <24576000>;
+	};
+
+	soc: soc@0 {
+		compatible = "simple-bus";
+		#address-cells = <2>;
+		#size-cells = <1>;
+		ranges;
+
+		cmu_misc: clock-controller@10010000 {
+			compatible = "google,gs101-cmu-misc";
+			reg = <0x0 0x10010000 0x8000>;
+			#clock-cells = <1>;
+			clocks =  <&ext_24_5m>, <&cmu_top CLK_DOUT_MISC_BUS>;
+			clock-names = "oscclk", "dout_cmu_misc_bus";
+		};
+
+		watchdog_cl0: watchdog@10060000 {
+			compatible = "google,gs101-wdt";
+			reg = <0x0 0x10060000 0x100>;
+			interrupts = <GIC_SPI 765 IRQ_TYPE_LEVEL_HIGH>;
+			clocks = <&cmu_misc CLK_GOUT_MISC_WDT_CLUSTER0>, <&ext_24_5m>;
+			clock-names = "watchdog", "watchdog_src";
+			samsung,syscon-phandle = <&pmu_system_controller>;
+			samsung,cluster-index = <0>;
+		};
+
+		watchdog_cl1: watchdog@10070000 {
+			compatible = "google,gs101-wdt";
+			reg = <0x0 0x10070000 0x100>;
+			interrupts = <GIC_SPI 766 IRQ_TYPE_LEVEL_HIGH>;
+			clocks = <&cmu_misc CLK_GOUT_MISC_WDT_CLUSTER1>, <&ext_24_5m>;
+			clock-names = "watchdog", "watchdog_src";
+			samsung,syscon-phandle = <&pmu_system_controller>;
+			samsung,cluster-index = <1>;
+			status = "disabled";
+		};
+
+		gic: interrupt-controller@10400000 {
+		     compatible = "arm,gic-v3";
+		     #interrupt-cells = <3>;
+		     interrupt-controller;
+		     reg = <0x0 0x10400000 0x10000>,	/* GICD */
+			   <0x0 0x10440000 0x100000>;	/* GICR * 8 */
+		     interrupts = <GIC_PPI 9 IRQ_TYPE_LEVEL_HIGH>;
+		};
+
+		sysreg_peric0: syscon@10821000 {
+			compatible = "google,gs101-peric0-sysreg", "syscon";
+			reg = <0x0 0x10821000 0x40000>;
+		};
+
+		/* GPIO_PERIC0 */
+		pinctrl_4: pinctrl@10840000 {
+			compatible = "google,gs101-pinctrl";
+			reg = <0x0 0x10840000 0x00001000>;
+			interrupts = <GIC_SPI 625 IRQ_TYPE_LEVEL_HIGH>;
+		};
+
+		serial_0: serial@10a00000 {
+			compatible = "google,gs101-uart";
+			reg = <0x0 0x10a00000 0xc0>;
+			reg-io-width = <4>;
+			samsung,uart-fifosize = <256>;
+			interrupts = <GIC_SPI 634 IRQ_TYPE_LEVEL_HIGH>;
+			clocks = <&dummy_clk 0>, <&dummy_clk 0>;
+			clock-names = "uart", "clk_uart_baud0";
+		};
+
+		/* GPIO_PERIC1 */
+		pinctrl_5: pinctrl@10c40000 {
+			compatible = "google,gs101-pinctrl";
+			reg = <0x0 0x10C40000 0x00001000>;
+			interrupts = <GIC_SPI 644 IRQ_TYPE_LEVEL_HIGH>;
+		};
+
+		sysreg_peric1: syscon@10c21000 {
+			compatible = "google,gs101-peric1-sysreg", "syscon";
+			reg = <0x0 0x10C21000 0x40000>;
+		};
+
+		/* GPIO_HSI1 */
+		pinctrl_6: pinctrl@11840000 {
+			compatible = "google,gs101-pinctrl";
+			reg = <0x0 0x11840000 0x00001000>;
+			interrupts = <GIC_SPI 471 IRQ_TYPE_LEVEL_HIGH>;
+		};
+
+		/* GPIO_HSI2 */
+		pinctrl_7: pinctrl@14440000 {
+			compatible = "google,gs101-pinctrl";
+			reg = <0x0 0x14440000 0x00001000>;
+			interrupts = <GIC_SPI 503 IRQ_TYPE_LEVEL_HIGH>;
+		};
+
+		cmu_apm: clock-controller@17400000 {
+			compatible = "google,gs101-cmu-apm";
+			reg = <0x0 0x17400000 0x8000>;
+			#clock-cells = <1>;
+
+			clocks = <&ext_24_5m>;
+			clock-names = "oscclk";
+		};
+
+		sysreg_apm: syscon@174204e0 {
+			compatible = "google,gs101-apm-sysreg", "syscon";
+			reg = <0x0 0x174204e0 0x1000>;
+		};
+
+		pmu_system_controller: system-controller@17460000 {
+			compatible = "google,gs101-pmu", "syscon";
+			reg = <0x0 0x17460000 0x10000>;
+		};
+
+		/* GPIO_ALIVE */
+		pinctrl_0: pinctrl@174d0000 {
+			compatible = "google,gs101-pinctrl";
+			reg = <0x0 0x174d0000 0x00001000>;
+			interrupts = <GIC_SPI 0 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 1 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 2 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 3 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 4 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 5 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 6 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 7 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 8 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 9 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 10 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 11 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 12 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 13 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 14 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 15 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 16 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 17 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 18 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 19 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 20 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 21 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 22 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 23 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 24 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 25 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 26 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 27 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 28 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 29 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 30 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 31 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 32 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 33 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 34 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 35 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 36 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 37 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 38 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 39 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 40 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 41 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 42 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 43 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 44 IRQ_TYPE_LEVEL_HIGH>;
+
+			wakeup-interrupt-controller {
+				compatible = "google,gs101-wakeup-eint";
+			};
+		};
+
+		/* GPIO_FAR_ALIVE */
+		pinctrl_1: pinctrl@174e0000 {
+			compatible = "google,gs101-pinctrl";
+			reg = <0x0 0x174e0000 0x00001000>;
+			interrupts = <GIC_SPI 45 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 46 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 47 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 48 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 49 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 50 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 51 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 52 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 53 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 54 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 55 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 56 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 57 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 58 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 59 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 60 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 61 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 62 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 63 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 64 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 65 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 66 IRQ_TYPE_LEVEL_HIGH>;
+
+			wakeup-interrupt-controller {
+				compatible = "google,gs101-wakeup-eint";
+			};
+		};
+
+		/* GPIO_GSACTRL */
+		pinctrl_3: pinctrl@17940000 {
+			compatible = "google,gs101-pinctrl";
+			reg = <0x0 0x17940000 0x00001000>;
+		};
+
+		/* GPIO_GSACORE */
+		pinctrl_2: pinctrl@17a80000 {
+			compatible = "google,gs101-pinctrl";
+			reg = <0x0 0x17a80000 0x00001000>;
+		};
+
+		cmu_top: clock-controller@1e080000 {
+			compatible = "google,gs101-cmu-top";
+			reg = <0x0 0x1e080000 0x8000>;
+			#clock-cells = <1>;
+
+			clocks = <&ext_24_5m>;
+			clock-names = "oscclk";
+		};
+	};
+};
+
+#include "gs101-pinctrl.dtsi"
-- 
2.42.0.609.gbb76f46606-goog

[PATCH v2 17/20] arm64: dts: google: Add initial Google gs101 SoC support

[Peter Griffin]

Google gs101 SoC is ARMv8 mobile SoC found in the Pixel 6,
(oriole) Pixel 6a (bluejay) and Pixel 6 pro (raven) mobile
phones. It features:
* 4xA55 little cluster
* 2xA76 Mid cluster
* 2xX1 Big cluster

This commit adds the basic device tree for gs101 (SoC).
Further platform support will be added over time.

Signed-off-by: Peter Griffin <peter.griffin@linaro.org>
---
 arch/arm64/Kconfig.platforms                  |    6 +
 arch/arm64/boot/dts/Makefile                  |    1 +
 arch/arm64/boot/dts/google/gs101-pinctrl.dtsi | 1275 +++++++++++++++++
 arch/arm64/boot/dts/google/gs101-pinctrl.h    |   32 +
 arch/arm64/boot/dts/google/gs101.dtsi         |  503 +++++++
 5 files changed, 1817 insertions(+)
 create mode 100644 arch/arm64/boot/dts/google/gs101-pinctrl.dtsi
 create mode 100644 arch/arm64/boot/dts/google/gs101-pinctrl.h
 create mode 100644 arch/arm64/boot/dts/google/gs101.dtsi

diff --git a/arch/arm64/Kconfig.platforms b/arch/arm64/Kconfig.platforms
index 6069120199bb..a5ed1b719488 100644
--- a/arch/arm64/Kconfig.platforms
+++ b/arch/arm64/Kconfig.platforms
@@ -107,6 +107,12 @@ config ARCH_EXYNOS
 	help
 	  This enables support for ARMv8 based Samsung Exynos SoC family.
 
+config ARCH_GOOGLE_TENSOR
+	bool "Google Tensor SoC fmaily"
+	depends on ARCH_EXYNOS
+	help
+	  Support for ARMv8 based Google Tensor platforms.
+
 config ARCH_SPARX5
 	bool "Microchip Sparx5 SoC family"
 	select PINCTRL
diff --git a/arch/arm64/boot/dts/Makefile b/arch/arm64/boot/dts/Makefile
index 30dd6347a929..a4ee7b628114 100644
--- a/arch/arm64/boot/dts/Makefile
+++ b/arch/arm64/boot/dts/Makefile
@@ -13,6 +13,7 @@ subdir-y += broadcom
 subdir-y += cavium
 subdir-y += exynos
 subdir-y += freescale
+subdir-y += google
 subdir-y += hisilicon
 subdir-y += intel
 subdir-y += lg
diff --git a/arch/arm64/boot/dts/google/gs101-pinctrl.dtsi b/arch/arm64/boot/dts/google/gs101-pinctrl.dtsi
new file mode 100644
index 000000000000..ba88000c3ed8
--- /dev/null
+++ b/arch/arm64/boot/dts/google/gs101-pinctrl.dtsi
@@ -0,0 +1,1275 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * GS101 SoC pin-mux and pin-config device tree source
+ *
+ * Copyright 2019-2023 Google LLC
+ *
+ */
+
+#include "gs101-pinctrl.h"
+
+/* GPIO_ALIVE */
+&pinctrl_0 {
+	gpa0: gpa0-gpio-bank {
+		gpio-controller;
+		#gpio-cells = <2>;
+		interrupt-controller;
+		#interrupt-cells = <2>;
+		interrupt-parent = <&gic>;
+		interrupts = <GIC_SPI 0 IRQ_TYPE_LEVEL_HIGH>,
+			   <GIC_SPI 1 IRQ_TYPE_LEVEL_HIGH>,
+			   <GIC_SPI 2 IRQ_TYPE_LEVEL_HIGH>,
+			   <GIC_SPI 3 IRQ_TYPE_LEVEL_HIGH>,
+			   <GIC_SPI 4 IRQ_TYPE_LEVEL_HIGH>,
+			   <GIC_SPI 5 IRQ_TYPE_LEVEL_HIGH>,
+			   <GIC_SPI 6 IRQ_TYPE_LEVEL_HIGH>,
+			   <GIC_SPI 7 IRQ_TYPE_LEVEL_HIGH>;
+	};
+
+	gpa1: gpa1-gpio-bank {
+		gpio-controller;
+		#gpio-cells = <2>;
+		interrupt-controller;
+		#interrupt-cells = <2>;
+		interrupt-parent = <&gic>;
+		interrupts = <GIC_SPI 8 IRQ_TYPE_LEVEL_HIGH>,
+			   <GIC_SPI 9 IRQ_TYPE_LEVEL_HIGH>,
+			   <GIC_SPI 10 IRQ_TYPE_LEVEL_HIGH>,
+			   <GIC_SPI 11 IRQ_TYPE_LEVEL_HIGH>,
+			   <GIC_SPI 12 IRQ_TYPE_LEVEL_HIGH>,
+			   <GIC_SPI 13 IRQ_TYPE_LEVEL_HIGH>,
+			   <GIC_SPI 14 IRQ_TYPE_LEVEL_HIGH>;
+	};
+
+	gpa2: gpa2-gpio-bank {
+		gpio-controller;
+		#gpio-cells = <2>;
+		interrupt-controller;
+		#interrupt-cells = <2>;
+		interrupt-parent = <&gic>;
+		interrupts = <GIC_SPI 15 IRQ_TYPE_LEVEL_HIGH>,
+			   <GIC_SPI 16 IRQ_TYPE_LEVEL_HIGH>,
+			   <GIC_SPI 17 IRQ_TYPE_LEVEL_HIGH>,
+			   <GIC_SPI 18 IRQ_TYPE_LEVEL_HIGH>,
+			   <GIC_SPI 19 IRQ_TYPE_LEVEL_HIGH>;
+	};
+
+	gpa3: gpa3-gpio-bank {
+		gpio-controller;
+		#gpio-cells = <2>;
+		interrupt-controller;
+		#interrupt-cells = <2>;
+		interrupt-parent = <&gic>;
+		interrupts = <GIC_SPI 20 IRQ_TYPE_LEVEL_HIGH>,
+			   <GIC_SPI 21 IRQ_TYPE_LEVEL_HIGH>,
+			   <GIC_SPI 22 IRQ_TYPE_LEVEL_HIGH>,
+			   <GIC_SPI 23 IRQ_TYPE_LEVEL_HIGH>;
+	};
+
+	gpa4: gpa4-gpio-bank {
+		gpio-controller;
+		#gpio-cells = <2>;
+		interrupt-controller;
+		#interrupt-cells = <2>;
+		interrupt-parent = <&gic>;
+		interrupts = <GIC_SPI 24 IRQ_TYPE_LEVEL_HIGH>,
+			   <GIC_SPI 25 IRQ_TYPE_LEVEL_HIGH>,
+			   <GIC_SPI 26 IRQ_TYPE_LEVEL_HIGH>,
+			   <GIC_SPI 27 IRQ_TYPE_LEVEL_HIGH>;
+	};
+
+	gpa5: gpa5-gpio-bank  {
+		gpio-controller;
+		#gpio-cells = <2>;
+		interrupt-controller;
+		#interrupt-cells = <2>;
+		interrupts = <GIC_SPI 28 IRQ_TYPE_LEVEL_HIGH>,
+			   <GIC_SPI 29 IRQ_TYPE_LEVEL_HIGH>,
+			   <GIC_SPI 30 IRQ_TYPE_LEVEL_HIGH>,
+			   <GIC_SPI 31 IRQ_TYPE_LEVEL_HIGH>,
+			   <GIC_SPI 32 IRQ_TYPE_LEVEL_HIGH>,
+			   <GIC_SPI 33 IRQ_TYPE_LEVEL_HIGH>,
+			   <GIC_SPI 34 IRQ_TYPE_LEVEL_HIGH>;
+	};
+
+	gpa9: gpa9-gpio-bank  {
+		gpio-controller;
+		#gpio-cells = <2>;
+		interrupt-controller;
+		#interrupt-cells = <2>;
+		interrupts = <GIC_SPI 35 IRQ_TYPE_LEVEL_HIGH>,
+			   <GIC_SPI 36 IRQ_TYPE_LEVEL_HIGH>,
+			   <GIC_SPI 37 IRQ_TYPE_LEVEL_HIGH>,
+			   <GIC_SPI 38 IRQ_TYPE_LEVEL_HIGH>,
+			   <GIC_SPI 39 IRQ_TYPE_LEVEL_HIGH>,
+			   <GIC_SPI 40 IRQ_TYPE_LEVEL_HIGH>,
+			   <GIC_SPI 41 IRQ_TYPE_LEVEL_HIGH>,
+			   <GIC_SPI 42 IRQ_TYPE_LEVEL_HIGH>;
+	};
+
+	gpa10: gpa10-gpio-bank  {
+		gpio-controller;
+		#gpio-cells = <2>;
+		interrupt-controller;
+		#interrupt-cells = <2>;
+		interrupts = <GIC_SPI 43 IRQ_TYPE_LEVEL_HIGH>,
+			   <GIC_SPI 44 IRQ_TYPE_LEVEL_HIGH>;
+	};
+
+	uart15_bus: uart15-bus-pins {
+	       samsung,pins = "gpa2-3", "gpa2-4";
+	       samsung,pin-function = <2>;
+	       samsung,pin-pud = <0>;
+	};
+
+	uart16_bus: uart16-bus-pins {
+	       samsung,pins = "gpa3-0", "gpa3-1", "gpa3-2", "gpa3-3";
+	       samsung,pin-function = <GS101_PIN_FUNC_2>;
+	       samsung,pin-pud = <GS101_PIN_PULL_NONE>;
+	};
+
+	uart16_bus_rts: uart1-bus-rts-pins {
+		samsung,pins = "gpa3-2";
+		samsung,pin-function = <GS101_PIN_FUNC_OUTPUT>;
+		samsung,pin-pud = <GS101_PIN_PULL_NONE>;
+		samsung,pin-val = <1>;
+	};
+
+	uart16_bus_tx_dat: uart1-bus-tx-dat-pins {
+		samsung,pins = "gpa3-1";
+		samsung,pin-val = <1>;
+	};
+
+	uart16_bus_tx_con: uart1-bus-tx-con-pins {
+		samsung,pins = "gpa3-1";
+		samsung,pin-function = <1>;
+	};
+
+	uart17_bus: uart17-bus-pins {
+	       samsung,pins = "gpa4-0", "gpa4-1", "gpa4-2", "gpa4-3";
+	       samsung,pin-function = <2>;
+	       samsung,pin-pud = <0>;
+	};
+
+	spi15_bus: spi15-bus-pins {
+		samsung,pins = "gpa4-0", "gpa4-1", "gpa4-2";
+		samsung,pin-function = <GS101_PIN_FUNC_2>;
+		samsung,pin-pud = <GS101_PIN_PULL_NONE>;
+		samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
+	};
+
+	spi15_cs: spi15-cs-pins {
+		samsung,pins = "gpa4-3";
+		samsung,pin-function = <GS101_PIN_FUNC_OUTPUT>;
+		samsung,pin-pud = <GS101_PIN_PULL_NONE>;
+		samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
+	};
+};
+
+/* GPIO_FAR_ALIVE */
+&pinctrl_1 {
+	gpa6: gpa6-gpio-bank {
+		gpio-controller;
+		#gpio-cells = <2>;
+		interrupt-controller;
+		#interrupt-cells = <2>;
+		interrupt-parent = <&gic>;
+		interrupts = <GIC_SPI 45 IRQ_TYPE_LEVEL_HIGH>,
+			   <GIC_SPI 46 IRQ_TYPE_LEVEL_HIGH>,
+			   <GIC_SPI 47 IRQ_TYPE_LEVEL_HIGH>,
+			   <GIC_SPI 48 IRQ_TYPE_LEVEL_HIGH>,
+			   <GIC_SPI 49 IRQ_TYPE_LEVEL_HIGH>,
+			   <GIC_SPI 50 IRQ_TYPE_LEVEL_HIGH>,
+			   <GIC_SPI 51 IRQ_TYPE_LEVEL_HIGH>,
+			   <GIC_SPI 52 IRQ_TYPE_LEVEL_HIGH>;
+	};
+
+	gpa7: gpa7-gpio-bank {
+		gpio-controller;
+		#gpio-cells = <2>;
+		interrupt-controller;
+		#interrupt-cells = <2>;
+		interrupt-parent = <&gic>;
+		interrupts = <GIC_SPI 53 IRQ_TYPE_LEVEL_HIGH>,
+			   <GIC_SPI 54 IRQ_TYPE_LEVEL_HIGH>,
+			   <GIC_SPI 55 IRQ_TYPE_LEVEL_HIGH>,
+			   <GIC_SPI 56 IRQ_TYPE_LEVEL_HIGH>;
+	};
+
+	gpa8: gpa8-gpio-bank {
+		gpio-controller;
+		#gpio-cells = <2>;
+		interrupt-controller;
+		#interrupt-cells = <2>;
+		interrupt-parent = <&gic>;
+		interrupts = <GIC_SPI 57 IRQ_TYPE_LEVEL_HIGH>,
+			   <GIC_SPI 58 IRQ_TYPE_LEVEL_HIGH>,
+			   <GIC_SPI 59 IRQ_TYPE_LEVEL_HIGH>,
+			   <GIC_SPI 60 IRQ_TYPE_LEVEL_HIGH>,
+			   <GIC_SPI 61 IRQ_TYPE_LEVEL_HIGH>,
+			   <GIC_SPI 62 IRQ_TYPE_LEVEL_HIGH>,
+			   <GIC_SPI 63 IRQ_TYPE_LEVEL_HIGH>,
+			   <GIC_SPI 64 IRQ_TYPE_LEVEL_HIGH>;
+	};
+
+	gpa11: gpa11-gpio-bank {
+		gpio-controller;
+		#gpio-cells = <2>;
+		interrupt-controller;
+		#interrupt-cells = <2>;
+		interrupt-parent = <&gic>;
+		interrupts = <GIC_SPI 65 IRQ_TYPE_LEVEL_HIGH>,
+			   <GIC_SPI 66 IRQ_TYPE_LEVEL_HIGH>;
+	};
+};
+
+/* GPIO_GSACORE */
+&pinctrl_2 {
+	gps0: gps0-gpio-bank {
+		gpio-controller;
+		#gpio-cells = <2>;
+		interrupt-controller;
+		#interrupt-cells = <2>;
+	};
+
+	gps1: gps1-gpio-bank {
+		gpio-controller;
+		#gpio-cells = <2>;
+		interrupt-controller;
+		#interrupt-cells = <2>;
+	};
+
+	gps2: gps2-gpio-bank {
+		gpio-controller;
+		#gpio-cells = <2>;
+		interrupt-controller;
+		#interrupt-cells = <2>;
+	};
+};
+
+/* GPIO_GSACTRL */
+&pinctrl_3 {
+	gps3: gps3-gpio-bank {
+		gpio-controller;
+		#gpio-cells = <2>;
+		interrupt-controller;
+		#interrupt-cells = <2>;
+	};
+};
+
+/* GPIO_HSI1 */
+&pinctrl_6 {
+	gph0: gph0-gpio-bank {
+		gpio-controller;
+		#gpio-cells = <2>;
+		interrupt-controller;
+		#interrupt-cells = <2>;
+	};
+
+	gph1: gph1-gpio-bank {
+		gpio-controller;
+		#gpio-cells = <2>;
+		interrupt-controller;
+		#interrupt-cells = <2>;
+	};
+
+	pcie0_clkreq: pcie0-clkreq-pins{
+		samsung,pins = "gph0-1";
+		samsung,pin-function = <2>;
+		samsung,pin-pud = <3>;
+		samsung,pin-drv = <GS101_PIN_DRV_10_MA>;
+		samsung,pin-con-pdn = <3>;
+		samsung,pin-pud-pdn = <3>;
+	};
+
+	pcie0_perst: pcie0-perst-pins {
+		samsung,pins = "gph0-0";
+		samsung,pin-function = <1>;
+		samsung,pin-drv = <GS101_PIN_DRV_10_MA>;
+		samsung,pin-con-pdn = <3>;
+	};
+};
+
+/* GPIO_HSI2 */
+&pinctrl_7 {
+	gph2: gph2-gpio-bank {
+		gpio-controller;
+		#gpio-cells = <2>;
+		interrupt-controller;
+		#interrupt-cells = <2>;
+	};
+
+	gph3: gph3-gpio-bank {
+		gpio-controller;
+		#gpio-cells = <2>;
+		interrupt-controller;
+		#interrupt-cells = <2>;
+	};
+
+	gph4: gph4-gpio-bank {
+		gpio-controller;
+		#gpio-cells = <2>;
+		interrupt-controller;
+		#interrupt-cells = <2>;
+	};
+
+	sd2_clk: sd2-clk-pins {
+		samsung,pins = "gph4-0";
+		samsung,pin-function = <2>;
+		samsung,pin-pud = <0>;
+		samsung,pin-drv = <GS101_PIN_DRV_7_5_MA>;
+	};
+
+	sd2_cmd: sd2-cmd-pins {
+		samsung,pins = "gph4-1";
+		samsung,pin-function = <2>;
+		samsung,pin-pud = <3>;
+		samsung,pin-drv = <GS101_PIN_DRV_7_5_MA>;
+	};
+
+	sd2_bus1: sd2-bus-width1-pins {
+		samsung,pins = "gph4-2";
+		samsung,pin-function = <2>;
+		samsung,pin-pud = <3>;
+		samsung,pin-drv = <GS101_PIN_DRV_7_5_MA>;
+	};
+
+	sd2_bus4: sd2-bus-width4-pins {
+		samsung,pins = "gph4-3", "gph4-4", "gph4-5";
+		samsung,pin-function = <2>;
+		samsung,pin-pud = <3>;
+		samsung,pin-drv = <GS101_PIN_DRV_7_5_MA>;
+	};
+
+	sd2_clk_fast_slew_rate_1x: sd2-clk-fast-slew-rate-1x-pins {
+		samsung,pins = "gph4-0";
+		samsung,pin-function = <2>;
+		samsung,pin-pud = <0>;
+		samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
+	};
+
+	sd2_clk_fast_slew_rate_2x: sd2-clk-fast-slew-rate-2x-pins {
+		samsung,pins = "gph4-0";
+		samsung,pin-function = <2>;
+		samsung,pin-pud = <0>;
+		samsung,pin-drv = <GS101_PIN_DRV_5_MA>;
+	};
+
+	sd2_clk_fast_slew_rate_3x: sd2-clk-fast-slew-rate-3x-pins {
+		samsung,pins = "gph4-0";
+		samsung,pin-function = <2>;
+		samsung,pin-pud = <0>;
+		samsung,pin-drv = <GS101_PIN_DRV_7_5_MA>;
+	};
+
+	sd2_clk_fast_slew_rate_4x: sd2-clk-fast-slew-rate-4x-pins {
+		samsung,pins = "gph4-0";
+		samsung,pin-function = <2>;
+		samsung,pin-pud = <0>;
+		samsung,pin-drv = <GS101_PIN_DRV_10_MA>;
+	};
+
+	ufs_rst_n: ufs-rst-n-pins {
+		samsung,pins = "gph3-1";
+		samsung,pin-function = <2>;
+		samsung,pin-pud = <0>;
+		samsung,pin-con-pdn = <3>;
+		samsung,pin-pud-pdn = <0>;
+	};
+
+	ufs_refclk_out: ufs-refclk-out-pins {
+		samsung,pins = "gph3-0";
+		samsung,pin-function = <2>;
+		samsung,pin-pud = <0>;
+		samsung,pin-con-pdn = <3>;
+		samsung,pin-pud-pdn = <0>;
+	};
+
+	pcie1_clkreq: pcie1-clkreq-pins {
+		samsung,pins = "gph2-1";
+		samsung,pin-function = <2>;
+		samsung,pin-pud = <3>;
+		samsung,pin-drv = <GS101_PIN_DRV_10_MA>;
+		samsung,pin-con-pdn = <3>;
+		samsung,pin-pud-pdn = <3>;
+	};
+
+	pcie1_perst: pcie1-perst-pins {
+		samsung,pins = "gph2-0";
+		samsung,pin-function = <1>;
+		samsung,pin-drv = <GS101_PIN_DRV_10_MA>;
+		samsung,pin-con-pdn = <3>;
+	};
+};
+
+/* GPIO_PERIC0 */
+&pinctrl_4 {
+	gpp0: gpp0-gpio-bank {
+		gpio-controller;
+		#gpio-cells = <2>;
+		interrupt-controller;
+		#interrupt-cells = <2>;
+	};
+
+	gpp1: gpp1-gpio-bank {
+		gpio-controller;
+		#gpio-cells = <2>;
+		interrupt-controller;
+		#interrupt-cells = <2>;
+	};
+
+	gpp2: gpp2-gpio-bank {
+		gpio-controller;
+		#gpio-cells = <2>;
+		interrupt-controller;
+		#interrupt-cells = <2>;
+	};
+
+	gpp3: gpp3-gpio-bank {
+		gpio-controller;
+		#gpio-cells = <2>;
+		interrupt-controller;
+		#interrupt-cells = <2>;
+	};
+
+	gpp4: gpp4-gpio-bank {
+		gpio-controller;
+		#gpio-cells = <2>;
+		interrupt-controller;
+		#interrupt-cells = <2>;
+	};
+
+	gpp5: gpp5-gpio-bank {
+		gpio-controller;
+		#gpio-cells = <2>;
+		interrupt-controller;
+		#interrupt-cells = <2>;
+	};
+
+	gpp6: gpp6-gpio-bank {
+		gpio-controller;
+		#gpio-cells = <2>;
+		interrupt-controller;
+		#interrupt-cells = <2>;
+	};
+
+	gpp7: gpp7-gpio-bank {
+		gpio-controller;
+		#gpio-cells = <2>;
+		interrupt-controller;
+		#interrupt-cells = <2>;
+	};
+
+	gpp8: gpp8-gpio-bank {
+		gpio-controller;
+		#gpio-cells = <2>;
+		interrupt-controller;
+		#interrupt-cells = <2>;
+	};
+
+	gpp9: gpp9-gpio-bank {
+		gpio-controller;
+		#gpio-cells = <2>;
+		interrupt-controller;
+		#interrupt-cells = <2>;
+	};
+
+	gpp10: gpp10-gpio-bank {
+		gpio-controller;
+		#gpio-cells = <2>;
+		interrupt-controller;
+		#interrupt-cells = <2>;
+	};
+
+	gpp11: gpp11-gpio-bank {
+		gpio-controller;
+		#gpio-cells = <2>;
+		interrupt-controller;
+		#interrupt-cells = <2>;
+	};
+
+	gpp12: gpp12-gpio-bank {
+		gpio-controller;
+		#gpio-cells = <2>;
+		interrupt-controller;
+		#interrupt-cells = <2>;
+	};
+
+	gpp13: gpp13-gpio-bank {
+		gpio-controller;
+		#gpio-cells = <2>;
+		interrupt-controller;
+		#interrupt-cells = <2>;
+	};
+
+	gpp14: gpp14-gpio-bank {
+		gpio-controller;
+		#gpio-cells = <2>;
+		interrupt-controller;
+		#interrupt-cells = <2>;
+	};
+
+	gpp15: gpp15-gpio-bank {
+		gpio-controller;
+		#gpio-cells = <2>;
+		interrupt-controller;
+		#interrupt-cells = <2>;
+	};
+
+	gpp16: gpp16-gpio-bank {
+		gpio-controller;
+		#gpio-cells = <2>;
+		interrupt-controller;
+		#interrupt-cells = <2>;
+	};
+
+	gpp17: gpp17-gpio-bank {
+		gpio-controller;
+		#gpio-cells = <2>;
+		interrupt-controller;
+		#interrupt-cells = <2>;
+	};
+
+	gpp18: gpp18-gpio-bank {
+		gpio-controller;
+		#gpio-cells = <2>;
+		interrupt-controller;
+		#interrupt-cells = <2>;
+	};
+
+	gpp19: gpp19-gpio-bank {
+		gpio-controller;
+		#gpio-cells = <2>;
+		interrupt-controller;
+		#interrupt-cells = <2>;
+	};
+
+	/* USI_PERIC0_UART_DBG */
+	uart0_bus: uart0-bus-pins {
+		samsung,pins = "gpp1-2", "gpp1-3";
+		samsung,pin-function = <2>;
+		samsung,pin-pud = <0>;
+	};
+
+	disp_te_pri_on: disp-te-pri-on-pins {
+		samsung,pins = "gpp0-3";
+		samsung,pin-function = <0xf>;
+	};
+
+	disp_te_pri_off: disp-te-pri-off-pins {
+		samsung,pins = "gpp0-3";
+		samsung,pin-function = <0>;
+	};
+
+	disp_te_sec_on: disp-te-sec-on-pins {
+		samsung,pins = "gpp0-4";
+		samsung,pin-function = <0xf>;
+	};
+
+	disp_te_sec_off: disp-te-sec-off-pins {
+		samsung,pins = "gpp0-4";
+		samsung,pin-function = <0>;
+	};
+
+	sensor_mclk1_out: sensor-mclk1-out-pins {
+		samsung,pins = "gpp3-0";
+		samsung,pin-function = <GS101_PIN_FUNC_OUTPUT>;
+		samsung,pin-pud = <GS101_PIN_PULL_DOWN>;
+		samsung,pin-drv = <GS101_PIN_DRV_5_MA>;
+	};
+
+	sensor_mclk1_fn: sensor-mclk1-fn-pins {
+		samsung,pins = "gpp3-0";
+		samsung,pin-function = <GS101_PIN_FUNC_2>;
+		samsung,pin-pud = <GS101_PIN_PULL_NONE>;
+		samsung,pin-drv = <GS101_PIN_DRV_5_MA>;
+	};
+
+	sensor_mclk2_out: sensor-mclk2-out-pins {
+		samsung,pins = "gpp5-0";
+		samsung,pin-function = <GS101_PIN_FUNC_OUTPUT>;
+		samsung,pin-pud = <GS101_PIN_PULL_DOWN>;
+		samsung,pin-drv = <GS101_PIN_DRV_5_MA>;
+	};
+
+	sensor_mclk2_fn: sensor-mclk2-fn-pins {
+		samsung,pins = "gpp5-0";
+		samsung,pin-function = <GS101_PIN_FUNC_2>;
+		samsung,pin-pud = <GS101_PIN_PULL_NONE>;
+		samsung,pin-drv = <GS101_PIN_DRV_5_MA>;
+	};
+
+	sensor_mclk3_out: sensor-mclk3-out-pins {
+		samsung,pins = "gpp7-0";
+		samsung,pin-function = <GS101_PIN_FUNC_OUTPUT>;
+		samsung,pin-pud = <GS101_PIN_PULL_DOWN>;
+		samsung,pin-drv = <GS101_PIN_DRV_5_MA>;
+	};
+
+	sensor_mclk3_fn: sensor-mclk3-fn-pins {
+		samsung,pins = "gpp7-0";
+		samsung,pin-function = <GS101_PIN_FUNC_2>;
+		samsung,pin-pud = <GS101_PIN_PULL_NONE>;
+		samsung,pin-drv = <GS101_PIN_DRV_5_MA>;
+	};
+
+	sensor_mclk4_out: sensor-mclk4-out-pins {
+		samsung,pins = "gpp9-0";
+		samsung,pin-function = <GS101_PIN_FUNC_OUTPUT>;
+		samsung,pin-pud = <GS101_PIN_PULL_DOWN>;
+		samsung,pin-drv = <GS101_PIN_DRV_5_MA>;
+	};
+
+	sensor_mclk4_fn: sensor-mclk4-fn-pins {
+		samsung,pins = "gpp9-0";
+		samsung,pin-function = <GS101_PIN_FUNC_2>;
+		samsung,pin-pud = <GS101_PIN_PULL_NONE>;
+		samsung,pin-drv = <GS101_PIN_DRV_5_MA>;
+	};
+
+	sensor_mclk5_out: sensor-mclk5-out-pins {
+		samsung,pins = "gpp11-0";
+		samsung,pin-function = <GS101_PIN_FUNC_OUTPUT>;
+		samsung,pin-pud = <GS101_PIN_PULL_DOWN>;
+		samsung,pin-drv = <GS101_PIN_DRV_5_MA>;
+	};
+
+	sensor_mclk5_fn: sensor-mclk5-fn-pins {
+		samsung,pins = "gpp11-0";
+		samsung,pin-function = <GS101_PIN_FUNC_2>;
+		samsung,pin-pud = <GS101_PIN_PULL_NONE>;
+		samsung,pin-drv = <GS101_PIN_DRV_5_MA>;
+	};
+
+	sensor_mclk6_out: sensor-mclk6-out-pins {
+		samsung,pins = "gpp13-0";
+		samsung,pin-function = <GS101_PIN_FUNC_OUTPUT>;
+		samsung,pin-pud = <GS101_PIN_PULL_DOWN>;
+		samsung,pin-drv = <GS101_PIN_DRV_5_MA>;
+	};
+
+	sensor_mclk6_fn: sensor-mclk6-fn-pins {
+		samsung,pins = "gpp13-0";
+		samsung,pin-function = <GS101_PIN_FUNC_2>;
+		samsung,pin-pud = <GS101_PIN_PULL_NONE>;
+		samsung,pin-drv = <GS101_PIN_DRV_5_MA>;
+	};
+
+	sensor_mclk7_out: sensor-mclk7-out-pins {
+		samsung,pins = "gpp15-0";
+		samsung,pin-function = <GS101_PIN_FUNC_OUTPUT>;
+		samsung,pin-pud = <GS101_PIN_PULL_DOWN>;
+		samsung,pin-drv = <GS101_PIN_DRV_5_MA>;
+	};
+
+	sensor_mclk7_fn: sensor-mclk7-fn-pins {
+		samsung,pins = "gpp15-0";
+		samsung,pin-function = <GS101_PIN_FUNC_2>;
+		samsung,pin-pud = <GS101_PIN_PULL_NONE>;
+		samsung,pin-drv = <GS101_PIN_DRV_5_MA>;
+	};
+
+	sensor_mclk8_out: sensor-mclk8-out-pins {
+		samsung,pins = "gpp17-0";
+		samsung,pin-function = <GS101_PIN_FUNC_OUTPUT>;
+		samsung,pin-pud = <GS101_PIN_PULL_DOWN>;
+		samsung,pin-drv = <GS101_PIN_DRV_5_MA>;
+	};
+
+	sensor_mclk8_fn: sensor-mclk8-fn-pins {
+		samsung,pins = "gpp17-0";
+		samsung,pin-function = <GS101_PIN_FUNC_2>;
+		samsung,pin-pud = <GS101_PIN_PULL_NONE>;
+		samsung,pin-drv = <GS101_PIN_DRV_5_MA>;
+	};
+
+	hsi2c14_bus: hsi2c14-bus-pins {
+		samsung,pins = "gpp18-0", "gpp18-1";
+		samsung,pin-function = <2>;
+		samsung,pin-pud = <0>;
+		samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
+	};
+
+	uart14_bus_single: uart14-bus-pins {
+		samsung,pins = "gpp18-0", "gpp18-1",
+			       "gpp18-2", "gpp18-3";
+		samsung,pin-function = <2>;
+		samsung,pin-pud = <0>;
+	};
+
+	spi14_bus: spi14-bus-pins {
+		samsung,pins = "gpp18-0", "gpp18-1", "gpp18-2";
+		samsung,pin-function = <2>;
+		samsung,pin-pud = <0>;
+		samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
+	};
+
+	spi14_cs: spi14-cs-pins {
+		samsung,pins = "gpp18-3";
+		samsung,pin-function = <1>;
+		samsung,pin-pud = <0>;
+		samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
+	};
+
+	spi14_cs_func: spi14-cs-func-pins {
+		samsung,pins = "gpp18-3";
+		samsung,pin-function = <2>;
+		samsung,pin-pud = <0>;
+		samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
+	};
+
+	hsi2c8_bus: hsi2c8-bus-pins {
+		samsung,pins = "gpp16-0", "gpp16-1";
+		samsung,pin-function = <GS101_PIN_FUNC_3>;
+		samsung,pin-pud = <GS101_PIN_PULL_NONE>;
+		samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
+		samsung,pin-pud-pdn = <GS101_PIN_PDN_OUT0>;
+	};
+
+	uart8_bus_single: uart8-bus-pins {
+		samsung,pins = "gpp16-0", "gpp16-1", "gpp16-2",
+			       "gpp16-3";
+		samsung,pin-function = <3>;
+		samsung,pin-pud = <0>;
+	};
+
+	spi8_bus: spi8-bus-pins {
+		samsung,pins = "gpp16-0", "gpp16-1", "gpp16-2";
+		samsung,pin-function = <3>;
+		samsung,pin-pud = <0>;
+		samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
+	};
+
+	spi8_cs: spi8-cs-pins {
+		samsung,pins = "gpp16-3";
+		samsung,pin-function = <1>;
+		samsung,pin-pud = <0>;
+		samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
+	};
+
+	spi8_cs_func: spi8-cs-func-pins {
+		samsung,pins = "gpp16-3";
+		samsung,pin-function = <3>;
+		samsung,pin-pud = <0>;
+		samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
+	};
+
+	hsi2c7_bus: hsi2c7-bus-pins {
+		samsung,pins = "gpp14-0", "gpp14-1";
+		samsung,pin-function = <3>;
+		samsung,pin-pud = <0>;
+		samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
+	};
+
+	uart7_bus_single: uart7-bus-pins {
+		samsung,pins = "gpp14-0", "gpp14-1",
+			       "gpp14-2", "gpp14-3";
+		samsung,pin-function = <3>;
+		samsung,pin-pud = <0>;
+	};
+
+	spi7_bus: spi7-bus-pins {
+		samsung,pins = "gpp14-0", "gpp14-1", "gpp14-2";
+		samsung,pin-function = <3>;
+		samsung,pin-pud = <0>;
+		samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
+	};
+
+	spi7_cs: spi7-cs-pins {
+		samsung,pins = "gpp14-3";
+		samsung,pin-function = <1>;
+		samsung,pin-pud = <0>;
+		samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
+	};
+
+	spi7_cs_func: spi7-cs-func-pins {
+		samsung,pins = "gpp14-3";
+		samsung,pin-function = <3>;
+		samsung,pin-pud = <0>;
+		samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
+	};
+
+	hsi2c6_bus: hsi2c6-bus-pins {
+		samsung,pins = "gpp12-0", "gpp12-1";
+		samsung,pin-function = <3>;
+		samsung,pin-pud = <0>;
+		samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
+	};
+
+	uart6_bus_single: uart6-bus-pins {
+		samsung,pins = "gpp12-0", "gpp12-1",
+			       "gpp12-2", "gpp12-3";
+		samsung,pin-function = <3>;
+		samsung,pin-pud = <0>;
+	};
+
+	spi6_bus: spi6-bus-pins {
+		samsung,pins = "gpp12-0", "gpp12-1", "gpp12-2";
+		samsung,pin-function = <3>;
+		samsung,pin-pud = <0>;
+		samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
+	};
+
+	spi6_cs: spi6-cs-pins {
+		samsung,pins = "gpp12-3";
+		samsung,pin-function = <1>;
+		samsung,pin-pud = <0>;
+		samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
+	};
+
+	spi6_cs_func: spi6-cs-func-pins {
+		samsung,pins = "gpp12-3";
+		samsung,pin-function = <3>;
+		samsung,pin-pud = <0>;
+		samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
+	};
+
+	hsi2c5_bus: hsi2c5-bus-pins {
+		samsung,pins = "gpp10-0", "gpp10-1";
+		samsung,pin-function = <3>;
+		samsung,pin-pud = <0>;
+		samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
+	};
+
+	uart5_bus_single: uart5-bus-pins {
+		samsung,pins = "gpp10-0", "gpp10-1",
+			       "gpp10-2", "gpp10-3";
+		samsung,pin-function = <3>;
+		samsung,pin-pud = <0>;
+	};
+
+	spi5_bus: spi5-bus-pins {
+		samsung,pins = "gpp10-0", "gpp10-1", "gpp10-2";
+		samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
+		samsung,pin-function = <GS101_PIN_FUNC_3>;
+		samsung,pin-pud = <GS101_PIN_PULL_NONE>;
+		samsung,pin-con-pdn = <GS101_PIN_PDN_PREV>;
+		samsung,pin-pud-pdn = <GS101_PIN_PULL_NONE>;
+	};
+
+	spi5_cs_func: spi5-cs-func-pins {
+		samsung,pins = "gpp10-3";
+		samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
+		samsung,pin-function = <GS101_PIN_FUNC_3>;
+		samsung,pin-pud = <GS101_PIN_PULL_NONE>;
+		samsung,pin-con-pdn = <GS101_PIN_PDN_PREV>;
+		samsung,pin-pud-pdn = <GS101_PIN_PULL_NONE>;
+	};
+
+	hsi2c4_bus: hsi2c4-bus-pins {
+		samsung,pins = "gpp8-0", "gpp8-1";
+		samsung,pin-function = <3>;
+		samsung,pin-pud = <0>;
+		samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
+	};
+
+	uart4_bus_single: uart4-bus-pins {
+		samsung,pins = "gpp8-0", "gpp8-1",
+			       "gpp8-2", "gpp8-3";
+		samsung,pin-function = <3>;
+		samsung,pin-pud = <0>;
+	};
+
+	spi4_bus: spi4-bus-pins {
+		samsung,pins = "gpp8-0", "gpp8-1", "gpp8-2";
+		samsung,pin-function = <3>;
+		samsung,pin-pud = <0>;
+		samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
+	};
+
+	spi4_cs: spi4-cs-pins {
+		samsung,pins = "gpp8-3";
+		samsung,pin-function = <1>;
+		samsung,pin-pud = <0>;
+		samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
+	};
+
+	spi4_cs_func: spi4-cs-func-pins {
+		samsung,pins = "gpp8-3";
+		samsung,pin-function = <3>;
+		samsung,pin-pud = <0>;
+		samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
+	};
+
+	hsi2c3_bus: hsi2c3-bus-pins {
+		samsung,pins = "gpp6-0", "gpp6-1";
+		samsung,pin-function = <3>;
+		samsung,pin-pud = <0>;
+		samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
+	};
+
+	uart3_bus_single: uart3-bus-pins {
+		samsung,pins = "gpp6-0", "gpp6-1",
+			       "gpp6-2", "gpp6-3";
+		samsung,pin-function = <3>;
+		samsung,pin-pud = <0>;
+	};
+
+	spi3_bus: spi3-bus-pins {
+		samsung,pins = "gpp6-0", "gpp6-1", "gpp6-2";
+		samsung,pin-function = <3>;
+		samsung,pin-pud = <0>;
+		samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
+	};
+
+	spi3_cs: spi3-cs-pins {
+		samsung,pins = "gpp6-3";
+		samsung,pin-function = <1>;
+		samsung,pin-pud = <0>;
+		samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
+	};
+
+	spi3_cs_func: spi3-cs-func-pins {
+		samsung,pins = "gpp6-3";
+		samsung,pin-function = <3>;
+		samsung,pin-pud = <0>;
+		samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
+	};
+
+	hsi2c2_bus: hsi2c2-bus-pins {
+		samsung,pins = "gpp4-0", "gpp4-1";
+		samsung,pin-function = <3>;
+		samsung,pin-pud = <0>;
+		samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
+	};
+
+	uart2_bus_single: uart2-bus-pins {
+		samsung,pins = "gpp4-0", "gpp4-1",
+			       "gpp4-2", "gpp4-3";
+		samsung,pin-function = <3>;
+		samsung,pin-pud = <0>;
+	};
+
+	spi2_bus: spi2-bus-pins {
+		samsung,pins = "gpp4-0", "gpp4-1", "gpp4-2";
+		samsung,pin-function = <3>;
+		samsung,pin-pud = <0>;
+		samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
+	};
+
+	spi2_cs: spi2-cs-pins {
+		samsung,pins = "gpp4-3";
+		samsung,pin-function = <1>;
+		samsung,pin-pud = <0>;
+		samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
+	};
+
+	spi2_cs_func: spi2-cs-func-pins {
+		samsung,pins = "gpp4-3";
+		samsung,pin-function = <3>;
+		samsung,pin-pud = <0>;
+		samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
+	};
+
+	hsi2c1_bus: hsi2c1-bus-pins {
+		samsung,pins = "gpp2-0", "gpp2-1";
+		samsung,pin-function = <3>;
+		samsung,pin-pud = <0>;
+		samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
+	};
+
+	uart1_bus_single: uart1-bus-pins {
+		samsung,pins = "gpp2-0", "gpp2-1",
+			       "gpp2-2", "gpp2-3";
+		samsung,pin-function = <3>;
+		samsung,pin-pud = <0>;
+	};
+
+	spi1_bus: spi1-bus-pins {
+		samsung,pins = "gpp2-0", "gpp2-1", "gpp2-2";
+		samsung,pin-function = <3>;
+		samsung,pin-pud = <0>;
+		samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
+	};
+
+	spi1_cs: spi1-cs-pins {
+		samsung,pins = "gpp2-3";
+		samsung,pin-function = <1>;
+		samsung,pin-pud = <0>;
+		samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
+	};
+
+	spi1_cs_func: spi1-cs-func-pins {
+		samsung,pins = "gpp2-3";
+		samsung,pin-function = <3>;
+		samsung,pin-pud = <0>;
+		samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
+	};
+};
+
+/* GPIO_PERIC1 */
+&pinctrl_5 {
+	gpp20: gpp20-gpio-bank {
+		gpio-controller;
+		#gpio-cells = <2>;
+		interrupt-controller;
+		#interrupt-cells = <2>;
+	};
+
+	gpp21: gpp21-gpio-bank {
+		gpio-controller;
+		#gpio-cells = <2>;
+		interrupt-controller;
+		#interrupt-cells = <2>;
+	};
+
+	gpp22: gpp22-gpio-bank {
+		gpio-controller;
+		#gpio-cells = <2>;
+		interrupt-controller;
+		#interrupt-cells = <2>;
+	};
+
+	gpp23: gpp23-gpio-bank {
+		gpio-controller;
+		#gpio-cells = <2>;
+		interrupt-controller;
+		#interrupt-cells = <2>;
+	};
+
+	gpp24: gpp24-gpio-bank {
+		gpio-controller;
+		#gpio-cells = <2>;
+		interrupt-controller;
+		#interrupt-cells = <2>;
+	};
+
+	gpp25: gpp25-gpio-bank {
+		gpio-controller;
+		#gpio-cells = <2>;
+		interrupt-controller;
+		#interrupt-cells = <2>;
+	};
+
+	gpp26: gpp26-gpio-bank {
+		gpio-controller;
+		#gpio-cells = <2>;
+		interrupt-controller;
+		#interrupt-cells = <2>;
+	};
+
+	gpp27: gpp27-gpio-bank {
+		gpio-controller;
+		#gpio-cells = <2>;
+		interrupt-controller;
+		#interrupt-cells = <2>;
+	};
+
+	hsi2c13_bus: hsi2c13-bus-pins  {
+		samsung,pins = "gpp25-0", "gpp25-1";
+		samsung,pin-function = <2>;
+		samsung,pin-pud = <0>;
+		samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
+	};
+
+	uart13_bus_single: uart13-bus-pins {
+	       samsung,pins = "gpp25-0", "gpp25-1",
+			      "gpp25-2", "gpp25-3";
+	       samsung,pin-function = <2>;
+	       samsung,pin-pud = <0>;
+	};
+
+	spi13_bus: spi13-bus-pins {
+		samsung,pins = "gpp25-0", "gpp25-1", "gpp25-2";
+		samsung,pin-function = <2>;
+		samsung,pin-pud = <0>;
+		samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
+	};
+
+	spi13_cs: spi13-cs-pins {
+		samsung,pins = "gpp25-3";
+		samsung,pin-function = <1>;
+		samsung,pin-pud = <0>;
+		samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
+	};
+
+	spi13_cs_func: spi13-cs-func-pins {
+		samsung,pins = "gpp25-3";
+		samsung,pin-function = <2>;
+		samsung,pin-pud = <0>;
+		samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
+	};
+
+	hsi2c12_bus: hsi2c12-bus-pins {
+		samsung,pins = "gpp23-4", "gpp23-5";
+		samsung,pin-function = <2>;
+		samsung,pin-pud = <0>;
+		samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
+	};
+
+	uart12_bus_single: uart12-bus-pins {
+		samsung,pins = "gpp23-4", "gpp23-5",
+			       "gpp23-6", "gpp23-7";
+		samsung,pin-function = <2>;
+		samsung,pin-pud = <0>;
+	};
+
+	spi12_bus: spi12-bus-pins {
+		samsung,pins = "gpp23-4", "gpp23-5", "gpp23-6";
+		samsung,pin-function = <2>;
+		samsung,pin-pud = <0>;
+		samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
+	};
+
+	spi14_cs2: spi14-cs2-pins {
+		samsung,pins = "gpp23-6";
+		samsung,pin-function = <GS101_PIN_FUNC_OUTPUT>;
+		samsung,pin-pud = <GS101_PIN_PULL_NONE>;
+		samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
+	};
+
+	spi12_cs: spi12-cs-pins {
+		samsung,pins = "gpp23-7";
+		samsung,pin-function = <1>;
+		samsung,pin-pud = <0>;
+		samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
+	};
+
+	spi12_cs_func: spi12-cs-func-pins {
+		samsung,pins = "gpp23-7";
+		samsung,pin-function = <2>;
+		samsung,pin-pud = <0>;
+		samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
+	};
+
+	hsi2c11_bus: hsi2c11-bus-pins {
+		samsung,pins = "gpp23-0", "gpp23-1";
+		samsung,pin-function = <2>;
+		samsung,pin-pud = <0>;
+		samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
+	};
+
+	uart11_bus_single: uart11-bus-pins {
+		samsung,pins = "gpp23-0", "gpp23-1",
+			       "gpp23-2", "gpp23-3";
+		samsung,pin-function = <2>;
+		samsung,pin-pud = <0>;
+	};
+
+	spi11_bus: spi11-bus-pins {
+		samsung,pins = "gpp23-0", "gpp23-1", "gpp23-2";
+		samsung,pin-function = <2>;
+		samsung,pin-pud = <0>;
+		samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
+	};
+
+	spi11_cs: spi11-cs-pins {
+		samsung,pins = "gpp23-3";
+		samsung,pin-function = <1>;
+		samsung,pin-pud = <0>;
+		samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
+	};
+
+	spi11_cs_func: spi11-cs-func-pins {
+		samsung,pins = "gpp23-3";
+		samsung,pin-function = <2>;
+		samsung,pin-pud = <0>;
+		samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
+	};
+
+	hsi2c10_bus: hsi2c10-bus-pins {
+		samsung,pins = "gpp21-0", "gpp21-1";
+		samsung,pin-function = <2>;
+		samsung,pin-pud = <0>;
+		samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
+	};
+
+	uart10_bus_single: uart10-bus-pins {
+		samsung,pins = "gpp21-0", "gpp21-1",
+			       "gpp21-2", "gpp21-3";
+		samsung,pin-function = <2>;
+		samsung,pin-pud = <0>;
+	};
+
+	spi10_bus: spi10-bus-pins {
+		samsung,pins = "gpp21-0", "gpp21-1", "gpp21-2";
+		samsung,pin-function = <2>;
+		samsung,pin-pud = <0>;
+		samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
+	};
+
+	spi10_cs: spi10-cs-pins {
+		samsung,pins = "gpp21-3";
+		samsung,pin-function = <1>;
+		samsung,pin-pud = <0>;
+		samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
+	};
+
+	spi10_cs_func: spi10-cs-func-pins {
+		samsung,pins = "gpp21-3";
+		samsung,pin-function = <2>;
+		samsung,pin-pud = <0>;
+		samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
+	};
+
+	hsi2c9_bus: hsi2c9-bus-pins {
+		samsung,pins = "gpp20-4", "gpp20-5";
+		samsung,pin-function = <2>;
+		samsung,pin-pud = <0>;
+		samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
+	};
+
+	uart9_bus_single: uart9-bus-pins {
+		samsung,pins = "gpp20-4", "gpp20-5",
+			       "gpp20-6", "gpp20-7";
+		samsung,pin-function = <2>;
+		samsung,pin-pud = <0>;
+	};
+
+	spi9_bus: spi9-bus-pins {
+		samsung,pins = "gpp20-4", "gpp20-5", "gpp20-6";
+		samsung,pin-function = <2>;
+		samsung,pin-pud = <0>;
+		samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
+	};
+
+	spi9_cs: spi9-cs-pins {
+		samsung,pins = "gpp20-7";
+		samsung,pin-function = <1>;
+		samsung,pin-pud = <0>;
+		samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
+	};
+
+	spi9_cs_func: spi9-cs-func-pins {
+		samsung,pins = "gpp20-7";
+		samsung,pin-function = <2>;
+		samsung,pin-pud = <0>;
+		samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
+	};
+
+	hsi2c0_bus: hsi2c0-bus-pins {
+		samsung,pins = "gpp20-0", "gpp20-1";
+		samsung,pin-function = <3>;
+		samsung,pin-pud = <0>;
+		samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
+	};
+
+	uart0_bus_single: uart0-bus-pins {
+		samsung,pins = "gpp20-0", "gpp20-1",
+			       "gpp20-2", "gpp20-3";
+		samsung,pin-function = <3>;
+		samsung,pin-pud = <0>;
+	};
+
+	spi0_bus: spi0-bus-pins {
+		samsung,pins = "gpp20-0", "gpp20-1", "gpp20-2";
+		samsung,pin-function = <3>;
+		samsung,pin-pud = <0>;
+		samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
+	};
+
+	spi0_cs: spi0-cs-pins {
+		samsung,pins = "gpp20-3";
+		samsung,pin-function = <1>;
+		samsung,pin-pud = <0>;
+		samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
+	};
+
+	spi0_cs_func: spi0-cs-func-pins {
+		samsung,pins = "gpp20-3";
+		samsung,pin-function = <3>;
+		samsung,pin-pud = <0>;
+		samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
+	};
+};
+
diff --git a/arch/arm64/boot/dts/google/gs101-pinctrl.h b/arch/arm64/boot/dts/google/gs101-pinctrl.h
new file mode 100644
index 000000000000..16c54888f4bb
--- /dev/null
+++ b/arch/arm64/boot/dts/google/gs101-pinctrl.h
@@ -0,0 +1,32 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/*
+ * Pinctrl binding constants for GS101
+ *
+ * Copyright (c) 2020-2023 Google, LLC.
+ */
+
+#ifndef __DT_BINDINGS_PINCTRL_GS101_H__
+#define __DT_BINDINGS_PINCTRL_GS101_H__
+
+#define GS101_PIN_PULL_NONE		0
+#define GS101_PIN_PULL_DOWN		1
+#define GS101_PIN_PULL_UP		3
+
+/* Pin function in power down mode */
+#define GS101_PIN_PDN_OUT0		0
+#define GS101_PIN_PDN_OUT1		1
+#define GS101_PIN_PDN_INPUT		2
+#define GS101_PIN_PDN_PREV		3
+
+/* GS101 drive strengths */
+#define GS101_PIN_DRV_2_5_MA		0
+#define GS101_PIN_DRV_5_MA		1
+#define GS101_PIN_DRV_7_5_MA		2
+#define GS101_PIN_DRV_10_MA		3
+
+#define GS101_PIN_FUNC_INPUT		0
+#define GS101_PIN_FUNC_OUTPUT		1
+#define GS101_PIN_FUNC_2		2
+#define GS101_PIN_FUNC_3		3
+
+#endif /* __DT_BINDINGS_PINCTRL_GS101_H__ */
diff --git a/arch/arm64/boot/dts/google/gs101.dtsi b/arch/arm64/boot/dts/google/gs101.dtsi
new file mode 100644
index 000000000000..28b18c594350
--- /dev/null
+++ b/arch/arm64/boot/dts/google/gs101.dtsi
@@ -0,0 +1,503 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * GS101 SoC
+ *
+ * Copyright 2019-2023 Google LLC
+ *
+ */
+
+#include <dt-bindings/clock/google,gs101.h>
+#include <dt-bindings/gpio/gpio.h>
+#include <dt-bindings/interrupt-controller/arm-gic.h>
+
+/ {
+	compatible = "google,gs101";
+	#address-cells = <2>;
+	#size-cells = <1>;
+
+	interrupt-parent = <&gic>;
+
+	aliases {
+		pinctrl0 = &pinctrl_0;
+		pinctrl1 = &pinctrl_1;
+		pinctrl2 = &pinctrl_2;
+		pinctrl3 = &pinctrl_3;
+		pinctrl4 = &pinctrl_4;
+		pinctrl5 = &pinctrl_5;
+		pinctrl6 = &pinctrl_6;
+		pinctrl7 = &pinctrl_7;
+	};
+
+	arm-pmu {
+		compatible = "arm,armv8-pmuv3";
+		interrupts = <GIC_PPI 7 (GIC_CPU_MASK_SIMPLE(8) | IRQ_TYPE_LEVEL_HIGH)>;
+	};
+
+	dsu-pmu-0 {
+		compatible = "arm,dsu-pmu";
+		interrupts = <GIC_SPI 257 IRQ_TYPE_LEVEL_HIGH>;
+		cpus = <&cpu0>, <&cpu1>, <&cpu2>, <&cpu3>,
+		       <&cpu4>, <&cpu5>, <&cpu6>, <&cpu7>;
+	};
+
+	/* TODO replace with CCF clock */
+	dummy_clk: oscillator {
+		compatible = "fixed-clock";
+		#clock-cells = <0>;
+		clock-frequency = <12345>;
+		clock-output-names = "pclk";
+	};
+
+	cpus {
+		#address-cells = <2>;
+		#size-cells = <0>;
+
+		cpu-map {
+			cluster0 {
+				core0 {
+					cpu = <&cpu0>;
+				};
+				core1 {
+					cpu = <&cpu1>;
+				};
+				core2 {
+					cpu = <&cpu2>;
+				};
+				core3 {
+					cpu = <&cpu3>;
+				};
+			};
+
+			cluster1 {
+				core0 {
+					cpu = <&cpu4>;
+				};
+				core1 {
+					cpu = <&cpu5>;
+				};
+			};
+
+			cluster2 {
+				core0 {
+					cpu = <&cpu6>;
+				};
+				core1 {
+					cpu = <&cpu7>;
+				};
+			};
+		};
+
+		cpu0: cpu@0 {
+			device_type = "cpu";
+			compatible = "arm,armv8";
+			reg = <0x0 0x0000>;
+			enable-method = "psci";
+			cpu-idle-states =  <&ANANKE_CPU_SLEEP>;
+			capacity-dmips-mhz = <250>;
+			dynamic-power-coefficient = <70>;
+		};
+
+		cpu1: cpu@100 {
+			device_type = "cpu";
+			compatible = "arm,armv8";
+			reg = <0x0 0x0100>;
+			enable-method = "psci";
+			cpu-idle-states =  <&ANANKE_CPU_SLEEP>;
+			capacity-dmips-mhz = <250>;
+			dynamic-power-coefficient = <70>;
+		};
+
+		cpu2: cpu@200 {
+			device_type = "cpu";
+			compatible = "arm,armv8";
+			reg = <0x0 0x0200>;
+			enable-method = "psci";
+			cpu-idle-states =  <&ANANKE_CPU_SLEEP>;
+			capacity-dmips-mhz = <250>;
+			dynamic-power-coefficient = <70>;
+		};
+
+		cpu3: cpu@300 {
+			device_type = "cpu";
+			compatible = "arm,armv8";
+			reg = <0x0 0x0300>;
+			enable-method = "psci";
+			cpu-idle-states =  <&ANANKE_CPU_SLEEP>;
+			capacity-dmips-mhz = <250>;
+			dynamic-power-coefficient = <70>;
+		};
+
+		cpu4: cpu@400 {
+			device_type = "cpu";
+			compatible = "arm,armv8";
+			reg = <0x0 0x0400>;
+			enable-method = "psci";
+			cpu-idle-states =  <&ENYO_CPU_SLEEP>;
+			capacity-dmips-mhz = <620>;
+			dynamic-power-coefficient = <284>;
+		};
+
+		cpu5: cpu@500 {
+			device_type = "cpu";
+			compatible = "arm,armv8";
+			reg = <0x0 0x0500>;
+			enable-method = "psci";
+			cpu-idle-states =  <&ENYO_CPU_SLEEP>;
+			capacity-dmips-mhz = <620>;
+			dynamic-power-coefficient = <284>;
+		};
+
+		cpu6: cpu@600 {
+			device_type = "cpu";
+			compatible = "arm,armv8";
+			reg = <0x0 0x0600>;
+			enable-method = "psci";
+			cpu-idle-states =  <&HERA_CPU_SLEEP>;
+			capacity-dmips-mhz = <1024>;
+			dynamic-power-coefficient = <650>;
+		};
+
+		cpu7: cpu@700 {
+			device_type = "cpu";
+			compatible = "arm,armv8";
+			reg = <0x0 0x0700>;
+			enable-method = "psci";
+			cpu-idle-states =  <&HERA_CPU_SLEEP>;
+			capacity-dmips-mhz = <1024>;
+			dynamic-power-coefficient = <650>;
+		};
+
+		idle-states {
+			entry-method = "psci";
+
+			ANANKE_CPU_SLEEP: cpu-ananke-sleep {
+				idle-state-name = "c2";
+				compatible = "arm,idle-state";
+				arm,psci-suspend-param = <0x0010000>;
+				entry-latency-us = <70>;
+				exit-latency-us = <160>;
+				min-residency-us = <2000>;
+			};
+
+			ENYO_CPU_SLEEP: cpu-enyo-sleep {
+				idle-state-name = "c2";
+				compatible = "arm,idle-state";
+				arm,psci-suspend-param = <0x0010000>;
+				entry-latency-us = <150>;
+				exit-latency-us = <190>;
+				min-residency-us = <2500>;
+			};
+
+			HERA_CPU_SLEEP: cpu-hera-sleep {
+				idle-state-name = "c2";
+				compatible = "arm,idle-state";
+				arm,psci-suspend-param = <0x0010000>;
+				entry-latency-us = <235>;
+				exit-latency-us = <220>;
+				min-residency-us = <3500>;
+			};
+		};
+	};
+
+	/* bootloader requires ect node */
+	ect {
+		parameter_address = <0x90000000>;
+		parameter_size = <0x53000>;
+	};
+
+	ext_24_5m: clock-1 {
+		compatible = "fixed-clock";
+		#clock-cells = <0>;
+		clock-frequency = <24576000>;
+		clock-output-names = "oscclk";
+	};
+
+	ext_200m: clock-2 {
+		compatible = "fixed-clock";
+		#clock-cells = <0>;
+		clock-frequency = <200000000>;
+		clock-output-names = "ext-200m";
+	};
+
+	psci {
+		compatible = "arm,psci-1.0";
+		method = "smc";
+	};
+
+	reserved_memory: reserved-memory {
+		#address-cells = <2>;
+		#size-cells = <1>;
+		ranges;
+
+		gsa_reserved_protected: gsa@90200000 {
+			reg = <0x0 0x90200000 0x400000>;
+			no-map;
+		};
+
+		tpu_fw_reserved: tpu-fw@93000000 {
+			reg = <0x0 0x93000000 0x1000000>;
+			no-map;
+		};
+
+		aoc_reserve: aoc@94000000 {
+			reg = <0x0 0x94000000 0x03000000>;
+			no-map;
+		};
+
+		abl_reserved: abl@f8800000 {
+			reg = <0x0 0xf8800000 0x02000000>;
+			no-map;
+		};
+
+		dss_log_reserved: dss-log-reserved@fd3f0000 {
+			reg = <0 0xfd3f0000 0x0000e000>;
+			no-map;
+		};
+
+		debug_kinfo_reserved: debug-kinfo-reserved@fd3fe000 {
+			reg = <0 0xfd3fe000 0x00001000>;
+			no-map;
+		};
+
+		bldr_log_reserved: bldr-log-reserved@fd800000 {
+			reg = <0 0xfd800000 0x00100000>;
+			no-map;
+		};
+
+		bldr_log_hist_reserved: bldr-log-hist-reserved@fd900000 {
+			reg = <0 0xfd900000 0x00002000>;
+			no-map;
+		};
+	};
+
+	timer {
+		compatible = "arm,armv8-timer";
+		interrupts = <GIC_PPI 13 (GIC_CPU_MASK_SIMPLE(8) | IRQ_TYPE_LEVEL_LOW)>,
+			     <GIC_PPI 14 (GIC_CPU_MASK_SIMPLE(8) | IRQ_TYPE_LEVEL_LOW)>,
+			     <GIC_PPI 11 (GIC_CPU_MASK_SIMPLE(8) | IRQ_TYPE_LEVEL_LOW)>,
+			     <GIC_PPI 10 (GIC_CPU_MASK_SIMPLE(8) | IRQ_TYPE_LEVEL_LOW)>;
+		clock-frequency = <24576000>;
+	};
+
+	soc: soc@0 {
+		compatible = "simple-bus";
+		#address-cells = <2>;
+		#size-cells = <1>;
+		ranges;
+
+		cmu_misc: clock-controller@10010000 {
+			compatible = "google,gs101-cmu-misc";
+			reg = <0x0 0x10010000 0x8000>;
+			#clock-cells = <1>;
+			clocks =  <&ext_24_5m>, <&cmu_top CLK_DOUT_MISC_BUS>;
+			clock-names = "oscclk", "dout_cmu_misc_bus";
+		};
+
+		watchdog_cl0: watchdog@10060000 {
+			compatible = "google,gs101-wdt";
+			reg = <0x0 0x10060000 0x100>;
+			interrupts = <GIC_SPI 765 IRQ_TYPE_LEVEL_HIGH>;
+			clocks = <&cmu_misc CLK_GOUT_MISC_WDT_CLUSTER0>, <&ext_24_5m>;
+			clock-names = "watchdog", "watchdog_src";
+			samsung,syscon-phandle = <&pmu_system_controller>;
+			samsung,cluster-index = <0>;
+		};
+
+		watchdog_cl1: watchdog@10070000 {
+			compatible = "google,gs101-wdt";
+			reg = <0x0 0x10070000 0x100>;
+			interrupts = <GIC_SPI 766 IRQ_TYPE_LEVEL_HIGH>;
+			clocks = <&cmu_misc CLK_GOUT_MISC_WDT_CLUSTER1>, <&ext_24_5m>;
+			clock-names = "watchdog", "watchdog_src";
+			samsung,syscon-phandle = <&pmu_system_controller>;
+			samsung,cluster-index = <1>;
+			status = "disabled";
+		};
+
+		gic: interrupt-controller@10400000 {
+		     compatible = "arm,gic-v3";
+		     #interrupt-cells = <3>;
+		     interrupt-controller;
+		     reg = <0x0 0x10400000 0x10000>,	/* GICD */
+			   <0x0 0x10440000 0x100000>;	/* GICR * 8 */
+		     interrupts = <GIC_PPI 9 IRQ_TYPE_LEVEL_HIGH>;
+		};
+
+		sysreg_peric0: syscon@10821000 {
+			compatible = "google,gs101-peric0-sysreg", "syscon";
+			reg = <0x0 0x10821000 0x40000>;
+		};
+
+		/* GPIO_PERIC0 */
+		pinctrl_4: pinctrl@10840000 {
+			compatible = "google,gs101-pinctrl";
+			reg = <0x0 0x10840000 0x00001000>;
+			interrupts = <GIC_SPI 625 IRQ_TYPE_LEVEL_HIGH>;
+		};
+
+		serial_0: serial@10a00000 {
+			compatible = "google,gs101-uart";
+			reg = <0x0 0x10a00000 0xc0>;
+			reg-io-width = <4>;
+			samsung,uart-fifosize = <256>;
+			interrupts = <GIC_SPI 634 IRQ_TYPE_LEVEL_HIGH>;
+			clocks = <&dummy_clk 0>, <&dummy_clk 0>;
+			clock-names = "uart", "clk_uart_baud0";
+		};
+
+		/* GPIO_PERIC1 */
+		pinctrl_5: pinctrl@10c40000 {
+			compatible = "google,gs101-pinctrl";
+			reg = <0x0 0x10C40000 0x00001000>;
+			interrupts = <GIC_SPI 644 IRQ_TYPE_LEVEL_HIGH>;
+		};
+
+		sysreg_peric1: syscon@10c21000 {
+			compatible = "google,gs101-peric1-sysreg", "syscon";
+			reg = <0x0 0x10C21000 0x40000>;
+		};
+
+		/* GPIO_HSI1 */
+		pinctrl_6: pinctrl@11840000 {
+			compatible = "google,gs101-pinctrl";
+			reg = <0x0 0x11840000 0x00001000>;
+			interrupts = <GIC_SPI 471 IRQ_TYPE_LEVEL_HIGH>;
+		};
+
+		/* GPIO_HSI2 */
+		pinctrl_7: pinctrl@14440000 {
+			compatible = "google,gs101-pinctrl";
+			reg = <0x0 0x14440000 0x00001000>;
+			interrupts = <GIC_SPI 503 IRQ_TYPE_LEVEL_HIGH>;
+		};
+
+		cmu_apm: clock-controller@17400000 {
+			compatible = "google,gs101-cmu-apm";
+			reg = <0x0 0x17400000 0x8000>;
+			#clock-cells = <1>;
+
+			clocks = <&ext_24_5m>;
+			clock-names = "oscclk";
+		};
+
+		sysreg_apm: syscon@174204e0 {
+			compatible = "google,gs101-apm-sysreg", "syscon";
+			reg = <0x0 0x174204e0 0x1000>;
+		};
+
+		pmu_system_controller: system-controller@17460000 {
+			compatible = "google,gs101-pmu", "syscon";
+			reg = <0x0 0x17460000 0x10000>;
+		};
+
+		/* GPIO_ALIVE */
+		pinctrl_0: pinctrl@174d0000 {
+			compatible = "google,gs101-pinctrl";
+			reg = <0x0 0x174d0000 0x00001000>;
+			interrupts = <GIC_SPI 0 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 1 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 2 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 3 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 4 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 5 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 6 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 7 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 8 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 9 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 10 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 11 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 12 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 13 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 14 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 15 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 16 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 17 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 18 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 19 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 20 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 21 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 22 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 23 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 24 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 25 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 26 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 27 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 28 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 29 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 30 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 31 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 32 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 33 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 34 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 35 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 36 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 37 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 38 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 39 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 40 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 41 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 42 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 43 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 44 IRQ_TYPE_LEVEL_HIGH>;
+
+			wakeup-interrupt-controller {
+				compatible = "google,gs101-wakeup-eint";
+			};
+		};
+
+		/* GPIO_FAR_ALIVE */
+		pinctrl_1: pinctrl@174e0000 {
+			compatible = "google,gs101-pinctrl";
+			reg = <0x0 0x174e0000 0x00001000>;
+			interrupts = <GIC_SPI 45 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 46 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 47 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 48 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 49 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 50 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 51 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 52 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 53 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 54 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 55 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 56 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 57 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 58 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 59 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 60 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 61 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 62 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 63 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 64 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 65 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 66 IRQ_TYPE_LEVEL_HIGH>;
+
+			wakeup-interrupt-controller {
+				compatible = "google,gs101-wakeup-eint";
+			};
+		};
+
+		/* GPIO_GSACTRL */
+		pinctrl_3: pinctrl@17940000 {
+			compatible = "google,gs101-pinctrl";
+			reg = <0x0 0x17940000 0x00001000>;
+		};
+
+		/* GPIO_GSACORE */
+		pinctrl_2: pinctrl@17a80000 {
+			compatible = "google,gs101-pinctrl";
+			reg = <0x0 0x17a80000 0x00001000>;
+		};
+
+		cmu_top: clock-controller@1e080000 {
+			compatible = "google,gs101-cmu-top";
+			reg = <0x0 0x1e080000 0x8000>;
+			#clock-cells = <1>;
+
+			clocks = <&ext_24_5m>;
+			clock-names = "oscclk";
+		};
+	};
+};
+
+#include "gs101-pinctrl.dtsi"
-- 
2.42.0.609.gbb76f46606-goog


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH v2 18/20] arm64: dts: google: Add initial Oriole/pixel 6 board support

[Peter Griffin]

Add initial board support for the Pixel 6 phone code named Oriole. This
has been tested with a minimal busybox initramfs and boots to a shell.

Signed-off-by: Peter Griffin <peter.griffin@linaro.org>
---
 arch/arm64/boot/dts/google/Makefile         |  4 ++
 arch/arm64/boot/dts/google/gs101-oriole.dts | 79 +++++++++++++++++++++
 2 files changed, 83 insertions(+)
 create mode 100644 arch/arm64/boot/dts/google/Makefile
 create mode 100644 arch/arm64/boot/dts/google/gs101-oriole.dts

diff --git a/arch/arm64/boot/dts/google/Makefile b/arch/arm64/boot/dts/google/Makefile
new file mode 100644
index 000000000000..5cea8ff27141
--- /dev/null
+++ b/arch/arm64/boot/dts/google/Makefile
@@ -0,0 +1,4 @@
+# SPDX-License-Identifier: GPL-2.0
+
+dtb-$(CONFIG_ARCH_GOOGLE_TENSOR) += \
+	gs101-oriole.dtb \
diff --git a/arch/arm64/boot/dts/google/gs101-oriole.dts b/arch/arm64/boot/dts/google/gs101-oriole.dts
new file mode 100644
index 000000000000..3bebca989d34
--- /dev/null
+++ b/arch/arm64/boot/dts/google/gs101-oriole.dts
@@ -0,0 +1,79 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Oriole Device Tree
+ *
+ * Copyright 2021-2023 Google,LLC
+ */
+
+/dts-v1/;
+/plugin/;
+
+#include <dt-bindings/gpio/gpio.h>
+#include <dt-bindings/input/input.h>
+#include "gs101-pinctrl.h"
+#include "gs101.dtsi"
+
+/ {
+	model = "Oriole";
+	compatible = "google,gs101-oriole", "google,gs101";
+
+	chosen {
+		bootargs = "earlycon=exynos4210,mmio32,0x10A00000 console=ttySAC0";
+	};
+
+	gpio-keys {
+		compatible = "gpio-keys";
+		pinctrl-names = "default";
+		pinctrl-0 = <&key_voldown &key_volup &key_power>;
+
+		button-vol-down {
+			label = "KEY_VOLUMEDOWN";
+			linux,code = <KEY_VOLUMEDOWN>;
+			gpios = <&gpa7 3 GPIO_ACTIVE_LOW>;
+			wakeup-source;
+		};
+
+		button-vol-up {
+			label = "KEY_VOLUMEUP";
+			linux,code = <KEY_VOLUMEUP>;
+			gpios = <&gpa8 1 GPIO_ACTIVE_LOW>;
+			wakeup-source;
+		};
+
+		button-power {
+			label = "KEY_POWER";
+			linux,code = <KEY_POWER>;
+			gpios = <&gpa10 1 GPIO_ACTIVE_LOW>;
+			wakeup-source;
+		};
+	};
+};
+
+&pinctrl_1 {
+	key_voldown: key-voldown-pins {
+		samsung,pins = "gpa7-3";
+		samsung,pin-function = <0xf>;
+		samsung,pin-pud = <0>;
+		samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
+	};
+
+	key_volup: key-volup-pins {
+		samsung,pins = "gpa8-1";
+		samsung,pin-function = <0xf>;
+		samsung,pin-pud = <0>;
+		samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
+	};
+};
+
+&pinctrl_0 {
+	key_power: key-power-pins {
+		samsung,pins = "gpa10-1";
+		samsung,pin-function = <0xf>;
+		samsung,pin-pud = <0>;
+		samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
+	};
+};
+
+&watchdog_cl0 {
+	timeout-sec = <30>;
+};
-- 
2.42.0.609.gbb76f46606-goog

[PATCH v2 18/20] arm64: dts: google: Add initial Oriole/pixel 6 board support

[Peter Griffin]

Add initial board support for the Pixel 6 phone code named Oriole. This
has been tested with a minimal busybox initramfs and boots to a shell.

Signed-off-by: Peter Griffin <peter.griffin@linaro.org>
---
 arch/arm64/boot/dts/google/Makefile         |  4 ++
 arch/arm64/boot/dts/google/gs101-oriole.dts | 79 +++++++++++++++++++++
 2 files changed, 83 insertions(+)
 create mode 100644 arch/arm64/boot/dts/google/Makefile
 create mode 100644 arch/arm64/boot/dts/google/gs101-oriole.dts

diff --git a/arch/arm64/boot/dts/google/Makefile b/arch/arm64/boot/dts/google/Makefile
new file mode 100644
index 000000000000..5cea8ff27141
--- /dev/null
+++ b/arch/arm64/boot/dts/google/Makefile
@@ -0,0 +1,4 @@
+# SPDX-License-Identifier: GPL-2.0
+
+dtb-$(CONFIG_ARCH_GOOGLE_TENSOR) += \
+	gs101-oriole.dtb \
diff --git a/arch/arm64/boot/dts/google/gs101-oriole.dts b/arch/arm64/boot/dts/google/gs101-oriole.dts
new file mode 100644
index 000000000000..3bebca989d34
--- /dev/null
+++ b/arch/arm64/boot/dts/google/gs101-oriole.dts
@@ -0,0 +1,79 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Oriole Device Tree
+ *
+ * Copyright 2021-2023 Google,LLC
+ */
+
+/dts-v1/;
+/plugin/;
+
+#include <dt-bindings/gpio/gpio.h>
+#include <dt-bindings/input/input.h>
+#include "gs101-pinctrl.h"
+#include "gs101.dtsi"
+
+/ {
+	model = "Oriole";
+	compatible = "google,gs101-oriole", "google,gs101";
+
+	chosen {
+		bootargs = "earlycon=exynos4210,mmio32,0x10A00000 console=ttySAC0";
+	};
+
+	gpio-keys {
+		compatible = "gpio-keys";
+		pinctrl-names = "default";
+		pinctrl-0 = <&key_voldown &key_volup &key_power>;
+
+		button-vol-down {
+			label = "KEY_VOLUMEDOWN";
+			linux,code = <KEY_VOLUMEDOWN>;
+			gpios = <&gpa7 3 GPIO_ACTIVE_LOW>;
+			wakeup-source;
+		};
+
+		button-vol-up {
+			label = "KEY_VOLUMEUP";
+			linux,code = <KEY_VOLUMEUP>;
+			gpios = <&gpa8 1 GPIO_ACTIVE_LOW>;
+			wakeup-source;
+		};
+
+		button-power {
+			label = "KEY_POWER";
+			linux,code = <KEY_POWER>;
+			gpios = <&gpa10 1 GPIO_ACTIVE_LOW>;
+			wakeup-source;
+		};
+	};
+};
+
+&pinctrl_1 {
+	key_voldown: key-voldown-pins {
+		samsung,pins = "gpa7-3";
+		samsung,pin-function = <0xf>;
+		samsung,pin-pud = <0>;
+		samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
+	};
+
+	key_volup: key-volup-pins {
+		samsung,pins = "gpa8-1";
+		samsung,pin-function = <0xf>;
+		samsung,pin-pud = <0>;
+		samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
+	};
+};
+
+&pinctrl_0 {
+	key_power: key-power-pins {
+		samsung,pins = "gpa10-1";
+		samsung,pin-function = <0xf>;
+		samsung,pin-pud = <0>;
+		samsung,pin-drv = <GS101_PIN_DRV_2_5_MA>;
+	};
+};
+
+&watchdog_cl0 {
+	timeout-sec = <30>;
+};
-- 
2.42.0.609.gbb76f46606-goog


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH v2 19/20] arm64: defconfig: Enable Google Tensor SoC

[Peter Griffin]

Add the Google Tensor SoC to the arm64 defconfig

Signed-off-by: Peter Griffin <peter.griffin@linaro.org>
---
 arch/arm64/configs/defconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
index 5315789f4868..8a34603b1822 100644
--- a/arch/arm64/configs/defconfig
+++ b/arch/arm64/configs/defconfig
@@ -41,6 +41,7 @@ CONFIG_ARCH_BCMBCA=y
 CONFIG_ARCH_BRCMSTB=y
 CONFIG_ARCH_BERLIN=y
 CONFIG_ARCH_EXYNOS=y
+CONFIG_ARCH_GOOGLE_TENSOR=y
 CONFIG_ARCH_SPARX5=y
 CONFIG_ARCH_K3=y
 CONFIG_ARCH_LG1K=y
-- 
2.42.0.609.gbb76f46606-goog

[PATCH v2 19/20] arm64: defconfig: Enable Google Tensor SoC

[Peter Griffin]

Add the Google Tensor SoC to the arm64 defconfig

Signed-off-by: Peter Griffin <peter.griffin@linaro.org>
---
 arch/arm64/configs/defconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
index 5315789f4868..8a34603b1822 100644
--- a/arch/arm64/configs/defconfig
+++ b/arch/arm64/configs/defconfig
@@ -41,6 +41,7 @@ CONFIG_ARCH_BCMBCA=y
 CONFIG_ARCH_BRCMSTB=y
 CONFIG_ARCH_BERLIN=y
 CONFIG_ARCH_EXYNOS=y
+CONFIG_ARCH_GOOGLE_TENSOR=y
 CONFIG_ARCH_SPARX5=y
 CONFIG_ARCH_K3=y
 CONFIG_ARCH_LG1K=y
-- 
2.42.0.609.gbb76f46606-goog


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH v2 20/20] MAINTAINERS: add entry for Google Tensor SoC

[Peter Griffin]

Add maintainers entry for the Google tensor SoC based
platforms.

Signed-off-by: Peter Griffin <peter.griffin@linaro.org>
---
 MAINTAINERS | 10 ++++++++++
 1 file changed, 10 insertions(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index 90f13281d297..149a0c364309 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -8836,6 +8836,16 @@ S:	Maintained
 T:	git git://git.kernel.org/pub/scm/linux/kernel/git/chrome-platform/linux.git
 F:	drivers/firmware/google/
 
+GOOGLE TENSOR SoC SUPPORT
+M:	Peter Griffin <peter.griffin@linaro.org>
+L:	linux-arm-kernel@lists.infradead.org (moderated for non-subscribers)
+L:	linux-samsung-soc@vger.kernel.org
+S:	Maintained
+F:	Documentation/devicetree/bindings/clock/google,gs101-clock.yaml
+F:	arch/arm64/boot/dts/google/
+F:	drivers/clk/samsung/clk-gs101.c
+F:	include/dt-bindings/clock/google,clk-gs101.h
+
 GPD POCKET FAN DRIVER
 M:	Hans de Goede <hdegoede@redhat.com>
 L:	platform-driver-x86@vger.kernel.org
-- 
2.42.0.609.gbb76f46606-goog

[PATCH v2 20/20] MAINTAINERS: add entry for Google Tensor SoC

[Peter Griffin]

Add maintainers entry for the Google tensor SoC based
platforms.

Signed-off-by: Peter Griffin <peter.griffin@linaro.org>
---
 MAINTAINERS | 10 ++++++++++
 1 file changed, 10 insertions(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index 90f13281d297..149a0c364309 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -8836,6 +8836,16 @@ S:	Maintained
 T:	git git://git.kernel.org/pub/scm/linux/kernel/git/chrome-platform/linux.git
 F:	drivers/firmware/google/
 
+GOOGLE TENSOR SoC SUPPORT
+M:	Peter Griffin <peter.griffin@linaro.org>
+L:	linux-arm-kernel@lists.infradead.org (moderated for non-subscribers)
+L:	linux-samsung-soc@vger.kernel.org
+S:	Maintained
+F:	Documentation/devicetree/bindings/clock/google,gs101-clock.yaml
+F:	arch/arm64/boot/dts/google/
+F:	drivers/clk/samsung/clk-gs101.c
+F:	include/dt-bindings/clock/google,clk-gs101.h
+
 GPD POCKET FAN DRIVER
 M:	Hans de Goede <hdegoede@redhat.com>
 L:	platform-driver-x86@vger.kernel.org
-- 
2.42.0.609.gbb76f46606-goog


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH v2 15/20] watchdog: s3c2410_wdt: Add support for Google tensor SoCs

[Guenter Roeck]

On Tue, Oct 10, 2023 at 11:49:23PM +0100, Peter Griffin wrote:
> This patch adds the compatibles and drvdata for the Google
> gs101 & gs201 SoCs found in Pixel 6 and Pixel 7 phones. Similar
> to Exynos850 it has two watchdog instances, one for each cluster
> and has some control bits in PMU registers.
> 
> The watchdog IP found in gs101 SoCs also supports a few
> additional bits/features in the WTCON register which we add
> support for and an additional register detailed below.
> 
> dbgack-mask - Enables masking WDT interrupt and reset request
> according to asserted DBGACK input
> 
> windowed-mode - Enabled Windowed watchdog mode
> 
> Windowed watchdog mode also has an additional register WTMINCNT.
> If windowed watchdog is enabled and you reload WTCNT when the
> value is greater than WTMINCNT, it prompts interrupt or reset
> request as if the watchdog time has expired.

I am a bit lost with this one. The patch adds QUIRK_HAS_WTMINCNT_REG
but doesn't use it. It also adds S3C2410_WTMINCNT but does not use it
either.

What is the point of doing that ? It is just confusing.

Guenter

> 
> Signed-off-by: Peter Griffin <peter.griffin@linaro.org>
> ---
>  drivers/watchdog/s3c2410_wdt.c | 104 ++++++++++++++++++++++++++++++---
>  1 file changed, 95 insertions(+), 9 deletions(-)
> 
> diff --git a/drivers/watchdog/s3c2410_wdt.c b/drivers/watchdog/s3c2410_wdt.c
> index 0b4bd883ff28..08a775c01c57 100644
> --- a/drivers/watchdog/s3c2410_wdt.c
> +++ b/drivers/watchdog/s3c2410_wdt.c
> @@ -31,12 +31,14 @@
>  #define S3C2410_WTDAT		0x04
>  #define S3C2410_WTCNT		0x08
>  #define S3C2410_WTCLRINT	0x0c
> -
> +#define S3C2410_WTMINCNT	0x10
>  #define S3C2410_WTCNT_MAXCNT	0xffff
>  
> -#define S3C2410_WTCON_RSTEN	(1 << 0)
> -#define S3C2410_WTCON_INTEN	(1 << 2)
> -#define S3C2410_WTCON_ENABLE	(1 << 5)
> +#define S3C2410_WTCON_RSTEN		(1 << 0)
> +#define S3C2410_WTCON_INTEN		(1 << 2)
> +#define S3C2410_WTCON_ENABLE		(1 << 5)
> +#define S3C2410_WTCON_DBGACK_MASK	(1 << 16)
> +#define S3C2410_WTCON_WINDOWED_WD	(1 << 20)
>  
>  #define S3C2410_WTCON_DIV16	(0 << 3)
>  #define S3C2410_WTCON_DIV32	(1 << 3)
> @@ -67,6 +69,12 @@
>  #define EXYNOSAUTOV9_CLUSTER0_WDTRESET_BIT	25
>  #define EXYNOSAUTOV9_CLUSTER1_WDTRESET_BIT	24
>  
> +#define GS_CLUSTER0_NONCPU_OUT			0x1220
> +#define GS_CLUSTER1_NONCPU_OUT			0x1420
> +#define GS_CLUSTER0_NONCPU_INT_EN		0x1244
> +#define GS_CLUSTER1_NONCPU_INT_EN		0x1444
> +#define GS_CLUSTER2_NONCPU_INT_EN		0x1644
> +#define GS_RST_STAT_REG_OFFSET			0x3B44
>  /**
>   * DOC: Quirk flags for different Samsung watchdog IP-cores
>   *
> @@ -106,6 +114,8 @@
>  #define QUIRK_HAS_PMU_RST_STAT			(1 << 2)
>  #define QUIRK_HAS_PMU_AUTO_DISABLE		(1 << 3)
>  #define QUIRK_HAS_PMU_CNT_EN			(1 << 4)
> +#define QUIRK_HAS_DBGACK_BIT			(1 << 5)
> +#define QUIRK_HAS_WTMINCNT_REG			(1 << 6)
>  
>  /* These quirks require that we have a PMU register map */
>  #define QUIRKS_HAVE_PMUREG \
> @@ -263,6 +273,54 @@ static const struct s3c2410_wdt_variant drv_data_exynosautov9_cl1 = {
>  		  QUIRK_HAS_PMU_RST_STAT | QUIRK_HAS_PMU_CNT_EN,
>  };
>  
> +static const struct s3c2410_wdt_variant drv_data_gs101_cl0 = {
> +	.mask_reset_reg = GS_CLUSTER0_NONCPU_INT_EN,
> +	.mask_bit = 2,
> +	.mask_reset_inv = true,
> +	.rst_stat_reg = GS_RST_STAT_REG_OFFSET,
> +	.rst_stat_bit = 0,
> +	.cnt_en_reg = GS_CLUSTER0_NONCPU_OUT,
> +	.cnt_en_bit = 8,
> +	.quirks = QUIRK_HAS_PMU_RST_STAT | QUIRK_HAS_PMU_MASK_RESET | QUIRK_HAS_PMU_CNT_EN |
> +		  QUIRK_HAS_WTCLRINT_REG | QUIRK_HAS_DBGACK_BIT | QUIRK_HAS_WTMINCNT_REG,
> +};
> +
> +static const struct s3c2410_wdt_variant drv_data_gs101_cl1 = {
> +	.mask_reset_reg = GS_CLUSTER1_NONCPU_INT_EN,
> +	.mask_bit = 2,
> +	.mask_reset_inv = true,
> +	.rst_stat_reg = GS_RST_STAT_REG_OFFSET,
> +	.rst_stat_bit = 1,
> +	.cnt_en_reg = GS_CLUSTER1_NONCPU_OUT,
> +	.cnt_en_bit = 7,
> +	.quirks = QUIRK_HAS_PMU_RST_STAT | QUIRK_HAS_PMU_MASK_RESET | QUIRK_HAS_PMU_CNT_EN |
> +		  QUIRK_HAS_WTCLRINT_REG | QUIRK_HAS_DBGACK_BIT | QUIRK_HAS_WTMINCNT_REG,
> +};
> +
> +static const struct s3c2410_wdt_variant drv_data_gs201_cl0 = {
> +	.mask_reset_reg = GS_CLUSTER0_NONCPU_INT_EN,
> +	.mask_bit = 2,
> +	.mask_reset_inv = true,
> +	.rst_stat_reg = GS_RST_STAT_REG_OFFSET,
> +	.rst_stat_bit = 0,
> +	.cnt_en_reg = GS_CLUSTER0_NONCPU_OUT,
> +	.cnt_en_bit = 8,
> +	.quirks = QUIRK_HAS_PMU_RST_STAT | QUIRK_HAS_PMU_MASK_RESET | QUIRK_HAS_PMU_CNT_EN |
> +		  QUIRK_HAS_WTCLRINT_REG | QUIRK_HAS_DBGACK_BIT | QUIRK_HAS_WTMINCNT_REG,
> +};
> +
> +static const struct s3c2410_wdt_variant drv_data_gs201_cl1 = {
> +	.mask_reset_reg = GS_CLUSTER1_NONCPU_INT_EN,
> +	.mask_bit = 2,
> +	.mask_reset_inv = true,
> +	.rst_stat_reg = GS_RST_STAT_REG_OFFSET,
> +	.rst_stat_bit = 1,
> +	.cnt_en_reg = GS_CLUSTER1_NONCPU_OUT,
> +	.cnt_en_bit = 7,
> +	.quirks = QUIRK_HAS_PMU_RST_STAT | QUIRK_HAS_PMU_MASK_RESET | QUIRK_HAS_PMU_CNT_EN |
> +		  QUIRK_HAS_WTCLRINT_REG | QUIRK_HAS_DBGACK_BIT | QUIRK_HAS_WTMINCNT_REG,
> +};
> +
>  static const struct of_device_id s3c2410_wdt_match[] = {
>  	{ .compatible = "samsung,s3c2410-wdt",
>  	  .data = &drv_data_s3c2410 },
> @@ -278,6 +336,10 @@ static const struct of_device_id s3c2410_wdt_match[] = {
>  	  .data = &drv_data_exynos850_cl0 },
>  	{ .compatible = "samsung,exynosautov9-wdt",
>  	  .data = &drv_data_exynosautov9_cl0 },
> +	{ .compatible = "google,gs101-wdt",
> +	  .data = &drv_data_gs101_cl0 },
> +	{ .compatible = "google,gs201-wdt",
> +	  .data = &drv_data_gs201_cl0 },
>  	{},
>  };
>  MODULE_DEVICE_TABLE(of, s3c2410_wdt_match);
> @@ -375,6 +437,21 @@ static int s3c2410wdt_enable(struct s3c2410_wdt *wdt, bool en)
>  	return 0;
>  }
>  
> +static void s3c2410wdt_mask_dbgack(struct s3c2410_wdt *wdt, bool mask)
> +{
> +	unsigned long wtcon;
> +
> +	if (!(wdt->drv_data->quirks & QUIRK_HAS_DBGACK_BIT))
> +		return;
> +
> +	wtcon = readl(wdt->reg_base + S3C2410_WTCON);
> +	if (mask)
> +		wtcon |= S3C2410_WTCON_DBGACK_MASK;
> +	else
> +		wtcon &= ~S3C2410_WTCON_DBGACK_MASK;
> +	writel(wtcon, wdt->reg_base + S3C2410_WTCON);
> +}
> +
>  static int s3c2410wdt_keepalive(struct watchdog_device *wdd)
>  {
>  	struct s3c2410_wdt *wdt = watchdog_get_drvdata(wdd);
> @@ -585,9 +662,11 @@ s3c2410_get_wdt_drv_data(struct platform_device *pdev, struct s3c2410_wdt *wdt)
>  	}
>  
>  #ifdef CONFIG_OF
> -	/* Choose Exynos850/ExynosAutov9 driver data w.r.t. cluster index */
> +	/* Choose Exynos850/ExynosAutov9/gsx01 driver data w.r.t. cluster index */
>  	if (variant == &drv_data_exynos850_cl0 ||
> -	    variant == &drv_data_exynosautov9_cl0) {
> +	    variant == &drv_data_exynosautov9_cl0 ||
> +	    variant == &drv_data_gs101_cl0 ||
> +	    variant == &drv_data_gs201_cl0) {
>  		u32 index;
>  		int err;
>  
> @@ -600,9 +679,14 @@ s3c2410_get_wdt_drv_data(struct platform_device *pdev, struct s3c2410_wdt *wdt)
>  		case 0:
>  			break;
>  		case 1:
> -			variant = (variant == &drv_data_exynos850_cl0) ?
> -				&drv_data_exynos850_cl1 :
> -				&drv_data_exynosautov9_cl1;
> +			if (variant == &drv_data_exynos850_cl0)
> +				variant = &drv_data_exynos850_cl1;
> +			else if (variant == &drv_data_exynosautov9_cl0)
> +				variant = &drv_data_exynosautov9_cl1;
> +			else if (variant == &drv_data_gs101_cl0)
> +				variant = &drv_data_gs101_cl1;
> +			else if (variant == &drv_data_gs201_cl0)
> +				variant = &drv_data_gs201_cl1;
>  			break;
>  		default:
>  			return dev_err_probe(dev, -EINVAL, "wrong cluster index: %u\n", index);
> @@ -700,6 +784,8 @@ static int s3c2410wdt_probe(struct platform_device *pdev)
>  	wdt->wdt_device.bootstatus = s3c2410wdt_get_bootstatus(wdt);
>  	wdt->wdt_device.parent = dev;
>  
> +	s3c2410wdt_mask_dbgack(wdt, true);
> +
>  	/*
>  	 * If "tmr_atboot" param is non-zero, start the watchdog right now. Also
>  	 * set WDOG_HW_RUNNING bit, so that watchdog core can kick the watchdog.
> -- 
> 2.42.0.609.gbb76f46606-goog
> 

Re: [PATCH v2 15/20] watchdog: s3c2410_wdt: Add support for Google tensor SoCs

[Guenter Roeck]

On Tue, Oct 10, 2023 at 11:49:23PM +0100, Peter Griffin wrote:
> This patch adds the compatibles and drvdata for the Google
> gs101 & gs201 SoCs found in Pixel 6 and Pixel 7 phones. Similar
> to Exynos850 it has two watchdog instances, one for each cluster
> and has some control bits in PMU registers.
> 
> The watchdog IP found in gs101 SoCs also supports a few
> additional bits/features in the WTCON register which we add
> support for and an additional register detailed below.
> 
> dbgack-mask - Enables masking WDT interrupt and reset request
> according to asserted DBGACK input
> 
> windowed-mode - Enabled Windowed watchdog mode
> 
> Windowed watchdog mode also has an additional register WTMINCNT.
> If windowed watchdog is enabled and you reload WTCNT when the
> value is greater than WTMINCNT, it prompts interrupt or reset
> request as if the watchdog time has expired.

I am a bit lost with this one. The patch adds QUIRK_HAS_WTMINCNT_REG
but doesn't use it. It also adds S3C2410_WTMINCNT but does not use it
either.

What is the point of doing that ? It is just confusing.

Guenter

> 
> Signed-off-by: Peter Griffin <peter.griffin@linaro.org>
> ---
>  drivers/watchdog/s3c2410_wdt.c | 104 ++++++++++++++++++++++++++++++---
>  1 file changed, 95 insertions(+), 9 deletions(-)
> 
> diff --git a/drivers/watchdog/s3c2410_wdt.c b/drivers/watchdog/s3c2410_wdt.c
> index 0b4bd883ff28..08a775c01c57 100644
> --- a/drivers/watchdog/s3c2410_wdt.c
> +++ b/drivers/watchdog/s3c2410_wdt.c
> @@ -31,12 +31,14 @@
>  #define S3C2410_WTDAT		0x04
>  #define S3C2410_WTCNT		0x08
>  #define S3C2410_WTCLRINT	0x0c
> -
> +#define S3C2410_WTMINCNT	0x10
>  #define S3C2410_WTCNT_MAXCNT	0xffff
>  
> -#define S3C2410_WTCON_RSTEN	(1 << 0)
> -#define S3C2410_WTCON_INTEN	(1 << 2)
> -#define S3C2410_WTCON_ENABLE	(1 << 5)
> +#define S3C2410_WTCON_RSTEN		(1 << 0)
> +#define S3C2410_WTCON_INTEN		(1 << 2)
> +#define S3C2410_WTCON_ENABLE		(1 << 5)
> +#define S3C2410_WTCON_DBGACK_MASK	(1 << 16)
> +#define S3C2410_WTCON_WINDOWED_WD	(1 << 20)
>  
>  #define S3C2410_WTCON_DIV16	(0 << 3)
>  #define S3C2410_WTCON_DIV32	(1 << 3)
> @@ -67,6 +69,12 @@
>  #define EXYNOSAUTOV9_CLUSTER0_WDTRESET_BIT	25
>  #define EXYNOSAUTOV9_CLUSTER1_WDTRESET_BIT	24
>  
> +#define GS_CLUSTER0_NONCPU_OUT			0x1220
> +#define GS_CLUSTER1_NONCPU_OUT			0x1420
> +#define GS_CLUSTER0_NONCPU_INT_EN		0x1244
> +#define GS_CLUSTER1_NONCPU_INT_EN		0x1444
> +#define GS_CLUSTER2_NONCPU_INT_EN		0x1644
> +#define GS_RST_STAT_REG_OFFSET			0x3B44
>  /**
>   * DOC: Quirk flags for different Samsung watchdog IP-cores
>   *
> @@ -106,6 +114,8 @@
>  #define QUIRK_HAS_PMU_RST_STAT			(1 << 2)
>  #define QUIRK_HAS_PMU_AUTO_DISABLE		(1 << 3)
>  #define QUIRK_HAS_PMU_CNT_EN			(1 << 4)
> +#define QUIRK_HAS_DBGACK_BIT			(1 << 5)
> +#define QUIRK_HAS_WTMINCNT_REG			(1 << 6)
>  
>  /* These quirks require that we have a PMU register map */
>  #define QUIRKS_HAVE_PMUREG \
> @@ -263,6 +273,54 @@ static const struct s3c2410_wdt_variant drv_data_exynosautov9_cl1 = {
>  		  QUIRK_HAS_PMU_RST_STAT | QUIRK_HAS_PMU_CNT_EN,
>  };
>  
> +static const struct s3c2410_wdt_variant drv_data_gs101_cl0 = {
> +	.mask_reset_reg = GS_CLUSTER0_NONCPU_INT_EN,
> +	.mask_bit = 2,
> +	.mask_reset_inv = true,
> +	.rst_stat_reg = GS_RST_STAT_REG_OFFSET,
> +	.rst_stat_bit = 0,
> +	.cnt_en_reg = GS_CLUSTER0_NONCPU_OUT,
> +	.cnt_en_bit = 8,
> +	.quirks = QUIRK_HAS_PMU_RST_STAT | QUIRK_HAS_PMU_MASK_RESET | QUIRK_HAS_PMU_CNT_EN |
> +		  QUIRK_HAS_WTCLRINT_REG | QUIRK_HAS_DBGACK_BIT | QUIRK_HAS_WTMINCNT_REG,
> +};
> +
> +static const struct s3c2410_wdt_variant drv_data_gs101_cl1 = {
> +	.mask_reset_reg = GS_CLUSTER1_NONCPU_INT_EN,
> +	.mask_bit = 2,
> +	.mask_reset_inv = true,
> +	.rst_stat_reg = GS_RST_STAT_REG_OFFSET,
> +	.rst_stat_bit = 1,
> +	.cnt_en_reg = GS_CLUSTER1_NONCPU_OUT,
> +	.cnt_en_bit = 7,
> +	.quirks = QUIRK_HAS_PMU_RST_STAT | QUIRK_HAS_PMU_MASK_RESET | QUIRK_HAS_PMU_CNT_EN |
> +		  QUIRK_HAS_WTCLRINT_REG | QUIRK_HAS_DBGACK_BIT | QUIRK_HAS_WTMINCNT_REG,
> +};
> +
> +static const struct s3c2410_wdt_variant drv_data_gs201_cl0 = {
> +	.mask_reset_reg = GS_CLUSTER0_NONCPU_INT_EN,
> +	.mask_bit = 2,
> +	.mask_reset_inv = true,
> +	.rst_stat_reg = GS_RST_STAT_REG_OFFSET,
> +	.rst_stat_bit = 0,
> +	.cnt_en_reg = GS_CLUSTER0_NONCPU_OUT,
> +	.cnt_en_bit = 8,
> +	.quirks = QUIRK_HAS_PMU_RST_STAT | QUIRK_HAS_PMU_MASK_RESET | QUIRK_HAS_PMU_CNT_EN |
> +		  QUIRK_HAS_WTCLRINT_REG | QUIRK_HAS_DBGACK_BIT | QUIRK_HAS_WTMINCNT_REG,
> +};
> +
> +static const struct s3c2410_wdt_variant drv_data_gs201_cl1 = {
> +	.mask_reset_reg = GS_CLUSTER1_NONCPU_INT_EN,
> +	.mask_bit = 2,
> +	.mask_reset_inv = true,
> +	.rst_stat_reg = GS_RST_STAT_REG_OFFSET,
> +	.rst_stat_bit = 1,
> +	.cnt_en_reg = GS_CLUSTER1_NONCPU_OUT,
> +	.cnt_en_bit = 7,
> +	.quirks = QUIRK_HAS_PMU_RST_STAT | QUIRK_HAS_PMU_MASK_RESET | QUIRK_HAS_PMU_CNT_EN |
> +		  QUIRK_HAS_WTCLRINT_REG | QUIRK_HAS_DBGACK_BIT | QUIRK_HAS_WTMINCNT_REG,
> +};
> +
>  static const struct of_device_id s3c2410_wdt_match[] = {
>  	{ .compatible = "samsung,s3c2410-wdt",
>  	  .data = &drv_data_s3c2410 },
> @@ -278,6 +336,10 @@ static const struct of_device_id s3c2410_wdt_match[] = {
>  	  .data = &drv_data_exynos850_cl0 },
>  	{ .compatible = "samsung,exynosautov9-wdt",
>  	  .data = &drv_data_exynosautov9_cl0 },
> +	{ .compatible = "google,gs101-wdt",
> +	  .data = &drv_data_gs101_cl0 },
> +	{ .compatible = "google,gs201-wdt",
> +	  .data = &drv_data_gs201_cl0 },
>  	{},
>  };
>  MODULE_DEVICE_TABLE(of, s3c2410_wdt_match);
> @@ -375,6 +437,21 @@ static int s3c2410wdt_enable(struct s3c2410_wdt *wdt, bool en)
>  	return 0;
>  }
>  
> +static void s3c2410wdt_mask_dbgack(struct s3c2410_wdt *wdt, bool mask)
> +{
> +	unsigned long wtcon;
> +
> +	if (!(wdt->drv_data->quirks & QUIRK_HAS_DBGACK_BIT))
> +		return;
> +
> +	wtcon = readl(wdt->reg_base + S3C2410_WTCON);
> +	if (mask)
> +		wtcon |= S3C2410_WTCON_DBGACK_MASK;
> +	else
> +		wtcon &= ~S3C2410_WTCON_DBGACK_MASK;
> +	writel(wtcon, wdt->reg_base + S3C2410_WTCON);
> +}
> +
>  static int s3c2410wdt_keepalive(struct watchdog_device *wdd)
>  {
>  	struct s3c2410_wdt *wdt = watchdog_get_drvdata(wdd);
> @@ -585,9 +662,11 @@ s3c2410_get_wdt_drv_data(struct platform_device *pdev, struct s3c2410_wdt *wdt)
>  	}
>  
>  #ifdef CONFIG_OF
> -	/* Choose Exynos850/ExynosAutov9 driver data w.r.t. cluster index */
> +	/* Choose Exynos850/ExynosAutov9/gsx01 driver data w.r.t. cluster index */
>  	if (variant == &drv_data_exynos850_cl0 ||
> -	    variant == &drv_data_exynosautov9_cl0) {
> +	    variant == &drv_data_exynosautov9_cl0 ||
> +	    variant == &drv_data_gs101_cl0 ||
> +	    variant == &drv_data_gs201_cl0) {
>  		u32 index;
>  		int err;
>  
> @@ -600,9 +679,14 @@ s3c2410_get_wdt_drv_data(struct platform_device *pdev, struct s3c2410_wdt *wdt)
>  		case 0:
>  			break;
>  		case 1:
> -			variant = (variant == &drv_data_exynos850_cl0) ?
> -				&drv_data_exynos850_cl1 :
> -				&drv_data_exynosautov9_cl1;
> +			if (variant == &drv_data_exynos850_cl0)
> +				variant = &drv_data_exynos850_cl1;
> +			else if (variant == &drv_data_exynosautov9_cl0)
> +				variant = &drv_data_exynosautov9_cl1;
> +			else if (variant == &drv_data_gs101_cl0)
> +				variant = &drv_data_gs101_cl1;
> +			else if (variant == &drv_data_gs201_cl0)
> +				variant = &drv_data_gs201_cl1;
>  			break;
>  		default:
>  			return dev_err_probe(dev, -EINVAL, "wrong cluster index: %u\n", index);
> @@ -700,6 +784,8 @@ static int s3c2410wdt_probe(struct platform_device *pdev)
>  	wdt->wdt_device.bootstatus = s3c2410wdt_get_bootstatus(wdt);
>  	wdt->wdt_device.parent = dev;
>  
> +	s3c2410wdt_mask_dbgack(wdt, true);
> +
>  	/*
>  	 * If "tmr_atboot" param is non-zero, start the watchdog right now. Also
>  	 * set WDOG_HW_RUNNING bit, so that watchdog core can kick the watchdog.
> -- 
> 2.42.0.609.gbb76f46606-goog
> 

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH v2 00/20] Add minimal Tensor/GS101 SoC support and Oriole/Pixel6 board

[Tudor Ambarus]

Hi, Peter,

On 10/10/23 23:49, Peter Griffin wrote:
> Note 3: In `dt-bindings: pinctrl: samsung: add google,gs101-pinctrl
> compatible` I tried to narrow the interrupts check to
> google,gs101-pinctrl but I still see a warning: gs101-oriole.dtb:
> pinctrl@174d0000: interrupts: [[0, 0, 4],[..] is too long If anyone can
> educate me on what I've done wrong here it would be most appreciated!

I guess the initial definition of the number of interrupts should
include the largest min/maxItems. I no longer see the warning with this
change:

diff --git
a/Documentation/devicetree/bindings/pinctrl/samsung,pinctrl.yaml
b/Documentation/devicetree/bindings/pinctrl/samsung,pinctrl.yaml
index 2464bc43aacb..6dc648490668 100644
--- a/Documentation/devicetree/bindings/pinctrl/samsung,pinctrl.yaml
+++ b/Documentation/devicetree/bindings/pinctrl/samsung,pinctrl.yaml
@@ -59,7 +59,8 @@ properties:
   interrupts:
     description:
       Required for GPIO banks supporting external GPIO interrupts.
-    maxItems: 1
+    minItems: 1
+    maxItems: 50

   power-domains:
     maxItems: 1

Re: [PATCH v2 00/20] Add minimal Tensor/GS101 SoC support and Oriole/Pixel6 board

[Tudor Ambarus]

Hi, Peter,

On 10/10/23 23:49, Peter Griffin wrote:
> Note 3: In `dt-bindings: pinctrl: samsung: add google,gs101-pinctrl
> compatible` I tried to narrow the interrupts check to
> google,gs101-pinctrl but I still see a warning: gs101-oriole.dtb:
> pinctrl@174d0000: interrupts: [[0, 0, 4],[..] is too long If anyone can
> educate me on what I've done wrong here it would be most appreciated!

I guess the initial definition of the number of interrupts should
include the largest min/maxItems. I no longer see the warning with this
change:

diff --git
a/Documentation/devicetree/bindings/pinctrl/samsung,pinctrl.yaml
b/Documentation/devicetree/bindings/pinctrl/samsung,pinctrl.yaml
index 2464bc43aacb..6dc648490668 100644
--- a/Documentation/devicetree/bindings/pinctrl/samsung,pinctrl.yaml
+++ b/Documentation/devicetree/bindings/pinctrl/samsung,pinctrl.yaml
@@ -59,7 +59,8 @@ properties:
   interrupts:
     description:
       Required for GPIO banks supporting external GPIO interrupts.
-    maxItems: 1
+    minItems: 1
+    maxItems: 50

   power-domains:
     maxItems: 1

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH v2 00/20] Add minimal Tensor/GS101 SoC support and Oriole/Pixel6 board

[Greg KH]

On Tue, Oct 10, 2023 at 11:49:08PM +0100, Peter Griffin wrote:
> Hi folks,
> 
> Firstly, thanks to everyone who reviewed the v1 series! V2 incorporates all
> the review feedback received so far.
> 
> This series adds initial SoC support for the GS101 SoC and also initial board
> support for Pixel 6 phone (Oriole).
> 
> The gs101 / Tensor SoC is also used in Pixel6a (bluejay) and Pixel 6 Pro
> (raven) phones. Currently DT is added for the gs101 SoC and Oriole.
> As you can see from the patches the SoC is based on a Samsung Exynos SoC,
> and therefore lots of the low level Exynos drivers can be re-used.
> 
> The support added in this series consists of:
> * cpus
> * pinctrl
> * some CCF implementation
> * watchdog
> * uart
> * gpio

So you have sent a patch series that crosses multiple subsystems, who is
supposed to be taking these patches?  Or do you not want them actually
merged?

confused,

greg k-h

Re: [PATCH v2 00/20] Add minimal Tensor/GS101 SoC support and Oriole/Pixel6 board

[Greg KH]

On Tue, Oct 10, 2023 at 11:49:08PM +0100, Peter Griffin wrote:
> Hi folks,
> 
> Firstly, thanks to everyone who reviewed the v1 series! V2 incorporates all
> the review feedback received so far.
> 
> This series adds initial SoC support for the GS101 SoC and also initial board
> support for Pixel 6 phone (Oriole).
> 
> The gs101 / Tensor SoC is also used in Pixel6a (bluejay) and Pixel 6 Pro
> (raven) phones. Currently DT is added for the gs101 SoC and Oriole.
> As you can see from the patches the SoC is based on a Samsung Exynos SoC,
> and therefore lots of the low level Exynos drivers can be re-used.
> 
> The support added in this series consists of:
> * cpus
> * pinctrl
> * some CCF implementation
> * watchdog
> * uart
> * gpio

So you have sent a patch series that crosses multiple subsystems, who is
supposed to be taking these patches?  Or do you not want them actually
merged?

confused,

greg k-h

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH v2 16/20] tty: serial: samsung: Add gs101 compatible and SoC data

[Greg KH]

On Tue, Oct 10, 2023 at 11:49:24PM +0100, Peter Griffin wrote:
> Add serial driver data for Google Tensor gs101 SoC.
> 
> Signed-off-by: Peter Griffin <peter.griffin@linaro.org>
> ---
>  drivers/tty/serial/samsung_tty.c | 12 ++++++++++++
>  1 file changed, 12 insertions(+)
> 
> diff --git a/drivers/tty/serial/samsung_tty.c b/drivers/tty/serial/samsung_tty.c
> index 07fb8a9dac63..79a1a184d5c1 100644
> --- a/drivers/tty/serial/samsung_tty.c
> +++ b/drivers/tty/serial/samsung_tty.c
> @@ -2597,14 +2597,21 @@ static const struct s3c24xx_serial_drv_data exynos850_serial_drv_data = {
>  	.fifosize = { 256, 64, 64, 64 },
>  };
>  
> +static const struct s3c24xx_serial_drv_data gs101_serial_drv_data = {
> +	EXYNOS_COMMON_SERIAL_DRV_DATA(),
> +	.fifosize = { 256, 64, 64, 64 },
> +};

Why are you duplicating a structure that is already in the same file?
What is the benifit here?

>  #define EXYNOS4210_SERIAL_DRV_DATA (&exynos4210_serial_drv_data)
>  #define EXYNOS5433_SERIAL_DRV_DATA (&exynos5433_serial_drv_data)
>  #define EXYNOS850_SERIAL_DRV_DATA (&exynos850_serial_drv_data)
> +#define GS101_SERIAL_DRV_DATA (&gs101_serial_drv_data)

What is "GS101"?

>  #else
>  #define EXYNOS4210_SERIAL_DRV_DATA NULL
>  #define EXYNOS5433_SERIAL_DRV_DATA NULL
>  #define EXYNOS850_SERIAL_DRV_DATA NULL
> +#define GS101_SERIAL_DRV_DATA NULL
>  #endif
>  
>  #ifdef CONFIG_ARCH_APPLE
> @@ -2688,6 +2695,9 @@ static const struct platform_device_id s3c24xx_serial_driver_ids[] = {
>  	}, {
>  		.name		= "artpec8-uart",
>  		.driver_data	= (kernel_ulong_t)ARTPEC8_SERIAL_DRV_DATA,
> +	}, {
> +		.name		= "gs101-uart",
> +		.driver_data	= (kernel_ulong_t)GS101_SERIAL_DRV_DATA,
>  	},
>  	{ },
>  };
> @@ -2709,6 +2719,8 @@ static const struct of_device_id s3c24xx_uart_dt_match[] = {
>  		.data = EXYNOS850_SERIAL_DRV_DATA },
>  	{ .compatible = "axis,artpec8-uart",
>  		.data = ARTPEC8_SERIAL_DRV_DATA },
> +	{ .compatible = "google,gs101-uart",
> +		.data =  GS101_SERIAL_DRV_DATA },

Why aren't you just listing this hardware as the same one above?  There
doesn't need to be a new entry if you just fix up the DT for the board
to declare it as the proper type of device.  No need to keep adding new
entries that do the exact same thing, we don't normally like that at all
for other bus types, why is DT different?

thanks,

greg k-h

Re: [PATCH v2 16/20] tty: serial: samsung: Add gs101 compatible and SoC data

[Greg KH]

On Tue, Oct 10, 2023 at 11:49:24PM +0100, Peter Griffin wrote:
> Add serial driver data for Google Tensor gs101 SoC.
> 
> Signed-off-by: Peter Griffin <peter.griffin@linaro.org>
> ---
>  drivers/tty/serial/samsung_tty.c | 12 ++++++++++++
>  1 file changed, 12 insertions(+)
> 
> diff --git a/drivers/tty/serial/samsung_tty.c b/drivers/tty/serial/samsung_tty.c
> index 07fb8a9dac63..79a1a184d5c1 100644
> --- a/drivers/tty/serial/samsung_tty.c
> +++ b/drivers/tty/serial/samsung_tty.c
> @@ -2597,14 +2597,21 @@ static const struct s3c24xx_serial_drv_data exynos850_serial_drv_data = {
>  	.fifosize = { 256, 64, 64, 64 },
>  };
>  
> +static const struct s3c24xx_serial_drv_data gs101_serial_drv_data = {
> +	EXYNOS_COMMON_SERIAL_DRV_DATA(),
> +	.fifosize = { 256, 64, 64, 64 },
> +};

Why are you duplicating a structure that is already in the same file?
What is the benifit here?

>  #define EXYNOS4210_SERIAL_DRV_DATA (&exynos4210_serial_drv_data)
>  #define EXYNOS5433_SERIAL_DRV_DATA (&exynos5433_serial_drv_data)
>  #define EXYNOS850_SERIAL_DRV_DATA (&exynos850_serial_drv_data)
> +#define GS101_SERIAL_DRV_DATA (&gs101_serial_drv_data)

What is "GS101"?

>  #else
>  #define EXYNOS4210_SERIAL_DRV_DATA NULL
>  #define EXYNOS5433_SERIAL_DRV_DATA NULL
>  #define EXYNOS850_SERIAL_DRV_DATA NULL
> +#define GS101_SERIAL_DRV_DATA NULL
>  #endif
>  
>  #ifdef CONFIG_ARCH_APPLE
> @@ -2688,6 +2695,9 @@ static const struct platform_device_id s3c24xx_serial_driver_ids[] = {
>  	}, {
>  		.name		= "artpec8-uart",
>  		.driver_data	= (kernel_ulong_t)ARTPEC8_SERIAL_DRV_DATA,
> +	}, {
> +		.name		= "gs101-uart",
> +		.driver_data	= (kernel_ulong_t)GS101_SERIAL_DRV_DATA,
>  	},
>  	{ },
>  };
> @@ -2709,6 +2719,8 @@ static const struct of_device_id s3c24xx_uart_dt_match[] = {
>  		.data = EXYNOS850_SERIAL_DRV_DATA },
>  	{ .compatible = "axis,artpec8-uart",
>  		.data = ARTPEC8_SERIAL_DRV_DATA },
> +	{ .compatible = "google,gs101-uart",
> +		.data =  GS101_SERIAL_DRV_DATA },

Why aren't you just listing this hardware as the same one above?  There
doesn't need to be a new entry if you just fix up the DT for the board
to declare it as the proper type of device.  No need to keep adding new
entries that do the exact same thing, we don't normally like that at all
for other bus types, why is DT different?

thanks,

greg k-h

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH v2 08/20] dt-bindings: serial: samsung: Add google-gs101-uart compatible

[Greg KH]

On Tue, Oct 10, 2023 at 11:49:16PM +0100, Peter Griffin wrote:
> Add dedicated google-gs101-uart compatible to the dt-schema for
> representing uart of the Google Tensor gs101 SoC.
> 
> Signed-off-by: Peter Griffin <peter.griffin@linaro.org>
> ---
>  Documentation/devicetree/bindings/serial/samsung_uart.yaml | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/serial/samsung_uart.yaml b/Documentation/devicetree/bindings/serial/samsung_uart.yaml
> index 8bd88d5cbb11..72471ebe5734 100644
> --- a/Documentation/devicetree/bindings/serial/samsung_uart.yaml
> +++ b/Documentation/devicetree/bindings/serial/samsung_uart.yaml
> @@ -19,11 +19,13 @@ properties:
>    compatible:
>      oneOf:
>        - items:
> +          - const: google,gs101-uart
>            - const: samsung,exynosautov9-uart
>            - const: samsung,exynos850-uart
>        - enum:
>            - apple,s5l-uart
>            - axis,artpec8-uart
> +          - google,gs101-uart

These shouldn't be needed, just declare the device as the same as what
the chip really is (i.e. a samsung uart), that way no .yaml or kernel
driver changes are needed at all.

thanks,

greg k-h

Re: [PATCH v2 08/20] dt-bindings: serial: samsung: Add google-gs101-uart compatible

[Greg KH]

On Tue, Oct 10, 2023 at 11:49:16PM +0100, Peter Griffin wrote:
> Add dedicated google-gs101-uart compatible to the dt-schema for
> representing uart of the Google Tensor gs101 SoC.
> 
> Signed-off-by: Peter Griffin <peter.griffin@linaro.org>
> ---
>  Documentation/devicetree/bindings/serial/samsung_uart.yaml | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/serial/samsung_uart.yaml b/Documentation/devicetree/bindings/serial/samsung_uart.yaml
> index 8bd88d5cbb11..72471ebe5734 100644
> --- a/Documentation/devicetree/bindings/serial/samsung_uart.yaml
> +++ b/Documentation/devicetree/bindings/serial/samsung_uart.yaml
> @@ -19,11 +19,13 @@ properties:
>    compatible:
>      oneOf:
>        - items:
> +          - const: google,gs101-uart
>            - const: samsung,exynosautov9-uart
>            - const: samsung,exynos850-uart
>        - enum:
>            - apple,s5l-uart
>            - axis,artpec8-uart
> +          - google,gs101-uart

These shouldn't be needed, just declare the device as the same as what
the chip really is (i.e. a samsung uart), that way no .yaml or kernel
driver changes are needed at all.

thanks,

greg k-h

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH v2 17/20] arm64: dts: google: Add initial Google gs101 SoC support

[Greg KH]

On Tue, Oct 10, 2023 at 11:49:25PM +0100, Peter Griffin wrote:
> +		serial_0: serial@10a00000 {
> +			compatible = "google,gs101-uart";

You use this entry, but:

> +			reg = <0x0 0x10a00000 0xc0>;
> +			reg-io-width = <4>;
> +			samsung,uart-fifosize = <256>;

See, it's really the samsung IP block.  Please don't declare new
compatible entries when you don't need to, it just adds churn to the
kernel for no reason (and makes you do more work.)

thanks,

greg k-h

Re: [PATCH v2 17/20] arm64: dts: google: Add initial Google gs101 SoC support

[Greg KH]

On Tue, Oct 10, 2023 at 11:49:25PM +0100, Peter Griffin wrote:
> +		serial_0: serial@10a00000 {
> +			compatible = "google,gs101-uart";

You use this entry, but:

> +			reg = <0x0 0x10a00000 0xc0>;
> +			reg-io-width = <4>;
> +			samsung,uart-fifosize = <256>;

See, it's really the samsung IP block.  Please don't declare new
compatible entries when you don't need to, it just adds churn to the
kernel for no reason (and makes you do more work.)

thanks,

greg k-h

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH v2 00/20] Add minimal Tensor/GS101 SoC support and Oriole/Pixel6 board

[Peter Griffin]

Hi Tudor,

Thanks for your reply.

On Wed, 11 Oct 2023 at 07:10, Tudor Ambarus <tudor.ambarus@linaro.org> wrote:
>
> Hi, Peter,
>
> On 10/10/23 23:49, Peter Griffin wrote:
> > Note 3: In `dt-bindings: pinctrl: samsung: add google,gs101-pinctrl
> > compatible` I tried to narrow the interrupts check to
> > google,gs101-pinctrl but I still see a warning: gs101-oriole.dtb:
> > pinctrl@174d0000: interrupts: [[0, 0, 4],[..] is too long If anyone can
> > educate me on what I've done wrong here it would be most appreciated!
>
> I guess the initial definition of the number of interrupts should
> include the largest min/maxItems. I no longer see the warning with this
> change:

Yes that is how it was in v1. The review feedback though was to narrow
the scope to just google,gs101-pinctrl compatible using if: then: else: which
is what I can't get to work properly.

regards,

Peter.


>
> diff --git
> a/Documentation/devicetree/bindings/pinctrl/samsung,pinctrl.yaml
> b/Documentation/devicetree/bindings/pinctrl/samsung,pinctrl.yaml
> index 2464bc43aacb..6dc648490668 100644
> --- a/Documentation/devicetree/bindings/pinctrl/samsung,pinctrl.yaml
> +++ b/Documentation/devicetree/bindings/pinctrl/samsung,pinctrl.yaml
> @@ -59,7 +59,8 @@ properties:
>    interrupts:
>      description:
>        Required for GPIO banks supporting external GPIO interrupts.
> -    maxItems: 1
> +    minItems: 1
> +    maxItems: 50
>
>    power-domains:
>      maxItems: 1

Re: [PATCH v2 00/20] Add minimal Tensor/GS101 SoC support and Oriole/Pixel6 board

[Peter Griffin]

Hi Tudor,

Thanks for your reply.

On Wed, 11 Oct 2023 at 07:10, Tudor Ambarus <tudor.ambarus@linaro.org> wrote:
>
> Hi, Peter,
>
> On 10/10/23 23:49, Peter Griffin wrote:
> > Note 3: In `dt-bindings: pinctrl: samsung: add google,gs101-pinctrl
> > compatible` I tried to narrow the interrupts check to
> > google,gs101-pinctrl but I still see a warning: gs101-oriole.dtb:
> > pinctrl@174d0000: interrupts: [[0, 0, 4],[..] is too long If anyone can
> > educate me on what I've done wrong here it would be most appreciated!
>
> I guess the initial definition of the number of interrupts should
> include the largest min/maxItems. I no longer see the warning with this
> change:

Yes that is how it was in v1. The review feedback though was to narrow
the scope to just google,gs101-pinctrl compatible using if: then: else: which
is what I can't get to work properly.

regards,

Peter.


>
> diff --git
> a/Documentation/devicetree/bindings/pinctrl/samsung,pinctrl.yaml
> b/Documentation/devicetree/bindings/pinctrl/samsung,pinctrl.yaml
> index 2464bc43aacb..6dc648490668 100644
> --- a/Documentation/devicetree/bindings/pinctrl/samsung,pinctrl.yaml
> +++ b/Documentation/devicetree/bindings/pinctrl/samsung,pinctrl.yaml
> @@ -59,7 +59,8 @@ properties:
>    interrupts:
>      description:
>        Required for GPIO banks supporting external GPIO interrupts.
> -    maxItems: 1
> +    minItems: 1
> +    maxItems: 50
>
>    power-domains:
>      maxItems: 1

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH v2 00/20] Add minimal Tensor/GS101 SoC support and Oriole/Pixel6 board

[Tudor Ambarus]

On 10/11/23 09:16, Peter Griffin wrote:
> Hi Tudor,
> 
> Thanks for your reply.
> 
> On Wed, 11 Oct 2023 at 07:10, Tudor Ambarus <tudor.ambarus@linaro.org> wrote:
>>
>> Hi, Peter,
>>
>> On 10/10/23 23:49, Peter Griffin wrote:
>>> Note 3: In `dt-bindings: pinctrl: samsung: add google,gs101-pinctrl
>>> compatible` I tried to narrow the interrupts check to
>>> google,gs101-pinctrl but I still see a warning: gs101-oriole.dtb:
>>> pinctrl@174d0000: interrupts: [[0, 0, 4],[..] is too long If anyone can
>>> educate me on what I've done wrong here it would be most appreciated!
>>
>> I guess the initial definition of the number of interrupts should
>> include the largest min/maxItems. I no longer see the warning with this
>> change:
> 
> Yes that is how it was in v1. The review feedback though was to narrow
> the scope to just google,gs101-pinctrl compatible using if: then: else: which
> is what I can't get to work properly.
>

Right. The diff that I sent is on top of your changes (patch 6/20).
I expect that when the interrupts property is defined it should include
the min/maxItems of all the available SoCs. Then use "if Soc" to narrow
the range.

Re: [PATCH v2 00/20] Add minimal Tensor/GS101 SoC support and Oriole/Pixel6 board

[Tudor Ambarus]

On 10/11/23 09:16, Peter Griffin wrote:
> Hi Tudor,
> 
> Thanks for your reply.
> 
> On Wed, 11 Oct 2023 at 07:10, Tudor Ambarus <tudor.ambarus@linaro.org> wrote:
>>
>> Hi, Peter,
>>
>> On 10/10/23 23:49, Peter Griffin wrote:
>>> Note 3: In `dt-bindings: pinctrl: samsung: add google,gs101-pinctrl
>>> compatible` I tried to narrow the interrupts check to
>>> google,gs101-pinctrl but I still see a warning: gs101-oriole.dtb:
>>> pinctrl@174d0000: interrupts: [[0, 0, 4],[..] is too long If anyone can
>>> educate me on what I've done wrong here it would be most appreciated!
>>
>> I guess the initial definition of the number of interrupts should
>> include the largest min/maxItems. I no longer see the warning with this
>> change:
> 
> Yes that is how it was in v1. The review feedback though was to narrow
> the scope to just google,gs101-pinctrl compatible using if: then: else: which
> is what I can't get to work properly.
>

Right. The diff that I sent is on top of your changes (patch 6/20).
I expect that when the interrupts property is defined it should include
the min/maxItems of all the available SoCs. Then use "if Soc" to narrow
the range.

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH v2 08/20] dt-bindings: serial: samsung: Add google-gs101-uart compatible

[Tudor Ambarus]

Hi, Greg,

On 10/11/23 08:48, Greg KH wrote:
> On Tue, Oct 10, 2023 at 11:49:16PM +0100, Peter Griffin wrote:
>> Add dedicated google-gs101-uart compatible to the dt-schema for
>> representing uart of the Google Tensor gs101 SoC.
>>
>> Signed-off-by: Peter Griffin <peter.griffin@linaro.org>
>> ---
>>  Documentation/devicetree/bindings/serial/samsung_uart.yaml | 2 ++
>>  1 file changed, 2 insertions(+)
>>
>> diff --git a/Documentation/devicetree/bindings/serial/samsung_uart.yaml b/Documentation/devicetree/bindings/serial/samsung_uart.yaml
>> index 8bd88d5cbb11..72471ebe5734 100644
>> --- a/Documentation/devicetree/bindings/serial/samsung_uart.yaml
>> +++ b/Documentation/devicetree/bindings/serial/samsung_uart.yaml
>> @@ -19,11 +19,13 @@ properties:
>>    compatible:
>>      oneOf:
>>        - items:
>> +          - const: google,gs101-uart
>>            - const: samsung,exynosautov9-uart
>>            - const: samsung,exynos850-uart
>>        - enum:
>>            - apple,s5l-uart
>>            - axis,artpec8-uart
>> +          - google,gs101-uart
> 
> These shouldn't be needed, just declare the device as the same as what

We should have SoC specific compatibles so that any further quirks or
incompatibilities can be easily addressed. It's not only the IP itself
that can differ, it's also the integration of the IP into the final
product that could have an influence on the behavior.

Cheers,
ta

> the chip really is (i.e. a samsung uart), that way no .yaml or kernel
> driver changes are needed at all.
> 

Re: [PATCH v2 08/20] dt-bindings: serial: samsung: Add google-gs101-uart compatible

[Tudor Ambarus]

Hi, Greg,

On 10/11/23 08:48, Greg KH wrote:
> On Tue, Oct 10, 2023 at 11:49:16PM +0100, Peter Griffin wrote:
>> Add dedicated google-gs101-uart compatible to the dt-schema for
>> representing uart of the Google Tensor gs101 SoC.
>>
>> Signed-off-by: Peter Griffin <peter.griffin@linaro.org>
>> ---
>>  Documentation/devicetree/bindings/serial/samsung_uart.yaml | 2 ++
>>  1 file changed, 2 insertions(+)
>>
>> diff --git a/Documentation/devicetree/bindings/serial/samsung_uart.yaml b/Documentation/devicetree/bindings/serial/samsung_uart.yaml
>> index 8bd88d5cbb11..72471ebe5734 100644
>> --- a/Documentation/devicetree/bindings/serial/samsung_uart.yaml
>> +++ b/Documentation/devicetree/bindings/serial/samsung_uart.yaml
>> @@ -19,11 +19,13 @@ properties:
>>    compatible:
>>      oneOf:
>>        - items:
>> +          - const: google,gs101-uart
>>            - const: samsung,exynosautov9-uart
>>            - const: samsung,exynos850-uart
>>        - enum:
>>            - apple,s5l-uart
>>            - axis,artpec8-uart
>> +          - google,gs101-uart
> 
> These shouldn't be needed, just declare the device as the same as what

We should have SoC specific compatibles so that any further quirks or
incompatibilities can be easily addressed. It's not only the IP itself
that can differ, it's also the integration of the IP into the final
product that could have an influence on the behavior.

Cheers,
ta

> the chip really is (i.e. a samsung uart), that way no .yaml or kernel
> driver changes are needed at all.
> 

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH v2 08/20] dt-bindings: serial: samsung: Add google-gs101-uart compatible

[Greg KH]

On Wed, Oct 11, 2023 at 09:49:07AM +0100, Tudor Ambarus wrote:
> Hi, Greg,
> 
> On 10/11/23 08:48, Greg KH wrote:
> > On Tue, Oct 10, 2023 at 11:49:16PM +0100, Peter Griffin wrote:
> >> Add dedicated google-gs101-uart compatible to the dt-schema for
> >> representing uart of the Google Tensor gs101 SoC.
> >>
> >> Signed-off-by: Peter Griffin <peter.griffin@linaro.org>
> >> ---
> >>  Documentation/devicetree/bindings/serial/samsung_uart.yaml | 2 ++
> >>  1 file changed, 2 insertions(+)
> >>
> >> diff --git a/Documentation/devicetree/bindings/serial/samsung_uart.yaml b/Documentation/devicetree/bindings/serial/samsung_uart.yaml
> >> index 8bd88d5cbb11..72471ebe5734 100644
> >> --- a/Documentation/devicetree/bindings/serial/samsung_uart.yaml
> >> +++ b/Documentation/devicetree/bindings/serial/samsung_uart.yaml
> >> @@ -19,11 +19,13 @@ properties:
> >>    compatible:
> >>      oneOf:
> >>        - items:
> >> +          - const: google,gs101-uart
> >>            - const: samsung,exynosautov9-uart
> >>            - const: samsung,exynos850-uart
> >>        - enum:
> >>            - apple,s5l-uart
> >>            - axis,artpec8-uart
> >> +          - google,gs101-uart
> > 
> > These shouldn't be needed, just declare the device as the same as what
> 
> We should have SoC specific compatibles so that any further quirks or
> incompatibilities can be easily addressed.

"further" work on quirks or incompatibilities can be added when they are
found and needed.  We don't add stuff for no good reason to the kernel.

> It's not only the IP itself
> that can differ, it's also the integration of the IP into the final
> product that could have an influence on the behavior.

This is for the Pixel 6, a device that is no longer even shipping.  The
"final product" is long stable, so this should not be an issue.

thanks,

greg k-h

Re: [PATCH v2 08/20] dt-bindings: serial: samsung: Add google-gs101-uart compatible

[Greg KH]

On Wed, Oct 11, 2023 at 09:49:07AM +0100, Tudor Ambarus wrote:
> Hi, Greg,
> 
> On 10/11/23 08:48, Greg KH wrote:
> > On Tue, Oct 10, 2023 at 11:49:16PM +0100, Peter Griffin wrote:
> >> Add dedicated google-gs101-uart compatible to the dt-schema for
> >> representing uart of the Google Tensor gs101 SoC.
> >>
> >> Signed-off-by: Peter Griffin <peter.griffin@linaro.org>
> >> ---
> >>  Documentation/devicetree/bindings/serial/samsung_uart.yaml | 2 ++
> >>  1 file changed, 2 insertions(+)
> >>
> >> diff --git a/Documentation/devicetree/bindings/serial/samsung_uart.yaml b/Documentation/devicetree/bindings/serial/samsung_uart.yaml
> >> index 8bd88d5cbb11..72471ebe5734 100644
> >> --- a/Documentation/devicetree/bindings/serial/samsung_uart.yaml
> >> +++ b/Documentation/devicetree/bindings/serial/samsung_uart.yaml
> >> @@ -19,11 +19,13 @@ properties:
> >>    compatible:
> >>      oneOf:
> >>        - items:
> >> +          - const: google,gs101-uart
> >>            - const: samsung,exynosautov9-uart
> >>            - const: samsung,exynos850-uart
> >>        - enum:
> >>            - apple,s5l-uart
> >>            - axis,artpec8-uart
> >> +          - google,gs101-uart
> > 
> > These shouldn't be needed, just declare the device as the same as what
> 
> We should have SoC specific compatibles so that any further quirks or
> incompatibilities can be easily addressed.

"further" work on quirks or incompatibilities can be added when they are
found and needed.  We don't add stuff for no good reason to the kernel.

> It's not only the IP itself
> that can differ, it's also the integration of the IP into the final
> product that could have an influence on the behavior.

This is for the Pixel 6, a device that is no longer even shipping.  The
"final product" is long stable, so this should not be an issue.

thanks,

greg k-h

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH v2 00/20] Add minimal Tensor/GS101 SoC support and Oriole/Pixel6 board

[Peter Griffin]

Hi Greg,

Thanks for your reply!

On Wed, 11 Oct 2023 at 08:44, Greg KH <greg@kroah.com> wrote:
>
> On Tue, Oct 10, 2023 at 11:49:08PM +0100, Peter Griffin wrote:
> > Hi folks,
> >
> > Firstly, thanks to everyone who reviewed the v1 series! V2 incorporates all
> > the review feedback received so far.
> >
> > This series adds initial SoC support for the GS101 SoC and also initial board
> > support for Pixel 6 phone (Oriole).
> >
> > The gs101 / Tensor SoC is also used in Pixel6a (bluejay) and Pixel 6 Pro
> > (raven) phones. Currently DT is added for the gs101 SoC and Oriole.
> > As you can see from the patches the SoC is based on a Samsung Exynos SoC,
> > and therefore lots of the low level Exynos drivers can be re-used.
> >
> > The support added in this series consists of:
> > * cpus
> > * pinctrl
> > * some CCF implementation
> > * watchdog
> > * uart
> > * gpio
>
> So you have sent a patch series that crosses multiple subsystems, who is
> supposed to be taking these patches?  Or do you not want them actually
> merged?

Krzysztof indicated here:
https://lore.kernel.org/all/b1598405-b01f-426a-aaba-89f2d2dc9c2e@linaro.org/
that he would like to be the one applying the entire series through the Samsung
SoC tree. If that's fine with everyone (it's OK with me).

kind regards,

Peter.

Re: [PATCH v2 00/20] Add minimal Tensor/GS101 SoC support and Oriole/Pixel6 board

[Peter Griffin]

Hi Greg,

Thanks for your reply!

On Wed, 11 Oct 2023 at 08:44, Greg KH <greg@kroah.com> wrote:
>
> On Tue, Oct 10, 2023 at 11:49:08PM +0100, Peter Griffin wrote:
> > Hi folks,
> >
> > Firstly, thanks to everyone who reviewed the v1 series! V2 incorporates all
> > the review feedback received so far.
> >
> > This series adds initial SoC support for the GS101 SoC and also initial board
> > support for Pixel 6 phone (Oriole).
> >
> > The gs101 / Tensor SoC is also used in Pixel6a (bluejay) and Pixel 6 Pro
> > (raven) phones. Currently DT is added for the gs101 SoC and Oriole.
> > As you can see from the patches the SoC is based on a Samsung Exynos SoC,
> > and therefore lots of the low level Exynos drivers can be re-used.
> >
> > The support added in this series consists of:
> > * cpus
> > * pinctrl
> > * some CCF implementation
> > * watchdog
> > * uart
> > * gpio
>
> So you have sent a patch series that crosses multiple subsystems, who is
> supposed to be taking these patches?  Or do you not want them actually
> merged?

Krzysztof indicated here:
https://lore.kernel.org/all/b1598405-b01f-426a-aaba-89f2d2dc9c2e@linaro.org/
that he would like to be the one applying the entire series through the Samsung
SoC tree. If that's fine with everyone (it's OK with me).

kind regards,

Peter.

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH v2 00/20] Add minimal Tensor/GS101 SoC support and Oriole/Pixel6 board

[Greg KH]

On Wed, Oct 11, 2023 at 10:06:18AM +0100, Peter Griffin wrote:
> Hi Greg,
> 
> Thanks for your reply!
> 
> On Wed, 11 Oct 2023 at 08:44, Greg KH <greg@kroah.com> wrote:
> >
> > On Tue, Oct 10, 2023 at 11:49:08PM +0100, Peter Griffin wrote:
> > > Hi folks,
> > >
> > > Firstly, thanks to everyone who reviewed the v1 series! V2 incorporates all
> > > the review feedback received so far.
> > >
> > > This series adds initial SoC support for the GS101 SoC and also initial board
> > > support for Pixel 6 phone (Oriole).
> > >
> > > The gs101 / Tensor SoC is also used in Pixel6a (bluejay) and Pixel 6 Pro
> > > (raven) phones. Currently DT is added for the gs101 SoC and Oriole.
> > > As you can see from the patches the SoC is based on a Samsung Exynos SoC,
> > > and therefore lots of the low level Exynos drivers can be re-used.
> > >
> > > The support added in this series consists of:
> > > * cpus
> > > * pinctrl
> > > * some CCF implementation
> > > * watchdog
> > > * uart
> > > * gpio
> >
> > So you have sent a patch series that crosses multiple subsystems, who is
> > supposed to be taking these patches?  Or do you not want them actually
> > merged?
> 
> Krzysztof indicated here:
> https://lore.kernel.org/all/b1598405-b01f-426a-aaba-89f2d2dc9c2e@linaro.org/
> that he would like to be the one applying the entire series through the Samsung
> SoC tree. If that's fine with everyone (it's OK with me).

As the serial changes are not ok (see my comments on them), I don't
think they should be going through any tree at this point in time :)

Also, in your 00/XX email, say what tree you expect them to go through
so we have a chance to know that please.

thanks,

greg k-h

Re: [PATCH v2 00/20] Add minimal Tensor/GS101 SoC support and Oriole/Pixel6 board

[Greg KH]

On Wed, Oct 11, 2023 at 10:06:18AM +0100, Peter Griffin wrote:
> Hi Greg,
> 
> Thanks for your reply!
> 
> On Wed, 11 Oct 2023 at 08:44, Greg KH <greg@kroah.com> wrote:
> >
> > On Tue, Oct 10, 2023 at 11:49:08PM +0100, Peter Griffin wrote:
> > > Hi folks,
> > >
> > > Firstly, thanks to everyone who reviewed the v1 series! V2 incorporates all
> > > the review feedback received so far.
> > >
> > > This series adds initial SoC support for the GS101 SoC and also initial board
> > > support for Pixel 6 phone (Oriole).
> > >
> > > The gs101 / Tensor SoC is also used in Pixel6a (bluejay) and Pixel 6 Pro
> > > (raven) phones. Currently DT is added for the gs101 SoC and Oriole.
> > > As you can see from the patches the SoC is based on a Samsung Exynos SoC,
> > > and therefore lots of the low level Exynos drivers can be re-used.
> > >
> > > The support added in this series consists of:
> > > * cpus
> > > * pinctrl
> > > * some CCF implementation
> > > * watchdog
> > > * uart
> > > * gpio
> >
> > So you have sent a patch series that crosses multiple subsystems, who is
> > supposed to be taking these patches?  Or do you not want them actually
> > merged?
> 
> Krzysztof indicated here:
> https://lore.kernel.org/all/b1598405-b01f-426a-aaba-89f2d2dc9c2e@linaro.org/
> that he would like to be the one applying the entire series through the Samsung
> SoC tree. If that's fine with everyone (it's OK with me).

As the serial changes are not ok (see my comments on them), I don't
think they should be going through any tree at this point in time :)

Also, in your 00/XX email, say what tree you expect them to go through
so we have a chance to know that please.

thanks,

greg k-h

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH v2 08/20] dt-bindings: serial: samsung: Add google-gs101-uart compatible

[Peter Griffin]

Hi Greg,

Thanks for your review feedback!

On Wed, 11 Oct 2023 at 08:48, Greg KH <gregkh@linuxfoundation.org> wrote:
>
> On Tue, Oct 10, 2023 at 11:49:16PM +0100, Peter Griffin wrote:
> > Add dedicated google-gs101-uart compatible to the dt-schema for
> > representing uart of the Google Tensor gs101 SoC.
> >
> > Signed-off-by: Peter Griffin <peter.griffin@linaro.org>
> > ---
> >  Documentation/devicetree/bindings/serial/samsung_uart.yaml | 2 ++
> >  1 file changed, 2 insertions(+)
> >
> > diff --git a/Documentation/devicetree/bindings/serial/samsung_uart.yaml b/Documentation/devicetree/bindings/serial/samsung_uart.yaml
> > index 8bd88d5cbb11..72471ebe5734 100644
> > --- a/Documentation/devicetree/bindings/serial/samsung_uart.yaml
> > +++ b/Documentation/devicetree/bindings/serial/samsung_uart.yaml
> > @@ -19,11 +19,13 @@ properties:
> >    compatible:
> >      oneOf:
> >        - items:
> > +          - const: google,gs101-uart
> >            - const: samsung,exynosautov9-uart
> >            - const: samsung,exynos850-uart
> >        - enum:
> >            - apple,s5l-uart
> >            - axis,artpec8-uart
> > +          - google,gs101-uart
>
> These shouldn't be needed, just declare the device as the same as what
> the chip really is (i.e. a samsung uart), that way no .yaml or kernel
> driver changes are needed at all.

What you describe is actually how I had it in the v1 submission, which is also
similar to what exynosautov9.dtsi is doing by re-using the
"samsung,exynos850-uart" compatible, and associated data in the driver.

However the review feedback in v1 from Krzysztof and Tudor was to add a
dedicated compatible for it. I guess I could have re-used the existing
EXYNOS850_SERIAL_DRV_DATA structure though rather than duplicating
that as well.

I'll let Krzysztof comment on why a dedicated compatible is required.

regards,

Peter

Re: [PATCH v2 08/20] dt-bindings: serial: samsung: Add google-gs101-uart compatible

[Peter Griffin]

Hi Greg,

Thanks for your review feedback!

On Wed, 11 Oct 2023 at 08:48, Greg KH <gregkh@linuxfoundation.org> wrote:
>
> On Tue, Oct 10, 2023 at 11:49:16PM +0100, Peter Griffin wrote:
> > Add dedicated google-gs101-uart compatible to the dt-schema for
> > representing uart of the Google Tensor gs101 SoC.
> >
> > Signed-off-by: Peter Griffin <peter.griffin@linaro.org>
> > ---
> >  Documentation/devicetree/bindings/serial/samsung_uart.yaml | 2 ++
> >  1 file changed, 2 insertions(+)
> >
> > diff --git a/Documentation/devicetree/bindings/serial/samsung_uart.yaml b/Documentation/devicetree/bindings/serial/samsung_uart.yaml
> > index 8bd88d5cbb11..72471ebe5734 100644
> > --- a/Documentation/devicetree/bindings/serial/samsung_uart.yaml
> > +++ b/Documentation/devicetree/bindings/serial/samsung_uart.yaml
> > @@ -19,11 +19,13 @@ properties:
> >    compatible:
> >      oneOf:
> >        - items:
> > +          - const: google,gs101-uart
> >            - const: samsung,exynosautov9-uart
> >            - const: samsung,exynos850-uart
> >        - enum:
> >            - apple,s5l-uart
> >            - axis,artpec8-uart
> > +          - google,gs101-uart
>
> These shouldn't be needed, just declare the device as the same as what
> the chip really is (i.e. a samsung uart), that way no .yaml or kernel
> driver changes are needed at all.

What you describe is actually how I had it in the v1 submission, which is also
similar to what exynosautov9.dtsi is doing by re-using the
"samsung,exynos850-uart" compatible, and associated data in the driver.

However the review feedback in v1 from Krzysztof and Tudor was to add a
dedicated compatible for it. I guess I could have re-used the existing
EXYNOS850_SERIAL_DRV_DATA structure though rather than duplicating
that as well.

I'll let Krzysztof comment on why a dedicated compatible is required.

regards,

Peter

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH v2 08/20] dt-bindings: serial: samsung: Add google-gs101-uart compatible

[Arnd Bergmann]

On Wed, Oct 11, 2023, at 10:57, Greg KH wrote:
> On Wed, Oct 11, 2023 at 09:49:07AM +0100, Tudor Ambarus wrote:
>> On 10/11/23 08:48, Greg KH wrote:
>> > On Tue, Oct 10, 2023 at 11:49:16PM +0100, Peter Griffin wrote:
>> >> Add dedicated google-gs101-uart compatible to the dt-schema for
>> >> representing uart of the Google Tensor gs101 SoC.
>> >>
>> >> Signed-off-by: Peter Griffin <peter.griffin@linaro.org>
>> >> ---
>> >>  Documentation/devicetree/bindings/serial/samsung_uart.yaml | 2 ++
>> >>  1 file changed, 2 insertions(+)
>> >>
>> >>      oneOf:
>> >>        - items:
>> >> +          - const: google,gs101-uart
>> >>            - const: samsung,exynosautov9-uart
>> >>            - const: samsung,exynos850-uart
>> >>        - enum:
>> >>            - apple,s5l-uart
>> >>            - axis,artpec8-uart
>> >> +          - google,gs101-uart
>> > 
>> > These shouldn't be needed, just declare the device as the same as what
>> 
>> We should have SoC specific compatibles so that any further quirks or
>> incompatibilities can be easily addressed.
>
> "further" work on quirks or incompatibilities can be added when they are
> found and needed.  We don't add stuff for no good reason to the kernel.
>
>> It's not only the IP itself
>> that can differ, it's also the integration of the IP into the final
>> product that could have an influence on the behavior.
>
> This is for the Pixel 6, a device that is no longer even shipping.  The
> "final product" is long stable, so this should not be an issue.

The driver does have soc specific settings for each compatible
string, in this case it looks like it overrides the FIFO size
based on driver specific data and the order in which the
ports are probed [1]. I don't understand why the driver does
this, but my impression is that if we wanted to change it to no
longer rely on that data, we'd also need a new compatible
string.

Ideally, the actual compatible list in the DTB lists both the
specific implementation (google,gs101-uart) in order to allow
such hacks if needed, and a more generic string (e.g. 
"samsung,exynos850-uart" for an older device that is entirely
compatible) in order to not actually need driver changes.

      Arnd

[1] https://lore.kernel.org/linux-arm-kernel/20231010224928.2296997-17-peter.griffin@linaro.org/

Re: [PATCH v2 08/20] dt-bindings: serial: samsung: Add google-gs101-uart compatible

[Arnd Bergmann]

On Wed, Oct 11, 2023, at 10:57, Greg KH wrote:
> On Wed, Oct 11, 2023 at 09:49:07AM +0100, Tudor Ambarus wrote:
>> On 10/11/23 08:48, Greg KH wrote:
>> > On Tue, Oct 10, 2023 at 11:49:16PM +0100, Peter Griffin wrote:
>> >> Add dedicated google-gs101-uart compatible to the dt-schema for
>> >> representing uart of the Google Tensor gs101 SoC.
>> >>
>> >> Signed-off-by: Peter Griffin <peter.griffin@linaro.org>
>> >> ---
>> >>  Documentation/devicetree/bindings/serial/samsung_uart.yaml | 2 ++
>> >>  1 file changed, 2 insertions(+)
>> >>
>> >>      oneOf:
>> >>        - items:
>> >> +          - const: google,gs101-uart
>> >>            - const: samsung,exynosautov9-uart
>> >>            - const: samsung,exynos850-uart
>> >>        - enum:
>> >>            - apple,s5l-uart
>> >>            - axis,artpec8-uart
>> >> +          - google,gs101-uart
>> > 
>> > These shouldn't be needed, just declare the device as the same as what
>> 
>> We should have SoC specific compatibles so that any further quirks or
>> incompatibilities can be easily addressed.
>
> "further" work on quirks or incompatibilities can be added when they are
> found and needed.  We don't add stuff for no good reason to the kernel.
>
>> It's not only the IP itself
>> that can differ, it's also the integration of the IP into the final
>> product that could have an influence on the behavior.
>
> This is for the Pixel 6, a device that is no longer even shipping.  The
> "final product" is long stable, so this should not be an issue.

The driver does have soc specific settings for each compatible
string, in this case it looks like it overrides the FIFO size
based on driver specific data and the order in which the
ports are probed [1]. I don't understand why the driver does
this, but my impression is that if we wanted to change it to no
longer rely on that data, we'd also need a new compatible
string.

Ideally, the actual compatible list in the DTB lists both the
specific implementation (google,gs101-uart) in order to allow
such hacks if needed, and a more generic string (e.g. 
"samsung,exynos850-uart" for an older device that is entirely
compatible) in order to not actually need driver changes.

      Arnd

[1] https://lore.kernel.org/linux-arm-kernel/20231010224928.2296997-17-peter.griffin@linaro.org/

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH v2 08/20] dt-bindings: serial: samsung: Add google-gs101-uart compatible

[Greg Kroah-Hartman]

On Wed, Oct 11, 2023 at 11:30:25AM +0200, Arnd Bergmann wrote:
> On Wed, Oct 11, 2023, at 10:57, Greg KH wrote:
> > On Wed, Oct 11, 2023 at 09:49:07AM +0100, Tudor Ambarus wrote:
> >> On 10/11/23 08:48, Greg KH wrote:
> >> > On Tue, Oct 10, 2023 at 11:49:16PM +0100, Peter Griffin wrote:
> >> >> Add dedicated google-gs101-uart compatible to the dt-schema for
> >> >> representing uart of the Google Tensor gs101 SoC.
> >> >>
> >> >> Signed-off-by: Peter Griffin <peter.griffin@linaro.org>
> >> >> ---
> >> >>  Documentation/devicetree/bindings/serial/samsung_uart.yaml | 2 ++
> >> >>  1 file changed, 2 insertions(+)
> >> >>
> >> >>      oneOf:
> >> >>        - items:
> >> >> +          - const: google,gs101-uart
> >> >>            - const: samsung,exynosautov9-uart
> >> >>            - const: samsung,exynos850-uart
> >> >>        - enum:
> >> >>            - apple,s5l-uart
> >> >>            - axis,artpec8-uart
> >> >> +          - google,gs101-uart
> >> > 
> >> > These shouldn't be needed, just declare the device as the same as what
> >> 
> >> We should have SoC specific compatibles so that any further quirks or
> >> incompatibilities can be easily addressed.
> >
> > "further" work on quirks or incompatibilities can be added when they are
> > found and needed.  We don't add stuff for no good reason to the kernel.
> >
> >> It's not only the IP itself
> >> that can differ, it's also the integration of the IP into the final
> >> product that could have an influence on the behavior.
> >
> > This is for the Pixel 6, a device that is no longer even shipping.  The
> > "final product" is long stable, so this should not be an issue.
> 
> The driver does have soc specific settings for each compatible
> string, in this case it looks like it overrides the FIFO size
> based on driver specific data and the order in which the
> ports are probed [1]. I don't understand why the driver does
> this, but my impression is that if we wanted to change it to no
> longer rely on that data, we'd also need a new compatible
> string.

As I reviewed that patch already, it is just duplicating an existing
quirk/device that the driver already supports, so there is no need for
any "new device type" to be added to that driver, just use the existing
hardware description in the dt and all should be fine.

thanks,

greg k-h

Re: [PATCH v2 08/20] dt-bindings: serial: samsung: Add google-gs101-uart compatible

[Greg Kroah-Hartman]

On Wed, Oct 11, 2023 at 11:30:25AM +0200, Arnd Bergmann wrote:
> On Wed, Oct 11, 2023, at 10:57, Greg KH wrote:
> > On Wed, Oct 11, 2023 at 09:49:07AM +0100, Tudor Ambarus wrote:
> >> On 10/11/23 08:48, Greg KH wrote:
> >> > On Tue, Oct 10, 2023 at 11:49:16PM +0100, Peter Griffin wrote:
> >> >> Add dedicated google-gs101-uart compatible to the dt-schema for
> >> >> representing uart of the Google Tensor gs101 SoC.
> >> >>
> >> >> Signed-off-by: Peter Griffin <peter.griffin@linaro.org>
> >> >> ---
> >> >>  Documentation/devicetree/bindings/serial/samsung_uart.yaml | 2 ++
> >> >>  1 file changed, 2 insertions(+)
> >> >>
> >> >>      oneOf:
> >> >>        - items:
> >> >> +          - const: google,gs101-uart
> >> >>            - const: samsung,exynosautov9-uart
> >> >>            - const: samsung,exynos850-uart
> >> >>        - enum:
> >> >>            - apple,s5l-uart
> >> >>            - axis,artpec8-uart
> >> >> +          - google,gs101-uart
> >> > 
> >> > These shouldn't be needed, just declare the device as the same as what
> >> 
> >> We should have SoC specific compatibles so that any further quirks or
> >> incompatibilities can be easily addressed.
> >
> > "further" work on quirks or incompatibilities can be added when they are
> > found and needed.  We don't add stuff for no good reason to the kernel.
> >
> >> It's not only the IP itself
> >> that can differ, it's also the integration of the IP into the final
> >> product that could have an influence on the behavior.
> >
> > This is for the Pixel 6, a device that is no longer even shipping.  The
> > "final product" is long stable, so this should not be an issue.
> 
> The driver does have soc specific settings for each compatible
> string, in this case it looks like it overrides the FIFO size
> based on driver specific data and the order in which the
> ports are probed [1]. I don't understand why the driver does
> this, but my impression is that if we wanted to change it to no
> longer rely on that data, we'd also need a new compatible
> string.

As I reviewed that patch already, it is just duplicating an existing
quirk/device that the driver already supports, so there is no need for
any "new device type" to be added to that driver, just use the existing
hardware description in the dt and all should be fine.

thanks,

greg k-h

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH v2 08/20] dt-bindings: serial: samsung: Add google-gs101-uart compatible

[Arnd Bergmann]

On Wed, Oct 11, 2023, at 11:42, Greg Kroah-Hartman wrote:
> On Wed, Oct 11, 2023 at 11:30:25AM +0200, Arnd Bergmann wrote:
>> On Wed, Oct 11, 2023, at 10:57, Greg KH wrote:
>> >
>> >> It's not only the IP itself
>> >> that can differ, it's also the integration of the IP into the final
>> >> product that could have an influence on the behavior.
>> >
>> > This is for the Pixel 6, a device that is no longer even shipping.  The
>> > "final product" is long stable, so this should not be an issue.
>> 
>> The driver does have soc specific settings for each compatible
>> string, in this case it looks like it overrides the FIFO size
>> based on driver specific data and the order in which the
>> ports are probed [1]. I don't understand why the driver does
>> this, but my impression is that if we wanted to change it to no
>> longer rely on that data, we'd also need a new compatible
>> string.
>
> As I reviewed that patch already, it is just duplicating an existing
> quirk/device that the driver already supports, so there is no need for
> any "new device type" to be added to that driver, just use the existing
> hardware description in the dt and all should be fine.

The thing is, I suspect that the FIFO size override is actually
wrong for the exynos850 as well, and is almost certainly wrong
for both exynosautov9 and google-gs101:

- The driver overrides an exynos850 compatible uart to use a
  256 byte FIFO on whichever port is probed first, 64 byte
  on the next three ports, and the setting from DT on any
  later ones, falling back to 16 bytes if the DT does not set
  anything.

- exynos850 only actually has three of these ports, not
  four. It does not lists  FIFO size in the dts at all.

- exynosautov9 has a total of 11 ports, each of these
  compatible with both "samsung,exynosautov9-uart" as
  the specific value and "samsung,exynos850-uart" as
  the generic fallback. The DT lists a FIFO size of 256
  bytes for ports 0, 1, and 6, but lists FIFO size 64
  for each of the other ones.

- google-gs101 only lists a single uart in the dts,
  and sets it to a 256 byte FIFO.

- testla-fsd claims to be compatible with exynos4210,
  which also overrides the first two ports in probe
  order to 256 and 64 bytes respectively (like exynos850),
  but it only has two ports.

- artpec8 has a separate compatible string so it overrides
  all ports to 64 bytes.

I don't know why probe order would have anything to do
with this, so most likely these are all the same thing
and should just put a fixed FIFO size into the DT for
each port instance.

      Arnd

Re: [PATCH v2 08/20] dt-bindings: serial: samsung: Add google-gs101-uart compatible

[Arnd Bergmann]

On Wed, Oct 11, 2023, at 11:42, Greg Kroah-Hartman wrote:
> On Wed, Oct 11, 2023 at 11:30:25AM +0200, Arnd Bergmann wrote:
>> On Wed, Oct 11, 2023, at 10:57, Greg KH wrote:
>> >
>> >> It's not only the IP itself
>> >> that can differ, it's also the integration of the IP into the final
>> >> product that could have an influence on the behavior.
>> >
>> > This is for the Pixel 6, a device that is no longer even shipping.  The
>> > "final product" is long stable, so this should not be an issue.
>> 
>> The driver does have soc specific settings for each compatible
>> string, in this case it looks like it overrides the FIFO size
>> based on driver specific data and the order in which the
>> ports are probed [1]. I don't understand why the driver does
>> this, but my impression is that if we wanted to change it to no
>> longer rely on that data, we'd also need a new compatible
>> string.
>
> As I reviewed that patch already, it is just duplicating an existing
> quirk/device that the driver already supports, so there is no need for
> any "new device type" to be added to that driver, just use the existing
> hardware description in the dt and all should be fine.

The thing is, I suspect that the FIFO size override is actually
wrong for the exynos850 as well, and is almost certainly wrong
for both exynosautov9 and google-gs101:

- The driver overrides an exynos850 compatible uart to use a
  256 byte FIFO on whichever port is probed first, 64 byte
  on the next three ports, and the setting from DT on any
  later ones, falling back to 16 bytes if the DT does not set
  anything.

- exynos850 only actually has three of these ports, not
  four. It does not lists  FIFO size in the dts at all.

- exynosautov9 has a total of 11 ports, each of these
  compatible with both "samsung,exynosautov9-uart" as
  the specific value and "samsung,exynos850-uart" as
  the generic fallback. The DT lists a FIFO size of 256
  bytes for ports 0, 1, and 6, but lists FIFO size 64
  for each of the other ones.

- google-gs101 only lists a single uart in the dts,
  and sets it to a 256 byte FIFO.

- testla-fsd claims to be compatible with exynos4210,
  which also overrides the first two ports in probe
  order to 256 and 64 bytes respectively (like exynos850),
  but it only has two ports.

- artpec8 has a separate compatible string so it overrides
  all ports to 64 bytes.

I don't know why probe order would have anything to do
with this, so most likely these are all the same thing
and should just put a fixed FIFO size into the DT for
each port instance.

      Arnd

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH v2 08/20] dt-bindings: serial: samsung: Add google-gs101-uart compatible

[Peter Griffin]

Hi Arnd,

Thanks for your feedback.

On Wed, 11 Oct 2023 at 11:19, Arnd Bergmann <arnd@arndb.de> wrote:
>
> On Wed, Oct 11, 2023, at 11:42, Greg Kroah-Hartman wrote:
> > On Wed, Oct 11, 2023 at 11:30:25AM +0200, Arnd Bergmann wrote:
> >> On Wed, Oct 11, 2023, at 10:57, Greg KH wrote:
> >> >
> >> >> It's not only the IP itself
> >> >> that can differ, it's also the integration of the IP into the final
> >> >> product that could have an influence on the behavior.
> >> >
> >> > This is for the Pixel 6, a device that is no longer even shipping.  The
> >> > "final product" is long stable, so this should not be an issue.
> >>
> >> The driver does have soc specific settings for each compatible
> >> string, in this case it looks like it overrides the FIFO size
> >> based on driver specific data and the order in which the
> >> ports are probed [1]. I don't understand why the driver does
> >> this, but my impression is that if we wanted to change it to no
> >> longer rely on that data, we'd also need a new compatible
> >> string.
> >
> > As I reviewed that patch already, it is just duplicating an existing
> > quirk/device that the driver already supports, so there is no need for
> > any "new device type" to be added to that driver, just use the existing
> > hardware description in the dt and all should be fine.
>
> The thing is, I suspect that the FIFO size override is actually
> wrong for the exynos850 as well, and is almost certainly wrong
> for both exynosautov9 and google-gs101:
>
> - The driver overrides an exynos850 compatible uart to use a
>   256 byte FIFO on whichever port is probed first, 64 byte
>   on the next three ports, and the setting from DT on any
>   later ones, falling back to 16 bytes if the DT does not set
>   anything.
>
> - exynos850 only actually has three of these ports, not
>   four. It does not lists  FIFO size in the dts at all.
>
> - exynosautov9 has a total of 11 ports, each of these
>   compatible with both "samsung,exynosautov9-uart" as
>   the specific value and "samsung,exynos850-uart" as
>   the generic fallback. The DT lists a FIFO size of 256
>   bytes for ports 0, 1, and 6, but lists FIFO size 64
>   for each of the other ones.
>
> - google-gs101 only lists a single uart in the dts,
>   and sets it to a 256 byte FIFO.
>
> - testla-fsd claims to be compatible with exynos4210,
>   which also overrides the first two ports in probe
>   order to 256 and 64 bytes respectively (like exynos850),
>   but it only has two ports.
>
> - artpec8 has a separate compatible string so it overrides
>   all ports to 64 bytes.
>
> I don't know why probe order would have anything to do
> with this, so most likely these are all the same thing
> and should just put a fixed FIFO size into the DT for
> each port instance.

I agree, I just looked again at gs101 and in total we can have
19 uarts on this SoC. 3 of them are 256byte rx/tx fifo and the
other 16 have 64byte tx/rx fifo size, but this is a SoC design
choice and has nothing to do with probe order.

I will update in v3 to get fifo size from DT.

regards,

Peter.

Re: [PATCH v2 08/20] dt-bindings: serial: samsung: Add google-gs101-uart compatible

[Peter Griffin]

Hi Arnd,

Thanks for your feedback.

On Wed, 11 Oct 2023 at 11:19, Arnd Bergmann <arnd@arndb.de> wrote:
>
> On Wed, Oct 11, 2023, at 11:42, Greg Kroah-Hartman wrote:
> > On Wed, Oct 11, 2023 at 11:30:25AM +0200, Arnd Bergmann wrote:
> >> On Wed, Oct 11, 2023, at 10:57, Greg KH wrote:
> >> >
> >> >> It's not only the IP itself
> >> >> that can differ, it's also the integration of the IP into the final
> >> >> product that could have an influence on the behavior.
> >> >
> >> > This is for the Pixel 6, a device that is no longer even shipping.  The
> >> > "final product" is long stable, so this should not be an issue.
> >>
> >> The driver does have soc specific settings for each compatible
> >> string, in this case it looks like it overrides the FIFO size
> >> based on driver specific data and the order in which the
> >> ports are probed [1]. I don't understand why the driver does
> >> this, but my impression is that if we wanted to change it to no
> >> longer rely on that data, we'd also need a new compatible
> >> string.
> >
> > As I reviewed that patch already, it is just duplicating an existing
> > quirk/device that the driver already supports, so there is no need for
> > any "new device type" to be added to that driver, just use the existing
> > hardware description in the dt and all should be fine.
>
> The thing is, I suspect that the FIFO size override is actually
> wrong for the exynos850 as well, and is almost certainly wrong
> for both exynosautov9 and google-gs101:
>
> - The driver overrides an exynos850 compatible uart to use a
>   256 byte FIFO on whichever port is probed first, 64 byte
>   on the next three ports, and the setting from DT on any
>   later ones, falling back to 16 bytes if the DT does not set
>   anything.
>
> - exynos850 only actually has three of these ports, not
>   four. It does not lists  FIFO size in the dts at all.
>
> - exynosautov9 has a total of 11 ports, each of these
>   compatible with both "samsung,exynosautov9-uart" as
>   the specific value and "samsung,exynos850-uart" as
>   the generic fallback. The DT lists a FIFO size of 256
>   bytes for ports 0, 1, and 6, but lists FIFO size 64
>   for each of the other ones.
>
> - google-gs101 only lists a single uart in the dts,
>   and sets it to a 256 byte FIFO.
>
> - testla-fsd claims to be compatible with exynos4210,
>   which also overrides the first two ports in probe
>   order to 256 and 64 bytes respectively (like exynos850),
>   but it only has two ports.
>
> - artpec8 has a separate compatible string so it overrides
>   all ports to 64 bytes.
>
> I don't know why probe order would have anything to do
> with this, so most likely these are all the same thing
> and should just put a fixed FIFO size into the DT for
> each port instance.

I agree, I just looked again at gs101 and in total we can have
19 uarts on this SoC. 3 of them are 256byte rx/tx fifo and the
other 16 have 64byte tx/rx fifo size, but this is a SoC design
choice and has nothing to do with probe order.

I will update in v3 to get fifo size from DT.

regards,

Peter.

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH v2 08/20] dt-bindings: serial: samsung: Add google-gs101-uart compatible

[Linus Walleij]

On Wed, Oct 11, 2023 at 9:48 AM Greg KH <gregkh@linuxfoundation.org> wrote:

> >        - enum:
> >            - apple,s5l-uart
> >            - axis,artpec8-uart
> > +          - google,gs101-uart
>
> These shouldn't be needed, just declare the device as the same as what
> the chip really is (i.e. a samsung uart), that way no .yaml or kernel
> driver changes are needed at all.

We strive to have these as unique as possible, as it is a hardware
description. It is fine to write drivers in Linux or any other OS just
being aware of a "courser" idea of what UART this is, in this case
would have looked something like this:

    compatible = "google,gs101-uart", "samsung-uart";

And the driver would be able to match to just the latter string
(these are listed in "particularity order").

BUT! The binding authors chose not to go that path, instead they
have one unique compatible string per hardware/integration version,
essentially per-SoC. So in this case it is just:

    compatible = "google,gs101-uart";

It is kind of impossible to fix now as well, because these bindings
are already deployed. So they are like a BIOS: written in stone.

It is possible to add dual compatibles for this *and following*
variants, but I don't know how Krzysztof feels about that, and as
others point out, probably knowledge of the exact SoC is
necessary.

Yours,
Linus Walleij

Re: [PATCH v2 08/20] dt-bindings: serial: samsung: Add google-gs101-uart compatible

[Linus Walleij]

On Wed, Oct 11, 2023 at 9:48 AM Greg KH <gregkh@linuxfoundation.org> wrote:

> >        - enum:
> >            - apple,s5l-uart
> >            - axis,artpec8-uart
> > +          - google,gs101-uart
>
> These shouldn't be needed, just declare the device as the same as what
> the chip really is (i.e. a samsung uart), that way no .yaml or kernel
> driver changes are needed at all.

We strive to have these as unique as possible, as it is a hardware
description. It is fine to write drivers in Linux or any other OS just
being aware of a "courser" idea of what UART this is, in this case
would have looked something like this:

    compatible = "google,gs101-uart", "samsung-uart";

And the driver would be able to match to just the latter string
(these are listed in "particularity order").

BUT! The binding authors chose not to go that path, instead they
have one unique compatible string per hardware/integration version,
essentially per-SoC. So in this case it is just:

    compatible = "google,gs101-uart";

It is kind of impossible to fix now as well, because these bindings
are already deployed. So they are like a BIOS: written in stone.

It is possible to add dual compatibles for this *and following*
variants, but I don't know how Krzysztof feels about that, and as
others point out, probably knowledge of the exact SoC is
necessary.

Yours,
Linus Walleij

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH v2 08/20] dt-bindings: serial: samsung: Add google-gs101-uart compatible

[Krzysztof Kozlowski]

On 11/10/2023 10:57, Greg KH wrote:
> On Wed, Oct 11, 2023 at 09:49:07AM +0100, Tudor Ambarus wrote:
>> Hi, Greg,
>>
>> On 10/11/23 08:48, Greg KH wrote:
>>> On Tue, Oct 10, 2023 at 11:49:16PM +0100, Peter Griffin wrote:
>>>> Add dedicated google-gs101-uart compatible to the dt-schema for
>>>> representing uart of the Google Tensor gs101 SoC.
>>>>
>>>> Signed-off-by: Peter Griffin <peter.griffin@linaro.org>
>>>> ---
>>>>  Documentation/devicetree/bindings/serial/samsung_uart.yaml | 2 ++
>>>>  1 file changed, 2 insertions(+)
>>>>
>>>> diff --git a/Documentation/devicetree/bindings/serial/samsung_uart.yaml b/Documentation/devicetree/bindings/serial/samsung_uart.yaml
>>>> index 8bd88d5cbb11..72471ebe5734 100644
>>>> --- a/Documentation/devicetree/bindings/serial/samsung_uart.yaml
>>>> +++ b/Documentation/devicetree/bindings/serial/samsung_uart.yaml
>>>> @@ -19,11 +19,13 @@ properties:
>>>>    compatible:
>>>>      oneOf:
>>>>        - items:
>>>> +          - const: google,gs101-uart
>>>>            - const: samsung,exynosautov9-uart
>>>>            - const: samsung,exynos850-uart
>>>>        - enum:
>>>>            - apple,s5l-uart
>>>>            - axis,artpec8-uart
>>>> +          - google,gs101-uart
>>>
>>> These shouldn't be needed, just declare the device as the same as what
>>
>> We should have SoC specific compatibles so that any further quirks or
>> incompatibilities can be easily addressed.
> 
> "further" work on quirks or incompatibilities can be added when they are
> found and needed.  We don't add stuff for no good reason to the kernel.

With a Devicetree bindings maintainer hat:
We expect the device-specific compatible in all bindings, followed by
fallback. The fallback is used by the driver, the device-specific for
any future needs.

This is the practice we follow everywhere and recommend everywhere since
some time. It is also documented here:

https://elixir.bootlin.com/linux/v6.6-rc5/source/Documentation/devicetree/bindings/writing-bindings.rst#L42

Best regards,
Krzysztof

Re: [PATCH v2 08/20] dt-bindings: serial: samsung: Add google-gs101-uart compatible

[Krzysztof Kozlowski]

On 11/10/2023 10:57, Greg KH wrote:
> On Wed, Oct 11, 2023 at 09:49:07AM +0100, Tudor Ambarus wrote:
>> Hi, Greg,
>>
>> On 10/11/23 08:48, Greg KH wrote:
>>> On Tue, Oct 10, 2023 at 11:49:16PM +0100, Peter Griffin wrote:
>>>> Add dedicated google-gs101-uart compatible to the dt-schema for
>>>> representing uart of the Google Tensor gs101 SoC.
>>>>
>>>> Signed-off-by: Peter Griffin <peter.griffin@linaro.org>
>>>> ---
>>>>  Documentation/devicetree/bindings/serial/samsung_uart.yaml | 2 ++
>>>>  1 file changed, 2 insertions(+)
>>>>
>>>> diff --git a/Documentation/devicetree/bindings/serial/samsung_uart.yaml b/Documentation/devicetree/bindings/serial/samsung_uart.yaml
>>>> index 8bd88d5cbb11..72471ebe5734 100644
>>>> --- a/Documentation/devicetree/bindings/serial/samsung_uart.yaml
>>>> +++ b/Documentation/devicetree/bindings/serial/samsung_uart.yaml
>>>> @@ -19,11 +19,13 @@ properties:
>>>>    compatible:
>>>>      oneOf:
>>>>        - items:
>>>> +          - const: google,gs101-uart
>>>>            - const: samsung,exynosautov9-uart
>>>>            - const: samsung,exynos850-uart
>>>>        - enum:
>>>>            - apple,s5l-uart
>>>>            - axis,artpec8-uart
>>>> +          - google,gs101-uart
>>>
>>> These shouldn't be needed, just declare the device as the same as what
>>
>> We should have SoC specific compatibles so that any further quirks or
>> incompatibilities can be easily addressed.
> 
> "further" work on quirks or incompatibilities can be added when they are
> found and needed.  We don't add stuff for no good reason to the kernel.

With a Devicetree bindings maintainer hat:
We expect the device-specific compatible in all bindings, followed by
fallback. The fallback is used by the driver, the device-specific for
any future needs.

This is the practice we follow everywhere and recommend everywhere since
some time. It is also documented here:

https://elixir.bootlin.com/linux/v6.6-rc5/source/Documentation/devicetree/bindings/writing-bindings.rst#L42

Best regards,
Krzysztof


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH v2 08/20] dt-bindings: serial: samsung: Add google-gs101-uart compatible

[Krzysztof Kozlowski]

On 11/10/2023 00:49, Peter Griffin wrote:
> Add dedicated google-gs101-uart compatible to the dt-schema for
> representing uart of the Google Tensor gs101 SoC.
> 
> Signed-off-by: Peter Griffin <peter.griffin@linaro.org>
> ---
>  Documentation/devicetree/bindings/serial/samsung_uart.yaml | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/serial/samsung_uart.yaml b/Documentation/devicetree/bindings/serial/samsung_uart.yaml
> index 8bd88d5cbb11..72471ebe5734 100644
> --- a/Documentation/devicetree/bindings/serial/samsung_uart.yaml
> +++ b/Documentation/devicetree/bindings/serial/samsung_uart.yaml
> @@ -19,11 +19,13 @@ properties:
>    compatible:
>      oneOf:
>        - items:
> +          - const: google,gs101-uart

You just broke existing users.

It does not look like you tested the DTS against bindings. Please run
`make dtbs_check W=1` (see
Documentation/devicetree/bindings/writing-schema.rst or
https://www.linaro.org/blog/tips-and-tricks-for-validating-devicetree-sources-with-the-devicetree-schema/
for instructions).



Best regards,
Krzysztof

Re: [PATCH v2 08/20] dt-bindings: serial: samsung: Add google-gs101-uart compatible

[Krzysztof Kozlowski]

On 11/10/2023 00:49, Peter Griffin wrote:
> Add dedicated google-gs101-uart compatible to the dt-schema for
> representing uart of the Google Tensor gs101 SoC.
> 
> Signed-off-by: Peter Griffin <peter.griffin@linaro.org>
> ---
>  Documentation/devicetree/bindings/serial/samsung_uart.yaml | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/serial/samsung_uart.yaml b/Documentation/devicetree/bindings/serial/samsung_uart.yaml
> index 8bd88d5cbb11..72471ebe5734 100644
> --- a/Documentation/devicetree/bindings/serial/samsung_uart.yaml
> +++ b/Documentation/devicetree/bindings/serial/samsung_uart.yaml
> @@ -19,11 +19,13 @@ properties:
>    compatible:
>      oneOf:
>        - items:
> +          - const: google,gs101-uart

You just broke existing users.

It does not look like you tested the DTS against bindings. Please run
`make dtbs_check W=1` (see
Documentation/devicetree/bindings/writing-schema.rst or
https://www.linaro.org/blog/tips-and-tricks-for-validating-devicetree-sources-with-the-devicetree-schema/
for instructions).



Best regards,
Krzysztof


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH v2 00/20] Add minimal Tensor/GS101 SoC support and Oriole/Pixel6 board

[Krzysztof Kozlowski]

On 11/10/2023 09:44, Greg KH wrote:
> On Tue, Oct 10, 2023 at 11:49:08PM +0100, Peter Griffin wrote:
>> Hi folks,
>>
>> Firstly, thanks to everyone who reviewed the v1 series! V2 incorporates all
>> the review feedback received so far.
>>
>> This series adds initial SoC support for the GS101 SoC and also initial board
>> support for Pixel 6 phone (Oriole).
>>
>> The gs101 / Tensor SoC is also used in Pixel6a (bluejay) and Pixel 6 Pro
>> (raven) phones. Currently DT is added for the gs101 SoC and Oriole.
>> As you can see from the patches the SoC is based on a Samsung Exynos SoC,
>> and therefore lots of the low level Exynos drivers can be re-used.
>>
>> The support added in this series consists of:
>> * cpus
>> * pinctrl
>> * some CCF implementation
>> * watchdog
>> * uart
>> * gpio
> 
> So you have sent a patch series that crosses multiple subsystems, who is
> supposed to be taking these patches?  Or do you not want them actually
> merged?

Me, through Samsung SoC -> ARM SoC. The cover letter could say that.

Best regards,
Krzysztof

Re: [PATCH v2 00/20] Add minimal Tensor/GS101 SoC support and Oriole/Pixel6 board

[Krzysztof Kozlowski]

On 11/10/2023 09:44, Greg KH wrote:
> On Tue, Oct 10, 2023 at 11:49:08PM +0100, Peter Griffin wrote:
>> Hi folks,
>>
>> Firstly, thanks to everyone who reviewed the v1 series! V2 incorporates all
>> the review feedback received so far.
>>
>> This series adds initial SoC support for the GS101 SoC and also initial board
>> support for Pixel 6 phone (Oriole).
>>
>> The gs101 / Tensor SoC is also used in Pixel6a (bluejay) and Pixel 6 Pro
>> (raven) phones. Currently DT is added for the gs101 SoC and Oriole.
>> As you can see from the patches the SoC is based on a Samsung Exynos SoC,
>> and therefore lots of the low level Exynos drivers can be re-used.
>>
>> The support added in this series consists of:
>> * cpus
>> * pinctrl
>> * some CCF implementation
>> * watchdog
>> * uart
>> * gpio
> 
> So you have sent a patch series that crosses multiple subsystems, who is
> supposed to be taking these patches?  Or do you not want them actually
> merged?

Me, through Samsung SoC -> ARM SoC. The cover letter could say that.

Best regards,
Krzysztof


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH v2 00/20] Add minimal Tensor/GS101 SoC support and Oriole/Pixel6 board

[Krzysztof Kozlowski]

On 11/10/2023 11:11, Greg KH wrote:
>>>
>>> So you have sent a patch series that crosses multiple subsystems, who is
>>> supposed to be taking these patches?  Or do you not want them actually
>>> merged?
>>
>> Krzysztof indicated here:
>> https://lore.kernel.org/all/b1598405-b01f-426a-aaba-89f2d2dc9c2e@linaro.org/
>> that he would like to be the one applying the entire series through the Samsung
>> SoC tree. If that's fine with everyone (it's OK with me).
> 
> As the serial changes are not ok (see my comments on them), I don't
> think they should be going through any tree at this point in time :)

Yes, of course, I still need (or will need) your Ack.

> 
> Also, in your 00/XX email, say what tree you expect them to go through
> so we have a chance to know that please.

+1

Best regards,
Krzysztof

Re: [PATCH v2 00/20] Add minimal Tensor/GS101 SoC support and Oriole/Pixel6 board

[Krzysztof Kozlowski]

On 11/10/2023 11:11, Greg KH wrote:
>>>
>>> So you have sent a patch series that crosses multiple subsystems, who is
>>> supposed to be taking these patches?  Or do you not want them actually
>>> merged?
>>
>> Krzysztof indicated here:
>> https://lore.kernel.org/all/b1598405-b01f-426a-aaba-89f2d2dc9c2e@linaro.org/
>> that he would like to be the one applying the entire series through the Samsung
>> SoC tree. If that's fine with everyone (it's OK with me).
> 
> As the serial changes are not ok (see my comments on them), I don't
> think they should be going through any tree at this point in time :)

Yes, of course, I still need (or will need) your Ack.

> 
> Also, in your 00/XX email, say what tree you expect them to go through
> so we have a chance to know that please.

+1

Best regards,
Krzysztof


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH v2 08/20] dt-bindings: serial: samsung: Add google-gs101-uart compatible

[Peter Griffin]

Hi Krzysztof,

Thanks for your review.

On Wed, 11 Oct 2023 at 13:09, Krzysztof Kozlowski
<krzysztof.kozlowski@linaro.org> wrote:
>
> On 11/10/2023 00:49, Peter Griffin wrote:
> > Add dedicated google-gs101-uart compatible to the dt-schema for
> > representing uart of the Google Tensor gs101 SoC.
> >
> > Signed-off-by: Peter Griffin <peter.griffin@linaro.org>
> > ---
> >  Documentation/devicetree/bindings/serial/samsung_uart.yaml | 2 ++
> >  1 file changed, 2 insertions(+)
> >
> > diff --git a/Documentation/devicetree/bindings/serial/samsung_uart.yaml b/Documentation/devicetree/bindings/serial/samsung_uart.yaml
> > index 8bd88d5cbb11..72471ebe5734 100644
> > --- a/Documentation/devicetree/bindings/serial/samsung_uart.yaml
> > +++ b/Documentation/devicetree/bindings/serial/samsung_uart.yaml
> > @@ -19,11 +19,13 @@ properties:
> >    compatible:
> >      oneOf:
> >        - items:
> > +          - const: google,gs101-uart
>
> You just broke existing users.
>
> It does not look like you tested the DTS against bindings. Please run
> `make dtbs_check W=1` (see
> Documentation/devicetree/bindings/writing-schema.rst or
> https://www.linaro.org/blog/tips-and-tricks-for-validating-devicetree-sources-with-the-devicetree-schema/
> for instructions).
>

Will fix in v3

fyi I've been running with

make -j$js ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu-
dt_binding_check DT_SCHEMA_FILES=google
make -j$js ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu-
dt_binding_check DT_SCHEMA_FILES=samsung
make -j$js ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu-  CHECK_DTBS=y
W=1 google/gs101-oriole.dtb

But clearly that wasn't enough to catch this.  `make dtbs_check W=1`
takes a long time
and gives so much output. I suppose adding a few of the other exynos
based boards should
still be fairly quick and hopefully catch things like this. For example adding

make -j$js ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- CHECK_DTBS=y
W=1 exynos/exynos850-e850-96.dtb
make -j$js ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- CHECK_DTBS=y
W=1 exynos/exynos5433-tm2.dtb
make -j$js ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- CHECK_DTBS=y
W=1 exynos/exynosautov9-sadk.dtb

regards,

Peter.

Re: [PATCH v2 08/20] dt-bindings: serial: samsung: Add google-gs101-uart compatible

[Peter Griffin]

Hi Krzysztof,

Thanks for your review.

On Wed, 11 Oct 2023 at 13:09, Krzysztof Kozlowski
<krzysztof.kozlowski@linaro.org> wrote:
>
> On 11/10/2023 00:49, Peter Griffin wrote:
> > Add dedicated google-gs101-uart compatible to the dt-schema for
> > representing uart of the Google Tensor gs101 SoC.
> >
> > Signed-off-by: Peter Griffin <peter.griffin@linaro.org>
> > ---
> >  Documentation/devicetree/bindings/serial/samsung_uart.yaml | 2 ++
> >  1 file changed, 2 insertions(+)
> >
> > diff --git a/Documentation/devicetree/bindings/serial/samsung_uart.yaml b/Documentation/devicetree/bindings/serial/samsung_uart.yaml
> > index 8bd88d5cbb11..72471ebe5734 100644
> > --- a/Documentation/devicetree/bindings/serial/samsung_uart.yaml
> > +++ b/Documentation/devicetree/bindings/serial/samsung_uart.yaml
> > @@ -19,11 +19,13 @@ properties:
> >    compatible:
> >      oneOf:
> >        - items:
> > +          - const: google,gs101-uart
>
> You just broke existing users.
>
> It does not look like you tested the DTS against bindings. Please run
> `make dtbs_check W=1` (see
> Documentation/devicetree/bindings/writing-schema.rst or
> https://www.linaro.org/blog/tips-and-tricks-for-validating-devicetree-sources-with-the-devicetree-schema/
> for instructions).
>

Will fix in v3

fyi I've been running with

make -j$js ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu-
dt_binding_check DT_SCHEMA_FILES=google
make -j$js ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu-
dt_binding_check DT_SCHEMA_FILES=samsung
make -j$js ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu-  CHECK_DTBS=y
W=1 google/gs101-oriole.dtb

But clearly that wasn't enough to catch this.  `make dtbs_check W=1`
takes a long time
and gives so much output. I suppose adding a few of the other exynos
based boards should
still be fairly quick and hopefully catch things like this. For example adding

make -j$js ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- CHECK_DTBS=y
W=1 exynos/exynos850-e850-96.dtb
make -j$js ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- CHECK_DTBS=y
W=1 exynos/exynos5433-tm2.dtb
make -j$js ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- CHECK_DTBS=y
W=1 exynos/exynosautov9-sadk.dtb

regards,

Peter.

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH v2 08/20] dt-bindings: serial: samsung: Add google-gs101-uart compatible

[Krzysztof Kozlowski]

On 11/10/2023 15:27, Peter Griffin wrote:
> Hi Krzysztof,
> 
> Thanks for your review.
> 
> On Wed, 11 Oct 2023 at 13:09, Krzysztof Kozlowski
> <krzysztof.kozlowski@linaro.org> wrote:
>>
>> On 11/10/2023 00:49, Peter Griffin wrote:
>>> Add dedicated google-gs101-uart compatible to the dt-schema for
>>> representing uart of the Google Tensor gs101 SoC.
>>>
>>> Signed-off-by: Peter Griffin <peter.griffin@linaro.org>
>>> ---
>>>  Documentation/devicetree/bindings/serial/samsung_uart.yaml | 2 ++
>>>  1 file changed, 2 insertions(+)
>>>
>>> diff --git a/Documentation/devicetree/bindings/serial/samsung_uart.yaml b/Documentation/devicetree/bindings/serial/samsung_uart.yaml
>>> index 8bd88d5cbb11..72471ebe5734 100644
>>> --- a/Documentation/devicetree/bindings/serial/samsung_uart.yaml
>>> +++ b/Documentation/devicetree/bindings/serial/samsung_uart.yaml
>>> @@ -19,11 +19,13 @@ properties:
>>>    compatible:
>>>      oneOf:
>>>        - items:
>>> +          - const: google,gs101-uart
>>
>> You just broke existing users.
>>
>> It does not look like you tested the DTS against bindings. Please run
>> `make dtbs_check W=1` (see
>> Documentation/devicetree/bindings/writing-schema.rst or
>> https://www.linaro.org/blog/tips-and-tricks-for-validating-devicetree-sources-with-the-devicetree-schema/
>> for instructions).
>>
> 
> Will fix in v3
> 
> fyi I've been running with
> 
> make -j$js ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu-
> dt_binding_check DT_SCHEMA_FILES=google
> make -j$js ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu-
> dt_binding_check DT_SCHEMA_FILES=samsung
> make -j$js ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu-  CHECK_DTBS=y
> W=1 google/gs101-oriole.dtb
> 
> But clearly that wasn't enough to catch this.  

None of the commands above test existing DTS...

>`make dtbs_check W=1`
> takes a long time
> and gives so much output. I suppose adding a few of the other exynos
> based boards should
> still be fairly quick and hopefully catch things like this. For example adding
> 
> make -j$js ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- CHECK_DTBS=y
> W=1 exynos/exynos850-e850-96.dtb
> make -j$js ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- CHECK_DTBS=y
> W=1 exynos/exynos5433-tm2.dtb
> make -j$js ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- CHECK_DTBS=y
> W=1 exynos/exynosautov9-sadk.dtb
> 
> regards,
> 
> Peter.

Best regards,
Krzysztof

Re: [PATCH v2 08/20] dt-bindings: serial: samsung: Add google-gs101-uart compatible

[Krzysztof Kozlowski]

On 11/10/2023 15:27, Peter Griffin wrote:
> Hi Krzysztof,
> 
> Thanks for your review.
> 
> On Wed, 11 Oct 2023 at 13:09, Krzysztof Kozlowski
> <krzysztof.kozlowski@linaro.org> wrote:
>>
>> On 11/10/2023 00:49, Peter Griffin wrote:
>>> Add dedicated google-gs101-uart compatible to the dt-schema for
>>> representing uart of the Google Tensor gs101 SoC.
>>>
>>> Signed-off-by: Peter Griffin <peter.griffin@linaro.org>
>>> ---
>>>  Documentation/devicetree/bindings/serial/samsung_uart.yaml | 2 ++
>>>  1 file changed, 2 insertions(+)
>>>
>>> diff --git a/Documentation/devicetree/bindings/serial/samsung_uart.yaml b/Documentation/devicetree/bindings/serial/samsung_uart.yaml
>>> index 8bd88d5cbb11..72471ebe5734 100644
>>> --- a/Documentation/devicetree/bindings/serial/samsung_uart.yaml
>>> +++ b/Documentation/devicetree/bindings/serial/samsung_uart.yaml
>>> @@ -19,11 +19,13 @@ properties:
>>>    compatible:
>>>      oneOf:
>>>        - items:
>>> +          - const: google,gs101-uart
>>
>> You just broke existing users.
>>
>> It does not look like you tested the DTS against bindings. Please run
>> `make dtbs_check W=1` (see
>> Documentation/devicetree/bindings/writing-schema.rst or
>> https://www.linaro.org/blog/tips-and-tricks-for-validating-devicetree-sources-with-the-devicetree-schema/
>> for instructions).
>>
> 
> Will fix in v3
> 
> fyi I've been running with
> 
> make -j$js ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu-
> dt_binding_check DT_SCHEMA_FILES=google
> make -j$js ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu-
> dt_binding_check DT_SCHEMA_FILES=samsung
> make -j$js ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu-  CHECK_DTBS=y
> W=1 google/gs101-oriole.dtb
> 
> But clearly that wasn't enough to catch this.  

None of the commands above test existing DTS...

>`make dtbs_check W=1`
> takes a long time
> and gives so much output. I suppose adding a few of the other exynos
> based boards should
> still be fairly quick and hopefully catch things like this. For example adding
> 
> make -j$js ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- CHECK_DTBS=y
> W=1 exynos/exynos850-e850-96.dtb
> make -j$js ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- CHECK_DTBS=y
> W=1 exynos/exynos5433-tm2.dtb
> make -j$js ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- CHECK_DTBS=y
> W=1 exynos/exynosautov9-sadk.dtb
> 
> regards,
> 
> Peter.

Best regards,
Krzysztof


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH v2 00/20] Add minimal Tensor/GS101 SoC support and Oriole/Pixel6 board

[Peter Griffin]

Hi Tudor,

Thanks for your review feedback.

On Wed, 11 Oct 2023 at 09:42, Tudor Ambarus <tudor.ambarus@linaro.org> wrote:
>
>
>
> On 10/11/23 09:16, Peter Griffin wrote:
> > Hi Tudor,
> >
> > Thanks for your reply.
> >
> > On Wed, 11 Oct 2023 at 07:10, Tudor Ambarus <tudor.ambarus@linaro.org> wrote:
> >>
> >> Hi, Peter,
> >>
> >> On 10/10/23 23:49, Peter Griffin wrote:
> >>> Note 3: In `dt-bindings: pinctrl: samsung: add google,gs101-pinctrl
> >>> compatible` I tried to narrow the interrupts check to
> >>> google,gs101-pinctrl but I still see a warning: gs101-oriole.dtb:
> >>> pinctrl@174d0000: interrupts: [[0, 0, 4],[..] is too long If anyone can
> >>> educate me on what I've done wrong here it would be most appreciated!
> >>
> >> I guess the initial definition of the number of interrupts should
> >> include the largest min/maxItems. I no longer see the warning with this
> >> change:
> >
> > Yes that is how it was in v1. The review feedback though was to narrow
> > the scope to just google,gs101-pinctrl compatible using if: then: else: which
> > is what I can't get to work properly.
> >
>
> Right. The diff that I sent is on top of your changes (patch 6/20).
> I expect that when the interrupts property is defined it should include
> the min/maxItems of all the available SoCs. Then use "if Soc" to narrow
> the range.

Ah I see, yes thanks Tudor! I will incorporate this in v3.

regards,

Peter

Re: [PATCH v2 00/20] Add minimal Tensor/GS101 SoC support and Oriole/Pixel6 board

[Peter Griffin]

Hi Tudor,

Thanks for your review feedback.

On Wed, 11 Oct 2023 at 09:42, Tudor Ambarus <tudor.ambarus@linaro.org> wrote:
>
>
>
> On 10/11/23 09:16, Peter Griffin wrote:
> > Hi Tudor,
> >
> > Thanks for your reply.
> >
> > On Wed, 11 Oct 2023 at 07:10, Tudor Ambarus <tudor.ambarus@linaro.org> wrote:
> >>
> >> Hi, Peter,
> >>
> >> On 10/10/23 23:49, Peter Griffin wrote:
> >>> Note 3: In `dt-bindings: pinctrl: samsung: add google,gs101-pinctrl
> >>> compatible` I tried to narrow the interrupts check to
> >>> google,gs101-pinctrl but I still see a warning: gs101-oriole.dtb:
> >>> pinctrl@174d0000: interrupts: [[0, 0, 4],[..] is too long If anyone can
> >>> educate me on what I've done wrong here it would be most appreciated!
> >>
> >> I guess the initial definition of the number of interrupts should
> >> include the largest min/maxItems. I no longer see the warning with this
> >> change:
> >
> > Yes that is how it was in v1. The review feedback though was to narrow
> > the scope to just google,gs101-pinctrl compatible using if: then: else: which
> > is what I can't get to work properly.
> >
>
> Right. The diff that I sent is on top of your changes (patch 6/20).
> I expect that when the interrupts property is defined it should include
> the min/maxItems of all the available SoCs. Then use "if Soc" to narrow
> the range.

Ah I see, yes thanks Tudor! I will incorporate this in v3.

regards,

Peter

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH v2 15/20] watchdog: s3c2410_wdt: Add support for Google tensor SoCs

[Peter Griffin]

Hi Guenter,

Thanks for your review.

On Wed, 11 Oct 2023 at 00:56, Guenter Roeck <linux@roeck-us.net> wrote:
>
> On Tue, Oct 10, 2023 at 11:49:23PM +0100, Peter Griffin wrote:
> > This patch adds the compatibles and drvdata for the Google
> > gs101 & gs201 SoCs found in Pixel 6 and Pixel 7 phones. Similar
> > to Exynos850 it has two watchdog instances, one for each cluster
> > and has some control bits in PMU registers.
> >
> > The watchdog IP found in gs101 SoCs also supports a few
> > additional bits/features in the WTCON register which we add
> > support for and an additional register detailed below.
> >
> > dbgack-mask - Enables masking WDT interrupt and reset request
> > according to asserted DBGACK input
> >
> > windowed-mode - Enabled Windowed watchdog mode
> >
> > Windowed watchdog mode also has an additional register WTMINCNT.
> > If windowed watchdog is enabled and you reload WTCNT when the
> > value is greater than WTMINCNT, it prompts interrupt or reset
> > request as if the watchdog time has expired.
>
> I am a bit lost with this one. The patch adds QUIRK_HAS_WTMINCNT_REG
> but doesn't use it. It also adds S3C2410_WTMINCNT but does not use it
> either.
>
> What is the point of doing that ? It is just confusing.

Good spot, it seems I lost a few hunks from this patch at some point, sorry
about that. I will update and send a v3.

regards,

Peter.

Re: [PATCH v2 15/20] watchdog: s3c2410_wdt: Add support for Google tensor SoCs

[Peter Griffin]

Hi Guenter,

Thanks for your review.

On Wed, 11 Oct 2023 at 00:56, Guenter Roeck <linux@roeck-us.net> wrote:
>
> On Tue, Oct 10, 2023 at 11:49:23PM +0100, Peter Griffin wrote:
> > This patch adds the compatibles and drvdata for the Google
> > gs101 & gs201 SoCs found in Pixel 6 and Pixel 7 phones. Similar
> > to Exynos850 it has two watchdog instances, one for each cluster
> > and has some control bits in PMU registers.
> >
> > The watchdog IP found in gs101 SoCs also supports a few
> > additional bits/features in the WTCON register which we add
> > support for and an additional register detailed below.
> >
> > dbgack-mask - Enables masking WDT interrupt and reset request
> > according to asserted DBGACK input
> >
> > windowed-mode - Enabled Windowed watchdog mode
> >
> > Windowed watchdog mode also has an additional register WTMINCNT.
> > If windowed watchdog is enabled and you reload WTCNT when the
> > value is greater than WTMINCNT, it prompts interrupt or reset
> > request as if the watchdog time has expired.
>
> I am a bit lost with this one. The patch adds QUIRK_HAS_WTMINCNT_REG
> but doesn't use it. It also adds S3C2410_WTMINCNT but does not use it
> either.
>
> What is the point of doing that ? It is just confusing.

Good spot, it seems I lost a few hunks from this patch at some point, sorry
about that. I will update and send a v3.

regards,

Peter.

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH v2 16/20] tty: serial: samsung: Add gs101 compatible and SoC data

[Peter Griffin]

Hi Greg,

Thanks for the review.

On Wed, 11 Oct 2023 at 08:47, Greg KH <gregkh@linuxfoundation.org> wrote:
>
> On Tue, Oct 10, 2023 at 11:49:24PM +0100, Peter Griffin wrote:
> > Add serial driver data for Google Tensor gs101 SoC.
> >
> > Signed-off-by: Peter Griffin <peter.griffin@linaro.org>
> > ---
> >  drivers/tty/serial/samsung_tty.c | 12 ++++++++++++
> >  1 file changed, 12 insertions(+)
> >
> > diff --git a/drivers/tty/serial/samsung_tty.c b/drivers/tty/serial/samsung_tty.c
> > index 07fb8a9dac63..79a1a184d5c1 100644
> > --- a/drivers/tty/serial/samsung_tty.c
> > +++ b/drivers/tty/serial/samsung_tty.c
> > @@ -2597,14 +2597,21 @@ static const struct s3c24xx_serial_drv_data exynos850_serial_drv_data = {
> >       .fifosize = { 256, 64, 64, 64 },
> >  };
> >
> > +static const struct s3c24xx_serial_drv_data gs101_serial_drv_data = {
> > +     EXYNOS_COMMON_SERIAL_DRV_DATA(),
> > +     .fifosize = { 256, 64, 64, 64 },
> > +};
>
> Why are you duplicating a structure that is already in the same file?
> What is the benifit here?

There is a mistake here, the struct shouldn't be the same as e850 it
should look like this

static const struct s3c24xx_serial_drv_data gs101_serial_drv_data = {
     EXYNOS_COMMON_SERIAL_DRV_DATA(),
     /* rely on samsung,uart-fifosize DT property for fifosize */
     .fifosize = { 0 },
};

This then allows the fifosize to be taken from the samsung,uart-fifosize
DT property for each of the 19 UARTs on this SoC.

>
> >  #define EXYNOS4210_SERIAL_DRV_DATA (&exynos4210_serial_drv_data)
> >  #define EXYNOS5433_SERIAL_DRV_DATA (&exynos5433_serial_drv_data)
> >  #define EXYNOS850_SERIAL_DRV_DATA (&exynos850_serial_drv_data)
> > +#define GS101_SERIAL_DRV_DATA (&gs101_serial_drv_data)
>
> What is "GS101"?

gs101 is the name of the SoC in Pixel 6, 6 pro, 6a phones. I've put
some more info
about the various names of the SoC in the bindings documentation. See
https://lore.kernel.org/linux-arm-kernel/20231010224928.2296997-9-peter.griffin@linaro.org/T/#mb45492e58de0bef566df8cdf6191ab8f96f0cf99

>
> >  #else
> >  #define EXYNOS4210_SERIAL_DRV_DATA NULL
> >  #define EXYNOS5433_SERIAL_DRV_DATA NULL
> >  #define EXYNOS850_SERIAL_DRV_DATA NULL
> > +#define GS101_SERIAL_DRV_DATA NULL
> >  #endif
> >
> >  #ifdef CONFIG_ARCH_APPLE
> > @@ -2688,6 +2695,9 @@ static const struct platform_device_id s3c24xx_serial_driver_ids[] = {
> >       }, {
> >               .name           = "artpec8-uart",
> >               .driver_data    = (kernel_ulong_t)ARTPEC8_SERIAL_DRV_DATA,
> > +     }, {
> > +             .name           = "gs101-uart",
> > +             .driver_data    = (kernel_ulong_t)GS101_SERIAL_DRV_DATA,
> >       },
> >       { },
> >  };
> > @@ -2709,6 +2719,8 @@ static const struct of_device_id s3c24xx_uart_dt_match[] = {
> >               .data = EXYNOS850_SERIAL_DRV_DATA },
> >       { .compatible = "axis,artpec8-uart",
> >               .data = ARTPEC8_SERIAL_DRV_DATA },
> > +     { .compatible = "google,gs101-uart",
> > +             .data =  GS101_SERIAL_DRV_DATA },
>
> Why aren't you just listing this hardware as the same one above?  There
> doesn't need to be a new entry if you just fix up the DT for the board
> to declare it as the proper type of device.  No need to keep adding new
> entries that do the exact same thing, we don't normally like that at all
> for other bus types, why is DT different?
>

I believe Krzysztof already answered this from a dt maintainer point of view.

regards,

Peter.

Re: [PATCH v2 16/20] tty: serial: samsung: Add gs101 compatible and SoC data

[Peter Griffin]

Hi Greg,

Thanks for the review.

On Wed, 11 Oct 2023 at 08:47, Greg KH <gregkh@linuxfoundation.org> wrote:
>
> On Tue, Oct 10, 2023 at 11:49:24PM +0100, Peter Griffin wrote:
> > Add serial driver data for Google Tensor gs101 SoC.
> >
> > Signed-off-by: Peter Griffin <peter.griffin@linaro.org>
> > ---
> >  drivers/tty/serial/samsung_tty.c | 12 ++++++++++++
> >  1 file changed, 12 insertions(+)
> >
> > diff --git a/drivers/tty/serial/samsung_tty.c b/drivers/tty/serial/samsung_tty.c
> > index 07fb8a9dac63..79a1a184d5c1 100644
> > --- a/drivers/tty/serial/samsung_tty.c
> > +++ b/drivers/tty/serial/samsung_tty.c
> > @@ -2597,14 +2597,21 @@ static const struct s3c24xx_serial_drv_data exynos850_serial_drv_data = {
> >       .fifosize = { 256, 64, 64, 64 },
> >  };
> >
> > +static const struct s3c24xx_serial_drv_data gs101_serial_drv_data = {
> > +     EXYNOS_COMMON_SERIAL_DRV_DATA(),
> > +     .fifosize = { 256, 64, 64, 64 },
> > +};
>
> Why are you duplicating a structure that is already in the same file?
> What is the benifit here?

There is a mistake here, the struct shouldn't be the same as e850 it
should look like this

static const struct s3c24xx_serial_drv_data gs101_serial_drv_data = {
     EXYNOS_COMMON_SERIAL_DRV_DATA(),
     /* rely on samsung,uart-fifosize DT property for fifosize */
     .fifosize = { 0 },
};

This then allows the fifosize to be taken from the samsung,uart-fifosize
DT property for each of the 19 UARTs on this SoC.

>
> >  #define EXYNOS4210_SERIAL_DRV_DATA (&exynos4210_serial_drv_data)
> >  #define EXYNOS5433_SERIAL_DRV_DATA (&exynos5433_serial_drv_data)
> >  #define EXYNOS850_SERIAL_DRV_DATA (&exynos850_serial_drv_data)
> > +#define GS101_SERIAL_DRV_DATA (&gs101_serial_drv_data)
>
> What is "GS101"?

gs101 is the name of the SoC in Pixel 6, 6 pro, 6a phones. I've put
some more info
about the various names of the SoC in the bindings documentation. See
https://lore.kernel.org/linux-arm-kernel/20231010224928.2296997-9-peter.griffin@linaro.org/T/#mb45492e58de0bef566df8cdf6191ab8f96f0cf99

>
> >  #else
> >  #define EXYNOS4210_SERIAL_DRV_DATA NULL
> >  #define EXYNOS5433_SERIAL_DRV_DATA NULL
> >  #define EXYNOS850_SERIAL_DRV_DATA NULL
> > +#define GS101_SERIAL_DRV_DATA NULL
> >  #endif
> >
> >  #ifdef CONFIG_ARCH_APPLE
> > @@ -2688,6 +2695,9 @@ static const struct platform_device_id s3c24xx_serial_driver_ids[] = {
> >       }, {
> >               .name           = "artpec8-uart",
> >               .driver_data    = (kernel_ulong_t)ARTPEC8_SERIAL_DRV_DATA,
> > +     }, {
> > +             .name           = "gs101-uart",
> > +             .driver_data    = (kernel_ulong_t)GS101_SERIAL_DRV_DATA,
> >       },
> >       { },
> >  };
> > @@ -2709,6 +2719,8 @@ static const struct of_device_id s3c24xx_uart_dt_match[] = {
> >               .data = EXYNOS850_SERIAL_DRV_DATA },
> >       { .compatible = "axis,artpec8-uart",
> >               .data = ARTPEC8_SERIAL_DRV_DATA },
> > +     { .compatible = "google,gs101-uart",
> > +             .data =  GS101_SERIAL_DRV_DATA },
>
> Why aren't you just listing this hardware as the same one above?  There
> doesn't need to be a new entry if you just fix up the DT for the board
> to declare it as the proper type of device.  No need to keep adding new
> entries that do the exact same thing, we don't normally like that at all
> for other bus types, why is DT different?
>

I believe Krzysztof already answered this from a dt maintainer point of view.

regards,

Peter.

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH v2 16/20] tty: serial: samsung: Add gs101 compatible and SoC data

[Greg KH]

On Wed, Oct 11, 2023 at 07:03:44PM +0100, Peter Griffin wrote:
> Hi Greg,
> 
> Thanks for the review.
> 
> On Wed, 11 Oct 2023 at 08:47, Greg KH <gregkh@linuxfoundation.org> wrote:
> >
> > On Tue, Oct 10, 2023 at 11:49:24PM +0100, Peter Griffin wrote:
> > > Add serial driver data for Google Tensor gs101 SoC.
> > >
> > > Signed-off-by: Peter Griffin <peter.griffin@linaro.org>
> > > ---
> > >  drivers/tty/serial/samsung_tty.c | 12 ++++++++++++
> > >  1 file changed, 12 insertions(+)
> > >
> > > diff --git a/drivers/tty/serial/samsung_tty.c b/drivers/tty/serial/samsung_tty.c
> > > index 07fb8a9dac63..79a1a184d5c1 100644
> > > --- a/drivers/tty/serial/samsung_tty.c
> > > +++ b/drivers/tty/serial/samsung_tty.c
> > > @@ -2597,14 +2597,21 @@ static const struct s3c24xx_serial_drv_data exynos850_serial_drv_data = {
> > >       .fifosize = { 256, 64, 64, 64 },
> > >  };
> > >
> > > +static const struct s3c24xx_serial_drv_data gs101_serial_drv_data = {
> > > +     EXYNOS_COMMON_SERIAL_DRV_DATA(),
> > > +     .fifosize = { 256, 64, 64, 64 },
> > > +};
> >
> > Why are you duplicating a structure that is already in the same file?
> > What is the benifit here?
> 
> There is a mistake here, the struct shouldn't be the same as e850 it
> should look like this
> 
> static const struct s3c24xx_serial_drv_data gs101_serial_drv_data = {
>      EXYNOS_COMMON_SERIAL_DRV_DATA(),
>      /* rely on samsung,uart-fifosize DT property for fifosize */
>      .fifosize = { 0 },
> };
> 
> This then allows the fifosize to be taken from the samsung,uart-fifosize
> DT property for each of the 19 UARTs on this SoC.

Ah, ok, then that makes more sense, and makes sense why you would want a
unique dt identifier for this device.  Make that change and I'll be much
happier :)

thanks,

greg k-h

Re: [PATCH v2 16/20] tty: serial: samsung: Add gs101 compatible and SoC data

[Greg KH]

On Wed, Oct 11, 2023 at 07:03:44PM +0100, Peter Griffin wrote:
> Hi Greg,
> 
> Thanks for the review.
> 
> On Wed, 11 Oct 2023 at 08:47, Greg KH <gregkh@linuxfoundation.org> wrote:
> >
> > On Tue, Oct 10, 2023 at 11:49:24PM +0100, Peter Griffin wrote:
> > > Add serial driver data for Google Tensor gs101 SoC.
> > >
> > > Signed-off-by: Peter Griffin <peter.griffin@linaro.org>
> > > ---
> > >  drivers/tty/serial/samsung_tty.c | 12 ++++++++++++
> > >  1 file changed, 12 insertions(+)
> > >
> > > diff --git a/drivers/tty/serial/samsung_tty.c b/drivers/tty/serial/samsung_tty.c
> > > index 07fb8a9dac63..79a1a184d5c1 100644
> > > --- a/drivers/tty/serial/samsung_tty.c
> > > +++ b/drivers/tty/serial/samsung_tty.c
> > > @@ -2597,14 +2597,21 @@ static const struct s3c24xx_serial_drv_data exynos850_serial_drv_data = {
> > >       .fifosize = { 256, 64, 64, 64 },
> > >  };
> > >
> > > +static const struct s3c24xx_serial_drv_data gs101_serial_drv_data = {
> > > +     EXYNOS_COMMON_SERIAL_DRV_DATA(),
> > > +     .fifosize = { 256, 64, 64, 64 },
> > > +};
> >
> > Why are you duplicating a structure that is already in the same file?
> > What is the benifit here?
> 
> There is a mistake here, the struct shouldn't be the same as e850 it
> should look like this
> 
> static const struct s3c24xx_serial_drv_data gs101_serial_drv_data = {
>      EXYNOS_COMMON_SERIAL_DRV_DATA(),
>      /* rely on samsung,uart-fifosize DT property for fifosize */
>      .fifosize = { 0 },
> };
> 
> This then allows the fifosize to be taken from the samsung,uart-fifosize
> DT property for each of the 19 UARTs on this SoC.

Ah, ok, then that makes more sense, and makes sense why you would want a
unique dt identifier for this device.  Make that change and I'll be much
happier :)

thanks,

greg k-h

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH v2 07/20] dt-bindings: pinctrl: samsung: add gs101-wakeup-eint compatible

[Sam Protsenko]

On Tue, Oct 10, 2023 at 5:49 PM Peter Griffin <peter.griffin@linaro.org> wrote:
>
> gs101 is similar to newer Exynos SoCs like Exynos850 and ExynosAutov9
> where more than one pin controller can do external wake-up interrupt.
> So add a dedicated compatible for it.
>
> Signed-off-by: Peter Griffin <peter.griffin@linaro.org>
> ---
>  .../bindings/pinctrl/samsung,pinctrl-wakeup-interrupt.yaml      | 2 ++
>  1 file changed, 2 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/pinctrl/samsung,pinctrl-wakeup-interrupt.yaml b/Documentation/devicetree/bindings/pinctrl/samsung,pinctrl-wakeup-interrupt.yaml
> index 1de91a51234d..7cddce761c46 100644
> --- a/Documentation/devicetree/bindings/pinctrl/samsung,pinctrl-wakeup-interrupt.yaml
> +++ b/Documentation/devicetree/bindings/pinctrl/samsung,pinctrl-wakeup-interrupt.yaml
> @@ -29,6 +29,7 @@ description: |
>  properties:
>    compatible:
>      enum:
> +      - google,gs101-wakeup-eint
>        - samsung,s3c2410-wakeup-eint
>        - samsung,s3c2412-wakeup-eint
>        - samsung,s3c64xx-wakeup-eint
> @@ -99,6 +100,7 @@ allOf:
>              enum:
>                - samsung,exynos850-wakeup-eint
>                - samsung,exynosautov9-wakeup-eint
> +              - google,gs101-wakeup-eint

Maybe move it on top, to keep the list sorted alphabetically?

>      then:
>        properties:
>          interrupts: false
> --
> 2.42.0.609.gbb76f46606-goog
>

Re: [PATCH v2 07/20] dt-bindings: pinctrl: samsung: add gs101-wakeup-eint compatible

[Sam Protsenko]

On Tue, Oct 10, 2023 at 5:49 PM Peter Griffin <peter.griffin@linaro.org> wrote:
>
> gs101 is similar to newer Exynos SoCs like Exynos850 and ExynosAutov9
> where more than one pin controller can do external wake-up interrupt.
> So add a dedicated compatible for it.
>
> Signed-off-by: Peter Griffin <peter.griffin@linaro.org>
> ---
>  .../bindings/pinctrl/samsung,pinctrl-wakeup-interrupt.yaml      | 2 ++
>  1 file changed, 2 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/pinctrl/samsung,pinctrl-wakeup-interrupt.yaml b/Documentation/devicetree/bindings/pinctrl/samsung,pinctrl-wakeup-interrupt.yaml
> index 1de91a51234d..7cddce761c46 100644
> --- a/Documentation/devicetree/bindings/pinctrl/samsung,pinctrl-wakeup-interrupt.yaml
> +++ b/Documentation/devicetree/bindings/pinctrl/samsung,pinctrl-wakeup-interrupt.yaml
> @@ -29,6 +29,7 @@ description: |
>  properties:
>    compatible:
>      enum:
> +      - google,gs101-wakeup-eint
>        - samsung,s3c2410-wakeup-eint
>        - samsung,s3c2412-wakeup-eint
>        - samsung,s3c64xx-wakeup-eint
> @@ -99,6 +100,7 @@ allOf:
>              enum:
>                - samsung,exynos850-wakeup-eint
>                - samsung,exynosautov9-wakeup-eint
> +              - google,gs101-wakeup-eint

Maybe move it on top, to keep the list sorted alphabetically?

>      then:
>        properties:
>          interrupts: false
> --
> 2.42.0.609.gbb76f46606-goog
>

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH v2 07/20] dt-bindings: pinctrl: samsung: add gs101-wakeup-eint compatible

[Peter Griffin]

Hi Sam,

Thanks for the review.

On Thu, 12 Oct 2023 at 00:12, Sam Protsenko <semen.protsenko@linaro.org> wrote:
>
> On Tue, Oct 10, 2023 at 5:49 PM Peter Griffin <peter.griffin@linaro.org> wrote:
> >
> > gs101 is similar to newer Exynos SoCs like Exynos850 and ExynosAutov9
> > where more than one pin controller can do external wake-up interrupt.
> > So add a dedicated compatible for it.
> >
> > Signed-off-by: Peter Griffin <peter.griffin@linaro.org>
> > ---
> >  .../bindings/pinctrl/samsung,pinctrl-wakeup-interrupt.yaml      | 2 ++
> >  1 file changed, 2 insertions(+)
> >
> > diff --git a/Documentation/devicetree/bindings/pinctrl/samsung,pinctrl-wakeup-interrupt.yaml b/Documentation/devicetree/bindings/pinctrl/samsung,pinctrl-wakeup-interrupt.yaml
> > index 1de91a51234d..7cddce761c46 100644
> > --- a/Documentation/devicetree/bindings/pinctrl/samsung,pinctrl-wakeup-interrupt.yaml
> > +++ b/Documentation/devicetree/bindings/pinctrl/samsung,pinctrl-wakeup-interrupt.yaml
> > @@ -29,6 +29,7 @@ description: |
> >  properties:
> >    compatible:
> >      enum:
> > +      - google,gs101-wakeup-eint
> >        - samsung,s3c2410-wakeup-eint
> >        - samsung,s3c2412-wakeup-eint
> >        - samsung,s3c64xx-wakeup-eint
> > @@ -99,6 +100,7 @@ allOf:
> >              enum:
> >                - samsung,exynos850-wakeup-eint
> >                - samsung,exynosautov9-wakeup-eint
> > +              - google,gs101-wakeup-eint
>
> Maybe move it on top, to keep the list sorted alphabetically?

Will fix in v4

Re: [PATCH v2 07/20] dt-bindings: pinctrl: samsung: add gs101-wakeup-eint compatible

[Peter Griffin]

Hi Sam,

Thanks for the review.

On Thu, 12 Oct 2023 at 00:12, Sam Protsenko <semen.protsenko@linaro.org> wrote:
>
> On Tue, Oct 10, 2023 at 5:49 PM Peter Griffin <peter.griffin@linaro.org> wrote:
> >
> > gs101 is similar to newer Exynos SoCs like Exynos850 and ExynosAutov9
> > where more than one pin controller can do external wake-up interrupt.
> > So add a dedicated compatible for it.
> >
> > Signed-off-by: Peter Griffin <peter.griffin@linaro.org>
> > ---
> >  .../bindings/pinctrl/samsung,pinctrl-wakeup-interrupt.yaml      | 2 ++
> >  1 file changed, 2 insertions(+)
> >
> > diff --git a/Documentation/devicetree/bindings/pinctrl/samsung,pinctrl-wakeup-interrupt.yaml b/Documentation/devicetree/bindings/pinctrl/samsung,pinctrl-wakeup-interrupt.yaml
> > index 1de91a51234d..7cddce761c46 100644
> > --- a/Documentation/devicetree/bindings/pinctrl/samsung,pinctrl-wakeup-interrupt.yaml
> > +++ b/Documentation/devicetree/bindings/pinctrl/samsung,pinctrl-wakeup-interrupt.yaml
> > @@ -29,6 +29,7 @@ description: |
> >  properties:
> >    compatible:
> >      enum:
> > +      - google,gs101-wakeup-eint
> >        - samsung,s3c2410-wakeup-eint
> >        - samsung,s3c2412-wakeup-eint
> >        - samsung,s3c64xx-wakeup-eint
> > @@ -99,6 +100,7 @@ allOf:
> >              enum:
> >                - samsung,exynos850-wakeup-eint
> >                - samsung,exynosautov9-wakeup-eint
> > +              - google,gs101-wakeup-eint
>
> Maybe move it on top, to keep the list sorted alphabetically?

Will fix in v4

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH v2 00/20] Add minimal Tensor/GS101 SoC support and Oriole/Pixel6 board

[Maksym Holovach]

Hi, all

I wanted to inquire about how do you all feel about calling this SoC by 
the Google "gs101" name.

I believe the proper name for it should be the actual Samsung name, 
written in the silicon and reported in the Chip ID hardware: Exynos9845. 
This also touches the Tensor G2 (Exynos9855), Tensor G3 (Exynos9865), 
and possibly the "Tesla" SoCs.

I do not think the Linux kernel should be a marketing material: it 
should reflect reality. The chip is almost 100% composed of Samsung 
Exynos IP blocks and should be called that way.

Yours,

- Markuss

On 10/11/23 01:49, Peter Griffin wrote:
> Hi folks,
>
> Firstly, thanks to everyone who reviewed the v1 series! V2 incorporates all
> the review feedback received so far.
>
> This series adds initial SoC support for the GS101 SoC and also initial board
> support for Pixel 6 phone (Oriole).
>
> The gs101 / Tensor SoC is also used in Pixel6a (bluejay) and Pixel 6 Pro
> (raven) phones. Currently DT is added for the gs101 SoC and Oriole.
> As you can see from the patches the SoC is based on a Samsung Exynos SoC,
> and therefore lots of the low level Exynos drivers can be re-used.
>
> The support added in this series consists of:
> * cpus
> * pinctrl
> * some CCF implementation
> * watchdog
> * uart
> * gpio
>
> This is enough to boot through to a busybox initramfs and shell using an
> upstream kernel though :) More platform support will be added over the
> following weeks and months.
>
> Note 1: I've removed the dtbo overlay from v2 submission and will re-submit once
> I have appropriate documentation for it.
>
> Note 2: I've left the bootargs in dts with earlycon for now, for two reasons.
> 1) The bootloader hangs if bootargs isn't present in the dtb as it tries to
> re-write this with additional bootargs.
> 2) there is a issue whereby the full serial console doesn't come up properly
> if earlycon isn't also specified. This issue needs further investigation.
>
> Note 3: In `dt-bindings: pinctrl: samsung: add google,gs101-pinctrl compatible`
> I tried to narrow the interrupts check to google,gs101-pinctrl but I still see
> a warning:
> gs101-oriole.dtb: pinctrl@174d0000: interrupts: [[0, 0, 4],[..] is too long
>
> If anyone can educate me on what I've done wrong here it would be most
> appreciated!
>
> kind regards,
>
> Peter.
>
> Changes since v1:
>   - Remove irq/gs101.h and replace macros with irq numbers globally
>   - exynos-pmu - keep alphabetical order
>   - add cmu_apm to clock bindings documentation
>   - sysreg bindings - remove superfluous `google,gs101-sysreg`
>   - watchdog bindings - Alphanumerical order, update gs201 comment
>   - samsung,pinctrl.yaml - add new "if:then:else:" to narrow for google SoC
>   - samsung,pinctrl-wakeup-interrupt.yaml - Alphanumerical order
>   - samsung,pinctrl- add google,gs101-wakeup-eint compatible
>   - clk-pll: fixup typos
>   - clk-gs101: fix kernel test robot warnings (add 2 new clocks,dividers,gate)
>   - clk-gs101: fix alphabetical order
>   - clk-gs101: cmu_apm: fixup typo and missing empty entry
>   - clk-gs101: cmu_misc: remove clocks that were being registerred twice
>   - pinctrl: filter sel: rename/reorder variables, add comment for FLTCON bitfield
>   - pinctrl: filter sel: avoid setting reserved bits by loop over FLTCON1 pins as well
>   - pinctrl: gs101: rename bank_type_6/7 structs to be more specific, split from filter
>   - watchdog: s3c2410_wdt: remove dev_info prints
>   - gs101.dtsi/oriole.dts: order by unit node, remove underscores from node name, blank lines
>     add SoC node, split dts and dtsi into separate patches, remove 'DVT' suffix
>   - gs101-oriole.dtso: Remove overlay until board_id is documented properly
>   - Add GS101_PIN_* macros to gs101-pinctrl.h instead of using Exynos ones
>   - gpio-keys: update linux,code to use input-event-code macros
>   - add dedicated gs101-uart compatible
>
> Peter Griffin (20):
>    dt-bindings: soc: samsung: exynos-pmu: Add gs101 compatible
>    dt-bindings: clock: Add Google gs101 clock management unit bindings
>    dt-bindings: soc: google: exynos-sysreg: add dedicated SYSREG
>      compatibles to GS101
>    dt-bindings: watchdog: Document Google gs101 & gs201 watchdog bindings
>    dt-bindings: arm: google: Add bindings for Google ARM platforms
>    dt-bindings: pinctrl: samsung: add google,gs101-pinctrl compatible
>    dt-bindings: pinctrl: samsung: add gs101-wakeup-eint compatible
>    dt-bindings: serial: samsung: Add google-gs101-uart compatible
>    clk: samsung: clk-pll: Add support for pll_{0516,0517,518}
>    clk: samsung: clk-gs101: Add cmu_top registers, plls, mux and gates
>    clk: samsung: clk-gs101: add CMU_APM support
>    clk: samsung: clk-gs101: Add support for CMU_MISC clock unit
>    pinctrl: samsung: Add filter selection support for alive banks
>    pinctrl: samsung: Add gs101 SoC pinctrl configuration
>    watchdog: s3c2410_wdt: Add support for Google tensor SoCs
>    tty: serial: samsung: Add gs101 compatible and SoC data
>    arm64: dts: google: Add initial Google gs101 SoC support
>    arm64: dts: google: Add initial Oriole/pixel 6 board support
>    arm64: defconfig: Enable Google Tensor SoC
>    MAINTAINERS: add entry for Google Tensor SoC
>
>   .../devicetree/bindings/arm/google.yaml       |   46 +
>   .../bindings/clock/google,gs101-clock.yaml    |  125 +
>   .../samsung,pinctrl-wakeup-interrupt.yaml     |    2 +
>   .../bindings/pinctrl/samsung,pinctrl.yaml     |   19 +
>   .../bindings/serial/samsung_uart.yaml         |    2 +
>   .../bindings/soc/samsung/exynos-pmu.yaml      |    2 +
>   .../soc/samsung/samsung,exynos-sysreg.yaml    |    6 +
>   .../bindings/watchdog/samsung-wdt.yaml        |   10 +-
>   MAINTAINERS                                   |   10 +
>   arch/arm64/Kconfig.platforms                  |    6 +
>   arch/arm64/boot/dts/Makefile                  |    1 +
>   arch/arm64/boot/dts/google/Makefile           |    4 +
>   arch/arm64/boot/dts/google/gs101-oriole.dts   |   79 +
>   arch/arm64/boot/dts/google/gs101-pinctrl.dtsi | 1275 ++++++++++
>   arch/arm64/boot/dts/google/gs101-pinctrl.h    |   32 +
>   arch/arm64/boot/dts/google/gs101.dtsi         |  503 ++++
>   arch/arm64/configs/defconfig                  |    1 +
>   drivers/clk/samsung/Kconfig                   |    9 +
>   drivers/clk/samsung/Makefile                  |    2 +
>   drivers/clk/samsung/clk-gs101.c               | 2164 +++++++++++++++++
>   drivers/clk/samsung/clk-pll.c                 |    9 +-
>   drivers/clk/samsung/clk-pll.h                 |    3 +
>   .../pinctrl/samsung/pinctrl-exynos-arm64.c    |  163 ++
>   drivers/pinctrl/samsung/pinctrl-exynos.c      |   84 +-
>   drivers/pinctrl/samsung/pinctrl-exynos.h      |   41 +
>   drivers/pinctrl/samsung/pinctrl-samsung.c     |    4 +
>   drivers/pinctrl/samsung/pinctrl-samsung.h     |   24 +
>   drivers/tty/serial/samsung_tty.c              |   12 +
>   drivers/watchdog/s3c2410_wdt.c                |  104 +-
>   include/dt-bindings/clock/google,gs101.h      |  232 ++
>   30 files changed, 4961 insertions(+), 13 deletions(-)
>   create mode 100644 Documentation/devicetree/bindings/arm/google.yaml
>   create mode 100644 Documentation/devicetree/bindings/clock/google,gs101-clock.yaml
>   create mode 100644 arch/arm64/boot/dts/google/Makefile
>   create mode 100644 arch/arm64/boot/dts/google/gs101-oriole.dts
>   create mode 100644 arch/arm64/boot/dts/google/gs101-pinctrl.dtsi
>   create mode 100644 arch/arm64/boot/dts/google/gs101-pinctrl.h
>   create mode 100644 arch/arm64/boot/dts/google/gs101.dtsi
>   create mode 100644 drivers/clk/samsung/clk-gs101.c
>   create mode 100644 include/dt-bindings/clock/google,gs101.h
>

Re: [PATCH v2 00/20] Add minimal Tensor/GS101 SoC support and Oriole/Pixel6 board

[Maksym Holovach]

Hi, all

I wanted to inquire about how do you all feel about calling this SoC by 
the Google "gs101" name.

I believe the proper name for it should be the actual Samsung name, 
written in the silicon and reported in the Chip ID hardware: Exynos9845. 
This also touches the Tensor G2 (Exynos9855), Tensor G3 (Exynos9865), 
and possibly the "Tesla" SoCs.

I do not think the Linux kernel should be a marketing material: it 
should reflect reality. The chip is almost 100% composed of Samsung 
Exynos IP blocks and should be called that way.

Yours,

- Markuss

On 10/11/23 01:49, Peter Griffin wrote:
> Hi folks,
>
> Firstly, thanks to everyone who reviewed the v1 series! V2 incorporates all
> the review feedback received so far.
>
> This series adds initial SoC support for the GS101 SoC and also initial board
> support for Pixel 6 phone (Oriole).
>
> The gs101 / Tensor SoC is also used in Pixel6a (bluejay) and Pixel 6 Pro
> (raven) phones. Currently DT is added for the gs101 SoC and Oriole.
> As you can see from the patches the SoC is based on a Samsung Exynos SoC,
> and therefore lots of the low level Exynos drivers can be re-used.
>
> The support added in this series consists of:
> * cpus
> * pinctrl
> * some CCF implementation
> * watchdog
> * uart
> * gpio
>
> This is enough to boot through to a busybox initramfs and shell using an
> upstream kernel though :) More platform support will be added over the
> following weeks and months.
>
> Note 1: I've removed the dtbo overlay from v2 submission and will re-submit once
> I have appropriate documentation for it.
>
> Note 2: I've left the bootargs in dts with earlycon for now, for two reasons.
> 1) The bootloader hangs if bootargs isn't present in the dtb as it tries to
> re-write this with additional bootargs.
> 2) there is a issue whereby the full serial console doesn't come up properly
> if earlycon isn't also specified. This issue needs further investigation.
>
> Note 3: In `dt-bindings: pinctrl: samsung: add google,gs101-pinctrl compatible`
> I tried to narrow the interrupts check to google,gs101-pinctrl but I still see
> a warning:
> gs101-oriole.dtb: pinctrl@174d0000: interrupts: [[0, 0, 4],[..] is too long
>
> If anyone can educate me on what I've done wrong here it would be most
> appreciated!
>
> kind regards,
>
> Peter.
>
> Changes since v1:
>   - Remove irq/gs101.h and replace macros with irq numbers globally
>   - exynos-pmu - keep alphabetical order
>   - add cmu_apm to clock bindings documentation
>   - sysreg bindings - remove superfluous `google,gs101-sysreg`
>   - watchdog bindings - Alphanumerical order, update gs201 comment
>   - samsung,pinctrl.yaml - add new "if:then:else:" to narrow for google SoC
>   - samsung,pinctrl-wakeup-interrupt.yaml - Alphanumerical order
>   - samsung,pinctrl- add google,gs101-wakeup-eint compatible
>   - clk-pll: fixup typos
>   - clk-gs101: fix kernel test robot warnings (add 2 new clocks,dividers,gate)
>   - clk-gs101: fix alphabetical order
>   - clk-gs101: cmu_apm: fixup typo and missing empty entry
>   - clk-gs101: cmu_misc: remove clocks that were being registerred twice
>   - pinctrl: filter sel: rename/reorder variables, add comment for FLTCON bitfield
>   - pinctrl: filter sel: avoid setting reserved bits by loop over FLTCON1 pins as well
>   - pinctrl: gs101: rename bank_type_6/7 structs to be more specific, split from filter
>   - watchdog: s3c2410_wdt: remove dev_info prints
>   - gs101.dtsi/oriole.dts: order by unit node, remove underscores from node name, blank lines
>     add SoC node, split dts and dtsi into separate patches, remove 'DVT' suffix
>   - gs101-oriole.dtso: Remove overlay until board_id is documented properly
>   - Add GS101_PIN_* macros to gs101-pinctrl.h instead of using Exynos ones
>   - gpio-keys: update linux,code to use input-event-code macros
>   - add dedicated gs101-uart compatible
>
> Peter Griffin (20):
>    dt-bindings: soc: samsung: exynos-pmu: Add gs101 compatible
>    dt-bindings: clock: Add Google gs101 clock management unit bindings
>    dt-bindings: soc: google: exynos-sysreg: add dedicated SYSREG
>      compatibles to GS101
>    dt-bindings: watchdog: Document Google gs101 & gs201 watchdog bindings
>    dt-bindings: arm: google: Add bindings for Google ARM platforms
>    dt-bindings: pinctrl: samsung: add google,gs101-pinctrl compatible
>    dt-bindings: pinctrl: samsung: add gs101-wakeup-eint compatible
>    dt-bindings: serial: samsung: Add google-gs101-uart compatible
>    clk: samsung: clk-pll: Add support for pll_{0516,0517,518}
>    clk: samsung: clk-gs101: Add cmu_top registers, plls, mux and gates
>    clk: samsung: clk-gs101: add CMU_APM support
>    clk: samsung: clk-gs101: Add support for CMU_MISC clock unit
>    pinctrl: samsung: Add filter selection support for alive banks
>    pinctrl: samsung: Add gs101 SoC pinctrl configuration
>    watchdog: s3c2410_wdt: Add support for Google tensor SoCs
>    tty: serial: samsung: Add gs101 compatible and SoC data
>    arm64: dts: google: Add initial Google gs101 SoC support
>    arm64: dts: google: Add initial Oriole/pixel 6 board support
>    arm64: defconfig: Enable Google Tensor SoC
>    MAINTAINERS: add entry for Google Tensor SoC
>
>   .../devicetree/bindings/arm/google.yaml       |   46 +
>   .../bindings/clock/google,gs101-clock.yaml    |  125 +
>   .../samsung,pinctrl-wakeup-interrupt.yaml     |    2 +
>   .../bindings/pinctrl/samsung,pinctrl.yaml     |   19 +
>   .../bindings/serial/samsung_uart.yaml         |    2 +
>   .../bindings/soc/samsung/exynos-pmu.yaml      |    2 +
>   .../soc/samsung/samsung,exynos-sysreg.yaml    |    6 +
>   .../bindings/watchdog/samsung-wdt.yaml        |   10 +-
>   MAINTAINERS                                   |   10 +
>   arch/arm64/Kconfig.platforms                  |    6 +
>   arch/arm64/boot/dts/Makefile                  |    1 +
>   arch/arm64/boot/dts/google/Makefile           |    4 +
>   arch/arm64/boot/dts/google/gs101-oriole.dts   |   79 +
>   arch/arm64/boot/dts/google/gs101-pinctrl.dtsi | 1275 ++++++++++
>   arch/arm64/boot/dts/google/gs101-pinctrl.h    |   32 +
>   arch/arm64/boot/dts/google/gs101.dtsi         |  503 ++++
>   arch/arm64/configs/defconfig                  |    1 +
>   drivers/clk/samsung/Kconfig                   |    9 +
>   drivers/clk/samsung/Makefile                  |    2 +
>   drivers/clk/samsung/clk-gs101.c               | 2164 +++++++++++++++++
>   drivers/clk/samsung/clk-pll.c                 |    9 +-
>   drivers/clk/samsung/clk-pll.h                 |    3 +
>   .../pinctrl/samsung/pinctrl-exynos-arm64.c    |  163 ++
>   drivers/pinctrl/samsung/pinctrl-exynos.c      |   84 +-
>   drivers/pinctrl/samsung/pinctrl-exynos.h      |   41 +
>   drivers/pinctrl/samsung/pinctrl-samsung.c     |    4 +
>   drivers/pinctrl/samsung/pinctrl-samsung.h     |   24 +
>   drivers/tty/serial/samsung_tty.c              |   12 +
>   drivers/watchdog/s3c2410_wdt.c                |  104 +-
>   include/dt-bindings/clock/google,gs101.h      |  232 ++
>   30 files changed, 4961 insertions(+), 13 deletions(-)
>   create mode 100644 Documentation/devicetree/bindings/arm/google.yaml
>   create mode 100644 Documentation/devicetree/bindings/clock/google,gs101-clock.yaml
>   create mode 100644 arch/arm64/boot/dts/google/Makefile
>   create mode 100644 arch/arm64/boot/dts/google/gs101-oriole.dts
>   create mode 100644 arch/arm64/boot/dts/google/gs101-pinctrl.dtsi
>   create mode 100644 arch/arm64/boot/dts/google/gs101-pinctrl.h
>   create mode 100644 arch/arm64/boot/dts/google/gs101.dtsi
>   create mode 100644 drivers/clk/samsung/clk-gs101.c
>   create mode 100644 include/dt-bindings/clock/google,gs101.h
>

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH v2 00/20] Add minimal Tensor/GS101 SoC support and Oriole/Pixel6 board

[Peter Griffin]

Hi Maksym,

Thanks for your feedback.

On Thu, 2 Nov 2023 at 22:32, Maksym Holovach
<maksym.holovach.an.2022@lpnu.ua> wrote:
>
> Hi, all
>
> I wanted to inquire about how do you all feel about calling this SoC by
> the Google "gs101" name.

Interesting question, I think calling it gs101 is the correct approach see
below for my rationale.

>
> I believe the proper name for it should be the actual Samsung name,
> written in the silicon and reported in the Chip ID hardware: Exynos9845.
> This also touches the Tensor G2 (Exynos9855), Tensor G3 (Exynos9865),
> and possibly the "Tesla" SoCs.
>
> I do not think the Linux kernel should be a marketing material: it
> should reflect reality. The chip is almost 100% composed of Samsung
> Exynos IP blocks and should be called that way.

As you alluded to Tesla fsd and Axis artpec8 SoCs are also based on
Exynos designs and support upstream uses the axis,artpec8* or tesla,fsd*
compatibles.

So using google,gs101 is consistent with the existing upstream naming
scheme, for customized ASICs that were based off a Exynos design. But
it also reflects the reality that this SoC is not a Exynos9845 as there is
also a lot of Google owned and other third party IP integrated that is not
found in Exynos9845.

I guess the same is also true for `axis,artpec8` and `tesla,fsd` SoCs.
IMO the SoC compatible string should be uniquely identifying the actual
SoC, not a close relative.

Regarding product_id you are correct this reads 0x09845000 but even
within Samsung Exynos family there are examples where the register
value does not match the SoC compatible. For example Exynos850 SoC
has a product ID value of "E3830". Where the Linux compatible is
matching the Samsung marketing name, not the internal/outdated name.

regards,

Peter.



>
> Yours,
>
> - Markuss
>
> On 10/11/23 01:49, Peter Griffin wrote:
> > Hi folks,
> >
> > Firstly, thanks to everyone who reviewed the v1 series! V2 incorporates all
> > the review feedback received so far.
> >
> > This series adds initial SoC support for the GS101 SoC and also initial board
> > support for Pixel 6 phone (Oriole).
> >
> > The gs101 / Tensor SoC is also used in Pixel6a (bluejay) and Pixel 6 Pro
> > (raven) phones. Currently DT is added for the gs101 SoC and Oriole.
> > As you can see from the patches the SoC is based on a Samsung Exynos SoC,
> > and therefore lots of the low level Exynos drivers can be re-used.
> >
> > The support added in this series consists of:
> > * cpus
> > * pinctrl
> > * some CCF implementation
> > * watchdog
> > * uart
> > * gpio
> >
> > This is enough to boot through to a busybox initramfs and shell using an
> > upstream kernel though :) More platform support will be added over the
> > following weeks and months.
> >
> > Note 1: I've removed the dtbo overlay from v2 submission and will re-submit once
> > I have appropriate documentation for it.
> >
> > Note 2: I've left the bootargs in dts with earlycon for now, for two reasons.
> > 1) The bootloader hangs if bootargs isn't present in the dtb as it tries to
> > re-write this with additional bootargs.
> > 2) there is a issue whereby the full serial console doesn't come up properly
> > if earlycon isn't also specified. This issue needs further investigation.
> >
> > Note 3: In `dt-bindings: pinctrl: samsung: add google,gs101-pinctrl compatible`
> > I tried to narrow the interrupts check to google,gs101-pinctrl but I still see
> > a warning:
> > gs101-oriole.dtb: pinctrl@174d0000: interrupts: [[0, 0, 4],[..] is too long
> >
> > If anyone can educate me on what I've done wrong here it would be most
> > appreciated!
> >
> > kind regards,
> >
> > Peter.
> >
> > Changes since v1:
> >   - Remove irq/gs101.h and replace macros with irq numbers globally
> >   - exynos-pmu - keep alphabetical order
> >   - add cmu_apm to clock bindings documentation
> >   - sysreg bindings - remove superfluous `google,gs101-sysreg`
> >   - watchdog bindings - Alphanumerical order, update gs201 comment
> >   - samsung,pinctrl.yaml - add new "if:then:else:" to narrow for google SoC
> >   - samsung,pinctrl-wakeup-interrupt.yaml - Alphanumerical order
> >   - samsung,pinctrl- add google,gs101-wakeup-eint compatible
> >   - clk-pll: fixup typos
> >   - clk-gs101: fix kernel test robot warnings (add 2 new clocks,dividers,gate)
> >   - clk-gs101: fix alphabetical order
> >   - clk-gs101: cmu_apm: fixup typo and missing empty entry
> >   - clk-gs101: cmu_misc: remove clocks that were being registerred twice
> >   - pinctrl: filter sel: rename/reorder variables, add comment for FLTCON bitfield
> >   - pinctrl: filter sel: avoid setting reserved bits by loop over FLTCON1 pins as well
> >   - pinctrl: gs101: rename bank_type_6/7 structs to be more specific, split from filter
> >   - watchdog: s3c2410_wdt: remove dev_info prints
> >   - gs101.dtsi/oriole.dts: order by unit node, remove underscores from node name, blank lines
> >     add SoC node, split dts and dtsi into separate patches, remove 'DVT' suffix
> >   - gs101-oriole.dtso: Remove overlay until board_id is documented properly
> >   - Add GS101_PIN_* macros to gs101-pinctrl.h instead of using Exynos ones
> >   - gpio-keys: update linux,code to use input-event-code macros
> >   - add dedicated gs101-uart compatible
> >
> > Peter Griffin (20):
> >    dt-bindings: soc: samsung: exynos-pmu: Add gs101 compatible
> >    dt-bindings: clock: Add Google gs101 clock management unit bindings
> >    dt-bindings: soc: google: exynos-sysreg: add dedicated SYSREG
> >      compatibles to GS101
> >    dt-bindings: watchdog: Document Google gs101 & gs201 watchdog bindings
> >    dt-bindings: arm: google: Add bindings for Google ARM platforms
> >    dt-bindings: pinctrl: samsung: add google,gs101-pinctrl compatible
> >    dt-bindings: pinctrl: samsung: add gs101-wakeup-eint compatible
> >    dt-bindings: serial: samsung: Add google-gs101-uart compatible
> >    clk: samsung: clk-pll: Add support for pll_{0516,0517,518}
> >    clk: samsung: clk-gs101: Add cmu_top registers, plls, mux and gates
> >    clk: samsung: clk-gs101: add CMU_APM support
> >    clk: samsung: clk-gs101: Add support for CMU_MISC clock unit
> >    pinctrl: samsung: Add filter selection support for alive banks
> >    pinctrl: samsung: Add gs101 SoC pinctrl configuration
> >    watchdog: s3c2410_wdt: Add support for Google tensor SoCs
> >    tty: serial: samsung: Add gs101 compatible and SoC data
> >    arm64: dts: google: Add initial Google gs101 SoC support
> >    arm64: dts: google: Add initial Oriole/pixel 6 board support
> >    arm64: defconfig: Enable Google Tensor SoC
> >    MAINTAINERS: add entry for Google Tensor SoC
> >
> >   .../devicetree/bindings/arm/google.yaml       |   46 +
> >   .../bindings/clock/google,gs101-clock.yaml    |  125 +
> >   .../samsung,pinctrl-wakeup-interrupt.yaml     |    2 +
> >   .../bindings/pinctrl/samsung,pinctrl.yaml     |   19 +
> >   .../bindings/serial/samsung_uart.yaml         |    2 +
> >   .../bindings/soc/samsung/exynos-pmu.yaml      |    2 +
> >   .../soc/samsung/samsung,exynos-sysreg.yaml    |    6 +
> >   .../bindings/watchdog/samsung-wdt.yaml        |   10 +-
> >   MAINTAINERS                                   |   10 +
> >   arch/arm64/Kconfig.platforms                  |    6 +
> >   arch/arm64/boot/dts/Makefile                  |    1 +
> >   arch/arm64/boot/dts/google/Makefile           |    4 +
> >   arch/arm64/boot/dts/google/gs101-oriole.dts   |   79 +
> >   arch/arm64/boot/dts/google/gs101-pinctrl.dtsi | 1275 ++++++++++
> >   arch/arm64/boot/dts/google/gs101-pinctrl.h    |   32 +
> >   arch/arm64/boot/dts/google/gs101.dtsi         |  503 ++++
> >   arch/arm64/configs/defconfig                  |    1 +
> >   drivers/clk/samsung/Kconfig                   |    9 +
> >   drivers/clk/samsung/Makefile                  |    2 +
> >   drivers/clk/samsung/clk-gs101.c               | 2164 +++++++++++++++++
> >   drivers/clk/samsung/clk-pll.c                 |    9 +-
> >   drivers/clk/samsung/clk-pll.h                 |    3 +
> >   .../pinctrl/samsung/pinctrl-exynos-arm64.c    |  163 ++
> >   drivers/pinctrl/samsung/pinctrl-exynos.c      |   84 +-
> >   drivers/pinctrl/samsung/pinctrl-exynos.h      |   41 +
> >   drivers/pinctrl/samsung/pinctrl-samsung.c     |    4 +
> >   drivers/pinctrl/samsung/pinctrl-samsung.h     |   24 +
> >   drivers/tty/serial/samsung_tty.c              |   12 +
> >   drivers/watchdog/s3c2410_wdt.c                |  104 +-
> >   include/dt-bindings/clock/google,gs101.h      |  232 ++
> >   30 files changed, 4961 insertions(+), 13 deletions(-)
> >   create mode 100644 Documentation/devicetree/bindings/arm/google.yaml
> >   create mode 100644 Documentation/devicetree/bindings/clock/google,gs101-clock.yaml
> >   create mode 100644 arch/arm64/boot/dts/google/Makefile
> >   create mode 100644 arch/arm64/boot/dts/google/gs101-oriole.dts
> >   create mode 100644 arch/arm64/boot/dts/google/gs101-pinctrl.dtsi
> >   create mode 100644 arch/arm64/boot/dts/google/gs101-pinctrl.h
> >   create mode 100644 arch/arm64/boot/dts/google/gs101.dtsi
> >   create mode 100644 drivers/clk/samsung/clk-gs101.c
> >   create mode 100644 include/dt-bindings/clock/google,gs101.h
> >

Re: [PATCH v2 00/20] Add minimal Tensor/GS101 SoC support and Oriole/Pixel6 board

[Peter Griffin]

Hi Maksym,

Thanks for your feedback.

On Thu, 2 Nov 2023 at 22:32, Maksym Holovach
<maksym.holovach.an.2022@lpnu.ua> wrote:
>
> Hi, all
>
> I wanted to inquire about how do you all feel about calling this SoC by
> the Google "gs101" name.

Interesting question, I think calling it gs101 is the correct approach see
below for my rationale.

>
> I believe the proper name for it should be the actual Samsung name,
> written in the silicon and reported in the Chip ID hardware: Exynos9845.
> This also touches the Tensor G2 (Exynos9855), Tensor G3 (Exynos9865),
> and possibly the "Tesla" SoCs.
>
> I do not think the Linux kernel should be a marketing material: it
> should reflect reality. The chip is almost 100% composed of Samsung
> Exynos IP blocks and should be called that way.

As you alluded to Tesla fsd and Axis artpec8 SoCs are also based on
Exynos designs and support upstream uses the axis,artpec8* or tesla,fsd*
compatibles.

So using google,gs101 is consistent with the existing upstream naming
scheme, for customized ASICs that were based off a Exynos design. But
it also reflects the reality that this SoC is not a Exynos9845 as there is
also a lot of Google owned and other third party IP integrated that is not
found in Exynos9845.

I guess the same is also true for `axis,artpec8` and `tesla,fsd` SoCs.
IMO the SoC compatible string should be uniquely identifying the actual
SoC, not a close relative.

Regarding product_id you are correct this reads 0x09845000 but even
within Samsung Exynos family there are examples where the register
value does not match the SoC compatible. For example Exynos850 SoC
has a product ID value of "E3830". Where the Linux compatible is
matching the Samsung marketing name, not the internal/outdated name.

regards,

Peter.



>
> Yours,
>
> - Markuss
>
> On 10/11/23 01:49, Peter Griffin wrote:
> > Hi folks,
> >
> > Firstly, thanks to everyone who reviewed the v1 series! V2 incorporates all
> > the review feedback received so far.
> >
> > This series adds initial SoC support for the GS101 SoC and also initial board
> > support for Pixel 6 phone (Oriole).
> >
> > The gs101 / Tensor SoC is also used in Pixel6a (bluejay) and Pixel 6 Pro
> > (raven) phones. Currently DT is added for the gs101 SoC and Oriole.
> > As you can see from the patches the SoC is based on a Samsung Exynos SoC,
> > and therefore lots of the low level Exynos drivers can be re-used.
> >
> > The support added in this series consists of:
> > * cpus
> > * pinctrl
> > * some CCF implementation
> > * watchdog
> > * uart
> > * gpio
> >
> > This is enough to boot through to a busybox initramfs and shell using an
> > upstream kernel though :) More platform support will be added over the
> > following weeks and months.
> >
> > Note 1: I've removed the dtbo overlay from v2 submission and will re-submit once
> > I have appropriate documentation for it.
> >
> > Note 2: I've left the bootargs in dts with earlycon for now, for two reasons.
> > 1) The bootloader hangs if bootargs isn't present in the dtb as it tries to
> > re-write this with additional bootargs.
> > 2) there is a issue whereby the full serial console doesn't come up properly
> > if earlycon isn't also specified. This issue needs further investigation.
> >
> > Note 3: In `dt-bindings: pinctrl: samsung: add google,gs101-pinctrl compatible`
> > I tried to narrow the interrupts check to google,gs101-pinctrl but I still see
> > a warning:
> > gs101-oriole.dtb: pinctrl@174d0000: interrupts: [[0, 0, 4],[..] is too long
> >
> > If anyone can educate me on what I've done wrong here it would be most
> > appreciated!
> >
> > kind regards,
> >
> > Peter.
> >
> > Changes since v1:
> >   - Remove irq/gs101.h and replace macros with irq numbers globally
> >   - exynos-pmu - keep alphabetical order
> >   - add cmu_apm to clock bindings documentation
> >   - sysreg bindings - remove superfluous `google,gs101-sysreg`
> >   - watchdog bindings - Alphanumerical order, update gs201 comment
> >   - samsung,pinctrl.yaml - add new "if:then:else:" to narrow for google SoC
> >   - samsung,pinctrl-wakeup-interrupt.yaml - Alphanumerical order
> >   - samsung,pinctrl- add google,gs101-wakeup-eint compatible
> >   - clk-pll: fixup typos
> >   - clk-gs101: fix kernel test robot warnings (add 2 new clocks,dividers,gate)
> >   - clk-gs101: fix alphabetical order
> >   - clk-gs101: cmu_apm: fixup typo and missing empty entry
> >   - clk-gs101: cmu_misc: remove clocks that were being registerred twice
> >   - pinctrl: filter sel: rename/reorder variables, add comment for FLTCON bitfield
> >   - pinctrl: filter sel: avoid setting reserved bits by loop over FLTCON1 pins as well
> >   - pinctrl: gs101: rename bank_type_6/7 structs to be more specific, split from filter
> >   - watchdog: s3c2410_wdt: remove dev_info prints
> >   - gs101.dtsi/oriole.dts: order by unit node, remove underscores from node name, blank lines
> >     add SoC node, split dts and dtsi into separate patches, remove 'DVT' suffix
> >   - gs101-oriole.dtso: Remove overlay until board_id is documented properly
> >   - Add GS101_PIN_* macros to gs101-pinctrl.h instead of using Exynos ones
> >   - gpio-keys: update linux,code to use input-event-code macros
> >   - add dedicated gs101-uart compatible
> >
> > Peter Griffin (20):
> >    dt-bindings: soc: samsung: exynos-pmu: Add gs101 compatible
> >    dt-bindings: clock: Add Google gs101 clock management unit bindings
> >    dt-bindings: soc: google: exynos-sysreg: add dedicated SYSREG
> >      compatibles to GS101
> >    dt-bindings: watchdog: Document Google gs101 & gs201 watchdog bindings
> >    dt-bindings: arm: google: Add bindings for Google ARM platforms
> >    dt-bindings: pinctrl: samsung: add google,gs101-pinctrl compatible
> >    dt-bindings: pinctrl: samsung: add gs101-wakeup-eint compatible
> >    dt-bindings: serial: samsung: Add google-gs101-uart compatible
> >    clk: samsung: clk-pll: Add support for pll_{0516,0517,518}
> >    clk: samsung: clk-gs101: Add cmu_top registers, plls, mux and gates
> >    clk: samsung: clk-gs101: add CMU_APM support
> >    clk: samsung: clk-gs101: Add support for CMU_MISC clock unit
> >    pinctrl: samsung: Add filter selection support for alive banks
> >    pinctrl: samsung: Add gs101 SoC pinctrl configuration
> >    watchdog: s3c2410_wdt: Add support for Google tensor SoCs
> >    tty: serial: samsung: Add gs101 compatible and SoC data
> >    arm64: dts: google: Add initial Google gs101 SoC support
> >    arm64: dts: google: Add initial Oriole/pixel 6 board support
> >    arm64: defconfig: Enable Google Tensor SoC
> >    MAINTAINERS: add entry for Google Tensor SoC
> >
> >   .../devicetree/bindings/arm/google.yaml       |   46 +
> >   .../bindings/clock/google,gs101-clock.yaml    |  125 +
> >   .../samsung,pinctrl-wakeup-interrupt.yaml     |    2 +
> >   .../bindings/pinctrl/samsung,pinctrl.yaml     |   19 +
> >   .../bindings/serial/samsung_uart.yaml         |    2 +
> >   .../bindings/soc/samsung/exynos-pmu.yaml      |    2 +
> >   .../soc/samsung/samsung,exynos-sysreg.yaml    |    6 +
> >   .../bindings/watchdog/samsung-wdt.yaml        |   10 +-
> >   MAINTAINERS                                   |   10 +
> >   arch/arm64/Kconfig.platforms                  |    6 +
> >   arch/arm64/boot/dts/Makefile                  |    1 +
> >   arch/arm64/boot/dts/google/Makefile           |    4 +
> >   arch/arm64/boot/dts/google/gs101-oriole.dts   |   79 +
> >   arch/arm64/boot/dts/google/gs101-pinctrl.dtsi | 1275 ++++++++++
> >   arch/arm64/boot/dts/google/gs101-pinctrl.h    |   32 +
> >   arch/arm64/boot/dts/google/gs101.dtsi         |  503 ++++
> >   arch/arm64/configs/defconfig                  |    1 +
> >   drivers/clk/samsung/Kconfig                   |    9 +
> >   drivers/clk/samsung/Makefile                  |    2 +
> >   drivers/clk/samsung/clk-gs101.c               | 2164 +++++++++++++++++
> >   drivers/clk/samsung/clk-pll.c                 |    9 +-
> >   drivers/clk/samsung/clk-pll.h                 |    3 +
> >   .../pinctrl/samsung/pinctrl-exynos-arm64.c    |  163 ++
> >   drivers/pinctrl/samsung/pinctrl-exynos.c      |   84 +-
> >   drivers/pinctrl/samsung/pinctrl-exynos.h      |   41 +
> >   drivers/pinctrl/samsung/pinctrl-samsung.c     |    4 +
> >   drivers/pinctrl/samsung/pinctrl-samsung.h     |   24 +
> >   drivers/tty/serial/samsung_tty.c              |   12 +
> >   drivers/watchdog/s3c2410_wdt.c                |  104 +-
> >   include/dt-bindings/clock/google,gs101.h      |  232 ++
> >   30 files changed, 4961 insertions(+), 13 deletions(-)
> >   create mode 100644 Documentation/devicetree/bindings/arm/google.yaml
> >   create mode 100644 Documentation/devicetree/bindings/clock/google,gs101-clock.yaml
> >   create mode 100644 arch/arm64/boot/dts/google/Makefile
> >   create mode 100644 arch/arm64/boot/dts/google/gs101-oriole.dts
> >   create mode 100644 arch/arm64/boot/dts/google/gs101-pinctrl.dtsi
> >   create mode 100644 arch/arm64/boot/dts/google/gs101-pinctrl.h
> >   create mode 100644 arch/arm64/boot/dts/google/gs101.dtsi
> >   create mode 100644 drivers/clk/samsung/clk-gs101.c
> >   create mode 100644 include/dt-bindings/clock/google,gs101.h
> >

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH v2 00/20] Add minimal Tensor/GS101 SoC support and Oriole/Pixel6 board

[Maksym Holovach]

Hi Peter,

On 11/3/23 15:11, Peter Griffin wrote:
> Hi Maksym,
>
> Thanks for your feedback.
>
> On Thu, 2 Nov 2023 at 22:32, Maksym Holovach
> <maksym.holovach.an.2022@lpnu.ua> wrote:
>> Hi, all
>>
>> I wanted to inquire about how do you all feel about calling this SoC by
>> the Google "gs101" name.
> Interesting question, I think calling it gs101 is the correct approach see
> below for my rationale.
>
>> I believe the proper name for it should be the actual Samsung name,
>> written in the silicon and reported in the Chip ID hardware: Exynos9845.
>> This also touches the Tensor G2 (Exynos9855), Tensor G3 (Exynos9865),
>> and possibly the "Tesla" SoCs.
>>
>> I do not think the Linux kernel should be a marketing material: it
>> should reflect reality. The chip is almost 100% composed of Samsung
>> Exynos IP blocks and should be called that way.
> As you alluded to Tesla fsd and Axis artpec8 SoCs are also based on
> Exynos designs and support upstream uses the axis,artpec8* or tesla,fsd*
> compatibles.
>
> So using google,gs101 is consistent with the existing upstream naming
> scheme, for customized ASICs that were based off a Exynos design. But
> it also reflects the reality that this SoC is not a Exynos9845 as there is
> also a lot of Google owned and other third party IP integrated that is not
> found in Exynos9845.

A quick question: Do you imply Exynos9845 exists outside of the context 
of Tensor G1? I used to believe Exynos9845 **is** Tensor G1.

Also, what kind of Google IP are you talking about? I believe only the 
neural accelerator should be custom-ish.

Additionally, I believe it having or not having Google IP is irrelevant: 
for example, the new Raspberry Pi 5 Broadcom SoC has a lot of 
Raspberry's own IP, but it's still called Broadcom as it's the real 
manufacturer and designer of the chip.

>
> I guess the same is also true for `axis,artpec8` and `tesla,fsd` SoCs.
> IMO the SoC compatible string should be uniquely identifying the actual
> SoC, not a close relative.
>
> Regarding product_id you are correct this reads 0x09845000 but even
> within Samsung Exynos family there are examples where the register
> value does not match the SoC compatible. For example Exynos850 SoC
> has a product ID value of "E3830". Where the Linux compatible is
> matching the Samsung marketing name, not the internal/outdated name.

I did not know Exynos 850 is also not going under it's real name. 
Ultimately, I believe all of those SoCs should go under their technical 
name in the exynos/ directory.

Another concern is that Google could in the future license other SoC: be 
it Qualcomm, Nvidia or anything. If we put completely different hw under 
google/ directory, does it really make sense? In that case, who'll 
maintain the google/ directory? Exynos people? Qualcomm people if they 
license it? Some other people?

Then, I don't think Tensor G3 has a proper "GS" name, it goes by "Zuma" 
in decompiled kernel modules as far as I see.

Finally, Tesla people already tried to submit drivers called by Tesla 
name, but which basically copied the functionality of the Exynos 
drivers. We would want to avoid that, ideally.

My opinion is that all the Tesla and Google SoCs should be in the 
exynos/ directory, not only because they are basically Samsung Exynos, 
but also because they don't really need a separate directory: neither 
Google nor Tesla didn't neither manufacture or design those SoCs from 
scratch. The only reason I can think of for them to have it in a 
separate directory is maybe because Google and Tesla actually paid 
Samsung money for the right to call Exynos "Google designed" SoCs, but I 
believe the kernel should be left out of that.

>
> regards,
>
> Peter.
>
>
>
>> Yours,
>>
>> - Markuss
>>
>> On 10/11/23 01:49, Peter Griffin wrote:
>>> Hi folks,
>>>
>>> Firstly, thanks to everyone who reviewed the v1 series! V2 incorporates all
>>> the review feedback received so far.
>>>
>>> This series adds initial SoC support for the GS101 SoC and also initial board
>>> support for Pixel 6 phone (Oriole).
>>>
>>> The gs101 / Tensor SoC is also used in Pixel6a (bluejay) and Pixel 6 Pro
>>> (raven) phones. Currently DT is added for the gs101 SoC and Oriole.
>>> As you can see from the patches the SoC is based on a Samsung Exynos SoC,
>>> and therefore lots of the low level Exynos drivers can be re-used.
>>>
>>> The support added in this series consists of:
>>> * cpus
>>> * pinctrl
>>> * some CCF implementation
>>> * watchdog
>>> * uart
>>> * gpio
>>>
>>> This is enough to boot through to a busybox initramfs and shell using an
>>> upstream kernel though :) More platform support will be added over the
>>> following weeks and months.
>>>
>>> Note 1: I've removed the dtbo overlay from v2 submission and will re-submit once
>>> I have appropriate documentation for it.
>>>
>>> Note 2: I've left the bootargs in dts with earlycon for now, for two reasons.
>>> 1) The bootloader hangs if bootargs isn't present in the dtb as it tries to
>>> re-write this with additional bootargs.
>>> 2) there is a issue whereby the full serial console doesn't come up properly
>>> if earlycon isn't also specified. This issue needs further investigation.
>>>
>>> Note 3: In `dt-bindings: pinctrl: samsung: add google,gs101-pinctrl compatible`
>>> I tried to narrow the interrupts check to google,gs101-pinctrl but I still see
>>> a warning:
>>> gs101-oriole.dtb: pinctrl@174d0000: interrupts: [[0, 0, 4],[..] is too long
>>>
>>> If anyone can educate me on what I've done wrong here it would be most
>>> appreciated!
>>>
>>> kind regards,
>>>
>>> Peter.
>>>
>>> Changes since v1:
>>>    - Remove irq/gs101.h and replace macros with irq numbers globally
>>>    - exynos-pmu - keep alphabetical order
>>>    - add cmu_apm to clock bindings documentation
>>>    - sysreg bindings - remove superfluous `google,gs101-sysreg`
>>>    - watchdog bindings - Alphanumerical order, update gs201 comment
>>>    - samsung,pinctrl.yaml - add new "if:then:else:" to narrow for google SoC
>>>    - samsung,pinctrl-wakeup-interrupt.yaml - Alphanumerical order
>>>    - samsung,pinctrl- add google,gs101-wakeup-eint compatible
>>>    - clk-pll: fixup typos
>>>    - clk-gs101: fix kernel test robot warnings (add 2 new clocks,dividers,gate)
>>>    - clk-gs101: fix alphabetical order
>>>    - clk-gs101: cmu_apm: fixup typo and missing empty entry
>>>    - clk-gs101: cmu_misc: remove clocks that were being registerred twice
>>>    - pinctrl: filter sel: rename/reorder variables, add comment for FLTCON bitfield
>>>    - pinctrl: filter sel: avoid setting reserved bits by loop over FLTCON1 pins as well
>>>    - pinctrl: gs101: rename bank_type_6/7 structs to be more specific, split from filter
>>>    - watchdog: s3c2410_wdt: remove dev_info prints
>>>    - gs101.dtsi/oriole.dts: order by unit node, remove underscores from node name, blank lines
>>>      add SoC node, split dts and dtsi into separate patches, remove 'DVT' suffix
>>>    - gs101-oriole.dtso: Remove overlay until board_id is documented properly
>>>    - Add GS101_PIN_* macros to gs101-pinctrl.h instead of using Exynos ones
>>>    - gpio-keys: update linux,code to use input-event-code macros
>>>    - add dedicated gs101-uart compatible
>>>
>>> Peter Griffin (20):
>>>     dt-bindings: soc: samsung: exynos-pmu: Add gs101 compatible
>>>     dt-bindings: clock: Add Google gs101 clock management unit bindings
>>>     dt-bindings: soc: google: exynos-sysreg: add dedicated SYSREG
>>>       compatibles to GS101
>>>     dt-bindings: watchdog: Document Google gs101 & gs201 watchdog bindings
>>>     dt-bindings: arm: google: Add bindings for Google ARM platforms
>>>     dt-bindings: pinctrl: samsung: add google,gs101-pinctrl compatible
>>>     dt-bindings: pinctrl: samsung: add gs101-wakeup-eint compatible
>>>     dt-bindings: serial: samsung: Add google-gs101-uart compatible
>>>     clk: samsung: clk-pll: Add support for pll_{0516,0517,518}
>>>     clk: samsung: clk-gs101: Add cmu_top registers, plls, mux and gates
>>>     clk: samsung: clk-gs101: add CMU_APM support
>>>     clk: samsung: clk-gs101: Add support for CMU_MISC clock unit
>>>     pinctrl: samsung: Add filter selection support for alive banks
>>>     pinctrl: samsung: Add gs101 SoC pinctrl configuration
>>>     watchdog: s3c2410_wdt: Add support for Google tensor SoCs
>>>     tty: serial: samsung: Add gs101 compatible and SoC data
>>>     arm64: dts: google: Add initial Google gs101 SoC support
>>>     arm64: dts: google: Add initial Oriole/pixel 6 board support
>>>     arm64: defconfig: Enable Google Tensor SoC
>>>     MAINTAINERS: add entry for Google Tensor SoC
>>>
>>>    .../devicetree/bindings/arm/google.yaml       |   46 +
>>>    .../bindings/clock/google,gs101-clock.yaml    |  125 +
>>>    .../samsung,pinctrl-wakeup-interrupt.yaml     |    2 +
>>>    .../bindings/pinctrl/samsung,pinctrl.yaml     |   19 +
>>>    .../bindings/serial/samsung_uart.yaml         |    2 +
>>>    .../bindings/soc/samsung/exynos-pmu.yaml      |    2 +
>>>    .../soc/samsung/samsung,exynos-sysreg.yaml    |    6 +
>>>    .../bindings/watchdog/samsung-wdt.yaml        |   10 +-
>>>    MAINTAINERS                                   |   10 +
>>>    arch/arm64/Kconfig.platforms                  |    6 +
>>>    arch/arm64/boot/dts/Makefile                  |    1 +
>>>    arch/arm64/boot/dts/google/Makefile           |    4 +
>>>    arch/arm64/boot/dts/google/gs101-oriole.dts   |   79 +
>>>    arch/arm64/boot/dts/google/gs101-pinctrl.dtsi | 1275 ++++++++++
>>>    arch/arm64/boot/dts/google/gs101-pinctrl.h    |   32 +
>>>    arch/arm64/boot/dts/google/gs101.dtsi         |  503 ++++
>>>    arch/arm64/configs/defconfig                  |    1 +
>>>    drivers/clk/samsung/Kconfig                   |    9 +
>>>    drivers/clk/samsung/Makefile                  |    2 +
>>>    drivers/clk/samsung/clk-gs101.c               | 2164 +++++++++++++++++
>>>    drivers/clk/samsung/clk-pll.c                 |    9 +-
>>>    drivers/clk/samsung/clk-pll.h                 |    3 +
>>>    .../pinctrl/samsung/pinctrl-exynos-arm64.c    |  163 ++
>>>    drivers/pinctrl/samsung/pinctrl-exynos.c      |   84 +-
>>>    drivers/pinctrl/samsung/pinctrl-exynos.h      |   41 +
>>>    drivers/pinctrl/samsung/pinctrl-samsung.c     |    4 +
>>>    drivers/pinctrl/samsung/pinctrl-samsung.h     |   24 +
>>>    drivers/tty/serial/samsung_tty.c              |   12 +
>>>    drivers/watchdog/s3c2410_wdt.c                |  104 +-
>>>    include/dt-bindings/clock/google,gs101.h      |  232 ++
>>>    30 files changed, 4961 insertions(+), 13 deletions(-)
>>>    create mode 100644 Documentation/devicetree/bindings/arm/google.yaml
>>>    create mode 100644 Documentation/devicetree/bindings/clock/google,gs101-clock.yaml
>>>    create mode 100644 arch/arm64/boot/dts/google/Makefile
>>>    create mode 100644 arch/arm64/boot/dts/google/gs101-oriole.dts
>>>    create mode 100644 arch/arm64/boot/dts/google/gs101-pinctrl.dtsi
>>>    create mode 100644 arch/arm64/boot/dts/google/gs101-pinctrl.h
>>>    create mode 100644 arch/arm64/boot/dts/google/gs101.dtsi
>>>    create mode 100644 drivers/clk/samsung/clk-gs101.c
>>>    create mode 100644 include/dt-bindings/clock/google,gs101.h
>>>
- Maksym

Re: [PATCH v2 00/20] Add minimal Tensor/GS101 SoC support and Oriole/Pixel6 board

[Maksym Holovach]

Hi Peter,

On 11/3/23 15:11, Peter Griffin wrote:
> Hi Maksym,
>
> Thanks for your feedback.
>
> On Thu, 2 Nov 2023 at 22:32, Maksym Holovach
> <maksym.holovach.an.2022@lpnu.ua> wrote:
>> Hi, all
>>
>> I wanted to inquire about how do you all feel about calling this SoC by
>> the Google "gs101" name.
> Interesting question, I think calling it gs101 is the correct approach see
> below for my rationale.
>
>> I believe the proper name for it should be the actual Samsung name,
>> written in the silicon and reported in the Chip ID hardware: Exynos9845.
>> This also touches the Tensor G2 (Exynos9855), Tensor G3 (Exynos9865),
>> and possibly the "Tesla" SoCs.
>>
>> I do not think the Linux kernel should be a marketing material: it
>> should reflect reality. The chip is almost 100% composed of Samsung
>> Exynos IP blocks and should be called that way.
> As you alluded to Tesla fsd and Axis artpec8 SoCs are also based on
> Exynos designs and support upstream uses the axis,artpec8* or tesla,fsd*
> compatibles.
>
> So using google,gs101 is consistent with the existing upstream naming
> scheme, for customized ASICs that were based off a Exynos design. But
> it also reflects the reality that this SoC is not a Exynos9845 as there is
> also a lot of Google owned and other third party IP integrated that is not
> found in Exynos9845.

A quick question: Do you imply Exynos9845 exists outside of the context 
of Tensor G1? I used to believe Exynos9845 **is** Tensor G1.

Also, what kind of Google IP are you talking about? I believe only the 
neural accelerator should be custom-ish.

Additionally, I believe it having or not having Google IP is irrelevant: 
for example, the new Raspberry Pi 5 Broadcom SoC has a lot of 
Raspberry's own IP, but it's still called Broadcom as it's the real 
manufacturer and designer of the chip.

>
> I guess the same is also true for `axis,artpec8` and `tesla,fsd` SoCs.
> IMO the SoC compatible string should be uniquely identifying the actual
> SoC, not a close relative.
>
> Regarding product_id you are correct this reads 0x09845000 but even
> within Samsung Exynos family there are examples where the register
> value does not match the SoC compatible. For example Exynos850 SoC
> has a product ID value of "E3830". Where the Linux compatible is
> matching the Samsung marketing name, not the internal/outdated name.

I did not know Exynos 850 is also not going under it's real name. 
Ultimately, I believe all of those SoCs should go under their technical 
name in the exynos/ directory.

Another concern is that Google could in the future license other SoC: be 
it Qualcomm, Nvidia or anything. If we put completely different hw under 
google/ directory, does it really make sense? In that case, who'll 
maintain the google/ directory? Exynos people? Qualcomm people if they 
license it? Some other people?

Then, I don't think Tensor G3 has a proper "GS" name, it goes by "Zuma" 
in decompiled kernel modules as far as I see.

Finally, Tesla people already tried to submit drivers called by Tesla 
name, but which basically copied the functionality of the Exynos 
drivers. We would want to avoid that, ideally.

My opinion is that all the Tesla and Google SoCs should be in the 
exynos/ directory, not only because they are basically Samsung Exynos, 
but also because they don't really need a separate directory: neither 
Google nor Tesla didn't neither manufacture or design those SoCs from 
scratch. The only reason I can think of for them to have it in a 
separate directory is maybe because Google and Tesla actually paid 
Samsung money for the right to call Exynos "Google designed" SoCs, but I 
believe the kernel should be left out of that.

>
> regards,
>
> Peter.
>
>
>
>> Yours,
>>
>> - Markuss
>>
>> On 10/11/23 01:49, Peter Griffin wrote:
>>> Hi folks,
>>>
>>> Firstly, thanks to everyone who reviewed the v1 series! V2 incorporates all
>>> the review feedback received so far.
>>>
>>> This series adds initial SoC support for the GS101 SoC and also initial board
>>> support for Pixel 6 phone (Oriole).
>>>
>>> The gs101 / Tensor SoC is also used in Pixel6a (bluejay) and Pixel 6 Pro
>>> (raven) phones. Currently DT is added for the gs101 SoC and Oriole.
>>> As you can see from the patches the SoC is based on a Samsung Exynos SoC,
>>> and therefore lots of the low level Exynos drivers can be re-used.
>>>
>>> The support added in this series consists of:
>>> * cpus
>>> * pinctrl
>>> * some CCF implementation
>>> * watchdog
>>> * uart
>>> * gpio
>>>
>>> This is enough to boot through to a busybox initramfs and shell using an
>>> upstream kernel though :) More platform support will be added over the
>>> following weeks and months.
>>>
>>> Note 1: I've removed the dtbo overlay from v2 submission and will re-submit once
>>> I have appropriate documentation for it.
>>>
>>> Note 2: I've left the bootargs in dts with earlycon for now, for two reasons.
>>> 1) The bootloader hangs if bootargs isn't present in the dtb as it tries to
>>> re-write this with additional bootargs.
>>> 2) there is a issue whereby the full serial console doesn't come up properly
>>> if earlycon isn't also specified. This issue needs further investigation.
>>>
>>> Note 3: In `dt-bindings: pinctrl: samsung: add google,gs101-pinctrl compatible`
>>> I tried to narrow the interrupts check to google,gs101-pinctrl but I still see
>>> a warning:
>>> gs101-oriole.dtb: pinctrl@174d0000: interrupts: [[0, 0, 4],[..] is too long
>>>
>>> If anyone can educate me on what I've done wrong here it would be most
>>> appreciated!
>>>
>>> kind regards,
>>>
>>> Peter.
>>>
>>> Changes since v1:
>>>    - Remove irq/gs101.h and replace macros with irq numbers globally
>>>    - exynos-pmu - keep alphabetical order
>>>    - add cmu_apm to clock bindings documentation
>>>    - sysreg bindings - remove superfluous `google,gs101-sysreg`
>>>    - watchdog bindings - Alphanumerical order, update gs201 comment
>>>    - samsung,pinctrl.yaml - add new "if:then:else:" to narrow for google SoC
>>>    - samsung,pinctrl-wakeup-interrupt.yaml - Alphanumerical order
>>>    - samsung,pinctrl- add google,gs101-wakeup-eint compatible
>>>    - clk-pll: fixup typos
>>>    - clk-gs101: fix kernel test robot warnings (add 2 new clocks,dividers,gate)
>>>    - clk-gs101: fix alphabetical order
>>>    - clk-gs101: cmu_apm: fixup typo and missing empty entry
>>>    - clk-gs101: cmu_misc: remove clocks that were being registerred twice
>>>    - pinctrl: filter sel: rename/reorder variables, add comment for FLTCON bitfield
>>>    - pinctrl: filter sel: avoid setting reserved bits by loop over FLTCON1 pins as well
>>>    - pinctrl: gs101: rename bank_type_6/7 structs to be more specific, split from filter
>>>    - watchdog: s3c2410_wdt: remove dev_info prints
>>>    - gs101.dtsi/oriole.dts: order by unit node, remove underscores from node name, blank lines
>>>      add SoC node, split dts and dtsi into separate patches, remove 'DVT' suffix
>>>    - gs101-oriole.dtso: Remove overlay until board_id is documented properly
>>>    - Add GS101_PIN_* macros to gs101-pinctrl.h instead of using Exynos ones
>>>    - gpio-keys: update linux,code to use input-event-code macros
>>>    - add dedicated gs101-uart compatible
>>>
>>> Peter Griffin (20):
>>>     dt-bindings: soc: samsung: exynos-pmu: Add gs101 compatible
>>>     dt-bindings: clock: Add Google gs101 clock management unit bindings
>>>     dt-bindings: soc: google: exynos-sysreg: add dedicated SYSREG
>>>       compatibles to GS101
>>>     dt-bindings: watchdog: Document Google gs101 & gs201 watchdog bindings
>>>     dt-bindings: arm: google: Add bindings for Google ARM platforms
>>>     dt-bindings: pinctrl: samsung: add google,gs101-pinctrl compatible
>>>     dt-bindings: pinctrl: samsung: add gs101-wakeup-eint compatible
>>>     dt-bindings: serial: samsung: Add google-gs101-uart compatible
>>>     clk: samsung: clk-pll: Add support for pll_{0516,0517,518}
>>>     clk: samsung: clk-gs101: Add cmu_top registers, plls, mux and gates
>>>     clk: samsung: clk-gs101: add CMU_APM support
>>>     clk: samsung: clk-gs101: Add support for CMU_MISC clock unit
>>>     pinctrl: samsung: Add filter selection support for alive banks
>>>     pinctrl: samsung: Add gs101 SoC pinctrl configuration
>>>     watchdog: s3c2410_wdt: Add support for Google tensor SoCs
>>>     tty: serial: samsung: Add gs101 compatible and SoC data
>>>     arm64: dts: google: Add initial Google gs101 SoC support
>>>     arm64: dts: google: Add initial Oriole/pixel 6 board support
>>>     arm64: defconfig: Enable Google Tensor SoC
>>>     MAINTAINERS: add entry for Google Tensor SoC
>>>
>>>    .../devicetree/bindings/arm/google.yaml       |   46 +
>>>    .../bindings/clock/google,gs101-clock.yaml    |  125 +
>>>    .../samsung,pinctrl-wakeup-interrupt.yaml     |    2 +
>>>    .../bindings/pinctrl/samsung,pinctrl.yaml     |   19 +
>>>    .../bindings/serial/samsung_uart.yaml         |    2 +
>>>    .../bindings/soc/samsung/exynos-pmu.yaml      |    2 +
>>>    .../soc/samsung/samsung,exynos-sysreg.yaml    |    6 +
>>>    .../bindings/watchdog/samsung-wdt.yaml        |   10 +-
>>>    MAINTAINERS                                   |   10 +
>>>    arch/arm64/Kconfig.platforms                  |    6 +
>>>    arch/arm64/boot/dts/Makefile                  |    1 +
>>>    arch/arm64/boot/dts/google/Makefile           |    4 +
>>>    arch/arm64/boot/dts/google/gs101-oriole.dts   |   79 +
>>>    arch/arm64/boot/dts/google/gs101-pinctrl.dtsi | 1275 ++++++++++
>>>    arch/arm64/boot/dts/google/gs101-pinctrl.h    |   32 +
>>>    arch/arm64/boot/dts/google/gs101.dtsi         |  503 ++++
>>>    arch/arm64/configs/defconfig                  |    1 +
>>>    drivers/clk/samsung/Kconfig                   |    9 +
>>>    drivers/clk/samsung/Makefile                  |    2 +
>>>    drivers/clk/samsung/clk-gs101.c               | 2164 +++++++++++++++++
>>>    drivers/clk/samsung/clk-pll.c                 |    9 +-
>>>    drivers/clk/samsung/clk-pll.h                 |    3 +
>>>    .../pinctrl/samsung/pinctrl-exynos-arm64.c    |  163 ++
>>>    drivers/pinctrl/samsung/pinctrl-exynos.c      |   84 +-
>>>    drivers/pinctrl/samsung/pinctrl-exynos.h      |   41 +
>>>    drivers/pinctrl/samsung/pinctrl-samsung.c     |    4 +
>>>    drivers/pinctrl/samsung/pinctrl-samsung.h     |   24 +
>>>    drivers/tty/serial/samsung_tty.c              |   12 +
>>>    drivers/watchdog/s3c2410_wdt.c                |  104 +-
>>>    include/dt-bindings/clock/google,gs101.h      |  232 ++
>>>    30 files changed, 4961 insertions(+), 13 deletions(-)
>>>    create mode 100644 Documentation/devicetree/bindings/arm/google.yaml
>>>    create mode 100644 Documentation/devicetree/bindings/clock/google,gs101-clock.yaml
>>>    create mode 100644 arch/arm64/boot/dts/google/Makefile
>>>    create mode 100644 arch/arm64/boot/dts/google/gs101-oriole.dts
>>>    create mode 100644 arch/arm64/boot/dts/google/gs101-pinctrl.dtsi
>>>    create mode 100644 arch/arm64/boot/dts/google/gs101-pinctrl.h
>>>    create mode 100644 arch/arm64/boot/dts/google/gs101.dtsi
>>>    create mode 100644 drivers/clk/samsung/clk-gs101.c
>>>    create mode 100644 include/dt-bindings/clock/google,gs101.h
>>>
- Maksym


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH v2 00/20] Add minimal Tensor/GS101 SoC support and Oriole/Pixel6 board

[Krzysztof Kozlowski]

On 03/11/2023 14:56, Maksym Holovach wrote:
> Hi Peter,
> 
> On 11/3/23 15:11, Peter Griffin wrote:
>> Hi Maksym,
>>
>> Thanks for your feedback.
>>
>> On Thu, 2 Nov 2023 at 22:32, Maksym Holovach
>> <maksym.holovach.an.2022@lpnu.ua> wrote:
>>> Hi, all
>>>
>>> I wanted to inquire about how do you all feel about calling this SoC by
>>> the Google "gs101" name.
>> Interesting question, I think calling it gs101 is the correct approach see
>> below for my rationale.
>>
>>> I believe the proper name for it should be the actual Samsung name,
>>> written in the silicon and reported in the Chip ID hardware: Exynos9845.
>>> This also touches the Tensor G2 (Exynos9855), Tensor G3 (Exynos9865),
>>> and possibly the "Tesla" SoCs.
>>>
>>> I do not think the Linux kernel should be a marketing material: it
>>> should reflect reality. The chip is almost 100% composed of Samsung
>>> Exynos IP blocks and should be called that way.
>> As you alluded to Tesla fsd and Axis artpec8 SoCs are also based on
>> Exynos designs and support upstream uses the axis,artpec8* or tesla,fsd*
>> compatibles.
>>
>> So using google,gs101 is consistent with the existing upstream naming
>> scheme, for customized ASICs that were based off a Exynos design. But
>> it also reflects the reality that this SoC is not a Exynos9845 as there is
>> also a lot of Google owned and other third party IP integrated that is not
>> found in Exynos9845.
> 
> A quick question: Do you imply Exynos9845 exists outside of the context 
> of Tensor G1? I used to believe Exynos9845 **is** Tensor G1.
> 
> Also, what kind of Google IP are you talking about? I believe only the 
> neural accelerator should be custom-ish.
> 
> Additionally, I believe it having or not having Google IP is irrelevant: 
> for example, the new Raspberry Pi 5 Broadcom SoC has a lot of 
> Raspberry's own IP, but it's still called Broadcom as it's the real 
> manufacturer and designer of the chip.

That's a good argument. Indeed BCM2712 contains "New Raspberry
Pi-developed ISP".
https://www.raspberrypi.com/documentation/computers/processors.html

There aren't many patches but GPU is still called brcm,2712.

For Tesla FSD, there was discussion and output was not very consisting.
First, the name itself was used for everything - SoC architecture, one
given SoC and eventually the board.
https://lore.kernel.org/all/5ab62673-8d46-ec1d-1c80-696421ab69ca@canonical.com/

Eventually the last part - board - was renamed to "Evaluation board",
but I don't know how true or real it is.

See also:
"I would argue that if this SoC shares the pinctrl, clock, spi, adc,
and timer implementation
with Exynos, we should consider it part of the Exynos family,"
https://lore.kernel.org/all/CAK8P3a31bCHNcNWrLX+QW+4RuK=DBpxLA_j5BFKxXxXKCT8PFQ@mail.gmail.com/

However it was also claimed:

"AFA architecture is concerns both Exynos and FSD has completely
different architecture (at least at HW level)."
https://lore.kernel.org/all/07ce01d8091e$9a6fd9c0$cf4f8d40$@samsung.com/

>> I guess the same is also true for `axis,artpec8` and `tesla,fsd` SoCs.
>> IMO the SoC compatible string should be uniquely identifying the actual
>> SoC, not a close relative.
>>
>> Regarding product_id you are correct this reads 0x09845000 but even
>> within Samsung Exynos family there are examples where the register
>> value does not match the SoC compatible. For example Exynos850 SoC
>> has a product ID value of "E3830". Where the Linux compatible is
>> matching the Samsung marketing name, not the internal/outdated name.
> 
> I did not know Exynos 850 is also not going under it's real name. 
> Ultimately, I believe all of those SoCs should go under their technical 
> name in the exynos/ directory.

The initial technical name does not exist outside of vendor sources and
part name. E.g. Winlink E850 board hardware manual calls it:
"Samsung Exynos 850, S5E3830"
and everywhere else Exynos 850 SoC is used.

If you start calling it Exynos 3830, only me and Sam (who mainlined it)
would know what is it. Everyone else, all users of kernel, would be
confused.

Therefore using well known final product name is for Exynos850 reasonable.

> 
> Another concern is that Google could in the future license other SoC: be 
> it Qualcomm, Nvidia or anything. If we put completely different hw under 
> google/ directory, does it really make sense? In that case, who'll 
> maintain the google/ directory? Exynos people? Qualcomm people if they 
> license it? Some other people?

That's indeed a problem. Future Tesla SoC might have just few pieces
similar to FSD. There would be no common SoC part, except the actual
Tesla IP.

Same for Google. Future GSXXX, if done by Qualcomm, will be absolutely
different than GS101 and the only common part would be the TPU (Tensor).

So now let's decide what is the common denominator:
1. Core SoC architecture, like buses, pinctrl, clocks, timers, serial,
and many IP blocks, which constitute 95% of Devicetree bindings and drivers,
2. The one, big piece made by Samsung's customer: TPU, NPU or whatever.

> 
> Then, I don't think Tensor G3 has a proper "GS" name, it goes by "Zuma" 
> in decompiled kernel modules as far as I see.
> 
> Finally, Tesla people already tried to submit drivers called by Tesla 
> name, but which basically copied the functionality of the Exynos 
> drivers. We would want to avoid that, ideally.
> 
> My opinion is that all the Tesla and Google SoCs should be in the 
> exynos/ directory, not only because they are basically Samsung Exynos, 
> but also because they don't really need a separate directory: neither 
> Google nor Tesla didn't neither manufacture or design those SoCs from 
> scratch. The only reason I can think of for them to have it in a 
> separate directory is maybe because Google and Tesla actually paid 
> Samsung money for the right to call Exynos "Google designed" SoCs, but I 
> believe the kernel should be left out of that.

For some reason, although I know which, Cc-list is here trimmed and
misses Alim...

So standard reply follow (it makes me really, really grumpy, because it
means you develop on some crazy old kernel or do not use tools which
automate the process):

Please use scripts/get_maintainers.pl to get a list of necessary people
and lists to CC (and consider --no-git-fallback argument). It might
happen, that command when run on an older kernel, gives you outdated
entries. Therefore please be sure you base your patches on recent Linux
kernel.

Best regards,
Krzysztof

Re: [PATCH v2 00/20] Add minimal Tensor/GS101 SoC support and Oriole/Pixel6 board

[Krzysztof Kozlowski]

On 03/11/2023 14:56, Maksym Holovach wrote:
> Hi Peter,
> 
> On 11/3/23 15:11, Peter Griffin wrote:
>> Hi Maksym,
>>
>> Thanks for your feedback.
>>
>> On Thu, 2 Nov 2023 at 22:32, Maksym Holovach
>> <maksym.holovach.an.2022@lpnu.ua> wrote:
>>> Hi, all
>>>
>>> I wanted to inquire about how do you all feel about calling this SoC by
>>> the Google "gs101" name.
>> Interesting question, I think calling it gs101 is the correct approach see
>> below for my rationale.
>>
>>> I believe the proper name for it should be the actual Samsung name,
>>> written in the silicon and reported in the Chip ID hardware: Exynos9845.
>>> This also touches the Tensor G2 (Exynos9855), Tensor G3 (Exynos9865),
>>> and possibly the "Tesla" SoCs.
>>>
>>> I do not think the Linux kernel should be a marketing material: it
>>> should reflect reality. The chip is almost 100% composed of Samsung
>>> Exynos IP blocks and should be called that way.
>> As you alluded to Tesla fsd and Axis artpec8 SoCs are also based on
>> Exynos designs and support upstream uses the axis,artpec8* or tesla,fsd*
>> compatibles.
>>
>> So using google,gs101 is consistent with the existing upstream naming
>> scheme, for customized ASICs that were based off a Exynos design. But
>> it also reflects the reality that this SoC is not a Exynos9845 as there is
>> also a lot of Google owned and other third party IP integrated that is not
>> found in Exynos9845.
> 
> A quick question: Do you imply Exynos9845 exists outside of the context 
> of Tensor G1? I used to believe Exynos9845 **is** Tensor G1.
> 
> Also, what kind of Google IP are you talking about? I believe only the 
> neural accelerator should be custom-ish.
> 
> Additionally, I believe it having or not having Google IP is irrelevant: 
> for example, the new Raspberry Pi 5 Broadcom SoC has a lot of 
> Raspberry's own IP, but it's still called Broadcom as it's the real 
> manufacturer and designer of the chip.

That's a good argument. Indeed BCM2712 contains "New Raspberry
Pi-developed ISP".
https://www.raspberrypi.com/documentation/computers/processors.html

There aren't many patches but GPU is still called brcm,2712.

For Tesla FSD, there was discussion and output was not very consisting.
First, the name itself was used for everything - SoC architecture, one
given SoC and eventually the board.
https://lore.kernel.org/all/5ab62673-8d46-ec1d-1c80-696421ab69ca@canonical.com/

Eventually the last part - board - was renamed to "Evaluation board",
but I don't know how true or real it is.

See also:
"I would argue that if this SoC shares the pinctrl, clock, spi, adc,
and timer implementation
with Exynos, we should consider it part of the Exynos family,"
https://lore.kernel.org/all/CAK8P3a31bCHNcNWrLX+QW+4RuK=DBpxLA_j5BFKxXxXKCT8PFQ@mail.gmail.com/

However it was also claimed:

"AFA architecture is concerns both Exynos and FSD has completely
different architecture (at least at HW level)."
https://lore.kernel.org/all/07ce01d8091e$9a6fd9c0$cf4f8d40$@samsung.com/

>> I guess the same is also true for `axis,artpec8` and `tesla,fsd` SoCs.
>> IMO the SoC compatible string should be uniquely identifying the actual
>> SoC, not a close relative.
>>
>> Regarding product_id you are correct this reads 0x09845000 but even
>> within Samsung Exynos family there are examples where the register
>> value does not match the SoC compatible. For example Exynos850 SoC
>> has a product ID value of "E3830". Where the Linux compatible is
>> matching the Samsung marketing name, not the internal/outdated name.
> 
> I did not know Exynos 850 is also not going under it's real name. 
> Ultimately, I believe all of those SoCs should go under their technical 
> name in the exynos/ directory.

The initial technical name does not exist outside of vendor sources and
part name. E.g. Winlink E850 board hardware manual calls it:
"Samsung Exynos 850, S5E3830"
and everywhere else Exynos 850 SoC is used.

If you start calling it Exynos 3830, only me and Sam (who mainlined it)
would know what is it. Everyone else, all users of kernel, would be
confused.

Therefore using well known final product name is for Exynos850 reasonable.

> 
> Another concern is that Google could in the future license other SoC: be 
> it Qualcomm, Nvidia or anything. If we put completely different hw under 
> google/ directory, does it really make sense? In that case, who'll 
> maintain the google/ directory? Exynos people? Qualcomm people if they 
> license it? Some other people?

That's indeed a problem. Future Tesla SoC might have just few pieces
similar to FSD. There would be no common SoC part, except the actual
Tesla IP.

Same for Google. Future GSXXX, if done by Qualcomm, will be absolutely
different than GS101 and the only common part would be the TPU (Tensor).

So now let's decide what is the common denominator:
1. Core SoC architecture, like buses, pinctrl, clocks, timers, serial,
and many IP blocks, which constitute 95% of Devicetree bindings and drivers,
2. The one, big piece made by Samsung's customer: TPU, NPU or whatever.

> 
> Then, I don't think Tensor G3 has a proper "GS" name, it goes by "Zuma" 
> in decompiled kernel modules as far as I see.
> 
> Finally, Tesla people already tried to submit drivers called by Tesla 
> name, but which basically copied the functionality of the Exynos 
> drivers. We would want to avoid that, ideally.
> 
> My opinion is that all the Tesla and Google SoCs should be in the 
> exynos/ directory, not only because they are basically Samsung Exynos, 
> but also because they don't really need a separate directory: neither 
> Google nor Tesla didn't neither manufacture or design those SoCs from 
> scratch. The only reason I can think of for them to have it in a 
> separate directory is maybe because Google and Tesla actually paid 
> Samsung money for the right to call Exynos "Google designed" SoCs, but I 
> believe the kernel should be left out of that.

For some reason, although I know which, Cc-list is here trimmed and
misses Alim...

So standard reply follow (it makes me really, really grumpy, because it
means you develop on some crazy old kernel or do not use tools which
automate the process):

Please use scripts/get_maintainers.pl to get a list of necessary people
and lists to CC (and consider --no-git-fallback argument). It might
happen, that command when run on an older kernel, gives you outdated
entries. Therefore please be sure you base your patches on recent Linux
kernel.

Best regards,
Krzysztof


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH v2 00/20] Add minimal Tensor/GS101 SoC support and Oriole/Pixel6 board

[William McVicker]

Hi Maksym, Krzysztof, Peter,

On 11/03/2023, Krzysztof Kozlowski wrote:
> On 03/11/2023 14:56, Maksym Holovach wrote:
> > Hi Peter,
> > 
> > On 11/3/23 15:11, Peter Griffin wrote:
> >> Hi Maksym,
> >>
> >> Thanks for your feedback.
> >>
> >> On Thu, 2 Nov 2023 at 22:32, Maksym Holovach
> >> <maksym.holovach.an.2022@lpnu.ua> wrote:
> >>> Hi, all
> >>>
> >>> I wanted to inquire about how do you all feel about calling this SoC by
> >>> the Google "gs101" name.
> >> Interesting question, I think calling it gs101 is the correct approach see
> >> below for my rationale.
> >>
> >>> I believe the proper name for it should be the actual Samsung name,
> >>> written in the silicon and reported in the Chip ID hardware: Exynos9845.
> >>> This also touches the Tensor G2 (Exynos9855), Tensor G3 (Exynos9865),
> >>> and possibly the "Tesla" SoCs.
> >>>
> >>> I do not think the Linux kernel should be a marketing material: it
> >>> should reflect reality. The chip is almost 100% composed of Samsung
> >>> Exynos IP blocks and should be called that way.
> >> As you alluded to Tesla fsd and Axis artpec8 SoCs are also based on
> >> Exynos designs and support upstream uses the axis,artpec8* or tesla,fsd*
> >> compatibles.
> >>
> >> So using google,gs101 is consistent with the existing upstream naming
> >> scheme, for customized ASICs that were based off a Exynos design. But
> >> it also reflects the reality that this SoC is not a Exynos9845 as there is
> >> also a lot of Google owned and other third party IP integrated that is not
> >> found in Exynos9845.
> > 
> > A quick question: Do you imply Exynos9845 exists outside of the context 
> > of Tensor G1? I used to believe Exynos9845 **is** Tensor G1.

Yes, the gs101 SoC is *not* equivalent to the Exynos9845. Similar to how Tesla
FSD licenses Exynos IP blocks, gs101 does not only comprise of Exynos IP
blocks. The final design is unique to Google and comprises of several different
vendor IP blocks (not only Exynos).

> > 
> > Also, what kind of Google IP are you talking about? I believe only the 
> > neural accelerator should be custom-ish.
> > 
> > Additionally, I believe it having or not having Google IP is irrelevant: 
> > for example, the new Raspberry Pi 5 Broadcom SoC has a lot of 
> > Raspberry's own IP, but it's still called Broadcom as it's the real 
> > manufacturer and designer of the chip.
> 
> That's a good argument. Indeed BCM2712 contains "New Raspberry
> Pi-developed ISP".
> https://www.raspberrypi.com/documentation/computers/processors.html
> 
> There aren't many patches but GPU is still called brcm,2712.
> 
> For Tesla FSD, there was discussion and output was not very consisting.
> First, the name itself was used for everything - SoC architecture, one
> given SoC and eventually the board.
> https://lore.kernel.org/all/5ab62673-8d46-ec1d-1c80-696421ab69ca@canonical.com/
> 
> Eventually the last part - board - was renamed to "Evaluation board",
> but I don't know how true or real it is.
> 
> See also:
> "I would argue that if this SoC shares the pinctrl, clock, spi, adc,
> and timer implementation
> with Exynos, we should consider it part of the Exynos family,"
> https://lore.kernel.org/all/CAK8P3a31bCHNcNWrLX+QW+4RuK=DBpxLA_j5BFKxXxXKCT8PFQ@mail.gmail.com/
> 
> However it was also claimed:
> 
> "AFA architecture is concerns both Exynos and FSD has completely
> different architecture (at least at HW level)."
> https://lore.kernel.org/all/07ce01d8091e$9a6fd9c0$cf4f8d40$@samsung.com/
> 
> >> I guess the same is also true for `axis,artpec8` and `tesla,fsd` SoCs.
> >> IMO the SoC compatible string should be uniquely identifying the actual
> >> SoC, not a close relative.
> >>
> >> Regarding product_id you are correct this reads 0x09845000 but even
> >> within Samsung Exynos family there are examples where the register
> >> value does not match the SoC compatible. For example Exynos850 SoC
> >> has a product ID value of "E3830". Where the Linux compatible is
> >> matching the Samsung marketing name, not the internal/outdated name.
> > 
> > I did not know Exynos 850 is also not going under it's real name. 
> > Ultimately, I believe all of those SoCs should go under their technical 
> > name in the exynos/ directory.
> 
> The initial technical name does not exist outside of vendor sources and
> part name. E.g. Winlink E850 board hardware manual calls it:
> "Samsung Exynos 850, S5E3830"
> and everywhere else Exynos 850 SoC is used.
> 
> If you start calling it Exynos 3830, only me and Sam (who mainlined it)
> would know what is it. Everyone else, all users of kernel, would be
> confused.
> 
> Therefore using well known final product name is for Exynos850 reasonable.

I agree with this. By using the final (well known) product SoC name -- gs101 --
other developers will be able to easily identify the particular SoC.

> 
> > 
> > Another concern is that Google could in the future license other SoC: be 
> > it Qualcomm, Nvidia or anything. If we put completely different hw under 
> > google/ directory, does it really make sense? In that case, who'll 
> > maintain the google/ directory? Exynos people? Qualcomm people if they 
> > license it? Some other people?

I don't understand why the architecture of the SoC would dictate which folder
to put the device tree files under. It makes more sense to group board DT files
together based on who distributes them. Having all the Pixel DT board files
together allows Google to create a single device tree binary per SoC coupled
with the set of device tree overlays per board variant (this is the dtbo.img)
to ship to all their devices. If you look at all the in-market Pixel devices
with Tensor SoCs, you will find that you could create one dtb (concatenate
gs101.dtb, gs201.dtb, and zuma.dtb) and one dtbo image for 10 devices which
significantly simplifies the maintenance, testing, and software distribution
for all 10 of those products.

> 
> That's indeed a problem. Future Tesla SoC might have just few pieces
> similar to FSD. There would be no common SoC part, except the actual
> Tesla IP.
> 
> Same for Google. Future GSXXX, if done by Qualcomm, will be absolutely
> different than GS101 and the only common part would be the TPU (Tensor).
> 
> So now let's decide what is the common denominator:
> 1. Core SoC architecture, like buses, pinctrl, clocks, timers, serial,
> and many IP blocks, which constitute 95% of Devicetree bindings and drivers,
> 2. The one, big piece made by Samsung's customer: TPU, NPU or whatever.

As mentioned above, I think this should be based on how the DTBs and DTBOs are
used and distributed. What is the benefit of adding the gs101 board files under
the exynos folder?

Thanks,
Will

> 
> > 
> > Then, I don't think Tensor G3 has a proper "GS" name, it goes by "Zuma" 
> > in decompiled kernel modules as far as I see.
> > 
> > Finally, Tesla people already tried to submit drivers called by Tesla 
> > name, but which basically copied the functionality of the Exynos 
> > drivers. We would want to avoid that, ideally.
> > 
> > My opinion is that all the Tesla and Google SoCs should be in the 
> > exynos/ directory, not only because they are basically Samsung Exynos, 
> > but also because they don't really need a separate directory: neither 
> > Google nor Tesla didn't neither manufacture or design those SoCs from 
> > scratch. The only reason I can think of for them to have it in a 
> > separate directory is maybe because Google and Tesla actually paid 
> > Samsung money for the right to call Exynos "Google designed" SoCs, but I 
> > believe the kernel should be left out of that.
> 
> For some reason, although I know which, Cc-list is here trimmed and
> misses Alim...
> 
> So standard reply follow (it makes me really, really grumpy, because it
> means you develop on some crazy old kernel or do not use tools which
> automate the process):
> 
> Please use scripts/get_maintainers.pl to get a list of necessary people
> and lists to CC (and consider --no-git-fallback argument). It might
> happen, that command when run on an older kernel, gives you outdated
> entries. Therefore please be sure you base your patches on recent Linux
> kernel.
> 
> Best regards,
> Krzysztof
> 

Re: [PATCH v2 00/20] Add minimal Tensor/GS101 SoC support and Oriole/Pixel6 board

[William McVicker]

Hi Maksym, Krzysztof, Peter,

On 11/03/2023, Krzysztof Kozlowski wrote:
> On 03/11/2023 14:56, Maksym Holovach wrote:
> > Hi Peter,
> > 
> > On 11/3/23 15:11, Peter Griffin wrote:
> >> Hi Maksym,
> >>
> >> Thanks for your feedback.
> >>
> >> On Thu, 2 Nov 2023 at 22:32, Maksym Holovach
> >> <maksym.holovach.an.2022@lpnu.ua> wrote:
> >>> Hi, all
> >>>
> >>> I wanted to inquire about how do you all feel about calling this SoC by
> >>> the Google "gs101" name.
> >> Interesting question, I think calling it gs101 is the correct approach see
> >> below for my rationale.
> >>
> >>> I believe the proper name for it should be the actual Samsung name,
> >>> written in the silicon and reported in the Chip ID hardware: Exynos9845.
> >>> This also touches the Tensor G2 (Exynos9855), Tensor G3 (Exynos9865),
> >>> and possibly the "Tesla" SoCs.
> >>>
> >>> I do not think the Linux kernel should be a marketing material: it
> >>> should reflect reality. The chip is almost 100% composed of Samsung
> >>> Exynos IP blocks and should be called that way.
> >> As you alluded to Tesla fsd and Axis artpec8 SoCs are also based on
> >> Exynos designs and support upstream uses the axis,artpec8* or tesla,fsd*
> >> compatibles.
> >>
> >> So using google,gs101 is consistent with the existing upstream naming
> >> scheme, for customized ASICs that were based off a Exynos design. But
> >> it also reflects the reality that this SoC is not a Exynos9845 as there is
> >> also a lot of Google owned and other third party IP integrated that is not
> >> found in Exynos9845.
> > 
> > A quick question: Do you imply Exynos9845 exists outside of the context 
> > of Tensor G1? I used to believe Exynos9845 **is** Tensor G1.

Yes, the gs101 SoC is *not* equivalent to the Exynos9845. Similar to how Tesla
FSD licenses Exynos IP blocks, gs101 does not only comprise of Exynos IP
blocks. The final design is unique to Google and comprises of several different
vendor IP blocks (not only Exynos).

> > 
> > Also, what kind of Google IP are you talking about? I believe only the 
> > neural accelerator should be custom-ish.
> > 
> > Additionally, I believe it having or not having Google IP is irrelevant: 
> > for example, the new Raspberry Pi 5 Broadcom SoC has a lot of 
> > Raspberry's own IP, but it's still called Broadcom as it's the real 
> > manufacturer and designer of the chip.
> 
> That's a good argument. Indeed BCM2712 contains "New Raspberry
> Pi-developed ISP".
> https://www.raspberrypi.com/documentation/computers/processors.html
> 
> There aren't many patches but GPU is still called brcm,2712.
> 
> For Tesla FSD, there was discussion and output was not very consisting.
> First, the name itself was used for everything - SoC architecture, one
> given SoC and eventually the board.
> https://lore.kernel.org/all/5ab62673-8d46-ec1d-1c80-696421ab69ca@canonical.com/
> 
> Eventually the last part - board - was renamed to "Evaluation board",
> but I don't know how true or real it is.
> 
> See also:
> "I would argue that if this SoC shares the pinctrl, clock, spi, adc,
> and timer implementation
> with Exynos, we should consider it part of the Exynos family,"
> https://lore.kernel.org/all/CAK8P3a31bCHNcNWrLX+QW+4RuK=DBpxLA_j5BFKxXxXKCT8PFQ@mail.gmail.com/
> 
> However it was also claimed:
> 
> "AFA architecture is concerns both Exynos and FSD has completely
> different architecture (at least at HW level)."
> https://lore.kernel.org/all/07ce01d8091e$9a6fd9c0$cf4f8d40$@samsung.com/
> 
> >> I guess the same is also true for `axis,artpec8` and `tesla,fsd` SoCs.
> >> IMO the SoC compatible string should be uniquely identifying the actual
> >> SoC, not a close relative.
> >>
> >> Regarding product_id you are correct this reads 0x09845000 but even
> >> within Samsung Exynos family there are examples where the register
> >> value does not match the SoC compatible. For example Exynos850 SoC
> >> has a product ID value of "E3830". Where the Linux compatible is
> >> matching the Samsung marketing name, not the internal/outdated name.
> > 
> > I did not know Exynos 850 is also not going under it's real name. 
> > Ultimately, I believe all of those SoCs should go under their technical 
> > name in the exynos/ directory.
> 
> The initial technical name does not exist outside of vendor sources and
> part name. E.g. Winlink E850 board hardware manual calls it:
> "Samsung Exynos 850, S5E3830"
> and everywhere else Exynos 850 SoC is used.
> 
> If you start calling it Exynos 3830, only me and Sam (who mainlined it)
> would know what is it. Everyone else, all users of kernel, would be
> confused.
> 
> Therefore using well known final product name is for Exynos850 reasonable.

I agree with this. By using the final (well known) product SoC name -- gs101 --
other developers will be able to easily identify the particular SoC.

> 
> > 
> > Another concern is that Google could in the future license other SoC: be 
> > it Qualcomm, Nvidia or anything. If we put completely different hw under 
> > google/ directory, does it really make sense? In that case, who'll 
> > maintain the google/ directory? Exynos people? Qualcomm people if they 
> > license it? Some other people?

I don't understand why the architecture of the SoC would dictate which folder
to put the device tree files under. It makes more sense to group board DT files
together based on who distributes them. Having all the Pixel DT board files
together allows Google to create a single device tree binary per SoC coupled
with the set of device tree overlays per board variant (this is the dtbo.img)
to ship to all their devices. If you look at all the in-market Pixel devices
with Tensor SoCs, you will find that you could create one dtb (concatenate
gs101.dtb, gs201.dtb, and zuma.dtb) and one dtbo image for 10 devices which
significantly simplifies the maintenance, testing, and software distribution
for all 10 of those products.

> 
> That's indeed a problem. Future Tesla SoC might have just few pieces
> similar to FSD. There would be no common SoC part, except the actual
> Tesla IP.
> 
> Same for Google. Future GSXXX, if done by Qualcomm, will be absolutely
> different than GS101 and the only common part would be the TPU (Tensor).
> 
> So now let's decide what is the common denominator:
> 1. Core SoC architecture, like buses, pinctrl, clocks, timers, serial,
> and many IP blocks, which constitute 95% of Devicetree bindings and drivers,
> 2. The one, big piece made by Samsung's customer: TPU, NPU or whatever.

As mentioned above, I think this should be based on how the DTBs and DTBOs are
used and distributed. What is the benefit of adding the gs101 board files under
the exynos folder?

Thanks,
Will

> 
> > 
> > Then, I don't think Tensor G3 has a proper "GS" name, it goes by "Zuma" 
> > in decompiled kernel modules as far as I see.
> > 
> > Finally, Tesla people already tried to submit drivers called by Tesla 
> > name, but which basically copied the functionality of the Exynos 
> > drivers. We would want to avoid that, ideally.
> > 
> > My opinion is that all the Tesla and Google SoCs should be in the 
> > exynos/ directory, not only because they are basically Samsung Exynos, 
> > but also because they don't really need a separate directory: neither 
> > Google nor Tesla didn't neither manufacture or design those SoCs from 
> > scratch. The only reason I can think of for them to have it in a 
> > separate directory is maybe because Google and Tesla actually paid 
> > Samsung money for the right to call Exynos "Google designed" SoCs, but I 
> > believe the kernel should be left out of that.
> 
> For some reason, although I know which, Cc-list is here trimmed and
> misses Alim...
> 
> So standard reply follow (it makes me really, really grumpy, because it
> means you develop on some crazy old kernel or do not use tools which
> automate the process):
> 
> Please use scripts/get_maintainers.pl to get a list of necessary people
> and lists to CC (and consider --no-git-fallback argument). It might
> happen, that command when run on an older kernel, gives you outdated
> entries. Therefore please be sure you base your patches on recent Linux
> kernel.
> 
> Best regards,
> Krzysztof
> 

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH v2 00/20] Add minimal Tensor/GS101 SoC support and Oriole/Pixel6 board

[William McVicker]

On 11/03/2023, William McVicker wrote:
> Hi Maksym, Krzysztof, Peter,
> 
> On 11/03/2023, Krzysztof Kozlowski wrote:
> > On 03/11/2023 14:56, Maksym Holovach wrote:
> > > Hi Peter,
> > > 
> > > On 11/3/23 15:11, Peter Griffin wrote:
> > >> Hi Maksym,
> > >>
> > >> Thanks for your feedback.
> > >>
> > >> On Thu, 2 Nov 2023 at 22:32, Maksym Holovach
> > >> <maksym.holovach.an.2022@lpnu.ua> wrote:
> > >>> Hi, all
> > >>>
> > >>> I wanted to inquire about how do you all feel about calling this SoC by
> > >>> the Google "gs101" name.
> > >> Interesting question, I think calling it gs101 is the correct approach see
> > >> below for my rationale.
> > >>
> > >>> I believe the proper name for it should be the actual Samsung name,
> > >>> written in the silicon and reported in the Chip ID hardware: Exynos9845.
> > >>> This also touches the Tensor G2 (Exynos9855), Tensor G3 (Exynos9865),
> > >>> and possibly the "Tesla" SoCs.
> > >>>
> > >>> I do not think the Linux kernel should be a marketing material: it
> > >>> should reflect reality. The chip is almost 100% composed of Samsung
> > >>> Exynos IP blocks and should be called that way.
> > >> As you alluded to Tesla fsd and Axis artpec8 SoCs are also based on
> > >> Exynos designs and support upstream uses the axis,artpec8* or tesla,fsd*
> > >> compatibles.
> > >>
> > >> So using google,gs101 is consistent with the existing upstream naming
> > >> scheme, for customized ASICs that were based off a Exynos design. But
> > >> it also reflects the reality that this SoC is not a Exynos9845 as there is
> > >> also a lot of Google owned and other third party IP integrated that is not
> > >> found in Exynos9845.
> > > 
> > > A quick question: Do you imply Exynos9845 exists outside of the context 
> > > of Tensor G1? I used to believe Exynos9845 **is** Tensor G1.
> 
> Yes, the gs101 SoC is *not* equivalent to the Exynos9845. Similar to how Tesla
> FSD licenses Exynos IP blocks, gs101 does not only comprise of Exynos IP
> blocks. The final design is unique to Google and comprises of several different
> vendor IP blocks (not only Exynos).

Sorry, I need to correct this after talking to more people. The Exynos9845 is
the name that Samsung LSI refers to as the gs101 SoC. However, it was made
exclusively for Google with Google-designed IP. Since this chip is exclusive to
the Pixel device line-up, it would make sense to use the well known name that
is used by Google in the Pixel factory kernel.

Regards,
Will

> 
> > > 
> > > Also, what kind of Google IP are you talking about? I believe only the 
> > > neural accelerator should be custom-ish.
> > > 
> > > Additionally, I believe it having or not having Google IP is irrelevant: 
> > > for example, the new Raspberry Pi 5 Broadcom SoC has a lot of 
> > > Raspberry's own IP, but it's still called Broadcom as it's the real 
> > > manufacturer and designer of the chip.
> > 
> > That's a good argument. Indeed BCM2712 contains "New Raspberry
> > Pi-developed ISP".
> > https://www.raspberrypi.com/documentation/computers/processors.html
> > 
> > There aren't many patches but GPU is still called brcm,2712.
> > 
> > For Tesla FSD, there was discussion and output was not very consisting.
> > First, the name itself was used for everything - SoC architecture, one
> > given SoC and eventually the board.
> > https://lore.kernel.org/all/5ab62673-8d46-ec1d-1c80-696421ab69ca@canonical.com/
> > 
> > Eventually the last part - board - was renamed to "Evaluation board",
> > but I don't know how true or real it is.
> > 
> > See also:
> > "I would argue that if this SoC shares the pinctrl, clock, spi, adc,
> > and timer implementation
> > with Exynos, we should consider it part of the Exynos family,"
> > https://lore.kernel.org/all/CAK8P3a31bCHNcNWrLX+QW+4RuK=DBpxLA_j5BFKxXxXKCT8PFQ@mail.gmail.com/
> > 
> > However it was also claimed:
> > 
> > "AFA architecture is concerns both Exynos and FSD has completely
> > different architecture (at least at HW level)."
> > https://lore.kernel.org/all/07ce01d8091e$9a6fd9c0$cf4f8d40$@samsung.com/
> > 
> > >> I guess the same is also true for `axis,artpec8` and `tesla,fsd` SoCs.
> > >> IMO the SoC compatible string should be uniquely identifying the actual
> > >> SoC, not a close relative.
> > >>
> > >> Regarding product_id you are correct this reads 0x09845000 but even
> > >> within Samsung Exynos family there are examples where the register
> > >> value does not match the SoC compatible. For example Exynos850 SoC
> > >> has a product ID value of "E3830". Where the Linux compatible is
> > >> matching the Samsung marketing name, not the internal/outdated name.
> > > 
> > > I did not know Exynos 850 is also not going under it's real name. 
> > > Ultimately, I believe all of those SoCs should go under their technical 
> > > name in the exynos/ directory.
> > 
> > The initial technical name does not exist outside of vendor sources and
> > part name. E.g. Winlink E850 board hardware manual calls it:
> > "Samsung Exynos 850, S5E3830"
> > and everywhere else Exynos 850 SoC is used.
> > 
> > If you start calling it Exynos 3830, only me and Sam (who mainlined it)
> > would know what is it. Everyone else, all users of kernel, would be
> > confused.
> > 
> > Therefore using well known final product name is for Exynos850 reasonable.
> 
> I agree with this. By using the final (well known) product SoC name -- gs101 --
> other developers will be able to easily identify the particular SoC.
> 
> > 
> > > 
> > > Another concern is that Google could in the future license other SoC: be 
> > > it Qualcomm, Nvidia or anything. If we put completely different hw under 
> > > google/ directory, does it really make sense? In that case, who'll 
> > > maintain the google/ directory? Exynos people? Qualcomm people if they 
> > > license it? Some other people?
> 
> I don't understand why the architecture of the SoC would dictate which folder
> to put the device tree files under. It makes more sense to group board DT files
> together based on who distributes them. Having all the Pixel DT board files
> together allows Google to create a single device tree binary per SoC coupled
> with the set of device tree overlays per board variant (this is the dtbo.img)
> to ship to all their devices. If you look at all the in-market Pixel devices
> with Tensor SoCs, you will find that you could create one dtb (concatenate
> gs101.dtb, gs201.dtb, and zuma.dtb) and one dtbo image for 10 devices which
> significantly simplifies the maintenance, testing, and software distribution
> for all 10 of those products.
> 
> > 
> > That's indeed a problem. Future Tesla SoC might have just few pieces
> > similar to FSD. There would be no common SoC part, except the actual
> > Tesla IP.
> > 
> > Same for Google. Future GSXXX, if done by Qualcomm, will be absolutely
> > different than GS101 and the only common part would be the TPU (Tensor).
> > 
> > So now let's decide what is the common denominator:
> > 1. Core SoC architecture, like buses, pinctrl, clocks, timers, serial,
> > and many IP blocks, which constitute 95% of Devicetree bindings and drivers,
> > 2. The one, big piece made by Samsung's customer: TPU, NPU or whatever.
> 
> As mentioned above, I think this should be based on how the DTBs and DTBOs are
> used and distributed. What is the benefit of adding the gs101 board files under
> the exynos folder?
> 
> Thanks,
> Will
> 
> > 
> > > 
> > > Then, I don't think Tensor G3 has a proper "GS" name, it goes by "Zuma" 
> > > in decompiled kernel modules as far as I see.
> > > 
> > > Finally, Tesla people already tried to submit drivers called by Tesla 
> > > name, but which basically copied the functionality of the Exynos 
> > > drivers. We would want to avoid that, ideally.
> > > 
> > > My opinion is that all the Tesla and Google SoCs should be in the 
> > > exynos/ directory, not only because they are basically Samsung Exynos, 
> > > but also because they don't really need a separate directory: neither 
> > > Google nor Tesla didn't neither manufacture or design those SoCs from 
> > > scratch. The only reason I can think of for them to have it in a 
> > > separate directory is maybe because Google and Tesla actually paid 
> > > Samsung money for the right to call Exynos "Google designed" SoCs, but I 
> > > believe the kernel should be left out of that.
> > 
> > For some reason, although I know which, Cc-list is here trimmed and
> > misses Alim...
> > 
> > So standard reply follow (it makes me really, really grumpy, because it
> > means you develop on some crazy old kernel or do not use tools which
> > automate the process):
> > 
> > Please use scripts/get_maintainers.pl to get a list of necessary people
> > and lists to CC (and consider --no-git-fallback argument). It might
> > happen, that command when run on an older kernel, gives you outdated
> > entries. Therefore please be sure you base your patches on recent Linux
> > kernel.
> > 
> > Best regards,
> > Krzysztof
> > 

Re: [PATCH v2 00/20] Add minimal Tensor/GS101 SoC support and Oriole/Pixel6 board

[William McVicker]

On 11/03/2023, William McVicker wrote:
> Hi Maksym, Krzysztof, Peter,
> 
> On 11/03/2023, Krzysztof Kozlowski wrote:
> > On 03/11/2023 14:56, Maksym Holovach wrote:
> > > Hi Peter,
> > > 
> > > On 11/3/23 15:11, Peter Griffin wrote:
> > >> Hi Maksym,
> > >>
> > >> Thanks for your feedback.
> > >>
> > >> On Thu, 2 Nov 2023 at 22:32, Maksym Holovach
> > >> <maksym.holovach.an.2022@lpnu.ua> wrote:
> > >>> Hi, all
> > >>>
> > >>> I wanted to inquire about how do you all feel about calling this SoC by
> > >>> the Google "gs101" name.
> > >> Interesting question, I think calling it gs101 is the correct approach see
> > >> below for my rationale.
> > >>
> > >>> I believe the proper name for it should be the actual Samsung name,
> > >>> written in the silicon and reported in the Chip ID hardware: Exynos9845.
> > >>> This also touches the Tensor G2 (Exynos9855), Tensor G3 (Exynos9865),
> > >>> and possibly the "Tesla" SoCs.
> > >>>
> > >>> I do not think the Linux kernel should be a marketing material: it
> > >>> should reflect reality. The chip is almost 100% composed of Samsung
> > >>> Exynos IP blocks and should be called that way.
> > >> As you alluded to Tesla fsd and Axis artpec8 SoCs are also based on
> > >> Exynos designs and support upstream uses the axis,artpec8* or tesla,fsd*
> > >> compatibles.
> > >>
> > >> So using google,gs101 is consistent with the existing upstream naming
> > >> scheme, for customized ASICs that were based off a Exynos design. But
> > >> it also reflects the reality that this SoC is not a Exynos9845 as there is
> > >> also a lot of Google owned and other third party IP integrated that is not
> > >> found in Exynos9845.
> > > 
> > > A quick question: Do you imply Exynos9845 exists outside of the context 
> > > of Tensor G1? I used to believe Exynos9845 **is** Tensor G1.
> 
> Yes, the gs101 SoC is *not* equivalent to the Exynos9845. Similar to how Tesla
> FSD licenses Exynos IP blocks, gs101 does not only comprise of Exynos IP
> blocks. The final design is unique to Google and comprises of several different
> vendor IP blocks (not only Exynos).

Sorry, I need to correct this after talking to more people. The Exynos9845 is
the name that Samsung LSI refers to as the gs101 SoC. However, it was made
exclusively for Google with Google-designed IP. Since this chip is exclusive to
the Pixel device line-up, it would make sense to use the well known name that
is used by Google in the Pixel factory kernel.

Regards,
Will

> 
> > > 
> > > Also, what kind of Google IP are you talking about? I believe only the 
> > > neural accelerator should be custom-ish.
> > > 
> > > Additionally, I believe it having or not having Google IP is irrelevant: 
> > > for example, the new Raspberry Pi 5 Broadcom SoC has a lot of 
> > > Raspberry's own IP, but it's still called Broadcom as it's the real 
> > > manufacturer and designer of the chip.
> > 
> > That's a good argument. Indeed BCM2712 contains "New Raspberry
> > Pi-developed ISP".
> > https://www.raspberrypi.com/documentation/computers/processors.html
> > 
> > There aren't many patches but GPU is still called brcm,2712.
> > 
> > For Tesla FSD, there was discussion and output was not very consisting.
> > First, the name itself was used for everything - SoC architecture, one
> > given SoC and eventually the board.
> > https://lore.kernel.org/all/5ab62673-8d46-ec1d-1c80-696421ab69ca@canonical.com/
> > 
> > Eventually the last part - board - was renamed to "Evaluation board",
> > but I don't know how true or real it is.
> > 
> > See also:
> > "I would argue that if this SoC shares the pinctrl, clock, spi, adc,
> > and timer implementation
> > with Exynos, we should consider it part of the Exynos family,"
> > https://lore.kernel.org/all/CAK8P3a31bCHNcNWrLX+QW+4RuK=DBpxLA_j5BFKxXxXKCT8PFQ@mail.gmail.com/
> > 
> > However it was also claimed:
> > 
> > "AFA architecture is concerns both Exynos and FSD has completely
> > different architecture (at least at HW level)."
> > https://lore.kernel.org/all/07ce01d8091e$9a6fd9c0$cf4f8d40$@samsung.com/
> > 
> > >> I guess the same is also true for `axis,artpec8` and `tesla,fsd` SoCs.
> > >> IMO the SoC compatible string should be uniquely identifying the actual
> > >> SoC, not a close relative.
> > >>
> > >> Regarding product_id you are correct this reads 0x09845000 but even
> > >> within Samsung Exynos family there are examples where the register
> > >> value does not match the SoC compatible. For example Exynos850 SoC
> > >> has a product ID value of "E3830". Where the Linux compatible is
> > >> matching the Samsung marketing name, not the internal/outdated name.
> > > 
> > > I did not know Exynos 850 is also not going under it's real name. 
> > > Ultimately, I believe all of those SoCs should go under their technical 
> > > name in the exynos/ directory.
> > 
> > The initial technical name does not exist outside of vendor sources and
> > part name. E.g. Winlink E850 board hardware manual calls it:
> > "Samsung Exynos 850, S5E3830"
> > and everywhere else Exynos 850 SoC is used.
> > 
> > If you start calling it Exynos 3830, only me and Sam (who mainlined it)
> > would know what is it. Everyone else, all users of kernel, would be
> > confused.
> > 
> > Therefore using well known final product name is for Exynos850 reasonable.
> 
> I agree with this. By using the final (well known) product SoC name -- gs101 --
> other developers will be able to easily identify the particular SoC.
> 
> > 
> > > 
> > > Another concern is that Google could in the future license other SoC: be 
> > > it Qualcomm, Nvidia or anything. If we put completely different hw under 
> > > google/ directory, does it really make sense? In that case, who'll 
> > > maintain the google/ directory? Exynos people? Qualcomm people if they 
> > > license it? Some other people?
> 
> I don't understand why the architecture of the SoC would dictate which folder
> to put the device tree files under. It makes more sense to group board DT files
> together based on who distributes them. Having all the Pixel DT board files
> together allows Google to create a single device tree binary per SoC coupled
> with the set of device tree overlays per board variant (this is the dtbo.img)
> to ship to all their devices. If you look at all the in-market Pixel devices
> with Tensor SoCs, you will find that you could create one dtb (concatenate
> gs101.dtb, gs201.dtb, and zuma.dtb) and one dtbo image for 10 devices which
> significantly simplifies the maintenance, testing, and software distribution
> for all 10 of those products.
> 
> > 
> > That's indeed a problem. Future Tesla SoC might have just few pieces
> > similar to FSD. There would be no common SoC part, except the actual
> > Tesla IP.
> > 
> > Same for Google. Future GSXXX, if done by Qualcomm, will be absolutely
> > different than GS101 and the only common part would be the TPU (Tensor).
> > 
> > So now let's decide what is the common denominator:
> > 1. Core SoC architecture, like buses, pinctrl, clocks, timers, serial,
> > and many IP blocks, which constitute 95% of Devicetree bindings and drivers,
> > 2. The one, big piece made by Samsung's customer: TPU, NPU or whatever.
> 
> As mentioned above, I think this should be based on how the DTBs and DTBOs are
> used and distributed. What is the benefit of adding the gs101 board files under
> the exynos folder?
> 
> Thanks,
> Will
> 
> > 
> > > 
> > > Then, I don't think Tensor G3 has a proper "GS" name, it goes by "Zuma" 
> > > in decompiled kernel modules as far as I see.
> > > 
> > > Finally, Tesla people already tried to submit drivers called by Tesla 
> > > name, but which basically copied the functionality of the Exynos 
> > > drivers. We would want to avoid that, ideally.
> > > 
> > > My opinion is that all the Tesla and Google SoCs should be in the 
> > > exynos/ directory, not only because they are basically Samsung Exynos, 
> > > but also because they don't really need a separate directory: neither 
> > > Google nor Tesla didn't neither manufacture or design those SoCs from 
> > > scratch. The only reason I can think of for them to have it in a 
> > > separate directory is maybe because Google and Tesla actually paid 
> > > Samsung money for the right to call Exynos "Google designed" SoCs, but I 
> > > believe the kernel should be left out of that.
> > 
> > For some reason, although I know which, Cc-list is here trimmed and
> > misses Alim...
> > 
> > So standard reply follow (it makes me really, really grumpy, because it
> > means you develop on some crazy old kernel or do not use tools which
> > automate the process):
> > 
> > Please use scripts/get_maintainers.pl to get a list of necessary people
> > and lists to CC (and consider --no-git-fallback argument). It might
> > happen, that command when run on an older kernel, gives you outdated
> > entries. Therefore please be sure you base your patches on recent Linux
> > kernel.
> > 
> > Best regards,
> > Krzysztof
> > 

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH v2 00/20] Add minimal Tensor/GS101 SoC support and Oriole/Pixel6 board

[Maksym Holovach]

Hi William,

On 11/3/23 19:36, William McVicker wrote:
> Hi Maksym, Krzysztof, Peter,
>
> On 11/03/2023, Krzysztof Kozlowski wrote:
>> On 03/11/2023 14:56, Maksym Holovach wrote:
>>> Hi Peter,
>>>
>>> On 11/3/23 15:11, Peter Griffin wrote:
>>>> Hi Maksym,
>>>>
>>>> Thanks for your feedback.
>>>>
>>>> On Thu, 2 Nov 2023 at 22:32, Maksym Holovach
>>>> <maksym.holovach.an.2022@lpnu.ua> wrote:
>>>>> Hi, all
>>>>>
>>>>> I wanted to inquire about how do you all feel about calling this SoC by
>>>>> the Google "gs101" name.
>>>> Interesting question, I think calling it gs101 is the correct approach see
>>>> below for my rationale.
>>>>
>>>>> I believe the proper name for it should be the actual Samsung name,
>>>>> written in the silicon and reported in the Chip ID hardware: Exynos9845.
>>>>> This also touches the Tensor G2 (Exynos9855), Tensor G3 (Exynos9865),
>>>>> and possibly the "Tesla" SoCs.
>>>>>
>>>>> I do not think the Linux kernel should be a marketing material: it
>>>>> should reflect reality. The chip is almost 100% composed of Samsung
>>>>> Exynos IP blocks and should be called that way.
>>>> As you alluded to Tesla fsd and Axis artpec8 SoCs are also based on
>>>> Exynos designs and support upstream uses the axis,artpec8* or tesla,fsd*
>>>> compatibles.
>>>>
>>>> So using google,gs101 is consistent with the existing upstream naming
>>>> scheme, for customized ASICs that were based off a Exynos design. But
>>>> it also reflects the reality that this SoC is not a Exynos9845 as there is
>>>> also a lot of Google owned and other third party IP integrated that is not
>>>> found in Exynos9845.
>>> A quick question: Do you imply Exynos9845 exists outside of the context
>>> of Tensor G1? I used to believe Exynos9845 **is** Tensor G1.
> Yes, the gs101 SoC is *not* equivalent to the Exynos9845. Similar to how Tesla
> FSD licenses Exynos IP blocks, gs101 does not only comprise of Exynos IP
> blocks. The final design is unique to Google and comprises of several different
> vendor IP blocks (not only Exynos).
>
>>> Also, what kind of Google IP are you talking about? I believe only the
>>> neural accelerator should be custom-ish.
>>>
>>> Additionally, I believe it having or not having Google IP is irrelevant:
>>> for example, the new Raspberry Pi 5 Broadcom SoC has a lot of
>>> Raspberry's own IP, but it's still called Broadcom as it's the real
>>> manufacturer and designer of the chip.
>> That's a good argument. Indeed BCM2712 contains "New Raspberry
>> Pi-developed ISP".
>> https://www.raspberrypi.com/documentation/computers/processors.html
>>
>> There aren't many patches but GPU is still called brcm,2712.
>>
>> For Tesla FSD, there was discussion and output was not very consisting.
>> First, the name itself was used for everything - SoC architecture, one
>> given SoC and eventually the board.
>> https://lore.kernel.org/all/5ab62673-8d46-ec1d-1c80-696421ab69ca@canonical.com/
>>
>> Eventually the last part - board - was renamed to "Evaluation board",
>> but I don't know how true or real it is.
>>
>> See also:
>> "I would argue that if this SoC shares the pinctrl, clock, spi, adc,
>> and timer implementation
>> with Exynos, we should consider it part of the Exynos family,"
>> https://lore.kernel.org/all/CAK8P3a31bCHNcNWrLX+QW+4RuK=DBpxLA_j5BFKxXxXKCT8PFQ@mail.gmail.com/
>>
>> However it was also claimed:
>>
>> "AFA architecture is concerns both Exynos and FSD has completely
>> different architecture (at least at HW level)."
>> https://lore.kernel.org/all/07ce01d8091e$9a6fd9c0$cf4f8d40$@samsung.com/
>>
>>>> I guess the same is also true for `axis,artpec8` and `tesla,fsd` SoCs.
>>>> IMO the SoC compatible string should be uniquely identifying the actual
>>>> SoC, not a close relative.
>>>>
>>>> Regarding product_id you are correct this reads 0x09845000 but even
>>>> within Samsung Exynos family there are examples where the register
>>>> value does not match the SoC compatible. For example Exynos850 SoC
>>>> has a product ID value of "E3830". Where the Linux compatible is
>>>> matching the Samsung marketing name, not the internal/outdated name.
>>> I did not know Exynos 850 is also not going under it's real name.
>>> Ultimately, I believe all of those SoCs should go under their technical
>>> name in the exynos/ directory.
>> The initial technical name does not exist outside of vendor sources and
>> part name. E.g. Winlink E850 board hardware manual calls it:
>> "Samsung Exynos 850, S5E3830"
>> and everywhere else Exynos 850 SoC is used.
>>
>> If you start calling it Exynos 3830, only me and Sam (who mainlined it)
>> would know what is it. Everyone else, all users of kernel, would be
>> confused.
>>
>> Therefore using well known final product name is for Exynos850 reasonable.
> I agree with this. By using the final (well known) product SoC name -- gs101 --
> other developers will be able to easily identify the particular SoC.
>
>>> Another concern is that Google could in the future license other SoC: be
>>> it Qualcomm, Nvidia or anything. If we put completely different hw under
>>> google/ directory, does it really make sense? In that case, who'll
>>> maintain the google/ directory? Exynos people? Qualcomm people if they
>>> license it? Some other people?
> I don't understand why the architecture of the SoC would dictate which folder
> to put the device tree files under. It makes more sense to group board DT files
> together based on who distributes them. Having all the Pixel DT board files
> together allows Google to create a single device tree binary per SoC coupled
> with the set of device tree overlays per board variant (this is the dtbo.img)
> to ship to all their devices. If you look at all the in-market Pixel devices
> with Tensor SoCs, you will find that you could create one dtb (concatenate
> gs101.dtb, gs201.dtb, and zuma.dtb) and one dtbo image for 10 devices which
> significantly simplifies the maintenance, testing, and software distribution
> for all 10 of those products.

How is that relevant?

I believe it is none of the kernel concerns, it's up to the user to do 
whatever with the built .dtb files.

Also I do not see an issue in having a file list of all the .dtbo files 
you might want.

>
>> That's indeed a problem. Future Tesla SoC might have just few pieces
>> similar to FSD. There would be no common SoC part, except the actual
>> Tesla IP.
>>
>> Same for Google. Future GSXXX, if done by Qualcomm, will be absolutely
>> different than GS101 and the only common part would be the TPU (Tensor).
>>
>> So now let's decide what is the common denominator:
>> 1. Core SoC architecture, like buses, pinctrl, clocks, timers, serial,
>> and many IP blocks, which constitute 95% of Devicetree bindings and drivers,
>> 2. The one, big piece made by Samsung's customer: TPU, NPU or whatever.
> As mentioned above, I think this should be based on how the DTBs and DTBOs are
> used and distributed. What is the benefit of adding the gs101 board files under
> the exynos folder?

One clear benefit would be the ease of maintaining all the SoC files at 
once. It's not that it is a benefit of having it in the Exynos folder, 
it's more like that there's no benefit in having a separate folder, and 
that also comes with some additional issues.

As I said earlier, it's pretty similar to the Raspberry Pi 5 example: It 
contains Raspberry's in-house IP, but it's still called properly 
Broadcom. The only difference is that Raspberry does not want its name 
on the chip, but Google does, despite it being just as custom as the 
Raspberry SoC is. The company's policy should not be a factor for this 
decision, in my opinion.

However as you've added, gs101 is the same thing as Exynos9845, so I 
believe there's no question that the Exynos name should be specified 
somewhere too, because this is what's literally wired in hardware, and 
not just a "well-known name that is used by Google in the Pixel factory 
kernel".

I agree though that just specifying the internal E9845 name could 
mislead some people, but GS101 is a similarly obscure name, and not even 
the real name of the hardware.

>
> Thanks,
> Will
>
>>> Then, I don't think Tensor G3 has a proper "GS" name, it goes by "Zuma"
>>> in decompiled kernel modules as far as I see.
>>>
>>> Finally, Tesla people already tried to submit drivers called by Tesla
>>> name, but which basically copied the functionality of the Exynos
>>> drivers. We would want to avoid that, ideally.
>>>
>>> My opinion is that all the Tesla and Google SoCs should be in the
>>> exynos/ directory, not only because they are basically Samsung Exynos,
>>> but also because they don't really need a separate directory: neither
>>> Google nor Tesla didn't neither manufacture or design those SoCs from
>>> scratch. The only reason I can think of for them to have it in a
>>> separate directory is maybe because Google and Tesla actually paid
>>> Samsung money for the right to call Exynos "Google designed" SoCs, but I
>>> believe the kernel should be left out of that.
>> For some reason, although I know which, Cc-list is here trimmed and
>> misses Alim...
>>
>> So standard reply follow (it makes me really, really grumpy, because it
>> means you develop on some crazy old kernel or do not use tools which
>> automate the process):
>>
>> Please use scripts/get_maintainers.pl to get a list of necessary people
>> and lists to CC (and consider --no-git-fallback argument). It might
>> happen, that command when run on an older kernel, gives you outdated
>> entries. Therefore please be sure you base your patches on recent Linux
>> kernel.
>>
>> Best regards,
>> Krzysztof
>>
Yours,

Maksym

Re: [PATCH v2 00/20] Add minimal Tensor/GS101 SoC support and Oriole/Pixel6 board

[Maksym Holovach]

Hi William,

On 11/3/23 19:36, William McVicker wrote:
> Hi Maksym, Krzysztof, Peter,
>
> On 11/03/2023, Krzysztof Kozlowski wrote:
>> On 03/11/2023 14:56, Maksym Holovach wrote:
>>> Hi Peter,
>>>
>>> On 11/3/23 15:11, Peter Griffin wrote:
>>>> Hi Maksym,
>>>>
>>>> Thanks for your feedback.
>>>>
>>>> On Thu, 2 Nov 2023 at 22:32, Maksym Holovach
>>>> <maksym.holovach.an.2022@lpnu.ua> wrote:
>>>>> Hi, all
>>>>>
>>>>> I wanted to inquire about how do you all feel about calling this SoC by
>>>>> the Google "gs101" name.
>>>> Interesting question, I think calling it gs101 is the correct approach see
>>>> below for my rationale.
>>>>
>>>>> I believe the proper name for it should be the actual Samsung name,
>>>>> written in the silicon and reported in the Chip ID hardware: Exynos9845.
>>>>> This also touches the Tensor G2 (Exynos9855), Tensor G3 (Exynos9865),
>>>>> and possibly the "Tesla" SoCs.
>>>>>
>>>>> I do not think the Linux kernel should be a marketing material: it
>>>>> should reflect reality. The chip is almost 100% composed of Samsung
>>>>> Exynos IP blocks and should be called that way.
>>>> As you alluded to Tesla fsd and Axis artpec8 SoCs are also based on
>>>> Exynos designs and support upstream uses the axis,artpec8* or tesla,fsd*
>>>> compatibles.
>>>>
>>>> So using google,gs101 is consistent with the existing upstream naming
>>>> scheme, for customized ASICs that were based off a Exynos design. But
>>>> it also reflects the reality that this SoC is not a Exynos9845 as there is
>>>> also a lot of Google owned and other third party IP integrated that is not
>>>> found in Exynos9845.
>>> A quick question: Do you imply Exynos9845 exists outside of the context
>>> of Tensor G1? I used to believe Exynos9845 **is** Tensor G1.
> Yes, the gs101 SoC is *not* equivalent to the Exynos9845. Similar to how Tesla
> FSD licenses Exynos IP blocks, gs101 does not only comprise of Exynos IP
> blocks. The final design is unique to Google and comprises of several different
> vendor IP blocks (not only Exynos).
>
>>> Also, what kind of Google IP are you talking about? I believe only the
>>> neural accelerator should be custom-ish.
>>>
>>> Additionally, I believe it having or not having Google IP is irrelevant:
>>> for example, the new Raspberry Pi 5 Broadcom SoC has a lot of
>>> Raspberry's own IP, but it's still called Broadcom as it's the real
>>> manufacturer and designer of the chip.
>> That's a good argument. Indeed BCM2712 contains "New Raspberry
>> Pi-developed ISP".
>> https://www.raspberrypi.com/documentation/computers/processors.html
>>
>> There aren't many patches but GPU is still called brcm,2712.
>>
>> For Tesla FSD, there was discussion and output was not very consisting.
>> First, the name itself was used for everything - SoC architecture, one
>> given SoC and eventually the board.
>> https://lore.kernel.org/all/5ab62673-8d46-ec1d-1c80-696421ab69ca@canonical.com/
>>
>> Eventually the last part - board - was renamed to "Evaluation board",
>> but I don't know how true or real it is.
>>
>> See also:
>> "I would argue that if this SoC shares the pinctrl, clock, spi, adc,
>> and timer implementation
>> with Exynos, we should consider it part of the Exynos family,"
>> https://lore.kernel.org/all/CAK8P3a31bCHNcNWrLX+QW+4RuK=DBpxLA_j5BFKxXxXKCT8PFQ@mail.gmail.com/
>>
>> However it was also claimed:
>>
>> "AFA architecture is concerns both Exynos and FSD has completely
>> different architecture (at least at HW level)."
>> https://lore.kernel.org/all/07ce01d8091e$9a6fd9c0$cf4f8d40$@samsung.com/
>>
>>>> I guess the same is also true for `axis,artpec8` and `tesla,fsd` SoCs.
>>>> IMO the SoC compatible string should be uniquely identifying the actual
>>>> SoC, not a close relative.
>>>>
>>>> Regarding product_id you are correct this reads 0x09845000 but even
>>>> within Samsung Exynos family there are examples where the register
>>>> value does not match the SoC compatible. For example Exynos850 SoC
>>>> has a product ID value of "E3830". Where the Linux compatible is
>>>> matching the Samsung marketing name, not the internal/outdated name.
>>> I did not know Exynos 850 is also not going under it's real name.
>>> Ultimately, I believe all of those SoCs should go under their technical
>>> name in the exynos/ directory.
>> The initial technical name does not exist outside of vendor sources and
>> part name. E.g. Winlink E850 board hardware manual calls it:
>> "Samsung Exynos 850, S5E3830"
>> and everywhere else Exynos 850 SoC is used.
>>
>> If you start calling it Exynos 3830, only me and Sam (who mainlined it)
>> would know what is it. Everyone else, all users of kernel, would be
>> confused.
>>
>> Therefore using well known final product name is for Exynos850 reasonable.
> I agree with this. By using the final (well known) product SoC name -- gs101 --
> other developers will be able to easily identify the particular SoC.
>
>>> Another concern is that Google could in the future license other SoC: be
>>> it Qualcomm, Nvidia or anything. If we put completely different hw under
>>> google/ directory, does it really make sense? In that case, who'll
>>> maintain the google/ directory? Exynos people? Qualcomm people if they
>>> license it? Some other people?
> I don't understand why the architecture of the SoC would dictate which folder
> to put the device tree files under. It makes more sense to group board DT files
> together based on who distributes them. Having all the Pixel DT board files
> together allows Google to create a single device tree binary per SoC coupled
> with the set of device tree overlays per board variant (this is the dtbo.img)
> to ship to all their devices. If you look at all the in-market Pixel devices
> with Tensor SoCs, you will find that you could create one dtb (concatenate
> gs101.dtb, gs201.dtb, and zuma.dtb) and one dtbo image for 10 devices which
> significantly simplifies the maintenance, testing, and software distribution
> for all 10 of those products.

How is that relevant?

I believe it is none of the kernel concerns, it's up to the user to do 
whatever with the built .dtb files.

Also I do not see an issue in having a file list of all the .dtbo files 
you might want.

>
>> That's indeed a problem. Future Tesla SoC might have just few pieces
>> similar to FSD. There would be no common SoC part, except the actual
>> Tesla IP.
>>
>> Same for Google. Future GSXXX, if done by Qualcomm, will be absolutely
>> different than GS101 and the only common part would be the TPU (Tensor).
>>
>> So now let's decide what is the common denominator:
>> 1. Core SoC architecture, like buses, pinctrl, clocks, timers, serial,
>> and many IP blocks, which constitute 95% of Devicetree bindings and drivers,
>> 2. The one, big piece made by Samsung's customer: TPU, NPU or whatever.
> As mentioned above, I think this should be based on how the DTBs and DTBOs are
> used and distributed. What is the benefit of adding the gs101 board files under
> the exynos folder?

One clear benefit would be the ease of maintaining all the SoC files at 
once. It's not that it is a benefit of having it in the Exynos folder, 
it's more like that there's no benefit in having a separate folder, and 
that also comes with some additional issues.

As I said earlier, it's pretty similar to the Raspberry Pi 5 example: It 
contains Raspberry's in-house IP, but it's still called properly 
Broadcom. The only difference is that Raspberry does not want its name 
on the chip, but Google does, despite it being just as custom as the 
Raspberry SoC is. The company's policy should not be a factor for this 
decision, in my opinion.

However as you've added, gs101 is the same thing as Exynos9845, so I 
believe there's no question that the Exynos name should be specified 
somewhere too, because this is what's literally wired in hardware, and 
not just a "well-known name that is used by Google in the Pixel factory 
kernel".

I agree though that just specifying the internal E9845 name could 
mislead some people, but GS101 is a similarly obscure name, and not even 
the real name of the hardware.

>
> Thanks,
> Will
>
>>> Then, I don't think Tensor G3 has a proper "GS" name, it goes by "Zuma"
>>> in decompiled kernel modules as far as I see.
>>>
>>> Finally, Tesla people already tried to submit drivers called by Tesla
>>> name, but which basically copied the functionality of the Exynos
>>> drivers. We would want to avoid that, ideally.
>>>
>>> My opinion is that all the Tesla and Google SoCs should be in the
>>> exynos/ directory, not only because they are basically Samsung Exynos,
>>> but also because they don't really need a separate directory: neither
>>> Google nor Tesla didn't neither manufacture or design those SoCs from
>>> scratch. The only reason I can think of for them to have it in a
>>> separate directory is maybe because Google and Tesla actually paid
>>> Samsung money for the right to call Exynos "Google designed" SoCs, but I
>>> believe the kernel should be left out of that.
>> For some reason, although I know which, Cc-list is here trimmed and
>> misses Alim...
>>
>> So standard reply follow (it makes me really, really grumpy, because it
>> means you develop on some crazy old kernel or do not use tools which
>> automate the process):
>>
>> Please use scripts/get_maintainers.pl to get a list of necessary people
>> and lists to CC (and consider --no-git-fallback argument). It might
>> happen, that command when run on an older kernel, gives you outdated
>> entries. Therefore please be sure you base your patches on recent Linux
>> kernel.
>>
>> Best regards,
>> Krzysztof
>>
Yours,

Maksym


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH v2 00/20] Add minimal Tensor/GS101 SoC support and Oriole/Pixel6 board

[Maksym Holovach]

I believe I misunderstood your point, and now that I'm reading it again 
I believe grouping device trees based on device manufacturer is 
definitely an interesting idea and it would definitely make sense for 
e.g. x86, where there's basically two big SoC vendors and all the DTBs 
for the motherboards in just those two folders would result in 
cluttering issues, however it is not currently done in arm64/boot/dts, 
where the subfolders are per-platform (exynos, qcom, mtk, tegra, ...) - 
with an exception of Tesla, which perhaps should be also corrected (also 
CONFIG_ARCH makes it clear what those directory names are actually meant 
to represent).

If you think the current approach should be changed, it should be 
changed for all device-trees, and the CONFIG_ARCH_* should be also 
renamed, but also we'd need to convince everyone that this approach is 
superior to others...

Maybe the solution to this is to have arch/arm64/boot/dts/exynos/google 
with Google's boards, and to have the SoC .dtsi files in 
arch/arm64/boot/dts/exynos, but I'm not sure.

Additionally, I believe using .dtbo files like that (per board variant) 
is not really expected, instead each board should have its own .dtb 
file, compiled from a board .dts file which includes the SoC .dtsi file 
but this is not up to me to judge...

On 11/4/23 01:05, Maksym Holovach wrote:
> Hi William,
>
> On 11/3/23 19:36, William McVicker wrote:
>> Hi Maksym, Krzysztof, Peter,
>>
>> On 11/03/2023, Krzysztof Kozlowski wrote:
>>> On 03/11/2023 14:56, Maksym Holovach wrote:
>>>> Hi Peter,
>>>>
>>>> On 11/3/23 15:11, Peter Griffin wrote:
>>>>> Hi Maksym,
>>>>>
>>>>> Thanks for your feedback.
>>>>>
>>>>> On Thu, 2 Nov 2023 at 22:32, Maksym Holovach
>>>>> <maksym.holovach.an.2022@lpnu.ua> wrote:
>>>>>> Hi, all
>>>>>>
>>>>>> I wanted to inquire about how do you all feel about calling this 
>>>>>> SoC by
>>>>>> the Google "gs101" name.
>>>>> Interesting question, I think calling it gs101 is the correct 
>>>>> approach see
>>>>> below for my rationale.
>>>>>
>>>>>> I believe the proper name for it should be the actual Samsung name,
>>>>>> written in the silicon and reported in the Chip ID hardware: 
>>>>>> Exynos9845.
>>>>>> This also touches the Tensor G2 (Exynos9855), Tensor G3 
>>>>>> (Exynos9865),
>>>>>> and possibly the "Tesla" SoCs.
>>>>>>
>>>>>> I do not think the Linux kernel should be a marketing material: it
>>>>>> should reflect reality. The chip is almost 100% composed of Samsung
>>>>>> Exynos IP blocks and should be called that way.
>>>>> As you alluded to Tesla fsd and Axis artpec8 SoCs are also based on
>>>>> Exynos designs and support upstream uses the axis,artpec8* or 
>>>>> tesla,fsd*
>>>>> compatibles.
>>>>>
>>>>> So using google,gs101 is consistent with the existing upstream naming
>>>>> scheme, for customized ASICs that were based off a Exynos design. But
>>>>> it also reflects the reality that this SoC is not a Exynos9845 as 
>>>>> there is
>>>>> also a lot of Google owned and other third party IP integrated 
>>>>> that is not
>>>>> found in Exynos9845.
>>>> A quick question: Do you imply Exynos9845 exists outside of the 
>>>> context
>>>> of Tensor G1? I used to believe Exynos9845 **is** Tensor G1.
>> Yes, the gs101 SoC is *not* equivalent to the Exynos9845. Similar to 
>> how Tesla
>> FSD licenses Exynos IP blocks, gs101 does not only comprise of Exynos IP
>> blocks. The final design is unique to Google and comprises of several 
>> different
>> vendor IP blocks (not only Exynos).
>>
>>>> Also, what kind of Google IP are you talking about? I believe only the
>>>> neural accelerator should be custom-ish.
>>>>
>>>> Additionally, I believe it having or not having Google IP is 
>>>> irrelevant:
>>>> for example, the new Raspberry Pi 5 Broadcom SoC has a lot of
>>>> Raspberry's own IP, but it's still called Broadcom as it's the real
>>>> manufacturer and designer of the chip.
>>> That's a good argument. Indeed BCM2712 contains "New Raspberry
>>> Pi-developed ISP".
>>> https://www.raspberrypi.com/documentation/computers/processors.html
>>>
>>> There aren't many patches but GPU is still called brcm,2712.
>>>
>>> For Tesla FSD, there was discussion and output was not very consisting.
>>> First, the name itself was used for everything - SoC architecture, one
>>> given SoC and eventually the board.
>>> https://lore.kernel.org/all/5ab62673-8d46-ec1d-1c80-696421ab69ca@canonical.com/ 
>>>
>>>
>>> Eventually the last part - board - was renamed to "Evaluation board",
>>> but I don't know how true or real it is.
>>>
>>> See also:
>>> "I would argue that if this SoC shares the pinctrl, clock, spi, adc,
>>> and timer implementation
>>> with Exynos, we should consider it part of the Exynos family,"
>>> https://lore.kernel.org/all/CAK8P3a31bCHNcNWrLX+QW+4RuK=DBpxLA_j5BFKxXxXKCT8PFQ@mail.gmail.com/ 
>>>
>>>
>>> However it was also claimed:
>>>
>>> "AFA architecture is concerns both Exynos and FSD has completely
>>> different architecture (at least at HW level)."
>>> https://lore.kernel.org/all/07ce01d8091e$9a6fd9c0$cf4f8d40$@samsung.com/ 
>>>
>>>
>>>>> I guess the same is also true for `axis,artpec8` and `tesla,fsd` 
>>>>> SoCs.
>>>>> IMO the SoC compatible string should be uniquely identifying the 
>>>>> actual
>>>>> SoC, not a close relative.
>>>>>
>>>>> Regarding product_id you are correct this reads 0x09845000 but even
>>>>> within Samsung Exynos family there are examples where the register
>>>>> value does not match the SoC compatible. For example Exynos850 SoC
>>>>> has a product ID value of "E3830". Where the Linux compatible is
>>>>> matching the Samsung marketing name, not the internal/outdated name.
>>>> I did not know Exynos 850 is also not going under it's real name.
>>>> Ultimately, I believe all of those SoCs should go under their 
>>>> technical
>>>> name in the exynos/ directory.
>>> The initial technical name does not exist outside of vendor sources and
>>> part name. E.g. Winlink E850 board hardware manual calls it:
>>> "Samsung Exynos 850, S5E3830"
>>> and everywhere else Exynos 850 SoC is used.
>>>
>>> If you start calling it Exynos 3830, only me and Sam (who mainlined it)
>>> would know what is it. Everyone else, all users of kernel, would be
>>> confused.
>>>
>>> Therefore using well known final product name is for Exynos850 
>>> reasonable.
>> I agree with this. By using the final (well known) product SoC name 
>> -- gs101 --
>> other developers will be able to easily identify the particular SoC.
>>
>>>> Another concern is that Google could in the future license other 
>>>> SoC: be
>>>> it Qualcomm, Nvidia or anything. If we put completely different hw 
>>>> under
>>>> google/ directory, does it really make sense? In that case, who'll
>>>> maintain the google/ directory? Exynos people? Qualcomm people if they
>>>> license it? Some other people?
>> I don't understand why the architecture of the SoC would dictate 
>> which folder
>> to put the device tree files under. It makes more sense to group 
>> board DT files
>> together based on who distributes them. Having all the Pixel DT board 
>> files
>> together allows Google to create a single device tree binary per SoC 
>> coupled
>> with the set of device tree overlays per board variant (this is the 
>> dtbo.img)
>> to ship to all their devices. If you look at all the in-market Pixel 
>> devices
>> with Tensor SoCs, you will find that you could create one dtb 
>> (concatenate
>> gs101.dtb, gs201.dtb, and zuma.dtb) and one dtbo image for 10 devices 
>> which
>> significantly simplifies the maintenance, testing, and software 
>> distribution
>> for all 10 of those products.
>
> How is that relevant?
>
> I believe it is none of the kernel concerns, it's up to the user to do 
> whatever with the built .dtb files.
>
> Also I do not see an issue in having a file list of all the .dtbo 
> files you might want.
>>
>>> That's indeed a problem. Future Tesla SoC might have just few pieces
>>> similar to FSD. There would be no common SoC part, except the actual
>>> Tesla IP.
>>>
>>> Same for Google. Future GSXXX, if done by Qualcomm, will be absolutely
>>> different than GS101 and the only common part would be the TPU 
>>> (Tensor).
>>>
>>> So now let's decide what is the common denominator:
>>> 1. Core SoC architecture, like buses, pinctrl, clocks, timers, serial,
>>> and many IP blocks, which constitute 95% of Devicetree bindings and 
>>> drivers,
>>> 2. The one, big piece made by Samsung's customer: TPU, NPU or whatever.
>> As mentioned above, I think this should be based on how the DTBs and 
>> DTBOs are
>> used and distributed. What is the benefit of adding the gs101 board 
>> files under
>> the exynos folder?
>
> One clear benefit would be the ease of maintaining all the SoC files 
> at once. It's not that it is a benefit of having it in the Exynos 
> folder, it's more like that there's no benefit in having a separate 
> folder, and that also comes with some additional issues.
>
> As I said earlier, it's pretty similar to the Raspberry Pi 5 example: 
> It contains Raspberry's in-house IP, but it's still called properly 
> Broadcom. The only difference is that Raspberry does not want its name 
> on the chip, but Google does, despite it being just as custom as the 
> Raspberry SoC is. The company's policy should not be a factor for this 
> decision, in my opinion.
>
> However as you've added, gs101 is the same thing as Exynos9845, so I 
> believe there's no question that the Exynos name should be specified 
> somewhere too, because this is what's literally wired in hardware, and 
> not just a "well-known name that is used by Google in the Pixel 
> factory kernel".
>
> I agree though that just specifying the internal E9845 name could 
> mislead some people, but GS101 is a similarly obscure name, and not 
> even the real name of the hardware.
>
>>
>> Thanks,
>> Will
>>
>>>> Then, I don't think Tensor G3 has a proper "GS" name, it goes by 
>>>> "Zuma"
>>>> in decompiled kernel modules as far as I see.
>>>>
>>>> Finally, Tesla people already tried to submit drivers called by Tesla
>>>> name, but which basically copied the functionality of the Exynos
>>>> drivers. We would want to avoid that, ideally.
>>>>
>>>> My opinion is that all the Tesla and Google SoCs should be in the
>>>> exynos/ directory, not only because they are basically Samsung Exynos,
>>>> but also because they don't really need a separate directory: neither
>>>> Google nor Tesla didn't neither manufacture or design those SoCs from
>>>> scratch. The only reason I can think of for them to have it in a
>>>> separate directory is maybe because Google and Tesla actually paid
>>>> Samsung money for the right to call Exynos "Google designed" SoCs, 
>>>> but I
>>>> believe the kernel should be left out of that.
>>> For some reason, although I know which, Cc-list is here trimmed and
>>> misses Alim...
>>>
>>> So standard reply follow (it makes me really, really grumpy, because it
>>> means you develop on some crazy old kernel or do not use tools which
>>> automate the process):
>>>
>>> Please use scripts/get_maintainers.pl to get a list of necessary people
>>> and lists to CC (and consider --no-git-fallback argument). It might
>>> happen, that command when run on an older kernel, gives you outdated
>>> entries. Therefore please be sure you base your patches on recent Linux
>>> kernel.
>>>
>>> Best regards,
>>> Krzysztof
>>>
> Yours,
>
> Maksym
>
Yours,

Maksym

Re: [PATCH v2 00/20] Add minimal Tensor/GS101 SoC support and Oriole/Pixel6 board

[Maksym Holovach]

I believe I misunderstood your point, and now that I'm reading it again 
I believe grouping device trees based on device manufacturer is 
definitely an interesting idea and it would definitely make sense for 
e.g. x86, where there's basically two big SoC vendors and all the DTBs 
for the motherboards in just those two folders would result in 
cluttering issues, however it is not currently done in arm64/boot/dts, 
where the subfolders are per-platform (exynos, qcom, mtk, tegra, ...) - 
with an exception of Tesla, which perhaps should be also corrected (also 
CONFIG_ARCH makes it clear what those directory names are actually meant 
to represent).

If you think the current approach should be changed, it should be 
changed for all device-trees, and the CONFIG_ARCH_* should be also 
renamed, but also we'd need to convince everyone that this approach is 
superior to others...

Maybe the solution to this is to have arch/arm64/boot/dts/exynos/google 
with Google's boards, and to have the SoC .dtsi files in 
arch/arm64/boot/dts/exynos, but I'm not sure.

Additionally, I believe using .dtbo files like that (per board variant) 
is not really expected, instead each board should have its own .dtb 
file, compiled from a board .dts file which includes the SoC .dtsi file 
but this is not up to me to judge...

On 11/4/23 01:05, Maksym Holovach wrote:
> Hi William,
>
> On 11/3/23 19:36, William McVicker wrote:
>> Hi Maksym, Krzysztof, Peter,
>>
>> On 11/03/2023, Krzysztof Kozlowski wrote:
>>> On 03/11/2023 14:56, Maksym Holovach wrote:
>>>> Hi Peter,
>>>>
>>>> On 11/3/23 15:11, Peter Griffin wrote:
>>>>> Hi Maksym,
>>>>>
>>>>> Thanks for your feedback.
>>>>>
>>>>> On Thu, 2 Nov 2023 at 22:32, Maksym Holovach
>>>>> <maksym.holovach.an.2022@lpnu.ua> wrote:
>>>>>> Hi, all
>>>>>>
>>>>>> I wanted to inquire about how do you all feel about calling this 
>>>>>> SoC by
>>>>>> the Google "gs101" name.
>>>>> Interesting question, I think calling it gs101 is the correct 
>>>>> approach see
>>>>> below for my rationale.
>>>>>
>>>>>> I believe the proper name for it should be the actual Samsung name,
>>>>>> written in the silicon and reported in the Chip ID hardware: 
>>>>>> Exynos9845.
>>>>>> This also touches the Tensor G2 (Exynos9855), Tensor G3 
>>>>>> (Exynos9865),
>>>>>> and possibly the "Tesla" SoCs.
>>>>>>
>>>>>> I do not think the Linux kernel should be a marketing material: it
>>>>>> should reflect reality. The chip is almost 100% composed of Samsung
>>>>>> Exynos IP blocks and should be called that way.
>>>>> As you alluded to Tesla fsd and Axis artpec8 SoCs are also based on
>>>>> Exynos designs and support upstream uses the axis,artpec8* or 
>>>>> tesla,fsd*
>>>>> compatibles.
>>>>>
>>>>> So using google,gs101 is consistent with the existing upstream naming
>>>>> scheme, for customized ASICs that were based off a Exynos design. But
>>>>> it also reflects the reality that this SoC is not a Exynos9845 as 
>>>>> there is
>>>>> also a lot of Google owned and other third party IP integrated 
>>>>> that is not
>>>>> found in Exynos9845.
>>>> A quick question: Do you imply Exynos9845 exists outside of the 
>>>> context
>>>> of Tensor G1? I used to believe Exynos9845 **is** Tensor G1.
>> Yes, the gs101 SoC is *not* equivalent to the Exynos9845. Similar to 
>> how Tesla
>> FSD licenses Exynos IP blocks, gs101 does not only comprise of Exynos IP
>> blocks. The final design is unique to Google and comprises of several 
>> different
>> vendor IP blocks (not only Exynos).
>>
>>>> Also, what kind of Google IP are you talking about? I believe only the
>>>> neural accelerator should be custom-ish.
>>>>
>>>> Additionally, I believe it having or not having Google IP is 
>>>> irrelevant:
>>>> for example, the new Raspberry Pi 5 Broadcom SoC has a lot of
>>>> Raspberry's own IP, but it's still called Broadcom as it's the real
>>>> manufacturer and designer of the chip.
>>> That's a good argument. Indeed BCM2712 contains "New Raspberry
>>> Pi-developed ISP".
>>> https://www.raspberrypi.com/documentation/computers/processors.html
>>>
>>> There aren't many patches but GPU is still called brcm,2712.
>>>
>>> For Tesla FSD, there was discussion and output was not very consisting.
>>> First, the name itself was used for everything - SoC architecture, one
>>> given SoC and eventually the board.
>>> https://lore.kernel.org/all/5ab62673-8d46-ec1d-1c80-696421ab69ca@canonical.com/ 
>>>
>>>
>>> Eventually the last part - board - was renamed to "Evaluation board",
>>> but I don't know how true or real it is.
>>>
>>> See also:
>>> "I would argue that if this SoC shares the pinctrl, clock, spi, adc,
>>> and timer implementation
>>> with Exynos, we should consider it part of the Exynos family,"
>>> https://lore.kernel.org/all/CAK8P3a31bCHNcNWrLX+QW+4RuK=DBpxLA_j5BFKxXxXKCT8PFQ@mail.gmail.com/ 
>>>
>>>
>>> However it was also claimed:
>>>
>>> "AFA architecture is concerns both Exynos and FSD has completely
>>> different architecture (at least at HW level)."
>>> https://lore.kernel.org/all/07ce01d8091e$9a6fd9c0$cf4f8d40$@samsung.com/ 
>>>
>>>
>>>>> I guess the same is also true for `axis,artpec8` and `tesla,fsd` 
>>>>> SoCs.
>>>>> IMO the SoC compatible string should be uniquely identifying the 
>>>>> actual
>>>>> SoC, not a close relative.
>>>>>
>>>>> Regarding product_id you are correct this reads 0x09845000 but even
>>>>> within Samsung Exynos family there are examples where the register
>>>>> value does not match the SoC compatible. For example Exynos850 SoC
>>>>> has a product ID value of "E3830". Where the Linux compatible is
>>>>> matching the Samsung marketing name, not the internal/outdated name.
>>>> I did not know Exynos 850 is also not going under it's real name.
>>>> Ultimately, I believe all of those SoCs should go under their 
>>>> technical
>>>> name in the exynos/ directory.
>>> The initial technical name does not exist outside of vendor sources and
>>> part name. E.g. Winlink E850 board hardware manual calls it:
>>> "Samsung Exynos 850, S5E3830"
>>> and everywhere else Exynos 850 SoC is used.
>>>
>>> If you start calling it Exynos 3830, only me and Sam (who mainlined it)
>>> would know what is it. Everyone else, all users of kernel, would be
>>> confused.
>>>
>>> Therefore using well known final product name is for Exynos850 
>>> reasonable.
>> I agree with this. By using the final (well known) product SoC name 
>> -- gs101 --
>> other developers will be able to easily identify the particular SoC.
>>
>>>> Another concern is that Google could in the future license other 
>>>> SoC: be
>>>> it Qualcomm, Nvidia or anything. If we put completely different hw 
>>>> under
>>>> google/ directory, does it really make sense? In that case, who'll
>>>> maintain the google/ directory? Exynos people? Qualcomm people if they
>>>> license it? Some other people?
>> I don't understand why the architecture of the SoC would dictate 
>> which folder
>> to put the device tree files under. It makes more sense to group 
>> board DT files
>> together based on who distributes them. Having all the Pixel DT board 
>> files
>> together allows Google to create a single device tree binary per SoC 
>> coupled
>> with the set of device tree overlays per board variant (this is the 
>> dtbo.img)
>> to ship to all their devices. If you look at all the in-market Pixel 
>> devices
>> with Tensor SoCs, you will find that you could create one dtb 
>> (concatenate
>> gs101.dtb, gs201.dtb, and zuma.dtb) and one dtbo image for 10 devices 
>> which
>> significantly simplifies the maintenance, testing, and software 
>> distribution
>> for all 10 of those products.
>
> How is that relevant?
>
> I believe it is none of the kernel concerns, it's up to the user to do 
> whatever with the built .dtb files.
>
> Also I do not see an issue in having a file list of all the .dtbo 
> files you might want.
>>
>>> That's indeed a problem. Future Tesla SoC might have just few pieces
>>> similar to FSD. There would be no common SoC part, except the actual
>>> Tesla IP.
>>>
>>> Same for Google. Future GSXXX, if done by Qualcomm, will be absolutely
>>> different than GS101 and the only common part would be the TPU 
>>> (Tensor).
>>>
>>> So now let's decide what is the common denominator:
>>> 1. Core SoC architecture, like buses, pinctrl, clocks, timers, serial,
>>> and many IP blocks, which constitute 95% of Devicetree bindings and 
>>> drivers,
>>> 2. The one, big piece made by Samsung's customer: TPU, NPU or whatever.
>> As mentioned above, I think this should be based on how the DTBs and 
>> DTBOs are
>> used and distributed. What is the benefit of adding the gs101 board 
>> files under
>> the exynos folder?
>
> One clear benefit would be the ease of maintaining all the SoC files 
> at once. It's not that it is a benefit of having it in the Exynos 
> folder, it's more like that there's no benefit in having a separate 
> folder, and that also comes with some additional issues.
>
> As I said earlier, it's pretty similar to the Raspberry Pi 5 example: 
> It contains Raspberry's in-house IP, but it's still called properly 
> Broadcom. The only difference is that Raspberry does not want its name 
> on the chip, but Google does, despite it being just as custom as the 
> Raspberry SoC is. The company's policy should not be a factor for this 
> decision, in my opinion.
>
> However as you've added, gs101 is the same thing as Exynos9845, so I 
> believe there's no question that the Exynos name should be specified 
> somewhere too, because this is what's literally wired in hardware, and 
> not just a "well-known name that is used by Google in the Pixel 
> factory kernel".
>
> I agree though that just specifying the internal E9845 name could 
> mislead some people, but GS101 is a similarly obscure name, and not 
> even the real name of the hardware.
>
>>
>> Thanks,
>> Will
>>
>>>> Then, I don't think Tensor G3 has a proper "GS" name, it goes by 
>>>> "Zuma"
>>>> in decompiled kernel modules as far as I see.
>>>>
>>>> Finally, Tesla people already tried to submit drivers called by Tesla
>>>> name, but which basically copied the functionality of the Exynos
>>>> drivers. We would want to avoid that, ideally.
>>>>
>>>> My opinion is that all the Tesla and Google SoCs should be in the
>>>> exynos/ directory, not only because they are basically Samsung Exynos,
>>>> but also because they don't really need a separate directory: neither
>>>> Google nor Tesla didn't neither manufacture or design those SoCs from
>>>> scratch. The only reason I can think of for them to have it in a
>>>> separate directory is maybe because Google and Tesla actually paid
>>>> Samsung money for the right to call Exynos "Google designed" SoCs, 
>>>> but I
>>>> believe the kernel should be left out of that.
>>> For some reason, although I know which, Cc-list is here trimmed and
>>> misses Alim...
>>>
>>> So standard reply follow (it makes me really, really grumpy, because it
>>> means you develop on some crazy old kernel or do not use tools which
>>> automate the process):
>>>
>>> Please use scripts/get_maintainers.pl to get a list of necessary people
>>> and lists to CC (and consider --no-git-fallback argument). It might
>>> happen, that command when run on an older kernel, gives you outdated
>>> entries. Therefore please be sure you base your patches on recent Linux
>>> kernel.
>>>
>>> Best regards,
>>> Krzysztof
>>>
> Yours,
>
> Maksym
>
Yours,

Maksym


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

RE: [PATCH v2 00/20] Add minimal Tensor/GS101 SoC support and Oriole/Pixel6 board

[Alim Akhtar]

Hi Krzysztof

Thanks for CCing me to the tread, I have not yet looked into the patches (as those never landed in my inbox).

> -----Original Message-----
> From: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
> Sent: Friday, November 3, 2023 8:19 PM
> To: Maksym Holovach <maksym.holovach.an.2022@lpnu.ua>; Peter Griffin
> <peter.griffin@linaro.org>
> Cc: robh+dt@kernel.org; krzysztof.kozlowski+dt@linaro.org;
> mturquette@baylibre.com; conor+dt@kernel.org; sboyd@kernel.org;
> tomasz.figa@gmail.com; s.nawrocki@samsung.com; linus.walleij@linaro.org;
> wim@linux-watchdog.org; linux@roeck-us.net; catalin.marinas@arm.com;
> will@kernel.org; arnd@arndb.de; olof@lixom.net; cw00.choi@samsung.com;
> tudor.ambarus@linaro.org; andre.draszik@linaro.org;
> semen.protsenko@linaro.org; saravanak@google.com;
> willmcvicker@google.com; soc@kernel.org; devicetree@vger.kernel.org;
> linux-arm-kernel@lists.infradead.org; linux-samsung-soc@vger.kernel.org;
> linux-clk@vger.kernel.org; linux-gpio@vger.kernel.org; linux-
> watchdog@vger.kernel.org; kernel-team@android.com; linux-
> serial@vger.kernel.org; Alim Akhtar <alim.akhtar@samsung.com>
> Subject: Re: [PATCH v2 00/20] Add minimal Tensor/GS101 SoC support and
> Oriole/Pixel6 board
> 
> On 03/11/2023 14:56, Maksym Holovach wrote:
> > Hi Peter,
> >
> > On 11/3/23 15:11, Peter Griffin wrote:
> >> Hi Maksym,
> >>
> >> Thanks for your feedback.
> >>
> >> On Thu, 2 Nov 2023 at 22:32, Maksym Holovach
> >> <maksym.holovach.an.2022@lpnu.ua> wrote:
> >>> Hi, all
> >>>
> >>> I wanted to inquire about how do you all feel about calling this SoC
> >>> by the Google "gs101" name.
> >> Interesting question, I think calling it gs101 is the correct
> >> approach see below for my rationale.
> >>
> >>> I believe the proper name for it should be the actual Samsung name,
> >>> written in the silicon and reported in the Chip ID hardware: Exynos9845.
> >>> This also touches the Tensor G2 (Exynos9855), Tensor G3
> >>> (Exynos9865), and possibly the "Tesla" SoCs.
> >>>
> >>> I do not think the Linux kernel should be a marketing material: it
> >>> should reflect reality. The chip is almost 100% composed of Samsung
> >>> Exynos IP blocks and should be called that way.
> >> As you alluded to Tesla fsd and Axis artpec8 SoCs are also based on
> >> Exynos designs and support upstream uses the axis,artpec8* or
> >> tesla,fsd* compatibles.
> >>
> >> So using google,gs101 is consistent with the existing upstream naming
> >> scheme, for customized ASICs that were based off a Exynos design. But
> >> it also reflects the reality that this SoC is not a Exynos9845 as
> >> there is also a lot of Google owned and other third party IP
> >> integrated that is not found in Exynos9845.
> >
> > A quick question: Do you imply Exynos9845 exists outside of the
> > context of Tensor G1? I used to believe Exynos9845 **is** Tensor G1.
> >
> > Also, what kind of Google IP are you talking about? I believe only the
> > neural accelerator should be custom-ish.
> >
> > Additionally, I believe it having or not having Google IP is irrelevant:
> > for example, the new Raspberry Pi 5 Broadcom SoC has a lot of
> > Raspberry's own IP, but it's still called Broadcom as it's the real
> > manufacturer and designer of the chip.
> 
> That's a good argument. Indeed BCM2712 contains "New Raspberry Pi-
> developed ISP".
> https://www.raspberrypi.com/documentation/computers/processors.html
> 
> There aren't many patches but GPU is still called brcm,2712.
> 
> For Tesla FSD, there was discussion and output was not very consisting.
> First, the name itself was used for everything - SoC architecture, one given
> SoC and eventually the board.
> https://lore.kernel.org/all/5ab62673-8d46-ec1d-1c80-
> 696421ab69ca@canonical.com/
> 
> Eventually the last part - board - was renamed to "Evaluation board", but I
> don't know how true or real it is.
> 
> See also:
> "I would argue that if this SoC shares the pinctrl, clock, spi, adc, and timer
> implementation with Exynos, we should consider it part of the Exynos
> family,"
> https://lore.kernel.org/all/CAK8P3a31bCHNcNWrLX+QW+4RuK=DBpxLA_j5B
> FKxXxXKCT8PFQ@mail.gmail.com/
> 
> However it was also claimed:
> 
> "AFA architecture is concerns both Exynos and FSD has completely different
> architecture (at least at HW level)."
> https://lore.kernel.org/all/07ce01d8091e$9a6fd9c0$cf4f8d40$@samsung.co
> m/
> 
Yes it is, IMO SoC belongs to a “vendor”. Just because it uses some common IPs,
does not make it belong to the some base family (in this case Exynos).
I have being working on Exynos since Exynos4 days
(and most of the Exynos series you have also worked on) and many more “vendor” specific SoC, like FSD etc.
And you know, it is not the IPs which differentiates SoC but it is SoC micro architecture which differentiate various SoC and
hence should be considered as different SoC.

> >> I guess the same is also true for `axis,artpec8` and `tesla,fsd` SoCs.
> >> IMO the SoC compatible string should be uniquely identifying the
> >> actual SoC, not a close relative.
> >>
> >> Regarding product_id you are correct this reads 0x09845000 but even
> >> within Samsung Exynos family there are examples where the register
> >> value does not match the SoC compatible. For example Exynos850 SoC
> >> has a product ID value of "E3830". Where the Linux compatible is
> >> matching the Samsung marketing name, not the internal/outdated name.
> >
> > I did not know Exynos 850 is also not going under it's real name.
> > Ultimately, I believe all of those SoCs should go under their
> > technical name in the exynos/ directory.
> 
> The initial technical name does not exist outside of vendor sources and part
> name. E.g. Winlink E850 board hardware manual calls it:
> "Samsung Exynos 850, S5E3830"
> and everywhere else Exynos 850 SoC is used.
> 
> If you start calling it Exynos 3830, only me and Sam (who mainlined it) would
> know what is it. Everyone else, all users of kernel, would be confused.
> 
> Therefore using well known final product name is for Exynos850 reasonable.
> 
You are right, the final product name should be used, which is, in case of FSD is FDS [1] and may be same is true for GS101 (I am not sure about GS101 though).
[1] https://www.autopilotreview.com/tesla-custom-ai-chips-hardware-3/

> >
> > Another concern is that Google could in the future license other SoC:
> > be it Qualcomm, Nvidia or anything. If we put completely different hw
> > under google/ directory, does it really make sense? In that case,
> > who'll maintain the google/ directory? Exynos people? Qualcomm people
> > if they license it? Some other people?
> 
> That's indeed a problem. Future Tesla SoC might have just few pieces similar
> to FSD. There would be no common SoC part, except the actual Tesla IP.
> 
> Same for Google. Future GSXXX, if done by Qualcomm, will be absolutely
> different than GS101 and the only common part would be the TPU (Tensor).
> 
> So now let's decide what is the common denominator:
> 1. Core SoC architecture, like buses, pinctrl, clocks, timers, serial, and many IP
> blocks, which constitute 95% of Devicetree bindings and drivers, 2. The one,
> big piece made by Samsung's customer: TPU, NPU or whatever.
> 
Just to keep things simple, IMO it should belong to "vendor" 
as they are the one who has or knows the current and future uses/plans for SoC/SoCs.
Because an IP can be sourced from many/any IP vendors. 

AFA maintenance is concerns, people who is/are doing upstreaming does have an entry in the MAINTAINERS list for the SoC.
  
> >
> > Then, I don't think Tensor G3 has a proper "GS" name, it goes by "Zuma"
> > in decompiled kernel modules as far as I see.
> >
> > Finally, Tesla people already tried to submit drivers called by Tesla
> > name, but which basically copied the functionality of the Exynos
> > drivers. We would want to avoid that, ideally.
> >
> > My opinion is that all the Tesla and Google SoCs should be in the
> > exynos/ directory, not only because they are basically Samsung Exynos,
> > but also because they don't really need a separate directory: neither
> > Google nor Tesla didn't neither manufacture or design those SoCs from
> > scratch. The only reason I can think of for them to have it in a
> > separate directory is maybe because Google and Tesla actually paid
> > Samsung money for the right to call Exynos "Google designed" SoCs, but
> > I believe the kernel should be left out of that.
> 
> For some reason, although I know which, Cc-list is here trimmed and misses
> Alim...
> 
Thanks Again.

> So standard reply follow (it makes me really, really grumpy, because it means
> you develop on some crazy old kernel or do not use tools which automate
> the process):
> 
> Please use scripts/get_maintainers.pl to get a list of necessary people and
> lists to CC (and consider --no-git-fallback argument). It might happen, that
> command when run on an older kernel, gives you outdated entries.
> Therefore please be sure you base your patches on recent Linux kernel.
> 
> Best regards,
> Krzysztof

RE: [PATCH v2 00/20] Add minimal Tensor/GS101 SoC support and Oriole/Pixel6 board

[Alim Akhtar]

Hi Krzysztof

Thanks for CCing me to the tread, I have not yet looked into the patches (as those never landed in my inbox).

> -----Original Message-----
> From: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
> Sent: Friday, November 3, 2023 8:19 PM
> To: Maksym Holovach <maksym.holovach.an.2022@lpnu.ua>; Peter Griffin
> <peter.griffin@linaro.org>
> Cc: robh+dt@kernel.org; krzysztof.kozlowski+dt@linaro.org;
> mturquette@baylibre.com; conor+dt@kernel.org; sboyd@kernel.org;
> tomasz.figa@gmail.com; s.nawrocki@samsung.com; linus.walleij@linaro.org;
> wim@linux-watchdog.org; linux@roeck-us.net; catalin.marinas@arm.com;
> will@kernel.org; arnd@arndb.de; olof@lixom.net; cw00.choi@samsung.com;
> tudor.ambarus@linaro.org; andre.draszik@linaro.org;
> semen.protsenko@linaro.org; saravanak@google.com;
> willmcvicker@google.com; soc@kernel.org; devicetree@vger.kernel.org;
> linux-arm-kernel@lists.infradead.org; linux-samsung-soc@vger.kernel.org;
> linux-clk@vger.kernel.org; linux-gpio@vger.kernel.org; linux-
> watchdog@vger.kernel.org; kernel-team@android.com; linux-
> serial@vger.kernel.org; Alim Akhtar <alim.akhtar@samsung.com>
> Subject: Re: [PATCH v2 00/20] Add minimal Tensor/GS101 SoC support and
> Oriole/Pixel6 board
> 
> On 03/11/2023 14:56, Maksym Holovach wrote:
> > Hi Peter,
> >
> > On 11/3/23 15:11, Peter Griffin wrote:
> >> Hi Maksym,
> >>
> >> Thanks for your feedback.
> >>
> >> On Thu, 2 Nov 2023 at 22:32, Maksym Holovach
> >> <maksym.holovach.an.2022@lpnu.ua> wrote:
> >>> Hi, all
> >>>
> >>> I wanted to inquire about how do you all feel about calling this SoC
> >>> by the Google "gs101" name.
> >> Interesting question, I think calling it gs101 is the correct
> >> approach see below for my rationale.
> >>
> >>> I believe the proper name for it should be the actual Samsung name,
> >>> written in the silicon and reported in the Chip ID hardware: Exynos9845.
> >>> This also touches the Tensor G2 (Exynos9855), Tensor G3
> >>> (Exynos9865), and possibly the "Tesla" SoCs.
> >>>
> >>> I do not think the Linux kernel should be a marketing material: it
> >>> should reflect reality. The chip is almost 100% composed of Samsung
> >>> Exynos IP blocks and should be called that way.
> >> As you alluded to Tesla fsd and Axis artpec8 SoCs are also based on
> >> Exynos designs and support upstream uses the axis,artpec8* or
> >> tesla,fsd* compatibles.
> >>
> >> So using google,gs101 is consistent with the existing upstream naming
> >> scheme, for customized ASICs that were based off a Exynos design. But
> >> it also reflects the reality that this SoC is not a Exynos9845 as
> >> there is also a lot of Google owned and other third party IP
> >> integrated that is not found in Exynos9845.
> >
> > A quick question: Do you imply Exynos9845 exists outside of the
> > context of Tensor G1? I used to believe Exynos9845 **is** Tensor G1.
> >
> > Also, what kind of Google IP are you talking about? I believe only the
> > neural accelerator should be custom-ish.
> >
> > Additionally, I believe it having or not having Google IP is irrelevant:
> > for example, the new Raspberry Pi 5 Broadcom SoC has a lot of
> > Raspberry's own IP, but it's still called Broadcom as it's the real
> > manufacturer and designer of the chip.
> 
> That's a good argument. Indeed BCM2712 contains "New Raspberry Pi-
> developed ISP".
> https://www.raspberrypi.com/documentation/computers/processors.html
> 
> There aren't many patches but GPU is still called brcm,2712.
> 
> For Tesla FSD, there was discussion and output was not very consisting.
> First, the name itself was used for everything - SoC architecture, one given
> SoC and eventually the board.
> https://lore.kernel.org/all/5ab62673-8d46-ec1d-1c80-
> 696421ab69ca@canonical.com/
> 
> Eventually the last part - board - was renamed to "Evaluation board", but I
> don't know how true or real it is.
> 
> See also:
> "I would argue that if this SoC shares the pinctrl, clock, spi, adc, and timer
> implementation with Exynos, we should consider it part of the Exynos
> family,"
> https://lore.kernel.org/all/CAK8P3a31bCHNcNWrLX+QW+4RuK=DBpxLA_j5B
> FKxXxXKCT8PFQ@mail.gmail.com/
> 
> However it was also claimed:
> 
> "AFA architecture is concerns both Exynos and FSD has completely different
> architecture (at least at HW level)."
> https://lore.kernel.org/all/07ce01d8091e$9a6fd9c0$cf4f8d40$@samsung.co
> m/
> 
Yes it is, IMO SoC belongs to a “vendor”. Just because it uses some common IPs,
does not make it belong to the some base family (in this case Exynos).
I have being working on Exynos since Exynos4 days
(and most of the Exynos series you have also worked on) and many more “vendor” specific SoC, like FSD etc.
And you know, it is not the IPs which differentiates SoC but it is SoC micro architecture which differentiate various SoC and
hence should be considered as different SoC.

> >> I guess the same is also true for `axis,artpec8` and `tesla,fsd` SoCs.
> >> IMO the SoC compatible string should be uniquely identifying the
> >> actual SoC, not a close relative.
> >>
> >> Regarding product_id you are correct this reads 0x09845000 but even
> >> within Samsung Exynos family there are examples where the register
> >> value does not match the SoC compatible. For example Exynos850 SoC
> >> has a product ID value of "E3830". Where the Linux compatible is
> >> matching the Samsung marketing name, not the internal/outdated name.
> >
> > I did not know Exynos 850 is also not going under it's real name.
> > Ultimately, I believe all of those SoCs should go under their
> > technical name in the exynos/ directory.
> 
> The initial technical name does not exist outside of vendor sources and part
> name. E.g. Winlink E850 board hardware manual calls it:
> "Samsung Exynos 850, S5E3830"
> and everywhere else Exynos 850 SoC is used.
> 
> If you start calling it Exynos 3830, only me and Sam (who mainlined it) would
> know what is it. Everyone else, all users of kernel, would be confused.
> 
> Therefore using well known final product name is for Exynos850 reasonable.
> 
You are right, the final product name should be used, which is, in case of FSD is FDS [1] and may be same is true for GS101 (I am not sure about GS101 though).
[1] https://www.autopilotreview.com/tesla-custom-ai-chips-hardware-3/

> >
> > Another concern is that Google could in the future license other SoC:
> > be it Qualcomm, Nvidia or anything. If we put completely different hw
> > under google/ directory, does it really make sense? In that case,
> > who'll maintain the google/ directory? Exynos people? Qualcomm people
> > if they license it? Some other people?
> 
> That's indeed a problem. Future Tesla SoC might have just few pieces similar
> to FSD. There would be no common SoC part, except the actual Tesla IP.
> 
> Same for Google. Future GSXXX, if done by Qualcomm, will be absolutely
> different than GS101 and the only common part would be the TPU (Tensor).
> 
> So now let's decide what is the common denominator:
> 1. Core SoC architecture, like buses, pinctrl, clocks, timers, serial, and many IP
> blocks, which constitute 95% of Devicetree bindings and drivers, 2. The one,
> big piece made by Samsung's customer: TPU, NPU or whatever.
> 
Just to keep things simple, IMO it should belong to "vendor" 
as they are the one who has or knows the current and future uses/plans for SoC/SoCs.
Because an IP can be sourced from many/any IP vendors. 

AFA maintenance is concerns, people who is/are doing upstreaming does have an entry in the MAINTAINERS list for the SoC.
  
> >
> > Then, I don't think Tensor G3 has a proper "GS" name, it goes by "Zuma"
> > in decompiled kernel modules as far as I see.
> >
> > Finally, Tesla people already tried to submit drivers called by Tesla
> > name, but which basically copied the functionality of the Exynos
> > drivers. We would want to avoid that, ideally.
> >
> > My opinion is that all the Tesla and Google SoCs should be in the
> > exynos/ directory, not only because they are basically Samsung Exynos,
> > but also because they don't really need a separate directory: neither
> > Google nor Tesla didn't neither manufacture or design those SoCs from
> > scratch. The only reason I can think of for them to have it in a
> > separate directory is maybe because Google and Tesla actually paid
> > Samsung money for the right to call Exynos "Google designed" SoCs, but
> > I believe the kernel should be left out of that.
> 
> For some reason, although I know which, Cc-list is here trimmed and misses
> Alim...
> 
Thanks Again.

> So standard reply follow (it makes me really, really grumpy, because it means
> you develop on some crazy old kernel or do not use tools which automate
> the process):
> 
> Please use scripts/get_maintainers.pl to get a list of necessary people and
> lists to CC (and consider --no-git-fallback argument). It might happen, that
> command when run on an older kernel, gives you outdated entries.
> Therefore please be sure you base your patches on recent Linux kernel.
> 
> Best regards,
> Krzysztof




_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH v2 00/20] Add minimal Tensor/GS101 SoC support and Oriole/Pixel6 board

[Krzysztof Kozlowski]

On 03/11/2023 18:36, William McVicker wrote:

>>
>> That's indeed a problem. Future Tesla SoC might have just few pieces
>> similar to FSD. There would be no common SoC part, except the actual
>> Tesla IP.
>>
>> Same for Google. Future GSXXX, if done by Qualcomm, will be absolutely
>> different than GS101 and the only common part would be the TPU (Tensor).
>>
>> So now let's decide what is the common denominator:
>> 1. Core SoC architecture, like buses, pinctrl, clocks, timers, serial,
>> and many IP blocks, which constitute 95% of Devicetree bindings and drivers,
>> 2. The one, big piece made by Samsung's customer: TPU, NPU or whatever.
> 
> As mentioned above, I think this should be based on how the DTBs and DTBOs are
> used and distributed.

None of existing platforms do it. Nowhere. All chromebooks are split per
SoC, not "how DTBs should be used and distributed". There is no google,
no Chromebook directory. None of Samsung phones have it. No
Samsung-phone directory. None of Google phones have Pixel directory.

You are now trying to introduce completely new rule, not existing in any
upstream platform.


> What is the benefit of adding the gs101 board files under
> the exynos folder?

To make it easier for us to maintain. You won't be maintaining any of
these platforms. None of Google folks contributed patches or maintained
any of these platforms so far, so it is up to upstream community to
decide what is the most convenience way to maintain the kernel sources.

Best regards,
Krzysztof

Re: [PATCH v2 00/20] Add minimal Tensor/GS101 SoC support and Oriole/Pixel6 board

[Krzysztof Kozlowski]

On 03/11/2023 18:36, William McVicker wrote:

>>
>> That's indeed a problem. Future Tesla SoC might have just few pieces
>> similar to FSD. There would be no common SoC part, except the actual
>> Tesla IP.
>>
>> Same for Google. Future GSXXX, if done by Qualcomm, will be absolutely
>> different than GS101 and the only common part would be the TPU (Tensor).
>>
>> So now let's decide what is the common denominator:
>> 1. Core SoC architecture, like buses, pinctrl, clocks, timers, serial,
>> and many IP blocks, which constitute 95% of Devicetree bindings and drivers,
>> 2. The one, big piece made by Samsung's customer: TPU, NPU or whatever.
> 
> As mentioned above, I think this should be based on how the DTBs and DTBOs are
> used and distributed.

None of existing platforms do it. Nowhere. All chromebooks are split per
SoC, not "how DTBs should be used and distributed". There is no google,
no Chromebook directory. None of Samsung phones have it. No
Samsung-phone directory. None of Google phones have Pixel directory.

You are now trying to introduce completely new rule, not existing in any
upstream platform.


> What is the benefit of adding the gs101 board files under
> the exynos folder?

To make it easier for us to maintain. You won't be maintaining any of
these platforms. None of Google folks contributed patches or maintained
any of these platforms so far, so it is up to upstream community to
decide what is the most convenience way to maintain the kernel sources.

Best regards,
Krzysztof


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH v2 00/20] Add minimal Tensor/GS101 SoC support and Oriole/Pixel6 board

[Greg KH]

On Sun, Nov 05, 2023 at 01:52:22PM +0100, Krzysztof Kozlowski wrote:
> On 03/11/2023 18:36, William McVicker wrote:
> 
> >>
> >> That's indeed a problem. Future Tesla SoC might have just few pieces
> >> similar to FSD. There would be no common SoC part, except the actual
> >> Tesla IP.
> >>
> >> Same for Google. Future GSXXX, if done by Qualcomm, will be absolutely
> >> different than GS101 and the only common part would be the TPU (Tensor).
> >>
> >> So now let's decide what is the common denominator:
> >> 1. Core SoC architecture, like buses, pinctrl, clocks, timers, serial,
> >> and many IP blocks, which constitute 95% of Devicetree bindings and drivers,
> >> 2. The one, big piece made by Samsung's customer: TPU, NPU or whatever.
> > 
> > As mentioned above, I think this should be based on how the DTBs and DTBOs are
> > used and distributed.
> 
> None of existing platforms do it. Nowhere. All chromebooks are split per
> SoC, not "how DTBs should be used and distributed". There is no google,
> no Chromebook directory. None of Samsung phones have it. No
> Samsung-phone directory. None of Google phones have Pixel directory.

but for code we have:
	drivers/patform/chrome/
	drivers/firmware/google/
	drivers/net/ethernet/google/

don't know if that matters or not, but thought I would mention it...

thanks,

greg k-h

Re: [PATCH v2 00/20] Add minimal Tensor/GS101 SoC support and Oriole/Pixel6 board

[Greg KH]

On Sun, Nov 05, 2023 at 01:52:22PM +0100, Krzysztof Kozlowski wrote:
> On 03/11/2023 18:36, William McVicker wrote:
> 
> >>
> >> That's indeed a problem. Future Tesla SoC might have just few pieces
> >> similar to FSD. There would be no common SoC part, except the actual
> >> Tesla IP.
> >>
> >> Same for Google. Future GSXXX, if done by Qualcomm, will be absolutely
> >> different than GS101 and the only common part would be the TPU (Tensor).
> >>
> >> So now let's decide what is the common denominator:
> >> 1. Core SoC architecture, like buses, pinctrl, clocks, timers, serial,
> >> and many IP blocks, which constitute 95% of Devicetree bindings and drivers,
> >> 2. The one, big piece made by Samsung's customer: TPU, NPU or whatever.
> > 
> > As mentioned above, I think this should be based on how the DTBs and DTBOs are
> > used and distributed.
> 
> None of existing platforms do it. Nowhere. All chromebooks are split per
> SoC, not "how DTBs should be used and distributed". There is no google,
> no Chromebook directory. None of Samsung phones have it. No
> Samsung-phone directory. None of Google phones have Pixel directory.

but for code we have:
	drivers/patform/chrome/
	drivers/firmware/google/
	drivers/net/ethernet/google/

don't know if that matters or not, but thought I would mention it...

thanks,

greg k-h

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH v2 00/20] Add minimal Tensor/GS101 SoC support and Oriole/Pixel6 board

[Krzysztof Kozlowski]

On 05/11/2023 14:08, Greg KH wrote:
> On Sun, Nov 05, 2023 at 01:52:22PM +0100, Krzysztof Kozlowski wrote:
>> On 03/11/2023 18:36, William McVicker wrote:
>>
>>>>
>>>> That's indeed a problem. Future Tesla SoC might have just few pieces
>>>> similar to FSD. There would be no common SoC part, except the actual
>>>> Tesla IP.
>>>>
>>>> Same for Google. Future GSXXX, if done by Qualcomm, will be absolutely
>>>> different than GS101 and the only common part would be the TPU (Tensor).
>>>>
>>>> So now let's decide what is the common denominator:
>>>> 1. Core SoC architecture, like buses, pinctrl, clocks, timers, serial,
>>>> and many IP blocks, which constitute 95% of Devicetree bindings and drivers,
>>>> 2. The one, big piece made by Samsung's customer: TPU, NPU or whatever.
>>>
>>> As mentioned above, I think this should be based on how the DTBs and DTBOs are
>>> used and distributed.
>>
>> None of existing platforms do it. Nowhere. All chromebooks are split per
>> SoC, not "how DTBs should be used and distributed". There is no google,
>> no Chromebook directory. None of Samsung phones have it. No
>> Samsung-phone directory. None of Google phones have Pixel directory.
> 
> but for code we have:
> 	drivers/patform/chrome/
> 	drivers/firmware/google/
> 	drivers/net/ethernet/google/
> 
> don't know if that matters or not, but thought I would mention it...

Yes, for the drivers for the similar hardware we have it. We have
drivers for Chromebook's Embedded Controller - let's put it in one
place, so that maintenance and review will be easier.

Now for DTS, the common hardware is not "Samsung phones", but "Samsung
SoC". We organize it like:
1. Samsung phones with Samsung SoC -> arm64/dts/samsung
2. Samsung phones with Qualcomm SoC -> arm64/dts/qcom

because the main common part is the SoC, not the rest of the phone.
There is no reviewer or maintainer for Samsung phones. There is no need
for such. No benefits, almost not many common parts except some touchscreen.

Why Google Pixel suddenly should be exception from the way we handle DTS
of all ARM64 platforms?

Best regards,
Krzysztof

Re: [PATCH v2 00/20] Add minimal Tensor/GS101 SoC support and Oriole/Pixel6 board

[Krzysztof Kozlowski]

On 05/11/2023 14:08, Greg KH wrote:
> On Sun, Nov 05, 2023 at 01:52:22PM +0100, Krzysztof Kozlowski wrote:
>> On 03/11/2023 18:36, William McVicker wrote:
>>
>>>>
>>>> That's indeed a problem. Future Tesla SoC might have just few pieces
>>>> similar to FSD. There would be no common SoC part, except the actual
>>>> Tesla IP.
>>>>
>>>> Same for Google. Future GSXXX, if done by Qualcomm, will be absolutely
>>>> different than GS101 and the only common part would be the TPU (Tensor).
>>>>
>>>> So now let's decide what is the common denominator:
>>>> 1. Core SoC architecture, like buses, pinctrl, clocks, timers, serial,
>>>> and many IP blocks, which constitute 95% of Devicetree bindings and drivers,
>>>> 2. The one, big piece made by Samsung's customer: TPU, NPU or whatever.
>>>
>>> As mentioned above, I think this should be based on how the DTBs and DTBOs are
>>> used and distributed.
>>
>> None of existing platforms do it. Nowhere. All chromebooks are split per
>> SoC, not "how DTBs should be used and distributed". There is no google,
>> no Chromebook directory. None of Samsung phones have it. No
>> Samsung-phone directory. None of Google phones have Pixel directory.
> 
> but for code we have:
> 	drivers/patform/chrome/
> 	drivers/firmware/google/
> 	drivers/net/ethernet/google/
> 
> don't know if that matters or not, but thought I would mention it...

Yes, for the drivers for the similar hardware we have it. We have
drivers for Chromebook's Embedded Controller - let's put it in one
place, so that maintenance and review will be easier.

Now for DTS, the common hardware is not "Samsung phones", but "Samsung
SoC". We organize it like:
1. Samsung phones with Samsung SoC -> arm64/dts/samsung
2. Samsung phones with Qualcomm SoC -> arm64/dts/qcom

because the main common part is the SoC, not the rest of the phone.
There is no reviewer or maintainer for Samsung phones. There is no need
for such. No benefits, almost not many common parts except some touchscreen.

Why Google Pixel suddenly should be exception from the way we handle DTS
of all ARM64 platforms?

Best regards,
Krzysztof


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH v2 00/20] Add minimal Tensor/GS101 SoC support and Oriole/Pixel6 board

[Peter Griffin]

Hi Maksym,

On Fri, 3 Nov 2023 at 13:56, Maksym Holovach
<maksym.holovach.an.2022@lpnu.ua> wrote:
>
> Hi Peter,
>
> On 11/3/23 15:11, Peter Griffin wrote:
> > Hi Maksym,
> >
> > Thanks for your feedback.
> >
> > On Thu, 2 Nov 2023 at 22:32, Maksym Holovach
> > <maksym.holovach.an.2022@lpnu.ua> wrote:
> >> Hi, all
> >>
> >> I wanted to inquire about how do you all feel about calling this SoC by
> >> the Google "gs101" name.
> > Interesting question, I think calling it gs101 is the correct approach see
> > below for my rationale.
> >
> >> I believe the proper name for it should be the actual Samsung name,
> >> written in the silicon and reported in the Chip ID hardware: Exynos9845.
> >> This also touches the Tensor G2 (Exynos9855), Tensor G3 (Exynos9865),
> >> and possibly the "Tesla" SoCs.

Also Exynos850 as I pointed out previously. I think that is the wrong approach
and very confusing. This SoC is not commonly known by anyone as
Exynos9845.

The same as the Exynos850 isn't known by anyone apart from Samsung folks
as Exynos 3830, and the tesla fsd SoC isn't known by whatever internal Samsung
name that presumably had.

Maybe Alim can comment what tesla fsd SoC has in the product id register.

> >>
> >> I do not think the Linux kernel should be a marketing material: it
> >> should reflect reality. The chip is almost 100% composed of Samsung
> >> Exynos IP blocks and should be called that way.

Where does this 'almost 100%' number come from? Are you measuring the die
area here or something else?

> > As you alluded to Tesla fsd and Axis artpec8 SoCs are also based on
> > Exynos designs and support upstream uses the axis,artpec8* or tesla,fsd*
> > compatibles.
> >
> > So using google,gs101 is consistent with the existing upstream naming
> > scheme, for customized ASICs that were based off a Exynos design. But
> > it also reflects the reality that this SoC is not a Exynos9845 as there is
> > also a lot of Google owned and other third party IP integrated that is not
> > found in Exynos9845.
>
> A quick question: Do you imply Exynos9845 exists outside of the context
> of Tensor G1? I used to believe Exynos9845 **is** Tensor G1.

You are correct. William clarified that point for us. Thanks William!

>
> Also, what kind of Google IP are you talking about? I believe only the
> neural accelerator should be custom-ish.

This should not be considered an exhaustive list, but whilst looking in the
downstream public drivers at least the following Google IPs in the SoC

TPU/ML accelerator
Bigocean av1 video accelerator
Emerald hill compression engine
Camera ISP blocks
(AoC) Always on Compute

Plus of course Arm IPs (CPU+GPU), Synopsis IPs (USB, PCI. phys) etc.

The Exynos based IPs tend to be for things like pinmux, clocks, i2c, spi,
uart, mfc, display controller, timer etc.

>
> Additionally, I believe it having or not having Google IP is irrelevant:
> for example, the new Raspberry Pi 5 Broadcom SoC has a lot of
> Raspberry's own IP, but it's still called Broadcom as it's the real
> manufacturer and designer of the chip.

I think RPi / Broadcom is a very different situation to this. The original SoC
in RPi 1 was wholly designed by Broadcom, and marketed as a Broadcom
SoC [1].

Further iterations of the SoC until now have also not had RPi IP integrated.
RPi themselves refer to them as "Broadcom SoCs" on their webpage [2],
so it is completely expected that they live in a broadcom directory.

BCM2717 has integrated the RPi ISP, but to all intents and purposes this is a
Broadcom owned and designed SoC, albeit only now sold to one customer.

[1] https://web.archive.org/web/20120215080023/https://www.broadcom.com/products/BCM2835
[2] https://www.raspberrypi.com/documentation/computers/processors.html

> >
> > I guess the same is also true for `axis,artpec8` and `tesla,fsd` SoCs.
> > IMO the SoC compatible string should be uniquely identifying the actual
> > SoC, not a close relative.
> >
> > Regarding product_id you are correct this reads 0x09845000 but even
> > within Samsung Exynos family there are examples where the register
> > value does not match the SoC compatible. For example Exynos850 SoC
> > has a product ID value of "E3830". Where the Linux compatible is
> > matching the Samsung marketing name, not the internal/outdated name.
>
> I did not know Exynos 850 is also not going under it's real name.

It is going by its real name :) just not by its internal name that nobody has
heard of.

> Ultimately, I believe all of those SoCs should go under their technical
> name in the exynos/ directory.
>
> Another concern is that Google could in the future license other SoC: be
> it Qualcomm, Nvidia or anything. If we put completely different hw under
> google/ directory, does it really make sense? In that case, who'll
> maintain the google/ directory? Exynos people? Qualcomm people if they
> license it? Some other people?

I expect Google, or Google sponsored devs (as is the case for Linaro) to be
helping maintain the Google SoCs upstream. See the MAINTAINERS entry
for this series of who I expect to maintain this google directory.

>
> Then, I don't think Tensor G3 has a proper "GS" name, it goes by "Zuma"
> in decompiled kernel modules as far as I see.

That is correct, it is named Zuma downstream and they did away with the
gs101, gs201 type naming scheme.

>
> Finally, Tesla people already tried to submit drivers called by Tesla
> name, but which basically copied the functionality of the Exynos
> drivers. We would want to avoid that, ideally.

As you can see from this series we are not proposing that. Any IPs that
use Exynos IP we are using the existing upstream driver and enhance
it where we have features that aren't present upstream.

>
> My opinion is that all the Tesla and Google SoCs should be in the
> exynos/ directory, not only because they are basically Samsung Exynos,
> but also because they don't really need a separate directory: neither
> Google nor Tesla didn't neither manufacture or design those SoCs from
> scratch.

Who manufactures it seems irrelevant. Qcom and Broadcom don't
manufacture their SoCs either, but they still live in qcom and broadcom
directories upstream. Whether they designed the SoC from scratch or not
is also IMO largely irrelevant. In many cases the upstream community
has no way to determine whether things were outsourced or not anyway.
Did Apple outsource things in their silicon design? Who knows, and why
do we care? It's an apple branded chip in an apple branded product
let's call the directory apple.

Interestingly apple uses the same uart driver as Tensor, when I check back
through the commits in the driver.

fcbba344907afe26da487f1ed0b0e285c06a547b

tty: serial: samsung_tty: Add support for Apple UARTs

Apple SoCs are a distant descendant of Samsung designs and use yet
 another variant of their UART style, with different interrupt handling.


> The only reason I can think of for them to have it in a
> separate directory is maybe because Google and Tesla actually paid
> Samsung money for the right to call Exynos "Google designed" SoCs, but I
> believe the kernel should be left out of that.

Also the fact that they contain IPs not found in Samsung designed devices,
aren't known to most people as Exynos, and the maintenance issues of
having all the Google, Tesla, Axis, Exynos based SoCs in the same directory
(and who knows how many other ASIC customers in the future).

Ultimately it is Krzysztof's decision I think. I followed what he had previously
accepted for other SoCs for consistency and also because it seemed like the
correct approach to help scale up and ease the maintenance burden. If I look
at the number of tensor based SoCs, phones per SoC and board variants per
phone model, then you end up having a lot of files in the exynos directory over
time.

regards,

Peter

Re: [PATCH v2 00/20] Add minimal Tensor/GS101 SoC support and Oriole/Pixel6 board

[Peter Griffin]

Hi Maksym,

On Fri, 3 Nov 2023 at 13:56, Maksym Holovach
<maksym.holovach.an.2022@lpnu.ua> wrote:
>
> Hi Peter,
>
> On 11/3/23 15:11, Peter Griffin wrote:
> > Hi Maksym,
> >
> > Thanks for your feedback.
> >
> > On Thu, 2 Nov 2023 at 22:32, Maksym Holovach
> > <maksym.holovach.an.2022@lpnu.ua> wrote:
> >> Hi, all
> >>
> >> I wanted to inquire about how do you all feel about calling this SoC by
> >> the Google "gs101" name.
> > Interesting question, I think calling it gs101 is the correct approach see
> > below for my rationale.
> >
> >> I believe the proper name for it should be the actual Samsung name,
> >> written in the silicon and reported in the Chip ID hardware: Exynos9845.
> >> This also touches the Tensor G2 (Exynos9855), Tensor G3 (Exynos9865),
> >> and possibly the "Tesla" SoCs.

Also Exynos850 as I pointed out previously. I think that is the wrong approach
and very confusing. This SoC is not commonly known by anyone as
Exynos9845.

The same as the Exynos850 isn't known by anyone apart from Samsung folks
as Exynos 3830, and the tesla fsd SoC isn't known by whatever internal Samsung
name that presumably had.

Maybe Alim can comment what tesla fsd SoC has in the product id register.

> >>
> >> I do not think the Linux kernel should be a marketing material: it
> >> should reflect reality. The chip is almost 100% composed of Samsung
> >> Exynos IP blocks and should be called that way.

Where does this 'almost 100%' number come from? Are you measuring the die
area here or something else?

> > As you alluded to Tesla fsd and Axis artpec8 SoCs are also based on
> > Exynos designs and support upstream uses the axis,artpec8* or tesla,fsd*
> > compatibles.
> >
> > So using google,gs101 is consistent with the existing upstream naming
> > scheme, for customized ASICs that were based off a Exynos design. But
> > it also reflects the reality that this SoC is not a Exynos9845 as there is
> > also a lot of Google owned and other third party IP integrated that is not
> > found in Exynos9845.
>
> A quick question: Do you imply Exynos9845 exists outside of the context
> of Tensor G1? I used to believe Exynos9845 **is** Tensor G1.

You are correct. William clarified that point for us. Thanks William!

>
> Also, what kind of Google IP are you talking about? I believe only the
> neural accelerator should be custom-ish.

This should not be considered an exhaustive list, but whilst looking in the
downstream public drivers at least the following Google IPs in the SoC

TPU/ML accelerator
Bigocean av1 video accelerator
Emerald hill compression engine
Camera ISP blocks
(AoC) Always on Compute

Plus of course Arm IPs (CPU+GPU), Synopsis IPs (USB, PCI. phys) etc.

The Exynos based IPs tend to be for things like pinmux, clocks, i2c, spi,
uart, mfc, display controller, timer etc.

>
> Additionally, I believe it having or not having Google IP is irrelevant:
> for example, the new Raspberry Pi 5 Broadcom SoC has a lot of
> Raspberry's own IP, but it's still called Broadcom as it's the real
> manufacturer and designer of the chip.

I think RPi / Broadcom is a very different situation to this. The original SoC
in RPi 1 was wholly designed by Broadcom, and marketed as a Broadcom
SoC [1].

Further iterations of the SoC until now have also not had RPi IP integrated.
RPi themselves refer to them as "Broadcom SoCs" on their webpage [2],
so it is completely expected that they live in a broadcom directory.

BCM2717 has integrated the RPi ISP, but to all intents and purposes this is a
Broadcom owned and designed SoC, albeit only now sold to one customer.

[1] https://web.archive.org/web/20120215080023/https://www.broadcom.com/products/BCM2835
[2] https://www.raspberrypi.com/documentation/computers/processors.html

> >
> > I guess the same is also true for `axis,artpec8` and `tesla,fsd` SoCs.
> > IMO the SoC compatible string should be uniquely identifying the actual
> > SoC, not a close relative.
> >
> > Regarding product_id you are correct this reads 0x09845000 but even
> > within Samsung Exynos family there are examples where the register
> > value does not match the SoC compatible. For example Exynos850 SoC
> > has a product ID value of "E3830". Where the Linux compatible is
> > matching the Samsung marketing name, not the internal/outdated name.
>
> I did not know Exynos 850 is also not going under it's real name.

It is going by its real name :) just not by its internal name that nobody has
heard of.

> Ultimately, I believe all of those SoCs should go under their technical
> name in the exynos/ directory.
>
> Another concern is that Google could in the future license other SoC: be
> it Qualcomm, Nvidia or anything. If we put completely different hw under
> google/ directory, does it really make sense? In that case, who'll
> maintain the google/ directory? Exynos people? Qualcomm people if they
> license it? Some other people?

I expect Google, or Google sponsored devs (as is the case for Linaro) to be
helping maintain the Google SoCs upstream. See the MAINTAINERS entry
for this series of who I expect to maintain this google directory.

>
> Then, I don't think Tensor G3 has a proper "GS" name, it goes by "Zuma"
> in decompiled kernel modules as far as I see.

That is correct, it is named Zuma downstream and they did away with the
gs101, gs201 type naming scheme.

>
> Finally, Tesla people already tried to submit drivers called by Tesla
> name, but which basically copied the functionality of the Exynos
> drivers. We would want to avoid that, ideally.

As you can see from this series we are not proposing that. Any IPs that
use Exynos IP we are using the existing upstream driver and enhance
it where we have features that aren't present upstream.

>
> My opinion is that all the Tesla and Google SoCs should be in the
> exynos/ directory, not only because they are basically Samsung Exynos,
> but also because they don't really need a separate directory: neither
> Google nor Tesla didn't neither manufacture or design those SoCs from
> scratch.

Who manufactures it seems irrelevant. Qcom and Broadcom don't
manufacture their SoCs either, but they still live in qcom and broadcom
directories upstream. Whether they designed the SoC from scratch or not
is also IMO largely irrelevant. In many cases the upstream community
has no way to determine whether things were outsourced or not anyway.
Did Apple outsource things in their silicon design? Who knows, and why
do we care? It's an apple branded chip in an apple branded product
let's call the directory apple.

Interestingly apple uses the same uart driver as Tensor, when I check back
through the commits in the driver.

fcbba344907afe26da487f1ed0b0e285c06a547b

tty: serial: samsung_tty: Add support for Apple UARTs

Apple SoCs are a distant descendant of Samsung designs and use yet
 another variant of their UART style, with different interrupt handling.


> The only reason I can think of for them to have it in a
> separate directory is maybe because Google and Tesla actually paid
> Samsung money for the right to call Exynos "Google designed" SoCs, but I
> believe the kernel should be left out of that.

Also the fact that they contain IPs not found in Samsung designed devices,
aren't known to most people as Exynos, and the maintenance issues of
having all the Google, Tesla, Axis, Exynos based SoCs in the same directory
(and who knows how many other ASIC customers in the future).

Ultimately it is Krzysztof's decision I think. I followed what he had previously
accepted for other SoCs for consistency and also because it seemed like the
correct approach to help scale up and ease the maintenance burden. If I look
at the number of tensor based SoCs, phones per SoC and board variants per
phone model, then you end up having a lot of files in the exynos directory over
time.

regards,

Peter

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH v2 00/20] Add minimal Tensor/GS101 SoC support and Oriole/Pixel6 board

[Peter Griffin]

Hi Krzysztof,

On Fri, 3 Nov 2023 at 14:49, Krzysztof Kozlowski
<krzysztof.kozlowski@linaro.org> wrote:
>
> On 03/11/2023 14:56, Maksym Holovach wrote:
> > Hi Peter,
> >
> > On 11/3/23 15:11, Peter Griffin wrote:
> >> Hi Maksym,
> >>
> >> Thanks for your feedback.
> >>
> >> On Thu, 2 Nov 2023 at 22:32, Maksym Holovach
> >> <maksym.holovach.an.2022@lpnu.ua> wrote:
> >>> Hi, all
> >>>
> >>> I wanted to inquire about how do you all feel about calling this SoC by
> >>> the Google "gs101" name.
> >> Interesting question, I think calling it gs101 is the correct approach see
> >> below for my rationale.
> >>
> >>> I believe the proper name for it should be the actual Samsung name,
> >>> written in the silicon and reported in the Chip ID hardware: Exynos9845.
> >>> This also touches the Tensor G2 (Exynos9855), Tensor G3 (Exynos9865),
> >>> and possibly the "Tesla" SoCs.
> >>>
> >>> I do not think the Linux kernel should be a marketing material: it
> >>> should reflect reality. The chip is almost 100% composed of Samsung
> >>> Exynos IP blocks and should be called that way.
> >> As you alluded to Tesla fsd and Axis artpec8 SoCs are also based on
> >> Exynos designs and support upstream uses the axis,artpec8* or tesla,fsd*
> >> compatibles.
> >>
> >> So using google,gs101 is consistent with the existing upstream naming
> >> scheme, for customized ASICs that were based off a Exynos design. But
> >> it also reflects the reality that this SoC is not a Exynos9845 as there is
> >> also a lot of Google owned and other third party IP integrated that is not
> >> found in Exynos9845.
> >
> > A quick question: Do you imply Exynos9845 exists outside of the context
> > of Tensor G1? I used to believe Exynos9845 **is** Tensor G1.
> >
> > Also, what kind of Google IP are you talking about? I believe only the
> > neural accelerator should be custom-ish.
> >
> > Additionally, I believe it having or not having Google IP is irrelevant:
> > for example, the new Raspberry Pi 5 Broadcom SoC has a lot of
> > Raspberry's own IP, but it's still called Broadcom as it's the real
> > manufacturer and designer of the chip.
>
> That's a good argument. Indeed BCM2712 contains "New Raspberry
> Pi-developed ISP".
> https://www.raspberrypi.com/documentation/computers/processors.html
>
> There aren't many patches but GPU is still called brcm,2712.

RPi ISP is named 'raspberrypi,pispbe' in RPi downstream drivers. See
linux/drivers/media/platform/raspberrypi/pisp_be/ in RPi tree.

>
> For Tesla FSD, there was discussion and output was not very consisting.
> First, the name itself was used for everything - SoC architecture, one
> given SoC and eventually the board.
> https://lore.kernel.org/all/5ab62673-8d46-ec1d-1c80-696421ab69ca@canonical.com/
>
> Eventually the last part - board - was renamed to "Evaluation board",
> but I don't know how true or real it is.
>
> See also:
> "I would argue that if this SoC shares the pinctrl, clock, spi, adc,
> and timer implementation
> with Exynos, we should consider it part of the Exynos family,"
> https://lore.kernel.org/all/CAK8P3a31bCHNcNWrLX+QW+4RuK=DBpxLA_j5BFKxXxXKCT8PFQ@mail.gmail.com/
>
> However it was also claimed:
>
> "AFA architecture is concerns both Exynos and FSD has completely
> different architecture (at least at HW level)."
> https://lore.kernel.org/all/07ce01d8091e$9a6fd9c0$cf4f8d40$@samsung.com/

Thanks for those references.

I know nothing about Tesla FSD SoC internals I'm afraid. But it seems
plausible to
me that you would not goto the expense of designing your own SoC if something
existed off the shelf you could just buy.

I suspect the original SoC series for Tesla, Tensor etc tend to look
very "exynos"
centric as it is the non differentiating bits of IP, but also the IP
that is required first
to bring up the platform.

>
> >> I guess the same is also true for `axis,artpec8` and `tesla,fsd` SoCs.
> >> IMO the SoC compatible string should be uniquely identifying the actual
> >> SoC, not a close relative.
> >>
> >> Regarding product_id you are correct this reads 0x09845000 but even
> >> within Samsung Exynos family there are examples where the register
> >> value does not match the SoC compatible. For example Exynos850 SoC
> >> has a product ID value of "E3830". Where the Linux compatible is
> >> matching the Samsung marketing name, not the internal/outdated name.
> >
> > I did not know Exynos 850 is also not going under it's real name.
> > Ultimately, I believe all of those SoCs should go under their technical
> > name in the exynos/ directory.
>
> The initial technical name does not exist outside of vendor sources and
> part name. E.g. Winlink E850 board hardware manual calls it:
> "Samsung Exynos 850, S5E3830"
> and everywhere else Exynos 850 SoC is used.
>
> If you start calling it Exynos 3830, only me and Sam (who mainlined it)
> would know what is it. Everyone else, all users of kernel, would be
> confused.
>
> Therefore using well known final product name is for Exynos850 reasonable.

I agree that was the correct decision IMO, and it is a very similar
situation here
as far as I'm concerned. Most people don't know Tensor G1 SoC as Exynos
9845.

>
> >
> > Another concern is that Google could in the future license other SoC: be
> > it Qualcomm, Nvidia or anything. If we put completely different hw under
> > google/ directory, does it really make sense? In that case, who'll
> > maintain the google/ directory? Exynos people? Qualcomm people if they
> > license it? Some other people?
>
> That's indeed a problem. Future Tesla SoC might have just few pieces
> similar to FSD. There would be no common SoC part, except the actual
> Tesla IP.
>
> Same for Google. Future GSXXX, if done by Qualcomm, will be absolutely
> different than GS101 and the only common part would be the TPU (Tensor).

There is more Google IP than TPU but I see the point you're making.

>
> So now let's decide what is the common denominator:
> 1. Core SoC architecture, like buses, pinctrl, clocks, timers, serial,
> and many IP blocks, which constitute 95% of Devicetree bindings and drivers,
> 2. The one, big piece made by Samsung's customer: TPU, NPU or whatever.

Or multiple big pieces of IP.

Does having it all under the exynos directory help you somehow with
maintenance? Has having Alim maintain tesla-fsd in a separate directory
caused issues?

I structured it like this as I thought it would scale better, and also
because it was
consistent with what you had accepted previously for other Exynos derived SoCs
like Tesla.

>
> >
> > Then, I don't think Tensor G3 has a proper "GS" name, it goes by "Zuma"
> > in decompiled kernel modules as far as I see.
> >
> > Finally, Tesla people already tried to submit drivers called by Tesla
> > name, but which basically copied the functionality of the Exynos
> > drivers. We would want to avoid that, ideally.
> >
> > My opinion is that all the Tesla and Google SoCs should be in the
> > exynos/ directory, not only because they are basically Samsung Exynos,
> > but also because they don't really need a separate directory: neither
> > Google nor Tesla didn't neither manufacture or design those SoCs from
> > scratch. The only reason I can think of for them to have it in a
> > separate directory is maybe because Google and Tesla actually paid
> > Samsung money for the right to call Exynos "Google designed" SoCs, but I
> > believe the kernel should be left out of that.
>
> For some reason, although I know which, Cc-list is here trimmed and
> misses Alim...
>
> So standard reply follow (it makes me really, really grumpy, because it
> means you develop on some crazy old kernel or do not use tools which
> automate the process):
>
> Please use scripts/get_maintainers.pl to get a list of necessary people
> and lists to CC (and consider --no-git-fallback argument). It might
> happen, that command when run on an older kernel, gives you outdated
> entries. Therefore please be sure you base your patches on recent Linux
> kernel.

Sorry about that. I can add Alim and others to CC next time around. I didn't
notice he was listed as a reviewer of Exynos. I thought it was only for Tesla
FSD SoC. My apologies Alim!

Thanks,

Peter.

Re: [PATCH v2 00/20] Add minimal Tensor/GS101 SoC support and Oriole/Pixel6 board

[Peter Griffin]

Hi Krzysztof,

On Fri, 3 Nov 2023 at 14:49, Krzysztof Kozlowski
<krzysztof.kozlowski@linaro.org> wrote:
>
> On 03/11/2023 14:56, Maksym Holovach wrote:
> > Hi Peter,
> >
> > On 11/3/23 15:11, Peter Griffin wrote:
> >> Hi Maksym,
> >>
> >> Thanks for your feedback.
> >>
> >> On Thu, 2 Nov 2023 at 22:32, Maksym Holovach
> >> <maksym.holovach.an.2022@lpnu.ua> wrote:
> >>> Hi, all
> >>>
> >>> I wanted to inquire about how do you all feel about calling this SoC by
> >>> the Google "gs101" name.
> >> Interesting question, I think calling it gs101 is the correct approach see
> >> below for my rationale.
> >>
> >>> I believe the proper name for it should be the actual Samsung name,
> >>> written in the silicon and reported in the Chip ID hardware: Exynos9845.
> >>> This also touches the Tensor G2 (Exynos9855), Tensor G3 (Exynos9865),
> >>> and possibly the "Tesla" SoCs.
> >>>
> >>> I do not think the Linux kernel should be a marketing material: it
> >>> should reflect reality. The chip is almost 100% composed of Samsung
> >>> Exynos IP blocks and should be called that way.
> >> As you alluded to Tesla fsd and Axis artpec8 SoCs are also based on
> >> Exynos designs and support upstream uses the axis,artpec8* or tesla,fsd*
> >> compatibles.
> >>
> >> So using google,gs101 is consistent with the existing upstream naming
> >> scheme, for customized ASICs that were based off a Exynos design. But
> >> it also reflects the reality that this SoC is not a Exynos9845 as there is
> >> also a lot of Google owned and other third party IP integrated that is not
> >> found in Exynos9845.
> >
> > A quick question: Do you imply Exynos9845 exists outside of the context
> > of Tensor G1? I used to believe Exynos9845 **is** Tensor G1.
> >
> > Also, what kind of Google IP are you talking about? I believe only the
> > neural accelerator should be custom-ish.
> >
> > Additionally, I believe it having or not having Google IP is irrelevant:
> > for example, the new Raspberry Pi 5 Broadcom SoC has a lot of
> > Raspberry's own IP, but it's still called Broadcom as it's the real
> > manufacturer and designer of the chip.
>
> That's a good argument. Indeed BCM2712 contains "New Raspberry
> Pi-developed ISP".
> https://www.raspberrypi.com/documentation/computers/processors.html
>
> There aren't many patches but GPU is still called brcm,2712.

RPi ISP is named 'raspberrypi,pispbe' in RPi downstream drivers. See
linux/drivers/media/platform/raspberrypi/pisp_be/ in RPi tree.

>
> For Tesla FSD, there was discussion and output was not very consisting.
> First, the name itself was used for everything - SoC architecture, one
> given SoC and eventually the board.
> https://lore.kernel.org/all/5ab62673-8d46-ec1d-1c80-696421ab69ca@canonical.com/
>
> Eventually the last part - board - was renamed to "Evaluation board",
> but I don't know how true or real it is.
>
> See also:
> "I would argue that if this SoC shares the pinctrl, clock, spi, adc,
> and timer implementation
> with Exynos, we should consider it part of the Exynos family,"
> https://lore.kernel.org/all/CAK8P3a31bCHNcNWrLX+QW+4RuK=DBpxLA_j5BFKxXxXKCT8PFQ@mail.gmail.com/
>
> However it was also claimed:
>
> "AFA architecture is concerns both Exynos and FSD has completely
> different architecture (at least at HW level)."
> https://lore.kernel.org/all/07ce01d8091e$9a6fd9c0$cf4f8d40$@samsung.com/

Thanks for those references.

I know nothing about Tesla FSD SoC internals I'm afraid. But it seems
plausible to
me that you would not goto the expense of designing your own SoC if something
existed off the shelf you could just buy.

I suspect the original SoC series for Tesla, Tensor etc tend to look
very "exynos"
centric as it is the non differentiating bits of IP, but also the IP
that is required first
to bring up the platform.

>
> >> I guess the same is also true for `axis,artpec8` and `tesla,fsd` SoCs.
> >> IMO the SoC compatible string should be uniquely identifying the actual
> >> SoC, not a close relative.
> >>
> >> Regarding product_id you are correct this reads 0x09845000 but even
> >> within Samsung Exynos family there are examples where the register
> >> value does not match the SoC compatible. For example Exynos850 SoC
> >> has a product ID value of "E3830". Where the Linux compatible is
> >> matching the Samsung marketing name, not the internal/outdated name.
> >
> > I did not know Exynos 850 is also not going under it's real name.
> > Ultimately, I believe all of those SoCs should go under their technical
> > name in the exynos/ directory.
>
> The initial technical name does not exist outside of vendor sources and
> part name. E.g. Winlink E850 board hardware manual calls it:
> "Samsung Exynos 850, S5E3830"
> and everywhere else Exynos 850 SoC is used.
>
> If you start calling it Exynos 3830, only me and Sam (who mainlined it)
> would know what is it. Everyone else, all users of kernel, would be
> confused.
>
> Therefore using well known final product name is for Exynos850 reasonable.

I agree that was the correct decision IMO, and it is a very similar
situation here
as far as I'm concerned. Most people don't know Tensor G1 SoC as Exynos
9845.

>
> >
> > Another concern is that Google could in the future license other SoC: be
> > it Qualcomm, Nvidia or anything. If we put completely different hw under
> > google/ directory, does it really make sense? In that case, who'll
> > maintain the google/ directory? Exynos people? Qualcomm people if they
> > license it? Some other people?
>
> That's indeed a problem. Future Tesla SoC might have just few pieces
> similar to FSD. There would be no common SoC part, except the actual
> Tesla IP.
>
> Same for Google. Future GSXXX, if done by Qualcomm, will be absolutely
> different than GS101 and the only common part would be the TPU (Tensor).

There is more Google IP than TPU but I see the point you're making.

>
> So now let's decide what is the common denominator:
> 1. Core SoC architecture, like buses, pinctrl, clocks, timers, serial,
> and many IP blocks, which constitute 95% of Devicetree bindings and drivers,
> 2. The one, big piece made by Samsung's customer: TPU, NPU or whatever.

Or multiple big pieces of IP.

Does having it all under the exynos directory help you somehow with
maintenance? Has having Alim maintain tesla-fsd in a separate directory
caused issues?

I structured it like this as I thought it would scale better, and also
because it was
consistent with what you had accepted previously for other Exynos derived SoCs
like Tesla.

>
> >
> > Then, I don't think Tensor G3 has a proper "GS" name, it goes by "Zuma"
> > in decompiled kernel modules as far as I see.
> >
> > Finally, Tesla people already tried to submit drivers called by Tesla
> > name, but which basically copied the functionality of the Exynos
> > drivers. We would want to avoid that, ideally.
> >
> > My opinion is that all the Tesla and Google SoCs should be in the
> > exynos/ directory, not only because they are basically Samsung Exynos,
> > but also because they don't really need a separate directory: neither
> > Google nor Tesla didn't neither manufacture or design those SoCs from
> > scratch. The only reason I can think of for them to have it in a
> > separate directory is maybe because Google and Tesla actually paid
> > Samsung money for the right to call Exynos "Google designed" SoCs, but I
> > believe the kernel should be left out of that.
>
> For some reason, although I know which, Cc-list is here trimmed and
> misses Alim...
>
> So standard reply follow (it makes me really, really grumpy, because it
> means you develop on some crazy old kernel or do not use tools which
> automate the process):
>
> Please use scripts/get_maintainers.pl to get a list of necessary people
> and lists to CC (and consider --no-git-fallback argument). It might
> happen, that command when run on an older kernel, gives you outdated
> entries. Therefore please be sure you base your patches on recent Linux
> kernel.

Sorry about that. I can add Alim and others to CC next time around. I didn't
notice he was listed as a reviewer of Exynos. I thought it was only for Tesla
FSD SoC. My apologies Alim!

Thanks,

Peter.

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH v2 00/20] Add minimal Tensor/GS101 SoC support and Oriole/Pixel6 board

[Krzysztof Kozlowski]

On 06/11/2023 13:46, Peter Griffin wrote:
>>
>> Also, what kind of Google IP are you talking about? I believe only the
>> neural accelerator should be custom-ish.
> 
> This should not be considered an exhaustive list, but whilst looking in the
> downstream public drivers at least the following Google IPs in the SoC
> 
> TPU/ML accelerator
> Bigocean av1 video accelerator
> Emerald hill compression engine
> Camera ISP blocks
> (AoC) Always on Compute
> 
> Plus of course Arm IPs (CPU+GPU), Synopsis IPs (USB, PCI. phys) etc.

These are all common to Exynos and usually they use Exynos-specific
glue, so we consider them all Exynos-specific.

> 
> The Exynos based IPs tend to be for things like pinmux, clocks, i2c, spi,
> uart, mfc, display controller, timer etc.
> 
>>
>> Additionally, I believe it having or not having Google IP is irrelevant:
>> for example, the new Raspberry Pi 5 Broadcom SoC has a lot of
>> Raspberry's own IP, but it's still called Broadcom as it's the real
>> manufacturer and designer of the chip.
> 
> I think RPi / Broadcom is a very different situation to this. The original SoC
> in RPi 1 was wholly designed by Broadcom, and marketed as a Broadcom
> SoC [1].
> 
> Further iterations of the SoC until now have also not had RPi IP integrated.
> RPi themselves refer to them as "Broadcom SoCs" on their webpage [2],
> so it is completely expected that they live in a broadcom directory.
> 
> BCM2717 has integrated the RPi ISP, but to all intents and purposes this is a
> Broadcom owned and designed SoC, albeit only now sold to one customer.

Not that different.
Broadcom designed previous chip.
Samsung designed previous chip.
Broadcom designed BCM2717 with RPi ISP.
Samsung designed GS101 with Tensor NPU and other blocks.

>>>
>>> I guess the same is also true for `axis,artpec8` and `tesla,fsd` SoCs.
>>> IMO the SoC compatible string should be uniquely identifying the actual
>>> SoC, not a close relative.
>>>
>>> Regarding product_id you are correct this reads 0x09845000 but even
>>> within Samsung Exynos family there are examples where the register
>>> value does not match the SoC compatible. For example Exynos850 SoC
>>> has a product ID value of "E3830". Where the Linux compatible is
>>> matching the Samsung marketing name, not the internal/outdated name.
>>
>> I did not know Exynos 850 is also not going under it's real name.
> 
> It is going by its real name :) just not by its internal name that nobody has
> heard of.
> 
>> Ultimately, I believe all of those SoCs should go under their technical
>> name in the exynos/ directory.
>>
>> Another concern is that Google could in the future license other SoC: be
>> it Qualcomm, Nvidia or anything. If we put completely different hw under
>> google/ directory, does it really make sense? In that case, who'll
>> maintain the google/ directory? Exynos people? Qualcomm people if they
>> license it? Some other people?
> 
> I expect Google, or Google sponsored devs (as is the case for Linaro) to be
> helping maintain the Google SoCs upstream. See the MAINTAINERS entry
> for this series of who I expect to maintain this google directory.

That's fine. What I don't agree is with putting it into Google, because
Google wants to have all its phones in one place. That's not the
argument we used for any other SoCs or products.

We do not make decisions based on marketing or packaging wishes of some
company. Otherwise Samsung phones will be together. Toradex boards (also
spanning over NXP and TI) as well. Chromebooks DTS as well (oh, Doug
would be happy, I guess :) ). And so on.

> 
>>
>> Then, I don't think Tensor G3 has a proper "GS" name, it goes by "Zuma"
>> in decompiled kernel modules as far as I see.
> 
> That is correct, it is named Zuma downstream and they did away with the
> gs101, gs201 type naming scheme.
> 
>>
>> Finally, Tesla people already tried to submit drivers called by Tesla
>> name, but which basically copied the functionality of the Exynos
>> drivers. We would want to avoid that, ideally.
> 
> As you can see from this series we are not proposing that. Any IPs that
> use Exynos IP we are using the existing upstream driver and enhance
> it where we have features that aren't present upstream.
> 
>>
>> My opinion is that all the Tesla and Google SoCs should be in the
>> exynos/ directory, not only because they are basically Samsung Exynos,
>> but also because they don't really need a separate directory: neither
>> Google nor Tesla didn't neither manufacture or design those SoCs from
>> scratch.
> 
> Who manufactures it seems irrelevant. Qcom and Broadcom don't
> manufacture their SoCs either, but they still live in qcom and broadcom
> directories upstream. Whether they designed the SoC from scratch or not
> is also IMO largely irrelevant. In many cases the upstream community
> has no way to determine whether things were outsourced or not anyway.
> Did Apple outsource things in their silicon design? Who knows, and why
> do we care? It's an apple branded chip in an apple branded product
> let's call the directory apple.
> 
> Interestingly apple uses the same uart driver as Tensor, when I check back
> through the commits in the driver.
> 
> fcbba344907afe26da487f1ed0b0e285c06a547b
> 
> tty: serial: samsung_tty: Add support for Apple UARTs
> 
> Apple SoCs are a distant descendant of Samsung designs and use yet
>  another variant of their UART style, with different interrupt handling.
> 
> 
>> The only reason I can think of for them to have it in a
>> separate directory is maybe because Google and Tesla actually paid
>> Samsung money for the right to call Exynos "Google designed" SoCs, but I
>> believe the kernel should be left out of that.
> 
> Also the fact that they contain IPs not found in Samsung designed devices,
> aren't known to most people as Exynos, and the maintenance issues of
> having all the Google, Tesla, Axis, Exynos based SoCs in the same directory
> (and who knows how many other ASIC customers in the future).
> 
> Ultimately it is Krzysztof's decision I think. I followed what he had previously
> accepted for other SoCs for consistency and also because it seemed like the
> correct approach to help scale up and ease the maintenance burden. If I look
> at the number of tensor based SoCs, phones per SoC and board variants per
> phone model, then you end up having a lot of files in the exynos directory over
> time.

I agreed on Tesla FSD in its own place mainly because of arguments
provided that time: it's entirely different architecture. These
arguments were not backed by actual facts or proofs, though. The
upstreamed parts of FSD turned out to be... only Exynos specific. There
is literally nothing non-Exynos in upstream. Therefore knowing the
outcome I would say: put FSD into samsung directory.

About GS101 I have the same questions - how similar it is? I am pretty
sure that 95% of upstreamed code (DTS and drivers) will be Exynos-like
(except for missing upstream support for generations of Exynos SoC!).
But I cannot really judge and I am not going to investigate downstream
code to figure this out. Thus if you insist that SoC architecture and
core features are quite different from Exynos family, then sure, I can
live with it.

Best regards,
Krzysztof

Re: [PATCH v2 00/20] Add minimal Tensor/GS101 SoC support and Oriole/Pixel6 board

[Krzysztof Kozlowski]

On 06/11/2023 13:46, Peter Griffin wrote:
>>
>> Also, what kind of Google IP are you talking about? I believe only the
>> neural accelerator should be custom-ish.
> 
> This should not be considered an exhaustive list, but whilst looking in the
> downstream public drivers at least the following Google IPs in the SoC
> 
> TPU/ML accelerator
> Bigocean av1 video accelerator
> Emerald hill compression engine
> Camera ISP blocks
> (AoC) Always on Compute
> 
> Plus of course Arm IPs (CPU+GPU), Synopsis IPs (USB, PCI. phys) etc.

These are all common to Exynos and usually they use Exynos-specific
glue, so we consider them all Exynos-specific.

> 
> The Exynos based IPs tend to be for things like pinmux, clocks, i2c, spi,
> uart, mfc, display controller, timer etc.
> 
>>
>> Additionally, I believe it having or not having Google IP is irrelevant:
>> for example, the new Raspberry Pi 5 Broadcom SoC has a lot of
>> Raspberry's own IP, but it's still called Broadcom as it's the real
>> manufacturer and designer of the chip.
> 
> I think RPi / Broadcom is a very different situation to this. The original SoC
> in RPi 1 was wholly designed by Broadcom, and marketed as a Broadcom
> SoC [1].
> 
> Further iterations of the SoC until now have also not had RPi IP integrated.
> RPi themselves refer to them as "Broadcom SoCs" on their webpage [2],
> so it is completely expected that they live in a broadcom directory.
> 
> BCM2717 has integrated the RPi ISP, but to all intents and purposes this is a
> Broadcom owned and designed SoC, albeit only now sold to one customer.

Not that different.
Broadcom designed previous chip.
Samsung designed previous chip.
Broadcom designed BCM2717 with RPi ISP.
Samsung designed GS101 with Tensor NPU and other blocks.

>>>
>>> I guess the same is also true for `axis,artpec8` and `tesla,fsd` SoCs.
>>> IMO the SoC compatible string should be uniquely identifying the actual
>>> SoC, not a close relative.
>>>
>>> Regarding product_id you are correct this reads 0x09845000 but even
>>> within Samsung Exynos family there are examples where the register
>>> value does not match the SoC compatible. For example Exynos850 SoC
>>> has a product ID value of "E3830". Where the Linux compatible is
>>> matching the Samsung marketing name, not the internal/outdated name.
>>
>> I did not know Exynos 850 is also not going under it's real name.
> 
> It is going by its real name :) just not by its internal name that nobody has
> heard of.
> 
>> Ultimately, I believe all of those SoCs should go under their technical
>> name in the exynos/ directory.
>>
>> Another concern is that Google could in the future license other SoC: be
>> it Qualcomm, Nvidia or anything. If we put completely different hw under
>> google/ directory, does it really make sense? In that case, who'll
>> maintain the google/ directory? Exynos people? Qualcomm people if they
>> license it? Some other people?
> 
> I expect Google, or Google sponsored devs (as is the case for Linaro) to be
> helping maintain the Google SoCs upstream. See the MAINTAINERS entry
> for this series of who I expect to maintain this google directory.

That's fine. What I don't agree is with putting it into Google, because
Google wants to have all its phones in one place. That's not the
argument we used for any other SoCs or products.

We do not make decisions based on marketing or packaging wishes of some
company. Otherwise Samsung phones will be together. Toradex boards (also
spanning over NXP and TI) as well. Chromebooks DTS as well (oh, Doug
would be happy, I guess :) ). And so on.

> 
>>
>> Then, I don't think Tensor G3 has a proper "GS" name, it goes by "Zuma"
>> in decompiled kernel modules as far as I see.
> 
> That is correct, it is named Zuma downstream and they did away with the
> gs101, gs201 type naming scheme.
> 
>>
>> Finally, Tesla people already tried to submit drivers called by Tesla
>> name, but which basically copied the functionality of the Exynos
>> drivers. We would want to avoid that, ideally.
> 
> As you can see from this series we are not proposing that. Any IPs that
> use Exynos IP we are using the existing upstream driver and enhance
> it where we have features that aren't present upstream.
> 
>>
>> My opinion is that all the Tesla and Google SoCs should be in the
>> exynos/ directory, not only because they are basically Samsung Exynos,
>> but also because they don't really need a separate directory: neither
>> Google nor Tesla didn't neither manufacture or design those SoCs from
>> scratch.
> 
> Who manufactures it seems irrelevant. Qcom and Broadcom don't
> manufacture their SoCs either, but they still live in qcom and broadcom
> directories upstream. Whether they designed the SoC from scratch or not
> is also IMO largely irrelevant. In many cases the upstream community
> has no way to determine whether things were outsourced or not anyway.
> Did Apple outsource things in their silicon design? Who knows, and why
> do we care? It's an apple branded chip in an apple branded product
> let's call the directory apple.
> 
> Interestingly apple uses the same uart driver as Tensor, when I check back
> through the commits in the driver.
> 
> fcbba344907afe26da487f1ed0b0e285c06a547b
> 
> tty: serial: samsung_tty: Add support for Apple UARTs
> 
> Apple SoCs are a distant descendant of Samsung designs and use yet
>  another variant of their UART style, with different interrupt handling.
> 
> 
>> The only reason I can think of for them to have it in a
>> separate directory is maybe because Google and Tesla actually paid
>> Samsung money for the right to call Exynos "Google designed" SoCs, but I
>> believe the kernel should be left out of that.
> 
> Also the fact that they contain IPs not found in Samsung designed devices,
> aren't known to most people as Exynos, and the maintenance issues of
> having all the Google, Tesla, Axis, Exynos based SoCs in the same directory
> (and who knows how many other ASIC customers in the future).
> 
> Ultimately it is Krzysztof's decision I think. I followed what he had previously
> accepted for other SoCs for consistency and also because it seemed like the
> correct approach to help scale up and ease the maintenance burden. If I look
> at the number of tensor based SoCs, phones per SoC and board variants per
> phone model, then you end up having a lot of files in the exynos directory over
> time.

I agreed on Tesla FSD in its own place mainly because of arguments
provided that time: it's entirely different architecture. These
arguments were not backed by actual facts or proofs, though. The
upstreamed parts of FSD turned out to be... only Exynos specific. There
is literally nothing non-Exynos in upstream. Therefore knowing the
outcome I would say: put FSD into samsung directory.

About GS101 I have the same questions - how similar it is? I am pretty
sure that 95% of upstreamed code (DTS and drivers) will be Exynos-like
(except for missing upstream support for generations of Exynos SoC!).
But I cannot really judge and I am not going to investigate downstream
code to figure this out. Thus if you insist that SoC architecture and
core features are quite different from Exynos family, then sure, I can
live with it.

Best regards,
Krzysztof


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH v2 00/20] Add minimal Tensor/GS101 SoC support and Oriole/Pixel6 board

[Henrik Grimler]

Hi all,

On Mon, Nov 06, 2023 at 01:36:24PM +0000, Peter Griffin wrote:
> Hi Krzysztof,
> 
> On Fri, 3 Nov 2023 at 14:49, Krzysztof Kozlowski
> <krzysztof.kozlowski@linaro.org> wrote:
> >
> > On 03/11/2023 14:56, Maksym Holovach wrote:
> > > Hi Peter,
> > >
> > > On 11/3/23 15:11, Peter Griffin wrote:
> > >> Hi Maksym,
> > >>
> > >> Thanks for your feedback.

[ ... ]

> > >> I guess the same is also true for `axis,artpec8` and `tesla,fsd` SoCs.
> > >> IMO the SoC compatible string should be uniquely identifying the actual
> > >> SoC, not a close relative.
> > >>
> > >> Regarding product_id you are correct this reads 0x09845000 but even
> > >> within Samsung Exynos family there are examples where the register
> > >> value does not match the SoC compatible. For example Exynos850 SoC
> > >> has a product ID value of "E3830". Where the Linux compatible is
> > >> matching the Samsung marketing name, not the internal/outdated name.
> > >
> > > I did not know Exynos 850 is also not going under it's real name.
> > > Ultimately, I believe all of those SoCs should go under their technical
> > > name in the exynos/ directory.
> >
> > The initial technical name does not exist outside of vendor sources and
> > part name. E.g. Winlink E850 board hardware manual calls it:
> > "Samsung Exynos 850, S5E3830"
> > and everywhere else Exynos 850 SoC is used.
> >
> > If you start calling it Exynos 3830, only me and Sam (who mainlined it)
> > would know what is it. Everyone else, all users of kernel, would be
> > confused.
> >
> > Therefore using well known final product name is for Exynos850 reasonable.
> 
> I agree that was the correct decision IMO, and it is a very similar
> situation here
> as far as I'm concerned. Most people don't know Tensor G1 SoC as Exynos
> 9845.

I am not sure if Exynos 3830 and the like would be *that* confusing to
users. It does not seem like the internal names (like Exynos 3830) are
well guarded secret. The wikipedia article for Exynos even sort of
gives these names for recent Exynos models, Exynos 850 is called
S5E3830 for example, see section for Exynos 800:
https://en.wikipedia.org/wiki/Exynos#Exynos_800_series

Exynos 9845/S5E9845 is not mentioned in the article though.

[ ... ]

> > > Another concern is that Google could in the future license other SoC: be
> > > it Qualcomm, Nvidia or anything. If we put completely different hw under
> > > google/ directory, does it really make sense? In that case, who'll
> > > maintain the google/ directory? Exynos people? Qualcomm people if they
> > > license it? Some other people?
> >
> > That's indeed a problem. Future Tesla SoC might have just few pieces
> > similar to FSD. There would be no common SoC part, except the actual
> > Tesla IP.
> >
> > Same for Google. Future GSXXX, if done by Qualcomm, will be absolutely
> > different than GS101 and the only common part would be the TPU (Tensor).
> 
> There is more Google IP than TPU but I see the point you're making.
> 
> >
> > So now let's decide what is the common denominator:
> > 1. Core SoC architecture, like buses, pinctrl, clocks, timers, serial,
> > and many IP blocks, which constitute 95% of Devicetree bindings and drivers,
> > 2. The one, big piece made by Samsung's customer: TPU, NPU or whatever.
> 
> Or multiple big pieces of IP.
> 
> Does having it all under the exynos directory help you somehow with
> maintenance? Has having Alim maintain tesla-fsd in a separate directory
> caused issues?
> 
> I structured it like this as I thought it would scale better, and also
> because it was
> consistent with what you had accepted previously for other Exynos derived SoCs
> like Tesla.

Another small benefit of putting GS101 in exynos/ is that it makes it
easier for future contributors to find the code. If someone is for
example trying to add mainline support for their Samsung Galaxy S21
(Exynos 2100/Exynos 9840) and want to find somewhat related boards to
draw inspiration from then it is not clear at a first glance that
google/gs101-* are (somewhat) related.

[ ... ]

> Thanks,
> 
> Peter.

Best regards,
Henrik Grimler

Re: [PATCH v2 00/20] Add minimal Tensor/GS101 SoC support and Oriole/Pixel6 board

[Henrik Grimler]

Hi all,

On Mon, Nov 06, 2023 at 01:36:24PM +0000, Peter Griffin wrote:
> Hi Krzysztof,
> 
> On Fri, 3 Nov 2023 at 14:49, Krzysztof Kozlowski
> <krzysztof.kozlowski@linaro.org> wrote:
> >
> > On 03/11/2023 14:56, Maksym Holovach wrote:
> > > Hi Peter,
> > >
> > > On 11/3/23 15:11, Peter Griffin wrote:
> > >> Hi Maksym,
> > >>
> > >> Thanks for your feedback.

[ ... ]

> > >> I guess the same is also true for `axis,artpec8` and `tesla,fsd` SoCs.
> > >> IMO the SoC compatible string should be uniquely identifying the actual
> > >> SoC, not a close relative.
> > >>
> > >> Regarding product_id you are correct this reads 0x09845000 but even
> > >> within Samsung Exynos family there are examples where the register
> > >> value does not match the SoC compatible. For example Exynos850 SoC
> > >> has a product ID value of "E3830". Where the Linux compatible is
> > >> matching the Samsung marketing name, not the internal/outdated name.
> > >
> > > I did not know Exynos 850 is also not going under it's real name.
> > > Ultimately, I believe all of those SoCs should go under their technical
> > > name in the exynos/ directory.
> >
> > The initial technical name does not exist outside of vendor sources and
> > part name. E.g. Winlink E850 board hardware manual calls it:
> > "Samsung Exynos 850, S5E3830"
> > and everywhere else Exynos 850 SoC is used.
> >
> > If you start calling it Exynos 3830, only me and Sam (who mainlined it)
> > would know what is it. Everyone else, all users of kernel, would be
> > confused.
> >
> > Therefore using well known final product name is for Exynos850 reasonable.
> 
> I agree that was the correct decision IMO, and it is a very similar
> situation here
> as far as I'm concerned. Most people don't know Tensor G1 SoC as Exynos
> 9845.

I am not sure if Exynos 3830 and the like would be *that* confusing to
users. It does not seem like the internal names (like Exynos 3830) are
well guarded secret. The wikipedia article for Exynos even sort of
gives these names for recent Exynos models, Exynos 850 is called
S5E3830 for example, see section for Exynos 800:
https://en.wikipedia.org/wiki/Exynos#Exynos_800_series

Exynos 9845/S5E9845 is not mentioned in the article though.

[ ... ]

> > > Another concern is that Google could in the future license other SoC: be
> > > it Qualcomm, Nvidia or anything. If we put completely different hw under
> > > google/ directory, does it really make sense? In that case, who'll
> > > maintain the google/ directory? Exynos people? Qualcomm people if they
> > > license it? Some other people?
> >
> > That's indeed a problem. Future Tesla SoC might have just few pieces
> > similar to FSD. There would be no common SoC part, except the actual
> > Tesla IP.
> >
> > Same for Google. Future GSXXX, if done by Qualcomm, will be absolutely
> > different than GS101 and the only common part would be the TPU (Tensor).
> 
> There is more Google IP than TPU but I see the point you're making.
> 
> >
> > So now let's decide what is the common denominator:
> > 1. Core SoC architecture, like buses, pinctrl, clocks, timers, serial,
> > and many IP blocks, which constitute 95% of Devicetree bindings and drivers,
> > 2. The one, big piece made by Samsung's customer: TPU, NPU or whatever.
> 
> Or multiple big pieces of IP.
> 
> Does having it all under the exynos directory help you somehow with
> maintenance? Has having Alim maintain tesla-fsd in a separate directory
> caused issues?
> 
> I structured it like this as I thought it would scale better, and also
> because it was
> consistent with what you had accepted previously for other Exynos derived SoCs
> like Tesla.

Another small benefit of putting GS101 in exynos/ is that it makes it
easier for future contributors to find the code. If someone is for
example trying to add mainline support for their Samsung Galaxy S21
(Exynos 2100/Exynos 9840) and want to find somewhat related boards to
draw inspiration from then it is not clear at a first glance that
google/gs101-* are (somewhat) related.

[ ... ]

> Thanks,
> 
> Peter.

Best regards,
Henrik Grimler

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH v2 00/20] Add minimal Tensor/GS101 SoC support and Oriole/Pixel6 board

[William McVicker]

Hi Krzysztof,

On 11/06/2023, Krzysztof Kozlowski wrote:
> On 06/11/2023 13:46, Peter Griffin wrote:
> >>
> >> Also, what kind of Google IP are you talking about? I believe only the
> >> neural accelerator should be custom-ish.
> > 
> > This should not be considered an exhaustive list, but whilst looking in the
> > downstream public drivers at least the following Google IPs in the SoC
> > 
> > TPU/ML accelerator
> > Bigocean av1 video accelerator
> > Emerald hill compression engine
> > Camera ISP blocks
> > (AoC) Always on Compute
> > 
> > Plus of course Arm IPs (CPU+GPU), Synopsis IPs (USB, PCI. phys) etc.
> 
> These are all common to Exynos and usually they use Exynos-specific
> glue, so we consider them all Exynos-specific.
> 
> > 
> > The Exynos based IPs tend to be for things like pinmux, clocks, i2c, spi,
> > uart, mfc, display controller, timer etc.
> > 
> >>
> >> Additionally, I believe it having or not having Google IP is irrelevant:
> >> for example, the new Raspberry Pi 5 Broadcom SoC has a lot of
> >> Raspberry's own IP, but it's still called Broadcom as it's the real
> >> manufacturer and designer of the chip.
> > 
> > I think RPi / Broadcom is a very different situation to this. The original SoC
> > in RPi 1 was wholly designed by Broadcom, and marketed as a Broadcom
> > SoC [1].
> > 
> > Further iterations of the SoC until now have also not had RPi IP integrated.
> > RPi themselves refer to them as "Broadcom SoCs" on their webpage [2],
> > so it is completely expected that they live in a broadcom directory.
> > 
> > BCM2717 has integrated the RPi ISP, but to all intents and purposes this is a
> > Broadcom owned and designed SoC, albeit only now sold to one customer.
> 
> Not that different.
> Broadcom designed previous chip.
> Samsung designed previous chip.
> Broadcom designed BCM2717 with RPi ISP.
> Samsung designed GS101 with Tensor NPU and other blocks.
> 
> >>>
> >>> I guess the same is also true for `axis,artpec8` and `tesla,fsd` SoCs.
> >>> IMO the SoC compatible string should be uniquely identifying the actual
> >>> SoC, not a close relative.
> >>>
> >>> Regarding product_id you are correct this reads 0x09845000 but even
> >>> within Samsung Exynos family there are examples where the register
> >>> value does not match the SoC compatible. For example Exynos850 SoC
> >>> has a product ID value of "E3830". Where the Linux compatible is
> >>> matching the Samsung marketing name, not the internal/outdated name.
> >>
> >> I did not know Exynos 850 is also not going under it's real name.
> > 
> > It is going by its real name :) just not by its internal name that nobody has
> > heard of.
> > 
> >> Ultimately, I believe all of those SoCs should go under their technical
> >> name in the exynos/ directory.
> >>
> >> Another concern is that Google could in the future license other SoC: be
> >> it Qualcomm, Nvidia or anything. If we put completely different hw under
> >> google/ directory, does it really make sense? In that case, who'll
> >> maintain the google/ directory? Exynos people? Qualcomm people if they
> >> license it? Some other people?
> > 
> > I expect Google, or Google sponsored devs (as is the case for Linaro) to be
> > helping maintain the Google SoCs upstream. See the MAINTAINERS entry
> > for this series of who I expect to maintain this google directory.
> 
> That's fine. What I don't agree is with putting it into Google, because
> Google wants to have all its phones in one place. That's not the
> argument we used for any other SoCs or products.
> 
> We do not make decisions based on marketing or packaging wishes of some
> company. Otherwise Samsung phones will be together. Toradex boards (also
> spanning over NXP and TI) as well. Chromebooks DTS as well (oh, Doug
> would be happy, I guess :) ). And so on.
> 
> > 
> >>
> >> Then, I don't think Tensor G3 has a proper "GS" name, it goes by "Zuma"
> >> in decompiled kernel modules as far as I see.
> > 
> > That is correct, it is named Zuma downstream and they did away with the
> > gs101, gs201 type naming scheme.
> > 
> >>
> >> Finally, Tesla people already tried to submit drivers called by Tesla
> >> name, but which basically copied the functionality of the Exynos
> >> drivers. We would want to avoid that, ideally.
> > 
> > As you can see from this series we are not proposing that. Any IPs that
> > use Exynos IP we are using the existing upstream driver and enhance
> > it where we have features that aren't present upstream.
> > 
> >>
> >> My opinion is that all the Tesla and Google SoCs should be in the
> >> exynos/ directory, not only because they are basically Samsung Exynos,
> >> but also because they don't really need a separate directory: neither
> >> Google nor Tesla didn't neither manufacture or design those SoCs from
> >> scratch.
> > 
> > Who manufactures it seems irrelevant. Qcom and Broadcom don't
> > manufacture their SoCs either, but they still live in qcom and broadcom
> > directories upstream. Whether they designed the SoC from scratch or not
> > is also IMO largely irrelevant. In many cases the upstream community
> > has no way to determine whether things were outsourced or not anyway.
> > Did Apple outsource things in their silicon design? Who knows, and why
> > do we care? It's an apple branded chip in an apple branded product
> > let's call the directory apple.
> > 
> > Interestingly apple uses the same uart driver as Tensor, when I check back
> > through the commits in the driver.
> > 
> > fcbba344907afe26da487f1ed0b0e285c06a547b
> > 
> > tty: serial: samsung_tty: Add support for Apple UARTs
> > 
> > Apple SoCs are a distant descendant of Samsung designs and use yet
> >  another variant of their UART style, with different interrupt handling.
> > 
> > 
> >> The only reason I can think of for them to have it in a
> >> separate directory is maybe because Google and Tesla actually paid
> >> Samsung money for the right to call Exynos "Google designed" SoCs, but I
> >> believe the kernel should be left out of that.
> > 
> > Also the fact that they contain IPs not found in Samsung designed devices,
> > aren't known to most people as Exynos, and the maintenance issues of
> > having all the Google, Tesla, Axis, Exynos based SoCs in the same directory
> > (and who knows how many other ASIC customers in the future).
> > 
> > Ultimately it is Krzysztof's decision I think. I followed what he had previously
> > accepted for other SoCs for consistency and also because it seemed like the
> > correct approach to help scale up and ease the maintenance burden. If I look
> > at the number of tensor based SoCs, phones per SoC and board variants per
> > phone model, then you end up having a lot of files in the exynos directory over
> > time.
> 
> I agreed on Tesla FSD in its own place mainly because of arguments
> provided that time: it's entirely different architecture. These
> arguments were not backed by actual facts or proofs, though. The
> upstreamed parts of FSD turned out to be... only Exynos specific. There
> is literally nothing non-Exynos in upstream. Therefore knowing the
> outcome I would say: put FSD into samsung directory.
> 
> About GS101 I have the same questions - how similar it is? I am pretty
> sure that 95% of upstreamed code (DTS and drivers) will be Exynos-like
> (except for missing upstream support for generations of Exynos SoC!).
> But I cannot really judge and I am not going to investigate downstream
> code to figure this out. Thus if you insist that SoC architecture and
> core features are quite different from Exynos family, then sure, I can
> live with it.

I honestly don't care too much about where the DT files are stored --
arch/arm64/boot/dts/exynos vs .../dts/google. I didn't think this would be such
a hot topic! If this makes it easier for you to maintain, then so be it.

Just to note, I do understand what I proposed is something new -- group DT
files based on product owner vs original SoC designer -- and think it warrants
consideration since it does make it easier to distinguish which DT files are
associated with each product as well as package and distribute them easily, but
that can be a discussion for another time when we get more upstreamed.

Thanks,
Will

> 
> Best regards,
> Krzysztof
> 

Re: [PATCH v2 00/20] Add minimal Tensor/GS101 SoC support and Oriole/Pixel6 board

[William McVicker]

Hi Krzysztof,

On 11/06/2023, Krzysztof Kozlowski wrote:
> On 06/11/2023 13:46, Peter Griffin wrote:
> >>
> >> Also, what kind of Google IP are you talking about? I believe only the
> >> neural accelerator should be custom-ish.
> > 
> > This should not be considered an exhaustive list, but whilst looking in the
> > downstream public drivers at least the following Google IPs in the SoC
> > 
> > TPU/ML accelerator
> > Bigocean av1 video accelerator
> > Emerald hill compression engine
> > Camera ISP blocks
> > (AoC) Always on Compute
> > 
> > Plus of course Arm IPs (CPU+GPU), Synopsis IPs (USB, PCI. phys) etc.
> 
> These are all common to Exynos and usually they use Exynos-specific
> glue, so we consider them all Exynos-specific.
> 
> > 
> > The Exynos based IPs tend to be for things like pinmux, clocks, i2c, spi,
> > uart, mfc, display controller, timer etc.
> > 
> >>
> >> Additionally, I believe it having or not having Google IP is irrelevant:
> >> for example, the new Raspberry Pi 5 Broadcom SoC has a lot of
> >> Raspberry's own IP, but it's still called Broadcom as it's the real
> >> manufacturer and designer of the chip.
> > 
> > I think RPi / Broadcom is a very different situation to this. The original SoC
> > in RPi 1 was wholly designed by Broadcom, and marketed as a Broadcom
> > SoC [1].
> > 
> > Further iterations of the SoC until now have also not had RPi IP integrated.
> > RPi themselves refer to them as "Broadcom SoCs" on their webpage [2],
> > so it is completely expected that they live in a broadcom directory.
> > 
> > BCM2717 has integrated the RPi ISP, but to all intents and purposes this is a
> > Broadcom owned and designed SoC, albeit only now sold to one customer.
> 
> Not that different.
> Broadcom designed previous chip.
> Samsung designed previous chip.
> Broadcom designed BCM2717 with RPi ISP.
> Samsung designed GS101 with Tensor NPU and other blocks.
> 
> >>>
> >>> I guess the same is also true for `axis,artpec8` and `tesla,fsd` SoCs.
> >>> IMO the SoC compatible string should be uniquely identifying the actual
> >>> SoC, not a close relative.
> >>>
> >>> Regarding product_id you are correct this reads 0x09845000 but even
> >>> within Samsung Exynos family there are examples where the register
> >>> value does not match the SoC compatible. For example Exynos850 SoC
> >>> has a product ID value of "E3830". Where the Linux compatible is
> >>> matching the Samsung marketing name, not the internal/outdated name.
> >>
> >> I did not know Exynos 850 is also not going under it's real name.
> > 
> > It is going by its real name :) just not by its internal name that nobody has
> > heard of.
> > 
> >> Ultimately, I believe all of those SoCs should go under their technical
> >> name in the exynos/ directory.
> >>
> >> Another concern is that Google could in the future license other SoC: be
> >> it Qualcomm, Nvidia or anything. If we put completely different hw under
> >> google/ directory, does it really make sense? In that case, who'll
> >> maintain the google/ directory? Exynos people? Qualcomm people if they
> >> license it? Some other people?
> > 
> > I expect Google, or Google sponsored devs (as is the case for Linaro) to be
> > helping maintain the Google SoCs upstream. See the MAINTAINERS entry
> > for this series of who I expect to maintain this google directory.
> 
> That's fine. What I don't agree is with putting it into Google, because
> Google wants to have all its phones in one place. That's not the
> argument we used for any other SoCs or products.
> 
> We do not make decisions based on marketing or packaging wishes of some
> company. Otherwise Samsung phones will be together. Toradex boards (also
> spanning over NXP and TI) as well. Chromebooks DTS as well (oh, Doug
> would be happy, I guess :) ). And so on.
> 
> > 
> >>
> >> Then, I don't think Tensor G3 has a proper "GS" name, it goes by "Zuma"
> >> in decompiled kernel modules as far as I see.
> > 
> > That is correct, it is named Zuma downstream and they did away with the
> > gs101, gs201 type naming scheme.
> > 
> >>
> >> Finally, Tesla people already tried to submit drivers called by Tesla
> >> name, but which basically copied the functionality of the Exynos
> >> drivers. We would want to avoid that, ideally.
> > 
> > As you can see from this series we are not proposing that. Any IPs that
> > use Exynos IP we are using the existing upstream driver and enhance
> > it where we have features that aren't present upstream.
> > 
> >>
> >> My opinion is that all the Tesla and Google SoCs should be in the
> >> exynos/ directory, not only because they are basically Samsung Exynos,
> >> but also because they don't really need a separate directory: neither
> >> Google nor Tesla didn't neither manufacture or design those SoCs from
> >> scratch.
> > 
> > Who manufactures it seems irrelevant. Qcom and Broadcom don't
> > manufacture their SoCs either, but they still live in qcom and broadcom
> > directories upstream. Whether they designed the SoC from scratch or not
> > is also IMO largely irrelevant. In many cases the upstream community
> > has no way to determine whether things were outsourced or not anyway.
> > Did Apple outsource things in their silicon design? Who knows, and why
> > do we care? It's an apple branded chip in an apple branded product
> > let's call the directory apple.
> > 
> > Interestingly apple uses the same uart driver as Tensor, when I check back
> > through the commits in the driver.
> > 
> > fcbba344907afe26da487f1ed0b0e285c06a547b
> > 
> > tty: serial: samsung_tty: Add support for Apple UARTs
> > 
> > Apple SoCs are a distant descendant of Samsung designs and use yet
> >  another variant of their UART style, with different interrupt handling.
> > 
> > 
> >> The only reason I can think of for them to have it in a
> >> separate directory is maybe because Google and Tesla actually paid
> >> Samsung money for the right to call Exynos "Google designed" SoCs, but I
> >> believe the kernel should be left out of that.
> > 
> > Also the fact that they contain IPs not found in Samsung designed devices,
> > aren't known to most people as Exynos, and the maintenance issues of
> > having all the Google, Tesla, Axis, Exynos based SoCs in the same directory
> > (and who knows how many other ASIC customers in the future).
> > 
> > Ultimately it is Krzysztof's decision I think. I followed what he had previously
> > accepted for other SoCs for consistency and also because it seemed like the
> > correct approach to help scale up and ease the maintenance burden. If I look
> > at the number of tensor based SoCs, phones per SoC and board variants per
> > phone model, then you end up having a lot of files in the exynos directory over
> > time.
> 
> I agreed on Tesla FSD in its own place mainly because of arguments
> provided that time: it's entirely different architecture. These
> arguments were not backed by actual facts or proofs, though. The
> upstreamed parts of FSD turned out to be... only Exynos specific. There
> is literally nothing non-Exynos in upstream. Therefore knowing the
> outcome I would say: put FSD into samsung directory.
> 
> About GS101 I have the same questions - how similar it is? I am pretty
> sure that 95% of upstreamed code (DTS and drivers) will be Exynos-like
> (except for missing upstream support for generations of Exynos SoC!).
> But I cannot really judge and I am not going to investigate downstream
> code to figure this out. Thus if you insist that SoC architecture and
> core features are quite different from Exynos family, then sure, I can
> live with it.

I honestly don't care too much about where the DT files are stored --
arch/arm64/boot/dts/exynos vs .../dts/google. I didn't think this would be such
a hot topic! If this makes it easier for you to maintain, then so be it.

Just to note, I do understand what I proposed is something new -- group DT
files based on product owner vs original SoC designer -- and think it warrants
consideration since it does make it easier to distinguish which DT files are
associated with each product as well as package and distribute them easily, but
that can be a discussion for another time when we get more upstreamed.

Thanks,
Will

> 
> Best regards,
> Krzysztof
> 

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH v2 00/20] Add minimal Tensor/GS101 SoC support and Oriole/Pixel6 board

[William McVicker]

Hi Maksym,

On 11/04/2023, Maksym Holovach wrote:
> I believe I misunderstood your point, and now that I'm reading it again I
> believe grouping device trees based on device manufacturer is definitely an
> interesting idea and it would definitely make sense for e.g. x86, where
> there's basically two big SoC vendors and all the DTBs for the motherboards
> in just those two folders would result in cluttering issues, however it is
> not currently done in arm64/boot/dts, where the subfolders are per-platform
> (exynos, qcom, mtk, tegra, ...) - with an exception of Tesla, which perhaps
> should be also corrected (also CONFIG_ARCH makes it clear what those
> directory names are actually meant to represent).
> 
> If you think the current approach should be changed, it should be changed
> for all device-trees, and the CONFIG_ARCH_* should be also renamed, but also
> we'd need to convince everyone that this approach is superior to others...
> 
> Maybe the solution to this is to have arch/arm64/boot/dts/exynos/google with
> Google's boards, and to have the SoC .dtsi files in
> arch/arm64/boot/dts/exynos, but I'm not sure.

Honesty, I don't care too much about where the files are kept. I agree it makes
sense to keep them with the other Exynos DT files due to similarities with the
other Exynos SoCs. I think the grouping based on vendor under the exynos folder
make a lot of sense though considering how many DT files we will accumulate
over time.

> 
> Additionally, I believe using .dtbo files like that (per board variant) is
> not really expected, instead each board should have its own .dtb file,
> compiled from a board .dts file which includes the SoC .dtsi file but this
> is not up to me to judge...

This is something we (Peter and I) are wanting to discuss at LPC next week.
We've included it in our slides and hope there will be enough folks there to
have a good discussion.

> 
> On 11/4/23 01:05, Maksym Holovach wrote:
> > Hi William,
> > 
> > On 11/3/23 19:36, William McVicker wrote:
> > > Hi Maksym, Krzysztof, Peter,
> > > 
> > > On 11/03/2023, Krzysztof Kozlowski wrote:
> > > > On 03/11/2023 14:56, Maksym Holovach wrote:
> > > > > Hi Peter,
> > > > > 
> > > > > On 11/3/23 15:11, Peter Griffin wrote:
> > > > > > Hi Maksym,
> > > > > > 
> > > > > > Thanks for your feedback.
> > > > > > 
> > > > > > On Thu, 2 Nov 2023 at 22:32, Maksym Holovach
> > > > > > <maksym.holovach.an.2022@lpnu.ua> wrote:
> > > > > > > Hi, all
> > > > > > > 
> > > > > > > I wanted to inquire about how do you all feel about
> > > > > > > calling this SoC by
> > > > > > > the Google "gs101" name.
> > > > > > Interesting question, I think calling it gs101 is the
> > > > > > correct approach see
> > > > > > below for my rationale.
> > > > > > 
> > > > > > > I believe the proper name for it should be the actual Samsung name,
> > > > > > > written in the silicon and reported in the Chip ID
> > > > > > > hardware: Exynos9845.
> > > > > > > This also touches the Tensor G2 (Exynos9855), Tensor
> > > > > > > G3 (Exynos9865),
> > > > > > > and possibly the "Tesla" SoCs.
> > > > > > > 
> > > > > > > I do not think the Linux kernel should be a marketing material: it
> > > > > > > should reflect reality. The chip is almost 100% composed of Samsung
> > > > > > > Exynos IP blocks and should be called that way.
> > > > > > As you alluded to Tesla fsd and Axis artpec8 SoCs are also based on
> > > > > > Exynos designs and support upstream uses the
> > > > > > axis,artpec8* or tesla,fsd*
> > > > > > compatibles.
> > > > > > 
> > > > > > So using google,gs101 is consistent with the existing upstream naming
> > > > > > scheme, for customized ASICs that were based off a Exynos design. But
> > > > > > it also reflects the reality that this SoC is not a
> > > > > > Exynos9845 as there is
> > > > > > also a lot of Google owned and other third party IP
> > > > > > integrated that is not
> > > > > > found in Exynos9845.
> > > > > A quick question: Do you imply Exynos9845 exists outside of
> > > > > the context
> > > > > of Tensor G1? I used to believe Exynos9845 **is** Tensor G1.
> > > Yes, the gs101 SoC is *not* equivalent to the Exynos9845. Similar to
> > > how Tesla
> > > FSD licenses Exynos IP blocks, gs101 does not only comprise of Exynos IP
> > > blocks. The final design is unique to Google and comprises of
> > > several different
> > > vendor IP blocks (not only Exynos).
> > > 
> > > > > Also, what kind of Google IP are you talking about? I believe only the
> > > > > neural accelerator should be custom-ish.
> > > > > 
> > > > > Additionally, I believe it having or not having Google IP is
> > > > > irrelevant:
> > > > > for example, the new Raspberry Pi 5 Broadcom SoC has a lot of
> > > > > Raspberry's own IP, but it's still called Broadcom as it's the real
> > > > > manufacturer and designer of the chip.
> > > > That's a good argument. Indeed BCM2712 contains "New Raspberry
> > > > Pi-developed ISP".
> > > > https://www.raspberrypi.com/documentation/computers/processors.html
> > > > 
> > > > There aren't many patches but GPU is still called brcm,2712.
> > > > 
> > > > For Tesla FSD, there was discussion and output was not very consisting.
> > > > First, the name itself was used for everything - SoC architecture, one
> > > > given SoC and eventually the board.
> > > > https://lore.kernel.org/all/5ab62673-8d46-ec1d-1c80-696421ab69ca@canonical.com/
> > > > 
> > > > 
> > > > Eventually the last part - board - was renamed to "Evaluation board",
> > > > but I don't know how true or real it is.
> > > > 
> > > > See also:
> > > > "I would argue that if this SoC shares the pinctrl, clock, spi, adc,
> > > > and timer implementation
> > > > with Exynos, we should consider it part of the Exynos family,"
> > > > https://lore.kernel.org/all/CAK8P3a31bCHNcNWrLX+QW+4RuK=DBpxLA_j5BFKxXxXKCT8PFQ@mail.gmail.com/
> > > > 
> > > > 
> > > > However it was also claimed:
> > > > 
> > > > "AFA architecture is concerns both Exynos and FSD has completely
> > > > different architecture (at least at HW level)."
> > > > https://lore.kernel.org/all/07ce01d8091e$9a6fd9c0$cf4f8d40$@samsung.com/
> > > > 
> > > > 
> > > > > > I guess the same is also true for `axis,artpec8` and
> > > > > > `tesla,fsd` SoCs.
> > > > > > IMO the SoC compatible string should be uniquely
> > > > > > identifying the actual
> > > > > > SoC, not a close relative.
> > > > > > 
> > > > > > Regarding product_id you are correct this reads 0x09845000 but even
> > > > > > within Samsung Exynos family there are examples where the register
> > > > > > value does not match the SoC compatible. For example Exynos850 SoC
> > > > > > has a product ID value of "E3830". Where the Linux compatible is
> > > > > > matching the Samsung marketing name, not the internal/outdated name.
> > > > > I did not know Exynos 850 is also not going under it's real name.
> > > > > Ultimately, I believe all of those SoCs should go under
> > > > > their technical
> > > > > name in the exynos/ directory.
> > > > The initial technical name does not exist outside of vendor sources and
> > > > part name. E.g. Winlink E850 board hardware manual calls it:
> > > > "Samsung Exynos 850, S5E3830"
> > > > and everywhere else Exynos 850 SoC is used.
> > > > 
> > > > If you start calling it Exynos 3830, only me and Sam (who mainlined it)
> > > > would know what is it. Everyone else, all users of kernel, would be
> > > > confused.
> > > > 
> > > > Therefore using well known final product name is for Exynos850
> > > > reasonable.
> > > I agree with this. By using the final (well known) product SoC name
> > > -- gs101 --
> > > other developers will be able to easily identify the particular SoC.
> > > 
> > > > > Another concern is that Google could in the future license
> > > > > other SoC: be
> > > > > it Qualcomm, Nvidia or anything. If we put completely
> > > > > different hw under
> > > > > google/ directory, does it really make sense? In that case, who'll
> > > > > maintain the google/ directory? Exynos people? Qualcomm people if they
> > > > > license it? Some other people?
> > > I don't understand why the architecture of the SoC would dictate
> > > which folder
> > > to put the device tree files under. It makes more sense to group
> > > board DT files
> > > together based on who distributes them. Having all the Pixel DT
> > > board files
> > > together allows Google to create a single device tree binary per SoC
> > > coupled
> > > with the set of device tree overlays per board variant (this is the
> > > dtbo.img)
> > > to ship to all their devices. If you look at all the in-market Pixel
> > > devices
> > > with Tensor SoCs, you will find that you could create one dtb
> > > (concatenate
> > > gs101.dtb, gs201.dtb, and zuma.dtb) and one dtbo image for 10
> > > devices which
> > > significantly simplifies the maintenance, testing, and software
> > > distribution
> > > for all 10 of those products.
> > 
> > How is that relevant?
> > 
> > I believe it is none of the kernel concerns, it's up to the user to do
> > whatever with the built .dtb files.
> > 
> > Also I do not see an issue in having a file list of all the .dtbo files
> > you might want.

I think organizing the DT files based on a product is relevant because it makes
it easier to identify what files are associated with the final product(s).
Leaving it up to the user just means you are forcing everyone to roll their own
scripts to re-organize/postprocess the kernel artifacts for their products.
I think it would be nice to be able to configure the kernel build to generate
artifacts that are directly usable on the device.

> > > 
> > > > That's indeed a problem. Future Tesla SoC might have just few pieces
> > > > similar to FSD. There would be no common SoC part, except the actual
> > > > Tesla IP.
> > > > 
> > > > Same for Google. Future GSXXX, if done by Qualcomm, will be absolutely
> > > > different than GS101 and the only common part would be the TPU
> > > > (Tensor).
> > > > 
> > > > So now let's decide what is the common denominator:
> > > > 1. Core SoC architecture, like buses, pinctrl, clocks, timers, serial,
> > > > and many IP blocks, which constitute 95% of Devicetree bindings
> > > > and drivers,
> > > > 2. The one, big piece made by Samsung's customer: TPU, NPU or whatever.
> > > As mentioned above, I think this should be based on how the DTBs and
> > > DTBOs are
> > > used and distributed. What is the benefit of adding the gs101 board
> > > files under
> > > the exynos folder?
> > 
> > One clear benefit would be the ease of maintaining all the SoC files at
> > once. It's not that it is a benefit of having it in the Exynos folder,
> > it's more like that there's no benefit in having a separate folder, and
> > that also comes with some additional issues.
> > 
> > As I said earlier, it's pretty similar to the Raspberry Pi 5 example: It
> > contains Raspberry's in-house IP, but it's still called properly
> > Broadcom. The only difference is that Raspberry does not want its name
> > on the chip, but Google does, despite it being just as custom as the
> > Raspberry SoC is. The company's policy should not be a factor for this
> > decision, in my opinion.
> > 
> > However as you've added, gs101 is the same thing as Exynos9845, so I
> > believe there's no question that the Exynos name should be specified
> > somewhere too, because this is what's literally wired in hardware, and
> > not just a "well-known name that is used by Google in the Pixel factory
> > kernel".
> > 
> > I agree though that just specifying the internal E9845 name could
> > mislead some people, but GS101 is a similarly obscure name, and not even
> > the real name of the hardware.

gs101 is used in the downstream drivers as well as referenced in online
materials referring to Pixel 6 (just search for "Google gs101"). In addition,
gs101 is used by the Android userspace to refer to the SoC that Pixel 6/6
Pro/6a use. The same goes for gs201 and zuma.  So I think it's important to
keep the names consistent. I don't think the Exynos 9845 is ever referenced in
the Android vendor userspace nor is it ever used by tech bloggers/writer/
enthusiast developers when referring to the Pixel 6 device. So if upstream
decides to use the term 9845, they will just be introducing even more
confusion.

I also want to point out that I don't really like the Tensor name either. This
is equivalent to the "Snapdragon" marketing name that is not used either in the
Qualcomm device tree. In my opinion, gs101 is equivant to the "msmXYZ" and
"smXYZ" names, e.g. msm8996 and sm8650.

Thanks,
Will

> > 
> > > 
> > > Thanks,
> > > Will
> > > 
> > > > > Then, I don't think Tensor G3 has a proper "GS" name, it
> > > > > goes by "Zuma"
> > > > > in decompiled kernel modules as far as I see.
> > > > > 
> > > > > Finally, Tesla people already tried to submit drivers called by Tesla
> > > > > name, but which basically copied the functionality of the Exynos
> > > > > drivers. We would want to avoid that, ideally.
> > > > > 
> > > > > My opinion is that all the Tesla and Google SoCs should be in the
> > > > > exynos/ directory, not only because they are basically Samsung Exynos,
> > > > > but also because they don't really need a separate directory: neither
> > > > > Google nor Tesla didn't neither manufacture or design those SoCs from
> > > > > scratch. The only reason I can think of for them to have it in a
> > > > > separate directory is maybe because Google and Tesla actually paid
> > > > > Samsung money for the right to call Exynos "Google designed"
> > > > > SoCs, but I
> > > > > believe the kernel should be left out of that.
> > > > For some reason, although I know which, Cc-list is here trimmed and
> > > > misses Alim...
> > > > 
> > > > So standard reply follow (it makes me really, really grumpy, because it
> > > > means you develop on some crazy old kernel or do not use tools which
> > > > automate the process):
> > > > 
> > > > Please use scripts/get_maintainers.pl to get a list of necessary people
> > > > and lists to CC (and consider --no-git-fallback argument). It might
> > > > happen, that command when run on an older kernel, gives you outdated
> > > > entries. Therefore please be sure you base your patches on recent Linux
> > > > kernel.
> > > > 
> > > > Best regards,
> > > > Krzysztof
> > > > 
> > Yours,
> > 
> > Maksym
> > 
> Yours,
> 
> Maksym
> 

Re: [PATCH v2 00/20] Add minimal Tensor/GS101 SoC support and Oriole/Pixel6 board

[William McVicker]

Hi Maksym,

On 11/04/2023, Maksym Holovach wrote:
> I believe I misunderstood your point, and now that I'm reading it again I
> believe grouping device trees based on device manufacturer is definitely an
> interesting idea and it would definitely make sense for e.g. x86, where
> there's basically two big SoC vendors and all the DTBs for the motherboards
> in just those two folders would result in cluttering issues, however it is
> not currently done in arm64/boot/dts, where the subfolders are per-platform
> (exynos, qcom, mtk, tegra, ...) - with an exception of Tesla, which perhaps
> should be also corrected (also CONFIG_ARCH makes it clear what those
> directory names are actually meant to represent).
> 
> If you think the current approach should be changed, it should be changed
> for all device-trees, and the CONFIG_ARCH_* should be also renamed, but also
> we'd need to convince everyone that this approach is superior to others...
> 
> Maybe the solution to this is to have arch/arm64/boot/dts/exynos/google with
> Google's boards, and to have the SoC .dtsi files in
> arch/arm64/boot/dts/exynos, but I'm not sure.

Honesty, I don't care too much about where the files are kept. I agree it makes
sense to keep them with the other Exynos DT files due to similarities with the
other Exynos SoCs. I think the grouping based on vendor under the exynos folder
make a lot of sense though considering how many DT files we will accumulate
over time.

> 
> Additionally, I believe using .dtbo files like that (per board variant) is
> not really expected, instead each board should have its own .dtb file,
> compiled from a board .dts file which includes the SoC .dtsi file but this
> is not up to me to judge...

This is something we (Peter and I) are wanting to discuss at LPC next week.
We've included it in our slides and hope there will be enough folks there to
have a good discussion.

> 
> On 11/4/23 01:05, Maksym Holovach wrote:
> > Hi William,
> > 
> > On 11/3/23 19:36, William McVicker wrote:
> > > Hi Maksym, Krzysztof, Peter,
> > > 
> > > On 11/03/2023, Krzysztof Kozlowski wrote:
> > > > On 03/11/2023 14:56, Maksym Holovach wrote:
> > > > > Hi Peter,
> > > > > 
> > > > > On 11/3/23 15:11, Peter Griffin wrote:
> > > > > > Hi Maksym,
> > > > > > 
> > > > > > Thanks for your feedback.
> > > > > > 
> > > > > > On Thu, 2 Nov 2023 at 22:32, Maksym Holovach
> > > > > > <maksym.holovach.an.2022@lpnu.ua> wrote:
> > > > > > > Hi, all
> > > > > > > 
> > > > > > > I wanted to inquire about how do you all feel about
> > > > > > > calling this SoC by
> > > > > > > the Google "gs101" name.
> > > > > > Interesting question, I think calling it gs101 is the
> > > > > > correct approach see
> > > > > > below for my rationale.
> > > > > > 
> > > > > > > I believe the proper name for it should be the actual Samsung name,
> > > > > > > written in the silicon and reported in the Chip ID
> > > > > > > hardware: Exynos9845.
> > > > > > > This also touches the Tensor G2 (Exynos9855), Tensor
> > > > > > > G3 (Exynos9865),
> > > > > > > and possibly the "Tesla" SoCs.
> > > > > > > 
> > > > > > > I do not think the Linux kernel should be a marketing material: it
> > > > > > > should reflect reality. The chip is almost 100% composed of Samsung
> > > > > > > Exynos IP blocks and should be called that way.
> > > > > > As you alluded to Tesla fsd and Axis artpec8 SoCs are also based on
> > > > > > Exynos designs and support upstream uses the
> > > > > > axis,artpec8* or tesla,fsd*
> > > > > > compatibles.
> > > > > > 
> > > > > > So using google,gs101 is consistent with the existing upstream naming
> > > > > > scheme, for customized ASICs that were based off a Exynos design. But
> > > > > > it also reflects the reality that this SoC is not a
> > > > > > Exynos9845 as there is
> > > > > > also a lot of Google owned and other third party IP
> > > > > > integrated that is not
> > > > > > found in Exynos9845.
> > > > > A quick question: Do you imply Exynos9845 exists outside of
> > > > > the context
> > > > > of Tensor G1? I used to believe Exynos9845 **is** Tensor G1.
> > > Yes, the gs101 SoC is *not* equivalent to the Exynos9845. Similar to
> > > how Tesla
> > > FSD licenses Exynos IP blocks, gs101 does not only comprise of Exynos IP
> > > blocks. The final design is unique to Google and comprises of
> > > several different
> > > vendor IP blocks (not only Exynos).
> > > 
> > > > > Also, what kind of Google IP are you talking about? I believe only the
> > > > > neural accelerator should be custom-ish.
> > > > > 
> > > > > Additionally, I believe it having or not having Google IP is
> > > > > irrelevant:
> > > > > for example, the new Raspberry Pi 5 Broadcom SoC has a lot of
> > > > > Raspberry's own IP, but it's still called Broadcom as it's the real
> > > > > manufacturer and designer of the chip.
> > > > That's a good argument. Indeed BCM2712 contains "New Raspberry
> > > > Pi-developed ISP".
> > > > https://www.raspberrypi.com/documentation/computers/processors.html
> > > > 
> > > > There aren't many patches but GPU is still called brcm,2712.
> > > > 
> > > > For Tesla FSD, there was discussion and output was not very consisting.
> > > > First, the name itself was used for everything - SoC architecture, one
> > > > given SoC and eventually the board.
> > > > https://lore.kernel.org/all/5ab62673-8d46-ec1d-1c80-696421ab69ca@canonical.com/
> > > > 
> > > > 
> > > > Eventually the last part - board - was renamed to "Evaluation board",
> > > > but I don't know how true or real it is.
> > > > 
> > > > See also:
> > > > "I would argue that if this SoC shares the pinctrl, clock, spi, adc,
> > > > and timer implementation
> > > > with Exynos, we should consider it part of the Exynos family,"
> > > > https://lore.kernel.org/all/CAK8P3a31bCHNcNWrLX+QW+4RuK=DBpxLA_j5BFKxXxXKCT8PFQ@mail.gmail.com/
> > > > 
> > > > 
> > > > However it was also claimed:
> > > > 
> > > > "AFA architecture is concerns both Exynos and FSD has completely
> > > > different architecture (at least at HW level)."
> > > > https://lore.kernel.org/all/07ce01d8091e$9a6fd9c0$cf4f8d40$@samsung.com/
> > > > 
> > > > 
> > > > > > I guess the same is also true for `axis,artpec8` and
> > > > > > `tesla,fsd` SoCs.
> > > > > > IMO the SoC compatible string should be uniquely
> > > > > > identifying the actual
> > > > > > SoC, not a close relative.
> > > > > > 
> > > > > > Regarding product_id you are correct this reads 0x09845000 but even
> > > > > > within Samsung Exynos family there are examples where the register
> > > > > > value does not match the SoC compatible. For example Exynos850 SoC
> > > > > > has a product ID value of "E3830". Where the Linux compatible is
> > > > > > matching the Samsung marketing name, not the internal/outdated name.
> > > > > I did not know Exynos 850 is also not going under it's real name.
> > > > > Ultimately, I believe all of those SoCs should go under
> > > > > their technical
> > > > > name in the exynos/ directory.
> > > > The initial technical name does not exist outside of vendor sources and
> > > > part name. E.g. Winlink E850 board hardware manual calls it:
> > > > "Samsung Exynos 850, S5E3830"
> > > > and everywhere else Exynos 850 SoC is used.
> > > > 
> > > > If you start calling it Exynos 3830, only me and Sam (who mainlined it)
> > > > would know what is it. Everyone else, all users of kernel, would be
> > > > confused.
> > > > 
> > > > Therefore using well known final product name is for Exynos850
> > > > reasonable.
> > > I agree with this. By using the final (well known) product SoC name
> > > -- gs101 --
> > > other developers will be able to easily identify the particular SoC.
> > > 
> > > > > Another concern is that Google could in the future license
> > > > > other SoC: be
> > > > > it Qualcomm, Nvidia or anything. If we put completely
> > > > > different hw under
> > > > > google/ directory, does it really make sense? In that case, who'll
> > > > > maintain the google/ directory? Exynos people? Qualcomm people if they
> > > > > license it? Some other people?
> > > I don't understand why the architecture of the SoC would dictate
> > > which folder
> > > to put the device tree files under. It makes more sense to group
> > > board DT files
> > > together based on who distributes them. Having all the Pixel DT
> > > board files
> > > together allows Google to create a single device tree binary per SoC
> > > coupled
> > > with the set of device tree overlays per board variant (this is the
> > > dtbo.img)
> > > to ship to all their devices. If you look at all the in-market Pixel
> > > devices
> > > with Tensor SoCs, you will find that you could create one dtb
> > > (concatenate
> > > gs101.dtb, gs201.dtb, and zuma.dtb) and one dtbo image for 10
> > > devices which
> > > significantly simplifies the maintenance, testing, and software
> > > distribution
> > > for all 10 of those products.
> > 
> > How is that relevant?
> > 
> > I believe it is none of the kernel concerns, it's up to the user to do
> > whatever with the built .dtb files.
> > 
> > Also I do not see an issue in having a file list of all the .dtbo files
> > you might want.

I think organizing the DT files based on a product is relevant because it makes
it easier to identify what files are associated with the final product(s).
Leaving it up to the user just means you are forcing everyone to roll their own
scripts to re-organize/postprocess the kernel artifacts for their products.
I think it would be nice to be able to configure the kernel build to generate
artifacts that are directly usable on the device.

> > > 
> > > > That's indeed a problem. Future Tesla SoC might have just few pieces
> > > > similar to FSD. There would be no common SoC part, except the actual
> > > > Tesla IP.
> > > > 
> > > > Same for Google. Future GSXXX, if done by Qualcomm, will be absolutely
> > > > different than GS101 and the only common part would be the TPU
> > > > (Tensor).
> > > > 
> > > > So now let's decide what is the common denominator:
> > > > 1. Core SoC architecture, like buses, pinctrl, clocks, timers, serial,
> > > > and many IP blocks, which constitute 95% of Devicetree bindings
> > > > and drivers,
> > > > 2. The one, big piece made by Samsung's customer: TPU, NPU or whatever.
> > > As mentioned above, I think this should be based on how the DTBs and
> > > DTBOs are
> > > used and distributed. What is the benefit of adding the gs101 board
> > > files under
> > > the exynos folder?
> > 
> > One clear benefit would be the ease of maintaining all the SoC files at
> > once. It's not that it is a benefit of having it in the Exynos folder,
> > it's more like that there's no benefit in having a separate folder, and
> > that also comes with some additional issues.
> > 
> > As I said earlier, it's pretty similar to the Raspberry Pi 5 example: It
> > contains Raspberry's in-house IP, but it's still called properly
> > Broadcom. The only difference is that Raspberry does not want its name
> > on the chip, but Google does, despite it being just as custom as the
> > Raspberry SoC is. The company's policy should not be a factor for this
> > decision, in my opinion.
> > 
> > However as you've added, gs101 is the same thing as Exynos9845, so I
> > believe there's no question that the Exynos name should be specified
> > somewhere too, because this is what's literally wired in hardware, and
> > not just a "well-known name that is used by Google in the Pixel factory
> > kernel".
> > 
> > I agree though that just specifying the internal E9845 name could
> > mislead some people, but GS101 is a similarly obscure name, and not even
> > the real name of the hardware.

gs101 is used in the downstream drivers as well as referenced in online
materials referring to Pixel 6 (just search for "Google gs101"). In addition,
gs101 is used by the Android userspace to refer to the SoC that Pixel 6/6
Pro/6a use. The same goes for gs201 and zuma.  So I think it's important to
keep the names consistent. I don't think the Exynos 9845 is ever referenced in
the Android vendor userspace nor is it ever used by tech bloggers/writer/
enthusiast developers when referring to the Pixel 6 device. So if upstream
decides to use the term 9845, they will just be introducing even more
confusion.

I also want to point out that I don't really like the Tensor name either. This
is equivalent to the "Snapdragon" marketing name that is not used either in the
Qualcomm device tree. In my opinion, gs101 is equivant to the "msmXYZ" and
"smXYZ" names, e.g. msm8996 and sm8650.

Thanks,
Will

> > 
> > > 
> > > Thanks,
> > > Will
> > > 
> > > > > Then, I don't think Tensor G3 has a proper "GS" name, it
> > > > > goes by "Zuma"
> > > > > in decompiled kernel modules as far as I see.
> > > > > 
> > > > > Finally, Tesla people already tried to submit drivers called by Tesla
> > > > > name, but which basically copied the functionality of the Exynos
> > > > > drivers. We would want to avoid that, ideally.
> > > > > 
> > > > > My opinion is that all the Tesla and Google SoCs should be in the
> > > > > exynos/ directory, not only because they are basically Samsung Exynos,
> > > > > but also because they don't really need a separate directory: neither
> > > > > Google nor Tesla didn't neither manufacture or design those SoCs from
> > > > > scratch. The only reason I can think of for them to have it in a
> > > > > separate directory is maybe because Google and Tesla actually paid
> > > > > Samsung money for the right to call Exynos "Google designed"
> > > > > SoCs, but I
> > > > > believe the kernel should be left out of that.
> > > > For some reason, although I know which, Cc-list is here trimmed and
> > > > misses Alim...
> > > > 
> > > > So standard reply follow (it makes me really, really grumpy, because it
> > > > means you develop on some crazy old kernel or do not use tools which
> > > > automate the process):
> > > > 
> > > > Please use scripts/get_maintainers.pl to get a list of necessary people
> > > > and lists to CC (and consider --no-git-fallback argument). It might
> > > > happen, that command when run on an older kernel, gives you outdated
> > > > entries. Therefore please be sure you base your patches on recent Linux
> > > > kernel.
> > > > 
> > > > Best regards,
> > > > Krzysztof
> > > > 
> > Yours,
> > 
> > Maksym
> > 
> Yours,
> 
> Maksym
> 

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

RE: [PATCH v2 00/20] Add minimal Tensor/GS101 SoC support and Oriole/Pixel6 board

[Alim Akhtar]

Hi Peter

> -----Original Message-----
> From: Peter Griffin <peter.griffin@linaro.org>
> Sent: Monday, November 6, 2023 6:16 PM
> To: Maksym Holovach <maksym.holovach.an.2022@lpnu.ua>
> Cc: robh+dt@kernel.org; krzysztof.kozlowski+dt@linaro.org;
> mturquette@baylibre.com; conor+dt@kernel.org; sboyd@kernel.org;
> tomasz.figa@gmail.com; s.nawrocki@samsung.com; linus.walleij@linaro.org;
> wim@linux-watchdog.org; linux@roeck-us.net; catalin.marinas@arm.com;
> will@kernel.org; arnd@arndb.de; olof@lixom.net; cw00.choi@samsung.com;
> tudor.ambarus@linaro.org; andre.draszik@linaro.org;
> semen.protsenko@linaro.org; saravanak@google.com;
> willmcvicker@google.com; soc@kernel.org; devicetree@vger.kernel.org;
> linux-arm-kernel@lists.infradead.org; linux-samsung-soc@vger.kernel.org;
> linux-clk@vger.kernel.org; linux-gpio@vger.kernel.org; linux-
> watchdog@vger.kernel.org; kernel-team@android.com; linux-
> serial@vger.kernel.org; Alim Akhtar <alim.akhtar@samsung.com>
> Subject: Re: [PATCH v2 00/20] Add minimal Tensor/GS101 SoC support and
> Oriole/Pixel6 board
> 
> Hi Maksym,
> 
> On Fri, 3 Nov 2023 at 13:56, Maksym Holovach
> <maksym.holovach.an.2022@lpnu.ua> wrote:
> >
> > Hi Peter,
> >
> > On 11/3/23 15:11, Peter Griffin wrote:
> > > Hi Maksym,
> > >
> > > Thanks for your feedback.
> > >
> > > On Thu, 2 Nov 2023 at 22:32, Maksym Holovach
> > > <maksym.holovach.an.2022@lpnu.ua> wrote:
> > >> Hi, all
> > >>
> > >> I wanted to inquire about how do you all feel about calling this
> > >> SoC by the Google "gs101" name.
> > > Interesting question, I think calling it gs101 is the correct
> > > approach see below for my rationale.
> > >
> > >> I believe the proper name for it should be the actual Samsung name,
> > >> written in the silicon and reported in the Chip ID hardware: Exynos9845.
> > >> This also touches the Tensor G2 (Exynos9855), Tensor G3
> > >> (Exynos9865), and possibly the "Tesla" SoCs.
> 
> Also Exynos850 as I pointed out previously. I think that is the wrong approach
> and very confusing. This SoC is not commonly known by anyone as
> Exynos9845.
> 
> The same as the Exynos850 isn't known by anyone apart from Samsung folks
> as Exynos 3830, and the tesla fsd SoC isn't known by whatever internal
> Samsung name that presumably had.
> 
> Maybe Alim can comment what tesla fsd SoC has in the product id register.
> 
FSD does not contain chip_id IP found in Exynos series of SoCs. And it does not follow chip ID naming convention like S5Exxxx etc. 
Chip ID is vendor specific and its depends on SoC owner/vendor how and what they want to embed for the chip identification.

> > >>
> > >> I do not think the Linux kernel should be a marketing material: it
> > >> should reflect reality. The chip is almost 100% composed of Samsung
> > >> Exynos IP blocks and should be called that way.
> 
> Where does this 'almost 100%' number come from? Are you measuring the
> die area here or something else?
> 
> > > As you alluded to Tesla fsd and Axis artpec8 SoCs are also based on
> > > Exynos designs and support upstream uses the axis,artpec8* or
> > > tesla,fsd* compatibles.
> > >
> > > So using google,gs101 is consistent with the existing upstream
> > > naming scheme, for customized ASICs that were based off a Exynos
> > > design. But it also reflects the reality that this SoC is not a
> > > Exynos9845 as there is also a lot of Google owned and other third
> > > party IP integrated that is not found in Exynos9845.
> >
> > A quick question: Do you imply Exynos9845 exists outside of the
> > context of Tensor G1? I used to believe Exynos9845 **is** Tensor G1.
> 
> You are correct. William clarified that point for us. Thanks William!
> 
> >
> > Also, what kind of Google IP are you talking about? I believe only the
> > neural accelerator should be custom-ish.
> 
> This should not be considered an exhaustive list, but whilst looking in the
> downstream public drivers at least the following Google IPs in the SoC
> 
> TPU/ML accelerator
> Bigocean av1 video accelerator
> Emerald hill compression engine
> Camera ISP blocks
> (AoC) Always on Compute
> 
> Plus of course Arm IPs (CPU+GPU), Synopsis IPs (USB, PCI. phys) etc.
> 
> The Exynos based IPs tend to be for things like pinmux, clocks, i2c, spi, uart,
> mfc, display controller, timer etc.
> 
> >
> > Additionally, I believe it having or not having Google IP is irrelevant:
> > for example, the new Raspberry Pi 5 Broadcom SoC has a lot of
> > Raspberry's own IP, but it's still called Broadcom as it's the real
> > manufacturer and designer of the chip.
> 
> I think RPi / Broadcom is a very different situation to this. The original SoC in
> RPi 1 was wholly designed by Broadcom, and marketed as a Broadcom SoC
> [1].
> 
> Further iterations of the SoC until now have also not had RPi IP integrated.
> RPi themselves refer to them as "Broadcom SoCs" on their webpage [2], so it
> is completely expected that they live in a broadcom directory.
> 
> BCM2717 has integrated the RPi ISP, but to all intents and purposes this is a
> Broadcom owned and designed SoC, albeit only now sold to one customer.
> 
> [1] https://protect2.fireeye.com/v1/url?k=da5b6ba0-bb20c137-da5ae0ef-
> 74fe4860001d-7fce4d4e8d7e8af0&q=1&e=b917214e-9ab0-44fd-9dce-
> aa4e41be3905&u=https%3A%2F%2Fweb.archive.org%2Fweb%2F2012021508
> 0023%2Fhttps%3A%2F%2Fwww.broadcom.com%2Fproducts%2FBCM2835
> [2]
> https://www.raspberrypi.com/documentation/computers/processors.html
> 
> > >
> > > I guess the same is also true for `axis,artpec8` and `tesla,fsd` SoCs.
> > > IMO the SoC compatible string should be uniquely identifying the
> > > actual SoC, not a close relative.
> > >
> > > Regarding product_id you are correct this reads 0x09845000 but even
> > > within Samsung Exynos family there are examples where the register
> > > value does not match the SoC compatible. For example Exynos850 SoC
> > > has a product ID value of "E3830". Where the Linux compatible is
> > > matching the Samsung marketing name, not the internal/outdated name.
> >
> > I did not know Exynos 850 is also not going under it's real name.
> 
> It is going by its real name :) just not by its internal name that nobody has
> heard of.
> 
> > Ultimately, I believe all of those SoCs should go under their
> > technical name in the exynos/ directory.
> >
> > Another concern is that Google could in the future license other SoC:
> > be it Qualcomm, Nvidia or anything. If we put completely different hw
> > under google/ directory, does it really make sense? In that case,
> > who'll maintain the google/ directory? Exynos people? Qualcomm people
> > if they license it? Some other people?
> 
> I expect Google, or Google sponsored devs (as is the case for Linaro) to be
> helping maintain the Google SoCs upstream. See the MAINTAINERS entry for
> this series of who I expect to maintain this google directory.
> 
> >
> > Then, I don't think Tensor G3 has a proper "GS" name, it goes by "Zuma"
> > in decompiled kernel modules as far as I see.
> 
> That is correct, it is named Zuma downstream and they did away with the
> gs101, gs201 type naming scheme.
> 
> >
> > Finally, Tesla people already tried to submit drivers called by Tesla
> > name, but which basically copied the functionality of the Exynos
> > drivers. We would want to avoid that, ideally.
> 
> As you can see from this series we are not proposing that. Any IPs that use
> Exynos IP we are using the existing upstream driver and enhance it where
> we have features that aren't present upstream.
> 
> >
> > My opinion is that all the Tesla and Google SoCs should be in the
> > exynos/ directory, not only because they are basically Samsung Exynos,
> > but also because they don't really need a separate directory: neither
> > Google nor Tesla didn't neither manufacture or design those SoCs from
> > scratch.
> 
> Who manufactures it seems irrelevant. Qcom and Broadcom don't
> manufacture their SoCs either, but they still live in qcom and broadcom
> directories upstream. Whether they designed the SoC from scratch or not is
> also IMO largely irrelevant. In many cases the upstream community has no
> way to determine whether things were outsourced or not anyway.
> Did Apple outsource things in their silicon design? Who knows, and why do
> we care? It's an apple branded chip in an apple branded product let's call the
> directory apple.
> 
> Interestingly apple uses the same uart driver as Tensor, when I check back
> through the commits in the driver.
> 
> fcbba344907afe26da487f1ed0b0e285c06a547b
> 
> tty: serial: samsung_tty: Add support for Apple UARTs
> 
> Apple SoCs are a distant descendant of Samsung designs and use yet
> another variant of their UART style, with different interrupt handling.
> 
> 
> > The only reason I can think of for them to have it in a separate
> > directory is maybe because Google and Tesla actually paid Samsung
> > money for the right to call Exynos "Google designed" SoCs, but I
> > believe the kernel should be left out of that.
> 
> Also the fact that they contain IPs not found in Samsung designed devices,
> aren't known to most people as Exynos, and the maintenance issues of
> having all the Google, Tesla, Axis, Exynos based SoCs in the same directory
> (and who knows how many other ASIC customers in the future).
> 
> Ultimately it is Krzysztof's decision I think. I followed what he had previously
> accepted for other SoCs for consistency and also because it seemed like the
> correct approach to help scale up and ease the maintenance burden. If I look
> at the number of tensor based SoCs, phones per SoC and board variants per
> phone model, then you end up having a lot of files in the exynos directory
> over time.
> 
> regards,
> 
> Peter

RE: [PATCH v2 00/20] Add minimal Tensor/GS101 SoC support and Oriole/Pixel6 board

[Alim Akhtar]

Hi Peter

> -----Original Message-----
> From: Peter Griffin <peter.griffin@linaro.org>
> Sent: Monday, November 6, 2023 6:16 PM
> To: Maksym Holovach <maksym.holovach.an.2022@lpnu.ua>
> Cc: robh+dt@kernel.org; krzysztof.kozlowski+dt@linaro.org;
> mturquette@baylibre.com; conor+dt@kernel.org; sboyd@kernel.org;
> tomasz.figa@gmail.com; s.nawrocki@samsung.com; linus.walleij@linaro.org;
> wim@linux-watchdog.org; linux@roeck-us.net; catalin.marinas@arm.com;
> will@kernel.org; arnd@arndb.de; olof@lixom.net; cw00.choi@samsung.com;
> tudor.ambarus@linaro.org; andre.draszik@linaro.org;
> semen.protsenko@linaro.org; saravanak@google.com;
> willmcvicker@google.com; soc@kernel.org; devicetree@vger.kernel.org;
> linux-arm-kernel@lists.infradead.org; linux-samsung-soc@vger.kernel.org;
> linux-clk@vger.kernel.org; linux-gpio@vger.kernel.org; linux-
> watchdog@vger.kernel.org; kernel-team@android.com; linux-
> serial@vger.kernel.org; Alim Akhtar <alim.akhtar@samsung.com>
> Subject: Re: [PATCH v2 00/20] Add minimal Tensor/GS101 SoC support and
> Oriole/Pixel6 board
> 
> Hi Maksym,
> 
> On Fri, 3 Nov 2023 at 13:56, Maksym Holovach
> <maksym.holovach.an.2022@lpnu.ua> wrote:
> >
> > Hi Peter,
> >
> > On 11/3/23 15:11, Peter Griffin wrote:
> > > Hi Maksym,
> > >
> > > Thanks for your feedback.
> > >
> > > On Thu, 2 Nov 2023 at 22:32, Maksym Holovach
> > > <maksym.holovach.an.2022@lpnu.ua> wrote:
> > >> Hi, all
> > >>
> > >> I wanted to inquire about how do you all feel about calling this
> > >> SoC by the Google "gs101" name.
> > > Interesting question, I think calling it gs101 is the correct
> > > approach see below for my rationale.
> > >
> > >> I believe the proper name for it should be the actual Samsung name,
> > >> written in the silicon and reported in the Chip ID hardware: Exynos9845.
> > >> This also touches the Tensor G2 (Exynos9855), Tensor G3
> > >> (Exynos9865), and possibly the "Tesla" SoCs.
> 
> Also Exynos850 as I pointed out previously. I think that is the wrong approach
> and very confusing. This SoC is not commonly known by anyone as
> Exynos9845.
> 
> The same as the Exynos850 isn't known by anyone apart from Samsung folks
> as Exynos 3830, and the tesla fsd SoC isn't known by whatever internal
> Samsung name that presumably had.
> 
> Maybe Alim can comment what tesla fsd SoC has in the product id register.
> 
FSD does not contain chip_id IP found in Exynos series of SoCs. And it does not follow chip ID naming convention like S5Exxxx etc. 
Chip ID is vendor specific and its depends on SoC owner/vendor how and what they want to embed for the chip identification.

> > >>
> > >> I do not think the Linux kernel should be a marketing material: it
> > >> should reflect reality. The chip is almost 100% composed of Samsung
> > >> Exynos IP blocks and should be called that way.
> 
> Where does this 'almost 100%' number come from? Are you measuring the
> die area here or something else?
> 
> > > As you alluded to Tesla fsd and Axis artpec8 SoCs are also based on
> > > Exynos designs and support upstream uses the axis,artpec8* or
> > > tesla,fsd* compatibles.
> > >
> > > So using google,gs101 is consistent with the existing upstream
> > > naming scheme, for customized ASICs that were based off a Exynos
> > > design. But it also reflects the reality that this SoC is not a
> > > Exynos9845 as there is also a lot of Google owned and other third
> > > party IP integrated that is not found in Exynos9845.
> >
> > A quick question: Do you imply Exynos9845 exists outside of the
> > context of Tensor G1? I used to believe Exynos9845 **is** Tensor G1.
> 
> You are correct. William clarified that point for us. Thanks William!
> 
> >
> > Also, what kind of Google IP are you talking about? I believe only the
> > neural accelerator should be custom-ish.
> 
> This should not be considered an exhaustive list, but whilst looking in the
> downstream public drivers at least the following Google IPs in the SoC
> 
> TPU/ML accelerator
> Bigocean av1 video accelerator
> Emerald hill compression engine
> Camera ISP blocks
> (AoC) Always on Compute
> 
> Plus of course Arm IPs (CPU+GPU), Synopsis IPs (USB, PCI. phys) etc.
> 
> The Exynos based IPs tend to be for things like pinmux, clocks, i2c, spi, uart,
> mfc, display controller, timer etc.
> 
> >
> > Additionally, I believe it having or not having Google IP is irrelevant:
> > for example, the new Raspberry Pi 5 Broadcom SoC has a lot of
> > Raspberry's own IP, but it's still called Broadcom as it's the real
> > manufacturer and designer of the chip.
> 
> I think RPi / Broadcom is a very different situation to this. The original SoC in
> RPi 1 was wholly designed by Broadcom, and marketed as a Broadcom SoC
> [1].
> 
> Further iterations of the SoC until now have also not had RPi IP integrated.
> RPi themselves refer to them as "Broadcom SoCs" on their webpage [2], so it
> is completely expected that they live in a broadcom directory.
> 
> BCM2717 has integrated the RPi ISP, but to all intents and purposes this is a
> Broadcom owned and designed SoC, albeit only now sold to one customer.
> 
> [1] https://protect2.fireeye.com/v1/url?k=da5b6ba0-bb20c137-da5ae0ef-
> 74fe4860001d-7fce4d4e8d7e8af0&q=1&e=b917214e-9ab0-44fd-9dce-
> aa4e41be3905&u=https%3A%2F%2Fweb.archive.org%2Fweb%2F2012021508
> 0023%2Fhttps%3A%2F%2Fwww.broadcom.com%2Fproducts%2FBCM2835
> [2]
> https://www.raspberrypi.com/documentation/computers/processors.html
> 
> > >
> > > I guess the same is also true for `axis,artpec8` and `tesla,fsd` SoCs.
> > > IMO the SoC compatible string should be uniquely identifying the
> > > actual SoC, not a close relative.
> > >
> > > Regarding product_id you are correct this reads 0x09845000 but even
> > > within Samsung Exynos family there are examples where the register
> > > value does not match the SoC compatible. For example Exynos850 SoC
> > > has a product ID value of "E3830". Where the Linux compatible is
> > > matching the Samsung marketing name, not the internal/outdated name.
> >
> > I did not know Exynos 850 is also not going under it's real name.
> 
> It is going by its real name :) just not by its internal name that nobody has
> heard of.
> 
> > Ultimately, I believe all of those SoCs should go under their
> > technical name in the exynos/ directory.
> >
> > Another concern is that Google could in the future license other SoC:
> > be it Qualcomm, Nvidia or anything. If we put completely different hw
> > under google/ directory, does it really make sense? In that case,
> > who'll maintain the google/ directory? Exynos people? Qualcomm people
> > if they license it? Some other people?
> 
> I expect Google, or Google sponsored devs (as is the case for Linaro) to be
> helping maintain the Google SoCs upstream. See the MAINTAINERS entry for
> this series of who I expect to maintain this google directory.
> 
> >
> > Then, I don't think Tensor G3 has a proper "GS" name, it goes by "Zuma"
> > in decompiled kernel modules as far as I see.
> 
> That is correct, it is named Zuma downstream and they did away with the
> gs101, gs201 type naming scheme.
> 
> >
> > Finally, Tesla people already tried to submit drivers called by Tesla
> > name, but which basically copied the functionality of the Exynos
> > drivers. We would want to avoid that, ideally.
> 
> As you can see from this series we are not proposing that. Any IPs that use
> Exynos IP we are using the existing upstream driver and enhance it where
> we have features that aren't present upstream.
> 
> >
> > My opinion is that all the Tesla and Google SoCs should be in the
> > exynos/ directory, not only because they are basically Samsung Exynos,
> > but also because they don't really need a separate directory: neither
> > Google nor Tesla didn't neither manufacture or design those SoCs from
> > scratch.
> 
> Who manufactures it seems irrelevant. Qcom and Broadcom don't
> manufacture their SoCs either, but they still live in qcom and broadcom
> directories upstream. Whether they designed the SoC from scratch or not is
> also IMO largely irrelevant. In many cases the upstream community has no
> way to determine whether things were outsourced or not anyway.
> Did Apple outsource things in their silicon design? Who knows, and why do
> we care? It's an apple branded chip in an apple branded product let's call the
> directory apple.
> 
> Interestingly apple uses the same uart driver as Tensor, when I check back
> through the commits in the driver.
> 
> fcbba344907afe26da487f1ed0b0e285c06a547b
> 
> tty: serial: samsung_tty: Add support for Apple UARTs
> 
> Apple SoCs are a distant descendant of Samsung designs and use yet
> another variant of their UART style, with different interrupt handling.
> 
> 
> > The only reason I can think of for them to have it in a separate
> > directory is maybe because Google and Tesla actually paid Samsung
> > money for the right to call Exynos "Google designed" SoCs, but I
> > believe the kernel should be left out of that.
> 
> Also the fact that they contain IPs not found in Samsung designed devices,
> aren't known to most people as Exynos, and the maintenance issues of
> having all the Google, Tesla, Axis, Exynos based SoCs in the same directory
> (and who knows how many other ASIC customers in the future).
> 
> Ultimately it is Krzysztof's decision I think. I followed what he had previously
> accepted for other SoCs for consistency and also because it seemed like the
> correct approach to help scale up and ease the maintenance burden. If I look
> at the number of tensor based SoCs, phones per SoC and board variants per
> phone model, then you end up having a lot of files in the exynos directory
> over time.
> 
> regards,
> 
> Peter


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel