[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <AM6PR0402MB36077C422DABCB4F2EA650A0FF6F0@AM6PR0402MB3607.eurprd04.prod.outlook.com>
Date: Tue, 30 Jun 2020 06:36:39 +0000
From: Andy Duan <fugang.duan@....com>
To: Sven Van Asbroeck <thesven73@...il.com>,
Fabio Estevam <festevam@...il.com>
CC: Shawn Guo <shawnguo@...nel.org>,
Sascha Hauer <s.hauer@...gutronix.de>,
Pengutronix Kernel Team <kernel@...gutronix.de>,
dl-linux-imx <linux-imx@....com>,
"moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE"
<linux-arm-kernel@...ts.infradead.org>,
linux-kernel <linux-kernel@...r.kernel.org>
Subject: RE: [EXT] Re: [PATCH v4 2/2] ARM: imx6plus: enable internal routing
of clk_enet_ref where possible
From: Sven Van Asbroeck <thesven73@...il.com> Sent: Monday, June 29, 2020 10:37 PM
> On Mon, Jun 29, 2020 at 10:26 AM Fabio Estevam <festevam@...il.com>
> wrote:
> >
> > Just tested 5.4.24_2.1.0 on an imx6qp sabresd and DHCP also fails there.
>
> I think I discovered the problem !
>
> When I compare the sabresd devicetree on mainline with the actual sabresd
> schematics, the devicetree is incorrect ! Things still work, but only by
> accident.
>
> The sabresd has an AR8131 PHY, which generates the enet ref clock, not the
> imx6. So on the schematic we see that the clock output of the PHY is wired to
> imx6 ENET_REF_CLK, so it can be used as a clock source. And GPIO_16 is
> disconnected, as it should, because the imx6 is not generating the ref clk.
>
> But the devicetree is written as if the imx6 is providing the clock ! See
> here:
>
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit.ker
> nel.org%2Fpub%2Fscm%2Flinux%2Fkernel%2Fgit%2Fstable%2Flinux.git%2Ftr
> ee%2Farch%2Farm%2Fboot%2Fdts%2Fimx6qdl-sabresd.dtsi%3Fh%3Dv5.7.6
> %23n513&data=02%7C01%7Cfugang.duan%40nxp.com%7C16c43e8d9d
> 8e4ff0b9ee08d81c39f7f2%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7
> C0%7C637290382588751887&sdata=hCRNGa9WrQzQ0XYwR%2FQTQ8h
> jY7CDHjhIbXr0L33fr%2Bc%3D&reserved=0
>
> Also there is no override of the fec PTP clock:
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit.ker
> nel.org%2Fpub%2Fscm%2Flinux%2Fkernel%2Fgit%2Fstable%2Flinux.git%2Ftr
> ee%2Farch%2Farm%2Fboot%2Fdts%2Fimx6qdl-sabresd.dtsi%3Fh%3Dv5.7.6
> %23n202&data=02%7C01%7Cfugang.duan%40nxp.com%7C16c43e8d9d
> 8e4ff0b9ee08d81c39f7f2%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7
> C0%7C637290382588751887&sdata=qOfiLs%2FGi01h9hSA787PHfGxTN
> bfYWFXVA3IhUB553Q%3D&reserved=0
>
> Although Shawn's mainline patch mandates this?
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit.ker
> nel.org%2Fpub%2Fscm%2Flinux%2Fkernel%2Fgit%2Fstable%2Flinux.git%2Fco
> mmit%2F%3Fh%3Dv5.7.6%26id%3D810c0ca879098a993e2ce0a190d24d11c
> 17df748&data=02%7C01%7Cfugang.duan%40nxp.com%7C16c43e8d9d8
> e4ff0b9ee08d81c39f7f2%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C
> 0%7C637290382588751887&sdata=3PiAnDlxO8iqsVR6YQWjCk1xsg8iW
> RK8TSGee4LhkjI%3D&reserved=0
>
> This will work, but only by accident. So on a plus, when we
> (incorrectly) switch the
> bypass bit on, things stop working.
Fabio, our QA double verify 5.4.24_2.1.0, no matter SD boot or tftp/nfs boot,
both work fine on i.MX6QP sabresd board, please double check your environment.
Sven, no matter PHY supply 125Mhz clock to pad or not, GPR5[9] is to select RGMII
gtx clock source from:
- 0 Clock from pad
- 1 Clock from PLL
Since i.MX6QP can internally supply clock to MAC, we can set GPR5[9] bit by default.
Powered by blists - more mailing lists