ARM: imx6q: skip ethernet refclock reconfiguration if enet_clk_ref is present
Current mach-imx6q code has following logic: - if ptp clock of the ethernet controller node is attached to the SoC internal enet_ref clock, then we configure RMII reference clock pin as output by setting IOMUXC_GPR1 BIT(21). In this case - MAC (SoC) is the clock provider, PHY is the clock consumer. - if ptp clock of the ethernet controller node is not attached to the enet_ref clock, then we configure RMII reference clock pin as input by clearing IOMUXC_GPR1 BIT(21). In this case - PHY is the clock provider, MAC is the clock consumer. According to the Freescale MX6SDL ReferenceManual v4, IOMUXC_GPR1 BIT(21) (page 2033) this configuration bit is not related to the PTP (IEEE1588) clock: 21 ENET_CLK_SEL - choose enet reference clk mode: 0 - get enet tx reference clk from pad (external OSC for both external PHY and Internal Controller) 1 - get enet tx reference clk from internal clock from anatop (loopback through pad), this clock also sent out to external PHY. According to the Documentation/devicetree/bindings/net/fsl,fec.yaml: The "ptp"(option), for IEEE1588 timer clock that requires the clock. The "enet_clk_ref"(option), for MAC transmit/receiver reference clock like RGMII TXC clock or RMII reference clock. It depends on board design, the clock is required if RGMII TXC and RMII reference clock source from SOC internal PLL. The "enet_out"(option), output clock for external device, like supply clock for PHY. The clock is required if PHY clock source from SOC. We can see, that "enet_clk_ref" clock is the best fit for this purpose. Other properties like "ptp" is designed for IEEE1588 and "enet_out" do not have real functionality within imx related clock infrastructure. Since the "enet_clk_ref" is not used by the imx6qdl devicetrees, we can use it as indicator of potentially properly configured DT. At same time we can keep ptp clock based logic as the fallback for old DTs. Signed-off-by: Oleksij Rempel <o.rempel@pengutronix.de> Signed-off-by: Shawn Guo <shawnguo@kernel.org>
Showing
Please register or sign in to comment