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

[ath9k-devel] 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 :-)

[ath9k-devel] 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 at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Thanks a lot Adrian !
Keep it up :-)

[ath9k-devel] Source code for Bluetooth AR3012 drivers

[sandeep suresh]

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?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ath9k.org/pipermail/ath9k-devel/attachments/20130402/1388d844/attachment.htm 

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
>

[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 at lists.ath9k.org
> https://lists.ath9k.org/mailman/listinfo/ath9k-devel
>

[ath9k-devel] Source code for Bluetooth AR3012 drivers

[sandeep suresh]

Thanks Mr.Adrian for the quick response.
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 at vger.kernel.org" <linux-wireless@vger.kernel.org> 
Sent: Tuesday, 2 April 2013 8:37 AM
Subject: Re: [ath9k-devel] Source code for Bluetooth AR3012 drivers

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 at lists.ath9k.org
> https://lists.ath9k.org/mailman/listinfo/ath9k-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ath9k.org/pipermail/ath9k-devel/attachments/20130402/f7e45649/attachment-0001.htm 

[ath9k-devel] AR9287; mapping between GPIOs and COEX pins

[sandeep suresh]

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ath9k.org/pipermail/ath9k-devel/attachments/20130402/f6fe4166/attachment.htm 

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.

[ath9k-devel] 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.

[ath9k-devel] AR9287; mapping between GPIOs and COEX pins

[sandeep suresh]

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 at 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ath9k.org/pipermail/ath9k-devel/attachments/20130402/9ed059ec/attachment-0001.htm 

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.
>
>

[ath9k-devel] 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 at 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.
>
>

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

[sandeep suresh]

Hello All,
????I started using the "default" 2-wire coexistence without making any changes in ath9k driver for AR9287. First executed "modprobe ath9k btcoex_enable = 1".I used some print statements and came to know that 2-wire initialization (ath9k_hw_btcoex_init_2wire()) and 2-wire enable? (ath9k_hw_btcoex_enable_2wire())routines were executed.
?
My understanding on 2-wire coex: Please correct me if I am wrong. When WLAN activitiy (Tx or Rx; AR9287 is 2 x 2 MIMO) is in progress, WLAN_ACTIVE is asserted. If Bluetooth wants to transmit any packets, than BT_ACTIVE line has to be asserted (pull high). Then WLAN should buffer any transmissions (however there can be receptions/ACK) and allow Bluetooth to transmit packets. AR9287 stops transmission when BT_ACTIVE is true.
?
Based on the following code snippet, from hw.c:
?
if (common->btcoex_enabled) {
??if (AR_SREV_9300_20_OR_LATER(ah)) {
???btcoex_hw->scheme = ATH_BTCOEX_CFG_3WIRE;
???btcoex_hw->btactive_gpio = ATH_BTACTIVE_GPIO_9300;
???btcoex_hw->wlanactive_gpio = ATH_WLANACTIVE_GPIO_9300;
???btcoex_hw->btpriority_gpio = ATH_BTPRIORITY_GPIO_9300;
??} else if (AR_SREV_9280_20_OR_LATER(ah)) {
???btcoex_hw->btactive_gpio = ATH_BTACTIVE_GPIO_9280;
???btcoex_hw->wlanactive_gpio = ATH_WLANACTIVE_GPIO_9280;
???if (AR_SREV_9285(ah)) {
????btcoex_hw->scheme = ATH_BTCOEX_CFG_3WIRE;
????btcoex_hw->btpriority_gpio =
??????ATH_BTPRIORITY_GPIO_9285;
???} else {
????btcoex_hw->scheme = ATH_BTCOEX_CFG_2WIRE;
???}
??}
?} else {
??btcoex_hw->scheme = ATH_BTCOEX_CFG_NONE;
?}
?
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. 
?
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?
?
Thanks & regards
Sandeep
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ath9k.org/pipermail/ath9k-devel/attachments/20130404/83212ab9/attachment.htm 

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

[ath9k-devel] 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

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

[Adrian Chadd]

Hi!

So, I've just done some further digging.

Yes, AR9285/AR9287 (and AR9380 and later) all support 2-wire and
3-wire bluetooth coexistence.

So I am gathering that the ath9k bluetooth setup code has to mostly do with:

* whether the particular combo wlan NIC has two or three wire
bluetooth coexistence wired up;
* the platform specifics about how to program the MAC bluetooth registers;
* .. and some ancillary stuff like antenna diversity on the AR9285.

I'll have to sit down with an WB195 (AR9285 + BT) and WB197 (AR9287 +
BT) to actually see how the various BT register and GPIO mux
programming works. But the code is there in freebsd and ath9k; it's
just not well documented (yet!)



Adrian

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

[sandeep suresh]

Hello Mr.Adrian,
????Thanks for your mail. Request to share more information on this as and when you discover, Please. As you mentioned below that BT code for coexistence is in freeBSD, Can you please send me the link so that I can also start digging into the code base and share to the community on my learnings? This will be a useful effort.
Thanks & regards
Sandeep


