The v1 and v3 interfaces returned the whole EEPROM but the v14/v4k
interfaces just returned the base header. There's extra information
outside of that which would also be nice to get access to.
The rxmonitor hook is called on each received packet. This can get very,
very busy as the tx/rx/chanbusy registers are thus read each time a packet
is received.
Instead, shuffle out the true per-packet processing which is needed and move
the rest of the ANI processing into a periodic event which runs every 100ms
by default.
This is apparently an AR9285 with the 802.11n specific bits disabled.
This code is completely untested; I'm doing this in response to users
who wish to test the functionality out. It's likely as buggy as the
AR9285 support is in FreeBSD at the moment.
sys/dev/ath/ath_hal/ar5416/ is getting very crowded and further
commits will make it even more crowded. Now is a good time to
shuffle these files out before any more extensive work is done
on them.
Create an ar9003 directory whilst I'm here; ar9003 specific
chipset code will eventually live there.
with these ADC DC Gain/Offset calibrations.
The whole idea is to calibrate a pair of ADCs to compensate for any
differences between them.
The AR5416 returns lots of garbage, so there's no need to do the
calibration there.
The AR9160 returns 0 for secondary ADCs when calibrating 2.4ghz 20mhz
modes. It returns valid data for the secondary ADCs when calibrating
2.4ghz HT/40 and any 5ghz mode.
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.
The AR9100 at least doesn't have an external serial EEPROM
attached to the MAC; it instead stores the calibration data
in the normal system flash.
I believe earlier parts can do something similar but I haven't
experienced it first-hand.
This commit introduces an eepromdata pointer into the API but
doesn't at all commit to using it. A future commit will
include the glue needed to allow the AR9100 support code
to use this data pointer as the EEPROM.
the completion schedule from the hardware and returns AH_TRUE if
the hardware supports multi-rate retries (AR5212 and above); and
returns AH_FALSE if the hardware doesn't support multi-rate retries.
The sample rate module directly reads the TX completion descriptor
and extracts the TX schedule information from that. It will be
updated in a future commit to instead use this method to determine
the completion schedule.
Since we now have the source code, there's no reason to hide the diag codes
from other areas.
They live in the HAL as they form part of the HAL API and should still be treate
as "potentially flexible; don't publish as a public API." But since they're
already used as a public API (see follow-up commit), we may as well use
them in place of magic constants.
If it does, don't then try reprogramming the NF "cap" values (ie
what values are the "maximum" value the NF can be) - instead,
just leave the current CCA value as the NF cap.
This was inspired by some similar work from ath9k. It isn't
a 100% complete solution (as there may be some reason where a
high NF CCA/cap is written, causing the baseband to stop thinking it
is able to transmit, leading to stuck beacon and interface reset)
which I'll investigate and look at fixing in a later commit.
Obtained from: Linux
AR5416 and later chipsets.
ath_hal_calibrateN() calls the HAL calibrateN function with rxchainmask=0x1.
This is not necessarily the case for AR5416 and later chipsets.
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.
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
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@
