On Sun, Sep 29, 2013 at 02:13:05PM +0800, Shawn Guo wrote:

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.

Let me repeat that in case it was unclear.

The AR8035 on the current boards has a 25MHz crystal, and the AR8035 is
*currently* required to be programmed to generate a 125MHz clock back to
the IMX6 for the transmit timings.

In future, and on the real cubox-i, this crystal will not be present, and
it will be required that the IMX6 generates the 25MHz clock for the
AR8035.

So, for the _existing_ hardware, it is _required_ that the AR8035
generates the transmit clock, and this is fed in on GPIO 16 as
ENET_REF_CLK.  This means that SION for this *must* be set and
GPR1 bit 21 *must* be clear.

So:

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.

We need a property for this if we wish to support the carrier-1 development
board that Solid-run sent out to a load of developers last week.  If not,
I guess those guys like Olof will find that they won't have properly
configured ethernet support on their boards they've received in mainline
kernels.

I think that as a fair number of key kernel developers now have this
board with this requirement, we need to have this DT property provided
even though the final cubox-i will not require it.