For the project I am currently working on, we are running an Apalis iMX8QM on a custom carrier board with Linux 5.15.77.
We are trying to reduce power consumption by disabling the GPU as we are not using them, and low power consumption is a priority.
We have seen quite an increase in power consumption from the previous iMX6 that we were using in previous iterations of the device.
Following information found here on the forums (here and also here), we have disabled the GPUs in the device tree.
We have also disabled the framebuffer in the kernel config, and lowered maximum number of GPUs to 0.
When I check the thermal zones of the iMX8, it shows the GPU temperatures to still be high, often exceeding the CPU temperature, which seems to suggest the GPUs are active.
GPU2 is often the highest temperature, with GPU1 being 1 degree C cooler than the CPUs.
Is this behaviour expected?
Hi @wmcl , sorry for the late response. The GPU functionality is disabled from the device tree. However, the power for GPU cores is still active. The fused PMIC will always give the voltage to GPU cores. It has to be compliant with the powering-up timing of iMX8QuadMax. I don’t think we can disable the GPU power rail from PMIC. There is leakage in GPU cores when it is powered on even though it has no workload. Due to the GPU core’s unique hardware design supporting powerful computing, its leakage could be larger than CPU. As you find out on PC the graphical card always consumes more power than the CPU. The GPU is proprietary, I don’t see the exact information about it on the iMX8QM reference manual but a similar statement on the CPU. The more powerful the component is, the more leakage it has. The location of CPU and GPU on the die will also contribute to temperature deviation. What do you see if a heavy workload is applied to the CPU cores?
11.1.1.4.4 Leakage Power for a Cluster
In general, the leakage of a single A72 plus its cluster is significantly more than the whole A53 cluster
Thank you for getting back to me.
This leakage explains the behaviour we are seeing, and confirms our suspicion that, although disabled, the power rail to the GPU has not been switched off.
Thanks for your response.
