mirror of https://github.com/hak5/openwrt.git
181bc02d2e
So here is another round of improvements for MT7620 WiFi. This commit fixes a few significant issues related to TX_PWR_CFG_x and TX_ALC and also makes the code more readable by adding register descriptions for things added for MT7620 and use the usual bit-field access macros and the now defined macros instead of plain bit-ops and magic numbers. Properly describe EEPROM_TARGET_POWER at word 0x68 (== byte 0xD0) and thereby fix internal TXALC which would otherwise just read out-of-bounds of the EEPROM map. Split-out tx-power/ALC related stuff into an additional function. Fix VCO calibration, it was carried out properly in the channel switching but incomplete in the actual VCO calibration function. Also there is no need to trigger VCO calibration in channel switching, the VCO calibration function is already being called at this point. Remove it from channel switching function to avoid redundant code. The TX power calibration differs significantly from all other Mediatek/Ralink chips: They finally allow 0.5dB steps stored as 8-bit values for (almost) each bitrate -- and promptly ran out of space and for some reason didn't want to change the EEPROM layout. The hence opted for a scheme of sharing values for some adjecent bitrates and a highly over-complicated (or obfuscated?) way to populate the TX_PWR_CFG_x registers with the values stored in the EEPROM. The code here now looks much less complicated than what you see in the vendor's driver, however, it does the exact same thing: bGpwrdeltaMinus is a constant and always TRUE, hence half of the code was dead. Gpwrdelta is always 0 (rather than using the value read from the EEPROM). What remains is some very grotesque effort to avoid 0x20, probably some hardware bug related to some misunderstanding of what a singed 8-bit value is (imagine: if it was a signed 6-bit value then someone could believe that 0x20 == 0x0). And then they didn't clean it up once they later on anandonned that whole story of having a constant offset for 40 MHz channels and just set the offset to be constant 0 -- there is no effort for avoiding 0x20 for the 20 MHz values stored in the EEPROM, hence that's probably just a forbidden value in the EEPROM specs and won't appear anyway... Anyway, the whole thing felt like solving some college math test where in the end everything cancels out and the result equals 0 ;) To make sure that channel bandwidth power compensation really doesn't need to be taken care of, output a warning when the corresponding value stored in the EEPROM is non-zero. Also there is no apparent reason to refrain from initializing RFCSR register 13, it doesn't fail what-so-ever. Signed-off-by: Daniel Golle <daniel@makrotopia.org> |
||
|---|---|---|
| .. | ||
| acx-mac80211 | ||
| ar7-atm | ||
| ath10k-ct | ||
| avila-wdt | ||
| brcm2708-gpu-fw | ||
| broadcom-wl | ||
| button-hotplug | ||
| gpio-button-hotplug | ||
| gpio-nct5104d | ||
| hwmon-gsc | ||
| i2c-gpio-custom | ||
| kmod-sched-cake | ||
| lantiq | ||
| leds-apu2 | ||
| linux | ||
| mac80211 | ||
| mt76 | ||
| mwlwifi | ||
| om-watchdog | ||
| rotary-gpio-custom | ||
| rtc-rv5c386a | ||
| spi-gpio-custom | ||
| trelay | ||
| w1-gpio-custom | ||
| wrt55agv2-spidevs | ||