Unrelated to what you hope for E-mail tips: a) don't quote everything, only relevant stuff b) don't reply to e-mail digests, a subject of "Re: [ath9k-devel] ath9k-devel Digest, Vol 58, Issue 15" is, well sorry for that word, crap
2013/4/5 anil m r <anil...@gmail.com> > hello, > > I am new to atheros driver development. could you please send me some user > guide documents to start. thanks in advance. > > Thanks & Regards, > Anil. > On Apr 5, 2013 8:55 PM, <ath9k-devel-requ...@lists.ath9k.org> wrote: > >> Send ath9k-devel mailing list submissions to >> ath9k-devel@lists.ath9k.org >> >> To subscribe or unsubscribe via the World Wide Web, visit >> https://lists.ath9k.org/mailman/listinfo/ath9k-devel >> or, via email, send a message with subject or body 'help' to >> ath9k-devel-requ...@lists.ath9k.org >> >> You can reach the person managing the list at >> ath9k-devel-ow...@lists.ath9k.org >> >> When replying, please edit your Subject line so it is more specific >> than "Re: Contents of ath9k-devel digest..." >> >> >> Today's Topics: >> >> 1. Re: AR9287 ; 2-wire coexistence expected behavior >> (Sujith Manoharan) >> 2. Re: Interpreting "link quality" of cards driven by ath9k to >> estimate usable bandwidth? (Steffen Dettmer) >> 3. Re: master firmware version bumped to 1.4; 1.3 branched >> (Eugene Krasnikov) >> 4. Re: AR9287 ; 2-wire coexistence expected behavior (sandeep suresh) >> >> >> ---------------------------------------------------------------------- >> >> Message: 1 >> Date: Fri, 5 Apr 2013 17:01:30 +0530 >> From: Sujith Manoharan <suj...@msujith.org> >> Subject: Re: [ath9k-devel] AR9287 ; 2-wire coexistence expected >> behavior >> To: sandeep suresh <sandeep.sur...@yahoo.co.in> >> Cc: ath9k-devel <ath9k-devel@lists.ath9k.org>, >> "linux-wirel...@vger.kernel.org" <linux-wirel...@vger.kernel.org> >> Message-ID: <20830.46610.23754.783...@gargle.gargle.howl> >> Content-Type: text/plain; charset=us-ascii >> >> 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 >> >> >> ------------------------------ >> >> Message: 2 >> Date: Fri, 5 Apr 2013 13:29:17 +0000 >> From: Steffen Dettmer <steffen.dett...@nomadrail.com> >> Subject: Re: [ath9k-devel] Interpreting "link quality" of cards driven >> by ath9k to estimate usable bandwidth? >> To: Holger Schurig <holgerschu...@gmail.com> >> Cc: Starschenko <alexej.starsche...@nomadrail.com>, >> "ath9k-devel@lists.ath9k.org" <ath9k-devel@lists.ath9k.org>, >> Alexej >> Message-ID: >> < >> 8c2cb2442bfddb4d95785b991b30d3463117d...@dbxprd0510mb372.eurprd05.prod.outlook.com >> > >> >> Content-Type: text/plain; charset="us-ascii" >> >> Hi, >> >> thanks a lot for your helpful mail. I made several tests and good >> progress, thanks to you :) >> >> * Holger Schurig [mailto:holgerschu...@gmail.com] wrote: >> > Hi, I wouldn't use "iwconfig" and link quality. >> > >> > "iwconfig" is outdated and virtually unmaintained since years. >> >> Ohh, good to know... it is mentioned by a lot of howtos, so I >> completely missed that it could be deprecated. >> >> > So this concept has been dropped, as far as I know. >> >> ok, I see. >> >> > If you get a fail, then maybe your distribution-provided >> > wpa_supplicant is outdated and/or using the old WEXT interface >> > as well. Find a way to use wpa_supplicant with -Dnl80211, and >> > retry. >> >> Indeed the WEXT interface was used (I guess it is default). I >> tested with -Dnl80211 and found it working, exactly as you told, >> thank you! >> >> However, if we start wpa_supplicant this way, we drop support for >> all chips not (yet) supported by nl80211 (which probably is the >> reason why it is not default), right? Are this only a few >> outdated devices? >> >> Documentation (of iw) just briefly tells "It supports all new >> drivers that have been added to the kernel recently." but does >> not tell a date. >> >> > Something that should work, even if you can't get >> > wpa_supplicant with -dnl80211 to work, is to use "iw wlan0 link": >> >> Yes, this works for me both with and without -Dnl80211, very well! >> I tested a bit monitoring this ten times per second while >> changing anntennas and so on and it looks very good and promising. >> >> It also shows the BSSID, so provides all information we need. >> >> So I think forgetting about wpa_cli but instead using iw actually >> is the right way to go here? >> >> Thanks so much for pointing me to the right direction, >> and have a nice weekend, >> >> Steffen >> >> >> >> >> ------------------------------ >> >> Message: 3 >> Date: Fri, 5 Apr 2013 16:28:43 +0200 >> From: Eugene Krasnikov <k.eugen...@gmail.com> >> Subject: Re: [ath9k-devel] master firmware version bumped to 1.4; >> 1.3 >> branched >> To: Adrian Chadd <adr...@freebsd.org> >> Cc: ath9k_htc_fw <ath9k_htc...@lists.infradead.org>, ath9k-devel >> <ath9k-devel@lists.ath9k.org> >> Message-ID: >> <CAFSJ42ajsPzoxGg-QpvOjAjCiTWAtOx1p4= >> tv_bskya7y74...@mail.gmail.com> >> Content-Type: text/plain; charset="iso-8859-1" >> >> Hi Adrian, >> >> Just to check firmware is >= 1.3 is not enough because e.g. this driver >> will try to run 3.0 firmware that is probably not compatible with this >> driver that was intended for 1.3 fw. >> >> Suggestion is to check only major version because major version is the one >> who determines if driver and firmware are compatible. What about fw == 1.x >> version? >> >> >> 2013/4/5 Adrian Chadd <adr...@freebsd.org> >> >> > Hi, >> > >> > I'd like this to be slightly different: >> > >> > * Just ensure that the firmware is >= 1.3 >> > >> > We'll make sure that the firmware doesn't break in a bad way. The >> > first set of really bad backwards compatible braking changes will kick >> > into whatever we eventually call 2.0.. >> > >> > That way we can release 1.4, 1.5, etc whilst maintaining backward >> > compatibility. >> > >> > Thanks! >> > >> > >> > Adrian >> > >> > On 4 April 2013 10:40, Eugene Krasnikov <k.eugen...@gmail.com> wrote: >> > > Hi, >> > > >> > > Finally firmware for AR7010 and AR9271 is opensourced >> > > https://github.com/KrasnikovEugene/open-ath9k-htc-firmware. >> > Unfortunately >> > > ath9k_htc driver does not support it yet because the version of >> > opensource >> > > fw is changed to 1.4. Driver must be updated to support both >> firmwares at >> > > the same time. >> > > >> > > Suggestion is to change the way driver check supported fw version like >> > this: >> > > >> > > diff --git a/drivers/net/wireless/ath/ath9k/hif_usb.h >> > > b/drivers/net/wireless/ath/ath9k/hif_usb.h >> > > index 51496e7..3edcb93 100644 >> > > --- a/drivers/net/wireless/ath/ath9k/hif_usb.h >> > > +++ b/drivers/net/wireless/ath/ath9k/hif_usb.h >> > > @@ -19,6 +19,7 @@ >> > > >> > > #define MAJOR_VERSION_REQ 1 >> > > #define MINOR_VERSION_REQ 3 >> > > +#define MINOR_VERSION_OPEN_REQ 4 >> > > >> > > #define IS_AR7010_DEVICE(_v) (((_v) == AR9280_USB) || ((_v) == >> > AR9287_USB)) >> > > >> > > diff --git a/drivers/net/wireless/ath/ath9k/htc_drv_init.c >> > > b/drivers/net/wireless/ath/ath9k/htc_drv_init.c >> > > index 716058b..7979bcf 100644 >> > > --- a/drivers/net/wireless/ath/ath9k/htc_drv_init.c >> > > +++ b/drivers/net/wireless/ath/ath9k/htc_drv_init.c >> > > @@ -796,7 +796,8 @@ static int ath9k_init_firmware_version(struct >> > > ath9k_htc_priv *priv) >> > > * required version. >> > > */ >> > > if (priv->fw_version_major != MAJOR_VERSION_REQ || >> > > - priv->fw_version_minor != MINOR_VERSION_REQ) { >> > > + (priv->fw_version_minor != MINOR_VERSION_REQ && >> > > + priv->fw_version_minor != MINOR_VERSION_OPEN_REQ)) { >> > > dev_err(priv->dev, "ath9k_htc: Please upgrade to FW version >> > > %d.%d\n", >> > > MAJOR_VERSION_REQ, MINOR_VERSION_REQ); >> > > return -EINVAL; >> > > >> > > >> > > 2013/4/1 Adrian Chadd <adr...@freebsd.org> >> > >> >> > >> HIya, >> > >> >> > >> * I've branched 1.3 off of master; >> > >> * The master firmware version for magpie/k2 is now 1.4, so ath9k_htc >> > >> will need patching; >> > >> * I've merged in the first round of build fixes. >> > >> >> > >> So! >> > >> >> > >> * Would someone please submit a fix to ath9k_htc to accept 1.3 and >> 1.4 >> > >> firmware? I don't plan on breaking the firmware API during 1.4. >> > >> * I'd really appreciate some more testing of the build fixes in >> > >> master. There's another round of changes that I'm going to review now >> > >> and I'd like to make sure we have those tested as well. >> > >> >> > >> Thanks! >> > >> >> > >> >> > >> >> > >> Adrian >> > >> >> > >> _______________________________________________ >> > >> Ath9k_htc_fw mailing list >> > >> ath9k_htc...@lists.infradead.org >> > >> http://lists.infradead.org/mailman/listinfo/ath9k_htc_fw >> > > >> > > >> > > >> > > >> > > -- >> > > Best regards, >> > > Eugene >> > >> >> >> >> -- >> Best regards, >> Eugene >> -------------- next part -------------- >> An HTML attachment was scrubbed... >> URL: >> http://lists.ath9k.org/pipermail/ath9k-devel/attachments/20130405/726dcef8/attachment-0001.htm >> >> ------------------------------ >> >> Message: 4 >> Date: Fri, 5 Apr 2013 23:24:42 +0800 (SGT) >> From: sandeep suresh <sandeep.sur...@yahoo.co.in> >> Subject: Re: [ath9k-devel] AR9287 ; 2-wire coexistence expected >> behavior >> To: Sujith Manoharan <suj...@msujith.org> >> Cc: ath9k-devel <ath9k-devel@lists.ath9k.org>, >> "linux-wirel...@vger.kernel.org" <linux-wirel...@vger.kernel.org> >> Message-ID: >> <1365175482.75704.yahoomail...@web193505.mail.sg3.yahoo.com> >> Content-Type: text/plain; charset="iso-8859-1" >> >> 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 <suj...@msujith.org> >> To: sandeep suresh <sandeep.sur...@yahoo.co.in> >> Cc: Adrian Chadd <adr...@freebsd.org>; ath9k-devel < >> ath9k-devel@lists.ath9k.org>; "linux-wirel...@vger.kernel.org" < >> linux-wirel...@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.htm >> >> ------------------------------ >> >> _______________________________________________ >> ath9k-devel mailing list >> ath9k-devel@lists.ath9k.org >> https://lists.ath9k.org/mailman/listinfo/ath9k-devel >> >> >> End of ath9k-devel Digest, Vol 58, Issue 15 >> ******************************************* >> > > _______________________________________________ > ath9k-devel mailing list > ath9k-devel@lists.ath9k.org > https://lists.ath9k.org/mailman/listinfo/ath9k-devel > >
_______________________________________________ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
