Kalle Valo writes:
> Erik Stromdahl wrote:
>
>> From: Alagu Sankar
>>
>> The existing implementation of initiating multiple sdio transfers for
>> receive bundling is slowing down the receive speed.
>>
>> Instead of having one sdio transfer for each packet in the bundle, we
>> read all
Erik Stromdahl wrote:
> From: Alagu Sankar
>
> The existing implementation of initiating multiple sdio transfers for
> receive bundling is slowing down the receive speed.
>
> Instead of having one sdio transfer for each packet in the bundle, we
> read all packets in one sdio transfer.
>
>
Erik Stromdahl wrote:
> Iterating the TX queue and thereby dequeuing all available packets in the
> queue could result in performance penalties on some SMP systems.
>
> The reason for this is most likely that the per-ac lock (active_txq_lock)
> in mac80211 will be held by the CPU iterating the
Erik Stromdahl wrote:
> Iterating the TX queue and thereby dequeuing all available packets in the
> queue could result in performance penalties on some SMP systems.
>
> The reason for this is most likely that the per-ac lock (active_txq_lock)
> in mac80211 will be held by the CPU iterating the
Dundi Raviteja writes:
> Enable support to configure different beacon interval per VAP.
>
> To support this feature, map different beacon interval service bit
> to wmi tlv service.
>
> Tested HW: WCN3990
> Tested FW: WLAN.HL.2.0-01188-QCAHLSWMTPLZ-1
>
> Signed-off-by: Dundi Raviteja
[...]
>
On 2019-09-23 17:29, Kalle Valo wrote:
Wen Gong writes:
The bottleneck of throughout on sdio chip is the bus bandwidth, to the
patches are all to increase the use ratio of sdio bus.
udp-rxudp-txtcp-rxtcp-tx
without patches(Mbps) 320180 170
On 2019-09-23 17:05, Kalle Valo wrote:
+#define ATH10K_HTC_FLAG_BUNDLE_MASK 0xF0
+#define ATH10K_HTC_BUNDLE_EXTRA_MASK GENMASK(3, 2)
+
+#define ATH10K_HTC_GET_BUNDLE_COUNT(flags) \
+ (FIELD_GET(ATH10K_HTC_FLAG_BUNDLE_MASK, (flags)) + \
+
On 2019-09-24 16:48, Toke Høiland-Jørgensen wrote:
Yibo Zhao writes:
I can see why we need the second part (basically, this happens
because
I
forgot to add a check for "no eligible stations" in may_transmit(),
like
the one in next_txq()). And rounding up the division result doesn't
hurt, I
Yibo Zhao writes:
>> I can see why we need the second part (basically, this happens because
>> I
>> forgot to add a check for "no eligible stations" in may_transmit(),
>> like
>> the one in next_txq()). And rounding up the division result doesn't
>> hurt, I guess. But why does it help to
Yibo Zhao writes:
> On 2019-09-24 15:26, Toke Høiland-Jørgensen wrote:
Hmm, yeah, I guess we could end up with a loop like that as well.
Keeping the schedule_round would be a way to fix it, but I'm not sure
we
should just skip that station; maybe we should just end the round
On 2019-09-24 15:26, Toke Høiland-Jørgensen wrote:
Hmm, yeah, I guess we could end up with a loop like that as well.
Keeping the schedule_round would be a way to fix it, but I'm not sure
we
should just skip that station; maybe we should just end the round
instead?
I am not sure. I believe, in
On 2019-09-23 18:55, Toke Høiland-Jørgensen wrote:
Yibo Zhao writes:
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,
On 24/09/2019, Kalle Valo wrote:
> Tomislav Požega writes:
>
>> Drop unneeded lines by moving skb data in both main and 10x WMI
>> pull service ready event operations.
>>
>> Signed-off-by: Tomislav Požega
>> ---
>> drivers/net/wireless/ath/ath10k/wmi.c |6 ++
>> 1 files changed, 2
On 2019-09-24 13:42, Kalle Valo wrote:
patch v4 sent.
So please rebase and resend.
For some hw version, it has more than one bus type, it need to add bus
type to distinguish different chip.
Tested with QCA6174 SDIO with firmware
WLAN.RMH.4.4.1-00018-QCARMSWP-1.
Signed-off-by: Wen Gong
---
v2: change code style
v3: split bus type to another patch,
remove ATH10K_BUS_ANY,
add
When firmware assert, it need coredump to analyze, this patch will
collect the register and memory info for sdio chip.
The coredump configuration is different between PCIE and SDIO for
the same reversion, so this patch add bus type to distinguish PCIE
and SDIO chip for coredump.
It has 2 type to
add fw coredump for sdio when firmware assert
v2: change code style
v3: split bus type to another patch,
remove ATH10K_BUS_ANY,
add bus type for each layout
v4: rebase to latest commit
Wen Gong (2):
ath10k: add bus type for each layout of coredump
ath10k: add fw coredump for sdio when
Yibo Zhao writes:
> On 2019-09-23 19:00, Toke Høiland-Jørgensen wrote:
>
>>> - if (params->airtime_weight)
>>> - sta->airtime_weight = params->airtime_weight;
>>> + if (params->airtime_weight &&
>>> + params->airtime_weight != sta->airtime_weight) {
>>
>> This check doesn't
>> Hmm, yeah, I guess we could end up with a loop like that as well.
>> Keeping the schedule_round would be a way to fix it, but I'm not sure
>> we
>> should just skip that station; maybe we should just end the round
>> instead?
> I am not sure. I believe, in some cases, the rest of the nodes
Kalle Valo writes:
> Toke Høiland-Jørgensen writes:
>
>> Kalle Valo writes:
>>
>>> Toke Høiland-Jørgensen writes:
>>>
Yibo Zhao writes:
> On 2019-09-21 22:00, Toke Høiland-Jørgensen wrote:
>> Yibo Zhao writes:
>>
>>> On 2019-09-21 21:02, Toke Høiland-Jørgensen
Hi,
The support for this device was added a while ago to OpenWrt. This AP requires
two special BDFs to get the Wi-Fi PHYs working (correctly). The bmi-board-id='s
would clash with one of the the IPQ401X AP-DK boards because QCA doesn't
provide special IDs for customers and seems to use the
21 matches
Mail list logo
