robclark 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
<steev>
craftyguy: the venus stuff is in jhovold/my branches, afaik
<steev>
as to whether the firmware shows up in linux-firmware, that's up to lenovo, but i believe it is being worked on
rz_ has joined #aarch64-laptops
rz has quit [Ping timeout: 480 seconds]
rz has joined #aarch64-laptops
rz_ has quit [Ping timeout: 480 seconds]
laticlave has joined #aarch64-laptops
laticlave is now known as oars
hexdump0815 has joined #aarch64-laptops
hexdump01 has quit [Ping timeout: 480 seconds]
iivanov has joined #aarch64-laptops
<steev>
and 6.6 is tagged for release
jhovold has joined #aarch64-laptops
Guest4450 has quit [Quit: WeeChat 4.0.5]
martin has joined #aarch64-laptops
martin is now known as Guest5126
Ablu has joined #aarch64-laptops
Ablu has quit [Remote host closed the connection]
Ablu has joined #aarch64-laptops
Ablu has quit [Remote host closed the connection]
Ablu has joined #aarch64-laptops
oars has quit [Ping timeout: 480 seconds]
<jhovold>
craftyguy: video acceleration support in is in my wip branches (and by extension in steev's branches as they are based on those)
<jhovold>
but the firmware has not yet been released so is not in linux-firmware
<jhovold>
you need to make sure you install it manually from your windows partition (or elsewhere) to avoid wasting power as you won't hit the interconnect sync state
<jhovold>
...if it's missing
<Jasper[m]>
<jhovold> "you need to make sure you..." <- Alternatively, `innoextract` on one of the driver exe's from lenovo's site
<Jasper[m]>
Can't remember which one it was specifically
hightower3 has joined #aarch64-laptops
<jhovold>
Jasper[m]: thanks, haven't tried that myself yet
hightower2 has quit [Ping timeout: 480 seconds]
svarbanov_ has joined #aarch64-laptops
svarbanov__ has quit [Read error: Connection reset by peer]
martin has joined #aarch64-laptops
martin is now known as Guest5133
Guest5126 has quit [Ping timeout: 480 seconds]
<jhovold>
Here's an updated wip branch for the X13s:
<jhovold>
- fix DisplayPort connector type (e.g. "DP-1" instead of "Unknown20-1" with xrandr)
<jhovold>
- update pops and clicks sound fixesy
<jhovold>
the x13s alsa-ucm-conf fixes were just merged so should be included in next release (1.2.11)
matthias_bgg has quit [Ping timeout: 480 seconds]
<Jasper[m]>
@jhovold do you happen to know how the calibrationdata for ath11k for the X13S was merged into the board-2.bin file? I think the people trying to get Volterra with proper wifi may want to reproduce for that device ;)
<Jasper[m]>
I have a good place to get all the firmware from and presumably the boardfiles needed for wifi, just not sure what to do with them or if they're evn the proper format.
<Jasper[m]>
I did read about ath11k-bdencoder, just not sure how to get the proper input basically...
matthias_bgg has joined #aarch64-laptops
<Jasper[m]>
Looks like Kalle merged it in March, I should probably send him an email...
<jhovold>
Jasper[m]: yeah, as I mentioned in my talk, the windows calibration data is not compatible with the firmware the linux driver uses
<jhovold>
so you need to ask kalle and qualcomm to release the corresponding file for Linux
<jhovold>
Kalle prefers a request in bugzilla
<jhovold>
so that he can track the outstanding ones
<steev>
somewhere in the backlog of the channel, i mention which download from lenovo has the video acceleration firmware in it
<steev>
i'm not at home at the moment, so i don't have the filename in my history since i extracted it on a different system
<Jasper[m]>
<jhovold> "so you need to ask kalle and..." <- Not needed apparently, between when I wrote that question and now I got an .elf file from windows update which should work. Combined with ath11k-bdencoder and a json file.
<Jasper[m]>
Gonna test the file soon and submit it to Kalle
<Jasper[m]>
Thanks either way!
<Jasper[m]>
<steev> "somewhere in the backlog of..." <- Same for this, got a windows update cab with qcvss8280.mbn in it
<jhovold>
Jasper[m]: as i said, that elf file is not in the right format, that's the whole point i was trying to convey...
<steev>
if you still have windows lying around, you can just search the filename somewhere in FileRepository
<Jasper[m]>
jhovold: Was told by Ansuel that it may still work. Interesting.
<Jasper[m]>
I'm trying to get rid of the dependency on Windows to make a working image 😅
<jhovold>
Jasper[m]: i don't know who Ansuel is, but are you saying that he got it to work or that he thinks it will work?
<Jasper[m]>
jhovold: Ansuel does work on ath11k on the openwrt side of things. He suggested that something strips the elf header and it uses the boardfile that's included in the same file instead. Going off your reaction I think it might be ath11k-bdencodee that does it?
<Jasper[m]>
s/bdencodee/bdencoder/
<Jasper[m]>
It's the script that creates board-2.bin in thend, from the elf and a json file. So I guess that's it
<jhovold>
you need to use that tool at some point to include it in board-2.bin, but that was not enough for the x13s due to the compatibility issue
<steev>
yeah, i ended up getting some invalid device or something from my memories of trying to get it going; and needed to take the original board-2.bin and break it out first
<jhovold>
i have no idea if ansuel is up to date on the WoA compatibility issue or not, kalle wasn't initially, but is now
<Jasper[m]>
s/thend/the end/
<Jasper[m]>
I'll test the board-2.bin file I generated with bdencoder as-is for now and send a message to Kalle. Ansuel will ask around too. Thanks for the remarks!
<craftyguy>
jhovold, steev: thanks for the info wrt vid. acceleration. so if this is missing, the device consumes more power if I understood you correctly?
<danielt>
Jasper: When I last played about with geekbench, I recall thinking that the GNU/Linux binaries seemed better optimized than the Windows ones (which I put down to compiler or optimization level differences).
<danielt>
(for Arm)
<_[m]1>
ah lmao intel all of a sudden coming with 1.8nm and sooner 🙂
<_[m]1>
dunno how these sizes compary between cisc and risc
<_[m]1>
s/compary/compare/
<robclark>
_[m]1: I think apple will maybe pull a bit ahead with m3.. but that is kinda not relevant (not like you are going to have an option for m3 in lenovo or intel/amd/qc in a macbook).. but I doubt intel will catch up with their new things
<_[m]1>
it feels like a media war for now, trying to get stock prices up indeed
<_[m]1>
and I guess cisc or risc, moar transistors moar fun right
<robclark>
arm probably does have a bit of an advantage on the frontend (instruction decode).. but maybe the bigger advantage is that intel has been standing still for a while ;-)
<jhovold>
clover[m]: no idea, but i guess it could
matthias_bgg has quit [Ping timeout: 480 seconds]
matthias_bgg has joined #aarch64-laptops
<HdkR>
robclark: Intel has a fun trick that they use in their small CPU cores for making the frontend wider which they don't use on the big cores yet. They claim that the technique scales, so it should end up on their big cores when they want the frontend to be wider
<HdkR>
I think it's basically two instruction decoders where one speculates what the next instruction is and most of the time it is correct?
<robclark>
hmm, I guess that sort of prediction is harder for x86 than for something with fixed instruction size
<robclark>
pretty easy to predict the next instruction on anything with fixed instruction size ;-)
<HdkR>
Yea, pretty easy there. Only need to worry about the rando movprfx instruction which makes behaviour strange :D
<HdkR>
Architecturally a move, but does instruction fusion with the next instruction to effectively let you encode an additional register in the instruction encoding
<robclark>
oh, sve instruction... but I guess decode won't be your bottleneck for vec instructions
<HdkR>
The two cycle latency on vec instructions is definitely the pain point for a lot of x86 devs used to single cycle things
<HdkR>
Single cycle shuffles and integer operations is pretty cool to be fair
<robclark>
but does it have a parallel-copy instruction?
<HdkR>
What does a parallel-copy instruction do?
<robclark>
well, it is a theoretical instruction invented to make out-of-ssa work.. except that adreno has a swz instruction that swaps to registers (and is therefore basically a parallel-copy instruction)
<robclark>
lets you move things around without having another spare reg avail.. you can also do the same with a sequence of xor's but this lets you do it in one instruction
<bamse>
jenneron[m]: if you have any bug fixes to sc8180x, please help make sure we get those upstream
<bamse>
jenneron[m]: that said, i too noticed the interconnect/pci thing last week when i worked on my sc8180x...so i'll have to do some more debugging of that
<jenneron[m]>
bamse: only firmware path for lenovo flex 5g, i've also tried fixing touchscreen (needs reset gpio and regulators), but no luck so far
<jenneron[m]>
bamse: two days ago i figured out that using cmdline recommended for x13s solves this
<jenneron[m]>
UFS becomes 10 times faster and doesn't cause lag anymore
<jenneron[m]>
well.. i blindly copy-pasted all of that, probably not a good way
<bamse>
hmm, if that's the case we need to do some broader measurement of the iommu tlbsync latency...i've only seen the problem on sc8280xp
<robclark>
IIRC even on sc7180 we had to do some iommu opt/tuning.. although I don't remember the details, maybe dianders does?
<jenneron[m]>
bamse: btw have you looked into audio? there are patches for sm8150 in a wild, and it seems similar to sc8180x, e.g. slim and dma addresses and interrupts are the same to our ACPI
<robclark>
bamse: re: iommu.strict... I have vague memories of toggling wait-for-safe off for certain smmu users? Not sure if we need something like that on sc8180*/sc8280*? Looks like that was done via scm for sdm845 (and maybe just hard-coded in fw for sc7180??)
<dianders>
Though at some point in time after we landed that Qualcomm found that our firmware was missing the "wait for safe" fixes (IIRC). When that got landed in firmware combined with (I think?) some kernel change then we actually got nearly the same speedup even without disabling strict mode...
<dianders>
Ah, I guess this was the kernel fix for wait-for-safe: 5bccb945f38b ("drm/msm/disp/dpu1: add safe lut config in dpu driver")
<dianders>
...but there were firmware fixes needed too, so you may be out of luck there...
<bamse>
dianders: awesome, i suspected as much but my initial investigation didn't provide any "proof" in that direction
<bamse>
robclark: i tried enabling that quirk in the iommu driver, but it didn't affect my tlb sync times on 8280 at least, that said it was speculative, so i didn't try that hard
<bamse>
but effectively our problem is that __arm_smmu_tlb_sync() takes 1-2ms on 8280xp, while it seem to take < 10us on other platforms
<bamse>
the DMA-FQ, or iommu.strict=0 both makes the tlbsync asynchronious, and thereby hides the problem...except for HdkR's workloads
<HdkR>
My workloads hate everything
<steev>
on my system, when i add the iommu.strict=0, causes my usb->nvme to drop off
<bamse>
steev: i get that with the new enclosure i bought as well...but with iommu.strict=1 i was able to trigger it as well, just took much much longer time
<steev>
it seems to happen for me the most when i try to run git updates on all 655 git repos in kali
<steev>
its a realtek RTL9210B-CG adapter
<steev>
(and gosh do i hate realtek)
<steev>
i can rant for days about their wifis
<HdkR>
When I update the kernel on my X13s I'll check if the 5gbit adapter still causes the kernel to oops
<robclark>
bamse: oh, hmm.. sc8280xp does seem to miss safe_lut_tbl in dpu hw catalog.. so that might be a smoking gun
<craftyguy>
jhovold: sorry for the dumb question, but where's your branch with the vid. accel fw? I didn't see it on git.kernel.org or github
<bamse>
robclark: but i presume that wouldn't be the only safe "user" in the system(?)
<konradybcio>
craftyguy due to legal stuff we can't distribute it (yet?)
<konradybcio>
you need to copy it from the windows partition
<craftyguy>
ah
<robclark>
bamse: camera is the other one I think.. if it is sharing the same apps_smmu
<robclark>
but looking at commit history, fixing that in dpu was a big help for emmc/usb (and maybe wifi?)
<bamse>
on 8280 pcie has its own smmu
<bamse>
robclark: wtf, that brought my tlbsync times from 1-2ms to 4-8us...thank you
<bamse>
dianders: thanks
<robclark>
\o/
<HdkR>
:O
<konradybcio>
whaat
<HdkR>
That sounds exciting
<robclark>
I wonder what it would be if camera were active? I guess then we might need similar fix in camera driver?
<robclark>
WARN_ON() might be too much.. and I'm not 100% sure if there are some platforms we don't need to configure.. I guess that would be a better question for abhinav
<dianders>
bamse: sweet! Yeah, I remember it was quite a shock after countless hours of discussions about this with various folks at Qualcomm and upstream to suddenly find that we just had a few bits set incorrectly.
<bamse>
robclark: on sdm845 we explicitly turn off the safe wait, so there it shouldn't be needed
<bamse>
dianders: my previous experience with the safe logic was that it made ufs 1000x slower on 845...so this wasn't in the same ballbark as my expectations
<bamse>
although ms -> us is 1000x...
<jenneron[m]>
<bamse> "robclark: wtf, that brought my..." <- do you mean the patch?
<jenneron[m]>
and do you mean sc810x?
<bamse>
jenneron[m]: sc8280xp
<jenneron[m]>
sc8180x*
<jenneron[m]>
i see
<robclark>
looks like sc8180x needs the same
<bamse>
jenneron[m]: but sc8180x has the same problem
<bamse>
jenneron[m]: i'll measure that as well and will send out a patch
<hexdump0815>
travmurav[m]: there is still a lot to be done before this can go to mainline - i marked everything where i'm not really sure about with TODO in there
<hexdump0815>
travmurav[m]: in case you like it would be very nice if you could have a look over it and maybe remove/change things you know in a pull request against it
<hexdump0815>
travmurav[m]: i have built it from scratch based on the mainline v6.6 aspire1 dts, so that it is easy to diff the two against each other in the end to see what is different/still missing
<hexdump0815>
travmurav[m]: at least the dts compiles fine into a dtb and a kernel with that boots on the galaxy book with v6.6 - on my quick test kbd did not work at all, so will have to check that in more detail
<hexdump0815>
travmurav[m]: there is still a bit or refinement to be done, but at least it is a beginning :) ... the .wip dts in the same dir is my full wip dts which works as good as before and has tons of notes in it
<steev>
HdkR: lenovo-x13s-linux-6.6.y - has bamse's patch in it if you wanna give it a whirl (it's johan's 6.6 with the usual stuff i add on top, and then the new patch)
<HdkR>
steev: Oh cool, when I get a minute I'll update and give it a try
<steev>
clover[m]: ^^
<clover[m]>
cool, updating
<steev>
with that you *should* be able to remove the iommu bits, i think, from your kernel cmdline
<steev>
i wasn't using them here cuz it was breaking my nvme