All of lore.kernel.org
 help / color / mirror / Atom feed
From: Rob Herring <robh@kernel.org>
To: Andreas Kemnade <andreas@kemnade.info>
Cc: Michael Turquette <mturquette@baylibre.com>,
	Krzysztof Kozlowski <krzk+dt@kernel.org>,
	linux-kernel@vger.kernel.org, linux-clk@vger.kernel.org,
	linux-omap@vger.kernel.org, Tero Kristo <kristo@kernel.org>,
	Tony Lindgren <tony@atomide.com>,
	Conor Dooley <conor+dt@kernel.org>,
	Stephen Boyd <sboyd@kernel.org>,
	devicetree@vger.kernel.org
Subject: Re: [PATCH] dt-bindings: clock: ti: Convert mux.txt to json-schema
Date: Tue, 5 Nov 2024 07:52:34 -0600	[thread overview]
Message-ID: <20241105135234.GA3100411-robh@kernel.org> (raw)
In-Reply-To: <20241104135549.38486-1-andreas@kemnade.info>

On Mon, Nov 04, 2024 at 02:55:49PM +0100, Andreas Kemnade wrote:
> Convert the OMAP mux clock device tree binding to json-schema.
> Specify the creator of the original binding as a maintainer.
> Choose GPL-only license because original binding was also GPL.
> 
> Signed-off-by: Andreas Kemnade <andreas@kemnade.info>
> ---
>  .../bindings/clock/ti/composite.txt           |   2 +-
>  .../devicetree/bindings/clock/ti/mux.txt      |  78 -----------
>  .../bindings/clock/ti/ti,mux-clock.yaml       | 123 ++++++++++++++++++
>  3 files changed, 124 insertions(+), 79 deletions(-)
>  delete mode 100644 Documentation/devicetree/bindings/clock/ti/mux.txt
>  create mode 100644 Documentation/devicetree/bindings/clock/ti/ti,mux-clock.yaml
> 
> diff --git a/Documentation/devicetree/bindings/clock/ti/composite.txt b/Documentation/devicetree/bindings/clock/ti/composite.txt
> index b02f22490dcb..238e6f7d74f8 100644
> --- a/Documentation/devicetree/bindings/clock/ti/composite.txt
> +++ b/Documentation/devicetree/bindings/clock/ti/composite.txt
> @@ -16,7 +16,7 @@ merged to this clock. The component clocks shall be of one of the
>  "ti,*composite*-clock" types.
>  
>  [1] Documentation/devicetree/bindings/clock/clock-bindings.txt
> -[2] Documentation/devicetree/bindings/clock/ti/mux.txt
> +[2] Documentation/devicetree/bindings/clock/ti/ti,mux-clock.yaml
>  [3] Documentation/devicetree/bindings/clock/ti/ti,divider-clock.yaml
>  [4] Documentation/devicetree/bindings/clock/ti/gate.txt
>  
> diff --git a/Documentation/devicetree/bindings/clock/ti/mux.txt b/Documentation/devicetree/bindings/clock/ti/mux.txt
> deleted file mode 100644
> index cd56d3c1c09f..000000000000
> --- a/Documentation/devicetree/bindings/clock/ti/mux.txt
> +++ /dev/null
> @@ -1,78 +0,0 @@
> -Binding for TI mux clock.
> -
> -This binding uses the common clock binding[1].  It assumes a
> -register-mapped multiplexer with multiple input clock signals or
> -parents, one of which can be selected as output.  This clock does not
> -gate or adjust the parent rate via a divider or multiplier.
> -
> -By default the "clocks" property lists the parents in the same order
> -as they are programmed into the register.  E.g:
> -
> -	clocks = <&foo_clock>, <&bar_clock>, <&baz_clock>;
> -
> -results in programming the register as follows:
> -
> -register value		selected parent clock
> -0			foo_clock
> -1			bar_clock
> -2			baz_clock
> -
> -Some clock controller IPs do not allow a value of zero to be programmed
> -into the register, instead indexing begins at 1.  The optional property
> -"index-starts-at-one" modified the scheme as follows:
> -
> -register value		selected clock parent
> -1			foo_clock
> -2			bar_clock
> -3			baz_clock
> -
> -The binding must provide the register to control the mux. Optionally
> -the number of bits to shift the control field in the register can be
> -supplied. If the shift value is missing it is the same as supplying
> -a zero shift.
> -
> -[1] Documentation/devicetree/bindings/clock/clock-bindings.txt
> -
> -Required properties:
> -- compatible : shall be "ti,mux-clock" or "ti,composite-mux-clock".
> -- #clock-cells : from common clock binding; shall be set to 0.
> -- clocks : link phandles of parent clocks
> -- reg : register offset for register controlling adjustable mux
> -
> -Optional properties:
> -- clock-output-names : from common clock binding.
> -- ti,bit-shift : number of bits to shift the bit-mask, defaults to
> -  0 if not present
> -- ti,index-starts-at-one : valid input select programming starts at 1, not
> -  zero
> -- ti,set-rate-parent : clk_set_rate is propagated to parent clock,
> -  not supported by the composite-mux-clock subtype
> -- ti,latch-bit : latch the mux value to HW, only needed if the register
> -  access requires this. As an example, dra7x DPLL_GMAC H14 muxing
> -  implements such behavior.
> -
> -Examples:
> -
> -sys_clkin_ck: sys_clkin_ck@4a306110 {
> -	#clock-cells = <0>;
> -	compatible = "ti,mux-clock";
> -	clocks = <&virt_12000000_ck>, <&virt_13000000_ck>, <&virt_16800000_ck>, <&virt_19200000_ck>, <&virt_26000000_ck>, <&virt_27000000_ck>, <&virt_38400000_ck>;
> -	reg = <0x0110>;
> -	ti,index-starts-at-one;
> -};
> -
> -abe_dpll_bypass_clk_mux_ck: abe_dpll_bypass_clk_mux_ck@4a306108 {
> -	#clock-cells = <0>;
> -	compatible = "ti,mux-clock";
> -	clocks = <&sys_clkin_ck>, <&sys_32k_ck>;
> -	ti,bit-shift = <24>;
> -	reg = <0x0108>;
> -};
> -
> -mcbsp5_mux_fck: mcbsp5_mux_fck {
> -	#clock-cells = <0>;
> -	compatible = "ti,composite-mux-clock";
> -	clocks = <&core_96m_fck>, <&mcbsp_clks>;
> -	ti,bit-shift = <4>;
> -	reg = <0x02d8>;
> -};
> diff --git a/Documentation/devicetree/bindings/clock/ti/ti,mux-clock.yaml b/Documentation/devicetree/bindings/clock/ti/ti,mux-clock.yaml
> new file mode 100644
> index 000000000000..b271ab86dde1
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/clock/ti/ti,mux-clock.yaml
> @@ -0,0 +1,123 @@
> +# SPDX-License-Identifier: GPL-2.0-only

