| 345636 |
28-Mar-2019 |
avos |
MFC r344990:
Fix ieee80211_radiotap(9) usage in wireless drivers:
- Alignment issues:
* Add missing __packed attributes + padding across all drivers; in
most places there was an assumption that padding will be always
minimally suitable; in few places - e.g., in urtw(4) / rtwn(4) -
padding was just missing.
* Add __aligned(8) attribute for all Rx radiotap headers since they can
contain 64-bit TSF timestamp; it cannot appear in Tx radiotap headers, so
just drop the attribute here. Refresh ieee80211_radiotap(9) man page
accordingly.
- Since net80211 automatically updates channel frequency / flags in
ieee80211_radiotap_chan_change() drop duplicate setup for these fields
in drivers. |
| 345635 |
28-Mar-2019 |
avos |
MFC r306049:
net80211: remove IEEE80211_RADIOTAP_TSFT field from transmit definitions.
This field may be used for received frames only. |
| 343493 |
27-Jan-2019 |
avos |
MFC r306323:
[ath_hal] Add FCC6_FCCA regulatory domain (0x0014).
PR: 194336
Requested by: Chris Hutchinson <portmaster@bsdforge.com> |
| 337951 |
17-Aug-2018 |
kevans |
MFC r337570-r337573
r337570:
bwi(4): Set ic->ic_softc before bwi_getradiocaps to avoid bad deref
r337571:
net80211: Drain ageq before cleaning it up.
The comment above ieee80211_ageq_cleanup specifically notes that the queue
is assumed to be empty, and in order to make it so, ieee80211_ageq_drain
must be used.
r337572:
ieee8021_node: fix whitespace issues
r337573:
ath: Minor style cleanups
device_printf => DPRINTF and two whitespace adjustments |
| 332303 |
08-Apr-2018 |
emaste |
MFC ath(4) potential memory disclosure fixes
[1] r327499: ath: fix memory disclosure from ath_btcoex_ioctl
The ath_btcoex_ioctl handler allocated a buffer without M_ZERO and
returned it to userland without writing to it.
The device has permissions only for root so this is not urgent, and the
fix can be MFCd and considered for a future EN.
[2] r327500: ath: fix possible memory disclosures in ioctl handlers
Apply the fix from r327499 to additional ioctl handlers.
[3] r327529: ath: fix possible memory disclosure in ioctl handler
Submitted by: Domagoj Stolfa <domagoj.stolfa@gmail.com> [1,3]
Reported by: Ilja van Sprundel <ivansprundel@ioactive.com> [1,2]
Reviewed by: adrian [1]
Sponsored by: The FreeBSD Foundation |
| 332288 |
08-Apr-2018 |
brooks |
MFC r331797:
Use an accessor function to access ifr_data.
This fixes 32-bit compat (no ioctl command defintions are required
as struct ifreq is the same size).
Reviewed by: kib
Obtained from: CheriBSD
Sponsored by: DARPA, AFRL
Differential Revision: https://reviews.freebsd.org/D14900 |
| 331722 |
29-Mar-2018 |
eadler |
Revert r330897:
This was intended to be a non-functional change. It wasn't. The commit
message was thus wrong. In addition it broke arm, and merged crypto
related code.
Revert with prejudice.
This revert skips files touched in r316370 since that commit was since
MFCed. This revert also skips files that require $FreeBSD$ property
changes.
Thank you to those who helped me get out of this mess including but not
limited to gonzo, kevans, rgrimes.
Requested by: gjb (re) |
| 330897 |
14-Mar-2018 |
eadler |
Partial merge of the SPDX changes
These changes are incomplete but are making it difficult
to determine what other changes can/should be merged.
No objections from: pfg |
| 330446 |
05-Mar-2018 |
eadler |
MFC r327231,r327232:
kernel: Fix several typos and minor errors
lib: Fix several typos and minor errors
- duplicate words
- typos
- references to old versions of FreeBSD |
| 305614 |
08-Sep-2016 |
pfg |
MFC r303891, r303892:
sys: replace comma with semicolon when pertinent.
Uses of commas instead of a semicolons can easily go undetected. The comma
can serve as a statement separator but this shouldn't be abused when
statements are meant to be standalone. |
| 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 |
| 302392 |
07-Jul-2016 |
adrian |
[ath] obey the short-GI vap config flag when transmitting.
This makes 'ifconfig wlanX -shortgi' work correctly.
Tested:
* AR9380, STA mode
Approved by: re (gjb)
|
| 302100 |
23-Jun-2016 |
adrian |
[ath] fix comments!
I keep asking myself "what do these fields mean" and so now I've clarified
it for myself.
Tested:
* Reading the comments, going "a-ha!" a couple times.
Approved by: re (gjb)
|
| 302060 |
21-Jun-2016 |
adrian |
[ath] fix TX throughput for EDMA chips by pushing more into the TX FIFO.
It turns out that getting decent performance requires stacking the TX
FIFO a little more aggressively.
* Ensure that when we complete a frame, we attempt to push a new frame
into the FIFO so TX is kept as active as it needs to be
* Be more aggressive about batching non-aggregate frames into a single
TX FIFO slot. This "fixes" TDMA performance (since we only get one
TX FIFO slot ungated per DMA beacon alert) but it does this by pushing
a whole lot of work into the TX FIFO slot.
I'm not /entirely/ pleased by this solution, but it does fix a whole bunch
of corner case issues in the transmit side and fix TDMA whilst I'm at it.
I'll go revisit transmit packet scheduling in ath(4) post 11.
Tested:
* AR9380, STA mode
* AR9580, hostap mode
* AR9380, TDMA client mode
Approved by: re (hrs)
|
| 302024 |
20-Jun-2016 |
adrian |
[ath] fix EDMA TX buffer flags for use when retransmitting frames.
This started showing up when doing lots of aggregate traffic. For TDMA it's
always no-ACK traffic and I didn't notice this, and I didn't notice it
when doing 11abg traffic as it didn't fail enough in a bad way to trigger
this.
This showed up as the fifo depth being < 0.
Eg:
Jun 19 09:23:07 gertrude kernel: ath0: ath_tx_edma_push_staging_list: queued 2 packets; depth=2, fifo depth=1
Jun 19 09:23:07 gertrude kernel: ath0: ath_edma_tx_processq: Q1, bf=0xfffffe000385f068, start=1, end=1
Jun 19 09:23:07 gertrude kernel: ath0: ath_edma_tx_processq: Q1: FIFO depth is now 0 (1)
Jun 19 09:23:07 gertrude kernel: ath0: ath_edma_tx_processq: Q1, bf=0xfffffe0003866fe8, start=0, end=1
Jun 19 09:23:07 gertrude kernel: ath0: ath_edma_tx_processq: Q1: FIFO depth is now -1 (0)
So, clear the flags before adding them to a TX queue, so if they're
re-added for the retransmit path it'll clear whatever they were and
not double-account the FIFOEND flag. Oops.
Tested:
* AR9380, STA mode, 11n iperf testing (~130mbit)
Approved by: re (delphij)
|
| 302017 |
19-Jun-2016 |
adrian |
[ath] add support for batching frames to the general TX queues.
It turns out the frame scheduling policies (eg DBA_GATED) operate on
a single TX FIFO entry. ASAP scheduling is fine; those frames always
go out.
DBA-gated sets the TX queue ready when the DBA timer fires, which triggers
a beacon transmit. Normally this is used for content-after-beacon queue
(CABQ) work, which needs to burst out immediately after a beacon.
(eg broadcast, multicast, etc frames.) This is a general policy that you
can use for any queue, and Sam's TDMA code uses it.
When DBA_GATED is used and something like say, an 11e TX burst window,
it only operates on a single TX FIFO entry. If you have a single frame
per TX FIFO entry and say, a 2.5ms long burst window (eg TDMA!) then it'll
only burst a single frame every 2.5ms. If there's no gating (eg ASAP) then
the burst window is fine, and multiple TX FIFO slots get used.
The CABQ code does pack in a list of frames (ie, the whole cabq) but
up until this commit, the normal TX queues didn't. It showed up when
I started to debug TDMA on the AR9380 and later.
This commit doesn't fix the TDMA case - that's still broken here, because
all I'm doing here is allowing 'some' frames to be bursting, but I'm
certainly not filling the whole TX FIFO slot entry with frames.
Doing that 'properly' kind of requires me to take into account how long
packets should take to transmit and say, doing 1.5 or something times that
per TX FIFO slot, as if you partially transmit a slot, when it's next
gated it'll just finish that TX FIFO slot, then not advance to the next
one.
Now, I /also/ think queuing a new packet restarts DMA, but you have to
push new frames into the TX FIFO. I need to experiment some more with
this because if it's really the case, I will be able to do TDMA support
without the egregious hacks I have in my local tree. Sam's TDMA code
for previous chips would just kick the TXE bit to push along DMA
again, but we can't do that for EDMA chips - we /have/ to push a new
frame into the TX FIFO to restart DMA. Ugh.
Tested:
* AR9380, STA mode
* AR9380, hostap mode
* AR9580, hostap mode
Approved by: re (gjb)
|
| 301994 |
17-Jun-2016 |
adrian |
[ath] don't debug RX EDMA descriptors that are not yet complete.
Approved by: re@ (gjb)
|
| 301767 |
09-Jun-2016 |
adrian |
[ath] add a placeholder event for debuggin EDMA TX FIFO push events.
Some later code I'll commit pushes lists of frames into the EDMA TX
FIFO, rather than a single frame at a time. The CABQ code already
pushes frame lists, but it turns out we should actually be doing it
in general or performance tanks. :(
|
| 301766 |
09-Jun-2016 |
adrian |
[ath] report node queue overflows.
I need to also update athstats to report this too.
|
| 301307 |
04-Jun-2016 |
adrian |
[ath] remove now unused parameters.
These will move to being part of the driver btcoex stuff I'm working
on, since the HAL doesn't know what to do with them.
|
| 301304 |
04-Jun-2016 |
adrian |
[ath_hal] add placeholders for AUDIO stomp for Kite/Kiwi.
It just stomps all; which is enough for some testing.
|
| 301303 |
04-Jun-2016 |
adrian |
[ath_hal] add BTCOEX_STOMP_AUDIO; delete unused methods.
|
| 301186 |
02-Jun-2016 |
adrian |
[ath] correctly shift the QCA9565 LNA config into the mci config variable.
Tested:
* QCA9565, STA + BT mode
|
| 301182 |
02-Jun-2016 |
gnn |
Fix kernel build. Improper definition location of a variable.
|
| 301181 |
02-Jun-2016 |
adrian |
[ath] commit initial bluetooth coexistence support for the MCI NICs.
This is the initial framework to call into the MCI HAL routines and drive
the basic state engine.
The MCI bluetooth coex model uses a command channel between wlan and
bluetooth, rather than a 2-wire or 3-wire signaling protocol to control things.
This means the wlan and bluetooth chip exchange a lot more information and
signaling, even at the per-packet level. The NICs in question can share
the input LNA and output PA on the die, so they absolutely can't stomp
on each other in a silly fashion. It also allows for the bluetooth side
to signal when profiles come and go, so the driver can take appropriate
control. There's also the possibility of dynamic bluetooth/wlan duty cycle
control which I haven't yet really played with.
It configures things up with a static "wlan wins everything" coexistence,
configures up the available 2GHz channel map for bluetooth, sets a static
duty cycle for bluetooth/wifi traffic priority and drives the basics needed to
keep the MCI HAL code happy.
It doesn't do any actual coexistence except to default to "wlan wins everything",
which at least demonstrates that things do indeed work. Bluetooth inquiry frames
still trump wifi (including beacons), so that demonstrates things really do
indeed seem to work.
Tested:
* AR9462 (WB222), STA mode + bt
* QCA9565 (WB335), STA mode + bt
TODO:
* .. the rest of coexistence. yes, bluetooth, not people. That stuff's hard.
* It doesn't do the initial BT side calibration, which requires a WLAN chip
reset. I'll fix up the reset path a bit more first before I enable that.
* The 1-ant and 2-ant configuration bits aren't being set correctly in
if_ath_btcoex.c - I'll dig into that and fix it in a subsequent commit.
* It's not enabled by default for WB222/WB225 even though I believe it now
can be - I'll chase that up in a subsequent commit.
Obtained from: Qualcomm Atheros, Linux ath9k
|
| 301089 |
01-Jun-2016 |
adrian |
[ath_hal] add extra MCI definitions used by the later chips (QCA9565/Aphrodite).
Obtained from: Linux ath9k
|
| 301043 |
31-May-2016 |
adrian |
[ath_hal] rename the MCI state info routine.
It's not /really/ "get state".
|
| 301042 |
31-May-2016 |
adrian |
[ath_hal] add support for setting the azimuth timestamp in the outgoing TX payload.
FYI: This is an unsupported/deprecated feature of the 11n hardware.
|
| 301041 |
31-May-2016 |
adrian |
[ath_hal] reserve a HAL_TXDESC_ bit for azimuth TX timestamp requests.
|
| 301014 |
31-May-2016 |
adrian |
[ath_hal] migrate the bluetooth definitions out from ah.h / ar9300_freebsd_inc.h.
The eventual MCI driver side of things needs the MCI bits to live
in the HAL API so we can get to them.
Tested:
* QCA9565, STA mode + bluetooth
|
| 301013 |
31-May-2016 |
adrian |
[ath_hal] add bluetooth coexistence definitions for both legacy and MCI.
The legacy bits are just from ah.h; the MCI bits are from the ar9300
HAL "freebsd" extras.
A subsequent commit will include ah_btcoex.h into ah.h and remove
the older defintions.
|
| 301008 |
31-May-2016 |
adrian |
[ath] add BTCOEX debug section; modify DPRINTF() to take a no-arg format string.
Tested:
* QCA9565, STA mode
|
| 300896 |
28-May-2016 |
adrian |
[ath] add WB335 btcoex for initial testing.
This is like the WB222 coexistence (ie, "MCI", a message bus inside the
chip), and it's currently a cut/paste so I can start using it to flesh
out the differences with WB222.
It doesn't completely /do/ bluetooth coexistence, because it turns out
I need to add some contigmalloc'ed buffers to the btcoex path for this
type of hardware. I'm putting this work in the "people would like
to see functioning-ish btcoex before FreeBSD-11" bucket because I see
this as "broken".
Tested:
* QCA9535 (WB335) NIC, BT + 2GHz STA
|
| 300267 |
20-May-2016 |
adrian |
[ath] convert recent changes over to HAL format.
This is needed to compile the ath tools, that includes this code
to run in userland.
Tested:
* Carambola 2, AR9331, STA mode
|
| 300246 |
19-May-2016 |
avos |
ath: refactor/split getchannels() method.
Split getchannels() method in ath_hal/ah_regdomain.c into a subset
of functions for better readability.
Note: due to different internal structure, it cannot use
ieee80211_add_channel*() (however, some parts are done in a
similar manner).
Differential Revision: https://reviews.freebsd.org/D6139
|
| 298939 |
02-May-2016 |
pfg |
dev/ath: minor spelling fixes in comments.
No functional change.
Reviewed by: adrian
|
| 298792 |
29-Apr-2016 |
adrian |
[ath] initialise do_ldpc to 0.
I .. can't believe I missed this.
This showed up because the AP was TX'ing LDPC to an iwm(4) chipset,
which didn't advertise LDPC and doesn't /accept/ LDPC. Amusingly, all
the two other FreeBSD 11n parts I had tested with (AR9380, Intel 7260)
and I completely forgot to test on ye olde hardware.
That'll teach me.
Tested:
* AR9580 (AP) - Intel 7260 (STA), AR9380 (STA), Intel 6205 (STA)
|
| 298762 |
29-Apr-2016 |
adrian |
[ath] Add LDPC transmit support.
LDPC adds better transmit reliability if both ends support it.
You in theory can do both STBC and LDPC at the same time.
If I see issues I'll disable it.
* Only enable it if both ends of a connection negotiate it.
* Disable it if any rate is non-11n.
* Count both LDPC TX and STBC TX.
Tested:
* AR9380, STA mode
|
| 298761 |
29-Apr-2016 |
adrian |
[ath] turn the BA hardware bug back into a printf().
I saw this happen a couple of times and all I saw was a dump of the
transmit descriptors. Log the message for now so I can see whta happened.
|
| 298760 |
29-Apr-2016 |
adrian |
[ath] Add counters for STBC TX and LDPC TX.
This is a big no-op until the TX path changes to enable LDPC TX are
added.
|
| 298608 |
26-Apr-2016 |
adrian |
[ath] add LDPC capability support and LDPC RX support.
This enables LDPC receive support for the AR9300 chips that support it.
It'll announce LDPC support via net80211.
Tested:
* AR9380, STA mode
* AR9331, (to verify the HAL didn't attach it to a chip which
doesn't support LDPC.)
TODO:
* Add in net80211 machinery to make this configurable at runtime.
|
| 298607 |
26-Apr-2016 |
adrian |
[ath] obey the STBC flag setting in iv_flags_ht
Add support for the FHT_STBC_TX flag in iv_flags_ht, so it'll now obey
the per-vap ifconfig stbctx flag.
This means that we can do STBC TX on one vap and not another VAP.
(As well as STBC RX on said vap; that changes the HTCAP announcement.)
|
| 298359 |
20-Apr-2016 |
avos |
net80211: replace internal LE_READ_*/LE_WRITE_* macro with system
le*dec / le*enc functions.
Replace net80211 specific macros with system-wide bytestream
encoding/decoding functions:
- LE_READ_2 -> le16dec
- LE_READ_4 -> le32dec
- LE_WRITE_2 -> le16enc
- LE_WRITE_4 -> le32enc
+ drop ieee80211_input.h include, where it was included for these
operations only.
Reviewed by: adrian
Differential Revision: https://reviews.freebsd.org/D6030
|
| 297793 |
10-Apr-2016 |
pfg |
Cleanup unnecessary semicolons from the kernel.
Found with devel/coccinelle.
|
| 297729 |
09-Apr-2016 |
adrian |
[ath] Only process beacon frames for the IBSS/BSSID if appropriate.
* Don't use arbitrary frames for the average RX RSSI - only frames
from the current BSSID
* Don't log / do the syncbeacon logic for another BSSID and definitely
don't do the syncbeacon call if we miss beacons outside of STA mode.
* Don't do the IBSS merge bits if the current node plainly won't ever
match our current BSS (ie, the IBSS doesn't have to match, but all
the same bits that we check in ieee80211_ibss_merge() have to match.)
Tested:
* ath(4), AR9380, IBSS mode, surrounded by a lot of IBSS 11ac networks.
Sponsored by: Eva Automation, Inc.
|
| 297405 |
30-Mar-2016 |
adrian |
[net80211] migrate the time_* macros to ieee80211_* namespace.
It turns out that these will clash very annoyingly with the linux
macros in the linuxkpi layer, so let the wookie^Wlinux win.
The only user that I can find is ath(4), so fix it there too.
|
| 296272 |
01-Mar-2016 |
jhb |
Remove taskqueue_enqueue_fast().
taskqueue_enqueue() was changed to support both fast and non-fast
taskqueues 10 years ago in r154167. It has been a compat shim ever
since. It's time for the compat shim to go.
Submitted by: Howard Su <howard0su@gmail.com>
Reviewed by: sephe
Differential Revision: https://reviews.freebsd.org/D5131
|
| 296176 |
29-Feb-2016 |
adrian |
Fix up the ath(4) device names for QCA chipsets.
Submitted by: Tobias Kortkamp <t@tobik.me>
|
| 293111 |
03-Jan-2016 |
adrian |
[ath] remove the inline version of the register access macros.
These are going to be much more efficient on low end embedded systems
but unfortunately they make it .. less convenient to implement correct
bus barriers and debugging. They also didn't implement the register
serialisation workaround required for Owl (AR5416.)
So, just remove them for now. Later on I'll just inline the routines
from ah_osdep.c.
|
| 293054 |
02-Jan-2016 |
adrian |
... and that would've never worked. Sorry!
(Note: everything I tested on locally has ATH_DEBUG / AH_DEBUG set.)
|
| 293050 |
02-Jan-2016 |
adrian |
[ath] add explicit bus barriers.
The ath hal and driver code all assume the world is an x86 or the
bus layer does an explicit bus flush after each operation (eg netbsd.)
However, we don't do that.
So, to be "correct" on platforms like sparc64, mips and ppc (and maybe
ARM, I am not sure), just do explicit barriers after each operation.
Now, this does slow things down a tad on embedded platforms but I'd
rather things be "correct" versus "fast." At some later point if someone
wishes it to be fast then we should add the barrier calls to the HAL and
driver.
Tested:
* carambola 2 (AR9331.)
|
| 291469 |
30-Nov-2015 |
adrian |
fix ht/40 configuration for ar9331 (hornet).
The synth programming here requires the real centre frequency,
which for HT20 channels is the normal channel, but HT40 is
/not/ the primary channel. Everything else was using 'freq',
which is the correct centre frequency, but the hornet config
was using 'ichan' to do the lookup which was also the primary
channel.
So, modify the HAL call that does the mapping to take a frequency
in MHz and return the channel number.
Tested:
* Carambola 2, AR9331, tested both HT/20 and HT/40 operation.
|
| 291418 |
28-Nov-2015 |
adrian |
[ath_hal] use the correct revision information for QCA953x.
This probe/attaches correctly in my local branch and now displays
a useful message:
ath0: <Qualcomm Atheros QCA953x> at mem 0x18100000-0x1811ffff irq 0 on nexus0
...
ath0: AR9530 mac 1280.0 RF5110 phy 0.0
|
| 291413 |
28-Nov-2015 |
adrian |
* Add device string for QCA955x (scorpion);
* Add device ID and device string for QCA953x (honeybee).
|
| 291412 |
28-Nov-2015 |
adrian |
wrap in ATH_DEBUG.
Thanks sparc64 build!
|
| 291411 |
27-Nov-2015 |
adrian |
[ath] conditionally print out the rate series information if ATH_DEBUG_XMIT is set.
|
| 291304 |
25-Nov-2015 |
adrian |
[ath] listen to all beacons in IBSS and software beacon miss.
I added MYBEACON support a while ago to listen to beacons that are only
for your configured BSSID. For AR9380 and later NICs this results in
a lot less chip wakeups in station mode as it then only shows you beacons
that are destined to you.
However in IBSS mode you really do want to hear all beacons so you can do
IBSS merges. Oops.
So only use MYBEACON for STA + not-scanning, and just use BEACON for
the other modes it used to use BEACON for.
This doesn't completely fix IBSS merges though - there are still some
conditions to chase down and fix.
|
| 291233 |
24-Nov-2015 |
adrian |
[ath] migrate ioctl and busdma memory operations out into separate source files.
This should be a big no-op pass; and reduces the size of if_ath.c.
I'm hopefully soon going to take a whack at the USB support for ath(4)
and this'll require some reuse of the busdma memory code.
|
| 290616 |
09-Nov-2015 |
garga |
Fix kernel build, broken in r290612
Approved by: adrian
|
| 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.
|
| 290474 |
07-Nov-2015 |
adrian |
ath(4) - reflect whether this is a full or fast channel change.
It's no longer "outdoor."
|
| 290339 |
03-Nov-2015 |
adrian |
ath(4) - don't try to free buffers / return an error if we've committed
to transmit the buffer.
ath_tx_start() may manipulate/reallocate the mbuf as part of the DMA
code, so we can't expect the mbuf can be returned back to the caller.
Now, the net80211 ifnet work changed the semantics slightly so
if an error is returned here, the mbuf/reference is freed by the
caller (here, it's net80211.)
So, once we reach ath_tx_start(), we never return failure. If we fail
then we still return OK and we free the mbuf/noderef ourselves, and
we increment OERRORS.
|
| 289165 |
12-Oct-2015 |
adrian |
net80211: move ieee80211_free_node() call on error from ic_raw_xmit() to ieee80211_raw_output().
This doesn't free the mbuf upon error; the driver ic_raw_xmit method is still
doing that.
Submitted by: <s3erios@gmail.com>
Differential Revision: https://reviews.freebsd.org/D3774
|
| 289162 |
12-Oct-2015 |
adrian |
net80211: separate mbuf cleanup from ieee80211_fragment()
* Create ieee80211_free_mbuf() which frees a list of mbufs.
* Use it in the fragment transmit path and ath / uath transmit paths.
* Call it in xmit_pkt() if the transmission fails; otherwise fragments
may be leaked.
This should be a big no-op.
Submitted by: <s3erios@gmail.com>
Differential Revision: https://reviews.freebsd.org/D3769
|
| 289099 |
10-Oct-2015 |
adrian |
Flip on fast frames support for AR5416 and AR9300 series NICs.
This was off because the net80211 aggregation code was using the same
state pointers for both fast frames and ampdu tx support which led to some
pretty unfortunate panic-y behaviour.
Now that net80211 doesn't panic, let's flip this back on.
It doesn't (yet) do the horrific sounding thing of A-MPDU aggregates
of fast frames; that'll come next. It's a pre-requisite to supporting
AMSDU + AMPDU anyway, which actually speeds things up quite considerably
(think packing lots of little ACK frames into a single AMSDU.)
Tested:
* QCA955x SoC, AP mode
* AR5416, STA mode
* AR9170, STA mode (with local fast frame patches)
|
| 288689 |
05-Oct-2015 |
kevlo |
Remove the unnecessary cast.
|
| 288636 |
03-Oct-2015 |
adrian |
net80211: drop ieee80211_beacon_offsets parameter from ieee80211_beacon_alloc() and ieee80211_beacon_update()
Submitted by: <s3erios@gmail.com>
Differential Revision: https://reviews.freebsd.org/D3659
|
| 288635 |
03-Oct-2015 |
adrian |
net80211: drop redundant 3rd parameter from iv_key_set().
The MAC can be fetched from the key struct.
I added the ndis updates to make it compile.
Submitted by: <s3erios@gmail.com>
Differential Revision: https://reviews.freebsd.org/D3657
|
| 288349 |
29-Sep-2015 |
adrian |
Remove the references to the TX IC lock - i ended up solving this
using net80211 to seralise encap+xmit, so now it's a non-issue.
|
| 288095 |
22-Sep-2015 |
adrian |
net80211: include one copy of struct ieee80211_beacon_offsets into ieee80211vap
Submitted by: Andriy Voskoboinyk <s3erios@gmail.com>
Differential Revision: https://reviews.freebsd.org/D3658
|
| 288087 |
22-Sep-2015 |
adrian |
net80211 & wireless drivers: remove duplicate defines (noop)
* IEEE80211_DIR_DSTODS(wh) -> IEEE80211_IS_DSTODS(wh).
* N(a) -> nitems(a).
* Remove LE_READ_2(p)/LE_READ_4(p) definitions (and include ieee80211_input.h instead).
* <drvname>_TXOP_TO_US(txop) -> IEEE80211_TXOP_TO_US(txop).
* Put IEEE80211_RV(v) into ieee80211_proto.h and remove local RV(v) definitions.
Submitted by: Andriy Voskoboinyk <s3erios@gmail.com>
Differential Revision: https://reviews.freebsd.org/D3705
|
| 287197 |
27-Aug-2015 |
glebius |
Replay r286410. Change KPI of how device drivers that provide wireless
connectivity interact with the net80211 stack.
Historical background: originally wireless devices created an interface,
just like Ethernet devices do. Name of an interface matched the name of
the driver that created. Later, wlan(4) layer was introduced, and the
wlanX interfaces become the actual interface, leaving original ones as
"a parent interface" of wlanX. Kernelwise, the KPI between net80211 layer
and a driver became a mix of methods that pass a pointer to struct ifnet
as identifier and methods that pass pointer to struct ieee80211com. From
user point of view, the parent interface just hangs on in the ifconfig
list, and user can't do anything useful with it.
Now, the struct ifnet goes away. The struct ieee80211com is the only
KPI between a device driver and net80211. Details:
- The struct ieee80211com is embedded into drivers softc.
- Packets are sent via new ic_transmit method, which is very much like
the previous if_transmit.
- Bringing parent up/down is done via new ic_parent method, which notifies
driver about any changes: number of wlan(4) interfaces, number of them
in promisc or allmulti state.
- Device specific ioctls (if any) are received on new ic_ioctl method.
- Packets/errors accounting are done by the stack. In certain cases, when
driver experiences errors and can not attribute them to any specific
interface, driver updates ic_oerrors or ic_ierrors counters.
Details on interface configuration with new world order:
- A sequence of commands needed to bring up wireless DOESN"T change.
- /etc/rc.conf parameters DON'T change.
- List of devices that can be used to create wlan(4) interfaces is
now provided by net.wlan.devices sysctl.
Most drivers in this change were converted by me, except of wpi(4),
that was done by Andriy Voskoboinyk. Big thanks to Kevin Lo for testing
changes to at least 8 drivers. Thanks to pluknet@, Oliver Hartmann,
Olivier Cochard, gjb@, mmoll@, op@ and lev@, who also participated in
testing.
Reviewed by: adrian
Sponsored by: Netflix
Sponsored by: Nginx, Inc.
|
| 286835 |
17-Aug-2015 |
adrian |
Remove most of the references of ifp->if_softc and replace with
references to ic->ic_softc.
This is in preparation for gleb's ifnet work.
Tested:
* ath(4), STA mode
* ath(4), hostap mode
* make universe
|
| 286437 |
08-Aug-2015 |
adrian |
Revert the wifi ifnet changes until things are more baked and tested.
* 286410
* 286413
* 286416
The initial commit broke a variety of debug and features that aren't
in the GENERIC kernels but are enabled in other platforms.
|
| 286410 |
07-Aug-2015 |
glebius |
Change KPI of how device drivers that provide wireless connectivity interact
with the net80211 stack.
Historical background: originally wireless devices created an interface,
just like Ethernet devices do. Name of an interface matched the name of
the driver that created. Later, wlan(4) layer was introduced, and the
wlanX interfaces become the actual interface, leaving original ones as
"a parent interface" of wlanX. Kernelwise, the KPI between net80211 layer
and a driver became a mix of methods that pass a pointer to struct ifnet
as identifier and methods that pass pointer to struct ieee80211com. From
user point of view, the parent interface just hangs on in the ifconfig
list, and user can't do anything useful with it.
Now, the struct ifnet goes away. The struct ieee80211com is the only
KPI between a device driver and net80211. Details:
- The struct ieee80211com is embedded into drivers softc.
- Packets are sent via new ic_transmit method, which is very much like
the previous if_transmit.
- Bringing parent up/down is done via new ic_parent method, which notifies
driver about any changes: number of wlan(4) interfaces, number of them
in promisc or allmulti state.
- Device specific ioctls (if any) are received on new ic_ioctl method.
- Packets/errors accounting are done by the stack. In certain cases, when
driver experiences errors and can not attribute them to any specific
interface, driver updates ic_oerrors or ic_ierrors counters.
Details on interface configuration with new world order:
- A sequence of commands needed to bring up wireless DOESN"T change.
- /etc/rc.conf parameters DON'T change.
- List of devices that can be used to create wlan(4) interfaces is
now provided by net.wlan.devices sysctl.
Most drivers in this change were converted by me, except of wpi(4),
that was done by Andriy Voskoboinyk. Big thanks to Kevin Lo for testing
changes to at least 8 drivers. Thanks to Olivier Cochard, gjb@, mmoll@,
op@ and lev@, who also participated in testing. Details here:
https://wiki.freebsd.org/projects/ifnet/net80211
Still, drivers: ndis, wtap, mwl, ipw, bwn, wi, upgt, uath were not
tested. Changes to mwl, ipw, bwn, wi, upgt are trivial and chances
of problems are low. The wtap wasn't compilable even before this change.
But the ndis driver is complex, and it is likely to be broken with this
commit. Help with testing and debugging it is appreciated.
Differential Revision: D2655, D2740
Sponsored by: Nginx, Inc.
Sponsored by: Netflix
|
| 286343 |
05-Aug-2015 |
adrian |
Add a hack-around to this fatal taskqueue running whilst the NIC
is detaching.
This mostly fixes a panic - the reset path shouldn't run whilst
the NIC is being torn down.
It's not locked, so it's "mostly" ok, but most of the rest of
the driver doesn't read sc->invalid with sensible locking. Grr.
The real solution is to cleanly tear down taskqueues in the detach/suspend
phase, but ..
|
| 285122 |
04-Jul-2015 |
adrian |
Call the WMAC DDR flush before handling an interrupt for the
Atheros AHB (internally) connected MAC.
TODO:
* verify the interrupt was for us before doing the DDR flush.
|
| 285120 |
04-Jul-2015 |
adrian |
Wake up the hardware before doing anything in sysctl.
This stops the panics that occur on MIPS platforms when doing say,
'sysctl dev.ath.0' whilst the MAC is asleep. The MIPS platform is
rather unforgiving in getting power-save register access wrong and you
will get all kinds of odd failures if you don't have things woken
up at the right times.
Tested:
* QCA9558 (TP-Link Archer C7 v2)
* AR9331 (Carambola 2)
.. with no VAPs configured and ath0 down (thus the MAC is definitely
asleep.)
PR: kern/201117
|
| 283744 |
29-May-2015 |
glebius |
Use device_printf() instead of if_printf(). No functional changes.
|
| 283540 |
25-May-2015 |
glebius |
Change three methods in struct ieee80211com, namely ic_updateslot,
ic_update_mcast and ic_update_promisc, to pass pointer to the ieee80211com,
not to the ifnet.
Sponsored by: Netflix
Sponsored by: Nginx, Inc.
|
| 283537 |
25-May-2015 |
glebius |
Set ic_softc in all 802.11 drivers. Not required right now, but will be
used quite soon.
Sponsored by: Netflix
Sponsored by: Nginx, Inc.
|
| 283535 |
25-May-2015 |
adrian |
Begin plumbing ieee80211_rx_stats through the receive path.
Smart NICs with firmware (eg wpi, iwn, the new atheros parts, the intel 7260
series, etc) support doing a lot of things in firmware. This includes but
isn't limited to things like scanning, sending probe requests and receiving
probe responses. However, net80211 doesn't know about any of this - it still
drives the whole scan/probe infrastructure itself.
In order to move towards suppoting smart NICs, the receive path needs to
know about the channel/details for each received packet. In at least
the iwn and 7260 firmware (and I believe wpi, but I haven't tried it yet)
it will do the scanning, power-save and off-channel buffering for you -
all you need to do is handle receiving beacons and probe responses on
channels that aren't what you're currently on. However the whole receive
path is peppered with ic->ic_curchan and manual scan/powersave handling.
The beacon parsing code also checks ic->ic_curchan to determine if the
received beacon is on the correct channel or not.[1]
So:
* add freq/ieee values to ieee80211_rx_stats;
* change ieee80211_parse_beacon() to accept the 'current' channel
as an argument;
* modify the iv_input() and iv_recv_mgmt() methods to include the rx_stats;
* add a new method - ieee80211_lookup_channel_rxstats() - that looks up
a channel based on the contents of ieee80211_rx_stats;
* if it exists, use it in the mgmt path to switch the current channel
(which still defaults to ic->ic_curchan) over to something determined
by rx_stats.
This is enough to kick-start scan offload support in the Intel 7260
driver that Rui/I are working on. It also is a good start for scan
offload support for a handful of existing NICs (wpi, iwn, some USB
parts) and it'll very likely dramatically improve stability/performance
there. It's not the whole thing - notably, we don't need to do powersave,
we should not scan all channels, and we should leave probe request sending
to the firmware and not do it ourselves. But, this allows for continued
development on the above features whilst actually having a somewhat
working NIC.
TODO:
* Finish tidying up how the net80211 input path works.
Right now ieee80211_input / ieee80211_input_all act as the top-level
that everything feeds into; it should change so the MIMO input routines
are those and the legacy routines are phased out.
* The band selection should be done by the driver, not by the net80211
layer.
* ieee80211_lookup_channel_rxstats() only determines 11b or 11g channels
for now - this is enough for scanning, but not 100% true in all cases.
If we ever need to handle off-channel scan support for things like
static-40MHz or static-80MHz, or turbo-G, or half/quarter rates,
then we should extend this.
[1] This is a side effect of frequency-hopping and CCK modes - you
can receive beacons when you think you're on a different channel.
In particular, CCK (which is used by the low 11b rates, eg beacons!)
is decodable from adjacent channels - just at a low SNR.
FH is a side effect of having the hardware/firmware do the frequency
hopping - it may pick up beacons transmitted from other FH networks
that are in a different phase of hopping frequencies.
|
| 283527 |
25-May-2015 |
glebius |
Make net80211 drivers supply their device name to the net80211 layer, so
that the latter doesn't need to go through struct ifnet to get their name.
Sponsored by: Netflix
Sponsored by: Nginx, Inc.
|
| 283291 |
22-May-2015 |
jkim |
CALLOUT_MPSAFE has lost its meaning since r141428, i.e., for more than ten
years for head. However, it is continuously misused as the mpsafe argument
for callout_init(9). Deprecate the flag and clean up callout_init() calls
to make them more consistent.
Differential Revision: https://reviews.freebsd.org/D2613
Reviewed by: jhb
MFC after: 2 weeks
|
| 281128 |
06-Apr-2015 |
adrian |
Return the correct HAL data type for HAL_DIAG_ANI_STATS.
I .. stupidly added code to return HAL_ANI_STATS to HAL_DIAG_ANI_STATS.
I discovered this in a noisy environment when the returned values were
enough to .. well, make everything terrible.
So - restore functionality.
Tested:
* AR5416 (uses the AR5212 HAL), in a /very/ noisy 2GHz environment.
Enough to trigger ANI to get upset and generate useful data.
|
| 280942 |
01-Apr-2015 |
adrian |
Use the HAL API for returning ar5212AniState, rather than just dumping
AniState itself.
|
| 280940 |
01-Apr-2015 |
adrian |
Start the process of migrating the ANI statistics out of the HALs and into
the top-level HAL.
The athstats program is blindly using a copy of the ar5212 ANI stats structure
to pull out ANI statistics/state and this is problematic for the AR9300
HAL.
So:
* Define HAL_ANI_STATS and HAL_ANI_STATE
* Use HAL_ANI_STATS inside the AR5212 HAL
This commit doesn't (yet) convert the ar5212AniState -> HAL_ANI_STATE when
exporting it to userland; that'll come in the next commit.
|
| 280828 |
29-Mar-2015 |
adrian |
Move the HAL channel survey support out to be in the top-level HAL,
rathe than private in each HAL module.
Whilst here, modify ath_hal_private to always have the per-channel
noisefloor stats, rather than conditionally. This just makes
life easier in general (no strange ABI differences between different
HAL compile options.)
Add a couple of methods (clear/reset, add) rather than using
hand-rolled versions of things.
|
| 280827 |
29-Mar-2015 |
adrian |
Add a new field to HAL_ANISTATS - the extension channel busy count.
This is only used by the AR9300 HAL for now - but just be careful if
you decide to recompile the kernel with NO_CLEAN=1.
|
| 280825 |
29-Mar-2015 |
adrian |
Fix more ticks wrapping bugs exposed by the ticks wrapping bug check.
This symptom is "calibrations don't ever run", which may cause some
pretty spectacularly bad behaviour in noisy environments or with longer
uptimes.
Thanks to dtrace to make it easy to check if specific non-inlined functions
are getting called by things like the ANI and calibration HAL methods.
Grr.
Tested:
* AR9380, STA mode
|
| 280802 |
29-Mar-2015 |
adrian |
Fix a long-standing bug with the early MAC address initialisation path,
which showed up after I started changing addresses this early.
It turns out that there's some other malarky going on behind the scenes
in the HAL and merely setting the net80211/ifp mac address this early
isn't enough. If the MAC is set from kenv at attach time, the HAL
also needs to be programmed early.
Without this, the VAP wouldn't work enough for finishing association -
probe requests would be fine as they're broadcast, but association
request would fail.
|
| 280799 |
28-Mar-2015 |
adrian |
Update if_ath(4) to check for "hint.ath.X.macaddr" for an override MAC address.
This is used by the AR71xx platform code to choose a local MAC based on
the "board MAC address", versus whatever potentially invalid/garbage
values are stored in the Atheros calibration data.
|
| 279512 |
02-Mar-2015 |
adrian |
Lay some groundwork for having this stuff hang off of AHB rather than
the CPU nexus.
* Add ahb as a possible bus attachment
* Lay a comment down to remind me or whoever else ends up trying
to debug why the EEPROM isn't mapped in as to what's going on.
|
| 278765 |
14-Feb-2015 |
adrian |
Move the lock destruction/creation to earlier in the process - if
interrupts are enabled and the NIC is awake (think: loading a module)
then there's a not-quite-zero window where we'll get an interrupt
for the device before the attach method is called to finish setting
up the hardware.
Since I grab locks in ath_intr() to check various things, the locks
need to be ready much earlier.
|
| 277823 |
28-Jan-2015 |
adrian |
Cast everything to something longer than 32 bits so the sample mask
doesn't get truncated to 32 bits.
Without this, 3x3 NICs transmitting at an MCS rate whose rix (rate
index) in the rate table is > 31 end up returning errors, as the
sample rate code doesn't think the rate is set in the rate table.
Tested:
* AR9380, STA, speaking 3x3 to an AP
|
| 277822 |
28-Jan-2015 |
adrian |
Print out the final_rix if there's a problem.
|
| 277821 |
28-Jan-2015 |
adrian |
Add a new HAL capability - required to compile the updated AR9300
HAL i have lying about.
|
| 277290 |
17-Jan-2015 |
adrian |
Oops; correctly reload the CCA registers with the uncapped value
in prep for the next NF calibration pass.
Totally missing braces. Damn you C.
Submitted by: Sascha Wildner <swildner@dragonflybsd.org>
MFC after: 1 week
|
| 277277 |
17-Jan-2015 |
adrian |
Until there's a full MCI implementation - just implement a placeholder
MCI bluetooth coexistence method for WB222.
The rest of MCI requires a bunch more work, including adding a DMA buffer
for the MCI hardware to bounce messages in/out of and handling MCI
interrupts. But the more important part here is telling the HAL
the btcoex is enabled and MCI is in use so it configures the correct
initial bluetooth parameters in the wireless NIC and configures
things like bluetooth traffic weights and such.
So, this at least gets the HAL to do some of the right things in
configuring the inital bluetooth coexistence stuff, but doesn't
actually do full btcoex. That'll take.. some effort.
Tested:
* AR9462 (WB222), STA mode
|
| 277275 |
16-Jan-2015 |
adrian |
Add bluetooth MCI coexistence HAL methods - used for AR9462 and AR9565 NICs.
It's found, amongst other things, in the Acer Chromebook (Intel)
devices.
Tested:
* AR9462 (WB222)
Obtained from: Qualcomm Atheros
|
| 277228 |
16-Jan-2015 |
adrian |
Check the right value correctly.
Thanks to clang for pointing out this silliness.
|
| 276150 |
23-Dec-2014 |
adrian |
Bump the valid GPIO range for rfkill up from 8 to 16.
AR5416 and later NICs have more than 8 (Well, more than 6) GPIO pins.
So to support rfkill on these NICs we need to bump this up or the
rfkill GPIO pin may get reset to the wrong value.
Noticed by: Anthony Jenkins <scoobi_doo@yahoo.com>
|
| 274922 |
23-Nov-2014 |
dim |
Fix the following -Werror warning from clang 3.5.0, while building the
ath kernel module:
sys/dev/ath/ath_hal/ar5212/ar5212_reset.c:2642:7: error: taking the absolute value of unsigned type 'unsigned int' has no effect [-Werror,-Wabsolute-value]
if (abs(lp[0] * EEP_SCALE - target) < EEP_DELTA) {
^
sys/dev/ath/ah_osdep.h:74:18: note: expanded from macro 'abs'
#define abs(_a) __builtin_abs(_a)
^
sys/dev/ath/ath_hal/ar5212/ar5212_reset.c:2642:7: note: remove the call to '__builtin_abs' since unsigned values cannot be negative
sys/dev/ath/ah_osdep.h:74:18: note: expanded from macro 'abs'
#define abs(_a) __builtin_abs(_a)
^
1 error generated.
This warning occurs because both lp[0] and target are unsigned, so the
subtraction expression is also unsigned, and calling abs() is a no-op.
However, the intention was to look at the absolute difference between
the two unsigned quantities. Introduce a small static function to
clarify what we're doing, and call that instead.
Reviewed by: adrian
MFC after: 3 days
Differential Revision: https://reviews.freebsd.org/D1212
|
| 274535 |
15-Nov-2014 |
adrian |
Convert the callouts back to using mutexes.
I did this wrong - I should've included a state flag for each callout
to see if it was supposed to run or not. I didn't do that.
Instead, just use mutexes anyway.
Suggested by: jhb
|
| 274493 |
14-Nov-2014 |
adrian |
Migrate the callouts from using mutex locks to being mpsafe with
the locks being held by the callers.
Kill callout_drain() and use callout_stop().
|
| 272295 |
30-Sep-2014 |
adrian |
Add a missing file from the last commit.
Noticed by: jhibbits
|
| 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
|
| 271887 |
20-Sep-2014 |
adrian |
Fix up the EDMA RX setup path to correctly initialise and reset the RX FIFO.
The original code was .. well, slightly more than incorrect.
It showed up as stalled RX queues if the NIC needed to be frequently
reinitialised (eg during scans.)
This is inspired by work done by Matt Dillon over at the DragonflyBSD
project.
So:
* track when EDMA RX has been stopped and when the MAC has been reset;
* re-initialise the ring only after a reset;
* track whether RX has been stopped/started - just for debugging now;
* don't bother with the RX EOL stuff for EDMA - we don't need the
interrupt at all. We also don't need to disable/enable the interrupt
or start DMA - once new frames are pushed into the ring via the
normal RX path, it'll just restart RX DMA on its own.
Tested:
* AR9380, STA mode
* AR9380, AP mode
* AR9485, STA mode
* AR9462, STA mode
|
| 271823 |
18-Sep-2014 |
glebius |
Mechanically convert to if_inc_counter().
|
| 270430 |
23-Aug-2014 |
adrian |
Shut down RX before TX - in theory, this should make the chip less likely
to get upset.
The Qualcomm Atheros reference design code goes through significant
hacks to shut down RX before TX. It doesn't even try do do it in the
driver - it actually makes the DMA stop routines in the HAL shut down
RX before shutting down TX.
So, to make this work for chips that aren't the AR9380 and later, do
it in the driver. Shuffle the TX stop/drain HAL calls to be called
*after* the RX stop HAL call.
Tested:
* AR5413 (STA)
* AR5212 (STA)
* AR5416 (STA)
* AR9380 (STA)
* AR9331 (AP)
* AR9341 (AP)
TODO:
* test ar92xx series NIC and the AR5210/AR5211, in case there's something
even odder about those.
|
| 269760 |
09-Aug-2014 |
adrian |
Bump the HAL_REGRANGE fields from 16 bit to 32 bit.
The AR9380 and later chips have a 128KiB register window, so the register
read diag api needs changing.
The tools are about to be updated as well. No, they're not backwards
compatible.
|
| 269749 |
09-Aug-2014 |
adrian |
Add two new debug mark entries for chip power configuration.
|
| 269714 |
08-Aug-2014 |
imp |
an isn't used, so eliminate it.
|
| 268351 |
07-Jul-2014 |
marcel |
Remove ia64.
This includes:
o All directories named *ia64*
o All files named *ia64*
o All ia64-specific code guarded by __ia64__
o All ia64-specific makefile logic
o Mention of ia64 in comments and documentation
This excludes:
o Everything under contrib/
o Everything under crypto/
o sys/xen/interface
o sys/sys/elf_common.h
Discussed at: BSDcan
|
| 267992 |
28-Jun-2014 |
hselasky |
Pull in r267961 and r267973 again. Fix for issues reported will follow.
|
| 267985 |
27-Jun-2014 |
gjb |
Revert r267961, r267973:
These changes prevent sysctl(8) from returning proper output,
such as:
1) no output from sysctl(8)
2) erroneously returning ENOMEM with tools like truss(1)
or uname(1)
truss: can not get etype: Cannot allocate memory
|
| 267961 |
27-Jun-2014 |
hselasky |
Extend the meaning of the CTLFLAG_TUN flag to automatically check if
there is an environment variable which shall initialize the SYSCTL
during early boot. This works for all SYSCTL types both statically and
dynamically created ones, except for the SYSCTL NODE type and SYSCTLs
which belong to VNETs. A new flag, CTLFLAG_NOFETCH, has been added to
be used in the case a tunable sysctl has a custom initialisation
function allowing the sysctl to still be marked as a tunable. The
kernel SYSCTL API is mostly the same, with a few exceptions for some
special operations like iterating childrens of a static/extern SYSCTL
node. This operation should probably be made into a factored out
common macro, hence some device drivers use this. The reason for
changing the SYSCTL API was the need for a SYSCTL parent OID pointer
and not only the SYSCTL parent OID list pointer in order to quickly
generate the sysctl path. The motivation behind this patch is to avoid
parameter loading cludges inside the OFED driver subsystem. Instead of
adding special code to the OFED driver subsystem to post-load tunables
into dynamically created sysctls, we generalize this in the kernel.
Other changes:
- Corrected a possibly incorrect sysctl name from "hw.cbb.intr_mask"
to "hw.pcic.intr_mask".
- Removed redundant TUNABLE statements throughout the kernel.
- Some minor code rewrites in connection to removing not needed
TUNABLE statements.
- Added a missing SYSCTL_DECL().
- Wrapped two very long lines.
- Avoid malloc()/free() inside sysctl string handling, in case it is
called to initialize a sysctl from a tunable, hence malloc()/free() is
not ready when sysctls from the sysctl dataset are registered.
- Bumped FreeBSD version to indicate SYSCTL API change.
MFC after: 2 weeks
Sponsored by: Mellanox Technologies
|
| 265588 |
07-May-2014 |
adrian |
Add casts to have it compile on amd64 without complaining about
mismatched types.
Tested:
* AR9280, TDMA slave, amd64.
|
| 265527 |
07-May-2014 |
adrian |
There's no need to be this paranoid - ni is deferenced before this
point.
Coverity ID: CID 1211937
|
| 265409 |
06-May-2014 |
adrian |
Modify the RX path to keep the previous RX descriptor around once it's
used.
It turns out that the RX DMA engine does the same last-descriptor-link-
pointer-re-reading trick that the TX DMA engine. That is, the hardware
re-reads the link pointer before it moves onto the next descriptor.
Thus we can't free a descriptor before we move on; it's possible the
hardware will need to re-read the link pointer before we overwrite
it with a new one.
Tested:
* AR5416, STA mode
TODO:
* more thorough AP and STA mode testing!
* test on other pre-AR9380 NICs, just to be sure.
* Break out the RX descriptor grabbing bits from the RX completion
bits, like what is done in the RX EDMA code, so ..
* .. the RX lock can be held during ath_rx_proc(), but not across
packet input.
|
| 265370 |
05-May-2014 |
adrian |
Wake up the hardware before calling ath_mode_init() in the ioctl() path.
Tested:
* AR5416, STA + powersave
|
| 265350 |
05-May-2014 |
adrian |
Break out the multicast programming into its own hardware specific
call, which assumes the hardware is awake.
Turn ath_update_mcast() into a routine that's only called from the
net80211 layer - and it forces the hardware awake first.
This fixes a LOR from the EDMA RX path which calls ath_mode_init()
with the RX lock held - the driver lock can't also be grabbed.
This path assumes that the ath_mode_init() callers all wake up
the NIC first.
Tested:
* AR9485, STA mode, powersave
|
| 265349 |
05-May-2014 |
adrian |
Quieten the RX/TX descriptor and FIFO setup debugging.
Tested:
* AR9485, STA mode
|
| 265348 |
05-May-2014 |
adrian |
Add Atheros AR1111 support to the HAL.
This seems to probe/attach as an AR9485 and thus nothing else besides
adding the device id seems to be required.
ath0: <Atheros AR1111> mem 0xf4800000-0xf487ffff irq 19 at device 0.0 on pci5
ath0: [HT] enabling HT modes
ath0: [HT] enabling short-GI in 20MHz mode
ath0: [HT] 1 stream STBC receive enabled
ath0: [HT] 1 RX streams; 1 TX streams
ath0: AR9485 mac 576.1 RF5110 phy 1926.8
ath0: 2GHz radio: 0x0000; 5GHz radio: 0x0000
The NIC I have here is a 1 antenna, 2GHz only device.
Thankyou to Jim Thompson <jim@netgate.com> for the AR1111 NIC.
Tested:
* AR1111 (pretending not to be an AR9485, but failing miserably);
STA mode with powersave.
Relnotes: yes
Sponsored by: Netgate
|
| 265205 |
02-May-2014 |
adrian |
Add tracking for self-generated frames when the VAP is in sleep state.
The hardware can generate its own frames (eg RTS/CTS exchanges, other
kinds of 802.11 management stuff, especially when it comes to 802.11n)
and these also have PWRMGT flags. So if the VAP is asleep but the
NIC is in force-awake for some reason, ensure that the self-generated
frames have PWRMGT set to 1.
Now, this (like basically everything to do with powersave) is still
racy - the only way to guarantee that it's all actually consistent
is to pause transmit and let it finish before transitioning the VAP
to sleep, but this at least gets the basic method of tracking and
updating the state debugged.
Tested:
* AR5416, STA mode
* AR9380, STA mode
|
| 265117 |
30-Apr-2014 |
adrian |
* Modify the beacon interval in debugging to be ni_intval, not 102400
* Be paranoid about avoiding divide-by-zero.
Tested:
* AR9380, STA mode
|
| 265115 |
30-Apr-2014 |
adrian |
Bring over some initial power save management support, reset path
fixes and beacon programming / debugging into the ath(4) driver.
The basic power save tracking:
* Add some new code to track the current desired powersave state; and
* Add some reference count tracking so we know when the NIC is awake; then
* Add code in all the points where we're about to touch the hardware and
push it to force-wake.
Then, how things are moved into power save:
* Only move into network-sleep during a RUN->SLEEP transition;
* Force wake the hardware up everywhere that we're about to touch
the hardware.
The net80211 stack takes care of doing RUN<->SLEEP<->(other) state
transitions so we don't have to do it in the driver.
Next, when to wake things up:
* In short - everywhere we touch the hardware.
* The hardware will take care of staying awake if things are queued
in the transmit queue(s); it'll then transit down to sleep if
there's nothing left. This way we don't have to track the
software / hardware transmit queue(s) and keep the hardware
awake for those.
Then, some transmit path fixes that aren't related but useful:
* Force EAPOL frames to go out at the lowest rate. This improves
reliability during the encryption handshake after 802.11
negotiation.
Next, some reset path fixes!
* Fix the overlap between reset and transmit pause so we don't
transmit frames during a reset.
* Some noisy environments will end up taking a lot longer to reset
than normal, so extend the reset period and drop the raise the
reset interval to be more realistic and give the hardware some
time to finish calibration.
* Skip calibration during the reset path. Tsk!
Then, beacon fixes in station mode!
* Add a _lot_ more debugging in the station beacon reset path.
This is all quite fluid right now.
* Modify the STA beacon programming code to try and take
the TU gap between desired TSF and the target TU into
account. (Lifted from QCA.)
Tested:
* AR5210
* AR5211
* AR5212
* AR5413
* AR5416
* AR9280
* AR9285
TODO:
* More AP, IBSS, mesh, TDMA testing
* Thorough AR9380 and later testing!
* AR9160 and AR9287 testing
Obtained from: QCA
|
| 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
|
| 265033 |
27-Apr-2014 |
adrian |
Note that the AR5416 and later hardware supports the MYBEACON RX filter.
|
| 265032 |
27-Apr-2014 |
adrian |
* Add a new capability which returns whether the hardware supports
the MYBEACON RX filter (only receive beacons which match the BSSID)
or all beacons on the current channel.
* Add the relevant RX filter entry for MYBEACON.
Tested:
* AR5416, STA
* AR9285, STA
TODO:
* once the code is in -HEAD, just make sure that the code which uses it
correctly sets BEACON for pre-AR5416 chips.
Obtained from: QCA, Linux ath9k
|
| 265031 |
27-Apr-2014 |
adrian |
Program the AR_TSFOOR_THRESHOLD register with a default lifted from
the QCA HAL.
This fires off an interrupt if the TSF from the AP / IBSS peer is
wildly out of range. I'll add some code to the ath(4) driver soon
which makes use of this.
TODO:
* verify this didn't break TDMA!
|
| 265030 |
27-Apr-2014 |
adrian |
Fix the AR_SLEEP1 and AR_SLEEP2 definitions. Oops!
Tested:
* AR9285, STA
* AR5416, STA
Obtained from: QCA, Linux ath9k
|
| 265029 |
27-Apr-2014 |
adrian |
Do a read-after-write to ensure the interrupt register update is flushed
to the hardware.
The QCA HAL has a comment noting that if this isn't done, modifications
to AR_IMR_S2 before AR_IMR is flushed may produce spurious interrupts.
Obtained from: QCA
|
| 264900 |
24-Apr-2014 |
adrian |
Fix the AR5211 power mode tracking stuff.
Tested:
* AR5211, STA mode
|
| 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
|
| 264798 |
23-Apr-2014 |
adrian |
Wrap the rate control re-init code in a lock, to serialise it with
concurrent updates from any completing transmits in other threads.
This was exposed when doing power save work - net80211 is constantly
doing reassociations and it's causing the rate control state to get
blanked out. This could cause the rate control code to assert.
This should be MFCed to stable/10 as it's a stability fix.
Tested:
* AR5416, STA
MFC after: 7 days
|
| 264720 |
21-Apr-2014 |
adrian |
Rewrite the cleanup code to, well, actually work right.
The existing cleanup code was based on the Atheros reference driver
from way back and stuff that was in Linux ath9k. It turned out to be ..
rather silly.
Specifically:
* The whole method of determining whether there's hardware-queued frames
was fragile and the BAW would never quite work right afterwards.
* The cleanup path wouldn't correctly pull apart aggregate frames in the
queue, so frames would not be freed and the BAW wouldn't be correctly
updated.
So to implement this:
* Pull the aggregate frames apart correctly and handle each separately;
* Make the atid->incomp counter just track the number of hardware queued
frames rather than try to figure it out from the BAW;
* Modify the aggregate completion path to handle it as a single frame
(atid->incomp tracks the one frame now, not the subframes) and
remove the frames from the BAW before completing them as normal frames;
* Make sure bf->bf_next is NULled out correctly;
* Make both aggregate session and non-aggregate path frames now be
handled via the incompletion path.
TODO:
* kill atid->incomp; the driver tracks the hardware queued frames
for each TID and so we can just use that.
This is a stability fix that should be merged back to stable/10.
Tested:
* AR5416, STA
MFC after: 7 days
|
| 264711 |
21-Apr-2014 |
adrian |
* Modify the debugging output from pause/resume to note the TID and STA
MAC
* Now that the paused < 0 bugs have been identified, make the DPRINTF()
a device_printf() again. Anything else that shows up here needs to be
fixed immediately.
Tested:
* AR5416, STA mode
MFC after: 7 days
|
| 264710 |
21-Apr-2014 |
adrian |
Make sure bf_next is NULL'ed out when we're completing up an aggregate
frame through the cleanup path.
Whilst here, fix the indenting for something I messed up.
Tested:
* AR5416, STA mode
|
| 264708 |
21-Apr-2014 |
adrian |
Fix a cleanup hang if cleanup gets called _during_ an active cleanup.
During power save testing I noticed that the cleanup code is being
called during a RUN->RUN state transition. It's because the net80211
stack is treating that (for reasons I don't quitey know yet) as a
reassociation and this calls the node cleanup code. The reason it's
seeing a RUN->RUN transition is because during active power save
stuff it's possible that the RUN->SLEEP and SLEEP->RUN transitions
happen so quickly that the deferred net80211 vap state code
"loses" a transition, namely the intermediary SLEEP transition.
So, this was causing the node reassociation code to sometimes be called
twice in quick succession and this would result in ath_tx_tid_cleanup()
to be called again. The code calling it would always call pause, and
then only call resume if the TID didn't have "cleanup_inprogress" set.
Unfortunately it didn't check if it was already set on entry, so it
would pause but not call resume. Thus, paused would be called more
than once (once before each entry into ath-tx_tid_cleanup()) but resume
would only be called once when the cleanup state was finished.
This doesn't entirely fix all of the issues seen in the cleanup path
but it's a necessary first step.
Since this is a stability fix, it should be merged to stable/10 at some
point.
Tested:
* AR5416, STA mode
MFC after: 7 days
|
| 264292 |
09-Apr-2014 |
adrian |
Add a function to check whether the given register can be accessed whilst
the chip is asleep.
It's AR5416 and later specific; I'll add a HAL method to generalise it
later.
Tested:
* AR5416, STA mode
|
| 264256 |
08-Apr-2014 |
adrian |
Add some debugging and forcing of the BAW to match what the current
tracked BAW actually is.
The net80211 code that completes a BAR will set tid->txa_start (the
BAW start) to whatever value was called when sending the BAR.
Now, in case there's bugs in my driver code that cause the BAW
to slip along, we should make sure that the new BAW we start
at is actually what we currently have it at, not what we've sent.
This totally breaks the specification and so this stays a printf().
If it happens then I need to know and fix it.
Whilst here, add some debugging updates:
* add TID logging to places where it's useful;
* use SEQNO().
|
| 264255 |
08-Apr-2014 |
adrian |
Don't do continue inside the scheduler loop; we really need to check
if we've hit the end of the list and cycled around to the first
node again.
Obtained from: DragonflyBSD
|
| 264254 |
08-Apr-2014 |
adrian |
Correct the actual definition of ath_tx_tid_filt_comp_single() to
match how it's used.
This is another bug that led to aggregate traffic hanging because
the BAW tracking stopped being accurate. In this instance, a filtered
frame that exceeded retries would return a non-error, which would
mean the caller would never remove it from the BAW. But it wouldn't
be added to the filtered list, so it would be lost forever. There'd
thus be a hole in the BAW that would never get transmitted and
this leads to a traffic hang.
Tested:
* Routerstation Pro, AR9220 AP
|
| 264253 |
08-Apr-2014 |
adrian |
Add a comment explaining the obvious.
|
| 264252 |
08-Apr-2014 |
adrian |
Don't resume a TID on each filtered frame completion - only do it if
we did suspend it.
The whole suspend/resume TID queue thing is supposed to be a matched
reference count - a subsystem (eg addba negotiation, BAR transmission,
filtered frames, etc) is supposed to call pause() once and then resume()
once.
ath_tx_tid_filt_comp_complete() is called upon the completion of any
filtered frame, regardless of whether the driver had aleady seen
a filtered frame and called pause().
So only call resume() if tid->isfiltered = 1, which indicates that
we had called pause() once.
This fixes a seemingly whacked and different problem - traffic hangs.
What was actually going on:
* There'd be some marginal link with crappy behaviour, causing filtered
frames and BAR TXing to occur;
* A BAR TX would occur, setting the new BAW (block-ack window) to seqno n;
* .. and pause() would be called, blocking further transmission;
* A filtered frame completion would occur from the hardware, but with
tid->isfiltered = 0 which indiciates we haven't actually marked
the queue yet as filtered;
* ath_tx_tid_filt_comp_complete() would call resume(), continuing
transmission;
* Some frames would be queued to the hardware, since the TID is now no
longer paused;
* .. and if some make it out and ACked successfully, the new BAW
may be seqno n+1 or more;
* .. then the BAR TX completes and sets the new seqno back to n.
At this point the BAW tracking would be loopy because the BAW
start was modified but the BAW ring buffer wasn't updated in lock
step.
Tested:
* Routerstation Pro + AR9220 AP
|
| 263618 |
22-Mar-2014 |
adrian |
Also set the AR5212 HAL power mode tracking in the right spot.
Tested:
* D-Link DWL-G650 NIC (AR2413), STA mode
|
| 263454 |
20-Mar-2014 |
adrian |
Throw the flush messages behind ATH_DEBUG_RESET as well.
These are needed to diagnose TX hangs that I and hiren are seeing.
Without it, the only way we'll see debugging is by having ATH_DEBUG_SW_TX
enabled and that is going to be very, very spammy.
ATH_DEBUG_RESET is fine; it's only going to be done during stuck beacon
situations in AP mode.
Whilst I'm here, and now that it's behind debugging, let's just disable
the "print only one" conditional. I'll eventually make it more tunable.
Tested:
* AR9220, hostap mode.
|
| 263418 |
20-Mar-2014 |
adrian |
Add some debugging code to print out if registers are touched whilst the
device is asleep.
This doesn't avoid logging errors for things that are actually OK to
access whilst the chip is asleep (eg, the RTC registers (0x7000->0x70ff
on the AR5416 and later.)
But, this is a pretty good indicator if things are accessed incorrectly.
Tested:
* AR5416, STA
|
| 263417 |
20-Mar-2014 |
adrian |
Shuffle ah_powerMode to be in a sane spot for the given power operation.
This way the state changes from sleep->awake before the registers are poked
and from awake->sleep after the registers are poked.
This way spurious warnings aren't printed by my (to be committed)
debugging code.
Tested:
* AR5416, STA
|
| 263416 |
20-Mar-2014 |
adrian |
Don't call ath_init() inside the lock.
Yes, this means that sc_invalid is slightly racy, but there are other
issues here which need fixing.
This fixes a source of eventual LORs - ath_init() grabs ATH_LOCK to do
work and releases it before it calls ieee80211_start_all().
ieee80211_start_all() will grab the net80211 comlock to iterate over
the VAPs.
TODO:
* .. I should just migrate the ieee80211_start_all() work to a
deferred task so it can be done later; it doesn't have to be
immediately done.
Tested:
* AR5416, 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
|
| 262930 |
08-Mar-2014 |
rpaulo |
Call ieee80211_dump_pkt() based on IFF_DUMPPKTS().
MFC after: 3 days
|
| 262375 |
23-Feb-2014 |
hiren |
PicoStation M2HP presents reg domain 0x2a which is not found in atheros or linux
reference code. Add this workaround for now.
Reviewed by: adrian
|
| 260444 |
08-Jan-2014 |
kevlo |
Rename definition of IEEE80211_FC1_WEP to IEEE80211_FC1_PROTECTED.
The origin of WEP comes from IEEE Std 802.11-1997 where it defines
whether the frame body of MAC frame has been encrypted using WEP
algorithm or not.
IEEE Std. 802.11-2007 changes WEP to Protected Frame, indicates
whether the frame is protected by a cryptographic encapsulation
algorithm.
Reviewed by: adrian, rpaulo
|
| 260363 |
06-Jan-2014 |
adrian |
Correctly remove entries from the relevant receive ath_buf list before
freeing them.
The current code would walk the list and call the buffer free, which
didn't remove it from any lists before pushing it back on the free list.
Tested: AR9485, STA mode
Noticed by: dillon@apollo.dragonflybsd.org
|
| 257284 |
28-Oct-2013 |
glebius |
- Provide necessary includes, that before came via if.h pollution.
- Remove unnecessary ones.
Sponsored by: Netflix
Sponsored by: Nginx, Inc.
|
| 257270 |
28-Oct-2013 |
cognet |
Include <sys/ktr.h>, since we need it if ATH_DEBUG is defined.
|
| 257241 |
28-Oct-2013 |
glebius |
Include necessary headers that now are available due to pollution
via if_var.h.
Sponsored by: Netflix
Sponsored by: Nginx, Inc.
|
| 257176 |
26-Oct-2013 |
glebius |
The r48589 promised to remove implicit inclusion of if_var.h soon. Prepare
to this event, adding if_var.h to files that do need it. Also, include
all includes that now are included due to implicit pollution via if_var.h
Sponsored by: Netflix
Sponsored by: Nginx, Inc.
|
| 256666 |
17-Oct-2013 |
rpaulo |
Add a missing comma.
|
| 256658 |
17-Oct-2013 |
rpaulo |
Move a lot of debugging printf's to DPRINTF.
Approved by: adrian
MFC after: 2 weeks
|
| 256139 |
08-Oct-2013 |
adrian |
Add channel survey support to the AR5212 HAL.
The AR5212 series of MACs implement the same channel counters as the
later 11n chips - except, of course, the 11n specific counter (extension
channel busy.)
This allows users of these NICs to use 'athsurvey' to see how busy their
current channel is.
Tested:
* AR5212, AR2413 NICs, STA mode
Approved by: re@ (gleb)
|
| 254957 |
27-Aug-2013 |
adrian |
Use the new ieee80211_tx_complete() function.
|
| 254435 |
17-Aug-2013 |
adrian |
Log the MAC address of the node in question rather than the pointer.
|
| 252385 |
29-Jun-2013 |
adrian |
Don't log anything if npkts == 0.
This occurs at RX DMA start, even though the RX FIFO has plenty of
space. I'll go figure out why, but this shouldn't cause people to
be spammed by these messages.
|
| 252239 |
26-Jun-2013 |
adrian |
Extend the AHB code to work on chips besides the AR9130.
The AHB code:
* hard coded the AR9130 device id;
* assumes a 4k flash calibration space.
This code now extends this:
* hint.ath.X.eepromsize now overrides the eeprom range, instead of 4k
* hint.ath.X.device_id and hint.ath.X.vendor_id can now be overridden.
Tested:
* AR9330 board (Carambola 2)
|
| 252236 |
26-Jun-2013 |
adrian |
Add a HAL local routine to map the 2GHz channel frequency to an IEEE
channel.
There's some HAL code in the AR9300 HAL that requires a back-mapping
and using the net80211 code isn't appropriate here.
|
| 251742 |
14-Jun-2013 |
adrian |
Add in an initial WB225 (AR9485 + AR3012 BT) combo profile.
This hasn't yet been tested as unfortunately the AR3012 I have doesn't
have the "real" firmware on it; it shipped with the cut down HCI firmware
that only understands enough to accept a new firmware image.
* Linux ath9k (GPIO constants)
|
| 251730 |
14-Jun-2013 |
adrian |
Initial AR9485/AR933x 1x1 LNA diversity work.
* Add the LNA configuration table entries for AR933x/AR9485
* Add a chip-dependent LNA signal level delta in the startup path
* Add a TODO list for the stuff I haven't yet ported over but
I haven't.
Tested:
* AR9462 with LNA diversity enabled
|
| 251656 |
12-Jun-2013 |
adrian |
Set the antenna "config group" field.
The reference HAL pushes a config group parameter to the driver layer
to inform it which particular chip behaviour to implement.
This particular value tags it as an AR9285.
|
| 251655 |
12-Jun-2013 |
adrian |
Migrate the LNA mixing diversity machinery from the AR9285 HAL to the driver.
The AR9485 chip and AR933x SoC both implement LNA diversity.
There are a few extra things that need to happen before this can be
flipped on for those chips (mostly to do with setting up the different
bias values and LNA1/LNA2 RSSI differences) but the first stage is
putting this code into the driver layer so it can be reused.
This has the added benefit of making it easier to expose configuration
options and diagnostic information via the ioctl API. That's not yet
being done but it sure would be nice to do so.
Tested:
* AR9285, with LNA diversity enabled
* AR9285, with LNA diversity disabled in EEPROM
|
| 251643 |
12-Jun-2013 |
adrian |
Remove the AR9285 specific structure for LNA diversity and use the HAL.
The AR9300 HAL update included the LNA diversity configuration information
so it can be used in the AR9485 configuration code.
|
| 251606 |
10-Jun-2013 |
adrian |
Add another comment about WB195 (AR9285+AR3011) when using ASPM.
|
| 251487 |
07-Jun-2013 |
adrian |
Bring over the initial static bluetooth coexistence configuration
for the WB195 combo NIC - an AR9285 w/ an AR3011 USB bluetooth NIC.
The AR3011 is wired up using a 3-wire coexistence scheme to the AR9285.
The code in if_ath_btcoex.c sets up the initial hardware mapping
and coexistence configuration. There's nothing special about it -
it's static; it doesn't try to configure bluetooth / MAC traffic priorities
or try to figure out what's actually going on. It's enough to stop basic
bluetooth traffic from causing traffic stalls and diassociation from
the wireless network.
To use this code, you must have the above NIC. No, it won't work
for the AR9287+AR3012, nor the AR9485, AR9462 or AR955x combo cards.
Then you set a kernel hint before boot or before kldload, where 'X'
is the unit number of your AR9285 NIC:
# kenv hint.ath.X.btcoex_profile=wb195
This will then appear in your boot messages:
[100482] athX: Enabling WB195 BTCOEX
This code is going to evolve pretty quickly (well, depending upon my
spare time) so don't assume the btcoex API is going to stay stable.
In order to use the bluetooth side, you must also load in firmware using
ath3kfw and the binary firmware file (ath3k-1.fw in my case.)
Tested:
* AR9280, no interference
* WB195 - AR9285 + AR3011 combo; STA mode; basic bluetooth inquiries
were enough to cause traffic stalls and disassociations. This has
stopped with the btcoex profile code.
TODO:
* Importantly - the AR9285 needs ASPM disabled if bluetooth coexistence
is enabled. No, I don't know why. It's likely some kind of bug to do
with the AR3011 sending bluetooth coexistence signals whilst the device
is asleep. Since we don't actually sleep the MAC just yet, it shouldn't
be a problem. That said, to be totally correct:
+ ASPM should be disabled - upon attach and wakeup
+ The PCIe powersave HAL code should never be called
Look at what the ath9k driver does for inspiration.
* Add WB197 (AR9287+AR3012) support
* Add support for the AR9485, which is another combo like the AR9285
* The later NICs have a different signaling mechanism between the MAC
and the bluetooth device; I haven't even begun to experiment with
making that HAL code work. But it should be a lot more automatic.
* The hardware can do much more interesting traffic weighting with
bluetooth and wifi traffic. None of this is currently used.
Ideally someone would code up something to watch the bluetooth traffic
GPIO (via an interrupt) and then watch it go high/low; then figure out
what the bluetooth traffic is and adjust things appropriately.
* If I get the time I may add in some code to at least track this stuff
and expose statistics. But it's up to someone else to experiment with
the bluetooth coexistence support and add the interesting stuff (like
"real" detection of bulk, audio, etc bluetooth traffic patterns and
change wifi parameters appropriately - eg, maximum aggregate length,
transmit power, using quiet time to control TX duty cycle, etc.)
|
| 251484 |
07-Jun-2013 |
adrian |
Add accessor macros for the bluetooth coexistence routines.
|
| 251483 |
07-Jun-2013 |
adrian |
Add bluetooth fixes to the AR5416/AR92xx HAL:
* Call the bluetooth setup function during the reset path, so the bluetooth
settings are actually initialised.
* Call the AR9285 diversity functions during bluetooth setup; so the AR9285
diversity and antenna configuration registers are correctly programmed
* Misc debugging info.
Tested:
* AR9285+AR3011 bluetooth combo; this code itself doesn't enable bluetooth
coexistence but it's part of what I'm currently using.
|
| 251442 |
05-Jun-2013 |
adrian |
Enable slow diversity combining for the AR9285.
Now that I understand what's going on - and the RX antenna array maps
to what the receive LNA configuration actually is - I feel comfortable
in enabling this.
If people do have issues with this, there's enough debugging now available
that we have a chance to diagnose it without writing it up as 'weird
crap.'
Tested:
* AR9285 STA w/ diversity combining enabled in EEPROM
TODO:
* (More) testing in hostap mode
|
| 251441 |
05-Jun-2013 |
adrian |
As a temporary work-around (read: until there's a nice API for exposing
and controlling this form of antenna diversity) - print out the AR9285
antenna diversity configuration at attach time.
This will help track down and diagose if/when people have connectivity
issues on cards (eg if they connect a single antenna to LNA1, yet the
card has RX configured to only occur on LNA2.)
Tested:
* AR9285 w/ antenna diversity enabled in EEPROM;
* AR9285 w/ antenna diversity disabled in EEPROM; mapping only to a
single antenna (LNA1.)
|
| 251401 |
05-Jun-2013 |
adrian |
Implement a bit of a hack to store the AR9285/AR9485 RX LNA configuration in
the RX antenna field.
The AR9285/AR9485 use an LNA mixer to determine how to combine the signals
from the two antennas. This is encoded in the RSSI fields (ctl/ext) for
chain 2. So, let's use that here.
This maps RX antennas 0->3 to the RX mixer configuration used to
receive a frame. There's more that can be done but this is good enough
to diagnose if the hardware is doing "odd" things like trying to
receive frames on LNA2 (ie, antenna 2 or "alt" antenna) when there's
only one antenna connected.
Tested:
* AR9285, STA mode
|
| 251400 |
05-Jun-2013 |
adrian |
Add a new capability flag to announce that the chip implements LNA mixing
for the RX path.
This is different to the div comb HAL flag, that says it actually
can use this for RX diversity (the "slow" diversity path implemented
but disabled in the AR9285 HAL code.)
Tested:
* AR9285, STA operation
|
| 251399 |
05-Jun-2013 |
adrian |
Document the AR9285/AR9485 LNA configuration information that's
stored in the ctl/ext RSSI field for chain 2.
Tested:
* AR9285, STA
|
| 251360 |
04-Jun-2013 |
adrian |
Add the combined (mixed) diversity support capability bit for the
AR9285/AR9485.
|
| 251342 |
03-Jun-2013 |
adrian |
Fix the order of TX shutdown and reset.
* Grab the reset lock first, so any subsequent interrupt, TX, RX work
will fail
* Then shut down interrupts
* Then wait for TX/RX to finish running
At this point no further work will be running, so it's safe to do the
reset path code.
PR: kern/179232
|
| 251340 |
03-Jun-2013 |
adrian |
Fix receive on the AR9285 (Kite) with only one antenna connected.
The main problem here is that fast and driver RX diversity isn't actually
configured; I need to figure out why that is. That said, this makes
the single-antenna connected AR9285 and AR2427 (AR9285 w/ no 11n) work
correctly.
PR: kern/179269
|
| 251099 |
29-May-2013 |
adrian |
Turn the reassociate debug print into a DPRINTF.
|
| 251090 |
29-May-2013 |
adrian |
Shuffle around the cleanup unpause calls a bit.
|
| 251014 |
26-May-2013 |
adrian |
Migrate ath(4) to now use if_transmit instead of the legacy if_start
and if queue mechanism; also fix up (non-11n) TX fragment handling.
This may result in a bit of a performance drop for now but I plan on
debugging and resolving this at a later stage.
Whilst here, fix the transmit path so fragment transmission works.
The TX fragmentation handling is a bit more special. In order to
correctly transmit TX fragments, there's a bunch of corner cases that
need to be handled:
* They must be transmitted back to back, in the same order..
* .. ie, you need to hold the TX lock whilst transmitting this
set of fragments rather than interleaving it with other MSDUs
destined to other nodes;
* The length of the next fragment is required when transmitting, in
order to correctly set the NAV field in the current frame to the
length of the next frame; which requires ..
* .. that we know the transmit duration of the next frame, which ..
* .. requires us to set the rate of all fragments to the same length,
or make the decision up-front, etc.
To facilitate this, I've added a new ath_buf field to describe the
length of the next fragment. This avoids having to keep the mbuf
chain together. This used to work before my 11n TX path work because
the ath_tx_start() routine would be handed a single mbuf with m_nextpkt
pointing to the next frame, and that would be maintained all the way
up to when the duration calculation was done. This doesn't hold
true any longer - the actual queuing may occur at any point in the
future (think ath_node TID software queuing) so this information
needs to be maintained.
Right now this does work for non-11n frames but it doesn't at all
enforce the same rate control decision for all frames in the fragment.
I plan on fixing this in a followup commit.
RTS/CTS has the same issue, I'll look at fixing this in a subsequent
commit.
Finaly, 11n fragment support requires the driver to have fully
decided what the rate scenario setup is - including 20/40MHz,
short/long GI, STBC, LDPC, number of streams, etc. Right now that
decision is (currently) made _after_ the NAV field value is updated.
I'll fix all of this in subsequent commits.
Tested:
* AR5416, STA, transmitting 11abg fragments
* AR5416, STA, 11n fragments work but the NAV field is incorrect for
the reasons above.
TODO:
* It would be nice to be able to queue mbufs per-node and per-TID so
we can only queue ath_buf entries when it's time to assemble frames
to send to the hardware.
But honestly, we should just do that level of software queue management
in net80211 rather than ath(4), so I'm going to leave this alone for now.
* More thorough AP, mesh and adhoc testing.
* Ensure that net80211 doesn't hand us fragmented frames when A-MPDU has
been negotiated, as we can't do software retransmission of fragments.
* .. set CLRDMASK when transmitting fragments, just to ensure.
|
| 250866 |
21-May-2013 |
adrian |
Implement a separate hardware queue threshold for aggregate and non-aggr
traffic.
When transmitting non-aggregate traffic, we need to keep the hardware
busy whilst transmitting or small bursts in txdone/tx latency will
kill us.
This restores non-aggregate iperf performance, especially when doing
TDMA.
Tested:
* AR5416<->AR5416, TDMA
* AR5416 STA <-> AR9280 AP
|
| 250865 |
21-May-2013 |
adrian |
Enable the use of TDMA on an 802.11n channel (with aggregation disabled,
of course.)
There's a few things that needed to happen:
* In case someone decides to set the beacon transmission rate to be
at an MCS rate, use the MCS-aware version of the duration calculation
to figure out how long the received beacon frame was.
* If TxOP enforcing is available on the hardware and we're doing TDMA,
enable it after a reset and set the TDMA guard interval to zero.
This seems to behave fine.
TODO:
* Although I haven't yet seen packet loss, the PHY errors that would be
triggered (specifically Transmit-Override-Receive) aren't enabled
by the 11n HAL. I'll have to do some work to enable these PHY errors
for debugging.
What broke:
* My recent changes to the TX queue handling has resulted in the driver
not keeping the hardware queue properly filled when doing non-aggregate
traffic. I have a patch to commit soon which fixes this situation
(albeit by reminding me about how my ath driver locking isn't working
out, sigh.)
So if you want to test this without updating to the next set of patches
that I commit, just bump the sysctl dev.ath.X.hwq_limit from 2 to 32.
Tested:
* AR5416 <-> AR5416, with ampdu disabled, HT40, 5GHz, MCS12+Short-GI.
I saw 30mbit/sec in both directions using a bidirectional UDP test.
|
| 250856 |
21-May-2013 |
adrian |
Fix build break - the SetCapability calls return HAL_BOOL,
not HAL_STATUS.
|
| 250841 |
21-May-2013 |
adrian |
Extend the TXOP enforce capability to support checking whether it's
supported.
|
| 250824 |
20-May-2013 |
adrian |
Make the HT rate duration calculation work for MCS rates > 15.
|
| 250796 |
19-May-2013 |
adrian |
More non-ATH_DEBUG build fixes.
|
| 250795 |
19-May-2013 |
adrian |
Since we're now using the ah pointer, always declare it.
This fixes non-DEBUG builds.
|
| 250783 |
18-May-2013 |
adrian |
Be (very) careful about how to add more TX DMA work.
The list-based DMA engine has the following behaviour:
* When the DMA engine is in the init state, you can write the first
descriptor address to the QCU TxDP register and it will work.
* Then when it hits the end of the list (ie, it either hits a NULL
link pointer, OR it hits a descriptor with VEOL set) the QCU
stops, and the TxDP points to the last descriptor that was transmitted.
* Then when you want to transmit a new frame, you can then either:
+ write the head of the new list into TxDP, or
+ you write the head of the new list into the link pointer of the
last completed descriptor (ie, where TxDP points), then kick
TxE to restart transmission on that QCU>
* The hardware then will re-read the descriptor to pick up the link
pointer and then jump to that.
Now, the quirks:
* If you write a TxDP when there's been no previous TxDP (ie, it's 0),
it works.
* If you write a TxDP in any other instance, the TxDP write may actually
fail. Thus, when you start transmission, it will re-read the last
transmitted descriptor to get the link pointer, NOT just start a new
transmission.
So the correct thing to do here is:
* ALWAYS use the holding descriptor (ie, the last transmitted descriptor
that we've kept safe) and use the link pointer in _THAT_ to transmit
the next frame.
* NEVER write to the TxDP after you've done the initial write.
* .. also, don't do this whilst you're also resetting the NIC.
With this in mind, the following patch does basically the above.
* Since this encapsulates Sam's issues with the QCU behaviour w/ TDMA,
kill the TDMA special case and replace it with the above.
* Add a new TXQ flag - PUTRUNNING - which indicates that we've started
DMA.
* Clear that flag when DMA has been shutdown.
* Ensure that we're not restarting DMA with PUTRUNNING enabled.
* Fix the link pointer logic during TXQ drain - we should always ensure
the link pointer does point to something if there's a list of frames.
Having it be NULL as an indication that DMA has finished or during
a reset causes trouble.
Now, given all of this, i want to nuke axq_link from orbit. There's now HAL
methods to get and set the link pointer of a descriptor, so what we
should do instead is to update the right link pointer.
* If there's a holding descriptor and an empty TXQ list, set the
link pointer of said holding descriptor to the new frame.
* If there's a non-empty TXQ list, set the link pointer of the
last descriptor in the list to the new frame.
* Nuke axq_link from orbit.
Note:
* The AR9380 doesn't need this. FIFO TX writes are atomic. As long as
we don't append to a list of frames that we've already passed to the
hardware, all of the above doesn't apply. The holding descriptor stuff
is still needed to ensure the hardware can re-read a completed
descriptor to move onto the next one, but we restart DMA by pushing in
a new FIFO entry into the TX QCU. That doesn't require any real
gymnastics.
Tested:
* AR5210, AR5211, AR5212, AR5416, AR9380 - STA mode.
|
| 250777 |
18-May-2013 |
adrian |
Re-add some code to exclude transmitting if we're in reset.
This fixes some "transmitting during reset" bugs that crept in after
I messed around with this part of the transmit path.
|
| 250735 |
17-May-2013 |
adrian |
Add some more debugging printf()s to complain if the ath_buf tx queue
doesn't match the actual hardware queue this frame is queued to.
I'm trying to ensure that the holding buffers are actually being queued
to the same TX queue as the holding buffer that they end up on.
I'm pretty sure this is all correct so if this complains, it'll be due
to some kind of subtle broken-ness that needs fixing.
This is only done for legacy hardware, not EDMA hardware.
Tested:
* AR5416 STA mode, very lightly
|
| 250705 |
16-May-2013 |
adrian |
Tidy up the debugging - don't bother printing out TID pointers; now
that we are printing out the MAC address in these fields, just printing
out the TID is enough.
|
| 250704 |
16-May-2013 |
adrian |
Limit the number of software queued frames when doing non-aggregation.
This should prevent the TX queue being filled with non-aggregate frames,
causing starvation and non-fair queue behaviour.
|
| 250703 |
16-May-2013 |
adrian |
Dump out the holding buffer descriptor contents and addresses stopping DMA.
|
| 250665 |
15-May-2013 |
adrian |
Implement my first cut at "correct" node power-save and
PS-POLL support.
This implements PS-POLL awareness i nthe
* Implement frame "leaking", which allows for a software queue
to be scheduled even though it's asleep
* Track whether a frame has been leaked or not
* Leak out a single non-AMPDU frame when transmitting aggregates
* Queue BAR frames if the node is asleep
* Direct-dispatch the rest of control and management frames.
This allows for things like re-association to occur (which involves
sending probe req/resp as well as assoc request/response) when
the node is asleep and then tries reassociating.
* Limit how many frames can set in the software node queue whilst
the node is asleep. net80211 is already buffering frames for us
so this is mostly just paranoia.
* Add a PS-POLL method which leaks out a frame if there's something
in the software queue, else it calls net80211's ps-poll routine.
Since the ath PS-POLL routine marks the node as having a single frame
to leak, either a software queued frame would leak, OR the next queued
frame would leak. The next queued frame could be something from the
net80211 power save queue, OR it could be a NULL frame from net80211.
TODO:
* Don't transmit further BAR frames (eg via a timeout) if the node is
currently asleep. Otherwise we may end up exhausting management frames
due to the lots of queued BAR frames.
I may just undo this bit later on and direct-dispatch BAR frames
even if the node is asleep.
* It would be nice to burst out a single A-MPDU frame if both ends
support this. I may end adding a FreeBSD IE soon to negotiate
this power save behaviour.
* I should make STAs timeout of power save mode if they've been in power
save for more than a handful of seconds. This way cards that get
"stuck" in power save mode don't stay there for the "inactivity" timeout
in net80211.
* Move the queue depth check into the driver layer (ath_start / ath_transmit)
rather than doing it in the TX path.
* There could be some naughty corner cases with ps-poll leaking.
Specifically, if net80211 generates a NULL data frame whilst another
transmitter sends a normal data frame out net80211 output / transmit,
we need to ensure that the NULL data frame goes out first.
This is one of those things that should occur inside the VAP/ic TX lock.
Grr, more investigations to do..
Tested:
* STA: AR5416, AR9280
* AP: AR5416, AR9280, AR9160
|
| 250619 |
13-May-2013 |
adrian |
Add ALQ beacon debugging.
|
| 250618 |
13-May-2013 |
adrian |
Support sending ATH_ALQ messages with no payload.
|
| 250611 |
13-May-2013 |
adrian |
Improve the debugging output - use the MAC address rather than various
pointer values everywhere.
|
| 250609 |
13-May-2013 |
adrian |
Since the node state is 100% back under the TX lock, just kill the use
of atomics.
I'll re-think this nonsense later.
|
| 250608 |
13-May-2013 |
adrian |
Oops, commit the other half of r250606.
|
| 250607 |
13-May-2013 |
adrian |
This lock only protects the rate control state for now, mention this.
|
| 250606 |
13-May-2013 |
adrian |
Begin tidying up the reassociation and node sleep/wakeup paths.
* Move the node sleep/wake state under the TX lock rather than the
node lock. Let's leave the node lock protecting rate control only
for now.
* When reassociating, various state needs to be cleared. For example,
the aggregate session needs to be torn down, including any pending
aggregation negotiation and BAR TX waiting.
* .. and we need to do a "cleanup" pass since frames in the hardware
TX queue need to be transmitted.
Modify ath_tx_tid_cleanup() to be called with the TX lock held and push
frames into a completion list. This allows for the cleanup to be
done atomically for all TIDs in a node rather than grabbing and
releasing the TX lock each time.
|
| 250444 |
10-May-2013 |
adrian |
Make sure the holding descriptor and link pointer are both freed during
a non-loss reset.
When the drain functions are called, the holding descriptor and link pointers
are NULLed out.
But when the processq function is called during a non-loss reset, this
doesn't occur. So the next time a DMA occurs, it's chained to a descriptor
that no longer exists and the hardware gets angry.
Tested:
* AR5416, STA mode; use sysctl dev.ath.X.forcebstuck=1 to force a non-loss
reset.
TODO:
* Further AR9380 testing just to check that the behaviour for the EDMA
chips is sane.
PR: kern/178477
|
| 250408 |
09-May-2013 |
adrian |
Update the holding buffer locking for EDMA.
|
| 250391 |
08-May-2013 |
adrian |
Fix the holding descriptor logic to actually be "right" (for values
of "right".)
Flip back on the "always continue TX DMA using the holding descriptor"
code - by always setting ATH_BUF_BUSY and never setting axq_link to NULL.
Since the holding descriptor is accessed via txq->axq_link and _that_
is done behind the TXQ lock rather than the TX path lock, the holding
descriptor stuff itself needs to be behind the TXQ lock.
So, do the mental gymnastics needed to do this.
I've not seen any of the hardware failures that I was seeing when
I last tried to do this.
Tested:
* AR5416, STA mode
|
| 250356 |
08-May-2013 |
adrian |
This shouldn't have made it into this commit, sorry.
|
| 250355 |
08-May-2013 |
adrian |
Revert a previous commit - this is causing hardware errors.
I'm not sure why this is failing. The holding descriptor should be being
re-read when starting DMA of the next frame. Obviously something here
isn't totally correct.
I'll review the TX queue handling and see if I can figure out why this
is failing. I'll then re-revert this patch out and use the holding
descriptor again.
|
| 250346 |
08-May-2013 |
adrian |
Implement STBC receive frame statistics.
The AR9280 and later can receive STBC. This adds some statistics
tracking to count these frames.
A patch to athstats will be forthcoming.
|
| 250326 |
07-May-2013 |
adrian |
Re-work how transmit buffer limits are enforced - partly to fix the PR,
but partly to just tidy up things.
The problem here - there are too many TX buffers in the queue! By the
time one needs to transmit an EAPOL frame (for this PR, it's the response
to the group rekey notification from the AP) there are no ath_buf entries
free and the EAPOL frame doesn't go out.
Now, the problem!
* Enforcing the TX buffer limitation _before_ we dequeue the frame?
Bad idea. Because..
* .. it means I can't check whether the mbuf has M_EAPOL set.
The solution(s):
* De-queue the frame first
* Don't bother doing the TX buffer minimum free check until after
we know whether it's an EAPOL frame or not.
* If it's an EAPOL frame, allocate the buffer from the mgmt pool
rather than the default pool.
Whilst I'm here:
* Add a tweak to limit how many buffers a single node can acquire.
* Don't enforce that for EAPOL frames.
* .. set that to default to 1/4 of the available buffers, or 32,
whichever is more sane.
This doesn't fix issues due to a sleeping node or a very poor performing
node; but this doesn't make it worse.
Tested:
* AR5416 STA, TX'ing 100+ mbit UDP to an AP, but only 50mbit being received
(thus the TX queue fills up.)
* .. with CCMP / WPA2 encryption configured
* .. and the group rekey time set to 10 seconds, just to elicit the
behaviour very quickly.
PR: kern/138379
|
| 250325 |
07-May-2013 |
adrian |
Simplify this bit of code!
|
| 250229 |
04-May-2013 |
adrian |
The holding buffer logic needs to be used for _all_ transmission, not
just "when the queue is busy."
After talking with the MAC team, it turns out that the linked list
implementation sometimes will not accept a TxDP update and will
instead re-read the link pointer. So even if the hardware has
finished transmitting a chain and has hit EOL/VEOL, it may still
re-read the link pointer to begin transmitting again.
So, always set ATH_BUF_BUSY on the last buffer in the chain (to
mark the last descriptor as the holding descriptor) and never
blank the axq_link pointer.
Tested:
* AR5416, STA mode
TODO:
* much more thorough testing with the pre-11n NICs, just to verify
that they behave the same way.
* test TDMA on the 11n and non-11n hardware.
|
| 250166 |
02-May-2013 |
adrian |
Add device identification and probe/attach support for the QCA9565.
The QCA9565 is a 1x1 2.4GHz 11n chip with integrated on-chip bluetooth.
The AR9300 HAL already has support for this chip; it just wasn't
included in the probe/attach path.
Tested:
* This commit brought to you over a QCA9565 wifi connection from
FreeBSD.
* .. ie, basic STA, pings, no iperf or antenna diversity checking just yet.
|
| 250041 |
29-Apr-2013 |
adrian |
Debugging changes!
* That lock isn't actually held during reset - just the whole TX/RX path
is paused. So, remove the assertion.
* Log the TX queue status - how many hardware frames are active in the
MAC and whether the queue is active.
|
| 249958 |
26-Apr-2013 |
adrian |
Conditionally compile this only if ATH_DEBUG is defined.
|
| 249957 |
26-Apr-2013 |
adrian |
Dump the entire TXQ descriptor contents during a reset, rather than only
completed descriptors.
|
| 249715 |
21-Apr-2013 |
adrian |
When doing BAW tracking, don't dereference a NULL pointer if the BAW
slot is actually NULL.
|
| 249713 |
20-Apr-2013 |
adrian |
There's some races (likely in the BAR handling, sigh) which is causing
the pause/resume code to not be called completely symmetrically.
I'll chase down the root cause of that soon; this at least works around
the bug and tells me when it happens.
|
| 249662 |
19-Apr-2013 |
adrian |
Initialise the chainmask fields regardless of whether 11n support
is compiled in or not.
This fixes issues with people running -HEAD but who build modules
without doing a "make buildkernel KERNCONF=XXX", thus picking up
opt_*.h. The resulting module wouldn't have 11n enabled and the
chainmask configuration would just be plain wrong.
|
| 249642 |
19-Apr-2013 |
adrian |
Add a debug statement to log the currently chosen chainmask configuration.
|
| 249641 |
19-Apr-2013 |
adrian |
.. don't know how this snuck into this commit. Sorry.
Fix compile build before anyone notices.
|
| 249640 |
19-Apr-2013 |
adrian |
Print out the chainmask configuration.
|
| 249639 |
19-Apr-2013 |
adrian |
Use uint32_t for fields that are fetched via ath_hal_getcapability().
|
| 249580 |
17-Apr-2013 |
adrian |
Setup needed tables for TPC on AR5416->AR9287 chips.
* Add ah_ratesArray[] to the ar5416 HAL state - this stores the maximum
values permissable per rate.
* Since different chip EEPROM formats store this value in a different place,
store the HT40 power detector increment value in the ar5416 HAL state.
* Modify the target power setup code to store the maximum values in the
ar5416 HAL state rather than using a local variable.
* Add ar5416RateToRateTable() - to convert a hardware rate code to the
ratesArray enum / index.
* Add ar5416GetTxRatePower() - which goes through the gymnastics required
to correctly calculate the target TX power:
+ Add the power detector increment for ht40;
+ Take the power offset into account for AR9280 and later;
+ Offset the TX power correctly when doing open-loop TX power control;
+ Enforce the per-rate maximum value allowable.
Note - setting a TPC value of 0x0 in the TX descriptor on (at least)
the AR9160 resulted in the TX power being very high indeed. This didn't
happen on the AR9220. I'm guessing it's a chip bug that was fixed at
some point. So for now, just assume the AR5416/AR5418 and AR9130 are
also suspect and clamp the minimum value here at 1.
Tested:
* AR5416, AR9160, AR9220 hostap, verified using (2GHz) spectrum analyser
* Looked at target TX power in TX descriptor (using athalq) as well as TX
power on the spectrum analyser.
TODO:
* The TX descriptor code sets the target TX power to 0 for AR9285 chips.
I'm not yet sure why. Disable this for TPC and ensure that the TPC
TX power is set.
* AR9280, AR9285, AR9227, AR9287 testing!
* 5GHz testing!
Quirks:
* The per-packet TPC code is only exercised when the tpc sysctl is set
to 1. (dev.ath.X.tpc=1.) This needs to be done before you bring the
interface up.
* When TPC is enabled, setting the TX power doesn't end up with a call
through to the HAL to update the maximum TX power. So ensure that
you set the TPC sysctl before you bring the interface up and configure
a lower TX power or the hardware will be clamped by the lower TX
power (at least until the next channel change.)
Thanks to Qualcomm Atheros for all the hardware, and Sam Leffler for use
of his spectrum analyser to verify the TX channel power.
|
| 249579 |
17-Apr-2013 |
adrian |
Use the TPC bank by default for AR9160.
Tested:
* AR9160, hostap, verified TX power using (2GHz) spectrum analyser
TODO:
* 5GHz verification!
|
| 249578 |
17-Apr-2013 |
adrian |
Update the rate series setup code to use the decisions already made in
ath_tx_rate_fill_rcflags(). Include setting up the TX power cap in the
rate scenario setup code being passed to the HAL.
Other things:
* add a tx power cap field in ath_rc.
* Add a three-stream flag in ath_rc.
* Delete the LDPC flag from ath_rc - it's not a per-rate flag, it's a
global flag for the transmission.
|
| 249569 |
16-Apr-2013 |
adrian |
Use the new net80211 method to fetch the node TX power, rather than
directly referencing ni->ni_txpower.
This provides the hardware with a slightly more accurate idea of
the maximum TX power to be using.
This is part of a series to get per-packet TPC to work (better).
Tested:
* AR5416, hostap mode
|
| 249565 |
16-Apr-2013 |
adrian |
Use a per-RX-queue deferred list, rather than a single deferred list for
both queues.
Since ath_rx_pkt() does multi-mbuf frame recombining based on the RX queue,
this needs to occur.
Tested:
* AR9380 (XB112), hostap mode
|
| 249517 |
15-Apr-2013 |
adrian |
Now that the register definitions are in -HEAD, enable this.
|
| 249516 |
15-Apr-2013 |
adrian |
Bring over some AR9271 register definitions from the QCA HAL.
Obtained from: Qualcomm Atheros
|
| 249386 |
11-Apr-2013 |
adrian |
Always enable TXOK interrupts when setting up TX queues for EDMA NICs.
|
| 249284 |
08-Apr-2013 |
adrian |
Fix this to compile when ATH_DEBUG_ALQ is defined but ATH_DEBUG isn't.
|
| 249137 |
05-Apr-2013 |
adrian |
Add a new TX power field - it's inteded to be used where low TX power
is configured for higher rates (lower than max) but higher TX power
is configured for the lower rates, above the configured cap, to improve
long distance behaviour.
|
| 249131 |
05-Apr-2013 |
adrian |
HAL additions to enable MCI Bluetooth coexistence in the AR9300 HAL.
* Add the rest of the missing GPIO output mux types;
* Add in a new debug category;
* And a new MCI btcoex configuration option in ath_hal.ah_config
Obtained from: Qualcomm Atheros
|
| 249088 |
04-Apr-2013 |
adrian |
Update comments!
|
| 249085 |
04-Apr-2013 |
adrian |
Fix the busdma logic to work with EDMA chipsets when using bounce
buffers (ie, >4GB on amd64.)
The underlying problem was that PREREAD doesn't sync the mbuf
with the DMA memory (ie, bounce buffer), so the bounce buffer may
have had stale information. Thus it was always considering the
buffer completed and things just went off the rails.
This change does the following:
* Make ath_rx_pkt() always consume the mbuf somehow; it no longer
passes error mbufs (eg CRC errors, crypt errors, etc) back up
to the RX path to recycle. This means that a new mbuf is always
allocated each time, but it's cleaner.
* Push the RX buffer map/unmap to occur in the RX path, not
ath_rx_pkt(). Thus, ath_rx_pkt() now assumes (a) it has to consume
the mbuf somehow, and (b) that it's already been unmapped and
synced.
* For the legacy path, the descriptor isn't mapped, it comes out of
coherent, DMA memory anyway. So leave it there.
* For the EDMA path, the RX descriptor has to be cleared before
its passed to the hardware, so that when we check with
a POSTREAD sync, we actually get either a blank (not finished)
or a filled out descriptor (finished.) Otherwise we get stale
data in the DMA memory.
* .. so, for EDMA RX path, we need PREREAD|PREWRITE to sync the
data -> DMA memory, then POSTREAD|POSTWRITE to finish syncing
the DMA memory -> data.
* Whilst we're here, make sure that in EDMA buffer setup (ie,
bzero'ing the descriptor part) is done before the mbuf is
map/synched.
NOTE: there's been a lot of commits besides this one with regards to
tidying up the busdma handling in ath(4). Please check the recent
commit history.
Discussed with and thanks to: scottl
Tested:
* AR5416 (non-EDMA) on i386, with the DMA tag for the driver
set to 2^^30, not 2^^32, STA
* AR9580 (EDMA) on i386, as above, STA
* User - tested AR9380 on amd64 with 32GB RAM.
PR: kern/177530
|
| 249000 |
02-Apr-2013 |
adrian |
Mark a couple of places where I think the dmamap isn't being unmapped
before the TX path is being aborted.
Right now it's in the TDMA code and I can live with that; but it really
should get fixed.
I'll do a more thorough audit of this code soon.
|
| 248999 |
02-Apr-2013 |
adrian |
Some TX dmamap cleanups.
* Don't use BUS_DMA_ALLOCNOW for descriptor DMA maps; we never use
bounce buffers for the descriptors themselves.
* Add some XXX's to mark where the ath_buf has its mbuf ripped from
underneath it without actually cleaning up the dmamap. I haven't
audited those particular code paths to see if the DMA map is guaranteed
to be setup there; I'll do that later.
* Print out a warning if the descdma tidyup code is given some descriptors
w/ maps to free. Ideally the owner will free the mbufs and unmap
the descriptors before freeing the descriptor/ath_buf pairs, but
right now that's not guaranteed to be done.
Reviewed by: scottl (BUS_DMA_ALLOCNOW tag)
|
| 248998 |
02-Apr-2013 |
adrian |
Add a missing unmap; if we're freeing this mbuf then we must
really both sync/unmap the dmamap before freeing it.
|
| 248988 |
01-Apr-2013 |
adrian |
Ensure that we only call the busdma unmap/flush routines once, when
the buffer is being freed.
* When buffers are cloned, the original mapping isn't copied but it
wasn't freeing the mapping until later. To be safe, free the
mapping when the buffer is cloned.
* ath_freebuf() now no longer calls the busdma sync/unmap routines.
* ath_tx_freebuf() now calls sync/unmap.
* Call sync first, before calling unmap.
Tested:
* AR5416, STA mode
|
| 248986 |
01-Apr-2013 |
adrian |
Remove an un-needed comment.
|
| 248985 |
01-Apr-2013 |
adrian |
Use ATH_MAX_SCATTER rather than ATH_TXDESC.
ATH_MAX_SCATTER is used to size the ath_buf DMA segment array.
We thus should use it when checking sizes of things.
|
| 248984 |
01-Apr-2013 |
adrian |
Only unmap the RX mbuf DMA map if there's a buffer here.
The normal RX path (ath_rx_pkt()) will sync and unmap the
buffer before passing it up the stack. We only need to do this
if we're flushing the FIFO during reset/shutdown.
|
| 248779 |
27-Mar-2013 |
adrian |
* Stop processing after HAL_EIO; this is what the reference driver does.
* If we hit an empty queue condition (which I haven't yet root caused, grr.)
.. make sure we release the lock before continuing.
|
| 248750 |
26-Mar-2013 |
adrian |
Implement the replacement EDMA FIFO code.
(Yes, the previous code temporarily broke EDMA TX. I'm sorry; I should've
actually setup ATH_BUF_FIFOEND on frames so txq->axq_fifo_depth was
cleared!)
This code implements a whole bunch of sorely needed EDMA TX improvements
along with CABQ TX support.
The specifics:
* When filling/refilling the FIFO, use the new TXQ staging queue
for FIFO frames
* Tag frames with ATH_BUF_FIFOPTR and ATH_BUF_FIFOEND correctly.
For now the non-CABQ transmit path pushes one frame into the TXQ
staging queue without setting up the intermediary link pointers
to chain them together, so draining frames from the txq staging
queue to the FIFO queue occurs AMPDU / MPDU at a time.
* In the CABQ case, manually tag the list with ATH_BUF_FIFOPTR and
ATH_BUF_FIFOEND so a chain of frames is pushed into the FIFO
at once.
* Now that frames are in a FIFO pending queue, we can top up the
FIFO after completing a single frame. This means we can keep
it filled rather than waiting for it drain and _then_ adding
more frames.
* The EDMA restart routine now walks the FIFO queue in the TXQ
rather than the pending queue and re-initialises the FIFO with
that.
* When restarting EDMA, we may have partially completed sending
a list. So stamp the first frame that we see in a list with
ATH_BUF_FIFOPTR and push _that_ into the hardware.
* When completing frames, only check those on the FIFO queue.
We should never ever queue frames from the pending queue
direct to the hardware, so there's no point in checking.
* Until I figure out what's going on, make sure if the TXSTATUS
for an empty queue pops up, complain loudly and continue.
This will stop the panics that people are seeing. I'll add
some code later which will assist in ensuring I'm populating
each descriptor with the correct queue ID.
* When considering whether to queue frames to the hardware queue
directly or software queue frames, make sure the depth of
the FIFO is taken into account now.
* When completing frames, tag them with ATH_BUF_BUSY if they're
not the final frame in a FIFO list. The same holding descriptor
behaviour is required when handling descriptors linked together
with a link pointer as the hardware will re-read the previous
descriptor to refresh the link pointer before contiuning.
* .. and if we complete the FIFO list (ie, the buffer has
ATH_BUF_FIFOEND set), then we don't need the holding buffer
any longer. Thus, free it.
Tested:
* AR9380/AR9580, STA and hostap
* AR9280, STA/hostap
TODO:
* I don't yet trust that the EDMA restart routine is totally correct
in all circumstances. I'll continue to thrash this out under heavy
multiple-TXQ traffic load and fix whatever pops up.
|
| 248745 |
26-Mar-2013 |
adrian |
Add per-TXQ EDMA FIFO staging queue support.
Each set of frames pushed into a FIFO is represented by a list of
ath_bufs - the first ath_buf in the FIFO list is marked with
ATH_BUF_FIFOPTR; the last ath_buf in the FIFO list is marked with
ATH_BUF_FIFOEND.
Multiple lists of frames are just glued together in the TAILQ as per
normal - except that at the end of a FIFO list, the descriptor link
pointer will be NULL and it'll be tagged with ATH_BUF_FIFOEND.
For non-EDMA chipsets this is a no-op - the ath_txq frame list (axq_q)
stays the same and is treated the same.
For EDMA chipsets the frames are pushed into axq_q and then when
the FIFO is to be (re) filled, frames will be moved onto the FIFO
queue and then pushed into the FIFO.
So:
* Add a new queue in each hardware TXQ (ath_txq) for staging FIFO frame
lists. It's a TAILQ (like the normal hardware frame queue) rather than
the ath9k list-of-lists to represent FIFO entries.
* Add new ath_buf flags - ATH_TX_FIFOPTR and ATH_TX_FIFOEND.
* When allocating ath_buf entries, clear out the flag value before
returning it or it'll end up having stale flags.
* When cloning ath_buf entries, only clone ATH_BUF_MGMT. Don't clone
the FIFO related flags.
* Extend ath_tx_draintxq() to first drain the FIFO staging queue, _then_
drain the normal hardware queue.
Tested:
* AR9280, hostap
* AR9280, STA
* AR9380/AR9580 - hostap
TODO:
* Test on other chipsets, just to be thorough.
|
| 248717 |
26-Mar-2013 |
adrian |
Remove the mcast path calls to ath_hal_gettxdesclinkptr() for axq_link -
they're no longer needed for the legacy path and they're not wanted
for the EDMA path.
Tested:
* AR9280, hostap + CABQ
* AR9380/AR9580, hostap + CABQ
|
| 248716 |
26-Mar-2013 |
adrian |
Remove this dead code - it's no longer relevant (as yes, we do actually
support TX on EDMA chips.)
|
| 248715 |
26-Mar-2013 |
adrian |
Convert the CABQ queue code over to use the HAL link pointer method
instead of axq_link.
This (among a bunch of uncommitted work) is required for EDMA chips
to correctly transmit frames on the CABQ.
Tested:
* AR9280, hostap mode
* AR9380/AR9580, hostap mode (staggered beacons)
TODO:
* This code only really gets called when burst beacons are used;
it glues multiple CABQ queues together when sending to the hardware.
* More thorough bursted beacon testing! (first requires some work with
the beacon queue code for bursted beacons, as that currently uses the
link pointer and will fail on EDMA chips.)
|
| 248714 |
26-Mar-2013 |
adrian |
Convert the EDMA multicast queue code over to use the HAL method to set
the descriptor link pointer, rather than directly.
This is needed on AR9380 and later (ie, EDMA) NICs so the multicast queue
has a chance in hell of being put together right.
Tested:
* AR9380, AR9580 in hostap mode, CABQ traffic (but with other patches..)
|
| 248713 |
26-Mar-2013 |
adrian |
Migrate the multicast queue assembly code to not use the axq_link pointer
and instead use the HAL method to set the link pointer.
Tested:
* AR9280, hostap mode, CABQ frames being queued and transmitted
|
| 248677 |
24-Mar-2013 |
adrian |
Add new regulatory domain.
Obtained from: Qualcomm Atheros
|
| 248676 |
24-Mar-2013 |
adrian |
Move the TXQ lock earlier in this routine - so to correctly protect the
link pointer check.
|
| 248675 |
24-Mar-2013 |
adrian |
Fix the locking changes due to the TXQ change drive-by.
Tested:
* AR9580, STA mode
|
| 248671 |
24-Mar-2013 |
adrian |
Overhaul the TXQ locking (again!) as part of some beacon/cabq timing
related issues.
Moving the TX locking under one lock made things easier to progress on
but it had one important side-effect - it increased the latency when
handling CABQ setup when sending beacons.
This commit introduces a bunch of new changes and a few unrelated changs
that are just easier to lump in here.
The aim is to have the CABQ locking separate from other locking.
The CABQ transmit path in the beacon process thus doesn't have to grab
the general TX lock, reducing lock contention/latency and making it
more likely that we'll make the beacon TX timing.
The second half of this commit is the CABQ related setup changes needed
for sane looking EDMA CABQ support. Right now the EDMA TX code naively
assumes that only one frame (MPDU or A-MPDU) is being pushed into each
FIFO slot. For the CABQ this isn't true - a whole list of frames is
being pushed in - and thus CABQ handling breaks very quickly.
The aim here is to setup the CABQ list and then push _that list_ to
the hardware for transmission. I can then extend the EDMA TX code
to stamp that list as being "one" FIFO entry (likely by tagging the
last buffer in that list as "FIFO END") so the EDMA TX completion code
correctly tracks things.
Major:
* Migrate the per-TXQ add/removal locking back to per-TXQ, rather than
a single lock.
* Leave the software queue side of things under the ATH_TX_LOCK lock,
(continuing) to serialise things as they are.
* Add a new function which is called whenever there's a beacon miss,
to print out some debugging. This is primarily designed to help
me figure out if the beacon miss events are due to a noisy environment,
issues with the PHY/MAC, or other.
* Move the CABQ setup/enable to occur _after_ all the VAPs have been
looked at. This means that for multiple VAPS in bursted mode, the
CABQ gets primed once all VAPs are checked, rather than being primed
on the first VAP and then having frames appended after this.
Minor:
* Add a (disabled) twiddle to let me enable/disable cabq traffic.
It's primarily there to let me easily debug what's going on with beacon
and CABQ setup/traffic; there's some DMA engine hangs which I'm finally
trying to trace down.
* Clear bf_next when flushing frames; it should quieten some warnings
that show up when a node goes away.
Tested:
* AR9280, STA/hostap, up to 4 vaps (staggered)
* AR5416, STA/hostap, up to 4 vaps (staggered)
TODO:
* (Lots) more AR9380 and later testing, as I may have missed something here.
* Leverage this to fix CABQ hanling for AR9380 and later chips.
* Force bursted beaconing on the chips that default to staggered beacons and
ensure the CABQ stuff is all sane (eg, the MORE bits that aren't being
correctly set when chaining descriptors.)
|
| 248670 |
23-Mar-2013 |
adrian |
CABQ calculation changes to try and fix some weird corner cases leading
to stuck beacons.
* Set the cabq readytime (ie, how long to burst for) to 50% of the total
beacon interval time
* fix the cabq adjustment calculation based on how the beacon offset is
calculated (the SWBA/DBA time offset.)
This is all still a bit magic voodoo but it does seem to have further
quietened issues with missed/stuck beacons under my local testing.
In any case, it better matches what the reference HAL implements.
Obtained from: Qualcomm Atheros
|
| 248543 |
20-Mar-2013 |
adrian |
Fix the EDMA CABQ handling - for now, the CABQ takes a descriptor chain
like the legacy chips expect.
|
| 248529 |
19-Mar-2013 |
adrian |
Break out the RX completion path into "FIFO check / refill" and
"complete RX frames."
The 128 entry RX FIFO is really easy to fill up and miss refilling
when it's done in the ath taskq - as that gets blocked up doing
RX completion, TX completion and other random things.
So the 128 entry RX FIFO now gets emptied and refilled in the ath_intr()
task (and it grabs / releases locks, so now ath_intr() can't just be
a FAST handler yet!) but the locks aren't held for very long. The
completion part is done in the ath taskqueue context.
Details:
* Create a new completed frame list - sc->sc_rx_rxlist;
* Split the EDMA RX process queue into two halves - one that
processes the RX FIFO and refills it with new frames; another
that completes the completed frame list;
* When tearing down the driver, flush whatever is in the deferred
queue as well as what's in the FIFO;
* Create two new RX methods - one that processes all RX queues,
one that processes the given RX queue. When MSI is implemented,
we get told which RX queue the interrupt came in on so we can
specifically schedule that. (And I can do that with the non-MSI
path too; I'll figure that out later.)
* Convert the legacy code over to use these new RX methods;
* Replace all the instances of the RX taskqueue enqueue with a call
to a relevant RX method to enqueue one or all RX queues.
Tested:
* AR9380, STA
* AR9580, STA
* AR5413, STA
|
| 248528 |
19-Mar-2013 |
adrian |
Add more TODO items.
|
| 248527 |
19-Mar-2013 |
adrian |
Now that the tx map field is correctly populated for both edma and
legacy chips, just use that.
|
| 248455 |
18-Mar-2013 |
adrian |
Print out the current fifo queue depth correctly - not just the max
queue depth.
Silly hat to me.
|
| 248451 |
18-Mar-2013 |
adrian |
Dump out information about the RX descriptor free list and FIFO information.
|
| 248450 |
18-Mar-2013 |
adrian |
Log some more information when the RX buffer allocation failed.
|
| 248347 |
15-Mar-2013 |
adrian |
Why'd I keep this here? remove it entirely now.
|
| 248341 |
15-Mar-2013 |
adrian |
Fix two bugs:
* when pulling frames off of the TID queue, the ATH_TID_REMOVE()
macro decrements the axq_depth field. So don't do it twice.
* in ath_tx_comp_cleanup_aggr(), bf wasn't being reset to bf_first
before walking the buffer list to complete buffers; so those buffers
will leak.
|
| 248312 |
15-Mar-2013 |
adrian |
Remove a now incorrect comment.
This comment dates back to my initial stab at TX aggregation completion,
where I didn't even bother trying to do software retries.
|
| 248311 |
15-Mar-2013 |
adrian |
Add locking around the new holdingbf code.
Since this is being done during buffer free, it's a crap shoot whether
the TX path lock is held or not. I tried putting the ath_freebuf() code
inside the TX lock and I got all kinds of locking issues - it turns out
that the buffer free path sometimes is called with the lock held and
sometimes isn't. So I'll go and fix that soon.
Hence for now the holdingbf buffers are protected by the TXBUF lock.
|
| 248264 |
14-Mar-2013 |
adrian |
Implement "holding buffers" per TX queue rather than globally.
When working on TDMA, Sam Leffler found that the MAC DMA hardware
would re-read the last TX descriptor when getting ready to transmit
the next one. Thus the whole ATH_BUF_BUSY came into existance -
the descriptor must be left alone (very specifically the link pointer
must be maintained) until the hardware has moved onto the next frame.
He saw this in TDMA because the MAC would be frequently stopping during
active transmit (ie, when it wasn't its turn to transmit.)
Fast-forward to today. It turns out that this is a problem not with
a single MAC DMA instance, but with each QCU (from 0->9). They each
maintain separate descriptor pointers and will re-read the last
descriptor when starting to transmit the next.
So when your AP is busy transmitting from multiple TX queues, you'll
(more) frequently see one QCU stopped, waiting for a higher-priority QCU
to finsh transmitting, before it'll go ahead and continue. If you mess
up the descriptor (ie by freeing it) then you're short of luck.
Thanks to rpaulo for sticking with me whilst I diagnosed this issue
that he was quite reliably triggering in his environment.
This is a reimplementation; it doesn't have anything in common with
the ath9k or the Qualcomm Atheros reference driver.
Now - it in theory doesn't apply on the EDMA chips, as long as you
push one complete frame into the FIFO at a time. But the MAC can DMA
from a list of frames pushed into the hardware queue (ie, you concat
'n' frames together with link pointers, and then push the head pointer
into the TXQ FIFO.) Since that's likely how I'm going to implement
CABQ handling in hostap mode, it's likely that I will end up teaching
the EDMA TX completion code about busy buffers, just to be "sure"
this doesn't creep up.
Tested - iperf ap->sta and sta->ap (with both sides running this code):
* AR5416 STA
* AR9160/AR9220 hostap
To validate that it doesn't break the EDMA (FIFO) chips:
* AR9380, AR9485, AR9462 STA
Using iperf with the -S <tos byte decimal value> to set the TCP client
side DSCP bits, mapping to different TIDs and thus different TX queues.
TODO:
* Make this work on the EDMA chips, if we end up pushing lists of frames
to the hardware (eg how we eventually will handle cabq in hostap/ibss
mode.)
|
| 248182 |
12-Mar-2013 |
adrian |
Use the correct antenna configuration variable here. "diversity" just
controls whether it's on or off.
Found by: clang
|
| 248146 |
11-Mar-2013 |
adrian |
Add a few new fields to the RX vendor radiotap header:
* a flags field that lets me know what's going on;
* the hardware ratecode, unmolested by conversion to a bitrate;
* the HAL rs_flags field, useful for debugging;
* specifically mark aggregate sub-frames.
This stuff sorely needs tidying up - it's missing some important
stuff (eg numdelims) and it would be nice to put the flags at the
beginning rather than at the end.
Tested:
* AR9380, STA mode, 2x2 HT40, monitoring RSSI and EVM values
|
| 248143 |
11-Mar-2013 |
adrian |
Bump the EVM array size up to fit the AR9380 EVM entries.
|
| 248142 |
11-Mar-2013 |
adrian |
Add three-stream EVM values.
|
| 248129 |
10-Mar-2013 |
adrian |
Add another register definition bit - whether to populate EVM or PLCP
data in the RX status descriptor.
Obtained from: Qualcomm Atheros
|
| 248091 |
09-Mar-2013 |
adrian |
Disable the hw TID != buffer TID check.
I can 100% reliably trigger this on TID 1 traffic by using iperf -S 32
<client fields> to create traffic that maps to TID 1.
The reference driver doesn't do this check.
|
| 248090 |
09-Mar-2013 |
adrian |
Print out the queue flags during a TX DMA shutdown.
|
| 247774 |
04-Mar-2013 |
adrian |
add a method to set/clear the VMF field in the TX descriptor.
Obtained from: Qualcomm Atheros
|
| 247508 |
28-Feb-2013 |
adrian |
Add missing flags.
|
| 247507 |
28-Feb-2013 |
adrian |
Oops - fix an incorrect test.
|
| 247506 |
28-Feb-2013 |
adrian |
Don't enable the HT flags for legacy rates.
I stumbled across this whilst trying to debug another weird hang reported
on the freebsd-wireless list.
Whilst here, add in the STBC check to ath_rateseries_setup().
Whilst here, fix the short preamble flag to be set only for legacy rates.
Whilst here, comment that we should be using the full set of decisions
made by ath_rateseries_setup() rather than recalculating them!
|
| 247372 |
27-Feb-2013 |
adrian |
I give up - just throw the EWMA update into the normal update_stats()
routine.
There were still corner cases where the EWMA update stats are being
called on a rix which didn't have an intermediary stats update; thus
no packets were counted against it. Sigh.
This should fix the crashes I've been seeing on recent -HEAD.
|
| 247368 |
27-Feb-2013 |
adrian |
Enable STBC for the given rate series if it's negotiated:
* If both ends have negotiated (at least) one stream;
* Only if it's a single stream rate (MCS0-7);
* Only if there's more than one TX chain enabled.
Tested:
* AR9280 STA mode -> Atheros AP; tested both MCS2 (STBC) and MCS12 (no STBC.)
Verified using athalq to inspect the TX descriptors.
TODO:
* Test AR5416 - no STBC should be enabled;
* Test AR9280 with one TX chain enabled - no STBC should be enabled.
|
| 247366 |
27-Feb-2013 |
adrian |
Add in the STBC TX/RX capability support into the HAL and driver.
The HAL already included the STBC fields; it just needed to be exposed
to the driver and net80211 stack.
This should allow single-stream STBC TX and RX to be negotiated; however
the driver and rate control code currently don't do anything with it.
|
| 247317 |
26-Feb-2013 |
adrian |
Update the EWMA statistics for each intermediary rate as well as the final
rate.
This fixes two things:
* The intermediary rates now also have their EWMA values changed;
* The existing code was using the wrong value for longtries - so the
EWMA stats were only adjusted for the first rate and not subsequent
rates in a MRR setup.
TODO:
* Merge the EWMA updates into update_stats() now..
|
| 247287 |
25-Feb-2013 |
adrian |
Part #2 of the TX chainmask changes:
* Remove ar5416UpdateChainmasks();
* Remove the TX chainmask override code from the ar5416 TX descriptor
setup routines;
* Write a driver method to calculate the current chainmask based on the
operating mode and update the driver state;
* Call the HAL chainmask method before calling ath_hal_reset();
* Use the currently configured chainmask in the TX descriptors rather than
the hardware TX chainmasks.
Tested:
* AR5416, STA/AP mode - legacy and 11n modes
|
| 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.
|
| 247145 |
22-Feb-2013 |
adrian |
Add a workaround for AR5416, AR9130 and AR9160 chipsets - work around
an incorrectly calculated RTS duration value when transmitting aggregates.
These earlier 802.11n NICs incorrectly used the ACK duration time when
calculating what to put in the RTS of an aggregate frame. Instead it
should have used the block-ack time. The result is that other stations
may not reserve enough time and start transmitting _over_ the top of
the in-progress blockack field. Tsk.
This workaround is to popuate the burst duration field with the delta
between the ACK duration the hardware is using and the required duration
for the block-ack. The result is that the RTS field should now contain
the correct duration for the subsequent block-ack.
This doesn't apply for AR9280 and later NICs.
Obtained from: Qualcomm Atheros
|
| 247135 |
21-Feb-2013 |
adrian |
Disable debugging entries about BAW issues. I haven't seen any issues
to do with BAW tracking in the last 9 months or so.
|
| 247092 |
21-Feb-2013 |
adrian |
Be slightly more paranoid with the TX DMA buffer maximum threshold.
Specifically - never jack the TX FIFO threshold up to the absolute
maximum; always leave enough space for two DMA transactions to
appear.
This is a paranoia from the Linux ath9k driver. It can't hurt.
Obtained from: Linux ath9k
|
| 247087 |
21-Feb-2013 |
adrian |
Add an option to allow the minimum number of delimiters to be tweaked.
This is primarily for debugging purposes.
Tested:
* AR5416, STA mode
|
| 247085 |
21-Feb-2013 |
adrian |
Add a new option to limit the maximum size of aggregates.
The default is to limit them to what the hardware is capable of.
Add sysctl twiddles for both the non-RTS and RTS protected aggregate
generation.
Whilst here, add some comments about stuff that I've discovered during
my exploration of the TX aggregate / delimiter setup path from the
reference driver.
|
| 247073 |
21-Feb-2013 |
adrian |
Remove this unneeded printf(), sorry!
|
| 247033 |
20-Feb-2013 |
adrian |
Configure larger TX FIFO default and maximum level values.
This has reduced the number of TX delimiter and data underruns when
doing large UDP transfers (>100mbit).
This stops any HAL_INT_TXURN interrupts from occuring, which is a good
sign!
Obtained from: Qualcomm Atheros
|
| 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.
|
| 247029 |
20-Feb-2013 |
adrian |
A couple of quick tidyups:
* Delete this debugging print - I used it when debugging the initial
TX descriptor chaining code. It now works, so let's toss it.
It just confuses people if they enable TX descriptor debugging as they
get two slightly different versions of the same descriptor.
* Indenting.
|
| 247028 |
20-Feb-2013 |
adrian |
Enable TX FIFO underrun interrupts. This allows the TX FIFO threshold
adjustment code to now run.
Tested:
* AR5416, STA
TODO:
* Much more thorough testing on the other chips, AR5210 -> AR9287
|
| 247027 |
20-Feb-2013 |
adrian |
oops, tab!
|
| 247026 |
20-Feb-2013 |
adrian |
Post interrupts in the ath alq trace.
|
| 247025 |
20-Feb-2013 |
adrian |
CFG_ERR, DATA_UNDERRUN and DELIM_UNDERRUN are all flags, rather than
part of ts_status. Thus:
* make sure we decode them from ts_flags, rather than ts_status;
* make sure we decode them regardless of whether there's an error or not.
This correctly exposes descriptor configuration errors, TX delimiter
underruns and TX data underruns.
|
| 246945 |
18-Feb-2013 |
adrian |
Fix an incorrect sizeof()
PR: kern/176238
Submitted by: Christoph Mallon <christoph.mallon@gmx.de>
|
| 246933 |
18-Feb-2013 |
adrian |
Add a new ATH KTR debug method to log the interrupt status.
|
| 246879 |
16-Feb-2013 |
adrian |
* Reduce the PCU lock overhead a little by only re-acquiring it if we
actually do have to reinitialise the RX side of things after an RX
descriptor EOL error.
* Revert a change of mine from quite a while ago - don't shortcut the
RX initialisation path. There's a RX FIFO bug in the earlier chips
(I'm not sure when it was fixed in this series, but it's fixed
with the AR9380 and later) which causes the same RX descriptor to
be written to over and over. This causes the descriptor to be
marked as "done", and this ends up causing the whole RX path to
go very strange. This should fixed the "kickpcu; handled X packets"
message spam where "X" is consistently small.
|
| 246745 |
13-Feb-2013 |
adrian |
Pull out the if_transmit() work and revert back to ath_start().
My changed had some rather significant behavioural changes to throughput.
The two issues I noticed:
* With if_start and the ifnet mbuf queue, any temporary latency
would get eaten up by some mbufs being queued. With ath_transmit()
queuing things to ath_buf's, I'd only get 512 TX buffers before I
couldn't queue any further frames.
* There's also some non-zero latency involved with TX being pushed
into a taskqueue via direct dispatch. Any time the scheduler didn't
immediately schedule the ath TX task would cause extra latency.
Various 1ge/10ge drivers implement both direct dispatch (if the TX
lock can be acquired) and deferred task transmission (if the TX lock
can't be acquired), with frames being pushed into a drbd queue.
I'll have to do this at some point, but until I figure out how to
deal with 802.11 fragments, I'll have to wait a while longer.
So what I saw:
* lots of extra latency, specially under load - if the taskqueue
wasn't immediately scheduled, things went pear shaped;
* any extra latency would result in TX ath_buf's taking their sweet time
being replenished, so any further calls to ath_transmit() would drop
mbufs.
* .. yes, there's no explicit backpressure here - things are just dropped.
Eek.
With this, the general performance has gone up, but those subtle if_start()
related race conditions are back. For some reason, this is doubly-obvious
with the AR5416 NIC and I don't quite understand why yet.
There's an unrelated issue with AR5416 performance in STA mode (it's
fine in AP mode when bridging frames, weirdly..) that requires a little
further investigation. Specifically - it works fine on a Lenovo T40
(single core CPU) running a March 2012 9-STABLE kernel, but a Lenovo T60
(dual core) running an early November 2012 kernel behaves very poorly.
The same hardware with an AR9160 or AR9280 behaves perfectly.
|
| 246652 |
11-Feb-2013 |
adrian |
Put this back into the ath taskqueue rather than the ath TX taskqueue.
This now should mean all the entry points into the software TX
scheduler are back in the same taskqueue.
|
| 246650 |
11-Feb-2013 |
adrian |
Go back to direct-dispatch of the software queue and frame TX paths
when they're being called from the TX completion handler.
Going (back) through the taskqueue is just adding extra locking and
latency to packet operations. This improves performance a little bit
on most NICs.
It still hasn't restored the original performance of the AR5416 NIC
but the AR9160, AR9280 and later NICs behave very well with this.
Tested:
* AR5416 STA (still tops out at ~ 70mbit TCP, rather than 150mbit TCP..)
* AR9160 hostap (good for both TX and RX)
* AR9280 hostap (good for both TX and RX)
|
| 246648 |
11-Feb-2013 |
adrian |
Extend the timestamp to be a timeval, rather than ticks.
This makes it easier to see TX and RX buffer latencies.
|
| 246579 |
09-Feb-2013 |
adrian |
The encryption type field needs to be preserved for each descriptor
making up a frame, in both a sub-frame and for all frames in an
aggregate.
Tested:
* AR5416, STA mode
|
| 246536 |
08-Feb-2013 |
adrian |
Fix a corner case that I noticed with the AR5416 (and it's currently
crappy 802.11n performance, sigh.)
With the AR5416, aggregates need to be limited to 8KiB if RTS/CTS is
enabled. However, larger aggregates were going out with RTSCTS enabled.
The following was going on:
* The first buffer in the list would have RTS/CTS enabled in
bf->bf_state.txflags;
* The aggregate would be formed;
* The "copy over the txflags from the first buffer" logic that I added
blanked the RTS/CTS TX flags fields, and then copied the bf_first
RTS/CTS flags over;
* .. but that'd cause bf_first to be blanked out! And thus the flag
was cleared;
* So the rest of the aggregate formation would run with those flags
cleared, and thus > 8KiB aggregates were formed.
The driver is now (again) correctly limiting aggregate formation for
the AR5416 but there are still other pending issues to resolve.
Tested:
* AR5416, STA mode
|
| 246453 |
07-Feb-2013 |
adrian |
Create a new TX lock specifically for queuing frames.
This now separates out the act of queuing frames from the act of running
TX and TX completion.
|
| 246450 |
07-Feb-2013 |
adrian |
Methodize the process of adding the software TX queue to the taskqueue.
Move it (for now) to the TX taskqueue.
|
| 246141 |
31-Jan-2013 |
adrian |
Work around some rather unfortunate race conditions inside net80211.
Right now, ic_curchan seems to be updated rather quickly (ie, during
the ioctl) and before the driver gets notified of what's going on.
So what I was seeing was:
* NIC was in channel X;
* It generates PHY errors for channel X;
* an ioctl comes along from userland and changes things to channel Y;
* .. this updates ic_curchan, but hasn't yet reset the hardware;
* in parallel, RX is occuring and it looks at ic_curchan;
* .. which is channel Y, so events get stamped with that now.
Sigh.
|
| 245952 |
26-Jan-2013 |
pfg |
Clean some 'svn:executable' properties in the tree.
Submitted by: Christoph Mallon
MFC after: 3 days
|
| 245927 |
26-Jan-2013 |
adrian |
Migrate the TX sending code out from under the ath0 taskq and into
the separate ath0 TX taskq.
Whilst here, make sure that the TX software scheduler is also
running out of the TX task, rather than the ath0 taskqueue.
Make sure that the tx taskqueue is blocked/unblocked as necessary.
This allows for a little more parallelism on multi-core machines,
as well as (eventually) supporting a higher task priority for TX
tasks, allowing said TX task to preempt an already running RX or
TX completion task.
Tested:
* AR5416, AR9280 hostap and STA modes
|
| 245739 |
21-Jan-2013 |
adrian |
Fix this routine to acutally break out and not set clrdmask if any
of the TIDs are currently marked as "filtered."
|
| 245708 |
21-Jan-2013 |
adrian |
Migrate CLRDMASK to be a per-node flag, rather than a per-TID flag.
This is easily possible now that the TX is protected by a single
lock, rather than a per-TXQ (and thus per-TID) lock.
Only set CLRDMASK if none of the destinations are filtered.
This likely will need some tuning when it comes time to do UASPD/PS-POLL
TX, however at that point it should be manually set anyway.
Tested:
* AR9280, STA mode
TODO:
* More thorough testing in AP mode
* test other chipsets, just to be safe/sure.
|
| 245556 |
17-Jan-2013 |
adrian |
Fix hangs (exposed by spectral scan activity) in STA mode when the
chip hangs.
* Always do a reset in ath_bmiss_proc(), regardless of whether the
hardware is "hung" or not. Specifically, for spectral scan, there's
likely a whole bunch of potential hangs that we don't (yet) recognise
in the HAL. So to avoid staying RX deaf persisting until the station
disassociates, just do a no-loss reset.
* Set sc_beacons=1 in STA mode. During a reset, the beacon programming
isn't done. (It's likely I need to set sc_syncbeacons during a hang
reset, but I digress.) Thus after a reset, there's no beacon timer
programming to send a BMISS interrupt if beacons aren't heard ..
thus if the AP disappears, you won't get notified and you'll have to
reset your interface.
This hasn't yet fixed all of the hangs that I've seen when debugging
spectral scan, but it's certainly reduced the hang frequency and it
should improve general STA stability in very noisy environments.
Tested:
* AR9280, STA mode, spectral scan off/on
PR: kern/175227
|
| 245554 |
17-Jan-2013 |
adrian |
Add a quick work-around if ath_beacon_config() to not die if it's called
when an interface is going down.
Right now it's quite possible (but very unlikely!) that ath_reset()
or similar is called, leading to a beacon config call, in parallel with
the last VAP being destroyed.
This likely should be fixed by making sure the bmiss/bstuck/watchdog
taskqueues are canceled whenever the last VAP is destroyed.
|
| 245465 |
15-Jan-2013 |
adrian |
Implement frame (data) transmission using if_transmit(), rather than
if_start().
This removes the overlapping data path TX from occuring, which
solves quite a number of the potential TX queue races in ath(4).
It doesn't fix the net80211 layer TX queue races and it doesn't
fix the raw TX path yet, but it's an important step towards this.
This hasn't dropped the TX performance in my testing; primarily
because now the TX path can quickly queue frames and continue
along processing.
This involves a few rather deep changes:
* Use the ath_buf as a queue placeholder for now, as we need to be
able to support queuing a list of mbufs (ie, when transmitting
fragments) and m_nextpkt can't be used here (because it's what is
joining the fragments together)
* if_transmit() now simply allocates the ath_buf and queues it to
a driver TX staging queue.
* TX is now moved into a taskqueue function.
* The TX taskqueue function now dequeues and transmits frames.
* Fragments are handled correctly here - as the current API passes
the fragment list as one mbuf list (joined with m_nextpkt) through
to the driver if_transmit().
* For the couple of places where ath_start() may be called (mostly
from net80211 when starting the VAP up again), just reimplement
it using the new enqueue and taskqueue methods.
What I don't like (about this work and the TX code in general):
* I'm using the same lock for the staging TX queue management and the
actual TX. This isn't required; I'm just being slack.
* I haven't yet moved TX to a separate taskqueue (but the taskqueue is
created); it's easy enough to do this later if necessary. I just need
to make sure it's a higher priority queue, so TX has the same
behaviour as it used to (where it would preempt existing RX..)
* I need to re-review the TX path a little more and make sure that
ieee80211_node_*() functions aren't called within the TX lock.
When queueing, I should just push failed frames into a queue and
when I'm wrapping up the TX code, unlock the TX lock and
call ieee80211_node_free() on each.
* It would be nice if I could hold the TX lock for the entire
TX and TX completion, rather than this release/re-acquire behaviour.
But that requires that I shuffle around the TX completion code
to handle actual ath_buf free and net80211 callback/free outside
of the TX lock. That's one of my next projects.
* the ic_raw_xmit() path doesn't use this yet - so it still has
sequencing problems with parallel, overlapping calls to the
data path. I'll fix this later.
Tested:
* Hostap - AR9280, AR9220
* STA - AR5212, AR9280, AR5416
|
| 245396 |
13-Jan-2013 |
adrian |
If we're doing a kickpcu, make sure we flush the whole RX list rather than
stopping after 128 frames.
Whilst here, add in some code that lets me optionally flip back to the
original behaviour of calling ath_startrecv().
|
| 245281 |
11-Jan-2013 |
adrian |
Place-holders for enable/active parameter flags.
|
| 245190 |
08-Jan-2013 |
adrian |
Fix format size.
|
| 245185 |
08-Jan-2013 |
adrian |
Add support for triggering spectral scan upon a channel reset/change.
This is intended to support reporting FFT results during active channel
scans, for users who would like to fiddle around with writing applications
that do both FFT visualisation _and_ AP scanning.
* add a new ioctl to enable/trigger spectral scan at channel change/reset;
* set do_spectral consistently if it's enabled, so a channel set/reset
will carry forth the correct PHY error configuration so frames
are actually received;
* for NICs that don't do spectral scan, don't bother checking the
spectral scan state on channel change/reset.
Tested:
* AR9280 - STA and scanning;
* AR5416 - STA, ensured that the SS code doesn't panic
|
| 245183 |
08-Jan-2013 |
adrian |
If spectral scan is enabled, ensure radar report PHY errors are also
enabled.
|
| 245031 |
04-Jan-2013 |
adrian |
For PHY error frames, populate the configured channel flags rather than
based on the received frame.
PHY errors don't have the relevant HT or 40MHz MCS flag set.
|
| 245002 |
03-Jan-2013 |
adrian |
Don't call the spectral methods for NICS that don't implement them.
|
| 244951 |
02-Jan-2013 |
adrian |
Add a new (skeleton) spectral mode manager module.
|
| 244950 |
02-Jan-2013 |
adrian |
Fix the short repeat option code to not flip the option to 0 when
we call this w/ NOVAL set.
|
| 244947 |
02-Jan-2013 |
adrian |
Add spectral HAL accessor methods.
|
| 244946 |
02-Jan-2013 |
adrian |
Add a method to explicitly disable radar reporting if required.
|
| 244943 |
02-Jan-2013 |
adrian |
Bring over the basic spectral scan framework code from Qualcomm Atheros.
This includes the HAL routines to setup, enable/activate/disable spectral
scan and configure the relevant registers.
This still requires driver interaction to enable spectral scan reporting.
Specifically:
* call ah_spectralConfigure() to configure and enable spectral scan;
* .. there's currently no way to disable spectral scan... that will have
to follow.
* call ah_spectralStart() to force start a spectral report;
* call ah_spectralStop() to force stop an active spectral report.
The spectral scan results appear as PHY errors (type 0x5 on the AR9280,
same as radar) but with the spectral scan bit set (0x10 in the last byte
of the frame) identifying it as a spectral report rather than a radar
FFT report.
Caveats:
* It's likely quite difficult to run spectral _and_ radar at the same
time. Enabling spectral scan disables the radar thresholds but
leaves radar enabled. Thus, the driver (for now) needs to ensure
that only one or the other is enabled.
* .. it needs testing on HT40 mode.
Tested:
* AR9280 in STA mode, HT/20 only
TODO:
* Test on AR9285, AR9287;
* Test in both HT20 and HT40 modes;
* .. all the driver glue.
Obtained from: Qualcomm Atheros
|
| 244854 |
30-Dec-2012 |
adrian |
Add the initial HAL glue for the spectral analysis support.
* Finish adding the HAL capability to announce whether a NIC supports
spectral scan or not;
* Add spectral scan methods to the HAL structure;
* Add HAL_SPECTRAL_PARAM for configuration of the spectral scan logic.
The capability ID and HAL_SPECTRAL_PARAM struct are from Qualcomm
Atheros.
|
| 244853 |
30-Dec-2012 |
adrian |
Add spectral scan capability.
|
| 244790 |
28-Dec-2012 |
bapt |
Fix typo in comment.
Submitted by: Christoph Mallon <christoph.mallon@gmx.de>
|
| 244768 |
28-Dec-2012 |
adrian |
Add the AR9280 and later spectral scan register definitions.
Obtained from: Linux ath9k, Qualcomm Atheros (datasheet)
|
| 244767 |
28-Dec-2012 |
adrian |
Add radar_bin_thresh_sel (bit 24:26), which defines when
to consider the radar FFT report bins as "strong".
|
| 244529 |
21-Dec-2012 |
adrian |
Note why fast frames is disabled for 802.11n NICs now.
It actually works, but net80211 handles A-MPDU and Fast frames
incorrectly; it tries enabling both in some instances, with tragic
results.
|
| 244109 |
11-Dec-2012 |
adrian |
There's no need to use a TXQ pointer here; we specifically need the
hardware queue ID when queuing to EDMA descriptors.
This is a small part of trying to reduce the size of ath_buf entries.
|
| 243975 |
07-Dec-2012 |
adrian |
Add XC900 SKU mapping.
|
| 243857 |
04-Dec-2012 |
glebius |
Mechanically substitute flags from historic mbuf allocator with
malloc(9) flags in sys/dev.
|
| 243843 |
04-Dec-2012 |
adrian |
Methodise the BT diversity configuration function; so the AR9285
can correctly override it.
This was missed in the previous commit.
|
| 243842 |
04-Dec-2012 |
adrian |
Override the BT coex parameter function for the AR9285.
|
| 243841 |
04-Dec-2012 |
adrian |
Reformat/reindent.
|
| 243840 |
03-Dec-2012 |
adrian |
Add and tie in the AR5416 bluetooth coexistence methods into the HAL.
|
| 243787 |
02-Dec-2012 |
adrian |
Don't grab the PCU lock inside the TX lock.
|
| 243786 |
02-Dec-2012 |
adrian |
Delete the per-TXQ locks and replace them with a single TX lock.
I couldn't think of a way to maintain the hardware TXQ locks _and_ layer
on top of that per-TXQ software queuing and any other kind of fine-grained
locks (eg per-TID, or per-node locks.)
So for now, to facilitate some further code refactoring and development
as part of the final push to get software queue ps-poll and u-apsd handling
into this driver, just do away with them entirely.
I may eventually bring them back at some point, when it looks slightly more
architectually cleaner to do so. But as it stands at the present, it's
not really buying us much:
* in order to properly serialise things and not get bitten by scheduling
and locking interactions with things higher up in the stack, we need to
wrap the whole TX path in a long held lock. Otherwise we can end up
being pre-empted during frame handling, resulting in some out of order
frame handling between sequence number allocation and encryption handling
(ie, the seqno and the CCMP IV get out of sequence);
* .. so whilst that's the case, holding the lock for that long means that
we're acquiring and releasing the TXQ lock _inside_ that context;
* And we also acquire it per-frame during frame completion, but we currently
can't hold the lock for the duration of the TX completion as we need
to call net80211 layer things with the locks _unheld_ to avoid LOR.
* .. the other places were grab that lock are reset/flush, which don't happen
often.
My eventual aim is to change the TX path so all rejected frame transmissions
and all frame completions result in any ieee80211_free_node() calls to occur
outside of the TX lock; then I can cut back on the amount of locking that
goes on here.
There may be some LORs that occur when ieee80211_free_node() is called when
the TX queue path fails; I'll begin to address these in follow-up commits.
|
| 243743 |
01-Dec-2012 |
adrian |
Add a new HAL capability - check and enforce whether the NIC supports
enforcing the TXOP and TBTT limits:
* Frames which will overlap with TBTT will not TX;
* Frames which will exceed TXOP will be filtered.
This is not enabled by default; it's intended to be enabled by the
TDMA code on 802.11n capable chipsets.
|
| 243648 |
28-Nov-2012 |
adrian |
Call if_free() with the correct vnet context if and only if ifp_vnet
isn't NULL.
If the attach fails prematurely and there's no if_vnet context, calling
CURVNET_SET(ifp->if_vnet) is going to dereference a NULL pointer.
|
| 243647 |
28-Nov-2012 |
adrian |
Until I figure out what to do here, remind myself that this needs some
rate control 'adjustment' when NOACK is set.
|
| 243642 |
28-Nov-2012 |
adrian |
Pull out the debugging code from the critical path and make sure it
happens _after_ all of the time delta calculations.
|
| 243614 |
27-Nov-2012 |
adrian |
* Fix another culprit of my "committed from the wrong directory" nonsense;
now this works for non-debug and debug builds.
* Add a comment reminding me (or someone) to audit all of the relevant
math to ensure there's no weird wrapping issues still lurking about.
But yes, this does seem to be mostly working.
Pointy-hat-to: adrian, yet again
|
| 243606 |
27-Nov-2012 |
adrian |
Correct some debugging output.
|
| 243597 |
27-Nov-2012 |
adrian |
Fix build
|
| 243592 |
27-Nov-2012 |
adrian |
Improve the TDMA debugging:
* add some further debugging prints, which are quite nice to have
* add in ALQ hooks (optional!) to allow for the TDMA information to be
logged in-line with the TX and RX descriptor information.
|
| 243591 |
27-Nov-2012 |
adrian |
Add in specific TDMA logging types.
|
| 243590 |
27-Nov-2012 |
adrian |
Fix the TDMA nexttbtt programming for 802.11n chips.
The existing logic wrapped programming nexttbtt at 65535 TU.
This is not good enough for the 11n chips, whose nexttbtt register
(GENERIC_TIMER_0) has an initial value from 0..2^31-1 TSF.
So converting the TU to TSF had the counter wrap at (65535 << 10) TSF.
Once this wrap occured, the nexttbtt value was very very low, much
lower than the current TSF value. At this point, the nexttbtt timer
would constantly fire, leading to the TX queue being constantly gated
open.. and when this occured, the sender was not correctly transmitting
in its slot but just able to continuously transmit. The master would
then delay transmitting its beacon until after the air became free
(which I guess would be after the burst interval, before the next burst
interval would quickly follow) and that big delta in master beacon TX
would start causing big swings in the slot timing adjustment.
With this change, the nexttbtt value is allowed to go all the way up
to the maximum value permissable by the 32 bit representation.
I haven't yet tested it to that point; I really should. The AR5212
HAL now filters out values above 65535 TU for the beacon configuration
(and the relevant legal values for SWBA, DBA and NEXTATIM) and the
AR5416 HAL just dutifully programs in what it should.
With this, TDMA is now useful on the 802.11n chips.
Tested:
* AR5416, AR9280 TDMA slave
* AR5413 TDMA slave
|
| 243589 |
27-Nov-2012 |
adrian |
Add a note about the magic values here; don't change them.
|
| 243588 |
27-Nov-2012 |
adrian |
When programming the beacon timer configuration, be very explicit about
what the maximum legal values are.
The current beacon timer configuration from TDMA wraps things at
HAL_BEACON_PERIOD-1 TU. For the 11a chips this is fine, but for
the 11n chips it's not enough resolution. Since the 11a chips have a
limit on what's "valid", just enforce this so when I do write larger
values in, they get suitably wrapped before programming.
Tested:
* AR5413, TDMA slave
Todo:
* Run it for a (lot) longer on a clear channel, ensure that no strange
slippages occur.
* Re-validate this on STA configurations, just to be sure.
|
| 243472 |
24-Nov-2012 |
adrian |
Add a comment which covers what's going on with the 64 bit TSF write.
After chatting with the MAC team, the TSF writes (at least on the 11n
MACs, I don't know about pre-11n MACs) are done as 64 bit writes that
can take some time. So, doing a 32 bit TSF write is definitely not
supported. Leave a comment here which explains that.
Whilst here, add a comment which outlines that after a reset or TSF
write, the TSF write may take a while (up to 50uS) to update.
A write or reset shouldn't be done whilst the previous one is in
flight. Also (and this isn't currently done) a read shouldn't
occur until the SLEEP32_TSF_WRITE_STAT is clear. Right now we're
not doing that, mostly because we haven't been doing lots of TSF
resets/writes until recently.
|
| 243427 |
23-Nov-2012 |
adrian |
Use a 64 bit TSF write to update the TSF adjust, rather than a 32 bit
TSF write.
The TSF_L32 update is fine for the AR5413 (and later, I guess) 11abg NICs
however on the 11n NICs this didn't work. The TSF writes were causing
a much larger time to be skipped, leading to the timing to never
converge.
I've tested this 64 bit TSF read, adjust and write on both the
11n NICs and the AR5413 NIC I've been using for testing. It works
fine on each.
This patch allows the AR5416/AR9280 to be used as a TDMA member.
I don't yet know why the AR9280 is ~7uS accurate rather than ~3uS;
I'll look into it soon.
Tested:
* AR5413, TDMA slave (~ 3us accuracy)
* AR5416, TDMA slave (~ 3us accuracy)
* AR9280, TDMA slave (~ 7us accuracy)
|
| 243426 |
23-Nov-2012 |
adrian |
Fix up the nexttbtt -> TSF delta calculation to not wrap ridiculously
on the 802.11n NICs.
The 802.11n NICs return a TBTT value that continues far past the 16 bit
HAL_BEACON_PERIOD time (in TU.) The code would constrain nextslot to
HAL_BEACON_PERIOD, but it wasn't constraining nexttbtt - the pre-11n
NICs would only return TU values from 0 -> HAL_BEACON_PERIOD. Thus,
when nexttbtt exceeded 64 milliseconds, it would not wrap (but nextslot
did) which lead to a huge tsfdelta.
So until the slot calculation is converted to work in TSF rather than
a mix of TSF and TU, "make" the nexttbtt values match the TU assumptions
for pre-11n NICs.
This fixes the crazy deltatsf calculations but it doesn't fix the
non-convergent tsfdelta issue. That'll be fixed in a subsequent commit.
|
| 243425 |
23-Nov-2012 |
adrian |
Add the HAL wrapper for settsf64.
|
| 243424 |
23-Nov-2012 |
adrian |
Implement a HAL method to set a 64 bit TSF value.
TODO: implement it (and test) for the AR5210/AR5211.
|
| 243318 |
19-Nov-2012 |
adrian |
Don't allocate or program a key for the AR5210.
The AR5210 doesn't support HAL_CIPHER_CLR ('clear encryption' keycache
slots), so don't bother - just map them to slot 0 and never program them.
|
| 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.
|
| 243249 |
18-Nov-2012 |
adrian |
Remove this include, it isn't needed.
|
| 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..
|
| 243169 |
17-Nov-2012 |
adrian |
.. include ah_desc.h here now.
|
| 243168 |
17-Nov-2012 |
adrian |
Remove the ah_desc.h reference; it's not needed.
I'm using these descriptor header files in userland and I'm trying to
avoid populating a compatibility ah_desc.h file.
|
| 243164 |
16-Nov-2012 |
adrian |
I'm not sure why ah_desc.h was required here, but it doesn't _need_
to be. So, just toss it.
There's no options or ah_desc fields in here.
Whilst I'm here, fix up the #ifdef and #define to mach.
|
| 243163 |
16-Nov-2012 |
adrian |
* Remove a duplicate TX ALQ post routine!
* For CABQ traffic, I -can- chain them together using the next pointer
and just push that particular chain head to the CABQ. However, this
doesn't magically make EDMA TX CABQ work - I have to do some further
hoop jumping.
|
| 243162 |
16-Nov-2012 |
adrian |
ALQ logging enhancements:
* upon setup, tell the alq code what the chip information is.
* add TX/RX path logging for legacy chips.
* populate the tx/rx descriptor length fields with a best-estimate.
It's overly big (96 bytes when AH_SUPPORT_AR5416 is enabled)
but it'll do for now.
Whilst I'm here, add CURVNET_RESTORE() here during probe/attach as a
partial solution to fixing crashes during attach when the attach fails.
There are other attach failures that I have to deal with; those'll come
later.
|
| 243158 |
16-Nov-2012 |
adrian |
ath(4) ALQ logging improvements.
* Add a new method which allows the driver to push the MAC/phy/hal info
into the logging stream.
* Add a new ALQ logging entry which logs the mac/phy/hal information.
* Modify the ALQ startup path to log the MAC/phy/hal information
so the decoder knows which HAL/chip is generating this information.
* Convert the header and mac/phy/hal information to use be32, rather than
host order. I'd like to make this stuff endian-agnostic so I can
decode MIPS generated logs on a PC.
This requires some further driver modifications to correctly log the
right initial chip information.
Also - although noone bar me is currently using this, I've shifted the
debug bitmask around a bit. Consider yourself warned!
|
| 243047 |
15-Nov-2012 |
adrian |
Make sure the final descriptor in an aggregate has rate control information.
This was broken by me when merging the 802.11n aggregate descriptor chain
setup with the default descriptor chain setup, in preparation for supporting
AR9380 NICs.
The corner case here is quite specific - if you queue an aggregate frame
with >1 frames in it, and the last subframe has only one descriptor making
it up, then that descriptor won't have the rate control information
copied into it. Look at what happens inside ar5416FillTxDesc() if
both firstSeg and lastSeg are set to 1.
Then when ar5416ProcTxDesc() goes to fill out ts_rate based on the
transmit index, it looks at the rate control fields in that descriptor
and dutifully sets it to be 0.
It doesn't happen for non-aggregate frames - if they have one descriptor,
the first descriptor already has rate control info.
I removed the call to ath_hal_setuplasttxdesc() when I migrated the
code to use the "new" style aggregate chain routines from the HAL.
But I missed this particular corner case.
This is a bit inefficient with MIPS boards as it involves a few redundant
writes into non-cachable memory. I'll chase that up when it matters.
Tested:
* AR9280 STA mode, TCP iperf traffic
* Rui Paulo <rpaulo@> first reported this and has verified it on
his AR9160 based AP.
PR: kern/173636
|
| 242993 |
13-Nov-2012 |
adrian |
Place 'dev.ath.X.debug' back under ATH_DEBUG, rather than ATH_DEBUG_ALQ.
|
| 242951 |
13-Nov-2012 |
adrian |
Add some debugging to try and catch an invalid TX rate (0x0) that is
being reported.
|
| 242899 |
11-Nov-2012 |
adrian |
Correctly fix the 'scan during STA mode' crash.
|
| 242898 |
11-Nov-2012 |
adrian |
Remove this; i incorrectly committed the wrong (debug) changes in my
previous commit.
|
| 242881 |
11-Nov-2012 |
adrian |
Don't call av_set_tim() if it's NULL.
This happens during a scan in STA mode; any queued data frames will
be power save queued but as there's no TIM in STA mode, it panics.
This was introduced by me when I disabled my driver-aware power save
handling support.
|
| 242880 |
10-Nov-2012 |
adrian |
Correct some rather weird and broken behaviour observed when doing
actual traffic with an AR9380/AR9382/AR9485.
The sample rate control stats would show impossibly large numbers for
"successful packets transmitted." The number was a tad under 2^^64-1.
So after a bit of digging, I found that the sample rate control code
was making 'tries' turn into a negative number.. and this was because
ts_longretry was too small.
The hardware returns "ts_longretry" at the current rate selection,
not overall for that TX descriptor. So if you setup four TX rate
scenarios and the second one works, ts_longretry is only set for
the number of attempts at that second rate scenario. The FreeBSD HAL
code does the correction in ath_hal_proctxdesc() - however, this isn't
possible with EDMA.
EDMA TX completion is done separate from the original TX descriptor.
So the real solution is to split out "find ts_rate and ts_longretry"
from "complete TX descriptor". Until that's done, put a hack in
the EDMA TX path that uses the rate scenario information in the ath_buf.
Tested: AR9380, AR9382, AR9485 STA mode
|
| 242872 |
10-Nov-2012 |
kevlo |
s/ATH_DEBUG/ATH_DEBUG_ALQ
|
| 242853 |
10-Nov-2012 |
kevlo |
Fix the build.
|
| 242813 |
09-Nov-2012 |
adrian |
Fix a very incorrect description.
|
| 242803 |
08-Nov-2012 |
adrian |
Fix the build - fix up the ath_alq code to not compile by default.
|
| 242782 |
08-Nov-2012 |
adrian |
Add some hooks into the driver to attach, detach and record EDMA descriptor
events.
This is primarily for the TX EDMA and TX EDMA completion. I haven't yet
tied it into the EDMA RX path or the legacy TX/RX path.
Things that I don't quite like:
* Make the pointer type 'void' in ath_softc and have if_ath_alq*()
return a malloc'ed buffer. That would remove the need to include
if_ath_alq.h in if_athvar.h.
* The sysctl setup needs to be cleaned up.
|
| 242781 |
08-Nov-2012 |
adrian |
Add my initial cut at driver-layer ALQ support.
I'm using this to debug EDMA TX and RX descriptors and it's really helpful
to have a non-printf() way to decode frames.
I won't link this into the build until I've tidied it up a little more.
This will eventually be behind ATH_DEBUG_ALQ.
|
| 242780 |
08-Nov-2012 |
adrian |
Oops, fix bogus spacing.
|
| 242779 |
08-Nov-2012 |
adrian |
Implement the ATH_RESET_NOLOSS path for TX stop and start; this is needed
for 802.11n TX device restarting.
Remove the debug printf()s; they're no longer needed here.
|
| 242778 |
08-Nov-2012 |
adrian |
Convert this to a debug printf; it's working fine now.
|
| 242698 |
07-Nov-2012 |
adrian |
Don't compile in my (not yet committed) ath_alq code unless ATH_DEBUG_ALQ
is defined.
This will unbreak ATH_DEBUG builds.
|
| 242690 |
07-Nov-2012 |
adrian |
Disable my software queue TIM and PS handling for now.
ps-poll is totally broken in its current form.
This should unbreak things enough to let people use PS-POLL devices,
but leave it in place for me to finish PS-POLL handling.
|
| 242689 |
07-Nov-2012 |
adrian |
Add new HAL configuration features for the updated AR9300 HAL.
|
| 242656 |
06-Nov-2012 |
adrian |
Convert the aggregate descriptor path over to use the same API as
the non-aggregate path.
I "cheated" by using some TX setup code in our HAL that isn't present
in the atheros HAL (or Linux ath9k.)
The old path for forming aggregates was:
* setup the rate control in the first descriptor;
* call chaintxdesc() on all the frames;
* call setupfirsttxdesc() on the first descrpitor in the first
frame;
* call setuplasttxdesc() on the last descriptor in the last frame.
The new path for forming aggregates looks like the non-aggregate path:
* call setuptxdesc() on the first descriptor in the first frame;
* setup the rate control in the first descriptor;
* call filltxdesc() on each descriptor in the frame;
* if it's an aggregate - call set11n_aggr_{first, middle, last} as
appropriate (see the code for a description of what is "appropriate".)
Now, this is done primarily for the AR9300 HAL - it doesn't implement
the first set of aggregate functions. It just has the older methods
and the "first/middle/last" aggregate methods. So, let's convert the
code to use these.
Note: the AR5416 HAL in FreeBSD had that code (from me, a while ago)
and a previous commit brought it up to behave the same as the AR9300
HAL routines.
There's some further tidyups to be done - specifically, avoid doing
multiple calls to the 11n descriptor functions. I shouldn't call
clr11n_aggr(), then set11n_aggr_middle(), then also set11n_aggr_first().
On (at least MIPS) the TX descriptors are in non-cachable memory and
this will cause multiple slow writes.
I'll debug/tidy that up in a future commit.
Tested:
* AR9280, STA
* AR9280/AR9160, AP
* AR9380, STA (using a local, closed source HAL, sorry!)
|
| 242625 |
05-Nov-2012 |
dim |
Remove duplicate const specifiers in many drivers (I hope I got all of
them, please let me know if not). Most of these are of the form:
static const struct bzzt_type {
[...list of members...]
} const bzzt_devs[] = {
[...list of initializers...]
};
The second const is unnecessary, as arrays cannot be modified anyway,
and if the elements are const, the whole thing is const automatically
(e.g. it is placed in .rodata).
I have verified this does not change the binary output of a full kernel
build (except for build timestamps embedded in the object files).
Reviewed by: yongari, marius
MFC after: 1 week
|
| 242604 |
05-Nov-2012 |
adrian |
Clear IFF_DRV_OACTIVE if any slots were completed.
This unblocks TX EDMA under high load.
|
| 242599 |
05-Nov-2012 |
adrian |
TX EDMA debugging fixes:
* Do the calculation for each ath_buf, rather than just the first
* Correct the calculation in the first place.
|
| 242540 |
04-Nov-2012 |
adrian |
Oops - conditionalise that.
|
| 242532 |
03-Nov-2012 |
adrian |
EDMA TX tweaks:
* don't poke ath_hal_txstart() if nothing was pushed into the FIFO during
the refill process;
* shuffle around the TX debugging output a little so it's logged at
TX hardware enqueue;
* Add logging of the TX status processing.
|
| 242528 |
03-Nov-2012 |
adrian |
For AR9380 NICs - the non-enterprise versions don't support RTS protection
of small (< 256 byte) aggregate frames.
This needs to be done or 11n aggregation TX just simply doesn't work
on these NICs.
Whilst here, extend some debug printing; I was using this whilst
debugging the TX power setup in the TX descriptor(s) on the AR9380.
|
| 242527 |
03-Nov-2012 |
adrian |
Add a new HAL call to extract out the HAL enterprise bits from the
AR9300 HAL.
|
| 242510 |
03-Nov-2012 |
adrian |
HAL API updates, from the previous couple of HAL commits.
|
| 242509 |
03-Nov-2012 |
adrian |
HAL API changes!
* introduce a new HAL API method to pull out the TX status descriptor
contents.
* Add num_delims to the 11n first aggr method. This isn't used by the
driver at the moment so it won't affect anything.
|
| 242508 |
03-Nov-2012 |
adrian |
Add a debug method to dump the EDMA TX status descriptor contents out.
This requires some HAL API changes to be useful, as there's no way
right now to pull out the TX status descriptor contents.
|
| 242412 |
31-Oct-2012 |
adrian |
Since the PLL changes aren't in here yet for the AR9130 half/quarter
rate support, disable it.
|
| 242411 |
31-Oct-2012 |
adrian |
Oops - this was incorrectly removed in a previous commit.
|
| 242409 |
31-Oct-2012 |
adrian |
Oops - missing from the last commit - add ANI immunity levels for AR9160.
Obtained from: Qualcomm Atheros
|
| 242408 |
31-Oct-2012 |
adrian |
HAL updates!
* Add some more ANI spur immunity levels.
* For AR5111 radios attached to an AR5212, limit the 5GHz channels
that are available. A later revision of the AR5111 supports the 4.9GHz
PSB channels but right now there's no check in place for the radio
revision.
If someone wants PSB support on AR5212+AR5111 radios then please let
me know and I'll add the relevant version check.
Obtained from: Qualcomm Atheros
|
| 242407 |
31-Oct-2012 |
adrian |
Add in the last random assortment of missing bits for the AR9380 HAL.
Obtained from: Qualcomm Atheros
|
| 242406 |
31-Oct-2012 |
adrian |
Add the emulation PCI device id - these days, 0xabcd shows up all over
the internet as "AR9380 and later which didn't get its PCI ID written
in at power-on", so it's hardly an unknown constant.
Obtained from: Qualcomm Atheros
|
| 242392 |
31-Oct-2012 |
adrian |
I've had some feedback that CCK rates are more reliable than MCS 0
in some very degenerate conditions.
However, until ath_rate_form_aggr() is taught to not form aggregates
if ANY selected rate is non-MCS, this can't yet be enabled.
So, just add a comment.
|
| 242391 |
31-Oct-2012 |
adrian |
I give up - introduce a TX lock to serialise TX operations.
I've tried serialising TX using queues and such but unfortunately
due to how this interacts with the locking going on elsewhere in the
networking stack, the TX task gets delayed, resulting in quite a
noticable throughput loss:
* baseline TCP for 2x2 11n HT40 is ~ 170mbit/sec;
* TCP for TX task in the ath taskq, with the RX also going on - 80mbit/sec;
* TCP for TX task in a separate, second taskq - 100mbit/sec.
So for now I'm going with the Linux wireless stack approach - lock tx
early. The linux code does in the wireless stack, before the 802.11
state stuff happens and before it's punted to the driver.
But TX locking needs to also occur at the driver layer as the TX
completion code _also_ begins to drain the ifnet TX queue.
Whilst I'm here, add some KTR traces for the TX path.
Note:
* This really should be done at the net80211 layer (as well, at least.)
But that'll have to wait for a little more thought to happen.
|
| 242271 |
28-Oct-2012 |
adrian |
Begin fleshing out some software queue awareness for TIM handling with
the power save queue.
* introduce some new ATH_NODE lock protected fields, tracking the
net80211 psq and TIM state;
* when doing buffer transitions - ie, when sending and completing
buffers - check the state of the SWQ and update the TIM appropriately.
* when clearing the TIM bit, if the SWQ is not empty then delay clearing
it.
This is racy, but it's no less racy than the current net80211 power
save queue management code. Specifically, with multiple TX threads,
it's quite plausible that parallel state updates will race and the
TIM will be left in an inconsistent state. I'll address that in
a follow-up commit.
|
| 242258 |
28-Oct-2012 |
adrian |
Add a temporary (for values of "temporary") work around for hotplug
support with ath(4) and VIMAGE.
Right now the VIMAGE code doesn't supply a default vnet context during:
* hotplug attach;
* any device detach.
It special cases kldload/boot time probing (by setting the context to
vnet0) but that doesn't occur when probing devices during a bus rescan -
eg, adding a cardbus card.
These will eventually go away when the VIMAGE support extends to providing
default contexts to hotplug attach/detach.
|
| 242144 |
26-Oct-2012 |
adrian |
Since it's not immediately obvious whether the current TX path handles
fragment rate lookups correctly, add a comment describing exactly that.
The assumption in the fragment duration code is the duration of the next
fragment will match the rate used by the current fragment. But I think
a rate lookup is being done for _each_ fragment. For older pre-sample
rate control this would almost always be the case, but for sample
it may be incorrect more often then correct.
|
| 241567 |
15-Oct-2012 |
adrian |
Track the total number of software queued frames in an atomic variable
stashed away in ath_node.
As much as I tried to stuff that behind the ATH_NODE lock, unfortunately
the locking is just too plain hairy (for me! And I wrote it!) to do
cleanly. Hence using atomics here instead of a lock. The ATH_NODE lock
just isn't currently used anywhere besides the rate control updates.
If in the future everything gets migrated back to using a single ATH_NODE
lock or a single global ATH_TX lock (ie, a single TX lock for all TX and
TX completion) then fine, I'll remove the atomics.
|
| 241566 |
15-Oct-2012 |
adrian |
Stop abusing the ATH_TID_*() queue macros for filtered frames and give
them their own macro set.
|
| 241559 |
14-Oct-2012 |
adrian |
Push the actual TX processing into the ath taskqueue, rather than having
it run out of multiple concurrent contexts.
Right now the ath(4) TX processing is a bit hairy. Specifically:
* It was running out of ath_start(), which could occur from multiple
concurrent sending processes (as if_start() can be started from multiple
sending threads nowdays.. sigh)
* during RX if fast frames are enabled (so not really at the moment, not
until I fix this particular feature again..)
* during ath_reset() - so anything which calls that
* during ath_tx_proc*() in the ath taskqueue - ie, TX is attempted again
after TX completion, as there's now hopefully some ath_bufs available.
* Then, the ic_raw_xmit() method can queue raw frames for transmission
at any time, from any net80211 TX context. Ew.
This has caused packet ordering issues in the past - specifically,
there's absolutely no guarantee that preemption won't occuring _during_
ath_start() by the TX completion processing, which will call ath_start()
again. It's a mess - 802.11 really, really wants things to be in
sequence or things go all kinds of loopy.
So:
* create a new task struct for TX'ing;
* make the if_start method simply queue the task on the ath taskqueue;
* make ath_start() just be called by the new TX task;
* make ath_tx_kick() just schedule the ath TX task, rather than directly
calling ath_start().
Now yes, this means that I've taken a step backwards in terms of
concurrency - TX -and- RX now occur in the same single-task taskqueue.
But there's nothing stopping me from separating out the TX / TX completion
code into a separate taskqueue which runs in parallel with the RX path,
if that ends up being appropriate for some platforms.
This fixes the CCMP/seqno concurrency issues that creep up when you
transmit large amounts of uni-directional UDP traffic (>200MBit) on a
FreeBSD STA -> AP, as now there's only one TX context no matter what's
going on (TX completion->retry/software queue,
userland->net80211->ath_start(), TX completion -> ath_start());
but it won't fix any concurrency issues between raw transmitted frames
and non-raw transmitted frames (eg EAPOL frames on TID 16 and any other
TID 16 multicast traffic that gets put on the CABQ.) That is going to
require a bunch more re-architecture before it's feasible to fix.
In any case, this is a big step towards making the majority of the TX
path locking irrelevant, as now almost all TX activity occurs in the
taskqueue.
Phew.
|
| 241558 |
14-Oct-2012 |
adrian |
Break the RX processing up into smaller chunks of 128 frames each.
Right now processing a full 512 frame queue takes quite a while (measured
on the order of milliseconds.) Because of this, the TX processing ends up
sometimes preempting the taskqueue:
* userland sends a frame
* it goes in through net80211 and out to ath_start()
* ath_start() will end up either direct dispatching or software queuing a
frame.
If TX had to wait for RX to finish, it would add quite a few ms of
additional latency to the packet transmission. This in the past has
caused issues with TCP throughput.
Now, as part of my attempt to bring sanity to the TX/RX paths, the first
step is to make the RX processing happen in smaller 'parts'. That way
when TX is pushed into the ath taskqueue, there won't be so much latency
in the way of things.
The bigger scale change (which will come much later) is to actually
process the frames in the ath_intr taskqueue but process _frames_ in
the ath driver taskqueue. That would reduce the latency between
processing and requeuing new descriptors. But that'll come later.
The actual work:
* Add ATH_RX_MAX at 128 (static for now);
* break out of the processing loop if npkts reaches ATH_RX_MAX;
* if we processed ATH_RX_MAX or more frames during the processing loop,
immediately reschedule another RX taskqueue run. This will handle
the further frames in the taskqueue.
This should have very minimal impact on the general throughput case,
unless the scheduler is being very very strange or the ath taskqueue
ends up spending a lot of time on non-RX operations (such as TX
completion.)
|
| 241500 |
13-Oct-2012 |
adrian |
Fix the non-TDMA build.
|
| 241336 |
07-Oct-2012 |
adrian |
Migrate the TID TXQ accesses to a new set of macros, rather than reusing
the ATH_TXQ_* macros.
* Introduce the new macros;
* rename the TID queue and TID filtered frame queue so the compiler
tells me I'm using the wrong macro.
These should correspond 1:1 to the existing code.
|
| 241229 |
05-Oct-2012 |
adrian |
Initialise an uninitialised variable.
|
| 241195 |
04-Oct-2012 |
adrian |
Implement the quarter rate fractional channel programming for the
AR5416 and AR9280, but leave it disabled by default.
TL;DR: don't enable this code at all unless you go through the process
of getting the NIC re-certified. This is purely to be used as a
reference and NOT a certified solution by any stretch of the imagination.
The background:
The AR5112 RF synth right up to the AR5133 RF synth (used on the AR5416,
derivative is used for the AR9130/AR9160) only implement down to 2.5MHz
channel spacing in 5GHz. Ie, the RF synth is programmed in steps of 2.5MHz
(or 5, 10, 20MHz.) So they can't represent the quarter rate channels
in the 4.9GHz PSB (which end in xxx2MHz and xxx7MHz). They support
fractional spacing in 2GHz (1MHz spacing) (or things wouldn't work,
right?)
So instead of doing this, the RF synth programming for the AR5112 and
later code will round to the nearest available frequency.
If all NICs were RF5112 or later, they'll inter-operate fine - they all
program the same. (And for reference, only the latest revision of the
RF5111 NICs do it, but the driver doesn't yet implement the programming.)
However:
* The AR5416 programming didn't at all implement the fractional synth
work around as above;
* The AR9280 programming actually programmed the accurate centre frequency
and thus wouldn't inter-operate with the legacy NICs.
So this patch:
* Implements the 4.9GHz PSB fractional synth workaround, exactly as the
RF5112 and later code does;
* Adds a very dirty workaround from me to calculate the same channel
centre "fudge" to the AR9280 code when operating on fractional frequencies
in 5GHz.
HOWEVER however:
It is disabled by default. Since the HAL didn't implement this feature,
it's highly unlikely that the AR5416 and AR928x has been tested in these
centre frequencies. There's a lot of regulatory compliance testing required
before a NIC can have this enabled - checking for centre frequency,
for drift, for synth spurs, for distortion and spectral mask compliance.
There's likely a lot of other things that need testing so please don't
treat this as an exhaustive, authoritative list. There's a perfectly good
process out there to get a NIC certified by your regulatory domain, please
go and engage someone to do that for you and pay the relevant fees.
If a company wishes to grab this work and certify existing 802.11n NICs
for work in these bands then please be my guest. The AR9280 works fine
on the correct fractional synth channels (49x2 and 49x7Mhz) so you don't
need to get certification for that. But the 500KHz offset hack may have
the above issues (spur, distortion, accuracy, etc) so you will need to
get the NIC recertified.
Please note that it's also CARD dependent. Just because the RF synth
will behave correctly doesn't at all mean that the card design will also
behave correctly. So no, I won't enable this by default if someone
verifies a specific AR5416/AR9280 NIC works. Please don't ask.
Tested:
I used the following NICs to do basic interoperability testing at
half and quarter rates. However, I only did very minimal spectrum
analyser testing (mostly "am I about to blow things up" testing;
not "certification ready" testing):
* AR5212 + AR5112 synth
* AR5413 + AR5413 synth
* AR5416 + AR5113 synth
* AR9280
|
| 241170 |
03-Oct-2012 |
adrian |
Pause and unpause the software queues for a given node based on the
net80211 node power save state.
* Add an ATH_NODE_UNLOCK_ASSERT() check
* Add a new node field - an_is_powersave
* Pause/unpause the queue based on the node state
* Attempt to handle net80211 concurrency issues so the queue
doesn't get paused/unpaused more than once at a time from
the net80211 power save code.
Whilst here (and breaking my usual rule), set CLRDMASK when a queue
is unpaused, regardless of whether the queue has some pending traffic.
This means the first frame from that TID (now or later) will hvae
CLRDMASK set.
Also whilst here, bump the swretrymax counters whenever the
filtered frames code expires a frame. Again, breaking my rule, but
this is just a statistics thing rather than a functional change.
This doesn't fix ps-poll (but it doesn't break it too much worse
than it is at the present) or correcting the TID updates.
That's next on the list.
Tested:
* AR9220 AP (Atheros AP96 reference design)
* Macbook Pro and LG Optimus 1 Android phone, both setting
and clearing power save state (but not using PS-POLL.)
|
| 240984 |
27-Sep-2012 |
adrian |
Track the last ANI TX/RX sample correctly.
This doesn't specifically fix the issue(s) i'm seeing in this 2GHz
environment (where setting/increasing spur immunity causes OFDM restart
errors to skyrocket through the roof; but leaving it at 0 would leave
the environment cleaner..)
Pointy-hat-to: me, for committing this broken code in the first place.
|
| 240946 |
26-Sep-2012 |
adrian |
Map the non-QoS TID to the voice queue, in order to ensure important
things like EAPOL frames make it out.
After a whole bunch of hacking/testing, I discovered that they weren't
being early-dropped by the stack (but I should look at ensuring that
later..) but were even making to the hardware transmit queue.
They were mostly even being received by the remote end. However, the
remote end was completely ignoring them.
This didn't happen under 150-170MBit TCP tests as I'm guessing the TX
queue stayed very busy and the STA didn't do any scanning. However, when
doing 100Mbit/s of TCP traffic, the STA would do background scanning -
which involves it coming in and out of powersave mode with the AP.
Now, this is a total and utter hack around the real problems, which are:
* I need to implement proper power save handling and integrate it into
the filtered frames support, so the driver/stack doesn't send frames
whilst the station is actually in sleep;
* .. but frames were actually making it to the STA (macbook pro) and
the AP did receive an ACK; but a tcpdump on the receiving side showed
the EAPOL frame never made it. So the stack was dropping it for
some reason;
* Importantly - the EAPOL frames are currently going into the non-QoS
TID, which maps to the BE queue and is susceptible to that queue being
busy doing other things, but;
* There's other traffic going on in the non-QoS TID from other contexts
when scanning is going on and it's possible there's some races causing
sequence number/IV issues, but;
* Importantly importantlly, I think the interaction with TID 16 multicast
traffic in power save mode is causing issues - since I -believe- the
sequence number space being used by the EAPOL frames on TID 16 overlaps
with the multicast frames that have sequence numbers allocated and
are then stuffed on the cabq. Since with EAPOL frames being in TID 16
and queued to the BE queue, it's going to be waiting to be serviced
with all of the aggregate traffic going on - and if the CABQ gets
emptied beforehand, those TID 16 multicast frames with sequence numbers
will go out beforehand.
Now, there's quite likely a bunch of "stuff happening slightly out of
sequence" going on due to the nature of the TX path (read: lots of
overlapping and concurrent ath_start() and ath_raw_xmit() calls going
on, sigh) but I thought I had caught them all and stuffed each TID TX
behind a lock (that lasted as long as it needed to in order to get
the frame onto the relevant destination queue - thus keeping things
in order.)
Unfortunately the last problem is the big one and I'm going to stare at
it some more. If it _is_
So this is a work around for now to ensure that EAPOL frames actually
make it out before any other stuff in the non-QoS TID and HOPEFULLY
before the CABQ gets active.
I'm now going to spend a little time in the TX path figuring out exactly
why the sender is rejecting things. There's two (well, three if you count
EAPOL contents invalid) possibilities:
* The sequence number is out of order (ie, something else like the multicast
traffic on CABQ) is going out first on TID 16;
* The CCMP IV is out of order (similar to above - but less likely, as the
TX key for multicast traffic is different to unicast traffic);
* EAPOL contents strangely invalid.
AP: Ubiquiti RSPRO, AR9160/AR9220 NICs
STA: Macbook Pro, Broadcom 11n NIC
|
| 240926 |
25-Sep-2012 |
adrian |
Oops - don't do the clrdmask check in ath_tx_xmit_normal() - the wrong
lock may be held.
Kim reported that the TID lock wasn't held when ath_tx_update_clrdmask()
was called. Well, the underlying hardware TXQ for that TID.
I'm betting it's the cabq stuff. ath_tx_xmit_normal() can be called
for both real and software cabq. For software cabq, the real destination
txq is different to the txq. So, the lock check will fail.
Reported by: Kim Culhan <w8hdkim@gmail.com>
|
| 240914 |
25-Sep-2012 |
adrian |
Call ath_tx_tid_unsched() after the node has been flushed, so the
state can be printed correctly.
|
| 240899 |
24-Sep-2012 |
adrian |
Migrate the ath(4) KTR logging to use an ATH_KTR() macro.
This should eventually be unified with ATH_DEBUG() so I can get both
from one macro; that may take some time.
Add some new probes for TX and TX completion.
|
| 240895 |
24-Sep-2012 |
adrian |
Debugging output fixes:
* use the correct frame status - although the completion descriptor is
the _last_ in the frame/aggregate, the status is currently stored in
the _first_ buffer.
* Print out ath_buf specific fields once, not per descriptor in an ath_buf.
|
| 240883 |
24-Sep-2012 |
adrian |
Prepare for software retransmission of non-aggregate frames but ensure
it's disabled.
The previous commit to enable CLRDMASK setting didn't do it at all
correctly for non-aggregate sessions - so the CLRDMASK bit would be
cleared and never re-set.
* move ath_tx_update_clrdmask() to be called by functions that setup
descriptors and queue frames to the hardware, rather than scattered
everywhere.
* Force CLRDMASK to be set on all non-aggregate session frames being
transmitted.
* Use ath_tx_normal_comp() now on non-aggregate sessoin frames
that are queued via ath_tx_xmit_normal(). That way the TID hwq is
updated and they can trigger (eventual) filter frame queue resets
and software retransmits.
There's still a bit more work to do in this area to reverse the silly
short-sightedness on my part, however it's likely going to be better
to fix this now than just reverting the patch.
Thanks to people on the freebsd-wireless@ mailing list for promptly
pointing this out.
|
| 240882 |
24-Sep-2012 |
adrian |
In (eventual) preparation for supporting disabling the whole 11n/software
retry path - add some code to make it obvious (to me!) how to disable
the software tx path.
|
| 240724 |
20-Sep-2012 |
adrian |
Introduce the CLRDMASK gating based on tid->clrdmask, enabling filtered
frames to occur.
* Create a new function which will set the bf_flags CLRDMASK bit
if required.
* For raw frames, always set CLRDMASK.
* For BAR, ADDBA frames, always set CLRDMASK.
* For everything else, check if CLRDMASK needs to be set before
calling tx_setds() or tx_setds11n().
* When unpausing a queue or drain/resetting it, set tid->clrdmask=1
just to ensure traffic starts flowing.
What I need to do:
* Modify that function to _clear_ the CLRDMASK if it's not required,
or retried frames may have CLRDMASK set when they don't need to.
(Which isn't a huge deal, but..)
Whilst I'm here:
* ath_tx_normal_xmit() should really act like the AMPDU session TX
functions - any incomplete frames will end up being assigned
ath_tx_normal_comp() which will decrement tid->hwq_depth - but that
won't have been incremented.
So whilst I'm here, add a comment to do that.
* Fix the debug print function to be slightly clearer about things;
it's not a good sign when I can't interpret my own debugging output.
I've done some testing on AR9280/AR5416/AR9160 STA and AP modes.
|
| 240722 |
20-Sep-2012 |
adrian |
Place the comment where it should be.
|
| 240721 |
20-Sep-2012 |
adrian |
Add a work-around for some strange net80211 BAR races in the wireless
stack.
There are unfortunately quite a few odd cases in BAR TX and BAR TX
retransmission that I haven't yet fully diagnosed. So for now, add
this work-around so the resume() function isn't called too often,
decrementing pause to -1 (and causing things to stay paused.)
|
| 240677 |
18-Sep-2012 |
adrian |
Oops - take a copy of ath_tx_status from the buffer before the TX processing
is done.
The aggregate path was definitely accessing 'ts' before it was actually
being assigned.
This had the side effect of over-filtering frames, since occasionally that
bit would be '1'.
Whilst here, do the same thing in the non-aggregate completion function -
as calling the filter function may also invalidate bf.
Pointy hat to: adrian, for not noticing this over many, many code reviews.
|
| 240639 |
18-Sep-2012 |
adrian |
Implement my first cut at filtered frames in aggregation sessions.
The hardware can optionally "filter" frames if successive transmissions
to a given node (ie, "entry in the keycache") fail. That way the hardware
can implement a kind of early abort of all the other frames queued to
that destination, rather than simply trying to TX each frame to that
destination (and failing.)
The background:
* If a frame comes back as being filtered, the hardware didn't try to
TX it (or it was outside the TX burst opportunity.) So, take it as a hint
that some (but not all, see below) frames to the destination may be
filtered.
* If the CLRDMASK bit is set in a TX descriptor, the "filter to this
destination" bit in the keycache entry is cleared and TX to that host
will be unconditionally retried.
* Right now everything has the CLRDMASK bit set, so filtered frames
tend to be aggregates and frames that fall outside of the WME burst
window. It was a bit worse in the past as I had messed up the TX
flags and CLRDMASK wasn't being set on aggregate frames.
The annoying bits:
* It's easy (ish) to do for aggregate session frames - firstly, they
can be retried in any order as long as they're within the BAW, and
there's already a bunch of infrastructure tracking how many frames
the TID has queued to the hardware (tid->hwq_depth.) However, for
frames that bypassed the software queue, hwq_depth doesn't get
incremented. I'll fix that in a subsequent commit.
* For non-aggregate session frames, the only retries that can occur
are ones for sequence numbers that hvaen't successfully been TXed yet.
Since there's no re-ordering going on in non-aggregate sessions, if any
subsequent seqno frames make it out, any filtered frames before that
seqno need to be dropped.
Hence why this initially is just for aggregate session frames.
* Since there may be intermediary frames to the destination that
have CLRDMASK set - for example, any directly dispatched management
frames to that destination - it's possible that there will be some
filtered frames followed up by some non filtered frames. Thus,
it can't be assumed that once you see a filtered frame for the given
destination node, all subsequent frames for all TIDs will be filtered.
Ok, with that in mind:
* Create a per-TID filtered frame queue for frames that the hardware
returns as filtered.
* Track filtered frames per-tid, rather than per-node. It just makes
the locking much easier.
* When a filtered frame appears in the completion function, the node
transitions to "filtered", and all subsequent completed error frames
(filtered or otherwise) are put on the filtered frame queue. The TID
is paused once (during the transition from non-filtered to filtered).
* If a filtered frame retry count exceeds SWMAX_RETRIES, a BAR should be
sent.
* Once all the frames queued to the hardware for the given filtered frame
TID, transition back from filtered frame to non-filtered frame, which
means pre-pending all the filtered frames onto the head of the software
queue, clearing the filtered frame state and unpausing the TID.
Things get quite hairy around handling completion (aggr, non-aggr, norm,
direct-dispatched frames to a hardware queue); whether it's an "error",
"cleanup" or "BAR" state as well as filtered, which order to do things
in (eg do filtered BEFORE checking for BAR, as the filter completion
may be needed to actually transmit a BAR frame.)
This work has definitely reminded me that I have to tidy up all the locking
and remove some of the ridiculous lock/unlock/lock/unlock going on in the
completion functions.
It's also reminded me that I should really split out TID versus hardware TXQ
locking, even if the underlying locking is still the destination hardware TXQ.
Finally, this is all pre-requisite for working on AP mode power save support
(PS-POLL, uAPSD) as well as improving performance to misbehaving nodes (as
they can transition into filter mode, stopping any TX until everything has
caught up.)
Finally (ish) - this should also be done for non-aggregate sessions as
there are still plenty of laptops and mobile devices that don't speak
802.11n but do wish for stable, useful power save AP support where packets
aren't simply dropped. This requires software retransmission for
non-aggregate sessions to be implemented, which includes the caveats I've
mentioned above.
Finally finally - this doesn't yet do anything about the CLRDMASK bit in the
TX descriptor. That's still unconditionally set to 1. I'll debug the
current work (mostly ensuring I haven't busted up the hairy transitions
between BAR, filtered, error (all frames in an aggregate failing) and
cleanup (when transitioning from aggregation -> non-aggregation.))
Finally finally finally - this is all original work by yours truely, rather
than ported from the Atheros internal driver codebase or Linux ath9k.
Tested:
* AR9280, AR5416 in STA mode
* AR9280, AR9130 in hostap mode
* Lots and lots of iperf testing in very marginal and non-marginal conditions,
complete with inducing filtered frames + BAR TX conditions.
|
| 240625 |
18-Sep-2012 |
adrian |
Add a couple of accessor inline functions for state that exists in net80211.
Obtained from: Qualcomm Atheros
|
| 240623 |
17-Sep-2012 |
adrian |
Rename AH_MIMO_MAX_CHAINS to AH_MAX_CHAINS, for compatibility with
internal atheros HAL code.
|
| 240592 |
17-Sep-2012 |
adrian |
Take credit for the work I've done in this source file.
|
| 240585 |
17-Sep-2012 |
adrian |
Add a per-TID filter queue and filter state bits.
These are intended for software TX filtering support, where the NIC
decides there has been too many successive failues to a destination
and will filter it.
Although the filtering is done per-destination (via the keycache),
the state and queue is kept per-TID for now. It simplifies the overall
architecture design and locking.
Whilst here, add ATH_TID_UNLOCK_ASSERT().
|
| 240584 |
17-Sep-2012 |
adrian |
Add a debug bit for TX destination filtering.
|
| 240583 |
17-Sep-2012 |
adrian |
Improve performance of the Sample rate algorithm on 802.11n networks.
* Don't treat high percentage failures as "sucessive failures" - high
MCS rates are very picky and will quite happily "fade" from low
to high failure % and back again within a few seconds. If they really
don't work, the aggregate will just plain fail.
* Only sample MCS rates +/- 3 from the current MCS. Sample will back off
quite quickly, so there's no need to sample _all_ MCS rates between
a high MCS rate and MCS0; there may be a lot of them.
* Modify the smoothing rate to be 75% rather than 95% - it's more adaptive
but it comes with a cost of being slightly less stable at times.
A per-node, hysterisis behaviour would be nicer.
|
| 240471 |
13-Sep-2012 |
adrian |
Don't use AR_PHY_MODE to setup half/quarter rate.
I'm not sure where in the deep, distant past I found the AR_PHY_MODE
registers for half/quarter rate mode, but unfortunately that doesn't
seem to work "right" for non-AR9280 chips.
Specifically:
* don't touch AR_PHY_MODE
* set the PLL bits when configuring half/quarter rate
I've verified this on the AR9280 (5ghz fast clock) and the AR5416.
The AR9280 works in both half/quarter rate; the AR5416 unfortunately
only currently works at half rate. It fails to calibrate on quarter rate.
|
| 240449 |
13-Sep-2012 |
adrian |
Enable fractional 5G mode on half/quarter rate channels.
Obtained from: Linux ath9k
|
| 240448 |
13-Sep-2012 |
adrian |
Flip on half/quarter rate support.
No, this isn't HT/5 and HT/10 support. This is the 11a half/quarter
rate support primarily used by the 4.9GHz and GSM band regulatory
domains.
This is definitely a work in progress.
TODO:
* everything in the last commit;
* lots more interoperability testing with the AR5212 half/quarter rate
support for the relevant chips;
* Do some interop testing on half/quarter rate support between _all_
the 11n chips - AR5416, AR9160, AR9280 (and AR9285/AR9287 when 2GHz
half/quarter rate support is coded up.)
|
| 240447 |
13-Sep-2012 |
adrian |
Introduce an AR5416 flavour of the IFS and mac usec/timing configuration
used when running the chips in half/quarter rate.
This sets up some default parameters which are then overridden by the
driver (which manually configures things like slot timing at interface
start time.)
Although this is a copy-and-modify from the AR5212 HAL, I did peek
at the reference HAL and the ath9k driver to see what they did.
Ath9k in particular doesn't hard-code this - instead, their version
of ar5416InitUserSettings() does all of the relevant math.
TODO:
* do the math, not hard code things!
* fix the mac clock calculation for the AR9287; since it runs the
MAC clock at a higher rate, requiring all the duration calculations
to change;
* Do a whole lot more validation for half/quarter rates.
Obtained from: Qualcomm Atheros, Linux ath9k
|
| 240446 |
13-Sep-2012 |
adrian |
Call the ar5212SetCoverageClass() function for now.
Some of the math is a little wrong thanks to clocks in 11a mode running
at 44MHz when in fast clock mode (rather than 40MHz, which the chips
before AR9280 ran 11a in). That'll have to be addressed in a future commit.
|
| 240445 |
13-Sep-2012 |
adrian |
Add register defintions for the AR5416 TX/RX latency fields.
Obtained from: Qualcomm Atheros
|
| 240444 |
13-Sep-2012 |
adrian |
Compensate for half/quarter rate differences in MAC clock speed.
This fixes the incorrect slot (and likely ACK/RTS timeout) values
which I see when enabling half/quarter rate support on the AR9280.
The resulting math matches the expected calculated default values.
|
| 240333 |
11-Sep-2012 |
adrian |
Clear the correct descriptor when going through the chained together
gather DMA descriptor list.
Pointy hat to: adrian@, for even USING bf->bf_desc here instead of 'ds'.
|
| 240255 |
09-Sep-2012 |
adrian |
Make sure the aggregate fields are properly cleared - both in the
ath_buf and when forming a non-aggregate frame.
The non-11n setds function is called when TXing aggregate frames (and
yes, I should fix this!) and the non-11n TX aggregation code doesn't clear
the delimiter field. I figure it's nicer to do that.
|
| 240254 |
09-Sep-2012 |
adrian |
Remove TDMA #define entries from if_ath.c; they now exist in if_ath_tdma.h.
|
| 240226 |
08-Sep-2012 |
adrian |
Correctly mask out the RTS/CTS flags when forming aggregates.
This had the side effect of clearing HAL_TXDESC_CLRDMASK for a bunch of
frames, meaning they'd end up being potentially filtered if there were
an error. This is fine in the previous world as they'd just be
software retried but now that I'm working on filtered frames, these
descriptors would be endlessly retried until another valid frame would
come along that had CLRDMASK set.
|
| 240180 |
07-Sep-2012 |
adrian |
Ensure that single-frame aggregate session frames are retransmitted
with the correct configuration.
Occasionally an aggregate TX would fail and the first frame would be
retransmitted as a non-AMPDU frame. Since bfs_aggr=1 and bfs_nframes > 1
(from the previous AMPDU attempt), the aggr completion function would be
called and be very confused about what's going on.
Noticed by: Kim <w8hdkim@gmail.com>
PR: kern/171394
|
| 240002 |
02-Sep-2012 |
adrian |
Disable strong signal diversity when enabling radar pulse detection
for the AR5212 era NICs.
|
| 240001 |
02-Sep-2012 |
adrian |
AR5212 radar pulse fixes.
Fix the strong signal diversity capability setting - I had totally
messed up the indentation.
Set the default values to match what's in the .ini for now, rather than
what values I had previously gleaned from places. This seems to work
quite well for the early AR5212 NICs I have. Of course, later NICs
have different PHYs and the radar configuration is very card/board
dependent..
Tested:
* ath1: AR5212 mac 5.3 RF5111 phy 4.1
ath1: 2GHz radio: 0x0023; 5GHz radio: 0x0017
This detects 1, 5, 25, 50, 75, 100uS pulses reliably (with no interference.)
However, 10uS pulses don't detect reliably. That may be around the
transition between short and long pulses so some further tuning may
improve things.
|
| 239966 |
01-Sep-2012 |
adrian |
Fix the PHY / CRC error bug in the AR5212 HAL, which apparently also pops
up on (at least) the AR5413.
The 30 second summary - if a CRC error frame comes in during PHY error
processing, that CRC bit will be set for all subsequent frames until
a non-CRC error frame is processed.
So to allow for accurate PHY error processing (Radar, and ANI on the AR5212
HAL chips) just tag the frame as being both CRC and PHY - let the driver
decide what to do with it.
PR: kern/169362
|
| 239890 |
30-Aug-2012 |
adrian |
Migrate the AR9285 diversity configuration LNA configuration to use
some HAL definitions rather than local definitions.
The original source (ath9k) pulled this stuff from the QCA driver and
removed the HAL_* prefix. I'm just restoring the correct order of things.
Obtained from: Qualcomm Atheros
|
| 239865 |
29-Aug-2012 |
adrian |
There's no nede to allocate a DMA map just before calling bus_dmamem_alloc().
In fact, bus_dmamem_alloc() happily NULLs the dmat pointer passed in,
before replacing it with its own.
This fixes a MIPS crash when kldload'ing if_ath/if_ath_pci -
bus_dmamap_destroy() was passed in a NULL dmat pointer and was doing
all kinds of very bad things.
Reviewed by: scottl
|
| 239803 |
29-Aug-2012 |
adrian |
Set the HAL combined antenna diversity capability if the AR9285
EEPROM settings allow it.
|
| 239802 |
29-Aug-2012 |
adrian |
Add a new capability bit - whether the hardware supports AR9285 style
combined diversity.
|
| 239801 |
29-Aug-2012 |
adrian |
Add AR5413 radar parameters and strong signal diversity capability.
This is a re-implementation based on the reference carrier code
for the AR5413.
Tested:
* Pulse detection for AR5212 and AR5413, to ensure the
correct behaviour for both chips
PR: kern/170904
Obtained from: Qualcomm Atheros
|
| 239800 |
29-Aug-2012 |
adrian |
Add a (temporarily located) definition.
|
| 239797 |
29-Aug-2012 |
adrian |
Remove - not needed.
|
| 239796 |
29-Aug-2012 |
adrian |
Remove extra debugging - there's no longer any need.
|
| 239761 |
27-Aug-2012 |
adrian |
Only print the descriptor contents!
Found by: magical CLANG build environments
Submitted by: Sevan <venture37@gmail.com>
|
| 239756 |
27-Aug-2012 |
adrian |
Improve the sample rate logging.
|
| 239753 |
27-Aug-2012 |
adrian |
Ensure that all firstep values are available in ANI.
The comparison assumes maxFirstepLevel is a count, rather than a maximum
value. The array is 3 entries in size however 'maxFirstepLevel' is 2.
This bug also exists in the AR5212 HAL.
|
| 239752 |
27-Aug-2012 |
adrian |
Fix the debugging output to correctly log CCK errors.
|
| 239704 |
26-Aug-2012 |
adrian |
Move this magic check to only occur if no eeprom data is given.
Tested on:
* AP99 (AR7241+AR9287)
|
| 239703 |
26-Aug-2012 |
adrian |
Add EEPROM data hooks for the AR9287.
Tested:
* AP99 Reference board (AR7241 + AR9287)
|
| 239658 |
24-Aug-2012 |
adrian |
Remove the hard-coded AR5416-series parameters and instead use the
DFS parameters fetched from the HAL.
Check whether the specific chipset supports RADAR reporting before
enabling DFS; or some of the (unset) DFS methods may fail.
Tested:
* AR5210 (correctly didn't enable radar PHY reporting)
* AR5212 (correctly enabled radar PHY reporting w/ the correct default
parameters.)
TODO:
* Now that I have this capability check in place, I could remove the
(empty) DFS methods from AR5210/AR5211.
* Test on AR5416, AR9160, AR9280.
PR: kern/170904
|
| 239657 |
24-Aug-2012 |
adrian |
Correctly handle the "pe_enabled" flag - both when configuring DFS and
fetching the current DFS configuration.
PR: kern/170904
|
| 239656 |
24-Aug-2012 |
adrian |
Add an accessor macro for getting access to the default DFS parameters.
PR: kern/170904
|
| 239643 |
24-Aug-2012 |
adrian |
Add default values for the NumTxMaps capability.
|
| 239642 |
24-Aug-2012 |
adrian |
Add the method to fetch the default DFS parameters for the AR5212 PHY.
I need to check whether new parameters were added for the AR5413 NIC.
PR: kern/170904
|
| 239638 |
24-Aug-2012 |
adrian |
Implement an API to fetch the default DFS parameters for the given chip.
The only chip this is currently implemented for is the AR5416 HAL family.
A follow-up commit will add AR5212 support.
PR: kern/170904
|
| 239637 |
24-Aug-2012 |
adrian |
Bring over some new EEPROM regulatory domain flags.
Obtained from: Qualcomm Atheros
|
| 239635 |
24-Aug-2012 |
adrian |
Oops, another copy/paste issue.
|
| 239634 |
24-Aug-2012 |
adrian |
Add ath_hal_get_curmode() - this is used by the Osprey HAL.
Obtained from: Qualcomm Atheros
|
| 239633 |
24-Aug-2012 |
adrian |
Add rfkill HAL accessor methods.
|
| 239632 |
24-Aug-2012 |
adrian |
Oops, fix copy/paste silliness.
|
| 239631 |
24-Aug-2012 |
adrian |
Add some more capabilities (unused at the present.)
Obtained from: Qualcomm Atheros
|
| 239630 |
24-Aug-2012 |
adrian |
Add the MFP capability to ath_hal_getcapability().
Obtained from: Qualcomm Atheros
|
| 239629 |
24-Aug-2012 |
adrian |
Add some more diagnostic codes.
Obtained from: Qualcomm Atheros
|
| 239628 |
24-Aug-2012 |
adrian |
Wrap this a little so it's slightly easier on the eyes.
|
| 239627 |
24-Aug-2012 |
adrian |
Add some new flags:
* mfp support;
* 4.9ghz support in the HAL;
* device type - specifically, the bus type and whether it's a HB63
NIC (which requires some subtle chainmask handling differences
in the AR5416 HAL.)
Obtained from: Qualcomm Atheros
|
| 239606 |
23-Aug-2012 |
adrian |
Add a placeholder and typedefs for MFP (management frame protection.)
Obtained from: Qualcomm Atheros
|
| 239605 |
23-Aug-2012 |
adrian |
Add some more interrupt handling bits.
Obtained from: Qualcomm Atheros
|
| 239604 |
23-Aug-2012 |
adrian |
Add AR9380 devid HAL definitions and probe/attach strings.
Obtained from: Device IDs are from Qualcomm Atheros
|
| 239603 |
23-Aug-2012 |
adrian |
Add chipset names.
|
| 239504 |
21-Aug-2012 |
adrian |
Initialise an uninitialised variable.
GCC on -9 didn't pick this up; clang did.
Submitted by: David Wolfskill
|
| 239465 |
20-Aug-2012 |
adrian |
Fix a build issue when ATH_DEBUG isn't defined - just initialise and use
qnum.
|
| 239438 |
20-Aug-2012 |
adrian |
Wrap debugging in #ifdef ATH_DEBUG
|
| 239410 |
20-Aug-2012 |
adrian |
Flesh out some initial EDMA TX FIFO fill, complete and refill routines.
Note: This is totally sub-optimal and a work in progress.
* Support filling an empty FIFO TXQ with frames from the ath_buf queue
in the ath_txq list. However, since there's (currently) no clean, easy
way to separate the frames that are in the FIFO versus just waiting,
the code waits for the FIFO to be totally empty before it attempts to
queue more. This is highly sub-optimal but is enough to get the ball
rolling.
* A _lot_ of the code assumes that the TX status is filled out in the
struct ath_buf bf_status field. So for now, memcpy() the completion over.
* None of the TX drain / reset routines will attempt to complete completed
frames before draining, so it can't be used for 802.11n TX aggregation.
(This won't work anyway, as the aggregation TX descriptor API hasn't
yet been converted; and that'll happen in some future commits.)
* Fix an issue where the FIFO counter wasn't being incremented, leading
to the queue logic just plain not working.
* HAL_EIO means "descriptor wasn't valid", versus "not finished, don't
continue." So don't stop processing descriptors when HAL_EIO is hit.
* Don't service frame completion from the beacon queue. It isn't currently
fully setup like a real queue and the first attempt at accessing the
queue lock will panic the kernel.
Tested:
* AR9380, STA mode
This commit is brought to you by said AR9380 in STA mode.
|
| 239409 |
20-Aug-2012 |
adrian |
Advance the descriptor pointer by sc->sc_tx_desclen bytes, rather than
sizeof(struct ath_desc). This isn't correct for EDMA TX descriptors.
This popped up during iperf tests. Ping tests never created frames that
had enough segments to overflow into a second descriptor. However,
an iperf TCP test would do that after a few seconds; the second descriptor
would almost always certainly have garbage.
Tested:
* AR9380, STA mode
* AR9280, STA mode (802.11n TX, legacy TX)
|
| 239408 |
20-Aug-2012 |
adrian |
Make sure all of the buffers are printed, rather than (n-1).
|
| 239381 |
19-Aug-2012 |
adrian |
Extend the TX descriptor debug printing to be properly aware of
EDMA code.
* create a new TX EDMA descriptor struct to represent TX EDMA descriptors
when doing debugging;
* implement an EDMA printing function which:
+ hardcodes the TX map size to 4 for now;
+ correctly prints out the number of segments - there's one descriptor
for up to 4 buffers (segments), not one for each segment;
+ print out 4 DS buffer and len pointers;
+ print out the correct number of DWORDs in the TX descriptor.
TODO:
* Remove all of the hard-coded stuff. Ew.
|
| 239380 |
19-Aug-2012 |
adrian |
When assembling the descriptor list, make sure that the "first" descriptor
is marked correctly.
The existing logic assumed that the first descriptor is i == 0, which
doesn't hold for EDMA TX. In this instance, the first time filltxdesc()
is called can be up to i == 3.
So for a two-buffer descriptor:
* firstSeg is set to 0;
* lastSeg is set to 1;
* the ath_hal_filltxdesc() code will treat it as the last segment in
a descriptor chain and blank some of the descriptor fields, causing
the TX to stop.
When firstSeg is set to 1 (regardless of lastSeg), it overrides the
lastSeg setting. Thus, ath_hal_filltxdesc() won't blank out these
fields.
Tested: AR9380, STA mode. With this, association is successful.
|
| 239300 |
15-Aug-2012 |
kib |
Fix build
|
| 239290 |
15-Aug-2012 |
adrian |
Extend the non-aggregate TX descriptor chain routine to be aware of:
* the descriptor ID, and
* the multi-buffer support that the EDMA chips support.
This is required for successful MAC transmission of multi-descriptor
frames. The MAC simply hangs if there are NULL buffers + 0 length pointers,
but the descriptor did have TxMore set.
This won't be done for the 11n aggregate path, as that will be modified
to use the newer API (ie, ath_hal_filltxdesc() and then set first|middle|
last_aggr), which will deprecate some of the current code.
TODO:
* Populate the numTxMaps field in the HAL, then make sure that's fetched
by the driver. Then I can undo that hack.
Tested:
* AR9380, AP mode, TX'ing non-aggregate 802.11n frames;
* AR9280, STA/AP mode, doing aggregate and non-aggregate traffic.
|
| 239289 |
15-Aug-2012 |
adrian |
Bump up the rate control table size to incorporate 3 stream entries.
|
| 239288 |
15-Aug-2012 |
adrian |
Remove this comment, it's no longer relevant.
|
| 239287 |
15-Aug-2012 |
adrian |
Extend the duration calculations to work with three and four stream
rates.
|
| 239286 |
15-Aug-2012 |
adrian |
Add a missing comma.
Pointy hat to: me, for not doing a 'clean' build first.
|
| 239285 |
15-Aug-2012 |
adrian |
Add 3 stream rates to the sample rate control module.
|
| 239284 |
15-Aug-2012 |
adrian |
Extend the sample mask from 32 bits to 64 bits.
This is required to support > MCS15 as more than 32 bit rate entries are
suddenly available.
This is quite messy - instead of doing typecasts at each mask operation,
this should be migrated to use a macro and have that do the typecast.
|
| 239282 |
15-Aug-2012 |
adrian |
Implement a sequential descriptor ID value and stuff it in the ath_buf.
This will be used by the EDMA TX code to assign descriptor IDs in order
to provide some debugging.
|
| 239263 |
14-Aug-2012 |
adrian |
Dump out the TX FIFO depth.
|
| 239262 |
14-Aug-2012 |
adrian |
Break out the TX completion code into a separate function, so it can be
re-used by the upcoming EDMA TX completion code.
Make ath_stoptxdma() public, again so the EDMA TX code can use it.
Don't check for the TXQ bitmap in the ISR when doing EDMA work as it
doesn't apply for EDMA.
|
| 239261 |
14-Aug-2012 |
adrian |
Add an assertion to check that the given TXQ is _not_ locked.
|
| 239205 |
12-Aug-2012 |
adrian |
Revert the ath_tx_draintxq() method, and instead teach it the minimum
necessary to "do" EDMA.
It was just using the TX completion status for logging information about
the descriptor completion. Since with EDMA we don't know this without
checking the TX completion FIFO, we can't provide this information.
So don't.
|
| 239204 |
12-Aug-2012 |
adrian |
Break out ath_draintxq() into a method and un-methodize ath_tx_processq().
Now that I understand what's going on with this, I've realised that
it's going to be quite difficult to implement a processq method in
the EDMA case. Because there's a separate TX status FIFO, I can't
just run processq() on each EDMA TXQ to see what's finished.
i have to actually run the TX status queue and handle individual
TXQs.
So:
* unmethodize ath_tx_processq();
* leave ath_tx_draintxq() as a method, as it only uses the completion status
for debugging rather than actively completing the frames (ie, all frames
here are failed);
* Methodize ath_draintxq().
The EDMA ath_draintxq() will have to take care of running the TX
completion FIFO before (potentially) freeing frames in the queue.
The only two places where ath_tx_draintxq() (on a single TXQ) are used:
* ath_draintxq(); and
* the CABQ handling in the beacon setup code - it drains the CABQ before
populating the CABQ with frames for a new beacon (when doing multi-VAP
operation.)
So it's quite possible that once I methodize the CABQ and beacon handling,
I can just drop ath_tx_draintxq() in its entirety.
Finally, it's also quite possible that I can remove ath_tx_draintxq()
in the future and just "teach" it to not check the status when doing
EDMA.
|
| 239201 |
11-Aug-2012 |
adrian |
Extend the beacon code slightly to support AP mode beaconing for the
EDMA HAL hardware.
* The EDMA HAL code assumes the nexttbtt and intval values are in TU/8
units, rather than TU. For now, just "hack" around that here, at least
until I code up something to translate it in the HAL.
* Setup some different TXQ flags for EDMA hardware.
* The EDMA HAL doesn't support setting the first rate series via
ath_hal_setuptxdesc() - instead, a call to ath_hal_set11nratescenario()
is always required. So for now, just do an 11n rate series setup
for EDMA beacon frames.
This allows my AR9380 to successfully transmit beacon frames.
However, CABQ TX and all normal data frame TX and TX completion is
still not functional and will require some more significant code churn
to make work.
|
| 239199 |
11-Aug-2012 |
adrian |
Add the AR9380 HAL to the TX descriptor debugging, in order to dump all
of the descriptor contents.
|
| 239198 |
11-Aug-2012 |
adrian |
Add the AR9300 HAL ID in to the 11n check routine.
I was having TX hang issues, which I root caused to having the
legacy ath_hal_setupxtxdesc() called, rather than the 11n rate scenario
setup code. This meant that rate control information wasn't being
put into frames, causing the MAC to stall/hang.
|
| 239197 |
11-Aug-2012 |
adrian |
Begin fleshing out the TX FIFO support.
* Add ATH_TXQ_FIRST() for easy tasting of what's on the list;
* Add an "axq_fifo_depth" for easy tracking of how deep the current
FIFO is;
* Flesh out the handoff (mcast, hw) functions;
* Begin fleshing out a TX ISR proc, which tastes the TX status FIFO.
The legacy hardware stuffs the TX completion at the end of the final frame
descriptor (or final sub-frame when doing aggregate.) So it's feasible
to do a per-TXQ drain and process, as the needed info is right there.
For EDMA hardware, there's a separate TX completion FIFO. So the TX
process routine needs to read the single FIFO and then process the
frames in each hardware queue.
This makes it difficult to do a per-queue process, as you'll end up with
frames in the TX completion FIFO for a different TXQ to the one you've
passed to ath_tx_draintxq() or ath_tx_processq().
Testing:
I've tested the TX queue and TX completion code in hostap mode on an
AR9380. Beacon frames successfully transmit and the completion routine
is called. Occasional data frames end up in TXQ 1 and are also
successfully completed.
However, this requires some changes to the beacon code path as:
* The AR9380 beacon configuration API is now in TU/8, rather than
TU;
* The AR9380 TX API requires the rate control is setup using a call
to setup11nratescenario, rather than having the try0 series setup
(rate/tries for the first series); so the beacon won't go out.
I'll follow this up with commits to the beacon code.
|
| 239134 |
07-Aug-2012 |
adrian |
Commit device IDs for the (eventually upcoming) AR9380 HAL.
Obtained from: Qualcomm Atheros, Linux ath9k
|
| 239120 |
07-Aug-2012 |
adrian |
Correct re-initialise the link pointer to be the final descriptor in
the last buffer.
This fixes traffic stalls that were occuring with stuck beacon events.
PR: kern/170433
|
| 239111 |
06-Aug-2012 |
adrian |
Remove unnecessary debugging printf()s.
|
| 239053 |
05-Aug-2012 |
adrian |
Migrate the 802.11n ath_hal_chaintxdesc() API to use a buffer/segment
array, similar to what filltxdesc() uses.
This removes the last reference to ds_data in the TX path outside of
debugging statements. These need to be adjusted/fixed.
Tested:
* AR9280 STA/AP with iperf TCP traffic
|
| 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
|
| 238993 |
02-Aug-2012 |
adrian |
Fix an issue that crept in with the previous descriptor tidyup.
When forming aggregates, the last descriptor was now not being
correctly setup - instead, the "setuplasttxdesc" call was being
handed the first descriptor in the last subframe, rather than the
last descriptor in the last subframe.
This showed up as "bad series0 hwrate" messages, as the final
descriptor just didn't have any of the rate control information
squirreled away.
Tested:
* AR9280 STA -> 11n AP, iperf TCP
|
| 238962 |
01-Aug-2012 |
adrian |
Fix a case of "mis-located braces".
PR: kern/170302
|
| 238961 |
01-Aug-2012 |
adrian |
Allow 802.11n hardware to support multi-rate retry when RTS/CTS is
enabled.
The legacy (pre-802.11n) hardware doesn't support this - although
the AR5212 era hardware supports MRR, it doesn't have all the bits
needed to support MRR + RTS/CTS. The AR5416 and later support
a packet duration and RTS/CTS flags per rate scenario, so we should
support it.
Tested:
* AR9280, STA
PR: kern/170302
|
| 238949 |
31-Jul-2012 |
adrian |
Shuffle the call to ath_hal_setuplasttxdesc() to _after_ the rate control
code is called and remove it from ath_buf_set_rate().
For the legacy (non-11n API) TX routines, ath_hal_filltxdesc() takes care
of setting up the intermediary and final descriptors right, complete
with copying the rate control info into the final descriptor so the
rate modules can grab it.
The 11n version doesn't do this - ath_hal_chaintxdesc() doesn't
copy the rate control bits over, nor does it clear isaggr/moreaggr/
pad delimiters. So the call to setuplasttxdesc() is needed here.
So:
* legacy NICs - never call the 11n rate control stuff, so filltxdesc
copies the rate control info right;
* 11n NICs transmitting legacy or 11n non-aggregate frames -
ath_hal_set11nratescenario() is called to setup rate control and
then ath_hal_filltxdesc() chains them together - so the rate control
info is right;
* 11n aggregate frames - set11nratescenario() is called, then
ath_hal_chaintxdesc() is called to chain a list of aggregate and subframes
together. This requires a call to ath_hal_setuplasttxdesc() to complete
things.
Tested:
* AR9280 in station mode
TODO:
* I really should make sure that the descriptor contents get blanked
out correctly or garbage left over from aggregate frames may show
up in non-aggregate frames, leading to badness.
|
| 238947 |
31-Jul-2012 |
adrian |
Push the rate control and descriptor chaining into the descriptor "set"
functions, for both legacy and 802.11n.
This will simplify supporting the EDMA chipsets as these two descriptor
setup functions can just be overridden in their entirety, hiding all of
the subtle differences in setting things up.
It's not a permanent solution, as eventually the AR5416 HAL should grow
similar versions of the 11n descriptor functions and then those can be
used.
TODO:
* Push the "clr11naggr" call into the legacy setds, just to ensure
that retried frames don't end up with the aggregate bits set
inappropriately;
* Remove the "setlasttxdesc" call from the 11n TX path and push it
into setds_11n.
* Ensure that setds_11n will work correctly for non-aggregate frames;
* .. and then when it does, just unconditionally call "setds_11n" for
11n NICs and "setds" for non-11n NICs.
|
| 238931 |
31-Jul-2012 |
adrian |
Migrate some more TX side setup routines to be methods.
|
| 238930 |
31-Jul-2012 |
adrian |
Break out the hardware handoff and TX DMA restart code into methods.
These (and a few others) will differ based on the underlying DMA
implementation.
For the EDMA NICs, simply stub them out in a fashion which will let
me focus on implementing the necessary descriptor API changes.
|
| 238929 |
31-Jul-2012 |
adrian |
Placeholder ioctl for an upcoming rate control statistics API change.
|
| 238885 |
29-Jul-2012 |
adrian |
Shuffle the rate control call to be consistent with non-aggregate TX.
The correct ordering for non-aggregate TX is:
* call ath_hal_setuptxdesc() to setup the first TX descriptor complete
with the first TX rate/try count;
* call ath_hal_setupxtxdesc() to setup the multi-rate retry;
* .. or for 802.11n NICs, call ath_hal_set11nratescenario() for MRR and
802.11n flags;
* then call ath_hal_filltxdesc() to setup intermediary descriptors
in a multi-descriptor single frame.
The call to ath_hal_filltxdesc() routines seem to correctly (consistently?)
handle the intermediary descriptor flags, including copying the rate
control information to the final descriptor in the frame. That's used
by the rate control module rather than the hardware.
Tested:
* Only on AR9280 STA mode, however it should work on other chips in
both STA and AP mode.
|
| 238884 |
29-Jul-2012 |
adrian |
Fix breakage introduced in r238824 - correctly calculate the descriptor
wrapping.
The previous code was only wrapping descriptor "block" boundaries rather
than individual descriptors. It sounds equivalent but it isn't.
r238824 changed the descriptor allocation to enforce that an individual
descriptor doesn't wrap a 4KiB boundary rather than the whole block
of descriptors. Eg, for TX descriptors, they're allocated in blocks
of 10 descriptors for each ath_buf (for scatter/gather DMA.)
|
| 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".
|
| 238857 |
28-Jul-2012 |
adrian |
Commit missing #define from a previous check-in.
The AR9300 and later have an 8-deep TX FIFO for each hardware queue.
|
| 238855 |
28-Jul-2012 |
adrian |
Flesh out the initial TX FIFO storage for each hardware TX queue.
|
| 238854 |
28-Jul-2012 |
adrian |
Add a missing call to ath_txdma_teardown().
|
| 238843 |
27-Jul-2012 |
adrian |
Tidy up the TX status fields a little and add a couple new flags.
* shuffle things around so things fall on natural padding boundaries;
* add a couple of new flags to specify LDPC and whether to switch to the
low power RX chain configuration after this TX has completed.
Obtained from: Qualcomm Atheros
|
| 238842 |
27-Jul-2012 |
adrian |
Add STBC TX support for AR5416 HAL chips.
Specifically, however:
* AR9280 and later support 1-stream STBC RX;
* AR9280 and AR9287 support 1-stream STBC TX.
The STBC support isn't announced (yet) via net80211 and it isn't at all
chosen by the rate control code, so there's no real consumer of this
yet.
Obtained from: Qualcomm Atheros
|
| 238841 |
27-Jul-2012 |
adrian |
Add a STBC TX flag.
Obtained from: Qualcomm Atheros
|
| 238840 |
27-Jul-2012 |
adrian |
Add some comments about what the two fields mean.
|
| 238839 |
27-Jul-2012 |
adrian |
Introduce a couple more fields in the rate scenario setup as part of
(future) TPC support in the AR9300 HAL.
This is effectively a no-op for the moment as (a) TPC isn't really
supported, (b) the AR9300 HAL isn't yet public, and (c) the existing
HAL code doesn't use these fields.
Obtained from: Qualcomm Atheros
|
| 238838 |
27-Jul-2012 |
adrian |
Bring this API in line with what the reference driver and Linux ath9k
was doing.
Obtained from: Qualcomm Atheros, Linux ath9k
|
| 238836 |
27-Jul-2012 |
adrian |
Allocate a descriptor ring for EDMA TX completion status.
Configure the hardware with said ring physical address and size.
|
| 238832 |
27-Jul-2012 |
adrian |
Modify ath_descdma_cleanup() to handle ath_descdma instances with no
buffers.
ath_descdma is now being used for things other than the classical
combination of ath_buf + ath_desc allocations. In this particular case,
don't try to free and blank out the ath_buf list if it's not passed in.
|
| 238824 |
27-Jul-2012 |
adrian |
Migrate the descriptor allocation function to not care about the number
of buffers, only the number of descriptors.
This involves:
* Change the allocation function to not use nbuf at all;
* When calling it, pass in "nbuf * ndesc" to correctly update how many
descriptors are being allocated.
Whilst here, fix the descriptor allocation code to correctly allocate
a larger buffer size if the Merlin 4KB WAR is required. It overallocates
descriptors when allocating a block that doesn't ever have a 4KB boundary
being crossed, but that can be fixed at a later stage.
|
| 238822 |
27-Jul-2012 |
adrian |
Refactor out the descriptor allocation code from the buffer allocation
code.
The TX EDMA completion path is going to need descriptors allocated but
not any buffers. This code will form the basis for that.
|
| 238731 |
24-Jul-2012 |
adrian |
Add a new HAL method - the AR93xx and later NICs have a separate
TX descriptor ring for TX status completion. This API call will pass
the allocated buffer details to the HAL.
|
| 238729 |
23-Jul-2012 |
adrian |
Modify ath_descdma_setup() to take a descriptor size parameter.
The AR9300 and later descriptors are 128 bytes, however I'd like to make
sure that isn't used for earlier chips.
* Populate the TX descriptor length field in the softc with
sizeof(ath_desc)
* Use this field when allocating the TX descriptors
* Pre-AR93xx TX/RX descriptors will use the ath_desc size; newer ones will
query the HAL for these sizes.
|
| 238711 |
23-Jul-2012 |
adrian |
Revert this; it wasn't supposed to be part of this commit.
|
| 238710 |
23-Jul-2012 |
adrian |
Begin separating out the TX DMA setup in preparation for TX EDMA support.
* Introduce TX DMA setup/teardown methods, mirroring what's done in
the RX path.
Although the TX DMA descriptor is setup via ath_desc_alloc() /
ath_desc_free(), there TX status descriptor ring will be allocated
in this path.
* Remove some of the TX EDMA capability probing from the RX path and
push it into the new TX EDMA path.
|
| 238709 |
23-Jul-2012 |
adrian |
Flesh out a new DMA map for the EDMA TX completion status, as well
as a lock to go with that whole code path.
|
| 238708 |
23-Jul-2012 |
adrian |
Begin modifying the descriptor allocation functions to support a variable
sized TX descriptor.
This is required for the AR93xx EDMA support which requires 128 byte
TX descriptors (which is significantly larger than the earlier
hardware.)
|
| 238638 |
20-Jul-2012 |
adrian |
Introduce a rate table TLV so rate table statistics consumers
know how to map rix -> rate code.
|
| 238636 |
20-Jul-2012 |
adrian |
Bump this up to match what the HAL is at now.
|
| 238634 |
20-Jul-2012 |
adrian |
Enable the basic node-based rate control statistics via an ioctl().
|
| 238633 |
20-Jul-2012 |
adrian |
Add a per-node rate control routine for each rate control module.
For now, the only module implement is 'sample', and that's only partially
implemented. The main issue here with reusing this structure in userland
is that it uses 'rix' everywhere, which requires the userland code to
have access to the current HAL rate table.
For now, this is a very large work in progress.
Specific details:
* The rate control information is per-node at the moment and wrapped
in a TLV, to ease parsing and backwards compatibility.
* .. but so I can be slack for now, the userland statistics are just
a copy of the kernel-land sample node state.
* However, for now use a temporary copy and change the rix entries
to dot11rate entries to make it slightly easier to eyeball.
Problems:
* The actual rate information table is unfortunately indexed by rix
and it doesn't contain a rate code. So the userland side of this
currently has no way to extract out a mapping.
TODO:
* Add a TLV payload to dump out the rate control table mapping so
'rix' can be turned into a dot11 / MCS rate.
* .. then remove the temporary copy.
|
| 238632 |
20-Jul-2012 |
adrian |
Create an ioctl API for fetching the current rate control information.
|
| 238630 |
20-Jul-2012 |
adrian |
Prepare for (re)using this header file in userland.
Remove the inlined code from the header file if it's compiled in userland.
It's not required and it shouldn't be there in the first place.
|
| 238609 |
19-Jul-2012 |
adrian |
Convert the TX path to use the new HAL methods for accessing the
TX descriptor link pointers.
This is required for the AR93xx and later chipsets.
The RX path is slightly different - the legacy RX path directly
accesses ath_desc->ds_link for now, however this isn't at all done
for EDMA (FIFO) RX.
Now, for those performing a little software archeology here:
This is all a bit sub-optimal. "struct ath_desc" is only really relevant
for the pre-AR93xx NICs - where ds_link and ds_data is always in the
same location.
The AR93xx and later NICs have different descriptor layouts altogether.
Now, for AR93xx and later NICs, you should never directly reference
ds_link and ds_data, as:
* the RX descriptors don't have either - the data is _after_ the RX
descriptor. They're just one large buffer. There's also no need for
a per-descriptor RX buffer size as they're all fixed sizes.
* the TX descriptors have 4 buffer and 4 length fields _and_ a link
pointer. Each frame takes up one TX FIFO pointer, but it can contain
multiple subframes (either multiple frames in a buffer, and/or
multiple frames in an aggregate/RIFS burst.)
* .. so, when TX frames are queued to a hardware queue, the link
pointer is ONLY for buffers in that frame/aggregate. The next frame
starts in a new FIFO pointer.
* Finally, descriptor completion status is in a different ring.
I'll write something up about that when its time to do so.
This was inspired by Linux ath9k and the reference driver but is a
reimplementation.
Obtained from: Linux ath9k, Qualcomm Atheros
|
| 238608 |
19-Jul-2012 |
adrian |
Use HAL_NUM_RX_QUEUES rather than a magic constant.
|
| 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
|
| 238507 |
15-Jul-2012 |
adrian |
Handle RX Keymiss events.
The AR9003 series NICs implement a separate RX error to signal that a
Keycache miss occured. The earlier NICs would not set the key index
valid bit.
I'll dig into the difference between "no key index bit set" and "keycache
miss".
|
| 238506 |
15-Jul-2012 |
adrian |
Log the number of handled decsriptors and valid descriptors when
hitting RXEOL.
|
| 238449 |
14-Jul-2012 |
adrian |
Fix build breakage when one isn't building with IEEE80211_SUPPORT_SUPERG.
Noticed by: mav
|
| 238445 |
14-Jul-2012 |
adrian |
Merge in some other features from the legacy RX path:
* wrap the RX proc calls in the RX refcount;
* call the DFS checking, fast frames staging and TX rescheduling if
required.
TODO:
* figure out if I can just make "do TX rescheduling" mean "schedule
TX taskqueue" ?
|
| 238441 |
14-Jul-2012 |
adrian |
Make sure that 'rs' is pointing to the correct RX status.
|
| 238440 |
14-Jul-2012 |
adrian |
Ensure that error is set.
Noticed by: rui
|
| 238436 |
14-Jul-2012 |
adrian |
Change the RX EDMA path to first complete the FIFO, then re-populate it
with fresh descriptors, before handling the frames.
Wrap it all in the RX locks.
Since the FIFO is very shallow (16 for HP, 128 for LP) it needs to be
drained and replenished very quickly. Ideally, I'll eventually move this
RX FIFO drain/fill into the interrupt handler, only deferring the actual
frame completion.
|
| 238435 |
14-Jul-2012 |
adrian |
Don't free the descriptor allocation/map if it doesn't exist.
I missed this in my previous commit.
|
| 238433 |
14-Jul-2012 |
adrian |
Create an RX queue lock.
Ideally these locks would go away and there'd be a single driver lock,
like what iwn(4) does. I'll worry about that later.
|
| 238432 |
14-Jul-2012 |
adrian |
Fix EDMA RX to actually work without panicing the machine.
I was setting up the RX EDMA buffer to be 4096 bytes rather than the
RX data buffer portion. The hardware was likely getting very confused
and DMAing descriptor portions into places it shouldn't, leading to
memory corruption and occasional panics.
Whilst here, don't bother allocating descriptors for the RX EDMA case.
We don't use those descriptors. Instead, just allocate ath_buf entries.
|
| 238365 |
11-Jul-2012 |
jhb |
Cast a bus address to a uintmax_t for a debug printf to fix the build on
arm.
|
| 238364 |
11-Jul-2012 |
jhb |
Map ATH_KTR_* to 0 when ATH_DEBUG is not defined. This effectively NOPs
out their use in that case.
|
| 238350 |
10-Jul-2012 |
jhb |
Fix build when ATH_DEBUG is not defined.
|
| 238349 |
10-Jul-2012 |
adrian |
Commit missing flags for the high/low priority (HP/LP) RX queues.
Noticed by: everyone
|
| 238344 |
10-Jul-2012 |
adrian |
Add some debugging and comments about what's going on when reinitialising
the FIFO.
I still see some corner cases where no RX occurs when it should be
occuring. It's quite possible that there's a subtle race condition
somewhere; or maybe I'm not programming the RX queues right.
There's also no locking here yet, so any reset/configuration path
state change (ie, enabling/disabling receive from the ioctl, net80211
taskqueue, etc) could quite possibly confuse things.
|
| 238343 |
10-Jul-2012 |
adrian |
Flip on EDMA RX of both HP and LP queue frames.
Yes, this is in the legacy interrupt path. The NIC does support
MSI but I haven't yet sat down and written that code.
|
| 238339 |
10-Jul-2012 |
adrian |
Migrate the ATH_KTR_* fields out to if_ath_debug.h .
|
| 238338 |
10-Jul-2012 |
adrian |
Print the TX buffer if this error condition is asserted.
I need to figure out why this is occuring. Hopefully I can get enough
descriptor dumps to figure it out.
|
| 238337 |
10-Jul-2012 |
adrian |
Add/fix EDMA RX behaviour.
* For now, kickpcu should hopefully just do nothing - the PCU doesn't need
'kicking' for Osprey and later NICs. The PCU will just restart once
the next FIFO entry is pushed in.
* Teach "proc" about "dosched", so it can be used to just flush the
FIFO contents without adding new FIFO entries.
* .. and now, implement the RX "flush" routine.
* Re-initialise the FIFO contents if the FIFO is empty (the DP is NULL.)
When PCU RX is disabled (ie, writing RX_D to the RX configuration
register) then the FIFO will be completely emptied. If the software FIFO
is full, then no further descriptors are pushed into the FIFO and
things stall.
This all requires much, much more thorough stress testing.
|
| 238333 |
10-Jul-2012 |
adrian |
Reorder these so they match the capability enum order.
|
| 238317 |
10-Jul-2012 |
adrian |
Implement EDMA RX for AR93xx and later chips.
This is inspired by ath9k and the reference driver, but it's a new
implementation of the RX FIFO handling.
This has some issues - notably the FIFO needs to be reprogrammed when
the chip is reset.
|
| 238316 |
10-Jul-2012 |
adrian |
Convert sc_rxpending to a per-EDMA queue, and use that for the legacy code.
Prepare ath_rx_pkt() to handle multiple RX queues, and default the legacy
RX queue to use the HP queue.
|
| 238314 |
10-Jul-2012 |
adrian |
Add some AR9300 HAL descriptor definition changes.
* Add a couple of RX errors;
* Add the spectral scan PHY error code;
* extend the RX flags to be a 16 bit field, rather than an 8 bit field;
* Add a new RX flag.
Obtained from: Qualcomm Atheros
|
| 238284 |
09-Jul-2012 |
adrian |
Further preparations for the RX EDMA support.
Break out the DMA descriptor setup/teardown code into a method.
The EDMA RX code doesn't allocate descriptors, just ath_buf entries.
|
| 238280 |
09-Jul-2012 |
adrian |
Introduce the EDMA related HAL capabilities.
Whilst here, fix a typo in a previous commit.
Obtained from: 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.
|
| 238276 |
09-Jul-2012 |
adrian |
Extend the debugging flags to include some AR9300 HAL related options.
Obtained from: Qualcomm Atheros
|
| 238275 |
09-Jul-2012 |
adrian |
Extend the RX descriptor completion debugging to log the larger
AR93xx receive descriptors.
This isn't entirely complete - the AR93xx and later descriptors
don't have a link/buffer pointer; the descriptor contents just
start.
|
| 238271 |
09-Jul-2012 |
adrian |
Add a debug category for RX EDMA.
|
| 238055 |
03-Jul-2012 |
adrian |
Begin abstracting out the RX path in preparation for RX EDMA support.
The RX EDMA support requires a modified approach to the RX descriptor
handling.
Specifically:
* There's now two RX queues - high and low priority;
* The RX queues are implemented as FIFOs; they're now an array of pointers
to buffers;
* .. and the RX buffer and descriptor are in the same "buffer", rather than
being separate.
So to that end, this commit abstracts out most of the RX related functions
from the bulk of the driver. Notably, the RX DMA/buffer allocation isn't
updated, primarily because I haven't yet fleshed out what it should look
like.
Whilst I'm here, create a set of matching but mostly unimplemented EDMA
stubs.
Tested:
* AR9280, station mode
TODO:
* Thorough AP and other mode testing for non-EDMA chips;
* Figure out how to allocate RX buffers suitable for RX EDMA, including
correctly setting the mbuf length to compensate for the RX descriptor
and completion status area.
|
| 237957 |
02-Jul-2012 |
adrian |
.. And fix another typo. Grr.
|
| 237956 |
02-Jul-2012 |
adrian |
Fix another typo.
|
| 237955 |
02-Jul-2012 |
adrian |
Fix typo.
|
| 237953 |
02-Jul-2012 |
adrian |
Bring over some further HAL capabilities from the Atheros HAL, as well
as an EDMA check function.
For the AR9003 and later NICs, different TX/RX DMA and descriptor handling
code will be conditional on the EDMA check.
Obtained from: Qualcomm Atheros
|
| 237874 |
01-Jul-2012 |
adrian |
Add in some further changes from the AR9300 HAL:
* Add a new ANI variable, for AR9003 and later chips;
* The AR9003 and later series chips support two RX queues now, so start
down the road of supporting that;
* Add some new TX queue types - uAPSD is possible on earlier chips,
but PAPRD is relevant to AR9003 and later.
Obtained from: Qualcomm Atheros, Linux ath9k
|
| 237868 |
01-Jul-2012 |
adrian |
Migrate the MAC/BB hang structures out from ar5416_misc.h into the HAL.
The ar9300 HAL also uses these types, so it makes no sense to duplicate
them.
|
| 237866 |
01-Jul-2012 |
adrian |
Bring over capabilities for the AR9300 and later HAL.
|
| 237865 |
01-Jul-2012 |
adrian |
Add OS_MEMCMP().
|
| 237864 |
01-Jul-2012 |
adrian |
Fix the HAL debugging to only use one bit to mark a message as unmaskable.
Whilst I'm here, remove the duplication of the #define.
|
| 237626 |
27-Jun-2012 |
adrian |
Fix a subtle corner case surrounding the handling of OFDM restart along
with AMPDU aggregate delimiters.
If there's an OFDM restart during an aggregate, the hardware ACKs
the previous frame, but communicates the RXed frame to the hardware
as having had CRC delimiter error + OFDM_RESTART phy error.
The frame however didn't have a CRC error and since the hardware ACKed
the aggregate to the sender, it thinks the frame was received.
Since I have no idea how often this occurs in the real world, add a
debug statement so trigger whenever this occurs. I'd appreciate an
email if someone finds this particular situation is triggered.
|
| 237622 |
27-Jun-2012 |
adrian |
Bring over some new typedefs as part of the AR9300 HAL import.
|
| 237621 |
27-Jun-2012 |
adrian |
Remove duplicate entries.
|
| 237611 |
26-Jun-2012 |
adrian |
Bring over the initial 802.11n bluetooth coexistence support code.
The Linux ath9k btcoex code is based off of this code.
Note this doesn't actually implement functional btcoex; there's some
driver glue and a whole lot of verification that is required.
On the other hand, I do have the AR9285+BT and AR9287+BT NICs which
this code supports..
Obtained from: Qualcomm Atheros, Linux ath9k
|
| 237593 |
26-Jun-2012 |
adrian |
Make sure the BAR TX session pause is correctly unpaused when a node
is reassociating.
PR: kern/169432
|
| 237529 |
24-Jun-2012 |
adrian |
In a complete lack of foresight on my part, my previous commit broke
the assumption that ath_softc doesn't change size based on build time
configuration.
I picked up on this because suddenly radar stuff didn't work; and
although the ath_dfs code was setting sc_dodfs=1, the main ath driver
saw sc_dodfs=0.
So for now, include opt_ath.h in driver source files. This seems like
the sane thing to do anyway.
I'll have to do a pass over the code at some later stage and turn
the radiotap TX/RX structs into malloc'ed memory, rather than in-line
inside of ath_softc. I'd rather like to keep ath_softc the same
layout regardless of configuration parameters.
Pointy hat to: adrian
|
| 237527 |
24-Jun-2012 |
adrian |
Shuffle these initialisations to where they should be.
|
| 237526 |
24-Jun-2012 |
adrian |
Change the ath_dfs_process_phy_err() method to take an mbuf rather than
a buffer pointer.
For large radar pulses, the AR9130 and later will return a series of
FFT results for software processing. These can overflow a single 2KB
buffer on longer pulses. This would result in undefined buffer behaviour.
|
| 237522 |
24-Jun-2012 |
adrian |
Introduce an optional ath(4) radiotap vendor extension.
This includes a few new fields in each RXed frame:
* per chain RX RSSI (ctl and ext);
* current RX chainmask;
* EVM information;
* PHY error code;
* basic RX status bits (CRC error, PHY error, etc).
This is primarily to allow me to do some userland PHY error processing
for radar and spectral scan data. However since EVM and per-chain RSSI
is provided, others may find it useful for a variety of tasks.
The default is to not compile in the radiotap vendor extensions, primarily
because tcpdump doesn't seem to handle the particular vendor extension
layout I'm using, and I'd rather not break existing code out there that
may be (badly) parsing the radiotap data.
Instead, add the option 'ATH_ENABLE_RADIOTAP_VENDOR_EXT' to your kernel
configuration file to enable these options.
|
| 237521 |
24-Jun-2012 |
adrian |
On second thought, let's just set both CRC and PHY errors together on
frames that have it and let the upper layer sort it out.
PR: kern/169362
|
| 237519 |
24-Jun-2012 |
adrian |
Sometimes the AR5416 sends back radar PHY errors with both the PHY error
and the CRC error bits set. The radar payload is correct.
When this happens, the stack doesn't see them PHY error frames and
isn't interpreted as a PHY error. So, no radar detection and no radiotap
PHY error handling.
Now, this may introduce some weird issues if the MAC sends up some other
combination of CRC error + PHY error frames; this commit would break that
and mark them as PHY errors instead of CRC errors.
I may tinker with this a little more to pass radar/early radar/spectral
frames up as PHY errors if the CRC bit is set, to restore the previous
behaviour (where if CRC is set on a PHY error frame, it's marked as a CRC
error rather than PHY error.)
Tested on: AR5416, over the air, to a USRP N200 which is generating a
large number of a variety of radar pulses.
TODO: Test on AR9130, AR9160, AR9280 (and maybe radar pulses on
2GHz on AR9285/AR9287.)
PR: kern/169362
|
| 237184 |
17-Jun-2012 |
adrian |
AR9287 tidyups:
* Add an OS_A_REG_WRITE() routine - analog writes require a 100usec delay
on AR9280 and later, so create a method to do it.
* Use it for the AR9287 analog writes.
* Re-indent and style(9) the code.
|
| 237183 |
17-Jun-2012 |
adrian |
Add an disabled workaround for the AR9285SE.
This just requires a little HAL change (add a new config parameter) and
some glue in if_ath_pci.c, however I'm leaving this up for someone else
to do.
Obtained from: Qualcomm Atheros
|
| 237182 |
17-Jun-2012 |
adrian |
Bring over the AR9285 specific PCIe suspend/resume/ASPM workarounds.
Obtained from: Qualcomm Atheros, Linux ath9k
|
| 237179 |
17-Jun-2012 |
adrian |
After some discussion with bschmidt@, it's likely better to just go
through ieee80211_suspend_all() and ieee80211_resume_all().
All the other wireless drivers are doing that particular dance.
PR: kern/169084
|
| 237174 |
16-Jun-2012 |
adrian |
.. and this wasn't supposed to be in the previous commit either.
|
| 237173 |
16-Jun-2012 |
adrian |
oops, remove this, it wasn't supposed to be committed.
|
| 237171 |
16-Jun-2012 |
adrian |
A few nitpicks:
* Use ATH_RC_NUM instead of '4' when iterating over the ratecontrol series
array.
* A few style(9) fixes, hopefully no regressions here.
* Add some comments that better describe what's going on.
|
| 237170 |
16-Jun-2012 |
kib |
Fix build.
|
| 237153 |
16-Jun-2012 |
adrian |
Shuffle some more fields in ath_buf so it's not too big.
This shaves off 20 bytes - from 288 bytes to 268 bytes.
However, it's still too big.
|
| 237152 |
16-Jun-2012 |
adrian |
Shave four (or eight) bytes off of ath_buf - this field isn't used.
|
| 237108 |
15-Jun-2012 |
adrian |
Convert ath(4) to just use ieee80211_suspend_all() and ieee80211_resume_all().
The existing code tries to use the beacon miss timer to signal that the AP
has gone away. Unfortunately this doesn't seem to be behaving itself.
I'll try to investigate why this is for the sake of completeness.
The result is the STA will stay "associated" to the AP it was associated
with when it suspended. It never receives a bmiss notification so it
never tries reassociating.
PR: kern/169084
|
| 237046 |
14-Jun-2012 |
adrian |
Shrink ath_buf a little more:
* Resize some types. In particular, bfs_seqno can be uint16_t for now.
Previous work would assign the unassigned seqno a value of -1, which
I obviously can't do here.
* Remove bfs_pktdur. It was in the original code but nothing so far uses
it.
This gets ath_buf down (on my i386 system) to 292 bytes from 300 bytes.
I'd rather it be much, much smaller.
|
| 237043 |
14-Jun-2012 |
adrian |
Disable BGSCAN for 802.11n for now. Until scanning during traffic is
fixed for 802.11n TX, this needs to be disabled or users wlil see randomly
hanging aggregation sessions.
Whilst I'm here, remove the warning about 802.11n being full of dragons.
It's nowhere near that scary now.
|
| 237041 |
14-Jun-2012 |
adrian |
Disable this warning debug for now, as I'm now aware of the particular
situation where it's occuring.
Whilst I'm here, flesh out a more descriptive description.
|
| 237038 |
14-Jun-2012 |
adrian |
Implement a global (all non-mgmt traffic) TX ath_buf limitation when
ath_start() is called.
This (defaults to 10 frames) gives for a little headway in the TX ath_buf
allocation, so buffer cloning is still possible.
This requires a lot omre experimenting and tuning.
It also doesn't stop a node/TID from consuming all of the available
ath_buf's, especially when the node is going through high packet loss
or only talking at a low TX rate. It also doesn't stop a paused TID
from taking all of the ath_bufs. I'll look at fixing that up in subsequent
commits.
PR: kern/168170
|
| 237000 |
13-Jun-2012 |
adrian |
Implement a separate, smaller pool of ath_buf entries for use by management
traffic.
* Create sc_mgmt_txbuf and sc_mgmt_txdesc, initialise/free them appropriately.
* Create an enum to represent buffer types in the API.
* Extend ath_getbuf() and _ath_getbuf_locked() to take the above enum.
* Right now anything sent via ic_raw_xmit() allocates via ATH_BUFTYPE_MGMT.
This may not be very useful.
* Add ATH_BUF_MGMT flag (ath_buf.bf_flags) which indicates the current buffer
is a mgmt buffer and should go back onto the mgmt free list.
* Extend 'txagg' to include debugging output for both normal and mgmt txbufs.
* When checking/clearing ATH_BUF_BUSY, do it on both TX pools.
Tested:
* STA mode, with heavy UDP injection via iperf. This filled the TX queue
however BARs were still going out successfully.
TODO:
* Initialise the mgmt buffers with ATH_BUF_MGMT and then ensure the right
type is being allocated and freed on the appropriate list. That'd save
a write operation (to bf->bf_flags) on each buffer alloc/free.
* Test on AP mode, ensure that BAR TX and probe responses go out nicely
when the main TX queue is filled (eg with paused traffic to a TID,
awaiting a BAR to complete.)
PR: kern/168170
|
| 236995 |
13-Jun-2012 |
adrian |
Remove a duplicate definition.
|
| 236994 |
13-Jun-2012 |
adrian |
Oops, return the newly allocated buffer to the queue, not the completed
buffer.
PR: kern/168170
|
| 236993 |
13-Jun-2012 |
adrian |
Replace the direct sc_txbuf manipulation with a pair of functions.
This is preparation work for having a separate ath_buf queue for
management traffic.
PR: kern/168170
|
| 236886 |
11-Jun-2012 |
adrian |
Fix uninitialised reference.
Noticed by: John Hay <jhay@meraka.org.za>
|
| 236880 |
11-Jun-2012 |
adrian |
Wrap the whole (software) TX path from ifnet dequeue to software queue
(or direct dispatch) behind the TXQ lock (which, remember, is doubling
as the TID lock too for now.)
This ensures that:
(a) the sequence number and the CCMP PN allocation is done together;
(b) overlapping transmit paths don't interleave frames, so we don't
end up with the original issue that triggered kern/166190.
Ie, that we don't end up with seqno A, B in thread 1, C, D in
thread 2, and they being queued to the software queue as "A C D B"
or similar, leading to the BAW stalls.
This has been tested:
* both STA and AP modes with INVARIANTS and WITNESS;
* TCP and UDP TX;
* both STA->AP and AP->STA.
STA is a Routerstation Pro (single CPU MIPS) and the AP is a dual-core
Centrino.
PR: kern/166190
|
| 236879 |
11-Jun-2012 |
adrian |
Add another TID lock.
|
| 236878 |
11-Jun-2012 |
adrian |
Make sure the frames are queued to the head of the list, not the tail.
See previous commit.
PR: kern/166190
|
| 236877 |
11-Jun-2012 |
adrian |
When scheduling frames in an aggregate session, the frames should be
scheduled from the head of the software queue rather than trying to
queue the newly given frame.
This leads to some rather unfortunate out of order (but still valid
as it's inside the BAW) frame TX.
This now:
* Always queues the frame at the end of the software queue;
* Tries to direct dispatch the frame at the head of the software queue,
to try and fill up the hardware queue.
TODO:
* I should likely try to queue as many frames to the hardware as I can
at this point, rather than doing one at a time;
* ath_tx_xmit_aggr() may fail and this code assumes that it'll schedule
the TID. Otherwise TX may stall.
PR: kern/166190
|
| 236876 |
11-Jun-2012 |
adrian |
Retried frames need to be inserted in the head of the list, not the tail.
This is an unfortunate byproduct of how the routine is used - it's called
with the head frame on the queue, but if the frame is failed, it's inserted
into the tail of the queue.
Because of this, the sequence numbers would get all shuffled around and
the BAW would be bumped past this sequence number, that's now at the
end of the software queue. Then, whenever it's time for that frame
to be transmitted, it'll be immediately outside of the BAW and TX will
stall until the BAW catches up.
It can also result in all kinds of weird duplicate BAW frames, leading
to hilarious panics.
PR: kern/166190
|
| 236874 |
11-Jun-2012 |
adrian |
Finish undoing the previous commit - this part of the code is no longer
required.
PR: kern/166190
|
| 236873 |
11-Jun-2012 |
adrian |
Introduce a new lock debug which is specifically for making sure the
_TID_ lock is held.
For now the TID lock is also the TXQ lock. This is just to make sure
that the right TXQ lock is held for the given TID.
|
| 236872 |
11-Jun-2012 |
adrian |
Revert r233227 and followup commits as it breaks CCMP PN replay detection.
This showed up when doing heavy UDP throughput on SMP machines.
The problem with this is because the 802.11 sequence number is being
allocated separately to the CCMP PN replay number (which is assigned
during ieee80211_crypto_encap()).
Under significant throughput (200+ MBps) the TX path would be stressed
enough that frame TX/retry would force sequence number and PN allocation
to be out of order. So once the frames were reordered via 802.11 seqnos,
the CCMP PN would be far out of order, causing most frames to be discarded
by the receiver.
I've fixed this in some local work by being forced to:
(a) deal with the issues that lead to the parallel TX causing out of
order sequence numbers in the first place;
(b) fix all the packet queuing issues which lead to strange (but mostly
valid) TX.
I'll begin fixing these in a subsequent commit or five.
PR: kern/166190
|
| 236833 |
10-Jun-2012 |
adrian |
Add a new ioctl for ath(4) which returns the aggregate statistics.
|
| 236599 |
05-Jun-2012 |
adrian |
Mostly revert previous commit(s). After doing a bunch of local testing,
it turns out that it negatively affects performance. I'm stil investigating
exactly why deferring the IO causes such negative TCP performance but
doesn't affect UDP preformance.
Leave the ath_tx_kick() change in there however; it's going to be useful
to have that there for if_transmit() work.
PR: kern/168649
|
| 236597 |
05-Jun-2012 |
adrian |
Create a function - ath_tx_kick() - which is called where ath_start() is
called to "kick" along TX.
For now, schedule a taskqueue call.
Later on I may go back to the direct call of ath_rx_tasklet() - but for
now, this will do.
I've tested UDP and TCP TX. UDP TX still achieves 240MBit, but TCP
TX gets stuck at around 100MBit or so, instead of the 150MBit it should
be at. I'll re-test with no ACPI/power/sleep states enabled at startup
and see what effect it has.
This is in preparation for supporting an if_transmit() path, which will
turn ath_tx_kick() into a NUL operation (as there won't be an ifnet
queue to service.)
Tested:
* AR9280 STA
TODO:
* test on AR5416, AR9160, AR928x STA/AP modes
PR: kern/168649
|
| 236583 |
04-Jun-2012 |
adrian |
Migrate the TX path to a taskqueue for now, until a better way of
implementing parallel TX and TX/RX completion can be done without
simply abusing long-held locks.
Right now, multiple concurrent ath_start() entries can result in
frames being dequeued out of order. Well, they're dequeued in order
fine, but if there's any preemption or race between CPUs between:
* removing the frame from the ifnet, and
* calling and runningath_tx_start(), until the frame is placed on a
software or hardware TXQ
Then although dequeueing the frame is in-order, queueing it to the hardware
may be out of order.
This is solved in a lot of other drivers by just holding a TX lock over
a rather long period of time. This lets them continue to direct dispatch
without races between dequeue and hardware queue.
Note to observers: if_transmit() doesn't necessarily solve this.
It removes the ifnet from the main path, but the same issue exists if
there's some intermediary queue (eg a bufring, which as an aside also
may pull in ifnet when you're using ALTQ.)
So, until I can sit down and code up a much better way of doing parallel
TX, I'm going to leave the TX path using a deferred taskqueue task.
What I will likely head towards is doing a direct dispatch to hardware
or software via if_transmit(), but it'll require some driver changes to
allow queues to be made without using the really large ath_buf / ath_desc
entries.
TODO:
* Look at how feasible it'll be to just do direct dispatch to
ath_tx_start() from if_transmit(), avoiding doing _any_ intermediary
serialisation into a global queue. This may break ALTQ for example,
so I have to be delicate.
* It's quite likely that I should break up ath_tx_start() so it
deposits frames onto the software queues first, and then only fill
in the 802.11 fields when it's being queued to the hardware.
That will make the if_transmit() -> software queue path very
quick and lightweight.
* This has some very bad behaviour when using ACPI and Cx states.
I'll do some subsequent analysis using KTR and schedgraph and file
a follow-up PR or two.
PR: kern/168649
|
| 236039 |
26-May-2012 |
adrian |
Add the AR9280 workarounds for PCIe suspend/resume.
These aren't strictly needed at the moment as we're not doing APSM
and forcing the NIC in and out of network sleep. But, they don't hurt.
Tested:
* AR9280 (mini-PCIe)
Obtained from: Qualcomm Atheros, Linux ath9k
|
| 236038 |
26-May-2012 |
adrian |
Avoid using hard-coded numbers here.
|
| 236036 |
26-May-2012 |
adrian |
Remove an unneeded field from ath_buf.
|
| 236017 |
25-May-2012 |
adrian |
Add some AR5416/AR5418 WAR's for power-on and suspend/resume:
* Now that ah_configPCIE is called for both power on and suspend/resume,
make sure the right bit(s) are cleared and set when suspending and
resuming. Specifically:
+ force disable/enable the PCIe PHY upon suspend/resume;
+ reprogram the PCIe WAR register when resuming and upon power-on.
* Add a recipe which powers down any PCIe PHY hardware inside the AR5416
(which is the PCI variant) to save on power. I have (currently) no way
to test exactly how much power is saved, if any.
Tested on:
* AR5416 cardbus - although unfortunately pccard/cbb/cardbus currently
detaches the NIC upon suspend, I don't think it's a proper test case.
* AR5418 PCIe attached to expresscard - since we're not doing PCIe APSM,
it's also not likely a full/good test case.
In both instances I went through a handful of suspend/resume cycles and
ensured that the STA vap reassociated correctly.
TODO:
* Setup a laptop to simply sit in a suspend/resume loop, making sure that
the NIC always correctly comes back;
* Start doing suspend/resume tests with actual traffic going on in the
background, as I bet this process is all quite racy at the present;
* Test adhoc/hostap mode, just to be completely sure it's working correctly;
* See if I can jury rig an external power source to an AR5416 to test out
whether ah_disablePCIE() works.
Obtained from: Qualcomm Atheros
|
| 236009 |
25-May-2012 |
adrian |
* According to the reference code, AR_WA_D3_L1_DISBABLE is bit 14.
* Add some other WAR bits (very usefully described too) in preparation for
porting over some suspend/resume fixes from ath9k/Atheros.
Obtained from: Qualcomm Atheros
|
| 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.
|
| 235957 |
25-May-2012 |
adrian |
Prepare for improved (read: pcie) suspend/resume support.
* Flesh out the pcie disable method for 11n chips, as they were defaulting
to the AR5212 (empty) PCIe disable method.
* Add accessor macros for the HAL PCIe enable/disable calls.
* Call disable on ath_suspend()
* Call enable on ath_resume()
NOTE:
* This has nothing to do with the NIC sleep/run state - the NIC still
will stay in network-run state rather than supporting network-sleep
state. This is preparation work for supporting correct suspend/resume
WARs for the 11n PCIe NICs.
TODO:
* It may be feasible at this point to keep the chip powered down during
initial probe/attach and only power it up upon the first configure/reset
pass. This however would require correct (for values of "correct")
tracking of the NIC power configuration state from the driver and that
just isn't attempted at the moment.
Tested:
* AR9280 on my Lenovo T60, but with no suspend/resume pass (yet).
|
| 235804 |
22-May-2012 |
adrian |
Re-up the TX ath_buf limit from 128 to 512.
I'll have to leave this high for now, until I've done some significant
surgery with how ath_bufs (and descriptors) are handled.
This should significantly cut down on the opportunities for a full TX
queue hanging traffic. I'll continue making things work though; I'm
mostly doing this for users. :)
|
| 235774 |
22-May-2012 |
adrian |
Fix up some corner cases with aggregation handling.
I've come across a weird scenario in net80211 where two TX streams will
happily attempt to setup an aggregation session together.
If we're very lucky, it happens concurrently on separate CPUs and the
total lack of locking in the net80211 aggregation code causes this stuff
to race. Badly.
So >1 call would occur to the ath(4) addba start, but only one call would
complete to addba complete or timeout. The TID would thus stay paused.
The real fix is to implement some proper per-node (or maybe per-TID)
locking in net80211, which then could be leveraged by the ath(4) TX
aggregation code.
Whilst I'm at it, shuffle around the debugging messages a bit.
I like to keep people on their toes.
|
| 235750 |
21-May-2012 |
adrian |
For now, add a quick debugging patch to log when the hw TXQ != the TID/AC.
|
| 235749 |
21-May-2012 |
adrian |
Rename ath_tx_cleanup() -> ath_tx_tid_cleanup() in order to not clash
with a symbol in if_ath.c
|
| 235728 |
21-May-2012 |
adrian |
Re-add 'ic' and properly wrap it in the SUPERG macro.
|
| 235685 |
20-May-2012 |
bschmidt |
Remove unused variable.
|
| 235682 |
20-May-2012 |
adrian |
Migrate the per-frame code out from ath_rx_proc() to ath_rx_pkt().
This will (eventually) be used by the EDMA RX path used by the
AR93xx and later NICs.
|
| 235680 |
20-May-2012 |
adrian |
Migrate most of the beacon handling functions out to if_ath_beacon.c.
This is also in preparation for supporting AR9300 and later NICs.
|
| 235679 |
20-May-2012 |
adrian |
Migrate the TDMA management functions out of if_ath.c into if_ath_tdma.c.
There's some TX path TDMA code in if_ath_tx.c which should be migrated
out, but first I should likely try and verify/fix/repair the TDMA support
in 9.x and -HEAD.
|
| 235676 |
20-May-2012 |
adrian |
Migrate the bulk of the RX routines out from if_ath.c to if_ath_rx.[ch].
* migrate the rx processing out into if_ath_rx.c
* migrate the TSF functions into if_ath_tsf.h, as inlines
This is in prepration for supporting the EDMA RX routines, required to
support the AR93xx series NICs.
TODO:
* ath_start() shouldn't be private, but it's called as part of
the RX path. I should likely migrate ath_rx_tasklet() back into
if_ath.c and then return this to be 'static'. The RX code really
shouldn't need to see TX routines (and vice versa.)
* ath_beacon_* should be in if_ath_beacon.[ch].
* ath_tdma_* should be in if_ath_tdma.[ch] ...
|
| 235491 |
15-May-2012 |
adrian |
Migrate ath_debug and sc_debug from an int to a uint64_t / QUAD;
add some more BAR debugging logic.
* Change the definition of ath_debug and ath_softc.sc_debug from
int to uint64_t;
* Change the relevant sysctls;
* Add a new BAR TX debugging field;
* Use this in if_ath_tx.
This has been tested by using the sysctl program, which happily allows
for fields > 32 bits to be configured.
|
| 235461 |
15-May-2012 |
adrian |
Handle non-xretry errors the same as xretry errors for now.
Although I _should_ handle the other errors in various ways (specifically
errors like FILT), treating them as having transmitted successfully
is completely wrong. Here, they'd be counted as successful and the BAW
would be advanced.. but the RX side wouldn't have received them.
The specific errors I've been seeing here are HAL_TXERR_FILT.
This patch does fix the issue - I've tested it using -i 0.001 pings
(enough to start aggregation) and now the behaviour is correct:
* The RX side never sees a "moved window" error, and
* The TX side sends BARs as needed, with the RX side correctly handling
them.
PR: kern/167902
|
| 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..
|
| 235134 |
07-May-2012 |
adrian |
Re-enable this particular DELAY() for now, at least until the
TX and RX PCU stop/drain routines have been thoroughly debugged.
It's also very likely that I should add hooks back up to the
interface glue (if_ath_pci / if_ath_ahb) to do any relevant
bus flushes that are required. A WMAC DDR flush may be required
for the AR9130 SoC.
|
| 235034 |
04-May-2012 |
adrian |
Fix a couple of sc_ac2q[] mappings that were using the TID, not the AC.
PR: kern/167588
|
| 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.
|
| 234774 |
28-Apr-2012 |
adrian |
After thinking about this a bit more, let's not keep statistics per-channel
in the HAL. That's very memory hungry (32k just for channel statistics)
which would be better served by keeping a summary in the ANI state.
Or, later, keep a survey history in net80211.
So:
* Migrate the ah_chansurvey array to be a single entry, for the current
channel.
* Change the ioctl interface and ANI code to just reference that.
* Clear the ah_chansurvey array during channel reset, both in the AR5212
and AR5416 reset path.
|
| 234768 |
28-Apr-2012 |
adrian |
Although not strictly needed, quieten a compiler warning by a user.
|
| 234752 |
28-Apr-2012 |
adrian |
Extend the ANI code to implement basic channel survey support.
* Always call ar5416GetListenTime()
* Modify ar5416GetListenTime() to:
+ don't update the ANI state if there isn't any ANI state;
+ don't update the channel survey state if there's no active
channel - just to be paranoid
+ copy the channel survey results into the current sample slot
based on the current channel; then increment the sample counter
and sample history counter.
* Modify ar5416GetMIBCyclesPct() to simply return a HAL_SURVEY_SAMPLE,
rather than a set of percentages. The ANI code wasn't using the
percentages anyway.
TODO:
* Create a new function which fetches the survey results periodically
* .. then modify the ANI code to use the pre-fetched values rather than
fetching them again
* Roll the 11n ext busy function from ar5416_misc.c to update all the
counters, then do the result calculation
* .. then, modify the MIB counter routine to correctly fetch a snapshot -
freeze the counters, fetch the values, then reset the counters.
|
| 234750 |
28-Apr-2012 |
adrian |
Fetch the channel survey code from the HAL.
This information is currently not being populated by any of the HAL
modules.
|
| 234749 |
28-Apr-2012 |
adrian |
Extend the HAL channel survey statistics:
* include ext_chan_busy;
* include ofdm/cck phy error counts, which aren't yet implemented.
|
| 234748 |
28-Apr-2012 |
adrian |
Add a comment about this DELAY(), I'm not sure whether it's supposed
to be for a DDR/FIFO flush or something else.
|
| 234747 |
28-Apr-2012 |
adrian |
Add an AR5416 PCU DMA stop method, as a check for the AR9130 is needed.
The reference driver has a 3ms delay for the AR9130 but I'm not as yet
sure why. From what I can gather, it's likely waiting for some FIFO
flush to occur.
At some point in the future it may be worthwhile adding a WMAC
FIFO flush here, but that'd require some side-call through to the SoC
DDR flush routines.
Obtained from: Atheros
|
| 234725 |
27-Apr-2012 |
adrian |
Remove some of the redundant locking done in the TX completion path,
when checking whether BAR frames need to be checked.
|
| 234692 |
26-Apr-2012 |
adrian |
Add the BT register definitions for AR9285/AR9287 BT coexistence.
Obtained from: Linux ath9k
|
| 234664 |
25-Apr-2012 |
adrian |
Add placeholder methods for WMI command access (USB, perhaps SDIO later)
which will be needed for AR7010 and AR9287 USB access.
The names differ slightly from Linux and Atheros, for the sake of
consistency.
A lot more work is required in order to convert the 11n HAL support to
fully support USB.
|
| 234663 |
25-Apr-2012 |
adrian |
Add a note that explains what the current state of the register byte order
macros are.
|
| 234510 |
20-Apr-2012 |
adrian |
.. oops.
|
| 234508 |
20-Apr-2012 |
adrian |
"Upgrade" the AR9285 code to support PCI/ART EEPROM on flash.
I've just verified that this boots on an Atheros AP91. I haven't verified
it with traffic though, so YMMV.
|
| 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.
|
| 234369 |
17-Apr-2012 |
adrian |
Run the fatal proc as a proc, rather than where it currently is.
Otherwise the reset path will sleep, which it can't do in this context.
|
| 234324 |
15-Apr-2012 |
adrian |
Migrate the net80211 TX aggregation state to be from per-AC to per-TID.
TODO:
* Test mwl(4) more thoroughly!
Reviewed by: bschmidt (for iwn)
|
| 234323 |
15-Apr-2012 |
adrian |
Drop this down from 512 to 128 for now.
This may result in a bit of a throughput drop. However, any throughput
drop at this point should be investigated and root caused, as it's likely
because TX scheduling (all the way down to how preemption, scheduler work,
etc) is happening in a sub-optimal fashion.
This also makes it much more likely to be reloadable on a live machine.
Allocating 5120 TX ath_buf entries via contigmalloc is very unlikely
after a few hours of using X/Chromium.
|
| 234304 |
15-Apr-2012 |
adrian |
Override some default values to work around various issues in the deep,
dirty and murky past.
* Override the default cache line size to be something reasonable if
it's set to 0. Some NICs initialise with '0' (eg embedded ones)
and there are comments in the driver stating that various OSes (eg
older Linux ones) would incorrectly program things and 0 out this
register.
* Just default to overriding the latency timer. Every other driver
does this.
* Use a default cache line size of 32 bytes. It should be "reasonable
enough".
Obtained from: Linux ath9k, Atheros
|
| 234269 |
14-Apr-2012 |
adrian |
Both linux ath9k and the reference driver initialises the PLL here
during chip wakeup.
Obtained from: Linux ath9k, Atheros
|
| 234231 |
13-Apr-2012 |
adrian |
Upgrade ATH_EEPROM_FIRMWARE to a configuration option.
|
| 234218 |
13-Apr-2012 |
adrian |
Introduce the ability to grab local EEPROM data from the firmware(9)
interface.
* Introduce a device hint, 'eeprom_firmware', which is the name of firmware
to lookup.
* If the lookup succeeds, take a copy of it and use it as the eeprom data.
This isn't enabled by default - you have to define ATH_EEPROM_FIRMWARE.
I'll add it to the configuration variables in a later commit.
TODO:
* just keep a firmware reference in ath_softc, and remove the need to
waste the extra memory in having sc_eepromdata be a malloc()ed block.
|
| 234117 |
11-Apr-2012 |
adrian |
Fix the default, non-superg compile.
Pointy-hat-to: adrian
|
| 234110 |
10-Apr-2012 |
adrian |
Fix compilation with IEEE80211_ENABLE_SUPERG defined.
PR: kern/164951
|
| 234109 |
10-Apr-2012 |
adrian |
Convert the flags over to a set of bit flags.
|
| 234091 |
10-Apr-2012 |
adrian |
Blank the aggregate stats whenever the zero ioctl is called.
|
| 234090 |
10-Apr-2012 |
adrian |
Squirrel away SYNC interrupt debugging if it's enabled in the HAL.
Bus errors will show up as various SYNC interrupts which will be passed
back up to ath_intr().
|
| 234089 |
10-Apr-2012 |
adrian |
Revert this for now - it may work for -8 and -9 and -HEAD, but not
"-HEAD driver + net80211 on -9 kernel."
I'll figure this out at some later stage.
|
| 234088 |
10-Apr-2012 |
adrian |
Squirrel away the SYNC interrupt in case we're doing interrupt debugging.
|
| 234085 |
10-Apr-2012 |
adrian |
* Since the API changed along the -CURRENT path (december 2011),
add a FreeBSD_version check. It should work fine for compiling
on -HEAD, 9.x and 8.x.
* Conditionally compile the 11n options only when 11n is enabled.
The above changes allow the ath(4) driver to compile and run on
8.1-RELEASE (Hi old PC-BSD!) but with the 11n stuff disabled.
I've done a test against the net80211 and tools in 8.1-RELEASE.
The NIC used in testing is the AR2427 in an EEEPC.
Just to be clear - this change is to allow the -HEAD ath/hal/rate
code to run on 9.x _and_ 8.x with no source changes. However,
when running on earlier kernels, it should only be used for legacy
mode. (Don't define ATH_ENABLE_11N.)
|
| 234009 |
08-Apr-2012 |
adrian |
After reviewing the mcast/sleep station code a little, undo some brain
damage which I committed when I had less clue about such things.
Don't ever put normal data frames on the mcast software queue.
Just put mcast frames there if needed.
Pass the txq decision into ath_tx_normal_setup(), as we've already made
the decision. Don't re-do it.
Whilst i'm here, add another random debugging statement.
|
| 233990 |
07-Apr-2012 |
adrian |
Do a dma sync before the descriptors are chained together.
I need to find a better place to do this..
|
| 233989 |
07-Apr-2012 |
adrian |
Break out the legacy duration and protection code into routines,
call these after rate control selection is done.
The duration/protection code wasn't working - it expected the rix to
be valid. Unfortunately after I moved the rate control selection into
late in the process, the rix value isn't valid and thus the protection/
duration code would get things wrong.
HT frames are now correctly protected with an RTS and for the AR5416,
this involves having the aggregate frames be limited to 8K.
TODO:
* Fix up the DMA sync to occur just before the frame is queued to the
hardware. I'm adjusting the duration here but not doing the DMA
flush.
* Doubly/triply ensure that the aggregate frames are being limited to
the correct size, or the AR5416 will get unhappy when TXing RTS-protected
aggregates.
|
| 233988 |
07-Apr-2012 |
adrian |
As I thought, this is a bad idea. When forming aggregates, the RTS/CTS
stuff and rate control lookup is only done on the first frame.
|
| 233970 |
07-Apr-2012 |
adrian |
Enforce the RTS aggregation limit if RTS/CTS protection is enabled;
if any subframes in an aggregate have different protection from the
first frame in the formed aggregate, don't add that frame to the
aggregate.
This is likely a suboptimal method (I think we'll mostly be OK marking
frames that have seqno's with the same protection as normal data frames)
but I'll just be cautious for now.
|
| 233967 |
07-Apr-2012 |
adrian |
Store away the RTS aggregate limit from the HAL.
This will be used by some upcoming code to ensure that aggregates
are enforced to be a certain size. The AR5416 has a limitation on
RTS protected aggregates (8KiB).
|
| 233966 |
07-Apr-2012 |
adrian |
Remove duplicate txflags field from ath_buf.
rename bf_state.bfs_flags to bf_state.bfs_txflags, as that is what
it effectively is.
|
| 233908 |
04-Apr-2012 |
adrian |
Implement BAR TX.
A BAR frame must be transmitted when an frame in an A-MPDU session fails
to transmit - it's retried too often, or it can't be cloned for
re-transmission. The BAR frame tells the remote side to advance the
left edge of the block-ack window (BAW) to a new value.
In order to do this:
* TX for that particular node/TID must be paused;
* The existing frames in the hardware queue needs to be completed, whether
they're TXed successfully or otherwise;
* The new left edge of the BAW is then communicated to the remote side
via a BAR frame;
* Once the BAR frame has been sucessfully TXed, aggregation can resume;
* If the BAR frame can't be successfully TXed, the aggregation session
is torn down.
This is a first pass that implements the above. What needs to be done/
tested:
* What happens during say, a channel reset / stuck beacon _and_ BAR
TX. It _should_ be correctly buffered and retried once the
reset has completed. But if a bgscan occurs (and they shouldn't,
grr) the BAR frame will be forcibly failed and the aggregation session
will be torn down.
Yes, another reason to disable bgscan until I've figured this out.
* There's way too much locking going on here. I'm going to do a couple
of further passes of sanitising and refactoring so the (re) locking
isn't so heavy. Right now I'm going for correctness, not speed.
* The BAR TX can fail if the hardware TX queue is full. Since there's
no "free" space kept for management frames, a full TX queue (from eg
an iperf test) can race with your ability to allocate ath_buf/mbufs
and cause issues. I'll knock this on the head with a subsequent
commit.
* I need to do some _much_ more thorough testing in hostap mode to ensure
that many concurrent traffic streams to different end nodes are correctly
handled. I'll find and squish whichever bugs show up here.
But, this is an important step to being able to flip on 802.11n by default.
The last issue (besides bug fixes, of course) is HT frame protection and
I'll address that in a subsequent commit.
|
| 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.)
|
| 233898 |
04-Apr-2012 |
adrian |
Disable the HWQ contents upon a TX queue reset, rather than a TX queue flush.
This is designed to assist in figuring out what the hardware state is
when something like a queue hang has occured.
|
| 233897 |
04-Apr-2012 |
adrian |
Now that I've fixed the BAW TX hangs, disable this verbose debugging
again.
|
| 233895 |
04-Apr-2012 |
adrian |
Correctly handle AR_MoreAggr when assembling multi-descriptor final frames.
Linux ath9k doesn't have this issue as it doesn't try queuing multi-
descriptor frames to the hardware.
Before, I was only setting the first and last descriptor in the final
frame correctly - and that was done by accident. The first descriptor in
the last sub-frame was being correctly updated by ath_tx_setds_11n();
the last descriptor in the last sub-frame was being correctly updated
by ath_buf_set_rate(). But both of those are "incorrect".
The correct behaviour is:
* AR_IsAggr is set for all descriptors for all subframes in an aggregate.
* AR_MoreAggr is set for all descriptors for all non-final sub-frames
in an aggregate.
Ie, all descriptors in the last sub-frame of an aggregate must have this
field set to 0.
I still need to do a couple of extra passes to ensure the pad delimiter
field is being correctly handled in all descriptors in the last sub-frame.
|
| 233887 |
04-Apr-2012 |
adrian |
Add a threadid to the ah_decode API.
This adds the current thread ID to each logged register and mark entry,
allowing for easier debugging of concurrent/overlapping NIC operations.
|
| 233885 |
04-Apr-2012 |
adrian |
Disable a specific Merlin hardware workaround which may cause hangs on some
PCIe controllers.
Obtained from: Atheros / Linux
|
| 233682 |
29-Mar-2012 |
adrian |
oops, add a missing lock.
|
| 233673 |
29-Mar-2012 |
adrian |
Defer the rescheduling of TID -> TXQ frames in some instances.
Right now ath_txq_sched() is mainly called from the TX ath_tx_processq()
routine, which is (mostly) done as part of the taskqueue. It shouldn't
be called outside the taskqueue.
But now that I'm about to flip back on BAR TX, I'm going to start
stressing the ath_tx_tid_pause() and ath_tx_tid_resume() paths.
What I don't want to have happen is a reschedule of the TID traffic
_during_ the completion of TX frames.
Ideally I'd like to have a way to flag back up to the processing code
that the current hardware queue should be rechecked for software TID
queue frames. But for now, this should suffice for the BAR TX case.
I may eventually delete this code once I've brought some further
sanity to the general TX queue/completion path.
|
| 233514 |
26-Mar-2012 |
adrian |
Use the assigned sequence number when checking if a retried packet is
within the BAW.
This regression was introduced in ane earlier commit by me to fix the
BAW seqno allocation-but-not-insertion-into-BAW race. Since it was only
ever using the to-be allocated sequence number, any frame retries
with the first frame in the BAW still in the software queue would
have constantly failed, as ni_txseqs[tid] would always be outside
the BAW.
TODO:
* Extract out the mostly common code here in the agg and non-agg ADDBA
case and stuff it into a single function.
PR: kern/166357
|
| 233480 |
25-Mar-2012 |
adrian |
Add some more debugging to try and nail down exactly what's going on when
I see traffic stalls.
It turns out that the bug isn't because the first and last frame in the
BAW is in the software queue. It is more likely that it's because
the first frame in the BAW is still in the software queue and thus there's
no more room to allocate and do subsequent TX.
PR: kern/166357
|
| 233453 |
25-Mar-2012 |
adrian |
Add the new channel width change field to the ath(4) driver.
This is not entirely correct as it simply resets the channel, flushing
whatever is in the TX/RX queue. This can and will break aggregation
BAW tracking. But the alternative (HT40 frames being sent with the hardware
in HT20 mode) is even worse.
There's still a small window between the htinfo being received (and the ni_chw
field being updated) which could cause problems. I'll look at fleshing this
out in follow-up commits.
PR: kern/166286
|
| 233330 |
22-Mar-2012 |
adrian |
Add some further debugging to try and aid tracking down what the state of
things were just before a full software queue is drained.
|
| 233329 |
22-Mar-2012 |
adrian |
Sprinkle some style(9) things around.
|
| 233227 |
20-Mar-2012 |
adrian |
Delay sequence number allocation for A-MPDU until just before the frame
is queued to the hardware.
Because multiple concurrent paths can execute ath_start(), multiple
concurrent paths can push frames into the software/hardware TX queue
and since preemption/interrupting can occur, there's the possibility
that a gap in time will occur between allocating the sequence number
and queuing it to the hardware.
Because of this, it's possible that a thread will have allocated a
sequence number and then be preempted by another thread doing the same.
If the second thread sneaks the frame into the BAW, the (earlier) sequence
number of the first frame will be now outside the BAW and will result
in the frame being constantly re-added to the tail of the queue.
There it will live until the sequence numbers cycle around again.
This also creates a hole in the RX BAW tracking which can also cause
issues.
This patch delays the sequence number allocation to occur only just before
the frame is going to be added to the BAW. I've been wanting to do this
anyway as part of a general code tidyup but I've not gotten around to it.
This fixes the PR.
However, it still makes it quite difficult to try and ensure in-order
queuing and dequeuing of frames. Since multiple copies of ath_start()
can be run at the same time (eg one TXing process thread, one TX completion
task/one RX task) the driver may end up having frames dequeued and pushed
into the hardware slightly/occasionally out of order.
And, to make matters more annoying, net80211 may have the same behaviour -
in the non-aggregation case, the TX code allocates sequence numbers
before it's thrown to the driver. I'll open another PR to investigate
this and potentially introduce some kind of final-pass TX serialisation
before frames are thrown to the hardware. It's also very likely worthwhile
adding some debugging code into ath(4) and net80211 to catch when/if this
does occur.
PR: kern/166190
|
| 233053 |
16-Mar-2012 |
adrian |
Fix a couple of debugging outputs.
* printf -> device_printf
* print the buffer pointer and sequence number for any buffer that wasn't
correctly tidied up before it was freed. This is to aid in some
current SMP TX debugging stalls.
PR: kern/166190
|
| 233051 |
16-Mar-2012 |
adrian |
Add a dependency on ALQ if IEEE80211_ALQ and/or AH_DEBUG_ALQ is included.
|
| 232795 |
10-Mar-2012 |
adrian |
Stick the if_drv_flags access (check and modify) behind the ifq lock.
Although access to the flags to check/set OACTIVE is racy due to how
the default if_start() function works, this should remove any races
with read/modify/write between threads.
|
| 232794 |
10-Mar-2012 |
adrian |
Fix a panic introduced in a previous commit - non-beaconing modes (eg STA)
don't setup the avp mcast queue.
This is a bit annoying though - it turns out the mcast queue isn't
initialised for STA mode but it's then touched to see whether anything
is in it. That should be fixed in a subsequent commit.
Noticed by: gperez@entel.upc.edu
PR: kern/165895
|
| 232764 |
10-Mar-2012 |
adrian |
Don't flood the cabq/mcastq with frames.
In a very noisy 2.4GHz environment (with HT/40 enabled, making it worse)
I saw the following occur:
* the air was considered "busy" a lot of the time;
* the cabq time is quite short due to staggered beacons being enabled;
* it just wasn't able to keep up TX'ing CABQ frames;
* .. and the cabq would swallow up all the TX ath_buf's.
This patch introduces a twiddle which allows the maximum cabq depth to be
set, forcing further frames to be dropped.
It defaults to the TX buffer count at the moment, so the default behaviour
isn't changed.
I've also started fleshing out a similar setup for the data path, so
it doesn't swallow up all the available TX buffers and preventing management
frames (such as ADDBA) out.
PR: kern/165895
|
| 232753 |
09-Mar-2012 |
adrian |
Document that we may end up with some suboptimal handling of data
frames with stations in power saving mode.
I'm not (yet) sure how to handle TX'ing aggregates frames to stations
that are in power saving mode, or whether that's even a feasible thing
to do. So in order to (mostly) not forget, leave a couple of comments
in the code.
The code presently assumes that the aggregation TID state for an ath_node
is locked not by the ath_node lock or a node+TID lock, but behind the
hardware queue said TID maps to. This assumption is going to be
incorrect for stations in power saving mode as we'll be TX'ing frames
on the multicast queue.
In any case, I'm afraid its a "later problem". :/
|
| 232752 |
09-Mar-2012 |
adrian |
Should the mcast queue be locked here? In case more multicast traffic
comes along?
This commit was brought to you via an Atheros AR5210, associated to an 3x3
HT40 11na access point. Yes, this driver still works with it.
|
| 232719 |
09-Mar-2012 |
adrian |
Insert extra paranoia into the ath(4) driver.
This function must be called with both the source and destination TXQs
locked or things will get hairy.
I added this as part of some debugging in a PR but it turned out to not
be the cause. I still think it's -correct- so, here it is.
|
| 232707 |
09-Mar-2012 |
adrian |
Correctly initialise the TXQ link pointer to the last descriptor in
the last buffer in the list.
The current behaviour (due to me, so pointy hat is firmly on my head here)
was incorrect - it was setting the link pointer to the last descriptor
of the _first_ buffer in the TXQ. Instead, it should have set it to the
last descriptor in the _last_ buffer in the TXQ.
This showed up as occasional TX stalls with frames in the TXQ but no
TX progress being made. Further inspection showed the TXQ looked like
it contained multiple "lists" of frames - there'd be a list of correct
frames, then a NULL link pointer, but there'd be a next buffer in the
list.
Since this code is only called upon an interface reset, it's likely
this only began showing up when I started doing stress testing
in environments which annoy the radios enough to cause lockups.
I've not yet any TX stalls with this patch applied.
PR: kern/165866
|
| 232375 |
02-Mar-2012 |
adrian |
Wrap another ATH_LOCK around the scanning flag.
PR: kern/163318
|
| 232374 |
02-Mar-2012 |
adrian |
Wrap the scan code state change stuff behind ATH_LOCK and the PCU fiddling
behind the PCU lock.
sc_scanning is being checked without ATH_LOCK behind held and could
in theory run from multiple threads.
|
| 232250 |
28-Feb-2012 |
gavin |
Correct capitalization of "Hz" in user-visible text (manpages, printf(),
etc).
MFC after: 3 days
|
| 232170 |
26-Feb-2012 |
adrian |
Add in some debugging code to check whether the current rate table has
been bait-and-switched from the rate control code.
This will avoid the panic that I saw and will avoid sending invalid rates
(eg 11a/11g OFDM rates when in 11b, on 11b-only NICs (AR5211)) where the
rate table is not "big".
It also will point out situations where this occurs for the 11n NICs
which will have sufficiently large rate tables that "invalid rix" doesn't
occur.
I'll try to follow this up with a commit that adds a current operating mode
check. The "rix" is only relevant to the current operating mode and rate
table.
PR: kern/165475
|
| 232163 |
25-Feb-2012 |
adrian |
Attempt to further fix some of the concurrency/reset issues that occur.
* ath_reset() is being called in softclock context, which may have the
thing sleep on a lock. To avoid this, since we really _shouldn't_
be sleeping on any locks, break out the no-loss reset path into a tasklet
and call that from:
+ ath_calibrate()
+ ath_watchdog()
This has the added advantage that it'll end up also doing the frame
RX cleanup from within the taskqueue context, rather than the softclock
context.
* Shuffle around the taskqueue_block() call to be before we grab the lock
and disable interrupts.
The trouble here is that taskqueue_block() doesn't block currently
queued (but not yet running) tasks so calling it doesn't guarantee
no further tasks (that weren't running on _A_ CPU at the time of this
call) will complete. Calling taskqueue_drain() on these tasks won't
work because if any _other_ thread calls taskqueue_enqueue() for whatever
reason, everything gets very angry and stops working.
This slightly changes the race condition enough to let ath_rx_tasklet()
run before we try disabling it, and thus quietens the warnings a bit.
The (more) true solution will be doing something like the following:
* having a taskqueue_blocked mask in ath_softc;
* having an interrupt_blocked mask in ath_softc;
* only calling taskqueue_drain() on each individual task _after_ the
lock has been acquired - that way no further tasklet scheduling
is going to occur.
* Then once the tasks have been blocked _and_ the interrupt has been
disabled, call taskqueue_drain() on each, ensuring that anything
that _was_ scheduled or running is removed.
The trouble is if something calls taskqueue_enqueue() on a task
after taskqueue_blocked() has been called but BEFORE taskqueue_drain()
has been called, ta_pending will be set to 1 and taskqueue_drain()
will sit there stuck in msleep() until you hard-kill the machine.
PR: kern/165382
PR: kern/165220
|
| 232041 |
23-Feb-2012 |
adrian |
Use the passed-in channel rather than ic->ic_curchan.
I'm not sure _why_ the ic is NULL here, but I've seen it occasionally do
this after I've been tinkering with things for a while. It ends up
crashing in a call to ath_chan_set() via the net80211 scan code and scan
task.
|
| 231927 |
20-Feb-2012 |
adrian |
Break out the radar code into a separate source file.
This mirrors the internal HAL organisation and reduces the differences
between the HAL codebases slightly.
Obtained from: Atheros
|
| 231893 |
18-Feb-2012 |
adrian |
Try to ensure that ieee80211_newstate() and the vap_newstate methods
hold the lock.
This is part of my series of work to try and capture when net80211
locking isn't.
ObNote: it'd be nice to be able to mark a lock as "assert if the lock
is dropped", so I could capture functions which decide that dropping
and reacquiring the lock is a good idea (without re-checking the
sanity of the state protected by the lock.)
|
| 231864 |
17-Feb-2012 |
adrian |
Fix the return type.
Submitted by: arundel
Found by: clang/llvm
|
| 231857 |
17-Feb-2012 |
adrian |
Enforce some consistent ordering and handling of interrupt disable/enable
with RX/TX halting.
* Always disable/enable interrupts during a channel change, just to simply
things.
* Ensure that the ath taskqueue has completed and is paused before
continuing.
This dramatically reduces the instances of overlapping RX and reset
conditions.
PR: kern/165220
|
| 231854 |
17-Feb-2012 |
adrian |
Begin breaking out the txrx stop code into a locked and unlocked variant.
PR: kern/165220
|
| 231709 |
14-Feb-2012 |
adrian |
Fix the usefir128 config bit flipping.
|
| 231708 |
14-Feb-2012 |
adrian |
Improve the radar register config API.
* Fix the "enabled" flag to actually reflect whether radar detection is
enabled or not.
* Add flags for the relstep/relpwr checks.
|
| 231571 |
13-Feb-2012 |
adrian |
Attempt to address some potential vap->iv_bss race conditions.
There are unfortunately a number of situations where vap->iv_bss is changed
or freed by some code in net80211. Because multiple threads can concurrently
be doing work (and the vap->iv_bss access isn't at all done behind any kind
of lock), it's quite possible that:
* a change will occur in one thread - eg, by a call through
ieee80211_sta_join1();
* a state change occurs in another thread - eg an RX is scheduled
in the ath tasklet and it calls ieee80211_input_mimo_all(), which
does dereference vap->iv_bss;
* these two executing concurrently, causing things to explode.
Another instance is ath_beacon_alloc() which takes an ieee80211_node *.
It's called with the vap->iv_bss node from ath_newstate(). If the node has
changed in the meantime (say it's been freed elsewhere) the reference
that it grabbed _before_ refcounting it may be stale.
I would _prefer_ that these sorts of things were serialised somewhere but
that may be a bit much to ask. Instead, the best we can (currently) hope
is that the underlying bss node is still (somewhat) valid.
There is a related PR (kern/164382) described by the first case above.
That should be fixed by properly serialising the RX path and reset path
so an RX can't occur at the same time as the vap free/shutdown path.
This is inspired by some related fixes in r212127.
PR: kern/165060
|
| 231371 |
10-Feb-2012 |
adrian |
Enforce the hardware chainmask when allowing the user to override the
chainmask.
This way a disabled radio chain can't be enabled by a user.
|
| 231370 |
10-Feb-2012 |
adrian |
.. oops, use the right chainmask.
|
| 231369 |
10-Feb-2012 |
adrian |
Add in a new driver feature to allow the TX and RX chainmask to be
overridden at attach time.
Some 802.11n NICs may only have one physical antenna connected.
The radios will be very upset if you try enabling radios which aren't
connected to antennas.
This allows hints to override the TX and RX chainmask.
These hints are:
hint.ath.X.rx_chainmask
hint.ath.X.tx_chainmask
They can be set at either boot time or in kenv before the module is loaded.
This and the previous HAL commit were sponsored in late 2011 by Hobnob, Inc.
Sponsored by: Hobnob, Inc.
|
| 231368 |
10-Feb-2012 |
adrian |
Extend the HAL code to allow the RX and TX chainmask to be overridden
by capabilities.
Add an ar5416SetCapability() function, which contains logic to override
the chainmask and update the relevant stream.
This is designed to be called after the attach function, which presets
the TX/RX chainmask and stream.
TODO: check the chainmask against the hardware chainmask so non-existing
chains aren't enabled.
|
| 231099 |
06-Feb-2012 |
adrian |
Contribute some example code which demonstrates how to initialise the
radar parameters for the AR5416 and later NICs.
These parameters have been tested on the following NICs:
* AR5416
* AR9160
* AR9220
* AR9280
And yes, these will return radar pulse parameters and (for AR9160 and later)
radar FFT information as PHY errors.
This is again not enough to do radar detection, it's just here to faciliate
development and validation of radar detection algorithms.
The (pulse, not FFT) decoding code for AR5212, AR5416 and later NICs exist
in the HAL.
This code is disabled for now as generating radar PHY errors can quickly
cause issues in busy environment.s Some further debugging of the RX path
is needed.
Finally, these parameters are likely not useful for the AR5212 era NICs.
The madwifi-dfs branch should have suitable example parameters for the
11a era NICs.
|
| 230847 |
31-Jan-2012 |
adrian |
Support AR9281/AR5B91 - a 1x2 stream device based on the AR9280.
* Override the TX/RX stream count if the EEPROM reports a single RX or
TX stream, rather than assuming the device will always be a 2x2 strea
device.
* For AR9280 devices, don't hard-code 2x2 stream. Instead, allow the
ar5416FillCapabilityInfo() routine to correctly determine things.
The latter should be done for all 11n chips now that
ar5416FillCapabilityInfo() will set the TX/RX stream count based on the
active TX/RX chainmask in the EEPROM.
Thanks to Maciej Milewski for donating some AR9281 NICs to me for
testing.
|
| 230846 |
31-Jan-2012 |
adrian |
Correctly fetch the TX/RX stream count from the HAL.
Pointy hat to: me
|
| 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.
|
| 230663 |
28-Jan-2012 |
adrian |
Oops, commit a missing implementation change.
Whilst I'm here, add a comment about what would happen in this function
if hypothetically you had a radar pattern matching detector written.
|
| 230658 |
28-Jan-2012 |
adrian |
Change the prototype so the radar enable can fail.
|
| 230657 |
28-Jan-2012 |
adrian |
Two changes from my DFS work:
* Grab the net80211com lock when calling ieee80211_dfs_notify_radar().
* Use the tsf extend function to turn the 64 bit base TSF into a per-
frame 64 bit TSF. This will improve radiotap logging (which will
now have a (more) correct per-frame TSF, rather then the single TSF64
value read at the beginning of ath_rx_proc().
|
| 230564 |
26-Jan-2012 |
adrian |
Add some node debugging which has helped me track down which particular
concurrent vap->iv_bss free issues have been occuring.
|
| 230493 |
24-Jan-2012 |
adrian |
Fix up some style(9) indenting and reorganise some of the hal methods.
There should be no functional change due to this commit.
|
| 230492 |
24-Jan-2012 |
adrian |
Add a missing HAL method macro. I'm using this as part of some personal
DFS radar stuff.
|
| 230147 |
15-Jan-2012 |
adrian |
Break out the "memory" EEPROM data read method from being AR9130 specific
to being more generic.
Other embedded SoCs also throw the configuration/PCI register
info into flash.
For now I'm just hard-coding the AR9280 option (for on-board AR9220's on
AP94 and commercial designs (eg D-Link DIR-825.))
TODO:
* Figure out how to support it for all 11n SoC NICs by doing it in
ar5416InitState();
* Don't hard-code the EEPROM size - add another field which is set
by the relevant chip initialisation code.
* 'owl_eep_start_loc' may need to be overridden in some cases to 0x0.
I need to do some further digging.
|
| 229950 |
11-Jan-2012 |
adrian |
Re-enable the PHY radar error frames if sc_dodfs is set.
This was messing up a local port of the atheros reference radar detection
code; I'll fix the port instead.
|
| 229949 |
11-Jan-2012 |
adrian |
style(9) changes. This shouldn't change functionality.
|
| 229791 |
07-Jan-2012 |
adrian |
.. the AR5416 HAL code touches the MIMO parts in HAL_CHANNEL,
so this is also needed.
Pointed out by: bz
|
| 229790 |
07-Jan-2012 |
adrian |
Commit a temporary workaround for people who are building kernels
where they've disabled all the wireless devices/framework.
This is just a build workaround. If you're actively using wireless,
you must still define AH_SUPPORT_AR5416 as I'm not sure what else
will break!
The real solution is to make the module build depend if AH_SUPPORT_AR5416
is defined, as well as make the 11n code in if_ath_tx.c and if_ath_tx_ht.c
completely optional (maybe depend upon ATH_SUPPORT_11N.)
|
| 229165 |
01-Jan-2012 |
adrian |
If frames are dumped out of the queue, let's at least see what they are.
This shows that the majority of the weird traffic I see here are probe
frames that haven't been sent out, but I can also trigger this condition
by doing ICMP w/ -i 0.3 - enough to trigger the TX during actual scanning,
but not fast enough to stop scanning from occuring.
PR: kern/163689
|
| 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
|
| 228893 |
26-Dec-2011 |
adrian |
AR5416 has 14 GPIO pins, from 0->13.
|
| 228892 |
26-Dec-2011 |
adrian |
Since the only thing with a mux is the AR5416 and later, and we're now
doing split software/hardware LED configuration, we can now simply
treat "softled" as an "output" mux type.
This works fine on this DWA-552. Previous generation (pre-11n NICs) don't
have a GPIO mux - only input/output configuration - so they ignore this
field.
|
| 228891 |
26-Dec-2011 |
adrian |
Flesh out configurable hardware based LED blinking.
The hardware (MAC) LED blinking involves a few things:
* Selecting which GPIO pins map to the MAC "power" and "network" lines;
* Configuring the MAC LED state (associated, scanning, idle);
* Configuring the MAC LED blinking type and speed.
The AR5416 HAL configures the normal blinking setup - ie, blink rate based
on TX/RX throughput. The default AR5212 HAL doesn't program in any
specific blinking type, but the default of 0 is the same.
This code introduces a few things:
* The hardware led override is configured via sysctl 'hardled';
* The MAC network and power LED GPIO lines can be set, or left at -1
if needed. This is intended to allow only one of the hardware MUX
entries to be configured (eg for PCIe cards which only have one LED
exposed.)
TODO:
* For AR2417, the software LED blinking involves software blinking the
Network LED. For the AR5416 and later, this can just be configured
as a GPIO output line. I'll chase that up with a subsequent commit.
* Add another software LED blink for "Link", separate from "activity",
which blinks based on the association state. This would make my
D-Link DWA-552 have consistent and useful LED behaviour (as they're
marked "Link" and "Activity."
* Don't expose the hardware LED override unless it's an AR5416 or later,
as the previous generation hardware doesn't have this multiplexing
setup.
|
| 228890 |
26-Dec-2011 |
adrian |
Setup the initial LED state on attach and resume.
Some of the NICs I have here power up with the LEDs blinking, which is
incorrect. The blinking should only occur when the NIC is attempting
to associate.
* On powerup, set the state to HAL_LED_INIT, which turns on the "Power" MAC
LED but leaves the "Network" MAC LED the way it is.
* On resume, also init it to HAL_LED_INIT unless in station mode, where
it's forced to HAL_LED_RUN. Hopefully the net80211 state machine will
call newstate() at some point, which will refiddle the LEDs.
I've tested this on a handful of 11n and pre-11n NICs. The blinking
behaviour is slightly more sensible now.
|
| 228889 |
26-Dec-2011 |
adrian |
Update the hardware LED blinking code to do something useful rather than
relying on what the register defaults are.
This forces the blink mode to be proportional to the TX and RX frames
which match the RX filter.
This (along with a few tweaks to if_ath_led.c to configure the correct
GPIO pins) allows my DWA-552 AR5416 NIC to blink the LEDs in a useful
fashion, however those LEDs are marked "Link" and "Act(ivity)", which
don't really map well to the "power" / "network" LED interface which
the MAC provides. Some further tinkering is needed to see what other
useful operating modes are possible.
|
| 228888 |
26-Dec-2011 |
adrian |
Refactor out the software LED config code into a common function, called
ath_led_config().
The eventual aim is to have both software and hardware based LED
configuration done here.
|
| 228887 |
26-Dec-2011 |
adrian |
First pass of LED related code changes.
Migrate the LED code out of if_ath.c and into if_ath_led.c.
These routines are _all_ software based LED blinking.
|
| 228886 |
26-Dec-2011 |
adrian |
Do a quick style(9) pass of some of the code introduced with 802.11n
support.
|
| 228837 |
23-Dec-2011 |
adrian |
Disable the code which hard-sets the LEDs on. This prevents the LED
state from correctly updating things.
The reference driver directly enables/disables the LED state as required,
rather than nailing it up like it currently is. That'll have to come
later by adding some further HAL methods.
Obtained from: Atheros
|
| 228836 |
23-Dec-2011 |
adrian |
Port over some more GPIO fixes from the atheros reference HAL.
* Bring the AR5416 GPIO mux mask code in line with the code from the
HAL.
* Add HAL_DEBUG_GPIO debugging statements, to track what's going on.
* Add Kiwi GPIO specific changes for reading values back.
Obtained from: Atheros
|
| 228834 |
23-Dec-2011 |
adrian |
Port over some GPIO and LED fixes.
* As a preparation for AR9287 GPIO support, add in the AR9287 GPIO mask.
* Fix the association mask values; these are post-shift values but were
being shifted in twice. This resulted in some garbage being written
in the wrong place and the link LED (at least on my d-link AR5416
NIC) giving totally incorrect blink patterns.
|
| 228833 |
23-Dec-2011 |
adrian |
Remove unused #define's.
Pointy hat to: adrian, for not properly reading things when he copied
ar9285.h to ar9287.h.
|
| 228832 |
23-Dec-2011 |
adrian |
Rework this ugly mess that tries to handle reset serialisation.
Some users were reporting concurrent resets _were_ occuring - ie,
either two ath_reset()s ran at the same time (likely one on each CPU)
or ath_reset() versus ath_chan_change().
Instead, this now tries to grab the serialisation semaphore and will
pause() for a while if it fails. It will always eventually succeed though
and will log an error if it hits the recursion situation.
All of this stuff needs to die a horrible death at some point and be
replaced with a properly serialising method of programming this stuff
(eg using the net80211 taskqueue for all of this stuff.) The trouble
is figuring out how to handle the concurrent ioctl() based things without
introducing more LORs (which is another reason why I haven't just wrapped
all of this stuff in large, long-lived locks, a-la what Linux can get
away with.)
MFC after: Absolutely, positively never.
|
| 228830 |
23-Dec-2011 |
adrian |
Make some more of the 11n specific code conditional.
This doesn't fix compilation w/out AH_SUPPORT_AR5416 as all of the software
aggregation support in if_ath_tx.c and 11n code in if_ath_tx_ht.c touches
the 11n specific fields. I'll work on that later.
|
| 228829 |
23-Dec-2011 |
adrian |
Add a temporary debugging statement in order to try and identify what's
going on with the occasional garbage rs_antenna field reported by AR9285
users.
I've discovered that the 11n NICs only fill out the entire RX status
descriptor on the final descriptor in an aggregate. Some of the fields
(notably RSSI) are complete nonsense for A-MPDU subframes. This may
be another example of this.
The driver doesn't currently toss out statistics for non-final aggregate
frames. It's likely that this should be done.
If any users hit this particular debugging message they should report it
immediately to freebsd-wireless@freebsd.org - please ensure you have
ATH_DEBUG enabled so it prints out the full receive descriptor.
PR: kern/163312
|
| 228817 |
22-Dec-2011 |
adrian |
Use the correct types when calling the decompression mask function.
There's currently no public code which uses this feature and the
current reference driver doesn't enable this feature at all.
It's possible it was used by a previous version of the driver and
that indeed it should return HAL_STATUS; but at this point I'm
happy to require that they complain and submit a patch.
This was found by LLVM compile-time type checking.
Submitted by: dim
|
| 228800 |
22-Dec-2011 |
dim |
Revert r228786. We'll need to work around the warnings in another way.
Requested 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
|
| 228786 |
21-Dec-2011 |
dim |
Fix enum conversion problems in sys/dev/ath/ath_hal/ar5212/ar5212_misc.c
and sys/dev/ath/ath_hal/ar5416/ar5416_misc.c:
sys/dev/ath/ath_hal/ar5212/ar5212_misc.c:577:24: warning: implicit conversion from enumeration type 'HAL_STATUS' to different enumeration type 'HAL_BOOL' [-Wconversion]
return HAL_EINVAL;
~~~~~~ ^~~~~~~~~~
and:
sys/dev/ath/ath_hal/ar5416/ar5416_misc.c:164:9: warning: implicit conversion from enumeration type 'HAL_STATUS' to different enumeration type 'HAL_BOOL' [-Wconversion]
return HAL_OK;
~~~~~~ ^~~~~~
In both cases, enums HAL_BOOL and HAL_STATUS are mixed up.
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
|
| 228621 |
17-Dec-2011 |
bschmidt |
Fix some net80211 enum nits:
- ic_vap_create() uses an ieee80211_opmode argument
- ieee80211_rate2media() takes an ieee80211_phymode argument
- ieee80211_plcp2rate() takes an ieee80211_phytype argument
- cast to enum ieee80211_protmode and ieee80211_roamingmode to silence
compiler warnings
Submitted by: arundel@
|
| 228517 |
15-Dec-2011 |
adrian |
Add the 11n chipset RF frontends to the linker set, even though they're not
attached this way.
The AR5212 based NICs have a variety of RF frontends, so there's a linker set
which the AR5212 attach routine calls. The same framework is used for the
AR5416 and later but as there's a fixed RF frontend for each 11n NIC, it
is just directly attached.
However in the case of compiling a cut down HAL (eg _just_ AR9130 WMAC support),
the linker set ends up being empty and this causes the compile to fail.
So this is just a workaround for that - it means those users who wish an 11n
only HAL can compile the 11n chipsets and RF frontend they need, and just
"ath_ar5212" for the AR5212/AR5416 common code, and it'll just work.
Sponsored by: Hobnob, Inc.
|
| 228516 |
15-Dec-2011 |
adrian |
Print out the radio RF version at startup, so I can better see which
RF frontend versions people have when they submit problem reports.
Sponsored by: Hobnob, Inc.
|
| 228515 |
15-Dec-2011 |
adrian |
Use the correct RF version probe routine.
Obtained from: Atheros
Sponsored by: Hobnob, Inc.
|
| 227872 |
23-Nov-2011 |
adrian |
Re-lock the ath lock after ath_reset() has been called.
The calibrate callout is done with the sc lock held.
This only showed up when using an older NIC (AR5212) whose
radio/phy requires the rfgain adjustment.
Pointy-hat-to: adrian
Sponsored by: Hobnob, Inc.
|
| 227868 |
23-Nov-2011 |
adrian |
Flesh out the TX aggregation completion statistics.
* Failall is now named just that.
* Add TX ok and TX fail, for aggregate frame sub-frames.
This will break athstats; a followup commit wil resolve this.
Sponsored by: Hobnob, Inc.
|
| 227806 |
21-Nov-2011 |
adrian |
Use the correct lock when calling msleep().
This fixes panics that users have been seeing when operating in station mode,
where the interface undergoes a lot more resets then in hostap mode (ie whilst
doing channel scanning.)
Reported by: arundel, wblock@wonkity.com
Sponsored by: Hobnob, Inc.
|
| 227804 |
21-Nov-2011 |
adrian |
Fix some whitespace pollution.
|
| 227741 |
19-Nov-2011 |
adrian |
Add some (totally untested!) code to correctly set the RF half/quarter
mode configuration registers. This is apparently required for correct
behaviour, but also requires the chip to actually officially support it.
Sponsored by: Hobnob, Inc.
|
| 227740 |
19-Nov-2011 |
adrian |
Begin breaking apart the receive setup/stop path in preparation for more
"correct" handling of frames in the RX pending queue during interface
transitions.
* ath_stoprecv() doesn't blank out the descriptor list - that's what
ath_startrecv() does. So, change a comment to reflect that.
* ath_stoprecv() does include a large (3ms) delay to let pending DMA
complete. However, I'm under the impression that the stopdma hal
method does check for a bit in the PCU to indicate DMA has stopped.
So, to help with fast abort and restart, modify ath_stoprecv() to take
a flag which indicates whether this is needed.
* Modify the uses of ath_stoprecv() to pass in a flag to support the
existing behaviour (ie, do the delay.)
* Remove some duplicate PCU teardown code (which wasn't shutting down DMA,
so it wasn't entirely correct..) and replace it with a call to
ath_stoprecv(sc, 0) - which disables the DELAY call.
The upshoot of this is now channel change doesn't simply drop completed
frames on the floor, but instead it cleanly handles those frames.
It still discards pending TX frames in the software and hardware queues
as there's no (current) logic which forcibly recalculates the rate control
information (or whether they're appropriate to be on the TX queue after
a channel change), that'll come later.
This still doesn't stop all the sources of queue stalls but it does
tidy up some of the code duplication.
To be complete, queue stalls now occur during normal behaviour -
they only occur after some kind of broken behaviour causes an interface
or node flush, upsetting the TX/RX BAW. Subsequent commits will
incrementally fix these and other related issues.
Sponsored by: Hobnob, Inc.
|
| 227651 |
18-Nov-2011 |
adrian |
Flesh out some slightly dirty reset/channel change serialisation code
for the ath(4) driver.
Currently, there's nothing stopping reset, channel change and general
TX/RX from overlapping with each other. This wasn't a big deal with
pre-11n traffic as it just results in some dropped frames.
It's possible this may have also caused some inconsistencies and
badly-setup hardware.
Since locks can't be held across all of this (the Linux solution)
due to LORs with the network stack locks, some state counter
variables are used to track what parts of the code the driver is
currently in.
When the hardware is being reset, it disables the taskqueue and
waits for pending interrupts, tx, rx and tx completion before
it begins the reset or channel change.
TX and RX both abort if called during an active reset or channel
change.
Finally, the reset path now doesn't flush frames if ATH_RESET_NOLOSS
is set. Instead, completed TX and RX frames are passed back up to
net80211 before the reset occurs.
This is not without problems:
* Raw frame xmit are just dropped, rather than placed on a queue.
The net80211 stack should be the one which queues these frames
rather than the driver.
* It's all very messy. It'd be better if these hardware operations
were serialised on some kind of work queue, rather than hoping
they can be run in parallel.
* The taskqueue block/unblock may occur in parallel with the
newstate() function - which shuts down the taskqueue and restarts
it once the new state is known. It's likely these operations should
be refcounted so the taskqueue is restored once no other areas
in the code wish to suspend operations.
* .. interrupt disable/enable should likely be refcounted as well.
With this work, the driver does not drop frames during stuck beacon
or fatal errors and thus 11n traffic continues to run correctly.
Default and full resets however do still drop frames and it's possible
this may occur, causing traffic loss and session stalls.
Sponsored by: Hobnob, Inc.
|
| 227468 |
12-Nov-2011 |
adrian |
Disable writing to the extension CYCPWR1 register.
This seems to make ANI behave better on the AR5416/AR5418.
Sponsored by: Hobnob, Inc.
|
| 227434 |
11-Nov-2011 |
adrian |
Correct device id comments.
|
| 227411 |
09-Nov-2011 |
adrian |
Bump this up to where it used to be.
I need to investigate this a little closer, but it seems that in noisy
environments the NF load takes longer than 5 * DELAY(10) and this is
messing up future NF calibrations. (The background: NF calibrations
begin at the value programmed in after the load has completed, so
if this is never loaded in, the NF calibrations only ever start at
the currently calibrated NF value, rather than starting at something
high (say -50.)
More investigation about the effect on 11n RX and calibration results
are needed.
Sponsored by: Hobnob, Inc.
|
| 227410 |
09-Nov-2011 |
adrian |
Introduce a work-around for issues with the AR5416 based MAC on SMP devices.
The AR5416 MAC (which shows up in the AR5008, AR9001, AR9002 devices) has
issues with PCI transactions on SMP machines. This work-around enforces
that register access is serialised through a (global for now) spinlock.
This should stop the hangs people have seen with the AR5416 PCI devices
on SMP hosts.
Obtained by: Linux, Atheros
|
| 227408 |
09-Nov-2011 |
adrian |
Commit a missing fix - the AR_SREV_KIWI_10_OR_LATER() check.
|
| 227405 |
09-Nov-2011 |
adrian |
Even though the HAL doesn't currently support Kiwi 1.0/1.1,
be "more correct" about the Kiwi setup.
Obtained from: Atheros
|
| 227398 |
09-Nov-2011 |
adrian |
If software retransmit occurs with an ath_buf marked ATH_BUF_BUSY,
it's cloned and that clone is retransmitted. This means that the
ath_buf pointer squirreled away on the baw window array is suddenly
wrong and was causing all kinds of console output.
This updates the pointer in that particular BAW slot to the new
ath_buf after ensuring that:
* the new and old buffers have the same seqno;
* the current slot pointer matches the old buffer pointer.
This quietens the debugging output (again), restoring said debugging
to only signify when a broken condition has occured.
Sponsored by: Hobnob, Inc.
|
| 227388 |
09-Nov-2011 |
adrian |
* Force the MAC to wakeup before we try resetting it, to ensure
it actually _gets_ reset properly.
* Add some more comments describing why things are done.
Obtained from: Atheros
|
| 227387 |
09-Nov-2011 |
adrian |
Tidy up the AR9287 HAL a tiny bit - fix up AR9280 references.
|
| 227381 |
09-Nov-2011 |
adrian |
Migrate the AR5416 ANI code to use the previously introduced method
to fetch the current channel busy statistics, rather than duplicating
it here.
This forms the (very crude) basis for doing basic channel surveying.
Sponsored by: Hobnob, Inc.
|
| 227380 |
09-Nov-2011 |
adrian |
Disable OFDM weak signal detection by default. Leave this to be
enabled if required by STA operation.
This quietens a lot of OFDM errors seen in hostap mode, where
there are no beacon RSSI levels to tune the dynamic range of the
baseband.
This may reduce reception range at the fringes, but does increase
stability.
Sponsored by: Hobnob, Inc.
|
| 227379 |
09-Nov-2011 |
adrian |
Use a restricted set of parameters when operating in hostap mode.
The 5ghz hostap mode (where DFS is being done) requires ANI to be disabled
or the radar detection parameters don't work as advertised (as they're based
on signal strength level, and tweaking ANI affects the signal strangth,
dynamic range and power increase the baseband is looking for in order to
detect it as a "signal".)
Obtained from: Linux, Atheros
Sponsored by: Hobnob, Inc.
|
| 227378 |
09-Nov-2011 |
adrian |
Add logic to ANI to tweak the firstep parameter when in hostap mode.
This is normally done based on the beacon RSSI but this isn't available
in hostap mode.
Obtained from: Atheros
Sponsored by: Hobnob, Inc.
|
| 227377 |
09-Nov-2011 |
adrian |
.. and add some ANI fixes missing from the last ANI commit.
Obtained from: Atheros
Sponsored by: Hobnob, Inc.
|
| 227376 |
09-Nov-2011 |
adrian |
Include some ANI fixes for the AR5416.
* If we fall through from an ANI command (eg because it's out of range,
or it's disabled) then fall through to the next ANI command rather then
being stuck there.
* Fix some off-by-one comparisons, meaning the final level in some parameters
were never tweaked.
Obtained from: Atheros
Sponsored by: Hobnob, Inc.
|
| 227375 |
09-Nov-2011 |
adrian |
Add a new HAL parameter which forces a full reset rather than warm reset.
This forces a full reset of the baseband/radio and seems needed to clear
some issues (with Merlin at least) when the baseband gets confused in a
very noisy environment.
Sponsored by: Hobnob, Inc.
|
| 227374 |
09-Nov-2011 |
adrian |
Port over a new routine which grabs the percentage of time spent in TX frame, RX frame,
RX clear, RX extension clear.
This is useful for estimating channel business.
The same routines should be written for AR5210->AR5212 where appopriate.
Obtained from: Atheros
|
| 227373 |
09-Nov-2011 |
adrian |
Add in some more PCI/PCIe differentiation.
|
| 227372 |
09-Nov-2011 |
adrian |
Try to make it more obvious when users are using the PCI or PCIe versions of
the 11n chips.
|
| 227371 |
09-Nov-2011 |
adrian |
Fix the compile to work when IEEE80211_DEBUG isn't defined.
Sponsored by: Hobnob, Inc.
|
| 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.
|
| 227364 |
08-Nov-2011 |
adrian |
Introduce TX aggregation and software TX queue management
for Atheros AR5416 and later wireless devices.
This is a very large commit - the complete history can be
found in the user/adrian/if_ath_tx branch.
Legacy (ie, pre-AR5416) devices also use the per-software
TXQ support and (in theory) can support non-aggregation
ADDBA sessions. However, the net80211 stack doesn't currently
support this.
In summary:
TX path:
* queued frames normally go onto a per-TID, per-node queue
* some special frames (eg ADDBA control frames) are thrown
directly onto the relevant hardware queue so they can
go out before any software queued frames are queued.
* Add methods to create, suspend, resume and tear down an
aggregation session.
* Add in software retransmission of both normal and aggregate
frames.
* Add in completion handling of aggregate frames, including
parsing the block ack bitmap provided by the hardware.
* Write an aggregation function which can assemble frames into
an aggregate based on the selected rate control and channel
configuration.
* The per-TID queues are locked based on their target hardware
TX queue. This matches what ath9k/atheros does, and thus
simplified porting over some of the aggregation logic.
* When doing TX aggregation, stick the sequence number allocation
in the TX path rather than net80211 TX path, and protect it
by the TXQ lock.
Rate control:
* Delay rate control selection until the frame is about to
be queued to the hardware, so retried frames can have their
rate control choices changed. Frames with a static rate
control selection have that applied before each TX, just
to simplify the TX path (ie, not have "static" and "dynamic"
rate control special cased.)
* Teach ath_rate_sample about aggregates - both completion and
errors.
* Add an EWMA for tracking what the current "good" MCS rate is
based on failure rates.
Misc:
* Introduce a bunch of dirty hacks and workarounds so TID mapping
and net80211 frame inspection can be kept out of the net80211
layer. Because of the way this code works (and it's from Atheros
and Linux ath9k), there is a consistent, 1:1 mapping between
TID and AC. So we need to ensure that frames going to a specific
TID will _always_ end up on the right AC, and vice versa, or the
completion/locking will simply get very confused. I plan on
addressing this mess in the future.
Known issues:
* There is no BAR frame transmission just yet. A whole lot of
tidying up needs to occur before BAR frame TX can occur in the
"correct" place - ie, once the TID TX queue has been drained.
* Interface reset/purge/etc results in frames in the TX and RX
queues being removed. This creates holes in the sequence numbers
being assigned and the TX/RX AMPDU code (on either side) just
hangs.
* There's no filtered frame support at the present moment, so
stations going into power saving mode will simply have a number
of frames dropped - likely resulting in a traffic "hang".
* Raw frame TX is going to just not function with 11n aggregation.
Likely this needs to be modified to always override the sequence
number if the frame is going into an aggregation session.
However, general raw frame injection currently doesn't work in
general in net80211, so let's just ignore this for now until
this is sorted out.
* HT protection is just not implemented and won't be until the above
is sorted out. In addition, the AR5416 has issues RTS protecting
large aggregates (anything >8k), so the work around needs to be
ported and tested. Thus, this will be put on hold until the above
work is complete.
* The rate control module 'sample' is the only currently supported
module; onoe/amrr haven't been tested and have likely bit rotted
a little. I'll follow up with some commits to make them work again
for non-11n rates, but they won't be updated to handle 11n and
aggregation. If someone wishes to do so then they're welcome to
send along patches.
* .. and "sample" doesn't really do a good job of 11n TX. Specifically,
the metrics used (packet TX time and failure/success rates) isn't as
useful for 11n. It's likely that it should be extended to take into
account the aggregate throughput possible and then choose a rate
which maximises that. Ie, it may be acceptable for a higher MCS rate
with a higher failure to be used if it gives a more acceptable
throughput/latency then a lower MCS rate @ a lower error rate.
Again, patches will be gratefully accepted.
Because of this, ATH_ENABLE_11N is still not enabled by default.
Sponsored by: Hobnob, Inc.
Obtained from: Linux, Atheros
|
| 227363 |
08-Nov-2011 |
adrian |
Add support to the TX descriptor printing code to follow ath_buf
chains. This allows for debugging of aggregate frames.
Sponsored by: Hobnob, Inc.
|
| 227362 |
08-Nov-2011 |
adrian |
Make sure TXEOL is set on default queues. Otherwise we don't get an
interrupt on the completion of a TX queue and this can cause TX
hangs / timeout.
Sponsored by: Hobnob, Inc.
|
| 227361 |
08-Nov-2011 |
adrian |
Refactor out the TX buffer management and completion code in
preparation for TX aggregation.
* Add in logic which calls ath_buf bf->bf_comp if it's set.
This allows for AMPDU (and RIFS, and FF, if someone desires) code
to handle completion - which includes freeing subframes, retransmitting
subframes, etc.
* Break out the buffer free, buffer busy/unbusy default completion handler
code into separate functions. This allows bf_comp methods to free and
unbusy each subframe ath_buf as required.
* Break out the statistics update code into a separate function, just
to clean up the TX completion path a little.
Sponsored by: Hobnob, Inc.
|
| 227360 |
08-Nov-2011 |
adrian |
Change the descriptor logic to use bf_lastds to point to the last
descriptor, rather than using the maths involving bf_desc[bf_nseg - 1].
When doing TX aggregation, the status will be updated in the -final-
descriptor of the -final- subframe in an aggregate. Thus bf_lastds
may point to the last descriptor in a completely different ath_buf.
Sponsored by: Hobnob, Inc.
|
| 227359 |
08-Nov-2011 |
adrian |
Change ath_buf allocation to:
* Immediately return NULL if a buffer isn't available;
* Track the "buffers not available" count;
* Clear some fields used for tx aggregation;
* Add ath_buf_clone() which clones the majority of buffer state.
This is needed when retransmission of a "busy" buffer is required.
Sponsored by: Hobnob, Inc.
|
| 227358 |
08-Nov-2011 |
adrian |
Break out the TX DMA stop code into a separate function.
Sponsored by: Hobnob, Inc.
|
| 227357 |
08-Nov-2011 |
adrian |
Add a 'vap' to ath_keyset().
Add some code (which is currently disabled) which modifies the group
multicast key cache behaviour. I haven't yet figured out what the
exact/correct behaviour is so I'm leaving it disabled. It's worth
investigating and "correcting", especially for future work with
mesh/ibss and encryption.
Sponsored by: Hobnob, Inc.
|
| 227356 |
08-Nov-2011 |
adrian |
Some more various fixes, etc from my 11n branch.
* When doing software TX queue handling and flush, it's possible
that the deletion of a VAP (eg a STA shutdown) will queue a
"STA Disassociate" frame whilst the interface is being deleted.
The VAP is then deleted, and the frame ends up being queued
to a node that is freed before it can be TX'ed. Things go awry
at this point.
There's no way at the present to avoid freeing the underlying node
when the vap is being deleted. It's too late in the game.
I suspect the real fix is to make sure the frame is software
queued with no completion information somehow, so it doesn't
link back to a node whose underlying VAP has been freed.
For now, we'll just have to do this.
* Add some comments showing what's going on.
* Move an instance of the ATH_LOCK() around to protect the interrupt
set. I'll worry about changing that to a PCU lock later on once
the 11n code is in the tree.
Sponsored by: Hobnob, Inc.
|
| 227354 |
08-Nov-2011 |
adrian |
Add KTR tracepoints to the ath driver, in order to debug TX, RX
and interrupt handling.
Sponsored by: Hobnob, Inc.
|
| 227353 |
08-Nov-2011 |
adrian |
In preparation for supporting 11n TX/RX properly, allow for TX queue draining
and interface resets to be marked as ATH_RESET_DEFAULT, ATH_RESET_FULL,
ATH_RESET_NOLOSS.
Currently a reset is still a reset - ie, all tx/rx frames in the hardware
queues are purged. This means that those frames will be lost to the 11n TX
and RX aggregation state tracking, breaking AMPDU sessions.
The (eventual) new semantics:
* ATH_RESET_DEFAULT:
full reset, this is the default for reset situations
which I haven't yet figured out what they should be.
* ATH_RESET_FULL:
A full reset - for things such as channel changes.
* ATH_RESET_NOLOSS:
Don't flush TX/RX queues - handle pending RX frames and leave TX
frames where they are; restart TX DMA from where it was.
|
| 227352 |
08-Nov-2011 |
adrian |
Break out the node cleanup and node free path, in preparation for
doing software TX queue management.
The software queued TX frames will be freed by the new cleanup
function.
Sponsored by: Hobnob, Inc.
|
| 227351 |
08-Nov-2011 |
adrian |
Preparation for correct 802.11n tx/rx handling.
* Change ath_rx_proc() to ath_rx_tasklet(); make that the taskqueue function.
This way (eventually) ath_rx_proc() can be called from elsewhere in the
packet reset/processing queue so frames aren't just "flushed" during
interface resets/reconfigure. This breaks 802.11n RX aggregation tracking.
* Extend ath_tx_proc() to take a 'resched' flag, which marks whether to
reschedule further RX PCU reads or not.
* Change ath_tx_processq() to take a "dosched" flag, which will eventually
be used to indicate whether to reschedule the software TX scheduler.
Sponsored by: Hobnob, Inc.
|
| 227350 |
08-Nov-2011 |
adrian |
Conditionally compile the PCI latency workaround; I think it's
only required for some earlier NICs.
|
| 227346 |
08-Nov-2011 |
adrian |
Merge in some fixes from the if_ath_tx branch.
* Close down some of the kickpcu races, where the interrupt handler
can and will run concurrently with the taskqueue.
* Close down the TXQ active/completed race between the interrupt
handler and the concurrently running tx completion taskqueue
function.
* Add some tx and rx interrupt count tracking, for debugging.
* Fix the kickpcu logic in ath_rx_proc() to not simply drain and
restart the TX queue - instead, assume the hardware isn't
(too) confused and just restart RX DMA. This may break on
previous chipsets, so if it does I'll add a HAL flag and
conditionally handle this (ie, for broken chipsets, I'll
just restore the "stop PCU / flush things / restart PCU"
logic.)
* Misc stuff
Sponsored by: Hobnob, Inc.
|
| 227344 |
08-Nov-2011 |
adrian |
Migrate the STAILQ lists to TAILQs.
A bunch of the 11n TX aggregation logic wants to traverse lists of buffers
in various ways. In order to provide O(1) behaviour in this instance,
use TAILQs.
This does blow out the memory footprint and CPU cycles slightly for some
of these operations. I may convert some of these back to STAILQs once
the rest of the software transmit queue handling has been stabilised.
Sponsored by: Hobnob, Inc.
|
| 227340 |
08-Nov-2011 |
adrian |
Some cosmetic fixes to ath_rate_sample.
* Use 64 bit integer types for the sample rate statistics.
When TX'ing 11n aggregates, a 32 bit counter will overflow in a few
hours due to the high packet throughput.
* Create a default label of "" rather than defaulting to "Mb" - that way
if a rate hasn't yet been selected, it won't say "-1 Mb".
Sponsored by: Hobnob, Inc.
|
| 227328 |
08-Nov-2011 |
adrian |
Begin merging in some of my 802.11n TX aggregation driver changes.
* Add a PCU lock, which isn't currently used but will eventually be
used to serialise some of the driver access.
* Add in all the software TX aggregation state, that's kept per-node
and per-TID.
* Add in the software and aggregation state to ath_buf.
* Add in hooks to ath_softc for aggregation state and the (upcoming)
aggregation TX state calls.
* Add / fix the HAL access macros.
Obtained from: Linux, ath9k
Sponsored by: Hobnob, Inc.
|
| 227327 |
08-Nov-2011 |
adrian |
Bring over the 11n aggregation statistics struct from the if_ath_tx branch.
|
| 227326 |
08-Nov-2011 |
adrian |
Merge in ath rate flags and ath_rc_series from my 11n TX branch.
This is in preparation for 802.11n TX aggregation support.
|
| 227309 |
07-Nov-2011 |
ed |
Mark all SYSCTL_NODEs static that have no corresponding SYSCTL_DECLs.
The SYSCTL_NODE macro defines a list that stores all child-elements of
that node. If there's no SYSCTL_DECL macro anywhere else, there's no
reason why it shouldn't be static.
|
| 227293 |
07-Nov-2011 |
ed |
Mark MALLOC_DEFINEs static that have no corresponding MALLOC_DECLAREs.
This means that their use is restricted to a single C file.
|
| 227080 |
04-Nov-2011 |
adrian |
Call the correct chipset power routine when disabling the AR5416 and later NICs.
|
| 226900 |
29-Oct-2011 |
adrian |
Add some new ath(4) debugging bits, from my if_ath_tx 11n TX branch.
|
| 226884 |
28-Oct-2011 |
adrian |
When punting frames to the RX tap, free the mbufs since we've tampered with
their length.
Without this, an error frame mbuf would:
* have its size adjusted;
* thrown at the radiotap code;
* then since it's never consumed, the rxbuf/mbuf is then re-added to the
RX descriptor list with the small size;
* .. and the hardware ends up (sometimes) only DMA'ing part of a frame into
the small buffer, chaining RX frames together (setting the more flag).
I discovered this particular issue when doing some promiscuous radiotap
testing; I found that I'd occasionally get rs_more set in RX descriptors
w/ the first frame length being very small (sub-100 bytes.) The driver
handles 2-descriptor RX frames (but not more), so this still worked; it
was just odd.
This is suboptimal and may benefit from being replaced with caching
the m_pkthdr_len and m_len fields, then restoring them after completion.
|
| 226798 |
26-Oct-2011 |
adrian |
As a prelude to bringing over the 11n work, include some extra statistics fields.
|
| 226767 |
25-Oct-2011 |
adrian |
Add in some more 11n related HAL methods.
|
| 226765 |
25-Oct-2011 |
adrian |
The AR5413 datasheet specifies that AR_TxIntrReq should be set consistently
for all frames, so do so.
|
| 226764 |
25-Oct-2011 |
adrian |
Add some fixes to the 11n aggregation HAL calls:
* preserve AR_TxIntrReq on every descriptor in an aggregate chain,
not just the first descriptor;
* always blank out the descriptor in ar5416ChainTxDesc() when forming
aggregates - the way I'm using this in the 11n branch is to first
chain aggregates together, then use the other HAL calls to fill in
the details.
|
| 226762 |
25-Oct-2011 |
adrian |
Correct/complete a partially-disabled TX interrupt mitigation configuration.
Although a previous commit disabled TX interrupt mitigation handling and
configuration, the mask register bits weren't setup correctly.
|
| 226761 |
25-Oct-2011 |
adrian |
Fix an incorrect flag.
Obtained from: Atheros
|
| 226760 |
25-Oct-2011 |
adrian |
Save and restore the association ID across interface resets.
Obtained from: Atheros
MFC after: 1 week
|
| 226759 |
25-Oct-2011 |
adrian |
Add some 11n bits from the if_ath_tx 11n branch:
* Add the TID field in the TX status descriptor;
* Add in the 11n first/middle/last functions for fiddling
with the descriptors. These are from the Linux and the
reference driver, but I'm not (currently) using them.
* Add further AR_ISR_S5 register definitions.
Obtained from: Linux ath9k, Atheros
|
| 226758 |
25-Oct-2011 |
adrian |
Reduce the NF wait timeout. When doing heavy 11n RX loads, this can actually
interfere with traffic, as the NF load can take quite a while and poking the
AGC every 10uS is just a bit silly.
Instead, just leave the baseband NF calibration where it is and just read it
back next time a longcal interval happens.
|
| 226491 |
18-Oct-2011 |
adrian |
Add in a currently-disabled WAR for PCI NICs.
Some earlier series (~AR5212?) play badly with BIOSes.
In these instances, they may require a forced reset (by transitioning
the NIC through D0 -> D3 -> D0) before they probe/attach correctly.
This is currently disabled because:
* I haven't figured out the "right" code to ensure this only happens
for PCI NICs (not PCIe or Cardbus);
* I haven't at all done wide scale testing for this, and I'm not yet
ready for said wide-scale testing.
I'm documenting this primarily so users with misbehaving NICs have
something to tinker with.
Obtained from: Atheros
|
| 226490 |
18-Oct-2011 |
adrian |
Add a WAR from the reference code - clear the PCI error status
upon detach.
Obtained from: Atheros
|
| 226489 |
18-Oct-2011 |
adrian |
Port over some missing code from the ar5212 reference driver reset path.
The final missing bit here is enabling the PCI configuration register
read, but there's currently no glue available for the HAL to read (and
write) PCI configuration space registers.
Obtained from: Atheros
|
| 226488 |
18-Oct-2011 |
adrian |
Implement the first part of the BB read workaround.
The AR5008/AR9001 series NICs have a bug where BB register reads
will occasionally be corrupted. This could cause issues with things
such as ANI, which adjust operational parameters based on the
BB radio register reads. This was introduced in the AR5008 chip
and fixed with the first released AR9002 series NIC (AR9280v2.)
A followup commit will implement the acutal WAR when reading
BB registers. I'm still not sure how I'll implement it - whether
it should be done in the osdep layer, or whether it should just
live in the AR5416 HAL. Either way, they can use this capability
bit to determine whether to implement the WAR or not.
Thankyou to various sources inside Atheros who have helped me track
down what this particular issue is.
Obtained from: Atheros
|
| 226487 |
18-Oct-2011 |
adrian |
Add in OS_REG_BIT_SET, a macro which does what it says it does.
This will be used in an upcoming commit to the ar5212 HAL.
|
| 226486 |
18-Oct-2011 |
adrian |
Include opt_ah.h when compiling the driver.
There are HAL methods which are actually direct register
access, rather than simply HAL calls. Because of this, these
register accesses would use the non-debug path in ah_osdep.h
as opt_ah.h isn't included.
With this, the correct register access methods are used,
so debugging traces show things such as TXDP checking and
TSF32 access.
|
| 226469 |
17-Oct-2011 |
adrian |
Don't enable the PHY radar errors in calcrxfilter.
That way the radar errors aren't enabled prematurely.
A DFS tester has reported that radar events are reported
during channel scanning, before DFS is actually enabled.
|
| 226436 |
16-Oct-2011 |
eadler |
- change "is is" to "is" or "it is"
- change "the the" to "the"
Approved by: lstewart
Approved by: sahil (mentor)
MFC after: 3 days
|
| 226355 |
14-Oct-2011 |
adrian |
ath_pci PCI setup fixes.
* Break out the PCI setup override code into a new function.
* Re-apply the PCI overrides on powersave resume. The retry timeout
register isn't currently being saved/resumed by the PCI driver/bus
code.
|
| 225957 |
04-Oct-2011 |
adrian |
Add an AR5416 aware version of the "current RSSI" function.
Pre-11n devices and AR5416 use AR_PHY(263) for current RX RSSI.
AR9130 and later have a fourth calibration register (for doing
ADC calibration) and thus the register has moved to AR_PHY(271).
This isn't currently used by any of the active code; I'm committing
this for completeness and in case any third party code attempts to
use it for legacy reasons.
|
| 225934 |
03-Oct-2011 |
adrian |
Port over the radar pulse decoding code common to the AR5416 and later chipsets.
Obtained from: Atheros
|
| 225926 |
02-Oct-2011 |
adrian |
Remove an unused variable.
|
| 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.
|
| 225924 |
02-Oct-2011 |
adrian |
Document exactly what the RX interrupt mitigation timers do.
|
| 225922 |
02-Oct-2011 |
adrian |
For now (ie: until autosleep support is fully fleshed out), always clear
all of the RX status fields when initialising a new RX descriptor.
|
| 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.
|
| 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.
|
| 225822 |
28-Sep-2011 |
adrian |
Don't bother triggering the cabq queue if it's empty.
Obtained from: Atheros
|
| 225821 |
28-Sep-2011 |
adrian |
Fix lock order to be correcter.
Nothing else locks these two queues (cabq, avp mcastq), but it should
be consistent and correct.
|
| 225820 |
28-Sep-2011 |
adrian |
Change the default CABQ time to be 70% of the beacon interval,
rather than the whole beacon interval.
The reference driver and Linux ath9k both choose 80% of the
beacon interval and they do it in the driver rather than
the HAL (Ath reference) or ath9k_hw (ath9k.)
This quietens stuck beacon conditions on my AR9220/AR9280
based NICs when a lot of burst broadcast/multicast traffic
is going on. It doesn't seem to annoy the earlier MACs as
much as the AR9280 and later one.
Obtained from: Linux ath9k, Atheros
|
| 225819 |
28-Sep-2011 |
adrian |
The AR5212 setup path (also used by the AR5416 code) configures a
local variable with a beacon interval of 100 TU. This never gets modified
if the beacon interval configuration changes.
This may have been correct in earlier times, but with the advent of
staggered beacons (which default to 1 / ATH_BCBUF beacon interval, so
25 TU here) this value is incorrect.
It is used to configure the default CABQ readytime. So here, the cabq
was being configured to be much greater than the target beacon timer
(TBTT.)
The driver should be configuring a cabq readytime value rather then
leaving it to the HAL to choose sensible defaults. This should be
done in the future - I'm simply trying to ensure sensible defaults
are chosen.
|
| 225818 |
28-Sep-2011 |
adrian |
Update the default AIFS value for hostap mode.
Obtained from: Linux ath9k, Atheros reference
|
| 225473 |
11-Sep-2011 |
adrian |
Fix the order of parameters passed to the HT frame duration calculation.
Approved by: re (kib)
|
| 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)
|
| 225431 |
07-Sep-2011 |
adrian |
Add a definition for ASYNC_CAUSE_CLR. It's not used yet, but the
reference driver does clear the async interrupts after each service.
I'll tinker with this in a future commit.
Obtained from: Atheros
Approved by: re (kib)
|
| 225421 |
06-Sep-2011 |
adrian |
Fix 5ghz calibration logic when using AR9280 w/ fast clock.
When the fast clock (44mhz) is enabled for 5ghz HT20, the
dual ADCs aren't enabled. Trying to do the ADC calibrations
here would result in calibration never completing; this
resulted in IQ calibration never running and thus performance
issues in 11a/11n HT20 mode.
Leave it enabled for non-fastclock (40mhz) 11a mode and
HT40 modes.
This has been fixed in discussion with Felix Fietkau (nbd)
and discussions with the Atheros baseband team.
Linux ath9k now has a similar fix.
Approved by: re (kib)
|
| 225420 |
06-Sep-2011 |
adrian |
Fix the addac serial load register write for AR5416.
Obtained from: Linux, Atheros
Approved by: re (kib)
|
| 225145 |
24-Aug-2011 |
adrian |
Fix a missing initialisation of bt_flags when setting up the TDMA beacon.
The AR5212 HAL didn't check this field; timers are enabled a different
way.
The AR5416 HAL however did, and since this field was uninitialised, it had
whatever was on the stack at the time. This lead to "unpredictable"
behaviour.
This allows TDMA to work on the AR5416 and later chipsets.
Thanks to: paradyse@gmail.com
Approved by: re (kib, blanket)
|
| 225125 |
24-Aug-2011 |
adrian |
TIM/Timer fixes for AR5416 and later:
* Fix SLEEP1/SLEEP2 register definitions; the CAB/Beacon timeout
fields have changed in AR5416 and later
* The TIM_PERIOD and DTIM_PERIOD registers are now microsecond fields,
not TU.
Obtained from: Linux ath9k, Atheros reference
Approved by: re (kib, blanket)
|
| 225111 |
23-Aug-2011 |
adrian |
These timer registers are all 1uS in resolution in AR5416
or later. Previous hardware had some as TU, some as 1/8th
TU.
* Modify AR_NEXT_DBA and AR_NEXT_SWBA to use a new macro,
ONE_EIGHTH_TU_TO_USEC(), which converts the 1/8th TU
fields to USEC. This is just cosmetic and matches the
Atheros reference driver.
* Fix AR_NEXT_TBTT, which is USEC, not TU.
Submitted by: paradyse@gmail.com
Approved by: re (kib, blanket)
|
| 224734 |
09-Aug-2011 |
adrian |
Remove the now unneeded references to these DFS methods.
Sorry for the noise everyone.
Approved by: re (kib, blanket)
|
| 224724 |
09-Aug-2011 |
adrian |
Remove this call, now that I've solved the radar module problem without
needing this particular modification.
It can be called during ath_dfs_radar_enable() and still achieve the
same functionality, so I am.
Approved by: re (kib, blanket)
|
| 224720 |
08-Aug-2011 |
adrian |
And add another missing brace. Another pointy hat moment.
This one however isn't used by any public code yet, so it
didn't break the build.
Approved by: re (kib, blanket)
|
| 224719 |
08-Aug-2011 |
adrian |
Bitten again by the optional HALDEBUG compilation.
Remove this debugging, it's not needed anymore and when not enabled,
those variables trigger a compiler warning.
Approved by: re (kib, blanket)
Pointy-hat-to: adrian, for not testing a non-debug compile of this code enough
|
| 224718 |
08-Aug-2011 |
adrian |
The older HAL code sets up the regulatory domain once; FreeBSD/net80211
allows it to be overridden at runtime.
Thus, add a function which updates ah_dfsDomain after a channel set
call to ath_hal_set_channels().
Approved by: re (kib, blanket)
|
| 224716 |
08-Aug-2011 |
adrian |
Introduce some more DFS related hooks, inspired both by local work
and the Atheros reference code.
The radar detection code needs to know what the current DFS domain is.
Since net80211 doesn't currently know this information, it's extracted
from the HAL regulatory domain information.
The specifics:
* add a new ath_dfs API hook, ath_dfs_init_radar_filters(), which
updates the radar filters whenever the regulatory domain changes.
* add HAL_DFS_DOMAIN which describes the currently configured DFS domain .
* add a new HAL internal variable which tracks the currently configured
HAL DFS domain.
* add a new HAL capability, HAL_CAP_DFS_DMN, which returns the currently
configured HAL DFS domain setting.
* update the HAL DFS domain setting whenever the channel setting is
updated.
Since this isn't currently used by any radar code, these should all
be no-ops for existing users.
Obtained from: Atheros
Submitted by: KBC Networks, sibridge
Approved by: re (kib, blanket)
|
| 224715 |
08-Aug-2011 |
adrian |
.. and add a missing bracket.
Approved by: re (kib, blanket)
|
| 224714 |
08-Aug-2011 |
adrian |
Fix method naming to match the reference HAL definition.
Obtained from: Atheros
Approved by: re (kib, blanket)
|
| 224709 |
08-Aug-2011 |
adrian |
Add another HAL method - ah_isFastClockEnabled - which returns AH_TRUE
if 5ghz fast clock is enabled in the current operating mode.
It's slightly dirty, but it's part of the reference HAL and used by
the (currently closed-source) radar event code to map radar pulses
back to microsecond durations.
Obtained from: Atheros
Approved by: re (kib, blanket)
|
| 224644 |
04-Aug-2011 |
adrian |
Undo this for now. It's "right", but it means everything will rely on
the ar9130 code.
Since at least one kernel config specifies individual ath HAL chips
rather than just "device ath_hal" (arm/AVILA), I'm doing this so people
aren't caught out when they update to -HEAD or 9.0 and discover their
ath setup doesn't compile.
I'll revisit this with a proper fix sometime before 9.0-RELEASE.
Approved by: re (kib, blanket)
Pointed out by: ray@
Pointy hat to: adrian@
|
| 224634 |
03-Aug-2011 |
adrian |
Add in a dirty hack that allows for AR9280/AR9285/AR9287 embedded
systems, in the same way that AR9130 embedded systems work.
This isn't -everything- that is required - the PCI glue still
needs to be taught about the eepromdata hint, along the same
lines as the AHB glue.
Approved by: re (kib, blanket)
|
| 224633 |
03-Aug-2011 |
adrian |
* Fix a clash in structure naming which occurs with (closed source)
radar detection code. This is just to make porting the atheros
radar code easier.
* add a missing space.
Approved by: re (kib, blanket)
|
| 224624 |
03-Aug-2011 |
adrian |
Remove the EEPROM minor >= 19 check for txgaintype; that's only needed for
Merlin / v14 eeprom formats.
Approved by: re (kib, blanket)
|
| 224588 |
02-Aug-2011 |
adrian |
Fix a corner case in RXEOL handling which was likely introduced by yours
truly.
Before 802.11n, the RX descriptor list would employ the "self-linked tail
descriptor" trick which linked the last descriptor back to itself.
This way, the RX engine would never hit the "end" of the list and stop
processing RX (and assert RXEOL) as it never hit a descriptor whose next
pointer was 0. It would just keep overwriting the last descriptor until
the software freed up some more RX descriptors and chained them onto the
end.
For 802.11n, this needs to stop as a self-linked RX descriptor tickles the
block-ack logic into ACK'ing whatever frames are received into that
self-linked descriptor - so in very busy periods, you could end up with
A-MPDU traffic that is ACKed but never received by the 802.11 stack.
This would cause some confusion as the ADDBA windows would suddenly
be out of sync.
So when that occured here, the last descriptor would be hit and the PCU
logic would stop. It would only start again when the RX descriptor list
was updated and the PCU RX engine was re-tickled. That wasn't being done,
so RXEOL would be continuously asserted and no RX would continue.
This patch introduces a new flag - sc->sc_kickpcu - which when set,
signals the RX task to kick the PCU after its processed whatever packets
it can. This way completed packets aren't discarded.
In case some other task gets called which resets the hardware, don't
update sc->sc_imask - instead, just update the hardware interrupt mask
directly and let either ath_rx_proc() or ath_reset() restore the imask
to its former setting.
Note: this bug was only triggered when doing a whole lot of frame snooping
with serial console IO in the RX task. This would defer interrupt processing
enough to cause an RX descriptor overflow. It doesn't happen in normal
conditions.
Approved by: re (kib, blanket)
|
| 224550 |
31-Jul-2011 |
adrian |
Disable the RXORN/RXEOL interrupts if RXEOL occurs, preventing an
interrupt storm.
This is easily triggered by flipping on and off tcpdump -y IEEE802_11_RADIO
w/ witness enabled. This causes a whole lot of console IO and when you're
attached to a serial console (eg on my AR7161 embedded board), the RX
interrupt doesn't get called quickly enough and the RX queue fills up.
This wasn't a problem in the past because of the self-linked RX descriptor
trick - the RX would never hit the "end" of the RX descriptor list.
However this isn't possible for 802.11n (see previous commit history for
why.)
Both Linux ath9k and the Atheros reference driver code do this; I'm just
looking now for where they then restart the PCU receive. Right now the RX
will just stop until the interface is reset.
Obtained from: Linux, Atheros
Approved by: re (kib)
|
| 224542 |
31-Jul-2011 |
adrian |
Remove two debugging printf()s which snuck in during the testing of the
last commit.
Approved by: re (kib)
Pointy-hat-to: adrian@
|
| 224541 |
31-Jul-2011 |
adrian |
Implement the 4KB split transaction workaround for Merlin (AR9280).
The AR9280 apparently has an issue with descriptors which straddle a page
boundary (4k). I'm not yet sure whether I should use PAGE_SIZE in the
calculations or whether I should use 4096; the reference code uses 4096.
This patch fiddles with descriptor allocation so a descriptor entry
doesn't straddle a 4kb address boundary. The descriptor memory allocation
is made larger to contain extra descriptors and then the descriptor
address is advanced to the next 4kb boundary where needed.
I've tested this both on Merlin (AR9280) and non-Merlin (in this case,
AR9160.)
Obtained from: Linux, Atheros
Approved by: re (kib)
|
| 224540 |
31-Jul-2011 |
adrian |
Fix typo!
Approved by: re (kib)
|
| 224539 |
31-Jul-2011 |
adrian |
Add extra flags for the radar event API.
(They're not used by any public code at the current time.)
Approved by: re (kib)
|
| 224538 |
31-Jul-2011 |
adrian |
Add some more phyerr bits.
Obtained from: Atheros
Approved by: re (kib)
|
| 224520 |
30-Jul-2011 |
adrian |
Fix incorrect error reporting during the dfs ioctl function.
Approved by: re (kib)
|
| 224519 |
30-Jul-2011 |
adrian |
Introduce the FRAC_5G EEPROM parameter.
This seems to indicate whether to program the NIC for fractional 5ghz
mode (ie, 5mhz spaced channels, rather than 10 or 20mhz spacing) or not.
The default (0) seems to mean "only program fractional mode if needed".
A different value (eg 1) seems to always enable fractional 5ghz mode
regardless of the frequency.
Obtained from: Atheros
Approved by: re (kib)
|
| 224518 |
30-Jul-2011 |
adrian |
Prepare for embedded use of the AR9285/AR9287.
Calibration/PCI data that's written to flash (rather than EEPROM attached
to the NIC) is typically already in host-endian. The existing checks
end up swapping 16 bit words incorrectly - the correct solution would be
to read the magic value and determine the EEPROM endianness from that.
(This is what Linux does.)
This doesn't completely enable embedded use of the AR9285/AR9287 -
notably, the EEPROM read methods need to be made generic and available
to all EEPROM drivers. I'll worry about that later.
Approved by: re (kib)
|
| 224517 |
30-Jul-2011 |
adrian |
Fix AR5416 radar parameter initialisation.
* I messed up the order of parameter true/false; oops!
* AR_PHY_RADAR_1 was being written at the wrong place, and was writing
potential garbage to the hardware.
Approved by: re (kib)
|
| 224515 |
30-Jul-2011 |
adrian |
Fix the initial calibration sample count when doing ADC calibrations.
Obtained from: Atheros
Approved by: re (kib)
|
| 224514 |
30-Jul-2011 |
adrian |
Fix ANI handling to work correctly when (trying) to receive radar errors.
* Teach the AR5212/AR5416 ANI code to use the RX filter methods, rather
than calling the RX filter routines directly.
* Make HAL_ANI_PRESENT and HAL_ANI_MODE unconditionally available,
regardless of whether ah_ani_function is masking it.
* (Mostly) fully disable ANI if interference mitigation is disabled.
When disabled, the ANI code doesn't touch any ANI/PHY registers,
leaving them the default value. This is in line with what the
Atheros reference driver does.
* Correctly set the ANI parameters during ANI reset, rather than
when ANI is enabled. In this way, if ANI is disabled or enabled
whilst the NIC is not active (and there's no current channel),
bogus parameters or a NULL pointer deference doesn't occur.
There's still some lingering issues - notably, the MIB events/interrupts
aren't fully disabled, so MIB interrupts still occur. I'll worry about
that later.
Approved by: re (kib)
|
| 224512 |
30-Jul-2011 |
adrian |
Bring over AR5416 specific RX filter get/set routines.
This in particular fixes radar PHY handling - on the AR5212
NIC, one enables the AR_PHY_ERR_RADAR bit in AR_PHY_ERR;
the AR5416 and later also needs a bit set in AR_RX_FILTER.
A follow-up commit is needed to convert the AR5416 ANI code
to use this particular method, as it's currently using the
AR5212 methods directly.
Obtained from: Atheros
Approved by: re (kib)
|
| 224510 |
30-Jul-2011 |
adrian |
I noticed that the Merlin NICs I had (AR9220, AR9280) never completed
the ADC calibrations if the NIC is in 5ghz 11a or 5ghz HT/20 modes.
I've been told that the dual-ADC is only engaged in turbo/40mhz modes.
Since Sowl (AR9160) seems to return valid-looking calibration data
in 5ghz 20MHz modes, I'm only disabling it for Merlin for now.
It may turn out I can disable it for all chipsets and only enable
it for 40MHz modes.
Approved by: re (kib)
|
| 224509 |
30-Jul-2011 |
adrian |
Fix the AR9280 initial AGC calibration code.
It looks like this was mixed up with the AR9285 calibration code.
This code is now more in line with what Linux ath9k and Atheros
reference drivers do.
Obtained from: Atheros
Approved by: re (kib)
|
| 224502 |
30-Jul-2011 |
adrian |
Reset the NIC if ANI is enabled or disabled.
Although this may not be what the original sysctl was designed to do,
it feels a bit more "expected".
Before, if ANI is disabled, the initial ANI parameters are still written
to the hardware, even if they're not enabled. "ANI enabled" would then
adjust the noise immunity parameters dynamically. Disabling ANI would
simply leave the existing noise immunity parameters where they are,
and disable the dynamic part.
The problem is that disabling ANI doesn't leave the hardware in
a consistent, predictable state - so asking a user to disable ANI
wouldn't actually reset the NIC to a consistent set of PHY signal
detection parameters, resulting in an unpredictable/unreliable outcome.
This makes it difficult to get reliable debugging information from
the user.
Approved by: re (kib)
|
| 224267 |
22-Jul-2011 |
adrian |
Implement a basic radar parameter API in the dfs_null module.
Since no actual radar data is ever handled, this won't
do anything. It's mostly here as a reference for those who
wish to experiment with radar detection.
Approved by: re (kib)
|
| 224245 |
21-Jul-2011 |
adrian |
This links in the ath dfs ioctl into the driver and defines the
ioctl interface for DFS modules to use.
Since there's no open source dfs code yet, this doesn't introduce any
operational changes.
Approved by: re (kib)
|
| 224244 |
21-Jul-2011 |
adrian |
Modify the radar API a little to be easier to "change" via run-time
tools.
* introduce pe_enabled, which (will) indicate whether the radar
detection stuff is enabled or not. Right now it's incorrectly
set, based on something previously written. I'll sort it out
later.
* Don't set HAL_PHYERR_PARAM_ENABLE in pe_relstep to say whether
radar detection is on.
* Return whether blockradar, fir128 and enmaxrssi is enabled.
* Change some of the phyerr params to be integers rather than
HAL_BOOL so they can be set to the NOPARAM value when the
setup function is called. This is in line with other radar
parameters.
* Add new configuration parameters for fir128, blockradar and
enmaxrssi, rather than defaulting to off, on and on respectively.
Approved by: re (kib)
|
| 224243 |
21-Jul-2011 |
adrian |
Break out the PLL setup into (mostly) per-chip methods, rather than
polluting the AR5416 code with later chipset support.
Note: ar9280InitPLL() supports Merlin (AR9280) and later (AR9285, AR9287.)
Submitted by: ssgriffonuser@gmail.com
Approved by: re (kib)
|
| 224242 |
21-Jul-2011 |
adrian |
This re-enables HT40 channels for use when DFS is enabled.
These should be disabled for the AR5416 in hostap/mesh/ibss mode,
as the AR5416 doesn't have support for radar detection on the
ext channel of a HT40 setup. Later chips do.
Approved by: re (kib)
|
| 224226 |
20-Jul-2011 |
adrian |
These two are ath_hal regulatory domain updates from the Atheros
reference driver.
* Australia should use FCC3_WORLD
* Add some new SKUs; these are just the EEPROM values and haven't been
fully defined yet. As such they won't affect anything.
Obtained from: Atheros
Approved by: re (kib)
|
| 224045 |
14-Jul-2011 |
adrian |
Add a missing check for the global ath_hal_debug.
This was removed accidentally when the per HAL instance
code was added, and not reverted when I added back the
global debug variable (for early chip setup debugging.)
|
| 223671 |
29-Jun-2011 |
adrian |
Fix a corner case in STA beacon processing when a CSA is received but
the AP doesn't transmit beacons.
If the AP requests a CSA (ie, a channel switch) and then enters CAC
(channel availability check) for 60 seconds, it doesn't send beacons
and it just listens for radar events (and other things which we don't
do yet.)
Now, ath_newstate() was not resetting the beacon timer config on
a transition to the RUN state when in STA mode - it was setting
sc_syncbeacon, which simply updates the beacon config from the
contents of the next received beacon.
This means the STA never generates beacon miss events.
If the AP goes into CAC for 60 seconds and recovers, the STA will
happily receive the first beacon and reconfigure timers.
But if it gets a radar event after that, it'll change channel
again, not notify the station that it's changed channel..
and since the station is happily waiting for the first beacon
to configure the beacon timer details from, it won't ever
generate a beacon miss interrupt and it'll sit there forever
(or until the AP appears on that channel once again.)
This change forces the last known beacon timer config to be
written to hardware on a transition from CSA->RUN in STA mode.
This forces bmiss events to occur and the STA will eventually
(after a handful of beacon miss events) begin scanning for
another access point.
|
| 223615 |
28-Jun-2011 |
adrian |
Make sure the extended regdomain word is initialised.
As with the AR9285, the AR9287 has a default word of 0x1F which means
all the various bits in that field are set on by default.
|
| 223568 |
26-Jun-2011 |
adrian |
Fix beacon transmission after a channel set.
The DFS code was tickling the channel set directly whilst going
through the state RUN -> CSA -> RUN. This only changed the channel;
it didn't go via ath_reset(). However in this driver, a channel
change always causes a chip reset, which resets the beacon timer
configuration and interrupt setup. This meant that data would go
out but as the beacon timers never fired, beacons would never
be queued.
The confusing part is that sometimes the state transition was
RUN -> SCAN -> CAC -> RUN (with CSA being in there sometimes);
going via SCAN would clear sc_beacons and thus the transition
to RUN would reprogram beacon transmission.
In case someone tries debugging why suspending a device currently
beaconing (versus just RX'ing beacons which is what occurs in STA
mode), add a silly comment which should hopefully land them at
this commit message. The call to ath_hal_reset() will be clearing
the beacon config and it may not be always reset.
|
| 223567 |
26-Jun-2011 |
adrian |
Add ATH_ENABLE_DFS which enables the DFS flag so the DFS code
can be tested.
This doesn't at all actually do radar detection! It's just
so developers who wish to test the net80211 DFS code can easily
do so. Without this flag, the DFS channels are never marked
DFS and thus the DFS stuff doesn't run.
|
| 223525 |
25-Jun-2011 |
adrian |
Commit missing piece from a couple days ago - re-add ath_hal_debug.
|
| 223524 |
25-Jun-2011 |
adrian |
Small fix to bring the non-debug definitions of HALDEBUG/HALDEBUG_G in line
with the debug definitions.
|
| 223474 |
23-Jun-2011 |
adrian |
add missing #define for the non-debug case.
|
| 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.
|
| 223465 |
23-Jun-2011 |
adrian |
Fix indenting issues introduced by the previous commit.
|
| 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
|
| 223032 |
13-Jun-2011 |
adrian |
Fix ath_ahb(4) bus attach and eeprom error handling.
Submitted by: Luiz Otavio O Souza <loos.br@gmail.com>
|
| 222821 |
07-Jun-2011 |
adrian |
Since HAL_PHYERR_* is used in the radar code, always include ah_desc.h.
|
| 222815 |
07-Jun-2011 |
adrian |
Flesh out a new HAL method to fetch the radar PHY error frame information.
For the AR5211/AR5212, this is apparently a one byte pulse duration
counter value. It is only coded up here for the AR5212 as I don't have
any AR5211-series hardware to test it on.
This information was extracted from the Madwifi DFS branch along with
some local additions.
Please note - all this does is extract out the radar event duration,
it in no way reflects the presence of a radar. Further code is needed
to take a set of radar events and filter them to extract out correct
radar pulse trains (and ignore other events.)
For further information, please see:
http://wiki.freebsd.org/dev/ath_hal%284%29/RadarDetection
This includes references to the relevant patents which describe what
is going on.
Obtained from: Madwifi
|
| 222707 |
05-Jun-2011 |
adrian |
Add a missing call to sync the DMAed buffer before the radar event data is extracted.
|
| 222672 |
04-Jun-2011 |
adrian |
Commit radar detection changes missed by my previous commit.
|
| 222668 |
04-Jun-2011 |
adrian |
A few changes to make radar detection implementable in a hal_dfs/
module.
* If sc->sc_dodfs is set to 1 by the ath_dfs_radar_enable(),
set the relevant rx filter bit to begin receiving radar PHY
errors. The HAL code already knows how to set the relevant
error mask register to enable radar events.
* Add a missing call to ath_dfs_radar_enable() after ath_hal_reset()
* change ath_dfs_process_phyerr() to take a const char *buf for now,
rather than a descriptor. This way it can get access to the packet
buffer contents.
|
| 222644 |
03-Jun-2011 |
adrian |
Bring over the relevant registers to use when implementing the quiet time
portion of 802.11h.
The AR5212 code has been brought over as a reference, it's currently
untested.
Obtained from: Atheros
|
| 222585 |
01-Jun-2011 |
adrian |
Flesh out the radar detection related operations for the ath driver.
This is in no way a complete DFS/radar detection implementation!
It merely creates an abstracted interface which allows for future
development of the DFS radar detection code.
Note: Net80211 already handles the bulk of the DFS machinery,
all we need to do here is figure out that a radar event has occured
and inform it as such. It then drives the DFS state engine for us.
The "null" DFS radar detection module is included by default;
it doesn't require a device line.
This commit:
* Adds a simple abstracted layer for radar detection state -
sys/dev/ath/ath_dfs/;
* Implements a null DFS module which doesn't do anything;
(ie, implements the exact behaviour at the moment);
* Adds hooks to the ath driver to process received radar events
and gives the DFS module a chance to determine whether
a radar has been detected.
Obtained from: Atheros
|
| 222584 |
01-Jun-2011 |
adrian |
Add some missing DFS chipset functionality to the FreeBSD HAL.
Please note - this doesn't in any way constitute a full DFS
implementation, it merely adds the relevant capability bits and
radar detection threshold register access.
The particulars:
* Add new capability bits outlining what the DFS capabilities
are of the various chipsets.
* Add HAL methods to set and get the radar related register values.
* Add AR5212 and AR5416+ DFS radar related register value
routines.
* Add a missing HAL phy error code that's related to radar event
processing.
* Add HAL_PHYERR_PARAM, a data type that encapsulates the radar
register values.
The AR5212 routines are just for completeness. The AR5416 routines
are a super-set of those; I may later on do a drive-by pass to
tidy up duplicate code.
Obtained from: Linux, Atheros
|
| 222498 |
30-May-2011 |
adrian |
Enable setting the short-GI bit when TX'ing HT rates but only if the
hardware supports it.
Since ni->ni_htcap in hostap mode is what the remote end has advertised,
not what has been negotiated/decided, we need to check ourselves what
the current channel width is and what the hardware supports before
enabling short-GI.
It's important that short-GI isn't enabled when it isn't negotiated
and when the hardware doesn't support it (ie, short-gi for 20mhz channels
on any chip < AR9287.)
I've quickly verified this on the AR9285 in 11n mode.
|
| 222497 |
30-May-2011 |
adrian |
Set default A-MPDU density/size.
|
| 222432 |
29-May-2011 |
adrian |
Teach if_ath about devices which have short-GI in 20MHz channel modes.
This has been disabled until now because there hasn't been any supported
device which has this feature. Since the AR9287 is the first device to
support it, and since now the HAL has functional AR9287+11n support,
flip this on.
|
| 222424 |
28-May-2011 |
adrian |
Fix AR9287 operation when >1 TX chain is enabled.
I didn't pick this up with the initial commit because I was only testing
with 11bg.
|
| 222324 |
26-May-2011 |
adrian |
Fix a macro name - it's currently unused in this file however, but
keep it consistent with ar9280.c.
|
| 222323 |
26-May-2011 |
adrian |
Revert this erroneous commit and re-disable the AR9285 combined antenna
diversity.
|
| 222316 |
26-May-2011 |
adrian |
Remove the three-chain scaled power check for the AR9287 - it isn't
needed.
|
| 222315 |
26-May-2011 |
adrian |
Make sure only two chains are calibrated for the AR9287.
|
| 222314 |
26-May-2011 |
adrian |
Add some open-loop TX power debugging for AR9287.
|
| 222312 |
26-May-2011 |
adrian |
Bring over the AR5416 per-rate TX power code, modified to use the
AR9287 EEPROM layout.
The AR9287 only supports 2ghz, so I've removed the 5ghz code (but left
the 5ghz edge flags in there for now) and hard-coded the 2ghz-only
path.
Whilst I'm there, fix a typo (ar9285->ar9287.)
This meets basic TX throughput testing - iperf TX tests == 27-28mbit in 11g,
matching the rest of my 11g kit.
|
| 222310 |
26-May-2011 |
adrian |
Flesh out ar9287SetTransmitPower() based on the AR9285 routine.
Hard-code the per-rate TX power at 5dBm for now so testing can be done.
This passes initial TX testing in 11g mode (but, obviously, at 5dBm.)
|
| 222308 |
26-May-2011 |
adrian |
Flesh out the TX power calibration for the AR9287.
I'm assuming for now that the AR9287 is only open-loop TX power control
(as mine is) so I've hard-coded the attach path to fail if the NIC is
not open-loop.
This greatly simplifies the TX calibration path and the amount of code
which needs to be ported over.
This still isn't complete - the rate calculation code still needs to be
ported and it all needs to be glued together.
Obtained from: Linux ath9k
|
| 222305 |
26-May-2011 |
adrian |
Add the AR9287 chip identification string.
|
| 222303 |
26-May-2011 |
adrian |
Fix a bad merge from a previous commit.
|
| 222302 |
26-May-2011 |
adrian |
Merlin -> Kiwi
|
| 222301 |
26-May-2011 |
adrian |
Bring over my AR9287 work in progress.
It isn't linked into the build because it's missing the TX power
and PDADC programming code.
This code is mostly based on the ath9k codebase, compared against
the Atheros codebase as appropriate.
What's implemented:
* probe/attach
* EEPROM board value programming
* RX initial calibration
* radio channel programming
* general MAC / baseband setup
* async fifo setup
* open-loop tx power calibration
What's missing before it can be enabled by default:
* TX power / calibration setting code
* closed-loop tx power calibration routines
* TSF2 handling
* generic timer support from ath9k
Obtained from: Atheros, ath9k
|
| 222300 |
26-May-2011 |
adrian |
AR9287 prep work:
* Add PCI/PCIE devids
* Add AR9287/Kiwi version check macros
* AR_SREV_9287 -> AR_SREV_KIWI
Obtained from: Atheros, ath9k
|
| 222299 |
26-May-2011 |
adrian |
Add temp sense to the EEPROM variable list;
Export the temperature sense variables to ah_eeprom_9287.c
|
| 222277 |
25-May-2011 |
adrian |
The current ANI capability information uses a different set of
values for the commands, compared to the internal command values
(HAL_ANI_CMD.)
My eventual aim is to make the HAL_ANI_CMD internal enum match
the public API and then remove all this messiness.
This now allows HAL_CAP_INTMIT users to use a public HAL_CAP_INTMIT_
enum rather than magic constants.
The only magic constants currently used by if_ath are "enable" and
"present". Some local tools of mine allow for direct, manual fiddling
of the ANI variables and I'll convert these to use the public enum API
before I commit them.
|
| 222276 |
25-May-2011 |
adrian |
Tidy up the ANI API in preparation for looking to expose some more
of the ANI statistics and committing some tools which use these.
* Change HAL_ANI_* commands _back_ to be numerical, rather than a
bitmap;
* modify access to the ANI control bitmap to convert a command to
a bitmap;
* Fix the ANI noise immunity fiddling for CCK errors - it wasn't
checking whether noise immunity was disabled or not.
|
| 222265 |
24-May-2011 |
adrian |
The ANI control for the AR5416 and later chips was calling ar5212AniControl(),
which did AR5212 specific initialisation. This would cause some slight
silliness when enabling/disabling ANI.
Just to be completely correct - and to ensure the phy error mask/RX filter
register isn't incorrectly played with - make the ANI control function a
method, have it set appropriately for AR5212/AR5416, and call that from the
ANI control interface.
|
| 222241 |
24-May-2011 |
adrian |
Use the new per-series antenna and TPC definitions when setting ctl8->11.
This should hopefully make it clearer to developers what is going on
and when TPC is being hacked on, make it obvious why it isn't working for
series 1, 2, 3.
I won't flip on setting TX power for TX series 1, 2, 3 until I've done
some further testing with Kite to ensure it doesn't break anything.
(Before people ask - yes, TPC is only needed for 5ghz regdomains and
yes, Kite is a 2.4ghz only chip, but there are potential use cases
for 2ghz TPC. I just need to sit down and ensure it's supported and
functional.)
|
| 222240 |
24-May-2011 |
adrian |
Add in descriptions for TX descriptor fields ctl8-11 - these fields
control the antenna control bits for the four TX series and the
TPC settings for TX series 1, 2, 3.
The specifics:
* The TPC setting for TX series 0 is handled in ctl0.
* TPC is currently disabled, so the per-packet TX power is
set via the global per-rate TX power register, not per packet.
* The antenna control bits don't matter for AR5416 and later
so they should stay 0 (which they currently do); they may
be set for Kite but as there's no TX diversity supported
at the moment (it requires the NIC to be built with an
external antenna switch, matching how antenna diversity
is done on legacy NICs), so again keep them 0.
This is in preparation for supporting per-rate TPC on the
AR5416 and later. The Kite (and soon to come Kiwi) code
sets ctl8-11 to 0x0, which doesn't have any effect at
the moment. When TPC is enabled it would result in the
second, third and fourth TX series attmpts to be done with
a TX power of 0. This commit doesn't change that; it'll
be followed up with some commits to properly set the TPC
registers appropriately.
|
| 222157 |
21-May-2011 |
adrian |
The Merlin analog register bank is from 0x7800 -> 0x78fc; fix the code
to reflect this.
|
| 222054 |
18-May-2011 |
adrian |
This isn't needed any longer, it's defined in ah_internal.h.
|
| 222049 |
18-May-2011 |
adrian |
Modify the sample rate control algorithm to only select/sample HT
rates for HT nodes.
|
| 222031 |
17-May-2011 |
adrian |
Fix the debugging code path to correctly support HAL_DEBUG_UNMASKABLE.
|
| 222027 |
17-May-2011 |
adrian |
Fix case, introduced in my previous commit.
Pointy hat goes to: adrian, for having multiple build screens
open and checking the wrong one.
|
| 222021 |
17-May-2011 |
adrian |
Use the halMcastKeySrchSupport capability bit to selectively enable/disable
the multicast key search support for AR5212, AR5416 and later.
The general HAL routine ath_hal_getcapability() implement checking this
but it's overridden by a check in ar5212_misc:ar5212GetCapability().
This restores the later functionality in case it's found to be broken
in any of the 11n chipsets.
|
| 222020 |
17-May-2011 |
adrian |
Set this HAL capabilities flag correctly even though it isn't currently
being used.
|
| 221965 |
15-May-2011 |
adrian |
* Add some more TX descriptor error counters; this'll be helpful when
implementing TX aggregation
* Whilst I'm there, comment some RX error counters
|
| 221944 |
15-May-2011 |
adrian |
Fix NF calibration breakage introduced by me in a past commit.
Since the returned NF will be -ve, checking for <= 0 is not good
enough. For now, check whether it equals 0 or -1; a future commit
will tidy this mess up and have it return HAL_BOOL instead.
|
| 221897 |
14-May-2011 |
adrian |
Fix the Merlin 5ghz fast-clock EEPROM fetch to return the correct value.
The eeprom Get method should return HAL_OK if fastclock is enabled in the
EEPROM. It was returning the opposite of what it should have.
Submitted by: Matthew Fleming <mdf356@gmail.com>
|
| 221896 |
14-May-2011 |
adrian |
Fix the eeprom set API method to return HAL_STATUS.
The code assumed it could return HAL_OK, HAL_EINVAL and other
HAL_STATUS types; so it shouldn't be declared as returning HAL_BOOL.
This commit was brought to you by the Clang compiler.
Submitted by: Matthew Fleming <mdf356@gmail.com>
|
| 221888 |
14-May-2011 |
adrian |
Import initial EEPROM code for Kite (AR9287).
I've tested this locally and it does indeed read and attach to an AR9287
EEPROM. But a lot more code needs to be ported over to the HAL before
the AR9287 is functional.
I'm importing this separate from the rest of the codebase (and unlinked from
the build for now) in case someone wishes to begin fiddling with porting
the rest of the code over from Linux ath9k.
Obtained from: Linux ath9k
|
| 221878 |
14-May-2011 |
adrian |
When disabling RIFS for Sowl (AR9160) and Howl (AR9130), make sure RIFS
is totally disabled.
The Atheros HAL code does this for Sowl/Howl but not for Owl (AR5416) where
RIFS is disabled by default.
This seems to quieten the occasional baseband hang I've been seeing with
the AR9160 in STA mode under constant heavy traffic load.
Obtained from: Atheros
|
| 221876 |
14-May-2011 |
adrian |
Major fix: when doing open-loop TX power calibration, adjust
the correct CCK rates rather than adjusting the first handful.
This may have affected some AR9280 based NICs.
Minor fix: merlin check update
|
| 221875 |
14-May-2011 |
adrian |
Fixes from the Atheros HAL - formatting; update Merlin checks to be consistent.
Nothing functional should change with this commit.
|
| 221869 |
14-May-2011 |
attilio |
Disconnect sun4v architecture from the three.
Some files keep the SUN4V tags as a code reference, for the future,
if any rewamped sun4v support wants to be added again.
Reviewed by: marius
Tested by: sbruno
Approved by: re
|
| 221868 |
14-May-2011 |
adrian |
Even though initial calibrations aren't done (yet), add this so we're
consistent with the Atheros HAL.
|
| 221837 |
13-May-2011 |
adrian |
Only do open loop power control and temperature compensation
for the AR9280 based NICs if it's actually enabled.
Some of the OLC code was erroneously called during setup
and calibration. This may have caused some incorrect behaviour.
|
| 221834 |
13-May-2011 |
adrian |
Remove duplicate code - add a function which calculates the ratesArray[]
table which contains the per-rate target TX power.
This code is shared between the v14 eeprom board setup (AR5416, AR9160,
AR9280) and will also be used by the upcoming Kite (AR9287) support.
|
| 221833 |
13-May-2011 |
adrian |
Some diversity changes relating to AR9285.
* grab the main, alt and selected LNA config
* add some optional / disabled logging code
* add a check to reject packets with an invalid main rssi too,
in case the alt is the active receive chain and main is -ve.
Note: The software-controlled combined diversity code is still disabled.
|
| 221811 |
12-May-2011 |
adrian |
Now that the devices with functioning ps-poll hardware support have
been enumerated (merlin and later), flick this on.
|
| 221806 |
12-May-2011 |
adrian |
Break out the AR9285 analog registers from ar5416/ar5416phy.h and put
them in a new header file, ar9002/ar9285_an.h.
Shuffle the AR9280 analog registers in ar5416/ar541phy.h into a contiguous
spot.
|
| 221801 |
12-May-2011 |
adrian |
Fix the half/quater rate PLL setup for AR5416, AR9160 and
(beta?) AR9280 chips.
Note: This doesn't "fix" half/quarter rate support for these
chips; it merely fixes an oversight.
Obtained from: Atheros
|
| 221800 |
12-May-2011 |
adrian |
Fixes from Atheros:
* If AR9130, give the chip extra time to reset
* If AR5416, don't shutdown the chip during reset
|
| 221779 |
11-May-2011 |
adrian |
Make the NF calibration logic (hopefully!) more resistive to noisy
environments.
In setups where NF calibration can take a while, don't load the CCA
and kick off a new NF calibration if the previous one hasn't yet
completed. This shouldn't happen unless the environment is noisy but
those exist (hi phk!).
Here, if the previous NF hasn't completed when ar5416LoadNf() is run
(which reads the NF), it skips updating the history buffer, loading
the NF CCA array and kicking off the next NF cal. It's hoped it'll
occur in the next long calibration interval.
Obtained from: Atheros, ath9k, my local HAL
|
| 221778 |
11-May-2011 |
adrian |
Always log if the NF CCA load fails; so users with debugging enabled
can see they're likely in a very noisy environment.
|
| 221777 |
11-May-2011 |
adrian |
Make sure the chip is awake before writing to it to finally detach
it.
Obtained from: Atheros
|
| 221776 |
11-May-2011 |
adrian |
Add a new flag - HAL_DEBUG_UNMASKABLE - which always logs a debug message
(when debug is enabled) no matter what.
|
| 221775 |
11-May-2011 |
adrian |
Remove unused variable
|
| 221773 |
11-May-2011 |
adrian |
Remove the initial NF completion check.
This is taking quite a while for some people in some situations
(eg AR5418 in phk's Abusive Radio Environment).
Instead, the rest of the calibration related code should
ensure that a NF calibration has occured before reading NF
values and kicking off another NF calibration.
The channel should also likely be marked as "noisy" (CWINT)
if the NF calibration takes too long.
|
| 221772 |
11-May-2011 |
adrian |
Remove a now unneeded comment..
|
| 221766 |
11-May-2011 |
adrian |
Restore the RSSI threshold after writing the board values.
This would be overwritten by the board initvals written in ah->writeIni().
|
| 221722 |
10-May-2011 |
adrian |
AR9285 (Kite) fixes.
* Correct some of the silicon revision checks to match what
the Atheros HAL does. (See [1] below.)
* Move the PA cal and init cal method assignment to -after-
the mac version/revision IDs are stored. The AR9285 init
cal was never being called.
* Enable ANI.
Note Kite 1.0 and 1.1 were prototypes that shouldn't be seen
in the wild. Linux ath9k simply removed the prototype code from
their codebase. I'm going to leave it in there for now but
make it conditionally compilable in the future.
Obtained from: Atheros
|
| 221702 |
09-May-2011 |
adrian |
Disable diversity combining support until I can get a firm answer
from Atheros as to what/when this is supposed to be enabled.
Using the default RX fast diversity settings seems to help quite
a bit.
Whilst I'm here, change the prototype to return HAL_BOOL rather than int.
|
| 221701 |
09-May-2011 |
adrian |
Fix a regression I introduced - only swap analog chains if the RX chainmask
is 0x5.
|
| 221700 |
09-May-2011 |
adrian |
Disable TX STBC - it isn't used for now, but it isn't supported on Kite.
|
| 221694 |
09-May-2011 |
adrian |
Import some initial Kite fixed diversity code from Atheros.
For now, the diversity settings are controlled by 'txantenna',
-not- rxantenna. This is because the earlier chipsets had
controllable TX diversity; the RX antenna setting twiddles
the default antenna register. I'll try sort that stuff out at
some point.
Call the antenna switch function from the board setup function
so scans, channel changes, mode changes, etc don't set the
diversity back to a default state too far from what's intended.
Things to todo:
* Squirrel away the last antenna diversity/combining parameters
and restore them during board setup if HAL_ANT_VARIABLE is
defined. That way scans, etc don't reset the diversity settings.
* Add some more public facing statistics, rather than what's
simply logged under HAL_DEBUG_DIVERSITY.
For now, the fixed antenna settings behave better than variable
settings for me. I have some further fiddling to do..
Obtained from: Atheros
|
| 221693 |
09-May-2011 |
adrian |
Remove an un-needed PA cal call here.
|
| 221667 |
08-May-2011 |
adrian |
Fix the 5ghz fast clock logic.
The macro which I incorrectly copied into ah_internal.h assumed
that it'd be called with an AR_SREV_MERLIN_20() check to ensure
it was only enabled for Merlin (AR9280) silicon revision 2.0 or
later.
Trouble is, the 5GHz fast clock EEPROM flag is only valid for
EEPROM revision 16 or greater; it's assumed to be enabled
by default for Merlin rev >= 2.0. This meant it'd be incorrectly
set for AR5416 and AR9160 in 5GHz mode.
This would have affected non-default clock timings such as SIFS,
ACK and slot time. The incorrect slot time was very likely wrong
for 5ghz mode.
|
| 221666 |
08-May-2011 |
adrian |
* Add AR_SREV_KITE macro for later use
* Modify AR_SREV_MERLIN_20() to match the Atheros/Linux ath9k behaviour -
its supposed to match Merlin 2.0 and later Merlin chips.
AR_SREV_MERLIN_20_OR_LATER() matches AR9280 2.0 and later chips
(AR9285, AR9287, etc.)
|
| 221622 |
08-May-2011 |
adrian |
These EEPROM bits actually defined whether HT/20 and HT/40 support
for the given channel is available.
It isn't used yet; ar5416GetWirelessModes() needs to be taught
about this rather than assuming HT20/HT40 is available.
|
| 221620 |
08-May-2011 |
adrian |
Fiddle with the PLL initialisation order to match ath9k/Atheros HAL.
This seems to make the AR9160 behave better during heavy scanning,
where before it'd hang and require a hard reset to recover.
Obtained From: Linux ath9k, Atheros
|
| 221618 |
08-May-2011 |
adrian |
Properly indent the WAR code i pasted in from ath9k a few months
ago.
|
| 221617 |
08-May-2011 |
adrian |
* Add in a comment about ar5416InitUserSettings() potentially
modifying AR_DIAG_SW.
There's a hardware workaround which sets disabling some errors
early at startup and clears said bits before the PCU begins
receiving - it does this to avoid RX descriptor status errors.
It's possible these bits aren't being completely properly twiddled
in all instances; but in particular if the diag_reg HAL variable
is set it won't be setting these bits correctly. I'll review this
at some point.
* Disable multicast search on mac address and key id - the driver
doesn't use it at the moment and thus adhoc may be broken for
merlin and later.
* Change this to be for Merlin 1.0 (which from what I understand
wasn't ever publicly released) to be more correct.
|
| 221616 |
08-May-2011 |
adrian |
Fiddle with the AR5416 1.0 chainmask setup.
Apparently all three RX chains need to be enabled before initial calibration
is done, even if only two are configured.
Reorder the alt chain swap bit to match what the Atheros HAL is doing.
Obtained From: ath9k, Atheros
|
| 221608 |
07-May-2011 |
adrian |
Fix the IS_5416 checks to actually work correctly.
I've verified that my AR5416 revision 2.2 (minor revision 0x0A) now
matches the correct checks.
|
| 221603 |
07-May-2011 |
adrian |
Do a HAL capabilities sync pass based on the Atheros HAL.
* Shuffle some of the capability numbers around to match the
Atheros HAL capability IDs, just for consistency.
* Add some new capabilities to FreeBSD from the Atheros
HAL which will be be shortly used when new chipsets are added
(HAL SGI-20 support is for Kiwi/AR9287 support); for
TX aggregation (MBSSID aggregate support, WDS aggregation
support); CST/GTT support for carrier sense/TX timeout.
|
| 221600 |
07-May-2011 |
adrian |
Update the ext channel cycpwr threshold 1 register for the extension
channel when the channel is HT/40.
The new ANI code (primarily for the AR9300/AR9400) in ath9k sets this
register but the ANI code for the previous 11n chips didn't set this.
Unlike ath9k, only set this for HT/40 channels.
Obtained From: ath9k
|
| 221596 |
07-May-2011 |
adrian |
Read in the extended regulatory domain flags so future code can use them.
These describe FCC/Japan channel and DFS behaviour.
The AR9285 and later chips don't set these bits in the eeprom, the correct
behaviour is to just assume all five bits are enabled.
|
| 221582 |
07-May-2011 |
adrian |
Instead of returning an unknown mac/bb signature, just return 0.
|
| 221581 |
07-May-2011 |
adrian |
Add some comments about which HAL capabilities are currently FreeBSD
specific.
The Atheros HAL and FreeBSD HAL share the same capabilities up
until HAL_CAP_11D, where things begin to diverge.
I'll look at tidying these up soon.
Obtained from: Atheros
|
| 221580 |
07-May-2011 |
adrian |
Some BB hang changes:
* Add Howl (ar9130) to the list of chips that have DFS/BB/MAC hangs
* Don't treat unknown BB hangs as fatal; ath9k/Atheros HAL don't
treat it as such.
* Add HAL_DEBUG_DFS to the debug fields in ath_hal/ah_debug.h
The BB hang check simply loops over an observation register checking
for a stuck state engine, but it can happen under high traffic
conditions. Ath9k and the Atheros HAL simply log a debug message and
continue.
Private to FreeBSD:
* Add HAL_DEBUG_HANG to the debug fields
* Change the hang debugging to HAL_DEBUG_HANG rather than HAL_DEBUG_DFS
like in the Atheros HAL.
Obtained from: Atheros
|
| 221574 |
07-May-2011 |
adrian |
Change AR_SREV_OWL_{X}_OR_LATER to AR_SREV_5416_{X}_OR_LATER.
For now, these are equivalent macros. AR_SREV_OWL{X}_OR_LATER
will later change to exclude Howl (AR9130) in line with what
the Atheros HAL does.
This should not functionally change anything.
Obtained from: Atheros
|
| 221573 |
07-May-2011 |
adrian |
Fix the OWL revision checks.
A quick story, which is partially documented in the commit.
The silicon revision in Linux ath9k and the Atheros HAL use an
AR_SREV_REVISION mask of 0x07.
FreeBSD's HAL uses the AR5212 AR_SREV_REVISION mask of 0x0F.
Thus the OWL silicon revisions were coming through as 0xA, 0xB,
0xC, rather than 0x0, 0x1 and 0x2.
My ath9k-sourced AR_SREV_OWL_<X> macros were thus using the wrong
silicon revision values and wouldn't correctly match.
This commit does a few things:
* Change the AR_SREV_OWL_<x> macros to use the AR_SREV_REVISION_OWL_*
values, not AR_XSREV_REVISION_OWL macros;
* Disable AR_XSREV_REVISION_OWL_* values;
* Modify the IS_5416 to properly check the MAC is OWL, rather than
potentially matching on non-OWL revisions (which shouldn't happen
unless there's a silicon revision of higher than 0x9 in a later
chip..)
* Add a couple more macros from the Atheros HAL for compatibility.
The main difference now is that the Atheros HAL defines
AR_SREV_OWL_{20,22}_OR_LATER subtly differently - it fails on all HOWL
silicon. The AR_SREV_5416_*_OR_LATER macros match on the relevant OWL
version -and- all HOWL versions, along with subsequent versions.
A subsequent commit is going to migrate the uses of AR_SREV_OWL_X_OR_LATER
to AR_SREV_5416_X_OR_LATER to match what's going on in the Atheros HAL.
There's only two uses of AR_SREV_OWL_X_OR_LATER which currently don't
apply to FreeBSD but it may do in the future.
Yes, it's all confusing!
|
| 221535 |
06-May-2011 |
adrian |
Add a function which enables or disables RX RIFS searching, and migrate
the code which does this into it.
|
| 221488 |
05-May-2011 |
adrian |
Don't perform NF calibration for radio chains which aren't in use:
Quoting the ath9k commit message:
At present the noise floor calibration is processed in supported
control and extension chains rather than required chains.
Unnccesarily doing nfcal in all supported chains leads to
invalid nf readings on extn chains and these invalid values
got updated into history buffer. While loading those values
from history buffer is moving the chip to deaf state.
This issue was observed in AR9002/AR9003 chips while doing
associate/dissociate in HT40 mode and interface up/down
in iterative manner. After some iterations, the chip was moved
to deaf state. Somehow the pci devices are recovered by poll work
after chip reset. Raading the nf values in all supported extension chains
when the hw is not yet configured in HT40 mode results invalid values.
Reference: https://patchwork.kernel.org/patch/753862/
Obtained from: Linux ath9k
|
| 221483 |
05-May-2011 |
adrian |
Another Howl (AR9130) fix.
I haven't seen a 5ghz AR9130 based board yet though!
Obtained from: Atheros
|
| 221480 |
05-May-2011 |
adrian |
Fix up the chipset checks for the AR5416 and later silicon.
The checks should function as follows:
* AR_SREV_<silicon> : check macVersion matches that version id
* AR_SREV_<silicon>_<revision> : check macVersion and macRevision match
the version / revision respectively
* AR_SREV_<silicon>_<revision>_OR_LATER: check that
+ if the chip silicon version == macVersion, enforce revision >= macRevision
+ if the chip silicon version > macVersion, allow it.
For example, AR_SREV_MERLIN() only matches AR9280 (any revision),
AR_SREV_MERLIN_10() would only match AR9280 version 1.0, but
AR_SREV_MERLIN_20_OR_LATER() matches AR9280 version >= 2.0 _AND_
any subsequent MAC (So AR9285, AR9287, etc.)
The specific fixes which may impact users:
* if there is Merlin hardware > revision 2.0, it'll now be correctly
matched by AR_SREV_MERLIN_20_OR_LATER() - the older code simply
would match on either Merlin 2.0 or a subsequent MAC (AR9285, AR9287, etc.)
* Kite version 1.1/1.2 should now correctly match. As these macros
are used in the AR9285 reset/attach path, and it's assumed that the
hardware is kite anyway, the behaviour shouldn't change. It'll only
change if these macros are used in other codepaths shared with
older silicon.
Obtained from: Linux ath9k, Atheros
|
| 221479 |
05-May-2011 |
adrian |
Import some HOWL (AR9130) related fixes from Atheros.
Obtained from: Atheros
|
| 221427 |
04-May-2011 |
adrian |
Remove this useless bit of code for Kite. The RIFS register value is overriden
by the initvals, so disabling RIFS before calling writeIni() effectively does
nothing.
|
| 221210 |
29-Apr-2011 |
adrian |
Cosmetic changes to fit 80 character screen width.
|
| 221206 |
29-Apr-2011 |
adrian |
Remove some holdovers from the AR5212 origin of this code.
These aren't relevant here.
|
| 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.
|
| 221019 |
25-Apr-2011 |
adrian |
Wrap the MIMO stuff in #ifdef AH_SUPPORT_AR5416, as the channel
state doesn't have MIMO stuff in it by default.
|
| 220990 |
24-Apr-2011 |
adrian |
Break out the PLL setup into an overridable method.
The only method right now is ar5416InitPLL() which handles multiple
chipsets; this can now be overridden by newer chipset HAL code.
|
| 220989 |
24-Apr-2011 |
adrian |
Use the refactored ar5416WriteTxPowerRateRegisters() call in the ar9285 code.
|
| 220988 |
24-Apr-2011 |
adrian |
Eliminate code duplication between AR5416/AR9160/AR9280 and AR9285.
Writing the TX power registers is the same between all of these chips
and later NICs (AR9287, AR9271 USB, etc.) so this will reduce code
duplication when those NICs are added to the HAL.
|
| 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.
|
| 220955 |
22-Apr-2011 |
adrian |
Fix the merlin LNA configuration code - these are bit flags, not raw values to be
written into the registers.
|
| 220947 |
22-Apr-2011 |
adrian |
The second regdomain word is a set of bitflags describing
regulatory domain behaviour. Document what the v14 EEPROM
flags are.
|
| 220946 |
22-Apr-2011 |
adrian |
Bring over a pdadc calibration fix from ath9k - unused power detector
gain values should be 58, not the previous values.
Obtained From: linux ath9k
|
| 220784 |
18-Apr-2011 |
adrian |
For now, only enable GTT. CST is firing very frequently during local tests;
I'll figure out what's going on before re-enabling this as it does add
to the interrupt load.
|
| 220782 |
18-Apr-2011 |
adrian |
Add TX carrier sense timeout statistics.
|
| 220780 |
18-Apr-2011 |
adrian |
Bump pad, I'm adding more statistics.
|
| 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.
|
| 220772 |
18-Apr-2011 |
adrian |
Add global TX timeout handling.
The global TX timeout counter increments whenever a frame is ready
to be transmitted and the medium is busy.
|
| 220738 |
17-Apr-2011 |
adrian |
Mark the PHY as inactive before the chip is reset.
It's also marked inactive by the initvals, and enabled after
the baseband/PLL has been configured, but before the RF
registers have been programmed.
The origin and reason for this particular change is currently unknown.
Obtained from: Linux ath9k
|
| 220722 |
16-Apr-2011 |
adrian |
Don't do Kite antenna switch selection this way (for now); antenna
diversity is done elsewhere now.
|
| 220718 |
16-Apr-2011 |
adrian |
Disable classic-style fast diversity on the AR5416 and later.
Antenna diversity on the >= AR5416 is implemented differently than the
AR5212 and previous chips. So for now, and not to confuse things, just
disable it for now.
|
| 220713 |
16-Apr-2011 |
adrian |
Remove some duplicate code from the AR9285 TX power configuration path.
|
| 220601 |
13-Apr-2011 |
adrian |
Add in the AR9285 (Kite) diversity to if_ath, enabling TX/RX antenna
diversity.
This is bit dirty and likely should be revised at a later date,
with an eye to unifying/tidying up the whole diversity setup
and allowing developers to do "tricky stuff" as they desire.
For now, this works.
|
| 220600 |
13-Apr-2011 |
adrian |
Add in the last bit of the HAL support for Kite diversity.
* add a new method, specifically for doing per-RX packet
antenna diversity
* set that HAL method only if it's Kite and a Kite chip that
does diversity.
|
| 220599 |
13-Apr-2011 |
adrian |
More kite diversity related changes.
* add a diversity flag to the HAL debugging section
* add a check to make sure the kite diversity code doesn't run
on boards that don't require it, as not all Kite chips will
implement it.
* add some debug statements when the diversity code makes
changes to the antenna diversity/combining setup.
|
| 220598 |
13-Apr-2011 |
adrian |
Change this to be less noisy.
|
| 220593 |
13-Apr-2011 |
adrian |
Bring over the antenna diversity logic support for Kite.
Again, this is just the code ported from ath9k and included in the build,
it isn't yet enabled.
|
| 220590 |
13-Apr-2011 |
adrian |
Port over a TX gain fix from ath9k specific to the AR9285 (Kite) and AR9271.
Note: this HAL currently only supports the AR9285.
From Linux ath9k:
The problem is that when the attenuation is increased,
the rate will start to drop from MCS7 -> MCS6, and finally
will see MCS1 -> CCK_11Mbps. When the rate is changed b/w
CCK and OFDM, it will use register desired_scale to calculate
how much tx gain need to change.
The output power with the same tx gain for CCK and OFDM modulated
signals are different. This difference is constant for AR9280
but not AR9285/AR9271. It has different PA architecture
a constant. So it should be calibrated against this PA
characteristic.
The driver has to read the calibrated values from EEPROM and set
the tx power registers accordingly.
|
| 220589 |
13-Apr-2011 |
adrian |
Add new fields to the v4k EEPROM modal header.
|
| 220588 |
13-Apr-2011 |
adrian |
Add OS_REG_RMW, which mirrors ath9k's REG_RMW.
This macro does a read-modify-write pass with register bits to set and clear.
|
| 220587 |
13-Apr-2011 |
adrian |
Add the initial AR9285 PHY glue for supporting antenna diversity.
This code isn't currently used anywhere; it's just linked into the build.
|
| 220539 |
11-Apr-2011 |
adrian |
De-dup the ar5416 rates array definition.
|
| 220444 |
08-Apr-2011 |
adrian |
Fix the completely wrong types I used in the previous commit.
|
| 220443 |
08-Apr-2011 |
adrian |
Begin fleshing out a public HAL routine to export the per-chain
ctl/ext noise floor values.
This routine doesn't check to see whether the radio is MIMO
capable - instead, it simply returns either the raw values,
the "nominal" values if the raw values aren't yet available
or are invalid, or '0' values if there's no valid channel/
no valid MIMO values.
Callers are expected to verify the radio is a MIMO radio
(which for now means it's an 11n chipset, there are non-11n
MIMO chipsets out there but I don't think we support them,
at least in MIMO mode) before exporting the MIMO values.
|
| 220442 |
08-Apr-2011 |
adrian |
Export the per-chain ctl/ext noise floor values, raw and uncut, to the
upper-level HAL.
Right now the per-chain noise floor values aren't used anywhere in
the upper-level HAL, so the driver currently has no real reference
to compare the per-chain RSSI values to.
This is needed before per-chain RSSI values (for ctl and ext radios)
are can be thrown upstairs to the net80211 code.
|
| 220438 |
08-Apr-2011 |
adrian |
Extend the RX descriptor block to include two more EVM words.
This will be needed for later AR93xx/AR94xx 3-stream devices.
|
| 220423 |
07-Apr-2011 |
adrian |
Add some more OS_MARK probes to the RX DMA setup/teardown code path.
I'm trying to debug the RX DMA path and help the ath9k guys with
"RX dma abort stuck" issue that both our drivers have.
|
| 220367 |
05-Apr-2011 |
adrian |
Make the alq log path tunable
|
| 220360 |
05-Apr-2011 |
adrian |
The xpaBiasLvlFreq[] fields in the modal header also need swapping
when the EEPROM contents are byte-swapped.
|
| 220325 |
04-Apr-2011 |
adrian |
Commit missing bits from the last commit:
* add the hal capability flag
* make sure its disabled for the ar9280/ar9285.
|
| 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.
|
| 220323 |
04-Apr-2011 |
adrian |
At least set the coverage class value here; worry about populating the
register values at a later date.
|
| 220302 |
03-Apr-2011 |
adrian |
I missed committing this last time - it's needed for the 5ghz fast clock calculation.
|
| 220298 |
03-Apr-2011 |
adrian |
Add in the clock timing calculation when Merlin is using the 5ghz fast clock.
This is a 44mhz clock, not a 40mhz clock like normal for 5ghz operation.
|
| 220294 |
03-Apr-2011 |
adrian |
Import a fix from the ath9k - reduce the TX FIFO size for Kite (AR9285.)
|
| 220293 |
03-Apr-2011 |
adrian |
Add an explanation of the inivals
|
| 220259 |
02-Apr-2011 |
adrian |
From ath9k - clear the RX descriptor status before recycling it.
|
| 220258 |
02-Apr-2011 |
adrian |
Add some more debugging
|
| 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.
|
| 220185 |
31-Mar-2011 |
adrian |
Break out the ath PCI logic into a separate device/module.
Introduce the AHB glue for Atheros embedded systems. Right now it's
hard-coded for the AR9130 chip whose support isn't yet in this HAL;
it'll be added in a subsequent commit.
Kernel configuration files now need both 'ath' and 'ath_pci' devices; both
modules need to be loaded for the ath device to work.
|
| 220132 |
29-Mar-2011 |
adrian |
According to ath9k recv.c, one shouldn't be doing self-linked descriptors
in the RX path when doing 11n and block-ack'ed frames. Apparently, the MAC
will loop over that self-linked descriptor and treat it as "good enough"
for (incorrectly!) ACKing the frames in the block-ack.
Until I figure out how to work around this issue in the future, this counter
will tell me if packet RX processing ever gets to the point where it's
touching the self-linked descriptor. If there's ever enough packets to get
to that point, BA's will be invalid and likely very unhappy.
|
| 220098 |
28-Mar-2011 |
adrian |
Add in HT protection but disable it by default.
I'll clear how it's supposed to work with Bernhard and then look
at enabling this in the correct situations.
But this -does- enable HT RTS protection (using the appropriate legacy
rates) if this bit of code is enabled.
|
| 220054 |
27-Mar-2011 |
adrian |
Fix typo.
|
| 220053 |
27-Mar-2011 |
adrian |
Rename AH_ENABLE_11N to ATH_ENABLE_11 - the HAL supports 11n by
default but the ath driver doesn't. This is a much more consistent
name.
|
| 220035 |
26-Mar-2011 |
adrian |
.. And another missed commit - add the PSPOLL capability.
|
| 220034 |
26-Mar-2011 |
adrian |
This was missing from the previous HAL commit - it fixes a typo and
introduces the PS-POLL hardware support.
|
| 220033 |
26-Mar-2011 |
adrian |
If 802.11n is enabled, bump the number of buffers used up to a larger
level.
This is important for AMPDU RX as each burst is multiple packets in a row.
|
| 220029 |
26-Mar-2011 |
adrian |
Add in the hardware PS-POLL frame reception setting, but leave it disabled
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.
|
| 220027 |
26-Mar-2011 |
adrian |
Introduce hardware PS-POLL support in the HAL.
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.
|
| 220025 |
26-Mar-2011 |
adrian |
Put these two back to mirror what ath9k does.
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.
|
| 220022 |
26-Mar-2011 |
adrian |
Shuffle around the HAL_RX_FILTER bits to be slightly more sensible.
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.
|
| 219985 |
25-Mar-2011 |
adrian |
After discussing with Bernhard, the "right" way in net80211 to check
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.
|
| 219984 |
25-Mar-2011 |
adrian |
I broke periodic adc calibrations - so restore them to working order.
|
| 219981 |
25-Mar-2011 |
adrian |
Re-disable the setting of 2040/shortgi bits for now.
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.
|
| 219980 |
25-Mar-2011 |
adrian |
After discussion with Felix Fietkau (nbd) about the ath9k Merlin LNA bit
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.
|
| 219979 |
25-Mar-2011 |
adrian |
Flip ANI on for the AR5416 and later chips. I haven't verified it on
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.
|
| 219978 |
25-Mar-2011 |
adrian |
The right commit - add a couple more AR_PCU_MISC_MODE2 register bits -
SOWL specific.
|
| 219977 |
25-Mar-2011 |
adrian |
oops, commited the wrong file change.
|
| 219976 |
25-Mar-2011 |
adrian |
Add some more AR_PCU_MISC_MODE2 register settings - these are SOWL or later.
|
| 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.
|
| 219962 |
24-Mar-2011 |
adrian |
Flip back HT/40 and Short-GI (for 40mhz operation). These are now verified to work.
|
| 219948 |
24-Mar-2011 |
adrian |
Fix a completely wrong variable reference.
|
| 219942 |
23-Mar-2011 |
adrian |
Make the ar2133ForceBias() call controllable at runtime.
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.)
|
| 219894 |
23-Mar-2011 |
adrian |
The AR5416+ chips all have MIB counters (which the AR5416 ANI code assumes)
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.
|
| 219891 |
22-Mar-2011 |
adrian |
Enable setting the MCS rate bit for ast_tx_rate.
This allows ath_stats to print the MCS rate when TX'ing.
|
| 219870 |
22-Mar-2011 |
adrian |
Clean up setting the short preamble bit in the rate - this way it
is very obvious (and cleanly so) that it occurs for non-11n rates.
|
| 219869 |
22-Mar-2011 |
adrian |
Flip this over to be a configurable option for people who wish to play with it.
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.
|
| 219868 |
22-Mar-2011 |
adrian |
This isn't actually needed any longer, A-MPDU frames work fine if only tagged for 11n nodes.
|
| 219863 |
22-Mar-2011 |
adrian |
Bring over an XPA (external power amplifer) bias fix for the AR9160.
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
|
| 219862 |
22-Mar-2011 |
adrian |
Fix OFDM ANI statistics gathering for the AR5416 and later chips.
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.
|
| 219860 |
22-Mar-2011 |
adrian |
Set the "right" CCA register.
Obtained From: ath9k
|
| 219855 |
22-Mar-2011 |
adrian |
Break out the RF mode setup into ar5416SetRfMode(), mirroring what ath9k does.
|
| 219854 |
22-Mar-2011 |
adrian |
Do a bit of spring cleaning in the board setup code, just to
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.
|
| 219853 |
22-Mar-2011 |
adrian |
Bring over a few queue changes from ath9k:
* add pspoll/uapsd queue setup defaults;
* enable the exponential backoff window rather than the random
backoff window when doing TX contention management.
|
| 219852 |
22-Mar-2011 |
adrian |
Even though it's very unlikely the misc mode register setting at -attach-
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.
|
| 219851 |
22-Mar-2011 |
adrian |
Remove the merlin delay workaround here, it isn't appropriate for
the analog bank writes as Merlin never does them.
|
| 219840 |
21-Mar-2011 |
adrian |
Back that commit out - something's broken, and I need to figure out
what/why.
|
| 219839 |
21-Mar-2011 |
adrian |
This CLKDRV workaround should only be for AR5416 v2.0/2.1;
the check was too strict and enabled it for all non AR5416-v2.2
chipsets - including later ones.
|
| 219822 |
21-Mar-2011 |
adrian |
Fix static ucastrate for ath_rate_sample.
* Pull out the static rix stuff into a different function
* I know this may slightly drop performance, but check if a static
rix is needed before each packet TX.
* Whilst I'm at it, add a little extra debugging to the rate
control stuff to make it easier to follow what's going on.
|
| 219802 |
20-Mar-2011 |
adrian |
Disable a check I added a while ago to ensure the initial NF cal completed.
Give it a good go (32 attempts) and then print out a warning that's
going to occur whether HAL debugging is enabled or not. Then don't
abort the radio setup; just continue merrily along.
This should fix the issue that users were having where scanning would
occasionally fail on the active channel, causing traffic to cease
until the radio scanned again.
|
| 219794 |
20-Mar-2011 |
adrian |
Cave in and disable the ADC DC gain/offset calibrations if they're
not needed.
These calibrations are only applicable if the chip operating mode
engages both interleaved RX ADCs (ie, it's compensating for the
differences in DC gain and DC offset -between- the two ADCs.)
Otherwise the chip reads values of 0x0 for the secondary ADC
(as I guess it's not enabled here) and thus writes potentially
bogus info into the chip.
I've tested this on the AR9160 and AR9280; both behave themselves
in 11g mode with these calibrations disabled.
|
| 219793 |
20-Mar-2011 |
adrian |
* Remove a not-needed check in the AR5416+ case
* Restore the chip default of the DCU backoff threshold to 0x2,
mirroring what ath9k does.
|
| 219792 |
20-Mar-2011 |
adrian |
Bring over a copy of the AR5212 TX queue reset and setup routines, in preparation
for fixing them based on the ath9k related TXQ fixes.
I've done this so people can go over the history of the diffs to the original
AR5212 routines (which AR5416 and later chips use) to see what's changed.
|
| 219790 |
20-Mar-2011 |
adrian |
Add a PSPOLL queue type, in preparation for (eventually) porting
over the TX queue setup code from ath9k for the AR5416 and later
chips.
|
| 219773 |
19-Mar-2011 |
adrian |
Add in the channel survey data structures. These will be filled out
by the HAL at some point in the future.
|
| 219772 |
19-Mar-2011 |
adrian |
Reserve a new diagnostic code for the channel survey code I'll add soon.
|
| 219771 |
19-Mar-2011 |
adrian |
Make sure that the AR_MISC_MODE value from the initvals are properly respected.
This commit really is "fix the OFDM duration calculation to match reality when
running in 802.11g mode."
The AR5212 init vals set AR_MISC_MODE to 0x0 and all the bits that can be set are
set through code.
The AR5416 and later initvals set AR_MISC_MODE to various other values (with
the AR5212 AR_MISC_MODE options cleared), which include AR_PCU_CCK_SIFS_MODE .
This adds 6uS to SIFS on non-CCK frames when transmitting.
This fixes the issue where _DATA_ 802.11g OFDM frames were being TX'ed with
the ACK duration set to 38uS, not 44uS as on the AR5212 (and other devices.)
The AR5212 TX pathway obeys the software-programmed duration field in the packet,
but the 11n TX pathway overrides that with a hardware-calculated duration. This
was getting it wrong because of the above AR_MISC_MODE setting. I've verified
that 11g data OFDM frames are now being TXed with the correct ACK+SIFS duration
programmed in.
|
| 219770 |
19-Mar-2011 |
adrian |
Use the HAL method rather than directly calling ar5212ResetTxQueue().
Since ath9k does some slightly different bit fiddling when setting up
the TX queues, it may that the TX queue setup/reset functions will need
overriding later on.
|
| 219767 |
19-Mar-2011 |
adrian |
Add debugging messages to the AR5416 ANI code that's found in the AR5212 ANI code.
|
| 219628 |
14-Mar-2011 |
adrian |
Fix typo that snuck in.
|
| 219627 |
14-Mar-2011 |
adrian |
Bring over the AR9285 board update code from ath9k.
This does a few things in particular:
* Abstracts out the gain control settings into a separate function;
* Configure antenna diversity, LNA and antenna gain parameters;
* Configure ob/db entries - the later v4k EEPROM modal revisions have
multiple OB/DB parameters which are used for some form of
calibration. Although the radio does have defaults for each,
the EEPROM can override them.
This resolves the AR2427 related issues I've been seeing and makes
it stable at all 11g rates for both TX and RX.
|
| 219605 |
13-Mar-2011 |
adrian |
Fix the nfarray offsets for the ar2133/ar5133 radio - (AR5416, AR9160, etc.)
The offsets didn't match the assumption that nfarray[] is ordered by the
chainmask bits and programmed via the register order in ar5416_cca_regs[].
This repairs that damage and ensures that chain 1 is programmed correctly.
(And extension channels will now be programmed correctly also.)
This fixes some of the stuck beacons I've been seeing on my AR9160/AR5416
setups - because Chain 1 would be programmed -80 or -85 dBm, which is
higher than the actual noise floor and thus convincing the radio that
indeed it can't ever transmit.
|
| 219588 |
13-Mar-2011 |
adrian |
The number of streams is not based on the interface stream count, but the
number of streams needed for that MCS rate.
|
| 219586 |
13-Mar-2011 |
adrian |
Move out some of the shared eeprom board value calculation routines into ah.c
rather than duplicating them for the v14 (ar5416+) and v4k (ar9285) codebases.
Further chipsets (eg the AR9287) have yet another EEPROM format which will use
these routines to calculate things.
|
| 219585 |
13-Mar-2011 |
adrian |
* Add in some board settings debugging to log what's being written
to the TX closed-loop power control registers.
* Modify a couple of functions to take the register chain number,
rather than the regChainOffset value. This allows for the
register chain to be logged.
|
| 219481 |
11-Mar-2011 |
adrian |
Port over the AR9285 PA calibration and initial calibration code from
Linux ath9k.
The ath9k ar9002_hw_init_cal() isn't entirely clear about what
is supposed to be called for what chipsets, so I'm ignoring the
rest of it and just porting the AR9285 init cal path as-is and
leaving the rest alone. Subsequent commits may also tidy up the
Merlin (AR9285) and other chipset support.
Obtained from: Linux ath9k
|
| 219480 |
11-Mar-2011 |
adrian |
Introduce methods for the initial calibration and the new PA calibration
routines.
These are needed for the AR9285/AR2427 and AR9287 calibration routines
which will be introducecd in a later commit.
|
| 219479 |
11-Mar-2011 |
adrian |
Remove the ar9285FillVpdTable() and just use ar5416FillVpdTable().
|
| 219475 |
11-Mar-2011 |
adrian |
Bring over the same fix from the AR5416 PDADC calibration code.
The ath9k driver has a unified boundary/pdadc function, whereas
ours is split into two (one for each EEPROM type.) This is why
the AR9280 check is done here where we could safely assume it'll
always be AR9280 or later.
|
| 219474 |
11-Mar-2011 |
adrian |
Don't call ar5416SetTransmitPower() directly from ar5416SetTxPowerLimit();
this is incorrect for Kite (AR9285) and any future chipsets that
override the EEPROM related routines.
It meant that a direct call to set the TX power would call the v14 EEPROM
AR5416/AR9280 calibration routines, rather than the v4k EEPROM routines
for the AR9285. It thus read the incorrect values from the EEPROM and
programmed garbage PDADC and TX power values into the hardware.
|
| 219450 |
10-Mar-2011 |
adrian |
Kite is a 1x1 stream device.
|
| 219445 |
10-Mar-2011 |
adrian |
Now that the power curve adjustment code is in, disable the error check
I introduced earlier, and turn it into debugging output.
|
| 219444 |
10-Mar-2011 |
adrian |
Port over the v14 eeprom PDADC curve changes from ath9k.
It looks like these apply in both open and closed loop TX power control,
but the only merlin boards i have either have OL -or- a non-default power
offset, not both.
|
| 219443 |
10-Mar-2011 |
adrian |
Merlin fix - first pdadc gain index is 0 - minpwr/2 .
Obtained from: Linux ath9k
|
| 219442 |
10-Mar-2011 |
adrian |
Migrate the regulatory database definitions into separate header files
to both make things clearer, and to make it easier to write userland
code which pulls in these definitions without needing to pull in the
rest of the HAL.
This stuff should be deprecated at some point in the future once
the net80211 regulatory domain support encapsulates all of the
defintions here.
|
| 219441 |
10-Mar-2011 |
adrian |
Introduce the Merlin PWDCLKIND workaround.
This is something bus clock related from what I can gather. It is needed for
the AR9220 based Ubiquiti SR71-12 and SR71-15 Mini-PCI NICs.
(Note: those NICs don't work right now because of earlier changes to handle
power table offset correctly. That'll be resolved in a follow-up commit.)
|
| 219419 |
09-Mar-2011 |
adrian |
For chips that are full reset in ar5416ChipReset(), save and restore the TSF.
Merlin (ar9280) and later were full-reset if they're doing open-loop TX
power control but the TSF wasn't being saved/restored.
Add ar5212SetTsf64() which sets the 64 bit TSF appropriately.
|
| 219394 |
08-Mar-2011 |
adrian |
Break out the ath regulatory domain structures into a separate header file.
|
| 219393 |
08-Mar-2011 |
adrian |
Implement open-loop TX power control (OLC) for Merlin (AR9280) and
generally tidy up the TX power programming code.
Enforce that the TX power offset for Merlin is -5 dBm, rather than
any other value programmable in the EEPROM. This requires some
further code to be ported over from ath9k, so until that is done
and tested, fail to attach NICs whose TX power offset isn't -5
dBm.
This improves both legacy and HT transmission on my merlin board.
It allows for stable MCS TX up to MCS15.
Specifics:
* Refactor out a bunch of the TX power calibration code -
setting/obtaining the power detector / gain boundaries,
programming the PDADC
* Take the -5 dBm TX power offset into account on Merlin -
"0" in the per-rate TX power register means -5 dBm, not
0 dBm
* When doing OLC
* Enforce min (0) and max (AR5416_MAX_RATE_POWER) when fiddling
with the TX power, to avoid the TX power values from wrapping
when low.
* Implement the 1 dBm cck power offset when doing OLC
* Implement temperature compensation for 2.4ghz mode when doing OLC
* Implement an AR9280 specific TX power calibration routine which
includes the OLC twiddles, leaving the earlier chipset path
(AR5416, AR9160) alone
Whilst here, use these refactored routines for the AR9285 TX power
calibration/programming code and enforce correct overflow/underflow
handling when fiddling with TX power values.
Obtained from: linux ath9k
|
| 219318 |
06-Mar-2011 |
adrian |
Add an EEPROM op that extracts out the power table offset.
It defaults to -5 dBm for eeproms earlier than v21.
This apparently only applies to Merlin (AR9280) or later,
earlier 11n chipsets have a power table offset of 0.
All the code in ath9k which checks the power table offset
and takes it into account first ensures the chip is
Merlin or later.
|
| 219315 |
05-Mar-2011 |
adrian |
Change HALDEBUG() to be a macro that conditionally calls the debug output routine.
The earlier way of doing debugging would evaluate the function parameters
before calling the HALDEBUG. In the case of detailed register debugging
would mean a -lot- of unneeded register IO and other stuff was going on.
This method evaluates the ath_hal_debug variable before the function
parameters are evaluated, drastically reducing the amount of overhead
enabling HAL debugging during compilation.
|
| 219252 |
03-Mar-2011 |
adrian |
The sample rate module currently does the slightly wrong thing when
determining whether to use MRR or not.
It uses the 11g protection mode when calculating 11n related stuff, rather
than checking the 11n protection mode.
Furthermore, the 11n chipsets can quite happily handle multi-rate retry w/
protection; the TX path and rate control modules need to be taught about
that.
|
| 219218 |
03-Mar-2011 |
adrian |
Port over ar5416OverrideIni() from ath9k ar5008_hw_override_ini().
* change the BB gating logic to explicitly define which chips are covered;
the ath9k method isn't as clear.
* don't disable the BB gating for now, the ar5416 initvals have it, and the
ar9160 initval sets it to 0x0. Figure out why before re-enabling this.
* migrate the Merlin (ar9280) applicable WAR from the Kite (ar9285) code
(which won't get called for Merlin!) and stuff it in here.
|
| 219217 |
03-Mar-2011 |
adrian |
* fix the ar5416 check macros to be slightly more correct;
* add some stubs for chipsets that we haven't yet obtained support for.
|
| 219216 |
03-Mar-2011 |
adrian |
Modify the sample rate module output to be (slightly) easier to understand.
* add dot11rate_label() which returns Mb or MCS based on legacy or HT
* use it everywhere dot11rate() is used
* in the "current selection" part at the top of the debugging output,
otuput what the rate itself is rather than the rix. The rate index
(rix) has very little meaning to normal humans who don't know how
to find the PHY settings for each of the chipsets; pointing out the
rix rate and type is likely more useful.
|
| 219214 |
03-Mar-2011 |
adrian |
Disable trying to do HT/40 and short-GI TX.
These flags are just plain wrong - they're the node flags from negotiation,
not the configured flags. I'll jump in later on and figure out exactly
what should be done to properly set these two flags when in both STA mode
(ie, what the AP says is possible and what's configured) and AP mode
(ie, where the AP has a configuration, but then negotiates what's possible
with each node, so per-node configuration can and will differ.)
This allows the 11n 2.4ghz/ht20 mode to associate (but perform poorly still)
and exchange MCS rates with atheros reference APs and a Cisco/Linksys
E3000 AP.
|
| 219185 |
02-Mar-2011 |
adrian |
Break the keycache management functions out into if_ath_keycache.c .
|
| 219180 |
02-Mar-2011 |
adrian |
Migrate the sysctl related routines (statistics, debugging, etc) out of
if_ath.c and into if_ath_sysctl.c .
|
| 218935 |
22-Feb-2011 |
adrian |
Don't set the RTS/CTS enable bit per-scenario if the global RTS/CTS
flags aren't set.
|
| 218932 |
22-Feb-2011 |
adrian |
Shuffle around the RTS/CTS rate/duration logic.
* Turn ath_tx_calc_ctsduration() into a function that
returns the ctsduration, or -1 for HT rates;
* add a printf() to ath_tx_calc_ctsduration() which will be
very loud if somehow that function is called with an MCS
rate;
* Add ath_tx_get_rtscts_rate() which returns the RTS/CTS
rate to use for the given data rate, incl. the short
preamble flag;
* Only call ath_tx_calc_ctsduration() for non-11n chipsets;
11n chipsets don't require the rtscts duration to be
calculated.
|
| 218931 |
22-Feb-2011 |
adrian |
* Don't setup the scenario if the try count is 0
* Comment what else is going on during rate scenario setup
|
| 218925 |
21-Feb-2011 |
adrian |
Fix formatting of new stat sysctls; add descriptions
|
| 218924 |
21-Feb-2011 |
adrian |
Add a new counter which tracks frames TX'ed with HT protection.
|
| 218923 |
21-Feb-2011 |
adrian |
Add a vocal warning to ath_hal_computetxtime() function is used for non-11n rates.
It's used to calculate:
* the initial per-rate entries for short/long preamble ACK durations;
* packet durations for TDMA slot decisions;
* RTS/CTS protection durations;
* updating the duration field in the 802.11 frame header
This way invalid durations will generate a warning, prompting for it to be
fixed.
|
| 218908 |
21-Feb-2011 |
adrian |
Modify the AR5416 11na rate table to use 24mb OFDM 11a for control traffic,
rather than MCS 0.
Using MCS0 for protecting 11a rates seems a bit silly.
|
| 218907 |
21-Feb-2011 |
adrian |
Implement setting the short preamble bit if it's needed for the current node.
Short preamble rates are only for legacy rates; MCS rate codes don't have a short
preamble code like this.
|
| 218779 |
17-Feb-2011 |
adrian |
Just be double-sure short-gi isn't being enabled in 20mhz mode.
|
| 218778 |
17-Feb-2011 |
adrian |
Disable short-GI in 20mhz mode - the hardware doesn't support this.
|
| 218764 |
17-Feb-2011 |
adrian |
Add in ANI parameters for the AR9280. These aren't enabled by default
as they're likely not entirely correct, but they give people something
to toy with to compare behaviour/performance.
Disable the anti-noise part, as this apparently interferes with
RIFS. I haven't verified this.
|
| 218763 |
17-Feb-2011 |
adrian |
Add a new parameter to selectively enable/disable the ANI operations.
This was inspired by ath9k, which disables ANI anti-noise immunity
parameter tweaking (but leaves the rest of the ANI operations alone.)
|
| 218762 |
17-Feb-2011 |
adrian |
Call the right function.
|
| 218761 |
17-Feb-2011 |
adrian |
Properly propagate whether the channel is HT40 or not when calculating
packet duration for the ath_rate_sample module.
This doesn't affect the packet TX at all; only how much time the
sample rate module attributes to a completed TX.
|
| 218708 |
15-Feb-2011 |
adrian |
Disable flipping antennas for AR9280.
Flipping antennas when doing 11n would cause all kinds of strange issues.
Just don't do it for now and when it comes time to do it, don't do it here.
|
| 218690 |
14-Feb-2011 |
adrian |
bring this in line with what ath9k does.
|
| 218689 |
14-Feb-2011 |
adrian |
Some statistics additions - prepare for error codes > 32 (since the AR5416
error mask is > 5 bits) and add some extra CRC/HT40/ShortGI counters to
help debug 802.11n issues.
|
| 218642 |
13-Feb-2011 |
adrian |
This should be TX stream, not RX stream.
|
| 218593 |
12-Feb-2011 |
adrian |
The current code used the fields in ath_set11nratescenario() . Use them
correctly:
* pass in whether to allow the hardware to override the duration field
in the main data frame (durupdate_en) - PS_POLL frames in particular
don't have the duration bit overriden;
* there's no rts/cts duration here; that's done elsehwere
|
| 218566 |
11-Feb-2011 |
adrian |
.. how'd this compile before I commit it and then not now?
Fixed.
|
| 218556 |
11-Feb-2011 |
adrian |
The last parameter to ath_computedur_ht() is short-GI, not short-preamble.
|
| 218490 |
09-Feb-2011 |
adrian |
Expose the 4k transaction workaround hooks to the driver, but don't (yet)
fix the descriptor allocation.
|
| 218488 |
09-Feb-2011 |
adrian |
Add in the (very!) optional glue to flip the 11n bits for if_ath.
There's still a lot of random issues to sort out with the radio side of
things and AMPDU RX handling (and completely missing AMPDU TX handling!)
but if people wish to give this a go and assist in debugging the
issues, they can define ATH_DO_11N to enable it.
I'm just re-iterating - this is here to allow people to assist in
further 11n development; it is not any indication that the 11n support
is complete and functional.
Important notes:
* This doesn't support 1-stream cards yet - (eg AR9285) - the various bits
that negotiate TX/RX MCS don't know not to try >1 stream TX or negotiate
1-stream RX; so don't enable 11n unless you've first taught the rate
control module and the net80211 stack to negotiate 1-stream stuff;
* The only rate control module minimally 11n aware is ath_rate_sample;
* ath_rate_sample doesn't know about HT/40; so airtime will be incorrectly
calculated;
* The AR9160 and AR9280 radio code is unreliable at the higher MCS rates for
some reason; this will definitely impact 11n performance;
* AMPDU-TX isn't yet implemented;
* AMPDU-RX may be a bit buggy still and will definitely suffer from the
radio unreliability mentioned above (ie, don't expect 150/300mbit
RX just yet.)
|
| 218483 |
09-Feb-2011 |
adrian |
Fix the keycache behaviour for multicast keycache search.
The correct bit to set is 0x1 in the high MAC address byte, not 0x80.
The hardware isn't programmed with that bit (which is the multicast
adress bit.)
The linux ath9k keycache code uses that bit in the MAC as a "this is
a multicast key!" and doesn't set the AR_KEYTABLE_VALID bit.
This tells the hardware the MAC isn't to be used for unicast destination
matching but it can be used for multicast bssid traffic.
This fixes some encryption problems in station mode.
PR: kern/154598
|
| 218453 |
08-Feb-2011 |
adrian |
net80211 really doesn't want A_MPDU to appear on non-11n station node mbufs.
Revert back to the previous method of doing it for where a node can be
identified and it's an 11n node.
I'll have to do some further research into exactly what is being messed up
with the sequence number matching and I'll then revisit this.
|
| 218448 |
08-Feb-2011 |
adrian |
Commit some missing bits to the sample rate module to (more) correctly calculate 802.11n packet duration.
This doesn't yet take into account HT40 packet durations as the node info
(needed to know if it's a HT20 or HT40 node) isn't available everywhere
it needs to be.
|
| 218441 |
08-Feb-2011 |
adrian |
I missed this commit - enable 4k transaction support for the ar5416+ar9160.
|
| 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.
|
| 218420 |
07-Feb-2011 |
adrian |
Add in some AR9280 specific board configuration options.
* The existing radio config code was for the AR5416/AR9160 and missed out
on some of the AR9280 specific stuff. Include said stuff from ath9k.
* Refactor out the gain control settings into a new function, again pilfered
from ath9k.
* Use the analog register RMW macro when touching analog registers.
Obtained from: Linux ath9k
|
| 218419 |
07-Feb-2011 |
adrian |
Bring over some AR9280-specific v14 additions that exist in ath9k.
Obtained from: Linux ath9k
|
| 218416 |
07-Feb-2011 |
adrian |
Use analog delay macro for modifying an analog register.
|
| 218415 |
07-Feb-2011 |
adrian |
Add a new RMW macro for analog register writes which implements the needed
wait period between operations.
|
| 218409 |
07-Feb-2011 |
adrian |
Fix typo in SIFS setup
|
| 218402 |
07-Feb-2011 |
adrian |
Add in a per phy error sysctl.
|
| 218379 |
06-Feb-2011 |
adrian |
Just tag all RX packets as needing reorder processing for now.
This fixes two problems -
* All packets need to be processed here, not just aggregate ones - as any
received frames (AMPDU or otherwise) in the given TID (traffic class id)
will update the sequence number and, implied with that, update the window;
* It seems there's situations where packets aren't matching a current node but
somehow need to be tracked. Thus just tag them all for now; I'll figure out
the why later.
Whilst I'm here, bump the stats counters whilst I'm at it.
This fixes AMPDU RX in my tests; the main problems now stem from what look
like PHY level error/retransmits which are impeding general throughput, incl.
AMPDU.
|
| 218378 |
06-Feb-2011 |
adrian |
Only tag packets with the A-MPDU bit if they were part of an A-MPDU RX.
Whilst I'm here, add a counter to count said packets.
|
| 218354 |
05-Feb-2011 |
adrian |
Add a temporary workaround so the 11n rate scenario setup code sets a useful
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.
|
| 218243 |
04-Feb-2011 |
adrian |
Oops, fix newbie mistake that breaks the normal build.
|
| 218240 |
03-Feb-2011 |
adrian |
Modify the TX path to set and use the 11n rate scenario bits.
This isn't strictly required to TX (at least non-agg and non-HT40,
non-short-GI) frames; but as it needs to be done anyway, just get
it done.
Linux ath9k uses the rate scenario style path for -all- packets,
legacy or otherwise. This code does much the same.
Beacon TX still uses the legacy, non-rate-scenario TX descriptor
setup. Ath9k also does this.
This 11n rate scenario path is only called for chips in the AR5416
HAL; legacy chips use the previous interface for TX'ing.
|
| 218238 |
03-Feb-2011 |
adrian |
Disable the code I previously added from Rui's 802.11n branch.
A-MPDU RX interferes with packet retransmission/reordering.
In local testing, I was seeing A-MPDU being negotiated and then
not used by the AP sending frames to the STA; the STA would then
treat non A-MPDU frames that are retransmits as out of the window
and get plain confused.
The hardware RX status descriptor has a "I'm part of an aggregate"
bit; so this should eventually be tested and then punted to the
A-MPDU reorder handling only if it has this bit set.
|
| 218183 |
02-Feb-2011 |
adrian |
Call the correct ANI Attach routine.
|
| 218170 |
01-Feb-2011 |
adrian |
Just to be sure, make sure the MCS rates are allowed for TX.
Approved by: rpaulo@
|
| 218160 |
01-Feb-2011 |
adrian |
Add a new method to the rate control modules which extract out the
three other rates and try counts.
The 11n rate scenario path wants to take a list of rate and tries,
rather than calling setupxtxdesc().
|
| 218159 |
01-Feb-2011 |
adrian |
Include some preliminary TX HT rate scenario setup code.
The AR5416 and later TX descriptors have new fields for supporting
11n bits (eg 20/40mhz mode, short/long GI) and enabling/disabling
RTS/CTS protection per rate.
These functions will be responsible for initialising the TX descriptors
for the AR5416 and later chips for both HT and legacy frames.
Beacon frames will remain using the non-11n TX descriptor setup for now;
Linux ath9k does much the same.
Note that these functions aren't yet used anywhere; a few more framework
changes are needed before all of the right rate information is available
for TX.
|
| 218157 |
01-Feb-2011 |
adrian |
Refator the common code which calculates the 802.11g protection duration.
|
| 218154 |
01-Feb-2011 |
adrian |
* Add a rather hacky "does this speak the 11n TX descriptor format"
function; which will be later used by the TX path to determine
whether to use the extended features or not.
* Break out the descriptor chaining logic into a separate function;
again so it can be switched out later on for the 11n version when
needed.
* Refactor out the encryption-swizzling code that's common in the
raw and normal TX path.
|
| 218151 |
01-Feb-2011 |
adrian |
Add TX/RX chainmask info to if_ath - this is needed for the 11n TX rate series.
|
| 218150 |
01-Feb-2011 |
adrian |
Add a new capability which reports the number of spatial streams a device supports.
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
|
| 218146 |
31-Jan-2011 |
adrian |
Remove the now unneeded XXX.
|
| 218145 |
31-Jan-2011 |
adrian |
Enable AMPDU reorder processing and receiving BAR frames when doing 802.11n.
Obtained from: rpaulo@
|
| 218131 |
31-Jan-2011 |
adrian |
Don't incorrectly set the burst duration setting in the TX descriptor.
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.
|
| 218069 |
29-Jan-2011 |
adrian |
Avoid writing CCA threshold values for the EXT radios for non-HT40 channels.
|
| 218068 |
29-Jan-2011 |
adrian |
Bring over some NF calibration changes from ath9k.
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.)
|
| 218067 |
29-Jan-2011 |
adrian |
Fix some errors introduced w/ the last commit; fix setting RTS/CTS in the 11n rate scenario.
* 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.
|
| 218066 |
29-Jan-2011 |
adrian |
Link in the 11n specific TX methods into the HAL.
|
| 218065 |
29-Jan-2011 |
adrian |
Migrate the TX path code out of if_ath and into a separate source file.
There's two reasons for this:
* the raw and non-raw TX path shares a lot of duplicate code which should be
refactored;
* the 11n-ready chip TX path needs a little reworking.
|
| 218061 |
29-Jan-2011 |
adrian |
Add a check for the AR9285E; I have no idea what this is.
The only other changes in ath9k for the AR9285E revolve around sleep modes
which are not fully implemented here yet.
|
| 218058 |
29-Jan-2011 |
adrian |
Break out the debug macros from if_ath.c into if_ath_debug.[ch] .
This is prep work for breaking out the TX path into a separate
set of source files.
|
| 218013 |
28-Jan-2011 |
adrian |
(Mostly) teach ath_rate_sample about MCS rates.
This is just the bare minimum needed to teach ath_rate_sample to try
and handle MCS rates. It doesn't at all attempt to find the best
rate by any means - it doesn't know anything about the MCS rate
relations, TX aggregation or any of the much sexier 11n stuff
that's out there.
It's just enough to transmit 11n frames and handle TX completion.
It shouldn't affect legacy (11abg) behaviour.
Obtained from: rpaulo@
|
| 218012 |
28-Jan-2011 |
adrian |
Make space for the extended 802.11n MCS rate tables.
|
| 218011 |
28-Jan-2011 |
adrian |
Bring in some 802.11n packet duration calculation functions from a mix of Sam/Rui and linux ath9k .
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
|
| 217930 |
27-Jan-2011 |
adrian |
Initialise the chainmask from the EEPROM rather than the hard-coded defaults.
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.
|
| 217925 |
27-Jan-2011 |
adrian |
Add missing getCapability call for AR5416.
|
| 217923 |
27-Jan-2011 |
adrian |
Make a note to re-check whether that particular check is needed.
|
| 217921 |
27-Jan-2011 |
adrian |
Writing to the analog registers on the AR9220 (Merlin PCI) seems to require a delay.
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
|
| 217882 |
26-Jan-2011 |
adrian |
Add ar5416RestoreChainMask() which will undo any AR5416 specific chainmask
overriding after calibration.
This will get set for other two chain radios, such as AR9280 and later on,
AR9287. It should however be a nul operation.
|
| 217881 |
26-Jan-2011 |
adrian |
Add an AR5416 workaround - force a different bias based on 2.4ghz channel frequency.
Obtained from: Linux ath9k
|
| 217879 |
26-Jan-2011 |
adrian |
Break out the chainmask init code into a new function - ar5416InitChainMasks() .
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.
|
| 217878 |
26-Jan-2011 |
adrian |
* fix HAL_DEBUG_INTERRUPT to be a separate bit, it was overlapping with
something else
* add HAL_DEBUG_GPIO, for some GPIO related debugging I'm tinkering with
at the moment.
|
| 217814 |
25-Jan-2011 |
adrian |
* Re-format the v4k header to be consistent
* 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.
|
| 217813 |
25-Jan-2011 |
adrian |
Bring over a fix from ath9k - zero some of the TX descriptors for Kite/AR9285.
Kite doesn't have per-chain control (it has one chain) or antenna control; so
don't try to set those descriptor entries.
|
| 217812 |
25-Jan-2011 |
adrian |
Rename this linux-ism __BIG_ENDIAN_BITFIELD macro to something suitable for FreeBSD.
Warner has pointed out that FreeBSD's bit orders follow byte orders.
|
| 217811 |
25-Jan-2011 |
adrian |
Commit updated AR9285 (Kite) v2 initvals from ath9k.
|
| 217809 |
25-Jan-2011 |
adrian |
Fix the Atheros V4K EEPROM definitions to match those in ath9k.
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.
|
| 217790 |
24-Jan-2011 |
adrian |
Remove an invalid register setup; this is likely a holdover from
the AR5212 code. It doesn't exist in ath9k and I've been told it
doesn't exist in the Atheros internal driver.
|
| 217752 |
23-Jan-2011 |
adrian |
Enable the 11n PHY by default whether or not 11n is configured.
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.
|
| 217751 |
23-Jan-2011 |
adrian |
Update the AR9280v2 inivals to match what is in Linux ath9k.
This repairs the behaviour of my AR9280 - both radio chains now seem
to correctly be receiving.
|
| 217687 |
21-Jan-2011 |
adrian |
Fix some typos.
|
| 217686 |
21-Jan-2011 |
adrian |
Add missing getCapability call for AR5416.
|
| 217685 |
21-Jan-2011 |
adrian |
Modify the v14/v4k eeprom diag interface to return the whole eeprom.
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.
|
| 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.
|
| 217641 |
20-Jan-2011 |
adrian |
ar9280SetAntennaSwitch() was using the AR5416 chainmasks (3 chains)
rather than the AR9280 chainmasks (2 chains)
|
| 217634 |
20-Jan-2011 |
adrian |
Only enable 11n modes if the chipset suports 11n.
Since the AR2427 doesn't allow 802.11n, it shouldn't have them
configured.
|
| 217632 |
20-Jan-2011 |
adrian |
Include the device ids for the AR2427.
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.
|
| 217631 |
20-Jan-2011 |
adrian |
Push the non-AR5416 related stuff into chipset specific directories.
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.
|
| 217629 |
20-Jan-2011 |
adrian |
Add a comment from my local HAL about what is actually going on here
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.
|
| 217628 |
20-Jan-2011 |
adrian |
Migrate the sample rate module to the new ath_hal_gettxcompletionrates() API.
This removes the chipset-dependent TX DMA completion descriptor groveling.
It should now be (more) portable to other, later atheros chipsets when the
time comes.
|
| 217627 |
20-Jan-2011 |
adrian |
Add in the public method to access the tx completion rates.
|
| 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.
|
| 217623 |
20-Jan-2011 |
adrian |
Port over another EEPROM option from ath9k - AR_EEP_DAC_HPWR_5G
This will be used by the temperature compensation calibration code
which will shortly make an appearance.
|
| 217622 |
20-Jan-2011 |
adrian |
Add another HAL function which waits for a register for a configurable amount.
This will be used by some future code.
|
| 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.
|
| 217619 |
20-Jan-2011 |
adrian |
Use the now-exposed diag code, rather than a hard-coded magic number.
|
| 217618 |
20-Jan-2011 |
adrian |
Break out the diagnostic codes from ah_internal.h and place them in ah_diagcodes.h.
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.
|
| 217368 |
13-Jan-2011 |
mdf |
Fix up a few more sysctl(9) mis-typing found in various LINT builds.
|
| 217323 |
12-Jan-2011 |
mdf |
sysctl(9) cleanup checkpoint: amd64 GENERIC builds cleanly.
Commit the rest of the devices.
|
| 211330 |
15-Aug-2010 |
adrian |
Fix indenting/whitespace issues introduced by me.
|
| 211328 |
15-Aug-2010 |
adrian |
The comment is misleading - that register setting seems to kick off the
initial chip NF cal.
|
| 211309 |
14-Aug-2010 |
adrian |
A local addition, not imported from ath9k.
AR_PHY_CALMODE is explicitly reset on interface reset for other chipsets;
this commit also sets it for the AR9160.
|
| 211308 |
14-Aug-2010 |
adrian |
* Merge in AR9160 initval updates from Linux-2.6.34.
* Grab the AR_PHY_CCA and AR_PHY_EXT_CCA initvals from Linux wireless-testing.
Obtained from: Linux-2.6.34
|
| 211307 |
14-Aug-2010 |
adrian |
Merge in a fix for the power/(gain?) calculation. Apply it to both
the 5416/9160 and 9285 code paths.
Obtained from: OpenWRT r22123, 522-ath9k_pwrcal_fix.patch
|
| 211306 |
14-Aug-2010 |
adrian |
Fix the calibration logic to correctly clamp the calculated coefficient.
Obtained from: OpenWRT r22123, 521-ath9k_iqcal_fix.patch
|
| 211303 |
14-Aug-2010 |
adrian |
Export ath stats via snmp, rather than requiring a debugging interface
and "athstats".
|
| 211299 |
14-Aug-2010 |
adrian |
Add a global counter of missed beacons.
The existing missed beacon count is reset once a beacon isn't missed.
|
| 211214 |
12-Aug-2010 |
adrian |
* Fix indentation
* Restore comment erroneously deleted from the previous commit
|
| 211211 |
12-Aug-2010 |
adrian |
Loading the NF CCA values may take longer than expected to occur.
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
|
| 211210 |
12-Aug-2010 |
adrian |
Use ar5212IsNFCalInProgress() to check for NF calibration progress.
|
| 211209 |
12-Aug-2010 |
adrian |
Fix indentation.
|
| 211208 |
12-Aug-2010 |
adrian |
Ensure that the correct rxchainmask is used when doing calibration in the
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.
|
| 211207 |
12-Aug-2010 |
adrian |
Internal NF calibration should not occur in parallel with any other
calibration. Ensure that the NF calibration completes before continuing
with the rest of the calibration setup process.
|
| 211206 |
12-Aug-2010 |
adrian |
Add a couple of functions to check NF calibration progress / completion.
|
| 211136 |
10-Aug-2010 |
adrian |
Don't delay updating the longcal timer - instead, update the longcal
flag immediately so it's only set once per longcal interval.
Without this, the current AR5416 code will continuously spam NF
calibrations during a periodic calibration if the longcal flag
is set. The longcal flag wouldn't be cleared until the calibration
method indicates that calibrations are "complete".
This drops the rate of NF calibration updates down from "once every
shortcal" (ie, every 100ms) during a periodic calibration, to only
once per "longcal" interval. Spamming NF calibrations every 100ms
caused some potentially horrific issues in noisy environments as
NF calibrations can take longer than 100ms and this spamming can
cause invalid NF calibration results to be read back - leading to
missed beacons, and thus leading to a stuck beacon situation.
Stuck beacons cause interface resets, which restart calibrations.
This means that the longcal calibration runs every 100ms (shortcal)
until all initial calibrations are completed. This spamming can then
cause the above issues which leads to stuck beacons, leading to
interface resets, etc, etc. Quite annoying.
|
| 211135 |
10-Aug-2010 |
adrian |
Bring over ar5416 inivals from Linux-2.6.34.
Reviewed by: rpaulo@
Obtained from: Linux
|
| 211134 |
10-Aug-2010 |
adrian |
Re-format the ar5416 inivals to be consistent with what
Linux ath9k uses.
|
| 209799 |
08-Jul-2010 |
adrian |
Extend the ath debugging a little to log the interface name.
Some devices have >1 atheros card and the current debug prints
make it impossible to tell which interface is being unhappy.
|
| 209548 |
27-Jun-2010 |
rpaulo |
Fix typo introduced in previous revision.
|
| 209541 |
26-Jun-2010 |
rpaulo |
Fix the AR_SREV_MERLIN_20_OR_LATER() check.
Submitted by: Alex Kozlov <spam at rm-rf.kiev.ua>
MFC after: 2 weeks
|
| 209156 |
14-Jun-2010 |
bschmidt |
sc_lastrs is also used in case the sending station is not known, for
example in a split IBSS scenario. Therefore always assign sc_lastrs.
This removes a hack I committed in r206457.
Approved by: rpaulo (mentor)
|
| 208712 |
01-Jun-2010 |
rpaulo |
Rewrite ar9285SetBoardValues() to match what ath9k does and fix out of
bounds reads.
MFC after: 3 days
|
| 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
|
| 208703 |
01-Jun-2010 |
rpaulo |
Fix an off by one in ar9285SetPowerCalTable().
Found with: Coverity Prevent(tm)
CID: 3979
MFC after: 3 days
|
| 208644 |
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.
While there, fix 'const static' typo.
Submitted by: Arnaud Lacombe <alc@FreeBSD.org>
MFC after: 1 week
|
| 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
|
| 208642 |
29-May-2010 |
rpaulo |
Don't shadow the global variable 'version'.
Submitted by: Arnaud Lacombe <alc@NetBSD.org>
MFC after: 1 week
|
| 207554 |
03-May-2010 |
sobomax |
Add new tunable 'net.link.ifqmaxlen' to set default send interface
queue length. The default value for this parameter is 50, which is
quite low for many of today's uses and the only way to modify this
parameter right now is to edit if_var.h file. Also add read-only
sysctl with the same name, so that it's possible to retrieve the
current value.
MFC after: 1 month
|
| 207472 |
01-May-2010 |
imp |
The Atheros AR71xx CPUs, when paired with the AR5212 parts, has a bug
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@
|
| 206496 |
12-Apr-2010 |
rpaulo |
Remove svn:executable prop.
|
| 206457 |
10-Apr-2010 |
bschmidt |
Add WPA-None support:
* WPA-None requires ap_scan=2:
The major difference between ap_scan=1 (default) and 2 is, that no
IEEE80211_IOC_SCAN* ioctls/functions are called, though, there is a
dependency on those. For example the call to wpa_driver_bsd_scan()
sets the interface UP, this never happens, therefore the interface
must be marked up in wpa_driver_bsd_associate(). IEEE80211_IOC_SSID
also is not called, which means that the SSID has not been set prior
to the IEEE80211_MLME_ASSOC call.
* WPA-None has no support for sequence number updates, it doesn't make
sense to check for replay violations..
* I had some crashes right after the switch to RUN state, issue is
that sc->sc_lastrs was not yet defined.
Approved by: rpaulo (mentor)
MFC after: 3 weeks
|
| 206420 |
09-Apr-2010 |
rpaulo |
Setup the correct RX/TX chainmask when we play with the antenna
settings.
MFC after: 1 week
Sponsored by: iXsystems, inc
|
| 204645 |
03-Mar-2010 |
rpaulo |
Introduce ath_hal_setInterrupts(), a macro for ah_setInterrupts().
Pointed out by: sam
|
| 204644 |
03-Mar-2010 |
rpaulo |
Replace Id keyword with FreeBSD keyword and set the svn props correctly.
No functional change.
|
| 204579 |
02-Mar-2010 |
rpaulo |
Couple of suggestions from Sam regarding latest commit:
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
|
| 204521 |
01-Mar-2010 |
rpaulo |
Properly setup the TX FIFO threshold for AR5416 based chipsets,
including the AR9285. This seems to fix some users's problems.
Submitted by: Jorge Boncompte [DTI2] <jorge at dti2.net>
|
| 204100 |
19-Feb-2010 |
deischen |
Correct spelling of reseting (found while researching the "bb hang detected"
messages that are plaguing me). While I'm here, delete trailing whitespace.
|
| 203959 |
16-Feb-2010 |
rpaulo |
Fix Kite and Merlin version check.
|
| 203933 |
15-Feb-2010 |
rpaulo |
Fix KITE version check.
Obtained from: //depot/user/rpaulo/80211n/...
|
| 203930 |
15-Feb-2010 |
rpaulo |
Bring back AR9285 support. This fixes most of the issues and should be
pretty usable.
MFC after: 1 month
|
| 203882 |
14-Feb-2010 |
rpaulo |
Revert part of the 9285 support because it breaks the 9280 support. I'll
try to do the 9285 support without interfering with any other chipset
revisions support.
|
| 203751 |
10-Feb-2010 |
rpaulo |
Fix typo in comment.
Pointed out by: danfe
|
| 203750 |
10-Feb-2010 |
rpaulo |
't' stands for Turbo and is a valid mode, so fix previous commit.
Pointed out by: sam
|
| 203695 |
09-Feb-2010 |
avatar |
Fixing compilation bustage by removing a stray comment fragment.
|
| 203683 |
08-Feb-2010 |
rpaulo |
Add multicast key search support. This fixes corrupted mcast packets
when we have more than one hostap vap.
Submitted by: Russell Yount <russell.yount at gmail.com>
MFC after: 2 weeks
|
| 203682 |
08-Feb-2010 |
rpaulo |
Fix TX power problems with AR9285.
|
| 203680 |
08-Feb-2010 |
rpaulo |
Fix typo in comment.
|
| 203159 |
29-Jan-2010 |
rpaulo |
Add support for the AR9285 chipset, which is found on many netbooks
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.
|
| 203158 |
29-Jan-2010 |
rpaulo |
Replace Id keyword with the FreeBSD keyword.
|
| 203156 |
29-Jan-2010 |
rpaulo |
Replace Id keyword with the FreeBSD keyword.
|
| 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
|
| 201758 |
07-Jan-2010 |
mbr |
Remove extraneous semicolons, no functional changes.
Submitted by: Marc Balmer <marc@msys.ch>
MFC after: 1 week
|
| 201453 |
03-Jan-2010 |
imp |
cardbus -> CardBus
|
| 199491 |
18-Nov-2009 |
rpaulo |
Add WorldB SKU.
Reviewed by: sam
MFC after: 1 week
|
| 198988 |
06-Nov-2009 |
jhb |
Take a step towards removing if_watchdog/if_timer. Don't explicitly set
if_watchdog/if_timer to NULL/0 when initializing an ifnet. if_alloc()
sets those members to NULL/0 already.
|
| 197948 |
10-Oct-2009 |
rpaulo |
Atheros EEPROM version 4K. This version is mostly based on version 1.4.
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
|
| 196970 |
08-Sep-2009 |
phk |
Revert previous commit and add myself to the list of people who should
know better than to commit with a cat in the area.
|
| 196969 |
08-Sep-2009 |
phk |
Add necessary include.
|
| 196935 |
07-Sep-2009 |
sam |
remove extranous return
Submitted by: phk
MFC after: 1 week
|
| 196934 |
07-Sep-2009 |
sam |
fix extraneous return that can cause a memory leak
Submitted by: phk
MFC after: 1 week
|
| 196933 |
07-Sep-2009 |
sam |
correct typo that was a noop on 32-bit machines but a bug on 64-bit machines
Submitted by: phk
|
| 196717 |
31-Aug-2009 |
sam |
On resume in sta mode program the beacon timers so when roaming (and
the previous ap is no longer in range) the device will deliver bmiss
interrupts and trigger the state machine. Also arrange to sync the
beacon timers on the next received beacon frame so that when we don't
roam we re-synchronize with the ap.
Tested by: trasz
MFC after: 1 week
|
| 196603 |
27-Aug-2009 |
sam |
change default regdomain for thailand
Obtained from: linux-wireless@kernel.org
|
| 195809 |
21-Jul-2009 |
sam |
Fix handling of AR_RX_FILTER_BSSID: write the shadow value for AR_MISC_MODE
so other register writes preserve the setting of AR_MISC_MODE_BSSID_MATCH_FORCE.
Reviewed by: rpaulo
Approved by: re (kib)
|
| 195807 |
21-Jul-2009 |
sam |
track whether any mesh vaps are present to correctly setup the rx filter
when, for example, an ap vap is created first
Reviewed by: rpaulo
Approved by: re (kib)
|
| 195620 |
11-Jul-2009 |
rpaulo |
Fix something bogus deletion that got it during mesh commit.
Approved by: re (implicit)
|
| 195618 |
11-Jul-2009 |
rpaulo |
Implementation of the upcoming Wireless Mesh standard, 802.11s, on the
net80211 wireless stack. This work is based on the March 2009 D3.0 draft
standard. This standard is expected to become final next year.
This includes two main net80211 modules, ieee80211_mesh.c
which deals with peer link management, link metric calculation,
routing table control and mesh configuration and ieee80211_hwmp.c
which deals with the actually routing process on the mesh network.
HWMP is the mandatory routing protocol on by the mesh standard, but
others, such as RA-OLSR, can be implemented.
Authentication and encryption are not implemented.
There are several scripts under tools/tools/net80211/scripts that can be
used to test different mesh network topologies and they also teach you
how to setup a mesh vap (for the impatient: ifconfig wlan0 create
wlandev ... wlanmode mesh).
A new build option is available: IEEE80211_SUPPORT_MESH and it's enabled
by default on GENERIC kernels for i386, amd64, sparc64 and pc98.
Drivers that support mesh networks right now are: ath, ral and mwl.
More information at: http://wiki.freebsd.org/WifiMesh
Please note that this work is experimental. Also, please note that
bridging a mesh vap with another network interface is not yet supported.
Many thanks to the FreeBSD Foundation for sponsoring this project and to
Sam Leffler for his support.
Also, I would like to thank Gateworks Corporation for sending me a
Cambria board which was used during the development of this project.
Reviewed by: sam
Approved by: re (kensmith)
Obtained from: projects/mesh11s
|
| 195426 |
07-Jul-2009 |
sam |
Fix ar5416 and later parts on big-endian platforms: setup the h/w byte
swizzler using the same technique used everywhere else.
Approved by: re (kib)
|
| 195418 |
06-Jul-2009 |
sam |
Fix AR5416 and later parts when building with AH_DEBUG or similar defined:
always define OS_REG_UNSWAPPED and use it in ath_hal_reg_{read,write}.
Approved by: re (kib)
|
| 195135 |
28-Jun-2009 |
phk |
Revert a local change that should not have been in the last commit.
Approved by: re (kib)
|
| 195134 |
28-Jun-2009 |
phk |
There are a number of ways an application can check if there are
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)
|
| 195114 |
27-Jun-2009 |
sam |
Add HAL_RX_FILTER_BSSID support (to disable bssid match):
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)
|
| 195049 |
26-Jun-2009 |
rwatson |
Use if_maddr_rlock()/if_maddr_runlock() rather than IF_ADDR_LOCK()/
IF_ADDR_UNLOCK() across network device drivers when accessing the
per-interface multicast address list, if_multiaddrs. This will
allow us to change the locking strategy without affecting our driver
programming interface or binary interface.
For two wireless drivers, remove unnecessary locking, since they
don't actually access the multicast address list.
Approved by: re (kib)
MFC after: 6 weeks
|
| 194135 |
13-Jun-2009 |
sam |
purge HAL_TXSTAT_ALTRATE; you can figure this out by checking ts_finaltsi
and it cannot be used with MCS rate codes
|
| 193389 |
03-Jun-2009 |
sam |
treat IEEE80211_S_CSA as a "running state"; this fixes
ap mode 11h channel switch announcements
|
| 193352 |
02-Jun-2009 |
sam |
improve raw xmit failure handling
|
| 193351 |
02-Jun-2009 |
sam |
count frag tx failures as an ifnet error
|
| 193350 |
02-Jun-2009 |
sam |
fix comment
|
| 193349 |
02-Jun-2009 |
sam |
restart tdma beacons after vap destroy
|
| 192468 |
20-May-2009 |
sam |
Overhaul monitor mode handling:
o replace DLT_IEEE802_11 support in net80211 with DLT_IEEE802_11_RADIO
and remove explicit bpf support from wireless drivers; drivers now
use ieee80211_radiotap_attach to setup shared data structures that
hold the radiotap header for each packet tx/rx
o remove rx timestamp from the rx path; it was used only by the tdma support
for debugging and was mostly useless due to it being 32-bits and mostly
unavailable
o track DLT_IEEE80211_RADIO bpf attachments and maintain per-vap and
per-com state when there are active taps
o track the number of monitor mode vaps
o use bpf tap and monitor mode vap state to decide when to collect radiotap
state and dispatch frames; drivers no longer explicitly directly check
bpf state or use bpf calls to tap frames
o handle radiotap state updates on channel change in net80211; drivers
should not do this (unless they bypass net80211 which is almost always
a mistake)
o update various drivers to be more consistent/correct in handling radiotap
o update ral to include TSF in radiotap'd frames
o add promisc mode callback to wi
Reviewed by: cbzimmer, rpaulo, thompsa
|
| 192401 |
19-May-2009 |
sam |
correct HAL_INT_BNR comment, this bit is mapped directly the h/w now
|
| 192400 |
19-May-2009 |
sam |
add TBTT interrupt support; this was added in Griffin so consumers should
check HAL_CAP_INTRMASK before using it
NB: didn't test 11n parts yet so supported only for 5212-class parts
|
| 192399 |
19-May-2009 |
sam |
minor cleanup
|
| 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
|
| 192147 |
15-May-2009 |
imp |
The module name convention is foo, not if_foo.
|
| 191909 |
08-May-2009 |
sam |
kill more portability functions that are no longer useful
|
| 191908 |
08-May-2009 |
sam |
kill unused OS_GETUPTIME
|
| 191866 |
07-May-2009 |
sam |
optimize ath_tx_findrix: there's no need to walk the rates table as
sc_rixmap is an inverse map
NB: could eliminate the check for an invalid rate by filling in 0 for
invalid entries but the rate control modules use it to identify
bogus rates so leave it for now
|
| 191865 |
07-May-2009 |
sam |
o cleanup checks for which vap combinations are permitted and what to
use for ic_opmode
o fixes the case where creating ahdemo+wds vaps caused ic_opmode to be
set to hostap
|
| 191864 |
06-May-2009 |
sam |
add support for the Beacon Not Ready (BNR) interrupt
(available on 5211 and later)
|
| 191753 |
02-May-2009 |
sam |
make superg/fast-frames state dynamically-allocated (and indirect off
the com structure instead of embedded); this reduces the overhead when
not configured and reduces visibility of the contents
|
| 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
|
| 191021 |
13-Apr-2009 |
sam |
don't use caddr_t to match ieee80211_dump_pkt type; supplying the correct
one costs nothing
|
| 191020 |
13-Apr-2009 |
sam |
o fix dynamic slave-side tdma slot length updating: we need to re-setup the
burst length in the tx q's
o remove re-config of the beaconq on update; it's not needed
|
| 191019 |
13-Apr-2009 |
sam |
add a debug msg for when a fixed transmit rate is not applied because
it's not found in the sta's negotiated rate set
|
| 190986 |
13-Apr-2009 |
sam |
remove reference to sc_tdmabintcnt; it was removed in r190848
|
| 190867 |
09-Apr-2009 |
sam |
check the method pointer before invoking ah_eepromDetach as it can
be null if attach work fails before hooking up the eeprom support
Obtained from: madwifi
|
| 190848 |
08-Apr-2009 |
sam |
remove unused struct member
|
| 190579 |
30-Mar-2009 |
sam |
Hoist 802.11 encapsulation up into net80211:
o call ieee80211_encap in ieee80211_start so frames passed down to drivers
are already encapsulated
o remove ieee80211_encap calls in drivers
o fixup wi so it recreates the 802.3 head it requires from the 802.11
header contents
o move fast-frame aggregation from ath to net80211 (conditional on
IEEE80211_SUPPORT_SUPERG):
- aggregation is now done in ieee80211_start; it is enabled when the
packets/sec exceeds ieee80211_ffppsmin (net.wlan.ffppsmin) and frames
are held on a staging queue according to ieee80211_ffagemax
(net.wlan.ffagemax) to wait for a frame to combine with
- drivers must call back to age/flush the staging queue (ath does this
on tx done, at swba, and on rx according to the state of the tx queues
and/or the contents of the staging queue)
- remove fast-frame-related data structures from ath
- add ieee80211_ff_node_init and ieee80211_ff_node_cleanup to handle
per-node fast-frames state (we reuse 11n tx ampdu state)
o change ieee80211_encap calling convention to include an explicit vap
so frames coming through a WDS vap are recognized w/o setting M_WDS
With these changes any device able to tx/rx 3Kbyte+ frames can use fast-frames.
Reviewed by: thompsa, rpaulo, avatar, imp, sephe
|
| 190571 |
30-Mar-2009 |
sam |
Remove ATH_SUPPORT_TDMA and use IEEE80211_SUPPORT_TDMA instead. It
doesn't make much sense to configure driver support w/o net80211.
Note this means ath now depends on opt_wlan.h.
|
| 190526 |
29-Mar-2009 |
sam |
Eliminate ic_myaddr so changing the mac address of a device works correctly:
o remove ic_myaddr from ieee80211com
o change ieee80211_ifattach to take the mac address of the physical device
and use that to setup the lladdr.
o replace all references to ic_myaddr in drivers by IF_LLADDR
o related cleanups (e.g. kill dead code)
PR: kern/133178
Reviewed by: thompsa, rpaulo
|
| 190347 |
24-Mar-2009 |
sam |
fix build w/ AH_DEBUG
|
| 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
|
| 189980 |
18-Mar-2009 |
sam |
Minor cleanups of tdma protocol handling:
o break out version-related code to simplify rev'ing the protocol
o add parameter validation macros so checks that appear multiple places
are consistent (and easy to change)
o add protocol version check when looking for a scan candidate
o improve scan debug output format
o rewrite beacon update handling to calculate a bitmask of changed values
and pass that down through the driver callback so drivers can optimize work
o do slot bounds check before use when parsing received beacons
|
| 189747 |
12-Mar-2009 |
sam |
preliminary ar9280 support:
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)
|
| 189713 |
12-Mar-2009 |
sam |
add asserts
|
| 189605 |
09-Mar-2009 |
sam |
replace if_watchdog w/ private callout; probably can merge this with the
calibration work sometime in the future
|
| 189604 |
09-Mar-2009 |
sam |
remove ar9160Detach; it does nothing
|
| 189575 |
09-Mar-2009 |
imp |
remove now-redunant cardbus attachment.
|
| 189380 |
05-Mar-2009 |
sam |
add a sysctl to ena/dis frobbing cca
|
| 188993 |
24-Feb-2009 |
sam |
fix typo's
|
| 188980 |
24-Feb-2009 |
sam |
move attach debug msg to the rf backend
|
| 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
|
| 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
|
| 188975 |
24-Feb-2009 |
sam |
misc fixups, mostly for code not compiled yet
|
| 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
|
| 188973 |
24-Feb-2009 |
sam |
move eeprom attach above first reset as the reset code checks the
eeprom contents for 9280 and later parts
|
| 188972 |
24-Feb-2009 |
sam |
attach methods don't need to be public, make 'em static
|
| 188971 |
23-Feb-2009 |
sam |
5416 and later parts get the radio rev differently; add ar5416GetRadioRev
to do it the right way
|
| 188970 |
23-Feb-2009 |
sam |
remove private copies of gpio methods that were needed when the hal
was an independent entity
|
| 188968 |
23-Feb-2009 |
sam |
print mac+rf part names; drop the printing 2ghz rf stuff (might come back)
|
| 188866 |
20-Feb-2009 |
sam |
correct SIFS setting; there is a 2usec adjustment between the calculated
value and what the hardware requires (based on inspection of INI values)
Submitted by: Jiri Fojtasek <jiri.fojtasek@hlohovec.net>
|
| 188865 |
20-Feb-2009 |
sam |
don't adjust core clk conversions for 1/2 and 1/4 rate channels; the
mac runs at full speed so doing this breaks conversion for ifs parameters
Submitted by: Felix Fietkau <nbd@openwrt.org>
|
| 188783 |
19-Feb-2009 |
sam |
remove private support for IEEE80211_MODE_HALF and IEEE80211_MODE_QUARTER
now that net80211 has them
|
| 188773 |
19-Feb-2009 |
sam |
Cleanup ath_hal_computetxtime's handling of 1/2 and 1/4-width channels:
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.
|
| 188771 |
19-Feb-2009 |
sam |
add HAL_DIAG_SETREGS to write registers via the diag api
|
| 188770 |
19-Feb-2009 |
sam |
whitespace
|
| 188557 |
13-Feb-2009 |
sam |
add SIOCZATHSTATS ioctl to zero driver statistics
|
| 188555 |
13-Feb-2009 |
sam |
add driver stat to count tx drops due to insufficient frag buffers
|
| 188549 |
13-Feb-2009 |
sam |
Recognize AR5212_AR2317_REV2 in ar5312Probe()
Submitted by: Pavel Roskin <proski@gnu.org>
|
| 188504 |
11-Feb-2009 |
sam |
fix both instances of name
Pointy hat: sam
|
| 188500 |
11-Feb-2009 |
sam |
fix typo in AH_CHIP definition
Submitted by: Pavel Roskin <proski@gnu.org>
|
| 188499 |
11-Feb-2009 |
sam |
gcc 4.3.2 examines getLowerUpperIndex() and concludes that it's not
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>
|
| 188465 |
11-Feb-2009 |
sam |
don't do phantom beacon miss checking for s/w beacon miss handling,
this can mistakenly drop events that cause the s/w bmiss timer to
never get re-armed
|
| 188447 |
10-Feb-2009 |
sam |
mark the CLR key installed for open auth stations such that it is reclaimed
when net80211 tears down station state; without this we leak keycache slots
|
| 188446 |
10-Feb-2009 |
sam |
add hw.ath.bstuck to control the stuck beacon threshold
|
| 188445 |
10-Feb-2009 |
sam |
on resume ah_curchan may be NULL if no channel change has been done;
workaround this by passing net80211's channel as we know it'll never
be null
Submitted by: trasz
|
| 188444 |
10-Feb-2009 |
sam |
consolidate conditional code
|
| 188269 |
07-Feb-2009 |
sam |
count stuck beacon events
|
| 188264 |
07-Feb-2009 |
sam |
fix 11n channel construction
|
| 188263 |
07-Feb-2009 |
sam |
add macro for future regulatory mods
|
| 188213 |
06-Feb-2009 |
sam |
add PSB channels to the calibration list
|
| 188197 |
05-Feb-2009 |
sam |
eliminate gainFCorrection; just have ar5212GetGainFCorrection return
the calculated value as it's only used in one place
|
| 188195 |
05-Feb-2009 |
sam |
Minor packet drop improvements:
o change tdma packet drop msg when ack required to ATH_DEBUG_TDMA
(ATH_DEBUG_XMIT is too noisy)
o add a debug msg for raw packet drop due to interface down/invalid
o add stats for these two cases
o explain how another drop case is handled
|
| 188194 |
05-Feb-2009 |
sam |
improve IQ cal debug msgs; in particular don't scare people by screaming
"MISGATED IQ CAL!" when it's not
|
| 188193 |
05-Feb-2009 |
sam |
fill in ar5212ResetCalValid; reset the IQ valid flag on the channel
so IQ calibration will be started on the next periodic cal
|
| 188192 |
05-Feb-2009 |
sam |
style
|
| 188191 |
05-Feb-2009 |
sam |
replace r/w idiom with OS_REG_SET_BIT (to match other code)
|
| 188084 |
03-Feb-2009 |
sam |
fix compilation w/ AH_DEBUG
|
| 188012 |
02-Feb-2009 |
sam |
o make SAVE_CCK slightly less error prone by always writing the _flag
value used later by RESTORE_CCK
o swap arg order in RESTORE_CCK to slightly reduce cost
|
| 188011 |
02-Feb-2009 |
sam |
restore variable initialization removed in r187831; this broke
the horrible SAVE/RESTORE_CCK macros used by swan/nala cards to
implement 11b using 11g
|
| 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
|
| 187800 |
27-Jan-2009 |
sam |
change ic_getradiocaps driver callback to include the max # channels
so callers know the size of the array passed down
|
| 187611 |
23-Jan-2009 |
sam |
fix return status handling by ar5XXXReset; this is the reason the
driver sometimes reports reset failed w/ status 0
|
| 187608 |
23-Jan-2009 |
sam |
don't run the calibration code if scanning, we won't be on the home channel
|
| 187510 |
21-Jan-2009 |
sam |
correct typo that left programmed sifs time in the slot time
(to be applied on subsequent resets)
Submitted by: Jiri Fojtasek <jiri.fojtasek@hlohovec.net>
|
| 187345 |
16-Jan-2009 |
sam |
export PSB frequencies
|
| 187129 |
13-Jan-2009 |
sam |
On some platforms touching the bb registers when the phy is powered
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).
|
| 186904 |
08-Jan-2009 |
sam |
TDMA support for long distance point-to-point links using ath devices:
o add net80211 support for a tdma vap that is built on top of the
existing adhoc-demo support
o add tdma scheduling of frame transmission to the ath driver; it's
conceivable other devices might be capable of this too in which case
they can make use of the 802.11 protocol additions etc.
o add minor bits to user tools that need to know: ifconfig to setup and
configure, new statistics in athstats, and new debug mask bits
While the architecture can support >2 slots in a TDMA BSS the current
design is intended (and tested) for only 2 slots.
Sponsored by: Intel
|
| 186879 |
07-Jan-2009 |
sam |
correct fixed rate handling; the rixmap was changed a while back
to be indexed by the ieee rate code
|
| 186806 |
06-Jan-2009 |
sam |
remove the ath_rate module dependency; it's all bundled
|
| 186804 |
06-Jan-2009 |
sam |
remove module glue, it's not used any more
|
| 186333 |
19-Dec-2008 |
sam |
add FreeBSD property
|
| 186332 |
19-Dec-2008 |
sam |
Correct 5212 ani support so that max noise immunity, spur immunity, and
step levels are used.
Noticed by: Jiri Fojtasek <jiri.fojtasek@hlohovec.net>
Reviewed by: rpaulo
|
| 186098 |
15-Dec-2008 |
sam |
fix ini setup
Submitted by: Jiri Fojtasek <jiri.fojtasek@hlohovec.net>
|
| 186020 |
13-Dec-2008 |
sam |
o remove dead code
o fix AH_RF macro expansion to be as intended (worked before unintentionally)
Obtained from: netbsd
|
| 186019 |
13-Dec-2008 |
sam |
remove dead code
Obtained from: netbsd
|
| 186018 |
13-Dec-2008 |
sam |
add const
Obtained from: netbsd
|
| 186017 |
13-Dec-2008 |
sam |
fix static const order
Obtained from: netbsd
|
| 186016 |
13-Dec-2008 |
sam |
fix static const order
Obtained from: netbsd
|
| 186015 |
13-Dec-2008 |
sam |
remove duplicate case
Obtained from: netbsd
|
| 186014 |
13-Dec-2008 |
sam |
remove conflicting decl
Obtained from: netbsd
|
| 185907 |
11-Dec-2008 |
sam |
add missing break
Coverity ID: 4159
|
| 185906 |
11-Dec-2008 |
sam |
add missing break
Coverity ID: 4151
|
| 185745 |
07-Dec-2008 |
sam |
honor IEEE80211_BPF_CRYPTO for raw xmit; fixes shared key auth in sta mode
PR: kern/129022
|
| 185744 |
07-Dec-2008 |
sam |
New periodic calibration scheme needed for 11n parts that have
multiple algorithms and potentially collect multiple samples.
Instead of a single calibration interval we now have short and long
intervals; the long interval roughly corresponds to the previous
single interval. The short interval is used to speedup collection
of samples and happens much quicker. We make calls using the short
interval until we're told the calibration work is complete at which
point we fallback to the long interval. In addition there is a
much longer reset interval used to flush all calibration state and
cause everthing to start anew.
With these changes you can also disable calibration entirely by
setting the long interval to zero.
|
| 185522 |
01-Dec-2008 |
sam |
Switch to ath hal source code. Note this removes the ath_hal
module; the ath module now brings in the hal support. Kernel
config files are almost backwards compatible; supplying
device ath_hal
gives you the same chip support that the binary hal did but you
must also include
options AH_SUPPORT_AR5416
to enable the extended format descriptors used by 11n parts.
It is now possible to control the chip support included in a
build by specifying exactly which chips are to be supported
in the config file; consult ath_hal(4) for information.
|
| 185521 |
01-Dec-2008 |
sam |
import ath hal
|
| 185490 |
30-Nov-2008 |
sam |
cover up sun4v namespace pollution
|
| 185482 |
30-Nov-2008 |
sam |
Major overhaul:
o eliminate private state indexed by 802.11 rate codes; use the hal's
rate tables directly to get the same info
o calculate a mask of operational rates to optimize lookups and checks
(instead of using for loops and similar)
o optimize size bin operations
o ignore rates marked as "do not use" in the hal phy tables
o fix bug that caused upshifting to break in 11g once the rate dropped
below 11Mb/s
o add more intelligent multi-rate tx schedules
o add support for 1/2 and 1/4 width channels
o add dev.ath.X.sample_stats sysctl to dump runtime statistics to the console
(needs to go up to a user app)
o export more tuning knobs via sysctls (still a couple of magic constants)
|
| 185481 |
30-Nov-2008 |
sam |
sync w/ p4 branch
|
| 185480 |
30-Nov-2008 |
sam |
some of the 11n parts can hang under certain conditions without
necessary workarounds, add code to detect these hangs and distinguish
them from other events; note this code is only invoked for anomalous
conditions and (at the moment) is a noop because the hang detection
code is in a new hal that's coming shortly
|
| 185479 |
30-Nov-2008 |
sam |
add frequency mapping for the Zcomax GZ-901
|
| 185243 |
24-Nov-2008 |
sam |
print the extended tx/rx descriptor for 5416 and later parts
|
| 185242 |
24-Nov-2008 |
sam |
nuke special handling of RXORN interrupt; the hal marks the FATAL
bit in the interrupt status when RXORN is hit and the chip requires
a reset so our special handling was causing useless resets
|
| 184480 |
30-Oct-2008 |
sam |
Fix checks for fast frames negotiation. ni_ath_flags holds the
capabilities reported by the ap. These need to be cross-checked
against the local configuration in the vap. Previously we were
only checking the ap capabilities which meant that if an ap reported
it was ff-capable but we were not setup to use them we'd try to do
ff aggregation and drop the frame.
There are a number of problems to be fixed here but applying this
fix immediately as the problem causes all traffic to stop (and has
not workaround).
Reported by: Ashish Shukla
|
| 184369 |
27-Oct-2008 |
sam |
prepare for a new hal
|
| 184368 |
27-Oct-2008 |
sam |
o With the addition of HT rates the set of h/w codes has a much wider range
making the use of sc_hwmap to do direct mapping impractical. Switch to
indexing by the rate index instead of the rate code and adjust associated
state and logic appropriately. This has several benefits including
simplification of the led code.
o fix radiotap capture of HT rates
o fix conditional compilation of HT radiotap support to be based on the
hal having 5416 support; not the ABI version as hal builds may or may
not include 5416 support
|
| 184366 |
27-Oct-2008 |
sam |
prefer #define to naked constant
|
| 184365 |
27-Oct-2008 |
sam |
fix handling of HT rates; these overlap legacy rates and need to be
marked as MCS in the inverse mapping table
|
| 184364 |
27-Oct-2008 |
sam |
add hack to deal with Ubiquiti XR9 cards, they have a different mapping
between 900MHz and 2.4GHz frequencies than SR9 cards; they are distinguished
by different country codes
|
| 184361 |
27-Oct-2008 |
sam |
install bssid for ahdemo mode too
|
| 184360 |
27-Oct-2008 |
sam |
fix comment
|
| 184359 |
27-Oct-2008 |
sam |
correct callback status parameter; only indicate success when an ACK was
received
|
| 184358 |
27-Oct-2008 |
sam |
Fixup statistics:
o update tx rssi data only when an ACK was received
o return tx rssi from sampled data instead of the last frame
o track noise floor
o return rx rssi and noise floor (was broken)
|
| 184357 |
27-Oct-2008 |
sam |
update the sta inactivity timer only if we actually received an ACK
|
| 184356 |
27-Oct-2008 |
sam |
Regdomain fixups:
o pass country code, outdoor indication, and ecm mode into the hal
when requesting a channel list
o add a console msg when regulatory setup fails
o add placeholder code to map between Atheros sku's and 802.11 sku's
that handles only the debug country code used to unlock the full
channel list (to be used only for debugging)
o fix multiple instances of mismapping the 802.11 location to the
outdoor indication (anywhere may be outdoor also)
|
| 184355 |
27-Oct-2008 |
sam |
add regdomain debug msgs
|
| 184354 |
27-Oct-2008 |
sam |
add sys.dev.ath.X.intmit knob to enable/disable ANI
(the intmit name is historical)
|
| 184353 |
27-Oct-2008 |
sam |
shuffle debug setup to simplify debugging events during attach
|
| 184351 |
27-Oct-2008 |
sam |
rename bf_flags to bf_txflags in preparation for the addition of flags
separate from the tx descriptor flags currently recorded
|
| 184350 |
27-Oct-2008 |
sam |
use the ic's opmode instead of our hal equivalent to check for adhoc mode;
they are always the same
|
| 184349 |
27-Oct-2008 |
sam |
intercept IEEE80211_IOC_TXPOWER and service tx power changes immediately
|
| 184348 |
27-Oct-2008 |
sam |
move complaints about bad rate codes up a level so we can print
the h/w rate code and other useful info
|
| 184347 |
27-Oct-2008 |
sam |
remove driver-private equivalent of ni_txparms; it's now superfluous
|
| 184346 |
27-Oct-2008 |
sam |
now that the new association callback is used when joining a bss we can
eliminate the ath_rate_newassoc callback and associated code
|
| 184345 |
27-Oct-2008 |
sam |
o use the new association callback to notify the driver when joining a bss
in sta and adhoc modes; this should've been done forever ago as most all
drivers use this hook to set per-station transmit parameters such as for
tx rate control
o adjust drivers to remove explicit calls to the driver newassoc method
|
| 184063 |
19-Oct-2008 |
sam |
fix static key wep; r183248 caused drivers to be called for keys to be
assigned to slots in the global key table but ath_key_alloc was not
updated to handle that
|
| 183248 |
21-Sep-2008 |
sam |
Crypto api changes:
o don't use the key index to identify when the driver has been
asked to allocate a key slot, use an explicit flag; allows
drivers to force s/w fallback for entries in the global table
o change callback api to allocate driver resources for a crypto key:
- de-const the key parameter so drivers can muck with the flags
- on callback failure don't automatically try to setup s/w crypto;
instead the driver must now mark the key entry for s/w crypto and
the caller will re-attach the cipher module
NB: api change permits drivers more control over fallback to s/w
crypto (e.g. based on a limited number of h/w key slots)
|
| 183222 |
21-Sep-2008 |
sam |
fix compilation on 64-bit platform w/ ATH_DEBUG
|
| 183221 |
21-Sep-2008 |
sam |
fix memory smash on lp64 platforms; mostly noticeable in user mode
as being unable to associate
|
| 182893 |
09-Sep-2008 |
rpaulo |
Update for new HAL.
Reviewed by: sam
|
| 179643 |
07-Jun-2008 |
sam |
Change the calling convention for ic_node_alloc to deal with
some longstanding issues:
o pass the vap since it's now the "coin of the realm" and required
to do things like set initial tx parameters in private node
state for use prior to association
o pass the mac address as cards that maintain outboard station
tables require this to create an entry (e.g. in ibss mode)
o remove the node table reference, we only have one node table
and it's unlikely this will change so this is not needed to
find the com structure
|
| 179467 |
31-May-2008 |
sam |
5416 and similar chips grew another region in the pci clock domain
where register accesses do not pass through the byte-lane hardware;
extend the register op macros to deal with this
MFC after: 1 week
|
| 179402 |
29-May-2008 |
sam |
correct rx radiotap channel flags construction for 11n frames
|
| 179401 |
29-May-2008 |
sam |
Cleanup power handling and fix suspend/resume:
o do not put the chip into full sleep in ath_stop as it gains
nothing and causes many parts to hang in ath_detach because we
may touch the chip during vap teardown; this may also fix issues
with unloading the module
o add a note in ath_detach to explain ath_hal_detach puts the
chip in low power mode; this is useful to know as it means
unloading the module will place a pci device in the lowest
possible power state
o leave an #ifdef notyet marker for powering down the chip when
a device is marked down; we can't do that until we handle all
the ways the driver may be entered and touch the chip
o fix resume by reloading the h/w key cache as it's been clobbered
(for pci) by the socket being powered off; for station mode we
directly stop+init the chip and then simulate a beacon miss to
get the upper layers sync'd up; for other configs we must brute
force stop+start the vaps so they go through the state machine
|
| 179400 |
28-May-2008 |
sam |
close a race on detach by reordering bpfdetach and taskqueue_free
|
| 179399 |
28-May-2008 |
sam |
send EAPOL frames at the same rate used for mgt frames
|
| 178957 |
12-May-2008 |
sam |
Minor cleanup of vap create work:
o add IEEE80211_C_STA capability to indicate sta mode is supported
(was previously assumed) and mark drivers as capable
o add ieee80211_opcap array to map an opmode to the equivalent capability bit
o move IEEE80211_C_OPMODE definition to where capabilities are defined so it's
clear it should be kept in sync (on future additions)
o check device capabilities in clone create before trying to create a vap;
this makes driver checks unneeded
o make error codes return on failed clone request unique
o temporarily add console printfs on clone request failures to aid in
debugging; these will move under DIAGNOSTIC or similar before release
|
| 178752 |
03-May-2008 |
sam |
o unbreak handling of TKIP tx-only keys for splitmic chips
o yank compat support for hal's older than 0.9.20.3; leave a
CTASSERT in place just in case
|
| 178751 |
03-May-2008 |
sam |
add back sysctl's to display the regdomain and country code from eeprom;
useful for debugging
|
| 178704 |
01-May-2008 |
thompsa |
Unify all the wifi *_ioctl routines
- Limit grabbing the lock to SIOCSIFFLAGS.
- Move ieee80211_start_all() to SIOCSIFFLAGS.
- Remove SIOCSIFMEDIA as it is not useful.
- Limit ether_ioctl to only SIOCGIFADDR. SIOCSIFADDR and SIOCSIFMTU have no
affect as there is no input/output path in the vap parent. The vap code
will handle the reinit of the mac address changes.
- Split off ndis_ioctl_80211 as it was getting too different to wired devices.
This fixes a copyout while locked and a lock recursion.
Reviewed by: sam
|
| 178696 |
30-Apr-2008 |
sam |
remove old code to handle mcast address changes; this is all done through
net80211 and pushed into the driver through non-ioctl callbacks
|
| 178627 |
27-Apr-2008 |
sam |
restore the hal's channel list when doing getradiocaps so it's in sync with
the 802.11 layer's list
|
| 178354 |
20-Apr-2008 |
sam |
Multi-bss (aka vap) support for 802.11 devices.
Note this includes changes to all drivers and moves some device firmware
loading to use firmware(9) and a separate module (e.g. ral). Also there
no longer are separate wlan_scan* modules; this functionality is now
bundled into the wlan module.
Supported by: Hobnob and Marvell
Reviewed by: many
Obtained from: Atheros (some bits)
|
| 177502 |
22-Mar-2008 |
sam |
(finally) add the hal status to the diagnostic generated after
a failed ath_hal_reset call
MFC after: 3 days
|
| 175414 |
17-Jan-2008 |
sam |
promote ath_defrag to m_collapse (and retire private+unused
m_collapse from cxgb)
Reviewed by: pyun, jhb, kmacy
MFC after: 2 weeks
|
| 172900 |
23-Oct-2007 |
kevlo |
- Use pci_enable_busmaster() to turn on busmaster.
- Don't test memory/port status and emit an error message; the PCI bus
will do this.
Reviewed by: sam
|
| 172620 |
13-Oct-2007 |
sam |
revert 1.18: the negotiated rate set may not match the hal
rate tables, so using the hal's rateCodeToIndex array
will produce wrong indices for the negotiated rate set
MFC after: 3 days
|
| 172211 |
17-Sep-2007 |
sam |
Update beacon handling to sync w/ vap code base:
o add driver callback to handle notification of beacon changes;
this is required for devices that manage beacon frames themselves
(devices must override the default handler which does nothing)
o move beacon update-related flags from ieee80211com to the beacon
offsets storage (or handle however a driver wants)
o expand beacon offsets structure with members needed for 11h/dfs
and appie's
o change calling convention for ieee80211_beacon_alloc and
ieee80211_beacon_update
o add overlapping bss support for 11g; requires driver to pass
beacon frames from overlapping bss up to net80211 which is not
presently done by any driver
o move HT beacon contents update to a routine in the HT code area
Reviewed by: avatar, thompsa, sephe
Approved by: re (blanket wireless)
|
| 172209 |
17-Sep-2007 |
sam |
convert hardware rate codes to IEEE rate codes with a lookup table
instead of a linear search
Reviewed by: sephe, avatar
Approved by: re (blanket wireless)
MFC after: 2 weeks
|
| 172206 |
17-Sep-2007 |
sam |
bandaid Dynamic Turbo A operation with old hal's: HAL_MODE_108A
does not have a rate table in older hal's so if we scan such a
channel the driver will hit an assertion or crash; for old hal's
fallback to using the static turbo rate table for this mode
(not correct but good enough for now given none of the rate
control algorithms understand how to switch between base+boost)
Approved by: re (blanket wireless)
|
| 172205 |
17-Sep-2007 |
sam |
fix led blinking in RUN state: the addition of the CAC state moved
IEEE80211_S_RUN and broke the array lookup used to find the LED flags
Approved by: re (blanket wireless)
|
| 172060 |
05-Sep-2007 |
sam |
Add missing bits that made bg scanning lame:
o update ic_lastdata to reflect time of last outbound frame
o outbound traffic must preempt/cancel bg scanning to avoid delays
This stuff was somehow missed in the initial import.
Reviewed by: thompsa, avatar, sephe (earlier version)
Approved by: re (blanket wireless)
|
| 171744 |
06-Aug-2007 |
rwatson |
Remove the now-unused NET_{LOCK,UNLOCK,ASSERT}_GIANT() macros, which
previously conditionally acquired Giant based on debug.mpsafenet. As that
has now been removed, they are no longer required. Removing them
significantly simplifies error-handling in the socket layer, eliminated
quite a bit of unwinding of locking in error cases.
While here clean up the now unneeded opt_net.h, which previously was used
for the NET_WITH_GIANT kernel option. Clean up some related gotos for
consistency.
Reviewed by: bz, csjp
Tested by: kris
Approved by: re (kensmith)
|
| 171613 |
27-Jul-2007 |
rwatson |
First in a series of changes to remove the now-unused Giant compatibility
framework for non-MPSAFE network protocols:
- Remove debug_mpsafenet variable, sysctl, and tunable.
- Remove NET_NEEDS_GIANT() and associate SYSINITSs used by it to force
debug.mpsafenet=0 if non-MPSAFE protocols are compiled into the kernel.
- Remove logic to automatically flag interrupt handlers as non-MPSAFE if
debug.mpsafenet is set for an INTR_TYPE_NET handler.
- Remove logic to automatically flag netisr handlers as non-MPSAFE if
debug.mpsafenet is set.
- Remove references in a few subsystems, including NFS and Cronyx drivers,
which keyed off debug_mpsafenet to determine various aspects of their own
locking behavior.
- Convert NET_LOCK_GIANT(), NET_UNLOCK_GIANT(), and NET_ASSERT_GIANT into
no-op's, as their entire behavior was determined by the value in
debug_mpsafenet.
- Alias NET_CALLOUT_MPSAFE to CALLOUT_MPSAFE.
Many remaining references to NET_.*_GIANT() and NET_CALLOUT_MPSAFE are still
present in subsystems, and will be removed in followup commits.
Reviewed by: bz, jhb
Approved by: re (kensmith)
|
| 171015 |
24-Jun-2007 |
sam |
Process tx callbacks when draining the tx q; this fixes a problem
where a device timeout that occurs with a mgt frame on the tx q
will leave the net80211 layer w/o any way to make progress.
Reviewed by: thompsa, sephe
Approved by: re (hrs)
|
| 170530 |
11-Jun-2007 |
sam |
Update 802.11 wireless support:
o major overhaul of the way channels are handled: channels are now
fully enumerated and uniquely identify the operating characteristics;
these changes are visible to user applications which require changes
o make scanning support independent of the state machine to enable
background scanning and roaming
o move scanning support into loadable modules based on the operating
mode to enable different policies and reduce the memory footprint
on systems w/ constrained resources
o add background scanning in station mode (no support for adhoc/ibss
mode yet)
o significantly speedup sta mode scanning with a variety of techniques
o add roaming support when background scanning is supported; for now
we use a simple algorithm to trigger a roam: we threshold the rssi
and tx rate, if either drops too low we try to roam to a new ap
o add tx fragmentation support
o add first cut at 802.11n support: this code works with forthcoming
drivers but is incomplete; it's included now to establish a baseline
for other drivers to be developed and for user applications
o adjust max_linkhdr et. al. to reflect 802.11 requirements; this eliminates
prepending mbufs for traffic generated locally
o add support for Atheros protocol extensions; mainly the fast frames
encapsulation (note this can be used with any card that can tx+rx
large frames correctly)
o add sta support for ap's that beacon both WPA1+2 support
o change all data types from bsd-style to posix-style
o propagate noise floor data from drivers to net80211 and on to user apps
o correct various issues in the sta mode state machine related to handling
authentication and association failures
o enable the addition of sta mode power save support for drivers that need
net80211 support (not in this commit)
o remove old WI compatibility ioctls (wicontrol is officially dead)
o change the data structures returned for get sta info and get scan
results so future additions will not break user apps
o fixed tx rate is now maintained internally as an ieee rate and not an
index into the rate set; this needs to be extended to deal with
multi-mode operation
o add extended channel specifications to radiotap to enable 11n sniffing
Drivers:
o ath: add support for bg scanning, tx fragmentation, fast frames,
dynamic turbo (lightly tested), 11n (sniffing only and needs
new hal)
o awi: compile tested only
o ndis: lightly tested
o ipw: lightly tested
o iwi: add support for bg scanning (well tested but may have some
rough edges)
o ral, ural, rum: add suppoort for bg scanning, calibrate rssi data
o wi: lightly tested
This work is based on contributions by Atheros, kmacy, sephe, thompsa,
mlaier, kevlo, and others. Much of the scanning work was supported by
Atheros. The 11n work was supported by Marvell.
|
| 170375 |
06-Jun-2007 |
sam |
update copyrights to 2007 and convert to be 2-clause bsd-only
|
| 170229 |
03-Jun-2007 |
sam |
disable taskqueue_drain calls on transition to INIT state; we need to
find another way to do this as we cannot hold the softc mtx across
these calls
|
| 170104 |
29-May-2007 |
sam |
Drain task q items when transitioning to INIT state; this closes a
race seen on smp laptops when suspending where the rx task can be
entered after the interface is detach'd.
NB: use of taskqueue_drain while holding the softc mutex is problematic
Submitted by: ambrisko
MFC after: 1 month
|
| 170011 |
27-May-2007 |
sam |
silence some compiler complaints
|
| 168967 |
23-Apr-2007 |
sam |
make dev.ath.N.ledpin have an immediate effect
PR: kern/111810
Submitted by: Henrik Brix Andersen <henrik@brixandersen.dk>
MFC after: 1 week
|
| 168860 |
19-Apr-2007 |
sephe |
- Fix mbuf/node leakage in drivers' raw_xmit().
- For ural(4):
o Fix node leakage in ural_start(), if ural_tx_mgt() fails.
o Fix mbuf leakage in ural_tx_{mgt,data}(), if usbd_transfer() fails.
o In ural_tx_{mgt,data}(), set ural_tx_data.{m,ni} to NULL, if
usbd_transfer() fails, so they will not be freed again in ural_stop().
Approved by: sam (mentor)
|
| 168589 |
10-Apr-2007 |
rwatson |
Remove unnecessary suser() check in the sysctl to set up ath_hal
logging: the sysctl framework will already have checked for privilege
if a sysctl value is being set.
Discussed a long time ago with: sam
|
| 167252 |
05-Mar-2007 |
sam |
Change mtx's to use the formulated name as type so witness does not
complain on nested tx q lock acquisitions when processing the cab q.
MFC after: 2 weeks
|
| 167251 |
05-Mar-2007 |
sam |
Kick tx after processing rx'd frames; this fixes latency issues
for processing frames from the power save queue when operating
in ap mode. This is especially noticeable for realtime data going
to devices like voip phones.
Submitted by: "J.R. Oldroyd" <jr@opal.com>
MFC after: 2 weeks
|
| 166955 |
24-Feb-2007 |
sam |
don't call ath_reset when processing sysctl's before the device
is marked running; we don't have all the needed state in place
Noticed by: Hugo Silva <hugo@barafranca.com>
MFC after: 1 week
|
| 166954 |
24-Feb-2007 |
sam |
set the antenna switch when fixing the tx antenna using the
dev.ath.X.txantenna sysctl; this is typically what folks
want but beware this has the side effect of disabling rx
diversity
MFC after: 2 weeks
|
| 166901 |
23-Feb-2007 |
piso |
o break newbus api: add a new argument of type driver_filter_t to
bus_setup_intr()
o add an int return code to all fast handlers
o retire INTR_FAST/IH_FAST
For more info: http://docs.freebsd.org/cgi/getmsg.cgi?fetch=465712+0+current/freebsd-current
Reviewed by: many
Approved by: re@
|
| 166165 |
21-Jan-2007 |
marius |
Change the remainder of the drivers for DMA'ing devices enabled in the
sparc64 GENERIC and the sound device drivers known working on sparc64
to use bus_get_dma_tag() to obtain the parent DMA tag so we can get rid
of the sparc64_root_dma_tag kludge eventually. Except for ath(4), sk(4),
stge(4) and ti(4) these changes are runtime tested (unless I booted up
the wrong kernels again...).
|
| 166016 |
15-Jan-2007 |
sam |
add compat shim for ath_hal_isgsmsku until the new hal gets committed
|
| 166014 |
15-Jan-2007 |
sam |
save changes for handling 5416/5418 parts
|
| 166013 |
15-Jan-2007 |
sam |
Add initial support for 900MHz cards like the Ubiquiti SR9:
o eliminate assumptions that half/quarter rate channels on exist in 11a
o handle frequency mapping between hal and net80211; hal gives us freq's
in the range 2422..2437 that we remap
MFC after: 1 month
|
| 165571 |
27-Dec-2006 |
sam |
Add half/quarter rate 11a channel support:
o change handling of regdomain-related mib knobs so they can be set
post-attach: regdomain, countrycode, outdoor, and xchanmode; the
hal will not permit changing the regdomain but we expose it for now
o on regdomain/countrycode change recalculate the channel list and
push it to the net80211 layer (NB: looks to need more tweaking)
o setup rate tables for half/quarter rate channels
o honor half/quarter rate channel configs when changing channels
o honor half/quarter rate channel configs when setting the slot time
o use hack/nonstandard channel numbering scheme for the public safety
band to avoid overlapping 2.4G channels on dual-band cards
o remove setup of ic_sup_rates; the net80211 layer can do this for us
and it simplifies handling of half/quarter rate channels
Tested only in Public Safety Band with cards that have RF5112.
|
| 165185 |
13-Dec-2006 |
sam |
Track v0.9.20.3 hal:
o no more ds_vdata in tx/rx descriptors
o split h/w tx/rx descriptor from s/w status
o as part of the descriptor split change the rate control module api
so the ath_buf is passed in to the module so it can fetch both
descriptor and status information as needed
o add some const poisoning
Also for sample rate control algorithm:
o split debug msgs (node, rate, any)
o uniformly bounds check rate indices (and in some cases correct checks)
o move array index ops to after bounds checking
o use final tsi from the status block instead of the h/w descriptor
o replace h/w descriptor struct's with proper mask+shift defs (this
doesn't belong here; everything is known by the driver and should
just be sent down so there's no h/w-specific knowledge)
MFC after: 1 month
|
| 164794 |
01-Dec-2006 |
sam |
clarify shortcut return
Submitted by: cognet, kevlo
MFC after: 1 week
|
| 164598 |
24-Nov-2006 |
sam |
mark tx/rx descriptors COHERENT; we do not sync changes so on
architectures like arm this is necessary
MFC after: 1 month
|
| 163187 |
09-Oct-2006 |
sam |
correct diag request to fetch isr state on fatal interrupts
MFC after: 1 week
|
| 162413 |
18-Sep-2006 |
sam |
o move ath hal os glue code from the hal to the driver: this code was
part of the hal distribution early on when the hal was built for
each os but it's been portable for a long time so move the os-specific
code out (and off the vendor branch)
o correct the copyright on ah_osdep.?; it was mistakenly given a
restricted license and not a dual-bsd/gpl license
o remove the module api definition as it was never used
o fixup include paths for move of ah_osdep.h
MFC after: 2 weeks
|
| 162410 |
18-Sep-2006 |
sam |
Add support for newer parts that do not require separate keycache
entries for tx+rx mic keys. This requires a newer hal, but works
fine with the current hal in cvs.
MFC after: 2 weeks
|
| 162409 |
18-Sep-2006 |
sam |
remove stub radar support; it's never been used and future
hal's will not include the calls (due to redesign)
MFC after: 1 week
|
| 161425 |
17-Aug-2006 |
imp |
while (0); -> while (0) in multi-line macros
|
| 161187 |
10-Aug-2006 |
sam |
o add noise floor to stats
o include current tx rate in stats so athstats gets a consistent
snapshot and doesn't have to make an extra ioctl
o record tx rate for raw frames
MFC after: 3 weeks
|
| 161102 |
08-Aug-2006 |
sam |
check return value of ath_tx_dmasetup
Noticed by: yongari
|
| 160992 |
05-Aug-2006 |
sam |
raw 802.11 packet transmit support
Joint work with: Andrea Bittau <a.bittau@cs.ucl.ac.uk>
|
| 160693 |
26-Jul-2006 |
sam |
add missing \n's
Submitted by: avatar@
MFC after: 1 week
|
| 160692 |
26-Jul-2006 |
sam |
check tim is present in the beacon before defer'ing the mcast buffer bit;
insures we don't do this when operating in adhoc mode
Submitted by: avatar@
MFC after: 1 week
|
| 159940 |
26-Jun-2006 |
sam |
enable rx of control frames when in monitor mode
Submitted by: Andrea Bittau <a.bittau@cs.ucl.ac.uk>
MFC after: 1 week
|
| 159938 |
26-Jun-2006 |
sam |
Close race in handling mcast traffic when operating as an ap with
stations in power save: add a new q where mcast frames are stashed
and on beacon update (at DTIM) move frames from the mcast q to the
cabq and start it. This ensures the cabq is only manipulated in
one place.
Sponsored by: Hobnob
MFC after: 2 weeks
|
| 159894 |
23-Jun-2006 |
sam |
new stats
MFC after: 1 month
|
| 159383 |
07-Jun-2006 |
sam |
bandaid type coercion for ia64
Submitted by: marcel
|
| 159290 |
05-Jun-2006 |
sam |
move hal bus+tag externalization to the bus glue code where it belongs;
this is a noop on all current freebsd architectures
MFC after: 1 month
|
| 159183 |
02-Jun-2006 |
sam |
add missed calls to bpf_peers_present
|
| 159180 |
02-Jun-2006 |
csjp |
Fix the following bpf(4) race condition which can result in a panic:
(1) bpf peer attaches to interface netif0
(2) Packet is received by netif0
(3) ifp->if_bpf pointer is checked and handed off to bpf
(4) bpf peer detaches from netif0 resulting in ifp->if_bpf being
initialized to NULL.
(5) ifp->if_bpf is dereferenced by bpf machinery
(6) Kaboom
This race condition likely explains the various different kernel panics
reported around sending SIGINT to tcpdump or dhclient processes. But really
this race can result in kernel panics anywhere you have frequent bpf attach
and detach operations with high packet per second load.
Summary of changes:
- Remove the bpf interface's "driverp" member
- When we attach bpf interfaces, we now set the ifp->if_bpf member to the
bpf interface structure. Once this is done, ifp->if_bpf should never be
NULL. [1]
- Introduce bpf_peers_present function, an inline operation which will do
a lockless read bpf peer list associated with the interface. It should
be noted that the bpf code will pickup the bpf_interface lock before adding
or removing bpf peers. This should serialize the access to the bpf descriptor
list, removing the race.
- Expose the bpf_if structure in bpf.h so that the bpf_peers_present function
can use it. This also removes the struct bpf_if; hack that was there.
- Adjust all consumers of the raw if_bpf structure to use bpf_peers_present
Now what happens is:
(1) Packet is received by netif0
(2) Check to see if bpf descriptor list is empty
(3) Pickup the bpf interface lock
(4) Hand packet off to process
From the attach/detach side:
(1) Pickup the bpf interface lock
(2) Add/remove from bpf descriptor list
Now that we are storing the bpf interface structure with the ifnet, there is
is no need to walk the bpf interface list to locate the correct bpf interface.
We now simply look up the interface, and initialize the pointer. This has a
nice side effect of changing a bpf interface attach operation from O(N) (where
N is the number of bpf interfaces), to O(1).
[1] From now on, we can no longer check ifp->if_bpf to tell us whether or
not we have any bpf peers that might be interested in receiving packets.
In collaboration with: sam@
MFC after: 1 month
|
| 158366 |
08-May-2006 |
sam |
quiet tindexbox complaints about passing BUS_SPACE_MAXADDR as
a bus_size_t to bus_dma_tag_create; when PAE is enabled this
does not work
Cluebat by: scottl
MFC after: 2 weeks
|
| 158341 |
06-May-2006 |
sam |
force type coercion for bus tag+handle when calling ath_hal_attach
to ensure we match the type signature; we cannot assume HAL_BUS_TAG
and HAL_BUS_HANDLE correspond to bus_space_tag_t and bus_space_handle_t
(should probably do this for HAL_SOFTC too but leave that for now)
MFC after: 1 month
|
| 158298 |
05-May-2006 |
sam |
correct type
MFC after: 2 weeks
|
| 158045 |
26-Apr-2006 |
sam |
intercept public safety channels and do explicit mapping of freq->ieee
channel number since we're not ready at the net80211 layer to deal with them;
note this mapping has to match what's done in ieee80211_mhz2ieee
MFC after: 3 days
|
| 158035 |
25-Apr-2006 |
sam |
honor fixed tx antenna when sending beacon frames
Submitted by: Michael Stevens (from netbsd)
MFC after: 1 week
|
| 157798 |
16-Apr-2006 |
sam |
Improve ath_draintxq debug info: dump the packet as well
as the descriptor and handle the beacon q like other q's
MFC after: 1 month
|
| 157797 |
16-Apr-2006 |
sam |
Unbreak cabq handling: check the s/w q, not the h/w q as the frames
have not been passed to the h/w yet. This remedies watchdog timeout
of buffered multicast frames in hostap mode.
While here eliminate an extraneous check; ieee80211_beacon_update sets
the tim bit based on ncabq != 0 so there's no reason to check it too.
Noticed by: Christophe Prevotaux
|
| 157438 |
03-Apr-2006 |
sam |
o add opt_ath.h enable tweaking various config parameters for the driver
without modifying the source code
o default debug msgs and diag support to off
MFC after: 3 days
|
| 156463 |
09-Mar-2006 |
sam |
correct ni_txrate when using a fixed rate; fixes current rate reporting
MFC after: 3 days
|
| 156073 |
27-Feb-2006 |
sam |
backout 1.136 until we can resolve report that it causes output to stall
|
| 155991 |
24-Feb-2006 |
sam |
fix a race whereby a tx descriptor might get reused before the hardware
is finished with it; this may only occur when the tx queue is setup as
dba-gated but since the fix is cheap apply it to all queues
while here make the queue depth signed for use in assertions
Reviewed by: apatti
MFC after: 2 weeks
|
| 155736 |
15-Feb-2006 |
sam |
drop softc lock around copyin/copyout
MFC after: 2 weeks
|
| 155735 |
15-Feb-2006 |
sam |
fix build w/o AR_DEBUG
MFC after: 2 weeks
|
| 155734 |
15-Feb-2006 |
sam |
improve tx/rx buf printing routines
MFC after: 2 weeks
|
| 155733 |
15-Feb-2006 |
sam |
add missing bit from 1.130
|
| 155732 |
15-Feb-2006 |
sam |
o handle fatal errors directly instead of via the task queue
o temporarily dump some h/w state for diagnosis; this will be
removed once some issues are resolved
MFC after: 2 weeks
|
| 155731 |
15-Feb-2006 |
sam |
use ath_hal_gettxintrtxqs so we only process h/w tx
queues that have an interrupt pending
MFC after: 2 weeks
|
| 155730 |
15-Feb-2006 |
sam |
fixup comments
|
| 155729 |
15-Feb-2006 |
sam |
close race between ath_tx_start and ath_tx_processq
Reviewed by: apatti
MFC after: 1 week
|
| 155609 |
13-Feb-2006 |
sam |
fix comment and whitespace
|
| 155608 |
13-Feb-2006 |
sam |
fix merge botch (duplicate processing of cabq for old cards)
|
| 155515 |
10-Feb-2006 |
sam |
Update for rev 0.9.16.16 hal:
o add dfs+radar hooks; DFS is presently disabled in the hal
o channel and mode handling changes
o various api changes
o be more aggressive about iq calibration settling so ap mode
operation is better immediately after startup
o rfkill/rfsilent sysctl support
o tpc ack/cts sysctl support
MFC after: 2 weeks
|
| 155499 |
09-Feb-2006 |
sam |
pad for future statistics
MFC after: 2 weeks
|
| 155498 |
09-Feb-2006 |
sam |
Minor tx path cleanups:
o assume all data frames have been classified so there's no need
to check if QoS is being used, just fetch the wme priority from
the mbuf
o fix double counting of noack frames
o fix nearby comment
MFC after: 2 weeks
|
| 155497 |
09-Feb-2006 |
sam |
correct handling of mbuf allocation failure when replenishing the rx list
(leave a printf for the moment, need to make a debug msg)
Obtained from: atheros
MFC after: 2 weeks
|
| 155496 |
09-Feb-2006 |
sam |
Beacon timer setup fixes:
o pull nexttbtt forward in adhoc mode too
o resync beacon timers on joining a bss or ibss as the tstamp we
collected while scanning is almost certainly out of date
Note we may need to refine the ibss mode check in ath_recv_mgmt.
Reviewed by: avatar, dyoung
Obtained from: atheros
MFC after: 2 weeks
|
| 155495 |
09-Feb-2006 |
sam |
only start the cab queue if there are frames to send
MFC after: 2 weeks
|
| 155494 |
09-Feb-2006 |
sam |
debug fixups: reduce noise msgs, report channel flags on reset failure,
mark data+link fields in descriptor dumps
MFC after: 2 weeks
|
| 155492 |
09-Feb-2006 |
sam |
Phantom beacon miss workaround: track the tsf of the last received
frame and if we get a beacon miss interrupt ignore it if we've received
a frame within the beacon miss interval. This should never trigger
and the handling at the net80211 layer should likewise deal with this
but it doesn't hurt and can suppress extranous probe request frames.
Note that we can legtimately get a bmiss when under heavy load.
MFC after: 2 weeks
|
| 155491 |
09-Feb-2006 |
sam |
use a private task queue thread
MFC after: 2 weeks
|
| 155490 |
09-Feb-2006 |
sam |
add adhoc demo mode support
MFC after: 2 weeks
|
| 155489 |
09-Feb-2006 |
sam |
make regdomain sysctl r/w in case it's possible to do this in the future
MFC after: 2 weeks
|
| 155488 |
09-Feb-2006 |
sam |
cleanup rate setup
MFC after: 2 weeks
|
| 155486 |
09-Feb-2006 |
sam |
add tx99 hooks
MFC after: 2 weeks
|
| 155485 |
09-Feb-2006 |
sam |
move hal statistics to softc; the per-node stats are overkill, they're
only used when operating in station mode
MFC after: 2 weeks
|
| 155484 |
09-Feb-2006 |
sam |
lookup the protection tx rate index in the rate tables
instead of using a known value
MFC after: 2 weeks
|
| 155483 |
09-Feb-2006 |
sam |
honor net80211 mcast tx rate
MFC after: 2 weeks
|
| 155482 |
09-Feb-2006 |
sam |
craft unique names for tx q + buffer mtx's to help with interpreting ktr data
MFC after: 2 weeks
|
| 155481 |
09-Feb-2006 |
sam |
allow the size of tx+rx buffer pools to be tuned
MFC after: 2 weeks
|
| 155480 |
09-Feb-2006 |
sam |
lower try count on mgt (and ctl) frames to avoid clogging the tx queue
and loading the bss when operating in ap mode under load; adjust recognition
of multi-rate retry to match
MFC after: 2 weeks
|
| 155477 |
09-Feb-2006 |
sam |
move mgt frame tx rate responsibility from the rate control modules
to the driver; this avoids redundant logic and will be necessary
for future additions
MFC after: 2 weeks
|
| 155476 |
09-Feb-2006 |
sam |
sync with latest code in madwifi
Obtained from: madwifi
MFC after: 2 weeks
|
| 154735 |
23-Jan-2006 |
sam |
track bmiss threshold change from time to frame count
|
| 154140 |
09-Jan-2006 |
sam |
Update monitoring support:
o record tsf in tx+rx frames
o switch from raw rssi to dbm for signal data and record both
signal and noise floor data (hacked for now to assume a fixed
noise floor; is correct with new hal)
o add monpass sysctl to control which rx'd frames are passed
up with errors; especially useful to see frames with CRC errors
o mark 'd packets w/ a CRC error with radiotap's BADFCS flag
Also add placeholder code for calibrating the noise floor when
using newer hals.
Reviewed by: avatar
MFC after: 1 week
|
| 152448 |
15-Nov-2005 |
sam |
nuke special handling to extend cts when bursting; it was race prone
MFC after: 7 days
|
| 152447 |
15-Nov-2005 |
sam |
bandaid inconsistent state handling: the rate index map may be
stale when called to reset rate control state causing us to
pickup an invalid index, check for this and skip 'em (things
will eventually get fixed up so this is not harmful)
|
| 152315 |
11-Nov-2005 |
ru |
- Store pointer to the link-level address right in "struct ifnet"
rather than in ifindex_table[]; all (except one) accesses are
through ifp anyway. IF_LLADDR() works faster, and all (except
one) ifaddr_byindex() users were converted to use ifp->if_addr.
- Stop storing a (pointer to) Ethernet address in "struct arpcom",
and drop the IFP2ENADDR() macro; all users have been converted
to use IF_LLADDR() instead.
|
| 150212 |
16-Sep-2005 |
ru |
Fix "struct ifnet" leak on detach.
|
| 149006 |
12-Aug-2005 |
sam |
correct CTS duration calculation; SIFS+ACK should use the xmit rate not
the rate for CTS
MFC after: 3 days
Obtained from: Atheros
|
| 148936 |
10-Aug-2005 |
sam |
Clarify/fix handling of the current channel:
o add ic_curchan and use it uniformly for specifying the current
channel instead of overloading ic->ic_bss->ni_chan (or in some
drivers ic_ibss_chan)
o add ieee80211_scanparams structure to encapsulate scanning-related
state captured for rx frames
o move rx beacon+probe response frame handling into separate routines
o change beacon+probe response handling to treat the scan table
more like a scan cache--look for an existing entry before adding
a new one; this combined with ic_curchan use corrects handling of
stations that were previously found at a different channel
o move adhoc neighbor discovery by beacon+probe response frames to
a new ieee80211_add_neighbor routine
Reviewed by: avatar
Tested by: avatar, Michal Mertl
MFC after: 2 weeks
|
| 148887 |
09-Aug-2005 |
rwatson |
Propagate rename of IFF_OACTIVE and IFF_RUNNING to IFF_DRV_OACTIVE and
IFF_DRV_RUNNING, as well as the move from ifnet.if_flags to
ifnet.if_drv_flags. Device drivers are now responsible for
synchronizing access to these flags, as they are in if_drv_flags. This
helps prevent races between the network stack and device driver in
maintaining the interface flags field.
Many __FreeBSD__ and __FreeBSD_version checks maintained and continued;
some less so.
Reviewed by: pjd, bz
MFC after: 7 days
|
| 148863 |
08-Aug-2005 |
sam |
Split crypto tx+rx key indices and add a key index -> node mapping table:
Crypto changes:
o change driver/net80211 key_alloc api to return tx+rx key indices; a
driver can leave the rx key index set to IEEE80211_KEYIX_NONE or set
it to be the same as the tx key index (the former disables use of
the key index in building the keyix->node mapping table and is the
default setup for naive drivers by null_key_alloc)
o add cs_max_keyid to crypto state to specify the max h/w key index a
driver will return; this is used to allocate the key index mapping
table and to bounds check table loookups
o while here introduce ieee80211_keyix (finally) for the type of a h/w
key index
o change crypto notifiers for rx failures to pass the rx key index up
as appropriate (michael failure, replay, etc.)
Node table changes:
o optionally allocate a h/w key index to node mapping table for the
station table using the max key index setting supplied by drivers
(note the scan table does not get a map)
o defer node table allocation to lateattach so the driver has a chance
to set the max key id to size the key index map
o while here also defer the aid bitmap allocation
o add new ieee80211_find_rxnode_withkey api to find a sta/node entry
on frame receive with an optional h/w key index to use in checking
mapping table; also updates the map if it does a hash lookup and the
found node has a rx key index set in the unicast key; note this work
is separated from the old ieee80211_find_rxnode call so drivers do
not need to be aware of the new mechanism
o move some node table manipulation under the node table lock to close
a race on node delete
o add ieee80211_node_delucastkey to do the dirty work of deleting
unicast key state for a node (deletes any key and handles key map
references)
Ath driver:
o nuke private sc_keyixmap mechansim in favor of net80211 support
o update key alloc api
These changes close several race conditions for the ath driver operating
in ap mode. Other drivers should see no change. Station mode operation
for ath no longer uses the key index map but performance tests show no
noticeable change and this will be fixed when the scan table is eliminated
with the new scanning support.
Tested by: Michal Mertl, avatar, others
Reviewed by: avatar, others
MFC after: 2 weeks
|
| 148654 |
03-Aug-2005 |
rwatson |
Modify device drivers supporting multicast addresses to lock if_addr_mtx
over iteration of their multicast address lists when synchronizing the
hardware address filter with the network stack-maintained list.
Problem reported by: Ed Maste (emaste at phaedrus dot sandvine dot ca>
MFC after: 1 week
|
| 148362 |
24-Jul-2005 |
sam |
o fix setup of sc_diversity; the hal does not give us reliable
status after attach, only after a reset
o when setting diversity via the sysctl don't update sc_diversity
until we know the hal requested worked
o while here eliminate sc_hasdiversity and sc_hastpc; just query
the hal each time since these are the only places we need to know
MFC after: 3 days
|
| 148326 |
23-Jul-2005 |
sam |
o move ath_sysctlattach down so variables it depends on are setup
o use any fixed tx antenna for beacons transmitted in adhoc mode
Submitted by: David Young
MFC after: 3 days
|
| 148307 |
22-Jul-2005 |
sam |
simplify ic_newassoc callback
MFC after: 3 days
|
| 148306 |
22-Jul-2005 |
sam |
simplify ieee80211_ibss_merge api
MFC after: 3 days
|
| 148290 |
22-Jul-2005 |
sam |
diff reduction against p4: define IEEE80211_FIXED_RATE_NONE and use
it instead of -1
|
| 147803 |
07-Jul-2005 |
sam |
only invoke ath_rate_tx_complete to update rate control state when the
frame being sent is to be ack'd and hasn't been filtered by the h/w;
this insures we don't pass in tx descriptors that have no meaningful
state (e.g. mcast/bcast frames are not acked and so have no tx retry
counts)
Approved by: re (scottl)
Obtained from: Atheros
|
| 147256 |
10-Jun-2005 |
brooks |
Stop embedding struct ifnet at the top of driver softcs. Instead the
struct ifnet or the layer 2 common structure it was embedded in have
been replaced with a struct ifnet pointer to be filled by a call to the
new function, if_alloc(). The layer 2 common structure is also allocated
via if_alloc() based on the interface type. It is hung off the new
struct ifnet member, if_l2com.
This change removes the size of these structures from the kernel ABI and
will allow us to better manage them as interfaces come and go.
Other changes of note:
- Struct arpcom is no longer referenced in normal interface code.
Instead the Ethernet address is accessed via the IFP2ENADDR() macro.
To enforce this ac_enaddr has been renamed to _ac_enaddr.
- The second argument to ether_ifattach is now always the mac address
from driver private storage rather than sometimes being ac_enaddr.
Reviewed by: sobomax, sam
|
| 147153 |
09-Jun-2005 |
sam |
Change station mode beacon timer setup to insure the calculated
nextTbtt is always ahead of the h/w TSF.
Reviewed by: avatar
|
| 147067 |
07-Jun-2005 |
sam |
Set the correct IFS parameters for the beacon tx queue
when operating in ap and adhoc modes.
|
| 147057 |
06-Jun-2005 |
sam |
Misc keycache changes:
o purge ath_initkeytable; it's not needed
o add multicast key search support for supporting multiple group keys
(disabled for now; requires updated hal)
o create keycache entry for stations using open auth so they get h/w
antenna management support
o add keycache -> node mapping table; eliminates mac-based lookup in
the net80211 layer
|
| 146885 |
02-Jun-2005 |
sam |
restore led state on resume
Submitted by: markus
|
| 144961 |
12-Apr-2005 |
sam |
honor new IEEE80211_KEY_GROUP key flag
Reviewed by: Tai-hwa Liang
|
| 144617 |
04-Apr-2005 |
sam |
use frame type returned by ieee80211_input to drive softled code
instead of monitoring the input packet count
|
| 144547 |
02-Apr-2005 |
sam |
fix size_to_bin
Obtained from: madwifi
|
| 144546 |
02-Apr-2005 |
sam |
nuke unintentional use of HAL_BOOL type
|
| 144403 |
31-Mar-2005 |
sam |
reclaim mbufs in failure cases
Submitted by: Tai-hwa Liang
|
| 144351 |
30-Mar-2005 |
sam |
close unlikely race
Submitted by: Michael Wong
|
| 144350 |
30-Mar-2005 |
sam |
correct comment
|
| 144348 |
30-Mar-2005 |
sam |
o fix bug where rate wouldn't lift off lowest setting when operating as
an ap in 11g with protection enabled
o correct rate selection when operating in 11g with protection when no
packets have been sent yet (from John Bicket)
o track api change to get first descriptor and use it to collect the frame
length for calculating the state bin
o add more debugging and shuffle some existing debugging to give more info
o bump version to distinguish bug fixes
|
| 144347 |
30-Mar-2005 |
sam |
rev rate control api to pass the both the first+last tx descriptors
to the rate control module for tx complete processing; this enables
rate control algorithms to extract the packet length for xmits that
require multiple descriptors
|
| 144346 |
30-Mar-2005 |
sam |
o extend cts to cover packet burst when operating in 11g w/ protection
o check current channel parameters, not shadow state, for acm policy
on data frames
|
| 144315 |
30-Mar-2005 |
avatar |
Fixing kernel build on amd64 machines.
Reviewed by: sam (mentor)
|
| 144309 |
29-Mar-2005 |
sam |
extend the timestamp from the rx descriptor to calculate the tsf to
use when checking for an ibss merge
|
| 144308 |
29-Mar-2005 |
sam |
forgot to merge this bit from p4
|
| 144307 |
29-Mar-2005 |
sam |
sync rates for any associated stations or neighbors on state transition
|
| 144306 |
29-Mar-2005 |
sam |
simplify callback
|
| 144305 |
29-Mar-2005 |
sam |
replace m_defrag with something more suitable
|
| 143863 |
20-Mar-2005 |
sam |
fix braino introduced when converting from madwifi
|
| 143862 |
20-Mar-2005 |
sam |
eliminate mid-block variable decls
|
| 143853 |
19-Mar-2005 |
sam |
version 1.1 (with cleanups)
Submitted by: John Bicket
|
| 143419 |
11-Mar-2005 |
avatar |
Adding missing module dependency. This should fix the undefined symbol
error(ath_hal_computetxtime) during module loading.
Reviewed by: sam (mentor)
|
| 143392 |
11-Mar-2005 |
sam |
SampleRate rate control algorithm for the ath driver
Submitted by: John Bicket
|
| 143299 |
08-Mar-2005 |
sam |
reclaim mbuf chain when ieee80211_crypto_encap fails
Noticed by: David Young
|
| 143163 |
05-Mar-2005 |
imp |
Use BUS_PROBE_DEFAULT for pci probe return value
|
| 140761 |
24-Jan-2005 |
sam |
Fixup radiotap handling of FCS and QoS frames per discussion with David Young:
o mark rx frames including FCS in the payload with the
IEEE80211_RADIOTAP_F_FCS flag
o remove hack to copy 802.11 headers with padding out of line; instead mark
the frames with IEEE80211_RADIOTAP_F_DATAPAD and require applications to
do the work
o split precalculated radiotap flags into tx+rx now that they can be different
Note the full usefulness of these changes depends on updates to applications
that process radiotap data.
|
| 140759 |
24-Jan-2005 |
sam |
beacon handling fixups for adhoc mode:
o don't reclaim any previous beacon state in ath_beacon_alloc; do it
explicitly in ath_newstate
o reference count the node held in the beacon frame state block
o process ibss merge more intelligently; let the state machine do the
right thing instead of explicitly setting the new bssi id
o explicitly stop tx dma before doing beacon setup to handle the ibss
merge case
|
| 140756 |
24-Jan-2005 |
sam |
switch to use bus_dmamap_load_mbuf_sg
|
| 140755 |
24-Jan-2005 |
sam |
o correct beacon interval calculation; the internal setting is in TU's not ms
o replace the private macro to convert MS->TU with the common one
|
| 140753 |
24-Jan-2005 |
sam |
statically allocate the station/neighbor node table; the deferred
allocation scheme introduced a race condition during device state
transitions
|
| 140438 |
18-Jan-2005 |
sam |
adjust tx buffer allocation based on empirical testing:
o increase the max per-frame tx descriptor count and the number of tx
buffers for forthcoming fast frame support
o correct the max scatter/gather count; it cannot be larger than the
max(tx,rx,beacon) descriptor counts
|
| 140437 |
18-Jan-2005 |
sam |
add missing statistic
|
| 140436 |
18-Jan-2005 |
sam |
disable interrupts when transitioning to INIT state so we don't rx frames
|
| 140435 |
18-Jan-2005 |
sam |
replace hand-rolled code to compact an mbuf chain with m_defrag; this is
suboptimal but needed for fast frames which won't fit in a single cluster
|
| 140433 |
18-Jan-2005 |
sam |
setup the beacon xmit queue to not interrupt; we don't use them and
they make the led's flash unnecessarily in adhoc mode
|
| 140432 |
18-Jan-2005 |
sam |
better led blinking
|
| 140428 |
18-Jan-2005 |
sam |
add paren's so we can supply a|b as a debug mask
|
| 140427 |
18-Jan-2005 |
sam |
o disable pci retry timeout to avoid problems when operating in C3 state
(fix imported from madwifi by Takanori Watanabe)
o eliminate save/restore of pci registers handled by the system
o eliminate duplicate zero of the softc (noted by njl)
o consolidate common code
MFC after: 1 week
|
| 139530 |
31-Dec-2004 |
sam |
bump copyright for 2005
|
| 139501 |
31-Dec-2004 |
sam |
correct some typos
Submitted by: Tai-hwa Liang
|
| 139500 |
31-Dec-2004 |
sam |
Radiotap fixups:
o catch one place where we were not using ath_chan_change to
switch channels; this fixes a problem where the channel
settings were not being correctly reported in captured packets
o return unique channel identification in the channel flags;
ethereal gets confused if you return merged flags (e.g. ofdm,
cck, and 2Ghz) (this is workaround and should be removed if
we can ever cleanup radiotap consumers)
o correct short/long preamble flag state for rx and treat tx
the same--use a new hwflags array that gives us the data
based on the h/w rate index/cookie
o add gross hack to handle radiotap capture of frames that
come in with hardware padding; should be replaced by a
flag in the radiotap header and more smarts in the apps
that decode radiotap data
|
| 139499 |
31-Dec-2004 |
sam |
for parts that require split keycache entries report the
the index of the first entry on a mic error so we're
consistent with parts that don't have split keycache
|
| 139498 |
31-Dec-2004 |
sam |
Correct beacon timer setup logic:
o lintval is in ms; must convert to TU's for passing to the hal
o roundup to calculate nexttbtt (should look at current tsf and pull the
calculated nextbtt forward but this'll do for now)
o don't or- in HAL_BEACON_RESET_TSF when doing station timer setup; this
is not needed and messes up the sleep timer calcs, though it's unclear
if it mattered as the hal masks these values before use
Submitted by: Thorsten von Eicken
|
| 139497 |
31-Dec-2004 |
sam |
no need to sweep the tx q's for node references in ath_node_free; we know
there are none since we're only called when the ref count goes to zero
|
| 139496 |
31-Dec-2004 |
sam |
cleanup some assertions
|
| 138879 |
15-Dec-2004 |
peter |
Like on the ath_rate_onoe component, make this compile on amd64. Convert
pointers to an integer via uintptr_t.
Fix an apparent bug that caused a compile failure.
ieee80211_iterate_nodes() takes ic->ic_sta as its first argument on the
onoe module. It had just 'ic' here in the same context, which was a
mismatched argument.
|
| 138878 |
15-Dec-2004 |
peter |
Make this amd64-clean. sizeof is long on amd64, so things that do a printf
of a sizeof, need to use %z to get the correct type on all our platforms.
Also, convert integers<->pointers via uintptr_t.
(I think Sam's instructions were for me to commit this. If I
misunderstood, then I apologize in advance.)
|
| 138570 |
08-Dec-2004 |
sam |
Update with last year of work.
|
| 138569 |
08-Dec-2004 |
sam |
Transmit rate control modules for the ath driver.
|
| 133330 |
08-Aug-2004 |
sam |
Add missing bit of last if_start workaround: mark scan callout
MPSAFE only debug_mpsafenet is 1 so callbacks to send management
frames hold Giant; this is another bandaid on the path to removing Giant.
|
| 133240 |
07-Aug-2004 |
sam |
Pickup Giant in ath_rx_proc and when handling a beacon miss in order to
satisfy the assertion in if_start.
|
| 132986 |
01-Aug-2004 |
mlaier |
Second part of ALTQ driver modifications, covering:
an(4), ath(4), hme(4), ndis(4), vr(4) and wi(4)
Please help testing: http://people.freebsd.org/~mlaier/ALTQ_driver/
Tested by: Vaidas Damosevicius (an, ath, wi)
Roman Divacky (vr)
Submitted by: yongari (hme)
|
| 127878 |
05-Apr-2004 |
sam |
use correct malloc type to allocate struct ieee80211_node's
Noticed by: phk
|
| 127784 |
03-Apr-2004 |
sam |
do proper subclassing of node free+copy; the previous hack falls apart when
the 802.11 layer does useful work
Obtained from: madwifi
|
| 127782 |
03-Apr-2004 |
sam |
do proper subclassing of node free+copy; the previous hack falls apart when
the 802.11 layer does useful work
Obtained from: madwifi
|
| 127781 |
03-Apr-2004 |
sam |
transmit beacon frames directly instead of defering them to a swi; there
was too much delay
Obtained from: madwifi
|
| 127780 |
02-Apr-2004 |
sam |
update copyright notice for 2004
|
| 127779 |
02-Apr-2004 |
sam |
add new statistics
Obtained from: madwifi
|
| 127778 |
02-Apr-2004 |
sam |
check more quickly (and directly) if an interrupt is pending; this reduces
work done in ath_intr when the irq is shared
Obtained from: madwifi
|
| 127777 |
02-Apr-2004 |
sam |
cleanup descriptor allocation if attach fails
Obtained from: madwifi
|
| 127776 |
02-Apr-2004 |
sam |
remove use IEEE80211_C_RCVMGT
|
| 127698 |
01-Apr-2004 |
sam |
radiotap updates:
o force little-endian byte order for header
o pad header to 32-bit boundary to guard against applications that assume
packet data alignment
|
| 127237 |
20-Mar-2004 |
mdodd |
Don't announce MAC addresses twice.
(ieee80211_ifattach() calls ether_ifattach().)
|
| 127135 |
17-Mar-2004 |
njl |
Convert callers to the new bus_alloc_resource_any(9) API.
Submitted by: Mark Santcroos <marks@ripe.net>
Reviewed by: imp, dfr, bde
|
| 125510 |
06-Feb-2004 |
peter |
Make this compile on amd64.
"I'll cope" by: sam
|
| 124225 |
07-Jan-2004 |
sam |
When draining the tx queue reclaim any node references held in packets.
This fixes a problem when operating as an AP where clients would get
stuck in the node table because the reference count never went to zero.
|
| 124224 |
07-Jan-2004 |
sam |
When ath_hal_stoptxdma returns an error dma is still likely stopped
so don't just stop trying to send a beacon frame or we'll be more likely
to lose sync. This only seems to happen on some older chips.
|
| 124223 |
07-Jan-2004 |
sam |
use ath_reset instead of ath_init when recovering from a watchdog timeout:
resetting the hardware is sufficient, no need to reset the 802.11 fsm
|
| 124222 |
07-Jan-2004 |
sam |
make hw.ath.debug a tunable
|
| 124221 |
07-Jan-2004 |
sam |
make hw.ath.outdoor and hw.ath.countrycode tunables
|
| 124220 |
07-Jan-2004 |
sam |
split debugging messages up into classes;
ah_debug is now treated as a bit vector
|
| 123928 |
28-Dec-2003 |
sam |
update radiotap support to reflect recent changes:
o move tx taps from ath_start to ath_tx_start so lots more
state is available to tap
o add tx flags
o add tx rate
o add tx power (constant for the moment)
o add tx antenna state
|
| 123922 |
28-Dec-2003 |
sam |
o eliminate widespread on-stack mbuf use for bpf by introducing
a new bpf_mtap2 routine that does the right thing for an mbuf
and a variable-length chunk of data that should be prepended.
o while we're sweeping the drivers, use u_int32_t uniformly when
when prepending the address family (several places were assuming
sizeof(int) was 4)
o return M_ASSERTVALID to BPF_MTAP* now that all stack-allocated
mbufs have been eliminated; this may better be moved to the bpf
routines
Reviewed by: arch@ and several others
|
| 123044 |
29-Nov-2003 |
sam |
o track API change for HAL v0.9.6.1
o fix race condition when processing rx descriptors: because we use
a self-linked descriptor at the end of the rx descriptor list to
avoid rx overruns (which can easily happen for 5212 parts that enable
PHY errors) we must carefully check that a descriptor is "done" by
looking ahead to the next descriptor before believing the done bit
in the current descriptor (this is all handled in the HAL since the
rx descriptor format is chip-specific so we need to pass in two
additional parameters--the physical address of the current descriptor
and the virtual address of the next descriptor in the list)
o check copyout return status for SIOCGATHSTATS ioctl
Approved by: re (scottl)
|
| 123019 |
28-Nov-2003 |
imp |
Sometimes cardbus attachments don't attach, so while we track down
this problem put these lines back in. While they should be
unnecessary, they appear to be sometimes necessary.
Reviewed in concept: dfr
Approved by: re (scottl@)
|
| 122866 |
17-Nov-2003 |
sam |
move rate control change messages under ath_debug
|
| 122863 |
17-Nov-2003 |
sam |
o fix WEP use in hostap mode; need to reset the pointer to the
802.11 packet header after stripping the WEP header on input
|
| 122862 |
17-Nov-2003 |
sam |
on a beacon miss try to reassociate before starting a scan
Submitted by: Henry Qian
|
| 122602 |
13-Nov-2003 |
sam |
Don't count PHY errors as input errors. This is important for
5212-based devices because PHY errors are used to collect data
on environmental noise that and doesn't truly reflect the state
of the communications media. The result is confused users.
Folks that want to watch PHY errors can still get the statistics
through the device ioctl (used by athstats).
|
| 121939 |
03-Nov-2003 |
dfr |
Remove explicit cardbus attachments from drivers where this is identical
to the pci attachment. Cardbus is a derived class of pci so all pci
drivers are automatically available for matching against cardbus devices.
Reviewed by: imp
|
| 121840 |
01-Nov-2003 |
sam |
o check hal ABI version to catch driver-HAL mismatches
o print MAC, PHY, and radio h/w revisions at attach
|
| 121816 |
31-Oct-2003 |
brooks |
Replace the if_name and if_unit members of struct ifnet with new members
if_xname, if_dname, and if_dunit. if_xname is the name of the interface
and if_dname/unit are the driver name and instance.
This change paves the way for interface renaming and enhanced pseudo
device creation and configuration symantics.
Approved By: re (in principle)
Reviewed By: njl, imp
Tested On: i386, amd64, sparc64
Obtained From: NetBSD (if_xname)
|
| 121322 |
22-Oct-2003 |
sam |
terminate the rx descriptor list with a self-linked entry
so high phy error rates on a 5212 don't cause rx overruns
|
| 121177 |
17-Oct-2003 |
sam |
o consolidate rx filter calculations in one place
o enable beacon reception when operating in adhoc mode
so the 802.11 layer can use them to create nodes for peers
|
| 121175 |
17-Oct-2003 |
sam |
indicate device receives all management frames
|
| 121138 |
16-Oct-2003 |
sam |
o correct handling of a frame that has too many segments to fit in the
tx descriptor array
o while here fix a whitespace nit
Obtained from: NetBSD
|
| 121100 |
14-Oct-2003 |
sam |
o convert mutex calls to #defines for portability, etc.
o destroy mutex's on detach (was missing)
|
| 121063 |
13-Oct-2003 |
sam |
remove dangling mtx_unlock orphaned by rev 1.21 change
|
| 121059 |
13-Oct-2003 |
sam |
Reduce per-packet overhead when using WEP by using an advancing IV
seeded with arc4random rather than calling arc4random for each
packet. Note this is the same algorithm used to select the IV when
doing WEP on the host.
|
| 121058 |
13-Oct-2003 |
sam |
Must reset the pointer to the 802.11 header after prepending
for WEP in case the prepend addes a new mbuf. This fixes WEP.
|
| 121057 |
13-Oct-2003 |
sam |
MFp4:
o don't grab the mutex at the top of ath_detach; it does nothing
useful
o deal with entry to ath_ioctl during detach to disable promiscuous
mode as a result of calling bpfdetach2: cannot call ath_init when
the device is marked invalid as the code isn't prepared to deal
with it (in particular by that time the hal reference may have
been yanked)
|
| 121056 |
13-Oct-2003 |
sam |
MFp4:
change ath_rate_ctl_reset to handle transition from station
mode to adhoc mode; was not resetting the initial xmit rate
causing outbound frames to be dicarded
|
| 120826 |
06-Oct-2003 |
sam |
include the DS element in beacons
|
| 120105 |
15-Sep-2003 |
sam |
Maintain a history of data associated with received frames and use this to
calculate smoothed signal quality data for each node.
o add a 16-deep history buffer to each driver-private node storage that
holds rssi and antenna info for received frames
o override the default per-node "get rssi" method to return an average
rssi value based on samples collected over the last second
o enable beacon reception so even idle systems maintain a running history
of signal quality
This data may also be useful for improving the rate control algorithm.
Based on work by Tom Marshall <tommy@home.tig-grr.com> for MADWIFI.
|
| 120100 |
15-Sep-2003 |
sam |
o do not filter received frames based on type or length; pass 'em all up
to the 802.11 layer if they are at least IEEE80211_MIN_LEN
o mask off interrupt status bits that we don't care about so we don't do
the wrong thing; this fixes a problem where the beacon miss interrupt status
bit is delivered together with other status bits when operating in monitor
mode (we would post a beacon miss swi and then do the wrong thing)
|
| 120075 |
14-Sep-2003 |
sam |
must also check for 5Ghz channels when marking short preamble capability in
the beacon frames
Reminded by: Stephane Laroche <stephane.laroche@colubris.com>
|
| 120071 |
14-Sep-2003 |
sam |
o mark the device capable of short preamble (meaningless for the 5210 but
safe since the 802.11 layer does the right thing for 11a operation)
o select short preamble operation based on the negotiated capabilities; not
just the local state/capability
o fillin the duration field in the 802.11 header as appropriate
o remove detection of 11g support; no longer needed
Obtained from: MADWIFI (with modifications)
|
| 119783 |
05-Sep-2003 |
sam |
Add support for the experimental radiotap capture format. With this
we no longer need the debugging code to dump packets.
|
| 119629 |
01-Sep-2003 |
sam |
Explicitly enable probe request frame reception when not in station mode;
this is needed for the 5212 which a separate filter bit for these frames.
Submitted by: Stephane Laroche <stephane.laroche@colubris.com>
|
| 119150 |
19-Aug-2003 |
sam |
MFp4 changes to fix locking issues and correct reference
count handling of station entries in hostap mode:
Input path:
o driver is now expected to find the node associated with the
sender of a received frame; use ic_bss if none is located
o driver passes the (referenced) node into ieee80211_input for
use within the wlan module and is responsible for cleaning up
on return
o the antenna state is no longer passed up with each frame; this
is now considered driver-private state and drivers are responsible
for keeping it in the driver-private part of a node
Output path:
Revamp output path for management frames to eliminate redundant
locking that causes problems and to correct reference counting
bogosity that occurs when stations are timed out due to inactivity
(in AP mode). On output the refcnt'd node is stashed in the pkthdr's
recvif field (yech) and retrieved by the driver. This eliminates
an unref/ref scenario and related node table unlock/lock due to the
driver looking up the node. This is particularly important when
stations are timed out as this causes a lock order reversal that
can result in a deadlock. As a byproduct we also reduce the overhead
for sending management frames (minimal). Additional fallout from
this is a change to ieee80211_encap to return a refcn't node for
tieing to the outbound frame. Node refcnts are not reclaimed until
after a frame is completely processed (e.g. in the tx interrupt
handler). This is especially important for timed out stations as
this deref will be the final one causing the node entry to be
reclaimed.
Additional semi-related changes:
o replace m_copym use with m_copypacket (optimization)
o add assert to verify ic_bss is never free'd during normal operation
o add comments explaining calling conventions by drivers for frames
going in each direction
o remove extraneous code that "cannot be executed" (e.g. because
pointers may never be null)
|
| 119147 |
19-Aug-2003 |
sam |
o pass control frames up the stack when in monitor mode (the 802.11 layer will
quietly discard them; this just permits them to be collected with bpf)
o add a counter for the number of rate control frames discarded when not in
monitor mode
o move the rx "too short" statistic in the stat structure so non-error rx stats
are together (NB: ABI change to apps that collect stats via driver ioctl)
|
| 119145 |
19-Aug-2003 |
sam |
o correct beacon frame length calculation and add an assert to catch any future
mistakes (this mistake was not an issue because the length is only used to
decide whether or not to allocate a cluster)
o while here, move a beacon length comment to the "right place"
|
| 119144 |
19-Aug-2003 |
sam |
maintain a table for mapping hardware rate codes to 802.11 rates for
calculating the rate for each rx'd frame
|
| 119143 |
19-Aug-2003 |
sam |
mark the scan and calibrate callouts MPSAFE
|
| 119142 |
19-Aug-2003 |
sam |
remove unneeded include files
|
| 118884 |
13-Aug-2003 |
sam |
Close a race where ath_intr is installed and may be called before
the HAL is setup: use sc_invalid to discard such entries into
ath_intr. This can easily happen if the device is assigned a shared IRQ.
|
| 118342 |
02-Aug-2003 |
sam |
o remove bmisshack no longer needed with the BSSID fix in v0.9.5.2 of the hal
o add monitor mode support
o fix short preamble handling in beacon setup (noop)
o correct resume handling
|
| 117812 |
20-Jul-2003 |
sam |
track changes to 802.11 code:
o override new_state method per new model
o use ieee80211_state_name instead of private copy
|
| 117516 |
13-Jul-2003 |
sam |
o add read-only sysctls to view regulatory domain, country code, and
outdoor use controls
o use sysctl-visible values in setting up channel list
|
| 117126 |
01-Jul-2003 |
scottl |
Mega busdma API commit.
Add two new arguments to bus_dma_tag_create(): lockfunc and lockfuncarg.
Lockfunc allows a driver to provide a function for managing its locking
semantics while using busdma. At the moment, this is used for the
asynchronous busdma_swi and callback mechanism. Two lockfunc implementations
are provided: busdma_lock_mutex() performs standard mutex operations on the
mutex that is specified from lockfuncarg. dftl_lock() is a panic
implementation and is defaulted to when NULL, NULL are passed to
bus_dma_tag_create(). The only time that NULL, NULL should ever be used is
when the driver ensures that bus_dmamap_load() will not be deferred.
Drivers that do not provide their own locking can pass
busdma_lock_mutex,&Giant args in order to preserve the former behaviour.
sparc64 and powerpc do not provide real busdma_swi functions, so this is
largely a noop on those platforms. The busdma_swi on is64 is not properly
locked yet, so warnings will be emitted on this platform when busdma
callback deferrals happen.
If anyone gets panics or warnings from dflt_lock() being called, please
let me know right away.
Reviewed by: tmm, gibbs
|
| 117055 |
30-Jun-2003 |
sam |
acknowledge the contribution of Atsushi Onoe
|
| 116743 |
23-Jun-2003 |
sam |
Atheros 802.11 driver. Requires Atheros Hardware Access Lay (HAL).
Supported by: Atheros Comunications
|