2010/11/13 Nick Kossifidis <mickflemm@gmail.com>:
quoted text
> 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