Enter Suspend mode for an unknown reason

we just plug out/in hdmi, but the system enter suspend mode for an unknown reason, and out again the suspend, help to analyze the attached log file. why it enter this mode.
line 1519:
[ 581.029365] PM: suspend entry 2022-08-27 07:26:33.813719216 UTC
[ 581.029369] PM: Syncing filesystems … done.
[ 581.111130] PM: Preparing system for sleep (mem)

line 1662:
[ 583.105832] PM: suspend of devices complete after 1385.706 msecs
[ 583.108074] host1x 50000000.host1x: suspended
[ 583.108275] PM: late suspend of devices complete after 2.432 msecs
[ 583.129030] PM: noirq suspend of devices complete after 20.744 msecs
[ 583.129035] Disabling non-boot CPUs …
[ 583.144334] IRQ10 no longer affine to CPU1
[ 583.148762] CPU1: shutdown
[ 583.151503] psci: CPU1 killed.
[ 583.172304] IRQ11 no longer affine to CPU2
[ 583.176795] CPU2: shutdown
[ 583.179529] psci: CPU2 killed.
[ 583.196293] IRQ12 no longer affine to CPU3
[ 583.200821] CPU3: shutdown
[ 583.203556] psci: CPU3 killed.
[ 583.205644] tegra-pmc: PMC wake level = 0x178000000000
[ 583.205644] tegra-pmc: PMC wake enable = 0x48178000000001
[ 583.205644] Entered SC7
[ 583.205644] Exited SC7
[ 583.205644] tegra-pmc: PMC wake status = 0x10000000000
[ 583.205644] tegra-pmc: Resume caused by PMC WAKE40, xhci-hcd:usb1
[ 583.205644] Suspended for 0.668 seconds
[ 583.205763] lt9611 lt9611_irq_Task dp-to-HDMI 0
[ 583.205775] lt9611 Failed to send i2c command, ret=-16
[ 583.211014] lt9611 Failed to select SYSTEM_CTRL0_BLOCK, ret=-16
[ 583.216939] lt9611 lt9611_irq_Task dp-to-HDMI 1
[ 583.216943] lt9611 Failed to send i2c command, ret=-16
[ 583.222091] lt9611 Failed to select SYSTEM_CTRL0_BLOCK, ret=-16
[ 583.228691] Enabling non-boot CPUs …
[ 583.229055] CPU1: Booted secondary processor [411fd071]
[ 583.229537] cache: parent cpu1 should not be sleeping
[ 583.235004] CPU1 is up
[ 583.235302] CPU2: Booted secondary processor [411fd071]
[ 583.235574] cache: parent cpu2 should not be sleeping
[ 583.240935] CPU2 is up
[ 583.241174] CPU3: Booted secondary processor [411fd071]
[ 583.241456] cache: parent cpu3 should not be sleeping
[ 583.246906] CPU3 is up
[ 583.248771] tegra-xusb 70090000.xusb: exiting ELPG
suspend-log.txt (118.7 KB)

Could you try to elaborate more about your board and more detail about your issue?

It is really hard to check your issue by just these information. For example, is this custom board or devkit?

Are you able to reproduce issue on devkit or not? I guess not, but you need to tell us. But not just keep let us guessing.
If this only happens to your board, then please review it with hardware design guide.

可以麻煩你多說明一下你的問題嗎? 這是devkit還是你自己的底板? 我猜是你自己的底板,但我想這種基本訊息還是請您發文的時候自己先說明一下.

如果只有你自己的底板會打到問題的話還請您去看一下design guide並檢視一下硬體設計有沒有問題.

I want to add that HDMI and DisplayPort use i2c for plug-n-play information, and that circuitry is powered by the video card, and not powered by the monitor itself. I see i2c popping up in logs, so can you verify if this occurs with just one monitor, or if different models of monitors have the same issue? It’d verify that this is or is not tied to a single monitor (or model of monitor) based on the i2c circuitry.

我们想知道什么情况下会导致 suspend entry,然后又退出了suspend.我们是自己设计的板子,当然是按照参考设计设计的,这个现象并非是必现的,偶然出现的,操作上 只是插拔HDMI线测试,如果知道哪些因素导致的,我们可以逐一排查下。

Can you repro this on devkit? If not, please check your design and compare to that of devkit (P3449 board), especially on the hotplug pin.

Hi, Your demo board can’t meet all the customer’s needs, * I don’t think everything has to be replicated in the demo board.
Please advise under what circumstances suspend is triggered ?
And the problem is low probability, we need to analyze and solve specific problems.

The logic is if you can’t repro on devkit, you should first check your HDMI design comparing that of devkit (P3449) to find out possible difference which might be the root cause. Have you done this?

Hi, our HDMI design is different from you, we add bridge make one hdmi to two hdmi port.
And the problem is low probability, we don’t know wether it id hardware related, and don’t know if it was accidental. We just had the dmesg log to find out what.

Then you should check the pin status when you plug in/unplug cable, especially check the HPD pin, also you should check the switch pin status to make sure the pins status on nano side are not affected by your such action. Please ask your hardware engineer to do more tests and try all method to find out root cause.

I want to add that one of the things the HPD triggers is a query of the monitor over the DDC wire. That is the i2c error you see. If you put a protocol analyzer on that, and can determine if the i2c never went out (which is probably the case), then the fix is different than if the query went out but failed to return. I am specifically thinking about this dmesg log line:

…did it fail due to lack of HPD? If not, did it fail due to bad i2c query? If not, did it fail due to returned i2c response?

1 Like

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.