- 31 10月, 2009 15 次提交
-
-
由 Luis R. Rodriguez 提交于
This allows us to later define a callback for both. 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 提交于
This is calling an allocation and checking for it, simplify this process in a macro. Signed-off-by: NLuis R. Rodriguez <lrodriguez@atheros.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Luis R. Rodriguez 提交于
ath9k_hw_rfattach() was just calling a helper and this helper was doing nothing for single-chip devices, and for non single-chip devices it is just allocating memory for banks to program the RF registers at a later time. Simplify this by having the hw initialization call the rf bank allocation directly for external radios. Also, propagate an -ENOMEM properly now upon failure. Signed-off-by: NLuis R. Rodriguez <lrodriguez@atheros.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Luis R. Rodriguez 提交于
We a huge branch for old hardware and nothing for newer hardware. Instead of doing this just bail out early for newer hardware. 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 提交于
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 提交于
We adjust the core clock for ar9271 to 117 MHz; this also requires us to adjust the baud divider based on the targetted baud rate. 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 提交于
Signed-off-by: NLuis R. Rodriguez <lrodriguez@atheros.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 John W. Linville 提交于
With the WLAN_PRE80211 drivers moved to drivers/staging, this distinction becomes unnecessary. Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Luis R. Rodriguez 提交于
An extra register was being written to for PA calibration making the hardware unresponsive, remove it. Hardware reset should now complete fine on ar9271. Signed-off-by: NLuis R. Rodriguez <lrodriguez@atheros.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Luis R. Rodriguez 提交于
We had 0x9912 but AR_PHY_SPECTRAL_SCAN is 0x9910. By using the 0x9912 we were making the hardware unresponsive. This allows us to move forward with hardware reset on ar9271 on the ath9k_htc driver. 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 提交于
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>
-
- 28 10月, 2009 4 次提交
-
-
由 Marek Lindner 提交于
Signed-off-by: NMarek Lindner <lindner_marek@yahoo.de> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Sujith 提交于
When TX is hung, the chip is reset. Ensure that the chip is awake by using the PS wrappers. Signed-off-by: NSujith <Sujith.Manoharan@atheros.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Luis R. Rodriguez 提交于
The PA calibration for ar9271 ath9k_hw_9271_pa_cal() can run during reset or initial calibration, update the PA calibration to account for that and initialize PA calibration variables for both conditions. Signed-off-by: NLuis R. Rodriguez <lrodriguez@atheros.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Luis R. Rodriguez 提交于
This is required for the ar9271 hardware as well. Signed-off-by: NLuis R. Rodriguez <lrodriguez@atheros.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
- 10 10月, 2009 1 次提交
-
-
由 Luis R. Rodriguez 提交于
Reported-by: sujith.manoharan@atheros.com Signed-off-by: NLuis R. Rodriguez <lrodriguez@atheros.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
- 08 10月, 2009 20 次提交
-
-
由 Luis R. Rodriguez 提交于
And move it to hw code on mac.c where it belongs. Signed-off-by: NLuis R. Rodriguez <lrodriguez@atheros.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Luis R. Rodriguez 提交于
This should fix the oops which occurs during module unload due to the dereferencig of ah upon debugfs exit. IP: [<46412d6b>] 0x46412d6b *pde = 00000000 Oops: 0000 [#1] PREEMPT SMP DEBUG_PAGEALLOC last sysfs file: /sys/class/power_supply/BAT0/energy_full Modules linked in: ath9k(-) ath9k_hw mac80211 ath cfg80211 <bleh> Pid: 3112, comm: rmmod Not tainted (2.6.32-rc2-wl #101) 9461DUU EIP: 0060:[<46412d6b>] EFLAGS: 00010246 CPU: 0 EIP is at 0x46412d6b EAX: f5870004 EBX: f6700d94 ECX: 00000000 EDX: c14313a7 ESI: f5870000 EDI: fb58ce70 EBP: f6661eb4 ESP: f6661ea8 DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068 Process rmmod (pid: 3112, ti=f6660000 task=f6579380 task.ti=f6660000) Stack: fb57e5e5 f5ca5d50 fb58ce70 f6661ebc fb58629a f6661ec8 c11b715e f5ca5da8 <0> f6661ed8 c1223d98 f5ca5da8 f5ca5ddc f6661eec c1223e6f fb58ce70 fb58ce70 <0> c14958a0 f6661f00 c1222edb fb58ce70 fb58ce70 fb58cebc f6661f1c c12243c9 Call Trace: [<fb57e5e5>] ? ath_cleanup+0x35/0x50 [ath9k] [<fb58629a>] ? ath_pci_remove+0x1a/0x20 [ath9k] [<c11b715e>] ? pci_device_remove+0x1e/0x40 [<c1223d98>] ? __device_release_driver+0x58/0xa0 [<c1223e6f>] ? driver_detach+0x8f/0xa0 [<c1222edb>] ? bus_remove_driver+0x7b/0xb0 [<c12243c9>] ? driver_unregister+0x49/0x80 [<c1158cf2>] ? sysfs_remove_file+0x12/0x20 [<c11b73b5>] ? pci_unregister_driver+0x35/0x90 [<fb586172>] ? ath_pci_exit+0x12/0x20 [ath9k] [<fb5883ec>] ? ath9k_exit+0x10/0x3d [ath9k] [<c131971d>] ? mutex_unlock+0xd/0x10 [<c1088c0f>] ? sys_delete_module+0x16f/0x220 [<c10e3d5d>] ? do_munmap+0x23d/0x290 [<c11a629c>] ? trace_hardirqs_off_thunk+0xc/0x10 [<c11a628c>] ? trace_hardirqs_on_thunk+0xc/0x10 [<c1003b41>] ? sysenter_exit+0xf/0x1a [<c1003b08>] ? sysenter_do_call+0x12/0x3c Code: Bad EIP value. EIP: [<46412d6b>] 0x46412d6b SS:ESP 0068:f6661ea8 CR2: 0000000046412d6b ---[ end trace 847f3b05ff3dcb19 ]--- Reported-by: NVasanthakumar Thiagarajan <vasanth@atheros.com> Signed-off-by: NLuis R. Rodriguez <lrodriguez@atheros.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Luis R. Rodriguez 提交于
The core driver needs to be stopped and then as a last step the hardware needs to be stopped and its structure free'd. We do this by moving the core driver cleanup to a new helper ath_clean_core() and have ath_cleanup() call it. Only as a last step does ath_cleanup() now free the hw. Signed-off-by: NLuis R. Rodriguez <lrodriguez@atheros.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Luis R. Rodriguez 提交于
This is used in several places, ensure we do it right in all callers by using a helper. Signed-off-by: NLuis R. Rodriguez <lrodriguez@atheros.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Luis R. Rodriguez 提交于
debugfs uses the hardware for several debugfs files as such the hardware must be initialized and available prior to its usage. The same applies to when we free the hw structs -- free debufs file entries prior to free'ing the hardware. Reported-by: NVasanthakumar Thiagarajan <vasanth@atheros.com> Signed-off-by: NLuis R. Rodriguez <lrodriguez@atheros.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Luis R. Rodriguez 提交于
What this means is we can enable now debug prints without requiring CONFIG_ATH9K_DEBUG. Signed-off-by: NLuis R. Rodriguez <lrodriguez@atheros.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 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>
-
由 Luis R. Rodriguez 提交于
Signed-off-by: NLuis R. Rodriguez <lrodriguez@atheros.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Luis R. Rodriguez 提交于
hw code for Atheros 802.11n hardware is commmon between different chipsets. This moves this code into a separate module, the next expected user of this code will be the ath9k_htc module. The ath9k/ dir is now selected by ATH9K_HW, an option which gets selected by either ath9k or ath9k_htc, but remains invisible for user menuconfig configuration. If either ath9k or ath9k_htc will be compiled into the kernel ath9k_hw will also be compiled in. Cc: Jouni Malinen <jouni.malinen@atheros.com> Signed-off-by: NLuis R. Rodriguez <lrodriguez@atheros.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Luis R. Rodriguez 提交于
PCI and debug code will not be shared between ath9k and ath9k_htc, so make that code use the common read/write ops. Signed-off-by: NLuis R. Rodriguez <lrodriguez@atheros.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Senthil Balasubramanian 提交于
* Get power table offset from the EEPROM instead of using a hardcoded value of -5 if the EEPROM rev is >= 21. * Add support in the 4k eeprom code for tx power offset in case we have a 4k AR9280 implementation. * Fix tx power accuracy at high powers. Signed-off-by: NSenthil Balasubramanian <senthilkumar@atheros.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Senthil Balasubramanian 提交于
This has to be done if the EEPROM supports FCC Midband capability. Signed-off-by: NSenthil Balasubramanian <senthilkumar@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>
-
由 Senthil Balasubramanian 提交于
Clearing a local variable is unnecessary. Get rid of it. Signed-off-by: NSenthil Balasubramanian <senthilkumar@atheros.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Senthil Balasubramanian 提交于
Signed-off-by: NSenthil Balasubramanian <senthilkumar@atheros.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
* Move 0xa274 and 0xa27c to the top of tx_gain table. * Update initvals to fix random failure of noise floor calibration. Signed-off-by: NVasanthakumar Thiagarajan <vasanth@atheros.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Sujith 提交于
For AR5416 chipsets, clearing RTC_RESET_EN when setting the chip to SLEEP mode results in high power consumption. This patch fixes this issue by not clearing it for AR5416. Signed-off-by: NSujith <Sujith.Manoharan@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>
-
由 Vivek Natarajan 提交于
* Prevent divide-by-zero errors in IQ Calibration. * Do not run temperature compensation if initPDADC or currPDADC is zero. * Also, introduce a separate function for handling OLC for AR9287. Signed-off-by: NVivek Natarajan <vnatarajan@atheros.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-