Linux wireless drivers development
 help / color / mirror / Atom feed
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


  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