Announcement: open source AR9380 and later HAL

Announcement: open source AR9380 and later HAL

[Adrian Chadd]

Hi,

I just realised I forgot to announce this here!

I've been working on open sourcing the QCA 10.x mainline AR9380 HAL.
It's passed legal approval (well, last week!) and you can now find it
online:

https://github.com/qca/qcamain_open_hal_public

Now, the 30 second FAQ:

* It's from Nov 27, 2012 - which means there are a few things that
have changed since then - so don't use it as an authoritative
reference compared to ath9k without doing much more digging! ;
* It's missing certain things - including but not limited to
EEPROM/OTP write, TX beamforming, spectral scan (but this will change
later), fast channel change, various calibration and debug modes which
are used for manufacturing;
* It (mostly) compiles and runs as-is, if you're a FreeBSD user and
have a HAL framework to compile it against.

I've done this so open source developers can see a known good and
working version of the chipset support for the AR9380 and later.

If you check out my personal git fork:

https://github.com/erikarn/qcamain_open_hal_public

You'll see that I have a branch (local/freebsd) which contains the
(mostly mechanical!) changes to FreeBSD in order to use it. And yes,
this branch does compile and run in FreeBSD, giving me AR9380 and
later chipset support.

I have an update underway to bring it up to the latest code (well, as
of March 13, 2013) and I'll send out another announcement once that's
done.

I'll also work with legal and engineering teams to get further
features opened up.

Thanks and enjoy!



Adrian

Re: Announcement: open source AR9380 and later HAL

[Nick Kossifidis]

On Fri Mar 15 02:10:50 2013, Adrian Chadd wrote:
> Hi,
>
> I just realised I forgot to announce this here!
>
> I've been working on open sourcing the QCA 10.x mainline AR9380 HAL.
> It's passed legal approval (well, last week!) and you can now find it
> online:
>
> https://github.com/qca/qcamain_open_hal_public
>
> Now, the 30 second FAQ:
>
> * It's from Nov 27, 2012 - which means there are a few things that
> have changed since then - so don't use it as an authoritative
> reference compared to ath9k without doing much more digging! ;
> * It's missing certain things - including but not limited to
> EEPROM/OTP write, TX beamforming, spectral scan (but this will change
> later), fast channel change, various calibration and debug modes which
> are used for manufacturing;
> * It (mostly) compiles and runs as-is, if you're a FreeBSD user and
> have a HAL framework to compile it against.
>
> I've done this so open source developers can see a known good and
> working version of the chipset support for the AR9380 and later.
>
> If you check out my personal git fork:
>
> https://github.com/erikarn/qcamain_open_hal_public
>
> You'll see that I have a branch (local/freebsd) which contains the
> (mostly mechanical!) changes to FreeBSD in order to use it. And yes,
> this branch does compile and run in FreeBSD, giving me AR9380 and
> later chipset support.
>
> I have an update underway to bring it up to the latest code (well, as
> of March 13, 2013) and I'll send out another announcement once that's
> done.
>
> I'll also work with legal and engineering teams to get further
> features opened up.
>
> Thanks and enjoy!
>
>
>
> Adrian
> --
> To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Thanks a lot Adrian !
Keep it up :-)

Re: [ath9k-devel] Source code for Bluetooth AR3012 drivers

[Adrian Chadd]

The source code is not available for the AR3xxx series hardware, I'm sorry.

The devices run firmware, either in RAM, ROM or flash.

Thanks,


Adrian

On 1 April 2013 20:00, sandeep suresh <sandeep.suresh@yahoo.co.in> wrote:
> Hello all,
>     Under the link,
>
> git://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/ar3k/
>
> there is only .dfu file and could not get the source code. Where can I find
> and download the source code base for this driver?
>
> Thanks & regards
> Sandeep Suresh
>
>
>
>
> _______________________________________________
> ath9k-devel mailing list
> ath9k-devel@lists.ath9k.org
> https://lists.ath9k.org/mailman/listinfo/ath9k-devel
>

Re: AR9287; mapping between GPIOs and COEX pins

[Adrian Chadd]

It depends on what the card manufacturer has done.




Adrian

On 2 April 2013 04:57, sandeep suresh <sandeep.suresh@yahoo.co.in> wrote:
> Hello All,
>         In AR9287, there are ten GPIOs and GPIO[0:3] are mapped to JTAG.
> Remaining GPIOs [4:9] are free. Can you please help me with the mapping of
> GPIO pins to COEX pins? That means which GPIO is connected to:
> a) WLAN_ACTIVE
> b)BT_PRIORITY
> c)BT_ACTIVE
> d)BT_FREQUENCY
>
> Thanks & regards
> Sandeep.

Re: AR9287; mapping between GPIOs and COEX pins

[Adrian Chadd]

The point behind GPIO pins is that they're generic. There's a
multiplexer in the NIC which lets you map various GPIO pins to any
internal function.

So, you need to find which GPIO pins the bluetooth device is connected to.

Once you know that, you can set the GPIO input/output multiplexer bits
to give those GPIO pins the right BT behaviour.



Adrian


On 2 April 2013 08:20, sandeep suresh <sandeep.suresh@yahoo.co.in> wrote:
> Hello Mr.Adrian,
>     The card manufacturer like Compex systems for AR9287 has these pins
> available on PCIe interface. But my query is AR9287 specific. AR9287 is a 76
> pin IC. GPIO4 is Pin22, GPIO5 is Pin23, GPIO6 is Pin 24 and so on. The
> question is if I need to access COEX signals (WL_ACTIVE, BT_ACTIVE,
> BT_PRIORITY, BT_FREQUENCY), on which of these 76 pins can I access them?
> Please help.
>
> Regards
> Sandeep.
>
> From: Adrian Chadd <adrian@freebsd.org>
> To: sandeep suresh <sandeep.suresh@yahoo.co.in>
> Cc: ath9k-devel <ath9k-devel@lists.ath9k.org>;
> "linux-wireless@vger.kernel.org" <linux-wireless@vger.kernel.org>
> Sent: Tuesday, 2 April 2013 8:23 PM
> Subject: Re: AR9287; mapping between GPIOs and COEX pins
>
> It depends on what the card manufacturer has done.
>
>
>
>
> Adrian
>
> On 2 April 2013 04:57, sandeep suresh <sandeep.suresh@yahoo.co.in> wrote:
>> Hello All,
>>        In AR9287, there are ten GPIOs and GPIO[0:3] are mapped to JTAG.
>> Remaining GPIOs [4:9] are free. Can you please help me with the mapping of
>> GPIO pins to COEX pins? That means which GPIO is connected to:
>> a) WLAN_ACTIVE
>> b)BT_PRIORITY
>> c)BT_ACTIVE
>> d)BT_FREQUENCY
>>
>> Thanks & regards
>> Sandeep.
>
>

Re: AR9287 ; 2-wire coexistence expected behavior

[Adrian Chadd]

Hi!

I'm glad you're looking into this in more depth!

