Re: device tree binding documentation outdated

[Russell King - ARM Linux <linux-lFZ/pmaqli7XmaaqVzeoHQ@public.gmane.org>]

On Fri, Sep 27, 2013 at 02:41:53PM -0500, Matt Sealey wrote:
> On Fri, Sep 27, 2013 at 2:05 PM, Russell King - ARM Linux
> <linux-lFZ/pmaqli7XmaaqVzeoHQ@public.gmane.org> wrote:
> > 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

Interesting.  Looking in the patches, there's a need to disable some
modes on the phy - i wonder if this is why.  As I said, I think there
is some scope for experimentation here.  I think that even Rabeeh only
sorted this out internally within solid-run during the last week, so
it could be that some of these settings are sub-optimal.

When I next see Rabeeh around, I'll talk to him about it.

> >> > - 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..

Okay, this is where things get a ltitle complicated.  The pre-release
dev hardware is not the final cubox hardware - it's a development
platform, which is currently fitted with a IMX6 Solo with an AR8035
phy.  The IXM6 Solo is gigabit capable, as is the AR8035.

There's support in Rabeeh's patches for an AR8030, which is a fast
ethernet phy (no gigabit).

I suspect that the production Cubox-i hardware will have an AR8030
fitted to the lower end models, but an AR8035 to the higher end,
while the dev hardware is a mix of low-end and high-end.

If you look at my photo of the dev hardware on google+, you'll notice
its quite different from the 2x2x2 form factor of the final product:

https://plus.google.com/103895730806848715870/posts/GMnPj1w8CGZ

> The question is here, really, does the PHY have it's own crystal
> input, ...

Yes it does.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html