2010/11/19 Nick Kossifidis <mickfl...@gmail.com>: > 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 ? >
Here you go... http://www.kernel.org/pub/linux/kernel/people/mickflemm/patches/ I'll send them tomorrow on the lists for review ;-) -- GPG ID: 0xD21DB2DB As you read this post global entropy rises. Have Fun ;-) Nick _______________________________________________ ath5k-devel mailing list ath5k-devel@lists.ath5k.org https://lists.ath5k.org/mailman/listinfo/ath5k-devel
