Re: device tree binding documentation outdated

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

On Fri, Sep 27, 2013 at 02:48:16PM -0500, Matt Sealey wrote:
> On Fri, Sep 27, 2013 at 2:41 PM, Matt Sealey <neko-HhXTZounMxbZATc7fWT8Dg@public.gmane.org> wrote:
> > On Fri, Sep 27, 2013 at 2:05 PM, Russell King - ARM Linux
> > <linux-lFZ/pmaqli7XmaaqVzeoHQ@public.gmane.org> wrote:
> >> I've got good news... finally!
> >>
> > 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)
> 
> Ignore that. It's not totally wrong but it's weird. This is really
> difficult to put into words...
> 
> GPR1[21] = 0 i.MX6 receives a clock from the PHY. You need to generate
> a clock at the PHY as input to the MAC. The MAC won't run until the
> PHY is out of reset and the clock is generated. You may need SION set
> for RMII depending on the pin...
> GPR1[21] = 1 implies we generate a clock from i.MX6 TO the PHY. The
> clock is looped back through the pad to the MAC. SION is irrelevant.
> 
> Still want to know who's clock it is and where it should be going....

As I said, when Rabeeh is around, I will ask questions about this.
I'm fairly certain that we don't need _all_ those ethernet pinmux
settings (we just need the RGMII ones, and can omit the MII ones.)

Having hacked on this solidly since about 5pm yesterday, I'm not going
to spend very much time on this until later next week, or I can talk to
Rabeeh.
--
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