Tina_Linux_功耗管理_开发指南

Posted 韦东山

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了Tina_Linux_功耗管理_开发指南相关的知识,希望对你有一定的参考价值。

Tina Linux 功耗管理开发指南

1 概述

1.1 编写目的

简要介绍tina 平台功耗管理机制,为关注功耗的开发者,维护者和测试者提供使用和配置参考。

1.2 适用范围

表1-1: 适用产品列表
产品名称内核版本休眠类型参与功耗管理的协处理器
R328Linux-4.9NormalStandby
R329Linux-4.9SuperStandbyDSP0
D1-HLinux-5.4NormalStandby
V853Linux-4.9SuperStandby/NormalStandby

注:若同时支持多种休眠类型,则系统最终进入的休眠状态,根据唤醒源的配置自动确定。一般来说(无特别说明),唤醒源仅包括rtc, nmi(powerkey),

gpio(wlan,usb 插拔等) 这些唤醒源,则最终进入super standby,否则包含任意的其他的唤醒源,则进入normal standby。

1.3 适用人员

tina 平台下功耗管理相关的开发、维护及测试相关人员。

2 Tina 功耗管理框架概述

2.1 功能介绍

tina 功耗管理系统主要由休眠唤醒(standby、autosleep、runtime pm), 调频调压(cpufreq、devfreq、dvfs ),开关核(cpu hotplug),cpuidle 等子系

统组成。主要用于对系统功耗进行管理和控制,平衡设备功耗和性能。

一般我们可将其分为两类,即静态功耗管理和动态功耗管理。

图2-1: 功耗管理系统分类

一般地,可以动态调整或实时改变系统状态而达到节能目的技术,称为动态功耗管理,例如调频调压,idle, hotplug, runtime-pm 等;

相对地,我们把单纯地将系统置为某一种状态,而不实时调整的低功耗技术,称为静态功耗管理,例如休眠唤醒相关技术等。

由于在tina 系统中,动态功耗技术一般来说默认配置好了,基本不需要客户修改, 另外如调频,温控等模块会在Linux 模块开发指南目录下,由模块相关的文档说

明。因此本文主要介绍静态功耗管理技术,即休眠唤醒框架。

2.2 相关术语

表2-1: 术语表
术语解释
CPUS全志平台上,专用于低功耗管理的协处理器单元。
CPUX主处理器单元,主要为客户应用提供算力的ARM/RISC-V 核心。
WFIARM 体系中一种指令,可将CPUX 置于低功耗状态,直到有中断发生
而退出该状态。详细请参考ARM 手册,例如
《DDI0487A_d_armv8_arm.pdf》。
NormalStandby、
SuperStandby
Allwinner 内部术语,系统进入一种低功耗状态,暂停运行,以获取更低
的功耗表现,区别是CPUX 是否掉电。前者CPUX 不掉电,系统唤醒直
接借助于CPUX 的WFI 指令完成。后者CPUX 掉电,系统唤醒需借助
其他硬件模块实现,如CPUS。
Arm Trusted
Firmware
ARMv8-A 安全世界软件的一种实现,包含标准接口:PSCI、TBRR、
SMCCC 等。在本文中,将其软硬件实现,统称为ATF。
OP-TEE一种安全操作系统方案,具有单独的SDK 环境,以二进制文件的形式集
成在tina 中,在本文中,统称为OP-TEE。
SCP、ARISC即CPUS 的SDK 环境。最初CPUS 固件以闭源方式集成在tina 环境
中,文件名为scp.bin,故称SCP。现已在tina 中提供开源代码包,目
录名为arisc,故又称为ARISC。
BMU电池管理芯片,提供电池升压,充电管理等功能,同时可外接电源键,用
于开机,休眠,唤醒等。
PMU电源管理芯片,有多个可调的DC-DC, LDO 通道,提供电源管理功能,
同时可外接电源键,用于开机,休眠,唤醒等。

2.3 唤醒源支持列表

PowerKeyLRADCRTCWIFI(GPIO)BTUARTUSB插拔MAD
R328NYNYY
R329Yˆ1YYYYˆ2Y
D1-HNYYY
V853YYYY

注:Y: 支持;N: 不支持;–: 未明确

ˆ1: 仅带PMU 的方案支持;

