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