On Fri, Nov 19, 2010 at 12:52 PM, Nick Kossifidis <mickfl...@gmail.com> wrote: > 2010/11/13 Nick Kossifidis <mickfl...@gmail.com>: >> Hello people ;-) >> >> Last 2 weeks I've been working on adding half/quarter rate support and >> (static) turbo mode support on ath5k. Here is what i have so far: >> >> All 3 modes are based on the same mechanism which means changing core >> clock frequency on OFDM-only modes (we won't support dynamic turbo on >> g, only static): >> >> Turbo: 40MHz * 2 = 80MHz >> Normal: 40MHz >> Half: 40MHz / 2 = 20MHz >> Quarter: 40MHz / 4 = 10MHz >> >> Core clock is used by both PHY and MAC so we need to recalculate all timings: >> ---- >> >> Usecs/core cycles: clock frequency - 1 >> >> TX latency: default value from initvals / clock multiplier >> (1,1/2,1/4), 32 (min ?) for turbo >> >> RX latency: default value from initvals / clock multiplier, 63 (max ?) >> for half/quarter, default(37) / 2 for turbo mode >> >> Slot time: A multiplication by 2 on the core clock frequency results a >> division by ~1.5 on the slot time: >> Turbo: 6 >> Normal: 9 >> Half: 13 >> Quarter: 21 >> IFS/EIFS etc change the same way >> >> Spur mitigation parameters change (see comment inside the function for the >> algo) >> >> OFDM timings change (see comment inside the function for the algo) >> >> PHY activation to RX start delay: base value (100) + delay from >> initvals / clock multiplier >> >> Rate -> duration table needs adjustment (HAL uses computetxtime >> instead of ieee80211_generic_frame_duration, i guess we can just play >> with rate var) >> >> PLL needs different divider etc settings by using the appropriate flags >> >> >> Comparing initvals between normal and turbo modes provides some extra tweaks: >> --- >> >> On turbo mode we also need to set PHY_TURBO but on 2425, TURBO_SHORT flag is >> off >> >> On 5111 turbog we have a different AGCOARSE_LO, on the other chips >> there is no difference, I think we can ignore it, ANI will play with >> it anyway. >> >> On turbo mode we have to increase phy switch settling time to 7168 on >> 5212 and agc settling time to 37 on both 5211/5212 (newer eeproms >> provide switch settling time for turbo so we use that instead but we >> got nothing for agc settling). I guess we can use the default values >> for 5/10MHz operation. >> >> Also on turbo mode we get some extra infos from EEPROM that we must >> use for compliance with regulatory domain restrictions + >> enable/disable flags. >> >> Finaly we need to tweak power detector delays on 5111/5112 through rf >> buffer registers, set a tweaked txstart2txdata delay on 5112 and >> change a window length on PHY for 5413 (no idea what this is). >> >> It's not that complicated + since I figured out what's going on (and >> after I verified it by comparing normal and turbo mode initvals), I >> decided to drop turboa/g initvals from initvals.c, clean up the whole >> "turbo mode" mess and handle 5/10/40MHz modes in a common way. >> >> I have a patch ready but it's still messy and under testing, 5/10MHz >> seems to work but a few more tests are needed to verify constellation >> etc so that we are compatible with 802.11p specs (thanks to Ricardo >> Moreira for testing). For 40MHz operation (turbo) a few more steps are >> needed before i start testing. >> >> Give me some time and I'll get back to you with code ;-) >> > > So i verified 5/10MHz operation with a spectrum analyzer and i found > something really interesting about 40MHz operation (turbo mode). > > Here is the spectrum of a 5GHz channel > @ 5MHz... > http://www.kernel.org/pub/linux/kernel/people/mickflemm/ath5k-bwmodes/5mhz-5413.png > @10MHz... > http://www.kernel.org/pub/linux/kernel/people/mickflemm/ath5k-bwmodes/10mhz-5413.png > @40MHz with short symbols enabled (default except on AR2425)... > http://www.kernel.org/pub/linux/kernel/people/mickflemm/ath5k-bwmodes/40mhz-s-5413.png > @40MHz without short symbols... > http://www.kernel.org/pub/linux/kernel/people/mickflemm/ath5k-bwmodes/40mhz-ns-5413.png > > So turbo mode with short symbols takes up 20MHz instead of 40 ! And > it's the default ! I wonder why Atheros never mentioned that, it's > actually a very good feature as it doesn't produce extra interference > on the channel... > > Anyway I'll look more into it, for now I have a 4600+ lines patch to > split and send (it contains 5/10/40Mhz operation + lots of cleanups + > various fixes + synth-only channel change). > > Also what do you think about changing reset behavior a little bit ? > Right now we reset everything, i think we can eg. skip PCU/DMA reset > when we reset the chip for PHY calibration failures so that we don't > mess with beacon timers/queues etc, or skip PHY reset when we reset > the chip due to DMA hangs. I know it's against default practice but > why not test it ?
That sounds like great stuff. What does this look like to nl80211? Did you get the spur mitigation filters adjusted for the various modes? Are the rate tables now dependent on channel width, in addition to just the band? The CCK rates actually seem to work ok at 10MHz, but I found that the chip locks up hard if you try to do CCK on a 5MHz channel. Sadly, making the rate table depend on the channel width ended up in a whole lot of ugly when I tried that. _______________________________________________ ath5k-devel mailing list ath5k-devel@lists.ath5k.org https://lists.ath5k.org/mailman/listinfo/ath5k-devel
