Hi all, The idea of correct per-packet TPC for ath9k chips has come up from time to time.
I decided to get it working on pre-AR9380 chips in FreeBSD. It already works in post-AR9380 chips in FreeBSD because I'm using the open source QCA HAL. So in case anyone wants to give it a whirl, here's what I had to do for the AR5416, AR91xx, AR92xx: Overview: * The target TX power isn't in dBm - it's an index into the TX gain table or TX powerdetector ADC (PDADC) curves. So no, '0' doesn't mean 0 dBm. * AR5416, AR9130, AR9160 - 0 (mostly) means 0 dBm in PDADC curve. * AR9280 and later - 0 means -5dBm in the PDADC curve. * HT40 mode TX need the TX power incremented by a factor (default to 2, it's in the EEPROM). * open loop power control needs an adjustment factor (again 2) for CCK rates. * You should cap the maximum TX power value per rate - so when programming in the AR_PHY_POWER_* registers, just store the per-rate maximum somewhere and cap the value at that. * Make sure you use the TPC arrays for AR5416, AR9130, AR9160. :-) Bugs: * AR9160 - if you put '0' in the TX descriptor power entry, the frame is transmitted at max TX power. So I cap pre-AR9280 chips at '1' as the minimum TX power value. Gotchas: * For PDADC curve based chips, the TX power accuracy is linked to which curve you select. The EEPROM has a bunch of different curves based on what your desired TX power range is. So if you're doing dynamic TPC, make sure you pick the right curve. You can do this by calling the TX power setup routine (as if you're doing normal fixed TX power limitations!) with the maximum TX power cap that you desire. * ACK/RTS/CTS are at a fixed, programmable TX power. Make sure you program that in correctly too. I think the pre-AR5416 (ie, pre-11n chips) have different quirks with per-packet TPC. I'll do some digging later and then give Nick some feedback. Now, luckily the logic needed in 'overview' is already in the driver - it's just used when calculating the target TX power for the per-rate TX power registers. I adapted that in the TX descriptor path in FreeBSD. It's a little sub-optimal but it works; I can easily optimise it later if anyone really cares. So, it's not that scary. It'd be good to see this in ath9k. 2c, Adrian _______________________________________________ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
