[PATCH] ARM64: meson-gxl: disable broken eee

[PATCH] ARM64: meson-gxl: disable broken eee

[Joseph Kogut]

Meson GXL appears to suffer from the same broken eee issue as GXB,
originally fixed by feb3cbea0946.

This patch disables the broken energy-efficient ethernet for GXL,
avoiding the tx link breakage.

Signed-off-by: Joseph Kogut <joseph.kogut@gmail.com>
---
 arch/arm64/boot/dts/amlogic/meson-gxl.dtsi | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm64/boot/dts/amlogic/meson-gxl.dtsi b/arch/arm64/boot/dts/amlogic/meson-gxl.dtsi
index 8d4f3160a0ee..620e8a4f9bb3 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gxl.dtsi
+++ b/arch/arm64/boot/dts/amlogic/meson-gxl.dtsi
@@ -570,6 +570,7 @@
 				compatible = "ethernet-phy-id0181.4400", "ethernet-phy-ieee802.3-c22";
 				reg = <8>;
 				max-speed = <100>;
+				eee-broken-100tx;
 			};
 		};
 
-- 
2.13.2

Re: [PATCH] ARM64: meson-gxl: disable broken eee

[Kevin Hilman]

Hi Joseph,

Joseph Kogut <joseph.kogut-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> writes:

> Meson GXL appears to suffer from the same broken eee issue as GXB,
> originally fixed by feb3cbea0946.
>
> This patch disables the broken energy-efficient ethernet for GXL,
> avoiding the tx link breakage.
>
> Signed-off-by: Joseph Kogut <joseph.kogut-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>

Can you share what platforms you tested to find/fix this problem?

Thanks for the patch!

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

Re: [PATCH] ARM64: meson-gxl: disable broken eee

[Joseph Kogut]

Hi Kevin,

I tested on a P212 reference board, which is currently the only GXL
based board I have.

Before applying the patch, high activity on the ethernet interface
would cause the link to break, requiring the interface to be brought
down and back up before it would work again. After applying the patch,
I could not get the link to break with any transfers.
--
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

Re: [PATCH] ARM64: meson-gxl: disable broken eee

[Neil Armstrong]

On 07/23/2017 07:03 PM, Joseph Kogut wrote:
> Hi Kevin,
> 
> I tested on a P212 reference board, which is currently the only GXL
> based board I have.
> 
> Before applying the patch, high activity on the ethernet interface
> would cause the link to break, requiring the interface to be brought
> down and back up before it would work again. After applying the patch,
> I could not get the link to break with any transfers.
> 
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
> 

Hi Joseph,

[please keep the history of the conversation when replying]

Is it a original P212 board, or a board based on the P212 ref design ?

I'm currently testing the v4.13-rc2 on the official P212 board we received from Amlogic
and using iperf3 in both directions, I have an issue after a few minutes running iperf3 with :

# while true ; do iperf3 -c 192.168.1.21 ; iperf3 -c 192.168.1.21 -R ; done

That cycles between the two iperf directions.

After a few minutes, it stalls with :

Connecting to host 192.168.1.21, port 5201
[  4] local 192.168.1.183 port 51286 connected to 192.168.1.21 port 5201
[ ID] Interval           Transfer     Bandwidth       Retr  Cwnd
[  4]   0.00-1.00   sec  1.64 MBytes  13.7 Mbits/sec    2   1.41 KBytes
[  4]   1.00-2.00   sec  0.00 Bytes  0.00 bits/sec    1   1.41 KBytes
[  4]   2.00-3.00   sec  0.00 Bytes  0.00 bits/sec    0   1.41 KBytes
[  4]   3.00-4.00   sec  0.00 Bytes  0.00 bits/sec    1   1.41 KBytes
[  4]   4.00-5.00   sec  0.00 Bytes  0.00 bits/sec    0   1.41 KBytes
[  4]   5.00-6.00   sec  0.00 Bytes  0.00 bits/sec    0   1.41 KBytes
[  4]   6.00-7.00   sec  0.00 Bytes  0.00 bits/sec    1   1.41 KBytes
[  4]   7.00-8.00   sec  0.00 Bytes  0.00 bits/sec    0   1.41 KBytes
[  4]   8.00-9.00   sec  0.00 Bytes  0.00 bits/sec    0   1.41 KBytes