ˆ2: 仅suart 支持;

3 Tina 休眠唤醒系统简介

3.1 唤醒源分类

唤醒源唤醒的本质是触发系统中断,因此在tina 平台上,我们可以按照中断不同将唤醒源分为两大类,

1、内部唤醒源,一般为IC 内部外设,有自己独立的中断,如RTC,UART,LRADC,USB等。

2、外部唤醒源,这类设备都通过GPIO 中断实现唤醒功能,占用一个对应的引脚,如WIFI,BT,GPIOKEY 等。

如下图,粉色为irq_chip【GPIO 模块也看做是一个irq_chip】,蓝色为内部唤醒源,紫色为外部唤醒源。

图3-1: 中断结构
外部唤醒源不同于内部唤醒源,主要有以下不同:

1、外部唤醒源依赖于GPIO 中断,而且GPIO 中断通常是一个GPIO Group 共用一个中断号,因此需要借助irq_chip 框架进行虚拟中断映射。tina 已经实现了映

射,设备驱动使用Linux 中断申请框架即可。

2、外部唤醒源使能唤醒功能时,还需设备驱动保证GPIO 复用功能,时钟,电源,上下拉状态等正常。

3、GPIO 中断分为CPUX 上的GPIO 和CPUS 上的GPIO,以及PMU 上的GPIO,不同模块上的GPIO 在实现上会有一定的差异,但tina 尽可能屏蔽了这些差异。

需要注意的是,不论哪种唤醒源,其正常工作都有以下几个前提:

1、休眠后,发生预定事件后,设备可产生唤醒中断;由设备驱动在其suspend/resume 函数中保证。

2、休眠后,该设备中断使能。设备驱动初始化或在suspend/resume 函数中,向内核注册唤醒源,之后由休眠唤醒框架保证。

3.2 唤醒源说明

本节介绍tinaLinux 内核驱动已经实现的唤醒源,简述其功能。由于各平台实现存在差异,对于以下唤醒源的支持可能不一致,具体请参考唤醒源支持列表。

• PowerKey(NMI)

PowerKey(电源键)一般是连接在PMU/BMU 上控制系统开机的按键,由PMU/BMU 检测管理。当系统处于开机状态时,触发按键,则PMU/BMU 会通过NMI 中

断上报按键事件。休眠框架,根据这个特性可支持其唤醒。另外,PMU/BMU 也会通过NMI 中断上报电池充电,电池过温等事件,由于这些事件都对应NMI 中

断,因此休眠框架无法区分,只能由PMU/BMU 驱动控制使能。

一般地,在支持PowerKey 的平台上,会默认使能此功能。

• LRADC 唤醒

利用LRADC 按键模块,检测到按键后唤醒。

由于LRADC 模块连接的多个按键对应一个LRADC 中断,因此只能整体配置,无法单独禁用/启用某一个按键唤醒。

一般地,在dts 中keyboard 设备节点下,配置“wakeup-source” 属性即可使能。

• RTC 唤醒

RTC 是日历时钟模块,其可以在关机,休眠等状态下正常走时,其支持设置一个未来时间点作为闹钟,当闹钟超时时,会产生RTC 中断,触发系统唤醒。

下面提供一个配置RTC 闹钟的方法,仅用于调试。量产产品中,应用程序应通过/dev/rtc0 设备节点进行闹钟的配置,具体方法可参考Linux 手册。

# 设置5秒后闹钟唤醒(注意定时时间从执行此条命令时开始计算)

echo +5 > /sys/class/rtc/rtc0/wakealarm

一般地,在dts 中rtc 设备节点下,配置“wakeup-source” 属性即可使能。

• WIFI(GPIO)唤醒

本质上是对应引脚的GPIO 中断唤醒。

依赖于WIFI 模块本身对数据包的监听和管理,若模块或驱动无法支持,该功能亦无法使用,实际以模块自身配置为准。

一般地,默认使能,如未使能,则在dts 中wlan 设备节点下,配置相应的GPIO 引脚和“wakeup-source” 属性即可使能,如有疑问,可查阅Tina_Linux WLAN 模块

相关文档。

• BT(GPIO)唤醒

与BT 相同,本质上是对应引脚的GPIO 中断唤醒。