________________________________
From: Adrian Chadd <adrian@freebsd.org>
To: sandeep suresh <sandeep.suresh@yahoo.co.in> 
Cc: ath9k-devel <ath9k-devel@lists.ath9k.org> 
Sent: Friday, 5 April 2013 3:57 AM
Subject: Re: AR9287 ; 2-wire coexistence expected behavior

Hi!

So, I've just done some further digging.

Yes, AR9285/AR9287 (and AR9380 and later) all support 2-wire and
3-wire bluetooth coexistence.

So I am gathering that the ath9k bluetooth setup code has to mostly do with:

* whether the particular combo wlan NIC has two or three wire
bluetooth coexistence wired up;
* the platform specifics about how to program the MAC bluetooth registers;
* .. and some ancillary stuff like antenna diversity on the AR9285.

I'll have to sit down with an WB195 (AR9285 + BT) and WB197 (AR9287 +
BT) to actually see how the various BT register and GPIO mux
programming works. But the code is there in freebsd and ath9k; it's
just not well documented (yet!)



Adrian
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ath9k.org/pipermail/ath9k-devel/attachments/20130405/f732b5c2/attachment.htm 

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

[sandeep suresh]

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 at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ath9k.org/pipermail/ath9k-devel/attachments/20130405/6ac67952/attachment.htm 

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
>
>

[ath9k-devel] 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 at 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
>
>

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

[sandeep suresh]

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 at 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 at 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ath9k.org/pipermail/ath9k-devel/attachments/20130405/094534c4/attachment.htm 

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
>>
>>
>
>

[ath9k-devel] 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 at 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 at 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
>>
>>
>
>

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

[sandeep suresh]

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?
Regards
Sandeep


________________________________
From: Adrian Chadd <adrian@freebsd.org>
To: sandeep suresh <sandeep.suresh@yahoo.co.in> 
Cc: "linux-wireless at vger.kernel.org" <linux-wireless@vger.kernel.org>; ath9k-devel <ath9k-devel@lists.ath9k.org> 
Sent: Friday, 5 April 2013 1:47 PM
Subject: Re: AR9287 ; 2-wire coexistence expected behavior

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 at 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 at 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
>>
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ath9k.org/pipermail/ath9k-devel/attachments/20130405/77108e9d/attachment-0001.htm 

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

[ath9k-devel] 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

