Hello Adrian,Thanks for your quick response. Specifically 3 follow-up
queries:a. Based on your comment, "I thought bt_tx_rx is "bt is active", not
"bt is tx'ing." I'd have tocheck the PHY docs.". Can you please check this and
confirm/let me know? Based on your comment, bt_tx_rx = 1 when BT_ACTIVE = 1 and
0 otherwise.b. Regarding the comment on BT indicating that it is only in
receive mode. As we understand there are multicast/ broadcast packets sent from
WiFi AP to WiFi STA (my WiFi device). There are cameras which does udp
streaming. So, if BT can inform WLAN that it is only in receive mode, then WLAN
can also receive the multicast/ broadcast packets and hence the throughput of
WLAN will increase. What is your opinion?c. Next, in a 2-wire coexistence
scheme, if BT_ACTIVE can we inform WLAN to enter into power save mode? As I
understand with this, the WiFi AP will buffer all multicast/broadcast packets.
When BT_ACTIVE is de-asserted, then WLAN can exit power save mode and get the
buffered packets. Is this realistic? And if Yes, how can this be achieved?
Thanks & regardsSandeep
On Wednesday, 30 March 2016 1:59 AM, Adrian Chadd <adr...@freebsd.org>
wrote:
On 28 March 2016 at 21:22, sandeep suresh <sandeep.sur...@yahoo.co.in> wrote:
> Hello Adrian,
> Thanks for your response. Currently with 2-wire coexistence, BT has
> higher priority when compared to WiFi. You had shared the following
> different bitfields that can be configured with different weights:
>
> WLAN:-
> wait_beacon | qcu_priority | rx_clear | wlan level
>
> BT:-
> bt_priority | bt freq | bt_tx_rx | bt_level
>
> I have the following queries, please help:
> 1. wait_beacon:- WLAN client is waiting for a beacon from AP, this bit will
> be set. If the weights during this state is kept the highest, then even if
> BT wants to use the medium (BT_ACTIVE = 1), WLAN will always attempt to
> catch the beacon. Am I correct in my understanding?
Right. The idea is that the STA wants to hear a beacon, so if it's
important to do this ,you want to have WLAN stomp BT.
> 2. What happens if BT wants to transmit during this time when wait_beacon =
> TRUE; will the BT transmission be suppressed?
If you set the weight appropriately then yeah, WLAN stomps BT.
> 3. Regarding "bt_tx_rx". As I understand, bt_tx_rx = 1 when BT is
> transmitting and bt_tx_rx = 0 when BT is receiving; am I correct? How can BT
> module communicate if it will be transmitting or receiving to WLAN module?
> Because BT_PRIORITY will only indicate High or Low priority.
I thought bt_tx_rx is "bt is active", not "bt is tx'ing." I'd have to
check the PHY docs.
> 4. Currently the WLAN_ACTIVE line indicates only Tx activity from WLAN. Is
> there any way to indicate only Rx activities (E.g. Beacon reception etc) ?
On two/three-wire coex, no, I don't think so. The whole point is that
you just need to know "is the BT wanting to do stuff", "is the wlan
wanting to do stuff" and "who wins".
The wlan chip is the arbiter of who wins, it has the weights
programmed in to figure out what to do when.
> 5. Regarding your comment on dynamically changing weights. AR9287 and the
> BT chipsets are separate and connected to a Host controller running linux.
> As for different states of BT, if there is a need for different weights, I
> do not think at runtime the weights can be changed (by sending a command
> from BT to Host and then weight change from Host to WLAN)as we might not be
> able to meet the short timings. WHat is your opinion on this?
No, the BT doesn't get to send the host commands like that. The driver
layer (ath9k) could be extended to include smarts about traffic
patterns and which BT profiles are active, so you can tune the weights
based on it.
The ath9k driver can also do things to "tune" how much of the channel
it uses - eg, by using the quiet time timers to control TX duty cycle
so BT has more of a chance to work.
The later chips (MCI?) implement a control protocol between the wlan
side and the bt side. I haven't yet ported that functionality to
freebsd so I don't have any operational experience with that!
-adrian
_______________________________________________
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel
