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?

[catmengi]

Which part of the kernel control this "clocks"?

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

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?

DSI is a protocol that usually uses four data lines and one clock line to transfer dsi commands and video data to display controller(nt36523), we have dual dsi configuration that uses two DSI controllers for one display, in this configuration DSI0 usually used to draw left half of display and DSI1 right half.
It would be easier to use 6.1 kernel code, because everything works fine there, but I already tested all changes in drivers/clk/qcom and drivers/gpu/drm/msm/dsi/phy folder, and im pretty sure that clocks driver and dsi driver is fine in 6.2-6.7, devlink changes in 6.2 probably causes drivers to start in different order and that somehow affects stability of sm8150 clocks.

Which part of the kernel control this "clocks"?

Display clocks specified in https://github.com/map220v/sm8150-mainline/blob/nabu-6.7/drivers/clk/qcom/dispcc-sm8250.c
UFS and other core clocks in https://github.com/map220v/sm8150-mainline/blob/nabu-6.7/drivers/clk/qcom/gcc-sm8150.c
This is where "clock status stuck" happens

sm8150-mainline/drivers/clk/qcom/clk-branch.c

Line 86 in 9894da1

WARN(1, "%s status stuck at 'o%s'", name,

And dsi phy 7nm which has dsi phy suspend(dsi_7nm_phy_disable)/resume(dsi_7nm_phy_enable) code, it requests clock driver to enable/disable or change frequency of clocks https://github.com/map220v/sm8150-mainline/blob/nabu-6.7/drivers/gpu/drm/msm/dsi/phy/dsi_phy_7nm.c

[catmengi]

May it just because it have not enough time? Eg ~200 cpu cycles might be not enough?(Clk-branch.c ± 80 line)

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

DSI is a protocol that usually uses four data lines and one clock line to transfer dsi commands and video data to display controller(nt36523), we have dual dsi configuration that uses two DSI controllers for one display, in this configuration DSI0 usually used to draw left half of display and DSI1 right half. It would be easier to use 6.1 kernel code, because everything works fine there, but I already tested all changes in drivers/clk/qcom and drivers/gpu/drm/msm/dsi/phy folder, and im pretty sure that clocks driver and dsi driver is fine in 6.2-6.7, devlink changes in 6.2 probably causes drivers to start in different order and that somehow affects stability of sm8150 clocks.

Which part of the kernel control this "clocks"?

Display clocks specified in https://github.com/map220v/sm8150-mainline/blob/nabu-6.7/drivers/clk/qcom/dispcc-sm8250.c UFS and other core clocks in https://github.com/map220v/sm8150-mainline/blob/nabu-6.7/drivers/clk/qcom/gcc-sm8150.c This is where "clock status stuck" happens

sm8150-mainline/drivers/clk/qcom/clk-branch.c

Line 86 in 9894da1

WARN(1, "%s status stuck at 'o%s'", name,

And dsi phy 7nm which has dsi phy suspend(dsi_7nm_phy_disable)/resume(dsi_7nm_phy_enable) code, it requests clock driver to enable/disable or change frequency of clocks https://github.com/map220v/sm8150-mainline/blob/nabu-6.7/drivers/gpu/drm/msm/dsi/phy/dsi_phy_7nm.c

Ok, first what i check will be reverting devlink changes, because they changed too much, and they might be a problem for sm8150

[catmengi]

If in 6.1 and previos kernels dsi a ufs clocks fine and dsi and clk drivers in newer kernels fine, is this mean high chance of that the fw_devlink "optimization" broke something on this platform?

[catmengi]

Does nabu6.0-rc1 already have broken dsi suspend? Or it broked in other branch?

[map220v]

Does nabu6.0-rc1 already have broken dsi suspend? Or it broked in other branch?

DSI and UFS clocks became unstable in 6.2
5.19-6.1 have dsi suspend/resume working, but with some patches/hacks(nabu-5.19 and nabu-6.0-rc1 already has needed patches)

[map220v]

Does nabu6.0-rc1 already have broken dsi suspend? Or it broked in other branch?

DSI and UFS clocks became unstable in 6.2 5.19-6.1 have dsi suspend/resume working, but with some patches/hacks(nabu-5.19 and nabu-6.0-rc1 already has needed patches)

Ok, i can mark 6.4 as start of unstable dsi, i will try to read commits related to fw_devlink. Can you tell me more about patches and hacks for nabu-5.19-6.0?

In 5.19 I used this hack to make dsi0, dsi1 and dispcc probe with new devlink.
In 6.0-rc1 I used patches made by Saravana Kannan to fix devlink issues.

[catmengi]

Any ideas what drivers and commits broke clocks for dsi and ufs? Why this patches not working in version 6.2+?

[map220v]

Any ideas what drivers and commits broke clocks for dsi and ufs? Why this patches not working in version 6.2+?

I didn't checked fw_devlink commits, but I know that changes in dsi and clk folders are fine, and reverting them doesn't fix clock issue.

These patches won't apply to new kernels because of devlink changes, and some of these patches might be already applied to new kernels or they got replaced by other patch.

[catmengi]

Any ideas what drivers and commits broke clocks for dsi and ufs? Why this patches not working in version 6.2+?

I didn't checked fw_devlink commits, but I know that changes in dsi and clk folders are fine, and reverting them doesn't fix clock issue.

These patches won't apply to new kernels because of devlink changes, and some of these patches might be already applied to new kernels or they got replaced by other patch.

Is reverting all devlink changes after 6.1 and keep Saravana Kannan's pathes and your's might be a way?

[catmengi]

Does nabu6.0-rc1 already have broken dsi suspend? Or it broked in other branch?

DSI and UFS clocks became unstable in 6.2 5.19-6.1 have dsi suspend/resume working, but with some patches/hacks(nabu-5.19 and nabu-6.0-rc1 already has needed patches)

Ok, i can mark 6.4 as start of unstable dsi, i will try to read commits related to fw_devlink. Can you tell me more about patches and hacks for nabu-5.19-6.0?

In 5.19 I used this hack to make dsi0, dsi1 and dispcc probe with new devlink. In 6.0-rc1 I used patches made by Saravana Kannan to fix devlink issues.

Did you mean this and next commits related to fw_devlink fix the issue with dsi clocks on 6.0-rc1 --- 6 1?

[map220v]

Does nabu6.0-rc1 already have broken dsi suspend? Or it broked in other branch?

DSI and UFS clocks became unstable in 6.2 5.19-6.1 have dsi suspend/resume working, but with some patches/hacks(nabu-5.19 and nabu-6.0-rc1 already has needed patches)

Ok, i can mark 6.4 as start of unstable dsi, i will try to read commits related to fw_devlink. Can you tell me more about patches and hacks for nabu-5.19-6.0?

In 5.19 I used this hack to make dsi0, dsi1 and dispcc probe with new devlink. In 6.0-rc1 I used patches made by Saravana Kannan to fix devlink issues.

Did you mean this and next commits related to fw_devlink fix the issue with dsi clocks on 6.0-rc1 --- 6 1?

I think these commits were used to fix dsi probing fail, which was caused by devlink that could not properly resolve cycle depenedecy between dispcc, dsi0 and dsi1.

In new kernels (6.2 and higher) probing issue releated to devlink was fixed but some devlink improvements somehow broke clocks on sm8150 with dual dsi configuration.
On other devices with sm8150 and without dual dsi, clocks work fine, and it's seems that on sm8250 with dual dsi, ufs and dsi clocks also getting enabled/disabled without being stuck.

[catmengi]

Does nabu6.0-rc1 already have broken dsi suspend? Or it broked in other branch?

DSI and UFS clocks became unstable in 6.2 5.19-6.1 have dsi suspend/resume working, but with some patches/hacks(nabu-5.19 and nabu-6.0-rc1 already has needed patches)

Ok, i can mark 6.4 as start of unstable dsi, i will try to read commits related to fw_devlink. Can you tell me more about patches and hacks for nabu-5.19-6.0?

In 5.19 I used this hack to make dsi0, dsi1 and dispcc probe with new devlink. In 6.0-rc1 I used patches made by Saravana Kannan to fix devlink issues.

Did you mean this and next commits related to fw_devlink fix the issue with dsi clocks on 6.0-rc1 --- 6 1?

I think these commits were used to fix dsi probing fail, which was caused by devlink that could not properly resolve cycle depenedecy between dispcc, dsi0 and dsi1.

In new kernels (6.2 and higher) probing issue releated to devlink was fixed but some devlink improvements somehow broke clocks on sm8150 with dual dsi configuration. On other devices with sm8150 and without dual dsi, clocks work fine, and it's seems that on sm8250 with dual dsi, ufs and dsi clocks also getting enabled/disabled without being stuck.

I think i will go in simpler way, i will rollback drivers/base/{parts related to fw_devlink} to 6.1 then apply Saravana Kannan's patches

[catmengi]

I think it would be easier to backport changee from your kernel to maverickjb kernel than try to found what change in fw_devlink causing error, Or is it possible to only port things related to fw_devlink from 6.1 to 6.7+?
Edit: how can i connect with Gregh Kruah Hartman? He is mainter of driver base subsystem, he can possible fix this in upstream. Or he just ignore me

[catmengi]

The problem is that only usb keyboard isnt working, flash drives are working properly

[map220v]

The problem is that only usb keyboard isnt working, flash drives are working properly

If your kb requires usbhid or other kernel modules then try recompiling kernel with all these configs set to 'Y'
https://github.com/map220v/sm8150-mainline/blob/nabu-6.8/arch/arm64/configs/sm8150.config#L93-L100

[catmengi]

Hi im here to give this dead issue a litlle more live. Recently i found that 6.7 still cant boot of ufs, and i able to get logs of this. Currently i booting of usb drive. Say if you need more detailed logs ufs.log

Try applying this missing patch and see if it fixes UFS clock issue.

P.s also your ubuntu image can only boot into emergency mode for some unknown reason

Maybe you don't have esp partition and fstab fail makes it enter emergency mode?

Cant apply this patch, screen suspend isnt working properly, black screen, kernel not crash. Usb keyboard is working. GUI is very smooth.Because of broken ufs wifi and bt not working, they cant get data from modem partition

[catmengi]

Hi everyone who is still there. Found some patch that can help with our issue but it need some changes, i want to see your opinion (@map220v). This patch for another qcom cpu, but it easy to fix to out cpu, can you review it? https://lore.kernel.org/lkml/YrXo+i3wwl2ERKIj@xps13/t/

[catmengi]

Well, as I see code patches is useless, they even got into mainline kernel. But dtc patch may be useful

[catmengi]

https://lore.kernel.org/linux-arm-msm/20240417-drm-msm-initial-dualpipe-dsc-fixes-v1-3-78ae3ee9a697@somainline.org/T/ found something interesting

[catmengi]

Why do Xiaomi vayu(Poco x3 pro) have these clocks in framebuffer:
clocks = <&gcc GCC_DISP_HF_AXI_CLK>, <&gcc GCC_DISP_SF_AXI_CLK>;

But nabu don't?

[map220v]

Why do Xiaomi vayu(Poco x3 pro) have these clocks in framebuffer: clocks = <&gcc GCC_DISP_HF_AXI_CLK>, <&gcc GCC_DISP_SF_AXI_CLK>;

But nabu don't?

These clocks(also few others in dispcc) needed to keep "logo framebuffer" working for simplefb.
Before dpu initialized new framebuffer, simplefb is used early logs, until clock framework resets unused clocks.

[catmengi]

Can this help with display in 6.8: torvalds/linux@d543d1b

[catmengi]

Hello again, can I ask you about rebase guide for this kernel? I'm interested in testing new kernel version, they have some msm and dpu related display patches

[map220v]

Hello again, can I ask you about rebase guide for this kernel? I'm interested in testing new kernel version, they have some msm and dpu related display patches

Add remote called upstream that points to linux kernel repo and run:

git fetch upstream --tags
git checkout -b nabu-6.9 nabu-6.8
git rebase v6.9

Then if it gives errors at some commits, fix them, "git add" files and run "git rebase --continue" to continue rebasing commits.

[catmengi]

trying to compile almost pure mainline kernel, with your nabu screen patch and dtb, because that i cant compile dtb on 6.9 branch

[catmengi]

image make signs of live, now trying to boot test rootfs

[catmengi]

6.10 acts same as 6.8 :(

[catmengi]

Hello, @map220v can you explain what does this patch do: maverickjb/linux-6.1.10@f366d74 I see that in affect dpu but I have no knowledge about internal Linux structure and api

[catmengi]

Maybe try applying sm8150-mainline version of this patch to mainline?

[catmengi]

Well i have an idea, maybe panel driver just not starting up properly? When kernel have no root= provided old fbdev is stil working and print "press any key to shutdown" (mainline)

[catmengi]

A was able to make nabu-6.9 kernel with git merge(git rebase create compilation issues). Kernel make almost no signs of live: initial bootlog, usb power, no kernel modules are trying to load and flash drive with led make no "mount kind" of blinks, will try using it as usb-serial but when i tryed this with 6.8 i got this issues: text wasnt alignment, systemd wasnt launch getty on this console(cannot got into the system). Also question nt36523 driver, it had firmware(at least in android kernel) does it loading in current kernels?

[map220v]

will try using it as usb-serial

You can also try NCM with sshd service, im currently using it on my phone.
With CONFIG_USB_G_NCM you only need this in kernel cmdline "ip=192.168.100.1::192.168.100.2:255.255.255.0::usb0:on"
With CONFIG_USB_F_NCM you need to run script in userspace to setup gadgetfs and network, I use usbnet systemctl service for that.

On PC you probably need to set ip address for this network to 192.168.100.2 and gateway to 192.168.100.1
Internet sharing from other networks also works.

Also question nt36523 driver, it had firmware(at least in android kernel) does it loading in current kernels?

Kernel loads it from this path /lib/firmware/novatek/novatek_nt36523_fw.bin , this firmware is required for touch and pen input handling.

[catmengi]

Also forget to say, nt36xxx touchscreen driver not compiling, they broke something in header files again, i'll try usb net if kernel will make signs of live into usb-serial

[catmengi]

6.8 kernel spaming with this line
OF: graph: no port node found in /soc@0/spmi@c440000/pmic@2/typec@1500`
no further load

[catmengi]

Hello, i found interesting thing, this is a simple drm panel generator: https://github.com/msm8916-mainline/linux-mdss-dsi-panel-driver-generator/blob/master/ can this help with enabling panel in mainline?

[map220v]

Hello, i found interesting thing, this is a simple drm panel generator: https://github.com/msm8916-mainline/linux-mdss-dsi-panel-driver-generator/blob/master/ can this help with enabling panel in mainline?

It won't help because it doesn't support Dual DSI and problem on nabu is not panel driver(we already have proper driver for panel controller from elish), it's dsi or dpu issue, probably releated to Dual DSI changes in 6.8

[catmengi]

If adreno core can draw to framebuffer or we can passthrough drm drawing results into simplefb, can we try to launch it on simple framebuffer. Or try to revert dual-dsi changes

[catmengi]

Hello, i found interesting thing, this is a simple drm panel generator: https://github.com/msm8916-mainline/linux-mdss-dsi-panel-driver-generator/blob/master/ can this help with enabling panel in mainline?

It won't help because it doesn't support Dual DSI and problem on nabu is not panel driver(we already have proper driver for panel controller from elish), it's dsi or dpu issue, probably releated to Dual DSI changes in 6.8

As far as I know xiaomi nabu kernel use simpledrm(its defconfig)

[catmengi]

Also about newer kernels, tried mainline one and 6.8, no ufs, stuck in rootwait or kernel panic

[Blakyrin]

This is fixed on 6.12, so now we can say it works :DD

[catmengi]

This is fixed on 6.12, so now we can say it works :DD

Previously after 6.8 it even doesnt turn on at boot :D

[Blakyrin]

the ufs seems to still be failing in some devices, not sure yet, but you can try this to workaround it, deviceinfo_kernel_cmdline="pd_ignore_unused,clk_ignore_unused,console=ttyMSM0,115200,"