| Message ID | 20250103075107.1337533-1-anarsoul@gmail.com |
|---|---|
| State | New |
| Headers | show |
| Series | wifi: rtw88: 8703b: Fix RX/TX issues | expand |
On 25-01-02 23:50, Vasily Khoruzhick wrote: > Fix 3 typos in 8703b driver. 2 typos in calibration routines are not > fatal and do not seem to have any impact, just fix them to match vendor > driver. > > However the last one in rtw8703b_set_channel_bb() clears too many bits > in REG_OFDM0_TX_PSD_NOISE, causing TX and RX issues (neither rate goes > above MCS0-MCS1). Vendor driver clears only 2 most significant bits. > > With the last typo fixed, the driver is able to reach MCS7 on Pinebook > > Cc: stable@vger.kernel.org > Fixes: 9bb762b3a957 ("wifi: rtw88: Add definitions for 8703b chip") > Signed-off-by: Vasily Khoruzhick <anarsoul@gmail.com> Tested-by: Andrey Skvortsov <andrej.skvortzov@gmail.com> Thank you, Vasily, for fixing that. Performance is much better with the fix. Here are iperf results made on PinePhone: 1. without the patch using rtw88 driver 1.98 Mbits/sec 2. with the patch using rtw88 driver 14.0 Mbits/sec 3. using old vendor 8723cs driver 23.6 Mbits/sec
On Fri, Jan 3, 2025 at 3:55 AM Fiona Klute <fiona.klute@gmx.de> wrote: > > Is this urgent? If not, I will take this via rtw-next tree. > It's a huge performance improvement, 10x more RX throughput in Iperf > tests, not just in the reported bit rate (residential, moderately noisy > environment). TX improved too, but not as massively. > > Tested-by: Fiona Klute <fiona.klute@gmx.de> Thanks for testing! Can you please share your iperf numbers? > Thank you very much Vasily for digging into this! Thanks for implementing 8723cs support in the first place! :) > Best regards, > Fiona >
On Fri, Jan 3, 2025 at 12:19 PM Andrey Skvortsov
<andrej.skvortzov@gmail.com> wrote:
> Here are more detailed testing results:
I was able to reproduce it with an AP located 2 floors away.
Basically, in perfect conditions rtw88 is able to match vendor driver
performance, however when signal strength is low, rtw88 is ~2x slower
On 25-01-03 12:53, Vasily Khoruzhick wrote: > On Fri, Jan 3, 2025 at 12:19 PM Andrey Skvortsov > <andrej.skvortzov@gmail.com> wrote: > > > Here are more detailed testing results: > > I was able to reproduce it with an AP located 2 floors away. > Basically, in perfect conditions rtw88 is able to match vendor driver > performance, however when signal strength is low, rtw88 is ~2x slower In my case AP was one meter away from the device. Maybe PinePhone's antenna isn't well designed as for PineBook.
Vasily Khoruzhick <anarsoul@gmail.com> wrote: > > On Fri, Jan 3, 2025 at 1:13 AM Ping-Ke Shih <pkshih@realtek.com> wrote: > > > > Vasily Khoruzhick <anarsoul@gmail.com> wrote: > > > Fix 3 typos in 8703b driver. 2 typos in calibration routines are not > > > fatal and do not seem to have any impact, just fix them to match vendor > > > driver. > > > > Just curious how you can find these typos? > > I added traces to sdio_* functions in linux (see [1]), so I can > capture register access traces. I captured the traces from both rtw88 > and the vendor driver and wrote a simple parser that decodes the > traces, see [2]. I guess it would be easier with an USB device, where > we have usbmon. I really wish there was something like usbmon for > SDIO. > > I also added traces for C2H messages to both drivers, since they go > through sdio_memcpy_fromio() that I don't trace. > > Once I had the traces, I manually compared them (along with register > dumps, rtw88 has it in debugfs, vendor driver in proc) trying to find > the writes that do not match. Unfortunately, rtw88 and vendor driver > flows are different enough, so I couldn't come up with a way to > compare it automatically > > Adrian and Bitterblue supported me on #linux-wireless on IRC, and one > of the typos in IQK calibration was actually found by Bitterblue. > > It took ~5 evenings and 1 weekend to get to REG_OFDM0_TX_PSD_NOISE > (0xce4). Once I changed it from 0 to 0x10000000 via reg_write over > debugfs, it magically fixed the issue. I changed it back to 0 to > confirm that it breaks it again, and then back to 0x10000000 to see it > working. Then it was just a matter of grep to find where this register > is written in rtw88 and compare the corresponding code to the vendor > driver. > > [1] https://github.com/anarsoul/rtl8723cs-re/blob/master/sdio_traces.patch > [2] https://github.com/anarsoul/rtl8723cs-re > Cool. I did similar works when we rewrite rtw89 from vendor drivers. Sometimes we also found flaws of vendor driver by their difference. Ping-Ke
diff --git a/drivers/net/wireless/realtek/rtw88/rtw8703b.c b/drivers/net/wireless/realtek/rtw88/rtw8703b.c index a19b94d022ee..1d232adbdd7e 100644 --- a/drivers/net/wireless/realtek/rtw88/rtw8703b.c +++ b/drivers/net/wireless/realtek/rtw88/rtw8703b.c @@ -903,7 +903,7 @@ static void rtw8703b_set_channel_bb(struct rtw_dev *rtwdev, u8 channel, u8 bw, rtw_write32_mask(rtwdev, REG_FPGA0_RFMOD, BIT_MASK_RFMOD, 0x0); rtw_write32_mask(rtwdev, REG_FPGA1_RFMOD, BIT_MASK_RFMOD, 0x0); rtw_write32_mask(rtwdev, REG_OFDM0_TX_PSD_NOISE, - GENMASK(31, 20), 0x0); + GENMASK(31, 30), 0x0); rtw_write32(rtwdev, REG_BBRX_DFIR, 0x4A880000); rtw_write32(rtwdev, REG_OFDM0_A_TX_AFE, 0x19F60000); break; @@ -1198,9 +1198,9 @@ static u8 rtw8703b_iqk_rx_path(struct rtw_dev *rtwdev, rtw_write32(rtwdev, REG_RXIQK_TONE_A_11N, 0x38008c1c); rtw_write32(rtwdev, REG_TX_IQK_TONE_B, 0x38008c1c); rtw_write32(rtwdev, REG_RX_IQK_TONE_B, 0x38008c1c); - rtw_write32(rtwdev, REG_TXIQK_PI_A_11N, 0x8216000f); + rtw_write32(rtwdev, REG_TXIQK_PI_A_11N, 0x8214030f); rtw_write32(rtwdev, REG_RXIQK_PI_A_11N, 0x28110000); - rtw_write32(rtwdev, REG_TXIQK_PI_B, 0x28110000); + rtw_write32(rtwdev, REG_TXIQK_PI_B, 0x82110000); rtw_write32(rtwdev, REG_RXIQK_PI_B, 0x28110000); /* LOK setting */ @@ -1372,7 +1372,7 @@ void rtw8703b_iqk_fill_a_matrix(struct rtw_dev *rtwdev, const s32 result[]) return; tmp_rx_iqi |= FIELD_PREP(BIT_MASK_RXIQ_S1_X, result[IQK_S1_RX_X]); - tmp_rx_iqi |= FIELD_PREP(BIT_MASK_RXIQ_S1_Y1, result[IQK_S1_RX_X]); + tmp_rx_iqi |= FIELD_PREP(BIT_MASK_RXIQ_S1_Y1, result[IQK_S1_RX_Y]); rtw_write32(rtwdev, REG_A_RXIQI, tmp_rx_iqi); rtw_write32_mask(rtwdev, REG_RXIQK_MATRIX_LSB_11N, BIT_MASK_RXIQ_S1_Y2, BIT_SET_RXIQ_S1_Y2(result[IQK_S1_RX_Y]));
Fix 3 typos in 8703b driver. 2 typos in calibration routines are not fatal and do not seem to have any impact, just fix them to match vendor driver. However the last one in rtw8703b_set_channel_bb() clears too many bits in REG_OFDM0_TX_PSD_NOISE, causing TX and RX issues (neither rate goes above MCS0-MCS1). Vendor driver clears only 2 most significant bits. With the last typo fixed, the driver is able to reach MCS7 on Pinebook Cc: stable@vger.kernel.org Fixes: 9bb762b3a957 ("wifi: rtw88: Add definitions for 8703b chip") Signed-off-by: Vasily Khoruzhick <anarsoul@gmail.com> --- drivers/net/wireless/realtek/rtw88/rtw8703b.c | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-)