enables broadcast filtering. Make sure to clear the bit to receive
broadcast frames. While I'm here rename the bit definition to
reflect reality.
Reported by: brad@OpenBSD
MFC after: 1 week
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.
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.
been undergoing test for some weeks. This improves the RX
mbuf handling to avoid system hang due to depletion. Thanks
to all those who have been testing the code, and to Beezar
Liu for the design changes.
Next the igb driver is updated for similar RX changes, but
also to add new features support for our upcoming i350 family
of adapters.
MFC after a week
chipsets that do not have an HT slave at 0:0:0:0. The Linux quirk is
actually specific to Nvidia chipsets and the check I had added was in
the wrong place.
Prodded by: nathanw
- Always enable the HyperTransport MSI mapping window for HyperTransport
to PCI bridges (these show up as HyperTransport slave devices).
The mapping windows in PCI-PCI bridges are enabled by existing code
in the PCI-PCI bridge driver as MSI requests propagate up the device
tree, but Host-PCI bridges don't really show up in that tree.
- If the PCI device at domain 0 bus 0 slot 0 function 0 is not a
HyperTransport device, then blacklist MSI on any other HT devices in
the system. Linux has a similar quirk.
PR: kern/155442
Tested by: Zack Dannar zdannar of gmail
MFC after: 1 week
With this change, driver may not notice updated descriptor status
change when bounce buffers are active. However, rxeof() in next run
will handle the synchronization.
Change dc_rxeof() a bit to return the number of processed frames in
RX descriptor ring. Previously it returned the number of frames
that were successfully passed to upper stack which in turn means it
ignored frames that were discarded due to errors. The number of
processed frames in RX descriptor ring is used to detect whether
driver is out of sync with controller's current descriptor pointer.
Returning number of processed frames reduces unnecessary (probably
wrong) re-synchronization.
Reviewed by: marius
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.
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.
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.
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.
also does this for sound drivers it's probably not necessary for all
combinations of controllers and drivers. However, given that our sound
drivers completely lack bus_dmamap_sync(9) calls this at least serves
as a workaround when enabling use of the IOMMU streaming buffers on
sparc64 and generally for arm and mips.
MFC after: 2 weeks
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
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.
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.
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.
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.
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.)
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.
value. Controllers that always require "store and forward" mode(
Davicom and PNIC 82C168) have no way to recover from TX underrun
except completely reinitializing hardware. Previously only Davicom
was reinitialized and the TX FIFO threshold was changed not to use
"store and forward" mode after reinitialization since the default
FIFO threshold value was 0. This effectively disabled Davicom
controller's "store and forward" mode once it encountered TX
underruns. In theory, this can cause watchodg timeouts.
Intel 21143 controller requires TX MAC should be idle before
changing TX FIFO threshold. So driver tried to disable TX MAC and
checked whether it saw the idle state of TX MAC. Driver should
perform full hardware reinitialization on failing to enter to idle
state and it should not touch TX MAC again once it performed full
reinitialization.
While I'm here remove resetting TX FIFO threshold to 0 when
interface is put into down state. If driver ever encountered TX
underrun, it's likely to trigger TX underrun again whenever
interface is brought to up again. Keeping old/learned TX FIFO
threshold value shall reduce the chance of seeing TX underrns in
next run.
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
the ataahci(4) and atamarvell(4) drivers share it between the host and
the controller.
- Spell some zeros as BUS_DMA_WAITOK when used as bus_dmamem_alloc() flags.
MFC after: 2 weeks
