From: Bitterblue Smith <rtl8821cerfe2@gmail.com>
To: luka.gejak@linux.dev, Ping-Ke Shih <pkshih@realtek.com>
Cc: linux-wireless@vger.kernel.org, linux-kernel@vger.kernel.org,
Michael Straube <straube.linux@gmail.com>,
Peter Robinson <pbrobinson@gmail.com>
Subject: Re: [PATCH 17/19] wifi: rtw88: calibrate and tune the PHY for RTL8723BS
Date: Sat, 25 Jul 2026 00:05:15 +0300 [thread overview]
Message-ID: <efef00cb-8369-48d5-859f-623663ddac56@gmail.com> (raw)
In-Reply-To: <20260724183310.197159-1-luka.gejak@linux.dev>
On 24/07/2026 21:33, luka.gejak@linux.dev wrote:
> From: Luka Gejak <luka.gejak@linux.dev>
>
> Three PHY adjustments this chip needs. The IQK has to run once at the
> first power on and not again when leaving IPS, because repeating it
> disturbs a working link; the vendor driver calibrates only during the
> initial hal_init for the same reason. Loading the parameter tables
> overwrites the per-rate TX AGC values with the by-rate cache, so the
> vendor power-by-rate bytes have to be restored after a channel set. And
> the scan-time initial gain has to be lowered, without which the site
> survey does not reliably hear an AP that the chip associates with fine.
These are three separate things, so they should be three patches.
>
> Signed-off-by: Luka Gejak <luka.gejak@linux.dev>
> ---
> drivers/net/wireless/realtek/rtw88/main.c | 114 ++++++++++++++++++++++
> drivers/net/wireless/realtek/rtw88/main.h | 2 +
> 2 files changed, 116 insertions(+)
>
> diff --git a/drivers/net/wireless/realtek/rtw88/main.c b/drivers/net/wireless/realtek/rtw88/main.c
> index 16228cae252e..a2ef4479f408 100644
> --- a/drivers/net/wireless/realtek/rtw88/main.c
> +++ b/drivers/net/wireless/realtek/rtw88/main.c
> @@ -43,6 +43,89 @@ MODULE_PARM_DESC(disable_lps_deep, "Set Y to disable Deep PS");
> MODULE_PARM_DESC(support_bf, "Set Y to enable beamformee support");
> MODULE_PARM_DESC(debug_mask, "Debugging mask");
>
> +#define RTW8723BS_REG_BB_SEL_BTG 0x0948
> +#define RTW8723BS_SCAN_IGI 0x1e
> +
> +struct rtw8723bs_txagc_entry {
> + u8 rate;
> + u8 pwr_idx;
> +};
> +
> +/* Vendor/staging per-rate TXAGC PG bytes for 8723BS 2.4 GHz. */
> +static const struct rtw8723bs_txagc_entry rtw8723bs_pg_txagc[] = {
> + { DESC_RATE1M, 0x38 }, { DESC_RATE2M, 0x36 },
> + { DESC_RATE5_5M, 0x34 }, { DESC_RATE11M, 0x32 },
> + { DESC_RATE6M, 0x44 }, { DESC_RATE9M, 0x44 },
> + { DESC_RATE12M, 0x42 }, { DESC_RATE18M, 0x40 },
> + { DESC_RATE24M, 0x38 }, { DESC_RATE36M, 0x36 },
> + { DESC_RATE48M, 0x32 }, { DESC_RATE54M, 0x28 },
> + { DESC_RATEMCS0, 0x44 }, { DESC_RATEMCS1, 0x42 },
> + { DESC_RATEMCS2, 0x40 }, { DESC_RATEMCS3, 0x38 },
> + { DESC_RATEMCS4, 0x36 }, { DESC_RATEMCS5, 0x34 },
> + { DESC_RATEMCS6, 0x30 }, { DESC_RATEMCS7, 0x26 },
> +};
> +
> +/* Lower the scan-time initial gain so the 8723BS SDIO site-survey hears the AP. */
This behaviour is already implemented for all the chips, although with
even higher gain (0x1c) than what you're setting here (0x1e). See
rtw_phy_dig_set_max_coverage(). Does it not work?
> +static void rtw_scan_set_8723bs_igi(struct rtw_dev *rtwdev)
> +{
> + if (!rtw_is_8723bs(rtwdev))
> + return;
> +
> + rtw_write32_mask(rtwdev, REG_RXIGI_A, MASKBYTE0, RTW8723BS_SCAN_IGI);
> +}
> +
> +/* rtw_load_table() only populates the by-rate cache; restore the staging
> + * 8723BS PG bytes after the generic channel power update and push them to the
> + * chip TXAGC registers.
> + */
> +static void rtw8723bs_reapply_pg_txagc(struct rtw_dev *rtwdev)
> +{
> + struct rtw_hal *hal = &rtwdev->hal;
> + u8 path;
> + int i;
> +
> + if (!rtw_is_8723bs(rtwdev) || hal->current_band_type != RTW_BAND_2G)
This chip only handles the 2.4 GHz band, so checking the current band
should not be necessary.
> + return;
> +
> + mutex_lock(&hal->tx_power_mutex);
> + for (path = 0; path < hal->rf_path_num && path < RTW_RF_PATH_MAX; path++)
> + for (i = 0; i < ARRAY_SIZE(rtw8723bs_pg_txagc); i++)
> + hal->tx_pwr_tbl[path][rtw8723bs_pg_txagc[i].rate] =
> + rtw8723bs_pg_txagc[i].pwr_idx;
> + rtwdev->chip->ops->set_tx_power_index(rtwdev);
With this you are always setting the same TX power, hardcoded in
rtw8723bs_pg_txagc. What is the reason for that?
Normally the TX power depends on values burned into the chip's efuse
(so they vary from device to device), and values hardcoded into the
driver are only used if there is nothing in the chip's efuse.
> + mutex_unlock(&hal->tx_power_mutex);
> +}
> +
> +/* Staging runs PHY_IQCalibrate_8723B() only during initial hal_init, never on
> + * IPS leave. Match that: run IQK once on the first power-on, then on later
> + * (IPS-leave) power-ons just restore the PTA antenna path and reset RF_WLINT.
> + */
In rtw88 the IQ calibration is normally done in the phy_calibration
function (from rtw_chip_ops) which runs right before connecting to a
network, not in the power on code. Wouldn't that be fine for this chip
too?
> +static void rtw_power_on_8723bs_sdio_rfk(struct rtw_dev *rtwdev)
> +{
> + const struct rtw_chip_info *chip = rtwdev->chip;
> + struct rtw_efuse *efuse = &rtwdev->efuse;
> + u32 pta_path;
> + u32 saved_path;
> +
> + if (!rtw_is_8723bs(rtwdev) || !chip->ops->phy_calibration)
> + return;
> +
> + pta_path = (efuse->bt_setting & BIT(6)) ? 0x80 : 0x200;
> +
> + if (rtwdev->initial_rfk_done) {
> + rtw_write32(rtwdev, RTW8723BS_REG_BB_SEL_BTG, pta_path);
> + rtw_write_rf(rtwdev, RF_PATH_A, RF_WLINT, RFREG_MASK, 0x0780);
> + return;
> + }
> +
> + saved_path = rtw_read32(rtwdev, RTW8723BS_REG_BB_SEL_BTG);
> + rtw_write32(rtwdev, RTW8723BS_REG_BB_SEL_BTG, pta_path);
> + chip->ops->phy_calibration(rtwdev);
> + rtwdev->need_rfk = false;
> + rtw_write32(rtwdev, RTW8723BS_REG_BB_SEL_BTG, saved_path);
> + rtwdev->initial_rfk_done = true;
> +}
> +
> static struct ieee80211_channel rtw_channeltable_2g[] = {
> {.center_freq = 2412, .hw_value = 1,},
> {.center_freq = 2417, .hw_value = 2,},
> @@ -904,6 +987,8 @@ void rtw_set_channel(struct rtw_dev *rtwdev)
>
> rtw_phy_set_tx_power_level(rtwdev, center_chan);
>
> + rtw8723bs_reapply_pg_txagc(rtwdev);
> +
> /* if the channel isn't set for scanning, we will do RF calibration
> * in ieee80211_ops::mgd_prepare_tx(). Performing the calibration
> * during scanning on each channel takes too long.
> @@ -1429,6 +1514,34 @@ int rtw_power_on(struct rtw_dev *rtwdev)
> rtw_fw_send_phydm_info(rtwdev);
>
> wifi_only = !rtwdev->efuse.btcoex;
> +
> + /* 8723BS SDIO: on an IPS-leave power-on (IQK already done once) skip the
> + * BT-path coex init entirely - scan_workaround re-establishes the PTA /
> + * coex state. Run the once-only IQK via the RFK helper; on the first
> + * power-on, finalise coex with the vendor init H2C toggle that enables
> + * the 8051 management TX scheduler.
> + */
> + if (rtw_is_8723bs(rtwdev)) {
> + bool ips_wake = rtwdev->initial_rfk_done;
> +
> + if (!ips_wake)
> + rtw_coex_power_on_setting(rtwdev);
> +
> + rtw_power_on_8723bs_sdio_rfk(rtwdev);
> +
> + if (!ips_wake) {
> + rtw_coex_init_hw_config(rtwdev, wifi_only);
> + rtw_fw_coex_tdma_type(rtwdev, 0x08, 0x00, 0x00, 0x00, 0x00);
> + rtw_fw_set_gnt_bt(rtwdev, 1);
> + rtw_fw_coex_ant_sel_rsv(rtwdev, 0, 0);
> + rtw_fw_query_bt_info(rtwdev);
> + rtw_fw_coex_tdma_type(rtwdev, 0x08, 0x00, 0x00, 0x00, 0x00);
> + rtw_fw_set_gnt_bt(rtwdev, 0);
> + }
> +
> + return 0;
> + }
> +
> rtw_coex_power_on_setting(rtwdev);
> rtw_coex_init_hw_config(rtwdev, wifi_only);
>
> @@ -1485,6 +1598,7 @@ void rtw_core_scan_start(struct rtw_dev *rtwdev, struct rtw_vif *rtwvif,
> set_bit(RTW_FLAG_SCANNING, rtwdev->flags);
>
> rtw_phy_dig_set_max_coverage(rtwdev);
> + rtw_scan_set_8723bs_igi(rtwdev);
> }
>
> void rtw_core_scan_complete(struct rtw_dev *rtwdev, struct ieee80211_vif *vif,
> diff --git a/drivers/net/wireless/realtek/rtw88/main.h b/drivers/net/wireless/realtek/rtw88/main.h
> index aa09fef8c19f..c6d993e989dd 100644
> --- a/drivers/net/wireless/realtek/rtw88/main.h
> +++ b/drivers/net/wireless/realtek/rtw88/main.h
> @@ -2151,6 +2151,8 @@ struct rtw_dev {
> struct rtw_wow_param wow;
>
> bool need_rfk;
> + /* Run the initial IQK once, not on every IPS leave. */
> + bool initial_rfk_done;
> struct completion fw_scan_density;
> bool ap_active;
>
next prev parent reply other threads:[~2026-07-24 21:05 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-24 18:18 [PATCH 00/19] wifi: rtw88: preparations for RTL8723B/RTL8723BS luka.gejak
2026-07-24 18:18 ` [PATCH 01/19] wifi: rtw88: add the RTL8723B chip type and SDIO helper luka.gejak
2026-07-24 18:18 ` [PATCH 02/19] wifi: rtw88: rx: mark zero length packets on RTL8723B luka.gejak
2026-07-24 22:34 ` Bitterblue Smith
2026-07-24 18:18 ` [PATCH 03/19] wifi: rtw88: tx: extend the TX report purge timeout to RTL8723BS luka.gejak
2026-07-24 18:18 ` [PATCH 04/19] wifi: rtw88: fw: handle the RTL8723BS management TX reports luka.gejak
2026-07-24 22:53 ` Bitterblue Smith
2026-07-24 18:18 ` [PATCH 05/19] wifi: rtw88: fw: send rate adaptation and RSSI info in the vendor layout luka.gejak
2026-07-24 23:46 ` Bitterblue Smith
2026-07-24 18:18 ` [PATCH 06/19] wifi: rtw88: fw: send the media status report " luka.gejak
2026-07-24 23:52 ` Bitterblue Smith
2026-07-24 18:18 ` [PATCH 07/19] wifi: rtw88: fw: add the vendor firmware commands used by RTL8723BS luka.gejak
2026-07-24 18:18 ` [PATCH 08/19] wifi: rtw88: fw: fix the reserved page upload on RTL8723BS luka.gejak
2026-07-24 18:18 ` [PATCH 09/19] wifi: rtw88: coex: add the RTL8723BS scan antenna workaround luka.gejak
2026-07-24 18:32 ` [PATCH 10/19] wifi: rtw88: coex: reassert the antenna path when associating luka.gejak
2026-07-24 18:32 ` [PATCH 11/19] wifi: rtw88: sdio: track free TX pages and OQT credits for RTL8723BS luka.gejak
2026-07-24 18:32 ` [PATCH 12/19] wifi: rtw88: sdio: handle the RTL8723BS management TX path luka.gejak
2026-07-24 18:32 ` [PATCH 13/19] wifi: rtw88: sdio: set up RX aggregation and interrupts for RTL8723BS luka.gejak
2026-07-24 18:32 ` [PATCH 14/19] wifi: rtw88: sdio: add TX back-pressure and retry on page starvation luka.gejak
2026-07-24 18:32 ` [PATCH 15/19] wifi: rtw88: record beacons from the target BSSID before authenticating luka.gejak
2026-07-24 18:32 ` [PATCH 16/19] wifi: rtw88: run the RTL8723BS association register sequence luka.gejak
2026-07-24 18:33 ` [PATCH 17/19] wifi: rtw88: calibrate and tune the PHY for RTL8723BS luka.gejak
2026-07-24 21:05 ` Bitterblue Smith [this message]
2026-07-24 18:33 ` [PATCH 18/19] wifi: rtw88: match the RTL8723BS firmware connect and power save behaviour luka.gejak
2026-07-24 22:10 ` Bitterblue Smith
2026-07-24 18:33 ` [PATCH 19/19] wifi: rtw88: advertise the correct receive capabilities on RTL8723BS luka.gejak
2026-07-24 22:29 ` Bitterblue Smith
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=efef00cb-8369-48d5-859f-623663ddac56@gmail.com \
--to=rtl8821cerfe2@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-wireless@vger.kernel.org \
--cc=luka.gejak@linux.dev \
--cc=pbrobinson@gmail.com \
--cc=pkshih@realtek.com \
--cc=straube.linux@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox