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
<kuruczgy[m]>
icecream95: Is your hyp running in EL2? Any hope of ever tracing Windows register accesses with it, or is it too Linux specific?
<icecream95>
kuruczgy[m]: The hope is to eventually run Windows (and hope that it works fine without getting access to EL2 itself), but Linux is easier to start with
<kuruczgy[m]>
icecream95: Cool! Please share when you published the code and/or have updates, I would certainly be interested.
shoragan has quit [Read error: Connection reset by peer]
shoragan has joined #aarch64-laptops
shoragan has quit []
shoragan has joined #aarch64-laptops
tobhe has joined #aarch64-laptops
tobhe_ has quit [Ping timeout: 480 seconds]
hexdump01 has quit [Ping timeout: 480 seconds]
lucanis has joined #aarch64-laptops
jglathe_ has joined #aarch64-laptops
jglathe_angrybox has quit [Ping timeout: 480 seconds]
zdykstra has quit [Ping timeout: 480 seconds]
zdykstra has joined #aarch64-laptops
ben__ has quit [Read error: No route to host]
jhovold has joined #aarch64-laptops
lucanis has quit [Read error: Connection reset by peer]
martiert_work has quit [Quit: WeeChat 4.4.4]
martiert_work has joined #aarch64-laptops
icecream95 has quit [Ping timeout: 480 seconds]
srinik has joined #aarch64-laptops
svarbanov__ has joined #aarch64-laptops
svarbanov_ has quit [Read error: No route to host]
svarbanov_ has joined #aarch64-laptops
svarbanov__ has quit [Ping timeout: 480 seconds]
SpieringsAE has joined #aarch64-laptops
<SpieringsAE>
I wrote this driver, and I am getting this error: max25014atg.c:(.init.text+0x14): undefined reference to `latent_entropy', I assume I missed some include or something but I've never seen this before. Does anyone know what I may have messed up?
<SpieringsAE>
this doesn't happen when I just do make Image, but I did a make deb-pkg this time to test something out and this error shows up
alfredo has joined #aarch64-laptops
<maz>
probably because this is built as a module, and there are some missing dependencies.
<maz>
#ifdef CONFIG_GCC_PLUGIN_LATENT_ENTROPY
<SpieringsAE>
hmm it is not built as a module
<maz>
then it is odd that 'make Image' doesn't generate an error.
<SpieringsAE>
aarch64-linux-gnu-ld: drivers/video/backlight/max25014atg.o: in function `max25014_driver_init':
<SpieringsAE>
I guess that function gets generated by module_i2c_driver()
alfredo has quit [Quit: alfredo]
<anthony25>
about the battery consumption, it seems that because qcom-battmgr-bat stores the power_now value as a negative number when on battery, it breaks `acpi` and things that estimate the battery life
<anthony25>
I didn't test to cast it as uint, so I'm not so sure about what I say
<anthony25>
was there a reason to leave it as a negative number?
nothorseface has joined #aarch64-laptops
nothorseface has quit []
<SpieringsAE>
huh nvm regular make Image doesn't work anymore either
nothorseface has joined #aarch64-laptops
nothorseface has quit [Remote host closed the connection]
nothorseface has joined #aarch64-laptops
jglathe_ has quit [Remote host closed the connection]
<SpieringsAE>
okay I fixed it that was weird, I had renamed some file but forgot the line in the Makefile, which caused some weird stuff, but after a make mrproper it actually gave the correct error
<anthony25>
yeah, having a positive value in /sys/class/power_supply/qcom-battmgr-bat/power_now fixes the remaining time on battery given by `acpi`
<anthony25>
(and the battery widget in waybar)
<anthony25>
should I send a patch or does something rely on the fact that it's not unsigned?
<travmurav[m]>
uh iirc power_now is immediate power usage?
<anthony25>
it is
<travmurav[m]>
iirc that's defined as "how much flows into battery" aka negative value == flows out of the battery (discharging) and positive - charging (into)
<anthony25>
but acpi, waybar and others just do a `energy_full/power_now` to know the battery life
<anthony25>
and if power_now is a negative number, it breaks it
<travmurav[m]>
uh
<travmurav[m]>
as in to get %?
<travmurav[m]>
uhh
<travmurav[m]>
hm
<anthony25>
no, the % they get it by doing `energy_now/energy_full`
<travmurav[m]>
ah as in "how much time left?
<anthony25>
yes
<travmurav[m]>
weird
<travmurav[m]>
tbh I wonder if the tool itself is broken and should take modulus
<travmurav[m]>
negative current/power is how those props are defined generally
<anthony25>
I never saw it on an x86 machine
<SpieringsAE>
waybar battery thing can be a bit special sometimes
<anthony25>
I mean, if it was only waybar, I would just do a PR for their widget
<SpieringsAE>
the kde one seems to be working better for me
<anthony25>
but `acpi` is broken the same way
<anthony25>
I think kde uses upower
<anthony25>
same for gnome
<travmurav[m]>
anthony25: acpi on my aspire1 definitely returns negative value when the device is discharging
<anthony25>
I mean the `acpi -i` command
* travmurav[m]
tries to find the acpi spec for that
<travmurav[m]>
well I mean acpi the firmware, which linux passes directly on x86 (and generally acpi systems) into those props
<anthony25>
yeah I understand, qcom-battmgr just sets the value it receives, there's no logic of switching to a negative number if it discharges
<anthony25>
just then, if we store this value as it is, it breaks some tools estimating the time left on battery, because of the negative number
<travmurav[m]>
well my argument is that linux returns correct data and the tool is broken
<travmurav[m]>
or hm
<travmurav[m]>
hm
<anthony25>
yeah I agree with you, but also it doesn't seem standard with what intel or amd laptops return
<travmurav[m]>
uhh
<travmurav[m]>
meh I guess if I read the spec right, acpi passes absolute value with a special bit in another field to show the direction and I guess acpi battery driver doesn't bother to correct the value
<travmurav[m]>
meh
<travmurav[m]>
what a mess
<anthony25>
I can just send a patch and see what people think about it
<anthony25>
it's a 1 line fix
<travmurav[m]>
duh energy is not even defined in the abi doc
<travmurav[m]>
and the driver code for acpi uses same variable for both
<travmurav[m]>
so unless I missed the inversion somewhere, I'd argue acpi code (and thus the most popular battery driver, on which most userspace was written) is broken garbage
<travmurav[m]>
eh
<anthony25>
I mean, if there's no standard, and every laptop until now was storing a positive value, they just considered it would always be a uint, and use the `status` file to know if it's charging or discharging
<travmurav[m]>
well there /is/ a standard defined by the docs in linux, which /most/ drivers follow, and there is acpi/x86 stuff that doesn't follow the doc (even for defined in the docs current values) but is now a shitty de-facto standard :(
<anthony25>
so either we keep doing the same, or we need to fix all tool relying on this, just I'm wondering what is the value of storing a negative value
<travmurav[m]>
it's semantically more correct to have sign signify the flow there IMO
<travmurav[m]>
but well
<travmurav[m]>
whatever I guess
<travmurav[m]>
this mess won't get any better anyway xD
<anthony25>
haha, no :D
<anthony25>
I'll just send a patch explaining the logic, and we'll see what people think
* travmurav[m]
is frustrated learning that acpi driver shit is this bad after he spent so much time carefully learning the proper semantics for current measurements and making sure he didn't swap the sign every time
<anthony25>
:}
<anthony25>
just I need to check on my intel laptop what happens if I use more power than what the charger can give
<anthony25>
I think it keeps the power_now as positive and sets the `status` as "Discharging", but well, I'm ready to be surprised
craftyguy has quit [Remote host closed the connection]
craftyguy has joined #aarch64-laptops
craftyguy has quit [Remote host closed the connection]
craftyguy has joined #aarch64-laptops
craftyguy has quit [Remote host closed the connection]
rmsilva has joined #aarch64-laptops
craftyguy has joined #aarch64-laptops
nothorseface has quit []
nothorseface has joined #aarch64-laptops
ben__ has joined #aarch64-laptops
alfredo has joined #aarch64-laptops
alfredo has quit [Ping timeout: 480 seconds]
<smoorgborg[m]>
Not sure if this belongs here, but PowerServe was just released. It's a LLM server that supports Qualcomm NPU under Android. Since it's close to Linux, it might be of interest here -> https://github.com/powerserve-project/PowerServe
nothorseface has quit []
<abby>
ew spam generators
<smoorgborg[m]>
I'd love to have the NPU working on my T14s, that was part of the reason I bought it
<JensGlathe[m]>
well, it might give us ideas (not just for spam generators)
<robclark>
AFAIU fastrpc is the way to use hexagon (and therefore npu).. but I think cdsp fw is signed so not sure how to load your own thing on it
<robclark>
maybe bamse or konradybcio or someone like that would know more
<smoorgborg[m]>
most of the stuff that is happening here is way over my head, so thanks for that :-) but wouldn't using the device just require same firmware from windows as everything else being supported right now? firmware runs the device, but that's not the same as executing code on it (like GPU) - or am I misunderstanding?
<konradybcio>
I think you should be able to run some stuff from the ai hub as is..
<konradybcio>
havent tested that though
<travmurav[m]>
I guess whatever eyy ayy framework it uses would just upload a dsp app for fastrpc stuff?
<bamse>
smoorgborg[m]: the way to use the NPU in a qualcomm platform is that you run your computation as "dynamically loadable programs", typically using fastrpc, on the DSPs
<travmurav[m]>
and iirc there was something for "user" apps compared to "secure/signed" apps for that
<bamse>
as robclark says, the DSP firmware itself is signed and can't be replaced, but these dynamic applications can supposedly be loaded without being signed
<bamse>
travmurav[m]: yes (although i haven't experimented with it myself)
<travmurav[m]>
and a quick skim makes me feel they sign the app with per-soc-serial number huh
<bamse>
i thought that went away with the introduction of "user" applications
srinik has quit [Ping timeout: 480 seconds]
srinik has joined #aarch64-laptops
SpieringsAE has quit [Quit: Leaving]
<anonymix007[m]>
travmurav: ADSP is fully locked down, but one can run some code on CDSP. That worked fine on my sm8550 phone (rooted), so will likely work on x1e as well
<steveej[m]>
to say something positive for once in this channel :-) since 6.13-rc6 the USB stability on my x13s has increased greatly. i've been using a USB dongle for audio and previously it would flake in/out and confuse the heck out of wireplumber/pulseaudio. this has improved significantly
<craftyguy>
JensGlathe[m] how goes it with iwd + msi-map disabled on your x13s?
<bamse>
steveej[m]: wonderful
<JensGlathe[m]>
craftyguy: it's holding up. 1x msdu_done bit in attention is not set No HTC Rx errors. Both WDK2023 boxes (with msi-map on, -rc7, wpa_supplicant) had their episode of HTC Rx errors today, first time I've seen screen artifacts because of it.
<craftyguy>
Interesting, well maybe disabling msi-map for pcie4 + wpa_supplicant causes problems 🤷♂️ I still get zero HTC errors with iwd+msi-map disabled, but the moment I re-enable msi-map on pcie4 the errors flood back in
<jhovold>
craftyguy: perhaps you can try with wpa_supplicant as well, to see if that makes any difference
<jhovold>
I think it must have something to do with the router you use also
<jhovold>
someone reported seeing these errors whenever he roamed from one ap to another (see bugzilla)
<craftyguy>
ya I can keep the msi-map disable patch and try wpa_supp to see if the errors come back
<craftyguy>
jhovold: roaming between APs or between freqs? I've observed that (for me at least) iwd does a better job handling roaming than wpa_supp
<craftyguy>
anyways, I got wpa_supp set up now, I'll use that and see if I start getting those HTC Rx errors now
<jhovold>
the report said roaming between APs, but there are obvisouly other ways to trigger this bug as well
<craftyguy>
ya I'm not roaming between APs when it happens, but I miiiight be "roaming" between 2.4GHz and 5GHz freqs on the same AP
<craftyguy>
I'm usually pretty close to the AP where it should be using 5GHz most/all the time though /shrug
<jhovold>
might be worth a try to disable 5 GHz as well or similar, since you got a setup where it usually triggers very often
minecrell has quit [Read error: Connection timed out]
minecrell has joined #aarch64-laptops
<steev>
craftyguy: i'm using wpa_supplicant (because kali uses networkmanager) here, and do not see the HTC errors
<steev>
oh, no, i lied; i do see them on 6.13-rc7, i have not on 6.12
<steev>
just ran dmesg on the laptop that had been running over night
alpernebbi has quit [Ping timeout: 480 seconds]
<JensGlathe[m]>
well that at least aligns the observed behaviour somewhat
alpernebbi has joined #aarch64-laptops
<steev>
unfortunate that it doesn't show up in 6.12 but does in 6.13
<steev>
but at least 6.12 is an lts?
<steev>
i do not seem to be able to switch to iwd backend for networkmanager here though, for some reason, in debian testing/kali at least, using iwd as the backend causes the x13s to just kernel panic?
<steev>
not kernel panic, but it definitely resets, nothing seems to show up in the logs
<craftyguy>
yikes
<craftyguy>
well... ~2 hours after switching to wpa_supplicant (and keeping msi-map disabled), I haven't seen any HTC errors yet. I'll keep using it for the rest of todayjust to be a bit more sure
<JensGlathe[m]>
at least with -rc6, msi-map disabled and wpa_supplicant on X13s it appeared really touchy with HTC Rx errors. with them enabled it was better. Now on rc7 for ~20hrs with iwd, no HTC Rx errors jet.
<JensGlathe[m]>
what is iwd doing different
<JensGlathe[m]>
...ly
svarbanov__ has joined #aarch64-laptops
akhilpo has joined #aarch64-laptops
svarbanov_ has quit [Ping timeout: 480 seconds]
<steev>
dunno, but i'd like to know why 3.3 causes my system to reboot
<steev>
i can boot with modprobe.blacklist=ath11k_pci but as soon as i probe, it reboots
lucanis has joined #aarch64-laptops
jhovold has quit [Ping timeout: 480 seconds]
srinik has quit [Ping timeout: 480 seconds]
ben__ has quit [Ping timeout: 480 seconds]
lucanis1 has joined #aarch64-laptops
lucanis1 has quit []
Lucanis_ has joined #aarch64-laptops
Lucanis_ has quit []
lucanis has quit []
lucanis has joined #aarch64-laptops
lucanis has quit []
lucanis has joined #aarch64-laptops
ben__ has joined #aarch64-laptops
ben__ has quit [Remote host closed the connection]