Does the drm suspend/wakeup works?

[catmengi]

Does the drm/dsi suspend works, can i suspend my screen and the wakeup it without any crash and fatal for UX bugs.
One important question, does hibernate to disk works? Eg, no crashes after resuming from image

[map220v]

Unfortunately it's broken on sm8150 with dual dsi since kernel 6.2, when dsi suspends or resumes it gives errors like: clock stuck in on/off state, on kernel 6.1 without this issue, there is no UX, OpenGL and Vulkan context crashes or bugs when suspending or resuming.

If linux hibernate doesn't require uefi varstore then it should work same way as on regular linux PC.

[catmengi]

Unfortunately it's broken on sm8150 with dual dsi since kernel 6.2, when dsi suspends or resumes it gives errors like: clock stuck in on/off state, on kernel 6.1 without this issue, there is no UX, OpenGL and Vulkan context crashes or bugs when suspending or resuming.

If linux hibernate doesn't require uefi varstore then it should work same way as on regular linux PC.

Does it mean kernel will panic on resume/suspend? I sawed commit for drm resume/suspend fix maverickjb/linux-6.1.10@7c92310 from maverickjb, only difference is gdsc.c, i updated it in my fork, but same as you i cant test it now :(

[map220v]

First dsi will give critical errors, then it will reboot because of unstable clock driver or dsi driver state.
I think gdsc.c issues were already fixed in older kernels, right now dsi issue seem to be releated to devlink and dsi cyclic dependencies.

[catmengi]

First dsi will give critical errors, then it will reboot because of unstable clock driver or dsi driver state. I think gdsc.c issues were already fixed in older kernels, right now dsi issue seem to be releated to devlink and dsi cyclic dependencies.

Well, if screen is suspended it will crash on resume, any ideas of fixing this? Did you have kernel log of crash? What parts of kernel/dts is related to dsi clocks, devlink and dsi cyclic dependencies? How can i debug my tablet's kernel via usb, without dissambling it and any external hardware?

Edit: torvalds/linux@9187ebb torvalds/linux@d09ec6f https://github.com/torvalds/linux/commits/master/drivers/gpu/drm/msm/dsi maybe this commits can be related to our problem? Or just try to downgrade dsi drivers?

[map220v]

First dsi will give critical errors, then it will reboot because of unstable clock driver or dsi driver state. I think gdsc.c issues were already fixed in older kernels, right now dsi issue seem to be releated to devlink and dsi cyclic dependencies.

Well, if screen is suspended it will crash on resume, any ideas of fixing this? Did you have kernel log of crash? What parts of kernel/dts is related to dsi clocks, devlink and dsi cyclic dependencies? How can i debug my tablet's kernel via usb, without dissambling it and any external hardware?

I don't have kernel logs from mainline, you can check this code it controls dsi clocks. For devlink and it's cyclic dependecies handling check latest nabu-6.0-rc1 commits.
Idk if linux has support for usb debugging, dwc3 driver on linux probably doesn't support that.

Edit: torvalds/linux@9187ebb torvalds/linux@d09ec6f https://github.com/torvalds/linux/commits/master/drivers/gpu/drm/msm/dsi maybe this commits can be related to our problem? Or just try to downgrade dsi drivers?

These commits doesn't seem to be releated to this issue. Downgrading dsi most likely won't help, because issue seem to be somewhere else, this error "clock stuck in on/off state" is also happens for UFS on boot, I fixed it temporarly by adding sleep functions in clock enable/disable, but it seems that ufs driver still has chance to crash at boot.

[catmengi]

Now only left two annoing parts, waiting for bootloader unlock and debugging. I wont close this issue until, i/you/we found a solution for this, if you can give me more info about this it may be very helpful

[catmengi]

How to get kernel crash log for debugging if screen is black(or it isnt?), does it save logs or dump files, if it does, where are they?

[map220v]

How to get kernel crash log for debugging if screen is black(or it isnt?), does it save logs or dump files, if it does, where are they?

I use ssh to get logs from dmesg, there is also ramoops(pstore) it saves kernel logs to ddr region at address 0xb0000000 that is persistent between reboots.

[catmengi]

How to get kernel crash log for debugging if screen is black(or it isnt?), does it save logs or dump files, if it does, where are they?

I use ssh to get logs from dmesg, there is also ramoops(pstore) it saves kernel logs to ddr region at address 0xb0000000 that is persistent between reboots.

But how to get thoose logs from there?

[map220v]

How to get kernel crash log for debugging if screen is black(or it isnt?), does it save logs or dump files, if it does, where are they?

I use ssh to get logs from dmesg, there is also ramoops(pstore) it saves kernel logs to ddr region at address 0xb0000000 that is persistent between reboots.

But how to get thoose logs from there?

Boot to android recovery and check /sys/fs/pstore/console-ramoops*
Also If there is no pstore compression enabled, you can read 0xb0001000-0xb0021000 from /dev/mem there should be tool for that.

[catmengi]

How to get kernel crash log for debugging if screen is black(or it isnt?), does it save logs or dump files, if it does, where are they?

I use ssh to get logs from dmesg, there is also ramoops(pstore) it saves kernel logs to ddr region at address 0xb0000000 that is persistent between reboots.

But how to get thoose logs from there?

Boot to android recovery and check /sys/fs/pstore/console-ramoops* Also If there is no pstore compression enabled, you can read 0xb0001000-0xb0021000 from /dev/mem there should be tool for that.

If i boot from linux to fastboot, then to orangefox recovery it wont be erased? If kernel panic isnt permanent (not everytime) can i just view logs from linux?

[map220v]

How to get kernel crash log for debugging if screen is black(or it isnt?), does it save logs or dump files, if it does, where are they?

I use ssh to get logs from dmesg, there is also ramoops(pstore) it saves kernel logs to ddr region at address 0xb0000000 that is persistent between reboots.

But how to get thoose logs from there?

Boot to android recovery and check /sys/fs/pstore/console-ramoops* Also If there is no pstore compression enabled, you can read 0xb0001000-0xb0021000 from /dev/mem there should be tool for that.

If i boot from linux to fastboot, then to orangefox recovery it wont be erased? If kernel panic isnt permanent (not everytime) can i just view logs from linux?

It won't be erased, but some kernel crashes can corrupt pstore header, and pstore in recovery won't show console-ramoops, so the only way to read such log would be /dev/mem
If after kernel panic you can still access ssh or any other console, then use dmesg command, it will print kernel logs.
Also for more logs from dsi use this "drm.debug=0x1ff" and "log_buf_len=8M" in kernel cmdline.

[catmengi]

Dsi_phy_7nm.c have big differences beetwen versions 6.1 to 6.7, maybe just some patch broke it for nabu🤔

[map220v]

Dsi_phy_7nm.c have big differences beetwen versions 6.1 to 6.7, maybe just some patch broke it for nabu🤔

elish with sm8250 also has Dual DSI, but dsi suspend and resume seem to work fine there, and they don't have clocks issues with UFS, so it's probably something wrong with clocks or clocks dependency handling on sm8150.
Without this hack UFS has around 30% chance to start without clock error, maybe same applies to dsi clocks, because suspend and resume worked for me 2 or 3 times in 6.6, or maybe it didn't fully suspended. Also disabling one of these nodes "dsi1, dsi0 or dispcc" also fixes ufs clocks issue.

[catmengi]

Dsi_phy_7nm.c have big differences beetwen versions 6.1 to 6.7, maybe just some patch broke it for nabu🤔

elish with sm8250 also has Dual DSI, but dsi suspend and resume seem to work fine there, and they don't have clocks issues with UFS, so it's probably something wrong with clocks or clocks dependency handling on sm8150. Without this hack UFS has around 30% chance to start without clock error, maybe same applies to dsi clocks, because suspend and resume worked for me 2 or 3 times in 6.6, or maybe it didn't fully suspended. Also disabling one of these nodes "dsi1, dsi0 or dispcc" also fixes ufs clocks issue.

May this be because patches with devlink "optimizing"? And what dsi1 and dsi0 does(where the screen lives)? And which part of kernel control thoose "clocks". Nabu android kernel dont have this issue, can we get code from there and rework?