| Message ID | 20140115073536.GD1914@S2101-09.ap.freescale.net |
|---|---|
| State | New |
| Headers | show |
On Wed, Jan 15, 2014 at 7:45 AM, Philippe De Muyter <phdm@macq.eu> wrote: > Here are my patches (I have called my board imx6dl-p6-2094): > Do I need to replace the hex value after MX6QDL_PAD_GPIO_16__ENET_REF_CLK > by something else ? hummingboard uses: MX6QDL_PAD_GPIO_16__ENET_REF_CLK 0xc0000000 Check arch/arm/boot/dts/imx6qdl-microsom-ar8035.dtsi in linux-next. Regards, Fabio Estevam
On Wed, Jan 15, 2014 at 08:13:15AM -0200, Fabio Estevam wrote: > On Wed, Jan 15, 2014 at 7:45 AM, Philippe De Muyter <phdm@macq.eu> wrote: > > > Here are my patches (I have called my board imx6dl-p6-2094): > > Do I need to replace the hex value after MX6QDL_PAD_GPIO_16__ENET_REF_CLK > > by something else ? > > hummingboard uses: > > MX6QDL_PAD_GPIO_16__ENET_REF_CLK 0xc0000000 I quickly tried that, but that does not solve my problem (still tx timeout) > > Check arch/arm/boot/dts/imx6qdl-microsom-ar8035.dtsi in linux-next. I will look there now. Thanks Philippe
On Wed, Jan 15, 2014 at 08:13:15AM -0200, Fabio Estevam wrote: > On Wed, Jan 15, 2014 at 7:45 AM, Philippe De Muyter <phdm@macq.eu> wrote: > > > Here are my patches (I have called my board imx6dl-p6-2094): > > Do I need to replace the hex value after MX6QDL_PAD_GPIO_16__ENET_REF_CLK > > by something else ? > > hummingboard uses: > > MX6QDL_PAD_GPIO_16__ENET_REF_CLK 0xc0000000 > > Check arch/arm/boot/dts/imx6qdl-microsom-ar8035.dtsi in linux-next. They use RGMII, while I have RMII :( Philippe
On Wed, Jan 15, 2014 at 8:55 AM, Philippe De Muyter <phdm@macq.eu> wrote: > On Wed, Jan 15, 2014 at 08:13:15AM -0200, Fabio Estevam wrote: >> On Wed, Jan 15, 2014 at 7:45 AM, Philippe De Muyter <phdm@macq.eu> wrote: >> >> > Here are my patches (I have called my board imx6dl-p6-2094): >> > Do I need to replace the hex value after MX6QDL_PAD_GPIO_16__ENET_REF_CLK >> > by something else ? >> >> hummingboard uses: >> >> MX6QDL_PAD_GPIO_16__ENET_REF_CLK 0xc0000000 >> >> Check arch/arm/boot/dts/imx6qdl-microsom-ar8035.dtsi in linux-next. > > They use RGMII, while I have RMII :( Are you able to do TFTP in the bootloader? Maybe it is easier to debug from the bootloader and check if the PHY is being properly powered and clocked. You can check mx6slevk which uses RMII. Regards, Fabio Estevam
Hi Shawn, On Wed, Jan 15, 2014 at 03:35:40PM +0800, Shawn Guo wrote: > On Tue, Jan 14, 2014 at 04:30:12PM +0100, Philippe De Muyter wrote: > > Hi, > > > > On the custom board we are developping (imx6q and imx6dl), we have connected > > the fec to a switch chip using rmii mode, and we let the switch provide the > > reference clock to gpio_16. > > > > I work currently with 3.13-rc8 and > > > > - I do not have ethernet access working (tx timeout) > > - I do not find in the dtb files a description of the pad settings for the > > RMII mode > > - when searching about the setting for bit 21 ing GPR1, which seems to > > be important for my setting to work, I found the following mail: > > http://www.spinics.net/lists/devicetree/msg06450.html > > Just for testing your hardware, does the following change make the > Ethernet work for you? > > Shawn > > diff --git a/arch/arm/mach-imx/mach-imx6q.c > b/arch/arm/mach-imx/mach-imx6q.c > index e51e3da..be8d074 100644 > --- a/arch/arm/mach-imx/mach-imx6q.c > +++ b/arch/arm/mach-imx/mach-imx6q.c > @@ -188,7 +188,7 @@ static void __init imx6q_1588_init(void) > if (!IS_ERR(gpr)) > regmap_update_bits(gpr, IOMUXC_GPR1, > IMX6Q_GPR1_ENET_CLK_SEL_MASK, > - IMX6Q_GPR1_ENET_CLK_SEL_ANATOP); > + 0); > else > pr_err("failed to find fsl,imx6q-iomux-gpr regmap\n"); > Yes, it works now. Thanks. Is that configurable from the device tree ? Philippe
On Wed, Jan 29, 2014 at 10:54:29AM +0100, Philippe De Muyter wrote: > > diff --git a/arch/arm/mach-imx/mach-imx6q.c > > b/arch/arm/mach-imx/mach-imx6q.c > > index e51e3da..be8d074 100644 > > --- a/arch/arm/mach-imx/mach-imx6q.c > > +++ b/arch/arm/mach-imx/mach-imx6q.c > > @@ -188,7 +188,7 @@ static void __init imx6q_1588_init(void) > > if (!IS_ERR(gpr)) > > regmap_update_bits(gpr, IOMUXC_GPR1, > > IMX6Q_GPR1_ENET_CLK_SEL_MASK, > > - IMX6Q_GPR1_ENET_CLK_SEL_ANATOP); > > + 0); > > else > > pr_err("failed to find fsl,imx6q-iomux-gpr regmap\n"); > > > > Yes, it works now. Thanks. Is that configurable from the device tree ? Yes, with some code change, I think that's configurable from device tree. But, it's not that simple. As I explained in thread [1], the RMII reference clock ENET_REF_CLK from pad GPIO_16 will also be used by PTP (IEEE 1588) as sampling clock in your configuration. Right now, the ptp clock in fec node is defaulted to be enet_ref from IMX6 CCM (id 190) in imx6qdl.dtsi. You will need to correct it in your board dts file, something like the following. clocks { #address-cells = <1>; #size-cells = <0>; rmii_clk: clock@0 { compatible = "fixed-clock"; reg = <0>; #clock-cells = <0>; clock-frequency = <25000000>; /* 25MHz for example */ }; }; &fec { clocks = <&clks 117>, <&clks 117>, <&rmii_clk>; }; I think we can even save a device tree property and ask kernel to figure it out that bit GPR1[21] should be set or cleared. Yes, kernel should be able to do that by checking whether the ptp_clk in fec node points to the enet_ref clock coming from IMX6 clock driver (ANATOP/CCM). I will send a patch for this soon. Shawn [1] http://thread.gmane.org/gmane.linux.ports.arm.kernel/269265/focus=269646
diff --git a/arch/arm/mach-imx/mach-imx6q.c b/arch/arm/mach-imx/mach-imx6q.c index e51e3da..be8d074 100644 --- a/arch/arm/mach-imx/mach-imx6q.c +++ b/arch/arm/mach-imx/mach-imx6q.c @@ -188,7 +188,7 @@ static void __init imx6q_1588_init(void) if (!IS_ERR(gpr)) regmap_update_bits(gpr, IOMUXC_GPR1, IMX6Q_GPR1_ENET_CLK_SEL_MASK, - IMX6Q_GPR1_ENET_CLK_SEL_ANATOP); + 0); else pr_err("failed to find fsl,imx6q-iomux-gpr regmap\n");