依赖于BT 模块本身对数据包的监听和管理,若模块或驱动无法支持,该功能亦无法使用,实际以模块自身配置为准。

一般地,默认未支持,具体配置方法,需查阅TinaLinux BT 相关文档或与我司联系。

• UART 唤醒

通过UART 接受到字符产生的中断,唤醒系统。

在UART 唤醒功能中,有以下几点需要注意:
1,由于UART 可能具有FIFO,依赖于具体实现,可能不是每个字符都能产生中断,用于唤醒;
2,UART 一般需要至少24MHz 以上的时钟频率,休眠需要保持时钟工作;
3,休眠唤醒系统只能识别到UART 中断就立即唤醒,无法对数据包进行解析判断后唤醒;
4,有些平台,唤醒的动作由CPUS/DSP 完成,因此存在CPUX 与CPUS/CPUX 分时复用UART 设备的问题,导致数据已丢失。

综上,我们不建议采用UART 唤醒功能,如明确需要使用,可与我司联系,并评估上述问题风险。

一般地,默认未支持,具体配置方法,可与我司联系。

• USB 插拔唤醒

通过插拔USB 时产生的中断唤醒系统。

这一般会依赖于PMU 或USB CC 器件支持,如明确需要使用,可与我司联系。

一般地,默认未支持,具体配置方法,需查阅TinaLinux USB 相关文档或与我司联系。

• MAD 唤醒

休眠后依靠硬件检测语音信号能量,若超过预设的阈值,将产生MAD 中断唤醒系统且同步录音。

一般地,默认未支持,具体配置方法,需查阅TinaLinux 音频相关文档或与我司联系。

3.3 休眠唤醒配置说明

在tina 源码根目录,执行make kernel_menuconfig,进入内核配置菜单。

如下图所示,进入Power management options 配置项:

图3-2: 休眠唤醒配置

选中以下配置项:

[*] Suspend to RAM and standby //使能休眠唤醒框架,默认选中
[*] Power Management Debug Support //使能休眠唤醒调试节点,默认选中

3.4 休眠唤醒流程说明

休眠唤醒流程基本上都是由内核框架完成,各家厂商差异不大。具体差异在于设备,系统,平台注册的回调函数,各厂商可通过修改这些回调,来适配各个平台,

实现差异化。

内核主要休眠流程:

1、冻结用户进程和线程;
2、休眠控制台,同步文件系统;
3、休眠设备,调用设备休眠回调(prepare,suspend,suspend_late,suspend_noirq),内核根据唤醒源配置使能和关闭中断;
4、关闭非引导CPU,关闭全局中断;
5、调用syscore休眠回调,休眠系统服务,如kernel time等;
6、调用平台休眠回调(suspend_ops->enter),进入最终的休眠状态。在此阶段可关闭不必要的时钟,电源,并进入等待唤醒模式。Tina中,各平台最终休眠状态的差别在于此函数的实现。

内核主要唤醒流程:

1、检测到唤醒中断后开始平台唤醒,从平台休眠回调(suspend_ops->enter)中退出,并使能休眠时关闭的时钟,电源;
2、调用syscore唤醒回调,恢复系统服务;
3、使能全局中断,使能关闭的CPU;
4、恢复设备,调用设备唤醒回调(resume_noirq,resume_early,resume,complete),内核在此阶段还原中断配置;
5、恢复控制台;
6、恢复用户进程和线程,还原到休眠前的状态。

在整个休眠流程中,调用回调函数的顺序,如下图所示:

图3-3: 休眠唤醒回调顺序

在本文中,无特殊说明,有如下约定:

绿色和蓝色方框部分:称为设备休眠唤醒回调,由设备驱动注册;每个驱动可注册一份或留空不注册,调用时,为每个设备都调用一次。

橙黄色方框部分:称为系统休眠唤醒回调,由内核模块注册,休眠系统服务,如内核时间服务等。

紫色方框部分:称为平台休眠唤醒回调,由平台厂商实现并注册,实现平台休眠逻辑,必须实现.valid 和.enter 函数,休眠的最终差异在于enter 函数的实现不

同。

3.5 wakeup count 模块

休眠唤醒是将系统从工作状态切换为非工作状态的一种技术,如果系统当前正在处理重要事件,而错误地切换到非工作状态,可能会造成使用体验不佳,甚至造成

