| Message ID | 20221227233020.284266-1-martin.blumenstingl@googlemail.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | rtw88: Add SDIO support | expand |
> -----Original Message----- > From: Martin Blumenstingl <martin.blumenstingl@googlemail.com> > Sent: Wednesday, December 28, 2022 7:30 AM > To: linux-wireless@vger.kernel.org > Cc: Yan-Hsuan Chuang <tony0620emma@gmail.com>; Kalle Valo <kvalo@kernel.org>; Ulf Hansson > <ulf.hansson@linaro.org>; linux-kernel@vger.kernel.org; netdev@vger.kernel.org; > linux-mmc@vger.kernel.org; Chris Morgan <macroalpha82@gmail.com>; Nitin Gupta <nitin.gupta981@gmail.com>; > Neo Jou <neojou@gmail.com>; Ping-Ke Shih <pkshih@realtek.com>; Jernej Skrabec <jernej.skrabec@gmail.com>; > Martin Blumenstingl <martin.blumenstingl@googlemail.com> > Subject: [RFC PATCH v1 00/19] rtw88: Add SDIO support > > Recently the rtw88 driver has gained locking support for the "slow" bus > types (USB, SDIO) as part of USB support. Thanks to everyone who helped > make this happen! > > Based on the USB work (especially the locking part and various > bugfixes) this series adds support for SDIO based cards. It's the > result of a collaboration between Jernej and myself. Neither of us has > access to the rtw88 datasheets. All of our work is based on studying > the RTL8822BS and RTL8822CS vendor drivers and trial and error. > > Jernej and myself have tested this with RTL8822BS and RTL8822CS cards. > Other users have confirmed that RTL8821CS support is working as well. > RTL8723DS may also work (we tried our best to handle rtw_chip_wcpu_11n > where needed) but has not been tested at this point. > > Jernej's results with a RTL8822BS: > - Main functionality works > - Had a case where no traffic got across the link until he issued a > scan > > My results with a RTL8822CS: > - 2.4GHz and 5GHz bands are both working > - TX throughput on a 5GHz network is between 50 Mbit/s and 90 Mbit/s > - RX throughput on a 5GHz network is at 19 Mbit/s I have a suggestion about RX throughput, please check below registers with vendor driver: REG_RXDMA_AGG_PG_TH REG_TXDMA_PQ_MAP(0x10c) BIT_RXDMA_AGG_EN (bit2) REG_RXDMA_MODE(0290) BIT_DMA_MODE (bit1) Try to adjust AGG_PG_TH to see if it can help. -- Ping-Ke
Hi Ping-Ke, thanks again for all your input! On Thu, Dec 29, 2022 at 5:19 AM Ping-Ke Shih <pkshih@realtek.com> wrote: [...] > > - RX throughput on a 5GHz network is at 19 Mbit/s > > I have a suggestion about RX throughput, please check below registers with > vendor driver: > > REG_RXDMA_AGG_PG_TH > REG_TXDMA_PQ_MAP(0x10c) BIT_RXDMA_AGG_EN (bit2) > REG_RXDMA_MODE(0290) BIT_DMA_MODE (bit1) Unfortunately I didn't manage to get the vendor driver to work with mainline Linux. The Android installation on my board (which is how it was shipped) uses the vendor driver but unlike some Amlogic code the Realtek (vendor) wireless driver does not allow reading arbitrary registers through sysfs. So I can't check the values that the vendor driver uses. > Try to adjust AGG_PG_TH to see if it can help. I tried a few values and I can say that it does change the RX throughput, but the result is always lower than 19 Mbit/s, meaning that it's worse than RX aggregation disabled (on my RTL8822CS). Currently we're disabling RX aggregation in the driver. But Jernej mentioned previously that for his RTL8822BS he found that RX aggregation seems to improve performance. Independent of this I did some investigation on my own and found that when reducing the TX throughput the RX throughput increases. For this I tried using ieee80211_{stop,wake}_queue() in the sdio.c HCI sub-driver. RX throughput is now at 23.5 Mbit/s (that +25% compared to before) on my RTL8822CS (with RX aggregation still disabled, just like in the 19 Mbit/s test). Unfortunately TX throughput is now way below 10 Mbit/s. Additionally I think that the antenna of my board is worse than my access point's antenna. So TX from rtw88 to my AP may be faster (because the AP can "hear better") than RX (rtw88 "hearing is worse"). For today I'm tired and will stop here. Best regards, Martin [0] https://github.com/xdarklight/linux/commit/3f2e6b9cd40dc785b5c72dbc9c8b471a2e205344
On Fri, 2022-12-30 at 00:18 +0100, Martin Blumenstingl wrote: > Hi Ping-Ke, > > thanks again for all your input! > > On Thu, Dec 29, 2022 at 5:19 AM Ping-Ke Shih <pkshih@realtek.com> wrote: > [...] > > > - RX throughput on a 5GHz network is at 19 Mbit/s > > > > I have a suggestion about RX throughput, please check below registers with > > vendor driver: > > > > REG_RXDMA_AGG_PG_TH > > REG_TXDMA_PQ_MAP(0x10c) BIT_RXDMA_AGG_EN (bit2) > > REG_RXDMA_MODE(0290) BIT_DMA_MODE (bit1) > Unfortunately I didn't manage to get the vendor driver to work with > mainline Linux. > The Android installation on my board (which is how it was shipped) > uses the vendor driver but unlike some Amlogic code the Realtek > (vendor) wireless driver does not allow reading arbitrary registers > through sysfs. > So I can't check the values that the vendor driver uses. > > > Try to adjust AGG_PG_TH to see if it can help. > I tried a few values and I can say that it does change the RX > throughput, but the result is always lower than 19 Mbit/s, meaning > that it's worse than RX aggregation disabled (on my RTL8822CS). > Currently we're disabling RX aggregation in the driver. But Jernej > mentioned previously that for his RTL8822BS he found that RX > aggregation seems to improve performance. > > Independent of this I did some investigation on my own and found that > when reducing the TX throughput the RX throughput increases. > For this I tried using ieee80211_{stop,wake}_queue() in the sdio.c HCI > sub-driver. > RX throughput is now at 23.5 Mbit/s (that +25% compared to before) on > my RTL8822CS (with RX aggregation still disabled, just like in the 19 > Mbit/s test). > Unfortunately TX throughput is now way below 10 Mbit/s. > > Additionally I think that the antenna of my board is worse than my > access point's antenna. So TX from rtw88 to my AP may be faster > (because the AP can "hear better") than RX (rtw88 "hearing is worse"). > Without equipment like CAT-C, it is hard to investigate SDIO usb aggregation, so I suggest to capture WiFi packets in the air to make sure things work as expected. After that, we can focus on bus aggregation tuning. The instructions to use another WiFi card to capture packets are: 1. sudo iw dev wlan0 interface add mon0 type monitor 2. sudo wireshark // select mon0 to capture Please check AMPDU and AMSDU size during doing TX/RX throughput test. Normally, expected AMSDU size is 3000+ bytes, and AMPDU number is around 32 MSDUs. If RX is too slow resulting in buffer overflow, AP could resend (check sequence number and 'R' bit, or BA of 8822CS). Also, check TX/RX rates to know if RF calibration and PHY dynamic mechanism work well. Normally, with 50cm distance long from AP, it must yield the highest rate, no doubt. I hope this can narrow down the problems you met. --- Ping-Ke
(Jakub, a question for you below) Martin Blumenstingl <martin.blumenstingl@googlemail.com> writes: > Recently the rtw88 driver has gained locking support for the "slow" bus > types (USB, SDIO) as part of USB support. Thanks to everyone who helped > make this happen! > > Based on the USB work (especially the locking part and various > bugfixes) this series adds support for SDIO based cards. It's the > result of a collaboration between Jernej and myself. Neither of us has > access to the rtw88 datasheets. All of our work is based on studying > the RTL8822BS and RTL8822CS vendor drivers and trial and error. > > Jernej and myself have tested this with RTL8822BS and RTL8822CS cards. > Other users have confirmed that RTL8821CS support is working as well. > RTL8723DS may also work (we tried our best to handle rtw_chip_wcpu_11n > where needed) but has not been tested at this point. Very nice, good work. Our recommendation is to have maximum of 10-12 patches per patchset to make it easier for us maintainers, any chance to split the patchset into two? For example, get the easy preparation patches into wireless-next first and later submit the actual SDIO support. [...] > Why is this an RFC? [...] > - My understanding is that there's a discussion about the rtw88 Kconfig > symbols. We're adding four new ones within this series. It's not > clear to me what the conclusion is on this topic though. Yeah, there were no conclusions about that. Jakub, do you have any opinions? For example, do we keep per device Kconfig options (eg. CONFIG_RTW88_8822BS, RTW88_8822CS and so on) or should we have only one more bus level option (eg. CONFIG_RTW88_SDIO)? rtw88 now uses the former and IIRC so does mt76. ath10k/ath11k/ath12k again use the latter :)
On Mon, 16 Jan 2023 18:01:05 +0200 Kalle Valo wrote: > > - My understanding is that there's a discussion about the rtw88 Kconfig > > symbols. We're adding four new ones within this series. It's not > > clear to me what the conclusion is on this topic though. > > Yeah, there were no conclusions about that. Jakub, do you have any > opinions? For example, do we keep per device Kconfig options (eg. > CONFIG_RTW88_8822BS, RTW88_8822CS and so on) or should we have only one > more bus level option (eg. CONFIG_RTW88_SDIO)? rtw88 now uses the former > and IIRC so does mt76. ath10k/ath11k/ath12k again use the latter :) No strong feelings. Larry (IIRC) provided a fair justification for the RTW symbols. If the module binary grows noticeably then having the kconfig does indeed make sense.
Jakub Kicinski <kuba@kernel.org> writes: > On Mon, 16 Jan 2023 18:01:05 +0200 Kalle Valo wrote: >> > - My understanding is that there's a discussion about the rtw88 Kconfig >> > symbols. We're adding four new ones within this series. It's not >> > clear to me what the conclusion is on this topic though. >> >> Yeah, there were no conclusions about that. Jakub, do you have any >> opinions? For example, do we keep per device Kconfig options (eg. >> CONFIG_RTW88_8822BS, RTW88_8822CS and so on) or should we have only one >> more bus level option (eg. CONFIG_RTW88_SDIO)? rtw88 now uses the former >> and IIRC so does mt76. ath10k/ath11k/ath12k again use the latter :) > > No strong feelings. Larry (IIRC) provided a fair justification for > the RTW symbols. If the module binary grows noticeably then having > the kconfig does indeed make sense. Thanks, makes sense. So the plan is that rtw88 continues to use per device Kconfig symbols with SDIO.
Recently the rtw88 driver has gained locking support for the "slow" bus types (USB, SDIO) as part of USB support. Thanks to everyone who helped make this happen! Based on the USB work (especially the locking part and various bugfixes) this series adds support for SDIO based cards. It's the result of a collaboration between Jernej and myself. Neither of us has access to the rtw88 datasheets. All of our work is based on studying the RTL8822BS and RTL8822CS vendor drivers and trial and error. Jernej and myself have tested this with RTL8822BS and RTL8822CS cards. Other users have confirmed that RTL8821CS support is working as well. RTL8723DS may also work (we tried our best to handle rtw_chip_wcpu_11n where needed) but has not been tested at this point. Jernej's results with a RTL8822BS: - Main functionality works - Had a case where no traffic got across the link until he issued a scan My results with a RTL8822CS: - 2.4GHz and 5GHz bands are both working - TX throughput on a 5GHz network is between 50 Mbit/s and 90 Mbit/s - RX throughput on a 5GHz network is at 19 Mbit/s - Sometimes there are frequent reconnects (once every 1-5 minutes) after the link has been up for a long time (multiple hours). Today I was unable to reproduce this though (I only had reconnect in 8 hours). Why is this an RFC? - It needs a through review especially by the rtw88 maintainers - It's not clear to me how the "mmc: sdio" patch will be merged (will Ulf take this or can we merge it thorugh the rtw88/linux wireless driver tree?) - Any comments / debugging hints on the reconnect / no traffic issues (see above) are welcome - My understanding is that there's a discussion about the rtw88 Kconfig symbols. We're adding four new ones within this series. It's not clear to me what the conclusion is on this topic though. - As with most patches: testing is very welcome. If things are working fine then a Tested-by is appreciated (with some details about the card, throughput, ...). If something doesn't work for you: please still report back so we can investigate that problem! Jernej Skrabec (2): rtw88: ps: Increase LEAVE_LPS_TRY_CNT for SDIO based chipsets rtw88: Add support for the SDIO based RTL8822BS chipset Martin Blumenstingl (17): rtw88: mac: Use existing interface mask macros in rtw_pwr_seq_parser() rtw88: pci: Change type of rtw_hw_queue_mapping() and ac_to_hwq to enum rtw88: pci: Change queue datatype from u8 to enum rtw_tx_queue_type rtw88: Move enum rtw_tx_queue_type mapping code to tx.{c,h} mmc: sdio: add Realtek SDIO vendor ID and various wifi device IDs rtw88: rtw8821c: Add support for parsing the RTL8821CS (SDIO) efuse rtw88: rtw8822b: Add support for parsing the RTL8822BS (SDIO) efuse rtw88: rtw8822c: Add support for parsing the RTL8822CS (SDIO) efuse rtw88: hci: Add an optional power_switch() callback to rtw_hci_ops rtw88: mac: Add support for the SDIO HCI in rtw_pwr_seq_parser() rtw88: mac: Add support for the SDIO HCI in the TX/page table setup rtw88: sdio: Add HCI implementation for SDIO based chipsets rtw88: mac: Add support for SDIO specifics in the power on sequence rtw88: main: Add the rpwm_addr and cpwm_addr for SDIO based chipsets rtw88: main: Reserve 8 bytes of extra TX headroom for SDIO based cards rtw88: Add support for the SDIO based RTL8822CS chipset rtw88: Add support for the SDIO based RTL8821CS chipset drivers/net/wireless/realtek/rtw88/Kconfig | 36 + drivers/net/wireless/realtek/rtw88/Makefile | 12 + drivers/net/wireless/realtek/rtw88/debug.h | 1 + drivers/net/wireless/realtek/rtw88/hci.h | 8 + drivers/net/wireless/realtek/rtw88/mac.c | 62 +- drivers/net/wireless/realtek/rtw88/mac.h | 1 - drivers/net/wireless/realtek/rtw88/main.c | 9 +- drivers/net/wireless/realtek/rtw88/pci.c | 50 +- drivers/net/wireless/realtek/rtw88/ps.h | 2 +- drivers/net/wireless/realtek/rtw88/reg.h | 10 + drivers/net/wireless/realtek/rtw88/rtw8821c.c | 9 + drivers/net/wireless/realtek/rtw88/rtw8821c.h | 6 + .../net/wireless/realtek/rtw88/rtw8821cs.c | 34 + drivers/net/wireless/realtek/rtw88/rtw8822b.c | 10 + drivers/net/wireless/realtek/rtw88/rtw8822b.h | 6 + .../net/wireless/realtek/rtw88/rtw8822bs.c | 34 + drivers/net/wireless/realtek/rtw88/rtw8822c.c | 9 + drivers/net/wireless/realtek/rtw88/rtw8822c.h | 6 + .../net/wireless/realtek/rtw88/rtw8822cs.c | 34 + drivers/net/wireless/realtek/rtw88/sdio.c | 1242 +++++++++++++++++ drivers/net/wireless/realtek/rtw88/sdio.h | 175 +++ drivers/net/wireless/realtek/rtw88/tx.c | 41 + drivers/net/wireless/realtek/rtw88/tx.h | 3 + include/linux/mmc/sdio_ids.h | 9 + 24 files changed, 1763 insertions(+), 46 deletions(-) create mode 100644 drivers/net/wireless/realtek/rtw88/rtw8821cs.c create mode 100644 drivers/net/wireless/realtek/rtw88/rtw8822bs.c create mode 100644 drivers/net/wireless/realtek/rtw88/rtw8822cs.c create mode 100644 drivers/net/wireless/realtek/rtw88/sdio.c create mode 100644 drivers/net/wireless/realtek/rtw88/sdio.h