No, I am done for the day anyway.
I should have some time tommorow midday/late night
1 Like
Ok will try to push it this night (do you mind if i push a very dirty tree? I manually added the 5.10 patches from the commits without cherry-pick the commits)
No, I am fine with dirty trees for deving
Pushed my very dirty repo (don't judge ahahhaha)
Anyway if you really want you can also reproduce the bug on 5.4
Minimal changes are needed to the regulator driver.
For example this is the modified driver for the kernel 5.4 (skipped the check if the regulator is enabled in the set voltage function since the regulator is enabled by just sending the voltage with rpm)
1 Like
I've installed the latest stable build on my R7800. I have noticed some very weird throughput problem on WiFi using my MacBook Pro. In a nutshell:
- Router configured as dumb access point
- Installed release 19.07.5
- Configured 5Ghz band as 80mhz, channel 32 (no conflicting AP's on this)
- Run iPERF3 test between my MacBook Pro Touch Bar 2016 and my home server wired to the AP. Download speed while close to the AP was ~700mbps and upload ~550-600mbps
- Run iPERF3 test between my MacBook Pro Touch Bar 2019 and my home server. Upload speed ~550-600mbps. But the download speed starts at ~350-400mbps and drops to ~150mbps.
- Reverted firmware to stock latest Netgear. Same channel config. Both laptops now download at full speed (~700-750mbps).
Has anyone else encountered this? No routing is done on the AP, just acting as a plain access point. The only reason to use OpenWRT for me is to enable 802.11R for fast roaming.
Thank you!
Stock firmware is faster because more stuff is offloaded by hardware. The hardware offload isn't officially supported by OpenWrt. There are some work being made tho'.
You might have slightly better luck with the master build of OpenWrt. Check out hnyman's build.
@Ansuel Isnt it weird that enable uV/mV functions are not called at all in 5.4?
I see a lot of requests from the kernel checking whether regulators are enabled and all of them show that its not.
I think that the main idea is the fact that most of the times regulator are enabled by the booloader and the kernel doesn't actually needs to enables them. So normally a regulator since it's already enabled and is set like that in the dts with the standard binding (regulator-always-on for example), the set voltage function is used directly without enabling it. In newer kernel they added the extra check and since it doesn't harm, they added the code to enable the regulator the first time the kernel pm try to change frequency.
Yeah, that works only if you actually check in some register and not have the driver simply return 0 if register_enable has never been called.
If you also check the regulator code you can also see that if it's not enabled, the set voltage just set the value in the struct even if nothing has applied. Don't know if this it's right for a normal regulator driver.
Yeah, I was digging through the calls in the RPM driver and I could clearly see that no writes were being done and driver was returning that regulators are not enabled at all.
If I add regulator_enable before regulator_put in cpufreq-dt.c then it will simply hang during the enable call for s2a.
I mean, regulator_put has a huge warning to ensure that regulator_enable was called before it anyway.
So, we have some real RPM issues.
Anyway in our case the enable isn't really needed... I read some comments in the original code from qsdk and the regulator is enabled by just issuing a voltage request to the rpm firmware.
So we actually have 2 kind of command
- set the regulator to this voltage
- disable the regulator if you request a voltage change with the value 0
That is what enable does in RPM, it simply sends a request with a voltage and then if that goes well marks the regulator as enabled.
But the write call obviously freezes the board completely, it does not simply fail but lock the kernel completely.
So if it fails here it will fail on a normal change voltage call.
Do you maybe know the hierachy of the regulators?
Are the s2a and s2b that supply the cores supplied by s1a or s1b or?
Mhh in my case rpm simply rejects it. Can you test one thing? try to remove the enable request and just remove the check in the set voltage for the is_enabled.
In my router, rpm works correctly and reject or accept the request
Or could be that rpm works more or less for r7800 and for your router just crash it.
No idea, but if I fake that regulator is enabled it simply hangs on RPM write.
I mean, I am trying this on a Asrock G10 running the same RPM FW as R7800:
qcom_rpm 108000.rpm: RPM firmware 3.0.16777342
it's ipq8064 or 65? could be that it does freze as the cpu requires more voltage than provided?
Should be IPQ8064
Try to hardcode 1250000 as the voltage in the set voltage function
Don't think the regulators are hierarchical. The SMB208 has a minimum input voltage of 4.5V which is way above what s1a or s1b supply.