Re: [RFC PATCH v3 4/6] dt-bindings: clock: meson: document A1 SoC audio clock controller driver

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




On 4/19/24 17:06, Krzysztof Kozlowski wrote:
> On 19/04/2024 14:58, Jan Dakinevich wrote:
>> Add device tree bindings for A1 SoC audio clock and reset controllers.
>>
>> Signed-off-by: Jan Dakinevich <jan.dakinevich@xxxxxxxxxxxxxxxxx>
> 
> This is still RFC, so not ready.
> 
> Limited, incomplete review follows. Full review will be provided when
> the work is ready.
> 
> Drop "driver" references, e.g. from subject. Bindings are about hardware.
> 
> 
> ....
> 
>> +
>> +  clocks:
>> +    maxItems: 26
>> +    items:
>> +      - description: input main peripheral bus clock
>> +      - description: input dds_in
>> +      - description: input fixed pll div2
>> +      - description: input fixed pll div3
>> +      - description: input hifi_pll
>> +      - description: input oscillator (usually at 24MHz)
>> +    additionalItems:
>> +      oneOf:
>> +        - description: slv_sclk[0-9] - slave bit clocks provided by external components
>> +        - description: slv_lrclk[0-9]- slave sample clocks provided by external components
> 
> What does it mean the clocks are optional? Pins could be not routed?

Yes exactly. Pins could be routed in any combination or could be not
routed at all. It is determined by schematics and that how external
codecs are configured.

> It's really rare case that clocks within the SoC are optional, so every
> such case is questionable.
> 
> 
>> +
>> +  clock-names:
>> +    maxItems: 26
>> +    items:
>> +      - const: pclk
>> +      - const: dds_in
>> +      - const: fclk_div2
>> +      - const: fclk_div3
>> +      - const: hifi_pll
>> +      - const: xtal
>> +    additionalItems:
>> +      oneOf:
>> +        - pattern: "^slv_sclk[0-9]$"
>> +        - pattern: "^slv_lrclk[0-9]$"
>> +
>> +required:
>> +  - compatible
>> +  - '#clock-cells'
>> +  - reg
>> +  - clocks
>> +  - clock-names
>> +
>> +allOf:
>> +  - if:
>> +      properties:
>> +        compatible:
>> +          contains:
>> +            const: amlogic,a1-audio-clkc
>> +    then:
>> +      required:
>> +        - '#reset-cells'
>> +    else:
>> +      properties:
>> +        '#reset-cells': false
>> +
>> +additionalProperties: false
>> +
>> +examples:
>> +  - |
>> +    #include <dt-bindings/clock/amlogic,a1-pll-clkc.h>
>> +    #include <dt-bindings/clock/amlogic,a1-peripherals-clkc.h>
>> +    #include <dt-bindings/clock/amlogic,a1-audio-clkc.h>
>> +    audio {
>> +        #address-cells = <2>;
>> +        #size-cells = <2>;
>> +
>> +        clkc_audio: clock-controller@fe050000 {
>> +                compatible = "amlogic,a1-audio-clkc";
>> +                reg = <0x0 0xfe050000 0x0 0xb0>;
>> +                #clock-cells = <1>;
>> +                #reset-cells = <1>;
>> +                clocks = <&clkc_audio_vad AUD_CLKID_VAD_AUDIOTOP>,
>> +                         <&clkc_periphs CLKID_DDS_IN>,
>> +                         <&clkc_pll CLKID_FCLK_DIV2>,
>> +                         <&clkc_pll CLKID_FCLK_DIV3>,
>> +                         <&clkc_pll CLKID_HIFI_PLL>,
>> +                         <&xtal>;
>> +                clock-names = "pclk",
>> +                              "dds_in",
>> +                              "fclk_div2",
>> +                              "fclk_div3",
>> +                              "hifi_pll",
>> +                              "xtal";
> 
> Make it complete - list all clocks.
> 

You mean, all optional clocks should be mentioned here. Right?

>> +        };
>> +
>> +        clkc_audio_vad: clock-controller@fe054800 {
> 
> Just keep one example. It's basically almost the same.
> 

The worth of this duplication is to show how a clock from second
controller (<&clkc_audio_vad AUD_CLKID_VAD_AUDIOTOP>) is used by first
one. May be it would be better to keep it... What do you think?

> 
> 
> Best regards,
> Krzysztof
> 

-- 
Best regards
Jan Dakinevich




[Index of Archives]     [Device Tree Compilter]     [Device Tree Spec]     [Linux Driver Backports]     [Video for Linux]     [Linux USB Devel]     [Linux PCI Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Yosemite Backpacking]


  Powered by Linux