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
<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]>
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]
<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
<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]>
<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]>
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.
<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?
<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
<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"