On Fri, Sep 27, 2013 at 09:21:10PM +0100, Russell King - ARM Linux wrote: > On Fri, Sep 27, 2013 at 02:48:16PM -0500, Matt Sealey wrote: > > 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. 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. 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? -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