严重的问题。因此休眠唤醒系统需要保证系统在执行一些重要事件时,不能休眠。

因此,一个完整的休眠唤醒框架需要实现以下几点:
(1)当系统正在处理重要事件时,系统不可以进入休眠;
(2)系统休眠过程中,若发生了重要事件需要处理,休眠应立即终止;
(3)系统进入休眠状态后,若发生了重要事件需要处理,应当立即唤醒;

最终内核把上述的“重要事件” 抽象为wakeup event,为了解决上述问题,内核又实现了wakeup count 模块。wakeup count 模块共维护两个计数,即系统当前正

在处理的wakeup event 个数(inpr)和系统已经处理完成的wakeup event 总数(cnt)。
1,休眠前,发起休眠的应用或内核程序,应该判断inpr 是否为0,然后否则应退出此次休眠。
2,休眠过程中,系统会比较save_cnt(进入休眠时的cnt 值)和cnt (当前系统的cnt 值)是否相同,且检测inpr 是不是0,若cnt 发生变化或inpr 不为0,则内核会终止休眠。
3,进入休眠后,系统会处于等待wakeup_event 对应的中断的状态,若发生,则系统唤醒。

3.6 wakelock 模块

在播放音视频或用户操作时,相关的应用程序可能需要阻止内核休眠,防止其他的应用程序或内核发起休眠,而导致设备异常。

为了解决这个问题,内核提供了wake lock 模块,该模块通过sysfs 文件系统想用户空间开放wake_lock 和wake_unlock 两个节点,应用程序可以通过这两个节点

向内核请求一个wakelock,此时内核会上报一个wakeup event,修改wakeup count 计数,阻止系统休眠。当应用程序处理完这一事件后,再通过wake_unlock

节点释放对应的wakelock,仅当系统中不存在任何一个wakelock 时,系统才可以休眠。

3.7 休眠参考示例

1、首先读出当前系统的wakeup count

若读取时阻塞,说明系统存在wakeup event 正在处理,即inpr 不为0,此时不能休眠。

若读取成功,则说明inpr 为0 ,且读出的值即为系统当前的cnt。

root@TinaLinux:/# cat /sys/power/wakeup_count
8

2、将读出的cnt 写回wakeup_count

若写入成功,说明cnt 被内核保存为save_cnt,之后系统可以休眠。

若写入失败,说明在本次读写cnt 的过程中产生了wakeup event,应该重复步骤1~2,直到写入成功。

root@TinaLinux:/# echo 8 > /sys/power/wakeup_count

3、尝试休眠

若休眠过程中未产生wakeup event,系统成功休眠。

若休眠过程中产生了wakeup event,内核会检测到inpr 不为0,或当前cnt 不等于save_cnt,系统会终止休眠,回退到正常状态,应用程序可等待一段时间后,重

复1~3 步,再次尝试。

root@TinaLinux:/# echo mem > /sys/power/state

休眠脚本示例:

#!/bin/ash
function suspend()

while true; do
if [ -f '/sys/power/wakeup_count' ] ; then
cnt=$(cat /sys/power/wakeup_count)
echo "Read wakeup_count: $cnt"
echo $cnt > /sys/power/wakeup_count
if [ $? -eq 0 ] ; then
echo mem > /sys/power/state
break;
else
echo "Error: write wakeup_count($cnt)"
sleep 1;
continue;
fi
else
echo "Error: File wakeup_count not exist"
break;
fi
done

echo "try to mem..."
suspend

技巧

休眠时不应连接usb,在usb 连接状态下,usb driver 会上报wake event,且永远不会释放,导致读取wakeup_count 阻塞。若出现执行阻塞的情况,拔掉USB 即可。

3.8 基础节点说明

state

路径:/sys/power/state

Linux 标准节点,系统休眠状态配置节点。通过写入不同的状态级别(freeze,standby,mem)可使系统进入到不同级别的休眠状态。

freeze 状态为Linux 系统自身支持的一种休眠状态,与平台无耦合,不调用到平台回调接口,无底层总线,时钟,电源控制,但会在调用设备休眠回调后进入

cpuidle 状态。

standby,mem 状态在tina 中效果相同。

# 强制进入休眠,不会判断系统inpr, cnt 状态

