Commit 522ba450 authored by Linus Torvalds's avatar Linus Torvalds
Browse files
Pull clk updates from Stephen Boyd:
 "There's a bunch of patches here across drivers/clk/ to migrate drivers
  to use struct clk_ops::determine_rate() instead of the round_rate()
  one so that we can remove the round_rate clk_op entirely. Brian has
  taken up that task which nobody else has wanted to do for close to a
  decade. Thanks Brian!

  This is all prerequisite work to get to the real task of improving the
  clk rate setting process. Once we have determine_rate() used
  everywhere, we'll be able to do things like chain the rate request
  structs in linked lists to order the rate setting operations or add
  more parameters without having to change every clk driver in
  existence. It's also nice to not have multiple ways to do something
  which just causes confusion for clk driver authors. Overall I'm glad
  this is getting done.

  Beyond this change we also have a tweak to the clk_lookup() function
  in the core framework to use hashing on the clk name instead of a clk
  tree walk with string comparisons. We _still_ rely on the clk name to
  be unique, because historically we've used globally unique strings to
  describe the clk tree topology. This tree walk becomes increasingly
  slow as more clks are added to the system. Searching from the roots
  for a duplicate is simple but pretty dumb and it wastes boot time so
  we're using a hash table as an improvement. Ideally we wouldn't rely
  on the strings to be unique at all, relegating them to simply debug
  information, but that is future work that will likely require some
  sort of Kconfig knob indicating strings aren't used for topology
  description.

  Outside of the core framework changes we have the usual new SoC
  support and fixes to clk drivers for things that were discovered once
  the clks were used by consumer drivers. Nothing in particular is
  jumping out at me in the "misc" pile, except maybe the Amlogic driver
  that has gone through a refactoring. That series got a fix from
  testing in -next though so it seems likely that things have been
  getting good test coverage for a couple weeks already"

* tag 'clk-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/clk/linux: (299 commits)
  clk: microchip: core: remove duplicate roclk_determine_rate()
  reset: aspeed: register AST2700 reset auxiliary bus device
  dt-bindings: clock: ast2700: modify soc0/1 clock define
  clk: tegra: do not overallocate memory for bpmp clocks
  clk: ep93xx: Use int type to store negative error codes
  clk: nxp: Fix pll0 rate check condition in LPC18xx CGU driver
  clk: loongson2: Add clock definitions for Loongson-2K0300 SoC
  clk: loongson2: Avoid hardcoding firmware name of the reference clock
  clk: loongson2: Allow zero divisors for dividers
  clk: loongson2: Support scale clocks with an alternative mode
  clk: loongson2: Allow specifying clock flags for gate clock
  dt-bindings: clock: loongson2: Add Loongson-2K0300 compatible
  clk: clocking-wizard: Fix output clock register offset for Versal platforms
  clk: xilinx: Optimize divisor search in clk_wzrd_get_divisors_ver()
  clk: mmp: pxa1908: Instantiate power driver through auxiliary bus
  clk: s2mps11: add support for S2MPG10 PMIC clock
  dt-bindings: clock: samsung,s2mps11: add s2mpg10
  dt-bindings: stm32: cosmetic fixes for STM32MP25 clock and reset bindings
  clk: stm32: introduce clocks for STM32MP21 platform
  dt-bindings: stm32: add STM32MP21 clocks and reset bindings
  ...
parents 971199ad 112104e2
Loading
Loading
Loading
Loading
+4 −0
Original line number Diff line number Diff line
@@ -42,6 +42,9 @@ properties:
          - const: clkin2
          - const: s_axi_aclk

  clock-output-names:
    maxItems: 1

  '#clock-cells':
    const: 0

@@ -65,4 +68,5 @@ examples:
      reg = <0xff000000 0x1000>;
      clocks = <&osc 1>, <&clkc 15>;
      clock-names = "clkin1", "s_axi_aclk";
      clock-output-names = "spi_sclk";
    };
+0 −26
Original line number Diff line number Diff line
Fujitsu CRG11 clock driver bindings
-----------------------------------

Required properties :
- compatible : Shall contain "fujitsu,mb86s70-crg11"
- #clock-cells : Shall be 3 {cntrlr domain port}

The consumer specifies the desired clock pointing to its phandle.

