From owner-svn-src-all@freebsd.org Mon May 11 05:53:13 2020 Return-Path: Delivered-To: svn-src-all@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 8E00E2D71FB; Mon, 11 May 2020 05:53:13 +0000 (UTC) (envelope-from adrian@FreeBSD.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 49L98T3JSTz46Yg; Mon, 11 May 2020 05:53:13 +0000 (UTC) (envelope-from adrian@FreeBSD.org) Received: from repo.freebsd.org (repo.freebsd.org [IPv6:2610:1c1:1:6068::e6a:0]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 6CA9A19D36; Mon, 11 May 2020 05:53:13 +0000 (UTC) (envelope-from adrian@FreeBSD.org) Received: from repo.freebsd.org ([127.0.1.37]) by repo.freebsd.org (8.15.2/8.15.2) with ESMTP id 04B5rDUf057601; Mon, 11 May 2020 05:53:13 GMT (envelope-from adrian@FreeBSD.org) Received: (from adrian@localhost) by repo.freebsd.org (8.15.2/8.15.2/Submit) id 04B5rDq8057599; Mon, 11 May 2020 05:53:13 GMT (envelope-from adrian@FreeBSD.org) Message-Id: <202005110553.04B5rDq8057599@repo.freebsd.org> X-Authentication-Warning: repo.freebsd.org: adrian set sender to adrian@FreeBSD.org using -f From: Adrian Chadd Date: Mon, 11 May 2020 05:53:13 +0000 (UTC) To: src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org Subject: svn commit: r360888 - head/sys/contrib/dev/ath/ath_hal/ar9300 X-SVN-Group: head X-SVN-Commit-Author: adrian X-SVN-Commit-Paths: head/sys/contrib/dev/ath/ath_hal/ar9300 X-SVN-Commit-Revision: 360888 X-SVN-Commit-Repository: base MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 May 2020 05:53:13 -0000 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) {