summaryrefslogtreecommitdiff
path: root/drivers/net/wireless/realtek/rtw88/reg.h
AgeCommit message (Collapse)Author
2025-03-13wifi: rtw88: Add some definitions for RTL8814AUBitterblue Smith
Add various register definitions which will be used by the new driver. Signed-off-by: Bitterblue Smith <rtl8821cerfe2@gmail.com> Acked-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/1dcb5abb-26f8-4db5-be36-057de56465e5@gmail.com
2025-02-10wifi: rtw88: Fix download_firmware_validate() for RTL8814AUBitterblue Smith
After the firmware is uploaded, download_firmware_validate() checks some bits in REG_MCUFW_CTRL to see if everything went okay. The RTL8814AU power on sequence sets bits 13 and 12 to 2, which this function does not expect, so it thinks the firmware upload failed. Make download_firmware_validate() ignore bits 13 and 12. Signed-off-by: Bitterblue Smith <rtl8821cerfe2@gmail.com> Acked-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/049d2887-22fc-47b7-9e59-62627cb525f8@gmail.com
2025-01-12wifi: rtw88: Add support for LED blinkingBitterblue Smith
Register a struct led_classdev with the kernel's LED subsystem and create a throughput-based trigger for it. Then mac80211 makes the LED blink. Tested with Tenda U12 (RTL8812AU), Tenda U9 (RTL8811CU), TP-Link Archer T2U Nano (RTL8811AU), TP-Link Archer T3U Plus (RTL8812BU), Edimax EW-7611UCB (RTL8821AU), LM842 (RTL8822CU). Also tested with devices which don't have LEDs: the laptop's internal RTL8822CE and a no-name RTL8723DU. Signed-off-by: Bitterblue Smith <rtl8821cerfe2@gmail.com> Acked-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/6c43451f-ab2f-4e76-ac6e-ff5a18dd981d@gmail.com
2025-01-12wifi: rtw88: Add USB PHY configurationBitterblue Smith
Add some extra configuration for USB devices. Currently only RTL8822BU version (cut) D needs this. The new code makes use of the existing usb3_param_8822b array from rtw8822b.c. A user reported that TP-Link Archer T3U in USB 3 mode was randomly disconnecting from USB: [ 26.036502] usb 2-2: new SuperSpeed USB device number 3 using xhci_hcd ... [ 27.576491] usb 2-2: USB disconnect, device number 3 [ 28.621528] usb 2-2: new SuperSpeed USB device number 4 using xhci_hcd ... [ 45.984521] usb 2-2: USB disconnect, device number 4 ... [ 46.845585] usb 2-2: new SuperSpeed USB device number 5 using xhci_hcd ... [ 94.400380] usb 2-2: USB disconnect, device number 5 ... [ 95.590421] usb 2-2: new SuperSpeed USB device number 6 using xhci_hcd This patch fixes that. Link: https://github.com/lwfinger/rtw88/issues/262 Signed-off-by: Bitterblue Smith <rtl8821cerfe2@gmail.com> Acked-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/9d312b14-0146-4be8-9c50-ef432234db50@gmail.com
2024-10-29wifi: rtw88: Add some definitions for RTL8821AU/RTL8812AUBitterblue Smith
Add 8821A and 8812A chip type enums. Add cck_high_power member to struct rtw_hal. This will be used to calculate the RX signal strength of RTL8812AU. Add various register definitions which will be used by the new drivers. Move some existing register definitions from rtw8821c.h and rtw8822b.h. They were duplicated in those headers and will also be used by the new drivers. Signed-off-by: Bitterblue Smith <rtl8821cerfe2@gmail.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/9279a9cd-6f86-4dc3-a095-7c36cb9b9d06@gmail.com
2024-08-09wifi: rtw88: usb: Init RX burst length according to USB speedBitterblue Smith
This is needed in order to make USB RX aggregation work with RTL8811CU (and presumably RTL8822BU and RTL8822CU also). I don't know what BIT_DMA_BURST_CNT, BIT_DMA_MODE, and BIT_DROP_DATA_EN are doing. Tested with RTL8822CU, RTL8811CU, and RTL8723DU. The RX speed is unchanged in my tests. Tested-by: Sascha Hauer <s.hauer@pengutronix.de> Signed-off-by: Bitterblue Smith <rtl8821cerfe2@gmail.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/ac569c6f-7129-4341-b523-901fe10cabff@gmail.com
2024-07-17wifi: rtw88: usb: Support USB 3 with RTL8822CU/RTL8822BUBitterblue Smith
The Realtek wifi 5 devices which support USB 3 are weird: when first plugged in, they pretend to be USB 2. The driver needs to send some commands to the device, which make it disappear and come back as a USB 3 device. Implement the required commands in rtw88. When a USB 3 device is plugged into a USB 2 port, rtw88 will try to switch it to USB 3 mode only once. The device will disappear and come back still in USB 2 mode, of course. Some people experience heavy interference in the 2.4 GHz band in USB 3 mode, so add a module parameter switch_usb_mode with the default value 1 to let people disable the switching. Signed-off-by: Bitterblue Smith <rtl8821cerfe2@gmail.com> Acked-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/77906c62-5674-426f-bde1-1b2a12a0339d@gmail.com
2024-06-21wifi: rtw88: usb: Further limit the TX aggregationBitterblue Smith
Currently the number of frames sent to the chip in a single USB Request Block is limited only by the size of the TX buffer, which is 20 KiB. Testing reveals that as many as 13 frames get aggregated. This is more than what any of the chips would like to receive. RTL8822CU, RTL8822BU, and RTL8821CU want at most 3 frames, and RTL8723DU wants only 1 frame per URB. RTL8723DU in particular reliably malfunctions during a speed test if it receives more than 1 frame per URB. All traffic seems to stop. Pinging the AP no longer works. Fix this problem by limiting the number of frames sent to the chip in a single URB according to what each chip likes. Also configure RTL8822CU, RTL8822BU, and RTL8821CU to expect 3 frames per URB. RTL8703B may or may not be found in USB devices. Declare that it wants only 1 frame per URB, just in case. Tested with RTL8723DU and RTL8811CU. Cc: stable@vger.kernel.org Signed-off-by: Bitterblue Smith <rtl8821cerfe2@gmail.com> Acked-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/cb46ea35-7e59-4742-9c1f-01ceeaad36fb@gmail.com
2024-01-10wifi: rtw88: 8822ce: refine power parameters for RFE type 5Ping-Ke Shih
Refine the power parameters for better step response especially at high current ramp case that is caused by power inductor variation. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://msgid.link/20240103070155.119488-1-pkshih@realtek.com
2023-10-19wifi: rtw88: dump firmware debug information in abnormal stateChin-Yen Lee
Sometimes firmware may enter strange state or infinite loop due to unknown bug, and then it will lead critical function fail, such as sending H2C command or changing power mode. In these abnormal states, we add more debug information, including hardware register status, to help further investigation. Signed-off-by: Chin-Yen Lee <timlee@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/20231016053554.744180-3-pkshih@realtek.com
2023-06-21wifi: rtw88: Stop high queue during scanPo-Hao Huang
When traversing channel list, TX in high queue should be disabled along with beacon function, so packets won't be sent to incorrect channels. 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/20230616125540.36877-5-pkshih@realtek.com
2023-06-21wifi: rtw88: Fix AP mode incorrect DTIM behaviorPo-Hao Huang
Broadcast and multicast packets in high queue should be transmitted all at once during DTIM. But without proper settings, hardware fails to recognize that there are multiple packets and fetches only one. Fix this by signaling hardware with more data bit set when there are packets in the high queue. 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/20230616125540.36877-3-pkshih@realtek.com
2023-04-12wifi: rtw88: sdio: Add HCI implementation for SDIO based chipsetsMartin Blumenstingl
Add a sub-driver for SDIO based chipsets which implements the following functionality: - register accessors for 8, 16 and 32 bits for all states of the card (including usage of 4x 8 bit access for one 32 bit buffer if the card is not fully powered on yet - or if it's fully powered on then 1x 32 bit access is used) - checking whether there's space in the TX FIFO queue to transmit data - transfers from the host to the device for actual network traffic, reserved pages (for firmware download) and H2C (host-to-card) transfers - receiving data from the device - deep power saving state The transmit path is optimized so DMA-capable SDIO host controllers can directly use the buffers provided because the buffer's physical addresses are 8 byte aligned. The receive path is prepared to support RX aggregation where the chipset combines multiple MAC frames into one bigger buffer to reduce SDIO transfer overhead. Co-developed-by: Jernej Skrabec <jernej.skrabec@gmail.com> Signed-off-by: Jernej Skrabec <jernej.skrabec@gmail.com> Reviewed-by: Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com> Reviewed-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20230405200729.632435-3-martin.blumenstingl@googlemail.com
2022-12-08wifi: rtw88: Add common USB chip supportSascha Hauer
Add the common bits and pieces to add USB support to the RTW88 driver. This is based on https://github.com/ulli-kroll/rtw88-usb.git which itself is first written by Neo Jou. Signed-off-by: neo_jou <neo_jou@realtek.com> Signed-off-by: Hans Ulli Kroll <linux@ulli-kroll.de> Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20221202081224.2779981-8-s.hauer@pengutronix.de
2022-04-12rtw88: Add update beacon flow for AP modePo-Hao Huang
To support stations in power saving mode, AP should notify stations that there are frames buffered at the AP via TIM during beacons. Driver used to transmit identical beacons that were downloaded to hardware during the initiation phase. This beacon will become obsolete over time. If the beacon does not contain sufficient information, station would not be able to percept that there is data to receive. Hence it won't wake up and start the PS-poll procedure, this could lead to timeout and/or lost data segments. In order to resolve this issue, driver will now download beacon to hardware whenever the content is updated. Enable hardware to update dtim_count for more efficiency, this reduces the overhead of downloading beacon at every beacon interval since most of the time only the dtim_count needs to be updated. Change queue mapping for broadcast/multicast frames to high queue, so these frames can be prioritized and sent when dtim_count is zero. 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/20220407095858.46807-4-pkshih@realtek.com
2021-10-05rtw88: fix RX clock gate setting while fifo dumpZong-Zhe Yang
When fw fifo dumps, RX clock gating should be disabled to avoid something unexpected. However, the register operation ran into a mistake. So, we fix it. 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@codeaurora.org> Link: https://lore.kernel.org/r/20210927111830.5354-1-pkshih@realtek.com
2021-09-21rtw88: move adaptivity mechanism to firmwareChin-Yen Lee
Current adaptivity mechanism is achieved in driver, by periodically referencing the IGI value and then updating related registers. But we find that this way may halt TX activity too long if huge and temporary energy is detected frequently. So we move the mechanism to firmware for immediately reacting this case to recover TX rapidly. Signed-off-by: Chin-Yen Lee <timlee@realtek.com> 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@codeaurora.org> Link: https://lore.kernel.org/r/20210830072014.12250-5-pkshih@realtek.com
2021-09-21rtw88: support adaptivity for ETSI/JP DFS regionZong-Zhe Yang
Add Energy Detected CCA (EDCCA) mechanism to detect energy on the channel. And EDCCA support adaptivity mode now. From MIC Ordinance Regulating Radio Equipment article 49.20, ETSI EN-300-328 and EN-301-893, the device should be able to dynamically pause TX activity when energy detected on the air. According to ETSI/JP DFS region, driver will set corresponding threshold and stop TX activity if the detected energy exceeds the threshold. For now, we support it on 8822b and 8822c first. By default, EDCCA mechanism is turned on. For ETSI/JP DFS region, it will turn to adaptivity mode. However, with adaptivity, if environment is too noisy, TX may often be halted. So, a debugfs for EDCCA is added. It can show what EDCCA mode is used currently. And EDCCA mechanism can be turned on/off through the debugfs while debugging. 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@codeaurora.org> Link: https://lore.kernel.org/r/20210830072014.12250-4-pkshih@realtek.com
2021-04-21rtw88: 8822c: Add gap-k calibration to improve long range performanceGuo-Feng Fan
gap-k is a calibration mechanism to eliminate power gaps between two nearly rate groups. This mechanism improves performance in long range test by applying proper power value to those rate groups which have nonlinear power gap. Signed-off-by: Guo-Feng Fan <vincent_fann@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20210419003748.3224-3-pkshih@realtek.com
2021-04-18rtw88: 8822c: add CFO trackingPo-Hao Huang
Add CFO tracking, which stands for central frequency offset tracking, to adjust oscillator to align central frequency of connected AP. Then, it can yield better performance. Signed-off-by: Po-Hao Huang <phhuang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20210416030901.7099-1-pkshih@realtek.com
2021-04-11rtw88: 8822c: add LC calibration for RTL8822CPo-Hao Huang
Fix power tracking issue by replacing unnecessary IQ calibration with LC calibration. When thermal difference exceeds limitation, let RF circuit adjsut its characteristic to fit in current environment. Signed-off-by: Po-Hao Huang <phhuang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20210319054218.3319-6-pkshih@realtek.com
2021-03-15rtw88: 8822c: support FW crash dump when FW crashZong-Zhe Yang
Although FW crash logs are already supported for dumping in driver, the logs may not be sufficient to analyze field issues. To improve this part, we add a support to dump FW memory. When driver receives FW crash notifications, driver uses DDMA, which is a HW ability, to copy specified FW memory to FW fifo. Driver can then dump these information from FW fifo. With this support, not only FW crash log but also specified FW memory will be dumped while FW crash. Besides, specified registers are also dumped. This feature is implemeted on 8822C first due to difference of FW layouts between ICs. In addition, we add a debugfs to trigger FW crash. It can simulate the process of crash, dump and reset. Through it, we can also check if a reset is ongoing. 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@codeaurora.org> Link: https://lore.kernel.org/r/20210309060121.9099-1-pkshih@realtek.com
2021-02-12rtw88: add dynamic rrsr configurationPo-Hao Huang
Register rrsr determines the response rate we send. In field tests, using rate higher than current tx rate could lead to difficulty for the receiving end to receive management/control frames. Calculate current modulation level by tx rate then cross out rate higher than those. Signed-off-by: Po-Hao Huang <phhuang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Reviewed-by: Brian Norris <briannorris@chromium.org> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20210209070755.23019-2-pkshih@realtek.com
2020-11-24rtw88: add CCK_PD debug logPing-Ke Shih
In order to help debugging in field, we add some log messages. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20201109090123.9254-2-pkshih@realtek.com
2020-11-10rtw88: coex: reduce magic numberChing-Te Ku
Use macro definition to replace magic number. Signed-off-by: Ching-Te Ku <ku920601@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20201109085909.9143-4-pkshih@realtek.com
2020-11-10rtw88: coex: fixed some wrong register definition and settingChing-Te Ku
Some register definition and bit definition were incorrect. e.g. REG_BT_COEX_V2 should be word alignment to meet the coding style. e.g. set REG_BT_TDMA_TIME[5:0]=0x5, But the original is to set REG_BT_TDMA_TIME[7:0]=0x5. This will cause unexpected hardware behavior. Signed-off-by: Ching-Te Ku <ku920601@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20201109085909.9143-2-pkshih@realtek.com
2020-09-29rtw88: add dump fw crash logTzu-En Huang
This patch adds a function which is able to dump firmware fifo when firmware crashes. If firmware needs more than one time to dump all logs, it will set a bit called "more bit" in the header of the first log, and driver needs to set a register to inform firmware that it is ready for the next dump. Signed-off-by: Tzu-En Huang <tehuang@realtek.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20200925061219.23754-5-tehuang@realtek.com
2020-09-29rtw88: handle and recover when firmware crashTzu-En Huang
This handles the situation when firmware crashes. When firmware crashes, it will send an interrupt, and driver will queue a work for recovery. In the work, driver will reset it's internal association state, which includes removing associated sta's macid, resetting vifs' states and removing keys. After resetting the driver's state, driver will call rtw_enter_ips() to force the chipset power off to reset the chip. Finally, driver calls ieee80211_restart_hw() to inform mac80211 stack to restart. Since only 8822c firmware supports this feature, the interrupt will only be triggered when 8822c chipset is loaded. Signed-off-by: Tzu-En Huang <tehuang@realtek.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20200925061219.23754-3-tehuang@realtek.com
2020-08-02rtw88: 8821c: coex: add functions and parametersPing-Cheng Chen
Without this patch, RTL8821CE will not have coex support, and will crash the system because of the NULL pointers for the coex functions. While RTL8822C series are WiFi + BT combo chips, it needs the co-existence mechanism for the device to work on both WiFi and BT without interfering each other. And the coex support has already been added before, most of the mechanisms are implemented. The driver should just add corresponding functions to operate on different types of chips and its coex parameters. Fixes: f745eb9ca5bf ("rtw88: 8821c: Add 8821CE to Kconfig and Makefile") Signed-off-by: Ping-Cheng Chen <pc.chen@realtek.com> Signed-off-by: Tzu-En Huang <tehuang@realtek.com> Signed-off-by: Yan-Hsuan Chuang <yhchuang@realtek.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20200724054208.31115-1-yhchuang@realtek.com
2020-07-15rtw88: 8821c: add basic functionsTzu-En Huang
RTL8821CE chipsets are 802.11ac dual-band WiFi + BT combo chips. This patch adds the basic functions such as parameter tables, chip information, power on flow. Reviewed-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de> Signed-off-by: Tzu-En Huang <tehuang@realtek.com> Signed-off-by: Yan-Hsuan Chuang <yhchuang@realtek.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20200616091625.26489-2-yhchuang@realtek.com
2020-05-13rtw88: 8723d: Add shutdown callback to disable BT USB suspendPing-Ke Shih
Without this patch, wifi card can't initialize properly due to BT in USB suspend state. So, we disable BT USB suspend (wakeup) in shutdown callback that is the moment before rebooting. To save BT USB power, we can't do this in 'remove' callback. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Yan-Hsuan Chuang <yhchuang@realtek.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20200512102621.5148-5-yhchuang@realtek.com
2020-05-13rtw88: 8723d: add IQ calibrationPing-Ke Shih
IQ calibration is used to calibrate RF characteristic to yield expected performance. Basically, we do calibration twice and compare the similarity to determine calibration is good or not, if not we do the third calibration, and then compare with the results of first and second calibration. If it still not similar, IQK is failed. Before doing calibration, we need to backup registers that will be modified in calibration procedure, and restore these registers after calibration is done. A calibration procedure can divided into four sub-procedures that are S1-TX, S1-RX, S0-TX and S0-RX. Where, S1 and S0 represent to path A and B respectively. Each sub-procedure configure proper registers, and then rigger one-shot calibration and poll until completion. For RX calibration, it needs to do twice one-shot calibration, first one is to yield parameter used by second one. The result of TX part is stored for TX power tracking that adjusts TX AGC to output expected power. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Yan-Hsuan Chuang <yhchuang@realtek.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20200512102621.5148-3-yhchuang@realtek.com
2020-04-23rtw88: 8723d: initialize mac/bb/rf basic functionsPing-Ke Shih
Implement rtw_chip_ops::phy_set_param and ::mac_init to initialize mac/bb/rf, and they are used during interface up. The procedure contains power on sequence registers, download firmware, load predefined parameters, mac/bb/rf specific register and etc. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Yan-Hsuan Chuang <yhchuang@realtek.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20200422034607.28747-9-yhchuang@realtek.com
2020-04-23rtw88: 8723d: Organize chip TX/RX FIFOPing-Ke Shih
TX FIFO size is 32k and it was divided into 256 pages with 128 bytes. A boundary is used to split pages into two parts, head part is used to store TX packets coming from host, and tail part is reserved for special purposes, such as beacon packet, null data packet and so on. The TX packets coming from host have many categories, such as VO, VI, BE, BK, MG and etc. When going into head part of TX FIFO, they are classified to four priority queue named low, normal, high and extra priority queues. Each priority queue occupies predefined number of page, if a certain priority queue is full, TX packet will store into PUB priority queue. Similarly, RX FIFO is 16k and split into two parts, head part is used to store RX packets, and tail part is 128 bytes and used to store report. Thus, we fill this boundary to register as well. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Yan-Hsuan Chuang <yhchuang@realtek.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20200422034607.28747-8-yhchuang@realtek.com
2020-04-23rtw88: 8723d: Add mac power-on/-off functionPing-Ke Shih
The mac power-on flow consists of three steps: 1. pre_sys_cfg (Before switching power state) 2. power_switch (Switching power state) 3. init_sys_cfg (Settings after swtiching power state) When switching power state, driver will load and parse the power sequence tables. For 8723D devices, the logics for parsing are most same except for the polling function. 8723D devices need to toggle BIT_PFM_WOWL twice. The settings after power state is switched for 8723D devices are quite different with other devices, extract a legacy function for them. For power-off flow, 8723D devices have the same logic with existing chips. But warning printed if we run power-off sequence in power-off state: rtw_pci 0000:03:00.0: failed to poll offset=0x5f8 mask=0xff value=0x0 The scenario is user do 'ifconfig up' that will run power-on sequence to bring up and then run power-off sequence to enter idle (IEEE80211_CONF_IDLE). Then, user do 'ifconfig down' that will run power-off sequence again, and the warning is shown. Original code check power-on state to avoid to run power-on sequence twice, and this commit extends to check both power-on and power-off states. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Yan-Hsuan Chuang <yhchuang@realtek.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20200422034607.28747-4-yhchuang@realtek.com
2020-04-23rtw88: add legacy firmware download for 8723D devicesPing-Ke Shih
The WLAN CPU of 8723D device is different from others, add legacy firmware download function for it. A new variable wlan_cpu is used to decide which firmware download function we should use. Legacy firmware file contains 32 bytes header including version and subversion. When downloading to wlan cpu, header is excluded. Firmware is downloaded via beacon queue to reserved page that is a part of TX buffer. Since 11N WLAN CPU uses different control registers, this patch introduces related control registers. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Yan-Hsuan Chuang <yhchuang@realtek.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20200422034607.28747-2-yhchuang@realtek.com
2020-04-21rtw88: 8723d: Add new chip op efuse_grant() to control efuse accessPing-Ke Shih
8723D devices need to grant efuse access before dumping physical efuse map, other chips don't need it, so keep this ops as blank. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Yan-Hsuan Chuang <yhchuang@realtek.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20200420055054.14592-8-yhchuang@realtek.com
2020-04-21rtw88: 8723d: Add cfg_ldo25 to control LDO25Ping-Ke Shih
Implement rtw_chip_ops::cfg_ldo25 to enable/disable LDO25 with proper voltage. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Yan-Hsuan Chuang <yhchuang@realtek.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20200420055054.14592-7-yhchuang@realtek.com
2020-01-26rtw88: Add wowlan pattern match supportChin-Yen Lee
Pattern match is an option of wowlan to allow the device to be woken up from suspend mode when receiving packets matched user-designed patterns. The patterns are written into hardware cam in suspend flow if users have set up them. If packets matched designed pattern are received, wowlan firmware will get an interrupt and then wake up the device. Signed-off-by: Chin-Yen Lee <timlee@realtek.com> Signed-off-by: Yan-Hsuan Chuang <yhchuang@realtek.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2020-01-26rtw88: support wowlan feature for 8822cChin-Yen Lee
Wake on WLAN(wowlan) is a feature which allows devices to be woken up from suspend state through wlan events. When user enables wowlan feature and then let the device enter suspend state, wowlan firmware will be loaded by the driver and periodically monitors wifi packets. Power consumption of wifi chip will be reduced in this state. If wowlan firmware detects that specific wlan event happens, it will issue wakeup signal to trigger resume process. Driver will load normal firmware and let wifi chip return to the original state. Currently supported wlan events include receiving magic packet, rekey packet and deauth packet, and disconnecting from AP. Signed-off-by: Chin-Yen Lee <timlee@realtek.com> Signed-off-by: Yan-Hsuan Chuang <yhchuang@realtek.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2020-01-26rtw88: add interface config for 8822cYan-Hsuan Chuang
Some devices need to configure interface/HCI related reigsters in power on flow. Add interface_cfg for HCI for the settings. The driver only supports RTL8822BE/RTL8822CE now, and since RTL8822BE does not need to configure PCIE, the configuration is only added for RTL8822CE. Without it, some of the RTL8822CE device can crash and disconnected to host in suspend/wowlan mode. Signed-off-by: Tzu-En Huang <tehuang@realtek.com> Signed-off-by: Yan-Hsuan Chuang <yhchuang@realtek.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2019-10-24rtw88: Enable 802.11ac beamformee supportTzu-En Huang
Enable MU-MIMO transmit beamformee support for chipset 8822b and 8822c. If the driver is in station mode and associated with an AP, and the capabilities of both meet the requirement of beamforming, driver will run as a beamformee and the corresponding chip settings will be set. In addition, module parameter support_bf is added to enable or disable beamforming. Sometimes driver will need to disable for inter-operate issues, and it would be easier for driver to debug. Signed-off-by: Tzu-En Huang <tehuang@realtek.com> Signed-off-by: Yan-Hsuan Chuang <yhchuang@realtek.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2019-10-14rtw88: config 8822c multicast address in MAC init flowTzu-En Huang
Multicast address should be congiured in the initialization flow. The value is created by a hashed calculation that is also implemented by the hardware for multicast address filtering. Signed-off-by: Tzu-En Huang <tehuang@realtek.com> Signed-off-by: Yan-Hsuan Chuang <yhchuang@realtek.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2019-10-04rtw88: configure TX queue EDCA parametersYan-Hsuan Chuang
Set CWmax/CWmin, TXOP and AIFS according to ieee80211_tx_queue_params. Do note that hardware has only one group of EDCA[ac] registers, if more than one vif are added, the EDCA[ac] registers will contain value of params of the most recent set by ieee80211_ops::conf_tx(). And AIFS = AIFSN[ac] * slot_time + SIFS, so if use_short_slot is changed, need to also change AIFS. Signed-off-by: Yan-Hsuan Chuang <yhchuang@realtek.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2019-10-04rtw88: check firmware leave lps successfullyChin-Yen Lee
Driver needs to wait for firmware to restore hardware setting to active mode after leaving lps. After getting H2C from driver for leaving lps, firmware will issue null packet without PS bit to inform AP driver is active, and then restore REG_TCR Register if AP has receiced null packet. But the transmission of null packet may cost much more time in noisy environment. If driver does not wait for firmware, null packet with PS bit could be sent due to incorrect REG_TCR setting. And AP will be confused. In our test, 100ms is enough for firmware to send null packet to AP. If REG_TCR Register is still wrong after 100ms, we will modify it directly, force the PS bit to be cleared Signed-off-by: Chin-Yen Lee <timlee@realtek.com> Signed-off-by: Yan-Hsuan Chuang <yhchuang@realtek.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2019-09-13rtw88: 8822c: add SW DPK supportTzu-En Huang
Power amplifiers are not linear components, and require DPK to reduce its nonlinearity. DPK is called Digital Pre-distortion Calibration, can be used to compensate the output of power. DPK tracking is in charge of tracking the thermal changes. And it then shifts the power curve accordingly, which makes the power output remains linear even if the PA works in different temperature. To perform DPK, the parameter table should also be updated. And the table will be applied when device is powered on. Then DPK will reference the values to calibrate. Signed-off-by: Tzu-En Huang <tehuang@realtek.com> Signed-off-by: Yan-Hsuan Chuang <yhchuang@realtek.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2019-09-13rtw88: 8822c: Enable interrupt migrationTsang-Shian Lin
Enable 8822C Tx/Rx interrupt migration. In some platforms, performance test may cause heavy cpu loading and get bad results. Interrupt migration can decrease the amount of interrupts, and lower cpu loading. Signed-off-by: Tsang-Shian Lin <thlin@realtek.com> Signed-off-by: Yan-Hsuan Chuang <yhchuang@realtek.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2019-08-06rtw88: add BT co-existence supportYan-Hsuan Chuang
Both RTL8822BE/RTL8822CE are WiFi + BT combo chips. Since WiFi and BT use 2.4GHz to transmit, it is important to make sure they run concurrently without interfering each other. To achieve this, WiFi driver requires a mechanism to collaborate with BT, whether they share the antenna(s) or not. The final decision made by the co-existence mechanism is to choose a proper strategy, or called "tdma/table", and inform either firmware or hardware of the strategy. To choose a strategy, co-existence mechanism needs to have enough information from WiFi and BT. BT information is provided through firmware C2H. The contents describe the current status of BT, such as if BT is connected or is idle, or the profile that is being used. WiFi information can be provided by WiFi itself. The WiFi driver will call various of "notify" functions each time the state of WiFi changed, such as WiFi is going to switch channel or is connected. Also WiFi driver can know if it shares antenna with BT by reading efuse content. Antenna configuration of the module will finally get a different strategy. Upon receiving any information from WiFi or BT, the WiFi driver will run the co-existence mechanism immediately. It will set the RF antenna configuration according to the strategy through the TDMA H2C to firmware and a hardware table. Based on the tdma/table, WiFi + BT should work with each other, and having a better user experience. Signed-off-by: Yan-Hsuan Chuang <yhchuang@realtek.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2019-04-30rtw88: new Realtek 802.11ac driverYan-Hsuan Chuang
This is a new mac80211 driver for Realtek 802.11ac wireless network chips. rtw88 now supports RTL8822BE/RTL8822CE now, with basic station mode functionalities. The firmware for both can be found at linux-firmware. https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git For RTL8822BE: rtw88/rtw8822b_fw.bin For RTL8822CE: rtw88/rtw8822c_fw.bin And for now, only PCI buses (RTL8xxxE) are supported. We will add support for USB and SDIO in the future. The bus interface abstraction can be seen in this driver such as hci.h. Most of the hardware setting are the same except for some TRX path or probing setup should be separated. Supported: * Basic STA/AP/ADHOC mode, and TDLS (STA is well tested) Missing feature: * WOW/PNO * USB & SDIO bus (such as RTL8xxxU/RTL8xxxS) * BT coexistence (8822B/8822C are combo ICs) * Multiple interfaces (for now single STA is better supported) * Dynamic hardware calibrations (to improve/stabilize performance) Potential problems: * static calibration spends too much time, and it is painful for driver to leave IDLE state. And slows down associate process. But reload function are under development, will be added soon! * TRX statictics misleading, as we are not reporting status correctly, or say, not reporting for "every" packet. The next patch set should have BT coexistence code since RTL8822B/C are combo ICs, and the driver for BT can be found after Linux Kernel v4.20. So it is better to add it first to make WiFi + BT work concurrently. Although now rtw88 is simple but we are developing more features for it. Even we want to add support for more chips such as RTL8821C/RTL8814B. Finally, rtw88 has many authors, listed alphabetically: Ping-Ke Shih <pkshih@realtek.com> Tzu-En Huang <tehuang@realtek.com> Yan-Hsuan Chuang <yhchuang@realtek.com> Reviewed-by: Stanislaw Gruszka <sgruszka@redhat.com> Reviewed-by: Brian Norris <briannorris@chromium.org> Tested-by: Brian Norris <briannorris@chromium.org> Signed-off-by: Yan-Hsuan Chuang <yhchuang@realtek.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
generated by cgit (git 2.34.1) at 2025-07-31 01:46:14 +0000