mbox series

[RFC,v1,00/19] rtw88: Add SDIO support

Message ID 20221227233020.284266-1-martin.blumenstingl@googlemail.com (mailing list archive)
Headers show
Series rtw88: Add SDIO support | expand

Message

Martin Blumenstingl Dec. 27, 2022, 11:30 p.m. UTC
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

Comments

Ping-Ke Shih Dec. 29, 2022, 4:19 a.m. UTC | #1
> -----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
Martin Blumenstingl Dec. 29, 2022, 11:18 p.m. UTC | #2
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
Ping-Ke Shih Dec. 30, 2022, 12:06 a.m. UTC | #3
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
Kalle Valo Jan. 16, 2023, 4:01 p.m. UTC | #4
(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 :)
Jakub Kicinski Jan. 17, 2023, 5:21 p.m. UTC | #5
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.
Kalle Valo Jan. 17, 2023, 6:01 p.m. UTC | #6
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.