root@TinaLinux:/# echo mem > /sys/power/state

警告

未通过wakeup_count 节点判断系统当前状态是否可以休眠,而直接使用echo mem > /sys/power/state命令强制系统进入休眠会使休眠唤醒流程忽略对inpr 和

cnt 变量检测,可能会导致一些同步问题。如休眠过程中,WIFI 唤醒中断不能导致休眠流程终止,而出现系统强制休眠,无法唤醒的异常。

wakeup_count

路径:/sys/power/wakeup_count

Linux 标准节点,将wakeup count 模块维护的计数开放到用户空间,为应用程序提供一个判断系统是否可以休眠的接口。

具体使用参考上文wakeup count 相关说明。

wake_[un]lock

路径:/sys/power/wake_lock、/sys/power/wake_unlock

Linux 标准节点,wake lock 模块开放到用户空间的接口。

应用程序可以通过wake_lock 节点申请一个lock,并通过wake_unlock 节点释放对应的lock,任一应用程序持有wakelock,系统都不休眠。

# 申请一个NativePower.Display.lock

root@TinaLinux:/# echo NativePower.Display.lock > /sys/power/wake_lock

# 可以查看有系统中存在哪些wakelock

root@TinaLinux:/# cat /sys/power/wake_lock
NativePower.Display.lock

# 释放NativePower.Display.lock

root@TinaLinux:/# echo NativePower.Display.lock > /sys/power/wake_unlock

# 可以查看那些wakelock被释放

root@TinaLinux:/# cat /sys/power/wake_unlock
NativePower.Display.lock

技巧
注意:强制休眠命令不会判断系统inpr, cnt 状态,因此wake_lock 机制无效。

pm_print_times

路径:/sys/power/pm_print_times

Linux 标准节点,该节点标志是否在休眠唤醒流程中,打印device 休眠唤醒调用信息。

该节点默认值为0,即不打印设备调用信息。

# 使能设备回调信息输出

root@TinaLinux:/# echo 1 > /sys/power/pm_print_times

pm_wakeup_irq

路径:/sys/power/pm_wakeup_irq

Linux 标准节点,只读。用于查看上一次唤醒系统的唤醒中断号。

说明

在Linux-4.9 中,该节点对于外部唤醒源的中断无法正常显示。

这是由于pinctrl 驱动中,为gpio 设置了IRQF_NO_SUSPEND 标志导致,由于影响模块较多,暂不处理。

# 使能设备回调信息输出

root@TinaLinux:/# cat /sys/power/pm_wakeup_irq

pm_test

路径:/sys/power/pm_test

Linux 标准节点。由内核实现的一种休眠唤醒调试机制。

读该节点会打印其支持的调试点,如下:

# linux 默认支持的调试点

root@TinaLinux:/# cat /sys/power/pm_test
[none] core processors platform devices freezer

对该节点写入其支持的调试点,会在休眠过程中,执行到该调试点时,等待几秒后返回。

root@TinaLinux:/# echo core > /sys/power/pm_test

说明
Freezer:任务冻结后,等待5s,即返回;
Devices:执行设备回调prepare,suspend 后,等待5s,即返回;
Platform:执行设备回调suspend_late、suspend_noirq 后,等待5s,即返回;
Processors:关闭非引导cpu 后,等待5s,即返回;
Core:冻结系统服务,如内核时间服务后,等待5s,即返回;
None:整个休眠流程全部走完,需触发唤醒源唤醒;

console_suspend

路径:/sys/module/printk/parameters/console_suspend

Linux 标准节点,该节点标记在系统进入休眠时,是否休眠控制台。

这个节点默认值为Y,即默认会休眠控制台。

将其设置为N 后,系统休眠时将不休眠控制台,这样可以将休眠后期(控制台休眠阶段后)的日志实时打印到控制台,便于调试。

# 禁用控制台休眠

root@TinaLinux:/# echo N > /sys/module/printk/parameters/console_suspend

ignore_loglevel

路径:/sys/module/printk/parameters/ignore_loglevel

Linux 标准节点,忽略打印级别控制。

这个节点默认值为N,即不忽略打印级别,仅输出可打印级别的日志。可打印级别由proc/sys/kernel/printk 点控制。

