[参考译文] PROCESSOR-SDK-AM62X：Weston 无法从空闲时间睡眠状态唤醒、在 SIGTERM 之后重新启动

您好、

我正在与我们的开发团队核实、并会回复您。

此致、
Krunal

您好、

是否可以移除 GPU 模块并使用 CPU 重新启动 Weston？ 我们想找出 GPU 和 DSS 之间的问题。

此致、
Krunal

您好、

感谢您的建议。 根据请求、我禁用了 GPU 模块 (pvrsrvkm) 并使用基于 CPU 的渲染 (Pixman) 重新启动 Weston、以确定问题是否与 GPU 或 DSS 有关。 下面、我将详细介绍我遵循的步骤、使用的配置、观察到的行为和密钥日志。 我附上了一份包含完整日志的 PDF 文档（“Weston-log")“）。

系统详细信息：

• uname -A：Linux am62xx-EVM 6.12.35-ti-00915-ge3e551586dfa #1 SMP Preempt Tue Jul 1 21：17：52 UTC 2025 AArch64 GNU/Linux
• Cat /etc/os-release：Arago 2025.01

禁用 GPU 和使用 CPU 渲染的步骤

1. 已禁用 GPU 模块 ：

   • 已使用 lsmod 验证加载的模块（存在 pvrsrvkm）。
   • 已删除模块：rmmod pvrsrvkm。
   • 已使用 lsmod 确认删除（不再列出 pvrsrvkm）。

2. 用于 CPU 呈现的修改的 Weston 配置 :(weston.ini)

   • 编辑了/etc/xdg/weston/weston.ini 以通过在[DRM]部分下添加 use-pixman=true 来强制进行软件渲染。 这将禁用 GPU 加速并使用 Pixman（基于 CPU）。

3. 启动 Weston 并使用 strace 进行调试 (strace)

   • 运行 strace -f -o /tmp/weston.strace Weston 以捕获跟踪。
   • 允许空闲 20 秒→屏幕消隐。
   • 使用鼠标/键盘尝试唤醒→未唤醒；使用 SIGABRT（信号 6）时、Weston 在~2.5 分钟后崩溃。

观察到的行为

• 空闲进入 ：20 秒后、屏幕会正确消隐（HDMI 信号停止，显示器进入睡眠模式）。
• 尝试唤醒 ：鼠标移动或按键无法恢复显示。 屏幕保持空白。
• 崩溃 :  用鼠标/键盘唤醒后 ,威斯顿以断言失败中止: weston:/usr/weston/debug/weston/13.0.1/libweston/compositor.c:3730: src weston_output_fine_frame:断言 timespec_sub_to_nsec(stamp,&output->frame_time)>= 0'失败。`
• 无 GPU 参与 :在纯 CPU 渲染模式下仍会发生崩溃,确认 GPU (pvrsrvkm) 不是根本原因。
• 需要手动重启 :必须通过 systemctl restart weston 重新启动 weston 以恢复 GUI。

这与原始问题相匹配、但现在已隔离到 CPU/DSS 路径。

来自 strace Run 的日志

• Weston 使用 Pixman 渲染器在 DRM 后端成功启动。
• 检测 HDMI-A-1 输出、设置模式 1024x768@60.0。
• 在 IDLE 后进入 SLEEP 模式。
• 唤醒尝试时：由于负时间戳差值、生效失败。
• 完整的启动日志摘录：
   

  日期：2025年05月29日 UTC

  [21：54：02.191] Weston 13.0.1

  ...

  [21:54:02.316]使用 Pixman 渲染器

  ...

  [21：54：08.111] DRM：找到“HDMI-A-1"，“，连接器、连接器 41 已连接...

  [21：54：08.125]输出 HDMI-A-1 (CRTC 39) 视频模式：1024x768@60.0、电流...

  ...

  进入 SLEEP 模式

  ...

  Weston：...断言`timespec_sub_to_nsec (stamp、&output->frame_time)>= 0'失败。

  已中止（核心已转储）
• 审计日志在 Weston PID 上显示 SIG6 (ABRT)。

使用 Modetest 进行附加测试  

要进一步隔离 DSS 行为、请执行以下操作：

• modetest -M tidss -s 41@39：1024x768-60：设置模式；屏幕显示彩色显示、直至按下 Enter（返回黑色）。
• modetest -M tidss -w 41:DPMS:3:屏幕短暂变暗,然后恢复为黑色（预期低功耗状态,但 HDMI 信号不会完全停止,因为显示器不进入待机状态）。
• modetest -M tidss -w 41:DPMS:0:无变化;屏幕保持黑色（应恢复信号和唤醒监视器,但不）。

DPMS 的预期值与实际值 ：

• DPMS：3（关闭） ：HDMI 信号应完全停止（显示器进入待机状态）、低功耗接合。 实际：短暂变暗、无完整信号停止。
• DPMS：0（开） ：信号恢复、显示器唤醒、图像在没有模式重置的情况下重新出现。 实际：无变化；指示 tidss 驱动程序中原子提交或编码器使能逻辑中的错误。

关键发现  

• 软件渲染过程中崩溃仍然存在→GPU 不是根本原因；可能是 DSS  

如果您需要任何其他测试或日志、请告诉我。 感谢您的帮助！

此致、

Eya

您好：

请尝试以下补丁： https://lore.kernel.org/all/20250905-tidss-fix-timestamp-v1-0-c2aedf31e2c9@ideasonboard.com/

此致、
Krunal

当我尝试使用patch上的工具直接应用修补程序文件时tidss_dispc.c、应用程序失败。 这表明我的内核树tidss_dispc.c与补丁预期的上下文不完全匹配（可能是由于版本差异）我收到了这个 do-patch 错误消息 ( error-do-patch-bitbake)。

我特别无法应用[补丁 1/2]的这一部分：

@@–1244、7 +1231、10 @@ void dispc_vp_enable (struct dispc_device *dispc、u32 hw_videoport、
mode->CRC_hdisplay –1)|
FIELD_PREP (DISPC_VP_SIZE_SCREEN_VDISPLAY_MASK、
Mode->CRC_vdisplay –1))；
+｝

在我的中找不到突出显示的器件   tidss_dispc.c file 
i can't find any information about the version of vernel module the patch applies to

i tried to apply it manualy  

我手动做了什么

• 更新tidss_crtc.c 和  tidss_CRTC.c 、没有任何问题

• 将的内容合并dispc_vp_enable()到中dispc_vp_prepare()（最后一个使能位除外）。

• 简化dispc_vp_enable()为仅设置使能位。

• 已tidss_dispc.c成功创建修补程序。

  手动修改没有解决这个问题,在内核模块编译时仍然出错。下面是附加的日志: do-compile-kernel-modules-log

请求帮助：

• 是否有可完全应用此补丁的建议 TI 内核分支或版本？ 使用 6.12.35 内核版本的 IM

您好、

我正在与我们的驾驶员团队核实、我会回复您。

此致、
Krunal