On 4 April 2013 08:19, sandeep suresh <sandeep.suresh@yahoo.co.in> wrote:

> I understand that ATH_BTCOEX_CFG_2_WIRE, ATH_BTACTIVE_GPIO_9280 (GPIO6 as
> per btcoex.h) and ATH_WLANACTIVE_GPIO_9280 (GPIO5 as per btcoex.h) are used.

Ok, right.

> I next started monitoring GPIO5 on oscillaoscope to see WLAN activity and I
> could see a lot of pulse trains. Next in order to simulate high priority BT
> traffic, I pulled the line GPIO6 high. But I did not see any change in WLAN
> activity as I could continue to see the pulse trains. My expectation was
> that there should not be any WLAN activity and hence no pulses. Please guide
> if I am missing anything?

Well, firstyl you need to ensure that the GPIO pin has been programmed
to be an input, and it's of the right bluetooth type. As I said
before, GPIO pins can be input, output; they can be connected via an
internal mux to a variety of "behaviours". Take a look at the gpio
configure code in ath9k to see more.

THen you need to ensure the bluetooth coexistence registers are
programmed so that btactive will correctly stomp wifi traffic.

THat's all I know for now. Sorry.



adrian

Re: AR9287 ; 2-wire coexistence expected behavior

[Adrian Chadd]

You'll have to give me some more time to digest what I'm reading
internally; it's all new to me.

For FreeBSD, you can look at these files in FreeBSD-HEAD:

sys/dev/ath/ath_hal/ar5416/ar5416_btcoex.c
sys/dev/ath/ath_hal/ar9002/ar9285_btcoex.c (not that relevant for you,
but still)

These contain the register writes that the internal reference HAL is
doing when programming btcoex for AR9285/AR9287.

The AR9287 should support 2-wire coex fine.

Just read those source files. The ar5416InitBTCoex() programs the
BT_ACTIVE / WLAN_ACTIVE gpio's when you say the coexistence type is
2-wire. There's weights and such being programmed elsewhere; you need
to make sure you pick the default values for that and try it out.

I can't help you more than that at the moment; I'm busy doing other
work that doesn't at all touch wifi. :)



Adrian

On 4 April 2013 20:08, sandeep suresh <sandeep.suresh@yahoo.co.in> wrote:
> Hello Mr.Adrian,
>     Thanks for your mail. Regarding your comment below:
>
> "THen you need to ensure the bluetooth coexistence registers are programmed
> so that btactive will correctly stomp wifi traffic."
>
> Can you please elaborate on this? As I understand the concept of "stomping"
> is only in 3-wire coexistence; correct me if I am wrong.
>
> As mentioned earlier, the set-up we have is a PCB board with general purpose
> MCU controlling the 2-wire coexistence pins of AR9287. As there are other
> 2.4GHz radio (called PROP radio here) on the board, we want to ensure that
> both radios do not transmit at the same time which will result in
> collisions. Hence we want to build a co-operative coexistence approach so
> that when PROP radio is active (by asserting BT_ACTIVE), AR9287 has to
> buffer transmissions and allow PROP radio to be active. Only when PROP radio
> is inactive (BT_ACTIVE is deasserted), only then WiFi can be active. Hope
> this is achievable?
>
> Thanks & Regards
> Sandeep.
>
> From: Adrian Chadd <adrian@freebsd.org>
> To: sandeep suresh <sandeep.suresh@yahoo.co.in>
> Cc: "linux-wireless@vger.kernel.org" <linux-wireless@vger.kernel.org>;
> ath9k-devel <ath9k-devel@lists.ath9k.org>
> Sent: Thursday, 4 April 2013 11:36 PM
>
> Subject: Re: AR9287 ; 2-wire coexistence expected behavior
>
> Hi!
>
> I'm glad you're looking into this in more depth!
>
> On 4 April 2013 08:19, sandeep suresh <sandeep.suresh@yahoo.co.in> wrote:
>
>> I understand that ATH_BTCOEX_CFG_2_WIRE, ATH_BTACTIVE_GPIO_9280 (GPIO6 as
>> per btcoex.h) and ATH_WLANACTIVE_GPIO_9280 (GPIO5 as per btcoex.h) are
>> used.
>
> Ok, right.
>
>> I next started monitoring GPIO5 on oscillaoscope to see WLAN activity and
>> I
>> could see a lot of pulse trains. Next in order to simulate high priority
>> BT
>> traffic, I pulled the line GPIO6 high. But I did not see any change in
>> WLAN
>> activity as I could continue to see the pulse trains. My expectation was
>> that there should not be any WLAN activity and hence no pulses. Please
>> guide
>> if I am missing anything?
>
> Well, firstyl you need to ensure that the GPIO pin has been programmed
> to be an input, and it's of the right bluetooth type. As I said
> before, GPIO pins can be input, output; they can be connected via an
> internal mux to a variety of "behaviours". Take a look at the gpio
> configure code in ath9k to see more.
>
> THen you need to ensure the bluetooth coexistence registers are
> programmed so that btactive will correctly stomp wifi traffic.
>
> THat's all I know for now. Sorry.
>
>
>
> adrian
>
>

Re: AR9287 ; 2-wire coexistence expected behavior

[Adrian Chadd]

There's nothing public, no. Just the source code. :)


adrian


