Skip to content

Power Consumption Adjustment Guide

REVISION HISTORY

Revision No.
Description
 Date
1.0
  • Initial release
    		•  04/27/2024

    1. Overview

    This document is provided as a guide to the power consumption optimization of the Sigmastar PureLinux & DualOs platform. An introduction of the clock switch and frequency adjustment method is provided for each module.

    2. Configuration

    The PureLinux & DualOs platform is currently connected to the CCF(Common Clock Framework), and by default unused modules will be disabled during the Linux system startup phase.

    But you need to make sure to enable the following configuration:

    PureLinux:

    Symbol: COMMON_CLK [=y]
Type  : bool
Defined at drivers/clk/Kconfig:25
  Prompt: Common Clock Framework
  Depends on: !HAVE_LEGACY_CLK [=n]

    DualOs also needs to ensure that the following configurations are enabled:

    Symbol: SSTAR_CLK_OS_MANAGE [=y]
Type  : tristate
Defined at drivers/sstar/clk/Kconfig:4
  Prompt: Sstar CLK OS Manage
  Depends on: SSTAR_DRIVERS [=y]
  Location:
    -> Device Drivers
      -> Sstar SoC platform drivers (SSTAR_DRIVERS [=y])

    After the above configuration is enabled, clock enable/disable and clock dependencies will be taken over by CCF. Each module only needs to be connected with the interface provided by CCF. For users, the points that need attention are mainly divided into:

    1. Module Addition and Removal

      Most BSP modules will enable the clock when they are in use, but some modules will enable the clock during the loading phase (probe). These modules need to ensure that they are not loaded when not in use, such as the USB module.

    2. Module Frequency Adjustment

      This part is mainly aimed at streaming modules with high power consumption. Users can adjust the appropriate frequency suitable for the scene to reduce power consumption.

    In addition, some special modules will be introduced in further detail, such as CPU.

    2.1. Module Addition and Removal

    This section introduces the configuration and operation for adding and removing modules.

    2.1.1. usb

    USB will be divided into host-side controller and device-side controller, which will be introduced separately here.

    usb 2.0 host controller:

    Symbol: USB_EHCI_HCD [=m]
Type  : tristate
Defined at drivers/usb/host/Kconfig:129
  Prompt: EHCI HCD (USB 2.0) support
  Depends on: USB_SUPPORT [=y] && USB [=y] && HAS_DMA [=y] && HAS_IOMEM [=y]
  Location:
    -> Device Drivers
      -> USB support (USB_SUPPORT [=y])
  Corresponding module driver: ehci-hcd.ko

    usb 2.0 device side controller:

    Symbol: USB_SSTAR_MSB250X_UDC [=m]
Type  : tristate
Defined at drivers/sstar/usb/gadget/udc/usb20/Kconfig:1
  Prompt: Sstar MSB250X USB 2.0 Device Controller
  Depends on: USB_SUPPORT [=y] && USB_GADGET [=m]
  Location:
    -> Device Drivers
      -> USB support (USB_SUPPORT [=y])
        -> USB Gadget Support (USB_GADGET [=m])
          -> USB Peripheral Controller
  Corresponding module driver: udc-msb250x.ko

    2.1.3. sdmmc

    Symbol: SSTAR_SDMMC [=m]                                                                                                        Type  : tristate
Defined at drivers/sstar/sdmmc/Kconfig:1
  Prompt: SStar SD/MMC Card Interface Support
  Depends on: SSTAR_DRIVERS [=y] && MMC [=m]
  Location:
    -> Device Drivers
      -> Sstar SoC platform drivers (SSTAR_DRIVERS [=y])
  Corresponding module driver: kdrv_sdmmc.ko

    2.1.4. crypto

    This module is mainly used for encryption and decryption operations.

    Symbol: SSTAR_CRYPTO [=y]
