Dear All, Our company ( LinoWave) build APs, and we can provide our boards to support some of the developers,(MIPS,Mem,Flash,USB,2X Serial, 32 GPIO,2 MiniPCI,5 Ethernet,POE,...) We have few Atheros MiniPCI cards but we did not select one yet.
Nick I can work on the AP mode, since we need it badly. I need some support from you but I think I can manage. Let me know How to take it from there. My Email is [EMAIL PROTECTED] Best Regards Louay [EMAIL PROTECTED] wrote: > Send ath5k-devel mailing list submissions to > ath5k-devel@lists.ath5k.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://lists.ath5k.org/mailman/listinfo/ath5k-devel > or, via email, send a message with subject or body 'help' to > [EMAIL PROTECTED] > > You can reach the person managing the list at > [EMAIL PROTECTED] > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of ath5k-devel digest..." > > > Today's Topics: > > 1. Ath5k status and todo list... (Nick Kossifidis) > 2. Re: Ath5k status and todo list... (Bob Copeland) > 3. Re: Ath5k status and todo list... (Nick Kossifidis) > 4. Re: Ath5k status and todo list... (Jeremy Apthorp) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Mon, 16 Jun 2008 19:22:29 +0300 > From: "Nick Kossifidis" <[EMAIL PROTECTED]> > Subject: [ath5k-devel] Ath5k status and todo list... > To: "ath5k mailing-list" <ath5k-devel@lists.ath5k.org> > Message-ID: > <[EMAIL PROTECTED]> > Content-Type: text/plain; charset=UTF-8 > > Here is a short list of things to be done, i work on most of them > (hw-related) but i could really use some help for the rest... > > TODO: > > Driver part > -------------- > * Process rate from descriptors (create an index with ratecodes and > rate values -check out madwifi revision 125 for an example) > * Oprofile the code and optimize > * Sparse check/cleanups > * Handle bmiss interrupts > * Add ap mode > * Add multi-queue support (wme) > * Handle gpio interrupts and integrate with rf-kill framework > * hw.c/ath5k.h cleanup led stuff and use mac80211 leds > > Hw part > ----------- > * Treat rx overrun as fatal (maybe try to clear PISR_RAC and see if it > comes again and then return fatal) > * Implement capabilities > * Split eeprom code > * Implement ANI > * Txpower set > * Power table calibration > * Work on noise floor calibration (pause tx queues, restore tx-power > -papd probe register- etc) > * Update register list on wiki from latest reg.h > * Further search for unkown registers (mostly AR5416) > * Implement rfregs functions for newer PHY chips (disassembly) > * Implement 32Khz clock setup etc (disassembly) > * Verify rest phy functions (disassembly/dumps/test) > * Verify calibration functions (disassembly/dumps/test) > * Verify noise floor related functions and implement nf_adjust > (disassembly/dumps/test) > * Finish RF2425 support (waiting for an eeepc) > * Update SREV values > > Status: > ----------- > > a) As i have mentioned on an earlier post, i've updated reg.h with > lots of registers, some of them we already knew (we set them inside > hw.c during reset), some are ANI related and come from ANI rev. > engineering (check out "tracing ANI" thread) and > if_ath_hal_extentions.h (MadWiFi) and the rest come from a memory dump > of a machine runing art (atheros radio test). They have compiled a > static table inside art with register addresses, names and shifts > (also for rf buffer), it wasn't hard to parse it (BTW if we can get an > updated memory dump of a machine runing latest art we 'll have most of > 5416 registers i guess, start looking, if you have a VxWorks atheros > ap you might have the binary inside already -we don't need it to work, > just to load so that it decompresses itself in RAM so we can get a > dump- ;-)). > > b) We have all infos needed to properly support power table > calibration for 5112 (check out latest commits on ath_info), i guess > 5112 based cards will be the first cards we are going to support 100% > (CM9 for example). Also it seems that all post 2413 have the same (or > very similar) way to calibrate the power table so if we find it we 're > practically done with power calibration. > > c) We also have card's max tx power table per rate (and that's for all > legacy cards, even those with eeprom version >= 5.0) so we can create > a function to set tx power safely. > > d) ANI is almost there ;-) > > e) There was a bug on phy calibration, we only activated calibration > during reset, not inside phy_calibrate. Also it seems that AGC_CAL bit > should be activated before enabling IQ calibration (i found a patent > that describes it nicely "Magnitude and phase imbalance calibration > and compensation in quadrature receivers"), it seems that one method > provides some parameters for the other (one of them is meant to be run > passively without disturbing rx and the other one is active and needs > to redirect rx to some other chip parts in order to get feedback) also > check out dumps from latest Sam's HAL, you'll see that it sets the bit > and checks for completion after enabling IQ calibration (as it does > during reset). Now there is an interesting point here, both AGC_CAL > and IQ calibration need the antennas attached (they need feedback from > the receiver) but AGC_NF needs to disconnect antennas. So i split > AGC_CAL + IQ from AGC_NF and we now have 2 functions, one for IQ > calibration & correction and one for Noise Floor calibration. We need > to work on the NF one because we have to stop tx queues (or pause > them) and restore tx power after (check out papd probe register). > AGC_CAL & IQ is run every 10 seconds and NF is run every 30 seconds, i > was thinking to limit NF calibrations since NF doesn't change so > frequently, how about having a minimum and a maximum value and for > every result that's the same with the previous one, we increase the > interval until we reach maximum (e.g. 60 secs) and on a different one > we reset to minimum (e.g. 30 secs) ? > > f) Rf regs functions are missing some bits. For 5111 & 5112 there are > some more parameters we should pass (also related to hal/quarter > rates). For newer chips it seems we only need to pass ob/db values > (that's why most dumps from them seem the same). > > g) Btw half/quarter rate operation is almost there, just setting a bit > in PHY_PLL and PHY_MODE does the trick, it needs some testing but > shouldn't take long ;-) > > --- > > Right now i have exams and it's really difficult for me to test and/or > provide any code snapshots/patches. When i'm done i'll upload a > tarball in kernel.org and let you know so you can test it. Until then > can someone please work on the driver related stuff mentioned above ? > > > Have fun ;-) > _______________________________________________ ath5k-devel mailing list ath5k-devel@lists.ath5k.org https://lists.ath5k.org/mailman/listinfo/ath5k-devel