On 5 April 2013 01:00, sandeep suresh <sandeep.suresh@yahoo.co.in> wrote:
> Thanks Mr. Adrian. I will revert back to you after sometime. But are there
> any documents/datasheets explaining on the BTCOEX mode registers, timing
> diagrams for 2-wire/3-wire coexistence based on Atheros chipset?
> I have already gone through the ath9k website; but does not contain these
> details.
> Thanks & Regards
> Sandeep.
>
> From: Adrian Chadd <adrian@freebsd.org>
> To: sandeep suresh <sandeep.suresh@yahoo.co.in>
> Cc: "linux-wireless@vger.kernel.org" <linux-wireless@vger.kernel.org>;
> ath9k-devel <ath9k-devel@lists.ath9k.org>
> Sent: Friday, 5 April 2013 9:43 AM
>
> Subject: Re: AR9287 ; 2-wire coexistence expected behavior
>
> You'll have to give me some more time to digest what I'm reading
> internally; it's all new to me.
>
> For FreeBSD, you can look at these files in FreeBSD-HEAD:
>
> sys/dev/ath/ath_hal/ar5416/ar5416_btcoex.c
> sys/dev/ath/ath_hal/ar9002/ar9285_btcoex.c (not that relevant for you,
> but still)
>
> These contain the register writes that the internal reference HAL is
> doing when programming btcoex for AR9285/AR9287.
>
> The AR9287 should support 2-wire coex fine.
>
> Just read those source files. The ar5416InitBTCoex() programs the
> BT_ACTIVE / WLAN_ACTIVE gpio's when you say the coexistence type is
> 2-wire. There's weights and such being programmed elsewhere; you need
> to make sure you pick the default values for that and try it out.
>
> I can't help you more than that at the moment; I'm busy doing other
> work that doesn't at all touch wifi. :)
>
>
>
> Adrian
>
> On 4 April 2013 20:08, sandeep suresh <sandeep.suresh@yahoo.co.in> wrote:
>> Hello Mr.Adrian,
>>    Thanks for your mail. Regarding your comment below:
>>
>> "THen you need to ensure the bluetooth coexistence registers are
>> programmed
>> so that btactive will correctly stomp wifi traffic."
>>
>> Can you please elaborate on this? As I understand the concept of
>> "stomping"
>> is only in 3-wire coexistence; correct me if I am wrong.
>>
>> As mentioned earlier, the set-up we have is a PCB board with general
>> purpose
>> MCU controlling the 2-wire coexistence pins of AR9287. As there are other
>> 2.4GHz radio (called PROP radio here) on the board, we want to ensure that
>> both radios do not transmit at the same time which will result in
>> collisions. Hence we want to build a co-operative coexistence approach so
>> that when PROP radio is active (by asserting BT_ACTIVE), AR9287 has to
>> buffer transmissions and allow PROP radio to be active. Only when PROP
>> radio
>> is inactive (BT_ACTIVE is deasserted), only then WiFi can be active. Hope
>> this is achievable?
>>
>> Thanks & Regards
>> Sandeep.
>>
>> From: Adrian Chadd <adrian@freebsd.org>
>> To: sandeep suresh <sandeep.suresh@yahoo.co.in>
>> Cc: "linux-wireless@vger.kernel.org" <linux-wireless@vger.kernel.org>;
>> ath9k-devel <ath9k-devel@lists.ath9k.org>
>> Sent: Thursday, 4 April 2013 11:36 PM
>>
>> Subject: Re: AR9287 ; 2-wire coexistence expected behavior
>>
>> Hi!
>>
>> I'm glad you're looking into this in more depth!
>>
>> On 4 April 2013 08:19, sandeep suresh <sandeep.suresh@yahoo.co.in> wrote:
>>
>>> I understand that ATH_BTCOEX_CFG_2_WIRE, ATH_BTACTIVE_GPIO_9280 (GPIO6 as
>>> per btcoex.h) and ATH_WLANACTIVE_GPIO_9280 (GPIO5 as per btcoex.h) are
>>> used.
>>
>> Ok, right.
>>
>>> I next started monitoring GPIO5 on oscillaoscope to see WLAN activity and
>>> I
>>> could see a lot of pulse trains. Next in order to simulate high priority
>>> BT
>>> traffic, I pulled the line GPIO6 high. But I did not see any change in
>>> WLAN
>>> activity as I could continue to see the pulse trains. My expectation was
>>> that there should not be any WLAN activity and hence no pulses. Please
>>> guide
>>> if I am missing anything?
>>
>> Well, firstyl you need to ensure that the GPIO pin has been programmed
>> to be an input, and it's of the right bluetooth type. As I said
>> before, GPIO pins can be input, output; they can be connected via an
>> internal mux to a variety of "behaviours". Take a look at the gpio
>> configure code in ath9k to see more.
>>
>> THen you need to ensure the bluetooth coexistence registers are
>> programmed so that btactive will correctly stomp wifi traffic.
>>
>> THat's all I know for now. Sorry.
>>
>>
>>
>> adrian
>>
>>
>
>

Re: AR9287 ; 2-wire coexistence expected behavior

[Adrian Chadd]

On 5 April 2013 02:06, sandeep suresh <sandeep.suresh@yahoo.co.in> wrote:
> Thanks Mr.Adrian for the information. I had a look at the source code for
> Ath9k. For 2-wire coexistence, other than GPIO configuration (direction, Mux
> etc) for WLAN_ACTIVE and BT_ACTIVITY, is there also weight register
> configuration for BT and WLAN for 2-wire?
> What exactly is the meaning of these weight registers?

I've no idea just yet, sorry. I'm still trying to digest how bluetooth
coexistence works.



Adrian

Re: [ath9k-devel] AR9287 ; 2-wire coexistence expected behavior

[Sujith Manoharan]

sandeep suresh wrote:
> I had a look at the source code for Ath9k. For 2-wire coexistence, other than
> GPIO configuration (direction, Mux etc) for WLAN_ACTIVE and BT_ACTIVITY, is
> there also weight register configuration for BT and WLAN for 2-wire?  What
> exactly is the meaning of these weight registers?

BTCOEX protocol in ath9k can be of 3 types: 2-wire, 3-wire and MCI.

All chips in the pre-AR9003 family have separate WLAN and BT devices
as part of the same board. In a 2-wire connection between the devices, they
are marked as BT_ACTIVE and WLAN_ACTIVE. BT_ACTIVE is driven by the BT device
and WLAN_ACTIVE by the WLAN device, obviously.

If the Bluetooth device is expecting to TX or RX, it asserts BT_ACTIVE. If
WLAN traffic has been prioritized over BT traffic, WLAN_ACTIVE is asserted and
Bluetooth traffic is "stomped".

Now, the means of "prioritizing" traffic is done based on "weights". For each
combination of BT_PRIORITY/BT_[TX|RX], weights are programmed in the HW.
The same is done for WLAN. So, when the card is operational and BT_ACTIVE is
asserted and if there is current WLAN traffic, the HW checks if the weight
of the BT traffic is lower than WLAN and if so, continues to transmit WLAN frames.
If BT priority is higher, the HW will *abort* WLAN traffic like there was
a collision. I'd assume that at this point, backoff will kick in.

2-wire doesn't have BT_PRIORITY, so traffic classification is very primitive
and coexistence is not optimal. 3-wire is much better and the best of the breed
is the MCI based scheme implemented in AR9462 and AR9565. These two chips, unlike
other WLAN+BT cards like WB195, WB225, WB197 etc. are *combo* chips and hence
have a complex system of message-passing to exchange information between the
BT-core and WLAN. MCI is built on 3-wire, so it uses the same lines at a basic level.

Now, these lines (either 2 or 3) are connected by GPIOs at the WLAN side. They
can be programmed as either input or output and the GPIO number is fixed for
each card. The WLAN-driven line WLAN_ACTIVE is configured as output and the
signals coming in from BT are configured as input. The actual pin numbers can be
found in ath9k_hw_btcoex_init_scheme().

This is only the basic picture - there are a lot of other components which
interact with each other to provide a more dynamic algorithm to distribute
airtime between WLAN and BT. Most of the stuff is in gpio.c and btcoex.c

Hope this helps.

Sujith

Re: [ath9k-devel] AR9287 ; 2-wire coexistence expected behavior

[Adrian Chadd]

On 5 April 2013 08:24, sandeep suresh <sandeep.suresh@yahoo.co.in> wrote:
> Hello Mr.Sujith,
>     Thanks for the elaborate answer which helps a lot.
> But the question is for 2-wire coexistence, are there any weight register?
> Because I did not see the same in ath9k code base neither in btcoex.c,
> gpio.c etc. The weight registers are only available for 3-wire. Please let
> me know if there is any weight register in AR9287 for 2-wire and its address
> in AR9287?

