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
chrisl has quit [Ping timeout: 480 seconds]
pbrobinson has quit [Ping timeout: 480 seconds]
chrisl has joined #aarch64-laptops
pbrobinson has joined #aarch64-laptops
chrisl has quit [Ping timeout: 480 seconds]
phire_ has joined #aarch64-laptops
phire is now known as Guest16443
phire_ is now known as phire
Guest16443 has quit [Ping timeout: 480 seconds]
davidinux has quit [Ping timeout: 480 seconds]
<valpackett>
hm, one difference vs. the xps i have in dsdt is with the i2c pins that are qup_i2c8_data_clk in linux, the last field in the tlmmgpio
<valpackett>
did not help: `&qup_i2c8_data_clk { /delete-property/ bias-pull-up; bias-disable; };`
nirik has joined #aarch64-laptops
<nirik>
FWIW, my ath12k problem was of course of my own making. I had copied firmware in long ago before it was in linux-firmware. I assumed the linux-firmware one would overwrite any one I had, but turns out I had uncompressed versions and fedora linux-firmware xz compresses everything and it prefers the uncompressed version. :) Anyhow, wifi working again with downgrade.
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
hexdump0815 has joined #aarch64-laptops
hexdump01 has quit [Ping timeout: 480 seconds]
chrisl has joined #aarch64-laptops
tobhe has quit [Ping timeout: 480 seconds]
chrisl has quit [Ping timeout: 480 seconds]
pabs has quit [Ping timeout: 480 seconds]
chrisl has joined #aarch64-laptops
pabs has joined #aarch64-laptops
chrisl has quit [Ping timeout: 480 seconds]
punit has quit [Ping timeout: 480 seconds]
enyalios has joined #aarch64-laptops
enyalios_ has quit [Ping timeout: 480 seconds]
jhovold has joined #aarch64-laptops
martiert_work has joined #aarch64-laptops
martiert_ has quit [Ping timeout: 480 seconds]
<steev>
oh nice, glad you got it working nirik :)
ravikant_ has joined #aarch64-laptops
chrisl has joined #aarch64-laptops
chrisl has quit [Ping timeout: 480 seconds]
jglathe_angrybox has quit [Read error: Connection reset by peer]
<janrinze>
valpackett: how does dtbloader solve the missing dtb at boot?
<valpackett>
janrinze: it loads the dtb (as the name suggests) so you don't need to tell the bootloader which one to load
SpieringsAE has joined #aarch64-laptops
Guest16424 is now known as maz
chrisl has joined #aarch64-laptops
chrisl has quit [Ping timeout: 480 seconds]
<janrinze>
valpackett: that was obvious, now where does dtbloader come in at boot? The kernel is loaded by grub. So I don't understand where dtbloader can do its thing.
<janrinze>
Treibholz[m]: Apparently your Debian setup is still quite a bit faster than mine. My glmark2 score is 3845. So there is room for improvement. Are you running Debian 12 or Debian 13? my kernel: 6.12.27-1 (2025-05-06)
chrisl has joined #aarch64-laptops
chrisl has quit [Ping timeout: 480 seconds]
steveej[m] has joined #aarch64-laptops
<steveej[m]>
janrinze: running `glmark2-wayland` on the x13s with nixos and 6.15.0-rc7 i'm getting 5635 score
<janrinze>
steveej[m]: Ah, probably wayland vs Xorg. I notice in Wayland the 800x600 image actually is scaled down.. Might explain the increase in fps?
<janrinze>
Although i get 6774 in Wayland, it's more likely due to the smaller window.
<deathmist>
then run both at 1x scale?
<janrinze>
deathmist: how?
<deathmist>
100% desktop scaling
<janrinze>
deathmist: obviously, but how?
<deathmist>
idk, search online, I don't know what desktops you're comparing
<deathmist>
obviously in display settings somewhere
<janrinze>
deathmist: :-D
<deathmist>
in KDE it's just a scaling % slider
<janrinze>
Gnome on wayland :-D
<janrinze>
Whoo, the DP-alt works too now. Clearly it required the firmware for the GPU. \o/
<JensGlathe[m]>
whut
<janrinze>
I think I need a USB-C monitor now that has all the goodies like charging and USB hub. :-D
<valpackett>
janrinze: look at the readme: https://github.com/TravMurav/dtbloader it's possible to install it "globally" as a driver from the efi shell so the firmware would load it before grub or any other bootloader
<JensGlathe[m]>
It has, but GPU firmware for DP altmode? Thinkbook 16 has dp altmode, but actually no GPU driver yet
<janrinze>
JensGlathe[m]: Ubuntu did dp-alt out-of-the-box. But Debian did not have the firmware for the GPU in the initrd. steev helped there. It's the x13s Lenovo.
<valpackett>
on my dell, dp altmode recognizes my capture card but the picture doesn't actually show up.. (todo: test with other devices i guess)
<janrinze>
valpackett: I saw some info on dtbloader at a linaro readme for the x13s. Didn't understand the guide.
<maz>
jhovold: funny how moving to a machine that didn't need the phy_qcom_snps_eusb2 driver resulted in finding a bucket-load of lockdep issues in my own code... :-/
<maz>
this thing urgently needs fixing, really.
<janrinze>
valpackett: dp-alt to capture card has given me many issues too. especially if the capture card has a different resolution than set for the external monitor. My CamLink is especially picky.
chrisl has joined #aarch64-laptops
<valpackett>
also enabling mdss_dp[01] was making the screen go black for waaay longer on boot (when initializing display)
<deathmist>
valpackett: regarding "bcfg driver" stuff I'm wondering couldn't "efibootmgr --driver" stuff be used somehow so you wouldn't necessarily need efi shell to set it up? would be rather convenient
<deathmist>
to setup dtbloader.efi that is
chrisl has quit [Ping timeout: 480 seconds]
reng_ has joined #aarch64-laptops
<deathmist>
gonna test if it works right now actually
hogliux has joined #aarch64-laptops
reng has quit [Ping timeout: 480 seconds]
<hogliux>
JosDehaes[m]: kuruczgy[m]: I was only testing qcam. With `rotation = <180>;` it *is* correct in gnome-snapshot and in firefox
<valpackett>
deathmist: yep that should work! if you confirm it, would be nice if you sent a PR adding an example to the readme
<hogliux>
kuruczgy[m]: btw: Not sure if you realised but video acceleration does work with you nix config. It's part of 6.15.0-rc6 (probably earlier). No other patches needed for the kernel at least. You can try `mpv -v path-to-h264-video` with `vd=h264_v4l2m2m` in `~/.config/mpv/mpv.conf`
<valpackett>
meanwhile systemd-boot just loads drivers from a directory itself :)
<hogliux>
kuruczgy[m]: so you can add that checkmark to your readme
hogliux has quit []
<valpackett>
hogliux: huh. i'm on latest linux-next and i didn't see any v4l in /dev..
hogliux has joined #aarch64-laptops
<hogliux>
valpackett: ahh then it actually might be part of the webcam patches I added. It was definitely also touching the iris stuff
<hogliux>
valpackett: but I thought I saw it being mentioned here that it would be part of 6.15.0. Do you have `qcom_iris` module loaded?
<hogliux>
valpackett: you also need to copy firmware from windows
<hogliux>
valpackett: so check `dmesg` if you see a firmware load error
<valpackett>
modprobed it, nothing
<valpackett>
i'm preeetty sure there are no dt nodes for it at all
<valpackett>
the iris yaml binding doesn't mention x1e
agl has quit [Quit: ZNC 1.8.2+deb3.1+deb12u1 - https://znc.in]
agl has joined #aarch64-laptops
WeetHet[m] has joined #aarch64-laptops
chrisl has joined #aarch64-laptops
chrisl has quit [Ping timeout: 480 seconds]
enyalios_ has joined #aarch64-laptops
enyalios has quit [Ping timeout: 480 seconds]
pbrobinson has quit [Ping timeout: 480 seconds]
pbrobinson has joined #aarch64-laptops
chrisl has joined #aarch64-laptops
chrisl has quit [Ping timeout: 480 seconds]
<robclark>
janrinze, JensGlathe[m]: dp needs adsp fw but itself shouldn't need gpu fw
<robclark>
also, I think x1-45 support should hopefully come in a matter of weeks
<JensGlathe[m]>
Testbed is prepared
craftyguy has quit [Remote host closed the connection]
craftyguy has joined #aarch64-laptops
SpieringsAE has quit [Quit: SpieringsAE]
<jhovold>
maz: indeed, I keep reminding them to get the lockdep issue sorted, not sure why it's taking so long
<jhovold>
I have a local hack so that I can run with lockdep myself, but I haven't included it in the wip branch in the hope that the splat should remind people that the phy implementation is broken
<maz>
jhovold: the logical conclusion is that the maintainers of this code don't use lockdep themselves... I suppose this could be papered over with a blanket "mutex_lock_nested()" all over the phy code.
<jhovold>
yeah, someone just need to come up with a way to set the nest level, really shouldn't be that hard, but I refuse to work on it
<jhovold>
I need to be able to delegate some things...
<robclark>
jhovold: is there somewhere in particular I should complain about not being able to use lockdep? ;-)
xroumegue has joined #aarch64-laptops
xroumegue has quit []
xroumegue has joined #aarch64-laptops
<maz>
maybe QC patches should stop being merged until this is solved. I can't see how we can ensure we have proper locking without it (yes, I've just been burned).
<maz>
or this module flagged as BROKEN.
ravikant_ has quit [Remote host closed the connection]
<jhovold>
maz: marking the module as broken would break usb and possibly also display on x1e and a some other qcom socs so that would at least be noticed ;)
<maz>
jhovold: I guess that's the angle. let me post a patch, because I don't think a driver in this state deserves to be upstream -- it impacts the quality of everything else.
<robclark>
I haven't looked at the phy code, so idk if it would make sense there... but I noticed regulator is using ww_mutex to deal with locking order issues
<maz>
my understanding is that the lock ordering is most probably OK here. it is the nesting that break things, as lockdep doesn't know (without further annotations) that two instances of a particular lock are compatible as long as the order is preserved.
erebion has joined #aarch64-laptops
chrisl has joined #aarch64-laptops
chrisl has quit [Ping timeout: 480 seconds]
hwpplayer1 has joined #aarch64-laptops
chrisl has joined #aarch64-laptops
chrisl has quit [Ping timeout: 480 seconds]
ravikant_ has quit []
hwpplayer1 has quit [Remote host closed the connection]
<valpackett>
make sure that clock driver is enabled in the config i guess
<JosDehaes[m]>
oh yeah there was an extra patch 🤦
<anthony25>
valpackett: the cpu spikes, how short are they? is it something I could just see in htop?
<valpackett>
yep
<anthony25>
and all the time or just when there's network activity?
<valpackett>
all the time
<anthony25>
ok, let me check
<valpackett>
it's a periodic timer hardcoded to 6 seconds that does the netlink dump to check on wifi status
<anthony25>
ok
<anthony25>
I don't see it
<JosDehaes[m]>
still the same probe error
<Jasper[m]>
@robclark slightly late, but I'm now trying to compile the kernel with your patch
<Jasper[m]>
I did see it was picked up already though (the panel patch)
<valpackett>
anthony25: wcn7850 with reverted to working firmware?
<anthony25>
yeah
<robclark>
Jasper[m]: yeah, so hopefully it works ;-)
<anthony25>
the only "spikes" I can see is a bump to 0.6% of CPU from NetworkManager
<robclark>
presumably dianders double checked my reading of the panel data sheet
etehtsea has joined #aarch64-laptops
<valpackett>
anthony25: yeah for me it bumps to 99%
<anthony25>
but they're very rare
<valpackett>
and the impact is it consumes 1W on average
<anthony25>
I'm on jhovold's kernel, 6.15-rc7
<anthony25>
network manager 1.52, on Tumbleweed
<valpackett>
i'm on linux-next with a couple manual patches, lemme see if there are any ath related ones there
<Jasper[m]>
@robclark we'll see, turns out sc8280xp isn't that much of a compiling monster with that big of a kernel
<dianders>
robclark: I didn't. I usually don't if things look reasonble. I can if you want, though. ;-)
<anthony25>
valpackett: which laptop do you have, btw?
<robclark>
I _think_ someone else already did test it (it isn't the panel I have in my x13s)
<Jasper[m]>
@Grabunhold?
<robclark>
yeah, I think so
<anthony25>
because 5W idle minus this causing 1W drain, it's pretty good! I get 6W idle with the brightness at < 10%
<Jasper[m]>
Hm, Fluffychat doesn't list him as being here it seems
<anthony25>
(on a slim 7x)
<valpackett>
anthony25: dell latitude-7455
<valpackett>
not minus this, heh
<valpackett>
5W is with networkmanager suspended xD
<anthony25>
ha, ok :p
<robclark>
iirc there was an issue w/ needing to leave one of the pcie's on x1e powered up which prevents hitting the lowest power states... and at some point someone was working on that? But bamse or konradybcio might know better
<anthony25>
well, still 1W less, but that could be due to the IPS using a bit less power
<robclark>
yeah, probably
<robclark>
panel (or backlight) still draws a lot of power, compared to a phone
<anthony25>
robclark: pcie and the nvme, if I understood correctly
<robclark>
or maybe the pcie the nvme is connected to, I guess
<anthony25>
<robclark> panel (or backlight) still draws a lot of power, compared to a phone << true, but windows is able to hit ~3W idle with the screen on (and quite bright)
<anthony25>
I was actually surprised by the oled on the slim 7x, the power consumption doesn't change much regarding of the brightness level
<robclark>
maybe we aren't entering PSR?
<dianders>
robclark: shouldn't it actually be `delay_200_500_e50_p2e80` since `T4+T5+T6+T8>80ms` ?
<robclark>
hmm, let me look at datasheet again
<anthony25>
robclark: also, no idea what could have fixed it, but I wasn't able to reproduce at all the gpu lockup bug I had
<robclark>
\o/
<robclark>
dianders: maybe? I was just comparing to another panel that used delay_200_500_e50 and looks like it had the same sequencing chart
chrisl has joined #aarch64-laptops
<robclark>
dianders: but I guess you've looked at a lot more panel sequencing charts than I have
<dianders>
robclark: I wouldn't be too surprised if the other panel just got it wrong. It really easy to miss things when reading the diagram. One of these days it'd be great to get a python script to ask questions about the diagram and say what the delays should be or something.
<valpackett>
ooh what's the deal w those timings? i picked delay_200_500_e80 sorta randomly for my boe panel and it works but i should have it more thought through for upstreaming
<dianders>
valpackett: It's all from the panel datasheet. If you don't have access to the datasheet then about the best you can do is guess. :( I have accepted patches that included guesses in the past, but I like it when people at least document in the commit message that it was a guess.
<robclark>
dianders: idk if other vendors label their charts differently.. otherwise it would be nice to just enter all the Tn's and get values
<robclark>
the other BOEs I looked at looked similar
<valpackett>
oh, ok. i'm not even certain of the *exact* model as the EDID just says it's a NE14QDM but not the suffix.. i can exclude the higher Hz ones but i saw various 60hz ones
<dianders>
I'm also still not sure why I wrote in the docs that `prepare_to_enable` is `This is not specified in a standard way on eDP timing diagrams`. I swear there was some panel doc that it was weird on, but in all recent panels I've looked at it's (T4+T5+T6+T8)-min
<dianders>
robclark: different panels definitely specify things differently. In 95% of the cases the "T" numbers match up, but different panels make different types of requirements on them.
<valpackett>
re: power, i see the ath12k doesn't have aspm enabled
<robclark>
valpackett: hmm, ok.. at least for NV133WUM-N61, parse-edid hadthe suffic
<robclark>
dianders: yeah, I meant the labeling, not the actual numeric values
<valpackett>
maybe the parser i'm using is bad lol (i only found di-edid-decode in alpine/pmos)
chrisl has quit [Ping timeout: 480 seconds]
<valpackett>
ah no that's visible in the raw hex dump too
<dianders>
robclark: The problem is that they don't just all specify the things individually, but some do. Like the panel you just pointed at didn't make any specific requirement on T4, T5, T6, or T8 but made a requirement about the sum of them. With so many differences it's hard to make something totally generic.
<valpackett>
RGNR <non printable char> NE14QDM
<robclark>
ahh, ok
<dianders>
Like `powered_on_to_enable` is for panels that make requirements about (T3+T4+T5+T6+T8)-min. ;-)
<anthony25>
valpackett: I'm not sure about this, someone who worked on this could tell you more, but I think aspm was disabled on purpose (linked to what robclark before)
<anthony25>
*said before
<Jasper[m]>
Still compiling modules...
etehtsea has quit [Read error: Connection reset by peer]
<valpackett>
oh maybe because of s2idle.. i just booted with pcie_aspm=force, confused myself re systemctl freeze vs suspend, suspended the system and it kinda woke up (backlight lit up) but stopped there, no picture
<valpackett>
though not confirming anything yet
<anthony25>
are you using s2idle or s3?
<valpackett>
oh aspm's disabled there anyway even with force
<valpackett>
anthony25: hmmmm i didn't change the default
<bamse>
robclark: right, there's more work needed in the pcie space in order to allow us to get into the lower power states, but more so on sc8280xp
<valpackett>
didn't think we even have s3
<anthony25>
by default it's using s3, and I got more bugs than s2idle, like wake up on USB plug/unplug
<bamse>
robclark: PSR is disabled, because it doesn't work with fbcon (and konrad reported that since it's always disabled, it has bitrotten)
<anthony25>
I don't know if it's really s3, but "deep" mem suspend is the default
<valpackett>
oh
<valpackett>
what's the power difference between deep and not deep?
<valpackett>
ooh, easy enough to try enabling PSR back?
<robclark>
I'm not quite sure where it was disabled offhand
<anthony25>
valpackett: when I switched to s2idle, I found almost no difference in power consumption, but I don't use it for long (I just use it if I need to close my laptop for < 1h and resume it after)
<anthony25>
but I list my laptop had less chances to wake up by itself burning in my bag :}
<anthony25>
*least
<robclark>
valpackett: try msm.psr_enabled=1 on kernel cmdline
etehtsea has joined #aarch64-laptops
<Grabunhold>
Jasper[m]: you pinged me?
<Grabunhold>
sorry, i'm at least 2 days or something behind in backlog here. and i'll be on a business trip for the next 2 days. with my x13s only, by the way! :)
<Grabunhold>
i read something about the panel in my x13s? I want to test the patch robclark posted, but haven't gotten around to it yet!
<anthony25>
robclark: that does something, but I have some black screen flickers when I guess the screen goes into a lower framerate
<anthony25>
on framebuffer it's just a short blink, but on a wayland session, when idle it can be really long black screens
<valpackett>
anthony25: VRR screen? fancy
<robclark>
hmm, ok.. so not working that great
<anthony25>
I don't think it's really VRR, no?
<robclark>
most of the screens support 60 and 09 or 120 fps, but with a fixed pixel clk
<valpackett>
or do you mean just the system output frame rate
<Jasper[m]>
@Grabunhold welcome back! Yes I did, but @robclark assumed you did test it
<robclark>
and super long backporch at lower rate
<Jasper[m]>
or at least someone did
<anthony25>
exactly, that's what I meant, like no change happening on the screen
<Jasper[m]>
Modules are still compiling....
<bamse>
robclark: ohh, i just reported it to abhinav and dmitry, had missed the issue tracker
<anthony25>
<robclark> and super long backporch at lower rate << well… here they seem to be a bit too long, the screen just shutdowns during several seconds :D
<bamse>
robclark: johan reported recently that PSR seems to give him about 2 hours extra battery...so it's certainly something we'd like to have
<robclark>
yeah
<bamse>
robclark: and iirc it workd fine in wayland, but i had to login and launch sway without screen updates (or do vt switching to see my screen updates)
<valpackett>
ok yea i see now it's basically not actually self refreshing at all while the kernel thinks it is
<anthony25>
I could only test it on idle, the power consumption was slightly lower (5.4W instead of 6W), but I'm not sure it's a good test considering that the screen was black due to the bug, and it's an oled
<bamse>
valpackett: regarding psr_enabled, be aware that few people run with that =1 so ymmv
<valpackett>
yea sadly on my panel rn it's just black when it's supposed to be self refreshing
<valpackett>
(i.e. when idle)
<anthony25>
yeah we have the same issue
<bamse>
valpackett: in console or in wayland/x11?
<anthony25>
both
<anthony25>
console is blinking every second
<valpackett>
in gnome wayland, but yea doesn't look like it would depend
<bamse>
then you're probably seeing bitrot, rather than the issue i saw
<anthony25>
and on wayland it depends, when going really idle then the black screen can last several seconds
<Grabunhold>
Jasper[m]: robclark: sorry to disappoint, but the last few days have been busy and i didn't get around to testing it. and that will unfortunately probably stay that way until at least monday
<robclark>
Grabunhold: no worries
etehtsea has quit [Read error: No route to host]
<anthony25>
actually, console has the same problem, the screen was just maintained awake to the cursor blinking
<anthony25>
*due to
etehtsea has joined #aarch64-laptops
<valpackett>
yeah with black screen psr it's like 4W which is p much the same as DPMS
<bamse>
anthony25: the console would render just fine for me, it just would only update when i switched vt
<valpackett>
looks like very dim backlight is barely an impact vs screen completely off?? 0.o
<valpackett>
bamse: heh i've had that exact bug with i915 (haswell) on freebsd
<robclark>
so with the panel using the same pix clk at 60fps as it would at 90/120, I guess you lean a bit on PSR to bring down the power
<Jasper[m]>
@Grabunhold no worries, am compiling the kernel now to test
<anthony25>
is it completely off on the IPS as well?
<Grabunhold>
robclark: well, it's the first time someone took the time to write a kernel patch on my behalf and I'm super humbled!
<valpackett>
anthony25: one would hope that DPMS would actually shut everything down for real? xD
<robclark>
yw :-)
<anthony25>
ha sorry, I misunderstood, I thought you were talking about the black screens with PSR shutting down the screen entirely
<valpackett>
i was comparing those to DPMS in terms of avg watts
<Grabunhold>
Jasper[m]: so you got the x13s with the same display as me?
<Grabunhold>
gotta go, will read later!
chrisl has joined #aarch64-laptops
jdb[m] has joined #aarch64-laptops
<jdb[m]>
<dianders> "robclark: shouldn't it actually..." <- dianders: Do we know how eDP panels are detected / supported on Windows side?
<dianders>
jdb[m]: I don't personally, but I think I've seen some references about all the magic delays being hardcoded in the BIOS somewhere?
<robclark>
probably similar to what panel-edp.c does, read the edid
<robclark>
hmm, could be in acpi tables
<dianders>
Possibly the BIOS might read the EDID and pick something to help with setting up the ACPI tables? I'm just guessing, though.
<jdb[m]>
I don't have a technical datasheet for the panel found in the Surface Pro 9 5G so I don't know how to guess the power sequence
<jdb[m]>
Any risk for the panel when trying different settings ?
<jdb[m]>
LG LP129WT232166 in this case
<dianders>
jdb[m]: Technically there can be, but typically panels are fairly robust. Settings are often "wrong" for years and work fine because mostly the panels don't care. ...but some are more picky and the hardware guys will always tell you you should put the right delays in.
chrisl has quit [Ping timeout: 480 seconds]
<jdb[m]>
Ok I'll keep trying existing options in panel-edp then
<valpackett>
ayyyy external DP to the capture card works today. i didn't rly change anything DP wise other than compiling my own kernel with the eDP timings recognition for the built-in screen..
<valpackett>
the apply button in gnome display settings freezes all display output for a long time upon changing scale for an external monitor.. and can even crash gnome it seems