RE: [PATCH net-next 2/2] net: stmmac: Add support for DWMAC5 and implement Safety Features

[Joao Pinto]

Looking great!

-Original Message-
From: Jose Abreu [mailto:joab...@synopsys.com] 
Sent: Thursday, February 1, 2018 2:42 PM
To: netdev@vger.kernel.org
Cc: Jose Abreu <joab...@synopsys.com>; David S. Miller <da...@davemloft.net>; 
Joao Pinto <jpi...@synopsys.com>; Giuseppe Cavallaro <peppe.cavall...@st.com>; 
Alexandre Torgue <alexandre.tor...@st.com>
Subject: [PATCH net-next 2/2] net: stmmac: Add support for DWMAC5 and implement 
Safety Features

This adds initial suport for DWMAC5 and implements the Automotive Safety 
Package which is available from core version 5.10.

The Automotive Safety Pacakge (also called Safety Features) offers us with 
error protection in the core by implementing ECC Protection in memories, 
on-chip data path parity protection, FSM parity and timeout protection and 
Application/CSR interface timeout protection.

In case of an uncorrectable error we call stmmac_global_err() and reconfigure 
the whole core.

Signed-off-by: Jose Abreu <joab...@synopsys.com>
Cc: David S. Miller <da...@davemloft.net>
Cc: Joao Pinto <jpi...@synopsys.com>
Cc: Giuseppe Cavallaro <peppe.cavall...@st.com>
Cc: Alexandre Torgue <alexandre.tor...@st.com>
---
 drivers/net/ethernet/stmicro/stmmac/Makefile  |2 +-
 drivers/net/ethernet/stmicro/stmmac/common.h  |8 +
 drivers/net/ethernet/stmicro/stmmac/dwmac4.h  |4 +
 drivers/net/ethernet/stmicro/stmmac/dwmac4_core.c |   38 +++-
 drivers/net/ethernet/stmicro/stmmac/dwmac4_dma.c  |6 +
 drivers/net/ethernet/stmicro/stmmac/dwmac5.c  |  242 +
 drivers/net/ethernet/stmicro/stmmac/dwmac5.h  |   49 
 drivers/net/ethernet/stmicro/stmmac/stmmac_main.c |   35 +++
 8 files changed, 382 insertions(+), 2 deletions(-)  create mode 100644 
drivers/net/ethernet/stmicro/stmmac/dwmac5.c
 create mode 100644 drivers/net/ethernet/stmicro/stmmac/dwmac5.h

diff --git a/drivers/net/ethernet/stmicro/stmmac/Makefile 
b/drivers/net/ethernet/stmicro/stmmac/Makefile
index ff3f83b..972e4ef 100644
--- a/drivers/net/ethernet/stmicro/stmmac/Makefile
+++ b/drivers/net/ethernet/stmicro/stmmac/Makefile
@@ -4,7 +4,7 @@ stmmac-objs:= stmmac_main.o stmmac_ethtool.o stmmac_mdio.o 
ring_mode.o  \
  chain_mode.o dwmac_lib.o dwmac1000_core.o dwmac1000_dma.o \
  dwmac100_core.o dwmac100_dma.o enh_desc.o norm_desc.o \
  mmc_core.o stmmac_hwtstamp.o stmmac_ptp.o dwmac4_descs.o  \
- dwmac4_dma.o dwmac4_lib.o dwmac4_core.o $(stmmac-y)
+ dwmac4_dma.o dwmac4_lib.o dwmac4_core.o dwmac5.o $(stmmac-y)
 
 # Ordering matters. Generic driver must be last.
 obj-$(CONFIG_STMMAC_PLATFORM)  += stmmac-platform.o
diff --git a/drivers/net/ethernet/stmicro/stmmac/common.h 
b/drivers/net/ethernet/stmicro/stmmac/common.h
index 2ffe76c..7bbd7eb 100644
--- a/drivers/net/ethernet/stmicro/stmmac/common.h
+++ b/drivers/net/ethernet/stmicro/stmmac/common.h
@@ -38,6 +38,8 @@
 #defineDWMAC_CORE_3_40 0x34
 #defineDWMAC_CORE_3_50 0x35
 #defineDWMAC_CORE_4_00 0x40
+#define DWMAC_CORE_5_00 0x50
+#define DWMAC_CORE_5_10 0x51
 #define STMMAC_CHAN0   0   /* Always supported and default for all chips */
 
 /* These need to be power of two, and >= 4 */ @@ -336,6 +338,8 @@ struct 
dma_features {
/* TX and RX FIFO sizes */
unsigned int tx_fifo_size;
unsigned int rx_fifo_size;
+   /* Automotive Safety Package */
+   unsigned int asp;
 };
 
 /* GMAC TX FIFO is 8K, Rx FIFO is 16K */ @@ -532,6 +536,10 @@ struct 
stmmac_ops {
 bool loopback);
void (*pcs_rane)(void __iomem *ioaddr, bool restart);
void (*pcs_get_adv_lp)(void __iomem *ioaddr, struct rgmii_adv *adv);
+   /* Safety Features */
+   int (*safety_feat_config)(void __iomem *ioaddr, unsigned int asp);
+   bool (*safety_feat_irq_status)(struct net_device *ndev,
+   void __iomem *ioaddr, unsigned int asp);
 };
 
 /* PTP and HW Timer helpers */
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac4.h 
b/drivers/net/ethernet/stmicro/stmmac/dwmac4.h
index 789dad8..afe9834 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac4.h
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac4.h
@@ -39,6 +39,7 @@
 #define GMAC_HW_FEATURE0   0x011c
 #define GMAC_HW_FEATURE1   0x0120
 #define GMAC_HW_FEATURE2   0x0124
+#define GMAC_HW_FEATURE3   0x0128
 #define GMAC_MDIO_ADDR 0x0200
 #define GMAC_MDIO_DATA 0x0204
 #define GMAC_ADDR_HIGH(reg)(0x300 + reg * 8)