And then, after:
# ifconfig eth0 down
# ifconfig eth0 up

It cycles between :
[ 1483.009919] meson8b-dwmac c9410000.ethernet eth0: Link is Up - 100Mbps/Full - flow control rx/tx
[ 1487.105725] meson8b-dwmac c9410000.ethernet eth0: Link is Down
[ 1490.177943] meson8b-dwmac c9410000.ethernet eth0: Link is Up - 100Mbps/Full - flow control rx/tx
[ 1494.273713] meson8b-dwmac c9410000.ethernet eth0: Link is Down

and so on.

And this patch does not fix this at all.

It seems to be more a PHY driver issue here.

Could you share the results with the same command ?

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

Re: [PATCH] ARM64: meson-gxl: disable broken eee

[Neil Armstrong]

On 07/24/2017 02:06 PM, Neil Armstrong wrote:
> On 07/23/2017 07:03 PM, Joseph Kogut wrote:
>> Hi Kevin,
>>
>> I tested on a P212 reference board, which is currently the only GXL
>> based board I have.
>>
>> Before applying the patch, high activity on the ethernet interface
>> would cause the link to break, requiring the interface to be brought
>> down and back up before it would work again. After applying the patch,
>> I could not get the link to break with any transfers.
>>
>> _______________________________________________
>> linux-arm-kernel mailing list
>> linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
>> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>>
> 
> Hi Joseph,
> 
> [please keep the history of the conversation when replying]
> 
> Is it a original P212 board, or a board based on the P212 ref design ?
> 
> I'm currently testing the v4.13-rc2 on the official P212 board we received from Amlogic
> and using iperf3 in both directions, I have an issue after a few minutes running iperf3 with :
> 
> # while true ; do iperf3 -c 192.168.1.21 ; iperf3 -c 192.168.1.21 -R ; done
> 
> That cycles between the two iperf directions.
> 
> After a few minutes, it stalls with :
> 
> Connecting to host 192.168.1.21, port 5201
> [  4] local 192.168.1.183 port 51286 connected to 192.168.1.21 port 5201
> [ ID] Interval           Transfer     Bandwidth       Retr  Cwnd
> [  4]   0.00-1.00   sec  1.64 MBytes  13.7 Mbits/sec    2   1.41 KBytes
> [  4]   1.00-2.00   sec  0.00 Bytes  0.00 bits/sec    1   1.41 KBytes
> [  4]   2.00-3.00   sec  0.00 Bytes  0.00 bits/sec    0   1.41 KBytes
> [  4]   3.00-4.00   sec  0.00 Bytes  0.00 bits/sec    1   1.41 KBytes
> [  4]   4.00-5.00   sec  0.00 Bytes  0.00 bits/sec    0   1.41 KBytes
> [  4]   5.00-6.00   sec  0.00 Bytes  0.00 bits/sec    0   1.41 KBytes
> [  4]   6.00-7.00   sec  0.00 Bytes  0.00 bits/sec    1   1.41 KBytes
> [  4]   7.00-8.00   sec  0.00 Bytes  0.00 bits/sec    0   1.41 KBytes
> [  4]   8.00-9.00   sec  0.00 Bytes  0.00 bits/sec    0   1.41 KBytes
> 
> 
> And then, after:
> # ifconfig eth0 down
> # ifconfig eth0 up
> 
> It cycles between :
> [ 1483.009919] meson8b-dwmac c9410000.ethernet eth0: Link is Up - 100Mbps/Full - flow control rx/tx
> [ 1487.105725] meson8b-dwmac c9410000.ethernet eth0: Link is Down
> [ 1490.177943] meson8b-dwmac c9410000.ethernet eth0: Link is Up - 100Mbps/Full - flow control rx/tx
> [ 1494.273713] meson8b-dwmac c9410000.ethernet eth0: Link is Down
> 
> and so on.
> 
> And this patch does not fix this at all.
> 
> It seems to be more a PHY driver issue here.
> 
> Could you share the results with the same command ?
> 
> Neil
> 