Surely TI as the only author of the original binding would agree to
dual-license this?

> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/clock/ti/ti,mux-clock.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Texas Instruments mux clock
> +
> +maintainers:
> +  - Tero Kristo <kristo@kernel.org>
> +
> +description: |
> +  This clock assumes a register-mapped multiplexer with multiple inpt clock
> +  signals or parents, one of which can be selected as output. This clock does
> +  not gate or adjust the parent rate via a divider or multiplier.
> +
> +  By default the "clocks" property lists the parents in the same order
> +  as they are programmed into the register.  E.g:
> +
> +    clocks = <&foo_clock>, <&bar_clock>, <&baz_clock>;
> +
> +  results in programming the register as follows:

Results

> +
> +  register value   selected parent clock
> +  0                foo_clock
> +  1                bar_clock
> +  2                baz_clock
> +
> +  Some clock controller IPs do not allow a value of zero to be programmed
> +  into the register, instead indexing begins at 1.  The optional property
> +  "index-starts-at-one" modified the scheme as follows:
> +
> +  register value   selected clock parent
> +  1                foo_clock
> +  2                bar_clock
> +  3                baz_clock
> +
> +  The binding must provide the register to control the mux. Optionally
> +  the number of bits to shift the control field in the register can be
> +  supplied. If the shift value is missing it is the same as supplying
> +  a zero shift.
> +
> +properties:
> +  compatible:
> +    enum:
> +      - ti,mux-clock
> +      - ti,composite-mux-clock
> +
> +  "#clock-cells":
> +    const: 0
> +
> +  clocks: true
> +
> +  clock-output-names:
> +    maxItems: 1
> +
> +  reg:
> +    maxItems: 1
> +
> +  ti,bit-shift:
> +    $ref: /schemas/types.yaml#/definitions/uint32
> +    description:
> +      number of bits to shift the bit-mask, defaults to 0 if not present

