ChanServ changed the topic of #aarch64-laptops to: Linux support for AArch64 Laptops (Chrome OS Trogdor Devices - Asus NovaGo TP370QL - HP Envy x2 - Lenovo Mixx 630 - Lenovo Yoga C630 - Lenovo ThinkPad X13s - and various other snapdragon laptops) - https://oftc.irclog.whitequark.org/aarch64-laptops
shoragan has quit []
shoragan has joined #aarch64-laptops
chrisl has joined #aarch64-laptops
chrisl has quit [Ping timeout: 480 seconds]
davidinux has quit [Ping timeout: 480 seconds]
<dgilmore> 5G has always worked well on the x13s for me
chrisl has joined #aarch64-laptops
chrisl has quit [Ping timeout: 480 seconds]
chrisl has joined #aarch64-laptops
chrisl has quit [Ping timeout: 480 seconds]
chrisl has joined #aarch64-laptops
chrisl has quit [Ping timeout: 480 seconds]
tobhe has joined #aarch64-laptops
pabs has quit [Ping timeout: 480 seconds]
hexdump01 has joined #aarch64-laptops
tobhe_ has quit [Ping timeout: 480 seconds]
chrisl has joined #aarch64-laptops
chrisl has quit [Ping timeout: 480 seconds]
mbuhl has quit [Remote host closed the connection]
mbuhl has joined #aarch64-laptops
chrisl has joined #aarch64-laptops
chrisl has quit [Ping timeout: 480 seconds]
pabs has joined #aarch64-laptops
chrisl has joined #aarch64-laptops
chrisl has quit [Ping timeout: 480 seconds]
ungeskriptet has quit [Remote host closed the connection]
ungeskriptet has joined #aarch64-laptops
ungeskriptet has quit [Remote host closed the connection]
ungeskriptet has joined #aarch64-laptops
ungeskriptet has quit [Remote host closed the connection]
ungeskriptet has joined #aarch64-laptops
chrisl has joined #aarch64-laptops
chrisl has quit [Ping timeout: 480 seconds]
<JensGlathe[m]> valpackett: Sleep with closed lid on my HP X14 leads to reboot... https://pastebin.com/qrWiBX8n No real idea why, but sort of consistently. No SD card reader on this one
chrisl has joined #aarch64-laptops
Kelsar_ has joined #aarch64-laptops
chrisl has quit [Ping timeout: 480 seconds]
Kelsar has quit [Ping timeout: 480 seconds]
<valpackett> hm. actually was just retesting now and sd card reader doesn't break deep sleep anymore 0.o
<valpackett> the only issue with deep is nvme drops out :/
<valpackett> anywaaaaaaaaaaaaay
<alexVinarskis[m]> does SPI11 actually has TPM2/is TZ protected? just curious, some of these like Asus Zenbook have fTPM, but still left that SPI behind TZ
<JensGlathe[m]> It is said to be, GPIO44
<travmurav[m]> afaiu x1 and further can have fTPM (tz trustlet), sTPM (tz + dedicated mcu inside the soc afaiu, I guess this is for pluton stuff) and fTPM (dedicated chip on tz managed spi)
<travmurav[m]> in all cases you go via tz but in first two I guess would also need to provide tz with a storage backend for the sealing stuff to work
<travmurav[m]> (prior x1 there was no sTPM)
<travmurav[m]> uh last one not fTPM but hTPM iirc
<travmurav[m]> that is, those were internal names
<travmurav[m]> so I think regardless if it's f/s/hTPM, you still go via tz, though there is also some way to pick which to use, I think x13s exposed the knob in efi settings
<travmurav[m]> it was "dTPM"
<travmurav[m]> for hardware
<travmurav[m]> not like it matters I guess
<janrinze> 6.15-rc7 form jhovold works on my X13s. I do notice a tiny bit of regression in speed of the nvme from 2800 to 2000 MB/s
whiskey9 has joined #aarch64-laptops
whiskey9 has quit []
whiskey9 has joined #aarch64-laptops
whiskey9 has quit []
whiskey9 has joined #aarch64-laptops
chrisl has joined #aarch64-laptops
chrisl has quit [Ping timeout: 480 seconds]
erebion_[m] has joined #aarch64-laptops
pbrobinson has quit [Ping timeout: 480 seconds]
erebion_[m] has left #aarch64-laptops [User left]
ungeskriptet has quit [Remote host closed the connection]
ungeskriptet has joined #aarch64-laptops
ungeskriptet has quit [Remote host closed the connection]
ungeskriptet has joined #aarch64-laptops
pbrobinson has joined #aarch64-laptops
chrisl has joined #aarch64-laptops
chrisl has quit [Ping timeout: 480 seconds]
chrisl has joined #aarch64-laptops
chrisl has quit [Ping timeout: 480 seconds]
<jdb[m]> valpackett: how did you find the correct info for the panel: "enable-gpios = <&tlmm 74 GPIO_ACTIVE_HIGH>;" ?
<jdb[m]> 74 in dec is 4A in hex, but I can't find any obvious mentions of 4A in the DSDT section
<jdb[m]> should I be looking somewhere else?
chrisl has joined #aarch64-laptops
chrisl has quit [Ping timeout: 480 seconds]
<jdb[m]> I'm trying to understand how it works / how to guess based on the DT from other models, still for the Surface Pro 9 5G
ungeskriptet has quit [Remote host closed the connection]
ungeskriptet has joined #aarch64-laptops
ungeskriptet has quit [Remote host closed the connection]
ungeskriptet has joined #aarch64-laptops
chrisl has joined #aarch64-laptops
chrisl has quit [Ping timeout: 480 seconds]
<valpackett> jdb[m]: copy paste xD
<jdb[m]> from another devicetree I imagine?
<valpackett> yep, it's been the same on all dells
<valpackett> from xps to inspiron to latitude
<alexVinarskis[m]> you can find it in AeoB dumps.
<valpackett> wow, how did i not even hear about aeob before
<valpackett> we're really missing a central doc with links to All The Things related to qcom based devices
<jdb[m]> indeed, good point alexVinarskis ! I wish it would be documented how to read the nesting of such files, there are a few other TLMMGPIO in this file for instance (0x46, 0x77) and I don't know what to make of those.
<jdb[m]> In the file you've helped me create for the Surface Pro 9 5G:
<jdb[m]> I wonder what the second TLMM GPIO 3 means
<kcxt> omg cpucp support is in -next now and my battery life is immediately doubled?!
<kcxt> this is AWESOME
<jdb[m]> I am also investigating how to reverse engineer the panel driver from Windows to see if it could contain some powering sequences for the LGD06B2 panel specifically
<Jasper[m]> @kcxt on what platform?
<Jasper[m]> Also what are those aeob dumps for? Panel related stuff?
<alexVinarskis[m]> jdb: gpio3 is input gpio, there was a screenshot somewhere above which indicated which line means its Input which on its output. Its likely HPD pin.
<kcxt> Jasper[m]: X1E, yoga slim 7x
<alexVinarskis[m]> jasper: cameras, displays, bunch of stuff. its like ACPI extension in Windows driver. so all the stuff that shouldve been in dsdt in ideal world, but it isn't.
<Jasper[m]> ohhh interesting
<Jasper[m]> I had missed that
<kcxt> anyone know about ath12k being broken on next? i get a weird QMI allocation failure and now i just got a null ptr while trying to rmmod ath12k... https://p.calebs.dev/61d60a@raw
<valpackett> ugh stupid windows, wanted to boot it via usb to dump the aeob stuff but it just doesn't support usb boot lol
<valpackett> kcxt: "qmi dma allocation failed (7012352 B type 1), will try later with small size" that kind of warning? that seems harmless
<alexVinarskis[m]> valpackett: if u have windows partitions still you can just find all the bins from linux. also some OEMs like Dell have drivers available publically, can download and extract. Just don't send .bin around as its technically non-redistributable.
<valpackett> alexVinarskis[m]: but the tool that extracts them is written for windows xD maybe linux dotnet could run it tho
<alexVinarskis[m]> oh right, forgot already :D. You can send them to me in private, i have one device with windows.
<jdb[m]> good point alexVinarskis , I didn't remember that one. I will try to create a hpd-gpios line
<valpackett> kcxt: on next-20250516 ath12k would panic a lot for me "very soon" after booting / logging in, but next-20250523 fixed that
<jdb[m]> and I would be curious to know how that screenshot was created, whether it makes references to an existing spec or something
<jdb[m]> otherwise it feels like magic :-)
chrisl has joined #aarch64-laptops
<kcxt> valpackett: hmm ok, i think for me the wifi adapter is going to crashdump mode or something
<jdb[m]> alexVinarskis: I will use this patch series as an example
<jdb[m]> even if there are still a few comments in the email exchange and I'll need to adapt it to the sc8280xp SoC
chrisl has quit [Ping timeout: 480 seconds]
<valpackett> ha, the aeob tool runs perfectly on linux dotnet
<valpackett> oh right if it's just "not working" you have that firmware
akaWolf has joined #aarch64-laptops
chrisl has joined #aarch64-laptops
chrisl has quit [Ping timeout: 480 seconds]
chrisl has joined #aarch64-laptops
chrisl has quit [Ping timeout: 480 seconds]
<Grabunhold_> robclark Jasper[m] i am running a kernel with the " drm/panel-edp: Add BOE NV133WUM-N61 panel entry" patch applied. the kernel warning is gone, and I haven't noticed any other effects so far. is there anything I should test?
sinan has joined #aarch64-laptops
<Grabunhold_> suspend is working, display brightness control is working
sinan is now known as nativeofcyberspace
nativeofcyberspace has quit [Quit: nativeofcyberspace]
sinan has joined #aarch64-laptops
sinan is now known as nativeofcyberspace
<robclark> Grabunhold_, dianders: thx
<Grabunhold_> robclark: no no, thank _you_! :)
chrisl has joined #aarch64-laptops
chrisl has quit [Ping timeout: 480 seconds]
nativeofcyberspace has quit [Quit: nativeofcyberspace]
nativeofcyberspace has joined #aarch64-laptops
chrisl has joined #aarch64-laptops
nativeofcyberspace has quit [Quit: nativeofcyberspace]
nativeofcyberspace has joined #aarch64-laptops
chrisl has quit [Ping timeout: 480 seconds]
nativeofcyberspace has quit [Quit: nativeofcyberspace]
<steev> Grabunhold_: the testing is more helpful than you think :)
chrisl has joined #aarch64-laptops
chrisl has quit [Ping timeout: 480 seconds]