From: "Heiko Stübner" <heiko@sntech.de>
To: mturquette@baylibre.com, sboyd@kernel.org,
Alexander Stein <alexander.stein@ew.tq-group.com>
Cc: robh@kernel.org, krzk+dt@kernel.org, conor+dt@kernel.org,
quentin.schulz@cherry.de, linux-clk@vger.kernel.org,
devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-rockchip@lists.infradead.org
Subject: Re: [PATCH 1/6] dt-bindings: clocks: add binding for generic clock-generators
Date: Wed, 10 Jul 2024 09:45:17 +0200 [thread overview]
Message-ID: <21244242.0c2gjJ1VT2@diego> (raw)
In-Reply-To: <12478313.O9o76ZdvQC@steina-w>
Hi,
Am Mittwoch, 10. Juli 2024, 09:02:34 CEST schrieb Alexander Stein:
> Am Dienstag, 9. Juli 2024, 14:31:16 CEST schrieb Heiko Stuebner:
> > In contrast to fixed clocks that are described as ungateable, boards
> > sometimes use additional clock generators for things like PCIe reference
> > clocks, that need actual supplies to get enabled and enable-gpios to be
> > toggled for them to work.
>
> Fixed clocks are intended to be ungateable? Where does this come from?
"DOC: basic fixed-rate clock that cannot gate"
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/clk/clk-fixed-rate.c#n18
> > This adds a binding for such clock generators that are not configurable
> > themself, but need to handle supplies for them to work.
> >
> > While in a lot of cases the type of the IC used is described in board
> > schematics, in some cases just a generic type description like
> > "100MHz, 3.3V" might also be used. The binding therefore allows both
> > cases. Specifying the type is of course preferred.
> >
> > The clock-frequency is set in devicetree, because while some clock
> > generators have pins to decide between multipls output rates, those
> > are generally set statically on the board-layout-level.
> >
> > Signed-off-by: Heiko Stuebner <heiko@sntech.de>
> > ---
> > .../bindings/clock/clock-generator.yaml | 62 +++++++++++++++++++
> > 1 file changed, 62 insertions(+)
> > create mode 100644 Documentation/devicetree/bindings/clock/clock-generator.yaml
> >
> > diff --git a/Documentation/devicetree/bindings/clock/clock-generator.yaml b/Documentation/devicetree/bindings/clock/clock-generator.yaml
> > new file mode 100644
> > index 0000000000000..f44e61e414e89
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/clock/clock-generator.yaml
> > @@ -0,0 +1,62 @@
> > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> > +%YAML 1.2
> > +---
> > +$id: http://devicetree.org/schemas/clock/clock-generator.yaml#
> > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > +
> > +title: Simple clock generators
> > +
> > +maintainers:
> > + - Heiko Stuebner <heiko@sntech.de>
> > +
> > +properties:
> > + $nodename:
> > + anyOf:
> > + - description:
> > + Preferred name is 'clock-<freq>' with <freq> being the output
> > + frequency as defined in the 'clock-frequency' property.
> > + pattern: "^clock-([0-9]+|[a-z0-9-]+)$"
> > + - description: Any name allowed
> > + deprecated: true
> > +
> > + compatible:
> > + oneOf:
> > + - const: clock-generator
> > + - items:
> > + - enum:
> > + - diodes,pi6c557-03b
> > + - diodes,pi6c557-05b
> > + - const: clock-generator
> > +
> > + "#clock-cells":
> > + const: 0
> > +
> > + clock-frequency: true
> > +
> > + clock-output-names:
> > + maxItems: 1
> > +
> > + enable-gpios:
> > + description:
> > + Contains a single GPIO specifier for the GPIO that enables and disables
> > + the clock generator.
> > + maxItems: 1
> > +
> > + vdd-supply:
> > + description: handle of the regulator that provides the supply voltage
>
> So essentially only enable-gpios and vdd-supply is added in comparison to
> fixed-clock. Does it make sense to add that to the fixed-clocks instead?
> Similar to fixed-regulator.
I wasn't that sure which way to go in the first place.
The deciding point was reading that line about the fixed clock not
being gateable, so I opted to not touch the fixed-clock.
But you're definitly right, this _could_ live inside the fixed-clock
as well, if we decide to get rid of the not-gateable thing above.
Heiko
WARNING: multiple messages have this Message-ID (diff)
From: "Heiko Stübner" <heiko@sntech.de>
To: mturquette@baylibre.com, sboyd@kernel.org,
Alexander Stein <alexander.stein@ew.tq-group.com>
Cc: robh@kernel.org, krzk+dt@kernel.org, conor+dt@kernel.org,
quentin.schulz@cherry.de, linux-clk@vger.kernel.org,
devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-rockchip@lists.infradead.org
Subject: Re: [PATCH 1/6] dt-bindings: clocks: add binding for generic clock-generators
Date: Wed, 10 Jul 2024 09:45:17 +0200 [thread overview]
Message-ID: <21244242.0c2gjJ1VT2@diego> (raw)
In-Reply-To: <12478313.O9o76ZdvQC@steina-w>
Hi,
Am Mittwoch, 10. Juli 2024, 09:02:34 CEST schrieb Alexander Stein:
> Am Dienstag, 9. Juli 2024, 14:31:16 CEST schrieb Heiko Stuebner:
> > In contrast to fixed clocks that are described as ungateable, boards
> > sometimes use additional clock generators for things like PCIe reference
> > clocks, that need actual supplies to get enabled and enable-gpios to be
> > toggled for them to work.
>
> Fixed clocks are intended to be ungateable? Where does this come from?
"DOC: basic fixed-rate clock that cannot gate"
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/clk/clk-fixed-rate.c#n18
> > This adds a binding for such clock generators that are not configurable
> > themself, but need to handle supplies for them to work.
> >
> > While in a lot of cases the type of the IC used is described in board
> > schematics, in some cases just a generic type description like
> > "100MHz, 3.3V" might also be used. The binding therefore allows both
> > cases. Specifying the type is of course preferred.
> >
> > The clock-frequency is set in devicetree, because while some clock
> > generators have pins to decide between multipls output rates, those
> > are generally set statically on the board-layout-level.
> >
> > Signed-off-by: Heiko Stuebner <heiko@sntech.de>
> > ---
> > .../bindings/clock/clock-generator.yaml | 62 +++++++++++++++++++
> > 1 file changed, 62 insertions(+)
> > create mode 100644 Documentation/devicetree/bindings/clock/clock-generator.yaml
> >
> > diff --git a/Documentation/devicetree/bindings/clock/clock-generator.yaml b/Documentation/devicetree/bindings/clock/clock-generator.yaml
> > new file mode 100644
> > index 0000000000000..f44e61e414e89
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/clock/clock-generator.yaml
> > @@ -0,0 +1,62 @@
> > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> > +%YAML 1.2
> > +---
> > +$id: http://devicetree.org/schemas/clock/clock-generator.yaml#
> > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > +
> > +title: Simple clock generators
> > +
> > +maintainers:
> > + - Heiko Stuebner <heiko@sntech.de>
> > +
> > +properties:
> > + $nodename:
> > + anyOf:
> > + - description:
> > + Preferred name is 'clock-<freq>' with <freq> being the output
> > + frequency as defined in the 'clock-frequency' property.
> > + pattern: "^clock-([0-9]+|[a-z0-9-]+)$"
> > + - description: Any name allowed
> > + deprecated: true
> > +
> > + compatible:
> > + oneOf:
> > + - const: clock-generator
> > + - items:
> > + - enum:
> > + - diodes,pi6c557-03b
> > + - diodes,pi6c557-05b
> > + - const: clock-generator
> > +
> > + "#clock-cells":
> > + const: 0
> > +
> > + clock-frequency: true
> > +
> > + clock-output-names:
> > + maxItems: 1
> > +
> > + enable-gpios:
> > + description:
> > + Contains a single GPIO specifier for the GPIO that enables and disables
> > + the clock generator.
> > + maxItems: 1
> > +
> > + vdd-supply:
> > + description: handle of the regulator that provides the supply voltage
>
> So essentially only enable-gpios and vdd-supply is added in comparison to
> fixed-clock. Does it make sense to add that to the fixed-clocks instead?
> Similar to fixed-regulator.
I wasn't that sure which way to go in the first place.
The deciding point was reading that line about the fixed clock not
being gateable, so I opted to not touch the fixed-clock.
But you're definitly right, this _could_ live inside the fixed-clock
as well, if we decide to get rid of the not-gateable thing above.
Heiko
_______________________________________________
Linux-rockchip mailing list
Linux-rockchip@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-rockchip
next prev parent reply other threads:[~2024-07-10 7:45 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-07-09 12:31 [PATCH 0/6] Binding and driver for "dumb" clock generators Heiko Stuebner
2024-07-09 12:31 ` Heiko Stuebner
2024-07-09 12:31 ` [PATCH 1/6] dt-bindings: clocks: add binding for generic clock-generators Heiko Stuebner
2024-07-09 12:31 ` Heiko Stuebner
2024-07-09 21:45 ` Stephen Boyd
2024-07-09 21:45 ` Stephen Boyd
2024-07-10 8:02 ` Heiko Stübner
2024-07-10 8:02 ` Heiko Stübner
2024-07-10 23:56 ` Stephen Boyd
2024-07-10 23:56 ` Stephen Boyd
2024-07-10 7:02 ` Alexander Stein
2024-07-10 7:02 ` Alexander Stein
2024-07-10 7:45 ` Heiko Stübner [this message]
2024-07-10 7:45 ` Heiko Stübner
2024-07-10 23:21 ` Stephen Boyd
2024-07-10 23:21 ` Stephen Boyd
2024-07-11 5:27 ` Alexander Stein
2024-07-11 5:27 ` Alexander Stein
2024-07-15 10:59 ` Heiko Stübner
2024-07-15 10:59 ` Heiko Stübner
2024-07-09 12:31 ` [PATCH 2/6] clk: add driver for generic clock generators Heiko Stuebner
2024-07-09 12:31 ` Heiko Stuebner
2024-07-09 12:31 ` [PATCH 3/6] arm64: dts: rockchip: fix the pcie clock generator on Rock 5 ITX Heiko Stuebner
2024-07-09 12:31 ` Heiko Stuebner
2024-07-09 12:31 ` [PATCH 4/6] arm64: dts: rockchip: use clock-generator for pcie-refclk on rk3588-jaguar Heiko Stuebner
2024-07-09 12:31 ` Heiko Stuebner
2024-07-09 12:31 ` [PATCH 5/6] arm64: dts: rockchip: use clock-generator for pcie-refclk on rk3588-tiger Heiko Stuebner
2024-07-09 12:31 ` Heiko Stuebner
2024-07-09 12:31 ` [PATCH 6/6] arm64: dts: rockchip: add pinctrl for clk-generator gpio " Heiko Stuebner
2024-07-09 12:31 ` Heiko Stuebner
2024-07-10 3:02 ` [PATCH 0/6] Binding and driver for "dumb" clock generators Anand Moon
2024-07-10 3:02 ` Anand Moon
2024-07-10 7:50 ` Heiko Stübner
2024-07-10 7:50 ` Heiko Stübner
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=21244242.0c2gjJ1VT2@diego \
--to=heiko@sntech.de \
--cc=alexander.stein@ew.tq-group.com \
--cc=conor+dt@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=krzk+dt@kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-clk@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-rockchip@lists.infradead.org \
--cc=mturquette@baylibre.com \
--cc=quentin.schulz@cherry.de \
--cc=robh@kernel.org \
--cc=sboyd@kernel.org \
/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.