[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <d7de65c614ee788152300f6d3799fd537b438496.camel@baylibre.com>
Date: Thu, 21 Feb 2019 18:46:50 +0100
From: Jerome Brunet <jbrunet@...libre.com>
To: Simon Huelck <simonmail@....de>,
Jose Abreu <jose.abreu@...opsys.com>,
Martin Blumenstingl <martin.blumenstingl@...glemail.com>
Cc: linux-amlogic@...ts.infradead.org, Gpeppe.cavallaro@...com,
alexandre.torgue@...com,
Emiliano Ingrassia <ingrassia@...genesys.com>,
netdev@...r.kernel.org
Subject: Re: stmmac / meson8b-dwmac
On Thu, 2019-02-21 at 18:27 +0100, Simon Huelck wrote:
> Hi,
>
>
>
> this was changed recently, with a patch for the EEE stuff , see here:
>
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?h=v5.0-rc7&id=e35e26b26e955c53e61c154ba26b9bb15da6b858
Hu, I was not aware this finally went through. Good !
As explained in the patch and by Jose, the GMAC should be using IRQ_LEVEL.
The realtek PHY has EEE enabled by default. Having this enabled generates a
lot of (Low Power) Interrupts.
Previously, when the GMAC used IRQ_EDGE. Because it is wrong, we would
eventually miss an IRQ and the interface would just die. Unfortunately, it was
not that easy find out.
2 years ago, we just noticed that disabling EEE would make the failure go
away. Forcing this EEE feature off through DT was merely a work around.
Now that the real cause of the problem is known, there is no reason to keep
this hack around.
Whether EEE adds a performance penality and why, is another topic.
As Jose pointed out, you can disable EEE at runtime, using ethtool.
Jerome
Powered by blists - more mailing lists