> 2010/11/13 Nick Kossifidis <mickflemm@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 ?
>
