Re: [PATCH v3 1/2] dt-bindings: clock: fixed-clock: Add nvmem support

[Krzysztof Kozlowski]

On 05/06/2023 16:00, Mike Looijmans wrote:
> On 05-06-2023 15:38, Krzysztof Kozlowski wrote:
>> On 05/06/2023 15:34, 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 v3:
>>> Modify fixed-clock instead of introducing nvmem-clock
>>>
>>> Changes in v2:
>>> Changed "fixed-clock" into "nvmem-clock" in dts example
>>> Add minItems:1 to nvmem-cell-names
>>>
>>>   .../bindings/clock/fixed-clock.yaml           | 25 ++++++++++++++++++-
>>>   1 file changed, 24 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/Documentation/devicetree/bindings/clock/fixed-clock.yaml b/Documentation/devicetree/bindings/clock/fixed-clock.yaml
>>> index b0a4fb8256e2..23e4df96d3b0 100644
>>> --- a/Documentation/devicetree/bindings/clock/fixed-clock.yaml
>>> +++ b/Documentation/devicetree/bindings/clock/fixed-clock.yaml
>>> @@ -12,7 +12,9 @@ maintainers:
>>>   
>>>   properties:
>>>     compatible:
>>> -    const: fixed-clock
>>> +    enum:
>>> +      - fixed-clock
>>> +      - fixed-clock-nvmem
>> Do you even need new compatible? Isn't this the same clock from the
>> hardware point of view?
> 
> I need a new compatible because a "fixed-clock" only loads at init time. 
> It registers using CLK_OF_DECLARE, which requires the clock to register 
> early. NVMEM providers are typical devices like I2C EEPROMs that won't 
> be available at that point, hence I needed to create a clock that 
> registers as a regular clock driver and can handle deferral and similar.

Ah, ok.

> 
> 
>>
>>>     "#clock-cells":
>>>       const: 0
>>> @@ -33,6 +35,27 @@ required:
>>>   
>>>   additionalProperties: false
>>>   
>> Put it under allOf. Entire block should be before additionalProperties
>> (just like in example-schema).
>>
>>> +if:
>>> +  properties:
>>> +    compatible:
>>> +      contains:
>>> +        const: fixed-clock-nvmem
>>> +
>>> +then:
>>> +  properties:
>>> +    nvmem-cells:
>>> +      maxItems: 2
>> Anyway, I don't think you tested it. Provide a DTS user of this. I don't
>> think it works and such user would point to mistakes.
>>
>> Properties should be defined in top-level properties:, not in
>> allOf:if:then. In allOf:if:then you only narrow them.
> 
> Ah, got it. Added an example dts block to the document, this revealed 
> the issues, indeed didn't test the bindings.
> 
> Fixed it into an "allOf" to properly narrow the properties.

The real DTS user would be also welcomed.

Best regards,
Krzysztof