wifi: rtw88: 8822cs/bs: Issues migrating RTL8822CS/BS from downstream to upstream driver

wifi: rtw88: 8822cs/bs: Issues migrating RTL8822CS/BS from downstream to upstream driver

[Lucas Tanure]

Hi Ping-Ke,

We are bringing up an RTL8822BS / RTL8822CS combo on a Rockchip PX30
board (kernel 6.1.118), Wi-Fi over SDIO, BT on the same die over UART
via btrtl + hci_h5.

We're deliberately migrating off Realtek's out-of-tree SDIO vendor
driver to mainline rtw88: the vendor driver hits memory-corruption
bugs we've been unable to get support on, and mainline is the better
long-term path.
That migration leaves us two gaps I'd appreciate your guidance on:

1) Power-parameter tables. Mainline carries the TX-power data as generated
   C arrays in rtw88xxc_table.c, while the vendor driver ships the same
   data as text files.

   The TX-power limits look like this (TXPWR_LMT.txt):

       ##  2.4G, 20M, 1T, CCK, //(1M;2M;5.5M;11M)
       ##  START
       ##  #3#  FCC  ETSI  MKK
       CH01  16  15  15
       CH02  16  15  15
       ##  END

   and the power-by-rate like this (PHY_REG_PG.txt):

       #[2.4G][A]#
       [1Tx] 0xc20  0xffffffff  18 19 19 19  // {11M 5.5M 2M 1M}
       [1Tx] 0xc24  0xffffffff  18 18 18 18  // {18M 12M 9M 6M}

   Is there any way to convert these .TXT files into the C tables? It
seems the vendor driver and the mainline driver power configuration
don't have anything in common.

2) Is there an upstream (linux-firmware) RTL8822BS firmware that
supports the UART transport (rtl_bt/rtl8822bs_fw.bin + config), or
does the 8822BS firmware still have to come from the vendor BSP?
   Is there a problem using vendor firmware (not released at
linux-firmware) with the mainline driver?

Thanks,
Lucas Tanure
Neat

RE: wifi: rtw88: 8822cs/bs: Issues migrating RTL8822CS/BS from downstream to upstream driver

[Ping-Ke Shih]

Hi,

Lucas Tanure <lucas.tanure@neat.no> wrote:
> Hi Ping-Ke,
> 
> We are bringing up an RTL8822BS / RTL8822CS combo on a Rockchip PX30
> board (kernel 6.1.118), Wi-Fi over SDIO, BT on the same die over UART
> via btrtl + hci_h5.
> 
> We're deliberately migrating off Realtek's out-of-tree SDIO vendor
> driver to mainline rtw88: the vendor driver hits memory-corruption
> bugs we've been unable to get support on, and mainline is the better
> long-term path.
> That migration leaves us two gaps I'd appreciate your guidance on:
> 
> 1) Power-parameter tables. Mainline carries the TX-power data as generated
>    C arrays in rtw88xxc_table.c, while the vendor driver ships the same
>    data as text files.
> 
>    The TX-power limits look like this (TXPWR_LMT.txt):
> 
>        ##  2.4G, 20M, 1T, CCK, //(1M;2M;5.5M;11M)
>        ##  START
>        ##  #3#  FCC  ETSI  MKK
>        CH01  16  15  15
>        CH02  16  15  15
>        ##  END

The tool from .txt to C arrays for vendor driver is not maintained by my team,
but I think it isn't too hard to use AI tool to convert the format. 

The C array from vendor driver to rtw88 struct is also a simple conversion
you can use AI to assist this.

If you have traced rtw88, the struct for TX power limit is:

struct rtw_txpwr_lmt_cfg_pair {
	u8 regd;
	u8 band;
	u8 bw;
	u8 rs;
	u8 ch;
	s8 txpwr_lmt;
};

> 
>    and the power-by-rate like this (PHY_REG_PG.txt):
> 
>        #[2.4G][A]#
>        [1Tx] 0xc20  0xffffffff  18 19 19 19  // {11M 5.5M 2M 1M}
>        [1Tx] 0xc24  0xffffffff  18 18 18 18  // {18M 12M 9M 6M}

TX power by rate is:

struct rtw_phy_pg_cfg_pair {
	u32 band;
	u32 rf_path;
	u32 tx_num;
	u32 addr;
	u32 bitmask;
	u32 data;
};

> 
>    Is there any way to convert these .TXT files into the C tables? It
> seems the vendor driver and the mainline driver power configuration
> don't have anything in common.

The purpose is different. The .TXT is from human point of view to be easier
to fill calibration data one by one. The design of C arrays is to look up table
quickly (it isn't so quickly though).

> 
> 2) Is there an upstream (linux-firmware) RTL8822BS firmware that
> supports the UART transport (rtl_bt/rtl8822bs_fw.bin + config), or
> does the 8822BS firmware still have to come from the vendor BSP?

Currently, no. 

>    Is there a problem using vendor firmware (not released at
> linux-firmware) with the mainline driver?

For BT part, I think it can work. But to work with WiFi, it needs
BT-coexistence implemented in WiFi driver to support UART BT. Unfortunately 
current is only partially support UART BT.

Ping-Ke