Number

And on all the other descriptions...

No need to say in prose what the constraints say. So drop "defaults to 0 
if not present".

> +    maximum: 31
> +    default: 0
> +
> +  ti,index-starts-at-one:
> +    type: boolean
> +    description:
> +      valid input select programming starts at 1, not zero
> +
> +  ti,set-rate-parent:
> +    type: boolean
> +    description:
> +      clk_set_rate is propagated to parent clock,
> +      not supported by the composite-mux-clock subtype.

blank line.

> +  ti,latch-bit:
> +    $ref: /schemas/types.yaml#/definitions/uint32
> +    description:
> +      latch the mux value to HW, only needed if the register
> +      access requires this. As an example, dra7x DPLL_GMAC H14 muxing
> +      implements such behavior.

Constraints?

> +
> +if:
> +  properties:
> +    compatible:
> +      contains:
> +        const: ti,composite-mux-clock
> +then:
> +  properties:
> +    ti,set-rate-parent: false
> +
> +required:
> +  - compatible
> +  - "#clock-cells"
> +  - clocks
> +  - reg
> +
> +additionalProperties: false
> +
> +examples:
> +  - |
> +    bus {
> +      #address-cells = <1>;
> +      #size-cells = <0>;
> +
> +      clock-controller@110 {
> +        #clock-cells = <0>;
> +        compatible = "ti,mux-clock";
> +        clocks = <&virt_12000000_ck>, <&virt_13000000_ck>, <&virt_16800000_ck>;
> +        reg = <0x0110>;
> +        ti,index-starts-at-one;
> +        ti,set-rate-parent;
> +      };
> +
> +      clock-controller@120 {

Wrong unit-address.

> +        #clock-cells = <0>;
> +        compatible = "ti,composite-mux-clock";
> +        clocks = <&core_96m_fck>, <&mcbsp_clks>;
> +        ti,bit-shift = <4>;
> +        reg = <0x02d8>;
> +      };
> +    };
> -- 
> 2.39.5
> 

  reply	other threads:[~2024-11-05 13:52 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-11-04 13:55 [PATCH] dt-bindings: clock: ti: Convert mux.txt to json-schema Andreas Kemnade
2024-11-05 13:52 ` Rob Herring [this message]
2024-11-07  6:58   ` Andreas Kemnade
2024-11-08 13:03     ` Roger Quadros
2024-11-08 14:48       ` Nishanth Menon
2024-11-08 15:15         ` Rob Herring
  -- strict thread matches above, loose matches on Subject: below --
2024-11-07  8:54 kernel test robot

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20241105135234.GA3100411-robh@kernel.org \
    --to=robh@kernel.org \
    --cc=andreas@kemnade.info \
    --cc=conor+dt@kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=kristo@kernel.org \
    --cc=krzk+dt@kernel.org \
    --cc=linux-clk@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-omap@vger.kernel.org \
    --cc=mturquette@baylibre.com \
    --cc=sboyd@kernel.org \
    --cc=tony@atomide.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.