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 joined #aarch64-laptops
chrisl has quit [Ping timeout: 480 seconds]
chrisl has joined #aarch64-laptops
chrisl has quit [Ping timeout: 480 seconds]
<valpackett>
idle with min brightness but screen still on: 3.5W (before it was around 4W) \o/
<anthony25>
nice !
<valpackett>
now if only i could actually always run with the SSD ASPM'd without worrying about random hangs
<anthony25>
are you on linux-next?
<valpackett>
yes
<valpackett>
with extra patches
<anthony25>
try to enable aspm on the SSD and see how it goes?
<anthony25>
I think it's enabled on my slim 7x, since I applied the aspm fix
<anthony25>
I didn't see any freeze yet
<valpackett>
oh i've had ASPM enabled on the SSD initially, before it stopped being enabled on boot
<valpackett>
the pwrctl thing breaking ASPM was what led me to conclude that it was SSD ASPM after all that was causing the hangs
<anthony25>
ha, I see
<valpackett>
initially it was just a mystery that affected some people but not everyone
<valpackett>
we did correlate it with "who has swapped their SSD to a 3rd party one", actually, just based on chat
<valpackett>
but no freezes anymore for me after ASPM got disabled was the real confirmation that it was SSD related
chrisl has joined #aarch64-laptops
<valpackett>
i'll eventually do another linux install on the stock ssd and try running on that.. or actually maybe a *different* 3rd party one would be more interesting
<valpackett>
well.. can't definitively say no but the symptoms are very different from just the *drive* hanging / dropping of the bus / failing to do something
<valpackett>
it's a *total* system freeze, no magic SysRq, nothing
<valpackett>
we really need someone with internal qcom debug equipment to try to reproduce that :)
chrisl has quit [Ping timeout: 480 seconds]
ungeskriptet has quit [Ping timeout: 480 seconds]
chrisl has joined #aarch64-laptops
ungeskriptet 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]
chrisl has joined #aarch64-laptops
chrisl has quit [Ping timeout: 480 seconds]
chrisl has joined #aarch64-laptops
tobhe_ has joined #aarch64-laptops
chrisl 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]
<steev>
valpackett: fwiw, i have an sn770m 2tb in mine, and the only time i see lockups are on ubuntu/JensGlathe[m] kernels
<steev>
no idea how to tell if i have aspm or not though
<valpackett>
grep LnkCtl, even, to avoid the noise about whether the devices themselves are capable
<steev>
looks like its enabled
ungeskriptet has joined #aarch64-laptops
<valpackett>
if you have a kernel where you can run for days on end without random complete freezes with aspm on on the ssd, tell me which kernel it is :D
<steev>
johan's patches and a few extra on top, using ubuntu
<steev>
i haven't pushed rc7 yet
<steev>
i am able to push it enough to lock up but it seems heat related, or possibly mem related, as i'm typically building a bunch of stuff at the same time and hitting 29GB of ram usage
<steev>
some day all 64GB will be available to me, but that day, is not today
chrisl has joined #aarch64-laptops
<valpackett>
steev: oh, no, the ssd related random freeze seems to always happen on idle / low load
<steev>
i've seen once or twice, a reset (nothing in the logs) when i ran a git pull, over ssh
<steev>
but definitely not constant or common
<valpackett>
it's very random, sometimes i got 4 days of uptime, sometimes it happened twice in a row
zetam has quit [Quit: going out!]
<valpackett>
and it's not a sudden reset, only the watchdog resets the machine in 2 minutes
<valpackett>
until it's reset by watchdog or holding power btn, it's just completely frozen, *no* kernel panic led, no reaction to magic sysrq, no nothing
ungeskriptet has quit [Ping timeout: 480 seconds]
chrisl has quit [Ping timeout: 480 seconds]
ungeskriptet has joined #aarch64-laptops
<valpackett>
back to power measurement: it seems that usb-c ports don't fully sleep before anything's been plugged into them? :/
<valpackett>
as in, fresh boot rn with nothing plugged in, idle 3.8W, not going below until i plugged & unplugged a yubikey into usbc, only *then* went down to 3.5W
chrisl has joined #aarch64-laptops
chrisl has quit [Ping timeout: 480 seconds]
hexdump01 has joined #aarch64-laptops
chrisl has joined #aarch64-laptops
hexdump0815 has quit [Ping timeout: 480 seconds]
ungeskriptet has quit [Ping timeout: 480 seconds]
chrisl has quit [Ping timeout: 480 seconds]
chrisl has joined #aarch64-laptops
chrisl has quit [Ping timeout: 480 seconds]
<steev>
oh, i've only had the reset, never completely frozen
chrisl has joined #aarch64-laptops
chrisl has quit [Ping timeout: 480 seconds]
chrisl has joined #aarch64-laptops
chrisl has quit [Ping timeout: 480 seconds]
ungeskriptet has joined #aarch64-laptops
chrisl has joined #aarch64-laptops
jglathe_volterra has quit [Remote host closed the connection]
ungeskriptet has quit [Ping timeout: 480 seconds]
chrisl has quit [Ping timeout: 480 seconds]
chrisl has joined #aarch64-laptops
<albsen[m]>
steev: how are you booting it, grub or systemd-boot? you're running kali on it, right? did you install from a debian live environment or via chroot out of ubuntu?
<steev>
grub, ubuntu on the t14s (for now)
chrisl has quit [Ping timeout: 480 seconds]
<albsen[m]>
how often does it reset for u?
<albsen[m]>
previously I had it once or twice a day, but that wasn't on 6.16
<albsen[m]>
and appeared to be wifi related which might be fixed now
chrisl has joined #aarch64-laptops
<steev>
for me, i've only seen twice since switching to rc6 (now i'm on rc7) and both times were me doing a git pull
<steev>
well, no, i had it do it earlier but i was building zed, uv, sniffnet, ghostty, and something else and had hit 29G of ram usage (plus it was fairly hot to the touch)
<steev>
nothing in the logs, so no idea what it actually was, sadly
<JensGlathe[m]>
Could it be emergency temp shutoff by firmware?
<JensGlathe[m]>
I triggered this once
chrisl has quit [Ping timeout: 480 seconds]
SpieringsAE has joined #aarch64-laptops
jhovold has joined #aarch64-laptops
icecream95 has quit [Ping timeout: 480 seconds]
<steev>
maybe
<steev>
hard to tell without any kind of logging :)
<valpackett>
wow, *these* issues i don't understand, never had a reset and my dell never gets anywhere close to emergency temps
<valpackett>
at full load it keeps one specific cpu temp sensor at exactly 90 degrees, clearly throttling correctly
fossdd has joined #aarch64-laptops
chrisl has joined #aarch64-laptops
hightower2 has joined #aarch64-laptops
chrisl has quit [Ping timeout: 480 seconds]
<JensGlathe[m]>
would be interesting to know which one
chrisl has joined #aarch64-laptops
<steev>
one of them is a skin temp, and that's the one that is "how hot is it to touch"
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]
chrisl has joined #aarch64-laptops
<valpackett>
Jens Glathe: cpu1_2_top_thermal IIRC
chrisl has quit [Ping timeout: 480 seconds]
<jdb[m]>
I have an sn770 2tb in the SP11 too, I see total freezes randomly, but I don't have the watchdog reset the machine after 2 minutes
eirikkar has joined #aarch64-laptops
ursa-major has quit [Write error: connection closed]
abcdw has quit [Remote host closed the connection]
kuruczgy_ has quit [Remote host closed the connection]
<jdb[m]>
I've seen a few assumptions so far: ASPM with that 3rd party SSD, Wi-Fi, GPU, external screen interaction with suspend/resume...
<jdb[m]>
I'll try to eliminate some of these possibilities to reduce the scenarios
<jdb[m]>
X13s with the same config, setup and conditions (but a different SSD) is perfectly stable, I'm switching to it as my main laptop
<jdb[m]>
I just wished it would have better suspend power consumption, in my dream crazy good like Mac laptops
<jdb[m]>
Which should be possible with Qualcomm-based SOCs
<JensGlathe[m]>
Curiously, my T14s has a SN740 from factory. No hangs.
<lynxy>
i get the occasional freeze combined with a watchdog reset, typically on low or idle loads, but i also have *not* replaced the first-party ssd so i'm not entirely sure.
<jdb[m]>
I've never been able to get the SP11 stable until I brought it up
<jdb[m]>
It's a really really nice device but until it's stable, I can't trust it and switch to it as a daily driver. We'll get there eventually
<jdb[m]>
Someone in the list told earlier that it was stable for them, so I am optimistic
eirikkar has quit [Ping timeout: 480 seconds]
<valpackett>
jdb: lynxy: yeah, definitely try disabling aspm on the ssd
<valpackett>
yeah my factory ssd is also an SN740
<valpackett>
meanwhile, testing iris encoder: ffmpeg crashes, gstreamer works.. but the output is 720p (even when the entire gstreamer log says 1080p) at a low bitrate right now :D
<valpackett>
i don't test suspend power frequently heh but so far with the GPU IFPC series the actual runtime power use is lower
<valpackett>
4.8-5.2W with 10% brightness and Actually Doing Things (scrolling and typing and opening pages..)
<JensGlathe[m]>
Fun, that Ideapad 5 2in1 has a not-so hidden EC reset button
ursa-major has joined #aarch64-laptops
chrisl has joined #aarch64-laptops
ungeskriptet has joined #aarch64-laptops
chrisl has quit [Ping timeout: 480 seconds]
chrisl has joined #aarch64-laptops
maxboone has quit [Remote host closed the connection]
maxboone 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
ungeskriptet has quit [Remote host closed the connection]
ungeskriptet has joined #aarch64-laptops
chrisl has quit [Ping timeout: 480 seconds]
chrisl has joined #aarch64-laptops
ungeskriptet has quit [Remote host closed the connection]
ungeskriptet 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]
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]
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]
erebion has quit [Remote host closed the connection]
erebion_muc has joined #aarch64-laptops
chrisl has joined #aarch64-laptops
erebion_muc has quit []
erebion_muc 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]
chrisl has joined #aarch64-laptops
SpieringsAE has quit [Quit: SpieringsAE]
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]
chrisl has joined #aarch64-laptops
chrisl has quit [Ping timeout: 480 seconds]
chrisl has joined #aarch64-laptops
chrisl has quit [Ping timeout: 480 seconds]
mltemev[m] has joined #aarch64-laptops
<bylaws>
robclark: so for the bug I mentioned, I ended up testing kde and gnome, both are effected
<bylaws>
It's every xwayland app I think?
<bylaws>
But it doesn't happen initially
<mltemev[m]>
Hello
<bylaws>
Just at some random point after starting the system all xwayland applications will lag/have significant UI glitches
chrisl has joined #aarch64-laptops
<robclark>
hmm, is there some way to tell which apps are using xwayland?
<travmurav[m]>
set fractional scaling /s
<robclark>
heh
<robclark>
bylaws: also, does restarting the app(s) using Xwayland fix them? (idk, if restarting Xwayland would work, but that might be another thing to try to narrow down client vs server side)
chrisl has quit [Ping timeout: 480 seconds]
<smoorgborg[m]>
<robclark> "hmm, is there some way to tell..." <- @robclark: GNOME has an extension "XWayland Indicator"
<robclark>
ok, I'll try that
<Treibholz[m]>
or use xeyes :-)
<Treibholz[m]>
run xeyes, move your mouse-curse into the window, you suspect to run in xwayland. If the eyes look to window, it's Xwayland :-)
<robclark>
ok, so chromium and vscode seem to use Xwayland
<Treibholz[m]>
yes, you need to force them, to use wayland...
<bylaws>
Chromium works if I force vulkan
<Treibholz[m]>
for all electron-apps: --enable-features=UseOzonePlatform,WaylandWindowDecorations --ozone-platform=wayland
<bylaws>
Will try restarting xwayland though
<spawacz>
robclark: I invoke xwininfo and hover the mouse over the window. If the cursor chagnes to a crosshair then it's xwayland
<robclark>
bylaws: if you can reproduce it easily enough you could try commenting out DRIVER_SYNCOBJ_TIMELINE in msm_drv.c in kernel? (Not that that is really a good fix but might give us a hint.)
chrisl has quit [Ping timeout: 480 seconds]
chrisl has joined #aarch64-laptops
hightower3 has joined #aarch64-laptops
<bylaws>
robclark: didn't seem to change anything
<robclark>
hmm, ok
<robclark>
when this happens do you get anything in dmesg (gpu hangs, or other msgs)?
<bylaws>
Nothing in dmesg
chrisl has quit [Ping timeout: 480 seconds]
<robclark>
hmm, ok
hightower2 has quit [Ping timeout: 480 seconds]
hightower4 has joined #aarch64-laptops
<smoorgborg[m]>
New T14s BIOS is out on LENOVOs support page - it's version 2.20
<steev>
2.20 was released 05-19
<anthony25>
bylaws: sorry what is the bug?
ungeskriptet has quit [Remote host closed the connection]
<smoorgborg[m]>
Hmm, OK, it just says release date 18 july 2025 on their page
ungeskriptet has joined #aarch64-laptops
<steev>
yeah, i looked and even attempted to install here, and it says i already have it
<steev>
and if i go into my bios, sure enough, i have 2.20, and dated 5-19
<bylaws>
anthony25: If I launch anything using opengl under xwayland, launching chromium vulkan under xwayland immediately causes all opengl apps to slow to a crawl and exhibit significant glitching
<anthony25>
Jasper[m]: haha, no, and I don't know why I still click on the "comments" link when the number of comments seems big
<Jasper[m]>
Nah I understand, Wayland stuff got particularly bad because of the murmur around the Xorg fork
<\[m]>
you can really feel it in the vendor's attention -_-
<jdb[m]>
Treibholz: Do we know why such a difference between Debian and Ubuntu, for the X13s?
<Treibholz[m]>
jdb: I don't - I am not a big fan of ubuntu anyway, so once trixie was in soft-freeze, I switched.
<anthony25>
though I find Michael to be quite pessimistic about snapdragon laptops, like yeah ok kernel needs some patches, though the patches needed becomes more a quality of life than real necessity to boot the laptop
<anthony25>
and the dtb problem is not solved
<\[m]>
why he doesn't mention the power efficiency though - that's the key factor imo still
<anthony25>
because it's not really more efficient than recent AMD or Intel laptops on linux
<\[m]>
yet 🙂
<anthony25>
yeah exactly, that's why I say he's pessimistic on this topic
<jdb[m]>
Well, power efficiency matters a lot during suspend, and we are still far off the full potential from this platform at the moment
<\[m]>
also for the thinkpad t14s seems only snapdragon sku has the non glossy oled option
<robclark>
re: phoronix qc hating, qc is usually reasonably high in the git stats, and I suspect a good chunk of linaro's commits could be added to the qc column: https://lwn.net/Articles/1013892/
kjm99[m] has quit [Ping timeout: 480 seconds]
kjm99[m] has joined #aarch64-laptops
<robclark>
(and they miss the fact that much of the WIP stuff is board level stuff, not in qc's hands.. ie. they should be complaining to dell/lenovo/asus/etc
<robclark>
)
<anthony25>
idk, apple chips took quite some time, you can't run it on anything else than asahi, and he's more enthousiastic about improvements around macbooks support
<robclark>
but wtvr, I guess I need to stock up on pop corn
<robclark>
heh, true, I guess the stack of patches for apple is still quite a bit larger
<robclark>
but we do need to get distro ppl locked in a room to hammer out the dtb picking ;-)
<\[m]>
to me hte power efficiency is more about heat generation, but I'm no expert if that's going to be a real diff in terms of fan speeds
<\[m]>
at least asahi didn't die after the kernel upstream drama, I guess that userbase is still smaller ? the cpus are superior afaict
<Treibholz[m]>
i got weak and bought a mac mini again, when there was a good offer at prime week...
<robclark>
I still would be curious about how apple compares with 4k pages, I guess they lose some of the advantage
<\[m]>
m4?
<Treibholz[m]>
yes. no asahi, yet. But I can use my 3 4k displays and use podman machine to build my kernel...
hightower3 has joined #aarch64-laptops
<Treibholz[m]>
its faster, more silente and needs less power than my ryzen5 5600x workstation here... (but with less ram an storage...)
chrisl has joined #aarch64-laptops
hightower4 has quit [Ping timeout: 480 seconds]
<\[m]>
what are those hacked packages of ubuntu then, that are so fundamental to a working system?
<Jasper[m]>
Likely firmware and kernel
<Treibholz[m]>
ubuntu-x13s-settings and ubuntu-x13s-settings-nogrub
<anthony25>
I guess the custom grub script to select the dtb, firmware and kernel
<Jasper[m]>
That seems like the only obvious ones
<Jasper[m]>
Ah
<\[m]>
asahi seems to have ushered in a year of stabilisation and getting good processes for upstreaming whatnot though not been following much
<\[m]>
the cool new stuff might take a while though
<jdb[m]>
The amount of duplication in between dts files is also concerning, usually we try to find ways to avoid code duplication
<jdb[m]>
But I agree that the vendors don't contribute much, they clearly focus on Windows support only / mostly
<jdb[m]>
It would be great to have a few vendors supporting officially Linux on a next generation QC-based product
<Treibholz[m]>
the x13s is completely unuseable on windows, as soon as you want to use any other program than a browser. almost nothing has native binaries.
<Treibholz[m]>
the x86 emulation is horrible
<jdb[m]>
Is it that bad really?
<Treibholz[m]>
yes
<HdkR>
Don't worry, the x86 emulation is horrible on Linux as well.
<jdb[m]>
Like you divide the perf by 2?
<Treibholz[m]>
HdkR: I don't need emulation in linux
<Treibholz[m]>
jdb: more by 4
<jdb[m]>
That seems ... a lot
chrisl has quit [Ping timeout: 480 seconds]
<HdkR>
Sounds about right actually.
<\[m]>
you run in docker for some binaries?
<Treibholz[m]>
jdb: I have not made any benchmarks, just "feeling"
<jdb[m]>
But as you said, on Linux we don't need emulation for open source software
<Treibholz[m]>
\: no. If there are no arm64 images, I build them myself or don't use the software.
<Treibholz[m]>
also I prefer podman, because it doesn't require root and no daemon.
<\[m]>
yeah same though it can get annoying no root
chrisl has joined #aarch64-laptops
<steev>
jdb[m]: if i had to guess, it's less services running on debian
chrisl has quit [Ping timeout: 480 seconds]
<Treibholz[m]>
no, really disk-io (or nvme-io) was horrible on ubuntu.
<Treibholz[m]>
CPU was almost identical.
<Treibholz[m]>
even with hdparm -tT
<steev>
using jhovold's kernel or using debian's (which doesn't include anything that isn't in mainline)
<Treibholz[m]>
it was also faster with standard debian. now I use a standard debian config, BUT jhovold patch.
<steev>
yeah, that's pretty much what i do here (though, kali, so debian testing)
<deathmist>
robclark: dtbloader? so far can be included with systemd-boot + dtbs in ESP of live images (hopefully soon drop-in EFI drivers also will be available on Limine which is of interest for me with Chimera Linux using it for liveiso) and then copied to ESP etc when installing the OS. even then needs distro willingness to ship it on aarch64 liveiso ESP
<robclark>
right.. we have the technology.. we just need distro's to deploy ;-)
<deathmist>
would be nice if providing dtbname and fixups alone without giving the bootloader a whole dtb was an option somehow which otherwise has to be picked from a pre-defined (not per-kernel) location currently. I just copy latest timestamp dtbs to the ESP path but already got bit by this once figuring out why my older known-working kernels didn't boot anymore either
<robclark>
yeah, we just probably need to yell more on list about dtb breaks ;-)
<robclark>
kernel probably needs a way to mark WIP bindings as "staging" so distro's don't install them
chrisl has joined #aarch64-laptops
<deathmist>
that was actually a problem from my end, I was testing some patches from the lists which caused dtb issues both with the new kernel and the old ones since all the per-kernel entries in systemd-boot still all kept loading the same dtbloader-provided dtb which was broken instead of the older known-working ones I also had around but in per-kernel paths :p
<deathmist>
UKIs with modern systemd-boot are also an option with automatic multi-DTB picking capabilities but I don't think it does fixups by itself like dtbloader nor am I sure how many distros would be willing to use either sysd-boot/UKIs for aarch64 live ISO or post-install aside from DIY ones where the user makes all the choices anyway
<robclark>
I guess one way to look at it is that dtb should be part of the "firmware" just like ACPI tables are.. and if you are testing broken fw, then you should have a recovery plan ;-)
<deathmist>
or the best option yet... Qualcomm instead "just" gives us proper generic ACPI (just like EL2 boot, eh?) so we don't have to even think about the PEP drivers or must write new devicetrees for each specific laptop model at all if we don't want to just for the OF hackability or otherwise ;)
<robclark>
or "just" write PEP support for linux, I assume if linux supported qc would contribute the SoC specific PEP driver (this is overlooking all of the existing driver dependencies on of_xyz/dtb.. but with enough typing that could be solved)
chrisl has quit [Ping timeout: 480 seconds]
<anthony25>
as the dtb is written in parallel with the drivers, so without the drivers already written for an OS using the dtb, how can the dtb be defined?
<anthony25>
if we would take the current state of qcom laptops, for example
<robclark>
usually there aren't completely new drivers which need completely new bindings.. but yeah, when the dtb is still WIP it should be marked as such so distro's don't get themselves into trouble
<robclark>
for early adopters, copying a dtb file or editing grub menu isn't such a big problem
chrisl has joined #aarch64-laptops
<robclark>
but distros should have an upgrade path that doesn't "brick" someones laptop (at least from end user's PoV if the device doesn't boot because dtb is b0rkd it is "bricked")
<anthony25>
yeah I agree, I was talking about the solution of the dtb being part of the firmware
<anthony25>
which seems to be a chicken and egg problem unless the device is fully supported by the manufacturer on linux from the start
<robclark>
yeah, as long as we are using dtb there will be a bringup phase.. but all the core SoC and driver stuff should be enabled before devices ship to consumers (maybe not quite there yet, but getting closer).. leaving just the remaining board level dtb
<tobhe[m]>
I suppose in theory if the dtb was purely describing hardware structure/layout and not logic the dtb design and implementation would be entirely independent steps
<deathmist>
robclark: maybe there's a chance if other upcoming WoA SoC vendors (NVIDIA and AMD at least) will also use PEP for providing important ACPI bits, but if it ends up being a Qualcomm+Linux exclusive proposed thing I'm not sure it'd ever get considered upstream
<robclark>
in theory.. people do sometimes bikeshed things (which amusingly, they couldn't really do if vendors shipped the dtb)
<robclark>
AFAIU AMD does already use _some_ PEP (but I guess in ways that can be ignored).. I kinda expect it to become a bigger problem as time goes on
<tobhe[m]>
is there an official PEP spec or standard or is it entirely defined by the windows implementation?
<robclark>
ms has some docs.. it basically hooks in to implement some acpi calls
<robclark>
so rather than writing all your clk/interconnect/power type platform drivers in aml you can implement them in a real language
chrisl has quit [Ping timeout: 480 seconds]
<tobhe[m]>
right, and they probably also are kernel modules of some sort that use whatever windows APIs are available?
<robclark>
tobhe[m]: yeah, I kinda like the clk/icc/etc drivers, it could be a module but probably would need to be in initrd
<robclark>
deathmist: well I guess x1 is at least closer to that than apple ;-)
chrisl has quit [Ping timeout: 480 seconds]
chrisl has joined #aarch64-laptops
HellDuck[m] has quit [Ping timeout: 480 seconds]
ahoneybun[m] has quit [Ping timeout: 480 seconds]
kjm99[m] has quit [Ping timeout: 480 seconds]
albsen[m] has quit [Ping timeout: 480 seconds]
konradybcio has quit [Ping timeout: 480 seconds]
anonymix007[m] has quit [Ping timeout: 480 seconds]
M9names[m] has quit [Ping timeout: 480 seconds]
steveej[m] has quit [Ping timeout: 480 seconds]
apple-corps[m] has quit [Ping timeout: 480 seconds]
amstan has quit [Ping timeout: 480 seconds]
binarycraft[m] has quit [Ping timeout: 480 seconds]
dcavalca has quit [Ping timeout: 480 seconds]
angeloverlain[m] has quit [Ping timeout: 480 seconds]
saladman[m] has quit [Ping timeout: 480 seconds]
AzkaliManad[m] has quit [Ping timeout: 480 seconds]
clover[m] has quit [Ping timeout: 480 seconds]
owen[m] has quit [Ping timeout: 480 seconds]
sungold[m] has quit [Ping timeout: 480 seconds]
JensGlathe[m] has quit [Ping timeout: 480 seconds]
Douloureux[m] has quit [Ping timeout: 480 seconds]
Leandro[m] has quit [Ping timeout: 480 seconds]
chapstikk[m] has quit [Ping timeout: 480 seconds]
KieranBingham[m] has quit [Ping timeout: 480 seconds]
strongtz[m] has quit [Ping timeout: 480 seconds]
TangTang[m] has quit [Ping timeout: 480 seconds]
Jasper[m] has quit [Ping timeout: 480 seconds]
WeetHet[m] has quit [Ping timeout: 480 seconds]
AlekseiNosachev[m] has quit [Ping timeout: 480 seconds]
Timmy[m] has quit [Ping timeout: 480 seconds]
freekurt[m] has quit [Ping timeout: 480 seconds]
logan2611 has quit [Ping timeout: 480 seconds]
jdb[m] has quit [Ping timeout: 480 seconds]
matheustura[m] has quit [Ping timeout: 480 seconds]
genius1237[m] has quit [Ping timeout: 480 seconds]
Eighth_Doctor has quit [Ping timeout: 480 seconds]
mltemev[m] has quit [Ping timeout: 480 seconds]
travmurav[m] has quit [Ping timeout: 480 seconds]
Badhri[m] has quit [Ping timeout: 480 seconds]
\[m] has quit [Ping timeout: 480 seconds]
noisycoil[m] has quit [Ping timeout: 480 seconds]
Treibholz[m] has quit [Ping timeout: 480 seconds]
macc24 has quit [Ping timeout: 480 seconds]
tobhe[m] has quit [Ping timeout: 480 seconds]
McCak[m] has quit [Ping timeout: 480 seconds]
Hugo[m]1 has quit [Ping timeout: 480 seconds]
cenunix[m] has quit [Ping timeout: 480 seconds]
Meti[m] has quit [Ping timeout: 480 seconds]
JosDehaes[m] has quit [Ping timeout: 480 seconds]
smoorgborg[m] has quit [Ping timeout: 480 seconds]
farchord has quit [Ping timeout: 480 seconds]
kuruczgy[m] has quit [Ping timeout: 480 seconds]
GurneyBuchanan[m] has quit [Ping timeout: 480 seconds]
shadowarrior[m] has quit [Ping timeout: 480 seconds]
osmoz[m] has quit [Ping timeout: 480 seconds]
alexVinarskis[m] has quit [Ping timeout: 480 seconds]
nirik has quit [Ping timeout: 480 seconds]
mehdidjait[m] has quit [Ping timeout: 480 seconds]
bumble[m] has quit [Ping timeout: 480 seconds]
[UNAVAILABLEUSER][m] has quit [Ping timeout: 480 seconds]
n0nfl3x[m] has quit [Ping timeout: 480 seconds]
Tammieyem[m] has quit [Ping timeout: 480 seconds]
zaktur[m] has quit [Ping timeout: 480 seconds]
life00[m] has quit [Ping timeout: 480 seconds]
sadan[m] has quit [Ping timeout: 480 seconds]
blue_alex[m] has quit [Ping timeout: 480 seconds]
valpackett has quit [Ping timeout: 480 seconds]
chrisl has quit [Ping timeout: 480 seconds]
sally has quit []
<bamse>
deathmist: i don't remember the exact wording we put there, but there's a fair amount of work left to be able to express our systems in ACPI and for us to express our systems in ACPI in a way where we could consume it in Linux...
chrisl has joined #aarch64-laptops
<deathmist>
I'll check again when X5 is out I guess, surely by then the 10+ MiB of gray area firmware extracted from windows which legally cannot be upstreamed to linux-firmware per each device model also won't be an issue anymore :p
chrisl has quit [Ping timeout: 480 seconds]
<tobhe_>
tbh PEPs do sound a lot like a hack to get a dtb like model with ACPI
<HdkR>
Or is dtb a hack to get a PEP like model with ACPI? :P
<tobhe_>
I think you're on to something
<deathmist>
if ACPI Linux won't do for a while still it does make me wonder how exactly they're planning on making Linux boot/support less painful on X2 over X1, we do have all these "fun" quirks and potentially lack of EL2 booting (outside windows) altogether to look forward to after all
chrisl has joined #aarch64-laptops
chrisl has quit [Ping timeout: 480 seconds]
chrisl has joined #aarch64-laptops
chrisl has quit [Ping timeout: 480 seconds]
<deathmist>
kuruczgy: speaking of EL2, dropping dtbloader while keeping slbounce setup on systemd-boot + trying 6.15/6.16 with the EL2 dtbs again didn't seem to change anything, just blank display soon after reaching initrd with functional ctrl+alt+del reboot. maybe I need the lite fw patch to do anything, will mess around again tomorrow
<tobhe_>
deathmist: out of interest, are you using the .dtbauto functionality? Have you tried adding all of the x1* dtbs?
<deathmist>
I previously tried it but I'm not using it anymore, seemed to work fine minus the fixups ig which now at least SP11 (of X1 devices) would want for the DPP MAC provisioning
<tobhe_>
ic. when I tested it seemed to just get stuck when I added all of them, I'm wondering if others are experiencing the same. Maybe I'm just holding it wrong