From: Conor Dooley <conor@kernel.org> To: Stephen Boyd <sboyd@kernel.org> Cc: Hal Feng <hal.feng@starfivetech.com>, linux-riscv@lists.infradead.org, devicetree@vger.kernel.org, linux-clk@vger.kernel.org, Palmer Dabbelt <palmer@dabbelt.com>, Rob Herring <robh+dt@kernel.org>, Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>, Michael Turquette <mturquette@baylibre.com>, Philipp Zabel <p.zabel@pengutronix.de>, Emil Renner Berthing <emil.renner.berthing@canonical.com>, linux-kernel@vger.kernel.org Subject: Re: [PATCH v3 07/11] dt-bindings: clock: Add StarFive JH7110 system clock and reset generator Date: Tue, 21 Feb 2023 23:39:32 +0000 [thread overview] Message-ID: <Y/VWNPfApsfm3/UD@spud> (raw) In-Reply-To: <72953dc9371b87da8d03c63633d7d9dd.sboyd@kernel.org> [-- Attachment #1: Type: text/plain, Size: 3865 bytes --] On Tue, Feb 21, 2023 at 02:17:17PM -0800, Stephen Boyd wrote: > Quoting Conor Dooley (2023-02-16 10:20:34) > > On Thu, Feb 16, 2023 at 10:42:20PM +0800, Hal Feng wrote: > > > On Tue, 27 Dec 2022 20:15:20 +0000, Conor Dooley wrote: > > > > On Mon, Dec 26, 2022 at 12:26:32AM +0800, Hal Feng wrote: > > > Please see the picture of these external clocks in clock tree. > > > > > > # mount -t debugfs none /mnt > > > # cat /mnt/clk/clk_summary > > > enable prepare protect duty hardware > > > clock count count count rate accuracy phase cycle enable > > > ------------------------------------------------------------------------------------------------------- > > > *mclk_ext* 0 0 0 12288000 0 0 50000 Y > > > *tdm_ext* 0 0 0 49152000 0 0 50000 Y > > > *i2srx_lrck_ext* 0 0 0 192000 0 0 50000 Y > > > *i2srx_bclk_ext* 0 0 0 12288000 0 0 50000 Y > > > *i2stx_lrck_ext* 0 0 0 192000 0 0 50000 Y > > > *i2stx_bclk_ext* 0 0 0 12288000 0 0 50000 Y > > > *gmac1_rgmii_rxin* 0 0 0 125000000 0 0 50000 Y > > > gmac1_rx 0 0 0 125000000 0 0 50000 Y > > > gmac1_rx_inv 0 0 0 125000000 0 180 50000 Y > > > *gmac1_rmii_refin* 0 0 0 50000000 0 0 50000 Y > > > gmac1_rmii_rtx 0 0 0 50000000 0 0 50000 Y > > > gmac1_tx 0 0 0 50000000 0 0 50000 N > > > gmac1_tx_inv 0 0 0 50000000 0 180 50000 Y > > > *osc* 4 4 0 24000000 0 0 50000 Y > > > apb_func 0 0 0 24000000 0 0 50000 Y > > > ... > > > > > > The clock "gmac1_rgmii_rxin" and the clock "gmac1_rmii_refin" are > > > actually used as the parent of other clocks. > > > > > The "dummy" clocks > > > you said are all internal clocks. > > > > No, what I meant by "dummy" clocks is that if you make clocks "required" > > in the binding that are not needed by the hardware for operation a > > customer of yours might have to add "dummy" clocks to their devicetree > > to pass dtbs_check. > > They can set the phandle specifier to '<0>' to fill in the required > property when there isn't anything there. If this is inside an SoC, it > is always connected because silicon can't change after it is made > (unless this is an FPGA). Therefore, any and all input clocks should be > listed as required. > If the clk controller has inputs that are > pads/balls/pins on the SoC then they can be optional if a valid design > can leave those pins not connected. From the discussion on the dts patches, where the clocks have been put (intentionally) into board.dts, I've been under the impression that we are in this situation. Up to Hal to tell us if the hardware is capable of having those inputs left unfilled! FWIW, there's a v4 [1] of this series - but the question has yet to be resolved. Thanks, Conor. 1 - https://lore.kernel.org/all/20230221024645.127922-1-hal.feng@starfivetech.com/ [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 228 bytes --]
WARNING: multiple messages have this Message-ID (diff)
From: Conor Dooley <conor@kernel.org> To: Stephen Boyd <sboyd@kernel.org> Cc: Hal Feng <hal.feng@starfivetech.com>, linux-riscv@lists.infradead.org, devicetree@vger.kernel.org, linux-clk@vger.kernel.org, Palmer Dabbelt <palmer@dabbelt.com>, Rob Herring <robh+dt@kernel.org>, Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>, Michael Turquette <mturquette@baylibre.com>, Philipp Zabel <p.zabel@pengutronix.de>, Emil Renner Berthing <emil.renner.berthing@canonical.com>, linux-kernel@vger.kernel.org Subject: Re: [PATCH v3 07/11] dt-bindings: clock: Add StarFive JH7110 system clock and reset generator Date: Tue, 21 Feb 2023 23:39:32 +0000 [thread overview] Message-ID: <Y/VWNPfApsfm3/UD@spud> (raw) In-Reply-To: <72953dc9371b87da8d03c63633d7d9dd.sboyd@kernel.org> [-- Attachment #1.1: Type: text/plain, Size: 3865 bytes --] On Tue, Feb 21, 2023 at 02:17:17PM -0800, Stephen Boyd wrote: > Quoting Conor Dooley (2023-02-16 10:20:34) > > On Thu, Feb 16, 2023 at 10:42:20PM +0800, Hal Feng wrote: > > > On Tue, 27 Dec 2022 20:15:20 +0000, Conor Dooley wrote: > > > > On Mon, Dec 26, 2022 at 12:26:32AM +0800, Hal Feng wrote: > > > Please see the picture of these external clocks in clock tree. > > > > > > # mount -t debugfs none /mnt > > > # cat /mnt/clk/clk_summary > > > enable prepare protect duty hardware > > > clock count count count rate accuracy phase cycle enable > > > ------------------------------------------------------------------------------------------------------- > > > *mclk_ext* 0 0 0 12288000 0 0 50000 Y > > > *tdm_ext* 0 0 0 49152000 0 0 50000 Y > > > *i2srx_lrck_ext* 0 0 0 192000 0 0 50000 Y > > > *i2srx_bclk_ext* 0 0 0 12288000 0 0 50000 Y > > > *i2stx_lrck_ext* 0 0 0 192000 0 0 50000 Y > > > *i2stx_bclk_ext* 0 0 0 12288000 0 0 50000 Y > > > *gmac1_rgmii_rxin* 0 0 0 125000000 0 0 50000 Y > > > gmac1_rx 0 0 0 125000000 0 0 50000 Y > > > gmac1_rx_inv 0 0 0 125000000 0 180 50000 Y > > > *gmac1_rmii_refin* 0 0 0 50000000 0 0 50000 Y > > > gmac1_rmii_rtx 0 0 0 50000000 0 0 50000 Y > > > gmac1_tx 0 0 0 50000000 0 0 50000 N > > > gmac1_tx_inv 0 0 0 50000000 0 180 50000 Y > > > *osc* 4 4 0 24000000 0 0 50000 Y > > > apb_func 0 0 0 24000000 0 0 50000 Y > > > ... > > > > > > The clock "gmac1_rgmii_rxin" and the clock "gmac1_rmii_refin" are > > > actually used as the parent of other clocks. > > > > > The "dummy" clocks > > > you said are all internal clocks. > > > > No, what I meant by "dummy" clocks is that if you make clocks "required" > > in the binding that are not needed by the hardware for operation a > > customer of yours might have to add "dummy" clocks to their devicetree > > to pass dtbs_check. > > They can set the phandle specifier to '<0>' to fill in the required > property when there isn't anything there. If this is inside an SoC, it > is always connected because silicon can't change after it is made > (unless this is an FPGA). Therefore, any and all input clocks should be > listed as required. > If the clk controller has inputs that are > pads/balls/pins on the SoC then they can be optional if a valid design > can leave those pins not connected. From the discussion on the dts patches, where the clocks have been put (intentionally) into board.dts, I've been under the impression that we are in this situation. Up to Hal to tell us if the hardware is capable of having those inputs left unfilled! FWIW, there's a v4 [1] of this series - but the question has yet to be resolved. Thanks, Conor. 1 - https://lore.kernel.org/all/20230221024645.127922-1-hal.feng@starfivetech.com/ [-- Attachment #1.2: signature.asc --] [-- Type: application/pgp-signature, Size: 228 bytes --] [-- Attachment #2: Type: text/plain, Size: 161 bytes --] _______________________________________________ linux-riscv mailing list linux-riscv@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-riscv
next prev parent reply other threads:[~2023-02-21 23:40 UTC|newest] Thread overview: 120+ messages / expand[flat|nested] mbox.gz Atom feed top 2022-12-20 0:50 [PATCH v3 00/11] Basic clock and reset support for StarFive JH7110 RISC-V SoC Hal Feng 2022-12-20 0:50 ` Hal Feng 2022-12-20 0:50 ` [PATCH v3 01/11] clk: starfive: Factor out common JH7100 and JH7110 code Hal Feng 2022-12-20 0:50 ` Hal Feng 2022-12-20 21:54 ` Conor Dooley 2022-12-20 21:54 ` Conor Dooley 2022-12-20 0:50 ` [PATCH v3 02/11] clk: starfive: Rename "jh7100" to "jh71x0" for the common code Hal Feng 2022-12-20 0:50 ` Hal Feng 2022-12-20 22:08 ` Conor Dooley 2022-12-20 22:08 ` Conor Dooley 2022-12-23 6:23 ` Hal Feng 2022-12-23 6:23 ` Hal Feng 2022-12-20 0:50 ` [PATCH v3 03/11] reset: Create subdirectory for StarFive drivers Hal Feng 2022-12-20 0:50 ` Hal Feng 2022-12-20 22:15 ` Conor Dooley 2022-12-20 22:15 ` Conor Dooley 2022-12-23 7:02 ` Hal Feng 2022-12-23 7:02 ` Hal Feng 2022-12-20 0:50 ` [PATCH v3 04/11] reset: starfive: Factor out common JH71X0 reset code Hal Feng 2022-12-20 0:50 ` Hal Feng 2022-12-20 22:28 ` Conor Dooley 2022-12-20 22:28 ` Conor Dooley 2022-12-23 7:49 ` Hal Feng 2022-12-23 7:49 ` Hal Feng 2022-12-20 0:50 ` [PATCH v3 05/11] reset: starfive: Rename "jh7100" to "jh71x0" for the common code Hal Feng 2022-12-20 0:50 ` Hal Feng 2022-12-20 2:40 ` kernel test robot 2022-12-20 2:40 ` kernel test robot 2022-12-20 22:31 ` Conor Dooley 2022-12-20 22:31 ` Conor Dooley 2022-12-24 3:48 ` kernel test robot 2022-12-24 3:48 ` kernel test robot 2022-12-20 0:50 ` [PATCH v3 06/11] reset: starfive: jh71x0: Use 32bit I/O on 32bit registers Hal Feng 2022-12-20 0:50 ` Hal Feng 2022-12-20 22:49 ` Conor Dooley 2022-12-20 22:49 ` Conor Dooley 2022-12-20 0:50 ` [PATCH v3 07/11] dt-bindings: clock: Add StarFive JH7110 system clock and reset generator Hal Feng 2022-12-20 0:50 ` Hal Feng 2022-12-20 20:12 ` Rob Herring 2022-12-20 20:12 ` Rob Herring 2022-12-20 23:14 ` Conor Dooley 2022-12-20 23:14 ` Conor Dooley 2022-12-20 23:16 ` Conor Dooley 2022-12-20 23:16 ` Conor Dooley 2022-12-25 16:26 ` Hal Feng 2022-12-25 16:26 ` Hal Feng 2022-12-27 20:15 ` Conor Dooley 2022-12-27 20:15 ` Conor Dooley 2023-02-16 14:42 ` Hal Feng 2023-02-16 14:42 ` Hal Feng 2023-02-16 18:20 ` Conor Dooley 2023-02-16 18:20 ` Conor Dooley 2023-02-17 2:27 ` Hal Feng 2023-02-17 2:27 ` Hal Feng 2023-02-17 7:51 ` Conor Dooley 2023-02-17 7:51 ` Conor Dooley 2023-02-17 12:20 ` Hal Feng 2023-02-17 12:20 ` Hal Feng 2023-02-17 13:32 ` Conor Dooley 2023-02-17 13:32 ` Conor Dooley 2023-02-17 15:47 ` Krzysztof Kozlowski 2023-02-17 15:47 ` Krzysztof Kozlowski 2023-02-17 16:27 ` Conor Dooley 2023-02-17 16:27 ` Conor Dooley 2023-02-18 10:20 ` Krzysztof Kozlowski 2023-02-18 10:20 ` Krzysztof Kozlowski 2023-02-18 11:17 ` Conor Dooley 2023-02-18 11:17 ` Conor Dooley 2023-02-18 14:55 ` Krzysztof Kozlowski 2023-02-18 14:55 ` Krzysztof Kozlowski 2023-02-18 15:08 ` Conor Dooley 2023-02-18 15:08 ` Conor Dooley 2023-02-21 22:17 ` Stephen Boyd 2023-02-21 22:17 ` Stephen Boyd 2023-02-21 23:39 ` Conor Dooley [this message] 2023-02-21 23:39 ` Conor Dooley 2023-02-22 13:27 ` Hal Feng 2023-02-22 13:27 ` Hal Feng 2023-02-22 16:26 ` Conor Dooley 2023-02-22 16:26 ` Conor Dooley 2023-02-23 3:03 ` Hal Feng 2023-02-23 3:03 ` Hal Feng 2023-02-23 6:18 ` Conor Dooley 2023-02-23 6:18 ` Conor Dooley 2023-02-23 9:52 ` Hal Feng 2023-02-23 9:52 ` Hal Feng 2022-12-20 0:50 ` [PATCH v3 08/11] dt-bindings: clock: Add StarFive JH7110 always-on " Hal Feng 2022-12-20 0:50 ` Hal Feng 2022-12-20 20:14 ` Rob Herring 2022-12-20 20:14 ` Rob Herring 2022-12-20 23:19 ` Conor Dooley 2022-12-20 23:19 ` Conor Dooley 2023-02-16 17:19 ` Hal Feng 2023-02-16 17:19 ` Hal Feng 2022-12-20 0:50 ` [PATCH v3 09/11] clk: starfive: Add StarFive JH7110 system clock driver Hal Feng 2022-12-20 0:50 ` Hal Feng 2022-12-23 9:57 ` kernel test robot 2022-12-23 9:57 ` kernel test robot 2023-01-05 11:32 ` kernel test robot 2023-01-05 11:32 ` kernel test robot 2023-02-19 21:23 ` Emil Renner Berthing 2023-02-19 21:23 ` Emil Renner Berthing 2023-02-21 6:44 ` Hal Feng 2023-02-21 6:44 ` Hal Feng 2022-12-20 0:50 ` [PATCH v3 10/11] clk: starfive: Add StarFive JH7110 always-on " Hal Feng 2022-12-20 0:50 ` Hal Feng 2022-12-23 11:28 ` kernel test robot 2022-12-23 11:28 ` kernel test robot 2023-01-05 13:44 ` kernel test robot 2023-01-05 13:44 ` kernel test robot 2022-12-20 0:50 ` [PATCH v3 11/11] reset: starfive: Add StarFive JH7110 reset driver Hal Feng 2022-12-20 0:50 ` Hal Feng 2022-12-20 7:14 ` kernel test robot 2022-12-20 7:14 ` kernel test robot 2022-12-23 12:39 ` kernel test robot 2022-12-23 12:39 ` kernel test robot 2022-12-27 19:20 ` kernel test robot 2022-12-27 19:20 ` kernel test robot 2023-01-05 15:35 ` kernel test robot 2023-01-05 15:35 ` kernel test robot
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=Y/VWNPfApsfm3/UD@spud \ --to=conor@kernel.org \ --cc=devicetree@vger.kernel.org \ --cc=emil.renner.berthing@canonical.com \ --cc=hal.feng@starfivetech.com \ --cc=krzysztof.kozlowski+dt@linaro.org \ --cc=linux-clk@vger.kernel.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-riscv@lists.infradead.org \ --cc=mturquette@baylibre.com \ --cc=p.zabel@pengutronix.de \ --cc=palmer@dabbelt.com \ --cc=robh+dt@kernel.org \ --cc=sboyd@kernel.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.