Type  : tristate
Defined at drivers/sstar/crypto/Kconfig:1
  Prompt: SigmaStar Crypto driver
  Depends on: MSTAR_DRIVERS [=y]
  Location:
    -> Device Drivers
      -> SStar SoC platform drivers (MSTAR_DRIVERS [=y])
  Corresponding module driver: mdrv_crypto.ko

    2.2. Module Frequency Adjustment

    All modules listed in this chapter support frequency adjustment. Modules related to streaming are mainly divided into Debug interface and Formal interface.

    Debug interface supports Clock Level Viewing and Clock Level Configuration.

    • This interface is only used to adjust the appropriate clock frequency. The displayed clock is divided into two parts, the clock source level and the current clock frequency. Since the module clock may support divider, the actual clock may be the clock source subdivision level.
    • This type of interface needs to ensure that the mi_debug function is enabled. For example, if you need to enable the VENC function, you need to make sure that CONFIG_ENABLE_VENC_DEBUG is enabled.

    Formal interface is set through modparam.json:

    • After confirming the clock through the debugging interface, configure it through this interface. This interface supports dualos and purelinux settings. modparam.json is a unified initialization interface. For detailed usage, please see the mi_common usage.

    Tips for confirming clock level

    • Clock level: The module clock level viewing only provides the level of the clock source. Some modules support divider, so there will be more clock levels (based on clock source frequency division). During actual configuration, you can first confirm whether the large clock source level meets the requirements, and then subdivide and configure smaller clock levels.

    • The clock frequency required for module processing tasks is related to the frame rate and image resolution of the hardware processing, so there is no way to give a relatively unified formula level to estimate the clock frequency. Therefore, the current way to obtain the clock frequency is to constantly try to configure the level, confirm whether the module is working properly, and gradually approach the final level. It can be roughly divided into the following steps:

      1. In the complete scene, based on the normal working condition of the scene, obtain the basic clock frequency at this time

      2. Start adjusting the clock frequency from the front-end module (sensor). It needs to be based on the basic clock frequency and proceed from high to low until a suitable clock is obtained.

        If the frame rate of the module decreases, or problems such as fifo full occur, it means that the clock frequency has reached the bottom. At this time, the relevant clock level needs to be adjusted to a higher level; if the scene is a hardware direct connection mode, the direct connection mode can be switched to frame mode to avoid mutual influence between front and rear stages

      3. Increase the obtained clock frequency by a margin

        Because the clock frequency is continuously debugged, it will tend to be the limit frequency value of the hardware processing in this scene. If the bandwidth is reduced or the scene is fine-tuned, the frame rate of the module processing may be insufficient, so it is necessary to add appropriate margin to the frequency adjusted in the second step at this time .

    2.2.1. sensor

    Clock Level Viewing:

    / # cat /proc/mi_modules/mi_sensor/debug_hal/csi_clk0
[0] 432000000 <--
[1] 288000000
[2] 320000000
[3] 172000000
Current CLK:432000000

csi_clk0 corresponds to sensor0, csi_clk1 corresponds to sensor1

    Clock Level Configuration:

    / # echo 226000000 > /proc/mi_modules/mi_sensor/debug_hal/csi_clk0
/ # cat /proc/mi_modules/mi_sensor/debug_hal/csi_clk0
[0] 432000000
[1] 288000000
[2] 320000000
[3] 172000000
Extend CLK 234000000:288000000 * 26 / 32

Extend CLK: Represents using dfs for level segmentation

    Formal interface:

    {
    "E_MI_MODULE_ID_SNR" :
    {
        "csi_clk": [234000000,234000000]
    }
}

csi_clk: The parameters configured here is csi_clk0, csi_clk1

    2.2.2.vif

    Clock Level Viewing:

    / # cat /proc/mi_modules/mi_vif/debug_hal/vif_clk
[0] 288000000 <--
[1] 240000000
[2] 192000000
[3] 320000000
Current CLK:288000000

    Clock Level Configuration:

    / # echo 140000000 > /proc/mi_modules/mi_vif/debug_hal/vif_clk
/ # cat /proc/mi_modules/mi_vif/debug_hal/vif_clk
[0] 288000000
[1] 240000000
[2] 192000000
[3] 320000000
Extend CLK 144000000:192000000 * 24 / 32

    Formal interface:

    {
    "E_MI_MODULE_ID_VIF" :
    {
        "vif_clk": 144000000
    }
}

    2.2.3. isp

    Clock Level Viewing:

    / # cat /proc/mi_modules/mi_isp/debug_hal/isp_clk
[0] 288000000
[1] 240000000
[2] 192000000
[3] 320000000
Extend CLK:144000000 = 192000000 * 24 / 32

    Clock Level Configuration:

    / # echo 123000000 > /proc/mi_modules/mi_isp/debug_hal/isp_clk