[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

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

[sandeep suresh]

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?
Do you know if AR9287 also supports MCI mode?
Thanks & regards
Sandeep Suresh


________________________________
From: Sujith Manoharan <sujith@msujith.org>
To: sandeep suresh <sandeep.suresh@yahoo.co.in> 
Cc: Adrian Chadd <adrian@freebsd.org>; ath9k-devel <ath9k-devel@lists.ath9k.org>; "linux-wireless at vger.kernel.org" <linux-wireless@vger.kernel.org> 
Sent: Friday, 5 April 2013 5:01 PM
Subject: Re: [ath9k-devel] AR9287 ; 2-wire coexistence expected behavior

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ath9k.org/pipermail/ath9k-devel/attachments/20130405/28d8f91f/attachment-0001.htm 

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

[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

[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

[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

[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

[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

[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

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

[sandeep suresh]

Hello Mr.Sujith,
????Thanks for your response. Based on your previous two mails, I understand the following; please correct me if I am wrong.
1. AR9287 supports a weight register for 2-wire?Coexistence.
2. AR9287 does not support MCI based coexistence.
Regards
Sandeep.


________________________________
From: Sujith Manoharan <sujith@msujith.org>
To: sandeep suresh <sandeep.suresh@yahoo.co.in> 
Cc: ath9k-devel <ath9k-devel@lists.ath9k.org>; linux-wireless at vger.kernel.org 
Sent: Sunday, 7 April 2013 1:10 AM
Subject: Re: [ath9k-devel] AR9287 ; 2-wire coexistence expected behavior

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

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

Sujith
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ath9k.org/pipermail/ath9k-devel/attachments/20130407/60def462/attachment.htm 

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

[sandeep suresh]

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.
?
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.
?
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.
?
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)
?
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?

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 at vger.kernel.org" <linux-wireless@vger.kernel.org> 
Sent: Saturday, 6 April 2013 4:06 AM
Subject: Re: [ath9k-devel] AR9287 ; 2-wire coexistence expected behavior


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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ath9k.org/pipermail/ath9k-devel/attachments/20130407/3d12c637/attachment.htm 

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

[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

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

[sandeep suresh]

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.
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




________________________________

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 at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ath9k.org/pipermail/ath9k-devel/attachments/20130408/4ca0fdc5/attachment-0001.htm 

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
>
>

[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 at 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

[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

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

[sandeep suresh]

Mr.Adrian,
????Thanks for your mail. In FreeBSD, where can I find the 2-wire/3-wire pin definitions, weight register settings, stomping etc. For AR9287, Should I need to look at AR5416 under /sys/dev/ath/ath_hal?
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 at vger.kernel.org" <linux-wireless@vger.kernel.org> 
Sent: Monday, 8 April 2013 2:30 PM
Subject: Re: [ath9k-devel] AR9287 ; 2-wire coexistence expected behavior

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ath9k.org/pipermail/ath9k-devel/attachments/20130408/04d2bb5d/attachment.htm 

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

[sandeep suresh]

Hello Mr.Adrian and Mr.Sujith,
????As I understand WLAN_ACTIVE is asserted whenever either WLAN_TX or WLAN_Rx is asserted. Hence the pulse trains that I am observing during BT_ACTIVE?asserted might be those corresponding to WLAN_RX. Hence is it possible to route the status of WLAN_TX and WLAN_RX via two separate GPIO lines for monitoring on oscilloscope rather than a single GPIO line for WLAN_ACTIVE (= WLAN_TX + WLAN_RX)?
?
Thanks & regards
Sandeep.


________________________________
From: sandeep suresh <sandeep.suresh@yahoo.co.in>
To: Adrian Chadd <adrian@freebsd.org> 
Cc: Sujith Manoharan <sujith@msujith.org>; ath9k-devel <ath9k-devel@lists.ath9k.org>; "linux-wireless at vger.kernel.org" <linux-wireless@vger.kernel.org> 
Sent: Monday, 8 April 2013 3:09 PM
Subject: Re: [ath9k-devel] AR9287 ; 2-wire coexistence expected behavior


Mr.Adrian,
????Thanks for your mail. In FreeBSD, where can I find the 2-wire/3-wire pin definitions, weight register settings, stomping etc. For AR9287, Should I need to look at AR5416 under /sys/dev/ath/ath_hal?
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 at vger.kernel.org" <linux-wireless@vger.kernel.org> 
Sent: Monday, 8 April 2013 2:30 PM
Subject: Re: [ath9k-devel] AR9287 ; 2-wire coexistence expected behavior

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ath9k.org/pipermail/ath9k-devel/attachments/20130408/731004c3/attachment.htm 

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

[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

[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

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

[sandeep suresh]

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 at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ath9k.org/pipermail/ath9k-devel/attachments/20130410/05d18aba/attachment.htm 

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
>
>

[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 at 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
>
>

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

[sandeep suresh]

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 at 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 at 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ath9k.org/pipermail/ath9k-devel/attachments/20130410/eb89df8b/attachment-0001.htm 

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
>>
>>
>
>

[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 at 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 at 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
>>
>>
>
>

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

[sandeep suresh]

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 at 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 at 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 at 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
>>
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ath9k.org/pipermail/ath9k-devel/attachments/20130415/c0b7c846/attachment-0001.htm 

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
>>>
>>>
>>
>>
>
>

[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 at 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 at 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 at 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
>>>
>>>
>>
>>
>
>

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

[sandeep suresh]

Hello Mr.Adian,
????I am using the function: So, BT always has highest?weightage (3) when compared to any of the wlan weightage (0). So the expectation is in any state of WLAN, always when BT_ACTIVE is true, then WLAN should stop either:
ath9k_hw_btcoex_set_weight(ah, 0xffff, 0x0000);
?
a.??Transmission (in my use-case transmission of video traffic from WiFi AP to Laptop client) and 
b.? Reception (in my use-case reception of video traffic from WiFi camera to WiFi AP). 
So no BT traffic is stomped.
?
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 at vger.kernel.org" <linux-wireless@vger.kernel.org> 
Sent: Monday, 15 April 2013 7:51 PM
Subject: Re: [ath9k-devel] AR9287 ; 2-wire coexistence expected behavior


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 at 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 at 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 at 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
>>>
>>>
>>
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ath9k.org/pipermail/ath9k-devel/attachments/20130415/2613ae00/attachment-0001.htm 

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

[sandeep suresh]

Hello Mr.Adrian,
?? I have not changed any of the?values used in the ath9k drivers in wireless.org apart from the weight registers which?I have given?0x0000 for WLAN and 0xFFFF for BT.
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 at vger.kernel.org" <linux-wireless@vger.kernel.org> 
Sent: Monday, 15 April 2013 7:51 PM
Subject: Re: [ath9k-devel] AR9287 ; 2-wire coexistence expected behavior


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 at 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 at 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 at 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
>>>
>>>
>>
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ath9k.org/pipermail/ath9k-devel/attachments/20130415/f84aac7c/attachment.htm 

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

[sandeep suresh]

Sorry for multiple mails. Please find all the register values and configurations. As mentioned earlier all are values as in the existing code and only weight registers have changed (0x0000 for WLAN and 0xFFFF for BT):
?
1. BT_COEX configuration:
?
??? {true, 
?? .bt_time_extend = 0, 
?? .bt_txstate_extend = 
?? .bt_txframe_extend = true, ???.bt_mode = ATH_BT_COEX_MODE_SLOTTED, ?? .bt_quiet_collision = true, ?? .bt_rxclear_polarity = true, ? .bt_priority_time = 2,
?? .bt_first_slot_time = 5,
? .bt_hold_rx_clear = 
??? };
?true,?? conststructath_btcoex_config ath_bt_config = ??? if(AR_SREV_9300_20_OR_LATER(ah)) ????? ? rxclear_polarity = !ath_bt_config.bt_rxclear_polarity;
?
??? btcoex_hw->bt_coex_mode =
??? (btcoex_hw->bt_coex_mode & AR_BT_QCU_THRESH) |
????? SM(ath_bt_config.bt_time_extend, AR_BT_TIME_EXTEND) |
????? SM(ath_bt_config.bt_txstate_extend, AR_BT_TXSTATE_EXTEND) |
??????SM(ath_bt_config.bt_txframe_extend, AR_BT_TX_FRAME_EXTEND) |
????? SM(ath_bt_config.bt_mode, AR_BT_MODE) |
????? SM(ath_bt_config.bt_quiet_collision, AR_BT_QUIET) |
????? SM(rxclear_polarity, AR_BT_RX_CLEAR_POLARITY) |
????? SM(ath_bt_config.bt_priority_time, AR_BT_PRIORITY_TIME) |
????? SM(ath_bt_config.bt_first_slot_time, AR_BT_FIRST_SLOT_TIME) |
????? SM(qnum, AR_BT_QCU_THRESH); ????? btcoex_hw->bt_coex_mode2 =
????? SM(ath_bt_config.bt_hold_rx_clear, AR_BT_HOLD_RX_CLEAR) |
????? SM(ATH_BTCOEX_BMISS_THRESH, AR_BT_BCN_MISS_THRESH) | ???? AR_BT_DISABLE_BT_ANT; 
} /* ath9k_hw_init_btcoex_hw */
?
?
2. BTCOEX initialization:/* connect bt_active to baseband */REG_CLR_BIT(ah, AR_GPIO_INPUT_EN_VAL,
(AR_GPIO_INPUT_EN_VAL_BT_PRIORITY_DEF |
AR_GPIO_INPUT_EN_VAL_BT_FREQUENCY_DEF));
REG_SET_BIT(ah, AR_GPIO_INPUT_EN_VAL,
AR_GPIO_INPUT_EN_VAL_BT_ACTIVE_BB);/* Set input mux for bt_active to gpio pin */REG_RMW_FIELD(ah, AR_GPIO_INPUT_MUX1,
AR_GPIO_INPUT_MUX1_BT_ACTIVE,
btcoex_hw->btactive_gpio);/* Configure the desired gpio port for input */ath9k_hw_cfg_gpio_input(ah, btcoex_hw->btactive_gpio);
?
3. BTCOEX Enable:REG_WRITE(ah, AR_BT_COEX_MODE, btcoex_hw->bt_coex_mode);
REG_WRITE(ah, AR_BT_COEX_MODE2, btcoex_hw->bt_coex_mode2);
REG_WRITE(ah, AR_BT_COEX_WEIGHT, btcoex_hw->bt_coex_weights);/* 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);
?
4. Weight register setting:ath9k_hw_btcoex_set_weight(ah, 0xffff,
0x0000);
?
Regards
Sandeep.?? boolrxclear_polarity = ath_bt_config.bt_rxclear_polarity;?
?
?
?
?

________________________________
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 at vger.kernel.org" <linux-wireless@vger.kernel.org> 
Sent: Monday, 15 April 2013 7:51 PM
Subject: Re: [ath9k-devel] AR9287 ; 2-wire coexistence expected behavior


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 at 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 at 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 at 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
>>>
>>>
>>
>>
>
>



txq = sc->tx.txq_map[WME_AC_BE];
ath9k_hw_init_btcoex_hw(sc->sc_ah, txq->axq_qnum);
sc->btcoex.bt_stomp_type = ATH_BTCOEX_STOMP_ALL;
?
?void ath9k_hw_init_btcoex_hw(struct ath_hw *ah, int qnum)
{
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ath9k.org/pipermail/ath9k-devel/attachments/20130416/237650a4/attachment-0001.htm 

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

[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

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

[sandeep suresh]

Hello Mr.Adrian,
????I had compiled the kernel with debug enabled for ath9k. Next I used modprobe ath9k btcoex_enable=1 debug=0xffffffff.
Where can I find the below debugfs thing as I could not see anything under:
/sys/kernel/debug/ieee80211/phy0$
Can you please send me the absolute path?
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 at vger.kernel.org" <linux-wireless@vger.kernel.org> 
Sent: Monday, 15 April 2013 11:15 PM
Subject: Re: [ath9k-devel] AR9287 ; 2-wire coexistence expected behavior


... 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ath9k.org/pipermail/ath9k-devel/attachments/20130416/3f05c39d/attachment.htm 

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

[sandeep suresh]

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
ar5416phy.h:#define? ? AR_BT_COEX_WEIGHT? ? ? ? ? 0x8174?????? Value is: 0xa8a8ff55
ar5416phy.h:#define? ? AR_BT_COEX_MODE2? ? ? ? ? 0x817c???????? Value is: 0x00110032
ar5416reg.h:#define? ? AR_BT_COEX_WEIGHT2? ? ? 0x81c4?????????? Value is: 0x00000000
?
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 at vger.kernel.org" <linux-wireless@vger.kernel.org> 
Sent: Monday, 15 April 2013 11:15 PM
Subject: Re: [ath9k-devel] AR9287 ; 2-wire coexistence expected behavior


... 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ath9k.org/pipermail/ath9k-devel/attachments/20130416/a11ea052/attachment.htm 

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

[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

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

[sandeep suresh]

Hello Mr.Adrian,
????Thanks for your observation. I changed the weight register to reflect the weightage of BT (= 0xFFFF) and WLAN(= 0x0000) ?which was verified after dumping the registers. I will try changing the mode and inform the results. What exactly is the meaning of these modes:
a) Legacy rx_clear mode
b) Untimed/unslotted mode
c) Slotted mode?
?
Thanks & 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 at vger.kernel.org" <linux-wireless@vger.kernel.org> 
Sent: Tuesday, 16 April 2013 10:30 PM
Subject: Re: [ath9k-devel] AR9287 ; 2-wire coexistence expected behavior


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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ath9k.org/pipermail/ath9k-devel/attachments/20130417/1a22c804/attachment.htm 

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

[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

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

[sandeep suresh]

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:
?
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.
?
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.
?
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
?
4. How can I come to know if the ath9k drivers are getting reset and reinitializing? 
?
Thanks & Regards
Sandeep Suresh.



________________________________
From: Adrian Chadd <adrian@freebsd.org>
To: sandeep suresh <sandeep.suresh@yahoo.co.in> 
Cc: ath9k-devel <ath9k-devel@lists.ath9k.org>; linux-wireless at vger.kernel.org 
Sent: Thursday, 18 April 2013 7:46 PM
Subject: Re: [ath9k-devel] AR9287 ; 2-wire coexistence expected behavior


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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ath9k.org/pipermail/ath9k-devel/attachments/20130521/b3a64126/attachment.htm 

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

[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

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

[sandeep suresh]

Hello Mr.Adrian,
????Thanks for your comments. 
?
In fact I have used the same ath9k code available and called the initialization for 2-wire coexistence that was missing. I will test further (the following aspects)and commit the code with some documentation so that it will be useful for the community.
?
Can you please further help me:
1. Commands to enable hostapd logging whichwill log the MLME events.
2. How can I enable missed beacon transmit events? Does it get automatically enabled during "modprobe ath9k diag=0xFFFFFFFF" ?

?
Thanks & regards
Sandeep Suresh

________________________________
From: Adrian Chadd <adrian@freebsd.org>
To: sandeep suresh <sandeep.suresh@yahoo.co.in> 
Cc: ath9k-devel <ath9k-devel@lists.ath9k.org>; "linux-wireless at vger.kernel.org" <linux-wireless@vger.kernel.org> 
Sent: Tuesday, 21 May 2013 8:03 PM
Subject: Re: [ath9k-devel] AR9287 ; 2-wire coexistence expected behavior


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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ath9k.org/pipermail/ath9k-devel/attachments/20130522/8357d8b0/attachment.htm 

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

[sandeep suresh]

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?
?
Thanks & regards
Sandeep
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ath9k.org/pipermail/ath9k-devel/attachments/20130527/ed202c27/attachment.htm 

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

[sandeep suresh]

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 at 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?
?
Thanks & regards
Sandeep
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ath9k.org/pipermail/ath9k-devel/attachments/20130603/3d2bc2de/attachment.htm 

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

[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 at 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 at lists.ath9k.org
> https://lists.ath9k.org/mailman/listinfo/ath9k-devel
>


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

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

[sandeep suresh]

Thanks Ben for this information. Can you please let me know where I can change the beacon time from 100ms to 250ms?
Thanks & regards
Sandeep.


________________________________
From: Ben Greear <greearb@candelatech.com>
To: sandeep suresh <sandeep.suresh@yahoo.co.in> 
Cc: Adrian Chadd <adrian@freebsd.org>; ath9k-devel <ath9k-devel@venema.h4ckr.net>; "linux-wireless at vger.kernel.org" <linux-wireless@vger.kernel.org> 
Sent: Monday, 3 June 2013 9:46 PM
Subject: Re: [ath9k-devel] AR9287; WiFi AP Mode - Increase interbeacon duration of 100ms


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 at 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 at lists.ath9k.org
> https://lists.ath9k.org/mailman/listinfo/ath9k-devel
>


-- 
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc? http://www.candelatech.com/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ath9k.org/pipermail/ath9k-devel/attachments/20130604/34992d52/attachment-0001.htm 

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

[sandeep suresh]

Good morning all,
????First I would like to thank once again for your help on this topic. 
I am submitting the patches/changes here; requesting again your help on merging to the mainline code. Please let me know how I can commit changes to the mainline of the code base
?
a. Changes in btcoex.c
??? Add the following lines in ath9k_hw_btcoex_enable_2wire()
?
REG_WRITE(ah, AR_BT_COEX_MODE, btcoex_hw->bt_coex_mode);
?REG_WRITE(ah, AR_BT_COEX_MODE2, btcoex_hw->bt_coex_mode2);
??? REG_WRITE(ah, AR_BT_COEX_WEIGHT, btcoex_hw->bt_coex_weights);
?
b. Changes in btcoex.c
??? In the function, ath9k_hw_btcoex_bt_stomp(), under the switch case ATH_BTCOEX_STOMP_ALL, replace the line?
?
?? ath9k_hw_btcoex_set_weight(ah, AR_BT_COEX_WGHT,? AR_STOMP_ALL_WLAN_WGHT);
?
??? with the following
?
??? ath9k_hw_btcoex_set_weight(ah, 0xffff, 0x0000);
?
Thanks & regards
Sandeep Suresh

________________________________
From: sandeep suresh <sandeep.suresh@yahoo.co.in>
To: Adrian Chadd <adrian@freebsd.org> 
Cc: ath9k-devel <ath9k-devel@lists.ath9k.org>; "linux-wireless at vger.kernel.org" <linux-wireless@vger.kernel.org> 
Sent: Wednesday, 22 May 2013 11:19 AM
Subject: Re: [ath9k-devel] AR9287 ; 2-wire coexistence expected behavior



Hello Mr.Adrian,
????Thanks for your comments. 
?
In fact I have used the same ath9k code available and called the initialization for 2-wire coexistence that was missing. I will test further (the following aspects)and commit the code with some documentation so that it will be useful for the community.
?
Can you please further help me:
1. Commands to enable hostapd logging whichwill log the MLME events.
2. How can I enable missed beacon transmit events? Does it get automatically enabled during "modprobe ath9k diag=0xFFFFFFFF" ?


Thanks & regards
Sandeep Suresh

________________________________
From: Adrian Chadd <adrian@freebsd.org>
To: sandeep suresh <sandeep.suresh@yahoo.co.in> 
Cc: ath9k-devel <ath9k-devel@lists.ath9k.org>; "linux-wireless at vger.kernel.org" <linux-wireless@vger.kernel.org> 
Sent: Tuesday, 21 May 2013 8:03 PM
Subject: Re: [ath9k-devel] AR9287 ; 2-wire coexistence expected behavior


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



_______________________________________________
ath9k-devel mailing list
ath9k-devel at lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ath9k.org/pipermail/ath9k-devel/attachments/20130625/1a10e88a/attachment.htm 

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

[Kamran Nishat]

Hi Do u know ar5416 does support Message in Message (MIM) in case of
interfering signals Carrier Sense. MIM means
 means if  a recv is looked on one packet and another packet is started
coming with higher strength.
many Atheros cards leave the weaker signal and start recv the new stronger
signal.

Kamran


On Tue, Jun 25, 2013 at 11:09 AM, sandeep suresh <sandeep.suresh@yahoo.co.in
> wrote:

> Good morning all,
>     First I would like to thank once again for your help on this topic.
> I am submitting the patches/changes here; requesting again your help on
> merging to the mainline code. Please let me know how I can commit changes
> to the mainline of the code base
>
> a. Changes in btcoex.c
>     Add the following lines in ath9k_hw_btcoex_enable_2wire()
>
> *REG_WRITE(ah, AR_BT_COEX_MODE, btcoex_hw->bt_coex_mode);
>  REG_WRITE(ah, AR_BT_COEX_MODE2, btcoex_hw->bt_coex_mode2);
>     REG_WRITE(ah, AR_BT_COEX_WEIGHT, btcoex_hw->bt_coex_weights);*
>
> b. Changes in btcoex.c
>     In the function, ath9k_hw_btcoex_bt_stomp(), under the switch case
> ATH_BTCOEX_STOMP_ALL, replace the line
>
>    *ath9k_hw_btcoex_set_weight(ah, AR_BT_COEX_WGHT,
> AR_STOMP_ALL_WLAN_WGHT);*
> **
>     with the following
>
>     *ath9k_hw_btcoex_set_weight(ah, 0xffff, 0x0000)*;
>
> Thanks & regards
> Sandeep Suresh
>   *From:* sandeep suresh <sandeep.suresh@yahoo.co.in>
> *To:* Adrian Chadd <adrian@freebsd.org>
> *Cc:* ath9k-devel <ath9k-devel@lists.ath9k.org>; "
> linux-wireless at vger.kernel.org" <linux-wireless@vger.kernel.org>
> *Sent:* Wednesday, 22 May 2013 11:19 AM
> *Subject:* Re: [ath9k-devel] AR9287 ; 2-wire coexistence expected behavior
>
>   Hello Mr.Adrian,
>     Thanks for your comments.
>
> In fact I have used the same ath9k code available and called the
> initialization for 2-wire coexistence that was missing. I will test further
> (the following aspects)and commit the code with some documentation so
> that it will be useful for the community.
>
> Can you please further help me:
> 1. Commands to enable hostapd logging whichwill log the MLME events.
> 2. How can I enable missed beacon transmit events? Does it get
> automatically enabled during "modprobe ath9k diag=0xFFFFFFFF" ?
>
> Thanks & regards
> Sandeep Suresh
>   *From:* Adrian Chadd <adrian@freebsd.org>
> *To:* sandeep suresh <sandeep.suresh@yahoo.co.in>
> *Cc:* ath9k-devel <ath9k-devel@lists.ath9k.org>; "
> linux-wireless at vger.kernel.org" <linux-wireless@vger.kernel.org>
> *Sent:* Tuesday, 21 May 2013 8:03 PM
> *Subject:* Re: [ath9k-devel] AR9287 ; 2-wire coexistence expected behavior
>
> 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
>
>
>
> _______________________________________________
> ath9k-devel mailing list
> ath9k-devel at lists.ath9k.org
> https://lists.ath9k.org/mailman/listinfo/ath9k-devel
>
>
>
> _______________________________________________
> ath9k-devel mailing list
> ath9k-devel at lists.ath9k.org
> https://lists.ath9k.org/mailman/listinfo/ath9k-devel
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ath9k.org/pipermail/ath9k-devel/attachments/20130704/25a2bee3/attachment-0001.htm 

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

[sandeep suresh]

Hello Kamran & All,
????Thanks for this information. 
Please let me know how I can commit changes to the mainline of the code base; I have the changes submitted below.
Regards
Sandeep Suresh


________________________________
From: Kamran Nishat <kamran.nishat@gmail.com>
To: 
Cc: ath9k-devel <ath9k-devel@lists.ath9k.org>; "linux-wireless at vger.kernel.org" <linux-wireless@vger.kernel.org> 
Sent: Thursday, 4 July 2013 3:54 AM
Subject: Re: [ath9k-devel] AR9287 ; 2-wire coexistence expected behavior



Hi Do u know ar5416 does support Message in Message (MIM) in case of interfering signals Carrier Sense. MIM means 
?means if ?a recv is looked on one packet and another packet is started coming with higher strength. 
many Atheros cards leave the weaker signal and start recv the new stronger signal.

Kamran




On Tue, Jun 25, 2013 at 11:09 AM, sandeep suresh <sandeep.suresh@yahoo.co.in> wrote:

Good morning all,
>????First I would like to thank once again for your help on this topic. 
>I am submitting the patches/changes here; requesting again your help on merging to the mainline code. Please let me know how I can commit changes to the mainline of the code base
>?
>a. Changes in btcoex.c
>??? Add the following lines in ath9k_hw_btcoex_enable_2wire()
>?
>REG_WRITE(ah, AR_BT_COEX_MODE, btcoex_hw->bt_coex_mode);
>?REG_WRITE(ah, AR_BT_COEX_MODE2, btcoex_hw->bt_coex_mode2);
>??? REG_WRITE(ah, AR_BT_COEX_WEIGHT, btcoex_hw->bt_coex_weights);
>?
>b. Changes in btcoex.c
>??? In the function, ath9k_hw_btcoex_bt_stomp(), under the switch case ATH_BTCOEX_STOMP_ALL, replace the line?
>?
>?? ath9k_hw_btcoex_set_weight(ah, AR_BT_COEX_WGHT,? AR_STOMP_ALL_WLAN_WGHT);
>?
>??? with the following
>?
>??? ath9k_hw_btcoex_set_weight(ah, 0xffff, 0x0000);
>
>Thanks & regards
>Sandeep Suresh
>From: sandeep suresh <sandeep.suresh@yahoo.co.in>
>To: Adrian Chadd <adrian@freebsd.org> 
>Cc: ath9k-devel <ath9k-devel@lists.ath9k.org>; "linux-wireless at vger.kernel.org" <linux-wireless@vger.kernel.org> 
>Sent: Wednesday, 22 May 2013 11:19 AM
>Subject: Re: [ath9k-devel] AR9287 ; 2-wire coexistence expected behavior
>
>
>
>Hello Mr.Adrian,
>????Thanks for your comments. 
>?
>In fact I have used the same ath9k code available and called the initialization for 2-wire coexistence that was missing. I will test further (the following aspects)and commit the code with some documentation so that it will be useful for the community.
>?
>Can you please further help me:
>1. Commands to enable hostapd logging whichwill log the MLME events.
>2. How can I enable missed beacon transmit events? Does it get automatically enabled during "modprobe ath9k diag=0xFFFFFFFF" ?
>
>
>Thanks & regards
>Sandeep Suresh
>From: Adrian Chadd <adrian@freebsd.org>
>To: sandeep suresh <sandeep.suresh@yahoo.co.in> 
>Cc: ath9k-devel <ath9k-devel@lists.ath9k.org>; "linux-wireless at vger.kernel.org" <linux-wireless@vger.kernel.org> 
>Sent: Tuesday, 21 May 2013 8:03 PM
>Subject: Re: [ath9k-devel] AR9287 ; 2-wire coexistence expected behavior
>
>
>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
>
>
>
>_______________________________________________
>ath9k-devel mailing list
>ath9k-devel at lists.ath9k.org
>https://lists.ath9k.org/mailman/listinfo/ath9k-devel
>
>
>
>_______________________________________________
>ath9k-devel mailing list
>ath9k-devel at lists.ath9k.org
>https://lists.ath9k.org/mailman/listinfo/ath9k-devel
>
>

_______________________________________________
ath9k-devel mailing list
ath9k-devel at lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ath9k.org/pipermail/ath9k-devel/attachments/20130705/8ab04ec4/attachment.htm 

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

[sandeep suresh]

Hello All,
????This is regarding?generating a 802.11 channel map with energy at periodic intervals. That means from a WiFi CLient I would like to query and retrieve the energy detected on each of the 802.11 channel from the WiFi AP and prepare a map of it. This is simillar/same as results available from a Site survey tool loke "Fluxe based WiFi Air Check meter".
Can anyone help me with the method and APIs available for the same?
Thanks in advance.
Regards
Sandeep.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ath9k.org/pipermail/ath9k-devel/attachments/20140207/863b41c5/attachment.htm 

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

[karl at aspodata.se]

Sandeep:
>?This is regarding?generating a 802.11 channel map with energy at
> periodic intervals. That means from a WiFi CLient I would like to
> query and retrieve the energy detected on each of the 802.11
> channel from the WiFi AP and prepare a map of it. This is
> simillar/same as results available from a Site survey tool loke
> "Fluxe based WiFi Air Check meter".

That functionality would be welcome. A review about Fluke's
air magnet is available at:

http://www.enterprisenetworkingplanet.com/netsysm/article.php/3652756/AirMagnets-Spectrum-Analyzer-20.htm

> Can anyone help me with the method and APIs available for the same?

 There are patches at e.g.:
http://article.gmane.org/gmane.linux.kernel.wireless.general/102332/match=spectral+scan

 The last one I have seen is
http://article.gmane.org/gmane.linux.kernel.wireless.general/117038/match=spectral+scan

 The wireless playground seem to be:
http://wireless.kernel.org/en/developers/Documentation/git-guide
git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-testing.git

 The Atheros 92xx/93xx seems to support spectral scan:
http://wireless.kernel.org/en/users/Drivers/ath9k/spectral_scan/

 To enable it look at:
http://wireless.kernel.org/en/users/Drivers/ath9k/debug

 Programs to test spectral scan with:
https://github.com/simonwunderlich/FFT_eval/
https://github.com/LorenzoBianconi/ath_spectral

 I am testing this with the kernel at:
http://turkos.aspodata.se/tmp/linux-image-3.12.8-i2-rt11_1_i386.deb

 and using the preocedure in FFT_eval/scan.sh I just got my first scan:
http://turkos.aspodata.se/tmp/ath9k_first_scan

I'm using a TP-Link TL-WDN4800 pcie card for testing.

Regards,
/Karl Hammar

-----------------------------------------------------------------------
Asp? Data
Lilla Asp? 148
S-742 94 ?sthammar
Sweden
+46 173 140 57

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

[sandeep suresh]

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?
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.
Thanks & regards
Sandeep Suresh.

From: "karl@aspodata.se" <karl@aspodata.se>
To: sandeep.suresh at yahoo.co.in 
Cc: ath9k-devel at lists.ath9k.org; linux-wireless at vger.kernel.org 
Sent: Monday, 10 February 2014 3:11 AM
Subject: Re: [ath9k-devel] How to prepare a 802.11 channel map with energy using ATH9K


Sandeep:
>?This is regarding?generating a 802.11 channel map with energy at
> periodic intervals. That means from a WiFi CLient I would like to
> query and retrieve the energy detected on each of the 802.11
> channel from the WiFi AP and prepare a map of it. This is
> simillar/same as results available from a Site survey tool loke
> "Fluxe based WiFi Air Check meter".

That functionality would be welcome. A review about Fluke's
air magnet is available at:

http://www.enterprisenetworkingplanet.com/netsysm/article.php/3652756/AirMagnets-Spectrum-Analyzer-20.htm

> Can anyone help me with the method and APIs available for the same?

There are patches at e.g.:
http://article.gmane.org/gmane.linux.kernel.wireless.general/102332/match=spectral+scan

The last one I have seen is
http://article.gmane.org/gmane.linux.kernel.wireless.general/117038/match=spectral+scan

The wireless playground seem to be:
http://wireless.kernel.org/en/developers/Documentation/git-guide
git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-testing.git

The Atheros 92xx/93xx seems to support spectral scan:
http://wireless.kernel.org/en/users/Drivers/ath9k/spectral_scan/

To enable it look at:
http://wireless.kernel.org/en/users/Drivers/ath9k/debug

Programs to test spectral scan with:
https://github.com/simonwunderlich/FFT_eval/
https://github.com/LorenzoBianconi/ath_spectral

I am testing this with the kernel at:
http://turkos.aspodata.se/tmp/linux-image-3.12.8-i2-rt11_1_i386.deb

and using the preocedure in FFT_eval/scan.sh I just got my first scan:
http://turkos.aspodata.se/tmp/ath9k_first_scan

I'm using a TP-Link TL-WDN4800 pcie card for testing. 


Regards,
/Karl Hammar

-----------------------------------------------------------------------
Asp? Data
Lilla Asp? 148
S-742 94 ?sthammar
Sweden
+46 173 140 57 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ath9k.org/pipermail/ath9k-devel/attachments/20140211/2a5f2297/attachment-0001.htm 

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

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

[karl at aspodata.se]

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.

[ath9k-devel] 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.

[ath9k-devel] 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.

[ath9k-devel] 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.