device tree binding documentation outdated

[Matt Sealey]

On Fri, Sep 27, 2013 at 2:05 PM, Russell King - ARM Linux
<linux at arm.linux.org.uk> wrote:
> I've got good news... finally!
>
> On Fri, Sep 27, 2013 at 01:33:35PM -0500, Matt Sealey wrote:
>> On Fri, Sep 27, 2013 at 12:49 PM, Russell King - ARM Linux
>> <linux at arm.linux.org.uk> wrote:
>> > Okay, but from what I'm working from (which works) the order is:
>> >
>> > - Set IOMUXC GPR1 bit 21.
>>
>> Just to clarify: set or clear? It should be clear if the PHY provides
>> the clock to the MAC, and set if the MAC provides the clock to the
>> PHY. There can be only one, Highlander!
>
> Well, the patch tells me:
>
> +       /* Set GPR1, bit 21 to 1 */
> +       mxc_iomux_set_gpr_register(1, 21, 1, 1);

But you're setting the MAC clock up, and the MAC clock always goes out
over RGMII_TXC and the PHY needs to use it.. so it works.

But that means setting up SION bits and setting ENET_REF_CLK up for
input is absolutely pointless..

This means the clock is being generated by the ethernet PLL

>> > - Set ipg/ahb ethernet clock to 50MHz
>>
>> Hmm.. this might be a touch low, but it's not the issue here. The way
>> I recall this working, the IP has a clock (IPG, AHB as above) and
>> there is a MAC clock too which you're generating from DIV_SELECT in
>> the ENET_PLL. They don't have to be the same..
>
> Actually, this is the issue.  I now have doubts that the patches which
> Rabeeh gave us early-developers correspond with the kernel binary he
> rushed to us on Wednesday (he wasn't expecting them to be delivered soo
> quickly.)
>
> Rabeeh says in the wiki that his patches should be applied on top of
> 3.0.35 BSP 4.1.0, and the patches contain this:
>
> +       /* Set enet clock to 50MHz RMII */

Note, RMII, not RGMII !!!!

Can you tell us what board you got:

http://cubox-i.com/table/

Subtle difference which I know I just faceplanted on in my previous
mail.. Same concept though... but if you have a DualLite then you
don't HAVE gigabit ethernet... a 125MHz clock is ridiculous, and Fabio
gave you the wrong manual.

If it's a Dual or Quad, then you do have gigabit... and the below applies..

> The real answer is: don't believe what you see in the patch!  This
> will fail on BSP 4.1.0.  Removing my hack to do this in my kernel...
> gets the ethernet working at both gigabit and 100mbit speeds!
>
> Now, I'm not going to say that anything with regard to that GPR bit
> is correct - but what I have now is something which does indeed work.
> I did hang a scope on that signal (my scope probes have small tips
> which can get on the solder pads up to the AR8035) and it didn't
> show signs of any contention.

I'm glad you have a scope..

It's not contention at all - the clocks never see each other on the
same pins. But there would be TWO 125MHz clocks being generated. One
at the MAC - which outputs to the PHY via TXC. And also you're
instructing the PHY to generate a 125MHz clock which should be input
to the MAC.. and it would use this for RXC too, and possibly for
internal clocking when it reads data accompanied TXC being clocked.
Screwy..

Usually you have an XTALIN on the PHY, and a REF_CLK out. There are
two main configurations;

* XTALIN connected to an oscillator, generating REF_CLK which is sent to the MAC
* XTALIN is connected to the MAC, REF_CLK is useless

The difference would be

* In the top situation, your PHY is generating the clock for the
entire system - the i.MX6 takes it and uses it drive logic and to
clock receive and sends it back out on TXC to transmit data (GPR1[21]
= 0)
* In the bottom situation, the i.MX6 generates a clock, the PHY uses
it to drive it's logic AND generate other clocks, and the i.MX6 clock
is looped back through the pad to the MAC to drive it's logic and
clock transmit data (GPR1[21] = 1)

And if you're driving it how I think you are what you're doing is
seeing XTALIN to the PHY from an external clock, the PHY is generating
ENET_REF_CLK to the i.MX6, but the i.MX6 is ignoring it and driving
it's logic and clocking data from it's internal reference clock.

Given the boards aren't released and the kernel you got isn't public,
I can't even look at the mess... is there any way you can convince
these guys to chop out a tiny section of the schematic vis a vis PHY
connection and strapping to the i.MX6, hopefully with some indicator
data direction? It's REALLY not possible, however you look at it, to
develop a device tree pinmuxing spec for a board without the
schematic. Who knows what horse shit is in the code they sent (if it's
based on the Freescale BSP, there could be upwards of 3 or 4 weird
reference-board-specific hacks littered around that don't apply to
their custom design and you shouldn't copy-paste them in)

The question is here, really, does the PHY have it's own crystal
input, and is it meant to provide the 125MHz clock, and do we want to
drive the MAC with it? Or does it get it's clock from the i.MX6?

--
Matt