[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <dca9e4c3e2ed61bf25a2d96a82a77e04@manjaro.org>
Date: Tue, 16 Jul 2024 22:11:02 +0200
From: Dragan Simic <dsimic@...jaro.org>
To: Heiko Stübner <heiko@...ech.de>
Cc: mturquette@...libre.com, sboyd@...nel.org, robh@...nel.org,
krzk+dt@...nel.org, conor+dt@...nel.org, linux-clk@...r.kernel.org,
devicetree@...r.kernel.org, linux-kernel@...r.kernel.org,
linux-arm-kernel@...ts.infradead.org, linux-rockchip@...ts.infradead.org
Subject: Re: [PATCH v2 1/3] dt-bindings: clocks: add binding for
voltage-controlled-oscillators
Hello Heiko,
On 2024-07-15 21:13, Heiko Stübner wrote:
> Am Montag, 15. Juli 2024, 20:01:35 CEST schrieb Dragan Simic:
>> On 2024-07-15 19:46, Heiko Stübner wrote:
>> > Am Montag, 15. Juli 2024, 17:15:45 CEST schrieb Dragan Simic:
>> >> On 2024-07-15 13:02, Heiko Stuebner wrote:
>> >> > In contrast to fixed clocks that are described as ungateable, boards
>> >> > sometimes use additional oscillators for things like PCIe reference
>> >> > clocks, that need actual supplies to get enabled and enable-gpios to be
>> >> > toggled for them to work.
>> >> >
>> >> > This adds a binding for such oscillators that are not configurable
>> >> > themself, but need to handle supplies for them to work.
>> >> >
>> >> > In schematics they often can be seen as
>> >> >
>> >> > ----------------
>> >> > Enable - | 100MHz,3.3V, | - VDD
>> >> > | 3225 |
>> >> > GND - | | - OUT
>> >> > ----------------
>> >> >
>> >> > or similar. The enable pin might be separate but can also just be tied
>> >> > to the vdd supply, hence it is optional in the binding.
>> >> >
>> >> > Signed-off-by: Heiko Stuebner <heiko@...ech.de>
>> >> > ---
>> >> > .../bindings/clock/voltage-oscillator.yaml | 49 +++++++++++++++++++
>> >> > 1 file changed, 49 insertions(+)
>> >> > create mode 100644
>> >> > Documentation/devicetree/bindings/clock/voltage-oscillator.yaml
>> >> >
>> >> > diff --git
>> >> > a/Documentation/devicetree/bindings/clock/voltage-oscillator.yaml
>> >> > b/Documentation/devicetree/bindings/clock/voltage-oscillator.yaml
>> >> > new file mode 100644
>> >> > index 0000000000000..8bff6b0fd582e
>> >> > --- /dev/null
>> >> > +++ b/Documentation/devicetree/bindings/clock/voltage-oscillator.yaml
>> >> > @@ -0,0 +1,49 @@
>> >> > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
>> >> > +%YAML 1.2
>> >> > +---
>> >> > +$id: http://devicetree.org/schemas/clock/voltage-oscillator.yaml#
>> >> > +$schema: http://devicetree.org/meta-schemas/core.yaml#
>> >> > +
>> >> > +title: Voltage controlled oscillator
>> >>
>> >> Frankly, I find the "voltage-oscillator" and "voltage controlled
>> >> oscillator" names awkward. In general, "clock" is used throughout
>> >> the entire kernel, when it comes to naming files and defining
>> >> "compatible" strings. Thus, I'd suggest that "clock" is used here
>> >> instead of "oscillator", because it's consistent and shorter.
>> >>
>> >> How about using "gated-clock" for the "compatible" string, and
>> >> "Simple gated clock generator" instead of "voltage controlled
>> >> oscillator"? Besides sounding awkward, "voltage controlled
>> >> oscillator" may suggest that the clock generator can be adjusted
>> >> or programmed somehow by applying the voltage, while it can only
>> >> be enabled or disabled that way, which is by definition clock
>> >> gating. Thus, "gated-clock" and "Simple gated clock generator"
>> >> would fit very well.
>> >
>> > The naming came from Stephen - one of the clock maintainers ;-)
>> > See discussion in v1. Who also described these things as
>> > "voltage-controlled-oscillators".
>> >
>> > And from that discussion I also got the impression we should aim for
>> > more specific naming - especially when talking about dt-bindings, for
>> > this
>> > "usage in the Linux kernel" actually isn't a suitable metric and
>> > "gated-clock" is probably way too generic I think.
>>
>> I see, thanks for the clarification. Though, the generic nature of
>> "gated-clock" as the name may actually make this driver a bit more
>> future-proof, by allowing some other features to be added to it at
>> some point in the future, avoiding that way the need for yet another
>> kernel driver.
>
> you're talking about the driver ... we're in the hardware-binding here.
> Those are two completely different topics ;-) .
>
> Devicetree is always about describing the hardware as best as possible,
> so you don't want too many "generics" there, because we're always
> talking
> about specific ICs soldered to some board.
>
> I also "violated" that in my v1 by grouping in the the Diodes parts,
> which
> as Stephen pointed out are quite different afterall.
I'll make sure to go through the v1 discussion in detail ASAP. After
that, I'll come back with some more thoughts.
Powered by blists - more mailing lists