public inbox for linux-wireless@vger.kernel.org
 help / color / mirror / Atom feed
From: Bitterblue Smith <rtl8821cerfe2@gmail.com>
To: Ping-Ke Shih <pkshih@realtek.com>,
	"linux-wireless@vger.kernel.org" <linux-wireless@vger.kernel.org>
Subject: Re: [PATCH rtw-next 00/12] wifi: rtw89: Add support for RTL8922AU
Date: Tue, 7 Apr 2026 23:41:52 +0300	[thread overview]
Message-ID: <e8d10b96-f305-46f4-a473-2592f237f871@gmail.com> (raw)
In-Reply-To: <0cbfd38ffd0b46e899885c83889d060b@realtek.com>

On 02/04/2026 03:48, Ping-Ke Shih wrote:
> Bitterblue Smith <rtl8821cerfe2@gmail.com> wrote:
>> On 30/03/2026 05:53, Ping-Ke Shih wrote:
>>> Bitterblue Smith <rtl8821cerfe2@gmail.com> wrote:
>>>> Often one or more of these messages appears when the chip powers on:
>>>>
>>>> [  +2.167037] rtw89_8922au 1-2:1.0: failed to wait RF DACK
>>>>
>>>> [  +2.942749] rtw89_8922au 1-2:1.0: failed to wait RF TSSI
>>>>
>>>> [  +0.019006] rtw89_8922au 2-4:1.0: failed to wait RF PRE_NTFY
>>>>
>>>> [  +5.985900] rtw89_8922au 2-4:1.0: failed to wait RF DPK
>>>>
>>>> It's unclear why.
>>>
>>> RTL8922D done RF calibrations by firmware one by one, so driver should
>>> wait for previous one done, and trigger next one. However, it'd be
>>> well to just do waiting at the last to wait for all calibrations.
>>>
>>> Try to enlarge waiting time in rtw8922a_rfk_channel().
>>>
>>
>> I was convinced I tried that already, but no.
>>
>> After increasing all delays a bit the warnings are much more rare.
> 
> Turn of debug mask RTW89_DBG_RFK and set a very large timeout time, and
> do connection >20 times and then check "RF %s takes %lld ms to complete"
> to see the maximum value in your environment.
> 
> Please share the number for each RF calibration after your experiments.
> 

I changed every delay to 500, then ran this, once with the adapter in
USB 2, once in USB 3:

for i in {01..20}; do nmcli connection up "<2.4 GHz SSID>"; sleep 10; nmcli connection up "<5 GHz SSID>"; sleep 10; done

There were no "failed to wait RF" warnings.

These are the results after processing with "sort --unique":

RF DACK takes 15 ms to complete
RF DACK takes 16 ms to complete
RF DACK takes 44 ms to complete
RF DACK takes 72 ms to complete

RF DPK takes 23 ms to complete
RF DPK takes 24 ms to complete
RF DPK takes 27 ms to complete
RF DPK takes 30 ms to complete

RF IQK takes 48 ms to complete
RF IQK takes 49 ms to complete
RF IQK takes 50 ms to complete

RF PRE_NTFY takes 0 ms to complete
RF PRE_NTFY takes 1 ms to complete

RF RX_DCK takes 8 ms to complete
RF RX_DCK takes 9 ms to complete
RF RX_DCK takes 11 ms to complete
RF RX_DCK takes 23 ms to complete
RF RX_DCK takes 24 ms to complete
RF RX_DCK takes 27 ms to complete
RF RX_DCK takes 38 ms to complete
RF RX_DCK takes 39 ms to complete
RF RX_DCK takes 53 ms to complete
RF RX_DCK takes 54 ms to complete
RF RX_DCK takes 58 ms to complete
RF RX_DCK takes 70 ms to complete
RF RX_DCK takes 110 ms to complete

RF TSSI takes 1 ms to complete
RF TSSI takes 2 ms to complete
RF TSSI takes 23 ms to complete
RF TSSI takes 24 ms to complete

RF TXGAPK takes 9 ms to complete
RF TXGAPK takes 10 ms to complete
RF TXGAPK takes 17 ms to complete
RF TXGAPK takes 18 ms to complete

I also left it unconnected and constantly scanning for a few minutes.
RTW89_TSSI_SCAN always takes 1-2 ms.

>>
>>>>
>>>> It seems to work well anyway.
>>>>
>>>
>>> If you can yield the highest rate (MCS13), I'd say it is fine.
>>>
>>> Ping-Ke
>>>
>>
>> Testing with RTL8832CU (Brostrend AX8) in AP mode, the RTL8912AU can
>> reach 1.5 Gbps (MCS10) RX, 1 Gbps TX.
>>
>> I used the RTL8832CU because my router is not working well with 160
>> MHz.
> 
> Since rtw89 only support beamformee (no beamformer), beamforming can't
> work between two rtw89 devices. More, two antenna can't have good
> beamforming performance. I think this is a point that it is hard to
> yield the highest rate. 
> 
> Another point may be the RF performance. If the warning messages of
> RF calibration disappeared, I'd say this might not a problem.
> 
> Let's mention this in commit message of 12/12.
> 
> Ping-Ke
> 


  reply	other threads:[~2026-04-07 20:41 UTC|newest]

