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]
pabs has joined #aarch64-laptops
chrisl has joined #aarch64-laptops
chrisl has quit [Ping timeout: 480 seconds]
weirdtreething has quit [Read error: No route to host]
<valpackett>
bamse: i only got the hw recently and 'always' had it but i started with very recent linux-next and no one else was having it because lots of ppl were still on 6.14
<valpackett>
that patch looks like it should help
<valpackett>
very strange though, it mentions completely different things-to-wait-on than what shows up in perf
<bamse>
valpackett: indeed, i don't understand why perf doesn't tell us that we're in ath12k_mac_get_fw_stats()
<bamse>
valpackett: but per perf's output that we're spinning, above bpftrace identifies all the stacks where this happens... and over a few seconds most of them happens at most a few hundred times...except this one, which happens hundreds of thousands of times
<jhovold>
- drop some 80 patches that are now in mainline
<jhovold>
Known issues:
<jhovold>
- dp hotplug crashes and resets (6.16-rc1 regression)
<jhovold>
- eusb2 phy module has been renamed (e.g. Kconfig and initramfs)
<jhovold>
- ath12k fw in linux-firmware-20250508 is broken (revert to previous version)
<anthony25>
wow, thanks a lot jhovold!
<anthony25>
drop some 80 patches that are now in mainline <<< that is really awesome!
<jhovold>
robclark, lumag: could you please look into the dp hotplug crashes, it appears to be a drm regression
<jhovold>
both wayland and xorg crashes when I connect an external monitor
chrisl has joined #aarch64-laptops
<jhovold>
second attempt triggered a reset of the t14s a few times
chrisl has quit [Ping timeout: 480 seconds]
enyalios has quit [Remote host closed the connection]
enyalios has joined #aarch64-laptops
chrisl has joined #aarch64-laptops
chrisl has quit [Ping timeout: 480 seconds]
pabs has quit [Read error: No route to host]
pabs has joined #aarch64-laptops
<jhovold>
anthony25: yeah, that branch was getting a bit unwieldy, partly because the qcom dt changes never made it into 6.15 so had to carry those for another cycle
<jhovold>
the updated t14s mainline status is looking a bit better now:
<deathmist>
nice! now x1e stuff is starting to look more distro-packaging friendly in general, maybe I'll have a go at that again and ISO images too once 6.16.1 stable is around in ~2 months
<bamse>
and i suspect we might need a EC driver for the dell xps13...because it probably need some enouragement to turn off the fan completely
<alexVinarskis[m]>
yes, fans are controlled by EC on XPS and work funnily atm without the driver. It appears their EC is not similar to EC in other x1e models, did some quick tests. So its up to Dell to add EC support.
chrisl has joined #aarch64-laptops
<bamse>
alexVinarskis[m]: right, it's mostly working...but despite the laptop being cold, it's still spinning the fan a bit
<bamse>
alexVinarskis[m]: i don't necessarily think we need to wait for Dell to do that, it seems to mostly be implemented in DSDT...
<alexVinarskis[m]>
its kind of 'retarded' - fans are too slow until almost 100C SoC, only then do just burts, and slow down again. And yes never fully stop, not even in suspend.
<alexVinarskis[m]>
As per my understanding, things in DSDT are not enough, so appears there is a windows driver as well, but perhaps you can make more sense of it, not a dsdt expert haha
<JensGlathe[m]>
Oh that retarded pattern, I know that from the WDK2023. Tried booting Windows, booting Linux afterwards and doing the load?
<JensGlathe[m]>
There seems to be a thermal management marker uefi variable which gets inavlid with every failed boot /crash, at least its on the WDK
chrisl has quit [Ping timeout: 480 seconds]
SpieringsAE has joined #aarch64-laptops
<SpieringsAE>
alexVinarskis: hows the fan on your zenbook? on my vivobook it just seems to always spin at the same speed, seems to be enough to keep it 85 degrees ish during 100% load, but still odd
<SpieringsAE>
wonder if at least those may be similar to each other
SpieringsAE has quit []
<anthony25>
bamse: the slim 7x does the same without the EC driver, the fans are not stopped in suspend and the keyboard is not shutdown
<anthony25>
but they stop when the laptop is cold
<alexVinarskis[m]>
on zenbook it seems to spin _up_ nicer than on dell, eg. before laptop reaches 100+C, however wont spin _down_ until i power off & power on (not reboot). So after compilation if i just suspend it, fans are still blasting full power :D
<dgilmore>
jhovold: Is there anything critical missing from upstream now for the t14s to boot and mostly function?
<jhovold>
dgilmore: yes, you still need my workaround for the EBS() failure to boot reliably
<jhovold>
and a revert for the irq suspend regression in 6.16-rc1
<jhovold>
support for the oled variant is also missing
<jhovold>
just one trivial patch missing but it was never resubmitted, should be in 6.17
<dgilmore>
okay cool. thanks, I was curious after 80 patches got in
<jhovold>
yeah, and of course skin temperature thermal throttling is still not implemented
<nirik>
sadly the slim7x bluetooth dts patch didn't seem to land upstream or in jhovolds tree... wonder what state it's stuck in...
<jhovold>
nirik: for the t14s/crd it's stuck on how to model m2 cards and whether we should rip out the pwrctrl dependency
<anthony25>
no I think you're right, I'm using this one as well
<anthony25>
JensGlathe[m]: can you resend this patch? or did you have some comments outside of the email thread that block it?
<JensGlathe[m]>
That wcn7850-pmu driver is required to safely enable the type-a+e card as I learned when trying to remove it for the DevKit (with an Intel card in that slot). You get 30 seconds of work, then something bad happens and no NIC
<JensGlathe[m]>
Anything special about resend? Never did that yet. Just a v2?
<anthony25>
you used b4?
<JensGlathe[m]>
yes
<bamse>
anthony25: 100C CPU temp, or 100C on one of the external thermistors?
<anthony25>
it should generate an email starting with "[PATCH RESEND] …"
<anthony25>
<bamse> anthony25: 100C CPU temp, or 100C on one of the external thermistors? <<< * alexVinarskis[m]
<anthony25>
JensGlathe[m]: and you can import the tags of your current email, so you'll have my "tested-by"
<erebion>
X13s, I am on Debian, tried 6.15.1-1~exp1 from experimental. External Display via Thinkpad dock no longer works, used to to work on 6.12.27 from testing. I think dmesg said something about link training failing. Is that already a known issue?
<steveej[m]>
erebion: i don't know about debian. external display via USB-C works for me on 6.15.0 on nixos with johan_defconfig (and some nixos defaults)
<jhovold>
erebion: afraid that's a known regression in 6.15, the added lttpr support in 6.15 was incomplete and alexVinarskis[m] fixes for that never made it into 6.15 final
<bamse>
erebion: what resolution does it attempt?
<erebion>
jhovold: Thanks for the answer. Will that regeression likely have a fix in 6.16? Have the fixes already been upstreamed?
<jhovold>
i don't think we heard anyone confirm the breakage until now, but I pointed out that possibility here:
<bamse>
erebion: i think starting in 6.14 my x13s suddenly think that 4k@60 is a valid mode, but it isn't (yet) so the display is failing to come up
<erebion>
jhovold: Will regressions get fixed in 6.15 as well or is it just broken until 6.16 is there?
<erebion>
The whole kernel development process looks like a huge pile of mess from the outside and hard to follow what's happening at kernel.org xD
<clover[m]>
For agl and the 2 other people that use my x13s arch repo, i updated the kernel to 6.14.10 and linux-firmware to 20250509. Might need to refresh keys bc my self signed one expired and I had to republish to keyserver
<jhovold>
erebion: yeah, it can be hard to follow also for folks used to the process at times, depends on the subsystem
<jhovold>
we should be able to backport the lttpr fixes if you can confirm that it helps and that it's not a different issue, like the one bamse just mentioned
<bamse>
jhovold: do we have anyone to do lttpr with on x13s as well?
<JensGlathe[m]>
shouldn't this be implemented with alexVinarskis lttpr patchset?
<jhovold>
there could be retimers in external docks which are now misconfigured, iiuc
<jhovold>
yes, alex's patches fix this, but they never made it into 6.15
<jhovold>
only 6.16-rc1
chrisl has joined #aarch64-laptops
<jhovold>
but if you run into a similar breakage already with 6.14, then erebion could try to confirm that too first
<steveej[m]>
(btw. i'm on jhovold/linux 6.15.0 and the above error i showed has been happening for all previous kernel versions that i ran. i believe i started around 6.10 with the x13s)
<bamse>
jhovold: ahh, right and people have been complainging about the thinkpad dock since the beginning of time
<jhovold>
steveej[m]: that would be the modem, i don't have one in my x13s which would explain why I haven't seen that
<jhovold>
bamse: have you noticed any stuck pcie3a gdsc like that?
<bamse>
jhovold: no, but i'm apparently still on v6.14 on my "production" x13s (which is the one with modem)
<bamse>
ohh, 6.10 < 6.14.3
chrisl has quit [Ping timeout: 480 seconds]
<bamse>
no oopses in the log here though
<bamse>
usb is functional, but i have a rather large number of usb disconnect/reconnects in my log...don't know what that is yet; seems to relate to the issues i've mentioned before wrt my monitor
<jhovold>
did enabling ucsi help with that at all?
<steveej[m]>
jhovold: i don't think i have one either in this machine if i'm not entirely mistaken :-D i think i have configuration for the modem enabled
<jhovold>
steveej[m]: hmm, right, the controller is enabled here too, but haven't seen that stuck off warning
<bamse>
jhovold: no
<bamse>
jhovold: and it's much worse on my second x13s...
<valpackett>
bamse: alexVinarskis[m]: hmmmmm, on dell latitude, the only fan issue is it spinning up due to the lid being closed in s2idle, but that seems actually mitigated by deep suspend. at multicore load it spins up perfectly and keeps the soc at 90 degrees
<travmurav[m]>
as in, takes the patches from the version backup and sends them, instead of sending the latest state, it's a bit annoying but I guess that's what "resend" kinda is xD
<travmurav[m]>
it's a bit annoying if you care about not having high vX but also not sure how much resends help really when subsystem maintainers organize their work with tracking submissions in i.e. patchwork
<travmurav[m]>
well not great if it's handled fifo xD
<alexVinarskis[m]>
bamse: in idling right now, not compiling anything just lots of things open. Xps fans are off (not slow, off). 95C SoC :)
<alexVinarskis[m]>
* valpackett:
chrisl has quit [Ping timeout: 480 seconds]
<steveej[m]>
jhovold: i actually had the modem disabled in the UEFI setup. i enabled it, and now the error doesn't show in dmesg! however, still capped at 1MB/s bandwidth
<steveej[m]>
now, this is via a USB3 hub that's connected to my monitor, which is connected via USB-C to the x13s. so there are a few hops
<bamse>
alexVinarskis[m]: hmm, my CPU cores are reportedly 29C...and the fan is spinning
<bamse>
travmurav[m]: that damn maintainer and his procesess... ;)
<travmurav[m]>
:)
<travmurav[m]>
I meant more generally I guess but in case of msm I understand you do just use patchwork and if it's "new" then it's still in the queue?
<valpackett>
alexVinarskis[m]: wtf 0.o is it actually hot to the touch or are the sensors wrong?
<valpackett>
here: cpu0_0_top_thermal-virtual-0 +33.7°C (and others around the same value)
<valpackett>
fan off
<gwolf>
travmurav[m]: one of the things I like most about the Yoga C630 is that is fanless ;-)
<bamse>
travmurav[m]: right, i have a tool that keeps patchwork and tags in my inbox (using notmuch) in sync...and then i just go through what's "new"
<bamse>
gwolf: same with x13s, it's really nice...although sometimes you miss the fact that it's hot and requires attention
<travmurav[m]>
Cool, thanks! Nice to understand the process to not spam patches too much when it's not necessary :D
<gwolf>
Maybe I'm to little of a power user... but I've never noticed the C630 get hot
crisma has left #aarch64-laptops [WeeChat 3.8]
<bamse>
gwolf: there was a time when we couldn't make it run hot...then we fixed that bug...
crisma has joined #aarch64-laptops
<bamse>
think the cpu cores where capped in hardware to 55C or something
<gwolf>
oh! Well, I've never noticed mine not being snappy... So I think it's not that bug's fault
<bamse>
gwolf: we where always behind on geekbench score compared to windows, and you couldn't maintain a zoom call without audio stuttering
<bamse>
gwolf: once i figured out the problem and let the beast free it was a much nicer platform
<bamse>
and speaking of that, i think need to follow up with the arch linux arm patch enabling the EC in linux-aarch64 kernel, so we can use that
gwolf has quit [Ping timeout: 480 seconds]
gwolf has joined #aarch64-laptops
<gwolf>
Right. Well, I've had video conferences on mine just fine (with an external audio dongle). But it's not good for sustaining WebRTC classes --- I think it's too much to ask from the little bugger...
chrisl has joined #aarch64-laptops
svarbanov__ has joined #aarch64-laptops
svarbanov_ has quit [Ping timeout: 480 seconds]
chrisl has quit [Ping timeout: 480 seconds]
vanveldt has quit [Ping timeout: 480 seconds]
<steveej[m]>
turns out my monitor has a usb-c mode setting that's either "high data rate" or "high resolution". if i set it to the latter then it caps I/O at ~1MB/s.
<steveej[m]>
and as i want to keep a yubikey in the laptop directly i'm limited to having just one USB-C connection for everything else. i wonder if there's a hub that can passthrough DP and PD that i could plug between the x13s and the monitor
<HdkR>
Whoa, it doesn't even pass through USB 2.0?
<HdkR>
That's nutty
<steveej[m]>
if i set it to "high data rate" i can get around ~40MB/s reading from a USB SSD, still not great. however then the wacom USB touchpad becomes laggy. not great either way
<gwolf>
steveej[m]: I might be mistaken here, but I remember reading (here? Probably) that the issue is hat DP does not _travel over_ USB 3.x, but the USB-C port has the _ability to switch_ over to being a DP port (that also carries USB)
<gwolf>
So, most USB hubs or the like will not offer that switching capabilities. If I understand correctly, all external USB video connectivity options have to be directly connected to the computer
djakov has quit [Remote host closed the connection]