Hi,
Am 21.09.2016 um 09:53 schrieb Michael Mrozek EvilDragon@openpandora.org:
- Discussion
So this clearly shows that the heat production in the CPU depends on the device tree file and if the mainboard is connected or not.
This is REALLY weird. Why should the OMAP5 produce more heat simply because the mainboard is connected? It doesn't do anything with the additional connected devices if no driver is configured. Unless... could it be that it sees there's something there (like on i2c bus) and it tries to permanently probe that?
Exactly.
But then again, it would need to be something that has nothing to do with load, as you're putting the OMAP5 on high load anyways.
We have 31 sec with pyra mainboard and pyra DT
So it heats up three times as fast simply because the mainboard is connected and MIPI is active? That sounds like WAY too much. It shouldn't have much impact.
I agree that it shouldn't, but it does according to this test.
40 sec without pyra mainboard and pyra DT
Wow! Still twice as fast. Some bug with the DT file maybe?
42 sec with pyra mainboard and uevm DT
... combined with something that the mainboard does?
100 sec without pyra mainboard and uevm DT
This is of course to be expected since the uevm.dtb does not know anything about panels and Pyra peripherals and therefore does not enable anything -
and does not have to process polling loops etc.
Is that the way the DT file works? Does it poll until it finds everything? No timeout, etc.?
No. DT configures drivers. Those might or might not poll.
Because usually Linux checks for the devices and that's it. It doesn't constantly poll. Well, that would explain the faster heat up when using Pyras DT file without the mainboard attached - but then again, polling is being done by the CPU which is already under high load, so the polling shouldn't make any difference at all.
So something really weird is going on there.
Having the additional components (mainboard) simply connected shouldn't heat up the OMAP5 at all, unless it does something actively with them (which it shouldn't). Yes, the PALMAS needs to provide power for them, so that one might heat up a bit more, but the OMAP5 shouldn't, when everything is properly setup.
So for me, this raises the following questions:
- Why does the OMAP5 heat up when the mainboard is attached? It really shouldn't do that, unless it actively uses any of these added components.
That might be in the range of measurement precision (I haven't had the same starting temperature which might be influenced by the total temperature of the Palmas).
- Why does the MIPI stream produce THAT much more heat? Based on the temperature rising, it needs... almost the same amount as both cores under full load? That can't be right.
Well, we pull 24 bit video data with 720x1200x60fps. This is roughly 51 Mpx/s and 1.2Gbit/s or 155 Mbyte from RAM. These go through the memory controller, DSS and MIPI encoder. These are running in addition to the situation when there is no MIPI.
But if we assume that the scenario 1 has the highest energy consumption, it explains why it is more risky to run into power supply limits.
Yes, but raises the question why so much more energy is needed. It shouldn't really add much!
Is the software setup causing that? Could there be a hardware issue on the mainboard that could cause the OMAP5 to heat up for some reason?
That is what puzzles me as well. The mainboard here only has 2 I2C interfaces, MIPI, a handful of GPIOs and power.
This is the connection diagram of the adapter I use so that you can see which signals of the EVM go to the mainboard:
AFAIK the omap5-evm.dts does only initialize the I2C controllers and the GPIOs are in high-resistance-input-mode. And DSI is also disabled.
Realistically, the heating difference in my opinion shouldn't be more than 5 - 10 seconds.
In my opinion it should be 0 seconds. But is this more or less realistic?
And you even have a 70 seconds difference with the Pyra.dt setup and mainboard connected. That's WAY too high (and also explains why I always thought the prototype heats up way too fast).
Please note that you have a different mainboard in the Pyra (modernized and bug fixed version) than the old one I am using here. The one I have does not have all interfaces and does not even connect everything.
When doing absolutely nothing, it shouldn't really warm up at all, but it's clearly noticeable.
In idle the EVM goes to 50° which *is* noticeable. Even at the outside connectors which have ca. 30°C for an EVM w/o enclosure.
So something (hardware, software, whatever) on the mainboard causes the OMAP5 to heat up immensively, and we need to find that part and check what's wrong with it!
Ok, I did run a short comparison again, trying to keep the setup the same as much as possible (which isn't easy if OMAP cools down and heats up and commands are started manually):
a) EVM with omap5-uevm.dts with Mainboard 4 connected: 50°C in idle 75°C after 40s; Xorg with 0.7%, login process with 1%, sshd with 0.3/0.7% and 2-3 kworkers&irqs sometimes with 0.3%
b) EVM with omap5-uevm.dts w/o Mainboard 4 connected: 49°C in idle 75°C after 37s; Xorg with 0.7%, login process with 1%, sshd with 0.3/0.7% and 2-3 kworkers&irqs sometimes with 0.3%
So this time, they are essentially the same and I can't find any significant difference.
BTW: in both cases the ARM is mostly running @ 1GHz and only goes up to 1.5GHz for the high-load test.
From this I must conclude that this "effect" is an artifact by low precision of measurement and not a real effect.
And about the 50° idle temperature this is something we can not solve. Unless we change the SoC. Or make Xorg, sshd and interrupts go to 0%. So it would neither be hardware only a little kernel.
c) EVM with omap5-uevm+pyra.dts with Mainboard 4 connected (and panel active): 44°C in idle 75°C after 78s; Xorg with 0.7%, login process with 2.3%, sshd with 0.3/0.7% and 2-3 kworkers&irqs sometimes with 0.3%
Everything is the same except the login process which tries to display battery status in this case adding some %.
And...
... this time measurement for heating up is crap. It heavily depends on initial temperature and that one depends on how long the board was powered down between measurements. I have repeated it and starting from 50°C it took 35s this time to get at 75°C. Exactly the same as with other DT and no Mainboard.
So please forget about this heat-up-time comparison. It does not tell us anything. Pure noise. No bug to find by this method.
In summary from my log-time results from yesterday and this morning, it remains that in one case the sawtooth stopped and temperature kept rising for several seconds which indicates that something broke in the kernel or OMAP.
If someone could shed some light on how this 100°C temperature limit of the OMAP5 works, it would be helpful.
BR, Nikolaus