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

[crow]

Hello,

On Mon, Jul 24, 2017 at 8:32 PM, Jerome Brunet <jbrunet@xxxxxxxxxxxx> 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@xxxxxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxx
>> > > > > 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@xxxxxxxxxxxxxxxxxxx
>> > 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