| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
Many Intel based platforms face system random freeze after commit
9e2fd29864c5 ("rtw88: add napi support").
The commit itself shouldn't be the culprit. My guess is that the 8821CE
only leaves ASPM L1 for a short period when IRQ is raised. Since IRQ is
masked during NAPI polling, the PCIe link stays at L1 and makes RX DMA
extremely slow. Eventually the RX ring becomes messed up:
[ 1133.194697] rtw_8821ce 0000:02:00.0: pci bus timeout, check dma status
Since the 8821CE hardware may fail to leave ASPM L1, manually do it in
the driver to resolve the issue.
Fixes: 9e2fd29864c5 ("rtw88: add napi support")
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=215131
BugLink: https://bugs.launchpad.net/bugs/1927808
Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com>
Acked-by: Jian-Hong Pan <jhp@endlessos.org>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20211215114635.333767-1-kai.heng.feng@canonical.com
|
|
We find the power sequence of system suspend flow don't meet
the criteria when using 8822CE-VR chip by rfe-type 6, because the
reference clock form host is sometimes late. To avoid the behavoir,
we keep CLKREQ# signal to low during suspend to make sure the reference
clock arrival in time.
Signed-off-by: Chin-Yen Lee <timlee@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/20210727100503.31626-1-pkshih@realtek.com
|
|
We used to stop napi before disabling irqs. And it turns out
to cause some problem when we try to stop device while interrupt arrives.
To safely stop pci, we do three steps:
1. disable interrupt
2. synchronize_irq
3. stop_napi
Since step 2 and 3 may not finish as expected when interrupt is enabled,
use rtwpci->running to decide whether interrupt should be re-enabled at
the time.
Fixes: 9e2fd29864c5 ("rtw88: add napi support")
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/20210415084703.27255-4-pkshih@realtek.com
|
|
Use napi to reduce overhead on rx interrupts.
Driver used to interrupt kernel for every Rx packet, this could
affect both system and network performance. NAPI is a mechanism that
uses polling when processing huge amount of traffic, by doing this
the number of interrupts can be decreased.
Network performance can also benefit from this patch. Since TCP
connection is bidirectional and acks are required for every several
packets. These ack packets occupie the PCI bus bandwidth and could
lead to performance degradation.
When napi is used, GRO receive is enabled by default in the mac80211
stack. So mac80211 won't pass every RX TCP packets to the kernel TCP
network stack immediately. Instead an aggregated large length TCP packet
will be delivered.
This reduces the tx acks sent and gains rx performance. After the patch,
the Rx throughput increases about 25Mbps in 11ac.
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>
Tested-by: Brian Norris <briannorris@chromium.org>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20210209070755.23019-4-pkshih@realtek.com
|
|
'const struct dev_pm_ops rtw_pm_ops' is declared by pci.c, and it should be
declare as 'extern' in pci.h. Without 'extern' causes every file including
pci.h has an individual instance of rtw_pm_ops but not reference to the one
declared in pci.c
If kernel config, like test robot, doesn't build driver as module, it leads
multiple definition.
Reported-by: kernel test robot <lkp@intel.com>
Fixes: 2e86ef413ab3 ("rtw88: pci: Add prototypes for .probe, .remove and .shutdown")
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20201208013746.11065-1-pkshih@realtek.com
|
|
Also strip out other duplicates from driver specific headers.
Ensure 'main.h' is explicitly included in 'pci.h' since the latter
uses some defines from the former. It avoids issues like:
from drivers/net/wireless/realtek/rtw88/rtw8822be.c:5:
drivers/net/wireless/realtek/rtw88/pci.h:209:28: error: ‘RTK_MAX_TX_QUEUE_NUM’ undeclared here (not in a function); did you mean ‘RTK_MAX_RX_DESC_NUM’?
209 | DECLARE_BITMAP(tx_queued, RTK_MAX_TX_QUEUE_NUM);
| ^~~~~~~~~~~~~~~~~~~~
Fixes the following W=1 kernel build warning(s):
drivers/net/wireless/realtek/rtw88/pci.c:1488:5: warning: no previous prototype for ‘rtw_pci_probe’ [-Wmissing-prototypes]
1488 | int rtw_pci_probe(struct pci_dev *pdev,
| ^~~~~~~~~~~~~
drivers/net/wireless/realtek/rtw88/pci.c:1568:6: warning: no previous prototype for ‘rtw_pci_remove’ [-Wmissing-prototypes]
1568 | void rtw_pci_remove(struct pci_dev *pdev)
| ^~~~~~~~~~~~~~
drivers/net/wireless/realtek/rtw88/pci.c:1590:6: warning: no previous prototype for ‘rtw_pci_shutdown’ [-Wmissing-prototypes]
1590 | void rtw_pci_shutdown(struct pci_dev *pdev)
| ^~~~~~~~~~~~~~~~
Cc: Yan-Hsuan Chuang <yhchuang@realtek.com>
Cc: Kalle Valo <kvalo@codeaurora.org>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: Jakub Kicinski <kuba@kernel.org>
Cc: linux-wireless@vger.kernel.org
Cc: netdev@vger.kernel.org
Signed-off-by: Lee Jones <lee.jones@linaro.org>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20201126133152.3211309-18-lee.jones@linaro.org
|
|
The vht capability of MAX_MPDU_LENGTH is 11454 in rtw88; however, the rx
buffer size for each packet is 8192. When receiving packets that are
larger than rx buffer size, it will leads to rx buffer ring overflow.
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-2-tehuang@realtek.com
|
|
remove the unused about pci after extracting chip modules
Signed-off-by: Zong-Zhe Yang <kevin_yang@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/20200515052327.31874-7-yhchuang@realtek.com
|
|
Driver used to kick off every TX packets, that will waste some
time while we can do better to kick off the TX packets once after
they are all prepared to be transmitted.
For PCI, it uses DMA engine to transfer the SKBs to the device,
and the transition of the state of the DMA engine could be a cost.
Driver can save some time to kick off multiple SKBs once so that
the DMA engine will have only one transition.
So, split rtw_hci_ops::tx() to rtw_hci_ops::tx_write() and
rtw_hci_ops::tx_kick_off() to explicitly kick the SKBs off after
they are written to the prepared buffer. For packets come from
ieee80211_ops::tx(), write one and then kick it off immediately.
For packets queued in TX queue, which come from
ieee80211_ops::wake_tx_queue(), we can dequeue them, write them
to the buffer, and then kick them off together.
Signed-off-by: Yan-Hsuan Chuang <yhchuang@realtek.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20200312080852.16684-6-yhchuang@realtek.com
|
|
Add a macro TRX_BD_IDX_MASK for access the TX/RX BD indexes.
The hardware has only 12 bits for TX/RX BD indexes, we should not
initialize a TX/RX ring or access the TX/RX BD index with a length
that is larger than TRX_BD_IDX_MASK.
Signed-off-by: Yan-Hsuan Chuang <yhchuang@realtek.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20200312080852.16684-5-yhchuang@realtek.com
|
|
This driver generally only needs to ensure that
(a) it doesn't try to process TX interrupts at the same time as
power-save operations (and similar)
(b) the device interrupt gets disabled while we're still handling the
last set of interrupts
For (a), all the operations (e.g., PS transitions, packet handling)
happens in non-atomic contexts (e.g., threaded IRQ).
For (b), we only need mutual exclusion for brief sections (i.e., while
we're actually manipulating the interrupt mask/status).
So, we can introduce a separate lock for handling (b), disabling IRQs
while we do it. For (a), we can demote the locking to BH only, now that
(b) (the only steps done in atomic context) and that has its own lock.
This helps reduce the amount of time this driver spends with IRQs off.
Notably, transitioning out of power-save modes can take >3 milliseconds,
and this transition is done under the protection of 'irq_lock'.
Signed-off-by: Brian Norris <briannorris@chromium.org>
Signed-off-by: Yan-Hsuan Chuang <yhchuang@realtek.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20200312080852.16684-2-yhchuang@realtek.com
|
|
Since RTL8822CE has enabled reference clock auto calibration,
there is no need to add any clock delay for covering the timing
gap of the reference clock.
Signed-off-by: Yan-Hsuan Chuang <yhchuang@realtek.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
|
|
It's more reasonable to define max_num_of_tx_queue() as an inline function.
Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com>
Signed-off-by: Yan-Hsuan Chuang <yhchuang@realtek.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
|
|
Different interfaces have its own link-related power save mechanism.
Such as PCI can enter L1 state based on the traffic on the link, and
sometimes driver needs to enable/disable it to avoid some issues, like
throughput degrade when PCI trying to enter L1 state even if driver is
having heavy traffic.
For now, rtw88 only supports PCIE chips, and they just need to disable
ASPM L1 when driver is not in power save mode, such as IPS and LPS.
Signed-off-by: Yan-Hsuan Chuang <yhchuang@realtek.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
|
|
By Realtek's design, there are two HW modules associated for CLKREQ,
one is responsible to follow the PCIE host settings, and another
is to actually working on it. But the module that is actually working
on it is default disabled, and driver should enable that module if
host and device have successfully sync'ed with each other.
The module is default disabled because sometimes the host does not
support it, and if there is any incorrect settings (ex. CLKREQ# is
not Bi-Direction), device can be lost and disconnected to the host.
So driver should first check after host and device are sync'ed, and
the host does support the function and set it in configuration
space, then driver can turn on the HW module to working on it.
Signed-off-by: Yan-Hsuan Chuang <yhchuang@realtek.com>
Reviewed-by: Chris Chiu <chiu@endlessm.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
|
|
Add some register and bit macros to access DBI/MDIO register. This
should not change the logic.
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>
|
