All of lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH] [net-next] stmmac: use netif_set_real_num_{rx,tx}_queues
@ 2017-03-28  9:48 Arnd Bergmann
  2017-03-29  1:01 ` David Miller
  0 siblings, 1 reply; 14+ messages in thread
From: Arnd Bergmann @ 2017-03-28  9:48 UTC (permalink / raw)
  To: Giuseppe Cavallaro, Alexandre Torgue
  Cc: Arnd Bergmann, David S. Miller, Joao Pinto, LABBE Corentin,
	Thierry Reding, netdev, linux-kernel

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 <arnd@arndb.de>
---
 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 c78f444ad423..fe1d9592956f 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
@@ -4080,8 +4080,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);
 
 	priv->dma_buf_sz = STMMAC_ALIGN(buf_sz);
 
-- 
2.9.0

^ permalink raw reply related	[flat|nested] 14+ messages in thread

* Re: [PATCH] [net-next] stmmac: use netif_set_real_num_{rx,tx}_queues
  2017-03-28  9:48 [PATCH] [net-next] stmmac: use netif_set_real_num_{rx,tx}_queues Arnd Bergmann
@ 2017-03-29  1:01 ` David Miller
  2017-03-30  7:45   ` Corentin Labbe
  0 siblings, 1 reply; 14+ messages in thread
From: David Miller @ 2017-03-29  1:01 UTC (permalink / raw)
  To: arnd
  Cc: peppe.cavallaro, alexandre.torgue, Joao.Pinto, clabbe.montjoie,
	treding, netdev, linux-kernel

From: Arnd Bergmann <arnd@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 <arnd@arndb.de>

Applied.

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: [PATCH] [net-next] stmmac: use netif_set_real_num_{rx,tx}_queues
  2017-03-29  1:01 ` David Miller
@ 2017-03-30  7:45   ` Corentin Labbe
  2017-03-30 14:34     ` Thierry Reding
  0 siblings, 1 reply; 14+ messages in thread
From: Corentin Labbe @ 2017-03-30  7:45 UTC (permalink / raw)
  To: David Miller
  Cc: arnd, peppe.cavallaro, alexandre.torgue, Joao.Pinto, treding,
	netdev, linux-kernel

On Tue, Mar 28, 2017 at 06:01:05PM -0700, David Miller wrote:
> From: Arnd Bergmann <arnd@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 <arnd@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.

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: [PATCH] [net-next] stmmac: use netif_set_real_num_{rx,tx}_queues
  2017-03-30  7:45   ` Corentin Labbe
@ 2017-03-30 14:34     ` Thierry Reding
  2017-03-30 16:35       ` Niklas Cassel
  2017-03-30 17:48       ` David Miller
  0 siblings, 2 replies; 14+ messages in thread
From: Thierry Reding @ 2017-03-30 14:34 UTC (permalink / raw)
  To: Corentin Labbe
  Cc: David Miller, arnd, peppe.cavallaro, alexandre.torgue,
	Joao.Pinto, netdev, linux-kernel

[-- Attachment #1: Type: text/plain, Size: 1364 bytes --]

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 <arnd@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 <arnd@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.

You can find the patch here:

	https://patchwork.ozlabs.org/patch/744286/

Thierry

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: Re: [PATCH] [net-next] stmmac: use netif_set_real_num_{rx,tx}_queues
  2017-03-30 14:34     ` Thierry Reding
@ 2017-03-30 16:35       ` Niklas Cassel
  2017-03-30 16:42         ` Joao Pinto
  2017-03-30 17:48       ` David Miller
  1 sibling, 1 reply; 14+ messages in thread
From: Niklas Cassel @ 2017-03-30 16:35 UTC (permalink / raw)
  To: Thierry Reding, Corentin Labbe
  Cc: David Miller, arnd, peppe.cavallaro, alexandre.torgue,
	Joao.Pinto, netdev, linux-kernel

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 <arnd@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 <arnd@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? :)

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: [PATCH] [net-next] stmmac: use netif_set_real_num_{rx,tx}_queues
  2017-03-30 16:35       ` Niklas Cassel
@ 2017-03-30 16:42         ` Joao Pinto
  2017-04-03 13:07           ` Giuseppe CAVALLARO
  0 siblings, 1 reply; 14+ messages in thread
From: Joao Pinto @ 2017-03-30 16:42 UTC (permalink / raw)
  To: Niklas Cassel, Thierry Reding, Corentin Labbe
  Cc: David Miller, arnd, peppe.cavallaro, alexandre.torgue,
	Joao.Pinto, netdev, linux-kernel

À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 <arnd@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 <arnd@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.

Thanks.

Joao

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: [PATCH] [net-next] stmmac: use netif_set_real_num_{rx,tx}_queues
  2017-03-30 14:34     ` Thierry Reding
  2017-03-30 16:35       ` Niklas Cassel
@ 2017-03-30 17:48       ` David Miller
  2017-03-31 10:14         ` Joao Pinto
  1 sibling, 1 reply; 14+ messages in thread
From: David Miller @ 2017-03-30 17:48 UTC (permalink / raw)
  To: treding
  Cc: clabbe.montjoie, arnd, peppe.cavallaro, alexandre.torgue,
	Joao.Pinto, netdev, linux-kernel

From: Thierry Reding <treding@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 <arnd@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 <arnd@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&m=149076922813085&w=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.

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: [PATCH] [net-next] stmmac: use netif_set_real_num_{rx,tx}_queues
  2017-03-30 17:48       ` David Miller
@ 2017-03-31 10:14         ` Joao Pinto
  2017-03-31 10:43           ` Joao Pinto
  0 siblings, 1 reply; 14+ messages in thread
