- 24 3月, 2010 1 次提交
-
-
由 Sujith 提交于
Update the register initialization values for AR9271. This is based on our last review from our systems team. Signed-off-by: NSujith <Sujith.Manoharan@atheros.com> Signed-off-by: NVasanthakumar Thiagarajan <vasanth@atheros.com> Signed-off-by: NLuis R. Rodriguez <lrodriguez@atheros.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
- 10 3月, 2010 1 次提交
-
-
由 Pavel Roskin 提交于
The AR_IMR_S2 register sometimes cannot be read correctly. Instead of a valid value, 0xdeadbeef is returned. The driver has been observed writing that value back to AR_IMR_S2 after changing a few bits. Cache the register value in ah->imrs2_reg and always write chached value to the register. Signed-off-by: NPavel Roskin <proski@gnu.org> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
- 03 2月, 2010 1 次提交
-
-
由 Luis R. Rodriguez 提交于
Some single chip family devices are sold in the market with 802.11n bonded out, these have no hardware capability for 802.11n but ath9k can still support them. These are called AR2427. Cc: stable@kernel.org Reported-by: NRolf Leggewie <bugzilla.kernel.org@rolf.leggewie.biz> Tested-by: NBernhard Reiter <ockham@raz.or.at> Signed-off-by: NLuis R. Rodriguez <lrodriguez@atheros.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
- 16 1月, 2010 2 次提交
-
-
由 Felix Fietkau 提交于
Signed-off-by: NFelix Fietkau <nbd@openwrt.org> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Felix Fietkau 提交于
Previously ath9k left the initialization of slot timing and ACK/CTS timeout to the mode specific initvals. This does not handle short vs long slot in 2.4 GHz and uses a rather strange value for the 2.4 GHz ACK timeout (64 usec). This patch uses the proper ath9k_hw functions for setting slot time and timeouts and also implements the switch between short and long slot time in 2.4 GHz Signed-off-by: NFelix Fietkau <nbd@openwrt.org> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
- 13 1月, 2010 1 次提交
-
-
由 Sujith 提交于
The device initialization and termination functions were messy and convoluted. Introduce helper functions to clarify init_softc() and simplify things in general. Signed-off-by: NSujith <Sujith.Manoharan@atheros.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
- 23 12月, 2009 1 次提交
-
-
由 Sujith 提交于
ath9k currently supports only RX interrupt mitigation. Signed-off-by: NSujith <Sujith.Manoharan@atheros.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
- 05 12月, 2009 1 次提交
-
-
由 Gabor Juhos 提交于
Currently, the 2GHz band is enabled unconditionally, even if the device does not support it. Changes-licensed-under: ISC Signed-off-by: NGabor Juhos <juhosg@openwrt.org> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
- 29 11月, 2009 2 次提交
-
-
由 Luis R. Rodriguez 提交于
Atheros single stream AR9285 and AR9271 have half the PCU TX FIFO buffer size of that of dual stream devices. Dual stream devices have a max PCU TX FIFO size of 8 KB while single stream devices have 4 KB. Single stream devices have an issue though and require hardware only to use half of the amount of its capable PCU TX FIFO size, 2 KB and this requires a change in software. Technically a change would not have been required (except for frame burst considerations of 128 bytes) if these devices would have been able to use the full 4 KB of the PCU TX FIFO size but our systems engineers recommend 2 KB to be used only. We enforce this through software by reducing the max frame triggger level to 2 KB. Fixing the max frame trigger level should then have a few benefits: * The PER will now be adjusted as designed for underruns when the max trigger level is reached. This should help alleviate the bus as the rate control algorithm chooses a slower rate which should ensure frames are transmitted properly under high system bus load. * The poll we use on our TX queues should now trigger and work as designed for single stream devices. The hardware passes data from each TX queue on the PCU TX FIFO queue respecting each queue's priority. The new trigger level ensures this seeding of the PCU TX FIFO queue occurs as designed which could mean avoiding false resets and actually reseting hw correctly when a TX queue is indeed stuck. * Some undocumented / unsupported behaviour could have been triggered when the max trigger level level was being set to 4 KB on single stream devices. Its not clear what this issue was to me yet. Cc: Kyungwan Nam <kyungwan.nam@atheros.com> Cc: Bennyam Malavazi <bennyam.malavazi@atheros.com> Cc: Stephen Chen <stephen.chen@atheros.com> Cc: Shan Palanisamy <shan.palanisamy@atheros.com> Cc: Paul Shaw <paul.shaw@atheros.com> Signed-off-by: NVasanthakumar Thiagarajan <vasanth@atheros.com> Signed-off-by: NLuis R. Rodriguez <lrodriguez@atheros.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Felix Fietkau 提交于
This patch changes ath9k to pass proper MCS indexes and flags between the RC and the rest of the driver code. sc->cur_rate_table remains, as it's used by the RC code internally, but the rest of the driver code no longer uses it, so a potential new RC for ath9k would not have to update it. Signed-off-by: NFelix Fietkau <nbd@openwrt.org> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
- 26 11月, 2009 1 次提交
-
-
由 John W. Linville 提交于
CC [M] drivers/net/wireless/ath/ath9k/recv.o drivers/net/wireless/ath/ath9k/recv.c: In function `ath_rx_prepare': drivers/net/wireless/ath/ath9k/recv.c:208: warning: comparison is always true due to limited range of data type drivers/net/wireless/ath/ath9k/recv.c:220: warning: comparison is always false due to limited range of data type Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
- 19 11月, 2009 1 次提交
-
-
由 Sujith 提交于
ATH9K_ANT_VARIABLE is the default diversity control used. Consequently ath9k_hw_decrease_chain_power() does nothing. ath9k_hw_setantennaswitch() is unused too. Also, gbeacon_rate is unused. Signed-off-by: NSujith <Sujith.Manoharan@atheros.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
- 14 11月, 2009 1 次提交
-
-
Signed-off-by: NVasanthakumar Thiagarajan <vasanth@atheros.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
- 12 11月, 2009 1 次提交
-
-
由 Luis R. Rodriguez 提交于
This will be shared between ath9k and ath9k_htc. Signed-off-by: NLuis R. Rodriguez <lrodriguez@atheros.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
- 31 10月, 2009 7 次提交
-
-
由 Luis R. Rodriguez 提交于
This only differs between single-chip solutions and non single-chip solutions. Signed-off-by: NLuis R. Rodriguez <lrodriguez@atheros.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Luis R. Rodriguez 提交于
This avoids a branch on every channel change. Signed-off-by: NLuis R. Rodriguez <lrodriguez@atheros.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Luis R. Rodriguez 提交于
This clarifies this is only required for external radios. Signed-off-by: NLuis R. Rodriguez <lrodriguez@atheros.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Luis R. Rodriguez 提交于
Document what we can about the RF analog front ends (radios) of Atheros 802.11n devices. What should be clearer now is the what we do for old pre AR5416 and AR5418 MAC based devices in comparison to the modern sigle-chip 802.11n solutions. All devices after AR9280 are single chip and require less programming -- the RF registers no longer need to be initialized as they all have the RF analog front end embedded together with the MAC/BB; this includes the AR9271. Older devices such as the ones with the AR5416 MACs (PCI) or AR5418 MACs (PCI-E) have an external 2.4 GHz AR2133 radio or a dual band 2.4 GHz / 5 GHz AR5133 radio. These external radios require additional programming of the RF registers. Clarify which parts are for what devices and which code is shared. This patch has no functional changes. Signed-off-by: NLuis R. Rodriguez <lrodriguez@atheros.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Luis R. Rodriguez 提交于
This update the register initialization/reset values (aka initvals) for ar9271 based on the last recommended values on 2009-06-04 by our systems engineering team. The changes account for: * Supporting ar9271 1.0 and ar9271 1.1 together, the difference is bb_spectral_scan_ena, for 1.0 we'll set this to 0x1. * Ensuring we get the correct noise floor values -115 ~ -118 when we enable bb_enable_ant_div_lnadiv=0 and mc_tx_def_ant_sel=1. Previous to this we would get noise floor values in the range -50 ~ -80. To fix settings for the registers: - bb_ch1_xatten1_db - bb_ch1_xatten2_db - bb_ch1_xatten1_margin - bb_ch1_xatten2_margin - bb_ch1_gain_force - bb_ch1_xatten2_hyst_margin - bb_ch1_xatten1_hyst_margin - bb_ch1_max_oc_gain * 0x8120[2] mc_mic_new_location_enable is changed to 0x1. The MAC team suggest to set this value. * 0x9910[0] bb_spectral_scan_ena is changed to 0x0. For ar9271 1.1 we don't need to enable this bit. Cc: Stephen Chen <Stephen.Chen@atheros.com> Signed-off-by: NLuis R. Rodriguez <lrodriguez@atheros.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Luis R. Rodriguez 提交于
Devices with external radios have revisions which we can count on. On single chip solutions these EEPROM values for these radio revision also exist but are not meaningful as the radios are embedded onto the same chip. Each single-chip device evolves together as one device. Signed-off-by: NLuis R. Rodriguez <lrodriguez@atheros.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Luis R. Rodriguez 提交于
These are shared between ath9k and the future ath9k_htc driver. Signed-off-by: NLuis R. Rodriguez <lrodriguez@atheros.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
- 08 10月, 2009 19 次提交
-
-
由 Luis R. Rodriguez 提交于
hw code should never use private driver data, but sometimes we need a backpointer so just stuff it on the common ath struct. Signed-off-by: NLuis R. Rodriguez <lrodriguez@atheros.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Luis R. Rodriguez 提交于
This allows for hw support to be enabled for ar9271. Signed-off-by: NLuis R. Rodriguez <lrodriguez@atheros.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Senthil Balasubramanian 提交于
Reduce PLL Settle time and eliminate redundant PLL calls. Also reduce the LoadNF timeout from 10 msec to 250usec as the 10 msec timeout was hit with AR9285 in some cases. Signed-off-by: NSenthil Balasubramanian <senthilkumar@atheros.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Sujith 提交于
If the current channel is between 2412 and 2472 MHz and if the channel is changing to 2484 MHz, then the registers 0xa1f4, 0xa1f8 and 0xa1fc need to be programmed to the "japan_2484" values. Conversely, if the current channel is 2484 MHz and if the channel is changing to one between 2412 and 2472 MHz, then the three registers need to be programmed to the "normal" values. This is needed for compliance with Japanese regulatory requirements. Signed-off-by: NSujith <Sujith.Manoharan@atheros.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Luis R. Rodriguez 提交于
mac.c is now core driver independent. Signed-off-by: NLuis R. Rodriguez <lrodriguez@atheros.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Luis R. Rodriguez 提交于
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: NLuis R. Rodriguez <lrodriguez@atheros.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Luis R. Rodriguez 提交于
This is used by hw code. Signed-off-by: NLuis R. Rodriguez <lrodriguez@atheros.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Luis R. Rodriguez 提交于
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: NLuis R. Rodriguez <lrodriguez@atheros.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Luis R. Rodriguez 提交于
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: NLuis R. Rodriguez <lrodriguez@atheros.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Luis R. Rodriguez 提交于
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: NLuis R. Rodriguez <lrodriguez@atheros.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Luis R. Rodriguez 提交于
Signed-off-by: NLuis R. Rodriguez <lrodriguez@atheros.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Luis R. Rodriguez 提交于
Make use of it on hw code in ath9k to avoid using the ath9k ath_softc. Signed-off-by: NLuis R. Rodriguez <lrodriguez@atheros.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Luis R. Rodriguez 提交于
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: NLuis R. Rodriguez <lrodriguez@atheros.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Luis R. Rodriguez 提交于
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: NLuis R. Rodriguez <lrodriguez@atheros.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Luis R. Rodriguez 提交于
This ensures that we can access common on hw related code independent of the driver core. Signed-off-by: NLuis R. Rodriguez <lrodriguez@atheros.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Luis R. Rodriguez 提交于
These are common amongst ath9k and ath5k, so put them into the common structure and make ath9k to use it. ar9170 can use macaddr, and curbssid. We'll change ath5k and ar9170 separately. Signed-off-by: NLuis R. Rodriguez <lrodriguez@atheros.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Luis R. Rodriguez 提交于
Signed-off-by: NLuis R. Rodriguez <lrodriguez@atheros.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Luis R. Rodriguez 提交于
ath9k_hw_setpower_nolock --> ath9k_hw_setpower() ath9k_hw_setpower() --> ath9k_setpower() Also change the param for ath9k_setpower() to pass the ath_softc. Signed-off-by: NLuis R. Rodriguez <lrodriguez@atheros.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Luis R. Rodriguez 提交于
And we make it static. Signed-off-by: NLuis R. Rodriguez <lrodriguez@atheros.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-