Hey Mike, I have no comments about whether this is a good idea or not, I'll leave that Stephen, Krzysztof etc.. On Fri, May 26, 2023 at 04:38:06PM +0200, Mike Looijmans wrote: > Add bindings for a fixed-rate clock that retrieves its rate from an > NVMEM provider. This allows to store clock settings in EEPROM or EFUSE > or similar device. > > Component shortages lead to boards being shipped with different clock > crystals, based on what was available at the time. The clock frequency > was written to EEPROM at production time. Systems can adapt to a wide > range of input frequencies using the clock framework, but this required > us to patch the devicetree at runtime or use some custom driver. This > provides a more generic solution. > > Signed-off-by: Mike Looijmans <mike.looijmans@xxxxxxxx> > > --- > > Changes in v2: > Changed "fixed-clock" into "nvmem-clock" in dts example > Add minItems:1 to nvmem-cell-names > > .../bindings/clock/nvmem-clock.yaml | 63 +++++++++++++++++++ > 1 file changed, 63 insertions(+) > create mode 100644 Documentation/devicetree/bindings/clock/nvmem-clock.yaml > > diff --git a/Documentation/devicetree/bindings/clock/nvmem-clock.yaml b/Documentation/devicetree/bindings/clock/nvmem-clock.yaml > new file mode 100644 > index 000000000000..af96a5e9372d > --- /dev/null > +++ b/Documentation/devicetree/bindings/clock/nvmem-clock.yaml > @@ -0,0 +1,63 @@ > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) > +%YAML 1.2 > +--- > +$id: http://devicetree.org/schemas/clock/nvmem-clock.yaml# > +$schema: http://devicetree.org/meta-schemas/core.yaml# > + > +title: Simple fixed-rate clock source from NVMEM > + > +maintainers: > + - Mike Looijmans <mike.looijmans@xxxxxxxx> > + > +description: > + Provides a clock rate from NVMEM. Typical usage is that the factory places a > + crystal on the board and writes the rate into an EEPROM or EFUSE. If some math > + is required, one can add a fixed-factor clock using this clock as input. > + > +properties: > + compatible: > + const: nvmem-clock > + > + "#clock-cells": > + const: 0 > + > + nvmem-cells: > + minItems: 1 > + maxItems: 2 > + description: > + Reads clock-frequency and optionally clock-accuracy from an NVMEM provider > + in binary native integer format. The size of the NVMEM cell can be 1, 2, 4 > + or 8 bytes. How is that size communicated to the driver? Some nvmem magic just takes care of it? > + > + nvmem-cell-names: > + minItems: 1 > + items: > + - const: clock-frequency > + - const: clock-accuracy > + > + clock-accuracy: I think the common pattern is to add a unit suffix for things like this, which I guess would be -ppb? Cheers, Conor. > + $ref: /schemas/types.yaml#/definitions/uint32 > + description: > + accuracy of clock in ppb (parts per billion). Alternative for providing > + this through nvmem, the nvmem provided value takes precedence. > + > + clock-output-names: > + maxItems: 1 > + > +required: > + - compatible > + - "#clock-cells" > + - nvmem-cells > + - nvmem-cell-names > + > +additionalProperties: false > + > +examples: > + - | > + xtal { > + compatible = "nvmem-clock"; > + #clock-cells = <0>; > + nvmem-cells = <&efuse_xtal_freq>; > + nvmem-cell-names = "clock-frequency"; > + }; > +... > -- > 2.17.1 > > > Met vriendelijke groet / kind regards, > > Mike Looijmans > System Expert > > > TOPIC Embedded Products B.V. > Materiaalweg 4, 5681 RJ Best > The Netherlands > > T: +31 (0) 499 33 69 69 > E: mike.looijmans@xxxxxxxxxxxxxxxxx > W: www.topic.nl > > Please consider the environment before printing this e-mail
Attachment:
signature.asc
Description: PGP signature
