Message-ID: <vwdy5d3xirgioeac3mo7ditkfxevwmwmweput3xziq6tafa3zl@vtxddkiv2tux>
Date: Tue, 3 Oct 2023 14:12:15 +0300
From: Serge Semin <fancer.lancer@...il.com>
To: Jakub Kicinski <kuba@...nel.org>
Cc: Rohan G Thomas <rohan.g.thomas@...el.com>, 
	"David S . Miller" <davem@...emloft.net>, Alexandre Torgue <alexandre.torgue@...s.st.com>, 
	Jose Abreu <joabreu@...opsys.com>, Eric Dumazet <edumazet@...gle.com>, 
	Paolo Abeni <pabeni@...hat.com>, Maxime Coquelin <mcoquelin.stm32@...il.com>, 
	netdev@...r.kernel.org, linux-stm32@...md-mailman.stormreply.com, 
	linux-arm-kernel@...ts.infradead.org, devicetree@...r.kernel.org, linux-kernel@...r.kernel.org, 
	Andy Shevchenko <andriy.shevchenko@...ux.intel.com>
Subject: Re: [PATCH net-next 1/1] net: stmmac: xgmac: EST interrupts handling

Hi Jakub

On Mon, Oct 02, 2023 at 01:55:51PM -0700, Jakub Kicinski wrote:
> On Tue, 26 Sep 2023 14:25:56 +0300 Serge Semin wrote:
> > On Sat, Sep 23, 2023 at 11:10:31AM +0800, Rohan G Thomas wrote:
> > > Enabled the following EST related interrupts:
> > >   1) Constant Gate Control Error (CGCE)
> > >   2) Head-of-Line Blocking due to Scheduling (HLBS)
> > >   3) Head-of-Line Blocking due to Frame Size (HLBF)
> > >   4) Base Time Register error (BTRE)
> > >   5) Switch to S/W owned list Complete (SWLC)
> > > Also, add EST errors into the ethtool statistic.
> > > 
> > > The commit e49aa315cb01 ("net: stmmac: EST interrupts handling and
> > > error reporting") and commit 9f298959191b ("net: stmmac: Add EST
> > > errors into ethtool statistic") add EST interrupts handling and error
> > > reporting support to DWMAC4 core. This patch enables the same support
> > > for XGMAC.  
> > 
> > So, this is basically a copy of what was done for the DW QoS Eth
> > IP-core (DW GMAC v4.x/v5.x). IMO it would be better to factor it out
> > into a separate module together with the rest of the setup methods
> > like it's done for TC or PTP. But since it implies some much more work
> > I guess we can leave it as is for now...
> 

> I think we can push back a little harder. At the very least we should
> get a clear explanation why this copy'n'paste is needed, i.e. what are
> the major differences. No?

AFAICS there are only two firm differences between the DW QoS Eth v5.x
and DW XGMAC v3.x ESTs implementations I managed to spot from the
currently available code (My DW XGMAC _v2.11a_ HW manual doesn't have
such feature described):

1. MTL_EST_CONTROL.PTOV field offset and width: QoS [31;24], XGMAC [31;23];

2. EST CSRs base addresses: QoS 0x0c50, XGMAC 0x1050.

After the patch in subject is applied the EST config method and EST
IRQ status handlers will look almost identical except the next two
things:

1. XGMAC EST-write implementation performs atomic
MTL_EST_GCL_CONTROL.SRWO flag polling. Initially added by Jose. Not
sure whether the sleepless polling is really needed because the
stmmac_est_configure() is always called within the est->lock mutex
being taken.

2. PTP time offset setup performed by means of the
MTL_EST_CONTROL.PTOV field. DW QoS Eth v5.x HW manual claims it's "The
value of PTP Clock period multiplied by 6 in nanoseconds." So either
Jose got mistaken by using _9_ for DW XGMAC v3.x or the DW XGMAC
indeed is different in that aspect.

The rest of the differences is in the macros and functions names.
Please see the attached diff-file I collected for the EST-related code
in the DW QoS Eth v5.x and DW XGMAC v3.x modules.

Getting back to the refactoring. So basically the EST part can be
factored out in a similar way as it's done for instance for TC/PTP:

1. Define EST_GMAC4_OFFSET and EST_XGMAC_OFFSET macros in the new
header file "stmmac_est.h" (I'd prefer to drop the stmmac_-prefix but
all the sub-modules except "mmc" tends to have it).

2. Add stmmac_regs_off.est field and initialize it with the respective
offsets for the QoS and XGMAC IP-cores in the stmmac_hw static array
(hwif.c).

3. Add stmmac_priv.estaddr field and initialize it with 
(ioaddr + stmmac_regs_off.est) in the stmmac_hwif_init() function (hwif.c).

4. Define stmmac_est_ops structure in "hwif.h" with two
callbacks: .est_configure and .est_irq_status. Add the
stmmac_hwif_entry.est field of the const-pointer type to that
structure instance.

5. Redefined the stmmac_est_configure() and stmmac_est_irq_status()
macro-functions to using the callbacks from the stmmac_priv->hw->est
(hwif.h).

6. Drop the stmmac_ops.est_configure and stmmac_ops.est_irq_status.
fields (hwif.h).

7. Move all the EST-related macros to the "stmmac_est.h" file. Make
sure they are defined with EST_-prefix and the CSRs are based from
zero address since they will be utilized as the offsets for the
stmmac_priv.estaddr field.

8. Move all the EST-related functions to the new "stmmac_est.c"
module. Make sure they use the new generic EST CSRs macros and the
stmmac_priv.estaddr field as the base address of the EST CSRs. Take
into account the possible differences in the MTL_EST_CONTROL.PTOV
field initialization for the DW QoS and DW XGMAC IP-cores. Add
stmmac_est.o to stmmac-objs list in the Makefile.

9. Define stmmac_est_ops structure instance (dwmac410_est_ops) in
"stmmac_est.c" and initialize its fields with the est_configure() and
est_irq_status() functions define in 8.

10. Use the stmmac_est_ops structure instance (dwmac410_est_ops) to
initialize the stmmac_hwif_entry.est field to point to that instance
for the DW Eth QoS and DW XGMAC IP-cores.

If I didn't miss some details after that we'll have a common EST
module utilized for both DW QoS Eth and DW XGMAC IP-cores.

-Serge(y)

View attachment "dwmac_est.diff" of type "text/x-patch" (8639 bytes)

Powered by blists - more mailing lists