ChanServ changed the topic of #aarch64-laptops to: Linux support for AArch64 Laptops (Asus NovaGo TP370QL - HP Envy x2 - Lenovo Mixx 630 - Lenovo Yoga C630)
<steev>
ajhalaney[m]: i mean... i didn't notice at all........
<steev>
that said...
<steev>
next still works, so, it's definitely something i yanked in, and it shouldn't be audio
<HdkR>
Could there be an errata in the X1C/A78C that makes exception level switching slower? I haven't looked at the errata list yet
<HdkR>
Looking forward to when iommu is fixed. I find myself falling back to the HDK888 because the gigabit ethernet is so slow on the X13s
<bamse>
HdkR: and iommu.strict=0 is not what you desire?
<HdkR>
Oh, does that also solve it?
<bamse>
or settings CONFIG_IOMMU_DEFAULT_DMA_STRICT=n...
<bamse>
yes
<HdkR>
Let me give that a try
<bamse>
either one of those two will cause all iommu domains to be DMA-FQ
<HdkR>
I just want the shiny new development device to be faster in every regard so I can ignore the HDK
<bamse>
HdkR: what tree are you running on your 888hdk?
<HdkR>
Some random 5.15 tree
<bamse>
i see...because my testing of linux-next indicated that it needed some more polish...
<HdkR>
I'd guess the tree it's on has some polish. It was just provided by someone else so I'm not sure what :P
<bamse>
that's the way we roll in the shire...
<HdkR>
Looks like non-strict iommu is an improvement but the HDK888 is still winning when compiling over the network
<HdkR>
3m42s on HDK888, 6m14s on the X13s with a USB gigabit dongle
<HdkR>
Meanwhile local building on X13s is like 1m16s if I remember
<HdkR>
fio saturates gigabit ethernet on the HDK888, X13s is peaking at 37MB/s
<HdkR>
IOPS reduced as well, 25.6K/s on HDK, 9.5K/s on X13s
<HdkR>
46% time in el0t_64_sync
<HdkR>
oh, that dropped, now 11% in queue_work_on, 9.44 in..el0_svc_common.constprop.0?, 6% in internal_get_user_pages_fast, 5% i __kernel_clock_gettime vdso
<steev>
stop trying to get the time
<HdkR>
Dang it fio, stop reading the clock
<steev>
shits and giggles... blacklist rtc_pm8xxx ?
<HdkR>
Could give it a try
<HdkR>
steev: No change
<bamse>
that shouldn't be the rtc clock
<HdkR>
At least fio is something that is easily reproducible rather than "compile my project"
<bamse>
so what are you running now? fio on nfs over usb-ether?
<HdkR>
yea
<steev>
i just assumed it was trying to hit the rtc, i have no idea how any of that works :)
<bamse>
the rtc is too slow...so it's using one of the other clock sources
<bamse>
HdkR: and when running that CPU0 is at 100% on x13s?
<HdkR>
It isn't actually
<bamse>
well, the reason why you need non-strict dma operations is that the tlb sync takes significant longer on x13s than 888...
<bamse>
with the non-strict operation we hide that problem, but i think it just shines through in your benchmark anyways
<HdkR>
Ah, I did test this in non-strict mode. Could be related
<HdkR>
womp womp
<HdkR>
Even a potato should be able to saturate gigabit so that's a bit worrying
<steev>
throw more potatoes at it
<travmurav[m]>
hexdump0815: re: wifi userspace: need to bring up the modem, then have all firmware blobs from windows in /lib/firmware/..., have stuff like rmtfs, tqftpserv and pd-mapper running. "blobs" == mbn files and also .jsn files for pd-mapper
<travmurav[m]>
all .mbn files are signed so have to pull from the device
<steev>
or convince samsung to submit them
<steev>
er, acer
<steev>
or both samsung and acer
<travmurav[m]>
qca can be from linux-firmware I think, and so are the gpu files apart from the zap shader
<steev>
i don't think the wifi strictly requires the mbn, but i've never really looked at the ath10k stuff closely
<travmurav[m]>
on 7c everything is in the SoC so afaiu the ath10k firmware runs as an "application" in the modem here
<travmurav[m]>
I think only qca is a dedicated IP block here in the wcn so it isn't affected by the SoC hw secure boot
<steev>
oh interesting
<travmurav[m]>
steev: I wonder if samsung, in their fashion, has a different SB key for each region they sell the laptops in, requiring 5 different sets of same blobs
<travmurav[m]>
would be sad
<steev>
i honestly do not know :)
<steev>
i have only ever lived in 1 region
<travmurav[m]>
steev: tbh it;s more of the "outloud thoughts" after I saw soo many instances of samsung doing that for phones, as evident by pmOS
<travmurav[m]>
hexdump0815: re: sound: tbh I got it half-working once and I think it's broken again on my current setup, in general the answer is "qcom hates you" so need to make sure lpass clocks are disabled, bring up adsp and then have fun hooking all of that together in the kernel sound board files and the userspace UCM
<travmurav[m]>
compared to cros that has the benefit of saner firmware that doesn't randomly lock out hw blocks, we have to use the adsp so the set-up would use sm8250 stuff instead of talking to lpass hw directly as crbooks do
<travmurav[m]>
hexdump0815: re: EC, it's for sure a different EC and thus different firmware, whatever aspire1 has is written by quanta (the ODM) and I had to "reverse engineer" the ACPI code to talk to it
<steev>
bamse: did the battery driver for thinkpad not make it in to 6.3?
<bamse>
steev: i did get an ack on my pull request, so it should be there
<steev>
ah, linus likely doesn't have it yet
<bamse>
that's highly unlikely
<steev>
steev@wintermute:~/kernels/torvalds$ ls drivers/power/supply/*qcom*
<steev>
drivers/power/supply/qcom_smbb.c
hexdump01 has joined #aarch64-laptops
hexdump0815 has quit [Ping timeout: 480 seconds]
<steev>
okay so the external display stuff is definitely something in the dts/i
<HdkR>
Wow, I never measured the performance difference between kernel mounted erofs and FUSE mounted. kernel mounted cuts an application's execution time in half, that's nuts
iivanov has joined #aarch64-laptops
alfredo has joined #aarch64-laptops
<steev>
but userland is the future!
<steev>
ardb: did you come up with something else? i just noticed the rft patch re:setva stuff on efi, but then you'd immediately replied with bah it doesn't even work on c630, so i kinda... didn't test, did you still want it tested?
<HdkR>
steev: Maybe if it passes *at syscalls directly to fuse if the FD O_PATH matches perfectly :P
<HdkR>
Sabrent drive arrived. I'll be doing a bunch of documentation writing and benching :P
<ardb>
steev: no don't bother
zjstraus has quit [Quit: Ping timeout (120 seconds)]
zjstraus has joined #aarch64-laptops
derzahl has quit [Remote host closed the connection]
alfredo has quit [Ping timeout: 480 seconds]
alfredo has joined #aarch64-laptops
alfredo has quit [Quit: alfredo]
janrinze has quit [Ping timeout: 480 seconds]
janrinze has joined #aarch64-laptops
alpernebbi has quit [Ping timeout: 480 seconds]
alpernebbi has joined #aarch64-laptops
mcbridematt has quit [Ping timeout: 480 seconds]
mcbridematt has joined #aarch64-laptops
Mr0btain has joined #aarch64-laptops
<Mr0btain>
What all alsa stuff needs installed for sound on the x13s? I did some digging but couldn't find anything that worked. And I'm guessing the a690 fw in the surface repo is all we need for GPU?
Mr0btain has quit [Read error: Connection reset by peer]
<clover[m]>
oh yeah external display fully borked on 6.2
<clover[m]>
MR Obtain if you are on arch you can use my pkgbuilds
Mr0btain has joined #aarch64-laptops
<Mr0btain>
Sweet, I got win arch and Ubuntu atm. Win sadly is just for the 5G I have yet to get the modem usable in Linux.
<jhovold>
danielt, steev, clover[m]: found the problem with the external display in 6.2, bad merge, will push a fixed branch in a bit
<steev>
jhovold: <3
Mr0btain has quit [Read error: Connection reset by peer]
Mr0btain has joined #aarch64-laptops
Mr0btain has quit [Read error: Connection reset by peer]
Mr0btain has joined #aarch64-laptops
Mr0btain has quit [Read error: Connection reset by peer]
<clover[m]>
well if you are using ubuntu you probably can't use my pkgbuilds, unless there is some kind of reverse debtap thing i don't know about
<steev>
ah, i do need to update my fork of alsa-ucm-conf, currently it has the older stuff
<jhovold>
steev and anyone using 6.2 for the X13s, I've just pushed an updated branch based on 6.2-final:
<steev>
his v2 has some niceties, but i need to fix up our detection
Mr0btain has joined #aarch64-laptops
Mr0btain has quit [Read error: Connection reset by peer]
<steev>
there's also another issue that my bluetooth testhing has discovered that isn't related to the driver itself... that is, somewhere else in the bluetooth stack, regulators aren't being properly dealt with
<jhovold>
how does that manifest itself?
<steev>
it's a warn - let me find it in my logs
<jhovold>
hmm, the x13s is definitely warmer with gpu and audio (idling at 5-6 degrees C higher here)
<jhovold>
steev: that looks like a qualcomm driver bug, check if qca_serdev_remove() does what it's supposed to do
Mr0btain has joined #aarch64-laptops
Mr0btain has quit [Read error: Connection reset by peer]
<steev>
will look into that
Mr0btain has joined #aarch64-laptops
Mr0btain has quit [Read error: Connection reset by peer]
<danielt>
jhovold: Thanks for the update. Will adopt/test/dogfood shortly...
miracolix has joined #aarch64-laptops
derzahl has joined #aarch64-laptops
<steev>
same
<steev>
well, i've layered my patches on top, also nice to see we've got mani's patch for iommu stuff so we don't need that force bypass hack anymore :D
<bamse>
jhovold: a proper ath11k board file improves the range of bt, but all you need is a january-drop of linux-firwmare to get the bt firmware
<bamse>
steev: the regulator WARN comes from leaving the driver without calling regulator_disable()...but that's a separate from you series...
<steev>
bamse: sure but maybe i should throw that out there too... although... i dunno, tim's still submitting stuff so not sure
<bamse>
steev: that you can most definitely do, separate from your other series
<steev>
oh, yeah i meant it as such
<derzahl>
steev: postmarketos porting guide is driving me nuts
<derzahl>
seems to be missing ALOT
<derzahl>
anyone build PMOS before?
<derzahl>
btw, how does the X13s run? Any comparison to the apple m1?
<derzahl>
macbook
<steev>
sorry? i have nothing to do with PM so i have no idea what is or isn't wrong with their porting guide
<clover[m]>
its slower than M1 but you can't beat the coolness factor ;)
<steev>
it's also closer to working with mainline than an m1
<steev>
hm
<steev>
how the hell does adding bluetooth break external display
<steev>
i have to be missing a kernel config option
<clover[m]>
something is weird with typing in this new kernel. like sometimes i can't type in text boxes on chrome / firefox
<derzahl>
m1 has made awesome progress as of late
<derzahl>
how much slower?
<derzahl>
steev: i know, but you mentioned pmos to me so I thought id ask:) i think ive almost got it building now
<derzahl>
any idea if anyone puts together a kernel for the sm8150 like you do with the sdm845 and 8cx(i think?)?
<clover[m]>
derzahl: like what kinda progress? we just got gpu, bluetooth, and speaker/headphone jack working
<clover[m]>
typing thing might be a gnome bug
<derzahl>
basic GPU, dimmable screen backlight and SUSPEND!!
<derzahl>
finally useable
<derzahl>
i also got my audio working again recently but that was possible long time ago if you edited the dts file
<clover[m]>
two things i can think off top of the head that x13s has over m is WWAN and touchscreen (if you get that model)
miracolix has quit [Remote host closed the connection]
iivanov has quit [Ping timeout: 480 seconds]
<derzahl>
cool. i wonder if the wwan works on the c630 yet
<derzahl>
is the speed even comparable to an m1 or is it closer to the c630 would you say?
<robclark>
it is 4x x1 + 4x a78, so should be _quite_ a bit faster than c630
<robclark>
I think c630 was something along the lines of 4x a73 + 4x a55 or so?
<robclark>
slow cores on x13s would be somewhat faster than the fast cores on c630
<steev>
the wwan on the c630 should be working a long time ago
<steev>
afaik, bamse used it, so he kinda made sure it worked