d/freebsd-skq
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

[ar9300] Disable unconditionally reducing transmit power in the case of FCC.

Browse Source 
Ok, yeah, the commit title is a bit misleading.

This has to do with CDD (cyclic delay diversity) - how this and later
wifi hardware transmits lower rates over more antennas.  Eg, if you're
transmitting legacy 11abg rates on 2 or 3 antennas, you COULD just
send them all at the same time or you could delay each by tens/hundreds
of nanoseconds to try and get some better diversity characteristics.

However, this has a fun side effect - the antenna pattern is no longer
a bunch of interacting dipoles, but are a bunch of interacting dipoles
plus a bunch of changing phases.  And it's frequency dependent - 50-200nS
is not exactly the same fraction of a wavelength across all of 2GHz or 5GHz!

Thus the power spectral density and maximum directional gain that you're
effectively getting is not .. well, as flat as it once was.

For more information, look up FCC/OET 13TR1003 in the FCC technical report
database.  It has pretty graphics and everything.

Anyway, the problem lies thusly - the CDD code just subtracts another 3dB
or 5dB for the lower rates based on transmit antenna configuration.
However, it's not done based on operating configuration and it doesn't
take into account how far from any regulatory limits the hardware is at.
It also doesn't let us do things like transmit legacy rates and frames
on a single antenna without losing up to 5dB when we absolutely don't
need to in that case (there's no CDD used when one antenna is used!)

This shows up as the hardware behaving even worse for longer distance links
at 20MHz because, well, those are the exact rates losing a bunch more
transmit power.

* For lower power NICs (ie the majority of what is out there!) it's highly
  unlikely we're going to hit anywhere near the PSD limits.
* It's doing it based on the existing limits from the CTL table (conformance
  testing limits) - this isn't the regulatory max!  It's what the NIC is
  allowed to put out in each frequency and rate configuration!  So things like
  band edges, power amplifier behaviour and maximum current draw apply here.
  Blindly subtracting 3 to 5dB from /this/ value is /very/ conservative..
* /and/ ath9k just plainly doesn't do any of this at all.

So, for now disable it and get the TX power back, thus matching what ath9k
in Linux is doing.  If/once I get some more cycles I'll look at making it
a bit more adaptive and really only kick in if we're a few dB away from
hard regulatory limits.

Tested:

* AR9344 (2GHz + SoC, 2x2 configuration) - AP and STA modes
* QCA9580 (5GHz 2x2 and 3x3 configurations) - AP and STA modes
This commit is contained in:
Adrian Chadd 2020-05-11 05:53:12 +00:00
parent 65bbba25d2
commit 6851341a33
2 changed files with 42 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

28
sys/contrib/dev/ath/ath_hal/ar9300/ar9300_eeprom.c
View File

