Hi Sven,
On Wed, Jul 1, 2020 at 1:03 PM Sven Van Asbroeck wrote:
>
> Fabio has already indicated that he's ok with adding a new property.
> Fabio, is that still the case?
Yes, please proceed with adding the new device tree property.
This way we prevent existing imx6qp dtb's breakage.
Thanks
Hi Andy and Fabio,
On Wed, Jul 1, 2020 at 11:30 AM Andy Duan wrote:
>
> Discuss with Fabio, an existing(old) dtb in mainline has to work in future
> kernels,
> without the need of being updated, so to add internal pll support for 6qp
> rgmii gtx,
> and not to break 6qp old dtb, add new property
From: Sven Van Asbroeck Sent: Wednesday, July 1, 2020
9:52 PM
> Andy, Fabio,
>
> Does the following describe the mainline situation?
> Please correct if not.
>
> 1. imx6 ethernet ref_clk can be generated internally (by imx6) or
>externally (by PHY or oscillator on PCB) 2. if internal, fec's
Andy, Fabio,
Does the following describe the mainline situation?
Please correct if not.
1. imx6 ethernet ref_clk can be generated internally (by imx6) or
externally (by PHY or oscillator on PCB)
2. if internal, fec's "ptp" clock in devicetree should be
<&clks IMX6QDL_CLK_ENET_REF>
3. if ext
On Wed, Jul 1, 2020 at 12:42 AM Andy Duan wrote:
> It doesn't break old dtbs, and doesn't break imx6q/dl/solo.
Well, it breaks imx6qp as I said multiple times.
It does not break in your case because you are using NXP U-Boot.
You cannot assume people are using NXP U-Boot.
From: Fabio Estevam Sent: Wednesday, July 1, 2020 11:39 AM
> Hi Andy,
>
> On Wed, Jul 1, 2020 at 12:18 AM Andy Duan wrote:
>
> > --- a/arch/arm/boot/dts/imx6qdl-sabresd.dtsi
> > +++ b/arch/arm/boot/dts/imx6qdl-sabresd.dtsi
> > @@ -202,6 +202,8 @@
> > &fec {
> > pinctrl-names = "defaul
Hi Andy,
On Wed, Jul 1, 2020 at 12:18 AM Andy Duan wrote:
> --- a/arch/arm/boot/dts/imx6qdl-sabresd.dtsi
> +++ b/arch/arm/boot/dts/imx6qdl-sabresd.dtsi
> @@ -202,6 +202,8 @@
> &fec {
> pinctrl-names = "default";
> pinctrl-0 = <&pinctrl_enet>;
> + assigned-clocks = <&clks I
From: Sven Van Asbroeck Sent: Tuesday, June 30, 2020
11:24 PM
> Andy, Fabio,
>
> On Tue, Jun 30, 2020 at 2:36 AM Andy Duan wrote:
> >
> > Sven, no matter PHY supply 125Mhz clock to pad or not, GPR5[9] is to
> > select RGMII gtx clock source from:
> > - 0 Clock from pad
> > - 1 Clock from PLL
>
From: Fabio Estevam Sent: Tuesday, June 30, 2020 7:49 PM
> Hi Andy,
>
> On Tue, Jun 30, 2020 at 3:36 AM Andy Duan wrote:
>
> > Fabio, our QA double verify 5.4.24_2.1.0, no matter SD boot or
> > tftp/nfs boot, both work fine on i.MX6QP sabresd board, please double
> check your environment.
>
>
Andy, Fabio,
On Tue, Jun 30, 2020 at 2:36 AM Andy Duan wrote:
>
> Sven, no matter PHY supply 125Mhz clock to pad or not, GPR5[9] is to select
> RGMII
> gtx clock source from:
> - 0 Clock from pad
> - 1 Clock from PLL
>
> Since i.MX6QP can internally supply clock to MAC, we can set GPR5[9] bit b
Hi Andy,
On Tue, Jun 30, 2020 at 3:36 AM Andy Duan wrote:
> Fabio, our QA double verify 5.4.24_2.1.0, no matter SD boot or tftp/nfs boot,
> both work fine on i.MX6QP sabresd board, please double check your
> environment.
Is static IP or DHCP used on these tests?
I have an SCH-28857 REV A2 im
From: Sven Van Asbroeck Sent: Monday, June 29, 2020 10:37
PM
> On Mon, Jun 29, 2020 at 10:26 AM Fabio Estevam
> wrote:
> >
> > Just tested 5.4.24_2.1.0 on an imx6qp sabresd and DHCP also fails there.
>
> I think I discovered the problem !
>
> When I compare the sabresd devicetree on mainline w
From: Fabio Estevam Sent: Monday, June 29, 2020 10:26 PM
> Hi Sven,
>
> On Mon, Jun 29, 2020 at 10:40 AM Sven Van Asbroeck
> wrote:
>
> > Thank you for testing this out on a different platform !
> >
> > I had a look at how things are done in the Freescale fork of the
> > kernel
> > (5.4.24_2.1.
Hi Sven,
On Mon, Jun 29, 2020 at 10:40 AM Sven Van Asbroeck wrote:
> I'm sure you've checked that sabresd ethernet works ok on mainline
> even without this patch?
Yes, I have tested several times: without this patch series, DHCP works fine.
Applying this series causes DHCP to fail. The test is
Hi Sven,
On Mon, Jun 29, 2020 at 10:40 AM Sven Van Asbroeck wrote:
> Thank you for testing this out on a different platform !
>
> I had a look at how things are done in the Freescale fork of the kernel
> (5.4.24_2.1.0) and I noticed that this kernel has almost the same
> behaviour as this propos
Hi Fabio,
On Mon, Jun 29, 2020 at 9:10 AM Fabio Estevam wrote:
>
> I have tested this series on an imx6qp sabresd and unfortunately, it
> breaks Ethernet as I can no longer get an IP address from the DHCP
> server.
Thank you for testing this out on a different platform !
I had a look at how thi
Hi Fabio,
On Mon, Jun 29, 2020 at 10:26 AM Fabio Estevam wrote:
>
> Just tested 5.4.24_2.1.0 on an imx6qp sabresd and DHCP also fails there.
I think I discovered the problem !
When I compare the sabresd devicetree on mainline with the actual sabresd
schematics, the devicetree is incorrect ! Thi
Hi Sven,
On Thu, Jun 25, 2020 at 11:01 AM Sven Van Asbroeck wrote:
>
> On imx6, the ethernet reference clock (clk_enet_ref) can be generated
> by either the imx6, or an external source (e.g. an oscillator or the
> PHY). When generated by the imx6, the clock source (from ANATOP)
> must be routed t
From: Sven Van Asbroeck Sent: Thursday, June 25, 2020
10:01 PM
> On imx6, the ethernet reference clock (clk_enet_ref) can be generated by
> either the imx6, or an external source (e.g. an oscillator or the PHY). When
> generated by the imx6, the clock source (from ANATOP) must be routed to the
>
On imx6, the ethernet reference clock (clk_enet_ref) can be generated
by either the imx6, or an external source (e.g. an oscillator or the
PHY). When generated by the imx6, the clock source (from ANATOP)
must be routed to the input of clk_enet_ref via two pads on the SoC,
typically via a dedicated
20 matches
Mail list logo
