Skip to content

K
Kernel

openeuler / Kernel
1 年多 前同步成功

通知 8
Star 0
Fork 0
K
Kernel
切换分支/标签
  1. 15 5月, 2020 1 次提交
  3. 01 9月, 2019 1 次提交
  5. 16 8月, 2019 1 次提交
  7. 27 5月, 2019 1 次提交
  9. 22 2月, 2019 1 次提交
  11. 09 2月, 2019 1 次提交
  13. 29 1月, 2019 2 次提交
  15. 26 1月, 2019 1 次提交
  17. 23 1月, 2019 2 次提交
  19. 28 11月, 2018 1 次提交
  21. 17 10月, 2018 2 次提交
  23. 21 8月, 2018 2 次提交
  25. 20 7月, 2018 1 次提交
  27. 23 5月, 2018 3 次提交
  29. 08 5月, 2018 1 次提交
  31. 24 4月, 2018 2 次提交
  33. 30 3月, 2018 2 次提交
  35. 27 7月, 2017 1 次提交
  37. 02 6月, 2017 1 次提交
  39. 25 5月, 2017 2 次提交
  41. 05 5月, 2017 1 次提交
  43. 28 4月, 2017 2 次提交
  45. 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
    • T
      qed: Support management-based resource locking · 95691c9c
      由 Tomer Tayar 提交于 
      Global locking can't properly be used to synchronize between different
PFs in all scenarios, as those instances might reside in different
logical partitions [e.g., when a PF is assigned via PDA to some VM].

The management firmware provides a generic infrastructure for
device locks. For each 'resource', it's guaranteed it could be acquired
by at most a single PF at any given time [or by management firmware].

This patch adds the necessary logic in qed for utilizing said
infrastructure, implementing lock/unlock internal APIs.
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>
      95691c9c
    • 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
    • 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
  47. 24 3月, 2017 2 次提交
  49. 15 3月, 2017 1 次提交