- 28 Apr, 2020 9 commits
-
-
Wen Gong authored
For SDIO chip, its rx indication is struct htt_rx_indication_hl, which does not include the bitrate info as well as PCIe, for PCIe, it use function ath10k_htt_rx_h_rates to parse the bitrate info in struct rx_ppdu_start and then report it to mac80211 via ieee80211_rx_status. SDIO does not have the same info as PCIe, then iw command can not get the rx bitrate by "iw wlan0 station dump". for example, it always show 6.0 MBit/s localhost ~ # iw wlan0 link Connected to 3c:28:6d:96:fd:69 (on wlan0) SSID: kukui_test freq: 5180 RX: 111800 bytes (595 packets) TX: 35419 bytes (202 packets) signal: -41 dBm rx bitrate: 6.0 MBit/s This patch is to send WMI_TLV_REQUEST_PEER_STATS_INFO_CMDID to firmware for ath10k_sta_statistics and save the rx bitrate for WMI event WMI_TLV_PEER_STATS_INFO_EVENTID. This patch only effect SDIO chip, ath10k_mac_sta_get_peer_stats_info has check for bitrate_statistics of hw_params, this patch only enable it for "qca6174 hw3.2 sdio". Tested with QCA6174 SDIO firmware WLAN.RMH.4.4.1-00042. Signed-off-by:
Wen Gong <wgong@codeaurora.org> Signed-off-by:
Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20200427080416.8265-3-wgong@codeaurora.org
-
Wen Gong authored
For wmi tlv type, firmware disable peer stats info by default, after enable it, firmware will report WMI_TLV_PEER_STATS_INFO_EVENTID if ath10k send WMI_TLV_REQUEST_PEER_STATS_INFO_CMDID to firmware. Enable it will only set a flag in firmware, firmware will not report it without receive request WMI command. Tested with QCA6174 SDIO with firmware WLAN.RMH.4.4.1-00042. Signed-off-by:
-
Jason Yan authored
The '>' expression itself is bool, no need to convert it to bool again. This fixes the following coccicheck warning: drivers/net/wireless/ath/ath5k/ani.c:504:56-61: WARNING: conversion to bool not needed here Signed-off-by:
Jason Yan <yanaijie@huawei.com> Signed-off-by:
-
Sergey Ryazanov authored
ADC & I/Q calibrations could take infinite time to comple, since they depend on received frames. In particular the I/Q mismatch calibration requires receiving of OFDM frames for completion. But in the 2.4GHz band, a station could receive only CCK frames for a very long time. And while we wait for the completion of one of the mentioned calibrations, the NF calibration is blocked. Moreover, in some environments, I/Q calibration is unable to complete until a correct noise calibration will be performed due to AGC behaviour. In order to avoid delaying NF calibration on forever, limit the maximum duration of ADCs & I/Q calibrations. If the calibration is not completed within the maximum time, it will be interrupted and a next calibration will be performed. The code that selects the next calibration has been reworked to the loop so incompleted calibration will be respinned later. Ð maximum calibration time of 30 seconds was selected to give the calibration enough time to complete and to not interfere with the long (NF) calibration. Run tested with AR9220. Signed-off-by:
Sergey Ryazanov <ryazanov.s.a@gmail.com> Signed-off-by:
-
Sergey Ryazanov authored
Previously after the calibration validity period is over, calibrations are invalidated in a one at time manner. So, for AR9002 family, which has three calibrations, the full recalibration interval becomes 3 x ATH_RESTART_CALINTERVAL. And each next calibration will be separated by the ATH_RESTART_CALINTERVAL time from a previous one. It seems like it is better to do whole recalibration at once. Also, this change makes the driver behaviour a little simpler. So, invalidate all calibrations at once at the end of the calibration validity interval. This change affects only AR9002 chips family, since the AR9003 utilize only a single calibration. Signed-off-by:
-
Sergey Ryazanov authored
NF calibration and other elements of long calibration are usually faster than ADCs & I/Q calibrations due to independence of receiption of the OFDM signal. Moreover sometime I/Q calibration can not be completed at all without preceding NF calibration. This is due to AGC, which has a habit to block a weak signal without regular NF calibration. Thus, we do not need to deferr the long calibration forever. So, if the long calibration is requested, then deferr the ADCs & I/Q calibration(s) and run the longcal (the NF calibration in particular) to obtain fresh noise data. Run tested with AR9220. Signed-off-by:
-
Sergey Ryazanov authored
Each of AGC & I/Q calibrations can take a long time. Long calibration and NF calibration in particular are forbiden for parallel run with ADC & I/Q calibrations. So, the chip could not be ready to perform the long calibration at the time of request. And a request to perform the long calibration may be lost. In order to fix this, preserve the long calibration request as a calibration state flag and restore the long calibration request each time the calibration function is called again (i.e. on each subsequent ivocation of the short calibration). This feature will be twice useful after the next change, which will make it possible to start the long calibration before all ADCs & I/Q calibrations are completed. Run tested with AR9220. Signed-off-by:
-
Sergey Ryazanov authored
The NFCAL_PENDING flag is set by the ath9k_hw_start_nfcal() routine, so there is no reason to set it manually after calling it during the AR9002 calibrations initialization. Signed-off-by:
-
Sergey Ryazanov authored
ADC calibration is only required for a 80 MHz sampling rate (i.e. for 40 MHz channels), when the chip utilizes the pair of ADCs in interleved mode. Calibration on a 20 MHz channel will never be completed. Previous channel check is trying to exclude all channels where the calibration will get stuck. It effectively blocks the calibration run for HT20 channels, but fails to exclude 20 MHz channels without HT (e.g. legacy mode channels). Fix this issue by reworking the channel check to explicitly allow ADCs gain & DC offset calibrations for HT40 channels only. Also update the complicated comment to make it clear that these calibrations are for multi-ADC mode only. Stuck ADCs calibration blocks the NF calibration, what could make it impossible to work in a noisy evironment: too big Rx attentuation, invalid RSSI value, etc. So this change is actually more of a NF calibration fix rather then the ADC calibration fix. Run tested with AR9220. Signed-off-by:
-
- 27 Apr, 2020 3 commits
-
-
Wen Gong authored
When tx complete is disabled, all tx status will be set with status HTT_TX_COMPL_STATE_ACK and indicate to mac80211 by ieee80211_tx_status, then it does not have the statistics for retries and failed packets. count of tx retries and tx failed of command "iw wlan0 station dump" are both 0. If tx complete is not disabled, then firmware report the tx status and ath10k indicate the status to mac80211, then mac80211 save the statistics and command "iw wlan0 station dump" show them. for example: localhost ~ # iw dev wlan0 station dump Station 3c:28:6d:96:fd:69 (on wlan0) inactive time: 5 ms rx bytes: 1325012 rx packets: 6477 tx bytes: 85264 tx packets: 518 tx retries: 0 tx failed: 0 This patch only effect chips with tx complete disabled, e.g. SDIO. with this patch, output of command "iw dev wlan0 station dump": Station c4:04:15:5d:97:22 (on wlan0) inactive time: 608 ms rx bytes: 180366 rx packets: 991 tx bytes: 98765577 tx packets: 64624 tx retries: 14682 tx failed: 47086 Tested with QCA6174 SDIO with firmware WLAN.RMH.4.4.1-00042. Signed-off-by: -
Wen Gong authored
When run command "iw dev wlan0 station dump", the rx duration is 0. When firmware indicate WMI_UPDATE_STATS_EVENTID, extended flag of statsis not set by default, so firmware do not report rx duration. one sample: localhost # iw wlan0 station dump Station c4:04:15:5d:97:22 (on wlan0) inactive time: 48 ms rx bytes: 21670 rx packets: 147 tx bytes: 11529 tx packets: 100 tx retries: 88 tx failed: 36 beacon loss: 1 beacon rx: 31 rx drop misc: 47 signal: -72 [-74, -75] dBm signal avg: -71 [-74, -75] dBm beacon signal avg: -71 dBm tx bitrate: 54.0 MBit/s MCS 3 40MHz rx bitrate: 1.0 MBit/s rx duration: 0 us This patch enable firmware's extened flag of stats by setting flag WMI_TLV_STAT_PEER_EXTD of ar->fw_stats_req_mask which is set in ath10k_core_init_firmware_features via WMI_REQUEST_STATS_CMDID. After apply this patch, rx duration show value with the command: Station c4:04:15:5d:97:22 (on wlan0) inactive time: 883 ms rx bytes: 44289 rx packets: 265 tx bytes: 10838 tx packets: 93 tx retries: 899 tx failed: 103 beacon loss: 0 beacon rx: 78 rx drop misc: 46 signal: -71 [-74, -76] dBm signal avg: -70 [-74, -76] dBm beacon signal avg: -70 dBm tx bitrate: 54.0 MBit/s MCS 3 40MHz rx bitrate: 1.0 MBit/s rx duration: 358004 us This patch do not have side effect for all chips, because function ath10k_debug_fw_stats_request is already exported to debugfs "fw_stats" and WMI_REQUEST_STATS_CMDID is safely sent after condition checked by ath10k_peer_stats_enabled in ath10k_sta_statistics. Tested with QCA6174 SDIO with firmware WLAN.RMH.4.4.1-00042. Signed-off-by: -
Karthikeyan Periyasamy authored
we are sending the reo flush command for the deleted peer tid after the ageout period reaches 1 second. This handling causes reo ring get full when more than 128 clients are disconnected continuously. so added the count for flush list and reo flush command is triggered after the list count reaches the threshold value, it is configured as 64 (half of the reo ring). This will avoid the situation where reo ring get full. Signed-off-by:
Karthikeyan Periyasamy <periyasa@codeaurora.org> Signed-off-by:
-
- 23 Apr, 2020 2 commits
-
-
Wen Gong authored
sdio chip use DMA buffer to receive TX packet from ath10k, and it has limitation of each buffer, if the packet size exceed the credit size, it will trigger error in firmware. Tested with QCA6174 SDIO with firmware WLAN.RMH.4.4.1-00017-QCARMSWP-1. Signed-off-by:
-
Maharaja Kennadyrajan authored
The driver is allowing the invalid tx/rx chainmask configuration (other than 1,3,7,15) set by the user. It causes the firmware crash due to the invalid chainmask values. Hence, reject the invalid chainmask values in the driver by not sending the pdev set command to the firmware. Tested hardware: QCA9888 Tested firmware: 10.4-3.10-00047 Signed-off-by:
Maharaja Kennadyrajan <mkenna@codeaurora.org> Signed-off-by:
-
- 22 Apr, 2020 5 commits
-
-
Wen Gong authored
When station connected to AP, and run TX traffic such as TCP/UDP, and system enter suspend state, then mac80211 call ath10k_flush with set drop flag, recently it only send wmi peer flush to firmware and firmware will flush all pending TX packets, for PCIe, firmware will indicate the TX packets status to ath10k, and then ath10k indicate to mac80211 TX complete with the status, then all the packets has been flushed at this moment. For SDIO chip, it is different, its TX complete indication is disabled by default, and it has a tx queue in ath10k, and its tx credit control is enabled, total tx credit is 96, when its credit is not sufficient, then the packets will buffered in the tx queue of ath10k, max packets is TARGET_TLV_NUM_MSDU_DESC_HL which is 1024, for SDIO, when mac80211 call ath10k_flush with set drop flag, maybe it have pending packets in tx queue of ath10k, and if it does not have sufficient tx credit, the packets will stay in queue untill tx credit report from firmware, if it is a noisy environment, tx speed is low and the tx credit report from firmware will delay more time, then the num_pending_tx will remain > 0 untill all packets send to firmware. After the 1st ath10k_flush, mac80211 will call the 2nd ath10k_flush without set drop flag immediately, then it will call to ath10k_mac_wait_tx_complete, and it wait untill num_pending_tx become to 0, in noisy environment, it is esay to wait about near 5 seconds, then it cause the suspend take long time. 1st and 2nd callstack of ath10k_flush [ 303.740427] ath10k_sdio mmc1:0001:1: ath10k_flush drop:1, pending:0-0 [ 303.740495] ------------[ cut here ]------------ [ 303.740739] WARNING: CPU: 1 PID: 3921 at /mnt/host/source/src/third_party/kernel/v4.19/drivers/net/wireless/ath/ath10k/mac.c:7025 ath10k_flush+0x54/0x104 [ath10k_core] [ 303.740757] Modules linked in: bridge stp llc ath10k_sdio ath10k_core rfcomm uinput cros_ec_rpmsg mtk_seninf mtk_cam_isp mtk_vcodec_enc mtk_fd mtk_vcodec_dec mtk_vcodec_common mtk_dip mtk_mdp3 videobuf2_dma_contig videobuf2_memops v4l2_mem2mem videobuf2_v4l2 videobuf2_common hid_google_hammer hci_uart btqca bluetooth dw9768 ov8856 ecdh_generic ov02a10 v4l2_fwnode mtk_scp mtk_rpmsg rpmsg_core mtk_scp_ipi ipt_MASQUERADE fuse iio_trig_sysfs cros_ec_sensors_ring cros_ec_sensors_sync cros_ec_light_prox cros_ec_sensors industrialio_triggered_buffer [ 303.740914] kfifo_buf cros_ec_activity cros_ec_sensors_core lzo_rle lzo_compress ath mac80211 zram cfg80211 joydev [last unloaded: ath10k_core] [ 303.741009] CPU: 1 PID: 3921 Comm: kworker/u16:10 Tainted: G W 4.19.95 #2 [ 303.741027] Hardware name: MediaTek krane sku176 board (DT) [ 303.741061] Workqueue: events_unbound async_run_entry_fn [ 303.741086] pstate: 60000005 (nZCv daif -PAN -UAO) [ 303.741166] pc : ath10k_flush+0x54/0x104 [ath10k_core] [ 303.741244] lr : ath10k_flush+0x54/0x104 [ath10k_core] [ 303.741260] sp : ffffffdf080e77a0 [ 303.741276] x29: ffffffdf080e77a0 x28: ffffffdef3730040 [ 303.741300] x27: ffffff907c2240a0 x26: ffffffde6ff39afc [ 303.741321] x25: ffffffdef3730040 x24: ffffff907bf61018 [ 303.741343] x23: ffffff907c2240a0 x22: ffffffde6ff39a50 [ 303.741364] x21: 0000000000000001 x20: ffffffde6ff39a50 [ 303.741385] x19: ffffffde6bac2420 x18: 0000000000017200 [ 303.741407] x17: ffffff907c24a000 x16: 0000000000000037 [ 303.741428] x15: ffffff907b49a568 x14: ffffff907cf332c1 [ 303.741476] x13: 00000000000922e4 x12: 0000000000000000 [ 303.741497] x11: 0000000000000001 x10: 0000000000000007 [ 303.741518] x9 : f2256b8c1de4bc00 x8 : f2256b8c1de4bc00 [ 303.741539] x7 : ffffff907ab5e764 x6 : 0000000000000000 [ 303.741560] x5 : 0000000000000080 x4 : 0000000000000001 [ 303.741582] x3 : ffffffdf080e74a8 x2 : ffffff907aa91244 [ 303.741603] x1 : ffffffdf080e74a8 x0 : 0000000000000024 [ 303.741624] Call trace: [ 303.741701] ath10k_flush+0x54/0x104 [ath10k_core] [ 303.741941] __ieee80211_flush_queues+0x1dc/0x358 [mac80211] [ 303.742098] ieee80211_flush_queues+0x34/0x44 [mac80211] [ 303.742253] ieee80211_set_disassoc+0xc0/0x5ec [mac80211] [ 303.742399] ieee80211_mgd_deauth+0x720/0x7d4 [mac80211] [ 303.742535] ieee80211_deauth+0x24/0x30 [mac80211] [ 303.742720] cfg80211_mlme_deauth+0x250/0x3bc [cfg80211] [ 303.742849] cfg80211_mlme_down+0x90/0xd0 [cfg80211] [ 303.742971] cfg80211_disconnect+0x340/0x3a0 [cfg80211] [ 303.743087] __cfg80211_leave+0xe4/0x17c [cfg80211] [ 303.743203] cfg80211_leave+0x38/0x50 [cfg80211] [ 303.743319] wiphy_suspend+0x84/0x5bc [cfg80211] [ 303.743335] dpm_run_callback+0x170/0x304 [ 303.743346] __device_suspend+0x2dc/0x3e8 [ 303.743356] async_suspend+0x2c/0xb0 [ 303.743370] async_run_entry_fn+0x48/0xf8 [ 303.743383] process_one_work+0x304/0x604 [ 303.743394] worker_thread+0x248/0x3f4 [ 303.743403] kthread+0x120/0x130 [ 303.743416] ret_from_fork+0x10/0x18 [ 303.743812] ath10k_sdio mmc1:0001:1: ath10k_flush drop:0, pending:0-0 [ 303.743858] ------------[ cut here ]------------ [ 303.744057] WARNING: CPU: 1 PID: 3921 at /mnt/host/source/src/third_party/kernel/v4.19/drivers/net/wireless/ath/ath10k/mac.c:7025 ath10k_flush+0x54/0x104 [ath10k_core] [ 303.744075] Modules linked in: bridge stp llc ath10k_sdio ath10k_core rfcomm uinput cros_ec_rpmsg mtk_seninf mtk_cam_isp mtk_vcodec_enc mtk_fd mtk_vcodec_dec mtk_vcodec_common mtk_dip mtk_mdp3 videobuf2_dma_contig videobuf2_memops v4l2_mem2mem videobuf2_v4l2 videobuf2_common hid_google_hammer hci_uart btqca bluetooth dw9768 ov8856 ecdh_generic ov02a10 v4l2_fwnode mtk_scp mtk_rpmsg rpmsg_core mtk_scp_ipi ipt_MASQUERADE fuse iio_trig_sysfs cros_ec_sensors_ring cros_ec_sensors_sync cros_ec_light_prox cros_ec_sensors industrialio_triggered_buffer kfifo_buf cros_ec_activity cros_ec_sensors_core lzo_rle lzo_compress ath mac80211 zram cfg80211 joydev [last unloaded: ath10k_core] [ 303.744256] CPU: 1 PID: 3921 Comm: kworker/u16:10 Tainted: G W 4.19.95 #2 [ 303.744273] Hardware name: MediaTek krane sku176 board (DT) [ 303.744301] Workqueue: events_unbound async_run_entry_fn [ 303.744325] pstate: 60000005 (nZCv daif -PAN -UAO) [ 303.744403] pc : ath10k_flush+0x54/0x104 [ath10k_core] [ 303.744480] lr : ath10k_flush+0x54/0x104 [ath10k_core] [ 303.744496] sp : ffffffdf080e77a0 [ 303.744512] x29: ffffffdf080e77a0 x28: ffffffdef3730040 [ 303.744534] x27: ffffff907c2240a0 x26: ffffffde6ff39afc [ 303.744556] x25: ffffffdef3730040 x24: ffffff907bf61018 [ 303.744577] x23: ffffff907c2240a0 x22: ffffffde6ff39a50 [ 303.744598] x21: 0000000000000000 x20: ffffffde6ff39a50 [ 303.744620] x19: ffffffde6bac2420 x18: 000000000001831c [ 303.744641] x17: ffffff907c24a000 x16: 0000000000000037 [ 303.744662] x15: ffffff907b49a568 x14: ffffff907cf332c1 [ 303.744683] x13: 00000000000922ea x12: 0000000000000000 [ 303.744704] x11: 0000000000000001 x10: 0000000000000007 [ 303.744747] x9 : f2256b8c1de4bc00 x8 : f2256b8c1de4bc00 [ 303.744768] x7 : ffffff907ab5e764 x6 : 0000000000000000 [ 303.744789] x5 : 0000000000000080 x4 : 0000000000000001 [ 303.744810] x3 : ffffffdf080e74a8 x2 : ffffff907aa91244 [ 303.744831] x1 : ffffffdf080e74a8 x0 : 0000000000000024 [ 303.744853] Call trace: [ 303.744929] ath10k_flush+0x54/0x104 [ath10k_core] [ 303.745098] __ieee80211_flush_queues+0x1dc/0x358 [mac80211] [ 303.745277] ieee80211_flush_queues+0x34/0x44 [mac80211] [ 303.745424] ieee80211_set_disassoc+0x108/0x5ec [mac80211] [ 303.745569] ieee80211_mgd_deauth+0x720/0x7d4 [mac80211] [ 303.745706] ieee80211_deauth+0x24/0x30 [mac80211] [ 303.745853] cfg80211_mlme_deauth+0x250/0x3bc [cfg80211] [ 303.745979] cfg80211_mlme_down+0x90/0xd0 [cfg80211] [ 303.746103] cfg80211_disconnect+0x340/0x3a0 [cfg80211] [ 303.746219] __cfg80211_leave+0xe4/0x17c [cfg80211] [ 303.746335] cfg80211_leave+0x38/0x50 [cfg80211] [ 303.746452] wiphy_suspend+0x84/0x5bc [cfg80211] [ 303.746467] dpm_run_callback+0x170/0x304 [ 303.746477] __device_suspend+0x2dc/0x3e8 [ 303.746487] async_suspend+0x2c/0xb0 [ 303.746498] async_run_entry_fn+0x48/0xf8 [ 303.746510] process_one_work+0x304/0x604 [ 303.746521] worker_thread+0x248/0x3f4 [ 303.746530] kthread+0x120/0x130 [ 303.746542] ret_from_fork+0x10/0x18 one sample's debugging log: it wait 3190 ms(5000 - 1810). 1st ath10k_flush, it has 120 packets in tx queue of ath10k: <...>-1513 [000] .... 25374.786005: ath10k_log_err: ath10k_sdio mmc1:0001:1 ath10k_flush drop:1, pending:120-0 <...>-1513 [000] ...1 25374.788375: ath10k_log_warn: ath10k_sdio mmc1:0001:1 ath10k_htt_tx_mgmt_inc_pending htt->num_pending_mgmt_tx:0 <...>-1500 [001] .... 25374.790143: ath10k_log_dbg: ath10k_sdio mmc1:0001:1 bundle tx work, eid:1, count:121 2st ath10k_flush, it has 121 packets in tx queue of ath10k: <...>-1513 [000] .... 25374.790571: ath10k_log_err: ath10k_sdio mmc1:0001:1 ath10k_flush drop:0, pending:121-0 <...>-1513 [000] .... 25374.791990: ath10k_log_err: ath10k_sdio mmc1:0001:1 ath10k_mac_wait_tx_complete state:1 pending:121-0 <...>-1508 [001] .... 25374.792696: ath10k_log_dbg: ath10k_sdio mmc1:0001:1 credit update: delta:46 <...>-1508 [001] .... 25374.792700: ath10k_log_dbg: ath10k_sdio mmc1:0001:1 credit total:46 <...>-1508 [001] .... 25374.792729: ath10k_log_dbg: ath10k_sdio mmc1:0001:1 bundle tx work, eid:1, count:121 <...>-1508 [001] .... 25374.792937: ath10k_log_dbg: ath10k_sdio mmc1:0001:1 bundle tx status:0, eid:1, req count:88, count:32, len:49792 <...>-1508 [001] .... 25374.793031: ath10k_log_dbg: ath10k_sdio mmc1:0001:1 bundle tx status:0, eid:1, req count:75, count:14, len:21784 kworker/u16:0-25773 [003] .... 25374.793701: ath10k_log_dbg: ath10k_sdio mmc1:0001:1 bundle tx complete, eid:1, pending complete count:46 <...>-1881 [000] .... 25375.073178: ath10k_log_dbg: ath10k_sdio mmc1:0001:1 credit update: delta:24 <...>-1881 [000] .... 25375.073182: ath10k_log_dbg: ath10k_sdio mmc1:0001:1 credit total:24 <...>-1881 [000] .... 25375.073429: ath10k_log_dbg: ath10k_sdio mmc1:0001:1 bundle tx work, eid:1, count:75 <...>-1879 [001] .... 25375.074090: ath10k_log_dbg: ath10k_sdio mmc1:0001:1 bundle tx complete, eid:1, pending complete count:24 <...>-1881 [000] .... 25375.074123: ath10k_log_dbg: ath10k_sdio mmc1:0001:1 bundle tx status:0, eid:1, req count:51, count:24, len:37344 <...>-1879 [001] .... 25375.270126: ath10k_log_dbg: ath10k_sdio mmc1:0001:1 credit update: delta:26 <...>-1879 [001] .... 25375.270130: ath10k_log_dbg: ath10k_sdio mmc1:0001:1 credit total:26 <...>-1488 [000] .... 25375.270174: ath10k_log_dbg: ath10k_sdio mmc1:0001:1 bundle tx work, eid:1, count:51 <...>-1488 [000] .... 25375.270529: ath10k_log_dbg: ath10k_sdio mmc1:0001:1 bundle tx status:0, eid:1, req count:25, count:26, len:40456 <...>-1879 [001] .... 25375.270693: ath10k_log_dbg: ath10k_sdio mmc1:0001:1 bundle tx complete, eid:1, pending complete count:26 <...>-1488 [001] .... 25377.775885: ath10k_log_dbg: ath10k_sdio mmc1:0001:1 credit update: delta:12 <...>-1488 [001] .... 25377.775890: ath10k_log_dbg: ath10k_sdio mmc1:0001:1 credit total:12 <...>-1488 [001] .... 25377.775933: ath10k_log_dbg: ath10k_sdio mmc1:0001:1 bundle tx work, eid:1, count:25 <...>-1488 [001] .... 25377.776059: ath10k_log_dbg: ath10k_sdio mmc1:0001:1 bundle tx status:0, eid:1, req count:13, count:12, len:18672 <...>-1879 [001] .... 25377.776100: ath10k_log_dbg: ath10k_sdio mmc1:0001:1 bundle tx complete, eid:1, pending complete count:12 <...>-1488 [001] .... 25377.878079: ath10k_log_dbg: ath10k_sdio mmc1:0001:1 credit update: delta:15 <...>-1488 [001] .... 25377.878087: ath10k_log_dbg: ath10k_sdio mmc1:0001:1 credit total:15 <...>-1879 [000] .... 25377.878323: ath10k_log_dbg: ath10k_sdio mmc1:0001:1 bundle tx work, eid:1, count:13 <...>-1879 [000] .... 25377.878487: ath10k_log_dbg: ath10k_sdio mmc1:0001:1 bundle tx status:0, eid:1, req count:0, count:13, len:20228 <...>-1879 [000] .... 25377.878497: ath10k_log_dbg: ath10k_sdio mmc1:0001:1 bundle tx complete, eid:1, pending complete count:13 <...>-1488 [001] .... 25377.919927: ath10k_log_dbg: ath10k_sdio mmc1:0001:1 credit update: delta:11 <...>-1488 [001] .... 25377.919932: ath10k_log_dbg: ath10k_sdio mmc1:0001:1 credit total:13 <...>-1488 [001] .... 25377.919976: ath10k_log_dbg: ath10k_sdio mmc1:0001:1 bundle tx work, eid:1, count:0 <...>-1881 [000] .... 25377.982645: ath10k_log_warn: ath10k_sdio mmc1:0001:1 HTT_T2H_MSG_TYPE_MGMT_TX_COMPLETION status:0 <...>-1513 [001] .... 25377.982973: ath10k_log_err: ath10k_sdio mmc1:0001:1 ath10k_mac_wait_tx_complete time_left:1810, pending:0-0 Flush all pending TX packets for the 1st ath10k_flush reduced the wait time of the 2nd ath10k_flush and then suspend take short time. This Patch only effect SDIO chips. Tested with QCA6174 SDIO with firmware WLAN.RMH.4.4.1-00042. Signed-off-by:
-
Wen Gong authored
The default credit size is 1792 bytes, but the IP mtu is 1500 bytes, then it has about 290 bytes's waste for each data packet on sdio transfer path for TX bundle, it will reduce the transmission utilization ratio for data packet. This patch enable the small credit size in firmware, firmware will use the new credit size 1556 bytes, it will increase the transmission utilization ratio for data packet on TX patch. It results in significant performance improvement on TX path. This patch only effect sdio chip, it will not effect PCI, SNOC etc. Tested with QCA6174 SDIO with firmware WLAN.RMH.4.4.1-00017-QCARMSWP-1. Signed-off-by:
-
Wen Gong authored
The transmission utilization ratio for sdio bus for small packet is slow, because the space and time cost for sdio bus is same for large length packet and small length packet. So the speed of data for large length packet is higher than small length. Test result of different length of data: data packet(byte) cost time(us) calculated rate(Mbps) 256 28 73 512 33 124 1024 35 234 1792 45 318 14336 168 682 28672 333 688 57344 660 695 This patch change the TX packet from single packet to a large length bundle packet, max size is 32, it results in significant performance improvement on TX path. Also there's a fourth thread "ath10k_tx_complete_wq" added to ath10k as it improves TCP RX throughput (values in Mbps): TCP-RX TCP-TX UDP-RX UDP-TX use workqueue_tx_complete 423 357 448 412 change it to ar->workqueue 410 360 449 414 change it to ar->workqueue_aux 405 339 446 401 This patch only effect sdio chip, it will not effect PCI, SNOC etc. It only enable bundle for sdio chip. Tested with QCA6174 SDIO with firmware WLAN.RMH.4.4.1-00017-QCARMSWP-1. Signed-off-by: -
Jason Yan authored
The '==' expression itself is bool, no need to convert it to bool again. This fixes the following coccicheck warning: drivers/net/wireless/ath/ath11k/debug.c:198:57-62: WARNING: conversion to bool not needed here drivers/net/wireless/ath/ath11k/debug.c:218:58-63: WARNING: conversion to bool not needed here Signed-off-by:
-
Jason Yan authored
The '==' expression itself is bool, no need to convert it to bool again. This fixes the following coccicheck warning: drivers/net/wireless/ath/ath11k/dp_rx.c:255:46-51: WARNING: conversion to bool not needed here Signed-off-by:
-
- 21 Apr, 2020 4 commits
-
-
Kalle Valo authored
That way we don't need to have an empty function in sdio.c. No functional changes, compile tested only. Signed-off-by:
-
Kalle Valo authored
The _hif_ prefix should be used only on functions part of ath10k_hif_ops, so remove it from functions which should not have it. No functional changes, compile tested only. Signed-off-by:
-
Wen Gong authored
This patch is to set register to allow the mbox enter sleep status if it does not have tx traffic and wakeup it if tx traffic arrive. After mbox enter sleep status, the soc will enter sleep status by firmware, this will save power. The power consume drops from about 90mW to about 10mW with this patch. This patch only effect sdio chip. Tested with QCA6174 SDIO with firmware WLAN.RMH.4.4.1-00029. Signed-off-by:
-
Kalle Valo authored
Convert ath10k_hif_swap_mailbox() to a more generic op so that bus drivers can do more than just swap the mailbox, for example set power save settings like in the following sdio patch. No functional changes, compile tested only. Signed-off-by:
-
- 15 Apr, 2020 6 commits
-
-
Sriram R authored
IPQ8074 HW supports three TCL rings for tx. Currently these rings are mapped based on the Access categories, viz. VO, VI, BE, BK. In case, one of the traffic type dominates, then it could stress the same tcl rings. Rather, it would be optimal to make use of all the rings in a round robin fashion irrespective of the traffic type so that the load could be evenly distributed among all the rings. Also, in case the selected ring is busy or full, a retry mechanism is used to ensure other available ring is selected without dropping the packet. In SMP systems, this change avoids a single CPU from getting hogged when heavy traffic of same category is transmitted. The tx completion interrupts corresponding to the used tcl ring would be more which causes the assigned CPU to get hogged. Distribution of tx packets to different tcl rings helps balance this load. Signed-off-by:
Sriram R <srirrama@codeaurora.org> Signed-off-by:
-
Govindaraj Saminathan authored
should not overwrite the error code. No buffer available then return invalid. For other failures return the error code of actual failure. Signed-off-by:
Govindaraj Saminathan <gsamin@codeaurora.org> Signed-off-by:
-
Mamatha Telu authored
Fix some typo: s/fnrom/from s/pkgs/pkts/ s/AMSUs/AMSDUs/ Signed-off-by:
Mamatha Telu <telumamatha36@gmail.com> Signed-off-by:
-
Maharaja Kennadyrajan authored
Rx_filter flags are set with default filter flags during wifi up/down sequence even though the 'ext_rx_stats' debugfs is enabled as 1. So, that we are not getting proper per peer rx_stats. Hence, fixing this by setting the missing rx_filter when ext_rx_stats is already set/enabled. Signed-off-by:
-
Ritesh Singh authored
After setting fixed vht-rate if new station is trying to assoc with mu_bfee cap, or if a sta is already connected with mu_bfee cap then set the fixed vht-rate and reconnecting the sta, FW assert is happening. So to avoid this, reset the MU_BEAMFORMEE bit in vht->caps, if mcs_index is invalid for nss 1. Signed-off-by:
Ritesh Singh <ritesi@codeaurora.org> Signed-off-by:
-
Maharaja Kennadyrajan authored
Debugfs pdev entries should be cleaned up during the crash on recovery. If not, mac register will fail for the reason that it is already registered during core reconfigure. Signed-off-by:
-
- 14 Apr, 2020 6 commits
-
-
git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/ath.gitKalle Valo authored
ath.git patches for v5.8. Major changes: ath11k * add debugfs file for testing ADDBA and DELBA ath10k * enable VHT160 and VHT80+80 modes * enable radar detection in secondary segment * sdio: disable TX complete indication to improve throughput
-
Manikanta Pubbisetty authored
During RX, accessing the reo dest ring descriptor directly is consuming a lot of CPU cycles. Accessing the descriptor after copying it locally has improved CPU usage by around ~10-15% while measuring throughput in RX DBTC test cases(all radios are involved in the throughput measurement). HW tested: IPQ8074 Signed-off-by:
Manikanta Pubbisetty <mpubbise@codeaurora.org> Signed-off-by:
-
Manikanta Pubbisetty authored
Unlike CE interrupts, DP interrupts are not enabled/disabled at source; they are enabled/disabled only at GIC level, therefore it is required to set IRQ_DISABLE_UNLAZY flag to avoid spurious interrupts. Signed-off-by:
-
Aloka Dixit authored
TWT feature fails on radio2 because physical device count is hardcoded to 2. Set value dynamically. Signed-off-by:
Aloka Dixit <alokad@codeaurora.org> Signed-off-by:
-
Karthikeyan Periyasamy authored
Modify the interrupt timer threshold param as 256 to avoid HW watchdog in heavy multicast traffic scenario. Signed-off-by:
-
Karthikeyan Periyasamy authored
Add the pdev index information in the peer object to validate the peer creation. Ignore the peer creation request, if the given MAC address is already present in the peer list with same radio. If we allow the peer creation in above scenario, FW assert will happen. Above scenario occurred in two cases, where Multiple AP VAP created in the same radio. 1. when testing tool sends association request to two AP with same MAC address 2. when a station do roaming from one AP VAP to another AP VAP. Signed-off-by:
-
- 12 Apr, 2020 5 commits
-
-
Linus Torvalds authored
-
Linus Torvalds authored
This sorts the actual field names too, potentially causing even more chaos and confusion at merge time if you have edited the MAINTAINERS file. But the end result is a more consistent layout, and hopefully it's a one-time pain minimized by doing this just before the -rc1 release. This was entirely scripted: ./scripts/parse-maintainers.pl --input=MAINTAINERS --output=MAINTAINERS --order Requested-by:
Joe Perches <joe@perches.com> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org>
-
Linus Torvalds authored
They are all supposed to be sorted, but people who add new entries don't always know the alphabet. Plus sometimes the entry names get edited, and people don't then re-order the entry. Let's see how painful this will be for merging purposes (the MAINTAINERS file is often edited in various different trees), but Joe claims there's relatively few patches in -next that touch this, and doing it just before -rc1 is likely the best time. Fingers crossed. This was scripted with /scripts/parse-maintainers.pl --input=MAINTAINERS --output=MAINTAINERS but then I also ended up manually upper-casing a few entry names that stood out when looking at the end result. Requested-by:
-
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tipLinus Torvalds authored
Pull x86 fixes from Thomas Gleixner: "A set of three patches to fix the fallout of the newly added split lock detection feature. It addressed the case where a KVM guest triggers a split lock #AC and KVM reinjects it into the guest which is not prepared to handle it. Add proper sanity checks which prevent the unconditional injection into the guest and handles the #AC on the host side in the same way as user space detections are handled. Depending on the detection mode it either warns and disables detection for the task or kills the task if the mode is set to fatal" * tag 'x86-urgent-2020-04-12' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: KVM: VMX: Extend VMXs #AC interceptor to handle split lock #AC in guest KVM: x86: Emulate split-lock access as a write in emulator x86/split_lock: Provide handle_guest_split_lock()
-
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tipLinus Torvalds authored
Pull time(keeping) updates from Thomas Gleixner: - Fix the time_for_children symlink in /proc/$PID/ so it properly reflects that it part of the 'time' namespace - Add the missing userns limit for the allowed number of time namespaces, which was half defined but the actual array member was not added. This went unnoticed as the array has an exessive empty member at the end but introduced a user visible regression as the output was corrupted. - Prevent further silent ucount corruption by adding a BUILD_BUG_ON() to catch half updated data. * tag 'timers-urgent-2020-04-12' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: ucount: Make sure ucounts in /proc/sys/user don't regress again time/namespace: Add max_time_namespaces ucount time/namespace: Fix time_for_children symlink
-
