On 12/04/2022 09:31, Nishanth Menon wrote:
> This adds the documentation for the devicetree bindings of the Texas
> Instruments RTC modules on K3 family of SoCs such as AM62x SoCs or
> newer.
>
Thank you for your patch. There is something to discuss/improve.
(...)
> +properties:
> + compatible:
> + items:
No need for items. Just enum under the compatible.
> + - enum:
> + - ti,am62-rtc
> +
> + reg:
> + maxItems: 1
> +
> + interrupts:
> + maxItems: 1
> +
> + clocks:
> + items:
> + - description: VBUS Interface clock
> + - description: 32k Clock source (external or internal).
> +
> + clock-names:
> + items:
> + - const: "vbus"
> + - const: "osc32k"
No quotes.
> +
> + power-domains:
> + maxItems: 1
> +
> + assigned-clocks:
> + description: |
> + override default osc32k parent clock reference to the osc32k clock entry
> + maxItems: 1
> +
> + assigned-clock-parents:
> + description: |
> + override default osc32k parent clock phandle of the new parent clock of osc32k
> + maxItems: 1
Usually assigned-clockXXX are not needed in the bindings. Is here
something different? They are put only to indicate something special.
> +
> + wakeup-source: true
> +
> +required:
> + - compatible
> + - reg
> + - interrupts
> + - clocks
> + - clock-names
> +
> +additionalProperties: false
> +
> +examples:
> + - |
> + #include <dt-bindings/interrupt-controller/arm-gic.h>
> + rtc@2b1f0000 {
> + compatible = "ti,am62-rtc";
> + reg = <0x2b1f0000 0x100>;
> + interrupts = <GIC_SPI 100 IRQ_TYPE_LEVEL_HIGH>;
> + power-domains = <&bar 0>;
> + clocks = <&foo 0>, <&foo 1>;
> + clock-names = "vbus", "osc32k";
> + wakeup-source;
> + };
> +
> + - |
> + #include <dt-bindings/interrupt-controller/arm-gic.h>
> + rtc@2b1f0000 {
> + compatible = "ti,am62-rtc";
> + reg = <0x2b1f0000 0x100>;
> + interrupts = <GIC_SPI 100 IRQ_TYPE_LEVEL_HIGH>;
> + power-domains = <&bar 0>;
> + clocks = <&foo 0>, <&foo 1>;
> + clock-names = "vbus", "osc32k";
> + wakeup-source;
> + assigned-clocks = <&foo 1>;
> + assigned-clock-parents = <&foo 2>;
> +
Unneeded blank line.
> + };
Best regards,
Krzysztof
On 14:06-20220412, Krzysztof Kozlowski wrote:
> > +properties:
> > + compatible:
> > + items:
>
> No need for items. Just enum under the compatible.
Will fix in next rev. Thanks for catching.
>
> > + - enum:
> > + - ti,am62-rtc
> > +
> > + reg:
> > + maxItems: 1
> > +
> > + interrupts:
> > + maxItems: 1
> > +
> > + clocks:
> > + items:
> > + - description: VBUS Interface clock
> > + - description: 32k Clock source (external or internal).
> > +
> > + clock-names:
> > + items:
> > + - const: "vbus"
> > + - const: "osc32k"
>
> No quotes.
Uggh.. my bad. yup
>
> > +
> > + power-domains:
> > + maxItems: 1
> > +
> > + assigned-clocks:
> > + description: |
> > + override default osc32k parent clock reference to the osc32k clock entry
> > + maxItems: 1
> > +
> > + assigned-clock-parents:
> > + description: |
> > + override default osc32k parent clock phandle of the new parent clock of osc32k
> > + maxItems: 1
>
> Usually assigned-clockXXX are not needed in the bindings. Is here
> something different? They are put only to indicate something special.
I wonder if I should rather use unevaluatedproperties instead? If I use
additionalProperties: False, then the second example below fails.
Thoughts?
>
> > +
> > + wakeup-source: true
> > +
> > +required:
> > + - compatible
> > + - reg
> > + - interrupts
> > + - clocks
> > + - clock-names
> > +
> > +additionalProperties: false
> > +
> > +examples:
> > + - |
> > + #include <dt-bindings/interrupt-controller/arm-gic.h>
> > + rtc@2b1f0000 {
> > + compatible = "ti,am62-rtc";
> > + reg = <0x2b1f0000 0x100>;
> > + interrupts = <GIC_SPI 100 IRQ_TYPE_LEVEL_HIGH>;
> > + power-domains = <&bar 0>;
> > + clocks = <&foo 0>, <&foo 1>;
> > + clock-names = "vbus", "osc32k";
> > + wakeup-source;
> > + };
> > +
> > + - |
> > + #include <dt-bindings/interrupt-controller/arm-gic.h>
> > + rtc@2b1f0000 {
> > + compatible = "ti,am62-rtc";
> > + reg = <0x2b1f0000 0x100>;
> > + interrupts = <GIC_SPI 100 IRQ_TYPE_LEVEL_HIGH>;
> > + power-domains = <&bar 0>;
> > + clocks = <&foo 0>, <&foo 1>;
> > + clock-names = "vbus", "osc32k";
> > + wakeup-source;
> > + assigned-clocks = <&foo 1>;
> > + assigned-clock-parents = <&foo 2>;
> > +
>
> Unneeded blank line.
Ack.
--
Regards,
Nishanth Menon
Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3 1A34 DDB5 849D 1736 249D
On 13/04/2022 00:17, Nishanth Menon wrote:
>>> + assigned-clocks:
>>> + description: |
>>> + override default osc32k parent clock reference to the osc32k clock entry
>>> + maxItems: 1
>>> +
>>> + assigned-clock-parents:
>>> + description: |
>>> + override default osc32k parent clock phandle of the new parent clock of osc32k
>>> + maxItems: 1
>>
>> Usually assigned-clockXXX are not needed in the bindings. Is here
>> something different? They are put only to indicate something special.
>
> I wonder if I should rather use unevaluatedproperties instead? If I use
> additionalProperties: False, then the second example below fails.
>
Are you sure it fails? I just checked and it worked in my case. This
AFAIR was working since some time (or fixed some time ago), so maybe
update your dtschema?
Best regards,
Krzysztof
On 08:42-20220413, Krzysztof Kozlowski wrote:
> On 13/04/2022 00:17, Nishanth Menon wrote:
> >>> + assigned-clocks:
> >>> + description: |
> >>> + override default osc32k parent clock reference to the osc32k clock entry
> >>> + maxItems: 1
> >>> +
> >>> + assigned-clock-parents:
> >>> + description: |
> >>> + override default osc32k parent clock phandle of the new parent clock of osc32k
> >>> + maxItems: 1
> >>
> >> Usually assigned-clockXXX are not needed in the bindings. Is here
> >> something different? They are put only to indicate something special.
> >
> > I wonder if I should rather use unevaluatedproperties instead? If I use
> > additionalProperties: False, then the second example below fails.
> >
>
> Are you sure it fails? I just checked and it worked in my case. This
> AFAIR was working since some time (or fixed some time ago), so maybe
> update your dtschema?
Arrgh, Thanks and you are right.
Apologies, I should have cross checked again since developing late
last year (understood the min schema currently is 2022.3).
Will fix this up in the repost v2 in a short while.
--
Regards,
Nishanth Menon
Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3 1A34 DDB5 849D 1736 249D