ExternalVendorCode/openwrt
1
0
Fork 0
mirror of https://github.com/openwrt/openwrt.git synced 2025-01-24 05:18:14 +00:00
Code Issues Actions 6 Packages Projects Releases Wiki Activity
a26f7e61e8
openwrt/package/kernel/mac80211/patches/rt2x00/996-rt2x00-mt7620-differentiate-based-on-SoC-CHIP_VER.patch

409 lines
16 KiB
Diff
Raw Normal View History

rt2x00: mt7620: differentiate based on SoC's CHIP_VER The vendor driver does things differently based on what it finds in the SoC's CHIP_VER register, which should tell whether this is MT7620N or MT7620A (PKG) and probably also the revision (VER) and most likely also something about the silicon implementer (ECO). Introduce codepaths just like the ones in the vendor driver to handle the different chips properly. Some of those paths are most likely dead code and left-overs from FPGA versions or early prototypes of the chip. It'd thus be great if people can post their kernel logs, at least the line telling the chip version and eco, so we know what's actually out there in the wild -- all I could find is [ 0.000000] SoC Type: Ralink MT7620A ver:2 eco:6 and [ 0.000000] SoC Type: Ralink MT7620N ver:2 eco:6 which would make things easier, as then we really just need to know whether it's MT7620N or MT7620A and not care about FPGA or prototypes with ver <= 1 and eco <= 2. Signed-off-by: Daniel Golle <daniel@makrotopia.org>
2017-02-05 16:55:53 +00:00
--- a/drivers/net/wireless/ralink/rt2x00/rt2800.h
+++ b/drivers/net/wireless/ralink/rt2x00/rt2800.h
mac80211: rt2x00: experimental improvements for MT7620 wifi Serge Vasilugin reports: To improve mt7620 built-in wifi performance some changes: 1. Correct BW20/BW40 switching (see comments with mark (1)) 2. Correct TX_SW_CFG1 MAC reg from v3 of vendor driver see https://gitlab.com/dm38/padavan-ng/-/blob/master/trunk/proprietary/rt_wifi/rtpci/3.0.X.X/mt76x2/chips/rt6352.c#L531 3. Set bbp66 for all chains. 4. US_CYC_CNT init based on Programming guide, default value was 33 (pci), set chipset bus clock with fallback to cpu clock/3. 5. Don't overwrite default values for mt7620. 6. Correct some typos. 7. Add support for external LNA: a) RF and BBP regs never be corrected for this mode b) eLNA is driven the same way as ePA with mt7620's pin PA but vendor driver explicitly pin PA to gpio mode (for forrect calibration?) so I'm not sure that request for pa_pin in dts-file will be enough First 5 changes (really 2) improve performance for boards w/o eLNA/ePA. Changes 7 add support for eLNA Configuration w/o eLAN/ePA and with eLNA show results tx/rx (from router point of view) for each stream: 35-40/30-35 Mbps for HT20 65-70/60-65 Mbps for HT40 Yes. Max results for 2T2R client is 140-145/135-140 with peaks 160/150, It correspond to mediatek driver results. Boards with ePA untested. Reported-by: Serge Vasilugin <vasilugin@yandex.ru> Signed-off-by: Daniel Golle <daniel@makrotopia.org> [directly include v3 of the patchset submitted upstream] (cherry picked from commit 31a6605de04218e1c04bd5c2436c24d7d1c07506) (cherry picked from commit e785ca05e9f0502894772f5df92192b816ba5d7c) (cherry picked from commit 412fcf3d4400f84551f3ead0514834c62d94a251)
2022-07-28 11:40:12 +00:00
@@ -1044,6 +1044,11 @@
rt2x00: mt7620: differentiate based on SoC's CHIP_VER The vendor driver does things differently based on what it finds in the SoC's CHIP_VER register, which should tell whether this is MT7620N or MT7620A (PKG) and probably also the revision (VER) and most likely also something about the silicon implementer (ECO). Introduce codepaths just like the ones in the vendor driver to handle the different chips properly. Some of those paths are most likely dead code and left-overs from FPGA versions or early prototypes of the chip. It'd thus be great if people can post their kernel logs, at least the line telling the chip version and eco, so we know what's actually out there in the wild -- all I could find is [ 0.000000] SoC Type: Ralink MT7620A ver:2 eco:6 and [ 0.000000] SoC Type: Ralink MT7620N ver:2 eco:6 which would make things easier, as then we really just need to know whether it's MT7620N or MT7620A and not care about FPGA or prototypes with ver <= 1 and eco <= 2. Signed-off-by: Daniel Golle <daniel@makrotopia.org>
2017-02-05 16:55:53 +00:00
#define MIMO_PS_CFG_RX_STBY_POL FIELD32(0x00000010)
#define MIMO_PS_CFG_RX_RX_STBY0 FIELD32(0x00000020)
+#define BB_PA_MODE_CFG0 0x1214
+#define BB_PA_MODE_CFG1 0x1218
+#define RF_PA_MODE_CFG0 0x121C
+#define RF_PA_MODE_CFG1 0x1220
+
/*
* EDCA_AC0_CFG:
*/
--- a/drivers/net/wireless/ralink/rt2x00/rt2800lib.c
+++ b/drivers/net/wireless/ralink/rt2x00/rt2800lib.c
mac80211: rt2x00: experimental improvements for MT7620 wifi Serge Vasilugin reports: To improve mt7620 built-in wifi performance some changes: 1. Correct BW20/BW40 switching (see comments with mark (1)) 2. Correct TX_SW_CFG1 MAC reg from v3 of vendor driver see https://gitlab.com/dm38/padavan-ng/-/blob/master/trunk/proprietary/rt_wifi/rtpci/3.0.X.X/mt76x2/chips/rt6352.c#L531 3. Set bbp66 for all chains. 4. US_CYC_CNT init based on Programming guide, default value was 33 (pci), set chipset bus clock with fallback to cpu clock/3. 5. Don't overwrite default values for mt7620. 6. Correct some typos. 7. Add support for external LNA: a) RF and BBP regs never be corrected for this mode b) eLNA is driven the same way as ePA with mt7620's pin PA but vendor driver explicitly pin PA to gpio mode (for forrect calibration?) so I'm not sure that request for pa_pin in dts-file will be enough First 5 changes (really 2) improve performance for boards w/o eLNA/ePA. Changes 7 add support for eLNA Configuration w/o eLAN/ePA and with eLNA show results tx/rx (from router point of view) for each stream: 35-40/30-35 Mbps for HT20 65-70/60-65 Mbps for HT40 Yes. Max results for 2T2R client is 140-145/135-140 with peaks 160/150, It correspond to mediatek driver results. Boards with ePA untested. Reported-by: Serge Vasilugin <vasilugin@yandex.ru> Signed-off-by: Daniel Golle <daniel@makrotopia.org> [directly include v3 of the patchset submitted upstream] (cherry picked from commit 31a6605de04218e1c04bd5c2436c24d7d1c07506) (cherry picked from commit e785ca05e9f0502894772f5df92192b816ba5d7c) (cherry picked from commit 412fcf3d4400f84551f3ead0514834c62d94a251)
2022-07-28 11:40:12 +00:00
@@ -3778,14 +3778,16 @@ static void rt2800_config_channel_rf7620
rt2x00: mt7620: differentiate based on SoC's CHIP_VER The vendor driver does things differently based on what it finds in the SoC's CHIP_VER register, which should tell whether this is MT7620N or MT7620A (PKG) and probably also the revision (VER) and most likely also something about the silicon implementer (ECO). Introduce codepaths just like the ones in the vendor driver to handle the different chips properly. Some of those paths are most likely dead code and left-overs from FPGA versions or early prototypes of the chip. It'd thus be great if people can post their kernel logs, at least the line telling the chip version and eco, so we know what's actually out there in the wild -- all I could find is [ 0.000000] SoC Type: Ralink MT7620A ver:2 eco:6 and [ 0.000000] SoC Type: Ralink MT7620N ver:2 eco:6 which would make things easier, as then we really just need to know whether it's MT7620N or MT7620A and not care about FPGA or prototypes with ver <= 1 and eco <= 2. Signed-off-by: Daniel Golle <daniel@makrotopia.org>
2017-02-05 16:55:53 +00:00
rt2x00_set_field8(&rfcsr, RFCSR19_K, rf->rf4);
rt2800_rfcsr_write(rt2x00dev, 19, rfcsr);
- /* Default: XO=20MHz , SDM mode */
- rfcsr = rt2800_rfcsr_read(rt2x00dev, 16);
- rt2x00_set_field8(&rfcsr, RFCSR16_SDM_MODE_MT7620, 0x80);
- rt2800_rfcsr_write(rt2x00dev, 16, rfcsr);
mac80211: Refresh patches again A wrong quilt configuration was used last time. Fixes: ed1e234d87fc ("mac80211: refresh patches") Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
2021-02-15 21:23:17 +00:00
-
- rfcsr = rt2800_rfcsr_read(rt2x00dev, 21);
- rt2x00_set_field8(&rfcsr, RFCSR21_BIT8, 1);
- rt2800_rfcsr_write(rt2x00dev, 21, rfcsr);
rt2x00: mt7620: differentiate based on SoC's CHIP_VER The vendor driver does things differently based on what it finds in the SoC's CHIP_VER register, which should tell whether this is MT7620N or MT7620A (PKG) and probably also the revision (VER) and most likely also something about the silicon implementer (ECO). Introduce codepaths just like the ones in the vendor driver to handle the different chips properly. Some of those paths are most likely dead code and left-overs from FPGA versions or early prototypes of the chip. It'd thus be great if people can post their kernel logs, at least the line telling the chip version and eco, so we know what's actually out there in the wild -- all I could find is [ 0.000000] SoC Type: Ralink MT7620A ver:2 eco:6 and [ 0.000000] SoC Type: Ralink MT7620N ver:2 eco:6 which would make things easier, as then we really just need to know whether it's MT7620N or MT7620A and not care about FPGA or prototypes with ver <= 1 and eco <= 2. Signed-off-by: Daniel Golle <daniel@makrotopia.org>
2017-02-05 16:55:53 +00:00
+ if (rt2800_hw_get_chipver(rt2x00dev) > 1) {
+ /* Default: XO=20MHz , SDM mode */
+ rfcsr = rt2800_rfcsr_read(rt2x00dev, 16);
+ rt2x00_set_field8(&rfcsr, RFCSR16_SDM_MODE_MT7620, 0x80);
+ rt2800_rfcsr_write(rt2x00dev, 16, rfcsr);
mac80211: Refresh patches again A wrong quilt configuration was used last time. Fixes: ed1e234d87fc ("mac80211: refresh patches") Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
2021-02-15 21:23:17 +00:00
+
rt2x00: mt7620: differentiate based on SoC's CHIP_VER The vendor driver does things differently based on what it finds in the SoC's CHIP_VER register, which should tell whether this is MT7620N or MT7620A (PKG) and probably also the revision (VER) and most likely also something about the silicon implementer (ECO). Introduce codepaths just like the ones in the vendor driver to handle the different chips properly. Some of those paths are most likely dead code and left-overs from FPGA versions or early prototypes of the chip. It'd thus be great if people can post their kernel logs, at least the line telling the chip version and eco, so we know what's actually out there in the wild -- all I could find is [ 0.000000] SoC Type: Ralink MT7620A ver:2 eco:6 and [ 0.000000] SoC Type: Ralink MT7620N ver:2 eco:6 which would make things easier, as then we really just need to know whether it's MT7620N or MT7620A and not care about FPGA or prototypes with ver <= 1 and eco <= 2. Signed-off-by: Daniel Golle <daniel@makrotopia.org>
2017-02-05 16:55:53 +00:00
+ rfcsr = rt2800_rfcsr_read(rt2x00dev, 21);
+ rt2x00_set_field8(&rfcsr, RFCSR21_BIT8, 1);
+ rt2800_rfcsr_write(rt2x00dev, 21, rfcsr);
+ }
rfcsr = rt2800_rfcsr_read(rt2x00dev, 1);
rt2x00_set_field8(&rfcsr, RFCSR1_TX2_EN_MT7620,
mac80211: rt2x00: experimental improvements for MT7620 wifi Serge Vasilugin reports: To improve mt7620 built-in wifi performance some changes: 1. Correct BW20/BW40 switching (see comments with mark (1)) 2. Correct TX_SW_CFG1 MAC reg from v3 of vendor driver see https://gitlab.com/dm38/padavan-ng/-/blob/master/trunk/proprietary/rt_wifi/rtpci/3.0.X.X/mt76x2/chips/rt6352.c#L531 3. Set bbp66 for all chains. 4. US_CYC_CNT init based on Programming guide, default value was 33 (pci), set chipset bus clock with fallback to cpu clock/3. 5. Don't overwrite default values for mt7620. 6. Correct some typos. 7. Add support for external LNA: a) RF and BBP regs never be corrected for this mode b) eLNA is driven the same way as ePA with mt7620's pin PA but vendor driver explicitly pin PA to gpio mode (for forrect calibration?) so I'm not sure that request for pa_pin in dts-file will be enough First 5 changes (really 2) improve performance for boards w/o eLNA/ePA. Changes 7 add support for eLNA Configuration w/o eLAN/ePA and with eLNA show results tx/rx (from router point of view) for each stream: 35-40/30-35 Mbps for HT20 65-70/60-65 Mbps for HT40 Yes. Max results for 2T2R client is 140-145/135-140 with peaks 160/150, It correspond to mediatek driver results. Boards with ePA untested. Reported-by: Serge Vasilugin <vasilugin@yandex.ru> Signed-off-by: Daniel Golle <daniel@makrotopia.org> [directly include v3 of the patchset submitted upstream] (cherry picked from commit 31a6605de04218e1c04bd5c2436c24d7d1c07506) (cherry picked from commit e785ca05e9f0502894772f5df92192b816ba5d7c) (cherry picked from commit 412fcf3d4400f84551f3ead0514834c62d94a251)
2022-07-28 11:40:12 +00:00
@@ -3819,18 +3821,23 @@ static void rt2800_config_channel_rf7620
rt2x00: mt7620: differentiate based on SoC's CHIP_VER The vendor driver does things differently based on what it finds in the SoC's CHIP_VER register, which should tell whether this is MT7620N or MT7620A (PKG) and probably also the revision (VER) and most likely also something about the silicon implementer (ECO). Introduce codepaths just like the ones in the vendor driver to handle the different chips properly. Some of those paths are most likely dead code and left-overs from FPGA versions or early prototypes of the chip. It'd thus be great if people can post their kernel logs, at least the line telling the chip version and eco, so we know what's actually out there in the wild -- all I could find is [ 0.000000] SoC Type: Ralink MT7620A ver:2 eco:6 and [ 0.000000] SoC Type: Ralink MT7620N ver:2 eco:6 which would make things easier, as then we really just need to know whether it's MT7620N or MT7620A and not care about FPGA or prototypes with ver <= 1 and eco <= 2. Signed-off-by: Daniel Golle <daniel@makrotopia.org>
2017-02-05 16:55:53 +00:00
rt2800_rfcsr_write_dccal(rt2x00dev, 59, 0x20);
}
- if (conf_is_ht40(conf)) {
- rt2800_rfcsr_write_dccal(rt2x00dev, 58, 0x08);
- rt2800_rfcsr_write_dccal(rt2x00dev, 59, 0x08);
- } else {
- rt2800_rfcsr_write_dccal(rt2x00dev, 58, 0x28);
- rt2800_rfcsr_write_dccal(rt2x00dev, 59, 0x28);
+ if (rt2800_hw_get_chipver(rt2x00dev) > 1) {
+ if (conf_is_ht40(conf)) {
+ rt2800_rfcsr_write_dccal(rt2x00dev, 58, 0x08);
+ rt2800_rfcsr_write_dccal(rt2x00dev, 59, 0x08);
+ } else {
+ rt2800_rfcsr_write_dccal(rt2x00dev, 58, 0x28);
+ rt2800_rfcsr_write_dccal(rt2x00dev, 59, 0x28);
+ }
}
- rfcsr = rt2800_rfcsr_read(rt2x00dev, 28);
- rt2x00_set_field8(&rfcsr, RFCSR28_CH11_HT40,
- conf_is_ht40(conf) && (rf->channel == 11));
- rt2800_rfcsr_write(rt2x00dev, 28, rfcsr);
+ if (rt2800_hw_get_chipver(rt2x00dev) > 1 &&
+ rt2800_hw_get_chipeco(rt2x00dev) == 2) {
+ rfcsr = rt2800_rfcsr_read(rt2x00dev, 28);
+ rt2x00_set_field8(&rfcsr, RFCSR28_CH11_HT40,
+ conf_is_ht40(conf) && (rf->channel == 11));
+ rt2800_rfcsr_write(rt2x00dev, 28, rfcsr);
+ }
if (!test_bit(DEVICE_STATE_SCANNING, &rt2x00dev->flags)) {
if (conf_is_ht40(conf)) {
mac80211: rt2x00: experimental improvements for MT7620 wifi Serge Vasilugin reports: To improve mt7620 built-in wifi performance some changes: 1. Correct BW20/BW40 switching (see comments with mark (1)) 2. Correct TX_SW_CFG1 MAC reg from v3 of vendor driver see https://gitlab.com/dm38/padavan-ng/-/blob/master/trunk/proprietary/rt_wifi/rtpci/3.0.X.X/mt76x2/chips/rt6352.c#L531 3. Set bbp66 for all chains. 4. US_CYC_CNT init based on Programming guide, default value was 33 (pci), set chipset bus clock with fallback to cpu clock/3. 5. Don't overwrite default values for mt7620. 6. Correct some typos. 7. Add support for external LNA: a) RF and BBP regs never be corrected for this mode b) eLNA is driven the same way as ePA with mt7620's pin PA but vendor driver explicitly pin PA to gpio mode (for forrect calibration?) so I'm not sure that request for pa_pin in dts-file will be enough First 5 changes (really 2) improve performance for boards w/o eLNA/ePA. Changes 7 add support for eLNA Configuration w/o eLAN/ePA and with eLNA show results tx/rx (from router point of view) for each stream: 35-40/30-35 Mbps for HT20 65-70/60-65 Mbps for HT40 Yes. Max results for 2T2R client is 140-145/135-140 with peaks 160/150, It correspond to mediatek driver results. Boards with ePA untested. Reported-by: Serge Vasilugin <vasilugin@yandex.ru> Signed-off-by: Daniel Golle <daniel@makrotopia.org> [directly include v3 of the patchset submitted upstream] (cherry picked from commit 31a6605de04218e1c04bd5c2436c24d7d1c07506) (cherry picked from commit e785ca05e9f0502894772f5df92192b816ba5d7c) (cherry picked from commit 412fcf3d4400f84551f3ead0514834c62d94a251)
2022-07-28 11:40:12 +00:00
@@ -3929,25 +3936,29 @@ static void rt2800_config_alc(struct rt2
if (unlikely(rt2800_wait_bbp_rf_ready(rt2x00dev, MAC_STATUS_CFG_BBP_RF_BUSY)))
rt2x00_warn(rt2x00dev, "RF busy while configuring ALC\n");
rt2x00: mt7620: differentiate based on SoC's CHIP_VER The vendor driver does things differently based on what it finds in the SoC's CHIP_VER register, which should tell whether this is MT7620N or MT7620A (PKG) and probably also the revision (VER) and most likely also something about the silicon implementer (ECO). Introduce codepaths just like the ones in the vendor driver to handle the different chips properly. Some of those paths are most likely dead code and left-overs from FPGA versions or early prototypes of the chip. It'd thus be great if people can post their kernel logs, at least the line telling the chip version and eco, so we know what's actually out there in the wild -- all I could find is [ 0.000000] SoC Type: Ralink MT7620A ver:2 eco:6 and [ 0.000000] SoC Type: Ralink MT7620N ver:2 eco:6 which would make things easier, as then we really just need to know whether it's MT7620N or MT7620A and not care about FPGA or prototypes with ver <= 1 and eco <= 2. Signed-off-by: Daniel Golle <daniel@makrotopia.org>
2017-02-05 16:55:53 +00:00
- if (chan->center_freq > 2457) {
- bbp = rt2800_bbp_read(rt2x00dev, 30);
- bbp = 0x40;
- rt2800_bbp_write(rt2x00dev, 30, bbp);
- rt2800_rfcsr_write(rt2x00dev, 39, 0);
- if (rt2x00_has_cap_external_lna_bg(rt2x00dev))
- rt2800_rfcsr_write(rt2x00dev, 42, 0xfb);
- else
- rt2800_rfcsr_write(rt2x00dev, 42, 0x7b);
- } else {
- bbp = rt2800_bbp_read(rt2x00dev, 30);
- bbp = 0x1f;
- rt2800_bbp_write(rt2x00dev, 30, bbp);
- rt2800_rfcsr_write(rt2x00dev, 39, 0x80);
- if (rt2x00_has_cap_external_lna_bg(rt2x00dev))
- rt2800_rfcsr_write(rt2x00dev, 42, 0xdb);
- else
- rt2800_rfcsr_write(rt2x00dev, 42, 0x5b);
+ if (rt2800_hw_get_chipver(rt2x00dev) > 1 &&
+ rt2800_hw_get_chipeco(rt2x00dev) >= 2) {
+ if (chan->center_freq > 2457) {
+ bbp = rt2800_bbp_read(rt2x00dev, 30);
+ bbp = 0x40;
+ rt2800_bbp_write(rt2x00dev, 30, bbp);
+ rt2800_rfcsr_write(rt2x00dev, 39, 0);
+ if (rt2x00_has_cap_external_lna_bg(rt2x00dev))
+ rt2800_rfcsr_write(rt2x00dev, 42, 0xfb);
+ else
+ rt2800_rfcsr_write(rt2x00dev, 42, 0x7b);
+ } else {
+ bbp = rt2800_bbp_read(rt2x00dev, 30);
+ bbp = 0x1f;
+ rt2800_bbp_write(rt2x00dev, 30, bbp);
+ rt2800_rfcsr_write(rt2x00dev, 39, 0x80);
+ if (rt2x00_has_cap_external_lna_bg(rt2x00dev))
+ rt2800_rfcsr_write(rt2x00dev, 42, 0xdb);
+ else
+ rt2800_rfcsr_write(rt2x00dev, 42, 0x5b);
+ }
}
+
rt2800_register_write(rt2x00dev, MAC_SYS_CTRL, mac_sys_ctrl);
rt2800_vco_calibration(rt2x00dev);
mac80211: rt2x00: experimental improvements for MT7620 wifi Serge Vasilugin reports: To improve mt7620 built-in wifi performance some changes: 1. Correct BW20/BW40 switching (see comments with mark (1)) 2. Correct TX_SW_CFG1 MAC reg from v3 of vendor driver see https://gitlab.com/dm38/padavan-ng/-/blob/master/trunk/proprietary/rt_wifi/rtpci/3.0.X.X/mt76x2/chips/rt6352.c#L531 3. Set bbp66 for all chains. 4. US_CYC_CNT init based on Programming guide, default value was 33 (pci), set chipset bus clock with fallback to cpu clock/3. 5. Don't overwrite default values for mt7620. 6. Correct some typos. 7. Add support for external LNA: a) RF and BBP regs never be corrected for this mode b) eLNA is driven the same way as ePA with mt7620's pin PA but vendor driver explicitly pin PA to gpio mode (for forrect calibration?) so I'm not sure that request for pa_pin in dts-file will be enough First 5 changes (really 2) improve performance for boards w/o eLNA/ePA. Changes 7 add support for eLNA Configuration w/o eLAN/ePA and with eLNA show results tx/rx (from router point of view) for each stream: 35-40/30-35 Mbps for HT20 65-70/60-65 Mbps for HT40 Yes. Max results for 2T2R client is 140-145/135-140 with peaks 160/150, It correspond to mediatek driver results. Boards with ePA untested. Reported-by: Serge Vasilugin <vasilugin@yandex.ru> Signed-off-by: Daniel Golle <daniel@makrotopia.org> [directly include v3 of the patchset submitted upstream] (cherry picked from commit 31a6605de04218e1c04bd5c2436c24d7d1c07506) (cherry picked from commit e785ca05e9f0502894772f5df92192b816ba5d7c) (cherry picked from commit 412fcf3d4400f84551f3ead0514834c62d94a251)
2022-07-28 11:40:12 +00:00
@@ -6011,18 +6022,33 @@ static int rt2800_init_registers(struct
rt2x00: mt7620: differentiate based on SoC's CHIP_VER The vendor driver does things differently based on what it finds in the SoC's CHIP_VER register, which should tell whether this is MT7620N or MT7620A (PKG) and probably also the revision (VER) and most likely also something about the silicon implementer (ECO). Introduce codepaths just like the ones in the vendor driver to handle the different chips properly. Some of those paths are most likely dead code and left-overs from FPGA versions or early prototypes of the chip. It'd thus be great if people can post their kernel logs, at least the line telling the chip version and eco, so we know what's actually out there in the wild -- all I could find is [ 0.000000] SoC Type: Ralink MT7620A ver:2 eco:6 and [ 0.000000] SoC Type: Ralink MT7620N ver:2 eco:6 which would make things easier, as then we really just need to know whether it's MT7620N or MT7620A and not care about FPGA or prototypes with ver <= 1 and eco <= 2. Signed-off-by: Daniel Golle <daniel@makrotopia.org>
2017-02-05 16:55:53 +00:00
} else if (rt2x00_rt(rt2x00dev, RT5350)) {
rt2800_register_write(rt2x00dev, TX_SW_CFG0, 0x00000404);
} else if (rt2x00_rt(rt2x00dev, RT6352)) {
- rt2800_register_write(rt2x00dev, TX_SW_CFG0, 0x00000401);
mac80211: rt2x00: experimental improvements for MT7620 wifi Serge Vasilugin reports: To improve mt7620 built-in wifi performance some changes: 1. Correct BW20/BW40 switching (see comments with mark (1)) 2. Correct TX_SW_CFG1 MAC reg from v3 of vendor driver see https://gitlab.com/dm38/padavan-ng/-/blob/master/trunk/proprietary/rt_wifi/rtpci/3.0.X.X/mt76x2/chips/rt6352.c#L531 3. Set bbp66 for all chains. 4. US_CYC_CNT init based on Programming guide, default value was 33 (pci), set chipset bus clock with fallback to cpu clock/3. 5. Don't overwrite default values for mt7620. 6. Correct some typos. 7. Add support for external LNA: a) RF and BBP regs never be corrected for this mode b) eLNA is driven the same way as ePA with mt7620's pin PA but vendor driver explicitly pin PA to gpio mode (for forrect calibration?) so I'm not sure that request for pa_pin in dts-file will be enough First 5 changes (really 2) improve performance for boards w/o eLNA/ePA. Changes 7 add support for eLNA Configuration w/o eLAN/ePA and with eLNA show results tx/rx (from router point of view) for each stream: 35-40/30-35 Mbps for HT20 65-70/60-65 Mbps for HT40 Yes. Max results for 2T2R client is 140-145/135-140 with peaks 160/150, It correspond to mediatek driver results. Boards with ePA untested. Reported-by: Serge Vasilugin <vasilugin@yandex.ru> Signed-off-by: Daniel Golle <daniel@makrotopia.org> [directly include v3 of the patchset submitted upstream] (cherry picked from commit 31a6605de04218e1c04bd5c2436c24d7d1c07506) (cherry picked from commit e785ca05e9f0502894772f5df92192b816ba5d7c) (cherry picked from commit 412fcf3d4400f84551f3ead0514834c62d94a251)
2022-07-28 11:40:12 +00:00
- rt2800_register_write(rt2x00dev, TX_SW_CFG1, 0x000C0001);
rt2x00: mt7620: differentiate based on SoC's CHIP_VER The vendor driver does things differently based on what it finds in the SoC's CHIP_VER register, which should tell whether this is MT7620N or MT7620A (PKG) and probably also the revision (VER) and most likely also something about the silicon implementer (ECO). Introduce codepaths just like the ones in the vendor driver to handle the different chips properly. Some of those paths are most likely dead code and left-overs from FPGA versions or early prototypes of the chip. It'd thus be great if people can post their kernel logs, at least the line telling the chip version and eco, so we know what's actually out there in the wild -- all I could find is [ 0.000000] SoC Type: Ralink MT7620A ver:2 eco:6 and [ 0.000000] SoC Type: Ralink MT7620N ver:2 eco:6 which would make things easier, as then we really just need to know whether it's MT7620N or MT7620A and not care about FPGA or prototypes with ver <= 1 and eco <= 2. Signed-off-by: Daniel Golle <daniel@makrotopia.org>
2017-02-05 16:55:53 +00:00
- rt2800_register_write(rt2x00dev, TX_SW_CFG2, 0x00000000);
- rt2800_register_write(rt2x00dev, TX_ALC_VGA3, 0x00000000);
- rt2800_register_write(rt2x00dev, TX0_BB_GAIN_ATTEN, 0x0);
- rt2800_register_write(rt2x00dev, TX1_BB_GAIN_ATTEN, 0x0);
- rt2800_register_write(rt2x00dev, TX0_RF_GAIN_ATTEN, 0x6C6C666C);
- rt2800_register_write(rt2x00dev, TX1_RF_GAIN_ATTEN, 0x6C6C666C);
- rt2800_register_write(rt2x00dev, TX0_RF_GAIN_CORRECT,
- 0x3630363A);
- rt2800_register_write(rt2x00dev, TX1_RF_GAIN_CORRECT,
- 0x3630363A);
+ if (rt2800_hw_get_chipver(rt2x00dev) <= 1) {
+ rt2800_register_write(rt2x00dev, TX_ALC_VGA3,
+ 0x00000000);
+ rt2800_register_write(rt2x00dev, BB_PA_MODE_CFG0,
+ 0x000055FF);
+ rt2800_register_write(rt2x00dev, BB_PA_MODE_CFG1,
+ 0x00550055);
+ rt2800_register_write(rt2x00dev, RF_PA_MODE_CFG0,
+ 0x000055FF);
+ rt2800_register_write(rt2x00dev, RF_PA_MODE_CFG1,
+ 0x00550055);
+ } else {
+ rt2800_register_write(rt2x00dev, TX_SW_CFG0, 0x00000401);
mac80211: rt2x00: experimental improvements for MT7620 wifi Serge Vasilugin reports: To improve mt7620 built-in wifi performance some changes: 1. Correct BW20/BW40 switching (see comments with mark (1)) 2. Correct TX_SW_CFG1 MAC reg from v3 of vendor driver see https://gitlab.com/dm38/padavan-ng/-/blob/master/trunk/proprietary/rt_wifi/rtpci/3.0.X.X/mt76x2/chips/rt6352.c#L531 3. Set bbp66 for all chains. 4. US_CYC_CNT init based on Programming guide, default value was 33 (pci), set chipset bus clock with fallback to cpu clock/3. 5. Don't overwrite default values for mt7620. 6. Correct some typos. 7. Add support for external LNA: a) RF and BBP regs never be corrected for this mode b) eLNA is driven the same way as ePA with mt7620's pin PA but vendor driver explicitly pin PA to gpio mode (for forrect calibration?) so I'm not sure that request for pa_pin in dts-file will be enough First 5 changes (really 2) improve performance for boards w/o eLNA/ePA. Changes 7 add support for eLNA Configuration w/o eLAN/ePA and with eLNA show results tx/rx (from router point of view) for each stream: 35-40/30-35 Mbps for HT20 65-70/60-65 Mbps for HT40 Yes. Max results for 2T2R client is 140-145/135-140 with peaks 160/150, It correspond to mediatek driver results. Boards with ePA untested. Reported-by: Serge Vasilugin <vasilugin@yandex.ru> Signed-off-by: Daniel Golle <daniel@makrotopia.org> [directly include v3 of the patchset submitted upstream] (cherry picked from commit 31a6605de04218e1c04bd5c2436c24d7d1c07506) (cherry picked from commit e785ca05e9f0502894772f5df92192b816ba5d7c) (cherry picked from commit 412fcf3d4400f84551f3ead0514834c62d94a251)
2022-07-28 11:40:12 +00:00
+ rt2800_register_write(rt2x00dev, TX_SW_CFG1, 0x000C0001);
rt2x00: mt7620: differentiate based on SoC's CHIP_VER The vendor driver does things differently based on what it finds in the SoC's CHIP_VER register, which should tell whether this is MT7620N or MT7620A (PKG) and probably also the revision (VER) and most likely also something about the silicon implementer (ECO). Introduce codepaths just like the ones in the vendor driver to handle the different chips properly. Some of those paths are most likely dead code and left-overs from FPGA versions or early prototypes of the chip. It'd thus be great if people can post their kernel logs, at least the line telling the chip version and eco, so we know what's actually out there in the wild -- all I could find is [ 0.000000] SoC Type: Ralink MT7620A ver:2 eco:6 and [ 0.000000] SoC Type: Ralink MT7620N ver:2 eco:6 which would make things easier, as then we really just need to know whether it's MT7620N or MT7620A and not care about FPGA or prototypes with ver <= 1 and eco <= 2. Signed-off-by: Daniel Golle <daniel@makrotopia.org>
2017-02-05 16:55:53 +00:00
+ rt2800_register_write(rt2x00dev, TX_SW_CFG2, 0x00000000);
+ rt2800_register_write(rt2x00dev, TX_ALC_VGA3, 0x00000000);
+ rt2800_register_write(rt2x00dev, TX0_BB_GAIN_ATTEN, 0x0);
+ rt2800_register_write(rt2x00dev, TX1_BB_GAIN_ATTEN, 0x0);
+ rt2800_register_write(rt2x00dev, TX0_RF_GAIN_ATTEN,
+ 0x6C6C666C);
+ rt2800_register_write(rt2x00dev, TX1_RF_GAIN_ATTEN,
+ 0x6C6C666C);
+ rt2800_register_write(rt2x00dev, TX0_RF_GAIN_CORRECT,
+ 0x3630363A);
+ rt2800_register_write(rt2x00dev, TX1_RF_GAIN_CORRECT,
+ 0x3630363A);
+ }
reg = rt2800_register_read(rt2x00dev, TX_ALC_CFG_1);
rt2x00_set_field32(&reg, TX_ALC_CFG_1_ROS_BUSY_EN, 0);
rt2800_register_write(rt2x00dev, TX_ALC_CFG_1, reg);
mac80211: rt2x00: experimental improvements for MT7620 wifi Serge Vasilugin reports: To improve mt7620 built-in wifi performance some changes: 1. Correct BW20/BW40 switching (see comments with mark (1)) 2. Correct TX_SW_CFG1 MAC reg from v3 of vendor driver see https://gitlab.com/dm38/padavan-ng/-/blob/master/trunk/proprietary/rt_wifi/rtpci/3.0.X.X/mt76x2/chips/rt6352.c#L531 3. Set bbp66 for all chains. 4. US_CYC_CNT init based on Programming guide, default value was 33 (pci), set chipset bus clock with fallback to cpu clock/3. 5. Don't overwrite default values for mt7620. 6. Correct some typos. 7. Add support for external LNA: a) RF and BBP regs never be corrected for this mode b) eLNA is driven the same way as ePA with mt7620's pin PA but vendor driver explicitly pin PA to gpio mode (for forrect calibration?) so I'm not sure that request for pa_pin in dts-file will be enough First 5 changes (really 2) improve performance for boards w/o eLNA/ePA. Changes 7 add support for eLNA Configuration w/o eLAN/ePA and with eLNA show results tx/rx (from router point of view) for each stream: 35-40/30-35 Mbps for HT20 65-70/60-65 Mbps for HT40 Yes. Max results for 2T2R client is 140-145/135-140 with peaks 160/150, It correspond to mediatek driver results. Boards with ePA untested. Reported-by: Serge Vasilugin <vasilugin@yandex.ru> Signed-off-by: Daniel Golle <daniel@makrotopia.org> [directly include v3 of the patchset submitted upstream] (cherry picked from commit 31a6605de04218e1c04bd5c2436c24d7d1c07506) (cherry picked from commit e785ca05e9f0502894772f5df92192b816ba5d7c) (cherry picked from commit 412fcf3d4400f84551f3ead0514834c62d94a251)
2022-07-28 11:40:12 +00:00
@@ -7127,14 +7153,16 @@ static void rt2800_init_bbp_6352(struct
rt2x00: mt7620: differentiate based on SoC's CHIP_VER The vendor driver does things differently based on what it finds in the SoC's CHIP_VER register, which should tell whether this is MT7620N or MT7620A (PKG) and probably also the revision (VER) and most likely also something about the silicon implementer (ECO). Introduce codepaths just like the ones in the vendor driver to handle the different chips properly. Some of those paths are most likely dead code and left-overs from FPGA versions or early prototypes of the chip. It'd thus be great if people can post their kernel logs, at least the line telling the chip version and eco, so we know what's actually out there in the wild -- all I could find is [ 0.000000] SoC Type: Ralink MT7620A ver:2 eco:6 and [ 0.000000] SoC Type: Ralink MT7620N ver:2 eco:6 which would make things easier, as then we really just need to know whether it's MT7620N or MT7620A and not care about FPGA or prototypes with ver <= 1 and eco <= 2. Signed-off-by: Daniel Golle <daniel@makrotopia.org>
2017-02-05 16:55:53 +00:00
rt2800_bbp_write(rt2x00dev, 188, 0x00);
rt2800_bbp_write(rt2x00dev, 189, 0x00);
- rt2800_bbp_write(rt2x00dev, 91, 0x06);
- rt2800_bbp_write(rt2x00dev, 92, 0x04);
- rt2800_bbp_write(rt2x00dev, 93, 0x54);
- rt2800_bbp_write(rt2x00dev, 99, 0x50);
- rt2800_bbp_write(rt2x00dev, 148, 0x84);
- rt2800_bbp_write(rt2x00dev, 167, 0x80);
- rt2800_bbp_write(rt2x00dev, 178, 0xFF);
- rt2800_bbp_write(rt2x00dev, 106, 0x13);
+ if (rt2800_hw_get_chipver(rt2x00dev) > 1) {
+ rt2800_bbp_write(rt2x00dev, 91, 0x06);
+ rt2800_bbp_write(rt2x00dev, 92, 0x04);
+ rt2800_bbp_write(rt2x00dev, 93, 0x54);
+ rt2800_bbp_write(rt2x00dev, 99, 0x50);
+ rt2800_bbp_write(rt2x00dev, 148, 0x84);
+ rt2800_bbp_write(rt2x00dev, 167, 0x80);
+ rt2800_bbp_write(rt2x00dev, 178, 0xFF);
+ rt2800_bbp_write(rt2x00dev, 106, 0x13);
+ }
/* BBP for G band GLRT function (BBP_128 ~ BBP_221) */
rt2800_bbp_glrt_write(rt2x00dev, 0, 0x00);
mac80211: rt2x00: experimental improvements for MT7620 wifi Serge Vasilugin reports: To improve mt7620 built-in wifi performance some changes: 1. Correct BW20/BW40 switching (see comments with mark (1)) 2. Correct TX_SW_CFG1 MAC reg from v3 of vendor driver see https://gitlab.com/dm38/padavan-ng/-/blob/master/trunk/proprietary/rt_wifi/rtpci/3.0.X.X/mt76x2/chips/rt6352.c#L531 3. Set bbp66 for all chains. 4. US_CYC_CNT init based on Programming guide, default value was 33 (pci), set chipset bus clock with fallback to cpu clock/3. 5. Don't overwrite default values for mt7620. 6. Correct some typos. 7. Add support for external LNA: a) RF and BBP regs never be corrected for this mode b) eLNA is driven the same way as ePA with mt7620's pin PA but vendor driver explicitly pin PA to gpio mode (for forrect calibration?) so I'm not sure that request for pa_pin in dts-file will be enough First 5 changes (really 2) improve performance for boards w/o eLNA/ePA. Changes 7 add support for eLNA Configuration w/o eLAN/ePA and with eLNA show results tx/rx (from router point of view) for each stream: 35-40/30-35 Mbps for HT20 65-70/60-65 Mbps for HT40 Yes. Max results for 2T2R client is 140-145/135-140 with peaks 160/150, It correspond to mediatek driver results. Boards with ePA untested. Reported-by: Serge Vasilugin <vasilugin@yandex.ru> Signed-off-by: Daniel Golle <daniel@makrotopia.org> [directly include v3 of the patchset submitted upstream] (cherry picked from commit 31a6605de04218e1c04bd5c2436c24d7d1c07506) (cherry picked from commit e785ca05e9f0502894772f5df92192b816ba5d7c) (cherry picked from commit 412fcf3d4400f84551f3ead0514834c62d94a251)
2022-07-28 11:40:12 +00:00
@@ -10408,31 +10436,36 @@ static void rt2800_init_rfcsr_6352(struc
rt2x00: mt7620: differentiate based on SoC's CHIP_VER The vendor driver does things differently based on what it finds in the SoC's CHIP_VER register, which should tell whether this is MT7620N or MT7620A (PKG) and probably also the revision (VER) and most likely also something about the silicon implementer (ECO). Introduce codepaths just like the ones in the vendor driver to handle the different chips properly. Some of those paths are most likely dead code and left-overs from FPGA versions or early prototypes of the chip. It'd thus be great if people can post their kernel logs, at least the line telling the chip version and eco, so we know what's actually out there in the wild -- all I could find is [ 0.000000] SoC Type: Ralink MT7620A ver:2 eco:6 and [ 0.000000] SoC Type: Ralink MT7620N ver:2 eco:6 which would make things easier, as then we really just need to know whether it's MT7620N or MT7620A and not care about FPGA or prototypes with ver <= 1 and eco <= 2. Signed-off-by: Daniel Golle <daniel@makrotopia.org>
2017-02-05 16:55:53 +00:00
rt2800_rfcsr_write(rt2x00dev, 42, 0x5B);
rt2800_rfcsr_write(rt2x00dev, 43, 0x00);
- rt2800_rfcsr_write(rt2x00dev, 11, 0x21);
- if (rt2800_clk_is_20mhz(rt2x00dev))
- rt2800_rfcsr_write(rt2x00dev, 13, 0x03);
- else
- rt2800_rfcsr_write(rt2x00dev, 13, 0x00);
- rt2800_rfcsr_write(rt2x00dev, 14, 0x7C);
- rt2800_rfcsr_write(rt2x00dev, 16, 0x80);
- rt2800_rfcsr_write(rt2x00dev, 17, 0x99);
- rt2800_rfcsr_write(rt2x00dev, 18, 0x99);
- rt2800_rfcsr_write(rt2x00dev, 19, 0x09);
- rt2800_rfcsr_write(rt2x00dev, 20, 0x50);
- rt2800_rfcsr_write(rt2x00dev, 21, 0xB0);
- rt2800_rfcsr_write(rt2x00dev, 22, 0x00);
- rt2800_rfcsr_write(rt2x00dev, 23, 0x06);
- rt2800_rfcsr_write(rt2x00dev, 24, 0x00);
- rt2800_rfcsr_write(rt2x00dev, 25, 0x00);
- rt2800_rfcsr_write(rt2x00dev, 26, 0x5D);
- rt2800_rfcsr_write(rt2x00dev, 27, 0x00);
- rt2800_rfcsr_write(rt2x00dev, 28, 0x61);
- rt2800_rfcsr_write(rt2x00dev, 29, 0xB5);
- rt2800_rfcsr_write(rt2x00dev, 43, 0x02);
mac80211: Refresh patches again A wrong quilt configuration was used last time. Fixes: ed1e234d87fc ("mac80211: refresh patches") Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
2021-02-15 21:23:17 +00:00
-
- rt2800_rfcsr_write(rt2x00dev, 28, 0x62);
- rt2800_rfcsr_write(rt2x00dev, 29, 0xAD);
- rt2800_rfcsr_write(rt2x00dev, 39, 0x80);
rt2x00: mt7620: differentiate based on SoC's CHIP_VER The vendor driver does things differently based on what it finds in the SoC's CHIP_VER register, which should tell whether this is MT7620N or MT7620A (PKG) and probably also the revision (VER) and most likely also something about the silicon implementer (ECO). Introduce codepaths just like the ones in the vendor driver to handle the different chips properly. Some of those paths are most likely dead code and left-overs from FPGA versions or early prototypes of the chip. It'd thus be great if people can post their kernel logs, at least the line telling the chip version and eco, so we know what's actually out there in the wild -- all I could find is [ 0.000000] SoC Type: Ralink MT7620A ver:2 eco:6 and [ 0.000000] SoC Type: Ralink MT7620N ver:2 eco:6 which would make things easier, as then we really just need to know whether it's MT7620N or MT7620A and not care about FPGA or prototypes with ver <= 1 and eco <= 2. Signed-off-by: Daniel Golle <daniel@makrotopia.org>
2017-02-05 16:55:53 +00:00
+ if (rt2800_hw_get_chipver(rt2x00dev) > 1) {
+ rt2800_rfcsr_write(rt2x00dev, 11, 0x21);
+ if (rt2800_clk_is_20mhz(rt2x00dev))
+ rt2800_rfcsr_write(rt2x00dev, 13, 0x03);
+ else
+ rt2800_rfcsr_write(rt2x00dev, 13, 0x00);
+ rt2800_rfcsr_write(rt2x00dev, 14, 0x7C);
+ rt2800_rfcsr_write(rt2x00dev, 16, 0x80);
+ rt2800_rfcsr_write(rt2x00dev, 17, 0x99);
+ rt2800_rfcsr_write(rt2x00dev, 18, 0x99);
+ rt2800_rfcsr_write(rt2x00dev, 19, 0x09);
+ rt2800_rfcsr_write(rt2x00dev, 20, 0x50);
+ rt2800_rfcsr_write(rt2x00dev, 21, 0xB0);
+ rt2800_rfcsr_write(rt2x00dev, 22, 0x00);
+ rt2800_rfcsr_write(rt2x00dev, 23, 0x06);
+ rt2800_rfcsr_write(rt2x00dev, 24, 0x00);
+ rt2800_rfcsr_write(rt2x00dev, 25, 0x00);
+ rt2800_rfcsr_write(rt2x00dev, 26, 0x5D);
+ rt2800_rfcsr_write(rt2x00dev, 27, 0x00);
+ rt2800_rfcsr_write(rt2x00dev, 28, 0x61);
+ rt2800_rfcsr_write(rt2x00dev, 29, 0xB5);
+ rt2800_rfcsr_write(rt2x00dev, 43, 0x02);
+ }
mac80211: Refresh patches again A wrong quilt configuration was used last time. Fixes: ed1e234d87fc ("mac80211: refresh patches") Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
2021-02-15 21:23:17 +00:00
+
rt2x00: mt7620: differentiate based on SoC's CHIP_VER The vendor driver does things differently based on what it finds in the SoC's CHIP_VER register, which should tell whether this is MT7620N or MT7620A (PKG) and probably also the revision (VER) and most likely also something about the silicon implementer (ECO). Introduce codepaths just like the ones in the vendor driver to handle the different chips properly. Some of those paths are most likely dead code and left-overs from FPGA versions or early prototypes of the chip. It'd thus be great if people can post their kernel logs, at least the line telling the chip version and eco, so we know what's actually out there in the wild -- all I could find is [ 0.000000] SoC Type: Ralink MT7620A ver:2 eco:6 and [ 0.000000] SoC Type: Ralink MT7620N ver:2 eco:6 which would make things easier, as then we really just need to know whether it's MT7620N or MT7620A and not care about FPGA or prototypes with ver <= 1 and eco <= 2. Signed-off-by: Daniel Golle <daniel@makrotopia.org>
2017-02-05 16:55:53 +00:00
+ if (rt2800_hw_get_chipver(rt2x00dev) > 1 &&
+ rt2800_hw_get_chipeco(rt2x00dev) >= 2) {
+ rt2800_rfcsr_write(rt2x00dev, 28, 0x62);
+ rt2800_rfcsr_write(rt2x00dev, 29, 0xAD);
+ rt2800_rfcsr_write(rt2x00dev, 39, 0x80);
+ }
/* Initialize RF channel register to default value */
rt2800_rfcsr_write_chanreg(rt2x00dev, 0, 0x03);
mac80211: rt2x00: experimental improvements for MT7620 wifi Serge Vasilugin reports: To improve mt7620 built-in wifi performance some changes: 1. Correct BW20/BW40 switching (see comments with mark (1)) 2. Correct TX_SW_CFG1 MAC reg from v3 of vendor driver see https://gitlab.com/dm38/padavan-ng/-/blob/master/trunk/proprietary/rt_wifi/rtpci/3.0.X.X/mt76x2/chips/rt6352.c#L531 3. Set bbp66 for all chains. 4. US_CYC_CNT init based on Programming guide, default value was 33 (pci), set chipset bus clock with fallback to cpu clock/3. 5. Don't overwrite default values for mt7620. 6. Correct some typos. 7. Add support for external LNA: a) RF and BBP regs never be corrected for this mode b) eLNA is driven the same way as ePA with mt7620's pin PA but vendor driver explicitly pin PA to gpio mode (for forrect calibration?) so I'm not sure that request for pa_pin in dts-file will be enough First 5 changes (really 2) improve performance for boards w/o eLNA/ePA. Changes 7 add support for eLNA Configuration w/o eLAN/ePA and with eLNA show results tx/rx (from router point of view) for each stream: 35-40/30-35 Mbps for HT20 65-70/60-65 Mbps for HT40 Yes. Max results for 2T2R client is 140-145/135-140 with peaks 160/150, It correspond to mediatek driver results. Boards with ePA untested. Reported-by: Serge Vasilugin <vasilugin@yandex.ru> Signed-off-by: Daniel Golle <daniel@makrotopia.org> [directly include v3 of the patchset submitted upstream] (cherry picked from commit 31a6605de04218e1c04bd5c2436c24d7d1c07506) (cherry picked from commit e785ca05e9f0502894772f5df92192b816ba5d7c) (cherry picked from commit 412fcf3d4400f84551f3ead0514834c62d94a251)
2022-07-28 11:40:12 +00:00
@@ -10498,63 +10531,71 @@ static void rt2800_init_rfcsr_6352(struc
rt2x00: mt7620: differentiate based on SoC's CHIP_VER The vendor driver does things differently based on what it finds in the SoC's CHIP_VER register, which should tell whether this is MT7620N or MT7620A (PKG) and probably also the revision (VER) and most likely also something about the silicon implementer (ECO). Introduce codepaths just like the ones in the vendor driver to handle the different chips properly. Some of those paths are most likely dead code and left-overs from FPGA versions or early prototypes of the chip. It'd thus be great if people can post their kernel logs, at least the line telling the chip version and eco, so we know what's actually out there in the wild -- all I could find is [ 0.000000] SoC Type: Ralink MT7620A ver:2 eco:6 and [ 0.000000] SoC Type: Ralink MT7620N ver:2 eco:6 which would make things easier, as then we really just need to know whether it's MT7620N or MT7620A and not care about FPGA or prototypes with ver <= 1 and eco <= 2. Signed-off-by: Daniel Golle <daniel@makrotopia.org>
2017-02-05 16:55:53 +00:00
rt2800_rfcsr_write_bank(rt2x00dev, 6, 45, 0xC5);
- rt2800_rfcsr_write_chanreg(rt2x00dev, 9, 0x47);
- rt2800_rfcsr_write_chanreg(rt2x00dev, 10, 0x71);
- rt2800_rfcsr_write_chanreg(rt2x00dev, 11, 0x33);
- rt2800_rfcsr_write_chanreg(rt2x00dev, 14, 0x0E);
- rt2800_rfcsr_write_chanreg(rt2x00dev, 17, 0x23);
- rt2800_rfcsr_write_chanreg(rt2x00dev, 19, 0xA4);
- rt2800_rfcsr_write_chanreg(rt2x00dev, 20, 0x02);
- rt2800_rfcsr_write_chanreg(rt2x00dev, 21, 0x12);
- rt2800_rfcsr_write_chanreg(rt2x00dev, 28, 0x1C);
- rt2800_rfcsr_write_chanreg(rt2x00dev, 29, 0xEB);
- rt2800_rfcsr_write_chanreg(rt2x00dev, 32, 0x7D);
- rt2800_rfcsr_write_chanreg(rt2x00dev, 34, 0xD6);
- rt2800_rfcsr_write_chanreg(rt2x00dev, 36, 0x08);
- rt2800_rfcsr_write_chanreg(rt2x00dev, 38, 0xB4);
- rt2800_rfcsr_write_chanreg(rt2x00dev, 43, 0xD3);
- rt2800_rfcsr_write_chanreg(rt2x00dev, 44, 0xB3);
- rt2800_rfcsr_write_chanreg(rt2x00dev, 45, 0xD5);
- rt2800_rfcsr_write_chanreg(rt2x00dev, 46, 0x27);
- rt2800_rfcsr_write_bank(rt2x00dev, 4, 47, 0x67);
- rt2800_rfcsr_write_bank(rt2x00dev, 6, 47, 0x69);
- rt2800_rfcsr_write_chanreg(rt2x00dev, 48, 0xFF);
- rt2800_rfcsr_write_bank(rt2x00dev, 4, 54, 0x27);
- rt2800_rfcsr_write_bank(rt2x00dev, 6, 54, 0x20);
- rt2800_rfcsr_write_chanreg(rt2x00dev, 55, 0x66);
- rt2800_rfcsr_write_chanreg(rt2x00dev, 56, 0xFF);
- rt2800_rfcsr_write_chanreg(rt2x00dev, 57, 0x1C);
- rt2800_rfcsr_write_chanreg(rt2x00dev, 58, 0x20);
- rt2800_rfcsr_write_chanreg(rt2x00dev, 59, 0x6B);
- rt2800_rfcsr_write_chanreg(rt2x00dev, 60, 0xF7);
- rt2800_rfcsr_write_chanreg(rt2x00dev, 61, 0x09);
mac80211: Refresh patches again A wrong quilt configuration was used last time. Fixes: ed1e234d87fc ("mac80211: refresh patches") Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
2021-02-15 21:23:17 +00:00
-
- rt2800_rfcsr_write_chanreg(rt2x00dev, 10, 0x51);
- rt2800_rfcsr_write_chanreg(rt2x00dev, 14, 0x06);
- rt2800_rfcsr_write_chanreg(rt2x00dev, 19, 0xA7);
- rt2800_rfcsr_write_chanreg(rt2x00dev, 28, 0x2C);
- rt2800_rfcsr_write_chanreg(rt2x00dev, 55, 0x64);
- rt2800_rfcsr_write_chanreg(rt2x00dev, 8, 0x51);
- rt2800_rfcsr_write_chanreg(rt2x00dev, 9, 0x36);
- rt2800_rfcsr_write_chanreg(rt2x00dev, 11, 0x53);
- rt2800_rfcsr_write_chanreg(rt2x00dev, 14, 0x16);
-
- rt2800_rfcsr_write_chanreg(rt2x00dev, 47, 0x6C);
- rt2800_rfcsr_write_chanreg(rt2x00dev, 48, 0xFC);
- rt2800_rfcsr_write_chanreg(rt2x00dev, 49, 0x1F);
- rt2800_rfcsr_write_chanreg(rt2x00dev, 54, 0x27);
- rt2800_rfcsr_write_chanreg(rt2x00dev, 55, 0x66);
- rt2800_rfcsr_write_chanreg(rt2x00dev, 59, 0x6B);
-
- /* Initialize RF channel register for DRQFN */
- rt2800_rfcsr_write_chanreg(rt2x00dev, 43, 0xD3);
- rt2800_rfcsr_write_chanreg(rt2x00dev, 44, 0xE3);
- rt2800_rfcsr_write_chanreg(rt2x00dev, 45, 0xE5);
- rt2800_rfcsr_write_chanreg(rt2x00dev, 47, 0x28);
- rt2800_rfcsr_write_chanreg(rt2x00dev, 55, 0x68);
- rt2800_rfcsr_write_chanreg(rt2x00dev, 56, 0xF7);
- rt2800_rfcsr_write_chanreg(rt2x00dev, 58, 0x02);
- rt2800_rfcsr_write_chanreg(rt2x00dev, 60, 0xC7);
rt2x00: mt7620: differentiate based on SoC's CHIP_VER The vendor driver does things differently based on what it finds in the SoC's CHIP_VER register, which should tell whether this is MT7620N or MT7620A (PKG) and probably also the revision (VER) and most likely also something about the silicon implementer (ECO). Introduce codepaths just like the ones in the vendor driver to handle the different chips properly. Some of those paths are most likely dead code and left-overs from FPGA versions or early prototypes of the chip. It'd thus be great if people can post their kernel logs, at least the line telling the chip version and eco, so we know what's actually out there in the wild -- all I could find is [ 0.000000] SoC Type: Ralink MT7620A ver:2 eco:6 and [ 0.000000] SoC Type: Ralink MT7620N ver:2 eco:6 which would make things easier, as then we really just need to know whether it's MT7620N or MT7620A and not care about FPGA or prototypes with ver <= 1 and eco <= 2. Signed-off-by: Daniel Golle <daniel@makrotopia.org>
2017-02-05 16:55:53 +00:00
+ if (rt2800_hw_get_chipver(rt2x00dev) > 1) {
+ rt2800_rfcsr_write_chanreg(rt2x00dev, 9, 0x47);
+ rt2800_rfcsr_write_chanreg(rt2x00dev, 10, 0x71);
+ rt2800_rfcsr_write_chanreg(rt2x00dev, 11, 0x33);
+ rt2800_rfcsr_write_chanreg(rt2x00dev, 14, 0x0E);
+ rt2800_rfcsr_write_chanreg(rt2x00dev, 17, 0x23);
+ rt2800_rfcsr_write_chanreg(rt2x00dev, 19, 0xA4);
+ rt2800_rfcsr_write_chanreg(rt2x00dev, 20, 0x02);
+ rt2800_rfcsr_write_chanreg(rt2x00dev, 21, 0x12);
+ rt2800_rfcsr_write_chanreg(rt2x00dev, 28, 0x1C);
+ rt2800_rfcsr_write_chanreg(rt2x00dev, 29, 0xEB);
+ rt2800_rfcsr_write_chanreg(rt2x00dev, 32, 0x7D);
+ rt2800_rfcsr_write_chanreg(rt2x00dev, 34, 0xD6);
+ rt2800_rfcsr_write_chanreg(rt2x00dev, 36, 0x08);
+ rt2800_rfcsr_write_chanreg(rt2x00dev, 38, 0xB4);
+ rt2800_rfcsr_write_chanreg(rt2x00dev, 43, 0xD3);
+ rt2800_rfcsr_write_chanreg(rt2x00dev, 44, 0xB3);
+ rt2800_rfcsr_write_chanreg(rt2x00dev, 45, 0xD5);
+ rt2800_rfcsr_write_chanreg(rt2x00dev, 46, 0x27);
+ rt2800_rfcsr_write_bank(rt2x00dev, 4, 47, 0x67);
+ rt2800_rfcsr_write_bank(rt2x00dev, 6, 47, 0x69);
+ rt2800_rfcsr_write_chanreg(rt2x00dev, 48, 0xFF);
+ rt2800_rfcsr_write_bank(rt2x00dev, 4, 54, 0x27);
+ rt2800_rfcsr_write_bank(rt2x00dev, 6, 54, 0x20);
+ rt2800_rfcsr_write_chanreg(rt2x00dev, 55, 0x66);
+ rt2800_rfcsr_write_chanreg(rt2x00dev, 56, 0xFF);
+ rt2800_rfcsr_write_chanreg(rt2x00dev, 57, 0x1C);
+ rt2800_rfcsr_write_chanreg(rt2x00dev, 58, 0x20);
+ rt2800_rfcsr_write_chanreg(rt2x00dev, 59, 0x6B);
+ rt2800_rfcsr_write_chanreg(rt2x00dev, 60, 0xF7);
+ rt2800_rfcsr_write_chanreg(rt2x00dev, 61, 0x09);
+ }
mac80211: Refresh patches again A wrong quilt configuration was used last time. Fixes: ed1e234d87fc ("mac80211: refresh patches") Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
2021-02-15 21:23:17 +00:00
+
rt2x00: mt7620: differentiate based on SoC's CHIP_VER The vendor driver does things differently based on what it finds in the SoC's CHIP_VER register, which should tell whether this is MT7620N or MT7620A (PKG) and probably also the revision (VER) and most likely also something about the silicon implementer (ECO). Introduce codepaths just like the ones in the vendor driver to handle the different chips properly. Some of those paths are most likely dead code and left-overs from FPGA versions or early prototypes of the chip. It'd thus be great if people can post their kernel logs, at least the line telling the chip version and eco, so we know what's actually out there in the wild -- all I could find is [ 0.000000] SoC Type: Ralink MT7620A ver:2 eco:6 and [ 0.000000] SoC Type: Ralink MT7620N ver:2 eco:6 which would make things easier, as then we really just need to know whether it's MT7620N or MT7620A and not care about FPGA or prototypes with ver <= 1 and eco <= 2. Signed-off-by: Daniel Golle <daniel@makrotopia.org>
2017-02-05 16:55:53 +00:00
+ if (rt2800_hw_get_chipver(rt2x00dev) > 1 &&
+ rt2800_hw_get_chipeco(rt2x00dev) >= 2) {
+ rt2800_rfcsr_write_chanreg(rt2x00dev, 10, 0x51);
+ rt2800_rfcsr_write_chanreg(rt2x00dev, 14, 0x06);
+ rt2800_rfcsr_write_chanreg(rt2x00dev, 19, 0xA7);
+ rt2800_rfcsr_write_chanreg(rt2x00dev, 28, 0x2C);
+ rt2800_rfcsr_write_chanreg(rt2x00dev, 55, 0x64);
+ rt2800_rfcsr_write_chanreg(rt2x00dev, 8, 0x51);
+ rt2800_rfcsr_write_chanreg(rt2x00dev, 9, 0x36);
+ rt2800_rfcsr_write_chanreg(rt2x00dev, 11, 0x53);
+ rt2800_rfcsr_write_chanreg(rt2x00dev, 14, 0x16);
mac80211: Refresh patches again A wrong quilt configuration was used last time. Fixes: ed1e234d87fc ("mac80211: refresh patches") Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
2021-02-15 21:23:17 +00:00
+
rt2x00: mt7620: differentiate based on SoC's CHIP_VER The vendor driver does things differently based on what it finds in the SoC's CHIP_VER register, which should tell whether this is MT7620N or MT7620A (PKG) and probably also the revision (VER) and most likely also something about the silicon implementer (ECO). Introduce codepaths just like the ones in the vendor driver to handle the different chips properly. Some of those paths are most likely dead code and left-overs from FPGA versions or early prototypes of the chip. It'd thus be great if people can post their kernel logs, at least the line telling the chip version and eco, so we know what's actually out there in the wild -- all I could find is [ 0.000000] SoC Type: Ralink MT7620A ver:2 eco:6 and [ 0.000000] SoC Type: Ralink MT7620N ver:2 eco:6 which would make things easier, as then we really just need to know whether it's MT7620N or MT7620A and not care about FPGA or prototypes with ver <= 1 and eco <= 2. Signed-off-by: Daniel Golle <daniel@makrotopia.org>
2017-02-05 16:55:53 +00:00
+ rt2800_rfcsr_write_chanreg(rt2x00dev, 47, 0x6C);
+ rt2800_rfcsr_write_chanreg(rt2x00dev, 48, 0xFC);
+ rt2800_rfcsr_write_chanreg(rt2x00dev, 49, 0x1F);
+ rt2800_rfcsr_write_chanreg(rt2x00dev, 54, 0x27);
+ rt2800_rfcsr_write_chanreg(rt2x00dev, 55, 0x66);
+ rt2800_rfcsr_write_chanreg(rt2x00dev, 59, 0x6B);
+ }
mac80211: Refresh patches again A wrong quilt configuration was used last time. Fixes: ed1e234d87fc ("mac80211: refresh patches") Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
2021-02-15 21:23:17 +00:00
+
rt2x00: mt7620: differentiate based on SoC's CHIP_VER The vendor driver does things differently based on what it finds in the SoC's CHIP_VER register, which should tell whether this is MT7620N or MT7620A (PKG) and probably also the revision (VER) and most likely also something about the silicon implementer (ECO). Introduce codepaths just like the ones in the vendor driver to handle the different chips properly. Some of those paths are most likely dead code and left-overs from FPGA versions or early prototypes of the chip. It'd thus be great if people can post their kernel logs, at least the line telling the chip version and eco, so we know what's actually out there in the wild -- all I could find is [ 0.000000] SoC Type: Ralink MT7620A ver:2 eco:6 and [ 0.000000] SoC Type: Ralink MT7620N ver:2 eco:6 which would make things easier, as then we really just need to know whether it's MT7620N or MT7620A and not care about FPGA or prototypes with ver <= 1 and eco <= 2. Signed-off-by: Daniel Golle <daniel@makrotopia.org>
2017-02-05 16:55:53 +00:00
+ if (rt2800_hw_get_chippkg(rt2x00dev) == 0 &&
+ rt2800_hw_get_chipver(rt2x00dev) == 1) {
+ /* Initialize RF channel register for DRQFN */
+ rt2800_rfcsr_write_chanreg(rt2x00dev, 43, 0xD3);
+ rt2800_rfcsr_write_chanreg(rt2x00dev, 44, 0xE3);
+ rt2800_rfcsr_write_chanreg(rt2x00dev, 45, 0xE5);
+ rt2800_rfcsr_write_chanreg(rt2x00dev, 47, 0x28);
+ rt2800_rfcsr_write_chanreg(rt2x00dev, 55, 0x68);
+ rt2800_rfcsr_write_chanreg(rt2x00dev, 56, 0xF7);
+ rt2800_rfcsr_write_chanreg(rt2x00dev, 58, 0x02);
+ rt2800_rfcsr_write_chanreg(rt2x00dev, 60, 0xC7);
+ }
/* Initialize RF DC calibration register to default value */
rt2800_rfcsr_write_dccal(rt2x00dev, 0, 0x47);
mac80211: rt2x00: experimental improvements for MT7620 wifi Serge Vasilugin reports: To improve mt7620 built-in wifi performance some changes: 1. Correct BW20/BW40 switching (see comments with mark (1)) 2. Correct TX_SW_CFG1 MAC reg from v3 of vendor driver see https://gitlab.com/dm38/padavan-ng/-/blob/master/trunk/proprietary/rt_wifi/rtpci/3.0.X.X/mt76x2/chips/rt6352.c#L531 3. Set bbp66 for all chains. 4. US_CYC_CNT init based on Programming guide, default value was 33 (pci), set chipset bus clock with fallback to cpu clock/3. 5. Don't overwrite default values for mt7620. 6. Correct some typos. 7. Add support for external LNA: a) RF and BBP regs never be corrected for this mode b) eLNA is driven the same way as ePA with mt7620's pin PA but vendor driver explicitly pin PA to gpio mode (for forrect calibration?) so I'm not sure that request for pa_pin in dts-file will be enough First 5 changes (really 2) improve performance for boards w/o eLNA/ePA. Changes 7 add support for eLNA Configuration w/o eLAN/ePA and with eLNA show results tx/rx (from router point of view) for each stream: 35-40/30-35 Mbps for HT20 65-70/60-65 Mbps for HT40 Yes. Max results for 2T2R client is 140-145/135-140 with peaks 160/150, It correspond to mediatek driver results. Boards with ePA untested. Reported-by: Serge Vasilugin <vasilugin@yandex.ru> Signed-off-by: Daniel Golle <daniel@makrotopia.org> [directly include v3 of the patchset submitted upstream] (cherry picked from commit 31a6605de04218e1c04bd5c2436c24d7d1c07506) (cherry picked from commit e785ca05e9f0502894772f5df92192b816ba5d7c) (cherry picked from commit 412fcf3d4400f84551f3ead0514834c62d94a251)
2022-07-28 11:40:12 +00:00
@@ -10617,12 +10658,17 @@ static void rt2800_init_rfcsr_6352(struc
rt2x00: mt7620: differentiate based on SoC's CHIP_VER The vendor driver does things differently based on what it finds in the SoC's CHIP_VER register, which should tell whether this is MT7620N or MT7620A (PKG) and probably also the revision (VER) and most likely also something about the silicon implementer (ECO). Introduce codepaths just like the ones in the vendor driver to handle the different chips properly. Some of those paths are most likely dead code and left-overs from FPGA versions or early prototypes of the chip. It'd thus be great if people can post their kernel logs, at least the line telling the chip version and eco, so we know what's actually out there in the wild -- all I could find is [ 0.000000] SoC Type: Ralink MT7620A ver:2 eco:6 and [ 0.000000] SoC Type: Ralink MT7620N ver:2 eco:6 which would make things easier, as then we really just need to know whether it's MT7620N or MT7620A and not care about FPGA or prototypes with ver <= 1 and eco <= 2. Signed-off-by: Daniel Golle <daniel@makrotopia.org>
2017-02-05 16:55:53 +00:00
rt2800_rfcsr_write_dccal(rt2x00dev, 62, 0x00);
rt2800_rfcsr_write_dccal(rt2x00dev, 63, 0x00);
- rt2800_rfcsr_write_dccal(rt2x00dev, 3, 0x08);
- rt2800_rfcsr_write_dccal(rt2x00dev, 4, 0x04);
- rt2800_rfcsr_write_dccal(rt2x00dev, 5, 0x20);
+ if (rt2800_hw_get_chipver(rt2x00dev) > 1) {
+ rt2800_rfcsr_write_dccal(rt2x00dev, 3, 0x08);
+ rt2800_rfcsr_write_dccal(rt2x00dev, 4, 0x04);
+ rt2800_rfcsr_write_dccal(rt2x00dev, 5, 0x20);
+ }
- rt2800_rfcsr_write_dccal(rt2x00dev, 5, 0x00);
- rt2800_rfcsr_write_dccal(rt2x00dev, 17, 0x7C);
+ if (rt2800_hw_get_chipver(rt2x00dev) > 1 &&
+ rt2800_hw_get_chipeco(rt2x00dev) >= 2) {
+ rt2800_rfcsr_write_dccal(rt2x00dev, 5, 0x00);
+ rt2800_rfcsr_write_dccal(rt2x00dev, 17, 0x7C);
+ }
mac80211: rt2x00: experimental improvements for MT7620 wifi Serge Vasilugin reports: To improve mt7620 built-in wifi performance some changes: 1. Correct BW20/BW40 switching (see comments with mark (1)) 2. Correct TX_SW_CFG1 MAC reg from v3 of vendor driver see https://gitlab.com/dm38/padavan-ng/-/blob/master/trunk/proprietary/rt_wifi/rtpci/3.0.X.X/mt76x2/chips/rt6352.c#L531 3. Set bbp66 for all chains. 4. US_CYC_CNT init based on Programming guide, default value was 33 (pci), set chipset bus clock with fallback to cpu clock/3. 5. Don't overwrite default values for mt7620. 6. Correct some typos. 7. Add support for external LNA: a) RF and BBP regs never be corrected for this mode b) eLNA is driven the same way as ePA with mt7620's pin PA but vendor driver explicitly pin PA to gpio mode (for forrect calibration?) so I'm not sure that request for pa_pin in dts-file will be enough First 5 changes (really 2) improve performance for boards w/o eLNA/ePA. Changes 7 add support for eLNA Configuration w/o eLAN/ePA and with eLNA show results tx/rx (from router point of view) for each stream: 35-40/30-35 Mbps for HT20 65-70/60-65 Mbps for HT40 Yes. Max results for 2T2R client is 140-145/135-140 with peaks 160/150, It correspond to mediatek driver results. Boards with ePA untested. Reported-by: Serge Vasilugin <vasilugin@yandex.ru> Signed-off-by: Daniel Golle <daniel@makrotopia.org> [directly include v3 of the patchset submitted upstream] (cherry picked from commit 31a6605de04218e1c04bd5c2436c24d7d1c07506) (cherry picked from commit e785ca05e9f0502894772f5df92192b816ba5d7c) (cherry picked from commit 412fcf3d4400f84551f3ead0514834c62d94a251)
2022-07-28 11:40:12 +00:00
rt6352_enable_pa_pin(rt2x00dev, 0);
rt2x00: mt7620: differentiate based on SoC's CHIP_VER The vendor driver does things differently based on what it finds in the SoC's CHIP_VER register, which should tell whether this is MT7620N or MT7620A (PKG) and probably also the revision (VER) and most likely also something about the silicon implementer (ECO). Introduce codepaths just like the ones in the vendor driver to handle the different chips properly. Some of those paths are most likely dead code and left-overs from FPGA versions or early prototypes of the chip. It'd thus be great if people can post their kernel logs, at least the line telling the chip version and eco, so we know what's actually out there in the wild -- all I could find is [ 0.000000] SoC Type: Ralink MT7620A ver:2 eco:6 and [ 0.000000] SoC Type: Ralink MT7620N ver:2 eco:6 which would make things easier, as then we really just need to know whether it's MT7620N or MT7620A and not care about FPGA or prototypes with ver <= 1 and eco <= 2. Signed-off-by: Daniel Golle <daniel@makrotopia.org>
2017-02-05 16:55:53 +00:00
rt2800_r_calibration(rt2x00dev);
Reference in New Issue Copy Permalink