将其设置为Y 后,任何级别的系统日志都可以输出到控制台。这不仅仅在休眠唤醒过程中有效,

在系统正常工作时也有效。

# 忽略系统日志打印级别

root@TinaLinux:/# echo Y > /sys/module/printk/parameters/ignore_loglevel

initcall_debug

路径:/sys/module/kernel/parameters/initcall_debug

Linux 标准节点,该节点标记是否开启内核早期日志,在内核启动早期先初始化控制台,输出内核启动早期日志信息。在休眠唤醒流程中,会影响到唤醒早期部分

日志的打印。

该节点默认值由内核参数确定,一般为N,即不使能早期打印。将其设置为Y 后,会多打印syscore_ops 调用信息。

使能该节点后,会休眠唤醒过程中打印各个设备休眠唤醒回调的调用顺序及返回值,通过这些打印信息,可以判断出是哪个设备休眠唤醒回调出了问题,方便调

试。

# 使能早期打印

root@TinaLinux:/# echo Y > /sys/module/kernel/parameters/initcall_debug

4 差异化方案说明

4.1 V853 休眠唤醒差异介绍

4.1.1 e907 的处理

V853 包含一个riscv 协处理器(e907 ),主要负责一些录像相关驱动及算法的处理。由于其运行在dram 中,系统休眠后它不能运行,因此它不会参与到最终的休

眠唤醒流程中。为了保证休眠唤醒后,e907 不会因为dram 进入自刷新而出现跑飞的情况,我们必须在dram 进入自刷新模式前将其关停,dram 恢复后再让其恢

复运行现场。

为了将e907 关停,我们将e907 作为linux 的一个外设,实现对应驱动的suspend/resume函数。在supend 函数中,通过核间通信机制通知e907 系统即将休眠,

e907 收到消息后保存自己的现场并进入关停状态(WFI)。最终e907 会下电,唤醒时,由cpux 为其上电,然后在resume 函数中,同样发送系统唤醒消息,

e907 通过该消息中断触发自己恢复现场运行。

4.1.2 基于boot 的superstandby 实现

superstandby 的主要特点是可以将主cpu 完全关闭,达到极致休眠功耗的目的。但由于cpu 需要掉电重开,因此一般会借助协处理器或其他硬件实现,例如

cpus, dsp 等。但在v853上,方案上没有上述硬件单元,因此在实现superstandby 时借助了rtc 部分寄存器不会掉电复位的特性。具体流程如下:
• 休眠时,先执行kernel 休眠流程,冻结任务,关闭设备,并保存cpu 现场;
• 判断如果是superstandby, 则保存C 一个superstandby flag 到rtc 寄存器中,并下电CPU;
• 唤醒时,由硬件触发自动cpu 上电,并运行到boot0;
• boot0 检查是否设置了superstandby flag,如果未设置,则走冷启动流程;
• 如果已设置,则直接在唤醒dram 后,跳转到唤醒地址上运行,进入唤醒流程。
• 执行唤醒流程,完成唤醒。

注:此种方式实现基本不依赖任何硬件模块,仅需要硬件可以在触发后自动上电即可(如开机键)。缺点是,唤醒后系统需要执行boot0, 才能进入唤醒流程,这会

拖慢唤醒速度,不利于快唤醒场景。

5 FAQ 问题及处理方法

5.1 系统无法休眠

这种问题一般是由于使用了wakelock 机制,在休眠前判断系统状态时,系统存在wakelock ,最终导致系统无法进入休眠流程。

处理:
• 一般先通过cat /sys/power/wake_lock 来确认是否存在wakelock;
• 注意:如果连接了usb,则usb driver 会申请wakelock,但该用户空间节点无法读出来。
• 如果存在usb 链接,拔掉usb;存在wakelock, 则可以通过cat /sys/power/wake_unlock 节点来取消该wakelock;
• 然后再次尝试使用上文的休眠脚本示例休眠;
• 另外,也可以直接执行echo mem > /sys/power/state在不释放wakelock 的情况下,强制休眠,来验证一些这个问题。注: 我们一般建议此操作仅用于临时调试,因为该操作会导致wakelock没有效果。
• 最终,需要找出设置wakelock 的模块,跟本上解决问题。

5.2 系统休眠后直接重启或延时几秒后重启

