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.
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.
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?