i.MX8M PWM backlight and CPU idle

[felixradensky]

On our i.MX8M board we use PWM backlight driver to control display backlight. Below are relevant definitions from the DTS:

backlight: backlight {
        compatible = "pwm-backlight";
        pwms = <&pwm1 0 1000000 0>;
        brightness-levels = < 0  1  2  3  4  5  6  7  8  9
                     10 11 12 13 14 15 16 17 18 19
                     20 21 22 23 24 25 26 27 28 29
                     30 31 32 33 34 35 36 37 38 39
                     40 41 42 43 44 45 46 47 48 49
                     50 51 52 53 54 55 56 57 58 59
                     60 61 62 63 64 65 66 67 68 69
                     70 71 72 73 74 75 76 77 78 79
                     80 81 82 83 84 85 86 87 88 89
                     90 91 92 93 94 95 96 97 98 99
                    100>;
        default-brightness-level = <80>;

};

&pwm1 {

        pinctrl-names = "default";
        pinctrl-0 = <&pinctrl_pwm1>;

};

pinctrl_pwm1: pwm1grp {
            fsl,pins = <
                MX8MQ_IOMUXC_GPIO1_IO01_PWM1_OUT         0x06
            >;
};

We've found that with backlight enabled CPU cores never enter idle state, causing higher power consumption and temperature. The idle state counter for all cores (/sys/devices/system/cpu/cpuN/cpuidle/state1/usage) is always 0. When backlight is disabled cores enter idle state and board temperature goes down. Setting brightness level to 0 (echo 0 > /sys/devices/platform/backlight/backlight/backlight/brightness) does not help.

Please help us fixing this problem.

Thanks a lot.

Felix.

[felixradensky]

Hi,

Upon further investigation we've come to the conclusion that cpuidle problems are caused by MIPI-DSI. We have disabled all display related hardware components in our DTS (backlight, PWM, DSI-LVDS bridge, touch) leaving only DCSS and MIPI-DSI. The problem still occurs. We don't see this problem when using HDMI display instead of MIPI-CSI. The problem is also reproducible on i.MX8M EVK using  fsl-imx8mq-evk-dcss-rm67191.dtb configuration.

Felix.

[lily_zhang]

@Felix_Radensky, we will check it.