@ -3039,6 +3039,33 @@ ar9300_eeprom_set_transmit_power(struct ath_hal *ah,
/* Save this for quick lookup */
ahp->reg_dmn = ath_hal_getctl(ah, chan);
/*
* After reading FCC/OET 13TR1003 (Directional Gain of IEEE 802.11
* MIMO devices employing cyclic delay diversity) and looking at what
* ath9k does, let's disable the CDD check until it's clearer exactly
* how the maximum cap should be applied here.
*
* Right now the CDD check is simply unconditionally reducing the
* gain of legacy and 1/2 stream rates depending upon the chainmask.
* (CDD is used when transmitting rates that don't already use up the
* full set of streams - eg OFDM or MCS0-7 on a 2 or 3 chain TX path.)
*
* It's dropping the 2-chain TX by 3dB and 3-chain by 5dB to "meet"
* power spectral density requirements but it's not currently taking
* into account how close to the regulatory limit the hardware/antenna
* system is already at. It doesn't help that the conductive testing
* limits have the array gain at 0dB for all AR9300/derivative
* configurations.
*
* It also doesn't let us do single chain transmit at the full allowed
* power for the regulatory/CTL limits as it subtracts it from what's
* programmed into the hardware.
*
* ath9k doesn't factor any of the CDD stuff into account, so I'm going
* to disable it here and in the TPC path until I get a better idea
* of what to really do here.
*/
#if 0
/*
* Always use CDD/direct per rate power table for register based approach.
* For FCC, CDD calculations should factor in the array gain, hence
@ -3050,6 +3077,7 @@ ar9300_eeprom_set_transmit_power(struct ath_hal *ah,
__func__);
ar9300_adjust_reg_txpower_cdd(ah, target_power_val_t2);
}
#endif
if (ar9300_eeprom_get(ahp, EEP_PAPRD_ENABLED)) {
for (i = 0; i < ar9300_rate_size; i++) {

14
sys/contrib/dev/ath/ath_hal/ar9300/ar9300_phy.c
View File

@ -55,10 +55,12 @@ static inline void ar9300_init_rate_txpower_stbc(struct ath_hal *ah,
const HAL_RATE_TABLE *rt, HAL_BOOL is40,
int rt_ss_offset, int rt_ds_offset,
int rt_ts_offset, u_int8_t chainmask);
#if 0
static inline void ar9300_adjust_rate_txpower_cdd(struct ath_hal *ah,
const HAL_RATE_TABLE *rt, HAL_BOOL is40,
int rt_ss_offset, int rt_ds_offset,
int rt_ts_offset, u_int8_t chainmask);
#endif
#define AR9300_11A_RT_OFDM_OFFSET 0
HAL_RATE_TABLE ar9300_11a_table = {
@ -442,6 +444,8 @@ ar9300_adjust_reg_txpower_cdd(struct ath_hal *ah,
((int16_t)AH_MIN((ahp->twice_antenna_reduction -
(ahp->twice_antenna_gain + AR9300_TXBF_2TX_ARRAY_GAIN)), 0));
cdd_power = ahp->upper_limit[1] + twice_array_gain;
HALDEBUG(ah, HAL_DEBUG_CALIBRATE, "%s: 2 chain; cdd_power=%d", __func__, cdd_power);
/* Adjust OFDM legacy rates as well */
for (i = ALL_TARGET_LEGACY_6_24; i <= ALL_TARGET_LEGACY_54; i++) {
if (power_per_rate[i] > cdd_power) {
@ -471,6 +475,7 @@ ar9300_adjust_reg_txpower_cdd(struct ath_hal *ah,
((int16_t)AH_MIN((ahp->twice_antenna_reduction -
(ahp->twice_antenna_gain + AR9300_TXBF_3TX_ARRAY_GAIN)), 0));
cdd_power = ahp->upper_limit[2] + twice_array_gain;
HALDEBUG(ah, HAL_DEBUG_CALIBRATE, "%s: 3 chain; cdd_power=%d", __func__, cdd_power);
/* Adjust OFDM legacy rates as well */
for (i = ALL_TARGET_LEGACY_6_24; i <= ALL_TARGET_LEGACY_54; i++) {
if (power_per_rate[i] > cdd_power) {
@ -531,6 +536,7 @@ ar9300_init_rate_txpower(struct ath_hal *ah, u_int mode,
AR9300_11NA_RT_HT_SS_OFFSET,
AR9300_11NA_RT_HT_DS_OFFSET,
AR9300_11NA_RT_HT_TS_OFFSET, chainmask);
#if 0
/* For FCC the array gain has to be factored for CDD mode */
if (is_reg_dmn_fcc(ath_hal_getctl(ah, chan))) {
ar9300_adjust_rate_txpower_cdd(ah, rt, is40,
@ -538,6 +544,7 @@ ar9300_init_rate_txpower(struct ath_hal *ah, u_int mode,
AR9300_11NA_RT_HT_DS_OFFSET,
AR9300_11NA_RT_HT_TS_OFFSET, chainmask);
}
#endif
break;
case HAL_MODE_11G:
ar9300_init_rate_txpower_cck(ah, rt, power_per_rate, chainmask);
@ -561,6 +568,7 @@ ar9300_init_rate_txpower(struct ath_hal *ah, u_int mode,
AR9300_11NG_RT_HT_SS_OFFSET,
AR9300_11NG_RT_HT_DS_OFFSET,
AR9300_11NG_RT_HT_TS_OFFSET, chainmask);
#if 0
/* For FCC the array gain needs to be factored for CDD mode */
if (is_reg_dmn_fcc(ath_hal_getctl(ah, chan))) {
ar9300_adjust_rate_txpower_cdd(ah, rt, is40,
@ -568,6 +576,7 @@ ar9300_init_rate_txpower(struct ath_hal *ah, u_int mode,
AR9300_11NG_RT_HT_DS_OFFSET,
AR9300_11NG_RT_HT_TS_OFFSET, chainmask);
}
#endif
break;
default:
HALDEBUG(ah, HAL_DEBUG_POWER_MGMT, "%s: invalid mode 0x%x\n",
@ -941,6 +950,10 @@ ar9300_init_rate_txpower_stbc(struct ath_hal *ah, const HAL_RATE_TABLE *rt,
return;
}
/*
* To see why this is disabled, look at ar9300_eeprom.c for FCC/OET 13TR1003.
*/
#if 0
static inline void
ar9300_adjust_rate_txpower_cdd(struct ath_hal *ah, const HAL_RATE_TABLE *rt,
HAL_BOOL is40,
@ -1037,6 +1050,7 @@ ar9300_adjust_rate_txpower_cdd(struct ath_hal *ah, const HAL_RATE_TABLE *rt,
return;
}
#endif
void ar9300_disp_tpc_tables(struct ath_hal *ah)
{