This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Linux/AM5728: Disable Linux thermal framework

Part Number: AM5728

Tool/software: Linux

Hello TI,

I am using TI AM572x EVM board. I am going through AM572x Thermal Considerations report (www.ti.com/.../sprac53a.pdf). Under Section 5.1, "OPP Settings and Linux Thermal Framework" I quote "Additionally,the Linux thermal framework was disabled to hold the OPP constant as the processor heats, and prevents thermal shutdown. This was done for data gathering purposes, and is not recommended for a production system."

How do I disable the Linux thermal framework for my experimentation? I mean for "thermal_zone0 - Cortex-A15 CPU". Would it be sufficient if I write "disabled" into /sys/class/thermal/thermal_zone0/mode after changing the sysfs "policy" to "user_space"?

I am using TI processor SDK (not RT Linux).

Thank you for your time.

  • Hi,

    The thermal framework has a DVFS component used to lower CPU frequency (CPU FREQ) voltage when the device thermal framework is heating up beyond desired temperatures. The CPU FREQ is a kernel config option that is disabled on RT Linux platforms as I believe you are reffering to. In the thermal considerations report the CPU FREQ was disabled so the part would not switch to lower a frequency. The Thermal framework is still active and will shut down the part if the temperature exceeds defined set points.

    Best Regards,
    Schuyler
  • Hi Schuyler,

    Thanks for the post. So, when the "thermal considerations" report said that it has disabled thermal framework, all it did was change the frequency governor to "usermode" and set a particular frequency, thereby holding the OPP constant? Anything else it did on top of this?

    Thank you for your time.
  • Hi,

    For the paper the kernel was configured and then built to disable CPU FREQ. The method you are alluding to sounds easier regarding the governor set to usermode would probably work since that would still allow you to set the frequency.

    Best Regards,
    Schuyler
  • Hello Schuyler,

    I am sorry, but I am still confused. In the thermal considerations report "Section 4.6: Default OPP levels", it states that

    "Typically, the MPU domain OPP level can scale dynamically between OPP_NOM, OPP_OD and OPP_HIGH, in Linux using the CPUFreq driver, based on CPU load and selected governor. For the tests in this document, the “userspace” governor was used, and MPU frequency was manually set at the Linux prompt."

    You are saying that the kernel was built to disable CPUFREQ driver. But, without the driver you cannot change the governor to "userspace". Am I wrong?

    The document further explains in "Section 5.1: OPP Settings and Linux Thermal Framework", and I quote

    "MPU OPP level was held constant for each test. Additionally, the Linux thermal framework was disabled to hold the OPP constant as the processor heats, and prevents thermal shutdown. This was done for data gathering purposes, and is not recommended for a production system."

    That means, apart from changing the governor to "userspace", the thermal framework was disabled somehow. That leads me back to my question as to how to disable the thermal framework?

    Best regards

  • Hi,

    I apologize for the confusion, I may have added to it. The RT kernel is built to configure out the CPUFREQ driver, but the thermal driver is present.

    Since you have selected the non-RT kernel the userspace governor approach that you have highlighted is the correct method for selecting an OPP. By doing a cat operation of disable to the thermal mode path above will disable thermal mode support. If the CPUFREQ is not configured into the kernel then the option to set governors and frequencies is not available.

    I would ask to be careful here with the part by turning off any of the thermal zone's protection you can damage the part if it gets too hot.

    Best Regards,
    Schuyler