这种问题一般是由于休眠过程中,某一驱动模块oops 卡死,导致触发保护机制重启,或休眠后系统掉电异常,例如rtc 的电也掉了导致。

对于前者,可以使能休眠唤醒日志,确认是哪一模块,然后找相关同事协助处理;临时测试,也可以先尝试去掉该驱动模块;

# 使能休眠唤醒所有的日志

echo 1 > /sys/power/pm_print_times;
echo N > /sys/module/printk/parameters/console_suspend;
echo Y > /sys/module/kernel/parameters/initcall_debug;
echo 8 > /proc/sys/kernel/printk;

对于后者,先排除前者问题后,可以用万用表或示波器抓取一些关键电源的休眠状态,如vccrtc,vdd-cpu, vdd-sys, vcc-pll 等,然后与正常机器比较,或找相关硬

件同事确认。

也有一些其他原因,如内存踩踏等,可导致此现象,这里不展开说明。

5.3 休眠后系统无法唤醒

这种问题是最常见的休眠唤醒问题,导致该现象的问题原因也比较多,包括但不限于,唤醒源配置不对,内核卡死但未触发重启,cpus/dsp/optee 等卡死,内存

踩踏或使用超出范围内存,dram 不正常,系统硬件问题。所以我们一般会建议客户通过以下流程逐步收集一些有用信息,如果发现问题跟因客户可根据情况自行

处理,若未发现跟因也可提供到我们进一步排查,可大大节省排查时间:

• 使用powerkey,rtc 等默认唤醒源唤醒,排除由于唤醒源配置导致的无法唤醒;

• 使能日志,排除由于系统卡死导致,导致休眠没有完成而无法唤醒;

• 与正常机器对比,回退部分提交,确认问题大致什么时间以及什么模块引入;

• 通过/sys/power/pm_test 节点,执行不同深度的休眠,确认问题点出现在休眠唤醒流程的哪个阶段;

• 如果echo core > /sys/power/pm_test 后仍不可以唤醒,说明问题大概率出现kernel 模块中,否则问题可能在cpus/dsp/optee 等阶段;

• 通过观察cpus,dsp,optee 串口日志,确认其是否存活。

• 通过仪器测量各路电源状态,以及在休眠流程中对一些寄存器(时钟、电源、IO 状态)值进行确认,细化问题点;

也有一些其他原因,如内存踩踏等,可导致此现象,这里不展开说明。

5.3 休眠后系统无法唤醒

这种问题是最常见的休眠唤醒问题,导致该现象的问题原因也比较多,包括但不限于,唤醒源配置不对,内核卡死但未触发重启,cpus/dsp/optee 等卡死,内存

踩踏或使用超出范围内存,dram 不正常,系统硬件问题。所以我们一般会建议客户通过以下流程逐步收集一些有用信息,如果发现问题跟因客户可根据情况自行

处理,若未发现跟因也可提供到我们进一步排查,可大大节省排查时间:

• 使用powerkey,rtc 等默认唤醒源唤醒,排除由于唤醒源配置导致的无法唤醒;

• 使能日志,排除由于系统卡死导致,导致休眠没有完成而无法唤醒;

• 与正常机器对比,回退部分提交,确认问题大致什么时间以及什么模块引入;

• 通过/sys/power/pm_test 节点,执行不同深度的休眠,确认问题点出现在休眠唤醒流程的哪个阶段;

• 如果echo core > /sys/power/pm_test 后仍不可以唤醒,说明问题大概率出现kernel 模块中,否则问题可能在cpus/dsp/optee 等阶段;

• 通过观察cpus,dsp,optee 串口日志,确认其是否存活。

• 通过仪器测量各路电源状态,以及在休眠流程中对一些寄存器(时钟、电源、IO 状态)值进行确认,细化问题点;

• 如果上述都不能找到有效点,可以联系处理,并尽可能提供相关信息。

以上是关于Tina_Linux_功耗管理_开发指南的主要内容,如果未能解决你的问题,请参考以下文章

Tina_Linux配网开发指南

Tina_Linux_启动优化_开发指南

Tina_Linux_图形系统_开发指南

Tina_Linux_系统裁剪_开发指南

Tina_Linux_安全_开发指南

Tina_Linux_音频_开发指南