RE: [PATCH rtw-next v3] wifi: rtw88: usb: route bmc frames via the high queue only for DTIM delivery

[Ping-Ke Shih <pkshih@realtek.com>]

Mehmet Fide <mehmet.fide@gmail.com> wrote:
> 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.

By consulting internal people and experiments, the last MORE_DATA is
unset by hardware. So I think we don't need to align behavior of
vendor driver, unless peeking the next frames before sending. 

Ping-Ke