Yup. The weight register is there for 2-wire. It just has a different meaning.

I'm digging thorough this, i'll let you know when I know more.

> Do you know if AR9287 also supports MCI mode?

Nope. It doesn't.


Adrian

Re: [ath9k-devel] AR9287 ; 2-wire coexistence expected behavior

[Adrian Chadd]

Ok, so what I've discovered:

The weight registers in pre-ar9300 chips are pairs of 2 bit registers
that map to some internal state inside the MAC.

Ie, if state is "X", then weight is "Y".

The MAC then compares the WLAN and BT weights; if WLAN >= BT, WLAN wins.

I'll see if I can polish this up and dump some register description
online for these coexistence registers. There's only like, 3 major
ones for AR9285/AR9287 (and then various ancillaries) that are
involved in basic BT coexistence.

AR9380 and later have larger weight tables because (a) their weight
values are bigger than 2 bits I Think? and (b) there's more internal
states to take into account. But 2-wire and 3-wire coexistence is
essentially the same. MCI (with lots of message passing around) is
where that changed.

Thanks,



Adrian

Re: [ath9k-devel] AR9287 ; 2-wire coexistence expected behavior

[Adrian Chadd]

Right.

So the weight table for Kite/Kiwi:

wait_beacon | qcu_priority | rx_clear | wlan level
0 | 0 | 0 | wlan_weight[0:1]
0 | 0 | 1 | wlan_weight[3:2]
0 | 1 | 0 | wlan_weight[5:4]
0 | 1 | 1 | wlan_weight[7:6]
1 | 0 | 0 | wlan_weight[9:8]
1 | 0 | 1 | wlan_weight[11:10]
1 | 1 | 0 | wlan_weight[13:12]
1 | 1 | 1 | wlan_weight[15:14]

bt_priority | bt freq | bt_tx_rx | bt_level
0 | 0 | 0 | bt_weight[0:1]
0 | 0 | 1 | bt_weight[3:2]
0 | 1 | 0 | bt_weight[5:4]
0 | 1 | 1 | bt_weight[7:6]
1 | 0 | 0 | bt_weight[9:8]
1 | 0 | 1 | bt_weight[11:10]
1 | 1 | 0 | bt_weight[13:12]
1 | 1 | 1 | bt_weight[15:14]

wait_beacon is whether we're waiting for a beacon in STA mode. No idea
how this works in hostap mode, but see below.
qcu_priority is whether it's a low or high queue priority.  Any queue
above the "queue threshold" value in one of the BT config registers
(see the source) is a high priority queue and is 1 here.
rx_clear is whether we're busy

bt_priority - the bt priority line
bt_freq - no idea
bt_tx_rx - whether the BT module is transmitting (3 wire only I guess,
irrelevant for 2 wire)

I hope that's enough to get started on what you're trying to achieve.
Please share your results!



Adrian

Re: [ath9k-devel] AR9287 ; 2-wire coexistence expected behavior

[Adrian Chadd]

On 7 April 2013 07:54, sandeep suresh <sandeep.suresh@yahoo.co.in> wrote:
> Hello Mr.Adrian and Mr.Sujith,
>     Thanks for your responses. In order to ensure that all of us are on the
> same page and referring to the same code base, some queries:
>
> 1. Please let me know you are referring to freebsd.org or linuxwireless.org
> drivers? Because you are referring to Kite & Kiwi which are in FreeBSD.
>    FreeBSD --> http://svn.freebsd.org/base/head/sys/
>    Ath9k --> http://linuxwireless.org/en/users/Drivers/ath9k
>    Because currently I am using ath9k drivers only from linuxwireless.org.

Kite = AR9285
Kiwi = AR9287

I know ath9k enough to be (somewhat) helpful and dangerous. But I'm
the FreeBSD guy here; I know the HAL and FreeBSD code much better.

The FreeBSD code is closer to what our reference driver does / did
than Linux, at least for the legacy chipset support.

> 2. Which version of ath9k driver is stable & complete from 2-wire/3-wire
> coexistence? The reason for this query is that I downloaded
> compat-wireless-3.6.8-1 which contains the function ath9k_start_btcoex() in
> which the Weight register is initialized. But this function is not available
> in some of the stable versions of ath9k which I am using.

Not unsurprising. ath9k's btcoex code is (relatively) recent. it
sounds like you've been using an older kernel.

> 3. What exactly are Kite and Kiwi? Are these third party modules using
> AR9287 Atheros chipsets? I did not see this in linuxwireless.org but only in
> FreeBSD.

They're chip names. AR9285 = Kite, AR9287 = Kiwi.

> 4. Just wanted to confirm if the address of the weight register that you are
> mentioning below for 2-wire coexistence is : AR_BT_COEX_WEIGHT (0x8174)

Yup. That's what it is for AR5146 -> AR9287. AR9380 changed this.

> 5. Just wanted to cross check if the weight register mentioned is for 2-wire
> coexistence? The reason for this doubt is I see bt_freq, bt_prio bits
>    in BT weight register and these bits are relevant to BT_FREQUENCY and
> BT_PRIORITY lines which are relevant for 3-wire coexistence?

The weight register is still used. I just don't quite know what the
table mapping is.

But specifically, as you're effectively trying to implement "bluetooth
stomps everything", what you really want is a table where bt wins each
round, except perhaps for beacon interval (so you send out beacons
reliably.) There should already be static stomp register values for
"BT wins all" and "Wifi wins all." That's all you should need to write
into that register.




Adrian

Re: [ath9k-devel] AR9287 ; 2-wire coexistence expected behavior

[Adrian Chadd]

hi,

I'd first double-check that you've correctly configured the btactive
GPIO pin to be an input and the mux config makes it be BT_ACTIVE.