Example:

	clock: crg11 {
		compatible = "fujitsu,mb86s70-crg11";
		#clock-cells = <3>;
	};

	mhu: mhu0@2b1f0000 {
		#mbox-cells = <1>;
		compatible = "arm,mhu";
		reg = <0 0x2B1F0000 0x1000>;
		interrupts = <0 36 4>, /* LP Non-Sec */
			     <0 35 4>, /* HP Non-Sec */
			     <0 37 4>; /* Secure */
		clocks = <&clock 0 2 1>; /* Cntrlr:0 Domain:2 Port:1 */
		clock-names = "clk";
	};
+15 −3
Original line number Diff line number Diff line
@@ -16,6 +16,7 @@ description: |
properties:
  compatible:
    enum:
      - loongson,ls2k0300-clk
      - loongson,ls2k0500-clk
      - loongson,ls2k-clk  # This is for Loongson-2K1000
      - loongson,ls2k2000-clk
@@ -24,8 +25,7 @@ properties:
    maxItems: 1

  clocks:
    items:
      - description: 100m ref
    maxItems: 1

  clock-names:
    items:
@@ -38,11 +38,23 @@ properties:
      ID in its "clocks" phandle cell. See include/dt-bindings/clock/loongson,ls2k-clk.h
      for the full list of Loongson-2 SoC clock IDs.

allOf:
  - if:
      properties:
        compatible:
          contains:
            const: loongson,ls2k0300-clk
    then:
      properties:
        clock-names: false
    else:
      required:
        - clock-names

required:
  - compatible
  - reg
  - clocks
  - clock-names
  - '#clock-cells'

additionalProperties: false
+112 −0
Original line number Diff line number Diff line
# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/clock/mediatek,mt8196-clock.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#

title: MediaTek Functional Clock Controller for MT8196

maintainers:
  - Guangjie Song <guangjie.song@mediatek.com>
  - Laura Nao <laura.nao@collabora.com>

description: |
  The clock architecture in MediaTek SoCs is structured like below:
  PLLs -->
          dividers -->
                      muxes
                           -->
                              clock gate

  The device nodes provide clock gate control in different IP blocks.

properties:
  compatible:
    items:
      - enum:
          - mediatek,mt8196-imp-iic-wrap-c
          - mediatek,mt8196-imp-iic-wrap-e
          - mediatek,mt8196-imp-iic-wrap-n
          - mediatek,mt8196-imp-iic-wrap-w
          - mediatek,mt8196-mdpsys0
          - mediatek,mt8196-mdpsys1
          - mediatek,mt8196-pericfg-ao
          - mediatek,mt8196-pextp0cfg-ao
          - mediatek,mt8196-pextp1cfg-ao
          - mediatek,mt8196-ufscfg-ao
          - mediatek,mt8196-vencsys
          - mediatek,mt8196-vencsys-c1
          - mediatek,mt8196-vencsys-c2
          - mediatek,mt8196-vdecsys
          - mediatek,mt8196-vdecsys-soc
          - mediatek,mt8196-vdisp-ao
      - const: syscon

  reg:
    maxItems: 1

  '#clock-cells':
    const: 1

  '#reset-cells':
    const: 1
    description:
      Reset lines for PEXTP0/1 and UFS blocks.

  mediatek,hardware-voter:
    $ref: /schemas/types.yaml#/definitions/phandle
    description: |
      Phandle to the "Hardware Voter" (HWV), as named in the vendor
      documentation for MT8196/MT6991.

      The HWV is a SoC-internal fixed-function MCU used to collect votes from
      both the Application Processor and other remote processors within the SoC.
      It is intended to transparently enable or disable hardware resources (such
      as power domains or clocks) based on internal vote aggregation handled by
      the MCU's internal state machine.

      However, in practice, this design is incomplete. While the HWV performs
      some internal vote aggregation,software is still required to
      - Manually enable power supplies externally, if present and if required
      - Manually enable parent clocks via direct MMIO writes to clock controllers
      - Enable the FENC after the clock has been ungated via direct MMIO
      writes to clock controllers

      As such, the HWV behaves more like a hardware-managed clock reference
      counter than a true voter. Furthermore, it is not a separate
      controller. It merely serves as an alternative interface to the same
      underlying clock or power controller. Actual control still requires
      direct access to the controller's own MMIO register space, in
      addition to writing to the HWV's MMIO region.

      For this reason, a custom phandle is used here - drivers need to directly
      access the HWV MMIO region in a syscon-like fashion, due to how the
      hardware is wired. This differs from true hardware voting systems, which
      typically do not require custom phandles and rely instead on generic APIs
      (clocks, power domains, interconnects).

      The name "hardware-voter" is retained to match vendor documentation, but
      this should not be reused or misunderstood as a proper voting mechanism.

