From: Bitterblue Smith <rtl8821cerfe2@gmail.com>
To: Luka Gejak <luka.gejak@linux.dev>, Ho Jie Feng <hjf3108@gmail.com>
Cc: Ping-Ke Shih <pkshih@realtek.com>, linux-wireless@vger.kernel.org
Subject: Re: [PATCH 5/6] wifi: rtw88: 88xxa: adapt channel sensing to receiver gain
Date: Fri, 30 Oct 2026 20:50:45 +0200 [thread overview]
Message-ID: <7f03b862-3cbd-4bc6-a1d8-9c2d5cd24afa@gmail.com> (raw)
In-Reply-To: <b54683e9ddd81ae2a4f08ed4a8dedcfdb0209a28@linux.dev>
On 30/10/2026 20:16, Luka Gejak wrote:
> Hi Bitterblue, Jie Feng,
>
> Thanks for testing this Bitterblue. I had a look at why the scan gets so
> slow and I think I found the cause.
>
> October 30, 2026 at 3:57 PM, "Bitterblue Smith" <rtl8821cerfe2@gmail.com> wrote:
>
>>
>> On 29/10/2026 07:52, Ho Jie Feng wrote:
>>
>> During the scans I see a lot of "timed out to flush queue 1" (and 3)
>> in dmesg. You need debug_mask=0x80000000 to see these.
>
> [ ... ]
>
>>> +void rtw88xxa_adaptivity(struct rtw_dev *rtwdev)
>>> +{
>>> + struct rtw_dm_info *dm_info = &rtwdev->dm_info;
>>> + int igi_diff = EDCCA_IGI_BASE - dm_info->igi_history[0];
>
> As far as I can see, igi_history[0] is not always the IGI in the hardware.
> Since 3f90942473d2 ("wifi: rtw88: Increase the RX gain before scanning")
> a sw scan writes IGI 0x1c without updating igi_history:
>
> rtw_core_scan_start()
> rtw_phy_dig_set_max_coverage()
> rtw_phy_dig_write(rtwdev, DIG_CVRG_MIN)
>
That appears to be the cause. If I disable rtw_phy_dig_set_max_coverage()
the problem goes away.
> rtw_watch_dog_work() skips rtw_phy_dynamic_mechanism() while scanning, so
> if I read it right 0x8a4 keeps the value computed for the associated IGI
> for the whole scan.
>
> In the 8812au vendor driver these chips are in ODM_IC_PWDB_EDCCA, and
> phydm_adaptivity() computes the threshold from the current IGI
> (cur_ig_value) with the same formula as here. So with the gain raised and
> 0x8a4 unchanged, EDCCA seems to get more sensitive by the difference
> between the associated IGI and 0x1c. Since rtw88xxa_adaptivity_init()
> clears BIT_DIS_EDCCA, the MAC would then hold the frames.
>
> I think this matches the flush timeouts quoted above. Queue 1 and 3 are
> the LOW and HIGH priority queues, and mac80211 flushes the queues every
> time it leaves the home channel. Most of the delayed pings also came back
> together at about the time the scan finished, which is when
> rtw_core_scan_complete() writes the old IGI back.
>
> The 8812A beacon loss branch in rtw_phy_dig() switches to DIG_CVRG_MIN
> after rtw_phy_dig_recorder() has stored the other value, so the same
> mismatch seems possible outside of scans too.
>
> Jie Feng, maybe something like what rtw89 does in 280c444745aa
> ("wifi: rtw89: config EDCCA threshold during scan to prevent TX failed")
> would work here, setting 0x8a4 to 0x7f/0x7f at scan start and restoring
> it at scan complete. Or rtw88xxa_adaptivity() could use the IGI that is
> actually in the hardware and run again when the core writes the IGI,
> which would also cover the beacon loss case. I think this belongs in
> this patch for v2.
>
> And one more thing Bitterblue, is there a reason for your email only
> being addressed to the mailing list. I am pretty certain that the
> author hasn't subscribed to the mailing list so your test results
> might now reach them.
>
That is Thunderbird being helpful. On some emails it replaces the
"Reply All" button with the very similar looking "Reply List". I didn't
notice until now.
> Best regards,
> Luka Gejak
next prev parent reply other threads:[~2026-10-30 18:50 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-29 5:52 [PATCH 0/6] wifi: rtw88: extend 88xxA support Ho Jie Feng
2026-10-29 5:52 ` [PATCH 1/6] wifi: rtw88: 8812a, 8814a: enable STBC for HT transmissions Ho Jie Feng
2026-10-29 5:52 ` [PATCH 2/6] wifi: rtw88: 88xxa: receive VHT SU beamformed transmissions Ho Jie Feng
2026-10-29 12:33 ` Bitterblue Smith
2026-10-29 14:13 ` Ho Jie Feng
2026-10-29 21:06 ` Bitterblue Smith
2026-10-29 5:52 ` [PATCH 3/6] wifi: rtw88: prepare frequency-offset correction for more chips Ho Jie Feng
2026-10-29 5:52 ` [PATCH 4/6] wifi: rtw88: 88xxa: correct carrier-frequency offset Ho Jie Feng
2026-10-29 5:52 ` [PATCH 5/6] wifi: rtw88: 88xxa: adapt channel sensing to receiver gain Ho Jie Feng
2026-10-30 14:57 ` Bitterblue Smith
2026-10-30 18:16 ` Luka Gejak
2026-10-30 18:50 ` Bitterblue Smith [this message]
2026-10-29 5:52 ` [PATCH 6/6] wifi: rtw88: 8812a, 8821a: respect peer A-MPDU size limits Ho Jie Feng
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=7f03b862-3cbd-4bc6-a1d8-9c2d5cd24afa@gmail.com \
--to=rtl8821cerfe2@gmail.com \
--cc=hjf3108@gmail.com \
--cc=linux-wireless@vger.kernel.org \
--cc=luka.gejak@linux.dev \
--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