net: mvpp2: adapt rxq distribution to PPv2.2
authorThomas Petazzoni <thomas.petazzoni@free-electrons.com>
Thu, 16 Feb 2017 08:03:16 +0000 (09:03 +0100)
committerStefan Roese <sr@denx.de>
Wed, 29 Mar 2017 05:41:30 +0000 (07:41 +0200)
commit09b3f948dc5a74c24da62d09e7d469ba4e71c93d
treecbaea3359662605b434da36f9513f8df479a8acc
parentbc0bbf41b10bb377b91b89863684bcb1865e8a4c
net: mvpp2: adapt rxq distribution to PPv2.2

In PPv2.1, we have a maximum of 8 RXQs per port, with a default of 4
RXQs per port, and we were assigning RXQs 0->3 to the first port, 4->7
to the second port, 8->11 to the third port, etc.

In PPv2.2, we have a maximum of 32 RXQs per port, and we must allocate
RXQs from the range of 32 RXQs available for each port. So port 0 must
use RXQs in the range 0->31, port 1 in the range 32->63, etc.

This commit adapts the mvpp2 to this difference between PPv2.1 and
PPv2.2:

- The constant definition MVPP2_MAX_RXQ is replaced by a new field
  'max_port_rxqs' in 'struct mvpp2', which stores the maximum number of
  RXQs per port. This field is initialized during ->probe() depending
  on the IP version.

- MVPP2_RXQ_TOTAL_NUM is removed, and instead we calculate the total
  number of RXQs by multiplying the number of ports by the maximum of
  RXQs per port. This was anyway used in only one place.

- In mvpp2_port_probe(), the calculation of port->first_rxq is adjusted
  to cope with the different allocation strategy between PPv2.1 and
  PPv2.2. Due to this change, the 'next_first_rxq' argument of this
  function is no longer needed and is removed.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Stefan Roese <sr@denx.de>
Acked-by: Joe Hershberger <joe.hershberger@ni.com>
drivers/net/mvpp2.c