ExternalVendorCode/openwrt
1
0
Fork 0
mirror of https://github.com/openwrt/openwrt.git synced 2024-12-28 17:48:58 +00:00
Code Issues Actions 7 Packages Projects Releases Wiki Activity
69f12c2f23
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: replace patches with v3 of pending series See also patchwork for submission progress: https://patchwork.kernel.org/project/linux-wireless/cover/cover.1663445157.git.daniel@makrotopia.org/ Signed-off-by: Daniel Golle <daniel@makrotopia.org>
2022-09-17 19:11: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: replace patches with v3 of pending series See also patchwork for submission progress: https://patchwork.kernel.org/project/linux-wireless/cover/cover.1663445157.git.daniel@makrotopia.org/ Signed-off-by: Daniel Golle <daniel@makrotopia.org>
2022-09-17 19:11: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: replace patches with v3 of pending series See also patchwork for submission progress: https://patchwork.kernel.org/project/linux-wireless/cover/cover.1663445157.git.daniel@makrotopia.org/ Signed-off-by: Daniel Golle <daniel@makrotopia.org>
2022-09-17 19:11: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: replace patches with v3 of pending series See also patchwork for submission progress: https://patchwork.kernel.org/project/linux-wireless/cover/cover.1663445157.git.daniel@makrotopia.org/ Signed-off-by: Daniel Golle <daniel@makrotopia.org>
2022-09-17 19:11: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: replace patches with v3 of pending series See also patchwork for submission progress: https://patchwork.kernel.org/project/linux-wireless/cover/cover.1663445157.git.daniel@makrotopia.org/ Signed-off-by: Daniel Golle <daniel@makrotopia.org>
2022-09-17 19:11: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: clean and submit a bunch of rt2x00 patches Clean and submit patches, mostly related to MT7620 to linux-wireless mailing list: https://patchwork.kernel.org/project/linux-wireless/list/?series=677770 Replace local patches with now submitted versions. Signed-off-by: Daniel Golle <daniel@makrotopia.org>
2022-09-16 23:33:30 +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: clean and submit a bunch of rt2x00 patches Clean and submit patches, mostly related to MT7620 to linux-wireless mailing list: https://patchwork.kernel.org/project/linux-wireless/list/?series=677770 Replace local patches with now submitted versions. Signed-off-by: Daniel Golle <daniel@makrotopia.org>
2022-09-16 23:33:30 +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: replace patches with v3 of pending series See also patchwork for submission progress: https://patchwork.kernel.org/project/linux-wireless/cover/cover.1663445157.git.daniel@makrotopia.org/ Signed-off-by: Daniel Golle <daniel@makrotopia.org>
2022-09-17 19:11: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: replace patches with v3 of pending series See also patchwork for submission progress: https://patchwork.kernel.org/project/linux-wireless/cover/cover.1663445157.git.daniel@makrotopia.org/ Signed-off-by: Daniel Golle <daniel@makrotopia.org>
2022-09-17 19:11: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: replace patches with v3 of pending series See also patchwork for submission progress: https://patchwork.kernel.org/project/linux-wireless/cover/cover.1663445157.git.daniel@makrotopia.org/ Signed-off-by: Daniel Golle <daniel@makrotopia.org>
2022-09-17 19:11: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: replace patches with v3 of pending series See also patchwork for submission progress: https://patchwork.kernel.org/project/linux-wireless/cover/cover.1663445157.git.daniel@makrotopia.org/ Signed-off-by: Daniel Golle <daniel@makrotopia.org>
2022-09-17 19:11: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: clean and submit a bunch of rt2x00 patches Clean and submit patches, mostly related to MT7620 to linux-wireless mailing list: https://patchwork.kernel.org/project/linux-wireless/list/?series=677770 Replace local patches with now submitted versions. Signed-off-by: Daniel Golle <daniel@makrotopia.org>
2022-09-16 23:33:30 +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