From: Andy Duan <fugang.duan@nxp.com> To: Sven Van Asbroeck <thesven73@gmail.com>, Fabio Estevam <festevam@gmail.com> Cc: Shawn Guo <shawnguo@kernel.org>, Rob Herring <robh+dt@kernel.org>, "David S. Miller" <davem@davemloft.net>, Jakub Kicinski <kuba@kernel.org>, netdev <netdev@vger.kernel.org>, "open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS" <devicetree@vger.kernel.org>, Sascha Hauer <s.hauer@pengutronix.de>, Pengutronix Kernel Team <kernel@pengutronix.de>, dl-linux-imx <linux-imx@nxp.com>, "moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE" <linux-arm-kernel@lists.infradead.org>, linux-kernel <linux-kernel@vger.kernel.org> Subject: RE: [EXT] Re: [PATCH v5 3/3] ARM: imx6plus: optionally enable internal routing of clk_enet_ref Date: Sun, 5 Jul 2020 14:45:02 +0000 [thread overview] Message-ID: <AM6PR0402MB360781DA3F738C2DF445E821FF680@AM6PR0402MB3607.eurprd04.prod.outlook.com> (raw) In-Reply-To: <CAGngYiXGXDqCZeJme026uz5FjU56UojmQFFiJ5_CZ_AywdQiEw@mail.gmail.com> From: Sven Van Asbroeck <thesven73@gmail.com> > Hi Fabio, Andy, > > On Thu, Jul 2, 2020 at 6:29 PM Fabio Estevam <festevam@gmail.com> wrote: > > > > With the device tree approach, I think that a better place to touch > > GPR5 would be inside the fec driver. > > > > Are we 100% sure this is the best way forward, though? > > All the FEC driver should care about is the FEC logic block inside the SoC. It > should not concern itself with the way a SoC happens to bring a clock (PTP > clock) to the input of the FEC logic block - that is purely a SoC implementation > detail. I also agree with that relates to SOC integration. > > It makes sense to add fsl,stop-mode (= a GPR bit) to the FEC driver, as this bit > is a logic input to the FEC block, which the driver needs to dynamically flip. > > But the PTP clock is different, because it's statically routed by the SoC. > > Maybe this problem needs a clock routing solution? > Isn't there an imx6q plus clock mux we're not modelling? > > enet_ref-o------>ext>---pad_clk--| \ > | |M |----fec_ptp_clk > o-----------------------|_/ > > Where M = mux controlled by GPR5[9] > > The issue here is that pad_clk is routed externally, so its parent could be any > internal or external clock. I have no idea how to model this in the clock > framework. Don't consider it complex, GPR5[9] just select the rgmii gtx source from PAD or internal Like: GPR5[9] is cleared: PAD -> MAC gtx GPR5[9] is set: Pll_enet -> MAC gtx As you said, register one clock mux for the selection, assign the clock parent by board dts file, but now current clock driver doesn't support GPR clock.
WARNING: multiple messages have this Message-ID (diff)
From: Andy Duan <fugang.duan@nxp.com> To: Sven Van Asbroeck <thesven73@gmail.com>, Fabio Estevam <festevam@gmail.com> Cc: "open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS" <devicetree@vger.kernel.org>, netdev <netdev@vger.kernel.org>, Sascha Hauer <s.hauer@pengutronix.de>, linux-kernel <linux-kernel@vger.kernel.org>, Rob Herring <robh+dt@kernel.org>, dl-linux-imx <linux-imx@nxp.com>, Pengutronix Kernel Team <kernel@pengutronix.de>, Jakub Kicinski <kuba@kernel.org>, Shawn Guo <shawnguo@kernel.org>, "David S. Miller" <davem@davemloft.net>, "moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE" <linux-arm-kernel@lists.infradead.org> Subject: RE: [EXT] Re: [PATCH v5 3/3] ARM: imx6plus: optionally enable internal routing of clk_enet_ref Date: Sun, 5 Jul 2020 14:45:02 +0000 [thread overview] Message-ID: <AM6PR0402MB360781DA3F738C2DF445E821FF680@AM6PR0402MB3607.eurprd04.prod.outlook.com> (raw) In-Reply-To: <CAGngYiXGXDqCZeJme026uz5FjU56UojmQFFiJ5_CZ_AywdQiEw@mail.gmail.com> From: Sven Van Asbroeck <thesven73@gmail.com> > Hi Fabio, Andy, > > On Thu, Jul 2, 2020 at 6:29 PM Fabio Estevam <festevam@gmail.com> wrote: > > > > With the device tree approach, I think that a better place to touch > > GPR5 would be inside the fec driver. > > > > Are we 100% sure this is the best way forward, though? > > All the FEC driver should care about is the FEC logic block inside the SoC. It > should not concern itself with the way a SoC happens to bring a clock (PTP > clock) to the input of the FEC logic block - that is purely a SoC implementation > detail. I also agree with that relates to SOC integration. > > It makes sense to add fsl,stop-mode (= a GPR bit) to the FEC driver, as this bit > is a logic input to the FEC block, which the driver needs to dynamically flip. > > But the PTP clock is different, because it's statically routed by the SoC. > > Maybe this problem needs a clock routing solution? > Isn't there an imx6q plus clock mux we're not modelling? > > enet_ref-o------>ext>---pad_clk--| \ > | |M |----fec_ptp_clk > o-----------------------|_/ > > Where M = mux controlled by GPR5[9] > > The issue here is that pad_clk is routed externally, so its parent could be any > internal or external clock. I have no idea how to model this in the clock > framework. Don't consider it complex, GPR5[9] just select the rgmii gtx source from PAD or internal Like: GPR5[9] is cleared: PAD -> MAC gtx GPR5[9] is set: Pll_enet -> MAC gtx As you said, register one clock mux for the selection, assign the clock parent by board dts file, but now current clock driver doesn't support GPR clock. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2020-07-05 14:45 UTC|newest] Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top 2020-07-02 17:53 [PATCH v5 1/3] ARM: imx: mach-imx6q: Search for fsl,imx6q-iomuxc-gpr earlier Sven Van Asbroeck 2020-07-02 17:53 ` [PATCH v5 1/3] ARM: imx: mach-imx6q: Search for fsl, imx6q-iomuxc-gpr earlier Sven Van Asbroeck 2020-07-02 17:53 ` [PATCH v5 2/3] dt-bindings: fec: add fsl,ptpclk-bypass-pad boolean property Sven Van Asbroeck 2020-07-02 17:53 ` [PATCH v5 2/3] dt-bindings: fec: add fsl, ptpclk-bypass-pad " Sven Van Asbroeck 2020-07-02 17:53 ` [PATCH v5 3/3] ARM: imx6plus: optionally enable internal routing of clk_enet_ref Sven Van Asbroeck 2020-07-02 17:53 ` Sven Van Asbroeck 2020-07-02 22:29 ` Fabio Estevam 2020-07-02 22:29 ` Fabio Estevam 2020-07-03 0:50 ` Sven Van Asbroeck 2020-07-03 0:50 ` Sven Van Asbroeck 2020-07-03 2:01 ` [EXT] " Andy Duan 2020-07-03 2:01 ` Andy Duan 2020-07-04 14:08 ` Sven Van Asbroeck 2020-07-04 14:08 ` Sven Van Asbroeck 2020-07-05 14:45 ` Andy Duan [this message] 2020-07-05 14:45 ` [EXT] " Andy Duan 2020-07-05 15:34 ` Sven Van Asbroeck 2020-07-05 15:34 ` Sven Van Asbroeck 2020-07-06 5:30 ` Andy Duan 2020-07-06 5:30 ` Andy Duan 2020-07-06 13:46 ` Fabio Estevam 2020-07-06 13:46 ` Fabio Estevam 2020-07-06 14:58 ` Sven Van Asbroeck 2020-07-06 14:58 ` Sven Van Asbroeck 2020-07-06 14:59 ` Sven Van Asbroeck 2020-07-06 14:59 ` Sven Van Asbroeck 2020-07-07 3:38 ` Andy Duan 2020-07-07 3:38 ` Andy Duan 2020-07-07 15:21 ` Sven Van Asbroeck 2020-07-07 15:21 ` Sven Van Asbroeck 2020-07-08 5:16 ` Andy Duan 2020-07-08 5:16 ` Andy Duan 2020-07-06 14:53 ` Sven Van Asbroeck 2020-07-06 14:53 ` Sven Van Asbroeck
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=AM6PR0402MB360781DA3F738C2DF445E821FF680@AM6PR0402MB3607.eurprd04.prod.outlook.com \ --to=fugang.duan@nxp.com \ --cc=davem@davemloft.net \ --cc=devicetree@vger.kernel.org \ --cc=festevam@gmail.com \ --cc=kernel@pengutronix.de \ --cc=kuba@kernel.org \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=linux-imx@nxp.com \ --cc=linux-kernel@vger.kernel.org \ --cc=netdev@vger.kernel.org \ --cc=robh+dt@kernel.org \ --cc=s.hauer@pengutronix.de \ --cc=shawnguo@kernel.org \ --cc=thesven73@gmail.com \ /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.