[PATCH] arm64: dts: imx8mp-debix-model-a: Disable EEE for 1000T

[Laurent Pinchart]

On Sun, Nov 23, 2025 at 08:52:00AM +0000, Russell King (Oracle) wrote:
> On Sun, Nov 23, 2025 at 02:38:02PM +0900, Laurent Pinchart wrote:
> > On Sat, Nov 22, 2025 at 09:57:49AM +0000, Russell King (Oracle) wrote:
> > > On Sat, Nov 22, 2025 at 04:22:46PM +0900, Laurent Pinchart wrote:
> > > > Hello Wei,
> > > > 
> > > > On Tue, Nov 18, 2025 at 01:50:55AM +0000, Wei Fang wrote:
> > > > > Sorry, I only have a little experience with DWMac, add Clark to help look
> > > > > at this issue.
> > > > 
> > > > Thank you.
> > > > 
> > > > I think we're getting close to having a good understanding of the
> > > > problem. I've debugged it as far as I could based on the information
> > > > available publicly. Let's try to get to the bottom of this issue, it
> > > > impacts quite a lot of people and it would be very nice to fix it
> > > > properly in mainline.
> > > > 
> > > > The short summary is that I'm experiencing an interrupt storm on IRQ 135
> > > > when EEE is enabled with the EQOS interface.
> > > > 
> > > > My current theory is that
> > > > 
> > > > - The lpi_intr_o signal of the EQOS is OR'ed into IRQ 135.
> > > > - The issue is triggerted by the PHY exiting LPI mode
> > > > - When it exits LPI mode, the PHY restarts generating the RX clock
> > > >   (clk_rx_i).
> > > > - The MAC detects exit from LPI, and asserts lpi_intr_o.
> > > > - Before the CPU has time to process the interrupt, the PHY enters LPI
> > > >   mode again, and stops generating the RX clock.
> > > > - The CPU processes the interrupt and reads the GMAC4_LPI_CTRL_STATUS
> > > >   registers. This does not clear lpi_intr_o as there's no clk_rx_i.
> > > 
> > > Please try setting STMMAC_FLAG_RX_CLK_RUNS_IN_LPI in dwmac-imx.c and
> > > see whether that changes the behaviour.
> > 
> > I have tested that and it worked like a charm ! I have submitted
> > https://lore.kernel.org/r/20251123053518.8478-1-laurent.pinchart@ideasonboard.com
> > 
> > That was quite an adventure. Thank you so much for all your support, I'm
> > not sure I would have managed without you (or at least I would have
> > needed way more time). I really really appreciate it.
> > 
> > If the above patch gets accepted, we will probably be able to remove the
> > eee-broken-* properties from the i.MX8MP device tree files (and possibly
> > from i.MX8DXL and i.MX93 as well). I have mentioned that below the
> > commit message of the patch, with a test procedure as it should be
> > tested on each board.
> 
> As stated in reply to that patch, while this may reduce the severity of
> the storm, I don't think it'll completely eliminate it.
> 
> I made the suggestion to set the flag as a test to confirm whether the
> lpi_intr_o is indeed the problem by ensuring that the receive domain is
> always clocked, and thus ensuring that the signal clears within four
> clock cycles, rather than an indefinite period should the remote end
> re-enter LPI mode quicky.

You're right. I've checked replied to the patch with the following
numbers.

100TX link, eee-broken-* set: 7000 interrupts
1000T link, eee-broken-* set: 2711 interrupts
100TX link, eee-broken-* unset: 9450 interrupts
1000T link, eee-broken-* unset: 6066 interrupts

-- 
Regards,

Laurent Pinchart