On 7/27/21 9:50 AM, Josef Schlehofer wrote:
On 24. 07. 21 20:03, Hauke Mehrtens wrote:
On 7/24/21 7:50 PM, Josef Schlehofer wrote:
On 24. 07. 21 19:37, Hauke Mehrtens wrote:
On 7/1/21 11:08 AM, Robert Marko wrote:
On Thu, Jul 1, 2021 at 12:42 AM Marek Behun <marek.be...@nic.cz>
wrote:
On Wed, 30 Jun 2021 17:51:24 +0200
Robert Marko <robert.ma...@sartura.hr> wrote:
On Wed, Jun 30, 2021 at 3:19 PM Marek Behún <marek.be...@nic.cz>
wrote:
Hello Robert,
I am writing regarding commit
mvebu: 5.10 fix DVFS caused random boot crashes
https://git.openwrt.org/?p=openwrt/openwrt.git;a=commit;h=080a0b74e39d159eecf69c468debec42f28bf4d8
in OpenWRT.
This commit reverts the one patch of a3720 cpufreq driver, but not
the subsequent ones.
Your commit message says that some 1.2 GHz SOCs are unstable
with the
fix. Did you also test this with the subsequent patches, which are
now
in stable kernels? I guess the answer is yes, because all these
patches
were backported to 5.10.37.
Hi Marek,
Yes, the rest of the patches were there as well.
I am of the opinion that a better approach would be to
- either disable cpufreq for 1.2 GHz variants
- fix a3720 cpufreq driver to only scale up to 1 GHz on 1.2 GHz
variant
I would prefer limiting it to 1GHz as that would not cause
performance issues,
but 1GHz models could have the same issue as well.
This is because the voltages that are set as a minimum are from the
testing that
Pali and the Turris guys did, but it really depends on the SoC batch
you receive.
Since the approach you've taken now (reverting the patch) basically
changes the CPU parnet clock to DDR clock, which is just wrong.
Worse is that you are doing this for everybody, not just for the
1.2
GHz variants.
What do you think?
I understand that it was not the best solution, but something had
to be done as
I was not able to even finish booting on multiple boards before
crashing.
It just reverted the things back to the previous state.
I really could not figure a proper solution even after being in
touch
with Pali, and contacting
GlobalScale.
This is an issue caused by Marvell simply ignoring the issue and
refusing to publish
a fix or release the OTP and AVS docs as they all have a validated
voltage in the OTP
somewhere.
Robert, we've found this table in linux-marvell repository:
https://github.com/MarvellEmbeddedProcessors/linux-marvell/blob/dc33b62c90696afb6adc7dbcc4ebbd48bedec269/drivers/regulator/armada-37xx-regulator.c#L99-L105
Do you still have the 1.2 GHz boards which were crashing? Would
you be
willing to test whether those boards are stable if we provided patch
for you?
Yes, I tested on 4 boards If I remember correctly and they all crashed
with the voltages that are set,
only by manually raising to at least 1.1902V one got stable while
other required 1.2+V
I would be glad to test a possible solution.
Regards,
Robert
Marek
Hi,
any progress on this?
Are there any patches to avoid the 1.2GHz?
Hello,
The patch [1] was sent to the linux-arm-kernel mailing list, but there
was no response from Marvell even though it was requested multiple
times. Hopefully, it will be merged soon.
[1]
https://lore.kernel.org/linux-arm-kernel/20210630135942.29730-1-ka...@kernel.org/T/
Josef
Hi,
Should we then better revert the patch from Robert and take this
additional patch from Marek even when Marvell does not react?
Does anyone have a better idea?
Hauke
Hello,
Yes, we should do it before there is going to be OpenWrt 21.02 release.
Should I send v2?
Josef
Hi Josef,
Yes, please send a v2.
Hauke
_______________________________________________
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
