#
2c681cbf |
|
14-Feb-2024 |
Ping-Ke Shih <pkshih@realtek.com> |
wifi: rtw89: 8922a: add set_channel RF part Configure RF registers according to band, channel, bandwidth. Since this chip will support MLO, it needs check the operating mode to decide paths we are going to configure. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://msgid.link/20240215055741.14148-4-pkshih@realtek.com
|
#
ca1e1163 |
|
14-Feb-2024 |
Ping-Ke Shih <pkshih@realtek.com> |
wifi: rtw89: 8922a: add set_channel MAC part To set channel, add a function to get TXSB (TX subband) that is hardware index to indicate primary channel. Then, configure band, channel, bandwidth and TXSB via registers. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://msgid.link/20240215055741.14148-2-pkshih@realtek.com
|
#
db84b758 |
|
08-Feb-2024 |
Ping-Ke Shih <pkshih@realtek.com> |
wifi: rtw89: correct PHY register offset for PHY-1 PHY-1 can be seen as a copy of PHY-0, and the difference is their base register address, so add a function to get offset to access PHY-1. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://msgid.link/20240209065229.34515-2-pkshih@realtek.com
|
#
ff146ec2 |
|
01-Feb-2024 |
Ping-Ke Shih <pkshih@realtek.com> |
wifi: rtw89: 8922a: rfk: implement chip_ops to call RF calibrations Calling RF calibrations when interface up, connection, switching bands and going to scan. For 8922AE, RF calibrations are moved to firmware, so use H2C commands to trigger RF calibrations and wait for a C2H event to indicate completion. Then, do next RF calibration. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://msgid.link/20240202030642.108385-10-pkshih@realtek.com
|
#
bd6f5f27 |
|
01-Feb-2024 |
Ping-Ke Shih <pkshih@realtek.com> |
wifi: rtw89: rfk: add H2C command to trigger TSSI TSSI is short for transmitter signal strength indication, which is a close-loop hardware circuit to feedback actual transmitting power as a reference to adjust power for next transmission. When connecting and switching bands or channels, do TSSI calibration and reset hardware status to output expected power. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://msgid.link/20240202030642.108385-9-pkshih@realtek.com
|
#
ad1c86e9 |
|
01-Feb-2024 |
Ping-Ke Shih <pkshih@realtek.com> |
wifi: rtw89: rfk: add a completion to wait RF calibration report from C2H event The RF calibrations should be executed one by one, so add a completion to ensure one is finish before next. The report from C2H event contains state and optional version, and we only check the state for now. We also care about the time a RF calibration takes, so record start time before asking firmware to do calibration and get the delta time when receiving report. Consider SER recovery, we can't receive C2H event, use half of argument 'ms' as fixed delay that is 2 times of measured maximum time of calibrations. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://msgid.link/20240202030642.108385-2-pkshih@realtek.com
|
#
88d1f9b2 |
|
23-Jan-2024 |
Ping-Ke Shih <pkshih@realtek.com> |
wifi: rtw89: 8922a: add RF read/write v2 Implement indirect interface v2 to read/write RF registers via PHY registers for 8922A. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://msgid.link/20240124033637.12330-5-pkshih@realtek.com
|
#
10af1627 |
|
19-Jan-2024 |
Ping-Ke Shih <pkshih@realtek.com> |
wifi: rtw89: 8922a: add chip_ops related to BB init The chip_ops::bb_preinit and ::bb_postinit are called before and after loading BB parameters from tables of firmware file. The ::bb_reset is used to reset hardware state, and currently it is not needed by 8922AE so leave it as empty. The ::bb_sethw is to implement conditional parameters. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://msgid.link/20240120003831.7014-4-pkshih@realtek.com
|
#
6bd23219 |
|
04-Jan-2024 |
Ping-Ke Shih <pkshih@realtek.com> |
wifi: rtw89: phy: set channel_info for WiFi 7 chips The channel_info is hardware settings to reflect operational status, such as scale factor, report unit, buffer matrix size, RU size and so on. Then, we can get desired reports to do further tuning. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://msgid.link/20240105064440.36926-1-pkshih@realtek.com
|
#
ce84ecbd |
|
04-Jan-2024 |
Ping-Ke Shih <pkshih@realtek.com> |
wifi: rtw89: phy: add BB wrapper of TX power for WiFi 7 chips TX power is controlled by BB layer basically, but it should interact with MAC layer, so these registers are put on MAC register domain and called BB wrapper, which contains TX power for each MAC ID, OFDMA RU power, and consideration of power type table. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://msgid.link/20240105064433.36870-1-pkshih@realtek.com
|
#
c207e14d |
|
04-Jan-2024 |
Ping-Ke Shih <pkshih@realtek.com> |
wifi: rtw89: 8922a: add NCTL pre-settings for WiFi 7 chips NCTL standing for nano-controller is used to assist RF calibration. Basically, we write settings from a table, but format of the table can't describe register mask and additional conditions, so add a function to set this kind of settings. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://msgid.link/20240105064422.36812-1-pkshih@realtek.com
|
#
0edcdd82 |
|
04-Jan-2024 |
Chung-Hsuan Hung <hsuan8331@realtek.com> |
wifi: rtw89: phy: add parser to support RX gain dynamic setting flow Add RX gain offset dynamic setting flow according to different bands and bandwidths. RX gain offset values will be different according to different channel bands, therefore, this dynamic mechanism is needed while channel is changed. Add this to parse data from the element of firmware file, and then we can use them easier at runtime. Signed-off-by: Chung-Hsuan Hung <hsuan8331@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://msgid.link/20240105064228.36580-3-pkshih@realtek.com
|
#
178b8e7d |
|
12-Dec-2023 |
Ping-Ke Shih <pkshih@realtek.com> |
wifi: rtw89: add C2H event handlers of RFK log and report Trigger a RFK (RF calibration) in firmware by a H2C command, and in progress it reports log and a result finally by C2H events. Firstly, add prototype of the C2H event handlers to have a simple picture of framework. The callers who trigger H2C will wait until a C2H event is received, so we must process these C2H events in receiving process. Thus, mark this kind of C2H events as atomic. Also, timestamp is also useful for debugging, mark C2H events carrying RFK log as atomic as well. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://msgid.link/20231213005054.10568-5-pkshih@realtek.com
|
#
7a9192ee |
|
12-Dec-2023 |
Ping-Ke Shih <pkshih@realtek.com> |
wifi: rtw89: load RFK log format string from firmware file To debug RFK (RF calibration) in firmware, it sends log via firmware C2H events to driver with string format ID and four arguments. Load formatted string from firmware file, and the string ID can get back its string. Then, use regular print format to show the message. This firmware element layout looks like +============================================+ | elm ID | elm size | version | | +----------+----------+----------+-----------+ | | nr |rsvd |rfk_id|rsvd| +--------------------------------------------+ | offset[] (__le16 * nr) | | ... | +--------------------------------------------+ | formatted string with null termintor (*nr) | | ... | +============================================+ * a firmware file can contains more than one elements with this element ID named RTW89_FW_ELEMENT_ID_RFKLOG_FMT (19), because many RFK needs its own formatted strings, so add 'rfk_id' to know it belongs to which RFK. * the 'formatted string' just follow 'offset[]' without padding to align 32bits. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://msgid.link/20231213005054.10568-4-pkshih@realtek.com
|
#
d60e73e5 |
|
12-Dec-2023 |
Ping-Ke Shih <pkshih@realtek.com> |
wifi: rtw89: fw: load TX power track tables from fw_element The TX power track tables are used to define compensation power reflected to thermal value. Currently, we have 16 (2 * 4 * 2) tables made by combinations of {negative/positive thermal value, 2GHz/2GHz-CCK/5GHz/6GHz, path A/B} Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://msgid.link/20231213005054.10568-2-pkshih@realtek.com
|
#
0bb18525 |
|
21-Nov-2023 |
Yi-Chen Chen <jamie_chen@realtek.com> |
wifi: rtw89: phy: dynamically adjust EDCCA threshold Add dynamic mechanism EDCCA (Energy Detection Clear Channel Assessment) in track work. Using a fixed-value threshold will make EDCCA particularly sensitive and cause failure to transmit under certain circumstances. Therefore, the threshold is dynamically adjusted to make EDCCA suitable for any situation. However, in some cases, we will adjust the EDCCA threshold to the highest level so that urgent transmissions can be performed successfully, such as scanning. Finally, in order to observe the EDCCA report in time, add the EDCCA perIC register macro and EDCCA HW report analysis. EDCCA logs can be displayed by using the EDCCA debug mask. Signed-off-by: Yi-Chen Chen <jamie_chen@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20231122060458.30878-3-pkshih@realtek.com
|
#
e102ff4b |
|
16-Nov-2023 |
Ping-Ke Shih <pkshih@realtek.com> |
wifi: rtw89: 8852c: read RX gain offset from efuse for 6GHz channels Read calibration values of RX gain offset from efuse, and set them to registers to normalize RX gain for all hardware modules. Then, PHY dynamic mechanism can get expected values to adjust hardware parameters to yield expected performance. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20231117024029.113845-5-pkshih@realtek.com
|
#
5d2f3c3a |
|
16-Oct-2023 |
Cheng-Chieh Hsieh <cj.hsieh@realtek.com> |
wifi: rtw89: modify the register setting and the flow of CFO tracking The register address used for CFO(carrier frequency offset) tracking is different from WiFi 7 series, so we change the way to access it. And we refine the flow of CFO tracking to compatible all WiFi 7 and 6 ICs. Signed-off-by: Cheng-Chieh Hsieh <cj.hsieh@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20231016065115.751662-4-pkshih@realtek.com
|
#
1f3cd090 |
|
11-Oct-2023 |
Ping-Ke Shih <pkshih@realtek.com> |
wifi: rtw89: Add EHT rate mask as parameters of RA H2C command Set EHT rate mask to RA (rate adaptive) H2C command according to handshake result. The EHT rate mask format looks like 44 28 12 4 0 +----------------+----------------+--------+----+ | EHT 2SS rate | EHT 1SS rate | OFDM | CCK| +----------------+----------------+--------+----+ Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20231011115256.6121-4-pkshih@realtek.com
|
#
932f85c1 |
|
02-Oct-2023 |
Zong-Zhe Yang <kevin_yang@realtek.com> |
wifi: rtw89: phy: set TX power RU limit according to chip gen Wi-Fi 6 chips and Wi-Fi 7 chips have different register design for TX power RU limit. We rename original setting stuffs with a suffix `_ax`, concentrate related enum declaration in phy.h, and implement setting flow for Wi-Fi 7 chips. Then, we set TX power RU limit according to chip generation. Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20231003015446.14658-6-pkshih@realtek.com
|
#
70aa04f2 |
|
02-Oct-2023 |
Zong-Zhe Yang <kevin_yang@realtek.com> |
wifi: rtw89: phy: set TX power limit according to chip gen Wi-Fi 6 chips and Wi-Fi 7 chips have different register design for TX power limit. We rename original setting stuffs with a suffix `_ax`, concentrate related enum declaration in phy.h, and implement setting flow for Wi-Fi 7 chips. Then, we set TX power limit according to chip generation. Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20231003015446.14658-5-pkshih@realtek.com
|
#
3b7dc652 |
|
02-Oct-2023 |
Zong-Zhe Yang <kevin_yang@realtek.com> |
wifi: rtw89: phy: set TX power offset according to chip gen We have a register to control TX power of each rate section to increase or decrease an offset. But, Wi-Fi 6 chips and Wi-Fi 7 chips have different address and format for this control register. We rename original setting stuffs with a suffix `_ax` and implement setting flow for Wi-Fi 7 chips. Then, we set TX power offset according to chip generation. Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20231003015446.14658-4-pkshih@realtek.com
|
#
d5136642 |
|
02-Oct-2023 |
Zong-Zhe Yang <kevin_yang@realtek.com> |
wifi: rtw89: phy: set TX power by rate according to chip gen Wi-Fi 6 chips and Wi-Fi 7 chips have different register design for TX power by rate. We rename original setting stuffs with a suffix `_ax` and implement setting flow for Wi-Fi 7 chips. Then, we set TX power by rate according to chip generation. Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20231003015446.14658-3-pkshih@realtek.com
|
#
5ee7b2ea |
|
20-Sep-2023 |
Zong-Zhe Yang <kevin_yang@realtek.com> |
wifi: rtw89: load TX power related tables from FW elements The following FW elements are recognized, and then the valid entries in them are loaded into SW struct case by case. * TX power by rate * TX power limit 2 GHz * TX power limit 5 GHz * TX power limit 6 GHz * TX power limit RU 2 GHz * TX power limit RU 5 GHz * TX power limit RU 6 GHz * TX shape limit * TX shape limit RU One single firmware file can contain multiples of each of the above FW elements. Each of them is configured with a target RFE (RF front end) type. We choose one of the multiples to load based on RFE type. If there are multiples of the same FW elements with the same target RFE type. The last one will be applied. We don't want to have many loading variants for above FW elements. Even if between different chips or between different generations, we would like to maintain only one single set of loadings. So, the loadings are designed to consider compatibility. The main concepts are listed below. * The driver structures, which are used to cast binary entry from FW, cannot insert new members in the middle. If there are something new, they should always be appended at the tail. * Each binary entry from FW uses a dictionary way containing a key set and a data. The keys in the key set indicate where to put the data. * If size of driver struct and size of binary entry do not match when loading, it means the number of keys in the key set are different. Then, we deal with compatibility. No matter which one has more keys, we take/use zero on those mismatched keys. If driver struct is bigger (backward compatibility): e.g. SW uses two keys, but FW is built with one key. Then, put the data of FW(keyX) into SW[keyX][0]. If binary entry is bigger (forward compatibility): e.g. FW is built with two keys, but SW uses one key. Then, only take the data of FW(keyX, keyY = 0) into SW[keyX] Besides, chip info setup flow is tweaked a bit for the following. * Before loading FW elements, we need to determine chip RFE via efuse. * Setting up RFE parameters depends on loading FW elements ahead. Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20230920074322.42898-8-pkshih@realtek.com
|
#
058b2074 |
|
22-Aug-2023 |
Cheng-Chieh Hsieh <cj.hsieh@realtek.com> |
wifi: rtw89: phy: modify register setting of ENV_MNTR, PHYSTS and DIG The ENV_MNTR(environment monitor) is the dynamic mechanism which based on the HW of CCX(Cisco Compatible Extensions) which provide the channel loading and noisy level indicator to debug or support the 802.11k. The PHYSTS provide the detail PHY information per packet we received for debugging. The DIG(dynamic initial gain) is the dynamic mechanism to adjust the packet detect power level by received signal strength to avoid false detection of the WiFi packet. The address of registers used for ENV_MNTR, PHYSTS and DIG of WiFi 7 IC are different with WiFi 6 series, so we modify the method to access the register address in order to compatible with all WiFi 7 and 6 ICs. Signed-off-by: Cheng-Chieh Hsieh <cj.hsieh@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20230822125822.23817-7-pkshih@realtek.com
|
#
1165f571 |
|
22-Aug-2023 |
Ping-Ke Shih <pkshih@realtek.com> |
wifi: rtw89: phy: add phy_gen_def::cr_base to support WiFi 7 chips cr_base is base address of PHY control register. The base of WiFi 6 and 7 chips are 0x1_0000 and 0x2_0000 respectively, so define them accordingly. For example, if PHY address is 0x1330, absolute address is 0x1_1330 for WiFi 6 chips, and 0x2_1330 for WiFi 7 chips. Meanwhile, there are two copies of PHY hardware named PHY0 and PHY1. The offset between them is 0x2_0000, so the base address of PHY0 and PHY1 are 0x2_0000 and 0x4_0000 respectively. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20230822125822.23817-6-pkshih@realtek.com
|
#
e3715859 |
|
17-Apr-2023 |
Eric Huang <echuang@realtek.com> |
wifi: rtw89: add RSSI based antenna diversity RSSI statistics are grouped by CCK, OFDM or non-legacy rate. These statistics will be collected in training state for both (main/aux) antenna. There is a time period (ANTDIV_DELAY) for rate adaptive settle down before start collect statistics when switch antenna. Antenna diversity checks packet count from training state for each group and use the most one as the final RSSI for comparison, and then choose the better one as target antenna. Signed-off-by: Eric Huang <echuang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20230418012820.5139-7-pkshih@realtek.com
|
#
280c4447 |
|
22-Mar-2023 |
Chih-Kang Chang <gary.chang@realtek.com> |
wifi: rtw89: config EDCCA threshold during scan to prevent TX failed Need to configure EDCCA threshold to default value before scan, and recall original value after scan to prevent probe request can't be sent out. Signed-off-by: Chih-Kang Chang <gary.chang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20230322060238.43922-1-pkshih@realtek.com
|
#
bb9040b3 |
|
20-Feb-2023 |
Po-Hao Huang <phhuang@realtek.com> |
wifi: rtw89: adjust channel encoding to common function Since the range of channel table is identical among ICs. Make channel encode/decode function common and not IC dependent. So all ICs with matching firmware that needs this kind of coding can use it directly. This patch doesn't change logic at all. Signed-off-by: Po-Hao Huang <phhuang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20230220070202.29868-4-pkshih@realtek.com
|
#
29136c95 |
|
16-Nov-2022 |
Eric Huang <echuang@realtek.com> |
wifi: rtw89: switch BANDEDGE and TX_SHAPE based on OFDMA trigger frame There are some registers for transmit waveform control, two of them used in this change are for BANDEDGE and TX_SHAPE control. BANDEDGE controls whether to apply band edge filter to transmit waveform. TX_SHAPE controls whether to apply triangular mask to transmit waveform. It is found for some chip, these two should be turned off during OFDMA UL traffic for better performance. Signed-off-by: Eric Huang <echuang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20221117063001.42967-3-pkshih@realtek.com
|
#
d9112042 |
|
26-Oct-2022 |
Chih-Kang Chang <gary.chang@realtek.com> |
wifi: rtw89: collect and send RF parameters to firmware for WoWLAN For WoWLAN mode, we only collect and send RF parameters to Firmware without writing RF registers. So we add one function to practice it. Signed-off-by: Chih-Kang Chang <gary.chang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20221027052707.14605-2-pkshih@realtek.com
|
#
3b66519b |
|
14-Oct-2022 |
Ping-Ke Shih <pkshih@realtek.com> |
wifi: rtw89: phy: add dummy C2H handler to avoid warning message The C2H class 2 function 3 is to report retry count of low rate, but driver doesn't implement yet, so add a dummy case to avoid message: rtw89_8852be 0000:03:00.0: c2h class 2 not support Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20221014060237.29050-4-pkshih@realtek.com
|
#
6b069898 |
|
05-Oct-2022 |
Ping-Ke Shih <pkshih@realtek.com> |
wifi: rtw89: 8852b: add chip_ops::set_channel set_channel is main function to configure channel and bandwidth for all layers, namely MAC, BB and RF. Additionally, MAC layer enables CCK rate checking to avoid wrong rate from driver. BB layer configures SCO (Sample Clock Offset) for CCK, TX gain error/offset, and reset baseband hardware circuit after all configurations done. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20221005083212.45683-7-pkshih@realtek.com
|
#
6e5125bc |
|
05-Oct-2022 |
Ping-Ke Shih <pkshih@realtek.com> |
wifi: rtw89: make generic functions to convert subband gain index The gain tables use different domain index, so we need to convert the index from subband of chandef. Since these conversion functions can share with 8852b, make generic functions for further use. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20221005083212.45683-6-pkshih@realtek.com
|
#
9b43bd1a |
|
28-Sep-2022 |
Zong-Zhe Yang <kevin_yang@realtek.com> |
wifi: rtw89: phy: make generic txpwr setting functions Previously, we thought control registers or setting things for TX power series may change according to chip. So, setting functions are implemented chip by chip. However, until now, the functions keep the same among chips, at least 8852A, 8852C, and 8852B. There is a sufficient number of chips to share generic setting functions. So, we now remake them including TX power by rate, TX power offset, TX power limit, and TX power limit RU as generic ones in phy.c. Besides, there are some code refinements in the generic ones, but almost all of the logic doesn't change. Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20220928084336.34981-5-pkshih@realtek.com
|
#
7dbdf655 |
|
08-Sep-2022 |
Ping-Ke Shih <pkshih@realtek.com> |
wifi: rtw89: support TX diversity for 1T2R chipset Check RSSI strength to decide which path is better, and then set TX path accordingly. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20220908074140.39776-6-pkshih@realtek.com
|
#
9bea5761 |
|
24-Aug-2022 |
Cheng-Chieh Hsieh <cj.hsieh@realtek.com> |
wifi: rtw89: enlarge the CFO tracking boundary The calibration value of XTAL offset may be too large in some wifi modules, that the CFO tracking mechanism under the existing tracking boundary can not adjust the CFO to the tolerable range. So we enlarge it. Signed-off-by: Cheng-Chieh Hsieh <cj.hsieh@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20220824061425.13764-1-pkshih@realtek.com
|
#
07ef5f2f |
|
09-Aug-2022 |
Zong-Zhe Yang <kevin_yang@realtek.com> |
wifi: rtw89: txpwr: concentrate channel related control to top For future support on multiple channels, it would be disturbing if we still allow scattered leaf functions of TX power to query and manage channel related control by themselves. So, query rtw89_chan only on top functions. Then, pass it via functions to make sure that the values coming from the same struct rtw89_chan. Besides, fix rtw8852a_set_txpwr_offset() from rtw8852a_set_txpwr_ctrl() to rtw8852a_set_txpwr(). TX power offset should consider current band, so move it to chip_ops::set_txpwr() which will be called every time that channel is set. Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20220809104952.61355-6-pkshih@realtek.com
|
#
3e5831ca |
|
09-Aug-2022 |
Zong-Zhe Yang <kevin_yang@realtek.com> |
wifi: rtw89: introduce rtw89_chan for channel stuffs Introduce struct rtw89_chan ahead to encapsulate stuffs from struct rtw89_channel_params. These stuffs have a clone in HAL and are used throughout driver. After multiple channels support, it's expected that each channel instance has a configuration of them. So, we refine them with struct rtw89_chan by precise type first, and will re-arrange HAL by struct rtw89_chan in the following as well. (No logic has changed.) Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20220809104952.61355-3-pkshih@realtek.com
|
#
bc013052 |
|
08-Jun-2022 |
Eric Huang <echuang@realtek.com> |
rtw89: add new state to CFO state machine for UL-OFDMA Add an new state, RTW89_PHY_DCFO_STATE_HOLD, to keep CFO acceleration after CFO_PERIOD_CNT if the traffic is UL-OFDMA, which is calculated based on RX trigger frame counter. Signed-off-by: Eric Huang <echuang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20220608113224.11193-4-pkshih@realtek.com
|
#
9d9a9edc |
|
15-May-2022 |
Ping-Ke Shih <pkshih@realtek.com> |
rtw89: add ieee80211::sta_rc_update ops When peer's NSS, rate or bandwidth is changed, we update RA(rate adaptive) mask to ensure transmitting packets properly. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20220516005215.5878-2-pkshih@realtek.com
|
#
1b00e923 |
|
14-Apr-2022 |
Ping-Ke Shih <pkshih@realtek.com> |
rtw89: 8852c: add set channel of BB part BB does many settings during setting channel. First is to configure CCK for 2G channels, and then basic channel and bandwidth settings with a encoded channel index that will report to driver when we receive packets. Configure spur elimination to avoid spur of CSI and NBI tones in certain frequencies. Also, it initializes BT grant to arrange path sharing with BT according to band. Finally, reset TSSI and BB hardware to ensure it stays in initial state. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20220414062027.62638-12-pkshih@realtek.com
|
#
c7845551 |
|
14-Apr-2022 |
Ping-Ke Shih <pkshih@realtek.com> |
rtw89: 8852c: phy: configure TSSI bandedge TSSI is used to manage TX power with thermal value as a factor. This patch is to configure bandedge to TX proper waveform. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20220414062027.62638-5-pkshih@realtek.com
|
#
c6badab2 |
|
14-Apr-2022 |
Zong-Zhe Yang <kevin_yang@realtek.com> |
rtw89: 8852c: add TX power track tables TX power track tables are used to do TX power compensation according to thermal value. In order to work in existing and new chip, add new 6G entries, and change type from u8 to s8. Internal version table is HALRF_027_00_031. Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20220414062027.62638-4-pkshih@realtek.com
|
#
2a5f2b32 |
|
16-Mar-2022 |
Ping-Ke Shih <pkshih@realtek.com> |
rtw89: add config_rf_reg_v1 to configure RF parameter tables The format of RF parameter is changed; it doesn't encode delay parameters into table, but the delay coding becomes regular pair of register address and value. To help firmware to recover RF register settings, we need to download these parameters to firmware. For v1 format, only download partial parameters (ignore them with addr < 0x100). Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20220317055543.40514-6-pkshih@realtek.com
|
#
84d0e33e |
|
16-Mar-2022 |
Chung-Hsuan Hung <hsuan8331@realtek.com> |
rtw89: 8852c: add read/write rf register function Using encoded address which BIT(16) is used to discriminate which region is going to access. Illustrate the calling flow as below rtw89_phy_write_rf_v1() -+-> rtw89_phy_write_rf() // old interface +-> rtw89_phy_write_rf_a() // new interface Signed-off-by: Chung-Hsuan Hung <hsuan8331@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20220317055543.40514-5-pkshih@realtek.com
|
#
a9e06f2e |
|
17-Feb-2022 |
Yi-Tang Chiu <chiuyitang@realtek.com> |
rtw89: Limit the CFO boundaries of x'tal value Set the boundaries of x'tal value to avoid extremely adjusted results, causing severely unexpected CFO. Signed-off-by: Yi-Tang Chiu <chiuyitang@realtek.com> Signed-off-by: Yuan-Han Zhang <yuanhan1020@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20220218034537.9338-1-pkshih@realtek.com
|
#
0701a424 |
|
11-Feb-2022 |
Zong-Zhe Yang <kevin_yang@realtek.com> |
rtw89: refine naming of rfk helpers with prefix Since these macro in rfk helpers are common now, a common naming should be better. So, apply RTW89_ as prefix to them, and modify the use correspondly. No logic is changed at all. Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20220211075953.40421-3-pkshih@realtek.com
|
#
db7fa61a |
|
11-Feb-2022 |
Zong-Zhe Yang <kevin_yang@realtek.com> |
rtw89: make rfk helpers common across chips These rfk helpers are also useful for the chip which is under planning. So, move them to common code to avoid duplicate stuff in the future. Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20220211075953.40421-2-pkshih@realtek.com
|
#
1c2423de |
|
21-Jan-2022 |
Johnson Lin <johnson.lin@realtek.com> |
rtw89: refine DIG feature to support 160M and CCK PD DIG, which is short for dynamic initial gain, is used to adjust gain to get good RX performance. CCK PD feature, a mechanism that adjusts 802.11b CCK packet detection(PD) power threshold based on environment noisy level in order to avoid false alarm. Also, refine related variable naming. Signed-off-by: Johnson Lin <johnson.lin@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20220121075555.12457-1-pkshih@realtek.com
|
#
861e58c8 |
|
20-Dec-2021 |
Zong-Zhe Yang <kevin_yang@realtek.com> |
rtw89: extract modules by chipset We are planning to support more chipsets, e.g. 8852C. Before that, we consider architecutre to handle multiple kinds of chipsets. Obviosuly, based on original design, rtw89_core module will have large size even if there is only one chipset under running. It is because all chipset related things are put in rtw89_core now. To reduce such overhead, we extract modules of rtw89 and adjust dependencies between modules. The following assumes that 8852AE, 8852AU, and 8852CE are all supported, we describe the difference before and after extraction. [Before extraction] ------------- |------------------------------------ | rtw89_usb | V ------------- --------------------------------------- ------------- | rtw89_core (including 8852A, 8852C) | <--- | rtw89_pci | --------------------------------------- ------------- The data of 8852A and 8852C are built in rtw89_core. And rtw89_pci is the entry of 8852AE and 8852CE. And rtw89_usb is the entry of 8852AU. [After extraction] ------------- ---------------- |----------- | rtw89_usb | <-------- | rtw89_8852au | | ------------- ---------------- V --------------- | -------------- | | <--------------- | rtw89_core | <--- | rtw89_8852a | -------------- | | <--------------- ^ ^ --------------- | | | ------------- ---------------- | | | | <-------- | rtw89_8852ae | | |----------- | rtw89_pci | ---------------- | | | <----------------- | ------------- | | --------------- ---------------- |--------------- | rtw89_8852c | <------ | rtw89_8852ce | --------------- ---------------- The data of 8852A/8852C is extracted to rtw89_8852a/rtw89_8852c. And rtw89_pci/rtw89_usb handles only common flow of pci/usb bus. Finally, 8852AE, 8852AU, and 8852CE have individual entry modules, i.e. rtw89_8852ae, rtw89_8852au, and rtw89_8852ce correspondingly. Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20211221025828.25092-1-pkshih@realtek.com
|
#
eb4e52b3 |
|
10-Nov-2021 |
Po Hao Huang <phhuang@realtek.com> |
rtw89: fix incorrect channel info during scan We used to fill in rx skbs' frequency field by mac80211's current channel value. In some cases, mac80211 switches channel before all rx packets have been processed. This results in incorrect bss info. We fix this by filling in frequency field with channel index obtained from hardware, then fix potential cck missing issue by skb's original hw rate. After all fix is done, convert hw rate back to the supported band rate index. Signed-off-by: Po Hao Huang <phhuang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20211111023706.14154-3-pkshih@realtek.com
|
#
e3ec7017 |
|
11-Oct-2021 |
Ping-Ke Shih <pkshih@realtek.com> |
rtw89: add Realtek 802.11ax driver This driver named rtw89, which is the next generation of rtw88, supports Realtek 8852AE 802.11ax 2x2 chip whose new features are OFDMA, DBCC, Spatial reuse, TWT and BSS coloring; now some of them aren't implemented though. The chip architecture is entirely different from the chips supported by rtw88 like RTL8822CE 802.11ac chip. First of all, register address ranges are totally redefined, so it's impossible to reuse register definition. To communicate with firmware, new H2C/C2H format is proposed. In order to have better utilization, TX DMA flow is changed to two stages DMA. To provide rich RX status information, additional RX PPDU packets are added. Since there are so many differences mentioned above, we decide to propose a new driver. It has many authors, they are listed in alphabetic order: Chin-Yen Lee <timlee@realtek.com> Ping-Ke Shih <pkshih@realtek.com> Po Hao Huang <phhuang@realtek.com> Tzu-En Huang <tehuang@realtek.com> Vincent Fann <vincent_fann@realtek.com> Yan-Hsuan Chuang <tony0620emma@gmail.com> Zong-Zhe Yang <kevin_yang@realtek.com> Tested-by: Aaron Ma <aaron.ma@canonical.com> Tested-by: Brian Norris <briannorris@chromium.org> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20211008035627.19463-1-pkshih@realtek.com
|