From: jbrunet@baylibre.com (Jerome Brunet)
To: linus-amlogic@lists.infradead.org
Subject: [RFC PATCH net v2 0/3] Fix OdroidC2 Gigabit Tx link issue
Date: Thu, 24 Nov 2016 17:01:46 +0100 [thread overview]
Message-ID: <1480003306.17538.137.camel@baylibre.com> (raw)
In-Reply-To: <CAFBinCCexmS_z9FCX-ud5NgGhhP7xJ_cLxpC7TEc=mLAdafosg@mail.gmail.com>
On Thu, 2016-11-24 at 15:40 +0100, Martin Blumenstingl wrote:
> Hi Jerome,
>
> On Mon, Nov 21, 2016 at 4:35 PM, Jerome Brunet <jbrunet@baylibre.com>
> wrote:
> >
> > This patchset fixes an issue with the OdroidC2 board (DWMAC +
> > RTL8211F).
> > Initially reported as a low Tx throughput issue at gigabit speed,
> > the
> > platform enters LPI too often. This eventually break the link (both
> > Tx
> > and Rx), and require to bring the interface down and up again to
> > get the
> > Rx path working again.
> >
> > The root cause of this issue is not fully understood yet but
> > disabling EEE
> > advertisement on the PHY prevent this feature to be negotiated.
> > With this change, the link is stable and reliable, with the
> > expected
> > throughput performance.
> I have just sent a series which allows configuring the TX delay on
> the
> MAC (dwmac-meson8b glue) side: [0]
> Disabling the TX delay generated by the MAC fixes TX throughput for
> me, even when leaving EEE enabled in the RTL8211F PHY driver!
>
> Unfortunately the RTL8211F PHY is a black-box for the community
> because there is no public datasheeet available.
> *maybe* (pure speculation!) they're enabling the TX delay based on
> some internal magic only when EEE is enabled.
Hi already tried acting on the register setting the TX_delay. I also
tried on the PHY. I never been able to improve situation on the
Odroic2. Only disabling EEE improved the situation.
To make sure, i tried again with your patch but the result remains
unchanged. With Tx_delay disabled (either the mac or the phy), the
situation is even worse, it seems that nothing gets through
>
> Jerome, could you please re-test the behavior on your Odroid-C2 when
> you have EEE still enabled but the TX-delay disabled?
> In my case throughput is fine, and "$ ethtool -S eth0 | grep lpi"
> gives:
> ????irq_tx_path_in_lpi_mode_n: 0
> ????irq_tx_path_exit_lpi_mode_n: 0
> ????irq_rx_path_in_lpi_mode_n: 0
> ????irq_rx_path_exit_lpi_mode_n: 0
>
I still have lpi interrupts on my side. I don't get how a properly
configured tx_delay would disable EEE. I must be missing something
here.
>
> Regards,
> Martin
>
>
> [0] http://lists.infradead.org/pipermail/linux-amlogic/2016-November/
> 001674.html
WARNING: multiple messages have this Message-ID (diff)
From: jbrunet@baylibre.com (Jerome Brunet)
To: linux-arm-kernel@lists.infradead.org
Subject: [RFC PATCH net v2 0/3] Fix OdroidC2 Gigabit Tx link issue
Date: Thu, 24 Nov 2016 17:01:46 +0100 [thread overview]
Message-ID: <1480003306.17538.137.camel@baylibre.com> (raw)
In-Reply-To: <CAFBinCCexmS_z9FCX-ud5NgGhhP7xJ_cLxpC7TEc=mLAdafosg@mail.gmail.com>
On Thu, 2016-11-24 at 15:40 +0100, Martin Blumenstingl wrote:
> Hi Jerome,
>
> On Mon, Nov 21, 2016 at 4:35 PM, Jerome Brunet <jbrunet@baylibre.com>
> wrote:
> >
> > This patchset fixes an issue with the OdroidC2 board (DWMAC +
> > RTL8211F).
> > Initially reported as a low Tx throughput issue at gigabit speed,
> > the
> > platform enters LPI too often. This eventually break the link (both
> > Tx
> > and Rx), and require to bring the interface down and up again to
> > get the
> > Rx path working again.
> >
> > The root cause of this issue is not fully understood yet but
> > disabling EEE
> > advertisement on the PHY prevent this feature to be negotiated.
> > With this change, the link is stable and reliable, with the
> > expected
> > throughput performance.
> I have just sent a series which allows configuring the TX delay on
> the
> MAC (dwmac-meson8b glue) side: [0]
> Disabling the TX delay generated by the MAC fixes TX throughput for
> me, even when leaving EEE enabled in the RTL8211F PHY driver!
>
> Unfortunately the RTL8211F PHY is a black-box for the community
> because there is no public datasheeet available.
> *maybe* (pure speculation!) they're enabling the TX delay based on
> some internal magic only when EEE is enabled.
Hi already tried acting on the register setting the TX_delay. I also
tried on the PHY. I never been able to improve situation on the
Odroic2. Only disabling EEE improved the situation.
To make sure, i tried again with your patch but the result remains
unchanged. With Tx_delay disabled (either the mac or the phy), the
situation is even worse, it seems that nothing gets through
>
> Jerome, could you please re-test the behavior on your Odroid-C2 when
> you have EEE still enabled but the TX-delay disabled?
> In my case throughput is fine, and "$ ethtool -S eth0 | grep lpi"
> gives:
> ????irq_tx_path_in_lpi_mode_n: 0
> ????irq_tx_path_exit_lpi_mode_n: 0
> ????irq_rx_path_in_lpi_mode_n: 0
> ????irq_rx_path_exit_lpi_mode_n: 0
>
I still have lpi interrupts on my side. I don't get how a properly
configured tx_delay would disable EEE. I must be missing something
here.
>
> Regards,
> Martin
>
>
> [0] http://lists.infradead.org/pipermail/linux-amlogic/2016-November/
> 001674.html
WARNING: multiple messages have this Message-ID (diff)
From: Jerome Brunet <jbrunet-rdvid1DuHRBWk0Htik3J/w@public.gmane.org>
To: Martin Blumenstingl
<martin.blumenstingl-gM/Ye1E23mwN+BqQ9rBEUg@public.gmane.org>
Cc: netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Florian Fainelli
<f.fainelli-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
Carlo Caione <carlo-KA+7E9HrN00dnm+yROfE0A@public.gmane.org>,
Kevin Hilman <khilman-rdvid1DuHRBWk0Htik3J/w@public.gmane.org>,
Giuseppe Cavallaro <peppe.cavallaro-qxv4g6HH51o@public.gmane.org>,
Alexandre TORGUE <alexandre.torgue-qxv4g6HH51o@public.gmane.org>,
Andre Roth <neolynx-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
Neil Armstrong
<narmstrong-rdvid1DuHRBWk0Htik3J/w@public.gmane.org>,
linux-amlogic-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Subject: Re: [RFC PATCH net v2 0/3] Fix OdroidC2 Gigabit Tx link issue
Date: Thu, 24 Nov 2016 17:01:46 +0100 [thread overview]
Message-ID: <1480003306.17538.137.camel@baylibre.com> (raw)
In-Reply-To: <CAFBinCCexmS_z9FCX-ud5NgGhhP7xJ_cLxpC7TEc=mLAdafosg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On Thu, 2016-11-24 at 15:40 +0100, Martin Blumenstingl wrote:
> Hi Jerome,
>
> On Mon, Nov 21, 2016 at 4:35 PM, Jerome Brunet <jbrunet-rdvid1DuHRBWk0Htik3J/w@public.gmane.org>
> wrote:
> >
> > This patchset fixes an issue with the OdroidC2 board (DWMAC +
> > RTL8211F).
> > Initially reported as a low Tx throughput issue at gigabit speed,
> > the
> > platform enters LPI too often. This eventually break the link (both
> > Tx
> > and Rx), and require to bring the interface down and up again to
> > get the
> > Rx path working again.
> >
> > The root cause of this issue is not fully understood yet but
> > disabling EEE
> > advertisement on the PHY prevent this feature to be negotiated.
> > With this change, the link is stable and reliable, with the
> > expected
> > throughput performance.
> I have just sent a series which allows configuring the TX delay on
> the
> MAC (dwmac-meson8b glue) side: [0]
> Disabling the TX delay generated by the MAC fixes TX throughput for
> me, even when leaving EEE enabled in the RTL8211F PHY driver!
>
> Unfortunately the RTL8211F PHY is a black-box for the community
> because there is no public datasheeet available.
> *maybe* (pure speculation!) they're enabling the TX delay based on
> some internal magic only when EEE is enabled.
Hi already tried acting on the register setting the TX_delay. I also
tried on the PHY. I never been able to improve situation on the
Odroic2. Only disabling EEE improved the situation.
To make sure, i tried again with your patch but the result remains
unchanged. With Tx_delay disabled (either the mac or the phy), the
situation is even worse, it seems that nothing gets through
>
> Jerome, could you please re-test the behavior on your Odroid-C2 when
> you have EEE still enabled but the TX-delay disabled?
> In my case throughput is fine, and "$ ethtool -S eth0 | grep lpi"
> gives:
> irq_tx_path_in_lpi_mode_n: 0
> irq_tx_path_exit_lpi_mode_n: 0
> irq_rx_path_in_lpi_mode_n: 0
> irq_rx_path_exit_lpi_mode_n: 0
>
I still have lpi interrupts on my side. I don't get how a properly
configured tx_delay would disable EEE. I must be missing something
here.
>
> Regards,
> Martin
>
>
> [0] http://lists.infradead.org/pipermail/linux-amlogic/2016-November/
> 001674.html
--
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
WARNING: multiple messages have this Message-ID (diff)
From: Jerome Brunet <jbrunet@baylibre.com>
To: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
Cc: netdev@vger.kernel.org, devicetree@vger.kernel.org,
Florian Fainelli <f.fainelli@gmail.com>,
Carlo Caione <carlo@caione.org>,
Kevin Hilman <khilman@baylibre.com>,
Giuseppe Cavallaro <peppe.cavallaro@st.com>,
Alexandre TORGUE <alexandre.torgue@st.com>,
Andre Roth <neolynx@gmail.com>,
Neil Armstrong <narmstrong@baylibre.com>,
linux-amlogic@lists.infradead.org,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org
Subject: Re: [RFC PATCH net v2 0/3] Fix OdroidC2 Gigabit Tx link issue
Date: Thu, 24 Nov 2016 17:01:46 +0100 [thread overview]
Message-ID: <1480003306.17538.137.camel@baylibre.com> (raw)
In-Reply-To: <CAFBinCCexmS_z9FCX-ud5NgGhhP7xJ_cLxpC7TEc=mLAdafosg@mail.gmail.com>
On Thu, 2016-11-24 at 15:40 +0100, Martin Blumenstingl wrote:
> Hi Jerome,
>
> On Mon, Nov 21, 2016 at 4:35 PM, Jerome Brunet <jbrunet@baylibre.com>
> wrote:
> >
> > This patchset fixes an issue with the OdroidC2 board (DWMAC +
> > RTL8211F).
> > Initially reported as a low Tx throughput issue at gigabit speed,
> > the
> > platform enters LPI too often. This eventually break the link (both
> > Tx
> > and Rx), and require to bring the interface down and up again to
> > get the
> > Rx path working again.
> >
> > The root cause of this issue is not fully understood yet but
> > disabling EEE
> > advertisement on the PHY prevent this feature to be negotiated.
> > With this change, the link is stable and reliable, with the
> > expected
> > throughput performance.
> I have just sent a series which allows configuring the TX delay on
> the
> MAC (dwmac-meson8b glue) side: [0]
> Disabling the TX delay generated by the MAC fixes TX throughput for
> me, even when leaving EEE enabled in the RTL8211F PHY driver!
>
> Unfortunately the RTL8211F PHY is a black-box for the community
> because there is no public datasheeet available.
> *maybe* (pure speculation!) they're enabling the TX delay based on
> some internal magic only when EEE is enabled.
Hi already tried acting on the register setting the TX_delay. I also
tried on the PHY. I never been able to improve situation on the
Odroic2. Only disabling EEE improved the situation.
To make sure, i tried again with your patch but the result remains
unchanged. With Tx_delay disabled (either the mac or the phy), the
situation is even worse, it seems that nothing gets through
>
> Jerome, could you please re-test the behavior on your Odroid-C2 when
> you have EEE still enabled but the TX-delay disabled?
> In my case throughput is fine, and "$ ethtool -S eth0 | grep lpi"
> gives:
> irq_tx_path_in_lpi_mode_n: 0
> irq_tx_path_exit_lpi_mode_n: 0
> irq_rx_path_in_lpi_mode_n: 0
> irq_rx_path_exit_lpi_mode_n: 0
>
I still have lpi interrupts on my side. I don't get how a properly
configured tx_delay would disable EEE. I must be missing something
here.
>
> Regards,
> Martin
>
>
> [0] http://lists.infradead.org/pipermail/linux-amlogic/2016-November/
> 001674.html
next prev parent reply other threads:[~2016-11-24 16:01 UTC|newest]
Thread overview: 50+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-11-21 15:35 [RFC PATCH net v2 0/3] Fix OdroidC2 Gigabit Tx link issue Jerome Brunet
2016-11-21 15:35 ` Jerome Brunet
2016-11-21 15:35 ` Jerome Brunet
2016-11-21 15:35 ` [RFC PATCH net v2 1/3] net: phy: add an option to disable EEE advertisement Jerome Brunet
2016-11-21 15:35 ` Jerome Brunet
2016-11-21 15:35 ` Jerome Brunet
2016-11-22 5:04 ` Anand Moon
2016-11-22 5:04 ` Anand Moon
2016-11-22 5:04 ` Anand Moon
2016-11-22 5:04 ` Anand Moon
2016-11-21 15:35 ` [RFC PATCH net v2 2/3] dt: bindings: add ethernet phy eee-disable-advert option documentation Jerome Brunet
2016-11-21 15:35 ` Jerome Brunet
2016-11-21 15:35 ` Jerome Brunet
2016-11-21 16:01 ` Andrew Lunn
2016-11-21 16:01 ` Andrew Lunn
2016-11-21 16:01 ` Andrew Lunn
2016-11-21 16:16 ` Jerome Brunet
2016-11-21 16:16 ` Jerome Brunet
2016-11-21 16:16 ` Jerome Brunet
2016-11-21 16:16 ` Jerome Brunet
2016-11-21 16:47 ` Andrew Lunn
2016-11-21 16:47 ` Andrew Lunn
2016-11-21 16:47 ` Andrew Lunn
2016-11-21 16:47 ` Andrew Lunn
2016-11-22 5:35 ` Florian Fainelli
2016-11-22 5:35 ` Florian Fainelli
2016-11-22 5:35 ` Florian Fainelli
2016-11-22 10:13 ` Jerome Brunet
2016-11-22 10:13 ` Jerome Brunet
2016-11-22 10:13 ` Jerome Brunet
2016-11-22 10:13 ` Jerome Brunet
2016-11-21 15:35 ` [RFC PATCH net v2 3/3] ARM64: dts: meson: odroidc2: disable advertisement EEE for GbE Jerome Brunet
2016-11-21 15:35 ` Jerome Brunet
2016-11-21 15:35 ` Jerome Brunet
2016-11-21 15:35 ` Jerome Brunet
2016-11-24 14:40 ` [RFC PATCH net v2 0/3] Fix OdroidC2 Gigabit Tx link issue Martin Blumenstingl
2016-11-24 14:40 ` Martin Blumenstingl
2016-11-24 14:40 ` Martin Blumenstingl
2016-11-24 16:01 ` Jerome Brunet [this message]
2016-11-24 16:01 ` Jerome Brunet
2016-11-24 16:01 ` Jerome Brunet
2016-11-24 16:01 ` Jerome Brunet
2016-11-24 17:10 ` Martin Blumenstingl
2016-11-24 17:10 ` Martin Blumenstingl
2016-11-24 17:10 ` Martin Blumenstingl
2016-11-24 17:10 ` Martin Blumenstingl
2016-11-25 9:55 ` Jerome Brunet
2016-11-25 9:55 ` Jerome Brunet
2016-11-25 9:55 ` Jerome Brunet
2016-11-25 9:55 ` Jerome Brunet
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1480003306.17538.137.camel@baylibre.com \
--to=jbrunet@baylibre.com \
--cc=linus-amlogic@lists.infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.