10:29 <kwizart> digetx, about updating dtb (wrt thierry answer about nyan panel support), fedora default to provide an updated dtb matching the kernel and I think most distro are doing the same (with the exeption to opensuse that might still distribute updated dtb against older kernel)

12:18 <tagr> hexdump0815: I don't see much on the console on Venice 2 when suspending... it gives me these:

12:19 <tagr> [ 57.153778] Disabling non-boot CPUs ...

12:19 <tagr> [ 57.165120] Entering suspend state LP1

12:19 <tagr> and then it doesn't come up again if I press the power key

12:21 <tagr> oh interesting... I do see that it resumes when I use rtcwake, but after the resume it immediately shuts down

12:46 <tagr> hexdump0815: resume also only seems to work on v5.15, not on linux-next

17:59 <kwizart> I okay, seems like there are improvements with glmark-wayland on jetson-tk1 with nouveau is giving 115 on 5.15.10 whereas it gives 175 on tegra-next (rebased onto current master 5.16-rc6 to get the usb fix)

18:02 <kwizart> suspend works on tegra-for-next (rebased) with me : https://paste.centos.org/view/08c30bdf

18:03 <kwizart> altough the error related to the pcie MSI interrupt (ethernet)

18:13 <kwizart> unfortunately, tearning still occurs,only preventing nouveau to load

20:43 <kwizart> digetx, paz00 is failing to display on tegra-for-next rebased on current 5.16-rc6 (instead of rc1), it's well possible that I'm missing others tree:

20:43 <kwizart> https://paste.centos.org/view/ab8a2d2c

20:44 <kwizart> digetx, specially: [ 6.111866] tegra-gr3d 54180000.gr3d: cannot get reset

20:44 <kwizart> [ 6.175595] tegra-gr3d: probe of 54180000.gr3d failed with error -16

20:53 <hexdump0815> tagr: thanks for the suspend/resume testing - this sounds like what i see on the nyan here (i.e. no wakeup from suspend)

20:54 <kwizart> digetx, nevermind, merging tegra-drm solved the issue

20:55 <hexdump0815> kwizart: iirc suspend/resume was somehow working on tk1 - right? i think that part is different for the nyan as there i guess the chromebook ec plays a role in the low level suspend maybe?

21:00 <kwizart> hexdump0815, indeed, suspend working on jtk1 means maybe the issue is at the board level over the soc level, but still need to find out the rationale behind

21:21 <hexdump0815> btw. i have nouveau working with latest xorg and mesa-21.0.1, but it does not longer work with any mesa-21.1+ complaining about memory allocation issues - any idea?

21:22 <hexdump0815> kernel is 5.15.7 right now

21:27 <hexdump0815> just reied suspend-to-disk but it fails the same way on resume as regular suspend

21:27 <hexdump0815> tried

21:39 <hexdump0815> while looking through dmesg i found "panel-simple-dp-aux aux-545c0000.dpaux: Specify missing connector_type" and "tegra-sor 54540000.sor: missing output definition for heads in DT" - is any of those of any relevance?

22:32 <hexdump0815> tagr: i am getting the same result as you if i use rtcwake - it resumes and then immediately does a clean shutdown

22:33 <hexdump0815> i guess this is actually a good sign as this means that mem suspend and resume basically works and we only need to find out why it shuts down afterwards - right?

22:34 <hexdump0815> digetx: tagr: btw. while looking at this - should this: https://github.com/torvalds/linux/blob/master/arch/arm/boot/dts/tegra124-nyan.dtsi#L384 maybe be 1? it is for all the other tegra124 and as i understand it 0 would be the lowest mode, which would require an extra firmware to run on the soc

22:35 <hexdump0815> this more is afaik use in chromeos, but i think the infrastructure for this is not there in mainline

22:38 <hexdump0815> this is the lp0 code used for chromeos: https://github.com/hexdump0815/linux-chromeos-kernel/tree/main/misc.310/misc/coreboot/src/soc/nvidia/tegra124/lp0

23:29 <hexdump0815> ok - i think i understand the lp modes now: 2 = cpu power off, 1 = cpu+dram refesh, 0 = cpu+dram+cre voltage off ... continuing my experiments with suspend-mode 2 now - should be the easiest of them

23:29 <hexdump0815> if i boot with init=/bin/bash and do rtcware there i'm getting out of deep suspend fine without the shutdown afterwards

23:32 <hexdump0815> if i go into suspend from there via "echo mem > /sys/power/state" the systems enters suspend, but i have no chance to wake it up from there - maybe there is some wakeup source missing or not working well?

23:35 <hexdump0815> enough sleep experiments for today - time to go to sleep :)

23:38 <hexdump0815> last note: in theory it should be possible to get lp1 mode working as someone already had it working before: https://archlinuxarm.org/forum/viewtopic.php?f=49&t=12185&start=230#p64180 - the display hack from there seems to be no longer required meanwhile