深圳做微信网站公司名称,全网营销与seo,网站轮播图怎么做的,网站流量查询 优帮云Tina Linux 功耗管理开发指南
1 概述
1.1 编写目的
简要介绍tina 平台功耗管理机制#xff0c;为关注功耗的开发者#xff0c;维护者和测试者提供使用和配置参考。
1.2 适用范围 表1-1: 适用产品列表产品名称内核版本休眠类型参与功耗管理的协处理器R328Linux-4.9NormalS…Tina Linux 功耗管理开发指南
1 概述
1.1 编写目的
简要介绍tina 平台功耗管理机制为关注功耗的开发者维护者和测试者提供使用和配置参考。
1.2 适用范围
表1-1: 适用产品列表产品名称内核版本休眠类型参与功耗管理的协处理器R328Linux-4.9NormalStandby无R329Linux-4.9SuperStandbyDSP0D1-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 hotplugcpuidle 等子系
统组成。主要用于对系统功耗进行管理和控制平衡设备功耗和性能。
一般我们可将其分为两类即静态功耗管理和动态功耗管理。 图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、SuperStandbyAllwinner 内部术语系统进入一种低功耗状态暂停运行以获取更低的功耗表现区别是CPUX 是否掉电。前者CPUX 不掉电系统唤醒直接借助于CPUX 的WFI 指令完成。后者CPUX 掉电系统唤醒需借助其他硬件模块实现如CPUS。Arm TrustedFirmwareARMv8-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插拔MADR328NYNY–––YR329Yˆ1YYY–Yˆ2–YD1-HNYYY––––V853Y–YY––Y–
注Y: 支持N: 不支持–: 未明确
ˆ1: 仅带PMU 的方案支持
ˆ2: 仅suart 支持
3 Tina 休眠唤醒系统简介
3.1 唤醒源分类
唤醒源唤醒的本质是触发系统中断因此在tina 平台上我们可以按照中断不同将唤醒源分为两大类
1、内部唤醒源一般为IC 内部外设有自己独立的中断如RTCUARTLRADCUSB等。
2、外部唤醒源这类设备都通过GPIO 中断实现唤醒功能占用一个对应的引脚如WIFIBTGPIOKEY 等。
如下图粉色为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 内核驱动已经实现的唤醒源简述其功能。由于各平台实现存在差异对于以下唤醒源的支持可能不一致具体请参考唤醒源支持列表。
• PowerKeyNMI
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” 属性即可使能。
• WIFIGPIO唤醒
本质上是对应引脚的GPIO 中断唤醒。
依赖于WIFI 模块本身对数据包的监听和管理若模块或驱动无法支持该功能亦无法使用实际以模块自身配置为准。
一般地默认使能如未使能则在dts 中wlan 设备节点下配置相应的GPIO 引脚和“wakeup-source” 属性即可使能如有疑问可查阅Tina_Linux WLAN 模块
相关文档。
• BTGPIO唤醒
与BT 相同本质上是对应引脚的GPIO 中断唤醒。
依赖于BT 模块本身对数据包的监听和管理若模块或驱动无法支持该功能亦无法使用实际以模块自身配置为准。
一般地默认未支持具体配置方法需查阅TinaLinux BT 相关文档或与我司联系。
• UART 唤醒
通过UART 接受到字符产生的中断唤醒系统。
在UART 唤醒功能中有以下几点需要注意 1由于UART 可能具有FIFO依赖于具体实现可能不是每个字符都能产生中断用于唤醒 2UART 一般需要至少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。
rootTinaLinux:/# cat /sys/power/wakeup_count
82、将读出的cnt 写回wakeup_count
若写入成功说明cnt 被内核保存为save_cnt之后系统可以休眠。
若写入失败说明在本次读写cnt 的过程中产生了wakeup event应该重复步骤12直到写入成功。
rootTinaLinux:/# echo 8 /sys/power/wakeup_count3、尝试休眠
若休眠过程中未产生wakeup event系统成功休眠。
若休眠过程中产生了wakeup event内核会检测到inpr 不为0或当前cnt 不等于save_cnt系统会终止休眠回退到正常状态应用程序可等待一段时间后重
复1~3 步再次尝试。
rootTinaLinux:/# 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 标准节点系统休眠状态配置节点。通过写入不同的状态级别freezestandbymem可使系统进入到不同级别的休眠状态。
freeze 状态为Linux 系统自身支持的一种休眠状态与平台无耦合不调用到平台回调接口无底层总线时钟电源控制但会在调用设备休眠回调后进入
cpuidle 状态。
standbymem 状态在tina 中效果相同。
# 强制进入休眠不会判断系统inpr, cnt 状态rootTinaLinux:/# 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.lockrootTinaLinux:/# echo NativePower.Display.lock /sys/power/wake_lock# 可以查看有系统中存在哪些wakelockrootTinaLinux:/# cat /sys/power/wake_lock
NativePower.Display.lock# 释放NativePower.Display.lockrootTinaLinux:/# echo NativePower.Display.lock /sys/power/wake_unlock# 可以查看那些wakelock被释放rootTinaLinux:/# cat /sys/power/wake_unlock
NativePower.Display.lock技巧 注意强制休眠命令不会判断系统inpr, cnt 状态因此wake_lock 机制无效。
pm_print_times
路径/sys/power/pm_print_times
Linux 标准节点该节点标志是否在休眠唤醒流程中打印device 休眠唤醒调用信息。
该节点默认值为0即不打印设备调用信息。
# 使能设备回调信息输出rootTinaLinux:/# echo 1 /sys/power/pm_print_timespm_wakeup_irq
路径/sys/power/pm_wakeup_irq
Linux 标准节点只读。用于查看上一次唤醒系统的唤醒中断号。
说明
在Linux-4.9 中该节点对于外部唤醒源的中断无法正常显示。
这是由于pinctrl 驱动中为gpio 设置了IRQF_NO_SUSPEND 标志导致由于影响模块较多暂不处理。
# 使能设备回调信息输出rootTinaLinux:/# cat /sys/power/pm_wakeup_irqpm_test
路径/sys/power/pm_test
Linux 标准节点。由内核实现的一种休眠唤醒调试机制。
读该节点会打印其支持的调试点如下
# linux 默认支持的调试点rootTinaLinux:/# cat /sys/power/pm_test
[none] core processors platform devices freezer对该节点写入其支持的调试点会在休眠过程中执行到该调试点时等待几秒后返回。
rootTinaLinux:/# echo core /sys/power/pm_test说明 Freezer任务冻结后等待5s即返回 Devices执行设备回调preparesuspend 后等待5s即返回 Platform执行设备回调suspend_late、suspend_noirq 后等待5s即返回 Processors关闭非引导cpu 后等待5s即返回 Core冻结系统服务如内核时间服务后等待5s即返回 None整个休眠流程全部走完需触发唤醒源唤醒
console_suspend
路径/sys/module/printk/parameters/console_suspend
Linux 标准节点该节点标记在系统进入休眠时是否休眠控制台。
这个节点默认值为Y即默认会休眠控制台。
将其设置为N 后系统休眠时将不休眠控制台这样可以将休眠后期控制台休眠阶段后的日志实时打印到控制台便于调试。
# 禁用控制台休眠rootTinaLinux:/# echo N /sys/module/printk/parameters/console_suspendignore_loglevel
路径/sys/module/printk/parameters/ignore_loglevel
Linux 标准节点忽略打印级别控制。
这个节点默认值为N即不忽略打印级别仅输出可打印级别的日志。可打印级别由proc/sys/kernel/printk 点控制。
将其设置为Y 后任何级别的系统日志都可以输出到控制台。这不仅仅在休眠唤醒过程中有效
在系统正常工作时也有效。
# 忽略系统日志打印级别rootTinaLinux:/# echo Y /sys/module/printk/parameters/ignore_loglevelinitcall_debug
路径/sys/module/kernel/parameters/initcall_debug
Linux 标准节点该节点标记是否开启内核早期日志在内核启动早期先初始化控制台输出内核启动早期日志信息。在休眠唤醒流程中会影响到唤醒早期部分
日志的打印。
该节点默认值由内核参数确定一般为N即不使能早期打印。将其设置为Y 后会多打印syscore_ops 调用信息。
使能该节点后会休眠唤醒过程中打印各个设备休眠唤醒回调的调用顺序及返回值通过这些打印信息可以判断出是哪个设备休眠唤醒回调出了问题方便调
试。
# 使能早期打印rootTinaLinux:/# echo Y /sys/module/kernel/parameters/initcall_debug4 差异化方案说明
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 不正常系统硬件问题。所以我们一般会建议客户通过以下流程逐步收集一些有用信息如果发现问题跟因客户可根据情况自行
处理若未发现跟因也可提供到我们进一步排查可大大节省排查时间
• 使用powerkeyrtc 等默认唤醒源唤醒排除由于唤醒源配置导致的无法唤醒
• 使能日志排除由于系统卡死导致导致休眠没有完成而无法唤醒
• 与正常机器对比回退部分提交确认问题大致什么时间以及什么模块引入
• 通过/sys/power/pm_test 节点执行不同深度的休眠确认问题点出现在休眠唤醒流程的哪个阶段
• 如果echo core /sys/power/pm_test 后仍不可以唤醒说明问题大概率出现kernel 模块中否则问题可能在cpus/dsp/optee 等阶段
• 通过观察cpusdspoptee 串口日志确认其是否存活。
• 通过仪器测量各路电源状态以及在休眠流程中对一些寄存器时钟、电源、IO 状态值进行确认细化问题点
也有一些其他原因如内存踩踏等可导致此现象这里不展开说明。
5.3 休眠后系统无法唤醒
这种问题是最常见的休眠唤醒问题导致该现象的问题原因也比较多包括但不限于唤醒源配置不对内核卡死但未触发重启cpus/dsp/optee 等卡死内存
踩踏或使用超出范围内存dram 不正常系统硬件问题。所以我们一般会建议客户通过以下流程逐步收集一些有用信息如果发现问题跟因客户可根据情况自行
处理若未发现跟因也可提供到我们进一步排查可大大节省排查时间
• 使用powerkeyrtc 等默认唤醒源唤醒排除由于唤醒源配置导致的无法唤醒
• 使能日志排除由于系统卡死导致导致休眠没有完成而无法唤醒
• 与正常机器对比回退部分提交确认问题大致什么时间以及什么模块引入
• 通过/sys/power/pm_test 节点执行不同深度的休眠确认问题点出现在休眠唤醒流程的哪个阶段
• 如果echo core /sys/power/pm_test 后仍不可以唤醒说明问题大概率出现kernel 模块中否则问题可能在cpus/dsp/optee 等阶段
• 通过观察cpusdspoptee 串口日志确认其是否存活。
• 通过仪器测量各路电源状态以及在休眠流程中对一些寄存器时钟、电源、IO 状态值进行确认细化问题点
• 如果上述都不能找到有效点可以联系处理并尽可能提供相关信息。
