From: Ping-Ke Shih <pkshih@realtek.com>
To: Lucas Tanure <lucas.tanure@neat.no>
Cc: "linux-wireless@vger.kernel.org" <linux-wireless@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"Krzysztof Opasiak" <krzysztof.opasiak@neat.no>,
"Anders Rønningen" <anders@neat.no>,
"Hilda Wu" <hildawu@realtek.com>,
"Max Chou" <max.chou@realtek.com>
Subject: RE: wifi: rtw88: 8822cs/bs: Issues migrating RTL8822CS/BS from downstream to upstream driver
Date: Mon, 22 Jun 2026 06:24:53 +0000 [thread overview]
Message-ID: <fc896e3ad87541dbbb76caa8e48d23bf@realtek.com> (raw)
In-Reply-To: <CALt7t=G_ssGBb1i+knq1_tbcpwi_TcrK+7GBMH3vNLQ3+rcetA@mail.gmail.com>
Lucas Tanure <lucas.tanure@neat.no> wrote:
> Hi Ping-Ke,
>
> On Tue, Jun 16, 2026 at 4:30 AM Ping-Ke Shih <pkshih@realtek.com> wrote:
> >
> > 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.
>
> If Realtek has an internal .txt -> C conversion tool, could you share it?
> Otherwise, could you put us in contact with the team that can verify
> our converted tables?
The better way is to check how vendor driver convert .txt into driver, and
what it writes to registers.
>
> >
> > 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).
>
> I used Claude, and it converted our vendor TXPWR_LMT.txt /
> PHY_REG_PG.txt into the rtw88 C arrays.
> Here is exactly how Claude did it - please tell us if any step is wrong.
>
> Row mapping (one TXPWR_LMT.txt line -> rtw_txpwr_lmt_cfg_pair rows):
> header "## 2.4G, 20M, 1T, CCK" + "CH01 16 15 15" (columns FCC ETSI MKK)
> -> { 0, 0, 0, 0, 1, 64 } FCC (regd 0)
> { 2, 0, 0, 0, 1, 60 } ETSI (regd 2)
> { 1, 0, 0, 0, 1, 60 } MKK (regd 1)
> One line -> 3 rows (one per regulatory column). Fields {regd, band,
> bw, rs, ch,
> value}: regd FCC/MKK/ETSI = 0/1/2; band/bw/rs come from the header;
> value = dBm*U.
>
> Unit (value = real_dBm * U):
> 8822c, U=4 (max_power_index 0x7f):
> bb_pg 0xc20 = 0x484c5054 = {18,19,20,21} (0x48=72=18*4)
> txpwr_lmt ETSI/CCK/ch1 = 60 = 15 dBm
> 8822b, U=2 (max_power_index 0x3f):
> txpwr_lmt FCC/CCK/ch1 = 32 = 16 dBm
> Both equal our vendor .txt (real dBm), so txpwr_lmt = dBm * U and
> bb_pg byte = codeword * U (packed high->low).
>
> Is this correct?
I don't remember the exact units these chips use. By the rtw88 driver,
.txgi_factor = 1 / 2 for RTL8822B and RTL8822C
So I think the units are correct.
For TX power unit, I remember it is not dBm, but with an offset, so you can
find function names of driver calling *_power_index_*. But treating it in
unit of dBm would be easier to understand.
I think the built-in tables in driver are very similar to the tables you
converted from .txt. I'd suggest using AI to compare their difference as
a validation -- the difference (TX power in dB) will be small (about 1
or 2 dB. I guess).
prev parent reply other threads:[~2026-06-22 6:24 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-06-15 13:55 wifi: rtw88: 8822cs/bs: Issues migrating RTL8822CS/BS from downstream to upstream driver Lucas Tanure
2026-06-16 3:30 ` Ping-Ke Shih
2026-06-16 11:02 ` Lucas Tanure
2026-06-22 6:24 ` Ping-Ke Shih [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=fc896e3ad87541dbbb76caa8e48d23bf@realtek.com \
--to=pkshih@realtek.com \
--cc=anders@neat.no \
--cc=hildawu@realtek.com \
--cc=krzysztof.opasiak@neat.no \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-wireless@vger.kernel.org \
--cc=lucas.tanure@neat.no \
--cc=max.chou@realtek.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox