Wow this was my exact scenario. Thank you for sharing, and you too @sppmaster!
You may try the patch below from @lynxis and see if it fixes the issue for you:
From 61bc085c21ba4dfd4f841308dc3030afe94bb1b4 Mon Sep 17 00:00:00 2001
From: Alexander Couzens <lynxis@fe80.eu>
Date: Tue, 26 Jul 2022 02:07:44 +0200
Subject: [PATCH] WIP: mt7531: move core pll init, disable port 5 sgmii, power
down port 5 & 6 before reset
---
drivers/net/dsa/mt7530.c | 22 ++++++++++++++++++----
drivers/net/dsa/mt7530.h | 4 ++++
2 files changed, 22 insertions(+), 4 deletions(-)
diff --git a/drivers/net/dsa/mt7530.c b/drivers/net/dsa/mt7530.c
index 835807911be0..1d35a1487822 100644
--- a/drivers/net/dsa/mt7530.c
+++ b/drivers/net/dsa/mt7530.c
@@ -506,7 +506,12 @@ static bool mt7531_dual_sgmii_supported(struct mt7530_priv *priv)
static int
mt7531_pad_setup(struct dsa_switch *ds, phy_interface_t interface)
{
- struct mt7530_priv *priv = ds->priv;
+ return 0;
+}
+
+static int
+mt7531_pll_setup(struct mt7530_priv *priv)
+{
u32 top_sig;
u32 hwstrap;
u32 xtal;
@@ -524,6 +529,11 @@ mt7531_pad_setup(struct dsa_switch *ds, phy_interface_t interface)
else
xtal = hwstrap & HWTRAP_XTAL_FSEL_MASK;
+ /* Disable Port5 SGMII clearly */
+ val = mt7530_read(priv, MT7531_PHYA_ANA_SYSPLL(5));
+ val &= ~MT7531_RG_VUSB10_ON;
+ mt7530_write(priv, MT7531_PHYA_ANA_SYSPLL(5), val);
+
/* Step 1 : Disable MT7531 COREPLL */
val = mt7530_read(priv, MT7531_PLLGP_EN);
val &= ~EN_COREPLL;
@@ -2326,11 +2336,17 @@ mt7531_setup(struct dsa_switch *ds)
return -ENODEV;
}
+ /* shutdown port 5 & 6 before initiating a reset */
+ mt7530_write(priv, MT7530_PMCR_P(5), MT7531_FORCE_LNK);
+ mt7530_write(priv, MT7530_PMCR_P(6), MT7531_FORCE_LNK);
+
/* Reset the switch through internal reset */
mt7530_write(priv, MT7530_SYS_CTRL,
- SYS_CTRL_PHY_RST | SYS_CTRL_SW_RST |
+ SYS_CTRL_SW_RST |
SYS_CTRL_REG_RST);
+ mt7531_pll_setup(priv);
+
if (mt7531_dual_sgmii_supported(priv)) {
priv->p5_intf_sel = P5_INTF_SEL_GMAC5_SGMII;
@@ -2887,8 +2903,6 @@ mt7531_cpu_port_config(struct dsa_switch *ds, int port)
case 6:
interface = PHY_INTERFACE_MODE_2500BASEX;
- mt7531_pad_setup(ds, interface);
-
priv->p6_interface = interface;
break;
default:
diff --git a/drivers/net/dsa/mt7530.h b/drivers/net/dsa/mt7530.h
index e509af95c354..d24b19b5bfc2 100644
--- a/drivers/net/dsa/mt7530.h
+++ b/drivers/net/dsa/mt7530.h
@@ -405,6 +405,10 @@ enum mt7531_sgmii_force_duplex {
#define MT7531_RG_TPHY_SPEED_1_25G 0x0
#define MT7531_RG_TPHY_SPEED_3_125G BIT(2)
+/* SGMII PHYA_ANA_SYSPLL (from Uboot-arm driver) */
+#define MT7531_PHYA_ANA_SYSPLL(p) MT7531_SGMII_REG(p, 0x158)
+#define MT7531_RG_VUSB10_ON BIT(29)
+
/* Register for system reset */
#define MT7530_SYS_CTRL 0x7000
#define SYS_CTRL_PHY_RST BIT(2)
--
2.35.1
Place it in a file e.g. target/linux/generic/hack-5.15/999-WIP-mt7531-move-core-pll-init-disable-port-5-sgmii-p.patch and rebuild kernel.
I switched to the 5.10 kernel / rc5 stable earlier last week or so - is this still applicable?
Is there a wiki/dev readme I should follow (absolute noob here) to ensure I don't mess up the process?
replace hack-5.15 with hack-5.10
1 Like
I've created a pull request https://github.com/openwrt/openwrt/pull/10349
with patches for 5.15 and 5.10 to fix the 100 mbit limit.
8 Likes
Would be great to get those patches into the 22.03 release branch as well, if possible.
RC6 rolling out now.
2 Likes
Largest number of release candidates ever?
1 Like
Note that two were skipped. Tagged but not released (rc2 and rc3)
1 Like
do you think the release can come out this month, and is there such a big difference between rc5 and rc6 because for the moment RC5 works very well on my belkin thanks
RC6 download online: https://downloads.openwrt.org/releases/22.03.0-rc6/targets/mediatek/mt7622/
1 Like
wrong topic ! 
@nbd I'm finding over time the 5ghz wifi radio gets stuck at slow speeds 100mbit vs 800ish with the newer builds.
After installing rc6, I was just poking around and saw this in my rc.local
echo 437500 > /sys/devices/system/cpu/cpufreq/policy0/scaling_min_freq
echo schedutil > /sys/devices/system/cpu/cpufreq/policy0/scaling_governor
and wondered if above workaround was still needed, or if some of the fixes that @daniel outlined were implemented to mitigate the boot hangs people were experiencing?
1 Like
At the very least, the first line shouldn't be required anymore. You shouldn't have any reboot hangs in rc6.
1 Like
I also noticed something similar with an Intel AX210 client: after resuming from sleep, the wireless transfer speed is about 100Mbps. I need to disable / enable the client WiFi adapter to work again at full speed. I don't know if the router is the cause or the client adapter.
Correct, test it with:
# cat /sys/devices/system/cpu/cpu*/cpufreq/scaling_available_frequencies
437500 600000 812500 1025000 1137500 1262500 1350000
437500 600000 812500 1025000 1137500 1262500 1350000
1 Like
Well, like already said, the first line is now unneeded due to the referenced patch.
And the second line should also be unnecessary, as I think that the mt7622 kernel is by default using "userspace" that practically means 100% all the time (unless you have changed a file. See https://kernel.org/doc/Documentation/cpu-freq/governors.txt )
The "schedutil" is an alternative to the traditional "ondemand" scaling but that is also optional.
mt7622 config from master:
97 # CONFIG_CPU_FREQ_DEFAULT_GOV_PERFORMANCE is not set
98 CONFIG_CPU_FREQ_DEFAULT_GOV_USERSPACE=y
99 CONFIG_CPU_FREQ_GOV_ATTR_SET=y
100 CONFIG_CPU_FREQ_GOV_COMMON=y
101 CONFIG_CPU_FREQ_GOV_CONSERVATIVE=y
102 CONFIG_CPU_FREQ_GOV_ONDEMAND=y
103 CONFIG_CPU_FREQ_GOV_PERFORMANCE=y
104 CONFIG_CPU_FREQ_GOV_POWERSAVE=y
105 CONFIG_CPU_FREQ_GOV_SCHEDUTIL=y
106 CONFIG_CPU_FREQ_GOV_USERSPACE=y
4 Likes
You are right @hnyman - I opened https://github.com/openwrt/openwrt/pull/4983 months ago to change that but seems to be of little interest to people.
2 Likes