I forgot to precise, this issue occurs when the "GXL PHY driver" is disabled, only relying on the
Generic PHY Driver.

[  630.767538] Generic PHY 0.e40908ff:08: attached PHY driver [Generic PHY] (mii_bus:phy_addr=0.e40908ff:08, irq=-1)


When the PHY driver is loaded the issue disappears, with and without your patch.

[   25.355620] Meson GXL Internal PHY 0.e40908ff:08: attached PHY driver [Meson GXL Internal PHY] (mii_bus:phy_addr=0.e40908ff:08, irq=-1)

Could you please check the PHY Driver is loaded ?

Thanks,
Neil
--
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

Re: [PATCH] ARM64: meson-gxl: disable broken eee

[Jerome Brunet]

On Mon, 2017-07-24 at 14:26 +0200, Neil Armstrong wrote:
> On 07/24/2017 02:06 PM, Neil Armstrong wrote:
> > On 07/23/2017 07:03 PM, Joseph Kogut wrote:
> > > Hi Kevin,
> > > 
> > > I tested on a P212 reference board, which is currently the only GXL
> > > based board I have.
> > > 
> > > Before applying the patch, high activity on the ethernet interface
> > > would cause the link to break, requiring the interface to be brought
> > > down and back up before it would work again. After applying the patch,
> > > I could not get the link to break with any transfers.
> > > 
> > > _______________________________________________
> > > linux-arm-kernel mailing list
> > > linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
> > > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
> > > 
> > 
> > Hi Joseph,
> > 
> > [please keep the history of the conversation when replying]
> > 
> > Is it a original P212 board, or a board based on the P212 ref design ?
> > 
> > I'm currently testing the v4.13-rc2 on the official P212 board we received
> > from Amlogic
> > and using iperf3 in both directions, I have an issue after a few minutes
> > running iperf3 with :
> > 
> > # while true ; do iperf3 -c 192.168.1.21 ; iperf3 -c 192.168.1.21 -R ; done
> > 
> > That cycles between the two iperf directions.
> > 
> > After a few minutes, it stalls with :
> > 
> > Connecting to host 192.168.1.21, port 5201
> > [  4] local 192.168.1.183 port 51286 connected to 192.168.1.21 port 5201
> > [ ID] Interval           Transfer     Bandwidth       Retr  Cwnd
> > [  4]   0.00-1.00   sec  1.64 MBytes  13.7 Mbits/sec    2   1.41 KBytes
> > [  4]   1.00-2.00   sec  0.00 Bytes  0.00 bits/sec    1   1.41 KBytes
> > [  4]   2.00-3.00   sec  0.00 Bytes  0.00 bits/sec    0   1.41 KBytes
> > [  4]   3.00-4.00   sec  0.00 Bytes  0.00 bits/sec    1   1.41 KBytes
> > [  4]   4.00-5.00   sec  0.00 Bytes  0.00 bits/sec    0   1.41 KBytes
> > [  4]   5.00-6.00   sec  0.00 Bytes  0.00 bits/sec    0   1.41 KBytes
> > [  4]   6.00-7.00   sec  0.00 Bytes  0.00 bits/sec    1   1.41 KBytes
> > [  4]   7.00-8.00   sec  0.00 Bytes  0.00 bits/sec    0   1.41 KBytes
> > [  4]   8.00-9.00   sec  0.00 Bytes  0.00 bits/sec    0   1.41 KBytes
> > 

Same kind of test shows no issue on the libretech-cc and the khadas-vim
In this case, I don't think meson-gxl.dtsi is where you should make your change.

