Re: [PATCH v3 08/11] dt-bindings: clock: Add StarFive JH7110 always-on clock and reset generator
From: Hal Feng
Date: Thu Feb 16 2023 - 12:19:32 EST
On Tue, 20 Dec 2022 23:19:04 +0000, Conor Dooley wrote:
> On Tue, Dec 20, 2022 at 08:50:51AM +0800, Hal Feng wrote:
>> From: Emil Renner Berthing <kernel@xxxxxxxx>
>>
>> Add bindings for the always-on clock and reset generator (AONCRG) on the
>> JH7110 RISC-V SoC by StarFive Ltd.
>>
>> Signed-off-by: Emil Renner Berthing <kernel@xxxxxxxx>
>> Signed-off-by: Hal Feng <hal.feng@xxxxxxxxxxxxxxxx>
>> ---
>> .../clock/starfive,jh7110-aoncrg.yaml | 76 +++++++++++++++++++
>> .../dt-bindings/clock/starfive,jh7110-crg.h | 18 +++++
>> .../dt-bindings/reset/starfive,jh7110-crg.h | 12 +++
>> 3 files changed, 106 insertions(+)
>> create mode 100644 Documentation/devicetree/bindings/clock/starfive,jh7110-aoncrg.yaml
>>
>> diff --git a/Documentation/devicetree/bindings/clock/starfive,jh7110-aoncrg.yaml b/Documentation/devicetree/bindings/clock/starfive,jh7110-aoncrg.yaml
>> new file mode 100644
>> index 000000000000..a3cf0570d950
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/clock/starfive,jh7110-aoncrg.yaml
>> @@ -0,0 +1,76 @@
>> +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
>> +%YAML 1.2
>> +---
>> +$id: http://devicetree.org/schemas/clock/starfive,jh7110-aoncrg.yaml#
>> +$schema: http://devicetree.org/meta-schemas/core.yaml#
>> +
>> +title: StarFive JH7110 Always-On Clock and Reset Generator
>> +
>> +maintainers:
>> + - Emil Renner Berthing <kernel@xxxxxxxx>
>> +
>> +properties:
>> + compatible:
>> + const: starfive,jh7110-aoncrg
>> +
>> + reg:
>> + maxItems: 1
>> +
>> + clocks:
>> + items:
>> + - description: Main Oscillator (24 MHz)
>> + - description: RTC Oscillator (32.768 kHz)
>> + - description: GMAC0 RMII reference
>> + - description: GMAC0 RGMII RX
>
> Gotta ask the same question here about the muxing - are all of these
> clocks truly required?
Please see the following clock tree.
enable prepare protect duty hardware
clock count count count rate accuracy phase cycle enable
-------------------------------------------------------------------------------------------------------
*rtc_osc* 0 0 0 32768 0 0 50000 Y
rtc_32k 0 0 0 32768 0 0 50000 Y
*gmac0_rgmii_rxin* 0 0 0 125000000 0 0 50000 Y
gmac0_rx 0 0 0 125000000 0 0 50000 Y
gmac0_rx_inv 0 0 0 125000000 0 180 50000 Y
*gmac0_rmii_refin* 0 0 0 50000000 0 0 50000 Y
gmac0_rmii_rtx 0 0 0 25000000 0 0 50000 Y
gmac0_tx 0 0 0 25000000 0 0 50000 N
gmac0_tx_inv 0 0 0 25000000 0 180 50000 Y
*osc* 3 3 0 24000000 0 0 50000 Y
rtc_cal 0 0 0 24000000 0 0 50000 N
rtc_internal 0 0 0 32000 0 0 50000 Y
apb_func 0 0 0 24000000 0 0 50000 Y
osc_div4 0 0 0 6000000 0 0 50000 Y
pll2_out 2 2 0 1188000000 0 0 50000 Y
bus_root 1 1 0 1188000000 0 0 50000 Y
axi_cfg0 2 2 0 396000000 0 0 50000 Y
*stg_axiahb* 3 3 0 198000000 0 0 50000 Y
gmac0_axi 0 0 0 198000000 0 0 50000 N
gmac0_ahb 0 0 0 198000000 0 0 50000 N
*apb_bus* 2 2 0 49500000 0 0 50000 Y
rtc_apb 0 0 0 49500000 0 0 50000 Y
otpc_apb 0 0 0 49500000 0 0 50000 Y
pll0_out 1 1 0 1250000000 0 0 50000 Y
*gmac0_gtxclk* 0 0 0 156250000 0 0 50000 N
gmac0_gtxc 0 0 0 156250000 0 0 50000 N
Most input clocks are used as parent of the clocks registered
in aon clock driver (patch 10) except the clock "gmac0_gtxclk".
But I still think there is no harm in building a complete
clock tree, so we can adjust the parent clocks easily.
>
>> + - description: STG AXI/AHB
>> + - description: APB Bus
>> + - description: GMAC0 GTX
>> +
>> + clock-names:
>> + items:
>> + - const: osc
>> + - const: rtc_osc
>> + - const: gmac0_rmii_refin
>> + - const: gmac0_rgmii_rxin
>> + - const: stg_axiahb
>> + - const: apb_bus
>> + - const: gmac0_gtxclk
>
> And if they are, is this actually needed since the order must be as
> above?
Will remove "clock-names" in the binding and device tree. Thanks.
Best regards,
Hal
>
> As I said in the previous patch, I've probably missed something...
>