From: Joao Pinto @ 2017-03-31 10:14 UTC (permalink / raw)
  To: David Miller, clabbe.montjoie
  Cc: treding, arnd, peppe.cavallaro, alexandre.torgue, Joao.Pinto,
	netdev, linux-kernel

Às 6:48 PM de 3/30/2017, David Miller escreveu:
> From: Thierry Reding <treding@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 <arnd@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 <arnd@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&m=149076922813085&w=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

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: [PATCH] [net-next] stmmac: use netif_set_real_num_{rx,tx}_queues
  2017-03-31 10:14         ` Joao Pinto
@ 2017-03-31 10:43           ` Joao Pinto
  2017-03-31 16:57             ` David Miller
  0 siblings, 1 reply; 14+ messages in thread
From: Joao Pinto @ 2017-03-31 10:43 UTC (permalink / raw)
  To: David Miller
  Cc: clabbe.montjoie, treding, arnd, peppe.cavallaro,
	alexandre.torgue, Joao.Pinto, netdev, linux-kernel

À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 <treding@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 <arnd@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 <arnd@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&m=149076922813085&w=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
> 

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: [PATCH] [net-next] stmmac: use netif_set_real_num_{rx,tx}_queues
  2017-03-31 10:43           ` Joao Pinto
@ 2017-03-31 16:57             ` David Miller
  2017-03-31 16:58               ` Joao Pinto
  0 siblings, 1 reply; 14+ messages in thread
From: David Miller @ 2017-03-31 16:57 UTC (permalink / raw)
  To: Joao.Pinto
  Cc: clabbe.montjoie, treding, arnd, peppe.cavallaro,
	alexandre.torgue, netdev, linux-kernel

From: Joao Pinto <Joao.Pinto@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.

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: [PATCH] [net-next] stmmac: use netif_set_real_num_{rx,tx}_queues
  2017-03-31 16:57             ` David Miller
@ 2017-03-31 16:58               ` Joao Pinto
  0 siblings, 0 replies; 14+ messages in thread
From: Joao Pinto @ 2017-03-31 16:58 UTC (permalink / raw)
  To: David Miller, Joao.Pinto
  Cc: clabbe.montjoie, treding, arnd, peppe.cavallaro,
	alexandre.torgue, netdev, linux-kernel

Às 5:57 PM de 3/31/2017, David Miller escreveu:
> From: Joao Pinto <Joao.Pinto@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.

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: [PATCH] [net-next] stmmac: use netif_set_real_num_{rx,tx}_queues
  2017-03-30 16:42         ` Joao Pinto
@ 2017-04-03 13:07           ` Giuseppe CAVALLARO
  2017-04-03 13:12             ` Joao Pinto
  0 siblings, 1 reply; 14+ messages in thread
From: Giuseppe CAVALLARO @ 2017-04-03 13:07 UTC (permalink / raw)
  To: Joao Pinto, Niklas Cassel, Thierry Reding, Corentin Labbe
  Cc: David Miller, arnd, alexandre.torgue, netdev, linux-kernel

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 <arnd@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 <arnd@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.

Regards
Peppe

>
> Thanks.
>
> Joao
>
>

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: [PATCH] [net-next] stmmac: use netif_set_real_num_{rx,tx}_queues
  2017-04-03 13:07           ` Giuseppe CAVALLARO
@ 2017-04-03 13:12             ` Joao Pinto
  2017-04-04  6:15               ` Giuseppe CAVALLARO
  0 siblings, 1 reply; 14+ messages in thread
From: Joao Pinto @ 2017-04-03 13:12 UTC (permalink / raw)
  To: Giuseppe CAVALLARO, Joao Pinto, Niklas Cassel, Thierry Reding,
	Corentin Labbe
  Cc: David Miller, arnd, alexandre.torgue, netdev, linux-kernel


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 <arnd@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 <arnd@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
>>
>>
> 

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: [PATCH] [net-next] stmmac: use netif_set_real_num_{rx,tx}_queues
  2017-04-03 13:12             ` Joao Pinto
@ 2017-04-04  6:15               ` Giuseppe CAVALLARO
  0 siblings, 0 replies; 14+ messages in thread
From: Giuseppe CAVALLARO @ 2017-04-04  6:15 UTC (permalink / raw)
  To: Joao Pinto, Niklas Cassel, Thierry Reding, Corentin Labbe
  Cc: David Miller, arnd, alexandre.torgue, netdev, linux-kernel

Hello Joao

On 4/3/2017 3:12 PM, Joao Pinto wrote:
> Yes older cores do not support multiple queues and I tried to isolate the
> features not to affect older versions.

ok so we are inline ;-)

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

I do not think so is we are passing the right txqs and rxqs values.

Regards
Peppe

>
> Thanks.

^ permalink raw reply	[flat|nested] 14+ messages in thread

end of thread, other threads:[~2017-04-04  6:16 UTC | newest]

Thread overview: 14+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2017-03-28  9:48 [PATCH] [net-next] stmmac: use netif_set_real_num_{rx,tx}_queues Arnd Bergmann
2017-03-29  1:01 ` David Miller
2017-03-30  7:45   ` Corentin Labbe
2017-03-30 14:34     ` Thierry Reding
2017-03-30 16:35       ` Niklas Cassel
2017-03-30 16:42         ` Joao Pinto
2017-04-03 13:07           ` Giuseppe CAVALLARO
2017-04-03 13:12             ` Joao Pinto
2017-04-04  6:15               ` Giuseppe CAVALLARO
2017-03-30 17:48       ` David Miller
2017-03-31 10:14         ` Joao Pinto
2017-03-31 10:43           ` Joao Pinto
2017-03-31 16:57             ` David Miller
2017-03-31 16:58               ` Joao Pinto

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.