All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mehmet Fide <mehmet.fide@gmail.com>
To: Ping-Ke Shih <pkshih@realtek.com>
Cc: Bitterblue Smith <rtl8821cerfe2@gmail.com>,
	linux-wireless@vger.kernel.org, linux-kernel@vger.kernel.org,
	Mehmet Fide <mehmet.fide@screeningeagle.com>
Subject: Re: [PATCH rtw-next v3] wifi: rtw88: usb: route bmc frames via the high queue only for DTIM delivery
Date: Fri, 14 Aug 2026 08:37:14 +0200	[thread overview]
Message-ID: <20260814063714.2480456-1-mehmet.fide@gmail.com> (raw)
In-Reply-To: <20260814053426.2473247-1-mehmet.fide@gmail.com>

From: Mehmet Fide <mehmet.fide@screeningeagle.com>

Hello Ping-Ke,

One more data point that may be useful for the firmware side,
separate from this patch.

While comparing against the vendor driver I noticed a difference in
how MORE_DATA is terminated. rtw88 sets the bit on every high queue
frame (rtw_tx_fill_tx_desc(): more_data = qsel == TX_DESC_QSEL_HIGH),
including the last one. The vendor driver releases the high queue as
an explicit batch and sets mdata = 1 on all frames of the batch
except the final one, which carries 0 (chk_bmc_sleepq_hdl() in
core/rtw_mlme_ext.c of the 88x2bu source).

On both RTL8822BU and RTL8821CU I measured the high queue draining at
roughly 3 frames per DTIM with BIT_TCR_UPDATE_HGQMD set, instead of
the whole buffered burst, so the burst fetch of 076f786a0ae1 does not
seem to engage on these chips. A never-terminated MORE_DATA chain is
my best guess for why, but that is a guess; whether the hardware
needs the 0 to conclude a burst is something only the firmware
documentation can answer.

Thanks,
Mehmet

  reply	other threads:[~2026-08-14  6:37 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-08-14  5:34 [PATCH rtw-next v3] wifi: rtw88: usb: route bmc frames via the high queue only for DTIM delivery Mehmet Fide
2026-08-14  6:37 ` Mehmet Fide [this message]
2026-08-17  2:57   ` Ping-Ke Shih
2026-08-17  3:00 ` Ping-Ke Shih

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=20260814063714.2480456-1-mehmet.fide@gmail.com \
    --to=mehmet.fide@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-wireless@vger.kernel.org \
    --cc=mehmet.fide@screeningeagle.com \
    --cc=pkshih@realtek.com \
    --cc=rtl8821cerfe2@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.