> > 
> > And then, after:
> > # ifconfig eth0 down
> > # ifconfig eth0 up
> > 
> > It cycles between :
> > [ 1483.009919] meson8b-dwmac c9410000.ethernet eth0: Link is Up -
> > 100Mbps/Full - flow control rx/tx
> > [ 1487.105725] meson8b-dwmac c9410000.ethernet eth0: Link is Down
> > [ 1490.177943] meson8b-dwmac c9410000.ethernet eth0: Link is Up -
> > 100Mbps/Full - flow control rx/tx
> > [ 1494.273713] meson8b-dwmac c9410000.ethernet eth0: Link is Down

This does not look like the issue we had on the odroid-c2.
However, I have seen behavior like this (link down/up flickering) when the rgmii
 delays are way off.

Maybe you could try playing with "amlogic,tx-delay-ns" property ?

> > 
> > and so on.
> > 
> > And this patch does not fix this at all.
> > 
> > It seems to be more a PHY driver issue here.
> > 
> > Could you share the results with the same command ?
> > 
> > Neil
> > 
> 
> I forgot to precise, this issue occurs when the "GXL PHY driver" is disabled,
> only relying on the
> Generic PHY Driver.
> 
> [  630.767538] Generic PHY 0.e40908ff:08: attached PHY driver [Generic PHY]
> (mii_bus:phy_addr=0.e40908ff:08, irq=-1)
> 
> 
> When the PHY driver is loaded the issue disappears, with and without your
> patch.
> 
> [   25.355620] Meson GXL Internal PHY 0.e40908ff:08: attached PHY driver
> [Meson GXL Internal PHY] (mii_bus:phy_addr=0.e40908ff:08, irq=-1)
> 
> Could you please check the PHY Driver is loaded ?
> 
> Thanks,
> Neil

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

Re: [PATCH] ARM64: meson-gxl: disable broken eee

[Martin Blumenstingl]

On Mon, Jul 24, 2017 at 6:09 PM, Jerome Brunet <jbrunet@baylibre.com> wrote:
> On Mon, 2017-07-24 at 14:26 +0200, Neil Armstrong wrote:
>> On 07/24/2017 02:06 PM, Neil Armstrong wrote:
>> > On 07/23/2017 07:03 PM, Joseph Kogut wrote:
>> > > Hi Kevin,
>> > >
>> > > I tested on a P212 reference board, which is currently the only GXL
>> > > based board I have.
>> > >
>> > > Before applying the patch, high activity on the ethernet interface
>> > > would cause the link to break, requiring the interface to be brought
>> > > down and back up before it would work again. After applying the patch,
>> > > I could not get the link to break with any transfers.
>> > >
>> > > _______________________________________________
>> > > linux-arm-kernel mailing list
>> > > linux-arm-kernel@lists.infradead.org
>> > > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>> > >
>> >
>> > Hi Joseph,
>> >
>> > [please keep the history of the conversation when replying]
>> >
>> > Is it a original P212 board, or a board based on the P212 ref design ?
>> >
>> > I'm currently testing the v4.13-rc2 on the official P212 board we received
>> > from Amlogic
>> > and using iperf3 in both directions, I have an issue after a few minutes
>> > running iperf3 with :
>> >
>> > # while true ; do iperf3 -c 192.168.1.21 ; iperf3 -c 192.168.1.21 -R ; done
>> >
>> > That cycles between the two iperf directions.
>> >
>> > After a few minutes, it stalls with :
>> >
>> > Connecting to host 192.168.1.21, port 5201
>> > [  4] local 192.168.1.183 port 51286 connected to 192.168.1.21 port 5201
>> > [ ID] Interval           Transfer     Bandwidth       Retr  Cwnd
>> > [  4]   0.00-1.00   sec  1.64 MBytes  13.7 Mbits/sec    2   1.41 KBytes
>> > [  4]   1.00-2.00   sec  0.00 Bytes  0.00 bits/sec    1   1.41 KBytes
>> > [  4]   2.00-3.00   sec  0.00 Bytes  0.00 bits/sec    0   1.41 KBytes
>> > [  4]   3.00-4.00   sec  0.00 Bytes  0.00 bits/sec    1   1.41 KBytes
>> > [  4]   4.00-5.00   sec  0.00 Bytes  0.00 bits/sec    0   1.41 KBytes
>> > [  4]   5.00-6.00   sec  0.00 Bytes  0.00 bits/sec    0   1.41 KBytes
>> > [  4]   6.00-7.00   sec  0.00 Bytes  0.00 bits/sec    1   1.41 KBytes
>> > [  4]   7.00-8.00   sec  0.00 Bytes  0.00 bits/sec    0   1.41 KBytes
>> > [  4]   8.00-9.00   sec  0.00 Bytes  0.00 bits/sec    0   1.41 KBytes
>> >
>
> Same kind of test shows no issue on the libretech-cc and the khadas-vim
> In this case, I don't think meson-gxl.dtsi is where you should make your change.
>
>> >
>> > And then, after:
>> > # ifconfig eth0 down
>> > # ifconfig eth0 up
>> >
>> > It cycles between :
>> > [ 1483.009919] meson8b-dwmac c9410000.ethernet eth0: Link is Up -
>> > 100Mbps/Full - flow control rx/tx
>> > [ 1487.105725] meson8b-dwmac c9410000.ethernet eth0: Link is Down
>> > [ 1490.177943] meson8b-dwmac c9410000.ethernet eth0: Link is Up -
>> > 100Mbps/Full - flow control rx/tx
>> > [ 1494.273713] meson8b-dwmac c9410000.ethernet eth0: Link is Down
>
> This does not look like the issue we had on the odroid-c2.
> However, I have seen behavior like this (link down/up flickering) when the rgmii
>  delays are way off.
>
> Maybe you could try playing with "amlogic,tx-delay-ns" property ?
we need to change dwmac-meson8b.c so it applies the TX delay also for
RMII PHYs. currently the TX delay is always set to 0 for RMII PHYs,
see: [0]

