From: Shawn Guo <shawn.guo@xxxxxxxxxx> Data: Sunday, September 29, 2013 2:13 PM > To: Russell King - ARM Linux > Cc: devicetree@xxxxxxxxxxxxxxx; Fabio Estevam; linux-arm- > kernel@xxxxxxxxxxxxxxxxxxx; Matt Sealey > Subject: Re: device tree binding documentation outdated > > On Sat, Sep 28, 2013 at 09:38:59AM +0100, Russell King - ARM Linux wrote: > > Okay, the answer is that yes, GPR1 bit 21 should be clear on this > > version of the hardware, but there's plans to have the IMX6 generate > > the clock and remove the crystal for the AR8035. > > Be careful, as mentioned in the reply to Matt, in that case, IMX6 can only > output the clock on pad GPIO_16, and the clock has to be externally routed > back to IMX6 on pad ENET_REF_CLK, so that ENET can get reference clock for > RGMII mode. > > > Now, here's the question for the IMX6 maintainers: how do I avoid > > having > > GPR1 bit 21 set - it's unconditionally set by imx6q_1588_init() in > > arch/arm/mach-imx/mach-imx6q.c. Moreover, how do I control this from > > DT? > > GPR1[21] should be cleared only when there is a clock input on pad > GPIO_16 from external phy or oscillator. Other than that, GPR1[21] should > always be set to loop the ENET_PLL clock back to ENET though pad GPIO_16, > for at least getting PTP (IEEE 1588) work, even in RGMII mode. > > So far, we haven't got any user with that setup (external phy or > oscillator generates clock to pad GPIO_16). When we do, we can add a > device tree property for telling that. Shawn, for RGMII mode, RGMII tx_clk cannot get external clock via GPIO_16, only by ENET_REF_CLK PAD. For RMII mode, enet refrenece clock can get external clock via GPIO_16 and RGMII_TX_CTL PADs. Thanks, Andy -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
