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
mbuhl has quit [Remote host closed the connection]
mbuhl has joined #aarch64-laptops
<bamse> icecream95: which kernel are you running?
<icecream95> bamse: 6.12 and 6.13, maybe I'll try 6.14-rc2
Melody91 has quit [Ping timeout: 480 seconds]
laine has joined #aarch64-laptops
laine_ has joined #aarch64-laptops
laine has quit [Read error: Connection reset by peer]
<bamse> icecream95: so a clean upstream tree?
<bamse> icecream95: we're still missing cpufreq support in upstream, so that would most certainly impact the cpu throughput
<icecream95> bamse: I tried with SpieringsAE wip/x1e80100-6.14-rc2, no difference. Interestingly schedutil is quite a bit faster than the performance governor
<icecream95> oh nevermind that's just run-to-run variation
laine__ has joined #aarch64-laptops
laine_ has quit [Read error: Connection reset by peer]
laine__ has quit [Ping timeout: 480 seconds]
<icecream95> oh it is real... sometimes when switching to the performance governor it's always slow and stays that way until I change the governor again, and sometimes it's always fast
<icecream95> Maybe the performance governor disables frequency scaling for some other part of the SoC, so it just stays at whatever frequency it was at when switching governor?
<anthony25> it could be that scheduling deals better with throttling, when in performance the frequencies are dropping harder?
<icecream95> No throttling on this vivobook!
<anthony25> * schedutil, sorry
<icecream95> I see some "bwmon" stuff in the x1e dts, so if that controls memory bandwidth it could be that
<robclark> for sanity check maybe compare geekbench to windows.. on my 7x (and I think for others), although I've not run it on latest kernel, scores seem to match up with what I've seen online for windows
<robclark> I guess that would rule out some recent regression, at least
<icecream95> Aha, so it's per-cluster! If I have one performance cluter and two schedutil clusters, then it's fast as long as only the schedutil ones are uesd
<icecream95> tinymembench is up to 3x slower on the "performance" cluster, so I guess it's the per-cluster bandwidth stuff
<icecream95> So it appears that the BWMON driver is trying to switch opp, but because the cluster uses the performance governor, it can't?
Kelsar_ has quit []
Kelsar has joined #aarch64-laptops
sally has quit [Quit: sally]
<icecream95> No perhaps it's not that. Annoyingly there doesn't appear to be a way to force the bandwidth setting, then it would be easier to tell if bwmon is the cause or not
<bamse> icecream95: /sys/kernel/debug/qcom_aoss/ddr_frequency_mhz
<bamse> although, that sets the ddr frequency, not necessarily the bus frequency
<icecream95> bamse: Changing that doesn't affect the performance of the "performance" cluster much, but the other clusters are fast enough to become bandwidth limited if I set it to a low value
<icecream95> Maybe I should give up on trying to investigate this, since "just using schedutil" isn't a bad workaround... but the performance governor giving consistent performance is a useful property to have
sally has joined #aarch64-laptops
<icecream95> I wonder if it's something like bandwidth changes only getting applied when the CPU frequency changes, in which case it could affect other governors
tobhe_ has joined #aarch64-laptops
tobhe has quit [Ping timeout: 480 seconds]
hexdump01 has joined #aarch64-laptops
hexdump0815 has quit [Ping timeout: 480 seconds]
lucanis has quit [Ping timeout: 480 seconds]
Melody91 has joined #aarch64-laptops
sally has quit [Quit: sally]
sally has joined #aarch64-laptops
jhovold has joined #aarch64-laptops
ungeskriptet_ has joined #aarch64-laptops
ungeskriptet has quit [Ping timeout: 480 seconds]
ungeskriptet_ is now known as ungeskriptet
SpieringsAE has joined #aarch64-laptops
<SpieringsAE> anonymix007: I see you added some fastrpc thing to your repo, I've heard this in context of the npu. Did you manage to get anything done with this?
<smoorgborg[m]> <anthony25> "Just I don't recommend the..." <- I do, unless the price is horrid. You can just disable half of it, and it runs fine. This is a bug that will get fixed for sure.
<smoorgborg[m]> <jhovold> "d0pefish: been running arch..." <- With the rust in the kernel controversy and realizing how much work goes into upstreaming things, your efforts are really appreciated
srini_ has joined #aarch64-laptops
crabbedhaloablution has joined #aarch64-laptops
socratitties[m] has joined #aarch64-laptops
icecream95 has quit [Ping timeout: 480 seconds]
Caterpillar has joined #aarch64-laptops
<anonymix007[m]> SpieringsAE: no, not yet. Hexagon DSP works just fine on my sm8550 phone though, but I'm yet to try it on X1E
laine__ has joined #aarch64-laptops
laine has joined #aarch64-laptops
ygooooooo3[m] has joined #aarch64-laptops
ygooooooo3[m] has left #aarch64-laptops [#aarch64-laptops]
chrisl has quit [Read error: Connection reset by peer]
chrisl has joined #aarch64-laptops
SpieringsAE has quit [Remote host closed the connection]
SpieringsAE has joined #aarch64-laptops
<SpieringsAE> Are you running alarm on that phone? I've been wanting to look into linux on a phone, but I have no idea what a good device would be to start with
<anonymix007[m]> No, just plain old android.
<anonymix007[m]> I guess I should've seen this coming: https://katb.in/acuneyiqivu
<anonymix007[m]> Does anyone know why ION memory allocation might fail?
<anonymix007[m]> Okay, so the issue is that `/dev/dma_heap/system` doesn't exist. Does this come from some module which isn't in the johan_defconfig?
<anonymix007[m]> Yep, with CONFIG_DMABUF_HEAPS_SYSTEM=y it fails in a different place
<SpieringsAE> new error, progress lol
srini_ has quit [Quit: Leaving]
weirdtreething has quit [Remote host closed the connection]
weirdtreething has joined #aarch64-laptops
sally has quit [Quit: sally]
<anonymix007[m]> Yay, it worked! I had to copy ADSP and CDSP into the respective subdirectories of /usr/lib/dsp and that's it.
<robclark> nice
haver has joined #aarch64-laptops
<ektor5> kudos to sgerhold :)
kalebris has quit [Quit: WeeChat 4.5.1]
kalebris has joined #aarch64-laptops
kalebris has quit [Quit: WeeChat 4.5.1]
<SpieringsAE> Am I missing something? What is being teased?
SpieringsAE has quit [Quit: SpieringsAE]
<tobhe_> deeper sleep I guess?
<konradybcio> this is not teasing, but a technical reason
<konradybcio> if the platform went into power collapse, it would have no way to wake back up without this patch
<anthony25> Yeah I was just happy to see preps for deeper sleep, I know it's not teasing
<robclark> being able to wake up is useful ;-)
<maz> I'd be happy to sleep! :)
<ppd[m]> less x1e80100 sleep apnea yey
weirdtreething_ has joined #aarch64-laptops
weirdtreething has quit [Ping timeout: 480 seconds]
weirdtreething_ has quit [Ping timeout: 480 seconds]
weirdtreething has joined #aarch64-laptops
kalebris has joined #aarch64-laptops
abbe has joined #aarch64-laptops
<abbe> hi kalebris :D
kalebris_ has joined #aarch64-laptops
cyrinux has quit []
cyrinux has joined #aarch64-laptops
donte has joined #aarch64-laptops
kalebris_ has quit [Quit: WeeChat 4.5.1]
SpieringsAE has joined #aarch64-laptops
<SpieringsAE> ^ sus?
SpieringsAE has quit []
<HdkR> Omega sus
laine__ has quit [Quit: (╯°□°)╯︵ ┻━┻]
laine_ has joined #aarch64-laptops
laine_ has quit []
weirdtreething has quit [Ping timeout: 480 seconds]
weirdtreething has joined #aarch64-laptops
donte has quit [Read error: Connection reset by peer]
jhovold has quit [Ping timeout: 480 seconds]
xroumegue has quit [Ping timeout: 480 seconds]
xroumegue has joined #aarch64-laptops