Message ID | 20230221141147.303642-4-xingyu.wu@starfivetech.com |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a5d:5915:0:0:0:0:0 with SMTP id v21csp40110wrd; Tue, 21 Feb 2023 06:31:50 -0800 (PST) X-Google-Smtp-Source: AK7set8LOjYK/fYPJYVk7K0dkJJ+Y8twaBG7gJOxlM7HYY5LjudPzJgAXLdGUDNJAhtPmTiAPGD+ X-Received: by 2002:a17:907:9627:b0:8d7:c649:635d with SMTP id gb39-20020a170907962700b008d7c649635dmr5991789ejc.37.1676989909804; Tue, 21 Feb 2023 06:31:49 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1676989909; cv=none; d=google.com; s=arc-20160816; b=xyl10a+HBvOf0ko0Fll6BSzrmKzY0wWE4nLwYql6g/pQQ2Tykk3C/DFMRfuKfxdgAs mV32PL4US/fJp4rYFYwOMQtnEHd8vSV7pMQU4hT37Jrb4850es4Wr7+iUoIhDjE3iNSL rFZdlnP4ib5UwAbmYMJpMCvcYgb7og0aZnSPAbsvZsaWhSn9PPBBPWYe4HWvGlXzQU7i rwwXzihDFrO1vaHvPF2cLRmflg/A721K7Rhuh2cxZwMeq835GkSwqb4/J/962rfpGg5i tMqGFQrvoWrqMAsIJPLrkJhpQ+0p2NowVB8J1aG36b3h4q5yWccBaEmKAgydip0HlOdK vy9g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :references:in-reply-to:message-id:date:subject:cc:to:from; bh=Mhhs5nHjfusb8RRg8Cq1XgnXuvDK2jIDF/e3Oyrpvfo=; b=U3f0aK/PMX+QbmiRAOfjfPZumfFzM6wf8bfY3B23sxFAV0R2a/y1SP2g6/AUDJt1Z5 nUt6Gr2Ft9Rfl0+IXNJjrziOFUvKzBK38B2Sx3yU+sXc+qXiOXbicGRe/zs4m0LunFqG TtRUQ2N3C81H9l56kzRoxVjgfT8FF4wlIptcBWIiLaRD1sMF8aCd+Tz2bMxIeBfTqab9 KEOilWT9Zcya1HU4HxbgdKs+KiGjtCogNyFBrX25HE4M+ysY6INU7WzR1Mfv7kRSjphL S4ehfNKt39L3g0FC6Qh305Zonp63lTHtntWYWP1JAXsLVuDYqPvYm00rU0RZchJTn4pw lIHQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id vs18-20020a170907139200b008cbf89a6787si8208988ejb.6.2023.02.21.06.31.26; Tue, 21 Feb 2023 06:31:49 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234194AbjBUOMC convert rfc822-to-8bit (ORCPT <rfc822;kloczko.tomasz@gmail.com> + 99 others); Tue, 21 Feb 2023 09:12:02 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:35074 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229696AbjBUOL5 (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Tue, 21 Feb 2023 09:11:57 -0500 Received: from fd01.gateway.ufhost.com (fd01.gateway.ufhost.com [61.152.239.71]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id A1EB9279AD; Tue, 21 Feb 2023 06:11:55 -0800 (PST) Received: from EXMBX166.cuchost.com (unknown [175.102.18.54]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "EXMBX166", Issuer "EXMBX166" (not verified)) by fd01.gateway.ufhost.com (Postfix) with ESMTP id 6D2D224E287; Tue, 21 Feb 2023 22:11:54 +0800 (CST) Received: from EXMBX061.cuchost.com (172.16.6.61) by EXMBX166.cuchost.com (172.16.6.76) with Microsoft SMTP Server (TLS) id 15.0.1497.42; Tue, 21 Feb 2023 22:11:54 +0800 Received: from localhost.localdomain (183.27.98.67) by EXMBX061.cuchost.com (172.16.6.61) with Microsoft SMTP Server (TLS) id 15.0.1497.42; Tue, 21 Feb 2023 22:11:53 +0800 From: Xingyu Wu <xingyu.wu@starfivetech.com> To: <linux-riscv@lists.infradead.org>, <devicetree@vger.kernel.org>, "Michael Turquette" <mturquette@baylibre.com>, Stephen Boyd <sboyd@kernel.org>, Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>, Philipp Zabel <p.zabel@pengutronix.de>, Emil Renner Berthing <kernel@esmil.dk> CC: Rob Herring <robh+dt@kernel.org>, Conor Dooley <conor@kernel.org>, "Paul Walmsley" <paul.walmsley@sifive.com>, Palmer Dabbelt <palmer@dabbelt.com>, Albert Ou <aou@eecs.berkeley.edu>, Hal Feng <hal.feng@starfivetech.com>, Xingyu Wu <xingyu.wu@starfivetech.com>, <linux-kernel@vger.kernel.org>, <linux-clk@vger.kernel.org> Subject: [PATCH v1 3/3] riscv: dts: starfive: jh7110: Add PLL clock node Date: Tue, 21 Feb 2023 22:11:47 +0800 Message-ID: <20230221141147.303642-4-xingyu.wu@starfivetech.com> X-Mailer: git-send-email 2.25.1 In-Reply-To: <20230221141147.303642-1-xingyu.wu@starfivetech.com> References: <20230221141147.303642-1-xingyu.wu@starfivetech.com> MIME-Version: 1.0 Content-Type: text/plain X-Originating-IP: [183.27.98.67] X-ClientProxiedBy: EXCAS064.cuchost.com (172.16.6.24) To EXMBX061.cuchost.com (172.16.6.61) X-YovoleRuleAgent: yovoleflag Content-Transfer-Encoding: 8BIT X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RCVD_IN_MSPIKE_H2, SPF_HELO_PASS,SPF_PASS autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1758451371785104079?= X-GMAIL-MSGID: =?utf-8?q?1758451371785104079?= |
Series |
Add PLL clocks driver for StarFive JH7110
|
|
Commit Message
Xingyu Wu
Feb. 21, 2023, 2:11 p.m. UTC
Add the PLL clock node for the Starfive JH7110 SoC and
modify the SYSCRG node to add PLL clocks.
Signed-off-by: Xingyu Wu <xingyu.wu@starfivetech.com>
---
arch/riscv/boot/dts/starfive/jh7110.dtsi | 15 +++++++++++++--
1 file changed, 13 insertions(+), 2 deletions(-)
Comments
On 21/02/2023 15:11, Xingyu Wu wrote: > Add the PLL clock node for the Starfive JH7110 SoC and > modify the SYSCRG node to add PLL clocks. > > Signed-off-by: Xingyu Wu <xingyu.wu@starfivetech.com> > --- > arch/riscv/boot/dts/starfive/jh7110.dtsi | 15 +++++++++++++-- > 1 file changed, 13 insertions(+), 2 deletions(-) > > diff --git a/arch/riscv/boot/dts/starfive/jh7110.dtsi b/arch/riscv/boot/dts/starfive/jh7110.dtsi > index b6612c53d0d2..0cb8d86ebce5 100644 > --- a/arch/riscv/boot/dts/starfive/jh7110.dtsi > +++ b/arch/riscv/boot/dts/starfive/jh7110.dtsi > @@ -461,12 +461,16 @@ syscrg: clock-controller@13020000 { > <&gmac1_rgmii_rxin>, > <&i2stx_bclk_ext>, <&i2stx_lrck_ext>, > <&i2srx_bclk_ext>, <&i2srx_lrck_ext>, > - <&tdm_ext>, <&mclk_ext>; > + <&tdm_ext>, <&mclk_ext>, > + <&pllclk JH7110_CLK_PLL0_OUT>, > + <&pllclk JH7110_CLK_PLL1_OUT>, > + <&pllclk JH7110_CLK_PLL2_OUT>; > clock-names = "osc", "gmac1_rmii_refin", > "gmac1_rgmii_rxin", > "i2stx_bclk_ext", "i2stx_lrck_ext", > "i2srx_bclk_ext", "i2srx_lrck_ext", > - "tdm_ext", "mclk_ext"; > + "tdm_ext", "mclk_ext", > + "pll0_out", "pll1_out", "pll2_out"; > #clock-cells = <1>; > #reset-cells = <1>; > }; > @@ -476,6 +480,13 @@ sys_syscon: syscon@13030000 { > reg = <0x0 0x13030000 0x0 0x1000>; > }; > > + pllclk: pll-clock-controller { Does not look like you tested the DTS against bindings. Please run `make dtbs_check` (see Documentation/devicetree/bindings/writing-schema.rst for instructions). You should see here warnings of mixing non-MMIO nodes in MMIO-bus. Best regards, Krzysztof
On 2023/2/22 17:09, Krzysztof Kozlowski wrote: > On 21/02/2023 15:11, Xingyu Wu wrote: >> Add the PLL clock node for the Starfive JH7110 SoC and >> modify the SYSCRG node to add PLL clocks. >> >> Signed-off-by: Xingyu Wu <xingyu.wu@starfivetech.com> >> --- >> arch/riscv/boot/dts/starfive/jh7110.dtsi | 15 +++++++++++++-- >> 1 file changed, 13 insertions(+), 2 deletions(-) >> >> diff --git a/arch/riscv/boot/dts/starfive/jh7110.dtsi b/arch/riscv/boot/dts/starfive/jh7110.dtsi >> index b6612c53d0d2..0cb8d86ebce5 100644 >> --- a/arch/riscv/boot/dts/starfive/jh7110.dtsi >> +++ b/arch/riscv/boot/dts/starfive/jh7110.dtsi >> @@ -461,12 +461,16 @@ syscrg: clock-controller@13020000 { >> <&gmac1_rgmii_rxin>, >> <&i2stx_bclk_ext>, <&i2stx_lrck_ext>, >> <&i2srx_bclk_ext>, <&i2srx_lrck_ext>, >> - <&tdm_ext>, <&mclk_ext>; >> + <&tdm_ext>, <&mclk_ext>, >> + <&pllclk JH7110_CLK_PLL0_OUT>, >> + <&pllclk JH7110_CLK_PLL1_OUT>, >> + <&pllclk JH7110_CLK_PLL2_OUT>; >> clock-names = "osc", "gmac1_rmii_refin", >> "gmac1_rgmii_rxin", >> "i2stx_bclk_ext", "i2stx_lrck_ext", >> "i2srx_bclk_ext", "i2srx_lrck_ext", >> - "tdm_ext", "mclk_ext"; >> + "tdm_ext", "mclk_ext", >> + "pll0_out", "pll1_out", "pll2_out"; >> #clock-cells = <1>; >> #reset-cells = <1>; >> }; >> @@ -476,6 +480,13 @@ sys_syscon: syscon@13030000 { >> reg = <0x0 0x13030000 0x0 0x1000>; >> }; >> >> + pllclk: pll-clock-controller { > > Does not look like you tested the DTS against bindings. Please run `make > dtbs_check` (see Documentation/devicetree/bindings/writing-schema.rst > for instructions). You should see here warnings of mixing non-MMIO nodes > in MMIO-bus. > Oh I cherry-pick the commit of syscon node and it also include the MMC node. I will remove the MMC node. I used dtbs_check and get the error 'should not be valid under {'type': 'object'}', If I move this node out of the 'soc' node, the dtbs_check will be pass. Is it OK to move the PLL node out of the 'soc' node? Thanks. Best regards, Xingyu Wu
On 23/02/2023 09:47, Xingyu Wu wrote: > On 2023/2/22 17:09, Krzysztof Kozlowski wrote: >> On 21/02/2023 15:11, Xingyu Wu wrote: >>> Add the PLL clock node for the Starfive JH7110 SoC and >>> modify the SYSCRG node to add PLL clocks. >>> >>> Signed-off-by: Xingyu Wu <xingyu.wu@starfivetech.com> >>> --- >>> arch/riscv/boot/dts/starfive/jh7110.dtsi | 15 +++++++++++++-- >>> 1 file changed, 13 insertions(+), 2 deletions(-) >>> >>> diff --git a/arch/riscv/boot/dts/starfive/jh7110.dtsi b/arch/riscv/boot/dts/starfive/jh7110.dtsi >>> index b6612c53d0d2..0cb8d86ebce5 100644 >>> --- a/arch/riscv/boot/dts/starfive/jh7110.dtsi >>> +++ b/arch/riscv/boot/dts/starfive/jh7110.dtsi >>> @@ -461,12 +461,16 @@ syscrg: clock-controller@13020000 { >>> <&gmac1_rgmii_rxin>, >>> <&i2stx_bclk_ext>, <&i2stx_lrck_ext>, >>> <&i2srx_bclk_ext>, <&i2srx_lrck_ext>, >>> - <&tdm_ext>, <&mclk_ext>; >>> + <&tdm_ext>, <&mclk_ext>, >>> + <&pllclk JH7110_CLK_PLL0_OUT>, >>> + <&pllclk JH7110_CLK_PLL1_OUT>, >>> + <&pllclk JH7110_CLK_PLL2_OUT>; >>> clock-names = "osc", "gmac1_rmii_refin", >>> "gmac1_rgmii_rxin", >>> "i2stx_bclk_ext", "i2stx_lrck_ext", >>> "i2srx_bclk_ext", "i2srx_lrck_ext", >>> - "tdm_ext", "mclk_ext"; >>> + "tdm_ext", "mclk_ext", >>> + "pll0_out", "pll1_out", "pll2_out"; >>> #clock-cells = <1>; >>> #reset-cells = <1>; >>> }; >>> @@ -476,6 +480,13 @@ sys_syscon: syscon@13030000 { >>> reg = <0x0 0x13030000 0x0 0x1000>; >>> }; >>> >>> + pllclk: pll-clock-controller { >> >> Does not look like you tested the DTS against bindings. Please run `make >> dtbs_check` (see Documentation/devicetree/bindings/writing-schema.rst >> for instructions). You should see here warnings of mixing non-MMIO nodes >> in MMIO-bus. >> > > Oh I cherry-pick the commit of syscon node and it also include the MMC node. > I will remove the MMC node. > I used dtbs_check and get the error 'should not be valid under {'type': 'object'}', > If I move this node out of the 'soc' node, the dtbs_check will be pass. > Is it OK to move the PLL node out of the 'soc' node? Thanks. Shall it be out side of soc? How it can then do anything with registers? This does not look like correct representation of hardware. Best regards, Krzysztof
On 2023/2/23 16:52, Krzysztof Kozlowski wrote: > On 23/02/2023 09:47, Xingyu Wu wrote: >> On 2023/2/22 17:09, Krzysztof Kozlowski wrote: >>> On 21/02/2023 15:11, Xingyu Wu wrote: >>>> Add the PLL clock node for the Starfive JH7110 SoC and >>>> modify the SYSCRG node to add PLL clocks. >>>> >>>> Signed-off-by: Xingyu Wu <xingyu.wu@starfivetech.com> >>>> --- >>>> arch/riscv/boot/dts/starfive/jh7110.dtsi | 15 +++++++++++++-- >>>> 1 file changed, 13 insertions(+), 2 deletions(-) >>>> >>>> diff --git a/arch/riscv/boot/dts/starfive/jh7110.dtsi b/arch/riscv/boot/dts/starfive/jh7110.dtsi >>>> index b6612c53d0d2..0cb8d86ebce5 100644 >>>> --- a/arch/riscv/boot/dts/starfive/jh7110.dtsi >>>> +++ b/arch/riscv/boot/dts/starfive/jh7110.dtsi >>>> @@ -461,12 +461,16 @@ syscrg: clock-controller@13020000 { >>>> <&gmac1_rgmii_rxin>, >>>> <&i2stx_bclk_ext>, <&i2stx_lrck_ext>, >>>> <&i2srx_bclk_ext>, <&i2srx_lrck_ext>, >>>> - <&tdm_ext>, <&mclk_ext>; >>>> + <&tdm_ext>, <&mclk_ext>, >>>> + <&pllclk JH7110_CLK_PLL0_OUT>, >>>> + <&pllclk JH7110_CLK_PLL1_OUT>, >>>> + <&pllclk JH7110_CLK_PLL2_OUT>; >>>> clock-names = "osc", "gmac1_rmii_refin", >>>> "gmac1_rgmii_rxin", >>>> "i2stx_bclk_ext", "i2stx_lrck_ext", >>>> "i2srx_bclk_ext", "i2srx_lrck_ext", >>>> - "tdm_ext", "mclk_ext"; >>>> + "tdm_ext", "mclk_ext", >>>> + "pll0_out", "pll1_out", "pll2_out"; >>>> #clock-cells = <1>; >>>> #reset-cells = <1>; >>>> }; >>>> @@ -476,6 +480,13 @@ sys_syscon: syscon@13030000 { >>>> reg = <0x0 0x13030000 0x0 0x1000>; >>>> }; >>>> >>>> + pllclk: pll-clock-controller { >>> >>> Does not look like you tested the DTS against bindings. Please run `make >>> dtbs_check` (see Documentation/devicetree/bindings/writing-schema.rst >>> for instructions). You should see here warnings of mixing non-MMIO nodes >>> in MMIO-bus. >>> >> >> Oh I cherry-pick the commit of syscon node and it also include the MMC node. >> I will remove the MMC node. >> I used dtbs_check and get the error 'should not be valid under {'type': 'object'}', >> If I move this node out of the 'soc' node, the dtbs_check will be pass. >> Is it OK to move the PLL node out of the 'soc' node? Thanks. > > Shall it be out side of soc? How it can then do anything with registers? > This does not look like correct representation of hardware. The error appears to be due to a lack of reg base about PLL node. PLL do something with register by 'sys_syscon' node and the syscon node is in the soc node. Best regards, Xingyu Wu
On 23/02/2023 10:03, Xingyu Wu wrote: > On 2023/2/23 16:52, Krzysztof Kozlowski wrote: >> On 23/02/2023 09:47, Xingyu Wu wrote: >>> On 2023/2/22 17:09, Krzysztof Kozlowski wrote: >>>> On 21/02/2023 15:11, Xingyu Wu wrote: >>>>> Add the PLL clock node for the Starfive JH7110 SoC and >>>>> modify the SYSCRG node to add PLL clocks. >>>>> >>>>> Signed-off-by: Xingyu Wu <xingyu.wu@starfivetech.com> >>>>> --- >>>>> arch/riscv/boot/dts/starfive/jh7110.dtsi | 15 +++++++++++++-- >>>>> 1 file changed, 13 insertions(+), 2 deletions(-) >>>>> >>>>> diff --git a/arch/riscv/boot/dts/starfive/jh7110.dtsi b/arch/riscv/boot/dts/starfive/jh7110.dtsi >>>>> index b6612c53d0d2..0cb8d86ebce5 100644 >>>>> --- a/arch/riscv/boot/dts/starfive/jh7110.dtsi >>>>> +++ b/arch/riscv/boot/dts/starfive/jh7110.dtsi >>>>> @@ -461,12 +461,16 @@ syscrg: clock-controller@13020000 { >>>>> <&gmac1_rgmii_rxin>, >>>>> <&i2stx_bclk_ext>, <&i2stx_lrck_ext>, >>>>> <&i2srx_bclk_ext>, <&i2srx_lrck_ext>, >>>>> - <&tdm_ext>, <&mclk_ext>; >>>>> + <&tdm_ext>, <&mclk_ext>, >>>>> + <&pllclk JH7110_CLK_PLL0_OUT>, >>>>> + <&pllclk JH7110_CLK_PLL1_OUT>, >>>>> + <&pllclk JH7110_CLK_PLL2_OUT>; >>>>> clock-names = "osc", "gmac1_rmii_refin", >>>>> "gmac1_rgmii_rxin", >>>>> "i2stx_bclk_ext", "i2stx_lrck_ext", >>>>> "i2srx_bclk_ext", "i2srx_lrck_ext", >>>>> - "tdm_ext", "mclk_ext"; >>>>> + "tdm_ext", "mclk_ext", >>>>> + "pll0_out", "pll1_out", "pll2_out"; >>>>> #clock-cells = <1>; >>>>> #reset-cells = <1>; >>>>> }; >>>>> @@ -476,6 +480,13 @@ sys_syscon: syscon@13030000 { >>>>> reg = <0x0 0x13030000 0x0 0x1000>; >>>>> }; >>>>> >>>>> + pllclk: pll-clock-controller { >>>> >>>> Does not look like you tested the DTS against bindings. Please run `make >>>> dtbs_check` (see Documentation/devicetree/bindings/writing-schema.rst >>>> for instructions). You should see here warnings of mixing non-MMIO nodes >>>> in MMIO-bus. >>>> >>> >>> Oh I cherry-pick the commit of syscon node and it also include the MMC node. >>> I will remove the MMC node. >>> I used dtbs_check and get the error 'should not be valid under {'type': 'object'}', >>> If I move this node out of the 'soc' node, the dtbs_check will be pass. >>> Is it OK to move the PLL node out of the 'soc' node? Thanks. >> >> Shall it be out side of soc? How it can then do anything with registers? >> This does not look like correct representation of hardware. > > The error appears to be due to a lack of reg base about PLL node. PLL do something with register > by 'sys_syscon' node and the syscon node is in the soc node. Again: And how is this correct representation of hardware? Best regards, Krzysztof
diff --git a/arch/riscv/boot/dts/starfive/jh7110.dtsi b/arch/riscv/boot/dts/starfive/jh7110.dtsi index b6612c53d0d2..0cb8d86ebce5 100644 --- a/arch/riscv/boot/dts/starfive/jh7110.dtsi +++ b/arch/riscv/boot/dts/starfive/jh7110.dtsi @@ -461,12 +461,16 @@ syscrg: clock-controller@13020000 { <&gmac1_rgmii_rxin>, <&i2stx_bclk_ext>, <&i2stx_lrck_ext>, <&i2srx_bclk_ext>, <&i2srx_lrck_ext>, - <&tdm_ext>, <&mclk_ext>; + <&tdm_ext>, <&mclk_ext>, + <&pllclk JH7110_CLK_PLL0_OUT>, + <&pllclk JH7110_CLK_PLL1_OUT>, + <&pllclk JH7110_CLK_PLL2_OUT>; clock-names = "osc", "gmac1_rmii_refin", "gmac1_rgmii_rxin", "i2stx_bclk_ext", "i2stx_lrck_ext", "i2srx_bclk_ext", "i2srx_lrck_ext", - "tdm_ext", "mclk_ext"; + "tdm_ext", "mclk_ext", + "pll0_out", "pll1_out", "pll2_out"; #clock-cells = <1>; #reset-cells = <1>; }; @@ -476,6 +480,13 @@ sys_syscon: syscon@13030000 { reg = <0x0 0x13030000 0x0 0x1000>; }; + pllclk: pll-clock-controller { + compatible = "starfive,jh7110-pll"; + clocks = <&osc>; + #clock-cells = <1>; + starfive,sysreg = <&sys_syscon>; + }; + sysgpio: pinctrl@13040000 { compatible = "starfive,jh7110-sys-pinctrl"; reg = <0x0 0x13040000 0x0 0x10000>;