302408 |
08-Jul-2016 |
gjb |
Copy head@r302406 to stable/11 as part of the 11.0-RELEASE cycle. Prune svn:mergeinfo from the new branch, as nothing has been merged here.
Additional commits post-branch will follow.
Approved by: re (implicit) Sponsored by: The FreeBSD Foundation |
290612 |
09-Nov-2015 |
adrian |
ath(4): begin fleshing out a "reset type" extension to force cold/warn resets.
Right now the only way to force a cold reset is:
* The HAL itself detects it's needed, or * The sysctl, setting all resets to be cold.
Trouble is, cold resets take quite a bit longer than warm resets.
However, there are situations where a cold reset would be nice. Specifically, after a stuck beacon, BB/MAC hang, stuck calibration results, etc.
The vendor HAL has a separate method to set the reset reason (which is how HAL_RESET_BBPANIC gets set) which informs the HAL during the reset path why it occured. This is almost but not quite the same; I may eventually unify both approaches in the future.
This commit just extends HAL_RESET_TYPE to include both status (eg BBPANIC) and type (eg do COLD.) None of the HAL code uses it yet though; that'll come later.
It also is a big no-op in each HAL - I need to go teach each of the HALs about cold/warm reset through this path.
|
272292 |
30-Sep-2014 |
adrian |
Add initial support for the AR9485 CUS198 / CUS230 variants.
These variants have a few differences from the default AR9485 NIC, namely:
* a non-default antenna switch config; * slightly different RX gain table setup; * an external XLNA hooked up to a GPIO pin; * (and not yet done) RSSI threshold differences when doing slow diversity.
To make this possible:
* Add the PCI device list from Linux ath9k, complete with vendor and sub-vendor IDs for various things to be enabled; * .. and until FreeBSD learns about a PCI device list like this, write a search function inspired by the USB device enumeration code; * add HAL_OPS_CONFIG to the HAL attach methods; the HAL can use this to initialise its local driver parameters upon attach; * copy these parameters over in the AR9300 HAL; * don't default to override the antenna switch - only do it for the chips that require it; * I brought over ar9300_attenuation_apply() from ath9k which is cleaner and easier to read for this particular NIC.
This is a work in progress. I'm worried that there's some post-AR9380 NIC out there which doesn't work without the antenna override set as I currently haven't implemented bluetooth coexistence for the AR9380 and later HAL. But I'd rather have this code in the tree and fix it up before 11.0-RELEASE happens versus having a set of newer NICs in laptops be effectively RX deaf.
Tested:
* AR9380 (STA) * AR9485 CUS198 (STA)
Obtained from: Qualcomm Atheros, Linux ath9k
|
265112 |
30-Apr-2014 |
adrian |
* Only update ah_powerMode if we're setting the chip sleep state. Some code will appear soon that is actually setting the chip powerstate separate from the self-generated frames power state. * Allow the AR5416 family chips to actually have the power state changed from the self generated state change.
Tested (STA mode):
* AR5210 * AR5211 * AR5412 * AR5413 * AR5416 * AR9285
|
264899 |
24-Apr-2014 |
adrian |
Fix the AR5210 HAL code to store the association ID and restore it upon reset.
Tested:
* AR5210, STA mode
|
264898 |
24-Apr-2014 |
adrian |
Fix ah_powerMode to be set at the correct place for the AR5210.
Tested:
* AR5210, STA mode
|
262969 |
10-Mar-2014 |
adrian |
Migrate the chip power mode status to public ath_hal, rather than the private per-chip HAL.
This allows the ah_osdep.[ch] code to check whether the power state is valid for doing chip programming.
It should be a no-op for normal driver work but it does require a clean kernel/module rebuild, as the size of HAL structures have changed.
Now, this doesn't track whether the hardware is ACTUALLY awake, as NETWORK_SLEEP wakes the chip up for a short period when traffic is received. This doesn't actually set the power mode to AWAKE, so we have to be careful about how we touch things.
But it's enough to start down the path of implementing station mode chipset power savings, as a large part of the silliness is making sure the chip is awake during periodic calibration / ANI and random places where transmit may be occuring. I'd rather not a repeat of debugging power save on ath9k, where races with calibration and transmit path stuff took a couple years to shake out.
Tested:
* AR5416, STA mode
|
247286 |
25-Feb-2013 |
adrian |
Begin adding support to explicitly set the current chainmask.
Right now the only way to set the chainmask is to set the hardware configured chainmask through capabilities. This is fine for forcing the chainmask to be something other than what the hardware is capable of (eg to reduce TX/RX to one connected antenna) but it does change what the HAL hardware chainmask configuration is.
For operational mode changes, it (may?) make sense to separately control the TX/RX chainmask.
Right now it's done as part of ar5416_reset.c - ar5416UpdateChainMasks() calculates which TX/RX chainmasks to enable based on the operating mode. (1 for legacy and whatever is supported for 11n operation.) But doing this in the HAL is suboptimal - the driver needs to know the currently configured chainmask in order to correctly enable things for each TX descriptor. This is currently done by overriding the chainmask config in the ar5416 TX routines but this has to disappear - the AR9300 HAL support requires the driver to dynamically set the TX chainmask based on the TX power and TX rate in order to meet mini-PCIe slot power requirements.
So:
* Introduce a new HAL method to set the operational chainmask variables; * Introduce null methods for the previous generation chipsets; * Add new driver state to record the current chainmask separate from the hardware configured chainmask.
Part #2 of this will involve disabling ar5416UpdateChainMasks() and moving it into the driver; as well as properly programming the TX chainmask based on the currently configured HAL chainmask.
Tested:
* AR5416, STA mode - both legacy (11a/11bg) and 11n rates - verified that AR_SELFGEN_MASK (the chainmask used for self-generated frames like ACKs and RTSes) is correct, as well as the TX descriptor contents is correct.
|
243317 |
19-Nov-2012 |
adrian |
Disable WEP hardware encryption on the AR5210, in order to allow other encryption types.
The AR5210 only has four WEP key slots, in contrast to what the later MACs have (ie, the keycache.) So there's no way to store a "clear" key.
Even if the driver is taught to not allocate CLR key entries for the AR5210, the hardware will actually attempt to decode the encrypted frames with the (likely all 0!) WEP keys.
So for now, disable the hardware encryption entirely and just so it all in software. That allows both WEP -and- WPA to actually work.
If someone wishes to try and make hardware WEP _but_ software WPA work, they'll have to create a HAL capability to enable/disable hardware encryption based on the current STA/Hostap mode. However, making multi-vap work with one WEP and one WPA VAP will require hardware encryption to be disabled anyway.
|
243174 |
17-Nov-2012 |
adrian |
Correctly populate the RTS field.
Tested: * AR5210, STA mode, RTS enabled
|
243173 |
17-Nov-2012 |
adrian |
* Remove ah_desc.h, it's not needed * Add some shifts that I'm using in userspace (athalq.)
However, this exposes a fun little bug..
|
239643 |
24-Aug-2012 |
adrian |
Add default values for the NumTxMaps capability.
|
239051 |
05-Aug-2012 |
adrian |
Migrate the ath_hal_filltxdesc() API to take a list of buffer/seglen values.
The existing API only exposes 'seglen' (the current buffer (segment) length) with the data buffer pointer set in 'ds_data'. This is fine for the legacy DMA engine but it won't work for the EDMA engines.
The EDMA engine has a significantly different TX descriptor layout.
* The legacy DMA engine had a ds_data pointer at the same offset in the descriptor for both TX and RX buffers; * The EDMA engine has no ds_data for RX - the data is DMAed after the descriptor; * The EDMA engine has support for 4 TX buffer/segment pairs in the TX DMA descriptor; * The EDMA TX completion is in a different FIFO, and the driver will 'link' the status completion entry to a QCU by a "QCU ID". I don't know why it's just not filled in by the hardware, alas.
So given that, here are the changes:
* Instead of directly fondling 'ds_data' in ath_desc, change the ath_hal_filltxdesc() to take an array of buffer pointers as well as segment len pointers; * The EDMA TX completion status wants a descriptor and queue id. This (for now) uses bf_state.bfs_txq and will extract the hardware QCU ID from that. * .. and this is ugly and wasteful; it should change to just store the QCU in the bf_state and save 3/7 bytes in the process.
Now, the weird crap:
* The aggregate TX path was using bf_state->bfs_txq for the TXQ, rather than taking a function argument. I've tidied that up. * The multicast queue frames get put on a software TXQ and then that is appended to the hardware CABQ when appropriate. So for now, make sure that bf_state->bfs_txq points at the CABQ when adding frames to the multicast queue. * .. but the multicast queue TX path for now doesn't use the software queue and instead (a) directly sets up the descriptor contents at that point; (b) the frames on the vap->avp_mcastq are then just appended wholesale to the CABQ. So for now, I don't have to worry about making the multicast path work with aggregation or the per-TID software queue. Phew.
What's left to do:
* I need to modify the 11n ath_hal_chaintxdesc() API to do the same. I'll do that in a subsequent commit. * Remove bf_state.bfs_txq entirely and store the QCU as appropriate. * .. then do the runtime "is this going on the right HWQ?" checks using that, rather than comparing pointer values.
Tested on:
* AR9280 STA/AP * AR5416 STA/AP
|
238858 |
28-Jul-2012 |
adrian |
Flesh out the multi-rate retry capability.
The existing method for testing for MRR is to call the "SetupXTXDesc" HAL method and see if it returns AH_TRUE or AH_FALSE. This capability explicitly lists what number of multi-rate attempts are possible.
"1" means "one rate attempt supported".
|
238607 |
19-Jul-2012 |
adrian |
Break out the TX descriptor link field into HAL methods.
The DMA FIFO chips (AR93xx and later) differ slightly to th elegacy chips:
* The RX DMA descriptors don't have a ds_link field; * The TX DMA descriptors have a ds_link field however at a different offset.
This is a reimplementation based on what the reference driver and ath9k does.
A subsequent commit will enable it in the TX and beacon paths.
Obtained from: Linux ath9k, Qualcomm Atheros
|
238278 |
09-Jul-2012 |
adrian |
Extend the RX HAL API to include the RX queue identifier.
The AR93xx and later chips support two RX FIFO queues - a high and low priority queue.
For legacy chips, just assume the queues are high priority.
This is inspired by the reference driver but is a reimplementation of the API and code.
|
235972 |
25-May-2012 |
adrian |
oops - ath_hal_disablepcie is actually destined for another purpose, not to disable the PCIe PHY in prepration for reset.
Extend the enablepci method to have a "poweroff" flag, which if equal to true means the hardware is about to go to sleep.
|
235206 |
09-May-2012 |
adrian |
Add some empty DFS methods for AR5210/AR5211 for now, if DFS is enabled but these don't exist, the code panics.
I should really just add or use a DFS HAL capability before doing this, so the methods wouldn't be needed..
|
234873 |
01-May-2012 |
adrian |
Change the MIB cycle count API to return HAL_BOOL, rather than uint32_t, to return whether it was successful.
Add placeholder (blank) methods for previous chips, for both it and the 11n extension channel busy call.
|
234450 |
19-Apr-2012 |
adrian |
Stop using the hardware register value byte order swapping for now, at least until I can root cause what's going on.
The only platform I've seen this on is the AR9220 when attached to the AR71xx CPUs. I get immediate PCIe bus errors and all subsequent accesses cause further MIPS bus exceptions. I don't have any other big-endian platforms to test this on.
If I get a chance (or two), I'll try to whack this on a bus analyser and see exactly what happens.
I'd rather leave this on, especially for slower, embedded platforms. But the #ifdef hell is something I'm trying to avoid.
|
230791 |
30-Jan-2012 |
adrian |
Radar API related fixes.
* For legacy NICs, the combined RSSI should be used. For earlier AR5416 NICs, use control chain 0 RSSI rather than combined RSSI. For AR5416 > version 2.1, use the combined RSSI again.
* Add in a missing AR5212 HAL method (get11nextbusy) which may be called by radar code.
This serves no functional change for what's currently in FreeBSD.
|
228980 |
30-Dec-2011 |
dim |
Reapply r228785 now it has been tested by Adrian. Also add comments with the old AR_SCR_SLE_XXX values, with a short explanation why they were changed.
Reviewed by: adrian MFC after: 1 week
|
228799 |
22-Dec-2011 |
dim |
Revert r228785. We'll need to work around the warnings in another way.
Requested by: adrian MFC after: 1 week
|
228785 |
21-Dec-2011 |
dim |
Fix shift overflow problem in sys/dev/ath/ath_hal/ar5210/ar5210_power.c and sys/dev/ath/ath_hal/ar5211/ar5211_power.c:
sys/dev/ath/ath_hal/ar5210/ar5210_power.c:36:3: warning: signed shift result (0x200000000) requires 35 bits to represent, but 'int' only has 32 bits [-Wshift-overflow] OS_REG_RMW_FIELD(ah, AR_SCR, AR_SCR_SLE, AR_SCR_SLE_ALLOW); ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ sys/dev/ath/ath_hal/ah_internal.h:472:42: note: expanded from: (OS_REG_READ(_a, _r) &~ (_f)) | (((_v) << _f##_S) & (_f))) ^ sys/dev/ath/ah_osdep.h:127:49: note: expanded from: (bus_space_handle_t)(_ah)->ah_sh, (_reg), (_val)) ^~~~
The AR_SCR_SLE_{WAKE,SLP,NORM} values are pre-shifted in ar5210reg.h and ar5211reg.h, while they should be unshifted, like in ar5212reg.h. Then, when the OS_REG_RMW_FIELD() macro shifts them again, the values will overflow, becoming effectively zero.
MFC after: 1 week
|
225883 |
30-Sep-2011 |
adrian |
Fix a corner case in the HAL debugging changes, where ah was NULL.
Although I tried to fix this earlier by introducing HALDEBUG_G(), it turns out there seem to be other cases where the pointer value is still NULL.
* Fix DO_HALDEBUG() and the HALDEBUG macro to check whether ah is NULL before deferencing it * Remove HALDEBUG_G() as it's no longer needed
This is hopefully a merge candidate for 9.0-RELEASE as enabling debugging at startup could result in a kernel panic.
|
225444 |
08-Sep-2011 |
adrian |
Update the TSF and next-TBTT methods to work for the AR5416 and later NICs. This is another commit in a series of TDMA support fixes for the 11n NICs.
* Move ath_hal_getnexttbtt() into the HAL; write methods for it. This returns a timer value in TSF, rather than TU.
* Move ath_hal_getcca() and ath_hal_setcca() into the HAL too, where they likely now belong.
* Create a new HAL capability: HAL_CAP_LONG_RXDESC_TSF. The pre-11n NICs write 15 bit TSF snapshots into the RX descriptor; the AR5416 and later write 32 bit TSF snapshots into the RX descriptor. * Use the new capability to choose between 15 and 31 bit TSF adjustment functions in ath_extend_tsf().
* Write ar5416GetTsf64() and ar5416SetTsf64() methods. ar5416GetTsf64() tries to compensate for TSF changes at the 32 bit boundary.
According to yin, this fixes the TDMA beaconing on 11n chipsets and TDMA stations can now associate/talk, but there are still issues with traffic stability which need to be investigated.
The ath_hal_extendtsf() function is also used in RX packet timestamping; this may improve adhoc mode on the 11n chipsets. It also will affect the timestamps seen in radiotap frames.
Submitted by: Kang Yin Su <cantona@cantona.net> Approved by: re (kib)
|
223466 |
23-Jun-2011 |
adrian |
Re-introduce a global ath_hal_debug again for now, whilst I figure out what to do about the few cases where the HAL state isn't available (regdomain) or isn't yet setup (probe/attach.)
The global ath_hal_debug now affects all instances of the HAL.
This also restores the ability for probe/attach debugging to work; as the sysctl tree may not be attached at that point. Users can just set the global "hw.ath.hal.debug" to a suitable value to enable probe/attach related debugging.
|
223459 |
23-Jun-2011 |
adrian |
Break out most of the HAL related tweaks into a per-HAL instance, rather than global variables.
This specifically allows for debugging to be enabled per-NIC, rather than globally.
Since the ath driver doesn't know about AH_DEBUG, and to keep the ABI consistent regardless of whether AH_DEBUG is enabled or not, enable the debug parameter always but only conditionally compile in the debug methods if needed.
The ALQ support is currently still global pending some brainstorming.
Submitted by: ssgriffonuser@gmail.com Reviewed by: adrian, bschmidt
|
220324 |
04-Apr-2011 |
adrian |
Add a HAL capability bit for supporting self-linked RX descriptors and disable it for the 11n chipsets.
From the ath9k source:
==
11N: we can no longer afford to self link the last descriptor. MAC acknowledges BA status as long as it copies frames to host buffer (or rx fifo). This can incorrectly acknowledge packets to a sender if last desc is self-linked.
==
Since this is useful for pre-AR5416 chips that communicate PHY errors via error frames rather than by on-chip counters, leave the support in there, but disable it for AR5416 and later.
|
218436 |
08-Feb-2011 |
adrian |
There's apparently a bug with Merlin (AR9280) and later chipsets where putting descriptors (not buffers) across a 4k page boundary can cause issues. I've not seen it in production myself but it apparently can cause problems.
So, in preparation for addressing this workaround, (re)-expose the particular HAL capability bit which marks whether the chipset has support for cross-4k- boundary transactions or not.
A subsequent commit will modify the descriptor allocation to avoid allocating descriptor entries that straddle a 4k page boundary.
|
217684 |
21-Jan-2011 |
adrian |
ANI changes #1 - split out the ANI polling from the RxMonitor hook.
The rxmonitor hook is called on each received packet. This can get very, very busy as the tx/rx/chanbusy registers are thus read each time a packet is received.
Instead, shuffle out the true per-packet processing which is needed and move the rest of the ANI processing into a periodic event which runs every 100ms by default.
|
217624 |
20-Jan-2011 |
adrian |
Include the initial support for external EEPROMs.
The AR9100 at least doesn't have an external serial EEPROM attached to the MAC; it instead stores the calibration data in the normal system flash.
I believe earlier parts can do something similar but I haven't experienced it first-hand.
This commit introduces an eepromdata pointer into the API but doesn't at all commit to using it. A future commit will include the glue needed to allow the AR9100 support code to use this data pointer as the EEPROM.
|
217621 |
20-Jan-2011 |
adrian |
Add a new HAL method to retrieve the completion schedule. It sets the completion schedule from the hardware and returns AH_TRUE if the hardware supports multi-rate retries (AR5212 and above); and returns AH_FALSE if the hardware doesn't support multi-rate retries.
The sample rate module directly reads the TX completion descriptor and extracts the TX schedule information from that. It will be updated in a future commit to instead use this method to determine the completion schedule.
|
208643 |
29-May-2010 |
rpaulo |
Due to the way HALDEBUG() is defined, we need to add curly brackets when using it as a sole if clause instruction.
Submitted by: Arnaud Lacombe <alc@FreeBSD.org> MFC after: 1 week
|
204644 |
03-Mar-2010 |
rpaulo |
Replace Id keyword with FreeBSD keyword and set the svn props correctly. No functional change.
|
202161 |
12-Jan-2010 |
gavin |
Spell "Hz" correctly wherever it is user-visible.
PR: bin/142566 Submitted by: N.J. Mann njm njm.me.uk Approved by: ed (mentor) MFC after: 2 weeks
|
192397 |
19-May-2009 |
sam |
remove special handling for BNR; it is direct mapped to the harwdare so can be added to HAL_INT_COMMON except on the 5210 where it doesn't exist
|
192396 |
19-May-2009 |
sam |
add HAL_CAP_INTRMASK to return the set of interrupts supported by the device
|
191022 |
13-Apr-2009 |
sam |
o eliminate a << in calculating the tx time for turbo mode by pre-multiplying data in the phy tables o correct the ctrl rate indices in the 5212 turbog phy table
|
190096 |
19-Mar-2009 |
sam |
purge hal abi support; now that the hal is merged w/ the driver we cannot be out of sync
MFC after: 1 week
|
188979 |
24-Feb-2009 |
sam |
Add PCIE power control api: o add ah_configPCIE and ah_disablePCIE for drivers to configure PCIE power save operation (modeled after ath9k, may need changes) o add private state flag to indicate if device is PCIE (replaces private hack in 5212 code) o add serdes programming ini bits for 5416 and later parts and setup for each part (5416 and 9160 logic hand-crafted from existing routines); 5212 remains open-coded but is now hooked in via ah_configPCIE o add PCIE workaround gunk o add ar5416AttachPCIE for iodomatic code used by 5416 and later parts
|
188974 |
24-Feb-2009 |
sam |
5416 and later parts mux the gpio outputs; extend the api to include a signal type that's used to select the appropriate mux
|
188970 |
23-Feb-2009 |
sam |
remove private copies of gpio methods that were needed when the hal was an independent entity
|
187831 |
28-Jan-2009 |
sam |
Overhaul regulatory support: o remove HAL_CHANNEL; convert the hal to use net80211 channels; this mostly involves mechanical changes to variable names and channel attribute macros o gut HAL_CHANNEL_PRIVATE as most of the contents are now redundant with the net80211 channel available o change api for ath_hal_init_channels: no more reglass id's, no more outdoor indication (was a noop), anM contents o add ath_hal_getchannels to have the hal construct a channel list without altering runtime state; this is used to retrieve the calibration list for the device in ath_getradiocaps o add ath_hal_set_channels to take a channel list and regulatory data from above and construct internal state to match (maps frequencies for 900MHz cards, setup for CTL lookups, etc) o compact the private channel table: we keep one private channel per frequency instead of one per HAL_CHANNEL; this gives a big space savings and potentially improves ani and calibration by sharing state (to be seen; didn't see anything in testing); a new config option AH_MAXCHAN controls the table size (default to 96 which was chosen to be ~3x the largest expected size) o shrink ani state and change to mirror private channel table (one entry per frequency indexed by ic_devdata) o move ani state flags to private channel state o remove country codes; use net80211 definitions instead o remove GSM regulatory support; it's no longer needed now that we pass in channel lists from above o consolidate ADHOC_NO_11A attribute with DISALLOW_ADHOC_11A o simplify initial channel list construction based on the EEPROM contents; we preserve country code support for now but may want to just fallback to a WWR sku and dispatch the discovered country code up to user space so the channel list can be constructed using the master regdomain tables o defer to net80211 for max antenna gain o eliminate sorting of internal channel table; now that we use ic_devdata as an index, table lookups are O(1) o remove internal copy of the country code; the public one is sufficient o remove AH_SUPPORT_11D conditional compilation; we always support 11d o remove ath_hal_ispublicsafetysku; not needed any more o remove ath_hal_isgsmsku; no more GSM stuff o move Conformance Test Limit (CTL) state from private channel to a lookup using per-band pointers cached in the private state block o remove regulatory class id support; was unused and belongs in net80211 o fix channel list construction to set IEEE80211_CHAN_NOADHOC, IEEE80211_CHAN_NOHOSTAP, and IEEE80211_CHAN_4MSXMIT o remove private channel flags CHANNEL_DFS and CHANNEL_4MS_LIMIT; these are now set in the constructed net80211 channel o store CHANNEL_NFCREQUIRED (Noise Floor Required) channel attribute in one of the driver-private flag bits of the net80211 channel o move 900MHz frequency mapping into the hal; the mapped frequency is stored in the private channel and used throughout the hal (no more mapping in the driver and/or net80211) o remove ath_hal_mhz2ieee; it's no longer needed as net80211 does the calculation and available in the net80211 channel o change noise floor calibration logic to work with compacted private channel table setup; this may require revisiting as we no longer can distinguish channel attributes (e.g. 11b vs 11g vs turbo) but since the data is used only to calculate status data we can live with it for now o change ah_getChipPowerLimits internal method to operate on a single channel instead of all channels in the private channel table o add ath_hal_gethwchannel to map a net80211 channel to a h/w frequency (always the same except for 900MHz channels) o add HAL_EEBADREG and HAL_EEBADCC status codes to better identify regulatory problems o remove CTRY_DEBUG and CTRY_DEFAULT enum's; these come from net80211 now o change ath_hal_getwirelessmodes to really return wireless modes supported by the hardware (was previously applying regulatory constraints) o return channel interference status with IEEE80211_CHANSTATE_CWINT (should change to a callback so hal api's can take const pointers) o remove some #define's no longer needed with the inclusion of <net80211/_ieee80211.h>
Sponsored by: Carlson Wireless
|
187611 |
23-Jan-2009 |
sam |
fix return status handling by ar5XXXReset; this is the reason the driver sometimes reports reset failed w/ status 0
|
186333 |
19-Dec-2008 |
sam |
add FreeBSD property
|
185521 |
01-Dec-2008 |
sam |
import ath hal
|
185418 |
28-Nov-2008 |
sam |
add chip+rf names for debug msgs, showing compiled-in support, etc.
|
185406 |
28-Nov-2008 |
sam |
Replace most compile-time support options with linker sets for chip and RF backend support: o add OS_DATA_SET and OS_SET_DECLARE os requirements for setting up linker sets o add AH_CHIP macro for registering chip support (e.g. 5210) o add AH_RF macro for registering RF support (e.g. 2413); note this isn't required for single chip solutions where there's no ambiguity (e.g. 5416/9160+2133) but for 5212 class parts it's required because of the multi-chip solutions o remove all uses of AH_SUPPORT_AR5210, AH_SUPPORT_AR5211, AH_SUPPORT_5212, and AH_SUPPORT_AR9160; still need AH_SUPPORT_AR5416 to enable the 11n descriptor formats and 5312 support is presently broken o remove all uses of AH_SUPPORT_2133, AH_SUPPORT_2413, AH_SUPPORT_5111, AH_SUPPORT_5112, AH_SUPPORT_2417, AH_SUPPORT_2425, and AH_SUPPORT_5413; 5312-related support still requires fixup
Remaining issues: o fixup SoC attach o ath_hal_attach uses a hack to probe w/o access to the vendorid o fallback handling of parts w/o a macrev needs to be restored
|
185380 |
28-Nov-2008 |
sam |
Update to later code from my repository: o many bug fixes o add new periodic calibration api o break up 5416 periodic calibration code in preparation for 928x o move get noise floor to rf backends o 5416-specific ani (still disabled) o modularize 5210 eeprom format a la other eeprom formats o start cleaning up regdomain code o prepare for proper 1/2 and 1/4 width channel support o bring back 900MHz card support o clean up 5212 rf version handling o add 1/2 and 1/4 width channel support for 5212 parts o split 5212 rfgain handling out o improve ani debugging o add AH_USE_INIPDGAIN compile option o purge a bunch of dead 5212 state o add 1/2 and 1/4 rate modes o remove HAL_CAP_CHAN_HALFRATE and HAL_CAP_CHAN_QUARTERRATE; the same info can now be deduced from the set of supported modes
|
185377 |
28-Nov-2008 |
sam |
virgin import of ath hal
|