I can't really help you more than this right now; I haven't sat down
and actually tried this. :-(

But it doesn't look like much else needs to happen besides configuring
the GPIOs right, enabling BTCOEX and setting the weights.

Thanks,


Adrian

On 7 April 2013 22:20, sandeep suresh <sandeep.suresh@yahoo.co.in> wrote:
> Hello Mr.Adrian & Mr.Sujith,
>     Started doing some experiments with different settings but there wasn't
> any good progress. Need your help further in analysis & recommendation,
> please. I monitor WLAN_ACTIVE (GPIO5) and BT_ACTIVE (GPIO6) on the
> oscilloscope. There were always a lot of pulse trains on WLAN_ACTIVE. On
> BT_ACTIVE, I initially pulled it high and also tested with a periodic pulse
> train (450ms On and 450ms Off). The following were the different settings
> with which I tested; the difference across each test case is marked in
> underline/bold:
>
> 1. In ath9k_hw_btcoex_enable_2wire(), I added the following code:
>     ath9k_hw_btcoex_set_weight(ah, AR_BT_COEX_WGHT, AR_STOMP_LOW_WLAN_WGHT);
>     REG_WRITE(ah, AR_BT_COEX_WEIGHT, btcoex_hw->bt_coex_weights);
>     Result: WLAN_ACTIVE pulse trains observed during BT_ACTIVE high.
>
> 2. In ath9k_hw_btcoex_enable_2wire(), I added the following code:
>     ath9k_hw_btcoex_set_weight(ah, AR_BT_COEX_WGHT, AR_STOMP_ALL_WLAN_WGHT);
>     REG_WRITE(ah, AR_BT_COEX_WEIGHT, btcoex_hw->bt_coex_weights);
>     Result: WLAN_ACTIVE pulse trains observed during BT_ACTIVE high.
>
> 3. In ath9k_hw_btcoex_enable_2wire(), I added the following code:
>     ath9k_hw_btcoex_set_weight(ah, 0xFFFF, 0x0000);
>     REG_WRITE(ah, AR_BT_COEX_WEIGHT, btcoex_hw->bt_coex_weights);
>     Result: WLAN_ACTIVE pulse trains observed during BT_ACTIVE high.
>
> In the next test cases, I realized that there are two registers
> (AR_BT_COEX_MODE, AR_BT_COEX_MODE2) for setting the coexistence mode. The
> following is the code and the test results:
>
> 4. In ath9k_hw_btcoex_enable_2wire(), I added the following code:
>     REG_WRITE(ah, AR_BT_COEX_MODE, btcoex_hw->bt_coex_mode);
>     REG_WRITE(ah, AR_BT_COEX_MODE2, btcoex_hw->bt_coex_mode);
>     ath9k_hw_btcoex_set_weight(ah, AR_BT_COEX_WGHT, AR_STOMP_LOW_WLAN_WGHT);
>     REG_WRITE(ah, AR_BT_COEX_WEIGHT, btcoex_hw->bt_coex_weights);
>     Result: WLAN_ACTIVE pulse trains observed during BT_ACTIVE high.
>
>
>     Result: WLAN_ACTIVE pulse trains observed during BT_ACTIVE high.
>
> 5.    Next I changed different enum for BT coex modes i.e ath_bt_mode.
> Changed from ATH_BT_COEX_MODE_SLOTTED, ATH_BT_COEX_MODE_UNSLOTTED and
> ATH_BT_COEX_MODE_LEGACY. I used again the above settings. But there still
> there were pulse trains observed.
>
> Please help to further solve these problems, please.
> Regards
> Sandeep Suresh.
> From: Adrian Chadd <adrian@freebsd.org>
> To: sandeep suresh <sandeep.suresh@yahoo.co.in>
> Cc: Sujith Manoharan <sujith@msujith.org>; ath9k-devel
> <ath9k-devel@lists.ath9k.org>; "linux-wireless@vger.kernel.org"
> <linux-wireless@vger.kernel.org>
> Sent: Sunday, 7 April 2013 11:16 PM
>
> Subject: Re: [ath9k-devel] AR9287 ; 2-wire coexistence expected behavior
>
> On 7 April 2013 07:54, sandeep suresh <sandeep.suresh@yahoo.co.in> wrote:
>> Hello Mr.Adrian and Mr.Sujith,
>>    Thanks for your responses. In order to ensure that all of us are on the
>> same page and referring to the same code base, some queries:
>>
>> 1. Please let me know you are referring to freebsd.org or
>> linuxwireless.org
>> drivers? Because you are referring to Kite & Kiwi which are in FreeBSD.
>>    FreeBSD --> http://svn.freebsd.org/base/head/sys/
>>    Ath9k --> http://linuxwireless.org/en/users/Drivers/ath9k
>>    Because currently I am using ath9k drivers only from linuxwireless.org.
>
> Kite = AR9285
> Kiwi = AR9287
>
> I know ath9k enough to be (somewhat) helpful and dangerous. But I'm
> the FreeBSD guy here; I know the HAL and FreeBSD code much better.
>
> The FreeBSD code is closer to what our reference driver does / did
> than Linux, at least for the legacy chipset support.
>
>> 2. Which version of ath9k driver is stable & complete from 2-wire/3-wire
>> coexistence? The reason for this query is that I downloaded
>> compat-wireless-3.6.8-1 which contains the function ath9k_start_btcoex()
>> in
>> which the Weight register is initialized. But this function is not
>> available
>> in some of the stable versions of ath9k which I am using.
>
> Not unsurprising. ath9k's btcoex code is (relatively) recent. it
> sounds like you've been using an older kernel.
>
>> 3. What exactly are Kite and Kiwi? Are these third party modules using
>> AR9287 Atheros chipsets? I did not see this in linuxwireless.org but only
>> in
>> FreeBSD.
>
> They're chip names. AR9285 = Kite, AR9287 = Kiwi.
>
>> 4. Just wanted to confirm if the address of the weight register that you
>> are
>> mentioning below for 2-wire coexistence is : AR_BT_COEX_WEIGHT (0x8174)
>
> Yup. That's what it is for AR5146 -> AR9287. AR9380 changed this.
>
>> 5. Just wanted to cross check if the weight register mentioned is for
>> 2-wire
>> coexistence? The reason for this doubt is I see bt_freq, bt_prio bits
>>    in BT weight register and these bits are relevant to BT_FREQUENCY and
>> BT_PRIORITY lines which are relevant for 3-wire coexistence?
>
> The weight register is still used. I just don't quite know what the
> table mapping is.
>
> But specifically, as you're effectively trying to implement "bluetooth
> stomps everything", what you really want is a table where bt wins each
> round, except perhaps for beacon interval (so you send out beacons
> reliably.) There should already be static stomp register values for
> "BT wins all" and "Wifi wins all." That's all you should need to write
> into that register.
>
>
>
>
> Adrian
>
>

Re: [ath9k-devel] AR9287 ; 2-wire coexistence expected behavior

[Adrian Chadd]

Also, I don't know why you're writing both config values out to
BTCOEX_MODE and BTCOEX_MODE2.

MODE2 has a _totally_ different register layout to AR_BT_COEX_MODE.

Please make sure you read the register definitions in the header
file(s) before you write values out. :-)



Adrian

Re: [ath9k-devel] AR9287 ; 2-wire coexistence expected behavior

[Adrian Chadd]

yes, there's GPIO MUX modes for:

