by default.
Adventourous souls with an AR9220/AR9280 or later and who have a device
that sends PS-POLL frames may wish to try tinkering with this option and
get back to me.
Linux ath9k only enables this for AR9280 and later NICs; so
create a capability for it so it isn't enabled for earlier
NICs.
Enabling hardware PS-POLL support will come in a later commit
and will be disabled by default.
Even though they map to setting the error filter register,
ath9k also writes them untouched to AR_RX_FILTER.
The Force-BSSID match bit can stay high, as it maps to a
misc mode register setting rather than an RX filter bit.
The phyerr, radar and bssid-match bits aren't real bits, they map
to enabling bits in other registers. Move those out of the way of
valid RX filter bits.
Add a few new fields from ath9k - compba, ps-poll, mcast-bcast-all.
Changes since 7.8.0 (from the official changelog):
- Fixed sporadic interrupt generation for associated CQ when processing
a local invalidate work request
- Changes to core scheduling to avoid starving requests from the host
under heavy RDMA Read Request load (e.g. packets to the wire)
- Programmed the tp tx resource limiter in function of the traffic (only
affects iWarp)
- Increased the egress NIC gather list length from 36 to 46 entries
MFC after: 1 week
the channel width is ni->ni_chw, which is set to the negotiated channel
width. ni->ni_htflags is the capability, rather than the negotiated
value.
Teach both the TX path and the sample rate module about this.
This seems to work fine for STA but not HT/20 AP mode.
Further discussion with net80211 people will need to take place
to ensure that the right flags are set based on the negotiated
capabilities of the remote peer, rather than whatever the local
parameters are.
Sending short-gi frames in 20mhz may work on some chips but
it certainly isn't supported on anything currently supported
by the HAL; and sending HT40 frames in HT20 mode just plain
won't work.
settings, it seems that our defines are backwards and don't match what
is in the EEPROM documentation or internal driver.
The ath9k code used to have a bitfield here, rather than a uint8_t, and
there were #defines used to swap the order based on the endian of the
platform - this wasn't because of nybble or bit ordering of the
underlying host but because of what the compiler was doing.
This may be the reason for the backwards field numbers, as ath9k had
similar issues.
the AR9285 so I'll leave it off for that.
Ath9k sources indiciate that one of the ANI modes interferes with
RIFS detection, so match ath9k and disable that.
* 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.
queue has its own interrupt. If the exact number that we need is not a
power of 2 and we're using MSI, then switch to interrupt multiplexing.
While here, replace the magic numbers with something more readable.
MFC after: 3 days
At least one AR5416 user has reported measurable throughput drops
with this option. For now, disable it and make it a run-time
twiddle. It won't take affect until the next radio programming
trip though (eg channel scan, channel change.)
so there's no need to enable the RX of invalid frames just to do ANI.
The if_ath code and AR5212 ANI code setup the RX filter bits to enable
receiving OFDM/CCK errors if the device doesn't have the hardware
MIB counters. It isn't initialising it for the AR5416+ because all of
those chips have hardware MIB counters.
This fixes the odd (and performance affecting!) situation where if ani
is enabled (via sysctl dev.ath.X.intmit) then suddenly there's be a very
large volume of phy errors - which is good to track, but not what was
intended. Since each PHY error is a received (0 length) frame, it can
significantly tie up the RX side of things.
It's still not ready for prime-time - there's some TX niggles with these 11n
cards that I'm still trying to wrap my head around, and AMPDU-TX is just not
implemented so things will come to a crashing halt if you're not careful.
"extended capabilities" to refer to the new set of capability structures
starting at offset 0x100 in config space for PCI-express devices. For now
both function names will still work. I will merge this to older branches
to ease driver portability, but 9.0 will ship with a new pci_find_extcap()
function that locates extended capabilities instead.
Reviewed by: imp
MFC after: 1 week
This fix modifies the const addac initval array, rather than modifying
a local copy. It means that running >1 AR9160 on a board may prove to
be unpredictable.
The AR5416 init path also does something similar, so supporting
>1 AR5416 of different revisions could cause problems.
The later fix will be to create a private copy of the Addac data
for the AR5416, AR9160 (and AR9100 when it's merged in) and then
modify that as needed.
Obtained From: Linux ath9k
I found this when trying to figure out why the RX PHY error count
didn't match the OFDM error count ANI was using. It turns out
there was two problems:
* What this commit addresses - using the wrong mask for OFDM errors,
and
* The RX filter is set incorrectly after a channel scan (at least)
even if interference mitigation is enabled by default.
ANI is still disabled by default for the AR5416 and later chips.
bring it in line with the rest of the register initialisation.
I've verified that the 2/5ghz board values written to the
chip match what was previously written.
* add pspoll/uapsd queue setup defaults;
* enable the exponential backoff window rather than the random
backoff window when doing TX contention management.
would be a problem, make sure it isn't overwritten by whatever is in
there at cold reset.
This brings the > ar5416 init path treatment of AR_MISC_MODE.
report descriptor information, sysctl utility
will show it for us.
- Modify sysctl node description to make it more
understanable.
Found by: Alexander Best <arundel@freebsd.org>
Submitted by: Eygene Ryabinkin <rea@freebsd.org>
MFC after: 14 days
Approved by: thompsa (mentor)
value is updated after that we read it in the queue-head. This patch can
fix problems with BULK timeouts. The issue was found on a Nvidia chipset.
MFC after: 14 days
Approved by: thompsa (mentor)
