Skip to content

K
Kernel

openeuler / Kernel
1 年多 前同步成功

通知 8
Star 0
Fork 0
K
Kernel
切换分支/标签
  1. 20 12月, 2015 1 次提交
  3. 13 12月, 2015 1 次提交
  5. 02 12月, 2015 2 次提交
  7. 18 11月, 2015 1 次提交
  9. 25 10月, 2015 1 次提交
  11. 05 10月, 2015 1 次提交
  13. 21 9月, 2015 2 次提交
  15. 28 8月, 2015 1 次提交
  17. 05 8月, 2015 2 次提交
    • M
      iwlwifi: mvm: Add FW paging mechanism for the UMAC on SDIO · e1120187
      由 Matti Gottlieb 提交于 
      Family 8000 products has 2 embedded processors, the first
known as LMAC (lower MAC) and implements the functionality from
previous products, the second one is known as UMAC (upper MAC)
and is used mainly for driver offloads as well as new features.
The UMAC is typically “less” real-time than the LMAC and is used
for higher level controls.
The UMAC's code/data size is estimated to be in the mega-byte arena,
taking into account the code it needs to replace in the driver and
the set of new features.

In order to allow the UMAC to execute code that is bigger than its code
memory, we allow the UMAC embedded processor to page out code pages on
DRAM.

When the device is slave on the bus(SDIO) the driver saves the UMAC's
image pages in blocks of 32K in the DRAM and sends the layout of the
pages to the FW. When the FW wants load / unload pages, it creates an
interrupt,	and the driver uploads / downloads the page to an address in
the a specific address on the device's memory.

The driver can support up to 1 MB of pages.

Add paging mechanism for the UMAC on SDIO in order to allow the program to
use a larger virtual space while using less physical memory on the device
itself.
Signed-off-by: NMatti Gottlieb <matti.gottlieb@intel.com>
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
      e1120187
    • M
      iwlwifi: mvm: Add FW paging mechanism for the UMAC on PCI · a6c4fb44
      由 Matti Gottlieb 提交于 
      Family 8000 products has 2 embedded processors, the first
known as LMAC (lower MAC) and implements the functionality from
previous products, the second one is known as UMAC (upper MAC)
and is used mainly for driver offloads as well as new features.
The UMAC is typically “less” real-time than the LMAC and is used
for higher level controls.
The UMAC's code/data size is estimated to be in the mega-byte arena,
taking into account the code it needs to replace in the driver and
the set of new features.

In order to allow the UMAC to execute code that is bigger than its code
memory, we allow the UMAC embedded processor to page out code pages on
DRAM.

When the device is master on the bus(PCI) the driver saves the UMAC's
image pages in blocks of 32K in the DRAM and sends the layout of the
pages to the FW. The FW can load / unload the pages on its own.

The driver can support up to 1 MB of pages.

Add paging mechanism for the UMAC on PCI in order to allow the program
to use a larger virtual space while using less physical memory on the
device.
Signed-off-by: NEran Harary <eran.harary@intel.com>
Signed-off-by: NMatti Gottlieb <matti.gottlieb@intel.com>
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
      a6c4fb44
  19. 04 8月, 2015 2 次提交
  21. 03 6月, 2015 2 次提交
  23. 28 5月, 2015 1 次提交
  25. 29 4月, 2015 1 次提交
  27. 19 4月, 2015 1 次提交
    • A
      iwlwifi: mvm: fix Tx Power firmware API · d44c3fe6
      由 Avri Altman 提交于 
      The firmware doesn't relate the scan to a vif. The scan is
run by a separate entity called auxiliary MAC (aka AUX MAC).
This AUX MAC needs to get Tx power limitations that are
not applied on a specific vif, but on the device as a whole.

This can be implemented by using the minimum of all the
values set by the user for all the MACs. But then we need
to ignore the limitations that come from the AP or
regulatory for a specific vif: a specific vif might have
regulatory limitations because of the channel is works on.
This limit is irrelevant for the AUX MAC.
Use the new API from mac80211: the user_power_level in
bss_conf to achieve this.

Firmware -13.ucode has already moved to this API.

Change-Id: Ifba83660f378e91b93bd46d29fe8ba35a7c168a4
Signed-off-by: NAvri Altman <avri.altman@intel.com>
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
      d44c3fe6
  29. 12 3月, 2015 6 次提交
  31. 01 3月, 2015 2 次提交
  33. 22 1月, 2015 4 次提交
  35. 02 12月, 2014 1 次提交
  37. 01 12月, 2014 1 次提交
  39. 24 11月, 2014 4 次提交
  41. 24 10月, 2014 1 次提交
    • E
      iwlwifi: configure the LTR · 9180ac50
      由 Emmanuel Grumbach 提交于 
      The LTR is the handshake between the device and the root
complex about the latency allowed when the bus exits power
save. This configuration was missing and this led to high
latency in the link power up. The end user could experience
high latency in the network because of this.

Cc: <stable@vger.kernel.org> [3.10+]
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
      9180ac50
  43. 16 9月, 2014 1 次提交
    • A
      iwlwifi: mvm: prepare for scheduler config command · 3edf8ff6
      由 Avri Altman 提交于 
      The scheduler is a HW sub-block that directs the work of the Flow
Handler by issuing requests for frame transfers, specifying source
and destination. Its primary function is to allocate flows into the
TX FIFOs based upon a pre-determined mapping.

The driver has some responsibilities to the scheduler, namely
initialising and maintaining the hardware registers. This is
currently done by directly accessing them, which can cause races
with the firmware also accessing the registers.

To address this problem, change the driver to no longer directly
access the registers but go through the firmware for this if the
firmware has support for DQA and thus the new command.
Signed-off-by: NAvri Altman <avri.altman@intel.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
      3edf8ff6
  45. 15 9月, 2014 1 次提交