required:
  - compatible
  - reg
  - '#clock-cells'

additionalProperties: false

examples:
  - |
    pericfg_ao: clock-controller@16640000 {
        compatible = "mediatek,mt8196-pericfg-ao", "syscon";
        reg = <0x16640000 0x1000>;
        mediatek,hardware-voter = <&scp_hwv>;
        #clock-cells = <1>;
    };
  - |
    pextp0cfg_ao: clock-controller@169b0000 {
        compatible = "mediatek,mt8196-pextp0cfg-ao", "syscon";
        reg = <0x169b0000 0x1000>;
        #clock-cells = <1>;
        #reset-cells = <1>;
    };
+107 −0
Original line number Diff line number Diff line
# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/clock/mediatek,mt8196-sys-clock.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#

title: MediaTek System Clock Controller for MT8196

maintainers:
  - Guangjie Song <guangjie.song@mediatek.com>
  - Laura Nao <laura.nao@collabora.com>

description: |
  The clock architecture in MediaTek SoCs is structured like below:
  PLLs -->
          dividers -->
                      muxes
                           -->
                              clock gate

  The apmixedsys, apmixedsys_gp2, vlpckgen, armpll, ccipll, mfgpll and ptppll
  provide most of the PLLs which are generated from the SoC's 26MHZ crystal oscillator.
  The topckgen, topckgen_gp2 and vlpckgen provide dividers and muxes which
  provide the clock source to other IP blocks.

properties:
  compatible:
    items:
      - enum:
          - mediatek,mt8196-apmixedsys
          - mediatek,mt8196-armpll-b-pll-ctrl
          - mediatek,mt8196-armpll-bl-pll-ctrl
          - mediatek,mt8196-armpll-ll-pll-ctrl
          - mediatek,mt8196-apmixedsys-gp2
          - mediatek,mt8196-ccipll-pll-ctrl
          - mediatek,mt8196-mfgpll-pll-ctrl
          - mediatek,mt8196-mfgpll-sc0-pll-ctrl
          - mediatek,mt8196-mfgpll-sc1-pll-ctrl
          - mediatek,mt8196-ptppll-pll-ctrl
          - mediatek,mt8196-topckgen
          - mediatek,mt8196-topckgen-gp2
          - mediatek,mt8196-vlpckgen
      - const: syscon

  reg:
    maxItems: 1

  '#clock-cells':
    const: 1

  mediatek,hardware-voter:
    $ref: /schemas/types.yaml#/definitions/phandle
    description: |
      Phandle to the "Hardware Voter" (HWV), as named in the vendor
      documentation for MT8196/MT6991.

      The HWV is a SoC-internal fixed-function MCU used to collect votes from
      both the Application Processor and other remote processors within the SoC.
      It is intended to transparently enable or disable hardware resources (such
      as power domains or clocks) based on internal vote aggregation handled by
      the MCU's internal state machine.

      However, in practice, this design is incomplete. While the HWV performs
      some internal vote aggregation,software is still required to
      - Manually enable power supplies externally, if present and if required
      - Manually enable parent clocks via direct MMIO writes to clock controllers
      - Enable the FENC after the clock has been ungated via direct MMIO
      writes to clock controllers

      As such, the HWV behaves more like a hardware-managed clock reference
      counter than a true voter. Furthermore, it is not a separate
      controller. It merely serves as an alternative interface to the same
      underlying clock or power controller. Actual control still requires
      direct access to the controller's own MMIO register space, in
      addition to writing to the HWV's MMIO region.

      For this reason, a custom phandle is used here - drivers need to directly
      access the HWV MMIO region in a syscon-like fashion, due to how the
      hardware is wired. This differs from true hardware voting systems, which
      typically do not require custom phandles and rely instead on generic APIs
      (clocks, power domains, interconnects).

      The name "hardware-voter" is retained to match vendor documentation, but
      this should not be reused or misunderstood as a proper voting mechanism.

required:
  - compatible
  - reg
  - '#clock-cells'

additionalProperties: false

examples:
  - |
    apmixedsys_clk: syscon@10000800 {
        compatible = "mediatek,mt8196-apmixedsys", "syscon";
        reg = <0x10000800 0x1000>;
        #clock-cells = <1>;
    };
  - |
    topckgen: syscon@10000000 {
        compatible = "mediatek,mt8196-topckgen", "syscon";
        reg = <0x10000000 0x800>;
        mediatek,hardware-voter = <&scp_hwv>;
        #clock-cells = <1>;
    };
Loading