[PATCH net-next] net: stmmac: fix dwmac4 transmit performance regression

[Georg Gottleuber]

Am 16.01.26 um 01:49 schrieb Russell King (Oracle):
> dwmac4's transmit performance dropped by a factor of four due to an
> incorrect assumption about which definitions are for what. This
> highlights the need for sane register macros.
> 
> Commit 8409495bf6c9 ("net: stmmac: cores: remove many xxx_SHIFT
> definitions") changed the way the txpbl value is merged into the
> register:
> 
>         value = readl(ioaddr + DMA_CHAN_TX_CONTROL(dwmac4_addrs, chan));
> -       value = value | (txpbl << DMA_BUS_MODE_PBL_SHIFT);
> +       value = value | FIELD_PREP(DMA_BUS_MODE_PBL, txpbl);
> 
> With the following in the header file:
> 
>  #define DMA_BUS_MODE_PBL               BIT(16)
> -#define DMA_BUS_MODE_PBL_SHIFT         16
> 
> The assumption here was that DMA_BUS_MODE_PBL was the mask for
> DMA_BUS_MODE_PBL_SHIFT, but this turns out not to be the case.
> 
> The field is actually six bits wide, buts 21:16, and is called
> TXPBL.
> 
> What's even more confusing is, there turns out to be a PBLX8
> single bit in the DMA_CHAN_CONTROL register (0x1100 for channel 0),
> and DMA_BUS_MODE_PBL seems to be used for that. However, this bit
> et.al. was listed under a comment "/* DMA SYS Bus Mode bitmap */"
> which is for register 0x1004.
> 
> Fix this up by adding an appropriately named field definition under
> the DMA_CHAN_TX_CONTROL() register address definition.
> 
> Move the RPBL mask definition under DMA_CHAN_RX_CONTROL(), correctly
> renaming it as well.
> 
> Also move the PBL bit definition under DMA_CHAN_CONTROL(), correctly
> renaming it.
> 
> This removes confusion over the PBL fields.
> 
> Signed-off-by: Russell King (Oracle) <rmk+kernel at armlinux.org.uk>

Thank you for this patch, which significantly speeds up the transmit (by
more than a factor of nine on our devices with Motorcomm yt6801).

Unfortunately, this patch also causes DMA errors on two of our devices;
logs from a iperf3 test are attached.

Strangely enough, a third device with the same Motorcomm yt6801 does not
appear to be affected by the DMA errors. However, further testing is needed.

Do you have any ideas for further tests?

Regards,
Georg
-------------- next part --------------
A non-text attachment was scrubbed...
Name: dmesg_stellaris16_intel_gen6.log.gz
Type: application/gzip
Size: 32509 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20260313/7b19ab18/attachment-0002.gz>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: dmesg_stellaris_slim_15_intel_gen6.log.gz
Type: application/gzip
Size: 39139 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20260313/7b19ab18/attachment-0003.gz>