In a loop txqs dequeue scenario, if the first txq in the rbtree gets
removed from rbtree immediately in the ieee80211_return_txq(), the
loop will break soon in the ieee80211_next_txq() due to schedule_pos
not leading to the second txq in the rbtree. Thus update schedule_pos
to previous node once th
Global airtime weight sum is updated only when txq is added/removed
from rbtree. If upper layer configures sta weight during high load,
airtime weight sum will not be updated since txq is most likely on the
tree. It could a little late for upper layer to reconfigure sta weight
when txq is already i
This series fix some issues when enabling virtual time-based airtime scheduler
on ath10k.
Changes since v3:
Change schedule_pos to previous node once it has chance to be moved/removed
from current position in the tree in loop scenario and bring back
schedule_round
in case that same node is
From: Toke Høiland-Jørgensen
This switches the airtime scheduler in mac80211 to use a virtual time-based
scheduler instead of the round-robin scheduler used before. This has a
couple of advantages:
- No need to sync up the round-robin scheduler in firmware/hardware with
the round-robin airtime
Not long after the start of multi-clients test, not a single station is
an eligible candidate for transmission since global virtual time(g_vt) is
smaller than the virtual airtime(s_vt) of all the stations. As a result,
the Tx has been blocked and throughput is quite low.
This may mainly due accumu
On 12/12/2019, Girish Mahadevan wrote:
> Thanks !
> Sadly I am still not able to bring up the WiFi module (Silex part
> (SDMAC),QCA9377 using SDIO).
>
> I can't find the right firmware for it (I tried the firmware from
> https://github.com/kvalo/ath10k-firmware/tree/master/QCA9377/hw1.0/untested
Thanks !
Sadly I am still not able to bring up the WiFi module (Silex part
(SDMAC),QCA9377 using SDIO).
I can't find the right firmware for it (I tried the firmware from
https://github.com/kvalo/ath10k-firmware/tree/master/QCA9377/hw1.0/untested
, but keep getting "Invalid Firmware magic").
I am
From: Ben Greear
Do not ignore 0 txpower setting unless the vif is of type p2p.
This should fix regression in:
commit 88407beb1b1462f706a1950a355fd086e1c450b6
Author: Ryan Hsu
Date: Tue Dec 13 14:55:19 2016 -0800
ath10k: fix incorrect txpower set by P2P_DEVICE interface
Tested (without
Hello,
first of all i have to say thank you for your great job and the support!
It seems we have the same bug as already described here:
http://lists.infradead.org/pipermail/ath10k/2019-May/013358.html
We saw that there is a Fix
(http://lists.infradead.org/pipermail/ath10k/2019-May/013370.html)