From: Stefan Chulski <redacted>
Armada hardware has a pause generation mechanism in GOP (MAC).
GOP has to generate flow control frames based on an indication
programmed in Ports Control 0 Register. There is a bit per port.
However assertion of the PortX Pause bits in the ports control 0 register
only sends a one time pause. To complement the function the GOP has
a mechanism to periodically send pause control messages based on periodic counters.
This mechanism ensures that the pause is effective as long as the Appropriate PortX Pause
is asserted.
Problem is that Packet Processor witch actually can drop packets due to lack of resources
not connected to the GOP flow control generation mechanism.
To solve this issue Armada has firmware running on CM3 CPU dedectated for Flow Control
support. Firmware monitors Packet Processor resources and asserts XON/XOFF by writing
to Ports Control 0 Register.
MSS shared memory used to communicate between CM3 firmware and MVPP2 driver.
During init MVPP2 driver informs firmware about used BM pools, RXQs and congestion and
depletion thresholds.
The pause is generated whenever congestion or depletion in resources is detected.
The back pressure is stopped when the resource reaches a sufficient level.
So the congestion/depletion and sufficient implement a hysteresis mechanism that
reduces the toggle frequency.
For buffer pools which are a depletion means that a pause frame should be generated.
For this the SW needs to poll BPPINumberOfPointers and BPPENumberOfPoint. For queues
congestion means that a pause frame should be generated. For this the SW
needs to poll OccupiedDescriptorsCounter.
Packet Processor v23 has hardware support to monitor FIFO fill level.
patch "add PPv23 version definition" to differ between v23 and v22 hardware.
Patch "add TX FC firmware check" verifies that CM3 firmware support Flow Control
monitoring.
Konstantin Porotchkin (1):
dts: marvell: add CM3 SRAM memory to cp115 ethernet device tree
Stefan Chulski (18):
doc: marvell: add cm3-mem device tree bindings description
net: mvpp2: add CM3 SRAM memory map
net: mvpp2: add PPv23 version definition
net: mvpp2: always compare hw-version vs MVPP21
net: mvpp2: increase BM pool size to 2048 buffers
net: mvpp2: increase RXQ size to 1024 descriptors
net: mvpp2: add FCA periodic timer configurations
net: mvpp2: add FCA RXQ non occupied descriptor threshold
net: mvpp2: add spinlock for FW FCA configuration path
net: mvpp2: add flow control RXQ and BM pool config callbacks
net: mvpp2: enable global flow control
net: mvpp2: add RXQ flow control configurations
net: mvpp2: add ethtool flow control configuration support
net: mvpp2: add BM protection underrun feature support
net: mvpp2: add PPv23 RX FIFO flow control
net: mvpp2: set 802.3x GoP Flow Control mode
net: mvpp2: add ring size validation before enabling FC
net: mvpp2: add TX FC firmware check
Documentation/devicetree/bindings/net/marvell-pp2.txt | 1 +
arch/arm64/boot/dts/marvell/armada-cp11x.dtsi | 10 +
drivers/net/ethernet/marvell/mvpp2/mvpp2.h | 130 ++++-
drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c | 570 +++++++++++++++++++-
4 files changed, 669 insertions(+), 42 deletions(-)
--
1.9.1
@@ -37,6 +37,7 @@ Required properties (port): GOP (Group Of Ports) point of view. This ID is used to index the per-port registers in the second register area. - phy-mode: See ethernet.txt file in the same directory+- cm3-mem: phandle to CM3 SRAM definitions Optional properties (port):
From: Konstantin Porotchkin <redacted>
CM3 SRAM address space would be used for Flow Control configuration.
Signed-off-by: Stefan Chulski <redacted>
---
arch/arm64/boot/dts/marvell/armada-cp11x.dtsi | 10 ++++++++++
1 file changed, 10 insertions(+)
@@ -925,6 +928,7 @@ struct mvpp2 {/* Shared registers' base addresses */void__iomem*lms_base;void__iomem*iface_base;+void__iomem*cm3_base;/* On PPv2.2, each "software thread" can access the base*registerthroughaseparateaddressspace,each64KBapart
@@ -6848,6 +6861,35 @@ static int mvpp2_init(struct platform_device *pdev, struct mvpp2 *priv)return0;}+staticintmvpp2_get_sram(structplatform_device*pdev,+structmvpp2*priv)+{+structdevice_node*dn=pdev->dev.of_node;+structresource*res;++if(has_acpi_companion(&pdev->dev)){+res=platform_get_resource(pdev,IORESOURCE_MEM,2);+if(!res){+dev_warn(&pdev->dev,"ACPI is too old, TX FC disabled\n");+return0;+}+priv->cm3_base=devm_ioremap_resource(&pdev->dev,res);+if(IS_ERR(priv->cm3_base))+returnPTR_ERR(priv->cm3_base);+}else{+priv->sram_pool=of_gen_pool_get(dn,"cm3-mem",0);+if(!priv->sram_pool){+dev_warn(&pdev->dev,"DT is too old, TX FC disabled\n");+return0;+}+priv->cm3_base=(void__iomem*)gen_pool_alloc(priv->sram_pool,+MSS_SRAM_SIZE);+if(!priv->cm3_base)+return-ENOMEM;+}+return0;+}+staticintmvpp2_probe(structplatform_device*pdev){conststructacpi_device_id*acpi_id;
@@ -6904,6 +6946,11 @@ static int mvpp2_probe(struct platform_device *pdev)priv->iface_base=devm_ioremap_resource(&pdev->dev,res);if(IS_ERR(priv->iface_base))returnPTR_ERR(priv->iface_base);++/* Map CM3 SRAM */+err=mvpp2_get_sram(pdev,priv);+if(err)+dev_warn(&pdev->dev,"Fail to alloc CM3 SRAM\n");}if(priv->hw_version==MVPP22&&dev_of_node(&pdev->dev)){
@@ -6949,11 +6996,13 @@ static int mvpp2_probe(struct platform_device *pdev)if(dev_of_node(&pdev->dev)){priv->pp_clk=devm_clk_get(&pdev->dev,"pp_clk");-if(IS_ERR(priv->pp_clk))-returnPTR_ERR(priv->pp_clk);+if(IS_ERR(priv->pp_clk)){+err=PTR_ERR(priv->pp_clk);+gotoerr_cm3;+}err=clk_prepare_enable(priv->pp_clk);if(err<0)-returnerr;+gotoerr_cm3;priv->gop_clk=devm_clk_get(&pdev->dev,"gop_clk");if(IS_ERR(priv->gop_clk)){
@@ -7089,6 +7138,11 @@ static int mvpp2_probe(struct platform_device *pdev)clk_disable_unprepare(priv->gop_clk);err_pp_clk:clk_disable_unprepare(priv->pp_clk);+err_cm3:+if(!has_acpi_companion(&pdev->dev)&&priv->cm3_base)+gen_pool_free(priv->sram_pool,(unsignedlong)priv->cm3_base,+MSS_SRAM_SIZE);+returnerr;}
@@ -7129,6 +7183,12 @@ static int mvpp2_remove(struct platform_device *pdev)aggr_txq->descs_dma);}+if(!has_acpi_companion(&pdev->dev)&&priv->cm3_base){+gen_pool_free(priv->sram_pool,(unsignedlong)priv->cm3_base,+MSS_SRAM_SIZE);+gen_pool_destroy(priv->sram_pool);+}+if(is_acpi_node(port_fwnode))return0;
From: Stefan Chulski <redacted>
This patch add PPv23 version definition.
PPv23 is new packet processor in CP115.
Everything that supported by PPv22, also supported by PPv23.
No functional changes in this stage.
Signed-off-by: Stefan Chulski <redacted>
---
drivers/net/ethernet/marvell/mvpp2/mvpp2.h | 24 ++++++++++++--------
drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c | 17 +++++++++-----
2 files changed, 25 insertions(+), 16 deletions(-)
@@ -469,7 +472,7 @@#define MVPP22_GMAC_INT_SUM_MASK_LINK_STAT BIT(1)#define MVPP22_GMAC_INT_SUM_MASK_PTP BIT(2)-/* Per-port XGMAC registers. PPv2.2 only, only for GOP port 0,+/* Per-port XGMAC registers. PPv2.2 and PPv2.3, only for GOP port 0,*relativetoport->base.*/#define MVPP22_XLG_CTRL0_REG 0x100
@@ -506,7 +509,7 @@#define MVPP22_XLG_CTRL4_MACMODSELECT_GMAC BIT(12)#define MVPP22_XLG_CTRL4_EN_IDLE_CHECK BIT(14)-/* SMI registers. PPv2.2 only, relative to priv->iface_base. */+/* SMI registers. PPv2.2 and PPv2.3, relative to priv->iface_base. */#define MVPP22_SMI_MISC_CFG_REG 0x1204#define MVPP22_SMI_POLLING_EN BIT(10)
@@ -930,15 +933,16 @@ struct mvpp2 {void__iomem*iface_base;void__iomem*cm3_base;-/* On PPv2.2, each "software thread" can access the base+/* On PPv2.2 and PPv2.3, each "software thread" can access the base*registerthroughaseparateaddressspace,each64KBapart*fromeachother.Typically,suchaddressspaceswillbe*usedperCPU.*/void__iomem*swth_base[MVPP2_MAX_THREADS];-/* On PPv2.2, some port control registers are located into the system-*controllerspace.Theseregistersareaccessiblethrougharegmap.+/* On PPv2.2 and PPv2.3, some port control registers are located into+*thesystemcontrollerspace.Theseregistersareaccessible+*througharegmap.*/structregmap*sysctrl_base;
@@ -980,7 +984,7 @@ struct mvpp2 {u32tclk;/* HW version */-enum{MVPP21,MVPP22}hw_version;+enum{MVPP21,MVPP22,MVPP23}hw_version;/* Maximum number of RXQs per port */unsignedintmax_port_rxqs;
@@ -1227,7 +1231,7 @@ struct mvpp21_rx_desc {__le32reserved8;};-/* HW TX descriptor for PPv2.2 */+/* HW TX descriptor for PPv2.2 and PPv2.3 */structmvpp22_tx_desc{__le32command;u8packet_offset;
@@ -1239,7 +1243,7 @@ struct mvpp22_tx_desc {__le64buf_cookie_misc;};-/* HW RX descriptor for PPv2.2 */+/* HW RX descriptor for PPv2.2 and PPv2.3 */structmvpp22_rx_desc{__le32status;__le16reserved1;
@@ -5469,7 +5469,7 @@ static void mvpp2_rx_irqs_setup(struct mvpp2_port *port)return;}-/* Handle the more complicated PPv2.2 case */+/* Handle the more complicated PPv2.2 and PPv2.3 case */for(i=0;i<port->nqvecs;i++){structmvpp2_queue_vector*qv=port->qvecs+i;
@@ -5646,7 +5646,7 @@ static bool mvpp22_port_has_legacy_tx_irqs(struct device_node *port_node,/* Checks if the port dt description has the required Tx interrupts:*-PPv2.1:therearenosuchinterrupts.-*-PPv2.2:+*-PPv2.2andPPv2.3:*-TheoldDTshave:"rx-shared","tx-cpuX"withXin[0...3]*-Thenewoneshave:"hifX"withXin[0..8]*
@@ -6636,7 +6636,7 @@ static void mvpp22_rx_fifo_set_hw(struct mvpp2 *priv, int port, int data_size)mvpp2_write(priv,MVPP2_RX_ATTR_FIFO_SIZE_REG(port),attr_size);}-/* Initialize TX FIFO's: the total FIFO size is 48kB on PPv2.2.+/* Initialize TX FIFO's: the total FIFO size is 48kB on PPv2.2 and PPv2.3.*4kBfixedspacemustbeassignedfortheloopbackport.*Redistributeremainingavialable44kBspaceamongallactiveports.*Guaranteeminimum32kBfor10Gportand8kBforport1,capableof2.5G
@@ -6693,7 +6693,7 @@ static void mvpp22_tx_fifo_set_hw(struct mvpp2 *priv, int port, int size)mvpp2_write(priv,MVPP22_TX_FIFO_THRESH_REG(port),threshold);}-/* Initialize TX FIFO's: the total FIFO size is 19kB on PPv2.2.+/* Initialize TX FIFO's: the total FIFO size is 19kB on PPv2.2 and PPv2.3.*3kBfixedspacemustbeassignedfortheloopbackport.*Redistributeremainingavialable16kBspaceamongallactiveports.*The10Ginterfaceshoulduse10kB(whichismaximumpossiblesize
From: Stefan Chulski <redacted>
BM pool size increased to support Firmware Flow Control.
Minimum depletion thresholds to support FC is 1024 buffers.
BM pool size increased to 2048 to have some 1024 buffers
space between depletion thresholds and BM pool size.
Signed-off-by: Stefan Chulski <redacted>
---
drivers/net/ethernet/marvell/mvpp2/mvpp2.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
From: Stefan Chulski <redacted>
RXQ size increased to support Firmware Flow Control.
Minimum depletion thresholds to support FC is 1024 buffers.
Default set to 1024 descriptors and maximum size to 2048.
Signed-off-by: Stefan Chulski <redacted>
---
drivers/net/ethernet/marvell/mvpp2/mvpp2.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
@@ -715,8 +715,8 @@#define MVPP2_PORT_MAX_RXQ 32/* Max number of Rx descriptors */-#define MVPP2_MAX_RXD_MAX 1024-#define MVPP2_MAX_RXD_DFLT 128+#define MVPP2_MAX_RXD_MAX 2048+#define MVPP2_MAX_RXD_DFLT 1024/* Max number of Tx descriptors */#define MVPP2_MAX_TXD_MAX 2048
From: Stefan Chulski <redacted>
Currently we have PP2v1 and PP2v2 hw-versions, with some different
handlers depending upon condition hw_version = MVPP21/MVPP22.
In a future there will be also PP2v3. Let's use now the generic
"if equal/notEqual MVPP21" for all cases instead of "if MVPP22".
This patch does not change any functionality.
It is not intended to introduce PP2v3.
It just modifies MVPP21/MVPP22 check-condition
bringing it to generic and unified form correct for new-code
introducing and PP2v3 net-next generation.
Signed-off-by: Stefan Chulski <redacted>
---
drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c | 36 ++++++++++----------
1 file changed, 18 insertions(+), 18 deletions(-)
@@ -332,7 +332,7 @@ static int mvpp2_get_nrxqs(struct mvpp2 *priv){unsignedintnrxqs;-if(priv->hw_version==MVPP22&&queue_mode==MVPP2_QDIST_SINGLE_MODE)+if(priv->hw_version!=MVPP21&&queue_mode==MVPP2_QDIST_SINGLE_MODE)return1;/* According to the PPv2.2 datasheet and our experiments on
From: Stefan Chulski <redacted>
RXQ non occupied descriptor threshold would be used by
Flow Control Firmware feature to move to the XOFF mode.
RXQ non occupied threshold would change interrupt cause
that polled by CM3 Firmware.
Actual non occupied interrupt masked and won't trigger interrupt.
Signed-off-by: Stefan Chulski <redacted>
---
drivers/net/ethernet/marvell/mvpp2/mvpp2.h | 3 ++
drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c | 29 ++++++++++++++++++++
2 files changed, 32 insertions(+)
@@ -2406,6 +2416,22 @@ static void mvpp2_txp_max_tx_size_set(struct mvpp2_port *port)}}+/* Routine set the number of non-occupied descriptors threshold that change+*interrupterrorcausepolledbyFWFlowControl+*/+voidmvpp2_set_rxq_free_tresh(structmvpp2_port*port,+structmvpp2_rx_queue*rxq)+{+u32val;++mvpp2_write(port->priv,MVPP2_RXQ_NUM_REG,rxq->id);++val=mvpp2_read(port->priv,MVPP2_RXQ_THRESH_REG);+val&=~MVPP2_RXQ_NON_OCCUPIED_MASK;+val|=MSS_THRESHOLD_STOP<<MVPP2_RXQ_NON_OCCUPIED_OFFSET;+mvpp2_write(port->priv,MVPP2_RXQ_THRESH_REG,val);+}+/* Set the number of packets that will be received before Rx interrupt*willbegeneratedbyHW.*/
@@ -2661,6 +2687,9 @@ static int mvpp2_rxq_init(struct mvpp2_port *port,mvpp2_rx_pkts_coal_set(port,rxq);mvpp2_rx_time_coal_set(port,rxq);+/* Set the number of non occupied descriptors threshold */+mvpp2_set_rxq_free_tresh(port,rxq);+/* Add number of descriptors ready for receiving packets */mvpp2_rxq_status_update(port,rxq->id,0,rxq->size);
From: Stefan Chulski <redacted>
Flow Control periodic timer would be used if port in
XOFF to transmit periodic XOFF frames.
Signed-off-by: Stefan Chulski <redacted>
---
drivers/net/ethernet/marvell/mvpp2/mvpp2.h | 13 +++++-
drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c | 45 ++++++++++++++++++++
2 files changed, 57 insertions(+), 1 deletion(-)
@@ -1293,6 +1293,49 @@ static void mvpp22_gop_init_10gkr(struct mvpp2_port *port)writel(val,mpcs+MVPP22_MPCS_CLK_RESET);}+staticvoidmvpp22_gop_fca_enable_periodic(structmvpp2_port*port,boolen)+{+structmvpp2*priv=port->priv;+void__iomem*fca=priv->iface_base+MVPP22_FCA_BASE(port->gop_id);+u32val;++val=readl(fca+MVPP22_FCA_CONTROL_REG);+val&=~MVPP22_FCA_ENABLE_PERIODIC;+if(en)+val|=MVPP22_FCA_ENABLE_PERIODIC;+writel(val,fca+MVPP22_FCA_CONTROL_REG);+}++staticvoidmvpp22_gop_fca_set_timer(structmvpp2_port*port,u32timer)+{+structmvpp2*priv=port->priv;+void__iomem*fca=priv->iface_base+MVPP22_FCA_BASE(port->gop_id);+u32lsb,msb;++lsb=timer&MVPP22_FCA_REG_MASK;+msb=timer>>MVPP22_FCA_REG_SIZE;++writel(lsb,fca+MVPP22_PERIODIC_COUNTER_LSB_REG);+writel(msb,fca+MVPP22_PERIODIC_COUNTER_MSB_REG);+}++/* Set Flow Control timer x140 faster than pause quanta to ensure that link+*partnerwon'tsendtafficifportinXOFFmode.+*/+staticvoidmvpp22_gop_fca_set_periodic_timer(structmvpp2_port*port)+{+u32timer;++timer=(port->priv->tclk/(USEC_PER_SEC*FC_CLK_DIVIDER))+*FC_QUANTA;++mvpp22_gop_fca_enable_periodic(port,false);++mvpp22_gop_fca_set_timer(port,timer);++mvpp22_gop_fca_enable_periodic(port,true);+}+staticintmvpp22_gop_init(structmvpp2_port*port){structmvpp2*priv=port->priv;
@@ -1337,6 +1380,8 @@ static int mvpp22_gop_init(struct mvpp2_port *port)val|=GENCONF_SOFT_RESET1_GOP;regmap_write(priv->sysctrl_base,GENCONF_SOFT_RESET1,val);+mvpp22_gop_fca_set_periodic_timer(port);+unsupported_conf:return0;
From: Stefan Chulski <redacted>
This patch did not change any functionality.
Added flow control RXQ and BM pool config callbacks that would be
used to configure RXQ and BM pool thresholds.
APIs also will disable/enable RXQ and pool Flow Control polling.
In this stage BM pool and RXQ has same stop/start thresholds
defined in code.
Also there are common thresholds for all RXQs.
Signed-off-by: Stefan Chulski <redacted>
---
drivers/net/ethernet/marvell/mvpp2/mvpp2.h | 51 +++++-
drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c | 169 ++++++++++++++++++++
2 files changed, 216 insertions(+), 4 deletions(-)
@@ -744,6 +744,175 @@ static void *mvpp2_buf_alloc(struct mvpp2_port *port,returndata;}+/* Routine calculate single queue shares address space */+staticintmvpp22_calc_shared_addr_space(structmvpp2_port*port)+{+/* If number of CPU's greater than number of threads, return last+*addressspace+*/+if(num_active_cpus()>=MVPP2_MAX_THREADS)+returnMVPP2_MAX_THREADS-1;++returnnum_active_cpus();+}++/* Routine enable flow control for RXQs conditon */+voidmvpp2_rxq_enable_fc(structmvpp2_port*port)+{+intval,cm3_state,host_id,q;+intfq=port->first_rxq;+unsignedlongflags;++spin_lock_irqsave(&port->priv->mss_spinlock,flags);++/* Remove Flow control enable bit to prevent race between FW and Kernel+*IfFlowcontrolwereenabled,itwouldbere-enabled.+*/+val=mvpp2_cm3_read(port->priv,MSS_FC_COM_REG);+cm3_state=(val&FLOW_CONTROL_ENABLE_BIT);+val&=~FLOW_CONTROL_ENABLE_BIT;+mvpp2_cm3_write(port->priv,MSS_FC_COM_REG,val);++/* Set same Flow control for all RXQs */+for(q=0;q<port->nrxqs;q++){+/* Set stop and start Flow control RXQ thresholds */+val=MSS_THRESHOLD_START;+val|=(MSS_THRESHOLD_STOP<<MSS_RXQ_TRESH_STOP_OFFS);+mvpp2_cm3_write(port->priv,MSS_RXQ_TRESH_REG(q,fq),val);++val=mvpp2_cm3_read(port->priv,MSS_RXQ_ASS_REG(q,fq));+/* Set RXQ port ID */+val&=~(MSS_RXQ_ASS_PORTID_MASK<<MSS_RXQ_ASS_Q_BASE(q,fq));+val|=(port->id<<MSS_RXQ_ASS_Q_BASE(q,fq));+val&=~(MSS_RXQ_ASS_HOSTID_MASK<<(MSS_RXQ_ASS_Q_BASE(q,fq)++MSS_RXQ_ASS_HOSTID_OFFS));++/* Calculate RXQ host ID:+*InSinglequeuemode:HostIDequaltoHostIDusedfor+*sharedRXinterrupt+*InMultiqueuemode:HostIDequaltonumberof+*RXQID/numberofCoSqueues+*InSingleresourcemode:HostIDalwaysequalto0+*/+if(queue_mode==MVPP2_QDIST_SINGLE_MODE)+host_id=mvpp22_calc_shared_addr_space(port);+elseif(queue_mode==MVPP2_QDIST_MULTI_MODE)+host_id=q;+else+host_id=0;++/* Set RXQ host ID */+val|=(host_id<<(MSS_RXQ_ASS_Q_BASE(q,fq)++MSS_RXQ_ASS_HOSTID_OFFS));++mvpp2_cm3_write(port->priv,MSS_RXQ_ASS_REG(q,fq),val);+}++/* Notify Firmware that Flow control config space ready for update */+val=mvpp2_cm3_read(port->priv,MSS_FC_COM_REG);+val|=FLOW_CONTROL_UPDATE_COMMAND_BIT;+val|=cm3_state;+mvpp2_cm3_write(port->priv,MSS_FC_COM_REG,val);++spin_unlock_irqrestore(&port->priv->mss_spinlock,flags);+}++/* Routine disable flow control for RXQs conditon */+voidmvpp2_rxq_disable_fc(structmvpp2_port*port)+{+intval,cm3_state,q;+unsignedlongflags;+intfq=port->first_rxq;++spin_lock_irqsave(&port->priv->mss_spinlock,flags);++/* Remove Flow control enable bit to prevent race between FW and Kernel+*IfFlowcontrolwereenabled,itwouldbere-enabled.+*/+val=mvpp2_cm3_read(port->priv,MSS_FC_COM_REG);+cm3_state=(val&FLOW_CONTROL_ENABLE_BIT);+val&=~FLOW_CONTROL_ENABLE_BIT;+mvpp2_cm3_write(port->priv,MSS_FC_COM_REG,val);++/* Disable Flow control for all RXQs */+for(q=0;q<port->nrxqs;q++){+/* Set threshold 0 to disable Flow control */+val=0;+val|=(0<<MSS_RXQ_TRESH_STOP_OFFS);+mvpp2_cm3_write(port->priv,MSS_RXQ_TRESH_REG(q,fq),val);++val=mvpp2_cm3_read(port->priv,MSS_RXQ_ASS_REG(q,fq));++val&=~(MSS_RXQ_ASS_PORTID_MASK<<MSS_RXQ_ASS_Q_BASE(q,fq));++val&=~(MSS_RXQ_ASS_HOSTID_MASK<<(MSS_RXQ_ASS_Q_BASE(q,fq)++MSS_RXQ_ASS_HOSTID_OFFS));++mvpp2_cm3_write(port->priv,MSS_RXQ_ASS_REG(q,fq),val);+}++/* Notify Firmware that Flow control config space ready for update */+val=mvpp2_cm3_read(port->priv,MSS_FC_COM_REG);+val|=FLOW_CONTROL_UPDATE_COMMAND_BIT;+val|=cm3_state;+mvpp2_cm3_write(port->priv,MSS_FC_COM_REG,val);++spin_unlock_irqrestore(&port->priv->mss_spinlock,flags);+}++/* Routine disable/enable flow control for BM pool conditon */+voidmvpp2_bm_pool_update_fc(structmvpp2_port*port,+structmvpp2_bm_pool*pool,+boolen)+{+intval,cm3_state;+unsignedlongflags;++spin_lock_irqsave(&port->priv->mss_spinlock,flags);++/* Remove Flow control enable bit to prevent race between FW and Kernel+*IfFlowcontrolwereenabled,itwouldbere-enabled.+*/+val=mvpp2_cm3_read(port->priv,MSS_FC_COM_REG);+cm3_state=(val&FLOW_CONTROL_ENABLE_BIT);+val&=~FLOW_CONTROL_ENABLE_BIT;+mvpp2_cm3_write(port->priv,MSS_FC_COM_REG,val);++/* Check if BM pool should be enabled/disable */+if(en){+/* Set BM pool start and stop thresholds per port */+val=mvpp2_cm3_read(port->priv,MSS_BUF_POOL_REG(pool->id));+val|=MSS_BUF_POOL_PORT_OFFS(port->id);+val&=~MSS_BUF_POOL_START_MASK;+val|=(MSS_THRESHOLD_START<<MSS_BUF_POOL_START_OFFS);+val&=~MSS_BUF_POOL_STOP_MASK;+val|=MSS_THRESHOLD_STOP;+mvpp2_cm3_write(port->priv,MSS_BUF_POOL_REG(pool->id),val);+}else{+/* Remove BM pool from the port */+val=mvpp2_cm3_read(port->priv,MSS_BUF_POOL_REG(pool->id));+val&=~MSS_BUF_POOL_PORT_OFFS(port->id);++/* Zero BM pool start and stop thresholds to disable pool+*flowcontrolifpoolempty(notusedbyanyport)+*/+if(!pool->buf_num){+val&=~MSS_BUF_POOL_START_MASK;+val&=~MSS_BUF_POOL_STOP_MASK;+}++mvpp2_cm3_write(port->priv,MSS_BUF_POOL_REG(pool->id),val);+}++/* Notify Firmware that Flow control config space ready for update */+val=mvpp2_cm3_read(port->priv,MSS_FC_COM_REG);+val|=FLOW_CONTROL_UPDATE_COMMAND_BIT;+val|=cm3_state;+mvpp2_cm3_write(port->priv,MSS_FC_COM_REG,val);++spin_unlock_irqrestore(&port->priv->mss_spinlock,flags);+}+/* Release buffer to BM */staticinlinevoidmvpp2_bm_pool_put(structmvpp2_port*port,intpool,dma_addr_tbuf_dma_addr,
From: Stefan Chulski <redacted>
This patch enable global flow control in FW.
Per port flow control is still disabled.
Signed-off-by: Stefan Chulski <redacted>
---
drivers/net/ethernet/marvell/mvpp2/mvpp2.h | 3 +++
drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c | 15 ++++++++++++++-
2 files changed, 17 insertions(+), 1 deletion(-)
@@ -7142,7 +7142,7 @@ static int mvpp2_probe(struct platform_device *pdev)structresource*res;void__iomem*base;inti,shared;-interr;+interr,val;priv=devm_kzalloc(&pdev->dev,sizeof(*priv),GFP_KERNEL);if(!priv)
@@ -7194,6 +7194,10 @@ static int mvpp2_probe(struct platform_device *pdev)err=mvpp2_get_sram(pdev,priv);if(err)dev_warn(&pdev->dev,"Fail to alloc CM3 SRAM\n");++/* Enable global Flow Control only if hanler to SRAM not NULL */+if(priv->cm3_base)+priv->global_tx_fc=true;}if(priv->hw_version!=MVPP21&&dev_of_node(&pdev->dev)){
@@ -7364,6 +7368,15 @@ static int mvpp2_probe(struct platform_device *pdev)gotoerr_port_probe;}+/* Enable global flow control. In this stage global+*flowcontrolenabled,butstilldisabledperport.+*/+if(priv->global_tx_fc&&priv->hw_version!=MVPP21){+val=mvpp2_cm3_read(priv,MSS_FC_COM_REG);+val|=FLOW_CONTROL_ENABLE_BIT;+mvpp2_cm3_write(priv,MSS_FC_COM_REG,val);+}+mvpp2_dbgfs_init(priv,pdev->name);platform_set_drvdata(pdev,priv);
From: Stefan Chulski <redacted>
This patch add RXQ flow control configurations.
Patch do not enable flow control itself, flow control
disabled by default.
Signed-off-by: Stefan Chulski <redacted>
---
drivers/net/ethernet/marvell/mvpp2/mvpp2.h | 3 +++
drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c | 7 +++++++
2 files changed, 10 insertions(+)
@@ -1234,6 +1234,9 @@ struct mvpp2_port {boolrx_hwtstamp;enumhwtstamp_tx_typestx_hwtstamp_type;structmvpp2_hwtstamp_queuetx_hwtstamp_queue[2];++/* Firmware TX flow control */+booltx_fc;};/* The mvpp2_tx_desc and mvpp2_rx_desc structures describe the
From: Stefan Chulski <redacted>
Feature double size of BPPI by decreasing number of pools from 16 to 8.
Increasing of BPPI size protect BM drop from BPPI underrun.
Underrun could occurred due to stress on DDR and as result slow buffer
transition from BPPE to BPPI.
New BPPI threshold recommended by spec is:
BPPI low threshold - 640 buffers
BPPI high threshold - 832 buffers
Supported only in PPv23.
Signed-off-by: Stefan Chulski <redacted>
---
drivers/net/ethernet/marvell/mvpp2/mvpp2.h | 8 +++++
drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c | 36 +++++++++++++++++++-
2 files changed, 43 insertions(+), 1 deletion(-)
From: Stefan Chulski <redacted>
This patch add ethtool flow control configuration support.
Tx flow control retrieved correctly by ethtool get function.
FW per port ethtool configuration capability added.
Patch also takes care about mtu change procedure, if PPv2 switch
BM pools during mtu change.
Signed-off-by: Stefan Chulski <redacted>
---
drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c | 53 ++++++++++++++++++++
1 file changed, 53 insertions(+)
@@ -1243,6 +1243,16 @@ static int mvpp2_bm_update_mtu(struct net_device *dev, int mtu)new_long_pool=MVPP2_BM_LONG;if(new_long_pool!=port->pool_long->id){+if(port->tx_fc){+if(pkt_size>MVPP2_BM_LONG_PKT_SIZE)+mvpp2_bm_pool_update_fc(port,+port->pool_short,+false);+else+mvpp2_bm_pool_update_fc(port,port->pool_long,+false);+}+/* Remove port from old short & long pool */port->pool_long=mvpp2_bm_pool_use(port,port->pool_long->id,port->pool_long->pkt_size);
@@ -1260,6 +1270,25 @@ static int mvpp2_bm_update_mtu(struct net_device *dev, int mtu)mvpp2_swf_bm_pool_init(port);mvpp2_set_hw_csum(port,new_long_pool);++if(port->tx_fc){+if(pkt_size>MVPP2_BM_LONG_PKT_SIZE)+mvpp2_bm_pool_update_fc(port,port->pool_long,+true);+else+mvpp2_bm_pool_update_fc(port,port->pool_short,+true);+}++/* Update L4 checksum when jumbo enable/disable on port */+if(new_long_pool==MVPP2_BM_JUMBO&&port->id!=0){+dev->features&=~(NETIF_F_IP_CSUM|NETIF_F_IPV6_CSUM);+dev->hw_features&=~(NETIF_F_IP_CSUM|+NETIF_F_IPV6_CSUM);+}else{+dev->features|=NETIF_F_IP_CSUM|NETIF_F_IPV6_CSUM;+dev->hw_features|=NETIF_F_IP_CSUM|NETIF_F_IPV6_CSUM;+}}out_set:
@@ -5373,6 +5402,30 @@ static int mvpp2_ethtool_set_pause_param(struct net_device *dev,structethtool_pauseparam*pause){structmvpp2_port*port=netdev_priv(dev);+inti;++if(pause->tx_pause&&port->priv->global_tx_fc){+port->tx_fc=true;+mvpp2_rxq_enable_fc(port);+if(port->priv->percpu_pools){+for(i=0;i<port->nrxqs;i++)+mvpp2_bm_pool_update_fc(port,&port->priv->bm_pools[i],true);+}else{+mvpp2_bm_pool_update_fc(port,port->pool_long,true);+mvpp2_bm_pool_update_fc(port,port->pool_short,true);+}++}elseif(port->priv->global_tx_fc){+port->tx_fc=false;+mvpp2_rxq_disable_fc(port);+if(port->priv->percpu_pools){+for(i=0;i<port->nrxqs;i++)+mvpp2_bm_pool_update_fc(port,&port->priv->bm_pools[i],false);+}else{+mvpp2_bm_pool_update_fc(port,port->pool_long,false);+mvpp2_bm_pool_update_fc(port,port->pool_short,false);+}+}if(!port->phylink)return-ENOTSUPP;
From: Stefan Chulski <redacted>
New FIFO flow control feature were added in PPv23.
PPv2 FIFO polled by HW and trigger pause frame if FIFO
fill level is below threshold.
FIFO HW flow control enabled with CM3 RXQ&BM flow
control with ethtool.
Current FIFO thresholds is:
9KB for port with maximum speed 10Gb/s port
4KB for port with maximum speed 5Gb/s port
2KB for port with maximum speed 1Gb/s port
Signed-off-by: Stefan Chulski <redacted>
---
drivers/net/ethernet/marvell/mvpp2/mvpp2.h | 16 +++++-
drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c | 55 ++++++++++++++++++++
2 files changed, 70 insertions(+), 1 deletion(-)
From: Stefan Chulski <redacted>
This patch add ring size validation before enabling FC.
1. Flow control cannot be enabled if ring size is below start
threshold.
2. Flow control disabled if ring size set below start
threshold.
Signed-off-by: Stefan Chulski <redacted>
---
drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c | 16 ++++++++++++++++
1 file changed, 16 insertions(+)
@@ -5372,6 +5372,15 @@ static int mvpp2_ethtool_set_ringparam(struct net_device *dev,if(err)returnerr;+if(ring->rx_pending<MSS_THRESHOLD_START&&port->tx_fc){+netdev_warn(dev,"TX FC disabled. Ring size is less than %d\n",+MSS_THRESHOLD_START);+port->tx_fc=false;+mvpp2_rxq_disable_fc(port);+if(port->priv->hw_version==MVPP23)+mvpp23_rx_fifo_fc_en(port->priv,port->id,false);+}+if(!netif_running(dev)){port->rx_ring_size=ring->rx_pending;port->tx_ring_size=ring->tx_pending;
@@ -5439,6 +5448,13 @@ static int mvpp2_ethtool_set_pause_param(struct net_device *dev,if(pause->tx_pause&&port->priv->global_tx_fc&&bm_underrun_protect){+if(port->rx_ring_size<MSS_THRESHOLD_START){+netdev_err(dev,"TX FC cannot be supported.");+netdev_err(dev,"Ring size is less than %d\n",+MSS_THRESHOLD_START);+return-EINVAL;+}+port->tx_fc=true;mvpp2_rxq_enable_fc(port);if(port->priv->percpu_pools){
From: Stefan Chulski <redacted>
Patch check that TX FC firmware is running in CM3.
If not, global TX FC would be disabled.
Signed-off-by: Stefan Chulski <redacted>
---
drivers/net/ethernet/marvell/mvpp2/mvpp2.h | 1 +
drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c | 39 ++++++++++++++++----
2 files changed, 33 insertions(+), 7 deletions(-)
@@ -946,6 +946,34 @@ void mvpp2_bm_pool_update_fc(struct mvpp2_port *port,spin_unlock_irqrestore(&port->priv->mss_spinlock,flags);}+staticintmvpp2_enable_global_fc(structmvpp2*priv)+{+intval,timeout=0;++/* Enable global flow control. In this stage global+*flowcontrolenabled,butstilldisabledperport.+*/+val=mvpp2_cm3_read(priv,MSS_FC_COM_REG);+val|=FLOW_CONTROL_ENABLE_BIT;+mvpp2_cm3_write(priv,MSS_FC_COM_REG,val);++/* Check if Firmware running and disable FC if not*/+val|=FLOW_CONTROL_UPDATE_COMMAND_BIT;+mvpp2_cm3_write(priv,MSS_FC_COM_REG,val);++while(timeout<MSS_FC_MAX_TIMEOUT){+val=mvpp2_cm3_read(priv,MSS_FC_COM_REG);++if(!(val&FLOW_CONTROL_UPDATE_COMMAND_BIT))+return0;+usleep_range(10,20);+timeout++;+}++priv->global_tx_fc=false;+return-EOPNOTSUPP;+}+/* Release buffer to BM */staticinlinevoidmvpp2_bm_pool_put(structmvpp2_port*port,intpool,dma_addr_tbuf_dma_addr,
@@ -7307,7 +7335,7 @@ static int mvpp2_probe(struct platform_device *pdev)structresource*res;void__iomem*base;inti,shared;-interr,val;+interr;priv=devm_kzalloc(&pdev->dev,sizeof(*priv),GFP_KERNEL);if(!priv)
@@ -7533,13 +7561,10 @@ static int mvpp2_probe(struct platform_device *pdev)gotoerr_port_probe;}-/* Enable global flow control. In this stage global-*flowcontrolenabled,butstilldisabledperport.-*/if(priv->global_tx_fc&&priv->hw_version!=MVPP21){-val=mvpp2_cm3_read(priv,MSS_FC_COM_REG);-val|=FLOW_CONTROL_ENABLE_BIT;-mvpp2_cm3_write(priv,MSS_FC_COM_REG,val);+err=mvpp2_enable_global_fc(priv);+if(err)+dev_warn(&pdev->dev,"CM3 firmware not running, TX FC disabled\n");}mvpp2_dbgfs_init(priv,pdev->name);
From: Andrew Lunn <andrew@lunn.ch> Date: 2021-01-10 17:14:07
On Sun, Jan 10, 2021 at 05:30:10PM +0200, stefanc@marvell.com wrote:
quoted hunk
From: Stefan Chulski <redacted>
BM pool size increased to support Firmware Flow Control.
Minimum depletion thresholds to support FC is 1024 buffers.
BM pool size increased to 2048 to have some 1024 buffers
space between depletion thresholds and BM pool size.
Signed-off-by: Stefan Chulski <redacted>
---
drivers/net/ethernet/marvell/mvpp2/mvpp2.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
Hi Stefan
Jumbo used to be 1/2 of regular. Do you know why?
It would be nice to have a comment in the commit message about why it
is O.K. to change the ratio of jumbo to regular frames, and what if
anything this does for memory requirements.
Andrew
From: Stefan Chulski <hidden> Date: 2021-01-10 17:26:45
External Email
----------------------------------------------------------------------
On Sun, Jan 10, 2021 at 05:30:10PM +0200, stefanc@marvell.com wrote:
quoted
From: Stefan Chulski <redacted>
BM pool size increased to support Firmware Flow Control.
Minimum depletion thresholds to support FC is 1024 buffers.
BM pool size increased to 2048 to have some 1024 buffers space between
depletion thresholds and BM pool size.
Signed-off-by: Stefan Chulski <redacted>
---
drivers/net/ethernet/marvell/mvpp2/mvpp2.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
Hi Stefan
Jumbo used to be 1/2 of regular. Do you know why?
It would be nice to have a comment in the commit message about why it is
O.K. to change the ratio of jumbo to regular frames, and what if anything this
does for memory requirements.
Andrew
I don't know why it is half(no hardware restrictions for this). I would add to commit message new memory requirements for buffer allocations.
Thanks.
From: Andrew Lunn <andrew@lunn.ch> Date: 2021-01-10 17:34:22
quoted hunk
@@ -5373,6 +5402,30 @@ static int mvpp2_ethtool_set_pause_param(struct net_device *dev, struct ethtool_pauseparam *pause) { struct mvpp2_port *port = netdev_priv(dev);+ int i;++ if (pause->tx_pause && port->priv->global_tx_fc) {+ port->tx_fc = true;+ mvpp2_rxq_enable_fc(port);+ if (port->priv->percpu_pools) {+ for (i = 0; i < port->nrxqs; i++)+ mvpp2_bm_pool_update_fc(port, &port->priv->bm_pools[i], true);+ } else {+ mvpp2_bm_pool_update_fc(port, port->pool_long, true);+ mvpp2_bm_pool_update_fc(port, port->pool_short, true);+ }++ } else if (port->priv->global_tx_fc) {+ port->tx_fc = false;+ mvpp2_rxq_disable_fc(port);+ if (port->priv->percpu_pools) {+ for (i = 0; i < port->nrxqs; i++)+ mvpp2_bm_pool_update_fc(port, &port->priv->bm_pools[i], false);+ } else {+ mvpp2_bm_pool_update_fc(port, port->pool_long, false);+ mvpp2_bm_pool_update_fc(port, port->pool_short, false);+ }+ }
This looks wrong. Flow control is normally the result of auto
negotiation. Both ends need to agree to it. Which is why
mvpp2_ethtool_set_pause_param() passes the users request onto phylink.
phylink will handle the autoneg and then ask the MAC to setup flow
control depending on the result in mvpp2_mac_link_up().
Andrew
From: Andrew Lunn <andrew@lunn.ch> Date: 2021-01-10 17:38:56
On Sun, Jan 10, 2021 at 05:30:22PM +0200, stefanc@marvell.com wrote:
From: Stefan Chulski <redacted>
This patch add ring size validation before enabling FC.
1. Flow control cannot be enabled if ring size is below start
threshold.
2. Flow control disabled if ring size set below start
threshold.
You should also tell phylink if pause is not supported, so it can
change what is auto-negotiated, letting the link partner know.
Andrew
From: Andrew Lunn <andrew@lunn.ch> Date: 2021-01-10 17:44:48
quoted
Should there be -EPROBE_DEFER handling in here somewhere? The SRAM is a
device, so it might not of been probed yet?
No, firmware probed during bootloader boot and we can use SRAM. SRAM
memory can be safely used.
A previous patch added:
+ CP11X_LABEL(cm3_sram): cm3@220000 {
+ compatible = "mmio-sram";
+ reg = <0x220000 0x800>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges = <0 0x220000 0x800>;
+ };
+
So it looks like the SRAM is a device, in the linux driver model. And
there is a driver for this, driver/misc/sram.c. How do you know this
device has been probed before the Ethernet driver?
Andrew
From: Stefan Chulski <hidden> Date: 2021-01-10 17:53:01
quoted
quoted
Should there be -EPROBE_DEFER handling in here somewhere? The SRAM
is a device, so it might not of been probed yet?
quoted
No, firmware probed during bootloader boot and we can use SRAM. SRAM
memory can be safely used.
A previous patch added:
+ CP11X_LABEL(cm3_sram): cm3@220000 {
+ compatible = "mmio-sram";
+ reg = <0x220000 0x800>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges = <0 0x220000 0x800>;
+ };
+
So it looks like the SRAM is a device, in the linux driver model. And there is a
driver for this, driver/misc/sram.c. How do you know this device has been
probed before the Ethernet driver?
Andrew
You right, I would add EPROBE_DEFER if of_gen_pool_get return NULL.
Thanks.
From: Russell King - ARM Linux admin <linux@armlinux.org.uk> Date: 2021-01-10 17:56:02
On Sun, Jan 10, 2021 at 05:30:07PM +0200, stefanc@marvell.com wrote:
+ } else {
+ priv->sram_pool = of_gen_pool_get(dn, "cm3-mem", 0);
+ if (!priv->sram_pool) {
+ dev_warn(&pdev->dev, "DT is too old, TX FC disabled\n");
I don't see anything in this patch that disables TX flow control, which
means this warning message is misleading.
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!
struct ethtool_pauseparam *pause) {
struct mvpp2_port *port = netdev_priv(dev);
+ int i;
+
+ if (pause->tx_pause && port->priv->global_tx_fc) {
+ port->tx_fc = true;
+ mvpp2_rxq_enable_fc(port);
+ if (port->priv->percpu_pools) {
+ for (i = 0; i < port->nrxqs; i++)
+ mvpp2_bm_pool_update_fc(port, &port-
priv->bm_pools[i], true);
+ } else {
+ mvpp2_bm_pool_update_fc(port, port->pool_long,
true);
quoted
+ mvpp2_bm_pool_update_fc(port, port->pool_short,
true);
quoted
+ }
+
+ } else if (port->priv->global_tx_fc) {
+ port->tx_fc = false;
+ mvpp2_rxq_disable_fc(port);
+ if (port->priv->percpu_pools) {
+ for (i = 0; i < port->nrxqs; i++)
+ mvpp2_bm_pool_update_fc(port, &port-
priv->bm_pools[i], false);
+ } else {
+ mvpp2_bm_pool_update_fc(port, port->pool_long,
false);
quoted
+ mvpp2_bm_pool_update_fc(port, port->pool_short,
false);
quoted
+ }
+ }
This looks wrong. Flow control is normally the result of auto negotiation. Both
ends need to agree to it. Which is why
mvpp2_ethtool_set_pause_param() passes the users request onto phylink.
phylink will handle the autoneg and then ask the MAC to setup flow control
depending on the result in mvpp2_mac_link_up().
Andrew
Ok, I would move it to mvpp2_mac_link_up.
Stefan,
Thanks.
From: Andrew Lunn <andrew@lunn.ch> Date: 2021-01-10 18:04:42
On Sun, Jan 10, 2021 at 05:57:14PM +0000, Stefan Chulski wrote:
quoted
quoted
+ } else {
+ priv->sram_pool = of_gen_pool_get(dn, "cm3-mem", 0);
+ if (!priv->sram_pool) {
+ dev_warn(&pdev->dev, "DT is too old, TX FC
disabled\n");
I don't see anything in this patch that disables TX flow control, which means
this warning message is misleading.
OK, I would change to TX FC not supported.
And you should tell phlylink, so it knows to disable it in autoneg.
Which make me wonder, do we need a fix for stable? Has flow control
never been support in this device up until these patches get merged?
It should not be negotiated if it is not supported, which means
telling phylink.
Andrew
From: Russell King - ARM Linux admin <linux@armlinux.org.uk> Date: 2021-01-10 18:07:27
On Sun, Jan 10, 2021 at 05:30:15PM +0200, stefanc@marvell.com wrote:
quoted hunk
From: Stefan Chulski <redacted>
This patch did not change any functionality.
Added flow control RXQ and BM pool config callbacks that would be
used to configure RXQ and BM pool thresholds.
APIs also will disable/enable RXQ and pool Flow Control polling.
In this stage BM pool and RXQ has same stop/start thresholds
defined in code.
Also there are common thresholds for all RXQs.
Signed-off-by: Stefan Chulski <redacted>
---
drivers/net/ethernet/marvell/mvpp2/mvpp2.h | 51 +++++-
drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c | 169 ++++++++++++++++++++
2 files changed, 216 insertions(+), 4 deletions(-)
@@ -744,6 +744,175 @@ static void *mvpp2_buf_alloc(struct mvpp2_port *port,returndata;}+/* Routine calculate single queue shares address space */+staticintmvpp22_calc_shared_addr_space(structmvpp2_port*port)+{+/* If number of CPU's greater than number of threads, return last+*addressspace+*/+if(num_active_cpus()>=MVPP2_MAX_THREADS)+returnMVPP2_MAX_THREADS-1;++returnnum_active_cpus();
Firstly - this can be written as:
return min(num_active_cpus(), MVPP2_MAX_THREADS - 1);
Secondly - what if the number of active CPUs change, for example due
to hotplug activity. What if we boot with maxcpus=1 and then bring the
other CPUs online after networking has been started? The number of
active CPUs is dynamically managed via the scheduler as CPUs are
brought online or offline.
+/* Routine enable flow control for RXQs conditon */
+void mvpp2_rxq_enable_fc(struct mvpp2_port *port)
...
+/* Routine disable flow control for RXQs conditon */
+void mvpp2_rxq_disable_fc(struct mvpp2_port *port)
Nothing seems to call these in this patch, so on its own, it's not
obvious how these are being called, and therefore what remedy to
suggest for num_active_cpus().
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!
From: Russell King - ARM Linux admin <linux@armlinux.org.uk> Date: 2021-01-10 18:10:01
On Sun, Jan 10, 2021 at 05:30:16PM +0200, stefanc@marvell.com wrote:
+ /* Enable global Flow Control only if hanler to SRAM not NULL */
I think this comment needs fixing. I'm not sure what a "hanler" is,
and "handler" doesn't make sense here.
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!
From: Stefan Chulski <hidden> Date: 2021-01-10 18:10:51
quoted
quoted
quoted
+ } else {
+ priv->sram_pool = of_gen_pool_get(dn, "cm3-mem", 0);
+ if (!priv->sram_pool) {
+ dev_warn(&pdev->dev, "DT is too old, TX FC
disabled\n");
I don't see anything in this patch that disables TX flow control,
which means this warning message is misleading.
OK, I would change to TX FC not supported.
And you should tell phlylink, so it knows to disable it in autoneg.
Which make me wonder, do we need a fix for stable? Has flow control never
been support in this device up until these patches get merged?
It should not be negotiated if it is not supported, which means telling phylink.
Andrew
TX FC never were really supported. MAC or PHY can negotiated flow control.
But MAC would never trigger FC frame.
Should I prepare separate patch that disable TX FC till we merge this patches?
Regards,
Stefan.
From: Russell King - ARM Linux admin <linux@armlinux.org.uk> Date: 2021-01-10 18:16:07
On Sun, Jan 10, 2021 at 05:30:18PM +0200, stefanc@marvell.com wrote:
quoted hunk
@@ -5373,6 +5402,30 @@ static int mvpp2_ethtool_set_pause_param(struct net_device *dev, struct ethtool_pauseparam *pause) { struct mvpp2_port *port = netdev_priv(dev);+ int i;++ if (pause->tx_pause && port->priv->global_tx_fc) {+ port->tx_fc = true;+ mvpp2_rxq_enable_fc(port);+ if (port->priv->percpu_pools) {+ for (i = 0; i < port->nrxqs; i++)+ mvpp2_bm_pool_update_fc(port, &port->priv->bm_pools[i], true);+ } else {+ mvpp2_bm_pool_update_fc(port, port->pool_long, true);+ mvpp2_bm_pool_update_fc(port, port->pool_short, true);+ }++ } else if (port->priv->global_tx_fc) {+ port->tx_fc = false;+ mvpp2_rxq_disable_fc(port);+ if (port->priv->percpu_pools) {+ for (i = 0; i < port->nrxqs; i++)+ mvpp2_bm_pool_update_fc(port, &port->priv->bm_pools[i], false);+ } else {+ mvpp2_bm_pool_update_fc(port, port->pool_long, false);+ mvpp2_bm_pool_update_fc(port, port->pool_short, false);+ }+ }
This doesn't look correct to me. This function is only called when
ethtool -A is used to change the flow control settings. This is not
the place to be configuring flow control, as flow control is
negotiated with the link partner.
The final resolved flow control settings are available in
mvpp2_mac_link_up() via the tx_pause and rx_pause parameters.
What also concerns me is whether flow control is supported in the
existing driver at all, given this patch set. If it isn't supported
without the firmware's help, then we should _not_ be negotiating flow
control with the link partner unless we actually support it, so the
Pause and Asym_Pause bits in mvpp2_phylink_validate() should be
cleared.
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!
From: Russell King - ARM Linux admin <linux@armlinux.org.uk> Date: 2021-01-10 18:18:27
Hi,
On Sun, Jan 10, 2021 at 05:30:04PM +0200, stefanc@marvell.com wrote:
Armada hardware has a pause generation mechanism in GOP (MAC).
GOP has to generate flow control frames based on an indication
programmed in Ports Control 0 Register. There is a bit per port.
However assertion of the PortX Pause bits in the ports control 0 register
only sends a one time pause. To complement the function the GOP has
a mechanism to periodically send pause control messages based on periodic counters.
This mechanism ensures that the pause is effective as long as the Appropriate PortX Pause
is asserted.
Can you ensure that your commit messages are consistently wrapped?
Some lines are wrapped others aren't.
Problem is that Packet Processor witch actually can drop packets due to lack of resources
Does the packet processor engage in magic or witchcraft? I suppose
some would argue that firmware does "magic"! However, I think you
mean "which". :)
not connected to the GOP flow control generation mechanism.
To solve this issue Armada has firmware running on CM3 CPU dedectated for Flow Control
support. Firmware monitors Packet Processor resources and asserts XON/XOFF by writing
to Ports Control 0 Register.
What is the minimum firmware version that supports this?
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!
From: Stefan Chulski <hidden> Date: 2021-01-10 18:25:47
quoted
+/* Routine calculate single queue shares address space */ static int
+mvpp22_calc_shared_addr_space(struct mvpp2_port *port) {
+ /* If number of CPU's greater than number of threads, return last
+ * address space
+ */
+ if (num_active_cpus() >= MVPP2_MAX_THREADS)
+ return MVPP2_MAX_THREADS - 1;
+
+ return num_active_cpus();
Firstly - this can be written as:
return min(num_active_cpus(), MVPP2_MAX_THREADS - 1);
OK.
Secondly - what if the number of active CPUs change, for example due to
hotplug activity. What if we boot with maxcpus=1 and then bring the other
CPUs online after networking has been started? The number of active CPUs is
dynamically managed via the scheduler as CPUs are brought online or offline.
quoted
+/* Routine enable flow control for RXQs conditon */ void
+mvpp2_rxq_enable_fc(struct mvpp2_port *port)
...
quoted
+/* Routine disable flow control for RXQs conditon */ void
+mvpp2_rxq_disable_fc(struct mvpp2_port *port)
Nothing seems to call these in this patch, so on its own, it's not obvious how
these are being called, and therefore what remedy to suggest for
num_active_cpus().
I don't think that current driver support CPU hotplug, anyway I can remove num_active_cpus
and just use shared RX IRQ ID.
Thanks.
.
From: Russell King - ARM Linux admin <linux@armlinux.org.uk> Date: 2021-01-10 18:28:43
On Sun, Jan 10, 2021 at 06:09:39PM +0000, Stefan Chulski wrote:
quoted
quoted
quoted
quoted
+ } else {
+ priv->sram_pool = of_gen_pool_get(dn, "cm3-mem", 0);
+ if (!priv->sram_pool) {
+ dev_warn(&pdev->dev, "DT is too old, TX FC
disabled\n");
I don't see anything in this patch that disables TX flow control,
which means this warning message is misleading.
OK, I would change to TX FC not supported.
And you should tell phlylink, so it knows to disable it in autoneg.
Which make me wonder, do we need a fix for stable? Has flow control never
been support in this device up until these patches get merged?
It should not be negotiated if it is not supported, which means telling phylink.
Andrew
TX FC never were really supported. MAC or PHY can negotiated flow control.
But MAC would never trigger FC frame.
That really sucks.
Should I prepare separate patch that disable TX FC till we merge this patches?
From what I see in table 28B in 802.3, there is no way to advertise
that you only support RX flow control. If you advertise ASM_DIR=1
PAUSE=0, it basically means you support sending FC frames, but not
receiving them. Advertising anything with PAUSE=1 means you support
both sending and receiving FC frames, irrespective of the state of
ASM_DIR.
So, our only option would be to completely disable pause frames.
Yes, I think we need a separate patch for that for the net tree,
and it should be backported to stable kernels, IMHO.
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!
struct ethtool_pauseparam *pause) {
struct mvpp2_port *port = netdev_priv(dev);
+ int i;
+
+ if (pause->tx_pause && port->priv->global_tx_fc) {
+ port->tx_fc = true;
+ mvpp2_rxq_enable_fc(port);
+ if (port->priv->percpu_pools) {
+ for (i = 0; i < port->nrxqs; i++)
+ mvpp2_bm_pool_update_fc(port, &port-
priv->bm_pools[i], true);
+ } else {
+ mvpp2_bm_pool_update_fc(port, port->pool_long,
true);
quoted
+ mvpp2_bm_pool_update_fc(port, port->pool_short,
true);
quoted
+ }
+
+ } else if (port->priv->global_tx_fc) {
+ port->tx_fc = false;
+ mvpp2_rxq_disable_fc(port);
+ if (port->priv->percpu_pools) {
+ for (i = 0; i < port->nrxqs; i++)
+ mvpp2_bm_pool_update_fc(port, &port-
priv->bm_pools[i], false);
+ } else {
+ mvpp2_bm_pool_update_fc(port, port->pool_long,
false);
quoted
+ mvpp2_bm_pool_update_fc(port, port->pool_short,
false);
quoted
+ }
+ }
This doesn't look correct to me. This function is only called when ethtool -A is
used to change the flow control settings. This is not the place to be
configuring flow control, as flow control is negotiated with the link partner.
The final resolved flow control settings are available in
mvpp2_mac_link_up() via the tx_pause and rx_pause parameters.
I would move this to mvpp2_mac_link_up.
Thanks.
What also concerns me is whether flow control is supported in the existing
driver at all, given this patch set. If it isn't supported without the firmware's
help, then we should _not_ be negotiating flow control with the link partner
unless we actually support it, so the Pause and Asym_Pause bits in
mvpp2_phylink_validate() should be cleared.
RX FC supported, issue only with TX FC.
Stefan,
Regards.
From: Russell King - ARM Linux admin <linux@armlinux.org.uk> Date: 2021-01-10 18:32:33
On Sun, Jan 10, 2021 at 06:24:30PM +0000, Stefan Chulski wrote:
quoted
quoted
+/* Routine calculate single queue shares address space */ static int
+mvpp22_calc_shared_addr_space(struct mvpp2_port *port) {
+ /* If number of CPU's greater than number of threads, return last
+ * address space
+ */
+ if (num_active_cpus() >= MVPP2_MAX_THREADS)
+ return MVPP2_MAX_THREADS - 1;
+
+ return num_active_cpus();
Firstly - this can be written as:
return min(num_active_cpus(), MVPP2_MAX_THREADS - 1);
OK.
quoted
Secondly - what if the number of active CPUs change, for example due to
hotplug activity. What if we boot with maxcpus=1 and then bring the other
CPUs online after networking has been started? The number of active CPUs is
dynamically managed via the scheduler as CPUs are brought online or offline.
quoted
+/* Routine enable flow control for RXQs conditon */ void
+mvpp2_rxq_enable_fc(struct mvpp2_port *port)
...
quoted
+/* Routine disable flow control for RXQs conditon */ void
+mvpp2_rxq_disable_fc(struct mvpp2_port *port)
Nothing seems to call these in this patch, so on its own, it's not obvious how
these are being called, and therefore what remedy to suggest for
num_active_cpus().
I don't think that current driver support CPU hotplug, anyway I can
remove num_active_cpus and just use shared RX IRQ ID.
Sorry, but that is not really a decision the driver can make. It is
part of a kernel that _does_ support CPU hotplug, and the online
CPUs can be changed today.
It is likely that every distro out there builds the kernel with
CPU hotplug enabled.
If changing the online CPUs causes the driver to misbehave, that
is a(nother) bug with the driver.
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!
From: Russell King - ARM Linux admin <linux@armlinux.org.uk> Date: 2021-01-10 18:34:32
On Sun, Jan 10, 2021 at 06:27:57PM +0000, Stefan Chulski wrote:
quoted
What also concerns me is whether flow control is supported in the existing
driver at all, given this patch set. If it isn't supported without the firmware's
help, then we should _not_ be negotiating flow control with the link partner
unless we actually support it, so the Pause and Asym_Pause bits in
mvpp2_phylink_validate() should be cleared.
RX FC supported, issue only with TX FC.
That doesn't seem relevant given table 28B in IEEE 802.3. There is
no advertisement combination that allows one to advertise an ability
to receive FC frames but not transmit FC frames.
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!
From: Stefan Chulski <hidden> Date: 2021-01-10 18:40:08
Sorry, but that is not really a decision the driver can make. It is part of a kernel
that _does_ support CPU hotplug, and the online CPUs can be changed today.
It is likely that every distro out there builds the kernel with CPU hotplug
enabled.
If changing the online CPUs causes the driver to misbehave, that is a(nother)
bug with the driver.
This function doesn't really need to know num_active_cpus, only host ID used by
used by shared RX interrupt in single queue mode.
Host ID is just register address space used to access PPv2 register space.
So I can remove this use of num_active_cpus.
Stefan,
Regards.
From: Stefan Chulski <hidden> Date: 2021-01-10 18:56:21
quoted
not connected to the GOP flow control generation mechanism.
To solve this issue Armada has firmware running on CM3 CPU dedectated
for Flow Control support. Firmware monitors Packet Processor resources
and asserts XON/XOFF by writing to Ports Control 0 Register.
What is the minimum firmware version that supports this?
Support were added to firmware about two years ago.
All releases from 18.09 should has it.
Stefan,
Regards.
From: Russell King - ARM Linux admin <linux@armlinux.org.uk> Date: 2021-01-10 19:02:20
On Sun, Jan 10, 2021 at 06:55:11PM +0000, Stefan Chulski wrote:
quoted
quoted
not connected to the GOP flow control generation mechanism.
To solve this issue Armada has firmware running on CM3 CPU dedectated
for Flow Control support. Firmware monitors Packet Processor resources
and asserts XON/XOFF by writing to Ports Control 0 Register.
What is the minimum firmware version that supports this?
Support were added to firmware about two years ago.
All releases from 18.09 should has it.
Please add that vital bit of information somewhere appropriate.
I would not be surprised if people are still running e.g. 17.10
on some of their Armada 8040 boards. My Macchiatobin which is
acting as a server currently has 17.10, although I plan to upgrade
it to 18.12 in about three to six months time, once I've well and
truely proven that my ext4 problems are resolved.
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!
From: Andrew Lunn <andrew@lunn.ch> Date: 2021-01-10 19:09:22
On Sun, Jan 10, 2021 at 06:55:11PM +0000, Stefan Chulski wrote:
quoted
quoted
not connected to the GOP flow control generation mechanism.
To solve this issue Armada has firmware running on CM3 CPU dedectated
for Flow Control support. Firmware monitors Packet Processor resources
and asserts XON/XOFF by writing to Ports Control 0 Register.
What is the minimum firmware version that supports this?
Support were added to firmware about two years ago.
All releases from 18.09 should has it.
Can you query the firmware and ask its version? We should keep all
this code disabled if the firmware it too old.
Andrew
From: Stefan Chulski <hidden> Date: 2021-01-10 19:13:04
On Sun, Jan 10, 2021 at 06:55:11PM +0000, Stefan Chulski wrote:
quoted
quoted
quoted
not connected to the GOP flow control generation mechanism.
To solve this issue Armada has firmware running on CM3 CPU
dedectated for Flow Control support. Firmware monitors Packet
Processor resources and asserts XON/XOFF by writing to Ports Control 0
Register.
quoted
quoted
What is the minimum firmware version that supports this?
Support were added to firmware about two years ago.
All releases from 18.09 should has it.
Can you query the firmware and ask its version? We should keep all this code
disabled if the firmware it too old.
Andrew
This is exactly what " net: mvpp2: add TX FC firmware check " patch do. If handshake of flow control support fail, FC won't be supported.
Stefan.
From: Andrew Lunn <andrew@lunn.ch> Date: 2021-01-10 19:21:48
On Sun, Jan 10, 2021 at 07:11:53PM +0000, Stefan Chulski wrote:
quoted
On Sun, Jan 10, 2021 at 06:55:11PM +0000, Stefan Chulski wrote:
quoted
quoted
quoted
not connected to the GOP flow control generation mechanism.
To solve this issue Armada has firmware running on CM3 CPU
dedectated for Flow Control support. Firmware monitors Packet
Processor resources and asserts XON/XOFF by writing to Ports Control 0
Register.
quoted
quoted
What is the minimum firmware version that supports this?
Support were added to firmware about two years ago.
All releases from 18.09 should has it.
Can you query the firmware and ask its version? We should keep all this code
disabled if the firmware it too old.
Andrew
This is exactly what " net: mvpp2: add TX FC firmware check " patch
do. If handshake of flow control support fail, FC won't be
supported.
Ah, O.K. Please extend the kernel log message to include the minimum
firmware version.
Andrew