device tree binding documentation outdated

[Duan Fugang-B38611]

From:  Shawn Guo <shawn.guo at linaro.org>
Data: Sunday, September 29, 2013 2:13 PM

> To: Russell King - ARM Linux
> Cc: devicetree at vger.kernel.org; Fabio Estevam; linux-arm-
> kernel at lists.infradead.org; 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