Skip to content

R
raspberrypi-kernel

openeuler / raspberrypi-kernel

通知 13
Star 1
Fork 0
R
raspberrypi-kernel
切换分支/标签
  1. 01 5月, 2017 2 次提交
  3. 28 4月, 2017 2 次提交
  5. 25 4月, 2017 4 次提交
  7. 07 4月, 2017 4 次提交
    • M
      qed: Inform qedi the number of possible CQs · 08737a3f
      由 Mintz, Yuval 提交于 
      Now that management firmware is capable of telling us the number of CQs
available for a given PF, qed needs to communicate the number to qedi
so it would know have many to use.
Signed-off-by: NYuval Mintz <Yuval.Mintz@cavium.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      08737a3f
    • M
      qed: Don't close the OUT_EN during init · bd1cc771
      由 Mintz, Yuval 提交于 
      Before initializing the chip's engine, driver currently closes a set
of registers on the HW's ingress flow to prevent packets from slipping
in while they're not supposed to.

This configuration is insufficient, as there are some scenarios where
packets would still arrive even when said registers are set,
but the management firmware already closes other per-port registers
that do suffice, making this setting unnecessray.
Signed-off-by: NYuval Mintz <Yuval.Mintz@cavium.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      bd1cc771
    • T
      qed: Configure cacheline size in HW · 60afed72
      由 Tomer Tayar 提交于 
      Default HW configuration is optimal for an architecture where cache
line size is 64B.

During chip initialization, properly initialize the cache line size
in HW to avoid possible redundant PCI transactions.
Signed-off-by: NTomer Tayar <Tomer.Tayar@cavium.com>
Signed-off-by: NYuval Mintz <Yuval.Mintz@cavium.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      60afed72
    • R
      qed: Don't use main-ptt in unrelated flows · 15582962
      由 Rahul Verma 提交于 
      In order to access HW registers driver needs to acquire a PTT entry
[mapping between bar memory and internal chip address].
Since acquiring PTT entries could fail [at least in theory] as their
number is finite and other flows can hold them, we reserve special PTT
entries for 'important' enough flows - ones we want to guarantee that
would not be susceptible to such issues.

One such special entry is the 'main' PTT which is meant to be used in
flows such as chip initialization and de-initialization.
However, there are other flows that are also using that same entry
for their own purpose, and might run concurrently with the original
flows [notice that for most cases using the main-ptt by mistake, such
a race is still impossible, at least today].

This patch re-organizes the various functions that currently use the
main_ptt in one of two ways:

  - If a function shouldn't use the main_ptt it starts acquiring and
    releasing it's own PTT entry and use it instead. Notice if those
    functions previously couldn't fail, they now can [as acquisition
    might fail].

  - Change the prototypes so that the main_ptt would be received as
    a parameter [instead of explicitly accessing it].
    This prevents the future risk of adding codes that introduces new
    use-cases for flows using the main_ptt, ones that might be in race
    with the actual 'main' flows.
Signed-off-by: NRahul Verma <Rahul.Verma@cavium.com>
Signed-off-by: NYuval Mintz <Yuval.Mintz@cavium.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      15582962
  9. 04 4月, 2017 2 次提交
  11. 29 3月, 2017 5 次提交
    • T
      qed: Utilize resource-lock based scheme · 9c8517c4
      由 Tomer Tayar 提交于 
      Management firmware is used as an arbiter between the various PFs
in matters of resources, but some of the resources that need to
be divided are dependent on the non-management firmware used,
so management firmware first needs to be told how many resources
there are before trying to divide them.

As part of the initialization sequence, driver would first inform
the management firmware of the available resources under
a dedicated resource lock, and afterwards request for various
resources which might be based on the previous set values.
Signed-off-by: NTomer Tayar <Tomer.Tayar@cavium.com>
Signed-off-by: NYuval Mintz <Yuval.Mintz@cavium.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      9c8517c4
    • M
      qed: Send pf-flr as part of initialization · 18a69e36
      由 Mintz, Yuval 提交于 
      During HW initialization, driver would set various registers to their
needed values - but it assumes all registers start at their reset-value,
so there's no need to re-configure a register's default value.

This assumption might be incorrect, e.g., in case of preboot driver
running and initializing the driver prior to our driver.

To overcome this, we now ask management firmware to initiate a PF-flr
early during the initialization sequence. That would return everything
in the PF's scope back to default and prevent previous configurations
from still being applied.
Signed-off-by: NYuval Mintz <Yuval.Mintz@cavium.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      18a69e36
    • T
      qed: Move to new load request scheme · 5d24bcf1
      由 Tomer Tayar 提交于 
      Management firmware is used as an arbiter between the various PFs
in regard to loading - it causes the various PFs to load/unload
sequentially and informs each of its appropriate rule in the init.

But the existing flow is too weak to handle some scenarios where
PFs aren't properly cleaned prior to loading.
The significant scenarios falling under this criteria:
  a. Preboot drivers in some environment can't properly unload.
  b. Unexpected driver replacement [kdump, PDA].