/ # cat /proc/mi_modules/mi_isp/debug_hal/isp_clk
[0] 288000000
[1] 240000000
[2] 192000000
[3] 320000000
Extend CLK:126000000 = 192000000 * 21 / 32

    Formal interface:

    {
    "E_MI_MODULE_ID_ISP" :
    {
        "isp_clk": 126000000
    }
}

    2.2.4.scl

    Clock Level Viewing:

    / # cat /proc/mi_modules/mi_scl/debug_hal/clk
[0] 144000000
[1] 192000000
[2] 216000000
[3] 240000000
[4] 288000000
[5] 320000000
ExtClock[121500000]:
[0] [144000000 * 27 / 32] = 121500000 <-------

    Clock Level Configuration:

    / # echo 152000000 > /proc/mi_modules/mi_scl/debug_hal/clk
/ # cat /proc/mi_modules/mi_scl/debug_hal/clk
[0] 144000000
[1] 192000000
[2] 216000000
[3] 240000000
[4] 288000000
[5] 320000000
ExtClock[152000000]:
[1] [192000000 * 26 / 32] = 156000000 <-------

    Formal interface:

    {
    "E_MI_MODULE_ID_SCL" :
    {
        "u32FClk1RateHz": 156000000
    }
}

    2.2.5.venc

    Clock Level Viewing:

    / # cat /proc/mi_modules/mi_venc/debug_hal/ven_clock

-------VENC Device [0]---------
345000000 <--
323400000
301800000
288000000
270000000
240000000
216000000
192000000
174000000
162000000
144000000
120000000
Current CLK: 345000000 (dfs=32/32, source=345000000)
/ # cat /proc/mi_modules/mi_venc/debug_hal/ven_clock_2nd

-------VENC Device [0]---------
432000000 <--
405000000
384000000
360000000
345000000
320000000
288000000
261000000
234000000
216000000
189000000
162000000
Current CLK: 432000000 (dfs=32/32, source=432000000)

    Clock Level Configuration:

    / # echo 286000000 > /proc/mi_modules/mi_venc/debug_hal/ven_clock
/ # cat /proc/mi_modules/mi_venc/debug_hal/ven_clock

-------VENC Device [0]---------
345000000
323400000
301800000
288000000 <--
270000000
240000000
216000000
192000000
174000000
162000000
144000000
120000000
Current CLK: 288000000 (dfs=32/32, source=288000000)

# ven_clock_2nd is 1.26 times ven_clock
/ # echo 355000000 > /proc/mi_modules/mi_venc/debug_hal/ven_clock_2nd
/ # cat /proc/mi_modules/mi_venc/debug_hal/ven_clock_2nd

-------VENC Device [0]---------
432000000
405000000
384000000
360000000 <--
345000000
320000000
288000000
261000000
234000000
216000000
189000000
162000000
Current CLK: 360000000 (dfs=30/32, source=384000000)

    Formal interface:

    {
    "E_MI_MODULE_ID_VENC" :
    {
        "ven_clock": 288000000,
        "ven_clock_2nd": 360000000
    }
}

    2.2.6.jpe

    Clock Level Viewing:

    / # cat /proc/mi_modules/mi_venc/debug_hal/jpe_clock
-------Device 0---------
288000000 <--
261000000
240000000
216000000
192000000
168000000
144000000
120000000
Current CLK: 288000000 (dfs=32/32, source=288000000)

    Clock Level Configuration:

    / # echo 266000000 > /proc/mi_modules/mi_venc/debug_hal/jpe_clock
/ # cat /proc/mi_modules/mi_venc/debug_hal/jpe_clock
-------Device 0---------
288000000 <--
261000000
240000000
216000000
192000000
168000000
144000000
120000000
Current CLK: 288000000 (dfs=32/32, source=288000000)

    Formal interface:

    {
    "E_MI_MODULE_ID_VENC" :
    {
        "jep_clock": 288000000
    }
}

    2.2.7. ipu

    Clock Level Viewing:

    / # cat /proc/mi_modules/mi_ipu/debug_hal/freq
current ipu clock gear: 400MHz
available frequency:
600MHz
500MHz
400MHz
300MHz

    Clock Level Configuration:

    / # echo 500 > /proc/mi_modules/mi_ipu/debug_hal/freq
/ # cat /proc/mi_modules/mi_ipu/debug_hal/freq
current ipu clock gear: 500MHz
available frequency:
600MHz
500MHz
400MHz
300MHz

    Formal interface:

    {
    "E_MI_MODULE_ID_IPU" :
    {
        "ipu_clk": 400000000
    }
}

    2.2.8.ive

    Clock Level Viewing:

    / # cat /proc/mi_modules/mi_ive/debug_hal/ive_clk

