| 8896f365 | 19-Dec-2024 |
Adrian Chadd <adrian@FreeBSD.org> |
rtwn: allow firmware rate control to be enabled for rtl8192cu
Although there's no RTS/CTS rate control available yet, the support
is enough to enable firmware rate control for experimenting.
This w
rtwn: allow firmware rate control to be enabled for rtl8192cu
Although there's no RTS/CTS rate control available yet, the support
is enough to enable firmware rate control for experimenting.
This won't be enabled by default - users will need to set a tunable
before loading the driver (eg kenv dev.rtwn.0.ratectl=2) but it is
enough for experimentation, feedback and continued work.
Locally tested:
* RTL8192CU, STA mode
Differential Revision: https://reviews.freebsd.org/D48143
Reviewed by: bz, emaste
show more ...
|
| ce7fca19 | 19-Dec-2024 |
Adrian Chadd <adrian@FreeBSD.org> |
rtwn: refactor out the r92c path protection decision / configuration
* refactor out the r92c path protection (RTS/CTS) decision
* handle firmware rate control being enabled - if DRVRATE isn't
set
rtwn: refactor out the r92c path protection decision / configuration
* refactor out the r92c path protection (RTS/CTS) decision
* handle firmware rate control being enabled - if DRVRATE isn't
set then the RTSRATE field is ignored and instead RRSR/INIRTS
registers are used (and the firmware/hardware will do RTS
rate adaptation / retry.)
* when making protection decisions with firmware rate control,
default to the channel mode rather than rate index.
This works on RTL8192CU both with firmware rate control and driver
rate control.
Locally tested:
* RTL8192CU, STA - firmware and net80211 rate control
Differential Revision: https://reviews.freebsd.org/D48142
show more ...
|
| 307f9c35 | 15-Dec-2024 |
Adrian Chadd <adrian@FreeBSD.org> |
rtwn: only set INIRATE if we're not doing firmware rate control.
This register (array) controls the initial rate to use for each
MACID. There's no need to set it if firmware rate control is enabled
rtwn: only set INIRATE if we're not doing firmware rate control.
This register (array) controls the initial rate to use for each
MACID. There's no need to set it if firmware rate control is enabled -
it'll actually be under firmware control (and we can read it back to
see what choices the firmware is making.)
Locally tested:
* RTL8188EU, STA
* RTL8192CU, STA
* RTL8192EU, STA
Differential Revision: https://reviews.freebsd.org/D48094
Reviewed by: bz
show more ...
|
| af2e102c | 15-Dec-2024 |
Adrian Chadd <adrian@FreeBSD.org> |
rtwn: enable periodic TX reporting support on RTL8188EU NICs.
The RTL8188E firmware doesn't have the "full" offload firmware
rate control. Instead, the vendor driver has a bunch of logic
in the dri
rtwn: enable periodic TX reporting support on RTL8188EU NICs.
The RTL8188E firmware doesn't have the "full" offload firmware
rate control. Instead, the vendor driver has a bunch of logic
in the driver for rate probing and selection.
Part of this is the periodic TX report - which uploads a summary
of multi-rate retries and drops per MAC. Using it drastically
cuts down on the TX notifications - it's fired from a timer
(defaulting to ~ 1.6 seconds) and is a single receive frame in
the normal bulk RX path.
I've not ported / reimplemented the whole vendor driver rate adaption
code - instead, I'm just using the normal net80211 rate control APIs.
It seems to behave OK - I get 25-30mbit down and 20mbit up using TCP/
speedtest.
Locally tested:
* RTL8188EU, STA mode
Differential Revision: https://reviews.freebsd.org/D48088
Reviewed by: fuz, bz
Obtained from: https://github.com/lwfinger/rtl8188eu/blob/master/hal/Hal8188ERateAdaptive.c
show more ...
|
| 300c843b | 14-Dec-2024 |
Adrian Chadd <adrian@FreeBSD.org> |
rtwn: bring the r92c rate control setup selection in line with tx descriptors
The rate control message was doing 11g+11n without 11b rates, but
the TX descriptor setup supports also falling back on
rtwn: bring the r92c rate control setup selection in line with tx descriptors
The rate control message was doing 11g+11n without 11b rates, but
the TX descriptor setup supports also falling back on 11b rates
when doing multi-rate retry / per-descriptor rate control.
So, line them up. They're not exactly the same as the TX path
supports pure-N and pure-G modes which the rate control configuration
does not, but there'll need to be a lot more work on supporting
those operating modes anyway (around things like self-generated
frame rate control/masks, beacon config, RTS/CTS selection, etc.)
Locally tested:
* RTL8192CU, STA mode
Differential Revision: https://reviews.freebsd.org/D48081
Reviewed by: bz
show more ...
|
| eb631451 | 11-Dec-2024 |
Adrian Chadd <adrian@FreeBSD.org> |
rtwn: disable a workaround introduced earlier for RTL8192CU TX performance
I'm unable to reproduce the original problem with my RTL8192CU USB
devices with the current codebase and I can't find any r
rtwn: disable a workaround introduced earlier for RTL8192CU TX performance
I'm unable to reproduce the original problem with my RTL8192CU USB
devices with the current codebase and I can't find any reference
to what this power register is doing - I see it defined in drivers,
but it's not described or used anywhere.
This reverts 7f740971658d71c1ee95ee68032b4696c1684845 -
rtwn_usb(4): fix Tx instability with RTL8192CU chipsets
In any case being able to do higher rate RTS/CTS is beneficial.
Local testing:
* rtl8192cu, STA mode, TX/RX testing
PR: 233949
Differential Revision: https://reviews.freebsd.org/D48026
Reviewed by: imp
show more ...
|
| aaaca5f2 | 10-Dec-2024 |
Adrian Chadd <adrian@FreeBSD.org> |
rtwn: add a default OFDM / CCK rate for self-generated frames
I noticed during testing that the MAC was generating MCS7 ACKs and
MCS7 block-ACK frames in response to MCS frames from its peer.
This i
rtwn: add a default OFDM / CCK rate for self-generated frames
I noticed during testing that the MAC was generating MCS7 ACKs and
MCS7 block-ACK frames in response to MCS frames from its peer.
This is very suboptimal - it means that unless you're very close
to your peer (in this case a 2GHz AP), you'll end up failing a lot
of ACKs.
Linux faced the opposite problem in rtl8xxxu - the rate set being
programmed in here included a lot MORE rates, including MCS 0->7
and OFDM 6M->54M. This meant that they were INTENTIONALLY telling
the hardware to transmit at higher rates, and their fix was to
mask out the higher rates so self-generated frames don't try the
high rates at all.
Now, I am not sure why I'm not seeing any OFDM or HT basic rates.
We don't mark any OFDM / HT rates as basic in net80211 (in
ieee80211_phy.c) so I'm going to need to go and do a review of the
standard to see what's up. Additionally, the HT rate set that we
populate isn't tagging any of the HT rates as IEEE80211_RATE_BASIC,
so the code I added for now is a no-op.
So:
* Extend rtwn_get_rates() and its consumers to populate the HT rateset
with basic rates if they're provided
* Add a default 2GHz / 5GHz mask, inspired by linux, applied over the
basic rates provided.
* Make sure there's at least an OFDM rate (for 2G/5G) rate available if
the peer node is HT, which avoids the MAC defaulting to MCS7 when
generating ACK/block-ACK.
* Add register definitions for INIDATA/INIRTS, which set the default
data rate when the driver doesn't specify the initial data / RTS/CTS
rates in the TX descriptor.
* Leave a comment about why I've modified the mask from Linux.
Locally tested:
* RTL8192CU, STA mode
* RTL8188EU, STA mode
* RTL8192EU, STA mode
* RTL8812AU, STA mode
Differential Revision: https://reviews.freebsd.org/D48019
Reviewed by: bz
show more ...
|
| 371a4ee9 | 09-Dec-2024 |
Adrian Chadd <adrian@FreeBSD.org> |
rtwn: add SGI flag for the rate control message
This is straight from all the drivers, linux and vendor.
Differential Revision: https://reviews.freebsd.org/D48004
Reviewed by: bz, imp |
| 745a8582 | 08-Dec-2024 |
Adrian Chadd <adrian@FreeBSD.org> |
rtwn: update rtwn_get_rates() to separate out the CCK/OFDM and HT rates
The 32 bit bitmap is enough for CCK/OFDM rates and MCS0..15, but
won't work for > MCS15, nor VHT rates.
So, break out the leg
rtwn: update rtwn_get_rates() to separate out the CCK/OFDM and HT rates
The 32 bit bitmap is enough for CCK/OFDM rates and MCS0..15, but
won't work for > MCS15, nor VHT rates.
So, break out the legacy rates and HT rates.
* break the rates and htrates out
* document which calls are looking up basic rates and which care
about the rates themselves
* ensure the rate bitmap passed into the rate control firmware call
(which isn't enabled yet!) is capped at 28 bits so they don't
set the mode field.
Differential Revision: https://reviews.freebsd.org/D47993
Reviewed by: bz, imp
show more ...
|
| 0ea7f8ca | 08-Dec-2024 |
Adrian Chadd <adrian@FreeBSD.org> |
rtwn: try enforcing net80211 regulatory / txpower limits for 11n chips
This is an attempt to reverse engineer what the actual transmit power
calculations are doing and apply net80211 limits on them.
rtwn: try enforcing net80211 regulatory / txpower limits for 11n chips
This is an attempt to reverse engineer what the actual transmit power
calculations are doing and apply net80211 limits on them. It doesn't
look as simple as just applying the check at the end - there are plenty
of places where offsets are calculated between different PHY modes and
1 / 2 antenna MCS transmit rates.
There are also some places where the offset being added is negative,
so handle the potential underflow so when things hit 0, they don't
just wrap and cause the maximum transmit power into the registers.
This is being done to aide in power/performance debugging - if there
are issues with the transmit power being wrongly calculated and are too
high, the output waveform will be distorted and it will effect performance.
Being able to drop the transmit power by a few dB here and there can
quickly identify if this is happening (because suddenly higher MCS
rates / OFDM rates suddenly work better!)
I've tested each NIC through the transmit power values from 0 dBm
to 30dBm via ifconfig (and they're all capped far before that,
normally around 20-25dBm) and they're not underflowing.
Locally tested:
* RTL8192CU, STA
* RTL8192EU, STA
* RTL8188EU, STA
Differential Revision: https://reviews.freebsd.org/D47987
Reviewed by: bz, imp
show more ...
|
| 6858c6b1 | 08-Dec-2024 |
Adrian Chadd <adrian@FreeBSD.org> |
rtwn: refactor out the TX power register power dump, condense output
* Refactor out the TX power register register dump - it's done in
a couple places and it makes sense to refactor it.
* Condens
rtwn: refactor out the TX power register power dump, condense output
* Refactor out the TX power register register dump - it's done in
a couple places and it makes sense to refactor it.
* Condense the output into a few lines per transmit chain. It's
very long with the 8 and 16 MCS rates, and it made it difficult
to eyeball what's going on when tweaking TX power.
Differential Revision: https://reviews.freebsd.org/D47986
Reviewed by: bz, imp
show more ...
|
| 977679d6 | 06-Dec-2024 |
Adrian Chadd <adrian@FreeBSD.org> |
rtwn: remove unused rate configuration code for management traffic.
After discussion with the rtlwifi maintainers, it looks like this
path isn't even used.
(And it's part of the firmware rate contr
rtwn: remove unused rate configuration code for management traffic.
After discussion with the rtlwifi maintainers, it looks like this
path isn't even used.
(And it's part of the firmware rate control path which we currently
don't enable for other reasons.)
Differential Revision: https://reviews.freebsd.org/D47938
show more ...
|
| 3d699261 | 04-Dec-2024 |
Adrian Chadd <adrian@FreeBSD.org> |
rtwn: expand the ridx numbers to include VHT; add accessor macros
* expand the ridx field all the way through 4x4 11n (MCS0..MCS31)
* and then expand it through VHT 4x4 (MCS0..9 for each stream)
* a
rtwn: expand the ridx numbers to include VHT; add accessor macros
* expand the ridx field all the way through 4x4 11n (MCS0..MCS31)
* and then expand it through VHT 4x4 (MCS0..9 for each stream)
* add accessor macros to check if the rate is HT, VHT
* use accessor macros to check if the rate is HT rather than
comparing it against OFDM54 or RIDX_HT_MCS(0); the values
aobve HT MCS will be VHT, and we don't want to trigger on those!
* add a couple of appropriate TODO VHT bits in the TX path
Locally tested:
* RTL8192CU, STA mode
* RTL8188EU, STA mode
* RTL8821AU, STA mode
* RTL8192EU, STA mode
Differential Revision: https://reviews.freebsd.org/D47896
show more ...
|