The LPS threshold was set to 2, means driver will leave LPS
mode if there is more than 2 frames TX/RX for every 2 seconds.
This makes driver enter/leave LPS frequently even if we just
"ping -i1" to the others.
Apparently we do not want to leave LPS mode if there is only
some background traffics or web surfing. By experiment, set
this to 50 is a more reasonable value to lower the over all
power consumption.
Signed-off-by: Yan-Hsuan Chuang <yhchuang@realtek.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
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>
Compare with LCLK mode, PG mode saves more power, by turning
off more circuits. Therefore, to recover from PG mode, driver
needs to backup some information into rsvd page. Such as CAM
entries, DPK results.
As CAM entries can change, it is required to re-download CAM
entries after set_key.
Signed-off-by: Yan-Hsuan Chuang <yhchuang@realtek.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Deep power save allows firmware/hardware to operate in a
lower power state. And the deep power save mode depends on
LPS mode. So, before entering deep PS, driver must first
enter LPS mode.
Under Deep PS, most of hardware functions are shutdown,
driver will not be able to read/write registers and transfer
data to the device. Hence TX path must be protected by each
interface. Take PCI for example, DMA engine should be idle,
and no nore activities on the PCI bus.
If driver wants to operate on the device, such as register
read/write, it must first acquire the mutex lock and wake
up from Deep PS, otherwise the behavior is undefined.
Signed-off-by: Yan-Hsuan Chuang <yhchuang@realtek.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
The original design of LPS enter/leave routines allows
to control the LPS state by each interface. But the
hardware cannot actually handle it that way. This means
the hardware can only enter LPS once with an associated
port, so there is no need to keep tracking the state of
each vif.
Hence the logic of enter/leave LPS state can be simple,
just to check the state of the device's flag. And for
leaving LPS state, it will get the same port id to send
to inform the hardware.
Signed-off-by: Yan-Hsuan Chuang <yhchuang@realtek.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Remove PS related *_irqsafe functions to avoid entering/leaving PS
under interrupt context. Instead, make PS decision in watch_dog.
This could simplify the logic and make the code look clean.
But it could have a little side-effect that if the driver is having
heavy traffic before the every-2-second watch_dog detect the traffic
and decide to leave PS, the thoughput will be lower. Once traffic is
detected by watch_dog and left PS state, the throughput will resume
to the peak the hardware ought to have again.
Signed-off-by: Yan-Hsuan Chuang <yhchuang@realtek.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
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>
Yan-Hsuan Chuang