----------IVE clock -----------
288000000 <--
216000000
384000000
432000000 od
Current CLK: 288000000 dfs(0/0, source=288000000)

    Clock Level Configuration:

    / # echo 266000000 > /proc/mi_modules/mi_ive/debug_hal/ive_clk
/ # cat /proc/mi_modules/mi_ive/debug_hal/ive_clk

---------- IVE clock -----------
288000000 <--
216000000
384000000
432000000 od
Current CLK: 288000000 dfs(0/0, source=288000000)

    Formal interface:

    {
    "E_MI_MODULE_ID_IVE" :
    {
        "ive_clk": 288000000
    }
}

    2.2.9. ldc

    Clock Level Viewing:

    / # cat /proc/mi_modules/mi_ldc/debug_hal/ldc_clock
--------- device[0] ---------
384000000 <----
216000000
172000000
123400000
432000000
Current CLK: 384000000

    Clock Level Configuration:

    / # echo 244000000 > /proc/mi_modules/mi_ldc/debug_hal/ldc_clock
/ # cat /proc/mi_modules/mi_ldc/debug_hal/ldc_clock
--------- device[0] ---------
[0] 384000000 <----
[1] 216000000
[2] 172000000
[3] 123400000
[4] 432000000
Current CLK: 252000000 (dfs=21/32, source=384000000)

    Formal interface:

    {
    "E_MI_MODULE_ID_LDC" :
    {
        "ldc_clk": 252000000
    }
}

    2.3. cpu

    CPU frequency adjustment is currently performed through the cpufreq subsystem of Linux, so here we will focus mainly on the interfaces provided by cpufreq.

    Please ensure that the configuration CONFIG_MS_CPU_FREQ is enabled.

    Please ensure that the configuration CONFIG_SSTAR_VOLTAGE_IDAC_CTRL is enabled.

    Please ensure that the configuration CONFIG_CPU_FREQ_GOV_USERSPACE is enabled.

    2.3.1. Node Introduction

    Node path: /sys/devices/system/cpu/cpufreq/policy0

    Node Name Function
    cpuinfo_cur_freq The current working frequency of the CPU, generally equal to scaling_cur_freq
    cpuinfo_max_freq The maximum working frequency that the CPU can support
    cpuinfo_min_freq The minimum working frequency that the CPU can support
    scaling_available_frequencies Frequency gears supported by the regulator:
    600000 800000 1000000
    scaling_cur_freq The current CPU working frequency determined by the regulator
    scaling_available_governors Supported moderation strategies:
    1. performance: Performance priority mode, using the highest frequency regardless of the power consumption
    2. powersave: Powersaving mode, usually running at the lowest frequency
    3. userspace: User-defined mode, supporting manual frequency adjustment in user space
    4. ondemand: On-demand mode, checking the load regularly and adjusting the frequency according to the load
    5.schedutil: Dynamically adjust frequency based on real-time CPU load to balance performance and energy efficiency
    scaling_governor View the current modulation strategy and set the modulation strategy. Default is ondemand.
    scaling_max_freq The maximum CPU working frequency that the regulator can support
    scaling_min_freq The minimum CPU working frequency that the regulator can support
    scaling_setspeed If the selected modulation strategy is userspace, you can set the CPU working frequency to a certain value.

    2.3.2. Configuration Constraint

    1. scaling_min_freq must be less than or equal to scaling_max_freq
    2. scaling_min_freq must be greater than or equal to cpuinfo_min_freq
    3. scaling_max_freq must be less than or equal to cpuinfo_max_freq
    4. scaling_setspeed must be within the range of scaling_min_freq and scaling_max_freq

    2.3.3 Frequency Setting

    # To configure the current governor as userspace:
/sys/devices/system/cpu/cpufreq/policy0/ # echo userspace > scaling_governor

# To confirm whether the frequency to be configured falls within the valid range:
/sys/devices/system/cpu/cpufreq/policy0 # cat scaling_min_freq
800000
/sys/devices/system/cpu/cpufreq/policy0 # cat scaling_max_freq
1200000

# To configure the current frequency:
/sys/devices/system/cpu/cpufreq/policy0 # echo  1000000 > scaling_setspeed
/sys/devices/system/cpu/cpufreq/policy0 # cat scaling_cur_freq
1000000