Modern management firmware supports a more intricate loading flow,
where the driver has the ability to overcome previous limitations.
This moves qed into using this newer scheme.

Notice new scheme is backward compatible, so new drivers would
still be able to load properly on top of older management firmwares
and vice versa.
Signed-off-by: NTomer Tayar <Tomer.Tayar@cavium.com>
Signed-off-by: NYuval Mintz <Yuval.Mintz@cavium.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      5d24bcf1
    • M
      qed: hw_init() to receive parameter-struct · c0c2d0b4
      由 Mintz, Yuval 提交于 
      We'll soon need additional information, so start by changing
the infrastructure to receive the initializing variables
via a parameter struct.
Signed-off-by: NYuval Mintz <Yuval.Mintz@cavium.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      c0c2d0b4
    • T
      qed: Correct HW stop flow · 1226337a
      由 Tomer Tayar 提交于 
      Management firmware is used as arbiter between different PFs
which are loading/unloading, but in order to use the synchronization
it offers the contending configurations need to be applied either
between their LOAD_REQ <-> LOAD_DONE or UNLOAD_REQ <-> UNLOAD_DONE
management firmware commands.

Existing HW stop flow utilizes 2 different functions: qed_hw_stop() and
qed_hw_reset() which don't abide this requirement; Most of the closure
is doing outside the scope of the unload request.

This patch removes qed_hw_reset() and places the relevant stop
functionality underneath the management firmware protection.
Signed-off-by: NTomer Tayar <Tomer.Tayar@cavium.com>
Signed-off-by: NYuval Mintz <Yuval.Mintz@cavium.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      1226337a
  13. 24 3月, 2017 2 次提交
  15. 15 3月, 2017 2 次提交
  17. 27 2月, 2017 1 次提交
  19. 21 2月, 2017 1 次提交
  21. 20 2月, 2017 1 次提交
  23. 02 1月, 2017 1 次提交
  25. 03 12月, 2016 2 次提交
  27. 01 12月, 2016 2 次提交
    • M
      qed*: Handle-based L2-queues. · 3da7a37a
      由 Mintz, Yuval 提交于 
      The driver needs to maintain several FW/HW-indices for each one of
its queues. Currently, that mapping is done by the QED where it uses
an rx/tx array of so-called hw-cids, populating them whenever a new
queue is opened and clearing them upon destruction of said queues.

This maintenance is far from ideal - there's no real reason why
QED needs to maintain such a data-structure. It becomes even worse
when considering the fact that the PF's queues and its child VFs' queues
are all mapped into the same data-structure.
As a by-product, the set of parameters an interface needs to supply for
queue APIs is non-trivial, and some of the variables in the API
structures have different meaning depending on their exact place
in the configuration flow.

This patch re-organizes the way L2 queues are configured and maintained.
In short:
  - Required parameters for queue init are now well-defined.
  - Qed would allocate a queue-cid based on parameters.
    Upon initialization success, it would return a handle to caller.
  - Queue-handle would be maintained by entity requesting queue-init,
    not necessarily qed.
  - All further queue-APIs [update, destroy] would use the opaque
    handle as reference for the queue instead of various indices.

The possible owners of such handles:
  - PF queues [qede] - complete handles based on provided configuration.
  - VF queues [qede] - fw-context-less handles, containing only relative
    information; Only the PF-side would need the absolute indices
    for configuration, so they're omitted here.
  - VF queues [qed, PF-side] - complete handles based on VF initialization.
Signed-off-by: NYuval Mintz <Yuval.Mintz@cavium.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      3da7a37a
    • M
      qed: Optimize qed_chain datapath usage · 6d937acf
      由 Mintz, Yuval 提交于 
      The chain structure and functions are widely used by the qed* modules,
both for configuration and datapath.
E.g., qede's Tx has one such chain and its Rx has two.

Currently, the strucutre's fields which are required for datapath
related functions [produce/consume] are intertwined with fields which
are required only for configuration purposes [init/destroy/etc.].

This patch re-arranges the chain structure so that all the fields which
are required for datapath usage could reside in a single cacheline instead
of the two which are required today.
Signed-off-by: NYuval Mintz <Yuval.Mintz@cavium.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      6d937acf
  29. 01 11月, 2016 4 次提交
  31. 14 10月, 2016 2 次提交
  33. 04 10月, 2016 2 次提交
  35. 07 9月, 2016 1 次提交
    • J
      qed: Remove OOM messages · 2591c280
      由 Joe Perches 提交于 
      These messages are unnecessary as OOM allocation failures already do
a dump_stack() giving more or less the same information.

$ size drivers/net/ethernet/qlogic/qed/built-in.o* (defconfig x86-64)
   text	   data	    bss	    dec	    hex	filename
 127817	  27969	  32800	 188586	  2e0aa	drivers/net/ethernet/qlogic/qed/built-in.o.new
 132474	  27969	  32800	 193243	  2f2db	drivers/net/ethernet/qlogic/qed/built-in.o.old

Miscellanea:

o Change allocs to the generally preferred forms where possible.
Signed-off-by: NJoe Perches <joe@perches.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      2591c280