v3 -> v4:
- do not program addition registers for MT7620
- fix RT6362 typo
v2 -> v3:
- fix wrongly applied hunk during rebase
- add SoB
Stanislaw Gruszka (5):
rt2800: fix registers init for MT7620
rt2800: enable TX_PIN_CFG_LNA_PE_ bits per band
rt2800: enable TX_PIN_CFG_RFRX_EN only for MT7620
rt2800: remove unneeded RT6352 check
rt2800: comment and simplify AGC init for RT6352
Tomislav Požega (3):
rt2x00: remove unneeded check
rt2x00: remove confusing AGC register
rt2x00: update TX_SW_CFG2 value
drivers/net/wireless/ralink/rt2x00/rt2800lib.c | 150 +++++++++++++------------
1 file changed, 78 insertions(+), 72 deletions(-)
--
2.7.5
From: Tomislav Požega <[email protected]>
Remove band check from rf53xx channel config routine since all chips
using it are single band.
Signed-off-by: Tomislav Požega <[email protected]>
Signed-off-by: Stanislaw Gruszka <[email protected]>
---
drivers/net/wireless/ralink/rt2x00/rt2800lib.c | 103 ++++++++++++-------------
1 file changed, 50 insertions(+), 53 deletions(-)
diff --git a/drivers/net/wireless/ralink/rt2x00/rt2800lib.c b/drivers/net/wireless/ralink/rt2x00/rt2800lib.c
index 9e7b8933d30c..1a2bf6c49b82 100644
--- a/drivers/net/wireless/ralink/rt2x00/rt2800lib.c
+++ b/drivers/net/wireless/ralink/rt2x00/rt2800lib.c
@@ -2963,6 +2963,7 @@ static void rt2800_config_channel_rf53xx(struct rt2x00_dev *rt2x00dev,
struct rf_channel *rf,
struct channel_info *info)
{
+ int idx = rf->channel-1;
u8 rfcsr;
rt2800_rfcsr_write(rt2x00dev, 8, rf->rf1);
@@ -3001,60 +3002,56 @@ static void rt2800_config_channel_rf53xx(struct rt2x00_dev *rt2x00dev,
rt2800_freq_cal_mode1(rt2x00dev);
- if (rf->channel <= 14) {
- int idx = rf->channel-1;
-
- if (rt2x00_has_cap_bt_coexist(rt2x00dev)) {
- if (rt2x00_rt_rev_gte(rt2x00dev, RT5390, REV_RT5390F)) {
- /* r55/r59 value array of channel 1~14 */
- static const char r55_bt_rev[] = {0x83, 0x83,
- 0x83, 0x73, 0x73, 0x63, 0x53, 0x53,
- 0x53, 0x43, 0x43, 0x43, 0x43, 0x43};
- static const char r59_bt_rev[] = {0x0e, 0x0e,
- 0x0e, 0x0e, 0x0e, 0x0b, 0x0a, 0x09,
- 0x07, 0x07, 0x07, 0x07, 0x07, 0x07};
-
- rt2800_rfcsr_write(rt2x00dev, 55,
- r55_bt_rev[idx]);
- rt2800_rfcsr_write(rt2x00dev, 59,
- r59_bt_rev[idx]);
- } else {
- static const char r59_bt[] = {0x8b, 0x8b, 0x8b,
- 0x8b, 0x8b, 0x8b, 0x8b, 0x8a, 0x89,
- 0x88, 0x88, 0x86, 0x85, 0x84};
-
- rt2800_rfcsr_write(rt2x00dev, 59, r59_bt[idx]);
- }
+ if (rt2x00_has_cap_bt_coexist(rt2x00dev)) {
+ if (rt2x00_rt_rev_gte(rt2x00dev, RT5390, REV_RT5390F)) {
+ /* r55/r59 value array of channel 1~14 */
+ static const char r55_bt_rev[] = {0x83, 0x83,
+ 0x83, 0x73, 0x73, 0x63, 0x53, 0x53,
+ 0x53, 0x43, 0x43, 0x43, 0x43, 0x43};
+ static const char r59_bt_rev[] = {0x0e, 0x0e,
+ 0x0e, 0x0e, 0x0e, 0x0b, 0x0a, 0x09,
+ 0x07, 0x07, 0x07, 0x07, 0x07, 0x07};
+
+ rt2800_rfcsr_write(rt2x00dev, 55,
+ r55_bt_rev[idx]);
+ rt2800_rfcsr_write(rt2x00dev, 59,
+ r59_bt_rev[idx]);
} else {
- if (rt2x00_rt_rev_gte(rt2x00dev, RT5390, REV_RT5390F)) {
- static const char r55_nonbt_rev[] = {0x23, 0x23,
- 0x23, 0x23, 0x13, 0x13, 0x03, 0x03,
- 0x03, 0x03, 0x03, 0x03, 0x03, 0x03};
- static const char r59_nonbt_rev[] = {0x07, 0x07,
- 0x07, 0x07, 0x07, 0x07, 0x07, 0x07,
- 0x07, 0x07, 0x06, 0x05, 0x04, 0x04};
-
- rt2800_rfcsr_write(rt2x00dev, 55,
- r55_nonbt_rev[idx]);
- rt2800_rfcsr_write(rt2x00dev, 59,
- r59_nonbt_rev[idx]);
- } else if (rt2x00_rt(rt2x00dev, RT5390) ||
- rt2x00_rt(rt2x00dev, RT5392) ||
- rt2x00_rt(rt2x00dev, RT6352)) {
- static const char r59_non_bt[] = {0x8f, 0x8f,
- 0x8f, 0x8f, 0x8f, 0x8f, 0x8f, 0x8d,
- 0x8a, 0x88, 0x88, 0x87, 0x87, 0x86};
-
- rt2800_rfcsr_write(rt2x00dev, 59,
- r59_non_bt[idx]);
- } else if (rt2x00_rt(rt2x00dev, RT5350)) {
- static const char r59_non_bt[] = {0x0b, 0x0b,
- 0x0b, 0x0b, 0x0b, 0x0b, 0x0b, 0x0a,
- 0x0a, 0x09, 0x08, 0x07, 0x07, 0x06};
-
- rt2800_rfcsr_write(rt2x00dev, 59,
- r59_non_bt[idx]);
- }
+ static const char r59_bt[] = {0x8b, 0x8b, 0x8b,
+ 0x8b, 0x8b, 0x8b, 0x8b, 0x8a, 0x89,
+ 0x88, 0x88, 0x86, 0x85, 0x84};
+
+ rt2800_rfcsr_write(rt2x00dev, 59, r59_bt[idx]);
+ }
+ } else {
+ if (rt2x00_rt_rev_gte(rt2x00dev, RT5390, REV_RT5390F)) {
+ static const char r55_nonbt_rev[] = {0x23, 0x23,
+ 0x23, 0x23, 0x13, 0x13, 0x03, 0x03,
+ 0x03, 0x03, 0x03, 0x03, 0x03, 0x03};
+ static const char r59_nonbt_rev[] = {0x07, 0x07,
+ 0x07, 0x07, 0x07, 0x07, 0x07, 0x07,
+ 0x07, 0x07, 0x06, 0x05, 0x04, 0x04};
+
+ rt2800_rfcsr_write(rt2x00dev, 55,
+ r55_nonbt_rev[idx]);
+ rt2800_rfcsr_write(rt2x00dev, 59,
+ r59_nonbt_rev[idx]);
+ } else if (rt2x00_rt(rt2x00dev, RT5390) ||
+ rt2x00_rt(rt2x00dev, RT5392) ||
+ rt2x00_rt(rt2x00dev, RT6352)) {
+ static const char r59_non_bt[] = {0x8f, 0x8f,
+ 0x8f, 0x8f, 0x8f, 0x8f, 0x8f, 0x8d,
+ 0x8a, 0x88, 0x88, 0x87, 0x87, 0x86};
+
+ rt2800_rfcsr_write(rt2x00dev, 59,
+ r59_non_bt[idx]);
+ } else if (rt2x00_rt(rt2x00dev, RT5350)) {
+ static const char r59_non_bt[] = {0x0b, 0x0b,
+ 0x0b, 0x0b, 0x0b, 0x0b, 0x0b, 0x0a,
+ 0x0a, 0x09, 0x08, 0x07, 0x07, 0x06};
+
+ rt2800_rfcsr_write(rt2x00dev, 59,
+ r59_non_bt[idx]);
}
}
}
--
2.7.5
From: Tomislav Požega <[email protected]>
Register 66 was causing issues on RT6352 if set to the same value as
in MTK driver. With 1c reg value device was working fine in both HT20
and HT40 modes.
Signed-off-by: Tomislav Požega <[email protected]>
Signed-off-by: Stanislaw Gruszka <[email protected]>
---
drivers/net/wireless/ralink/rt2x00/rt2800lib.c | 6 +-----
1 file changed, 1 insertion(+), 5 deletions(-)
diff --git a/drivers/net/wireless/ralink/rt2x00/rt2800lib.c b/drivers/net/wireless/ralink/rt2x00/rt2800lib.c
index 1a2bf6c49b82..3a04eaef8511 100644
--- a/drivers/net/wireless/ralink/rt2x00/rt2800lib.c
+++ b/drivers/net/wireless/ralink/rt2x00/rt2800lib.c
@@ -3981,11 +3981,7 @@ static void rt2800_config_channel(struct rt2x00_dev *rt2x00dev,
rt2800_bbp_write(rt2x00dev, 196, reg);
/* AGC init */
- if (rt2x00_rt(rt2x00dev, RT6352))
- reg = 0x04;
- else
- reg = rf->channel <= 14 ? 0x1c : 0x24;
-
+ reg = rf->channel <= 14 ? 0x1c : 0x24;
reg += 2 * rt2x00dev->lna_gain;
rt2800_bbp_write_with_rx_chain(rt2x00dev, 66, reg);
--
2.7.5
From: Tomislav Požega <[email protected]>
Use default value of TX_SW_CFG2 register that is in charge
of LNA timings. Works for somewhat higher RX throughput.
Signed-off-by: Tomislav Požega <[email protected]>
---
drivers/net/wireless/ralink/rt2x00/rt2800lib.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/wireless/ralink/rt2x00/rt2800lib.c b/drivers/net/wireless/ralink/rt2x00/rt2800lib.c
index 3a04eaef8511..daf20d7424ac 100644
--- a/drivers/net/wireless/ralink/rt2x00/rt2800lib.c
+++ b/drivers/net/wireless/ralink/rt2x00/rt2800lib.c
@@ -5465,7 +5465,7 @@ static int rt2800_init_registers(struct rt2x00_dev *rt2x00dev)
} else if (rt2x00_rt(rt2x00dev, RT6352)) {
rt2800_register_write(rt2x00dev, TX_SW_CFG0, 0x00000401);
rt2800_register_write(rt2x00dev, TX_SW_CFG1, 0x000C0000);
- rt2800_register_write(rt2x00dev, TX_SW_CFG2, 0x00000000);
+ rt2800_register_write(rt2x00dev, TX_SW_CFG2, 0x000C0408);
rt2800_register_write(rt2x00dev, MIMO_PS_CFG, 0x00000002);
rt2800_register_write(rt2x00dev, TX_PIN_CFG, 0x00150F0F);
rt2800_register_write(rt2x00dev, TX_ALC_VGA3, 0x06060606);
--
2.7.5
There is duplicated 'if (rt2x00_rt(rt2x00dev, RT6352))' entry that
causes we do not perform register initialization for RT6352 (MT7620
SOCs) in correct branch. Fix this and disable registers initialization
that is specific to particular MT7620 revision.
Signed-off-by: Stanislaw Gruszka <[email protected]>
---
drivers/net/wireless/ralink/rt2x00/rt2800lib.c | 8 ++++++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/drivers/net/wireless/ralink/rt2x00/rt2800lib.c b/drivers/net/wireless/ralink/rt2x00/rt2800lib.c
index daf20d7424ac..16d6d99b1d44 100644
--- a/drivers/net/wireless/ralink/rt2x00/rt2800lib.c
+++ b/drivers/net/wireless/ralink/rt2x00/rt2800lib.c
@@ -5451,8 +5451,7 @@ static int rt2800_init_registers(struct rt2x00_dev *rt2x00dev)
0x00000000);
}
} else if (rt2x00_rt(rt2x00dev, RT5390) ||
- rt2x00_rt(rt2x00dev, RT5392) ||
- rt2x00_rt(rt2x00dev, RT6352)) {
+ rt2x00_rt(rt2x00dev, RT5392)) {
rt2800_register_write(rt2x00dev, TX_SW_CFG0, 0x00000404);
rt2800_register_write(rt2x00dev, TX_SW_CFG1, 0x00080606);
rt2800_register_write(rt2x00dev, TX_SW_CFG2, 0x00000000);
@@ -5466,6 +5465,10 @@ static int rt2800_init_registers(struct rt2x00_dev *rt2x00dev)
rt2800_register_write(rt2x00dev, TX_SW_CFG0, 0x00000401);
rt2800_register_write(rt2x00dev, TX_SW_CFG1, 0x000C0000);
rt2800_register_write(rt2x00dev, TX_SW_CFG2, 0x000C0408);
+ /* TODO add chip version support and init registers
+ * according to the version.
+ */
+#if 0
rt2800_register_write(rt2x00dev, MIMO_PS_CFG, 0x00000002);
rt2800_register_write(rt2x00dev, TX_PIN_CFG, 0x00150F0F);
rt2800_register_write(rt2x00dev, TX_ALC_VGA3, 0x06060606);
@@ -5480,6 +5483,7 @@ static int rt2800_init_registers(struct rt2x00_dev *rt2x00dev)
reg = rt2800_register_read(rt2x00dev, TX_ALC_CFG_1);
rt2x00_set_field32(®, TX_ALC_CFG_1_ROS_BUSY_EN, 0);
rt2800_register_write(rt2x00dev, TX_ALC_CFG_1, reg);
+#endif
} else {
rt2800_register_write(rt2x00dev, TX_SW_CFG0, 0x00000000);
rt2800_register_write(rt2x00dev, TX_SW_CFG1, 0x00080606);
--
2.7.5
Do not enable TX_PIN_CFG_LNA_PE_A* bits for 2.4GHz band and
vice versa TX_PIN_CFG_LNA_PE_G* bits for 5GHz.
Signed-off-by: Stanislaw Gruszka <[email protected]>
---
drivers/net/wireless/ralink/rt2x00/rt2800lib.c | 18 ++++++++++++------
1 file changed, 12 insertions(+), 6 deletions(-)
diff --git a/drivers/net/wireless/ralink/rt2x00/rt2800lib.c b/drivers/net/wireless/ralink/rt2x00/rt2800lib.c
index 16d6d99b1d44..bf0d12c5b2db 100644
--- a/drivers/net/wireless/ralink/rt2x00/rt2800lib.c
+++ b/drivers/net/wireless/ralink/rt2x00/rt2800lib.c
@@ -3891,18 +3891,24 @@ static void rt2800_config_channel(struct rt2x00_dev *rt2x00dev,
switch (rt2x00dev->default_ant.rx_chain_num) {
case 3:
/* Turn on tertiary LNAs */
- rt2x00_set_field32(&tx_pin, TX_PIN_CFG_LNA_PE_A2_EN, 1);
- rt2x00_set_field32(&tx_pin, TX_PIN_CFG_LNA_PE_G2_EN, 1);
+ rt2x00_set_field32(&tx_pin, TX_PIN_CFG_LNA_PE_A2_EN,
+ rf->channel > 14);
+ rt2x00_set_field32(&tx_pin, TX_PIN_CFG_LNA_PE_G2_EN,
+ rf->channel <= 14);
/* fall-through */
case 2:
/* Turn on secondary LNAs */
- rt2x00_set_field32(&tx_pin, TX_PIN_CFG_LNA_PE_A1_EN, 1);
- rt2x00_set_field32(&tx_pin, TX_PIN_CFG_LNA_PE_G1_EN, 1);
+ rt2x00_set_field32(&tx_pin, TX_PIN_CFG_LNA_PE_A1_EN,
+ rf->channel > 14);
+ rt2x00_set_field32(&tx_pin, TX_PIN_CFG_LNA_PE_G1_EN,
+ rf->channel <= 14);
/* fall-through */
case 1:
/* Turn on primary LNAs */
- rt2x00_set_field32(&tx_pin, TX_PIN_CFG_LNA_PE_A0_EN, 1);
- rt2x00_set_field32(&tx_pin, TX_PIN_CFG_LNA_PE_G0_EN, 1);
+ rt2x00_set_field32(&tx_pin, TX_PIN_CFG_LNA_PE_A0_EN,
+ rf->channel > 14);
+ rt2x00_set_field32(&tx_pin, TX_PIN_CFG_LNA_PE_G0_EN,
+ rf->channel <= 14);
break;
}
--
2.7.5
The TX_PIN_CFG_RFRX_EN bit was not set on other devices than MT7620,
restore old behavaviour since setting this bit maight not be
correct for older devices.
Fixes: 41977e86c984 ("rt2x00: add support for MT7620")
Signed-off-by: Stanislaw Gruszka <[email protected]>
---
drivers/net/wireless/ralink/rt2x00/rt2800lib.c | 7 ++++---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/net/wireless/ralink/rt2x00/rt2800lib.c b/drivers/net/wireless/ralink/rt2x00/rt2800lib.c
index bf0d12c5b2db..d0af0d9d2550 100644
--- a/drivers/net/wireless/ralink/rt2x00/rt2800lib.c
+++ b/drivers/net/wireless/ralink/rt2x00/rt2800lib.c
@@ -3856,10 +3856,12 @@ static void rt2800_config_channel(struct rt2x00_dev *rt2x00dev,
if (rt2x00_rt(rt2x00dev, RT3572))
rt2800_rfcsr_write(rt2x00dev, 8, 0);
- if (rt2x00_rt(rt2x00dev, RT6352))
+ if (rt2x00_rt(rt2x00dev, RT6352)) {
tx_pin = rt2800_register_read(rt2x00dev, TX_PIN_CFG);
- else
+ rt2x00_set_field32(&tx_pin, TX_PIN_CFG_RFRX_EN, 1);
+ } else {
tx_pin = 0;
+ }
switch (rt2x00dev->default_ant.tx_chain_num) {
case 3:
@@ -3914,7 +3916,6 @@ static void rt2800_config_channel(struct rt2x00_dev *rt2x00dev,
rt2x00_set_field32(&tx_pin, TX_PIN_CFG_RFTR_EN, 1);
rt2x00_set_field32(&tx_pin, TX_PIN_CFG_TRSW_EN, 1);
- rt2x00_set_field32(&tx_pin, TX_PIN_CFG_RFRX_EN, 1); /* mt7620 */
rt2800_register_write(rt2x00dev, TX_PIN_CFG, tx_pin);
--
2.7.5
Remove rt2x00_rt(rt2x00dev, RT6352)) check from
rt2800_config_channel_rf53xx() which is not called for RT6352 devices.
Signed-off-by: Stanislaw Gruszka <[email protected]>
---
drivers/net/wireless/ralink/rt2x00/rt2800lib.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/net/wireless/ralink/rt2x00/rt2800lib.c b/drivers/net/wireless/ralink/rt2x00/rt2800lib.c
index d0af0d9d2550..ba7470897f3c 100644
--- a/drivers/net/wireless/ralink/rt2x00/rt2800lib.c
+++ b/drivers/net/wireless/ralink/rt2x00/rt2800lib.c
@@ -3037,8 +3037,7 @@ static void rt2800_config_channel_rf53xx(struct rt2x00_dev *rt2x00dev,
rt2800_rfcsr_write(rt2x00dev, 59,
r59_nonbt_rev[idx]);
} else if (rt2x00_rt(rt2x00dev, RT5390) ||
- rt2x00_rt(rt2x00dev, RT5392) ||
- rt2x00_rt(rt2x00dev, RT6352)) {
+ rt2x00_rt(rt2x00dev, RT5392)) {
static const char r59_non_bt[] = {0x8f, 0x8f,
0x8f, 0x8f, 0x8f, 0x8f, 0x8f, 0x8d,
0x8a, 0x88, 0x88, 0x87, 0x87, 0x86};
--
2.7.5
We do not need separate lines for calculating register values.
Also add comment that value is different than in vendor driver.
Suggested-by: Daniel Golle <[email protected]>
Signed-off-by: Stanislaw Gruszka <[email protected]>
---
drivers/net/wireless/ralink/rt2x00/rt2800lib.c | 9 ++++++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/drivers/net/wireless/ralink/rt2x00/rt2800lib.c b/drivers/net/wireless/ralink/rt2x00/rt2800lib.c
index ba7470897f3c..29b08d63e95b 100644
--- a/drivers/net/wireless/ralink/rt2x00/rt2800lib.c
+++ b/drivers/net/wireless/ralink/rt2x00/rt2800lib.c
@@ -3986,9 +3986,12 @@ static void rt2800_config_channel(struct rt2x00_dev *rt2x00dev,
rt2800_bbp_write(rt2x00dev, 195, 141);
rt2800_bbp_write(rt2x00dev, 196, reg);
- /* AGC init */
- reg = rf->channel <= 14 ? 0x1c : 0x24;
- reg += 2 * rt2x00dev->lna_gain;
+ /* AGC init.
+ * Despite the vendor driver using different values here for
+ * RT6352 chip, we use 0x1c for now. This may have to be changed
+ * once TSSI got implemented.
+ */
+ reg = (rf->channel <= 14 ? 0x1c : 0x24) + 2*rt2x00dev->lna_gain;
rt2800_bbp_write_with_rx_chain(rt2x00dev, 66, reg);
rt2800_iq_calibrate(rt2x00dev, rf->channel);
--
2.7.5
chip version support exist in daniel's tree since a long time ago. so
don't disable registers initialization but try to upstream his
changes.
changing TX_SW_CFG* entries did not make any noticeable difference in
my tests either, besides small RX improvement with configured
TX_SW_CFG2.
waiting for more of your test results
On 12/10/2018, Stanislaw Gruszka <[email protected]> wrote:
> There is duplicated 'if (rt2x00_rt(rt2x00dev, RT6352))' entry that
> causes we do not perform register initialization for RT6352 (MT7620
> SOCs) in correct branch. Fix this and disable registers initialization
> that is specific to particular MT7620 revision.
>
> Signed-off-by: Stanislaw Gruszka <[email protected]>
> ---
> drivers/net/wireless/ralink/rt2x00/rt2800lib.c | 8 ++++++--
> 1 file changed, 6 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/net/wireless/ralink/rt2x00/rt2800lib.c
> b/drivers/net/wireless/ralink/rt2x00/rt2800lib.c
> index daf20d7424ac..16d6d99b1d44 100644
> --- a/drivers/net/wireless/ralink/rt2x00/rt2800lib.c
> +++ b/drivers/net/wireless/ralink/rt2x00/rt2800lib.c
> @@ -5451,8 +5451,7 @@ static int rt2800_init_registers(struct rt2x00_dev
> *rt2x00dev)
> 0x00000000);
> }
> } else if (rt2x00_rt(rt2x00dev, RT5390) ||
> - rt2x00_rt(rt2x00dev, RT5392) ||
> - rt2x00_rt(rt2x00dev, RT6352)) {
> + rt2x00_rt(rt2x00dev, RT5392)) {
> rt2800_register_write(rt2x00dev, TX_SW_CFG0, 0x00000404);
> rt2800_register_write(rt2x00dev, TX_SW_CFG1, 0x00080606);
> rt2800_register_write(rt2x00dev, TX_SW_CFG2, 0x00000000);
> @@ -5466,6 +5465,10 @@ static int rt2800_init_registers(struct rt2x00_dev
> *rt2x00dev)
> rt2800_register_write(rt2x00dev, TX_SW_CFG0, 0x00000401);
> rt2800_register_write(rt2x00dev, TX_SW_CFG1, 0x000C0000);
> rt2800_register_write(rt2x00dev, TX_SW_CFG2, 0x000C0408);
> + /* TODO add chip version support and init registers
> + * according to the version.
> + */
> +#if 0
> rt2800_register_write(rt2x00dev, MIMO_PS_CFG, 0x00000002);
> rt2800_register_write(rt2x00dev, TX_PIN_CFG, 0x00150F0F);
> rt2800_register_write(rt2x00dev, TX_ALC_VGA3, 0x06060606);
> @@ -5480,6 +5483,7 @@ static int rt2800_init_registers(struct rt2x00_dev
> *rt2x00dev)
> reg = rt2800_register_read(rt2x00dev, TX_ALC_CFG_1);
> rt2x00_set_field32(®, TX_ALC_CFG_1_ROS_BUSY_EN, 0);
> rt2800_register_write(rt2x00dev, TX_ALC_CFG_1, reg);
> +#endif
> } else {
> rt2800_register_write(rt2x00dev, TX_SW_CFG0, 0x00000000);
> rt2800_register_write(rt2x00dev, TX_SW_CFG1, 0x00080606);
> --
> 2.7.5
>
>
is there some specific reason to read TX_PIN_CFG register on RT6352,
rather than just null it before programming in tx values like in other
chips?
On 12/10/2018, Stanislaw Gruszka <[email protected]> wrote:
> The TX_PIN_CFG_RFRX_EN bit was not set on other devices than MT7620,
> restore old behavaviour since setting this bit maight not be
> correct for older devices.
>
> Fixes: 41977e86c984 ("rt2x00: add support for MT7620")
> Signed-off-by: Stanislaw Gruszka <[email protected]>
> ---
> drivers/net/wireless/ralink/rt2x00/rt2800lib.c | 7 ++++---
> 1 file changed, 4 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/net/wireless/ralink/rt2x00/rt2800lib.c
> b/drivers/net/wireless/ralink/rt2x00/rt2800lib.c
> index bf0d12c5b2db..d0af0d9d2550 100644
> --- a/drivers/net/wireless/ralink/rt2x00/rt2800lib.c
> +++ b/drivers/net/wireless/ralink/rt2x00/rt2800lib.c
> @@ -3856,10 +3856,12 @@ static void rt2800_config_channel(struct rt2x00_dev
> *rt2x00dev,
> if (rt2x00_rt(rt2x00dev, RT3572))
> rt2800_rfcsr_write(rt2x00dev, 8, 0);
>
> - if (rt2x00_rt(rt2x00dev, RT6352))
> + if (rt2x00_rt(rt2x00dev, RT6352)) {
> tx_pin = rt2800_register_read(rt2x00dev, TX_PIN_CFG);
> - else
> + rt2x00_set_field32(&tx_pin, TX_PIN_CFG_RFRX_EN, 1);
> + } else {
> tx_pin = 0;
> + }
>
> switch (rt2x00dev->default_ant.tx_chain_num) {
> case 3:
> @@ -3914,7 +3916,6 @@ static void rt2800_config_channel(struct rt2x00_dev
> *rt2x00dev,
>
> rt2x00_set_field32(&tx_pin, TX_PIN_CFG_RFTR_EN, 1);
> rt2x00_set_field32(&tx_pin, TX_PIN_CFG_TRSW_EN, 1);
> - rt2x00_set_field32(&tx_pin, TX_PIN_CFG_RFRX_EN, 1); /* mt7620 */
>
> rt2800_register_write(rt2x00dev, TX_PIN_CFG, tx_pin);
>
> --
> 2.7.5
>
>
On Fri, Oct 12, 2018 at 12:48:07PM +0200, Tom Psyborg wrote:
> chip version support exist in daniel's tree since a long time ago. so
> don't disable registers initialization but try to upstream his
> changes.
I do not see reason for for blocking this change because some other
changes are not unstreamed yet. When chip version support will
be unstreamed, the register initialization will be unblocked.
Regards.
Stanislaw
On Fri, Oct 12, 2018 at 12:52:13PM +0200, Tom Psyborg wrote:
> is there some specific reason to read TX_PIN_CFG register on RT6352,
> rather than just null it before programming in tx values like in other
> chips?
I don't remember the details, but Daniel explained that tere are
some bits in the TX_PIN_CFG register that have to be preserved
for RT6352.
Regards
Stanislaw
it will cause regression on other devices
On 12/10/2018, Stanislaw Gruszka <[email protected]> wrote:
> On Fri, Oct 12, 2018 at 12:48:07PM +0200, Tom Psyborg wrote:
>> chip version support exist in daniel's tree since a long time ago. so
>> don't disable registers initialization but try to upstream his
>> changes.
>
> I do not see reason for for blocking this change because some other
> changes are not unstreamed yet. When chip version support will
> be unstreamed, the register initialization will be unblocked.
>
> Regards.
> Stanislaw
>
Please stop top-posting.
On Fri, Oct 12, 2018 at 01:51:00PM +0200, Tom Psyborg wrote:
> it will cause regression on other devices
How exactly ? On upstream tree where this patch is intended
additional registers where never programmed as proper branch
were never used, because of additional check in RT5390 branch.
Patch does only change TX_SW_CFG* regs values for RT6352.
Thanks
Stanislaw
On 12/10/2018, Stanislaw Gruszka <[email protected]> wrote:
> Please stop top-posting.
>
> On Fri, Oct 12, 2018 at 01:51:00PM +0200, Tom Psyborg wrote:
>> it will cause regression on other devices
>
> How exactly ?
the same way your wifi works without TX_SW_CFG entries and mine
doesn't, while both are RT6352
> On upstream tree where this patch is intended
> additional registers where never programmed as proper branch
> were never used, because of additional check in RT5390 branch.
>
on my hardware additional registers were programmed in regardless of
redundant check. that why i opened whole thread on forum since i
couldn't understand how's that happening
> Patch does only change TX_SW_CFG* regs values for RT6352.
>
i'd still prefer that we include CONFIG_RT2800SOC, and if required
move rest of the registers to that check, because at least on my
hardware driver would still recognize chip as RT5390 despite the
RT6352 defines
On Fri, Oct 12, 2018 at 02:20:07PM +0200, Tom Psyborg wrote:
> > On upstream tree where this patch is intended
> > additional registers where never programmed as proper branch
> > were never used, because of additional check in RT5390 branch.
> >
>
> on my hardware additional registers were programmed in regardless of
> redundant check. that why i opened whole thread on forum since i
> couldn't understand how's that happening
I don't understand how that possible either.
> > Patch does only change TX_SW_CFG* regs values for RT6352.
> >
>
> i'd still prefer that we include CONFIG_RT2800SOC, and if required
> move rest of the registers to that check, because at least on my
> hardware driver would still recognize chip as RT5390 despite the
> RT6352 defines
As I pointed before you should add additional printk's and provide
dmesg to make us see what is going on.
Thanks
Stanislaw
On 12/10/2018, Stanislaw Gruszka <[email protected]> wrote:
> On Fri, Oct 12, 2018 at 02:20:07PM +0200, Tom Psyborg wrote:
>> > On upstream tree where this patch is intended
>> > additional registers where never programmed as proper branch
>> > were never used, because of additional check in RT5390 branch.
>> >
>>
>> on my hardware additional registers were programmed in regardless of
>> redundant check. that why i opened whole thread on forum since i
>> couldn't understand how's that happening
>
> I don't understand how that possible either.
i'd assume because device use external lna
>
>> > Patch does only change TX_SW_CFG* regs values for RT6352.
>> >
>>
>> i'd still prefer that we include CONFIG_RT2800SOC, and if required
>> move rest of the registers to that check, because at least on my
>> hardware driver would still recognize chip as RT5390 despite the
>> RT6352 defines
>
> As I pointed before you should add additional printk's and provide
> dmesg to make us see what is going on.
sorry,my hardware is broken, maybe somebody else could provide us with
additional printks
Stanislaw Gruszka <[email protected]> writes:
> There is duplicated 'if (rt2x00_rt(rt2x00dev, RT6352))' entry that
> causes we do not perform register initialization for RT6352 (MT7620
> SOCs) in correct branch. Fix this and disable registers initialization
> that is specific to particular MT7620 revision.
>
> Signed-off-by: Stanislaw Gruszka <[email protected]>
[...]
> @@ -5466,6 +5465,10 @@ static int rt2800_init_registers(struct rt2x00_dev *rt2x00dev)
> rt2800_register_write(rt2x00dev, TX_SW_CFG0, 0x00000401);
> rt2800_register_write(rt2x00dev, TX_SW_CFG1, 0x000C0000);
> rt2800_register_write(rt2x00dev, TX_SW_CFG2, 0x000C0408);
> + /* TODO add chip version support and init registers
> + * according to the version.
> + */
> +#if 0
> rt2800_register_write(rt2x00dev, MIMO_PS_CFG, 0x00000002);
> rt2800_register_write(rt2x00dev, TX_PIN_CFG, 0x00150F0F);
> rt2800_register_write(rt2x00dev, TX_ALC_VGA3, 0x06060606);
> @@ -5480,6 +5483,7 @@ static int rt2800_init_registers(struct rt2x00_dev *rt2x00dev)
> reg = rt2800_register_read(rt2x00dev, TX_ALC_CFG_1);
> rt2x00_set_field32(®, TX_ALC_CFG_1_ROS_BUSY_EN, 0);
> rt2800_register_write(rt2x00dev, TX_ALC_CFG_1, reg);
> +#endif
No '#if 0', please. If the code is not needed you can remove it, it's
available from git history anyway if it's needed later.
--
Kalle Valo
On Sat, Oct 13, 2018 at 12:46:54PM +0300, Kalle Valo wrote:
> No '#if 0', please. If the code is not needed you can remove it, it's
> available from git history anyway if it's needed later.
Plase drop this patch, other patches from the set can be applied
without it.
Thanks
Stanislaw
On Fri, Oct 12, 2018 at 02:41:41PM +0200, Tom Psyborg wrote:
> On 12/10/2018, Stanislaw Gruszka <[email protected]> wrote:
> > On Fri, Oct 12, 2018 at 02:20:07PM +0200, Tom Psyborg wrote:
> >> > On upstream tree where this patch is intended
> >> > additional registers where never programmed as proper branch
> >> > were never used, because of additional check in RT5390 branch.
> >> >
> >>
> >> on my hardware additional registers were programmed in regardless of
> >> redundant check. that why i opened whole thread on forum since i
> >> couldn't understand how's that happening
> >
> > I don't understand how that possible either.
>
> i'd assume because device use external lna
I have no idea how this could be related. But I think I found
somewhat reasonable explenation where the problem is.
I think below code :
if (a || b || c) {
CODE1();
} else if (c) {
CODE2();
}
can not be deterministic and can be compiled differently depending
on compiler version and used options. Sometimes it could result
in this
if (a || b || c) {
CODE1();
}
and sometimes in this:
if (a || b) {
CODE1();
} else if (c) {
CODE2();
}
So that would explain the problems you see. And indeed patch
could cause regression on systems where second variant of
initalizing RT6352 registers was used.
Thanks
Stanislaw
On Fri, Oct 12, 2018 at 12:48:07PM +0200, Tom Psyborg wrote:
> chip version support exist in daniel's tree since a long time ago. so
> don't disable registers initialization but try to upstream his
> changes.
Where is this patch ? I can not find it.
Thanks
Stanislaw
On Tue, Oct 16, 2018 at 10:11:16AM +0200, Stanislaw Gruszka wrote:
> On Fri, Oct 12, 2018 at 12:48:07PM +0200, Tom Psyborg wrote:
> > chip version support exist in daniel's tree since a long time ago. so
> > don't disable registers initialization but try to upstream his
> > changes.
>
> Where is this patch ? I can not find it.
So this requires to make the chip version and package available to
drivers like rt2x00. First of all, this is a patch for linux-mips:
https://git.openwrt.org/?p=openwrt/staging/dangole.git;a=blob;f=target/linux/ramips/patches-4.4/300-mt7620-export-chip-version-and-pkg.patch;h=f6aca6c90516f9c534b3c51e9f99dff6a3f41b75;hb=709fe05dfea58728d6accb9fe56c7056d9d0715b
It belongs to this (very outdated) tree:
https://git.openwrt.org/?p=openwrt/staging/dangole.git;a=shortlog;h=refs/heads/differentiate-pkg-ver-eco
I'm not sure whether this is the right way to do this, but it worked.
Cheers
Daniel
>
> Thanks
> Stanislaw
On 2018-10-16 10:09, Stanislaw Gruszka wrote:
> On Fri, Oct 12, 2018 at 02:41:41PM +0200, Tom Psyborg wrote:
>> On 12/10/2018, Stanislaw Gruszka <[email protected]> wrote:
>> > On Fri, Oct 12, 2018 at 02:20:07PM +0200, Tom Psyborg wrote:
>> >> > On upstream tree where this patch is intended
>> >> > additional registers where never programmed as proper branch
>> >> > were never used, because of additional check in RT5390 branch.
>> >> >
>> >>
>> >> on my hardware additional registers were programmed in regardless of
>> >> redundant check. that why i opened whole thread on forum since i
>> >> couldn't understand how's that happening
>> >
>> > I don't understand how that possible either.
>>
>> i'd assume because device use external lna
>
> I have no idea how this could be related. But I think I found
> somewhat reasonable explenation where the problem is.
> I think below code :
>
> if (a || b || c) {
> CODE1();
> } else if (c) {
> CODE2();
> }
>
> can not be deterministic and can be compiled differently depending
> on compiler version and used options. Sometimes it could result
> in this
>
> if (a || b || c) {
> CODE1();
> }
>
> and sometimes in this:
>
> if (a || b) {
> CODE1();
> } else if (c) {
> CODE2();
> }
>
> So that would explain the problems you see. And indeed patch
> could cause regression on systems where second variant of
> initalizing RT6352 registers was used.
I don't see how that can be non-deterministic at all. The 'else if' part
can only be hit if the first if did not match.
- Felix
On Tue, Oct 16, 2018 at 01:19:52PM +0200, Felix Fietkau wrote:
> > I have no idea how this could be related. But I think I found
> > somewhat reasonable explenation where the problem is.
> > I think below code :
> >
> > if (a || b || c) {
> > CODE1();
> > } else if (c) {
> > CODE2();
> > }
> >
> > can not be deterministic and can be compiled differently depending
> > on compiler version and used options. Sometimes it could result
> > in this
> >
> > if (a || b || c) {
> > CODE1();
> > }
> >
> > and sometimes in this:
> >
> > if (a || b) {
> > CODE1();
> > } else if (c) {
> > CODE2();
> > }
> >
> > So that would explain the problems you see. And indeed patch
> > could cause regression on systems where second variant of
> > initalizing RT6352 registers was used.
> I don't see how that can be non-deterministic at all. The 'else if' part
> can only be hit if the first if did not match.
I meant non-deterministic during compilation process, when compiler
do or do not some optimizations or if compiler version differs.
Regards
Stanislaw
On 2018-10-16 13:21, Stanislaw Gruszka wrote:
> On Tue, Oct 16, 2018 at 01:19:52PM +0200, Felix Fietkau wrote:
>> > I have no idea how this could be related. But I think I found
>> > somewhat reasonable explenation where the problem is.
>> > I think below code :
>> >
>> > if (a || b || c) {
>> > CODE1();
>> > } else if (c) {
>> > CODE2();
>> > }
>> >
>> > can not be deterministic and can be compiled differently depending
>> > on compiler version and used options. Sometimes it could result
>> > in this
>> >
>> > if (a || b || c) {
>> > CODE1();
>> > }
>> >
>> > and sometimes in this:
>> >
>> > if (a || b) {
>> > CODE1();
>> > } else if (c) {
>> > CODE2();
>> > }
>> >
>> > So that would explain the problems you see. And indeed patch
>> > could cause regression on systems where second variant of
>> > initalizing RT6352 registers was used.
>> I don't see how that can be non-deterministic at all. The 'else if' part
>> can only be hit if the first if did not match.
>
> I meant non-deterministic during compilation process, when compiler
> do or do not some optimizations or if compiler version differs.
In my opinion, this is not C undefined behavior territory. The compiler
is not allowed to change the behavior here based on optimization settings.
- Felix
On 16/10/2018, Stanislaw Gruszka <[email protected]> wrote:
> On Fri, Oct 12, 2018 at 02:41:41PM +0200, Tom Psyborg wrote:
>> On 12/10/2018, Stanislaw Gruszka <[email protected]> wrote:
>> > On Fri, Oct 12, 2018 at 02:20:07PM +0200, Tom Psyborg wrote:
>> >> > On upstream tree where this patch is intended
>> >> > additional registers where never programmed as proper branch
>> >> > were never used, because of additional check in RT5390 branch.
>> >> >
>> >>
>> >> on my hardware additional registers were programmed in regardless of
>> >> redundant check. that why i opened whole thread on forum since i
>> >> couldn't understand how's that happening
>> >
>> > I don't understand how that possible either.
>>
>> i'd assume because device use external lna
>
> I have no idea how this could be related. But I think I found
> somewhat reasonable explenation where the problem is.
> I think below code :
>
> if (a || b || c) {
> CODE1();
> } else if (c) {
> CODE2();
> }
>
> can not be deterministic and can be compiled differently depending
> on compiler version and used options. Sometimes it could result
> in this
>
> if (a || b || c) {
> CODE1();
> }
>
> and sometimes in this:
>
> if (a || b) {
> CODE1();
> } else if (c) {
> CODE2();
> }
>
> So that would explain the problems you see. And indeed patch
> could cause regression on systems where second variant of
> initalizing RT6352 registers was used.
>
> Thanks
> Stanislaw
>
Hi
I am sending you two builds privately so please check if there are any
differences between the two builds and report back. Thanks.
Hello
On Tue, Oct 16, 2018 at 01:32:18PM +0200, Tom Psyborg wrote:
> I am sending you two builds privately so please check if there are any
> differences between the two builds and report back. Thanks.
I extracted rt2800lib.ko module from provided images, did disassembly via:
./staging_dir/toolchain-mipsel_24kc_gcc-7.3.0_musl/bin/mipsel-openwrt-linux-objdump \
-d -r --prefix-addresses ~/rt2800lib-BUILDn.ko > ~/BUILDn.dump.txt
command and compered disassembled code. Here is difference:
$ diff -up BUILD1.dump.txt BUILD2.dump.txt
--- BUILD1.dump.txt 2018-10-16 16:40:34.834220838 +0200
+++ BUILD2.dump.txt 2018-10-16 16:40:40.187219211 +0200
@@ -1,5 +1,5 @@
-/home/stasiu/rt2800lib-BUILD1.ko: file format elf32-tradlittlemips
+/home/stasiu/rt2800lib-BUILD2.ko: file format elf32-tradlittlemips
Disassembly of section .text:
@@ -9374,7 +9374,7 @@ Disassembly of section .text:
00007f80 <rt2800_clear_beacon+0x224> jalr v0
00007f84 <rt2800_clear_beacon+0x228> move a0,s0
00007f88 <rt2800_clear_beacon+0x22c> lhu v1,732(s0)
-00007f8c <rt2800_clear_beacon+0x230> li v0,21392
+00007f8c <rt2800_clear_beacon+0x230> li v0,25426
00007f90 <rt2800_clear_beacon+0x234> bne v1,v0,0000810c <rt2800_clear_beacon+0x3b0>
00007f94 <rt2800_clear_beacon+0x238> li a2,1025
00007f98 <rt2800_clear_beacon+0x23c> lw v0,4(s0)
There is no difference in init_registers (which is inlined in
rt2800_enable_radio). The only difference is in some number
rt2800_clear_beacon() function.
Regards
Stanislaw
On 16/10/2018, Stanislaw Gruszka <[email protected]> wrote:
> Hello
>
> On Tue, Oct 16, 2018 at 01:32:18PM +0200, Tom Psyborg wrote:
>> I am sending you two builds privately so please check if there are any
>> differences between the two builds and report back. Thanks.
>
> I extracted rt2800lib.ko module from provided images, did disassembly via:
>
> ./staging_dir/toolchain-mipsel_24kc_gcc-7.3.0_musl/bin/mipsel-openwrt-linux-objdump
> \
> -d -r --prefix-addresses ~/rt2800lib-BUILDn.ko > ~/BUILDn.dump.txt
>
> command and compered disassembled code. Here is difference:
>
> $ diff -up BUILD1.dump.txt BUILD2.dump.txt
> --- BUILD1.dump.txt 2018-10-16 16:40:34.834220838 +0200
> +++ BUILD2.dump.txt 2018-10-16 16:40:40.187219211 +0200
> @@ -1,5 +1,5 @@
>
> -/home/stasiu/rt2800lib-BUILD1.ko: file format elf32-tradlittlemips
> +/home/stasiu/rt2800lib-BUILD2.ko: file format elf32-tradlittlemips
>
>
> Disassembly of section .text:
> @@ -9374,7 +9374,7 @@ Disassembly of section .text:
> 00007f80 <rt2800_clear_beacon+0x224> jalr v0
> 00007f84 <rt2800_clear_beacon+0x228> move a0,s0
> 00007f88 <rt2800_clear_beacon+0x22c> lhu v1,732(s0)
> -00007f8c <rt2800_clear_beacon+0x230> li v0,21392
> +00007f8c <rt2800_clear_beacon+0x230> li v0,25426
> 00007f90 <rt2800_clear_beacon+0x234> bne v1,v0,0000810c
> <rt2800_clear_beacon+0x3b0>
> 00007f94 <rt2800_clear_beacon+0x238> li a2,1025
> 00007f98 <rt2800_clear_beacon+0x23c> lw v0,4(s0)
>
> There is no difference in init_registers (which is inlined in
> rt2800_enable_radio). The only difference is in some number
> rt2800_clear_beacon() function.
>
> Regards
> Stanislaw
>
i meant you try it on your nexx device. and post dmesg if you can boot them
On 16/10/2018, Stanislaw Gruszka <[email protected]> wrote:
> Hello
>
> On Tue, Oct 16, 2018 at 01:32:18PM +0200, Tom Psyborg wrote:
>> I am sending you two builds privately so please check if there are any
>> differences between the two builds and report back. Thanks.
>
> I extracted rt2800lib.ko module from provided images, did disassembly via:
>
> ./staging_dir/toolchain-mipsel_24kc_gcc-7.3.0_musl/bin/mipsel-openwrt-linux-objdump
> \
> -d -r --prefix-addresses ~/rt2800lib-BUILDn.ko > ~/BUILDn.dump.txt
>
> command and compered disassembled code. Here is difference:
>
> $ diff -up BUILD1.dump.txt BUILD2.dump.txt
> --- BUILD1.dump.txt 2018-10-16 16:40:34.834220838 +0200
> +++ BUILD2.dump.txt 2018-10-16 16:40:40.187219211 +0200
> @@ -1,5 +1,5 @@
>
> -/home/stasiu/rt2800lib-BUILD1.ko: file format elf32-tradlittlemips
> +/home/stasiu/rt2800lib-BUILD2.ko: file format elf32-tradlittlemips
>
>
> Disassembly of section .text:
> @@ -9374,7 +9374,7 @@ Disassembly of section .text:
> 00007f80 <rt2800_clear_beacon+0x224> jalr v0
> 00007f84 <rt2800_clear_beacon+0x228> move a0,s0
> 00007f88 <rt2800_clear_beacon+0x22c> lhu v1,732(s0)
> -00007f8c <rt2800_clear_beacon+0x230> li v0,21392
> +00007f8c <rt2800_clear_beacon+0x230> li v0,25426
> 00007f90 <rt2800_clear_beacon+0x234> bne v1,v0,0000810c
> <rt2800_clear_beacon+0x3b0>
> 00007f94 <rt2800_clear_beacon+0x238> li a2,1025
> 00007f98 <rt2800_clear_beacon+0x23c> lw v0,4(s0)
>
> There is no difference in init_registers (which is inlined in
> rt2800_enable_radio). The only difference is in some number
> rt2800_clear_beacon() function.
>
> Regards
> Stanislaw
>
hi
i rechecked this and your debug procedure seems to be unreliable.
On Wed, Oct 17, 2018 at 03:25:58PM +0200, Tom Psyborg wrote:
> On 16/10/2018, Stanislaw Gruszka <[email protected]> wrote:
> > On Tue, Oct 16, 2018 at 01:32:18PM +0200, Tom Psyborg wrote:
> >> I am sending you two builds privately so please check if there are any
> >> differences between the two builds and report back. Thanks.
> >
> > I extracted rt2800lib.ko module from provided images, did disassembly via:
> >
> > ./staging_dir/toolchain-mipsel_24kc_gcc-7.3.0_musl/bin/mipsel-openwrt-linux-objdump
> > \
> > -d -r --prefix-addresses ~/rt2800lib-BUILDn.ko > ~/BUILDn.dump.txt
> >
> > command and compered disassembled code. Here is difference:
> >
> > $ diff -up BUILD1.dump.txt BUILD2.dump.txt
> > --- BUILD1.dump.txt 2018-10-16 16:40:34.834220838 +0200
> > +++ BUILD2.dump.txt 2018-10-16 16:40:40.187219211 +0200
> > @@ -1,5 +1,5 @@
> >
> > -/home/stasiu/rt2800lib-BUILD1.ko: file format elf32-tradlittlemips
> > +/home/stasiu/rt2800lib-BUILD2.ko: file format elf32-tradlittlemips
> >
> >
> > Disassembly of section .text:
> > @@ -9374,7 +9374,7 @@ Disassembly of section .text:
> > 00007f80 <rt2800_clear_beacon+0x224> jalr v0
> > 00007f84 <rt2800_clear_beacon+0x228> move a0,s0
> > 00007f88 <rt2800_clear_beacon+0x22c> lhu v1,732(s0)
> > -00007f8c <rt2800_clear_beacon+0x230> li v0,21392
> > +00007f8c <rt2800_clear_beacon+0x230> li v0,25426
> > 00007f90 <rt2800_clear_beacon+0x234> bne v1,v0,0000810c
> > <rt2800_clear_beacon+0x3b0>
> > 00007f94 <rt2800_clear_beacon+0x238> li a2,1025
> > 00007f98 <rt2800_clear_beacon+0x23c> lw v0,4(s0)
> >
> > There is no difference in init_registers (which is inlined in
> > rt2800_enable_radio). The only difference is in some number
> > rt2800_clear_beacon() function.
> >
> > Regards
> > Stanislaw
> >
>
> i meant you try it on your nexx device. and post dmesg if you can boot them
I tried to do this, but somehow after update BUILD1 image into device
my configuration was wiped out :-( and I have to reconfigure the
device now. Anyway I'm going to test and provide dmesg , but this
will take some time.
Regards
Stanislaw
On 19/10/2018, Stanislaw Gruszka <[email protected]> wrote:
>
> I tried to do this, but somehow after update BUILD1 image into device
> my configuration was wiped out :-( and I have to reconfigure the
> device now. Anyway I'm going to test and provide dmesg , but this
> will take some time.
>
> Regards
> Stanislaw
>
that's because these builds were done on 4.4 that i had in my system
and there are config differences between these builds and current
snapshot. to save you time i need only bootlogs not wifi performance
tests.
On Fri, Oct 19, 2018 at 04:21:09PM +0200, Tom Psyborg wrote:
> On 19/10/2018, Stanislaw Gruszka <[email protected]> wrote:
> >
> > I tried to do this, but somehow after update BUILD1 image into device
> > my configuration was wiped out :-( and I have to reconfigure the
> > device now. Anyway I'm going to test and provide dmesg , but this
> > will take some time.
> >
> > Regards
> > Stanislaw
> >
>
> that's because these builds were done on 4.4 that i had in my system
> and there are config differences between these builds and current
> snapshot. to save you time i need only bootlogs not wifi performance
> tests.
So, there is no diffrence in dmesg and device is recognized as RT6352.
I atteched both dmesg's for the record.
Regards
Stanislaw