From: Sven Van Asbroeck <thesven73@gmail.com> To: Fabio Estevam <festevam@gmail.com> Cc: Andy Duan <fugang.duan@nxp.com>, Shawn Guo <shawnguo@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 v4 2/2] ARM: imx6plus: enable internal routing of clk_enet_ref where possible Date: Wed, 1 Jul 2020 09:51:33 -0400 [thread overview] Message-ID: <CAGngYiWV93yWY-mWM-1YcRU71iWnP=qsLSD6Z5dZkz=Zb+iqRA@mail.gmail.com> (raw) In-Reply-To: <CAOMZO5CZMBeSY=0sa39wJsZpaCqWeCb4-HG4jjXO5pGeW64azg@mail.gmail.com> Andy, Fabio, Does the following describe the mainline situation? Please correct if not. 1. imx6 ethernet ref_clk can be generated internally (by imx6) or externally (by PHY or oscillator on PCB) 2. if internal, fec's "ptp" clock in devicetree should be <&clks IMX6QDL_CLK_ENET_REF> 3. if external, fec's "ptp" clock should be that external clock, see 810c0ca879098 ("ARM: imx6q: support ptp and rmii clock from pad") 4. sabresd devicetree describes "ptp" clock as IMX6QDL_CLK_ENET_REF, although it's externally supplied (by PHY). This is incorrect. 5. nevertheless sabresd will work, because FEC driver can still work when the PTP clock in devicetree is different from supplied PTP clock 6. sabresd plus believes FEC is clocked internally, so flips the bit which routes the ptp clock internally 7. this breaks sabresd plus, as default internal clock is unsuitable 8. sabresd is sample board, so all boards based on sabresd may have the same issue, and break Solution 1: - describe sabresd ptp clock correctly in devicetree - "clean/correct" solution - may break other imx6q plus boards in mainline - may break out-of-tree (private) imx6q plus devicetrees based on sabresd Solution 2: - on plus, never route PTP clock internally by default use a devicetree property instead - complex solution, hard to understand if newcomer - prevents sabresd / clones breakage Solution 3: - set sabresd ptp clock freq to same as externally supplied clock - may still break designs based on sabresd - hard to understand what's actually happening Other solutions??
WARNING: multiple messages have this Message-ID (diff)
From: Sven Van Asbroeck <thesven73@gmail.com> To: Fabio Estevam <festevam@gmail.com> Cc: Andy Duan <fugang.duan@nxp.com>, Sascha Hauer <s.hauer@pengutronix.de>, linux-kernel <linux-kernel@vger.kernel.org>, dl-linux-imx <linux-imx@nxp.com>, Pengutronix Kernel Team <kernel@pengutronix.de>, Shawn Guo <shawnguo@kernel.org>, "moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE" <linux-arm-kernel@lists.infradead.org> Subject: Re: [EXT] Re: [PATCH v4 2/2] ARM: imx6plus: enable internal routing of clk_enet_ref where possible Date: Wed, 1 Jul 2020 09:51:33 -0400 [thread overview] Message-ID: <CAGngYiWV93yWY-mWM-1YcRU71iWnP=qsLSD6Z5dZkz=Zb+iqRA@mail.gmail.com> (raw) In-Reply-To: <CAOMZO5CZMBeSY=0sa39wJsZpaCqWeCb4-HG4jjXO5pGeW64azg@mail.gmail.com> Andy, Fabio, Does the following describe the mainline situation? Please correct if not. 1. imx6 ethernet ref_clk can be generated internally (by imx6) or externally (by PHY or oscillator on PCB) 2. if internal, fec's "ptp" clock in devicetree should be <&clks IMX6QDL_CLK_ENET_REF> 3. if external, fec's "ptp" clock should be that external clock, see 810c0ca879098 ("ARM: imx6q: support ptp and rmii clock from pad") 4. sabresd devicetree describes "ptp" clock as IMX6QDL_CLK_ENET_REF, although it's externally supplied (by PHY). This is incorrect. 5. nevertheless sabresd will work, because FEC driver can still work when the PTP clock in devicetree is different from supplied PTP clock 6. sabresd plus believes FEC is clocked internally, so flips the bit which routes the ptp clock internally 7. this breaks sabresd plus, as default internal clock is unsuitable 8. sabresd is sample board, so all boards based on sabresd may have the same issue, and break Solution 1: - describe sabresd ptp clock correctly in devicetree - "clean/correct" solution - may break other imx6q plus boards in mainline - may break out-of-tree (private) imx6q plus devicetrees based on sabresd Solution 2: - on plus, never route PTP clock internally by default use a devicetree property instead - complex solution, hard to understand if newcomer - prevents sabresd / clones breakage Solution 3: - set sabresd ptp clock freq to same as externally supplied clock - may still break designs based on sabresd - hard to understand what's actually happening Other solutions?? _______________________________________________ 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-01 13:51 UTC|newest] Thread overview: 42+ messages / expand[flat|nested] mbox.gz Atom feed top 2020-06-25 14:01 [PATCH v4 1/2] ARM: imx: mach-imx6q: Search for fsl,imx6q-iomuxc-gpr earlier Sven Van Asbroeck 2020-06-25 14:01 ` [PATCH v4 1/2] ARM: imx: mach-imx6q: Search for fsl, imx6q-iomuxc-gpr earlier Sven Van Asbroeck 2020-06-25 14:01 ` [PATCH v4 2/2] ARM: imx6plus: enable internal routing of clk_enet_ref where possible Sven Van Asbroeck 2020-06-25 14:01 ` Sven Van Asbroeck 2020-06-28 5:05 ` [EXT] " Andy Duan 2020-06-28 5:05 ` Andy Duan 2020-06-29 13:09 ` Fabio Estevam 2020-06-29 13:09 ` Fabio Estevam 2020-06-29 13:40 ` Sven Van Asbroeck 2020-06-29 13:40 ` Sven Van Asbroeck 2020-06-29 14:04 ` Fabio Estevam 2020-06-29 14:04 ` Fabio Estevam 2020-06-29 14:25 ` Fabio Estevam 2020-06-29 14:25 ` Fabio Estevam 2020-06-29 14:37 ` Sven Van Asbroeck 2020-06-29 14:37 ` Sven Van Asbroeck 2020-06-30 6:36 ` [EXT] " Andy Duan 2020-06-30 6:36 ` Andy Duan 2020-06-30 11:49 ` Fabio Estevam 2020-06-30 11:49 ` Fabio Estevam 2020-07-01 1:31 ` Andy Duan 2020-07-01 1:31 ` Andy Duan 2020-06-30 15:23 ` Sven Van Asbroeck 2020-06-30 15:23 ` Sven Van Asbroeck 2020-07-01 3:18 ` Andy Duan 2020-07-01 3:18 ` Andy Duan 2020-07-01 3:39 ` Fabio Estevam 2020-07-01 3:39 ` Fabio Estevam 2020-07-01 3:42 ` Andy Duan 2020-07-01 3:42 ` Andy Duan 2020-07-01 3:45 ` Fabio Estevam 2020-07-01 3:45 ` Fabio Estevam 2020-07-01 13:51 ` Sven Van Asbroeck [this message] 2020-07-01 13:51 ` Sven Van Asbroeck 2020-07-01 15:30 ` Andy Duan 2020-07-01 15:30 ` Andy Duan 2020-07-01 16:03 ` Sven Van Asbroeck 2020-07-01 16:03 ` Sven Van Asbroeck 2020-07-01 16:39 ` Fabio Estevam 2020-07-01 16:39 ` Fabio Estevam 2020-06-30 2:24 ` Andy Duan 2020-06-30 2:24 ` Andy Duan
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='CAGngYiWV93yWY-mWM-1YcRU71iWnP=qsLSD6Z5dZkz=Zb+iqRA@mail.gmail.com' \ --to=thesven73@gmail.com \ --cc=festevam@gmail.com \ --cc=fugang.duan@nxp.com \ --cc=kernel@pengutronix.de \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=linux-imx@nxp.com \ --cc=linux-kernel@vger.kernel.org \ --cc=s.hauer@pengutronix.de \ --cc=shawnguo@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.