TX chainmask.
since the upper layers don't (yet) know about the active TX/RX chainmasks,
it can't tell the rate scenario functions what to use. I'll eventually sort
this out; this restores functionality in the meantime.
The higher levels (net80211, if_ath, ath_rate) need this to make correct
choices about what MCS capabilities to advertise and what MCS rates are
able to be TXed.
In summary:
* AR5416 - 2/3 antennas, 2x2 streams
* AR9160 - 2/3 antennas, 2x2 streams
* AR9220 - 2 antennas, 2x2 sstraems
* AR9280 - 2 antennas, 2x2 streams
* AR9285 - 2 antennas but with antenna diversity, 1x1 stream
After inspecting the ath9k source, it seems the AR5416 and later MACs
don't take an explicit RTS/CTS duration. A per-scenario (ie, what multi-
rate retry became) rts/cts control flag and packet duration is provided;
the hardware then apparently fills in whatever details are required.
The per-rate sp/lpack duration calculation just isn't used anywhere
in the ath9k TX packet length calculations.
The burst duration register controls something different; it seems to
be involved with RTS/CTS protection of 11n aggregate frames and is set
via a call to ar5416Set11nBurstDuration().
I've done some light testing with rts/cts protected frames and nothing
seems to break; but this may break said RTS/CTS and CTS-to-self protection.
Each different radio chipset has a different "good" range of CCA
(clear channel access) parameters where, if you write something
out of range, it's possible the radio will go deaf.
Also, since apparently occasionally reading the NF calibration
returns "wrong" values, so enforce those limits on what is being
written into the CCA register.
Write a default value if there's no history available.
This isn't the case right now but it may be later on when "off-channel"
scanning occurs without init'ing or changing the NF history buffer.
(As each channel may have a different noise floor; so scanning or
other off-channel activity shouldn't affect the NF history of
the current channel.)
* I messed up a couple of things in if_athvar.h; so fix that.
* Undo some guesswork done in ar5416Set11nRateScenario() and introduce a
flags parameter which lets the caller set a few things. To begin with,
this includes whether to do RTS or CTS protection.
* If both RTS and CTS is set, only do RTS. Both RTS and CTS shouldn't be
set on a frame.
This will eventually be used by rate control modules and by the TX
code for calculating packet duration when handling rts/cts protection.
Obtained from: sam@, rpaulo@, linux ath9k
The defaults enabled three chains on the AR5416 even if the card has two
chains. This restores that and ensures that only the correct TX/RX
chainmasks are used.
When HT modes are enabled, all TX chains will be correctly enabled.
This should now enable analog chain swapping with 2-chain cards.
I'm not sure if this is needed for just the AR5416 or whether
it also applies to AR9160, AR9280 and AR9287 (later on); I'll have
to get clarification.
This, along with an initval change which will appear in a subsequent commit,
fixes bus panics that I have been seing with the AR9220 on a Routerstation Pro
(AR7161 MIPS board.)
Obtained from: Linux ath9k
PR: kern/154220
ath9k does a few different things here during config - if it's an early
AR5416 with two chains, it enables all three chains for calibration and
then restores the chainmask to the original values after initial
calibration has completed.
The reason behind this commit is to begin breaking out the chainmask
configuration for this specific reason; follow-up commits will add
the chainmask restore in the ar5416Reset() routine.
* Re-do the structure size/component math to make sure the struct matches
the expected size
* Just to be clear that we care about bitmask ordering, revert my previous
change and instead define that macro if we're on big-endian.
It turns out that the V4K eeprom definitions (used by the AR9285 and
its derivatives) is wrong. These values are at least causing issues
on my AR2427.
With this fix (and initvals in a subsequent commit), the AR2427 behaves
a lot better.
Note - there's still significant drift between the ath9k v4k eeprom
init code (again, used by AR9285 and derivatives) and what's in this
tree. That needs to be investigated and resolved.
The linux ath9k driver and (from what I've been told) the atheros reference
driver does this; it then leaves discarding 11n frames to the 802.11 layer.
Whilst I'm here, merge in a fix from ath9k which maintains a turbo register
setting when enabling the 11n register; and remove an un-needed (duplicate)
flag setting.
The v1 and v3 interfaces returned the whole EEPROM but the v14/v4k
interfaces just returned the base header. There's extra information
outside of that which would also be nice to get access to.
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.
This is apparently an AR9285 with the 802.11n specific bits disabled.
This code is completely untested; I'm doing this in response to users
who wish to test the functionality out. It's likely as buggy as the
AR9285 support is in FreeBSD at the moment.
sys/dev/ath/ath_hal/ar5416/ is getting very crowded and further
commits will make it even more crowded. Now is a good time to
shuffle these files out before any more extensive work is done
on them.
Create an ar9003 directory whilst I'm here; ar9003 specific
chipset code will eventually live there.
with these ADC DC Gain/Offset calibrations.
The whole idea is to calibrate a pair of ADCs to compensate for any
differences between them.
The AR5416 returns lots of garbage, so there's no need to do the
calibration there.
The AR9160 returns 0 for secondary ADCs when calibrating 2.4ghz 20mhz
modes. It returns valid data for the secondary ADCs when calibrating
2.4ghz HT/40 and any 5ghz mode.
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.
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.
Since we now have the source code, there's no reason to hide the diag codes
from other areas.
They live in the HAL as they form part of the HAL API and should still be treate
as "potentially flexible; don't publish as a public API." But since they're
already used as a public API (see follow-up commit), we may as well use
them in place of magic constants.
If it does, don't then try reprogramming the NF "cap" values (ie
what values are the "maximum" value the NF can be) - instead,
just leave the current CCA value as the NF cap.
This was inspired by some similar work from ath9k. It isn't
a 100% complete solution (as there may be some reason where a
high NF CCA/cap is written, causing the baseband to stop thinking it
is able to transmit, leading to stuck beacon and interface reset)
which I'll investigate and look at fixing in a later commit.
Obtained from: Linux
AR5416 and later chipsets.
ath_hal_calibrateN() calls the HAL calibrateN function with rxchainmask=0x1.
This is not necessarily the case for AR5416 and later chipsets.
that generates a fatal bus trap. Normally, the chips are setup to do
128 byte DMA bursts, but when on this CPU, they can only safely due
4-byte DMA bursts due to this bug. Details of the exact nature of the
bug are sketchy, but some can be found at
https://forum.openwrt.org/viewtopic.php?pid=70060 on pages 4, 5 and 6.
There's a small performance penalty associated with this workaround,
so it is only enabled when needed on the Atheros AR71xx platforms.
Unfortunately, this condition is impossible to detect at runtime
without MIPS specific ifdefs. Rather than cast an overly-broad net
like Linux/OpenWRT dues (which enables this workaround all the time on
MIPS32 platforms), we put this option in the kernel for just the
affected machines. Sam didn't like this aspect of the patch when he
reviewed it, and I'd love to hear sane proposals on how to fix it :)
Reviewed by: sam@
o rename the new variables to comply with the naming scheme
o move the new variables to an AR5212 specific struct
o use ahp when available
o revert to previous ts_flags check
available today.
This card is a low power 802.11bgn that only does 11n rates up to MCS 7
(that's 65 Mbps in 20Mhz mode and 135 in 40Mhz mode).
802.11n is not yet supported, but will be in the future.
The driver still has a problem regarding to the setting of txpower on
the card, so don't expect good performance yet. After fixing this
problem, an MFC is possible.
Special thanks to iXsystems and S Smirnov <tonve at yandex.ru> for help
with the purchase of a netbook with this card.
Sponsored by: iXsystems, Inc.
This is needed by the upcoming AR9285 support.
Information on the layout gathered from Linux ath9k.
Not yet connected to the build.
Tested by: Eugeny Dzhurinsky
inbound data waiting on a filedescriptor, such as a pipe or a socket,
for instance by using select(2), poll(2), kqueue(2), ioctl(FIONREAD)
etc.
But we have no way of finding out if written data have yet to be
disposed of, for instance, transmitted (and ack'ed!) to some remote
host, or read by the applicantion at the far end of the pipe.
The closest we get, is calling shutdown(2) on a TCP socket in
non-blocking mode, but this has the undesirable sideeffect of
preventing future communication.
Add a complement to FIONREAD, called FIONWRITE, which returns the
number of bytes not yet properly disposed of. Implement it for
all sockets.
Background:
A HTTP server will want to time out connections, if no new request
arrives within a certain period after the last transmitted response
has actually been sent (and ack'ed).
For a busy HTTP server, this timeout can be subsecond duration.
In order to signal to a load-balancer that the connection is truly
dead, TCP_RST will be the preferred method, as this avoids the need
for a RTT delay for FIN handshaking, with a client which, surprisingly
often, no longer at the remote IP number.
If a slow, distant client is being served a response which is big
enough to fill the window, but small enough to fit in the socket
buffer, the write(2) call will return immediately.
If the session timeout is armed at that time, all bytes in the
response may not have been transmitted by the time it fires.
FIONWRITE allows the timeout to check that no data is outstanding
on the connection, before it TCP_RST's it.
Input & Idea from: rwatson
Approved by: re (kib)
o add HAL_CAP_BSSIDMATCH to identify parts that have the support for
disabling bssid match
o honor capability for set/get rx filter
o use HAL_CAP_BSSIDMATCH in driver to decide whether to use the bssid
match disable or fall back to promisc mode
Reviewed by: rpaulo
Approved by: re (rwatson)
o add 9280 attach that sets up ini, cal, etc.
o new rf backend for 9280 and later parts
o split ini setup and spur mitigation support out to methods
and provide 9280-specific support
o minor fixups to shared code to handle 9280-specific work
Obtained from: Atheros (ini values and some code)
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
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
o mark phy type to indicate 1/2 or 1/4-rate operation
o use phy type instead of channel attributes to identify 1/2 and 1/4-rate
operation
o general cleanup of code including move phy constants to ah_internal.h
Eventually this code should go away and we should use the net0211 equivalents.
guaranteed to initialize its two last arguments. Therefore, there is a
warning in the subsequent caller ar5416FillVpdTable(), which doesn't
initialize those arguments.
Change getLowerUpperIndex() to assign values to indexL and indexR even
in the case of assertion failure.
Submitted by: Pavel Roskin <proski@gnu.org>
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
down will cause a fault. Check the phy power state before possibly
reading from the bb, this can happen as ar5212Reset intentionally
calls ar5212GetRfgain before bringing the bb out of reset (but we
do it here and not in the caller to guard against other possible uses).
