device tree binding documentation outdated

From:  Shawn Guo <redacted>
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:

quoted

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.

quoted

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