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/AM3352: Increased power consumption migrating to SDK3.0

Part Number: AM3352

Tool/software: Linux

Team,

I have been working with one of my customers who has recently migrated their AM3352 (BZCZ30) Linux platform from Sitara Processor SDK 1.0 to SDK 3.0 (2016  LTS). This exercise took quite some effort and hence was started a while ago and thus prior to the latest 2017 LTS SDK 4.0 release.

All seems to be working well under testing so far although the current draw when running has increased by ~20% between the SDK builds.  Digging deeper we have noticed that the power management configurations have changed somewhat and the kernel config options need to be modified.

We have found a processor option that was originally called in the 3.14 kernel 

<*>   Generic CPU0 cpufreq driver

And is now no longer there... but have found the following option in the later 4.4 kernel

<*>   Generic DT based cpufreq driver

Once have added this as a kernel module and it seems to have dropped the power consumption a little. Would that be expected behaviour? It looks like this is the same option but it’s been renamed in newer kernels. This has been added in the build as a module as the kernel doesn’t seem to be happy if I it was build-in to the kernel.

It seems an additional configuration item is also required 

<*>   Texas Instruments CPUFreq support

With these changes we are now down from 250mA to about 210mA which is more like normal consumption.  

We have been using the PM user guides on the wiki as a basis for investigation so far: 

http://processors.wiki.ti.com/index.php/Linux_Core_Power_Management_User%27s_Guide_(v3.14)

http://processors.wiki.ti.com/index.php/Linux_Core_Power_Management_User%27s_Guide_(v4.1) (This should be close to 4.4)

Do we have a PM configuration migration guide or wiki article for moving between the Proc SDK releases ? It might be a good idea if not.

Any thoughts/advice on additional settings required would be very much appreciated.

Regards,

Garry

  • The PM experts have been notified. They will respond here.
  • Hi Garry,

    Garry Clarkson said:
    Do we have a PM configuration migration guide or wiki article for moving between the Proc SDK releases ? It might be a good idea if not.

    See if the below wiki will be in help:

    Regards,
    Pavel

  • Garry,

    Make sure also you are using tisdk_am335x-evm_defconfig file, where we have:

    #

    # CPU Power Management

    #

    #

    # CPU Frequency scaling

    #

    CONFIG_CPU_FREQ=y

    CONFIG_CPU_FREQ_GOV_COMMON=y

    CONFIG_CPU_FREQ_STAT=y

    CONFIG_CPU_FREQ_STAT_DETAILS=y

    # CONFIG_CPU_FREQ_DEFAULT_GOV_PERFORMANCE is not set

    # CONFIG_CPU_FREQ_DEFAULT_GOV_POWERSAVE is not set

    # CONFIG_CPU_FREQ_DEFAULT_GOV_USERSPACE is not set

    CONFIG_CPU_FREQ_DEFAULT_GOV_ONDEMAND=y

    # CONFIG_CPU_FREQ_DEFAULT_GOV_CONSERVATIVE is not set

    CONFIG_CPU_FREQ_GOV_PERFORMANCE=y

    CONFIG_CPU_FREQ_GOV_POWERSAVE=y

    CONFIG_CPU_FREQ_GOV_USERSPACE=y

    CONFIG_CPU_FREQ_GOV_ONDEMAND=y

    CONFIG_CPU_FREQ_GOV_CONSERVATIVE=y

    #

    # CPU frequency scaling drivers

    #

    CONFIG_CPUFREQ_DT=y

    # CONFIG_ARM_KIRKWOOD_CPUFREQ is not set

    # CONFIG_ARM_OMAP2PLUS_CPUFREQ is not set

    CONFIG_ARM_TI_CPUFREQ=y

    # CONFIG_QORIQ_CPUFREQ is not set

     

    And according to the linux 4.4 power management wiki (link below), CPUFreq DT should be configured as module.

    http://processors.wiki.ti.com/index.php/Linux_Core_Power_Management_User's_Guide_(v4.4)

     

  • Thanks Pavel,

    we will check this out and update the thread with results.

    Regards,

    Garry

  • Hi all,

    We applied the setting as per the referenced threads and we got another 5 hours of operation, which was very pleasing.

    Thank you for all your help. I think we will need to review exactly what we have enabled/disabled and get back to yourselves about what we are doing.

    Andrew