* RX clear (but I think this "Wlan active" pin is likely triggering on
RX_CLEAR, which I think gets asserted for both TX and RX busy. I'll
have to check.
* TX active

Check the GPIO MUX pin definitions to see.

But if I understand this right, if you have the correct btcoex setup
and GPIO pins working, then stomping traffic will stomp both TX and
RX..


Adrian

Re: [ath9k-devel] AR9287 ; 2-wire coexistence expected behavior

[Adrian Chadd]

Hi,

Yes, "WLAN_ACTIVE" here is just both TX and RX activity.

So if it were working, that would stay low.



adrian

Re: [ath9k-devel] AR9287 ; 2-wire coexistence expected behavior

[Adrian Chadd]

Right, but same deal - if it asserts the line, it should stomp wifi
transmission in your particular scheme.



adrian


On 9 April 2013 19:37, sandeep suresh <sandeep.suresh@yahoo.co.in> wrote:
> Hello Mr.Adrian,
>     Thanks for your response. During googling, I had come across the
> following 2-wire coexistence solution from owl modules.
>
> http://support.connectblue.com/display/PRODWLAN/cB-OWL22x+Bluetooth+co-existence+application+note
> According to this application note, for 2-wire coexistence, WLAN_ACTIVE and
> BT_PRIORITY signals are used rather than WLAN_ACTIVE and BT_ACTIVE.  What is
> your opinion on this? And as I understand owl modules are based on Atheros
> chipsets.
>
> Regards
> Sandeep.
>
> From: Adrian Chadd <adrian@freebsd.org>
> To: sandeep suresh <sandeep.suresh@yahoo.co.in>
> Cc: Sujith Manoharan <sujith@msujith.org>; ath9k-devel
> <ath9k-devel@lists.ath9k.org>; "linux-wireless@vger.kernel.org"
> <linux-wireless@vger.kernel.org>
> Sent: Wednesday, 10 April 2013 4:30 AM
>
> Subject: Re: [ath9k-devel] AR9287 ; 2-wire coexistence expected behavior
>
> Hi,
>
> Yes, "WLAN_ACTIVE" here is just both TX and RX activity.
>
> So if it were working, that would stay low.
>
>
>
> adrian
>
>

Re: [ath9k-devel] AR9287 ; 2-wire coexistence expected behavior

[Adrian Chadd]

No, wifi stomping occurs with both 2-wire and 3-wire.

BT_PRIORITY just gives the MAC the ability to tell the difference
between high priority TX and any bt activity requiring the air, so the
MAC can then choose a weight based on differnet kinds of BT inputs.

If all you have is two wire, then you don't get separate weight table
entries for different kinds of BT transmissions.



adrian

On 9 April 2013 23:13, sandeep suresh <sandeep.suresh@yahoo.co.in> wrote:
> Hello Mr.Adrian,
>     Thanks for your response. I understand the following: Please correct if
> I am wrong.
> 1. With WLAN_ACTIVE and BT_ACTIVE, the wireless medium is managed between BT
> and WLAN without stomping the traffic.
> 2. With WLAN_ACTIVE, BT_ACTIVE and BT_PRIORITY, WiFI traffic stomping is
> possible.
>
> Regards
> Sandeep.
>
> From: Adrian Chadd <adrian@freebsd.org>
> To: sandeep suresh <sandeep.suresh@yahoo.co.in>
> Cc: Sujith Manoharan <sujith@msujith.org>; ath9k-devel
> <ath9k-devel@lists.ath9k.org>; "linux-wireless@vger.kernel.org"
> <linux-wireless@vger.kernel.org>
> Sent: Wednesday, 10 April 2013 11:07 AM
>
> Subject: Re: [ath9k-devel] AR9287 ; 2-wire coexistence expected behavior
>
> Right, but same deal - if it asserts the line, it should stomp wifi
> transmission in your particular scheme.
>
>
>
> adrian
>
>
> On 9 April 2013 19:37, sandeep suresh <sandeep.suresh@yahoo.co.in> wrote:
>> Hello Mr.Adrian,
>>    Thanks for your response. During googling, I had come across the
>> following 2-wire coexistence solution from owl modules.
>>
>>
>> http://support.connectblue.com/display/PRODWLAN/cB-OWL22x+Bluetooth+co-existence+application+note
>> According to this application note, for 2-wire coexistence, WLAN_ACTIVE
>> and
>> BT_PRIORITY signals are used rather than WLAN_ACTIVE and BT_ACTIVE.  What
>> is
>> your opinion on this? And as I understand owl modules are based on Atheros
>> chipsets.
>>
>> Regards
>> Sandeep.
>>
>> From: Adrian Chadd <adrian@freebsd.org>
>> To: sandeep suresh <sandeep.suresh@yahoo.co.in>
>> Cc: Sujith Manoharan <sujith@msujith.org>; ath9k-devel
>> <ath9k-devel@lists.ath9k.org>; "linux-wireless@vger.kernel.org"
>> <linux-wireless@vger.kernel.org>
>> Sent: Wednesday, 10 April 2013 4:30 AM
>>
>> Subject: Re: [ath9k-devel] AR9287 ; 2-wire coexistence expected behavior
>>
>> Hi,
>>
>> Yes, "WLAN_ACTIVE" here is just both TX and RX activity.
>>
>> So if it were working, that would stay low.
>>
>>
>>
>> adrian
>>
>>
>
>

Re: [ath9k-devel] AR9287 ; 2-wire coexistence expected behavior

[Adrian Chadd]

Hi,

Please supply the register values that you're programming in here.

Thanks,



adrian


On 15 April 2013 00:53, sandeep suresh <sandeep.suresh@yahoo.co.in> wrote:
> Hello Mr.Adrian,
>     I continued my testing with:
> 1. 2-wire coexistence mode with WLAN_ACTIVE and BT_ACTIVE lines
> 2.  Different values to the weight registers. For most of the cases I give a
> 0x0000 weightage to WLAN and 0xFFFF weightage to BT, to ensure that BT
> always gets the priority for any type of WLAN traffic.
> 3. WiFi in Access Point mode. I have connected one WiFi source (WiFi camera
> as client ) and WiFi destination (Laptop as client).
>
> I definetely see a lot of difference (based on status of WLAN_ACTIVE) with
> and without Co-existence active. Following are the observations:
> 1. Without the BT_ACTIVE signal, the WLAN traffic seems to be evenly
> distributed.
> 2. Next I duty cycle BT_ACTIVE with 100ms period, 70ms for BT and 30ms for
> WiFi. The observation is that when BT_ACTIVE is true, the WiFi activity is
> REDUCED but not completely eliminated. My understanding is that when
> BT_ACTIVE is True WLAN should show logic '0'.
>
> The following are some queries:
> a. WiFi chipset is in WiFI AP mode and WLAN_ACTIVE is True when either
> WLAN_TX or WLAN_RX is True. So are the pulses I see during BT_ACTIVE true
> are because of WLAN_RX? The following is the configuration for WLAN_ACTIVE
> gpio
>
> /* Configure the desired GPIO port for TX_FRAME output */
>  ath9k_hw_cfg_output(ah, btcoex_hw->wlanactive_gpio,
>        AR_GPIO_OUTPUT_MUX_AS_TX_FRAME);
> b. Is there a way to configure the MUX and GPIO in a manner to do some thing
> like this?
>     When WLAN_TX is active than GPIO6 is activated
>     When WLAN_RX is active than GPIO7 is activated.
> c. Or is it that I need to use 3-wire coexistence for this kind of wifi
> configuration (WiFI AP mode)?
> d. Please let me know if there is any basic mis-understanding I have?
>
> Thanks & regards
> Sandeep.
> From: Adrian Chadd <adrian@freebsd.org>
> To: sandeep suresh <sandeep.suresh@yahoo.co.in>
> Cc: Sujith Manoharan <sujith@msujith.org>; ath9k-devel
> <ath9k-devel@lists.ath9k.org>; "linux-wireless@vger.kernel.org"
> <linux-wireless@vger.kernel.org>
> Sent: Wednesday, 10 April 2013 12:52 PM
>
> Subject: Re: [ath9k-devel] AR9287 ; 2-wire coexistence expected behavior
>
> No, wifi stomping occurs with both 2-wire and 3-wire.
>
> BT_PRIORITY just gives the MAC the ability to tell the difference
> between high priority TX and any bt activity requiring the air, so the
> MAC can then choose a weight based on differnet kinds of BT inputs.
>
> If all you have is two wire, then you don't get separate weight table
> entries for different kinds of BT transmissions.
>
>
>
> adrian
>
> On 9 April 2013 23:13, sandeep suresh <sandeep.suresh@yahoo.co.in> wrote:
>> Hello Mr.Adrian,
>>    Thanks for your response. I understand the following: Please correct if
>> I am wrong.
>> 1. With WLAN_ACTIVE and BT_ACTIVE, the wireless medium is managed between
>> BT
>> and WLAN without stomping the traffic.
>> 2. With WLAN_ACTIVE, BT_ACTIVE and BT_PRIORITY, WiFI traffic stomping is
>> possible.
>>
>> Regards
>> Sandeep.
>>
>> From: Adrian Chadd <adrian@freebsd.org>
>> To: sandeep suresh <sandeep.suresh@yahoo.co.in>
>> Cc: Sujith Manoharan <sujith@msujith.org>; ath9k-devel
>> <ath9k-devel@lists.ath9k.org>; "linux-wireless@vger.kernel.org"
>> <linux-wireless@vger.kernel.org>
>> Sent: Wednesday, 10 April 2013 11:07 AM
>>
>> Subject: Re: [ath9k-devel] AR9287 ; 2-wire coexistence expected behavior
>>
>> Right, but same deal - if it asserts the line, it should stomp wifi
>> transmission in your particular scheme.
>>
>>
>>
>> adrian
>>
>>
>> On 9 April 2013 19:37, sandeep suresh <sandeep.suresh@yahoo.co.in> wrote:
>>> Hello Mr.Adrian,
>>>    Thanks for your response. During googling, I had come across the
>>> following 2-wire coexistence solution from owl modules.
>>>
>>>
>>>
>>> http://support.connectblue.com/display/PRODWLAN/cB-OWL22x+Bluetooth+co-existence+application+note
>>> According to this application note, for 2-wire coexistence, WLAN_ACTIVE
>>> and
>>> BT_PRIORITY signals are used rather than WLAN_ACTIVE and BT_ACTIVE.  What
>>> is
>>> your opinion on this? And as I understand owl modules are based on
>>> Atheros
>>> chipsets.
>>>
>>> Regards
>>> Sandeep.
>>>
>>> From: Adrian Chadd <adrian@freebsd.org>
>>> To: sandeep suresh <sandeep.suresh@yahoo.co.in>
>>> Cc: Sujith Manoharan <sujith@msujith.org>; ath9k-devel
>>> <ath9k-devel@lists.ath9k.org>; "linux-wireless@vger.kernel.org"
>>> <linux-wireless@vger.kernel.org>
>>> Sent: Wednesday, 10 April 2013 4:30 AM
>>>
>>> Subject: Re: [ath9k-devel] AR9287 ; 2-wire coexistence expected behavior
>>>
>>> Hi,
>>>
>>> Yes, "WLAN_ACTIVE" here is just both TX and RX activity.
>>>
>>> So if it were working, that would stay low.
>>>
>>>
>>>
>>> adrian
>>>
>>>
>>
>>
>
>

Re: [ath9k-devel] AR9287 ; 2-wire coexistence expected behavior

[Adrian Chadd]

... this is way way too complicated.

There's a debugfs thing (regidx/regval) that lets you read/write
individual register values.

So please dump the contents of these registers:


ar5416phy.h:#define     AR_BT_COEX_MODE            0x8170
ar5416phy.h:#define     AR_BT_COEX_WEIGHT          0x8174
ar5416phy.h:#define     AR_BT_COEX_MODE2           0x817c
ar5416reg.h:#define     AR_BT_COEX_WEIGHT2      0x81c4



adrian

Re: [ath9k-devel] AR9287 ; 2-wire coexistence expected behavior

[Adrian Chadd]

On 15 April 2013 20:55, sandeep suresh <sandeep.suresh@yahoo.co.in> wrote:
> Hello Mr.Adrian,
>     Got the debugfs working. I used the regdump under
> "/sys/kernel/debug/ieee80211/phy0/ath9k". The following are the values:
> ar5416phy.h:#define    AR_BT_COEX_MODE            0x8170        Value is:
> 0x050a5b00

How's that being set? it looks like you're enabling mode 2 (slotted)
versus 2-wire or 3-wire.

Look at the code and HAL definitions. You want 2-wire / legacy
rx_clear mode for the _MODE_ field inside AR_BT_COEX_MODE.


> ar5416phy.h:#define    AR_BT_COEX_WEIGHT          0x8174       Value is:
> 0xa8a8ff55

Double-check your weight values and make sure that they're actually
-correct- for having BT stomp wifi in all instances.



Adrian

Re: [ath9k-devel] AR9287 ; 2-wire coexistence expected behavior

[Adrian Chadd]

On 18 April 2013 03:34, sandeep suresh <sandeep.suresh@yahoo.co.in> wrote:
> Hello Mr.Adrian,
>     Yes I also fixed the weights as being reflected in the regdump register.
> Let me also try with other options for MODE register.

Ok.

> Please clarify my understanding below on rx_clear for WLAN: rx_clear is TRUE
> when any one of the following conditions are TRUE:
> a) WLAN is transmitting.
> b) WLAN is receiving.
> c) air medium is clear as per CCA assessment based on signal strength.
>
> What is the meaning of " but not a wifi signal" in your reply below?

