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
hightower2 has joined #aarch64-laptops
smpl has quit [Ping timeout: 480 seconds]
KREYREN_oftc has quit [Remote host closed the connection]
hexdump0815 has joined #aarch64-laptops
hexdump01 has quit [Ping timeout: 480 seconds]
KREYREN_oftc has joined #aarch64-laptops
KREYREN_oftc has quit [Remote host closed the connection]
KREYREN_oftc has joined #aarch64-laptops
KREYREN_oftc has quit [Remote host closed the connection]
KREYREN_oftc has joined #aarch64-laptops
KREYREN_oftc has quit [Remote host closed the connection]
laine has quit [Quit: (╯°□°)╯︵ ┻━┻]
alfredo has joined #aarch64-laptops
alfredo has quit [Quit: alfredo]
alfredo has joined #aarch64-laptops
possiblemeatball has quit [Quit: Quit]
possiblemeatball has joined #aarch64-laptops
possiblemeatball has quit [Quit: Quit]
possiblemeatball has joined #aarch64-laptops
possiblemeatball has quit [Remote host closed the connection]
possiblemeatball has joined #aarch64-laptops
adamcstephens has quit [Remote host closed the connection]
adamcstephens has joined #aarch64-laptops
possiblemeatball has quit [Quit: Quit]
jhovold has joined #aarch64-laptops
alfredo has quit [Read error: Connection reset by peer]
alfredo has joined #aarch64-laptops
alfredo has quit [Read error: Connection reset by peer]
iivanov has joined #aarch64-laptops
iivanov has quit []
iivanov has joined #aarch64-laptops
martiert_work has quit [Ping timeout: 480 seconds]
smpl has joined #aarch64-laptops
martiert_work has joined #aarch64-laptops
Segfault[m] has joined #aarch64-laptops
<Segfault[m]>
hmm that's strange, on my x13s the top usb-c port consistently only works for charging, the bottom port works fine for charge and data
suihkulokki has joined #aarch64-laptops
alfredo has joined #aarch64-laptops
<KieranBingham[m]>
<HdkR> "steev: What would the NPU be..." <- For camera NPU can be interesting (way, way, way, in the future) for things like FaceDetection to make sure the AGC/Autofocus is tracked to the face, or for different AWB implementations. There's lots of research at the moment using NN's for other image processing like better denoise and colour corrections too. But ... not anything I'll worry about needing to integrate in the x13s in
<KieranBingham[m]>
the near future :D
<KieranBingham[m]>
Also - the only time I've seen AGC tracked against face detection - it's /awful/ You can play 'peek-a-boo' with the camera where it changes the brightness/contrast of the image depending on if your face is visible or not - and it's horrifically distracting for video calls ...
<KieranBingham[m]>
s/also/although/
iivanov has quit [Remote host closed the connection]
alfredo has quit [Read error: Connection reset by peer]
alfredo1 has joined #aarch64-laptops
alfredo1 is now known as alfredo
iivanov has joined #aarch64-laptops
alfredo has quit [Quit: alfredo]
Lucanis has quit [Ping timeout: 480 seconds]
<HdkR>
KieranBingham[m]: Spicy. I'm happy my webcam has locked ISO and exposure so I don't need to deal with that :D
<HdkR>
and shutter speed*
Lucanis has joined #aarch64-laptops
iivanov has quit [Remote host closed the connection]
iivanov has joined #aarch64-laptops
Liso[m] has joined #aarch64-laptops
Las[m] has joined #aarch64-laptops
ahoneybun[m] has joined #aarch64-laptops
aigotchi[m] has joined #aarch64-laptops
Nei[m] has joined #aarch64-laptops
ajhalaney[m] has joined #aarch64-laptops
akawolf[m] has joined #aarch64-laptops
albsen[m] has joined #aarch64-laptops
arisu has joined #aarch64-laptops
AlexMarty[m] has joined #aarch64-laptops
anarchron has joined #aarch64-laptops
anonymix007[m] has joined #aarch64-laptops
Anton[m]1 has joined #aarch64-laptops
ArtyomK[m] has joined #aarch64-laptops
averyfreeman[m] has joined #aarch64-laptops
baspar[m] has joined #aarch64-laptops
bioxvirizm[m] has joined #aarch64-laptops
bumble[m] has joined #aarch64-laptops
Leandro[m]12345 has joined #aarch64-laptops
pz[m] has joined #aarch64-laptops
clover[m] has joined #aarch64-laptops
cmeerw[m] has joined #aarch64-laptops
danielt has joined #aarch64-laptops
dcavalca has joined #aarch64-laptops
davidebeatrici[m] has joined #aarch64-laptops
EricCurtin[m] has joined #aarch64-laptops
Lucanis has quit [Ping timeout: 480 seconds]
emily[m]1 has joined #aarch64-laptops
EnigmaCurry[m] has joined #aarch64-laptops
enserzo[m] has joined #aarch64-laptops
firlaev-hans-fiete[m] has joined #aarch64-laptops
freekurt[m] has joined #aarch64-laptops
Guest8372 has joined #aarch64-laptops
harvests[m] has joined #aarch64-laptops
harvestz[m] has joined #aarch64-laptops
hlr[m] has joined #aarch64-laptops
szclsya[m] has joined #aarch64-laptops
Jasper[m] has joined #aarch64-laptops
jjardon[m] has joined #aarch64-laptops
juergh1 has joined #aarch64-laptops
kazek[m] has joined #aarch64-laptops
konradybcio has joined #aarch64-laptops
LoganLeland[m] has joined #aarch64-laptops
LikeNeosMatrix[m] has joined #aarch64-laptops
lollaritits[m] has joined #aarch64-laptops
lun[m] has joined #aarch64-laptops
z3ntu has joined #aarch64-laptops
Lucy[m] has joined #aarch64-laptops
malvi[m]1 has joined #aarch64-laptops
matrix638[m] has joined #aarch64-laptops
matthew[m]123 has joined #aarch64-laptops
mothenjoyer69 has joined #aarch64-laptops
NomadNaomie[m] has joined #aarch64-laptops
nekogirl[m] has joined #aarch64-laptops
neobrain[m] has joined #aarch64-laptops
nicholascw[m] has joined #aarch64-laptops
Nick[m]1234 has joined #aarch64-laptops
nick1343[m] has joined #aarch64-laptops
Nao[m] has joined #aarch64-laptops
nscnt[m] has joined #aarch64-laptops
owc[m] has joined #aarch64-laptops
patzek[m] has joined #aarch64-laptops
PterKoczka[m] has joined #aarch64-laptops
pine-clover[m] has joined #aarch64-laptops
DocGalaxyBlock[m] has joined #aarch64-laptops
Prawn[m] has joined #aarch64-laptops
psydroid[m] has joined #aarch64-laptops
KhalIshaIii[m] has joined #aarch64-laptops
quinine has joined #aarch64-laptops
valida-69[m] has joined #aarch64-laptops
Guest8437 has joined #aarch64-laptops
resuenehparg[m]1 has joined #aarch64-laptops
sally[m]123 has joined #aarch64-laptops
sally[m]1234 has joined #aarch64-laptops
cenunix[m] has joined #aarch64-laptops
shjim[m] has joined #aarch64-laptops
SintayewGashaw[m] has joined #aarch64-laptops
Sobek[m] has joined #aarch64-laptops
sporos11[m] has joined #aarch64-laptops
steevdave[m] has joined #aarch64-laptops
steveej[m] has joined #aarch64-laptops
Stirl[m] has joined #aarch64-laptops
strongtz[m] has joined #aarch64-laptops
sz3m3k[m] has joined #aarch64-laptops
M0133oracle[m] has joined #aarch64-laptops
underpantsgnome[m] has joined #aarch64-laptops
vadikas[m] has joined #aarch64-laptops
valentine has joined #aarch64-laptops
Nios34[m] has joined #aarch64-laptops
wiizzard has joined #aarch64-laptops
dlx[m] has joined #aarch64-laptops
iivanov has quit [Remote host closed the connection]
iivanov has joined #aarch64-laptops
<clover[m]>
Gdm with arch linux logo just dropped lol
<robclark>
bamse: re: NPU/hexagon, I wonder if anyone has looked at DRM accel stuff, and whether that would be suitable? jhugo was, IIRC, looking at that for the cloud AI thing, idk how similar that is to hexagon... https://lkml.org/lkml/2024/5/18/87
<robclark>
also, did anyone hear back yet about the x1e dev kit after filling the web form thing?
<bamse>
robclark: to my knowledge noone has looked at that, as we already have fastrpc in the kernel
<maz>
robclark: I got an email saying they'd get in touch at some point.
<bamse>
robclark: jhugo has managed to land the cloud AI interface driver therein, but they are different
<Jasper[m]>
robclark: Just that I'm in the queue
<robclark>
I guess the question is how buffer mgmt works with fastrpc? And would GEM add anything useful
<robclark>
hmm, ok.. I don't _think_ I got an email.. but I guess I should check spam folder
<maz>
it definitely has all the hallmarks of a spam email (html galore...)
<robclark>
from an @qualcomm.com
<robclark>
?
<maz>
qdn.news@qti.qualcomm.com
<robclark>
thx... not finding it tho :-/
<Jasper[m]>
robclark: I re-registered with a different email and got it still. If you want to be sure you can probably try again
<robclark>
yeah, perhaps I should do that
<robclark>
hmm, probably the first time, I didn't check the "please send me spam" checkbox
<maz>
I'm sure I didn't check that one...
<robclark>
hmm, this time I got a response email immediately.. idk if it is related to the checkbox or not (I used my work email which is already already on their spam list somehow)
<Jasper[m]>
I didn't either
<\[m]>
did you invert the direction?
possiblemeatball has joined #aarch64-laptops
iivanov has quit [Remote host closed the connection]
<Dylanger[m]>
How will the NPU look to Linux? A PCIe device?
<Jasper[m]>
Isn't it drm?
<Jasper[m]>
I think the etnaviv npu driver is being developed under that subsystem
<robclark>
it isn't currently drm.. it is fastrpc.. whether it _should_ be drm, idk.. it probably looks less like a gpu than vivante's npu
<Jasper[m]>
Aha, didn't know about that last detail
iivanov has joined #aarch64-laptops
<jhugo>
I dunno. I think its pretty close to Adreno - as in an on-SoC "GPU"
iivanov has quit [Ping timeout: 480 seconds]
<robclark>
I assume in ACPI it is part of the "gpu"?
<robclark>
I guess, my question is how buffer passing/mapping works? Depending on how that works, re-using GEM could be useful or not.
iivanov has joined #aarch64-laptops
iivanov has quit [Ping timeout: 480 seconds]
iivanov has joined #aarch64-laptops
alfredo has quit [Quit: alfredo]
iivanov has quit [Ping timeout: 480 seconds]
alfredo has joined #aarch64-laptops
<jhugo>
No, I'm saying that the NPU is a Q6 CPU attached to the SoC that can receive a workload kernel and run it, much in the same way that the GPU does
<robclark>
right.. but in vivante case, I assume they use the same sort of command-stream format as 2d and 3d cores
<jhugo>
From memory, fastrpc uses shared memory buffer passing - host allocates memory from some location that the NPU can also access, fills in the data, then assigns the buffer over the NPU
alfredo has quit [Quit: alfredo]
<jhugo>
"from memory" - what I recall
<robclark>
that part, it seems kinda like re-using GEM would be useful
<robclark>
is the hexagon sitting behind an arm-smmu? Or does it have it's own mmu thing?
iivanov has joined #aarch64-laptops
iivanov has quit [Remote host closed the connection]
<jhugo>
again from my memory, modern MSMs are smmu-500 (ish) so I think of it as one global SMMU, where nearly every block is behind its own TBU
<jhugo>
I'm pretty sure the NPU q6 is the same
<jhugo>
In concept, yes, I think its behind a SMMU
<robclark>
then could probably just re-use drm_gem_dma_object
<steev>
Segfault[m]: fwiw, i can't reproduce that here :( i can plug in my apple hdmi adapter to either port and it lets me use the external display
possiblemeatball has quit [Quit: Quit]
iivanov has joined #aarch64-laptops
<Dylanger[m]>
<jhugo> "In concept, yes, I think its..." <- This is why Qualcomm don't wanna give raw/direct EL2 access to anyone other than Ganyah/themselves
<jhugo>
Dylanger[m]: No comment :)
iivanov has quit [Quit: Leaving...]
<JensGlathe[m]>
This odd behaviour of all big players is puzzling. They want to use linux, though. Or is it just their engineers?
<robclark>
I think the answer is that they want to support linux, but linux is just a small part of the market so the linux side of the house doesn't have as much influence on fw and hw architecture designs ;-)
rz has joined #aarch64-laptops
<JensGlathe[m]>
business case -> hw design -> fw development -> "extended" fw development (os, drivers) -> actual devices on the market. Judging by the results, the only (*) corp that I see that has this down pat is apple, and they're strained sometimes.
<JensGlathe[m]>
And I guess it starts with business case.
<Dylanger[m]>
<jhugo> "Dylanger: No comment :)" <- 😉 just plz give us the ability to from UEFI or something, I can understand the security risks, but giving users power over EL2 would be amazing
<robclark>
I'm not sure there are actually security risks outside of protected-content
<Dylanger[m]>
That makes me a little more angy
<robclark>
and I guess that is a feature more linux users aren't really caring too much about
<steev>
most linux users already have access to kvm outside of qcom devices
<JensGlathe[m]>
wth is protected content, this is ridiculous. Security by obscurity in the end, increasing just the cost of doing business, but not security.
<steev>
my rock5b has had kvm access since 5.10
<Dylanger[m]>
Qualcomm's custom EL2 very likely increases attack surface too
<steev>
i'm torn because as i user i don't want that, but as an attacker i do
<Dylanger[m]>
Bahaha
<Dylanger[m]>
same tbh
<steev>
realistically though, i just want kvm access (and being able to access the rest of the system too)
<steev>
i have so many tools for distro work that rely on kvm access
<steev>
and i have to run them on inferior hardware
<Dylanger[m]>
In my perfect world, they'll let you have access to EL2 and possibly even EL3, but they'll display an unlocked lock icon on the bootscreen or something, like what happens when you unlock the bootloader on Pixel's/Xaomi devices
<HdkR>
Is the hardware really inferior if it offers a feature you require?
<Dylanger[m]>
That's how I envision it
<steev>
HdkR: yes. because it means i can't do anything else with that hardware while i wait for it to complete
<JensGlathe[m]>
slbounce gives you EL2 on qcom, but no zap shader and some other things
<steev>
can i have nvme?
<robclark>
technically zap shader isn't needed if you have EL2 boot, so it isn't really something that is "missing"
<robclark>
zap shader just clears the GPU state and takes it out of "secure" (as in protected-content) mode
<HdkR>
steev: I'm still using the "inferior" NVIDIA Orin because I can plug a Radeon in to it. Nothing else gives me that same feature set so I keep using it :P
<JensGlathe[m]>
and I have yet to actually test/stress the rk1 cluster that's blinking here, but the rk3588 has ~75% of the CPU power of the sc8280xp by the benchmark numbers
<JensGlathe[m]>
steev: yes it works
<steev>
i thought you said before that pcie was broken
<HdkR>
steev: SR-IOV is broken, PCIe actually works
<steev>
all those snaps smh
<JensGlathe[m]>
cmon I'm not a unix guy
<steev>
that's not even a you thing
<HdkR>
er wait, VFIO is broken, I dunno about SR-IOV since it requires VFIO
<steev>
that's ubuntu not wanting to maintain stuff
<JensGlathe[m]>
steev: truth
<steev>
hm, so maybe i should try it on the x13s then
<JensGlathe[m]>
anyway, that's why I dug into the smmu patchset for 6.10. to understand what's going on. smmu, no way thats black magic, but the setup code
<steev>
oh wait, wasn't it no remote procs? so no battery charging?
<JensGlathe[m]>
true
<JensGlathe[m]>
travmurav: hinted that there might be a way to get them, chromeOS has a way to do this
<steev>
because google gets to throw their weight around and tell companies to give them good(ish) firmware
<JensGlathe[m]>
I have both variants on the device. normal kernel (with all the definitions for the smmu), and slbounce + el2-enabled dtb. So both is possible. On the normal kernel you just don't have kvm
<JensGlathe[m]>
steev: there's a hint then
<jhugo>
Dylanger[m]: If I had that kind of power, I would