Application Qt5.6 running with EGLFS crash when running communication SPI

I have a simple application running on Qt5.6 EGLFS (without server X).
I made a change in the device tree to release the SPI(3.0) to use a RFID, created a patch for this:

--- a/arch/arm/boot/dts/imx6dl-colibri-eval-v3.dts
+++ b/arch/arm/boot/dts/imx6dl-colibri-eval-v3.dts
@@ -134,14 +134,18 @@
 		interrupt-parent = <&gpio3>;
 		interrupts = <27 0x2>;
 		spi-max-frequency = <10000000>;
-		status = "okay";
+		status = "disabled";
 	};
 	spidev0: spidev@1 {
 		compatible = "spidev";
 		reg = <0>;
 		spi-max-frequency = <23000000>;
-		status = "disabled";
 	};

Running only Qt application works!
Running only a C or Python application to communicate via SPI works!

Running Qt5 and the application to communicate via SPI, some time after the qt application crash and reports the following error.

[ 1669.453671] System is too hot. GPU3D will work at 1/64 clock.
[ 1669.470178] imx-ipuv3 2400000.ipu: IPU Warning - IPU_INT_STAT_5 = 0x00800000
[ 1669.479060] imx-ipuv3 2400000.ipu: IPU Warning - IPU_INT_STAT_10 = 0x00100000
[ 1685.883623] mxc_sdc_fb fb.18: timeout when waiting for flip irq
[ 1686.854765] PU: Power-off latency exceeded, new value 28333 ns
[ 1687.053619] mxc_sdc_fb fb.18: timeout when waiting for flip irq
[ 1688.233647] mxc_sdc_fb fb.18: timeout when waiting for flip irq
[ 1689.393619] mxc_sdc_fb fb.18: timeout when waiting for flip irq
[ 1690.483612] Hot alarm is canceled. GPU3D clock will return to 64/64
[ 1690.563621] mxc_sdc_fb fb.18: timeout when waiting for flip irq
[ 1691.113619] mxc_sdc_fb fb.18: timeout when waiting for flip irq
[ 1691.653621] mxc_sdc_fb fb.18: timeout when waiting for flip irq
[ 1692.173644] mxc_sdc_fb fb.18: timeout when waiting for flip irq
[ 1692.703749] mxc_sdc_fb fb.18: timeout when waiting for flip irq
[ 1693.243593] mxc_sdc_fb fb.18: timeout when waiting for flip irq
[ 1693.783591] mxc_sdc_fb fb.18: timeout when waiting for flip irq
[ 1694.323626] mxc_sdc_fb fb.18: timeout when waiting for flip irq
[ 1694.853621] mxc_sdc_fb fb.18: timeout when waiting for flip irq
[ 1695.393616] mxc_sdc_fb fb.18: timeout when waiting for flip irq
[ 1695.923636] mxc_sdc_fb fb.18: timeout when waiting for flip irq
[ 1696.463624] mxc_sdc_fb fb.18: timeout when waiting for flip irq
[ 1696.993627] mxc_sdc_fb fb.18: timeout when waiting for flip irq
[ 1697.533617] mxc_sdc_fb fb.18: timeout when waiting for flip irq
[ 1698.063624] mxc_sdc_fb fb.18: timeout when waiting for flip irq

Already reduces the spi-max-frequency to 10000000 and the same problem occurs.

Any suggestion?


Cleiton Bueno

Blog | Linkedin | B2Open

Hi

I guess Qt5/QML uses the GPU very intensively. Thus you get:

[ 1669.453671] System is too hot. GPU3D will work at 1/64 clock.

The reduction in GPU performence then trips your system. Maybe the addition of your SPI code adds a little to the CPU load but is not the real culprit.

Could you try

echo 16 > /sys/bus/platform/drivers/galcore/gpu3DMinClock

to make the GPU performance drop less dramatically (but having also smaller cooling effects) to see if that is the problem and exclude the SPI/Qt5 combination as the reason?

Max

As Max mentions, it is likely due to the GPU throttling. Maybe this is obvious but I found it worth mentioning: Especially when using the GPU heavily, it is recommended to use a cooling solution such as:

Update: Sorry just realized that you are using Colibri iMX6, for which we don’t have an official cooling solution. Internally, for Demos and Windows 10 IoT, we used small heat sinks such as this one from Digikey.

Thanks Max and Stefan.

@Max Implemented its trick, and this running for over 6 hours and the GUI Qt5.6 gave no problems.

The maximum I saw was the log below, but no problem in any of the IPC sockets, GUI or SPI.

[ 1721.393655] System is too hot. GPU3D will work at 16/64 clock.
[ 1783.393688] Hot alarm is canceled. GPU3D clock will return to 64/64

...

[ 2783.563635] System is too hot. GPU3D will work at 16/64 clock.
[ 2862.573704] Hot alarm is canceled. GPU3D clock will return to 64/64

@Stefan Thank you for your tip, yes, I have to put sinks on the SoC.


Cleiton Bueno

Blog | Linkedin | B2Open