#
5e32cd22 |
| 05-Jan-2016 |
stsp <stsp@openbsd.org> |
Remove the IEEE80211_NO_HT macro. Reduces ifdef spaghetti, enables 11n mode in bsd.rd, and might uncover some bugs. Suggested by tedu@ and deraadt@. ok sthen@ jasper@ deraadt@
|
#
0b3397be |
| 21-Oct-2013 |
stsp <stsp@openbsd.org> |
Write AR9485 initvals in the same order as Linux ath9k does. Verified by comparing register write traces. No currently working athn(4) devices are affected by this change.
|
#
c8971d2a |
| 20-Oct-2012 |
stsp <stsp@openbsd.org> |
Init values for the AR9485 were for version 1.0 of this chip, which according to Atheros Linux developers was never sold. So update initvals to what Linux is using for the 1.1 generation. Because the
Init values for the AR9485 were for version 1.0 of this chip, which according to Atheros Linux developers was never sold. So update initvals to what Linux is using for the 1.1 generation. Because the serdes values are written to different registers on the AR9485 this involves tweaking the serdes init code for all athn(4) chip families. This commit doesn't make AR9485 devices work yet but is a step in the right direction.
Tested by krw, kettenis, and Andrew Ngo. ok kettenis@
show more ...
|
#
67a3f4d7 |
| 20-Oct-2012 |
stsp <stsp@openbsd.org> |
Fix hardware kill switch detection for the ar9300 chip family. The driver was checking the wrong bits of eeprom to determine rfkill switch pin and polarity, and was reading the wrong register to dete
Fix hardware kill switch detection for the ar9300 chip family. The driver was checking the wrong bits of eeprom to determine rfkill switch pin and polarity, and was reading the wrong register to determine rfkill gpio pin state. ok kettenis@
show more ...
|
#
328b15b2 |
| 10-Jun-2012 |
kettenis <kettenis@openbsd.org> |
Allow a variable number of words for the Serializer/Deserializer programming. Probably not enought to make the AR9380 chips to work, but at least the kernel shouldn't crash anymore when we see one.
Allow a variable number of words for the Serializer/Deserializer programming. Probably not enought to make the AR9380 chips to work, but at least the kernel shouldn't crash anymore when we see one.
ok stsp@
show more ...
|
#
4796a19f |
| 01-Jan-2011 |
damien <damien@openbsd.org> |
more AR9380/AR9485 bits. add Tx gain initvals for high-power AR9380 solutions.
|
#
3a686414 |
| 01-Jan-2011 |
damien <damien@openbsd.org> |
add code to read OTPROM on the AR9485
|
#
44176b8e |
| 31-Dec-2010 |
damien <damien@openbsd.org> |
limit the number of Tx chains used on some 3-stream AR9380 chips for MCS0~15 to not exceed the PCIe power requirements.
|
#
faa8804c |
| 31-Dec-2010 |
damien <damien@openbsd.org> |
Fix conformance test limit values in default AR9380 rom images.
|
#
7016ea4f |
| 31-Dec-2010 |
damien <damien@openbsd.org> |
add initvals for the AR9271. add initvals for the AR9485. update initvals for the AR9380 2.2 (from ath9k): "reduce the likelihood of false pulse detects in the hardware" "improve carrier leak
add initvals for the AR9271. add initvals for the AR9485. update initvals for the AR9380 2.2 (from ath9k): "reduce the likelihood of false pulse detects in the hardware" "improve carrier leak calibration/correction"
show more ...
|
#
e7e15635 |
| 10-Nov-2010 |
damien <damien@openbsd.org> |
Several updates for the Osprey (AR9380): - Add the different ROM templates for the different chips - Fix AR_PHY_65NM_CH0_TOP_XPABIASLVL definition - Apply attenuation settings from the ROM
|
#
817b7f48 |
| 19-Oct-2010 |
damien <damien@openbsd.org> |
update initialization values for the Osprey 2.2. see http://marc.info/?l=linux-wireless&m=128746728412954&w=2 for a list of changes.
|
#
7a0ab6fa |
| 18-Oct-2010 |
damien <damien@openbsd.org> |
remove v2.0 initialization values for the Osprey. this is a pre-production chip.
|
#
120ae0d6 |
| 20-Jun-2010 |
damien <damien@openbsd.org> |
update AR9380 ROM layout (add PA predistortion related fields.)
|
#
31a383f5 |
| 20-Jun-2010 |
damien <damien@openbsd.org> |
update 5GHz Tx gain tables for the Osprey (AR9380).
|
#
79bc8a8e |
| 13-May-2010 |
damien <damien@openbsd.org> |
initialization values for AR9380 2.2. turns out the Rx gain tables are the same as 2.0 (and the Tx gain registers too), which saves us a few bytes.
|
#
97bf8fdc |
| 11-May-2010 |
damien <damien@openbsd.org> |
enable fast PLL clock for 5GHz on AR9280 >=2.0 (unless EEPROM says the opposite) and on AR9380 2.0.
tested on my AR9280 2.1 with a NETGEAR WNHDE111 AP.
|
#
9a51ad34 |
| 11-May-2010 |
damien <damien@openbsd.org> |
various AR9003 fixes (found during code inspection): - the ROM deviceCap field is now 8 bits (instead of 16), so the number of entries in the key cache is always 0; just use the default value. - AR
various AR9003 fixes (found during code inspection): - the ROM deviceCap field is now 8 bits (instead of 16), so the number of entries in the key cache is always 0; just use the default value. - AR_CR_RXE is equal to 0 on AR9003. - do not use ``m'' unititialized in ar9003_rx_process. - if an Rx descriptor is not valid (bad signature), skip it instead of leaving it at the head of the FIFO. - update the Rx software descriptor with new virtual and physical address of Rx descritor when mapping a new buffer.
show more ...
|
#
5577ea7d |
| 11-May-2010 |
damien <damien@openbsd.org> |
update initvals for AR9380 2.0. see http://marc.info/?l=linux-wireless&m=127354213505700&q=raw for the list of changes.
|
#
c773697c |
| 10-May-2010 |
damien <damien@openbsd.org> |
misplaced #endif
|
#
bd6ea91d |
| 10-May-2010 |
damien <damien@openbsd.org> |
athn(4) is going to support a new family of Atheros 802.11n chips (AR9003), which differs from the currently supported families (AR5008, AR9001 and AR9002).
The main differences (from a driver point
athn(4) is going to support a new family of Atheros 802.11n chips (AR9003), which differs from the currently supported families (AR5008, AR9001 and AR9002).
The main differences (from a driver point of view) are:
* DMA: Tx and Rx descriptors have changed. A single Tx descriptor can now reference up to 4 scatter/gather DMA segments. There is now a DMA ring for reporting Tx status with separate Tx status descriptors (this ring is used to report Tx status for all the Tx FIFOs). Rx status descriptors are now put at the beginning of Rx buffers and do not need to be allocated separately from buffers. There are two Rx FIFOs (low priority and high priority) instead of one.
* ROM: The AR9003 family uses OTP-ROM instead of EEPROM. Reading the ROM is totally insane since vendors can provide only the chunks of ROM that differ from a default image (and thus the default image has to be stored in the driver). This is referenced as "compressed ROM" in the Linux driver, though there is no real compression involved, at least for the moment.
* PHY registers: All PHY registers have changed. Some registers offsets do not fit on 16 bits anymore, but since they are 32-bit aligned, we can still make them fit on 16 bits to save .rodata space in initialization tables.
* MAC registers: Some MAC registers offsets have changed (GPIO, interrupt masks) which is quite annoying (though ~98% remain the same.)
* Initialization values: Initialization values are now split in mac/soc/bb/radio blocks and pre/core/post phases in the Linux driver. I have chosen to not go that road and merge these blocks in modal and non-modal initialization values (similar to the other families). The initialization order remains exactly the same as the Linux driver though.
To manage these differences, I have split athn.c in two backends: ar5008.c contains the bits that are specific to the AR5008, AR9001 and AR9002 families (used by ar5416.c, ar9280.c, ar9285.c and ar9287.c) and that were previously in athn.c.
ar9003.c contains the bits that are specific to the new AR9003 family (used by ar9380.c only for now.)
I have introduced a thin hardware abstraction layer (actually a set of pointers to functions) that is used in athn.c. My intent is to keep this abstraction layer as thin as possible and not to create another ugly pile of abstraction layers a la MadWifi.
I think I've managed to keep things sane, probably at the expense of duplicating some code in both ar5008.c and ar9003.c, but at least we do not have to dig through layers and layers of virtual descriptors to figure out what is mapped to the hardware.
Tested for non-regression on various AR5416 (sparc64+i386), AR9281 and AR9285 (i386 only) adapters. AR9380 part is not tested (hardware is not available to the general public yet).
Committed over my AR9285 2.0.
show more ...
|