@@ -192,6 +193,9 @@ enum power_event {
 #define GMAC_HW_FEAT_TXQCNTGENMASK(9, 6)
 #define GMAC_HW_FEAT_RXQCNTGENMASK(3, 0)
 
+/* MAC HW features3 bitmap */
+#define GMAC_HW_FEAT_ASP   GENMASK(29, 28)
+
 /* MAC HW ADDR regs */
 #define GMAC_HI_DCSGENMASK(18, 16)
 #de

Re: [PATCH net-next] net: stmmac: fix broken dma_interrupt handling for multi-queues

[Joao Pinto]

Hi Niklas,

Às 10:56 PM de 12/7/2017, Niklas Cassel escreveu:
> There is nothing that says that number of TX queues == number of RX
> queues. E.g. the ARTPEC-6 SoC has 2 TX queues and 1 RX queue.
> 

Yes you are totally right. Our Hardware was configured with 4RX queues and 4TX
queues and that lead us not to detect some of the issues that you are reporting.
We are already developing a prototype with a number of RX Queue different from
TX Queues.

We would like to resume a discussion that we had a couple of months ago, about
Synopsys testing stmmac in market boards. Currently I am the new Software Team
Manager and so I would like to say to you that we are interested in testing the
driver in several boards to assure quality in the stmmac driver, since we will
be constantly developing the new features for future HW releases.

If some vendors can send us sample boards it would be great, if we have to buy
some, it would be very useful to have reference suggestions.

Thanks and best regards,
Joao

> This code is obviously wrong:
> for (chan = 0; chan < tx_channel_count; chan++) {
> struct stmmac_rx_queue *rx_q = >rx_queue[chan];
> 
> priv->rx_queue has size MTL_MAX_RX_QUEUES, so this will send an
> uninitialized napi_struct to __napi_schedule(), causing us to
> crash in net_rx_action(), because napi_struct->poll is zero.
> 
> [12846.759880] Unable to handle kernel NULL pointer dereference at virtual 
> address 
> [12846.768014] pgd = (ptrval)
> [12846.770742] [] *pgd=39ec7831, *pte=, *ppte=
> [12846.777023] Internal error: Oops: 8007 [#1] PREEMPT SMP ARM
> [12846.782942] Modules linked in:
> [12846.785998] CPU: 0 PID: 161 Comm: dropbear Not tainted 
> 4.15.0-rc2-00285-gf5fb5f2f39a7 #36
> [12846.794177] Hardware name: Axis ARTPEC-6 Platform
> [12846.798879] task: (ptrval) task.stack: (ptrval)
> [12846.803407] PC is at 0x0
> [12846.805942] LR is at net_rx_action+0x274/0x43c
> [12846.810383] pc : [<>]lr : [<80bff064>]psr: 200e0113
> [12846.816648] sp : b90d9ae8  ip : b90d9ae8  fp : b90d9b44
> [12846.821871] r10: 0008  r9 : 0013250e  r8 : 0100
> [12846.827094] r7 : 012c  r6 :   r5 : 0001  r4 : bac84900
> [12846.833619] r3 :   r2 : b90d9b08  r1 :   r0 : bac84900
> 
> Since each DMA channel can be used for rx and tx simultaneously,
> the current code should probably be rewritten so that napi_struct is
> embedded in a new struct stmmac_channel.
> That way, stmmac_poll() can call stmmac_tx_clean() on just the tx queue
> where we got the IRQ, instead of looping through all tx queues.
> This is also how the xgbe driver does it (another driver for this IP).
> 
> Fixes: c22a3f48ef99 ("net: stmmac: adding multiple napi mechanism")
> Signed-off-by: Niklas Cassel 
> ---
>  drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 54 
> +++
>  1 file changed, 46 insertions(+), 8 deletions(-)
> 
> diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c 
> b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
> index d7250539d0bd..c52a9963c19d 100644
> --- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
> +++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
> @@ -1997,22 +1997,60 @@ static void stmmac_set_dma_operation_mode(struct 
> stmmac_priv *priv, u32 txmode,
>  static void stmmac_dma_interrupt(struct stmmac_priv *priv)
>  {
>   u32 tx_channel_count = priv->plat->tx_queues_to_use;
> - int status;
> + u32 rx_channel_count = priv->plat->rx_queues_to_use;
> + u32 channels_to_check = tx_channel_count > rx_channel_count ?
> + tx_channel_count : rx_channel_count;
>   u32 chan;
> + bool poll_scheduled = false;
> + int status[channels_to_check];
> +
> + /* Each DMA channel can be used for rx and tx simultaneously, yet
> +  * napi_struct is embedded in struct stmmac_rx_queue rather than in a
> +  * stmmac_channel struct.
> +  * Because of this, stmmac_poll currently checks (and possibly wakes)
> +  * all tx queues rather than just a single tx queue.
> +  */
> + for (chan = 0; chan < channels_to_check; chan++)
> + status[chan] = priv->hw->dma->dma_interrupt(priv->ioaddr,
> + >xstats,
> + chan);
>  
> - for (chan = 0; chan < tx_channel_count; chan++) {
> - struct stmmac_rx_queue *rx_q = >rx_queue[chan];
> + for (chan = 0; chan < rx_channel_count; chan++) {
> + if (likely(status[chan] & handle_rx)) {
> + struct stmmac_rx_queue *rx_q = >rx_queue[chan];
>  
> - status = priv->hw->dma->dma_interrupt(priv->ioaddr,
> -   >xstats, chan);
> - if (likely((status & handle_rx)) || (status & handle_tx)) {
>   if (likely(napi_schedule_prep(_q->napi))) {
>

stmmac: issue while performing iperf data flood

[Joao Pinto]

Hello to all,

I am executing some tests in stmmac regarding its multiple tx queue capability.

My setup is routing through queue 0 generic traffic and through queue 2 higher
priority traffic. It works fine, but when I execute a data flood using iperf in
the TX side, the interface goes down, instead of giving the higher traffic the
free pass and manage the generic traffic as good as possible. The command I am
executing is:

iperf -c  -u -b 1000M -t 60

The interface begins to drop packets (assuming this from return value of
dev_queue_xmit -> =1) and so the queues start to have timeouts.

If I use the same queue index, no problem happens, being perfectly capable of
sending both traffic types in a single queue. When using two queues, it does not
work, I think they might be entering in some kind of race.

Any ideas about this? Has anyone encountered this problem or similar?

Thak you so much.

Best regards,

Joao

Re: [PATCH 2/2 net-next] net: stmmac: Improve documentation on AVB parameters

[Joao Pinto]

Hi Peppe,

Às 8:09 AM de 7/7/2017, Giuseppe CAVALLARO escreveu:
> Hi Joao
> 
> On 7/5/2017 12:34 PM, Joao Pinto wrote:
>> Hi Peppe,
>>
>> Às 8:10 AM de 6/9/2017, Giuseppe CAVALLARO escreveu:
>>> Hi Joao
>>>
>>> On 6/8/2017 8:02 PM, Joao Pinto wrote:
>>>> This patch fixes the description of the DT AVB parameters and gives
>>>> an accurate example. It was also included the base values that were
>>>> used to get the example' CBS paremeter values.
>>>>
>>>> Signed-off-by: Joao Pinto<jpi...@synopsys.com>
>>>> ---
>>>>Documentation/devicetree/bindings/net/stmmac.txt | 24 
>>>> 
>>>>1 file changed, 16 insertions(+), 8 deletions(-)
>>>>
>>>> diff --git a/Documentation/devicetree/bindings/net/stmmac.txt
>>>> b/Documentation/devicetree/bindings/net/stmmac.txt
>>>> index c3a7be6..707426d 100644
>>>> --- a/Documentation/devicetree/bindings/net/stmmac.txt
>>>> +++ b/Documentation/devicetree/bindings/net/stmmac.txt
>>>> @@ -109,10 +109,10 @@ Optional properties:
>>>>  [Attention] Queue 0 is reserved for legacy traffic
>>>>  and so no AVB is available in this queue.
>>>>- Configure Credit Base Shaper (if AVB Mode selected):
>>>> -- snps,send_slope: enable Low Power Interface
>>>> -- snps,idle_slope: unlock on WoL
>>>> -- snps,high_credit: max write outstanding req. limit
>>>> -- snps,low_credit: max read outstanding req. limit
>>>> +- snps,send_slope: Send Slope Credit value
>>>> +- snps,idle_slope:  Idle Slope Credit value
>>>> +- snps,high_credit: High Credit value
>>>> +- snps,low_credit: Low Credit value
>>>>- snps,priority: TX queue priority (Range: 0x0 to 0xF)
>>>>Examples:
>>>>@@ -143,10 +143,18 @@ Examples:
>>>>  queue1 {
>>>>snps,avb-algorithm;
>>>> -snps,send_slope = <0x1000>;
>>>> -snps,idle_slope = <0x1000>;
>>>> -snps,high_credit = <0x3E800>;
>>>> -snps,low_credit = <0xFFC18000>;
>>>> +/*
>>>> + *  Example AVB parameters based on:
>>>> + *   Allocated Bandwidth: 40%
>>>> + *   Maximum Frame size: 1000 bytes
>>>> + *   Maximum Interference size: 1500 bytes
>>>> + *   Port Transmit Rate: 8
>>>> + *   Scaling Factor: 1024
>>>> + */
>>>> +snps,idle_slope = <0xCCC>;
>>>> +snps,send_slope = <0x1333>;
>>>> +snps,high_credit = <0x4B>;
>>> Thanks for having taken care about this changes, please, as required, add a
>>> cover-letter
>>> and give more information about these values that can be tuned by user and, 
>>> for
>>> example,
>>> the snps,high_credit could be as default = 0xbe4000 that is a reasonable 
>>> value
>>> because
>>> comes from 1522 * 8 * 1024 and LOW credit is the two complement.
>>>^
>>>  frame size ---> maximum is 16
>> I calculate the hi credit this way:
>>
>>HiCredit = BW / 100 * MaxInterferenceSize * 8 * Scaling
>>
>> Can I assume that you are considering 100% bandwidth for this example 
>> channel?
>> If so, it is not correct, since the maximum bandwidth should be 75%, leaving 
>> at
>> least 25% for default channel 0 (I think this is assured in the hardware).
> 
> ok, I did not remember that so I let you detail with a right example this 
> part 
> in the doc.
> 
> Well done and thanks.

No problem! I will send an example soon. Thanks.

Joao

> 
> Peppe
> 
>> Thanks,
>> Joao
>>
>>> Regards
>>> Peppe
>>>
>>>> +snps,low_credit = <0xFFB5>;
>>>>snps,priority = <0x1>;
>>>>};
>>>>};
>>>
>>
> 

Re: [PATCH 2/2 net-next] net: stmmac: Improve documentation on AVB parameters

[Joao Pinto]

Hi Peppe,

Às 8:10 AM de 6/9/2017, Giuseppe CAVALLARO escreveu:
> Hi Joao
> 
> On 6/8/2017 8:02 PM, Joao Pinto wrote:
>> This patch fixes the description of the DT AVB parameters and gives
>> an accurate example. It was also included the base values that were
>> used to get the example' CBS paremeter values.
>>
>> Signed-off-by: Joao Pinto <jpi...@synopsys.com>
>> ---
>>   Documentation/devicetree/bindings/net/stmmac.txt | 24 
>> 
>>   1 file changed, 16 insertions(+), 8 deletions(-)
>>
>> diff --git a/Documentation/devicetree/bindings/net/stmmac.txt
>> b/Documentation/devicetree/bindings/net/stmmac.txt
>> index c3a7be6..707426d 100644
>> --- a/Documentation/devicetree/bindings/net/stmmac.txt
>> +++ b/Documentation/devicetree/bindings/net/stmmac.txt
>> @@ -109,10 +109,10 @@ Optional properties:
>> [Attention] Queue 0 is reserved for legacy traffic
>> and so no AVB is available in this queue.
>>   - Configure Credit Base Shaper (if AVB Mode selected):
>> -- snps,send_slope: enable Low Power Interface
>> -- snps,idle_slope: unlock on WoL
>> -- snps,high_credit: max write outstanding req. limit
>> -- snps,low_credit: max read outstanding req. limit
>> +- snps,send_slope: Send Slope Credit value
>> +- snps,idle_slope:  Idle Slope Credit value
>> +- snps,high_credit: High Credit value
>> +- snps,low_credit: Low Credit value
>>   - snps,priority: TX queue priority (Range: 0x0 to 0xF)
>>   Examples:
>>   @@ -143,10 +143,18 @@ Examples:
>> queue1 {
>>   snps,avb-algorithm;
>> -snps,send_slope = <0x1000>;
>> -snps,idle_slope = <0x1000>;
>> -snps,high_credit = <0x3E800>;
>> -snps,low_credit = <0xFFC18000>;
>> +/*
>> + *  Example AVB parameters based on:
>> + *   Allocated Bandwidth: 40%
>> + *   Maximum Frame size: 1000 bytes
>> + *   Maximum Interference size: 1500 bytes
>> + *   Port Transmit Rate: 8
>> + *   Scaling Factor: 1024
>> + */
>> +snps,idle_slope = <0xCCC>;
>> +snps,send_slope = <0x1333>;
>> +snps,high_credit = <0x4B>;
> 
> Thanks for having taken care about this changes, please, as required, add a
> cover-letter
> and give more information about these values that can be tuned by user and, 
> for
> example,
> the snps,high_credit could be as default = 0xbe4000 that is a reasonable value
> because
> comes from 1522 * 8 * 1024 and LOW credit is the two complement.
>   ^
> frame size ---> maximum is 16

I calculate the hi credit this way:

  HiCredit = BW / 100 * MaxInterferenceSize * 8 * Scaling

Can I assume that you are considering 100% bandwidth for this example channel?
If so, it is not correct, since the maximum bandwidth should be 75%, leaving at
least 25% for default channel 0 (I think this is assured in the hardware).

Thanks,
Joao

> 
> Regards
> Peppe
> 
>> +snps,low_credit = <0xFFB5>;
>>   snps,priority = <0x1>;
>>   };
>>   };
> 
> 

[PATCH 2/2 net-next] net: stmmac: Improve documentation on AVB parameters

[Joao Pinto]

This patch fixes the description of the DT AVB parameters and gives
an accurate example. It was also included the base values that were
used to get the example' CBS paremeter values.

Signed-off-by: Joao Pinto <jpi...@synopsys.com>
---
 Documentation/devicetree/bindings/net/stmmac.txt | 24 
 1 file changed, 16 insertions(+), 8 deletions(-)

diff --git a/Documentation/devicetree/bindings/net/stmmac.txt 
b/Documentation/devicetree/bindings/net/stmmac.txt
index c3a7be6..707426d 100644
--- a/Documentation/devicetree/bindings/net/stmmac.txt
+++ b/Documentation/devicetree/bindings/net/stmmac.txt
@@ -109,10 +109,10 @@ Optional properties:
  [Attention] Queue 0 is reserved for legacy traffic
  and so no AVB is available in this queue.
- Configure Credit Base Shaper (if AVB Mode selected):
-   - snps,send_slope: enable Low Power Interface
-   - snps,idle_slope: unlock on WoL
-   - snps,high_credit: max write outstanding req. limit
-   - snps,low_credit: max read outstanding req. limit
+   - snps,send_slope: Send Slope Credit value
+   - snps,idle_slope:  Idle Slope Credit value
+   - snps,high_credit: High Credit value
+   - snps,low_credit: Low Credit value
- snps,priority: TX queue priority (Range: 0x0 to 0xF)
 Examples:
 
@@ -143,10 +143,18 @@ Examples:
 
queue1 {
snps,avb-algorithm;
-   snps,send_slope = <0x1000>;
-   snps,idle_slope = <0x1000>;
-   snps,high_credit = <0x3E800>;
-   snps,low_credit = <0xFFC18000>;
+   /*
+*  Example AVB parameters based on:
+*   Allocated Bandwidth: 40%
+*   Maximum Frame size: 1000 bytes
+*   Maximum Interference size: 1500 bytes
+*   Port Transmit Rate: 8
+*   Scaling Factor: 1024
+*/
+   snps,idle_slope = <0xCCC>;
+   snps,send_slope = <0x1333>;
+   snps,high_credit = <0x4B>;
+   snps,low_credit = <0xFFB5>;
snps,priority = <0x1>;
};
};
-- 
2.9.3

[PATCH 1/2 net-next] net: stmmac: fix RX routing function name

[Joao Pinto]

This patch fixes the RX packet routing function name in dwmac4_core.
It also calls the correct dwmac4_core callback for the routing
configuration purpose.

Signed-off-by: Joao Pinto <jpi...@synopsys.com>
---
 drivers/net/ethernet/stmicro/stmmac/dwmac4_core.c | 6 +++---
 drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 2 +-
 2 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac4_core.c 
b/drivers/net/ethernet/stmicro/stmmac/dwmac4_core.c
index f233bf8..0df038f 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac4_core.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac4_core.c
@@ -111,7 +111,7 @@ static void dwmac4_tx_queue_priority(struct mac_device_info 
*hw,
writel(value, ioaddr + base_register);
 }
 
-static void dwmac4_tx_queue_routing(struct mac_device_info *hw,
+static void dwmac4_rx_queue_routing(struct mac_device_info *hw,
u8 packet, u32 queue)
 {
void __iomem *ioaddr = hw->pcsr;
@@ -676,7 +676,7 @@ static const struct stmmac_ops dwmac4_ops = {
.rx_queue_enable = dwmac4_rx_queue_enable,
.rx_queue_prio = dwmac4_rx_queue_priority,
.tx_queue_prio = dwmac4_tx_queue_priority,
-   .rx_queue_routing = dwmac4_tx_queue_routing,
+   .rx_queue_routing = dwmac4_rx_queue_routing,
.prog_mtl_rx_algorithms = dwmac4_prog_mtl_rx_algorithms,
.prog_mtl_tx_algorithms = dwmac4_prog_mtl_tx_algorithms,
.set_mtl_tx_queue_weight = dwmac4_set_mtl_tx_queue_weight,
@@ -707,7 +707,7 @@ static const struct stmmac_ops dwmac410_ops = {
.rx_queue_enable = dwmac4_rx_queue_enable,
.rx_queue_prio = dwmac4_rx_queue_priority,
.tx_queue_prio = dwmac4_tx_queue_priority,
-   .rx_queue_routing = dwmac4_tx_queue_routing,
+   .rx_queue_routing = dwmac4_rx_queue_routing,
.prog_mtl_rx_algorithms = dwmac4_prog_mtl_rx_algorithms,
.prog_mtl_tx_algorithms = dwmac4_prog_mtl_tx_algorithms,
.set_mtl_tx_queue_weight = dwmac4_set_mtl_tx_queue_weight,
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c 
b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
index f446f36..9ca3a2d 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
@@ -2353,7 +2353,7 @@ static void stmmac_mac_config_rx_queues_routing(struct 
stmmac_priv *priv)
continue;
 
packet = priv->plat->rx_queues_cfg[queue].pkt_route;
-   priv->hw->mac->rx_queue_prio(priv->hw, packet, queue);
+   priv->hw->mac->rx_queue_routing(priv->hw, packet, queue);
}
 }
 
-- 
2.9.3

Re: mlx5 endpoint driver problem

[Joao Pinto]

Hi again Saeed,

Às 6:44 PM de 5/9/2017, Saeed Mahameed escreveu:
> On Tue, May 9, 2017 at 8:38 PM, Joao Pinto <joao.pi...@synopsys.com> wrote:
>> Hi Saeed,
>>
>> Às 6:35 PM de 5/9/2017, Saeed Mahameed escreveu:
>>> On Tue, May 9, 2017 at 7:25 PM, Joao Pinto <joao.pi...@synopsys.com> wrote:
>>>> Hello,
>>>>
>>>> I am making tests with a Mellanox MLX5 Endpoint, and I am getting kernel 
>>>> hangs
>>>> when trying to enable the hca:
>>>>
>>>> mlx5_core :01:00.0: enabling device ( -> 0002)
>>>> mlx5_core :01:00.0: Warning: couldn't set 64-bit PCI DMA mask
>>>> mlx5_core :01:00.0: Warning: couldn't set 64-bit consistent PCI DMA 
>>>> mask
>>>> mlx5_core :01:00.0: firmware version: 16.19.21102
>>>> INFO: task swapper:1 blocked for more than 10 seconds.
>>>>   Not tainted 4.11.0-BETAMSIX1 #51
>>>> "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
>>>> swapper D0 1  0 0x
>>>>
>>>> Stack Trace:
>>>>   __switch_to+0x0/0x94
>>>>   __schedule+0x1da/0x8b0
>>>>   schedule+0x26/0x6c
>>>>   schedule_timeout+0x2da/0x380
>>>>   wait_for_completion+0x92/0x104
>>>>   mlx5_cmd_exec+0x70e/0xd60
>>>>   mlx5_load_one+0x1b4/0xad8
>>>>   init_one+0x404/0x600
>>>>   pci_device_probe+0x122/0x1f0
>>>>   really_probe+0x1ac/0x348
>>>>   __driver_attach+0xa8/0xd0
>>>>   bus_for_each_dev+0x3c/0x74
>>>>   bus_add_driver+0xc2/0x184
>>>>   driver_register+0x50/0xec
>>>>   init+0x40/0x60
>>>>
>>>> (...)
>>>>
>>>> Stack Trace:
>>>>   __switch_to+0x0/0x94
>>>>   __schedule+0x1da/0x8b0
>>>>   schedule+0x26/0x6c
>>>>   schedule_timeout+0x2da/0x380
>>>>   wait_for_completion+0x92/0x104
>>>>   mlx5_cmd_exec+0x70e/0xd60
>>>>   mlx5_load_one+0x1b4/0xad8
>>>>   init_one+0x404/0x600
>>>>   pci_device_probe+0x122/0x1f0
>>>>   really_probe+0x1ac/0x348
>>>>   __driver_attach+0xa8/0xd0
>>>>   bus_for_each_dev+0x3c/0x74
>>>>   bus_add_driver+0xc2/0x184
>>>>   driver_register+0x50/0xec
>>>>   init+0x40/0x60
>>>> mlx5_core :01:00.0: wait_func:882:(pid 1): ENABLE_HCA(0x104) timeout. 
>>>> Will
>>>> cause a leak of a command resource
>>>> mlx5_core :01:00.0: enable hca failed
>>>> mlx5_core :01:00.0: mlx5_load_one failed with error code -110
>>>> mlx5_core: probe of :01:00.0 failed with error -110
>>>>
>>>> Could you give me a clue of what might be happennig?
>>>>
>>>
>>> Hi Joao,
>>>
>>> Looks like FW is not responding, most likely due to the DMA mask
>>> setting warnings, which architecture is this ?
>>>
>>>> Thanks,
>>>> Joao
>>
>> I am working with a 32-bit ARC processor based board, connected to a 
>> prototyped
>> Gen4 PCI RC.
>>
> 
> Ok, i will consult with our PCI and FW experts and get back to you.
> 
> please note that the current mlx5 driver was never tested on 32-bit
> architecture and might not work properly for you.

I have new data for you. My colleague is using a Mellanox MT27800 Family
(ConnectX-5) with Firmware version 16.19.148 and it does have hangs, but it
fails in the CPU mask:

mlx5_core :01:00.0: enabling device ( -> 0002)
mlx5_core :01:00.0: Warning: couldn't set 64-bit PCI DMA mask
mlx5_core :01:00.0: Warning: couldn't set 64-bit consistent PCI DMA mask
mlx5_core :01:00.0: firmware version: 16.19.148
mlx5_core :01:00.0: Port module event: module 0, Cable unplugged
mlx5_core :01:00.0: mlx5_irq_set_affinity_hint:628:(pid 1):
irq_set_affinity_hint failed,irq 0x0032
mlx5_core :01:00.0: Failed to alloc affinity hint cpumask
mlx5_core :01:00.0: mlx5_load_one failed with error code -22
mlx5_core: probe of :01:00.0 failed with error -22

Mine is a Mellanox MT28800 Family (ConnectX-5) with Firmware Version 
16.19.21102.

Hopes it gives more data for analysis.

Thanks,
Joao

> 
>> Thanks,
>> Joao
>>
>>
>>

Re: mlx5 endpoint driver problem

[Joao Pinto]

Hi Saeed,

Às 6:35 PM de 5/9/2017, Saeed Mahameed escreveu:
> On Tue, May 9, 2017 at 7:25 PM, Joao Pinto <joao.pi...@synopsys.com> wrote:
>> Hello,
>>
>> I am making tests with a Mellanox MLX5 Endpoint, and I am getting kernel 
>> hangs
>> when trying to enable the hca:
>>
>> mlx5_core :01:00.0: enabling device ( -> 0002)
>> mlx5_core :01:00.0: Warning: couldn't set 64-bit PCI DMA mask
>> mlx5_core :01:00.0: Warning: couldn't set 64-bit consistent PCI DMA mask
>> mlx5_core :01:00.0: firmware version: 16.19.21102
>> INFO: task swapper:1 blocked for more than 10 seconds.
>>   Not tainted 4.11.0-BETAMSIX1 #51
>> "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
>> swapper D0 1  0 0x
>>
>> Stack Trace:
>>   __switch_to+0x0/0x94
>>   __schedule+0x1da/0x8b0
>>   schedule+0x26/0x6c
>>   schedule_timeout+0x2da/0x380
>>   wait_for_completion+0x92/0x104
>>   mlx5_cmd_exec+0x70e/0xd60
>>   mlx5_load_one+0x1b4/0xad8
>>   init_one+0x404/0x600
>>   pci_device_probe+0x122/0x1f0
>>   really_probe+0x1ac/0x348
>>   __driver_attach+0xa8/0xd0
>>   bus_for_each_dev+0x3c/0x74
>>   bus_add_driver+0xc2/0x184
>>   driver_register+0x50/0xec
>>   init+0x40/0x60
>>
>> (...)
>>
>> Stack Trace:
>>   __switch_to+0x0/0x94
>>   __schedule+0x1da/0x8b0
>>   schedule+0x26/0x6c
>>   schedule_timeout+0x2da/0x380
>>   wait_for_completion+0x92/0x104
>>   mlx5_cmd_exec+0x70e/0xd60
>>   mlx5_load_one+0x1b4/0xad8
>>   init_one+0x404/0x600
>>   pci_device_probe+0x122/0x1f0
>>   really_probe+0x1ac/0x348
>>   __driver_attach+0xa8/0xd0
>>   bus_for_each_dev+0x3c/0x74
>>   bus_add_driver+0xc2/0x184
>>   driver_register+0x50/0xec
>>   init+0x40/0x60
>> mlx5_core :01:00.0: wait_func:882:(pid 1): ENABLE_HCA(0x104) timeout. 
>> Will
>> cause a leak of a command resource
>> mlx5_core :01:00.0: enable hca failed
>> mlx5_core :01:00.0: mlx5_load_one failed with error code -110
>> mlx5_core: probe of :01:00.0 failed with error -110
>>
>> Could you give me a clue of what might be happennig?
>>
> 
> Hi Joao,
> 
> Looks like FW is not responding, most likely due to the DMA mask
> setting warnings, which architecture is this ?
> 
>> Thanks,
>> Joao

I am working with a 32-bit ARC processor based board, connected to a prototyped
Gen4 PCI RC.

Thanks,
Joao

mlx5 endpoint driver problem

[Joao Pinto]

Hello,

I am making tests with a Mellanox MLX5 Endpoint, and I am getting kernel hangs
when trying to enable the hca:

mlx5_core :01:00.0: enabling device ( -> 0002)
mlx5_core :01:00.0: Warning: couldn't set 64-bit PCI DMA mask
mlx5_core :01:00.0: Warning: couldn't set 64-bit consistent PCI DMA mask
mlx5_core :01:00.0: firmware version: 16.19.21102
INFO: task swapper:1 blocked for more than 10 seconds.
  Not tainted 4.11.0-BETAMSIX1 #51
"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
swapper D0 1  0 0x

Stack Trace:
  __switch_to+0x0/0x94
  __schedule+0x1da/0x8b0
  schedule+0x26/0x6c
  schedule_timeout+0x2da/0x380
  wait_for_completion+0x92/0x104
  mlx5_cmd_exec+0x70e/0xd60
  mlx5_load_one+0x1b4/0xad8
  init_one+0x404/0x600
  pci_device_probe+0x122/0x1f0
  really_probe+0x1ac/0x348
  __driver_attach+0xa8/0xd0
  bus_for_each_dev+0x3c/0x74
  bus_add_driver+0xc2/0x184
  driver_register+0x50/0xec
  init+0x40/0x60

(...)

Stack Trace:
  __switch_to+0x0/0x94
  __schedule+0x1da/0x8b0
  schedule+0x26/0x6c
  schedule_timeout+0x2da/0x380
  wait_for_completion+0x92/0x104
  mlx5_cmd_exec+0x70e/0xd60
  mlx5_load_one+0x1b4/0xad8
  init_one+0x404/0x600
  pci_device_probe+0x122/0x1f0
  really_probe+0x1ac/0x348
  __driver_attach+0xa8/0xd0
  bus_for_each_dev+0x3c/0x74
  bus_add_driver+0xc2/0x184
  driver_register+0x50/0xec
  init+0x40/0x60
mlx5_core :01:00.0: wait_func:882:(pid 1): ENABLE_HCA(0x104) timeout. Will
cause a leak of a command resource
mlx5_core :01:00.0: enable hca failed
mlx5_core :01:00.0: mlx5_load_one failed with error code -110
mlx5_core: probe of :01:00.0 failed with error -110

Could you give me a clue of what might be happennig?

Thanks,
Joao

Re: [PATCH v1 4/4] stmmac: pci: split out common_default_data() helper

[Joao Pinto]

Às 3:14 PM de 5/8/2017, Andy Shevchenko escreveu:
> New helper is added in order to prevent misconfiguration happened
> for one of the platforms when configuration data is expanded.
> 
> Signed-off-by: Andy Shevchenko <andriy.shevche...@linux.intel.com>
> ---
>  drivers/net/ethernet/stmicro/stmmac/stmmac_pci.c | 52 
> 
>  1 file changed, 18 insertions(+), 34 deletions(-)
> 
> diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_pci.c 
> b/drivers/net/ethernet/stmicro/stmmac/stmmac_pci.c
> index 2456e0a945ef..22f910795be4 100644
> --- a/drivers/net/ethernet/stmicro/stmmac/stmmac_pci.c
> +++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_pci.c
> @@ -70,11 +70,8 @@ static int stmmac_pci_find_phy_addr(struct stmmac_pci_info 
> *info)
>   return -ENODEV;
>  }
>  
> -static void stmmac_default_data(struct plat_stmmacenet_data *plat)
> +static void common_default_data(struct plat_stmmacenet_data *plat)
>  {
> - plat->bus_id = 1;
> - plat->phy_addr = 0;
> - plat->interface = PHY_INTERFACE_MODE_GMII;
>   plat->clk_csr = 2;  /* clk_csr_i = 20-35MHz & MDC = clk_csr_i/16 */
>   plat->has_gmac = 1;
>   plat->force_sf_dma_mode = 1;
> @@ -82,10 +79,6 @@ static void stmmac_default_data(struct 
> plat_stmmacenet_data *plat)
>   plat->mdio_bus_data->phy_reset = NULL;
>   plat->mdio_bus_data->phy_mask = 0;
>  
> - plat->dma_cfg->pbl = 32;
> - plat->dma_cfg->pblx8 = true;
> - /* TODO: AXI */
> -
>   /* Set default value for multicast hash bins */
>   plat->multicast_filter_bins = HASH_TABLE_SIZE;
>  
> @@ -107,12 +100,29 @@ static void stmmac_default_data(struct 
> plat_stmmacenet_data *plat)
>   plat->rx_queues_cfg[0].pkt_route = 0x0;
>  }
>  
> +static void stmmac_default_data(struct plat_stmmacenet_data *plat)
> +{
> + /* Set common default data first */
> + common_default_data(plat);
> +
> + plat->bus_id = 1;
> + plat->phy_addr = 0;
> + plat->interface = PHY_INTERFACE_MODE_GMII;
> +
> + plat->dma_cfg->pbl = 32;
> + plat->dma_cfg->pblx8 = true;
> + /* TODO: AXI */
> +}
> +
>  static int quark_default_data(struct plat_stmmacenet_data *plat,
> struct stmmac_pci_info *info)
>  {
>   struct pci_dev *pdev = info->pdev;
>   int ret;
>  
> + /* Set common default data first */
> + common_default_data(plat);
> +
>   /*
>* Refuse to load the driver and register net device if MAC controller
>* does not connect to any PHY interface.
> @@ -124,38 +134,12 @@ static int quark_default_data(struct 
> plat_stmmacenet_data *plat,
>   plat->bus_id = PCI_DEVID(pdev->bus->number, pdev->devfn);
>   plat->phy_addr = ret;
>   plat->interface = PHY_INTERFACE_MODE_RMII;
> - plat->clk_csr = 2;
> - plat->has_gmac = 1;
> - plat->force_sf_dma_mode = 1;
> -
> - plat->mdio_bus_data->phy_reset = NULL;
> - plat->mdio_bus_data->phy_mask = 0;
>  
>   plat->dma_cfg->pbl = 16;
>   plat->dma_cfg->pblx8 = true;
>   plat->dma_cfg->fixed_burst = 1;
>   /* AXI (TODO) */
>  
> - /* Set default value for multicast hash bins */
> - plat->multicast_filter_bins = HASH_TABLE_SIZE;
> -
> - /* Set default value for unicast filter entries */
> - plat->unicast_filter_entries = 1;
> -
> - /* Set the maxmtu to a default of JUMBO_LEN */
> - plat->maxmtu = JUMBO_LEN;
> -
> - /* Set default number of RX and TX queues to use */
> - plat->tx_queues_to_use = 1;
> - plat->rx_queues_to_use = 1;
> -
> - /* Disable Priority config by default */
> - plat->tx_queues_cfg[0].use_prio = false;
> - plat->rx_queues_cfg[0].use_prio = false;
> -
> - /* Disable RX queues routing by default */
> - plat->rx_queues_cfg[0].pkt_route = 0x0;
> -
>   return 0;
>  }
>  
> 

Makes sense!

Acked-by: Joao Pinto <jpi...@synopsys.com>

Re: [PATCH v1 3/4] stmmac: pci: RX queue routing configuration

[Joao Pinto]

Às 3:14 PM de 5/8/2017, Andy Shevchenko escreveu:
> The commit abe80fdc6ee6
> 
> ("net: stmmac: RX queue routing configuration")
> 
> missed Intel Quark configuration. Append it here.
> 
> Fixes: abe80fdc6ee6 ("net: stmmac: RX queue routing configuration")
> Cc: Joao Pinto <joao.pi...@synopsys.com>
> Signed-off-by: Andy Shevchenko <andriy.shevche...@linux.intel.com>
> ---
>  drivers/net/ethernet/stmicro/stmmac/stmmac_pci.c | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_pci.c 
> b/drivers/net/ethernet/stmicro/stmmac/stmmac_pci.c
> index c015a715a8ac..2456e0a945ef 100644
> --- a/drivers/net/ethernet/stmicro/stmmac/stmmac_pci.c
> +++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_pci.c
> @@ -153,6 +153,9 @@ static int quark_default_data(struct plat_stmmacenet_data 
> *plat,
>   plat->tx_queues_cfg[0].use_prio = false;
>   plat->rx_queues_cfg[0].use_prio = false;
>  
> + /* Disable RX queues routing by default */
> + plat->rx_queues_cfg[0].pkt_route = 0x0;
> +
>   return 0;
>  }
>  
> 

Acked-by: Joao Pinto <jpi...@synopsys.com>

Re: [PATCH v1 2/4] stmmac: pci: TX and RX queue priority configuration

[Joao Pinto]

Às 3:14 PM de 5/8/2017, Andy Shevchenko escreveu:
> The commit a8f5102af2a7
> 
>   ("net: stmmac: TX and RX queue priority configuration")
> 
> missed Intel Quark configuration. Append it here.
> 
> Fixes: a8f5102af2a7 ("net: stmmac: TX and RX queue priority configuration")
> Cc: Joao Pinto <joao.pi...@synopsys.com>
> Signed-off-by: Andy Shevchenko <andriy.shevche...@linux.intel.com>
> ---
>  drivers/net/ethernet/stmicro/stmmac/stmmac_pci.c | 4 
>  1 file changed, 4 insertions(+)
> 
> diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_pci.c 
> b/drivers/net/ethernet/stmicro/stmmac/stmmac_pci.c
> index ae3e836f9bb6..c015a715a8ac 100644
> --- a/drivers/net/ethernet/stmicro/stmmac/stmmac_pci.c
> +++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_pci.c
> @@ -149,6 +149,10 @@ static int quark_default_data(struct 
> plat_stmmacenet_data *plat,
>   plat->tx_queues_to_use = 1;
>   plat->rx_queues_to_use = 1;
>  
> + /* Disable Priority config by default */
> + plat->tx_queues_cfg[0].use_prio = false;
> + plat->rx_queues_cfg[0].use_prio = false;
> +
>   return 0;
>  }
>  
> 

Acked-by: Joao Pinto <jpi...@synopsys.com>

Re: [PATCH v1 1/4] stmmac: pci: set default number of rx and tx queues

[Joao Pinto]

Às 3:14 PM de 5/8/2017, Andy Shevchenko escreveu:
> The commit 26d6851fd24e
> 
>   ("net: stmmac: set default number of rx and tx queues in stmmac_pci")
> 
> missed Intel Quark configuration. Append it here.
> 
> Fixes: 26d6851fd24e ("net: stmmac: set default number of rx and tx queues in 
> stmmac_pci")
> Cc: Joao Pinto <joao.pi...@synopsys.com>
> Signed-off-by: Andy Shevchenko <andriy.shevche...@linux.intel.com>
> ---
>  drivers/net/ethernet/stmicro/stmmac/stmmac_pci.c | 4 
>  1 file changed, 4 insertions(+)
> 
> diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_pci.c 
> b/drivers/net/ethernet/stmicro/stmmac/stmmac_pci.c
> index 39be96779145..ae3e836f9bb6 100644
> --- a/drivers/net/ethernet/stmicro/stmmac/stmmac_pci.c
> +++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_pci.c
> @@ -145,6 +145,10 @@ static int quark_default_data(struct 
> plat_stmmacenet_data *plat,
>   /* Set the maxmtu to a default of JUMBO_LEN */
>   plat->maxmtu = JUMBO_LEN;
>  
> + /* Set default number of RX and TX queues to use */
> + plat->tx_queues_to_use = 1;
> + plat->rx_queues_to_use = 1;
> +
>   return 0;
>  }
>  
> 

Acked-by: Joao Pinto <jpi...@synopsys.com>

Re: [PATCH v3 net-next 01/11] net: stmmac: prepare dma op mode config for multiple queues

[Joao Pinto]

Às 12:56 PM de 5/8/2017, Andy Shevchenko escreveu:
> On Mon, May 8, 2017 at 2:40 PM, Joao Pinto <joao.pi...@synopsys.com> wrote:
>> Às 12:34 PM de 5/8/2017, Andy Shevchenko escreveu:
>>> On Mon, May 8, 2017 at 1:42 PM, Joao Pinto <joao.pi...@synopsys.com> wrote:
>>>> Às 11:12 AM de 5/8/2017, Andy Shevchenko escreveu:
>>>>> On Mon, May 8, 2017 at 12:54 PM, Joao Pinto <joao.pi...@synopsys.com> 
>>>>> wrote:
>>>>>> Às 10:36 AM de 5/8/2017, Andy Shevchenko escreveu:
> 
>>>
>>> [   44.374161] stmmac_dvr_probe <<< 0 0
>>>
>>
>> Ok, so this is the cause of the problem. The driver is geting 0 for real RX 
>> and
>> TX queues.
>>
>> Your setup uses standard DT parsing from stmmac_platform or a custom one?
>>
>> If you are using stmmac_probe_config_dt():
>> https://urldefense.proofpoint.com/v2/url?u=https-3A__git.kernel.org_pub_scm_linux_kernel_git_torvalds_linux.git_tree_drivers_net_ethernet_stmicro_stmmac_stmmac-5Fplatform.c-23n363=DwIFaQ=DPL6_X_6JkXFx7AXWqB0tg=s2fO0hii0OGNOv9qQy_HRXy-xAJUD1NNoEcc3io_kx0=fJQj7RiT2sksJYOAZ9VSJUDnxPR7RlE6Fw_cTV0_Mqc=KhdAPUtP0twDkibE89cLYs8JjnxEvBgav5uf08WL_e8=
>>  
>>
>> You will find a function named stmmac_mtl_setup() being called:
>> https://urldefense.proofpoint.com/v2/url?u=https-3A__git.kernel.org_pub_scm_linux_kernel_git_torvalds_linux.git_tree_drivers_net_ethernet_stmicro_stmmac_stmmac-5Fplatform.c-23n492=DwIFaQ=DPL6_X_6JkXFx7AXWqB0tg=s2fO0hii0OGNOv9qQy_HRXy-xAJUD1NNoEcc3io_kx0=fJQj7RiT2sksJYOAZ9VSJUDnxPR7RlE6Fw_cTV0_Mqc=rTxn0fwdudwq9XAquH60xNHN538KBQ6_n4wODdLoyA0=
>>  
>>
>> In this function, the number of RX and TX queues is being set to 1 by 
>> default.
> 
> Ah-ha, now I know how it's happened.
> You forget to update all setup() hooks in PCI bus driver :-)
> 
> I will prepare a fix.
> Just tell me should I put Fixes tag or not? And if yes, what commit
> should I refer to?
> 

Great, you can use this commit:

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/drivers/net/ethernet/stmicro/stmmac/stmmac_pci.c?id=26d6851fd24ed5d88580d66b4c8384947d5ca29b

Thanks!

Joao

Re: [PATCH v3 net-next 01/11] net: stmmac: prepare dma op mode config for multiple queues

[Joao Pinto]

Às 12:34 PM de 5/8/2017, Andy Shevchenko escreveu:
> On Mon, May 8, 2017 at 1:42 PM, Joao Pinto <joao.pi...@synopsys.com> wrote:
>> Às 11:12 AM de 5/8/2017, Andy Shevchenko escreveu:
>>> On Mon, May 8, 2017 at 12:54 PM, Joao Pinto <joao.pi...@synopsys.com> wrote:
>>>> Às 10:36 AM de 5/8/2017, Andy Shevchenko escreveu:
> 
>>>>> JFYI: With today's linux-next when _kexec:ed_ kernel boots I tried and
>>>>> got the following:
> 
>>>> Are you using the same version of Ethernet IP, 10/100?
>>>
>>> I'm running on Intel Galileo Gen2 board (v4.11 by the way works fine
>>> with direct boot from SD card)
>>>
>>>> Could you please verify if the crash you are experiencing is this place?
>>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__git.kernel.org_pub_scm_linux_kernel_git_torvalds_linux.git_tree_drivers_net_ethernet_stmicro_stmmac_stmmac-5Fmain.c-23n2956=DwIFaQ=DPL6_X_6JkXFx7AXWqB0tg=s2fO0hii0OGNOv9qQy_HRXy-xAJUD1NNoEcc3io_kx0=UF269QZ9ExFRw1XXpgdvO2QeTCLEp-GquRe8OqZwRf0=yZu3uME5PK-3nJlxz-H-HfHh3Shjzg0je5If_jSXVb4=
>>>>
>>>> I would say that for rather old IPs, the napi is not capable of giving a 
>>>> valid
>>>> queue number. Could you please print the queue index returned by this line?
>>>>
>>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__git.kernel.org_pub_scm_linux_kernel_git_torvalds_linux.git_tree_drivers_net_ethernet_stmicro_stmmac_stmmac-5Fmain.c-23n2948=DwIFaQ=DPL6_X_6JkXFx7AXWqB0tg=s2fO0hii0OGNOv9qQy_HRXy-xAJUD1NNoEcc3io_kx0=UF269QZ9ExFRw1XXpgdvO2QeTCLEp-GquRe8OqZwRf0=p_TgHODJum23I2N4AldR4oIaOPffSDpk9agmbRMQgoM=
>>>
>>> --- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
>>> +++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
>>> @@ -2953,7 +2953,9 @@ static netdev_tx_t stmmac_xmit(struct sk_buff
>>> *skb, struct net_device *dev)
>>>unsigned int enh_desc;
>>>unsigned int des;
>>>
>>> +   pr_info("%s <<< 1: priv %p, queue: %u\n", __func__, priv, queue);
>>>tx_q = >tx_queue[queue];
>>> +   pr_info("%s <<< 2: priv %p, queue: %u tx_q: %p\n", __func__,
>>> priv, queue, tx_q);
>>>
>>>
>>> [  101.591040] stmmac_xmit <<< 1: priv cdd1c4c0, queue: 7
>>> [  101.596377] stmmac_xmit <<< 2: priv cdd1c4c0, queue: 7 tx_q: cdd1caac
> 
>> I assume that the queue index is always 7 right? By return 7, the napi 
>> interface
>> 'thinks' that your setup is using 8 TX queues which I assume it is not and 
>> thats
>> the problem causing your board to malfuntion.
>>
>> Could you please check the values of the 'real' tx and rx queues count in 
>> this line?
>> https://urldefense.proofpoint.com/v2/url?u=https-3A__git.kernel.org_pub_scm_linux_kernel_git_torvalds_linux.git_tree_drivers_net_ethernet_stmicro_stmmac_stmmac-5Fmain.c-23n4107=DwIFaQ=DPL6_X_6JkXFx7AXWqB0tg=s2fO0hii0OGNOv9qQy_HRXy-xAJUD1NNoEcc3io_kx0=6PN46fgWi1XTHkxFzV9wkYHPkKJWvkRC1OOlEhyKdcA=cyYmWeYuPwacYmVRzJbhRm3Krz6XNyHbxq8t7ZUi8Ec=
>>  
>>
>> For default they are =1, so napi should be assuming 1RX and 1TX, and so you
>> should be getting queue index =0 in reception and transmission.
>>
>> In terms of reception, could you print the queue index that stmmac_poll is 
>> using
>> here:
>>
>> https://urldefense.proofpoint.com/v2/url?u=https-3A__git.kernel.org_pub_scm_linux_kernel_git_torvalds_linux.git_tree_drivers_net_ethernet_stmicro_stmmac_stmmac-5Fmain.c-23n3468=DwIFaQ=DPL6_X_6JkXFx7AXWqB0tg=s2fO0hii0OGNOv9qQy_HRXy-xAJUD1NNoEcc3io_kx0=6PN46fgWi1XTHkxFzV9wkYHPkKJWvkRC1OOlEhyKdcA=Xli0e7Key3FA7Rve_opcwc6W7nd4khVX15wwoNpFHL4=
>>  
> 
> +   pr_info("%s <<< %u\n", __func__, rx_q->queue_index);
>work_done = stmmac_rx(priv, budget, rx_q->queue_index);
>if (work_done < budget) {
>napi_complete_done(napi, work_done);
> 
>/* Configure real RX and TX queues */
>netif_set_real_num_rx_queues(ndev, priv->plat->rx_queues_to_use);
>netif_set_real_num_tx_queues(ndev, priv->plat->tx_queues_to_use);
> +   pr_info("%s <<< %hhu %hhu\n", __func__,
> priv->plat->rx_queues_to_use, priv->plat->tx_queues_to_use);
> 
> 
> [   44.374161] stmmac_dvr_probe <<< 0 0
> 

Ok, so this is the cause of the problem. The driver is geting 0 for real RX and
TX queues.

Your setup uses standard DT parsing from stmmac_platform or a custom one?

If you are using stmmac_probe_config_dt():
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c#n363

You will find a function named stmmac_mtl_setup() being called:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c#n492

In this function, the number of RX and TX queues is being set to 1 by default.

Joao


> [  109.014763] stmmac_xmit <<< 1: priv cdcea4c0, queue: 2
> [  109.020099] stmmac_xmit <<< 2: priv cdcea4c0, queue: 2 tx_q: cdcea9e4
> 
> That's all, no poll activated.
> 

Re: [PATCH v3 net-next 01/11] net: stmmac: prepare dma op mode config for multiple queues

[Joao Pinto]

Às 11:12 AM de 5/8/2017, Andy Shevchenko escreveu:
> On Mon, May 8, 2017 at 12:54 PM, Joao Pinto <joao.pi...@synopsys.com> wrote:
>> Hi Andy and Jan,
>>
>> Às 10:36 AM de 5/8/2017, Andy Shevchenko escreveu:
>>> On Mon, May 8, 2017 at 9:56 AM, Jan Kiszka <jan.kis...@siemens.com> wrote:
>>>> On 2017-03-15 12:04, Joao Pinto wrote:
>>>>> This patch prepares DMA Operation Mode configuration for multiple queues.
>>>>> The work consisted on breaking the DMA operation Mode configuration 
>>>>> function
>>>>> into RX and TX scope and adapting its mechanism in stmmac_main.
>>>
>>>> Starting with this patch, the stmmac-based network adapters of the Intel
>>>> Quark SoC stop working. I'm getting an IP via DHCP, I can ping, but TCP
>>>> connections can no longer be established.
> 
>>> JFYI: With today's linux-next when _kexec:ed_ kernel boots I tried and
>>> got the following:
>>>

snip (...)

>>>
>>>
>>
>> Are you using the same version of Ethernet IP, 10/100?
> 
> I'm running on Intel Galileo Gen2 board (v4.11 by the way works fine
> with direct boot from SD card)
> 
>> Could you please verify if the crash you are experiencing is this place?
>> https://urldefense.proofpoint.com/v2/url?u=https-3A__git.kernel.org_pub_scm_linux_kernel_git_torvalds_linux.git_tree_drivers_net_ethernet_stmicro_stmmac_stmmac-5Fmain.c-23n2956=DwIFaQ=DPL6_X_6JkXFx7AXWqB0tg=s2fO0hii0OGNOv9qQy_HRXy-xAJUD1NNoEcc3io_kx0=UF269QZ9ExFRw1XXpgdvO2QeTCLEp-GquRe8OqZwRf0=yZu3uME5PK-3nJlxz-H-HfHh3Shjzg0je5If_jSXVb4=
>>  
>>
>> I would say that for rather old IPs, the napi is not capable of giving a 
>> valid
>> queue number. Could you please print the queue index returned by this line?
>>
>> https://urldefense.proofpoint.com/v2/url?u=https-3A__git.kernel.org_pub_scm_linux_kernel_git_torvalds_linux.git_tree_drivers_net_ethernet_stmicro_stmmac_stmmac-5Fmain.c-23n2948=DwIFaQ=DPL6_X_6JkXFx7AXWqB0tg=s2fO0hii0OGNOv9qQy_HRXy-xAJUD1NNoEcc3io_kx0=UF269QZ9ExFRw1XXpgdvO2QeTCLEp-GquRe8OqZwRf0=p_TgHODJum23I2N4AldR4oIaOPffSDpk9agmbRMQgoM=
>>  
> 
> --- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
> +++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
> @@ -2953,7 +2953,9 @@ static netdev_tx_t stmmac_xmit(struct sk_buff
> *skb, struct net_device *dev)
>unsigned int enh_desc;
>unsigned int des;
> 
> +   pr_info("%s <<< 1: priv %p, queue: %u\n", __func__, priv, queue);
>tx_q = >tx_queue[queue];
> +   pr_info("%s <<< 2: priv %p, queue: %u tx_q: %p\n", __func__,
> priv, queue, tx_q);
> 
> 
> [  101.591040] stmmac_xmit <<< 1: priv cdd1c4c0, queue: 7
> [  101.596377] stmmac_xmit <<< 2: priv cdd1c4c0, queue: 7 tx_q: cdd1caac
> 

I assume that the queue index is always 7 right? By return 7, the napi interface
'thinks' that your setup is using 8 TX queues which I assume it is not and thats
the problem causing your board to malfuntion.

Could you please check the values of the 'real' tx and rx queues count in this 
line?
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c#n4107

For default they are =1, so napi should be assuming 1RX and 1TX, and so you
should be getting queue index =0 in reception and transmission.

In terms of reception, could you print the queue index that stmmac_poll is using
here:

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c#n3468

> 
> Also noticed warning that have to be addressed:
> 
> drivers/net/ethernet/stmicro/stmmac/stmmac_main.c:2504:49: warning:
> incorrect type in argument 1 (different address spaces)
> drivers/net/ethernet/stmicro/stmmac/stmmac_main.c:2504:49:expected
> void [noderef] *ioaddr
> drivers/net/ethernet/stmicro/stmmac/stmmac_main.c:2504:49:got
> struct mac_device_info *hw

This one was well caught! Although it has no influence in your setup, since you
don't have this callback implemented, eQOS (>= 4.00) and 1000 cores will have
issues if using PCS. I can make a patch for this one.

> 
> drivers/net/ethernet/stmicro/stmmac/stmmac_main.c: In function
> ‘init_dma_rx_desc_rings’:
> drivers/net/ethernet/stmicro/stmmac/stmmac_main.c:1274:15: warning:
> comparison of
> unsigned expression >= 0 is always true [-Wtype-limits]
>  while (queue >= 0) {
>   ^~

This one I have in my agenda to improve it, I also talked about it with Dan
Carpenter about it.

Re: [PATCH v3 net-next 01/11] net: stmmac: prepare dma op mode config for multiple queues

[Joao Pinto]

Hi Andy and Jan,

Às 10:36 AM de 5/8/2017, Andy Shevchenko escreveu:
> On Mon, May 8, 2017 at 9:56 AM, Jan Kiszka <jan.kis...@siemens.com> wrote:
>> On 2017-03-15 12:04, Joao Pinto wrote:
>>> This patch prepares DMA Operation Mode configuration for multiple queues.
>>> The work consisted on breaking the DMA operation Mode configuration function
>>> into RX and TX scope and adapting its mechanism in stmmac_main.
> 
>> Starting with this patch, the stmmac-based network adapters of the Intel
>> Quark SoC stop working. I'm getting an IP via DHCP, I can ping, but TCP
>> connections can no longer be established.
>>
>> Moving on a few patches (didn't bisect the exact one yet), the TX
>> watchdog starts to fire, and DHCP fails completely. And if I go to
>> current master in Linus tree (reverting an unrelated boot regression), I
>> even get a crash in stmmac_xmit.
>>
>> Here are some details about the hw from dma_cap POV, if this helps:
>>
>> ==
>> DMA HW features
>> ==
>> 10/100 Mbps: Y
>> 1000 Mbps: N
>> Half duplex: Y
>> Hash Filter: Y
>> Multiple MAC address registers: N
>> PCS (TBI/SGMII/RTBI PHY interfaces): N
>> SMA (MDIO) Interface: Y
>> PMT Remote wake up: N
>> PMT Magic Frame: N
>> RMON module: Y
>> IEEE 1588-2002 Time Stamp: N
>> IEEE 1588-2008 Advanced Time Stamp: Y
>> 802.3az - Energy-Efficient Ethernet (EEE): N
>> AV features: N
>> Checksum Offload in TX: Y
>> IP Checksum Offload (type1) in RX: N
>> IP Checksum Offload (type2) in RX: Y
>> RXFIFO > 2048bytes: Y
>> Number of Additional RX channel: 0
>> Number of Additional TX channel: 0
>> Enhanced descriptors: Y
>>
>> Given the number of different failure modes, my feeling is that there
>> are multiple regressions coming with these patches...
>>
>> I've tested on the IOT2000 board, but I suspect the Galileo Gen2 will be
>> affected equally. If you don't have access to any such device, let me
>> know what I can debug for you.
> 
> JFYI: With today's linux-next when _kexec:ed_ kernel boots I tried and
> got the following:
> 
> 
> # ip a s
> 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue qlen 1000
>link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
>inet 127.0.0.1/8 scope host lo
>   valid_lft forever preferred_lft forever
>inet6 ::1/128 scope host
>   valid_lft forever preferre[  130.403995] random: fast init done
> d_lft forever
> 2: eth0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop qlen 1000
>link/ether 00:00:00:00:00:00 brd ff:ff:ff:ff:ff:ff
> 3: eth1: <BROADCAST,MULTICAST> mtu 1500 qdisc noop qlen 1000
>link/ether 00:00:00:00:00:00 brd ff:ff:ff:ff:ff:ff
> 4: sit0@NONE:  mtu 1480 qdisc noop qlen 1000
>link/sit 0.0.0.0 brd 0.0.0.0
> # udhcpc -i eth0
> udhcpc: started, v1.26.2
> [  140.825131] stmmaceth :00:14.6 eth0: device MAC address 
> 98:4f:ee:05:ac:47
> [  140.834304] Generic PHY stmmac-a6:01: attached PHY driver [Generic
> PHY] (mii_bus:phy_addr=stmmac-a6:01, irq=-1)
> [  140.930871] stmmaceth :00:14.6 eth0: IEEE 1588-2008 Advanced
> Timestamp supported
> [  140.941109] stmmaceth :00:14.6 eth0: registered PTP clock
> [  140.953626] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready
> udhcpc: sending discover
> [  142.979557] stmmaceth :00:14.6 eth0: Link is Up - 100Mbps/Full
> - flow control off
> [  142.988756] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
> [  142.998810] BUG: unable to handle kernel NULL pointer dereference at   
> (null)
> [  143.006193] IP: stmmac_xmit+0xf1/0x1080
> [  143.010168] *pde = 
> [  143.010177]
> [  143.014762] Oops: 0002 [#1]
> [  143.017672] Modules linked in: at24 nvmem_core pwm_pca9685
> [  143.023338] CPU: 0 PID: 0 Comm: swapper Not tainted 4.11.0-next-20170508+ 
> #2
> [  143.030539] task: c8533580 task.stack: c852c000
> [  143.035237] EIP: stmmac_xmit+0xf1/0x1080
> [  143.039302] EFLAGS: 00010216 CPU: 0
> [  143.042915] EAX:  EBX: 0050 ECX:  EDX: ceb6a0c0
> [  143.049326] ESI:  EDI: cdd16000 EBP: cdc25d70 ESP: cdc25d20
> [  143.055735]  DS: 007b ES: 007b FS:  GS:  SS: 0068
> [  143.061271] CR0: 80050033 CR2:  CR3: 0eb5c000 CR4: 00100010
> [  143.067671] Call Trace:
> [  143.070238]  
> [  143.072763]  dev_hard_start_xmit+0x7c/0x1a0
> [  143.077120]  sch_direct_xmit+0xf0/0x120
> 

Re: [PATCH net-next v3] bindings: net: stmmac: add missing note about LPI interrupt

[Joao Pinto]

Hi Niklas,

Às 1:39 PM de 4/18/2017, Niklas Cassel escreveu:
> From: Niklas Cassel <niklas.cas...@axis.com>
> 
> The hardware has a LPI interrupt.
> There is already code in the stmmac driver to parse and handle the
> interrupt. However, this information was missing from the DT binding.
> 
> At the same time, improve the description of the existing interrupts.
> 
> Signed-off-by: Niklas Cassel <niklas.cas...@axis.com>
> ---
>  Documentation/devicetree/bindings/net/stmmac.txt | 13 -
>  1 file changed, 8 insertions(+), 5 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/net/stmmac.txt 
> b/Documentation/devicetree/bindings/net/stmmac.txt
> index f652b0c384ce..c3a7be6615c5 100644
> --- a/Documentation/devicetree/bindings/net/stmmac.txt
> +++ b/Documentation/devicetree/bindings/net/stmmac.txt
> @@ -7,9 +7,12 @@ Required properties:
>  - interrupt-parent: Should be the phandle for the interrupt controller
>that services interrupts for this device
>  - interrupts: Should contain the STMMAC interrupts
> -- interrupt-names: Should contain the interrupt names "macirq"
> -  "eth_wake_irq" if this interrupt is supported in the "interrupts"
> -  property
> +- interrupt-names: Should contain a list of interrupt names corresponding to
> + the interrupts in the interrupts property, if available.
> + Valid interrupt names are:
> +  - "macirq" (combined signal for various interrupt events)
> +  - "eth_wake_irq" (the interrupt to manage the remote wake-up packet 
> detection)
> +  - "eth_lpi" (the interrupt that occurs when Tx or Rx enters/exits LPI 
> state)
>  - phy-mode: See ethernet.txt file in the same directory.
>  - snps,reset-gpiogpio number for phy reset.
>  - snps,reset-active-low boolean flag to indicate if phy reset is active low.
> @@ -152,8 +155,8 @@ Examples:
>   compatible = "st,spear600-gmac";
>   reg = <0xe080 0x8000>;
>   interrupt-parent = <>;
> - interrupts = <24 23>;
> - interrupt-names = "macirq", "eth_wake_irq";
> + interrupts = <24 23 22>;
> + interrupt-names = "macirq", "eth_wake_irq", "eth_lpi";
>   mac-address = []; /* Filled in by U-Boot */
>   max-frame-size = <3800>;
>   phy-mode = "gmii";
> 

Acked-By: Joao Pinto <jpi...@synopsys.com>

Regards!

Re: [PATCH v2 net-next] net: stmmac: add drop transmit status feature

[Joao Pinto]

Hi Florian,

Às 6:43 PM de 4/12/2017, Florian Fainelli escreveu:
> On 04/12/2017 07:58 AM, Andrew Lunn wrote:
>> On Wed, Apr 12, 2017 at 01:07:02PM +0100, Joao Pinto wrote:
>>> Hi Andrew,
>>>
>>> Às 12:56 PM de 4/12/2017, Andrew Lunn escreveu:
>>>> On Wed, Apr 12, 2017 at 10:26:20AM +0100, Joao Pinto wrote:
>>>>> When the Drop Transmit Status bit is set, the Tx packet status
>>>>> received from the MAC is dropped in the MTL. When this bit is reset,
>>>>> the Tx packet status received from the MAC is forwarded to the
>>>>> application. This feature will cause a performance improvement.
>>>>>
>>>>> Signed-off-by: Joao Pinto <jpi...@synopsys.com>
>>>>> ---
>>>>> changes v1->v2:
>>>>> - removed mask from dwmac4_enable_tx_drop()
>>>>>
>>>>>  Documentation/devicetree/bindings/net/stmmac.txt  |  1 +
>>>>>  drivers/net/ethernet/stmicro/stmmac/common.h  |  2 ++
>>>>>  drivers/net/ethernet/stmicro/stmmac/dwmac4.h  |  1 +
>>>>>  drivers/net/ethernet/stmicro/stmmac/dwmac4_core.c | 12 
>>>>>  drivers/net/ethernet/stmicro/stmmac/stmmac_main.c |  3 +++
>>>>>  drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c |  2 ++
>>>>>  include/linux/stmmac.h|  1 +
>>>>>  7 files changed, 22 insertions(+)
>>>>>
>>>>> diff --git a/Documentation/devicetree/bindings/net/stmmac.txt 
>>>>> b/Documentation/devicetree/bindings/net/stmmac.txt
>>>>> index f652b0c..dbcb2cc 100644
>>>>> --- a/Documentation/devicetree/bindings/net/stmmac.txt
>>>>> +++ b/Documentation/devicetree/bindings/net/stmmac.txt
>>>>> @@ -60,6 +60,7 @@ Optional properties:
>>>>>and MAC2MAC connection.
>>>>>  - snps,tso: this enables the TSO feature otherwise it will be managed by
>>>>>MAC HW capability register. Only for GMAC4 and newer.
>>>>> +- snps,drop-tx-status: this enables drop tx status
>>>>
>>>> Hi Joao
>>>>
>>>> Was the conclusion from testing that this cannot be turned on by
>>>> default?
>>>
>>> This feature is great for applications that need good performance, but has a
>>> drawback since it has an impact in timestamp feature in Tx. There are some
>>> operations in PTP where the timestamp is given to the host through the TX 
>>> status
>>> in the descriptor, so this will have an impact.
>>>
>>> There's a way of solving this of course by making the driver checking the
>>> timestamp in the MAC_Tx_Timestamp_Status_XXX registers, but I can only look 
>>> into
>>> that feature later in the future.
>>
>> So the numbers you show, even if they are not on real hardware that
>> anybody uses, do look good.
>>
>> But i don't like this DT property, it sounds like it can potential do
>> bad things to PTP, and you say it can be done without the DT or PTP
>> problems. So I would personally NACK this patch, and ask you to
>> re-submit when you have solved these issues.
> 
> Is not it possible to simply figure out whether this can safely be
> enabled at run time or not? If nobody uses PTP, then turn that on as
> soon as you get someone using PTP, turn this back off?

Yes that might work, and cause a performance improvement since TX processing
would be lighter. According to the R, the PTP problem can be overcome by
reading a special register that contains the timestamping, but I will need to
investigate that more.

I am going to start working on TSN features soon, and then I will get the "Drop
Status" topic again with the PTP issue solved and submit the patch again.

> 
> The problem is the commit message is extremely scarce about what this
> implies, and quite frankly, I don't understand what "application" means
> here, whether this means:
> 
> - application in the sense of the HW IP, which is then, the OS'
> networking stack presumably?
> 
> - application in the sense of the OS, which is sort of conflated with
> the socket user?
> 
> Worst case, can't you create a new netdev feature (e.g: similar to
> NETIF_F_RXFCS) that allows dynamically turning this on based on user
> configuration? Not suggesting this is the right approach here, but it
> should be thought of. Maybe an ethtool private flag is more appropriate?
> 
> One perspective you need to look at is the following:
> 
> - as an IP vendor, you

Re: [PATCH v2 net-next] net: stmmac: add drop transmit status feature

[Joao Pinto]

Às 4:28 PM de 4/12/2017, David Miller escreveu:
> From: Joao Pinto <joao.pi...@synopsys.com>
> Date: Wed, 12 Apr 2017 16:13:33 +0100
> 
>> Às 3:51 PM de 4/12/2017, David Miller escreveu:
>>> You cannot develop performance based features and only test their
>>> impact on FPGA when almost all users are on real silicon.
>>>
>>> And this requirement is absolutely non-negotiable.
>>>
>>> You must test the impact on real silicon otherwise your performance
>>> numbers, which are required to be provided in the commit message
>>> for any "performance" feature or change, are completely useless.
>>
>> Next time I won't mention anything about performance, honestly. "Drop TX 
>> Status"
>> is just an IP Core feature that can or not be used, it is up to the driver 
>> user.
> 
> Being dishonest about why a change might be desirable doesn't help things, in 
> fact
> now that you've stated this intent in the future, people know to be 
> suspucious of
> your changes.

Dishonest? I just sent the patch adding a optional configuration that can boost
performance in applications where timestapping is not an issue. You can request
more info in stmmac.txt, but calling me dishonest is a bit out of line.

I perfectly accept if you feel that the patch is not useful, that's fine.

> 
> I seriously don't think you realize the ramifications of what you just said 
> right
> there.

No, I don't see honestly. I just said that I am a developer that has an interest
in the success of stmmac, but I don't want to steal maintenance seats :).

> 
> Everything here is about trust, and if you create a situation where you can't 
> be
> trusted then the process of doing upstream development will be extremely 
> difficult
> and time consuming for you.

Agree, trust is fundamental. I never gave reasons not to be trusted, in fact I
have a good relation with some of the stmmac developers and in other subsystems,
so I don't see the point of your observations.

> 
> Thanks.
> 

Joao

Re: [PATCH v2 net-next] net: stmmac: add drop transmit status feature

[Joao Pinto]

Hello,

Às 3:51 PM de 4/12/2017, David Miller escreveu:
> From: Joao Pinto <joao.pi...@synopsys.com>
> Date: Wed, 12 Apr 2017 14:55:03 +0100
> 
>> Understand your point, but for now our development and testing setup will be
>> based on the IP Prototyping Kit, consisting of a FPGA + PHY.
> 
> That's completely, and utterly, unacceptable.
> 
> I will be quite frank with you, that instances like this are causing
> people to contact me privately and telling me that your handling of
> becomming the stmmac driver maintainer is causing very real and
> serious concerns.

So, adding features to the driver are causing concerns to people? People don't
have to worry about maintenance, since goals are not to be a maintainer. My job
is just to help improve and add missing features to the driver and that's it.

> 
> You cannot develop performance based features and only test their
> impact on FPGA when almost all users are on real silicon.
> 
> And this requirement is absolutely non-negotiable.
> 
> You must test the impact on real silicon otherwise your performance
> numbers, which are required to be provided in the commit message
> for any "performance" feature or change, are completely useless.

Next time I won't mention anything about performance, honestly. "Drop TX Status"
is just an IP Core feature that can or not be used, it is up to the driver user.

> 
> I want your attitude on these matters to change quickly, as myself
> and many other interested parties are becomming extremely frustrated
> with how you are handling things.

Attitude? Are there complaints with my attitude? I try to help in everything I
can, I listen to feedback, I did the rework on the Multiple Buffers patch to try
to solve the negative impact in sunxi board. Sincerely I don't see a bad 
attitude.

Are you mentioning the e-mail about sxgbe?

> 
> Thank you.
> 

Thank you.

Re: [PATCH v2 net-next] net: stmmac: add drop transmit status feature

[Joao Pinto]

Às 2:52 PM de 4/12/2017, Andrew Lunn escreveu:
 My setup is FPGA based, so it will have lower performance values.
 Iperf results with
   "Drop Transmit Status" set: ~650Mbps.
   "Drop Transmit Status" unset: ~450Mbps.
>>>
>>> What percentage of your customers use FPGAs? When i look at the users
>>> of this driver, i see ST, Allwinner, Rockchip, Meson, etc. So silicon,
>>> not FPGA. Does it make sense to do performance measurements on FPGA,
>>> when you say it has lower performance?
>>
>> I don't understand your question. Synopsys is an IP vendor, so all recent IPs
>> are available for prototyping as you can understand and so early development 
>> is
>> done using a FPGA.
> 
> Sure, early development on FPGA makes sense. But my guess is, > 95% of
> the devices running this driver are silicon, not FPGA. The customers
> you sell the IP to want to know that the driver is going to work well
> on their silicon, not your internal FPGA development setup. The kernel
> community want a warm fuzzy feeling that you care about the real
> devices out in the wild using this driver. So if you could say, "I
> tested on a STM DISCO devel board, and performance went up 20%, an
> RK3288 devel board and got 18% performance boost, and a Merrii A80
> Optimus Board showed 22% improvements", we would have a lot better
> feeling about these patches.

Understand your point, but for now our development and testing setup will be
based on the IP Prototyping Kit, consisting of a FPGA + PHY.

Thanks,
Joao

> 
>   Andrew
> 

Re: [PATCH v2 net-next] net: stmmac: add drop transmit status feature

[Joao Pinto]

Às 2:10 PM de 4/12/2017, Andrew Lunn escreveu:
 +- snps,drop-tx-status: this enables drop tx status
>>>
>>> Hi Joao
>>>
>>> Was the conclusion from testing that this cannot be turned on by
>>> default?
>>
>> This feature is great for applications that need good performance, but has a
>> drawback since it has an impact in timestamp feature in Tx. There are some
>> operations in PTP where the timestamp is given to the host through the TX 
>> status
>> in the descriptor, so this will have an impact.
>>
>> There's a way of solving this of course by making the driver checking the
>> timestamp in the MAC_Tx_Timestamp_Status_XXX registers, but I can only look 
>> into
>> that feature later in the future.
> 
> The problem you have is that the device tree binding is a Binary API
> you have to keep backwards compatible with for the next 20 years. You
> cannot drop this property when you do get around to finishing the
> work. You also want to avoid adding more and more options, which
> nobody knows what they do, and what best combination is to get the
> best performance. You should be aiming for a driver which just works
> without any configuration and with good performance.
> 
>>> What sort of performance improvement did you get? Do you have some
>>> benchmark numbers?
>>
>> My setup is FPGA based, so it will have lower performance values.
>> Iperf results with
>>   "Drop Transmit Status" set: ~650Mbps.
>>   "Drop Transmit Status" unset: ~450Mbps.
> 
> What percentage of your customers use FPGAs? When i look at the users
> of this driver, i see ST, Allwinner, Rockchip, Meson, etc. So silicon,
> not FPGA. Does it make sense to do performance measurements on FPGA,
> when you say it has lower performance?

I don't understand your question. Synopsys is an IP vendor, so all recent IPs
are available for prototyping as you can understand and so early development is
done using a FPGA.

I only mentioned that the values were from a FPGA based setup because you could
think that they were low. Performance values are just an indication.

> 
>  Andrew
> 

Joao

Re: [PATCH v2 net-next] net: stmmac: add drop transmit status feature

[Joao Pinto]

Hi Andrew,

Às 12:56 PM de 4/12/2017, Andrew Lunn escreveu:
> On Wed, Apr 12, 2017 at 10:26:20AM +0100, Joao Pinto wrote:
>> When the Drop Transmit Status bit is set, the Tx packet status
>> received from the MAC is dropped in the MTL. When this bit is reset,
>> the Tx packet status received from the MAC is forwarded to the
>> application. This feature will cause a performance improvement.
>>
>> Signed-off-by: Joao Pinto <jpi...@synopsys.com>
>> ---
>> changes v1->v2:
>> - removed mask from dwmac4_enable_tx_drop()
>>
>>  Documentation/devicetree/bindings/net/stmmac.txt  |  1 +
>>  drivers/net/ethernet/stmicro/stmmac/common.h  |  2 ++
>>  drivers/net/ethernet/stmicro/stmmac/dwmac4.h  |  1 +
>>  drivers/net/ethernet/stmicro/stmmac/dwmac4_core.c | 12 
>>  drivers/net/ethernet/stmicro/stmmac/stmmac_main.c |  3 +++
>>  drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c |  2 ++
>>  include/linux/stmmac.h|  1 +
>>  7 files changed, 22 insertions(+)
>>
>> diff --git a/Documentation/devicetree/bindings/net/stmmac.txt 
>> b/Documentation/devicetree/bindings/net/stmmac.txt
>> index f652b0c..dbcb2cc 100644
>> --- a/Documentation/devicetree/bindings/net/stmmac.txt
>> +++ b/Documentation/devicetree/bindings/net/stmmac.txt
>> @@ -60,6 +60,7 @@ Optional properties:
>>   and MAC2MAC connection.
>>  - snps,tso: this enables the TSO feature otherwise it will be managed by
>>   MAC HW capability register. Only for GMAC4 and newer.
>> +- snps,drop-tx-status: this enables drop tx status
> 
> Hi Joao
> 
> Was the conclusion from testing that this cannot be turned on by
> default?

This feature is great for applications that need good performance, but has a
drawback since it has an impact in timestamp feature in Tx. There are some
operations in PTP where the timestamp is given to the host through the TX status
in the descriptor, so this will have an impact.

There's a way of solving this of course by making the driver checking the
timestamp in the MAC_Tx_Timestamp_Status_XXX registers, but I can only look into
that feature later in the future.

> 
> What sort of performance improvement did you get? Do you have some
> benchmark numbers?

My setup is FPGA based, so it will have lower performance values.
Iperf results with
  "Drop Transmit Status" set: ~650Mbps.
  "Drop Transmit Status" unset: ~450Mbps.

> 
> Andrew
> 

Joao

[PATCH v2 net-next] net: stmmac: add drop transmit status feature

[Joao Pinto]

When the Drop Transmit Status bit is set, the Tx packet status
received from the MAC is dropped in the MTL. When this bit is reset,
the Tx packet status received from the MAC is forwarded to the
application. This feature will cause a performance improvement.

Signed-off-by: Joao Pinto <jpi...@synopsys.com>
---
changes v1->v2:
- removed mask from dwmac4_enable_tx_drop()

 Documentation/devicetree/bindings/net/stmmac.txt  |  1 +
 drivers/net/ethernet/stmicro/stmmac/common.h  |  2 ++
 drivers/net/ethernet/stmicro/stmmac/dwmac4.h  |  1 +
 drivers/net/ethernet/stmicro/stmmac/dwmac4_core.c | 12 
 drivers/net/ethernet/stmicro/stmmac/stmmac_main.c |  3 +++
 drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c |  2 ++
 include/linux/stmmac.h|  1 +
 7 files changed, 22 insertions(+)

diff --git a/Documentation/devicetree/bindings/net/stmmac.txt 
b/Documentation/devicetree/bindings/net/stmmac.txt
index f652b0c..dbcb2cc 100644
--- a/Documentation/devicetree/bindings/net/stmmac.txt
+++ b/Documentation/devicetree/bindings/net/stmmac.txt
@@ -60,6 +60,7 @@ Optional properties:
 and MAC2MAC connection.
 - snps,tso: this enables the TSO feature otherwise it will be managed by
 MAC HW capability register. Only for GMAC4 and newer.
+- snps,drop-tx-status: this enables drop tx status
 - AXI BUS Mode parameters: below the list of all the parameters to program the
   AXI register inside the DMA module:
- snps,lpi_en: enable Low Power Interface
diff --git a/drivers/net/ethernet/stmicro/stmmac/common.h 
b/drivers/net/ethernet/stmicro/stmmac/common.h
index 90d28bc..312f9670 100644
--- a/drivers/net/ethernet/stmicro/stmmac/common.h
+++ b/drivers/net/ethernet/stmicro/stmmac/common.h
@@ -487,6 +487,8 @@ struct stmmac_ops {
/* RX Queues Routing */
void (*rx_queue_routing)(struct mac_device_info *hw, u8 packet,
 u32 queue);
+   /* Enable TX drop */
+   void (*enable_tx_drop)(struct mac_device_info *hw);
/* Program RX Algorithms */
void (*prog_mtl_rx_algorithms)(struct mac_device_info *hw, u32 rx_alg);
/* Program TX Algorithms */
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac4.h 
b/drivers/net/ethernet/stmicro/stmmac/dwmac4.h
index d74cedf..56ba01a 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac4.h
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac4.h
@@ -202,6 +202,7 @@ enum power_event {
 #define MTL_OPERATION_RAA  BIT(2)
 #define MTL_OPERATION_RAA_SP   (0x0 << 2)
 #define MTL_OPERATION_RAA_WSP  (0x1 << 2)
+#define MTL_OPERATION_DTXSTS   BIT(1)
 
 #define MTL_INT_STATUS 0x0c20
 #define MTL_INT_QX(x)  BIT(x)
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac4_core.c 
b/drivers/net/ethernet/stmicro/stmmac/dwmac4_core.c
index 48793f2..e9bc51c 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac4_core.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac4_core.c
@@ -142,6 +142,16 @@ static void dwmac4_tx_queue_routing(struct mac_device_info 
*hw,
writel(value, ioaddr + GMAC_RXQ_CTRL1);
 }
 
+static void dwmac4_enable_tx_drop(struct mac_device_info *hw)
+{
+   void __iomem *ioaddr = hw->pcsr;
+   u32 value = readl(ioaddr + MTL_OPERATION_MODE);
+
+   value |= MTL_OPERATION_DTXSTS;
+
+   writel(value, ioaddr + MTL_OPERATION_MODE);
+}
+
 static void dwmac4_prog_mtl_rx_algorithms(struct mac_device_info *hw,
  u32 rx_alg)
 {
@@ -675,6 +685,7 @@ static const struct stmmac_ops dwmac4_ops = {
.rx_queue_prio = dwmac4_rx_queue_priority,
.tx_queue_prio = dwmac4_tx_queue_priority,
.rx_queue_routing = dwmac4_tx_queue_routing,
+   .enable_tx_drop = dwmac4_enable_tx_drop,
.prog_mtl_rx_algorithms = dwmac4_prog_mtl_rx_algorithms,
.prog_mtl_tx_algorithms = dwmac4_prog_mtl_tx_algorithms,
.set_mtl_tx_queue_weight = dwmac4_set_mtl_tx_queue_weight,
@@ -706,6 +717,7 @@ static const struct stmmac_ops dwmac410_ops = {
.rx_queue_prio = dwmac4_rx_queue_priority,
.tx_queue_prio = dwmac4_tx_queue_priority,
.rx_queue_routing = dwmac4_tx_queue_routing,
+   .enable_tx_drop = dwmac4_enable_tx_drop,
.prog_mtl_rx_algorithms = dwmac4_prog_mtl_rx_algorithms,
.prog_mtl_tx_algorithms = dwmac4_prog_mtl_tx_algorithms,
.set_mtl_tx_queue_weight = dwmac4_set_mtl_tx_queue_weight,
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c 
b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
index a89f76b..bbde5b2 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
@@ -2368,6 +2368,9 @@ static void stmmac_mtl_configuration(struct stmmac_priv 
*priv)
u32 rx_queues_count = priv->plat->rx_queues_to_use;
u3

Re: [PATCH] net: stmmac: add drop transmit status feature

[Joao Pinto]

Hi Andrew,

Às 4:04 PM de 4/11/2017, Andrew Lunn escreveu:
> On Tue, Apr 11, 2017 at 03:44:10PM +0100, Joao Pinto wrote:
>> When the Drop Transmit Status bit is set, the Tx packet status
>> received from the MAC is dropped in the MTL. When this bit is reset,
>> the Tx packet status received from the MAC is forwarded to the
>> application. This feature will cause a performance improvement.
> 
> Hi Joao
> 
> Is there a reason not to turn this on by default?

The only reason is not to cause problems for other people setup by introducing a
new variable. In my setup is set by default.

@Niklas and Thierry: Could you please test this feature in order to see if it
boosts your perfomance? If it works fine in your setup we can follow Andrew idea
to turn it on by default.

> 
>Andrew
> 

Thanks.

[PATCH] net: stmmac: add drop transmit status feature

[Joao Pinto]

When the Drop Transmit Status bit is set, the Tx packet status
received from the MAC is dropped in the MTL. When this bit is reset,
the Tx packet status received from the MAC is forwarded to the
application. This feature will cause a performance improvement.

Signed-off-by: Joao Pinto <jpi...@synopsys.com>
---
 Documentation/devicetree/bindings/net/stmmac.txt  |  1 +
 drivers/net/ethernet/stmicro/stmmac/common.h  |  2 ++
 drivers/net/ethernet/stmicro/stmmac/dwmac4.h  |  1 +
 drivers/net/ethernet/stmicro/stmmac/dwmac4_core.c | 13 +
 drivers/net/ethernet/stmicro/stmmac/stmmac_main.c |  3 +++
 drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c |  2 ++
 include/linux/stmmac.h|  1 +
 7 files changed, 23 insertions(+)

diff --git a/Documentation/devicetree/bindings/net/stmmac.txt 
b/Documentation/devicetree/bindings/net/stmmac.txt
index f652b0c..dbcb2cc 100644
--- a/Documentation/devicetree/bindings/net/stmmac.txt
+++ b/Documentation/devicetree/bindings/net/stmmac.txt
@@ -60,6 +60,7 @@ Optional properties:
 and MAC2MAC connection.
 - snps,tso: this enables the TSO feature otherwise it will be managed by
 MAC HW capability register. Only for GMAC4 and newer.
+- snps,drop-tx-status: this enables drop tx status
 - AXI BUS Mode parameters: below the list of all the parameters to program the
   AXI register inside the DMA module:
- snps,lpi_en: enable Low Power Interface
diff --git a/drivers/net/ethernet/stmicro/stmmac/common.h 
b/drivers/net/ethernet/stmicro/stmmac/common.h
index 90d28bc..312f9670 100644
--- a/drivers/net/ethernet/stmicro/stmmac/common.h
+++ b/drivers/net/ethernet/stmicro/stmmac/common.h
@@ -487,6 +487,8 @@ struct stmmac_ops {
/* RX Queues Routing */
void (*rx_queue_routing)(struct mac_device_info *hw, u8 packet,
 u32 queue);
+   /* Enable TX drop */
+   void (*enable_tx_drop)(struct mac_device_info *hw);
/* Program RX Algorithms */
void (*prog_mtl_rx_algorithms)(struct mac_device_info *hw, u32 rx_alg);
/* Program TX Algorithms */
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac4.h 
b/drivers/net/ethernet/stmicro/stmmac/dwmac4.h
index d74cedf..56ba01a 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac4.h
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac4.h
@@ -202,6 +202,7 @@ enum power_event {
 #define MTL_OPERATION_RAA  BIT(2)
 #define MTL_OPERATION_RAA_SP   (0x0 << 2)
 #define MTL_OPERATION_RAA_WSP  (0x1 << 2)
+#define MTL_OPERATION_DTXSTS   BIT(1)
 
 #define MTL_INT_STATUS 0x0c20
 #define MTL_INT_QX(x)  BIT(x)
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac4_core.c 
b/drivers/net/ethernet/stmicro/stmmac/dwmac4_core.c
index 48793f2..a71e9db 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac4_core.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac4_core.c
@@ -142,6 +142,17 @@ static void dwmac4_tx_queue_routing(struct mac_device_info 
*hw,
writel(value, ioaddr + GMAC_RXQ_CTRL1);
 }
 
+static void dwmac4_enable_tx_drop(struct mac_device_info *hw)
+{
+   void __iomem *ioaddr = hw->pcsr;
+   u32 value = readl(ioaddr + MTL_OPERATION_MODE);
+
+   value &= ~MTL_OPERATION_DTXSTS;
+   value |= MTL_OPERATION_DTXSTS;
+
+   writel(value, ioaddr + MTL_OPERATION_MODE);
+}
+
 static void dwmac4_prog_mtl_rx_algorithms(struct mac_device_info *hw,
  u32 rx_alg)
 {
@@ -675,6 +686,7 @@ static const struct stmmac_ops dwmac4_ops = {
.rx_queue_prio = dwmac4_rx_queue_priority,
.tx_queue_prio = dwmac4_tx_queue_priority,
.rx_queue_routing = dwmac4_tx_queue_routing,
+   .enable_tx_drop = dwmac4_enable_tx_drop,
.prog_mtl_rx_algorithms = dwmac4_prog_mtl_rx_algorithms,
.prog_mtl_tx_algorithms = dwmac4_prog_mtl_tx_algorithms,
.set_mtl_tx_queue_weight = dwmac4_set_mtl_tx_queue_weight,
@@ -706,6 +718,7 @@ static const struct stmmac_ops dwmac410_ops = {
.rx_queue_prio = dwmac4_rx_queue_priority,
.tx_queue_prio = dwmac4_tx_queue_priority,
.rx_queue_routing = dwmac4_tx_queue_routing,
+   .enable_tx_drop = dwmac4_enable_tx_drop,
.prog_mtl_rx_algorithms = dwmac4_prog_mtl_rx_algorithms,
.prog_mtl_tx_algorithms = dwmac4_prog_mtl_tx_algorithms,
.set_mtl_tx_queue_weight = dwmac4_set_mtl_tx_queue_weight,
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c 
b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
index a89f76b..bbde5b2 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
@@ -2368,6 +2368,9 @@ static void stmmac_mtl_configuration(struct stmmac_priv 
*priv)
u32 rx_queues_count = priv->plat->rx_queues_to_use;
u32 tx_queues_count

Re: [PATCH net-next] net: stmmac: set total length of the packet to be transmitted in TDES3

[Joao Pinto]

Hi Niklas,

Às 7:33 PM de 4/10/2017, Niklas Cassel escreveu:
> From: Niklas Cassel 
> 
> Field FL/TPL in register TDES3 is not correctly set on GMAC4.
> TX appears to be functional on GMAC 4.10a even if this field is not set,
> however, to avoid relying on undefined behavior, set the length in TDES3.
> 
> The field has a different meaning depending on if the TSE bit in TDES3
> is set or not (TSO). However, regardless of the TSE bit, the field is
> not optional. The field is already set correctly when the TSE bit is set.
> 
> Since there is no limit for the number of descriptors that can be
> used for a single packet, the field should be set to the sum of
> the buffers contained in:
> [ ...  ...
> ], which should be equal to skb->len.
> 
> Signed-off-by: Niklas Cassel 

Sounds fine to me. Did you check for performance improvement? Thanks.

Joao

Suggestion: Merge of sxgbe to stmmac

[Joao Pinto]

Dear Byungho, Girish and David,

Today I was requested to analyse the Synopsys XGMAC IP support in the Linux
kernel and I found AMD' xgbe and Samsung's sxgbe drivers.

Samsung' driver has the same architecture as stmmac, so I am sending this e-mail
to suggest the merge of sxgbe to stmmac.

Currently stmmac supports older cores like MAC 10/100/1000 but also one of the
latest such as eQOS. The idea would be to add XGMAC support to stmmac by
creating a dwxgmac_core.c and dwxgmac_dma.c with all XGMAC operations related to
MAC and DMA and use the common infrastructure.

This would bring many advantages like:

a) xgmac support would be available for all Synopsys XGMAC IP users
b) stmmac has a great and wide community of users that maintain it, assuring
quality and latest features availability
c) avoid replication of code and this way we can work together and achieve
better results
d) maintaince becomes easier

I would like to hear your thoughts about the subject.

Thanks,
Joao

[PATCH] net: stmmac: use netif_set_real_num_{rx,tx}_queues

[Joao Pinto]

In the submission of the lastest multiple buffer patch set, this fix was lost.
I am sending this patch to put it right again. The fix was originally proposed
by Arnd Bergmann.

Signed-off-by: Arnd Bergmann <a...@arndb.de>
Signed-off-by: Joao Pinto <jpi...@synopsys.com>
---
 drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c 
b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
index a89f76b..85f315e 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
@@ -4103,8 +4103,8 @@ int stmmac_dvr_probe(struct device *device,
goto error_hw_init;
 
/* Configure real RX and TX queues */
-   ndev->real_num_rx_queues = priv->plat->rx_queues_to_use;
-   ndev->real_num_tx_queues = priv->plat->tx_queues_to_use;
+   netif_set_real_num_rx_queues(ndev, priv->plat->rx_queues_to_use);
+   netif_set_real_num_tx_queues(ndev, priv->plat->tx_queues_to_use);
 
ndev->netdev_ops = _netdev_ops;
 
-- 
2.9.3

[PATCH 3/4 v3 net-next] net: stmmac: adding multiple buffers for TX

[Joao Pinto]

This patch adds the structure stmmac_tx_queue which contains
tx queues specific data (previously in stmmac_priv).

Signed-off-by: Joao Pinto <jpi...@synopsys.com>
---
changes v1->v3:
- just to keep up with patch-set version

 drivers/net/ethernet/stmicro/stmmac/chain_mode.c  |  38 +-
 drivers/net/ethernet/stmicro/stmmac/ring_mode.c   |  46 +-
 drivers/net/ethernet/stmicro/stmmac/stmmac.h  |  26 +-
 drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 519 +-
 4 files changed, 374 insertions(+), 255 deletions(-)

diff --git a/drivers/net/ethernet/stmicro/stmmac/chain_mode.c 
b/drivers/net/ethernet/stmicro/stmmac/chain_mode.c
index 8db5a80..37881f8 100644
--- a/drivers/net/ethernet/stmicro/stmmac/chain_mode.c
+++ b/drivers/net/ethernet/stmicro/stmmac/chain_mode.c
@@ -26,12 +26,15 @@
 
 static int stmmac_jumbo_frm(void *p, struct sk_buff *skb, int csum)
 {
-   struct stmmac_priv *priv = (struct stmmac_priv *)p;
-   unsigned int entry = priv->cur_tx;
-   struct dma_desc *desc = priv->dma_tx + entry;
+   struct stmmac_tx_queue *tx_q = (struct stmmac_tx_queue *)p;
unsigned int nopaged_len = skb_headlen(skb);
+   struct stmmac_priv *priv = tx_q->priv_data;
+   unsigned int entry = tx_q->cur_tx;
unsigned int bmax, des2;
unsigned int i = 1, len;
+   struct dma_desc *desc;
+
+   desc = tx_q->dma_tx + entry;
 
if (priv->plat->enh_desc)
bmax = BUF_SIZE_8KiB;
@@ -45,16 +48,16 @@ static int stmmac_jumbo_frm(void *p, struct sk_buff *skb, 
int csum)
desc->des2 = cpu_to_le32(des2);
if (dma_mapping_error(priv->device, des2))
return -1;
-   priv->tx_skbuff_dma[entry].buf = des2;
-   priv->tx_skbuff_dma[entry].len = bmax;
+   tx_q->tx_skbuff_dma[entry].buf = des2;
+   tx_q->tx_skbuff_dma[entry].len = bmax;
/* do not close the descriptor and do not set own bit */
priv->hw->desc->prepare_tx_desc(desc, 1, bmax, csum, STMMAC_CHAIN_MODE,
0, false);
 
while (len != 0) {
-   priv->tx_skbuff[entry] = NULL;
+   tx_q->tx_skbuff[entry] = NULL;
entry = STMMAC_GET_ENTRY(entry, DMA_TX_SIZE);
-   desc = priv->dma_tx + entry;
+   desc = tx_q->dma_tx + entry;
 
if (len > bmax) {
des2 = dma_map_single(priv->device,
@@ -63,8 +66,8 @@ static int stmmac_jumbo_frm(void *p, struct sk_buff *skb, int 
csum)
desc->des2 = cpu_to_le32(des2);
if (dma_mapping_error(priv->device, des2))
return -1;
-   priv->tx_skbuff_dma[entry].buf = des2;
-   priv->tx_skbuff_dma[entry].len = bmax;
+   tx_q->tx_skbuff_dma[entry].buf = des2;
+   tx_q->tx_skbuff_dma[entry].len = bmax;
priv->hw->desc->prepare_tx_desc(desc, 0, bmax, csum,
STMMAC_CHAIN_MODE, 1,
false);
@@ -77,8 +80,8 @@ static int stmmac_jumbo_frm(void *p, struct sk_buff *skb, int 
csum)
desc->des2 = cpu_to_le32(des2);
if (dma_mapping_error(priv->device, des2))
return -1;
-   priv->tx_skbuff_dma[entry].buf = des2;
-   priv->tx_skbuff_dma[entry].len = len;
+   tx_q->tx_skbuff_dma[entry].buf = des2;
+   tx_q->tx_skbuff_dma[entry].len = len;
/* last descriptor can be set now */
priv->hw->desc->prepare_tx_desc(desc, 0, len, csum,
STMMAC_CHAIN_MODE, 1,
@@ -87,7 +90,7 @@ static int stmmac_jumbo_frm(void *p, struct sk_buff *skb, int 
csum)
}
}
 
-   priv->cur_tx = entry;
+   tx_q->cur_tx = entry;
 
return entry;
 }
@@ -152,17 +155,18 @@ static void stmmac_refill_desc3(void *priv_ptr, struct 
dma_desc *p)
 
 static void stmmac_clean_desc3(void *priv_ptr, struct dma_desc *p)
 {
-   struct stmmac_priv *priv = (struct stmmac_priv *)priv_ptr;
-   unsigned int entry = priv->dirty_tx;
+   struct stmmac_tx_queue *tx_q = (struct stmmac_tx_queue *)priv_ptr;
+   struct stmmac_priv *priv = tx_q->priv_data;
+   unsigned int entry = tx_q->dirty_tx;
 
-   if (priv->tx_skbuff_dma[entry].last_segment && !priv->extend_desc &&
+   if (tx_q->tx_skbuff_dma[entry].last_segment && !priv->extend_desc &&
priv->hwts_tx_en)
/* NOTE: Device will overwrite des3 with timestamp value if
 

[PATCH 4/4 v3 net-next] net: stmmac: adding multiple napi mechanism

[Joao Pinto]

This patch adds the napi variable to the stmmac_rx_queue
structure and forces that operations like netif_queue_stopped,
netif_wake_queue, netif_stop_queue, netdev_reset_queue and
netdev_sent_queue be made by queue.

Signed-off-by: Joao Pinto <jpi...@synopsys.com>
---
changes v2->v3:
- just to keep up with patch-set version
changes v1->v2:
- init_dma_desc_rings() and alloc_dma_desc_resources() placed back to
stmmac_open(), since they are not necessary anymore in probe() (old mechanism).

 drivers/net/ethernet/stmicro/stmmac/stmmac.h  |   3 +-
 drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 158 --
 2 files changed, 120 insertions(+), 41 deletions(-)

diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac.h 
b/drivers/net/ethernet/stmicro/stmmac/stmmac.h
index 359f8fd..33efe70 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac.h
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac.h
@@ -72,6 +72,7 @@ struct stmmac_rx_queue {
u32 rx_zeroc_thresh;
dma_addr_t dma_rx_phy;
u32 rx_tail_addr;
+   struct napi_struct napi cacheline_aligned_in_smp;
 };
 
 struct stmmac_priv {
@@ -91,8 +92,6 @@ struct stmmac_priv {
u32 rx_riwt;
int hwts_rx_en;
 
-   struct napi_struct napi cacheline_aligned_in_smp;
-
void __iomem *ioaddr;
struct net_device *dev;
struct device *device;
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c 
b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
index 56a081f..a89f76b 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
@@ -139,6 +139,64 @@ static void stmmac_verify_args(void)
 }
 
 /**
+ * stmmac_disable_all_queues - Disable all queues
+ * @priv: driver private structure
+ */
+static void stmmac_disable_all_queues(struct stmmac_priv *priv)
+{
+   u32 rx_queues_cnt = priv->plat->rx_queues_to_use;
+   u32 queue;
+
+   for (queue = 0; queue < rx_queues_cnt; queue++) {
+   struct stmmac_rx_queue *rx_q = >rx_queue[queue];
+
+   napi_disable(_q->napi);
+   }
+}
+
+/**
+ * stmmac_enable_all_queues - Enable all queues
+ * @priv: driver private structure
+ */
+static void stmmac_enable_all_queues(struct stmmac_priv *priv)
+{
+   u32 rx_queues_cnt = priv->plat->rx_queues_to_use;
+   u32 queue;
+
+   for (queue = 0; queue < rx_queues_cnt; queue++) {
+   struct stmmac_rx_queue *rx_q = >rx_queue[queue];
+
+   napi_enable(_q->napi);
+   }
+}
+
+/**
+ * stmmac_stop_all_queues - Stop all queues
+ * @priv: driver private structure
+ */
+static void stmmac_stop_all_queues(struct stmmac_priv *priv)
+{
+   u32 tx_queues_cnt = priv->plat->tx_queues_to_use;
+   u32 queue;
+
+   for (queue = 0; queue < tx_queues_cnt; queue++)
+   netif_tx_stop_queue(netdev_get_tx_queue(priv->dev, queue));
+}
+
+/**
+ * stmmac_start_all_queues - Start all queues
+ * @priv: driver private structure
+ */
+static void stmmac_start_all_queues(struct stmmac_priv *priv)
+{
+   u32 tx_queues_cnt = priv->plat->tx_queues_to_use;
+   u32 queue;
+
+   for (queue = 0; queue < tx_queues_cnt; queue++)
+   netif_tx_start_queue(netdev_get_tx_queue(priv->dev, queue));
+}
+
+/**
  * stmmac_clk_csr_set - dynamically set the MDC clock
  * @priv: driver private structure
  * Description: this is to dynamically set the MDC clock according to the csr
@@ -1262,7 +1320,6 @@ static int init_dma_tx_desc_rings(struct net_device *dev)
 
for (i = 0; i < DMA_TX_SIZE; i++) {
struct dma_desc *p;
-
if (priv->extend_desc)
p = &((tx_q->dma_etx + i)->basic);
else
@@ -1286,9 +1343,9 @@ static int init_dma_tx_desc_rings(struct net_device *dev)
 
tx_q->dirty_tx = 0;
tx_q->cur_tx = 0;
-   }
 
-   netdev_reset_queue(priv->dev);
+   netdev_tx_reset_queue(netdev_get_tx_queue(priv->dev, queue));
+   }
 
return 0;
 }
@@ -1805,13 +1862,16 @@ static void stmmac_tx_clean(struct stmmac_priv *priv, 
u32 queue)
}
tx_q->dirty_tx = entry;
 
-   netdev_completed_queue(priv->dev, pkts_compl, bytes_compl);
+   netdev_tx_completed_queue(netdev_get_tx_queue(priv->dev, queue),
+ pkts_compl, bytes_compl);
+
+   if (unlikely(netif_tx_queue_stopped(netdev_get_tx_queue(priv->dev,
+   queue))) &&
+   stmmac_tx_avail(priv, queue) > STMMAC_TX_THRESH) {
 
-   if (unlikely(netif_queue_stopped(priv->dev) &&
-   stmmac_tx_avail(priv, queue) > STMMAC_TX_THRESH)) {
netif_dbg(priv, tx_done, priv->dev,
  &qu

[PATCH 0/4 v3 net-next] net: stmmac: adding multiple buffers

[Joao Pinto]

This patch adds multiple buffers to stmmac in a more fragmented
way, in order to make problem debug easier.

I would kindly request to people to test this patch in their HWs in
order to check if everything's functional. Thank you.

Joao Pinto (4):
  net: stmmac: break some functions into RX and TX scopes
  net: stmmac: adding multiple buffers for rx
  net: stmmac: adding multiple buffers for TX
  net: stmmac: adding multiple napi mechanism

 drivers/net/ethernet/stmicro/stmmac/chain_mode.c  |   45 +-
 drivers/net/ethernet/stmicro/stmmac/ring_mode.c   |   46 +-
 drivers/net/ethernet/stmicro/stmmac/stmmac.h  |   49 +-
 drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 1260 ++---
 4 files changed, 950 insertions(+), 450 deletions(-)

-- 
2.9.3

[PATCH 1/4 v3 net-next] net: stmmac: break some functions into RX and TX scopes

[Joao Pinto]

This patch breaks several functions into RX and TX scopes, which
will be useful when adding multiple buffers mechanism.

Signed-off-by: Joao Pinto <jpi...@synopsys.com>
---
changes v2->v3:
- just to keep up with patch-set version
changes v1->v2:
- RX and TX inconsistency
- stmmac_free_rx_buffers renamed to stmmac_free_rx_buffer
- stmmac_free_tx_buffers renamed to stmmac_free_tx_buffer
- some useless comments were removed

 drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 352 --
 1 file changed, 266 insertions(+), 86 deletions(-)

diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c 
b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
index 7cbda41..ff839e1 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
@@ -889,24 +889,41 @@ static int stmmac_init_phy(struct net_device *dev)
return 0;
 }
 
-static void stmmac_display_rings(struct stmmac_priv *priv)
+static void stmmac_display_rx_rings(struct stmmac_priv *priv)
 {
-   void *head_rx, *head_tx;
+   void *head_rx;
 
-   if (priv->extend_desc) {
+   if (priv->extend_desc)
head_rx = (void *)priv->dma_erx;
-   head_tx = (void *)priv->dma_etx;
-   } else {
+   else
head_rx = (void *)priv->dma_rx;
-   head_tx = (void *)priv->dma_tx;
-   }
 
-   /* Display Rx ring */
+   /* Display RX ring */
priv->hw->desc->display_ring(head_rx, DMA_RX_SIZE, true);
-   /* Display Tx ring */
+}
+
+static void stmmac_display_tx_rings(struct stmmac_priv *priv)
+{
+   void *head_tx;
+
+   if (priv->extend_desc)
+   head_tx = (void *)priv->dma_etx;
+   else
+   head_tx = (void *)priv->dma_tx;
+
+   /* Display TX ring */
priv->hw->desc->display_ring(head_tx, DMA_TX_SIZE, false);
 }
 
+static void stmmac_display_rings(struct stmmac_priv *priv)
+{
+   /* Display RX ring */
+   stmmac_display_rx_rings(priv);
+
+   /* Display TX ring */
+   stmmac_display_tx_rings(priv);
+}
+
 static int stmmac_set_bfsize(int mtu, int bufsize)
 {
int ret = bufsize;
@@ -924,16 +941,16 @@ static int stmmac_set_bfsize(int mtu, int bufsize)
 }
 
 /**
- * stmmac_clear_descriptors - clear descriptors
+ * stmmac_clear_rx_descriptors - clear RX descriptors
  * @priv: driver private structure
- * Description: this function is called to clear the tx and rx descriptors
+ * Description: this function is called to clear the RX descriptors
  * in case of both basic and extended descriptors are used.
  */
-static void stmmac_clear_descriptors(struct stmmac_priv *priv)
+static void stmmac_clear_rx_descriptors(struct stmmac_priv *priv)
 {
int i;
 
-   /* Clear the Rx/Tx descriptors */
+   /* Clear the RX descriptors */
for (i = 0; i < DMA_RX_SIZE; i++)
if (priv->extend_desc)
priv->hw->desc->init_rx_desc(>dma_erx[i].basic,
@@ -943,6 +960,19 @@ static void stmmac_clear_descriptors(struct stmmac_priv 
*priv)
priv->hw->desc->init_rx_desc(>dma_rx[i],
 priv->use_riwt, priv->mode,
 (i == DMA_RX_SIZE - 1));
+}
+
+/**
+ * stmmac_clear_tx_descriptors - clear tx descriptors
+ * @priv: driver private structure
+ * Description: this function is called to clear the TX descriptors
+ * in case of both basic and extended descriptors are used.
+ */
+static void stmmac_clear_tx_descriptors(struct stmmac_priv *priv)
+{
+   int i;
+
+   /* Clear the TX descriptors */
for (i = 0; i < DMA_TX_SIZE; i++)
if (priv->extend_desc)
priv->hw->desc->init_tx_desc(>dma_etx[i].basic,
@@ -955,6 +985,21 @@ static void stmmac_clear_descriptors(struct stmmac_priv 
*priv)
 }
 
 /**
+ * stmmac_clear_descriptors - clear descriptors
+ * @priv: driver private structure
+ * Description: this function is called to clear the TX and RX descriptors
+ * in case of both basic and extended descriptors are used.
+ */
+static void stmmac_clear_descriptors(struct stmmac_priv *priv)
+{
+   /* Clear the RX descriptors */
+   stmmac_clear_rx_descriptors(priv);
+
+   /* Clear the TX descriptors */
+   stmmac_clear_tx_descriptors(priv);
+}
+
+/**
  * stmmac_init_rx_buffers - init the RX descriptor buffer.
  * @priv: driver private structure
  * @p: descriptor pointer
@@ -996,7 +1041,12 @@ static int stmmac_init_rx_buffers(struct stmmac_priv 
*priv, struct dma_desc *p,
return 0;
 }
 
-static void stmmac_free_rx_buffers(struct stmmac_priv *priv, int i)
+/**
+ * stmmac_free_rx_buffer - free RX dma buffers
+ * @priv: private structure
+ * @i: buffer index.
+ */
+static void stmmac_free_rx_buffer(struct stmmac_priv *priv, i

[PATCH 2/4 v3 net-next] net: stmmac: adding multiple buffers for rx

[Joao Pinto]

This patch adds the structure stmmac_rx_queue which contains
rx queues specific data (previously in stmmac_priv).

Signed-off-by: Joao Pinto <jpi...@synopsys.com>
---
changes v2->v3:
- fixed infinite loop in err_init_rx_buffers error handling
changes v1->v2:
- %d replaced by %u when printing unsigned
- err_init_rx_buffers treatment fixed

 drivers/net/ethernet/stmicro/stmmac/chain_mode.c  |   7 +-
 drivers/net/ethernet/stmicro/stmmac/stmmac.h  |  26 +-
 drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 457 ++
 3 files changed, 306 insertions(+), 184 deletions(-)

diff --git a/drivers/net/ethernet/stmicro/stmmac/chain_mode.c 
b/drivers/net/ethernet/stmicro/stmmac/chain_mode.c
index 01a8c02..8db5a80 100644
--- a/drivers/net/ethernet/stmicro/stmmac/chain_mode.c
+++ b/drivers/net/ethernet/stmicro/stmmac/chain_mode.c
@@ -136,15 +136,16 @@ static void stmmac_init_dma_chain(void *des, dma_addr_t 
phy_addr,
 
 static void stmmac_refill_desc3(void *priv_ptr, struct dma_desc *p)
 {
-   struct stmmac_priv *priv = (struct stmmac_priv *)priv_ptr;
+   struct stmmac_rx_queue *rx_q = (struct stmmac_rx_queue *)priv_ptr;
+   struct stmmac_priv *priv = rx_q->priv_data;
 
if (priv->hwts_rx_en && !priv->extend_desc)
/* NOTE: Device will overwrite des3 with timestamp value if
 * 1588-2002 time stamping is enabled, hence reinitialize it
 * to keep explicit chaining in the descriptor.
 */
-   p->des3 = cpu_to_le32((unsigned int)(priv->dma_rx_phy +
- (((priv->dirty_rx) + 1) %
+   p->des3 = cpu_to_le32((unsigned int)(rx_q->dma_rx_phy +
+ (((rx_q->dirty_rx) + 1) %
   DMA_RX_SIZE) *
  sizeof(struct dma_desc)));
 }
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac.h 
b/drivers/net/ethernet/stmicro/stmmac/stmmac.h
index cd8fb61..c7ad9e4 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac.h
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac.h
@@ -46,6 +46,20 @@ struct stmmac_tx_info {
bool is_jumbo;
 };
 
+struct stmmac_rx_queue {
+   u32 queue_index;
+   struct stmmac_priv *priv_data;
+   struct dma_extended_desc *dma_erx;
+   struct dma_desc *dma_rx cacheline_aligned_in_smp;
+   struct sk_buff **rx_skbuff;
+   dma_addr_t *rx_skbuff_dma;
+   unsigned int cur_rx;
+   unsigned int dirty_rx;
+   u32 rx_zeroc_thresh;
+   dma_addr_t dma_rx_phy;
+   u32 rx_tail_addr;
+};
+
 struct stmmac_priv {
/* Frequently used values are kept adjacent for cache effect */
struct dma_extended_desc *dma_etx cacheline_aligned_in_smp;
@@ -64,18 +78,10 @@ struct stmmac_priv {
struct timer_list txtimer;
bool tso;
 
-   struct dma_desc *dma_rx cacheline_aligned_in_smp;
-   struct dma_extended_desc *dma_erx;
-   struct sk_buff **rx_skbuff;
-   unsigned int cur_rx;
-   unsigned int dirty_rx;
unsigned int dma_buf_sz;
unsigned int rx_copybreak;
-   unsigned int rx_zeroc_thresh;
u32 rx_riwt;
int hwts_rx_en;
-   dma_addr_t *rx_skbuff_dma;
-   dma_addr_t dma_rx_phy;
 
struct napi_struct napi cacheline_aligned_in_smp;
 
@@ -85,6 +91,9 @@ struct stmmac_priv {
struct mac_device_info *hw;
spinlock_t lock;
 
+   /* RX Queue */
+   struct stmmac_rx_queue rx_queue[MTL_MAX_RX_QUEUES];
+
int oldlink;
int speed;
int oldduplex;
@@ -119,7 +128,6 @@ struct stmmac_priv {
spinlock_t ptp_lock;
void __iomem *mmcaddr;
void __iomem *ptpaddr;
-   u32 rx_tail_addr;
u32 tx_tail_addr;
u32 mss;
 
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c 
b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
index ff839e1..77caba4 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
@@ -197,14 +197,20 @@ static inline u32 stmmac_tx_avail(struct stmmac_priv 
*priv)
return avail;
 }
 
-static inline u32 stmmac_rx_dirty(struct stmmac_priv *priv)
+/**
+ * stmmac_rx_dirty - Get RX queue dirty
+ * @priv: driver private structure
+ * @queue: RX queue index
+ */
+static inline u32 stmmac_rx_dirty(struct stmmac_priv *priv, u32 queue)
 {
+   struct stmmac_rx_queue *rx_q = >rx_queue[queue];
u32 dirty;
 
-   if (priv->dirty_rx <= priv->cur_rx)
-   dirty = priv->cur_rx - priv->dirty_rx;
+   if (rx_q->dirty_rx <= rx_q->cur_rx)
+   dirty = rx_q->cur_rx - rx_q->dirty_rx;
else
-   dirty = DMA_RX_SIZE - priv->dirty_rx + priv->cur_rx;
+   dirty = DMA_RX_SIZE - rx_q->dirty_rx + rx_q->cur_rx;
 
return dirty

Re: [PATCH 0/4 v2 net-next] net: stmmac: adding multiple buffers

[Joao Pinto]

Às 5:59 PM de 4/5/2017, Corentin Labbe escreveu:
> On Wed, Apr 05, 2017 at 05:43:00PM +0100, Joao Pinto wrote:
>> This patch adds multiple buffers to stmmac in a more fragmented
>> way, in order to make problem debug easier.
>>
>> I would kindly request to people to test this patch in their HWs in
>> order to check if everything's functional. Thank you.
>>
>> Joao Pinto (4):
>>   net: stmmac: break some functions into RX and TX scopes
>>   net: stmmac: adding multiple buffers for RX
>>   net: stmmac: adding multiple buffers for TX
>>   net: stmmac: adding multiple napi mechanism
>>
>>  drivers/net/ethernet/stmicro/stmmac/chain_mode.c  |   45 +-
>>  drivers/net/ethernet/stmicro/stmmac/ring_mode.c   |   46 +-
>>  drivers/net/ethernet/stmicro/stmmac/stmmac.h  |   49 +-
>>  drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 1257 
>> ++---
>>  4 files changed, 947 insertions(+), 450 deletions(-)
>>
>> -- 
>> 2.9.3
>>
> 
> Hello
> 
> I have tested v1 and didn't hit any issue on dwmac-sunxi/dwmac-sun8i.
> I will test the v2 and send just after my tested-by
> 

Hi,
Great news!

Joao

> Regards
> 

Re: [PATCH 2/4 v2 net-next] net: stmmac: adding multiple buffers for RX (fwd)

[Joao Pinto]

Às 6:29 AM de 4/6/2017, Julia Lawall escreveu:
> It looks like an infinite loop, if queue is unsigned.
> 
> julia
> 

Yes you are right, I will fix it, thanks.

Joao

> -- Forwarded message --
> Date: Thu, 6 Apr 2017 11:49:01 +0800
> From: kbuild test robot <fengguang...@intel.com>
> To: kbu...@01.org
> Cc: Julia Lawall <julia.law...@lip6.fr>
> Subject: Re: [PATCH 2/4 v2 net-next] net: stmmac: adding multiple buffers for 
> RX
> 
> [auto build test WARNING on net-next/master]
> 
> url:
> https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_0day-2Dci_linux_commits_Joao-2DPinto_net-2Dstmmac-2Dbreak-2Dsome-2Dfunctions-2Dinto-2DRX-2Dand-2DTX-2Dscopes_20170406-2D081523=DwIBAg=DPL6_X_6JkXFx7AXWqB0tg=s2fO0hii0OGNOv9qQy_HRXy-xAJUD1NNoEcc3io_kx0=SF-IM8g8b7VBN_AjT6JxdRBYkTu-2huMLcFlVh_4YKw=h9uKHPp4P6ZsYsIGUk0YBvl3ToWDvBWaDUPv5JaNfF4=
>  
> :: branch date: 4 hours ago
> :: commit date: 4 hours ago
> 
>drivers/net/ethernet/stmicro/stmmac/stmmac_main.c:2852:15-20: WARNING: 
> Unsigned expression compared with zero: entry < 0
>>> drivers/net/ethernet/stmicro/stmmac/stmmac_main.c:1190:8-13: WARNING: 
>>> Unsigned expression compared with zero: queue >= 0
> 
> git remote add linux-review 
> https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_0day-2Dci_linux=DwIBAg=DPL6_X_6JkXFx7AXWqB0tg=s2fO0hii0OGNOv9qQy_HRXy-xAJUD1NNoEcc3io_kx0=SF-IM8g8b7VBN_AjT6JxdRBYkTu-2huMLcFlVh_4YKw=q4A5_6A5zp5DRgmx5IJbDiIpc2W3GK3tSNhqpyIaHX8=
>  
> git remote update linux-review
> git checkout b403b5806dca0f85904ddc6cf2241286da86ed9b
> vim +1190 drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
> 
> b6ad2502 Joao Pinto 2017-04-05  1174  if 
> (priv->extend_desc)
> b403b580 Joao Pinto 2017-04-05  1175  
> priv->hw->mode->init(rx_q->dma_erx,
> b403b580 Joao Pinto 2017-04-05  1176  
>  rx_q->dma_rx_phy,
> e3ad57c9 Giuseppe Cavallaro 2016-02-29  1177      
>  DMA_RX_SIZE, 1);
> b6ad2502 Joao Pinto 2017-04-05  1178  else
> b403b580 Joao Pinto 2017-04-05  1179  
> priv->hw->mode->init(rx_q->dma_rx,
> b403b580 Joao Pinto 2017-04-05  1180  
>  rx_q->dma_rx_phy,
> e3ad57c9 Giuseppe Cavallaro 2016-02-29  1181      
>  DMA_RX_SIZE, 0);
> b6ad2502 Joao Pinto 2017-04-05  1182      }
> b403b580 Joao Pinto 2017-04-05  1183  }
> b403b580 Joao Pinto 2017-04-05  1184
> b403b580 Joao Pinto     2017-04-05  1185  buf_sz = bfsize;
> b6ad2502 Joao Pinto 2017-04-05  1186
> b6ad2502 Joao Pinto 2017-04-05  1187      return 0;
> b403b580 Joao Pinto 2017-04-05  1188
> b6ad2502 Joao Pinto 2017-04-05  1189  err_init_rx_buffers:
> b403b580 Joao Pinto 2017-04-05 @1190  while (queue >= 0) {
> b6ad2502 Joao Pinto 2017-04-05  1191  while (--i >= 0)
> b403b580 Joao Pinto 2017-04-05  1192  
> stmmac_free_rx_buffer(priv, queue, i);
> b403b580 Joao Pinto 2017-04-05  1193
> b403b580 Joao Pinto     2017-04-05  1194  i = DMA_RX_SIZE;
> b403b580 Joao Pinto 2017-04-05  1195  queue--;
> b403b580 Joao Pinto 2017-04-05  1196  }
> b403b580 Joao Pinto 2017-04-05  1197
> b6ad2502 Joao Pinto 2017-04-05  1198  return ret;
> 
> ---
> 0-DAY kernel test infrastructureOpen Source Technology Center
> https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.01.org_pipermail_kbuild-2Dall=DwIBAg=DPL6_X_6JkXFx7AXWqB0tg=s2fO0hii0OGNOv9qQy_HRXy-xAJUD1NNoEcc3io_kx0=SF-IM8g8b7VBN_AjT6JxdRBYkTu-2huMLcFlVh_4YKw=g4EUS_5pRcIV-m5yRBYE0N_JUxlnC68-_z4v2N9zdaU=
> Intel Corporation
> 

[PATCH 2/4 v2 net-next] net: stmmac: adding multiple buffers for RX

[Joao Pinto]

This patch adds the structure stmmac_rx_queue which contains
rx queues specific data (previously in stmmac_priv).

Signed-off-by: Joao Pinto <jpi...@synopsys.com>
---
changes v1->v2:
- %d replaced by %u when printing unsigned
- err_init_rx_buffers treatment fixed

 drivers/net/ethernet/stmicro/stmmac/chain_mode.c  |   7 +-
 drivers/net/ethernet/stmicro/stmmac/stmmac.h  |  26 +-
 drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 454 ++
 3 files changed, 303 insertions(+), 184 deletions(-)

diff --git a/drivers/net/ethernet/stmicro/stmmac/chain_mode.c 
b/drivers/net/ethernet/stmicro/stmmac/chain_mode.c
index 01a8c02..8db5a80 100644
--- a/drivers/net/ethernet/stmicro/stmmac/chain_mode.c
+++ b/drivers/net/ethernet/stmicro/stmmac/chain_mode.c
@@ -136,15 +136,16 @@ static void stmmac_init_dma_chain(void *des, dma_addr_t 
phy_addr,
 
 static void stmmac_refill_desc3(void *priv_ptr, struct dma_desc *p)
 {
-   struct stmmac_priv *priv = (struct stmmac_priv *)priv_ptr;
+   struct stmmac_rx_queue *rx_q = (struct stmmac_rx_queue *)priv_ptr;
+   struct stmmac_priv *priv = rx_q->priv_data;
 
if (priv->hwts_rx_en && !priv->extend_desc)
/* NOTE: Device will overwrite des3 with timestamp value if
 * 1588-2002 time stamping is enabled, hence reinitialize it
 * to keep explicit chaining in the descriptor.
 */
-   p->des3 = cpu_to_le32((unsigned int)(priv->dma_rx_phy +
- (((priv->dirty_rx) + 1) %
+   p->des3 = cpu_to_le32((unsigned int)(rx_q->dma_rx_phy +
+ (((rx_q->dirty_rx) + 1) %
   DMA_RX_SIZE) *
  sizeof(struct dma_desc)));
 }
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac.h 
b/drivers/net/ethernet/stmicro/stmmac/stmmac.h
index cd8fb61..c7ad9e4 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac.h
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac.h
@@ -46,6 +46,20 @@ struct stmmac_tx_info {
bool is_jumbo;
 };
 
+struct stmmac_rx_queue {
+   u32 queue_index;
+   struct stmmac_priv *priv_data;
+   struct dma_extended_desc *dma_erx;
+   struct dma_desc *dma_rx cacheline_aligned_in_smp;
+   struct sk_buff **rx_skbuff;
+   dma_addr_t *rx_skbuff_dma;
+   unsigned int cur_rx;
+   unsigned int dirty_rx;
+   u32 rx_zeroc_thresh;
+   dma_addr_t dma_rx_phy;
+   u32 rx_tail_addr;
+};
+
 struct stmmac_priv {
/* Frequently used values are kept adjacent for cache effect */
struct dma_extended_desc *dma_etx cacheline_aligned_in_smp;
@@ -64,18 +78,10 @@ struct stmmac_priv {
struct timer_list txtimer;
bool tso;
 
-   struct dma_desc *dma_rx cacheline_aligned_in_smp;
-   struct dma_extended_desc *dma_erx;
-   struct sk_buff **rx_skbuff;
-   unsigned int cur_rx;
-   unsigned int dirty_rx;
unsigned int dma_buf_sz;
unsigned int rx_copybreak;
-   unsigned int rx_zeroc_thresh;
u32 rx_riwt;
int hwts_rx_en;
-   dma_addr_t *rx_skbuff_dma;
-   dma_addr_t dma_rx_phy;
 
struct napi_struct napi cacheline_aligned_in_smp;
 
@@ -85,6 +91,9 @@ struct stmmac_priv {
struct mac_device_info *hw;
spinlock_t lock;
 
+   /* RX Queue */
+   struct stmmac_rx_queue rx_queue[MTL_MAX_RX_QUEUES];
+
int oldlink;
int speed;
int oldduplex;
@@ -119,7 +128,6 @@ struct stmmac_priv {
spinlock_t ptp_lock;
void __iomem *mmcaddr;
void __iomem *ptpaddr;
-   u32 rx_tail_addr;
u32 tx_tail_addr;
u32 mss;
 
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c 
b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
index ff839e1..5892796 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
@@ -197,14 +197,20 @@ static inline u32 stmmac_tx_avail(struct stmmac_priv 
*priv)
return avail;
 }
 
-static inline u32 stmmac_rx_dirty(struct stmmac_priv *priv)
+/**
+ * stmmac_rx_dirty - Get RX queue dirty
+ * @priv: driver private structure
+ * @queue: RX queue index
+ */
+static inline u32 stmmac_rx_dirty(struct stmmac_priv *priv, u32 queue)
 {
+   struct stmmac_rx_queue *rx_q = >rx_queue[queue];
u32 dirty;
 
-   if (priv->dirty_rx <= priv->cur_rx)
-   dirty = priv->cur_rx - priv->dirty_rx;
+   if (rx_q->dirty_rx <= rx_q->cur_rx)
+   dirty = rx_q->cur_rx - rx_q->dirty_rx;
else
-   dirty = DMA_RX_SIZE - priv->dirty_rx + priv->cur_rx;
+   dirty = DMA_RX_SIZE - rx_q->dirty_rx + rx_q->cur_rx;
 
return dirty;
 }
@@ -891,15 +897,24 @@ static int stmmac_init_phy(struct net_device *dev)
 
 static 

[PATCH 1/4 v2 net-next] net: stmmac: break some functions into RX and TX scopes

[Joao Pinto]

This patch breaks several functions into RX and TX scopes, which
will be useful when adding multiple buffers mechanism.

Signed-off-by: Joao Pinto <jpi...@synopsys.com>
---
changes v1->v2:
- RX and TX inconsistency
- stmmac_free_rx_buffers renamed to stmmac_free_rx_buffer
- stmmac_free_tx_buffers renamed to stmmac_free_tx_buffer
- some useless comments were removed

 drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 352 --
 1 file changed, 266 insertions(+), 86 deletions(-)

diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c 
b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
index 7cbda41..ff839e1 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
@@ -889,24 +889,41 @@ static int stmmac_init_phy(struct net_device *dev)
return 0;
 }
 
-static void stmmac_display_rings(struct stmmac_priv *priv)
+static void stmmac_display_rx_rings(struct stmmac_priv *priv)
 {
-   void *head_rx, *head_tx;
+   void *head_rx;
 
-   if (priv->extend_desc) {
+   if (priv->extend_desc)
head_rx = (void *)priv->dma_erx;
-   head_tx = (void *)priv->dma_etx;
-   } else {
+   else
head_rx = (void *)priv->dma_rx;
-   head_tx = (void *)priv->dma_tx;
-   }
 
-   /* Display Rx ring */
+   /* Display RX ring */
priv->hw->desc->display_ring(head_rx, DMA_RX_SIZE, true);
-   /* Display Tx ring */
+}
+
+static void stmmac_display_tx_rings(struct stmmac_priv *priv)
+{
+   void *head_tx;
+
+   if (priv->extend_desc)
+   head_tx = (void *)priv->dma_etx;
+   else
+   head_tx = (void *)priv->dma_tx;
+
+   /* Display TX ring */
priv->hw->desc->display_ring(head_tx, DMA_TX_SIZE, false);
 }
 
+static void stmmac_display_rings(struct stmmac_priv *priv)
+{
+   /* Display RX ring */
+   stmmac_display_rx_rings(priv);
+
+   /* Display TX ring */
+   stmmac_display_tx_rings(priv);
+}
+
 static int stmmac_set_bfsize(int mtu, int bufsize)
 {
int ret = bufsize;
@@ -924,16 +941,16 @@ static int stmmac_set_bfsize(int mtu, int bufsize)
 }
 
 /**
- * stmmac_clear_descriptors - clear descriptors
+ * stmmac_clear_rx_descriptors - clear RX descriptors
  * @priv: driver private structure
- * Description: this function is called to clear the tx and rx descriptors
+ * Description: this function is called to clear the RX descriptors
  * in case of both basic and extended descriptors are used.
  */
-static void stmmac_clear_descriptors(struct stmmac_priv *priv)
+static void stmmac_clear_rx_descriptors(struct stmmac_priv *priv)
 {
int i;
 
-   /* Clear the Rx/Tx descriptors */
+   /* Clear the RX descriptors */
for (i = 0; i < DMA_RX_SIZE; i++)
if (priv->extend_desc)
priv->hw->desc->init_rx_desc(>dma_erx[i].basic,
@@ -943,6 +960,19 @@ static void stmmac_clear_descriptors(struct stmmac_priv 
*priv)
priv->hw->desc->init_rx_desc(>dma_rx[i],
 priv->use_riwt, priv->mode,
 (i == DMA_RX_SIZE - 1));
+}
+
+/**
+ * stmmac_clear_tx_descriptors - clear tx descriptors
+ * @priv: driver private structure
+ * Description: this function is called to clear the TX descriptors
+ * in case of both basic and extended descriptors are used.
+ */
+static void stmmac_clear_tx_descriptors(struct stmmac_priv *priv)
+{
+   int i;
+
+   /* Clear the TX descriptors */
for (i = 0; i < DMA_TX_SIZE; i++)
if (priv->extend_desc)
priv->hw->desc->init_tx_desc(>dma_etx[i].basic,
@@ -955,6 +985,21 @@ static void stmmac_clear_descriptors(struct stmmac_priv 
*priv)
 }
 
 /**
+ * stmmac_clear_descriptors - clear descriptors
+ * @priv: driver private structure
+ * Description: this function is called to clear the TX and RX descriptors
+ * in case of both basic and extended descriptors are used.
+ */
+static void stmmac_clear_descriptors(struct stmmac_priv *priv)
+{
+   /* Clear the RX descriptors */
+   stmmac_clear_rx_descriptors(priv);
+
+   /* Clear the TX descriptors */
+   stmmac_clear_tx_descriptors(priv);
+}
+
+/**
  * stmmac_init_rx_buffers - init the RX descriptor buffer.
  * @priv: driver private structure
  * @p: descriptor pointer
@@ -996,7 +1041,12 @@ static int stmmac_init_rx_buffers(struct stmmac_priv 
*priv, struct dma_desc *p,
return 0;
 }
 
-static void stmmac_free_rx_buffers(struct stmmac_priv *priv, int i)
+/**
+ * stmmac_free_rx_buffer - free RX dma buffers
+ * @priv: private structure
+ * @i: buffer index.
+ */
+static void stmmac_free_rx_buffer(struct stmmac_priv *priv, int i)
 {
if (priv->rx_skbuff[i]) {
dm

[PATCH 4/4 v2 net-next] net: stmmac: adding multiple napi mechanism

[Joao Pinto]

This patch adds the napi variable to the stmmac_rx_queue
structure and forces that operations like netif_queue_stopped,
netif_wake_queue, netif_stop_queue, netdev_reset_queue and
netdev_sent_queue be made by queue.

Signed-off-by: Joao Pinto <jpi...@synopsys.com>
---
changes v1->v2:
- init_dma_desc_rings() and alloc_dma_desc_resources() placed back to
stmmac_open(), since they are not necessary anymore in probe() (old mechanism).

 drivers/net/ethernet/stmicro/stmmac/stmmac.h  |   3 +-
 drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 158 --
 2 files changed, 120 insertions(+), 41 deletions(-)

diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac.h 
b/drivers/net/ethernet/stmicro/stmmac/stmmac.h
index 359f8fd..33efe70 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac.h
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac.h
@@ -72,6 +72,7 @@ struct stmmac_rx_queue {
u32 rx_zeroc_thresh;
dma_addr_t dma_rx_phy;
u32 rx_tail_addr;
+   struct napi_struct napi cacheline_aligned_in_smp;
 };
 
 struct stmmac_priv {
@@ -91,8 +92,6 @@ struct stmmac_priv {
u32 rx_riwt;
int hwts_rx_en;
 
-   struct napi_struct napi cacheline_aligned_in_smp;
-
void __iomem *ioaddr;
struct net_device *dev;
struct device *device;
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c 
b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
index 487f702..3d22473 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
@@ -139,6 +139,64 @@ static void stmmac_verify_args(void)
 }
 
 /**
+ * stmmac_disable_all_queues - Disable all queues
+ * @priv: driver private structure
+ */
+static void stmmac_disable_all_queues(struct stmmac_priv *priv)
+{
+   u32 rx_queues_cnt = priv->plat->rx_queues_to_use;
+   u32 queue;
+
+   for (queue = 0; queue < rx_queues_cnt; queue++) {
+   struct stmmac_rx_queue *rx_q = >rx_queue[queue];
+
+   napi_disable(_q->napi);
+   }
+}
+
+/**
+ * stmmac_enable_all_queues - Enable all queues
+ * @priv: driver private structure
+ */
+static void stmmac_enable_all_queues(struct stmmac_priv *priv)
+{
+   u32 rx_queues_cnt = priv->plat->rx_queues_to_use;
+   u32 queue;
+
+   for (queue = 0; queue < rx_queues_cnt; queue++) {
+   struct stmmac_rx_queue *rx_q = >rx_queue[queue];
+
+   napi_enable(_q->napi);
+   }
+}
+
+/**
+ * stmmac_stop_all_queues - Stop all queues
+ * @priv: driver private structure
+ */
+static void stmmac_stop_all_queues(struct stmmac_priv *priv)
+{
+   u32 tx_queues_cnt = priv->plat->tx_queues_to_use;
+   u32 queue;
+
+   for (queue = 0; queue < tx_queues_cnt; queue++)
+   netif_tx_stop_queue(netdev_get_tx_queue(priv->dev, queue));
+}
+
+/**
+ * stmmac_start_all_queues - Start all queues
+ * @priv: driver private structure
+ */
+static void stmmac_start_all_queues(struct stmmac_priv *priv)
+{
+   u32 tx_queues_cnt = priv->plat->tx_queues_to_use;
+   u32 queue;
+
+   for (queue = 0; queue < tx_queues_cnt; queue++)
+   netif_tx_start_queue(netdev_get_tx_queue(priv->dev, queue));
+}
+
+/**
  * stmmac_clk_csr_set - dynamically set the MDC clock
  * @priv: driver private structure
  * Description: this is to dynamically set the MDC clock according to the csr
@@ -1259,7 +1317,6 @@ static int init_dma_tx_desc_rings(struct net_device *dev)
 
for (i = 0; i < DMA_TX_SIZE; i++) {
struct dma_desc *p;
-
if (priv->extend_desc)
p = &((tx_q->dma_etx + i)->basic);
else
@@ -1283,9 +1340,9 @@ static int init_dma_tx_desc_rings(struct net_device *dev)
 
tx_q->dirty_tx = 0;
tx_q->cur_tx = 0;
-   }
 
-   netdev_reset_queue(priv->dev);
+   netdev_tx_reset_queue(netdev_get_tx_queue(priv->dev, queue));
+   }
 
return 0;
 }
@@ -1802,13 +1859,16 @@ static void stmmac_tx_clean(struct stmmac_priv *priv, 
u32 queue)
}
tx_q->dirty_tx = entry;
 
-   netdev_completed_queue(priv->dev, pkts_compl, bytes_compl);
+   netdev_tx_completed_queue(netdev_get_tx_queue(priv->dev, queue),
+ pkts_compl, bytes_compl);
+
+   if (unlikely(netif_tx_queue_stopped(netdev_get_tx_queue(priv->dev,
+   queue))) &&
+   stmmac_tx_avail(priv, queue) > STMMAC_TX_THRESH) {
 
-   if (unlikely(netif_queue_stopped(priv->dev) &&
-   stmmac_tx_avail(priv, queue) > STMMAC_TX_THRESH)) {
netif_dbg(priv, tx_done, priv->dev,
  "%s: restart transmit\n", __func__);
-

[PATCH 3/4 v2 net-next] net: stmmac: adding multiple buffers for TX

[Joao Pinto]

This patch adds the structure stmmac_tx_queue which contains
tx queues specific data (previously in stmmac_priv).

Signed-off-by: Joao Pinto <jpi...@synopsys.com>
---
changes v1->v2:
- just to keep up with patch-set version

 drivers/net/ethernet/stmicro/stmmac/chain_mode.c  |  38 +-
 drivers/net/ethernet/stmicro/stmmac/ring_mode.c   |  46 +-
 drivers/net/ethernet/stmicro/stmmac/stmmac.h  |  26 +-
 drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 519 +-
 4 files changed, 374 insertions(+), 255 deletions(-)

diff --git a/drivers/net/ethernet/stmicro/stmmac/chain_mode.c 
b/drivers/net/ethernet/stmicro/stmmac/chain_mode.c
index 8db5a80..37881f8 100644
--- a/drivers/net/ethernet/stmicro/stmmac/chain_mode.c
+++ b/drivers/net/ethernet/stmicro/stmmac/chain_mode.c
@@ -26,12 +26,15 @@
 
 static int stmmac_jumbo_frm(void *p, struct sk_buff *skb, int csum)
 {
-   struct stmmac_priv *priv = (struct stmmac_priv *)p;
-   unsigned int entry = priv->cur_tx;
-   struct dma_desc *desc = priv->dma_tx + entry;
+   struct stmmac_tx_queue *tx_q = (struct stmmac_tx_queue *)p;
unsigned int nopaged_len = skb_headlen(skb);
+   struct stmmac_priv *priv = tx_q->priv_data;
+   unsigned int entry = tx_q->cur_tx;
unsigned int bmax, des2;
unsigned int i = 1, len;
+   struct dma_desc *desc;
+
+   desc = tx_q->dma_tx + entry;
 
if (priv->plat->enh_desc)
bmax = BUF_SIZE_8KiB;
@@ -45,16 +48,16 @@ static int stmmac_jumbo_frm(void *p, struct sk_buff *skb, 
int csum)
desc->des2 = cpu_to_le32(des2);
if (dma_mapping_error(priv->device, des2))
return -1;
-   priv->tx_skbuff_dma[entry].buf = des2;
-   priv->tx_skbuff_dma[entry].len = bmax;
+   tx_q->tx_skbuff_dma[entry].buf = des2;
+   tx_q->tx_skbuff_dma[entry].len = bmax;
/* do not close the descriptor and do not set own bit */
priv->hw->desc->prepare_tx_desc(desc, 1, bmax, csum, STMMAC_CHAIN_MODE,
0, false);
 
while (len != 0) {
-   priv->tx_skbuff[entry] = NULL;
+   tx_q->tx_skbuff[entry] = NULL;
entry = STMMAC_GET_ENTRY(entry, DMA_TX_SIZE);
-   desc = priv->dma_tx + entry;
+   desc = tx_q->dma_tx + entry;
 
if (len > bmax) {
des2 = dma_map_single(priv->device,
@@ -63,8 +66,8 @@ static int stmmac_jumbo_frm(void *p, struct sk_buff *skb, int 
csum)
desc->des2 = cpu_to_le32(des2);
if (dma_mapping_error(priv->device, des2))
return -1;
-   priv->tx_skbuff_dma[entry].buf = des2;
-   priv->tx_skbuff_dma[entry].len = bmax;
+   tx_q->tx_skbuff_dma[entry].buf = des2;
+   tx_q->tx_skbuff_dma[entry].len = bmax;
priv->hw->desc->prepare_tx_desc(desc, 0, bmax, csum,
STMMAC_CHAIN_MODE, 1,
false);
@@ -77,8 +80,8 @@ static int stmmac_jumbo_frm(void *p, struct sk_buff *skb, int 
csum)
desc->des2 = cpu_to_le32(des2);
if (dma_mapping_error(priv->device, des2))
return -1;
-   priv->tx_skbuff_dma[entry].buf = des2;
-   priv->tx_skbuff_dma[entry].len = len;
+   tx_q->tx_skbuff_dma[entry].buf = des2;
+   tx_q->tx_skbuff_dma[entry].len = len;
/* last descriptor can be set now */
priv->hw->desc->prepare_tx_desc(desc, 0, len, csum,
STMMAC_CHAIN_MODE, 1,
@@ -87,7 +90,7 @@ static int stmmac_jumbo_frm(void *p, struct sk_buff *skb, int 
csum)
}
}
 
-   priv->cur_tx = entry;
+   tx_q->cur_tx = entry;
 
return entry;
 }
@@ -152,17 +155,18 @@ static void stmmac_refill_desc3(void *priv_ptr, struct 
dma_desc *p)
 
 static void stmmac_clean_desc3(void *priv_ptr, struct dma_desc *p)
 {
-   struct stmmac_priv *priv = (struct stmmac_priv *)priv_ptr;
-   unsigned int entry = priv->dirty_tx;
+   struct stmmac_tx_queue *tx_q = (struct stmmac_tx_queue *)priv_ptr;
+   struct stmmac_priv *priv = tx_q->priv_data;
+   unsigned int entry = tx_q->dirty_tx;
 
-   if (priv->tx_skbuff_dma[entry].last_segment && !priv->extend_desc &&
+   if (tx_q->tx_skbuff_dma[entry].last_segment && !priv->extend_desc &&
priv->hwts_tx_en)
/* NOTE: Device will overwrite des3 with timestamp value if
 

[PATCH 0/4 v2 net-next] net: stmmac: adding multiple buffers

[Joao Pinto]

This patch adds multiple buffers to stmmac in a more fragmented
way, in order to make problem debug easier.

I would kindly request to people to test this patch in their HWs in
order to check if everything's functional. Thank you.

Joao Pinto (4):
  net: stmmac: break some functions into RX and TX scopes
  net: stmmac: adding multiple buffers for RX
  net: stmmac: adding multiple buffers for TX
  net: stmmac: adding multiple napi mechanism

 drivers/net/ethernet/stmicro/stmmac/chain_mode.c  |   45 +-
 drivers/net/ethernet/stmicro/stmmac/ring_mode.c   |   46 +-
 drivers/net/ethernet/stmicro/stmmac/stmmac.h  |   49 +-
 drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 1257 ++---
 4 files changed, 947 insertions(+), 450 deletions(-)

-- 
2.9.3

Re: [PATCH 1/4] net: stmmac: break some functions into RX and TX scopes

[Joao Pinto]

Hi Thierry,

Às 7:57 PM de 4/4/2017, Thierry Reding escreveu:
> On Tue, Apr 04, 2017 at 06:54:24PM +0100, Joao Pinto wrote:
>> This patch breaks several functions into RX and TX scopes, which
>> will be useful when adding multiple buffers mechanism.
>>
>> Signed-off-by: Joao Pinto <jpi...@synopsys.com>
>> ---
>>  drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 350 
>> +-
>>  1 file changed, 268 insertions(+), 82 deletions(-)
> 
> A couple of small nits below.
> 
>> diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c 
>> b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
> [...]
>> @@ -924,16 +941,16 @@ static int stmmac_set_bfsize(int mtu, int bufsize)
>>  }
>>  
>>  /**
>> - * stmmac_clear_descriptors - clear descriptors
>> + * stmmac_clear_rx_descriptors - clear RX descriptors
>>   * @priv: driver private structure
>> - * Description: this function is called to clear the tx and rx descriptors
>> + * Description: this function is called to clear the rx descriptors
> 
> You seem to be transitioning to "RX" and "TX" everywhere, maybe do the
> same in this comment for consistency?
> 
> Also, on a general note: there's no need for "Description:" here. The
> kerneldoc format mandates that you leave a blank line after the block
> of parameter descriptions, and the paragraph that follows becomes the
> description. I know that these are static functions and are therefore
> not parsed by kerneldoc, but since you already use the syntax anyway,
> you might as well get it right.
> 
>>   * in case of both basic and extended descriptors are used.
>>   */
>> -static void stmmac_clear_descriptors(struct stmmac_priv *priv)
>> +static void stmmac_clear_rx_descriptors(struct stmmac_priv *priv)
>>  {
>>  int i;
> 
> This could be unsigned.
> 
>>  
>> -/* Clear the Rx/Tx descriptors */
>> +/* Clear the RX descriptors */
>>  for (i = 0; i < DMA_RX_SIZE; i++)
>>  if (priv->extend_desc)
>>  priv->hw->desc->init_rx_desc(>dma_erx[i].basic,
>> @@ -943,6 +960,19 @@ static void stmmac_clear_descriptors(struct stmmac_priv 
>> *priv)
>>  priv->hw->desc->init_rx_desc(>dma_rx[i],
>>   priv->use_riwt, priv->mode,
>>   (i == DMA_RX_SIZE - 1));
>> +}
>> +
>> +/**
>> + * stmmac_clear_tx_descriptors - clear tx descriptors
>> + * @priv: driver private structure
>> + * Description: this function is called to clear the tx descriptors
>> + * in case of both basic and extended descriptors are used.
>> + */
>> +static void stmmac_clear_tx_descriptors(struct stmmac_priv *priv)
>> +{
>> +int i;
> 
> Same here. There are a couple of other such occurrences throughout the
> file. This already exists in many places in the driver, so I don't think
> this needs to be changed. Or at least it could be a follow-up patch.
> 
>> +
>> +/* Clear the TX descriptors */
>>  for (i = 0; i < DMA_TX_SIZE; i++)
>>  if (priv->extend_desc)
>>  priv->hw->desc->init_tx_desc(>dma_etx[i].basic,
>> @@ -955,6 +985,21 @@ static void stmmac_clear_descriptors(struct stmmac_priv 
>> *priv)
>>  }
>>  
>>  /**
>> + * stmmac_clear_descriptors - clear descriptors
>> + * @priv: driver private structure
>> + * Description: this function is called to clear the tx and rx descriptors
>> + * in case of both basic and extended descriptors are used.
>> + */
>> +static void stmmac_clear_descriptors(struct stmmac_priv *priv)
>> +{
>> +/* Clear the RX descriptors */
>> +stmmac_clear_rx_descriptors(priv);
>> +
>> +/* Clear the TX descriptors */
>> +stmmac_clear_tx_descriptors(priv);
>> +}
>> +
>> +/**
>>   * stmmac_init_rx_buffers - init the RX descriptor buffer.
>>   * @priv: driver private structure
>>   * @p: descriptor pointer
>> @@ -996,6 +1041,11 @@ static int stmmac_init_rx_buffers(struct stmmac_priv 
>> *priv, struct dma_desc *p,
>>  return 0;
>>  }
>>  
>> +/**
>> + * stmmac_free_rx_buffers - free RX dma buffers
>> + * @priv: private structure
>> + * @i: buffer index.
> 
> If this operates on a single buffer, as specified by the buffer index,
> maybe this should be named singular stmmac_free_rx_buffer()?
> 
>> + */
>>  static void stmmac_free

[PATCH 0/4 net-next] net: stmmac: adding multiple buffers

[Joao Pinto]

This patch adds multiple buffers to stmmac in a more fragmented
way, in order to make problem debug easier.

I would kindly request to people to test this patch in their HWs in
order to check if everything's functional. Thank you.

Joao Pinto (4):
  net: stmmac: break some functions into RX and TX scopes
  net: stmmac: adding multiple buffers for rx
  net: stmmac: adding multiple buffers for TX
  net: stmmac: adding multiple napi mechanism

 drivers/net/ethernet/stmicro/stmmac/chain_mode.c  |   45 +-
 drivers/net/ethernet/stmicro/stmmac/ring_mode.c   |   46 +-
 drivers/net/ethernet/stmicro/stmmac/stmmac.h  |   49 +-
 drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 1295 ++---
 4 files changed, 969 insertions(+), 466 deletions(-)

-- 
2.9.3

[PATCH 3/4] net: stmmac: adding multiple buffers for TX

[Joao Pinto]

This patch adds the structure stmmac_tx_queue which contains
tx queues specific data (previously in stmmac_priv).

Signed-off-by: Joao Pinto <jpi...@synopsys.com>
---
 drivers/net/ethernet/stmicro/stmmac/chain_mode.c  |  38 +-
 drivers/net/ethernet/stmicro/stmmac/ring_mode.c   |  46 +-
 drivers/net/ethernet/stmicro/stmmac/stmmac.h  |  26 +-
 drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 521 +-
 4 files changed, 375 insertions(+), 256 deletions(-)

diff --git a/drivers/net/ethernet/stmicro/stmmac/chain_mode.c 
b/drivers/net/ethernet/stmicro/stmmac/chain_mode.c
index 8db5a80..37881f8 100644
--- a/drivers/net/ethernet/stmicro/stmmac/chain_mode.c
+++ b/drivers/net/ethernet/stmicro/stmmac/chain_mode.c
@@ -26,12 +26,15 @@
 
 static int stmmac_jumbo_frm(void *p, struct sk_buff *skb, int csum)
 {
-   struct stmmac_priv *priv = (struct stmmac_priv *)p;
-   unsigned int entry = priv->cur_tx;
-   struct dma_desc *desc = priv->dma_tx + entry;
+   struct stmmac_tx_queue *tx_q = (struct stmmac_tx_queue *)p;
unsigned int nopaged_len = skb_headlen(skb);
+   struct stmmac_priv *priv = tx_q->priv_data;
+   unsigned int entry = tx_q->cur_tx;
unsigned int bmax, des2;
unsigned int i = 1, len;
+   struct dma_desc *desc;
+
+   desc = tx_q->dma_tx + entry;
 
if (priv->plat->enh_desc)
bmax = BUF_SIZE_8KiB;
@@ -45,16 +48,16 @@ static int stmmac_jumbo_frm(void *p, struct sk_buff *skb, 
int csum)
desc->des2 = cpu_to_le32(des2);
if (dma_mapping_error(priv->device, des2))
return -1;
-   priv->tx_skbuff_dma[entry].buf = des2;
-   priv->tx_skbuff_dma[entry].len = bmax;
+   tx_q->tx_skbuff_dma[entry].buf = des2;
+   tx_q->tx_skbuff_dma[entry].len = bmax;
/* do not close the descriptor and do not set own bit */
priv->hw->desc->prepare_tx_desc(desc, 1, bmax, csum, STMMAC_CHAIN_MODE,
0, false);
 
while (len != 0) {
-   priv->tx_skbuff[entry] = NULL;
+   tx_q->tx_skbuff[entry] = NULL;
entry = STMMAC_GET_ENTRY(entry, DMA_TX_SIZE);
-   desc = priv->dma_tx + entry;
+   desc = tx_q->dma_tx + entry;
 
if (len > bmax) {
des2 = dma_map_single(priv->device,
@@ -63,8 +66,8 @@ static int stmmac_jumbo_frm(void *p, struct sk_buff *skb, int 
csum)
desc->des2 = cpu_to_le32(des2);
if (dma_mapping_error(priv->device, des2))
return -1;
-   priv->tx_skbuff_dma[entry].buf = des2;
-   priv->tx_skbuff_dma[entry].len = bmax;
+   tx_q->tx_skbuff_dma[entry].buf = des2;
+   tx_q->tx_skbuff_dma[entry].len = bmax;
priv->hw->desc->prepare_tx_desc(desc, 0, bmax, csum,
STMMAC_CHAIN_MODE, 1,
false);
@@ -77,8 +80,8 @@ static int stmmac_jumbo_frm(void *p, struct sk_buff *skb, int 
csum)
desc->des2 = cpu_to_le32(des2);
if (dma_mapping_error(priv->device, des2))
return -1;
-   priv->tx_skbuff_dma[entry].buf = des2;
-   priv->tx_skbuff_dma[entry].len = len;
+   tx_q->tx_skbuff_dma[entry].buf = des2;
+   tx_q->tx_skbuff_dma[entry].len = len;
/* last descriptor can be set now */
priv->hw->desc->prepare_tx_desc(desc, 0, len, csum,
STMMAC_CHAIN_MODE, 1,
@@ -87,7 +90,7 @@ static int stmmac_jumbo_frm(void *p, struct sk_buff *skb, int 
csum)
}
}
 
-   priv->cur_tx = entry;
+   tx_q->cur_tx = entry;
 
return entry;
 }
@@ -152,17 +155,18 @@ static void stmmac_refill_desc3(void *priv_ptr, struct 
dma_desc *p)
 
 static void stmmac_clean_desc3(void *priv_ptr, struct dma_desc *p)
 {
-   struct stmmac_priv *priv = (struct stmmac_priv *)priv_ptr;
-   unsigned int entry = priv->dirty_tx;
+   struct stmmac_tx_queue *tx_q = (struct stmmac_tx_queue *)priv_ptr;
+   struct stmmac_priv *priv = tx_q->priv_data;
+   unsigned int entry = tx_q->dirty_tx;
 
-   if (priv->tx_skbuff_dma[entry].last_segment && !priv->extend_desc &&
+   if (tx_q->tx_skbuff_dma[entry].last_segment && !priv->extend_desc &&
priv->hwts_tx_en)
/* NOTE: Device will overwrite des3 with timestamp value if
 * 1588-2002 time stamping 

[PATCH 2/4] net: stmmac: adding multiple buffers for rx

[Joao Pinto]

This patch adds the structure stmmac_rx_queue which contains
rx queues specific data (previously in stmmac_priv).

Signed-off-by: Joao Pinto <jpi...@synopsys.com>
---
 drivers/net/ethernet/stmicro/stmmac/chain_mode.c  |   7 +-
 drivers/net/ethernet/stmicro/stmmac/stmmac.h  |  26 +-
 drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 453 +-
 3 files changed, 301 insertions(+), 185 deletions(-)

diff --git a/drivers/net/ethernet/stmicro/stmmac/chain_mode.c 
b/drivers/net/ethernet/stmicro/stmmac/chain_mode.c
index 01a8c02..8db5a80 100644
--- a/drivers/net/ethernet/stmicro/stmmac/chain_mode.c
+++ b/drivers/net/ethernet/stmicro/stmmac/chain_mode.c
@@ -136,15 +136,16 @@ static void stmmac_init_dma_chain(void *des, dma_addr_t 
phy_addr,
 
 static void stmmac_refill_desc3(void *priv_ptr, struct dma_desc *p)
 {
-   struct stmmac_priv *priv = (struct stmmac_priv *)priv_ptr;
+   struct stmmac_rx_queue *rx_q = (struct stmmac_rx_queue *)priv_ptr;
+   struct stmmac_priv *priv = rx_q->priv_data;
 
if (priv->hwts_rx_en && !priv->extend_desc)
/* NOTE: Device will overwrite des3 with timestamp value if
 * 1588-2002 time stamping is enabled, hence reinitialize it
 * to keep explicit chaining in the descriptor.
 */
-   p->des3 = cpu_to_le32((unsigned int)(priv->dma_rx_phy +
- (((priv->dirty_rx) + 1) %
+   p->des3 = cpu_to_le32((unsigned int)(rx_q->dma_rx_phy +
+ (((rx_q->dirty_rx) + 1) %
   DMA_RX_SIZE) *
  sizeof(struct dma_desc)));
 }
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac.h 
b/drivers/net/ethernet/stmicro/stmmac/stmmac.h
index cd8fb61..c7ad9e4 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac.h
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac.h
@@ -46,6 +46,20 @@ struct stmmac_tx_info {
bool is_jumbo;
 };
 
+struct stmmac_rx_queue {
+   u32 queue_index;
+   struct stmmac_priv *priv_data;
+   struct dma_extended_desc *dma_erx;
+   struct dma_desc *dma_rx cacheline_aligned_in_smp;
+   struct sk_buff **rx_skbuff;
+   dma_addr_t *rx_skbuff_dma;
+   unsigned int cur_rx;
+   unsigned int dirty_rx;
+   u32 rx_zeroc_thresh;
+   dma_addr_t dma_rx_phy;
+   u32 rx_tail_addr;
+};
+
 struct stmmac_priv {
/* Frequently used values are kept adjacent for cache effect */
struct dma_extended_desc *dma_etx cacheline_aligned_in_smp;
@@ -64,18 +78,10 @@ struct stmmac_priv {
struct timer_list txtimer;
bool tso;
 
-   struct dma_desc *dma_rx cacheline_aligned_in_smp;
-   struct dma_extended_desc *dma_erx;
-   struct sk_buff **rx_skbuff;
-   unsigned int cur_rx;
-   unsigned int dirty_rx;
unsigned int dma_buf_sz;
unsigned int rx_copybreak;
-   unsigned int rx_zeroc_thresh;
u32 rx_riwt;
int hwts_rx_en;
-   dma_addr_t *rx_skbuff_dma;
-   dma_addr_t dma_rx_phy;
 
struct napi_struct napi cacheline_aligned_in_smp;
 
@@ -85,6 +91,9 @@ struct stmmac_priv {
struct mac_device_info *hw;
spinlock_t lock;
 
+   /* RX Queue */
+   struct stmmac_rx_queue rx_queue[MTL_MAX_RX_QUEUES];
+
int oldlink;
int speed;
int oldduplex;
@@ -119,7 +128,6 @@ struct stmmac_priv {
spinlock_t ptp_lock;
void __iomem *mmcaddr;
void __iomem *ptpaddr;
-   u32 rx_tail_addr;
u32 tx_tail_addr;
u32 mss;
 
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c 
b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
index 8e20e6f..6d984ac 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
@@ -197,14 +197,20 @@ static inline u32 stmmac_tx_avail(struct stmmac_priv 
*priv)
return avail;
 }
 
-static inline u32 stmmac_rx_dirty(struct stmmac_priv *priv)
+/**
+ * stmmac_rx_dirty - Get RX queue dirty
+ * @priv: driver private structure
+ * @queue: RX queue index
+ */
+static inline u32 stmmac_rx_dirty(struct stmmac_priv *priv, u32 queue)
 {
+   struct stmmac_rx_queue *rx_q = >rx_queue[queue];
u32 dirty;
 
-   if (priv->dirty_rx <= priv->cur_rx)
-   dirty = priv->cur_rx - priv->dirty_rx;
+   if (rx_q->dirty_rx <= rx_q->cur_rx)
+   dirty = rx_q->cur_rx - rx_q->dirty_rx;
else
-   dirty = DMA_RX_SIZE - priv->dirty_rx + priv->cur_rx;
+   dirty = DMA_RX_SIZE - rx_q->dirty_rx + rx_q->cur_rx;
 
return dirty;
 }
@@ -891,15 +897,24 @@ static int stmmac_init_phy(struct net_device *dev)
 
 static void stmmac_display_rx_rings(struct stmmac_priv *priv)
 {
+   u32 rx_cnt = priv->plat->

[PATCH 1/4] net: stmmac: break some functions into RX and TX scopes

[Joao Pinto]

This patch breaks several functions into RX and TX scopes, which
will be useful when adding multiple buffers mechanism.

Signed-off-by: Joao Pinto <jpi...@synopsys.com>
---
 drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 350 +-
 1 file changed, 268 insertions(+), 82 deletions(-)

diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c 
b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
index 7cbda41..8e20e6f 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
@@ -889,24 +889,41 @@ static int stmmac_init_phy(struct net_device *dev)
return 0;
 }
 
-static void stmmac_display_rings(struct stmmac_priv *priv)
+static void stmmac_display_rx_rings(struct stmmac_priv *priv)
 {
-   void *head_rx, *head_tx;
+   void *head_rx;
 
-   if (priv->extend_desc) {
+   if (priv->extend_desc)
head_rx = (void *)priv->dma_erx;
-   head_tx = (void *)priv->dma_etx;
-   } else {
+   else
head_rx = (void *)priv->dma_rx;
-   head_tx = (void *)priv->dma_tx;
-   }
 
-   /* Display Rx ring */
+   /* Display RX ring */
priv->hw->desc->display_ring(head_rx, DMA_RX_SIZE, true);
-   /* Display Tx ring */
+}
+
+static void stmmac_display_tx_rings(struct stmmac_priv *priv)
+{
+   void *head_tx;
+
+   if (priv->extend_desc)
+   head_tx = (void *)priv->dma_etx;
+   else
+   head_tx = (void *)priv->dma_tx;
+
+   /* Display TX ring */
priv->hw->desc->display_ring(head_tx, DMA_TX_SIZE, false);
 }
 
+static void stmmac_display_rings(struct stmmac_priv *priv)
+{
+   /* Display RX ring */
+   stmmac_display_rx_rings(priv);
+
+   /* Display TX ring */
+   stmmac_display_tx_rings(priv);
+}
+
 static int stmmac_set_bfsize(int mtu, int bufsize)
 {
int ret = bufsize;
@@ -924,16 +941,16 @@ static int stmmac_set_bfsize(int mtu, int bufsize)
 }
 
 /**
- * stmmac_clear_descriptors - clear descriptors
+ * stmmac_clear_rx_descriptors - clear RX descriptors
  * @priv: driver private structure
- * Description: this function is called to clear the tx and rx descriptors
+ * Description: this function is called to clear the rx descriptors
  * in case of both basic and extended descriptors are used.
  */
-static void stmmac_clear_descriptors(struct stmmac_priv *priv)
+static void stmmac_clear_rx_descriptors(struct stmmac_priv *priv)
 {
int i;
 
-   /* Clear the Rx/Tx descriptors */
+   /* Clear the RX descriptors */
for (i = 0; i < DMA_RX_SIZE; i++)
if (priv->extend_desc)
priv->hw->desc->init_rx_desc(>dma_erx[i].basic,
@@ -943,6 +960,19 @@ static void stmmac_clear_descriptors(struct stmmac_priv 
*priv)
priv->hw->desc->init_rx_desc(>dma_rx[i],
 priv->use_riwt, priv->mode,
 (i == DMA_RX_SIZE - 1));
+}
+
+/**
+ * stmmac_clear_tx_descriptors - clear tx descriptors
+ * @priv: driver private structure
+ * Description: this function is called to clear the tx descriptors
+ * in case of both basic and extended descriptors are used.
+ */
+static void stmmac_clear_tx_descriptors(struct stmmac_priv *priv)
+{
+   int i;
+
+   /* Clear the TX descriptors */
for (i = 0; i < DMA_TX_SIZE; i++)
if (priv->extend_desc)
priv->hw->desc->init_tx_desc(>dma_etx[i].basic,
@@ -955,6 +985,21 @@ static void stmmac_clear_descriptors(struct stmmac_priv 
*priv)
 }
 
 /**
+ * stmmac_clear_descriptors - clear descriptors
+ * @priv: driver private structure
+ * Description: this function is called to clear the tx and rx descriptors
+ * in case of both basic and extended descriptors are used.
+ */
+static void stmmac_clear_descriptors(struct stmmac_priv *priv)
+{
+   /* Clear the RX descriptors */
+   stmmac_clear_rx_descriptors(priv);
+
+   /* Clear the TX descriptors */
+   stmmac_clear_tx_descriptors(priv);
+}
+
+/**
  * stmmac_init_rx_buffers - init the RX descriptor buffer.
  * @priv: driver private structure
  * @p: descriptor pointer
@@ -996,6 +1041,11 @@ static int stmmac_init_rx_buffers(struct stmmac_priv 
*priv, struct dma_desc *p,
return 0;
 }
 
+/**
+ * stmmac_free_rx_buffers - free RX dma buffers
+ * @priv: private structure
+ * @i: buffer index.
+ */
 static void stmmac_free_rx_buffers(struct stmmac_priv *priv, int i)
 {
if (priv->rx_skbuff[i]) {
@@ -1007,14 +1057,42 @@ static void stmmac_free_rx_buffers(struct stmmac_priv 
*priv, int i)
 }
 
 /**
- * init_dma_desc_rings - init the RX/TX descriptor rings
+ * stmmac_free_tx_buffers - free RX dma buffers
+ * @priv: private structure
+ * @i: buffer index.
+ */
+s

[PATCH 4/4] net: stmmac: adding multiple napi mechanism

[Joao Pinto]

This patch adds the napi variable to the stmmac_rx_queue
structure and forces that operations like netif_queue_stopped,
netif_wake_queue, netif_stop_queue, netdev_reset_queue and
netdev_sent_queue be made by queue.

Signed-off-by: Joao Pinto <jpi...@synopsys.com>
---
 drivers/net/ethernet/stmicro/stmmac/stmmac.h  |   3 +-
 drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 193 --
 2 files changed, 139 insertions(+), 57 deletions(-)

diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac.h 
b/drivers/net/ethernet/stmicro/stmmac/stmmac.h
index 359f8fd..33efe70 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac.h
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac.h
@@ -72,6 +72,7 @@ struct stmmac_rx_queue {
u32 rx_zeroc_thresh;
dma_addr_t dma_rx_phy;
u32 rx_tail_addr;
+   struct napi_struct napi cacheline_aligned_in_smp;
 };
 
 struct stmmac_priv {
@@ -91,8 +92,6 @@ struct stmmac_priv {
u32 rx_riwt;
int hwts_rx_en;
 
-   struct napi_struct napi cacheline_aligned_in_smp;
-
void __iomem *ioaddr;
struct net_device *dev;
struct device *device;
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c 
b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
index f3e0e8f..eae610a 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
@@ -139,6 +139,64 @@ static void stmmac_verify_args(void)
 }
 
 /**
+ * stmmac_disable_all_queues - Disable all queues
+ * @priv: driver private structure
+ */
+static void stmmac_disable_all_queues(struct stmmac_priv *priv)
+{
+   u32 rx_queues_cnt = priv->plat->rx_queues_to_use;
+   u32 queue;
+
+   for (queue = 0; queue < rx_queues_cnt; queue++) {
+   struct stmmac_rx_queue *rx_q = >rx_queue[queue];
+
+   napi_disable(_q->napi);
+   }
+}
+
+/**
+ * stmmac_enable_all_queues - Enable all queues
+ * @priv: driver private structure
+ */
+static void stmmac_enable_all_queues(struct stmmac_priv *priv)
+{
+   u32 rx_queues_cnt = priv->plat->rx_queues_to_use;
+   u32 queue;
+
+   for (queue = 0; queue < rx_queues_cnt; queue++) {
+   struct stmmac_rx_queue *rx_q = >rx_queue[queue];
+
+   napi_enable(_q->napi);
+   }
+}
+
+/**
+ * stmmac_stop_all_queues - Stop all queues
+ * @priv: driver private structure
+ */
+static void stmmac_stop_all_queues(struct stmmac_priv *priv)
+{
+   u32 tx_queues_cnt = priv->plat->tx_queues_to_use;
+   u32 queue;
+
+   for (queue = 0; queue < tx_queues_cnt; queue++)
+   netif_tx_stop_queue(netdev_get_tx_queue(priv->dev, queue));
+}
+
+/**
+ * stmmac_start_all_queues - Start all queues
+ * @priv: driver private structure
+ */
+static void stmmac_start_all_queues(struct stmmac_priv *priv)
+{
+   u32 tx_queues_cnt = priv->plat->tx_queues_to_use;
+   u32 queue;
+
+   for (queue = 0; queue < tx_queues_cnt; queue++)
+   netif_tx_start_queue(netdev_get_tx_queue(priv->dev, queue));
+}
+
+/**
  * stmmac_clk_csr_set - dynamically set the MDC clock
  * @priv: driver private structure
  * Description: this is to dynamically set the MDC clock according to the csr
@@ -1259,7 +1317,6 @@ static int init_dma_tx_desc_rings(struct net_device *dev)
/* TX INITIALIZATION */
for (i = 0; i < DMA_TX_SIZE; i++) {
struct dma_desc *p;
-
if (priv->extend_desc)
p = &((tx_q->dma_etx + i)->basic);
else
@@ -1283,9 +1340,9 @@ static int init_dma_tx_desc_rings(struct net_device *dev)
 
tx_q->dirty_tx = 0;
tx_q->cur_tx = 0;
-   }
 
-   netdev_reset_queue(priv->dev);
+   netdev_tx_reset_queue(netdev_get_tx_queue(priv->dev, queue));
+   }
 
return 0;
 }
@@ -1805,13 +1862,16 @@ static void stmmac_tx_clean(struct stmmac_priv *priv, 
u32 queue)
}
tx_q->dirty_tx = entry;
 
-   netdev_completed_queue(priv->dev, pkts_compl, bytes_compl);
+   netdev_tx_completed_queue(netdev_get_tx_queue(priv->dev, queue),
+ pkts_compl, bytes_compl);
+
+   if (unlikely(netif_tx_queue_stopped(netdev_get_tx_queue(priv->dev,
+   queue))) &&
+   stmmac_tx_avail(priv, queue) > STMMAC_TX_THRESH) {
 
-   if (unlikely(netif_queue_stopped(priv->dev) &&
-   stmmac_tx_avail(priv, queue) > STMMAC_TX_THRESH)) {
netif_dbg(priv, tx_done, priv->dev,
  "%s: restart transmit\n", __func__);
-   netif_wake_queue(priv->dev);
+   netif_tx_wake_queue(netdev_get_tx_queue(priv->dev, queue));
}
 
  

[PATCH net-next] net: stmmac: rx queue to dma channel mapping fix

[Joao Pinto]

In hardware configurations where multiple queues are active,
the rx queue needs to be mapped into a dma channel, even if
a single rx queue is used.

Signed-off-by: Joao Pinto <jpi...@synopsys.com>
---
 drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c 
b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
index c1c6319..7cbda41 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
@@ -2001,7 +2001,7 @@ static void stmmac_mtl_configuration(struct stmmac_priv 
*priv)
stmmac_configure_cbs(priv);
 
/* Map RX MTL to DMA channels */
-   if (rx_queues_count > 1 && priv->hw->mac->map_mtl_to_dma)
+   if (priv->hw->mac->map_mtl_to_dma)
stmmac_rx_queue_dma_chan_map(priv);
 
/* Enable MAC RX Queues */
-- 
2.9.3

Re: [PATCH] [net-next] stmmac: use netif_set_real_num_{rx,tx}_queues

[Joao Pinto]

Hello Peppe,

Às 2:07 PM de 4/3/2017, Giuseppe CAVALLARO escreveu:
> Hello Joao
> 
> On 3/30/2017 6:42 PM, Joao Pinto wrote:
>> Às 5:35 PM de 3/30/2017, Niklas Cassel escreveu:
>>> On 03/30/2017 04:34 PM, Thierry Reding wrote:
>>>> On Thu, Mar 30, 2017 at 09:45:36AM +0200, Corentin Labbe wrote:
>>>>> On Tue, Mar 28, 2017 at 06:01:05PM -0700, David Miller wrote:
>>>>>> From: Arnd Bergmann <a...@arndb.de>
>>>>>> Date: Tue, 28 Mar 2017 11:48:21 +0200
>>>>>>
>>>>>>> A driver must not access the two fields directly but should instead use
>>>>>>> the helper functions to set the values and keep a consistent internal
>>>>>>> state:
>>>>>>>
>>>>>>> ethernet/stmicro/stmmac/stmmac_main.c: In function 'stmmac_dvr_probe':
>>>>>>> ethernet/stmicro/stmmac/stmmac_main.c:4083:8: error: 'struct net_device'
>>>>>>> has no member named 'real_num_rx_queues'; did you mean 
>>>>>>> 'real_num_tx_queues'?
>>>>>>>
>>>>>>> Fixes: a8f5102af2a7 ("net: stmmac: TX and RX queue priority 
>>>>>>> configuration")
>>>>>>> Signed-off-by: Arnd Bergmann <a...@arndb.de>
>>>>>> Applied.
>>>>> This break my revert patch. (since it patch ("net: stmmac: enable multiple
>>>>> buffers").
>>>>> Since dwmac-sunxi is still broken, what can I do ? send two revert patch ?
>>>>> or adapt the reverting patch.
>>>> Have you tried if the kcalloc() patch I sent on Tuesday fixes things the
>>>> issues introduced by the multiple buffers patch? Niklas reported that it
>>>> restores functionality on his setup.
>>>>
>>>> If it makes things work for you as well, we could maybe avoid the revert
>>>> altogether.
>>> Thierry, I know that you are using DWMAC CORE 4.XX
>>> How many RX queues and how many TX queues have you got?
>>>
>>> I'm also using DWMAC CORE 4.XX
>>> We have 2 TX queues and 1 RX queue.
>>>
>>> I think that Corentin is using DWMAC CORE 3.XX
>>>
>>> I know that Joao is using an IP Prototyping Kit that uses
>>> DWMAC CORE 4.XX (connected via PCIe).
>>> It would be nice if Joao could get an IP Prototyping Kit
>>> based on DWMAC CORE 3.XX.
>>>
>>> Doesn't Synopsys have an IP Prototyping Kit based on
>>> DWMAC CORE 3.XX laying around somewhere? :)
>>>
>> I requested a prototyping platform with MAC 100 or a MAC 1000 in order to 
>> make
>> more tests, but I don't have an ETA for it yet.
>>
>> The implication of the multiple buffers patch in 3.xx is some flow change in 
>> the
>> configuration of dma op mode or similar. I would recomend Corentin to dump 
>> the
>> dma & mac registers in the end of the _open function in order to see if the 
>> DMA
>> is really being well configured and is really started.
> 
> Old devices managed as stmmac: mac10/100 platform driver have no multi-queue
> support.
> 
> It was introduced in the new versions managed by mac1000 but in my opinion
> the stmmac driver has to only work with a single queue for tx and rx on ALL
> the 3.x versions.
> 
> In fact, although the latest series have the multi-queue and channels there is
> just one IRQ and this is a very poor implementation.
> The 3.xx is very different from what we have in the 4.XX (QoS) on this part 
> and
> AV/B.
> 
> Nobody has ever asked for having this support in all these years for the 
> previous
> chips.
> 
> Adding this kind of support we'll spend time for having a no useful 
> optimization
> and risking to break the compatibility with a lot platforms that use these 
> chips.
> 
> I image, multi-queue stable on 4.XX and no support on all older versions.
> Let me know if you share that.

Yes older cores do not support multiple queues and I tried to isolate the
features not to affect older versions.

Do you think that functions as "ndev = alloc_etherdev_mqs" has some sort of
influence?

Thanks.

> 
> Regards
> Peppe
> 
>>
>> Thanks.
>>
>> Joao
>>
>>
> 

Re: [PATCH] [net-next] stmmac: use netif_set_real_num_{rx,tx}_queues

[Joao Pinto]

Às 5:57 PM de 3/31/2017, David Miller escreveu:
> From: Joao Pinto <joao.pi...@synopsys.com>
> Date: Fri, 31 Mar 2017 11:43:38 +0100
> 
>> @David: Could you please create a branch in your git tree for us to work on 
>> it
>> until the multiple buffers get stable for everyone? This way the patches 
>> could
>> circulate in the mailing-list with a different target, like stmmac-next or 
>> similar.
>>
>> What do you think?
> 
> Sorry, I'm not going to do that.
> 

Ok. I will send the patches normally through the mailing-list.

Thanks.

[PATCH] net: stmmac: fix cbs configuration

[Joao Pinto]

Sending again, because forgot to include net-dev.

The QoS IP does not accept AVB capabilities to default/queue 0, this way we
guarantee 75% bandwidth for AVB. This patch assures that only queues >= 1
gets CBS confgured. Additional info was also added to stmmac.txt.

Reported-by: Niklas Cassel <niklas.cas...@axis.com>
Signed-off-by: Joao Pinto <jpi...@synopsys.com>
---
 Documentation/devicetree/bindings/net/stmmac.txt  | 2 ++
 drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 3 ++-
 2 files changed, 4 insertions(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/net/stmmac.txt 
b/Documentation/devicetree/bindings/net/stmmac.txt
index 784d988..f652b0c 100644
--- a/Documentation/devicetree/bindings/net/stmmac.txt
+++ b/Documentation/devicetree/bindings/net/stmmac.txt
@@ -103,6 +103,8 @@ Optional properties:
- Choose one of these modes:
- snps,dcb-algorithm: TX queue will be working in DCB
- snps,avb-algorithm: TX queue will be working in AVB
+ [Attention] Queue 0 is reserved for legacy traffic
+ and so no AVB is available in this queue.
- Configure Credit Base Shaper (if AVB Mode selected):
- snps,send_slope: enable Low Power Interface
- snps,idle_slope: unlock on WoL
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c 
b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
index 43361f3..c1c6319 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
@@ -1880,7 +1880,8 @@ static void stmmac_configure_cbs(struct stmmac_priv *priv)
u32 mode_to_use;
u32 queue;
 
-   for (queue = 0; queue < tx_queues_count; queue++) {
+   /* queue 0 is reserved for legacy traffic */
+   for (queue = 1; queue < tx_queues_count; queue++) {
mode_to_use = priv->plat->tx_queues_cfg[queue].mode_to_use;
if (mode_to_use == MTL_QUEUE_DCB)
continue;
-- 
2.9.3

Re: stmmac CBS configuration for TX AVB queue

[Joao Pinto]

Às 10:59 AM de 3/31/2017, Niklas Cassel escreveu:
> Hello Joao
> 
> 
> I was looking at
> 
> commit 19d9187317979cf0c25f67017d2676149abc46b2
> Author: Joao Pinto <joao.pi...@synopsys.com>
> Date:   Fri Mar 10 18:24:59 2017 +
> 
> net: stmmac: configuration of CBS in case of a TX AVB queue
> 
> This patch adds the configuration of the AVB Credit-Based Shaper.
> 
> 
> 
> It looks to me that we loop through all txqueues (including 0)
> 
> static void stmmac_configure_cbs(struct stmmac_priv *priv)
> ...
> for (queue = 0; queue < tx_queues_count; queue++) {
> ...
> priv->hw->mac->config_cbs(...)
> 
> 
> then in
> 
> static void dwmac4_config_cbs(..)
> ...
> value = readl(ioaddr + MTL_ETSX_CTRL_BASE_ADDR(queue));
> 
> 
> The MTL_ETSX_CTRL_BASE_ADDR register only exists for txqueues != 0.
> (Since txqueue0 will always handle legacy traffic.)
> 
> I think that we need to make sure that we do not enter
> config_cbs() for txqueue0, even if the user's device tree
> has txqueue0 set to AVB, since MTL_ETSX_CTRL_BASE_ADDR
> will evaluate to a non-existing register for txqueue0.
> 
> Perhaps also clarify how we expect the user to configure
> his device tree for txqueue0 when using AVB in:
> Documentation/devicetree/bindings/net/stmmac.txt
> 
> 
> Best regards,
> Niklas
> 

You are right, we did not add AVB capabilities to default/Q0, this way we
guarantee 75% bandwidth for AVB. I will send a patch soon to fix this.

Thanks,
Joao

Re: [PATCH] [net-next] stmmac: use netif_set_real_num_{rx,tx}_queues

[Joao Pinto]

Às 11:14 AM de 3/31/2017, Joao Pinto escreveu:
> Às 6:48 PM de 3/30/2017, David Miller escreveu:
>> From: Thierry Reding <tred...@nvidia.com>
>> Date: Thu, 30 Mar 2017 16:34:36 +0200
>>
>>> On Thu, Mar 30, 2017 at 09:45:36AM +0200, Corentin Labbe wrote:
>>>> On Tue, Mar 28, 2017 at 06:01:05PM -0700, David Miller wrote:
>>>>> From: Arnd Bergmann <a...@arndb.de>
>>>>> Date: Tue, 28 Mar 2017 11:48:21 +0200
>>>>>
>>>>>> A driver must not access the two fields directly but should instead use
>>>>>> the helper functions to set the values and keep a consistent internal
>>>>>> state:
>>>>>>
>>>>>> ethernet/stmicro/stmmac/stmmac_main.c: In function 'stmmac_dvr_probe':
>>>>>> ethernet/stmicro/stmmac/stmmac_main.c:4083:8: error: 'struct net_device' 
>>>>>> has no member named 'real_num_rx_queues'; did you mean 
>>>>>> 'real_num_tx_queues'?
>>>>>>
>>>>>> Fixes: a8f5102af2a7 ("net: stmmac: TX and RX queue priority 
>>>>>> configuration")
>>>>>> Signed-off-by: Arnd Bergmann <a...@arndb.de>
>>>>>
>>>>> Applied.
>>>>
>>>> This break my revert patch. (since it patch ("net: stmmac: enable multiple 
>>>> buffers").
>>>> Since dwmac-sunxi is still broken, what can I do ? send two revert patch ? 
>>>> or adapt the reverting patch.
>>>
>>> Have you tried if the kcalloc() patch I sent on Tuesday fixes things the
>>> issues introduced by the multiple buffers patch? Niklas reported that it
>>> restores functionality on his setup.
>>
>> I think he said yesterday that he did indeed test all of your patches and it
>> did not fix things for him.
>>
>> http://marc.info/?l=linux-kernel=149076922813085=2
>>
>> I am going to revert the enable multiple buffers commit, and I would ask that
>> all involved parties work together in the background to resolve all of this.

@David: Could you please create a branch in your git tree for us to work on it
until the multiple buffers get stable for everyone? This way the patches could
circulate in the mailing-list with a different target, like stmmac-next or 
similar.

What do you think?

Joao

>>
>> Thank you.
>>
> 
> @David: Agreed.
> 
> @Corentin: Please check if the DMA Engine is well configured and if the dma
> rx/tx has started. This is done by dumping the DMA Registers.
> Please also check the MAC related registers and dump them in order to have a
> clear picture if the IP is being well configured.
> This is critial to analise what's hapenning in your setup.
> 
> Joao
> 

Re: [PATCH] [net-next] stmmac: use netif_set_real_num_{rx,tx}_queues

[Joao Pinto]

Às 6:48 PM de 3/30/2017, David Miller escreveu:
> From: Thierry Reding 
> Date: Thu, 30 Mar 2017 16:34:36 +0200
> 
>> On Thu, Mar 30, 2017 at 09:45:36AM +0200, Corentin Labbe wrote:
>>> On Tue, Mar 28, 2017 at 06:01:05PM -0700, David Miller wrote:
 From: Arnd Bergmann 
 Date: Tue, 28 Mar 2017 11:48:21 +0200

> A driver must not access the two fields directly but should instead use
> the helper functions to set the values and keep a consistent internal
> state:
>
> ethernet/stmicro/stmmac/stmmac_main.c: In function 'stmmac_dvr_probe':
> ethernet/stmicro/stmmac/stmmac_main.c:4083:8: error: 'struct net_device' 
> has no member named 'real_num_rx_queues'; did you mean 
> 'real_num_tx_queues'?
>
> Fixes: a8f5102af2a7 ("net: stmmac: TX and RX queue priority 
> configuration")
> Signed-off-by: Arnd Bergmann 

 Applied.
>>>
>>> This break my revert patch. (since it patch ("net: stmmac: enable multiple 
>>> buffers").
>>> Since dwmac-sunxi is still broken, what can I do ? send two revert patch ? 
>>> or adapt the reverting patch.
>>
>> Have you tried if the kcalloc() patch I sent on Tuesday fixes things the
>> issues introduced by the multiple buffers patch? Niklas reported that it
>> restores functionality on his setup.
> 
> I think he said yesterday that he did indeed test all of your patches and it
> did not fix things for him.
> 
> http://marc.info/?l=linux-kernel=149076922813085=2
> 
> I am going to revert the enable multiple buffers commit, and I would ask that
> all involved parties work together in the background to resolve all of this.
> 
> Thank you.
> 

@David: Agreed.

@Corentin: Please check if the DMA Engine is well configured and if the dma
rx/tx has started. This is done by dumping the DMA Registers.
Please also check the MAC related registers and dump them in order to have a
clear picture if the IP is being well configured.
This is critial to analise what's hapenning in your setup.

Joao

Re: [PATCH] [net-next] stmmac: use netif_set_real_num_{rx,tx}_queues

[Joao Pinto]

Às 5:35 PM de 3/30/2017, Niklas Cassel escreveu:
> On 03/30/2017 04:34 PM, Thierry Reding wrote:
>> On Thu, Mar 30, 2017 at 09:45:36AM +0200, Corentin Labbe wrote:
>>> On Tue, Mar 28, 2017 at 06:01:05PM -0700, David Miller wrote:
 From: Arnd Bergmann 
 Date: Tue, 28 Mar 2017 11:48:21 +0200

> A driver must not access the two fields directly but should instead use
> the helper functions to set the values and keep a consistent internal
> state:
>
> ethernet/stmicro/stmmac/stmmac_main.c: In function 'stmmac_dvr_probe':
> ethernet/stmicro/stmmac/stmmac_main.c:4083:8: error: 'struct net_device' 
> has no member named 'real_num_rx_queues'; did you mean 
> 'real_num_tx_queues'?
>
> Fixes: a8f5102af2a7 ("net: stmmac: TX and RX queue priority 
> configuration")
> Signed-off-by: Arnd Bergmann 

 Applied.
>>>
>>> This break my revert patch. (since it patch ("net: stmmac: enable multiple 
>>> buffers").
>>> Since dwmac-sunxi is still broken, what can I do ? send two revert patch ? 
>>> or adapt the reverting patch.
>>
>> Have you tried if the kcalloc() patch I sent on Tuesday fixes things the
>> issues introduced by the multiple buffers patch? Niklas reported that it
>> restores functionality on his setup.
>>
>> If it makes things work for you as well, we could maybe avoid the revert
>> altogether.
> 
> Thierry, I know that you are using DWMAC CORE 4.XX
> How many RX queues and how many TX queues have you got?
> 
> I'm also using DWMAC CORE 4.XX
> We have 2 TX queues and 1 RX queue.
> 
> I think that Corentin is using DWMAC CORE 3.XX
> 
> I know that Joao is using an IP Prototyping Kit that uses
> DWMAC CORE 4.XX (connected via PCIe).
> It would be nice if Joao could get an IP Prototyping Kit
> based on DWMAC CORE 3.XX.
> 
> Doesn't Synopsys have an IP Prototyping Kit based on
> DWMAC CORE 3.XX laying around somewhere? :)
> 

I requested a prototyping platform with MAC 100 or a MAC 1000 in order to make
more tests, but I don't have an ETA for it yet.

The implication of the multiple buffers patch in 3.xx is some flow change in the
configuration of dma op mode or similar. I would recomend Corentin to dump the
dma & mac registers in the end of the _open function in order to see if the DMA
is really being well configured and is really started.

Thanks.

Joao

Re: [PATCH net-next 2/2] net: stmmac: fix number of tx queues in stmmac_poll

[Joao Pinto]

Às 6:28 PM de 3/27/2017, David Miller escreveu:
> From: Corentin Labbe <clabbe.montj...@gmail.com>
> Date: Mon, 27 Mar 2017 19:00:58 +0200
> 
>> On Mon, Mar 27, 2017 at 04:26:48PM +0100, Joao Pinto wrote:
>>> Hi David,
>>>
>>> Às 7:26 AM de 3/25/2017, Corentin Labbe escreveu:
>>>> On Fri, Mar 24, 2017 at 05:16:45PM +, Joao Pinto wrote:
>>>>> For cores that have more than 1 TX queue configured, the kernel would 
>>>>> crash,
>>>>> since only one TX queue is permitted by default.
>>>>>
>>>>> Signed-off-by: Joao Pinto <jpi...@synopsys.com>
>>>>> ---
>>>>>  drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 2 +-
>>>>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>>>>
>>>>> diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c 
>>>>> b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
>>>>> index 3827952..1eab084 100644
>>>>> --- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
>>>>> +++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
>>>>> @@ -3429,7 +3429,7 @@ static int stmmac_poll(struct napi_struct *napi, 
>>>>> int budget)
>>>>>   struct stmmac_rx_queue *rx_q =
>>>>>   container_of(napi, struct stmmac_rx_queue, napi);
>>>>>   struct stmmac_priv *priv = rx_q->priv_data;
>>>>> - u32 tx_count = priv->dma_cap.number_tx_queues;
>>>>> + u32 tx_count = priv->plat->tx_queues_to_use;
>>>>>   u32 chan = rx_q->queue_index;
>>>>>   u32 work_done = 0;
>>>>>   u32 queue = 0;
>>>>> -- 
>>>>> 2.9.3
>>>>>
>>>>
>>>> This patch fix the performance issue on dwmac-sun8i only.
>>>> The dwmac-sunxi is still broken.
>>>>
>>>
>>> This patch series can be upstreamed please, since they make 2 fixes, one of 
>>> them
>>> solving the problem in dwmac-sun8i.
>>>
>>> Thanks.
>>
>> As I said in a previous answer, finaly dwmac-sun8i is still broken.
>> Adding thoses 2 patch will just made the revert harder.
> 
> I agree.

For what I am understanding, SoCs base on Core versions >= 4.00 are working
properly and for some reason SoCs based on older versions are not working.

This fix is necessary, since if you have a diferent configured tx_queues_to_use
in the driver and priv->dma_cap.number_tx_queues in the core, this can lead to
kernel crashes.

The other fix (netdev resources release) is also necessary, since when you
release the driver its crashes, because the rx queue struct is freed before
releasing the netdevs.

We can revert, but I think it might not solve the issue. We can break the
"multiple buffers" patch into "rx multilple buffers" and "tx multiple buffers",
but will that actually work? We can give it a try, I don't mind making a new
multiple buffers patch broken into 2, that can be tested by new cores and older
cores.

Joao

Re: [PATCH net-next 2/2] net: stmmac: fix number of tx queues in stmmac_poll

[Joao Pinto]

Às 6:00 PM de 3/27/2017, Corentin Labbe escreveu:
> On Mon, Mar 27, 2017 at 04:26:48PM +0100, Joao Pinto wrote:
>> Hi David,
>>
>> Às 7:26 AM de 3/25/2017, Corentin Labbe escreveu:
>>> On Fri, Mar 24, 2017 at 05:16:45PM +, Joao Pinto wrote:
>>>> For cores that have more than 1 TX queue configured, the kernel would 
>>>> crash,
>>>> since only one TX queue is permitted by default.
>>>>
>>>> Signed-off-by: Joao Pinto <jpi...@synopsys.com>
>>>> ---
>>>>  drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 2 +-
>>>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>>>
>>>> diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c 
>>>> b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
>>>> index 3827952..1eab084 100644
>>>> --- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
>>>> +++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
>>>> @@ -3429,7 +3429,7 @@ static int stmmac_poll(struct napi_struct *napi, int 
>>>> budget)
>>>>struct stmmac_rx_queue *rx_q =
>>>>container_of(napi, struct stmmac_rx_queue, napi);
>>>>struct stmmac_priv *priv = rx_q->priv_data;
>>>> -  u32 tx_count = priv->dma_cap.number_tx_queues;
>>>> +  u32 tx_count = priv->plat->tx_queues_to_use;
>>>>u32 chan = rx_q->queue_index;
>>>>u32 work_done = 0;
>>>>u32 queue = 0;
>>>> -- 
>>>> 2.9.3
>>>>
>>>
>>> This patch fix the performance issue on dwmac-sun8i only.
>>> The dwmac-sunxi is still broken.
>>>
>>
>> This patch series can be upstreamed please, since they make 2 fixes, one of 
>> them
>> solving the problem in dwmac-sun8i.
>>
>> Thanks.
> 
> As I said in a previous answer, finaly dwmac-sun8i is still broken.
> Adding thoses 2 patch will just made the revert harder.

Oh, ok. You are using version >=4.00 or older versions?

> 
> Regards
> 

Re: [PATCH net-next 2/2] net: stmmac: fix number of tx queues in stmmac_poll

[Joao Pinto]

Hi David,

Às 7:26 AM de 3/25/2017, Corentin Labbe escreveu:
> On Fri, Mar 24, 2017 at 05:16:45PM +0000, Joao Pinto wrote:
>> For cores that have more than 1 TX queue configured, the kernel would crash,
>> since only one TX queue is permitted by default.
>>
>> Signed-off-by: Joao Pinto <jpi...@synopsys.com>
>> ---
>>  drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c 
>> b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
>> index 3827952..1eab084 100644
>> --- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
>> +++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
>> @@ -3429,7 +3429,7 @@ static int stmmac_poll(struct napi_struct *napi, int 
>> budget)
>>  struct stmmac_rx_queue *rx_q =
>>  container_of(napi, struct stmmac_rx_queue, napi);
>>  struct stmmac_priv *priv = rx_q->priv_data;
>> -u32 tx_count = priv->dma_cap.number_tx_queues;
>> +u32 tx_count = priv->plat->tx_queues_to_use;
>>  u32 chan = rx_q->queue_index;
>>  u32 work_done = 0;
>>  u32 queue = 0;
>> -- 
>> 2.9.3
>>
> 
> This patch fix the performance issue on dwmac-sun8i only.
> The dwmac-sunxi is still broken.
> 

This patch series can be upstreamed please, since they make 2 fixes, one of them
solving the problem in dwmac-sun8i.

Thanks.

Re: [PATCH net-next 2/2] net: stmmac: fix number of tx queues in stmmac_poll

[Joao Pinto]

Hin Thierry,

Às 2:34 PM de 3/27/2017, Joao Pinto escreveu:
> Às 2:28 PM de 3/27/2017, Niklas Cassel escreveu:
>>
>>
>> On 03/27/2017 11:12 AM, Joao Pinto wrote:
>>> Às 10:09 AM de 3/27/2017, Corentin Labbe escreveu:
>>>> On Mon, Mar 27, 2017 at 10:04:57AM +0100, Joao Pinto wrote:
>>>>> Às 7:26 AM de 3/25/2017, Corentin Labbe escreveu:
>>>>>> On Fri, Mar 24, 2017 at 05:16:45PM +, Joao Pinto wrote:
>>>>>>> For cores that have more than 1 TX queue configured, the kernel would 
>>>>>>> crash,
>>>>>>> since only one TX queue is permitted by default.
>>>>>>>
>>>>>>> Signed-off-by: Joao Pinto <jpi...@synopsys.com>
>>>>>>> ---
>>>>>>>  drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 2 +-
>>>>>>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>>>>>>
>>>>>>> diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c 
>>>>>>> b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
>>>>>>> index 3827952..1eab084 100644
>>>>>>> --- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
>>>>>>> +++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
>>>>>>> @@ -3429,7 +3429,7 @@ static int stmmac_poll(struct napi_struct *napi, 
>>>>>>> int budget)
>>>>>>> struct stmmac_rx_queue *rx_q =
>>>>>>> container_of(napi, struct stmmac_rx_queue, napi);
>>>>>>> struct stmmac_priv *priv = rx_q->priv_data;
>>>>>>> -   u32 tx_count = priv->dma_cap.number_tx_queues;
>>>>>>> +   u32 tx_count = priv->plat->tx_queues_to_use;
>>>>>>> u32 chan = rx_q->queue_index;
>>>>>>> u32 work_done = 0;
>>>>>>> u32 queue = 0;
>>>>>>> -- 
>>>>>>> 2.9.3
>>>>>>>
>>>>>>
>>>>>> This patch fix the performance issue on dwmac-sun8i only.
>>>>>
>>>>> Ok, great!
>>>>>
>>>>
>>>> Sorry, in the we, I see that my gigabit dwmac-sun8i didnt work... (but 
>>>> didnt have time to find why).
>>>>
>>>>>> The dwmac-sunxi is still broken.
>>>
>>> Ok, let's see what others report.
>>>
>>>>>>
>>>>>
>>>>> What is the difference between the setups?
>>>>
>>>> dwmac-sun8i use chain mode, dwmac-sunxi use ring mode
>>>>
>>>
>>> @Thierry and Niklas: Hi! Your setup is working well with these 2 fix 
>>> patches?
>>>
>>
>> Hello Joao,
>>
>> I have not tested these 2 patches.
>>
>> Previously, when I tested next-20170321, artpec-6 SoC got TX queue timeouts.
>> When testing today's linux-next, next-20170327, things are working again :)
>>
>>
>> So I guess one of the following patches fixed our problem:
>>
>> 270c7759fbbc net: stmmac: add set_mac to the stmmac_ops
>> b4f0a6615556 net: stmmac: fix dma operation mode config for older versions
>> 33e85b8dd69e net: stmmac: Restore DT backwards-compatibility
>> f39768744fd6 net: stmmac: Always enable MAC RX queues
>> abe80fdc6ee6 net: stmmac: RX queue routing configuration
>> a8f5102af2a7 net: stmmac: TX and RX queue priority configuration
>> aff3d9eff843 net: stmmac: enable multiple buffers
> 
> Yes for sure :) Great! Thanks.

Could you please confirm your setup works with these final 2 patches?

Thanks.

> 
>>
>> Regards,
>> Niklas
>>
> 

Re: [PATCH net-next 2/2] net: stmmac: fix number of tx queues in stmmac_poll

[Joao Pinto]

Às 2:28 PM de 3/27/2017, Niklas Cassel escreveu:
> 
> 
> On 03/27/2017 11:12 AM, Joao Pinto wrote:
>> Às 10:09 AM de 3/27/2017, Corentin Labbe escreveu:
>>> On Mon, Mar 27, 2017 at 10:04:57AM +0100, Joao Pinto wrote:
>>>> Às 7:26 AM de 3/25/2017, Corentin Labbe escreveu:
>>>>> On Fri, Mar 24, 2017 at 05:16:45PM +, Joao Pinto wrote:
>>>>>> For cores that have more than 1 TX queue configured, the kernel would 
>>>>>> crash,
>>>>>> since only one TX queue is permitted by default.
>>>>>>
>>>>>> Signed-off-by: Joao Pinto <jpi...@synopsys.com>
>>>>>> ---
>>>>>>  drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 2 +-
>>>>>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>>>>>
>>>>>> diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c 
>>>>>> b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
>>>>>> index 3827952..1eab084 100644
>>>>>> --- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
>>>>>> +++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
>>>>>> @@ -3429,7 +3429,7 @@ static int stmmac_poll(struct napi_struct *napi, 
>>>>>> int budget)
>>>>>>  struct stmmac_rx_queue *rx_q =
>>>>>>  container_of(napi, struct stmmac_rx_queue, napi);
>>>>>>  struct stmmac_priv *priv = rx_q->priv_data;
>>>>>> -u32 tx_count = priv->dma_cap.number_tx_queues;
>>>>>> +u32 tx_count = priv->plat->tx_queues_to_use;
>>>>>>  u32 chan = rx_q->queue_index;
>>>>>>  u32 work_done = 0;
>>>>>>  u32 queue = 0;
>>>>>> -- 
>>>>>> 2.9.3
>>>>>>
>>>>>
>>>>> This patch fix the performance issue on dwmac-sun8i only.
>>>>
>>>> Ok, great!
>>>>
>>>
>>> Sorry, in the we, I see that my gigabit dwmac-sun8i didnt work... (but 
>>> didnt have time to find why).
>>>
>>>>> The dwmac-sunxi is still broken.
>>
>> Ok, let's see what others report.
>>
>>>>>
>>>>
>>>> What is the difference between the setups?
>>>
>>> dwmac-sun8i use chain mode, dwmac-sunxi use ring mode
>>>
>>
>> @Thierry and Niklas: Hi! Your setup is working well with these 2 fix patches?
>>
> 
> Hello Joao,
> 
> I have not tested these 2 patches.
> 
> Previously, when I tested next-20170321, artpec-6 SoC got TX queue timeouts.
> When testing today's linux-next, next-20170327, things are working again :)
> 
> 
> So I guess one of the following patches fixed our problem:
> 
> 270c7759fbbc net: stmmac: add set_mac to the stmmac_ops
> b4f0a6615556 net: stmmac: fix dma operation mode config for older versions
> 33e85b8dd69e net: stmmac: Restore DT backwards-compatibility
> f39768744fd6 net: stmmac: Always enable MAC RX queues
> abe80fdc6ee6 net: stmmac: RX queue routing configuration
> a8f5102af2a7 net: stmmac: TX and RX queue priority configuration
> aff3d9eff843 net: stmmac: enable multiple buffers

Yes for sure :) Great! Thanks.

> 
> Regards,
> Niklas
> 

Re: [v2,net-next,1/3] net: stmmac: enable multiple buffers

[Joao Pinto]

Às 10:28 AM de 3/27/2017, Alexandre Torgue escreveu:
> Hi Joao
> 
> On 03/24/2017 06:09 PM, Joao Pinto wrote:
>>
>> Hello David,
>>
>> Às 5:05 PM de 3/24/2017, David Miller escreveu:
>>> From: Andrew Lunn <and...@lunn.ch>
>>> Date: Fri, 24 Mar 2017 12:17:36 +0100
>>>
>>>>> Yes it would be fantastic to have a set of boards, but I rarely see this 
>>>>> in
>>>>> any
>>>>> maintainer :).
>>>>
>>>> Being a Marvell SoC and switch maintainer, i have around a dozen
>>>> boards. Some i got some simply by asking the manufacture, others i
>>>> purchased. I don't think i'm in the minority here. Without having
>>>> access to a number of different hardwares, i don't feel i would be
>>>> doing my work properly.
>>>>
>>>>> I try as hard as I can to network with people and try to minimize this
>>>>> situations, but when there is so many different setups using a driver with
>>>>> diff
>>>>> configurations, situations like this can happen, but I am here to help
>>>>> debugging
>>>>> and solving them.
>>>>
>>>> You made a move to rename stmmac to synopsys not long ago. It gave the
>>>> impression that synopsis wants to take over this driver. If there are
>>>> a number of different configurations, who better than synopsys to
>>>> actually properly test these configurations? If you ask around, i'm
>>>> sure people will send you hardware.
>>>
>>> I completely agree with everything Andrew is saying here.
>>>
>>
>> I'll maintain the driver if everyone agrees with it, no problem, mas I would
>> like to hear from Peppe and Alex, since they are the current maintainers.
> 
> I agree with this proposition. As you can see (and unfortunately) I have
> currently no time for reviewing (I'm busy on another subsystem). You are close
> to new GMAC evolution and very active (I hope for a long time).
> For sure you need boards with old GMAC Ips. I will send you an STM32 with GMAC
> IP 3.5. Don't hesitate to contact us if you have question about historic 
> content
> of stmmac driver.

Thanks Alex, I will do my best to maintain it! That would be great to have a
board with an older IP to test. I will send you my office address soon. Thanks!

@ Peppe: Are you ok with it?

Thanks.

> 
> Thanks!
> 
> Alex
> 
> 
> 
>>
>> HW testing would be nice, but hard to justify investing in one shot, so it 
>> would
>> be great to receive hardware to make tests if the companies wish it.
>>
>> About the problems in the last patch I am going to send a 2 patch set with 2
>> fixes, lets see if stuff gets better.
>>
>> Thnaks
>> Joao
>>

Re: [PATCH net-next 2/2] net: stmmac: fix number of tx queues in stmmac_poll

[Joao Pinto]

Às 10:09 AM de 3/27/2017, Corentin Labbe escreveu:
> On Mon, Mar 27, 2017 at 10:04:57AM +0100, Joao Pinto wrote:
>> Às 7:26 AM de 3/25/2017, Corentin Labbe escreveu:
>>> On Fri, Mar 24, 2017 at 05:16:45PM +, Joao Pinto wrote:
>>>> For cores that have more than 1 TX queue configured, the kernel would 
>>>> crash,
>>>> since only one TX queue is permitted by default.
>>>>
>>>> Signed-off-by: Joao Pinto <jpi...@synopsys.com>
>>>> ---
>>>>  drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 2 +-
>>>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>>>
>>>> diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c 
>>>> b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
>>>> index 3827952..1eab084 100644
>>>> --- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
>>>> +++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
>>>> @@ -3429,7 +3429,7 @@ static int stmmac_poll(struct napi_struct *napi, int 
>>>> budget)
>>>>struct stmmac_rx_queue *rx_q =
>>>>container_of(napi, struct stmmac_rx_queue, napi);
>>>>struct stmmac_priv *priv = rx_q->priv_data;
>>>> -  u32 tx_count = priv->dma_cap.number_tx_queues;
>>>> +  u32 tx_count = priv->plat->tx_queues_to_use;
>>>>u32 chan = rx_q->queue_index;
>>>>u32 work_done = 0;
>>>>u32 queue = 0;
>>>> -- 
>>>> 2.9.3
>>>>
>>>
>>> This patch fix the performance issue on dwmac-sun8i only.
>>
>> Ok, great!
>>
> 
> Sorry, in the we, I see that my gigabit dwmac-sun8i didnt work... (but didnt 
> have time to find why).
> 
>>> The dwmac-sunxi is still broken.

Ok, let's see what others report.

>>>
>>
>> What is the difference between the setups?
> 
> dwmac-sun8i use chain mode, dwmac-sunxi use ring mode
> 

@Thierry and Niklas: Hi! Your setup is working well with these 2 fix patches?

Thnaks.

Re: [PATCH net-next 2/2] net: stmmac: fix number of tx queues in stmmac_poll

[Joao Pinto]

Às 7:26 AM de 3/25/2017, Corentin Labbe escreveu:
> On Fri, Mar 24, 2017 at 05:16:45PM +0000, Joao Pinto wrote:
>> For cores that have more than 1 TX queue configured, the kernel would crash,
>> since only one TX queue is permitted by default.
>>
>> Signed-off-by: Joao Pinto <jpi...@synopsys.com>
>> ---
>>  drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c 
>> b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
>> index 3827952..1eab084 100644
>> --- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
>> +++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
>> @@ -3429,7 +3429,7 @@ static int stmmac_poll(struct napi_struct *napi, int 
>> budget)
>>  struct stmmac_rx_queue *rx_q =
>>  container_of(napi, struct stmmac_rx_queue, napi);
>>  struct stmmac_priv *priv = rx_q->priv_data;
>> -u32 tx_count = priv->dma_cap.number_tx_queues;
>> +u32 tx_count = priv->plat->tx_queues_to_use;
>>  u32 chan = rx_q->queue_index;
>>  u32 work_done = 0;
>>  u32 queue = 0;
>> -- 
>> 2.9.3
>>
> 
> This patch fix the performance issue on dwmac-sun8i only.

Ok, great!

> The dwmac-sunxi is still broken.
> 

What is the difference between the setups?

Thanks,
Joao

Re: [v2,net-next,1/3] net: stmmac: enable multiple buffers

[Joao Pinto]

Às 5:17 PM de 3/24/2017, David Miller escreveu:
> From: Joao Pinto <joao.pi...@synopsys.com>
> Date: Fri, 24 Mar 2017 15:02:27 +
> 
>> Yes, I agree, it is better to revert and leave the tree functional for all.
>>
>> @David Miller:
>> The multiple-buffer patch introduced some problems in some setups that are 
>> being
>> hard to debug, so Corentin gave the idea of reverting the until
>> commit 7bac4e1ec3ca2342929a39638d615c6b672c27a0 (net: stmmac: stmmac 
>> interrupt
>> treatment prepared for multiple queues), which I fully agree.
>>
>> In my setup is ok, but the idea is to have everyone's setup working :), so 
>> lets
>> break them into smaller pieces, and let's only apply them when everyone 
>> confirms
>> that is working ok in your setups, agree?
>>
>> What is the typical mechanism for this? I send a patch reverting them?
> 
> If you can compose a single "git revert" command to achieve this, just
> tell me what it is and I'll do it.
> 
> Otherwise send a patch that does the revert.

Ok, I sent 2 patches with fixes. Let's see if you get some happy clients.
If not, I will inform the commit id to revert.

Thanks David.

> 
> Thanks.
> 

[PATCH net-next 0/2] net: stmmac: multiple queue fixes

[Joao Pinto]

This patch set contains two fixes for problems I detected when ran the driver
in single queue mode.

Please test in your setups to check if you get better results.

Joao Pinto (2):
  net: stmmac: fix netdev release
  net: stmmac: fix number of tx queues in stmmac_poll

 drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 18 +++---
 1 file changed, 11 insertions(+), 7 deletions(-)

-- 
2.9.3

[PATCH net-next 2/2] net: stmmac: fix number of tx queues in stmmac_poll

[Joao Pinto]

For cores that have more than 1 TX queue configured, the kernel would crash,
since only one TX queue is permitted by default.

Signed-off-by: Joao Pinto <jpi...@synopsys.com>
---
 drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c 
b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
index 3827952..1eab084 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
@@ -3429,7 +3429,7 @@ static int stmmac_poll(struct napi_struct *napi, int 
budget)
struct stmmac_rx_queue *rx_q =
container_of(napi, struct stmmac_rx_queue, napi);
struct stmmac_priv *priv = rx_q->priv_data;
-   u32 tx_count = priv->dma_cap.number_tx_queues;
+   u32 tx_count = priv->plat->tx_queues_to_use;
u32 chan = rx_q->queue_index;
u32 work_done = 0;
u32 queue = 0;
-- 
2.9.3

[PATCH net-next 1/2] net: stmmac: fix netdev release

[Joao Pinto]

This patch fixes the kernel crash problem that happens when the driver
exits. The dma resouces must be freed after netdev resouces get freed and
in driver removed, multiple napi's should be deleted before removing
netdev resouces or it will hang.

Signed-off-by: Joao Pinto <jpi...@synopsys.com>
---
 drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 16 ++--
 1 file changed, 10 insertions(+), 6 deletions(-)

diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c 
b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
index 4b418d2..3827952 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
@@ -2659,9 +2659,6 @@ static int stmmac_release(struct net_device *dev)
/* Stop TX/RX DMA and clear the descriptors */
stmmac_stop_all_dma(priv);
 
-   /* Release and free the Rx/Tx resources */
-   free_dma_desc_resources(priv);
-
/* Disable the MAC Rx/Tx */
stmmac_set_mac(priv->ioaddr, false);
 
@@ -4080,7 +4077,7 @@ int stmmac_dvr_probe(struct device *device,
/* Init MAC and get the capabilities */
ret = stmmac_hw_init(priv);
if (ret)
-   goto error_hw_init;
+   return ret;
 
/* Configure real RX and TX queues */
ndev->real_num_rx_queues = priv->plat->rx_queues_to_use;
@@ -4207,9 +4204,8 @@ int stmmac_dvr_probe(struct device *device,
netif_napi_del(_q->napi);
}
 init_dma_error:
-   free_dma_desc_resources(priv);
-error_hw_init:
free_netdev(ndev);
+   free_dma_desc_resources(priv);
 
return ret;
 }
@@ -4225,6 +4221,7 @@ int stmmac_dvr_remove(struct device *dev)
 {
struct net_device *ndev = dev_get_drvdata(dev);
struct stmmac_priv *priv = netdev_priv(ndev);
+   u32 queue = 0;
 
netdev_info(priv->dev, "%s: removing driver", __func__);
 
@@ -4241,7 +4238,15 @@ int stmmac_dvr_remove(struct device *dev)
priv->hw->pcs != STMMAC_PCS_TBI &&
priv->hw->pcs != STMMAC_PCS_RTBI)
stmmac_mdio_unregister(ndev);
+
+   for (queue = 0; queue < priv->plat->rx_queues_to_use; queue++) {
+   struct stmmac_rx_queue *rx_q = >rx_queue[queue];
+
+   netif_napi_del(_q->napi);
+   }
+
free_netdev(ndev);
+   free_dma_desc_resources(priv);
 
return 0;
 }
-- 
2.9.3

Re: [v2,net-next,1/3] net: stmmac: enable multiple buffers

[Joao Pinto]

Hello David,

Às 5:05 PM de 3/24/2017, David Miller escreveu:
> From: Andrew Lunn 
> Date: Fri, 24 Mar 2017 12:17:36 +0100
> 
>>> Yes it would be fantastic to have a set of boards, but I rarely see this in 
>>> any
>>> maintainer :).
>>
>> Being a Marvell SoC and switch maintainer, i have around a dozen
>> boards. Some i got some simply by asking the manufacture, others i
>> purchased. I don't think i'm in the minority here. Without having
>> access to a number of different hardwares, i don't feel i would be
>> doing my work properly.
>>
>>> I try as hard as I can to network with people and try to minimize this
>>> situations, but when there is so many different setups using a driver with 
>>> diff
>>> configurations, situations like this can happen, but I am here to help 
>>> debugging
>>> and solving them.
>>
>> You made a move to rename stmmac to synopsys not long ago. It gave the
>> impression that synopsis wants to take over this driver. If there are
>> a number of different configurations, who better than synopsys to
>> actually properly test these configurations? If you ask around, i'm
>> sure people will send you hardware.
> 
> I completely agree with everything Andrew is saying here.
> 

I'll maintain the driver if everyone agrees with it, no problem, mas I would
like to hear from Peppe and Alex, since they are the current maintainers.

HW testing would be nice, but hard to justify investing in one shot, so it would
be great to receive hardware to make tests if the companies wish it.

About the problems in the last patch I am going to send a 2 patch set with 2
fixes, lets see if stuff gets better.

Thnaks
Joao

Fwd: Re: [v2,net-next,1/3] net: stmmac: enable multiple buffers

[Joao Pinto]

Sorry, sending again with David Miller in TO: instead of CC.

Às 2:09 PM de 3/24/2017, Corentin Labbe escreveu:
> On Thu, Mar 23, 2017 at 07:10:59PM +0100, Thierry Reding wrote:
>> On Thu, Mar 23, 2017 at 05:27:08PM +0000, Joao Pinto wrote:
>>> Hi Thierry,
>>>
>>
>> Yes, I can submit a patch for that.
>>
>> After some more testing I did get a couple (roughly 2 out of 10)
>> successful boots (I'm booting over NFS using the EQOS), and given that
>> this pointed towards something related to uninitialized data, I changed
>> all occurrences of kmalloc_array() with kcalloc() and that I've gotten
>> 10 successful reboots out of 10.
>>
>> I still can't pinpoint why this is now necessary since previously the
>> kmalloc_array() was working just fine. The only thing I can think of is
>> that we're not properly initializing all fields of the new queue
>> structures, since that's the only thing that's changed with this commit.
>>
>> I haven't investigated in detail yet, but from nothing so far has jumped
>> out at me.
>>
>> Thierry
> 
> I have tried this change, but it made the situation worse on dwmac-sunxi (no 
> network at all).
> 
> Joao, perhaps it's time to revert the faulty (and very huge) patch and rework 
> it by splitting at least in two:
> - adding RX queue / adding TX queue
> And more if possible (like just adding an unused queue parameter) or a patch 
> just for adding stmmac_free_tx_buffers() for example.
> I think it will help to find where the problem is.
> 
> And this time I will test them before applying:)
> 
> Regards
> Corentin Labbe
> 

Yes, I agree, it is better to revert and leave the tree functional for all.

@David Miller:
The multiple-buffer patch introduced some problems in some setups that are being
hard to debug, so Corentin gave the idea of reverting the until
commit 7bac4e1ec3ca2342929a39638d615c6b672c27a0 (net: stmmac: stmmac interrupt
treatment prepared for multiple queues), which I fully agree.

In my setup is ok, but the idea is to have everyone's setup working :), so lets
break them into smaller pieces, and let's only apply them when everyone confirms
that is working ok in your setups, agree?

What is the typical mechanism for this? I send a patch reverting them?

Thanks,
Joao

Re: [v2,net-next,1/3] net: stmmac: enable multiple buffers

[Joao Pinto]

Às 2:09 PM de 3/24/2017, Corentin Labbe escreveu:
> On Thu, Mar 23, 2017 at 07:10:59PM +0100, Thierry Reding wrote:
>> On Thu, Mar 23, 2017 at 05:27:08PM +0000, Joao Pinto wrote:
>>> Hi Thierry,
>>>
>>
>> Yes, I can submit a patch for that.
>>
>> After some more testing I did get a couple (roughly 2 out of 10)
>> successful boots (I'm booting over NFS using the EQOS), and given that
>> this pointed towards something related to uninitialized data, I changed
>> all occurrences of kmalloc_array() with kcalloc() and that I've gotten
>> 10 successful reboots out of 10.
>>
>> I still can't pinpoint why this is now necessary since previously the
>> kmalloc_array() was working just fine. The only thing I can think of is
>> that we're not properly initializing all fields of the new queue
>> structures, since that's the only thing that's changed with this commit.
>>
>> I haven't investigated in detail yet, but from nothing so far has jumped
>> out at me.
>>
>> Thierry
> 
> I have tried this change, but it made the situation worse on dwmac-sunxi (no 
> network at all).
> 
> Joao, perhaps it's time to revert the faulty (and very huge) patch and rework 
> it by splitting at least in two:
> - adding RX queue / adding TX queue
> And more if possible (like just adding an unused queue parameter) or a patch 
> just for adding stmmac_free_tx_buffers() for example.
> I think it will help to find where the problem is.
> 
> And this time I will test them before applying:)
> 
> Regards
> Corentin Labbe
> 

Yes, I agree, it is better to revert and leave the tree functional for all.

@David Miller:
The multiple-buffer patch introduced some problems in some setups that are being
hard to debug, so Corentin gave the idea of reverting the until
commit 7bac4e1ec3ca2342929a39638d615c6b672c27a0 (net: stmmac: stmmac interrupt
treatment prepared for multiple queues), which I fully agree.

In my setup is ok, but the idea is to have everyone's setup working :), so lets
break them into smaller pieces, and let's only apply them when everyone confirms
that is working ok in your setups, agree?

What is the typical mechanism for this? I send a patch reverting them?

Thanks,
Joao

Re: [v2,net-next,1/3] net: stmmac: enable multiple buffers

[Joao Pinto]

Às 11:17 AM de 3/24/2017, Andrew Lunn escreveu:
>> Yes it would be fantastic to have a set of boards, but I rarely see this in 
>> any
>> maintainer :).
> 
> Being a Marvell SoC and switch maintainer, i have around a dozen
> boards. Some i got some simply by asking the manufacture, others i
> purchased. I don't think i'm in the minority here. Without having
> access to a number of different hardwares, i don't feel i would be
> doing my work properly.
> 
>> I try as hard as I can to network with people and try to minimize this
>> situations, but when there is so many different setups using a driver with 
>> diff
>> configurations, situations like this can happen, but I am here to help 
>> debugging
>> and solving them.
> 
> You made a move to rename stmmac to synopsys not long ago. It gave the
> impression that synopsis wants to take over this driver. If there are
> a number of different configurations, who better than synopsys to
> actually properly test these configurations? If you ask around, i'm
> sure people will send you hardware.

If the stmmac community wishes that I become the maintainer and are available to
send me their ref hardware, I am available and I can build a farm in my site to
make all necessary tests to all the patches made by me and the ones that I 
receive.

> 
>  Andrew
> 

Joao

Re: [v2,net-next,1/3] net: stmmac: enable multiple buffers

[Joao Pinto]

Hi Andrew,

Às 7:42 AM de 3/24/2017, Andrew Lunn escreveu:
> On Thu, Mar 23, 2017 at 05:27:08PM +0000, Joao Pinto wrote:
> 
>> Yes, you are correct. It should be priv->plat->tx_queues_to_use instead of 
>> "u32
>> tx_count = priv->dma_cap.number_tx_queues;"... sorry for that, but in my 
>> setup
>> is the same value. Could you please make a patch for it?
> 
> Hi Joao
> 
> As the new maintainer, don't you think you should be testing on
> multiple systems? There are SoC vendor reference design boards you can
> buy, and set up a test farm. You can then ensure your new features
> don't break stuff, or add performance regressions.
> 
>   Andrew
> 

I am not the maintainer of stmmac :), I am just developing on it like everyone
else, just glad to help improving it and adding new features to it. Of course if
the current maintainers invite me to be, I will honored to do so.

Yes it would be fantastic to have a set of boards, but I rarely see this in any
maintainer :). I think it would be nice to have a farm like Linaro has with a
farm of boards donated by each company, enabling tests for everyone in the 
project.
I have talked with the Prototyping team and I will have an AXI based design,
which will emulate the SoC environment making possible to test the platform
driver scope.

I try as hard as I can to network with people and try to minimize this
situations, but when there is so many different setups using a driver with diff
configurations, situations like this can happen, but I am here to help debugging
and solving them.

Joao

Re: [v2,net-next,1/3] net: stmmac: enable multiple buffers

[Joao Pinto]

Hi Thierry,

Às 5:17 PM de 3/23/2017, Thierry Reding escreveu:
> On Fri, Mar 17, 2017 at 04:11:05PM +0000, Joao Pinto wrote:
>> This patch creates 2 new structures (stmmac_tx_queue and stmmac_rx_queue)
>> in include/linux/stmmac.h, enabling that each RX and TX queue has its
>> own buffers and data.
>>
>> Signed-off-by: Joao Pinto <jpi...@synopsys.com>
>> ---
>> changes v1->v2:
>> - just to keep up version
>>
>>  drivers/net/ethernet/stmicro/stmmac/chain_mode.c  |   45 +-
>>  drivers/net/ethernet/stmicro/stmmac/ring_mode.c   |   46 +-
>>  drivers/net/ethernet/stmicro/stmmac/stmmac.h  |   49 +-
>>  drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 1306 
>> ++---
>>  4 files changed, 973 insertions(+), 473 deletions(-)
> 
> Hi Joao,
> 
> This seems to break support on Tegra186 again. I've gone through this
> patch multiple times and I can't figure out what could be causing it.
> Any ideas?
> 
> What I'm seeing is that the transmit queue 0 times out:
> 
>   [  101.121774] Sending DHCP requests ...
>   [  111.841763] NETDEV WATCHDOG: eth0 (dwc-eth-dwmac): transmit queue 0 
> timed out

You are using a GMAC or GMAC4 aka QoS?

> 
> and then I also see this:
> 
>   [  112.252024] dwc-eth-dwmac 249.ethernet: DMA-API: device driver 
> tries to free DMA memory it has not allocated [device 
> address=0x57ac6e9d] [size=0 bytes]

Humm... Something in stmmac_free_tx_buffers... I'll need to check.

>   [  112.266606] [ cut here ]
>   [  112.271220] WARNING: CPU: 0 PID: 0 at 
> /home/thierry.reding/src/kernel/linux-tegra.git/lib/dma-debug.c:1106 
> check_unmap+0x7b0/0x930
>   [  112.282934] Modules linked in:
>   [  112.285985]
>   [  112.287474] CPU: 0 PID: 0 Comm: swapper/0 Tainted: G S  W   
> 4.11.0-rc3-next-20170323-00060-g2eab4557749b-dirty #400
>   [  112.298581] Hardware name: NVIDIA Tegra186 P2771- Development 
> Board (DT)
>   [  112.305615] task: 08f87b00 task.stack: 08f7
>   [  112.311523] PC is at check_unmap+0x7b0/0x930
>   [  112.315785] LR is at check_unmap+0x7b0/0x930
>   [  112.320046] pc : [] lr : [] 
> pstate: 6145
>   [  112.327426] sp : 8001f5e50c50
>   [  112.330733] x29: 8001f5e50c50 x28: 08f75180
>   [  112.336042] x27: 08f87b00 x26: 0020
>   [  112.341351] x25: 0140 x24: 08f81000
>   [  112.346660] x23: 8001ec4b0810 x22: 57ac6e9d
>   [  112.351969] x21: 57ac6e9d x20: 8001f5e50cb0
>   [  112.357277] x19: 8001ec4b0810 x18: 0010
>   [  112.362586] x17: 262ea01f x16: 0f48bf67
>   [  112.367895] x15: 0006 x14: 5d64396536636137
>   [  112.373203] x13: 3530303030303030 x12: 3078303d73736572
>   [  112.378511] x11: 6464612065636976 x10: 65645b2064657461
>   [  112.383819] x9 : 0852c238 x8 : 01fb
>   [  112.389126] x7 :  x6 : 0810ad58
>   [  112.394434] x5 :  x4 : 
>   [  112.399743] x3 :  x2 : 08f99258
>   [  112.405050] x1 : 08f87b00 x0 : 0097
>   [  112.410358]
>   [  112.411846] ---[ end trace 48028f96a0e990fb ]---
>   [  112.416453] Call trace:
>   [  112.418895] Exception stack(0x8001f5e50a80 to 0x8001f5e50bb0)
>   [  112.425324] 0a80: 8001ec4b0810 0001 8001f5e50c50 
> 083d75f0
>   [  112.433139] 0aa0: 01c0   
> 08d1c0c0
>   [  112.440954] 0ac0: 8001f5e50c50 8001f5e50c50 8001f5e50c10 
> ffc8
>   [  112.448769] 0ae0: 8001f5e50b10 0810c3a8 8001f5e50c50 
> 8001f5e50c50
>   [  112.456585] 0b00: 8001f5e50c10 ffc8 8001f5e50bc0 
> 08178388
>   [  112.464399] 0b20: 0097 08f87b00 08f99258 
> 
>   [  112.472215] 0b40:   0810ad58 
> 
>   [  112.480030] 0b60: 01fb 0852c238 65645b2064657461 
> 6464612065636976
>   [  112.487845] 0b80: 3078303d73736572 3530303030303030 5d64396536636137 
> 0006
>   [  112.495659] 0ba0: 0f48bf67 262ea01f
>   [  112.500528] [] check_unmap+0x7b0/0x930
>   [  112.505830] [] debug_dma_unmap_page+0x68/0x70
>   [  112.511744] [] 
> stmmac_free_tx_buffers.isra.1+0x114/0x198
>   [  112.518604] [] stmmac_tx_err+0x7c/0x160
>   [  112.5239

Re: stmmac: Performance regression after commit aff3d9eff843 "net: stmmac: enable multiple buffers"

[Joao Pinto]

Às 10:56 AM de 3/23/2017, Joao Pinto escreveu:
> Às 10:51 AM de 3/23/2017, Giuseppe CAVALLARO escreveu:
>> On 3/23/2017 11:48 AM, Giuseppe CAVALLARO wrote:
>>> Hello
>>>
>>> On 3/23/2017 11:20 AM, Corentin Labbe wrote:
>>>>> I have a 4.21 QoS Core with 4 RX + 4 TX and detected no regression.
>>>>>> Could you please share the iperf cmds you are using in order for me to
>>>>> reproduce
>>>>>> in my side?
>>>

HW Version: 4.21 QoS Core in HAPS DX7 (FPGA)
The connection between the FPGA and PC where stmmac is running is PCIe.
My configurations are done in stmmac_pci. Here they are:

@@ -68,10 +70,52 @@ static void stmmac_default_data(struct plat_stmmacenet_data
*plat)
 {
plat->bus_id = 1;
plat->phy_addr = 0;
-   plat->interface = PHY_INTERFACE_MODE_GMII;
-   plat->clk_csr = 2;  /* clk_csr_i = 20-35MHz & MDC = clk_csr_i/16 */
-   plat->has_gmac = 1;
-   plat->force_sf_dma_mode = 1;
+   plat->interface = PHY_INTERFACE_MODE_SGMII;
+   plat->clk_csr = 0x5;
+   plat->has_gmac = 0;
+   plat->has_gmac4 = 1;
+   plat->force_sf_dma_mode = 0;
+
+   plat->rx_queues_to_use = 4;
+   plat->tx_queues_to_use = 4;
+
+   plat->rx_sched_algorithm = MTL_RX_ALGORITHM_SP;
+
+   plat->rx_queues_cfg[0].mode_to_use = MTL_QUEUE_AVB;
+   plat->rx_queues_cfg[1].mode_to_use = MTL_QUEUE_DCB;
+   plat->rx_queues_cfg[2].mode_to_use = MTL_QUEUE_DCB;
+   plat->rx_queues_cfg[3].mode_to_use = MTL_QUEUE_DCB;
+
+   plat->tx_queues_cfg[0].mode_to_use = MTL_QUEUE_DCB;
+   plat->tx_queues_cfg[1].mode_to_use = MTL_QUEUE_AVB;
+   plat->tx_queues_cfg[2].mode_to_use = MTL_QUEUE_DCB;
+   plat->tx_queues_cfg[3].mode_to_use = MTL_QUEUE_DCB;
+
+   plat->tx_queues_cfg[1].send_slope = 0xCCC;
+   plat->tx_queues_cfg[1].idle_slope = 0x1333;
+   plat->tx_queues_cfg[1].high_credit = 0x4B;
+   plat->tx_queues_cfg[1].low_credit = 0xFFB5;
+
+   plat->rx_queues_cfg[0].chan = 0;
+   plat->rx_queues_cfg[1].chan = 1;
+   plat->rx_queues_cfg[2].chan = 2;
+   plat->rx_queues_cfg[3].chan = 3;
+
+   plat->tx_sched_algorithm = MTL_TX_ALGORITHM_WRR;
+   plat->tx_queues_cfg[0].weight = 0x10;
+   plat->tx_queues_cfg[1].weight = 0x11;
+   plat->tx_queues_cfg[2].weight = 0x12;
+   plat->tx_queues_cfg[3].weight = 0x13;
+
+   /* Disable Priority config by default */
+   plat->tx_queues_cfg[0].use_prio = false;
+   plat->rx_queues_cfg[0].use_prio = false;
+
+   /* Disable RX queues routing by default */
+   plat->rx_queues_cfg[0].pkt_route = 0x0;
+   plat->rx_queues_cfg[1].pkt_route = 0x0;
+   plat->rx_queues_cfg[2].pkt_route = 0x0;
+   plat->rx_queues_cfg[3].pkt_route = 0x0;

plat->mdio_bus_data->phy_reset = NULL;
plat->mdio_bus_data->phy_mask = 0;
@@ -83,22 +127,14 @@ static void stmmac_default_data(struct plat_stmmacenet_data
*plat)
/* Set default value for multicast hash bins */
plat->multicast_filter_bins = HASH_TABLE_SIZE;

+   plat->dma_cfg->fixed_burst = 0;
+   plat->dma_cfg->aal = 0;
+
/* Set default value for unicast filter entries */
plat->unicast_filter_entries = 1;

/* Set the maxmtu to a default of JUMBO_LEN */
plat->maxmtu = JUMBO_LEN;
-
-   /* Set default number of RX and TX queues to use */
-   plat->tx_queues_to_use = 1;
-   plat->rx_queues_to_use = 1;
-
-   /* Disable Priority config by default */
-   plat->tx_queues_cfg[0].use_prio = false;
-   plat->rx_queues_cfg[0].use_prio = false;
-
-   /* Disable RX queues routing by default */
-   plat->rx_queues_cfg[0].pkt_route = 0x0;
 }


*** TESTS ***


*TEST 1: File (linux-next tarball) transfer of ~1.4G by scp to the DUT*

scp net-next-20170323.tar.gz x@XXX:/home/synopsys/
The authenticity of host 'X' can't be established.
ECDSA key fingerprint is SHA256:/XX.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added 'XX' (ECDSA) to the list of known hosts.
XX@X's password:
net-next20170323.tar.gz

 100% 1366MB  79.3MB/s   00:17

ifconfig after transfer:

eth1  Link encap:Ethernet  HWaddr 
  inet addr:  Bcast:  Mask:
  inet6 addr: X Scope:Link
  UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
  RX packets:1026614 errors:0 dropped:0 overruns:0 frame:0
  TX packets:56804 errors:0 dropped:0 overruns:0 carrier:0
  collisions:0 txqueuelen:1000
  RX bytes:1502856063 (1.5 GB)  TX bytes:4224767 (4.2 MB)
  Interrupt:16

*stmmac Log after transfer:

#:~/temp$ dmesg | grep stmmac
[0.

Re: stmmac: Performance regression after commit aff3d9eff843 "net: stmmac: enable multiple buffers"

[Joao Pinto]

Às 10:51 AM de 3/23/2017, Giuseppe CAVALLARO escreveu:
> On 3/23/2017 11:48 AM, Giuseppe CAVALLARO wrote:
>> Hello
>>
>> On 3/23/2017 11:20 AM, Corentin Labbe wrote:
 I have a 4.21 QoS Core with 4 RX + 4 TX and detected no regression.
 >Could you please share the iperf cmds you are using in order for me to
 reproduce
 >in my side?
>>
>> Joao, you have a really powerful HW integration with multiple channels for
>> both RX and TX.
>> Often this is not the same for other setup where, usually just a DMA0 is
>> present or, sometime, there
>> is just one RX extra channel.
>>
>> My question is, what happens on this kind of configurations? Are we still
>> guarantying the best performances?
>>
>> Also we have to guarantee, that the TSO and SG are always working. Another
>> point is the buffer sizes that
>> can be different among platforms.
>>
>> The problem  below reported by Corentin push me to think that there is a bug,
>> so we should
>> understand when this has been introduced and if likely fixed by some
>> configuration we are
>> not take care right now.
>>
>> ndesc_get_rx_status: Oversized frame spanned multiple buffers"
> 
> I wonder if this could be easily triggered by getting a big file via FTP. So 
> not
> properly related on performance benchs

I am going to do that test and check it out and also run iperf a couple of
times. I am counting on doing this today and send you later the results. If
anyone gets results sooner please share.

> 
> peppe
> 
>>
>>
>> Best Regards
>> Peppe
>>
> 

Thanks.

Re: stmmac: Performance regression after commit aff3d9eff843 "net: stmmac: enable multiple buffers"

[Joao Pinto]

Hi Peppe,

Às 10:48 AM de 3/23/2017, Giuseppe CAVALLARO escreveu:
> Hello
> 
> On 3/23/2017 11:20 AM, Corentin Labbe wrote:
>>> I have a 4.21 QoS Core with 4 RX + 4 TX and detected no regression.
>>> >Could you please share the iperf cmds you are using in order for me to
>>> reproduce
>>> >in my side?
> 
> Joao, you have a really powerful HW integration with multiple channels for 
> both
> RX and TX.
> Often this is not the same for other setup where, usually just a DMA0 is 
> present
> or, sometime, there
> is just one RX extra channel.

My opinion is that we should not have problems, since the majority of features
introduced are used if you configure rx queues > 1 or tx queues > 1, so if you
use the default (=1) those confiogurations will not take place.

> 
> My question is, what happens on this kind of configurations? Are we still
> guarantying the best performances?
> 
> Also we have to guarantee, that the TSO and SG are always working. Another 
> point
> is the buffer sizes that
> can be different among platforms.

We have to pay attention to the RX buffer size, since I had problems with DHCP
messages not being received because of little buffer size.
Currently TX buffer size is not configurable and in the future it should be
useful to include it too.

> 
> The problem  below reported by Corentin push me to think that there is a bug, 
> so
> we should
> understand when this has been introduced and if likely fixed by some
> configuration we are
> not take care right now.

Of course.

> 
> ndesc_get_rx_status: Oversized frame spanned multiple buffers"
> 
> 
> Best Regards
> Peppe

Thanks,
Joao

Re: stmmac: Performance regression after commit aff3d9eff843 "net: stmmac: enable multiple buffers"

[Joao Pinto]

Às 10:20 AM de 3/23/2017, Corentin Labbe escreveu:
> On Thu, Mar 23, 2017 at 10:12:18AM +0000, Joao Pinto wrote:
>>
>> Hi Corentin,
>>
>> Às 10:08 AM de 3/23/2017, Corentin Labbe escreveu:
>>> Hello
>>>
>>> Using next-20170323 produce a huge performance regression on my sunxi 
>>> boards.
>>> On dwmac-sun8i, iperf goes from 94mbs/s to 37 when sending.
>>>
>>> On cubieboard2(dwmac-sunxi), iperf made the kernel flood with 
>>> "ndesc_get_rx_status: Oversized frame spanned multiple buffers"
>>> and network is lost after.
>>>
>>> Reverting aff3d9eff84399e433c4aca65a9bb236581bc082 fix the issue.
>>> I still try to found which part of this patch mades the performance lower.
>>>
>>> Regards
>>> Corentin Labbe
>>>
>>
>> I have a 4.21 QoS Core with 4 RX + 4 TX and detected no regression.
>> Could you please share the iperf cmds you are using in order for me to 
>> reproduce
>> in my side?
> 
> simple iperf -c serverip for both board
> 

Ok, I am going to run my tests with a fresh net-next and come back to you soon.

Thanks,
Joao

Re: stmmac: Performance regression after commit aff3d9eff843 "net: stmmac: enable multiple buffers"

[Joao Pinto]

Hi Corentin,

Às 10:08 AM de 3/23/2017, Corentin Labbe escreveu:
> Hello
> 
> Using next-20170323 produce a huge performance regression on my sunxi boards.
> On dwmac-sun8i, iperf goes from 94mbs/s to 37 when sending.
> 
> On cubieboard2(dwmac-sunxi), iperf made the kernel flood with 
> "ndesc_get_rx_status: Oversized frame spanned multiple buffers"
> and network is lost after.
> 
> Reverting aff3d9eff84399e433c4aca65a9bb236581bc082 fix the issue.
> I still try to found which part of this patch mades the performance lower.
> 
> Regards
> Corentin Labbe
> 

I have a 4.21 QoS Core with 4 RX + 4 TX and detected no regression.
Could you please share the iperf cmds you are using in order for me to reproduce
in my side?

@stmmac users: It would be great if people that have a setup could also perform
teh same iperf test in order to clean in up for everyone.

Thanks,
Joao

[PATCH v3 net-next] net: stmmac: fix dma operation mode config for older versions

[Joao Pinto]

The dma operation mode configuration routine was wrongly moved to a
function (stmmac_mtl_configuration) that is only executed if the
core version is >= 4.00.

Fixes: 6deee2221e11 ("net: stmmac: prepare dma op mode config for multiple 
queues")
Reported-by: Corentin Labbe <clabbe.montj...@gmail.com>
Reviewed-by: Thierry Reding <thierry.red...@gmail.com>
Signed-off-by: Joao Pinto <jpi...@synopsys.com>
---
changes v2->v3:
- Commit ID and title should be under a 'Fixes' tag
changes v1->v2:
- commit id did not have 12 digits

 drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c 
b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
index d3a2151..225a3a3 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
@@ -1945,9 +1945,6 @@ static void stmmac_mtl_configuration(struct stmmac_priv 
*priv)
/* Enable MAC RX Queues */
if (rx_queues_count > 1 && priv->hw->mac->rx_queue_enable)
stmmac_mac_enable_rx_queues(priv);
-
-   /* Set the HW DMA mode and the COE */
-   stmmac_dma_operation_mode(priv);
 }
 
 /**
@@ -2014,6 +2011,9 @@ static int stmmac_hw_setup(struct net_device *dev, bool 
init_ptp)
else
stmmac_set_mac(priv->ioaddr, true);
 
+   /* Set the HW DMA mode and the COE */
+   stmmac_dma_operation_mode(priv);
+
stmmac_mmc_setup(priv);
 
if (init_ptp) {
-- 
2.9.3

Re: [PATCH v2 net-next] net: fix dma operation mode config for older versions

[Joao Pinto]

Às 6:56 PM de 3/21/2017, Florian Fainelli escreveu:
> On 03/21/2017 11:02 AM, Joao Pinto wrote:
>> This patch fixes a bug introduced in:
>> commit 6deee2221e11 ("net: stmmac: prepare dma op mode config for multiple
>> queues")
> 
> So even though this is against net-next which is the only tree so far
> having the offending commit, it is nice to see this appear later in the
> commit messages as:
> 
> Fixes: 6deee2221e11 ("net: stmmac: prepare dma op mode config for
> multiple queues")
> 
> Also, your subject for this patch should be:
> 
> net: stmmac: fix dma operation mode config for older versions

Ok, I will do that! Thanks.

> 
>>
>> The dma operation mode configuration routine was wrongly moved to a
>> function (stmmac_mtl_configuration) that is only executed if the
>> core version is >= 4.00.
>>
>> Reported-by: Corentin Labbe <clabbe.montj...@gmail.com>
>> Signed-off-by: Joao Pinto <jpi...@synopsys.com>
>> ---
>>  drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 6 +++---
>>  1 file changed, 3 insertions(+), 3 deletions(-)
>>
>> diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c 
>> b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
>> index d3a2151..225a3a3 100644
>> --- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
>> +++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
>> @@ -1945,9 +1945,6 @@ static void stmmac_mtl_configuration(struct 
>> stmmac_priv *priv)
>>  /* Enable MAC RX Queues */
>>  if (rx_queues_count > 1 && priv->hw->mac->rx_queue_enable)
>>  stmmac_mac_enable_rx_queues(priv);
>> -
>> -/* Set the HW DMA mode and the COE */
>> -stmmac_dma_operation_mode(priv);
>>  }
>>  
>>  /**
>> @@ -2014,6 +2011,9 @@ static int stmmac_hw_setup(struct net_device *dev, 
>> bool init_ptp)
>>  else
>>  stmmac_set_mac(priv->ioaddr, true);
>>  
>> +/* Set the HW DMA mode and the COE */
>> +stmmac_dma_operation_mode(priv);
>> +
>>  stmmac_mmc_setup(priv);
>>  
>>  if (init_ptp) {
>>
> 
> 

Re: [PATCH net-next] net: fix dma operation mode config for older versions

[Joao Pinto]

Às 5:53 PM de 3/21/2017, Sergei Shtylyov escreveu:
> On 03/21/2017 08:36 PM, Joao Pinto wrote:
> 
>> This patch fixes a bug introduced in commit:
>> 6deee22 (net: stmmac: prepare dma op mode config for multiple queues)
> 
>Need 12 hex digits and the commit summary enclosed into ("").
> 
>> The dma operation mode configuration routine was wrongly moved to a
>> function (stmmac_mtl_configuration) that is only executed if the
>> core version is >= 4.00.
>>
>> Reported-by: Corentin Labbe <clabbe.montj...@gmail.com>
>>
>> Signed-off-by: Joao Pinto <jpi...@synopsys.com>
> [...]
> 
> MBR, Sergei
> 

Thanks for the tip, going to send a v2.

Joao

[PATCH v2 net-next] net: fix dma operation mode config for older versions

[Joao Pinto]

This patch fixes a bug introduced in:
commit 6deee2221e11 ("net: stmmac: prepare dma op mode config for multiple
queues")

The dma operation mode configuration routine was wrongly moved to a
function (stmmac_mtl_configuration) that is only executed if the
core version is >= 4.00.

Reported-by: Corentin Labbe <clabbe.montj...@gmail.com>
Signed-off-by: Joao Pinto <jpi...@synopsys.com>
---
 drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c 
b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
index d3a2151..225a3a3 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
@@ -1945,9 +1945,6 @@ static void stmmac_mtl_configuration(struct stmmac_priv 
*priv)
/* Enable MAC RX Queues */
if (rx_queues_count > 1 && priv->hw->mac->rx_queue_enable)
stmmac_mac_enable_rx_queues(priv);
-
-   /* Set the HW DMA mode and the COE */
-   stmmac_dma_operation_mode(priv);
 }
 
 /**
@@ -2014,6 +2011,9 @@ static int stmmac_hw_setup(struct net_device *dev, bool 
init_ptp)
else
stmmac_set_mac(priv->ioaddr, true);
 
+   /* Set the HW DMA mode and the COE */
+   stmmac_dma_operation_mode(priv);
+
stmmac_mmc_setup(priv);
 
if (init_ptp) {
-- 
2.9.3

[PATCH net-next] net: fix dma operation mode config for older versions

[Joao Pinto]

This patch fixes a bug introduced in commit:
6deee22 (net: stmmac: prepare dma op mode config for multiple queues)

The dma operation mode configuration routine was wrongly moved to a
function (stmmac_mtl_configuration) that is only executed if the
core version is >= 4.00.

Reported-by: Corentin Labbe <clabbe.montj...@gmail.com>

Signed-off-by: Joao Pinto <jpi...@synopsys.com>
---
 drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c 
b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
index d3a2151..225a3a3 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
@@ -1945,9 +1945,6 @@ static void stmmac_mtl_configuration(struct stmmac_priv 
*priv)
/* Enable MAC RX Queues */
if (rx_queues_count > 1 && priv->hw->mac->rx_queue_enable)
stmmac_mac_enable_rx_queues(priv);
-
-   /* Set the HW DMA mode and the COE */
-   stmmac_dma_operation_mode(priv);
 }
 
 /**
@@ -2014,6 +2011,9 @@ static int stmmac_hw_setup(struct net_device *dev, bool 
init_ptp)
else
stmmac_set_mac(priv->ioaddr, true);
 
+   /* Set the HW DMA mode and the COE */
+   stmmac_dma_operation_mode(priv);
+
stmmac_mmc_setup(priv);
 
if (init_ptp) {
-- 
2.9.3

Re: [PATCH 3/3] net: stmmac: Use AVB mode by default

[Joao Pinto]

Às 4:50 PM de 3/21/2017, Joao Pinto escreveu:
> Às 4:42 PM de 3/21/2017, Thierry Reding escreveu:
>> On Tue, Mar 21, 2017 at 03:23:00PM +0000, Joao Pinto wrote:
>>> Às 3:12 PM de 3/21/2017, Thierry Reding escreveu:
>>>> From: Thierry Reding <tred...@nvidia.com>
>>>>
>>>> Prior to the recent multi-queue changes the driver would configure the
>>>> queues to use the AVB mode, but the mode then got switched to DCB. The
>>>> hardware still works fine in DCB mode, but my testing capabilities are
>>>> limited, so it's safer to revert to the prior setting anyway.
>>>>
>>>> Signed-off-by: Thierry Reding <tred...@nvidia.com>
>>>> ---
>>>>  include/linux/stmmac.h | 4 ++--
>>>>  1 file changed, 2 insertions(+), 2 deletions(-)
>>>>
>>>> diff --git a/include/linux/stmmac.h b/include/linux/stmmac.h
>>>> index be47b859e954..8349a5c1537b 100644
>>>> --- a/include/linux/stmmac.h
>>>> +++ b/include/linux/stmmac.h
>>>> @@ -56,8 +56,8 @@
>>>>  #define MTL_RX_ALGORITHM_WSP  0x5
>>>>  
>>>>  /* RX/TX Queue Mode */
>>>> -#define MTL_QUEUE_DCB 0x0
>>>> -#define MTL_QUEUE_AVB 0x1
>>>> +#define MTL_QUEUE_AVB 0x0
>>>> +#define MTL_QUEUE_DCB 0x1
>>>>  
>>>>  /* The MDC clock could be set higher than the IEEE 802.3
>>>>   * specified frequency limit 0f 2.5 MHz, by programming a clock divider
>>>>
>>>
>>> Thierry, I don't understand this patch. It will have 0 impact.
>>>
>>> In stmmac_platform configuration, 0 impact:
>>>
>>> if (of_property_read_bool(q_node, "snps,dcb-algorithm"))
>>> plat->rx_queues_cfg[queue].mode_to_use = MTL_QUEUE_DCB;
>>> else if (of_property_read_bool(q_node, "snps,avb-algorithm"))
>>> plat->rx_queues_cfg[queue].mode_to_use = MTL_QUEUE_AVB;
>>> else
>>> **  plat->rx_queues_cfg[queue].mode_to_use = MTL_QUEUE_DCB;
>>>
>>> In dwmac4_core, 0 impact:
>>>
>>> value &= GMAC_RX_QUEUE_CLEAR(queue);
>>> if (mode == MTL_QUEUE_AVB)
>>> value |= GMAC_RX_AV_QUEUE_ENABLE(queue);
>>> else if (mode == MTL_QUEUE_DCB)
>>> value |= GMAC_RX_DCB_QUEUE_ENABLE(queue);
>>>
>>> I think you should set the default mode in (**).
>>
>> That was my initial attempt, but then I realized that for old DTBs,
>> stmmac_mtl_setup() will already exit prematurely because of the missing
>> snps,mtl-{rx,tx}-config properties. It's pretty much for the same reason
>> as the separate assignment of the default {rx,tx}_queues_to_use. In this
>> case it's somewhat more obfuscated, though. Changing AVB to be mode 0
>> means that plat->rx_queues_cfg[].mode_to_use will contain AVB as default
>> because plat is devm_kzalloc()'ed.
>>
>> Effectively this change makes all queues use AVB by default unless they
>> are configured using the new device tree bindings.
> 
> Yes I keep forgeting that :), but you are assuming that
> plat->rx_queues_cfg[queue].mode_to_use is 0 by default, which might not be the
> case, but I agree with you that this is the simpler approach. Let's see what
> others have to say.

Forget what I said, yes devm_kzalloc() in plat guarantees this. I need a cup of
coffee :).

Acked-By: Joao Pinto <jpi...@synopsys.com>
>>
>> Thierry
>>
> 

Re: [PATCH 3/3] net: stmmac: Use AVB mode by default

[Joao Pinto]

Às 4:42 PM de 3/21/2017, Thierry Reding escreveu:
> On Tue, Mar 21, 2017 at 03:23:00PM +0000, Joao Pinto wrote:
>> Às 3:12 PM de 3/21/2017, Thierry Reding escreveu:
>>> From: Thierry Reding <tred...@nvidia.com>
>>>
>>> Prior to the recent multi-queue changes the driver would configure the
>>> queues to use the AVB mode, but the mode then got switched to DCB. The
>>> hardware still works fine in DCB mode, but my testing capabilities are
>>> limited, so it's safer to revert to the prior setting anyway.
>>>
>>> Signed-off-by: Thierry Reding <tred...@nvidia.com>
>>> ---
>>>  include/linux/stmmac.h | 4 ++--
>>>  1 file changed, 2 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/include/linux/stmmac.h b/include/linux/stmmac.h
>>> index be47b859e954..8349a5c1537b 100644
>>> --- a/include/linux/stmmac.h
>>> +++ b/include/linux/stmmac.h
>>> @@ -56,8 +56,8 @@
>>>  #define MTL_RX_ALGORITHM_WSP   0x5
>>>  
>>>  /* RX/TX Queue Mode */
>>> -#define MTL_QUEUE_DCB  0x0
>>> -#define MTL_QUEUE_AVB  0x1
>>> +#define MTL_QUEUE_AVB  0x0
>>> +#define MTL_QUEUE_DCB  0x1
>>>  
>>>  /* The MDC clock could be set higher than the IEEE 802.3
>>>   * specified frequency limit 0f 2.5 MHz, by programming a clock divider
>>>
>>
>> Thierry, I don't understand this patch. It will have 0 impact.
>>
>> In stmmac_platform configuration, 0 impact:
>>
>>  if (of_property_read_bool(q_node, "snps,dcb-algorithm"))
>>  plat->rx_queues_cfg[queue].mode_to_use = MTL_QUEUE_DCB;
>>  else if (of_property_read_bool(q_node, "snps,avb-algorithm"))
>>  plat->rx_queues_cfg[queue].mode_to_use = MTL_QUEUE_AVB;
>>  else
>> **   plat->rx_queues_cfg[queue].mode_to_use = MTL_QUEUE_DCB;
>>
>> In dwmac4_core, 0 impact:
>>
>>  value &= GMAC_RX_QUEUE_CLEAR(queue);
>>  if (mode == MTL_QUEUE_AVB)
>>  value |= GMAC_RX_AV_QUEUE_ENABLE(queue);
>>  else if (mode == MTL_QUEUE_DCB)
>>  value |= GMAC_RX_DCB_QUEUE_ENABLE(queue);
>>
>> I think you should set the default mode in (**).
> 
> That was my initial attempt, but then I realized that for old DTBs,
> stmmac_mtl_setup() will already exit prematurely because of the missing
> snps,mtl-{rx,tx}-config properties. It's pretty much for the same reason
> as the separate assignment of the default {rx,tx}_queues_to_use. In this
> case it's somewhat more obfuscated, though. Changing AVB to be mode 0
> means that plat->rx_queues_cfg[].mode_to_use will contain AVB as default
> because plat is devm_kzalloc()'ed.
> 
> Effectively this change makes all queues use AVB by default unless they
> are configured using the new device tree bindings.

Yes I keep forgeting that :), but you are assuming that
plat->rx_queues_cfg[queue].mode_to_use is 0 by default, which might not be the
case, but I agree with you that this is the simpler approach. Let's see what
others have to say.
> 
> Thierry
> 

Re: [PATCH 3/3] net: stmmac: Use AVB mode by default

[Joao Pinto]

Às 3:12 PM de 3/21/2017, Thierry Reding escreveu:
> From: Thierry Reding 
> 
> Prior to the recent multi-queue changes the driver would configure the
> queues to use the AVB mode, but the mode then got switched to DCB. The
> hardware still works fine in DCB mode, but my testing capabilities are
> limited, so it's safer to revert to the prior setting anyway.
> 
> Signed-off-by: Thierry Reding 
> ---
>  include/linux/stmmac.h | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/include/linux/stmmac.h b/include/linux/stmmac.h
> index be47b859e954..8349a5c1537b 100644
> --- a/include/linux/stmmac.h
> +++ b/include/linux/stmmac.h
> @@ -56,8 +56,8 @@
>  #define MTL_RX_ALGORITHM_WSP 0x5
>  
>  /* RX/TX Queue Mode */
> -#define MTL_QUEUE_DCB0x0
> -#define MTL_QUEUE_AVB0x1
> +#define MTL_QUEUE_AVB0x0
> +#define MTL_QUEUE_DCB0x1
>  
>  /* The MDC clock could be set higher than the IEEE 802.3
>   * specified frequency limit 0f 2.5 MHz, by programming a clock divider
> 

Thierry, I don't understand this patch. It will have 0 impact.

In stmmac_platform configuration, 0 impact:

if (of_property_read_bool(q_node, "snps,dcb-algorithm"))
plat->rx_queues_cfg[queue].mode_to_use = MTL_QUEUE_DCB;
else if (of_property_read_bool(q_node, "snps,avb-algorithm"))
plat->rx_queues_cfg[queue].mode_to_use = MTL_QUEUE_AVB;
else
**  plat->rx_queues_cfg[queue].mode_to_use = MTL_QUEUE_DCB;

In dwmac4_core, 0 impact:

value &= GMAC_RX_QUEUE_CLEAR(queue);
if (mode == MTL_QUEUE_AVB)
value |= GMAC_RX_AV_QUEUE_ENABLE(queue);
else if (mode == MTL_QUEUE_DCB)
value |= GMAC_RX_DCB_QUEUE_ENABLE(queue);

I think you should set the default mode in (**).

Thanks.

Re: [PATCH 2/3] net: stmmac: Restore DT backwards-compatibility

[Joao Pinto]

Às 3:12 PM de 3/21/2017, Thierry Reding escreveu:
> From: Thierry Reding <tred...@nvidia.com>
> 
> Recent changes to support multiple queues in the device tree bindings
> resulted in the number of RX and TX queues to be initialized to zero for
> device trees not adhering to the new bindings.
> 
> Restore backwards-compatibility with those device trees by falling back
> to a single RX and TX queues each.
> 
> Signed-off-by: Thierry Reding <tred...@nvidia.com>
> ---
>  drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c | 7 +++
>  1 file changed, 7 insertions(+)
> 
> diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c 
> b/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
> index 37f550ae76a5..74b0aff79b25 100644
> --- a/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
> +++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
> @@ -143,6 +143,13 @@ static void stmmac_mtl_setup(struct platform_device 
> *pdev,
>   struct device_node *tx_node;
>   u8 queue = 0;
>  
> + /* For backwards-compatibility with device trees that don't have any
> +  * snps,mtl-rx-config or snps,mtl-tx-config properties, we fall back
> +  * to one RX and TX queues each.
> +  */
> + plat->rx_queues_to_use = 1;
> + plat->tx_queues_to_use = 1;
> +
>   rx_node = of_parse_phandle(pdev->dev.of_node, "snps,mtl-rx-config", 0);
>   if (!rx_node)
>   return;
> 

Acked-By: Joao Pinto <jpi...@synopsys.com>

Re: [PATCH 1/3] net: stmmac: Always enable MAC RX queues

[Joao Pinto]

Às 3:12 PM de 3/21/2017, Thierry Reding escreveu:
> From: Thierry Reding <tred...@nvidia.com>
> 
> The MAC RX queues always need to be enabled in order to receive network
> packets. Remove the condition that this only needs to be done for multi-
> queue configurations.
> 
> Signed-off-by: Thierry Reding <tred...@nvidia.com>
> ---
>  drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c 
> b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
> index d3a21519e4c0..298956032098 100644
> --- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
> +++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
> @@ -1943,7 +1943,7 @@ static void stmmac_mtl_configuration(struct stmmac_priv 
> *priv)
>   stmmac_rx_queue_dma_chan_map(priv);
>  
>   /* Enable MAC RX Queues */
> - if (rx_queues_count > 1 && priv->hw->mac->rx_queue_enable)
> + if (priv->hw->mac->rx_queue_enable)
>   stmmac_mac_enable_rx_queues(priv);
>  
>   /* Set the HW DMA mode and the COE */
> 

This text is from the Databook:

"In multiple Rx queues configuration, all the queues are disabled by default.
Enable the Rx queue by programming the corresponding field in this register."

So by theory, only multiple queue configured cores needs the enable operation.

>>> But came to my attention a setup that has 1 RX queue and 2 TX queues, which
enables multiple queues mechanism inside the core (even with 1 RX) and so RX
needs to be enabled. Because of that I agree with this patch.

Acked-By: Joao Pinto <jpi...@synopsys.com>

Re: linux-next-20170320 break stmmac on dwmac-sunxi

[Joao Pinto]

Hi Peppe,

Às 2:39 PM de 3/21/2017, Giuseppe CAVALLARO escreveu:
> Hello Corentin
> 
> yes, bisect process is really good approach to me. Pls give us more details.
> Recently the multi DMA channel logic has been added so it could be that
> something is needed to allow your platform to manage the new code.
> Or we introduced some regression. If I have some other idea, I ping you.
> 
> Peppe
> 
> On 3/20/2017 8:54 PM, Corentin Labbe wrote:
>> Hello
>>
>> Just pushed next-20170320 to my boards and stmmac stop working on both intree
>> dwmac-sunxi and my dev dwmac-sun8i.
>> It seems that interrupts never fire, and transmit queue timeout.
>> I will try to bisect this problem but perhaps other people could try to
>> reproduce it.
>>
>> Regards
>> Corentin Labbe
>>
> 

Corentin spotted 2 bugs (dma_op_mode was only being set for core versions >=
4.00 and rx/tx default nº of queues was being set in a place that would not be
accessible if no multiqueue config is added to the DT). Thierry will send a set
of patches to improve soon.

Thanks,
Joao

Re: [v5,net-next,2/9] net: stmmac: configure mtl rx and tx algorithms

[Joao Pinto]

Às 2:33 PM de 3/21/2017, Thierry Reding escreveu:
> On Tue, Mar 21, 2017 at 02:25:15PM +0000, Joao Pinto wrote:
>> Às 2:23 PM de 3/21/2017, Corentin Labbe escreveu:
>>> On Tue, Mar 21, 2017 at 02:10:47PM +, Joao Pinto wrote:
>>>> ++Adding Corentin
>>>>
>>>> Às 2:08 PM de 3/21/2017, Thierry Reding escreveu:
>>>>> On Tue, Mar 21, 2017 at 01:58:36PM +, Joao Pinto wrote:
>>>>>> Às 12:24 PM de 3/21/2017, Thierry Reding escreveu:
>>>>>>> On Tue, Mar 21, 2017 at 12:02:03PM +, Joao Pinto wrote:
>>>>>>>> Às 11:58 AM de 3/21/2017, Thierry Reding escreveu:
>>>>>>>>> On Fri, Mar 10, 2017 at 06:24:52PM +, Joao Pinto wrote:
>>>>>>>>>> This patch adds the RX and TX scheduling algorithms programming.
>>>>>>>>>> It introduces the multiple queues configuration function
>>>>>>>>>> (stmmac_mtl_configuration) in stmmac_main.
>>>>>>>>>>
>>>>>>>>>> Signed-off-by: Joao Pinto <jpi...@synopsys.com>
>>>>>>>>>> ---
>>>>>>>>>> Changes v4->v5:
>>>>>>>>>> - patch title update (stmicro replaced by stmmac)
>>>>>>>>>> Changes v3->v4:
>>>>>>>>>> - Just to keep up with patch-set version
>>>>>>>>>> Changes v2->v3:
>>>>>>>>>> - Switch statements with a tab
>>>>>>>>>> Changes v1->v2:
>>>>>>>>>> - Just to keep up with patch-set version
>>>>>>>>>>
>>>>>>>>>>  drivers/net/ethernet/stmicro/stmmac/common.h  |  4 ++
>>>>>>>>>>  drivers/net/ethernet/stmicro/stmmac/dwmac4.h  | 10 +
>>>>>>>>>>  drivers/net/ethernet/stmicro/stmmac/dwmac4_core.c | 48 
>>>>>>>>>> +++
>>>>>>>>>>  drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 31 
>>>>>>>>>> +--
>>>>>>>>>>  4 files changed, 90 insertions(+), 3 deletions(-)
>>>>>>>>>
>>>>>>>>> This patch breaks backwards-compatibility with DTBs that don't have an
>>>>>>>>> of the multiple queue properties.
>>>>>>>>>
>>>>>>>>> See below...
>>>>>>>>>
>>>>>>>>>> diff --git a/drivers/net/ethernet/stmicro/stmmac/common.h 
>>>>>>>>>> b/drivers/net/ethernet/stmicro/stmmac/common.h
>>>>>>>>>> index 04d9245..5a0a781 100644
>>>>>>>>>> --- a/drivers/net/ethernet/stmicro/stmmac/common.h
>>>>>>>>>> +++ b/drivers/net/ethernet/stmicro/stmmac/common.h
>>>>>>>>>> @@ -455,6 +455,10 @@ struct stmmac_ops {
>>>>>>>>>>  int (*rx_ipc)(struct mac_device_info *hw);
>>>>>>>>>>  /* Enable RX Queues */
>>>>>>>>>>  void (*rx_queue_enable)(struct mac_device_info *hw, u32 queue);
>>>>>>>>>> +/* Program RX Algorithms */
>>>>>>>>>> +void (*prog_mtl_rx_algorithms)(struct mac_device_info *hw, u32 
>>>>>>>>>> rx_alg);
>>>>>>>>>> +/* Program TX Algorithms */
>>>>>>>>>> +void (*prog_mtl_tx_algorithms)(struct mac_device_info *hw, u32 
>>>>>>>>>> tx_alg);
>>>>>>>>>>  /* Dump MAC registers */
>>>>>>>>>>  void (*dump_regs)(struct mac_device_info *hw, u32 *reg_space);
>>>>>>>>>>  /* Handle extra events on specific interrupts hw dependent */
>>>>>>>>>> diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac4.h 
>>>>>>>>>> b/drivers/net/ethernet/stmicro/stmmac/dwmac4.h
>>>>>>>>>> index db45134..748ab6f 100644
>>>>>>>>>> --- a/drivers/net/ethernet/stmicro/stmmac/dwmac4.h
>>>>>>>>>> +++ b/drivers/net/ethernet/stmicro/stmmac/dwmac4.h
>>>>>>>>>> @@ -161,6 +161,16 @@ enum power_event {
>>>>>>>>>>  #define GMAC_HI_REG_AE   

Re: [v5,net-next,2/9] net: stmmac: configure mtl rx and tx algorithms

[Joao Pinto]

Às 2:23 PM de 3/21/2017, Corentin Labbe escreveu:
> On Tue, Mar 21, 2017 at 02:10:47PM +0000, Joao Pinto wrote:
>> ++Adding Corentin
>>
>> Às 2:08 PM de 3/21/2017, Thierry Reding escreveu:
>>> On Tue, Mar 21, 2017 at 01:58:36PM +, Joao Pinto wrote:
>>>> Às 12:24 PM de 3/21/2017, Thierry Reding escreveu:
>>>>> On Tue, Mar 21, 2017 at 12:02:03PM +, Joao Pinto wrote:
>>>>>> Às 11:58 AM de 3/21/2017, Thierry Reding escreveu:
>>>>>>> On Fri, Mar 10, 2017 at 06:24:52PM +, Joao Pinto wrote:
>>>>>>>> This patch adds the RX and TX scheduling algorithms programming.
>>>>>>>> It introduces the multiple queues configuration function
>>>>>>>> (stmmac_mtl_configuration) in stmmac_main.
>>>>>>>>
>>>>>>>> Signed-off-by: Joao Pinto <jpi...@synopsys.com>
>>>>>>>> ---
>>>>>>>> Changes v4->v5:
>>>>>>>> - patch title update (stmicro replaced by stmmac)
>>>>>>>> Changes v3->v4:
>>>>>>>> - Just to keep up with patch-set version
>>>>>>>> Changes v2->v3:
>>>>>>>> - Switch statements with a tab
>>>>>>>> Changes v1->v2:
>>>>>>>> - Just to keep up with patch-set version
>>>>>>>>
>>>>>>>>  drivers/net/ethernet/stmicro/stmmac/common.h  |  4 ++
>>>>>>>>  drivers/net/ethernet/stmicro/stmmac/dwmac4.h  | 10 +
>>>>>>>>  drivers/net/ethernet/stmicro/stmmac/dwmac4_core.c | 48 
>>>>>>>> +++
>>>>>>>>  drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 31 +--
>>>>>>>>  4 files changed, 90 insertions(+), 3 deletions(-)
>>>>>>>
>>>>>>> This patch breaks backwards-compatibility with DTBs that don't have an
>>>>>>> of the multiple queue properties.
>>>>>>>
>>>>>>> See below...
>>>>>>>
>>>>>>>> diff --git a/drivers/net/ethernet/stmicro/stmmac/common.h 
>>>>>>>> b/drivers/net/ethernet/stmicro/stmmac/common.h
>>>>>>>> index 04d9245..5a0a781 100644
>>>>>>>> --- a/drivers/net/ethernet/stmicro/stmmac/common.h
>>>>>>>> +++ b/drivers/net/ethernet/stmicro/stmmac/common.h
>>>>>>>> @@ -455,6 +455,10 @@ struct stmmac_ops {
>>>>>>>>int (*rx_ipc)(struct mac_device_info *hw);
>>>>>>>>/* Enable RX Queues */
>>>>>>>>void (*rx_queue_enable)(struct mac_device_info *hw, u32 queue);
>>>>>>>> +  /* Program RX Algorithms */
>>>>>>>> +  void (*prog_mtl_rx_algorithms)(struct mac_device_info *hw, u32 
>>>>>>>> rx_alg);
>>>>>>>> +  /* Program TX Algorithms */
>>>>>>>> +  void (*prog_mtl_tx_algorithms)(struct mac_device_info *hw, u32 
>>>>>>>> tx_alg);
>>>>>>>>/* Dump MAC registers */
>>>>>>>>void (*dump_regs)(struct mac_device_info *hw, u32 *reg_space);
>>>>>>>>/* Handle extra events on specific interrupts hw dependent */
>>>>>>>> diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac4.h 
>>>>>>>> b/drivers/net/ethernet/stmicro/stmmac/dwmac4.h
>>>>>>>> index db45134..748ab6f 100644
>>>>>>>> --- a/drivers/net/ethernet/stmicro/stmmac/dwmac4.h
>>>>>>>> +++ b/drivers/net/ethernet/stmicro/stmmac/dwmac4.h
>>>>>>>> @@ -161,6 +161,16 @@ enum power_event {
>>>>>>>>  #define GMAC_HI_REG_AEBIT(31)
>>>>>>>>  
>>>>>>>>  /*  MTL registers */
>>>>>>>> +#define MTL_OPERATION_MODE0x0c00
>>>>>>>> +#define MTL_OPERATION_SCHALG_MASK GENMASK(6, 5)
>>>>>>>> +#define MTL_OPERATION_SCHALG_WRR  (0x0 << 5)
>>>>>>>> +#define MTL_OPERATION_SCHALG_WFQ  (0x1 << 5)
>>>>>>>> +#define MTL_OPERATION_SCHALG_DWRR (0x2 << 5)
>>>>>>>> +#define MTL_OPERATION_SCHALG_SP   (0x3 << 5)
>>

Re: [v5,net-next,2/9] net: stmmac: configure mtl rx and tx algorithms

[Joao Pinto]

Às 2:08 PM de 3/21/2017, Thierry Reding escreveu:
> On Tue, Mar 21, 2017 at 01:58:36PM +0000, Joao Pinto wrote:
>> Às 12:24 PM de 3/21/2017, Thierry Reding escreveu:
>>> On Tue, Mar 21, 2017 at 12:02:03PM +, Joao Pinto wrote:
>>>> Às 11:58 AM de 3/21/2017, Thierry Reding escreveu:
>>>>> On Fri, Mar 10, 2017 at 06:24:52PM +, Joao Pinto wrote:
>>>>>> This patch adds the RX and TX scheduling algorithms programming.
>>>>>> It introduces the multiple queues configuration function
>>>>>> (stmmac_mtl_configuration) in stmmac_main.
>>>>>>
>>>>>> Signed-off-by: Joao Pinto <jpi...@synopsys.com>
>>>>>> ---
>>>>>> Changes v4->v5:
>>>>>> - patch title update (stmicro replaced by stmmac)
>>>>>> Changes v3->v4:
>>>>>> - Just to keep up with patch-set version
>>>>>> Changes v2->v3:
>>>>>> - Switch statements with a tab
>>>>>> Changes v1->v2:
>>>>>> - Just to keep up with patch-set version
>>>>>>
>>>>>>  drivers/net/ethernet/stmicro/stmmac/common.h  |  4 ++
>>>>>>  drivers/net/ethernet/stmicro/stmmac/dwmac4.h  | 10 +
>>>>>>  drivers/net/ethernet/stmicro/stmmac/dwmac4_core.c | 48 
>>>>>> +++
>>>>>>  drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 31 +--
>>>>>>  4 files changed, 90 insertions(+), 3 deletions(-)
>>>>>
>>>>> This patch breaks backwards-compatibility with DTBs that don't have an
>>>>> of the multiple queue properties.
>>>>>
>>>>> See below...
>>>>>
>>>>>> diff --git a/drivers/net/ethernet/stmicro/stmmac/common.h 
>>>>>> b/drivers/net/ethernet/stmicro/stmmac/common.h
>>>>>> index 04d9245..5a0a781 100644
>>>>>> --- a/drivers/net/ethernet/stmicro/stmmac/common.h
>>>>>> +++ b/drivers/net/ethernet/stmicro/stmmac/common.h
>>>>>> @@ -455,6 +455,10 @@ struct stmmac_ops {
>>>>>>  int (*rx_ipc)(struct mac_device_info *hw);
>>>>>>  /* Enable RX Queues */
>>>>>>  void (*rx_queue_enable)(struct mac_device_info *hw, u32 queue);
>>>>>> +/* Program RX Algorithms */
>>>>>> +void (*prog_mtl_rx_algorithms)(struct mac_device_info *hw, u32 
>>>>>> rx_alg);
>>>>>> +/* Program TX Algorithms */
>>>>>> +void (*prog_mtl_tx_algorithms)(struct mac_device_info *hw, u32 
>>>>>> tx_alg);
>>>>>>  /* Dump MAC registers */
>>>>>>  void (*dump_regs)(struct mac_device_info *hw, u32 *reg_space);
>>>>>>  /* Handle extra events on specific interrupts hw dependent */
>>>>>> diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac4.h 
>>>>>> b/drivers/net/ethernet/stmicro/stmmac/dwmac4.h
>>>>>> index db45134..748ab6f 100644
>>>>>> --- a/drivers/net/ethernet/stmicro/stmmac/dwmac4.h
>>>>>> +++ b/drivers/net/ethernet/stmicro/stmmac/dwmac4.h
>>>>>> @@ -161,6 +161,16 @@ enum power_event {
>>>>>>  #define GMAC_HI_REG_AE  BIT(31)
>>>>>>  
>>>>>>  /*  MTL registers */
>>>>>> +#define MTL_OPERATION_MODE  0x0c00
>>>>>> +#define MTL_OPERATION_SCHALG_MASK   GENMASK(6, 5)
>>>>>> +#define MTL_OPERATION_SCHALG_WRR(0x0 << 5)
>>>>>> +#define MTL_OPERATION_SCHALG_WFQ(0x1 << 5)
>>>>>> +#define MTL_OPERATION_SCHALG_DWRR   (0x2 << 5)
>>>>>> +#define MTL_OPERATION_SCHALG_SP (0x3 << 5)
>>>>>> +#define MTL_OPERATION_RAA   BIT(2)
>>>>>> +#define MTL_OPERATION_RAA_SP(0x0 << 2)
>>>>>> +#define MTL_OPERATION_RAA_WSP   (0x1 << 2)
>>>>>> +
>>>>>>  #define MTL_INT_STATUS  0x0c20
>>>>>>  #define MTL_INT_Q0  BIT(0)
>>>>>>  
>>>>>> diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac4_core.c 
>>>>>> b/drivers/net/ethernet/stmicro/stmmac/dwmac4_core.c
>>>>>> index 1e79e65..f966755 100644

Re: [v5,net-next,2/9] net: stmmac: configure mtl rx and tx algorithms

[Joao Pinto]

++Adding Corentin

Às 2:08 PM de 3/21/2017, Thierry Reding escreveu:
> On Tue, Mar 21, 2017 at 01:58:36PM +0000, Joao Pinto wrote:
>> Às 12:24 PM de 3/21/2017, Thierry Reding escreveu:
>>> On Tue, Mar 21, 2017 at 12:02:03PM +, Joao Pinto wrote:
>>>> Às 11:58 AM de 3/21/2017, Thierry Reding escreveu:
>>>>> On Fri, Mar 10, 2017 at 06:24:52PM +, Joao Pinto wrote:
>>>>>> This patch adds the RX and TX scheduling algorithms programming.
>>>>>> It introduces the multiple queues configuration function
>>>>>> (stmmac_mtl_configuration) in stmmac_main.
>>>>>>
>>>>>> Signed-off-by: Joao Pinto <jpi...@synopsys.com>
>>>>>> ---
>>>>>> Changes v4->v5:
>>>>>> - patch title update (stmicro replaced by stmmac)
>>>>>> Changes v3->v4:
>>>>>> - Just to keep up with patch-set version
>>>>>> Changes v2->v3:
>>>>>> - Switch statements with a tab
>>>>>> Changes v1->v2:
>>>>>> - Just to keep up with patch-set version
>>>>>>
>>>>>>  drivers/net/ethernet/stmicro/stmmac/common.h  |  4 ++
>>>>>>  drivers/net/ethernet/stmicro/stmmac/dwmac4.h  | 10 +
>>>>>>  drivers/net/ethernet/stmicro/stmmac/dwmac4_core.c | 48 
>>>>>> +++
>>>>>>  drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 31 +--
>>>>>>  4 files changed, 90 insertions(+), 3 deletions(-)
>>>>>
>>>>> This patch breaks backwards-compatibility with DTBs that don't have an
>>>>> of the multiple queue properties.
>>>>>
>>>>> See below...
>>>>>
>>>>>> diff --git a/drivers/net/ethernet/stmicro/stmmac/common.h 
>>>>>> b/drivers/net/ethernet/stmicro/stmmac/common.h
>>>>>> index 04d9245..5a0a781 100644
>>>>>> --- a/drivers/net/ethernet/stmicro/stmmac/common.h
>>>>>> +++ b/drivers/net/ethernet/stmicro/stmmac/common.h
>>>>>> @@ -455,6 +455,10 @@ struct stmmac_ops {
>>>>>>  int (*rx_ipc)(struct mac_device_info *hw);
>>>>>>  /* Enable RX Queues */
>>>>>>  void (*rx_queue_enable)(struct mac_device_info *hw, u32 queue);
>>>>>> +/* Program RX Algorithms */
>>>>>> +void (*prog_mtl_rx_algorithms)(struct mac_device_info *hw, u32 
>>>>>> rx_alg);
>>>>>> +/* Program TX Algorithms */
>>>>>> +void (*prog_mtl_tx_algorithms)(struct mac_device_info *hw, u32 
>>>>>> tx_alg);
>>>>>>  /* Dump MAC registers */
>>>>>>  void (*dump_regs)(struct mac_device_info *hw, u32 *reg_space);
>>>>>>  /* Handle extra events on specific interrupts hw dependent */
>>>>>> diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac4.h 
>>>>>> b/drivers/net/ethernet/stmicro/stmmac/dwmac4.h
>>>>>> index db45134..748ab6f 100644
>>>>>> --- a/drivers/net/ethernet/stmicro/stmmac/dwmac4.h
>>>>>> +++ b/drivers/net/ethernet/stmicro/stmmac/dwmac4.h
>>>>>> @@ -161,6 +161,16 @@ enum power_event {
>>>>>>  #define GMAC_HI_REG_AE  BIT(31)
>>>>>>  
>>>>>>  /*  MTL registers */
>>>>>> +#define MTL_OPERATION_MODE  0x0c00
>>>>>> +#define MTL_OPERATION_SCHALG_MASK   GENMASK(6, 5)
>>>>>> +#define MTL_OPERATION_SCHALG_WRR(0x0 << 5)
>>>>>> +#define MTL_OPERATION_SCHALG_WFQ(0x1 << 5)
>>>>>> +#define MTL_OPERATION_SCHALG_DWRR   (0x2 << 5)
>>>>>> +#define MTL_OPERATION_SCHALG_SP (0x3 << 5)
>>>>>> +#define MTL_OPERATION_RAA   BIT(2)
>>>>>> +#define MTL_OPERATION_RAA_SP(0x0 << 2)
>>>>>> +#define MTL_OPERATION_RAA_WSP   (0x1 << 2)
>>>>>> +
>>>>>>  #define MTL_INT_STATUS  0x0c20
>>>>>>  #define MTL_INT_Q0  BIT(0)
>>>>>>  
>>>>>> diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac4_core.c 
>>>>>> b/drivers/net/ethernet/stmicro/stmmac/dwmac4_core.c
>>>>>> index 1e

Re: [v5,net-next,2/9] net: stmmac: configure mtl rx and tx algorithms

[Joao Pinto]

Às 12:24 PM de 3/21/2017, Thierry Reding escreveu:
> On Tue, Mar 21, 2017 at 12:02:03PM +0000, Joao Pinto wrote:
>> Às 11:58 AM de 3/21/2017, Thierry Reding escreveu:
>>> On Fri, Mar 10, 2017 at 06:24:52PM +, Joao Pinto wrote:
>>>> This patch adds the RX and TX scheduling algorithms programming.
>>>> It introduces the multiple queues configuration function
>>>> (stmmac_mtl_configuration) in stmmac_main.
>>>>
>>>> Signed-off-by: Joao Pinto <jpi...@synopsys.com>
>>>> ---
>>>> Changes v4->v5:
>>>> - patch title update (stmicro replaced by stmmac)
>>>> Changes v3->v4:
>>>> - Just to keep up with patch-set version
>>>> Changes v2->v3:
>>>> - Switch statements with a tab
>>>> Changes v1->v2:
>>>> - Just to keep up with patch-set version
>>>>
>>>>  drivers/net/ethernet/stmicro/stmmac/common.h  |  4 ++
>>>>  drivers/net/ethernet/stmicro/stmmac/dwmac4.h  | 10 +
>>>>  drivers/net/ethernet/stmicro/stmmac/dwmac4_core.c | 48 
>>>> +++
>>>>  drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 31 +--
>>>>  4 files changed, 90 insertions(+), 3 deletions(-)
>>>
>>> This patch breaks backwards-compatibility with DTBs that don't have an
>>> of the multiple queue properties.
>>>
>>> See below...
>>>
>>>> diff --git a/drivers/net/ethernet/stmicro/stmmac/common.h 
>>>> b/drivers/net/ethernet/stmicro/stmmac/common.h
>>>> index 04d9245..5a0a781 100644
>>>> --- a/drivers/net/ethernet/stmicro/stmmac/common.h
>>>> +++ b/drivers/net/ethernet/stmicro/stmmac/common.h
>>>> @@ -455,6 +455,10 @@ struct stmmac_ops {
>>>>int (*rx_ipc)(struct mac_device_info *hw);
>>>>/* Enable RX Queues */
>>>>void (*rx_queue_enable)(struct mac_device_info *hw, u32 queue);
>>>> +  /* Program RX Algorithms */
>>>> +  void (*prog_mtl_rx_algorithms)(struct mac_device_info *hw, u32 rx_alg);
>>>> +  /* Program TX Algorithms */
>>>> +  void (*prog_mtl_tx_algorithms)(struct mac_device_info *hw, u32 tx_alg);
>>>>/* Dump MAC registers */
>>>>void (*dump_regs)(struct mac_device_info *hw, u32 *reg_space);
>>>>/* Handle extra events on specific interrupts hw dependent */
>>>> diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac4.h 
>>>> b/drivers/net/ethernet/stmicro/stmmac/dwmac4.h
>>>> index db45134..748ab6f 100644
>>>> --- a/drivers/net/ethernet/stmicro/stmmac/dwmac4.h
>>>> +++ b/drivers/net/ethernet/stmicro/stmmac/dwmac4.h
>>>> @@ -161,6 +161,16 @@ enum power_event {
>>>>  #define GMAC_HI_REG_AEBIT(31)
>>>>  
>>>>  /*  MTL registers */
>>>> +#define MTL_OPERATION_MODE0x0c00
>>>> +#define MTL_OPERATION_SCHALG_MASK GENMASK(6, 5)
>>>> +#define MTL_OPERATION_SCHALG_WRR  (0x0 << 5)
>>>> +#define MTL_OPERATION_SCHALG_WFQ  (0x1 << 5)
>>>> +#define MTL_OPERATION_SCHALG_DWRR (0x2 << 5)
>>>> +#define MTL_OPERATION_SCHALG_SP   (0x3 << 5)
>>>> +#define MTL_OPERATION_RAA BIT(2)
>>>> +#define MTL_OPERATION_RAA_SP  (0x0 << 2)
>>>> +#define MTL_OPERATION_RAA_WSP (0x1 << 2)
>>>> +
>>>>  #define MTL_INT_STATUS0x0c20
>>>>  #define MTL_INT_Q0BIT(0)
>>>>  
>>>> diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac4_core.c 
>>>> b/drivers/net/ethernet/stmicro/stmmac/dwmac4_core.c
>>>> index 1e79e65..f966755 100644
>>>> --- a/drivers/net/ethernet/stmicro/stmmac/dwmac4_core.c
>>>> +++ b/drivers/net/ethernet/stmicro/stmmac/dwmac4_core.c
>>>> @@ -70,6 +70,52 @@ static void dwmac4_rx_queue_enable(struct 
>>>> mac_device_info *hw, u32 queue)
>>>>writel(value, ioaddr + GMAC_RXQ_CTRL0);
>>>>  }
>>>>  
>>>> +static void dwmac4_prog_mtl_rx_algorithms(struct mac_device_info *hw,
>>>> +u32 rx_alg)
>>>> +{
>>>> +  void __iomem *ioaddr = hw->pcsr;
>>>> +  u32 value = readl(ioaddr + MTL_OPERATION_MODE);
>>>> +
>>>> +  value &= ~MTL_OPERATION_RAA;
>>>> +  switch (rx_alg) {
>>>> +  case MTL_RX_ALGORITHM

Re: [v5,net-next,2/9] net: stmmac: configure mtl rx and tx algorithms

[Joao Pinto]

Às 11:58 AM de 3/21/2017, Thierry Reding escreveu:
> On Fri, Mar 10, 2017 at 06:24:52PM +0000, Joao Pinto wrote:
>> This patch adds the RX and TX scheduling algorithms programming.
>> It introduces the multiple queues configuration function
>> (stmmac_mtl_configuration) in stmmac_main.
>>
>> Signed-off-by: Joao Pinto <jpi...@synopsys.com>
>> ---
>> Changes v4->v5:
>> - patch title update (stmicro replaced by stmmac)
>> Changes v3->v4:
>> - Just to keep up with patch-set version
>> Changes v2->v3:
>> - Switch statements with a tab
>> Changes v1->v2:
>> - Just to keep up with patch-set version
>>
>>  drivers/net/ethernet/stmicro/stmmac/common.h  |  4 ++
>>  drivers/net/ethernet/stmicro/stmmac/dwmac4.h  | 10 +
>>  drivers/net/ethernet/stmicro/stmmac/dwmac4_core.c | 48 
>> +++
>>  drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 31 +--
>>  4 files changed, 90 insertions(+), 3 deletions(-)
> 
> This patch breaks backwards-compatibility with DTBs that don't have an
> of the multiple queue properties.
> 
> See below...
> 
>> diff --git a/drivers/net/ethernet/stmicro/stmmac/common.h 
>> b/drivers/net/ethernet/stmicro/stmmac/common.h
>> index 04d9245..5a0a781 100644
>> --- a/drivers/net/ethernet/stmicro/stmmac/common.h
>> +++ b/drivers/net/ethernet/stmicro/stmmac/common.h
>> @@ -455,6 +455,10 @@ struct stmmac_ops {
>>  int (*rx_ipc)(struct mac_device_info *hw);
>>  /* Enable RX Queues */
>>  void (*rx_queue_enable)(struct mac_device_info *hw, u32 queue);
>> +/* Program RX Algorithms */
>> +void (*prog_mtl_rx_algorithms)(struct mac_device_info *hw, u32 rx_alg);
>> +/* Program TX Algorithms */
>> +void (*prog_mtl_tx_algorithms)(struct mac_device_info *hw, u32 tx_alg);
>>  /* Dump MAC registers */
>>  void (*dump_regs)(struct mac_device_info *hw, u32 *reg_space);
>>  /* Handle extra events on specific interrupts hw dependent */
>> diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac4.h 
>> b/drivers/net/ethernet/stmicro/stmmac/dwmac4.h
>> index db45134..748ab6f 100644
>> --- a/drivers/net/ethernet/stmicro/stmmac/dwmac4.h
>> +++ b/drivers/net/ethernet/stmicro/stmmac/dwmac4.h
>> @@ -161,6 +161,16 @@ enum power_event {
>>  #define GMAC_HI_REG_AE  BIT(31)
>>  
>>  /*  MTL registers */
>> +#define MTL_OPERATION_MODE  0x0c00
>> +#define MTL_OPERATION_SCHALG_MASK   GENMASK(6, 5)
>> +#define MTL_OPERATION_SCHALG_WRR(0x0 << 5)
>> +#define MTL_OPERATION_SCHALG_WFQ(0x1 << 5)
>> +#define MTL_OPERATION_SCHALG_DWRR   (0x2 << 5)
>> +#define MTL_OPERATION_SCHALG_SP (0x3 << 5)
>> +#define MTL_OPERATION_RAA   BIT(2)
>> +#define MTL_OPERATION_RAA_SP(0x0 << 2)
>> +#define MTL_OPERATION_RAA_WSP   (0x1 << 2)
>> +
>>  #define MTL_INT_STATUS  0x0c20
>>  #define MTL_INT_Q0  BIT(0)
>>  
>> diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac4_core.c 
>> b/drivers/net/ethernet/stmicro/stmmac/dwmac4_core.c
>> index 1e79e65..f966755 100644
>> --- a/drivers/net/ethernet/stmicro/stmmac/dwmac4_core.c
>> +++ b/drivers/net/ethernet/stmicro/stmmac/dwmac4_core.c
>> @@ -70,6 +70,52 @@ static void dwmac4_rx_queue_enable(struct mac_device_info 
>> *hw, u32 queue)
>>  writel(value, ioaddr + GMAC_RXQ_CTRL0);
>>  }
>>  
>> +static void dwmac4_prog_mtl_rx_algorithms(struct mac_device_info *hw,
>> +  u32 rx_alg)
>> +{
>> +void __iomem *ioaddr = hw->pcsr;
>> +u32 value = readl(ioaddr + MTL_OPERATION_MODE);
>> +
>> +value &= ~MTL_OPERATION_RAA;
>> +switch (rx_alg) {
>> +case MTL_RX_ALGORITHM_SP:
>> +value |= MTL_OPERATION_RAA_SP;
>> +break;
>> +case MTL_RX_ALGORITHM_WSP:
>> +value |= MTL_OPERATION_RAA_WSP;
>> +break;
>> +default:
>> +break;
>> +}
>> +
>> +writel(value, ioaddr + MTL_OPERATION_MODE);
>> +}
>> +
>> +static void dwmac4_prog_mtl_tx_algorithms(struct mac_device_info *hw,
>> +  u32 tx_alg)
>> +{
>> +void __iomem *ioaddr = hw->pcsr;
>> +u32 value = readl(ioaddr + MTL_OPERATION_MODE);
>> +
>> +value &= ~MTL_OPERATION_SCHALG_MASK;
>> +switch (tx_alg) {
>> +case MTL_TX_ALGOR

Re: [v5,net-next,1/9] net: stmmac: multiple queues dt configuration

[Joao Pinto]

Hi Thierry,

Às 11:32 AM de 3/21/2017, Thierry Reding escreveu:
> On Fri, Mar 10, 2017 at 06:24:51PM +0000, Joao Pinto wrote:
>> This patch adds the multiple queues configuration in the Device Tree.
>> It was also created a set of structures to keep the RX and TX queues
>> configurations to be used in the driver.
>>
>> Signed-off-by: Joao Pinto <jpi...@synopsys.com>
>> ---
>> Changes v4->v5:
>> - patch title update (stmicro replaced by stmmac)
>> Changes v2->v4:
>> - Just to keep up with patch-set version
>> Changes v1->v2:
>> - RX and TX queues child nodes had bad handle
>>
>>  Documentation/devicetree/bindings/net/stmmac.txt   | 40 ++
>>  .../net/ethernet/stmicro/stmmac/stmmac_platform.c  | 91 
>> ++
>>  include/linux/stmmac.h | 30 +++
>>  3 files changed, 161 insertions(+)
>>
>> diff --git a/Documentation/devicetree/bindings/net/stmmac.txt 
>> b/Documentation/devicetree/bindings/net/stmmac.txt
>> index d3bfc2b..4107e67 100644
>> --- a/Documentation/devicetree/bindings/net/stmmac.txt
>> +++ b/Documentation/devicetree/bindings/net/stmmac.txt
>> @@ -72,6 +72,27 @@ Optional properties:
>>  - snps,mb: mixed-burst
>>  - snps,rb: rebuild INCRx Burst
>>  - mdio: with compatible = "snps,dwmac-mdio", create and register mdio bus.
>> +- Multiple RX Queues parameters: below the list of all the parameters to
>> + configure the multiple RX queues:
>> +- snps,rx-queues-to-use: number of RX queues to be used in the driver
>> +- Choose one of these RX scheduling algorithms:
>> +- snps,rx-sched-sp: Strict priority
>> +- snps,rx-sched-wsp: Weighted Strict priority
>> +- For each RX queue
>> +- Choose one of these modes:
>> +- snps,dcb-algorithm: Queue to be enabled as DCB
>> +- snps,avb-algorithm: Queue to be enabled as AVB
>> +- snps,map-to-dma-channel: Channel to map
>> +- Multiple TX Queues parameters: below the list of all the parameters to
>> + configure the multiple TX queues:
>> +- snps,tx-queues-to-use: number of TX queues to be used in the driver
>> +- Choose one of these TX scheduling algorithms:
>> +- snps,tx-sched-wrr: Weighted Round Robin
>> +- snps,tx-sched-wfq: Weighted Fair Queuing
>> +- snps,tx-sched-dwrr: Deficit Weighted Round Robin
>> +- snps,tx-sched-sp: Strict priority
>> +- For each TX queue
>> +- snps,weight: TX queue weight (if using a weighted algorithm)
>>  
>>  Examples:
>>  
>> @@ -81,6 +102,23 @@ Examples:
>>  snps,blen = <256 128 64 32 0 0 0>;
>>  };
>>  
>> +mtl_rx_setup: rx-queues-config {
>> +snps,rx-queues-to-use = <1>;
>> +snps,rx-sched-sp;
>> +queue0 {
>> +snps,dcb-algorithm;
>> +snps,map-to-dma-channel = <0x0>;
>> +};
>> +};
>> +
>> +mtl_tx_setup: tx-queues-config {
>> +snps,tx-queues-to-use = <1>;
>> +snps,tx-sched-wrr;
>> +queue0 {
>> +snps,weight = <0x10>;
>> +};
>> +};
>> +
>>  gmac0: ethernet@e080 {
>>  compatible = "st,spear600-gmac";
>>  reg = <0xe080 0x8000>;
>> @@ -104,4 +142,6 @@ Examples:
>>  phy1: ethernet-phy@0 {
>>  };
>>  };
>> +snps,mtl-rx-config = <_rx_setup>;
>> +snps,mtl-tx-config = <_tx_setup>;
>>  };
> 
> That's kind of an odd placement for these nodes. Wouldn't they be better
> located within the controller's device tree node, rather than referenced
> by phandle? Making them children of the root node leaves them completely
> without context.
> 
> Thierry
> 

I followed the same approach as "stmmac_axi_setup":
https://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next.git/tree/Documentation/devicetree/bindings/net/stmmac.txt

I personally find it cleaner and easier to read.

Thanks,
Joao

Re: linux-next-20170320 breaks stmmac on meson (Amlogic S905GXBB)

[Joao Pinto]

Hi Heiner and Corentin,

Às 9:58 PM de 3/20/2017, Heiner Kallweit escreveu:
> As reported by Corentin Labbe before:
> stmmac in the latest next kernel is broken also on meson8b.
> 
> The following commit seems to create the trouble:
> 6deee2221e11 "net: stmmac: prepare dma op mode config for multiple queues"
> 
> I also get queue timeout errors.

>From what you are describing it seems that the tx op mode is not being
configured by some reason and so it is not enabled.

Please check if this path is being executed:

stmmac_mtl_configuration >> stmmac_dma_operation_mode >> 
priv->hw->dma->dma_tx_mode

It must iterate by all the available channels / queues, that should be =1 since
I assume you have a single queue:

if (priv->synopsys_id >= DWMAC_CORE_4_00) {
for (chan = 0; chan < rx_channels_count; chan++)
priv->hw->dma->dma_rx_mode(priv->ioaddr, rxmode, chan,
   rxfifosz);

for (chan = 0; chan < tx_channels_count; chan++)
priv->hw->dma->dma_tx_mode(priv->ioaddr, txmode, chan);

Could you please check if RX and TX op mode are being programmed?

The rx and tx queue counters are initialized in stmmac_mtl_setup() function
(stmmac_platform.c). If they are not declared in DT they assume the default
value of 1.

> 
> Rgds, Heiner
> 

Thanks.

Re: [PATCH net-next] stmmac: call stmmac_init_phy from stmmac_dvr_probe

[Joao Pinto]

Às 5:44 PM de 3/20/2017, Niklas Cassel escreveu:
> On 03/20/2017 06:42 PM, Joao Pinto wrote:
>> Às 5:29 PM de 3/20/2017, Niklas Cassel escreveu:
>>> From: Niklas Cassel <niklas.cas...@axis.com>
>>>
>>> It is usually possible to do
>>> ethtool -s autoneg on
>>> so that you trigger an autoneg before calling
>>> ip link set dev eth0 up
>>>
>>> However, stmmac returns -EBUSY if !netif_running.
>>> The only reason for this appears to be that stmmac_init_phy
>>> is called from stmmac_open instead of from stmmac_dvr_probe.
>>>
>>> Move stmmac_init_phy to stmmac_dvr_probe so that ethool
>>> works as soon as register_netdev has been called.
>>> stmmac_check_ether_addr was also moved to probe,
>>> so that the ordering doesn't change.
>>>
>>> Signed-off-by: Niklas Cassel <niklas.cas...@axis.com>
>>> ---
>> Hi Niklas, did you test this patch?
> 
> I tested it on our hardware, but it would be nice
> if you could test it on your side, since you are
> using the PCI glue layer.
> 

Ok, I can do that. As Florian stated in a past e-mail, this change might not be
compatible with all setups.

Joao