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

[Russell King (Oracle)]

On Wed, Nov 12, 2025 at 01:54:34AM +0200, Laurent Pinchart wrote:
> On Tue, Oct 28, 2025 at 09:18:17AM +0200, Laurent Pinchart wrote:
> > I didn't notice it at the time because my board was connected to a
> > switch that didn't support EEE.
> 
> I can confirm that reverting that commit makes the issue disappear. So
> we're dealing with an interrupt storm that occurs when all three of the
> following conditions are true:
> 
> - cpu-pd-wait is enabled
> - EEE is enabled
> - the peer also supports EEE

Thanks - overall, please take the statistics and interrupt status bits
with a pinch of salt - I suspect there are cases where the interrupt
is not actually enabled, and the code doesn't take action to clear
down a set status bit, but _does_ count it - so every interrupt that
happens increments the counter.

> 
> Furthermore, I tried counting bits from all the interrupt status
> registers I could find. The count of MTL_INTERRUPT_STATUS Q0IS to Q4IS
> bits is very high, and so are the DMA_CH0_STATUS TBU and ETI bits.

TBU means that the transmitter found that the next buffer was owned by
the "application" rather than the hardware, which would be normal after
getting to the end of the queued packets.

ETI means that a packet has been transferred into MTL memory, and thus
would occur for every transmitted packet.

Having dug into the imx8m documentation and the driver this morning,
I don't think TBU and ETI are the source of the interrupt storm. Their
corresponding interrupt enable bits are DMA_CHAN_INTR_ENA_TBUE and
DMA_CHAN_INTR_ENA_ETE (driver names). Both of these only appear in a
header file - the code never enables these interrupts. So, TBU and ETI
should not be causing an interrupt storm.

As for QxIS, stmmac_common_interrupt() will iterate over the queues
in use, calling stmmac_host_mtl_irq_status() aka dwmac4_irq_mtl_status()
for each. Only if this happens will MTL_CHAN_INT_CTRL() be read which
clears the status bit. In other words, if e.g. Q1IS is set, but only
one queue is being used. dwmac4_irq_mtl_status() won't be called for
queue 1, and thus MTL_CHAN_INT_CTRL() won't be read to clear Q1IS.

> The debix board's DT doesn't specify a multi-queue setup, so only
> channel 0 gets processed in stmmac_dma_interrupt(). I thought that could
> explain why Q1IS to Q4IS stay set (but not why Q0IS also has a high
> count, or why Q1IS to Q4IS are set in the first place), and enabled
> multi-queue support in DT by copying the imx8mp-evk configuration. I
> then see lots of non-zero DMA_CH1_STATUS, DMA_CH2_STATUS and
> DMA_CH4_STATUS values (but DMA_CH3_STATUS stays 0 all the time), but
> sadly this doesn't fix the interrupt storm.

Now, a queue will only be enabled if stmmac_dma_rx_mode() /
stmmac_dma_tx_mode() is called, which only happens for queues that are
going ot be used. So, I think QxIS where x >= 1 is set is a red
herring.

Given that the driver does a software reset which clears out all the
registers, any stale configuration for queues e.g. from a boot loader
can't be preserved.

> I don't think I can debug this further and figure out the root cause
> unassisted in a reasonable amount of time, so I'd like to merge
> disabling EEE as a workaround for the time being, unless someone has any
> idea of what I could test next. I'll submit a v2 of this patch with an
> updated commit message.

I'm also not fully conversant with dwmac hardware, especially not the
v5.10 hardware that is in imx8m. All the above is stuff I've pieced
together this morning from reading the driver code and the imx8m
manual. I'm putting in effort here to try and get to the bottom of
your problem without hardware... it would be helpful if others could
do the same rather than throwing their hands up.

The driver is really crappy, and part of the reason its crappy is
because of this kind of "patch in a workaround because we can't be
bothered to do the research and fix problems properly" attitude.

I'm saying enough is enough. I'm saying no, not going to merge a
workaround for this problem. I want to see stmmac improve. I've
put in considerable effort over the last year or so sorting out
fundamental issues that others just can't be bothered to solve
properly (like the DMA reset failures on resume that has plagued
this driver which no one seems _capable_ of fixing, yet I, with no
experience of stmmac, was able to analyse the issue, read the
availble documentation, and fix the problem properly once and for
all.) Either I'm bloody good at what I do and everyone else is
useless, or it's laziness by others. It pisses me off that I seem
to be one of the few who is willing to put the effort in to stuff
in the kernel to see _improvement_. I don't _have_ to work on stmmac,
but me working on stmmac benefits a lot of people.

What I'm saying is, we need more people willing to put effort in
and less bodging.

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!