- 01 Jul, 2016 6 commits
-
-
Sara Sharon authored
rx_phy notification is no longer sent in devices with multiple rx queues. All the needed data is now set in the metadata - update code accordingly to reflect all the features as in the previous RX path. Signed-off-by:
Sara Sharon <sara.sharon@intel.com> Signed-off-by:
Luca Coelho <luciano.coelho@intel.com>
-
Sara Sharon authored
In multiple RX queues architecture, the RX_PHY notification is no longer useful as it is received in the default queue even for packets that are received on RSS queue, and cannot be accessed without locking. All the needed data is in the new RX packet metadata and firmware will no longer send this notification for 9000 devices. Remove support of it. Signed-off-by:
-
Avraham Stern authored
Ucode capability bit 26 indicates support for UAPSD on P2P interface even with a simultaneous BSS station interface, as long as both interfaces are in the same binding. Change the name of the capability bit to reflect that. Signed-off-by:
Avraham Stern <avraham.stern@intel.com> Signed-off-by:
-
Johannes Berg authored
Somehow we ended up without leading spaces here, fix that. Signed-off-by:
Johannes Berg <johannes.berg@intel.com> Signed-off-by:
-
Sara Sharon authored
We cannot trust NSSN for AMSDU sub-frames that are not the last. The reason is that NSSN advances on the first sub-frame, and may cause the reorder buffer to advance before all the sub-frames arrive. Example: Reorder buffer contains SN 0 & 2. We receive AMSDU with SN 1 and NSSN for first sub frame 3. The result us that driver releases SN 0,1, 2. When sub-frame 1 arrives - reorder buffer is already ahead and it will be dropped. If the last sub-frame is not on this queue - we will get frame release notification with up to date NSSN. Signed-off-by:
-
Emmanuel Grumbach authored
The new hardware that supports multiple queue also de-aggregates A-MSDUs. This means that we can advertise the maximal size of A-MSDUs regardless of the receive buffer's size. In order to be able to forcefully use a lower A-MSDU size, add a default value for the module parameter. Pre-9000 will have a default of 4K, and 9000 will have 12K. Setting the amsdu_size module parameter to 4K will limit the A-MSDU on 9000 as well. Signed-off-by:
Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by:
-
- 10 May, 2016 34 commits
-
-
Luca Coelho authored
I'm starting to take a more active role in the iwlwifi driver maintainership. Cc: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Cc: Johannes Berg <johannes.berg@intel.com> Signed-off-by: -
Emmanuel Grumbach authored
Small change to make it clear that the default value is false. Signed-off-by:
-
Sara Sharon authored
When initializing RX we grab NIC access for every read and write. This is redundant - we can just grab access once. Signed-off-by:
-
Sara Sharon authored
The RX queues have a shadow register for the write pointer that enables updates without grabbing NIC access. Use them instead of the periphery registers because accessing those is much more expensive. Signed-off-by:
-
Liad Kaufman authored
In non-shared queues, DQA requires re-configuring existing queues to become aggregated rather than allocating a new one. It also requires "un-aggregating" an existing queue when aggregations are turned off. Support this requirement for non-shared queues. Signed-off-by:
Liad Kaufman <liad.kaufman@intel.com> Signed-off-by:
-
Johannes Berg authored
Since msleep is based on jiffies, it can sleep for a long time. Use usleep_range() instead to shorten the maximum time. Signed-off-by:
-
Johannes Berg authored
Newer hardware generations will take longer to be accessible again after reset, so we need to wait longer before continuing any flow that did a reset. Rather than make the wait time configurable, simply extend it for all. Since all of these code paths can sleep, use usleep_range() rather than mdelay(). Signed-off-by:
-
Gregory Greenman authored
Devices supporting VHT 160MHz width are supporting also Short GI. Turn on this capability in vht cap. Signed-off-by:
Gregory Greenman <gregory.greenman@intel.com> Signed-off-by:
-
Johannes Berg authored
Since we have a lot of configuration structs (almost 70) saving some memory in each one of them leads to an overall saving of ~2.6KiB of memory. Signed-off-by:
-
Emmanuel Grumbach authored
The commit below added code to dump the content of FIFOs that are present only on dual CPU products (8000 and up). This broke 7265D whose firmware does advertise IWL_UCODE_TLV_CAPA_EXTEND_SHARED_MEM_CFG but doesn't have 2 CPUs. The current code does check the length of the FIFO before dumping them (and the nonexistent FIFO has a 0 length), but we still accessed a register to set the FIFO number and that made the DMA unhappy. The impact was a much longer recovery upon firmware assert. Fixes: 5b086414 ("iwlwifi: mvm: support dumping UMAC internal txfifos") Signed-off-by:
-
Emmanuel Grumbach authored
This Kconfig option allows to load a firmware for debugging with a different name. This mechanism has not been used for a few years now and replacing the firmware file works as well. Kill this Kconfig option and all the code that goes with it. Signed-off-by:
-
Sara Sharon authored
Getting the mvm station out of station id requires dereferencing the station id to get ieee80211_sta, then checking for pointer validity and only then extract mvm station out. Given that there are helpers to do it - use them instead of duplicating the code whenever we need only mvm station. Signed-off-by:
-
Sara Sharon authored
iwl_phy_db_set_section() is get called only from atomic context, the alloc_ctx parameter is not needed. Remove it. Signed-off-by:
-
Sara Sharon authored
Driver is agnostic to the number of the phy_db entries and only serves the firmware as a pipe to move the data from init image to RT image. As the size of the arrays may change (as it does in 9000 device) allocate it dynamically. Firmware sends the largest index first so we can use this to know how much we should allocate. Signed-off-by:
-
Sara Sharon authored
Our device supports only 160 GHz and not 80+80. Fix VHT flag accordingly. Signed-off-by:
-
Sara Sharon authored
Up till now, the reorder buffer uses standard spec based comparison when comparing the buffer status to NSSN. This indeed works for the regular case, since we shouldn't cross the 2048 boundary without getting a frame release notification. However, this is problematic due to packet filtering that may be performed by the FW while we are in d0i3. Theoretically we may filter over 2048 packets, and then the check of the NSSN will get incorrect. Change the comparison to always trust nssn unless it is 64 or less frames behind the head - which might happen due to a timeout. This new comparison is to be used only when comparing reorder buffer head with nssn, and not when comparing the packet SN to nssn or reorder buffer head. Put this in a separate commit as the logic is a bit tricky and stands for its own commit message. Signed-off-by:
-
Haim Dreyfuss authored
CSR registers are always available even when the NIC is not awake, no need to wake up the NIC before accessing them. This has a huge impact when we re-enable an interrupt at the end of the ISR since waking up the NIC can take some time. Signed-off-by:
Haim Dreyfuss <haim.dreyfuss@intel.com> Signed-off-by:
-
Haim Dreyfuss authored
Previous patch had changed firmware name convention for new generation product. The firmware name is now longer than the former convention. Adapt max firmware name length to the new convention. Fixes: e1ba684f ("iwlwifi: 8000: fix MODULE_FIRMWARE input") Signed-off-by:
-
Sara Sharon authored
Currently code allows mvm reference to become negative and only warns in case mvm reference is released while reference counting is 0. However, we better prevent this from happening at all since iwl_mvm_unref() may race against iwl_mvm_unref_all_except() which is called on restart. As a result we might get the same reference unreferenced twice ending with a negative value: An example for an easily reproduced log: [ 2689.909166] iwl_mvm_ref Take mvm reference - type 8 [ 2690.732716] iwl_mvm_unref_all_except Cleanup: remove mvm ref type 8 (1) [ 2690.849708] iwl_mvm_unref Leave mvm reference - type 8 [ 2690.849721] WARNING: ... iwl_mvm_unref+0xb0/0xc0 [iwlmvm]() If there will be yet another another restart iwl_mvm_unref_all_except will run from 0 up to ref count, and since it is unsigned, we will throw the transport ref count completely out of balance: iwl_mvm_unref_all_except[I] -- Cleanup: remove mvm ref type 8 (255) iwl_trans_slv_unref[I] -- rpm counter: 0 iwl_trans_slv_unref[I] -- rpm counter: -1 iwl_trans_slv_unref[I] -- rpm counter: -2 ... iwl_trans_slv_unref[I] -- rpm counter: -253 iwl_trans_slv_unref[I] -- rpm counter: -254 As there is no valid scenario where we can get to a negative reference count - prevent it from happening. Signed-off-by: -
Golan Ben-Ami authored
Add UREG, RXFC, RFH, WMAL and RL2P registers to the prph dump upon error. These regesiters could help to debug MSI-X and other issues. These register should be dumped only when multi-queue rx is supported so separate the prph ranges static array to two different arrays, and enable dumping different prph ranges according to run-time decision. Signed-off-by:
Golan Ben-Ami <golan.ben.ami@intel.com> Signed-off-by:
-
Luca Coelho authored
When a data packet is received, we need to make sure that we stay awake until it can be processed and wait a while before trying to enter runtime_suspend os system_suspend again. To do so, add a new reference type for RX data and take the reference when sending the packet to mac80211. We only do this for data packets, all the other RX packets sent by the firmware (e.g. notifications) are not a reason to prevent suspend. Signed-off-by: -
Johannes Berg authored
When we've already looked up the transmitter station, we can just pass it to mac80211 using the new ieee80211_rx_napi(). This saves the overhead of looking it up in mac80211 again. Signed-off-by:
-
Gregory Greenman authored
Devices belonging to 9000 family can support VHT 160MHz channel width, so need to consider it when configuring VHT capabilities. However, NVM file doesn't have a single bit specifying that 160MHz is supported. This patch turns on 160MHz support in VHT capabilities in case there's at least one channel supporting 160MHz. Signed-off-by:
-
Haim Dreyfuss authored
Currently there is one to one function between device id to it's ucode. The new generation devices allows to combine different phy and mac images. Now we have two different ucode images with the same device id. Read RF ID to identify phy image and overwrite it if needed. Signed-off-by:
-
Luca Coelho authored
If a host command was queued while in runtime suspend, it would go out before the D0I3_END_CMD was sent. Sometimes it works, but sometimes it fails, and it is obviously the wrong thing to do. To fix this, have the opmode take a reference before sending a SYNC command and make the pcie trans wait for the runtime state to become active before actually queueing the command. Signed-off-by: -
Emmanuel Grumbach authored
There is a debugfs knob to configure the maximal length of the A-MSDU. If this value is not 0 (which is the default), allow Tx A-MSDU even if the rate control disallows it. While at it, add "unlikely" to the if that limits the length of the A-MSDU based on the debugfs hook. Signed-off-by:
-
Haim Dreyfuss authored
Rename 9560 to 9260. Add new PCI ID for 9260 and change some entries from 5165 to 9260. Also order the 9000 series. Signed-off-by:
-
Sara Sharon authored
Add a constant to allow disabling checksum. This will enable easier debugging in early phases. Signed-off-by:
-
Johannes Berg authored
In order for mac80211 to use per-CPU statistics for RSS RX, the driver needs to advertise that it uses RSS. Do this when using more than a single queue. Signed-off-by:
-
Luca Coelho authored
It's cleaner to always call the iwl_trans_ref/unref() functions instead of sometimes calling the trans-specific ops directly. This also prepares for moving some of the code from the trans-specific ops to the common trans code. Signed-off-by:
-
Liad Kaufman authored
To indicate to the FW that a queue has been removed, an existing flag in the ADD_STA HCMD (that hasn't been in use) has been changed to indicate that a queue is being removed from a STA. Update this in the driver code. Signed-off-by:
-
Sara Sharon authored
The firmware will send frame release notification in order to release "stuck" frames on a queue where no more frames arrive on. Upon receiving the message the driver shall indicate the frames up to the NSSN. Signed-off-by:
-
Sara Sharon authored
Add a timer in order to release expired frames from the reorder buffer. This is needed since some APs do not retransmit frames to fill in the reorder holes and in TCP it results with a complete stall of traffic. This has a few side effects on the general design: The nssn may not reflect the the head of the reorder buffer. This situation is valid, and packets with SN lower than the reorder buffer head will be dropped. Another side effect is that since the reorder timer might expire we need to lock the reorder buffer. This however is fine since the locking is only inside a single reorder buffer between RX path and reorder timeout and there is no outside contention. Signed-off-by:
-
Sara Sharon authored
Next hardware will direct packets to core based on the TCP/UDP streams. This logic can create holes in reorder buffer since packets that belong to other stream were directed to a different core. However, those are valid holes and the packets can be indicated in L3 order. The hardware will utilize a mechanism of informing the driver of the normalized ssn and the driver shall release all packets that SN is lower than the nssn. This enables managing the reorder across the queues without sharing any data between them. The reorder buffer is allocated and released directly in the RX path in order to avoid various races between control path and rx path. The code utilizes the internal messaging to notify rx queues of when to delete the reorder buffer. Signed-off-by:
-
