This can significantly reduce scan duration thus saving time and power.
EBS failure reported by FW disables EBS for current connection. It is
re-enabled upon new connection attempt on any WLAN interface.
Obtained from: dragonflybsd.git 89f579e9823a5c446ca172cf82bbc210d6a054a4
Add support for early boot access to NVRAM variables, using a new
bhnd_nvram_data_getvar_direct() API to support zero-allocation direct
reading of NVRAM variables from a bhnd_nvram_io instance backed by the
CFE NVRAM device.
Approved by: adrian (mentor)
Differential Revision: https://reviews.freebsd.org/D9913
r315083 essentially reverted r263954 which was made for a good reason,
but didn't take into account AACRAID_DEBUG.
Now both types of build should be clean.
MFC after: 5 days
No MFC to: stable/10
* All the supported firmwares have these flags set.
* This removes the following flags:
IWM_UCODE_TLV_FLAGS_PM_CMD_SUPPORT,
IWM_UCODE_TLV_FLAGS_NEWBT_COEX,
IWM_UCODE_TLV_FLAGS_BF_UPDATED,
IWM_UCODE_TLV_FLAGS_D3_CONTINUITY_API,
IWM_UCODE_TLV_FLAGS_STA_KEY_CMD,
IWM_UCODE_TLV_FLAGS_DEVICE_PS_CMD,
IWM_UCODE_TLV_FLAGS_SCHED_SCAN,
IWM_UCODE_TLV_FLAGS_RX_ENERGY_API,
IWM_UCODE_TLV_FLAGS_TIME_EVENT_API_V2
* Also remove definitions and code for dealing with the v1 time-event api.
* Remove unneeded calc_rssi() function.
Obtained from: dragonflybsd.git d078c812418d0e2c3392e99fa25fc776d07bdfad
Let firmware do its best first, and if it can't, try software recovery.
I would remove software timeout handler completely, but found bunch of
complains on command timeout on sparc64 mailing list few years ago, so
better be safe in case of interrupt loss.
MFC after: 2 weeks
mmc(4). For the most part, this consists of support for:
- Switching the signal voltage (VCCQ) to 1.8 V or (if supported
by the host controller) to 1.2 V,
- setting the UHS mode as appropriate in the SDHCI_HOST_CONTROL2
register,
- setting the power class in the eMMC device according to the
core supply voltage (VCC),
- using different bits for enabling a bus width of 4 and 8 bits
in the the eMMC device at DDR or higher timings respectively,
- arbitrating timings faster than high speed if there actually
are additional devices on the same MMC bus.
Given that support for DDR52 is not denoted by SDHCI capability
registers, availability of that timing is indicated by a new
quirk SDHCI_QUIRK_MMC_DDR52 and only enabled for Intel SDHCI
controllers so far. Generally, what it takes for a sdhci(4)
front-end to enable support for DDR52 is to hook up the bridge
method mmcbr_switch_vccq (which especially for 1.2 V signaling
support is chip/board specific) and the sdhci_set_uhs_timing
sdhci(4) method.
As a side-effect, this change also fixes communication with
some eMMC devices at SDR high speed mode with 52 MHz due to
the signaling voltage and UHS bits in the SDHCI controller no
longer being left in an inappropriate state.
Compared to 52 MHz at SDR high speed which typically yields
~45 MB/s with the eMMC chips tested, throughput goes up to
~80 MB/s at DDR52.
Additionally, this change already adds infrastructure and quite
some code for modes up to HS400ES and SDR104 respectively (I did
not want to add to much stuff at a time, though). Essentially,
what is still missing in order to be able to activate support
for these latter is is support for and handling of (re-)tuning.
o In sdhci(4), add two tunables hw.sdhci.quirk_clear as well as
hw.sdhci.quirk_set, which (when hooked up in the front-end)
allow to set/clear sdhci(4) quirks for debugging and testing
purposes. However, especially for SDHCI controllers on the
PCI bus which have no specific support code so far and, thus,
are picked up as generic SDHCI controllers, hw.sdhci.quirk_set
allows for setting the necessary quirks (if required).
o In mmc(4), check and handle the return values of some more
function calls instead of assuming that everything went right.
In case failures actually are not problematic, indicate that
by casting the return value to void.
Reviewed by: jmcneill
For 24xx and above use 2 vectors (default and response queue).
For 26xx and above use 3 vectors (default, response and ATIO queues).
Due to global lock interrupt hardlers never run simultaneously now, but
at least this allows to save one regitster read per interrupt.
MFC after: 2 weeks
Since we support RQSTYPE_RPT_ID_ACQ, that functionality is only useful
in loop mode, which probably doesn't worth having this hack in 2017.
MFC after: 2 weeks
When I initially did this 11n TX work in days of yonder, my 802.11 standards
clue was ... not as finely tuned. One of the things in 802.11-2012 (which
I guess technically was after I did this work, but I'm sure it was like this
in the previous rev?) is that among other traffic classes, three things are
important:
* group addressed frames should be default non-QoS, even if they're QoS frames, and
* group addressed frames should have a seqno out of a different space than the
per-TID QoS one; and because of this
* group addressed frames, being non-QoS, should never be in the Block-ACK window
for TX.
Now, net80211 and now this code cheats by using the non-QOS TID, but ideally
we'd introduce a separate seqno space just for multicast/group traffic for
TX and RX comparison.
Later extensions (eg reliable multicast / multimedia) express what one should do
when doing multicast traffic in a TID. Now, technically we /could/ do group traffic
as QoS traffic and throw it into a per-TID seqno space, but this definitely
introduces ordering issues when you take into account things like CABQ behaviour.
(Ie, if some traffic in the TID goes into the CABQ and some doesn't, because
it's doing a split of multicast and non-multicast traffic, then you have
seqno ordering issues.)
So, until someone implements 802.11vv reliable multicast / multimedia extensions,
group traffic is non-QoS.
Next, software/hardware queue TID mapping. In the past I believed the WME tagging
of frames because well, net80211 had a habit of tagging things like management
traffic with it. But, then we also map QoS traffic categories to TIDs as well.
So, we should obey the TID! But! then it put some management traffic into higher
WME categories too, as those frames don't have QoS TIDs. But! It'd do things like
put things like QoS action frames into higher WME categories, when they should
be kept in-order with the rest of the traffic for that TID. So! Given all of this,
the ath(4) driver does overrides to not trust the WME category.
I .. am undoing some of this. Now, the TID has a 1:1 mapping to the hardware
queue. The TID is the primary source of truth now for all QoS traffic.
The WME is only used for non-QoS traffic. This now means that any TID traffic
queued should be consistently queued regardless of WME, so things like the
"TX finished, do more TX" that is occuring right now for transmit handling
should be "better".
The consistent {TID, WME} -> hardware queue mapping is important for
transmit completion. It's used to schedule more traffic for that
particular TID, because that {many TID}:{1 TXQ} mapping in ath_tx_tid_sched()
is used for driving completion. Ie, when the hardware queue completes,
it'll walk that list of scheduled TIDs attached to that TXQ.
The eventual aim is to get ready for some other features around putting
some data into other hardware queues (eg for better PS-POLL support,
uAPSD, support, correct-er TDMA support, etc) which requires that
I tidy all of this up in preparation for then introducing further
TID scheduling that isn't linked to a hardware TXQ (likely a per-WME, per-TID
driver queue, and a per-node driver queue) to enable that.
Tested:
* AR9380, STA mode
* AR9380, AR9580, AP mode
There were two copies of the code: one in generic code was half-broken, and
another in platform code was never called. Leave only one in generic code
and working.
MFC after: 2 weeks
