net: stmmac: refactor FPE for gmac4 and xgmac
Subsystems (4)
cover net: stmmac: refactor FPE for gmac4 and xgmac
Refactor FPE implementation by moving common code for DWMAC4 and DWXGMAC into a separate FPE module.
FPE implementation for DWMAC4 and DWXGMAC differs only for:
1) Offset address of MAC_FPE_CTRL_STS
2) FPRQ(Frame Preemption Residue Queue) field in MAC_RxQ_Ctrl1
Tested on DWMAC CORE 5.20a and DWXGMAC CORE 3.20a
Furong Xu (7):
net: stmmac: xgmac: drop incomplete FPE implementation
net: stmmac: gmac4: drop FPE implementation for refactoring
net: stmmac: refactor Frame Preemption(FPE) implementation
net: stmmac: gmac4: complete FPE support
net: stmmac: xgmac: rename XGMAC_RQ to XGMAC_FPRQ
net: stmmac: xgmac: complete FPE support
net: stmmac: xgmac: enable Frame Preemption Interrupt by default
drivers/net/ethernet/stmicro/stmmac/Makefile | 2 +- drivers/net/ethernet/stmicro/stmmac/common.h | 1 + .../net/ethernet/stmicro/stmmac/dwmac4_core.c | 6 - drivers/net/ethernet/stmicro/stmmac/dwmac5.c | 66 --------- drivers/net/ethernet/stmicro/stmmac/dwmac5.h | 16 --- .../net/ethernet/stmicro/stmmac/dwxgmac2.h | 9 +- .../ethernet/stmicro/stmmac/dwxgmac2_core.c | 27 ---- drivers/net/ethernet/stmicro/stmmac/hwif.c | 7 + drivers/net/ethernet/stmicro/stmmac/hwif.h | 30 ++-- .../net/ethernet/stmicro/stmmac/stmmac_fpe.c | 131 ++++++++++++++++++ .../net/ethernet/stmicro/stmmac/stmmac_fpe.h | 16 +++ 11 files changed, 177 insertions(+), 134 deletions(-) create mode 100644 drivers/net/ethernet/stmicro/stmmac/stmmac_fpe.c create mode 100644 drivers/net/ethernet/stmicro/stmmac/stmmac_fpe.h
Signature · 1 line
2.34.1
PATCH 1/7 net: stmmac: xgmac: drop incomplete FPE implementation
The FPE support for xgmac is incomplete, drop it temporarily. Once FPE implementation is refactored, xgmac support will be added.
--- .../net/ethernet/stmicro/stmmac/dwxgmac2.h | 2 -- .../ethernet/stmicro/stmmac/dwxgmac2_core.c | 27 ------------------- 2 files changed, 29 deletions(-)
drivers/net/ethernet/stmicro/stmmac/dwxgmac2.h +0 -2
@@ -193,8 +193,6 @@#define XGMAC_MDIO_ADDR 0x00000200#define XGMAC_MDIO_DATA 0x00000204#define XGMAC_MDIO_C22P 0x00000220 -#define XGMAC_FPE_CTRL_STS 0x00000280 -#define XGMAC_EFPE BIT(0)#define XGMAC_ADDRx_HIGH (x) (0x00000300 + (x) * 0x8)#define XGMAC_ADDR_MAX 32#define XGMAC_AE BIT(31)
drivers/net/ethernet/stmicro/stmmac/dwxgmac2_core.c +0 -27
@@ -1505,31 +1505,6 @@ static void dwxgmac2_set_arp_offload(struct mac_device_info *hw, bool en,writel (value, ioaddr +XGMAC_RX_CONFIG ); } -static void dwxgmac3_fpe_configure (void __iomem *ioaddr,struct stmmac_fpe_cfg *cfg, -u32 num_txq, -u32 num_rxq,bool enable) -{ -u32 value; - -if (!enable) { - value =readl (ioaddr +XGMAC_FPE_CTRL_STS ); - - value &= ~XGMAC_EFPE ; - -writel (value, ioaddr +XGMAC_FPE_CTRL_STS ); -return ; - } - - value =readl (ioaddr +XGMAC_RXQ_CTRL1 ); - value &= ~XGMAC_RQ ; - value |= (num_rxq -1 ) <<XGMAC_RQ_SHIFT ; -writel (value, ioaddr +XGMAC_RXQ_CTRL1 ); - - value =readl (ioaddr +XGMAC_FPE_CTRL_STS ); - value |=XGMAC_EFPE ; -writel (value, ioaddr +XGMAC_FPE_CTRL_STS ); -} -const struct stmmac_ops dwxgmac210_ops = { .core_init = dwxgmac2_core_init, .set_mac = dwxgmac2_set_mac,
@@ -1570,7 +1545,6 @@ const struct stmmac_ops dwxgmac210_ops = { .config_l3_filter = dwxgmac2_config_l3_filter, .config_l4_filter = dwxgmac2_config_l4_filter, .set_arp_offload = dwxgmac2_set_arp_offload, - .fpe_configure = dwxgmac3_fpe_configure, }; static void dwxlgmac2_rx_queue_enable(struct mac_device_info *hw, u8 mode,
@@ -1627,7 +1601,6 @@ const struct stmmac_ops dwxlgmac2_ops = { .config_l3_filter = dwxgmac2_config_l3_filter, .config_l4_filter = dwxgmac2_config_l4_filter, .set_arp_offload = dwxgmac2_set_arp_offload, - .fpe_configure = dwxgmac3_fpe_configure, };int dwxgmac2_setup (struct stmmac_priv *priv)
Signature · 1 line
2.34.1
Re: [PATCH net-next v1 1/7] net: stmmac: xgmac: drop incomplete FPE implementation
Quoted 2 lines · Furong Xu
The FPE support for xgmac is incomplete, drop it temporarily. Once FPE implementation is refactored, xgmac support will be added.
This is a pretty unusual thing to do. What does the current implementation do? Is there enough for it to actually work? If i was doing a git bisect and landed on this patch, could i find my networking is broken?
More normal is to build a new implementation by the side, and then swap to it.
Andrew
Re: [PATCH net-next v1 1/7] net: stmmac: xgmac: drop incomplete FPE implementation
Hi Andrew, Furong,
Quoted 9 lines · Andrew Lunn
Quoted 2 lines · Furong Xu
The FPE support for xgmac is incomplete, drop it temporarily. Once FPE implementation is refactored, xgmac support will be added.
This is a pretty unusual thing to do. What does the current implementation do? Is there enough for it to actually work? If i was doing a git bisect and landed on this patch, could i find my networking is broken?
Quoted 5 lines
More normal is to build a new implementation by the side, and then swap to it.
Andrew
There were 2 earlier attempts from Jianheng Zhang @ Synopsys to add FPE support to new hardware.
I told him that the #1 priority should be to move the stmmac driver over to the new standard API which uses ethtool + tc.
https://lore.kernel.org/netdev/CY5PR12MB63726FED738099761A9B81E7BF8FA@CY5PR12MB6372.namprd12.prod.outlook.com/
https://lore.kernel.org/netdev/CY5PR12MB63727C24923AE855CFF0D425BF8EA@CY5PR12MB6372.namprd12.prod.outlook.com/
I'm not sure what happened in the meantime. Jianheng must have faced some issue, because he never came back.
I did comment this at the time:
| Even this very patch is slightly strange - it is not brand new hardware | support, but it fills in some more FPE ops in dwxlgmac2_ops - when | dwxgmac3_fpe_configure() was already there. So this suggests the | existing support was incomplete. How complete is it now? No way to tell. | There is a selftest to tell, but we can't run it because the driver | doesn't integrate with those kernel APIs.
So it is relatively known that the support is incomplete. But I still think we should push for more reviewer insight into this driver by having access to a selftest to get a clearer picture of how it behaves. For that, we need the compliance to the common API.
Otherwise, I completely agree to the idea that any development should be done incrementally on top of whatever already exists, instead of putting a curtain on and then taking it back off.
Re: [PATCH net-next v1 1/7] net: stmmac: xgmac: drop incomplete FPE implementation
Hi Vladimir
Quoted 38 lines · Vladimir Oltean
Hi Andrew, Furong,
Quoted 9 lines · Andrew Lunn
Quoted 2 lines · Furong Xu
The FPE support for xgmac is incomplete, drop it temporarily. Once FPE implementation is refactored, xgmac support will be added.
This is a pretty unusual thing to do. What does the current implementation do? Is there enough for it to actually work? If i was doing a git bisect and landed on this patch, could i find my networking is broken?
Quoted 5 lines
More normal is to build a new implementation by the side, and then swap to it.
Andrew
There were 2 earlier attempts from Jianheng Zhang @ Synopsys to add FPE support to new hardware.
I told him that the #1 priority should be to move the stmmac driver over to the new standard API which uses ethtool + tc.
https://lore.kernel.org/netdev/CY5PR12MB63726FED738099761A9B81E7BF8FA@CY5PR12MB6372.namprd12.prod.outlook.com/
https://lore.kernel.org/netdev/CY5PR12MB63727C24923AE855CFF0D425BF8EA@CY5PR12MB6372.namprd12.prod.outlook.com/I'm not sure what happened in the meantime. Jianheng must have faced some issue, because he never came back.
I did comment this at the time:
| Even this very patch is slightly strange - it is not brand new hardware | support, but it fills in some more FPE ops in dwxlgmac2_ops - when | dwxgmac3_fpe_configure() was already there. So this suggests the | existing support was incomplete. How complete is it now? No way to tell. | There is a selftest to tell, but we can't run it because the driver | doesn't integrate with those kernel APIs.
Quoted 5 lines
So it is relatively known that the support is incomplete. But I still think we should push for more reviewer insight into this driver by having access to a selftest to get a clearer picture of how it behaves. For that, we need the compliance to the common API.
After some searching and learning about your commits for FPE using the generic framework, I think it is clear enough to me to implement the new standard driver interface which uses ethtool + tc, and then the refactor of low level FPE function can follow.
Thanks.
Issue with SJA1105QELY on STM32MP151CAA3T over RGMII Interface
In reply to Vladimir OlteanHi Vladimir,
I hope this email finds you well.
I'm reaching out because I'm having an issue with the SJA1105QELY switch connected to an STM32MP151CAA3T over an RGMII interface. About 1 in every 10 starts, the SJA1105 fails to receive frames from the CPU. Specifically, the p04_n_rxfrm counters stay at 0, and all RX error counters are zero too, indicating that the port doesn't seem to see any frames at all.
I can reproduce this issue even without rebooting, just by using the unbind/bind sequence:
```sh echo spi0.0 > /sys/bus/spi/drivers/sja1105/unbind echo spi0.0 > /sys/bus/spi/drivers/sja1105/bind ip l s dev t10 up sleep 1 ethtool -t t10 ```
Running the ethtool self-test is the most reliable way to reproduce the problem early without additional software.
I've checked the RX_CTL and RX_CLK lines of the SJA1105 port 4 with an oscilloscope, and both look correct and identical in both working and non-working cases.
Interestingly, the external RGMII switch ports are working fine. I can bridge them and push frames in all directions without issues. Transferring frames from the switch to the CPU works fine as well, which makes me suspect that the problem is isolated to the reception of frames on the CPU RGMII interface.
Is it possible there's some RGMII-specific race condition during the initialization stage? The bootloader implementation of the SJA1105 on same HW seems to work fine too, so this seems to be a Linux kernel-specific issue.
Any insights or suggestions you might have would be greatly appreciated!
Thanks a lot for your help.
Best regards,
Oleksij
Signature · 4 lines
Pengutronix e.K. | | Steuerwalder Str. 21 | http://www.pengutronix.de/ | 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 | Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
Re: Issue with SJA1105QELY on STM32MP151CAA3T over RGMII Interface
Hi Oleksij,
Quoted 35 lines · Oleksij Rempel
Hi Vladimir,
I hope this email finds you well.
I'm reaching out because I'm having an issue with the SJA1105QELY switch connected to an STM32MP151CAA3T over an RGMII interface. About 1 in every 10 starts, the SJA1105 fails to receive frames from the CPU. Specifically, the
p04_n_rxfrmcounters stay at 0, and all RX error counters are zero too, indicating that the port doesn't seem to see any frames at all.I can reproduce this issue even without rebooting, just by using the unbind/bind sequence:
```sh echo spi0.0 > /sys/bus/spi/drivers/sja1105/unbind echo spi0.0 > /sys/bus/spi/drivers/sja1105/bind ip l s dev t10 up sleep 1 ethtool -t t10 ```Running the ethtool self-test is the most reliable way to reproduce the problem early without additional software.
I've checked the
RX_CTLandRX_CLKlines of the SJA1105 port 4 with an oscilloscope, and both look correct and identical in both working and non-working cases.Interestingly, the external RGMII switch ports are working fine. I can bridge them and push frames in all directions without issues. Transferring frames from the switch to the CPU works fine as well, which makes me suspect that the problem is isolated to the reception of frames on the CPU RGMII interface.
Quoted 7 lines
Is it possible there's some RGMII-specific race condition during the initialization stage? The bootloader implementation of the SJA1105 on same HW seems to work fine too, so this seems to be a Linux kernel-specific issue.
Any insights or suggestions you might have would be greatly appreciated!
Thanks a lot for your help.
The symptoms sound awfully similar to a situation described in NXP document AH1704, chapter 6.1.13.3. I can't disclose anything from its contents here, since it is not a public document, requiring, AFAIK, sign-in.
But there have been workarounds implemented in other drivers for this particular issue, used as DSA masters for this switch. For example commit 4fa6c976158b ("net: stmmac: dwmac-imx: pause the TXC clock in fixed-link"). If you get access to the NXP document, maybe you can confirm that the circumstances leading to the issue are the same, and you are able to implement a similar workaround for this NIC (also stmmac driver, I believe?!).
Hope this helps.
PATCH 2/7 net: stmmac: gmac4: drop FPE implementation for refactoring
In reply to Furong XuThe FPE support for gmac4 is complete, still drop it temporarily. Once FPE implementation is refactored, gmac4 support will be added.
--- .../net/ethernet/stmicro/stmmac/dwmac4_core.c | 6 -- drivers/net/ethernet/stmicro/stmmac/dwmac5.c | 66 ------------------- drivers/net/ethernet/stmicro/stmmac/dwmac5.h | 16 ----- 3 files changed, 88 deletions(-)
drivers/net/ethernet/stmicro/stmmac/dwmac4_core.c +0 -6
@@ -1265,9 +1265,6 @@ const struct stmmac_ops dwmac410_ops = { .set_arp_offload = dwmac4_set_arp_offload, .config_l3_filter = dwmac4_config_l3_filter, .config_l4_filter = dwmac4_config_l4_filter, - .fpe_configure = dwmac5_fpe_configure, - .fpe_send_mpacket = dwmac5_fpe_send_mpacket, - .fpe_irq_status = dwmac5_fpe_irq_status, .add_hw_vlan_rx_fltr = dwmac4_add_hw_vlan_rx_fltr, .del_hw_vlan_rx_fltr = dwmac4_del_hw_vlan_rx_fltr, .restore_hw_vlan_rx_fltr = dwmac4_restore_hw_vlan_rx_fltr,
@@ -1317,9 +1314,6 @@ const struct stmmac_ops dwmac510_ops = { .set_arp_offload = dwmac4_set_arp_offload, .config_l3_filter = dwmac4_config_l3_filter, .config_l4_filter = dwmac4_config_l4_filter, - .fpe_configure = dwmac5_fpe_configure, - .fpe_send_mpacket = dwmac5_fpe_send_mpacket, - .fpe_irq_status = dwmac5_fpe_irq_status, .add_hw_vlan_rx_fltr = dwmac4_add_hw_vlan_rx_fltr, .del_hw_vlan_rx_fltr = dwmac4_del_hw_vlan_rx_fltr, .restore_hw_vlan_rx_fltr = dwmac4_restore_hw_vlan_rx_fltr,
drivers/net/ethernet/stmicro/stmmac/dwmac5.c +0 -66
69 lines not on this page · raw message
drivers/net/ethernet/stmicro/stmmac/dwmac5.h +0 -16
@@ -11,15 +11,6 @@#define PRTYEN BIT(1)#define TMOUTEN BIT(0) -#define MAC_FPE_CTRL_STS 0x00000234 -#define TRSP BIT(19) -#define TVER BIT(18) -#define RRSP BIT(17) -#define RVER BIT(16) -#define SRSP BIT(2) -#define SVER BIT(1) -#define EFPE BIT(0) -#define MAC_PPS_CONTROL 0x00000b70#define PPS_MAXIDX (x) ((((x) + 1) * 8) - 1)#define PPS_MINIDX (x) ((x) * 8)
@@ -102,12 +93,5 @@ int dwmac5_rxp_config(void __iomem *ioaddr, struct stmmac_tc_entry *entries,int dwmac5_flex_pps_config (void __iomem *ioaddr,int index,struct stmmac_pps_cfg *cfg,bool enable,u32 sub_second_inc,u32 systime_flags); -void dwmac5_fpe_configure (void __iomem *ioaddr,struct stmmac_fpe_cfg *cfg, -u32 num_txq,u32 num_rxq, -bool enable); -void dwmac5_fpe_send_mpacket (void __iomem *ioaddr, -struct stmmac_fpe_cfg *cfg, -enum stmmac_mpacket_type type); -int dwmac5_fpe_irq_status (void __iomem *ioaddr,struct net_device *dev);#endif /* __DWMAC5_H__ */
Signature · 1 line
2.34.1
Andrew Lunn
NAKRe: [PATCH net-next v1 2/7] net: stmmac: gmac4: drop FPE implementation for refactoring
Quoted 2 lines · Furong Xu
The FPE support for gmac4 is complete, still drop it temporarily. Once FPE implementation is refactored, gmac4 support will be added.
So you say this implementation does work. So sorry, no.
NACK.
What we want is lots of small patches which are obviously correct. If this code is correct, you could simply move it to a shared location. Code which disappears from one file and reappears in another file, no other changes, is obviously correct. You can make this clear in the commit message: Moving code into a shared location. No functional changes intended.
Once moved, you can then do refactoring changes, which when combined with a good commit message should be obviously correct.
In linux, you do not throw code away and replace it with a new implementation. You step by step transform it.
Andrew
---
pw-bot: cr
PATCH 3/7 net: stmmac: refactor Frame Preemption(FPE) implementation
In reply to Furong XuRefactor FPE implementation into a separate FPE module. Interfaces only, implementations for gmac4 and xgmac will follow.
--- drivers/net/ethernet/stmicro/stmmac/Makefile | 2 +- drivers/net/ethernet/stmicro/stmmac/common.h | 1 + drivers/net/ethernet/stmicro/stmmac/hwif.c | 3 ++ drivers/net/ethernet/stmicro/stmmac/hwif.h | 28 ++++++++++--------- .../net/ethernet/stmicro/stmmac/stmmac_fpe.c | 9 ++++++ .../net/ethernet/stmicro/stmmac/stmmac_fpe.h | 13 +++++++++ 6 files changed, 42 insertions(+), 14 deletions(-) create mode 100644 drivers/net/ethernet/stmicro/stmmac/stmmac_fpe.c create mode 100644 drivers/net/ethernet/stmicro/stmmac/stmmac_fpe.h
drivers/net/ethernet/stmicro/stmmac/Makefile +1 -1
@@ -6,7 +6,7 @@ stmmac-objs:= stmmac_main.o stmmac_ethtool.o stmmac_mdio.o ring_mode.o \ mmc_core.o stmmac_hwtstamp.o stmmac_ptp.o dwmac4_descs.o \ dwmac4_dma.o dwmac4_lib.o dwmac4_core.o dwmac5.o hwif.o \ stmmac_tc.o dwxgmac2_core.o dwxgmac2_dma.o dwxgmac2_descs.o \ - stmmac_xdp.o stmmac_est.o \ + stmmac_xdp.o stmmac_est.o stmmac_fpe.o \ $(stmmac-y) stmmac-$(CONFIG_STMMAC_SELFTESTS) += stmmac_selftests.o
drivers/net/ethernet/stmicro/stmmac/common.h +1 -0
@@ -591,6 +591,7 @@ struct mac_device_info {const struct stmmac_tc_ops *tc;const struct stmmac_mmc_ops *mmc;const struct stmmac_est_ops *est; +const struct stmmac_fpe_ops *fpe;struct dw_xpcs *xpcs;struct phylink_pcs *phylink_pcs;struct mii_regs mii;/* MII register Addresses */
drivers/net/ethernet/stmicro/stmmac/hwif.c +3 -0
@@ -8,6 +8,7 @@#include "stmmac.h" #include "stmmac_ptp.h" #include "stmmac_est.h" +#include "stmmac_fpe.h" static u32 stmmac_get_id (struct stmmac_priv *priv,u32 id_reg) {
@@ -116,6 +117,7 @@ static const struct stmmac_hwif_entry {const void *tc;const void *mmc;const void *est; +const void *fpe;int (*setup)(struct stmmac_priv *priv);int (*quirks)(struct stmmac_priv *priv); } stmmac_hw[] = {
@@ -351,6 +353,7 @@ int stmmac_hwif_init(struct stmmac_priv *priv) mac->tc = mac->tc ? : entry->tc; mac->mmc = mac->mmc ? : entry->mmc; mac->est = mac->est ? : entry->est; + mac->fpe = mac->fpe ? : entry->fpe; priv->hw = mac; priv->ptpaddr = priv->ioaddr + entry->regs.ptp_off;
drivers/net/ethernet/stmicro/stmmac/hwif.h +15 -13
@@ -418,13 +418,6 @@ struct stmmac_ops { bool en, bool udp, bool sa, bool inv, u32 match);void (*set_arp_offload)(struct mac_device_info *hw,bool en,u32 addr); -void (*fpe_configure)(void __iomem *ioaddr,struct stmmac_fpe_cfg *cfg, -u32 num_txq,u32 num_rxq, -bool enable); -void (*fpe_send_mpacket)(void __iomem *ioaddr, -struct stmmac_fpe_cfg *cfg, -enum stmmac_mpacket_type type); -int (*fpe_irq_status)(void __iomem *ioaddr,struct net_device *dev); }; #define stmmac_core_init(__priv, __args...) \
@@ -523,12 +516,6 @@ struct stmmac_ops { stmmac_do_callback(__priv, mac, config_l4_filter, __args) #define stmmac_set_arp_offload(__priv, __args...) \ stmmac_do_void_callback(__priv, mac, set_arp_offload, __args) -#define stmmac_fpe_configure(__priv, __args...) \ - stmmac_do_void_callback(__priv, mac, fpe_configure, __args) -#define stmmac_fpe_send_mpacket(__priv, __args...) \ - stmmac_do_void_callback(__priv, mac, fpe_send_mpacket, __args) -#define stmmac_fpe_irq_status(__priv, __args...) \ - stmmac_do_callback(__priv, mac, fpe_irq_status, __args)/* PTP and HW Timer helpers */ struct stmmac_hwtimestamp {
@@ -660,6 +647,21 @@ struct stmmac_est_ops { #define stmmac_est_irq_status(__priv, __args...) \ stmmac_do_void_callback(__priv, est, irq_status, __args) +struct stmmac_fpe_ops { +void (*configure)(void __iomem *ioaddr,struct stmmac_fpe_cfg *cfg, +u32 num_txq,u32 num_rxq,bool enable); +int (*irq_status)(void __iomem *ioaddr,struct net_device *dev); +void (*send_mpacket)(void __iomem *ioaddr,struct stmmac_fpe_cfg *cfg, +enum stmmac_mpacket_type type); +}; + +#define stmmac_fpe_configure(__priv, __args...) \ + stmmac_do_void_callback(__priv, fpe, configure, __args) +#define stmmac_fpe_irq_status(__priv, __args...) \ + stmmac_do_callback(__priv, fpe, irq_status, __args) +#define stmmac_fpe_send_mpacket(__priv, __args...) \ + stmmac_do_void_callback(__priv, fpe, send_mpacket, __args) +struct stmmac_regs_off {u32 ptp_off;u32 mmc_off;
drivers/net/ethernet/stmicro/stmmac/stmmac_fpe.c new file +9 -0
@@ -0,0 +1,9 @@ +// SPDX-License-Identifier: GPL-2.0-only +/* +* Copyright (C) 2024 Furong Xu <[email protected]> +* stmmac FPE(802.3 Qbu) handling +*/ + +#include "stmmac.h" +#include "stmmac_fpe.h" +
drivers/net/ethernet/stmicro/stmmac/stmmac_fpe.h new file +13 -0
@@ -0,0 +1,13 @@ +/* SPDX-License-Identifier: GPL-2.0-only */ +/* +* Copyright (C) 2024 Furong Xu <[email protected]> +* stmmac FPE(802.3 Qbu) handling +*/ + +#define FPE_CTRL_STS_TRSP BIT(19) +#define FPE_CTRL_STS_TVER BIT(18) +#define FPE_CTRL_STS_RRSP BIT(17) +#define FPE_CTRL_STS_RVER BIT(16) +#define FPE_CTRL_STS_SRSP BIT(2) +#define FPE_CTRL_STS_SVER BIT(1) +#define FPE_CTRL_STS_EFPE BIT(0)
Signature · 1 line
2.34.1
PATCH 4/7 net: stmmac: gmac4: complete FPE support
In reply to Furong XuIntroduce dwmac4_fpe_ops to complete the FPE implementation for DWMAC4
--- drivers/net/ethernet/stmicro/stmmac/hwif.c | 2 + drivers/net/ethernet/stmicro/stmmac/hwif.h | 1 + .../net/ethernet/stmicro/stmmac/stmmac_fpe.c | 85 +++++++++++++++++++ .../net/ethernet/stmicro/stmmac/stmmac_fpe.h | 2 + 4 files changed, 90 insertions(+)
drivers/net/ethernet/stmicro/stmmac/hwif.c +2 -0
@@ -216,6 +216,7 @@ static const struct stmmac_hwif_entry { .tc = &dwmac510_tc_ops, .mmc = &dwmac_mmc_ops, .est = &dwmac510_est_ops, + .fpe = &dwmac4_fpe_ops, .setup = dwmac4_setup, .quirks = NULL, }, {
@@ -236,6 +237,7 @@ static const struct stmmac_hwif_entry { .tc = &dwmac510_tc_ops, .mmc = &dwmac_mmc_ops, .est = &dwmac510_est_ops, + .fpe = &dwmac4_fpe_ops, .setup = dwmac4_setup, .quirks = NULL, }, {
drivers/net/ethernet/stmicro/stmmac/hwif.h +1 -0
@@ -685,6 +685,7 @@ extern const struct stmmac_desc_ops dwxgmac210_desc_ops;extern const struct stmmac_mmc_ops dwmac_mmc_ops;extern const struct stmmac_mmc_ops dwxgmac_mmc_ops;extern const struct stmmac_est_ops dwmac510_est_ops; +extern const struct stmmac_fpe_ops dwmac4_fpe_ops;#define GMAC_VERSION 0x00000020/* GMAC CORE Version */ #define GMAC4_VERSION 0x00000110/* GMAC4+ CORE Version */
drivers/net/ethernet/stmicro/stmmac/stmmac_fpe.c +85 -0
89 lines not on this page · raw message
drivers/net/ethernet/stmicro/stmmac/stmmac_fpe.h +2 -0
@@ -4,6 +4,8 @@* stmmac FPE(802.3 Qbu) handling */ +#define FPE_CTRL_STS_GMAC4_OFFSET 0x00000234 +#define FPE_CTRL_STS_TRSP BIT(19)#define FPE_CTRL_STS_TVER BIT(18)#define FPE_CTRL_STS_RRSP BIT(17)
Signature · 1 line
2.34.1
PATCH 5/7 net: stmmac: xgmac: rename XGMAC_RQ to XGMAC_FPRQ
In reply to Furong XuSynopsys XGMAC Databook defines MAC_RxQ_Ctrl1 register:
RQ: Frame Preemption Residue Queue
XGMAC_FPRQ is more readable and more consistent with GMAC4.
--- drivers/net/ethernet/stmicro/stmmac/dwxgmac2.h | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
drivers/net/ethernet/stmicro/stmmac/dwxgmac2.h +2 -2
@@ -84,8 +84,8 @@#define XGMAC_MCBCQEN BIT(15)#define XGMAC_MCBCQ GENMASK(11, 8)#define XGMAC_MCBCQ_SHIFT 8 -#define XGMAC_RQ GENMASK(7, 4) -#define XGMAC_RQ_SHIFT 4 +#define XGMAC_FPRQ GENMASK(7, 4) +#define XGMAC_FPRQ_SHIFT 4#define XGMAC_UPQ GENMASK(3, 0)#define XGMAC_UPQ_SHIFT 0#define XGMAC_RXQ_CTRL2 0x000000a8
Signature · 1 line
2.34.1
PATCH 6/7 net: stmmac: xgmac: complete FPE support
In reply to Furong XuFPE implementation for DWMAC4 and DWXGMAC differs only for:
1) Offset address of MAC_FPE_CTRL_STS
2) FPRQ(Frame Preemption Residue Queue) field in MAC_RxQ_Ctrl1
Introduce dwxgmac_fpe_ops to complete the FPE implementation for DWXGMAC.
--- drivers/net/ethernet/stmicro/stmmac/hwif.c | 2 + drivers/net/ethernet/stmicro/stmmac/hwif.h | 1 + .../net/ethernet/stmicro/stmmac/stmmac_fpe.c | 37 +++++++++++++++++++ .../net/ethernet/stmicro/stmmac/stmmac_fpe.h | 1 + 4 files changed, 41 insertions(+)
drivers/net/ethernet/stmicro/stmmac/hwif.c +2 -0
@@ -259,6 +259,7 @@ static const struct stmmac_hwif_entry { .tc = &dwmac510_tc_ops, .mmc = &dwxgmac_mmc_ops, .est = &dwmac510_est_ops, + .fpe = &dwxgmac_fpe_ops, .setup = dwxgmac2_setup, .quirks = NULL, }, {
@@ -280,6 +281,7 @@ static const struct stmmac_hwif_entry { .tc = &dwmac510_tc_ops, .mmc = &dwxgmac_mmc_ops, .est = &dwmac510_est_ops, + .fpe = &dwxgmac_fpe_ops, .setup = dwxlgmac2_setup, .quirks = stmmac_dwxlgmac_quirks, },
drivers/net/ethernet/stmicro/stmmac/hwif.h +1 -0
@@ -686,6 +686,7 @@ extern const struct stmmac_mmc_ops dwmac_mmc_ops;extern const struct stmmac_mmc_ops dwxgmac_mmc_ops;extern const struct stmmac_est_ops dwmac510_est_ops;extern const struct stmmac_fpe_ops dwmac4_fpe_ops; +extern const struct stmmac_fpe_ops dwxgmac_fpe_ops;#define GMAC_VERSION 0x00000020/* GMAC CORE Version */ #define GMAC4_VERSION 0x00000110/* GMAC4+ CORE Version */
drivers/net/ethernet/stmicro/stmmac/stmmac_fpe.c +37 -0
@@ -7,6 +7,7 @@#include "stmmac.h" #include "stmmac_fpe.h" #include "dwmac4.h" +#include "dwxgmac2.h" static int __fpe_irq_status (void __iomem *ioaddr,struct net_device *dev) {
@@ -92,3 +93,39 @@ const struct stmmac_fpe_ops dwmac4_fpe_ops = { .irq_status = dwmac4_fpe_irq_status, .send_mpacket = dwmac4_fpe_send_mpacket, }; + +static void dwxgmac_fpe_configure (void __iomem *ioaddr, +struct stmmac_fpe_cfg *cfg, +u32 num_txq,u32 num_rxq,bool enable) +{ +u32 value; + +if (enable) { + cfg->fpe_csr =FPE_CTRL_STS_EFPE ; + value =readl (ioaddr +XGMAC_RXQ_CTRL1 ); + value &= ~XGMAC_FPRQ ; + value |= (num_rxq -1 ) <<XGMAC_FPRQ_SHIFT ; +writel (value, ioaddr +XGMAC_RXQ_CTRL1 ); + }else { + cfg->fpe_csr =0 ; + } + +writel (cfg->fpe_csr, ioaddr +FPE_CTRL_STS_XGMAC_OFFSET ); +} + +static int dwxgmac_fpe_irq_status (void __iomem *ioaddr,struct net_device *dev) +{ +return __fpe_irq_status (ioaddr +FPE_CTRL_STS_XGMAC_OFFSET , dev); +} + +static void dwxgmac_fpe_send_mpacket (void __iomem *ioaddr,struct stmmac_fpe_cfg *cfg, +enum stmmac_mpacket_type type) +{ +__fpe_send_mpacket (ioaddr +FPE_CTRL_STS_XGMAC_OFFSET , cfg, type); +} + +const struct stmmac_fpe_ops dwxgmac_fpe_ops = { + .configure = dwxgmac_fpe_configure, + .irq_status = dwxgmac_fpe_irq_status, + .send_mpacket = dwxgmac_fpe_send_mpacket, +};
drivers/net/ethernet/stmicro/stmmac/stmmac_fpe.h +1 -0
@@ -5,6 +5,7 @@*/ #define FPE_CTRL_STS_GMAC4_OFFSET 0x00000234 +#define FPE_CTRL_STS_XGMAC_OFFSET 0x00000280#define FPE_CTRL_STS_TRSP BIT(19)#define FPE_CTRL_STS_TVER BIT(18)
Signature · 1 line
2.34.1
PATCH 7/7 net: stmmac: xgmac: enable Frame Preemption Interrupt by default
In reply to Furong XuFrame Preemption Interrupt is required to finish FPE handshake.
XGMAC_FPEIE is read-only reserved if FPE is not supported by HW. There is no harm that we always set XGMAC_FPEIE bit.
--- drivers/net/ethernet/stmicro/stmmac/dwxgmac2.h | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
drivers/net/ethernet/stmicro/stmmac/dwxgmac2.h +2 -1
@@ -96,10 +96,11 @@#define XGMAC_LPIIS BIT(5)#define XGMAC_PMTIS BIT(4)#define XGMAC_INT_EN 0x000000b4 +#define XGMAC_FPEIE BIT(15)#define XGMAC_TSIE BIT(12)#define XGMAC_LPIIE BIT(5)#define XGMAC_PMTIE BIT(4) -#define XGMAC_INT_DEFAULT_EN (XGMAC_LPIIE | XGMAC_PMTIE) +#define XGMAC_INT_DEFAULT_EN (XGMAC_FPEIE | XGMAC_LPIIE | XGMAC_PMTIE)#define XGMAC_Qx_TX_FLOW_CTRL (x) (0x00000070 + (x) * 4)#define XGMAC_PT GENMASK(31, 16)#define XGMAC_PT_SHIFT 16
Signature · 1 line
2.34.1
Re: [PATCH net-next v1 7/7] net: stmmac: xgmac: enable Frame Preemption Interrupt by default
Quoted 4 lines · Furong Xu
Frame Preemption Interrupt is required to finish FPE handshake.
XGMAC_FPEIEis read-only reserved if FPE is not supported by HW. There is no harm that we always setXGMAC_FPEIEbit.
This is better, it explains what is going on, why the change is being made. But when i see this, i think about the interrupt handler. You don't just enable a new interrupt, you also need to handle the interrupt. Where is that handler code?
The commit message is the place you try to answer the questions reviewers are going to ask. So if the interrupt handler already looks for this interrupt cause and handles it, add a statement to the commit message explaining it.
Andrew