#
285830 |
|
23-Jul-2015 |
gjb |
- Copy stable/10@285827 to releng/10.2 in preparation for 10.2-RC1 builds. - Update newvers.sh to reflect RC1. - Update __FreeBSD_version to reflect 10.2. - Update default pkg(8) configuration to use the quarterly branch.[1]
Discussed with: re, portmgr [1] Approved by: re (implicit) Sponsored by: The FreeBSD Foundation |
#
256281 |
|
10-Oct-2013 |
gjb |
Copy head (r256279) to stable/10 as part of the 10.0-RELEASE cycle.
Approved by: re (implicit) Sponsored by: The FreeBSD Foundation
|
#
247030 |
|
20-Feb-2013 |
adrian |
If any of the TX queues have underrun reporting enabled, enable HAL_INT_TXURN in the interrupt mask register.
This should now allow for TXURN interrupts to be posted.
|
#
234088 |
|
10-Apr-2012 |
adrian |
Squirrel away the SYNC interrupt in case we're doing interrupt debugging.
|
#
233900 |
|
04-Apr-2012 |
adrian |
Track and optionally log the actual sync interrupt cause.
These are involved in tracking host interface issues (ie, PCI/PCIe/AHB interface.)
|
#
227365 |
|
08-Nov-2011 |
adrian |
Fix the KTR option to compile by default - it was referencing some unmerged interrupt status debugging code from my branch.
* Add ah_intrstate[8] which will have the record of the last call to ath_hal_getintr(). * Wrap the KTR code behind ATH_KTR_INTR_DEBUG. * Add the HAL interrupt debugging behind AH_INTERRUPT_DEBUGGING.
This is only done for the AR5416 and later NICs but it will be trivial to add to the earlier NICs if required.
Neither are enabled by default, although to minimise HAL binary API differences, the ah_intrstate[] array is always compiled into the ath_hal struct.
|
#
225925 |
|
02-Oct-2011 |
adrian |
Various interrupt handling and RX interrupt mitigation fixes.
* The AR_ISR_RAC interrupt processing method has a subtle bug in all the MAC revisions (including pre-11n NICs) until AR9300v2. If you're unlucky, the clear phase clears an update to one of the secondary registers, which includes TX status.
This shows up as a "watchdog timeout" if you're doing very low levels of TX traffic. If you're doing a lot of non-11n TX traffic, you'll end up receiving a TX interrupt from some later traffic anyway.
But when TX'ing 11n aggregation session traffic (which -HEAD isn't yet doing), you may find that you're only able to TX one frame (due to BAW restrictions) and this may end up hitting this race condition.
The only solution is to not use RAC and instead use AR_ISR and the AR_ISR_Sx registers. The bit in AR_ISR which represents the secondary registers are not cleared; only the AR_ISR_Sx bits are. This way any updates which occur between the read and subsequent write will stay asserted and (correctly) trigger a subsequent interrupt.
I've tested this on the AR5416, AR9160, AR9280. I will soon test the AR9285 and AR9287.
* The AR_ISR TX and RX bits (and all others!) are set regardless of whether the contents of the AR_IMR register. So if RX mitigation is enabled, RXOK is going to be set in AR_ISR and it would normally set HAL_INT_RX.
Fix the code to not set HAL_INT_RX when RXOK is set and RX mitigation is compiled in. That way the RX path isn't prematurely called.
I would see:
* An interrupt would come in (eg a beacon, or TX completion) where RXOK was set but RXINTM/RXMINT wasn't; * ath_rx_proc() be called - completing RX frames; * RXINTM/RXMINT would then fire; * ath_rx_proc() would then be called again but find no frames in the queue.
This fixes the RX mitigation behaviour to not overly call ath_rx_proc().
* Start to flesh out more correct timer interrupt handling - it isn't kite/merlin specific. It's actually based on whether autosleep support is enabled or not.
This is sourced from my 11n TX branch and has been tested for a few weeks.
Finally, the interrupt handling change should likely be implemented for AR5210, AR5211 and AR5212.
|
#
225921 |
|
02-Oct-2011 |
adrian |
Disable TX interrupt mitigation just for the time being.
There are some timing concerns which I've yet to fully map out. In any case, there's an existing software driven mitigation method for TX interrupts and when TX'ing 11n frames, the whole frame itself generates an interrupt rather then the subframes.
|
#
221163 |
|
28-Apr-2011 |
adrian |
Introduce AR9130 (HOWL) WMAC support to the FreeBSD HAL.
The AR9130 is an AR9160/AR5416 family WMAC which is glued directly to the AR913x SoC peripheral bus (APB) rather than via a PCI/PCIe bridge.
The specifics:
* A new build option is required to use the AR9130 - AH_SUPPORT_AR9130. This is needed due to the different location the RTC registers live with this chip; hopefully this will be undone in the future. This does currently mean that enabling this option will break non-AR9130 builds, so don't enable it unless you're specifically building an image for the AR913x SoC.
* Add the new probe, attach, EEPROM and PLL methods specific to Howl.
* Add a work-around to ah_eeprom_v14.c which disables some of the checks for endian-ness and magic in the EEPROM image if an eepromdata block is provided. This'll be fixed at a later stage by porting the ath9k probe code and making sure it doesn't break in other setups (which my previous attempt at this did.)
* Sprinkle Howl modifications throughput the interrupt path - it doesn't implement the SYNC interrupt registers, so ignore those.
* Sprinkle Howl chip powerup/down throughout the reset path; the RTC methods were
* Sprinkle some other Howl workarounds in the reset path.
* Hard-code an alternative setup for the AR_CFG register for Howl, that sets up things suitable for Big-Endian MIPS (which is the only platform this chip is glued to.)
This has been tested on the AR913x based TP-Link WR-1043nd mode, in legacy, HT/20 and HT/40 modes.
Caveats:
* 2ghz has only been tested. I've not seen any 5ghz radios glued to this chipset so I can't test it.
* AR5416_INTERRUPT_MITIGATION is not supported on the AR9130. At least, it isn't implemented in ath9k. Please don't enable this.
* This hasn't been tested in MBSS mode or in RX/TX block-aggregation mode.
|
#
220966 |
|
23-Apr-2011 |
adrian |
Fix a corner-case of interrupt handling which resulted in potentially spurious (and fatal) interrupt errors.
One user reported seeing this:
Apr 22 18:04:24 ceres kernel: ar5416GetPendingInterrupts: fatal error, ISR_RAC 0x0 SYNC_CAUSE 0x2000
SYNC_CAUSE of 0x2000 is AR_INTR_SYNC_LOCAL_TIMEOUT which is a bus timeout; this shouldn't cause HAL_INT_FATAL to be set.
After checking out ath9k, ath9k_ar9002_hw_get_isr() clears (*masked) before continuing, regardless of whether any bits in the ISR registers are set. So if AR_INTR_SYNC_CAUSE is set to something that isn't treated as fatal, and AR_ISR isn't read or is read and is 0, then (*masked) wouldn't be cleared. Thus any of the existing bits set that were passed in would be preserved in the output.
The caller in if_ath - ath_intr() - wasn't setting the masked value to 0 before calling ath_hal_getisr(), so anything that was present in that uninitialised variable would be preserved in the case above of AR_ISR=0, AR_INTR_SYNC_CAUSE != 0; and if the HAL_INT_FATAL bit was set, a fatal condition would be interpreted and the chip was reset.
This patch does the following:
* ath_intr() - set masked to 0 before calling ath_hal_getisr(); * ar5416GetPendingInterrupts() - clear (*masked) before processing continues; so if the interrupt source is AR_INTR_SYNC_CAUSE and it isn't fatal, the hardware isn't reset via returning HAL_INT_FATAL.
This doesn't fix any underlying errors which trigger AR_INTR_SYNC_LOCAL_TIMEOUT - which is a bus timeout of some sort - so that likely should be further investigated.
|
#
220779 |
|
18-Apr-2011 |
adrian |
Rework the Global TX timeout handling to look more like ath9k.
It correctly now sets the AR_IMR BCNMISC register, along with the GTT register in AR_IMR_S2.
|
#
220188 |
|
31-Mar-2011 |
adrian |
Introduce AH_AR5416_INTERRUPT_MITIGATION which enables interrupt mitigation for the AR5416 and later. Rename the older HAL option to use this.
|
#
219975 |
|
25-Mar-2011 |
adrian |
Bring over interrupt mitigation changes from ath9k.
* The existing interrupt mitigation code didn't mitigate anything - the per-packet TX/RX interrupts are still occuring. It's possible this worked for the AR5416 but not any later chipsets; I'll investigate and update as needed.
* Set both the RX and TX threshold registers whilst I'm at it.
This is verified to work on the AR9220 and AR9160. I'm leaving it off by default in case it's truely broken, but I need to have it enabled when doing 11n testing or interrupt loads exceed 10,000 interrupts/sec.
|
#
208711 |
|
01-Jun-2010 |
rpaulo |
Bring in a couple of fixes from the Linux ath9k related to chip hangs. While there, try to make the register write pattern look like what's done by ath9k.
MFC after: 3 days
|
#
201758 |
|
07-Jan-2010 |
mbr |
Remove extraneous semicolons, no functional changes.
Submitted by: Marc Balmer <marc@msys.ch> MFC after: 1 week
|
#
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
|
#
191864 |
|
06-May-2009 |
sam |
add support for the Beacon Not Ready (BNR) interrupt (available on 5211 and later)
|
#
188976 |
|
24-Feb-2009 |
sam |
Fill in gpio support for 5416 and later parts: o add output mux support o gpio pin count is chip-dependent o 9280 and 9285 do input handling different o hookup gpio interrupts o no need to save/restore soft led state around reset
|
#
186333 |
|
19-Dec-2008 |
sam |
add FreeBSD property
|
#
185521 |
|
01-Dec-2008 |
sam |
import ath hal
|
#
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
|
#
185377 |
|
28-Nov-2008 |
sam |
virgin import of ath hal
|