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
jhugo has quit [Quit: Connection closed for inactivity]
iivanov has joined #aarch64-laptops
iivanov has quit [Ping timeout: 480 seconds]
iivanov has joined #aarch64-laptops
iivanov has quit [Ping timeout: 480 seconds]
iivanov has joined #aarch64-laptops
iivanov has quit [Ping timeout: 480 seconds]
hexdump0815 has joined #aarch64-laptops
hexdump01 has quit [Ping timeout: 480 seconds]
ektor5 has quit [Server closed connection]
ektor5 has joined #aarch64-laptops
alfredo has joined #aarch64-laptops
iivanov has joined #aarch64-laptops
pbsds has quit [Server closed connection]
pbsds has joined #aarch64-laptops
iivanov has quit [Ping timeout: 480 seconds]
abcdw_ has joined #aarch64-laptops
abcdw has quit [Server closed connection]
abcdw_ is now known as abcdw
dubiousness has quit [Server closed connection]
dubiousness has joined #aarch64-laptops
kuruczgy has quit [Server closed connection]
kuruczgy has joined #aarch64-laptops
indy has quit [Server closed connection]
indy has joined #aarch64-laptops
iivanov has joined #aarch64-laptops
iivanov has quit [Ping timeout: 480 seconds]
todi has quit [Server closed connection]
todi has joined #aarch64-laptops
kettenis has quit [Server closed connection]
kettenis has joined #aarch64-laptops
anarsoul has joined #aarch64-laptops
anarsoul|2 has quit [Read error: Connection reset by peer]
iivanov has joined #aarch64-laptops
agraf has quit [Server closed connection]
agraf has joined #aarch64-laptops
alfredo has quit [Ping timeout: 480 seconds]
<jhovold> robclark: thanks, I'll probably drop the gpu id hack next week, hopefully arch will ship the new mesa by then
hightower2 has quit [Server closed connection]
hightower2 has joined #aarch64-laptops
akaWolf has quit [Server closed connection]
akaWolf has joined #aarch64-laptops
ema has quit [Server closed connection]
ema has joined #aarch64-laptops
KieranBingham[m] has quit [Server closed connection]
KieranBingham[m] has joined #aarch64-laptops
Nios34[m] has quit [Server closed connection]
Nios34[m] has joined #aarch64-laptops
\[m] has joined #aarch64-laptops
<\[m]> seems they have put now a real configurability for the t14s - but still no higher cpu
<HdkR> Dang, I don't have configuration in the US yet
alfredo has joined #aarch64-laptops
JosDehaes[m] has quit [Server closed connection]
JosDehaes[m] has joined #aarch64-laptops
alfredo has quit [Ping timeout: 480 seconds]
TSIN[m] has quit [Server closed connection]
TSIN[m] has joined #aarch64-laptops
bluerise_ has quit [Server closed connection]
bluerise has joined #aarch64-laptops
martiert_ has quit [Server closed connection]
martiert_ has joined #aarch64-laptops
hexdump0815 has quit [Ping timeout: 480 seconds]
tobhe has quit [Server closed connection]
tobhe has joined #aarch64-laptops
Kelsar has quit [Server closed connection]
Kelsar has joined #aarch64-laptops
hexdump0815 has joined #aarch64-laptops
<kuruczgy[m]> I am having issues with the battery status on my yoga. `cat /sys/class/power_supply/qcom-battmgr-bat/charge_now` gives "Resource temporarily unavailable".
<kuruczgy[m]> Did anyone encounter this? Any tips for where I should start with debugging this one?
iivanov_ has joined #aarch64-laptops
iivanov has quit [Remote host closed the connection]
iivanov has joined #aarch64-laptops
iivanov_ has quit [Read error: Connection reset by peer]
<travmurav[m]> What about energy_now?
<travmurav[m]> kuruczgy: I think that driver exposes both amps and watts hours but only allows reading one depending on the firmware
<abby> yeah use energy_*
<kuruczgy[m]> <travmurav[m]> "kuruczgy: I think that driver..." <- Nope, none of energy_now, power_now or voltage_now work
<travmurav[m]> Capacity doesn't work either I guess?
<travmurav[m]> Perhaps adsp is not booted?
<kuruczgy[m]> travmurav[m]: I don't have any capacity files
<kuruczgy[m]> travmurav[m]: How do I check that? I don't see any errors when grepping dmesg for adsp
<travmurav[m]> It would be "remoteproc"
<travmurav[m]> I think there is something in sysfs
<travmurav[m]> class/remoteproc/???/state
<travmurav[m]> Which would only work if you have the firmware extracted from windows
<travmurav[m]> Aadsp would work that is
<kuruczgy[m]> travmurav[m]: /sys/class/remoteproc is empty, so this seems like the issue then. No dmesg remoteproc errors though.
<travmurav[m]> Any messages for remoteproc at all?
<travmurav[m]> It should at least say they're "available " I think
<travmurav[m]> But yes, you need the adsp cpu to run which is what runs battmgr software
<kuruczgy[m]> travmurav[m]: Nope, `dmesg | grep -i remoteproc` is empty.
<kuruczgy[m]> Is this gonna be one of those module in initramfs issues again? I had to remove ath12k from initramfs because it was trying to load the firmware too early. (I only have firmware in rootfs)
<kuruczgy[m]> What are the kernel modules involved with the adsp?
<travmurav[m]> something_something_pas
lollaritits[m] has quit [Server closed connection]
lollaritits[m] has joined #aarch64-laptops
<kuruczgy[m]> Ant it's not qcom_q6v5_pas, because I was told that one needs to be blacklisted, right?
<travmurav[m]> It's the one
<kuruczgy[m]> 🤦 Then I guess "it needs to be blacklisted" is outdated info
<travmurav[m]> Well I recall there was something horribly broken recently I guess?
<travmurav[m]> But yes this is what boots the hexagons
<travmurav[m]> So no hexagons = no battmgr
<kuruczgy[m]> And what is qcom_edac btw, that's the other one I have blacklisted?
<travmurav[m]> (And some USB bits too nowadays?)
<kuruczgy[m]> travmurav[m]: Yeah, now it makes sense, I will try to unblacklist it
<kuruczgy[m]> Ok now it boots and I have both remoteproc 0 and 1 in /sys/class/remoteproc, but both are still offline. Now I will try removing the module from initramfs.
<travmurav[m]> kuruczgy: do you have firmware?
<kuruczgy[m]> travmurav[m]: Yes, but only in rootfs. And now I see dmesg messages that it's trying to load the firmware and failing, but of course it is failing because rootfs isn't mounted yet.
<kuruczgy[m]> Okay now I have both remoteprocs in state "running", but the battery status still isn't working 😭
<travmurav[m]> pd-mapper service? (Or in-kernel one?)
<kuruczgy[m]> What is pd-mapper?
<travmurav[m]> A service that needs to run for qcom remoteprocs to work properly, something about protection-domains (dsp os equivalent of applications I guess)
iivanov_ has joined #aarch64-laptops
<kuruczgy[m]> Ah. What would be the easiest way to set one up? Are there any instructions/documentation somewhere?
iivanov_ has quit []
<travmurav[m]> I think it should be in the repos in most distros by now
<travmurav[m]> But there was also a recent in-kernwl version
iivanov_ has joined #aarch64-laptops
<Jasper[m]> <\[m]> "seems they have put now a real..." <- psref doesn't mention anything other than 78 for now, so don't hold out hope for it
<kuruczgy[m]> travmurav[m]: Well I can't find it in either the Arch or NixOS repos.
<kuruczgy[m]> travmurav[m]: The in-kernel version might be easier if it exists. What's the name of the module? How do I make sure it is working properly?
iivanov_ has quit [Remote host closed the connection]
iivanov_ has joined #aarch64-laptops
<kuruczgy[m]> I have qcom_pd_mapper loaded, is that the one?
<travmurav[m]> I think so, yes
<travmurav[m]> If it's loaded then I guess it's not pd-mapper
<kuruczgy[m]> Ah but I have it in initramfs, let me try removing it, that seems to have magically solved all my issues so far :D
iivanov has quit [Ping timeout: 480 seconds]
<kuruczgy[m]> kuruczgy[m]: No, still not working :(
<kuruczgy[m]> But thank you travmurav for all the help so far, you already helped a ton. Later I will try fudging around with the modules a bit more, and if that fails I will try to dive a little deeper and try to understand how this whole coprocessor battery reading system is supposed to work.
Lucanis has quit [Ping timeout: 480 seconds]
<Jasper[m]> <kuruczgy[m]> "🤦 Then I guess "it needs to be..." <- iirc it only needs to be blacklisted when booting off usb
alpernebbi has quit [Server closed connection]
alpernebbi has joined #aarch64-laptops
<Jasper[m]> Because the usb controller resets and the UUID's become inconsistent
Lucanis has joined #aarch64-laptops
<Jasper[m]> idk if that changed from sc8280xp to x1e
<kuruczgy[m]> Jasper[m]: Hm okay thanks I will double check this, I just recently switched to booting from nvme instead of usb. So I might still want to blacklist it in the install iso
<Jasper[m]> for fedora it was enough to add it cmdline parameter in grub
<Jasper[m]> But if you're booting off nvme it should be fine to let it load
f_ is now known as funderscore
iivanov_ has quit [Remote host closed the connection]
iivanov has joined #aarch64-laptops
iivanov has quit [Remote host closed the connection]
iivanov has joined #aarch64-laptops
craftyguy has quit [Remote host closed the connection]
funderscore is now known as f_
craftyguy has joined #aarch64-laptops
craftyguy has quit [Remote host closed the connection]
craftyguy has joined #aarch64-laptops
iivanov_ has joined #aarch64-laptops
iivanov has quit [Ping timeout: 480 seconds]
iivanov_ has quit [Remote host closed the connection]
iivanov has joined #aarch64-laptops
<kuruczgy[m]> <travmurav[m]> "If it's loaded then I guess it's..." <- Actually it is, I found that this message comes from the pd_mapper module:... (full message at <https://matrix.org/_matrix/media/v3/download/matrix.org/jOhFoJrPGkVZAWLivXCIrWuT>)
<travmurav[m]> I thiink the pd-mapper patch for x1e was sent on the lists at some point
<travmurav[m]> this I think
<kuruczgy[m]> Yes indeed, and it seems like it was applied 6 days ago: https://lore.kernel.org/all/172375444805.1011236.7812815658652492158.b4-ty@kernel.org/
<kuruczgy[m]> But I have no idea to which tree, and how many steps in needs to trickle down to an rc kernel. Let me check johan's new kernel, if I am lucky it's already there.
<travmurav[m]> kuruczgy: if it was applied over a day ago, it's always in linux-next :P
<travmurav[m]> but well, in any case can just use b4 to fetch the patches from the list too
<travmurav[m]> Many options :D
Mathew has joined #aarch64-laptops
mcbridematt has quit [Ping timeout: 480 seconds]
akaWolf has quit [Remote host closed the connection]
iivanov_ has joined #aarch64-laptops
iivanov has quit [Ping timeout: 480 seconds]
alfredo has joined #aarch64-laptops
<kuruczgy[m]> So I had to pick up this (trivial) patch as well for it to apply cleanly: https://git.kernel.org/pub/scm/linux/kernel/git/qcom/linux.git/commit/?id=dbd6bd124e34f9f859271ed9ae2afc39f36c7e8c
<kuruczgy[m]> But it works now!! Thanks again for your help.
<kuruczgy[m]> jhovold: You might want to pick up the above mentioned pd_mapper patch into your x1e80100 branch as well, it makes the battery work without needing a userspace pd-mapper daemon.
iivanov has joined #aarch64-laptops
iivanov_ has quit [Read error: Connection reset by peer]
todi has quit [Read error: Connection reset by peer]
todi has joined #aarch64-laptops
<kuruczgy[m]> Hm actually the values don't seem to be updating... Only status is fine. energy_now is not decreasing, and power_now is not changing either no matter if the CPU is idle or running on full load.
alfredo has quit [Quit: alfredo]
<kuruczgy[m]> Hm they seem to be updating though when I unplug/replug the charger, but only then. wth
javierm has left #aarch64-laptops [#aarch64-laptops]
iivanov has quit [Remote host closed the connection]
weirdtreething has quit [Remote host closed the connection]
<kuruczgy[m]> anonymix007[m]: (It says your graphics is llvmpipe, you should probably look into that next.)
rz_ has joined #aarch64-laptops
rz has quit [Ping timeout: 480 seconds]
<JensGlathe[m]> yeah but have it come up is something
<anonymix007[m]> kuruczgy @kuruczgy:matrix.org: Any suggestions? I guess I might have to build mesa and drop chipid hack
<robclark> chipid hack won't _hurt_ (other than the renderer name being incorrect).. but you defn need mesa 24.2.0
<kuruczgy[m]> anonymix007[m]: - Mesa 24.2.0... (full message at <https://matrix.org/_matrix/media/v3/download/matrix.org/gCeUbnQSFnWRNeNJbMGmcMLd>)
<kuruczgy[m]> <kuruczgy[m]> "Hm they seem to be updating..." <- I see this error in dmesg: `failed to request power notifications`. So something is still definitely wrong
<kuruczgy[m]> <kuruczgy[m]> "I see this error in dmesg: `..." <- Hm Johan seems to have encountered this issue as well: https://lore.kernel.org/all/Zqet8iInnDhnxkT9@hovoldconsulting.com/
<kuruczgy[m]> So I guess this is why he didn't apply the pd_mapper patches to his kernel yet.
<agl> steev: I have installed yesterday your 6.10.6 kernel. All works, only the USB-Thethering have I not yet probed.
iivanov has joined #aarch64-laptops
<kuruczgy[m]> robclark: are you using the userspace pd-mapper daemon? Is the battery status working consistently with that?
<agl> s/probed/tested/
<robclark> I'm using the kernel one.. battery status works.. if some of the q6v5 modules load before fw is enabled you need to `echo start > /sys/class/remoteproc/remoteproc0/state` once fw is avail
<robclark> like if you have module in initrd but not fw
<kuruczgy[m]> robclark: Both my remoteprocs properly get to the `running` state on boot, so unless there is some weirdness where it needs to be restarted or something I think this should be fine.
<kuruczgy[m]> So you never encountered the issue reported by Johan that I linked above? For me the error happens on every boot
<robclark> no
<kuruczgy[m]> I see. Well, thanks anyway, at least then I know that it's not necessarily a kernel/userspace pd-mapper difference.
<anonymix007[m]> robclark: am I supposed to get this?
<robclark> anonymix007[m]: I just disable rusticl and things that use rust rather than dealing with unstable dependencies
jhugo has joined #aarch64-laptops
iivanov has quit [Remote host closed the connection]
iivanov has joined #aarch64-laptops
<jhovold> kuruczgy[m]: as you noticed, using the in-kernel pd-mapper is currently broken so that's why it's not enabled in my branch
<jhovold> you may be lucky like robclark depending on kernel config and when drivers are loaded, but for now you should stick to the user space daemon
<kuruczgy[m]> Okay, I will try the userspace daemon, thanks. Are there any instructions anywhere to set it up? The repo doesn't seem to have a README
<jhovold> just build and run I guess, I think someone has prepared a PKGBUILD for arch somewhere
<jhovold> some distros have it packaged already
<bamse> jhovold: on that subject, "make pacman-pkg" works like a charm...
<bamse> jhovold: although, if you run systemd-boot, you need https://lore.kernel.org/linux-arm-msm/20240819-uncompressed-distro-packages-v1-1-c8accc8bc9ea@quicinc.com/ and CONFIG_COMPRESSED_INSTALL=n to be able to boot the resulting package
<jhovold> I was referring to pd-mapper
<jhovold> looks like you have a recipe here:
<bamse> ahh, so not the in-kernel PKGBUILD
<bamse> yeah, that's what i rely on for the userspace pieces... but it would be really nice to have those landed in alarm...
<kuruczgy[m]> Btw is there some kind of issue tracker somewhere where I could reference & track this bug? Or is it just your mail jhovold on the mailing list?
<JensGlathe[m]> nice
<anonymix007[m]> I guess mesa 24.2 was enough? It was painful to build though as meson didn't want to cross-compile.
<bamse> anonymix007[m]: good thing you have a decent arm64 machine that could build that thing natively then ;)
<steev> yeah, should take 5-10 minutes tops
<anonymix007[m]> bamse: I had to build it in qemu. As one might imagine, this was painfully slow.
<anonymix007[m]> Cross-compilation would've been *much* faster than this or x1e native build given that I have 7950x
<steev> if you weren't passing something specific to QEMU_CPU it was likely far slower than it should be
<anonymix007[m]> `-cpu cortex-a75 -smp 32`
<steev> not sure if a75 is faster or slower than a72, i haven't checked it
weirdtreething has joined #aarch64-laptops
iivanov has quit [Remote host closed the connection]
<Jasper[m]> <steev> "not sure if a75 is faster or..." <- more number is more better
<Jasper[m]> up until the a78, that's when the X1 came out
<JensGlathe[m]> X is another dimension ofc
<steev> i mean the options that qemu uses, not about speed itself
<jannau> do not compare cores with different number of digits
<Jasper[m]> Ah in that sense, can otherwise imagine one has more features than the other if you need those for the cross-compile process
<steev> no, it has to do with... something that i don't feel like digging through the qemu docs to find. something like pauth-impdef=off (or maybe setting it to on?) i'm not sure if that's specific to the "max" cpu model or not though (cortex-a72 does not need it) - but that's what was causing our builds to take 7 hours when they used to take 1h15m
<steev> so if you jsut take qemu's defaults, and you have a modern gcc, the performance is atrocious
<steev> it took me 7 months to track that crap down, and as soon as you mention qemu everyone just dismisses it as "qemu is slow" so i gave up trying to get anyone to care
iivanov has joined #aarch64-laptops
<kuruczgy[m]> Notes for setting up userspace pd-mapper, in case they are useful for anyone:... (full message at <https://matrix.org/_matrix/media/v3/download/matrix.org/LUiScfkWwLHwvEBwqBALTRwk>)
<HdkR> steev: Is the issue more that emulating the exclusive monitor is a nightmare and once you switch to something that supports LSE, it matches x86 atomic semantics so things go faster?
iivanov has quit [Ping timeout: 480 seconds]
<steev> HdkR: i am not sure. it only seems to occur when using a gcc that has been patched for that cve i mentioned a while back
<steev> of course, getting a cve patch reverted is... not gonna happen
<HdkR> Interesting
<steev> regardless, i have workaround, and i'll let people who run into it when the next debian stable rolls around deal with it
<HdkR> The entire premise of FEX is that qemu is slow, let's NIH a solution :P
<HdkR> But that's just taking advantage of domain specific optimizations that qemu can't use, so it's a real argument
<steev> i'm just tired of repeating "yes, qemu is slow, it's just not supposed to be *this* slow" and being told "give us a reproducer that doesn't require qemu"
<HdkR> :D