Re: stmmac driver timeout issue
On Fri, Mar 12, 2021 at 10:33:06AM -0800, Florian Fainelli wrote: > On 3/11/21 4:04 AM, Joakim Zhang wrote: > > I have a question about PHY framework, please point me if something I > > misunderstanding. > > There are many scenarios from PHY framework would trigger auto-nego, such > > as switch from power down to normal operation, but it never polling the ack > > of auto-nego (phy_poll_aneg_done), is there any special reasons? Is it > > possible and reasonable for MAC controller driver to poll this ack, if yes, > > at least we have a stable RXC at that time. > > Adding Heiner and Russell as well. Usually you do not want, or rather > cannot know whether auto-negotiation will ever succeed, so waiting for > it could essentially hog your system for some fairly indefinite amount > of time. I think the question being asked is essentially whether checking the link status bit (1.2) without checking the aneg complete bit (1.5) is sufficient. Reading 802.3, it seems to be defined that if autonegotiation is in use, the link shall be reported as down until autonegotiation has completed - which is logical. The link can only be up if a valid data path capable of transferring data has been established, which implies that autonegotiation must have completed. However, note that when coming out of power down, there is no guarantee that there is anything connected to the other side of the media, and thus there is no guarantee that autonegotiation will complete. Waiting for autonegotiation to complete in this case would not be feasible. -- RMK's Patch system: https://www.armlinux.org.uk/developer/patches/ FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!
Re: stmmac driver timeout issue
On 3/11/21 4:04 AM, Joakim Zhang wrote: > >> -Original Message- >> From: Florian Fainelli >> Sent: 2021年3月9日 1:57 >> To: Joakim Zhang ; Jakub Kicinski >> ; Andrew Lunn >> Cc: netdev@vger.kernel.org >> Subject: Re: stmmac driver timeout issue >> >> On 3/8/21 4:45 AM, Joakim Zhang wrote: >>> >>> Hi Florian, Andrew, >>> >>> Thanks for your help, after debug, It seems related to PHY(RTL8211FDI). It >> stop output RXC clock for dozens to hundreds milliseconds during >> auto-negotiation, and there is no such issue with AR8031. >>> When do ifup/ifdown test or system suspend/resume test, it will >>> suspend then resume phy which do power down and then change to normal >>> operation.(switch from power to normal operation) >>> >>> There is a note in RTL8211FDI datasheet: >>> Note 2: When the RTL8211F(I)/RTL8211FD(I) is switched from power to >> normal operation, a software reset and restart auto-negotiation is performed, >> even if bits Reset(0.15) and Restart_AN(0.9) are not set by the users. >>> >>> Form above note, it will trigger auto-negotiation when do ifup/ifdown test >>> or >> system suspend/resume, so we will meet RXC clock is stop issue on >> RTL8211FDI. My question is that, Is this a normal behavior, all PHYs will >> perform this behavior? And Linux PHY frame work can handle this case, there >> is >> no config_init after resume, will the config be reset? >> >> I do not have experience with Realtek PHYs however what you describe does >> not sound completely far off from what Broadcom PHYs would do when >> auto-power down is enabled and when the link is dropped either because the >> PHY was powered down or auto-negotiation was restarted which then leads to >> the RXC/TXC clocks being disabled. >> >> For RGMII that connects to an actual PHY you can probably use the same >> technique that Doug had implemented for GENET whereby you put it in isolate >> mode and it maintains its RXC while you do the reset. The problem is that >> this >> really only work for an RGMII connection and a PHY, if you connect to a MAC >> you could create contention on the pins. I am afraid there is no fool proof >> situation but maybe you can find a way to configure the STMMAC so as to route >> another internal clock that it generates as a valid RXC just for the time you >> need it? >> >> With respect to your original problem, looks like it may be fixed with: >> >> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit.kern >> el.org%2Fnetdev%2Fnet%2Fc%2F9a7b3950c7e1&data=04%7C01%7Cqian >> gqing.zhang%40nxp.com%7Cb7e83671b0184471020708d8e25b8ca6%7C686ea >> 1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C637508230113442096%7CUnk >> nown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1 >> haWwiLCJXVCI6Mn0%3D%7C1000&sdata=LPY4fazuJFAOanncuGll1jGK8W >> bxiR2iZ5KfuuaAk98%3D&reserved=0 >> >> or maybe this only works on the specific Intel platform? > > Thanks Florian, I also noticed that patch, but that should work for driver > remove. The key is RXC not stable when auto-nego at my side. > > I have a question about PHY framework, please point me if something I > misunderstanding. > There are many scenarios from PHY framework would trigger auto-nego, such as > switch from power down to normal operation, but it never polling the ack of > auto-nego (phy_poll_aneg_done), is there any special reasons? Is it possible > and reasonable for MAC controller driver to poll this ack, if yes, at least > we have a stable RXC at that time. Adding Heiner and Russell as well. Usually you do not want, or rather cannot know whether auto-negotiation will ever succeed, so waiting for it could essentially hog your system for some fairly indefinite amount of time. With respect to your Realtek PHY is there no way you can force it to output the 125MHz RX clock towards the MAC while you perform the MAC initialization? -- Florian
RE: stmmac driver timeout issue
> -Original Message- > From: Florian Fainelli > Sent: 2021年3月9日 1:57 > To: Joakim Zhang ; Jakub Kicinski > ; Andrew Lunn > Cc: netdev@vger.kernel.org > Subject: Re: stmmac driver timeout issue > > On 3/8/21 4:45 AM, Joakim Zhang wrote: > > > > Hi Florian, Andrew, > > > > Thanks for your help, after debug, It seems related to PHY(RTL8211FDI). It > stop output RXC clock for dozens to hundreds milliseconds during > auto-negotiation, and there is no such issue with AR8031. > > When do ifup/ifdown test or system suspend/resume test, it will > > suspend then resume phy which do power down and then change to normal > > operation.(switch from power to normal operation) > > > > There is a note in RTL8211FDI datasheet: > > Note 2: When the RTL8211F(I)/RTL8211FD(I) is switched from power to > normal operation, a software reset and restart auto-negotiation is performed, > even if bits Reset(0.15) and Restart_AN(0.9) are not set by the users. > > > > Form above note, it will trigger auto-negotiation when do ifup/ifdown test > > or > system suspend/resume, so we will meet RXC clock is stop issue on > RTL8211FDI. My question is that, Is this a normal behavior, all PHYs will > perform this behavior? And Linux PHY frame work can handle this case, there is > no config_init after resume, will the config be reset? > > I do not have experience with Realtek PHYs however what you describe does > not sound completely far off from what Broadcom PHYs would do when > auto-power down is enabled and when the link is dropped either because the > PHY was powered down or auto-negotiation was restarted which then leads to > the RXC/TXC clocks being disabled. > > For RGMII that connects to an actual PHY you can probably use the same > technique that Doug had implemented for GENET whereby you put it in isolate > mode and it maintains its RXC while you do the reset. The problem is that this > really only work for an RGMII connection and a PHY, if you connect to a MAC > you could create contention on the pins. I am afraid there is no fool proof > situation but maybe you can find a way to configure the STMMAC so as to route > another internal clock that it generates as a valid RXC just for the time you > need it? > > With respect to your original problem, looks like it may be fixed with: > > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit.kern > el.org%2Fnetdev%2Fnet%2Fc%2F9a7b3950c7e1&data=04%7C01%7Cqian > gqing.zhang%40nxp.com%7Cb7e83671b0184471020708d8e25b8ca6%7C686ea > 1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C637508230113442096%7CUnk > nown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1 > haWwiLCJXVCI6Mn0%3D%7C1000&sdata=LPY4fazuJFAOanncuGll1jGK8W > bxiR2iZ5KfuuaAk98%3D&reserved=0 > > or maybe this only works on the specific Intel platform? Thanks Florian, I also noticed that patch, but that should work for driver remove. The key is RXC not stable when auto-nego at my side. I have a question about PHY framework, please point me if something I misunderstanding. There are many scenarios from PHY framework would trigger auto-nego, such as switch from power down to normal operation, but it never polling the ack of auto-nego (phy_poll_aneg_done), is there any special reasons? Is it possible and reasonable for MAC controller driver to poll this ack, if yes, at least we have a stable RXC at that time. Best Regards, Joakim Zhang > -- > Florian
Re: stmmac driver timeout issue
On 3/8/21 4:45 AM, Joakim Zhang wrote: > > Hi Florian, Andrew, > > Thanks for your help, after debug, It seems related to PHY(RTL8211FDI). It > stop output RXC clock for dozens to hundreds milliseconds during > auto-negotiation, and there is no such issue with AR8031. > When do ifup/ifdown test or system suspend/resume test, it will suspend then > resume phy which do power down and then change to normal operation.(switch > from power to normal operation) > > There is a note in RTL8211FDI datasheet: > Note 2: When the RTL8211F(I)/RTL8211FD(I) is switched from power to normal > operation, a software reset and restart auto-negotiation is performed, even > if bits Reset(0.15) and Restart_AN(0.9) are not set by the users. > > Form above note, it will trigger auto-negotiation when do ifup/ifdown test or > system suspend/resume, so we will meet RXC clock is stop issue on RTL8211FDI. > My question is that, Is this a normal behavior, all PHYs will perform this > behavior? And Linux PHY frame work can handle this case, there is no > config_init after resume, will the config be reset? I do not have experience with Realtek PHYs however what you describe does not sound completely far off from what Broadcom PHYs would do when auto-power down is enabled and when the link is dropped either because the PHY was powered down or auto-negotiation was restarted which then leads to the RXC/TXC clocks being disabled. For RGMII that connects to an actual PHY you can probably use the same technique that Doug had implemented for GENET whereby you put it in isolate mode and it maintains its RXC while you do the reset. The problem is that this really only work for an RGMII connection and a PHY, if you connect to a MAC you could create contention on the pins. I am afraid there is no fool proof situation but maybe you can find a way to configure the STMMAC so as to route another internal clock that it generates as a valid RXC just for the time you need it? With respect to your original problem, looks like it may be fixed with: https://git.kernel.org/netdev/net/c/9a7b3950c7e1 or maybe this only works on the specific Intel platform? -- Florian
RE: stmmac driver timeout issue
Hi Florian, Andrew, Thanks for your help, after debug, It seems related to PHY(RTL8211FDI). It stop output RXC clock for dozens to hundreds milliseconds during auto-negotiation, and there is no such issue with AR8031. When do ifup/ifdown test or system suspend/resume test, it will suspend then resume phy which do power down and then change to normal operation.(switch from power to normal operation) There is a note in RTL8211FDI datasheet: Note 2: When the RTL8211F(I)/RTL8211FD(I) is switched from power to normal operation, a software reset and restart auto-negotiation is performed, even if bits Reset(0.15) and Restart_AN(0.9) are not set by the users. Form above note, it will trigger auto-negotiation when do ifup/ifdown test or system suspend/resume, so we will meet RXC clock is stop issue on RTL8211FDI. My question is that, Is this a normal behavior, all PHYs will perform this behavior? And Linux PHY frame work can handle this case, there is no config_init after resume, will the config be reset? Best Regards, Joakim Zhang > -Original Message- > From: Florian Fainelli > Sent: 2021年3月5日 8:28 > To: Joakim Zhang ; Jakub Kicinski > ; Andrew Lunn > Cc: netdev@vger.kernel.org > Subject: Re: stmmac driver timeout issue > > On 3/4/21 5:14 AM, Joakim Zhang wrote: > > > > Hello Andrew, Hello Jakub, > > > > You may can give some suggestions based on your great networking > knowledge, thanks in advance! > > > > I found that add vlan id hw filter (stmmac_vlan_rx_add_vid) have possibility > timeout when accessing VLAN Filter registers during ifup/ifdown stress test, > and restore vlan id hw filter (stmmac_restore_hw_vlan_rx_fltr) always timeout > when access VLAN Filter registers. > > > > My hardware is i.MX8MP > (drivers/net/ethernet/stmicro/stmmac/dwmac-imx.c, RGMII interface, > RTL8211FDI-CG PHY), it needs fix mac speed(imx_dwmac_fix_speed), it > indirectly involved in phylink_link_up. After debugging, if phylink_link_up is > called later than adding vlan id hw filter, it will report timeout, so I > guess we > need fix mac speed before accessing VLAN Filter registers. Error like below: > > [ 106.389879] 8021q: adding VLAN 0 to HW filter on device eth1 > > [ 106.395644] imx-dwmac 30bf.ethernet eth1: Timeout accessing > MAC_VLAN_Tag_Filter > > [ 108.160734] imx-dwmac 30bf.ethernet eth1: Link is Up - > 100Mbps/Full - flow control rx/tx ->->-> which means accessing VLAN Filter > registers before phylink_link_up is called. > > > > Same case when system resume back, > > [ 1763.842294] imx-dwmac 30bf.ethernet eth1: configuring for > phy/rgmii-id link mode > > [ 1763.853084] imx-dwmac 30bf.ethernet eth1: No Safety Features > support found > > [ 1763.853186] imx-dwmac 30bf.ethernet eth1: Timeout accessing > MAC_VLAN_Tag_Filter > > [ 1763.873465] usb usb1: root hub lost power or was reset > > [ 1763.873469] usb usb2: root hub lost power or was reset > > [ 1764.090321] PM: resume devices took 0.248 seconds > > [ 1764.257381] OOM killer enabled. > > [ 1764.260518] Restarting tasks ... done. > > [ 1764.265229] PM: suspend exit > > === > > suspend 12 times > > === > > [ 1765.887915] imx-dwmac 30bf.ethernet eth1: Link is Up - > 100Mbps/Full - flow control rx/tx ->->-> which means accessing VLAN Filter > registers before phylink_link_up is called. > > > > My question is that some MAC controllers need RXC clock from RGMII > interface to reset DAM or access to some registers. If there is any way to > ensure phylink_link_up is invoked synchronously when we need it. I am not sure > this timeout caused by a fix mac speed is needed before accessing VLAN Filter > registers, is there ang hints, thanks a lot! We have another board i.MX8DXL > which don't need fix mac speed attach to AR8031 PHY, can't reproduce this > issue. > > Every Ethernet controller is different, but you can see that we struggled to > fix a > similar problem where we need the RXC from the PHY for the MAC to complete > its reset side reset with GENET, it took several iterations to get there: > > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit.kern > el.org%2Fpub%2Fscm%2Flinux%2Fkernel%2Fgit%2Ftorvalds%2Flinux.git%2Fco > mmit%2F%3Fid%3D88f6c8bf1aaed5039923fb4c701cab4d42176275&data > =04%7C01%7Cqiangqing.zhang%40nxp.com%7Cbe0cffc475f946efac1908d8df6 > d97f8%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C637505009093 > 274835%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2lu > MzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=Ar2K
Re: stmmac driver timeout issue
On 3/4/21 5:14 AM, Joakim Zhang wrote: > > Hello Andrew, Hello Jakub, > > You may can give some suggestions based on your great networking knowledge, > thanks in advance! > > I found that add vlan id hw filter (stmmac_vlan_rx_add_vid) have possibility > timeout when accessing VLAN Filter registers during ifup/ifdown stress test, > and restore vlan id hw filter (stmmac_restore_hw_vlan_rx_fltr) always timeout > when access VLAN Filter registers. > > My hardware is i.MX8MP (drivers/net/ethernet/stmicro/stmmac/dwmac-imx.c, > RGMII interface, RTL8211FDI-CG PHY), it needs fix mac > speed(imx_dwmac_fix_speed), it indirectly involved in phylink_link_up. After > debugging, if phylink_link_up is called later than adding vlan id hw filter, > it will report timeout, so I guess we need fix mac speed before accessing > VLAN Filter registers. Error like below: > [ 106.389879] 8021q: adding VLAN 0 to HW filter on device eth1 > [ 106.395644] imx-dwmac 30bf.ethernet eth1: Timeout accessing > MAC_VLAN_Tag_Filter > [ 108.160734] imx-dwmac 30bf.ethernet eth1: Link is Up - > 100Mbps/Full - flow control rx/tx ->->-> which means accessing VLAN Filter > registers before phylink_link_up is called. > > Same case when system resume back, > [ 1763.842294] imx-dwmac 30bf.ethernet eth1: configuring for > phy/rgmii-id link mode > [ 1763.853084] imx-dwmac 30bf.ethernet eth1: No Safety Features > support found > [ 1763.853186] imx-dwmac 30bf.ethernet eth1: Timeout accessing > MAC_VLAN_Tag_Filter > [ 1763.873465] usb usb1: root hub lost power or was reset > [ 1763.873469] usb usb2: root hub lost power or was reset > [ 1764.090321] PM: resume devices took 0.248 seconds > [ 1764.257381] OOM killer enabled. > [ 1764.260518] Restarting tasks ... done. > [ 1764.265229] PM: suspend exit > === > suspend 12 times > === > [ 1765.887915] imx-dwmac 30bf.ethernet eth1: Link is Up - > 100Mbps/Full - flow control rx/tx ->->-> which means accessing VLAN Filter > registers before phylink_link_up is called. > > My question is that some MAC controllers need RXC clock from RGMII interface > to reset DAM or access to some registers. If there is any way to ensure > phylink_link_up is invoked synchronously when we need it. I am not sure this > timeout caused by a fix mac speed is needed before accessing VLAN Filter > registers, is there ang hints, thanks a lot! We have another board i.MX8DXL > which don't need fix mac speed attach to AR8031 PHY, can't reproduce this > issue. Every Ethernet controller is different, but you can see that we struggled to fix a similar problem where we need the RXC from the PHY for the MAC to complete its reset side reset with GENET, it took several iterations to get there: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=88f6c8bf1aaed5039923fb4c701cab4d42176275 https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=612eb1c3b9e504de24136c947ed7c07bc342f3aa https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=6b6d017fccb4693767d2fcae9ef2fd05243748bb https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=3a55402c93877d291b0a612d25edb03d1b4b93ac https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=1f515486275a08a17a2c806b844cca18f7de5b34 This driver uses PHYLIB (hardware is no longer developed and will not receive updates to support different PCS), but maybe you can glean some idea on how to solve this? -- Florian
Re: stmmac driver timeout issue
On Thu, Mar 04, 2021 at 01:14:31PM +, Joakim Zhang wrote: > > Hello Andrew, Hello Jakub, > > You may can give some suggestions based on your great networking knowledge, > thanks in advance! > > I found that add vlan id hw filter (stmmac_vlan_rx_add_vid) have possibility > timeout when accessing VLAN Filter registers during ifup/ifdown stress test, > and restore vlan id hw filter (stmmac_restore_hw_vlan_rx_fltr) always timeout > when access VLAN Filter registers. > > My hardware is i.MX8MP (drivers/net/ethernet/stmicro/stmmac/dwmac-imx.c, > RGMII interface, RTL8211FDI-CG PHY), it needs fix mac > speed(imx_dwmac_fix_speed), it indirectly involved in phylink_link_up. After > debugging, if phylink_link_up is called later than adding vlan id hw filter, > it will report timeout, so I guess we need fix mac speed before accessing > VLAN Filter registers. Error like below: > [ 106.389879] 8021q: adding VLAN 0 to HW filter on device eth1 > [ 106.395644] imx-dwmac 30bf.ethernet eth1: Timeout accessing > MAC_VLAN_Tag_Filter > [ 108.160734] imx-dwmac 30bf.ethernet eth1: Link is Up - > 100Mbps/Full - flow control rx/tx ->->-> which means accessing VLAN Filter > registers before phylink_link_up is called. > > Same case when system resume back, > [ 1763.842294] imx-dwmac 30bf.ethernet eth1: configuring for > phy/rgmii-id link mode > [ 1763.853084] imx-dwmac 30bf.ethernet eth1: No Safety Features > support found > [ 1763.853186] imx-dwmac 30bf.ethernet eth1: Timeout accessing > MAC_VLAN_Tag_Filter > [ 1763.873465] usb usb1: root hub lost power or was reset > [ 1763.873469] usb usb2: root hub lost power or was reset > [ 1764.090321] PM: resume devices took 0.248 seconds > [ 1764.257381] OOM killer enabled. > [ 1764.260518] Restarting tasks ... done. > [ 1764.265229] PM: suspend exit > === > suspend 12 times > === > [ 1765.887915] imx-dwmac 30bf.ethernet eth1: Link is Up - > 100Mbps/Full - flow control rx/tx ->->-> which means accessing VLAN Filter > registers before phylink_link_up is called. > > My question is that some MAC controllers need RXC clock from RGMII interface > to reset DAM or access to some registers. There are some controllers which need the PHY clock. And some PHYs can give you some control over the clock. e.g. there are DT properties like "ti,clk-output-sel", "qca,clk-out-frequency". You probably want to look at the PHY datasheet and see what you can control. It might be possible to make it tick all the time. It has also been suggested that the PHY could implement a clk provider, which a MAC driver to clk_prepare_enable() when it needs it. Andrew
stmmac driver timeout issue
Hello Andrew, Hello Jakub, You may can give some suggestions based on your great networking knowledge, thanks in advance! I found that add vlan id hw filter (stmmac_vlan_rx_add_vid) have possibility timeout when accessing VLAN Filter registers during ifup/ifdown stress test, and restore vlan id hw filter (stmmac_restore_hw_vlan_rx_fltr) always timeout when access VLAN Filter registers. My hardware is i.MX8MP (drivers/net/ethernet/stmicro/stmmac/dwmac-imx.c, RGMII interface, RTL8211FDI-CG PHY), it needs fix mac speed(imx_dwmac_fix_speed), it indirectly involved in phylink_link_up. After debugging, if phylink_link_up is called later than adding vlan id hw filter, it will report timeout, so I guess we need fix mac speed before accessing VLAN Filter registers. Error like below: [ 106.389879] 8021q: adding VLAN 0 to HW filter on device eth1 [ 106.395644] imx-dwmac 30bf.ethernet eth1: Timeout accessing MAC_VLAN_Tag_Filter [ 108.160734] imx-dwmac 30bf.ethernet eth1: Link is Up - 100Mbps/Full - flow control rx/tx ->->-> which means accessing VLAN Filter registers before phylink_link_up is called. Same case when system resume back, [ 1763.842294] imx-dwmac 30bf.ethernet eth1: configuring for phy/rgmii-id link mode [ 1763.853084] imx-dwmac 30bf.ethernet eth1: No Safety Features support found [ 1763.853186] imx-dwmac 30bf.ethernet eth1: Timeout accessing MAC_VLAN_Tag_Filter [ 1763.873465] usb usb1: root hub lost power or was reset [ 1763.873469] usb usb2: root hub lost power or was reset [ 1764.090321] PM: resume devices took 0.248 seconds [ 1764.257381] OOM killer enabled. [ 1764.260518] Restarting tasks ... done. [ 1764.265229] PM: suspend exit === suspend 12 times === [ 1765.887915] imx-dwmac 30bf.ethernet eth1: Link is Up - 100Mbps/Full - flow control rx/tx ->->-> which means accessing VLAN Filter registers before phylink_link_up is called. My question is that some MAC controllers need RXC clock from RGMII interface to reset DAM or access to some registers. If there is any way to ensure phylink_link_up is invoked synchronously when we need it. I am not sure this timeout caused by a fix mac speed is needed before accessing VLAN Filter registers, is there ang hints, thanks a lot! We have another board i.MX8DXL which don't need fix mac speed attach to AR8031 PHY, can't reproduce this issue. Best Regards, Joakim Zhang
Re: [PATCH V5 net 0/5] ethernet: fixes for stmmac driver
Hello: This series was applied to netdev/net.git (refs/heads/master): On Thu, 25 Feb 2021 17:01:09 +0800 you wrote: > Fixes for stmmac driver. > > --- > ChangeLogs: > V1->V2: > * subject prefix: ethernet: stmmac: -> net: stmmac: > * use dma_addr_t instead of unsigned int for physical address > * use cpu_to_le32() > V2->V3: > * fix the build issue pointed out by kbuild bot. > * add error handling for stmmac_reinit_rx_buffers() function. > V3->V4: > * remove patch (net: stmmac: remove redundant null check for ptp clock), > reviewer thinks it should target net-next. > V4->V5: > * use %pad format to print dma_addr_t. > * extend dwmac4_display_ring() to support all descriptor types. > * while() -> do-while() > > [...] Here is the summary with links: - [V5,net,1/5] net: stmmac: stop each tx channel independently https://git.kernel.org/netdev/net/c/a3e860a83397 - [V5,net,2/5] net: stmmac: fix watchdog timeout during suspend/resume stress test https://git.kernel.org/netdev/net/c/c511819d138d - [V5,net,3/5] net: stmmac: fix dma physical address of descriptor when display ring https://git.kernel.org/netdev/net/c/bfaf91ca848e - [V5,net,4/5] net: stmmac: fix wrongly set buffer2 valid when sph unsupport https://git.kernel.org/netdev/net/c/396e13e11577 - [V5,net,5/5] net: stmmac: re-init rx buffers when mac resume back https://git.kernel.org/netdev/net/c/9c63faaa931e You are awesome, thank you! -- Deet-doot-dot, I am a bot. https://korg.docs.kernel.org/patchwork/pwbot.html
[PATCH V5 net 0/5] ethernet: fixes for stmmac driver
Fixes for stmmac driver. --- ChangeLogs: V1->V2: * subject prefix: ethernet: stmmac: -> net: stmmac: * use dma_addr_t instead of unsigned int for physical address * use cpu_to_le32() V2->V3: * fix the build issue pointed out by kbuild bot. * add error handling for stmmac_reinit_rx_buffers() function. V3->V4: * remove patch (net: stmmac: remove redundant null check for ptp clock), reviewer thinks it should target net-next. V4->V5: * use %pad format to print dma_addr_t. * extend dwmac4_display_ring() to support all descriptor types. * while() -> do-while() Joakim Zhang (5): net: stmmac: stop each tx channel independently net: stmmac: fix watchdog timeout during suspend/resume stress test net: stmmac: fix dma physical address of descriptor when display ring net: stmmac: fix wrongly set buffer2 valid when sph unsupport net: stmmac: re-init rx buffers when mac resume back .../ethernet/stmicro/stmmac/dwmac4_descs.c| 59 +-- .../net/ethernet/stmicro/stmmac/dwmac4_lib.c | 4 - .../ethernet/stmicro/stmmac/dwxgmac2_descs.c | 2 +- .../net/ethernet/stmicro/stmmac/enh_desc.c| 9 +- drivers/net/ethernet/stmicro/stmmac/hwif.h| 5 +- .../net/ethernet/stmicro/stmmac/norm_desc.c | 9 +- .../net/ethernet/stmicro/stmmac/stmmac_main.c | 151 +++--- 7 files changed, 194 insertions(+), 45 deletions(-) -- 2.17.1
[PATCH V4 net 0/5] ethernet: fixes for stmmac driver
Fixes for stmmac driver. --- ChangeLogs: V1->V2: * subject prefix: ethernet: stmmac: -> net: stmmac: * use dma_addr_t instead of unsigned int for physical address * use cpu_to_le32() V2->V3: * fix the build issue pointed out by kbuild bot. * add error handling for stmmac_reinit_rx_buffers() function. V3->V4: * remove patch (net: stmmac: remove redundant null check for ptp clock), reviewer thinks it should target net-next. Joakim Zhang (5): net: stmmac: stop each tx channel independently net: stmmac: fix watchdog timeout during suspend/resume stress test net: stmmac: fix dma physical address of descriptor when display ring net: stmmac: fix wrongly set buffer2 valid when sph unsupport net: stmmac: re-init rx buffers when mac resume back .../ethernet/stmicro/stmmac/dwmac4_descs.c| 16 +- .../net/ethernet/stmicro/stmmac/dwmac4_lib.c | 4 - .../ethernet/stmicro/stmmac/dwxgmac2_descs.c | 2 +- .../net/ethernet/stmicro/stmmac/enh_desc.c| 7 +- drivers/net/ethernet/stmicro/stmmac/hwif.h| 5 +- .../net/ethernet/stmicro/stmmac/norm_desc.c | 7 +- .../net/ethernet/stmicro/stmmac/stmmac_main.c | 151 +++--- 7 files changed, 152 insertions(+), 40 deletions(-) -- 2.17.1
[PATCH net-next 0/2] patch for stmmac driver
Small improvement for stmmac driver. Reviewer think patch #1 should go into net-next repo, and add patch #2. Joakim Zhang (2): net: stmmac: remove redundant null check for ptp clock net: stmmac: slightly adjust the order of the codes in stmmac_resume() .../net/ethernet/stmicro/stmmac/stmmac_main.c | 17 +++-- 1 file changed, 7 insertions(+), 10 deletions(-) -- 2.17.1
[PATCH V3 0/6] ethernet: fixes for stmmac driver
Fixes for stmmac driver. --- ChangeLogs: V1->V2: * subject prefix: ethernet: stmmac: -> net: stmmac: * use dma_addr_t instead of unsigned int for physical address * use cpu_to_le32() V2-V3: * fix the build issue pointed out by kbuild bot. * add error handling for stmmac_reinit_rx_buffers() function. Joakim Zhang (6): net: stmmac: remove redundant null check for ptp clock net: stmmac: stop each tx channel independently net: stmmac: fix watchdog timeout during suspend/resume stress test net: stmmac: fix dma physical address of descriptor when display ring net: stmmac: fix wrongly set buffer2 valid when sph unsupport net: stmmac: re-init rx buffers when mac resume back .../ethernet/stmicro/stmmac/dwmac4_descs.c| 16 +- .../net/ethernet/stmicro/stmmac/dwmac4_lib.c | 4 - .../ethernet/stmicro/stmmac/dwxgmac2_descs.c | 2 +- .../net/ethernet/stmicro/stmmac/enh_desc.c| 7 +- drivers/net/ethernet/stmicro/stmmac/hwif.h| 5 +- .../net/ethernet/stmicro/stmmac/norm_desc.c | 7 +- .../net/ethernet/stmicro/stmmac/stmmac_main.c | 154 +++--- 7 files changed, 153 insertions(+), 42 deletions(-) -- 2.17.1
Re: [PATCH V2 net 0/6] ethernet: fixes for stmmac driver
On Mon, 25 Jan 2021 04:53:00 + Joakim Zhang wrote: > Gentle Ping... Please fix the build issue pointed out by kbuild bot, ensure there is no other build problem and repost.
RE: [PATCH V2 net 0/6] ethernet: fixes for stmmac driver
Gentle Ping... Best Regards, Joakim Zhang > -Original Message- > From: Joakim Zhang > Sent: 2021年1月12日 19:34 > To: peppe.cavall...@st.com; alexandre.tor...@st.com; > joab...@synopsys.com; da...@davemloft.net; k...@kernel.org > Cc: netdev@vger.kernel.org; dl-linux-imx ; > and...@lunn.ch; f.faine...@gmail.com > Subject: [PATCH V2 net 0/6] ethernet: fixes for stmmac driver > > Fixes for stmmac driver. > > --- > ChangeLogs: > V1->V2: > * subject prefix: ethernet: stmmac: -> net: stmmac: > * use dma_addr_t instead of unsigned int for physical address > * use cpu_to_le32() > > Joakim Zhang (6): > net: stmmac: remove redundant null check for ptp clock > net: stmmac: stop each tx channel independently > net: stmmac: fix watchdog timeout during suspend/resume stress test > net: stmmac: fix dma physical address of descriptor when display ring > net: stmmac: fix wrongly set buffer2 valid when sph unsupport > net: stmmac: re-init rx buffers when mac resume back > > .../ethernet/stmicro/stmmac/dwmac4_descs.c| 16 +- > .../net/ethernet/stmicro/stmmac/dwmac4_lib.c | 4 - > .../ethernet/stmicro/stmmac/dwxgmac2_descs.c | 2 +- > .../net/ethernet/stmicro/stmmac/enh_desc.c| 7 +- > drivers/net/ethernet/stmicro/stmmac/hwif.h| 5 +- > .../net/ethernet/stmicro/stmmac/norm_desc.c | 7 +- > .../net/ethernet/stmicro/stmmac/stmmac_main.c | 140 +++--- > 7 files changed, 139 insertions(+), 42 deletions(-) > > -- > 2.17.1
[PATCH V2 net 0/6] ethernet: fixes for stmmac driver
Fixes for stmmac driver. --- ChangeLogs: V1->V2: * subject prefix: ethernet: stmmac: -> net: stmmac: * use dma_addr_t instead of unsigned int for physical address * use cpu_to_le32() Joakim Zhang (6): net: stmmac: remove redundant null check for ptp clock net: stmmac: stop each tx channel independently net: stmmac: fix watchdog timeout during suspend/resume stress test net: stmmac: fix dma physical address of descriptor when display ring net: stmmac: fix wrongly set buffer2 valid when sph unsupport net: stmmac: re-init rx buffers when mac resume back .../ethernet/stmicro/stmmac/dwmac4_descs.c| 16 +- .../net/ethernet/stmicro/stmmac/dwmac4_lib.c | 4 - .../ethernet/stmicro/stmmac/dwxgmac2_descs.c | 2 +- .../net/ethernet/stmicro/stmmac/enh_desc.c| 7 +- drivers/net/ethernet/stmicro/stmmac/hwif.h| 5 +- .../net/ethernet/stmicro/stmmac/norm_desc.c | 7 +- .../net/ethernet/stmicro/stmmac/stmmac_main.c | 140 +++--- 7 files changed, 139 insertions(+), 42 deletions(-) -- 2.17.1
[PATCH 0/6] ethernet: fixes for stmmac driver
Fixes for stmmac driver. Joakim Zhang (6): ethernet: stmmac: remove redundant null check for ptp clock ethernet: stmmac: stop each tx channal independently ethernet: stmmac: fix watchdog timeout during suspend/resume stress test ethernet: stmmac: fix dma physical address of descriptor when display ring ethernet: stmmac: fix wrongly set buffer2 valid when sph unsupport ethernet: stmmac: re-init rx buffers when mac resume back .../ethernet/stmicro/stmmac/dwmac4_descs.c| 14 +- .../net/ethernet/stmicro/stmmac/dwmac4_lib.c | 4 - .../ethernet/stmicro/stmmac/dwxgmac2_descs.c | 2 +- .../net/ethernet/stmicro/stmmac/enh_desc.c| 5 +- drivers/net/ethernet/stmicro/stmmac/hwif.h| 5 +- .../net/ethernet/stmicro/stmmac/norm_desc.c | 5 +- .../net/ethernet/stmicro/stmmac/stmmac_main.c | 136 +++--- 7 files changed, 134 insertions(+), 37 deletions(-) -- 2.17.1
suspend/resume issue in stmmac driver
Hi guys, When I do suspend/resume stress test with stmmac driver, I encountered some tricky issues. DWC EQOS version is 5.10, Linux kernel version is 5.10. 1. The first issue is net watchdog timeout. stmmac_xmit() call stmmac_tx_timer_arm() at the end to modify a timer to do the transmission cleanup work. Imagine such a situation, stmmac enters suspend immediately after stmmac_xmit() modify tx timer, stmmac_tx_clean() would not be invoked, this could affect BQL(I still don't know the specific reason), since netdev_tx_completed_queue() have not been involved, and then dql_avail(&dev_queue->dql) finally always return a negative value. __dev_xmit_skb() -> qdisc_run() -> __qdisc_run() -> qdisc_restart() -> dequeue_skb(): if ((q->flags & TCQ_F_ONETXQUEUE) && netif_xmit_frozen_or_stopped(txq)) // __QUEUE_STATE_STACK_XOFF bit is set After checking this, net core will stop transmitting any more. As a result, net watchdong would timeout. To fix this issue, we should call netdev_tx_reset_queue() in stmmac_resume(). 2. The second issue is Rx channel fatal bus error. During suspend/resume test, Rx channel report fatal bus error at a high possibility(and report many times), but there is no handler for this situation in stmmac driver. Do you know what would cause Rx channel fatal error? And how to handle it? I did some work, but now still can't fix it. Thanks a lot in advance. 😊 Best Regards, Joakim Zhang
Re: STMMAC driver with TSO enabled issue
Hi Jose,
On 5/28/2018 4:26 PM, Jose Abreu wrote:
Hi Bhadram,
On 28-05-2018 10:15, Bhadram Varka wrote:
Hi Jose,
On 5/25/2018 8:02 PM, Jose Abreu wrote:
On 25-05-2018 15:25, Bhadram Varka wrote:
Hi Jose,
On 5/25/2018 7:35 PM, Jose Abreu wrote:
Hi Bhadram,
On 25-05-2018 05:41, Bhadram Varka wrote:
Hi Jose,
On 5/24/2018 3:01 PM, Jose Abreu wrote:
Hi Bhadram,
On 24-05-2018 06:58, Bhadram Varka wrote:
After some time if check Tx descriptor status - then I see
only
below
[..]
[85788.286730] 027 [0x827951b0]: 0xf854f000 0x0 0x16d8
0x9000
index 025 and 026 descriptors processed but not index 027.
At this stage Tx DMA is always in below state -
■ 3'b011: Running (Reading Data from system memory
buffer and queuing it to the Tx buffer (Tx FIFO))
Thats strange, I think the descriptors look okay though. I
will
need the registers values (before the lock) and, if
possible, the
git bisect output.
Attaching the register dump file after the issue observed.
Please check once.
->8-
0x112c = 0x003F
0x11ac = 0x003F
0x122c = 0x003F
0x12ac = 0x003F
0x1130 = 0x003F
0x11b0 = 0x003F
0x1230 = 0x003F
0x12b0 = 0x003F
->8-
This can't be right, it should be DMA_{RX/TX}_SIZE - 1 =
511. Did
you change these values in the code?
Yes. I have changed the descriptor length to 64 - so that
searching for the current descriptor status would be easy.
Ok, it shouldn't impact anything. The only thing I'm remembering
now is that you can have TSO not enabled in all DMA channels (HW
configuration allows this). Please check if TSO in single-queue
works.
TSO works fine if only single queue enabled. I don't see any
limitation from HW side because TSO works fine with other
driver which we received from Synopsys with IP drop.
You need to check with HW team if TSO is enabled for all channels
because you can have TSO channels < DMA channels and there is no
way to confirm this in the registers. Also check if received
driver is routing packets to queue != 0.
Root caused the issue to TxPBL settings. In current configuration driver
using the TxPBL = 32 which will be fine for single channel but its not
recommended settings for multi-queue scenario. Recommended setting for
TxPBL is half of the queue size.
o Total MTL Tx queue size - 16KB
o For multi-queue - total size divided by number of queues -
(16KB/4) = 4KB for each queue.
o So we need to set the TxPBL value so that we can place memory request
for 2KB from system memory. For this to achieve we need to set TxPBL=16.
Thanks for the help in debugging.
--
Thanks,
Bhadram.
Re: STMMAC driver with TSO enabled issue
Hi Bhadram,
On 28-05-2018 10:15, Bhadram Varka wrote:
> Hi Jose,
>
> On 5/25/2018 8:02 PM, Jose Abreu wrote:
>> On 25-05-2018 15:25, Bhadram Varka wrote:
>>> Hi Jose,
>>>
>>> On 5/25/2018 7:35 PM, Jose Abreu wrote:
Hi Bhadram,
On 25-05-2018 05:41, Bhadram Varka wrote:
> Hi Jose,
>
> On 5/24/2018 3:01 PM, Jose Abreu wrote:
>> Hi Bhadram,
>>
>> On 24-05-2018 06:58, Bhadram Varka wrote:
>>>
>>> After some time if check Tx descriptor status - then I see
>>> only
>>> below
>>>
>>> [..]
>>> [85788.286730] 027 [0x827951b0]: 0xf854f000 0x0 0x16d8
>>> 0x9000
>>>
>>> index 025 and 026 descriptors processed but not index 027.
>>>
>>> At this stage Tx DMA is always in below state -
>>>
>>> ■ 3'b011: Running (Reading Data from system memory
>>> buffer and queuing it to the Tx buffer (Tx FIFO))
>>
>> Thats strange, I think the descriptors look okay though. I
>> will
>> need the registers values (before the lock) and, if
>> possible, the
>> git bisect output.
>
> Attaching the register dump file after the issue observed.
> Please check once.
>
->8-
0x112c = 0x003F
0x11ac = 0x003F
0x122c = 0x003F
0x12ac = 0x003F
0x1130 = 0x003F
0x11b0 = 0x003F
0x1230 = 0x003F
0x12b0 = 0x003F
->8-
This can't be right, it should be DMA_{RX/TX}_SIZE - 1 =
511. Did
you change these values in the code?
>>>
>>> Yes. I have changed the descriptor length to 64 - so that
>>> searching for the current descriptor status would be easy.
>>
>> Ok, it shouldn't impact anything. The only thing I'm remembering
>> now is that you can have TSO not enabled in all DMA channels (HW
>> configuration allows this). Please check if TSO in single-queue
>> works.
> TSO works fine if only single queue enabled. I don't see any
> limitation from HW side because TSO works fine with other
> driver which we received from Synopsys with IP drop.
You need to check with HW team if TSO is enabled for all channels
because you can have TSO channels < DMA channels and there is no
way to confirm this in the registers. Also check if received
driver is routing packets to queue != 0.
Thanks and Best Regards,
Jose Miguel Abreu
>
>
> Thanks,
> Bhadram.
Re: STMMAC driver with TSO enabled issue
Hi Jose,
On 5/25/2018 8:02 PM, Jose Abreu wrote:
On 25-05-2018 15:25, Bhadram Varka wrote:
Hi Jose,
On 5/25/2018 7:35 PM, Jose Abreu wrote:
Hi Bhadram,
On 25-05-2018 05:41, Bhadram Varka wrote:
Hi Jose,
On 5/24/2018 3:01 PM, Jose Abreu wrote:
Hi Bhadram,
On 24-05-2018 06:58, Bhadram Varka wrote:
After some time if check Tx descriptor status - then I see
only
below
[..]
[85788.286730] 027 [0x827951b0]: 0xf854f000 0x0 0x16d8
0x9000
index 025 and 026 descriptors processed but not index 027.
At this stage Tx DMA is always in below state -
■ 3'b011: Running (Reading Data from system memory
buffer and queuing it to the Tx buffer (Tx FIFO))
Thats strange, I think the descriptors look okay though. I will
need the registers values (before the lock) and, if
possible, the
git bisect output.
Attaching the register dump file after the issue observed.
Please check once.
->8-
0x112c = 0x003F
0x11ac = 0x003F
0x122c = 0x003F
0x12ac = 0x003F
0x1130 = 0x003F
0x11b0 = 0x003F
0x1230 = 0x003F
0x12b0 = 0x003F
->8-
This can't be right, it should be DMA_{RX/TX}_SIZE - 1 = 511. Did
you change these values in the code?
Yes. I have changed the descriptor length to 64 - so that
searching for the current descriptor status would be easy.
Ok, it shouldn't impact anything. The only thing I'm remembering
now is that you can have TSO not enabled in all DMA channels (HW
configuration allows this). Please check if TSO in single-queue
works.
TSO works fine if only single queue enabled. I don't see any limitation
from HW side because TSO works fine with other driver which we received
from Synopsys with IP drop.
Thanks,
Bhadram.
Re: STMMAC driver with TSO enabled issue
On 25-05-2018 15:25, Bhadram Varka wrote:
> Hi Jose,
>
> On 5/25/2018 7:35 PM, Jose Abreu wrote:
>> Hi Bhadram,
>>
>> On 25-05-2018 05:41, Bhadram Varka wrote:
>>> Hi Jose,
>>>
>>> On 5/24/2018 3:01 PM, Jose Abreu wrote:
Hi Bhadram,
On 24-05-2018 06:58, Bhadram Varka wrote:
>
> After some time if check Tx descriptor status - then I see
> only
> below
>
> [..]
> [85788.286730] 027 [0x827951b0]: 0xf854f000 0x0 0x16d8
> 0x9000
>
> index 025 and 026 descriptors processed but not index 027.
>
> At this stage Tx DMA is always in below state -
>
> ■ 3'b011: Running (Reading Data from system memory
> buffer and queuing it to the Tx buffer (Tx FIFO))
Thats strange, I think the descriptors look okay though. I will
need the registers values (before the lock) and, if
possible, the
git bisect output.
>>>
>>> Attaching the register dump file after the issue observed.
>>> Please check once.
>>>
>>
>> ->8-
>> 0x112c = 0x003F
>> 0x11ac = 0x003F
>> 0x122c = 0x003F
>> 0x12ac = 0x003F
>>
>> 0x1130 = 0x003F
>> 0x11b0 = 0x003F
>> 0x1230 = 0x003F
>> 0x12b0 = 0x003F
>> ->8-
>>
>> This can't be right, it should be DMA_{RX/TX}_SIZE - 1 = 511. Did
>> you change these values in the code?
>>
>
> Yes. I have changed the descriptor length to 64 - so that
> searching for the current descriptor status would be easy.
Ok, it shouldn't impact anything. The only thing I'm remembering
now is that you can have TSO not enabled in all DMA channels (HW
configuration allows this). Please check if TSO in single-queue
works.
Thanks and Best Regards,
Jose Miguel Abreu
Re: STMMAC driver with TSO enabled issue
Hi Jose,
On 5/25/2018 7:35 PM, Jose Abreu wrote:
Hi Bhadram,
On 25-05-2018 05:41, Bhadram Varka wrote:
Hi Jose,
On 5/24/2018 3:01 PM, Jose Abreu wrote:
Hi Bhadram,
On 24-05-2018 06:58, Bhadram Varka wrote:
After some time if check Tx descriptor status - then I see only
below
[..]
[85788.286730] 027 [0x827951b0]: 0xf854f000 0x0 0x16d8
0x9000
index 025 and 026 descriptors processed but not index 027.
At this stage Tx DMA is always in below state -
■ 3'b011: Running (Reading Data from system memory
buffer and queuing it to the Tx buffer (Tx FIFO))
Thats strange, I think the descriptors look okay though. I will
need the registers values (before the lock) and, if possible, the
git bisect output.
Attaching the register dump file after the issue observed.
Please check once.
->8-
0x112c = 0x003F
0x11ac = 0x003F
0x122c = 0x003F
0x12ac = 0x003F
0x1130 = 0x003F
0x11b0 = 0x003F
0x1230 = 0x003F
0x12b0 = 0x003F
->8-
This can't be right, it should be DMA_{RX/TX}_SIZE - 1 = 511. Did
you change these values in the code?
Yes. I have changed the descriptor length to 64 - so that searching for
the current descriptor status would be easy.
--
Thanks,
Bhadram.
Re: STMMAC driver with TSO enabled issue
Hi Bhadram,
On 25-05-2018 05:41, Bhadram Varka wrote:
> Hi Jose,
>
> On 5/24/2018 3:01 PM, Jose Abreu wrote:
>> Hi Bhadram,
>>
>> On 24-05-2018 06:58, Bhadram Varka wrote:
>>>
>>> After some time if check Tx descriptor status - then I see only
>>> below
>>>
>>> [..]
>>> [85788.286730] 027 [0x827951b0]: 0xf854f000 0x0 0x16d8
>>> 0x9000
>>>
>>> index 025 and 026 descriptors processed but not index 027.
>>>
>>> At this stage Tx DMA is always in below state -
>>>
>>> ■ 3'b011: Running (Reading Data from system memory
>>> buffer and queuing it to the Tx buffer (Tx FIFO))
>>
>> Thats strange, I think the descriptors look okay though. I will
>> need the registers values (before the lock) and, if possible, the
>> git bisect output.
>
> Attaching the register dump file after the issue observed.
> Please check once.
>
->8-
0x112c = 0x003F
0x11ac = 0x003F
0x122c = 0x003F
0x12ac = 0x003F
0x1130 = 0x003F
0x11b0 = 0x003F
0x1230 = 0x003F
0x12b0 = 0x003F
->8-
This can't be right, it should be DMA_{RX/TX}_SIZE - 1 = 511. Did
you change these values in the code?
Thanks and Best Regards,
Jose Miguel Abreu
Re: STMMAC driver with TSO enabled issue
Hi Jose, On 5/24/2018 3:01 PM, Jose Abreu wrote: Hi Bhadram, On 24-05-2018 06:58, Bhadram Varka wrote: After some time if check Tx descriptor status - then I see only below [..] [85788.286730] 027 [0x827951b0]: 0xf854f000 0x0 0x16d8 0x9000 index 025 and 026 descriptors processed but not index 027. At this stage Tx DMA is always in below state - ■ 3'b011: Running (Reading Data from system memory buffer and queuing it to the Tx buffer (Tx FIFO)) Thats strange, I think the descriptors look okay though. I will need the registers values (before the lock) and, if possible, the git bisect output. Attaching the register dump file after the issue observed. Please check once. -- Thanks, Bhadram. 0x0 = 0x08062203 0x4 = 0x 0x8 = 0x0004 0xc = 0x 0x10 = 0x4002 0x14 = 0x00020001 0x18 = 0x 0x1c = 0x 0x20 = 0x 0x24 = 0x 0x28 = 0x 0x2c = 0x 0x50 = 0x 0x54 = 0x 0x58 = 0x 0x60 = 0x 0x64 = 0x 0x70 = 0x 0x74 = 0x 0x78 = 0x 0x7c = 0x 0x90 = 0x 0x94 = 0x 0x98 = 0x 0x9c = 0x 0xa0 = 0x00AA 0xa4 = 0x 0xa8 = 0x03020100 0xac = 0x 0xb0 = 0x 0xb4 = 0x0030 0xb8 = 0x 0xc0 = 0x 0xc4 = 0x 0xd0 = 0x 0xd4 = 0x03E8 0xd8 = 0x 0xdc = 0x0063 0xe0 = 0x 0xe4 = 0x 0xe8 = 0x 0xec = 0x 0xf0 = 0x 0xf4 = 0x 0xf8 = 0x 0x110 = 0x1041 0x114 = 0x 0x11c = 0x1BFD73F7 0x120 = 0x429E79C7 0x124 = 0x100C30C3 0x128 = 0x 0x140 = 0x 0x144 = 0x 0x148 = 0x 0x14c = 0x 0x150 = 0x 0x200 = 0x00100104 0x204 = 0x 0x208 = 0x 0x20c = 0x 0x210 = 0x 0x230 = 0x 0x234 = 0x 0x238 = 0x 0x240 = 0x 0x244 = 0x 0x300 = 0x80005CE1 0x304 = 0xCAA296FE 0xc00 = 0x 0xc08 = 0x 0xc0c = 0x00800018 0xc10 = 0x 0xc20 = 0x 0xc30 = 0x02020100 0xc34 = 0x 0xd00 = 0x000F000A 0xd04 = 0x 0xd08 = 0x 0xd0c = 0x 0xd14 = 0x 0xd18 = 0x0010 0xd2c = 0x0100 0xd30 = 0x00F0C1A0 0xd34 = 0x 0xd38 = 0x 0xd3c = 0x 0xd40 = 0x000F000A 0xd80 = 0x000F000A 0xdc0 = 0x000F000A 0xd44 = 0x 0xd84 = 0x 0xdc4 = 0x 0xd48 = 0x 0xd88 = 0x 0xdc8 = 0x 0x1000 = 0x 0x1004 = 0x0002100E 0x1008 = 0x 0x100c = 0x33636300 0x1010 = 0x0063 0x1014 = 0x 0x1020 = 0x 0x1024 = 0x 0x1028 = 0x 0x1100 = 0x0001 0x1180 = 0x0001 0x1200 = 0x0001 0x1280 = 0x0001 0x1104 = 0x00201001 0x1184 = 0x00201001 0x1204 = 0x00201001 0x1284 = 0x00201001 0x1108 = 0x00080001 0x1188 = 0x00080001 0x1208 = 0x00080001 0x1288 = 0x00080001 0x1110 = 0x 0x1190 = 0x 0x1210 = 0x 0x1290 = 0x 0x1114 = 0xFC044000 0x1194 = 0xFC045000 0x1214 = 0xFC046000 0x1294 = 0xFC047000 0x1118 = 0x 0x1198 = 0x 0x1218 = 0x 0x1298 = 0x 0x111C = 0xFC04 0x119c = 0xFC041000 0x121c = 0xFC042000 0x129c = 0xFC043000 0x1120 = 0xFC044400 0x11A0 = 0xFC045400 0x1220 = 0xFC046400 0x12A0 = 0xFC047400 0x1128 = 0xFC040400 0x11A8 = 0xFC041400 0x1228 = 0xFC042400 0x12A8 = 0xFC043400 0x112c = 0x003F 0x11ac = 0x003F 0x122c = 0x003F 0x12ac = 0x003F 0x1130 = 0x003F 0x11b0 = 0x003F 0x1230 = 0x003F 0x12b0 = 0x003F
Re: STMMAC driver with TSO enabled issue
Hi Bhadram, On 24-05-2018 06:58, Bhadram Varka wrote: > > After some time if check Tx descriptor status - then I see only > below > > [..] > [85788.286730] 027 [0x827951b0]: 0xf854f000 0x0 0x16d8 0x9000 > > index 025 and 026 descriptors processed but not index 027. > > At this stage Tx DMA is always in below state - > > ■ 3'b011: Running (Reading Data from system memory > buffer and queuing it to the Tx buffer (Tx FIFO)) Thats strange, I think the descriptors look okay though. I will need the registers values (before the lock) and, if possible, the git bisect output. Thanks and Best Regards, Jose Miguel Abreu > > Thanks, > Bhadram.
Re: STMMAC driver with TSO enabled issue
Hi Jose, On 5/17/2018 7:43 PM, Jose Abreu wrote: Hi Bhadram, On 15-05-2018 07:44, Bhadram Varka wrote: Hi Jose, On 5/10/2018 9:15 PM, Jose Abreu wrote: On 10-05-2018 16:08, Bhadram Varka wrote: Hi Jose, On 5/10/2018 7:59 PM, Jose Abreu wrote: Hi Bhadram, On 10-05-2018 09:55, Jose Abreu wrote: ++net-dev Hi Bhadram, On 09-05-2018 12:03, Bhadram Varka wrote: Hi, Thanks for responding. Tried below suggested way. Still observing the issue - It seems stmmac has a bug in the RX side when using TSO which is causing all the RX descriptors to be consumed. The stmmac_rx() function will need to be refactored. I will send a fix ASAP. Are you using this patch [1] ? Because there is a problem with the patch. By adding the previously removed call to stmmac_init_rx_desc() TSO works okay in my setup. No. I don't have this change in my code base. I am using net-next tree. Can you please post the change for which TSO works ? I can help you with the testing. It should work with net-next because patch was not merged yet ... Please send me the output of "dmesg | grep -i stmmac", since boot and your full register values (from 0x0 to 0x12E4). [root@alarm ~]# dmesg | grep -i dwc [6.925005] dwc-eth-dwmac 249.ethernet: Cannot get CSR clock [6.933657] dwc-eth-dwmac 249.ethernet: no reset control found [6.955325] dwc-eth-dwmac 249.ethernet: User ID: 0x10, Synopsys ID: 0x41 [6.962379] dwc-eth-dwmac 249.ethernet: DWMAC4/5 [6.967434] dwc-eth-dwmac 249.ethernet: DMA HW capability register supported [6.974827] dwc-eth-dwmac 249.ethernet: RX Checksum Offload Engine supported [6.982915] dwc-eth-dwmac 249.ethernet: TX Checksum insertion supported [6.991235] dwc-eth-dwmac 249.ethernet: Wake-Up On Lan supported [6.998974] dwc-eth-dwmac 249.ethernet: TSO supported [7.006422] dwc-eth-dwmac 249.ethernet: TSO feature enabled [7.012581] dwc-eth-dwmac 249.ethernet: Enable RX Mitigation via HW Watchdog Timer [7.236391] dwc-eth-dwmac 249.ethernet eth0: device MAC address 4a:d1:e3:58:cb:7a [7.333414] dwc-eth-dwmac 249.ethernet eth0: IEEE 1588-2008 Advanced Timestamp supported [7.342441] dwc-eth-dwmac 249.ethernet eth0: registered PTP clock [ 10.157066] dwc-eth-dwmac 249.ethernet eth0: Link is Up - 1Gbps/Full - flow control off [root@alarm ~]# dmesg | grep -i stmma [7.020567] libphy: stmmac: probed [7.316295] Broadcom BCM89610 stmmac-0:00: attached PHY driver [Broadcom BCM89610] (mii_bus:phy_addr=stmmac-0:00, irq=64) I will get the register details - FYI - TSO works fine with single channel. I see the issue only if multi channel enabled (supports 4 Tx/Rx channels). And normal data transfer works okay with multi channel, right? I will need the register details to proceed ... You could also try git bisect ... Yes - normal data transfers works fine. Issue observed only driver gets TSO packet. Looks like TX DMA channel hang. After adding few debug logs - observed that while processing second or third descriptor TX DMA hangs. [85788.137498] stmmac_tso_xmit: tcphdrlen 32, hdr_len 66, pay_len 1392, mss 1448 [85788.144634] skb->len 7306, skb->data_len 5848 [..] [85788.274876] 025 [0x82795190]: 0x0 0x0 0x5a8 0xc400 [85788.280020] 026 [0x827951a0]: 0xf854e000 0xf854e042 0x5700042 0xa0441c48 [85788.286730] 027 [0x827951b0]: 0xf854f000 0x0 0x16d8 0x9000 [...] After some time if check Tx descriptor status - then I see only below [..] [85788.286730] 027 [0x827951b0]: 0xf854f000 0x0 0x16d8 0x9000 index 025 and 026 descriptors processed but not index 027. At this stage Tx DMA is always in below state - ■ 3'b011: Running (Reading Data from system memory buffer and queuing it to the Tx buffer (Tx FIFO)) Thanks, Bhadram.
Re: STMMAC driver with TSO enabled issue
Hi Bhadram, On 15-05-2018 07:44, Bhadram Varka wrote: > Hi Jose, > > On 5/10/2018 9:15 PM, Jose Abreu wrote: >> >> >> On 10-05-2018 16:08, Bhadram Varka wrote: >>> Hi Jose, >>> >>> On 5/10/2018 7:59 PM, Jose Abreu wrote: Hi Bhadram, On 10-05-2018 09:55, Jose Abreu wrote: > ++net-dev > > Hi Bhadram, > > On 09-05-2018 12:03, Bhadram Varka wrote: >> Hi, >> >> Thanks for responding. >> >> Tried below suggested way. Still observing the issue - > It seems stmmac has a bug in the RX side when using TSO > which is > causing all the RX descriptors to be consumed. The stmmac_rx() > function will need to be refactored. I will send a fix ASAP. Are you using this patch [1] ? Because there is a problem with the patch. By adding the previously removed call to stmmac_init_rx_desc() TSO works okay in my setup. >>> >>> No. I don't have this change in my code base. I am using >>> net-next tree. >>> >>> Can you please post the change for which TSO works ? I can help >>> you with the testing. >> >> It should work with net-next because patch was not merged yet ... >> Please send me the output of "dmesg | grep -i stmmac", since boot >> and your full register values (from 0x0 to 0x12E4). >> > > [root@alarm ~]# dmesg | grep -i dwc > [6.925005] dwc-eth-dwmac 249.ethernet: Cannot get CSR > clock > [6.933657] dwc-eth-dwmac 249.ethernet: no reset control > found > [6.955325] dwc-eth-dwmac 249.ethernet: User ID: 0x10, > Synopsys ID: 0x41 > [6.962379] dwc-eth-dwmac 249.ethernet: DWMAC4/5 > [6.967434] dwc-eth-dwmac 249.ethernet: DMA HW > capability register supported > [6.974827] dwc-eth-dwmac 249.ethernet: RX Checksum > Offload Engine supported > [6.982915] dwc-eth-dwmac 249.ethernet: TX Checksum > insertion supported > [6.991235] dwc-eth-dwmac 249.ethernet: Wake-Up On Lan > supported > [6.998974] dwc-eth-dwmac 249.ethernet: TSO supported > [7.006422] dwc-eth-dwmac 249.ethernet: TSO feature enabled > [7.012581] dwc-eth-dwmac 249.ethernet: Enable RX > Mitigation via HW Watchdog Timer > [7.236391] dwc-eth-dwmac 249.ethernet eth0: device MAC > address 4a:d1:e3:58:cb:7a > [7.333414] dwc-eth-dwmac 249.ethernet eth0: IEEE > 1588-2008 Advanced Timestamp supported > [7.342441] dwc-eth-dwmac 249.ethernet eth0: registered > PTP clock > [ 10.157066] dwc-eth-dwmac 249.ethernet eth0: Link is Up > - 1Gbps/Full - flow control off > [root@alarm ~]# dmesg | grep -i stmma > [7.020567] libphy: stmmac: probed > [7.316295] Broadcom BCM89610 stmmac-0:00: attached PHY > driver [Broadcom BCM89610] (mii_bus:phy_addr=stmmac-0:00, irq=64) > > I will get the register details - > > FYI - TSO works fine with single channel. I see the issue only > if multi channel enabled (supports 4 Tx/Rx channels). > And normal data transfer works okay with multi channel, right? I will need the register details to proceed ... You could also try git bisect ... Thanks and Best Regards, Jose Miguel Abreu
Re: STMMAC driver with TSO enabled issue
Hi Jose, On 5/10/2018 9:15 PM, Jose Abreu wrote: On 10-05-2018 16:08, Bhadram Varka wrote: Hi Jose, On 5/10/2018 7:59 PM, Jose Abreu wrote: Hi Bhadram, On 10-05-2018 09:55, Jose Abreu wrote: ++net-dev Hi Bhadram, On 09-05-2018 12:03, Bhadram Varka wrote: Hi, Thanks for responding. Tried below suggested way. Still observing the issue - It seems stmmac has a bug in the RX side when using TSO which is causing all the RX descriptors to be consumed. The stmmac_rx() function will need to be refactored. I will send a fix ASAP. Are you using this patch [1] ? Because there is a problem with the patch. By adding the previously removed call to stmmac_init_rx_desc() TSO works okay in my setup. No. I don't have this change in my code base. I am using net-next tree. Can you please post the change for which TSO works ? I can help you with the testing. It should work with net-next because patch was not merged yet ... Please send me the output of "dmesg | grep -i stmmac", since boot and your full register values (from 0x0 to 0x12E4). [root@alarm ~]# dmesg | grep -i dwc [6.925005] dwc-eth-dwmac 249.ethernet: Cannot get CSR clock [6.933657] dwc-eth-dwmac 249.ethernet: no reset control found [6.955325] dwc-eth-dwmac 249.ethernet: User ID: 0x10, Synopsys ID: 0x41 [6.962379] dwc-eth-dwmac 249.ethernet: DWMAC4/5 [6.967434] dwc-eth-dwmac 249.ethernet: DMA HW capability register supported [6.974827] dwc-eth-dwmac 249.ethernet: RX Checksum Offload Engine supported [6.982915] dwc-eth-dwmac 249.ethernet: TX Checksum insertion supported [6.991235] dwc-eth-dwmac 249.ethernet: Wake-Up On Lan supported [6.998974] dwc-eth-dwmac 249.ethernet: TSO supported [7.006422] dwc-eth-dwmac 249.ethernet: TSO feature enabled [7.012581] dwc-eth-dwmac 249.ethernet: Enable RX Mitigation via HW Watchdog Timer [7.236391] dwc-eth-dwmac 249.ethernet eth0: device MAC address 4a:d1:e3:58:cb:7a [7.333414] dwc-eth-dwmac 249.ethernet eth0: IEEE 1588-2008 Advanced Timestamp supported [7.342441] dwc-eth-dwmac 249.ethernet eth0: registered PTP clock [ 10.157066] dwc-eth-dwmac 249.ethernet eth0: Link is Up - 1Gbps/Full - flow control off [root@alarm ~]# dmesg | grep -i stmma [7.020567] libphy: stmmac: probed [7.316295] Broadcom BCM89610 stmmac-0:00: attached PHY driver [Broadcom BCM89610] (mii_bus:phy_addr=stmmac-0:00, irq=64) I will get the register details - FYI - TSO works fine with single channel. I see the issue only if multi channel enabled (supports 4 Tx/Rx channels). -- Thanks, Bhadram.
Re: STMMAC driver with TSO enabled issue
On 10-05-2018 16:08, Bhadram Varka wrote: > Hi Jose, > > On 5/10/2018 7:59 PM, Jose Abreu wrote: >> Hi Bhadram, >> >> On 10-05-2018 09:55, Jose Abreu wrote: >>> ++net-dev >>> >>> Hi Bhadram, >>> >>> On 09-05-2018 12:03, Bhadram Varka wrote: Hi, Thanks for responding. Tried below suggested way. Still observing the issue - >>> It seems stmmac has a bug in the RX side when using TSO which is >>> causing all the RX descriptors to be consumed. The stmmac_rx() >>> function will need to be refactored. I will send a fix ASAP. >> >> Are you using this patch [1] ? Because there is a problem with >> the patch. By adding the previously removed call to >> stmmac_init_rx_desc() TSO works okay in my setup. >> > > No. I don't have this change in my code base. I am using > net-next tree. > > Can you please post the change for which TSO works ? I can help > you with the testing. It should work with net-next because patch was not merged yet ... Please send me the output of "dmesg | grep -i stmmac", since boot and your full register values (from 0x0 to 0x12E4).
Re: STMMAC driver with TSO enabled issue
Hi Jose, On 5/10/2018 7:59 PM, Jose Abreu wrote: Hi Bhadram, On 10-05-2018 09:55, Jose Abreu wrote: ++net-dev Hi Bhadram, On 09-05-2018 12:03, Bhadram Varka wrote: Hi, Thanks for responding. Tried below suggested way. Still observing the issue - It seems stmmac has a bug in the RX side when using TSO which is causing all the RX descriptors to be consumed. The stmmac_rx() function will need to be refactored. I will send a fix ASAP. Are you using this patch [1] ? Because there is a problem with the patch. By adding the previously removed call to stmmac_init_rx_desc() TSO works okay in my setup. No. I don't have this change in my code base. I am using net-next tree. Can you please post the change for which TSO works ? I can help you with the testing. -- Thanks, Bhadram.
Re: STMMAC driver with TSO enabled issue
Hi Bhadram, On 10-05-2018 09:55, Jose Abreu wrote: > ++net-dev > > Hi Bhadram, > > On 09-05-2018 12:03, Bhadram Varka wrote: >> Hi, >> >> Thanks for responding. >> >> Tried below suggested way. Still observing the issue - > It seems stmmac has a bug in the RX side when using TSO which is > causing all the RX descriptors to be consumed. The stmmac_rx() > function will need to be refactored. I will send a fix ASAP. Are you using this patch [1] ? Because there is a problem with the patch. By adding the previously removed call to stmmac_init_rx_desc() TSO works okay in my setup. [1] https://patchwork.ozlabs.org/patch/910224/ > > Thanks and Best Regards, > Jose Miguel Abreu > >> [root@alarm ~]# iperf3 -c 10.19.65.141 >> Connecting to host 10.19.65.141, port 5201 >> [ 5] local 10.19.65.210 port 57630 connected to 10.19.65.141 >> port 5201 >> [ 65.408268] stmmac_tso_xmit(): line = 2842 >> [ 65.412362] stmmac_tso_xmit: tcphdrlen 32, hdr_len 66, >> pay_len 0, mss 1448 >> [ 65.419224] skb->len 8754, skb->data_len 8688 >> [ 65.423672] stmmac_tso_xmit: curr=20 dirty=17 f=18, e=20, >> f_p=178e52e1, nfrags 1 >> [ 65.431747] TX descriptor ring: >> [ 65.434881] 000 [0x82005000]: 0x0 0x0 0x0 0x0 >> [ 65.439230] 001 [0x82005010]: 0x0 0x0 0x0 0x0 >> [ 65.443578] 002 [0x82005020]: 0x0 0x0 0x0 0x0 >> [ 65.447927] 003 [0x82005030]: 0x0 0x0 0x0 0x0 >> [ 65.452275] 004 [0x82005040]: 0x0 0x0 0x0 0x0 >> [ 65.456622] 005 [0x82005050]: 0x0 0x0 0x0 0x0 >> [ 65.460970] 006 [0x82005060]: 0x0 0x0 0x0 0x0 >> [ 65.465316] 007 [0x82005070]: 0x0 0x0 0x0 0x0 >> [ 65.469664] 008 [0x82005080]: 0x0 0x0 0x0 0x0 >> [ 65.474010] 009 [0x82005090]: 0x0 0x0 0x0 0x0 >> [ 65.478357] 010 [0x820050a0]: 0x0 0x0 0x0 0x0 >> [ 65.482706] 011 [0x820050b0]: 0x0 0x0 0x0 0x0 >> [ 65.487053] 012 [0x820050c0]: 0x0 0x0 0x0 0x0 >> [ 65.491400] 013 [0x820050d0]: 0x0 0x0 0x0 0x0 >> [ 65.495746] 014 [0x820050e0]: 0x0 0x0 0x0 0x0 >> [ 65.500092] 015 [0x820050f0]: 0x0 0x0 0x0 0x0 >> [ 65.504438] 016 [0x82005100]: 0x0 0x0 0x0 0x0 >> [ 65.508784] 017 [0x82005110]: 0x0 0x0 0x5a8 0xc400 >> [ 65.513910] 018 [0x82005120]: 0xfb297000 0x0 0x42 0xa04421f0 >> [ 65.519557] 019 [0x82005130]: 0xfb298000 0x0 0x21f0 0x9000 >> [ 65.525376] 020 [0x82005140]: 0x0 0x0 0x0 0x0 >> [ 65.529722] 021 [0x82005150]: 0x0 0x0 0x0 0x0 >> [ 65.534069] 022 [0x82005160]: 0x0 0x0 0x0 0x0 >> [ 65.538414] 023 [0x82005170]: 0x0 0x0 0x0 0x0 >> [ 65.542761] 024 [0x82005180]: 0x0 0x0 0x0 0x0 >> [ 65.547107] 025 [0x82005190]: 0x0 0x0 0x0 0x0 >> [ 65.551454] 026 [0x820051a0]: 0x0 0x0 0x0 0x0 >> [ 65.555802] 027 [0x820051b0]: 0x0 0x0 0x0 0x0 >> [ 65.560147] 028 [0x820051c0]: 0x0 0x0 0x0 0x0 >> [ 65.564493] 029 [0x820051d0]: 0x0 0x0 0x0 0x0 >> [ 65.568840] 030 [0x820051e0]: 0x0 0x0 0x0 0x0 >> [ 65.573187] 031 [0x820051f0]: 0x0 0x0 0x0 0x0 >> [ 65.577533] 032 [0x82005200]: 0x0 0x0 0x0 0x0 >> [ 65.581879] 033 [0x82005210]: 0x0 0x0 0x0 0x0 >> [ 65.586225] 034 [0x82005220]: 0x0 0x0 0x0 0x0 >> [ 65.590571] 035 [0x82005230]: 0x0 0x0 0x0 0x0 >> [ 65.594917] 036 [0x82005240]: 0x0 0x0 0x0 0x0 >> [ 65.599262] 037 [0x82005250]: 0x0 0x0 0x0 0x0 >> [ 65.603607] 038 [0x82005260]: 0x0 0x0 0x0 0x0 >> [ 65.607952] 039 [0x82005270]: 0x0 0x0 0x0 0x0 >> [ 65.612297] 040 [0x82005280]: 0x0 0x0 0x0 0x0 >> [ 65.616643] 041 [0x82005290]: 0x0 0x0 0x0 0x0 >> [ 65.620989] 042 [0x820052a0]: 0x0 0x0 0x0 0x0 >> [ 65.625336] 043 [0x820052b0]: 0x0 0x0 0x0 0x0 >> [ 65.629681] 044 [0x820052c0]: 0x0 0x0 0x0 0x0 >> [ 65.634027] 045 [0x820052d0]: 0x0 0x0 0x0 0x0 >> [ 65.638372] 046 [0x820052e0]: 0x0 0x0 0x0 0x0 >> [ 65.642718] 047 [0x820052f0]: 0x0 0x0 0x0 0x0 >> [ 65.647063] 048 [0x82005300]: 0x0 0x0 0x0 0x0 >> [ 65.651408] 049 [0x82005310]: 0x0 0x0 0x0 0x0 >> [ 65.655754] 050 [0x82005320]: 0x0 0x0 0x0 0x0 >> [ 65.660099] 051 [0x82005330]: 0x0 0x0 0x0 0x0 >> [ 65.66] 052 [0x82005340]: 0x0 0x0 0x0 0x0 >> [ 65.668790] 053 [0x82005350]: 0x0 0x0 0x0 0x0 >> [ 65.673134] 054 [0x82005360]: 0x0 0x0 0x0 0x0 >> [ 65.677480] 055 [0x82005370]: 0x0 0x0 0x0 0x0 >> [ 65.681825] 056 [0x82005380]: 0x0 0x0 0x0 0x0 >> [ 65.686170] 057 [0x82005390]: 0x0 0x0 0x0 0x0 >> [ 65.690515] 058 [0x820053a0]: 0x0 0x0 0x0 0x0 >> [ 65.694861] 059 [0x820053b0]: 0x0 0x0 0x0 0x0 >> [ 65.699206] 060 [0x820053c0]: 0x0 0x0 0x0 0x0 >> [ 65.703552] 061 [0x820053d0]: 0x0 0x0 0x0 0x0 >> [ 65.707898] 062 [0x820053e0]: 0x0 0x0 0x0 0x0 >> [ 65.712243] 063 [0x820053f0]: 0x0 0x0 0x0 0x0 >> [ 65.716706] stmmac_tso_xmit(): line = 2842 >> [ 65.720802] stmmac_tso_xmit: tcphdrlen 32, hdr_len 66, >> pay_len 0, mss 1448 >> [ 65.727669] skb->len 4410, skb->data_len 4344 >> [ 65.732114] stmmac_tso_xmit: curr=22 dirty=19 f=20, e=22, >> f_p=b1247b41, nfrags 1 >> [ 65.740190] TX descriptor ring: >> [ 65.743327] 000 [0x82005000]: 0x0 0x0 0x0 0x0 >> [ 65.747678] 001 [0x82005010]: 0x0 0x0 0x0 0x0 >> [ 65.752029] 002 [0x8200502
Re: STMMAC driver with TSO enabled issue
++net-dev Hi Bhadram, On 09-05-2018 12:03, Bhadram Varka wrote: > Hi, > > Thanks for responding. > > Tried below suggested way. Still observing the issue - It seems stmmac has a bug in the RX side when using TSO which is causing all the RX descriptors to be consumed. The stmmac_rx() function will need to be refactored. I will send a fix ASAP. Thanks and Best Regards, Jose Miguel Abreu > > [root@alarm ~]# iperf3 -c 10.19.65.141 > Connecting to host 10.19.65.141, port 5201 > [ 5] local 10.19.65.210 port 57630 connected to 10.19.65.141 > port 5201 > [ 65.408268] stmmac_tso_xmit(): line = 2842 > [ 65.412362] stmmac_tso_xmit: tcphdrlen 32, hdr_len 66, > pay_len 0, mss 1448 > [ 65.419224] skb->len 8754, skb->data_len 8688 > [ 65.423672] stmmac_tso_xmit: curr=20 dirty=17 f=18, e=20, > f_p=178e52e1, nfrags 1 > [ 65.431747] TX descriptor ring: > [ 65.434881] 000 [0x82005000]: 0x0 0x0 0x0 0x0 > [ 65.439230] 001 [0x82005010]: 0x0 0x0 0x0 0x0 > [ 65.443578] 002 [0x82005020]: 0x0 0x0 0x0 0x0 > [ 65.447927] 003 [0x82005030]: 0x0 0x0 0x0 0x0 > [ 65.452275] 004 [0x82005040]: 0x0 0x0 0x0 0x0 > [ 65.456622] 005 [0x82005050]: 0x0 0x0 0x0 0x0 > [ 65.460970] 006 [0x82005060]: 0x0 0x0 0x0 0x0 > [ 65.465316] 007 [0x82005070]: 0x0 0x0 0x0 0x0 > [ 65.469664] 008 [0x82005080]: 0x0 0x0 0x0 0x0 > [ 65.474010] 009 [0x82005090]: 0x0 0x0 0x0 0x0 > [ 65.478357] 010 [0x820050a0]: 0x0 0x0 0x0 0x0 > [ 65.482706] 011 [0x820050b0]: 0x0 0x0 0x0 0x0 > [ 65.487053] 012 [0x820050c0]: 0x0 0x0 0x0 0x0 > [ 65.491400] 013 [0x820050d0]: 0x0 0x0 0x0 0x0 > [ 65.495746] 014 [0x820050e0]: 0x0 0x0 0x0 0x0 > [ 65.500092] 015 [0x820050f0]: 0x0 0x0 0x0 0x0 > [ 65.504438] 016 [0x82005100]: 0x0 0x0 0x0 0x0 > [ 65.508784] 017 [0x82005110]: 0x0 0x0 0x5a8 0xc400 > [ 65.513910] 018 [0x82005120]: 0xfb297000 0x0 0x42 0xa04421f0 > [ 65.519557] 019 [0x82005130]: 0xfb298000 0x0 0x21f0 0x9000 > [ 65.525376] 020 [0x82005140]: 0x0 0x0 0x0 0x0 > [ 65.529722] 021 [0x82005150]: 0x0 0x0 0x0 0x0 > [ 65.534069] 022 [0x82005160]: 0x0 0x0 0x0 0x0 > [ 65.538414] 023 [0x82005170]: 0x0 0x0 0x0 0x0 > [ 65.542761] 024 [0x82005180]: 0x0 0x0 0x0 0x0 > [ 65.547107] 025 [0x82005190]: 0x0 0x0 0x0 0x0 > [ 65.551454] 026 [0x820051a0]: 0x0 0x0 0x0 0x0 > [ 65.555802] 027 [0x820051b0]: 0x0 0x0 0x0 0x0 > [ 65.560147] 028 [0x820051c0]: 0x0 0x0 0x0 0x0 > [ 65.564493] 029 [0x820051d0]: 0x0 0x0 0x0 0x0 > [ 65.568840] 030 [0x820051e0]: 0x0 0x0 0x0 0x0 > [ 65.573187] 031 [0x820051f0]: 0x0 0x0 0x0 0x0 > [ 65.577533] 032 [0x82005200]: 0x0 0x0 0x0 0x0 > [ 65.581879] 033 [0x82005210]: 0x0 0x0 0x0 0x0 > [ 65.586225] 034 [0x82005220]: 0x0 0x0 0x0 0x0 > [ 65.590571] 035 [0x82005230]: 0x0 0x0 0x0 0x0 > [ 65.594917] 036 [0x82005240]: 0x0 0x0 0x0 0x0 > [ 65.599262] 037 [0x82005250]: 0x0 0x0 0x0 0x0 > [ 65.603607] 038 [0x82005260]: 0x0 0x0 0x0 0x0 > [ 65.607952] 039 [0x82005270]: 0x0 0x0 0x0 0x0 > [ 65.612297] 040 [0x82005280]: 0x0 0x0 0x0 0x0 > [ 65.616643] 041 [0x82005290]: 0x0 0x0 0x0 0x0 > [ 65.620989] 042 [0x820052a0]: 0x0 0x0 0x0 0x0 > [ 65.625336] 043 [0x820052b0]: 0x0 0x0 0x0 0x0 > [ 65.629681] 044 [0x820052c0]: 0x0 0x0 0x0 0x0 > [ 65.634027] 045 [0x820052d0]: 0x0 0x0 0x0 0x0 > [ 65.638372] 046 [0x820052e0]: 0x0 0x0 0x0 0x0 > [ 65.642718] 047 [0x820052f0]: 0x0 0x0 0x0 0x0 > [ 65.647063] 048 [0x82005300]: 0x0 0x0 0x0 0x0 > [ 65.651408] 049 [0x82005310]: 0x0 0x0 0x0 0x0 > [ 65.655754] 050 [0x82005320]: 0x0 0x0 0x0 0x0 > [ 65.660099] 051 [0x82005330]: 0x0 0x0 0x0 0x0 > [ 65.66] 052 [0x82005340]: 0x0 0x0 0x0 0x0 > [ 65.668790] 053 [0x82005350]: 0x0 0x0 0x0 0x0 > [ 65.673134] 054 [0x82005360]: 0x0 0x0 0x0 0x0 > [ 65.677480] 055 [0x82005370]: 0x0 0x0 0x0 0x0 > [ 65.681825] 056 [0x82005380]: 0x0 0x0 0x0 0x0 > [ 65.686170] 057 [0x82005390]: 0x0 0x0 0x0 0x0 > [ 65.690515] 058 [0x820053a0]: 0x0 0x0 0x0 0x0 > [ 65.694861] 059 [0x820053b0]: 0x0 0x0 0x0 0x0 > [ 65.699206] 060 [0x820053c0]: 0x0 0x0 0x0 0x0 > [ 65.703552] 061 [0x820053d0]: 0x0 0x0 0x0 0x0 > [ 65.707898] 062 [0x820053e0]: 0x0 0x0 0x0 0x0 > [ 65.712243] 063 [0x820053f0]: 0x0 0x0 0x0 0x0 > [ 65.716706] stmmac_tso_xmit(): line = 2842 > [ 65.720802] stmmac_tso_xmit: tcphdrlen 32, hdr_len 66, > pay_len 0, mss 1448 > [ 65.727669] skb->len 4410, skb->data_len 4344 > [ 65.732114] stmmac_tso_xmit: curr=22 dirty=19 f=20, e=22, > f_p=b1247b41, nfrags 1 > [ 65.740190] TX descriptor ring: > [ 65.743327] 000 [0x82005000]: 0x0 0x0 0x0 0x0 > [ 65.747678] 001 [0x82005010]: 0x0 0x0 0x0 0x0 > [ 65.752029] 002 [0x82005020]: 0x0 0x0 0x0 0x0 > [ 65.756378] 003 [0x82005030]: 0x0 0x0 0x0 0x0 > [ 65.760727] 004 [0x82005040]: 0x0 0x0 0x0 0x0 > [ 65.765077] 005 [0x82005050]: 0x0 0x0 0x0 0x0 > [ 65.769427] 006 [0x82005060]: 0x0 0x0 0x0 0x0 > [ 65.773776] 007 [0x82005070]: 0x0 0x0 0x0 0x0 > [ 65.778126] 008 [0x82005080]: 0x0 0x0 0x0 0x0 > [ 65.782476] 009 [0x82005090]: 0x0 0x0 0x0 0
Re: stmmac driver...
Hello Jie On 12/14/2016 5:05 AM, Jie Deng wrote: Hi Peppe, On 2016/12/12 22:17, Giuseppe CAVALLARO wrote: Hi David On 12/7/2016 7:06 PM, David Miller wrote: Giuseppe and Alexandre, There are a lot of patches and discussions happening around the stammc driver lately and both of you are listed as the maintainers. I really need prompt and conclusive reviews of these patch submissions from you, and participation in all discussions about the driver. yes we are trying to do the best. Otherwise I have only three things I can do: 1) let the patches rot in patchwork for days 2) trust that the patches are sane and fit your desires and goals and just apply them or 3) reject them since they aren't being reviewed properly. at this stage, I think the best is: (3). I think the patches David mentioned also included XLGMAC. He sent this email before I explained QoS and XLGMAC were different IPs. Do you mind we do XLGMAC development under drivers/net/ethernet/synopsys/ ? I think we don't have conflict since we will keep QoS development in stmmac. Great. Many thanks for the clarification :-) Regards Peppe Thanks in advance. you are welcome Peppe
Re: stmmac driver...
Hi David, Giuseppe and Alexandre, There are a lot of patches and discussions happening around the stammc driver lately and both of you are listed as the maintainers. I really need prompt and conclusive reviews of these patch submissions from you, and participation in all discussions about the driver. >>> >>> yes we are trying to do the best. >>> Otherwise I have only three things I can do: 1) let the patches rot in patchwork for days 2) trust that the patches are sane and fit your desires and goals and just apply them or 3) reject them since they aren't being reviewed properly. >>> >>> at this stage, I think the best is: (3). >> I think the patches David mentioned also included XLGMAC. He sent this email >> before I explained QoS and XLGMAC were different IPs. Do you mind we do >> XLGMAC >> development under drivers/net/ethernet/synopsys/ ? I think we don't have >> conflict since we will keep QoS development in stmmac. > > Great. Many thanks for the clarification :-) > > Regards > Peppe > Do you agree that we do XLGMAC development under drivers/net/ethernet/synopsys/ in the future ? There is no conflict of interest since this is a new IP without driver. As you see, there are several drivers for QoS (GMAC) and several drivers for XGMAC. We want to avoid this situation for the new IP XLGMAC. Regards, Jie
Re: stmmac driver...
Hi Peppe, On 2016/12/12 22:17, Giuseppe CAVALLARO wrote: > Hi David > > On 12/7/2016 7:06 PM, David Miller wrote: >> >> Giuseppe and Alexandre, >> >> There are a lot of patches and discussions happening around the stammc >> driver lately and both of you are listed as the maintainers. >> >> I really need prompt and conclusive reviews of these patch submissions >> from you, and participation in all discussions about the driver. > > yes we are trying to do the best. > >> Otherwise I have only three things I can do: 1) let the patches rot in >> patchwork for days 2) trust that the patches are sane and fit your >> desires and goals and just apply them or 3) reject them since they >> aren't being reviewed properly. > > at this stage, I think the best is: (3). I think the patches David mentioned also included XLGMAC. He sent this email before I explained QoS and XLGMAC were different IPs. Do you mind we do XLGMAC development under drivers/net/ethernet/synopsys/ ? I think we don't have conflict since we will keep QoS development in stmmac. > >> >> Thanks in advance. >> > you are welcome > > > Peppe
Re: stmmac driver...
Hi David On 12/7/2016 7:06 PM, David Miller wrote: Giuseppe and Alexandre, There are a lot of patches and discussions happening around the stammc driver lately and both of you are listed as the maintainers. I really need prompt and conclusive reviews of these patch submissions from you, and participation in all discussions about the driver. yes we are trying to do the best. Otherwise I have only three things I can do: 1) let the patches rot in patchwork for days 2) trust that the patches are sane and fit your desires and goals and just apply them or 3) reject them since they aren't being reviewed properly. at this stage, I think the best is: (3). Thanks in advance. you are welcome Peppe
Re: Re: stmmac driver...
(resend with netdev included) On 12/09/2016 05:29 PM, Jie Deng wrote: > > On 2016/12/9 18:50, Niklas Cassel wrote: >> Hello Jie Deng >> >> >> In your cover letter you wrote >> >> dwc-eth-xxx.x >> The DWC ethernet core layer (DWC ECL). This layer contains codes >> can be shared by different DWC series ethernet cores >> >> Does this mean that code in dwc-eth-xxx.x is common to all >> the different Synopsys IPs, GMAC, XGMAC and XLGMAC ? >> >> >> Regards, >> Niklas > Yeah, these codes may be reused in the future (due to HW similarities) but it > would require a lot of refactoring. For the moment I will focus on the driver > only for XLGMAC. Ok, thank you for the clarification. > > XLGMAC is Synopsys "Enterprise MAC" controller (the product is already > public): > https://www.synopsys.com/dw/ipdir.php?ds=dwc_ether_enterprise_mac > > What do you think following strategy: > - GMAC (QoS): discard drivers/net/ethernet/synopsys/dwc_eth_qos.c and keep > development under drivers/net/ethernet/stmicro/stmmac/ > - XGMAC: keep development under drivers/net/ethernet/amd/xgbe/ > - XLGMAC: do development under drivers/net/ethernet/synopsys/ I don't have an opinion regarding XLGMAC. For GMAC, I think it's a good idea that everybody focuses on the same driver (stmmac). The same thing applies to XGMAC, amd-xgbe and sxgbe, however there I don't know of any consolidation efforts. > > Thanks, > Jie > >> On Fri, Dec 9, 2016 at 11:05 AM, Jie Deng wrote: >>> On 2016/12/8 23:25, David Miller wrote: >>>> From: Alexandre Torgue >>>> Date: Thu, 8 Dec 2016 14:55:04 +0100 >>>> >>>>> Maybe I forget some series. Do you have others in mind ? >>>> Please see the thread titled: >>>> >>>> "net: ethernet: Initial driver for Synopsys DWC XLGMAC" >>>> >>>> which seems to be discussing consolidation of various drivers >>>> for the same IP core, of which stmmac is one. >>>> >>>> I personally am against any change of the driver name and >>>> things like this, and wish the people doing that work would >>>> simply contribute to making whatever changes they need directly >>>> to the stmmac driver. >>>> >>>> You really need to voice your opinion when major changes are being >>>> proposed for the driver you maintain. >>>> >>> Hi David and Alex, >>> >>> XLGMAC is not a version of GMAC. Synopsys has several IPs and each IP has >>> several versions. >>> >>> GMAC(QoS): 3.5, 3.7, 4.0, 4.10, 4.20... >>> XGMAC: 1.00, 1.10, 1.20, 2.00, 2.10, 2.11... >>> XLGMAC (Synopsys DesignWare Core Enterprise Ethernet): this is a new IP. >>> >>> Regards, >>> Jie >>> >
Re: stmmac driver...
Hello Jie Deng In your cover letter you wrote dwc-eth-xxx.x The DWC ethernet core layer (DWC ECL). This layer contains codes can be shared by different DWC series ethernet cores Does this mean that code in dwc-eth-xxx.x is common to all the different Synopsys IPs, GMAC, XGMAC and XLGMAC ? Regards, Niklas On Fri, Dec 9, 2016 at 11:05 AM, Jie Deng wrote: > > > On 2016/12/8 23:25, David Miller wrote: >> From: Alexandre Torgue >> Date: Thu, 8 Dec 2016 14:55:04 +0100 >> >>> Maybe I forget some series. Do you have others in mind ? >> Please see the thread titled: >> >> "net: ethernet: Initial driver for Synopsys DWC XLGMAC" >> >> which seems to be discussing consolidation of various drivers >> for the same IP core, of which stmmac is one. >> >> I personally am against any change of the driver name and >> things like this, and wish the people doing that work would >> simply contribute to making whatever changes they need directly >> to the stmmac driver. >> >> You really need to voice your opinion when major changes are being >> proposed for the driver you maintain. >> > Hi David and Alex, > > XLGMAC is not a version of GMAC. Synopsys has several IPs and each IP has > several versions. > > GMAC(QoS): 3.5, 3.7, 4.0, 4.10, 4.20... > XGMAC: 1.00, 1.10, 1.20, 2.00, 2.10, 2.11... > XLGMAC (Synopsys DesignWare Core Enterprise Ethernet): this is a new IP. > > Regards, > Jie >
Re: stmmac driver...
On 2016/12/8 23:25, David Miller wrote: > From: Alexandre Torgue > Date: Thu, 8 Dec 2016 14:55:04 +0100 > >> Maybe I forget some series. Do you have others in mind ? > Please see the thread titled: > > "net: ethernet: Initial driver for Synopsys DWC XLGMAC" > > which seems to be discussing consolidation of various drivers > for the same IP core, of which stmmac is one. > > I personally am against any change of the driver name and > things like this, and wish the people doing that work would > simply contribute to making whatever changes they need directly > to the stmmac driver. > > You really need to voice your opinion when major changes are being > proposed for the driver you maintain. > Hi David and Alex, XLGMAC is not a version of GMAC. Synopsys has several IPs and each IP has several versions. GMAC(QoS): 3.5, 3.7, 4.0, 4.10, 4.20... XGMAC: 1.00, 1.10, 1.20, 2.00, 2.10, 2.11... XLGMAC (Synopsys DesignWare Core Enterprise Ethernet): this is a new IP. Regards, Jie
Re: stmmac driver...
On 12/08/2016 04:25 PM, David Miller wrote: From: Alexandre Torgue Date: Thu, 8 Dec 2016 14:55:04 +0100 Maybe I forget some series. Do you have others in mind ? Please see the thread titled: "net: ethernet: Initial driver for Synopsys DWC XLGMAC" which seems to be discussing consolidation of various drivers for the same IP core, of which stmmac is one. I personally am against any change of the driver name and things like this, and wish the people doing that work would simply contribute to making whatever changes they need directly to the stmmac driver. You really need to voice your opinion when major changes are being proposed for the driver you maintain. For sure I agree. I miss this one as it doesn't modify (yet) stmmac driver. I gonna respond to the thread; Regards Alex
Re: stmmac driver...
From: Alexandre Torgue Date: Thu, 8 Dec 2016 14:55:04 +0100 > Maybe I forget some series. Do you have others in mind ? Please see the thread titled: "net: ethernet: Initial driver for Synopsys DWC XLGMAC" which seems to be discussing consolidation of various drivers for the same IP core, of which stmmac is one. I personally am against any change of the driver name and things like this, and wish the people doing that work would simply contribute to making whatever changes they need directly to the stmmac driver. You really need to voice your opinion when major changes are being proposed for the driver you maintain.
Re: stmmac driver...
Hi David, On 12/07/2016 07:06 PM, David Miller wrote: Giuseppe and Alexandre, There are a lot of patches and discussions happening around the stammc driver lately and both of you are listed as the maintainers. I really need prompt and conclusive reviews of these patch submissions from you, and participation in all discussions about the driver. Otherwise I have only three things I can do: 1) let the patches rot in patchwork for days 2) trust that the patches are sane and fit your desires and goals and just apply them or 3) reject them since they aren't being reviewed properly. Sorry for the delay. I reviewed Niklas series this morning. I'm testing "net: ethernet: stmmac: remove private tx queue lock". Maybe I forget some series. Do you have others in mind ? Regards Alex Thanks in advance.
stmmac driver...
Giuseppe and Alexandre, There are a lot of patches and discussions happening around the stammc driver lately and both of you are listed as the maintainers. I really need prompt and conclusive reviews of these patch submissions from you, and participation in all discussions about the driver. Otherwise I have only three things I can do: 1) let the patches rot in patchwork for days 2) trust that the patches are sane and fit your desires and goals and just apply them or 3) reject them since they aren't being reviewed properly. Thanks in advance.
Re: [RESEND PATCH net-next 00/13] Enhance stmmac driver to support GMAC4.x IP
From: Alexandre TORGUE Date: Fri, 1 Apr 2016 11:37:24 +0200 > This is a subset of patch to enhance current stmmac driver to support > new GMAC4.x chips. New set of callbacks is defined to support this new > family: descriptors, dma, core. Series applied, thanks.
[RESEND PATCH net-next 00/13] Enhance stmmac driver to support GMAC4.x IP
This is a subset of patch to enhance current stmmac driver to support new GMAC4.x chips. New set of callbacks is defined to support this new family: descriptors, dma, core. One of main changes of GMAC 4.xx IP is descriptors management. -descriptors are only used in ring mode. -A descriptor is composed of 4 32bits registers (no more extended descriptors) -descriptor mechanism (Tx for example, but it is exactly the same for RX): -useful registers: -DMA_CH#_TxDesc_Ring_Len: length of transmit descriptor ring -DMA_CH#_TxDesc_List_Address: start address of the ring -DMA_CH#_TxDesc_Tail_Pointer: address of the last descriptor to send + 1. -DMA_CH#_TxDesc_Current_App_TxDesc: address of the current descriptor -The descriptor Tail Pointer register contains the pointer to the descriptor address (N). The base address and the current descriptor decide the address of the current descriptor that the DMA can process. The descriptors up to one location less than the one indicated by the descriptor tail pointer (N-1) are owned by the DMA. The DMA continues to process the descriptors until the following condition occurs: "current descriptor pointer == Descriptor Tail pointer" Then the DMA goes into suspend mode. The application must perform a write to descriptor tail pointer register and update the tail pointer to have the following condition and to start a new transfer: "current descriptor pointer < Descriptor tail pointer" The DMA automatically wraps around the base address when the end of ring is reached. New features are available on IP: -TSO (TCP Segmentation Offload) for TX only -Split header: to have header and payload in 2 different buffers (not yet implemented) Below some throughput figures obtained on some boxes: iperf (mbps) -- tcp udp tx rx tx rx - GMAC4.x 935 930 750 800 Note: There is a change in 4.10a databook on bitfield mapping of DMA_CHANx_INTR_ENA register. This requires to have � diffrent set of callbacks between IP 4.00a and 4.10a. Best regards Alex I'm resending this series because first sending was badly done during merge window. Alexandre TORGUE (13): stmmac: rework get_hw_feature function stmmac: rework the routines to show the ring status stmmac: rework synopsys id read, moved to dwmac setup stmmac: add descriptors function for GMAC 4.xx stmmac: add GMAC4 DMA/CORE Header File stmmac: add DMA support for GMAC 4.xx stmmac: add GMAC4 core support stmmac: enhance mmc counter management stmmac: add new DT platform entries for GMAC4 stmmac: support new GMAC4 Documentation: networking: update stmmac stmmac: update version to Jan_2016 stmmac: update MAINTAINERS Documentation/devicetree/bindings/net/stmmac.txt | 2 + Documentation/networking/stmmac.txt| 44 +- MAINTAINERS| 1 + drivers/net/ethernet/stmicro/stmmac/Makefile | 3 +- drivers/net/ethernet/stmicro/stmmac/common.h | 64 +- .../net/ethernet/stmicro/stmmac/dwmac1000_core.c | 7 +- .../net/ethernet/stmicro/stmmac/dwmac1000_dma.c| 35 +- .../net/ethernet/stmicro/stmmac/dwmac100_core.c| 5 +- drivers/net/ethernet/stmicro/stmmac/dwmac4.h | 255 drivers/net/ethernet/stmicro/stmmac/dwmac4_core.c | 407 + drivers/net/ethernet/stmicro/stmmac/dwmac4_descs.c | 396 + drivers/net/ethernet/stmicro/stmmac/dwmac4_descs.h | 129 + drivers/net/ethernet/stmicro/stmmac/dwmac4_dma.c | 354 drivers/net/ethernet/stmicro/stmmac/dwmac4_dma.h | 202 +++ drivers/net/ethernet/stmicro/stmmac/dwmac4_lib.c | 225 +++ drivers/net/ethernet/stmicro/stmmac/enh_desc.c | 21 + drivers/net/ethernet/stmicro/stmmac/mmc.h | 4 + drivers/net/ethernet/stmicro/stmmac/mmc_core.c | 349 +-- drivers/net/ethernet/stmicro/stmmac/norm_desc.c| 21 + drivers/net/ethernet/stmicro/stmmac/stmmac.h | 7 +- .../net/ethernet/stmicro/stmmac/stmmac_ethtool.c | 7 +- drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 643 +++-- .../net/ethernet/stmicro/stmmac/stmmac_platform.c | 7 + include/linux/stmmac.h | 2 + 24 files changed, 2821 insertions(+), 369 deletions(-) create mode 100644 drivers/net/ethernet/stmicro/stmmac/dwmac4.h create mode 100644 drivers/net/ethernet/stmicro/stmmac/dwmac4_core.c create mode 100644 drivers/net/ethernet/stmicro/stmmac/dwmac4_descs.c create mode 100644 drivers/net/ethernet/stmicro/stmmac/dwmac4_descs.h create mode 100644 drivers/net/ethernet/stmicro/stmmac/dwmac4_dma.c create mode 100644 drivers/net/ethernet/stmicro/stmmac/dwmac4_dma.h create mode 100644 drivers/net/ethernet/stmicro/stmmac/dwmac4_lib.c -- 1.9.1
Re: [PATCH 00/13] Enhance stmmac driver to support GMAC4.x IP
Hi, On 03/25/2016 04:11 PM, David Miller wrote: It is absolutely not appropriate to submit new feature patches at this time. Please resubmit this after the net-next tree opens back out. No pb, I will wait and resend. Regards Alex Thank you.
Re: [PATCH 00/13] Enhance stmmac driver to support GMAC4.x IP
It is absolutely not appropriate to submit new feature patches at this time. Please resubmit this after the net-next tree opens back out. Thank you.
[PATCH 00/13] Enhance stmmac driver to support GMAC4.x IP
This is a subset of patch to enhance current stmmac driver to support new GMAC4.x chips. New set of callbacks is defined to support this new family: descriptors, dma, core. One of main changes of GMAC 4.xx IP is descriptors management. -descriptors are only used in ring mode. -A descriptor is composed of 4 32bits registers (no more extended descriptors) -descriptor mechanism (Tx for example, but it is exactly the same for RX): -useful registers: -DMA_CH#_TxDesc_Ring_Len: length of transmit descriptor ring -DMA_CH#_TxDesc_List_Address: start address of the ring -DMA_CH#_TxDesc_Tail_Pointer: address of the last descriptor to send + 1. -DMA_CH#_TxDesc_Current_App_TxDesc: address of the current descriptor -The descriptor Tail Pointer register contains the pointer to the descriptor address (N). The base address and the current descriptor decide the address of the current descriptor that the DMA can process. The descriptors up to one location less than the one indicated by the descriptor tail pointer (N-1) are owned by the DMA. The DMA continues to process the descriptors until the following condition occurs: "current descriptor pointer == Descriptor Tail pointer" Then the DMA goes into suspend mode. The application must perform a write to descriptor tail pointer register and update the tail pointer to have the following condition and to start a new transfer: "current descriptor pointer < Descriptor tail pointer" The DMA automatically wraps around the base address when the end of ring is reached. New features are available on IP: -TSO (TCP Segmentation Offload) for TX only -Split header: to have header and payload in 2 different buffers (not yet implemented) Below some throughput figures obtained on some boxes: iperf (mbps) -- tcp udp tx rx tx rx - GMAC4.x 935 930 750 800 Note: There is a change in 4.10a databook on bitfield mapping of DMA_CHANx_INTR_ENA register. This requires to have � diffrent set of callbacks between IP 4.00a and 4.10a. Best regards Alex Alexandre TORGUE (13): stmmac: rework get_hw_feature function stmmac: rework the routines to show the ring status stmmac: rework synopsys id read, moved to dwmac setup stmmac: add descriptors function for GMAC 4.xx stmmac: add GMAC4 DMA/CORE Header File stmmac: add DMA support for GMAC 4.xx stmmac: add GMAC4 core support stmmac: enhance mmc counter management stmmac: add new DT platform entries for GMAC4 stmmac: support new GMAC4 Documentation: networking: update stmmac stmmac: update version to Jan_2016 stmmac: update MAINTAINERS Documentation/devicetree/bindings/net/stmmac.txt | 2 + Documentation/networking/stmmac.txt| 44 +- MAINTAINERS| 1 + drivers/net/ethernet/stmicro/stmmac/Makefile | 3 +- drivers/net/ethernet/stmicro/stmmac/common.h | 64 +- .../net/ethernet/stmicro/stmmac/dwmac1000_core.c | 7 +- .../net/ethernet/stmicro/stmmac/dwmac1000_dma.c| 35 +- .../net/ethernet/stmicro/stmmac/dwmac100_core.c| 5 +- drivers/net/ethernet/stmicro/stmmac/dwmac4.h | 255 drivers/net/ethernet/stmicro/stmmac/dwmac4_core.c | 407 + drivers/net/ethernet/stmicro/stmmac/dwmac4_descs.c | 396 + drivers/net/ethernet/stmicro/stmmac/dwmac4_descs.h | 129 + drivers/net/ethernet/stmicro/stmmac/dwmac4_dma.c | 354 drivers/net/ethernet/stmicro/stmmac/dwmac4_dma.h | 202 +++ drivers/net/ethernet/stmicro/stmmac/dwmac4_lib.c | 225 +++ drivers/net/ethernet/stmicro/stmmac/enh_desc.c | 21 + drivers/net/ethernet/stmicro/stmmac/mmc.h | 4 + drivers/net/ethernet/stmicro/stmmac/mmc_core.c | 349 +-- drivers/net/ethernet/stmicro/stmmac/norm_desc.c| 21 + drivers/net/ethernet/stmicro/stmmac/stmmac.h | 7 +- .../net/ethernet/stmicro/stmmac/stmmac_ethtool.c | 7 +- drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 643 +++-- .../net/ethernet/stmicro/stmmac/stmmac_platform.c | 7 + include/linux/stmmac.h | 2 + 24 files changed, 2821 insertions(+), 369 deletions(-) create mode 100644 drivers/net/ethernet/stmicro/stmmac/dwmac4.h create mode 100644 drivers/net/ethernet/stmicro/stmmac/dwmac4_core.c create mode 100644 drivers/net/ethernet/stmicro/stmmac/dwmac4_descs.c create mode 100644 drivers/net/ethernet/stmicro/stmmac/dwmac4_descs.h create mode 100644 drivers/net/ethernet/stmicro/stmmac/dwmac4_dma.c create mode 100644 drivers/net/ethernet/stmicro/stmmac/dwmac4_dma.h create mode 100644 drivers/net/ethernet/stmicro/stmmac/dwmac4_lib.c -- 1.9.1
Re: [v6,1/4] stmmac: create of compatible mdio bus for stmmac driver
Hi all,
I work on STih410B2120 board and i have a regression since this patch
(eth0: No PHY found)
My configuration is an Ethernet MAC with a "fixed link", and not
connected to a normal MDIO-managed PHY device.
Please find my remark below.
On 12/14/2015 04:31 AM, Phil Reid wrote:
The DSA driver needs to be passed a reference to an mdio bus. Typically
the mac is configured to use a fixed link but the mdio bus still needs
to be registered so that it con configure the switch.
This patch follows the same process as the altera tse ethernet driver for
creation of the mdio bus.
Acked-by: Rob Herring
Signed-off-by: Phil Reid
---
Documentation/devicetree/bindings/net/stmmac.txt | 8 +++
drivers/net/ethernet/stmicro/stmmac/stmmac_mdio.c | 26 +++---
.../net/ethernet/stmicro/stmmac/stmmac_platform.c | 2 +-
3 files changed, 32 insertions(+), 4 deletions(-)
diff --git a/Documentation/devicetree/bindings/net/stmmac.txt
b/Documentation/devicetree/bindings/net/stmmac.txt
index f34fc3c..fd5ddf8 100644
--- a/Documentation/devicetree/bindings/net/stmmac.txt
+++ b/Documentation/devicetree/bindings/net/stmmac.txt
@@ -47,6 +47,7 @@ Optional properties:
- snps,burst_len: The AXI burst lenth value of the AXI BUS MODE register.
- tx-fifo-depth: See ethernet.txt file in the same directory
- rx-fifo-depth: See ethernet.txt file in the same directory
+- mdio: with compatible = "snps,dwmac-mdio", create and register mdio bus.
Examples:
@@ -65,4 +66,11 @@ Examples:
tx-fifo-depth = <16384>;
clocks = <&clock>;
clock-names = "stmmaceth";
+ mdio0 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ compatible = "snps,dwmac-mdio";
+ phy1: ethernet-phy@0 {
+ };
+ };
};
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_mdio.c
b/drivers/net/ethernet/stmicro/stmmac/stmmac_mdio.c
index bba670c..16c85cc 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_mdio.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_mdio.c
@@ -29,7 +29,7 @@
#include
#include
#include
-
+#include
#include
#include "stmmac.h"
@@ -200,10 +200,29 @@ int stmmac_mdio_register(struct net_device *ndev)
struct stmmac_priv *priv = netdev_priv(ndev);
struct stmmac_mdio_bus_data *mdio_bus_data = priv->plat->mdio_bus_data;
int addr, found;
+ struct device_node *mdio_node = NULL;
+ struct device_node *child_node = NULL;
if (!mdio_bus_data)
return 0;
+ if (IS_ENABLED(CONFIG_OF)) {
+ for_each_child_of_node(priv->device->of_node, child_node) {
+ if (of_device_is_compatible(child_node,
+ "snps,dwmac-mdio")) {
+ mdio_node = child_node;
+ break;
+ }
+ }
+
+ if (mdio_node) {
+ netdev_dbg(ndev, "FOUND MDIO subnode\n");
+ } else {
+ netdev_err(ndev, "NO MDIO subnode\n");
+ return 0;
+ }
+ }
+
new_bus = mdiobus_alloc();
if (new_bus == NULL)
return -ENOMEM;
@@ -231,7 +250,8 @@ int stmmac_mdio_register(struct net_device *ndev)
new_bus->irq = irqlist;
new_bus->phy_mask = mdio_bus_data->phy_mask;
new_bus->parent = priv->device;
- err = mdiobus_register(new_bus);
+
+ err = of_mdiobus_register(new_bus, mdio_node);
if (err != 0) {
pr_err("%s: Cannot register as MDIO bus\n", new_bus->name);
goto bus_register_fail;
@@ -284,7 +304,7 @@ int stmmac_mdio_register(struct net_device *ndev)
}
}
- if (!found) {
+ if (!found && !mdio_node) {
pr_warn("%s: No PHY found\n", ndev->name);
mdiobus_unregister(new_bus);
mdiobus_free(new_bus);
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
b/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
index d02691b..6a52fa1 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
@@ -146,7 +146,7 @@ stmmac_probe_config_dt(struct platform_device *pdev, const
char **mac)
if (of_property_read_u32(np, "snps,phy-addr", &plat->phy_addr) == 0)
dev_warn(&pdev->dev, "snps,phy-addr property is deprecated\n");
- if (plat->phy_node || plat->phy_bus_name)
+ if ((plat->phy_node && !of_phy_is_fixed_link(np)) || plat->phy_bus_name)
plat->mdio_bus_data = NULL;
else
plat->mdio_bus_data =
It's impossible for me now to enter in the case "plat->mdio_bus_data =
NULL;"
Due to the test of "&& !of_phy_is_fixed_link(np)
[PATCH v6 1/4] stmmac: create of compatible mdio bus for stmmac driver
The DSA driver needs to be passed a reference to an mdio bus. Typically
the mac is configured to use a fixed link but the mdio bus still needs
to be registered so that it con configure the switch.
This patch follows the same process as the altera tse ethernet driver for
creation of the mdio bus.
Acked-by: Rob Herring
Signed-off-by: Phil Reid
---
Documentation/devicetree/bindings/net/stmmac.txt | 8 +++
drivers/net/ethernet/stmicro/stmmac/stmmac_mdio.c | 26 +++---
.../net/ethernet/stmicro/stmmac/stmmac_platform.c | 2 +-
3 files changed, 32 insertions(+), 4 deletions(-)
diff --git a/Documentation/devicetree/bindings/net/stmmac.txt
b/Documentation/devicetree/bindings/net/stmmac.txt
index f34fc3c..fd5ddf8 100644
--- a/Documentation/devicetree/bindings/net/stmmac.txt
+++ b/Documentation/devicetree/bindings/net/stmmac.txt
@@ -47,6 +47,7 @@ Optional properties:
- snps,burst_len: The AXI burst lenth value of the AXI BUS MODE register.
- tx-fifo-depth: See ethernet.txt file in the same directory
- rx-fifo-depth: See ethernet.txt file in the same directory
+- mdio: with compatible = "snps,dwmac-mdio", create and register mdio bus.
Examples:
@@ -65,4 +66,11 @@ Examples:
tx-fifo-depth = <16384>;
clocks = <&clock>;
clock-names = "stmmaceth";
+ mdio0 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ compatible = "snps,dwmac-mdio";
+ phy1: ethernet-phy@0 {
+ };
+ };
};
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_mdio.c
b/drivers/net/ethernet/stmicro/stmmac/stmmac_mdio.c
index bba670c..16c85cc 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_mdio.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_mdio.c
@@ -29,7 +29,7 @@
#include
#include
#include
-
+#include
#include
#include "stmmac.h"
@@ -200,10 +200,29 @@ int stmmac_mdio_register(struct net_device *ndev)
struct stmmac_priv *priv = netdev_priv(ndev);
struct stmmac_mdio_bus_data *mdio_bus_data = priv->plat->mdio_bus_data;
int addr, found;
+ struct device_node *mdio_node = NULL;
+ struct device_node *child_node = NULL;
if (!mdio_bus_data)
return 0;
+ if (IS_ENABLED(CONFIG_OF)) {
+ for_each_child_of_node(priv->device->of_node, child_node) {
+ if (of_device_is_compatible(child_node,
+ "snps,dwmac-mdio")) {
+ mdio_node = child_node;
+ break;
+ }
+ }
+
+ if (mdio_node) {
+ netdev_dbg(ndev, "FOUND MDIO subnode\n");
+ } else {
+ netdev_err(ndev, "NO MDIO subnode\n");
+ return 0;
+ }
+ }
+
new_bus = mdiobus_alloc();
if (new_bus == NULL)
return -ENOMEM;
@@ -231,7 +250,8 @@ int stmmac_mdio_register(struct net_device *ndev)
new_bus->irq = irqlist;
new_bus->phy_mask = mdio_bus_data->phy_mask;
new_bus->parent = priv->device;
- err = mdiobus_register(new_bus);
+
+ err = of_mdiobus_register(new_bus, mdio_node);
if (err != 0) {
pr_err("%s: Cannot register as MDIO bus\n", new_bus->name);
goto bus_register_fail;
@@ -284,7 +304,7 @@ int stmmac_mdio_register(struct net_device *ndev)
}
}
- if (!found) {
+ if (!found && !mdio_node) {
pr_warn("%s: No PHY found\n", ndev->name);
mdiobus_unregister(new_bus);
mdiobus_free(new_bus);
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
b/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
index d02691b..6a52fa1 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
@@ -146,7 +146,7 @@ stmmac_probe_config_dt(struct platform_device *pdev, const
char **mac)
if (of_property_read_u32(np, "snps,phy-addr", &plat->phy_addr) == 0)
dev_warn(&pdev->dev, "snps,phy-addr property is deprecated\n");
- if (plat->phy_node || plat->phy_bus_name)
+ if ((plat->phy_node && !of_phy_is_fixed_link(np)) || plat->phy_bus_name)
plat->mdio_bus_data = NULL;
else
plat->mdio_bus_data =
--
1.8.3.1
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