>> >
>> > and so on.
>> >
>> > And this patch does not fix this at all.
>> >
>> > It seems to be more a PHY driver issue here.
>> >
>> > Could you share the results with the same command ?
>> >
>> > Neil
>> >
>>
>> I forgot to precise, this issue occurs when the "GXL PHY driver" is disabled,
>> only relying on the
>> Generic PHY Driver.
>>
>> [  630.767538] Generic PHY 0.e40908ff:08: attached PHY driver [Generic PHY]
>> (mii_bus:phy_addr=0.e40908ff:08, irq=-1)
>>
>>
>> When the PHY driver is loaded the issue disappears, with and without your
>> patch.
>>
>> [   25.355620] Meson GXL Internal PHY 0.e40908ff:08: attached PHY driver
>> [Meson GXL Internal PHY] (mii_bus:phy_addr=0.e40908ff:08, irq=-1)
>>
>> Could you please check the PHY Driver is loaded ?
>>
>> Thanks,
>> Neil
>
>
> _______________________________________________
> linux-amlogic mailing list
> linux-amlogic@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-amlogic


[0] https://github.com/torvalds/linux/blob/master/drivers/net/ethernet/stmicro/stmmac/dwmac-meson8b.c#L222

Re: [PATCH] ARM64: meson-gxl: disable broken eee

[Jerome Brunet]