c). If there's some strong signal in the air that exceeds the CCA
threshold but isn't a decodable wifi signal, rx_clear is cleared.




Adrian

Re: [ath9k-devel] AR9287 ; 2-wire coexistence expected behavior

[Adrian Chadd]

Hi!

On 20 May 2013 23:40, sandeep suresh <sandeep.suresh@yahoo.co.in> wrote:
> Hello Mr.Adrian,
>     Greetings! I resumed my experiments with 2-wire co-existence with AR9287
> in WiFi AP mode.
> I was able to see that WLAN_STATUS signal being suppressed when BT_ACTIVE is
> enabled. I used a 100ms On and 100ms Off (Period = 200ms; 50% dc) for
> BT_ACTIVE. Just want to confirm the following before ensuring that I am
> seeing the expected behavior:
>
Cool! Can you share some code and register settings to enable this?

> 1. As I am running the WiFi AP with co-existence, other WiFi clients are
> connected to my AP. by means of diagnsosis (I have enabled diagnosis with
> modprobe ath9k btcoex_enabled=1 diag=0xffffffff), how can I find out if any
> WiFi clients are loosing connection and re-connecting back to AP.

I think you should enable hostapd logging. That will log the MLME events.

> 2. How can I come to know if any of the beacons in WiFi AP mode are getting
> missed? Diagnosis messages that I can look at.

