Hi,
Am 23.11.2016 um 11:45 schrieb Grazvydas Ignotas notasas@gmail.com:
On Tue, Nov 22, 2016 at 10:49 PM, H. Nikolaus Schaller hns@goldelico.com wrote:
- it shows that the thermal throttling makes clock OPP go down to 750/500 MHz,
sometimes in multiple steps
Hmm still using those TI unsupported low frequencies? I'd drop them just in case they have some problem, they must have had a reason to remove it from mainline.
Well, yes. And we have good reasons to add them... Initially it was to get the boards booted without freezes.
I have tested 6 of the new CPU boards with 1.0GHz and 1.25GHz only and I sometimes get a freeze even with the bash-loop which I didn't see with 500/750 included.
With 500/750/1000/1250 it seems as if the 4GB RAM boards have a slightly higher risk to freeze, but this is not statistically validated.
Anyways this would not be enough reason to keep the lower OPP even when we have fixed the freezes, because there is another effect:
The chips get hotter. During high-load they typically oscillate between 98° and 108° instead of 90 and 100°. The reason seems to be that even with thermal throttling to 1GHz (and not deeper) there is more average energy dissipated inside the chip and this results in a higher average temperature. Well, higher average performance as well :)
This may become a general problem: we might get it up to 1.7GHz peak clock rate by fixing the freeze issue, but thermal throttling might reduce the average clock rate to let's say 1.2GHz. Then it is the same as running them permanently at 1.2GHz.
Also the latest datasheet (swps051k) lists 1.014V as the lowest allowed voltage, I'd not ever go below that in tests like this as you may end up triggering several unrelated issues and then arrive to wrong conclusions.
I have not seen any problem with lower frequency OPPs so far and they significantly reduce power consumption in low-load situations.
So unless we really find a problem I think we better should keep them.
Anyways, having them reduces the 1.25GHz freeze risk a little for the tests I am running.
- since this OPP change also includes VDD-MPU changes (between 1.25V
and 0.85V) it shows that the Palmas regulation works fine
- what makes a really big difference is running the bash-loop vs. the NEON-loop
- high-load freezes almost immediately after switching from 1GHz to 1.25GHz
What about 1.2GHz? ED already announced 1.2GHz as fully working on the forums, but I fear it might actually not work with NEON.
Yes, it is likely that it fails at 1.20GHz as well. Maybe a little later than with 1.25GHz. I will try in the next run.
- it is indeed the Cortex A15 MPU/NEON core and not any peripheral on the OMAP5 SoC
A weird reason could still be that the DRAM interface is used differently/faster if we run NEON at >1GHz. But the EMIF DRAM clock is constant if CPU clock changes.
The test doesn't use memory at all, it operates on registers only, except repeatedly reading and writing to the same locations, which should always hit L1 cache.
OTOH now that I think about it, it might actually start doing writes after a task switch because ARM doesn't write-allocate cache. You can comment out lines with ldrd and strd instructions (add @ at the start of lines 24 and 29) and then there will be no chance for it to do RAM accesses, except kernel reloading the instructions after a task switch (after interrupts or whatever). This should rule out any RAM issue.
Ah, good to know! I will try that next and see if we have any differences. But anyways it becomes more and more clear that we only have a CPU issue and no peripheral or RAM.
BR and thanks, Nikolaus