Thread overview: 42+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-03-26 17:02 [PATCH rtw-next 00/12] wifi: rtw89: Add support for RTL8922AU Bitterblue Smith
2026-03-26 17:03 ` [PATCH rtw-next 01/12] wifi: rtw89: usb: Disable MLO for now Bitterblue Smith
2026-03-30  2:59   ` Ping-Ke Shih
2026-04-04 14:07     ` Bitterblue Smith
2026-03-26 17:04 ` [PATCH rtw-next 02/12] wifi: rtw89: usb: Support 2 bulk in endpoints Bitterblue Smith
2026-03-30  3:16   ` Ping-Ke Shih
2026-03-26 17:04 ` [PATCH rtw-next 03/12] wifi: rtw89: Fix rtw89_usb_ops_mac_lv1_rcvy() for RTL8922AU Bitterblue Smith
2026-03-30  3:36   ` Ping-Ke Shih
2026-03-26 17:05 ` [PATCH rtw-next 04/12] wifi: rtw89: Fix rtw89_usb_ops_mac_pre_init() " Bitterblue Smith
2026-03-30  3:39   ` Ping-Ke Shih
2026-03-26 17:05 ` [PATCH rtw-next 05/12] wifi: rtw89: Fix rtw89_usb_ops_mac_post_init() " Bitterblue Smith
2026-03-30  3:41   ` Ping-Ke Shih
2026-03-26 17:06 ` [PATCH rtw-next 06/12] wifi: rtw89: usb: Enable RX aggregation " Bitterblue Smith
2026-03-30  3:46   ` Ping-Ke Shih
2026-04-01 22:58     ` Bitterblue Smith
2026-03-26 17:06 ` [PATCH rtw-next 07/12] wifi: rtw89: Fix rtw8922a_pwr_{on,off}_func() for USB Bitterblue Smith
2026-03-30  3:54   ` Ping-Ke Shih
2026-03-26 17:07 ` [PATCH rtw-next 08/12] wifi: rtw89: Let hfc_param_ini have separate settings for USB 2/3 Bitterblue Smith
2026-03-30  3:59   ` Ping-Ke Shih
2026-03-26 17:08 ` [PATCH rtw-next 09/12] wifi: rtw89: Add rtw8922a_hfc_param_ini_usb{2,3} Bitterblue Smith
2026-03-30  4:01   ` Ping-Ke Shih
2026-03-26 17:08 ` [PATCH rtw-next 10/12] wifi: rtw89: Add rtw8922a_dle_mem_usb{2,3} Bitterblue Smith
2026-03-30  4:25   ` Ping-Ke Shih
2026-03-26 17:09 ` [PATCH rtw-next 11/12] wifi: rtw89: Add rtw8922au.c Bitterblue Smith
2026-03-30  4:27   ` Ping-Ke Shih
2026-03-26 17:09 ` [PATCH rtw-next 12/12] wifi: rtw89: Enable the new rtw89_8922au module Bitterblue Smith
2026-03-30  4:30   ` Ping-Ke Shih
2026-03-30  2:53 ` [PATCH rtw-next 00/12] wifi: rtw89: Add support for RTL8922AU Ping-Ke Shih
2026-04-01 17:43   ` Bitterblue Smith
2026-04-02  0:48     ` Ping-Ke Shih
2026-04-07 20:41       ` Bitterblue Smith [this message]
2026-04-08  0:46         ` Ping-Ke Shih
2026-04-10  8:00           ` [PATCH 0/2] wifi: rtw89: fix RF calibration for USB transport Louis Kotze
2026-04-10  8:00             ` [PATCH 1/2] wifi: rtw89: phy: increase RF calibration timeouts " Louis Kotze
2026-04-14  6:32               ` Ping-Ke Shih
2026-04-15 11:13                 ` Louis Kotze
2026-04-10  8:00             ` [PATCH 2/2] wifi: rtw89: phy: make RF calibration timeouts non-fatal on USB Louis Kotze
2026-04-14  6:39               ` Ping-Ke Shih
2026-04-15 11:13                 ` Louis Kotze
2026-04-15 11:13             ` [PATCH v2] wifi: rtw89: phy: increase RF calibration timeouts for USB transport Louis Kotze
2026-04-16  1:15               ` Ping-Ke Shih
2026-04-16  4:56                 ` Louis Kotze

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=e8d10b96-f305-46f4-a473-2592f237f871@gmail.com \
    --to=rtl8821cerfe2@gmail.com \
    --cc=linux-wireless@vger.kernel.org \
    --cc=pkshih@realtek.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