On Mon, 2017-07-24 at 20:20 +0200, Martin Blumenstingl wrote:
> On Mon, Jul 24, 2017 at 6:09 PM, Jerome Brunet <jbrunet-rdvid1DuHRBWk0Htik3J/w@public.gmane.org> wrote:
> > On Mon, 2017-07-24 at 14:26 +0200, Neil Armstrong wrote:
> > > On 07/24/2017 02:06 PM, Neil Armstrong wrote:
> > > > On 07/23/2017 07:03 PM, Joseph Kogut wrote:
> > > > > Hi Kevin,
> > > > > 
> > > > > I tested on a P212 reference board, which is currently the only GXL
> > > > > based board I have.
> > > > > 
> > > > > Before applying the patch, high activity on the ethernet interface
> > > > > would cause the link to break, requiring the interface to be brought
> > > > > down and back up before it would work again. After applying the patch,
> > > > > I could not get the link to break with any transfers.
> > > > > 
> > > > > _______________________________________________
> > > > > linux-arm-kernel mailing list
> > > > > linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
> > > > > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
> > > > > 
> > > > 
> > > > Hi Joseph,
> > > > 
> > > > [please keep the history of the conversation when replying]
> > > > 
> > > > Is it a original P212 board, or a board based on the P212 ref design ?
> > > > 
> > > > I'm currently testing the v4.13-rc2 on the official P212 board we
> > > > received
> > > > from Amlogic
> > > > and using iperf3 in both directions, I have an issue after a few minutes
> > > > running iperf3 with :
> > > > 
> > > > # while true ; do iperf3 -c 192.168.1.21 ; iperf3 -c 192.168.1.21 -R ;
> > > > done
> > > > 
> > > > That cycles between the two iperf directions.
> > > > 
> > > > After a few minutes, it stalls with :
> > > > 
> > > > Connecting to host 192.168.1.21, port 5201
> > > > [  4] local 192.168.1.183 port 51286 connected to 192.168.1.21 port 5201
> > > > [ ID] Interval           Transfer     Bandwidth       Retr  Cwnd
> > > > [  4]   0.00-1.00   sec  1.64 MBytes  13.7 Mbits/sec    2   1.41 KBytes
> > > > [  4]   1.00-2.00   sec  0.00 Bytes  0.00 bits/sec    1   1.41 KBytes
> > > > [  4]   2.00-3.00   sec  0.00 Bytes  0.00 bits/sec    0   1.41 KBytes
> > > > [  4]   3.00-4.00   sec  0.00 Bytes  0.00 bits/sec    1   1.41 KBytes
> > > > [  4]   4.00-5.00   sec  0.00 Bytes  0.00 bits/sec    0   1.41 KBytes
> > > > [  4]   5.00-6.00   sec  0.00 Bytes  0.00 bits/sec    0   1.41 KBytes
> > > > [  4]   6.00-7.00   sec  0.00 Bytes  0.00 bits/sec    1   1.41 KBytes
> > > > [  4]   7.00-8.00   sec  0.00 Bytes  0.00 bits/sec    0   1.41 KBytes
> > > > [  4]   8.00-9.00   sec  0.00 Bytes  0.00 bits/sec    0   1.41 KBytes
> > > > 
> > 
> > Same kind of test shows no issue on the libretech-cc and the khadas-vim
> > In this case, I don't think meson-gxl.dtsi is where you should make your
> > change.

ahahah, silly me ! I forgot that it was 100MBps PHY.
tx delay makes no sense here, 2ns delay would not make much difference on a
25MHz clock

Sorry for the confusion


> > 
> > > > 
> > > > And then, after:
> > > > # ifconfig eth0 down
> > > > # ifconfig eth0 up
> > > > 
> > > > It cycles between :
> > > > [ 1483.009919] meson8b-dwmac c9410000.ethernet eth0: Link is Up -
> > > > 100Mbps/Full - flow control rx/tx
> > > > [ 1487.105725] meson8b-dwmac c9410000.ethernet eth0: Link is Down
> > > > [ 1490.177943] meson8b-dwmac c9410000.ethernet eth0: Link is Up -
> > > > 100Mbps/Full - flow control rx/tx
> > > > [ 1494.273713] meson8b-dwmac c9410000.ethernet eth0: Link is Down
> > 
> > This does not look like the issue we had on the odroid-c2.
> > However, I have seen behavior like this (link down/up flickering) when the
> > rgmii
> >  delays are way off.
> > 
> > Maybe you could try playing with "amlogic,tx-delay-ns" property ?
> 
> we need to change dwmac-meson8b.c so it applies the TX delay also for
> RMII PHYs. currently the TX delay is always set to 0 for RMII PHYs,
> see: [0]
> 
> > > > 
> > > > and so on.
> > > > 
> > > > And this patch does not fix this at all.
> > > > 
> > > > It seems to be more a PHY driver issue here.
> > > > 
> > > > Could you share the results with the same command ?
> > > > 
> > > > Neil
> > > > 
> > > 
> > > I forgot to precise, this issue occurs when the "GXL PHY driver" is
> > > disabled,
> > > only relying on the
> > > Generic PHY Driver.
> > > 
> > > [  630.767538] Generic PHY 0.e40908ff:08: attached PHY driver [Generic
> > > PHY]
> > > (mii_bus:phy_addr=0.e40908ff:08, irq=-1)
> > > 
> > > 
> > > When the PHY driver is loaded the issue disappears, with and without your
> > > patch.
> > > 
> > > [   25.355620] Meson GXL Internal PHY 0.e40908ff:08: attached PHY driver
> > > [Meson GXL Internal PHY] (mii_bus:phy_addr=0.e40908ff:08, irq=-1)
> > > 
> > > Could you please check the PHY Driver is loaded ?
> > > 
> > > Thanks,
> > > Neil
> > 
> > 
> > _______________________________________________
> > linux-amlogic mailing list
> > linux-amlogic-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
> > http://lists.infradead.org/mailman/listinfo/linux-amlogic
> 
> 
> [0] https://github.com/torvalds/linux/blob/master/drivers/net/ethernet/stmicro
> /stmmac/dwmac-meson8b.c#L222

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

Re: [PATCH] ARM64: meson-gxl: disable broken eee

[crow]

Hello,

On Mon, Jul 24, 2017 at 8:32 PM, Jerome Brunet <jbrunet@baylibre.com> wrote:
> On Mon, 2017-07-24 at 20:20 +0200, Martin Blumenstingl wrote:
>> On Mon, Jul 24, 2017 at 6:09 PM, Jerome Brunet <jbrunet@baylibre.com> wrote:
>> > On Mon, 2017-07-24 at 14:26 +0200, Neil Armstrong wrote:
>> > > On 07/24/2017 02:06 PM, Neil Armstrong wrote:
>> > > > On 07/23/2017 07:03 PM, Joseph Kogut wrote:
>> > > > > Hi Kevin,
>> > > > >
>> > > > > I tested on a P212 reference board, which is currently the only GXL
>> > > > > based board I have.
>> > > > >
>> > > > > Before applying the patch, high activity on the ethernet interface
>> > > > > would cause the link to break, requiring the interface to be brought
>> > > > > down and back up before it would work again. After applying the patch,
>> > > > > I could not get the link to break with any transfers.
>> > > > >
>> > > > > _______________________________________________
>> > > > > linux-arm-kernel mailing list
>> > > > > linux-arm-kernel@lists.infradead.org
>> > > > > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>> > > > >
>> > > >
>> > > > Hi Joseph,
>> > > >
>> > > > [please keep the history of the conversation when replying]
>> > > >
>> > > > Is it a original P212 board, or a board based on the P212 ref design ?
>> > > >
>> > > > I'm currently testing the v4.13-rc2 on the official P212 board we
>> > > > received
>> > > > from Amlogic
>> > > > and using iperf3 in both directions, I have an issue after a few minutes
>> > > > running iperf3 with :
>> > > >
>> > > > # while true ; do iperf3 -c 192.168.1.21 ; iperf3 -c 192.168.1.21 -R ;
>> > > > done
>> > > >
>> > > > That cycles between the two iperf directions.
>> > > >
>> > > > After a few minutes, it stalls with :
>> > > >
>> > > > Connecting to host 192.168.1.21, port 5201
>> > > > [  4] local 192.168.1.183 port 51286 connected to 192.168.1.21 port 5201
>> > > > [ ID] Interval           Transfer     Bandwidth       Retr  Cwnd
>> > > > [  4]   0.00-1.00   sec  1.64 MBytes  13.7 Mbits/sec    2   1.41 KBytes
>> > > > [  4]   1.00-2.00   sec  0.00 Bytes  0.00 bits/sec    1   1.41 KBytes
>> > > > [  4]   2.00-3.00   sec  0.00 Bytes  0.00 bits/sec    0   1.41 KBytes
>> > > > [  4]   3.00-4.00   sec  0.00 Bytes  0.00 bits/sec    1   1.41 KBytes
>> > > > [  4]   4.00-5.00   sec  0.00 Bytes  0.00 bits/sec    0   1.41 KBytes
>> > > > [  4]   5.00-6.00   sec  0.00 Bytes  0.00 bits/sec    0   1.41 KBytes
>> > > > [  4]   6.00-7.00   sec  0.00 Bytes  0.00 bits/sec    1   1.41 KBytes
>> > > > [  4]   7.00-8.00   sec  0.00 Bytes  0.00 bits/sec    0   1.41 KBytes
>> > > > [  4]   8.00-9.00   sec  0.00 Bytes  0.00 bits/sec    0   1.41 KBytes
>> > > >
>> >
>> > Same kind of test shows no issue on the libretech-cc and the khadas-vim
>> > In this case, I don't think meson-gxl.dtsi is where you should make your
>> > change.

