- 07 Oct, 2009 40 commits
-
-
Johannes Berg authored
When instructing the microcode to use just a single chain when we have power saving enabled, we should also tell the AP that we are doing SM powersave. However, using a single chain doesn't actually have any power saving advantage while idle -- measurements show that the power consumption is no different when using one vs. two or three chains. Therefore, always instruct the microcode to use all chains. Signed-off-by:
Johannes Berg <johannes@sipsolutions.net> Signed-off-by:
Reinette Chatre <reinette.chatre@intel.com> Signed-off-by:
John W. Linville <linville@tuxdriver.com>
-
Johannes Berg authored
We never have four chains, but let's fix the typo while we noticed it. You count 0, 1, 2, 3, not 0, 1, 2, 4 :) Signed-off-by:
-
Wey-Yi Guy authored
Today's implementation allow LED to blink based on the traffic condition. We introduce an additional LED mode that reflects the RF state. The supported LED modes after this are: IWL_LED_BLINK (current/default) - blink rate based on current Tx/Rx traffic IWL_LED_RF_STATE (new) - LED OFF: No power/RF disabled, the LED is emitting no light LED ON: Powered/RF enabled, the LED is emitting light in a stable non-flashing state. In order to provide the flexibility to support different LED behavior per user/system preference we add "led_mode" iwlcore module parameter. Signed-off-by:Wey-Yi Guy <wey-yi.w.guy@intel.com> Signed-off-by:
-
Wey-Yi Guy authored
Update PCI Subsystem ID for 60x0 series based on HW SKU. Adding new SKU for "ABG" and "BG" only devices. Signed-off-by:
-
Wey-Yi Guy authored
Update PCI Subsystem ID for 1000 series based on HW SKU. Adding new SKU for "BG" only devices. Signed-off-by:
-
Wey-Yi Guy authored
In order for uCode to select the valid antennas for transmit, driver need to configure the allowed tx antennas through host command. The TX_ANT_CONFIGURATION_CMD should be used for 5000 series and up Signed-off-by:
-
Daniel C Halperin authored
Current rate scale algorithm fluctuates between different MIMO modes fairly rapidly, causing widely varying performance. These fluctuations occur because in the rate_scale tables for expected throughput the values are not very different for different modes. However, when aggregation is turned on and MAC overhead is reduced, the expected throughput for different MIMO modes grows and different modes have vastly different performance. Add expected throughput tables for this case. We also need to keep track of aggregation status per-station, so we add the "is_agg" field to struct lq_sta. Also includes cleanup of comments and variable names in/around the affected code. Signed-off-by:
Daniel C Halperin <daniel.c.halperin@intel.com> Signed-off-by:
-
Daniel C Halperin authored
OR-in AMPDU flags rather than assigning them. This lets the TX status for aggregated packets be processed by rs_tx_status. Signed-off-by:
-
Daniel C Halperin authored
Cut down on redundant code, reorganize structure, and add/improve comments. Should contain no functional changes. Signed-off-by:
-
Wey-Yi Guy authored
Instead of hardcode module parameter's permissions, use pre-defined. Signed-off-by:
-
Wey-Yi Guy authored
Update EEPROM version requirement for 1000 and 6000 series of NIC for EEPROM version verification. Signed-off-by:
-
Wey-Yi Guy authored
Allow user to change protection mechanism for HT between RTS/CTS and CTS-to-self through sysfs: Show current protection mechanism for HT cat /sys/class/net/wlan0/device/rts_ht_protection Change protection mechanism for HT (only allowed while not-associated) CTS-to-self: echo 0 > /sys/class/net/wlan0/device/rts_ht_protection RTS/CTS: echo 1 > /sys/class/net/wlan0/device/rts_ht_protection Signed-off-by:
-
Wey-Yi Guy authored
When 802.11g was introduced, we had RTS/CTS and CTS-to-Self protection mechanisms. In an HT Beacon, HT stations use the "Operating Mode" field in the HT Information Element to determine whether or not to use protection. The Operating Mode field has 4 possible settings: 0-3: Mode 0: If all stations in the BSS are 20/40 MHz HT capable, or if the BSS is 20/40 MHz capable, or if all stations in the BSS are 20 MHz HT stations in a 20 MHz BSS Mode 1: used if there are non-HT stations or APs using the primary or secondary channels Mode 2: if only HT stations are associated in the BSS and at least one 20 MHz HT station is associated. Mode 3: used if one or more non-HT stations are associated in the BSS. When in operating modes 1 or 3, and the Use_Protection field is 1 in the Beacon's ERP IE, all HT transmissions must be protected using RTS/CTS or CTS-to-Self. By default, CTS-to-self is the preferred protection mechanism for less overhead and higher throughput; but using the full RTS/CTS will better protect the inner exchange from interference, especially in highly-congested environment. For 6000 series WIFI NIC, RTS/CTS protection mechanism is the recommended choice for HT traffic based on the HW design. Signed-off-by:
-
Johannes Berg authored
The chain settings we currently use in iwlwifi are rather confusing -- and we also go by the wrong settings entirely under certain circumstances. To clean it up, create a new variable in the current HT config -- single_chain_sufficient -- that tells us whether we need more than one chain. Calculate that based on the AP and operating mode (no IBSS HT implemented -- so no need for multiple chains, for station mode we use the AP's capabilities). Additionally, since APs always send disabled SM PS mode, keeping track of their sm_ps mode isn't very useful -- doubly not so for our _own_ RX config since that should depend on our, not the AP's, SM PS mode. Finally, document that our configuration of the number of RX chains used is currently wrong when in powersave (by adding a comment). All together this removes the two remaining items in struct iwl_ht_config that were done wrong there. For the future, the number of RX chains and some SM PS handshaking needs to be added to mac80211, which then needs to tell us, and the new variable current_ht_config.single_chain_sufficient should also be calculated by mac80211. Signed-off-by:
-
Wey-Yi Guy authored
Show version number along with dumping NVM data, the version information being removed from sysfs, add it back to debugfs to help debugging. Signed-off-by:
-
Johannes Berg authored
Daniel Halperin pointed out that the naming here is rather inconsistent with at least 3 different names being used for one thing in different contexts. Rename the struct to iwl_ht_config (rather than iwl_ht_info) and use ht_conf as a variable for it. Signed-off-by:
-
Wey-Yi Guy authored
Adjust led blink rate to compensate on a MAC Clock difference on every HW. Led blink rate analysis showed an average deviation of 0% on 3945, 5% on 4965 HW and 20% on 5000 series and up. Need to compensate on the led on/off time per HW according to the deviation to achieve the desired led frequency The calculation is: (100-averageDeviation)/100 * blinkTime For code efficiency the calculation will be: compensation = (100 - averageDeviation) * 64 / 100 NewBlinkTime = (compensation * BlinkTime) / 64 Signed-off-by: -
Johannes Berg authored
is_ht can be bool instead of u8, and there's no need to use IWL_CHANNEL_WIDTH_* constants in supported_chan_width when that could just be named is_40mhz instead. Signed-off-by:
-
Wey-Yi Guy authored
Separate set_hw_params() function for 6000 series from 5000/1000 series because: 1) 6000 series use different set of sensitivity range table 2) 6000 series has different uCode image size Also include the new sensitivity parameters needed by sensitivity algorithm. Signed-off-by: -
Wey-Yi Guy authored
Different NIC has different requirements for configuration. Currently all 5000 series hardware and later share the same configuration function even though they do not need the same configurations. Fix this by separating the needed configuration actions for each hardware model. .5000 series: L1-ASPM H/W bug work-around configure radio write CSR_HW_IF_CONFIG_REG for uCode use work-around for NIC get stuck after early PCIe power off .1000 series: write CSR_HW_IF_CONFIG_REG for uCode use setting digital SVR for 1000 card to 1.32V .6000 series: configure radio write CSR_HW_IF_CONFIG_REG for uCode use write CSR_GP_DRIVER_REG to indicate radio sku Signed-off-by: -
Wey-Yi Guy authored
Remove few of the parameters not used and no longer valid in EEPROM. Signed-off-by:
-
Wey-Yi Guy authored
Modify LED blink index table to include 1Mbps. Signed-off-by:
-
Luis R. Rodriguez authored
As noted by Jiri. Signed-off-by:
Luis R. Rodriguez <lrodriguez@atheros.com> Signed-off-by:
-
Luis R. Rodriguez authored
This is the last part to make ath9k hw code core driver agnostic. I believe ath9k_htc can now use use the hw code unmodified. Signed-off-by:
-
Luis R. Rodriguez authored
mac.c is now core driver independent. Signed-off-by:
-
Luis R. Rodriguez authored
hw code will be shared between ath9k and ath9k_htc. Just a few more files are left to clean up, mark them as well. Signed-off-by:
-
Luis R. Rodriguez authored
Signed-off-by:
-
Luis R. Rodriguez authored
This is used by hw code. Signed-off-by:
-
Luis R. Rodriguez authored
This is used just to determine how to program the MAC, either for 20 MHz operation of 40 MHz so just use conf_is_ht40() Signed-off-by:
-
Luis R. Rodriguez authored
This was for supporting 25 MHz spacing for HT40, this is not used as we use 20 MHz spacing instead for HT40 as per 802.11n. The hardware is capable of it though so we leave the phymode definition and EEPROM parsing for it. If some experimenter wants to work on this stuff stuff you can add an extension enabling bool on ath_common and perhaps some debugfs knob to enable it. Keep in mind you'll also need to update the phymode with the AR_PHY_FC_DYN2040_EXT_CH which has been left on the driver. Signed-off-by:
-
Luis R. Rodriguez authored
Signed-off-by:
-
Luis R. Rodriguez authored
ath9k uses this for now, ath9k_htc is expected to re-use this as well. We lave ath5k as is, but it certainly can also be converted later. The ath9k module parameter and debugfs entry is kept. Signed-off-by:
-
Luis R. Rodriguez authored
Signed-off-by:
-
Luis R. Rodriguez authored
Make use of it on hw code in ath9k to avoid using the ath9k ath_softc. Signed-off-by:
-
Luis R. Rodriguez authored
Also make ath5k and ath9k use it, and share register definitions. Signed-off-by:
-
Luis R. Rodriguez authored
Only common ath read/write ops go through the common ops. Signed-off-by:
-
Luis R. Rodriguez authored
We can propagate better errors upon failed hw initialization, and set up the ath_common structure for attach purposes. This will become important once we start using the ath_common for read/write ops. Signed-off-by:
-
Luis R. Rodriguez authored
In an effort to make hw code driver core agnostic read and write operations are defined on the ath_common structure. This patch adds that and makes ath9k use it. This allows drivers like ath9k_htc to define its own read/write ops and still rely on the same hw code. This also paves the way for sharing code between ath9k/ath5k/ath9k_htc. Signed-off-by:
-
Luis R. Rodriguez authored
We disable ASPM when enabling bluetooth coexistance. Disabling ASPM is a bus specific operation. In the future other buses may support bluetooth coexistance, an example is USB. To this end move the current routine which disables ASPM into pci.c, and declare it the PCI bt_coex_prep() helper. Additionally, since ASPM is a PCI-Express primitive ensure we don't ever try to muck with ASPM registers on non PCI-express devices. This also cleans up hw.c to not include bus specific headers or utilities. Cc: Vasanthakumar Thiagarajan <vasanth@atheros.com> Cc: Stephen Chen <stephen.chen@atheros.com> Cc: Zhifeng Cai <zhifeng.cai@atheros.com> Signed-off-by:
-
Luis R. Rodriguez authored
Signed-off-by:
-
