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
<enyalios> steev: oh thats going to be fun to navigate when binutils updates
<steev> i'm sure there will be a fix by 2.43
strongtz[m] has joined #aarch64-laptops
<strongtz[m]> Jos Dehaes: There's no tplg firmware in Windows, the only equivalent is ACDB. You need to generate your own based on this: https://git.codelinaro.org/linaro/qcomlt/audioreach-topology
<steev> ah, it is the acdb
<steev> i wasn't sure if it was acdb or rcds or whatever
sera[m] has joined #aarch64-laptops
<sera[m]> <robclark> "btw, could other who have yoga..." <- have the same panel too, identical edid
<steev> weird, i got the cma thing again when waking up from sleep, but wifi definitely working this time
<steev> fwiw, it's only 9 hours of uptime
<JensGlathe[m]> no cma messages on wakeup here
<JensGlathe[m]> Ubuntu config sets CMA region to 128 MiB
<steev> i don't get it every time, just the second time i'm noticing
<steev> and cma is also set to 128 in johan's config
<steev> it also has only been happening since 6.10
<craftyguy> Has anyone had trouble waking from s2idle on the x13s with 6.10? Sometimes the internal display doesn't wake/backlight stays off while I _think_ the rest of the system is awake (but haven't figured out how to confirm that since I can't see anything)
<steev> enable ssh and ssh in?
<steev> do you have an external display plugged in ?
<craftyguy> no external display
<craftyguy> yeah I'll try SSH/poking around the next time it happens. usually it's at a coffee shop or some place where I can't really SSH in
<steev> i haven't seen that here, unfortunately, at least not yet
<jhovold> craftyguy: does the display come back if you suspend again?
<craftyguy> not sure, I can't get it to suspend again (I don't have it configured to suspend automatically when lid is closed, for example)
<craftyguy> I could try to enable that so I'd be able to try it next time
<jhovold> ok, probably won't help
<jhovold> bryanodonoghue reported a stuck clock off list with rc5, may be what you're hitting, and then he display would be hosed
<jhovold> still waiting for bryanodonoghue to provide some more details, but could be another drm regression
<jhovold> a log would tell if you could get one
<craftyguy> ok, I'll try to get a log the next time it happens
<jhovold> maz: just gave your patch a spin and it does seem to fix the MSI regression here, these machines use msi-map
<maz> jhovold: great, thanks for confirming. feel free to add a tested-by: on the list so that tglx picks it up when he reappears.
<jhovold> just did
<maz> cheers.
smpl has joined #aarch64-laptops
<bryanodonoghue> jhovold
<bryanodonoghue> [49301.294387] disp0_cc_mdss_dptx1_link_clk status stuck at 'off'
<bryanodonoghue> I took a quick look but if I remember right the parent ? clock "parks"
<bryanodonoghue> and that clock ... let me check
<bryanodonoghue> is rcg2
<jhovold> bryanodonoghue: first I need to know what you did when you hit this
<bryanodonoghue> for me this was about plugging and unplugging a type-c hdmi dongle
<bryanodonoghue> just typing
<jhovold> ok, so unrelated to craftyguy
<jhovold> craftyguy's issue
<jhovold> probably best to report it to the drm devs as hotplug is known to be broken in the msm drm driver
<jhovold> well, some of these code paths are involved also for the eDP so I guess it could still be related the resume issue craftyguy reported
<bryanodonoghue> I think the problem I reported there is in the definition of the dptx clock
srinik has joined #aarch64-laptops
<Jasper[m]> may explain some of the issues that are left after fw version .41
<JensGlathe[m]> WiFi Power Management is the culprit?
JoshuaAshton has quit [Remote host closed the connection]
JoshuaAshton has joined #aarch64-laptops
smpl has quit [Ping timeout: 480 seconds]
Lucanis has quit [Ping timeout: 480 seconds]
Lucanis has joined #aarch64-laptops
Caterpillar has joined #aarch64-laptops
Adam[m] has joined #aarch64-laptops
iivanov_ has joined #aarch64-laptops
iivanov has quit [Ping timeout: 480 seconds]
martiert has joined #aarch64-laptops
lollaritits[m] has joined #aarch64-laptops
<lollaritits[m]> <steev> "i'm hoping for someone to get..." <- i just wait for the gaming kiddies to buy one. notice not all their games run and then sell it for cheap somewhere.
<lollaritits[m]> please windows fuck up in terms of gaming
<lollaritits[m]> so i can get a cheap T14s
<FarchordSteveCossette[m]> lollaritits[m]: Well I know I saw quite a few ytbers say that gaming on the vivobook is very very "meh"
<FarchordSteveCossette[m]> until there's native arm builds of said games at least
<Adam[m]> A friend with one says it’s “fine”
<Adam[m]> I suspect the biggest issue will be the fact Prism doesn’t support kernel components
<Adam[m]> So games that use Kernel level anti cheat are unlikely to work
<HdkR> Which is why HellDivers 2 works on Linux but not Windows
iivanov_ has quit [Remote host closed the connection]
iivanov has joined #aarch64-laptops
<Jasper[m]> HdkR: Isn't that technically just because of AVX? (Congrats btw)
<HdkR> nprotect gameguard should have kernel components on Windows which are disabled on Linux. But AVX is another problem :D
<\[m]> I wouldn't hope for gamers to yolo buy a t14s lol
<FarchordSteveCossette[m]> \[m]: Yeeeah not a good idea. lol
<FarchordSteveCossette[m]> Mind you there's already a way to run x86_64 windows apps on arm it sems
<Adam[m]> Prism, I mentioned it just then 
<Adam[m]> But it doesn’t support Kernel level components, only user space
<FarchordSteveCossette[m]> Oh, I was talking more about hangover
<FarchordSteveCossette[m]> Maybe that's the same thing idk
<Adam[m]> Ah, sorry, you meant Windows x86 on Linux?
<Adam[m]> Gotcha
<Adam[m]> I mix up Fex, box64 and all those all the time
<HdkR> There's a bunch of software, depends on what you're trying to accomplish
<Adam[m]> Too many :D
<FarchordSteveCossette[m]> tl;dr: I play a 20+ year old MMO using Wine lol I was curious if it would run on arm on Linux lol
<FarchordSteveCossette[m]> I guess I'll work on getting Linux booted, and THEN ill see about gaming on it XD let's keep proper priorities lol
<Jasper[m]> <HdkR> "nprotect gameguard should have..." <- Oh! Didn't know Helldivers 2 had a Linuc release.
<Jasper[m]> Nevermind then
<HdkR> Jasper[m]: Nah, they just detect Wine
<\[m]> what mmo might that be then??
<Jasper[m]> HdkR: Interesting
<lollaritits[m]> one usb-c ports displayport randomly stopped working for me is there any way to debug this?
<FarchordSteveCossette[m]> <\[m]> "what mmo might that be then??" <- Final Fantasy XI. On a private server XD
<lollaritits[m]> what was needed for getting DRM to work?
kalebris has quit [Quit: ZNC 1.9.0 - https://znc.in]
tobhe_ is now known as tobhe
smpl has joined #aarch64-laptops
<bluerise_> But... but... Linux will never be able to run with ACPI on this thing. Is it supposed to boot with FDT and then use the ACPI tables for that info?
bluerise_ is now known as bluerise
<Jasper[m]> bluerise_: Interesting
<Jasper[m]> bluerise_: I guess so
kalebris has joined #aarch64-laptops
<bluerise> oh my god this platform is cursed
<travmurav[m]> fun fact, if you boot with acpi on "sane" platforms, efistub still creates an almost empty fdt to pass the uefi pointers to the kernel, linux //always// boots with dt on aarch64 :P
<bluerise> OpenBSD does the same
<bluerise> efiboot crafts a DTS with basic info for handover
<robclark> bluerise: it would be desirable if basic boot (and possibly wifi) worked with acpi boot, so distro installer would work and user could get far enough to install and then check for updates (which would presumably switch over to dtb).. but "don't put it in dt because it is in acpi" is nonsense
<travmurav[m]> pretty sure Linux completely disables acpi interpreter as soon as it smells that dt has anything but the uefi pointers
<bluerise> robclark: yeah, that's why we added basic ACPI support for that laptop, so people can install and the installer automatically downloads and switches over to DTs for next reboot
<bluerise> Ah well, I'll just wait for another year until people got the bikeshed painted on all side :-)
<Eighth_Doctor> robclark: it'd be even more desirable if having a dt didn't disable acpi
<Eighth_Doctor> then we could have supplementary dts instead of requiring it for everything
<Eighth_Doctor> could treat dts like we treat acpi quirks for x86
<robclark> yeah.. but in practice not sure how that could work, it is largely an either/or currently
<robclark> bluerise: I wouldn't worry about what Jeff has to say about acpi.. bamse is the one who would pick up the dts patch
<Eighth_Doctor> robclark: why aren't you sure how that could work?
<konradybcio> you can't have two firmwares describing the base platform with possibly conflicting information
<travmurav[m]> <del>did anyone even figure out how to map gpio numbers from acpi to hw yet?</del>
<bluerise> travmurav[m]: try every single one until you find one that works
<konradybcio> subscribe to all of them as interrupt providers and binsearch /s
<FarchordSteveCossette[m]> That sounded like "Throw everything at the wall and see what sticks" lol
<travmurav[m]> world when you can auto-discover fixed-regulator gpio outputs: space_age.jpg
* FarchordSteveCossette[m] wonders how long it takes for Asus to ship his laptop.... it has been 1.5 days. Lack of patience ftl.
<lollaritits[m]> are you me?
<FarchordSteveCossette[m]> <lollaritits[m]> "are you me?" <- Probably. Not especially looking to prove it though!
<FarchordSteveCossette[m]> XD
<broonie> Eighth_Doctor: ACPI has it's own quirking mechanisms, (including loading additional overlays at runtime IIRC).
<Eighth_Doctor> can that be used to fill in things that are missing?
<Eighth_Doctor> rather than acpi->dt switching
<Eighth_Doctor> or is it too limited for that?
<robclark> well, it is kinda 90% missing (ie. no PEP driver, no PEP support in linux ACPI implementation) rather than just some quirks
<travmurav[m]> and iirc even with that, there are per-board versions of the pep driver so you literally can't know some things at all?
<Eighth_Doctor> :(
<Eighth_Doctor> why does everything suck?
<travmurav[m]> like at this point, if the goal for the thing to "just work" it's really just easier (as in human-hours spent) to autodetect and load the dtb somehow, whether as part of the distro iso or as a manual action retrofit
<broonie> ACPI really has a strong model for how the system will look, you really have to design things from the silicon up to use ACPI idiomatically.
<konradybcio> robclark i was told some windows drivers nowadays ship their own acpi overlays on x1
<robclark> that is.. a bit terrifying
<robclark> but what board level things would effect the PEP driver? Choosing different PMICs?
<robclark> could we have a PEP driver that itself used dt for this configuration.. basically just a shim for clk/gdsc/icc type stuff?
<robclark> (that is completely ignoring that we have no ACPI based answer to things like how panel is wired up, and probably other similar things in other subsystems.. but I guess if we solved the PEP thing, then those other things become worth solving)
<travmurav[m]> I think konradybcio mentioned different pmic configuration will have different pep driver at some point in this room, yeah
<konradybcio> i dont think i did
<travmurav[m]> maybe I understood it wrong back then
<konradybcio> well iiuc there is some pmic specifics, but windows probably does a better job abstracting this away
<travmurav[m]> but well, in any case, as I understand it, to gain acpi support, even if pep is sorted, there needs to be an insane amount of human hours to integrate that into all the drivers, and even just for the gpio numbers it seems to be an absolute mess
<travmurav[m]> which makes me wonder if those human hours are really worth it?
<konradybcio> no
qzed has joined #aarch64-laptops
<qzed> robclark: tbh I think you ideally have some kind of declarative language to describe the PEP stuff... in the Windows driver it's all hard-coded C structs by the looks of it (or they do some automated conversion from xml/whatever to C)
<qzed> so if one can use DTs for that... that would be quite useful
<robclark> I'd laugh if they generate that from dt :-P
checkfoc_us has quit []
checkfoc_us has joined #aarch64-laptops
<robclark> konradybcio, srinik: so.. what would I be looking for in acpi dump for panel enable gpio? re: https://lore.kernel.org/lkml/CAD=FV=WJQBTjt61ma-CoJQeGYKigEyXpA6j25JSyEfikrLeSNQ@mail.gmail.com/
<konradybcio> robclark, without engaging brain cells, try copying crd and seeing if it works ootb
<konradybcio> vendors are lazy 9/10 times
<konradybcio> well.. sometimes it's lazy, sometimes it's smart
<konradybcio> if it ain't broke, don't fix it (the design..)
<robclark> would be nice to have the crd acpi tables for reference
<robclark> if someone could push those, that would be swell :-)
<konradybcio> i can only say the same..
<qzed> robclark: on the SPX it's in an ACPO PEP resource, part of a ton of other stuff... so might be tricky to find if you don't know which pin exactly you're looking for
<robclark> so, turned out copying crd did work, so I guess I'm saved from reading dt
<sgerhold> robclark: maybe check the /sys/kernel/debug/gpio state of the enable gpio without the DT changes and see if the bootloader pre-configured that gpio to out high
<sgerhold> and medium drive-strength if it's the same as crd
<travmurav[m]> fwiw I was taking x1 firmware blobs from here, I'd guess with some manual work, could extract acpi from it too... https://github.com/WOA-Project/Qualcomm-Reference-Drivers/blob/master/8380_CRD/200.0.29.0/qcfirmware8380_CRD_NVME.cab
<qzed> I'm wondering though: at which point/with which assumptions would ACPI PEP support become feasible... without it some DT work will always be required, with PEP/ACPI driver support it ideally should only be once-per-SoC work
iivanov has quit [Quit: Leaving...]
<qzed> and for future pin reference: looking for 'TLMMGPIO' or 'PMICGPIO' in the DSDT brings up the relevant config entries, those are associated with devices (e.g. there's a package for _SB.GPU0), device states (e.g. 'FSTATE' 0), and transitions (e.g. 'ENTER')
<qzed> so you can check there which GPIOs are enabled for which device and which state
<qzed> but each GPIO config is specified as some package, so you need to figure out how that works exactly... all I know is that the first field is the pin number
<robclark> sgerhold: I'll check that a bit later.. but defn the bootloader was leaving the screen on
<robclark> qzed: yeah, I saw a _bunch_ of TLMMGPIO and PMICGPIO (but it was somewhat all jibberish to me ;-))
<craftyguy> jhovold: I'm trying to reproduce the issue I reported earlier, naturally it's not happening since I'm looking for it :P
<craftyguy> anyways, I noticed these errors in the log when resuming (shows for ports 2, 3, 4): dwc3-qcom a4f8800.usb: port-2 HS-PHY not in L2
<craftyguy> not sure if those are known or something new
srinik has quit [Ping timeout: 480 seconds]
<abelvesa> robclark: since you seem to be using my kernel tree for you laptop, please pull as I pushed a new one today
<abelvesa> robclark: plan to stop maintaining that tree after rc1, BTW
<robclark> ok.. I'll rebase in a bit.. I assume/hope after -rc1 that we don't really need a linux-next based branch, but haven't really been keeping track of what has landed and what has not
<robclark> sgerhold: confirmed that gpiochip3 state was same with panel-edp vs using the crd setup
<abelvesa> after rc1, jhovold tree will be the best one to use. I'll switch to his myself as well
<robclark> ok, sg
<robclark> I'll have some patches for yoga display shortly
<abelvesa> cc me as well, please
<robclark> will do
<robclark> also, https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30249 will let us drop the chip-id hack, it should be in mesa 24.2.x which will branch tomorrow
<abelvesa> nice, need to update mesa on my CRD then. Thanks!
<HdkR> \o/
<HdkR> I should send an update for nvtop as well
<HdkR> Once I confirm that actually works anyway
<abelvesa> does anyone here have the t14s ?
<HdkR> Most people waiting for the customize option on that
<steev> there are a couple though
<robclark> abelvesa: I think gabertron has one
agl has quit [Ping timeout: 480 seconds]
agl has joined #aarch64-laptops
<FarchordSteveCossette[m]> w00t my laptop shipped, it shipped from Ontario, so I should get it tomorrow!
<robclark> \o/
* Eighth_Doctor still wants one but can't afford to spend the money
<HdkR> Getting this Yoga Slim 7x that I have setup finally
<robclark> other than the PgUp/PgDn fiasco, I think I kinda like the slim kb better than x13s.. somehow it feels more comfortable.. maybe just because it is a bit bigger
agl has quit [Quit: ZNC 1.8.2+deb3.1+deb12u1 - https://znc.in]
<HdkR> Oh cool, full CPU load on the Yoga clocks the CPU cores down to 1.9/2.0Ghz
agl has joined #aarch64-laptops
<HdkR> Cute little dual fan arrangement in the thing
<HdkR> Definitely can't wedge a double-sided 2242 drive in to the thing this time around
<FarchordSteveCossette[m]> <HdkR> "https://cdn.discordapp.com/..."; <- Ahh, I do appreciate the hardware naughty bits...
hexdump0815 has joined #aarch64-laptops
<HdkR> I'd take off the cooling system to get a bare die shot but I don't feel like pulling out new thermal paste right now
<HdkR> and it's just going to look like an 8cxG3 anyway
<HdkR> What kernel should I use on the Yoga Slim 7x currently?
<robclark> for next few days I guess abelvesa's -next branch
<HdkR> Coolio, backing up the Windows drive atm
<konradybcio> robclark have you started poking at win command traces by chance?
<konradybcio> everybody's turbo interested in what this gpu even is
<konradybcio> and perhaps what it isn't