svn commit: r360888 - head/sys/contrib/dev/ath/ath_hal/ar9300

Adrian Chadd adrian at FreeBSD.org
Mon May 11 05:53:13 UTC 2020


Author: adrian
Date: Mon May 11 05:53:12 2020
New Revision: 360888
URL: https://svnweb.freebsd.org/changeset/base/360888

Log:
  [ar9300] Disable unconditionally reducing transmit power in the case of FCC.
  
  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

Modified:
  head/sys/contrib/dev/ath/ath_hal/ar9300/ar9300_eeprom.c
  head/sys/contrib/dev/ath/ath_hal/ar9300/ar9300_phy.c

Modified: head/sys/contrib/dev/ath/ath_hal/ar9300/ar9300_eeprom.c
==============================================================================
--- head/sys/contrib/dev/ath/ath_hal/ar9300/ar9300_eeprom.c	Mon May 11 02:33:37 2020	(r360887)
+++ head/sys/contrib/dev/ath/ath_hal/ar9300/ar9300_eeprom.c	Mon May 11 05:53:12 2020	(r360888)
@@ -3040,6 +3040,33 @@ ar9300_eeprom_set_transmit_power(struct ath_hal *ah,
     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 
      * this adjust call. ETSI and MKK does not have this requirement.
@@ -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++) {

Modified: head/sys/contrib/dev/ath/ath_hal/ar9300/ar9300_phy.c
==============================================================================
--- head/sys/contrib/dev/ath/ath_hal/ar9300/ar9300_phy.c	Mon May 11 02:33:37 2020	(r360887)
+++ head/sys/contrib/dev/ath/ath_hal/ar9300/ar9300_phy.c	Mon May 11 05:53:12 2020	(r360888)
@@ -55,10 +55,12 @@ static inline void ar9300_init_rate_txpower_stbc(struc
        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 mod
                             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 mod
                             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 mod
                             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 mod
                             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, cons
     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, con
     return;
 
 }
+#endif
 
 void ar9300_disp_tpc_tables(struct ath_hal *ah)
 {


More information about the svn-src-head mailing list