PROCESSOR-SDK-AM62X: Weston Fails to Wake from idle-time Sleep, Restarts After SIGTERM

Hi,

I am checking with our dev team and will get back to you.

Regards,
Krunal

Hi,

Is it possible for you to remove the GPU module and relaunch weston with CPU. We would like to isolate the issue between GPU and DSS.

Regards,
Krunal

Hi,

Thank you for the suggestion. As requested, I disabled the GPU module (pvrsrvkm) and relaunched Weston using CPU-based rendering (Pixman) to isolate whether the issue is related to the GPU or DSS. Below, I'll detail the steps I followed, the configurations used, the observed behavior, and key logs. I've attached a PDF document ("weston-log") containing the full logs.

System details:

• 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

Steps Taken to Disable GPU and Use CPU Rendering

1. Disabled GPU Module:

   • Verified loaded modules with lsmod (pvrsrvkm was present).
   • Removed the module: rmmod pvrsrvkm.
   • Confirmed removal with lsmod (pvrsrvkm no longer listed).

2. Modifed Weston Configuration for CPU Rendering:(weston.ini)

   • Edited /etc/xdg/weston/weston.ini to force software rendering by adding use-pixman=true under the [drm] section. This disables GPU acceleration and uses Pixman (CPU-based).

3. Launched Weston with Strace for Debugging:(strace)

   • Ran strace -f -o /tmp/weston.strace weston to capture traces.
   • Allowed idle for 20 seconds → screen blanked.
   • Attempted wake-up with mouse/keyboard → no wake-up; Weston crashed after ~2.5 minutes with SIGABRT (signal 6).

Observed Behavior

• Idle Entry: After 20 seconds, the screen blanks correctly (HDMI signal stops, monitor enters sleep mode).
• Wake Attempt: Mouse movement or key press does not restore the display. Screen remains blank.
• Crash: After  wake-up with mouse/keyboard Weston aborts with an assertion failure: weston: /usr/src/debug/weston/13.0.1/libweston/compositor.c:3730: weston_output_finish_frame: Assertion timespec_sub_to_nsec(stamp, &output->frame_time) >= 0' failed.`
• No GPU Involvement: The crash still occurs in pure CPU rendering mode, confirming the GPU (pvrsrvkm) is not the root cause.
• Manual Restart Required: Had to restart Weston via systemctl restart weston to recover the GUI.

This matches the original issue, but now isolated to CPU/DSS paths.

Logs from Strace Run

• Weston starts successfully in DRM backend with Pixman renderer.
• Detects HDMI-A-1 output, sets mode 1024x768@60.0.
• Enters sleep mode after idle.
• Upon wake attempt: Assertion failure due to negative timestamp delta.
• Full startup log excerpt:
   

  Date: 2025-05-29 UTC

  [21:54:02.191] weston 13.0.1

  ...

  [21:54:02.316] Using Pixman renderer

  ...

  [21:54:08.111] DRM: head 'HDMI-A-1' found, connector 41 is connected...

  [21:54:08.125] Output HDMI-A-1 (crtc 39) video modes: 1024x768@60.0, current...

  ...

  Enters sleep mode

  ...

  weston: ... Assertion `timespec_sub_to_nsec(stamp, &output->frame_time) >= 0' failed.

  Aborted (core dumped)
• Audit logs show SIG6 (ABRT) on Weston PID.

Additional Tests with Modetest 

To further isolate DSS behavior:

• modetest -M tidss -s 41@39:1024x768-60: Sets mode; screen shows colored display until Enter pressed (returns to black).
• modetest -M tidss -w 41:DPMS:3: Screen darkens briefly, then back to black (expected low-power state, but HDMI signal doesn't fully stop as monitor doesn't enter standby).
• modetest -M tidss -w 41:DPMS:0: No change; screen remains black (should restore signal and wake monitor, but doesn't).

Expected vs. Actual for DPMS:

• DPMS:3 (Off): HDMI signal should stop fully (monitor to standby), low power engaged. Actual: Brief darken, no full signal stop.
• DPMS:0 (On): Signal restored, monitor wakes, image reappears without mode reset. Actual: No change; indicates bug in atomic commit or encoder enable logic in tidss driver.

Key Findings 

• Crash persists in software rendering → GPU not root cause; likely DSS 

Let me know if you need any additional tests or logs. Thanks for your assistance!

Best regards,

Eya

Hello,

Could you please try the following patch: https://lore.kernel.org/all/20250905-tidss-fix-timestamp-v1-0-c2aedf31e2c9@ideasonboard.com/

Regards,
Krunal

When I tried to apply the patch file directly with the patch tool on my tidss_dispc.c, the application failed. This indicates my kernel tree’s tidss_dispc.c didn’t match exactly the context expected by the patch (likely due to version differences) i got this do-patch error message( error-do-patch-bitbake).

i specifically could not apply this part of [patch 1/2]:

@@ -1244,7 +1231,10 @@ void dispc_vp_enable(struct dispc_device *dispc, u32 hw_videoport,
mode->crtc_hdisplay - 1) |
FIELD_PREP(DISPC_VP_SIZE_SCREEN_VDISPLAY_MASK,
mode->crtc_vdisplay - 1));
+}

i can't find the highlighted part in my  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  

What I did manually

• update tidss_crtc.c and tidss_crtc.c  with no problem

• Merged the contents of dispc_vp_enable() into dispc_vp_prepare() (except the final enable bit).

• Simplified dispc_vp_enable() to only set the enable bit.

• Created a patched tidss_dispc.c successfully.

  the manual modification didn't solve the problem and still got an error at kernel module compilation here is the log attached: do-compile-kernel-modules-log

Request for help:

• Is there a recommended TI kernel branch or version where this patch applies cleanly? im using the 6.12.35 kernel version

Hi,

I am checking with our driver team and I will get back to you.

Regards,
Krunal