You can look for missed beacon transmit events. That should tell you
if you're missing beacon transmission at all.

> 3. As diagnosis is enabled I see the following....is this a concern as there
> is disable and enable of IER?
> <7>ath: disable IER
> <7>ath: AR_IMR 0x918104b0 IER 0x1
> <7>ath: tx queue 2 (4bfc09c4), link ffde09c4
> <7>ath: enable IER
> <7>ath: Enable TXE on queue: 2
> <7>ath: disable IER
> <7>ath: AR_IMR 0x918104b0 IER 0x1

That's fine. That's what ath9k does with interrupts. :-)

> 4. How can I come to know if the ath9k drivers are getting reset and
> reinitializing?

There's a hw reset routine that gets called. You can just look for the
logging from that, or add a printk() yourself.



Adrian

Re: [ath9k-devel] AR9287; WiFi AP Mode - Increase interbeacon duration of 100ms

[Ben Greear]

On 06/03/2013 03:15 AM, sandeep suresh wrote:
> Hello All,
>      Gentle reminder; really will be greatful, if you can give me some directions on this, Please.
> Regards
> Sandeep
>
> *From:* sandeep suresh <sandeep.suresh@yahoo.co.in>
> *To:* Adrian Chadd <adrian@freebsd.org>; ath9k-devel <ath9k-devel@lists.ath9k.org>
> *Cc:* "linux-wireless@vger.kernel.org" <linux-wireless@vger.kernel.org>
> *Sent:* Monday, 27 May 2013 1:40 PM
> *Subject:* AR9287; WiFi AP Mode - Increase interbeacon duration of 100ms
>
> Hello All,
>      This is regarding the inter beacon timing for AR9287 WiFi module when configured in WiFi Access Point mode. In this mode, the beacons are generated every
> 100ms by the WiFi AP. I have the following questions:
> 1. As per documentation available on the internet, the minimum inter beacon timing is 100ms. But can we increase the the inter beacon timing above this value?
> say 250ms, 500ms etc
> 2. As per standard, does increase in inter beacon time > 100ms, have any impact on the WiFi Clients connected to AR9287 WiFi AP? Even though I might test with
> some WiFi clients without any side effects but there may be some WiFi clients (which I might be unaware of )that might not work.
> 3. Has anyone attempted to do this? Please let me know if you have any observations on this?

We have been using a default of 250ms beacon timer for years in our ath9k APs.  Seems to work
just fine, but we mostly use them for internal testing with other ath9k systems acting as
the stations.

Thanks,
Ben

> Thanks & regards
> Sandeep
>
>
>
>
> _______________________________________________
> ath9k-devel mailing list
> ath9k-devel@lists.ath9k.org
> https://lists.ath9k.org/mailman/listinfo/ath9k-devel
>


-- 
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc  http://www.candelatech.com

Re: [ath9k-devel] How to prepare a 802.11 channel map with energy using ATH9K

[karl]

Sandeep:
> Thanks Karl for the detailed response...will go through it.

> Just one query....will the spectral scan work in parallel with WiFi
> AP or WiFi CLient mode?

Don't know, just found out how to do a simple scan, don't really
use wireless myself. The scanning exercise is to investigate problems
that a customer have.

> What I mean is that when the WiFi chipset (AR92xx/AR93xx) is
> operating in AP or client mode, based on request from Linux
> userspace, it should also perform a scan of the spectrum and
> return the energy values.

Wouldn't that be problematic. When you put out energy to the antenna,
do the receiver sense that, and if so wouldn't the output energy
more or less mask the input signal ?

///

Perhaps this don't need to be cross-posted.

Regards,
/Karl Hammar

-----------------------------------------------------------------------
Aspo Data
Lilla Aspo 148
S-742 94 Osthammar
Sweden
+46 173 140 57

Linux board that supports AR9287 and 7" display with ath9k support

[sandeep suresh]

Hello All,
    For performing some experiments, I want to buy a Linux development board with the following features:
Can any one suggest any specific cheap model which any one of you already have and using? Any tablets etc
a. AR9287 chipset
b. 7" display for streaming video with good resolution; e.g. 1280 x 600.
c. ath9k support for AR9287.
d. Main MCU -- which can run linux.

Thanks & regards
Sandeep.

Impact of migration from compat wireless to backports

[sandeep suresh]

Hello Mr.Adrian, Mr.Sujith & others,
       We have been asked to migrate from Compat wireless 3.1.1 to backports. When i took the differences with the latest version (3.13.2 backports) and  compat wireless 3.1.1, there were huge differences in files. From AR9287 BT Wifi 2/3 wire coexistence are there any differences in migrating to backports as I might need to restart from scratch all the efforts?
Please share if any of you had any issues.
Thanks & regards
Sandeep.

Wifi client Bluetooth coexistence; non smooth video streams

[sandeep suresh]

Dear all,
   Please help if any one have encountered simillar problems or other guidance on this, Please.

The following is my set-up:
Linksys Access point. Cisco 802.11g camera connected as a wifi client to Linksys. I have a development board in which i have AR9287 as the Wifi chipset associated as wifi client to linksys. The development board has Bluetooth dongle for streaming audio etc. The development board has a LCD display and I stream the video stream from camera at 640 x 480 resolution, MPEG-4, 10fps (also tried with 15, 30 fps).

Software: For the Wifi client on the development board, I am using the ath9k driver with btcoex_enable=1.
2-wire coexistence. I am allowing 40% of the time for Bluetooth an 60% of the time for WiFi. The period is around 200ms.

Observations: 
1. The video streams are not smooth. There will be a small pause of a second or two between frames and hence we do not see smooth transitions.
2. Sometimes it looks like, the streams are bufferred and played back at a rapid pace. So, one can see like a fast forward play of video streams on the board.
3. Disabling coexistence does not have these observations.
Please help.
Regards
Sandeep.

Re: [ath9k-devel] AR9287 ; 2-wire coexistence expected behavior

[Sujith Manoharan]

sandeep suresh wrote:
> But the question is for 2-wire coexistence, are there any weight register?

No.

> Do you know if AR9287 also supports MCI mode?

No.

Sujith

Re: [ath9k-devel] AR9287 ; 2-wire coexistence expected behavior

[Sujith Manoharan]

Sujith Manoharan wrote:
> > Do you know if AR9287 also supports MCI mode?
> 
> No.

I mean - AR9287 doesn't have MCI. :)

Sujith