Skip to content

R
raspberrypi-kernel

openeuler / raspberrypi-kernel

通知 13
Star 1
Fork 0
R
raspberrypi-kernel
切换分支/标签
  1. 03 1月, 2018 2 次提交
  3. 27 7月, 2017 2 次提交
  5. 03 7月, 2017 4 次提交
  7. 22 6月, 2017 1 次提交
  9. 21 6月, 2017 1 次提交
  11. 05 6月, 2017 2 次提交
  13. 02 6月, 2017 6 次提交
  15. 31 5月, 2017 1 次提交
  17. 25 5月, 2017 5 次提交
  19. 22 5月, 2017 1 次提交
  21. 09 5月, 2017 1 次提交
  23. 05 5月, 2017 2 次提交
  25. 01 5月, 2017 2 次提交
  27. 28 4月, 2017 2 次提交
  29. 25 4月, 2017 4 次提交
  31. 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