01:03 <freekurt[m]> All devs are cool, I agree. Thanks for the explanation.

03:31 <oem_> Argentum is looking for experienced IRC operators to moderate our #politics channel on Snoonet. please /join #help on irc.snoonet.org for further details.

03:39 <oem_> Argentum is looking for experienced IRC operators to moderate our #politics channel on Snoonet. please /join #help on irc.snoonet.org for further details.

04:23 <HdkR> `CPU: All CPU(s) started at EL1` Right, I forgot to check this on X1E. Still no change on that front

05:49 <travmurav[m]> robclark: oled <- Nice! That would indeed simplify things if we can have two dtb for it (though I guess a bit sad for duplication but whatever, storage is not precious on those funny 2TB nvme laptops)

05:49 <travmurav[m]> HdkR: slbounce should presumably work on x1e though :^)

05:49 <travmurav[m]> but yeah, without remoteprocs for now

05:57 <travmurav[m]> robclark: while the iron is hot, do you have chids for both t14s (or who has them?) to make sure we document correct hwids for both variants? I only have the 21N1 right now

05:57 <travmurav[m]> https://github.com/TravMurav/dtbloader/blob/main/scripts/hwids/x1e78100-lenovo-thinkpad-t14s.txt

05:57 <steev> HdkR: has both, i think?

05:59 <HdkR> I only have the 64GB plus OLED model, but I also don't have Linux booting on it for obvious reasons

06:02 <travmurav[m]> ughhh

06:03 <travmurav[m]> so I quickly looked at psref thing

06:05 <travmurav[m]> and the "ProductName: 21N10001US" is a string unique to the configuration, so there are hundreeds of them (each keyboard * each screen * etc) so using that to match oled vs ips is possible but ugh... would need to add every device sku then and it would be a mess

06:05 <travmurav[m]> there is "ProductSku: LENOVO_MT_21N1_BU_Think_FM_ThinkPad T14s Gen 6" which is maybe more stable and "MT", "BU" encode something about the display but idk what those mean

06:06 <travmurav[m]> robclark: so somehow I doubt it's easy to just use chids for that again...

06:06 <travmurav[m]> so using dynamic detection might still be worth it to make it a bit more reliable

06:10 <travmurav[m]> since otherwise psref is like

06:10 <travmurav[m]> Total loaded rows: 150/994

06:20 <travmurav[m]> but hm

06:20 <travmurav[m]> I think I have a (dumb but) workable idea how dtbloader could help anyway, that would be reliable enough and doesn't require surveying each physical device

06:20 <travmurav[m]> should probably draft it up later, sounds like fun

06:33 <steev> polaris dawn launch in ~1h

06:35 <robclark> travmurav[m]: HdkR uploaded dmidecode to aarch64-laptops/build

06:40 <travmurav[m]> robclark: yeah so I guess it's just 1-out-of-1000 "product name" sku number

06:43 <travmurav[m]> ugh

06:43 <travmurav[m]> can't find that sku code on psref

06:44 <travmurav[m]> great here goes the funny plan

06:50 <travmurav[m]> I was going to use the psref excel export feature to add all possible oled skus to the special list and detect form that but if there is no complete list... -_-

07:09 <juergh> steev, oh, the venus fw is mandatory? hm. maybe that's why I have boot issues (sometimes).

07:52 <hogliux> anonymix007[m]: You were right: it had nothing to do with jhovold's kernel or your kernel. I was using 6.11 rc1 kernel with jhovold's branch and yours is on rc6. With rc1 (same firmware) the device doesn't lock up after two minutes when booting into busbox and only loading the keyboard modules. With rc6 it does. Anybody know what exactly causes the screen to go blank in rc6 if you don't load all the necessary modules.