I am using mainline Kernel on Khadas VIM Pro and have such problems. I
did send today an update [0] to my older mailinglist post.

> ahahah, silly me ! I forgot that it was 100MBps PHY.
> tx delay makes no sense here, 2ns delay would not make much difference on a
> 25MHz clock
>
> Sorry for the confusion
>
>
>> >
>> > > >
>> > > > And then, after:
>> > > > # ifconfig eth0 down
>> > > > # ifconfig eth0 up
>> > > >
>> > > > It cycles between :
>> > > > [ 1483.009919] meson8b-dwmac c9410000.ethernet eth0: Link is Up -
>> > > > 100Mbps/Full - flow control rx/tx
>> > > > [ 1487.105725] meson8b-dwmac c9410000.ethernet eth0: Link is Down
>> > > > [ 1490.177943] meson8b-dwmac c9410000.ethernet eth0: Link is Up -
>> > > > 100Mbps/Full - flow control rx/tx
>> > > > [ 1494.273713] meson8b-dwmac c9410000.ethernet eth0: Link is Down
>> >
>> > This does not look like the issue we had on the odroid-c2.
>> > However, I have seen behavior like this (link down/up flickering) when the
>> > rgmii
>> >  delays are way off.
>> >
>> > Maybe you could try playing with "amlogic,tx-delay-ns" property ?
>>
>> we need to change dwmac-meson8b.c so it applies the TX delay also for
>> RMII PHYs. currently the TX delay is always set to 0 for RMII PHYs,
>> see: [0]
>>
>> > > >
>> > > > and so on.
>> > > >
>> > > > And this patch does not fix this at all.
>> > > >
>> > > > It seems to be more a PHY driver issue here.
>> > > >
>> > > > Could you share the results with the same command ?
>> > > >
>> > > > Neil
>> > > >
>> > >
>> > > I forgot to precise, this issue occurs when the "GXL PHY driver" is
>> > > disabled,
>> > > only relying on the
>> > > Generic PHY Driver.
>> > >
>> > > [  630.767538] Generic PHY 0.e40908ff:08: attached PHY driver [Generic
>> > > PHY]
>> > > (mii_bus:phy_addr=0.e40908ff:08, irq=-1)
>> > >
>> > >
>> > > When the PHY driver is loaded the issue disappears, with and without your
>> > > patch.
>> > >
>> > > [   25.355620] Meson GXL Internal PHY 0.e40908ff:08: attached PHY driver
>> > > [Meson GXL Internal PHY] (mii_bus:phy_addr=0.e40908ff:08, irq=-1)
>> > >
>> > > Could you please check the PHY Driver is loaded ?
>> > >
>> > > Thanks,
>> > > Neil
>> >
>> >
>> > _______________________________________________
>> > linux-amlogic mailing list
>> > linux-amlogic@lists.infradead.org
>> > http://lists.infradead.org/mailman/listinfo/linux-amlogic
>>
>>
>> [0] https://github.com/torvalds/linux/blob/master/drivers/net/ethernet/stmicro
>> /stmmac/dwmac-meson8b.c#L222
>

Regards,

[0] http://lists.infradead.org/pipermail/linux-amlogic/2017-July/004393.html