08:01 <hogliux> robclark: There is something very strange with the internal keyboard on the slim 7x and grub. For me, internal keyboard and grub just suddenly started to work on my Slim 7x. Others seemed to have had the same experience (see comment by kuruczgy here, for example: https://gist.github.com/joske/52be3f1e5d0239706cd5a4252606644b?permalink_comment_id=5162458#gistcomment-5162458). I 100% did not update the firmware (or even boot into windows) bet

08:01 <hogliux> ween the keyboard working and not working. The only thing that may have "unlocked" the keyboard for me is to boot into an efishell. Maybe you need to boot once into efishell to unlock the keyboard somehow.

08:03 <hogliux> robclark: Also, there are firmware updates available. I by mistake fat-finger nuked my SSD during linux installation and needed to download Lenovo's Windows recovery medium: https://pcsupport.lenovo.com/de/en/solutions/ht103653

08:04 <hogliux> robclark: It's a huge pain! You need to have an account with lenovo and then download a windows only download tool to download the recovery medium. Then I needed 3 attempts for the recovery to actually work. But it did. And I ended up with a different firmware version (can't actually tell if it's newer because I forgot what the firmware version was before - I just new it was different).

08:05 <hogliux> robclark: s/new/knew

09:27 <jhovold> konradybcio: tested usb-c dp altmode on the crd, does not work at all here

09:27 <jhovold> [drm:dp_ctrl_link_train [msm]] *ERROR* DP link status read failed, err: -5

09:27 <jhovold> abelvesa: ^

09:28 <jhovold> same cable and monitor works fine with the x13s

09:32 <konradybcio> jhovold which crd? 8280?

10:49 <jhovold> konradybcio: x1e, as we discussed yesterday

10:52 <jhovold> only tested one of the ports, but dp support is broken in any case

13:50 <robclark> hogliux: a shell.efi build I had laying around (maybe >1yr old) had same no-keyboard issues, fwiw.. and the recovery image.. well I don't want to wipe out my linux install, and the whole needing a windows machine to create the recovery image is a bit of a chicken/egg problem. But maybe it is possible to extract the bios update from the recovery image?

13:52 <robclark> idk if the recovery image contains some of the files mentioned at https://gitlab.com/TheOneWithTheBraid/x13s-firmware-update

13:56 <hogliux> The recovery image is not very straight forward. I think it reboots probably something like 20 times and runs a crazy number of .bat scripts to install stuff. It almost looks like your computer is being remote controlled during the process. It all goes so fast though. I'd have no idea which part of the install actually updates the firmware.

13:58 <hogliux> robclark: which grub are you using? I'm using the grub from linaro's debian image: https://git.codelinaro.org/linaro/qcomlt/demos/debian-12-installer-image.

14:13 <robclark> hogliux: using grub from f41

14:13 <robclark> I guess I could try the linaro one somehow

15:15 <abelvesa> jhovold: is it type-c to DP cable ?

15:16 <JensGlathe[m]> Hmm rc7 not booting on X13s

15:16 <JensGlathe[m]> rc6 doesn't come back from suspend (screen stays blank)

15:18 <JensGlathe[m]> rc5 works, but boot may land in you in not mountabe rootfs - (initramfs prompt)

15:18 <JensGlathe[m]> sounds like some accumulation of quirks

15:18 <JensGlathe[m]> oh all on the same rootfs, same mesa

15:19 <konradybcio> wanna take up the sword and bisect?

15:29 <JensGlathe[m]> Not saying I want to, but I guess I'll take a shot at it

15:54 <jhovold> abelvesa: yes, usb-c to dp cable, just 1080p

15:56 <jhovold> JensGlathe[m]: rc5, rc6, and rc7 work fine here on the x13s

15:56 <abelvesa> jhovold: what I've noticed is that, after some link training failures (4 or 5), if I power off the external monitor and then power on again, it has output

15:57 <abelvesa> jhovold: can you try that?

15:57 <jhovold> are you running my wip branches or mainline, or have you added further stuff on top?

15:57 <jhovold> abelvesa: I remeber you mentioning that so I tried that as well, but makes no difference

15:57 <abelvesa> jhovold: crd, right ?

15:57 <jhovold> correct

15:58 <jhovold> third port (on the right)

15:59 <abelvesa> jhovold: will try your tree on my crd and let you know

15:59 <jhovold> when you say 4-5 link training failures, do you mean that you have to replug the cable 4-5 times?

15:59 <jhovold> or power cycle the monitor 4-5 times?

16:00 <jhovold> (that's effectively mostly the same thing)

16:00 <abelvesa> jhovold: nope, I do get 4-5 link training failures after plug-in and then I need to power off and on the monitor

16:00 <jhovold> ok, I never get that far, just fails hard once

16:39 <anonymix007[m]> BTW, it's the same for me on T14s as well: it just fails once and that's it.

16:41 <JensGlathe[m]> jhovold: basically your branch (x1e) with additions for Volterra. rc7 runs fine on Volterra, the other effects are on x13s only. My config is basically ubuntu default config, checked against yours and defconfig, reduced to qualcomm platform only. Since modules, firmware hooks and the used rootfs are the same with all kernels, its at least worth a bisect IMO.

16:53 <JensGlathe[m]> And yes I haven't seen the other described effects on the HP X14 either, booted there with rc5 and rc6. Need to try a boot with rc7 though. Since there is almost no firmware loaded yet... maybe that's a datum. No idea re screen not coming back there, but it just works. And I had it on battery for several hours with default screensaver settings.

17:57 <hogliux> Yeah! Suspend to disk aka hibernation (almost) works on the slim 7x with jhovold's rc7 kernel. GPU, WiFi, Keyboard, Trackpad restores nicely again. Unfortunately, everything depending on remoteproc (battmgr, bluetooth etc.) does not survive restore. I've tried unloading qcom_glink and qcom_q6v5_pas before hibernation but reloading them after hibernation gives me this:https://paste.pics/76672cd740f07d8842a966c89d7db49c

17:57 <hogliux> abelvesa: Do you have any suggestions on what I could try?

17:58 <hogliux> Now with clickable link: https://paste.pics/76672cd740f07d8842a966c89d7db49c

18:01 <steev> assuming you're using the userland pd-mapper, does restarting the server help?

18:01 <steev> service*

18:01 <hogliux> Yeah I good try restarting the service

18:01 <hogliux> I also see that the kernel disables IRQ 138 because no one is using it

18:02 <hogliux> Maybe remoteproc needs that IRQ and I'm not reloading the remoteproc modules fast enough before the kernel disables that

18:02 <hogliux> s/good/could

18:04 <hogliux> Nope restarting userspace pd-mapper does not help

18:10 <hogliux> Hmmm still getting: remoteproc remoteproc0: can't start rproc 30000000.remoteproc: -110

19:34 <stefan-schmidt> bamse: I understand you are having a Dell XPS X1E laptop? Is there any wip branch from you for the basics? I just ordered mine today. :-)

20:19 <steev> juergh: https://www.irccloud.com/pastebin/hiE9XT3R/

21:56 <oem> We are looking for an experienced IRC operator to moderate our #politics channel on Snoonet. please see argentum in the channel #help on irc.snoonet.org for further details

21:58 <oem> We are looking for an experienced IRC operator to moderate our #politics channel on Snoonet. please inquire in #help on irc.snoonet.org for further details

22:06 <bamse> stefan-schmidt: i have a base dtb, one hack, and one manual workaround...need to find the time to resolve the latter two so that i can post it on lkml